CMM Overview

1
CMM Overview
Professor Ron Kenett Tel Aviv University School
of Engineering
2
????? ????????

• Faster time to market
• Improve quality
• Increase customer satisfaction
• Enhance productivity
• Develop right products in required time windows

3
????? ?????? ????? ???? ???? ??????? ??? ?????
???????? ?????
?????
????
???????
4
??? ????????
??? ????? ??????
3
SDMD
2
1
???? ??????
1
5
????? ????? ??????

• ???? ?????
• ?????
• ????? ?????
• ??????? ??????
• ????? ????

6
????? ??????? ?????? ??????
7
????? ??????
8
Israeli Process Improvement Experiments
ESPRIT European Systems and Software Initiative

• IAI 23683 TESTART
• Magic 23690 MAGICIAN
• Motorola 23705 PREV-DEV
• Onyx 23750 SPIP
• ECI 27582 ARMT

9
Best Practice Manual
ESPRIT European Systems and Software Initiative

• Israel ESPINODE
• ???? ???? ?????? ?????? ????? ?????
• ????? ?????? ??????? ?????? ?????
• KPA ??"?
• Email espinode_at_kpa.co.il
• http//www.kpa.co.il/espinode

10
The Software Engineering Institute Capability
Maturity Model
The Capability Maturity Model, Version
1.1 CMU/SEI-93-TR-24, Software Engineering
Institute Carnegie Mellon University, Pittsburgh,
1993 Watts S. Humphrey, Managing the Software
Process Addison-Wesley, Reading Mass., 1989
11
SEI Capability Maturity Model
Levels of Process Maturity
12

Level 1Just do it.
to produce
Activity
Results
Level 2Think before you act,and think after
you act, just to make sure you did it right.
Planning
to produce
Activity
Results

input to
Evaluation
to improve
13

Level 3
Planning
input to
to produce
Activity
Standards
Results

input to
input to
Evaluation
to improve
Use your lessons learned.
14

Level 4
Planning
input to
to forecast
to produce
Activity
Standards
Results

input to
input to
Evaluation
to improve
Predict the results you need and expect and then
create opportunities to get those results
15

Level 5
Planning
input to
to forecast
to produce
Activity
Standards
Results

input to
input to
Evaluation
to improve
to improve
Create lessons learned,and use lessons learned
to create more lessons learned, and use more
lessons learned to create even more
lessons learned, and use even
more lessons learned to create...
16
SEI Capability Maturity Model
????? ?? ?????? ?????? ??????? ????? ???????
17
The process is a "black box" at Level 1
IN
OUT
18
Milestones provide visibility at Level 2
IN
OUT
19
Internal processes become visible at Level 3
IN
OUT
20
At Level 4 visibility is quantitative, objective
IN
OUT
21
High degrees of insight at Level 5
IN
OUT
22
SEI Capability Maturity Model
????? ?? ????? ?????? ??????? ?????
23
Targets usually missed at Level 1
Level 1
Target
Time//...
24
Targets more often met at Level 2
Level 2
Target
Time//...

• Plans are more realistic
• Results still vary widely

25
Performance improves at Level 3
Level 3
Target
Time//...

• Variability decreases
• Actual results improve

26
Process under statistical control at Level 4
Level 4
Target
Time//...

• Results highly predictable
• Variability narrows significantly

27
Level 5 a platform for ongoing improvement
Level 5
Target
Time//...

• Defect prevention and continuous improvement
  provide ongoing performance gains

28
CMM structure overview
29
The CMM comprises 18 KPAs
30

5
The CMM Structure
4
3
2
Maturity Levels
RM
PP
PT
SM
CM
QA
KeyProcess Areas

Goals
Common Features
Commitment to Perform
Ability to Perform
Verifying Implementation
Activities Performed
Measurement and Analysis
KeyPractices
31
Quality increases and risk decreases as the
process matures
32
Understanding the Managed and Optimizing Levels
Level 3
Level 4
Level 5
"Stability"
"Control"
"Continuous Improvement"
Upper limit
Zone of Performance
?
Cost of Poor Quality
Lower Limit
Chronic Waste
33
A Software Process Immaturity Model
34
Process appraisal steps
35
CMM-based process profile
36
(No Transcript)
37
????????? ???? ??????? ????????
??? 2 ???? 2000
Source SEI, 1994, number of organizations
261 1997, number of
organizations 606
38
Examples from data reported inhttp//www.sei.cmu.
edu/technology/measurement/profile.html

• ATT Network Systems Advanced Software
  Construction Center
• Maturity Level-2
• Aug-95
• Hewlett Packard
• Maturity Level-2
• May-95
• Lockheed Martin Aircraft Services Division
• Maturity Level-2
• Oct 95

• Motorola Transmission Products Group
• Maturity Level-2
• Sep-93
• Systems and Electronics Group at Texas
  Instruments
• Maturity Level-3
• Jun-94
• CITIL (Citicorp Information Technology Industries
  Limited)
• Maturity Level-4
• Aug-95

39
More examples from data reported
inhttp//www.sei.cmu.edu/technology/measurement/p
rofile.html

• McDonnell Douglas Aerospace (St. Louis)
• Level-3
• Aug Maturity -94
• Raytheon Electronic Systems
• Maturity Level-3
• 1991
• IBM Federal Systems Company
• Maturity Level-5
• 1989

• Tracor, Inc.
• Maturity Level-3
• September 1996
• Boeing Defense Space Group
• Maturity Level-5
• Aug-96
• Motorola Electronic India Ltd. (MEIL)
• Maturity Level-5
• Aug-96

40
CMM structure overview
Process Capability
Maturity Level
Goals
Key Process Areas
Key Practices
41
Establishing a repeatable process

• Requirements Management
• Project Planning
• Project Tracking Oversight
• Subcontract Management
• Quality Assurance
• Configuration Management

REPEATABLE
INITIAL
42
CMM Level 2 Key Process Areas
Software Quality Assurance
Requirements Management
SoftwareProjectPlanning
Software Configuration Management
SoftwareProject Tracking and Oversight
Software Subcontract Management
43
Requirements Management

• Purpose
• To establish a common understanding between the
  customer and the software project of the
  customer's requirements that will be addressed by
  the software project.
• Involves
• Establishing and maintaining an agreement with
  the customer on the requirements for the software
  project
• Forms the basis for estimating, planning,
  performing, and managing the project

44
Requirements Management
Selected key practices

• Commitment to Perform
• An organizational policy specifies that
• Requirements are documented.
• Requirements are reviewed by the software manager
  and other affected groups.
• Plans, products, and activities are changed when
  the requirements change.

45
Goal 1 System requirements allocated to software
are controlled to establish a baseline for
software engineering and management use.
Requirements Management Activities Performed

• The software engineering group reviews the
  allocated requirements before they are
  incorporated into the software project.
• Incomplete and missing allocated requirements are
  identified.
• Commitments resulting from the allocated
  requirements are negotiated with the affected
  groups.
• The allocated requirements are managed and
  controlled.

46
Goal 2 Software plans, products, and activities
are kept consistent with the system requirements
allocated to software.
Requirements Management Activities Performed

• The software engineering group uses the allocated
  requirements as the basis for plans, work
  products, and activities.
• Changes to the allocated requirements are
  reviewed and incorporated into the project.
• The impact to existing commitments is assessed,
  and changes are negotiated as appropriate.
• Changes to plans, products, and activities are
  identified, documented, managed, and tracked.

47
Software Project Planning

• Purpose
• To establish reasonable plans for performing the
  software engineering and for managing the
  software project.
• Involves
• Developing estimates
• Negotiating commitments
• Establishing the plan

48
Software Project Planning
Selected key practices

• Commitment to Perform
• A software project manager is designated to
  negotiate commitments and develop a plan.
• An organizational policy specifies that
• requirements are used as a basis for planning
• commitments are negotiated.
• other groups involvement is negotiated and
  documented.
• affected groups review estimates and commitments.
  
• senior management reviews external commitments.
• development plan is managed and controlled.
• Ability to Perform
• Documented and approved statement of work exists.

49
Goal 1 Software estimates are documented for use
in planning and tracking the software project.
Software Project Planning Activities Performed

• Documented procedures are used to derive
  estimates for product size (and size changes),
  effort and costs, critical computer resources,
  and schedule.
• Estimated capacity requirements for the software
  facilities, environments, and tools are based on
  size estimates and other characteristics.
• Planning data are recorded

50
Goal 2 Software project activities and
commitments are planned and documented.
Software Project Planning Activities Performed

• Software project planning is initiated in the
  early stages of, and in parallel with, the
  overall project planning.
• A software life cycle with stages of manageable
  size is defined.
• A software development plan is developed
  according to a documented procedure.
• The SDP is documented, reviewed, managed, and
  controlled.)
• Software work products that help maintain control
  of the software project are identified.

51
Goal 2 Software project activities and
commitments are planned and documented.
Software Project Planning Activities Performed
Contd

• Software technical, cost, resource, and schedule
  risks are identified, assessed, and documented.
• Plans for software engineering facilities and
  support tools are prepared.

52
Goal 3 Affected groups and individuals agree to
their commitments related to the software project
Software Project Planning Activities Performed

• The software group participates on the project
  proposal team.
• The software group participates with other
  affected groups in overall project planning.
• External software commitments are reviewed with
  senior management according to a documented
  procedure.
• Plans for the involvement of the software group
  with related groups, and vice versa, are
  negotiated, the support efforts are budgeted, and
  agreements documented.

53
Project Tracking Oversight

• Purpose
• To provide adequate visibility into actual
  progress so that management can take effective
  actions when the software project's performance
  deviates significantly from the software plans.
• Involves
• Monitoring project results
• Comparing results to estimates and plans
• Taking corrective actions

54
Project Tracking Oversight
Selected key practices

• Commitment to Perform
• A software project manager designated to be
  responsible for projects activities and results.
• An organizational policy specifies that
• a documented SDP is used and maintained as the
  basis for tracking the project
• the project manager is kept informed of the
  software projects status and issues
• corrective actions are taken when the plan is not
  being achieved
• changes to the commitments are made with the
  agreement of the affected groups
• senior management reviews all new external
  commitments and changes

55
Goal 1 Actual results and performances are
tracked against the software plans.
Software Project Tracking Oversight Activities
Performed

• A software development plan is used for tracking
  activities and communicating status.
• Results are tracked
• size of software products
• software effort and costs
• critical computer resources
• software schedule
• software engineering technical activities
• software risks

more...
56
Goal 1 Actual results and performances are
tracked against the software plans.
Software Project Tracking Oversight Activities
Performed

• Actual measurement data are recorded.
• SW group conducts regular internal reviews to
  track performance against the SDP.
• Formal reviews of software results are conducted
  at milestones according to documented procedure.

Contd
57
Goal 2 Corrective actions are taken and managed
to closure when actual results and performance
deviate significantly from the software plans.
Software Project Tracking Oversight Activities
Performed

• The SDP is revised according to documented
  procedure.
• Corrective actions, determined through tracking
  software items, are taken as necessary.
• Replanning data are recorded.

58
Goal 3 Changes to software commitments are
agreed to by the affected groups and individuals.
Software Project Tracking Oversight Activities
Performed

• External software commitments and changes to them
  are reviewed with senior management according to
  a documents procedure.
• Approved changes to software commitments are
  communicated to the software group and other
  related groups.

59
Software Quality Assurance

• Purpose
• To provide management with appropriate visibility
  into the process being used by the software
  project and of the products being built.
• Involves
• Reviewing and auditing products and activities to
  determine whether the project is adhering to
  established plans, standards, and procedures
• Providing the results to the project manager and
  other managers, as appropriate

60
Software Quality Assurance
Selected key practices

• Commitment to Perform
• An organizational policy specifies that
• the SQA function is in place for all projects
• the SQA group has an independent reporting
  channel to senior management
• senior management periodically reviews SQA
  activities and results

61
Goal 1 Software quality assurance activities are
planned.
Software Quality Assurance Activities Performed

• An SQA plan is prepared for the software project
  according to a documented procedure.
• The SQA plan is reviewed by the affected groups
  and individuals.
• The SQA plan covers
• responsibilities and authority of the SQA group
• evaluations, reviews, and audits to be conducted

62
Goal 2 Adherence of software products and
activities to the applicable standards,
procedures, and requirements is verified
objectively.
Software Quality Assurance Activities Performed

• The SQA groups activities are performed in
  accordance with the SQA plan.
• The SQA group participates in the preparation and
  review of the projects SDP, standards, and
  procedures.
• The SQA group reviews the software engineering
  activities to verify compliance.
• The SQA group audits the designated software work
  products.

63
Goal 3 Affected groups and individuals are
informed of software quality assurance activities
and results.
Software Quality Assurance Activities Performed

• The SQA group periodically reports the results of
  its activities to the software engineering group.
  
• Deviations identified in the software activities
  and software work products are documented and
  handled according to a documented procedure.
• The SQA group conducts periodic reviews of its
  activities and findings with the customers SQA
  personnel, as appropriate.

64
Goal 4 Noncompliance issues that cannot be
resolved within the software project are
addressed by senior management.
Software Quality Assurance Activities Performed

• Deviations not resolvable with the software task
  leaders, software managers, or project manager
  are documented and presented to the senior
  manager designated to receive non-compliance
  items.
• Non-compliance items presented to the senior
  manager are periodically reviewed until resolved.

65
Software Configuration Management

• Purpose
• To establish and maintain the integrity of the
  products of the software project throughout the
  project's software life cycle.
• Involves
• Identifying the configuration of the software at
  given points of time
• Controlling changes to the configuration
• Maintaining the integrity and traceability of the
  configuration

66
Software Configuration Management
Selected key practices

• Commitment to Perform
• An organizational policy specifies that
• SCM responsibility for each project is explicitly
  assigned
• SCM is implemented throughout the projects life
  cycle
• SCM is implemented for externally deliverable
  products, designated internal work products and
  support tools
• projects have a repository for storing
  configuration items and associated SCM records
• baselines and SCM activities are audited on a
  periodic basis

67
Goal 1 Software configuration management
activities are planned.
Software ConfigurationManagement Activities Per
formed

• An SCM plan is prepared for each software project
  according to a documented procedure.
• The SCM plan covers the SCM activities to be
  performed, including those performed by the
  software engineering group and other
  software-related groups.)

68
Goal 2 Selected software work products are
identified, controlled, and available.
Software ConfigurationManagement Activities Per
formed

• The SCM plan is the basis for performing SCM
  activities.
• A configuration management library system is
  established as a repository for the software
  baselines.
• Work products to be placed under SCM are
  identified.
• Products from the software baseline library are
  created, and their release is controlled,
  according to a documented procedure.

69
Goal 3 Changes to identified software work
products are controlled.
Software ConfigurationManagement Activities Per
formed

• Change requests and problem reports for all
  configuration items/units are initiated,
  recorded, reviewed, approved, and tracked
  according to documented procedure.
• Changes to baselines are controlled according to
  a documented procedure.

70
Goal 4 Affected groups and individuals are
informed of the status and content of software
baselines.
Software ConfigurationManagement Activities Per
formed

• The status of the configuration items is recorded
  according to a documented procedure.
• Standard reports documenting the SCM activities
  and the contents of the software baseline are
  developed and made available to affected groups
  and individuals.
• Software baseline audits are conducted according
  to a documented procedure.
• Results of the software baseline audits are
  reported to the project software manager.

71
Establishing a defined process

• Organization Process Focus
• Organization Process Definition
• Training Program
• Integrated Software Management
• Software Product Engineering
• Intergroup Coordination
• Peer Reviews

DEFINED
REPEATABLE
72
Organization Process Focus

• Purpose
• To establish the organizational responsibility
  for software process activities that improve the
  organization's overall software process
  capability.
• Involves
• Developing and maintaining an understanding of
  processes used
• Coordinating process improvement activities

73
Organization Process Definition

• Purpose
• To develop and maintain a usable set of software
  process assets that improve process performance
  across the projects and provide a basis for
  cumulative, long-term benefits to the
  organization.
• Involves
• Developing and maintaining the organizations
  standard software process and related process
  assets

74
Training Program

• Purpose
• To develop the skills and knowledge of
  individuals so they can perform their roles
  effectively and efficiently.
• Involves
• Identifying training needs
• Developing or procuring training to meet the needs

75
Integrated Software Management

• Purpose
• To integrate the software engineering and
  management activities into a coherent, defined
  software process that is tailored from the
  organization's standard software process and
  related process assets
• Involves
• Developing a projects defined process
• Managing the project using this defined process

76
Software Product Engineering

• Purpose
• To consistently perform a well-defined
  engineering process that integrates all the
  software engineering activities to produce
  correct, consistent software products effectively
  and efficiently.
• Involves
• Performing the engineering tasks using the
  defined process and appropriate tools and methods

77
Intergroup Coordination

• Purpose
• To establish a means for the software engineering
  group to participate actively with the other
  engineering groups so the project is better able
  to satisfy the customer's needs effectively and
  efficiently.
• Involves
• Participating with other project engineering
  groups to address system-level requirements,
  objectives, and issues

78
Peer Reviews

• Purpose
• To remove defects from the software work products
  early and efficiently.
• Involves
• Methodical examination of software work products
  by the producers peers to identify defects and
  areas where changes are needed

79
Establishing a managed process
MANAGED

• Quantitative Process Management
• Software Quality Management

DEFINED
80
Quantitative Process Management

• Purpose
• To control the process performance of the
  software project quantitatively. Software
  process performance represents the actual results
  achieved from following a software process.
• Involves
• Establishing goals for the performance of a
  projects defined process
• Taking measurements of process performance
• Analyzing the measurements
• Making adjustments to maintain process
  performance within acceptable limits

81
Software Quality Management

• Purpose
• To develop a quantitative understanding of the
  quality of the project's software products and
  achieve specific quality goals.
• Involves
• Defining quality goals for software products
• Establishing plans to achieve these goals
• Monitoring and adjusting plans, work products,
  activities, and quality goals to satisfy customer
  needs

82
Establishing an optimizing process
OPTIMIZING

• Defect Prevention
• Technology Change Management
• Process Change Management

MANAGED
83
Defect Prevention

• Purpose
• To identify the cause of defects and prevent them
  from recurring.
• Involves
• Analyzing defects that were encountered in the
  past
• Taking specific actions to prevent the occurrence
  of those types of defects in the future

84
Technology Change Management

• Purpose
• To identify new technologies (i.e., tools,
  methods, and processes) and track them into the
  organization in an orderly manner.
• Involves
• Identifying, selecting, and evaluating new
  technologies
• Incorporating effective technologies into the
  organization

85
Process Change Management

• Purpose
• To continually improve the software processes
  used in the organization with the intent of
  improving software quality, increasing
  productivity, and decreasing the cycle time for
  product development.
• Involves
• Defining process improvement goals
• Identifying, evaluating, and implementing
  improvements to the organizations standard
  process and the projects defined processes on a
  continuous basis