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.