All that is gold does not glitter, Not all who wander are lost. | ||
| --J. R. R. Tolkien, The Fellowship of the Ring (1954) | ||
I have gathered a posie of other men’s flowers, and nothing but the thread that binds them is mine own. | ||
| --John Bartlett, Preface to Familiar Quotations (1901) | ||
What’s in a Capability Maturity Model Integration (CMMI) model, and how can your organization use it? At several hundred pages in length, the CMMI models seem formidable to even the most experienced process improvement champion. With just a little understanding of how the models are put together and what kind of material is presented, however, you can begin to navigate the depths of CMMI with confidence. This chapter describes the types of information you can find in the CMMI models and notes the location where you can find it. You will also learn to interpret the importance of the various types of information.
Constellations provide a way for the CMMI to be used, with as much commonality as possible, for different types of organizations.[1] The two constellations in CMMI version 1.2 are Development and Acquisition; material for a possible third constellation for Services is being created. The Development constellation supports organizations that develop products and is the successor to all of the previous versions of CMMI. The Acquisition constellation supports an organization in procuring products or services from suppliers outside of the organization. The Services constellation is intended to support organizations that primarily deliver services rather than products. The CMMI Framework provides the information necessary to produce the different models. Here we introduce the architecture and use of the CMMI Framework.[2]
Constellations are actually a part of the CMMI Framework: A collection of components used to construct CMMI models, CMMI training materials, and CMMI appraisal methods. A key part of the CMMI Framework is the CMMI Model Foundation (CMF), which consists of material common to every existing and future CMMI model. The model components include process areas, goals, practices, and informative material about the use of the model. The model components are described in the following sections of this chapter, and the CMF is described more fully in Chapter 7.
The fundamental organizational feature of all the CMMI models is the “process area.” Not everything related to processes and process improvement is included in a process improvement model. Like its predecessor models, CMMI selects only the most important topics for process improvement and then groups those topics into “areas.” The number of process areas varies with each constellation.
We will discuss the CMMI process areas in detail in Chapter 7. For now, to introduce the concept of a process area, let’s look at one and see what it covers. For our example, we’ll use Requirements Management.
Within systems, software, and hardware engineering, it is widely believed that the management of the product requirements is a central area of concern during any development effort. Experience has demonstrated that failure to adequately identify the requirements and manage changes to them is a major cause of projects not meeting their cost, schedule, or quality objectives. This experience justifies collecting information related to the management of requirements into a major model component—that is, a process area. Users of the model should, therefore, focus on this process area to establish capability relating to the management of requirements.
As stated in the model, the purpose of the Requirements Management process area is “to manage the requirements of the project’s products and product components and to identify inconsistencies between those requirements and the project’s plans and work products.” In addition to this purpose, the process area has goals that describe the results of a successful requirements management process and practices that can help achieve these goals. A great deal of explanatory and “how to” material is also supplied to provide some concrete help with managing requirements. That’s pretty much a process area in a nutshell.
Any process improvement model must, of necessity, indicate the importance and role of the materials contained in the model. In the CMMI models, a distinction is drawn between the terms “required,” “expected,” and “informative.” The most important material is required; these items are essential to the model and to an understanding of what is needed for process improvement and demonstrations of conformance to the model. Second in importance is the expected material; these items may not be essential, and in some instances they may not be present in an organization that successfully uses the model. Nevertheless, expected material is presumed to play a central role in process improvement; such items are a strong indicator that the required components are being achieved. Third in importance (and largest in quantity) is informative material; these items constitute the majority of the model. The informative material provides useful guidance for process improvement, and in many instances it may offer clarification regarding the intended meaning of the required and expected components.
If you are seeking only a quick overview of a CMMI model, one recommended approach is to review all of the required material. This strategy may be thought of as an “executive overview” level. For a medium-level review, you could focus on the combined required and expected materials. This approach may be considered a “manager overview” level. With either type of review, the best place to look is in the model summary in Appendix A of this book. Here the first two categories of model components are joined (with a very minimal amount of informative material) to present only the most essential elements of the model.
The sole required component of the CMMI models is the “goal.” A goal represents a desirable end state, the achievement of which indicates that a certain degree of project and process control has been achieved. When a goal is unique to a single process area, it is called a “specific goal.” In contrast, when a goal may apply across all of the process areas, it is called a “generic goal.” Table 4-1 lists four examples of specific goals. Each process area has between one and four specific goals; the entire CMMI for Development version 1.2 model includes a total of 50 specific goals.
Table 4-1. Specific Goals for Four Process Areas
Process Area | Specific Goal |
|---|---|
Requirements Management | REQM SG 1: Requirements are managed and inconsistencies with project plans and work products are identified. |
Project Monitoring and Control | PMC SG 2: Corrective actions are managed to closure when the project’s performance or results deviate significantly from the plan. |
Organizational Process Performance | OPP SG 1: Baselines and models that characterize the expected process performance of the organization’s set of standard processes are established and maintained. |
Causal Analysis and Resolution | CAR SG 2: Root causes of defects and other problems are systematically addressed to prevent their future occurrence. |
As is evident from the four examples in Table 4-1, a goal statement is fairly succinct. Reviewing the expected and informative materials in the process area can help you to understand the specific goal in practical terms.
In contrast to a specific goal, a generic goal has a scope that crosses all of the process areas. Because their application is so broad, the wording of generic goals is more abstract than the wording of specific goals. Consider, for example, GG 2: “The process is institutionalized as a managed process.” To better understand what this statement means, let’s start with the CMMI Glossary (CMMI for Development version 1.2, Appendix D). There we find the definition of “institutionalization” and “managed process.” Both definitions are provided in Table 4-2.
Table 4-2. Definitions Related to CMMI Generic Goal 2
CMMI Glossary Term | CMMI Definition |
|---|---|
Institutionalization | The ingrained way of doing business that an organization follows routinely as part of its corporate culture. |
Managed process | A “managed process” is a performed process that is planned and executed in accordance with policy; employs skilled people having adequate resources to produce controlled outputs; involves relevant stakeholders; is monitored, controlled, and reviewed; and is evaluated for adherence to its process description. |
Taken together, these two definitions provide much more detail than the short statement of the generic goal itself. Nevertheless, even with these definitions, questions about practical meaning may linger. What are the key features of the “ingrained way of doing business”? How is a process “evaluated for adherence to process description”?
Although the goal is the only required component in a CMMI model, no statement of any goal—specific or generic—can be fully understood without exploring more of the model. The first expansion of that understanding comes by looking at the expected components.
The sole expected component of the CMMI models is a “practice.” A set of practices represent the “expected” means of achieving a goal. Every practice in the CMMI model is mapped to exactly one goal. A practice is not a required component, however; an organization may achieve a goal in a way that does not rely on the performance of all the practices that are mapped to that goal. That is, “alternative” practices may provide an equally useful way of reaching the goal. It may help to think of the practices as critical success factors; if you aren’t addressing them, understanding their absence is important.
When a practice is unique to a single process area, it is called a “specific practice.” When a practice may apply across all of the process areas, it is called a “generic practice.”
Table 4-3 details several examples of specific practices, together with the specific goals to which they are mapped. Note that a goal, which represents an end state, is always written in the passive voice, whereas a practice, as a means to achieve the goal, is always written in the active voice.
Table 4-3. Specific Practices Associated with Specific Goals
Specific Goal | Specific Practice |
|---|---|
REQM SG 1: Requirements are managed and inconsistencies with project plans and work products are identified. | REQM SP 1.1: Develop an understanding with the requirements providers on the meaning of the requirements. |
PMC SG 2: Corrective actions are managed to closure when the project’s performance or results deviate significantly from the plan. | PMC SP 2.1: Collect and analyze the issues and determine the corrective actions necessary to address the issues. |
OPP SG 1: Baselines and models that characterize the expected process performance of the organization’s set of standard processes are established and maintained. | OPP SP 1.2: Establish and maintain definitions of the measures that are to be included in the organization’s process performance analyses. |
CAR SG 2: Root causes of defects and other problems are systematically addressed to prevent their future occurrence. | CAR SP 2.2: Evaluate the effect of changes on process performance. |
Between two and seven specific practices are mapped to each specific goal; the entire CMMI for Development version 1.2 model includes a total of 173 specific practices, which are mapped to the 50 specific goals.
When the specific practices mapped to a specific goal are taken as a unit, they provide additional insight into how the goal should be understood. Table 4-4 shows one specific goal with its full complement of specific practices. In this example, establishing and maintaining work-product baselines involves identifying configuration items, implementing a configuration and change management system, and establishing baselines for both internal and external use.
Table 4-4. Specific Goal and Specific Practices for Configuration Management
Specific Goal | Specific Practices |
|---|---|
Configuration Management (CM) SG 1: Baselines of identified work products are established. | CM SP 1.1: Identify the configuration items, components, and related work products that will be placed under configuration management. |
CM SP 1.2: Establish and maintain a configuration management and change management system for controlling work products. | |
CM SP 1.3: Create or release baselines for internal use and for delivery to the customer. |
In contrast to a specific practice, a generic practice has a scope that crosses all of the process areas. For example, one generic practice that is mapped to the generic goal to institutionalize a managed process (GG 2) addresses the training of people. Consider GP 2.5: “Train the people performing or supporting the process as needed.” In other words, a project is expected to provide the training that is needed when it follows a managed process in such a way that the process becomes institutionalized. For each process area in a CMMI model, needed training is expected based on the application of this generic practice.
CMMI models may contain as many as 10 types of informative components, taken from the following list.[3]
Purpose. Each process area begins with a brief statement of purpose for the process area. Generally, a purpose statement consists of one or two sentences that summarize or draw together the specific goals of the process area. Consider the purpose statement from Risk Management:
The purpose of Risk Management is to identify potential problems before they occur, so that risk-handling activities can be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives.
The three specific goals in Risk Management address preparations, identification and analysis of risk, and mitigation as needed. In this way, the purpose statement provides a quick, high-level orientation for the entire process area.
Introductory Note. A section including multiple introductory notes that apply to the entire process area follows the purpose statement. Typically, these notes present information on the scope of the process area, its importance, the way in which it reflects recognized successful practices, unique terminology used in it, and the interaction of it with other process areas.
Reference. Explicit pointing from one process area to all or part of another process area is accomplished with a reference. In CMMI, a reference is simply an indicator noting that, to obtain more information on some topic, one should look in another process area.
Names. In CMMI, all required and expected components (goals and practices) are given a name, which provides a convenient handle for referring to the component. Table 4-5 lists examples of names from the Measurement and Analysis (MA) process area. Thus, in training classes or in discussion, we can refer to the “align activities” goal or the “specify measures” practice in Measurement and Analysis. Although this name provides a convenient shorthand, do not confuse the name of the model component with the component itself. The components form the basis for process improvement and process appraisal—not the names.
Table 4-5. Names from the Measurement and Analysis Process Area
Component
Name
Required or Expected Material
MA SG 1
Align Measurement and Analysis Activities
Measurement objectives and activities are aligned with identified information needs and objectives.
MA SP 1.2
Specify Measures
Specify measures to address the measurement objectives.
Specific Goal and Practice Summary. Using the names for goals and practices, the relationship table in each process area maps each specific and generic practice to its related specific or generic goal, respectively.
Notes. Whereas the general notes at the beginning of a process area are labeled as “introductory notes,” there are also (plain) notes attached to other model components, such as goals, practices, and subpractices. These notes represent a rich source of information that should prove valuable in planning and conducting process improvement efforts. In the model, examples are highlighted by a box outlining the note.
Typical Work Products. When a practice is performed, there will often be outputs in the form of work products. In the Glossary, a work product is defined (in part) as follows:
Sample outputs from a specific practice. These examples are called typical work products because there are often other work products that are just as effective but are not listed.
These work products can include files, documents, parts of the product, services, process descriptions, and specifications.
The items identified in a list of typical work products are examples; they should not be considered essential to the performance of the process, and the list should not be thought of as exhaustive. The intention is merely to provide initial guidance regarding the type of work products that may be produced by a practice. During an appraisal, however, you will be required to produce evidence proving that your process produces outputs and to show examples of those outputs to get credit for institutionalization of the process area.
Typical Supplier Deliverables. These components are used only in the CMMI for Acquisition model. A typical supplier deliverable represents an artifact that is input into or supports the acquirer’s implementation of the practice.
Subpractices. For many practices in the CMMI models, subpractices provide a decomposition of their meaning and the activities that they might entail as well as an elaboration of their use. Unlike practices, which are expected model components, subpractices appear in the model for information purposes only.
Discipline Amplifications. One of the most distinctive aspects of CMMI as compared with prior source models is the fact that the CMMI model components are discipline independent. The advantage of this approach derives from the ability of different disciplines to use the same components, which promotes common terminology and understanding across various disciplines. The limitation on discipline-independent components becomes apparent, however, when one considers that generalization can entail the removal of content. For example, the CMM Software included a practice that made explicit reference to developing estimates of software size. In contrast, CMMI speaks more generally about producing estimates for the attributes of work products and tasks (see Project Planning, SP 1.2–1).
To maintain the usefulness of the discipline-specific material found in its source models, CMMI provides discipline amplifications that are introduced with phrases such as “For Hardware Engineering,” “For Software Engineering,” or “For Systems Engineering.” For example, in the Project Planning process area, the specific practice on establishing the project plan has a discipline amplification for software that mentions the common names of software plans. It also has a discipline amplification for hardware engineering that mentions the hardware development plan and addresses production plans. Amplifications are informative material, so they are not required in an appraisal. Nevertheless, the appraisers may use them as guidance on how to interpret the practice for specific disciplines and to gain a better idea of how the practice will affect the process improvement activities.
Generic Practice Elaborations. Whereas discipline amplifications provide details for each specific discipline, generic practice elaborations provide details regarding the application of a generic practice in a given process area. For example, in the Product Integration process area, an elaboration of the generic practice on establishing an organizational policy is explained with these words:
This policy establishes organizational expectations for developing product integration sequences, procedures, and an environment, ensuring interface compatibility among product components, assembling the product components, and delivering the product and product components.
Sometimes, in a given process area, a generic practice and a specific practice may seem to address a similar topic. For example, the generic practice may deal with planning the process, and a specific practice may focus on planning a particular aspect of the process. In such a circumstance, a generic practice elaboration is used to comment on the distinction intended between the generic and specific practices.
Additions extend the scope of a model or emphasize a particular aspect of its use. They can be additional process areas, specific goals, specific practices, or informative material. In CMMI for Development version 1.2, the only additions that exist are related to IPPD. An example IPPD Addition can be found in Organizational Process Definition +IPPD, GP 2.6:
Examples of work products placed under control include the following:
Empowerment rules and guidelines for people and integrated teams
Organizational process documentation for issue resolution
The CMMI for Services constellation currently has three additions. Each one is a complete process area. See Chapter 7 for a discussion of the CMMI-SVC.
Earlier in this chapter we mentioned the CMF but did not explain its significance in the CMMI Framework. This section describes how the CMF is used.
The CMF contains components that must be used in every constellation. However, constellation-specific information can be added to the CMF. For example, the notes associated with a practice can be marked as CMF material. The CMF notes cannot be modified in any way, but a new note can be added to a practice to clarify some aspect of the practice within the constellation. In fact, material associated with any process area component can be added to a CMF process area, including specific goals, specific practices, and any informative component.
Each constellation comprises a collection of process areas (see Section 4.2). The CMF contains the 16 core process areas that are common to all constellations:
Causal Analysis and Resolution
Configuration Management
Decision Analysis and Resolution
Measurement and Analysis
Organizational Innovation and Deployment
Organizational Process Definition
Organizational Process Focus
Organizational Process Performance
Organizational Training
Project Monitoring and Control
Project Planning
Process and Product Quality Assurance
Quantitative Project Management
Requirements Management
Risk Management
Each constellation is composed of the following elements:
The CMF
Named groups of non-CMF materials to expand the scope of the CMF in various ways[4]
Generic practice elaborations [See Section 4.6(11)] for the process areas in the constellation (optional)
Appropriate training materials
Appraisal materials
The models of a constellation are constructed by inserting selected non-CMF materials including amplifications into the CMF, and optionally inserting the generic practice elaborations for the process areas into the model.
Figure 4-1 shows where to find the various types of information described in this chapter. The illustration is from the downloadable model.[5]
[1] The term “constellation” is an element of the CMMI architecture that is used to characterize parts of the model that work together to address improvement in specific areas of interest. (Definition: A constellation is a collection of components that are used to construct models, training material, and appraisal materials in an area of interest.) There is some uncertainty whether in the future this architectural construct and this term will continue to be used. The authors make use of the current architecture and terminology for this edition of the book, but readers should be aware that this situation may change in the future.
[2] A Technical Note from the SEI describes the CMMI Framework, the CMMI Model Foundation, and the Structure of CMMI Models. See Introduction to the Architecture of the CMMI Framework, CMU/SEI-2007-TN-009.
[3] Not all models make use of each of the informative components. For example, the CMMI-DEV does not use Typical Supplier Deliverables and the CMMI-ACQ does not use either Generic Practice Elaborations or Discipline Amplifications. So while there are 11 types of informative components, currently no model uses more than 10.
[4] For example, non-CMF materials in CMMI-DEV include all of the Engineering process areas. An IPPD group of additions consisting of specific goals to be added to IPM and OPF creates the CMMI-DEV +IPPD model.
[5] The model is formatted differently in the book CMMI: Guidelines for Process Integration and Product Improvement. See Section 5.4 for more information.