[cmm-cmmi].cmmi.-.a.comprehensive.overview.(ppt)

CMMI: A Comprehensive Overview

Rushby Craig (801) 775-5739

Software Technology Support Center

Bruce Allgood (801) 777-3207

Computer Resources Support Improvement Program

Hill AFB, UT

2CMMI User Group Nov 13, 2001

Agenda

• Project History

• CMMI Structure

• Comparisons with SW-CMM v1.1, SE-CMM, andEIA/IS 731_

• Process Areas Overview

• Assessment Methodology

• Training


What Model do I use?

• Historically: Depends on the discipline that you wantto model.–Software Engineering–Systems Engineering–Software Acquisition–Systems Security–etc.


What is a CMM?

• Capability Maturity Model:A reference model of mature practices in a specifieddiscipline, used to assess a group’s capability to performthat discipline

• CMMs differ by–Discipline (software, systems, acquisition, etc.)–Structure (staged versus continuous)–How Maturity is Defined (process improvement path)–How Capability is Defined (institutionalization)

• “Capability Maturity Model®” and CMM® are used by theSoftware Engineering Institute (SEI) to denote a particularclass of maturity modelsCapability Maturity Model®, CMM®, CMM Integration, and CMMI are service marks and registered trademarks ofCarnegie Mellon University


Commonly Used CMMsSoftware CMM staged software development

System Engineering CMM continuous system engineering

System Engineering Capability Model continuous system engineering

Software Acquisition CMM staged software acquisition

System Security Engineering CMM continuous security engineering

Personal Software Process staged individual softwaredevelopment

FAA-iCMM continuous software engineering,systems engineering,and acquisition

IPD-CMM continuous integrated productdevelopment

People CMM staged workforce

SPICE Model continuous software development


So Many Models, So Little Time

SoftwareCMM

SoftwareCMM

SystemsSecurity

Engr CMM

SystemsSecurity

Engr CMM

SystemsEngrCMM

SystemsEngrCMM

PeopleCMM

PeopleCMM

ZZZCMMZZZCMM

FAAiCMMFAA

iCMM

IPDCMMIPD

CMMSoftware

AcqCMM

SoftwareAcqCMM

EIA 731EIA 731

•Different structures,formats, terms, waysof measuring maturity•Causes confusion,especially when usingmore than one model•Hard to integratethem in a combinedimprovement program•Hard to use multiplemodels in supplierselection


Mike Phillips

Bridging the Divide

Systems Software• Systems and software

disciplines havetraditionally not been wellintegrated

• The importance of softwarein systems has increaseddramatically–Example: % of

requirements allocated tosoftware: *» B-2 -- 65%» F-22 -- 80%

• The DOD has emphasizedthe need to make thesystems/software interfacemore seamless * Source: Standish Group Chaos Report

CMMI


CMMI to the Rescue!

• Integrates systems and software disciplines into oneprocess improvement framework.

• Provides a framework for introducing new disciplinesas needs arise.


The CMMI Project

• DoD sponsored collaborationbetween industry, Government, academia

• Over 100 people involved• 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• Lockheed Martin• Motorola• Northrop Grumman• Pacific Bell• Q-Labs• Raytheon• Reuters• Rockwell Collins• SAIC• Software Productivity Consortium• Sverdrup Corporation• Thomson CSF• TRW


Air Force Involvement in CMMI ProjectAir Force involved in development of CMMI from beginning

Steering Group Co-chair: Phil Babel, Ajmel Dulai, Mike Nicol (ASC)

Product Development Team (PDT) members

(4-6 PE 25% time CRSIP/STSC)

– John Kordik AFMC/ASC - (Engineering PAs, IPPD, Editor)– Lt. Col Joe Jarzombek CRSIP (Test & Evaluation Team)

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


CMMI Product Suite

• Models–Disciplines

»Software»Systems»IPPD»Acquisition (coming

soon!)–Representations

»Staged»Continuous

• Training–Model

»Introduction to CMMI»Intermediate Concepts

–Instructor Training–Lead Assessor

• Appraisal methods–Assessment Requirements

for CMMI (ARC)–SCAMPI Method

Description Document(MDD)


CMMI Models

Source Models

• Capability MaturityModel for Software V2,draft C (SW-CMM V2C)

• EIA Interim Standard731, System EngineeringCapability Model (SECM)

• Integrated ProductDevelopment CapabilityMaturity Model, draftV0.98 (IPD-CMM)

CMMI-SE/SW

Staged

Representation

CMMI-SE/SW

Continuous

Representation

• Combined System Engineering /Software Engineering model

• Can be applied to:– Just the software engineering

projects in an organization– Just the system engineering

project in an organization– Both– IPPD can be used in either/both


Comparing ModelRepresentations

PA PA

Continuous Staged

ML 1

ML2

ML3

ML4

ML5

Cap

abili

ty

0

1 2

3

4

5

OrganizationProcess

PA


Why Do We Have Two Representations?

• Source Model Heritage–Software CMM--Staged–SECM--Continuous–IPD CMM--Hybrid

• Proponents for each type of representation were partof CMMI product development team.

• Selecting a single representation approach became“too hard”.

• A compromise was made to initially support tworepresentations of the model with equivalent content.


Advantages of the StagedRepresentation

• Provides a roadmap for implementing:–groups of process areas–sequencing of implementation

• Familiar structure for those transitioning from theSW-CMM


Advantages of the ContinuousRepresentation

• Provides maximum flexibility for focusing on specificprocess areas according to business goals andobjectives.

• Familiar structure for those transitioning from thesystems engineering community.


Model Measures

Release PAs/ Goals/ Activities/FAs Themes* Practices**

SW-CMM V1.1 18 52 316

SW-CMM V2C 19 62 318

EIA/IS 731 19 77 383

IPD-CMM V0.98 23 60 865

CMMI V1.0 SE/SW 22 70 417

CMMI V1.1 SE/SW/IPPD24 76 460

* Ratable components

** Key to implementation effort

61 1566199


Decision Analysis and Resolution Requirements Development

System Product Deliveries

Project Planning

Supplier Agreement Management

Product Control

Products

Outcome & Feedback

ProductVerification

ValidationMeasurementand Analysis

Deficiencies

Directives, Constraints,

Contracting Activity Planning

Requirements DefinitionBudgeting Priority

Assessment & Certification

Integrated ProjectManagement

Project Monitoringand Control

Risk Management

TechnicalSolution

ProductIntegration

RequirementsManagement

ConfigurationManagement

Quality Assurance

Program ManagementTechnical Execution

ProcessFocus

ProcessDefinition Training

QuantitativeMgmt

ProcessPerformance

Innovation andDeployment

Process Maturation

Organizational Process Management

Mission Area Planning

ConcurrentFront-EndActivities

Causal Analysisand Resolution

Life Cycle Relationships

Mission Shortfalls


Topics

• The structure of the CMMI documents

• The structure of the CMMI Continuous representation

• The structure of the CMMI Staged representation

• Summary


Organization of Continuous Model-1

• Six chapters provide an overview–The Introduction–Structure of the Model–Model Terminology–Capability Level and Generic Model components–Understanding the Model–Using the Model


Organization of Continuous Model-2

• Process areas»Process management»Project Management»Engineering»Support

• Appendixes»References»Acronyms»Glossary»Required and expected Model Elements»CMMI Project Participants»Equivalent Staging


Organization of Staged Model-1

• Six chapters provide an overview–The Introduction–Structure of the Model–Model Terminology–Maturity Levels, Common Features, and Generic

Practices–Understanding the Model–Using the Model


Organization of Staged Model-2

• Process areas»Maturity Level: 2 Managed»Maturity Level: 3 Defined»Maturity Level: 4 Quantitatively Managed»Maturity Level: 5 Optimizing

• Appendixes»References»Acronyms»Glossary»Required and expected Model Elements»CMMI Project Participants


Model Components

• Process Areas–Specific Goals–Specific Practices–Generic Goals–Generic Practices

»Typical Work Products»Sub-practices»Notes»Discipline Amplifications»Generic Practice Elaborations»References


CMMI StructureOne Model, Two Representations

Maturity Level 5 OID, CAR

Maturity Level 4 OPP, QPM

Maturity Level 3 REQD, TS, PI, VER, VAL, OPF, OPD, OT, IPM, RSKM, DAR

Overview Introduction Structure of the Model Model Terminology Maturity Levels, Common Features, and Generic Practices Understanding the Model Using the Model

Maturity Level 2 REQM, PP, PMC, SAM, MA, PPQA, CM

Appendixes

Engineering REQM, REQD, TS, PI, VER, VAL

Project Management PP, PMC, SAM IPM, RSKM, QPM

Process Management OPF, OPD, OT, OPP, OID

Process Management PAs - Goals - Practices

Support CM, PPQA, MA, CAR, DAR

Appendixes

CMMI-SE/SWStaged

Overview Introduction Structure of the Model Model Terminology Capability Levels and Generic Model Components Understanding the Model Using the Model

CMMI-SE/SWContinuous


Topics

• Structure of the CMMI documents

• The structure of the CMMI continuous representation

• The structure of the CMMI staged representation

• Summary


Process Capability

Process capability may be represented by a set ofpoints in two dimensions.–the process dimension

»“What” you do–the capability dimension

»“How well” you do it

Cap

abili

ty(H

ow

wel

l)

Process (What you do)


The Process Dimension

• The values on this axis describe what processes(described within Process Areas) you perform.

Process

ProcessArea 1

ProcessArea n

ProcessArea 2

ProcessArea 3

Cap

abili

ty


Process Areas

•Process Areas (PAs) are a cluster of relatedpractices.

•They are the major building blocks in establishingprocess capability.

•Example PA: “Requirements Management”


Requirements ManagementRequirements DevelopmentTechnical SolutionProduct IntegrationVerificationValidation

Engineering

ProjectManagement

Project PlanningProject Monitoring and ControlSupplier Agreement ManagementIntegrated Project Management(IPPD)Integrated Teaming (IPPD)Risk ManagementQuantitative Project Management

Organizational Process FocusOrganizational Process DefinitionOrganizational TrainingOrganizational Process PerformanceOrganizational Innovation and Deployment

ProcessManagement

Configuration ManagementProcess and Product Quality AssuranceMeasurement and AnalysisCausal Analysis and ResolutionDecision Analysis and ResolutionOrganizational Environment for Integration (IPPD)

Support

Continuous Organization of PAsCategory Process Area


The Capability Dimension -1

• The values on this axis describe how well youperform process (called Capability Levels).

Process not performed

Cap

abili

ty

Process

ProcessArea 1

ProcessArea n

ProcessArea 2

ProcessArea 3


The Capability Dimension -2

• The values on this axis describe how well youperform process (called Capability Levels).

Cap

abili

ty

Process

ProcessArea 1

ProcessArea n

ProcessArea 2

ProcessArea 3

Process performed well andcontinuously improved

Process not performed


Capability Levels

• A capability level is a well-defined evolutionaryplateau describing the capability of a processarea.

• There are six capability levels.

• Each level is a layer in the foundation forcontinuous process improvement.

• Thus, capability levels are cumulative, i.e., ahigher capability level includes the attributes ofthe lower levels.


The Capability Levels

5 Optimizing

4 Quantitatively Managed

3 Defined

2 Managed

1 Performed

0 Incomplete


Capability Levels are Cumulative

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


Representing Process Capability

• The capability of a implemented process can berepresented by a bar.

Process

Cap

abili

ty

This point represents a higher level of capabilitythan this pointin a specificprocess area

3

2

1

0

Process Area n


An Example OrganizationalProcess Capability Profile

P r o c e s sRM PP PMC etc

5

4

3

2

1

0

C a

p a

b i

l i t

y


Realizing These Concepts inthe CMMI Continuous Model

• Goals and Practices are the model elements used torealize the values on both the capability and processdimensions.–Goal

»A high level statement of the outcome to be achievedby effective implementation of a group of practices.

–Practice»A description of an action that is necessary

to enact a key element of a process area.


There Are Two Types ofGoals and Practices

• Specific Goals and Specific Practices– realize the process dimension– therefore, they apply to a particular Process

Area

• Generic Goals and Generic Practices– realize the capability dimension– therefore, they apply across all Process Areas


Example: Specific Goal andSpecific Practice

• Specific Goal (from Requirements ManagementPA)

–Requirements are maintained and accuratelyreflected in project plans, activities andproducts.

• Specific Practice (from RequirementsManagement PA)

–Maintain the traceability of requirements to theirsource requirements.


Example: Generic Goal andGeneric Practice

• Generic Goal (from Capability Level 1)

– The implemented process achieves the specificgoals of the process area.

• Generic Practice (from Capability Level 1)

– Perform the basic activities of the process todevelop work products and provide services toachieve the specific goals of the process area.


Structure of the CMMIContinuous Representation

GenericGoals

& Generic Practices

GenericGoals

& Generic Practices

SpecificGoals

&Practices

SpecificGoals

& Practices


Summary

• CMMI models were developed with broadparticipation and review.

• Process Areas identify “what you do.”

• Capability Levels identify “how well you do it.”


Topics

• Structure of the CMMI documents

• The structure of the CMMI Continuous representationdocument

• The Structure of the CMMI Staged representation

• Summary


Structure of the CMMI StagedRepresentation

Maturity Level

Process Area Process Area Process Area

Generic Goals Specific Goals

Commitmentto Perform

Ability toPerform

DirectingImplementation Verification

CommonFeatures

Commitment to Perform: creates policies and secures sponsorship for process improvement effortsAbility to Perform: ensures that the project and/or organization has the resources it needs to pursue process improvementDirecting Implementation: collects, measures, and analyzes data related to processesVerification: verifies that the projects and/or organization’s activities conform to requirements, processes, and procedures

Commitment to Perform: creates policies and secures sponsorship for process improvement effortsAbility to Perform: ensures that the project and/or organization has the resources it needs to pursue process improvementDirecting Implementation: collects, measures, and analyzes data related to processesVerification: verifies that the projects and/or organization’s activities conform to requirements, processes, and procedures

Generic Practices Specific Practices


Maturity Levels

• A maturity level is a well-defined evolutionaryplateau on the path to becoming a matureorganization.

• There are five maturity levels.

• Each level is a layer in the foundation forcontinuous process improvement.


The Maturity Levels

Process unpredictable,poorly controlled andreactive

Process characterized forprojects and is oftenreactive

Process characterizedfor the organizationand is proactive

Process measuredand controlled

Focus on processimprovement

Optimizing

QuantitativelyManaged

Defined

Initial

Managed

Optimizing

Defined

1

2

3

4

5


Maturity LevelsCannot Be Skipped

• A level provides a necessary foundation foreffective implementation of processes at thenext level.

– Higher level processes are easily sacrificedwithout the discipline provided by lowerlevels.

– The effect of innovation is obscured in anoisy process.

• Higher maturity level processes may beperformed by organizations at lower maturitylevels, with risk of not being consistentlyapplied in a crisis.


Process Areas

•Process Areas (PAs) are clusters of relatedpractices performed collectively to achieve a set ofgoals.

•They are the major building blocks in establishingthe process capability of an organization.

•Each process area has been defined to resideat a given maturity level.


PA’s by Maturity Level

Organizational Innovation and DeploymentCausal Analysis and Resolution5 Optimizing

4 Quantitatively Managed

3 Defined

2 Managed

Continuous process improvement

Quantitativemanagement

Processstandardization

Basicprojectmanagement

Organizational Process PerformanceQuantitative Project Management

Requirements DevelopmentTechnical SolutionProduct IntegrationVerificationValidationOrganizational Process FocusOrganizational Process DefinitionOrganizational Training Integrated Project ManagementRisk ManagementDecision Analysis and ResolutionOrganizational Environment for IntegrationIntegrated Teaming

Requirements ManagementProject PlanningProject Monitoring and ControlSupplier Agreement ManagementMeasurement and AnalysisProcess and Product Quality AssuranceConfiguration Management

1 Initial

Process AreasLevel Focus

(IPPD)(IPPD)


Example: Specific Goal andSpecific Practice

• Specific Goal (from Requirements ManagementPA)

–Requirements are maintained and accuratelyreflected in project plans, activities andproducts.

• Specific Practice (from RequirementsManagement PA)

–Maintain the traceability of requirements to theirsource requirements.


Example: Generic Goal andGeneric Practice

• Generic Goal (from Maturity Level 2)

–Institutionalize a Managed Process.

• Generic Practice (from Maturity Level 2)

–Establish an Organizational Policy.


Common Features

Common features are a means of categorizingGeneric practices.

– Commitment to perform:establishment of management policies

– Ability to perform:establishment and maintenance of plans,resources, assigned responsibility andauthority, and training

– Directing implementation:measurement, control, and performance practices

– Verification:ensure implementation and compliance


Another way to look atCommon Features -1

•Common feature categories are very similar acrossprocess areas.

•They are referred to as Institutionalization CommonFeatures because they:

– ensure the process areas are effective,repeatable and lasting

– provide needed infrastructure support


Common Feature Examples - 1from Requirements Management Process Area

•Commitment to perform:

–Establish and maintain a writtenorganizational policy for planning andperforming the Requirements Managementprocess.

•Ability to perform:

–Train the people performing or supportingthe Requirements Management process asneeded.


Common Feature Examples - 2from Requirements Management Process Area

• Directing implementation:

– Place designated work products of theRequirements Management Process underappropriate levels of configurationmanagement.

• Verification:

– Review the activities, status, and results ofthe implemented RequirementsManagement Process with managementand resolve issues.


Summary-1

• There is one CMMI Model with two representations,Staged and Continuous.

• The Material in both representations is the same justorganized differently.

• Each representation provides different ways ofimplementing processes

• The CMMI model should be applied using intelligence,common sense, and professional judgment.


Summary-2• Continuous

–Flexible in its application so the organization canchoose which areas to emphasize.

–Provides equivalent staging to compare to stagedrepresentation.

• Staged–Structured for implementation based on proven

grouping and ordering of processes.


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

SW-CMM v1.1 vs. CMMIProcess Areas

Defect Prevention Causal Analysis and ResolutionTechnology Change Mgmt Organizational Innovation & DeploymentProcess Change Management

Quantitative Process Mgmt Organizational Process PerformanceSoftware Quality Mgmt Quantitative Project Management

Organization Process Focus Organization Process Focus Organization Process Definition Organization Process DefinitionTraining Program Organizational TrainingIntegrated Software Mgmt Integrated Project Management

Risk ManagementSoftware Product Engr Requirements Development

Technical SolutionProduct Integration

Intergroup Coordination VerificationPeer Reviews Validation

Decision Analysis and Resolution

Requirements Management Requirements ManagementSoftware Project Planning Project PlanningSoftware Project Tracking & Oversight Project Monitoring and ControlSoftware Subcontract Mgmt Supplier Agreement ManagementSoftware Quality Assurance Product & Process Quality AssuranceSoftware Configuration Mgmt Configuration Management

Measurement and Analysis

LEVEL 5OPTIMIZING

LEVEL 4MANAGED

LEVEL 3DEFINED

LEVEL 2REPEATABLE

60

SW-CMM v1.1 Common Features CMM I Common FeaturesCommitment to Perform Commitment to Perform

Establish an Organizational Policy Establish an Organizational PolicyAbility to Perform Ability to Perform

P lan the ProcessProvide Resources Provide ResourcesAssign Responsibility Assign ResponsibilityTrain People Train People

Activities PerformedP lan the Process (Specific Practices)Perform the ProcessMonitor and Control the Process

Directing ImplementationCollaborate with Rel. StakeholdersManage ConfigurationsMonitor and Control the Process

Measurement & AnalysisMeasure the ProcessAnalyze the Measurements

Verifying Implementation Verifying ImplementationReview with Org. Management Review with [Higher-Level] MgtReview with Project ManagementObjectively Verify Adherence Objectively Verify Adherence

SW-CMM v1.1 vs. CMMICommon Features

61


CMMI Improvements Over theCMM

• Emphasis on measurable improvements to achievebusiness objectives.

• Process areas have been added to place moreemphasis on some important practices:–Risk Management–Measurement and Analysis–Engineering Process Areas–Decision Analysis


CMMI-SE/SW/IPPDCompared to EIA/IS 731(Systems Engineering

Capability Model)


Background -1

• Electronic Industries Association InterimStandard (EIA/IS) 731, System EngineeringCapability Model (SECM), was created as amerger of the SE-CMM and the INCOSESystems Engineering Capability AssessmentModel (SECAM)

• Used as a source model for CMMI


Background - 2

• CMMI-SE/SW/IPPD merges software andsystems ideas into product developmentideas

–Staged representation

–Continuous representation with “equivalentstaging”


What is the Systems EngineeringCapability Model (SECM)?

• Describes the essential systems engineering andmanagement tasks that any organization must perform

• Road map for systems engineering & managementprocess improvement

• Systems engineering and management processmeasurement tool


Define &Improve SEProcess

ManageRisk

ManageRisk

ManageTechnology

DefineStkhldr &Sys Level Rqmnts

Monitor &Control

Monitor &Control

IntegrateDisciplines

IntegrateDisciplines

ManageConfigurations

ManageConfigurations

ManageCompetency

Environment

Management

Technical

Manage SE SupportEnvironment

CoordinatewithSuppliers

CoordinatewithSuppliers

ManageData

ManageData

DefineTechnicalProblem

DefineSolution

Assess &Select

IntegrateSystem

VerifySystem

ValidateSystem

Plan &Organize

Plan &Organize

Ensure Quality

SECM Focus Areas


Comparison of Elements -1

CMMI Engineering PAsSECM Technical Focus Areas

RequirementsManagementRequirementsDevelopment

Technical Solution

Product Integration

Verification

Validation

1.1 Define Stakeholder & System Level Requirements

1.2 Define Technical Requirements1.3 Define Solution1.4 Assess and Select1.5 Integrate System1.6 Verify System1.7 Validate System

Support



2.1 Plan and Organize2.2 Monitor & Control2.3 Integrate Disciplines2.4 Coordinate w/ Supp.2.5 Manage Risk2.6 Manage Data2.7 Manage Configurations2.8 Ensure Quality

Project PlanningProject Monitor & ControlIntegrated Project MgtSupplier Agreement MgtRisk ManagementQuantitative Project Mgt

Support Process AreasConfiguration MgtProc & Prod QAMeasurement & AnalysisCausal Analysis and ResolutionDecision Analysis &

Resolution

SECM Management Focus AreasCMMI Project Management

Process Areas

1.4



SECM Environment Focus Areas Organizational ProcessFocus

Organizational ProcessDefinition

Organizational Training

Organizational ProcessPerformance

Organizational Innovation & Deployment

3.1 Define & Improve SE Process3.2 Manage Competency3.3 Manage Technology3.4 Manage SE Support

Environment

CMMI Process Management Process Areas


Comparison of Generic Elements-1

CMMI Generic AttributesSECM Generic Attributes

noneGA1 Effectiveness of FA ActivitiesGA2 Value of FA Products

Capability Level 1 Capability Level 1

none 1.1 Identify WorkScope

1.2 Perform BasePractices


Comparison of Generic Elements -2

CMMI Capability Level 2SECM Capability Level 2

2.1 Follow recorded &approved plans &processes

2.2 Verify compliance &take action whenneeded

2.1 Establish org policy2.2 Plan the process2.3 Provide resources2.4 Assign responsibilities2.5 Train people2.6 Manage configurations2.7 Identify & involve relevant

stakeholders2.8 Monitor & control process2.9 Objectively evaluate adherence2.10 Review status w/ higher-level

mgmt


CMMI Capability Level 3SECM Capability Level 33.1 Standardize &

record a well-definedproc

3.2 Tailor the standardproc using standardguidelines

3.3 Implement &improve the FAactivities

3.4 Improve thestandard process

3.1 Establish adefinedprocess

3.2 Collectimprovementinformation



Comparison of Generic Elements - 4

CMMI Capability Level 4SECM Capability Level 4

4.1 Collect & analyzemetrics

4.2 Take appropriateaction to alignperformance &expectations

4.1 Establishqualityobjectives

4.2 Stabilizesubprocessperformance



CMMI Capability Level 5SECM Capability Level 55.1 Identify FA activities for

which it is appropriate toquantify processrepeatability

5.2 Establish quantitativegoals for improving thestandard process

5.3 Improve the std procbased on data & metrics

5.4 Perform causal analysis& eliminate causes ofvariation by changing thestandard process

5.1 Ensurecontinuousprocessimprovement

5.2 Correctcommoncauses ofproblems


EngineeringPA06 Understand

Customer Needsand Expectations

PA02 Derive and AllocateRequirements

PA03 Evolve SystemArchitecture

PA01 Analyze CandidateSolutions

PA05 Integrate SystemPA07 Verify and Validate

SystemPA04 Integrate

Disciplines

SE-CMMEngineering

CMMITechnical

1.1 DefineStakeholder andSystem LevelRequirements

1.2 Define TechnicalRequirements

1.3 Define Solution1.4 Assess and

Select

1.5 Integrate System

1.6 Verify System

1.7 Validate System

SECM

2.3

SE-CMM and SECM (EIA/IS 731) vs. CMMICommon Features - Engineering

Req’s Management

RequirementsDevelopment

Technical Solution

Decision Analysisand Resolution

Product Integration

Verification

Validation


Project ManagementProject PlanningProject Mon and ConSupplier Agree MgtIntegrated Proj MgtRisk Management

* Not in SE-CMM

SE-CMM

Management

2.1 Plan and Organize2.2 Monitor and

Control2.3 Integrate

Disciplines2.4 Coordinate with

Suppliers2.5 Manage Risk2.6 Manage Data2.7 Manage

Configurations2.8 Ensure Quality

SECM

*

Project

PA12 Plan TechnicalEffort

PA11 Monitor andControlTechnical Effort

PA10 Manage RiskPA09 Manage

ConfigurationsPA08 Ensure Quality

CMMI

PA04

PA18

SE-CMM and SECM (EIA/IS 731) vs. CMMICommon Features - Project Management

SupportConfiguration MgtProc and Prod QAMeas and Analysis

L2 GP


SE-CMMEnvironment

3.1 Define andImprove the SEProcess

3.2 ManageCompetency

3.3 ManageTechnology

3.4 Manage SESupportEnvironment

SECMOrganization

PA13 Define Organization’sSE Process

PA14 ImproveOrganization’s SEProcess

PA17 Provide OngoingKnowledge and Skills

PA15 Manage Product LineEvolution

PA16 Manage SE SupportEnvironment

PA18 Coordinate WithSuppliers

CMMI

Org Process FocusOrg Process DefOrganizational TngQuant Project MgtOrg Process PerfCausal An & Res

Org Innovation andDeployment

(IPPD Extension)OrganizationalEnvironmentIntegration

Process Management

2.4

SE-CMM and SECM (EIA/IS 731) vs. CMMICommon Features - Process Management

L4 GP

L4 GP

L5 GP


Conclusions

•EIA/IS 731 users should be able to smoothlytransition to the CMMI-SE/SW model

–Continuous representation (+ “equivalent” stagedrepresentation)

–Some lower-level differences

–Application of common SE/SW practices toproduct development community


Overview of CMMISM

SE/SW/IPPD ModelProcess Areas


Requirements ManagementRequirements DevelopmentTechnical SolutionProduct IntegrationVerificationValidation

Engineering

ProjectManagement

Project PlanningProject Monitoring and ControlSupplier Agreement ManagementIntegrated Project Management(IPPD)Integrated TeamingRisk ManagementQuantitative Project Management

Organizational Process FocusOrganizational Process DefinitionOrganizational TrainingOrganizational Process PerformanceOrganizational Innovation and Deployment

ProcessManagement

Configuration ManagementProcess and Product Quality AssuranceMeasurement and AnalysisCausal Analysis and ResolutionDecision Analysis and ResolutionOrganizational Environment for Integration

Support

Continuous Organization of PAsCategory


Project Management Process Areas

• There are seven Project Management Process Areas.–Project Planning–Project Monitoring and Control–Supplier Agreement Management–Integrated Project Management–Risk Management–Quantitative Project Management

–Integrated Teaming (IT) and IPM(IPPD) will bediscussed with IPPD.


Basic Project Management PAs

PPWhat To Build

What To Do

SAM

PMC

What To Monitor Replan

Plans

Status, issues,resultsof progressand milestonereviews

Product component requirements Technical issuesCompleted product componentsAcceptance reviews and tests

Engineeringand Support

process areas

Status, issues, results of process and product evaluations;measures and analyses

Commitments

Measurement needs

Corrective action

Supplier

Supplieragreement

Correctiveaction


Project Planning

• Purpose:

• Establish and maintain plans that defineproject activities.


Project Planning - Context

PlanningData

EstablishEstimates

ObtainCommitmentto the Plan

Develop aProject Plan

ProjectPlans

PMC



Determine Estimates

of Effortand Cost

PlanningData

Establish Estimates

Estimate the Scope

of the Project

EstablishEstimates of

Project Attributes

Define ProjectLife Cycle



Establish the Budget

andSchedule

Planning Data

Develop a Project Plan

Planfor Data

Management

Plan Stakeholder

Involvement

Plan forProject

Resources

Project Plans

Establishthe Project

Plan

IdentifyProject Risks

Plan forNeeded

Knowledge and Skills



Obtain Commitmentto the Plan

ReconcileWork andResource

Levels

ProjectPlans

ReviewSubordinate

Plans

ObtainPlan

Commitment


Project Monitoring and Control

• Purpose:

• Provide understanding into the project’sprogress so that appropriate corrective actionscan be taken when the project’s performancedeviates significantly fromthe plan.


Project Monitoring and Control - Context

Project Plans

Monitor Project Risks

Monitor Commitments

Analyze Issues

TakeCorrective

Actions

ConductMilestoneReviews

MonitorData

Management

Monitor Project

PlanningParameters

ManageCorrective Actions

to Closure

Monitor Project Against Plans

ConductprogressReviews

Monitor StakeholderInvolvement

ManageCorrective Actions

PP


Supplier Agreement Management

• Purpose:

• Manage the acquisition of products and servicesfrom suppliers external to the project for whichthere exists a formal agreement.


Supplier Agreement Management-Context

Product

List of Products

EstablishSupplier

Agreements

Supplier Agreement

AcquireCOTS

Product

Analyze Needs and

Requirements

TransitionProducts

Conduct

AcceptanceTesting

SelectSuppliers

Supplier Requirements

Executethe SupplierAgreement

Establish Supplier Agreements

Satisfy Supplier Agreements


Coordination & collaboration; Sharedvision & IT structure

subprocesses forquantitative mgmt.

AdvancedProject Management PAs

Process Performance Objectives, Baselines, Models

QPM

Organization’s Std. Processes

IPMRSKM

Lessons Learned,Performance Data

Project’sDefinedProcess

Statistical Mgmt Data

RiskTaxonomies

& Parameters,Status,

Mitigation,and

Corrective Action

ProcessManagement

process areas

Basic ProjectManagement

process areas

Risk exposure due to unstable processes

Identified risks

Engineering &Support

process areas

Coordination,commitments,issues; Product Architecture for Structuring Teams

ITIT mgmt forengineeringprocesses;

Integratedworkenvironmentpeople &practices


Integrated Project Management

• Purpose:

• Establish and manage the project and theinvolvement of the relevant stakeholdersaccording to an integrated and defined processthat is tailored from the organization’s set ofstandard processes.


Integrated Project Management - Context

ManageStakeholderInvolvement

ManageDependencies

ResolveCoordination

Issues

Coordinate withRelevant

Stakeholders

Documented Technical

Issues

Documented Critical

Dependencies

Agendas andSchedules forCollaborative

Activities

Use the Project’s Defined Process DefinedProcessBased

Project Plan

Project’s Defined Process

Use OrgProc Assetsfor Planning

ProjectActivities

Integrate PlansOPD

• Estimates and Measures• Documentation• Lessons Learned

Other Project& Org Functions

Establishthe Project’s

DefinedProcess

Contributeto Org

ProcessAssets

ManageProject Using

IntegratedPlans


Risk Management

• Purpose:

• Identify potential problems before they occur,so that risk handling activities may be plannedand invoked as needed across the life cycle tomitigate adverse impacts on achieving objectives.


Risk Management - Context

IdentifyRisks

Evaluate, Classify, and

PrioritizeRisks

Identify andAnalyze Risks

From Project Planning and Project Monitoring

and Control

DevelopRisk

MitigationPlans

ImplementRisk

MitigationPlans

Mitigate Risks

DAR

Risk Repository

DetermineRisk

Sourcesand

Categories

DefineRisk

Parameters

Prepare for Risk Management

Establish a Risk

ManagementStrategy


Quantitative Project Management

• Purpose:

• Quantitatively manage the project’s definedprocess to achieve the project’s establishedquality and process performance objectives.


Quantitative Project Management - Context

Definitions ofMeasures;

DerivedObjectives

SubprocesseCapabilityMeasure

Statistically Manage Subprocess Performance

RecordStatistical

ManagementData

MonitorPerformance of Selected

Subprocesses

ApplyStatistical

Methods toUnderstand

Variation

SelectMeasures

and AnalyticTechniques

StableSub-

processes

SelectedSubprocesses

OPP

Predictions ofQuality and

Process Performance

OrganizationMeasurement

Repository

EstablishProject’s

Objectives

Compose the Defined

Process

Quality and ProcessPerformance Objectives

RemedialActions

Selectthe

Subprocessesto be

Managed

Quantitatively Manage the Project

ManageProject

Performance

Project’sDefinedProcess


Summary• Project Planning

• Project Monitoring and Control

• Supplier Agreement Management

• Risk Management

• Integrated Project Management

• Quantitative Project Management

Special Note: Integrated Teaming (IT) and IPM(IPPD)will be discussed with IPPD.


Support Process Areas

There are six Support Process Areas:

• Configuration Management

• Process and Product Quality Assurance

• Measurement and Analysis

• Causal Analysis and Resolution

• Decision Analysis and Resolution

• Organizational Environment for Integration will bediscussed with IPPD.


Understanding SupportProcesses

• Support process areas cover the practices thatsupport product development, maintenance, andacquisition.

• They provide essential processes used by all theCMMI process areas, and are typically used in thecontext of performing other processes.


Basic Support Process Areas

PPQAMA

CM

All process areas

Measurements,analyses

Information needs

Configuration items;change requests

Baselines;audit reports

Processes and workproducts;standards andprocedures

Quality and noncompliance issues


Configuration Management

• Purpose:

• Establish and maintain the integrity of workproducts using configuration identification,configuration control, configuration status

• accounting, and configuration audits.


Configuration Management -Context

EstablishConfig Mgmt

Records

PerformConfiguration

Audits ActionItems

Audit Results

Status

Establish Integrity

Change RequestDatabase

ConfigurationManagement

System

ChangeRequests

Create orRelease

Baselines

Establisha Config.

ManagementSystem

IdentifyConfiguration

Items

Establish Baselines

ControlChanges

TrackChanges

TrackandControlChanges


Process and Product QualityAssurance

• Purpose:

• Provide staff and management with objectiveinsight into the processes and associated workproducts.


Process and Product QualityAssurance - Context

WorkProducts

Reports and Records

Objectively

EvaluateProcesses

ObjectivelyEvaluate

Work Products

& Services

Objectively Evaluate Processes and Work Products

EstablishRecords

Communicateand Ensure

Resolution ofNon-compliance

Issues

Provide Objective Insight


Measurement and Analysis

• Purpose:

• Develop and sustain a measurement capabilitythat is used to support management informationneeds.


Measurement & Analysis - Context

Measurement Indicators

CollectMeasurement

Data Communicate

Results

StoreData &Results

Analyze Measurement

Data

Provide Measurement Results

Measurement Personnel

MeasurementRepository

Measurement Objectives Procedures,Tools

SpecifyMeasures

EstablishMeasurement

Objectives

SpecifyAnalysis

Procedures

SpecifyData

Collectionand StorageProcedures

Align Measurement Analysis Activities

Advanced Support Process Areas

DAR

All process areas

CAR

Defects & other problems

Selected issues;

Process improvementproposals;

Structured decisions

OEI

ProcessManagement

PAs

ProjectManagement

PAs

Ability to develop& deploy IPPDprocesses& supportingassets; IPPD knowledge

& skill needs Integrated workenvironment &people practices

Organization IPPDInfrastructure


Causal Analysis and Resolution

• Purpose:

• Identify causes of defects and other problemsand take action to prevent them from occurringin the future.


Causal Analysis andResolution - Context

SelectData for Analysis

AnalyzeCauses

Defect &Problem

Data

DetermineCauses of Defects

ImplementAction

Proposals

EvaluateEffect ofChanges

RecordData

ActionProposal

Action Plans

CAR Records

PerformanceMeasures

Address Causesof Defects



• Purpose:

• Make decisions using a structured approach thatevaluates identified alternatives againstestablished criteria.



• Applicability:

• The project should document guidelines for whena structured decision analysis process is to beused.

• DAR should be applied where significanttechnical, cost, or schedule risks evolve.


Decision Analysis andResolution - Context

Establishand Use

Guidelines for Decision

Analysis

Guidelines

Evaluate Alternatives

SelectEvaluation

Techniques

Techniques

EstablishEvaluation

Criteria

Criteria

IdentifyAlternative Solutions

ProposedAlternatives

EvaluationResults

SelectSolutions

Solutions Evaluate

Alternatives


Engineering Process Areas

• There are six Engineering Process Areas.

• Requirements Management

• Requirements Development

• Technical Solution

• Product Integration

• Verification

• Validation


Engineering Process Areas

RD PI

Val

CustomerTS

Ver

REQMRequirements

Customer needs

Product & product component requirements

Product components, work products, verification and validation reports

Productcomponents

Alternativesolutions

Require-ments

Product


Requirements Management

•Purpose:

•Manage the requirements of the project’s productand product components and identifyinconsistencies between those requirements andthe project’s plans and work products.


Requirements Management - Context

Requirements

Obtain anUnderstanding

of Requirements

CL2Obtain

Commitmentto

Requirements

IdentifyInconsistenciesbetween Project

Work and Reqmts

TraceabilityHierarchy

CL2Maintain

Bi-directional Requirements

Traceability

Manage Requirements

ManageRequirements

Changes


Requirements Development

• Purpose:

• Produce and analyze customer, product, andproduct component requirements.


Requirements Development -Context

Develop Customer

Requirements

CustomerRequirements

ProductRequirements

DevelopProduct

Requirements

Analyze andValidate

Requirements

ValidatedRequirements


TransformNeeds intoCustomer

Requirements

Requirements Development -Context


Develop Customer Requirements

CollectStakeholder

Needs

CL2Elicit Needs


EstablishProduct &Product

ComponentRequirements

Requirements Development - Context

ProductRequirements

Develop Product Requirements

AllocateProduct

ComponentRequirements

IdentifyInterface

Requirements



EstablishOperationalConcepts

& Scenarios

Establish aDefinition of

RequiredFunctionality

CL3EvaluateProduct

Cost,Schedule,

& Risk

AnalyzeRequirements

ProductRequirements


Analyze and Validate Requirements

ValidateRequirements

CL2Validate

Requirementswith

ComprehensiveMethods

Requirements Development - Context


Technical Solution

• Purpose:

• Develop, design, and implement solutionsto requirements. Solutions, designs andimplementations encompass products, productcomponents, and product related processeseither singly or in combinations as appropriate.


Select ProductComponent

Solutions

Technical Solution - Context


Design Detail &Documentation

DeliveredProduct

Develop the Design

Implement theProduct Design

Alternative Designsand Evaluation Criteria



DevelopAlternative

Solutions andSelectionCriteria

Select Product Component Solutions

CL 2Develop Detailed

Solutions andSelectionCriteria

Alternative SolutionsSelection Criteria

New Technology Evaluations

SelectProduct

ComponentSolutionsSelection Decisions

Compliance w/ Reqmts

DAR

CL 2Evolve

OperationalConcepts &Scenarios

Operational ScenariosTimeline Analysis

Use Cases




UseEffectiveDesign

Methods

Develop the Design

DevelopTech DataPackage

CL 3EstablishCompleteTech DataPackage

Tech DataPackage

EstablishInterface

Descriptions

CL 3Design

ComprehensiveInterface

I/F Design DocumentationI/F SpecificationI/F Control Documents

PerformMake, Buy,

or ReuseAnalyses

Selection CriteriaMake/Buy Analysis

Design MethodsDesign ToolsDesign Processes



Parts FabricatedSoftware CodedData DocumentedProcesses DocumentedFacilities Constructed

ImplementThe

Design

Implement the Product Design

Establish ProductSupport

Documentation

Training ManualsUsers ManualOperator’s ManualMaintenance ManualOn-line Help


Product Integration

• Purpose:

• Assemble the product from the productcomponents, ensure the product, asintegrated, functions properly and deliver theproduct.


Product Integration - Context

Assemble ProductComponents

and Deliver theProduct

IntegrationPlan

Prepare forProduct Integration

TechnicalSolution

DAR

EnsureInterface

Compatibility

Assemblies

Sub-assemblies


Integration Plan- Integration Resources- Integration Procedures- Interface Data

Prepare for Product Integration

Decision Analysis& Resolution

TechnicalSolution

Establisha Product

IntegrationStrategy

CL3Define Detailed

ProductIntegrationProcedures

CL2Establish

the ProductIntegration

Environment




Ensure Interface Compatibility

TechnicalSolution

ReviewInterface

Descriptionsfor

Completeness

ManageInterfaces



Assemble Product Components and Deliver Product

TechnicalSolution

Confirm Readiness ofComponents

forIntegration

AssembleProduct

Components

CheckoutAssembled

ProductComponents

PackageAnd Deliverthe Productor Product Component




Verification versus Validation

• Verification–Did you build the product right?

–That is, did you meet the requirementsspecification?

• Validation–Did you build the right product?

–That is, did you meet the operational need?


Verification

• Purpose:

• Assure that selected work products meet theirspecified requirements.


Verification - Context

VerificationPlan

Prepare for Verification

CorrectiveActions

Verify SelectedWork Products

PerformPeer Reviews



Establish aVerification

Strategy

Requirements,Methods, Processes,

Evaluation Criteria

Prepare for Verification

CL2Establish theVerification

Environment

Verification Plan- Verification Resources- Verification Procedures

TechnicalSolution

CL3EstablishDetailed

Verification Plans



PrepareFor Peer Reviews

Requirement for DataCollectionEntry and Exit CriteriaPeer Review Plan

Review ResultsReview IssuesReview DataAction ItemsConduct

PeerReviews

Perform Peer Reviews

CL 2Analyze

Peer ReviewData



Verification ResultsDeficienciesVerification DataCorrective Actions

Verify Selected Work Products

PerformVerification

CL2Analyze

VerificationResults and

IdentifyCorrective

Actions

PerformRe-Verification


Validation

• Purpose:

• Demonstrate that a product or productcomponent fulfills its intended use whenplaced in its intended environment.


Validation - Context

- Customer Requirements- Product Requirements- Products- Validation Requirements

Prepare for Validation

- Requirements Validation Plan- Product Validation Plan- Process and Support Needs

Validate Product orProduct Components

- Conformance- Deficiencies



Establish aValidationStrategy

- Validation Plan- Support Needs- Environment Needs- Resources

- Test Case Scenario- Validation Procedures

Prepare for Validation

CL3Define

DetailedValidation

Procedures

CL2Establish the

ValidationEnvironment



Validate Product or Product Components

PerformValidation

Validation ReportsValidation ResultsCross Reference MatrixAs run procedures logOperational Demonstrations

Captureand AnalyzeValidation

Results

Validation Deficiency ReportsValidation IssuesProcedure Change Request


Process Management Process Areas

• There are six Process Management Process Areas:–Organizational Process Focus–Organizational Process Definition–Organizational Training–Organizational Process Performance–Organizational Innovation and Deployment–Organizational Environment for Integration will be

covered with IPPD


Understanding ProcessManagement PAs

•The process management PAs apply across theorganization as a whole and provide details thatsupport the Capability Level 3 Generic Goal.

•For selected PAs, the organization has standardprocesses, which individual projects tailor to theirneeds.


Understanding ProcessManagement PAs

•Process Management PAs can capitalize onproject level stability provided by PAs that areinstitutionalized at CL 2.

•(i.e., policy, planning, resources, responsibility,training, performing the process, managingconfigurations, monitoring and controlling,objective verification, management review)


Basic Process Management PAs

OPF OPDResources and Coordination

OT

Std Process and OtherAssets

Training for Projects andSupport Groups in StdProcess and Assets

Organization’sprocess needsand objectives

Std Process and Other

Assets

Senior Management

Organization’sbusiness objectives

Project Management,Support, and

Engineering processareas

Training needs

Improvement information(e.g., lessons learned, data, artifacts)Process Improvement

Proposals; Participation indefining, assessing, anddeploying processes


Organizational Process Focus

• Purpose:

• Establish and maintain an understandingof the organization's processes and processassets, and identify, plan, and implement theorganization's process improvement activities.


Selected Improvements

ImprovementInitiatives

Pilots, Action

Teams

Organizational Process Focus- Context

• Findings

•& Ratings

Assess Org’s

Processes

Identify Org.’sProcess

Improve- ments

EstablishOrganizational

ProcessNeeds

Process Needsand Objectives

DetermineProcessImprovementOpportunities

Establish Process Action Plans

ImplementProcessActionPlans

Process Action plans

Deployable Process Assets

(Revised) ProcessAssets

IncorporateProcess-Related

Experiences

Process Experiences

Deploy Process

and RelatedProcessAssets

Planand ImplementProcessImprove-mentActivities


• Purpose:

• Establish and maintain a usable set of organizationalprocess assets.

Organizational Process Definition


Organizational ProcessDefinition - Context

EstablishTailoring

Criteria andGuidelines

Establish Life-Cycle

Model Descriptions

Establish Standard

Processes

Create Organizational Process Assets

ProcessImplementers

Life Cycle Models

Organizational Standard Processes

Organizational Library of Process

Documentation

Organizational Measurement

Repository

Improvements

OPF

Deploy-ment

Tailoring Guidelines

Establish an Organizational Measurement

Repository

Establish Organizational

Process AssetLibrary

Make SupportingProcess Assets

Available


Organizational Training

•Purpose:

•Develop the skills and knowledge of peopleso they can perform their roles effectivelyand efficiently.


Organizational Training - Context

DeliverTraining

Materials

Records ChangeRequests

AssessTraining

Effectiveness

EstablishTrainingRecords

Surveys

Records

Provide Necessary Training

Establish the Strategic Training

Needs

Analysis Needs Strategy Reqmts

Determinewhich TrainingNeeds are theResponsibility

of the Org.

MaterialsTraining Repository

Identify Training Needs andMake Training Available

Establish Training

Capability

Establish Organizational

TrainingTactical Plan


Senior Management

OPP

Progress towardachieving business

objectives

OID

Quality and process performance objectives,

measures, baselines, models

Cost and benefitdata from pilotedimprovements

Quality and processperformance

objectives,measures, baselines,

models

Process performanceand capability data

“Basic Set” of ProcessManagement

Process Areas

Project Management,Support, andEngineering

process areas

Ability to developand deploy processand supporting assets

OrganizationImprovements

Common measures

Advanced ProcessManagement PAs


Organizational Process Performance

•Purpose:

•Establish and maintain a quantitativeunderstanding of the performance of theorganization’s set of standard processes, andprovide the process performance data,baselines, and models to quantitatively managethe organization’s projects.


Organizational ProcessPerformance - Context

EstablishQuality and

ProcessPerformanceObjectives

Organizational ProcessPerformance Baselines

ProcessPerformance

Models

Organization’sStandard Processes Project Process

Measurements

SelectProcesses

Selected Subprocesses fromOrg. Std. Processes

BusinessObjectives

Organizational ProcessPerformance Objectives

EstablishProcess

PerformanceModels

Establish Process

PerformanceMeasures

EstablishProcess

PerformanceBaselines

•Org set ofmeasures

QPM

QPM

BusinessObjectives

Establish Performance Baselines and Models

MA


Organizational Innovation andDeployment

• Purpose:

• Select and deploy incremental and innovativeimprovements that measurably improve theorganization’s processes and technologies.The improvements support the organization’squality and process performance objectives asderived from the organization’s businessobjectives.


Manage theDeployment

MeasureImprovements

Effects

Plan theDeployment

Deploy Improvements

Organizational Innovation andDeployment - Context

Collectand AnalyzeImprovement

Proposals

MeasurementResults

PilotImprovements

Improvement Proposalsand Analysis

Select Improvements

for Deployment

Improvements

Select Improvements

IdentifyInnovations


Overview of Integrated Productand Process Development

IPPD


About IPPD

• IPPD affects all process areas.

• IPPD is not a discipline.

• Rather, it is a way of doing business.

• IPPD is employed in conjunction with the CMMIdisciplines (software and systems engineering).

• Implementation of IPPD shapes how you performthe work in these disciplines.


IPPD - Definition

IPPD provides a systematic approach toproduct development that achieves a timelycollaboration of relevant stakeholdersthroughout the product life cycle to bettersatisfy customer needs.


IPPD - Definition -2

Integration of the development of product-related processes (e.g., manufacturing,support, training, disposal) during productdevelopment is embedded in SE/SW specificpractices by involving relevant stakeholdersfrom all life cycle phases and by the conceptof “work product.”


Stakeholder Involvement

• Stakeholder Involvement is guided and assured bythree constructs in CMMI- SE/SW/IPPD:

• GP 2.7 Identify and involve the relevant stakeholdersof the process as planned.

• PP SP 2.6-1 Plan the involvement with identifiedstakeholders.

• IPM SG 2 Collaborate and coordinate with relevantstakeholders.


CMMI Work Product - Definition

–Any artifact produced by a process.–This may include files, documents, parts of the

product, services, processes, specifications, andinvoices.

–Examples of processes as work product include amanufacturing process, a training process, and adisposal process.

–A key distinction between a work product and aproduct component is that a work product neednot be engineered (although it may be).


IPPD in CMMI Models

• Then, what makes IPPD different from pure SE/SWimplementations?

• IPPD relies on integrated teams to develop theproduct and processes.

• IPPD provides an integrated work environment andthe management of people to incentivize teamwork.

• Processes are tailored to be used by integratedteams.


CMMI Integrated Team Definition

• An integrated team is comprised of people–with complementary skills and expertise–appropriate skills and advocacy–fully empowered to represent stakeholders–from all phases of the work product’s life cycle

• These people are committed to and arecollectively responsible for–delivering specified work products–through timely collaboration


Scope of IPPD

•CMMI SE/SW/IPPD adds to CMMI-SE/SW:

–Two new process areas»Organizational Environment for Integration»Integrated Teaming

–A revised Integrated Project Management (IPPD)process area

–IPPD amplifications and references–New glossary definitions and acronyms–Overview material


Organizational Environmentfor Integration (OEI)

•Purpose:

•To provide an IPPD infrastructure and managepeople for integration.


Provide IPPD

Infrastructure

IPPD-EnabledPeople

andWork

Environments

ManagePeople forIntegration

Mechanismsand

Incentivesto SupportIntegration

andCollaboration

Organizational Environmentfor Integration (OEI)- Context


Organizational Environment forIntegration – Context

Guidelines forLeadership,

Decision-makingContext

Manage People forIntegration

Establish Leadership

Mechanisms

Establish Incentives for

Integration

Establish Mechanisms to Balance Responsi-

bilities

Guidelines forEmpowerment

Process forIssue Resolution

Team &IndividualRewards

OrganizationalGuidelines

JointPerformance

Review Process

Organization’sShared Vision

Establish an Integrated

Work Environ- ment

Establish theOrganization’s

Shared Vision

Provide IPPD Infrastructure

IntegratedWork

Environment

Identify IPPD-Unique

Skill Require- ments

Guidelines for Shared Vision

Building

IPPD Tactical & StrategicTraining

Needs

OPD

OT


Integrated Project Management -(IPPD)

• Purpose:

• Establish and manage the project and theinvolvement of the relevant stakeholdersaccording to an integrated and defined processthat is tailored from the organization’s set ofstandard processes.

• It also covers the establishment of a a sharedvision for the project and an integrated teamstructure that will carry out the objectives of theproject.


Integrated Project Management(IPPD) - Context

Use theProject’sDefinedProcess

Coordinate and Collaborate with Relevant Stakeholders

Stakeholders

ProductRequirements

DefinedProcessBased

Project Plan

Contributions toOrganization’s Process Assets

Use theProject’s

Shared Vision

Project’sSharedVision

Stakeholders

ProjectPlanning

OrganizeIntegrated

Teams

IntegratedTeams

OrganizationalEnvironment for

Integration


Work Breakdown Structure

Integrated Teams

Integrated Project Management (IPPD)

Responsibility & Requirements

Allocation

Info onOrg/Project Situation

Organize Integrated TeamsUse the Project’s SharedVision

Define theProject’sShared Vision

Context

Establish the

Project’s Shared Vision

OEI

Project’s SharedVision

DetermineTeam

Structure

Develop aPreliminary

Distribution ofRequirements

EstablishIntegrated

Teams

Team Structure

Member Aspirations

List ofTeams

IntegratedTeaming


Integrated Teaming

•Purpose:

•To form and sustain an integrated teamfor the development of work products.


Integrated Teaming - Context

Establish andMaintain TeamComposition

Govern TeamOperation

Stakeholders

Sponsor’sObjectives

AssignedProduct

IntegratedTeam

ProjectPlanning

Plans and

Commitments

OrganizationalEnvironment forIntegration

IPM(IPPD)


Identify Team Tasks

Establish TeamComposition

Results Lists

TaskDescriptions

Identify Knowledge and Skills

Functions, Skills,& Expertise

Lists

Assign Appropriate

Team Members

IntegratedTeam

Stakeholders

AssignedProduct

Govern TeamOperation

Establish a Shared

Vision

TeamCharter Establish

a Team Charter

Assignments,& Respon-sibilities

Define Roles & Respon- sibilities

Ground Rulesand

Procedures

Establish Operating

Procedures

Collaborate With

Interfacing Teams

Plans and Commitments

Team’sShared Vision

Sponsor’sObjectives

Integrated Teaming - Context

Training and Assessments


“Introduction to the CMMI” Course,Staged & Continuous (Separate

Courses)

• Introduction course will enable the participant to– Understand the importance of defined processes– Understand the rationale for process improvement– Comprehend the CMMI model– Identify ways of applying the CMMI model

for process improvement

• Broad audience– Systems and software developers– Systems and software managers– Practitioners of disciplines that support systems and software– Government and industry acquirers of software-intensive systems

• Assumes one year of experience in systems and software

• No process improvement or Capability MaturityModel (CMM ) experience assumed


“Intermediate Concepts ofCMMI Models” Course

• Provides a deeper understanding of theCMMI and it’s fundamental concepts.–PA’s in more detail–Linking the PA’s together– Interpreting the CMMI for

assessments–Application of CMMI for process

improvement

• Required as a prerequisite to SCAMPILead Assessor training.


Additional Training Identified

• Executive Tutorial

• Moving From SW-CMM to CMMI

• Process Improvement Training

• Concept-Specific Training (RM, CM, QA, etc.)


• Similar to the current CMM AppraisalFramework (CAF) V1.0–A guide to assessment method developers

• Specifies the requirements for classes ofassessment methods–Class A: Full, comprehensive assessment methods–Class B: Initial, incremental, self-assessments–Class C: Quick-look

• Method developers can declare which class theirmethod fits

• Implications of the desired class of assessment

Assessment Requirements for CMMI (ARC)


Standard CMMI Assessment Method forProcess Improvement (SCAMPI)

• Similar to CBA IPI method

• Led by authorized Lead Assessor

• Tailorable to organization andmodel scope

• SCE will be a tailoring option from SCAMPI

• SCAMPI Method Description Document


CMMI Lead Assessor Program

• Similar to existing SEI Lead Assessorand Lead Evaluator programs–To be administered by SEI

• Will transition current SW & SELead Assessors–SCAMPI Upgrade Training

• Lead Assessor requirements:–Introduction to CMMI Training–Assessment team experience–Intermediate CMMI Training–SCAMPI Lead Assessor Training


Expectations

• The method has been simplified, but…–CMMI models have more process

areas and more practices than eachof the individual source models

• The goal:–Assuming an organization

of 3-6 projects, 6-9 team members,experienced Lead Assessor

–SCAMPI assessment of process areas throughLevels 3 in 100 hours or less

Wrap-Up


What’s New in CMMI V1.1?

• Mainly minor changes

• Terminology clean-up–“process”–“stakeholder”–“goals” vs. “objectives”–“CM process” vs. “CM process area”–“DAR process” vs. “Formal evaluation process”

• Informative material has been beefed up in GP’s

• A few goals and practices have been modified


CMMI Transition Plan

Development Phase• Development of CMMI products• Verification and validation of CMMI products

Transition Phase• Approval of initial CMMI products for

public release• Evidence of sufficient use• Transition planning to help organizations

use CMMI products

Sustainment Phase• Upkeep and continuous improvement

of the product suite• Additional evidence of adoption and use

V1.0Aug 2000

V1.1Dec 2001

SW-CMM, EIA 731 phased outDec 2003

V0.2Aug 1999

Pilots


DoD Expectations for CMMI

CMMI will improve the maturity for the software intensive systemsdevelopment and maintenance– Integration of systems and software emphasis will focus programs

on the essential engineering processes–Gains already made in software will migrate to systems

engineering

CMMI will become the logical integrated successor for the CMM-SW forsoftware engineering and EIA/IS 731 for systems engineering–Simplifies the process of viewing the two disciplines–Major companies have migration plans in place–Support for pilot assessments across Government and Industry–Transition Partners are being trained as CMMI Lead Assessors

Comments of Dr. Jack Ferguson, Director, Software Intensive Systems (OUSD (AT&L))At STC, 2001


DoD Expectations for CMMI(continued)

• CMMI will become the approved means of judgingengineering maturity for procurements within two years–Integrated appraisal method should minimize the impact

on industry and Government during procurementevaluations

–OSD policy update to reference CMMI being considered

• New techniques for minimizing costs and scheduleimpacts during appraisals related to procurements will beconsidered and adopted–Government participation in internal assessments

Comments of Dr. Jack Ferguson, Director, Software Intensive Systems (OUSD (AT&L))At STC, 2001


CMMI...Re-cap

• ... Is not so different from the models with which weare familiar

• ... Has 2 representations in a single model:– Staged– Continuous

• ... Contains specific and generic goals that must besatisfied

• ... Is directly related to our work:– Not everything we do is just ‘software’

engineering– There is a lot of systems engineering and

“other”