8/13/2019 200702 Phillips

1/44 CROSSTALKThe Journal of Defense Software Engineering February 2007

CMMI

For the CMMI product suite, the devel-opment of V1.2 has improved in threedimensions for each of the products thatcomprise the product suite. In one dimen-

sion, the emphasis was to clarify and sim-plify. In the opposite dimension, the effortwas to position each of the products forpotential expansion of the life cycle orexpansion into new and related areas ofinterest. Overarching these dimensionswas a growing recognition that all of theelements of the product suite could bestrengthened to increase user confidencethat appraisal results accurately reflectgenuine process improvement.

What Are the Major Changes?The CMMI framework is a repository of

elements from which CMMI products arebuilt. For the framework, V1.2 improve-ments resulted in a new architecture thatallows the creation of new groupings ofCMMI products called constellations. Theword constellation refers to a set of modelcomponents, training materials, andappraisal documents in the CMMI frame-work that covers an area of interest such asdevelopment, services, or acquisition.

The result for the V1.2 model is thatwhat once was CMMI V1.1 was improvedand is now part of the development con-

stellation. Therefore, the V1.2 constella-tion, called CMMI for Development, hastwo member models: CMMI for Devel-opment and CMMI for Development +Integrated Product and Process Develop-ment (IPPD). Both models have 22process areas (PAs). I address the PAsmore thoroughly further in the article.

For the appraisal method, SCAMPIV1.2, improvements focused on the clarifi-

cation of terms that had proven problem-atic, such as the use offace-to-faceinterviewsin organizations that are virtual or havemultiple and distant sites. The appraisal

team has addressed requests for more flex-ibility in breaking up appraisal activities(particularly across multiple sites) withoutcompromising the confidence in appraisalresults. Also added are new approaches tobroaden sampling across the organization-al unit being appraised to build confidencein process institutionalization. AlthoughSCAMPI B and C methods (less stringentappraisal methods than the more well-known SCAMPI A method, which do notresult in maturity level or capability levelratings) were developed under the existingV1.1 approach, the thought regarding hav-ing several classes of ratings to make up anappraisal family (SCAMPI As, Bs, and Cs)has been clarified in the V1.2 release.

The training approach for V1.2 alsogot a start under V1.1. The CMMISteering Groups agreement to have a sin-gle introduction to CMMI course ratherthan separate ones for the two representa-tions of the model (staged and continu-ous) was accomplished early in the V1.2development schedule. Today, the singlecourse has been updated to reflect themodel changes described in more detail to

come.At the Software Engineering Institute

(SEI), we are applying similar improve-ments to related courses, such as theIntermediate Concepts of CMMI coursethat we use to groom CMMI subject mat-ter experts, including Introduction toCMMI instructors and SCAMPI leadappraisers. To date, we have offered theIntermediate Concepts of CMMI coursefor those leading improvement efforts intheir organization, even if they do notwish to become instructors or lead

appraisers. We are now pursuing the cre-ation of a CMMI Deployment andInterpretation course that will better servethis audience.

A new approach that was institutedwith V1.2 is an online upgrade courseWhile we provide the essential elements ofchange in the CMMI model, the SCAMPIMethod Definition Document, and theIntroduction to CMMI training in materialprovided free on the Web site, we haveadded both the refresher material andmore advanced training material in CMMIV1.2 Upgrade Training for all those whomust be able to apply CMMI principles onappraisals. A more detailed CMMI V1.2Upgrade Training course is available tothose who are instructors or lead apprais-

ers or are along the path toward being oneThe course for instructors and appraisersis part of the annual partner/fee structureThe upgrade course, available for everyoneelse is available on the SEI Web site whereusers can register and complete theupgrade course online for $175.

Now Tell Me What the

Actual Changes AreSimplification:Three Fewer PAs forthe Model,With IPPD and SupplierSourcing Simplified

More than 80 percent of the appraisalsperformed using CMMI V1.1 used modelsthat did not extend beyond systems engi-neering and software engineering (i.e.they did not use models containing suppli-er sourcing or IPPD), despite the use ofteam-based development (where IPPDpractices would be useful) and of com-plex, multi-company developments(where supplier sourcing practices wouldbe useful). The CMMI development teamfelt that by consolidating the material ineach of the areas, it could improve the use

CMMI V1.2: What Has Changed and Why

Mike Phillips

Software Engineering Institute

This article provides a view of what has been included and not included in Capability Maturity Model Integration

Version 1.2 (CMMI V1.2) for CMMI users who are familiar with the products. CMMI V1.2 products, includingCMMI for Development, V1.2 (the model), Standard CMMI Appraisal Method for Process Improvement (SCAMPISM),

V1.2 (the appraisal method), and Introduction to CMMI, V1.2 (the training), was released on August 25, 2006. I

describe the major elements of change for each of these CMMI products. Draft V1.2 products were approved, piloted, and

revised to ensure that the proposed changes actually improved the quality of the model, method, and training materials and

did no harm to existing improvement efforts and investments already made by those who used CMMI V1.1. I also seek to

add some idea of why many of these changes were made.

Capability Maturity Model, CMM, and CMMI are regis-tered in the U.S. Patent and Trademark Office byCarnegie Mellon University.

SM SCAMPI is a service mark of Carnegie Mellon University.

8/13/2019 200702 Phillips

2/4

CMMI V1.2:What Has Changed and Why

of these practices while simplifyingCMMI models.

An approach suggested by manychange requests received from CMMIusers was to combine Integrated SupplierManagement (ISM), which comprised thesupplier sourcing addition, with SupplierAgreement Management (SAM), whichwas part of the software and systems engi-neering portion of the models. While ISM

was designed for an environment in whichprocess understanding is maintainedacross organizations and SAM wasdesigned for an environment that wouldnot necessarily require such understand-ing, the overlap between these two PAswas troubling.

The resulting change for V1.2 is thatthe informative material was strengthenedin SAM about effective sourcing, and twospecific practices were added to addressthe kind of enhanced visibility of supplierprogress that ISM covered. Since one spe-cific practice, Analyze COTS(commercialoff-the-shelf), was refocused as informa-tive material within SAM and sub-prac-tices in Technical Solution (TS), the netincrease for SAM is one additional specif-ic practice.

The two new SAM-specific practicesare the following: Monitor selected supplier processes. Evaluate selected supplier work prod-

ucts.These two practices are added with the

understanding that the process monitor-ing and work product evaluation opportu-

nities will be as described in the estab-lished agreements with the projects sup-pliers. Not all agreements will allow closescrutiny by the project and not all prod-ucts provided by suppliers will need thatlevel of scrutiny to avoid system develop-ment risk.

When the development team firstsought to address IPPD in CMMI, weplaced many of the concurrent engineer-ing (i.e., a non-linear approach to productdesign and engineering) conceptsthroughout the model. We then used twoapproaches to address team-based behav-iors. In the case of the Integrated ProjectManagement (IPM) PA, we added twogoals that were team-centric and wouldonly be used if the IPPD was selected. Wethen added two additional PAs to captureteam-based thinking: OrganizationalEnvironment for Integration (OEI) andIntegrated Teaming (IT).

For V1.2, we determined that theapproach could be simplified if we addeda goal to Organizational ProcessDevelopment (OPD) to address the orga-nizational commitment to IPPD and then

consolidated the material from IT intoIPM. This simpler approach has greatlyreduced the number of practices and PAsthat are unique to team-based develop-ment. IPPD will now be addressed withonly one approach for expansion theinclusion of one additional IPPD goal inOPD (to address the organizationalbehaviors) and a single goal in IPM (toaddress the project behaviors). These two

goals, which replace the five IPPD goals inV1.1, are the following (revision shown inFigure 1): Enable IPPD management (in OPD). Apply IPPD principles (in IPM).

Simplification: Eliminating CommonFeatures and Advanced PracticesA legacy from the Capability MaturityModel for Software (SW-CMM) was theuse of common features as a method ofdescribing the different roles that genericpractices fulfill in assuring institutionaliza-tion of the models intent across the orga-nization. While this concept may be usefulin training, it complicates model depic-tion. We felt it was time to move to a sim-pler approach of simply numbering thegeneric practices. Therefore, V1.2 modelsno longer contain common features as away to organize the generic practices.

More difficult was resolving the legacyfrom the Systems Engineering CapabilityModel (SECM) Electronics IndustriesAlliance (EIA)-731, the advanced prac-tices that we had placed in the engineeringPAs. We felt that while the idea of

advanced practices made sense, they wereless valuable in the existing model struc-

ture because they added complexity with-out providing strong differentiationbetween base and advanced practicesFurther, advanced practices seemed tocomplicate appraisals. Therefore, V1.2models no longer contain advanced prac-tices. All specific practices are now con-sidered to be at capability level 1.

Expansion: Hardware Engineering

Amplifications and WorkEnvironment CoverageA hardware engineering team was char-tered with finding ways to ensure thatCMMI adequately addressed the hardwareaspects of product development that weresometimes perceived to be missing fromearlier versions of CMMI. Much of thiswork is now reflected in additional hard-ware engineering examples throughout themodel, sometimes within hardware engi-neering amplifications and sometimes inlists of examples representing multipleaspects of product development. Thisaddition of examples resulted in a reduc-tion in the total number of amplificationsin the model.

We typically considered it better tocover product development examplestogether rather than seek to separate theminto software examples, hardware exam-ples, etc. Therefore, the additional hard-ware engineering material, when possiblewas added as material that all would see aspart of the development model, ratherthan an amplification that only some mayread. The final result for V1.2 is that the

hardware amplification (i.e., labeled ForHardware Engineering) were limited to only

February 2007 www.stsc.hill.af.mil 5

IPM

SG1

SG2

SG3

SG4

IPM

SG1

SG2

SG3

IT SG1

SG2

OEI SG1

SG2

OPDSG1

SG2

IPPD Changes IllustratedV1.1 V1.2

Process

Mgt

.

PAs

Support

PAs

ProjectManagementPAs

SG2 = EnableIPPD

Management

SG3 = ApplyIPPD Principles

IPM= I ntegrated Project ManagementIPPD= Integrated Product and ProcessDevelopmentIT= IntegratedTeamingOEI = OrganizationalEnvironmentforIntegrationOPD= OrganizationalProcessDefinitionPA =ProcessAreaSG = SpecificGoal

Legend

Figure 1: How IPPD Material Was Moved for V1.2

8/13/2019 200702 Phillips

3/4

CMMI

six and the software amplification (i.e.,labeled For Software Engineering) werereduced to only eight. An example ofhardware amplification is found inTechnical Solution, specific practice 2.1:

For Hardware Engineering:Detailed design is focused onproduct development of electron-ic, mechanical, electro-optical, and

other hardware products and theircomponents. Electrical schematicsand interconnection diagrams aredeveloped, mechanical and opticalassembly models are generated,and fabrication and assemblyprocesses are developed.

Work that explored future focus areassuch as security and safety resulted in aproposal to include a new PA in V1.2 thatcovered the work environment (i.e., awork environment PA was proposed).However, further investigation revealedthat we could cover the basics of workenvironment material just as we had fordata management by creating two prac-tices to address the concept.

These two practices were added to thesame PAs as the new IPPD-related goals OPD and IPM. A practice in OPDexpects organizational attentiveness toeffective work environment practices, andIPM expects deployment of these prac-tices to the individual projects. These twospecific practices are the following: Establish work environment standards

(in OPD). Establish the projects work environ-

ment (in IPM).

Not Applicable PAsWith the release of V1.2, the potential formaturity level variability has been signifi-cantly reduced. In both V1.0 and V1.1, wedescribed in Chapter 6 that PAs could bedetermined to be not applicable for orga-nizational process improvement. One ofthe heritage models, the SW-CMM, hadalways allowed Software SubcontractManagement (SSM) to be considered notapplicable. The CMMI equivalent, SAM,was highlighted in the Chapter 6 discus-sion as the example of a PA potentiallyconsidered not applicablein CMMI.

The number of organizations seekingto exclude this type of PA from theirappraisals dropped from 58 percent withthe SW-CMM to 20 percent with CMMI,but we knew that some organizations, par-ticularly small software developers, had nocritical suppliers so that an allowance forexclusion remained important. However,the model text did not identify this as the

only acceptable PA for consideration. Wehad a few other PAs declared not applicablefor various reasons, but our view was thatcontinuing to accommodate these exclu-sions diminished the confidence in thebenchmark associated with maturity levelappraisal results. (Appraisals using thecontinuous approach and not seekingstaged equivalence, of course, allow any ofthe options desired for process improve-

ment without providing potentially mis-leading results.)

Version 1.2 addressed this issue inboth the model and the method. The V1.2model no longer discusses not applicablestatus. The needed procedures for theappraisal teams determination are nowpart of the SCAMPI Method DefinitionDocument. We will rely on the appraisal

team to determine, prior to the appraisalonsite, if the SAM practices are needed in

the organizational unit being appraised ornot. The appraisal disclosure statementwill include a statement about the lack ofsuppliers needing management, if theteam makes that determination.

Appraisal Validity PeriodThe CMMI Steering Group has deter-mined that some sense of lifetimeneededto be defined for CMMI appraisals. Afterextended discussions, the Steering Groupdetermined that a three-year validity peri-od, similar to that established for ISO9000:2000, would be the most reasonable

length of time. (We have frequently men-tioned that there are often other signifi-cant reasons to question the maintenanceof process capability, such as reorganiza-tions or mergers and acquisitions.)

So how will this approach be phasedin? The first part is easy. All futureappraisals, both V1.1 and V1.2, will beconsidered valid for three years from thedate of completion, as noted on theappraisal disclosure statement. When twoyears have passed without a new appraisalcovering the organization, the SEI will

contact the sponsor of the two-year-oldappraisal to remind them of the three-yearvalidity rule. At the three-year-point, pub-licly available appraisals on the SEI Website will beremoved.

But what about already performedappraisals? Here, the planned availabilityof V1.2 causes a need for flexibility, as

we want to encourage a smooth transi-

tion to the improved version. We there-fore will consider existing appraisalsolder than three years valid for a full yearafter the release of V1.2, done in August2006. This plan allows time to plan andexecute appraisals using the V1.2 prod-uct suite. Further, we will continue torecognize V1.1 appraisals through mostof 2007 in case the concerns aboutchange are greater than what we current-ly expect.

Although we no longer publish SW-CMM appraisal results, we felt it appropri-ate to establish a validity periodfor these aswell. The choice in this case, since all rec-ognized appraisals had to be completed bythe sunset of December 2005, was tochoose a single date: December 2007. Thisplan leaves CMM users with some flexibil-ity more than a year and a half to makethe transition to CMMI, and to use eitherV1.1 or V1.2.

Discipline DistinctionsWith the first two releases of CMMI, itwas important to recognize which disci-plines the models covered (e.g., software

engineering, systems engineering), alongwith recognizing the heritage of theimprovement models for each of the disci-plines (i.e., material from the three sourcemodels: the SW-CMM, EIA 731, and theIntegrated Product Development-CMM)However, over the years, these distinctionshave become less important, and the uni-fying engineering development processeshave demonstrated synergies that gobeyond the original source models. Wewere also asked by users and the CMMISteering Group to simplify the material.

The increasing number of possiblemodel variations (e.g., CMMI-SE, CMMI-SE/SW/IPPD, CMMI-SW/IPPD), andtherefore printed models, to address thevarious combinations of engineering dis-ciplines made movement in that directionundesirable. Instead, we added amplifica-tions for hardware engineering examples,but chose not to call out another modelvariation in the model name. Nor are mul-tiple model documents available for usersto choose from. Instead, there is one inte-grated model document containing thebest development practices.

6 CROSSTALKThe Journal of Defense Software Engineering February 2007

Appraisals using the

continuous approach ...

allow any of the options

desired for process

improvement without

providing potentially

misleading results.

8/13/2019 200702 Phillips

4/4

CMMI V1.2:What Has Changed and Why

Changes to CMMI Beyond

CMMI for DevelopmentAs we began to consider future coverageof organizational process improvement,we sought to maintain the greatest possi-ble commonality among all the modelscreated from the CMMI common frame-work of best practices. Figure 2 depictsthe desire for commonality and needed

specificity. This approach provides a wayto avoid any CMMI model to grow toolarge for effective use.

Based on the initial efforts to maxi-mize commonality among CMMI mod-els, 16 of the 22 PAs of CMMI V1.2comprise the process improvementCMMI Model Foundation for the threeareas of interest currently being pursued:development, acquisition, and services.

The 16 PAs (in alphabetical order) are thefollowing:1. Causal Analysis and Resolution (CAR).2. Configuration Management (CM).

3. Decision Analysis and Resolution(DAR).

4. Integrated Project Management(IPM).

5. Measurement and Analysis (MA).6. Organizational Innovation and

Deployment (OID).7. OPD.8. Organizational Process Focus (OPF).9. Organizational Process Performance

(OPP).10. Organizational Training (OT).11. Process and Product Quality

Assurance (PPQA).12. Project Monitoring and Control(PMC).

13. Project Planning (PP).14. Quantitative Project Management

(QPM).15. Requirements Management (REQM).16. Risk Management (RSKM).

Each constellation includes the com-mon parts of the 16 PAs above, with addi-tions unique to the area of interest cov-ered, or shared across some, but not all, ofthe constellations.

We recognized that even with the

CMMI Model Foundation, we needed toallow some flexibility. No flexibility isallowed, however, for the required(i.e., spe-cific goals and generic goals) or expected(i.e., specific practices and generic prac-tices) components of the 16 PAs thatmake up the model foundation. Additionsto these PAs will be allowed, just as theIPPD addition is allowed (and encour-aged) in the development constellation.

In the informative material, we allow alittle more flexibility so that typical workproducts can be added or substituted to fit

a process area in each constellation. Theonly other substitutions or deletionsallowed within these 16 PAs will be theinformative material judged specific todevelopment. This occurs in the currentmodel in subpractices, where develop-ment-specific explanations are oftenfound. These statements may be tailoredto the needs of the new constellation.These include informative paragraphsbelow sub-practices and generic practiceelaborations.

More tailoring is permitted todescribe activities captured primarily inthe engineering PAs of CMMI-DEV.

While some of the constellations mayshare components with the engineeringPAs in CMMI-DEV, the shared materialmay be arranged and grouped differentlyto meet the needs of the constellations

user base. If these adjustments changethe PA in any significant way, the PA willbe given a different name to avoid confu-sion in use, training, or appraisal. If twoconstellations find that a particular PAcan be shared, then these PAs will bedesigned to capture that commonality as

well. For example, the existingVerification or Validation PAs might beusable in one of the future models butnot in others, so it would be sharedacross two constellations.

SummaryWith V1.2, we sought to address a numberof needed changes. Many of you, as CMMIusers, gave us your thoughts on changes toimprove CMMI. You may see, in thechanges, something that you suggested.You may see areas changed in ways a bitdifferently than you suggested but similarin intent. And there may well be changesthat you recommended, particularly expan-sions that we did not include this time.

Improvements will continue to beneeded, and future updates to our constel-lations will continue to be made. We hope

that this set of changes will simplify, addsome needed coverage, and, most impor-tantly, increase the confidence that thecommunity appraisal results do representfaithfully the sincere efforts in processimprovement that you and your peers

have made in your organizations.

February 2007 www.stsc.hill.af.mil 7

CMMIFramework

Development-SpecificMaterials DevelopmentAmplifications DevelopmentAdditions PA XX

PA ZZ

PADEV

Acquisition-SpecificMaterials AcquisitionAmplifications AcquisitionAdditions

PA AY

PA XX PA ACQ

Services-SpecificMaterials ServicesAmplifications ServicesAdditions PA ZZ

PAAY

PA SVC

SharedCMMI Material

Core Foundation Model

CommonPAs,SpecificPractices,GenericPractices

Shared PAs,SpecificPractices,Additions, Amplifications

Figure 2: How the CMMI Constellations Interact

About the Author

Mike Phillips is the pro-gram manager for CMMIV1.2 at the SEI. Pre-viously, he was responsi-ble for transition enablingactivities at the SEI.

Phillips has authored technical reports,technical notes, CMMI columns, and

various articles in addition to presentingCMMI material at conferences aroundthe world. Prior to his retirement as acolonel from the Air Force, he managedthe $36 billion development program forthe B-2 in the B-2 System ProgramOffice and commanded the 4950th TestWing at Wright-Patterson AFB, OH.Phillips has a bachelors degree inAstronautical Engineering from the AirForce Academy, a masters degree inNuclear Engineering from Georgia TechUniversity, a masters degree in Systems

Management from the University ofSouthern California, and a mastersdegree in International Affairs fromSalve Regina College and the Naval WarCollege.

SEI

4500 Fifth AVE

Pittsburgh, PA 15213

Phone: (412) 268-5884

Fax: (412) 268-5758

E-mail: dmp@sei.cmu.edu