cmmi (capability maturity model– integrated) overview dan weinberger mgr., software process...

CMMI (Capability Maturity Model–Integrated)Overview

Dan WeinbergerMgr., Software Process EngineeringiDEN Systems Division, Motorola Inc.Prof. Paul Rogoway, Judea and Samaria University and Consultant to Motorola Corporate Quality

March 1, 2001 CMMI - Rogoway, Weinberger 2

What we will Discuss

CMMI – why, provenance, releases Terminology shifts from CMM How is the CMMI different from CMM Maturity Level definition has changed Level by Level content changes Process Area structure Summary

In a hurry? – see pp. 29-30 & 34


Motivation/requirements Integrate the many CMMs: software, systems

engineering, integrated product [and process] development,SW acquisition,people

Integrate the assessment process Strengthen process areas at higher maturity

levels Strengthen link of model to business results Add benefit from SPI experience over many years Harmonize with international process standards,

e.g. ISO/IEC 15504 (SPICE) Respond to specific change requests

CMMI Background 1 of 4


Who ? Whence ? What ? Project Team

Sponsors: OSD + NDIA, other Govt. orgs. Steering Group: DoD, SEI, Defense industry SEI Proj. Mgr., 40+ authors, 60 Stakeholder/Reviewers

Source models: CMM SW v1.1, CMM SW v2.0d, EIA IS731, IPD v0.98

Products Continuous and staged representations of:

CMMI-SE/SW With and without IPPD

ARC (Assessment Requirements for CMMI) SCAMPI (Standard CMMI Assessment Method for Process Improvement) Training Common CMM framework (CCF) for easy extensibility



First Release of CMMI – August 1999 Numerous public comment periods Current Status

Version 1.02 of CMMI-SE/SW and CMMI-SE/SW/IPPD released Dec. 4,‘00

Version 1.02d of CMMI-SE/SW/IPPD/A (addition of the Acquisition discipline amplification)

Version 1.1 Dec. 2001 – next major release Training

CMMI Releases



Training

Introductory classes for SE/SW Staged Continuous

CMMI Intermediate concepts class For prospective CMMI teachers and

Lead Assessors

Lead Assessor training (SCAMPI)



Vocabulary Shift KPA is now Process Area (PA) Key Practices are now Practices “Software” dropped from many terms

“Organization’s Standard SW Process” (OSSP) is now “Organization’s Set of Standard Processes”

“Project’s defined software process” now simply “project’s defined process”

CAF -> ARC (Assessment Requirements for CMMI)

CBA-IPI -> SCAMPI (Standard CMMI Assessment Method for Process Improvement)

CMMI Terminology 1 of 2


New Terms in the CMMI Generic Goals and Practices Process architectures Process elements Product life cycle Organizational support environment Organizational measurement repository Project development plan Achievement/Target capability level profile

CMMI Terminology 2 of 2


CMMI Broadens ScopeOverview 1 of 4

1010

ProjectInitiation

99

SystemRequirements

Baselined

88

SystemRequirements

Allocated

77

ContractBook

Baselined &Approved

66

DesignReadiness

55

System TestReadiness

44

Ready forFieldTest

System Engineering Software Engineering

Integrated Product & Process Development

• Current CMM-SW covers Allocated SW Reqts -> SW Test

• Integrated CMMI-SE/SW covers Product Development

• Integrated CMMI-SE/SW/IPPD adds collaborative support


CMMI Is Tailorable Staged Model

Continuous Model Every PA [goal] can be at any Capability Level Raises the bar for high maturity organizations An organization can choose, for example, to be at

least at Level 3 for all PAs, at Level 4 for a small number, and at Level 5 for a select few

Overview 2 of 4

PerformedManaged

Quantitatively ManagedDefined

Optimizing


CMMIs Are Configurable CMMI has a modular design to fit the varied needs

of users, or to fit the needs of a single organization at various times in its improvement path

Overview 3 of 4

Disciplines

Today:

• Software

• System Engineering

• Integrated P&P Dev.

Future:

• Acquisition

• Hardware Engineering

• People\

CMMI-3CMMI-2

CMMI-1

Improvement Approach

Maturity

or

Capability

Pick a combination of disciplines

SEI can generate a custom CMMI,Training & Assessment Tool

Pick Staged orContinuous


Model Structural Terms

Generic Goals (GGs) Apply to all Process Areas GGs for Institutionalizing each Level

Generic Practices Define activities for each GG

Common Features Apply to Staged only ! GGs for

Commitment, Ability to Perform, Directing Implementation, Verification

Measurement replaced by Directing Implementation Activities (CF) is now Practices

Overview 4 of 4


CMM to CMMI Maturity Levels

24 Process Areas in Levels 2 - 5 (# PA’s)

L1: Initial -> L0: Not Performed L1: Performed L2: Repeatable(6) -> Managed (7) L3: Defined(7) -> Defined (11/13) L4: Managed(2) -> Quantitatively Managed

(2) L5: Optimizing(3) -> Optimizing (2)


Continuous CMMI Capability Levels - Model

Only

6 Levels of capability L0 Not Performed L1 Performed

Specific practices (activities) performed but institutionalizing generic practices are not

Level 2 - 5 same objective as CMM

Each PA may be implemented at its own Capability Level !


Process Areas – Managed Level

Similar to CMM, Requirements Management Project Planning Project Monitoring and Control (Project Tracking &

Oversight) Supplier Agreement Management (expanded from

Subcontract Management) Process and Product Quality Assurance (expanded SQA) Configuration Mgmt. (“Software” dropped)

Measurement is “promoted” and receives focus Measurement and Analysis (huge change; “[The

organization] develops and sustains a measurement capability in support of management information needs" )

L2: Managed 1 of 2


IPPD Changes – Managed Level

New Practice added to Project Planning Plan Stakeholder Involvement

New Practice added to Project Monitoring and Control

Monitor Stakeholder Involvement

New Generic Practice added to Directing Implementation (all Process Areas at Level 2)

Identify and Involve Relevant Stakeholders

L2: Managed 2 of 2


Process Areas – Defined Level

Similar to CMM Organizational Process Focus Organizational Process Definition Organizational Training (Training Program) Integrated Project Management (Integrated SW Mgmt

– risk management + Intergroup Coordination) New

Decision Analysis and Resolution (applies to planning, budgeting, architecture, design, supplier selection, test planning, logistics, project control, and production)

Risk Management (…identifies potential problems before they occur, so that risk-handling activities may be invoked as needed…)

L3: Defined 1 of 3


Engineering Process Areas CMM’s Software Product Engineering is replaced by 5 PA’s

Direct influence of Systems Engineering model The new PA’s are:

Requirements Development (produces requirements + preliminary functional architecture)

Technical Solution (transforms product requirements into a specification of physical components and interfaces)

Product Integration Verification (includes Peer Reviews; did we build the

product right?) Validation (did we build the right product?)

L3: Defined 2 of 3


IPPD Changes for Defined Level

Integrated Project Management given a collaborative focus – goals for:

Using Shared Vision Organizing Integrated Teams

New PA: Organizational Environment for Integration

Provide IPPD Infrastructure – share vision, integrate work environment

Manage People for Integration – leadership, incentives

New PA: Integrated Teaming The purpose of Integrated Teaming is to form and sustain an

integrated team for the development of products. Like Intergroup Coordination but much much more

L3: Defined 3 of 3


Process Areas at L4: Quantitatively

Managed

Organizational Process Performance Formerly a goal of QPM, now a PA to emphasize its

importance Provides the organizational data, baselines, and models to

support quantitative management of both the organization's and the projects' processes

Quantitative Project Management Combines CMM’s SQM (product) and QPM (process) “…quantitatively manage the project’s defined process to

achieve the project’s established quality and process performance objectives

Statistical control Quantitative quality goals and controls during the project


Process Areas at L5: Optimizing

Process Change Management and Technology Change Management have been restructured into Organizational Innovation and Deployment

Continually select and deploy incremental and innovative improvements Identification and evaluation of potential changes, prioritized using

quantitative performance measures produced by Organizational Process Performance (L4)

Technology here is to support, enhance or automate processes (the Technical Solution PA addresses the broader areas of technology)

Defect Prevention has been transformed into Causal Analysis and Resolution

Identifies causes of defects in the project’s defined process to take action to prevent them from occurring in the future

Broadened to address “other problems” besides defects, e.g. cycle time


Specifics & Generics in Staged Model

PA - Project Monitoring and Control SG1 Monitor Project Against Plan

SP 1.1 Monitor Project Planning Parameters SP 1.2 Monitor Commitments SP 1.3 Monitor Risks SP 1.4 Monitor Data Management SP 1.5 Monitor Stakeholder Involvement SP 1.6 Conduct Progress Reviews SP 1.7 Conduct Milestone Reviews

SG2 Manage Corrective Action to Closure SP 2.1 Analyze Issues SP 2.2 Take Corrective Action SP 2.3 Manage Corrective Action

Staged 1 of 3

Specific PracticesCorrespond to ActivitiesIn the CMM



GG2 Institutionalize a Managed Process GP 2.1 CO1 Establish an Organizational Policy GP 2.2 AB1 Plan the Process GP 2.3 AB2 Provide Resources GP 2.4 AB3 Assign Responsibility GP 2.5 AB4 Train People GP 2.6 DI1 Manage Configurations GP 2.7 DI2 Identify and Involve Relevant

Stakeholders GP 2.8 DI3 Monitor and Control the Process GP 2.9 VE1 Objectively Evaluate Adherence GP 2.10 VE2 Review Status with Higher-level Mgmt.

Staged 2 of 3

For all L2 Process Areas



GG3 Institutionalize a Defined Process In addition to GP 2.1 – 2.10 GP 3.1 (AB1) Establish a Defined

Process GP 3.2 (DI4) Collect Improvement

Information

Staged 2 of 3

For all L3, L4, & L5 Process Areas


Specifics & Generics in Continuous Model

PA - Project Monitoring and Control SG1 Monitor Project Against Plan

SP 1.1 Monitor Project Planning Parameters SP 1.2 Monitor Commitments SP 1.3 Monitor Risks SP 1.4 Monitor Data Management SP 1.5 Monitor Stakeholder Involvement SP 1.6 Conduct Progress Reviews SP 1.7 Conduct Milestone Reviews

SG2 Manage Corrective Action to Closure SP 2.1 Analyze Issues SP 2.2 Take Corrective Action SP 2.3 Manage Corrective Action

Continuous 1 of 3



GG1 Achieve Specific Goals GP 1.1 Identify Work Scope GP 1.2 Perform Base Practices

GG2 Institutionalize a Managed Process GP 2.1 CO1 Establish an Organizational Policy GP 2.2 AB1 Plan the Process GP 2.3 AB2 Provide Resources GP 2.4 AB3 Assign Responsibility GP 2.5 AB4 Train People GP 2.6 DI1 Manage Configurations GP 2.7 DI2 Identify and Involve Relevant Stakeholders GP 2.8 DI3 Monitor and Control the Process GP 2.9 VE1 Objectively Evaluate Adherence GP 2.10 VE2 Review Status with Higher-level Mgmt.

Continuous 2 of 3



GG3 Institutionalize a Defined Process GP 3.1 Establish a Defined Process GP 3.2 Collect Improvement Information

GG4 Institutionalize a Quantitatively Managed Process

GP 4.1 Establish Quality Objectives GP 4.2 Stabilize Subprocess Performance

GG5 Institutionalize an Optimizing Process GP 5.1 Ensure Continuous Process Improvement GP 5.2 Correct Common Cause of Problems

Continuous 3 of 3

Applies to each Process Area !As well as product faults


What you can learn from the Model Documents

Both Staged & Continuous model documents have: Model Structure Model Terminology Understanding the Model Using the Model

In addition to the PA definitions.


So what’s Changed from CMM SW v1.1, Really ?

Clarification of “Measurement” Expansion of Software Product Engineering Support for Risk Management and Decision

Making “Redundant” common feature definitions

have become “Generics” The “mitosis” of SQM / QPM into Process

Capability + Quant. Process Management PCM + TCM -> Organizational Innovation

and Deployment


And what else has changed?

SE, IPPD & (soon) Acquisition disciplines

Integration of CMMs into “one” model

Support for Staged and ContinuousModel support – ARC, SCAMPI,

Training, Transition Plan Thorough defined Transition Plan couched in legalese


Benefits of using the CMMI (1 of 2)

Better alignment with Total Product Mgmt. Focuses on alignment of process with business

goals and results Covers more of the development life-cycle Makes possible an integrated assessment to cover

multiple discipline-based assessments SW,SE,IPPD Evolutionary

Relatively smooth transition from CMM 1.1 to CMMI SW Staged

More precise definitions for measurement practices and Risk Management


Benefits of Using the CMMI (2 of 2)

Tailorable to organization’s needs(Staged and/or Continuous)

Clear and unambiguous at higher maturity levels

Intentional closer compatibility with emerging international standards

“A26. The method shall define a mechanism for translating assessment observations into associated process attribute outcomes in accordance with ISO/IEC TR 15504-2 [SPICE] clause 7.6.”


Risks of Using the CMMI

CMMI IPPD is not soup yet… V1.1 Release target 12/01 ( 2.25 yrs from Day 1 ) CMMI SW/SE training piloted SCAMPI pilots under way

Transitioning from CMM requires re-orientation Continuous or Staged ? When used for maturity verification the bar is

higher Linkage to ISO 9000 & 9000:2000 has been

done on a case by case basis – no consensus among ISO registrars at this time on ISO – CMMI equivalency


For more information http://www.sei.cmu.edu/cmmi/

CMMISM •General Information

•News and Communications •Publications and Transition Materials •Product Suite •Organizing Documents •Related Web Pages

cmmi (capability maturity model– integrated) overview dan weinberger mgr., software process...

Documents

cmmi rogoway

release of cmmi

d of cmmi

cmmi different

weinberger9 cmmi

cmmi seswippd

prospective cmmi teachers

cmmi generic goals