Technical ReportCMU/SEI-93-TR-024ESC-TR-93-177February 1993Capability Maturity ModelSMfor Software, Version 1.1Mark C. PaulkBill CurtisMary Beth ChrissisCharles V. Weber

Technical ReportCMU/SEI-93-TR-024ESC-TR-93-177February 1993Capability Maturity ModelSMfor Software, Version 1.1Mark C. PaulkBill CurtisMary Beth ChrissisCharles V. WeberUnlimited distribution subject to the copyright.Software Engineering InstituteCarnegie Mellon UniversityPittsburgh, Pennsylvania 15213

This report was prepared for theSEI Joint Program OfficeHQ ESC/AXS5 Eglin StreetHanscom AFB, MA 01731-2116The ideas and findings in this report should not be construed as an official DoD position. It is published in theinterest of scientific and technical information exchange.FOR THE COMMANDER(signature on file)Thomas R. Miller, Lt Col, USAFSEI Joint Program OfficeThis work is sponsored by the U.S. Department of Defense.Copyright 1996 by Carnegie Mellon University.Permission to reproduce this document and to prepare derivative works from this document for internal use isgranted, provided the copyright and “No Warranty” statements are included with all reproductions and derivativeworks.Requests for permission to reproduce this document or to prepare derivative works of this document for externaland commercial use should be addressed to the SEI Licensing Agent.NO WARRANTYTHIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIALIS 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 NOTLIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTIBILITY, EXCLUSIVITY, ORRESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOESNOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT,TRADEMARK, OR COPYRIGHT INFRINGEMENT.This work was created in the performance of Federal Government Contract Number F19628-95-C-0003 withCarnegie Mellon University for the operation of the Software Engineering Institute, a federally funded researchand development center. The Government of the United States has a royalty-free government-purpose license touse, 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 52.227-7013.This document is available through Research Access, Inc., 800 Vinial Street, Pittsburgh, PA 15212.Phone: 1-800-685-6510. FAX: (412) 321-2994. RAI also maintains a World Wide Web home page. The URL ishttp://www.rai.comCopies of this document are available through the National Technical Information Service (NTIS). For information on ordering, please contact NTIS directly: National Technical Information Service, U.S. Department ofCommerce, Springfield, VA 22161. Phone: (703) 487-4600.This document is also available through the Defense Technical Information Center (DTIC). DTIC provides access to and transfer of scientific and technical information for DoD personnel, DoD contractors and potential contractors, and other U.S. Government agency personnel and their contractors. To obtain a copy, please contactDTIC directly: Defense Technical Information Center, Attn: FDRA, Cameron Station, Alexandria, VA 223046145. Phone: (703) 274-7633.Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder.

Table of ContentsAcknowledgments.vTo the Reader.viiWhat is the Purpose of This Paper?.viiiWho Should Read This Paper?.viiiHow is This Paper Organized?.ixWhat Are the Other CMM Products?.xHow Do You Receive More Information?.xi1 The Process Maturity Framework.11.1 Immature Versus Mature Software Organizations.11.2 Fundamental Concepts Underlying Process Maturity.31.3 Overview of the Capability Maturity Model.42 The Five Levels of Software Process Maturity.72.1 Behavioral Characterization of the Maturity Levels.92.1.1 Level 1 - The Initial Level.102.1.2 Level 2 - The Repeatable Level.102.1.3 Level 3 - The Defined Level.112.1.4 Level 4 - The Managed Level.122.1.5 Level 5 - The Optimizing Level.132.2 Understanding the Maturity Levels.142.2.1 Understanding the Initial Level.152.2.2 Understanding the Repeatable and Defined Levels.152.2.3 Understanding the Managed and Optimizing Levels.162.3 Visibility Into the Software Process.192.4 Process Capability and the Prediction of Performance.222.5 Skipping Maturity Levels.253 Operational Definition of the Capability Maturity Model.273.1 Internal Structure of the Maturity Levels.273.2 Maturity Levels.303.3 Key Process Areas.303.4 Common Features.373.5 Key Practices.394 Using the CMM.434.1 Software Process Assessment and Software CapabilityEvaluation Methods.444.2 Differences Between Software Process Assessments andSoftware Capability Evaluations.474.3 Other Uses of the CMM in Process Improvement.49CMU/SEI-93-TR-24Capability Maturity Model i

Table of Contents5Future Directions of the CMM.515.1 What the CMM Does Not Cover.515.2 Near-Term Activities.515.3 Long-Term Activities.525.4 Conclusion.536 References.55Appendix A: Goals for Each Key Process Area.59A.1 The Key Process Areas for Level 2: Repeatable.59A.2 The Key Process Areas for Level 3: Defined.61A.3 The Key Process Areas for Level 4: Managed.62A.4 The Key Process Areas for Level 5: Optimizing.63ii Capability Maturity ModelCMU/SEI-91-TR-24

List of FiguresFigure 2.1Figure 2.2Figure 2.3Figure 2.4Figure 3.1Figure 3.2Figure 3.3Figure 4.1CMU/SEI-93-TR-24The Five Levels of Software Process Maturity.8The Juran Trilogy Diagram: Quality Planning, QualityControl, and Quality Improvement.17A Management View of Visibility into the Software Processat Each Maturity Level.20Process Capability as Indicated by Maturity Level.23The CMM Structure.29The Key Process Areas by Maturity Level.31Building the CMM Structure: An Example of a Key Practice.40Common Steps in Software Process Assessments andSoftware Capability Evaluations.45Capability Maturity Model iii

List of Figuresiv Capability Maturity ModelCMU/SEI-91-TR-24

AcknowledgmentsThe description of the Capability Maturity Model for Software was initiallyproduced by a dedicated group of people who spent many hours discussingthe model and its features and then trying to document it in CMM v1.0.This group consisted of Mark Paulk, Bill Curtis, Mary Beth Chrissis, EdwardAverill, Judy Bamberger, Tim Kasse, Mike Konrad, Jeff Perdue, CharlieWeber, and Jim Withey.This paper is based on the vision of Watts Humphrey, first director of theSEI's Software Process Program. It took several drafts to evolve this paperinto the final product. Jim Withey, Mark Paulk, and Cynthia Wiseproduced an early draft in 1990. Watts Humphrey provided a second draftof the document, and Mark Paulk then took over the paper and remainedbook boss until the end. Mary Beth Chrissis and Bill Curtis helped Markproduce the CMM v1.0 revision of this paper in August, 1991. Mark Paulkproduced the CMM v1.1 revision of the paper, which is this technical report.At various stages, several people contributed to the concepts expressed inthis paper. They include Joe Besselman, Marilyn Bush, Anita Carleton,Marty Carlson, Betty Deimel, Suzie Garcia, Richard Kauffold, Steve Masters,Mary Merrill, Jim Over, George Pandelios, Jane Siegel and Charlie Weber.We appreciate the administrative help from Todd Bowman, DorothyJosephson, Debbie Punjack, Carolyn Tady, Marcia Theoret, Andy Tsounos,and David White; and the editorial assistance from Mary Beth Chrissis,Suzanne Couturiaux, and Bill Pollak. Renne Dutkowski from theAmerican Institutes for Research provided suggestions for the design of thedocument.CMU/SEI-93-TR-24Capability Maturity Model v

Acknowledgmentsvi Capability Maturity ModelCMU/SEI-93-TR-24

To the ReaderIn November 1986, the Software Engineering Institute (SEI), with assistancefrom the Mitre Corporation, began developing a process maturityframework that would help organizations improve their software process.This effort was initiated in response to a request to provide the federalgovernment with a method for assessing the capability of its softwarecontractors. In September 1987, the SEI released a brief description of theprocess maturity framework [Humphrey 87a] and a maturity questionnaire[Humphrey87b]. The SEI intended the maturity questionnaire to provide asimple tool for identifying areas where an organization's software processneeded improvement. Unfortunately, the maturity questionnaire was toooften regarded as "the model" rather than as a vehicle for exploring processmaturity issues.After four years of experience with the software process maturity frameworkand the preliminary version of the maturity questionnaire, the SEI evolvedthe software process maturity framework into the Capability MaturityModel for Software (CMM) [Paulk91, Weber91]. The CMM is based onknowledge acquired from software process assessments and extensivefeedback from both industry and government. By elaborating the maturityframework, a model has emerged that provides organizations with moreeffective guidance for establishing process improvement programs.The initial release of the CMM, Version 1.0, was reviewed and used by thesoftware community during 1991 and 1992. A workshop was held in April,1992 on CMM v1.0, which was attended by about 200 software professionals.This version of the CMM, Version 1.1, is the result of the feedback from thatworkshop and ongoing feedback from the software community.The CMM is the foundation for systematically building a set of tools,including a maturity questionnaire, which are useful in software processimprovement. The essential point to remember is that the model, not aquestionnaire, is the basis for improving the software process. This paper isintended to introduce the reader to CMM v1.1.CMU/SEI-93-TR-24Capability Maturity Model vii

To the ReaderWhat is the Purpose of This Paper?This paper provides a technical overview of the Capability Maturity Modelfor Software and reflects Version 1.1. Specifically, this paper describes theprocess maturity framework of five maturity levels, the structuralcomponents that comprise the CMM, how the CMM is used in practice, andfuture directions of the CMM. This paper serves as one of the best sourcesfor understanding the CMM, and it should clear up some of themisconceptions associated with software process maturity as advocated bythe SEI.The SEI has worked with industry and government to refine and expandthe model, and software organizations are encouraged to focus on the CMMrather than on the maturity questionnaire. The SEI has developed, and isdeveloping, a suite of process products to encourage this focus. This paper[Paulk93a], in combination with the "Key Practices of the Capability MaturityModel, Version 1.1" [Paulk93b], comprises CMM v1.1. The "Key Practices ofthe Capability Maturity Model, Version 1.1" describes the key practices foreach level of the CMM. This paper describes the principles underlyingsoftware process maturity and is intended to help software organizationsuse CMM v1.1 as a guide to improve the maturity of their softwareprocesses.Who Should Read This Paper?This paper presents an introduction to the CMM and its associated products.Therefore, anyone who is interested in learning about the CMM shouldread this paper. However, this paper assumes that the reader has someknowledge of, and experience in, developing and/or maintaining software,as well as an understanding of the problems that the software communityfaces today.viii Capability Maturity ModelCMU/SEI-93-TR-24

To the ReaderThis document can be used in several ways: by anyone wanting to understand the key practices that are part ofeffective processes for developing or maintaining software, by anyone wanting to identify the key practices that are needed toachieve the next maturity level in the CMM, by organizations wanting to understand and improve their capabilityto develop software effectively, by acquisition organizations or prime contractors wanting to knowthe risks of having a particular software organization perform thework of a contract, by the SEI as the basis for developing questions for the maturityquestionnaire, and by instructors preparing teams to perform software processassessments or software capability evaluations.How is This Paper Organized?This paper has five chapters:Chapter 1CMU/SEI-93-TR-24Defines the concepts necessary to understandthe CMM and the motivation and purposebehind it.Capability Maturity Model ix

To the ReaderChapter 2Describes the five levels of the CMM and theprinciples that underlie them.Chapter 3Describes how the CMM is structured intokey process areas, organized by commonfeatures, and described in terms of keypractices.Chapter 4Provides a high-level overview of how theCMM provides guidance for software processassessments, software capability evaluations,and process improvement programs.Chapter 5Concludes by providing a description offuture directions for the CMM and its relatedproducts.What Are the Other CMM Products?Although this paper can be read in isolation, it is designed to be thelaunching point for other products. This paper and the associated productshelp the reader understand and use the CMM. All of the CMM-basedproducts have been, or will be, systematically derived from the model. Atthe time of this writing, most of these products are not available in theirfinal form, although preliminary versions are in various stages of pilottesting and release.x Capability Maturity ModelCMU/SEI-93-TR-24

To the ReaderThe CMM-based set of products includes several diagnostic tools, which areused by software process assessment1 and software capability evaluation2teams to identify strengths, weaknesses, and risks of an organization'ssoftware process. Probably the best known of these is the maturityquestionnaire. The software process assessment and software capabilityevaluation methods and training also rely on the CMM.The users of these products form a community dedicated to improving thematurity of their software process. The SEI will continue to work with thesoftware community to enhance the model and its associated products.How Do You Receive More Information?For further information regarding the CMM and its associated products,including training on the CMM and how to perform software processassessments and software capability evaluations, contact:SEI Customer RelationsSoftware Engineering InstituteCarnegie Mellon UniversityPittsburgh, PA 15213-3890(412) 268-5800Internet: [email protected] A software process assessment is an appraisal by a trained team of software professionals todetermine the state of an organization's current software process, to determine the high-prioritysoftware process-related issues facing an organization, and to obtain the organizational support forsoftware process improvement.2 A software capability evaluation is an appraisal by a trained team of professionals to identifycontractors who are qualified to perform the software work or to monitor the state of the softwareprocess used on an existing software effort.CMU/SEI-93-TR-24Capability Maturity Model xi

To the ReaderSEI technical reports, such as this paper and the "Key Practices of theCapability Maturity Model, Version 1.1," are directly available from theDefense Technical Information Center (DTIC), the National TechnicalInformation Service (NTIS), and Research Access Inc. (RAI). Thesedocuments can be obtained by contacting:xii RAI:Research Access Inc.3400 Forbes AvenueSuite 302Pittsburgh, PA 15213Telephone: (800) 685-6510FAX: (412) 682-6530NTIS:National Technical Information ServiceU.S. Department of CommerceSpringfield, VA 22161-2103Telephone: (703) 487-4600DTIC:Defense Technical Information CenterATTN: FDRA Cameron StationAlexandria, VA 22304-6145Telephone: (703) 274-7633Capability Maturity ModelCMU/SEI-93-TR-24

To the ReaderSEI technical reports are also available via Internet. To use anonymous ftpfrom a Unix system on Internet:ftp ftp.sei.cmu.edu3login: anonymouspassword: your user id or any string cd pub/cmmget READ.MEget files quitThe file READ.ME contains information on what files are available. OtherSEI publications are available in a similar manner.3 The SEI ftp machine address is Maturity Model xiii

To the Readerxiv Capability Maturity ModelCMU/SEI-93-TR-24

1The Process MaturityFrameworkAfter two decades of unfulfilled promises about productivity and qualitygains from applying new software methodologies and technologies,industry and government organizations are realizing that theirfundamental problem is the inability to manage the software process[DoD87]. The benefits of better methods and tools cannot be realized in themaelstrom of an undisciplined, chaotic project. In many organizations,projects are often excessively late and double the planned budget [Siegel90].In such instances, the organization frequently is not providing theinfrastructure and support necessary to help projects avoid these problems.Even in undisciplined organizations, however, some individual softwareprojects produce excellent results. When such projects succeed, it isgenerally through the heroic efforts of a dedicated team, rather thanthrough repeating the proven methods of an organization with a maturesoftware process. In the absence of an organization-wide software process,repeating results depends entirely on having the same individuals availablefor the next project. Success that rests solely on the availability of specificindividuals provides no basis for long-term productivity and qualityimprovement throughout an organization. Continuous improvement canoccur only through focused and sustained effort towards building a processinfrastructure of effective software engineering and management practices.1.1Immature Versus Mature SoftwareOrganizationsSetting sensible goals for process improvement requires an understandingof the difference between immature and mature software organizations. Inan immature software organization, software processes are generallyimprovised by practitioners and their management during the course of theproject. Even if a software process has been specified, it is not rigorouslyCMU/SEI-93-TR-24Capability Maturity Model 1

The Process Maturity Frameworkfollowed or enforced. The immature software organization is reactionary,and managers are usually focused on solving immediate crises (betterknown as fire fighting). Schedules and budgets are routinely exceededbecause they are not based on realistic estimates. When hard deadlines areimposed, product functionality and quality are often compromised to meetthe schedule.In an immature organization, there is no objective basis for judging productquality or for solving product or process problems. Therefore, productquality is difficult to predict. Activities intended to enhance quality such asreviews and testing are often curtailed or eliminated when projects fallbehind schedule.On the other hand, a mature software organization possesses anorganization-wide ability for managing software development andmaintenance processes. The software process is accurately communicated toboth existing staff and new employees, and work activities are carried outaccording to the planned process. The processes mandated are fit for use[Humphrey91b] and consistent with the way the work actually gets done.These defined processes are updated when necessary, and improvementsare developed through controlled pilot-tests and/or cost benefit analyses.Roles and responsibilities within the defined process are clear throughoutthe project and across the organization.In a mature organization, managers monitor the quality of the softwareproducts and customer satisfaction. There is an objective, quantitative basisfor judging product quality and analyzing problems with the product andprocess. Schedules and budgets are based on historical performance and arerealistic; the expected results for cost, schedule, functionality, and quality ofthe product are usually achieved. In general, a disciplined process isconsistently followed because all of the participants understand the value ofdoing so, and the necessary infrastructure exists to support the process.2 Capability Maturity ModelCMU/SEI-93-TR-24

The Process Maturity FrameworkCapitalizing on these observations about immature and mature softwareorganizations requires construction of a software process maturityframework. This framework describes an evolutionary path from ad hoc,chaotic processes to mature, disciplined software processes. Without thisframework, improvement programs may prove ineffective because thenecessary foundation for supporting successive improvements has not beenestablished. The software process maturity framework emerges fromintegrating the concepts of software process, software process capability,software process performance, and software process maturity, all of whichare defined in succeeding paragraphs.1.2Fundamental Concepts Underlying ProcessMaturityAccording to Webster's dictionary, a process is "a system of operations inproducing something . a series of actions, changes, or functions thatachieve an end or result." The IEEE defines a process as "a sequence of stepsperformed for a given purpose" [IEEE-STD-610]. A software process can bedefined as a set of activities, methods, practices, and transformations thatpeople use to develop and maintain software and the associated products(e.g., project plans, design documents, code, test cases, and user manuals).As an organization matures, the software process becomes better definedand more consistently implemented throughout the organization.Software process capability describes the range of expected results that can beachieved by following a software process. The software process capability ofan organization provides one means of predicting the most likely outcomesto be expected from the next software project the organization undertakes.Software process performance represents the actual results achieved byfollowing a software process. Thus, software process performance focuseson the results achieved, while software process capability focuses on resultsexpected. Based on the attributes of a specific project and the context withinCMU/SEI-93-TR-24Capability Maturity Model 3

The Process Maturity Frameworkwhich it is conducted, the actual performance of the project may not reflectthe full process capability of the organization; i.e., the capability of theproject is constrained by its environment. For instance, radical changes inthe application or technology undertaken may place a project' s staff on alearning curve that causes their project's capability, and performance, to fallshort of the organization's full process capability.Software process maturity is the extent to which a specific process isexplicitly defined, managed, measured, controlled, and effective. Maturityimplies a potential for growth in capability and indicates both the richnessof an organization's software process and the consistency with which it isapplied in projects throughout the organization. The software process iswell-understood throughout a mature organization, usually throughdocumentation and training, and the process is continually beingmonitored and improved by its users. The capability of a mature softwareprocess is known. Software process maturity implies that the productivityand quality resulting from an organization’s software process can beimproved over time through consistent gains in the discipline achieved byusing its software process.As a software organization gains in software process maturity, itinstitutionalizes its software process via policies, standards, andorganizational structures. Institutionalization entails building aninfrastructure and a corporate culture that supports the methods, practices,and procedures of the business so that they endure after those whooriginally defined them have gone.1.3Overview of the Capability Maturity ModelAlthough software engineers and managers often know their problems ingreat detail, they may disagree on which improvements are most important.Without an organized strategy for improvement, it is difficult to achieveconsensus between management and the professional staff on what4 Capability Maturity ModelCMU/SEI-93-TR-24

The Process Maturity Frameworkimprovement activities to undertake first. To achieve lasting results fromprocess improvement efforts, it is necessary to design an evolutionary paththat increases an organization's software process maturity in stages. Thesoftware process maturity framework [Humphrey 87a] orders these stages sothat improvements at each stage provide the foundation on which to buildimprovements undertaken at the next stage. Thus, an improvementstrategy drawn from a software process maturity framework provides aroadmap for continuous process improvement. It guides advancement andidentifies deficiencies in the organization; it is not intended to provide aquick fix for projects in trouble.The Capability Maturity Model for Software provides software organizationswith guidance on how to gain control of their processes for developing andmaintaining software and how to evolve toward a culture of softwareengineering and management excellence. The CMM was designed to guidesoftware organizations in selecting process improvement strategies bydetermining current process maturity and identifying the few issues mostcritical to software quality and process improvement. By focusing on alimited set of activities and working aggressively to achieve them, anorganization can steadily improve its organization-wide software process toenable continuous and lasting gains in software process capability.The staged structure of the CMM is based on principles of product qualitythat have existed for the last sixty years. In the 1930s, Walter Shewart,promulgated the principles of statistical quality control. His principles werefurther developed and successfully demonstrated in the work of W.Edwards Deming [Deming86] and Joseph Juran [Juran88, Juran89]. Theseprinciples have been adapted by the SEI into a maturity framework thatestablishes a project management and engineering foundation forquantitative control of the software process, which is the basis forcontinuous process improvement.The maturity framework into which these quality principles have beenadapted was first inspired by Philip Crosby of in his book Quality is Free[Crosby79]. Crosby's quality management maturity grid describes fiveCMU/SEI-93-TR-24Capability Maturity Model 5

The Process Maturity Frameworkevolutionary stages in adopting quality practices. This maturity frameworkwas adapted

CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. This work was created in the performance of Federal Government Contract Number F19628-95-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a File Size: 464KB