The CMM Integration Project
Dr. Jack R. Ferguson
CMMI Project Manager
Dr. Rick Hefner
Assessment Team Co-Lead
CMMI 1
Objectives
• Present the background and current status of
the CMM Integration Project
• Discuss structure and sample content of the
new maturity models
• Discuss timeline for public release of the
models and pilot assessments
• Discuss transition from the current maturity
models and assessment methods
CMMI 2
Agenda
• Introduction
• Background
• Design Approach
Dr. Jack Ferguson (SEI)
• Comparison to SW-CMM v1.1
• Comparison to EIA IS 731
(SECM)
• Assessment Methodology
Dr. Rick Hefner (TRW)
• Comment Process
• Transition Process
• Discussion
Dr. Jack Ferguson (SEI)
CMMI 3
Background
Dr. Jack Ferguson
Objectives
• Review project objectives
• Review key requirements and source material
• Discuss CMMI project team
• Compare and contrast current maturity models
– CMM for Software, SECM, IPD-CMM
– Staged, continuous
CMMI 4
What are Capability Maturity
Models?
• Organized collections of best practices
• Based on work by Crosby, Deming, Juran,
Humphrey...
• Systematic ordered approach to process
improvement.
• Means of measuring organizational maturity.
• Have proven to bring significant return on
investment in productivity and quality.
CMMI 5
How are
CMMs used?
• Process
Improvement
• Process Definition
• Competency
Assessment
• Risk Management
• Communication
CMMI 6
The Current Situation - every silver
lining has a dark cloud
• Explosion of CMMs
and CMM-like models
• Multiple assessments
• Multiple training
• Multiple models within • Multiple expenses
an organization
CMMI 7
The Frameworks Quagmire
PSP
SDCCR
SW-CMM
People
CMM
SDCE
SCE
SA-CMM
FAAiCMM
ISO
15504*
(SPICE)
IPDCMM*
SECM*
(EIA/IS 731)
SECAM
MIL-STD
-499B*
IEEE Stds. 730,828
829, 830,1012,1016
1028,1058,1063
IEEE
1220 EIA/IS
632
* Not yet released
NATO
AQAP1,4,9
EQA
CMMI*
SE-CMM
SSECMM
MIL-Q
-9858
Trillium
DO178B
DOD
IPPD
AF IPD
Guide
Baldrige
TickIT
Q9000
ISO 10011
MIL-STD-1679
DODSTDDOD-STD
2168
-2167A
MIL-STD498
BS
5750
ISO/IEC
12207
DOD-STD
-7935A
EIA/IEEE
J-STD-016
IEEE
1074
ISO 9000
Series
ISO 15288*
IEEE/EIA
12207
EIA 632*
Also see www.software.org/quagmire
5 June
1998
Courtesy Sarah quag14d:
Sheard,
SPC
CMMI 8
Why is This a Problem?
• Similar process improvement concepts, but...
– Different model representations (e.g. staged,
continuous, questionnaire, hybrid)
– Different terminology
– Different content
– Different conclusions
– Different appraisal methods
CMMI 9
The Common Basis for ModelBased Process Improvement
Improvement in any discipline is a function of
performing:
– Implementing practices that reflect the
fundamentals of a particular topic (e.g.
configuration management)
– Institutionalizing practices that lead to
sustainment and improvement of an
implementation
CMMI 10
All CMMI source models contain:
• Implementing practices grouped by affinity
• Institutionalizing practices that vary from
model to model, however all models specify
levels that describe increasing capability to
perform
CMMI 11
Improvement Levels
Continuously
improving
process
Quantitatively
(4)
Managed
Predictable
process
Standard,
consistent
process
Defined
Managed
Disciplined
process
Initial
(1)
Optimizing
(2)
(3)
(5)
(measured)
(standard)
(planned and tracked)
(performed)
Not performed (0)
CMMI 12
The CMMI Project
• DoD sponsored
• Collaborative endeavor
– Industry
– Government
– Academia
• Over 100 people involved
CMMI 13
CMM Integration Project
Steering Group
Co-Chairs
P. Babel / B. Rassa
Stakeholder/
Reviewers
Product Development Team
Project Manager
J. Ferguson
Coordinating IPT
Team leads
Architecture
IPT
PA Author
Groups
Usability Team
IPPD
IPT
Training
Meth.
IPT
Lotus Notes Team
Chief Architect
R. Bate
Editors (CCB)
Assessment
Meth.
IPT
Reqmts.
IPT
Pilot Planning
CMMI 14
The CMMI Development Team
• U.S. Air Force
• U.S. Navy
• Federal Aviation
Administration
• National Security Agency
• Software Engineering
Institute (SEI)
• ADP, Inc.
• Boeing
• Computer Sciences Corp.
•
•
•
•
•
•
Ericsson Canada
General Dynamics
Honeywell
Litton
Lockheed Martin
Northrop Grumman
•
•
•
•
•
Pacific Bell
Raytheon
Rockwell Collins
Thomson CSF
TRW
CMMI 15
CMMI Design Goals
• Integrate the models, eliminate
inconsistencies, reduce duplication
• Reduce the cost of implementing modelbased process improvement
• Increase clarity and understanding
–
–
–
–
Common terminology
Consistent style
Uniform construction rules
Common components
• Assure consistency with ISO 15504
• Be sensitive to impact on legacy efforts
CMMI 16
Benefits
• Efficient, effective assessment and improvement
across multiple process disciplines in an
organization
• Reduced training and assessment costs
• A common, integrated vision of improvement for
all elements of an organization
• A means of representing new discipline-specific
information in a standard, proven process
improvement context
CMMI 17
The Challenge
• Extract the common or best
features from the source models
• Provide users the ability to
produce single- or multiplediscipline models, both
continuous and staged, tailored
to their organizational needs.
• Provide users the ability to
assess and train based on these
models.
CMMI 18
CMMI Source Models
• Capability Maturity Model for Software V2,
draft C (SW-CMM V2C)
• EIA Interim Standard 731, System
Engineering Capability Model (SECM)
• Integrated Product Development Capability
Maturity Model, draft V0.98 (IPD-CMM)
CMMI 19
Staged Representations
• Key Process Areas are grouped in the stages
(levels) from 2 to 5
• A Key Process Area contains specific
practices (activities) to achieve the purpose of
the process area.
• For a Key Process Area at a given stage,
institutionalization practices are integral to the
process area.
CMMI 20
Staged Model
Level
Key Process Areas
Org Improvement Deployment
Continuous
5
Org Process and Tech Innovation
process
Optimizing
improvement
Defect Prevention
4
Organization Process Performance
Quantitatively Quantitative
Statistical Process Management
Managed
management
Org Software Asset Commonality
Peer Reviews
3
Process
Project Interface Coordination
Defined
Standardization Software Product Engineering
Organization Training Program
Organization Process Definition
Organization Process Focus
Software Configuration Management
2
Basic
Repeatable
Software Quality Assurance
Project
Software Acquisition Management
Management
Software Project Control
Software Project Planning
Requirements Management
1
Initial
Focus
Competent people and heroics
CMMI 21
Continuous Representations
• A process area contains specific practices to
achieve the purpose of the process area.
• Generic practices are grouped in Capability
Levels
• Generic practices are added to the specific
practices of each process area to attain a
capability level for the process area.
• The order in which Process Areas are
addressed can follow a recommended staging.
CMMI 22
Continuous Model
CL5
CL4
CL3
CL2
Implemented
GP
GP
GP
GP
GP
GP
GP
GP
GP
GP
GP
GP
GP
GP
GP
GP
NI
NA
Process Area NE RQ OS TR PM KM QA VS
NR
…
SR FD IN
PA - Process Area
CLn - Capability Level n institutionalized
(Level n GPs satisfied for PA)
GP - Generic Practice
Imp - Implemented Base Practices
NI - Not Implemented
NA - Not Applicable
NR - Not Rated
CMMI 23
Source Model Terminology
SW-CMM
V2C
Staged
Maturity Levels
Key Process Areas
Key Process Area
Goals
Activities Common
Feature
Common Features
CBA IPI Method
EIA IS 731
SECM
Continuous
Capability Levels
Categories
Focus Areas
Themes
Specific Practices
Generic Practices
Advanced Practices
Generic Attributes
(process effectiveness, product value)
SECM Appraisal
Method
IPD-CMM
V0.98
Hybrid
Maturity and
Capability Levels
Process Areas
Capability and
Process Area Goals
Base Practices
Generic Practices
CMMI 24
Assessment Methods
• CBA IPI Method
–
–
–
–
Rating of goals
Single digit rating
Full goal satisfaction
More strict data
validation requirement
• SECM Assessment
Method
–
–
–
–
Rating of practices
Granularity options
Partial credit options
Less strict data
validation requirement
Both methods use the same basic set of activities
CMMI 25
The CMMI Challenge
• Integrate three source models that have many
differences
• Provide consistency with ISO 15504
• Maintain support from user communities
• Develop framework to allow growth to other
disciplines
CMMI 26
Design Approach
Objectives
• Review design goals
• Discuss framework of CMMI models
• Describe CMMI terminology and components
• Outline CMMI products
• Discuss CMMI Schedule and current issues
CMMI 27
The CMMI Solution
A Product Line Approach
SW
IPPD
SE
...
Industry
SEI
CMMI
Product Suite
Government
Assess
Training
• Team of Teams
• Modeling and
Discipline Experts
• Collaborative
Process
CMMI- CMMI- CMMISW
SE
SE/SW
CMMISE/SW/
IPPD
...
CMMI 28
The CMMI Product Line
The CMMI product line is a product suite sharing a
common, managed set of features that satisfy
specific needs of a selected domain.
pertain to
Domain
is satisfied by
share an
Architecture
Products
guides development of
are built from
Components
CMMI 29
CMMI Product Suite
Framework
Input
•Common
content
•Discipline
content
•Criteria for
content
Transform
•Rules for
generating
products
-Model
-Assessment
-Training
Output
•Integrated
model(s)
•Assessment
method(s)
•Training
materials
Repository
CMMI 30
Framework
• Components
• Construction rules
• Conceptual architecture
CMMI 31
The CMMI Framework
Framework General
•Glossary
•Development Standards and Guidelines
•Document Templates
•Assessment Methodology
•Framework Training Materials
Shared (Discipline X+Y)
Process Management
Core (PMC)
Integration Core (IC)
IPPD Environment
PMC Generic Practices/Templates
PMC Process Areas
PMC Assessment Material
PMC Model Training Material
PMC Assessment Training Material
IC Generic Practices/Templates
IC Process Areas
IC Assessment Material
IC Model Training Material
IC Assessment Training Material
Discipline Y
Discipline X (DX)
+
DX Amplifications
DX Process Areas
DX Assessment Material
DX Model Training Material
DX Assessment Training Material
Output
Models
Assessment Methods
Model Training Materials
Assessment Training Materials
CMMI 32
CMMI Terminology
CMMI Models contain institutionalization (Generic)
and implementation (Specific) parts:
• Front matter
• Process Areas that contain:
Required
– Generic and Specific Goals
Expected
– Generic and Specific Practices
(in Common Features in staged representation)
Informative
– Subpractices
– Notes
– Discipline-specific amplifications
• Glossary and tailoring guidelines
CMMI 33
CMMI V0.2 Process Areas - 1
Maturity Level 2
Process Management Core
Engineering Shared (SE & SW)
• Project Planning
Requirements Management
• Project Monitoring and Control
• Configuration Management
• Process & Product Quality
Assurance
• Supplier Agreement Management
• Data Management
• Measurement & Analysis
CMMI 34
CMMI V0.2 Process Areas - 2
Maturity Level 3
Process Management Core
Engineering Shared (SE & SW)
• Organizational Process Focus
• Customer & Product
Requirements
• Organizational Process
Definition
• Technical Solution
• Organizational Training
• Product Integration
• Integrated Project
Management
• Product Verification
• Validation
• Risk Management
• Decision Analysis &
Resolution
CMMI 35
CMMI V0.2 Process Areas - 3
Maturity Levels 4 & 5
Process Management Core
• Quantitative Management of Quality and Process
• Organizational Process Performance
• Causal Analysis and Resolution
• Organizational Process Technology Innovation
• Process Innovation Deployment
CMMI 36
CMMI Products
• CMMI Models
• Assessment Material
• Training Material
• Model Developer Material
CMMI 37
CMMI Models
• Staged and Continuous (with equivalent
staging) versions of:
–
–
–
–
Software Engineering
Systems Engineering
Systems Engineering + Software
Systems Engineering + Software with IPPD
• Tailoring Guidance
CMMI 38
Assessment Material
• Assessment requirements
• Assessment methodology
• Assessment data collection methods and tools
(e.g., questionnaires, interviews)
• Assessment Team qualifications
CMMI 39
Training Material
• Model Training
• Assessment Training
– Team Training
– Lead Assessor Training
CMMI 40
Model Developer Material
• Glossary
• Framework and model content criteria
• Framework Training
CMMI 41
CMMI Schedule
• August 31, 1999
Release CMMI-SE/SW V0.2
for public review.
• Nov 30, 1999
Release CMMI-SE/SW/IPPD
for public review
• Nov 1999-May 2000
Pilot assessments
• Jun-Aug 2000
Publish models V1.0
CMMI 42
Issues Concerning
Initial CMMI Drafts
• Size of model
• Complexity of model
• “Normative” model
• Goals and Themes
• Order of process areas
• Equivalence between
staged and continuous
representations
– “Advanced” practices
– Process area boundaries
– Generic practices
• ISO Consistency
CMMI team received 4000+ change requests from reviewers
CMMI 43
CMMI-SE/SW compared to
SW-CMM v1.1
Dr. Rick Hefner
Objectives
• Philosophy
• Model Component Comparison
• Process Area Comparison
• Common Features Comparison
CMMI 44
Philosophy - 1
• SEI had completed updates to the SW-CMM
when the CMMI project was started
– SW-CMM v2 Draft C was used as the source
model for CMMI
– Adapted for compatibility with SE
• Most of the community is currently using
SW-CMM v1.1
– Detailed traceability matrices are being
developed
CMMI 45
Philosophy - 2
• CMMI- SE/SW staged representation is similar
to SW-CMM v1.1
– Maturity Levels composed of Process Areas
– Goals are required; implemented & institutionalized
– Key practices are expected; alternative practices are
acceptable if effective at meeting the goals
– All else is informative
• CMMI- SE/SW continuous representation
reflects the same info in a SPICE-like structure
CMMI 46
Model Component Comparison
CMMI Models
SW CMM
Process Area
Key Process Area
Generic Goal
Planning Goal sometimes used v1.1,
Institutionalization Goal in 2.0
Specific Goal
KPA Goal
Generic Practice
Key practices from
institutionalization common features
Specific Practice
Key Practice from Activities Performed
Common Features
Subpractice
Subpractice
Maturity Level
Maturity Level
Capability Level
Notes
None
Explanatory Material
Work Products
Examples
“For Software Engineering”
Examples and explanatory materiel
CMMI 47
SW-CMM v1.1
LEVEL 5
OPTIMIZING
LEVEL 4
MANAGED
LEVEL 3
DEFINED
Defect prevention
Technology change mgmt
Process change mgmt
Causal Analysis and Resolution
Org. Process Technology Innovation
Process Innovation Deployment
Quantitative process mgmt
Software quality mgmt
Org. Process Performance
Quantitative Mgmt of Quality & Process
Organization process focus
Organization process definition
Training program
Integrated software mgmt
Organization process focus
Organization process definition
Organizational training
Integrated project management
Risk Management
Customer and Product Reqmts
Technical Solution
Product Integration
Product Verification
Validation
Decision Analysis and Resolution
Software product engr
Intergroup coordination
Peer reviews
LEVEL 2
REPEATABLE
CMMI
Requirements management
Software project planning
Software project tracking & oversight
Software subcontract mgmt
Software quality assurance
Software configuration mgmt
Requirements management
Project planning
Project Monitoring and Control
Supplier Agreement Management
Product & Process Quality Assurance
Configuration Management
Data Management
Measurement and Analysis CMMI 48
Software Product Engineering
SW-CMM v1.1 Activities
1 Appropriate software engineering methods and tools
are integrated into the project's defined software
process.
2 The software requirements are developed, maintained,
documented, and verified by systematically analyzing
the allocated requirements according to the project's
defined software process.
3 The software design is developed, maintained,
documented, and verified, according to the project's
defined software process, to accommodate the
software requirements and to form the framework for
coding.
4 The software code is developed, maintained,
documented, and verified, according to the project's
defined software process, to implement the software
requirements and software design.
Customer and
Product Req PA
Technical
Solution PA
Technical
Solution PA
Product
Verification PA
Software Product Engineering
SW-CMM v1.1 Activities (continued)
6 Integration testing of the software is planned and
performed according to the project's defined software
process.
Product
Integration PA
7 System and acceptance testing of the software are
planned and performed to demonstrate that the
software satisfies its requirements.
Product
Verification PA
8 The documentation that will be used to operate and
maintain the software is developed and maintained
according to the project's defined software process.
9 Data on defects identified in peer reviews and testing
are collected and analyzed according to the project's
defined software process.
10 Consistency is maintained across software work
products, including the software plans, process
descriptions, allocated requirements, software
requirements, software design, code, test plans, and
CMMI 50
Common Feature Comparison
SW-CMM v1.1 Common Features
Commitment to Perform
Establish an Organizational Policy
Ability to Perform
Provide Resources
Assign Responsibility
Train People
Activities Performed
Plan the Process
Perform the Process
Monitor and Control the Process
Measurement & Analysis
Measurement the Process
Analyze the Measurements
Verifying Implementation
Review with Org. Management
Review with Project Management
Objectively Verify Adherence
CMMI Common Features
Commitment to Perform
Establish an Organizational Policy
Ability to Perform
Plan the Process
Provide Resources
Assign Responsibility
Train People
Directing Implementation
Manage Configurations
Monitor and Control the Process
Activities Performed
Perform the Process
Handled by the
Measurement and Analysis PA
Verifying Implementation
Review with Management
Objectively Verify Adherence
CMMI 51
Conclusions
• Organizations using SW-CMM v1.1 should be
able to smoothly transition to CMMI
– Measurement and Analysis & Data Mgmt at L2
– Risk Management & Decision Analysis and
Resolution at L3
– Expansion of Software Product Engineering
– Configuration Management for all Process Areas
CMMI 52
Comparing CMMI-SE/SW
to EIA IS 731-SECM
Objectives
• Philosophy
• Process Area Comparison
• Planned IPPD Extensions
CMMI 53
Philosophy - 1
• EIA 731 was created as a merger of the SECMM and INCOSE SECM models
– Used as a source model for CMMI
• CMMI-SE/SW merges software ideas
– Staged representation of SE available
– Continuous representation with “equivalent
staging”
CMMI 54
CMMI-SE
Process Manag emen t Core
Proj ect Plan ning
Proj ect Monitoring and Contro l
Configura tion Manag emen t
Process and Produ ct Qu ality Assu rance
Sup plie r Agre emen t Mana geme nt
Data Manag emen t
Meas ureme nt a nd Analysi s
Organ izatio nal Proce ss Focu s
Organ izatio nal Proce ss Definition
Organ izatio nal Train ing
In tegra ted Project Man agem ent
Risk Mana geme nt
Decisio n An alysis and Resol utio n
Quan tita tive Mgm t of Quali ty & Process
Organ izatio nal Proce ss Pe rforma nce
Caus al Analysi s an d Reso luti on
Org. Proce ss Tech nolo gy Inn ovatio n
Process Inn ovatio n Depl oyment
Eng inee ring Shared (SW & SE)
Requ ireme nts Mg mt
Customer & Produ ct Re quire ments
Te chn ica l Sol utio n
Syste m In tegra tion
Prod uct Veri ficatio n
Va lida tion
Othe r
EIA731/SECM
SE-CMM
Pla n an d Organ ize
Moni tor a nd Con trol
Mana ge Con figu ratio ns
Ens ure Qua lity
Coord inate with Supp liers
Mana ge Data
Meas ure a nd Improve
Pla n te chn ica l effort
Moni tor a nd control tech nical e ffort
Mana ge configura tion s
Ens ure q uali ty
Coord inate with sup plie rs
Defi ne a nd Improve the SE Process
Mana ge Su pport Environ ment
Mana ge Com pete ncy
In tegra te Dis cip line s
Mana ge Ris k
As sess and Sele ct
Im prove o rgani za tion 's SE process
Defi ne o rgani za tion 's SE process es
Mana ge SE supp ort e nvironm ent
Provid e on goin g skill s an d knowled ge
Mana ge ri sk
Mana ge Tech nolo gy
Derive and allo cate req uirem ents
Defi ne Stake hold er an d Syste m Le ve l Reqs Unde rstan d custo mer n eeds & expe ct.
Defi ne Tech nical Pro blem
Evolve system archite ctu re
Defi ne So luti on
An alyze candi date sol utio ns
In tegra te System
In tegra te s ys tem
Ve rify Syste m
Ve rify & val idate system
Va lida te System
Mana ge p roduct l ine evolution
EIA 731 Focus Areas - 1
• Technical Focus Areas
– Define Stakeholder and
System Level Requirements
– Define Technical Problem
– Define Solution
– Assess and Select
– Integrate System
– Verify System
– Validate System
Causal Analysis and Resolution (PM)
Org Process Technology Innovation (PM)
Process Innovation Deployment (PM)
Quantitative Mgmt of Quality and Process (PM)
Organizational Process Performance (PM)
Organizational Process Focus (PM)
Organizational Process Definition (PM)
Organizational Training (PM)
Integrated Project Management (PM)
Risk Management (PM)
Decision Analysis and Resolution (PM)
Customer and Product Requirements (Eng)
Technical Solution (Eng)
Product Integration (Eng)
Product Verification (Eng)
Validation (Eng)
Project Planning (PM)
Project Monitoring and Control (PM)
Configuration Management (PM)
Product and Process Quality Assurance (PM)
Supplier Agreement Management (PM)
Data Management (PM)
Measurement and Analysis (PM)
Requirements Management (Eng)
CMMI 56
EIA 731 Focus Areas - 2
• Management Focus Areas
–
–
–
–
–
–
–
–
Plan and Organize
Monitor and Control
Integrate Disciplines
Coordinate with Suppliers
Manage Risk
Manage Data
Manage Configurations
Ensure Quality
Causal Analysis and Resolution (PM)
Org Process Technology Innovation (PM)
Process Innovation Deployment (PM)
Quantitative Mgmt of Quality and Process (PM)
Organizational Process Performance (PM)
Organizational Process Focus (PM)
Organizational Process Definition (PM)
Organizational Training (PM)
Integrated Project Management (PM)
Risk Management (PM)
Decision Analysis and Resolution (PM)
Customer and Product Requirements (Eng)
Technical Solution (Eng)
Product Integration (Eng)
Product Verification (Eng)
Project Planning (PM)
Project Monitoring and Control (PM) Validation (Eng)
Configuration Management (PM)
Product and Process Quality Assurance (PM)
Supplier Agreement Management (PM)
Data Management (PM)
Measurement and Analysis (PM)
CMMI 57
Requirements Management (Eng)
EIA 731 Focus Areas - 3
• Environment Focus Areas
– Define and Improve the
Systems Engineering Process
– Manage Competency
– Manage Technology
– Manage Systems
Engineering Support
Environment
Causal Analysis and Resolution (PM)
Org Process Technology Innovation (PM)
Process Innovation Deployment (PM)
Quantitative Mgmt of Quality and Process (PM)
Organizational Process Capability (PM)
Organizational Process Focus (PM)
Organizational Process Definition (PM)
Organizational Training (PM)
Integrated Project Management (PM)
Risk Management (PM)
Decision Analysis and Resolution (PM)
Customer and Product Requirements (Eng)
Technical Solution (Eng)
Product Integration (Eng)
Product Verification (Eng)
Validation (Eng)
Project Planning (PM)
Project Monitoring and Control (PM)
Configuration Management (PM)
Product and Process Quality Assurance (PM)
Supplier Agreement Management (PM)
Data Management (PM)
Measurement and Analysis (PM)
Requirements Management (Eng)
CMMI 58
What’s New?
• Not a EIA 731 Focus Area
(but in the content)
– Causal Analysis and Resolution
– Process Innovation Deployment
– Quantitative Process and
Quality Mgmt
– Organizational Process
Performance
Causal Analysis and Resolution (PM)
Org Process Technology Innovation (PM)
Process Innovation Deployment (PM)
Quantitative Mgmt of Quality and Process (PM)
Organizational Process Performance (PM)
Organizational Process Focus (PM)
Organizational Process Definition (PM)
Organizational Training (PM)
Integrated Project Management (PM)
Risk Management (PM)
Decision Analysis and Resolution (PM)
Customer and Product Requirements (Eng)
Technical Solution (Eng)
Product Integration (Eng)
Product Verification (Eng)
Validation (Eng)
Project Planning (PM)
Project Monitoring and Control (PM)
Configuration Management (PM)
Product and Process Quality Assurance (PM)
Supplier Agreement Management (PM)
Data Management (PM)
Measurement and Analysis (PM)
Requirements Management (Eng)
CMMI 59
Conclusions
• EIA 731 users should be able to smoothly
transition to the CMMI-SE/SW model
– Continuous representation (+ “equivalent” staged
representation)
– Some lower level differences
• Integrated Product and Process Development
(IPPD) will be added
– Based on IPPD-CMM practices
CMMI 60
Assessment Methodology
Dr. Rick Hefner (TRW)
Assessment Methodology Team Co-lead
Objectives
• Assessment approach
• Assessment Requirements for CMMI (ARC)
• SCAMPI assessment method
• Lead Assessor program, transition plan
CMMI 61
Assessment Methods
• CBA IPI Method
–
–
–
–
Rating of goals
Single digit rating
Full goal satisfaction
More strict data
validation requirement
• SECM Method
–
–
–
–
Rating of practices
Granularity options
Partial credit options
Less strict data
validation requirement
Essentially the same activities in the two methods
CMMI 62
Assessment Requirements for CMMI
(ARC)
• Similar to the current CMM
Appraisal Framework (CAF) V1.0
– Specifies the minimum
requirements for full, comprehensive
assessment methods, e.g., SCAMPI
• Other assessment methods may be defined
for situations not requiring a comprehensive
assessment
– initial assessment, quick-look, process improvement
monitoring, etc.
CMMI 63
Standard CMMI Assessment Method
for Process Improvement (SCAMPI)
• Similar to CBA IPI method
• Led by authorized Lead Assessor
• Tailorable to organization and model scope
• Artifacts:
– SCAMPI Method description document
– Maturity questionnaire, work aids, templates
• Current activities
– Merger of SECM appraisal method features
CMMI 64
CMMI Lead Assessor Program
• Similar to existing SEI Lead Assessor
and Lead Evaluator programs
• Grandfather current Lead Assessors
• Under consideration
– Delineate by discipline, e.g., SW Lead Assessors,
SE Lead Assessors?
– Details of transition process for current Lead
Assessors and other assessment leaders
– Required training in CMMI models
CMMI 65
Comment Process
Dr. Jack Ferguson
• Release CMMI-SE/SW v0.2 August 31
– Available at http://www.sei.cmu.edu
– Public comments due November 30
• Release CMMI-SE/SW/IPPD November 30
– Comments due February 28
• Hold Focus Group discussions
– SEI Transition
– Assessors for both communities
– SPINs
CMMI 66
Pilot Assessments
• Nine initial assessments (desired)
– Supported by 3 Product Development Team (PDT) members,
– Covering all CMMI models, staged and continuous representations
– Nine organizations (4 DoD & 5 industry) volunteered to participate
•
•
•
•
•
1 - CMMI SE/SW with IPPD, staged or continuous representation
4 - CMMI SE/SW, staged representation
2 - CMMI SE/SW, continuous representation
1 - CMMI SE, continuous representation
1 - CMMI SW, staged representation
• Product Development Team (PDT) member roles
– CMMI Product Suite Training
– Coaching and structured observation
• Structured feedback from assessment participants
– Assessors and Sponsors, and
– Participating organization members
CMMI 67
CMMI Transition Plan
• Development Phase
– Development of CMMI products
– Verification and Validation of CMMI products
• Transition Phase
– Approval of a CMMI Product for public release
– Evidence of sufficient use
– Transition planning to help organizations use CMMI products
• Sustainment Phase
– Upkeep & continuous improvement of the product suite
– Additional evidence of adoption and use
Sustainment Phase
Transition Phase
Development Phase
CMMI 68
Transitioning to Use of CMMI
• Understand how models are used:
– Steps to enterprise-wide process improvement
• Apply Lessons Learned in transitioning from
single-discipline models
– Federal Aviation Administration’s experiences
with iCMM
– US Air Force experiences with transitioning
between models
– Others...
CMMI 69
Steps to Enterprise-wide
Organizational Maturity
Org name
1. Vision, Goals, Buy-in
Section name
USED AT:
USED AT:
AUTHOR: Joel Van Berkum
PROJECT: MWSSS SOFTWARE PROCESS
WORKING
REV:
DRAFT
11/2/98
READER
DATE
2. Process
Capture
PUBLICATION
PROCESS RCP
PHASE 1
Vali dated
RCP
1
PLAN, COORDINATE
AND APPROVE A
MAINTENANCE
SOFTWARE PROJECT
PACKAGE
PHASE 2
2
CCB VCN
approval
Rej ected
contractor cos t
propos al
Validated
RCP
-0
Contractor
Reports
3
DRAFT
OASB minutes
Delayed
CCB
package
3. Gap Analysis
Fi nal CCB package
PUT THE
MAINTENANCE
SOFTWARE PROJECT
ON CONTRACT
PHASE 3
WORKING
REV: 10/22/98
NOTES: 1 2 3 4 5 6 7 8 9 10
MWSSS OI 21-7
RCP
DATE: 10/21/98
PROJECT: MWSSS SOFTWARE PROCESS
CONTEXT:
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
AUTHOR: Joel Van Berkum
PERFORM VCN
ANALYSIS
Rejected
contractor
cos t
propos al
21ST SW
21-10401
DATE CONTEXT:
CONSULT WITH
SOFTWARE IPT
2
Best
Practices
Releas e Factors
Informal as s es s ment
of Releas e Factors
2.1.2
PREPARE
CCB
PACKAGE
2.1.3
Operational acceptance m es s age
CCB package
CAT2 Deficiencies
4
PREPARE ACQUISITION
STRATEGY BRIEFING
2.1.4
5
Dis tri buted
s igned
project
closeout
report
Pers onnel
TITLE:
0
Section name
CCB package template
2.1.1
CLOSEOUT THE
MAINTENANCE
SOFTWARE PROJECT
PHASE 5
NODE:
READER
PUBLICATION
OARB minutes
Awarded
Contract
MANAGE THE
EXECUTION OF
THE MAINTENANCE
SOFTWARE PROJECT
PHASE 4
Section name
RECOMMENDED
Organization
Processes
DATE: 9/18/98
Section name
MAINTAIN AIR FORCE SPACE COMMAND
SENSOR SOFTWARE
Acquis ition
strategy briefing
CONDUCT
ACQUISITION
STRATEGY
2.1.5
Validated RCP
NUMBER:
Sens or IPT
NODE:
USED AT:
AUTHOR: Joel Van Berkum
DATE: 9/23/98
WORKING
PROJECT: MWSSS SOFTWARE PROCESS
REV:
DRAFT
10/23/98
READER
DATE CONTEXT:
Approved
acquis ition
s trategy
Mys tic Algorithms
TITLE:
PLAN PROJECT
PREPARE AND Draft VCN
COORDINATE
DRAFT VCN
2.1.6
NUMBER:
2.1
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLICATION
2
SSM
4. Process
Transformation
Draft of VCN
staff s ummary
sheet
Cus tomer
GET DRAFT VCN
APPROVAL
PM
Draft VCN approval
2.3.1
CCB
package
REVIEW
CCB PACKAGE
2.3.2
Delayed CCB package
DRY-RUN
CCB
Proposed
CCB agenda
2.3.3
Configuration
Management
Approved
CCB
package
Conditionally
approved CCB
package
MODIFY
CCB
SLIDES
2.3.4
REVIEW
CCB
PACKAGE
2.3.5
Delayed CCB
package
Final CCB
agenda
From Process,
all good things flow!
Final CCB package
Configuration Management
REVIEW VCN
BY CCB
Dis approved
CCB
package
CCB
minutes
Pers onnel
2.3.6
NODE:
TITLE:
APPROVE VCN
CCB VCN
approval
NUMBER:
2.3
Project
Management
Process
Level
Evolution
Metrics
Capture
Activity
Based
Costing
Simulation
CMMI 70
CMMI Benefits
• CMMI product users can expect to:
– Efficiently and effectively improve and
assess multiple disciplines across their
organization
– Reduce costs (including training) associated
with improving and assessing processes
– Deploy a common, integrated vision of
Improved
Processes
process improvement that can be used
as a basis for enterprise-wide process
improvement efforts.
CMMI 71
The promise...
• CMMI team is working to
assure the CMMI Product
Suite addresses needs of
software and systems
engineering communities
of practice
• Use of an integrated model
to guide enterprise process
improvement promises to
be one of the more
sustainable & profitable
initiatives that any
organization might pursue
CMMI 72
Discussion
CMMI 73