Upload
others
View
13
Download
0
Embed Size (px)
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 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.