Attachment_A.PDF

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 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-C-

0003 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 royalty-free 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: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.

mailto:permission@sei.cmu.edu http://www.sei.cmu.edu/library

CMMI for Development, Version 1.3

Preface i

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.

CMMI-DEV is based on the CMMI Model

Foundation or CMF (i.e., model components common to all CMMI models and constellations ) 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.

The CMMI Framework is the basic structure that organizes CMMI components and combines them into CMMI constellations and models.

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).

ii Preface

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 A-

Specification 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.

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.

Chapter 3, Tying It All Together, assembles the model components and explains the concepts of maturity levels and capability levels.

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.

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.

Preface iii

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 CMMI-

DEV 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 iv Preface 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).

Preface v

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.

http://www.sei.cmu.edu/cmmi/tools/cmmiv1-3/ http://www.sei.cmu.edu/cmmi/ http://www.sei.cmu.edu/cmmi/tools/cr/ mailto:cmmi-comments@sei.cmu.edu vi Preface

Table of Contents vii

Table of Contents

Preface ii Purpose i Acknowledgments i Audience ii Organization of this Document ii How to Use this Document iii

Readers New to Process Improvement iii Readers Experienced with Process Improvement iv Readers Familiar with CMMI iv

Additional Information and Reader Feedback v

Part One: About CMMI for Development 1

1 Introduction 3 About Process Improvement 4 About Capability Maturity Models 5 Evolution of CMMI 5 CMMI Framework 7 CMMI for Development 7

2 Process Area Components 9 Core Process Areas and CMMI Models 9 Required, Expected, and Informative Components 9

Required Components 9 Expected Components 9 Informative Components 10

Components Associated with Part Two 10 Process Areas 11 Purpose Statements 11 Introductory Notes 11 Related Process Areas 12 Specific Goals 12 Generic Goals 12 Specific Goal and Practice Summaries 12 Specific Practices 13 Example Work Products 13 Subpractices 13 Generic Practices 13 Generic Practice Elaborations 14 Additions 14

Supporting Informative Components 14 Notes 14 Examples 14 References 15

Numbering Scheme 15 Typographical Conventions 16

3 Tying It All Together 21 Understanding Levels 21 Structures of the Continuous and Staged Representations 22 viii Table of Contents

Understanding Capability Levels 24 Capability Level 0: Incomplete 24 Capability Level 1: Performed 24 Capability Level 2: Managed 25 Capability Level 3: Defined 25 Advancing Through Capability Levels 25

Understanding Maturity Levels 26 Maturity Level 1: Initial 27 Maturity Level 2: Managed 27 Maturity Level 3: Defined 28 Maturity Level 4: Quantitatively Managed 28 Maturity Level 5: Optimizing 29 Advancing Through Maturity Levels 29

Process Areas 30 Equivalent Staging 34 Achieving High Maturity 37

4 Relationships Among Process Areas 39 Process Management 39

Basic Process Management Process Areas 40 Advanced Process Management Process Areas 41

Project Management 43 Basic Project Management Process Areas 43 Advanced Project Management Process Areas 45

Engineering 47 Recursion and Iteration of Engineering Processes 50 Support 50

Basic Support Process Areas 51 Advanced Support Process Areas 52

5 Using CMMI Models 55 Adopting CMMI 55 Your Process Improvement Program 56 Selections that Influence Your Program 56 CMMI Models 57 Interpreting CMMI When Using Agile Approaches 58 Using CMMI Appraisals 59 Appraisal Requirements for CMMI 59 SCAMPI Appraisal Methods 59 Appraisal Considerations 60 CMMI Related Training 61

Part Two: Generic Goals and Generic Practices, and the Process Areas 63

Generic Goals and Generic Practices 65 Overview 65 Process Institutionalization 65

Performed Process 65 Managed Process 66 Defined Process 66 Relationships Among Processes 67

Generic Goals and Generic Practices 68 Applying Generic Practices 120 Process Areas that Support Generic Practices 121

Table of Contents ix

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 415 Information Assurance/Information Security Related Sources 419

Appendix B: Acronyms 421

Appendix C: CMMI Version 1.3 Project Participants 425 CMMI Steering Group 425

Steering Group Members 425 Ex-Officio Steering Group Members 426 Steering Group Support 426

CMMI for Services Advisory Group 426 CMMI V1.3 Coordination Team 427 CMMI V1.3 Configuration Control Board 427 CMMI V1.3 Core Model Team 428 CMMI V1.3 Translation Team 428 CMMI V1.3 High Maturity Team 429 CMMI V1.3 Acquisition Mini Team 429 CMMI V1.3 Services Mini Team 429 CMMI V1.3 SCAMPI Upgrade Team 430 CMMI Version 1.3 Training Teams 430

ACQ and DEV Training Team 430 x Table of Contents

SVC Training Team 431 CMMI V1.3 Quality Team 431

Appendix D: Glossary 433

Part One:

About CMMI for Development

Introduction 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.

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.

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 4

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

Tools and equipment

People with skills, training, and motivation

A

B

C

D

PROCESS

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.

Introduction 5

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 6 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.

v1.02 (2000)V1.02 (2000) v1.1 (2002)V1.1 (2002)

History of CMMs

CMM for Software V1.1 (1993)

Systems Engineering

CMM V1.1 (1995)

EIA 731 SECM

(1998)

INCOSE SECAM

(1996)

Integrated Product Development CMM (1997)

Software CMM V2, draft C (1997)

CMMI for Development V1.2 (2006)

CMMI for Acquisition V1.2 (2007)

Software Acquisition

CMM V1.03 (2002)

V1.2 (2009) CMMI for Services

CMMI for Acquisition

V1.3 (2010)

CMMI for Development

V1.3 (2010)

CMMI for Services

V1.3 (2010)

Figure 1.2: The History of CMMs

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.

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 7

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 8

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.

Process Area Components 9

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 10

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

Generic PracticesGeneric Practices

Generic GoalsGeneric Goals

Expected InformativeInformativeRequiredKEY:

Purpose

Statement Introductory

Notes

Related

Process Areas

SubpracticesSubpractices

Specific GoalsSpecific Goals

Specific PracticesSpecific Practices

Typical Work

Products

Example Work

Products SubpracticesSubpractices Subpractices

Generic Practice

Elaborations

Figure 2.1: CMMI Model Components

The following sections provide detailed descriptions of CMMI model components.

Process Area Components 11

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 12

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.

Process Area Components 13

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 14 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.

Process Area Components 15

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 16

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.

Process Area Components 17

Figure 2.2: Sample Page from Decision Analysis and Resolution

Process Area Name

Process Area Category

Maturity Level

Purpose Statement

Introductory Notes

Process Area Components 18

Figure 2.3: Sample Page from Causal Analysis and Resolution

Reference

Subpractice

Example Work Product

Specific Goal

Specific Practice

Example Box

Process Area Components 19

Figure 2.4: Sample Page from the Generic Goals and Generic Practices

Generic Goal

Elaboration

Process Area Components 20

Tying It All Together 21

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.

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.”

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 22

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.

Process Areas

Capability Levels

Continuous Representation

Generic Practices

Generic GoalsSpecific Goals

Specific Practices

Maturity Levels

Staged Representation

Generic Practices

Generic GoalsSpecific Goals

Specific Practices

Process Areas

Figure 3.1: Structure of the Continuous and Staged Representations

Tying It All Together 23

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…