Transcript No Slide Title

7/16/2015
CMM Overview
Professor Ron Kenett
Tel Aviv University
School of Engineering
1
7/16/2015
:‫יעדים טיפוסיים‬
 Faster
time to market
 Improve quality
 Increase customer satisfaction
 Enhance productivity
 Develop right products in
required time windows
2
‫הצלחת הארגון דורשת הבנת יחסי‬
‫הגומלין בין שלושת המרכיבים‬
‫הבאים‪:‬‬
‫אנשים‬
‫כלים‬
‫תהליכים‬
‫‪3‬‬
‫‪7/16/2015‬‬
‫‪7/16/2015‬‬
‫האם מתקדמים?‬
‫‪3‬‬
‫לאן רוצים להגיע?‬
‫‪SDMD‬‬
‫‪2‬‬
‫איפה אנחנו?‬
‫‪4‬‬
‫‪1‬‬
‫‪1‬‬
‫‪7/16/2015‬‬
‫ארגון תהליך השיפור‪:‬‬
‫‪‬צוות היגוי‬
‫‪‬אבחון‬
‫‪‬צוותי שיפור‬
‫‪‬פרויקטי פיילוט‬
‫‪‬יישום כולל‬
‫‪5‬‬
‫‪7/16/2015‬‬
‫מסגרת ארגונית לתהליך השיפור‪:‬‬
‫צוות היגוי‬
‫‪Team 3‬‬
‫‪Team 2‬‬
‫‪Team 1‬‬
‫לקוחות פנימיים וחיצוניים‬
‫‪6‬‬
7/16/2015
‫תהליך השיפור‬
P1: Assessment
P2: Projects Launch
P3: Process analysis
P5: Implementation
and on going
control
P4: Management Dashboards
7
7/16/2015
ESPRIT
European Systems
and Software Initiative
Israeli Process Improvement Experiments
 IAI
 Magic
 Motorola
 Onyx
 ECI
23683 TESTART
23690 MAGICIAN
23705 PREV-DEV
23750 SPIP
27582 ARMT
8
7/16/2015
ESPRIT
European Systems
and Software Initiative
Best Practice Manual
Israel ESPINODE
‫מרכז הידע לשיפור תהליכי פיתוח תוכנה‬
‫מדריך לשיטות מתקדמות בפיתוח תוכנה‬
KPA ‫בע"מ‬
Email: [email protected]
http://www.kpa.co.il/espinode
9
7/16/2015
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
10
7/16/2015
SEI Capability Maturity Model
5. OPTIMIZING
Continuous Improvement
4. MANAGED
Process Control
3. DEFINED
Process Definition
2. REPEATABLE
Process Discipline
1. INITIAL
Ad Hoc
Levels of
Process Maturity
11
7/16/2015
Level 1:
Just do it.
Level 2:
Think before
you act,
and think after
you act, just to
make sure you
did it right.
Activity
to produce
Results
Planning
Activity
to produce
Results
input to
Evaluation
to improve
12
7/16/2015
Level 3
input to
Standards
Planning
Activity
input to
to produce
Results
input to
Evaluation
to improve
Use your lessons learned.
13
7/16/2015
Level 4
input to
Standards
Planning
Activity
input to
to forecast
to produce
Results
input to
Evaluation
to improve
Predict the results you need and expect and then
create opportunities to get those results
14
7/16/2015
Level 5
input to
Standards
Planning
Activity
input to
to forecast
to produce
Results
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...
15
7/16/2015
SEI Capability Maturity Model
‫השפעה על שקיפות הפיתוח‬
‫והיכלות לתכנן ולהתריע‬
5. OPTIMIZING
Continuous Improvement
4. MANAGED
Process Control
3. DEFINED
Process Definition
2. REPEATABLE
Process Discipline
1. INITIAL
Ad Hoc
16
7/16/2015
The process is a "black box" at Level 1
IN
OUT
17
7/16/2015
Milestones provide visibility at Level 2
IN
OUT
18
7/16/2015
Internal processes become visible at Level 3
IN
OUT
19
7/16/2015
At Level 4 visibility is quantitative, objective
IN
OUT
20
7/16/2015
High degrees of insight at Level 5
IN
OUT
21
7/16/2015
SEI Capability Maturity Model
‫השפעה על עמידה ויעדים‬
‫ועלויות פיתוח‬
5. OPTIMIZING
Continuous Improvement
4. MANAGED
Process Control
3. DEFINED
Process Definition
2. REPEATABLE
Process Discipline
1. INITIAL
Ad Hoc
22
7/16/2015
Targets usually missed at Level 1
Level 1
Target
Time/$/...
23
7/16/2015
Targets more often met at Level 2
Level 2
Target
Time/$/...
• Plans are more realistic
• Results still vary widely
24
7/16/2015
Performance improves at Level 3
Level 3
Target
Time/$/...
• Variability decreases
• Actual results improve
25
7/16/2015
Process under statistical control at Level 4
Level 4
Target
Time/$/...
• Results highly predictable
• Variability narrows significantly
26
7/16/2015
Level 5: a platform for ongoing improvement
Target
Level 5
Time/$/...
• Defect prevention and continuous
improvement provide ongoing
performance gains
27
7/16/2015
CMM structure overview
Maturity Level
Process
Capability
Key Process Areas
Goals
Key Practices
28
7/16/2015
The CMM comprises 18 KPAs
Level
Key Process Areas
Optimizing
Process Change Management
Defect Prevention
Technology Change Management
Managed
Software Quality Management
Quantitative Process Management
Defined
Organization Process Focus
Organization Process Definition
Training Program
Integrated Software Management
Software Product Engineering
Intergroup Coordination
Peer Reviews
Repeatable
Requirements Management
Project Planning
Project Tracking & Oversight
Subcontract Management
Quality Assurance
Configuration Management
Initial
29
7/16/2015
The CMM Structure
2
Maturity Levels
Key
Process
Areas
RM
3
PP
PT
SM
QA
4
5
CM
Goals
Common
Features
Activities
Performed
Commitment
to Perform
Ability to
Perform
Measurement and
Analysis
Verifying
Implementation
Key
Practices
30
7/16/2015
Quality increases and risk decreases as the process matures
Level
Characteristic
Optimizing
Continuous process capability
improvement
Managed
Product quality planning;
tracking of measured software
processes
Defined
Software process defined and
institutionalized to provide
product quality control
Repeatable
Management oversight and
tracking of projects; stable
planning and product baselines
Initial
Impact
QUALITY
RISK
Ad hoc
(unpredictable, chaotic)
31
7/16/2015
Understanding the Managed and Optimizing Levels
Level 3
"Stability"
Level 4
"Control"
Level 5
"Continuous Improvement"
Upper limit
Cost
of
Poor
Quality
Zone of
Performance
?
Lower Limit
Chronic Waste
32
7/16/2015
A Software Process Immaturity Model
Level
Characteristic
Key Process Area
0
Foolish
Negligent:
Failure to allow
successful development
process
• Software reuse
-1
Stupid
Obstructive:
counter-productive
process imposed
• Development
environments
• Repositories
-2
Lunatic
Contemptuous:
disregard for good
software engineering
institutionalized
• Automatic
programming
Result
Sense
Idiocy
Source: A. Finkelstein, ACM SIGSOFT Software Engineering Notes, Oct 1992
33
7/16/2015
Process appraisal steps
Form & Train
Team
Findings
Software Quality Assurance
Maturity
Questionnaire
Finding
Few standards and procedures for process and products have been formally adopted 
There are no independent means to assure that defined standards and procedures are followed 
Consequences
Quality gains are not sustainable 
SDM is inconsistently applied 
Potential for conflict between groups 
Quality is at risk 
Defined processes may be abandoned 
Frequent emergency releases 
Collect Data
Interviews •
Discussions •
Document •
Reviews
KPA Profile
Process Change Management
Technology Change Management
Defect Prevention
Software Quality Management
Quantitative Process Management
Peer Reviews
Intergroup Coordination
Software Product Engineering
Integrated Software Management
Training Program
Organization Process Definition
Organization Process Focus
Subcontract Management
Requirements Management
Quality Assurance
Analyze Data &
Formulate
Findings
Configuration Management
Project Tracking & Monitoring
Project Planning
34
7/16/2015
CMM-based process profile
Process Change Management
Technology Change Management
Defect Prevention
Software Quality Management
Quantitative Process Management
Peer Reviews
Intergroup Coordination
Software Product Engineering
Integrated Software Management
Training Program
Organization Process Definition
Organization Process Focus
Subcontract Management
Requirements Management
Quality Assurance
Configuration Management
Project Tracking & Monitoring
Project Planning
Legend
Not satisfied
Partially satisfied
Fully satisfied
Not applicable
35
7/16/2015
KPA Implementation Status
Quality Assurance (QA)
Configuration Management (CM)
Project Tracking and Oversight (PTO)
Project Planning (PP)
Requirements Management (RM)
0
10
20
30
40
50
60
70
80
90
100
36
7/16/2015
‫סטטיסטיקה מתוך אבחונים פורמליים‬
Source: SEI, 1994, number of organizations: 261
1997, number of organizations 606
37
7/16/2015
Examples from data reported in
http://www.sei.cmu.edu/technology/measurement/profile.html

AT&T Network Systems
Advanced Software
Construction Center








Maturity Level-2
Oct 95


Maturity Level-2
Sep-93
Systems and Electronics
Group at Texas Instruments

Maturity Level-2
May-95
Lockheed Martin Aircraft
Services Division
Motorola Transmission
Products Group

Hewlett Packard


Maturity Level-2
Aug-95

Maturity Level-3
Jun-94
CITIL (Citicorp Information
Technology Industries
Limited)


Maturity Level-4
Aug-95
38
7/16/2015
More examples from data reported in
http://www.sei.cmu.edu/technology/measurement/profile.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
39
7/16/2015
CMM structure overview
Maturity Level
Process
Capability
Key Process Areas
Goals
Key Practices
40
7/16/2015
Establishing a repeatable process
• Requirements Management
REPEATABLE
• Project Planning
• Project Tracking & Oversight
• Subcontract Management
• Quality Assurance
INITIAL
• Configuration Management
41
7/16/2015
CMM Level 2 Key Process Areas
Requirements
Management
Software Quality
Assurance
Software
Project
Planning
Software
Configuration
Management
Software
Project Tracking
and Oversight
Software
Subcontract
Management
42
7/16/2015
Requirements Management

Purpose:


Involves:


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.
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
43
7/16/2015
Selected
key practices
Requirements Management
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.
44
7/16/2015
Requirements
Management
Activities
Performed
Goal 1: System requirements allocated to software are
controlled to establish a baseline for software
engineering and management use.

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.
45
7/16/2015
Requirements
Management
Activities
Performed
Goal 2: Software plans, products, and activities are kept
consistent with the system requirements allocated
to software.


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.
46
7/16/2015
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
47
7/16/2015
Selected
key practices
Software Project Planning
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.
48
7/16/2015
Software
Project
Planning
Goal 1: Software estimates are documented for use in
planning and tracking the software project.
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
49
7/16/2015
Software
Project
Planning
Goal 2: Software project activities and commitments are
planned and documented.
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.
50
7/16/2015
Software
Project
Planning
Goal 2: Software project activities and commitments are
planned and documented.
Activities
Performed
Cont’d


Software technical, cost, resource, and
schedule risks are identified, assessed,
and documented.
Plans for software engineering facilities
and support tools are prepared.
51
7/16/2015
Software
Project
Planning
Goal 3: Affected groups and individuals agree to their
commitments related to the software project
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.
52
7/16/2015
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
53
7/16/2015
Selected
key practices
Project Tracking & Oversight
Commitment to Perform:
 A software project manager designated to be
responsible for project’s 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 project’s
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
54
7/16/2015
Software Project
Tracking &
Oversight
Goal 1: Actual results and performances are tracked
against the software plans.
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...
55
7/16/2015
Software Project
Tracking &
Oversight
Goal 1: Actual results and performances are tracked
against the software plans.
Activities
Performed
Cont’d



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.
56
7/16/2015
Software Project
Tracking &
Oversight
Activities
Performed
Goal 2: Corrective actions are taken and managed to
closure when actual results and performance
deviate significantly from the software plans.



The SDP is revised according to
documented procedure.
Corrective actions, determined through
tracking software items, are taken as
necessary.
Replanning data are recorded.
57
7/16/2015
Software Project
Tracking &
Oversight
Goal 3: Changes to software commitments are agreed to
by the affected groups and individuals.
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.
58
7/16/2015
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
59
7/16/2015
Selected
key practices
Software Quality Assurance
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
60
7/16/2015
Software
Quality
Assurance
Goal 1: Software quality assurance activities are planned.
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
61
7/16/2015
Software
Quality
Assurance
Activities
Performed
Goal 2: Adherence of software products and activities to
the applicable standards, procedures, and
requirements is verified objectively.




The SQA group’s activities are performed
in accordance with the SQA plan.
The SQA group participates in the
preparation and review of the project’s
SDP, standards, and procedures.
The SQA group reviews the software
engineering activities to verify
compliance.
The SQA group audits the designated
software work products.
62
7/16/2015
Software
Quality
Assurance
Goal 3: Affected groups and individuals are informed of
software quality assurance activities and results.
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
customer’s SQA personnel, as
appropriate.
63
7/16/2015
Software
Quality
Assurance
Activities
Performed
Goal 4: Noncompliance issues that cannot be resolved
within the software project are addressed by
senior management.


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.
64
7/16/2015
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
65
7/16/2015
Selected
key practices
Software Configuration Management
Commitment to Perform:
 An organizational policy specifies that:





SCM responsibility for each project is explicitly assigned
SCM is implemented throughout the project’s 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
66
7/16/2015
Software
Configuration
Management
Goal 1: Software configuration management activities are
planned.
Activities
Performed


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.)
67
7/16/2015
Software
Configuration
Management
Goal 2: Selected software work products are identified,
controlled, and available.
Activities
Performed




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.
68
7/16/2015
Software
Configuration
Management
Goal 3: Changes to identified software work products are
controlled.
Activities
Performed


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.
69
7/16/2015
Software
Configuration
Management
Goal 4: Affected groups and individuals are informed of
the status and content of software baselines.
Activities
Performed




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.
70
7/16/2015
Establishing a defined process
• Organization Process Focus
• Organization Process
Definition
DEFINED
• Training Program
• Integrated Software
Management
REPEATABLE
• Software Product
Engineering
• Intergroup Coordination
• Peer Reviews
71
7/16/2015
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
72
7/16/2015
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 organization’s
standard software process and related process
assets
73
7/16/2015
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
74
7/16/2015
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 project’s defined process
 Managing the project using this defined process
75
7/16/2015
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
76
7/16/2015
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
77
7/16/2015
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
78
7/16/2015
Establishing a managed process
• Quantitative
Process
Management
DEFINED
MANAGED
• Software Quality
Management
79
7/16/2015
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
project’s defined process
 Taking measurements of process performance
 Analyzing the measurements
 Making adjustments to maintain process
performance within acceptable limits
80
7/16/2015
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
81
7/16/2015
Establishing an optimizing process
• Defect Prevention
OPTIMIZING
• Technology Change
Management
MANAGED
• Process Change
Management
82
7/16/2015
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
83
7/16/2015
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
84
7/16/2015
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 organization’s standard
process and the projects’ defined processes on a
continuous basis
85