Software Project Management

Demystifying the Capability Maturity ModelBrian ParrishSENG 510Software Project ManagementInstructor: Larry JacowitzMarch 27, 2003With the increasing push by the U.S. government to verify that their subcontractors have achieved certain Capability Maturity Model (CMM) levels, there is an increased need to understand the workings of the CMM. Judy Bamberger states “the CMM is one of the most misunderstood pieces of technical literature in existence.” [Bemberger] This paper will be an attempt to de-fog the CMM language and help the reader achieve a better understanding of it.After several decades of missed deadlines, overrun budgets and sub-par quality products, software developers realized that mismanagement of the software process was their primary shortfall. This realization started the research initiative that led to the CMM. In late 1986, the Software Engineering Institute (SEI) and Mitre Corporation began development of a process maturity framework that would enable software process improvement by developers. This framework was released by SEI in a September 1987 description document. [Humphrey 1] Since the SEI was a government funded organization, they could not evaluate private organizations. This situation led to the development of the software-process assessment and the software-process evaluation. They also developed a maturity questionnaire to appraise software process maturity. [Humphrey 2] After four years of experience with the process maturity framework, the SEI evolved it into the CMM. This evolution was consummated by the release of version 1.0 of the CMM in 1991.Parrish 1Since its inception, the CMM has evolved into the following focus areas:¾SW-CMM - Capability Maturity Model for Software¾P-CMM - People Capability Maturity Model¾SA-CMM - Software Acquisition Capability Maturity Model¾SE-CMM - Systems Engineering Capability Maturity Model¾IPD-CMM - Integrated Product Development Capability Maturity Model For the purposes of this paper, the term “CMM” will refer to the SW-CMM since thiswas the CMM development team’s original intent.Since the CMM focuses on the ideas of mature organizations versus immatureorganizations, it would behoove the reader to have an understanding of what is meant bymature and immature in this context.In a mature organization, there is an organization-wide ability to manage maintenanceand development. Managers can accurately communicate the software process and workactivities to staff because of the planned process. The processes actually model the ways inwhich work is actually done within the organization and are updated when necessary.Roles and responsibilities are clear within the project and across the organization.Schedules and budgets are based on realistic historical performance. Expected results areusually achieved for cost, quality and functionality. Quality is monitored as well as theprocesses that produce it. Generally, the process is consistently followed and there is abuy-in by all of the participants due to an understanding of the benefits of compliance.Immature organizations have ad-hoc software processes that are created on-the-fly bydevelopers and project managers. If there is an organization-wide software process plan, itis not followed or enforced. The organization takes a reactionary approach to development2and maintenance by having the managers more focused on solving crises than on process improvement. Schedules and budgets are routinely exceeded. Product quality and functionality suffer when deadlines are enforced to meet a schedule. Since there is no way to judge product quality or solve problems, product quality is difficult to predict and activities to improve quality are often overlooked when trying to meet a schedule. These activities include testing and reviews.Figure 1 - Maturity FrameworkThe CMM is based on many small steps rather than large world-shattering innovations. The CMM provides a framework for organizing these evolutionary steps in five maturity levels as shown in Figure 1. Each maturity level is comprised of a set of goals that, when3satisfied, result in an increase in process maturity. The arrows in Figure 1 represent the set of ideas that are being implemented at that level. For example, to get from level 1 to level 2, an organization must implement disciplined processes.Level 1: Initial. Level 1 organizations do not have a stable environment for development and maintenance of software. There is usually difficulty making commitments that the staff can meet with an orderly engineering process. This usually results in a series of crises. During such a crisis, planned processes are ignored and the organization reverts to coding and testing. Success depends on having strong project management that can withstand outside influences that are trying to change the process. Despite the chaotic nature of level 1 organizations, they may be able to develop working products, but the chances of doing so on time and under budget are quite slim. This level of organization relies on heroic individuals and that makes this level individually capable instead of organizationally capable.Level 2: Repeatable. At the Repeatable level, policies for managing a software project and procedures to implement those policies are established. The planning and management of a project is based on experience with similar projects. Projects in level 2 organizations have installed basic management controls. Project managers track costs, schedules and functionality and identify problems in meeting commitments when they arise. Software requirements and the products developed to satisfy them are baselined and their integrity is controlled. Project standards are defined and the organization ensures that they are faithfully followed. Processes may differ among projects in a level 2 organization. To achieve level 2, an organization must have policies that help project managers establish4appropriate management processes. Level 2 organizations have disciplined processes because project planning and tracking are stable and earlier processes can be repeated. Because of the repeatable nature of the processes, prior successes can be relived and prior failures can be avoided.Level 3: Defined. At the Defined level, a typical process for developing and maintaining software across the organization is documented, including both software -engineering and management processes, and these processes are integrated into a consistent whole. A group, such as a software-engineering process group, is responsible for an organization’s process activities. [Fowler] An organization-wide training program ensures that the staff and managers have the knowledge and skills that they require. Project teams tailor an organization’s standard software process to develop their own defined process, which takes into account the project’s unique characteristics. A well defined process includes readiness criteria, inputs, standards and procedures for performing the work, verification mechanisms, outputs and completion criteria. An example of a verification mechanism is a peer review. Because the process is well defined, management has good insight into technical progress on all projects. Level 3 organizations are standard and consistent because both software engineering and management activities are stable and repeatable. This process capability is based on a common, organization-wide understanding of the activities, roles and responsibilities in the defined processes.Level 4: Managed. At the Managed level, an organization sets quantitative quality goals for both products and processes and refines processes with well-defined and consistent measurements. Productivity and quality are measured for important process5activities across all projects as part of an organizational measurement program. Software products are predictably of high quality. An organization wide database is used to collect and analyze the data available from a project’s defined processes. These measurements establish the quantitative foundation for evaluating a project’s processes and products. Projects control their products and processes by narrowing the variation in their performance to fall within acceptable quantitative boundaries for the organization. Level 4 organizations are quantifiable and predictable because the process is measured and operates within measurable limits. This level of capability lets an organization predict trends in process and product quality within the quantitative bounds of these limits.Level 5: Optimizing. At the Optimizing level, the entire organization is focused on continuous process improvement. The organization has the means to identify weaknesses and strengthen the process proactively, with the goal of preventing defects. Data on process effectiveness is used to perform cost-benefit analysis on new technologies and propose changes to the process. Project teams analyze defects to determine their causes, evaluate the process to prevent known types of defects from recurring and disseminate lessons learned to other projects. Organized efforts to remove waste result in changing the system by changing the common causes of inefficiency. Reducing waste happens in all of the levels, but it is the predominant theme at level 5. Level 5 organizations are continuously improving because they are continuously striving to improve the range of their process capability, thereby improving the process performance of their projects. Improvement occurs both by incremental advancements and by innovations in technologies6and methods. Technology and process improvements are planned and managed as ordinary business activities.One of the major downfalls of the CMM is how organizations choose to apply it. The CMM was not meant to be a progress marker for organizations, but instead a tool that should be applied and modified to fit their organization. Judy Bamberger, one of the original authors of the CMM, states that “the CMM wasn’t intended to be all things to all people or cover all aspects of software and system development.” [Bemberger] A very important aspect of process development that the CMM leaves out is the people aspect. This includes how to retain people, team dynamics and other important activities.There are countless ways to integrate the CMM into an organizations framework. Two interesting examples of large efforts are the Federal Aviation Administration (FAA) and the U.S. Army Simulation, Training and Instrumentation Command (STRICOM). These are interesting because they both produced successful results but went about the process in different ways.The FAA took several different CMM models including the SW-CMM, the SE-CMM and the SA-CMM and incorporated them into one version called the FAA Integrated Maturity Model (FAA-iCMM). They use this model to “increase the efficiency and effectiveness of FAA processes and process improvement efforts.” [Sheard] This model has been in place since March 1997.U.S. Army STRICOM took a different approach in that they adopted one of the original CMM models, the SA-CMM, and molded to fit that process themselves. They did not7tailor the model to fit their organization; instead, they tailored their organization to fit the model. This model also has been in place since March 1997.The CMM has proved to be an invaluable tool when it is tailored to an organizations needs. However, the organization needs to understand that the CMM may not be the total solution that is needed for their process improvement goals.8References[Humphrey 1] W.S. Humphrey. “Characterizing the Software Process: A Maturity Framework.” IEEE Software. March 1998. pp. 73-79.[Humphrey 2] W.S. Humphrey and W.L. Sweet. ”A Method For Assessing the Software Engineering Capability of Contractors.” Tech. Report CMU/SEI-87-TR-24,ADA235784, Software Engineering Institute, Pittsburgh, 1987.[Fowler] P. Fowler and S. Ritkin. “Software Engineering Process Group Guide.” Tech.Report CMU/SEI-90-TR-24, ADA235784, Software Engineering Institute,Pittsburgh, 1990.[Bemberger] Bemberger, J. (June 1997) Essence of the Capability Maturity Model. IEEE Computer, p. 112-114.[Helrsleb] J. Helrsleb, et. al. “Software Quality and the Capability Maturity Model.”Communication of the ACM. Online. Available:“/SWPI/processframework/cmm/cmm.html.” AccessedMarch 20, 2003.[Card] D. Card. “Sorting Out Six Sigma and the CMM.” Online. Available:/pub/externalpapers/sorting_out_six_sigma.pdf. Accessed:March 20, 2003.[Sheard] S. Sheard and S. Rose. “Two Approaches to CMM Integration.” Online.Available: /pub/externalpapers/9804-1.html.” Accessed:March 20, 2003.9。