1 The Capability Maturity Model for Software: An Overview

2 The Problem: too many immature software organizations Good performance is possible - but Requirements often misunderstood, uncontrolled Schedules and budgets frequently missed Progress not measured Product content not tracked or controlled Engineering activities nonstandard, inconsistent Teams not coordinated, not trained Defects proliferate Success depends on “heroes” “Schedules run everything” “Processes limit my creativity” “Processes don’t help my delivery schedule” “Just send in the Tiger Team”

3 Capability Maturity Model Overview Developed at the DoD-sponsored Software Engineering Institute (SEI) Focuses on practices that are under control of the software group Describes common sense, efficient, proven ways of doing business (which you should already be doing) - not a radical new approach Presents a minimum set of recommended practices that have been shown to enhance a software development and maintenance capability – It defines the expectation (the “what”) – Without overly constraining the implementation (the “how”) Used by Government and industry around the world to measure maturity of software development organizations Being updated in the SEI’s CMM Integration (CMMI) effort

4 Objectives of the CMM To increase customer satisfaction, by producing products according to plan while simultaneously improving the organization’s capability to produce better products To increase software process maturity, the extent to which processes are explicitly defined, managed, measured, controlled, and effective, by: Establishing basic project management controls Standardizing the organization's software process activities Quantitatively analyzing processes and products for monitoring and control Institutionalizing process improvement

5 Level 5 Optimizing Level 5 Optimizing Continuous process capability improvement Level 4 Managed Level 4 Managed Product quality planning, tracking of measured software process Level 3 Defined Level 3 Defined Software process defined and institutionalized to provide product quality control Level 2 Repeatable Level 2 Repeatable Management oversight and tracking of project; stable planning and product baselines Level 1 Initial Level 1 Initial Ad hoc; success depends on heroes The CMM’s Five Maturity Levels

6 Process Maturity Benefits Initial Repeatable Defined Managed Optimizing Process is informal and ad-hoc; performance is unpredictable Project management System in place; performance is repeatable Software engineering and management processes defined and integrated Product and process are quantitatively controlled Process improvement is institutionalized Level Process Characteristics 5 Probability Time / $ Target Probability Time / $ Target 4 Probability Target 3 Time / $ Probability Time / $ Target 2 Probability Time / $ Target 1 Predicted Performance

7 CMM Building Blocks: the Maturity Levels Institutionalize process improvement Quantitative analysis of processes and products for monitoring and control Standardize the software process activities for all the organization’s projects Establish basic project management controls

8 ActivityResults to produce Level 1: Just do it. Level 1 - Initial

9 Activity Results to produce Level 2: Think before you act, and think after you act, just to make sure you did it right. Planning Evaluation input to to improve Level 2 - Repeatable

10 Level 3 - Defined Standards Activity Results to produce Planning Evaluation input to to improve input to Level 3: Defined Standards are used for all activities.

11 Level 4 - Managed Standards Activity Results to produce Planning Evaluation input to to improve input to to forecast

12 Level 5 - Optimized Standards Activity Results to produce Planning Evaluation input to to improve input to to forecast continuous improvement

13 Process Categories ManagementOrganizationalEngineering Levels/ 1 Initial 2 Repeatable 3 Defined 4 Managed 5 Optimizing Ad Hoc Processes Integrated Software Management Inter-group Coordination Requirements Management Software Project Planning Software Project Tracking and Oversight Software Subcontract Management Software Quality Assurance Software Configuration Management Organization Process Focus Organization Process Definition Training Program Software Product Engineering Peer Reviews Software Quality Management Quantitative Software Management Technology Change Management Process Change Management Defect Prevention

14 Project Management Risks Addressed by CMM Level 2 RisksIssue Little agreement on technical requirementsRequirements Weak control over changes to requirements Weak understanding of activities, effort, and time requiredPlans Sketchy plans, schedules, budgets Program risks not identified or managed Weak visibility into actual progressProgress No ability to take corrective action Little visibility into quality of products and processes Weak control over contents and changes to productsControl Contractors not qualified to perform the work Weak control over contractor activities and products

15 CMM Level 2: the “Repeatable” Level - Establishing basic project management controls Builds a “foundation” for Process Improvement Actions: –CLARIFY REQUIREMENTS –DOCUMENT PLANS –TRACK PROGRESS –CONTROL PRODUCTS

16 What to Do at Level 2 Baseline the requirements allocated to software Estimate the project’s size, effort, costs, and resources Establish the project plans and processes; identify risks Measure actual progress to enable timely corrective action Verify adherence of products and activities to requirements Identify and control software products, changes, problem reports Select qualified subcontractors; manage their activities CLARIFY REQUIREMENTS DOCUMENT PLANS TRACK PROGRESS CONTROL PRODUCTS Key Process Area –Requirements Management (RM) Software Project Planning (SPP) –Software Project Tracking and Oversight (SPTO) –Software Quality Assurance (SQA) –Software Configuration Management (SCM) –Software Subcontractor Management (SSM)

17 Organizational Process Risks Addressed by CMM Level 3 RisksIssue No centralized coordination of the way we produce Processes software No central source / repository of processes, templates, samples, lessons learned, project data Engineering activities unplanned, uncoordinated, inconsistent among projects Management activities not coordinated with technical activities Engineering groups not coordinated, little Teamwork understanding of roles or commitments Team members unprepared for their jobs Defects proliferate in products Defects

18 CMM Level 3: the “Defined” Level - Standardizing the Organization’s software process activities Focus changes from the project level to the organization level Capabilities are based on practices established in Level 2 Emphasis is on developing software across the organization Actions: –STANDARDIZE PROCESSES –CULTIVATE TEAMWORK –REDUCE DEFECTS

19 What you see at Level 3 Establish organizational responsibility for SPI Define the organization’s best practices; establish asset database Tailor the organization’s best practices to projects Establish standards for software engineering activities Get agreement from all parties on requirements and commitments Develop the skills and knowledge of team members Identify and remove defects early and efficiently STANDARDIZE PROCESSES CULTIVATE TEAMWORK REDUCE DEFECTS Key Process Areas –Organizational Process Focus(OPF) –Organizational Process Definition (OPD) –Integrated Software Management (ISM) –Software Product Engineering (SPE) –Intergroup Coordination (IC) –Training Program (TP) –Peer Reviews (PR)

20 Quantitative Management Risks Addressed by CMM Level 4 RisksIssue No controls or expectations of process performance Goals No ability to set and achieve quality goals for products Limited understanding of the performance of a project’s Progress processes Limited measures of the quality of software products

21 CMM Level 4: the “Managed” Level - Quantitative analysis of processes and products for monitoring and control Measurements taken at previous levels are used to manage both products and processes Actions: –SET GOALS –MANAGE PROGRESS QUANTITATIVELY

22 A few things more at Level 4 Set numeric goals for process performance Set quality goals for the software products Measure the performance of the software processes Measure progress toward product quality goals SET GOALS MANAGE PROGRESS QUANTITATIVELY Key Process Areas –Quantitative Process Management(QPM) –Software Quality Management(SQM) –Quantitative Process Management(QPM) –Software Quality Management(SQM)

23 Continuous Improvement Risks Addressed by CMM Level 5 RisksIssue Defects keep recurring, causes are not known Performance Process improvement activities are not uniform or fully institutionalized New technologies (tools, methods, processes) are notNew recognized or adoptedTechnologies

24 CMM Level 5: the “Optimizing” Level - Institutionalizing process improvement Actions: –OPTIMIZE PERFORMANCE –ADAPT NEW TECHNOLOGIES The organization is focused on continuous process improvement

25 How to thrive at Level 5 Identify and eliminate the cause of defects Continually improve quality, productivity, cycle times Identify new technologies; transition them to use OPTIMIZE PERFORMANCE ADAPT NEW TECHNOLOGIES Key Process Areas –Defect Prevention(DP) –Process Change Management (PCM) –Technology Change Management (TCM)

26 Results, Needs, and Activities the CMM Supports Results Needs (Actions) Activities (steps) Level 2: Clarify requirements Establish Document plans basic project management Track progress processes Control products Level 3: Standardize processes Standardize the organization’s software process Cultivate teamwork activities Reduce defects Level 4: Analyze Set goals processes & products Manage progress for monitoring, quantitatively control Level 5: Institutionalize Optimize process performance improvementAdapt new technologies KPA Baseline the requirements allocated to softwareRM Estimate project size, effort, cost, resourcesSPP Establish project plans, estimates, processes, risksSPP Measure actual progress for timely actionSPTO Verify adherence of products and activities to reqts.SQA Identify & control products, changes, problemsSCM Select qualified contractors, manage their activitiesSSM Establish organizational responsibility for SPIOPF Define the org’s best practices, set asset databaseOPD Establish standards for software engrg. activitiesSPE Tailor the org’s best practices to projectsISM Get agreement from all on reqts. and commitmentsIC Develop skills and knowledge of team membersTP Identify & remove defects early and efficientlyPR Set numeric goals for process performanceQPM Set quality goals for the software productsSQM Measure the performance of the software processesQPM Measure progress toward product quality goalsSQM Identify and eliminate the cause of defectsDP Continually improve quality, productivity, cycle timesPCM Identify new technologies, transition them to useTCM

27 Top Management Middle Management Dept. B The Organization Dept. A Dept. C Project 1 Div. BB Div. AA Project 4 Project 3 Project 2 Projects Processes Sample Level 1 Software Organization few processes in place

28 Top Management Middle Management Dept. B The Organization Dept. A Dept. C Project 1 Div. BB Div. AA Project 4 Project 3 Project 2 Projects Processes Sample Level 2 Software Organization many processes in place; but they are project-specific

29 Sample Higher-Level Organization processes based on organization’s Process Asset Library (PAL) Div. AA The Organization Dept. A Dept. C Div. BB Projects Processes Project 1Project 2 Dept. B Project 3Project 4 SEPO Process Asset Library Approved life cycles Standard processes Tailoring guidelines Process database Related documents

30 SEI Capability Maturity Model Result LevelCharacteristic Optimizing Continuous process Process change management (5) capability improvement Technology change management Defect prevention Managed (4) Defined Software process defined (3) and institutionalized to provide product quality control Repeatable (2) Initial (1) Product quality planning; Software quality management tracking of measured Quantitative process management software process Management oversight and tracking project; stable planning and product baselines Key Process Areas Ad hoc (success depends on heroes) "People" Software configuration management Software quality assurance Software subcontract management Software project tracking & oversight Software project planning Requirements management Peer reviews Intergroup coordination Software product engineering Integrated software management Training program Organization process definition Organization process focus Risk Productivity & Quality Productivity & Quality

31 Key Process Area (KPA) Structure Each of the 18 CMM Key Process Areas (KPAs) has: Purpose Goals Common Features: - Commitment to perform: sponsorship and policies - Ability to perform: resources, organization, training - Activities to perform - Measurement of performance - Verification of performance

32 Example: Structure of the Software Project Planning KPA Purpose Establish reasonable plans for software engineering and managing the project Goals Software estimates are documented and used Activities and commitments are documented Groups agree to their commitments Commitments A project software manager is designated An organizational policy for planning is followed Abilities Resources and funding are provided Training in estimating and planning is provided Activities Estimate project parameters - size, effort, cost, schedules, risks Plan software activities - goals, life cycle, processes, standards Get agreements to commitments - from practitioners, management, others Measurements Track planning status Verifications Review plans with management Conduct independent review of planning

33 CMM Structure Maturity Levels Key Process Areas Goals Common Features Key Practices RMPPPTSMCMQA Commitment to Perform Ability to Perform Activities Performed Measurement and Analysis Verifying Implementation

34 How is a Maturity Level determined? The Software Capability Evaluation (SCE) Description: A structured CMM-Based Appraisal in which a trained team examines an organization’s current software practices. It consists of interviews, questionnaires, and analysis designed to identify the current process capability. Evaluators: A team of 4-6 SCE-trained people, external or internal to the organization Process: Typically one week of preparation off-site, then one week of on-site interviews and analysis, using the SCE process (see guidelines on SSC San Diego PAL) Results: Comprehensive verbal and written findings of strengths, weaknesses, and areas to improve. Can optionally result in a validated maturity level.

35 Process Maturity Profile of Software Community Source:

36 Know Thy Competition Some Organizations at CMM Level 4 or 5 BFL SoftwareBoeingCG-Smith Software Citicorp OverseasCognizant TechCSC Defense Group CSC Civil GroupDCM TechDSQ Tech Future SoftwareHCL Perot SystemsHoneywell Hughes IBM Global ServicesInt. Computers Litton PRCLockheed MartinMotorola NCRNetwork SystemsNorthrop Grumman OracleRaytheonSatyam Computer Siemens Info SystemsSilverline TechTata Consultancy Telcordia TechUnited Space AllianceUSAF Hill AFB USAF Tinker AFBUSA CECOMUSN FMSO USN NAWC China LakeWipro GE Med Systems

37 SW-CMMCapability Maturity Model for Software T-CMMTrusted CMM SSE-CMMSystems Security Engineering CMM SE-CMMSystems Engineering CMM P-CMMPeople CMM SA-CMMSoftware Acquisition CMM IPD-CMMIntegrated Product Development CMM FAA-iCMMFAA’s integrated CMM (SW-CMM, SE-CMM, SA-CMM) CMMICMM Integration (SW-CMM, SE-CMM, SA-CMM, IPD-CMM) Some CMM Variants

38 Points to Remember! CMM Level 2 focuses on basic management practices of the _______________ CMM Level 3 concentrates on standard software processes of the _______________ Most software organizations today are at CMM Level _____ The primary objective of the CMM is ___________________________________________ The CMM was developed by _________

39  Describing The CMM: Summary The “Business Case” for using the CMM was addressed in an Air Force Institute of Technology (AFIT) study: The aim was to determine any correlation between the CMM rating and software development success Observed improved cost and schedule performance with increased process maturity. –Less mature organizations were likely to have difficulty adhering to cost and schedule baselines –More mature organizations were likely to meet cost and schedules Conclusion: Validated a statistical correlation between project success and CMM ratings CrossTalk, September 1995

40 CMM References Capability Maturity Model (CMM) for Software, Version 1.1. CMU/SEI-93-TR-24 & 25, February 1993 – Benefits of CMM-Based Software Process Improvement: Initial Results. CMU/SEI-94-TR-13, August 1994 – A Software Process Framework for the SEI CMM, Handbook. CMU/SEI-94-HB-01, September 1994 – Article: The Capability Maturity Model for Software. Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, Charles V. Weber. (in Section 7 of SME Guidebook) – SEI CMM Level 5: For the Right Reasons. George Yamamura and Gary Wigle, Boeing Defense & Space Group. CrossTalk, August – SEPO’s Power Point presentation on “The Capability Maturity Model: an Overview” Key Process Area flow charts, at

41 Backup CMM Material Key Process Areas of each Maturity Level Level 1 Processes and results Goals, Artifacts, and Training requirements of each KPA at Levels 2, 3, 4, 5

42