The Capability Maturity Model for Software: An Overview
description
Transcript of The Capability Maturity Model for Software: An Overview
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”
“Ju
st s
end
in t
he
Tig
er T
eam
”
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 5Optimizing
Level 5Optimizing
Continuous process capability improvement
Level 4Managed
Level 4Managed
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 2Repeatable
Level 2Repeatable
Management oversight and tracking of project; stable planning and product baselines
Level 1Initial
Level 1Initial Ad hoc; success depends on heroes
The CMM’s Five Maturity Levels
6
Process Maturity Benefits
Initial
Repeatable
Defined
Managed
Optimizing
Process is informal andad-hoc; performance is unpredictable
Project managementSystem in place;performance is repeatable
Software engineering and management processesdefined and integrated
Product and process arequantitatively controlled
Process improvementis institutionalized
Level Process Characteristics
5
Pro
ba
bil
ity
Time / $ Ta
rge
t
Pro
ba
bil
ity
Time / $
Ta
rge
t
4
Pro
ba
bil
ity
Ta
rge
t
3
Time / $
Pro
ba
bil
ity
Time / $ Ta
rge
t
2
Pro
ba
bil
ity
Time / $ Ta
rge
t
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
Activity Resultsto produce
Level 1:Just do it.
Level 1 - Initial
9
Activity Resultsto 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 Resultsto produce
Planning
Evaluation
input to
to improveinput to
input to
Level 3:Defined Standards are used for all activities.
11
Level 4 - Managed
• Standards Activity Resultsto produce
Planning
Evaluation
input to
to improve
input to
input to to forecast
12
Level 5 - Optimized
Standards Activity Resultsto produce
Planning
Evaluation
input to
to improve
input to
input to to forecast
continuous improvement
13
Process Categories
Management Organizational Engineering
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
Risks Issue
• Little agreement on technical requirements Requirements • Weak control over changes to requirements
• Weak understanding of activities, effort, and time required Plans• Sketchy plans, schedules, budgets • Program risks not identified or managed
• Weak visibility into actual progress Progress• No ability to take corrective action • Little visibility into quality of products and processes
• Weak control over contents and changes to products Control• 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
Risks Issue
• 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
Risks Issue
• 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 ProcessManagement
(QPM)– Software Quality
Management(SQM)
– Quantitative ProcessManagement
(QPM)– Software Quality
Management(SQM)
23
Continuous Improvement Risks Addressed by CMM Level 5
Risks Issue
• Defects keep recurring, causes are not known Performance
• Process improvement activities are not uniform or fully institutionalized
• New technologies (tools, methods, processes) are not New recognized or adopted Technologies
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 ChangeManagement
(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 goalsprocesses &products Manage progress for monitoring, quantitativelycontrol Level 5:Institutionalize Optimizeprocess performance improvement Adapt new technologies
KPA
Baseline the requirements allocated to software RMEstimate project size, effort, cost, resources SPPEstablish project plans, estimates, processes, risks SPPMeasure actual progress for timely action SPTOVerify adherence of products and activities to reqts. SQAIdentify & control products, changes, problems SCMSelect qualified contractors, manage their activities SSM
Establish organizational responsibility for SPI OPFDefine the org’s best practices, set asset database OPDEstablish standards for software engrg. activities SPETailor the org’s best practices to projects ISMGet agreement from all on reqts. and commitments ICDevelop skills and knowledge of team members TPIdentify & remove defects early and efficiently PR
Set numeric goals for process performance QPMSet quality goals for the software products SQMMeasure the performance of the software processes QPMMeasure progress toward product quality goals SQM
Identify and eliminate the cause of defects DPContinually improve quality, productivity, cycle times PCMIdentify new technologies, transition them to use TCM
27
Top Management
Middle Management
Dept. BDept. B
The OrganizationThe Organization
Dept. ADept. A Dept. CDept. C
Project 1
Div. BBDiv. AA
Project 4Project 3Project 2Projects
Processes
Sample Level 1 Software Organizationfew processes in place
28
Top Management
Middle Management
Dept. BDept. B
The OrganizationThe Organization
Dept. ADept. A Dept. CDept. C
Project 1
Div. BBDiv. AA
Project 4Project 3Project 2Projects
Processes
Sample Level 2 Software Organizationmany processes in place; but they are project-specific
29
Sample Higher-Level Organizationprocesses based on organization’s Process Asset Library (PAL)
Div. AA
The OrganizationThe Organization
Dept. ADept. A Dept. CDept. C
Div. BB
Projects
Processes
Project 1 Project 2
Dept. B
Project 3
Project 4
SEPOSEPO
Process Asset Library Approved life cycles Standard processes Tailoring guidelines Process database Related documents
30
SEI Capability Maturity Model
Result
Level Characteristic
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 managementtracking of measured Quantitative process managementsoftware process
Management oversightand tracking project;stable planning andproduct baselines
Key Process Areas
Ad hoc(success depends on heroes)
"People"
Software configuration management Software quality assurance Software subcontract management Software project tracking & oversightSoftware project planningRequirements management
Peer reviews Intergroup coordinationSoftware product engineering Integrated software managementTraining programOrganization process definitionOrganization process focus
RiskRisk
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 softwareengineering 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
KeyProcess Areas
Goals
Common Features
KeyPractices
2 3 4 5
RM PP PT SM CMQA
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
Maturity Level 1994 1995 1996 1997 1998 1999 2000
1- Initial 71% 67% 64% 58% 52% 43% 35%
2- Repeatable 19% 20% 21% 25% 28% 34% 38%
3- Defined 10% 11% 13% 14% 17% 17% 19%
4- Managed 0% 1% 2% 2% 3% 4% 6%
5- Optimizing 1% 0% 0% 0% 1% 1% 3%
Organizationsreporting to SEI
156 353 458 541 621 734 901
Source: http://www.sei.cmu.edu/sema/profile.html
0
200
400
600
800
1000
Org
an
iza
tio
ns
1994 1995 1996 1997 1998 1999 2000
5-Optimizing
4-Managed
3-Defined
2-Repeatable
1-Initial
36
Know Thy Competition
Some Organizations at CMM Level 4 or 5
BFL Software Boeing CG-Smith SoftwareCiticorp Overseas Cognizant Tech CSC Defense GroupCSC Civil Group DCM Tech DSQ TechFuture Software HCL Perot Systems HoneywellHughes IBM Global Services Int. ComputersLitton PRC Lockheed Martin MotorolaNCR Network Systems Northrop GrummanOracle Raytheon Satyam ComputerSiemens Info Systems Silverline Tech Tata ConsultancyTelcordia Tech United Space Alliance USAF Hill AFBUSAF Tinker AFB USA CECOM USN FMSOUSN NAWC China Lake Wipro GE Med Systems
37
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-iCMM FAA’s integrated CMM (SW-CMM, SE-CMM, SA-CMM)
CMMI CMM 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
– 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.v1.1.html
• SEI CMM Level 5: For the Right Reasons. George Yamamura and Gary Wigle, Boeing Defense & Space Group. CrossTalk, August 1997.
– http://www.stsc.hill.af.mil/CrossTalk/1997/aug/seicmm5.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
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