CMMi for Development

An explanation of what CMMi for Development is and how the official CMMi-DEV document is structured.

Article Purpose

The purpose of this article is to provide a basic overview of CMMi for Software Development, in the form of a definition of CMMi and an explanation of how the official CMMi-DEV Version 1.2 documentation is organized.

CMMi® stands for Capability Maturity Model® Integration and it is a process improvement maturity model that has been developed by the Software Engineering Institute, SEI, at Carnegie Mellon. It is important to note that CMMi defines what processes and activities need to be done and not how these processes and activities are done. The goal of CMMi is process improvement and CMMi can be thought of as a Software Process Improvement, SPI, framework.

This article explains the CMMi for Development CMMi-DEV. CMMi® for Development, Version 1.2, contains 573 pages and is organized around 22 process areas that represent the core processes for software development.

The 22 process areas of CMMi for Development are:-

CMMI® for Development, Version 1.2 (CMMI-DEV, V1.2)
Causal Analysis and Resolution (CAR) Configuration Management (CM) Decision Analysis and Resolution (DAR) Integrated Project Management +IPPD (IPM+IPPD)
Measurement and Analysis (MA) Organizational Innovation and Deployment (OID) Organizational Process Definition +IPPD (OPD+IPPD) Organizational Process Focus (OPF)
Organizational Process Performance (OPP) Organizational Training (OT) Product Integration (PI) Project Monitoring and Control (PMC)
Project Planning (PP) Process and Product Quality Assurance (PPQA) Quantitative Project Management (QPM) Requirements Development (RD)
Requirements Management (REQM) Risk Management (RSKM) Supplier Agreement Management (SAM) Technical Solution (TS)
Validation (VAL) Verification (VER) . .

For each process area a list of practices (or capabilities) is given. The idea being that a software development organization improves their capability by implementing the practices documented. There are a number of levels of capability which are achieved by applying more definition and control to the key development processes. The level of capability (of a given software development organization) can be assessed by an independent auditor, usually external.

By way of example the practices (which are grouped by goals) for the Requirements Management (REQM) process area are:-

Specific Goal 1 (SG 1) Manage Requirements.
  • Specific practice 1.1 (SP 1.1) Obtain an Understanding of Requirements.
  • Specific practice 1.2 (SP 1.2) Obtain Commitment to Requirements.
  • Specific practice 1.3 (SP 1.3) Manage Requirements Changes.
  • Specific practice 1.4 (SP 1.4) Maintain Bidirectional Traceability of Requirements.
  • Specific practice 1.5 (SP 1.5) Identify Inconsistencies Between Project Work and Requirements.
Note that the practices only define what is needed to be done and not how, for example SP 1.4 Maintain Bidirectional Traceability of Requirements, can be achieved using a Traceability Matrix but only the goal and practices are stated. SP 1.4 could also be achieved using a database of cross references or some other mechanism, the intent of CMMi is to describe what capabilities a software development process should have and not prescribe how those capabilities are achieved. This gives organizations the flexibility to implement an appropriate solution to achieve the capabilities in their unique environments.

For any level of process capability, beyond the basic incomplete or initial (discussed later), all of the specific practices have to be implemented. In addition to the Specific Practices (SP), as illustrated above, there are Generic Practices (GP). It is the generic practices that determine what capability level an organization has reached, with respect to a given process.

Extending the Manage Requirements process area, to include the generic practices, we would include the following (arranged by goal, or in this case generic goal (GG)):-
Generic Goal 1 (GG 1) Achieve Specific Goals.
  • Generic Practice 1.1 (GP 1.1) Perform Specific Practices.
Generic Goal 2 (GG 2) Institutionalize a Managed Process.
  • Generic Practice 2.1 (GP 2.1) Establish an Organizational Policy.
  • Generic Practice 2.2 (GP 2.2) Plan the Process.
  • Generic Practice 2.3 (GP 2.3) Provide Resources.
  • Generic Practice 2.4 (GP 2.4) Assign Responsibility.
  • Generic Practice 2.5 (GP 2.5) Train People.
  • Generic Practice 2.6 (GP 2.6) Manage Configurations.
  • Generic Practice 2.7 (GP 2.7) Identify and Involve Relevant Stakeholders.
  • Generic Practice 2.8 (GP 2.8) Monitor and Control the Process.
  • Generic Practice 2.9 (GP 2.9) Objectively Evaluate Adherence.
  • Generic Practice 2.10 (GP 2.10) Review Status with Higher Level Management.
Generic Goal 3 (GG 3) Institutionalize a Defined Process.
  • Generic Practice 3.1 (GP 3.1) Establish a Defined Process.
  • Generic Practice 3.2 (GP 3.2) Collect Improvement Information.
Generic Goal 4 (GG 4) Institutionalize a Quantitatively Managed Process.
  • Generic Practice 4.1 (GP 4.1) Establish Quantitative Objectives for the Process.
  • Generic Practice 4.2 (GP 4.2) Stabilize Sub process Performance.
Generic Goal 5 (GG 5) Institutionalize an Optimizing Process.
  • Generic Practice 5.1 (GP 5.1) Ensure Continuous Process Improvement.
  • Generic Practice 5.2 (GP 5.2) Correct Root Causes of Problems.
A clear pattern can be seen, with reference to the Manage Requirements process area, across all the 22 process areas of CMMi. That is each process area has specific goals with practices that must be implemented. When the specific practices are implement then the first generic goal is achieved, the first generic goal in all the process areas is perform specific practices. This will get the organization to a level 2 capability. Then to gain higher capability levels the organization needs to apply the generic practices which will bring the process under increasing control, moving from capability 0, incomplete, thru to capability 5, optimizing.

The following table maps the capability level with the generic practices that have been implemented.

Capability level Practices implemented
0 - Incomplete The specific practices are not fully implemented.
1 - Performed The specific practices for a given process area have been implemented, that is generic goal 1 has been achieved.
2 - Managed Generic goal 2 (GG 2) Institutionalize a Managed Process, is implemented. Note the levels are incremental, that is they build on each other so level 2 implies level 1 and level 2.
3 - Defined Generic goal 3 (GG 3) Institutionalize a Defined Process, is implemented.
4 - Quantitatively Managed Generic goal 4 (GG 4) Institutionalize a Quantitatively Managed process, is implemented.
5 - Optimizing Generic goal 5 (GG 5) Institutionalize an Optimizing process, is implemented.

The above capability mapping for all 22 processes is the same as the example Requirements Management process area. The specific goals and practices will be unique to the process area whilst the generic goals and practices will be similar, hence the terms specific and generic.

One major complication for the reader of CMMi-DEV is that there are 2 maturity (or capability) hierarchies. This is because there are 2 separate implementation paths for CMMi. The first path is known as continuous and is described above. The second implementation path is known as staged and refers to an implementation path under which the order of which process areas are subjected to process improvement is important. The staged implementation path prescribes a set of process areas that need to be implemented for each capability level. Also the staged implementation has maturity levels in place of capability levels.

The same principles, as for the continuous implementation method described above, apply to a staged implementation. In all cases the specific practices need to be implemented then the maturity level increases as the generic goals and practices are implemented. The process area definitions as well as the specific goals are the same for both staged and continuous implementation paths.

For more information on the staged implementation method, as well as a detailed description of CMM-DEV, see the official CMMI-DEV V1.2 documentation.

I have also written an article about SCAMPI, Standard CMMI Appraisal Method for Process Improvement for a further explanation on the CMMi appraisal process.

If anyone is interested in using CMMi-DEV as the basis for establishing a comprehensive software process improvement framework, without the goal of being formally audited, then a good place to start is to select the process areas that are the most problematic within your organization and then implement the specific practices for those process areas. Following that other processes should be implemented, as per the specific practices, and then the generic goals should be incrementally pursued, as per the continuous implementation methodology.

No guarantee (or claim) is made regarding the accuracy of this information. Any questions or comments should be sent to:-