GEF492 ppt16 Capability Maturity Model CMM

1
GEF492 ppt16 Capability Maturity Model (CMM)
Royal Military College of Canada Electrical and
Computer Engineering

• Dr. Terry Shepard
• shepard_at_rmc.ca
• 541-6031

Contributions from Major JW Paul, Michelle
Crane, Maj. Ron Smith,
Reference HvV 6.6
2
What is the purpose of 492?

• Software Processes and Work Products
• The implication is that by following an effective
  process and building better work products one
  will produce better software
• We have looked at many variations - how do we
  know if an organization is using a given set of
  concepts - or just using the buzzwords?
• Partial answer CMM
• there are trained appraisers for CMM
• Standard CMMI Appraisal Method for Process
  Improvement (SCAMPISM)
• also for other standards such as ISO 9000
• CMM appraisal being applied to agile processes.

3
Observations that motivated CMM

• productivity and quality gains from methodologies
  and technologies not near what was expected in
  the early 80s
• difficult to do better in a chaotic process
• in undisciplined organizations, most projects
  produce poor results
• in undisciplined organizations, some projects
  produce excellent results
• usually the result of heroic effort
• repeating the result means repeating the heroics

4
The Birth of CMM

• 1986, the Software Engineering Institute (SEI),
  investigated a maturity framework (Watts
  Humphrey)
• 1987 questionaires
• software capability evaluation
• maturity questionaire
• 1991 CMM (later renamed the SW-CMM)
• a set of key processes and recommended practices
• guidance on how to gain control of their process
  and how to evolve toward a culture of software
  engineering and management excellence

5
Process Standards we mostly dont have time to
look at
DoD-Std 2167A
SW CMM
EIA/IEEE J-Std-016
Mil-Std 498
IEEE/EIA Std 12207
ISO 9000 series
ISO/IEC 12207
Reference http//www.software.org/quagmire/
6
Not Just Software CMM
SW CMM
7
Decoding abbreviations

• SCE Software Capability Evaluation
• SCDE Software Development Capability Evaluation
• SA-CMM Software Acquisition
• P-CMM People
• SE-CMM Systems Engineering
• SSE-CMM Systems Security Engineering
• IPD-CMM Integrated Product Development
• CMMI CMM Integration

8
Capability Maturity Model (CMM)

• used as a standard for appraising the current
  state of the organizations 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 areas
  (KPAs)
• a CMM-based maturity questionnaire may be used
  to assess the software capability of a particular
  organization
• government may use this to assess the capability
  of potential software development contractors

9
SW-CMM Maturity Levels
10
Software Process Improvement

• Can be based on increasing maturity level in the
  Software Capability Maturity Model
• Other options are available
• ISO 9000 certification
• ISO 15504 (SPICE)
• Software Process Improvement and Capability
  dEtermination
• introduction of an agile method
• See www.spin.org (Ottawa Software Process
  Improvement Network)
• many other SPINs exist

11
The Immature Organization

• processes improvised
• if process specified, it is not followed
• managers focuses on fighting fires
• schedules and budgets routinely exceeded
• quality and function compromised to meet schedule
• no objective basis for judging product quality
• quality-related activities often eliminated due
  to schedule pressures

12
Common Aspects of Maturity

• 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

13
CMM Levels

• 1 Initial Individual Effort and Heroics
• 2 Repeatable Basic Management Practices
• 3 Defined Documented Standard Process
• 4 Managed Product and Process Quality
• 5 Optimizing Continuous Process Improvement

14
The Five Levels of SW-CMM

• Level 1Initial
• software process is ad hoc, maybe even chaotic
• few processes are defined success depends on
  individual effort and heroics
• Level 2 Repeatable
• basic 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
15
The Five Levels of SW-CMM (contd)

• Level 3 Defined
• software 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 organizations standard software process for
  developing and maintaining software

Reference www.sei.cmu.edu/cmm/cmm_sum.html
16
The Five Levels of SW-CMM (contd)

• Level 4 Managed
• detailed measures of the software process and
  product quality are collected
• both the software process and products are
  quantitatively understood and controlled
• Level 5 Optimized
• continuous 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
17
SW-CMM Structure
18
Common Features

• Commitment 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 organizations
  activities conform to requirements, processes,
  and procedures.

19
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

20
Key Process Areas (contd)

• KPAs are enhanced in succeeding levels
• to achieve a maturity level, the KPAs for that
  level must be satisfied
• there are other processes deemed to be not key to
  achieving a maturity level they are not
  addressed by the model

21
Key Process Areas (KPAs)

• Individual Effort Heroics (no KPAs)
• Requirements Management
• SW Project Planning
• SW Project Tracking Oversight
• SW Subcontract Management
• SW Quality Assurance
• SW Configuration Management
• Organization Process Focus
• Organization Process Defintion
• Training Program
• Integrated SW management
• SW Product Engineering
• Intergroup Coordination
• Peer Reviews
• Quantitative Process management
• SW Quality Management
• Defect Prevention
• Technology Change Management
• Process Change Management

1
initial
2
repeatable
3
defined
4
managed
5
optimizing
22
SW-CMM Process Maturity Levels
Optimizing (5)
Continuously Improving Process
Process Control
Managed (4)
Predictable Process
Process Measurement
Defined (3)
Standard, Consistent Process
Process Definition
Repeatable (2)
Disciplined Process
Basic Management Control
Initial (1)
23
The Initial Process (no KPAs)

• Risk of total chaos
• No management mechanism in place to plan and
  track the work of individuals
• If procedures are established they are abandoned
  during a crisis
• PM Panic Management (make the biggest fire
  smaller)
• tends to be continuous
• capability of org capability of individuals

Initial (1)
24
To Improve to Repeatable Process

• Understand the difference between speed and
  progress
• Basic project control
• Project management
• project size estimation
• Management oversight
• quarterly review of process
• Quality assurance
• establish a QA organization (? 5-6 of
  development org)
• Change control

25
The Repeatable Process

• Provides control over the way the organization
  establishes its plan and commitments
• basic software management controls exist for
  tracking cost, schedule and functionality
• Draws on experience doing similar work
• realistic project commitments based upon previous
  results

Repeatable (2)
Basic Management Control
26
Repeatable KPAs

• Software configuration management
• Software quality assurance
• Software subcontract management
• Software project tracking and oversight
• Software project planning
• Requirements management
• major risks at this level
• introduction of new tools
• development of a new type of product
• major organizational changes

27
Getting to the Defined Process

• Establish a process group
• ? 1-3 of development org
• Establish a development process architecture
• describes the technical and management activities
  for proper execution of the development process
• Introduce a family of software engineering
  methods and technologies

28
The Defined Process

• Processes for development and maintenance of
  software is standardized across the corporation
• software engineering is integrated into the
  larger engineering management processes
• The Acid-test
• When faced with a crisis they will continue to
  use the process that has been defined (might
  happen at level 2 as well)
• But only qualitative
• Little data to support the effectiveness of the
  process
• need to move to a quantitative process

Defined (3)
Process Definition
29
Defined KPAs

• Organization process focus
• Organization process definition
• Training program
• Integrated software management
• Software product engineering
• Intergroup coordination
• Peer reviews (including inspections)

30
To Improve to the Managed Process

• Establish basic process measurements to identify
  quality and cost of each process step
• cost-benefit analysis aimed at continuous
  improvement of the process in a generic way
• Establish a process database and provide
  resources to maintain it (gathering of data)
• Assess the quality of the product at each step
• monitor and revise product quality goals as needed

31
The Managed Process
Managed (4)

• Productivity and quality are quantitatively
  measured across the organization
• Key software processes are instrumented
• statistical quality control is employed
• Definition of the measured data is key
• only gather what you need ()
• process data must not be used to compare projects
  or evaluate individuals

Process Measurement
32
Managed KPAs

• Quality management
• Quantitative process management

33
To Improve to the Optimizing Process

• Causal analysis
• eliminate the causes of defects
• Orderly transition of new technologies into the
  organization
• Use process data to analyze and change the
  process
• continuous improvement
• of process to improve product quality
• of productivity
• of time needed to develop

34
The Optimizing Process
Optimizing (5)
Process Control

• Organizational focus on continuous process
  improvement is supported by quantitative trend
  analysis as to process strengths and weaknesses
• Process innovations and new technologies are
  introduced when supported by cost benefit
  analysis
• Data is available to tune the process itself
• Ability to put the resources where it counts

35
Optimizing KPAs

• Process change management
• Technology change management
• Defect prevention

36
CMM vs XP
CMM LEVEL

• Individual Effort Heroics
• Requirements Management
• SW Project Planning
• SW Project Tracking Oversight
• SW Subcontract Management
• SW Quality Assurance
• SW Configuration Management
• Organization Process Focus
• Organization Process Defintion
• Training Program
• Integrated SW management
• SW Product Engineering
• Intergroup Coordination
• Peer Reviews
• Quantitative Process management
• SW Quality Management
• Defect Prevention
• Technology Change Management
• Process Change Management

1
- - - - - - -
2
3
4
5
37
CMM representations

• two representations
• provide 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
38
CMM Representations (contd)

• Representation 1. focus on the organization as a
  whole and provide a road map of successive stages
  aimed at improving the organizations ability to
  understand and control its process
• staged view (comparable to SW-CMM)
• Representation 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
39
Representations (contd)

• each representation is a 600 page document
• equivalent staging
• sometimes desirable to convert an organizations
  capability level achievements into a maturity
  level
• cant translate from maturity level back
  capability level

Reference Menezes, CrossTalk
www.stsc.hill.af.mil/cmmi/more_cmmi.asp
40
Continuous Representation

• groups process areas into
• process management
• project management
• engineering
• support
• for each group, assigns a rating from 0 to 5,
  according to an organizations performance on
  process areas in that group

41
Staged Representation

• groups process areas by maturity level
• allows an overall assessment leading to an
  assessment of the maturity level observed in an
  organization

42
Some Differences between Representations
Reference www.sei.cmu.edu/cmmi/adoption/cmmi-faq
.html
43
Issues 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
44
Issues (contd)

• 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
45
Issues (contd)

• 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
• however, agile methods may be able to be mapped
  on to CMM stay tuned!

Reference Royce, CMM vs. CMMI
46
Evolution 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

47
Value and Future of CMM

• Surprise, surprise - CMM is not a silver bullet
• a mature process is no guarantee of a quality
  product
• Not well suited for smaller companies / projects
• Personal Software Process (PSP) next set of
  slides is one attempt to address this need
• Crude and harsh 5-point scale in staged
  representation continuous mitigates this
• if you fail just one of the KPAs, you fail the
  level
• CMMs now exist for software, people, software
  acquisition, systems engineering and integrated
  product development
• latest initiative (2001) CMM Integration (CMMI)

48
State of the Industry
Goal for most organizations is to achieve Level
3. Royce
49
September 2005
50
September 2005