Updated revision of the best selling book on CMMI - now covering version 1.2.

Sandy Shrum is the CMMI communications coordinator and is a CMMI author, reviewer, editor, and member of the Quality Assurance Team Mary Beth Chrissis is a member of the CMMI Architecture Team and is the CMMI training manager Mike Konrad is the leader of the CMMI Model Team and chair of the CMMI Configuration Control Board

List of Perspectives

xi

Preface

xiii

Acknowledgments

xxi

PART ONE---ABOUT CMMI FOR DEVELOPMENT

1

(148)

Introduction

3

(28)

About Capability Maturity Models

4

(5)

Evolution of CMMI

9

(9)

CMMI for Development

18

(3)

The Scope of CMMI for Development

21

(1)

The Group of IPPD Additions

22

(1)

Resolving Different Approaches of CMMs

22

(1)

Choosing a Representation

22

(6)

Continuous Representation

23

(1)

Staged Representation

23

(1)

Comparison of the Continuous and Staged Representations

24

(1)

Factors in Your Decision

24

(1)

Why Not Both Representations?

25

(3)

Your Approach to Process Improvement

28

(3)

Scenario 1

28

(2)

Scenario 2

30

(1)

Process Area Components

31

(12)

Required, Expected, and Informative Components

31

(1)

Required Components

31

(1)

Expected Components

31

(1)

Informative Components

32

(1)

Components Associated with Part Two

32

(5)

Process Areas

33

(1)

Purpose Statements

34

(1)

Introductory Notes

34

(1)

Related Process Areas

34

(1)

Specific Goals

34

(1)

Generic Goals

34

(1)

Specific Goal and Practice Summaries

35

(1)

Specific Practices

35

(1)

Typical Work Products

35

(1)

Subpractices

36

(1)

Generic Practices

36

(1)

Generic Practice Elaborations

36

(1)

Supporting Informative Components

37

(1)

Notes

37

(1)

Examples

37

(1)

Amplifications

38

(1)

References

38

(1)

Numbering Scheme

38

(1)

Typographical Conventions

39

(4)

Representation-Specific Content

39

(1)

Additions

39

(4)

Tying It All Together

43

(28)

Understanding Levels

43

(1)

Structures of the Continuous and Staged Representations

44

(2)

Understanding Capability Levels

46

(6)

Capability Level 0: Incomplete

47

(1)

Capability Level 1: Performed

47

(1)

Capability Level 2: Managed

47

(1)

Capability Level 3: Defined

47

(1)

Capability Level 4: Quantitatively Managed

48

(1)

Capability Level 5: Optimizing

48

(1)

Advancing Through Capability Levels

48

(4)

Understanding Maturity Levels

52

(8)

Maturity Level 1: Initial

53

(1)

Maturity Level 2: Managed

53

(1)

Maturity Level 3: Defined

54

(1)

Maturity Level 4: Quantitatively Managed

54

(1)

Maturity Level 5: Optimizing

55

(1)

Advancing Through Maturity Levels

55

(5)

Process Areas

60

(3)

Generic Goals and Practices

63

(2)

Representation Comparison

65

(1)

Equivalent Staging

65

(6)

Relationships Among Process Areas

71

(22)

Four Categories of CMMI Process Areas

71

(1)

Process Management

72

(4)

Basic Process Management Process Areas

72

(1)

Advanced Process Management Process Areas

73

(3)

Project Management

76

(5)

Basic Project Management Process Areas

77

(1)

Advanced Project Management Process Areas

77

(4)

Engineering

81

(4)

Recursion and Iteration of Engineering Processes

84

(1)

Support

85

(8)

Basic Support Process Areas

85

(6)

Advanced Support Process Areas

91

(2)

Using CMMI Models

93

(26)

Adopting CMMI

97

(5)

Your Process Improvement Program

102

(4)

Selections That Influence Your Program

106

(1)

CMMI Models

107

(1)

Using CMMI Appraisals

107

(2)

Appraisal Requirements for CMMI

108

(1)

SCAMPI Appraisal Methods

108

(1)

Appraisal Considerations

109

(4)

CMMI-Related Training

113

(6)

Case Study: Applying CMMI to Services at Raytheon

119

(30)

The Organization and Its Process Dilemma

122

(1)

History

123

(3)

Success at Last

126

(4)

Key Roles That Contributed to Success

130

(1)

Approach to Interpreting CMMI for Services

131

(1)

Process Artifacts

131

(6)

Lifecycle Model

137

(8)

Epiphanies

145

(2)

Epiphany #1: Task Orders Are Equivalent to Projects in the Traditional Application of the Model

145

(1)

Epiphany #2: Every Project Shares the Same (Unchanging) Five Requirements

146

(1)

Epiphany #3: The Execution and Monitoring of Customer-Assigned Tasks Constitutes the Core of the Verification and Validation Processes

146

(1)

Epiphany #4: The Relative Time Spent for Development versus Delivery in Services Is Reversed from That of Products

147

(1)

Lessons Learned

147

(2)

PART TWO---GENERIC GOALS AND GENERIC PRACTICES AND THE PROCESS AREAS

149

(448)

Generic Goals and Generic Practices

151

(26)

Causal Analysis and Resolution

177

(14)

Configuration Management

191

(16)

Decision Analysis and Resolution

207

(14)

Integrated Project Management +IPPD

221

(32)

Measurement and Analysis

253

(20)

Organizational Innovation and Deployment

273

(20)

Organizational Process Definition +IPPD

293

(22)

Organizational Process Focus

315

(20)

Organizational Process Performance

335

(14)

Organizational Training

349

(18)

Product Integration

367

(20)

Project Monitoring and Control

387

(14)

Project Planning

401

(26)

Process and Product Quality Assurance

427

(12)

Quantitative Project Management

439

(26)

Requirements Development

465

(22)

Requirements Management

487

(12)

Risk Management

499

(20)

Supplier Agreement Management

519

(18)

Technical Solution

537

(28)

Validation

565

(14)

Verification

579

(18)

PART THREE---THE APPENDICES AND GLOSSARY

597

(42)

References

599

(4)

Publicly Available Sources

599

(3)

Regularly Updated Sources

602

(1)

Acronyms

603

(4)

CMMI for Development Project Participants

607

(6)

Product Team

607

(2)

Sponsors

609

(1)

Steering Group

610

(1)

Configuration Control Board

611

(2)

Glossary

613

(26)

Book Contributors

639

(12)

Index

651

What is included with this book?

The New copy of this book will include any supplemental materials advertised. Please check the title of the book to determine if it should include any access cards, study guides, lab manuals, CDs, etc.

The Used, Rental and eBook copies of this book are not guaranteed to include any supplemental materials. Typically, only the book itself is included. This is true even if the title states it includes any access cards, study guides, lab manuals, CDs, etc.

Capability Maturity Model Integration (CMMI) is a process improvement maturity model for the development of products and services. It consists of best practices that address development and maintenance activities that cover the product lifecycle from conception through delivery and maintenance. This latest iteration of the model as represented herein integrates bodies of knowledge that are essential for development and maintenance, but that have been addressed separately in the past, such as software engineering, systems engineering, hardware and design engineering, the engineering "-ilities," and acquisition. The prior designations of CMMI for systems engineering and software engineering (CMMI-SE/SW) are superseded by the title "CMMI for Development" to truly reflect the comprehensive integration of these bodies of knowledge, and the application of the model within the organization. CMMI for Development (CMMI-DEV) provides a comprehensive integrated solution for development and maintenance activities applied to products and services. CMMI for Development, v1.2 is a continuation and update of CMMI v1.1 and has been facilitated by the concept of CMMI "constellations" wherein a set of core components can be augmented by additional material to provide application-specific models with highly common content. CMMI-DEV is the first of such constellations and represents the development area of interest. Purpose The purpose of CMMI for Development is to help organizations improve their development and maintenance processes for both products and services. This book is based on CMMI for Development, v1.2, which was produced from the CMMI Framework 1 in August 2006. The CMMI Framework supports the CMMI Product Suite by allowing multiple models, training courses, and appraisal methods to be generated that support specific areas of interest. A constellation is a collection of CMMI components that includes a model, its training materials, and appraisal-related documents for an area of interest. Currently there are three planned constellations supported by the v1.2 model framework: development, services, and acquisition. "Additions" are used to expand constellations for specific additional content. This book contains the CMMI for Development constellation and contains both the base CMMI-DEV as well as CMMI-DEV with the IPPD group of additions (CMMI-DEV +IPPD). If you are not using IPPD, ignore the information that is marked "IPPD Addition" and you will be using theCMMI for Developmentmodel. CMMI v1.2 Contributors Many talented people were involved in the development of the CMMI v1.2 Product Suite. Three primary groups involved in this development were the Steering Group, Product Team, and Configuration Control Board. The Steering Group guides and approves the plans of the Product Team, provides consultation on significant CMMI project issues, and ensures involvement from a variety of interested communities. The Product Team writes, reviews, revises, discusses, and agrees on the structure and technical content of the CMMI Product Suite, including the framework, models, training, and appraisal materials. Development activities are based on multiple inputs. These inputs include 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 Configuration Control Board is the official mechanism for controlling changes to the CMMI models andIntroduction to CMMItraining. 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 the identified issues and meet the criteria for the upcomin