+ All Categories
Home > Documents > The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources,...

The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources,...

Date post: 26-Dec-2015
Category:
Upload: augustus-gregory
View: 218 times
Download: 0 times
Share this document with a friend
Popular Tags:
24
The Capability The Capability Maturity Model in Maturity Model in Software Development Software Development Paul X. Harder, JD Paul X. Harder, JD Government Micro Resources, Government Micro Resources, Inc. Inc. September 14, 2004 September 14, 2004
Transcript
Page 1: The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004.

The Capability Maturity Model The Capability Maturity Model in Software Developmentin Software Development

Paul X. Harder, JDPaul X. Harder, JD

Government Micro Resources, Inc.Government Micro Resources, Inc.

September 14, 2004September 14, 2004

Page 2: The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004.

The Capability Maturity ModelThe Capability Maturity Model

What is the Capability Maturity Model What is the Capability Maturity Model (CMM)?(CMM)? The application of process management and The application of process management and

quality improvement concepts to software quality improvement concepts to software development and maintenance.development and maintenance.

A guide for evolving toward a culture of A guide for evolving toward a culture of engineering excellence.engineering excellence.

A model for organizational improvement.A model for organizational improvement.

Page 3: The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004.

The Capability Maturity ModelThe Capability Maturity Model

Working with DoD, Carnegie-Mellon University (CMU) Working with DoD, Carnegie-Mellon University (CMU) created the Software Engineering Institutecreated the Software Engineering Institute

In September 1987, the SEI released a brief description In September 1987, the SEI released a brief description of the process maturity framework Two methods, of the process maturity framework Two methods, software process assessment and software capability software process assessment and software capability evaluation and a maturity questionnaire were developed evaluation and a maturity questionnaire were developed to appraise software process maturity.to appraise software process maturity.

In 1991, SEI released the Capability Maturity Model for In 1991, SEI released the Capability Maturity Model for Software version 1.0.Software version 1.0.

In 2001, SEI released the Capability Maturity Model – In 2001, SEI released the Capability Maturity Model – Integrated, superseding the CMM for software.Integrated, superseding the CMM for software.

Page 4: The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004.

Focuses on practices that are under control of Focuses on practices that are under control of the software groupthe software group

Presents a minimum set of recommended Presents a minimum set of recommended practices that have been shown to enhance a practices that have been shown to enhance a software development and maintenance software development and maintenance capabilitycapability It defines the expectation (the “what”)It defines the expectation (the “what”) Without overly constraining the implementation (the Without overly constraining the implementation (the

“how”)“how”)

Capability Maturity ModelCapability Maturity Model

Page 5: The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004.

Process Maturity Increases Process Maturity Increases Project SuccessProject Success

Pro

ba

bil

ity

Pro

ba

bil

ity

Pro

ba

bil

ity

Pro

ba

bil

ity

Pro

ba

bil

ity

Time/$/ . . .

Time/$/ . . .

Time/$/ . . .

Time/$/ . . .

Time/$/ . . .

Ta

rge

t N

Ta

rge

t N

+a

Ta

rge

t N

-xT

arg

et

N-y

Ta

rge

t N

-z

1

2

3

4

5

Mat

uri

ty L

evel

s

Plans based on past performance are more realistic in Level 2 organizations

Plans based on past performance are more realistic in Level 2 organizations

With well-defined processes, performance improves in Level 3 organizations

With well-defined processes, performance improves in Level 3 organizations

Schedule and cost targets are typically overrun by Level 1 organizations

Schedule and cost targets are typically overrun by Level 1 organizations

Based on quantitative understanding of process and product, performance continues to improve in Level 4 organizations

Based on quantitative understanding of process and product, performance continues to improve in Level 4 organizations

Performance continuously improves in Level 5 organizationsPerformance continuously improves in Level 5 organizations

Page 6: The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004.

CMM-ICMM-IBased on the CMM-SW model created in 1991 Based on the CMM-SW model created in 1991

to assess the maturity of software development, to assess the maturity of software development, with integration into other models.with integration into other models.

Multiple Multiple modelsmodels, based on disciplines addressed, based on disciplines addressedCMMI - CMMI - SWSW: Software Engineering: Software Engineering

CMMI - CMMI - SESE / SW: above plus Systems Engineering / SW: above plus Systems Engineering

CMMI - SE / SW / CMMI - SE / SW / IPPDIPPD: above plus Integrated Product & : above plus Integrated Product & Process DevelopmentProcess Development

CMMI - SE / SW / IPPD / CMMI - SE / SW / IPPD / SSSS: above plus Supplier : above plus Supplier SourcingSourcing

C M M I

Page 7: The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004.

Why We Chose CMMWhy We Chose CMM

CMM today serves as a “seal of approval” in software CMM today serves as a “seal of approval” in software developmentdevelopmentCMM helped guide us towards standard, repeatable CMM helped guide us towards standard, repeatable processes – reduced learning time on how to get things processes – reduced learning time on how to get things donedoneStandard practices mean time savings to our team - Standard practices mean time savings to our team - everyone knows what to expect and what to delivereveryone knows what to expect and what to deliverOur quality activities became more aligned within the Our quality activities became more aligned within the project rather than thought of as a separate eventproject rather than thought of as a separate eventWe rely on our processes and our people together, not We rely on our processes and our people together, not just one or the otherjust one or the otherIdeas in CMM creates an environment of improvement – Ideas in CMM creates an environment of improvement – if you don’t like things one way, make it better!if you don’t like things one way, make it better!

Page 8: The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004.

Level Focus Process Areas

5 OptimizingContinuousProcess Improvement

Organizational Innovation and DeploymentCausal Analysis and Resolution

4 Quantitatively Managed

Quantitative Management

Organizational Process PerformanceQuantitative Project Management

3 Defined ProcessStandardization

Requirements DevelopmentTechnical SolutionProduct IntegrationVerificationValidationOrganizational Process FocusOrganizational Process DefinitionOrganizational TrainingIntegrated Project Mgmt (with IPPD extras)Risk ManagementDecision Analysis and ResolutionIntegrated Teaming (IPPD only)Org. Environment for Integration (IPPD only)Integrated Supplier Management (SS only)

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

2 ManagedBasicProject Management

1 Initial

QualityProductivity

RiskRework

Stages of Process MaturityStages of Process Maturity

Page 9: The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004.

Level 1: the “Initial” Level Level 1: the “Initial” Level Success depends on heroesSuccess depends on heroes

Good performance is possible - butGood performance is possible - but

Requirements often misunderstood, uncontrolledRequirements often misunderstood, uncontrolled

Schedules and budgets frequently missedSchedules and budgets frequently missed

Progress not measuredProgress not measured

Product content not tracked or controlledProduct content not tracked or controlled

Engineering activities nonstandard, inconsistentEngineering activities nonstandard, inconsistent

Teams not coordinated, not trainedTeams not coordinated, not trained

Defects proliferateDefects proliferate

Page 10: The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004.

CMMI Level 2: “Managed”CMMI Level 2: “Managed”

Baseline the product requirements Baseline the product requirements

Estimate project parameters,Estimate project parameters,Develop plans and processesDevelop plans and processes

Measure actual progress to enable Measure actual progress to enable timely corrective actiontimely corrective action Measure for mgmt. info needsMeasure for mgmt. info needsVerify adherence of processes Verify adherence of processes and products to requirementsand products to requirements

Identify and control products,Identify and control products, changes, problem reports changes, problem reports

Select qualified suppliers / vendors; Select qualified suppliers / vendors; manage their activitiesmanage their activities

CLARIFY REQUIREMENTSCLARIFY REQUIREMENTS

DOCUMENT PLANSDOCUMENT PLANS

TRACK PROGRESSTRACK PROGRESS

CONTROL PRODUCTSCONTROL PRODUCTS

7 Process Areas7 Process Areas

– Requirements Management Requirements Management (REQM)(REQM)

Project Planning Project Planning (PP)(PP)

– Project Monitoring Project Monitoring and Control and Control (PMC)(PMC)

– Measurement & AnalysisMeasurement & Analysis (M&A)(M&A)– Process & ProductProcess & Product

Quality Assurance Quality Assurance (PPQA)(PPQA)

– Configuration Configuration Management Management (CM)(CM)

– Supplier Agreement Supplier Agreement Management Management (SAM(SAM))

Page 11: The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004.

What Happens During Level 2What Happens During Level 2

Processes become easier to digest and Processes become easier to digest and understandunderstandManagers and team members spend less time Managers and team members spend less time explaining how things are done and more time explaining how things are done and more time doingdoingProjects are better estimated, better planned, Projects are better estimated, better planned, and more flexibleand more flexibleQuality is integrated into the projectQuality is integrated into the projectCosts may go up initially, but do go down over Costs may go up initially, but do go down over timetimeAnd yes, there may be more documentation and And yes, there may be more documentation and paperpaper

Page 12: The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004.

Clarify customer requirementsClarify customer requirements Solve design requirements; developSolve design requirements; develop

implementation processes implementation processes Assemble product components, deliverAssemble product components, deliver Ensure products meet requirementsEnsure products meet requirements Ensure products fulfill intended useEnsure products fulfill intended use Analyze decisions systematicallyAnalyze decisions systematically

Follow integrated, defined processesFollow integrated, defined processes Identify and control potential problemsIdentify and control potential problems

Establish org. responsibility for PIEstablish org. responsibility for PI Define the org’s best practicesDefine the org’s best practices Develop skills and knowledge Develop skills and knowledge

ENGINEER THE PRODUCTENGINEER THE PRODUCT

MANAGE THE PROCESSESMANAGE THE PROCESSES

PROVIDE ORG. INFRASTRUCTUREPROVIDE ORG. INFRASTRUCTURE

CMMI Level 3: “Defined”CMMI Level 3: “Defined” 11 Process Areas*11 Process Areas*

– Requirements Definition Requirements Definition (RD)(RD)– Technical Solution Technical Solution (TS)(TS)

– Product IntegrationProduct Integration (PI)(PI)– VerificationVerification (Ver)(Ver)– ValidationValidation (Val)(Val)– Decision AnalysisDecision Analysis

& Resolution & Resolution (DAR)(DAR)

– Integrated Project MgmtIntegrated Project Mgmt (IPM) (IPM) – Risk ManagementRisk Management (RSKM)(RSKM)

– Org. Process FocusOrg. Process Focus (OPF) (OPF) – Org. Process Definition Org. Process Definition (OPD)(OPD)– Org. TrainingOrg. Training (OT)(OT)

Page 13: The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004.

What Happens During Level 3What Happens During Level 3

Process Improvement becomes the standard – Process Improvement becomes the standard – Cross-Functional teams look for ways to “short-Cross-Functional teams look for ways to “short-cut” the systemcut” the systemSolutions go from being “coded” to being Solutions go from being “coded” to being “engineered”“engineered”Quality gates appear throughout the project Quality gates appear throughout the project effort with the entire team involved in the effort with the entire team involved in the process, reducing reworkprocess, reducing reworkRisks are managed and don’t take the team by Risks are managed and don’t take the team by surprisesurprise

Page 14: The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004.

MANAGE PROJECTS QUANTITATIVELYMANAGE PROJECTS QUANTITATIVELY

MANAGE THE ORGANIZATION QUANTITATIVELYMANAGE THE ORGANIZATION QUANTITATIVELY

CMMI Level 4: “Quantitatively CMMI Level 4: “Quantitatively Managed”Managed”

Statistically manage the project’s Statistically manage the project’s processes and sub-processesprocesses and sub-processes

Understand process performance; Understand process performance; quantitatively manage quantitatively manage the organization’s projectsthe organization’s projects

2 Process Areas2 Process Areas

– Quantitative ProjectQuantitative ProjectManagementManagement(QPM)(QPM)

– OrganizationalOrganizationalProcess PerformanceProcess Performance(OPP)(OPP)

Page 15: The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004.

CMMI Level 5: “Optimizing”CMMI Level 5: “Optimizing”

Identify and eliminateIdentify and eliminatethe cause of defects the cause of defects earlyearly

Identify and deploy new tools and Identify and deploy new tools and process improvements to meet needs process improvements to meet needs and business objectivesand business objectives

OPTIMIZE PERFORMANCEOPTIMIZE PERFORMANCE

ADOPT IMPROVEMENTSADOPT IMPROVEMENTS

2 Process Areas2 Process Areas

– Causal AnalysisCausal Analysisand Resolutionand Resolution(CAR)(CAR)

– Organizational Innovation Organizational Innovation and Deploymentand Deployment(OID)(OID)

Page 16: The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004.

The CMM Maturity LevelsThe CMM Maturity Levels

Maturity Level 1

~Maturity Level 2

~ ~~Maturity Level 3

~~~~ ~ ~

Maturity Level 4

~~~~~ ~ ~

Maturity Level 5

Page 17: The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004.

Proving Maturity LevelsProving Maturity Levels

Five characteristics must be demonstrated in each Five characteristics must be demonstrated in each practice to be assessed in that maturity level practice practice to be assessed in that maturity level practice areas:areas:

Commitment to Perform – Policies, procedures, and resources Commitment to Perform – Policies, procedures, and resources to perform the workto perform the work

Ability to Perform – Personnel, tools, and templates in placeAbility to Perform – Personnel, tools, and templates in place Activities Performed – Documentation and interviews Activities Performed – Documentation and interviews

demonstrating that policies are implementeddemonstrating that policies are implemented Measurement and Analysis – Metrics and other tools used to Measurement and Analysis – Metrics and other tools used to

evaluate effectiveness of processesevaluate effectiveness of processes Verifying Implementation – Independent review and evaluation Verifying Implementation – Independent review and evaluation

of the processesof the processes

Maturity levels are proven through documentation Maturity levels are proven through documentation (policies, procedures, templates) and interviews of staff (policies, procedures, templates) and interviews of staff (to prove institutionalization).(to prove institutionalization).

Page 18: The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004.

Source: http://www.sei.cmu.edu/sema/profile.html

CMM Process Maturity ProfileCMM Process Maturity Profileof Software Organizationsof Software Organizations

Maturity Level 1987-91 1997 1999 2001 December 2002

1- Initial 80% 61% 48% 38% 32%

2- Repeatable 12% 23% 30% 34% 37%

3- Defined 7% 14% 16% 20% 21%

4- Managed 0% 2% 4% 5% 5%

5- Optimizing 1% 1% 2% 4% 5%

Organizations reporting to SEI

130 795 1179 1641 1998

Page 19: The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004.

Pitfalls of Pitfalls of ImplementationImplementation

Page 20: The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004.

How Long Does it Take?How Long Does it Take?

Implementing CMM does not occur Implementing CMM does not occur overnight.overnight.Implementing CMM is not merely a “paper Implementing CMM is not merely a “paper drill”.drill”.Typical times for implementation:Typical times for implementation: 3-6 months of preparation3-6 months of preparation 6-12 months of implementation6-12 months of implementation 3 months of assessment preparation3 months of assessment preparation 12 months for each new level12 months for each new level

Page 21: The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004.

Is it Perfect?Is it Perfect?

No! Some implementations do more No! Some implementations do more harm than good.harm than good. Complete re-vamp of processes to “get Complete re-vamp of processes to “get

certified” instead of smartly adapting certified” instead of smartly adapting processes.processes.

Process focus used more as a stick Process focus used more as a stick than as a carrot.than as a carrot.

Focusing on compliance instead of Focusing on compliance instead of improvement.improvement.

Page 22: The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004.

Overall BenefitsOverall Benefits

Defect rates have droppedDefect rates have dropped

Defect detection occurs earlierDefect detection occurs earlier

User requirements are documented, controlled, User requirements are documented, controlled, and managedand managed Especially important when users change their minds!Especially important when users change their minds!

Estimating improves and becomes more preciseEstimating improves and becomes more precise

Risk management is a practiceRisk management is a practice

Development processes remain agile!Development processes remain agile!

Page 23: The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004.

Implementation Best PracticesImplementation Best Practices

Be Realistic – Some processes will be Be Realistic – Some processes will be more ready than others.more ready than others.

Be Flexible – Allowing tailoring is key to Be Flexible – Allowing tailoring is key to adoption.adoption.

Be Open – The key is to learn how to do Be Open – The key is to learn how to do things better, not how to “comply”.things better, not how to “comply”.

Be Patient – It does not happen overnight.Be Patient – It does not happen overnight.

Page 24: The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004.

For More InformationFor More Information

CMM Softcopy: CMM Softcopy: http://www.sei.cmu.edu/cmm/obtain.cmm.htmlhttp://www.sei.cmu.edu/cmm/obtain.cmm.html Overview article: in SME Guidebook and atOverview article: in SME Guidebook and at

http://www.sei.cmu.edu/publications/documents/96.reports/96.ar.cmm.v1.1.hhttp://www.sei.cmu.edu/publications/documents/96.reports/96.ar.cmm.v1.1.htmltml

CMMI Sources:CMMI Sources: CMMI Softcopy: CMMI Softcopy: http://www.sei.cmu.edu/cmmi/models/models.htmlhttp://www.sei.cmu.edu/cmmi/models/models.html Transitioning to CMMI – A Guide for Executives Transitioning to CMMI – A Guide for Executives

http://www.sei.cmu.edu/cmmi/publications/exec.pdfhttp://www.sei.cmu.edu/cmmi/publications/exec.pdf


Recommended