Você está na página 1de 12
The Capability Maturity Model for Software Mark C. Paulk ‘Software Engineering Institute Carmegie Mellon University Pittsburgh, PA 15213-3890 Bill Curis TeraQuest Metrics, Inc. P.O. Box 200490 ‘Austin, TX 78720-0490 Mary Beth Chrissis Software Engineering Institute ‘Camegie Mellon University Pittsburgh, PA 15219-3890 Charles V. Weber Lockheed Martin Federal Systems Company 6304 Spine Fload Boulder, CO 60301 Abstract ‘This paper provides an overview of the latest ver- sion of the Capability Maturity Model™ for Software, MMM yi.], CMM v1.1 describes the software engi neering and management practices that. characterize organizations as they mature their processes for developing and maintaining software. This paper Stresses the need for a process matarity framework to prioritize improvement actions, describes the five ‘maturity levels, key process areas, and their common features, and discusses future directions for the CMM. Keywords: capability maturity model, CMM, software process improvement, process capability, maturity level, Key process area, software process as- sessment, software capability evaluation. 1 Introduction ‘Afier decades of unfulfilled promises about pro- uctivity and quality gains from applying new soft- ‘ware methodologies and technologies, organizations ‘ase realizing that their fundamental problem is the inability to manage the software process. In many oF ganizations, projects are often excessively late and over budget, and the benefits of better methods and tools cannot be realized in the maelstrom of an undis- ciplined, chaotic project, In November 1986, the Software Engineering Institute (SBI), with assistance from the Mitre Corpo- ration, began developing a process maturity frame- ‘work that would help organizations improve their software process. In September 1987, the SEI released ‘a brief description of the process maturity framework, ‘which was later expanded in Watts Humphrey's book, Managing the Software Process (Humphrey89}. Two methods, software process assessment! and software capability evaluation? were developed to appraise sofiware process maturity ‘Afier four years of experience with the software 1 software proces sesosement isan apps by a trined tear of sofware professionals to determine the sat of an organization's ‘Srremt sftare process, 10 determine the Bih-prorty software Sroceerelted iceee facing an organization, and to obtain the Erganiational suppor for stare process improvement 2 A software capability evaluation is an appraisal by a sined team cof proesronal fo identify contactors who are quaific to perform the software work oft monitor the state of the software process tied on an existing software eff. Reprinted frm Sofeare Engineering, M. Doran snd RH. Thayer, es, 1997 pp 427-408. Ccopnighs © 1997 by The fine of Eecrical an ectonks ngiezs Is. Argh revered 48 mammal : : : i i process maturity framework, the SEI evolved the maturity framework into the Capability Maturity Model for Software (CMM or SW-CMM3). The (CMM presents sets of recommended practices in a ‘number of Key process areas that have been shown to enhance software process capability. The CMM is based on knowledge acquired from software process assessments and extensive feedback from both indus ‘ny and government. ‘The CMM provides software organizations with suidance on how to gain control of their processes for developing and maintaining software and how to evolve toward a culture of software engineering and ‘management excellence, The CMM was designed to ‘guide software organizations in selecting process improvement strategies by determining current process ‘maturity and identifying the most critical issues for software quality and process improvement. By focus- ing on a limited set of activities and working aggres- sively to achieve them, ain organization can steadily improve its organization-wide software process to enable continuous and lasting gains in software proc- ess capability. ‘The initial release of the CMM, version 1.0, was reviewed and used by the software’ community during 1991 and 1992. The current version of the CMM, ver- sion 1.1, was released in 1993 (Paulk95a] and is the result of extensive feedback from the software com munity. The CMM has evolved significantly since 1986 [Paulk9Sb], and the SEI is currently working on version 2 1.1 Immatare Versus Mature Software Organizations Setting sensible goals for process improvement requires an understanding of the difference between immature and mature software organizations. In an immature software organization, software processes are generally improvised by practitioners and their ‘management during the course of the project. Even if a software process has been specified, it is not rigor- ously followed or enforced. The immature software ‘organization is reactionary, and managers arc usually focused on solving immediate crises (better known as fire fighting). Schedules and budgets are routinely exceeded because they are not based on realistic esti- 3 ss numberof CMMs inpiccd by the CMM for Software have now bean develope, including the Systems Eogiecring CMM (Bate95) and the People CMM {Curis85}. Additional CMMs ste being ‘Erxeloped on sofware acquisition and integrated product develop- nent To misimize confurion, we are stating ( use SW-CMM ‘Sistnguish the oigzal CMM for Software, bat since this paper focuses on sofevars engineering we will se the CMM acronyin 49 mates, When hard deadlines are imposed, product functionality and quality are often compromised to meet the schedule. Tn an immature organization, there is no objective basis for judging product quality or for solving prod- uct oF process problems. Therefore, product quality is difficult to predict. Activities intended to enhance ‘quality such as reviews and testing are often curtailed or eliminated when projects fall behind schedule. ‘On the other hand, a mature software organization possesses an organization-wide ability for managing softivare development and maintenance processes. The software process is accurately communicated to both existing staff and new employees, and work activities are carried out according to the planned process. The ‘mandated processes are usable and consistent with the ‘way the work actually gets done. These defined proc- cesses are updated when necessary, and improvements are developed through controlled pilot-tests and/or cost benefit analyses. Roles and responsibilities within the defined process are clear throughout the project ‘and across the organization, In 2 mature organization, managers monitor the quality of the software products and the process that produced them. ‘There is an objective, quantitative basis for judging product quality and analyzing prob. lems with the product and process. Schedules and budgets are based on historical performance and are realistic; the expected results for cost, schedule, func- tionality, and quality of the product are usually achieved. In general, a disciplined process is consis- tently followed because all of the participants under- stand the value of doing so, and the necessary infra- structure exists to support the process. 1.2 Fundamental Concepts Underlying Process Maturity A. software process can be defined as a set of activities, methods, practices, and transformations that people use to develop and maintain software and the associated products (for instance, project plans, design documents, code, test cases, and user manuals). As an organization matures, the software process becomes better defined and more consistently implemented throughout the organization. Software process capability describes the range of expected results that can be achieved by following a software process. An organization's software process ‘capability is one way of predicting the most likely out- ‘come to expect from the next software project the organization undertakes. ‘Software process performance represents the ‘actual results achieved by following a software proc- cess. Thus, software process performance focuses on the results achieved, while software process capability focuses on results expected. Software process maturity is the extent to which a specific process is explicitly defined, managed, meas- ‘ured, controlled, and. effective. Maturity implies potential for growth in capability and indicates both the richness of an organization’s software process and the consistency with which it is applied in projects throughout the organization 'AS a software organization gains in software proo- ‘ess maturity, it institutionalizes its software process vis policies, standards, and organizational structures. Institutionalization entails building an infrastructure ‘and a corporate culture that supports the methods, practices, and procedures of the business so that they endure after those who originally defined them have gone. 2 The Five Levels of Software Proc- ess Maturity Continuous process improvement is based on many simall, evolutionary steps rather than revolutionary Proditable Discpines process Initial a Figure 2.1 Continuously improving process standart, Defined } censstont ( @ proces innovations. The staged structure of the CMM is based ‘on principles of product quality espoused by Walter Showart, W. Edwards Deming, Joseph Juran, and Philip Crosby. The CMM provides a framework for ‘organizing these evolutionary steps into five maturity levels that lay successive foundations for continuous process improvement, These five maturity levels define an ordinal scale for measuring the maturity of fan organization's software process and for evaluating its software process capability. The levels also help an “organization prioritize its improvement efforts. ‘A maturity level is well-defined evolutionary plateau toward achieving a mature software process, ach maturity level comprises a set of process goals that, when satisfied, stabilize an important component of the software process. Achieving each level of the ‘maturity framework establishes a higher level of proc- ‘ess capability forthe organization. ‘Organizing the CMM into the five levels shown in Figure 21 prioritizes improvement actions for increasing software process maturity. The labeled arrows in Figure 2.1 indicate the type of process capa- bility being institutionalized by the organization at cach step of the maturity framework. ‘The five levels of software process maturity