CMMI® for Development, Version 1.3
CMMI-DEV, V1.3
CMMI Product Team
Improving processes for developing better products and services
November 2010
TECHNICAL REPORT
CMU/SEI-2010-TR-033
ESC-TR-2010-033
Software Engineering Process Management Program
Unlimited distribution subject to the copyright.
http://www.sei.cmu.edu
This report was prepared for the
SEI Administrative Agent
ESC/XPK
5 Eglin Street
Hanscom AFB, MA 01731-2100
The ideas and findings in this report should not be construed as an official DoD position. It is
published in the interest of scientific and technical information exchange.
This work is sponsored by the U.S. Department of Defense. The Software Engineering Institute is a
federally funded research and development center sponsored by the U.S. Department of Defense.
Copyright 2010 Carnegie Mellon University.
NO WARRANTY
THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE
MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY
MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY
MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR
MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE
MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF
ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT
INFRINGEMENT.
Use of any trademarks in this report is not intended in any way to infringe on the rights of the
trademark holder.
Internal use. Permission to reproduce this document and to prepare derivative works from this
document for internal use is granted, provided the copyright and “No Warranty” statements are
included with all reproductions and derivative works.
External use. This document may be reproduced in its entirety, without modification, and freely distributed in
written or electronic form without requesting formal permission. Permission is required for any other external
and/or commercial use. Requests for permission should be directed to the Software Engineering Institute at
permission@sei.cmu.edu.
This work was created in the performance of Federal Government Contract Number FA8721-05-C0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a
federally funded research and development center. The Government of the United States has a royaltyfree government-purpose license to use, duplicate, or disclose the work, in whole or in part and in any
manner, and to have or permit others to do so, for government purposes pursuant to the copyright
license under the clause at 252.227-7013.
For information about SEI publications, please visit the library on the SEI website
(www.sei.cmu.edu/library).
The following service marks and registered marks are used in this document:
document:Capability Maturity
Model
Carnegie Mellon CERT CMM CMMI CMM Integration IDEALSM SCAMPISM
CMMI, CMM, CERT, CMM Integration, Carnegie Mellon, and Capability Maturity Model are
registered in the U.S. Patent and Trademark Office.
SCAMPI and IDEAL are service marks of Carnegie Mellon University.
CMMI for Development, Version 1.3
Preface
CMMI® (Capability Maturity Model® Integration) models are collections of
best practices that help organizations to improve their processes. These
models are developed by product teams with members from industry,
government, and the Software Engineering Institute (SEI).
This model, called CMMI for Development (CMMI-DEV), provides a
comprehensive integrated set of guidelines for developing products and
services.
Purpose
The CMMI-DEV model provides guidance for applying CMMI best practices
in a development organization. Best practices in the model focus on
activities for developing quality products and services to meet the needs of
customers and end users.
The CMMI-DEV, V1.3 model is a collection of development best practices
from government and industry that is generated from the CMMI V1.3
Architecture and Framework.1 CMMI-DEV is based on the CMMI Model
Foundation or CMF (i.e., model components common to all CMMI models
and constellations2) and incorporates work by development organizations to
adapt CMMI for use in the development of products and services.
Acknowledgments
Many talented people were involved in the development of the V1.3 CMMI
Product Suite. Three primary groups were the CMMI Steering Group,
Product Team, and Configuration Control Board (CCB).
The Steering Group guided and approved the plans of the Product Team,
provided consultation on significant CMMI project issues, and ensured
involvement from a variety of interested communities.
The Steering Group oversaw the development of the Development
constellation recognizing the importance of providing best practices to
development organizations.
1
The CMMI Framework is the basic structure that organizes CMMI components and combines them into CMMI constellations
and models.
2
A constellation is a collection of CMMI components that are used to construct models, training materials, and appraisal related
documents for an area of interest (e.g., development, acquisition, services).
Preface
i
CMMI for Development, Version 1.3
The Product Team wrote, reviewed, revised, discussed, and agreed on the
structure and technical content of the CMMI Product Suite, including the
framework, models, training, and appraisal materials. Development
activities were based on multiple inputs. These inputs included an ASpecification and guidance specific to each release provided by the
Steering Group, source models, change requests received from the user
community, and input received from pilots and other stakeholders.
The CCB is the official mechanism for controlling changes to CMMI models,
appraisal related documents, and Introduction to CMMI training. As such,
this group ensures integrity over the life of the product suite by reviewing all
proposed changes to the baseline and approving only those changes that
satisfy identified issues and meet criteria for the upcoming release.
Members of the groups involved in developing CMMI-DEV, V1.3 are listed
in Appendix C.
Audience
The audience for CMMI-DEV includes anyone interested in process
improvement in a development environment. Whether you are familiar with
the concept of Capability Maturity Models or are seeking information to
begin improving your development processes, CMMI-DEV will be useful to
you. This model is also intended for organizations that want to use a
reference model for an appraisal of their development related processes.3
Organization of this Document
This document is organized into three main parts:
Part One: About CMMI for Development
Part Two: Generic Goals and Generic Practices, and the Process Areas
Part Three: The Appendices and Glossary
Part One: About CMMI for Development, consists of five chapters:
Chapter 1, Introduction, offers a broad view of CMMI and the CMMI for
Development constellation, concepts of process improvement, and the
history of models used for process improvement and different process
improvement approaches.
Chapter 2, Process Area Components, describes all of the components
of the CMMI for Development process areas.4
Chapter 3, Tying It All Together, assembles the model components and
explains the concepts of maturity levels and capability levels.
3
An appraisal is an examination of one or more processes by a trained team of professionals using a reference model (e.g.,
CMMI-DEV) as the basis for determining strengths and weaknesses.
4
A process area is a cluster of related practices in an area that, when implemented collectively, satisfies a set of goals
considered important for making improvement in that area. This concept is covered in detail in Chapter 2.
ii
Preface
CMMI for Development, Version 1.3
Chapter 4, Relationships Among Process Areas, provides insight into
the meaning and interactions among the CMMI-DEV process areas.
Chapter 5, Using CMMI Models, describes paths to adoption and the
use of CMMI for process improvement and benchmarking of practices
in a development organization.
Part Two: Generic Goals and Generic Practices, and the Process Areas,
contains all of this CMMI model’s required and expected components. It
also contains related informative components, including subpractices,
notes, examples, and example work products.
Part Two contains 23 sections. The first section contains the generic goals
and practices. The remaining 22 sections each represent one of the CMMIDEV process areas.
To make these process areas easy to find, they are organized
alphabetically by process area acronym. Each section contains descriptions
of goals, best practices, and examples.
Part Three: The Appendices and Glossary, consists of four sections:
Appendix A: References, contains references you can use to locate
documented sources of information such as reports, process
improvement models, industry standards, and books that are related to
CMMI-DEV.
Appendix B: Acronyms, defines the acronyms used in the model.
Appendix C: CMMI Version 1.3 Project Participants contains lists of
team members who participated in the development of CMMI-DEV,
V1.3.
Appendix D: Glossary, defines many of the terms used in CMMI-DEV.
How to Use this Document
Whether you are new to process improvement, new to CMMI, or already
familiar with CMMI, Part One can help you understand why CMMI-DEV is
the model to use for improving your development processes.
Readers New to Process Improvement
If you are new to process improvement or new to the Capability Maturity
Model (CMM®) concept, we suggest that you read Chapter 1 first. Chapter 1
contains an overview of process improvement that explains what CMMI is
all about.
Next, skim Part Two, including generic goals and practices and specific
goals and practices, to get a feel for the scope of the best practices
contained in the model. Pay close attention to the purpose and introductory
notes at the beginning of each process area.
In Part Three, look through the references in Appendix A and select
additional sources you think would be beneficial to read before moving
forward with using CMMI-DEV. Read through the acronyms and glossary to
Preface
iii
CMMI for Development, Version 1.3
become familiar with the language of CMMI. Then, go back and read the
details of Part Two.
Readers Experienced with Process Improvement
If you are new to CMMI but have experience with other process
improvement models, such as the Software CMM or the Systems
Engineering Capability Model (i.e., EIA 731), you will immediately recognize
many similarities in their structure and content [EIA 2002a].
We recommend that you read Part One to understand how CMMI is
different from other process improvement models. If you have experience
with other models, you may want to select which sections to read first. Read
Part Two with an eye for best practices you recognize from the models that
you have already used. By identifying familiar material, you will gain an
understanding of what is new, what has been carried over, and what is
familiar from the models you already know.
Next, review the glossary to understand how some terminology can differ
from that used in the process improvement models you know. Many
concepts are repeated, but they may be called something different.
Readers Familiar with CMMI
If you have reviewed or used a CMMI model before, you will quickly
recognize the CMMI concepts discussed and the best practices presented.
As always, the improvements that the CMMI Product Team made to CMMI
for the V1.3 release were driven by user input. Change requests were
carefully considered, analyzed, and implemented.
Some significant improvements you can expect in CMMI-DEV, V1.3 include
the following:
High maturity process areas are significantly improved to reflect
industry best practices, including a new specific goal and several new
specific practices in the process area that was renamed from
Organizational Innovation and Deployment (OID) to Organizational
Performance Management (OPM).
Improvements were made to the model architecture that simplify the
use of multiple models.
Informative material was improved, including revising the engineering
practices to reflect industry best practice and adding guidance for
organizations that use Agile methods.
Glossary definitions and model terminology were improved to enhance
the clarity, accuracy, and usability of the model.
Level 4 and 5 generic goals and practices were eliminated as well as
capability levels 4 and 5 to appropriately focus high maturity on the
achievement of business objectives, which is accomplished by applying
capability level 1-3 to the high maturity process areas (Causal Analysis
and Resolution, Quantitative Project Management, Organizational
Performance Management, and Organizational Process Performance).
iv
Preface
CMMI for Development, Version 1.3
For a more complete and detailed list of improvements, see
http://www.sei.cmu.edu/cmmi/tools/cmmiv1-3/.
Additional Information and Reader Feedback
Many sources of information about CMMI are listed in Appendix A and are
also published on the CMMI website—http://www.sei.cmu.edu/cmmi/.
Your suggestions for improving CMMI are welcome. For information on how
to provide feedback, see the CMMI website at
http://www.sei.cmu.edu/cmmi/tools/cr/. If you have questions about CMMI,
send email to cmmi-comments@sei.cmu.edu.
Preface
v
CMMI for Development, Version 1.3
vi
Preface
CMMI for Development, Version 1.3
Table of Contents
Preface
Purpose
Acknowledgments
Audience
Organization of this Document
How to Use this Document
Readers New to Process Improvement
Readers Experienced with Process Improvement
Readers Familiar with CMMI
Additional Information and Reader Feedback
ii
i
i
ii
ii
iii
iii
iv
iv
v
Part One: About CMMI for Development
1
1
Introduction
About Process Improvement
About Capability Maturity Models
Evolution of CMMI
CMMI Framework
CMMI for Development
3
4
5
5
7
7
2
Process Area Components
Core Process Areas and CMMI Models
Required, Expected, and Informative Components
Required Components
Expected Components
Informative Components
Components Associated with Part Two
Process Areas
Purpose Statements
Introductory Notes
Related Process Areas
Specific Goals
Generic Goals
Specific Goal and Practice Summaries
Specific Practices
Example Work Products
Subpractices
Generic Practices
Generic Practice Elaborations
Additions
Supporting Informative Components
Notes
Examples
References
Numbering Scheme
Typographical Conventions
9
9
9
9
9
10
10
11
11
11
12
12
12
12
13
13
13
13
14
14
14
14
14
15
15
16
3
Tying It All Together
Understanding Levels
Structures of the Continuous and Staged Representations
21
21
22
Table of Contents
vii
CMMI for Development, Version 1.3
Understanding Capability Levels
Capability Level 0: Incomplete
Capability Level 1: Performed
Capability Level 2: Managed
Capability Level 3: Defined
Advancing Through Capability Levels
Understanding Maturity Levels
Maturity Level 1: Initial
Maturity Level 2: Managed
Maturity Level 3: Defined
Maturity Level 4: Quantitatively Managed
Maturity Level 5: Optimizing
Advancing Through Maturity Levels
Process Areas
Equivalent Staging
Achieving High Maturity
24
24
24
25
25
25
26
27
27
28
28
29
29
30
34
37
4
Relationships Among Process Areas
Process Management
Basic Process Management Process Areas
Advanced Process Management Process Areas
Project Management
Basic Project Management Process Areas
Advanced Project Management Process Areas
Engineering
Recursion and Iteration of Engineering Processes
Support
Basic Support Process Areas
Advanced Support Process Areas
39
39
40
41
43
43
45
47
50
50
51
52
5
Using CMMI Models
Adopting CMMI
Your Process Improvement Program
Selections that Influence Your Program
CMMI Models
Interpreting CMMI When Using Agile Approaches
Using CMMI Appraisals
Appraisal Requirements for CMMI
SCAMPI Appraisal Methods
Appraisal Considerations
CMMI Related Training
55
55
56
56
57
58
59
59
59
60
61
Part Two: Generic Goals and Generic Practices, and the Process Areas
63
Generic Goals and Generic Practices
Overview
Process Institutionalization
Performed Process
Managed Process
Defined Process
Relationships Among Processes
Generic Goals and Generic Practices
Applying Generic Practices
Process Areas that Support Generic Practices
65
65
65
65
66
66
67
68
120
121
viii
Table of Contents
CMMI for Development, Version 1.3
Causal Analysis and Resolution
127
Configuration Management
137
Decision Analysis and Resolution
149
Integrated Project Management
157
Measurement and Analysis
175
Organizational Process Definition
191
Organizational Process Focus
203
Organizational Performance Management
217
Organizational Process Performance
235
Organizational Training
247
Product Integration
257
Project Monitoring and Control
271
Project Planning
281
Process and Product Quality Assurance
301
Quantitative Project Management
307
Requirements Development
325
Requirements Management
341
Risk Management
349
Supplier Agreement Management
363
Technical Solution
373
Validation
393
Verification
401
Part Three: The Appendices
413
Appendix A: References
Information Assurance/Information Security Related Sources
415
419
Appendix B: Acronyms
421
Appendix C: CMMI Version 1.3 Project Participants
CMMI Steering Group
Steering Group Members
Ex-Officio Steering Group Members
Steering Group Support
CMMI for Services Advisory Group
CMMI V1.3 Coordination Team
CMMI V1.3 Configuration Control Board
CMMI V1.3 Core Model Team
CMMI V1.3 Translation Team
CMMI V1.3 High Maturity Team
CMMI V1.3 Acquisition Mini Team
CMMI V1.3 Services Mini Team
CMMI V1.3 SCAMPI Upgrade Team
CMMI Version 1.3 Training Teams
ACQ and DEV Training Team
425
425
425
426
426
426
427
427
428
428
429
429
429
430
430
430
Table of Contents
ix
CMMI for Development, Version 1.3
SVC Training Team
CMMI V1.3 Quality Team
Appendix D: Glossary
x
431
431
433
Table of Contents
CMMI for Development, Version 1.3
Part One:
About CMMI for Development
1
CMMI for Development, Version 1.3
2
CMMI for Development, Version 1.3
1 Introduction
Now more than ever, companies want to deliver products and services
better, faster, and cheaper. At the same time, in the high-technology
environment of the twenty-first century, nearly all organizations have found
themselves building increasingly complex products and services. It is
unusual today for a single organization to develop all the components that
compose a complex product or service. More commonly, some components
are built in-house and some are acquired; then all the components are
integrated into the final product or service. Organizations must be able to
manage and control this complex development and maintenance process.
The problems these organizations address today involve enterprise-wide
solutions that require an integrated approach. Effective management of
organizational assets is critical to business success. In essence, these
organizations are product and service developers that need a way to
manage their development activities as part of achieving their business
objectives.
In the current marketplace, maturity models, standards, methodologies, and
guidelines exist that can help an organization improve the way it does
business. However, most available improvement approaches focus on a
specific part of the business and do not take a systemic approach to the
problems that most organizations are facing. By focusing on improving one
area of a business, these models have unfortunately perpetuated the
stovepipes and barriers that exist in organizations.
CMMI® for Development (CMMI-DEV) provides an opportunity to avoid or
eliminate these stovepipes and barriers. CMMI for Development consists of
best practices that address development activities applied to products and
services. It addresses practices that cover the product’s lifecycle from
conception through delivery and maintenance. The emphasis is on the work
necessary to build and maintain the total product.
CMMI-DEV contains 22 process areas. Of those process areas, 16 are core
process areas, 1 is a shared process area, and 5 are development specific
process areas.5
All CMMI-DEV model practices focus on the activities of the developer
organization. Five process areas focus on practices specific to
development: addressing requirements development, technical solution,
product integration, verification, and validation.
5
A core process area is a process area that is common to all CMMI models. A shared process area is shared by at least two
CMMI models, but not all of them.
Introduction
3
CMMI for Development, Version 1.3
About Process Improvement
In its research to help organizations to develop and maintain quality
products and services, the Software Engineering Institute (SEI) has found
several dimensions that an organization can focus on to improve its
business. Figure 1.1 illustrates the three critical dimensions that
organizations typically focus on: people, procedures and methods, and
tools and equipment.
Procedures and methods
defining the relationship of
tasks
B
A
D
C
PROCESS
People
with skills,
training, and
motivation
Tools and
equipment
Figure 1.1: The Three Critical Dimensions
What holds everything together? It is the processes used in your
organization. Processes allow you to align the way you do business. They
allow you to address scalability and provide a way to incorporate knowledge
of how to do things better. Processes allow you to leverage your resources
and to examine business trends.
This is not to say that people and technology are not important. We are
living in a world where technology is changing at an incredible speed.
Similarly, people typically work for many companies throughout their
careers. We live in a dynamic world. A focus on process provides the
infrastructure and stability necessary to deal with an ever-changing world
and to maximize the productivity of people and the use of technology to be
competitive.
Manufacturing has long recognized the importance of process effectiveness
and efficiency. Today, many organizations in manufacturing and service
industries recognize the importance of quality processes. Process helps an
organization’s workforce to meet business objectives by helping them to
work smarter, not harder, and with improved consistency. Effective
processes also provide a vehicle for introducing and using new technology
in a way that best meets the business objectives of the organization.
4
Introduction
CMMI for Development, Version 1.3
About Capability Maturity Models
A Capability Maturity Model® (CMM®), including CMMI, is a simplified
representation of the world. CMMs contain the essential elements of
effective processes. These elements are based on the concepts developed
by Crosby, Deming, Juran, and Humphrey.
In the 1930s, Walter Shewhart began work in process improvement with his
principles of statistical quality control [Shewhart 1931]. These principles
were refined by W. Edwards Deming [Deming 1986], Phillip Crosby [Crosby
1979], and Joseph Juran [Juran 1988]. Watts Humphrey, Ron Radice, and
others extended these principles further and began applying them to
software in their work at IBM (International Business Machines) and the SEI
[Humphrey 1989]. Humphrey’s book, Managing the Software Process,
provides a description of the basic principles and concepts on which many
of the Capability Maturity Models® (CMMs®) are based.
The SEI has taken the process management premise, “the quality of a
system or product is highly influenced by the quality of the process used to
develop and maintain it,” and defined CMMs that embody this premise. The
belief in this premise is seen worldwide in quality movements, as evidenced
by the International Organization for Standardization/International
Electrotechnical Commission (ISO/IEC) body of standards.
CMMs focus on improving processes in an organization. They contain the
essential elements of effective processes for one or more disciplines and
describe an evolutionary improvement path from ad hoc, immature
processes to disciplined, mature processes with improved quality and
effectiveness.
Like other CMMs, CMMI models provide guidance to use when developing
processes. CMMI models are not processes or process descriptions. The
actual processes used in an organization depend on many factors,
including application domains and organization structure and size. In
particular, the process areas of a CMMI model typically do not map one to
one with the processes used in your organization.
The SEI created the first CMM designed for software organizations and
published it in a book, The Capability Maturity Model: Guidelines for
Improving the Software Process [SEI 1995].
Today, CMMI is an application of the principles introduced almost a century
ago to this never-ending cycle of process improvement. The value of this
process improvement approach has been confirmed over time.
Organizations have experienced increased productivity and quality,
improved cycle time, and more accurate and predictable schedules and
budgets [Gibson 2006].
Evolution of CMMI
The CMM Integration® project was formed to sort out the problem of using
multiple CMMs. The combination of selected models into a single
Introduction
5
CMMI for Development, Version 1.3
improvement framework was intended for use by organizations in their
pursuit of enterprise-wide process improvement.
Developing a set of integrated models involved more than simply combining
existing model materials. Using processes that promote consensus, the
CMMI Product Team built a framework that accommodates multiple
constellations.
The first model to be developed was the CMMI for Development model
(then simply called “CMMI”). Figure 1.2 illustrates the models that led to
CMMI Version 1.3.
History of CMMs
CMM for Software
V1.1 (1993)
INCOSE SECAM
(1996)
Systems Engineering
CMM V1.1 (1995)
Software CMM
V2, draft C (1997)
Software Acquisition
CMM V1.03 (2002)
CMMI for Acquisition
V1.2 (2007)
EIA 731 SECM
(1998)
Integrated Product
Development CMM
(1997)
V1.02
v1.02 (2000)
V1.1
v1.1 (2002)
(2002)
CMMI for Development
V1.2 (2006)
CMMI for Services
V1.2 (2009)
CMMI for Acquisition CMMI for Development CMMI for Services
V1.3 (2010)
V1.3 (2010)
V1.3 (2010)
Figure 1.2: The History of CMMs6
Initially, CMMI was one model that combined three source models: the
Capability Maturity Model for Software (SW-CMM) v2.0 draft C, the
Systems Engineering Capability Model (SECM) [EIA 2002a], and the
Integrated Product Development Capability Maturity Model (IPD-CMM)
v0.98.
6
6
EIA 731 SECM is the Electronic Industries Alliance standard 731, or the Systems Engineering Capability Model. INCOSE
SECAM is International Council on Systems Engineering Systems Engineering Capability Assessment Model [EIA 2002a].
Introduction
CMMI for Development, Version 1.3
These three source models were selected because of their successful
adoption or promising approach to improving processes in an organization.
The first CMMI model (V1.02) was designed for use by development
organizations in their pursuit of enterprise-wide process improvement. It
was released in 2000. Two years later version 1.1 was released and four
years after that, version 1.2 was released.
By the time that version 1.2 was released, two other CMMI models were
being planned. Because of this planned expansion, the name of the first
CMMI model had to change to become CMMI for Development and the
concept of constellations was created.
The CMMI for Acquisition model was released in 2007. Since it built on the
CMMI for Development Version 1.2 model, it also was named Version 1.2.
Two years later the CMMI for Services model was released. It built on the
other two models and also was named Version 1.2.
In 2008 plans were drawn to begin developing Version 1.3, which would
ensure consistency among all three models and improve high maturity
material in all of the models. Version 1.3 of CMMI for Acquisition [Gallagher
2011, SEI 2010b], CMMI for Development [Chrissis 2011], and CMMI for
Services [Forrester 2011, SEI 2010a] were released in November 2010.
CMMI Framework
The CMMI Framework provides the structure needed to produce CMMI
models, training, and appraisal components. To allow the use of multiple
models within the CMMI Framework, model components are classified as
either common to all CMMI models or applicable to a specific model. The
common material is called the “CMMI Model Foundation” or “CMF.”
The components of the CMF are part of every model generated from the
CMMI Framework. Those components are combined with material
applicable to an area of interest (e.g., acquisition, development, services) to
produce a model.
A “constellation” is defined as a collection of CMMI components that are
used to construct models, training materials, and appraisal related
documents for an area of interest (e.g., acquisition, development, services).
The Development constellation’s model is called “CMMI for Development”
or “CMMI-DEV.”
CMMI for Development
CMMI for Development is a reference model that covers activities for
developing both products and services. Organizations from many
industries, including aerospace, banking, computer hardware, software,
defense, automobile manufacturing, and telecommunications, use CMMI for
Development.
Introduction
7
CMMI for Development, Version 1.3
CMMI for Development contains practices that cover project management,
process management, systems engineering, hardware engineering,
software engineering, and other supporting processes used in development
and maintenance.
Use professional judgment and common sense to interpret the model for
your organization. That is, although the process areas described in this
model depict behaviors considered best practices for most users, process
areas and practices should be interpreted using an in-depth knowledge of
CMMI-DEV, your organizational constraints, and your business
environment.
8
Introduction
CMMI for Development, Version 1.3
2 Process Area Components
This chapter describes the components found in each process area and in
the generic goals and generic practices. Understanding these components
is critical to using the information in Part Two effectively. If you are
unfamiliar with Part Two, you may want to skim the Generic Goals and
Generic Practices section and a couple of process area sections to get a
general feel for the content and layout before reading this chapter.
Core Process Areas and CMMI Models
All CMMI models are produced from the CMMI Framework. This framework
contains all of the goals and practices that are used to produce CMMI
models that belong to CMMI constellations.
All CMMI models contain 16 core process areas. These process areas
cover basic concepts that are fundamental to process improvement in any
area of interest (i.e., acquisition, development, services). Some of the
material in the core process areas is the same in all constellations. Other
material may be adjusted to address a specific area of interest.
Consequently, the material in the core process areas may not be exactly
the same.
Required, Expected, and Informative Components
Model components are grouped into three categories—required, expected,
and informative—that reflect how to interpret them.
Required Components
Required components are CMMI components that are essential to
achieving process improvement in a given process area. This achievement
must be visibly implemented in an organization’s processes. The required
components in CMMI are the specific and generic goals. Goal satisfaction is
used in appraisals as the basis for deciding whether a process area has
been satisfied.
Expected Components
Expected components are CMMI components that describe the activities
that are important in achieving a required CMMI component. Expected
components guide those who implement improvements or perform
appraisals. The expected components in CMMI are the specific and generic
practices.
Process Area Components
9
CMMI for Development, Version 1.3
Before goals can be considered to be satisfied, either their practices as
described, or acceptable alternatives to them, must be present in the
planned and implemented processes of the organization.
Informative Components
Informative components are CMMI components that help model users
understand CMMI required and expected components. These components
can be example boxes, detailed explanations, or other helpful information.
Subpractices, notes, references, goal titles, practice titles, sources,
example work products, and generic practice elaborations are informative
model components.
The informative material plays an important role in understanding the
model. It is often impossible to adequately describe the behavior required or
expected of an organization using only a single goal or practice statement.
The model’s informative material provides information necessary to achieve
the correct understanding of goals and practices and thus cannot be
ignored.
Components Associated with Part Two
The model components associated with Part Two are summarized in Figure
2.1 to illustrate their relationships.
Process Area
Purpose
Statement
Specific Goals
Goals
Specific
KEY:
Required
Related
Process Areas
Generic Goals
Specific Practices
Example
Work
Typical Work
Products
Products
Introductory
Notes
Generic Practices
Subpractices
Expected
Subpractices
Generic Practice
Subpractices
Elaborations
Informative
Informative
Figure 2.1: CMMI Model Components
The following sections provide detailed descriptions of CMMI model
components.
10
Process Area Components
CMMI for Development, Version 1.3
Process Areas
A process area is a cluster of related practices in an area that, when
implemented collectively, satisfies a set of goals considered important for
making improvement in that area. (See the definition of “process area” in
the glossary.)
The 22 process areas are presented in alphabetical order by acronym:
Causal Analysis and Resolution (CAR)
Configuration Management (CM)
Decision Analysis and Resolution (DAR)
Integrated Project Management (IPM)
Measurement and Analysis (MA)
Organizational Process Definition (OPD)
Organizational Process Focus (OPF)
Organizational Performance Management (OPM)
Organizational Process Performance (OPP)
Organizational Training (OT)
Product Integration (PI)
Project Monitoring and Control (PMC)
Project Planning (PP)
Process and Product Quality Assurance (PPQA)
Quantitative Project Management (QPM)
Requirements Development (RD)
Requirements Management (REQM)
Risk Management (RSKM)
Supplier Agreement Management (SAM)
Technical Solution (TS)
Validation (VAL)
Verification (VER)
Purpose Statements
A purpose statement describes the purpose of the process area and is an
informative component.
For example, the purpose statement of the Organizational Process
Definition process area is “The purpose of Organizational Process
Definition (OPD) is to establish and maintain a usable set of organizational
process assets, work environment standards, and rules and guidelines for
teams.”
Introductory Notes
The introductory notes section of the process area describes the major
concepts covered in the process area and is an informative component.
Process Area Components
11
CMMI for Development, Version 1.3
An example from the introductory notes of the Project Monitoring and
Control process area is “When actual status deviates significantly from
expected values, corrective actions are taken as appropriate.”
Related Process Areas
The Related Process Areas section lists references to related process
areas and reflects the high-level relationships among the process areas.
The Related Process Areas section is an informative component.
An example of a reference found in the Related Process Areas section of
the Project Planning process area is “Refer to the Risk Management
process area for more information about identifying and analyzing risks and
mitigating risks.”
Specific Goals
A specific goal describes the unique characteristics that must be present to
satisfy the process area. A specific goal is a required model component and
is used in appraisals to help determine whether a process area is satisfied.
(See the definition of “specific goal” in the glossary.)
For example, a specific goal from the Configuration Management process
area is “Integrity of baselines is established and maintained.”
Only the statement of the specific goal is a required model component. The
title of a specific goal (preceded by the goal number) and notes associated
with the goal are considered informative model components.
Generic Goals
Generic goals are called “generic” because the same goal statement
applies to multiple process areas. A generic goal describes the
characteristics that must be present to institutionalize processes that
implement a process area. A generic goal is a required model component
and is used in appraisals to determine whether a process area is satisfied.
(See the Generic Goals and Generic Practices section in Part Two for a
more detailed description of generic goals. See the definition of “generic
goal” in the glossary.)
An example of a generic goal is “The process is institutionalized as a
defined process.”
Only the statement of the generic goal is a required model component. The
title of a generic goal (preceded by the goal number) and notes associated
with the goal are considered informative model components.
Specific Goal and Practice Summaries
The specific goal and practice summary provides a high-level summary of
the specific goals and specific practices. The specific goal and practice
summary is an informative component.
12
Process Area Components
CMMI for Development, Version 1.3
Specific Practices
A specific practice is the description of an activity that is considered
important in achieving the associated specific goal. The specific practices
describe the activities that are expected to result in achievement of the
specific goals of a process area. A specific practice is an expected model
component. (See the definition of “specific practice” in the glossary.)
For example, a specific practice from the Project Monitoring and Control
process area is “Monitor commitments against those identified in the project
plan.”
Only the statement of the specific practice is an expected model
component. The title of a specific practice (preceded by the practice
number) and notes associated with the specific practice are considered
informative model components.
Example Work Products
The example work products section lists sample outputs from a specific
practice. An example work product is an informative model component.
(See the definition of “example work product” in the glossary.)
For instance, an example work product for the specific practice “Monitor
Project Planning Parameters” in the Project Monitoring and Control process
area is “Records of significant deviations.”
Subpractices
A subpractice is a detailed description that provides guidance for
interpreting and implementing a specific or generic practice. Subpractices
can be worded as if prescriptive, but they are actually an informative
component meant only to provide ideas that may be useful for process
improvement. (See the definition of “subpractice” in the glossary.)
For example, a subpractice for the specific practice “Take Corrective
Action” in the Project Monitoring and Control process area is “Determine
and document the appropriate actions needed to address identified issues.”
Generic Practices
Generic practices are called “generic” because the same practice applies to
multiple process areas. The generic practices associated with a generic
goal describe the activities that are considered important in achieving the
generic goal and contribute to the institutionalization of the processes
associated with a process area. A generic practice is an expected model
component. (See the definition of “generic practice” in the glossary.)
For example, a generic practice for the generic goal “The process is
institutionalized as a managed process” is “Provide adequate resources for
performing the process, developing the work products, and providing the
services of the process.”
Only the statement of the generic practice is an expected model
component. The title of a generic practice (preceded by the practice
Process Area Components
13
CMMI for Development, Version 1.3
number) and notes associated with the practice are considered informative
model components.
Generic Practice Elaborations
Generic practice elaborations appear after generic practices to provide
guidance on how the generic practices can be applied uniquely to process
areas. A generic practice elaboration is an informative model component.
(See the definition of “generic practice elaboration” in the glossary.)
For example, a generic practice elaboration after the generic practice
“Establish and maintain an organizational policy for planning and
performing the process” for the Project Planning process area is “This
policy establishes organizational expectations for estimating the planning
parameters, making internal and external commitments, and developing the
plan for managing the project.”
Additions
Additions are clearly marked model components that contain information of
interest to particular users. An addition can be informative material, a
specific practice, a specific goal, or an entire process area that extends the
scope of a model or emphasizes a particular aspect of its use. There are no
additions in the CMMI-DEV model.
Supporting Informative Components
In many places in the model, further information is needed to describe a
concept. This informative material is provided in the form of the following
components:
Notes
Examples
References
Notes
A note is text that can accompany nearly any other model component. It
may provide detail, background, or rationale. A note is an informative model
component.
For example, a note that accompanies the specific practice “Implement
Action Proposals” in the Causal Analysis and Resolution process area is
“Only changes that prove to be of value should be considered for broad
implementation.”
Examples
An example is a component comprising text and often a list of items, usually
in a box, that can accompany nearly any other component and provides
one or more examples to clarify a concept or described activity. An example
is an informative model component.
14
Process Area Components
CMMI for Development, Version 1.3
The following is an example that accompanies the subpractice “Document
noncompliance issues when they cannot be resolved in the project” under
the specific practice “Communicate and Ensure the Resolution of
Noncompliance Issues” in the Process and Product Quality Assurance
process area.
Examples of ways to resolve noncompliance in the project include the following:
Fixing the noncompliance
Changing the process descriptions, standards, or procedures that were violated
Obtaining a waiver to cover the noncompliance
References
A reference is a pointer to additional or more detailed information in related
process areas and can accompany nearly any other model component. A
reference is an informative model component. (See the definition of
“reference” in the glossary.)
For example, a reference that accompanies the specific practice “Compose
the Defined Process” in the Quantitative Project Management process area
is “Refer to the Organizational Process Definition process area for more
information about establishing organizational process assets.”
Numbering Scheme
Specific and generic goals are numbered sequentially. Each specific goal
begins with the prefix “SG” (e.g., SG 1). Each generic goal begins with the
prefix “GG” (e.g., GG 2).
Specific and generic practices are also numbered sequentially. Each
specific practice begins with the prefix “SP,” followed by a number in the
form “x.y” (e.g., SP 1.1). The x is the same number as the goal to which the
specific practice maps. The y is the sequence number of the specific
practice under the specific goal.
An example of specific practice numbering is in the Project Planning
process area. The first specific practice is numbered SP 1.1 and the second
is SP 1.2.
Each generic practice begins with the prefix “GP,” followed by a number in
the form “x.y” (e.g., GP 1.1).
The x corresponds to the number of the generic goal. The y is the sequence
number of the generic practice under the generic goal. For example, the
first generic practice associated with GG 2 is numbered GP 2.1 and the
second is GP 2.2.
Process Area Components
15
CMMI for Development, Version 1.3
Typographical Conventions
The typographical conventions used in this model were designed to enable
you to easily identify and select model components by presenting them in
formats that allow you to find them quickly on the page.
Figures 2.2, 2.3, and 2.4 are sample pages from process areas in Part Two;
they show the different process area components, labeled so that you can
identify them. Notice that components differ typographically so that you can
easily identify each one.
16
Process Area Components
CMMI for Development, Version 1.3
Process Area Name
Maturity Level
Process Area Category
Purpose Statement
Introductory Notes
Figure 2.2: Sample Page from Decision Analysis and Resolution
Process Area Components
17
CMMI for Development, Version 1.3
Specific Goal
Specific Practice
Example Work Product
Example Box
Reference
Subpractice
Figure 2.3: Sample Page from Causal Analysis and Resolution
18
Process Area Components
CMMI for Development, Version 1.3
Generic Goal
Generic Practice
Generic Practice
Elaboration
Figure 2.4: Sample Page from the Generic Goals and Generic Practices
Process Area Components
19
CMMI for Development, Version 1.3
20
Process Area Components
CMMI for Development, Version 1.3
3 Tying It All Together
Now that you have been introduced to the components of CMMI models,
you need to understand how they fit together to meet your process
improvement needs. This chapter introduces the concept of levels and
shows how the process areas are organized and used.
CMMI-DEV does not specify that a project or organization must follow a
particular process flow or that a certain number of products be developed
per day or specific performance targets be achieved. The model does
specify that a project or organization should have processes that address
development related practices. To determine whether these processes are
in place, a project or organization maps its processes to the process areas
in this model.
The mapping of processes to process areas enables the organization to
track its progress against the CMMI-DEV model as it updates or creates
processes. Do not expect that every CMMI-DEV process area will map one
to one with your organization’s or project’s processes.
Understanding Levels
Levels are used in CMMI-DEV to describe an evolutionary path
recommended for an organization that wants to improve the processes it
uses to develop products or services. Levels can also be the outcome of
the rating activity in appraisals.7 Appraisals can apply to entire
organizations or to smaller groups such as a group of projects or a division.
CMMI supports two improvement paths using levels. One path enables
organizations to incrementally improve processes corresponding to an
individual process area (or group of process areas) selected by the
organization. The other path enables organizations to improve a set of
related processes by incrementally addressing successive sets of process
areas.
These two improvement paths are associated with the two types of levels:
capability levels and maturity levels. These levels correspond to two
approaches to process improvement called “representations.” The two
representations are called “continuous” and “staged.” Using the continuous
representation enables you to achieve “capability levels.” Using the staged
representation enables you to achieve “maturity levels.”
7
For more information about appraisals, refer to Appraisal Requirements for CMMI and the Standard CMMI Appraisal Method
for Process Improvement Method Definition Document [SEI 2011a, SEI 2011b].
Tying It All Together
21
CMMI for Development, Version 1.3
To reach a particular level, an organization must satisfy all of the goals of
the process area or set of process areas that are targeted for improvement,
regardless of whether it is a capability or a maturity level.
Both representations provide ways to improve your processes to achieve
business objectives, and both provide the same essential content and use
the same model components.
Structures of the Continuous and Staged Representations
Figure 3.1 illustrates the structures of the continuous and staged
representations. The differences between the structures are subtle but
significant. The staged representation uses maturity levels to characterize
the overall state of the organization’s processes relative to the model as a
whole, whereas the continuous representation uses capability levels to
characterize the state of the organization’s processes relative to an
individual process area.
Continuous Representation
Process Areas
Specific Goals
Capability Levels
Generic Goals
Specific Practices
Generic Practices
Staged Representation
Maturity Levels
Process Areas
Specific Goals
Specific Practices
Generic Goals
Generic Practices
Figure 3.1: Structure of the Continuous and Staged Representations
22
Tying It All Together
CMMI for Development, Version 1.3
What may strike you as you compare these two representations is their
similarity. Both have many of the same components (e.g., process areas,
specific goals, specific practices), and these components have the same
hierarchy and configuration.
What is not readily apparent from the high-level view in Figure 3.1 is that
the continuous representation focuses on process area capability as
measured by capability levels and the staged representation focuses on
overall maturity as measured by maturity levels. This dimension (the
capability/maturity dimension) of CMMI is used for benchmarking and
appraisal activities, as well as guiding an organization’s improvement
efforts.
Capability levels apply to an organization’s process improvement
achievement in individual process areas. These levels are a means for
incrementally improving the processes corresponding to a given process
area. The four capability levels are numbered 0 through 3.
Maturity levels apply to an organization’s process improvement
achievement across multiple process areas. These levels are a means of
improving the processes corresponding to a given set of process areas (i.e.,
maturity level). The five maturity levels are numbered 1 through 5.
Table 3.1 compares the four capability levels to the five maturity levels.
Notice that the names of two of the levels are the same in both
representations (i.e., Managed and Defined). The differences are that there
is no maturity level 0; there are no capability levels 4 and 5; and at level 1,
the names used for capability level 1 and maturity level 1 are different.
Table 3.1 Comparison of Capability and Maturity Levels
Level
Continuous Representation
Capability Levels
Staged Representation
Maturity Levels
Level 0
Incomplete
Level 1
Performed
Initial
Level 2
Managed
Managed
Level 3
Defined
Defined
Level 4
Quantitatively Managed
Level 5
Optimizing
The continuous representation is concerned with selecting both a particular
process area to improve and the desired capability level for that process
area. In this context, whether a process is performed or incomplete is
important. Therefore, the name “Incomplete” is given to the continuous
representation starting point.
Tying It All Together
23
CMMI for Development, Version 1.3
The staged representation is concerned with selecting multiple process
areas to improve within a maturity level; whether individual processes are
performed or incomplete is not the primary focus. Therefore, the name
“Initial” is given to the staged representation starting point.
Both capability levels and maturity levels provide a way to improve the
processes of an organization and measure how well organizations can and
do improve their processes. However, the associated approach to process
improvement is different.
Understanding Capability Levels
To support those who use the continuous representation, all CMMI models
reflect capability levels in their design and content.
The four capability levels, each a layer in the foundation for ongoing
process improvement, are designated by the numbers 0 through 3:
0.
Incomplete
1.
Performed
2.
Managed
3.
Defined
A capability level for a process area is achieved when all of the generic
goals are satisfied up to that level. The fact that capability levels 2 and 3
use the same terms as generic goals 2 and 3 is intentional because each of
these generic goals and practices reflects the meaning of the capability
levels of the goals and practices. (See the Generic Goals and Generic
Practices section in Part Two for more information about generic goals and
practices.) A short description of each capability level follows.
Capability Level 0: Incomplete
An incomplete process is a process that either is not performed or is
partially performed. One or more of the specific goals of the process area
are not satisfied and no generic goals exist for this level since there is no
reason to institutionalize a partially performed process.
Capability Level 1: Performed
A capability level 1 process is characterized as a performed process. A
performed process is a process that accomplishes the needed work to
produce work products; the specific goals of the process area are satisfied.
Although capability level 1 results in important improvements, those
improvements can be lost over time if they are not institutionalized. The
application of institutionalization (the CMMI generic practices at capability
levels 2 and 3) helps to ensure that improvements are maintained.
24
Tying It All Together
CMMI for Development, Version 1.3
Capability Level 2: Managed
A capability level 2 process is characterized as a 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.
The process discipline reflected by capability level 2 helps to ensure that
existing practices are retained during times of stress.
Capability Level 3: Defined
A capability level 3 process is characterized as a defined process. A
defined process is a managed process that is tailored from the
organization’s set of standard processes according to the organization’s
tailoring guidelines; has a maintained process description; and contributes
process related experiences to the organizational process assets.
A critical distinction between capability levels 2 and 3 is the scope of
standards, process descriptions, and procedures. At capability level 2, the
standards, process descriptions, and procedures can be quite different in
each specific instance of the process (e.g., on a particular project). At
capability level 3, the standards, process descriptions, and procedures for a
project are tailored from the organization’s set of standard processes to suit
a particular project or organizational unit and therefore are more consistent,
except for the differences allowed by the tailoring guidelines.
Another critical distinction is that at capability level 3 processes are typically
described more rigorously than at capability level 2. A defined process
clearly states the purpose, inputs, entry criteria, activities, roles, measures,
verification steps, outputs, and exit criteria. At capability level 3, processes
are managed more proactively using an understanding of the
interrelationships of the process activities and detailed measures of the
process and its work products.
Advancing Through Capability Levels
The capability levels of a process area are achieved through the application
of generic practices or suitable alternatives to the processes associated
with that process area.
Reaching capability level 1 for a process area is equivalent to saying that
the processes associated with that process area are performed processes.
Reaching capability level 2 for a process area is equivalent to saying that
there is a policy that indicates you will perform the process. There is a plan
for performing it, resources are provided, responsibilities are assigned,
training to perform it is provided, selected work products related to
performing the process are controlled, and so on. In other words, a
capability level 2 process can be planned and monitored just like any
project or support activity.
Tying It All Together
25
CMMI for Development, Version 1.3
Reaching capability level 3 for a process area is equivalent to saying that
an organizational standard process exists associated with that process
area, which can be tailored to the needs of the project. The processes in
the organization are now more consistently defined and applied because
they are based on organizational standard processes.
After an organization has reached capability level 3 in the process areas it
has selected for improvement, it can continue its improvement journey by
addressing high maturity process areas (Organizational Process
Performance, Quantitative Project Management, Causal Analysis and
Resolution, and Organizational Performance Management).
The high maturity process areas focus on improving the performance of
those processes already implemented. The high maturity process areas
describe the use of statistical and other quantitative techniques to improve
organizational and project processes to better achieve business objectives.
When continuing its improvement journey in this way, an organization can
derive the most benefit by first selecting the OPP and QPM process areas,
and bringing those process areas to capability levels 1, 2, and 3. In doing
so, projects and organizations align the selection and analyses of
processes more closely with their business objectives.
After the organization attains capability level 3 in the OPP and QPM
process areas, the organization can continue its improvement path by
selecting the CAR and OPM process areas. In doing so, the organization
analyzes the business performance using statistical and other quantitative
techniques to determine performance shortfalls, and identifies and deploys
process and technology improvements that contribute to meeting quality
and process performance objectives. Projects and the organization use
causal analysis to identify and resolve issues affecting performance and
promote the dissemination of best practices.
Understanding Maturity Levels
To support those who use the staged representation, all CMMI models
reflect maturity levels in their design and content. A maturity level consists
of related specific and generic practices for a predefined set of process
areas that improve the organization’s overall performance.
The maturity level of an organization provides a way to characterize its
performance. Experience has shown that organizations do their best when
they focus their process improvement efforts on a manageable number of
process areas at a time and that those areas require increasing
sophistication as the organization improves.
A maturity level is a defined evolutionary plateau for organizational process
improvement. Each maturity level matures an important subset of the
organization’s processes, preparing it to move to the next maturity level.
The maturity levels are measured by the achievement of the specific and
generic goals associated with each predefined set of process areas.
26
Tying It All Together
CMMI for Development, Version 1.3
The five maturity levels, each a layer in the foundation for ongoing process
improvement, are designated by the numbers 1 through 5:
1.
Initial
2.
Managed
3.
Defined
4.
Quantitatively Managed
5.
Optimizing
Remember that maturity levels 2 and 3 use the same terms as capability
levels 2 and 3. This consistency of terminology was intentional because the
concepts of maturity levels and capability levels are complementary.
Maturity levels are used to characterize organizational improvement relative
to a set of process areas, and capability levels characterize organizational
improvement relative to an individual process area.
Maturity Level 1: Initial
At maturity level 1, processes are usually ad hoc and chaotic. The
organization usually does not provide a stable environment to support
processes. Success in these organizations depends on the competence
and heroics of the people in the organization and not on the use of proven
processes. In spite of this chaos, maturity level 1 organizations often
produce products and services that work, but they frequently exceed the
budget and schedule documented in their plans.
Maturity level 1 organizations are characterized by a tendency to
overcommit, abandon their processes in a time of crisis, and be unable to
repeat their successes.
Maturity Level 2: Managed
At maturity level 2, the projects have ensured that processes are planned
and executed in accordance with policy; the projects employ skilled people
who have adequate resources to produce controlled outputs; involve
relevant stakeholders; are monitored, controlled, and reviewed; and are
evaluated for adherence to their process descriptions. The process
discipline reflected by maturity level 2 helps to ensure that existing practices
are retained during times of stress. When these practices are in place,
projects are performed and managed according to their documented plans.
Also at maturity level 2, the status of the work products are visible to
management at defined points (e.g., at major milestones, at the completion
of major tasks). Commitments are established among relevant stakeholders
and are revised as needed. Work products are appropriately controlled. The
work products and services satisfy their specified process descriptions,
standards, and procedures.
Tying It All Together
27
CMMI for Development, Version 1.3
Maturity Level 3: Defined
At maturity level 3, processes are well characterized and understood, and
are described in standards, procedures, tools, and methods. The
organization’s set of standard processes, which is the basis for maturity
level 3, is established and improved over time. These standard processes
are used to establish consistency across the organization. Projects
establish their defined processes by tailoring the organization’s set of
standard processes according to tailoring guidelines. (See the definition of
“organization’s set of standard processes” in the glossary.)
A critical distinction between maturity levels 2 and 3 is the scope of
standards, process descriptions, and procedures. At maturity level 2, the
standards, process descriptions, and procedures can be quite different in
each specific instance of the process (e.g., on a particular project). At
maturity level 3, the standards, process descriptions, and procedures for a
project are tailored from the organization’s set of standard processes to suit
a particular project or organizational unit and therefore are more consistent
except for the differences allowed by the tailoring guidelines.
Another critical distinction is that at maturity level 3, processes are typically
described more rigorously than at maturity level 2. A defined process clearly
states the purpose, inputs, entry criteria, activities, roles, measures,
verification steps, outputs, and exit criteria. At maturity level 3, processes
are managed more proactively using an understanding of the
interrelationships of process activities and detailed measures of the
process, its work products, and its services.
At maturity level 3, the organization further improves its processes that are
related to the maturity level 2 process areas. Generic practices associated
with generic goal 3 that were not addressed at maturity level 2 are applied
to achieve maturity level 3.
Maturity Level 4: Quantitatively Managed
At maturity level 4, the organization and projects establish quantitative
objectives for quality and process performance and use them as criteria in
managing projects. Quantitative objectives are based on the needs of the
customer, end users, organization, and process implementers. Quality and
process performance is understood in statistical terms and is managed
throughout the life of projects.
For selected subprocesses, specific measures of process performance are
collected and statistically analyzed. When selecting subprocesses for
analyses, it is critical to understand the relationships between different
subprocesses and their impact on achieving the objectives for quality and
process performance. Such an approach helps to ensure that subprocess
monitoring using statistical and other quantitative techniques is applied to
where it has the most overall value to the business. Process performance
baselines and models can be used to help set quality and process
performance objectives that help achieve business objectives.
28
Tying It All Together
CMMI for Development, Version 1.3
A critical distinction between maturity levels 3 and 4 is the predictability of
process performance. At maturity level 4, the performance of projects and
selected subprocesses is controlled using statistical and other quantitative
techniques, and predictions are based, in part, on a statistical analysis of
fine-grained process data.
Maturity Level 5: Optimizing
At maturity level 5, an organization continually improves its processes
based on a quantitative understanding of its business objectives and
performance needs. The organization uses a quantitative approach to
understand the variation inherent in the process and the causes of process
outcomes.
Maturity level 5 focuses on continually improving process performance
through incremental and innovative process and technological
improvements. The organization’s quality and process performance
objectives are established, continually revised to reflect changing business
objectives and organizational performance, and used as criteria in
managing process improvement. The effects of deployed process
improvements are measured using statistical and other quantitative
techniques and compared to quality and process performance objectives.
The project’s defined processes, the organization’s set of standard
processes, and supporting technology are targets of measurable
improvement activities.
A critical distinction between maturity levels 4 and 5 is the focus on
managing and improving organizational performance. At maturity level 4,
the organization and projects focus on understanding and controlling
performance at the subprocess level and using the results to manage
projects. At maturity level 5, the organization is concerned with overall
organizational performance using data collected from multiple projects.
Analysis of the data identifies shortfalls or gaps in performance. These gaps
are used to drive organizational process improvement that generates
measureable improvement in performance.
Advancing Through Maturity Levels
Organizations can achieve progressive improvements in their maturity by
achieving control first at the project level and continuing to the most
advanced level—organization-wide performance management and
continuous process improvement—using both qualitative and quantitative
data to make decisions.
Since improved organizational maturity is associated with improvement in
the range of expected results that can be achieved by an organization,
maturity is one way of predicting general outcomes of the organization’s
next project. For instance, at maturity level 2, the organization has been
elevated from ad hoc to disciplined by establishing sound project
management. As the organization achieves generic and specific goals for
the set of process areas in a maturity level, it increases its organizational
maturity and reaps the benefits of process improvement. Because each
Tying It All Together
29
CMMI for Development, Version 1.3
maturity level forms a necessary foundation for the next level, trying to skip
maturity levels is usually counterproductive.
At the same time, recognize that process improvement efforts should focus
on the needs of the organization in the context of its business environment
and that process areas at higher maturity levels can address the current
and future needs of an organization or project.
For example, organizations seeking to move from maturity level 1 to
maturity level 2 are frequently encouraged to establish a process group,
which is addressed by the Organizational Process Focus process area at
maturity level 3. Although a process group is not a necessary characteristic
of a maturity level 2 organization, it can be a useful part of the
organization’s approach to achieving maturity level 2.
This situation is sometimes characterized as establishing a maturity level 1
process group to bootstrap the maturity level 1 organization to maturity level
2. Maturity level 1 process improvement activities may depend primarily on
the insight and competence of the process group until an infrastructure to
support more disciplined and widespread improvement is in place.
Organizations can institute process improvements anytime they choose,
even before they are prepared to advance to the maturity level at which the
specific practice is recommended. In such situations, however,
organizations should understand that the success of these improvements is
at risk because the foundation for their successful institutionalization has
not been completed. Processes without the proper foundation can fail at the
point they are needed most—under stress.
A defined process that is characteristic of a maturity level 3 organization
can be placed at great risk if maturity level 2 management practices are
deficient. For example, management may commit to a poorly planned
schedule or fail to control changes to baselined requirements. Similarly,
many organizations prematurely collect the detailed data characteristic of
maturity level 4 only to find the data uninterpretable because of
inconsistencies in processes and measurement definitions.
Another example of using processes associated with higher maturity level
process areas is in the building of products. Certainly, we would expect
maturity level 1 organizations to perform requirements analysis, design,
product integration, and verification. However, these activities are not
described until maturity level 3, where they are defined as coherent, wellintegrated engineering processes. The maturity level 3 engineering process
complements a maturing project management capability put in place so that
the engineering improvements are not lost by an ad hoc management
process.
Process Areas
Process areas are viewed differently in the two representations. Figure 3.2
compares views of how process areas are used in the continuous
representation and the staged representation.
30
Tying It All Together
CMMI for Development, Version 1.3
Continuous
Target Profile
Selected Process Areas
Process Area 1
Process Area 2
Process Area 3
Process Area 4
Process Area N
CL1
CL2
CL3
Targeted Capability Levels
Staged
Selected Maturity Level
Maturity Level 5
Maturity Level 4
Maturity Level 3
Maturity Level 2
SAM
REQM
PPQA
PMC
MA
PP
CM
= Groups of process areas chosen for process improvement to achieve maturity level 3
Figure 3.2: Process Areas in the Continuous and Staged Representations
The continuous representation enables the organization to choose the
focus of its process improvement efforts by choosing those process areas,
or sets of interrelated process areas, that best benefit the organization and
its business objectives. Although there are some limits on what an
organization can choose because of the dependencies among process
areas, the organization has considerable freedom in its selection.
Tying It All Together
31
CMMI for Development, Version 1.3
To support those who use the continuous representation, process areas are
organized into four categories: Process Management, Project Management,
Engineering, and Support. These categories emphasize some of the key
relationships that exist among the process areas.
Sometimes an informal grouping of process areas is mentioned: high
maturity process areas. The four high maturity process areas are:
Organizational Process Performance, Quantitative Project Management,
Organizational Performance Management, and Causal Analysis and
Resolution. These process areas focus on improving the performance of
implemented processes that most closely relate to the organization’s
business objectives.
Once you select process areas, you must also select how much you would
like to mature processes associated with those process areas (i.e., select
the appropriate capability level). Capability levels and generic goals and
practices support the improvement of processes associated with individual
process areas. For example, an organization may wish to reach capability
level 2 in one process area and capability level 3 in another. As the
organization reaches a capability level, it sets its sights on the next
capability level for one of these same process areas or decides to widen its
view and address a larger number of process areas. Once it reaches
capability level 3 in most of the process areas, the organization can shift its
attention to the high maturity process areas and can track the capability of
each through capability level 3.
The selection of a combination of process areas and capability levels is
typically described in a “target profile.” A target profile defines all of the
process areas to be addressed and the targeted capability level for each.
This profile governs which goals and practices the organization will address
in its process improvement efforts.
Most organizations, at minimum, target capability level 1 for the process
areas they select, which requires that all of these process areas’ specific
goals be achieved. However, organizations that target capability levels
higher than 1 concentrate on the institutionalization of selected processes in
the organization by implementing generic goals and practices.
The staged representation provides a path of improvement from maturity
level 1 to maturity level 5 that involves achieving the goals of the process
areas at each maturity level. To support those who use the staged
representation, process areas are grouped by maturity level, indicating
which process areas to implement to achieve each maturity level.
For example, at maturity level 2, there is a set of process areas that an
organization would use to guide its process improvement until it could
achieve all the goals of all these process areas. Once maturity level 2 is
achieved, the organization focuses its efforts on maturity level 3 process
areas, and so on. The generic goals that apply to each process area are
also predetermined. Generic goal 2 applies to maturity level 2 and generic
goal 3 applies to maturity levels 3 through 5.
32
Tying It All Together
CMMI for Development, Version 1.3
Table 3.2 provides a list of CMMI-DEV process areas and their associated
categories and maturity levels.
Table 3.2 Process Areas, Categories, and Maturity Levels
Tying It All Together
Process Area
Category
Maturity Level
Causal Analysis and Resolution (CAR)
Support
5
Configuration Management (CM)
Support
2
Decision Analysis and Resolution
(DAR)
Support
3
Integrated Project Management (IPM)
Project
Management
3
Measurement and Analysis (MA)
Support
2
Organizational Process Definition
(OPD)
Process
Management
3
Organizational Process Focus (OPF)
Process
Management
3
Organizational Performance
Management (OPM)
Process
Management
5
Organizational Process Performance
(OPP)
Process
Management
4
Organizational Training (OT)
Process
Management
3
Product Integration (PI)
Engineering
3
Project Monitoring and Control (PMC)
Project
Management
2
Project Planning (PP)
Project
Management
2
Process and Product Quality Assurance
(PPQA)
Support
2
Quantitative Project Management
(QPM)
Project
Management
4
Requirements Development (RD)
Engineering
3
Requirements Management (REQM)
Project
Management
2
Risk Management (RSKM)
Project
Management
3
Supplier Agreement Management
(SAM)
Project
Management
2
Technical Solution (TS)
Engineering
3
33
CMMI for Development, Version 1.3
Validation (VAL)
Engineering
3
Verification (VER)
Engineering
3
Equivalent Staging
Equivalent staging is a way to compare results from using the continuous
representation to results from using the staged representation. In essence,
if you measure improvement relative to selected process areas using
capability levels in the continuous representation, how do you translate that
work into maturity levels? Is this translation possible?
Up to this point, we have not discussed process appraisals in much detail.
The SCAMPISM method8 is used to appraise organizations using CMMI, and
one result of an appraisal is a rating [SEI 2011a, Ahern 2005]. If the
continuous representation is used for an appraisal, the rating is a “capability
level profile.” If the staged representation is used for an appraisal, the rating
is a “maturity level rating” (e.g., maturity level 3).
A capability level profile is a list of process areas and the corresponding
capability level achieved for each. This profile enables an organization to
track its capability level by process area. The profile is called an
“achievement profile” when it represents the organization’s actual progress
for each process area. Alternatively, the profile is called a “target profile”
when it represents the organization’s planned process improvement
objectives.
Figure 3.3 illustrates a combined target and achievement profile. The gray
portion of each bar represents what has been achieved. The unshaded
portion represents what remains to be accomplished to meet the target
profile.
8
34
The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) method is described in Chapter 5.
Tying It All Together
CMMI for Development, Version 1.3
Requirements Management
Project Planning
Project Monitoring
and Control
Supplier Agreement
Management
Measurement and Analysis
Process and Product
Quality Assurance
Configuration Management
Capability
Level 1
Capability
Level 2
Capability
Level 3
Figure 3.3: Example Combined Target and Achievement Profile
An achievement profile, when compared with a target profile, enables an
organization to plan and track its progress for each selected process area.
Maintaining capability level profiles is advisable when using the continuous
representation.
Target staging is a sequence of target profiles that describes the path of
process improvement to be followed by the organization. When building
target profiles, the organization should pay attention to the dependencies
between generic practices and process areas. If a generic practice depends
on a process area, either to carry out the generic practice or to provide a
prerequisite work product, the generic practice can be much less effective
when the process area is not implemented.9
Although the reasons to use the continuous representation are many,
ratings consisting of capability level profiles are limited in their ability to
provide organizations with a way to generally compare themselves with
other organizations. Capability level profiles can be used if each
organization selects the same process areas; however, maturity levels have
been used to compare organizations for years and already provide
predefined sets of process areas.
Because of this situation, equivalent staging was created. Equivalent
staging enables an organization using the continuous representation to
convert a capability level profile to the associated maturity level rating.
9
See Table 6.2 in the Generic Goals and Generic Practices section of Part Two for more information about the dependencies
between generic practices and process areas.
Tying It All Together
35
CMMI for Development, Version 1.3
The most effective way to depict equivalent staging is to provide a
sequence of target profiles, each of which is equivalent to a maturity level
rating of the staged representation reflected in the process areas listed in
the target profile. The result is a target staging that is equivalent to the
maturity levels of the staged representation.
Figure 3.4 shows a summary of the target profiles that must be achieved
when using the continuous representation to be equivalent to maturity
levels 2 through 5. Each shaded area in the capability level columns
represents a target profile that is equivalent to a maturity level.
Name
Abbr.
ML
Configuration Management
CM
2
Measurement and Analysis
MA
2
Project Monitoring and Control
PMC
2
Project Planning
PP
2
Process and Product Quality Assurance
PPQA
2
Requirements Management
REQM
2
Supplier Agreement Management
SAM
2
Decision Analysis and Resolution
DAR
3
Integrated Project Management
IPM
3
Organizational Process Definition
OPD
3
Organizational Process Focus
OPF
3
Organizational Training
OT
3
Product Integration
PI
3
Requirements Development
RD
3
Risk Management
RSKM
3
Technical Solution
TS
3
Validation
VAL
3
Verification
VER
3
Organizational Process Performance
OPP
4
Quantitative Project Management
QPM
4
Causal Analysis and Resolution
CAR
5
Organizational Performance Management
OPM
5
CL1
CL2
CL3
Target
Profile 2
Target
Profile 3
Target
Profile 4
Target
Profile 5
Figure 3.4: Target Profiles and Equivalent Staging
The following rules summarize equivalent staging:
To achieve maturity level 2, all process areas assigned to maturity level
2 must achieve capability level 2 or 3.
To achieve maturity level 3, all process areas assigned to maturity
levels 2 and 3 must achieve capability level 3.
36
Tying It All Together
CMMI for Development, Version 1.3
To achieve maturity level 4, all process areas assigned to maturity
levels 2, 3, and 4 must achieve capability level 3.
To achieve maturity level 5, all process areas must achieve capability
level 3.
Achieving High Maturity
When using the staged representation, you attain high maturity when you
achieve maturity level 4 or 5. Achieving maturity level 4 involves
implementing all process areas for maturity levels 2, 3, and 4. Likewise,
achieving maturity level 5 involves implementing all process areas for
maturity levels 2, 3, 4, and 5.
When using the continuous representation, you attain high maturity using
the equivalent staging concept. High maturity that is equivalent to staged
maturity level 4 using equivalent staging is attained when you achieve
capability level 3 for all process areas except for Organizational
Performance Management (OPM) and Causal Analysis and Resolution
(CAR). High maturity that is equivalent to staged maturity level 5 using
equivalent staging is attained when you achieve capability level 3 for all
process areas.
Tying It All Together
37
CMMI for Development, Version 1.3
38
Tying It All Together
CMMI for Development, Version 1.3
4 Relationships Among Process Areas
In this chapter we describe the key relationships among process areas to
help you see the organization’s view of process improvement and how
process areas depend on the implementation of other process areas.
The relationships among multiple process areas, including the information
and artifacts that flow from one process area to another—illustrated by the
figures and descriptions in this chapter—help you to see a larger view of
process implementation and improvement.
Successful process improvement initiatives must be driven by the business
objectives of the organization. For example, a common business objective
is to reduce the time it takes to get a product to market. The process
improvement objective derived from that might be to improve the project
management processes to ensure on-time delivery; those improvements
rely on best practices in the Project Planning and Project Monitoring and
Control process areas.
Although we group process areas in this chapter to simplify the discussion
of their relationships, process areas often interact and have an effect on
one another regardless of their group, category, or level. For example, the
Decision Analysis and Resolution process area (a Support process area at
maturity level 3) contains specific practices that address the formal
evaluation process used in the Technical Solution process area for
selecting a technical solution from alternative solutions.
Being aware of the key relationships that exist among CMMI process areas
will help you apply CMMI in a useful and productive way. Relationships
among process areas are described in more detail in the references of each
process area and specifically in the Related Process Areas section of each
process area in Part Two. Refer to Chapter 2 for more information about
references.
Process Management
Process Management process areas contain the cross-project activities
related to defining, planning, deploying, implementing, monitoring,
controlling, appraising, measuring, and improving processes.
The five Process Management process areas in CMMI-DEV are as follows:
Organizational Process Definition (OPD)
Organizational Process Focus (OPF)
Organizational Performance Management (OPM)
Relationships Among Process Areas
39
CMMI for Development, Version 1.3
Organizational Process Performance (OPP)
Organizational Training (OT)
Basic Process Management Process Areas
The Basic Process Management process areas provide the organization
with a capability to document and share best practices, organizational
process assets, and learning across the organization.
O
p rg
an roc aniz
d ess at
ob n io
je ee n’s
ct d
ive s
s
Figure 4.1 provides a bird’s-eye view of the interactions among the Basic
Process Management process areas and with other process area
categories. As illustrated in Figure 4.1, the Organizational Process Focus
process area helps the organization to plan, implement, and deploy
organizational process improvements based on an understanding of the
current strengths and weaknesses of the organization’s processes and
process assets.
Senior
management
Organization’s
business
objectives
OPF
Training for projects and
support groups in standard
process and assets
OT
Standard
process
and other
assets
Resources and
coordination
OPD
Tra
inin
gn
eed
s
Standard process, work,
environment standards, and
other assets
Project Management,
Support, and Engineering
process areas
Improvement information
(e.g., lessons learned, data,
and artifacts
Process improvement proposals; participation in
defining, assessing, and deploying processes
OPD = Organizational Process Definition
OPF = Organizational Process Focus
OT = Organizational Training
Figure 4.1: Basic Process Management Process Areas
Candidate improvements to the organization’s processes are obtained
through various sources. These activities include process improvement
proposals, measurement of the processes, lessons learned in implementing
the processes, and results of process appraisal and product evaluation
activities.
40
Relationships Among Process Areas
CMMI for Development, Version 1.3
The Organizational Process Definition process area establishes and
maintains the organization’s set of standard processes, work environment
standards, and other assets based on the process needs and objectives of
the organization. These other assets include descriptions of lifecycle
models, process tailoring guidelines, and process related documentation
and data.
Projects tailor the organization’s set of standard processes to create their
defined processes. The other assets support tailoring as well as
implementation of the defined processes.
Experiences and work products from performing these defined processes,
including measurement data, process descriptions, process artifacts, and
lessons learned, are incorporated as appropriate into the organization’s set
of standard processes and other assets.
The Organizational Training process area identifies the strategic training
needs of the organization as well as the tactical training needs that are
common across projects and support groups. In particular, training is
developed or obtained to develop the skills required to perform the
organization’s set of standard processes. The main components of training
include a managed training development program, documented plans, staff
with appropriate knowledge, and mechanisms for measuring the
effectiveness of the training program.
Advanced Process Management Process Areas
The Advanced Process Management process areas provide the
organization with an improved capability to achieve its quantitative
objectives for quality and process performance.
Figure 4.2 provides a bird’s-eye view of the interactions among the
Advanced Process Management process areas and with other process
area categories. Each of the Advanced Process Management process
areas depends on the ability to develop and deploy processes and
supporting assets. The Basic Process Management process areas provide
this ability.
Relationships Among Process Areas
41
CMMI for Development, Version 1.3
Improvements
Organization
ce
an
m
r
rfo lity
Pe pabi
ca
Senior
management
Business objectives
fit
ne ted
b e il o s
nd p nt
t a rom me
os f e
C ata rov
d p
im
OPM
Quality and process
measures, baselines,
Performance objectives,
and models
OPP
Project Management,
Support, and Engineering
process areas
Quality and process
objectives
on
mm res
Co easu
m
Ability to develop and
deploy standard process
and other assets
Performance
capability data
Basic
Process Management
process areas
OPM = Organizational Performance Management
OPP = Organizational Process Performance
Figure 4.2: Advanced Process Management Process Areas
As illustrated in Figure 4.2, the Organizational Process Performance
process area derives quantitative objectives for quality and process
performance from the organization’s business objectives. The organization
provides projects and support groups with common measures, process
performance baselines, and process performance models.
These additional organizational assets support composing a defined
process that can achieve the project’s quality and process performance
objectives and support quantitative management. The organization
analyzes the process performance data collected from these defined
processes to develop a quantitative understanding of product quality,
service quality, and process performance of the organization’s set of
standard processes.
In Organizational Performance Management, process performance
baselines and models are analyzed to understand the organization’s ability
to meet its business objectives and to derive quality and process
performance objectives. Based on this understanding, the organization
proactively selects and deploys incremental and innovative improvements
that measurably improve the organization’s performance.
The selection of improvements to deploy is based on a quantitative
understanding of the likely benefits and predicted costs of deploying
42
Relationships Among Process Areas
CMMI for Development, Version 1.3
candidate improvements. The organization can also adjust business
objectives and quality and process performance objectives as appropriate.
Project Management
Project Management process areas cover the project management
activities related to planning, monitoring, and controlling the project.
The seven Project Management process areas in CMMI-DEV are as
follows:
Integrated Project Management (IPM)
Project Monitoring and Control (PMC)
Project Planning (PP)
Quantitative Project Management (QPM)
Requirements Management (REQM)
Risk Management (RSKM)
Supplier Agreement Management (SAM)
Basic Project Management Process Areas
The Basic Project Management process areas address the activities related
to establishing and maintaining the project plan, establishing and
maintaining commitments, monitoring progress against the plan, taking
corrective action, and managing supplier agreements.
Figure 4.3 provides a bird’s-eye view of the interactions among the Basic
Project Management process areas and with other process area categories.
As illustrated in Figure 4.3, the Project Planning process area includes
developing the project plan, involving relevant stakeholders, obtaining
commitment to the plan, and maintaining the plan.
Relationships Among Process Areas
43
CMMI for Development, Version 1.3
Status, issues, and results of process and
product evaluations; measures and analyses
Corrective action
PMC
Corrective action
What to
monitor
Replan
t
en
n
d
an po
ct com s
u
d t
nt
Prooduc eme
pr quir
re
REQM
Product and
product
component
requirements
What to build
Status, issues,
and results of
reviews and
monitoring
Plans
SAM
Supplier
agreement
PP
What to do
Commitments
Engineering and Support
process areas
Measurement
needs
Product component requirements, technical
issues, completed product components, and
acceptance reviews and tests
Supplier
PMC = Project Monitoring and Control
PP = Project Planning
REQM = Requirements Management
SAM = Supplier Agreement Management
Figure 4.3: Basic Project Management Process Areas
Planning begins with requirements that define the product and project
(“What to Build” in Figure 4.3). The project plan covers the various project
management and development activities performed by the project. The
project reviews other plans that affect the project from various relevant
stakeholders and establishes commitments with those stakeholders for their
contributions to the project. For example, these plans cover configuration
management, verification, and measurement and analysis.
The Project Monitoring and Control process area contains practices for
monitoring and controlling activities and taking corrective action. The project
plan specifies the frequency of progress reviews and the measures used to
monitor progress. Progress is determined primarily by comparing project
status to the plan. When the actual status deviates significantly from the
expected values, corrective actions are taken as appropriate. These actions
can include replanning, which requires using Project Planning practices.
The Requirements Management process area maintains the requirements.
It describes activities for obtaining and controlling requirement changes and
ensuring that other relevant plans and data are kept current. It provides
44
Relationships Among Process Areas
CMMI for Development, Version 1.3
traceability of requirements from customer requirements to product
requirements to product component requirements.
Requirements Management ensures that changes to requirements are
reflected in project plans, activities, and work products. This cycle of
changes can affect the Engineering process areas; thus, requirements
management is a dynamic and often recursive sequence of events. The
Requirements Management process area is fundamental to a controlled
and disciplined engineering process.
The Supplier Agreement Management process area addresses the need of
the project to acquire those portions of work that are produced by suppliers.
Sources of products that can be used to satisfy project requirements are
proactively identified. The supplier is selected, and a supplier agreement is
established to manage the supplier.
The supplier’s progress and performance are tracked as specified in the
supplier agreement, and the supplier agreement is revised as appropriate.
Acceptance reviews and tests are conducted on the supplier-produced
product component.
Advanced Project Management Process Areas
The Advanced Project Management process areas address activities such
as establishing a defined process that is tailored from the organization’s set
of standard processes, establishing the project work environment from the
organization’s work environment standards, coordinating and collaborating
with relevant stakeholders, forming and sustaining teams for the conduct of
projects, quantitatively managing the project, and managing risk.
Figure 4.4 provides a bird’s-eye view of the interactions among the
Advanced Project Management process areas and with other process area
categories. Each Advanced Project Management process area depends on
the ability to plan, monitor, and control the project. The Basic Project
Management process areas provide this ability.
Relationships Among Process Areas
45
CMMI for Development, Version 1.3
Statistical management data
Quantitative objectives,
subprocesses to statistically
manage, project’s composed
and defined process
Organization’s standard processes,
work environment standards, and
supporting assets
QPM
Risk exposure due to
unstable processes
RSKM
IPM
Process Management
process areas
Product architecture
for structuring teams
Risk taxonomies
and parameters,
risk status, risk
mitigation plans,
and corrective
action
Project’s defined
process and work
environment
Coordination,
commitments, and issues
to resolve
Teams for performing engineering
and support processes
Engineering and Support
process areas
Basic Project Management
process areas
IPM= Integrated Project Management
QPM = Quantitative Project Management
RSKM = Risk Management
Figure 4.4: Advanced Project Management Process Areas
The Integrated Project Management process area establishes and
maintains the project’s defined process that is tailored from the
organization’s set of standard processes (Organizational Process
Definition). The project is managed using the project’s defined process.
The project uses and contributes to the organizational process assets, the
project’s work environment is established and maintained from the
organization’s work environment standards, and teams are established
using the organization’s rules and guidelines. The project’s relevant
stakeholders coordinate their efforts in a timely manner through the
identification, negotiation, and tracking of critical dependencies and the
resolution of coordination issues.
Although risk identification and monitoring are covered in the Project
Planning and Project Monitoring and Control process areas, the Risk
Management process area takes a continuing, forward-looking approach to
managing risks with activities that include identification of risk parameters,
risk assessments, and risk mitigation.
46
Relationships Among Process Areas
CMMI for Development, Version 1.3
The Quantitative Project Management process area establishes objectives
for quality and process performance, composes a defined process that can
help achieve those objectives, and quantitatively manages the project. The
project’s quality and process performance objectives are based on the
objectives established by the organization and the customer.
The project’s defined process is composed using statistical and other
quantitati...
Purchase answer to see full
attachment