# Presentation: 001011

## Transitioning Capability Maturity Model for SoftwareToCapability Maturity Model Integration 

- Paul Meyers
- DSCMO Systems Integration Organization

- Software Engineering Process Group

## Agenda

- Introduction
- Why CMMI?
- CMMI Overview
- CMMI Structure vs. SW-CMM Structure
- SW-CMM KPA’s to CMMI PA’s
- Helpful Hints
- Conclusion
- Contact Information
- Questions

## Introduction

**Notes:**
I’m Paul Meyers 
A lot to cover, please hold questions to the end, may find it is answered later in presentation

Today’s topic is transition from SW-CMM to CMMI

## WHY CMMI?

## Problems

- Multiple CMM’s differed by
- Discipline (software, systems, acquisition, etc.)
- How Maturity is Defined (process improvement path)
- How Capability is Defined (institutionalization)
- There were also a number of competing and complementary frameworks for process measurement and improvement

**Notes:**
There were multiple CMM’s - SEI initially delivered Capability Maturity Model (CMM) covering the disciplines of:
Software Engineering (SW-CMM)
Systems Engineering (SE-CMM)
System Acquisition (SA-CMM)
People CMM (P-CMM)
Personal Software Process (PSP)
Others: SPICE (Software Process Improvement and Capability dEtermination), ISO, EIA, Trillium, IEEE, US Government

## Slide 6

**Notes:**
More like this.  

Journey started about 1987

## CMMI Project

**    ****CMMI**
**Product Suite**

**SW **
**CMMI**

**SE**
**CMMI**

**SE/SW**
**CMMI**

**SE/SW/**
**IPPD**
**CMMI**

- ...

- Assess

- ...

**Industry**

**SEI**

**Government**

**Notes:**
1993 – SEI Software CMM v1.1
1995– SPICE Baseline Practices Guide
1995– Systems Engineering CMM
1997 – SEI Software CMM v2 Draft C
1998– EIA 731 (Systems Engineering Capability Model)
1998– ISO/IEC 15504 type 2 technical reports 

Members has average 21 years of experience, organizations with solid process improvement experience:
U.S. Army, Navy, Air Force, Federal Aviation  Administration, National Security Agency, Software Engineering Institute, ADP, Inc., AT&T Labs, BAE, Boeing, Computer Sciences Corporation, EER Systems, Ericsson Canada, Ernst and Young, General Dynamics, Harris Corporation, Honeywell, KPMG, Litton, Lockheed Martin, Motorola, Northrop Grumman, Pacific Bell, Q-Labs, Raytheon, Rockwell Collins,Thomson CSF, TRW

## CMMI Product Suite

- Framework for generating integrated products to support product and process development
- Bodies of Knowledge
- Software Engineering, Systems Engineering, Integrated Product and Process Development, and Supplier Sourcing
- Two Representations
- Continuous
- Staged

**Notes:**
Why called product suite?

Because it is a framework – reference models, training models, appraisal models – allow for other models to be developed by individual industries based on need

Products share – common terminology and common components

Each body of knowledge related to a product or process development in CMMI is considered a discipline

## CMMI Product Suite

- Staged Representation
- Process Areas grouped and measured by Maturity Levels (Ala CMM)
- Continuous Representation
- Process Areas grouped by category (e.g., Project Management, Engineering) and measured by Capability Level
- Multiple Model Options
- Systems, Software, Systems + Software,
-    Systems + Software + Integrated Product and Process Development

**Notes:**
Disciplines can be grouped into Model Options:

## CMMI Model Components

- Process Area
- Goals (specific and generic)
- Practices (specific and generic)
- Typical Work Product
- Sub-practices
- Notes
- Discipline Amplifications
- Generic Practice Amplifications
- References

**Notes:**
Meaning of each will become clearer as presentation progresses

## CMMI Product Suite

- CMMI Generic Levels
- 5  Optimizing
- 4  Quantitatively Managed
- 3  Defined
- 2  Managed
- 1  Performed/Initial
- 0  Incomplete (continuous model only)

**Notes:**

5 Process Improvement is a continuous focus
4 Process are both measured and controlled
3 Process are characterized for the organization and is proactive
2 Process are characterized for projects and actions are often reactive
1 Processes are unpredictable, poorly controlled and reactive
0 Incomplete not done or not fully done
Required
Must be achieved
Essential for rating the achievement of the PA
Expected
Describe what is typically implemented to achieve a required component (i.e., a goal)
Alternatives are allowed
Informative
Provide details that help model users understand a PA and how they can be achieved

## Continuous Representation

## Process Capability

- The capability of an implemented process can be represented by a bar.

## Capability Levels are Cumulative

- Because capability levels build upon one another, there can be no gaps.

## Process Capability Profile

**Notes:**
Capabilities can vary process area to process area, no requirement that they be aligned

## Staged Representation

## Staged Model

**Notes:**
The staged representation organizes process areas into five maturity levels
Level One - Initial
Level Two - Managed
Level Three - Defined
Level Four - Quantitatively Managed
Level Five – Optimizing

Maturity Levels are cumulative, can not skip levels, e.g, from ML 2 to ML 4

## Model Comparison

## SW-CMM Structure

## SW-CMM Model Components

- Maturity Level
- Indicate Process Capability
- Key Process Areas
- Achieve Goals
- Common Features
- Address Implementation or Institutionalization
- Commitment, Ability, Activities, Measurement and Analysis, Verifying
- Key Practices
- Describe Infrastructure or Activities

## Slide 21

## CMMI Structure

## CMMI Model Components

- Process Area
- Goals (specific and generic)
- Practices (specific and generic)
- Typical Work Product
- Sub-practices
- Notes
- Discipline Amplifications
- Generic Practice Elaborations
- References
- Examples

**Notes:**
As we noted earlier

## Slide 24

**Notes:**
For the staged representation

Represent the “core” of the process specification

## Model Components

**Notes:**
For the staged representation
The maturity level of an organization provides a way to predict the future performance of an organization within a given discipline or set of disciplines (e.g., Systems Engineering).  
Maturity levels still consist of a predefined set of process areas. - The maturity levels are measured by the achievement of the specific and generic goals that apply to each predefined set of process areas. 
A maturity level is still a defined evolutionary plateau of process improvement
A process area is a cluster of related practices in an area that, when performed collectively, satisfy a set of goals considered important for making significant improvement in that area
Practices are actions to be performed to achieve the goals of a process area
A process area is not a process description, but a description of a process
Purpose Statement – Brief statement of what is to be accomplished by the implementation of the practices of a particular process areas 
Introductory Notes – Notes provide details that help understand the core information of the model.
Related Processes – Identify other process areas that interact and provides context for process 
Discipline Amplifications – Specialized piece of information that is relevant to a particular discipline
Notes – Can accompany nearly any other model component to provide detail, background or rational
References – Can accompany nearly any other process component and is a pointer to additional or more detailed information in a related process area
Examples – Can accompany nearly any other model component to provide concept clarification or describe activity

## Model Components

**Notes:**
There are two types of goals in CMMI – Specific and Generic
Specific goals apply to a specific process area and address the unique characteristics that describe what must be implemented to satisfy the process area. Specific goals are required model components and are used in appraisals to help determine whether a process area is satisfied.
SG 1 Manage Requirements - Requirements are managed and inconsistencies with project plans and work products are identified.  
Generic goals are called “generic” because the same goal statement appears in multiple process areas. 
Achievement of a generic goal in a process area signifies improved control in planning and implementing the processes associated with that process area.
GG 2 Institutionalize a Managed Process – The process is institutionalized as a managed process. 
Generic goals are required model components and are used in appraisals to determine whether a process area is satisfied.

Bullet two - thus indicating whether these processes are likely to be effective, repeatable, and lasting

Generic goals are always tailored to the needs of the process they are embedded in.

## Model Components

**Notes:**
Practices are descriptions of actions need to enact key elements of a process and are the essence of the CMMI model, Practices are major building blocks in establishing the process maturity of an organization
Specific Practices map to specific goals
A specific practice is an activity that is considered important in achieving the associated specific goal. 
Req. Mgmt. 
Specific Goal 1 – Manage Requirements, Specific Practice (SP) 1.4 – Maintain Bi-directional Traceability of Requirements 
Typical Work Products provide examples of outputs from a practice area
There are often other work products that could be used that are not listed
Specific Practice (SP) 1.4 – Maintain Bi-directional Traceability of Requirements
Requirements traceability matrix, Requirements tracking system
Sub-practices are related to practices 
Suggest a course of action for the associated specific process
Specific Practice (SP) 1.4 -  Maintain requirements traceability to ensure that the source of lower level (derived) requirements is documented (total of 4 listed)
Generic Practices map to Generic Goals
Are activities that ensure that the process associated with the process area will be effective, repeatable and lasting
Contribute to the achievement of the generic goal when applied to a particular process area
Organized by “Common Features”, Commitment to Perform (CO), Ability to Perform (AB) Directing Implementation (DI) Verification (VE)
Establishing organizational policies and leadership, Resources, organizational structures, and training, Insight into the performance of the process, Reviews and audits.

## SW-CMM KPA’s ToCMMI PA’sUsing Maturity Levels

## Mapping CMM ML to CMMI ML

**ML=MC****2****=PA*ln(GG****3****/SG)*(PR)*GPA****exp(TWP)**
**PA = q*[1-exp(-x*t)] / [1+exp(-x*t)] **
**GG = [-M / (2*k)]*ln([T - M*g - k*v^2] / [T - M*g]) **
**SG = [+M / (2*k)]*ln([M*g + k*v^2] / [M*g]) **
**PR = (M / k)*(1 / [2*q])*ln([q+v] / [q-v])**** **
**GPA = q*[1 - exp(-x*t)] / [1 + exp(-x*t)]**
**TWP = 1 - [ (m / {m+0.5*m}) / ln({m+m} / m)**** ]**

**Notes:**
ML – Maturity Level 
PA – Process Area
GG – Generic Goals
SG – Specific Goals
PR – Practices
GPA – Generic Practice Amplifications
TWP – Typical Work Products

## Changes at Maturity Level 2 - Repeatable

- SW-CMM
- Requirements Management
- Software Project Planning
- Software Project Tracking and Oversight
- Software Subcontract Management
- Software Quality Assurance
- Software Configuration Management

- CMMI
- Requirements Management
- Project Planning
- Project Monitoring and Control
- Supplier Agreement Management
- Product and Process QA
- Configuration Management
- _Measurement and Analysis_

**Notes:**
Measurement and Analysis is a new PA
Other process areas contain similar materials
Word “software” removed, CMMI covers both systems and software

## Changes at Maturity Level 3 - Defined

- SW-CMM
- Organization Process Focus
- Organization Process Definition
- Training Program
- _Inter-group Coordination_
- _Integrated Software Mgmt_

- CMMI
- Organization Process Focus
- Organization Process Definition
- Organizational Training
- Integrated Project Management
- _Integrated Supplier Mgmt_
- _Organizational Environment for Innovation_
- _Integrated Teaming_

**Notes:**
Some KPA’s from Maturity Level 3 SW-CMM do not have a one-to-one correspondence to Maturity Level 3 in CMMI.

Practices from Inter-group Coordination now found in Requirements Management, Project Planning, Integrated Project Management, and other PA’s. 

Practices from Integrated Software Management now found in Integrated Project Management and Risk Management

Integrated Supplier Management, Organizational Environment for Innovation, and Integrated Teaming have no comparable KPA in SW CMM

## Changes at Maturity Level 3 - Defined

- SW-CMM
- _Software Product Engineering_
- Peer Reviews ========

- CMMI
- _Risk Management_
- _Requirements Development_
- _Technical Solutions_
- _Product Integration_
- _Verification_
- _Validation_
- _Decision Analysis and Resolution_

**Notes:**
Software Product Engineering handled what is now distributed in the new Engineering Process Areas (Requirements Development, Technical Solutions, Product Integration, etc.) in CMMI

Peer Reviews incorporated into Verification Process Area

Decision Analysis and Resolution is new 

## Changes at Maturity Level 4 - Managed

- SW-CMM
- _Quantitative Process Management_
- _Software Quality Management_

- CMMI
- _Organization Process Performance_
- _Quantitative Project Management_

**Notes:**
KPA’s from Maturity Level 4 in SW-CMM do not have a one-to-one correspondence to Maturity Level 4 in CMMI.

Practices from Quantitative Process Management and Software Quality Management are found in Quantitative Project Management and Risk Management

Organizational Process Performance is new to CMMI

## Changes at Maturity Level 5 - Optimizing

- SW-CMM
- Causal Analysis and Resolution
- _Technology Change Management =======___
- _Process Change Management =======___

- CMMI
- Causal Analysis and Resolution
- _Organizational Innovation & Deployment_

**Notes:**
Some KPA’s from Maturity Level 5 in SW-CMM do not have a one-to-one correspondence to Maturity Level 5 in CMMI.

Ideas contained in Technology Change Management and Process Change Management are found in the Organizational Innovation and Deployment

## THE PLAN

- AKA – Git Er Don

## The Basic’s 

- Use KPIIDS (Key Practice Implementation Indicator Descriptions)
- Select CMM ML2 Project(s) (3 Max)
- Create KPIID for the Project(s) mapping Objective Evidence (OE) **AND** Process Documents

## KPIID

## The Basic’s 

- Map CMM Components to CMMI Components (done for you)

## Slide 39

**Notes:**
I only provided an overview of the mapping, but detailed one exists

This is a detailed map of SW-CMM to CMMI

Provide a reference to get the complete work later

## The Basic’s 

- Add Project and Process Columns to CMM/CMMI Map
- Map KPIID(s) OE and Process Doc’s to CMM/CMMI Map

## CMM/CMMI X-Ref

## The Basic’s 

- Identify the Gaps and Restructuring
- Extract The Measures
- Treat It As A Development Project – Use Your Existing CMM Processes
- Gaps/Restructuring are requirements
- Developing documentation is a project deliverable
- Manage documentation versions
- QA Applies

## Helpful Hints

- Understand SCAMPI
- Standard CMMI Appraisal Method for Process Improvement
- Use SCAMPI C and B as approach to monitoring overall progress (in alignment with QA)
- Don’t forget to include pilot project for updated processes
- Need to assess conversion requirements
- Select target projects for first release early

## Helpful Hints

- Continuous model can be used to help plan at detailed level
- Practice level is more granular due to additional level of the model, i.e, level 1
- Equivalent staging

## For Non CMM Organizations

- Use the CMMI GP’s to Plan your effort
**GP 2.1 Establish an Organizational Policy **
**GP 2.2 Plan the Process**
**GP 2.3 Provide Resources**
**GP 2.4 Assign Responsibilities **
**GP 2.5 Train people**
**GP 2.6 Manage configurations**
**GP 2.7 Identify and involve relevant stake holders**
**GP 2.8 Monitor and control the process**
**GP 2.9 Objectively Evaluate Adherence**
**GP 2.10 Review Status with Higher Level Management**

**Notes:**
From a Presentation done by Richard Marks of Raytheon

## For Non CMM Organizations

**GP 2.1 Establish an Organizational Policy **
**State clearly that the organization is going to follow CMMI and be successful**
**GP 2.2 Plan the Process**
**Develop an approach and schedule for implementing each PA including estimates of time/resources needed**
**GP 2.3 Provide Resources**
**Overhead, direct/indirect expenses, supplies, travel**
**Facilities required**
**Training for people, key players, etc.**

**Notes:**
From a Presentation done by Richard Marks of Raytheon

## Conclusion

- The models map sufficiently well to allow for sane conversion
- You say Tomato, I say Toemato, You say Potato, I Say Pototo, you get the idea
- Hard Work – Yes, Rocket Science – No

## CMMI Future

- Next version will contain minor revisions, e.g., clarifications
- Moving to single training class for representations
- Future versions will
- Drop common features
- Add additional process area, e.g., Acquisition
- Add a “service model”, ITIL/COBIT
- Other changes
- Moving to certifying appraisers and instructors

**Notes:**
Authorized  Certified

ITIL – IT Infrastructure Library is an authoritative source of descriptive IT best practices, notably in operations and service management

COBIT (Control Objectives for Information and related Technologies) was borne out of the efforts of dedicated experienced practitioners who recognized the need to have a series of controls to manage IT. In fact, numerous standards and practices were reviewed to identify the controls that it covers, and it is still evolving

## Questions

- ?

## Additional Information

**Frequently Asked Questions (FAQs)** - M**appings of CMMI to Other Standards**
-  _[http://www.sei.cmu.edu/cmmi/faq/map-faq.html#MAP01](http://www.sei.cmu.edu/cmmi/faq/map-faq.html#MAP01)_

## Contact Information

- Paul H. Meyers, SAIC Project Manager
- DSCMO Systems Integration Organization
- 301-763-3911
- paul.h.meyers@census.gov