Topic: The Capability Maturity Model for Software

The Capability Maturity Model for Software [Paulk93a, Paulk93b] describes the principles and practices underlying software process maturity and is intended to help software organizations improve the maturity of their software processes in terms of an evolutionary path from ad hoc, chaotic processes to mature, disciplined software processes. The CMM is organized into five maturity levels. A maturity level is a well-defined evolutionary plateau toward achieving a mature software process. Each maturity level provides a layer in the foundation for continuous process improvement.

The Five Maturity Levels

The following characterizations of the five maturity levels highlight the primary process changes made at each level:

 

1) Initial The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort and heroics.

2) Repeatable Basic project management processes are established to track

cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.

3) Defined The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software.

4) Managed Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled.

5) Optimizing Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.

Key Process Areas:

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 and their purposes are listed below. The name of each key process area is followed by its two-letter abbreviation.

By definition there are no key process areas for level 1.

The key process areas at level 2 focus on the software project's concerns related to establishing basic project management controls, as summarized below:
Requirements Management (RM)

Establish a common understanding between the customer and the software project of the customer's requirements that will be addressed by the software project.

Software Project Planning (PP)

Establish reasonable plans for performing the software engineering and for managing the software project.

Software Project Tracking and Oversight (PT)

Establish adequate visibility into actual progress so that management can take effective actions when the software project's performance deviates significantly from the software plans.

Software Subcontract Management (SM)

Select qualified software subcontractors and manage them effectively.

Software QualityAssurance (QA)

Provide management with appropriate visibility into the process being used by the software project and of the products being built.

Software Configuration Management (CM)

Establish and maintain the integrity of the products of the software project throughout the project's software life cycle.

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, as summarized below:

Organization Process Focus (PF)

Establish the organizational responsibility for software process activities that improve the organization's overall software process capability. CMU/SEI-94-TR-12 5

Organization Process Definition (PD)

Develop and maintain a usable set of software process assets that improve process performance across the projects and provide a basis for cumulative, long-term benefits to the organization.

Training Program (TP)

Develop the skills and knowledge of individuals so they can perform their roles effectively and efficiently.

Integrated Software Management (IM)

Integrate the software engineering and management activities into a coherent, defined software process that is tailored from the organization's standard software process and related process assets.

Software Product Engineering (PE)

Consistently perform a well-defined engineering process that integrates all the software engineering activities to produce correct, consistent software products effectively and efficiently.

Intergroup Coordination (IC)

Establish a means for the software engineering group to participate actively with the other engineering groups so the project is better able to satisfy the customer's needs effectively and efficiently.

Peer Reviews (PR) Remove defects from the software work products early and
efficiently. An important corollary effect is to develop a better understanding of the software work products and of the defects that can be prevented.

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, as summarized below:

Quantitative Process Management (QP)

Control the process performance of the software project quantitatively.

Software Quality Management (QM)

Develop a quantitative understanding of the quality of the project's software  products and achieve specific quality goals.


The key process areas at level 5 cover the issues that both the organization and the projects must address to implement continuous and measurable software process improvement, as summarized below:

Defect Prevention (DP)

Identify the causes of defects and prevent them from recurring.

Technology Change Management (TM)

Identify beneficial new technologies (i.e., tools, methods, and processes) and transfer them into the organization in an orderly manner.

Process Change Management (PC)

Continually improve the software processes used in the organization with the intent of improving software quality, increasing productivity, and decreasing the cycle time for product development.

Common Features:

For convenience, each of the key process areas is 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, followed by their two-letter abbreviations, are listed below:

Commitment to Perform (CO)

Describes the actions the organization must take to ensure that the process is established and will endure. Includes practices on policy and leadership.

Ability to Perform (AB)

Describes the preconditions that must exist in the project or organization to implement the software process competently. Includes practices on resources,
organizational structure, training, and tools.

Activities Performed (AC)

Describes the roles and procedures necessary to implement a key process area. Includes practices on plans, procedures, work performed, tracking, and corrective
action.

Measurement and Analysis (ME)

Describes the need to measure the process and analyze the measurements. Includes examples of measurements.

Verifying Implementation (VE)

Describes the steps to ensure that the activities are performed in compliance with the process that has been established. Includes practices on management reviews
and audits.