Cmmi V1

Pittsburgh, PA 15213-3890
CMMI V1.1 Tutorial
Mike Phillips, CMMI Program Manager
Sponsored by the U.S. Department of Defense

© 2003 by Carnegie Mellon University
CMMI Tutorial Apr 22, 2003

Agenda
• Why focus on Process?
• Background – Why use a Model?
• CMMI Structure
• Comparisons with SW-CMM v1.1, SE-CMM, and
EIA/IS 731_
• Process Areas Overview
• Appraisal Methodology
• Training

2
Quality Leverage Points
Everyone realizes the importance of

having a motivated, quality work force
but...
PEOPLE
• ...even our finest people

TECHNOLOGY
can’t perform at their best
PROCESS when the process is not
understood or operating
“at its best.”
Major determinants of product

cost, schedule, and quality
3
What Is Process?
• How do you define process?

4
General Definition of Process
• How do you define process?
• A process is a set of practices performed to achieve
a given purpose; it may include tools, methods,

materials, and/or people.
• While process is often described as a leg of the

process-people-technology triad, it may also be
considered the “glue” that unifies the other aspects.
5
Why Focus on Process?
• Process provides a constructive, high-leverage focus...

–as opposed to a focus on people
»Your work force, on the average, is as “good”
as it is trained to be.
»Working harder is not the answer.
»Working smarter, through process, is the
answer.
–as opposed to a focus on technology
»Technology applied without a suitable roadmap
will not result in significant payoff.
»Technology provides the most benefit in the
context of an appropriate process roadmap.

6
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.

7
Early Process Improvement
• The theories of process management are a synthesis of
the concepts of Deming, Crosby, Juran, and others.
• Over the past 30 years, these theories have been used to

address problems common to many organizations.
• Solutions have been discovered, but a gap existed

between the state of the practice and the state of the art.
• Many of these concepts have been used to build process-

improvement models.

8
What Is a Process Model?
• A model is a structured collection of elements that

describe characteristics of effective processes.
• Processes included are those proven by experience

to be effective.

9
How Is a Model Used?
A model is used
–to help set process improvement objectives and

priorities, improve processes, and provide
guidance for ensuring stable, capable, and mature
processes
–as a guide for improvement of organizational

processes

10
Why Is a Model Important?
• A model provides
–a place to start
–the benefit of a community’s prior experiences
–a common language and a shared vision
–a framework for prioritizing actions

11
Models
“All models are wrong, but some

are useful.”
– George Box
• Simplified approximations of reality that provide insight.

12
What Model do I use?
• Historically: Depends on the discipline that you want

to model.
–Software Engineering
–Systems Engineering
–Software Acquisition
–Systems Security
–etc.

13
What is a CMM?
• Capability Maturity Model:
A reference model of mature practices in a specified
discipline, used to assess a group’s capability to perform
that discipline
• CMMs differ by
– Discipline (software, systems, acquisition, etc.)
– Structure (staged versus continuous)
– How Maturity is Defined (process improvement path)
– How Capability is Defined (institutionalization)
• “Capability Maturity Model®” and CMM® are used by the
Software Engineering Institute (SEI) to denote a particular
class of maturity models
Capability Maturity Model®, CMM®, CMM Integration, and CMMI are service marks and registered trademarks of
Carnegie Mellon University

14
Commonly Used CMMs
Software CMM staged software
development
System Engineering CMM continuous system
engineering
System Engineering Capability Model continuous system
engineering
Software Acquisition CMM staged software
acquisition
System Security Engineering CMM continuous security
engineering
Personal Software Process staged individual
software development
FAA-iCMM continuous software
engineering, systems
engineering, and
acquisition
IPD-CMM hybrid integrated
CMMI Tutorial Apr 22, 2003 product development 15
The Problem
• Systems and software
disciplines have traditionally not
been well integrated
Systems Software
• The importance of software in
systems has increased
dramatically
– Example: % of requirements
allocated to software: *
» B-2 -- 65%
» F-22 -- 80%
• The DOD has emphasized the
need to make the
systems/software interface more
seamless
* Source: Standish Group Chaos Report

16
So Many Models, So Little Time
ZZZ • Different structures,

Software CMM formats, terms, ways
EIA 731
CMM of measuring
maturity
• Causes confusion,
Systems especially when
Engr using more than one
CMM model
People
CMM • Hard to integrate
IPD Software them in a combined
CMM Acq improvement
CMM program
• Hard to use multiple
FAA Systems models in supplier
iCMM Security selection
Engr CMM
17
CMMI to the Rescue!
• Integrates systems and software disciplines into one

process improvement framework.
• Provides a framework for introducing new disciplines

as needs arise.

18
Bridging the Divide
• Systems engineering and

software engineering
processes are integrated.
• Integrates systems and
software disciplines into
one process improvement
framework.
• Provides a framework for
introducing new disciplines
as needs arise.

19
But We Don’t Do That...
• Some organizations see themselves as performing just one
discipline
– Software
– Systems
– Acquisition
• But…
– Software always must be part of some kind of system
– Systems that don’t have software are rare
– Acquisition can involve both
• Communication and cooperation with other disciplines, even if
they are external to our organization is vital

20
The CMMI Project
• DoD sponsored collaboration
between industry, Government, SEI
• Over 100 people involved
• U.S. Army, Navy, Air Force • KPMG
• Federal Aviation Administration • Lockheed Martin
• National Security Agency • Motorola
• Software Engineering Institute • Northrop Grumman
• ADP, Inc. • Pacific Bell
• AT&T Labs • Q-Labs
• BAE • Raytheon
• Boeing • Reuters
• Computer Sciences Corporation • Rockwell Collins
• EER Systems • SAIC
• Ericsson Canada • Software Productivity Consortium
• Ernst and Young • Sverdrup Corporation
• General Dynamics • TeraQuest
• Harris Corporation • Thomson CSF
• Honeywell • TRW
21
CMMI Models
Source Models SE/ SW /SW

CMMI CMMISE
• Capability Maturity
Staged tion ous
Continu tion
Model for Software V2, enta Represe
nta
Repres
draft C (SWCMM V2C)
• EIA Interim Standard
731, System Engineering
Capability Model (SECM) • Combined System Engineering /
Software Engineering model
• Integrated Product
Development Capability • Can be applied to:
Maturity Model, draft – Just the software engineering
V0.98 (IPDCMM) projects in an organization
– Just the system engineering
projects in an organization
– Both
– IPPD can be used in either/both
22
Comparing
Model Representations Staged
ML5
Continuous ML4
5
Process Area
ML3
Capability
4
ML2
3
ML 1
1 2
. . .for an established
set of process areas across an
0
organization
PA PA PA
. . .for a single process area
or a set of process areas
23
Relating Process Area Capability
and Organizational Maturity 1
• Process area capability and organizational

maturity are similar concepts.
• The difference between them is that process area

capability deals with a set of processes relating to
a single process area or specific practice, while
organizational maturity pertains to a set of
process areas across an organization.

24
Relating Process Area Capability
and Organizational Maturity 2
• Although the comparison of ratings and levels is

an advanced topic we don’t address in this
tutorial, in general terms, if a set of organizational
processes have been appraised at a particular
maturity level, the appraised processes may
demonstrate a comparable level of process area
capability.

25
Remember
•A model is not a process.
•The model shows what to do, NOT how to do it or

who does it.

26
Why Do We Have
Two Representations?
• Source Model Heritage
–Software CMM--Staged
–SECM--Continuous
–IPD CMM--Hybrid
• Proponents for each type of representation were part
of CMMI product development team.
• Selecting a single representation approach became
“too hard”.
• A compromise was made to initially support two
representations of the model with equivalent content.

27
Advantages of the Staged
Representation
• Provides a roadmap for implementing:

–groups of process areas
–sequencing of implementation
• Familiar structure for those transitioning from the

SW-CMM

28
Advantages of the Continuous
Representation
• Provides maximum flexibility for focusing on specific

process areas according to business goals and
objectives.
• Familiar structure for those transitioning from the

systems engineering community.

29
CMMI Product Suite
• Training
• Models
– Model
– Disciplines » Introduction to CMMI
» Systems Engineering SE » Intermediate Concepts
» Software Engineering SW
» Integrated Product and – Instructor Training
Process Development – Lead Appraiser
(IPPD) • Appraisal methods
» Supplier Sourcing (SS)
– Appraisal Requirements
– Representations for CMMI (ARC)
» Staged
– SCAMPI Method Description
» Continuous
Document (MDD)

30
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

31
The Bottom Line 1
• Process improvement
should be done
to help the business—
not for its
own sake.
“In God we trust,

all others bring data.”
CMMI Tutorial Apr 22, 2003 - W. Edwards Deming32
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?

33
Categories of Process
Improvement Benefits
• Process improvement benefits fall into one of seven

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

34
Improved Schedule and
Budget Predictability
140%
Over/Under Percentage
Results: Boeing Effort

Estimation
. .
... ..........................
... .... .. .... .
.
0% .
. . .. ... . . .. .. . ..............
.
. . . ... .. .. ... . . ....
.. .. .. .... .
. . ..
. .. . ..
. ... . .. .. .. . . .. .
..
. . .... . .. . . . .
.. . . .. ..... .... .
. . .. .. .... .. . . . .
. . . . ..
-140%
Without Historical Data With Historical Data
Variance between + 20% to - 145% Variance between - 20% to + 20%
(Mostly Level 1 & 2) (Level 3)
(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.
35
Improved Cycle Time
Project Cycle Times

Avg Working
750
500 Req Def
Days
250 Implement
0
91
92
93
94
95
96
19
19
19
19
19
19 Year
Source: Software Engineering Div., Hill AFB, Published in Crosstalk May 1999
36
Increased Productivity
Man-hours per LOC
1.2
Normalized Man-hours
1
0.8
0.6
0.4
0.2
0
A B C D E
Release
Source: Software Engineering Div., Hill AFB, Published in Crosstalk May 1999
37
Increased Productivity and
Quality

38
Topics
• The structure of the CMMI documents

• The structure of the CMMI Continuous representation
• The structure of the CMMI Staged representation
• Summary

39
Organization of
Continuous Model -1
• Six chapters provide an overview

–The Introduction
–Structure of the Model
–Model Terminology
–Capability Level and Generic Model components
–Understanding the Model
–Using the Model

40
Organization of
Continuous Model -2
• Process areas
»Process management
»Project Management
»Engineering
»Support
• Appendixes
»References
»Acronyms
»Glossary
»Required and expected Model Elements
»CMMI Project Participants
»Equivalent Staging

41
Organization of
Staged Model -1
• Six chapters provide an overview

–The Introduction
–Structure of the Model
–Model Terminology
–Maturity Levels, Common Features, and Generic
Practices
–Understanding the Model
–Using the Model

42
Organization of
Staged Model -2
• Process areas
»Maturity Level: 2 Managed
»Maturity Level: 3 Defined
»Maturity Level: 4 Quantitatively Managed
»Maturity Level: 5 Optimizing
• Appendixes
»References
»Acronyms
»Glossary
»Required and expected Model Elements
»CMMI Project Participants

43
Model Components
• Process Areas
–Specific Goals
–Specific Practices
–Generic Goals
–Generic Practices
»Typical Work Products
»Sub-practices
»Notes
»Discipline Amplifications
»Generic Practice Elaborations
»References

44
CMMI Structure
One Model, Two Representations
Appendixes
Appendixes
Support
Maturity Level 5 CM, PPQA, MA,
OID, CAR CAR, DAR
Maturity Level 4 Engineering
OPP, QPM REQM, REQD, TS,
PI, VER, VAL
Maturity Level 3
REQD, TS, PI, VER, Project Management
VAL, OPF, OPD, OT, PP, PMC, SAM
IPM, RSKM, DAR IPM, RSKM, QPM
Maturity Level 2
REQM, PP, PMC, Process Management
SAM, MA, PPQA, CM OPF, OPD, OT,
OPP, OID
Overview
Introduction Overview
Process Management
Introduction
Structure of the Model
PAs
Structure of the Model
Model Terminology - Goals
Maturity Levels, Common Features, and Generic Practices Model Terminology
- Practices
Understanding the Model Capability Levels and Generic Model Components
Using the Model Understanding the Model
Using the Model
CMMI-SE/SW CMMI-SE/SW
Staged Continuous
45
Topics
• Structure of the CMMI documents

• The structure of the CMMI continuous representation
• The structure of the CMMI staged representation
• Summary

46
Process Area Capability Profile
A process area capability profile may be represented by

a set of points in two dimensions.
– the process dimension
» “What” you do
– the capability dimension
» “How well” you do it
(How well)
Capability
Process Area (What you do)

47
The Process Dimension
• The values on this axis describe what processes
(described within Process Areas) you perform.
Capability
Process Process Process Process

Area 1 Area 2 Area 3 Area n
Process
48
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”

49
Continuous
Organization of Process Areas
Category Process Area
Project Planning
Project Project Monitoring and Control
Management Supplier Agreement Management
Integrated Project Management(IPPD)
Integrated Supplier Management (SS)
Integrated Teaming (IPPD)
Risk Management
Quantitative Project Management
Support Configuration Management
Process and Product Quality Assurance
Measurement and Analysis
Causal Analysis and Resolution
Decision Analysis and Resolution
Organizational Environment for Integration (IPPD)
Engineering Requirements Management

Requirements Development
Technical Solution
Product Integration
Verification
Validation
Process Organizational Process Focus

Management Organizational Process Definition
Organizational Training
Organizational Process Performance
Organizational Innovation and Deployment 50
Life Cycle Relationships
Mission Area Planning Budgeting Priority Requirements Definition
Directives, Constraints,
Decision Analysis and Resolution Requirements Development
Mission Shortfalls
Contracting Activity Planning

Supplier Agreement Project
Management Planning
Concurrent
Product Control Front-End
Integrated Project
Management
Requirements Activities
Management Technical
Integrated Teaming Solution
Configuration
Integrated Supplier
Management
Management
Risk Management Quality Assurance Product
Project Monitoring Integration
and Control Causal Analysis
and Resolution Technical Execution
Program Management
Assessment & Certification

Product
Deficiencies Product Measurement
Validation s
Verification and Analysis
Outcome & Feedback
System Product Deliveries
Organizational Process Management
Process Process Innovation and Environment Process Quantitative

Focus Definition Training for Performance
Deployment Mgmt
Integration
Process Maturation

51
The Capability Dimension -1
• The values on this axis describe how well you

perform a process (called Capability Levels).
Capability
Process not performed

Process 52
The Capability Dimension -2
• The values on this axis describe how well you

perform a process (called Capability Levels).
Process performed well and

continuously improved
Capability
Process not performed

Process 53
Capability Levels
• A capability level is a well-defined evolutionary

plateau describing the capability of a process
area.
• There are six capability levels.
• Each level is a layer in the foundation for
continuous process improvement.
• Thus, capability levels are cumulative, i.e., a
higher capability level includes the attributes of
the lower levels.

54
The Capability Levels
5 Optimizing
4 Quantitatively Managed
3 Defined
2 Managed
1 Performed
0 Incomplete

55
Capability Levels
are Cumulative
• Because capability levels build upon one another,
there can be no gaps.

56
Representing
Process Capability
• The capability of a implemented process can be

represented by a bar.
This point
3 represents
Capability
a higher level
2 of capability
than this point
1 in a specific
process area
0
Process Area n
Process

57
An Example Process Area
Capability Profile
5
Capability
4
3
2
1
0
REQM PP PMC etc
Process Area

58
Realizing These Concepts in
the CMMI Continuous Model
• Goals and Practices are the model elements used to

realize the values on both the capability and process
dimensions.
–Goal
»A high level statement of the outcome to be achieved
by effective implementation of a group of practices.
–Practice
»A description of an action that is necessary
to enact a key element of a process area.

59
There Are Two Types
of Goals and Practices
• Specific Goals and Specific Practices

– realize the process dimension
– therefore, they apply to a particular Process
Area
• Generic Goals and Generic Practices

– realize the capability dimension
– therefore, they apply across all Process Areas

60
Example: Specific Goal and
Specific Practice
• Specific Goal (from Requirements Management

PA)
–Requirements are managed and inconsistencies
with project plans and work products are
identified.
• Specific Practice (from Requirements
Management PA)
–Maintain bidirectional traceability among the
requirements and the project plans and work
products.

61
Example: Generic Goal and
Generic Practice
• Generic Goal (from Capability Level 1)

– The process supports and enables achievement
of the specific goals of the process area by
transforming identifiable input work products to
produce identifiable output work products.
• Generic Practice (from Capability Level 1)

– Perform the basic activities of the process area
to develop work products and provide services
to achieve the specific goals of the process area.

62
Structure of the CMMI
Continuous Representation
Generic
Goals
&
Generic
Practices
Generic
Goals
&
Generic
Practices
Specific Specific
Goals Goals
& &
Practices Practices
63
Critical Distinctions
• performed vs. managed
•--the extent to which the process is planned; performance is managed

against the plan; corrective actions are taken when needed
•managed vs. defined
•--the scope of application of the process descriptions, standards, and

procedures (i.e., project vs. organization)
•defined vs. quantitatively managed
•--the predictability of process performance
•quantitatively managed vs. optimizing
•--the process is continuously improved by addressing common causes of

process variation
64
Improving a Process Area
GP1.1 through GP5.2 CL5 Defect prevention, proactive improvement,
CL1+CL2*+CL3* SPs Optimizing innovative technology insertion and deployment
GP1.1 through GP4.2 CL4 Measure process performance,

CL1+CL2*+CL3* SPs Quantitatively stabilize process, control charts,
Managed deal with causes of special variations
GP1.1 through GP3.2 Project’s process is tailored from organization’s
CL3
CL1+CL2*+CL3* SPs standard processes, understand process qualitatively,
Defined
process contributes to the organizations assets
GP1.1 through GP2.10 Adhere to policy, follow documented plans and processes,
CL2 apply adequate resources, assign responsibility and
CL1 + CL2* SPs
Managed authority, train people, apply CM, monitor, control, and
evaluate process, identify and involve stakeholders,
review with management
GP1.1 CL1
CL1 (base) SPs Performed Perform the work
No GPs or SPs exist CL0 Not performed, incomplete
* Advanced practices exist only in the Engineering PAs.
65
REQM - Capability Levels 1
&2
Requirements Management
Specific practices (CL1 “base”) Generic practices (CL1)
SP1.11: Obtain an Understanding of GP1.1: Perform Base Practices
Requirements
SP1.31: Manage Requirements Changes
SP1.51: Identify Inconsistencies Between
Project Work and Requirements
Specific practices (CL2 “advanced”) Generic practices (CL2)
SP1.22: Obtain Commitment to Requirements GP2.1: Establish an Organizational Policy
SP1.42: Maintain Bidirectional Traceability of GP2.2: Plan the Process
Requirements GP2.3: Provide Resources
GP2.4: Assign Responsibility
GP2.5: Train People
GP2.6: Manage Configurations
GP2.7: Identify and Involve Relevant Stakeholders
GP2.8: Monitor and Control the Process
GP2.9: Objectively Evaluate Adherence
GP2.10: Review Status with Higher Level Management

66
REQM - Capability Level 3
Specific practices (CL1 & CL2) Generic practices (CL1 & CL2)
SP1.11: Obtain an Understanding of GP1.1: Perform Base Practices
Requirements GP2.1: Establish an Organizational Policy
SP1.22: Obtain Commitment to Requirements GP2.2: Plan the Process
SP1.31: Manage Requirements Changes GP2.3: Provide Resources
SP1.42: Maintain Bidirectional Traceability of GP2.4: Assign Responsibility
Requirements GP2.5: Train People
SP1.51: Identify Inconsistencies Between GP2.6: Manage Configurations
Project Work and Requirements GP2.7: Identify and Involve Relevant Stakeholders
GP2.8: Monitor and Control the Process
GP2.9: Objectively Evaluate Adherence
GP2.10: Review Status w/Higher Level Management
Specific practices (CL3) Generic practices (CL3)
All the CL1 & CL2 Specific Practices All the CL1 & CL2 Generic Practices plus(+):
GP3.1: Establish a Defined Process
GP3.2: Collect Improvement Information

67
REQM - Capability Levels 4
&5
All the CL1 & CL2 Specific Practices All the CL1 & CL2 & CL3 Generic Practices plus(+):
GP4.1: Establish Quantitative Objectives for the Process
GP4.2: Stabilize Subprocess Performance
All the CL1 & CL2 Specific Practices All the CL1 & CL2 & CL3 & CL4 Generic Practices plus(+):
GP5.1: Ensure Continuous Process Improvement
GP5.2: Correct Root Causes of Problems

68
Summary
• CMMI models were developed with broad

participation and review.
• Process Areas identify “what you do.”
• Capability Levels identify “how well you do it.”

69
Topics
• Structure of the CMMI documents

• The structure of the CMMI Continuous representation
document
• The Structure of the CMMI Staged representation
• Summary

70
Maturity Levels
• A maturity level is a well-defined evolutionary

plateau on the path to becoming a mature
organization.
• There are five maturity levels.
• Each level is a layer in the foundation for

continuous process improvement.

71
The Maturity Levels
Optimizing
5 Focus on process
improvement
Quantitatively
4 Process measured Managed
and controlled
Defined
3 Process characterized
for the organization
and is proactive
Managed
2 Process characterized for
projects and is often
reactive
Performed
1 Process unpredictable,
poorly controlled and
reactive

72
Structure of the CMMI
Staged Representation
Maturity Level
Process Area Process Area Process Area
Generic Goals Specific Goals
Common
Features
Commitment Ability to Directing

Verification
to Perform Perform Implementation
Generic
Specific Practices
Practices
Commitment to Perform: creates policies and secures sponsorship for process improvement efforts
Ability to Perform: ensures that the project and/or organization has the resources it needs to pursue process improvement
Directing Implementation: collects, measures, and analyzes data related to processes
Verification: verifies that the projects and/or organization’s activities conform to requirements, processes, and procedures

73
Maturity Levels
Cannot Be Skipped
• A level provides a necessary foundation for
effective implementation of processes at the
next level.
– Higher level processes are easily sacrificed
without the discipline provided by lower
levels.
– The effect of innovation is obscured in a
noisy process.
• Higher maturity level processes may be

performed by organizations at lower maturity
levels, with risk of not being consistently
applied in a crisis.
74
Process Areas
•Process Areas (PAs) are clusters of related

practices performed collectively to achieve a set of
goals.
•They are the major building blocks in establishing
the process capability of an organization.
•Each process area has been defined to reside
at a given maturity level.

75
Process Areas by Maturity Level
Level Focus Process Areas
Continuous Organizational Innovation and Deployment
5 Optimizing process Causal Analysis and Resolution
improvement
4 Quantitatively Quantitative Organizational Process Performance

Managed management Quantitative Project Management
Technical Solution
Product Integration
Verification
Process Validation
3 Defined standardization Organizational Process Focus
Organizational Process Definition
Integrated Project Management
(SS) Integrated Supplier Management
Risk Management
(IPPD) Organizational Environment for Integration
(IPPD) Integrated Teaming
Basic Requirements Management
2 Managed project Project Planning
management Project Monitoring and Control
Supplier Agreement Management
Configuration Management
76
1 Performed
Example: Specific Goal and
Specific Practice
• Specific Goal (from Requirements Management

PA)
–Requirements are managed and inconsistencies
with project plans and work products are
identified.
• Specific Practice (from Requirements
Management PA)
–Maintain bidirectional traceability among the
requirements and the project plans and work
products.

77
Example: Generic Goal and
Generic Practice
• Generic Goal (from Capability Level 1)

– The process supports and enables achievement
of the specific goals of the process area by
transforming identifiable input work products to
produce identifiable output work products.
• Generic Practice (from Capability Level 1)

– Perform the basic activities of the process area
to develop work products and provide services
to achieve the specific goals of the process area.

78
Common Features
Common features are a means of categorizing

Generic practices.
– Commitment to perform:
establishment of management policies
– Ability to perform:
establishment and maintenance of plans,
resources, assigned responsibility and
authority, and training
– Directing implementation:
measurement, control, and performance practices
– Verification:
ensure implementation and compliance
79
Another way to look at
Common Features -1
• Common feature categories are very similar across

process areas.
• They are referred to as Institutionalization Common

Features because they:
– ensure the process areas are effective,
repeatable and lasting
– provide needed infrastructure support

80
Common Feature Examples -1
from Requirements Management Process Area
•Commitment to perform:
–Establish and maintain an organizational
policy for planning and performing the
requirements management process.
•Ability to perform:
–Train the people performing or supporting
the requirements management process as
needed.

81
Common Feature Examples -2
from Requirements Management Process Area
• Directing implementation:
– Place designated work products of the
requirements management process under
appropriate levels of configuration
management.
• Verification:
– Review the activities, status, and results of
the requirements management process

with higher level management and resolve
issues.
82
Summary -1
• There is one CMMI Model with two representations,
Staged and Continuous.
• The material in both representations is the same just

organized differently.
• Each representation provides different ways of

implementing processes
• The CMMI model should be applied using intelligence,

common sense, and professional judgment.

83
Summary -2
• Continuous
–Flexible in its application so the organization can
choose which areas to emphasize.
–Provides equivalent staging to compare to staged
representation.
• Staged
–Structured for implementation based on proven
grouping and ordering of processes.

84
CMMI-SE/SW
Compared to SW-CMM v1.1

85
SW-CMM v1.1 vs. CMMI
Process Areas
Defect Prevention Causal Analysis and Resolution
LEVEL 5 Technology Change Mgmt Organizational Innovation & Deployment
OPTIMIZING Process Change Management
LEVEL 4 Quantitative Process Mgmt Organizational Process Performance

MANAGED Software Quality Mgmt Quantitative Project Management
Organization Process Focus Organization Process Focus
Organization Process Definition Organization Process Definition
Training Program Organizational Training
Integrated Software Mgmt Integrated Project Management
Risk Management
Software Product Engr Requirements Development
Technical Solution
Product Integration
Intergroup Coordination Verification
LEVEL 3 Peer Reviews Validation
DEFINED Decision Analysis and Resolution
Requirements Management Requirements Management
Software Project Planning Project Planning
Software Project Tracking & Oversight Project Monitoring and Control
Software Subcontract Mgmt Supplier Agreement Management
Software Quality Assurance Product & Process Quality Assurance
LEVEL 2 Software Configuration Mgmt Configuration Management
REPEATABLE Measurement and Analysis
86
CMMI Improvements
Over the CMM
• Emphasis on measurable improvements to achieve

business objectives.
• Process areas have been added to place more
emphasis on some important practices:
–Risk Management
–Measurement and Analysis
–Engineering Process Areas
–Decision Analysis

87
CMMI-SE/SW/IPPD
Compared to EIA/IS 731
(Systems Engineering
Capability Model)

88
Background
• Electronic Industries Alliance Interim

Standard (EIA/IS) 731, System Engineering
Capability Model (SECM), was created as a
merger of the SE-CMM and the INCOSE
Systems Engineering Capability Assessment
Model (SECAM)
• Used as a source model for CMMI

89
What is the Systems Engineering
Capability Model (SECM)?
• Describes the essential systems engineering and

management tasks that any organization must perform
• Road map for systems engineering & management

process improvement
• Systems engineering and management process

measurement tool

90
SECM Focus Areas
Environment
Plan & Monitor &
Organize Control
Integrate
Management Define & Disciplines
Improve SE
Process
Technical Define
Solution
Define Integrate
Manage SE Manage
Stkhldr & System
Support Risk
Sys Level
Environment Rqmnts Assess &
Select
Verify
Define System Manage
Manage
Competency Technical Configurations
Problem Validate
System
Manage Manage
Technology Data
Coordinate
with Ensure
Suppliers Quality

91
Comparison of Elements -1
SECM Technical Focus Areas CMMI Engineering PAs
1.1 Define Stakeholder & Requirements
Management
System Level Requirements
Requirements
1.2 Define Technical Development
Requirements
Technical Solution
1.3 Define Solution
1.4 Assess and Select Product Integration
Support
1.5 Integrate System Verification
1.6 Verify System
1.7 Validate System Validation

92
SECM Management Focus Areas CMMI Project Management
Process Areas
2.1 Plan and Organize Project Planning
2.2 Monitor & Control Project Monitor & Control
2.3 Integrate Disciplines Integrated Project Mgt
2.4 Coordinate w/ Supp. Supplier Agreement Mgt
2.5 Manage Risk Risk Management
2.6 Manage Data Quantitative Project Mgt
2.7 Manage Configurations Support Process Areas
2.8 Ensure Quality Configuration Mgt
Proc & Prod QA
1.4 Measurement & Analysis
Decision Analysis & 93
Resolution
CMMI Process Management
Process Areas
SECM Environment Focus Areas Organizational Process

Focus
3.1 Define & Improve
Process
Organizational
SE Process Definition
3.2 Manage Competency Organizational Training
3.3 Manage Technology
Process
Organizational
3.4 Manage SE Support Performance
Environment Innovation
Organizational
& Deployment

94
Comparison of
Generic Elements
SECM Capability Level 2 CMMI Capability Level 2

2.1 Establish org policy
2.1 Follow recorded &
approved plans & 2.2 Plan the process
processes 2.3 Provide resources
2.4 Assign responsibilities
2.5 Train people
2.6 Manage configurations
2.7 Identify & involve relevant
stakeholders
2.2 Verify compliance & 2.8 Monitor & control process
take action when 2.9 Objectively evaluate adherence
needed
2.10 Review status w/ higher-level
95
CMMI Tutorial Apr 22, 2003 mgmt
Comparison of
Generic Elements -3

3.1 Standardize & 3.1 Establish a
record a well-defined defined
proc process
3.2 Tailor the standard
proc using standard
guidelines
3.3 Implement &
improve the FA 3.2 Collect
activities improvement
3.4 Improve the information
standard process 96
Comparison of
Generic Elements -4
4.1 Collect & analyze 4.1 Establish

metrics quantitative
objectives for
the process
4.2 Take appropriate
action to align
performance & 4.2 Stabilize
expectations subprocess
performance
97
Comparison of
Generic Elements -5

5.1 Identify FA activities for
which it is appropriate to
5.1 Ensure
quantify process
repeatability
continuous
process
5.2 Establish quantitative improvement
goals for improving the
standard process
5.3 Improve the std proc
based on data & metrics 5.2 Correct root
5.4 Perform causal analysis causes of
& eliminate causes of problems
variation by changing the
standard process
98
Conclusions
•EIA/IS 731 users should be able to smoothly

transition to the CMMI-SE/SW model
–Continuous representation (+ “equivalent” staged
representation)
–Some lower-level differences
–Application of common SE/SW practices to
product development community

99
Overview of CMMISM
SE/SW/IPPD/SS Model
Process Areas

100
Continuous
Organization of PAs
Category Process Area
Project Planning
Project Project Monitoring and Control
Management Supplier Agreement Management
Integrated Project Management(IPPD)
Integrated Supplier Management (SS)
Integrated Teaming (IPPD)
Risk Management
Support Configuration Management
Organizational Environment for Integration (IPPD)
Engineering Requirements Management

Technical Solution
Product Integration
Verification
Validation
Process Organizational Process Focus
Management Organizational Process Definition
Organizational Innovation and Deployment 101
Project Management
Process Areas
• There are eight Project Management Process Areas.

–Project Planning
–Project Monitoring and Control
–Supplier Agreement Management
–Integrated Project Management
–Integrated Supplier Management (SS)
–Risk Management
–Quantitative Project Management
–Integrated Teaming (IT) and IPM(IPPD) will be

discussed with IPPD.

102
Basic Project
Management PAs
Status, issues, results
of process and
PMC product evaluations;
Corrective measures and analyses
action
Corrective action
What
Replan To Monitor
Status, What To Build

issues, PP What To Do
results
of progress Engineering
Commitm and Support
and milestone ents
reviews process areas
Plans
Measurement needs
SAM
Supplier
agreement
Product component requirements
Technical issues
Completed product components
Supplier Acceptance reviews and tests

103
Project Planning
• Purpose:
• Establish and maintain plans that define

project activities.

104
Project Planning - Context
Establish Planning Develop a

Estimates Data Project Plan
Obtain
Project
Commitment
Plans
to the Plan
PMC

105
Establish Estimates
Establish
Estimate Estimates of
the Scope Work Product
of the Project and Task
Attributes Planning
Data
Determine
Estimates
of Effort
and Cost
Define
Project
Life Cycle

106
Planning Data
Develop a Project Plan
Establish Plan Plan for

the Budget Identify for Data Project
and Project Risks Management Resources
Schedule
Plan Establish Plan for

Stakeholder the Project Needed
Involvement Plan Knowledge
and Skills
Project Plans
107
Obtain Commitment
to the Plan
Review
Plans that
Affect the
Project
Reconcile
Project Work and
Plans Resource
Levels
Obtain
Plan
Commitment

108
Project Monitoring and Control
• Purpose:
• Provide understanding into the project’s

progress so that appropriate corrective actions
can be taken when the project’s performance
deviates significantly from
the plan.

109
Project Monitoring and Control
- Context
Manage
Monitor Project Against Plans Corrective Actions
to Closure
Monitor
Monitor Monitor Conduct
Project
Project Stakeholder Milestone Analyze
Planning
Risks Involvement Reviews Issues
Parameters
Monitor Conduct Take

Monitor Data Corrective
progress
Commitments Management Actions
Reviews
Manage
Corrective
Actions
PP Project Plans

110
• Purpose:
• Manage the acquisition of products from suppliers

for which there exists a formal agreement.

111
Context
Establish Supplier Agreements
Determine Establish
Acquisition Select Supplier
Type Suppliers Agreements
List of Products
Supplier Requirements Product Supplier Agreement
Satisfy
Supplier
Agreements Execute
the Supplier
Agreement
Review Accept
COTS Transition
the Acquired
Products Products
Product

112
Advanced
Project Management PAs
Risk exposure due to
Process Performance
Objectives, Baselines, Models unstable processes
Statistical Mgmt Data QPM

subprocesses for
quantitative mgmt.
Organization’s Std. Identified risks
Processes
RSKM
Lessons IPM Coordination & collaboration; Shared
Learned, vision & IT structure
Performance
Process Data Risk
Management Taxonomies
process areas IT mgmt for & Parameters,
Project’s engineering IT Status,
Defined processes; Mitigation,
Process and
Corrective Action
Coordination,
commitments,
issues; Product
Architecture
for Structuring
Engineering & Teams Basic Project
Integrated
Support work
Management
process areas environment process areas
people &
113
CMMI Tutorial Apr 22, 2003 practices
• Purpose:
• Establish and manage the project and the

involvement of the relevant stakeholders
according to an integrated and defined process
that is tailored from the organization’s set of
standard processes.

114
Integrated Project Management - Context
Use the Project’s Defined Process Coordinate with
Defined Relevant
Process Stakeholders
Use Org
Establish Based
Proc Assets
the Project’s Integrate Project Plan
for Planning Manage
OPD Defined Plans
Project Stakeholder
Process Activities Involvement
Agendas and
Schedules for
Collaborative
Project’s Activities
• Estimates and Measures Defined
• Documentation Process
• Lessons Learned Manage
Dependencies
Documented
Critical
Dependencies
Manage
Project Using Contribute
Integrated to Org
Plans Process Resolve
Assets Other Project Coordination
& Org Functions Documented Issues
Technical
Issues

115
Integrated Supplier Management
• Purpose:
• Proactively identify sources of products that may

be used to satisfy the project’s requirements and
to manage selected suppliers while maintaining a
cooperative project-supplier relationship.

116
Integrated Supplier Management
-Context
Analyze and Select Sources of Products

SAM
Evaluate
Analyze
and
Potential
Determine
Sources of
Sources of
Products
Products
Coordinate Work with Suppliers
Monitor Evaluate
Selected Revise the
Selected Supplier
Supplier
Supplier Work Agreement or
Processes Products Relationship
Supplier Processes Supplier Work Products

117
Risk Management
• Purpose:
• Identify potential problems before they occur,

so that risk handling activities may be planned
and invoked as needed across the life of the
product or project to mitigate adverse impacts on
achieving objectives.

118
Risk Management - Context
Prepare for Risk Management Identify and
Analyze Risks
Determine Establish
Risk Define a Risk
Sources Risk Management
and Parameters Identify
Strategy Risks
Categories
Risk Repository
From Project Planning

Mitigate Risks Evaluate,
and Project Monitoring
Categorize, and
and Control
Prioritize
Implement Develop Risks
Risk Risk
Mitigation Mitigation
Plans Plans
DAR

119
• Purpose:
• Quantitatively manage the project’s defined

process to achieve the project’s established
quality and process-performance objectives.

120
Quantitative Project Management - Context
Quantitatively Manage the Project
Establish Quality and Process Compose

Project’s Performance Objectives the Defined
OPP Objectives Process
Predictions of Remedial Selected

Quality and Actions Subprocesses
Process Select
Performance
Manage Project’s the
Project Defined Subprocesses Definitions of
Performance Process that will be Measures;
Organization Statistically Derived
Measurement Managed Objectives
Repository
Statistically Manage Subprocess Performance
Subprocesse
Capability Monitor Apply
Select
Measure Record Performance Statistical
Stable Measures
Statistical of Selected Methods to
Sub- and Analytic
Management Subprocesses Understand
processes Techniques
Data Variation

121
Summary
• Project Planning
• Project Monitoring and Control
• Supplier Agreement Management
• Risk Management
• Integrated Project Management
• Integrated Supplier Management (SS)
• Quantitative Project Management
Special Note: Integrated Teaming (IT) and IPM(IPPD) will be


122
Support Process Areas
There are six Support Process Areas:

• Configuration Management
• Process and Product Quality Assurance
• Measurement and Analysis
• Causal Analysis and Resolution
• Decision Analysis and Resolution
• Organizational Environment for Integration will be

123
Understanding Support
Processes
• Support process areas cover the practices that

support product development, maintenance, and
acquisition.
• They provide essential processes used by all the

CMMI process areas, and are typically used in the
context of performing other processes.

124
Basic Support Process Areas
Measurements, Quality and

analyses noncompliance
issues
MA All process areas PPQA
Information
needs Processes and work
Configuration products;
items; standards and
change procedures
requests
CM
Baselines;
audit reports

125
Configuration Management
• Purpose:
• Establish and maintain the integrity of work

products using configuration identification,
configuration control, configuration status
accounting, and configuration audits.

126
Configuration Management -
Context
Establish Integrity
Establish Baselines Configuration

Management Establish
Identify System Config Mgmt Status
Configuration Records
Items Change
Request Audit
Database Results
Perform
Establish Configuration
a Config. Change Audits Action
Management Requests Items
System
Track
and
Create or Control Track Control
Release Changes Change Configuration
Baselines Requests Items

127
Process and Product Quality
Assurance
• Purpose:
• Provide staff and management with objective

insight into processes and associated work
products.

128
Process and Product Quality
Assurance - Context
Objectively Evaluate Processes and Work Products
Objectively
Objectively Evaluate
Evaluate Work
Work Processes Products
& Services
Products
Reports and Records
Provide Objective Insight
Communicate
and Ensure Establish
Resolution of Records
Non-compliance
Issues

129
• Purpose:
• Develop and sustain a measurement capability

that is used to support management information
needs.

130
Measurement & Analysis - Context
Align Measurement Analysis Activities
Specify
Establish Data Specify
Specify Collection
Measurement Analysis
Measures and Storage
Objectives Procedures
Procedures
Measurement Objectives Measurement

Repository Procedures,
Measurement Measurement Indicators Tools

Personnel
Provide Measurement Results
Store Analyze Collect

Communicate Data & Measurement Measurement
Results Results Data Data

131
Advanced Support Organization IPPD
Process Areas Infrastructure
CAR Process Ability to develop

improvement & deploy IPPD
processes OEI
proposals;
& supporting
Defects & assets;
other problems IPPD knowledge
& skill needs Integrated work
environment &
Process people practices
Project
Management Management
PAs PAs Selected
issues;
All process areas
Structured DAR
decisions
• Purpose:
• Identify causes of defects and other problems

and take action to prevent them from occurring
in the future.

133
Causal Analysis and
Resolution - Context
Determine Address Causes

Causes of Defects of Defects
Implement Evaluate
Action Effect of
Analyze Proposals Changes
Causes Action
Proposal
Action Plans
Select Record
Data for Defect & Performance
Problem Data Measures
Analysis
Data
CAR Records
134
• Purpose:
• Analyze possible decisions using a formal

evaluation process that evaluates identified
alternatives against established criteria.

135
• Applicability:
• The project should document guidelines for when
a structured decision analysis process is to be
used.
• DAR should be applied where significant
technical, cost, or schedule risks evolve.

136
Decision Analysis and
Resolution -Context
Evaluate Alternatives
Establish Select
Establish Identify
Guidelines Evaluation
Evaluation Alternative Methods
for Decision
Criteria Solutions
Other
Analysis
PAs
Guidelines Criteria Proposed Methods

Alternatives
Select Evaluate
Solutions Alternatives

137
Engineering Process Areas
• There are six Engineering Process Areas.

• Requirements Management
• Requirements Development
• Technical Solution
• Product Integration
• Verification
• Validation

138
Engineering Process Areas
Requirements
REQM
Product & product

component requirements
Alternative
solutions Product
components Product
RD TS PI Customer
Require-
ments
Product components, work products,

verification and validation reports
Ver Val
Customer needs
139
•Purpose:
•Manage the requirements of the project’s product

and product components and identify
inconsistencies between those requirements and
the project’s plans and work products.

140
Context
Manage Requirements
Obtain an Identify
Understanding Inconsistencies
of Requirements between Project
Requirements Work and
Reqmts
CL2 CL2
Obtain Manage Maintain
Commitment Requirements Bi-directional
to Requirements
Requirements Changes
Traceability
Traceability
Hierarchy

141
• Purpose:
• Produce and analyze customer, product, and

product component requirements.

142
Requirements Development -
Context
Develop Develop Analyze and

Customer Product Validate
Requirements Requirements Requirements
Customer Product Validated

Requirements Requirements Requirements

143
Context
Develop Customer Requirements
Collect Develop the

Stakeholder Customer
Needs Requirements
CL2
Elicit Needs
Customer
144
CMMI Tutorial Apr 22, 2003 Requirements
Context
Develop Product Requirements
Establish
Product &
Product
Component
Requirements
Allocate
Product and Identify
Product- Interface
Component Requirements
Requirements
Customer Product
Requirements
Requirements 145
Context
Analyze and Validate Requirements
CL3
Establish Establish a Analyze
Operational Definition of Analyze Requirements
Concepts Required Requirements to Achieve
& Scenarios Functionality Balance
CL2
Validate
Requirements
Validate with
Requirements Comprehensive
Methods
Product Validated
Requirements
Requirements 146
Technical Solution
• Purpose:
• Design, develop, and implement solutions

to requirements. Solutions, designs and
implementations encompass products, product
components, and product related life-cycle
processes either singly or in combinations as
appropriate.

147
Technical Solution - Context
Validated
Requirements
Select Product- Develop the Implement the

Component Design Product Design
Solutions
Alternative Designs Design Detail & Delivered

and Evaluation Criteria Documentation Product

148
Operational Scenarios
Validated Timeline Analysis DAR
Requirements Use Cases
Select Product Component Solutions
CL 2
Develop CL 2
Develop
Alternative Evolve
Detailed
Solutions and Operational
Solutions and
Selection Concepts &
Selection
Criteria Scenarios
Criteria
Select
Product
Component
Alternative Solutions Solutions
Selection Criteria Selection Decisions
New Technology Evaluations Compliance w/ Reqmts

149
Selection Criteria
Make/Buy Analysis
Develop the Design
Design Perform
Establish a Establish
the Product Make, Buy,
Tech Data Interface
or Product or Reuse
Package Descriptions
Component Analyses
I/F Design Documentation

Tech Data
I/F Specification
Package
I/F Control Documents
Design Methods
Design Tools CL 3
Design Processes Design
Interfaces
Using Criteria

150
Implement the Product Design
Develop
Implement Product
The Support
Design Documentation
Parts Fabricated Training Manuals

Software Coded Users Manual
Data Documented Operator’s Manual
Processes Documented Maintenance Manual
Facilities Constructed On-line Help

151
Product Integration
• Purpose:
• Assemble the product from the product

components, ensure the product, as
integrated, functions properly and deliver the
product.

152
Product Integration - Context
DAR
Ensure
Prepare for Integration Interface
Product Integration Plan Compatibility
Assemblies
Technical
Solution Sub-
assemblies
Assemble Product
Components
and Deliver the
Product

153
Prepare for Product Integration
CL3
CL2
Determine Establish
Establish
Integration Product
the Product
Sequence Integration
Integration
Procedures and
Environment
Criteria
Decision Analysis
& Resolution
Integration Plan
Technical
- Integration Resources
Solution - Integration Procedures
- Interface Data
154
Ensure Interface Compatibility
Review
Interface
Descriptions Manage
for Interfaces
Completeness
Integration Plan
Technical
- Integration Resources
- Interface Data

155
Assemble Product Components and Deliver Product
Package
Assemble And Deliver
Product the Product
Components or Product
Component
Confirm
Readiness of Evaluate
Components Assembled
for Product
Integration Components
Integration Plan
Technical - Integration Resources
- Interface Data
156
Verification versus Validation
• Verification
–Did you build the product right?
–That is, did you meet the requirements
specification?
• Validation
–Did you build the right product?
–That is, did you meet the operational need?

157
Verification
• Purpose:
• Ensure that selected work products meet their

specified requirements.

158
Verification - Context
Prepare for Perform

Verification Peer Reviews
Verification
Plan
Verify Selected
Work Products
Corrective
Actions

159
Prepare for Verification
CL3
Select CL2 Establish
Work Products Establish the Verification
for Verification Procedures
Verification Environment and Criteria
Requirements,
Methods, Processes,
Evaluation Criteria
Technical Verification Plan

- Verification Resources
Solution
- Verification Procedures

160
Perform Peer Reviews
Prepare CL 2
For Peer Analyze
Reviews Peer Review
Data
Requirement for Data
Collection
Entry and Exit Criteria
Peer Review Plan
Review Results
Review Issues
Review Data
Conduct Action Items
Peer
Reviews

161
Verify Selected Work Products
Perform
Verification
Verification Results
Deficiencies
Verification Data
Corrective Actions
CL2
Analyze
Verification
Results and
Identify
Corrective
Actions

162
Validation
• Purpose:
• Demonstrate that a product or product

component fulfills its intended use when
placed in its intended environment.

163
Validation - Context
- Customer Requirements
- Product Requirements
- Products
- Validation Requirements Validate Product or
Product Components
Prepare
for Validation
- Conformance
- Deficiencies
- Requirements Validation Plan

- Product Validation Plan
- Process and Support Needs

164
Requirements
Prepare for Validation
CL2
Select Products Establish the
For Validation Validation
Environment
CL3
Establish
Validation
Procedures
and
- Validation Plan Criteria
- Support Needs
- Environment Needs - Test Case Scenario
- Resources - Validation Procedures

165
Validate Product or Product Components
Perform Analyze
Validation Validation
Results
Validation Reports Validation Deficiency Reports

Validation Results Validation Issues
Cross Reference Matrix Procedure Change Request
As run procedures log
Operational Demonstrations

166
Process Management Process Areas
• There are six Process Management Process Areas:

–Organizational Process Focus
–Organizational Process Definition
–Organizational Training
–Organizational Process Performance
–Organizational Innovation and Deployment
–Organizational Environment for Integration will be
covered with IPPD

167
Understanding Process
Management Process Areas
•The process management PAs apply across the

organization as a whole and provide details that
support the Capability Level 3 Generic Goal.
•For selected PAs, the organization has standard

processes, which individual projects tailor to their
needs.

168
Understanding Process
•Process Management PAs can capitalize on

project level stability provided by PAs that are
institutionalized at CL 2.
•(i.e., policy, planning, resources, responsibility,

training, performing the process, managing
configurations, monitoring and controlling,
objective verification, management review)

169
Basic Process Management PAs
Organization’s
process needs
and objectives Training for Projects and
Senior Support Groups in Std
Process and Assets
Management
Organization’s OT
business Training needs
objectives
Std Process
and Other
Assets
Std Process
and Other Project Management,
Assets Support, and
OPF Resources and
OPD Engineering process
areas
Coordination
Improvement information
Process Improvement (e.g., lessons learned, data, artifacts)
Proposals; Participation in
defining, assessing, and
deploying processes
170
Organizational Process Focus
• Purpose:
• Plan and implement organizational process

improvement based on a thorough understanding
of the current strengths and weaknesses of the

organization’s processes and process assets.

171
Organizational Process Focus
- Context
Process Needs • Findings Improvement
and Objectives •& Ratings Initiatives
Identify Selected
Establish Appraise Org.’s Improvements
Organizational Org’s Process
Determine
Process
Process Processes Improve-
Improvement Needs ments Pilots,
Opportunities Action
Teams
(Revised) Process Deployable Process Process

Assets Process Assets Experiences Action plans
Plan
and
Implement
Process
Incorporate Implement Establish
Process- Deploy
Improve- Process Process
Related Organizational
ment Process Action Action
Activities Experiences Plans Plans
Assets

172
Organizational Process Definition
• Purpose:
• Establish and maintain a usable set of organizational

process assets.

173
Organizational Process
Definition - Context
Establish Organizational
Process Assets
Life Cycle Models
Establish
Life-Cycle Organizational
Model
Descriptions Standard Processes Process
Implementers
Organizational
Measurement
Establish the Repository
Establish Organization’s
Standard Measurement Organizational Library
Processes Repository of Process
Documentation
Tailoring Guidelines
Establish Establish the
Tailoring Organization’s
Criteria and Process Asset Deploy- Improvements
Guidelines Library ment
OPF

174
•Purpose:
•Develop the skills and knowledge of people

so they can perform their roles effectively
and efficiently.

175
Organizational Training - Context
Establish an Organizational
Training Capability
Determine Establish an
which Training Organizational
Establish Needs are the Training Establish
the Strategic Responsibility Tactical Plan Training
Training of the Org. Capability
Needs
Analysis Needs Strategy Reqmts
Materials
Training Repository
Change
Requests Records Records
Surveys Materials
Assess
Training Establish Deliver
Effectiveness Training Training
Records
Provide Necessary Training

176
Advanced Process
Cost and benefit
Improvements data from piloted
Organization
improvements
Quality and process

OID performance
objectives,
Quality and process measures,
performance objectives, baselines, models
Project Management,
measures, baselines, models Support, and
Engineering
process areas
Senior OPP
Management
Progress toward
achieving business
objectives Common
measures
Ability to develop Process performance
and deploy process and capability data
and supporting assets
“Basic Set” of Process
Management
Process Areas

177
•Purpose:
•Establish and maintain a quantitative

understanding of the performance of the
organization’s set of standard processes in
support of quality and process-performance
objectives, and to provide the process
performance data, baselines, and models to
quantitatively manage the organization’s
projects.

178
Organizational Process
Performance - Context
Establish Performance Baselines and Models
Establish
Select Selected Subprocesses Process
Processes from Org. Std. Processes Performance
Objectives
Business
Objectives
Organization’s Establish
Standard Process Project Process
Processes Performance Measurements
Baselines
QPM
•Org set of
Establish
Organizational Process measures
Process MA
Performance Baselines
Performance
Models
Organizational Process Establish
Business
Performance Objectives Quality and Objectives
Process
Process Performance
Performance Measures
Models
QPM
179
Organizational Innovation and
Deployment
• Purpose:
• Select and deploy incremental and innovative

improvements that measurably improve the
organization’s processes and technologies.
The improvements support the organization’s
quality and process-performance objectives as
derived from the organization’s business
objectives.

180
Organizational Innovation and
Deployment - Context
Select Improvements
Collect Select
and Analyze Identify
and Analyze Pilot Improvements
Improvement Improvements for
Proposals Innovations
Deployment
Measurement Improvement Proposals Improvements

Results and Analysis
Deploy Improvements
Measure Manage the Plan the

Improvements Deployment
Deployment
Effects


181
Overview of Integrated Product
and Process Development
IPPD

182
About IPPD
• IPPD affects all process areas.

• IPPD is not a discipline like SE or SW.
• Rather, it is a way of doing business.
• IPPD is employed in conjunction with the CMMI

disciplines (software and systems engineering).
• Implementation of IPPD shapes how you perform

the work in these disciplines.

183
IPPD - Definition
IPPD provides a systematic approach to

product development that achieves a timely
collaboration of relevant stakeholders
throughout the product life cycle to better
satisfy customer needs.

184
IPPD - Definition -2
Integration of the development of product-

related processes (e.g., manufacturing,
support, training, disposal) during product
development is embedded in SE/SW specific
practices by involving relevant stakeholders
from all life cycle phases and by the concept
of “work product.”

185
Stakeholder Involvement
• Stakeholder Involvement is guided and assured by
three constructs in CMMI- SE/SW/IPPD:
• GP 2.7 Identify and involve the relevant stakeholders

of the process as planned.
• PP SP 2.6-1 Plan the involvement of identified

stakeholders.
• IPM SG 2 Collaborate and coordinate with relevant

stakeholders.

186
CMMI Work Product - Definition
–Any artifact produced by a process.
–This may include files, documents, parts of the
product, services, processes, specifications, and
invoices.
–Examples of processes as work product include a
manufacturing process, a training process, and a
disposal process.
–A key distinction between a work product and a
product component is that a work product need
not be engineered (although it may be).

187
IPPD in CMMI Models
• Then, what makes IPPD different from pure SE/SW
implementations?
• IPPD relies on integrated teams to develop the

product and processes.
• IPPD provides an integrated work environment and

the management of people to incentivize teamwork.
• Processes are tailored to be used by integrated

teams.

188
CMMI Integrated Team Definition
• An integrated team is comprised of people

–with complementary skills and expertise
–appropriate skills and advocacy
–fully empowered to represent stakeholders
–from all phases of the work product’s life cycle
• These people are committed to and are

collectively responsible for
–delivering specified work products
–through timely collaboration

189
Scope of IPPD
• CMMI SE/SW/IPPD adds to CMMI-SE/SW:
– Two new process areas

» Organizational Environment for Integration
» Integrated Teaming
– A revised Integrated Project Management (IPPD)
process area
– IPPD amplifications and references
– New glossary definitions and acronyms
– Overview material

190
Organizational Environment
for Integration (OEI)
•Purpose:
•To provide an Integrated Product and Process
Development (IPPD) infrastructure and manage
people for integration.

191
Organizational Environment
for Integration (OEI)- Context
Mechanisms
IPPD-Enabled and
Provide People Manage Incentives
IPPD and People for to Support
Infrastructure Work Integration Integration
Environments and
Collaboration

192
Organizational Environment for
Integration – Context
OPD
Provide IPPD Infrastructure Manage People for Integration
Guidelines for
Organization’s Empowerment
Shared Vision
Establish the Establish
Organization’s Guidelines for
Leadership Leadership,
Shared Guidelines for Mechanisms Decision-making
Vision Shared Vision Context
Building
Process for
Issue Resolution
Establish
an Integrated Integrated Establish Team &
Work Environ- Work Incentives for Individual
ment Integration Rewards
Environment
Establish Organizational
Identify Guidelines
IPPD-Unique IPPD Tactical Mechanisms
Skill Require- & Strategic to Balance
Responsi- Joint
ments Training Performance
Needs bilities
Review Process
OT

193
For IPPD
• Purpose:
• Establish and manage the project and the
involvement of the relevant stakeholders
according to an integrated and defined process
that is tailored from the organization’s set of
standard processes.
• For Integrated Product and Process Development,
Integrated Project Management also covers the
establishment of a a shared vision for the project
and an integrated team structure that will carry
out the objectives of the project.

194
(IPPD) - Context
Product
Requirements
Stakeholders
Use the Defined Coordinate
Project’s Process and Collaborate Contributions to
Defined Based with Relevant Organization’s
Process Project Plan Stakeholders Process Assets
Use the Project’s Organize

Project’s Integrated Integrated
Shared Vision Shared
Vision Teams Teams
for IPPD for IPPD
Organizational
Environment for Project
Integration Planning
Stakeholders 195
(IPPD)
OEI Work
Use the Project’s Shared Breakdown
Organize Integrated Teams
Vision for IPPD Structure for IPPD
Team
Define the Info on Determine
Org/Project Structure
Project’s Team
Shared Situation
Structure List of
Vision
Context Member Teams
Aspirations
Develop a Responsibility
Preliminary & Requirements
Distribution of Allocation
Requirements
Establish
the
Project’s Project’s
Shared Shared Vision Establish Integrated
Vision Integrated Teams
Integrated Teams
Teaming
196
Integrated Teaming
•Purpose:
•To form and sustain an integrated team

for the development of work products.

197
Integrated Teaming - Context
Sponsor’s
Objectives
Assigned
Product (IPPD) Organizational
OEI
IPM
Requirements Environment for
Integration
Establish Team
Composition Integrated Govern Team Plans
Team Operation and
Commitments
PP
Project
Relevant Planning
Stakeholders
198
Integrated Teaming - Context
Establish Team Govern Team
Composition Operation
Results
Sponsors Lists
Establish Team’s
Objectives a Shared Shared Vision
Identify Vision
Team Tasks Task Team
Descriptions Establish Charter
a Team
Assigned Charter
Product Assignments,
Define
Identify Functions, Skills, & Respon-
Requirements Roles &
Knowledge & Expertise Respon- sibilities
and Skills Lists sibilities
Establish Ground Rules

Operating and
Procedures Procedures
Assign
Stakeholders Appropriate
Integrated Collaborate
Team among Plans and
Members Team Interfacing Commitments
Teams

199
Training and Appraisals

“Introduction to the CMMI” Course,
Staged & Continuous (Separate Courses)
• Introduction course will enable the participant to

– Understand the importance of defined processes
– Understand the rationale for process improvement
– Comprehend the CMMI model
– Identify ways of applying the CMMI model
for process improvement
• Broad audience
– Systems and software developers
– Systems, Program and software managers
– Practitioners of disciplines that support systems and software
– Government and industry acquirers of software-intensive systems
• Assumes one year of experience in systems and software
• No process improvement or Capability Maturity
Model (CMM ) experience assumed

201
“Intermediate Concepts of
CMMI Models” Course
• Provides a deeper understanding of the
CMMI and it’s fundamental concepts.
– PA’s in more detail
– Linking the PA’s together
– Interpreting the CMMI for appraisals
– Application of CMMI for process
improvement
• Required as a prerequisite to SCAMPI
Lead Appraiser training and “train the
trainer” course.

202
Appraisal Requirements for CMMI (ARC) v1.1
• Similar to the current CMM Appraisal

Framework (CAF) V1.0
–A guide to appraisal method developers
• Specifies the requirements for classes of
appraisal methods
–Class A: Full, comprehensive appraisal methods
–Class B: Initial, incremental, self-appraisals
–Class C: Quick-look
• Method developers can declare which class their
method fits
• Implications of the desired class of appraisal
203
Standard CMMI Appraisal Method for
Process Improvement (SCAMPI)
• Similar to CBA IPI method

• Led by authorized Lead Appraiser
• Tailorable to organization and
model scope
• Source selection appraisals or process monitoring are
tailoring options of SCAMPI
• SCAMPI Method Definition Document V1.1

204
CMMI Lead Appraiser Program
• Similar to existing SEI Lead Assessor
and Lead Evaluator programs
–To be administered by SEI
• Will transition current SW & SE Lead Assessors
or Evaluators, as well as new candidates
• Lead Appraiser requirements:
–Introduction to CMMI Training
–Appraisal team experience
–Intermediate CMMI Training
–SCAMPI Lead Appraiser Training

205
Expectations
• The method has been simplified, but…
–CMMI models have more process
areas and more practices than the
individual SE and SW models
–More of the organization may be
covered
• The achievable goal:
–Assuming an organization
of 3-6 projects, 6-9 team members,
experienced Lead Appraiser
–SCAMPI appraisals of process areas through
Levels 3 in 100 hours or less

206
Pilot Results
•Six SCAMPIs performed against V1.02 models:
– 2 government, 4 industry
– All explored continuous representation
•Each appraisal was characterized by:

– 6-12 assessment team members
– 2-4 projects
– 15-21 interviews
•Total on-site hours ranged from 85-137 hours

– All went beyond SE/SW
– “Equivalent” hours: 77-120; median 92
207
Discoveries in Use - 1
•Appraisal time shows an excellent learning curve

–40% reduction in appraisal time over five Australian
assessments
•“Shadow appraisals” show ease of transition

–High maturity CBA IPI at Litton PRC
–TSP based Level 4 CBA IPI at China Lake
•Mappings and gap analyses confirm evolutionary

expansion from predecessor models
–Government and contractors agree on CMMI’s improved
engineering coverage in contract monitoring
208
Wrap-Up

CMMI Transition Plan
Development Phase
• Development of CMMI products
• Verification and validation of CMMI products
Transition Phase
• Approval of initial CMMI products for
public release
• Evidence of sufficient use
• Transition planning to help organizations
use CMMI products
Sustainment Phase
• Upkeep and continuous improvement
of the product suite
• Additional evidence of adoption and
Pilots
use
V0.2 V1.0 V1.1 SWCMM, EIA 731 phased out
Aug 1999 Aug 2000 Dec 2001 Dec 2003

210
DoD Expectations for CMMI
Comments of Dr. Jack Ferguson,
Director, Software Intensive Systems (OUSD (AT&L))
At STC, 2001
CMMI will improve the maturity for the software intensive systems
development and maintenance
– Integration of systems and software emphasis will focus programs
on the essential engineering processes
– Gains already made in software will migrate to systems
engineering
CMMI will become the logical integrated successor for the SW-CMM
for software engineering and EIA/IS 731 for systems engineering
– Simplifies the process of viewing the two disciplines
– Major companies have migration plans in place
– Support for pilot assessments across Government and Industry
– Transition Partners are being trained as CMMI Lead Appraisers
211
DoD Expectations for CMMI
(continued)
• CMMI will become the approved means of judging

engineering maturity for procurements within two years
– Integrated appraisal method should minimize the impact
on industry and Government during procurement
evaluations
– OSD policy update to reference CMMI being considered
• New techniques for minimizing costs and schedule
impacts during appraisals related to procurements will be
considered and adopted
– Government participation in internal assessments
Comments of Dr. Jack Ferguson,

Director, Software Intensive Systems (OUSD (AT&L))
At STC, 2001 212
CMMI Schedule
• Available now
– CMMI-SE/SW, V1.1
– CMMI-SE/SW/IPPD, V1.1
– CMMI-SE/SW/IPPD/SS, V1.1
– SCAMPI Method Definition Document. V1.1
– V1.1 model and method training
• December 2003
– Sunset period for SW-CMM, EIA/IS 731 completed (no
more public courses, new lead assessors)
• December 2005
– SW-CMM Transition Partner licenses end
213
CMMI – What is coming next?
• Emphasis through 2003 is on CMMI adoption and transition
from legacy models
– Quarterly transition workshops will complement an annual User
Workshop and SEPG Conference
– “Communities of Practice” will be encouraged
» Course Instructors
» CMMI Appraisers
» Transition Teams
• “Technical Notes” and “Special Reports” will complement V1.1:
– Mapping CMMI with other standards and models
– Managing COTS integration
– Making attribute tradeoffs in design
– Allowing prototypical coverage for specific interests
(e.g., safety, security, modeling and simulation)

214
CMMI...Re-cap
• ... Is not so different from the models with which we
are familiar
• ... Has 2 representations in a single model:
– Staged
– Continuous
• ... Contains specific and generic goals that must be
satisfied
• ... Is directly related to our work:
– Not everything we do is just ‘software’
engineering
– There is a lot of systems engineering and
“other”
215
For More Information About CMMI
– Go to CMMI Website
» http://sei.cmu.edu/cmmi
» http://seir.sei.cmu.edu/seir/
» http://jo.sei.cmu.edu/pub/english.cgi/0/323123
» http://dtic.mil/ndia (first and second annual CMMI Conferences)
» http://www.faa.gov/aio
– Assistance for government organizations:

» SW-CMM v1.1 to CMMI v1.1 Mappings
Software Technology Support Center

OO-ALC/TI-3
7278 4th Ave
Hill AFB, UT 84056-5705
http://www.stsc.hill.af.mil

216

Cmmi V1

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cmmi V1

Uploaded by

Copyright:

Available Formats

Pittsburgh, PA 15213-3890

CMMI V1.1 Tutorial

Mike Phillips, CMMI Program Manager

Sponsored by the U.S. Department of Defense

CMMI Tutorial Apr 22, 2003

CMMI Tutorial Apr 22, 2003

Everyone realizes the importance of

• ...even our finest people

Major determinants of product

CMMI Tutorial Apr 22, 2003

• A process is a set of practices performed to achieve

a given purpose; it may include tools, methods,

• While process is often described as a leg of the

• Process provides a constructive, high-leverage focus...

CMMI Tutorial Apr 22, 2003

“The quality of a product is

Based on TQM principles as taught by

CMMI Tutorial Apr 22, 2003

• Over the past 30 years, these theories have been used to

• Solutions have been discovered, but a gap existed

• Many of these concepts have been used to build process-

CMMI Tutorial Apr 22, 2003

• A model is a structured collection of elements that

• Processes included are those proven by experience

CMMI Tutorial Apr 22, 2003

–to help set process improvement objectives and

–as a guide for improvement of organizational

CMMI Tutorial Apr 22, 2003

CMMI Tutorial Apr 22, 2003

“All models are wrong, but some

• Simplified approximations of reality that provide insight.

CMMI Tutorial Apr 22, 2003

• Historically: Depends on the discipline that you want

CMMI Tutorial Apr 22, 2003

CMMI Tutorial Apr 22, 2003

* Source: Standish Group Chaos Report

ZZZ • Different structures,

• Integrates systems and software disciplines into one

• Provides a framework for introducing new disciplines

CMMI Tutorial Apr 22, 2003

• Systems engineering and

CMMI Tutorial Apr 22, 2003

CMMI Tutorial Apr 22, 2003

Source Models SE/ SW /SW

• Process area capability and organizational

• The difference between them is that process area

CMMI Tutorial Apr 22, 2003

• Although the comparison of ratings and levels is

CMMI Tutorial Apr 22, 2003

•A model is not a process.

•The model shows what to do, NOT how to do it or

CMMI Tutorial Apr 22, 2003

CMMI Tutorial Apr 22, 2003

• Provides a roadmap for implementing:

• Familiar structure for those transitioning from the

CMMI Tutorial Apr 22, 2003

• Provides maximum flexibility for focusing on specific

• Familiar structure for those transitioning from the

CMMI Tutorial Apr 22, 2003

CMMI Tutorial Apr 22, 2003

• A CMMI model provides a structured view of

• CMMI can help