(CMM-CMMI) CMMI - A Comprehensive Overview

CMMI: A Comprehensive Overview
Rushby Craig (801) 775-5739

Software Technology Support Center
Bruce Allgood (801) 777-3207

Computer Resources Support Improvement Program
Hill AFB, UT
Agenda
• Project History
• CMMI Structure
• Comparisons with SW-CMM v1.1, SE-CMM, and
EIA/IS 731_
• Process Areas Overview
• Assessment Methodology
• Training
CMMI User Group Nov 13, 2001 2

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

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

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
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 continuous integrated product
development
People CMM staged workforce
SPICE Model continuous software development

So Many Models, So Little Time
ZZZ
ZZZ
•Different structures,
Software
Software CMM
CMM formats, terms, ways
EIA
EIA 731
731
CMM
CMM of measuring maturity
•Causes confusion,
Systems
Systems especially when using
Engr
Engr more than one model
CMM
CMM
People
People •Hard to integrate
CMM
CMM
IPD
IPD Software
Software them in a combined
CMM
CMM Acq
Acq improvement program
CMM
CMM
•Hard to use multiple
Systems
Systems
models in supplier
FAA
FAA Security
Security selection
iCMM
iCMM Engr
Engr CMM
CMM
Bridging the Divide
• Systems and software Systems Software
disciplines have
traditionally not been well
integrated
• The importance of software
in systems has increased
dramatically
CMMI
Mike Phillips
– Example: % of
requirements allocated to
software: *
» B-2 -- 65%
» F-22 -- 80%
• The DOD has emphasized
the need to make the
systems/software interface
* Source: Standish Group Chaos Report
more seamless
CMMI to the Rescue!
• Integrates systems and software disciplines into one

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

as needs arise.

The CMMI Project
• DoD sponsored collaboration
between industry, Government, academia
• Over 100 people involved
• U.S. Army, Navy, Air Force • Honeywell
• Federal Aviation Administration • KPMG
• National Security Agency • Lockheed Martin
• Software Engineering Institute • Motorola
• ADP, Inc. • Northrop Grumman
• AT&T Labs • Pacific Bell
• BAE • Q-Labs
• Boeing • Raytheon
• Computer Sciences Corporation • Reuters
• EER Systems • Rockwell Collins
• Ericsson Canada • SAIC
• Ernst and Young • Software Productivity Consortium
• General Dynamics • Sverdrup Corporation
• Harris Corporation • Thomson CSF
• TRW
Air Force Involvement in CMMI Project
Air Force involved in development of CMMI from beginning
Steering Group Co-chair: Phil Babel, Ajmel Dulai, Mike Nicol (ASC)
Product Development Team (PDT) members
(4-6 PE 25% time CRSIP/STSC)
– John Kordik AFMC/ASC - (Engineering PAs, IPPD, Editor)

– Lt. Col Joe Jarzombek CRSIP (Test & Evaluation Team)
– Dan Bennett STSC (Assessment Method Integrated Team)

– Rushby Craig STSC (Test & Evaluation Team)
– Bruce Allgood CRSIP (Training Team, Implementation Strategy)
– Kevin Richins STSC (Editor Team)

CMMI Product Suite
• Training
• Models
–Model
–Disciplines
»Introduction to CMMI
»Software »Intermediate Concepts
»Systems
»IPPD –Instructor Training
»Acquisition (coming –Lead Assessor
soon!) • Appraisal methods
–Representations –Assessment Requirements
»Staged for CMMI (ARC)
»Continuous
–SCAMPI Method
Description Document
(MDD)

CMMI Models
Source Models SE/SW /SW

CMM I- CMMI-SE
• Capability Maturity Staged tion us
Continuo tion
Model for Software V2, enta nta
Repres Represe
draft C (SW-CMM V2C)
• EIA Interim Standard
731, System Engineering
Capability Model (SECM) • Combined System Engineering /
• Integrated Product Software Engineering model
Development Capability • Can be applied to:
Maturity Model, draft – Just the software engineering
V0.98 (IPD-CMM) projects in an organization
– Just the system engineering
project in an organization
– Both
– IPPD
CMMI User Group Nov 13, 2001 can be used in either/both
12
Comparing Model
Representations
Continuous Staged
5
ML5
Capability
4
ML4
3
ML3
1 2
ML2
ML 1
0
PA PA PA
Organization
Process
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.

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

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.

Model Measures
Release PAs/ Goals/ Activities/

FAs Themes* Practices**
SW-CMM V1.1 18 52 316
SW-CMM V2C 19 62 318
EIA/IS 731 19 61 77 199 383 1566
IPD-CMM V0.98 23 60 865
CMMI V1.0 SE/SW 22 70 417
CMMI V1.1 SE/SW/IPPD

24 76 460
* Ratable components
** Key to implementation effort

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 Requirements Activities
Management Management Technical
Solution
Configuration
Risk Management Management
Quality Assurance Product

Project Monitoring Integration
and Control Causal Analysis
and Resolution Technical Execution
Program Management
Assessment & Certification

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

Focus Definition Deployment Training Performance Mgmt
Process Maturation

Topics
• The structure of the CMMI documents

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

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

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

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

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

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

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
Structure of the Model Process Management
Introduction
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
Topics
• Structure of the CMMI documents

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

Process Capability
Process capability 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 (What you do)

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
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”

Continuous Organization of PAs
Category Process Area
Project Project Planning
Management Project Monitoring and Control
Supplier Agreement Management
Integrated Project Management(IPPD)
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
The Capability Dimension -1
• The values on this axis describe how well you
perform process (called Capability Levels).
Capability
Process not performed

Process 31
CMMI User Group Nov 13, 2001
The Capability Dimension -2
• The values on this axis describe how well you
perform process (called Capability Levels).
Process performed well and

continuously improved
Capability
Process not performed

Process 32
CMMI User Group Nov 13, 2001
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.

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

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

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
An Example Organizational
Process Capability Profile
5
Capability
4
3
2
1
0
RM PP PMC etc
Process

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.

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

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

PA)
–Requirements are maintained and accurately
reflected in project plans, activities and
products.
• Specific Practice (from Requirements
Management PA)
–Maintain the traceability of requirements to their
source requirements.

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

– The implemented process achieves the specific
goals of the process area.
• Generic Practice (from Capability Level 1)

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

Structure of the CMMI
Continuous Representation
Generic
Goals
&
Generic
Practices
Generic
Goals
&
Generic
Practices
Specific Specific
Goals Goals
& &
Practices Practices
Summary
• CMMI models were developed with broad

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

Topics
• Structure of the CMMI documents

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

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 Practices Specific Practices
Commitment
CommitmenttotoPerform:
Perform:creates
createspolicies
policiesand
andsecures
securessponsorship
sponsorshipfor forprocess
processimprovement
improvementefforts
efforts
Ability
Ability to Perform: ensures that the project and/or organization has the resources it needs to pursueprocess
to Perform: ensures that the project and/or organization has the resources it needs to pursue processimprovement
improvement
Directing
DirectingImplementation:
Implementation:collects,
collects,measures,
measures,and
andanalyzes
analyzesdata
datarelated
relatedtotoprocesses
processes
Verification:
Verification:verifies
verifiesthat
thatthe
theprojects
projectsand/or
and/ororganization’s
organization’sactivities
activitiesconform
conformtotorequirements,
requirements,processes,
processes,and
andprocedures
procedures
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.

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
Initial
1 Process unpredictable,
poorly controlled and
reactive

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

PA’s 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
3 Defined Validation
standardization Organizational Process Focus
Organizational Process Definition
Integrated Project Management
Risk Management
(IPPD) Organizational Environment for Integration
(IPPD) Integrated Teaming
Basic Requirements Management
2 Managed project Project Planning
management Project Monitoring and Control
Configuration Management
1 Initial
Example: Specific Goal and
Specific Practice
• Specific Goal (from Requirements Management

PA)
–Requirements are maintained and accurately
reflected in project plans, activities and
products.
• Specific Practice (from Requirements
Management PA)
–Maintain the traceability of requirements to their
source requirements.

Example: Generic Goal and
Generic Practice
• Generic Goal (from Maturity Level 2)

–Institutionalize a Managed Process.
• Generic Practice (from Maturity Level 2)

–Establish an Organizational Policy.

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

Common Feature Examples - 1
from Requirements Management Process Area
•Commitment to perform:
–Establish and maintain a written
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.

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 implemented Requirements
Management Process with management
and resolve issues.

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.

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.

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

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
60
SW-CMM v1.1 vs. CMMI
Common Features
SW-CMM v1.1 Common Features CMM I Common Features
Commitment to Perform Commitment to Perform
Establish an Organizational Policy Establish an Organizational Policy
Ability to Perform Ability to Perform
P lan the Process
Provide Resources Provide Resources
Assign Responsibility Assign Responsibility
Train People Train People
Activities Performed
P lan the Process (Specific Practices)
Perform the Process
Monitor and Control the Process
Directing Implementation
Collaborate with Rel. Stakeholders
Manage Configurations
Monitor and Control the Process
Measurement & Analysis
Measure the Process
Analyze the Measurements
Verifying Implementation Verifying Implementation
Review with Org. Management Review with [Higher-Level] Mgt
Review with Project Management
Objectively Verify Adherence Objectively Verify Adherence 61
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

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

Background -1
• Electronic Industries Association 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

Background - 2
• CMMI-SE/SW/IPPD merges software and

systems ideas into product development
ideas
–Staged representation
–Continuous representation with “equivalent
staging”

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

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

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 Support
and Select Product Integration
1.5 Integrate System Verification
1.6 Verify System
Validation
1.7 Validate System

CMMI Project Management
SECM Management Focus Areas
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 &
Resolution
CMMI Process Management
Process Areas
SECM Environment Focus Areas Organizational Process

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

Comparison of Generic Elements-1
SECM Generic Attributes CMMI Generic Attributes
GA1 Effectiveness of FA
none
Activities
GA2 Value of FA Products
Capability Level 1 Capability Level 1

none 1.1 Identify Work
Scope
1.2 Perform Base
Practices
Comparison of Generic Elements -2
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
CMMI User Groupmgmt
Nov 13, 2001 72

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
Comparison of Generic Elements - 4
4.1 Collect & analyze 4.1 Establish

metrics quality
objectives
4.2 Take appropriate
action to align 4.2 Stabilize
performance & subprocess
expectations performance

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
5.4 Perform causal analysis common
& eliminate causes of causes of
variation by changing the problems
standard process CMMI User Group Nov 13, 2001 75
SE-CMM and SECM (EIA/IS 731) vs. CMMI
Common Features - Engineering
SE-CMM SECM CMMI

Engineering Technical Engineering
PA06 Understand 1.1 Define
Customer Needs Stakeholder and Req’s Management
and Expectations System Level Requirements
PA02 Derive and Allocate Requirements
Development
Requirements 1.2 Define Technical
PA03 Evolve System Requirements Technical Solution
Architecture 1.3 Define Solution
PA01 Analyze Candidate 1.4 Assess and Decision Analysis
Solutions Select and Resolution
PA05 Integrate System
PA07 Verify and Validate Product Integration
1.5 Integrate System
System Verification
1.6 Verify System
PA04 Integrate 2.3
Disciplines 1.7 Validate System Validation

Common Features - Project Management
SE-CMM SECM CMMI

Project Management Project Management
2.1 Plan and Organize Project Planning
PA12 Plan Technical 2.2 Monitor and Project Mon and Con
Effort Control Supplier Agree Mgt
PA11 Monitor and 2.3 Integrate
PA04 Integrated Proj Mgt
Control Disciplines
Technical Effort Risk Management
2.4 Coordinate with
PA10 Manage Risk PA18 Suppliers
Support
PA09 Manage 2.5 Manage Risk Configuration Mgt
Configurations 2.6 Manage Data
PA08 Ensure Quality * 2.7 Manage
Proc and Prod QA
Meas and Analysis
Configurations
2.8 Ensure Quality L2 GP
Not in SE-CMM
* CMMI User Group Nov 13, 2001 77
Common Features - Process Management
SE-CMM SECM CMMI

Organization Environment Process Management
PA13 Define Organization’s 3.1 Define and Org Process Focus
SE Process Improve the SE Org Process Def
PA14 Improve Process
Organization’s SE Organizational Tng
3.2 Manage
Process L4 GP Quant Project Mgt
Competency
PA17 Provide Ongoing 3.3 Manage Org Process Perf
Knowledge and Skills L4 GP
Technology Causal An & Res
PA15 Manage Product Line L5 GP
3.4 Manage SE
Evolution Support
PA16 Manage SE Support Org Innovation and
Environment Deployment
Environment
PA18 Coordinate With 2.4 (IPPD Extension)
Suppliers Organizational
Environment
Integration

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

SM
Overview of CMMI
SE/SW/IPPD Model
Process Areas

Continuous Organization of PAs
Category
Project Project Planning
Management Project Monitoring and Control
Integrated Project Management(IPPD)
Integrated Teaming
Risk Management
Support Configuration Management

Organizational Environment for Integration
Engineering Requirements Management

Technical Solution
Product Integration
Verification
Validation
Process Organizational Process Focus

Management Organizational Process Definition
Organizational Innovation and Deployment
Project Management Process Areas
• There are seven Project Management Process Areas.
–Project Planning
–Project Monitoring and Control
–Supplier Agreement Management
–Integrated Project Management
–Risk Management
–Quantitative Project Management
–Integrated Teaming (IT) and IPM(IPPD) will be

discussed with IPPD.

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, issues, What To Build

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

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

project activities.

Project Planning - Context
Establish Planning Develop a

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

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

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
Obtain Commitment
to the Plan
Review
Subordinate
Plans
Reconcile
Project Work and
Plans Resource
Levels
Obtain
Plan
Commitment

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.

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

• Purpose:
• Manage the acquisition of products and services

from suppliers external to the project for which
there exists a formal agreement.

Supplier Agreement Management-Context
Establish Supplier Agreements
Analyze Establish
Needs and Select Supplier
Requirements Suppliers
Agreements
List of Products
Supplier Requirements Product Supplier Agreement
Satisfy
Supplier
Agreements Execute
the Supplier
Agreement
Acquire Conduct
COTS Transition
Acceptance
Product Products
Testing

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

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

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

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

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

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

• Purpose:
• Quantitatively manage the project’s defined

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

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
Performance Select
Manage Project’s the
Defined Definitions of
Project Subprocesses
Process Measures;
Performance to be
Organization Derived
Managed Objectives
Measurement
Repository
Statistically Manage Subprocess Performance

Subprocesse
Capability Monitor Apply
Select
Measure Record Performance Stable Statistical
Measures
Statistical of Selected Sub- Methods to
and Analytic
Management Subprocesses processes Understand
Techniques
Data Variation

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

will be discussed with IPPD.

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
discussed with IPPD.

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.

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

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

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

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
Changes Control
Release Changes Changes
Baselines

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

insight into the processes and associated work
products.

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

• Purpose:
• Develop and sustain a measurement capability

that is used to support management information
needs.

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,
Tools
Measurement Measurement Indicators
Personnel
Provide Measurement Results
Store Analyze Collect

Communicate Data & Measurement Measurement
Results Results Data Data

Advanced Support IPPD
Organization
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.

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
• Purpose:
• Make decisions using a structured approach that

evaluates identified alternatives against
established criteria.

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

Decision Analysis and
Resolution - Context
Evaluate Alternatives
Establish
and Use Select Establish Identify
Guidelines Evaluation Evaluation Alternative
for Decision Techniques Criteria Solutions
Analysis
Guidelines Techniques Criteria Proposed

Alternatives
Solutions
Select Evaluate
Solutions Alternatives
Evaluation
Results
Engineering Process Areas
• There are six Engineering Process Areas.

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

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
Requirements Management
•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.

Requirements Management - 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
Changes
Requirements Traceability
Traceability
Hierarchy

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

product component requirements.

Requirements Development -
Context
Develop Develop Analyze and

Customer Product Validate
Requirements Requirements Requirements
Customer Product Validated

Requirements Requirements Requirements

Requirements Development -Context
Develop Customer Requirements
Collect Transform
Needs into
Stakeholder
Needs Customer
Requirements
CL2
Elicit Needs
Customer
Requirements
Requirements Development - Context
Develop Product Requirements
Establish
Product &
Product
Component
Requirements
Allocate Identify
Product Interface
Component Requirements
Requirements
Customer Product
Requirements CMMI User Group Nov 13, 2001 Requirements 123
Requirements Development - Context
Analyze and Validate Requirements
CL3
Establish Establish a Evaluate
Operational Definition of Analyze Product
Concepts Required Requirements Cost,
& Scenarios Functionality Schedule,
& Risk
CL2
Validate
Requirements
Validate with
Requirements Comprehensive
Methods
Product Validated
Requirements CMMI User Group Nov 13, 2001 Requirements 124
Technical Solution
• Purpose:
• Develop, design, and implement solutions

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

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

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

Selection Criteria
Make/Buy Analysis
Develop the Design
Use Perform
Develop Establish
Effective Make, Buy,
Tech Data Interface
Design or Reuse
Package Descriptions
Methods Analyses
I/F Design Documentation

Tech Data
I/F Specification
Package
I/F Control Documents
Design Methods
Design Tools CL 3 CL 3
Design Processes Establish Design
Complete Comprehensive
Tech Data Interface
Package

Implement the Product Design
Establish
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

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

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

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

Prepare for Product Integration
CL2 CL3
Establish Establish
a Product Define Detailed
the Product Product
Integration
Integration Integration
Strategy
Environment Procedures
Decision Analysis
& Resolution
Technical
Integration Plan
- Integration Resources
Solution - Integration Procedures
- Interface Data
Ensure Interface Compatibility
Review
Interface
Descriptions Manage
for Interfaces
Completeness
Technical
Integration Plan
- Integration Resources
- Interface Data

Assemble Product Components and Deliver Product
Package
Assemble And Deliver
Product the Product
Components or Product
Component
Confirm Checkout
Readiness of Assembled
Components Product
for Components
Integration
Integration Plan
Technical - Integration Resources
- Interface Data
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?

Verification
• Purpose:
• Assure that selected work products meet their

specified requirements.

Verification - Context
Prepare for Perform

Verification Peer Reviews
Verification
Plan
Verify Selected
Work Products
Corrective
Actions

Prepare for Verification
CL3
CL2 Establish
Establish a Establish the
Verification Detailed
Verification Verification
Strategy Environment Plans
Requirements,
Methods, Processes,
Evaluation Criteria
Technical Verification Plan

Solution - Verification Resources
- Verification Procedures

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

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

Validation
• Purpose:
• Demonstrate that a product or product

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

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

Prepare for Validation
CL2
Establish a Establish the
Validation Validation
Strategy Environment
CL3
Define
Detailed
Validation
Procedures
- Validation Plan
- Support Needs
- Environment Needs - Test Case Scenario
- Resources - Validation Procedures

Validate Product or Product Components
Capture
Perform and 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

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

Understanding Process
Management PAs
•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.

Understanding Process
Management PAs
•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)

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
Organizational Process Focus
• Purpose:
• Establish and maintain an understanding

of the organization's processes and process
assets, and identify, plan, and implement the
organization's process improvement activities.

Organizational Process Focus
- Context
Process Needs • Findings Improvement
and Objectives •& Ratings Initiatives
Identify Selected
Establish Assess Org.’s Improvements
Determine
Organizational Org’s Process
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 Deploy
Process
Incorporate Implement Establish
Process- Process Process
Improve- and Related Process
ment Related Action Action
Experiences Process
Activities Assets Plans Plans

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

process assets.

Definition - Context
Create Organizational
Process Assets
Life Cycle Models
Establish
Life-Cycle Organizational
Model
Descriptions Standard Processes Process
Make Supporting
Process Assets Implementers
Available
Organizational
Measurement
Establish an Repository
Establish Organizational
Standard Measurement Organizational Library
Processes Repository of Process
Documentation
Tailoring Guidelines
Establish Establish
Tailoring Organizational
Criteria and Process Asset Deploy- Improvements
Guidelines Library ment
OPF
•Purpose:
•Develop the skills and knowledge of people

so they can perform their roles effectively
and efficiently.

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

Advanced Process
Management PAs
Cost and benefit
Improvements data from piloted
Organization
improvements
OID Quality and process

performance
objectives,
Quality and process measures, baselines,
performance objectives, 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

•Purpose:
•Establish and maintain a quantitative

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

Performance - Context
Establish Performance Baselines and Models
Establish
Select Selected Subprocesses from Process
Processes MA
Org. Std. Processes Performance
Measures
Business
Objectives
Organization’s Establish
Standard Process
Processes Performance
Project Process
Baselines
Measurements
Establish •Org set of QPM

Organizational Process measures
Process
Performance Baselines
Performance
Models
Organizational Process Business
Establish
Performance Objectives Quality and Objectives
Process
Process Performance
Performance Objectives
Models
QPM
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.

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

Results and Analysis
Deploy Improvements
Measure
Manage the Plan the
Improvements
Deployment Deployment
Effects

Overview of Integrated Product
and Process Development
IPPD

About IPPD
• IPPD affects all process areas.

• IPPD is not a discipline.
• 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.

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.

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

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 with identified

stakeholders.
• IPM SG 2 Collaborate and coordinate with relevant

stakeholders.

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

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.

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

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

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

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

Organizational Environment for
Integration – Context
OPD
Provide IPPD Infrastructure Manage People for
Integration
Guidelines for
Organization’s Empowerment
Shared Vision
Establish the Establish
Guidelines for
Organization’s 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

Integrated Project Management -
(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.
• It 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.

(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

Shared Integrated
Project’s Integrated Teams
Shared Vision Vision Teams
Organizational
Environment for Project
Integration Planning
Stakeholders
Integrated Project Management (IPPD)
OEI Work
Use the Project’s Shared Breakdown
Organize Integrated Teams
Vision Structure
Team
Define the Info on Determine Structure
Project’s Org/Project 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 Establish Integrated
Vision Vision Integrated Teams
Integrated Teams
Teaming
Integrated Teaming
•Purpose:
•To form and sustain an integrated team

for the development of work products.

Integrated Teaming - Context
Sponsor’s
Objectives
Assigned Organizational
IPM
Product Environment for
(IPPD)
Integration
Establish and
Maintain Team Integrated Govern Team Plans
Composition Team Operation and
Commitments
Project
Stakeholders Planning

Integrated Teaming - Context
Establish Team Govern Team
Composition Operation
Results
Sponsor’s 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, Roles &
& Respon-
Knowledge & Expertise Respon- sibilities
and Skills Lists sibilities
Establish Ground Rules

Operating and
Procedures Procedures
Assign
Stakeholders Appropriate
Integrated Collaborate
Team With Plans and
Members Team Interfacing Commitments
Teams
Training and Assessments
“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 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

“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
assessments
– Application of CMMI for process
improvement
• Required as a prerequisite to SCAMPI
Lead Assessor training.

Additional Training Identified
• Executive Tutorial
• Moving From SW-CMM to CMMI
• Process Improvement Training
• Concept-Specific Training (RM, CM, QA, etc.)

Assessment Requirements for CMMI (ARC)
• Similar to the current CMM Appraisal

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

• Led by authorized Lead Assessor
• Tailorable to organization and
model scope
• SCE will be a tailoring option from SCAMPI
• SCAMPI Method Description Document

CMMI Lead Assessor Program
• Similar to existing SEI Lead Assessor
and Lead Evaluator programs
–To be administered by SEI
• Will transition current SW & SE
Lead Assessors
–SCAMPI Upgrade Training
• Lead Assessor requirements:
–Introduction to CMMI Training
–Assessment team experience
–Intermediate CMMI Training
–SCAMPI Lead Assessor Training
Expectations
• The method has been simplified, but…
–CMMI models have more process
areas and more practices than each
of the individual source models
• The goal:
–Assuming an organization
of 3-6 projects, 6-9 team members,
experienced Lead Assessor
–SCAMPI assessment of process areas through
Levels 3 in 100 hours or less

Wrap-Up
What’s New in CMMI V1.1?
• Mainly minor changes

• Terminology clean-up
–“process”
–“stakeholder”
–“goals” vs. “objectives”
–“CM process” vs. “CM process area”
–“DAR process” vs. “Formal evaluation process”
• Informative material has been beefed up in GP’s
• A few goals and practices have been modified

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 use
Pilots
V0.2 V1.0 V1.1 SW-CMM, EIA 731 phased out

Aug 1999 Aug 2000 Dec 2001 Dec 2003

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 CMM-SW 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 Assessors
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, 2001CMMI User Group Nov 13, 2001 190
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”

(CMM-CMMI) CMMI - A Comprehensive Overview

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

(CMM-CMMI) CMMI - A Comprehensive Overview

Caricato da

Copyright:

Formati disponibili

CMMI: A Comprehensive Overview

Rushby Craig (801) 775-5739

Bruce Allgood (801) 777-3207

CMMI User Group Nov 13, 2001 2

• Historically: Depends on the discipline that you want

CMMI User Group Nov 13, 2001 3

CMMI User Group Nov 13, 2001 5

• Integrates systems and software disciplines into one

• Provides a framework for introducing new disciplines

CMMI User Group Nov 13, 2001 8

– John Kordik AFMC/ASC - (Engineering PAs, IPPD, Editor)

– Dan Bennett STSC (Assessment Method Integrated Team)

CMMI User Group Nov 13, 2001 10

CMMI User Group Nov 13, 2001 11

Source Models SE/SW /SW

• Source Model Heritage

CMMI User Group Nov 13, 2001 14

• Provides a roadmap for implementing:

• Familiar structure for those transitioning from the

CMMI User Group Nov 13, 2001 15

• Provides maximum flexibility for focusing on specific

• Familiar structure for those transitioning from the

CMMI User Group Nov 13, 2001 16

Release PAs/ Goals/ Activities/

SW-CMM V2C 19 62 318

EIA/IS 731 19 61 77 199 383 1566

IPD-CMM V0.98 23 60 865

CMMI V1.0 SE/SW 22 70 417

CMMI V1.1 SE/SW/IPPD

** Key to implementation effort

Contracting Activity Planning

Quality Assurance Product

Assessment & Certification

Organizational Process Management

Process Process Innovation and Process Quantitative

CMMI User Group Nov 13, 2001 18

• The structure of the CMMI documents

CMMI User Group Nov 13, 2001 19

• Six chapters provide an overview

CMMI User Group Nov 13, 2001 20

CMMI User Group Nov 13, 2001 21

• Six chapters provide an overview

CMMI User Group Nov 13, 2001 22

CMMI User Group Nov 13, 2001 23

CMMI User Group Nov 13, 2001 24

• Structure of the CMMI documents

CMMI User Group Nov 13, 2001 26

Process capability may be represented by a set of

Process (What you do)

Process Process Process Process

•Process Areas (PAs) are a cluster of related

•They are the major building blocks in establishing

•Example PA: “Requirements Management”

CMMI User Group Nov 13, 2001 29

Support Configuration Management

Engineering Requirements Management

Process Organizational Process Focus

Process not performed

Process Process Process Process

Process performed well and

Process not performed

Process Process Process Process