7. Capability Maturity Model Integration (CMMI) - tud.ttu.ee

The Frameworks Quagmire (present)PSPPeopleCMMSA-CMMSSE-CMMMIL-STD-499B*CMMIIEEE1220ISO15504*(SPICE)EIA/IS632IEEE Stds. 730,828829, 830,1012,10161028,1058,1063DODIPPDAF IPDGuideEIA 632*TrilliumTickITQ9000ISO 10011EQABaldrigeFAAiCMMDO-178BMIL-Q-9858NATOAQAP1,4,9BS5750ISO 9000SeriesMIL-STD-498ISO 15288*DOD-STD-2168ISO/IEC12207IEEE1074MIL-STD-1679DOD-STD-2167ADOD-STD-7935AEIA/IEEEJ-STD-016IEEE/EIA122075CMMI High LevelOrganizationsFeb 20043

CMMI Published Level 5Organizations• Blue Star Infotech Limited,Mumbai, India• GE Capital International Services - Software, Hyderabad &Gurgaon Development Centers, India• Infosys Technologies Limited Development Centre in Chennai• Larsen & Toubro Limited, EmSyS,Mysore, India• Lockheed Martin Management & Data Systems (M&DS) King ofPrussia, Pennsylvania• SSI TECHONOLOGIES (SSIT) A DIVISION OF SSI LIMITEDCHENNAI, INDIA• Wipro Technologies Doddkannelli, Sarjapur Road Bangalore– Wipro technologies is world's first CMMI Level 5 Ver1.1 organization– http://www.prdomain.com/companies/w/wipro/news_releases/200205may/pr_wipro_20020530.htm7CMMI Published Level 4 Organizations• IBM Japan, Ltd., IBM Global Services Japan, Public Sector Services 19-21,Nihonbashi Hakozaki-cho Chuo-ku, Tokyo 103-8510 Japan• Digital Design, Software Development Department, St. Petersburg, Russia– Digital Design sets the standard by becoming the first Russian software companyto successfully undergo a formal CMMI assessment.• Hitachi Software Engineering Co.,Ltd., Financial Systems Group, 4-12-6Higashishinagawa Shinagawa-ku, Tokyo 140-0002 Japan– (1)Hitachi Software achieved CMMI Level 3 in all the business groups.(2)Achieved CMMI Level 3 at the whole company level.• Hitachi Software Engineering Co.,Ltd., Government & Public CorporationSystems Division, 4-12-6 Higashishinagawa Shinagawa-ku, Tokyo 140-0002 Japan• Hitachi Software Engineering Co.,Ltd., Software Development Division,Tokyo Japan• Nihon Unisys, Ltd., Financial, Koto-ku, Tokyo, Japan• Northrop Grumman Mission Systems, Command, Control and IntelligenceDivision, Omaha Site• Northrop Grumman Mission Systems, Tactical Systems Division• Rockwell Collins Government Systems• Soza & Company, Ltd84

CMM-i probleemid• Kosemudelil tuginev nõuetepõhine tarkvara kvaliteedihindamine teeb spetsifikatsiooni järgimise olulisemakskliendi tegelike vajaduste rahuldamisest (pole haruldane,et klient ei suuda esialgu nõudeid korrektseltspetsifitseerida, ka võivad kliendi vajadused aja jooksulmuutuda).• CMM-i erinevad standardid (CMM for Software (SW-CMM), People CMM (P-CMM), SA-CMM (CMM forSoftware Acquisition), Systems Engineering CapabilityModel (SECM) jt) on osaliselt kattuvad (ntprojektijuhtimise metoodika, nõuete spetsifitseerimine,protsessi määratlus), isegi vasturääkivad.13Roots of CMMI7

Intro• U.S. Department of Defense—specifically, theDeputy Under Secretary of Defense (Scienceand Technology)—teamed up with the NationalDefense Industrial Association (NDIA) to jointlysponsor the development of Capability MaturityModel Integration (CMMI).• Working with the Software Engineering Institute(SEI) at Carnegie Mellon University, this effortproduced the first integrated CMMI models in2000, together with associated appraisal andtraining materials; 2002 saw the release ofCMMI version 1.1.15Intro• CMMI provides guidance for yourmanagerial processes.• CMMI guidance on technical mattersincludes ways to develop, elaborate, andmanage requirements, and to developtechnical solutions that meet thoserequirements.168

Process Improvement• The improvement information in CMMI models includes the creation of aviable, improvable process infrastructure. To build this infrastructure, CMMIincludes ways to get your organization to focus more on defining andfollowing its processes. Through training and standardization you can makesure everyone knows their roles and how to execute them in the process.You learn to use the measurement data you collect to improve your processperformance, innovate when processes need to evolve, and ensure yourability to meet changing needs.• Processes need to be planned just like projects, and it helps if theorganization has given some weight and validity to it through policy. Youneed to make sure that resources are available for trained, empoweredpeople to perform the process.• Processes become more capable when they are standardized across theorganization and their performance is monitored against historical data. Thisway you can detect variation in performance early enough to address it lessexpensively. And ultimately, the process should be continuously improvingthrough identifying the root causes of variability and innovative ways to fulfillits objectives.17CMMI and Business Objectives• Produce quality products or services.• Create value for the stockholders• Be an employer of choice• Enhance customer satisfaction• Increase market share• Implement cost savings and best practices• Gain an industry-wide recognition forexcellence189

Produce quality products or services• The process-improvement concept inCMMI models evolved out of the Deming,Juran, and Crosby quality paradigm:– Quality products are a result of qualityprocesses• CMMI has a strong focus on qualityrelatedactivities including requirementsmanagement, quality assurance,verification, and validation.19Current ROI Value to ProgramsA report by Dod Data & Analysis Center for Software(DACS) found:Application of SPI to “Example organization withexample projects”:Development costs Reduced 73%Rework costs Reduced 96%Average schedule length Reduced 37%Post-release defects Reduced 80%Weighted risk likelihood Reduced 92%Return on investment 21:12010

Improvements from AdoptingSW-CMMPercentage Improvement403530252015105035%19%39%Savings vs. cost ofsoftware processimprovement(median) 5:1Productivity(increase)Time to market(reduction)Post-releasedefect reports(reduction)Annual Medians21Create value for the stockholders• Mature organizations are more likely to makebetter cost and revenue estimates than thosewith less maturity, and then perform in line withthose estimates.• CMMI supports quality products, predictableschedules, and effective measurement tosupport management in making accurate anddefensible forecasts.• This process maturity can guard against projectperformance problems that could weaken thevalue of the organization in the eyes ofinvestors.2211

Be an employer of choice• Watts Humphrey has said,"Quality work is not done by accident; it is done only byskilled and motivated people." [1]• CMMI emphasizes training, both in disciplines and inprocess.• Experience has shown that organizations with matureprocesses have far less turnover than immatureorganizations.• Engineers in particular are more comfortable in anorganization where there is a sense of cohesion andcompetence.• [1] Humphrey, W. Winning with Software, Boston: Addison-Wesley, 200223Employee Satisfaction2412

Enhance customer satisfaction• Meeting cost and schedule targets withhigh-quality products that are validatedagainst customer needs is a good formulafor customer satisfaction.• CMMI addresses all of these ingredientsthrough its emphasis on planning,monitoring, and measuring, and theimproved predictability that comes withmore capable processes.25Increase market share• Market share is a result of many factors, including qualityproducts and services, name identification, pricing, andimage.• Clearly, customer satisfaction is a central factor, and in amarketplace, having satisfied customers can becontagious.• Customers like to deal with suppliers who have areputation for meeting their commitments.• CMMI improves estimation and lowers process variabilityto enable better, more accurate bids that aredemonstrably achievable.• It also contributes to meeting essential quality goals.2613

Implement cost savings and best practices• Processes that are documented, measured, andcontinuously improved are perfect candidates forbecoming best practices, resulting in costsavings for the organization.• CMMI encourages measurement as amanagerial tool.• By using the historical data collected to supportschedule estimation, an organization can identifyand widely deploy practices that work, andeliminate those that don't.27Benefits of Continuing ProcessImprovement•SEI SW-CMM Level 5: For the Right Reasons*•Defects are now nearly all found and fixed before testing begins.•Defects escaping into the field have been reduced from 11% topractically 0%.•Programs consistently reach customer satisfaction andperformance targets.•Peer reviews increase total project costs by 4%, but reducedrework during testing by 31%. R.O.I. is 7.75:1.•* Reference: Yamamura and Wigle, Boeing Space andTransportation Systems, Crosstalk, Aug, 1997.2814

Gain an industry-wide recognitionfor excellence• The best way to develop a reputation forexcellence is to consistently perform well onprojects, delivering quality products and serviceswithin cost and schedule parameters.• Having processes that conform to CMMIrequirements can enhance that reputation.• The results of CMMI appraisals can becompared across a company, a corporation, oran industry.• Many organizations proudly advertise theirCMMI-defined maturity rating alongside theirISO 9000 registration.29CMMI Objectives• Eliminating inconsistencies.• Reducing duplication.• Increasing clarity and understanding.• Providing common terminology.• Providing consistent style.• Establishing uniform construction rules.• Maintaining common components.• Assuring consistency with ISO/IEC 15504.• Being sensitive to the implications for legacyefforts.3015

CMMI Milestones• 1997 - CMMI initiated by U.S. Department of Defenseand NDIA• 1998 - First team meeting held• 1999 - First pilot completed• 2000:– CMMI-SE/SW version 1.0 released for initial use– CMMI-SE/SW/IPPD version 1.0 released for initial use– CMMI-SE/SW/IPPD/SS version 1.0 released for piloting• 2002:– CMMI-SE/SW version 1.1 released– CMMI-SE/SW/IPPD version 1.1 released– CMMI-SE/SW/IPPD/SS version 1.1 released– CMMI-SW version 1.1 released31Systems Engineering Guidelines and CMMIDOD5000EIA 632Processes forEngineeringa SystemIEEE/EIA12207SoftwareLife CycleProcessesSupportsSoftware - SW-CMMEIA/IS 731Systems EngineeringCapabilityIPPD CMMSystems Engineering - EIA/IS 731CapabilityMaturityModelIntegration(CMMI)Integrated Product and Process Development - IPD-CMMSupplier Sourcing - SSCMM for Software Aquisition - SA CMMSW-CMMSoftware CapabilityMaturity ModelSA CMM3216

The CMMI Product Line ApproachSWIPPDAssess...SEIndustrySEIGovernmentCMMIProduct SuiteTrainingAcquisition• Team of Teams• Modeling andDiscipline Experts• Collaborative ProcessCMMI-SE/SW/IPPDCMMI-SE/SWCMMI-...SE/SW/IPPD/A33Source Models for CMMI-SE/SW/IPPD• Software - SW-CMM, draft version 2(c)• Systems Engineering - EIA/IS 731• Integrated Product and ProcessDevelopment - IPD-CMM, version 0.983417

CMM for Software• Software Engineering– As defined in IEEE Standard 610.12, softwareengineering is the application of a systematic,disciplined, quantifiable approach to thedevelopment, operation, and maintenance ofsoftware—that is, the application ofengineering to software• IEEE Standard Glossary of Software EngineeringTerminology. IEEE Standard 610.12–1990. NewYork: Institute of Electrical and ElectronicsEngineers, 1990.35CMM for Software• In 1986, Watts Humphrey, the SEI, and the Mitre Corporation responded to a requestby the U.S. federal government to create a way of evaluating the software capabilityof its contractors.– The group used IBM's concepts to create a software maturity framework, a questionnaire,and two appraisal methods. Over the next few years, this work was continued and refined.• In 1991, the SEI published the CMM for Software version 1.0, a model that describesthe principles and practices underlying software process maturity.• The CMM is organized to help software organizations improve along an evolutionarypath, growing from an ad hoc, chaotic environment toward mature, disciplinedsoftware processes.• The CMM was used and evaluated for two years, then revised and released asversion 1.1 in 1993.• A similar revision was planned for 1997 as version 2.0;– this version was developed but never released as an independent model. However, thegood work did not go to waste:– The proposed revision was used as the source for the CMMI integration effort. In addition,two documents regarding software appraisals were used:– the CMM Appraisal Framework, version 1.0,– and the CMM-Based Appraisal for Internal Process Improvement (CBA IPI): MethodDescription.3618

Systems Engineering CapabilityModel• Systems Engineering– INCOSE defines systems engineering as "an interdisciplinary approachand means to enable the realization of successful systems.“• In August 1995, the Enterprise Process ImprovementCollaboration (EPIC), a group of industry, academic, andgovernment organizations, released the Systems EngineeringCapability Maturity Model (SE-CMM).– EPIC enlisted the SEI and architect Roger Bate to lead thedevelopment.– The team pulled its systems engineering expertise primarily fromaerospace and defense industry corporations and from the SoftwareProductivity Consortium.– The result was a model based on the appraisal model architecturecontained in draft versions of ISO/IEC 15504 that addressedengineering, project, process, and organization practices.37Systems Engineering CapabilityModel• Around the same time that the SE-CMM wasunder development, INCOSE created a checklistfor evaluating the capabilities of systemsengineering organizations based on variousengineering standards.– Over time, this checklist evolved into a full-blowncapability model known as the Systems EngineeringCapability Assessment Model (SECAM).– SECAM extended the SPICE concepts of acontinuous model but focused more specifically onsystems engineering practices than the SE-CMM,using ANSI/EIA 632, "Processes for Engineering aSystem," as the fundamental reference.3819

Systems Engineering CapabilityModel• Needless to say, an environment with two models developed by tworeputable organizations that purported to address the same issues was ripefor a model war.• Which model would emerge as the "standard" by which organizations couldbe evaluated?• After a year of heated discussions, in 1996 EPIC and INCOSE agreed towork together under the auspices of the Government Electronic andInformation Technology Association (GEIA) of the Electronic IndustriesAlliance (EIA), with the goal of merging the two models into a single EIAstandard.• The result was the interim standard EIA/IS 731, Systems EngineeringCapability Model (SECM).• By issuing the interim standard, the systems engineering community couldapply a single, common description of systems engineering processes tothe CMMI project.• EIA 731 includes both the SECM model (Part 1) and an appraisal method(Part 2).39The Integrated ProductDevelopment CMM• CMMI defines Integrated Product and ProcessDevelopment as a systematic approach to productdevelopment that achieves a timely collaboration ofrelevant stakeholders throughout the product life cycle tobetter satisfy customer needs.• The source model for Integrated Product and ProcessDevelopment (IPPD) was a draft of the IntegratedProduct Development CMM, known as IPD-CMM version0.98.– This model had been developed almost to the point of its initialformal release when the CMMI project began in 1998.4020

Supplier Sourcing (SS)• Project may use suppliers to performcertain functions and modifications toproducts that are specifically needed forthe project.• Enhanced source analysis and monitoringsupplier activities• SS discipline coversacquiering productsfrom suppliers under such circumstances41CMMI Representations21

CMMI Model RepresentationsStagedContinuousML5ML4ML3ML2ML 1OrganizationCapability0 1 2 3 4 5PA PA PAProcess43CMMI Model Representations• The Continuous Representation– The continuous representation isbased on process capability—therange of expected results that canbe achieved by following aprocess.– Process improvement ismeasured in capability levels thatrelate to the achievement ofspecific and generic goals in eachprocess area.– The continuous representationprovides flexibility fororganizations to choose whichprocesses to emphasize forimprovement, as well as howmuch to improve each process.– It enables selection of the orderof process improvement that bestmeets the organization’s businessobjectives and that most mitigatesrisk.• The Staged Representation– The staged representation is based onorganizational maturity—the combinedcapabilities of a set of relatedprocesses.– Organizational improvement ismeasured in maturity levels.– This representation has arecommended order for approachingprocess improvement, beginning withbasic management practices andprogressing along a proven path.• Equivalent Staging– Sometimes it may be desirable toconvert an organization’s capabilitylevel achievements into a maturitylevel.– This conversion is made possible by“equivalent staging.”– The CMMI model includes rules fordetermining which capability levelsmust be satisfied in each process areato achieve each maturity level.4422

One Model, Two RepresentationsAppendixesMaturity Level 5OID, CARMaturity Level 4OPP, QPMMaturity Level 3REQD, TS, PI, VER,VAL, OPF, OPD, OT,IPM, RSKM, DARMaturity Level 2REQM, PP, PMC,SAM, MA, PPQA, CMOverviewIntroductionStructure of the ModelModel TerminologyMaturity Levels, Common Features, and Generic PracticesUnderstanding the ModelUsing the ModelCMMI-SE/SWStagedEngineeringREQM, REQD, TS,PI, VER, VALProject ManagementPP, PMC, SAMIPM, RSKM, QPMProcess ManagementOPF, OPD, OT,OPP, OIDAppendixesSupportCM, PPQA, MA,CAR, DAROverviewIntroduction Process ManagementStructure PAs of the ModelModel Terminology- Goals- PracticesCapability Levels and Generic Model ComponentsUnderstanding the ModelUsing the ModelCMMI-SE/SWContinuous45CMMI-SE/SW/IPPD/A - ContinuousCMMIProcessManagementProjectManagementEngineeringSupport• Organizational Process Focus• Organizational Process• Definition• Organizational Training• Organizational Process• Performance• Organizational Innovationand Deployment• Project Planning• Project Monitoring andControl• Supplier Agreement Mgmt.• Integrated Project Mgmt.• Risk Management• Quantitative Project Mgmt.• Requirements Management• Requirements Development• Technical Solution• Product Integration• Verification• Validation• Configuration Mgmt.• Process and ProductQuality Assurance• Measurement & Analysis• Decision Analysis andResolution• Causal Analysis andResolutionIPPDAcquisition• Organizational Environmentfor Integration• Integrated Team• Supplier Selection and Monitoring• Integrated Supplier Management• Quantitative Supplier Management4623

CMMI-SE/SW/IPPD/A - StagedFocusContinuousProcess Improvement(2 PAs)Optimizing(5)•Organizational Innovation and Deployment (OID)•Causal Analysis and Resolution (CAR)QuantitativeManagement(2 PAs)ProcessStandardization(11 PAs)Basic ProjectManagement(7 PAs)Initial(1)Managed(2)Defined(3)QuantitativelyManaged(4)Ad hoc, chaotic processes•Organizational Process Performance (OPP)•Quantitative Project Management (QPM)•Quantitative SupplierManagement (QSM)•Requirements Development (RD)•Technical Solution (TS)•Product Integration (PI)•Verification (VER)•Validation (VAL)•Organizational Process Focus (OPF)•Organizational Process Definition (OPD)•Organization Training (OT)•Integrated Project Management (IPM) *•Risk Management(RSKM)•Decision Analysis and Resolution (DAR)•Requirements Management (REQM)•Project Planning (PP)•Project Monitoring and Control (PMC)•Supplier Agreement Management (SAM)•Measurement and Analysis (M&A)•Process and Product Quality Assurance (PPQA)•Configuration Management (CM)•Organization Environmentfor Integration (OEI)•Integrated Team (IT)•Integrated SupplierManagement (ISM)• Supplier Selection andMonitoring (SSM)* Additional PA goals andactivities added for IPPD47Model MetricsRelease PAs/ Goals/ Activities/FAs Themes* Practices**SW-CMM V1.1 18 52 316SW-CMM V2C 19 62 318EIA/IS 731 19 61 77 199 383 1566IPD-CMM V0.98 23 60 865CMMI V1.0 SE/SW 22 70 417CMMI V1.02 SE/SW/IPPD 24 76 460* Ratable components** Key to implementation effort4824

ExpectedRequiredCMMI Model StructureStagedContinuousMaturity LevelsProcess Area 1Process Area 2 Process Area n Process Area 1 Process Area 2 Process Area nSpecificGoalsGenericGoalsSpecificGoalsGenericGoalsCommon FeaturesCommitmentto PerformAbilityto PerformDirectingImplementationVerifyingImplementationCapability LevelsSpecificPracticesGenericPracticesSpecificPracticesGenericPractices49Staged Models• The term "staged" comes from the way that the modeldescribes this road map as a series of "stages" that arecalled "maturity levels."• Each maturity level has a set of process areas thatindicate where an organization should focus to improveits organizational process.• Each process area is described in terms of the practicesthat contribute to satisfying its goals.• The practices describe the infrastructure and activitiesthat contribute most to the effective implementation andinstitutionalization of the process areas.• Progress occurs by satisfying the goals of all processareas in a particular maturity level5025

Staged Models• The CMM for Software is the primary example ofa staged model51Continuous Models• Continuous models provide less specific guidance on theorder in which improvement should be accomplished.• They are called continuous because no discrete stagesare associated with organizational maturity.• Like the staged models, continuous models haveprocess areas that contain practices.• Unlike in staged models, however, the practices of aprocess area in a continuous model are organized in amanner that supports individual process area growth andimprovement.• Most of the practices associated with processimprovement are generic; they are external to theindividual process areas and apply to all process areas5226

Continuous Models• The generic practices are grouped into capability levels (CLs), eachof which has a definition that is roughly equivalent to the definition ofthe maturity levels in a staged model.• Process areas are improved and institutionalized by implementingthe generic practices in those process areas.• In a continuous model goals are not specifically stated, which putseven more emphasis on practices.• The collective capability levels of all process areas determineorganizational improvement, and an organization can tailor acontinuous model and target only certain process areas forimprovement.• In other words, they create their own "staging" of process areas.53CMMI Capability LevelsImproved Performance Through Managed Processes5427

Capability Profile• In a continuous appraisal, each processarea is rated at its own capability level.• An organization will most likely havedifferent process areas rated at differentcapability levels.• The results can be reported as a capabilityprofile.55Capability Profile5628

CMMI Model Representations• The CMMI Team was given an unprecedentedchallenge:Create a single model that could be viewed fromtwo distinct perspectives, continuous andstaged.• The 25 process areas of CMMI-SE/SW/IPPD/SSare divided into four maturity levels in the stagedrepresentation and four process categories inthe continuous representation.57CapabilityLevel:Generic Goals (GG):Generic Practices (GP):5(Optimizing)Institutionalize anOptimizing Process.Ensure continuous process improvement.Correct common cause of problems.4(QuantitativelyManaged)Institutionalize aQuantitativelyManaged Process.Establish quality objectives.Stabilize subprocess performance.3(Defined)Institutionalize aDefined Process.Establish a defined process.Collect improvement information.2(Managed)Institutionalize aManaged Process.Establish org. policy.Plan the process.Provide resources.Assign responsibility.Train people.Perform managedprocess.Manage configurations.Identify & involve relevantstakeholders.Monitor and control theprocess.Objectively verify adherence.Review status with mgmt.1(Performed)Achieve SpecificGoals.Identify work scope.Perform base practices.0 (Incomplete)(None)(None)5829

Staged Groupings - Maturity level 2AcronymsREQMProcess AreasRequirements ManagementPPProject PlanningPMCProject Monitoring and ControlSAMMASupplier Agreement ManagementMeasurement and AnalysisPPQAProcess and Product Quality AssuranceCMConfiguration Management59Staged Groupings - Maturity level 4AcronymsOPPQPMProcess AreasOrganizational ProcessPerformanceQuantitative Project Management6030

Continuous Grouping –Process ManagementAcronymsOPFOPDOTOPPOIDProcess AreasOrganizational Process FocusOrganizational Process DefinitionOrganizational TrainingOrganizational ProcessPerformanceOrganizational Innovation andDeployment61Equivalent Staging• To reinforce the concept of one model with twoviews or representations, CMMI provides amapping to move from the continuous to thestaged perspective.• For maturity levels 2 and 3, the concept isstraightforward and easy to understand.• If an organization using the continuousrepresentation has achieved capability level 2 inthe seven process areas that make up maturitylevel 2 (in the staged representation), then it canbe said to have achieved maturity level 26231

Target profile 263Target profile 56432

CMMI Dimensions forMeasuring ImprovementCapability Dimension• CMMI includes six levels of process areacapability, imaginatively called capabilitylevels (CLs), and numbered 0 through 5.• These CLs indicate how well theorganization performs in an individualprocess area.6633

Capability Dimension67Generic Goals• CL 0 - No goal.• CL 1 - GG 1: The process supports and enablesachievement of the specific goals of the process area bytransforming identifiable input work products to produceidentifiable output work products.• CL 2 - GG 2: The process is institutionalized as amanaged process.• CL 3 - GG 3: The process is institutionalized as adefined process.• CL 4 - GG 4: The process is institutionalized as aquantitatively managed process.• CL 5 - GG 5: The process is institutionalized as anoptimizing process.6834

Buildingcapability69Maturity Dimension• The maturity dimension of a CMMI model isdescribed in the staged representation.• Five levels of maturity exist, each of whichindicates the process maturity of theorganization.• Capability levels are independently applied toany individual process area, whereas a maturitylevel specifies a set of process areas whosecombined set of goals must be achieved.7035

Staged maturity levels71Maturity levelstructure7236

Content of CMMIBuyer/Supplier MismatchAcquirerMismatch• mature buyermust mentor lowmaturitydeveloper• outcome notpredictableMatched Team•match of skills, maturity•team risk approach•execution to plan•measurable performance•quantitative managementhighest probability ofsuccessincreasingManagementCapabilityLevelDisaster• constant crises• no req’s mgt.• no risk mgt.• no discipline• no process. . .• no productincreasingMismatch• “Customer isalways right”hurts.• Customerencourages“short cuts.”Developer7437

Process Areas• CMMI selects only the most importanttopics for process improvement and thengroups those topics into "areas."• This classification results in CMMI version1.1 models with a relatively small set ofprocess areas:– 22 in CMMI-SE/SW and CMMI-SW,– 24 in CMMI-SE/SW/IPPD,– and 25 in CMMI-SE/SW/IPPD/SS.75CMMI Process Area Contents•Purpose•Introductory Notes•Goals: Specific and Generic•Generic Practices•Specific Practices•Notes•Work Products•Subpractices•Amplifications•ElaborationsRequiredExpectedInformative7638

CMMI PAs in PSP and TSPLevel Focus Process Areas (PA)5 Optimizing4 Quantitatively •Managed3 Defined2 ManagedContinuous processimprovementProduct and processqualityEngineering processProject management CMMI SE/SW Staged Representation ProcessArea addressed at the project level when usingPSP and TSP Organizational innovation and deployment Causal analysis and resolution Organizational process performance Quantitative project management Requirements development Technical solution Product integration Verification Validation Organizational process focus Organizational process definitionOrganizational training Integrated project management Risk management Integrated teamingDecision analysis and resolution Organizational environment for integration Requirements management Project planning Project monitoring and controlSupplier agreement management Measurement and analysis Process and product quality assurance Configuration management77Content Classification• Any process-improvement model must, ofnecessity, include a scale relating to theimportance and role of the materialscontained in the model.• In the CMMI models, a distinction is drawnbetween the terms "required,""expected," and "informative."7839

Content Classification• The most important material is required; these items are essential tothe model and to an understanding of what is needed for processimprovement and demonstrations of conformance to the model.• Second in importance is the expected material; these items may notbe fully essential, and in some instances they may not be present inan organization that successfully uses the model.– Nevertheless, expected material is presumed to play a central role inprocess improvement; such items are a strong indicator that therequired components are being achieved.• Third in importance (and largest in quantity) is informative material;these items constitute the majority of the model. The informativematerials provide useful guidance for process improvement, and inmany instances they may offer clarification regarding the intendedmeaning of the required and expected components.79Required Materials• The sole required component of the CMMImodels is the "goal."• A goal represents a desirable end state, theachievement of which indicates that a certaindegree of project and process control has beenachieved.• When a goal is unique to a single process area,it is called a "specific goal" (SG).• In contrast, when a goal may apply across all ofthe process areas, it is called a "generic goal"(GG).8040

Specific Goals - RequirementsManagement• REQM SG 1: Requirements are managedand inconsistencies with project plans andwork products are identified.81Specific Goals - Project Monitoringand Control• PMC SG 2: Corrective actions aremanaged to closure when the project'sperformance or results deviate significantlyfrom the plan.8241

Specific Goals - OrganizationalProcess Performance• OPP SG 1: Baselines and models thatcharacterize the expected processperformance of the organization's set ofstandard processes are established andmaintained.83Specific Goals - Causal Analysisand Resolution• CAR SG 2: Root causes of defects andother problems are systematicallyaddressed to prevent their futureoccurrence.8442

Expected Materials• The only expected component of the CMMI models isthe statement of a "practice."• A practice represents the "expected" means of achievinga goal.• Every practice in the CMMI models is mapped to exactlyone goal.• A practice is not a required component, however; aspecific organization may possess demonstrated meansof achieving a goal that do not rely on the performanceof all the practices that are mapped to that goal.– That is, "alternative" practices may provide an equally useful wayof reaching the goal.85Expected Materials• When a practice is unique to a singleprocess area, it is called a "specificpractice" (SP).• When a practice may apply across all ofthe process areas, it is called a "genericpractice" (GP).8643

Specific Practices Associated withSpecific Goals• Specific Goal– REQM SG 1:Requirements aremanaged andinconsistencies withproject plans and workproducts are identified.• Specific Practice– REQM SP 1.1-1:Develop anunderstanding with therequirementsproviders on themeaning of therequirements.87Specific Practices Associated withSpecific Goals• Specific Goal– PMC SG 2: Correctiveactions are managedto closure when theproject's performanceor results deviatesignificantly from theplan.• Specific Practice– PMC SP 2.1-1: Collectand analyze the issuesand determine thecorrective actionsnecessary to addressthe issues.8844

Specific Practices Associated withSpecific Goals• Specific Goal– OPP SG 1: Baselinesand models thatcharacterize theexpected processperformance of theorganization's set ofstandard processesare established andmaintained.• Specific Practice– OPP SP 1.2-1:Establish and maintaindefinitions of themeasures that are tobe included in theorganization's processperformance analyses.89Specific Practices Associated withSpecific Goals• Specific Goal– CAR SG 2: Rootcauses of defects andother problems aresystematicallyaddressed to preventtheir futureoccurrence.• Specific Practice– CAR SP 2.2-1:Evaluate the effect ofchanges on processperformance.9045

Informative Materials1. Purpose2. Introductory Note3. Reference4. Names5. Practice-to-Goal Relationship Table6. Notes7. Typical Work Products8. Subpractices9. Discipline Amplifications10. Generic Practice Elaborations91DocumentMap9246

CMMI Process AreasProcess Areas by Category withMaturity Level –Process Management• Organizational Process Definition - Level 3• Organizational Process Focus - Level 3• Organizational Training - Level 3• Organizational Process Performance - Level 4• Organizational Innovation and Deployment -Level 59447

Process Management process arearelationships95Organizational Process Definitioncontext diagram9648

CMMI as an Enterprise Process-Improvement Framework• Tie process improvement directly to businessresults.• Be flexible enough to adapt to changingbusiness goals.• Be scalable. It should be as easy for a 10-person group to use as for a 1,500-persongroup.• Emphasize measuring process improvement(goals and changes) and performance, not aparticular "maturity" (level x). The frameworkmust have the ability to show short-term as wellas long-term benefit (i.e., less than one year).97CMMI as an Enterprise Process-Improvement Framework• Help develop a roadmap to achieve businessobjectives.• Address all enterprise processes, as well asprovide for integration of functional areas.• Be accepted by the government andinternational communities as the framework.• Be supported by infrastructure-training,ownership, and so on.9849

CMMI as an Enterprise Process-Improvement Framework• Cost less than today's frameworks.• Trace to existing standards where appropriate.• Be flexible and provide guidance on which elements touse and when.• Be cost-effective to implement.• Help the enterprise focus on the interfaces within theirsystem.• Be specific with regard to appropriate variations fordifferent users.• Be supported by an appraisal method.• Be transparent to the interviewee during an appraisal99Process Areas DescribedDecision Analysis and ResolutionRequirements DevelopmentSupplier AgreementManagementProjectPlanningIntegrated ProjectManagementRisk ManagementProject Monitoringand ControlRequirementsManagementConfigurationManagementQuality AssuranceCausal Analysisand ResolutionTechnicalSolutionProductIntegrationDeficienciesOutcome & FeedbackProductVerificationMeasurementand AnalysisValidationProductsProcessFocusProcessDefinitionInnovation andDeploymentTrainingProcessPerformanceQuantitativeMgmtProcess Maturation10050

Process Management Process Areas101Project Management Process Areas10251

Engineering Process Areas103Support Process Areas10452

CMMI transition project: Schedule• Consider the following guidelines:– Making the transition to CMMI is like implementing othercultural changes in an organization;• the further the starting point on the journey, the longer the trip willtake.– Based on SEI measurements on implementing the CMM forSoftware, organizations with little existing infrastructures orexperience with process improvement projects typically require18 to 24 months to reach maturity level 2.• To reach maturity level 3 typically requires an additional 12months.– Organizations at higher maturity or capability levels in softwareand systems engineering will probably require one year,depending upon the current measurement programs and thenumber of new processes that need to be developed androlled out.• Typically, new processes take at least six months to be rolled outin an organization.105CMMI as an Enterprise Process-Improvement Framework53

Strategy: Use Process FrameworkStandards to Aid in Life Cycle Definition• Systems Life Cycle– ISO/IEC 15288, Systems engineering — System life cycle processes• Software Life Cycle– ISO/IEC 12207, Standard for Information Technology —Software lifecycle processes– IEEE/EIA 12207.0, Industry Implementation of International StandardISO/IEC12207:1995 — (ISO/IEC 12207) Standard for InformationTechnology —Software life cycle processes• IEEE/EIA 12207.1, Industry Implementation of International StandardISO/IEC12207:1995 — (ISO/IEC 12207) Standard for Information Technology—Software life cycle processes – Life Cycle Data• IEEE/EIA 12207.2, Industry Implementation of International StandardISO/IEC12207:1995 — (ISO/IEC 12207) Standard for Information Technology—Software life cycle processes – Implementation considerations107The ISO/IEC 15288 SystemsLife Cycle Process FrameworkSYSTEMLIFE CYCLEENTERPRISEAGREEMENTPROJECTPROJECT PLANNINGTECHNICALSYSTEM LIFE CYCLE MANAGEMENTRESOURCE MANAGEMENTQUALITY MANAGEMENTACQUISITIONSUPPLYENTERPRISE ENVIRONMENT MANAGEMENTINVESTMENT MANAGEMENTPROJECT ASSESSMENTPROJECT CONTROLDECISION MAKINGRISK MANAGEMENTCONFIGURATION MANAGEMENTINFORMATION MANAGEMENTSTAKEHOLDER REQUIREMENTS DEFINITIONREQUIREMENTS ANALYSISARCHITECTURAL DESIGNIMPLEMENTATIONINTEGRATIONVERIFICATIONTRANSITIONVALIDATIONOPERATIONMAINTENANCEDISPOSAL10854

The IEEE/EIA 12207 Software LifeCycle Process FrameworkSOFTWARELIFE CYCLESUPPORTINGPRIMARYDEVELOPMENTOPERATIONMAINTENANCEACQUISITIONSUPPLYDOCUMENTATIONCONFIGURATION MANAGEMENTQUALITY ASSURANCEVERIFICATIONVALIDATIONJOINT REVIEWAUDITPROBLEM RESOLUTIONORGANIZATIONALMANAGEMENTINFRASTRUCTUREIMPROVEMENTTRAININGTAILORING109Relationship between ISO/IEC15288 and ISO/IEC 12207Project Planning Project Assessment Project ControlDecision MakingStakeholderRequirementsDefinitionRequirements AnalysisArchitectural DesignRisk ManagementImplementationIntegrationConfiguration ManagementVerificationValidationTransitionUsabilityInformation ManagementOperationMaintenanceDisposalProjectprocessesTechnicalprocessesHardware ImplementationSoftware ImplementationRefer to ISO/IEC 12207Human TaskImplementationEnterprise EnvironmentManagementInvestment ManagementSystem Life CycleProcesses ManagementResource ManagementQuality ManagementEnterpriseprocessesAcquisitionSupplyAgreementprocesses11055

Strategy: Use Supporting Standards asBest Practice Support for Your DefinedSystem Life CycleLife cycle progressionISO/IEC 15288 Life Cycle Model StagesConcept Development Production Utilization Support RetirementISO/IEC 15288 system life cycle processesIncreasing level of detailActivity level detail from a 2nd StandardFor example, ANSI/EIA 632Taskleveldetailfrom a3rdStandardForexample,IEEE1220Activity level detailfrom a 4th StandardTaskTaskleveldetailfrom a5thStandardA1. ISO/IEC 15288 and other engineering standards111Strategy: Use Supporting Standardsas Best Practice Support for YourDefined Software Life Cycle11256

CMMI SE/SW/IPPD/SS v1.1 StandardsMapping - Process Management• ISO/IEC 15288, System Life CycleProcess Management Processes• IEEE 12207.0, Software Life Cycle• EIA 632 - Processes forProcessesEngineering a System• IEEE 12207.1, Guide to Software LifeCMMI SM SE/SW/IPPD/SS v1.1Cycle Processes—Life Cycle Data• IEEE 1220, Application Process and Area/Specific PracticeManagement of the Systems • IEEE 12207.2, Guide to Software LifeEngineering ProcessCycle Processes—ImplementationConsiderations• IEEE 1074, Developing SoftwareLife Cycle Framework Processes Standards• 1517-1999, Reuse ProcessesSupporting Standards113CMMI SE/SW/IPPD/SS v1.1 StandardsMapping – Project ManagementProject Management• IEEE 1220, Application andManagement of the SystemsEngineering Process• IEEE 1058, Software ProjectManagement Plans• IEEE 1490, A Guide to the ProgramManagement Body of Knowledge• IEEE 1062, Recommended Practicefor Software Acquisition• IEEE 1540, Risk Management• IEEE 1028, Software Reviews• ISO/IEC 15288, System Life CycleProcesses• IEEE 12207.0, Software Life CycleProcesses• IEEE 12207.1, Guide to Software LifeCycle Processes—Life Cycle Data• IEEE 12207.2, Guide to Software LifeCycle Processes—ImplementationConsiderations11457

CMMI SE/SW/IPPD/SS v1.1 StandardsMapping – EngineeringEngineering• IEEE 1233, Guide for DevelopingSystem Requirements Specifications• IEEE 1362, Guide for Concept ofOperations Document• IEEE 1471, Architectural Descriptionof Software Intensive Systems• IEEE 830, Software RequirementsSpecifications• IEEE 1016, Software DesignDescriptions• IEEE 1012, Software Verification andValidation• IEEE 1008, Software Unit Testing• ISO/IEC 15288, System Life Cycle Processes• IEEE 12207.0, Software Life Cycle Processes• IEEE 12207.1, Guide to Software Life CycleProcesses—Life Cycle Data• IEEE 12207.2, Guide to Software Life CycleProcesses—Implementation Considerations• IEEE 1228, Software Safety Plans• IEEE 1063, Software User Documentation• IEEE 1219, Software Maintenance• IEEE 1320.1,.2, IDEF0, IDEF1X97• IEEE 1420.1, Data Model for Reuse LibraryInteroperability115CMMI SE/SW/IPPD/SS v1.1 StandardsMapping – SupportSupport• IEEE 828, Software ConfigurationManagement Plans• IEEE 730, Software QualityAssurance Plans• IEEE 982.1, Dictionary of Measuresto Produce Reliable Software• IEEE 1045, Software ProductivityMetrics• IEEE 1061, Software Quality MetricsMethodology• IEEE 1219, Software Maintenance• ISO/IEC 15288, System Life CycleProcesses• IEEE 12207.0, Software Life CycleProcesses• IEEE 12207.1, Guide to Software LifeCycle Processes—Life Cycle Data• IEEE 12207.2, Guide to Software LifeCycle Processes—ImplementationConsiderations• IEEE 1465 (ISO/IEC 12119) -Software Packages - QualityRequirements and Testing• IEEE 14143.1 (ISO/IEC 1443-1) -Functional Size Measurement - Part1: Definition of Concepts11658

An Example - RequirementsDevelopment SP 2.1-1 Establish Product andProduct Component Requirements– Establish and maintain, from thecustomer requirements, product andproduct component requirementsessential to product and productcomponent effectiveness andaffordability• ISO/IEC 15288, System Life CycleProcesses– Clause 5.5.3 - Requirements AnalysisProcess• IEEE/EIA 12207.0, Software LifeCycle Processes– Clause 5.3.2 - System RequirementsAnalysis– Clause 5.3.4 - Software requirementsanalysis• IEEE 1233, Guide for DevelopingSystem Requirements Specifications• IEEE 830, Software RequirementsSpecifications117An Example - RequirementsDevelopment SP 2.1-1 Establish Product andProduct Component Requirements– Establish and maintain, from thecustomer requirements, product andproduct component requirementsessential to product and product5.5.3 RequirementscomponentAnalysiseffectivenessProcessandaffordability5.5.3.1 Purpose of the Requirements Analysis ProcessThe purpose of the Requirements Analysis Process is to transform thestakeholder, requirement-driven view of desired services into a technical viewof a required product that could deliver those services.This process builds a representation of a future system that will meetstakeholder requirements and that, as far as constraints permit, does not implyany specific implementation. It results in measurable system requirements thatspecify, from the developer’s perspective, what characteristics it is to possessand with what magnitude in order to satisfy stakeholder requirements.5.5.3.2 Requirements Analysis Process OutcomesAs a result of the successful implementation of the Requirements AnalysisProcess:a) The required characteristics, attributes, and functional and performancerequirements for a product solution are specified.b) Constraints that will affect the architectural design of a system and themeans to realize it are specified.c) The integrity and traceability of system requirements to stakeholderrequirements is achieved.. . .• ISO/IEC 15288, System Life CycleProcesses– Clause 5.5.3 - Requirements AnalysisProcess• IEEE/EIA 12207.0, Software LifeCycle Processes– Clause 5.3.2 - System RequirementsAnalysis– Clause 5.3.4 - Software requirementsanalysis• IEEE 1233, Guide for DevelopingSystem Requirements Specifications• IEEE 830, Software RequirementsSpecifications11859

An Example - RequirementsDevelopment5.3.2.1 The specific intended use of the system to be developedshall be analyzed to specify system requirements. The systemrequirements specification shall describe: functions andcapabilities of the system; business, organizational and userrequirements; safety, security, human-factors engineering(ergonomics), interface, operations, and maintenancerequirements; design constraints and qualification requirements.The system requirements specification shall be documented.5.3.4.1 The developer shall establish and document softwarerequirements, including the quality characteristics specifications, SP 2.1-1 Establish Productand Product Componentdescribed below. . . .Requirementsa) Functional and capability specifications, including performance,physical characteristics, and environmental conditions underwhich the software item is to perform;b) Interfaces external to the software item;c) Qualification requirements;d) Safety specifications, including those related to methods ofoperation and maintenance, environmental influences, andpersonnel injury;e) Security specifications, including those related to compromiseof sensitive information . . .– Establish and maintain, fromthe customer requirements,product and productcomponent requirementsessential to product andproduct componenteffectiveness and affordability• ISO/IEC 15288, System Life CycleProcesses– Clause 5.5.3 - Requirements AnalysisProcess• IEEE/EIA 12207.0, Software LifeCycle Processes– Clause 5.3.2 - System RequirementsAnalysis– Clause 5.3.4 - Software requirementsanalysis• IEEE 1233, Guide for DevelopingSystem Requirements Specifications• IEEE 830, Software RequirementsSpecifications119An Example - RequirementsDevelopment7.2 Build a well-formed requirementThe analysts carry out this subphase by doing the following:a) Ensuring that each requirement is a necessary, short, definitivestatement of need (capability, constraints);b) Defining the appropriate conditions (quantitative or qualitativemeasures) for each requirement and avoiding adjectives such as SP 2.1-1 Establish Product“resistant” or “industry wide;”c) Avoiding and requirements Product pitfalls Component(see 6.4);Requirementsd) Ensuring the readability of requirements, which entails the following:1) Simple words/phrases/concepts;2) Uniform arrangement and relationship;– Establish maintain, from3) Definition of unique words, symbols, and notations;4) The use the of grammatically customer correct requirements,language and symbology.e) Ensuring testability.product and productExample:Capability: component Move people between requirementsLos Angeles and New YorkCondition: Cruising speed of 200 km/hressential to product andConstraint: Maximum speed of 300 km/hrWell-formed product requirement: componentThis system should move people betweenLos Angeles and New York at an optimal cruising speed of 200 km/hreffectiveness and affordabilitywith a maximum speed of 300 km/hr.• ISO/IEC 15288, System Life CycleProcesses– Clause 5.5.3 - Requirements AnalysisProcess• IEEE/EIA 12207.0, Software LifeCycle Processes– Clause 5.3.2 - System RequirementsAnalysis– Clause 5.3.4 - Software requirementsanalysis• IEEE 1233, Guide for DevelopingSystem Requirements Specifications• IEEE 830, Software RequirementsSpecifications12060

An Example - RequirementsDevelopment SP 2.1-1 Establish Productand Product ComponentRequirements– Establish and maintain, fromthe customer requirements,product and productcomponent requirementsessential to product andproduct componenteffectiveness and affordability• ISO/IEC 15288, System Life CycleProcesses– Clause 5.5.3 - Requirements AnalysisProcess• IEEE/EIA 12207.0, Software LifeCycle Processes– Clause 5.3.2 - System RequirementsAnalysis– Clause 5.3.4 - Software requirementsanalysis• IEEE 1233, Guide for DevelopingSystem Requirements Specifications• IEEE 830, Software RequirementsSpecifications121An Example - RequirementsDevelopment5.3.2 FunctionsFunctional requirements should define the fundamental actions thatmust take place in the software in accepting and processing the inputsand in processing and generating the outputs. These are generallylisted as “shall” statements starting with “The system shall”These include:a) Validity checks on the inputsb) Exact SP sequence 2.1-1 of Establish operations Productc) Responses to abnormal situations, including:1) Overflow and Product Component2) Communication facilitiesRequirements3) Error handling and recoveryd) Effect–ofEstablishparametersand maintain, frome) Relationship of outputs to inputs . . .1) It may the be appropriate customer partition requirements,the functional requirements intosubfunctionsproductor subprocesses.and productThis doesnot imply that the software design will also be partitioned that way.5.3.3 Performance component requirements requirementsThis subsection should specify both the static and the dynamicessential to product andnumerical requirements placed on the softwareor on product human interaction component with the software as a whole. Staticnumerical requirements may include theeffectiveness and affordabilityfollowing:a) The number of terminals to be supported;b) The number of simultaneous users to be supported;c) Amount and type of information to be handled.• ISO/IEC 15288, System Life CycleProcesses– Clause 5.5.3 - Requirements AnalysisProcess• IEEE/EIA 12207.0, Software LifeCycle Processes– Clause 5.3.2 - System RequirementsAnalysis– Clause 5.3.4 - Software requirementsanalysis• IEEE 1233, Guide for DevelopingSystem Requirements Specifications• IEEE 830, Software RequirementsSpecifications12261

An Example - RequirementsDevelopment SP 2.1-1 Establish Productand Product ComponentRequirements– Establish and maintain, fromthe customer requirements,product and productcomponent requirementsessential to product andproduct componenteffectiveness and affordability• ISO/IEC 15288, System Life CycleProcesses– Clause 5.5.3 - Requirements AnalysisProcess• IEEE/EIA 12207.0, Software LifeCycle Processes– Clause 5.3.2 - System RequirementsAnalysis– Clause 5.3.4 - Software requirementsanalysis• IEEE 1233, Guide for DevelopingSystem Requirements Specifications• IEEE 830, Software RequirementsSpecifications123Strategy: Base Your Business Activities onYour Defined Processes• Institutionalize your processes– Train your workforce in yourdefined processes– Incentivize both managementand staff• Check process performance– Goal Process Results(GPR)• A business-focused Plan Do Check Act cycle• For a given set of resultseither goals or processes maybe modifiedGoalProcessResults12462

Strategy: Establish an Active MeasurementProgram• For both Processes and Products:– Identify measurement objectives that are aligned with yourbusiness needs– Choose specific measures, data collection and storagemechanisms, analysis techniques, and reporting and feedbackmechanisms that support your measurement objectives– Implement your measurement program– Provide decision-makers with objective results that can be usedin making informed decisions– Periodically assess your measurement program to ensure thatit is meeting current business needs125Benefits at Boeing 1Projects operating atMaturity Level 3increased productivityby 62%...•… while cycle timesimproved 36%.Reference: Scott Griffin, Chief Information Officer, The Boeing Company, SEPG Conference, 2000.12663

Benefits at Boeing 2•Bothcustomer...… and employeesatisfaction increasedwith rising maturitylevels.127Benefits at Boeing 3Planningwas moreaccurate.Defects couldbe detectedmuch earlier.Product qualityincreased withrising maturitylevels.12864

Sector Business CaseAdvantagesDoD ContractorDoD Customers- May require process maturityin RFP implicitly or explicitly- May use maturity as adiscriminatorDoDCustomersAssociateContractorsAssociate Contractors- Improves integration ofproducts and servicesCompetitors- Will use processmaturity to advisecustomers- Will use processmaturity to competitiveadvantageCompetitorsSubcontractorsYour CompanyName HereSubcontractor- Improves integration ofproducts and services- Provides insight into subcontractorperformance and quality13065

DoD Contractor• DoD contractors are motivated to adopt processimprovement initiatives for the following reasons:– DoD acquisition agencies and policy directivesrequire them for bidding– To improve performance on software developmentand systems engineering efforts– To improve interface compatibility with associatecontractors– To gain insight into vendor, supplier, andsubcontractor delivery and performance131Joint Government / DoD ContractorContractorAcquisitionOperationsSmallerIPTsDefense BudgetsCOTSRapid TechnologyChange•Sustainment13266

Joint Government / DoD Contractor• Implementation of CMMI affords all stakeholdersin the Joint Government/DoD Contractorenvironment these benefits:– A common business/process language– Improvement in business performance throughprocess improvement (more productivity, higherquality, shorter cycle time)– More consistent and effective process assessmentacross multiple business units– Better integrated processes across multipledisciplines133CommercialCommercial Environment CMMI Adopters- Improve Customer satisfaction- To meet business objectives of increasing revenue and profitability- Enhance time-to-market performance13467

Commercial• Product development in the commercial environment drives revenuefor the corporation:– Strategic planning for the corporation is driven by market pressures withthe ultimate goal of improving revenue and profitability.– Process discipline will enhance productivity by reducing the time tomarket.– Customer satisfaction will increase with measurable improvements inreliability and quality.– Process improvement activities compete for corporate resources:• Return on investment must be equal to or better than other opportunities.• Examples for software process improvement:[1]– Development time Reduced 73%– Rework costs Reduced 96%– Average schedule length Reduced 37%– Post release defects Reduced 80%– Return on investment 21:1135Commercial13668

SummaryCMMI aids organizations to …Improve delivery of promised performance, cost,and schedule Collaborate with external stakeholders and managetheir expectations Provide competitive world-class products andservices Implement an integrated enterprise business andengineering perspective Master system-of-systems evolutionary developmentcomplexity Use common, integrated, and improving processesfor systems and software13869

CMMI also aids organizations to …Implement proactive program managementtechniquesDevelop project leaders who look ahead and not overtheir shoulderDevelop a staff who use best practices to cope withchanging development, technology, and customerenvironmentsEnable staff to move between projects and still usethe same processesCreate and improve processes that adapt to achanging business environment139CMMI is….•a process improvement method that providesa set of best practices that addressproductivity, performance, costs, andstakeholder satisfaction.•It is NOT• • • 14070