The Capability Maturity Model for Software An Overview
The Capability Maturity Model for Software: An Overview 1
es ” ul ng ed thi ch ry “S eve n ru 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” “Proc esses limit m y crea “Proces ses don ’t “Ju st the send in Tige r Te am” The Problem: too many immature software organizations tivity” help my delivery s chedule ” 2
Capability Maturity Model Overview • Developed at the Do. D-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 3
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 4
The CMM’s Five Maturity Levels Level 5 Optimizing Level 4 Managed Level 3 Defined Level 2 Repeatable Level 1 Initial Continuous process capability improvement Product quality planning, tracking of measured software process Software process defined and institutionalized to provide product quality control Management oversight and tracking of project; stable planning and product baselines Ad hoc; success depends on heroes 5
Process Maturity Benefits Software engineering and management processes defined and integrated Target Probability Time / $ 4 Time / $ 3 Target Defined Product and process are quantitatively controlled 5 Target Managed Process improvement is institutionalized Predicted Performance Probability Optimizing Process Characteristics Probability Level Target Process is informal and ad-hoc; performance is unpredictable 2 Time / $ 1 Target Initial Probability Repeatable Project management System in place; performance is repeatable Probability Time / $ 6
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 7
Level 1 - Initial Level 1: Just do it. Activity to produce Results 8
Level 2 - Repeatable Level 2: Think before you act, and think after you act, just to make sure you did it right. Planning Activity to produce Results input to Evaluation to improve 9
Level 3 - Defined Level 3: Defined Standards are used for all activities. Planning input to Activity to produce Results input to Standards input to Evaluation to improve 10
Level 4 - Managed input to Standards • Planning Activity input to to forecast to produce Results input to Evaluation to improve 11
Level 5 - Optimized input to Standards Planning Activity input to continuous improvement to forecast to produce Results input to Evaluation to improve 12
Levels/ Process Categories Management • Technology Change Management • Process Change Management 5 Optimizing 4 Managed 3 Defined Organizational • Quantitative Software Management • Integrated Software Management • Inter-group Coordination 2 Repeatable • Requirements Management • Software Project Planning • Software Project Tracking and Oversight • Software Subcontract Management • Software Quality Assurance • Software Configuration Management 1 Initial Ad Hoc Processes Engineering Defect Prevention • Software Quality Management • Organization Process Focus • Organization Process Definition • Training Program • Software Product Engineering • Peer Reviews 13
Results, Needs, and Activities the CMM Supports Results Needs (Actions) Activities (steps) KPA Level 2: Clarify requirements Establish Document plans basic project management Track progress processes Control products Baseline the requirements allocated to software RM Estimate project size, effort, cost, resources SPP Establish project plans, estimates, processes, risks SPP Measure actual progress for timely action SPTO Verify adherence of products and activities to reqts. SQA Identify & control products, changes, problems SCM Select qualified contractors, manage their activities SSM Level 3: Standardize processes Standardize the organization’s software process Cultivate teamwork activities Reduce defects Establish organizational responsibility for SPI Define the org’s best practices, set asset database Establish standards for software engrg. activities Tailor the org’s best practices to projects Get agreement from all on reqts. and commitments Develop skills and knowledge of team members Identify & remove defects early and efficiently Level 4: Analyze Set goals Set numeric goals for process performance processes & Set quality goals for the software products Manage progress Measure the performance of the software processes for monitoring, quantitatively Measure progress toward product quality goals control Level 5: Institutionalize Optimize Identify and eliminate the cause of defects process performance Continually improve quality, productivity, cycle times improvement Adapt new technologies Identify new technologies, transition them to use 14 OPF OPD SPE ISM IC TP PR QPM SQM DP PCM TCM
Sample Level 1 Software Organization few processes in place The Organization Top Management Dept. A Middle Management Projects Project 1 Div. AA Project 2 Dept. B Dept. C Div. BB Project 3 Project 4 Processes 15
Sample Level 2 Software Organization many processes in place; but they are project-specific The Organization Top Management Dept. A Middle Management Projects Project 1 Div. AA Project 2 Dept. B Dept. C Div. BB Project 3 Project 4 Processes 16
Sample Higher-Level Organization processes based on organization’s Process Asset Library (PAL) The Organization Process Asset Library Approved life cycles Standard processes Tailoring guidelines Process database Related documents SEPO Dept. A Div. AA Projects Project 1 Project 2 Dept. B Dept. C Div. BB Project 3 Project 4 Processes 17
SEI Capability Maturity Model Result Level Characteristic Key Process Areas Productivity & Quality Optimizing Continuous process (5) capability improvement Managed (4) Defined (3) Process change management Technology change management Defect prevention Product quality planning; Software quality management tracking of measured Quantitative process management software process Peer reviews Intergroup coordination Software process defined Software product engineering and institutionalized to Integrated software management provide product quality Training program control Organization process definition Organization process focus Repeatable Management oversight and tracking project; (2) stable planning and product baselines Initial (1) Ad hoc (success depends on heroes) Software configuration management Software quality assurance Software subcontract management Software project tracking & oversight Software project planning Requirements management "People" Risk 18
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 19
Example: Structure of the Software Project Planning KPA Purpose Goals • Establish reasonable plans for software engineering and managing the project • Software estimates are documented and used • Activities and commitments are documented • Groups agree to their commitments Commitments • Abilities • Activities • A project software manager is designated An organizational policy for planning is followed • Resources and funding are provided Training in estimating and planning is provided • 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 20
CMM Structure Maturity Levels Key Process Areas RM PP 2 PT 3 SM QA 5 4 CM Goals Common Features Activities Performed Commitment to Perform Ability to Perform Measurement and Analysis Verifying Implementation Key Practices 21
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. 22
Some CMM Variants SW-CMM Capability Maturity Model for Software T-CMM Trusted CMM SSE-CMM Systems Security Engineering CMM SE-CMM Systems Engineering CMM P-CMM People CMM SA-CMM Software Acquisition CMM IPD-CMM Integrated Product Development CMM FAA-i. CMM FAA’s integrated CMM (SW-CMM, SE-CMM, SA-CMM) CMMI CMM Integration (SW-CMM, SE-CMM, SA-CMM, IPD-CMM) 23
CMM References • Capability Maturity Model (CMM) for Software, Version 1. 1. CMU/SEI-93 -TR-24 & 25 , February 1993 – http: //sepo. spawar. navy. mil/sepo/CMMinfo. html • Benefits of CMM-Based Software Process Improvement: Initial Results. CMU/SEI-94 -TR-13, August 1994 – http: //www. sei. cmu. edu/publications/documents/94. reports/94. tr. 013. html • A Software Process Framework for the SEI CMM, Handbook. CMU/SEI-94 -HB-01, September 1994 – • • http: //www. sei. cmu. edu/publications/documents/94. reports/94. hb. 001. html Article: The Capability Maturity Model for Software. Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, Charles V. Weber. (in Section 7 of SME Guidebook) – http: //www. sei. cmu. edu/publications/documents/96. reports/96. ar. cmm. v 1. 1. html SEI CMM Level 5: For the Right Reasons. George Yamamura and Gary Wigle, Boeing Defense & Space Group. Cross. Talk, August 1997. – http: //www. stsc. hill. af. mil/Cross. Talk/1997/aug/seicmm 5. html • • SEPO’s Power Point presentation on “The Capability Maturity Model: an Overview” http: //sepo. spawar. navy. mil/sepo/CMMinfo. html Key Process Area flow charts, at http: //sepo. spawar. navy. mil/sepo/CMMinfo. html 24
- Slides: 24