cmmi v1.1 tutorial
TRANSCRIPT
January 2003
CMMIÂŽ
CMMIÂŽ V1.1 Tutorial
Sponsored by the U.S. Department of DefenseŠ 2003 by Carnegie Mellon University
SM CMM Integration and SCAMPI are service marks of Carnegie Mellon University.ÂŽ Capability Maturity Model, CMMI, and CMM are registered with the U.S. Patent and Trademark Office.
Pittsburgh, PA 15213-3890
(Excerpted and augmented by R. Bubaczfor use in SE 450 Software Process & Product Metrics Course)
2January 2003
CMMIÂŽ
Everyone realizes the importance of having a motivated, quality work force but...
⢠...even our finest people canât perform at their best when the process is not understood or operating âat its best.â
PEOPLE
PROCESSTECHNOLOGY
Quality Leverage Points
Major determinants of product cost, schedule, and quality
3January 2003
CMMIÂŽ
Why Process Improvement?⢠Good software engineering practice increases the chance of
delivering quality software products on time and on budget
⢠So, improving the software process improves the software product and the business
⢠Stable, repeatable software processes reduce the variability andrisk in development
4January 2003
CMMIÂŽUnderlying Premise of Process
Improvement
âThe quality of a product is largely determined by the quality of the process that is used to develop and maintain it.â
Based on TQM principles as taught by Shewhart, Juran, Deming and Humphrey.
5January 2003
CMMIÂŽImmature Versus Mature
Organizations
⢠Software Process, though specified, is not followed/enforced
⢠Reactionary (Fire-Fighting)
⢠Software processes are generally improvised by practitioners and managers during the course of the project.
⢠Schedules and Budgets keep constantly changing
⢠No objective basis for judging product quality or for solving product or process problems
⢠Software process is accurately communicated to staff and work activities are carried out according to the planned process.
⢠Process improvements are developed through controlled pilot-tests and/or benefit analysis
⢠Schedules and Budgets are based on historical performance.
⢠There is an objective, quantitative basis for judging product quality and analyzing problems with the product and process
Immature Mature
6January 2003
CMMIÂŽ
The Five Levels of Software Process Maturity
⢠A maturity level is a well-defined evolutionary plateau towards achieving a mature process
⢠Each level has a set of goals
⢠Achieving each levelâEstablishes a different
component in the software process.
â Increases the process capability of the organization.
(Staged Representation)
7January 2003
CMMIÂŽ
Process Capability & Performance
Prediction
⢠As Maturity increases, the difference between targeted results and actual results decreases
⢠Higher maturity a better way to run a business
Improved productivity
Reduced variability
8January 2003
CMMIÂŽ
Key Process Areas by Maturity Level
⢠Achieving each levelâEstablishes a
different component in the software process
â Increases the process capability of the organization
9January 2003
CMMIÂŽ
Requirements ManagementRequirements DevelopmentTechnical SolutionProduct IntegrationVerificationValidation
Engineering
ProjectManagement
Project PlanningProject Monitoring and ControlSupplier Agreement ManagementIntegrated Project Management (IPPD)Integrated Supplier Management (SS)Integrated Teaming (IPPD)Risk ManagementQuantitative Project Management
Organizational Process FocusOrganizational Process DefinitionOrganizational TrainingOrganizational Process PerformanceOrganizational Innovation and Deployment
ProcessManagement
Configuration ManagementProcess and Product Quality AssuranceMeasurement and AnalysisCausal Analysis and ResolutionDecision Analysis and ResolutionOrganizational Environment for Integration (IPPD)
Support
Category
Continuous Organization of Process Areas
Process Area
10January 2003
CMMIÂŽCMMI Structure
One Model, Two Representations
Maturity Level 5OID, CAR
Maturity Level 4OPP, QPM
Maturity Level 3REQD, TS, PI, VER,VAL, OPF, OPD, OT,IPM, RSKM, DAR
OverviewIntroductionStructure of the ModelModel TerminologyMaturity Levels, Common Features, and Generic PracticesUnderstanding the ModelUsing the Model
Maturity Level 2REQM, PP, PMC,SAM, MA, PPQA, CM
Appendixes
EngineeringREQM, REQD, TS,PI, VER, VAL
Project ManagementPP, PMC, SAMIPM, RSKM, QPM
Process ManagementOPF, OPD, OT,OPP, OID
Process ManagementPAs- Goals- Practices
SupportCM, PPQA, MA, CAR, DAR
Appendixes
CMMI-SE/SWStaged
OverviewIntroductionStructure of the ModelModel TerminologyCapability Levels and Generic Model ComponentsUnderstanding the ModelUsing the Model
CMMI-SE/SWContinuous
11January 2003
CMMIÂŽThe Maturity Levels (Staged
Representation)⢠Level 1 â Initial Level
â Ad Hoc processes, ineffective planning and reaction-driven systemsâ Crisis â abandon planned procedures & revert to coding and testingâ Schedules, Budget, Functionality, Product Quality: Unpredictableâ Software Process Capability: Unpredictable
⢠Level 2 â Repeatable Levelâ Basic Software Management controlsâ Planning/Managing new projects is based on successes with similar projectsâ Realistic project commitments based on empirical knowledgeâ Project managers track software costs, schedules and functionalityâ Projects standards are defined and followedâ Software Process Capability: Disciplined
⢠Level 3 â Defined Levelâ Standard Process for developing and maintaining software is documentedâ Organization-wide training program: to ensure that staff and managers have knowledge and
skills to fulfill their assigned rolesâ Projects tailor the Standard Process to develop their own well-defined process for their unique
project requirementsâ Schedules, Budget, Functionality, Product Quality: Under Control and Trackedâ Software Process Capability: Standard and Consistent
12January 2003
CMMIÂŽ
⢠Level 4 â Managed Levelâ Quantitative quality goals for products and processesâ Organizational Measurement Program for important software process activitiesâ Variation in process performance is controlled to be within acceptable range â Software Process Capability: Predictable
⢠Level 5 â Optimizing Levelâ Focus on Continuous Process Improvementâ Identify weakness and strengthen the process proactivelyâ Perform cost benefit analyses of new technologies and proposed changes to the
organizationâs software processâ Analyze defects to determine their causes â evaluate the software process accordinglyâ Software Process Capability: Continuous Improving
The Maturity Levels (Staged) (continued)
13January 2003
CMMIÂŽ
Staged
ML 1
ML2ML3
ML4
ML5
. . .for an established set of process areas across anorganization
Continuous
. . .for a single process areaor a set of process areas
PA PA
Proc
ess
Are
a C
apab
ility
0
1 2
3
4
5
PA
Comparing Model Representations
14January 2003
CMMIÂŽ
Remember
â˘A model is not a process.
â˘The model shows what to do, NOT how to do it or who does it.
15January 2003
CMMIÂŽCMMI in a Nutshell
⢠A CMMI model provides a structured view of process improvement across an organization
⢠CMMI can helpâset process improvement goals and
prioritiesâprovide guidance for quality processes âprovide a yardstick for appraising current
practices
16January 2003
CMMIÂŽ
The Bottom Line 2
⢠Improvement means different things to different organizations:
âWhat are your business goals?
âHow do you measure progress?
⢠Improvement is a long-term, strategic effort:
âWhat is the expected impact on the bottom line?
âHow will impact be measured?
17January 2003
CMMIÂŽCategories of Process
Improvement Benefits
⢠Process improvement benefits fall into one of eight general categories:âimproved schedule and budget predictabilityâimproved cycle timeâincreased productivityâimproved quality (as measured by defects)âincreased customer satisfactionâimproved employee moraleâincreased return on investmentâdecreased cost of quality
18January 2003
CMMIÂŽ
Results: Boeing Effort Estimation
.
0 %
140%
-140%
....
.
..
. ... .
.
. .. . . .
.. . .
. .
.
.. . . .. .. . . . . .... . . .. .
.. .
. ...
..
. .. .. ...... . .. . ... . .. . .. ..
Without Historical Data With Historical DataVariance between + 20% to - 145% Variance between - 20% to + 20%
(Mostly Level 1 & 2) (Level 3)
Ove
r/Und
er P
erce
ntag
e
.
(Based on 120 projects in Boeing Information Systems)
.. . .
.
.. .
...
. .. .
..
. .
..
.. .. . .. . . . . .. . . . . .. .
... . .. . . . . . .. . . .. . . . .
. . . . .. . . . .. . . . . .. . . . .. . . . . .
. . . . . .. . . . .. . .
. . . . . . . .
. . . . . . . . .
. . . . . .. . . . . .
. . . . . .
Reference: John D. Vu. âSoftware Process Improvement Journey:From Level 1 to Level 5.â7th SEPG Conference, San Jose, March 1997.
Improved Schedule and Budget Predictability
19January 2003
CMMIÂŽ
Project Cycle Times
0250500750
1991
1992
1993
1994
1995
1996
Year
Avg
Wor
king
D
ays Req Def
Implement
Source: Software Engineering Div., Hill AFB, Published in Crosstalk May 1999
Improved Cycle Time
20January 2003
CMMIÂŽ
Source: Software Engineering Div., Hill AFB, Published in Crosstalk May 1999
Man-hours per LOC
00.20.40.60.8
11.2
A B C D E
Release
Nor
mal
ized
Man
-hou
rs
Increased Productivity
21January 2003
CMMIÂŽIncreased Productivity and
Quality
â˘
22January 2003
CMMIÂŽ
Process Areas
â˘Process Areas (PAs) are a cluster of related practices.
â˘They are the major building blocks in establishing process capability.
â˘Example PA: âRequirements Managementâ
23January 2003
CMMIÂŽ
The Capability Dimension
⢠The values on this axis describe how well you perform a process (called Capability Levels).
Cap
abili
ty
Process
ProcessArea 1
ProcessArea n
ProcessArea 2
ProcessArea 3
Process performed well andcontinuously improved
Process not performed
24January 2003
CMMIÂŽ
The Capability Levels
5 Optimizing
4 Quantitatively Managed
3 Defined
2 Managed
1 Performed
0 Incomplete
Capability levels are cumulative â a higher capability level includes the attributes of the lower levels
25January 2003
CMMIÂŽAn Example Process Area
Capability Profile
P r o c e s s A r e aRM PP PMC etc
543210
C a
p a
b i
l i t
y
26January 2003
CMMIÂŽ
Requirements ManagementRequirements DevelopmentTechnical SolutionProduct IntegrationVerificationValidation
Engineering
ProjectManagement
Project PlanningProject Monitoring and ControlSupplier Agreement ManagementIntegrated Project Management (IPPD)Integrated Supplier Management (SS)Integrated Teaming (IPPD)Risk ManagementQuantitative Project Management
Organizational Process FocusOrganizational Process DefinitionOrganizational TrainingOrganizational Process PerformanceOrganizational Innovation and Deployment
ProcessManagement
Configuration ManagementProcess and Product Quality AssuranceMeasurement and AnalysisCausal Analysis and ResolutionDecision Analysis and ResolutionOrganizational Environment for Integration (IPPD)
Support
Category
Alignment of Metrics & Quality Practices with Process Areas
Process Area Metrics/Quality Practices
Project Mgmt MetricsActivity MetricsBasic Quality Tools
Requirements VolatilityDefect Removal MetricsReliability EngineeringDefect Prevention TechniquesBasic Quality Tools
Maintenance MetricsBasic Quality ToolsGQMMeasurement FundamentalsDefect Prevention Techniques
In-Process MetricsProject Mgmt MetricsBasic Quality Tools
27January 2003
CMMIÂŽ
Summary
⢠CMMI models were developed with broad participation and review.
⢠Process Areas identify âwhat you do.â⢠Capability Levels identify âhow well you do it.â⢠The CMMI model should be applied using intelligence,
common sense, and professional judgment. ⢠Metrics and quality practices are an integral part of
achieving process maturity.