CMMI for Development, 3rd Edition Free ebook download

  Process Areas by Category Process Management OPD Organizational Process Definition OPF Organizational Process Focus

OPM Organizational Performance Management

OPP Organizational Process Performance OT Organizational Training Project Management

  IPM Integrated Project Management PMC Project Monitoring and Control PP Project Planning QPM Quantitative Project Management REQM Requirements Management RSKM Risk Management SAM Supplier Agreement Management Engineering PI Product Integration RD Requirements Development TS Technical Solution

  VAL Validation

  VER Verification Support CAR Causal Analysis and Resolution CM Configuration Management DAR Decision Analysis and Resolution MA Measurement and Analysis PPQA Process and Product Quality Assurance

  Generic Goals and Practices GG1 Achieve Specific Goals GP 1.1 Perform Specific Practices GG2 Institutionalize a Managed Process GP2.1 Establish an Organizational Policy

  GP 2.2 Plan the Process GP 2.3 Provide Resources GP 2.4 Assign Responsibility GP 2.5 Train People GP 2.6 Control Work Products GP 2.7 Identify and Involve Relevant Stakeholders GP 2.8 Monitor and Control the Process GP 2.9 Objectively Evaluate Adherence GP 2.10 Review Status with Higher Level Management GG3 Institutionalize a Defined Process GP 3.1 Establish a Defined Process

GP 3.2 Collect Process Related Experiences

  

CMMI® for Development

Third Edition

  

The SEI Series in

Software Engineering

Visit informit.com/sei for a complete list of available products.

he SEI Series in Software Engineering represents is a collaborative

undertaking of the Carnegie Mellon Software Engineering Institute (SEI) and

  T Addison-Wesley to develop and publish books on software engineering and related topics. The common goal of the SEI and Addison-Wesley is to provide the most current information on these topics in a form that is easily usable by practitioners and students.

  Books in the series describe frameworks, tools, methods, and technologies designed to help organizations, teams, and individuals improve their technical

or management capabilities. Some books describe processes and practices for

developing higher-quality software, acquiring programs for complex systems, or

delivering services more effectively. Other books focus on software and system

architecture and product-line development. Still others, from the SEI’s CERT Program, describe technologies and practices needed to manage software and network security risk. These and all books in the series address critical problems in software engineering for which practical solutions are available.

  CMMI® for Development

Guidelines for Process Integration and

Product Improvement Third Edition Mary Beth Chrissis Mike Konrad Sandy Shrum Upper Saddle River, NJ • Boston• Indianapolis • San Francisco New York • Toronto • Montreal • London • Munich • Paris • Madrid Capetown • Sydney • Tokyo • Singapore • Mexico City

  The SEI Series in Software Engineering

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those

designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with ini-

tial capital letters or in all capitals.

CMM, CMMI, Capability Maturity Model, Capability Maturity Modeling, Carnegie Mellon, CERT, and CERT Coordination Center

are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University. ATAM; Architecture Tradeoff Analysis Method; CMM Integration; COTS Usage-Risk Evaluation; CURE; EPIC; Evolutionary Process for Integrating COTS Based Systems; Framework for Software Product Line Practice; IDEAL; Interim Profile; OAR;

OCTAVE; Operationally Critical Threat, Asset, and Vulnerability Evaluation; Options Analysis for Reengineering; Personal Soft-

ware Process; PLTP; Product Line Technical Probe; PSP; SCAMPI; SCAMPI Lead Appraiser; SCAMPI Lead Assessor; SCE; SEI; SEPG; Team Software Process; and TSP are service marks of Carnegie Mellon University. Special permission to reproduce portions of CMMI for Development (CMU/SEI-2010-TR-035), © 2010 by Carnegie Mellon University, has been granted by the Software Engineering Institute. The authors and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests. For more information, please contact: U.S. Corporate and Government Sales

  (800) 382-3419 corpsales@pearsontechgroup.com For sales outside the United States, please contact: International Sales international@pearsoned.com Visit us on the Web: informit.com/aw

  Library of Congress Cataloging-in-Publication Data Chrissis, Mary Beth.

  CMMI for development : guidelines for process integration and product improvement / Mary Beth Chrissis, Mike Konrad, Sandy Shrum.—3rd ed. p. cm. Includes bibliographical references and index.

  ISBN 978-0-321-71150-2 (hardcover : alk. paper)

1. Capability maturity model (Computer software) 2. Software engineering. 3. Production engineering. 4. Manufacturing processes.

I. Konrad, Mike. II. Shrum, Sandy. III. Title.

  QA76.758.C518 2011 005.1—dc22 2010049515 Copyright © 2011 Pearson Education, Inc.

  

All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must be

obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by

any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, write to: Pearson Education, Inc.

  Rights and Contracts Department 501 Boylston Street, Suite 900 Boston, MA 02116 Fax: (617) 671-3447

  ISBN-13: 978-0-321-71150-2

  ISBN-10: 0-321-71150-5 Text printed in the United States on recycled paper at Courier in Westford, Massachusetts. First printing, March 2011

  

This book is dedicated to Watts Humphrey, in appreciation for all

he accomplished as a leader, visionary, and teacher. You only

needed to be in a room with Watts Humphrey a short time to real-

ize what a special person he was. Watts’ leadership, vision, and

insights helped many over his lifetime. He was a student of learn-

ing and he shared that quest for learning with everyone with whom

he came into contact. He had a vision that he shared with the

world and the world became a better place. CMMI would not have

been possible without Watts Humphrey. May he continue to inspire

us for years to come.

  This page intentionally left blank

  CONTENTS

  

  20 Informative Components

  19 Expected Components

   Required Components

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  20

  

  35 Advancing Through Capability Levels

  

  

   Capability Level 0: Incomplete

  35 Capability Level 1: Performed

  35 Capability Level 2: Managed

  35 Capability Level 3: Defined

  36

  

   Maturity Level 1: Initial

  42 Maturity Level 2: Managed

  42 Maturity Level 3: Defined

  43 Maturity Level 4: Quantitatively Managed

  43 Maturity Level 5: Optimizing

  44 Advancing Through Maturity Levels

  45

  

  

   Process Areas

  23 Example Work Products

  20 Purpose Statements

  22 Introductory Notes

  22 Related Process Areas

  22 Specific Goals

  22 Generic Goals

  23 Specific Goal and Practice Summaries

  23 Specific Practices

  24 Subpractices

  26

  24 Generic Practices

  24 Generic Practice Elaborations

  25 Additions

  25

   Notes

  25 Examples

  25 References

  viii Contents

  Contents ix

  

  

  

  

  

  

   Basic Process Management Process Areas

  60 Advanced Process Management Process Areas

  62

   Basic Project Management Process Areas

  64 Advanced Project Management Process Areas

  66

  

  

   Basic Support Process Areas

  78 Advanced Support Process Areas

  79

  

  

  

  

  

  

  

  

  

  x Contents

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  Contents xi

  This page intentionally left blank

  

  LOOKING AHEAD Watts Humphrey

  5 CMMI: INTEGRATION AND IMPROVEMENT CONTINUES Bob Rassa

  12 THE ARCHITECTURE OF THE CMMI FRAMEWORK Roger Bate with a postscript by Mike Konrad

  14 APPLYING PRINCIPLES OF EMPIRICISM Victor R. Basili, Kathleen C. Dangle, and Michele A. Shaw

  37 USING PROCESS PERFORMANCE BASELINES AND PROCESS PERFORMANCE MODELS TO ENABLE SUCCESS Michael Campo, Neal Mackertich, and Peter Kraus

  53 EXPANDING CAPABILITIES ACROSS THE “CONSTELLATIONS” Mike Phillips

  72 MEASUREMENT MAKES IMPROVEMENT MEANINGFUL David N. Card

  75 PEOPLE, PROCESS, TECHNOLOGY, AND CMMI Gargi Keeni

  80 THE ROLE OF PROCESS STANDARDS IN PROCESS DEFINITION James W. Moore

  85 EXECUTIVE RESPONSIBILITIES IN PROCESS IMPROVEMENT Bill Curtis

  91

  xiv Perspectives

  IMPLEMENTING ENGINEERING CULTURE FOR SUCCESSFUL PROCESS IMPROVEMENT Tomoo Matsubara

  95 PROCESS IMPROVEMENT IN A SMALL COMPANY Khaled El Emam

  101

  IMPROVING INDUSTRIAL PRACTICE Hans-Jürgen Kugler

  107 SWITCHING TRACKS: FINDING THE RIGHT WAY TO GET TO MATURITY LEVEL 2 Heather Oppenheimer and Steve Baldassano 113 USING CMMI AS A BASIS FOR COMPETITIVE ADVANTAGE AT ABB Aldo Dagnino

  123 LEVERAGING CMMI AND LSS TO ACCELERATE THE PROCESS

  IMPROVEMENT JOURNEY Kileen Harrison and Anne Prem 130 GETTING STARTED IN PROCESS IMPROVEMENT: TIPS AND PITFALLS Judah Mogilensky

  137 AVOIDING TYPICAL PROCESS IMPROVEMENT PITFALLS Pat O’Toole

  141 TEN MISSING LINKS TO CMMI SUCCESS Hillel Glazer

  146 ADOPTING CMMI: HIRING A CMMI CONSULTANT OR LEAD APPRAISER Rawdon Young, Will Hayes, Kevin Schaaff, and Alexander Stall 152 FROM DOUBTER TO BELIEVER: MY JOURNEY TO CMMI Joseph Morin

  157

  

  CMMI (Capability Maturity Model Integration) models are collec- tions of best practices that help organizations to improve their processes. These models are developed by product teams with mem- bers from industry, government, and the Software Engineering Insti- tute (SEI).

  This model, called CMMI for Development (CMMI-DEV), pro- vides 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

1 CMMI V1.3 Architecture and Framework. CMMI-DEV is based on the

  CMMI Model Foundation or CMF (i.e., model components common

1. The CMMI Framework is the basic structure that organizes CMMI components and com- bines them into CMMI constellations and models.

  xvi Preface

  2

  to all CMMI models and constellations ) and incorporates work by development organizations to adapt CMMI for use in the develop- ment of products and services.

  Model 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 Develop- ment 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 famil- iar with the concept of Capability Maturity Models or are seeking infor- mation to begin improving your development processes, CMMI-DEV

  

2. A constellation is a collection of CMMI components that are used to construct models, training materials, and appraisal related documents for an area of interest (e.g., development, acquisition, services). This document is organized into three main parts:

  will be useful to you. This model is also intended for organizations that want to use a reference model for an appraisal of their develop- ment related processes.

• 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 compo-

  nents 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 prac- tices in a development organization.
• Chapter 6, Essays and Case Studies, contains essays and case studies

  contributed by invited authors from a variety of backgrounds and

  organizations.

  Part Two: Generic Goals and Generic Practices, and the Process Areas, contains all of this CMMI model’s required and expected com- ponents. It also contains related informative components, including subpractices, notes, examples, and example work products.

  Preface xvii

3 Organization of this Document

  3. An appraisal is an examination of one or more processes by a trained team of professionals using a reference model (e.g., CMMI-DEV) as the basis for determining strengths and weaknesses.

  

4. A process area is a cluster of related practices in an area that, when implemented collec-

tively, satisfies a set of goals considered important for making improvement in that area. This

  xviii Preface

  Part Two contains 23 sections. The first section contains the generic goals and practices. The remaining 22 sections each repre- sent 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 improve-

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

  Preface xix 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 recog- nize 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 pre- sented. 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 imple- mented.

  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 engineer- •

ing 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 apply-

ing capability level 1-3 to the high maturity process areas (Causal

Analysis and Resolution, Quantitative Project Management, Organi-

zational Performance Management, and Organizational Process

Performance).

  For a more complete and detailed list of improvements, see

  Additional Information and Reader Feedback

  Many sources of information about CMMI are listed in Appendix A and are also published on the CMMI

  Your suggestions for improving CMMI are welcome. For informa- tion on how to provide feedback, see the CMMI website at If you have questions about CMMI, send email to cmmi-comments@sei.cmu.edu.

  xx Preface

  This book wouldn’t be possible without the support of the CMMI user community and the work of a multitude of dedicated people working together on CMMI-based process improvement. Ultimately, without the work of those involved in the CMMI project since it began in 1998, this book would not exist. We would like to specially thank our many CMMI partners who help organizations apply CMMI practices.

  The complete CMMI-DEV model is contained in the book, which was created based on more than one thousand change requests sub- mitted by CMMI users. The CMMI Product Team, which included members from different organizations and backgrounds, used these change requests to improve the model to what it is today.

  We would also like to acknowledge those who directly con- tributed to this book. All of these authors were willing to share their insights and experiences and met aggressive deadlines to do so: Steve Baldassano, Victor Basili, Michael Campo, David Card, Bill Curtis, Aldo Dagnino, Kathleen Dangle, Khaled El Emam, Hillel Glazer, Kileen Harrison, Will Hayes, Watts Humphrey, Gargi Keeni, Peter Kraus, Hans Juergen Kugler, Neal Mackertish, Tomoo Matsubara, Judah Mogilensky, James Moore, Joseph Morin, Heather Oppen- heimer, Mike Philips, Pat O’Toole, Anne Prem, Robert Rassa, Kevin Schaaff, Michele Shaw, Alex Stall, and Rusty Young. We are delighted that they agreed to contribute their experiences to our book and we

  xxii Book Acknowledgments

  hope that you find their insights valuable and applicable to your process improvement activities.

  Special thanks go to Addison-Wesley Publishing Partner, Peter Gordon, for his assistance, experience, and advice. We’d also like to thank Kim Boedigheimer, Curt Johnson, Stephane Nakib, and Julie Nahil for their help with the book’s publication and promotion.

  From Mary Beth Chrissis

  I am so very blessed and humbled to be fortunate enough to be part of the third edition of this book. Working on CMMI has allowed me the opportunity to interact with many people. From the SEI Partners who work with the community daily, to the many individuals I’ve had the privilege to teach, to the people in organizations that believe CMMI will help them improve their business, I’ve learned so much from you. I’d like you all to know that I realize although my name appears on this book, I’m really just representing all of you. I don’t know why I have been given this opportunity, but please know I am greatly appreciative.

  I have a very special thank you for my colleagues at the SEI and especially those in the SEPM Program. You’ve encouraged and sup- ported me. Thanks to Anita Carleton, Mike Phillips, Barbara Tyson, Bob McFeeley, Stacey Cope, Mary Lou Russo, and Barbara Baldwin for all of your day-to-day assistance. I can’t forget Bill Peterson who has supported CMMI and the work on this book since its inception.

  Version 1.3 wouldn’t have been accomplished without the many volunteers who worked on it. I’d like to recognize the training team, particularly Mike Campo and Katie Smith, for spending many hours writing and reviewing the model and training materials. Thanks to Diane Mizukami Williams who had the vision and expertise to improve the CMMI-DEV Intro course. I’d also like to thank Bonnie Bollinger for her sage wisdom and comments. Lastly, thanks to Eric Dorsett, Steve Masters, and Dan Foster for their help with the train- ing materials.

  To my coauthors Sandy and Mike, you’re the best. Each time we write a book, it is a different experience and I wouldn’t want to work with anyone else. Thanks for your patience and understanding dur- ing this busy time.

  If you know me, you know my family is the center of my life. To my husband, Chuck, and my children, Adam, Pamela, and Kevin, thank you again for supporting me with this book. I love you and I am grateful to have you in my life.

  Book Acknowledgments xxiii From Mike Konrad

  I came to the SEI 23 years ago hoping to contribute to an interna- tional initiative that would fundamentally improve the way systems and software are built. CMMI has become that initiative. For this, I thank my many colleagues at the SEI and Industry, past and present.

  Over the years I’ve been honored to work with some of the most talented individuals in systems and software engineering. My favorite teachers have been Roger Bate, Jack Ferguson, Watts Humphrey, and Bill Peterson.

  For Version 1.3, I’ve been particularly honored to work with Jim Armstrong, Richard Basque, Rhonda Brown, Brandon Buteau, Mike Campo, Sandra Cepeda, Mary Beth Chrissis, Mike D’Ambrosa, Eileen Forrester, Brian Gallagher, Will Hayes, Larry Jones, So Norimatsu, Alice Parry, Lynn Penn, Mike Phillips, Karen Richter, Mary Lou Russo, Mary Lynn Russo, Winfried Russwurm, John Scibilia, Sandy Shrum, Kathy Smith, Katie Smith-McGarty, Barbara Tyson, and Rusty Young.

  I also continue to learn from my two coauthors, Mary Beth and Sandy; one could not hope for better or more talented coauthors. With respect to my family, words cannot express my heartfelt thanks to my wife, Patti, and our family, Paul, Jill, Christian, Katie,

  Alison, Tim, David, and Walter, for their patience while I was work- ing on the book and for sharing their time and insights of the world we all share; to my father, Walter, and my late mother, Renée, for their years of nurturing and sacrifice; and to my sister, Corinne, for her encouragement over the years.

  From Sandy Shrum

  Working simultaneously on three CMMI books has tested my limits in many ways. Those that have helped me along the journey pro- vided both professional and personal support.

  Many thanks to Rhonda Brown and Mike Konrad for their part- nership during CMMI model development. They are peerless as team members and friends. Our joint management of the CMMI Core Model Team was not only effective, but enjoyable.

  Affectionate thanks to my boyfriend, Jimmy Orsag, for his loving support and for helping me keep my focus and sense of humor through all the hours of work preparing three manuscripts. Heartfelt thanks to my parents, John and Eileen Maruca, for always being there for me no matter what and instilling my strong work ethic.

  xxiv Book Acknowledgments

  Finally, thanks to the coauthors of all three CMMI books: Bran- don Buteau, Mary Beth Chrissis, Eileen Forrester, Brian Gallagher, Mike Konrad, Mike Phillips, and Karen Richter. They are all terrific to work with. Without their understanding, excellent coordination, and hard work, I would never have been able to participate.

PART ONE

  

  This page intentionally left blank

CHAPTER 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 serv- ices. It is unusual today for a single organization to develop all the components that compose a complex product or service. More com- monly, some components are built in-house and some are acquired; then all the components are integrated into the final product or serv- ice. Organizations must be able to manage and control this complex development and maintenance process.

  The problems these organizations address today involve enter- prise-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, method- ologies, 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 fac- ing. 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 Devel- opment 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.

4 PART ONE ABOUT CMMI FOR DEVELOPMENT

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

  1 ment specific process areas.

  All CMMI-DEV model practices focus on the activities of the developer organization. Five process areas focus on practices specific to development: addressing requirements development, technical solution, product integration, verification, and validation.

  

  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 dimen- sions that organizations typically focus on: people, procedures and methods, and tools and equipment.

  What holds everything together? It is the processes used in your organization. Processes allow you to align the way you do business.

  Procedures and methods defining the relationship of tasks B

  A D C Process

  People with skills, training, and

  Tools and motivation equipment

FIGURE 1.1 The Three Critical Dimensions

1. A core process area is a process area that is common to all CMMI models. A shared process

Chapter 1 Introduction

  They allow you to address scalability and provide a way to incorpo- rate 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 incredi- ble 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 manufac- turing 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.

  Looking Ahead by Watts Humphrey

  Nearly 25 years ago when we first started the maturity model work that led to the CMM and CMMI, we took a diagnostic approach. What are the characteristics of organizations that performed good software work? We were following the principle that Tolstoy stated in Anna Karenina.

  2 “Happy families are all alike; every unhappy family is unhappy in its own way.”

  In applying the Tolstoy principle to software organizations, we looked for those markers that characterized effective software oper- ations and then formed these characteristics into a maturity model. The logic for the maturity model was that, to do good work, organi- zations must do everything right. However, since no one could pos- sibly fix all of their problems at once, our strategy was to determine what organizations were doing and compare that to what they

  5

2. Leo Tolstoy, Anna Karenina, Modern Library, New York.

6 PART ONE ABOUT CMMI FOR DEVELOPMENT

  should be doing to be a “happy family.” Then, using the model as a guide, they should start fixing the omissions and mistakes in the order defined by the model. Keep Doing the Good Things Unfortunately, we were not sufficiently clear with our initial guid- ance, and some people felt that, if they were only trying to get to maturity level 2, they should not do things that were at levels 3, 4, and 5. That is not what we meant. Organizations should continue doing all of the “good” things they now are doing and only focus on the problem areas. The objective at level 2 is to address those level 2 things that are missing or inadequate, and fix them first. Then the organization should consider addressing the level 3, 4, and 5 gaps. Again, they should not stop doing any things that work. The Logic for the Maturity Level 2 The logic that we followed in establishing the maturity levels was as follows. First, organizations cannot do good work, and they cer- tainly cannot improve, if they are in a perpetual state of crisis. Therefore, the first improvement efforts should focus on those things that, if done poorly or not at all, will result in crises. These are plan- ning, configuration management, requirements management, sub- contract management, quality assurance, and the like.

  The Logic for Maturity Level 3 Second, after the crises are largely controlled and the organization is plan-driven rather than crisis-driven, the next step is learning. How can people learn from each other rather than having to learn from their own mistakes? Again, from Tolstoy’s principle, there is an infi- nite number of ways to fail, so improving by reacting to failures is a never-ending and fruitless struggle. The key is to find out what works best in the organization and to spread that across all groups. There- fore, maturity level 3 focuses on learning-oriented things like process definition, training, and defined ways to make decisions and evalu- ate alternatives.

  The Logic for Maturity Levels 4 and 5 At level 4, the focus turns to quantitative management and quality control, and at level 5, the efforts include continuous improvement, technological innovations, and defect prevention. Unfortunately, we never included an explicit requirement in CMM or CMMI that high- maturity organizations must look outside of their own laboratories

Chapter 1 Introduction

  7

  to identify best industry practices. Then, after they find these prac- tices, they should measure, evaluate, and prototype them to see if these practices would help improve their operations. This seemed like such an obvious step that we never explicitly required it. How- ever, judging from the slow rate of adoption of new and well-proven software and systems development innovations, such a requirement should have been included in the model. Continuous Improvement At this point, of the many organizations that have been evaluated at CMMI level 5, too many have essentially stopped working on improvement. Their objective was to get to level 5 and they are there, so why should they keep improving? This is both an unfortu- nate and an unacceptable attitude. It is unfortunate because there are many new concepts and methods that these organizations would find beneficial, and it is unacceptable because the essence of level 5 is continuous improvement.

  Unfortunately, many organizations have become entangled in the weeds of process improvement and have lost sight of the forest and even of the trees. Six Sigma is a powerful and enormously help- ful statistically based method for improvement, but it is easy for people to become so enamored with these sophisticated methods that they lose sight of the objective. This is a mistake. The key is pri- orities and what will help organizations to improve their business performance. This is where external benchmarking and internal performance measures are needed. Use them to establish improve- ment priorities and then focus your improvement muscle on those areas that will substantially improve business performance. Next Steps While CMMI has been enormously successful, we have learned a great deal in the last 25 years, and there are now important new concepts and methods that were not available when we started. The key new concept concerns knowledge work. Peter Drucker, the leading management thinker of the twentieth century, defined knowledge work as work that is done with ideas and concepts rather than with things. While a great deal of today’s technical work is knowledge work, large-scale knowledge work is a relatively new phenomenon. Except for software, until recently, the really big proj- ects all concerned hardware systems. Now, however, software work pervades most parts of modern systems, and even the work of hard- ware designers more closely resembles that of software developers

8 PART ONE ABOUT CMMI FOR DEVELOPMENT

  To properly manage this new kind of work, new methods are needed, and Drucker enunciated the key new management concept. This is that knowledge work can’t be managed with traditional

  3

  methods; the knowledge workers must manage themselves. The logic behind Drucker’s view is compelling, but the story is too extensive to cover in this short perspective. However, there is a growing number of publications that describe knowledge work and

  4 how and why new management methods are needed.

  In summary, the key point is that software and complex systems development projects are large-scale knowledge work, and the rea- son such projects have long been troubled is that they have not been managed with suitable methods. The first method that has been designed to follow Drucker’s knowledge-management princi- ples is the Team Software Process (TSP), but there will almost cer- tainly be more such methods in the future.

  Using the TSP to guide software and systems development proj- ects turns out to be highly effective, and TSP projects are typically delivered on schedule, within budget, and with substantially

  5

  improved quality and productivity. To assist CMMI users in contin- uously improving their performance, the SEI has defined a new CMMI-based strategy and a family of practices to guide them in evaluating and piloting these methods. This method is called CMMI-AIM (Accelerated Improvement Method), and it is currently in use by a growing number of organizations.

  Conclusions As we continue refining our processes and methods to address the needs and practices of creative teams and people, new opportunities will keep showing up for broadening the scope of our processes and including new methods and technologies as they become available.

  Because many of these advances will be new to most users, users will need specific guidance on what these new methods are and how to best use them. The SEI strategy has been to provide this guidance for each new family of methods as it becomes available and is proven in practice.

  3. Peter Drucker, Knowledge-Worker Productivity: the Biggest Challenge, California Man- agement Review, Winter 1999, 41, 2, ABI/INFORM Global.

  4. Watts S. Humphrey, “Why Can’t We Manage Large Projects?” CrossTalk, July/August 2010, pp. 4–7; and Watts S. Humphrey and James W. Over, Leadership, Teamwork, and Trust: Build- ing a Competitive Software Capability, Reading, MA: Addison Wesley, 2011.

  5. Noopur Davis and Julia Mullaney, Team Software Process (TSP) in Practice, SEI Technical

Chapter 1 Introduction

  9

  Two examples of such new methods are CMMI- and TSP-related guidance on how to develop secure systems and on how to architect complex systems. As we look to the future, there will be many more opportunities for improving the performance of our systems and software engineering work. The key is to couple these methods into a coherent improvement framework such as TSP-CMMI and to pro- vide the explicit guidance organizations need to obtain the potential benefits of these new methods. To avoid chasing the latest fads, however, organizations should measure their own operations, eval- uate where they stand relative to their leading peers and competi- tors, and focus on those improvements that will measurably improve their business performance.

  

  A Capability Maturity Model (CMM), including CMMI, is a simpli- fied representation of the world. CMMs contain the essential ele- ments 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 improve- ment 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 descrip- tion of the basic principles and concepts on which many of the Capa- bility Maturity Models (CMMs) are based.