Upload
jackie72
View
1.620
Download
1
Tags:
Embed Size (px)
DESCRIPTION
Citation preview
CMM CMMI
CFICSE 2002 – ST07
Michelle L. Crane
CFICSE 2002 / ST07 - 2
ReferencesReferencesJames W. Moore, Software Engineering
Standards: A User’s Road Map, IEEE Computer Society, 1998.
www.software.org/quagmire www.sei.cmu.edu
publicationsCMM, etc.
Walker Royce, CMM vs. CMMI: From Conventional to Modern Software Management, www.therationaledge.com
Winifred Menezes, To CMMI or Not to CMMI: Issues to Think About. CrossTalk. Feb 2002.
CFICSE 2002 / ST07 - 3
OutlineOutline
Review of MotivationReview of SW-CMM
SW-CMM Maturity LevelsKey Process Areas (KPAs)Evaluation
SCESCDE
Problems with SW-CMM
CFICSE 2002 / ST07 - 4
Outline (cont’d)Outline (cont’d)
Other Capability Maturity ModelsSA-CMMP-CMMSE-CMMSSE-CMMIPD-CMM
CMMIPurpose of CMMICMMI Maturity LevelsRepresentations
CFICSE 2002 / ST07 - 5
Standards We Will LoveStandards We Will LoveDoD-Std2167A
ISO/IEC12207
EIA/IEEEJ-Std-016
Mil-Std498
IEEE/EIAStd 12207
Reference: http://www.software.org/quagmire/
SW CMM
ISO 9000series
supersedesbased onuses/references
CFICSE 2002 / ST07 - 6
But Not Just SW CMMBut Not Just SW CMM
SW CMM
CFICSE 2002 / ST07 - 7
SW-CMMSW-CMM
CFICSE 2002 / ST07 - 8
SW-CMM HistorySW-CMM History November 1986, the SEI and Mitre Corporation
begin developing process maturity framework 1987, a short article and questionnaire released
provide vehicle to identify areas in need of process improvement
1991, the Software Capability Maturity Model (SW-CMM) version 1.0 released; 1993, SW-CMM version 1.1 released (31 drafts to this point)
1996, work on SW-CMM version 2.0 begins; ends in October 1997 with draft ‘C’
CFICSE 2002 / ST07 - 9
Review of MotivationReview of Motivation
CFICSE 2002 / ST07 - 10
Motivating ObservationsMotivating Observations
productivity and quality gains from methodologies and technologies not near what was expected
difficult to do better in a chaotic processin undisciplined organizations, most projects
produce poor resultsin undisciplined organizations, some projects
produce excellent resultsusually the result of heroic effortrepeating the result means repeating the heroics
CFICSE 2002 / ST07 - 11
The Immature OrganizationThe Immature Organization
processes improvisedif process specified, it is not followedmanagers focuses on “fighting fires”schedules and budgets routinely exceededquality and function compromised to meet
scheduleno objective basis for judging product
qualityquality-related activities often eliminated
due to schedule pressures
CFICSE 2002 / ST07 - 12
The Mature OrganizationThe Mature Organization
organization-wide ability for managing development and maintenance
process communicated to staff; staff follow process
processes are “fit for use”processes are updated as necessary
CFICSE 2002 / ST07 - 13
The Mature Organization (cont’d)The Mature Organization (cont’d)
improvements developed through controlled pilot projects or cost/benefit analysis
managers monitor quality against an objective basis
schedules and budgets are realisticexpected results are usually achieved
CFICSE 2002 / ST07 - 14
Review of SW-CMMReview of SW-CMM
CFICSE 2002 / ST07 - 15
SW-CMM (or CMM)SW-CMM (or CMM)
Capability Maturity Model for Softwaremodel for
judging the maturity of the software processes of an organization
for identifying the key practices that are required to increase the maturity of these processes
developed by the software community with stewardship by the SEI
has become a de facto standard for assessing and improving software processes
Reference: www.sei.cmu.edu/cmm/cmm.html
CFICSE 2002 / ST07 - 16
SW-CMM (cont’d)SW-CMM (cont’d)
used as a standard for appraising the current state of an organization’s software process
used as a guide for identifying and prioritizing the actions comprising the software process improvement effort
made up of 5 levels and 18 key process areasa CMM-based maturity questionnaire may be
used to assess the software capability of a particular organization
CFICSE 2002 / ST07 - 17
SW-CMM Maturity LevelsSW-CMM Maturity Levels
Initial(1)
Repeatable(2)
Defined(3)
Managed(4)
Optimizing(5)
Basic ManagementControl
ProcessDefinition
ProcessMeasurement
ProcessControl
CFICSE 2002 / ST07 - 18
The Five Levels of SW-CMMThe Five Levels of SW-CMM
Level 1—Initialsoftware process is ad hoc, maybe even chaoticfew processes are defined; success depends on individual effort and heroics
Level 2 – Repeatablebasic project management practices to track cost, schedule, functionality
necessary process discipline is in place to repeat earlier successes on projects with similar applications
Reference: www.sei.cmu.edu/cmm/cmm_sum.html
CFICSE 2002 / ST07 - 19
The Five Levels of SW-CMM (cont’d)The Five Levels of SW-CMM (cont’d)
Level 3 – Definedsoftware process for both management and engineering activities is documented, standardized, integrated into a standard software process
all projects use an approved, tailored version of the organization’s standard software process for developing and maintaining software
Reference: www.sei.cmu.edu/cmm/cmm_sum.html
CFICSE 2002 / ST07 - 20
The Five Levels of SW-CMM (cont’d)The Five Levels of SW-CMM (cont’d)
Level 4 – Manageddetailed measures of the software process and product quality are collected
both the software process and products are quantitatively understood and controlled
Level 5 – Optimizedcontinuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies
Reference: www.sei.cmu.edu/cmm/cmm_sum.html
CFICSE 2002 / ST07 - 21
SW-CMM StructureSW-CMM Structure
CFICSE 2002 / ST07 - 22
Key Process Areas (KPAs)Key Process Areas (KPAs)
each maturity level (except 1) is decomposed into several key process areas that indicate the areas an organization should focus on to improve its software process
a cluster of related activities which collectively achieve a set of important goals
when the goals are accomplished on a continuing basis, the KPA is said to be institutionalized
CFICSE 2002 / ST07 - 23
Key Process Areas (cont’d)Key Process Areas (cont’d)
KPAs are enhanced in succeeding levelsto achieve a maturity level, the KPA for
that level must be satisfiedthere are other processes deemed to be
not key to achieving a maturity level; they are not addressed by the model
CFICSE 2002 / ST07 - 24
Key Process Areas (KPA)Key Process Areas (KPA)
Level 1 has none by definition
Level 2software project concerns related to establishing basic project management controls
requirements managementsoftware project planningsoftware project tracking and oversightsoftware subcontract managementsoftware quality assurancesoftware configuration management
Reference: www.sei.cmu.edu/cmm/cmm_sum.html
CFICSE 2002 / ST07 - 25
Key Process Areas (cont’d)Key Process Areas (cont’d)
Level 3address both project and organizational issues
organizational process focusorganizational process definitiontraining programintegrated software managementsoftware product engineeringintergroup coordinationpeer reviews
Reference: www.sei.cmu.edu/cmm/cmm_sum.html
CFICSE 2002 / ST07 - 26
Key Process Areas (cont’d)Key Process Areas (cont’d)
Level 4focus on establishing a quantitative understanding of both the software process and the software work products being built
process measurement and analysisquality managementdefect prevention
Reference: www.sei.cmu.edu/cmm/cmm_sum.html
CFICSE 2002 / ST07 - 27
Key Process Areas (cont’d)Key Process Areas (cont’d)
Level 5cover the issues that both the organization and the projects must address to implement continual, measurable software process improvement
technology innovationprocess change management
Reference: www.sei.cmu.edu/cmm/cmm_sum.html
CFICSE 2002 / ST07 - 28
Key PracticesKey Practices
each Key Process Area is described in terms of the key practices that contribute to satisfying its goals
describe the infrastructure and activities that contribute most to the effective implementation and institutionalization of the key process area
Reference: www.sei.cmu.edu/cmm/cmm_sum.html
CFICSE 2002 / ST07 - 29
Common FeaturesCommon FeaturesCommitment to Perform (CO)
groups all generic practices related to creating policies and securing sponsorship for process improvement efforts.
Ability to Perform (AB)groups all generic practices related to ensuring that the project
and/or organization has the resources it needs to pursue process improvement.
Directing Implementation (DI) groups the generic practices related to collecting, measuring, and
analyzing data related to processes. The purpose of these activities is to provide insight into the performance of processes.
Verifying Implementation (VE) groups all generic practices related to verifying that the projects
and/or organization’s activities conform to requirements, processes, and procedures.
CFICSE 2002 / ST07 - 30
State of the IndustryState of the Industry
Goal for most organizations is to achieve Level 3.
Royce
CFICSE 2002 / ST07 - 31
EvaluationEvaluation
one instrument for assessing is a software capability evaluation (SCE)
determines whether the organization “says what it does and does what it says”
by evaluating its software process (usually in the form of policy statements) and project practices
process captures “say what you do”project implementations demonstrate “do what you say”
Reference: Royce, CMM vs. CMMI
CFICSE 2002 / ST07 - 32
Back to the MapBack to the Map
CFICSE 2002 / ST07 - 33
SCESCE
Software Capability Evaluationpublished: Version 3.0, April 1996
method for evaluating the software process of an organization to gain insight into its process capability
version 3.0 based on SW-CMM version 1.1SCE team conducts a document review and
extensive interviewsobserved strengths and weaknesses are formally documented and then used to determine risk for a particular development
Reference: www.software.org/quagmire
CFICSE 2002 / ST07 - 34
SCE (cont’d)SCE (cont’d)
SCEs are designed to be used insource selection
help select a qualified contractorcontract monitoring
identify risksmeasure performance for incentive feesbaselining organizational performance
SCE does NOT determine an SEI SW-CMM Level
Reference: www.software.org/quagmire
CFICSE 2002 / ST07 - 35
Back to the MapBack to the Map
CFICSE 2002 / ST07 - 36
SCDESCDESoftware Development Capability Evaluation
published: 15 Jun 95structured methodology for assessing an
organization’s ability to develop software for mission-critical computer resources
primary purpose is to reduce acquisition risk for software-intensive systems
conducted as an integral part of the source selection process
addresses each offerer’s ability to develop the software required by a specific Request for Proposal
Reference: www.software.org/quagmire
CFICSE 2002 / ST07 - 37
Problems with SW-CMMProblems with SW-CMM
CFICSE 2002 / ST07 - 38
Issues with the CMMIssues with the CMM
key process areas (KPAs) focus mostly on activities and supporting artifacts associated with a conventional waterfall process
requirements specifications, documented plans, quality assurance audits and inspections, and documented processes and procedures
very few of the KPAs address the evolving results (i.e., the software product) and associated engineering artifacts (use case models, design models, source code, or executable code)
Reference: Royce, CMM vs. CMMI
CFICSE 2002 / ST07 - 39
Issues (cont’d)Issues (cont’d)
no emphasis on the architecting/design process, assessment process, or deployment process
which have proven to be key discriminators for project success
also overemphasizes peer reviews, inspections and traditional Quality Assurance “policing” methods
although manual reviews and inspections may be capable of uncovering 60% of errors, they rarely uncover the architecturally significant flaws…
Reference: Royce, CMM vs. CMMI
CFICSE 2002 / ST07 - 40
Issues (cont’d)Issues (cont’d)
most implementations of CMM drive organizations to produce more documents, more checkpoints, more artifacts, more traceability, more reviews, and more plans
thicker documents, more detailed information, and longer meetings are considered better
Reference: Royce, CMM vs. CMMI
CFICSE 2002 / ST07 - 41
Issues (cont’d)Issues (cont’d)
hard to accurately measure an organization’s current maturity level
CMM takes an activity based approach to measuring maturity
set of foundation project activities = Level 2
set of activities as an organization = Level 3
nothing that characterizes or quantifies whether you do these activities well enough to deliver the intended results
Reference: Royce, CMM vs. CMMI
CFICSE 2002 / ST07 - 42
More Short-Comings of CMMMore Short-Comings of CMM
not a silver bulleta mature process is no guarantee of a quality product
not well suited for smaller companies/projects
Personal Software Process (PSP) is one attempt to address this need
crude and harsh 5-point scaleif you fail just one of the KPAs, you fail the level
CFICSE 2002 / ST07 - 43
Evolution of CMMEvolution of CMM
initial Capability Maturity Model was developed specifically to address software process maturity
it was successfully adopted and used in many domains
other CMMs were developed for other disciplines and functions
CMMs now exist for software, people, software acquisition, systems engineering, and integrated product development
CFICSE 2002 / ST07 - 44
Other Capability Maturity Models
Other Capability Maturity Models
CFICSE 2002 / ST07 - 45
Back to the MapBack to the Map
CFICSE 2002 / ST07 - 46
SA-CMMSA-CMMSoftware Acquisition Capability Maturity Model
published: Version 1.01, December 1996a model for benchmarking and improving the
software acquisition processfollows the same architecture as the Capability
Maturity Model for Software (SW-CMM), but with a unique emphasis on
acquisition issuesneeds of individuals/groups planning software
acquisition effortsfocused on the Buyer’s or Acquirer’s Software
Acquisition Process
Reference: www.software.org/quagmire
CFICSE 2002 / ST07 - 47
SA-CMM Maturity LevelsSA-CMM Maturity LevelsLevel Focus Key Process Areas
Level 5Optimizing
Continuous process improvement
Acquisition Innovation ManagementContinuous Process Improvement
Level 4Quantitative
Quantitative management
Quantitative Acquisition ManagementQuantitative Process Management
Level 3Defined
Process standardization
Training ProgramAcquisition Risk ManagementContract Performance ManagementProject Performance ManagementProcess Definition and Maintenance
Level 2Repeatable
Basic project management
Transition to SupportEvaluationContract Tracking and OversightProject ManagementRequirements Development and ManagementSolicitationSoftware Acquisition Planning
Level 1Initial
Competent people and heroics
No KPAs at this levelReference: www.software.org/quagmire
CFICSE 2002 / ST07 - 48
Back to the MapBack to the Map
CFICSE 2002 / ST07 - 49
P-CMMP-CMM
People Capability Maturity Modelpublished: July 2001
describes the key elements of managing and developing the work force of an organization
describes an evolutionary path from an ad hoc approach to managing the workforce
to a mature, disciplined development of the knowledge, skills, and motivation of the people that fuel enhanced performance
Reference: www.software.org/quagmire
CFICSE 2002 / ST07 - 50
P-CMM (cont’d)P-CMM (cont’d)
purpose is to enhance the readiness of software development and information systems organizations to undertake increasingly complex applications by helping them to attract, grow, motivate, deploy, and retain the talent necessary to improve their software development capability
Reference: www.software.org/quagmire
CFICSE 2002 / ST07 - 51
P-CMM Maturity LevelsP-CMM Maturity LevelsLevel Key Process Areas
Level 5Optimizing
Continuous Workforce InnovationCoachingPersonal Competency Development
Level 4Managed
Organizational Performance AlignmentOrganizational CompetencyManagementTeam-Based PracticesTeam BuildingMentoring
Level 3Defined
Participatory CultureCompetency-Based PracticesCareer DevelopmentCompetency DevelopmentWorkforce PlanningKnowledge and Skills Analysis
Reference: www.software.org/quagmire
CFICSE 2002 / ST07 - 52
P-CMM Maturity Levels (cont’d)P-CMM Maturity Levels (cont’d)Level Key Process Areas
Level 2Repeatable
CompensationTrainingPerformance ManagementStaffingCommunicationWork Environment
Level 1Initial
No KPAs at this level
Reference: www.software.org/quagmire
CFICSE 2002 / ST07 - 53
Back to the MapBack to the Map
CFICSE 2002 / ST07 - 54
SE-CMMSE-CMMSystems Engineering Capability Maturity Model
published: November 1995describes the essential elements of an
organization’s systems engineering process that must exist to ensure good systems engineering
18 process areas (PAs) are grouped into categories
EngineeringProjectOrganization
Reference: www.software.org/quagmire
CFICSE 2002 / ST07 - 55
SE-CMM (cont’d)SE-CMM (cont’d)still 5 levels (counted in each PA?)
1 – Generic Practices2 – Planned and Tracked3 – Well-Defined4 – Quantitatively Controlled5 – Continuously Improving
built onto the Software CMM frameworkbut used the two-axis architecture of the ISO SPICE model
replaced SECM merged systems engineering model (EIA/IS 731)
Reference: www.software.org/quagmire
CFICSE 2002 / ST07 - 56
Back to the MapBack to the Map
CFICSE 2002 / ST07 - 57
SSE-CMMSSE-CMM
Systems Security Engineering CMMpublished: 1 Apr 99 (Version 2.0)
describes the essential characteristics of an organization’s security engineering process that must exist to ensure good security engineering
objective is to advance security engineering as a defined, mature, and measurable discipline
…
Reference: www.software.org/quagmire
CFICSE 2002 / ST07 - 58
Back to the MapBack to the Map
CFICSE 2002 / ST07 - 59
IPD-CMMIPD-CMM
Integrated Product Development Capability Maturity Model
published: no longer published; halted in Nov 1997
developed by Enterprise Process Improvement Collaboration (EPIC)
to serve as a framework for improvement of
processes for the entire product life cycle and processes for integrating product development efforts across the enterprise
Reference: www.software.org/quagmire
CFICSE 2002 / ST07 - 60
IPD-CMMIPD-CMM
built on a continuous model architecture like the Systems Engineering CMM
adds the concept of organizational stages, similar to organizational maturity levels in the SW-CMM
development halted in Nov 1997model had serious problems with complexity, overlap with other models, and lack of IPD content beyond team practices
EPIC decided to end the development and provide content to the CMMI effort
Reference: www.software.org/quagmire
CFICSE 2002 / ST07 - 61
So Many CMMsSo Many CMMs
many organizations found these models to be useful
but struggled with problems caused by overlap, inconsistencies, and integration
many organizations also confronted conflicting demands between these models and ISO 9001 audits or other process improvement programs
Reference: Royce, CMM vs. CMMI
CFICSE 2002 / ST07 - 62
Back to the MapBack to the Map
CFICSE 2002 / ST07 - 63
IntegrationIntegration
CMM Integration (CMMI) project was conceived as an initiative to integrate the various CMMs into a set of integrated models
reduce redundancy and eliminate inconsistency experienced by those using multiple standalone models
Reference: Royce, CMM vs. CMMI
CFICSE 2002 / ST07 - 64
Overview of CMMIOverview of CMMI
CFICSE 2002 / ST07 - 65
CMMICMMI
Capability Maturity Model Integrationpublished: draft version 1.02b, Dec 2001
includedsystems engineering and softwareIPPD (integrated product and process development)
some acquisition (draft)US DoD tasked the Software Engineering
Institute (SEI) to integrate the capability maturity model
SEI is the current steward of the CMMI model
Reference: www.software.org/quagmire
CFICSE 2002 / ST07 - 66
CMMI (cont’d)CMMI (cont’d)
source modelsSW-CMM version 2.0 draftEIA/IS 731 SECM (which replaced SE-CMM)draft version of IPD-CMM (integrated product development)
some items from SA-CMMthese sources will no longer be updated or
supported by their issuing organizationsgoal is to absorb more source models in
the same way
Reference: www.software.org/quagmire
CFICSE 2002 / ST07 - 67
CMMI Product Suite NamingCMMI Product Suite Naming
each CMMI model is given a name consisting of “CMMI-” followed by the abbreviation for the discipline
CMMI-SE/SW – systems engineering and software engineering integrated model
CMMI-SE/SW/IPPD – systems engineering, software engineering, integrated product and process development integrated model
CMMI-SE/SW/IPPD/SS - systems engineering, software engineering, integrated product and process development, supplier sourcing integrated model
Reference: www.sei.cmu.edu/cmmi/adoption/cmmi-faq.html
CFICSE 2002 / ST07 - 68
Purpose of CMMIPurpose of CMMI
to provide guidance for improving the organization’s processes and ability to manage the
developmentacquisitionmaintenance
of products and services
Reference: www.sei.cmu.edu/cmmi/general/
CFICSE 2002 / ST07 - 69
Purpose of CMMI (cont’d)Purpose of CMMI (cont’d)
places proven practices into a structure that helps the organization
assess its organizational maturity and process area capability
establish priorities for improvementguide the implementation of these improvements
Reference: www.sei.cmu.edu/cmmi/general/
CFICSE 2002 / ST07 - 70
Purpose of CMMIPurpose of CMMI
CMMI is a framework that describes the essential elements of an effective system or software engineering process
in the software context, forms the basis forsoftware process assessmentsoftware process improvementsoftware capability evaluation
related to ISO Software Process Improvement and Capability Evaluation (SPICE) program and ISO 15504
CFICSE 2002 / ST07 - 71
Core ConceptsCore Concepts
Software Process Capabilitythe range of expected results that can be achieved by following a software process
Software Process Performancethe actual results achieved by following a software process
Software Process Maturitythe extent to which a specific process is explicitly defined, managed, measured, controlled, and effective
CFICSE 2002 / ST07 - 72
CMMI Maturity LevelsCMMI Maturity Levels
Initial(1)
Managed(2)
Defined(3)
QuantitativelyManaged
(4)
Optimizing(5)
Disciplinedprocess
Standard,consistent
process
Predictableprocess
Continuouslyimprovingprocess
CFICSE 2002 / ST07 - 73
CMMI Maturity LevelsCMMI Maturity Levels
Initial(1)
Managed(2)
Defined(3)
QuantitativelyManaged
(4)
Optimizing(5)
Disciplinedprocess
Standard,consistent
process
Predictableprocess
Continuouslyimprovingprocess
Initial(1)
Repeatable(2)
Defined(3)
Managed(4)
Optimizing(5)
Basic ManagementControl
ProcessDefinition
ProcessMeasurement
ProcessControl
SW-CMMSW-
CMM
Not capability levels
CFICSE 2002 / ST07 - 74
Levels and Process AreasLevels and Process Areas
elements of CMMI are called Process Areas (not Key Process Areas or Focus Areas)
Reference: www.software.org/quagmire
CFICSE 2002 / ST07 - 75
The Five Maturity Levels of CMMIThe Five Maturity Levels of CMMI
Level 1 – Initialprocess maturity characterized by unpredictable results
ad hoc approaches, methods, notations, tools, and reactive management
translate into a process dependent predominantly on the skills of the team to succeed
Reference: Royce, CMM vs. CMMI
CFICSE 2002 / ST07 - 76
The Five Maturity Levels of CMMI (cont’d)The Five Maturity Levels of CMMI (cont’d)
Level 2 – Managedprocess maturity characterized by repeatable project performance
organization uses foundation disciplines forrequirements managementproject planningproject management and controlsupplier agreement managementproduct and process quality assuranceconfiguration managementmeasurement/analysis
key process focus is on project-level activities and practices
Reference: Royce, CMM vs. CMMI
CFICSE 2002 / ST07 - 77
The Five Maturity Levels of CMMI (cont’d)The Five Maturity Levels of CMMI (cont’d)
Level 3 – Definedprocess maturity characterized by improving project performance within an organization
consistent, cross-project disciplines for Level 2 key process areas are emphasized to establish organization-level activities and practices
additional process areasrequirements development
multi-stakeholder requirements evolutiontechnical solution
evolutionary design and quality engineering
Reference: Royce, CMM vs. CMMI
CFICSE 2002 / ST07 - 78
The Five Maturity Levels of CMMI (cont’d)The Five Maturity Levels of CMMI (cont’d)
product integration continuous integration, interface control,
change managementverification
assessment techniques to ensure that the product is built correctly
validation assessment techniques to ensure that the
right product is builtrisk management
detection, prioritization, and resolution of relevant issues and contingencies
Reference: Royce, CMM vs. CMMI
CFICSE 2002 / ST07 - 79
The Five Maturity Levels of CMMI (cont’d)The Five Maturity Levels of CMMI (cont’d)
organizational training establishing mechanisms for developing more
proficient peopleorganizational process focus
establishing an organizational framework for project process definition
decision analysis and resolution systematic alternative assessment
organizational process definition treatment of process as a persistent, evolving asset
of an organizationintegrated project management
methods for unifying the various teams and stakeholders within a project
Reference: Royce, CMM vs. CMMI
CFICSE 2002 / ST07 - 80
The Five Maturity Levels of CMMI (cont’d)The Five Maturity Levels of CMMI (cont’d)
Level 4 – Quantitatively Managedprocess maturity characterized by improving organization performance
historical results for Level 3 projects can be exploited to make trade offs with predictable results
additional Level 4 process areas includeorganizational process performance
setting norms and benchmarks for process performance
quantitative project management executing projects based on statistical quality-control
methods
Reference: Royce, CMM vs. CMMI
CFICSE 2002 / ST07 - 81
The Five Maturity Levels of CMMI (cont’d)The Five Maturity Levels of CMMI (cont’d)
Level 5 – Optimizedprocess maturity characterized by rapidly reconfigurable organizational performance
as well as quantitative, continuous process improvement
additional Level 5 process areas includecausal analysis and resolution
proactive fault avoidance and best practice reinforcement
organizational innovation and deployment establishing a learning organization that
organically adapts and improves
Reference: Royce, CMM vs. CMMI
CFICSE 2002 / ST07 - 82
Representations (cont’d)Representations (cont’d)
two representationsprovide alternative approaches to process improvement for familiarity with either approach
represent two different philosophical approaches to process improvement
Reference: Menezes, CrossTalk; www.stsc.hill.af.mil/cmmi/more_cmmi.asp
CFICSE 2002 / ST07 - 83
Representations (cont’d)Representations (cont’d)
1. focus on the organization as a whole and provide a road map of successive stages aimed at improving the organization’s ability to understand and control its process
staged view (comparable to SW-CMM)2. focus on individual processes, allowing
the organization to choose which process or set of processes need to have more capability
continuous view (comparable to systems engineering and IPD models)
Reference: Menezes, CrossTalk
CFICSE 2002 / ST07 - 84
Representations (cont’d)Representations (cont’d)
each representation is a 600 page document
equivalent stagingsometimes desirable to convert an organization’s capability level achievements into a maturity level
can translate back and forth betweenCMMI includes rules for determining which capability levels must be satisfied in each process area to achieve each maturity level
Reference: Menezes, CrossTalk; www.stsc.hill.af.mil/cmmi/more_cmmi.asp
CFICSE 2002 / ST07 - 85
ContinuousContinuous
groups process areas intoprocess managementproject managementengineeringsupport
for each process area, assigns a rating from 0 to 5, according to an organization’s performance
CFICSE 2002 / ST07 - 86
StagedStaged
groups process areas by maturity levelallows an overall assessment leading to
an assessment of the maturity level observed in an organization
CFICSE 2002 / ST07 - 87
Some Differences between RepresentationsSome Differences between Representations
Continuous Staged
process areas organized by process area categories
process areas organized by maturity levels
six capability levels (0-5) five maturity levels (1-5)
improvement is measured using capability levels that reflect incremental implementation of a particular process area
improvement is measured using maturity levels that reflect the concurrent implementation of multiple process areas
additional appendix describing equivalent staging; allows translation of a target profile into a maturity level
no equivalence concept to go from maturity level to a target profile
Reference: www.sei.cmu.edu/cmmi/adoption/cmmi-faq.html
CFICSE 2002 / ST07 - 88
SummarySummary
Review of MotivationReview of SW-CMM
Problems with SW-CMMOther Capability Maturity Models
SA-CMM, P-CMM, SE-CMM, SSE-CMM, IPD-CMM
CMMIPurpose of CMMICMMI Maturity LevelsRepresentations
CFICSE 2002 / ST07 - 89
??