Course Notes : Software Process Maturity CMM

1
Course Notes Software Process Maturity(CMM)

• 1st Semester 2002/2003
• School of Information Technology
• Northern University
• By
• Mazni Omar

2
OUTLINE

• What is CMM
• The evolution of the CMM
• Five levels of process maturity
• Understanding the maturity levels
• Characteristics of immaturity and maturity
• Process characterization
• Internal CMM structure
• How is CMM used in support process improvement
• Conclusion
• References

3
Software Process Maturity

• A measure of the long-term effectiveness of an
  organizations software engineering practices.
• Being rated at a certain level of maturity can be
  a contractual obligation for the software
  developer, required by the client.
• In this class we only focusing on
• Capability Maturity Model (CMM) - SEI

4
What is CMM?

• The application of process management and quality
  improvement concepts to software development and
  maintenance.
• A guide for evolving toward a culture of
  engineering excellence.
• A model for organizational improvement.
• The underlying structure for reliable and
  consistent software process assessments and
  software capability evaluations.

5
What is CMM?

• The CMM should support
• setting goals for senior management
• identifying priorities for process
  improvement
• identifying process capability of
  organizations
• predicting future process performance of
  projects
• industry-wide comparisons of the state of
  the
• practice

6
The evolution of the CMM

• Began in 1986 as the SEI and MITRE responded to
  the DoDs demands for better software.
• First brief description released in 1987 by Watts
  Humphrey.
• Formally evolved into the CMM, authored by Mark
  Paulk in 1992.
• Principle ideas
• Describes the key elements of an effective
  software process.
• Describes an evolutionary improvement path from
  an ad hoc, immature process to a disciplined,
  mature process.
• The CMM is composed of five maturity levels all
  but the first (Level 1) are, in turn, composed of
  key process areas (KPA). Each KPA is organized
  into five sections called common features which
  specify key practices. The key practices, when
  collectively addressed, accomplish the goals of
  the given KPA.
• An organization is graded according to the
  presence of key practices that support KPAs.

7
Five levels of process maturity

• A maturity level is a well-defined evolutionary
  plateau
• toward achieving a mature software process.
• Each maturity level provides a layer in the
  foundation
• for continuous process improvement.
• Each level comprises a set of process goals
  that, when
• satisfied, stabilize an important component of
  the
• software process.
• Achieving each level of the maturity framework
  
• establishes a different component in the
  software
• process, resulting in an increase in the
  process capability
• of the organization.

8
Five levels of process maturity

• Improvement is not a revolutionary activity.
  
• Improvement is achieved through many small
  actions.
• CMM is a framework for these small steps. By
• conceptualizing it in this manner it becomes
  clearer that
• improvement is incremental transitioning from
  one level
• to another implies the foundation required
  from the prior
• level is in place.
• The layered structure of the CMM implies moving
  from
• one level to another where the upper layer
  depends on
• the existence of the practices defined in the
  lower level.

9
Five levels of process maturity
10
Five levels of process maturity

• Initial
• The software process is characterized as ad hoc,
  and
• occasionally even chaotic.
• Few processes are defined,and success depends on
  individual effort.
• Repeatable
• Basic project management processes are
  established to
• track cost, schedule, and functionality. The
  necessary process
• discipline is in place to repeat earlier
  successes on projects with similar
• applications.

11
Five levels of process maturity
3) Defined The software process for both
management and engineering activities is
documented, standardized, and integrated into a
standard software process for the
organization. All projects use an approved,
tailored version of the organization's standard
software process for developing and
maintaining software. 4) Managed Detailed
measures of the software process and product
quality are collected. Both the software
process and products are quantitatively
understood and controlled.
12
Five levels of process maturity
5) Optimizing Continuous process improvement
is enabled by quantitative feedback from the
process and from piloting innovative ideas and
technologies.
13
Understanding the maturity level

• CMM is a descriptive model that provides
  details on essential
• operational activities at a particular
  maturity level.
• CMM is a normative model in it describes
  practices that
• characterize the normal types of behavior
  expected in a software
• organization. The intent is that the CMM is at
  a sufficient level of
• abstraction that it does not unduly constrain
  how the software
• process is implemented by an organization.

14
Understanding the maturity level

• The CMM is not prescriptive. it does not tell
  an organization how to
• improve.
• The CMM describes an organization at each
  maturity level without
• prescribing the specific means for getting
  there.

15
Understanding the maturity level
View of Level 1
The software process is a black box. Visibility
of the project's processes is not possible
16
Understanding the maturity level
View of Level 2
The customer requirements and work products are
controlled, and basic project management
practices have been established.
17
Understanding the maturity level
View of Level 3
The tasks that define the internal structure of
the boxes is visible. The internal structure
represents the way the standard software process
is applied to projects.
18
Understanding the maturity level
View of Level 4
The defined software processes are instrumented
and controlled quantitatively. Managers are able
to measure progress and problems.
19
Understanding the maturity level
View of Level 5
New and improved ways of building the software
are continually tried, in a controlled manner, to
improve productivity and quality. Disciplined
change is a way of life as inefficient or
defect-prone activities are identified and
replaced or revised.
20
Characteristics of Immaturity

• Software process improvised during the course of
  a project.
• Even if process is specified, it is not
  rigorously followed or enforced.
• Reactionary, focus on solving immediate crises.
• Hard deadlines often mean a compromise in
  functionality and/or quality.
• No objective basis for judging product quality or
  for solving process problems.
• Quality is difficult if not impossible to predict.

21
Characteristics of Maturity

• Able to manage software development and
  maintenance organization/project wide.
• There is a prescribed, mandated, and enforced
  process.
• Process is consistent with the way that work
  actually gets done.
• Process is updated and improved as necessary.
• Roles and responsibilities within the process are
  clear.
• Quality is measured and monitored, and an
  objective basis for judgment exists.
• The necessary infrastructure for supporting the
  process exists.
• Workers see the value in the process.

22
A Survey of High Maturity Organizations

• No organization type or structure seems to be
  correlated with maturity.
• Most have multiple quality improvement
  initiatives.
• Typically use incremental or evolutionary process
  models.
• Most measure customer/user satisfaction and have
  meaningful interaction with them.
• Most use cost models (functionality, schedule gt
  cost)
• Typically incorporate risk management into their
  process.
• Typically have an independent SQA group and embed
  SQA into the process.
• Typically use Internet/intranet to deploy process
  assets.
• Most use a consistent, though not formal, process
  notation.
• Most have required training in people issues -
  interpersonal skills, team building.
• Typically use both inspections and walkthroughs

From Practices of High Maturity Organizations
The 1999 Survey by Paulk, Goldenson, and White,
December 1999.
23
Greater Maturity Can Bear Fruit

• SE division of Hughes aircraft spent _at_500K over
  a three year period for assessment and
  improvement programs. By the end of the three
  year period, assessed at CMM Level 3. Estimated
  savings of _at_2M annually as a result (less
  overtime, less rework, greater productivity,
  etc.)
• Equipment Division of Raytheon rise to CMM Level
  3, at an estimated cost of _at_580K resulted in
  2-fold increase in productivity along with
  savings of _at_15.8M in rework costs.
• Motorola GED (CMM Level 4) documented significant
• reduction in cycle time
• reduction in defect rates
• increase in productivity

24
Process Characterization

• Process Performance
• The actual results achieved by following a
  software process.
• Process Capability
• The range of expected results that can be
  achieved by following
• a software process.
• Process Maturity
• The extent to which a specific process is
  explicitly defined,
• managed,measured, controlled, and effective.

25
Process Characterization
The performance of a process is described as a
probability distribution. Schedule and cost
targets are typically overruns by Level 1
organizations.
26
Process Characterization
Plans based on past performance are more
realistic in Level 2 organizations
27
Process Characterization
With well-defined processes, performance improves
in Level 3 organizations.
28
Process Characterization
Based on quantitative understanding of the
process and product, performance continues to
improve in Level 4 organizations.
29
Process Characterization
Performance continuously improves in Level 5
organizations.
30
Internal CMM Structure
31
Internal CMM Structure

• Maturity Levels
• Maturity levels are evolutionary plateaus.
  Each level characterizes a process capability.
• Key Process Areas
• Maturity levels are described by key process
  areas that indicate areas of potential
  improvement.
• These areas help identify areas that must be
  addressed to achieve a particular maturity level.
  
• Key process areas identify a cluster of related
  activities that, when performed collectively,
  achieve a set of goals considered important for
  enhancing process capability.
• There are both project and organizational
  responsibilities in all key process areas.

32
Internal CMM Structure

• Common Features
• Key process areas have attributes indicating
  whether particular activities are effective as
  well as whether they have become part of the
  infrastructure.
• Common features are
• commitment to perform
• Typical sub features include
• policies
• senior management sponsorship
• responsibility

33
Internal CMM Structure

• ability to perform
• Typical subfeatures include
• resources
• organization structure
• delegation
• training
• orientation

34
Internal CMM Structure

• activities performed
• Typical subfeatures include
• establishing plans and procedures
• performing the work
• tracking it
• taking corrective actions as necessary
  
• measurement and analysis
• Typically includes examples of the measurements
  that could be taken to determine the status and
  effectiveness of the Activities Performed

35
Internal CMM Structure

• verifying implementation
• Typical subfeatures include reviews and audits
  by
• senior management
• project management
• software quality assurance
• Key Practices
• Key practices provide a more detailed view of
  specific activities, policies, procedures for key
  process areas.

36
CMM Maturity Levels and KPAs
Continuously improving process
Optimizing (Level 5)

• Process change management
• Technology change management
• Defect prevention

Predictable process
Managed (Level 4)

• Software quality management
• Quantitative process management

Defined (Level 3)
Standard, consistent process

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

Repeatable (Level 2)
Disciplined process
Initial (Level 1)

• Software configuration management
• Software quality assurance
• Software subcontract management
• Software project tracking and oversight
• Software project planning
• Requirements management

Adapted from Technical Report SEI-93-TR-24
37
How is CMM used in process improvement?

• Software process assessments are used to
  determine the state of an organization's current
  software process, to determine the high-priority
  software process-related issues facing an
  organization, and to obtain the organizational
  support for software process improvement.
• Software capability evaluations are used to
  identify contractors who are qualified to perform
  the software work or to monitor the state of the
  software process used on an existing software
  effort.

38
How is CMM used in process improvement?

• Software process assessments and software
  capability evaluations differ in motivation,
  objective, outcome, and ownership of the results.
  
• These factors lead to substantive differences in
  the dynamics of interviews, the scope of inquiry,
  the information gathered, and the formulation of
  the outcome. The assessment and evaluation
  methods are quite different when the detailed
  procedures employed are examined.
• Assessment training does not prepare a team to
  perform evaluations, or vice versa.

39
How is CMM used in process improvement?

• Software process assessments are performed in an
  open, collaborative environment.
• Their success depends on a commitment from both
  management and the professional staff to improve
  the organization.
• The objective is to surface problems and help
  managers and engineers improve their
  organization. While the questionnaire is valuable
  in focusing the assessment team on maturity level
  issues, the emphasis is on structured and
  unstructured interviews as tools for
  understanding the organization's software process

40
How is CMM used in process improvement?

• Aside from identifying the software process
  issues facing the organization, the buy-in to
  improvement, the organization-wide focus on
  process, and the motivation and enthusiasm in
  executing an action plan are the most valuable
  outcomes of an assessment.
• Software capability evaluations, on the other
  hand, are performed in a more audit-oriented
  environment. The objective is tied to monetary
  considerations, since the team's recommendations
  will help select contractors or set award fees.
• The emphasis is on a documented audit trail that
  reveals the software process actually implemented
  by the organization.

41
Conclusion

• A reasonable software process is
• practiced
• documented
• enforced
• trained
• measured
• able to improve

42
Conclusion

• A well-defined process can be characterized in
  terms of
• readiness criteria
• inputs
• standards and procedures for performing the
  
• work
• verification mechanisms (e.g., peer reviews)
  
• outputs
• completion criteria

43
Conclusion

• The quality of software system is governed by the
  quality of the process used to develop and evolve
  it
• - Watts S.Humphrey

44
References

• Paulk, M. C., B. Curtis, M. B. Chrissis, C. V.
  Weber (1993) The Capability Maturity Model For
  Software, Version 1.1. Software Engineering
  Institute, Carnegie Mellon University,
  CMU/SEI-93-TR-24.
• SEI (1993) The Capability Maturity Model A
  Tutorial.