Other sections in this blog refer to the SEI CMM, particularly with regard to the way that model supports the blog topic - life cycles, peer reviews, metrics, etc. The CMM is divided into five maturity levels. They are well-defined evolutionary plateaus aimed toward achieving a mature software process. The maturity levels each indicate a level of process capability and those capabilities are decomposed into several key process areas. The levels can be thought of as layers in the foundation for continuous process improvement. These layers comprise sets of process goals that, when satisfied, stabilize an important component of the software process. As these levels of the maturity framework are reached, different components in the software process are more effectively used, resulting in an increase in the process capability of the organization. Organizations cannot skip levels. All key process areas (KPAs) from a lower level must be satisfied before progressing to a higher level. A KPA is a specific process area on which the organization must focus to move to the next maturity level. They are explained for each CMM level in the following paragraphs.

The five maturity levels are shown in Figure 1 with their key process areas. Level 1, "Initial," has no KPAs. All organizations start out at a Level 1 when first evaluated. A Level 1 organization typically has no stable environment for developing and maintaining software. During a crisis, projects typically abandon planned procedures and revert to coding and testing. Success depends entirely on having an exceptional manager and a seasoned and effective software team. The software process is constantly changed as the work progresses. Schedules, budgets, functionality, and product quality are generally unpredictable. Performance can be predicted only by individual rather than organizational capability.

SEI CMM Key Process Areas by Maturity Level

Level 2, "Repeatable," has these KPAs:

1. Requirements management
2. Software project planning
3. Software project tracking and oversight
4. Software subcontract management
5. Software configuration management
6. Software quality assurance

At Level 2, the process of building software as a series of black boxes with defined checkpoints (milestones) is in place. As shown in Figure 2, requirements come into the process and flow through a series of process black boxes. Outputs result from each box, and milestones and checkpoints are used to monitor the progress of the product through the process. Policies, standards, and procedures are followed. Planning, estimating, and managing new projects are based on experience with similar projects. This experience is quantified in a rudimentary project metrics system. Projects are controlled through formal project management practices. Software costs, schedules, and functionality are tracked. Software requirements and work products are baselined, and their integrity is controlled through a configuration management system. Projects have a strong customer-supplier relationship and the software process capability is disciplined.

Level 2 Process

At Level 3, "Defined," the standard process for developing and maintaining software across the organization is documented and consistently used (see Figure 3). Projects tailor the organization's standard software process to develop their own defined software process. Software engineering and management processes are integrated into a coherent whole. An organization-wide training program is implemented. The software process capability is standard and a group is responsible for the organization's software process activities. These are the KPAs for Level 3:

1. Organization process focus
2. Organization process definition
3. Software product engineering
4. Integrated software management
5. Intergroup coordination
6. Peer reviews
7. Training program

Level 3 Process

At Level 3, software development is done according to a well-defined process. Roles and responsibilities in the process are understood. The production of the software product is visible throughout the software process.

Level 4 (see Figure 4) is the "Managed" level with two KPAs: quantitative process management and software quality management. Detailed measures of the software process and product quality are collected through an extensive metrics system. Both the software process and products are quantitatively understood and controlled. Management has an objective basis for making decisions and is able to predict performance within quantified bounds.

Level 4 Process

Level 5, "Optimizing," focuses on the KPAs of (a) technology change management, (b) process change management, and (c) defect prevention. Continuous process improvement is enabled by quantitative feedback from the process. At this level, the organization is able to test innovative ideas and technologies to improve product quality. See Figure 19-9.

Level 5 Process

Disciplined change to the existing process becomes an organizational approach to continuous process improvement. Institutionalizing this change is critical because:

1. The organization outlives those who leave it.
2. The organization culture must convey the process.
3. Management must nurture the culture.
4. Culture is conveyed with role models and rewards.

In summary, the CMM is a road map to success in process improvement. It should be interpreted and used with a view toward business objectives. Today, the CMM is the most widely accepted method (by a broad cross-section of business domains and countries) for process improvement in a software development organization. It is normative, not prescriptive, and is a living model, developed and maintained by a broad base of the software community.

The SWEBOK may be mapped to the SEI CMM key process areas, as shown in Tables 1 and 2.

Map of CMM Levels to SWEBOK Knowledge Areas Part 1 of 2

Map of CMM Levels to SWEBOK Knowledge Areas Part 2 of 2


software process, life cycle, maturity level, key process area
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2018 SPMInfoBlog.
Designed by TechPlus