| Capability Maturity Model Integration (CMMI) SE/SW/IPPD version 1.02 was published in 2000, and SE/SW/IPPD/SS version 1.1 was published in 2002. CMMI was developed into a single model for organizations pursuing enterprise-wide process improvement, based on -
Capability Maturity Model for Software (SW-CMM) version 2.0, draft C -
Electronic Industries Alliance Interim Standard (EIA/IS) 731, Systems Engineering Capability Model (SECM) -
Integrated Product Development Capability Maturity Model (IPD-CMM) version 0.98 One set of models is characterized as representations, and the representations defined are staged or continuous. The staged representation model is similar to CMM version 1.1 and will therefore not be described further in this section. The continuous representation model is SPICE compatible (see section 2.3) and is the model discussed here. Both are designed to offer essentially equivalent results, and both are in use today. Another way to look at the CMMI models is from the disciplines and environment angle. Currently the CMMI model includes two disciplines and one development environment: systems engineering (SE) and software engineering (SW) disciplines and the integrated product and process development (IPPD) environment. These are described in Table 2-2. Table 2-2. Discipline Description in CMMI | Discipline/Environment | Description | | Systems engineering | The systems engineering discipline covers the development of total systems, which may or may not include software. Systems engineers focus on transforming customer needs, expectations, and constraints into product solutions and supporting those product solutions throughout the product life cycle. | | Software engineering | The software engineering discipline covers the development of software systems. Software engineers focus on applying systematic, disciplined, and quantifiable approaches to the development, operation, and maintenance of software. | | Integrated product and process development | Integrated Product and Process Development (IPPD) is a systematic approach to product development that achieves a timely collaboration of relevant stakeholders throughout the product life cycle to better satisfy customer needs. The CMMI-SE/SW/IPPD model captures the underlying best practices exhibited by a good IPPD approach. These practices may be used in developing, improving, or appraising the implementation of IPPD. | CMMI is, like CMM version 1.0, developed and supported by the Software Engineering Institute. The material offers guidelines on how to choose between the models and how to tailor the chosen model to specific needs. CMMI Process Areas The process areas defined in CMMI are divided into four main groups: process management, project management, engineering, and support. These groups are again divided into process areas, as follows : Process Management Organizational Process Focus Organizational Process Definition Organizational Training Organizational Process Performance Organizational Innovation and Deployment Project Management Project Planning Project Monitoring and Control Supplier Agreement Management Integrated Product and Process Development (IPPD) Management Risk Management Integrated Teaming Quantitative Project Management Engineering Requirements Management Requirements Development Technical Solution Product Integration Verification Validation Support Configuration Management Process and Product Quality Assurance Measurement and Analysis Decision Analysis and Resolution Organizational Environment for Integration Causal Analysis and Resolution Configuration management is, as can be seen, a process area under Support. Definition CMMI-SE/SW/IPPD/SS version 1.1 defines configuration management as follows: The purpose of Configuration Management is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits . Goals The goals for configuration management as defined in CMMI are SG 1 Establish Baselines. Baselines of identified work products are established and maintained . SG 2 Track and Control Changes. Changes to the work products under configuration management are tracked and controlled. SG 3 Establish Integrity. Integrity of baselines is established and maintained. The S in the identification of the goal means that the goal is specific to configuration managementas opposed to generic, or similar across process areas. Practice-to-Goal Relationships In CMMI, a number of practices are defined for each goal. The practices for the configuration management goals are SG 1 Establish Baselines SP 1.1-1 Identify Configuration Items SP 1.2-1 Establish a Configuration Management System SP 1.3-1 Create or Release Baselines SG 2 Track and Control Changes SP 2.1-1 Track Changes SP 2.2-1 Control Changes SG 3 Establish Integrity SP 3.1-1 Establish Configuration Management Records SP 3.2-1 Perform Configuration Audits Capability and Maturity Levels Continuous representation uses capability levels, while staged representation uses maturity levels. The main difference between these two types of levels is the representation to which they belong and how they are applied: -
Capability levels apply to an organization's processimprovement achievement for each process area. There are six capability levels, numbered 0 through 5. Each capability level corresponds to a generic goal and a defined set of generic practices. -
Maturity levels, which belong to a staged representation, apply to an organization's overall process capability and organizational maturity. Each maturity level consists of a predefined set of process areas and generic goals. There are five maturity levels, numbered 1 through 5. Table 2-3 shows the definitions of capability and maturity levels in CMMI. Table 2-3. Definition of Capability and Maturity Levels in CMMI | Level | Continuous Representation Capability Levels | Staged Representation Maturity Levels | | | Incomplete | N/A | | 1 | Performed | Initial | | 2 | Managed | Managed | | 3 | Defined | Defined | | 4 | Quantitatively managed | Quantitatively managed | | 5 | Optimizing | Optimizing | Achieving Capability Levels As is the case for specific goals for a given process area, CMMI defines generic goals for each capability level within a process area. The generic goals are the same, no matter what process area you're trying to improve. The goals for the capability levels 1 to 5 are GG 1 Achieve Specific Goals. The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products. GG 2 Institutionalize a Managed Process. The process is institutionalized as a managed process. GG 3 Institutionalize a Defined Process. The process is institutionalized as a defined process. GG 4 Institutionalize a Quantitatively Managed Process. The process is institutionalized as a quantitatively managed process. GG 5 Institutionalize an Optimizing Process. The process is institutionalized as an optimizing process. Capability levels are determined by reviewing the organization's implementation of the specific and generic practices and its achievement of the associated goals through that capability level. For example, to achieve capability level 2 for a process area, the organization's activities are reviewed against the specific and generic practices and goals through capability level 2. Level 2 for All Process Areas Also for the generic goals, CMMI defines a number of generic practices for each goal. The generic practices for the capability level 2 goals are GG 2 Institutionalize a Managed Process GP 2.1 Establish an Organizational Policy GP 2.2 Plan the Process GP 2.3 Provide Resources GP 2.4 Assign Responsibility GP 2.5 Train People GP 2.6 Manage Configurations GP 2.7 Identify and Involve Relevant Stakeholders GP 2.8 Monitor and Control the Process GP 2.9 Objectively Evaluate Adherence GP 2.10 Review Status with HigherLevel Management Here, configuration management is practice number 6, so it must be performed for any process area in order for the process area to reach capability level 2. The definition of configuration management as a discipline is as stated above: the integrity of the work products for each processas identified in the plan for performing the processmust be established and maintained throughout the products' useful life. CMMI further states, different levels of configuration management are appropriate for different work products and for different points in time. For some work products, it may be sufficient to maintain version control (i.e., the version of the work product in use at a given time, past or present, is known and changes are incorporated in a controlled manner). Sometimes, it may be critical that work products be placed under formal or "baseline" configuration management. This type of configuration management includes defining and establishing baselines at predetermined points. These baselines are formally reviewed and agreed on, and serve as the basis for further development. Additional levels of configuration management between version control and formal configuration management are possible. An identified work product may be under various levels of configuration management at different points in time. Raising the Capability of the Configuration Management Process In the continuous representations of CMMI, each process area may be performed at a given capability level, and therefore also configuration management. The characteristics of each capability level are described below, from the point of view of configuration management. To reach capability level 1, the configuration management process is expected to fulfill all the goals for configuration management. Performance may not be stable and may not meet specific objectives such as quality, cost, and schedule, but useful work can be done. At capability level 2, configuration management is a managed process. A managed process is planned, performed, monitored , and controlled for individual projects, groups, or standalone processes, to achieve a given purpose. Management is concerned with achievement of both the model objectives for the process as well as other objectives, such as cost, schedule, and quality. At capability level 3, configuration management is a defined process. This is a managed process tailored from the organization's set of standard processes. Deviations beyond those allowed by the tailoring guidelines are documented, justified, reviewed, and approved. At capability level 4, configuration management is a quantitatively managed process. This is a defined process that is controlled using statistical and other quantitative techniques. Product quality, service quality, process performance, and other business objectives are understood in statistical terms and are controlled throughout the life cycle. At capability level 5, configuration management is an optimizing process. This is a quantitatively managed process that is improved based on an understanding of the common causes of process variation inherent in the process. An optimizing process focuses on continually improving process performance through both incremental and innovative improvements. Table 2-4. Mapping from CMMI Activities | CMMI Practice | Mapping to This Book | | SP 1.11: Identify configuration items | Chapter 1Identification | | SP 1.21: Establish a configuration management system | Chapter 5Scoping the Configuration Management Task Part VImproving Configuration Management | | SP 1.31: Create or release baselines | Chapter 1Storage Chapter 1Change Control Chapter 6Deliveries for Planned Events Like Milestones | | SP 2.11: Track changes | Chapter 1Change Control Chapter 8Event Registration Chapter 8Change Request | | SP 2.21: Control changes | Chapter 1Change Control | | SP 3.11: Establish configuration management records | Chapter 8What One Must Register for a Configuration Item Chapter 1Status Reporting | | SP 3.21: Perform configuration audits | Not handledsee Chapter 1, Auditing |  | 