View
231
Download
1
Category
Tags:
Preview:
Citation preview
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 and risk 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
Continuous Organization of Process Areas
Category Process Area
10January 2003
CMMI®CMMI Structure
One Model, Two Representations
Maturity Level 5 OID, CAR
Maturity Level 4 OPP, QPM
Maturity Level 3 REQD, TS, PI, VER, VAL, OPF, OPD, OT, IPM, RSKM, DAR
Overview Introduction Structure of the Model Model Terminology Maturity Levels, Common Features, and Generic Practices Understanding the Model Using the Model
Maturity Level 2 REQM, PP, PMC, SAM, MA, PPQA, CM
Appendixes
Engineering REQM, REQD, TS, PI, VER, VAL
Project Management PP, PMC, SAM IPM, RSKM, QPM
Process Management OPF, OPD, OT, OPP, OID
Process Management PAs - Goals - Practices
Support CM, PPQA, MA, CAR, DAR
Appendixes
CMMI-SE/SWStaged
Overview Introduction Structure of the Model Model Terminology Capability Levels and Generic Model Components Understanding the Model Using 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
ML2
ML3
ML4
ML5
. . .for an established set of process areas across anorganization
Continuous
. . .for a single process areaor a set of process areas
PA PA
Pro
cess
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/U
nd
er P
erce
nta
ge
.
(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
0
250
500
750
1991
1992
1993
1994
1995
1996
Year
Avg
Wo
rkin
g
Day
s 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
0
0.2
0.4
0.6
0.8
1
1.2
A B C D E
Release
No
rmal
ized
Man
-ho
urs
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
abil
ity
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 a
RM PP PMC etc
5
4
3
2
1
0
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
Alignment of Metrics & Quality Practices with Process Areas
Category 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.
Recommended