CAPABILITY MATURITY MODEL INTEGRATED- DETAILED OVERVIEW (Staged Representation) Stephen Gristock (CMM/CMMI Lead Assessor)

1
CAPABILITY MATURITY MODEL INTEGRATED- DETAILED
OVERVIEW(Staged Representation) Stephen
Gristock (CMM/CMMI Lead Assessor)

2

• Global Media Information (150 years)
• 21,000 staff/140 Countries
• Local Process Initiatives (pre96)
• Corporate Process Improvement (CMM since 1996)
• Program Scope 60 groups world-wide (development
  and business)
• CMMI Partnership/Transition Program

3
Class Objectives

• Provide an understanding of the structure and
  content of CMMI
• Compare CMMI with CMM and address options for
  transitioning
• Discuss CMMI assessment implications
• Do you have any other expectations?

4
Conduct

• Please ask questions anytime
• Some questions may be posted to the parking lot
• There will be regular breaks for off-line
  discussion and exercises

5
Agenda

• PART1 Introduction
• Process Improvement Background
• PART2 CMMI OVERVIEW
• CMMI High-level Overview
• CMMI Model Architecture
• PART3 CMMI Process Areas
• Level 2
• Level 3
• Levels 45
• Process Area Interrelationships
• PART4 CMMI CMM
• Transitioning From CMM to CMMI
• PART5 CMMI Assessments
• CMMI Assessment Considerations
• RE-CAP CLOSE

6
PART 1 INTRODUCTION
7
Back To Basics!
8
Perceptions (or misconceptions) Of Process
9
Dealing With ProcessProcess exists whether we
acknowledge it or not. The only question is- do
we take a structured and systematic approach to
managing it, or do we allow it to develop
organically?
10
Some Process Improvement Principles (Re)Visited

• Provide structure, clarity, repeatability and
  accountability
• Fully leverage staff capabilities (by reducing
  unhealthy levels of dependence on key
  individuals)
• Measurement is a key to understanding and driving
  Process
• Need a strong correlation between business
  and Process goals
• Use models as frameworks- not rules!
• Process is for the entire organization

11
The Process Improvement Universe
SA-CMM
P-CMM
ISO/SPICE
SW-CMM
SEI CMM
IEEE
TRILLIUM
US MIL-STDs
DOD
SE-CMM
DODs
CMMI
BALDRIDGE
EIA
ISO
SDCE
ISO Series
BS series
IPD-CMM
TICKIT
12
Characteristics of an Immature Process

• Ad hoc process improvised by practitioners and
  their management.
• Not rigorously followed or enforced.
• Highly dependent on current practitioners.
• Cost and schedule problems likely.
• Product functionality and quality may be
  compromised to meet schedule.
• Use of new technology risky.
• Quality difficult to predict.

13
Characteristics of a Mature Process

• Consistent with the way work actually gets done.
• Defined, documented, and continuously improving.
• Supported visibly by management and engineering.
• Well controlled-process compliance is audited and
  enforced.
• Product and process measurement used.
• Disciplined use of technology.

14
Software Process Management Models

• The quality of a software system is highly
  influenced by the quality of the process used to
  develop and maintain it. This implies focus on
  process as well as product.
• But Models are simplifications of the real world
  so
• Interpretation and tailoring must be aligned to
  business objectives.
• Judgement is necessary to use models correctly
  and with insight.

15
Benefits Of Model-based Improvement

• Establishes a common language.
• Forges a shared vision.
• Builds on a set of processes and practices
  developed with input from a broad selection of
  the software community.
• Provides a framework for prioritizing actions.
• Provides a framework for performing reliable and
  consistent appraisals.
• Supports industry-wide comparisons.

16
What Is Process Maturity?

• Process maturity measures the extent to which a
  specific process is
• Defined
• Managed
• Measured
• Controlled
• Effective

17
What are the Benefits of a Mature Process?

• About 85 of the problems are caused by the
  process, not the people.
• People develop more fully to their potential and
  are more effective within the organization.
• By defining, measuring, and controlling the
  process, improvements are more successful and
  sustained.
• There is an increased likelihood of successful
  introduction of appropriate technology,
  techniques, and tools.

18
PART 2 CMMI OVERVIEW
19
High-Level Overview
20
Software Engineering Institute

• Formed 1984
• Carnegie Mellon Univ.
• Govt/Commercial funding
• Center Of Excellence For Software And Technology
• CMM launched 1990
• CMMI launched 2000

21
Some CMM/CMMI Users

• BULL, Computer Science Corporation, GTE,
• Motorola, IBM, GEC Marconi, UK MOD, US DOD,
• Reuters, Siemens, Nokia, Xerox, Volvo, Glaxo,
• Federal Express, Texaco, BOEING, Citicorp,
• Lloyds Bank, JP MorganChase, Honeywell, Unisys,
• Bellsouth Telecom, Paine Webber, Hughes
• Aerospace, Caterpillar Inc, CIGNA, EDS, Texas
• Instruments, DHL, Oracle, Thomson CSF, Lockheed
• Martin, Alcatel, Eastman Kodak, GE Info Systems,
• Telcordia, Sprint, Intel, Westinghouse, Ericsson
• 450 Companies/Organizations, 1900 Groups

22
Why CMMI?

• Industry proven approach
• Opportunity to be an early adopter
• Flexible and adaptive
• Process Improvement vs. Process Attainment (ISO)
• Wide business scope (but still specific to
  technology domain)
• Measurement

23
Scope Of CMMI

Business/Product Lifecycle
CMM
CMMI
CMMI
24
CMMI Model Architecture
25
CMMI Base

• Integrate models
• CMM SW V2.0 draft C
• Systems Engineering Capability Model
• IPPD
• Software Acquisition
• v1.0 Launched Aug 2000
• v1.1 Launched Dec 2001

26
Integrating Models
SW-CMM
SE-CMM
CMMI
SAM
IPPD
SPICE
27
CMMI Representations

• Staged
• Goals-Process Areas-Practices
• Maturity levels (1-5)
• Continuous
• Goals-Process Areas-Practices
• Capability levels (0-5)
• This class addresses the Staged
• Representation in detail with a summary
• review of the Continuous Representation

28
CMMI Representations

• The representation defines the way an
  organisation approaches process improvement
• The Staged Representation
• The process areas are grouped into Maturity
  levels. The organisation approaches the Maturity
  levels one at a time, in a pre-set order.
• The Continuous Representation
• The process areas are group by category. The
  Organisation selects a set of process areas to
  improve certain selected parts of the business

29
CMMI Continuous Representation
30
CMMI Continuous PAs
31
CMMI Capability Levels
32
CMMI Continuous Structure
CAPABILITY LEVEL
5Optimizing
PROCESS AREAS
4Quantative
GOALS
3Defined
PRACTICES
2Managed
SUBPRACTICES
1Performed
GENERIC SPECIFIC
1Initial
0Incomplete
33
CMMI Staged Representation
34
CMMI Maturity Levels
35
Staged CMMI Structure
MATURITY LEVELS
5Optimal
SUBPRACTICES
PROCESS AREAS
4Metrics
PRACTICES
3Org
GOALS
2Project
1Initial
36
Generic Goals/Practices

• PP RM CM

GENERIC
Goal
Practice
37
CMMI Structure- REI

• REQUIRED
• Specific/Generic Goals
• EXPECTED
• Specific/Generic Practices
• INFORMATIVE
• Sub-practices/Elaborations

38
Continuous vs. Staged Representation

• STAGED
• Maturity levels well understood sequencing
  delivers
• benefits most efficiently
• Easier to compare against competitors and
  industry
• Staged software model already widely understood

• CONTINUOUS
• Capability profile gives more granularity than a
  simple maturity level
• But, no explicit mapping of inter-dependencies
  between PAs
• Can focus on specific PAs to implement, so
  enables
• tailoring to business needs

39
Key Points

• CMMI provides an enterprise-wide model for
  process improvement (SW, SE, IPPD, SAM)
• Initial emphasis on Project Management
• CMMI provides flexibility/granularity
• CMMI contains an enhanced version of the SW-CMM
  (v2.0)
• Staged Representation is simpler to implement and
  provides and easier transition path from SW-CMM

40
Exercise

• Discuss the differences between the Staged and
  Continuous Representations
• What factors influence use of one over the other?

41
PART 3 CMMI PROCESS AREAS
42
CMMI Level 2 Process Areas
43
Repeatable Maturity Level (2)

• An organization at the Repeatable Maturity Level
• Has established effective project management.
• Documents and follows the project management
  process.
• Uses organizational policies to guide the
  projects in establishing management process.
• Repeats successful practices developed during
  previous projects.

44
Requirements Management

• Requirements are gathered, docd and approved by
  appropriate staff
• Requirements are used as a basis for planning
• Changes are tracked and approved
• Progress against requirements
  is tracked
• Requirements traceability is
  maintained
• See RD at L3

45
(No Transcript)
46
Project Planning

• Proj planning involves appropriate staff
• A Software lifecycle is selected used
• Estimation/Planning processes docd
• Effort, cost, risk capacity are included
• A project plan is prepared that considers roles,
  planning data and commitments

47
(No Transcript)
48
Project Monitoring and Control

• Tracking data is retained (actual v plan)
• The schedule is maintained and corrective action
  made
• Formal reviews (incl risks) take place at
  milestones
• Reporting mechanisms are in place

49
(No Transcript)
50
Process and Product Quality Assurance

• A PPQA Plan is prepd
• PPQA participate in planning
• PPQA group periodically audit projects (incl
  artifacts) and report results
• Deviations follow an escalation path
• Trained PPQA group (reps and mgr)

51
Optimum PPQA/SQA Organization
52
(No Transcript)
53
Configuration Management

• CM plan (incl CM List) exists and used
• A CM library is established
• SWPs are baselined (for auditing) and change
  procedures are docd. CM status is reported
• Release management procs are docd
• An SCCB approves change

54
(No Transcript)
55
Supplier Agreement Management

• A docd process for Selection
• Contract Plan
• Plan used to track (changes approved)
• Reviews at milestones
  (maybe PPQA)
• Delivery/review/testing/acceptance
• 3rd party performance

56
(No Transcript)
57
Measurement and Analysis

• Sets the org up to evolve its metrics thru
• Basic proj management measures, to-
• Org standard measures, to-
• Statistical control of selected sub-processes
  according to business needs
• Requires much more than Me Common
  Feature under CMM

58
(No Transcript)
59
Level 2 Generic Goal/Practice Summary

• GG2 Institutionalize a Managed Process
• 2.1 Establish an Organizational Policy (CO)
• 2.2 Plan the Process (AB)
• 2.3 Provide Resources (AB)
• 2.4 Assign Responsibility (AB)
• 2.5 Train People (AB)
• 2.6 Manage Configurations (DI)
• 2.7 Identify and Involve Stakeholders (DI)
• 2.8 Monitor and Control the Process (DI)
• 2.9 Objectively Evaluate Adherance (VE)
• 2.10 Review Status with Higher-Level Management
  (VE)

60
Exercise

• Name the process areas at the Repeatable Level
  (Level 2).
• Discuss the purpose of each of the process areas.

61
CMMI Level 3 Process Areas
62
Defined Maturity Level (3)

• An organization at the Defined Maturity Level
• Builds on the project management foundation of
  Level 2.
• Controls a process by defining, documenting,
  understanding, training and measuring.
• Builds processes that empower the individuals
  doing the work.

63
Organizational Process Focus

• This process area addresses
• Identification of PI opportunities
• Establishment of PI infrastructure
• Planning and execution of PI program

64
(No Transcript)
65
Organizational Process Definition

• Requirements for this process area
• Establish and maintain a usable
  set of organizational process assets
  including the OSSP
• Acknowledges that an organization may utilize
  more than one standard process to handle its
  product lines and business
• Create an Organizational Measurement Repository

66
OSSP- Example
67
(No Transcript)
68
Organizational Training

• This process area has seen no significant changes
  from CMM, still addresses
• Identification of training needs
• Deliver and evaluate training

69
(No Transcript)
70
Integrated Project Management

• Emphasizes the need to integrate the concepts in
  the Project Plan and all supporting plans such
  as
• Quality assurance plans
• Configuration management plans
• Risk management strategy
• Verification strategy
• Validation strategy
• Product integration plans

71
(No Transcript)
72
Risk Management

• The concepts inherent to Risk Management
• Risk Identification
• Risk Assessment
• Risk Analysis
• Risk Prioritization
• Risk Mitigation
• Risk Contingency Planning

73
(No Transcript)
74
Requirements Development

• The concepts in Requirements Development are
  consistent with modern publications
• Clearly defines the need for identification and
  care of stakeholders (more customer focus)

75
(No Transcript)
76
Technical Solution

• Technical Solution practices apply not only to
  the product and product components but also to
  services and product-related processes
• Technical Solutions are developed interactively
  with product or product component requirements
  definition
• Technical Solution stresses the need for
  developing alternative solutions

77
(No Transcript)
78
Product Integration

• Product Integration presents the concepts to
  achieve complete product integration through
  progressive assembly of product components
  according to a defined strategy
• It stresses the careful analysis and selection of
  the optimum integration strategy
• The basis for effective product integration is an
  integration strategy that uses combinations of
  techniques in an incremental manner

79
(No Transcript)
80
Verification did we build/deliver what was
specified?

• Captures the ideas of using
• Reviews
• Load, stress and performance testing
• Simulation/functional tests
• Observations and demonstrations

81
(No Transcript)
82
Validation did we build/deliver what was needed?

• Stronger emphasis on ensuring that the system
  will perform as intended in the operational
  environment from a user /end-user/client
  perspective (UAT, Customer survey)

83
(No Transcript)
84
Decision Analysis Resolution

• Decision and Analysis presents the concepts of
  identifying alternatives to issues that have a
  significant impact on meeting objectives,
  analyzing the alternatives,
• and selecting one or
• more that best support
• prescribed objectives

85
(No Transcript)
86
Level 3 Generic Goal/Practice Summary

• Implement L2 Generic Goals and Practices and-
• GG2 Institutionalize a Defined Process
• 3.1 Establish a Defined Process (AB)
• 3.2 Collect Improvement Information (DI)

87
Exercise

• Name the process areas at the Defined Level
  (Level 3).
• Discuss the purpose of each of the Level 3
  process areas.

88
CMMI Level 4 Process Areas
89
Quantitatively Managed Maturity Level (4)

• An organization at the Quantitatively
• Managed Maturity Level applies the
• principles of statistical process control to
• address special causes of process variation.

90
Level 4

• Quantitative Process Performance
• Through definition and systematic collection of
  key process attributes, use quantitative
  measures to drive process enhancement
• Quantitative Project Management
• Use project-specific quantitative measures to
  drive the selection, deployment and enhancement
  of project processes

91
CMMI Level 5 Process Areas
92
Optimizing Maturity Level (5)

• An organization at the Optimizing Maturity
• Level
• Identifies and eliminates common causes of poor
• performance.
• Continually improves the process via process and
  technology change management.

93
Level 5

• Organizational Innovation Deployment
• Identify new or existing innovative practices
  and/or tools that measurably enhance the
  organizations process capability
• Causal Analysis Resolution
• Through deployment of standard analyses identify
  and remove causes of defects and other problems
  and implement measures to prevent reoccurrence

94
Exercise

• Name the process areas at the Quantitative and
  Optimizing Levels (Levels 4 and 5).
• Discuss the purpose of each of the process areas.

95
CMMI Process Areas Interrelationships
96
Interrelationships Level 2 Project Management
Process Areas
Status, issues, results
PMC
of process and
product evaluations
Corrective
measures and analyses
action
Replan
Corrective action
What
To Monitor
What To Build
Status, issues,
PP
results
What To Do
of progress and
milestone
Engineering and Support
Commitments
reviews
process areas
Plans
Measurement needs
SAM
Supplier
agreement
Product component requirements
Technical issues
Completed product components
Supplier
Acceptance reviews and tests
97
Interrelationships Level 2 Support Process Areas
Measurements,
Quality and
analyses
noncompliance
All process areas
issues
Information
needs
Processes and work products
standards and procedures
Configuration
Baselines
items
audit reports
change
requests
98
Interrelationships Level 3 Process Management
Process Areas
Organizations
process needs
and objectives
Training for Projects and
Senior
Support Groups in Std
Process and Assets
Management
OT
Organizations
business
Training needs
objectives
Std Process
and Other
Assets
Std Process
Project Management,
and Other
Support, and Engineering
Assets
OPF
OPD
process areas
Resources and
Coordination
Improvement information
(e.g., lessons learned, data, artifacts)
Process Improvement
Proposals Participation in
defining, assessing, and
deploying processes
99
Interrelationships Level 3 Engineering Process
Areas
100
Interrelationships Level 3 4 Project
Management Process Areas
Process Performance
Risk exposure due to
Objectives, Baselines, Models
unstable processes
QPM
Statistical Mgmt Data
Quantitative objectives
subprocesses
to
Organizations Std.
statistically manage
Processes and
Supporting Assets
RSKM
Identified risks
IPM
Lessons Learned,
Planning and
Performance Data
Projects
Process Management
Defined
process areas
Process
Coordination,
Risk
commitments,
Taxonomies
issues to resolve
and
Parameters
Corrective
Basic
Action
Engineering and Support
Project Management
process areas
process areas
Risk
Status
Risk Mitigation
Plans
101
Key Points

• Generic goals practices (SW-CMM Common
  Features) are common to each Process Area within
  a particular Maturity level
• Specific goals practices are unique to a
  Process Area
• Specific and Generic goals must be satisfied and
  maintained before progressing to the next
  Maturity Level

102
PART 4 CMMI CMM
103
Transitioning From CMM to CMMI
104
CMMI/CMM Some Key Differences

• SW-CMM
• Software specific
• Maturity Levels
• Common Features
• 6 Level 2 KPAs
• 7 Level 3 KPAs
• 1 L3 Engineering KPA

• CMMI
• Multi disciplinary
• Maturity Capability Levels
• Generic Goals/Practices
• 7 Level 2 PAs
• 11 Level 3 PAs
• 5 L3 Engineering PAs

105
Why CMMI? (1)

• SW-CMM is being End-of-lifed (in December 2003
  the SEI will no longer develop or deliver CMM
  material)
• The industry is moving in this direction- dont
  get left behind
• The path from CMM L2 to CMMI L2 is relatively easy

106
Why CMMI? (2)

• CMMI contains an enhanced version of the SW-CMM
  (based on unreleased CM v2.00)
• It may be deployed in non-software elements of
  your business and thereby provide stronger
  interfaces
• CMM still has great utility, but CMMI better
  reflects current industry thinking and methods

107
CMMI Staged Representation
Red new or significant changes, Blue
existed, now with greater emphasis
108
Minor DifferencesLevel 2
109
Requirements Management

• Requirements Management is expected
• to operate in parallel with Requirements
• Development (see Level 3)
• Traceability is now explicitly
• asked for in Requirements
• Management

110
Project Planning

• Stronger emphasis on
• stakeholders
• having a detailed WBS
• focus on project skill requirements
• data management of project data items

111
Project Monitoring and Control

• Monitoring Commitments has been elevated to
  specific practice level
• Monitoring Risks and Stakeholder Involvement is
  also more strongly emphasized in the CMMI
  compared to the SW-CMM

112
Process and Product Quality Assurance

• Stresses the objective evaluation of work
  products as well as processes
• Evaluation criteria must be formally
  established

113
Configuration Management

• The idea of Software Library has been replaced
  by the more encompassing Configuration
  Management System
• A configuration management system includes the
  storage media, the procedures, and the tools for
  accessing the configuration system

114
Major DifferencesLevels 2
115
Supplier Agreement Management

• Replaces the initial ideas found in SSM
• Now incorporates the original intent of SSM (and
  elements of IC), with far
  heavier emphasis on
  contracts

116
Measurement and Analysis

• New PA. Sets the org up to systematically develop
  and evolve its metrics.
• Requires much more than Me Common
  Feature under CMM

117
Key Points

• The CMMI contains the SW-CMM
• Transition from CMM Level 2 to CMM Level 3
  requires minimal effort
• CMMI Level 3 is significantly larger and more
  complex then CMM Level 3, but the benefits are
  greater

118
Exercise

• Discuss the primary differences between CMM and
  CMMI
• Consider the differing challenges for
  organizations transitioning from CMM L2 to CMMI
  L2 and CMM L3 to CMMI L3

119
PART 5 CMMI ASSESSMENTS
120
CMMI Assessment Considerations
121
SEI Appraisal Method Definitions

• SW-CMM
• CAF
• CMM Appraisal Framework
• CBA-IPI
• CMM Based Appraisal for Internal Process
  Improvement

• CMMI
• ARC
• Appraisal Requirements for CMMI (v1.1)
• SCAMPI
• Standard CMMI Appraisal Method for Process
  Improvement (v1.1)

122
Summary Of Significant Changes

• Transition Partners
• ARC (Assessment Classes)
• SCAMPI Modes
• SCAMPI Process
• Planning
• Practice Implementation Indicators
• Rating
• Archiving Results

123
TPWeb

• Registers Lead Appraisers
• Appraisal Set-ups
• Contains Appraisal Kit
• Online Process Appraisal Info System (PAIS)

124
ARC

• Appraisal Requirements CMMI
• Broad descriptions across Assm lifecycle
• Provides Classes of Appraisals
• A CLASS (Full- SCAMPI)
• B CLASS (Initial/incremental-Mini)
• C CLASS (Quick check/self)

125
SCAMPI Scope Variants

• Modes of Usage
• Supplier Selection/Process Monitoring
• Internal Process Improvement
• Discovery vs. Verification
• Addressed overheads incurred by larger model. In
  theory allows for more up-front affirmation of
  alignment with model by the assessed organization

126
Planning

• More options under modes of usage (IPI for us)
• Balancing discovery vs. verification upfront
  (Objective Evidence)
• Sponsors have a more active role in defining
  requirements and objectives
• Model scope is potentially more complex because
  of Representations and multiple models
• Organizational scope still (necessarily)
  ambiguous
• Tailoring must conform to MDD limits and be
  documented in the Appraisal Plan

127
Practice Implementation Indicators (PII)

• PIIs are the footprints that occur as a
  consequence of practice implementation
• Direct Artifacts (tangible work products-i.e.
  plan, spec)
• Indirect Artifacts (tangible by-products- i.e.
  metrics, minutes, logs)
• Affirmations (questionnaires, interviews)
• SCAMPI 1.1 focuses on PIIs rather than pure
  observations (CBA-IPI/SCAMPI 1.0)

128
Rating

• Goal (Specific Generic) rating
• Satisfied if all associated practices are
  characterized as Largely or Fully Implemented and
  the aggregation of weaknesses does not undermine
  this position
• Maturity Level rating
• All goals in all targeted and supporting PAs are
  satisfied
• Results are logged with SEI (via Tpweb-soon)

129
CLASS A- SCAMPI vs. CLASS-B MINI

• Larger sample
• Wider model scope
• Detailed plan
• Team (Lead Appraiser 4)
• Stringent rules of evidence
• Mandatory opening, draft
• Longer/more Interviews
• Lengthy data consolidation
• Final presentation to all staff
• Ratings and Findings
• Registered with SEI

• Minimal sample
• Narrow focus (model)
• Basic Plan
• Smaller Team
• Relaxed rules of evidence
• Optional opening, draft
• Shorter/less interviews
• Concise data consolidation
• Presentation to affected staff
• Scores Findings
• Not registered with SEI

130
Basic Assessment Steps
Scoping
Planning
Interviews
Delivery
Findings Scores
Consolidate
131
SCAMPI LA Track

• Qualification
• Intro To CMMI
• Intermediate CMMI
• SCAMP LA Course
• Observation (by independent)
• Lead 2 appraisals in 2 years
• Transition Partner (Appraisal License)
• Must go through an established Transition Partner
  (TPWeb)

132
Key Points

• SCAMPI Assessments contain new methods to off-set
  the increased work due to larger CMMI model
• SCAMPI Assessments must be delivered by an
  authorized Lead Assessor through a recognized
  Transition Partner
• The SEI now provides guidance on Mini assessments
  (ARC Class B)

133
RE-CAP CLOSE
134
CMMI Class- Key Summary

• CMMI provides an enterprise-wide framework for
  Process Improvement
• There are two representations (Staged and
  Continuous
• CMMI contains all the features of the SW-CMM and
  more
• Use mini assessments to establish a CMMI baseline
  and SCAMPI assessments to certify your
  organization

135
Questions?Contact Stephen Gristockgristock_at_op
tonline.netgristock_at_optonline.net