3 Operational Definition of the Capability Maturity Model
The CMM is a framework representing a path of improvements recommended for software organizations that want to increase their software process capability. This operational elaboration of the CMM is designed to support the many ways it will be used. There are at least four uses of the CMM that are supported:
Because of the diverse uses of the CMM, it must be decomposed in sufficient detail that actual process recommendations can be derived from the structure of the maturity levels. This decomposition also indicates the processes and their structure that characterizes software process maturity and software process capability.
3.1 Internal Structure of the Maturity Levels
Each maturity level has been decomposed into constituent parts. With the exception of Level 1, the decomposition of each maturity level ranges from abstract summaries of each level down to their operational definition in the key practices, as shown in Figure 3.1. Each maturity level is composed of several key process areas. Each key process area is organized into five sections called common features. The common features specify the key practices that, when collectively addressed, accomplish the goals of the key process area.
Figure 3.1 The CMM Structure
A maturity level is a well-defined evolutionary plateau toward achieving a mature software process. Each maturity level indicates a level of process capability, as was illustrated in Figure 2.1. For instance, at Level 2 the process capability of an organization has been elevated from ad hoc to disciplined by establishing sound project management controls.
Except for Level 1, each maturity level is decomposed into several key process areas that indicate the areas an organization should focus on to improve its software process. Key process areas identify the issues that must be addressed to achieve a maturity level.
Each key process area identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important for enhancing process capability. The key process areas have been defined to reside at a single maturity level as shown in Figure 3.2. The path to achieving the goals of a key process area may differ across projects based on differences in application domains or environments. Nevertheless, all the goals of a key process area must be achieved for the organization to satisfy that key process area. When the goals of a key process area are accomplished on a continuing basis across projects, the organization can be said to have institutionalized the process capability characterized by the key process area.
Figure 3.2 The Key Process Areas by Maturity Level
The adjective "key" implies that there are process areas (and processes) that are not key to achieving a maturity level. The CMM does not describe all the process areas in detail that are involved with developing and maintaining software. Certain process areas have been identified as key determiners of process capability; these are the ones described in the CMM.
Although other issues affect process performance, the key process areas were identified because of their effectiveness in improving an organization's software process capability. They may be considered the requirements for achieving a maturity level. Figure 3.2 displays the key process areas for each maturity level. To achieve a maturity level, the key process areas for that level must be satisfied. To satisfy a key process area, each of the goals for the key process area must be satisfied. The goals summarize the key practices of a key process area and can be used to determine whether an organization or project has effectively implemented the key process area. The goals signify the scope, boundaries, and intent of each key process area. [ Begin Footnote ] --- For a listing of the goals for each key process area, refer to Appendix A. --- [ End Footnote ]
The specific practices to be executed in each key process area will evolve as the organization achieves higher levels of process maturity. For instance, many of the project estimating capabilities described in the Software Project Planning key process area at Level 2 must evolve to handle the additional project data available at Levels 3, 4, and 5. Integrated Software Management at Level 3 is the evolution of Software Project Planning and Software Project Tracking and Oversight at Level 2 as the project is managed using a defined software process.
The key process areas of the CMM represent one way of describing how organizations mature. These key process areas were defined based on many years of experience in software engineering and management and over five years of experience with software process assessments and software capability evaluations.
The key process areas at Level 2 focus on the software project's concerns related to establishing basic project management controls. Descriptions of each of the key process areas for Level 2 are given below:
The key process areas at Level 3 address both project and organizational issues, as the organization establishes an infrastructure that institutionalizes effective software engineering and management processes across all projects. Descriptions of each of the key process areas for Level 3 are given below:
The key process areas at Level 4 focus on establishing a quantitative understanding of both the software process and the software work products being built. The two key process areas at this level, Quantitative Process Management and Software Quality Management, are highly interdependent, as is described below:
For convenience, the key process areas are organized by common features. The common features are attributes that indicate whether the implementation and institutionalization of a key process area is effective, repeatable, and lasting. The five common features are listed below:
Commitment to Perform
Commitment to Perform describes the actions the organization must take to ensure that the process is established and will endure. Commitment to Perform typically involves establishing organizational policies and senior management sponsorship.
Ability to Perform
Ability to Perform describes the preconditions that must exist in the project or organization to implement the software process competently. Ability to Perform typically involves resources, organizational structures, and training.
Activities Performed
Activities Performed describes the roles and procedures necessary to implement a key process area. Activities Performed typically involve establishing plans and procedures, performing the work, tracking it, and taking corrective actions as necessary.
Measurement and Analysis
Measurement and Analysis describes the need to measure the process and analyze the measurements. Measurement and Analysis typically includes examples of the measurements that could be taken to determine the status and effectiveness of the Activities Performed.
Verifying Implementation
Verifying Implementation describes the steps to ensure that the activities are performed in compliance with the process that has been established. Verification typically encompasses reviews and audits by management and software quality assurance.
The practices in the common feature Activities Performed describe what must be implemented to establish a process capability. The other practices, taken as a whole, form the basis by which an organization can institutionalize the practices described in the Activities Performed common feature.
Each key process area is described in terms of the key practices that contribute to satisfying its goals. The key practices describe the infrastructure and activities that contribute most to the effective implementation and institutionalization of the key process area.
Each key practice consists of a single sentence, often followed by a more detailed description, which may include examples and elaboration. These key practices, also referred to as the top-level key practices, state the fundamental policies, procedures, and activities for the key process area. The components of the detailed description are frequently referred to as subpractices. Figure 3.3 provides an example of the structure underlying a key practice for the Software Project Planning key process area.
Figure 3.3 Building the CMM Structure: An Example of a Key Practice
As illustrated in Figure 3.3, to ensure consistent accomplishment of the goal of documenting plans for planning and tracking the project, the organization must establish a documented procedure for deriving estimates of software size. If these estimates are not developed from a documented procedure, they may vary wildly as differences in sizing assumptions are never surfaced. The detailed description of what would be expected in such a procedure includes using historical size data, documenting assumptions, and reviewing the estimates. These criteria guide the judgment of whether a reasonable size estimating procedure is followed.
The key practices describe "what" is to be done, but they should not be interpreted as mandating "how" the goals should be achieved. Alternative practices may accomplish the goals of the key process area. The key practices should be interpreted rationally to judge whether the goals of the key process area are effectively, although perhaps differently, achieved. The key practices are contained in the "Key Practices of the Capability Maturity Model, Version 1.1" [Paulk93b], along with guidance on their interpretation.