The Capability Maturity Model (CMM) in software engineering is a model of the maturity of the capability of certain business processes. A maturity model can be described as a structured collection of elements that describe certain aspects of maturity in an organization, and aids in the definition and understanding of an organization's processes. The CMM has been superseded by the Capability Maturity Model Integration (CMMI).
Contents
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 and later published in its full form as a book in 1995 by Mark Paulk, Charles Weber, Bill Curtis, and Mary Beth Chrissis. Though it comes from the area of software development, it has also been applied to improving organizational 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, and human capital management. The CMM has been used extensively not only by government, but has also been widely adopted in software and application development organizations around the world, and most notably by organizations offering offshore outsourcing services.
History
The Capability Maturity Model is based on the Process Maturity Framework first described in the 1989 book "Managing the Software Process" by Watts Humphrey. Humphrey based this framework on the earlier Quality Maturity Grid developed by Philip Crosby in his book "Quality Is Free". However, Humphrey's approach differed because of his unique insight that organizations mature their processes in stages based on solving process problems in a specific order. Humphrey based his approach on the staged evolution of a system of software development practices within an organization, rather than measuring the maturity of each separate development process independently. This insight has given the staged maturity models based on Humphrey's original framework their unique power for improving organizational performance[citation needed][neutrality disputed].
Humphrey began developing his process maturity concepts during the later stages of his 27 year career at IBM. He joined the Software Engineering Institute located at Carnegie Mellon University in Pittsburgh, Pennsylvania in 1986 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. Organizations were originally assessed using a process maturity questionnaire and a Software Capability Evaluation method devised by Humphrey and his colleagues at the SEI[clarification needed]. The full representation of the Capability Maturity Model as a collection of defined process areas and practices at each of the five maturity levels was initiated 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 CMM has been superseded by the Capability Maturity Model Integration (CMMI).
Context
In the 1970s the use of computers became more widespread, flexible and less expensive. 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 infancy, 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.
Watts Humphrey's Capability Maturity Model (CMM) was described in Managing the Software Process. The CMM as conceived by Watts Humphrey was based on the work a decade earlier of Phil Crosby who published the Quality Management Maturity Grid in his book Quality is Free in 1979.[1] Active development of the model by the US Department of Defense Software Engineering Institute (SEI) began in 1986.
The CMM was originally intended as a tool to evaluate the ability of government contractors to perform a contracted software project. Though it comes from the area of software development, it can be, has been, and continues to be widely applied as a general model of the maturity of processes (e.g. IT Service Management processes) in IS/IT (and other) organizations.
Note that the first application of a staged maturity model to IT was not by CMM/SEI, but rather Richard L. Nolan, who, in 1973 published the Stages of growth model for IT organizations. [2]
The model identifies five levels of process maturity for an organization:
1. Initial (chaotic, ad hoc, heroic) the starting point for use of a new process.
2. Repeatable (project management, process discipline) the process is used repeatedly.
3. Defined (institutionalized) the process is defined/confirmed as a standard business process.
4. Managed (quantified) process management and measurement takes place.
5.Optimizing (process improvement) process management includes deliberate process optimization/improvement.
Within each of these maturity levels are Key Process Areas (KPAs) which characterise that level, and for each KPA there are five definitions identified:
1. Goals
2. Commitment
3. Ability
4. Measurement
5. 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.
Process assessment is best led by an appropriately skilled/competent lead assessor[neutrality disputed]. The organisation's process maturity level is assessed, and then a specific plan is developed to get to the next level. Skipping levels is not allowed.
N.B.: The CMM was originally intended as a tool to evaluate the ability of government contractors to perform a contracted software project. It may be suited for that purpose. When it became a general model for software process improvement, there were many critics.
Shrinkwrap companies are also called commercial-off-the-shelf (COTS) firms or software package firms. They include Claris, Apple, Symantec, Microsoft, and Lotus, amongst others. Many such companies rarely if ever managed their requirements documents as formally as the CMM described in order to achieve level 2, and so all of these companies would probably fall into level 1 of the model.
Origins
In the 1980s, several military projects involving software subcontractors ran over-budget and were completed much later than planned, if they were completed at all. In an effort to determine why this was occurring, the United States Air Force funded a study at the SEI. The result of this study was a model for the military to use as an objective evaluation of software subcontractors. In 1989, the Capability Maturity Model was published as Managing the Software Process. The basis for the model is the Quality Management Maturity Grid introduced by Philip Crosby in his 1979 book 'Quality is Free'.
Current state and future direction
Although the CMM model proved useful to many organizations, the use of multiple models has been problematic. Applying multiple models that are not integrated within and across an organization could be costly in terms of training, appraisals, and improvement activities. The Capability Maturity Model Integration (CMMI) project was formed to sort out the problem of using multiple CMMs.
Capability Maturity Model topics
Maturity model
A maturity model can be described as a structured collection of elements that describe certain aspects of maturity in an organization. A maturity model may provide, for example :
* a place to start
* the benefit of a community’s prior experiences
* a common language and a shared vision
* a framework for prioritizing actions
* a way to define what improvement means for your organization.
A maturity model can be used as a benchmark for comparison and as an aid to understanding - for example, for comparative assessment of different organizations where there is something in common that can be used as a basis for comparison. In the case of the CMM, for example, the basis for comparison would be the organizations' software development processes.
Capability Maturity Model structure
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 collectively, 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.
Levels of the Capability Maturity Model
There are five levels defined along the continuum of the CMM[3], 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."
Level 1 - Ad hoc (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, shifting 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.
Software process framework for SEI's Capability Maturity Model
The software process framework documented is intended to guide those wishing to assess an organization/projects consistency with the CMM. For each maturity level there are five checklist types:
* roles
* entry criteria
* inputs
* activities
* outputs
* exit criteria
* reviews and audits
* work products managed and controlled
* measurements
* documented procedures
* training
* tools
Procedure Describes the recommended content of documented procedures described in the CMM.
Level overview Provides an overview of an entire maturity level. The level overview checklists are further refined into checklists for:
* KPA purposes (Key Process Areas)
* KPA goals
* policies
* standards
* process descriptions
* procedures
* training
* tools
* reviews and audits
* work products managed and controlled
* measurements
Contents
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 and later published in its full form as a book in 1995 by Mark Paulk, Charles Weber, Bill Curtis, and Mary Beth Chrissis. Though it comes from the area of software development, it has also been applied to improving organizational 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, and human capital management. The CMM has been used extensively not only by government, but has also been widely adopted in software and application development organizations around the world, and most notably by organizations offering offshore outsourcing services.
History
The Capability Maturity Model is based on the Process Maturity Framework first described in the 1989 book "Managing the Software Process" by Watts Humphrey. Humphrey based this framework on the earlier Quality Maturity Grid developed by Philip Crosby in his book "Quality Is Free". However, Humphrey's approach differed because of his unique insight that organizations mature their processes in stages based on solving process problems in a specific order. Humphrey based his approach on the staged evolution of a system of software development practices within an organization, rather than measuring the maturity of each separate development process independently. This insight has given the staged maturity models based on Humphrey's original framework their unique power for improving organizational performance[citation needed][neutrality disputed].
Humphrey began developing his process maturity concepts during the later stages of his 27 year career at IBM. He joined the Software Engineering Institute located at Carnegie Mellon University in Pittsburgh, Pennsylvania in 1986 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. Organizations were originally assessed using a process maturity questionnaire and a Software Capability Evaluation method devised by Humphrey and his colleagues at the SEI[clarification needed]. The full representation of the Capability Maturity Model as a collection of defined process areas and practices at each of the five maturity levels was initiated 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 CMM has been superseded by the Capability Maturity Model Integration (CMMI).
Context
In the 1970s the use of computers became more widespread, flexible and less expensive. 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 infancy, 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.
Watts Humphrey's Capability Maturity Model (CMM) was described in Managing the Software Process. The CMM as conceived by Watts Humphrey was based on the work a decade earlier of Phil Crosby who published the Quality Management Maturity Grid in his book Quality is Free in 1979.[1] Active development of the model by the US Department of Defense Software Engineering Institute (SEI) began in 1986.
The CMM was originally intended as a tool to evaluate the ability of government contractors to perform a contracted software project. Though it comes from the area of software development, it can be, has been, and continues to be widely applied as a general model of the maturity of processes (e.g. IT Service Management processes) in IS/IT (and other) organizations.
Note that the first application of a staged maturity model to IT was not by CMM/SEI, but rather Richard L. Nolan, who, in 1973 published the Stages of growth model for IT organizations. [2]
The model identifies five levels of process maturity for an organization:
1. Initial (chaotic, ad hoc, heroic) the starting point for use of a new process.
2. Repeatable (project management, process discipline) the process is used repeatedly.
3. Defined (institutionalized) the process is defined/confirmed as a standard business process.
4. Managed (quantified) process management and measurement takes place.
5.Optimizing (process improvement) process management includes deliberate process optimization/improvement.
Within each of these maturity levels are Key Process Areas (KPAs) which characterise that level, and for each KPA there are five definitions identified:
1. Goals
2. Commitment
3. Ability
4. Measurement
5. 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.
Process assessment is best led by an appropriately skilled/competent lead assessor[neutrality disputed]. The organisation's process maturity level is assessed, and then a specific plan is developed to get to the next level. Skipping levels is not allowed.
N.B.: The CMM was originally intended as a tool to evaluate the ability of government contractors to perform a contracted software project. It may be suited for that purpose. When it became a general model for software process improvement, there were many critics.
Shrinkwrap companies are also called commercial-off-the-shelf (COTS) firms or software package firms. They include Claris, Apple, Symantec, Microsoft, and Lotus, amongst others. Many such companies rarely if ever managed their requirements documents as formally as the CMM described in order to achieve level 2, and so all of these companies would probably fall into level 1 of the model.
Origins
In the 1980s, several military projects involving software subcontractors ran over-budget and were completed much later than planned, if they were completed at all. In an effort to determine why this was occurring, the United States Air Force funded a study at the SEI. The result of this study was a model for the military to use as an objective evaluation of software subcontractors. In 1989, the Capability Maturity Model was published as Managing the Software Process. The basis for the model is the Quality Management Maturity Grid introduced by Philip Crosby in his 1979 book 'Quality is Free'.
Current state and future direction
Although the CMM model proved useful to many organizations, the use of multiple models has been problematic. Applying multiple models that are not integrated within and across an organization could be costly in terms of training, appraisals, and improvement activities. The Capability Maturity Model Integration (CMMI) project was formed to sort out the problem of using multiple CMMs.
Capability Maturity Model topics
Maturity model
A maturity model can be described as a structured collection of elements that describe certain aspects of maturity in an organization. A maturity model may provide, for example :
* a place to start
* the benefit of a community’s prior experiences
* a common language and a shared vision
* a framework for prioritizing actions
* a way to define what improvement means for your organization.
A maturity model can be used as a benchmark for comparison and as an aid to understanding - for example, for comparative assessment of different organizations where there is something in common that can be used as a basis for comparison. In the case of the CMM, for example, the basis for comparison would be the organizations' software development processes.
Capability Maturity Model structure
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 collectively, 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.
Levels of the Capability Maturity Model
There are five levels defined along the continuum of the CMM[3], 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."
Level 1 - Ad hoc (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, shifting 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.
Software process framework for SEI's Capability Maturity Model
The software process framework documented is intended to guide those wishing to assess an organization/projects consistency with the CMM. For each maturity level there are five checklist types:
TypeSD Description
====== ===========
Policy Describes the policy contents and KPA goals recommended by the CMM.
The process checklists are further refined into checklists for:
====== ===========
Policy Describes the policy contents and KPA goals recommended by the CMM.
Standard Describes the recommended content of select work products described in the CMM.
Process Describes the process information content recommended by the CMM.The process checklists are further refined into checklists for:
* roles
* entry criteria
* inputs
* activities
* outputs
* exit criteria
* reviews and audits
* work products managed and controlled
* measurements
* documented procedures
* training
* tools
Procedure Describes the recommended content of documented procedures described in the CMM.
Level overview Provides an overview of an entire maturity level. The level overview checklists are further refined into checklists for:
* KPA purposes (Key Process Areas)
* KPA goals
* policies
* standards
* process descriptions
* procedures
* training
* tools
* reviews and audits
* work products managed and controlled
* measurements
