© 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon...

65
© 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE 17 February 2011 ® CMMI is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University. CMMI ® Version 1.3 and Beyond November 2010

Transcript of © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon...

Page 1: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

© 2010 Carnegie Mellon University

Mike PhillipsSoftware Engineering InstituteCarnegie Mellon UniversityExcerpted by Pat Wegerson forNorth Star INCOSE 17 February 2011

® CMMI is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.

CMMI® Version 1.3 and Beyond

November 2010

Page 2: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

2CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Organizations Are Complex Systems

Strategic Technological

StructuralHuman/

Cultural

Managerial

OrganizationalSystem

Input-output flow of materials, energy, information

InputsHuman,

Financial,Technological,

Material,Resources

OutputsProducts,Services

Adapted from Kast and Rosenzweig, 1972.

Page 3: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

3CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

What Is a Process?

A process is a set of interrelated activities, which transform inputs into outputs, to achieve a given purpose.

Result

Process Improvement flows from and extends the general management theories developed over the past ~30 years (Juran, Deming, Crosby, etc.)

Page 4: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

4CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

How Do You Want to Work?

Random motion – lots of energy, not much progress

No teamwork – individual effort

Frequent conflict

You never know where you’ll end up

Directed motion – every step brings you closer to the goal

Coordinated efforts

Cooperation

Predictable results

Processes can make the difference!

Page 5: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

5CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Symptoms of Process Failure

Quality Problems

• Too much rework

• No product documentation

• Functions that don’t work correctly

• Customer complaints after delivery

• Delivery of embarrassing products

• Wide variation in how people perform identical tasks

• Work with wrong versions of work products

No View to the Future

• No concern for process improvement

• No feedback on process effectiveness

• Program cancellation

Page 6: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

6CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Workforce Challenges

Generation Workforce(Millions)

% Workforce Workforce % Workforce Workforce % Workforce

Traditionalists(Born before 1946)

11.5 7.5% 45,625 6.7% 8,322 7.4%

Baby Boomers (1946 - 1964)

61.5 42.0% 438,971 64.5% 77,779 68.7%

Generation X (1965-1976)

43.5 29.5% 132,948 19.5% 17,581 15.5%

Generation Y (1977 -1989)

31.5 21.0% 62,676 9.2% 9,394 8.3%

Millennium (1990 - present)

51.0 0% 153 0% 0 0%

National(2005)

DoD(2006)

Civilian AT&L Workforce (2006)

Source: Anderson 2007, NDIA STEM Initiative Strategy Session

“DoD faces significant challenges related to mitigating the pending departure of its highly experienced and seasoned talent – the critical challenge”

Frank Anderson, Jr., Director, AT&L Human Capital Initiatives and President, Defense Acquisition University 2007

Page 7: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

7CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Characteristics of Effective Processes

trackable

measurable

simple

Well-defined gates

docu

men

ted

trained

supported

enforced

practiced

Page 8: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

8CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Process Definition Inputs

Strategic Plans,

Goals, Objectives

Policies

Process Descriptions,

Procedures,

Instructions

Asset Library Measurement Repository

Process Architecture

Process Scope

Process Needs

Page 9: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

9CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Signs that Processes Are Insufficient

Unmet commitments• Late delivery• Last minute crunches• Spiraling costs

Little or no management visibility• You’re always being surprised

Quality problems• Too much rework• Functions do not work correctly• Customer dissatisfaction post-delivery;

continuing high costs

Poor morale• Frustration• Is anyone in charge?

Mars Orbiter (Sep 1999)

A 125 million dollar orbiter was lost because one team used English units of measure while another used metric units of measure.

Page 10: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

10CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Process Improvement

Whether intentional or not, you already have processes in place. Are they the RIGHT processes?

Something is wrong…

… if no one uses the processes (except under duress)

… if everyone has their own interpretation of the process

… if you find you are always tailoring your processes

Page 11: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

12CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Common Misconceptions

I don’t need process, I have …

• Really good people

• Advanced technology

• An experienced manager

Process…

• Interferes with creativity

• = bureaucracy + regimentation

• Is only useful on large projects

• Hinders agility in fast-moving markets

• Costs too much

Page 12: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

13CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Threats to Process Improvement

Senior management problems

• Change or loss of sponsorship

• Inadequate support and resources

• Desire for quick fixes

• Unreasonable expectations

• Termination before institutionalization

• Inconsistent reinforcement

Middle management resistance

• “If it ain’t broke don’t fix it”

• “Flavor of the day”

• “This is another management initiative I can outlast”

Understand resistance before trying to eliminate it.It may be justified!

Page 13: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

14CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

How Can Process Help?

Process supports the goals of the company, enabling

• Repeatability

• Insight and oversight

• Control and tracking

• Measurement

• Improvement

• Training

• Transformation (via consistency, integration, coordination)

Inte

rcha

ngea

ble

part

s

Page 14: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

18CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

An Investment Is Required

DesiredState

TransitionState

PresentState

T i m e

Productivity

Page 15: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

19CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Commitment to improve must start at the top.

First understand the current process.

Structured change must become a way of life.

Improvement requires investment.

When failure occurs, focus on the process, not the people.

Institutionalizing improvements requires vigilance and periodic reinforcement.

SUCCESS

STATUS QUO

FAILURE

Critical Success Factors for Process Improvement

Page 16: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

© 2010 Carnegie Mellon University

What Is CMMI?

Page 17: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

21CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

“M” Is for Model

Models are simplified views of the real world.

CMMI

THE REAL WORLD

Process descriptions, models, and instantiations are below the level of detail of the CMMs.

Systems Engineering

Marketing

Integrated product teams

Technology

Organizationalculture

People issues

Maturity Levels

Process Areas

Practices

ProcessDescriptions

“All models are wrong, but some are useful.” - George Box

Page 18: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

22CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

CMMI in a Nutshell

CMMI is a collection of characteristics of effective processes that provides guidance for improving an organization’s processes and ability to manage the development, acquisition, and maintenance of products or services.

CMMI places proven approaches into a structure that• helps an organization examine the effectiveness of its processes• establishes priorities for improvement• helps implement these improvements

Improving processes for better products

Page 19: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

23CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

CMMI Product Suite

CMMI Modelso CMMI for Developmento CMMI for Acquisitiono CMMI for Services

SCAMPISM (Standard CMMI Appraisal Method for Process Improvement) o Class A (results in ratings)o Class B (deployment)o Class C (approach)

Trainingo Introduction to CMMIo Advanced training courses

Training

Models

SCAMPI

Page 20: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

25CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Five Reasons to Adopt CMMI

CMMI helps your organization to …

• Improve delivery of performance, cost, and schedule

• Collaborate with external stakeholders and integratetheir expectations into day-to-day activities

• Provide competitive world-class products and services

• Implement an integrated enterprise business and engineering perspective

• Use common, integrated, and improving processes for systems and software

Page 21: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

26CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Evolution of Process Capability

Process is informal and unpredictable

Project management system is in place; performance is repeatable

Software engineering and management processes are defined and integrated

Product and process are quantitatively controlled

Process improvement is institutionalized

Level Process Characteristics

Time/$/...

Time/$/...

Time/$/...

Time/$/...

Time/$/...

Predicted Performance

1

2

3

4

5

Page 22: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

27CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Example Chart from CMMI Level 5 Company: Multi-Performance Results Summary

We all do!

Measure Performance Result

Cost Firm fixed price upon acceptance of requirements specifications

Schedule • Not to exceed 8% of committed schedule• Weekly status reporting with ability to detect one-day schedule slip• Time in test and agility with rework time significantly less than customer

historical average

Quality • Acceptance test defects significantly lower than customer historical average

• Company will fix defects found in production use free for life of the product

Page 23: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

28CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Example Chart from CMMI Level 5 Company: Their Results vs. Industry Average

We all do!

Measure Performance Result (Industry vs. ML5 Company)

Schedule deviation >50% <10%

Number of defects in delivered product (Size: 100,000 source lines of code)

>100 <15

% of design and code inspected <100 100

Time to accept 100,000 SLOC product 10 months 5 weeks

% of defects removed prior to system test <60% >85%

% of development time fixing system test defects >33% <10%

Cost of Quality >50% <35%

Warranty on products ? Lifetime

Page 24: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

29CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

CMMI Models

Page 25: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

30CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Sequence of Models

41

Page 26: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

31CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

CMMI Models for Three Constellations

16 Core Process Areas, common to all

CMMI-DEVCMMI-DEV provides guidance for measuring, monitoring and managing development processes.

CMMI-SVCCMMI-SVC provides guidance for those providing services within organizations and to external customers.

CMMI-ACQCMMI-ACQ provides guidance to enableinformed and decisiveacquisition leadership.

Page 27: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

32CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

CMMI Core PAs

CMMICore PAs

CMMI-DEV CMMI-ACQ

CMMI-SVCCore PAs are common to all three CMMI models.

Core PAs include informative material that interprets the goals and practices for the model’s area of interest.

Page 28: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

33CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Process Area Components

Related Process Areas

Introductory Notes

Example WorkProducts

Subpractices

Expected Informative

Specific Goals (SG)

Generic Goals (GG)

Required

Purpose Statement

SpecificPractices

(SP)Generic

Practices(GP)

Generic PracticeElaborations

Legend

Process Area (PA)

Subpractices

Page 29: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

34CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

CMMI Model Structure

Institutionalization•Policies•Plans•Resources

•Responsibilities•Training•Managing Configurations

•Stakeholder Involvement•Monitoring and Control•Objective Evaluation

•Management Visibility•Defined Process•Improvement Information

CMMI Model Foundation (Core Process Areas)•Requirements Management•Project Planning•Project Monitoring & Control•Measurement & Analysis•Configuration Management•Process and Product QA

•Integrated Project Management•Risk Management•Decision Analysis & Resolution•Organizational Process Focus•Organizational Process Definition•Organizational Training

•Causal Analysis & Resolution•Org Process Performance•Org Performance Management

•Quantitative Project Mgmt

•Requirements Development•Supplier Agreement Mgmt•Technical Solution•Product Integration•Verification•Validation

CMMI-DEV•Capacity & Availability Management•Incident Resolution and Prevention•Supplier Agreement Mgmt•Service Continuity•Service Delivery•Service System Development•Service System Transition•Strategic Service Mgmt

CMMI-SVC CMMI-ACQ•Agreement Management•Acquisition Requirements Development•Acquisition Technical Mgt•Acquisition Validation•Acquisition Verification•Solicitation and Supplier Agreement Development

Benchmark Ratings•Goals•Process Areas

•Maturity Levels•Capability Levels

Incremental Frameworks forContinuous Process Improvement

Page 30: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

35CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Critical Distinctions Among Processes

performed vs. managed the extent to which the process is planned; performance is managed against the plan; corrective actions are taken when needed

managed vs. defined the scope of application of the process descriptions, standards, and procedures (i.e., project vs. organization)

Page 31: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

36CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Understanding Levels

Levels are used in CMMI to describe an evolutionary path for an organization that wants to improve the processes it uses to develop and maintain its products and services.

CMMI supports two improvement paths:

• continuous - enabling an organization to incrementally improve processes corresponding to an individual process area (or set of process areas) selected by the organization

• staged - enabling the organization to improve a set of related processes by incrementally addressing successive predefined sets of process areas

Page 32: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

37CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Staged Representation: PAs by Maturity Level

5 Optimizing

4 Quantitatively Managed

3 Defined

2 Managed

Continuous Process Improvement

Quantitative Management

Process Standardization

Basic Project Management

RiskRework

1 Initial

Level Focus QualityProductivity

Page 33: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

38CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Achieving Maturity Levels

Processes are ad hoc and chaotic

Adhere to policy; follow documented plans and processes; apply adequate resources; assign responsibility and authority; train people; apply CM; monitor, control, and evaluate process; identify and involve stakeholders; review with management

Tailor the project’s process from organization’sstandard processes; understand processes qualitatively; ensure that projects contribute to organization assets

Measure process performance; stabilize process and control charts; deal with causes of special variations

Prevent defects; proactively improve; insert and deploy innovative technology

ML1Initial

ML2Managed

ML3Defined

ML4 Quantitatively

Managed

ML5Optimizing

GG 2All ML2 PAs

GG 2 and GG 3All ML2 and ML3 PAs

GG 2 and GG 3All ML2, ML3, andML4 PAs

GG 2 and GG 3All ML2, ML3, ML4,and ML5 PAs

Page 34: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

40CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Achieving Capability Levels (CLs) for a Process Area

CL0 Not performed, incomplete

CL1Performed

Perform the work

CL2Managed

Adhere to policy; follow documented plans and processes, apply adequate resources; assign responsibility and authority; train people, apply CM, monitor, control, and evaluate process; identify and involve stakeholders; review with management

CL3Defined

Project’s process is tailored from organization’s standard processes; understand process qualitatively; process contributes to the organizations assets

A few GPs or SPs may be implemented

GG 1All SPs

GG 1 and GG 2All SPs

GG 1, GG 2, and GG 3All SPs

Page 35: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

42CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

CMMI for Development

Page 36: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

43CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

CMMI for Development Model

CMMI

Core PAs

Development-specific PAs

Shared PA (SAM)

16

5

1

22

CMMI-SVC CMMI-ACQ

CMMI-DEV

Core PAs that are present in all CMMI models.

Page 37: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

44CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Comparison of Models

Measure CMMI for Development CMMI for Acquisition

CMMI for Services

V1.1 Staged

V1.1Cont

V1.2 V1.3 V1.2 V1.3 V1.2 V1.3

Pages 715 710 560 468 428 423 531 506

Process Areas

25 25 22 22 22 22 24 24

Generic Goals

2 5 5 3 5 3 5 3

Generic Practices

12 17 17 13 17 13 17 13

Specific Goals

55 55 50 49 46 47 52 53

Specific Practices

185 189 173 167 161 163 182 181

Page 38: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

45CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Development-Specific PAs

Technical Solution

Requirements Development

Supplier Agreement

Management

(Shared with SVC)

Product Integration

Validation

Verification

CMMI Model Framework

(CMF)

16 Project, Organizational,

and Support Process Areas

Page 39: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

46CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

CMMI-DEV PAs by Maturity Level

Maturity Level Process Areas

5 Optimizing Causal Analysis and Resolution Organizational Performance Management

4 Quantitatively Managed Organizational Process PerformanceQuantitative Project Management

3 Defined

Decision Analysis and ResolutionIntegrated Project ManagementOrganizational Process DefinitionOrganizational TrainingOrganizational Process FocusProduct IntegrationRequirements DevelopmentRisk ManagementTechnical SolutionValidationVerification

2 Managed

Configuration ManagementMeasurement and AnalysisProject Monitoring and ControlProject PlanningProcess and Product Quality AssuranceRequirements ManagementSupplier Agreement Management

For the V1.3 release, there were

no changes that affected the DEV

PAs’ positioning by maturity level.

Page 40: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

47CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

CMMI-DEV PAs by Category

Process ManagementOrganizational Innovation and Deployment (OID)Organizational Process Definition (OPD)Organizational Process Focus (OPF)Organizational Process Performance (OPP)Organizational Training (OT)

SupportCausal Analysis and Resolution (CAR)Configuration Management (CM)Decision Analysis and Resolution (DAR)Measurement and Analysis (MA)Process and Product Quality Assurance (PPQA)

Project ManagementIntegrated Project Management (IPM)Project Monitoring and Control (PMC)Project Planning (PP)Quantitative Project Management (QPM)Requirements Management (REQM)Risk Management (RSKM)(+) Supplier Agreement Management (SAM)

EngineeringProduct Integration (PI)Requirements Development (RD)Technical Solution (TS) Validation (VAL) Verification (VER)For the V1.3 release, REQM was moved from

“Engineering” to “Project Management.”

Page 41: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

48CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Product Integration

SG 1: Prepare for Product IntegrationSP 1.1 Establish an Integration Strategy

SP 1.2 Establish the Product Integration EnvironmentSP 1.3 Establish Product Integration Procedures and

CriteriaSG 2: Ensure Interface Compatibility

SP 2.1 Review Interface Descriptions for Completeness

SP 2.2 Manage InterfacesSG 3: Assemble Product Components and Deliver the

Product

SP 3.1 Confirm Readiness of Product Components for Integration

SP 3.2 Assemble Product Components

SP 3.3 Evaluate Assembled Product Components

SP 3.4 Package and Deliver the Product or Product Component

Revised the purpose statement to ensure proper behavior instead of

proper function, thereby more explicitly including quality attributes and required

functionality.

Changed emphasis on integration sequence to an emphasis on

integration strategy.

Described an integration strategy and how it relates to an integration

sequence.

Page 42: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

49CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Requirements Development

SG 1: Develop Customer Requirements

SP 1.1 Elicit Needs

SP 1.2 Transform Stakeholder Needs into Customer Requirements

SG 2: Develop Product Requirements

SP 2.1 Establish Product and Product Component Requirements

SP 2.2 Allocate Product Component Requirements

SP 2.3 Identify Interface RequirementsSG 3: Analyze and Validate Requirements

SP 3.1 Establish Operational Concepts and Scenarios

SP 3.2 Establish a Definition of Required Functionality and Quality Attributes

SP 3.3 Analyze Requirements

SP 3.4 Analyze Requirements to Achieve Balance

SP 3.5 Validate Requirements

SP1.2 revised to add that customer requirements should be prioritized

based on their criticality to the customer and other stakeholders.

Broadened emphasis from “operational scenarios” to a more

balanced “scenarios (operational, sustainment, and development).”

Added a focus on architectural requirements.

Because “Quality attributes” needs to be considered in addition to “functionality,” SG3 and SP 3.2 were

revised.

Added informative material that requirements can be monitored

through development based on their criticality to the customer.

Page 43: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

© 2010 Carnegie Mellon University

V1.3 CMMI Model Updates: Core PAs

Page 44: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

54CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

CMMI Product Suite, Version 1.3

Version 1.3 focused on but was not limited to the following:

• High Maturity

• Appraisal efficiency

• Consistency across constellations

• Simplify the generic practices

Version 1.3 was change request (CR) driven.

Page 45: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

56CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

How Similar Are Core PAs?

Core process areas appear in all CMMI models; however...

• These process areas are not identical across all models.

• Informative material can be different so that users interpret goals and practices for the area of interest addressed by the model.

• Sometimes practices can be different in one model from another (e.g., Project Planning).

Page 46: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

57CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

V1.3 Model Architecture Changes

IPPD/TeamingRemoved the IPPD addition from CMMI-DEV and in its place added teaming practices from CMMI-ACQ and CMMI-SVC. These practices are not optional.

AmplificationsRemoved the “amplification” model component.

CMMI-ACQRenamed the “Acquisition” process area category to be “Acquisition Engineering.”

Moved AM and SSAD from the Acquisition PA category to the Project Management PA category.

CMMI-DEVMoved REQM from the Engineering PA category to the Project Management PA category.

Page 47: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

58CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

V1.3 Changes to GGs, GPs, and GP Elaborations

Positioned generic goals, generic practices, and GP elaborations in one central location as the first section of Part 2 in all three models.

Simplified GG1 to make it more readable.

Renamed GP 2.6 to “Control Work Products.”

Added “selected work products” to the GP 2.9 statement.

Simplified the GP 3.2 statement to replace “collect work products, measures, measurement results, and improvement information” with “collect process related experiences.”

Eliminated GG4 and GG5.

Page 48: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

59CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Core PAs by Maturity Level

Causal Analysis and ResolutionOrganizational Performance Management

5 Optimizing

4 Quantitatively Managed

3 Defined

2 Managed

ContinuousProcess Improvement

QuantitativeManagement

ProcessStandardization

BasicProjectManagement

Organizational Process PerformanceQuantitative Project Management

Decision Analysis and ResolutionIntegrated Project Management Organizational Process DefinitionOrganizational Process FocusOrganizational Training Risk Management

Configuration ManagementMeasurement and AnalysisProject Monitoring and ControlProject PlanningProcess and Product Quality AssuranceRequirements Management

RiskRework

1 Initial

Process AreasLevel Focus QualityProductivity

Page 49: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

60CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Core PAs by Category

Process ManagementOrganizational Process Definition (OPD)Organizational Process Focus (OPF)Organizational Performance Management (OPM)Organizational Process Performance (OPP)Organizational Training (OT)

SupportCausal Analysis and Resolution (CAR)Configuration Management (CM)Decision Analysis and Resolution (DAR)Measurement and Analysis (MA)Process and Product Quality Assurance (PPQA)

Project and Work ManagementIntegrated Project Management (IPM)Project Monitoring and Control (PMC)Project Planning (PP)Quantitative Project Management (QPM)Requirements Management (REQM)Risk Management (RSKM)(+) Supplier Agreement Management (SAM)

SAM is a shared PA instead of a core PA.

“Work” is substituted for “Project” in CMMI-SVC titles.

Page 50: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

66CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

New Informative Material

Update selected process areas to provide interpretation of practices for organizations with respect to the following topics:

• Agile methods

• Quality attributes (i.e., non functional requirements or “ilities”)

• Allocation of product capabilities to release increments

• Product lines

• System of systems

• Architecture-centric development practices

• Technology maturation

• Customer satisfaction 

Page 51: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

71CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

V1.3 Changes to High Maturity PAs

Many of the most significant changes to CMMI models as part of Version 1.3, are the changes to the high maturity process areas (CAR, OPM, OPP, and QPM).

These process areas are core process areas, but we’ve focused on these four over the others because of their significance in this release.

Page 52: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

72CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

High Maturity Changes for V1.3

Terminology Confusion

• Common Cause (Statistical versus Quantitative Techniques)

• Process Models and Process Modeling

• Business Objectives

• Subprocesses

Requirements implied versus explicit/ Explanations not central or consistent

• Model/ Audit Criteria/ Presentations (Healthy Ingredients)/ UCHMP

Perceptions

• Customers – ML 5 is expensive – no better than 3

• Industry – ML 5 is NOT RIGHT for every business

High Maturity in ALL constellations

• Examples are focused on Development

Page 53: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

73CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

High Maturity Restructuring for V1.3

• Insufficient link between process improvement, business objectives, and performance

• Clarify distinction between ML4 and ML5

• Eliminate GG4 and GG5

• Make CAR more relevant for organizational benefit

Page 54: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

75CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Causal Analysis and Resolution

SG 1: Determine Causes of Selected Outcomes

SP 1.1 Select Outcomes for Analysis

SP 1.2 Analyze Causes

SG 2: Address Causes of Selected Outcomes

SP 2.1 Implement Action Proposals

SP 2.2 Evaluate the Effect of Implemented Actions

SP 2.3 Record Causal Analysis Data

Used “outcomes” instead of “defects and problems.”

Added examples for service organizations and for selecting

outcomes for analysis.

Added subpractices in SP 1.1 for defining the problem, and in SP 2.2

for following up when expected results did not occur.

Added more information about how PPMs can be used.

Added emphasis on prevention and reducing recurrence.

Page 55: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

76CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Organizational Performance Management

SG 1: Manage Business Performance

SP 1.1 Maintain Business Objectives

SP 1.2 Analyze Process Performance Data

SP 1.3 Identify Potential Areas for Improvement

SG 2: Select Improvements

SP 2.1 Elicit Suggested Improvements

SP 2.2 Analyze Suggested Improvements

SP 2.3 Validate Improvements

SP 2.4 Select and Implement Improvements for Deployment

SG 3: Deploy Improvements

SP 3.1 Plan the Deployment

SP 3.2 Manage the Deployment

SP 3.3 Evaluate Improvement Effects

Renamed the PA to be Organizational Performance

Management (OPM).

Added a new goal about managing business performance using

statistical and other quantitative techniques.

Provided more information about how improvements can be selected

for deployment.

More explicitly described and discussed using process performance models.

Clarified that not all improvement validations include piloting.

Page 56: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

77CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Organizational Process Performance

SG 1: Establish Performance Baselines and Models

SP 1.1 Establish Quality and Process Performance Objectives

SP 1.2 Select Processes

SP 1.3 Establish Process Performance Measures

SP 1.4 Analyze Process Performance and Establish Process Performance Baselines

SP 1.5 Establish Process Performance Models

Re-ordered SPs, moving the old SP 1.3 (Establish Quality and Process Performance Objectives) to SP 1.1

Revised SP 1.4 to include process performance analysis and

assessment of subprocess stability.

Revised SP 1.5 to note that under certain circumstances, projects may need to create their own process

performance models.

Clarified the relationship of OPP to other high maturity process areas.

Page 57: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

78CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Quantitative Project Management

SG 1: Prepare for Quantitative Management

SP 1.1 Establish the Project’s Objectives

SP 1.2 Compose the Defined Process

SP 1.3 Select Subprocesses and Attributes

SP 1.4 Select Measures and Analytic Techniques

SG 2: Quantitatively Manage the Project

SP 2.1 Monitor the Performance of Selected Subprocesses

SP 2.2 Manage Project Performance

SP 2.3 Perform Root Cause Analysis

Restructured QPM so that SG1 focuses on preparation and SG2 focuses on managing the project.

Added guidance about using process performance baselines and

process performance models.

Define quantitative management in the glossary to include statistical

management and use that definition for use of the terms

throughout QPM.

Removed the practice about applying statistical methods to

understand variation to reduce the over-emphasis on control charts.

Added new practices about managing performance and

performing root cause analysis.

Page 58: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

© 2010 Carnegie Mellon University

CMMI Adoption

Page 59: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

80CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

72

3012

42

760

1885

355

0

200

400

600

800

1000

1200

1400

1600

1800

2000

2200

2400

2600

2800

3000

3200

3400

3600

Africa Asia Australia Europe North America South America

Nu

mb

er o

f A

pp

rais

als

Number of Appraisals Reported to the SEI by Continent

Page 60: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

81CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

* Red/Italic country name: New additions with this reporting since March 2010

Countries Where Appraisals Have Been Performed and Reported to the SEI

Argentina Australia Austria Bahrain Bangladesh Belarus Belgium BrazilBulgaria Canada Chile China Colombia Costa Rica Czech Republic DenmarkDominican Republic Egypt Finland France Germany Greece Guatemala Hong KongHungary India Indonesia Ireland Israel Italy Japan Korea, Republic OfLatvia Lithuania Luxembourg Macedonia Malaysia Mauritius Mexico MoroccoNepal Netherlands New Zealand Norway Pakistan Panama Paraguay PeruPhilippines Poland Portugal Romania Russia Saudi Arabia Singapore SlovakiaSouth Africa Spain Sri Lanka Sweden Switzerland Taiwan Thailand TunisiaTurkey Ukraine United Arab Emirates United Kingdom United States Uruguay Viet Nam

Page 61: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

82CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

CMMI Adoption Has Been Broad

34 countries with > 10 appraisals(as of Sept 2010):

USA 1719 China 1475 India 576 Japan 324 Spain 198 France 183 Korea (ROK) 176 Brazil 167

Taiwan 147 U.K. 118Mexico 104 Germany 80 Argentina 79

Malaysia 74Canada 62 Egypt 52 Italy 46Colombia 43 Chile 43Thailand 41

And - Australia, Pakistan, Philippines,Singapore, Israel, Hong Kong, Viet Nam, Turkey, Netherlands, Portugal,Sri Lanka, Ireland, Peru and Russia

http://www.sei.cmu.edu/cmmi/casestudies/profiles/cmmi.cfm

Is the source for these statistical analyses.

Estimated 1.2 million people work in organizations that have had at least one SCAMPI A appraisal since April 2002.

• There were SCAMPI A appraisals reported from 71 countries.

• Approximately 75% of adopters are commercial organizations.

• Services; 1/6 Manufacturing

• Approximately 2/3 of adopters in the US are contractors for military/government or are government.

25 or fewer13.6%

26 to 5015.6%

51 to 7512.8%

76 to 1008.9%

101 to 20019.8%

201 to 3009.0%

301 to 5007.4%

501 to 10006.8%

1001 to 20003.7%

2000+2.5%

201 to 2000+23.8%

1 to 10058.2%

Manufacturing16.3%

Services71.1%

Retail Trade0.3%

Wholesale Trade0.1%

Transportation, Communication, Electric, Gas

and Sanitary Services3.6%

Finance, Insurance and Real Estate5.5%

Public Administration (Including Defense)

3.2%

Fabricated Metal Products0.2%

Primary Metal Industries0.3%

Industrial Machinery And Equipment

0.7%

Electronic & Other Electric Equipment

10.4%

Instruments And Related Products

1.0%

Transportation Equipment2.4%

Other Manufacturing Industries

1.2%Health Services

1.3%

Other Services10.7%

Engineering & Management Services24.2%

Business Services35.0%

Page 62: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

83CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

CMMI Transition StatusReported to the SEI as of 10-31-10

Training

Introduction to CMMI V1.2 120,838

Intermediate Concepts of CMMI 3,238

Understanding CMMI High Maturity Practices 636

Introduction to CMMI V1.2 Supplement for ACQ 1,325

Introduction to CMMI V1.2 Supplement for SVC 2,361

Introduction to CMMI for Services V1.2 314

Certifications

Introduction to CMMI V1.2 Instructors 408

CMMI-ACQ V1.2 Supplement Instructors 66

CMMI-SVC V1.2 Supplement Instructors 131

Introduction to CMMI for Services V1.2 Instructors 23

SCAMPI V1.2 Lead Appraisers 466

SCAMPI V1.2 High Maturity Lead Appraisers 142

CMMI-ACQ V1.2 Lead Appraisers 72

CMMI-SVC V1.2 Lead Appraisers 147

Page 63: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

85CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Number of Appraisals Conducted by YearReported as of 10-31-10

0

200

400

600

800

1000

1200

1400

1600

SPA CBAIPI(Discontinued after 12/31/2005) SCAMPI v.X ClassA

Page 64: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

86CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Continuous Improvement

Certification of our process improvement professionals is appropriate and achievable

• Lead Appraisers first

• Instructors next

• CMMI consultants/practitioners in the future

Improved architecture allows process improvement model expansion.

• Extensions of the lifecycle

o allows coverage of more of the enterprise or potential partnering organizations

o adapts model features to fit non-developmental efforts

Page 65: © 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE.

87CMMI V1.3 and BeyondPhillips – November 2010

© 2010 Carnegie Mellon University

Transition…

We are providing an on-line upgrade course for V1.3 as we did for V1.2.

• Users make the transition by taking the upgrade course.

During a period of one year, organizations may use either V1.2 or V1.3 models for their appraisals.

Appraisals using V1.2 models will be valid for the full 3 years.