Capability Maturity Model

The Capability Maturity Model (CMM) is a service mark registered with the U.S. Patent and Trademark Office by Carnegie Mellon University (CMU) and refers to a development model that was created after study of data collected from organizations that contracted with the U.S. Department of Defense, who funded the research. This became the foundation from which CMU created the Software Engineering Institute (SEI). Like any model, it is an abstraction of an existing system. When it is applied to an existing organization's software development processes, it allows an effective approach toward improving them. Eventually it became clear that the model could be applied to other processes. This gave rise to a more general concept that is applied to business processes and to developing people. Overview The Capability Maturity Model (CMM) was originally developed as a tool for objectively assessing the ability of government contractors' processes to perform a contracted software project. The CMM is based on the process maturity framework first described in the 1989 book Managing the Software Process by Watts Humphrey. It was later published in a report in 1993 (Technical Report CMU/SEI-93-TR-024 ESC-TR-93-177 February 1993, Capability Maturity Model for Software, Version 1.1) and as a book by the same authors in 1995. Though the CMM comes from the field of software development, it is used as a general model to aid in improving organizational business processes in diverse areas; for example in software engineering, system engineering, project management, software maintenance, risk management, system acquisition, information technology (IT), services, business processes generally, and human capital management. The CMM has been used extensively worldwide in government offices, commerce, industry and software development organizations. Prior need for software processes: In the 1970s, the use of computers grew more widespread, flexible and less costly. Organizations began to adopt computerized information systems, and the demand for software development grew significantly. The processes for software development were in their infancy, with few standard or "best practice" approaches defined. As a result, the growth was accompanied by growing pains: project failure was common, and the field of computer science was still in its early days, and the ambitions for project scale and complexity exceeded the market capability to deliver. Individuals such as Edward Yourdon, Larry Constantine, Gerald Weinberg, Tom DeMarco, and David Parnas began to publish articles and books with research results in an attempt to professionalize the software development process.

In the 1980s, several US military projects involving software subcontractors ran over-budget and were completed far later than planned, if at all. In an effort to determine why this was occurring, the United States Air Force funded a study at the SEI. Active development of the model by the US Department of Defense Software Engineering Institute (SEI) began in 1986 when Humphrey joined the Software Engineering Institute located at Carnegie Mellon University in Pittsburgh, Pennsylvania after retiring from IBM. At the request of the U.S. Air Force he began formalizing his Process Maturity Framework to aid the U.S. Department of Defense in evaluating the capability of software contractors as part of awarding contracts. Watts Humphrey's Capability Maturity Model (CMM) was published in 1988[3] and as a book in 1989, in Managing the Software Process. Organizations were originally assessed using a process maturity questionnaire and a Software Capability Evaluation method devised by Humphrey and his colleagues at the Software Engineering Institute (SEI). The full representation of the Capability Maturity Model as a set of defined process areas and practices at each of the five maturity levels was initiated in 1991, with Version 1.1 being completed in January 1993. The CMM was published as a book in 1995 by its primary authors, Mark C. Paulk, Charles V. Weber, Bill Curtis, and Mary Beth Chrissis. The Capability Maturity Model involves the following aspects:

Maturity Levels: a 5-level process maturity continuum - where the uppermost (5th) level is a notional ideal state where processes would be systematically managed by a combination of process optimization and continuous process improvement. Key Process Areas: a Key Process Area (KPA) identifies a cluster of related activities that, when performed together, achieve a set of goals considered important. Goals: the goals of a key process area summarize the states that must exist for that key process area to have been implemented in an effective and lasting way. The extent to which the goals have been accomplished is an indicator of how much capability the organization has established at that maturity level. The goals signify the scope, boundaries, and intent of each key process area. Common Features: common features include practices that implement and institutionalize a key process area. There are five types of common features: commitment to Perform, Ability to Perform, Activities Performed, Measurement and Analysis, and Verifying Implementation. Key Practices: The key practices describe the elements of infrastructure and practice that contribute most effectively to the implementation and institutionalization of the KPAs.

CMM Levels There are five levels defined along the continuum of the CMM and, according to the SEI: "Predictability, effectiveness, and control of an organization's software processes are believed to improve as the organization moves up these five levels. While not rigorous, the empirical evidence to date supports this belief." 1. Initial (chaotic, ad hoc, individual heroics) - the starting point for use of a new process. 2. Managed - the process is managed in accordance with agreed metrics. 3. Defined - the process is defined/confirmed as a standard business process, and decomposed to levels 0, 1 and 2 (the latter being Work Instructions). 4. Quantitatively managed 5. Optimizing - process management includes deliberate process optimization/improvement. Level 1 - Initial (Chaotic) It is characteristic of processes at this level that they are (typically) undocumented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled and reactive manner by users or events. This provides a chaotic or unstable environment for the processes. Level 2 - Repeatable It is characteristic of processes at this level that some processes are repeatable, possibly with consistent results. Process discipline is unlikely to be rigorous, but where it exists it may help to ensure that existing processes are maintained during times of stress. Level 3 - Defined It is characteristic of processes at this level that there are sets of defined and documented standard processes established and subject to some degree of improvement over time. These standard processes are in place (i.e., they are the AS-IS processes) and used to establish consistency of process performance across the organization. Level 4 - Managed It is characteristic of processes at this level that, using process metrics, management can effectively control the AS-IS process (e.g., for software development ). In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Process Capability is established from this level. Level 5 - Optimizing It is a characteristic of processes at this level that the focus is on continually improving process performance through both incremental and innovative technological changes/improvements. At maturity level 5, processes are concerned with addressing statistical common causes of process variation and changing the process (for example, to shift the mean of the process performance) to improve process performance. This would be done at the same time as maintaining the likelihood of achieving the established quantitative process-improvement objectives.

Within each of these maturity levels are Key Process Areas (KPAs) which characterize that level, and for each KPA there are five definitions identified: 1. 2. 3. 4. 5. Goals Commitment Ability Measurement Verification

The KPAs are not necessarily unique to CMM, representing as they do the stages that organizations must go through on the way to becoming mature.