Click to Print Print
suggested options:
Only the selected frame

CMMI® for Development, Version 1.3 - Hyperlinked

 

Very useful but "AS IS". Please see Disclaimer of Disclaimer of Warranties.

 

Generic Goals and Generic Practices

Causal Analysis and Resolution

Configuration Management

Decision Analysis and Resolution

Integrated Project Management

Measurement and Analysis

Organizational Process Definition

Organizational Process Focus

Organizational Performance Management

Organizational Process Performance

Organizational Training

Product Integration

Project Monitoring and Control

Project Planning

Process and Product Quality Assurance

Quantitative Project Management

Requirements Development

Requirements Management

Risk Management

Supplier Agreement Management

Technical Solution

Validation

Verification

Glossary

For questions on this hyperlinked version, contact EPPICT, LLC (Expert Process Performance Improvement Consulting and Training, LLC) at Diane.Mizukami-Williams@hotmail.com.

 

 

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

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

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

SVC Training Team   431

CMMI V1.3 Quality Team   431

Appendix D: Glossary  433


 


 

 

 

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

 

 

 

 


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 constellations[2]) 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 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.[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.

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

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.


 


 

 

 

 


 


Part One:

About CMMI for Development


 


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.

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.

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.

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

Figure 1.2: The History of CMMs[6]

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.

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.

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.


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.

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.

Figure 2.1: CMMI Model Components

The following sections provide detailed descriptions of CMMI model components.

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.

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.

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

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.

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.

Figure 2.2: Sample Page from Decision Analysis and Resolution

Figure 2.3: Sample Page from Causal Analysis and Resolution

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

 


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

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.

Figure 3.1: Structure of the Continuous and Staged Representations

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.

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.

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.

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.

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.

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.

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 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, well-integrated 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.

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.

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.

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

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

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 method[8] 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.

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.

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

CL1

CL2

CL3

Configuration Management

CM

2

 

Target Profile 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

Target
Profile 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


Target
Profile 4

Quantitative Project Management

QPM

4

Causal Analysis and Resolution

CAR

5


Target
Profile 5

Organizational Performance Management

OPM

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.

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



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)

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

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.

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.

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.

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

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

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.

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 quantitative techniques. Such an analysis enables the project to predict whether it will achieve its quality and process performance objectives.

Based on the prediction, the project can adjust the defined process or can negotiate changes to quality and process performance objectives. As the project progresses, the performance of selected subprocesses is carefully monitored to help evaluate whether the project is on track to achieving its objectives.

Engineering

Engineering process areas cover the development and maintenance activities that are shared across engineering disciplines. The Engineering process areas were written using general engineering terminology so that any technical discipline involved in the product development process (e.g., software engineering, mechanical engineering) can use them for process improvement.

The Engineering process areas also integrate the processes associated with different engineering disciplines into a single product development process, supporting a product oriented process improvement strategy. Such a strategy targets essential business objectives rather than specific technical disciplines. This approach to processes effectively avoids the tendency toward an organizational “stovepipe” mentality.

The Engineering process areas apply to the development of any product or service in the development domain (e.g., software products, hardware products, services, processes).

The five Engineering process areas in CMMI-DEV are as follows:

·        Product Integration (PI)

·        Requirements Development (RD)

·        Technical Solution (TS)

·        Validation (VAL)

·        Verification (VER)

Figure 4.5 provides a bird’s-eye view of the interactions among the six Engineering process areas.

Figure 4.5: Engineering Process Areas

The Requirements Development process area identifies customer needs and translates these needs into product requirements. The set of product requirements is analyzed to produce a high-level conceptual solution. This set of requirements is then allocated to establish an initial set of product component requirements.

Other requirements that help define the product are derived and allocated to product components. This set of product and product component requirements clearly describes the product’s performance, quality attributes, design features, verification requirements, etc., in terms the developer understands and uses.

The Requirements Development process area supplies requirements to the Technical Solution process area, where the requirements are converted into the product architecture, product component designs, and product components (e.g., by coding, fabrication). Requirements are also supplied to the Product Integration process area, where product components are combined and interfaces are verified to ensure that they meet the interface requirements supplied by Requirements Development.

The Technical Solution process area develops technical data packages for product components to be used by the Product Integration or Supplier Agreement Management process area. Alternative solutions are examined to select the optimum design based on established criteria. These criteria can be significantly different across products, depending on product type, operational environment, performance requirements, support requirements, and cost or delivery schedules. The task of selecting the final solution makes use of the specific practices in the Decision Analysis and Resolution process area.

The Technical Solution process area relies on the specific practices in the Verification process area to perform design verification and peer reviews during design and prior to final build.

The Verification process area ensures that selected work products meet the specified requirements. The Verification process area selects work products and verification methods that will be used to verify work products against specified requirements. Verification is generally an incremental process, starting with product component verification and usually concluding with verification of fully assembled products.

Verification also addresses peer reviews. Peer reviews are a proven method for removing defects early and provide valuable insight into the work products and product components being developed and maintained.

The Validation process area incrementally validates products against the customer’s needs. Validation can be performed in the operational environment or in a simulated operational environment. Coordination with the customer on validation requirements is an important element of this process area.

The scope of the Validation process area includes validation of products, product components, selected intermediate work products, and processes. These validated elements can often require reverification and revalidation. Issues discovered during validation are usually resolved in the Requirements Development or Technical Solution process area.

The Product Integration process area contains the specific practices associated with generating an integration strategy, integrating product components, and delivering the product to the customer.

Product Integration uses the specific practices of both Verification and Validation in implementing the product integration process. Verification practices verify the interfaces and interface requirements of product components prior to product integration. Interface verification is an essential event in the integration process. During product integration in the operational environment, the specific practices of the Validation process area are used.

Recursion and Iteration of Engineering Processes

Most process standards agree that there are two ways that processes can be applied. These two ways are called recursion and iteration.

Recursion occurs when a process is applied to successive levels of system elements within a system structure. The outcomes of one application are used as inputs to the next level in the system structure. For example, the verification process is designed to apply to the entire assembled product, the major product components, and even components of components. How far into the product you apply the verification process depends entirely on the size and complexity of the end product.

Iteration occurs when processes are repeated at the same system level. New information is created by the implementation of one process that feeds that information back into a related process. This new information typically raises questions that must be resolved before completing the processes.

For example, iteration will most likely occur between requirements development and technical solution. Reapplication of the processes can resolve the questions that are raised. Iteration can ensure quality prior to applying the next process.

Engineering processes (e.g., requirements development, verification) are implemented repeatedly on a product to ensure that these engineering processes have been adequately addressed before delivery to the customer. Further, engineering processes are applied to components of the product.

For example, some questions that are raised by processes associated with the Verification and Validation process areas can be resolved by processes associated with the Requirements Development or Product Integration process area. Recursion and iteration of these processes enable the project to ensure quality in all components of the product before it is delivered to the customer.

The project management process areas can likewise be recursive because sometimes projects are nested within projects.

Support

Support process areas cover the activities that support product development and maintenance. The Support process areas address processes that are used in the context of performing other processes. In general, the Support process areas address processes that are targeted toward the project and can address processes that apply more generally to the organization.

For example, Process and Product Quality Assurance can be used with all the process areas to provide an objective evaluation of the processes and work products described in all the process areas.

The five Support process areas in CMMI-DEV are as follows:

·        Causal Analysis and Resolution (CAR)

·        Configuration Management (CM)

·        Decision Analysis and Resolution (DAR)

·        Measurement and Analysis (MA)

·        Process and Product Quality Assurance (PPQA)

Basic Support Process Areas

The Basic Support process areas address fundamental support functions that are used by all process areas. Although all Support process areas rely on the other process areas for input, the Basic Support process areas provide support functions that also help implement several generic practices.

Figure 4.6 provides a bird’s-eye view of the interactions among the Basic Support process areas and with all other process areas.

Figure 4.6: Basic Support Process Areas

The Measurement and Analysis process area supports all process areas by providing specific practices that guide projects and organizations in aligning measurement needs and objectives with a measurement approach that is used to support management information needs. The results can be used in making informed decisions and taking appropriate corrective actions.

The Process and Product Quality Assurance process area supports all process areas by providing specific practices for objectively evaluating performed processes, work products, and services against the applicable process descriptions, standards, and procedures, and ensuring that any issues arising from these reviews are addressed.

Process and Product Quality Assurance supports the delivery of high quality products and services by providing the project staff and all levels of management with appropriate visibility into, and feedback on, the processes and associated work products throughout the life of the project.

The Configuration Management process area supports all process areas by establishing and maintaining the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits. The work products placed under configuration management include the products that are delivered to the customer, designated internal work products, acquired products, tools, and other items that are used in creating and describing these work products.

Examples of work products that can be placed under configuration management include plans, process descriptions, requirements, design data, drawings, product specifications, code, compilers, product data files, and product technical publications.

Advanced Support Process Areas

The Advanced Support process areas provide the projects and organization with an improved support capability. Each of these process areas relies on specific inputs or practices from other process areas.

Figure 4.7 provides a bird’s-eye view of the interactions among the Advanced Support process areas and with all other process areas.

Figure 4.7: Advanced Support Process Areas

Using the Causal Analysis and Resolution process area, project members identify causes of selected outcomes and take action to prevent negative outcomes from occurring in the future or to leverage positive outcomes. While the project’s defined processes are the initial targets for root cause analysis and action plans, effective process changes can result in process improvement proposals submitted to the organization’s set of standard processes.

The Decision Analysis and Resolution process area supports all the process areas by determining which issues should be subjected to a formal evaluation process and then applying a formal evaluation process to them.

 



5      Using CMMI Models

The complexity of products today demands an integrated view of how organizations do business. CMMI can reduce the cost of process improvement across enterprises that depend on multiple functions or groups to achieve their objectives.

To achieve this integrated view, the CMMI Framework includes common terminology, common model components, common appraisal methods, and common training materials. This chapter describes how organizations can use the CMMI Product Suite not only to improve their quality, reduce their costs, and optimize their schedules, but also to gauge how well their process improvement program is working.

Adopting CMMI

Research has shown that the most powerful initial step to process improvement is to build organizational support through strong senior management sponsorship. To gain the sponsorship of senior management, it is often beneficial to expose them to the performance results experienced by others who have used CMMI to improve their processes [Gibson 2006].

For more information about CMMI performance results, see the SEI website at http://www.sei.cmu.edu/cmmi/research/results/.

The senior manager, once committed as the process improvement sponsor, must be actively involved in the CMMI-based process improvement effort. Activities performed by the senior management sponsor include but are not limited to the following:

·        Influence the organization to adopt CMMI

·        Choose the best people to manage the process improvement effort

·        Monitor the process improvement effort personally

·        Be a visible advocate and spokesperson for the process improvement effort

·        Ensure that adequate resources are available to enable the process improvement effort to be successful

Given sufficient senior management sponsorship, the next step is establishing a strong, technically competent process group that represents relevant stakeholders to guide process improvement efforts [Ahern 2008, Dymond 2005].

For an organization with a mission to develop software-intensive systems, the process group might include those who represent different disciplines across the organization and other selected members based on the business needs driving improvement. For example, a systems administrator may focus on information technology support, whereas a marketing representative may focus on integrating customers’ needs. Both members could make powerful contributions to the process group.

Once your organization decides to adopt CMMI, planning can begin with an improvement approach such as the IDEALSM (Initiating, Diagnosing, Establishing, Acting, and Learning) model [McFeeley 1996]. For more information about the IDEAL model, see the SEI website at http://www.sei.cmu.edu/library/abstracts/reports/96hb001.cfm.

Your Process Improvement Program

Use the CMMI Product Suite to help establish your organization’s process improvement program. Using the product suite for this purpose can be a relatively informal process that involves understanding and applying CMMI best practices to your organization. Or, it can be a formal process that involves extensive training, creation of a process improvement infrastructure, appraisals, and more.

Selections that Influence Your Program

You must make three selections to apply CMMI to your organization for process improvement:

1.       Select a part of the organization.

2.       Select a model.

3.       Select a representation.

Selecting the projects to be involved in your process improvement program is critical. If you select a group that is too large, it may be too much for the initial improvement effort. The selection should also consider organizational, product, and work homogeneity (i.e., whether the group’s members all are experts in the same discipline, whether they all work on the same product or business line, and so on).

Selecting an appropriate model is also essential to a successful process improvement program. The CMMI-DEV model focuses on activities for developing quality products and services. The CMMI-ACQ model focuses on activities for initiating and managing the acquisition of products and services. The CMMI-SVC model focuses on activities for providing quality services to the customer and end users. When selecting a model, appropriate consideration should be given to the primary focus of the organization and projects, as well as to the processes necessary to satisfy business objectives. The lifecycle processes (e.g., conception, design, manufacture, deployment, operations, maintenance, disposal) on which an organization concentrates should also be considered when selecting an appropriate model.

Select the representation (capability or maturity levels) that fits your concept of process improvement. Regardless of which you choose, you can select nearly any process area or group of process areas to guide improvement, although dependencies among process areas should be considered when making such a selection.

As process improvement plans and activities progress, other important selections must be made, including whether to use an appraisal, which appraisal method should be used, which projects should be appraised, how training for staff should be secured, and which staff members should be trained.

CMMI Models

CMMI models describe best practices that organizations have found to be productive and useful to achieving their business objectives. Regardless of your organization, you must use professional judgment when interpreting CMMI best practices for your situation, needs, and business objectives.

This use of judgment is reinforced when you see words such as “adequate,” “appropriate,” or “as needed” in a goal or practice. These words are used for activities that may not be equally relevant in all situations. Interpret these goals and practices in ways that work for your organization.

Although process areas depict the characteristics of an organization committed to process improvement, you must interpret the process areas using an in-depth knowledge of CMMI, your organization, the business environment, and the specific circumstances involved.

As you begin using a CMMI model to improve your organization’s processes, map your real world processes to CMMI process areas. This mapping enables you to initially judge and later track your organization’s level of conformance to the CMMI model you are using and to identify opportunities for improvement.

To interpret practices, it is important to consider the overall context in which these practices are used and to determine how well the practices satisfy the goals of a process area in that context. CMMI models do not prescribe nor imply processes that are right for any organization or project. Instead, CMMI describes minimal criteria necessary to plan and implement processes selected by the organization for improvement based on business objectives.

CMMI practices purposely use nonspecific phrases such as “relevant stakeholders,” “as appropriate,” and “as necessary” to accommodate the needs of different organizations and projects. The specific needs of a project can also differ at various points in its life.

Interpreting CMMI When Using Agile Approaches

CMMI practices are designed to provide value across a range of different situations and thus are stated in general terms. Because CMMI does not endorse any particular approach to development, little information that is approach-specific is provided. Therefore, those who don’t have prior experience implementing CMMI in situations similar to the one they are now in may find interpretation non-intuitive.

To help those who use Agile methods to interpret CMMI practices in their environments, notes have been added to selected process areas. These notes are added, usually in the introductory notes, to the following process areas in CMMI-DEV: CM, PI, PMC, PP, PPQA, RD, REQM, RSKM, TS, and VER.

All of the notes begin with the words, “In Agile environments” and are in example boxes to help you to easily recognize them and remind you that these notes are examples of how to interpret practices and therefore are neither necessary nor sufficient for implementing the process area.

Multiple Agile approaches exist. The phrases “Agile environment” and “Agile method” are shorthand for any development or management approach that adheres to the Manifesto for Agile Development [Beck 2001].

Such approaches are characterized by the following:

·         Direct involvement of the customer in product development

·         Use of multiple development iterations to learn about and evolve the product

·         Customer willingness to share in the responsibility for decisions and risk

Many development and management approaches can share one or more of these characteristics and yet not be called “Agile.” For example, some teams are arguably “Agile” even though the term Agile is not used. Even if you are not using an Agile approach, you might still find value in these notes.

Be cautious when using these notes. Your ultimate interpretation of the process area should fit the specifics of your situation, including your organization’s business, project, work group, or team objectives, while fully meeting a CMMI process area’s goals and practices. As mentioned earlier, the notes should be taken as examples and are neither necessary nor sufficient to implementing the process area.

Some general background and motivation for the guidance given on Agile development approaches are found in the SEI technical note CMMI or Agile: Why Not Embrace Both! [Glazer 2008].

Using CMMI Appraisals

Many organizations find value in measuring their progress by conducting an appraisal and earning a maturity level rating or a capability level achievement profile. These types of appraisals are typically conducted for one or more of the following reasons:

·        To determine how well the organization’s processes compare to CMMI best practices and identify areas where improvement can be made

·        To inform external customers and suppliers about how well the organization’s processes compare to CMMI best practices

·        To meet the contractual requirements of one or more customers

Appraisals of organizations using a CMMI model must conform to the requirements defined in the Appraisal Requirements for CMMI (ARC) [SEI 2011b] document. Appraisals focus on identifying improvement opportunities and comparing the organization’s processes to CMMI best practices.

Appraisal teams use a CMMI model and ARC-conformant appraisal method to guide their evaluation of the organization and their reporting of conclusions. The appraisal results are used (e.g., by a process group) to plan improvements for the organization.

Appraisal Requirements for CMMI

The Appraisal Requirements for CMMI (ARC) document describes the requirements for several types of appraisals. A full benchmarking appraisal is defined as a Class A appraisal method. Less formal methods are defined as Class B or Class C methods. The ARC document was designed to help improve consistency across appraisal methods and to help appraisal method developers, sponsors, and users understand the tradeoffs associated with various methods.

Depending on the purpose of the appraisal and the nature of the circumstances, one class may be preferred over the others. Sometimes self assessments, initial appraisals, quick-look or mini appraisals, or external appraisals are appropriate; at other times a formal benchmarking appraisal is appropriate.

A particular appraisal method is declared an ARC Class A, B, or C appraisal method based on the sets of ARC requirements that the method developer addressed when designing the method.

More information about the ARC is available on the SEI website at http://www.sei.cmu.edu/cmmi/tools/appraisals/.

SCAMPI Appraisal Methods

The SCAMPI A appraisal method is the generally accepted method used for conducting ARC Class A appraisals using CMMI models. The SCAMPI A Method Definition Document (MDD) defines rules for ensuring the consistency of SCAMPI A appraisal ratings [SEI 2011a]. For benchmarking against other organizations, appraisals must ensure consistent ratings. The achievement of a specific maturity level or the satisfaction of a process area must mean the same thing for different appraised organizations.

The SCAMPI family of appraisals includes Class A, B, and C appraisal methods. The SCAMPI A appraisal method is the officially recognized and most rigorous method. It is the only method that can result in benchmark quality ratings. SCAMPI B and C appraisal methods provide organizations with improvement information that is less formal than the results of a SCAMPI A appraisal, but nonetheless helps the organization to identify improvement opportunities.

More information about SCAMPI methods is available on the SEI website at http://www.sei.cmu.edu/cmmi/tools/appraisals/.

Appraisal Considerations

Choices that affect a CMMI-based appraisal include the following:

·        CMMI model

·        Appraisal scope, including the organizational unit to be appraised, the CMMI process areas to be investigated, and the maturity level or capability levels to be appraised

·        Appraisal method

·        Appraisal team leader and team members

·        Appraisal participants selected from the appraisal entities to be interviewed

·        Appraisal outputs (e.g., ratings, instantiation-specific findings)

·        Appraisal constraints (e.g., time spent on site)

The SCAMPI MDD allows the selection of predefined options for use in an appraisal. These appraisal options are designed to help organizations align CMMI with their business needs and objectives.

CMMI appraisal plans and results should always include a description of the appraisal options, model scope, and organizational scope selected. This documentation confirms whether an appraisal meets the requirements for benchmarking.

For organizations that wish to appraise multiple functions or groups, the integrated approach of CMMI enables some economy of scale in model and appraisal training. One appraisal method can provide separate or combined results for multiple functions.

The following appraisal principles for CMMI are the same as those principles used in appraisals for other process improvement models:

·        Senior management sponsorship[10]

·        A focus on the organization’s business objectives

·        Confidentiality for interviewees

·        Use of a documented appraisal method

·        Use of a process reference model (e.g., a CMMI model)

·        A collaborative team approach

·        A focus on actions for process improvement

CMMI Related Training

Whether your organization is new to process improvement or is already familiar with process improvement models, training is a key element in the ability of organizations to adopt CMMI. An initial set of courses is provided by the SEI and its Partner Network, but your organization may wish to supplement these courses with its own instruction. This approach allows your organization to focus on areas that provide the greatest business value.

The SEI and its Partner Network offer the introductory course, Introduction to CMMI for Development. The SEI also offers advanced training to those who plan to become more deeply involved in CMMI adoption or appraisal—for example, those who will guide improvement as part of a process group, those who will lead SCAMPI appraisals, and those who will teach the Introduction to CMMI for Development course.

Current information about CMMI related training is available on the SEI website at http://www.sei.cmu.edu/training/.