Capability Maturity Model

Table of Contents
Acknowledgments............................................................................................................v To the Reader.................................................................................................................vii What is the Purpose of This Paper?..............................................................................viii Who Should Read This Paper?.....................................................................................viii How is This Paper Organi ed?........................................................................................i! What Are the Other "## Products?...............................................................................! How $o %ou Receive #ore &nformation?......................................................................!i ' The Process #aturit( )ramework................................................................................' '.' &mmature *ersus #ature Software Organi ations..............................................' '.+ )undamental "oncepts ,nderl(ing Process #aturit(.........................................'.- Overview of the "apa.ilit( #aturit( #odel......................................................./ + The )ive 0evels of Software Process #aturit(............................................................1 +.' 2ehavioral "haracteri ation of the #aturit( 0evels...........................................3 +.'.' 0evel ' 4 The &nitial 0evel.....................................................................'5 +.'.+ 0evel + 4 The Repeata.le 0evel............................................................'5 +.'.- 0evel - 4 The $efined 0evel.................................................................'' +.'./ 0evel / 4 The #anaged 0evel...............................................................'+ +.'.6 0evel 6 4 The Optimi ing 0evel............................................................'+.+ ,nderstanding the #aturit( 0evels...................................................................'/ +.+.' ,nderstanding the &nitial 0evel.............................................................'6 +.+.+ ,nderstanding the Repeata.le and $efined 0evels..............................'6 +.+.- ,nderstanding the #anaged and Optimi ing 0evels............................'7 +.- *isi.ilit( &nto the Software Process..................................................................'3 +./ Process "apa.ilit( and the Prediction of Performance.....................................++ +.6 Skipping #aturit( 0evels..................................................................................+6 - Operational $efinition of the "apa.ilit( #aturit( #odel.........................................+1 -.' &nternal Structure of the #aturit( 0evels..........................................................+1 -.+ #aturit( 0evels.................................................................................................-5 -.- 8e( Process Areas..................................................................................................................-5 -./ "ommon )eatures.............................................................................................-1 -.6 8e( Practices.....................................................................................................-3 / ,sing the "##..........................................................................................................//.' Software Process Assessment and Software "apa.ilit( 9valuation #ethods.........................................................................................// /.+ $ifferences 2etween Software Process Assessments and Software "apa.ilit( 9valuations...................................................................../1 /.- Other ,ses of the "## in Process &mprovement............................................/3
CMU/SEI-93-TR-24
Capability Maturity Model
Table of Contents
6 )uture $irections of the "##........................................................................................................................ 6' 6.' What the "## $oes :ot "over........................................................................................................................ 6' 6.+ :ear4Term Activities.................................................................................................................. 6' 6.- 0ong4Term Activities.................................................................................................................. 6+ 6./ "onclusion......................................................................................................... 67 References.................................................................................................................. 66 Appendi! A; <oals for 9ach 8e( Process Area................................................................................................................................ 63 A.' The 8e( Process Areas for 0evel +; Repeata.le................................................................................................................ 63 A.+ The 8e( Process Areas for 0evel -; $efined....................................................................................................... 7' A.- The 8e( Process Areas for 0evel /; #anaged..................................................................................................... 7+ A./ The 8e( Process Areas for 0evel 6; Optimi ing................................................................................................................ 7-
ii
Capability
Maturity Model
CMU/SEI-91-TR-24
List of Figures
)igure +.' The )ive 0evels of Software Process #aturit(................................................................................................................ = )igure +.+ The >uran Trilog( $iagram; ?ualit( Planning@ ?ualit( "ontrol@ and ?ualit( &mprovement............................................................................................. '1 )igure +.- A #anagement *iew of *isi.ilit( into the Software Process at 9ach #aturit( 0evel.............................................................................. +5 )igure +./ Process "apa.ilit( as &ndicated .( #aturit( 0evel............................................................................................. +)igure -.' The "## Structure...................................................................................... +3 )igure -.+ The 8e( Process Areas .( #aturit( 0evel................................................................................................................. -' )igure -.- 2uilding the "## Structure; An 9!ample of a 8e( Practice........................................................................ /5 )igure /.' "ommon Steps in Software Process Assessments and Software "apa.ilit( 9valuations...................................................................................... /6
CMU/SEI-93-TR-24
iii
List of Figures
iv
Capability
Maturity Model
CMU/SEI-91-TR-24
CMU/SEI-93-TR-24
Acknowledgments
vi
Capability
Maturity Model
CMU/SEI-93-TR-24
To the Reader
'.-
Overvie w of the Capabili ty Maturit y Model

Although software engineers and managers often know their pro.lems in great detail@ the( ma( disagree on which improvements are most important. Without an organi ed strateg( for improvement@ it is difficult to achieve consensus .etween management and the professional staff on what
Capability
Maturity Model
CMU/SEI-93-TR-24
The rocess Maturity Framework

improvement activities to undertake first. To achieve lasting results from process improvement efforts@ it is necessar( to design an evolutionar( path that increases an organi ationAs software process maturit( in stages. The software process maturit( framework BHumphre( =1aC orders these stages so that improvements at each stage provide the foundation on which to .uild improvements undertaken at the ne!t stage. Thus@ an improvement strateg( drawn from a software process maturit( framework provides a roadmap for continuous process improvement. &t guides advancement and identifies deficiencies in the organi ationD it is not intended to provide a Euick fi! for proFects in trou.le.
The "apa.ilit( #aturit( #odel for Software provides software organi ations with guidance 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 e!cellence. The "## was designed to guide software organi ations in selecting process improvement strategies .( determining current process maturit( and identif(ing the few issues most critical to software Eualit( and process improvement. 2( focusing on a limited set of activities and working aggressivel( to achieve them@ an organi ation can steadil( improve its organi ation4wide software process to ena.le continuous and lasting gains in software process capa.ilit(.
The staged structure of the "## is .ased on principles of product Eualit( that have e!isted for the last si!t( (ears. &n the '3-5s@ Walter Shewart@ promulgated the principles of statistical Eualit( control. His principles were further developed and successfull( demonstrated in the work of W. 9dwards $eming B$eming=7C and >oseph >uran B>uran==@ >uran=3C. These principles have .een adapted .( the S9& into a maturit( framework that esta.lishes a proFect management and engineering foundation for Euantitative control of the software process@ which is the .asis for continuous process improvement.
The maturit( framework into which these Eualit( principles have .een adapted was first inspired .( Philip "ros.( of in his .ook Quality is Free B"ros.(13C. "ros.(As Eualit( management maturit( grid descri.es five
CMU/SEI-93-TR-24
The rocess Maturity Framework

evolutionar( stages in adopting Eualit( practices. This maturit( framework was adapted to the software process .( Ron Radice and his colleagues@ working under the direction of Watts Humphre( at &2# BRadice=6C. Humphre( .rought this maturit( framework to the Software 9ngineering &nstitute in '3=7@ added the concept of maturit( levels@ and developed the foundation for its current use throughout the software industr(.
9arl( versions of Humphre(As maturit( framework are descri.ed in S9& technical reports BHumphre(=1a@ Humphre(=1.C@ papers BHumphre(==C@ and in his .ook@ Managing the So t!are "ro#ess BHumphre(=3C. A preliminar( maturit( Euestionnaire BHumphre(=1.C was released in '3=1 as a tool to provide organi ations with a wa( to characteri e the maturit( of their software processes. Two methods@ software process assessment and software capa.ilit( evaluation@ were developed to appraise software process maturit( in '3=1. Since '335@ the S9&@ with the help of man( people from government and industr(@ has further e!panded and refined the model .ased on several (ears of e!perience in its application to software process improvement.
Capability
Maturity Model
CMU/SEI-93-TR-24
The Five Levels of !oftware rocess Maturity

"ontinuous process improvement is .ased on man( small@ evolutionar( steps rather than revolutionar( innovations B&mai=7C. The "## provides a framework for organi ing these evolutionar( steps into five maturit( levels that la( successive foundations for continuous process improvement. These five maturit( levels define an ordinal scale for measuring the maturit( of an organi ationAs software process and for evaluating its software process capa.ilit(. The levels also help an organi ation prioriti e its improvement efforts.
A $aturity le%el is a well4defined evolutionar( plateau toward achieving a mature software process. 9ach maturit( level provides a la(er in the foundation for continuous process improvement. 9ach level comprises a set of process goals that@ when satisfied@ sta.ili e an important component of the software process. Achieving each level of the maturit( framework esta.lishes a different component in the software process@ resulting in an increase in the process capa.ilit( of the organi ation.
Organi ing the "## into the five levels shown in )igure +.' prioriti es improvement actions for increasing software process maturit(. The la.eled arrows in )igure +.' indicate the t(pe of process capa.ilit( .eing institutionali ed .( the organi ation at each step of the maturit( framework.
CMU/SEI-93-TR-24
Continuo usly
Optimizi ng
improvin g (5) process
Predictable
Managed
process
(4)
Standard, consistent process
Defined (3)
Disciplined process
Repeatable (2)
Initial (1)
Figure "#$ The Five Levels of !oftware rocess Maturity
The following characteri ations of the five maturit( levels highlight the primar( process changes made at each level;
1& Initial The software process is characteri ed as ad hoc@ and occasionall( even chaotic. )ew processes are defined@ and success depends on individual effort.
Capability
Maturity Model
CMU/SEI-93-TR-24

2& Re'eata(le 2asic proFect management processes are esta.lished to track cost@ schedule@ and functionalit(. The necessar( process discipline is in place to repeat earlier successes on proFects with similar applications.
3& )e ine* The software process for .oth management and engineering activities is documented@ standardi ed@ and integrated into a standard software process for the organi ation. All proFects use an approved@ tailored version of the organi ationAs standard software process for developing and maintaining software.
4& Manage* $etailed measures of the software process and product Eualit( are collected. 2oth the software process and products are Euantitativel( understood and controlled.
+& ,'ti$i-ing "ontinuous process improvement is ena.led .( Euantitative feed.ack from the process and from piloting innovative ideas and technologies.
+.'
%ehavioral Characteri&ation of the Maturity Levels
#aturit( 0evels + through 6 can .e characteri ed through the activities performed .( the organi ation to esta.lish or improve the software process@ .( activities performed on each proFect@ and .( the resulting process capa.ilit( across proFects. A .ehavioral characteri ation of 0evel ' is included to esta.lish a .ase of comparison for process improvements at higher maturit( levels.
CMU/SEI-93-TR-24

+.'.'
Level $ ' The (nitial Level

At the &nitial 0evel@ the organi ation t(picall( does not provide a sta.le environment for developing and maintaining software. When an organi ation lacks sound management practices@ the .enefits of good software engineering practices are undermined .( ineffective planning and reaction4driven commitment s(stems.
$uring a crisis@ proFects t(picall( a.andon planned procedures and revert to coding and testing. Success depends entirel( on having an e!ceptional manager and a seasoned and effective software team. Occasionall(@ capa.le and forceful software managers can withstand the pressures to take shortcuts in the software processD .ut when the( leave the proFect@ their sta.ili ing influence leaves with them. 9ven a strong engineering process cannot overcome the insta.ilit( created .( the a.sence of sound management practices.
The software process capa.ilit( of 0evel ' organi ations is unpredicta.le .ecause the software process is constantl( changed or modified as the work progresses Gi.e.@ the process is ad hocH. Schedules@ .udgets@ functionalit(@ and product Eualit( are generall( unpredicta.le. Performance depends on the capa.ilities of individuals and varies with their innate skills@ knowledge@ and motivations. There are few sta.le software processes in evidence@ and performance can .e predicted onl( .( individual rather than organi ational capa.ilit(.
+.'.+
Level " ' The Repeatable Level

At the Repeata.le 0evel@ policies for managing a software proFect and procedures to implement those policies are esta.lished. Planning and managing new proFects is .ased on e!perience with similar proFects. An o.Fective in achieving 0evel + is to institutionali e effective management
'5
CMU/SEI-93-TR-24

processes for software proFects@ which allow organi ations to repeat successful practices developed on earlier proFects@ although the specific processes implemented .( the proFects ma( differ. An effective process can .e characteri ed as practiced@ documented@ enforced@ trained@ measured@ and a.le to improve.
ProFects in 0evel + organi ations have installed .asic software management controls. Realistic proFect commitments are .ased on the results o.served on previous proFects and on the reEuirements of the current proFect. The software managers for a proFect track software costs@ schedules@ and functionalit(D pro.lems in meeting commitments are identified when the( arise. Software reEuirements and the work products developed to satisf( them are .aselined@ and their integrit( is controlled. Software proFect standards are defined@ and the organi ation ensures the( are faithfull( followed. The software proFect works with its su.contractors@ if an(@ to esta.lish a strong customer4supplier relationship.
The software process capa.ilit( of 0evel + organi ations can .e summari ed as disciplined .ecause planning and tracking of the software proFect is sta.le and earlier successes can .e repeated. The proFectAs process is under the effective control of a proFect management s(stem@ following realistic plans .ased on the performance of previous proFects.
+.'.-
Level ) ' The *efined Level

At the $efined 0evel@ the standard process for developing and maintaining software across the organi ation is documented@ including .oth software engineering and management processes@ and these processes are integrated into a coherent whole. This standard process is referred to throughout the "## as the organi ationAs standard software process. Processes esta.lished at 0evel - are used Gand changed@ as appropriateH to help the software managers and technical staff perform more effectivel(. The organi ation e!ploits effective software engineering practices when standardi ing its software processes. There is a group that is responsi.le for the
CMU/SEI-93-TR-24
''

organi ationAs software process activities@ e.g.@ a software engineering process group@ or S9P< B)owler35C. An organi ation4wide training program is implemented to ensure that the staff and managers have the knowledge and skills reEuired to fulfill their assigned roles.
ProFects tailor the organi ationAs standard software process to develop their own defined software process@ which accounts for the uniEue characteristics of the proFect. This tailored process is referred to in the "## as the proFectAs defined software process. A defined software process contains a coherent@ integrated set of well4defined software engineering and management processes. A well4defined process can .e characteri ed as including readiness criteria@ inputs@ standards and procedures for performing the work@ verification mechanisms Gsuch as peer reviewsH@ outputs@ and completion criteria. 2ecause the software process is well defined@ management has good insight into technical progress on all proFects.
The software process capa.ilit( of 0evel organi ations can .e summari ed as standard and consistent .ecause .oth software engineering and management activities are sta.le and repeata.le. Within esta.lished product lines@ cost@ schedule@ and functionalit( are under control@ and software Eualit( is tracked. This process capa.ilit( is .ased on a common@ organi ation4wide understanding of the activities@ roles@ and responsi.ilities in a defined software process.
+.'./
Level + ' The Managed Level
At the #anaged 0evel@ the organi ation sets Euantitative Eualit( goals for .oth software products and processes. Productivit( and Eualit( are measured for important software process activities across all proFects as part of an organi ational measurement program. An organi ation4wide software process data.ase is used to collect and anal( e the data availa.le from the proFectsA defined software processes. Software processes are instrumented with well4 defined and consistent measurements at 0evel /.
'+
CMU/SEI-93-TR-24

These measurements esta.lish the Euantitative foundation for evaluating the proFectsA software processes and products.
ProFects achieve control over their products and processes .( narrowing the variation in their process performance to fall within accepta.le Euantitative .oundaries. #eaningful variations in process performance can .e distinguished from random variation GnoiseH@ particularl( within esta.lished product lines. The risks involved in moving up the learning curve of a new application domain are known and carefull( managed.
The software process capa.ilit( of 0evel / organi ations can .e summari ed as predicta.le .ecause the process is measured and operates within measura.le limits. This level of process capa.ilit( allows an organi ation to predict trends in process and product Eualit( within the Euantitative .ounds of these limits. When these limits are e!ceeded@ action is taken to correct the situation. Software products are of predicta.l( high Eualit(.
+.'.6
Level , ' The Optimi&ing Level

At the Optimi ing 0evel@ the entire organi ation is focused on continuous process improvement. The organi ation has the means to identif( weaknesses and strengthen the process proactivel(@ with the goal of preventing the occurrence of defects. $ata on the effectiveness of the software process is used to perform cost .enefit anal(ses of new technologies and proposed changes to the organi ationAs software process. &nnovations that e!ploit the .est software engineering practices are identified and transferred throughout the organi ation.
Software proFect teams in 0evel 6 organi ations anal( e defects to determine their causes. Software processes are evaluated to prevent known t(pes of defects from recurring@ and lessons learned are disseminated to other proFects.
CMU/SEI-93-TR-24
'-

The software process capa.ilit( of 0evel 6 organi ations can .e characteri ed as continuousl( improving .ecause 0evel 6 organi ations are continuousl( striving to improve the range of their process capa.ilit(@ there.( improving the process performance of their proFects. &mprovement occurs .oth .( incremental advancements in the e!isting process and .( innovations using new technologies and methods.
+.+
-nderstanding the Maturity Levels

The "## is a descriptive model in the sense that it descri.es essential Gor ke(H attri.utes that would .e e!pected to characteri e an organi ation at a particular maturit( level. &t is a normative model in the sense that the detailed practices characteri e the normal t(pes of .ehavior that would .e e!pected in an organi ation doing large4scale proFects in a government contracting conte!t. The intent is that the "## is at a sufficient level of a.straction that it does not undul( constrain how the software process is implemented .( an organi ationD it simpl( descri.es what the essential attri.utes of a software process would normall( .e e!pected to .e.
&n an( conte!t in which the "## is applied@ a reasona.le interpretation of the practices should .e used. The "## must .e appropriatel( interpreted@ using informed professional Fudgment@ when the .usiness environment of the organi ation differs significantl( from that of a large contracting organi ation.
The "## is not prescriptiveD it does not tell an organi ation how to improve. The "## descri.es an organi ation at each maturit( level without prescri.ing the specific means for getting there. &t can take several (ears to move from 0evel ' to 0evel +@ and moving .etween the other levels will usuall( take on the order of two (ears.
'/
CMU/SEI-93-TR-24

Software process improvement occurs within the conte!t of the organi ationAs strategic plans and .usiness o.Fectives@ its organi ational structure@ the technologies in use@ its social culture@ and its management s(stem. The "## focuses on the process aspects of a Total ?ualit( #anagement effortD successful process improvement implies that aspects outside the scope of software process are also addressed Ge.g.@ the people issues involved with changing the organi ational culture that ena.le the process improvements to .e implemented and institutionali edH.
+.+.'
-nderstanding the (nitial Level

Although 0evel ' organi ations are freEuentl( characteri ed as having ad hoc@ even chaotic@ processes@ the( freEuentl( develop products that work@ even though the( ma( .e over the .udget and schedule. Success in 0evel ' organi ations depends on the competence and heroics of the people in the organi ation. Selecting@ hiring@ developing@ andIor retaining competent people are significant issues for organi ations at all levels of maturit(@ .ut the( are largel( outside the scope of the "##.
+.+.+
-nderstanding the Repeatable and *efined Levels

As proFects grow in si e and comple!it(@ attention shifts from technical issues to organi ational and managerial issues J the focus of process maturit( BSiegel35@ $o$=1@ <AO43+4/=C. Process ena.les people to work more effectivel( .( incorporating the lessons learned .( the .est staff into documented processes@ .uilding the skills needed to perform those processes effectivel( Gusuall( via trainingH@ and continuall( improving .( learning from the people performing the Fo..
To achieve 0evel +@ management must focus on its own processes to achieve a disciplined software process. 0evel + provides the foundation for 0evel - .ecause the focus is on management acting to improve its processes
CMU/SEI-93-TR-24
'6

.efore tackling technical and organi ational issues at 0evel -. #anagement esta.lishes a leadership position in achieving 0evel + .( documenting and following proFect management processes.
Processes ma( differ .etween proFects in a 0evel + organi ationD the organi ational reEuirement for achieving 0evel + is that there are policies that guide the proFects in esta.lishing the appropriate management processes. $ocumented procedures provide the foundation for consistent processes that can .e institutionali ed across the organi ation@ with the aid of training and software Eualit( assurance.
0evel - .uilds on this proFect management foundation .( defining@ integrating@ and documenting the entire software process. &ntegration in this case means that the outputs of one task flow smoothl( into the inputs of the ne!t task. When there are mismatches .etween tasks@ the( are identified and addressed in the planning stages of the software process@ rather than when the( are encountered while enacting the process. One of the challenges of 0evel - is to .uild processes that empower the individuals doing the work without .eing overl( rigid BHumphre( 3'.C.
+.+.-
-nderstanding the Optimi&ing Levels
Managed
and
#aturit( 0evels / and 6 are relativel( unknown territor( for the software industr(. There are onl( a few e!amples of 0evel / and 6 software proFects and organi ations BHumphre(3'a@ 8itson3+C. There are too few to draw general
conclusions a.out the characteristics of 0evel / and 6 organi ations. The characteristics of these levels have .een defined .( analog( with other industries and the few e!amples in the software industr( e!hi.iting this level of process capa.ilit(.
#an( characteristics of 0evels / and 6 are .ased on the concepts of statistical process control as e!emplified in )igure +.+. The >uran Trilog( $iagram B>uran==C illustrates the primar( o.Fectives of process management.
'7
CMU/SEI-93-TR-24
Quality Planning
Quality Control (during operations)

Sporadic spike
poor quali ty
Chronic waste
Original zone of
quality control
of Cost
New zone of quality control
Quality Improvement Time
Lessons learned
J.M. Juran Wilton, CT Used with the express permission of the Juran Institute, Aug, 1990.
Figure "#" The .uran Trilogy *iagram/ 0uality lanning1 0uality Control1 and 0uality (mprovement
>uran .reaks Eualit( management into three .asic managerial processes B>uran==C. The purpose of Eualit( planning is to provide the operating forces@ i.e.@ the software producers@ with the means of producing products that can meet customer needs. The operating forces produce the product@ .ut some rework must .e done .ecause of Eualit( deficiencies. This waste is chronic .ecause the process was planned that wa(D Eualit( control is carried out to prevent things from getting worse. Sporadic spikes in the process@ as shown in )igure +.+@ represent fire fighting activities. "hronic waste provides an opportunit( for improvementD sei ing that opportunit( is referred to as Eualit( improvement.
CMU/SEI-93-TR-24
'1

The first responsi.ilit(@ and the focus of 0evel /@ is process control. The software process is managed so that it operates sta.l( within a one of Eualit( control. There is inevita.l( some chronic waste@ and there ma( .e spikes in the measured results that need to .e controlled@ .ut the s(stem is generall( sta.le overall. This is where the concept of controlling special causes of variation comes into pla(. 2ecause the process is .oth sta.le and measured@ when some e!ceptional circumstance occurs@ the Kspecial causeK of the variation can .e identified and addressed.
The second responsi.ilit(@ and the focus of 0evel 6@ is continuous process improvement. The software process is changed to improve Eualit(@ and the one of Eualit( control moves. A new .aseline for performance is esta.lished that reduces chronic waste. The lessons learned in improving such a process are applied in planning future processes. This is where the concept of addressing common causes of variation comes to the fore. There is chronic waste@ in the form of rework@ in an( s(stem simpl( due to random variation. Waste is unaccepta.leD organi ed efforts to remove waste result in changing the s(stem@ i.e.@ improving the process .( changing Kcommon causesK of inefficienc( to prevent the waste from occurring.
&t is anticipated that organi ations reaching the highest maturit( levels of the "## would have a process that is capa.le of producing e!tremel( relia.le software within predicta.le cost and schedule limits. As understanding of the higher maturit( levels grows@ the e!isting ke( process areas will .e refined@ and others ma( .e added to the model. The "## is derived from ideas a.out process that were inspired in manufacturing@ .ut software processes are not dominated .( replication issues like a manufacturing process is. The software process is dominated .( design issues and is a knowledge4intensive activit( B"urtis==C.
'=
CMU/SEI-93-TR-24
+.-
2isibility (nto the !oftware rocess

Software engineers have detailed insight into the state of a proFect .ecause the( have first4hand information on proFect status and performance. However@ on large proFects their insight usuall( is drawn onl( from their personal e!perience in their area of responsi.ilit(. Those outside the proFect without first4hand e!posure@ such as senior managers@ lack visi.ilit( into the proFectAs processes and rel( on periodic reviews for the information the( reEuire to monitor progress. )igure +.- illustrates the level of visi.ilit( into proFect status and performance afforded to management at each level of process maturit(. 9ach succeeding maturit( level incrementall( provides .etter visi.ilit( into the software process.
CMU/SEI-93-TR-24
'3
In
O ut
In
O ut
In
O ut
In
O ut
In
Out
Figure "#) A Management 2iew of 2isibility (nto the !oftware rocess at 3ach Maturity Level
At 0evel '@ the software process is an amorphous entit( J a .lack .o! J and visi.ilit( into the proFectAs processes is limited. Since the staging of activities is poorl( defined@ managers have an e!tremel( difficult time esta.lishing the status of the proFectAs progress and activities.
/
/
This leads to the :inet(4:inet( Rule; 35L of the proFect is complete 35L of the time.
+5
CMU/SEI-93-TR-24

ReEuirements flow into the software process in an uncontrolled manner@ and a product results. Software development is freEuentl( viewed as .lack magic@ especiall( .( managers who are unfamiliar with software.
At 0evel +@ the customer reEuirements and work products are controlled@ and .asic proFect management practices have .een esta.lished. These management controls allow visi.ilit( into the proFect on defined occasions. The process of .uilding the software can .e viewed as a succession of .lack .o!es that allows management visi.ilit( at transition points as activit( flows .etween .o!es GproFect milestonesH. 9ven though management ma( not know the details of what is happening in the .o!@ the products of the process and checkpoints for confirming that the process is working are identified and known. #anagement reacts to pro.lems as the( occur.
At 0evel -@ the internal structure of the .o!es@ i.e.@ the tasks in the proFectAs defined software process@ is visi.le. The internal structure represents the wa( the organi ationAs standard software process has .een applied to specific proFects. 2oth managers and engineers understand their roles and responsi.ilities within the process and how their activities interact at the appropriate level of detail. #anagement proactivel( prepares for risks that ma( arise. &ndividuals e!ternal to the proFect can o.tain accurate and rapid status updates .ecause defined processes afford great visi.ilit( into proFect activities.
At 0evel /@ the defined software processes are instrumented and controlled Euantitativel(. #anagers are a.le to measure progress and pro.lems. The( have an o.Fective@ Euantitative .asis for making decisions. Their a.ilit( to predict outcomes grows steadil( more precise as the varia.ilit( in the process grows smaller.
At 0evel 6@ new and improved wa(s of .uilding the software are continuall( tried@ in a controlled manner@ to improve productivit( and Eualit(. $isciplined change is a wa( of life as inefficient or defect4prone activities are identified and replaced or revised. &nsight e!tends .e(ond e!isting processes
CMU/SEI-93-TR-24
+'

and into the effects of potential changes to processes. #anagers are a.le to estimate and then track Euantitativel( the impact and effectiveness of change.
+./
rocess Capability and the rediction of erformance

The maturit( of an organi ationAs software process helps to predict a proFectAs a.ilit( to meet its goals. ProFects in 0evel ' organi ations e!perience wide variations in achieving cost@ schedule@ functionalit(@ and Eualit( targets. As illustrated in )igure +./@ three improvements in meeting targeted goals are o.served as the organi ationAs software process matures.
)irst@ as maturit( increases@ the difference .etween targeted results and actual results decreases across proFects. )or instance@ if ten proFects of the same si e were targeted to .e delivered on #a( '@ then the average date of their deliver( would move closer to #a( ' as the organi ation matures. 0evel ' organi ations often miss their originall( scheduled deliver( dates .( a wide margin@ whereas 0evel 6 organi ations should .e a.le to meet targeted dates with considera.le accurac(. This is .ecause 0evel 6 organi ations use a carefull( constructed software process operating within known parameters@ and the selection of the target date is .ased on the e!tensive data the( possess a.out their process and on their performance in appl(ing it. GThis is illustrated in )igure +./ .( how much of the area under the curve lies to the right of the target line.H
++
CMU/SEI-93-TR-24

T a r g e t N
5
T a r g e t N z
Time/$/...
P r Time/$/...
4
T a r g e t N y
P r Time/$/...
P r
Time/$/...
T a
P r P r
Time/$/...
T a
organizations
Performance continuously improves in Level 5 organizations
Based on quantitative understanding of process and product, performance continues to improve in Level 4 organizations
Plans based on past performance are more realistic in Level 2 organizations
With well-defined processes, performance improves in Level 3
Schedule and cost targets are typically overrun by Level 1 organizations.
Figure "#+ Level
rocess Capability as (ndicated by Maturity
CMU/SEI-93-TR-24
+-

Second@ as maturit( increases@ the varia.ilit( of actual results around targeted results decreases. )or instance@ in 0evel ' organi ations deliver( dates for proFects of similar si e are unpredicta.le and var( widel(. Similar proFects in a 0evel 6 organi ation@ however@ will .e delivered within a much smaller range. This narrowed variation occurs at the highest maturit( levels .ecause virtuall( all proFects are performing within controlled parameters approaching the organi ationAs process capa.ilit( for cost@ schedule@ functionalit(@ and Eualit(. GThis is illustrated in )igure +./ .( how much of the area under the curve is concentrated near the target line.H
Third@ targeted results improve as the maturit( of the organi ation increases. That is@ as a software organi ation matures@ costs decrease@ development time .ecomes shorter@ and productivit( and Eualit( increase. &n a 0evel ' organi ation@ development time can .e Euite long .ecause of the amount of rework that must .e performed to correct mistakes. &n contrast@ 0evel 6 organi ations use continuous process improvement and defect prevention techniEues to increase process efficienc( and eliminate costl( rework@ allowing development time to .e shortened. GThis is illustrated in )igure +./ .( the hori ontal displacement of the target line from the origin.H
The improvements in predicting a proFectAs results represented in )igure +./ assume that the software proFectAs outcomes .ecome more predicta.le as noise@ often in the form of rework@ is removed from the software process. ,nprecedented s(stems complicate the picture since new technologies and applications lower the process capa.ilit( .( increasing varia.ilit(. 9ven in the case of unprecedented s(stems@ the management and engineering practices characteristic of more mature organi ations help identif( and address pro.lems earlier in the development c(cle than the( would have .een detected in less mature organi ations. 9arlier detection of defects contri.utes to proFect sta.ilit(
and performance .( eliminating the rework during later phases. Risk management is an integral part of proFect management in a mature process. &n some cases a mature process means that KfailedK proFects are identified earl( in the software life c(cle and investment in a lost cause is minimi ed.
+/
CMU/SEI-93-TR-24
+.6
!kipping Maturity Levels

The maturit( levels in the "## descri.e the characteristics of an organi ation at a maturit( level. 9ach level .uilds a foundation for succeeding levels to leverage for implementing processes effectivel( and efficientl(. Organi ations can@ however@ profita.l( use processes descri.ed at a higher maturit( level than the( are. 9ngineering processes@ such as reEuirements anal(sis@ design@ code@ and test@ are not discussed in the "## until 0evel -@ (et even 0evel ' organi ations must perform these activities. A 0evel ' or 0evel + organi ation ma( .e a.le to perform peer reviews G0evel -H@ do Pareto anal(sis G0evel /H@ or pilot new technologies G0evel 6H profita.l(. When prescri.ing what steps an organi ation should take to move from 0evel ' to 0evel +@ freEuentl( one of the recommendations is to esta.lish a software engineering process group@ which is an attri.ute of 0evel - organi ations. Although measurement is the focus of 0evel /@ it is also an integral part of the lower maturit( levels.
These processes cannot reach their full potential@ however@ until the proper foundation is laid. Peer reviews cannot .e full( effective@ for e!ample@ unless the( are consistentl( implemented@ even when fires threaten the proFect. The maturit( levels descri.e the pro.lems that predominate at a level. The dominant pro.lems of a 0evel ' organi ation are managerialD other pro.lems tend to .e masked .( the difficulties in planning and managing software proFects.
Skipping levels is counterproductive .ecause each level forms a necessar( foundation from which to achieve the ne!t level. The "## identifies the levels through which an organi ation must evolve to esta.lish a culture of software engineering e!cellence. Processes without the proper foundation fail at the ver( point the( are needed most J under stress J and the( provide no .asis for future improvement.
CMU/SEI-93-TR-24
+6

A 0evel ' organi ation that is tr(ing to implement a defined process G0evel -H .efore it has esta.lished a repeata.le process G0evel +H is usuall( unsuccessful .ecause proFect managers are overwhelmed .( schedule and cost pressures. This is the fundamental reason for focusing on management processes .efore engineering processes. &t ma( seem easier to define and implement an engineering process than a management process Gespeciall( in the e(es of technical peopleH@ .ut without management discipline@ the engineering process is sacrificed to schedule and cost pressures BHumphre(==C.
An organi ation that is tr(ing to implement a managed process G0evel /H without the foundation of a defined process is usuall( unsuccessful .ecause there is no common .asis for interpreting measurements without defined processes. While data can .e collected for individual proFects@ few of the measurements have significant meaning across proFects@ and the( do not significantl( increase organi ational understanding of the software process. &t is difficult to identif( meaningful measurements in the a.sence of defined processes .ecause of the variation in the processes .eing measured.
An organi ation that is tr(ing to implement an optimi ing process G0evel 6H without the foundation of a managed process G0evel /H is likel( to fail .ecause of a lack of understanding of the impact of process changes. Without controlling the process within statisticall( narrow .oundaries Gsmall variations in process measuresH@ there is too much noise in the data to determine o.Fectivel( whether a specific process improvement has an effect. $ecisions can degenerate into religious wars .ecause little Euantitative foundation e!ists for making rational@ informed decisions.
The process improvement effort should focus on the needs of the organi ation in the conte!t of its .usiness environment. The a.ilit( to implement processes from higher maturit( levels does not impl( that maturit( levels can .e skipped.
+7
CMU/SEI-93-TR-24
Operational *efinition of the Capability Maturity Model

The "## is a framework representing a path of improvements recommended for software organi ations that want to increase their software process capa.ilit(. This operational ela.oration of the "## is designed to support the man( wa(s it will .e used. There are at least four uses of the "## that are supported; Assessments teams will use the "## to identif( strengths and weaknesses in the organi ation. 9valuation teams will use the "## to identif( the risks of selecting among different contractors for awarding .usiness and to monitor contracts. #anagers and technical staff will use the "## to understand the activities necessar( to plan and implement a software process improvement program for their organi ation. Process improvement groups@ such as an S9P<@ will use the "## as a guide to help them define and improve the software process in their organi ation.
2ecause of the diverse uses of the "##@ it must .e decomposed in sufficient detail that actual process recommendations can .e derived from the structure of the maturit( levels. This decomposition also indicates the processes and their structure that characteri es software process maturit( and software process capa.ilit(.
-.'
(nternal !tructure of the Maturity Levels

9ach maturit( level has .een decomposed into constituent parts. With the e!ception of 0evel '@ the decomposition of each maturit( level ranges from a.stract summaries of each level down to their operational definition in the ke( practices@ as shown in )igure -.'. 9ach maturit( level is composed of several ke( process areas. 9ach ke( process area is organi ed into five
CMU/SEI-93-TR-24
+1

sections called common features. The common features specif( the ke( practices that@ when collectivel( addressed@ accomplish the goals of the ke( process area.
+=
CMU/SEI-93-TR-24
Maturity Levels
indicate contain Process
Capability
Key Process Areas

achieve organized by
Goals
Common Features
address
contain
Implementation or Institutionalization
Key Practices
describe
Infrastructure or Activities
Figure )#$ The CMM !tructure
CMU/SEI-93-TR-24
Capability Maturity
Model
+3
-.+
Maturity Levels
A maturit( level is a well4defined evolutionar( plateau toward achieving a mature software process. 9ach maturit( level indicates a level of process capa.ilit(@ as was illustrated in )igure +.'. )or instance@ at 0evel + the process capa.ilit( of an organi ation has .een elevated from ad hoc to disciplined .( esta.lishing sound proFect management controls.
-.-
4ey rocess Areas

9!cept for 0evel '@ each maturit( level is decomposed into several ke( process areas that indicate the areas an organi ation should focus on to improve its software process. 8e( process areas identif( the issues that must .e addressed to achieve a maturit( level.
9ach .ey 'ro#ess area identifies a cluster of related activities that@ when performed collectivel(@ achieve a set of goals considered important for enhancing process capa.ilit(. The ke( process areas have .een defined to reside at a single maturit( level as shown in )igure -.+. The path to achieving the goals of a ke( process area ma( differ across proFects .ased on differences in application domains or environments. :evertheless@ all the goals of a ke( process area must .e achieved for the organi ation to satisf( that ke( process area. When the goals of a ke( process area are accomplished on a continuing .asis across proFects@ the organi ation can .e said to have institutionali ed the process capa.ilit( characteri ed .( the ke( process area.
-5
CMU/SEI-93-TR-24
Optimizing (5)
Process change management Technology change management Defect prevention
Managed (4)
Software quality management Quantitative process management
Defined (3)
Peer reviews Intergroup coordination Software product engineering Integrated software management Training program Organization process definition Organization process focus
Repeatable (2)
Software configuration management Software quality assurance Software subcontract management Software project tracking and oversight Software project planning Requirements management
Initial (1)
Figure )#" The 4ey rocess Areas by Maturity Level
CMU/SEI-93-TR-24
-'

The adFective Kke(K implies that there are process areas Gand processesH that are not ke( to achieving a maturit( level. The "## does not descri.e all the process areas in detail that are involved with developing and maintaining software. "ertain process areas have .een identified as ke( determiners of process capa.ilit(D these are the ones descri.ed in the "##.
Although other issues affect process performance@ the ke( process areas were identified .ecause of their effectiveness in improving an organi ationAs software process capa.ilit(. The( ma( .e considered the reEuirements for achieving a maturit( level. )igure -.+ displa(s the ke( process areas for each maturit( level. To achieve a maturit( level@ the ke( process areas for that level must .e satisfied. To satisf( a ke( process area@ each of the goals for the ke( process area must .e satisfied. The goals summari e the ke( practices of a ke( process area and can .e used to determine whether an organi ation or proFect has effectivel( implemented the ke( process area. The goals signif( the scope@ .oundaries@ and intent of each ke( process area.
6
The specific practices to .e e!ecuted in each ke( process area will evolve as the organi ation achieves higher levels of process maturit(. )or instance@ man( of the proFect estimating capa.ilities descri.ed in the Software ProFect Planning ke( process area at 0evel + must evolve to handle the additional proFect data availa.le at 0evels -@ /@ and 6. &ntegrated Software #anagement at 0evel - is the evolution of Software ProFect Planning and Software ProFect Tracking and Oversight at 0evel + as the proFect is managed using a defined software process.
The ke( process areas of the "## represent one wa( of descri.ing how organi ations mature. These ke( process areas were defined .ased on man( (ears of e!perience in software engineering and management and over five (ears of e!perience with software process assessments and software capa.ilit( evaluations.
)or a listing of the goals for each ke( process area@ refer to Appendi! A.
-+
CMU/SEI-93-TR-24

The ke( process areas at 0evel + focus on the software proFectAs concerns related to esta.lishing .asic proFect management controls. $escriptions of each of the ke( process areas for 0evel + are given .elow;
The purpose of ReEuirements #anagement is to esta.lish a common understanding .etween the customer and the software proFect of the customerAs reEuirements that will .e addressed .( the software proFect. This agreement with the customer is the .asis for planning Gas descri.ed in Software ProFect PlanningH and managing Gas descri.ed in Software ProFect Tracking and OversightH the software proFect. "ontrol of the relationship with the customer depends on following an effective change control process Gas descri.ed in Software "onfiguration #anagementH.
The purpose of Software ProFect Planning is to esta.lish reasona.le plans for performing the software engineering and for managing the software proFect. These plans are the necessar( foundation for managing the software proFect Gas descri.ed in Software ProFect Tracking and OversightH. Without realistic plans@ effective proFect management cannot .e implemented.
The purpose of Software ProFect Tracking and Oversight is to esta.lish adeEuate visi.ilit( into actual progress so that management can take effective actions when the software proFectAs performance deviates significantl( from the software plans. The purpose of Software Su.contract #anagement is to select Eualified software su.contractors and manage them effectivel(. &t com.ines the concerns of ReEuirements #anagement@ Software ProFect Planning@ and Software ProFect Tracking and Oversight for .asic management control@ along with necessar( coordination of Software ?ualit( Assurance and Software "onfiguration #anagement@ and applies this control to the su.contractor as appropriate.
CMU/SEI-93-TR-24
--

The purpose of Software ?ualit( Assurance is to provide management with appropriate visi.ilit( into the process .eing used .( the software proFect and of the products .eing .uilt. Software ?ualit( Assurance is an integral part of most software engineering and management processes.
The purpose of Software "onfiguration #anagement is to esta.lish and maintain the integrit( of the products of the software proFect throughout the proFectAs software life c(cle. Software "onfiguration #anagement is an integral part of most software engineering and management processes.
The ke( process areas at 0evel - address .oth proFect and organi ational issues@ as the organi ation esta.lishes an infrastructure that institutionali es effective software engineering and management processes across all proFects. $escriptions of each of the ke( process areas for 0evel - are given .elow;
The purpose of Organi ation Process )ocus is to esta.lish the organi ational responsi.ilit( for software process activities that improve the organi ationAs overall software process capa.ilit(. The primar( result of the Organi ation Process )ocus activities is a set of software process assets@ which are descri.ed in Organi ation Process $efinition. These assets are used .( the software proFects@ as is descri.ed in &ntegrated Software #anagement.
The purpose of Organi ation Process $efinition is to develop and maintain a usa.le set of software process assets that improve process performance across the proFects and provide a .asis for cumulative@ long4term .enefits to the organi ation. These assets provide a sta.le foundation that can .e institutionali ed via mechanisms such as training@ which is descri.ed in Training Program.
-/
CMU/SEI-93-TR-24

The purpose of Training Program is to develop the skills and knowledge of individuals so the( can perform their roles effectivel( and efficientl(. Training is an organi ational responsi.ilit(@ .ut the software proFects should identif( their needed skills and provide the necessar( training when the proFectAs needs are uniEue. The purpose of &ntegrated Software #anagement is to integrate the software engineering and management activities into a coherent@ defined software process that is tailored from the organi ationAs standard software process and related process assets@ which are descri.ed in Organi ation Process $efinition. This tailoring is .ased on the .usiness environment and technical needs of the proFect@ as descri.ed in Software Product 9ngineering. &ntegrated Software #anagement evolves from Software ProFect Planning and Software ProFect Tracking and Oversight at 0evel +.
The purpose of Software Product 9ngineering is to consistentl( perform a well4 defined engineering process that integrates all the software engineering activities to produce correct@ consistent software products effectivel( and efficientl(. Software Product 9ngineering descri.es the technical activities of the proFect@ e.g.@ reEuirements anal(sis@ design@ code@ and test.
The purpose of &ntergroup "oordination is to esta.lish a means for the software engineering group to participate activel( with the other engineering groups so the proFect is .etter a.le to satisf( the customerAs needs effectivel( and efficientl(. &ntergroup "oordination is the interdisciplinar( aspect of &ntegrated Software #anagement that e!tends .e(ond software engineeringD not onl( should the software process .e integrated@ .ut the software engineering groupAs interactions with other groups must .e coordinated and controlled.
The purpose of Peer Reviews is to remove defects from the software work products earl( and efficientl(. An important corollar( effect is to
CMU/SEI-93-TR-24
-6

develop a .etter understanding of the software work products and of the defects that can .e prevented. The peer review is an important and effective engineering method that is called out in Software Product 9ngineering and that can .e implemented via )agan4st(le inspections B)agan=7C@ structured walkthroughs@ or a num.er of other collegial review methods B)reedman35C.
The ke( process areas at 0evel / focus on esta.lishing a Euantitative understanding of .oth the software process and the software work products .eing .uilt. The two ke( process areas at this level@ ?uantitative Process #anagement and Software ?ualit( #anagement@ are highl( interdependent@ as is descri.ed .elow;
The purpose of ?uantitative Process #anagement is to control the process performance of the software proFect Euantitativel(. Software process performance represents the actual results achieved from following a software process. The focus is on identif(ing special causes of variation within a measura.l( sta.le process and correcting@ as appropriate@ the circumstances that drove the transient variation to occur. ?uantitative Process #anagement adds a comprehensive measurement program to the practices of Organi ation Process $efinition@ &ntegrated Software #anagement@ &ntergroup "oordination@ and Peer Reviews.
The purpose of Software ?ualit( #anagement is to develop a Euantitative understanding of the Eualit( of the proFectAs software products and achieve specific Eualit( goals. Software ?ualit( #anagement applies a comprehensive measurement program to the software work products descri.ed in Software Product 9ngineering.
The ke( process areas at 0evel 6 cover the issues that .oth the organi ation and the proFects must address to implement continuous and measura.le software process improvement. $escriptions of each of the ke( process areas for 0evel 6 are given .elow;
-7
CMU/SEI-93-TR-24

The purpose of $efect Prevention is to identif( the causes of defects and prevent them from recurring. The software proFect anal( es defects@ identifies their causes@ and changes its defined software process@ as is descri.ed in &ntegrated Software #anagement. Process changes of general value are transitioned to other software proFects@ as is descri.ed in Process "hange #anagement.
The purpose of Technolog( "hange #anagement is to identif( .eneficial new technologies Gi.e.@ tools@ methods@ and processesH and transfer them into the organi ation in an orderl( manner@ as is descri.ed in Process "hange #anagement. The focus of Technolog( "hange #anagement is on performing innovation efficientl( in an ever4changing world.
The purpose of Process "hange #anagement is to continuall( improve the software processes used in the organi ation with the intent of improving software Eualit(@ increasing productivit(@ and decreasing the c(cle time for product development. Process "hange #anagement takes the incremental improvements of $efect Prevention and the innovative improvements of Technolog( "hange #anagement and makes them availa.le to the entire organi ation.
-./
Common Features
)or convenience@ the ke( process areas are organi ed .( common features. The common features are attri.utes that indicate whether the implementation and institutionali ation of a ke( process area is effective@ repeata.le@ and lasting. The five common features are listed .elow;
CMU/SEI-93-TR-24
-1
Co$$it$ent to "er or$
"ommitment to Perform descri.es the actions the organi ation must take to ensure that the process is esta.lished and will endure. "ommitment to Perform t(picall( involves esta.lishing organi ational policies and senior management sponsorship.
/(ility to "er or$
A.ilit( to Perform descri.es the preconditions that must e!ist in the proFect or organi ation to implement the software process competentl(. A.ilit( to Perform t(picall( involves resources@ organi ational structures@ and training. Activities Performed descri.es the roles and procedures necessar( to implement a ke( process area. Activities Performed t(picall( involve esta.lishing plans and procedures@ performing the work@ tracking it@ and taking corrective actions as necessar(. #easurement and Anal(sis descri.es the need to measure the process and anal( e the measurements. #easurement and Anal(sis t(picall( includes e!amples of the measurements that could .e taken to determine the status and effectiveness of the Activities Performed. *erif(ing &mplementation descri.es the steps to
that the activities are performed in compliance with the
/#ti%ities "er or$e*
Measure$ent an* /nalysis
0eri ying
ensure
I$'le$entation
process that has .een esta.lished. *erification t(picall( encompasses reviews and audits .( management and software Eualit( assurance.
-=
CMU/SEI-93-TR-24

The practices in the common feature Activities Performed descri.e what must .e implemented to esta.lish a process capa.ilit(. The other practices@ taken as a whole@ form the .asis .( which an organi ation can institutionali e the practices descri.ed in the Activities Performed common feature.
-.6
4ey ractices
9ach ke( process area is descri.ed in terms of the ke( practices that contri.ute to satisf(ing its goals. The .ey 'ra#ti#es descri.e the infrastructure and activities that contri.ute most to the effective implementation and institutionali ation of the ke( process area.
9ach ke( practice consists of a single sentence@ often followed .( a more detailed description@ which ma( include e!amples and ela.oration. These ke( practices@ also referred to as the top4level ke( practices@ state the fundamental policies@ procedures@ and activities for the ke( process area. The components of the detailed description are freEuentl( referred to as su.practices. )igure -.- provides an e!ample of the structure underl(ing a ke( practice for the Software ProFect Planning ke( process area.
CMU/SEI-93-TR-24
-3
Maturity Level: Level 2, Repeatable

indicates contain s
Key Process Area:

Process Capability: disciplined process
Software Project Planning
achieves
organized by
Goal 1: Software estimates are documented for use in planning and tracking the software project.
Common Feature:
Activities Performed
addr ess contains
Implementation or Institutionalization: Implementatio n
Key Practice: Activity 9. Estimates for the size of the software work products (or changes to the size of software work products) are derived according to a documented procedure.
describes
Infrastructure or Activities: Acti vity
Figure )#) %uilding the CMM !tructure/ An 35ample of a 4ey ractice
/5
CMU/SEI-93-TR-24

As illustrated in )igure -.-@ to ensure consistent accomplishment of the goal of documenting plans for planning and tracking the proFect@ the organi ation must esta.lish a documented procedure for deriving estimates of software si e. &f these estimates are not developed from a documented procedure@ the( ma( var( wildl( as differences in si ing assumptions are never surfaced. The detailed description of what would .e e!pected in such a procedure includes using historical si e data@ documenting assumptions@ and reviewing the estimates. These criteria guide the Fudgment of whether a reasona.le si e estimating procedure is followed.
The ke( practices descri.e KwhatK is to .e done@ .ut the( should not .e interpreted as mandating KhowK the goals should .e achieved. Alternative practices ma( accomplish the goals of the ke( process area. The ke( practices should .e interpreted rationall( to Fudge whether the goals of the ke( process area are effectivel(@ although perhaps differentl(@ achieved. The ke( practices are contained in the K8e( Practices of the "apa.ilit( #aturit( #odel@ *ersion '.'K BPaulk3-.C@ along with guidance on their interpretation.
CMU/SEI-93-TR-24
/'
/+
CMU/SEI-93-TR-24
+ -sing the CMM

The "## esta.lishes a set of pu.lic in availa.le criteria descri.ing the characteristics of mature software organi ations. These criteria can .e used .( organi ations to improve their processes for developing and maintaining software@ or .( government or commercial organi ations to evaluate the risks of contracting a software proFect to a particular compan(. This chapter focuses on two S9&4developed methods for appraising the maturit( of an organi ationAs e!ecution of the software process; software process assessment and software capa.ilit( evaluation. So t!are 'ro#ess assess$ents are used to determine the state of an organi ationAs current software process@ to determine the high4 priorit( software process4related issues facing an organi ation@ and to o.tain the organi ational support for software process improvement. So t!are #a'a(ility e%aluations are used to identif( contractors who are Eualified to perform the software work or to monitor the state of the software process used on an e!isting software effort. This overview is not sufficient .( itself for readers to conduct either an assessment or evaluation. An(one wishing to appl( the "## through these methods should reEuest further information on assessment and evaluation training.
The "## is a common foundation for .oth software process assessments and software capa.ilit( evaluations. The purpose of the methods are Euite different@ however@ and there are significant differences in the specific methods used. 2oth are
.ased on the model and the products derived from it. The "##@ in conFunction with the "##4.ased products@ ena.les the methods to .e applied relia.l( and consistentl(.
CMU/SEI-93-TR-24
/-
-sing the CMM
/.'
!of tw are r oce ss Ass ess me nt an d !of tw are Ca pa bili ty 3v alu ati on Me tho ds
Software process assessment s focus on identif(ing improveme
nt priorities within an organi atio nAs own software process. Assessmen t teams use the "## to guide them in identif(ing and prioriti ing findings. These findings@ along with guidance provided .( the ke( practices in the "##@ are used G.( a software engineerin g process group@ for e!ampleH to plan an improveme nt strateg( for the organi atio n.
Software capa.ilit( evaluations are focused on identif(ing the risks associated
with a particular proFect or contract for .uilding high4 Eualit( software on schedule and within .udget. $uring the acEuisition process@ software capa.ilit( evaluations ma( .e performed on .idders. The findings of the evaluation@ as structured .( the "##@ ma( .e used to identif( the risks in selecting a particular contractor. 9valuations ma( also .e performed on e!isting contracts to monitor their process performanc e@ with the intent of identif(ing potential improveme
nts in the software process of the contractor.
The "## esta.lishes a common frame of reference for performing software process assessment s and software capa.ilit( evaluations . Although the two methods differ in purpose@ the methods use the "## as a foundation for appraising software process maturit(. )igure /.' provides a summar( description of the common steps in assessment s and
evaluations .

//
CMU/SEI-93-TR-24
-sing the CMM
( 2 )
Maturity Questio nnaire Team Selection samples the CMM

(1)
Findings R based e Interviews on the s and document CMM p review o s n s e A (4) n (5) a l y s i s On-site Visit
(3)
KP A Pr of ile
(6)
Figure +#$
Com mon !teps in !oftw are roce ss Asses sment s and !oftw are Capa
bility 3valu ations
The first step in is to select a team. This team should .e trained in the fundamental concepts of the "## as well as the specifics of the assessment or evaluation method. The mem.ers of the team should .e professionals knowledgea.le in software engineering and management.
CMU/SEI-93-TR-24
/6
-sing the CMM

The second step is to have representati ves from the site to .e assessed or evaluated complete the maturit( Euestionnai re and other diagnostic instruments . Once this activit( is completed@ the assessment or evaluation team performs a response anal(sis Gstep -H@ which tallies the responses to the Euestions and identifies those areas where further e!ploration is warranted. The areas to .e
investigate d correspond to the "## ke( process areas.
The team is now read( to visit the site .eing assessed or evaluated Gstep /H. 2eginning with the results of the response anal(sis@ the team conducts interviews and reviews documentat ion to gain an understandi ng of the software process followed .( the site. The ke( process areas and ke( practices in the "## guide the team mem.ers in Euestioning @ listening@ reviewing@
and s(nthesi in g the information received from the interviews and documents. The team applies professiona l Fudgment in deciding whether the siteAs implementa tion of the ke( process areas satisfies the relevant ke( process area goals. When there are clear differences .etween the ke( practices in the "## and the siteAs practices@ the team must document its rationale for Fudging that ke( process area.
7
At the end
of the on4 site period@ the team produces a list of findings Gstep 6H that identifies the strengths and weaknesse s of the organi ati onAs software process. &n a software process assessmen t@ the findings .ecome the .asis for recommen dations for process improvem entD in a software capa.ilit( evaluation@ the findings .ecome part of the risk anal(sis performed .( the acEuisition agenc(.
)inall(@ the team prepares a ke( process area profile Gstep 7H that shows the areas where the organi ati on has@ and has not@ satisfied the goals of the ke( process areas. A ke( process area can .e satisfied and still have associated findings@ provided the findings do not identif( maFor pro.lems that inhi.it achieving an( goals of the ke( process areas.
These Fudgements
ma( have to take place without complete information when compan( proprietar( or securit( issues ma( .e involved.

/7
CMU/SEI-93-TR-24
-sing the CMM

&n summar(@ the software process assessment and software capa.ilit( evaluation methods .oth; use the maturit( Euestionnaire as a spring.oard for the on4site visit@ use the "## as a map that guides the on4site investigation@ develop findings that identif( software process strengths and weaknesses in terms of the ke( process areas in the "##@ derive a profile .ased on an anal(sis of the satisfaction of the goals within the ke( process area@ and present their results@ to the appropriate audience@ in terms of findings and a ke( process area profile.
/.+
*ifferences %etween !oftware rocess Assessments and !oftware Capability 3valuations

&n spite of these similarities@ the results of a software process assessment or software capa.ilit( evaluation ma( differ@ even on successive applications of the same method. One reason is that the scope of the assessment or evaluation ma( var(. )irst@ the organi ation .eing investigated must .e determined. )or a large compan(@ several different definitions for Korgani ationK are possi.le. The scope ma( .e .ased on common senior management@ common geographical location@ designation as a profit and loss center@ common application domain@ or other considerations. Second@ even in what appears to .e the same organi ation@ the sample of proFects selected ma( affect the scope. A division within a compan( ma( .e assessed@ with the team arriving at findings .ased on a division4wide scope. 0ater@ a product line in that division ma( .e evaluated@ with that team arriving at its findings .ased on a much narrower scope. "omparison .etween the results without understanding the conte!t is pro.lematic.
Software process assessments and software capa.ilit( evaluations differ in motivation@ o.Fective@ outcome@ and ownership of the results. These factors
CMU/SEI-93-TR-24
/1
-sing the CMM

lead to su.stantive differences in the d(namics of interviews@ the scope of inEuir(@ the information gathered@ and the formulation of the outcome. The assessment and evaluation methods are Euite different when the detailed procedures emplo(ed are e!amined. Assessment training does not prepare a team to perform evaluations@ or vice versa.
Software process assessments are performed in an open@ colla.orative environment. Their success depends on a commitment from .oth management and the professional staff to improve the organi ation. The o.Fective is to surface pro.lems and help managers and engineers improve their organi ation. While the Euestionnaire is valua.le in focusing the assessment team
on maturit( level issues@ the emphasis is on structured and unstructured interviews as tools for understanding the organi ationAs software process. Aside from identif(ing the software process issues facing the organi ation@ the .u(4in to improvement@ the organi ation4wide focus on process@ and the motivation and enthusiasm in e!ecuting an action plan are the most valua.le outcomes of an assessment.
Software capa.ilit( evaluations@ on the other hand@ are performed in a more audit4oriented environment. The o.Fective is tied to monetar( considerations@ since the teamAs recommendations will help select contractors or set award fees. The emphasis is on a documented audit trail that reveals the software process actuall( implemented .( the organi ation.
This does not mean@ however@ that the results of software process assessments and software capa.ilit( evaluations should not .e compara.le. Since .oth methods are "##4.ased@ the points of comparison and difference should .e evident and e!plaina.le.

/=
CMU/SEI-93-TR-24
-sing the CMM
/.-
Other -ses of the CMM in (mprovement
rocess
)or software engineering process groups or others tr(ing to improve their software process@ the "## has specific value in the areas of action planning@ implementing action plans@ and defining processes. $uring action planning@ the mem.ers of the software engineering process group@ eEuipped with knowledge of their software process issues and .usiness environment@ can compare their current practices against the goals of the ke( process areas in the "##. The ke( practices should .e e!amined in relation to corporate goals@ management priorities@ the level of performance of the practice@ the value of implementing each practice to the organi ation@ and the a.ilit( of the organi ation to implement a practice in light of its culture.
The software engineering process group must ne!t determine which process improvements are needed@ how to effect the change@ and o.tain the necessar( .u(4in. The "## aids this activit( .( providing a starting point for discussion a.out process improvement and .( helping to surface disparate assumptions a.out commonl( accepted software engineering practices. &n implementing the action plan@ the "## and the ke( practices can .e used .( the process groups to construct parts of the operational action plan and to define the software process.
CMU/SEI-93-TR-24
/3
-sing the CMM
65
Capability
Maturity Model
CMU/SEI-93-TR-24
, Future *irections of the CMM

Achieving higher levels of software process maturit( is incremental and reEuires a long4term commitment to continuous process improvement. Software organi ations ma( take ten (ears or more to .uild the foundation for@ and a culture oriented toward@ continuous process improvement. Although a decade4long process improvement program is foreign to most ,.S. companies@ this level of effort is reEuired to produce mature software organi ations. This time frame is consistent with e!perience from other industries@ such as the ,.S. automotive industr(@ that have achieved significant gains in process maturit( B<a.or35C.
6.'
6hat the CMM *oes 7ot Cover

The "## is not a silver .ullet B2rooks=1C and does not address all of the issues that are important for successful proFects. )or e!ample@ the "## does not currentl( address e!pertise in particular application domains@ advocate specific software technologies@ or suggest how to select@ hire@ motivate@ and retain competent people. Although these issues are crucial to a proFectAs success@ some of these issues have .een anal( ed in other conte!ts B"urtis35C. The( have not@ however@ .een integrated into the "##. The "## was specificall( developed to provide an orderl(@ disciplined framework within which to address software management and engineering process issues.
6.+
7ear'Term Activities
Tutorials and courses on the "## are .eing presented at maFor conferences and seminars throughout the ,nited States to ensure that the software industr( has adeEuate awareness of the "## and its associated products. "##4.ased tools Ge.g.@ the maturit( EuestionnaireH@ software process assessment training@ and software capa.ilit( evaluation training are .eing developed andIor revised to incorporate the "##.
CMU/SEI-93-TR-24
6'
Future *irections of the CMM

The near4term focus on "## development activities will .e oriented towards tailored versions of the "##@ such as a "## for small proFects andIor small organi ations. "## v'.' is e!pressed in terms of the normative practices of large@ government contracting organi ations@ and these practices must .e tailored to the needs of organi ations that differ from this template.
6.-
Long'Term Activities
$uring the ne!t few (ears@ the "## will continue to undergo e!tensive testing through use in software process assessments and software capa.ilit( evaluations. "##4.ased products and training materials will .e developed and revised as appropriate. The "## is a living document that will .e improved@ .ut it is anticipated that "## v'.' will remain the .aseline until at least '337. This provides an appropriate and realistic .alance .etween the needs for sta.ilit( and for continued
improvement.
)or the ne!t version of the "##@ *ersion +@ the S9& will turn its attention to improving the overall model. While all levels of the model ma( .e revised@ the emphasis will .e on 0evels / and 6. "urrentl( the ke( process areas for 0evels + and - have .een the most completel( defined. Since few organi ations have .een assessed to .e at 0evels / or 6 BHumphre(3'a@ 8itson3+C@ less is known a.out the characteristics of such organi ations. The practices for these two levels will .e refined as the S9& works closel( with organi ations that are striving to understand and achieve 0evels / and 6. The "## ma( also .ecome multi4 dimensional to address technolog( and human resource issues.
The S9& is also working with the &nternational Standards Organi ation G&SOH in its efforts to .uild international standards for software process assessment@ improvement@ and capa.ilit( evaluation. The development of the &SO standards will influence "## v+@ even as the S9&As process work will influence the activities of the &SO.
6+
CMU/SEI-93-TR-24
6./
Conclusion
"ontinuous improvement applies to the maturit( model and practices@ Fust as it does to the software process. The potential impact of changes to the "## on the software communit( will .e carefull( considered@ .ut the "##@ the maturit( Euestionnaire@ and the software process assessment and software capa.ilit( evaluation methods will continue to evolve as e!perience is gained with improving the software process. The S9& intends to work closel( with industr(@ government@ and academia in continuing this evolution.
The "## provides a conceptual structure for improving the management and development of software products in a disciplined and consistent wa(. &t does not guarantee that software products will .e successfull( .uilt or that all pro.lems in software engineering will .e adeEuatel( resolved. The "## identifies practices for a mature software process and provides e!amples of the state4of4the4practice Gand in some cases@ the state4of4the4artH@ .ut it is not meant to .e either e!haustive or dictatorial. The "## identifies the characteristics of an effective software process@ .ut the mature organi ation addresses all issues essential to a successful proFect@ including people and technolog(@ as well as process.
CMU/SEI-93-TR-24
6-
6/
CMU/SEI-93-TR-24
8 References
2rooks=1 ).P. 2rooks@ K:o Silver 2ullet; 9ssence and Accidents of Software 9ngineering@K IEEE Co$'uter@ *ol. +5@ :o. /@ April '3=1@ pp. '54'3. "ros.(13 P.2. "ros.(@ Quality is Free@ #c<raw4Hill@ :ew %ork@ :%@ '313.
"urtis35 2. "urtis@ K#anaging the Real 0everage in Software Productivit( and ?ualit(@K /$eri#an "rogra$$er@ *ol. -@ :o. 1@ >ul( '335@ pp. /4'/.
$eming=7 W. 9dwards $eming@ ,ut o the Crisis1 #&T "enter for Advanced 9ngineering Stud(@ "am.ridge@ #A@ '3=7.
$o$=1 Re'ort o the )e ense S#ien#e 2oar* Tas. For#e on Military
So t!are@ Office of the ,nder Secretar( of $efense for AcEuisition@ Washington@ $.".@ Septem.er '3=1.
)agan=7 #.9. )agan@ KAdvances in Software &nspections@K IEEE Transa#tions on So t!are Engineering@ *ol. '+@ :o. 1@ >ul(@ '3=7@ pp. 1//4 16'.
)owler35 P. )owler and S. Rifkin@ So t!are Engineering "ro#ess 3rou' 3ui*e@ Software 9ngineering &nstitute@ "#,IS9&4 354TR4+/@ A$A+-61=/@ Septem.er@ '335.
)reedman35 $.P. )reedman and <.#. Wein.erg@ 4an*(oo. o 5al.throughs1 Ins'e#tions1 an* Te#hni#al Re%ie!s1 Thir* E*ition@ $orset House@ :ew %ork@ :%@ '335.
CMU/SEI-93-TR-24

66
References
<a.or35 A. <a.or@ The Man 5ho )is#o%ere* Quality@ Random House @ :ew %ork@ :%@ '335.
<AO43+4/= E$(e**e* Co$'uter Syste$s6 Signi i#ant So t!are "ro(le$s on C-17 Must 2e /**resse*@ <AOI&#T9" 43+4/=@ #a( '33+.
Humphre(=1a W.S. Humphre(@ Chara#teri-in g the So t!are "ro#ess6 / Matur ity Fra$ e!or. @ Softw are 9ngin
eering &nstitu te@ "#,I S9&4 =14 TR4 ''@ A$A' =+=36 @ >une '3=1.
Humphre(=1 . W.S. Humphre( and W.0. Sweet@ / Metho* or /ssessing the So t! are Engin eering Ca'a (ility o Contr a#tors @ Softw are 9ngin eering &nstitu te@ "#,I S9&4 =14 TR4 +-@ A$A' =1-+5 @ Septe m.er
'3=1.
Humphre(== W.S. Humphre(@ K"haracteri i ng the Software Process@K IEEE So t! are@ *ol. 6@ :o. +@ #arch @ '3==@ pp. 1-413.
Humphre(=3 W.S. Humphre(@ Managing the So t!are "ro#ess@ Addis on4 Wesle (@ Readi ng@ #A@ '3=3.
Humphre(3'a W.S. Humphre(@ $.H. 8itson@ and >. <ale@ KA "omparison of ,.S. and
>apan ese Softw are Proces s #atur it(@K "ro#e e*ing so the 13th Intern ationa l Con e ren#e on So t! are Engin eering @ Austin @ TM@ '-4'1 #a( '33'@ pp. -=4 /3.
67

CMU/SEI-93TR-24
Referenc es
Humphre(3'. W.S. Humphre(@ KProcess )itness and )idelit(@K "ro#ee*ings o the Se%enth International So t!are "ro#ess 5or.sho' @ '74'= Octo.er '33'.
&9994ST$47'5
A:S&I&999 Std 7'5.'+4'335@ K&999 Standard <lossar( of Software 9ngineering Terminolog(@K )e.ruar( '33'.
&mai=7
#. &mai@ 8ai-en6 The 8ey to 9a'an:s Co$'etiti%e Su##ess@ #c<raw4Hill@ :ew %ork@ :%@ '3=7.
>uran==
>.#. >uran@ 9uran on "lanning or Quality@ #acmillan@ :ew %ork@ :%@ '3==.
>uran=3
>.#. >uran@ 9uran on ;ea*ershi' or Quality@ The )ree Press@ :ew %ork@ :%@ '3=3.
8itson3+
$.H. 8itson and S. #asters@ /n /nalysis o SEI So t!are "ro#ess /ssess$ent Results6 19<7-1991@ Software 9ngineering &nstitute@ "#,IS9&43+4TR4+/@ >ul( '33+.
Paulk3'
#.". Paulk@ 2. "urtis@ #.2. "hrissis@ et al@ Ca'a(ility Maturity Mo*el or So t!are@ Software 9ngineering &nstitute@ "#,IS9&43'4TR4+/@ A$A+/575-@ August '33'.
Paulk3-a
#.". Paulk@ 2. "urtis@ #.2. "hrissis@ and ".*. We.er@ Ca'a(ility Maturity Mo*el or So t!are1 0ersion 1=1@ Software 9ngineering &nstitute@ "#,IS9&43-4TR4+/@ )e.ruar( '33-.
CMU/SEI-93-TR-24
61
References
Paulk3-. #.". Paulk@ ".*. We.er@ S. <arcia@ #.2. "hrissis@ and #. 2ush@ 8ey "ra#ti #es o the Ca'a (ility Matur ity Mo*el 1 0ersio n 1=1@ Softw are 9ngin eering &nstitu te@ "#,I S9&4 3-4 TR4 +6@ )e.ru ar( '33-.
Radice=6 R.A. Radice@ >.T. Harding@ P.9. #unnis@ and R.W. Phillips@ KA Progra
mmin g Proces s Stud(@ K I2M Syste $s 9ourn al@ *ol. +/@ :o.+@ '3=6.
Siegel35 >.A.0. Siegel@ et al.@ >ational So t!are Ca'a#ity6 >ear-Ter$ Stu*y@ Software 9ngineering &nstitute@ "#,IS9&4354 TR4'+@ A$A+ +773/ @ #a( '335.
We.er3' ".*. We.er@ #.". Paulk@ ".>. Wise@ and >.*. Withe(@ 8ey "ra#ti #es o the Ca'a (ility Matur ity
Mo*el @ Softw are 9ngin eering &nstitu te@ "#,I S9&4 3'4 TR4 +6@ A$A+ /575/ @ Augus t '33'.
6=

CMU/SEI-93TR-24
Appendi5 A/ 9oals for 3ach 4ey rocess Area

<oals for each ke( process area are listed .( maturit( level .elow.
A#$ The 4ey rocess Areas for Level "/ Repeatable

Re?uire$ents Manage$ent <oal ' S(stem reEuirements allocated to software are controlled to esta.lish a .aseline for software engineering and management use. <oal + Software plans@ products@ and activities are kept consistent with the s(stem reEuirements allocated to software.
So t!are "ro@e#t "lanning <oal ' Software estimates are documented for use in planning and tracking the software proFect. <oal + Software proFect activities and commitments are planned and documented. <oal - Affected groups and individuals agree to their commitments related to the software proFect.
So t!are "ro@e#t Tra#.ing an* ,%ersight <oal ' Actual results and performances are tracked against the software plans. <oal + "orrective actions are taken and managed to closure when actual results and performance deviate significantl( from the software plans.
CMU/SEI-93-TR-24
63
9oals for 3ach 4ey rocess Area

<oal - "hanges to software commitments are agreed to .( the affected groups and individuals.
So t!are Su(#ontra#t Manage$ent <oal ' The prime contractor selects Eualified software su.contractors. <oal + The prime contractor and the software su.contractor agree to their commitments to each other. <oal - The prime contractor and the software su.contractor maintain ongoing communications. <oal / The prime contractor tracks the software su.contractorAs actual results and performance against its commitments.
So t!are Quality /ssuran#e <oal ' Software Eualit( assurance activities are planned. <oal + Adherence of software products and activities to the applica.le standards@ procedures@ and reEuirements is verified o.Fectivel(. <oal - Affected groups and individuals are informed of software Eualit( assurance activities and results. <oal / :oncompliance issues that cannot .e resolved within the software proFect are addressed .( senior
management.
So t!are Con iguration Manage$ent <oal ' Software configuration management activities are planned. <oal + Selected software work products are identified@ controlled@ and availa.le. <oal - "hanges to identified software work products are controlled. <oal / Affected groups and individuals are informed of the status and content of software .aselines.
75
CMU/SEI-93-TR-24
A#" The 4ey rocess Areas for Level )/ *efined

,rgani-ation "ro#ess Fo#us <oal ' Software process development and improvement activities are coordinated across the organi ation. <oal + The strengths and weaknesses of the software processes used are identified relative to a process standard. <oal - Organi ation4level process development and improvement activities are planned.
,rgani-ation "ro#ess )e inition <oal ' A standard software process for the organi ation is developed and maintained. <oal + &nformation related to the use of the organi ationAs standard software process .( the software proFects is collected@ reviewed@ and made availa.le.
Training "rogra$ <oal ' Training activities are planned. <oal + Training for developing the skills and knowledge needed to perform software management and technical roles is provided. <oal - &ndividuals in the software engineering group and software4related groups receive the training necessar( to perform their roles.
Integrate* So t!are Manage$ent <oal ' The proFectAs defined software process is a tailored version of the organi ationAs standard software process.
CMU/SEI-93-TR-24
7'

<oal + The proFect is planned and managed according to the proFectAs defined software process.
So t!are "ro*u#t Engineering <oal ' The software engineering tasks are defined@ integrated@ and consistentl( performed to produce the software. <oal + Software work products are kept consistent with each other.
Intergrou' Coor*ination <oal ' The customerAs reEuirements are agreed to .( all affected groups. <oal + The commitments .etween the engineering groups are agreed to .( the affected groups. <oal - The engineering groups identif(@ track@ and resolve intergroup issues.
"eer Re%ie!s <oal ' Peer review activities are planned. <oal + $efects in the software work products are identified and removed.
A#) The 4ey rocess Areas for Level +/ Managed

Quantitati%e "ro#ess Manage$ent <oal ' The Euantitative process management activities are planned. <oal + The process performance of the proFectAs defined software process is controlled Euantitativel(. <oal - The process capa.ilit( of the organi ationAs standard software process is known in Euantitative terms.
7+
CMU/SEI-93-TR-24

So t!are Quality Manage$ent <oal ' The proFectAs software Eualit( management activities are planned. <oal + #easura.le goals for software product Eualit( and their priorities are defined. <oal - Actual progress toward achieving the Eualit( goals for the software products is Euantified and managed.
A#+ The 4ey rocess Areas for Level ,/ Optimi&ing

)e e#t "re%ention <oal ' $efect prevention activities are planned. <oal + "ommon causes of defects are sought out and identified. <oal - "ommon causes of defects are prioriti ed and s(stematicall( eliminated.
Te#hnology Change Manage$ent <oal ' &ncorporation of technolog( changes are planned. <oal + :ew technologies are evaluated to determine their effect on Eualit( and productivit(. <oal - Appropriate new technologies are transferred into normal practice across the organi ation.
"ro#ess Change Manage$ent <oal ' "ontinuous process improvement is planned. <oal + Participation in the organi ationAs software process improvement activities is organi ation wide.
CMU/SEI-93-TR-24
7-

<oal - The organi ationAs standard software process and the proFectsA defined software processes are improved continuousl(.
7/
CMU/SEI-93-TR-24
REPORT DOCUMENTATION PAGE
Form Approved
OMB No. 0704-0188
Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Head uarters Services, !irectorate for information "perations and #eports, 1$1% &efferson !avis Highway, Suite 1$'(, )rlington, *) $$$'$+(,'$, and to the "ffice of -anagement and .udget, Paperwor/ #eduction Pro0ect 1'2'(+ '1334, Washington, !5 $'%',.
1.
AGENCY USE ONLY 1leave
blan/4
(.
TITLE AND SUBTITLE
Capability Maturity Mode

6.
AUTHOR(S)
#ark ". Paulk@ 2ill "urtis@ #

2.
PERFORMING ORGANIZATION NAME (S) AN
Software 7ngineering 8nstitu 5arnegie -ellon 9niversity Pittsburgh, P) 1%$1,

:.
SPONSORING/MONITORING AGENCY NAME
H; 7S5<)=S % 7glin Street Hanscom )>., -) '12,1+$1

1 1. 1 $. a
SUPPLEMENTARY NOTES
DISTRIBUTION/AVAILABILITY STATEMENT
9nclassified<9nlimited, !?85
'-.
ABSTRACT
1maximum $'' words4
8n @ovemb er 1:36, the Softwar
e 7ngineering 8nstitute 1S784, with assistance from the -itre 5orporation, began developing a process maturity framewor/ that would help organiAations improve their software process. ?his effort was initiated in response to a re uest to provide the federal government with a method for assessing the capability of its software contractors. 8n September 1:32, the S78 released a brief description of the process maturity framewor/ BHumphrey 32aC and a maturity uestionnaire BHumphrey32bC. ?he S78 intended the maturity uestionnaire to provide a simple tool for identifying areas where an organiAationDs software process needed improvement. 9nfortunately, the maturity uestionnaire was too often regarded as Ethe modelE rather than as a vehicle for exploring process maturity issues. )fter four years of experience with the software process maturity framewor/ and the preliminary version of the maturity uestionnaire, the S78 evolved the software process maturity framewor/ into the 5apability -aturity -odel for Software 15--4 BPaul/:1, Weber:1C. ?he 5-is based on /nowledge ac uired from software process assessments and extensive feedbac/ from both industry and government. .y elaborating the maturity framewor/, a model has emerged that provides organiAations with more effective guidance for establishing process improvement programs. ?he initial release of the 5--, *ersion 1.', was reviewed and used by the software community during 1::1 and 1::$. ) wor/shop was held in )pril, 1::$ on 5-- v1.', which was attended by about $'' software professionals. ?his version of the 5--, *ersion 1.1, is the result of the feedbac/ from that wor/shop and ongoing feedbac/ from the software community. ?he 5-- is the foundation for systematically building a set of tools, including a maturity uestionnaire, which are useful in software process improvement. ?he essential point to remember is that the model, not a uestionnaire, is the basis for improving the software process. ?his paper is intended to introduce the reader to 5-- v1.1. .c$.
1 ( .
SUBJECT TERMS
1 2 .
SECURITY CLASSIFICATION OF REPORT
13.
SECURITY CLASSIFICATION OF THIS PAGE
1 : .
SECURITY CLASSIFICATION OF ABSTRACT
9@5F)SS8>87!
@S@ 2%('+'1+$3'+%%''
9@5F)SS8>87!
9@5F)SS8>87!
Prescribed by )@S8 Std. G,:+ 13 $:3+1'$

Capability Maturity Model

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Capability Maturity Model

Uploaded by

Copyright:

Available Formats

Table of Contents