Assess-IT
Working to Improve Software Development Processes
Introduction to Process Improvement
and the
SM
Capability Maturity Model (CMM)
Assess-IT, Inc.
404-863-8790
http://www.assess-it.com
(C) 2000 Assess-IT, Inc. All Rights Reserved. This material adapted from SEI proprietary material.
Assess-IT
Working to Improve Software Development Processes
Proprietary Rights
• CMM, Capability Maturity Model, and IDEAL
are service marks of Carnegie Mellon University
(CMU).
• The material in this course is adapted from material
that is proprietary information of the Software
Engineering Institute (SEI) at CMU.
• All material not expressly owned by another
organization is the proprietary property of Assess-IT,
Inc. with all rights reserved.
2
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 1
Introduction
3
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Getting Acquainted
• Introductions
• Name
• Project
• Role
• Hobby
• Expectations from this course
4
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Logistics
• Class times
• Breaks
• Lunch
• Smoking
• Rest rooms
• Phone messages
• Email messages
• Attendance
5
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
More Logistics
• Homework
• There isn’t any
• In-class exercises
• There will be several
• Your thoughts and comments
• This class is for you. Your thoughts and comments are crucial
for me to help you get the most benefit out of this class.
6
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Who Should Take This Course
• Anyone interested in learning about CMM based
process improvement and the underlying concepts of
the CMM itself
• Assessment team members
• Assessment participants
• Project managers
• Software engineers
• Personnel from supporting disciplines
7
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Course Agenda
DAY 1
• Introduction
DAY 2
3
• Repeatable Level
97
• The SEI
11
• Defined Level
142
• Software Process
Maturity
18
• Managed Level
186
• Optimizing Level
197
• CMM Overview
53
• Interpreting the CMM
207
• Structure of the CMM
66
• Conclusion
212
8
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
What You Should Already Know
• Basic software development and project
management principles and concepts
• Gantt, SOW, Schedule, Estimate
• Conversational familiarity with software process
concepts
• Process vs Procedure
• Continuous Improvement
• Roles and Responsibilities
• Measurement Based Improvement
9
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Course Objectives
• By the end of this course you should be able to:
• Understand basic process improvement and CMM
terminology and principles
• Discuss the structure and content of the CMM
• Use the CMM in process improvement efforts within your
organizations
• Interpret the CMM within the context of your organization’s
business needs
• Identify recurrent themes within the CMM
10
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 2
The SEI
11
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
The Software Engineering Institute (SEI)
• Established in 1984
• Federally Funded Research and Development Center
(FFRDC)
• Awarded to and located at Carnegie Mellon
University (CMU) in Pittsburgh, PA
• Sponsored by the Department of Defense (DoD)
12
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
SEI’s Mission
To provide leadership in advancing the state of the
practice of software engineering to improve the
quality of systems that depend on software
13
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
SEI’s Process Focus
• Capability Maturity Models
• CMM based appraisals
• Process definition
• Measurement and analysis
14
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
SEI and Vendor Provided Training
• Process Improvement
• Managing
• Consulting
• Measuring
• Defining
• Appraising
• CMM Based Appraisal for Internal Process Improvement
(CBA IPI)
• Software Capability Evaluation (SCE)
• Interim Profile (IP)
15
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Getting Started
Before you follow the yellow brick road to process
improvement, it is important to know several things:
•
•
•
•
Origin
Destination
Route
Where to
get Help
Where you are now
Where are you heading (reference model)
A plan for getting there
Scarecrow, Tin Man, Cowardly Lion
aka - Consultants
16
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Knowledge of the Current Process
To effectively change the way you do business,
you must first understand how it is currently done.
Chinese? Proverb
If you don’t know where you’re going, any road will do.
Humphrey Proverb
If you don’t know where you are, a map won’t help you.
17
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 3
Software Process Maturity
18
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 3 Objectives
• Understand the principles of process improvement
• Identify the characteristics of immature and mature
processes
• Describe process relative to the CMM
19
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Question
What Is Process?
20
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Process
Process is the ordered steps
followed by people, using methods
and tools, to convert inputs into
outputs.
21
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Putting Process In Perspective
B
A
D
C
People
with skills,
training, and
motivation
Procedures and methods
defining the relationship
of tasks
Technology
(tools and
equipment)
22
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Software Process Management Premise
The quality of a software product is largely determined
by the quality of the process used to develop and
maintain it.
The implication is that the focus needs to be on both the
process and products.
23
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Why Focus on the Process?
Focusing on product alone misses:
• Scalability issues
• Knowledge of how to do it better
Focusing on process predicts:
• Produces repeatable outcomes
• Allows you to develop project trends
• Provides consistent product characteristics
24
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Process Capability vs Performance
• Capability
• Describes the range of expected/probable/possible results
• Predicts how well you might perform
• Performance
• Demonstrates the actual results achieved
• Shows how well you did perform
25
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Software Process Maturity
• Extent to which a process is:
• Repeatable / Repeated
• Defined / Documented
• Managed and Controlled
• Continuously Improved
• Measured
• Effective
Maturity implies a potential for growth/improvement
26
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Question
Is go ask Bob a process?
Is brushing your teeth a process?
Is baking a cake a process?
27
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Characteristics of an Immature Process
• Processes are ad hoc / improvised on the fly
• Difficult to estimate time, schedule, functionality
• Dependent on the heroic efforts of specific individuals
• Not rigorously followed
• No objective basis for judging quality
• Reactionary
• Addition of new technology can be risky
Most organizations are in this state
28
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Characteristics of a Mature Process
• Processes are defined, documented, and used
• Deliverables are identified and produced
• Management - plans, monitors, and communicates
• Roles and responsibilities are clear
• Product and process are measured
• Quality, cost, and schedule are predictable
• Technology is planned and used effectively
• Continuous improvement is a way of life
29
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Institutionalization of Processes
• “That’s the way we do it here!”
• There is an organizational infrastructure that supports
process
• The organizational culture supports process
• Institutionalized processes endure after their creators
move on
The Focus Is on Building an Organizational Culture of
Process Reliance, Not a Culture of Hero Dependence
30
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Process: A Way to Get Things Done
Do
A
Act
ct
P lan
C heck
Adapted from Shewart
(see page 82 in the CMM)
31
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
What are the Benefits of a Mature Process?
• About 85% - 90% of problems are caused by the
system, not the people
• People more fully develop their potential
• Following and measuring a defined process allows
for improvement to be implemented and sustained
• Integration of new tools and technologies is less risky
32
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Another Question
What Is An Organization?
33
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Organizations
A unit within a larger group, within
which many projects are managed
as a whole
34
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Organization
• Some examples of different organizations
• Government agency
• Military branch
• Corporate division
All projects within an organization share a common toplevel manager and common policies.
Assessments are performed at the organization level.
35
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Organizations are Complex Entities
• Different types
• Many different parts
• Different needs
• Different perspectives
• Hopefully same goals
36
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Different Types of Organizations
• Closed
• Random
• Synchronous
• Open
Adapted from Constantine
37
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Closed Organization
• Strengths
• Traditional hierarchy
• Stable
• Clear lines of authority
• Responds to incremental change
• Weaknesses
• Change and innovation not valued
• Requires strong leadership to change
• Diversity not valued
• Individuality often thought of as disloyal
38
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Random Organization
• Strengths
• Creativity
• Independence
• Free expression and individual freedom
• Thrives on change
• Weaknesses
• Requires strong leader (cult of personality)
• Doesn’t value tradition and unity
• Weak follow-through
• Less able to sustain change
• Difficulty in meeting deadlines
39
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Synchronous Organization
• Strengths
• Harmony
• Common goals
• Unified vision
• Weaknesses
• Little authentic negotiation or discussion
• Doesn’t respond well to change
40
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Open Organization
• Strengths
• Adaptable
• Flexible
• Changes open to negotiation
• Weaknesses
• No hierarchy
• No leadership
• Personnel need to be involved in planning changes and
frequently undermine directives from above
41
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Yet Another Question
What Is Quality?
42
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Quality
Fitness for use
It makes the customer happy
Meets requirements
43
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Quality Concepts
• Focus on fixing the process not the people
• Improvement is continuous
• Improvement requires investment and nurturing
• Unless the level of discomfort is high enough, things
will not change
• Incentive and rewards enable and sustain
improvement
44
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Total Quality Management (TQM)
• TQM is the application of the concepts statistical process
control and statistical quality control to systems that involve
software and the people who develop it.
• TQM is a synthesis of the concepts of Deming, Juran,
Crosby, Shewart and others.
The CMM Strives to apply TQM to software intensive systems
TQM is focused on customer satisfaction
45
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Quality is not Free
It’s Just
Cheaper
Than All of the
Alternatives
46
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
You Guessed It, More Questions
What is a Model?
47
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Model
An abstract view of how the real
world behaves
48
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
The Benefits of Model Based Improvement
• Shared vision
• Common language
• Supports prioritization of challenges
• Supports comparisons among similar organizations
• Developed and supported by the software
development community
• CMM is an attempt to codify common sense
49
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
The Risks of Model Based Improvement
• Models are abstract simplifications, not reality
• Models must be interpreted and tailored to make
sense in the business context you exist in
• Experience and judgment are necessary
George Box “All models are wrong,
some models are useful”
50
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Summary of Module 3
• The CMM applies the techniques and concepts of
TQM to software systems
• TQM focuses on satisfying the customer
• The CMM is a model and therefore a simplification
51
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 3 Exercise
Task: Produce the product the customer requires
Outcome: Meet your production quota while meeting the
customer’s cost, schedule and quality expectations
Duration: 1 Hour
• Receive customer requirements (5 minutes)
• Plan, organize, purchase supplies and submit bids (30 minutes)
• Produce the product (20 minutes)
• Wrap-up (5 minutes)
52
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 4
CMM Overview
53
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 4 objectives
• Recognize the 5 maturity levels in the CMM
• Recognize the KPAs associated with each level
• Understand how capability predicts organizational
behavior
• Explain why you can not skip maturity levels
54
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
What the CMM Is
• The CMM is a staged model
• Codification of common sense
• Method for applying process management and
software process improvement concepts to software
development and maintenance
• A community developed guide
• A model for improvement
• Provides a mechanism for repeatable and consistent
processes
55
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
What the CMM Is Not
• Does not address EVERYTHING !!!
• Addresses Key Process Areas and Practices
• Does not address tools, methods, technologies
• Does not address concurrent engineering
• Does not address marketing
• Does not address human resources
• Does not address organizational behavior
56
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
A Closer Look at the Name (CMM)
• Capability – The potential for performance
• Maturity – The level at which one might perform
• Model – A representation of reality
57
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Level Predicts Organizational Behavior
Level
Initial
Repeatable
Defined
Managed
Optimizing
%
Characteristics
Key Challenges
43
Ad Hoc processes
Not all requirements documented
Dependence on heroes
Project Planning
Project Management
Configuration Management
Software QA
34
Intuitive
Policies exists
Process dependent on individuals
Training
Technical Practices
Process Focus (Stds, SEPG)
17
Qualitative
Process defined and institutionalized
Process Measurement
Process Analysis
Quantitative Quality Plans
4
Quantitative
Measured Process
Changing Technology
Problem Analysis
Problem Prevention
Improvement routinely fed
back into the process
Continuous Process
Improvement
1
Result
Risk
High
Productivity
and Quality
High
58
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Initial
Process is informal and ad hoc
Just Do It
Probability
Evolution of Process Capability
1
Managed
Product and processes are
quantitatively controlled
Probability
Defined
Technical practices are
integrated with management
practices and institutionalized
Probability
Repeatable
Project management practices
are institutionalized
Probability
Time/$/...
2
Time/$/...
3
4
Time/$/...
Optimizing
Process improvement is
institutionalized
(see page 28 in the CMM)
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Probability
Time/$/...
5
Time/$/...
59
Assess-IT
Working to Improve Software Development Processes
View of Process at Each Maturity Level
Initial
Process is ad hoc and informal
Repeatable
Project management practices
are institutionalized
Defined
Technical practices are
integrated with management
practices and institutionalized
Managed
Product and processes are
quantitatively controlled
Optimizing
Process improvement is
institutionalized
(see page 23 in the CMM)
(C) 2000 Assess-IT, Inc. All Rights Reserved.
In
Out
In
Out
In
Out
In
Out
In
Out
60
Assess-IT
Working to Improve Software Development Processes
Structure of the Maturity Continuum
Planning
To improve
To forecast
Input to
Standards
To produce
Activity
Input to
To improve
Results
Input to
Evaluation
To improve
Adapted from Caputo – CMM Implementation Guide
Initial
Repeatable
Defined
Managed
Optimizing
61
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Level Skipping Isn’t Not Allowed, It’s Impossible
• Higher level processes may be attempted, they may
be less effective
• Capability is built in stages
• Without management, process is sacrificed
• Without process, measurements can’t be taken
• Without measurement, effective process improvement is
impossible
62
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Summary of Module 4
• The CMM is a 5 level staged model
• It focuses on management issues
• Visibility into the process depends on its maturity
• It predicts the capabilities and challenges of various
organizations at differing levels of process maturity
• Each layer builds on the foundations laid by the
previous levels
63
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Some Level 2 Concepts
• Requirements Management
• Gather, agree on, commit to and use the requirements
• Software Project Planning, Tracking and Oversight
• Estimate, plan, manage to the plan and take corrective action when
necessary
• Software Subcontract Management
• Select, hire and manage qualified subcontractors
• Software Quality Assurance
• Ensure the work is being done according to the standards
• Software Configuration Management
• Identify and keep track of all the work products
(see page 32 in the CMM)
64
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 4 Exercise
Task: Break into the same teams as the last exercise. For each
Level 2 KPA, identify a problem that you encountered in the
exercise. Document the problems and choose someone to
present them to the class
Outcome: A list of the problems encountered in the last exercise,
sorted by KPA
Duration: 45 Minutes
• Discuss and document problems (30 minutes)
• Present to class (5 minutes)
65
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 5
CMM Structure
66
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 5 Objectives
• Locate information in the CMM
• Identify the Common Features in the CMM
• Explain how the CMM is structured
67
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Structure of the CMM
Maturity
Level
Contain
Indicate
Organized By
KPA
Process
Capability
Achieve
Goal
Common
Feature
Address
Implementation
Institutionalization
Contain
Key
Practice
Describe
Activities
Infrastructure
(see page 31 in the CMM)
(C) 2000 Assess-IT, Inc. All Rights Reserved.
68
Assess-IT
Working to Improve Software Development Processes
Structure of the CMM (Alternate View)
Maturity Level
Key Process
Area
2
RM
SPP
SPTO
SSM
SQA
SCM
Goals
Common
Features
Activities
Commitment
Ability
Measurement
& Analysis
Verification
Key Practices
69
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Maturity Level
• Well defined evolutionary plateau, a layer in the
foundation for subsequent process improvement
activities
• Predicts a range of results expected from following a
process
• Lowest common denominator of all the KPAs
grouped under a particular maturity level
70
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Optimizing (5)
Assess-IT
Working to Improve Software Development Processes
Process Change Management
Technology Change Management
Defect Prevention
The Maturity
Levels
Managed (4)
Software Quality Management
Quantitative Process Management
Defined (3)
Peer Reviews
Intergroup Coordination
Software Product Engineering
Integrated Software Management
Training Program
Organization Process Definition
Organization Process Focus
Repeatable (2)
Software Configuration Management
Software Quality Assurance
Software Subcontract Management
Software Project Tracking and Oversight
Software Project Planning
Requirements Management
Initial (1)
(see page 33 in the CMM)
71
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
CMM Metrics
Maturity
Level
Key Process Areas (KPA)
No. of Goals
per KPA
5
Process change management
Technology change management
Defect prevention
3
3
3
4
Software quality management
Quantitative process management
3
3
Peer reviews
Intergroup coordination
Software product engineering
Integrated software management
Training program
Organization process definition
Organization process focus
2
3
2
2
3
2
3
Software configuration management
Software quality assurance
Software subcontract management
Software project tracking and oversight
Software project planning
Requirements management
4
4
4
3
3
2
3
2
TOTALS
No. of Key
Practices per KPA
Subtotal
9
Subtotal
6
Subtotal
17
Subtotal
20
52
19
19
18
13
18
9
17
20
19
16
11
16
21
17
22
24
25
12
TOTALS
Subtotal
56
Subtotal
31
Subtotal
108
Subtotal
121
316
72
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Maturity Levels
Indicate Performance Capability
• Initial – ad hoc, based on the heroism of individuals, not
repeatable
• Repeatable – disciplined adherence to process, earlier project
successes repeatable, plans and estimates are reasonable
• Defined – organization wide processes in place, process
group in place for the organization’s benefit
• Managed – Quantitative goals are set, performance
predictions can be made, special causes of variance are
identified
• Optimizing – Organization focus on continuous improvement
73
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Key Process Area
• Identifies a cluster of related activities that, when
performed collectively, achieve a set of goals
considered important for enhancing process
capability
• Defined to reside at a single maturity level
• Identify the issues that must be addressed to achieve
a maturity level
74
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Key Process Area Sample
Requirements Management – “The purpose of
Requirements Management is to establish a common
understanding between the customer and the software
project of the customer’s requirements to be addressed
by the software project. This agreement with the
customer is the basis for planning and managing the
software project.”
75
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Goals
• High level statements that characterize or summarize
a KPA
• 2-4 goals for each KPA
• They are considered important for enhancing process
capability for a given maturity level.
• They can an be used to guide organizations and
appraisal teams in assessing alternative ways to
implement key process areas.
• Attainable yet may not be measurable
76
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Goals Sample
Software Project Planning Goal 3 – “Affected groups
and individuals agree to their commitments related to
the software project.”
77
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Common Features
Are a device for organizing the key practices within a
KPA
• Institutionalization
• Enablers – infrastructure for doing work
• Commitment to Perform
• Ability to Perform
• Measurement and Analysis
• Verifying Implementation
• Implementation
• Getting the work done
• Activities Performed
78
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Commitment to Perform
What results do we want to achieve?
What actions must we take to ensure that the process is
established and will endure?
Involves establishing organizational policies and senior
management sponsorship.
79
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Ability to Perform
Can we achieve those results?
What preconditions must exist in the project or
organization to implement the software process
competently?
Involves resources, organizational structures, and
training.
80
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Activities Performed
What do we have to do to achieve the results?
What activities, roles and procedures are necessary to
implement a Key Process Area?
Involves establishing plans and procedures, performing
the work, tracking it, and taking corrective actions as
necessary.
81
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Measurement and Analysis
What are the current results in comparison to the
desired results?
What basic measurements are needed to determine the
process status and correct any deviances.
Includes the measurements that could be taken to
determine the status and effectiveness of the Activities
Performed.
82
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Verifying Implementation
How will we know / be able to prove we have achieved
the desired results.
What steps must we take to verify compliance with the
processes and procedures?
Involves reviews and audits by management and
software quality assurance.
83
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Key Practices
• Organized under common features
• Components of the CMM that actually guide the
organization in what needs to be done
• Retain the nomenclature of the common features they
fall under
• During an assessment
• Activities Performed common feature is examined at the key
practices level
• The other four common features are examined at the
common feature level
84
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Commitment to Perform Samples
• A <role> is designated to be responsible for <x>
• Senior management sponsors <x>
• The project follows a written organizational policy for
<x>
85
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Ability to Perform Samples
• Responsibilities to perform <x> are assigned
• Adequate resources and funding for <x> are provided
• Practitioners of <x> receive training or orientation
86
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Activities Performed Samples
• RM Ac 1 – The software engineering group reviews
the allocated requirements before they are
incorporated into the software project
• SPP Ac 7 – The plan for the software project is
documented
• SQA Ac 4 – The SQA group reviews the software
engineering activities to verify compliance
87
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Measurement and Analysis Sample
• Measurements are made and used to determine the
status of the activities (X)
88
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Verification Samples
• Senior manager reviews are conducted periodically
• Project manager reviews are conducted periodically
and on an as needed basis
• SQA reviews/audits the activities and work products
to ensure compliance, and reports their findings
89
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Key Process Area Template
KPA Name
a key process for Level N: <Level name>
The purpose of <KPA N> is <statement of purpose>
<KPA N> involves <summary of KPA>
<Additional elaboration of KPA N as necessary>
Goals
Goal N <Process summary statement as goal>
Commitment to Perform
Commitment N <Statement of commitment N>
Ability to Perform
Ability N <Statement of ability N>
Activities Performed
Activity N <Statement of activity N>
Measurement and Analysis
Measurement N <Statement of measurement N>
Verifying Implementation
Verification N <Statement of verification N>
(see page 43 in the CMM)
90
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Summary of Module 5
• Know how to locate information in the CMM
• Covered the Common Features in the CMM
• The CMM is hierarchically structured
91
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 5 Exercise
Task: Complete the two “Structure of the CMM”
problems. This is an individual exercise
Outcome: Successfully completed CMM structure
charts
Duration: 15 Minutes
92
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 5 Exercise
93
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 5 Exercise
Maturity
Level
Contain
Indicate
Organized By
KPA
Process
Capability
Achieve
Goal
Common
Feature
Address
Implementation
Institutionalization
Contain
Key
Practice
Describe
Activities
Infrastructure
94
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 5 Exercise
_______________
_______________
_______________
_______________ __________ __________ __________ __________
__________
_______________
95
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 5 Exercise
Maturity Level
Key Process
Area
2
RM
SPP
SPTO
SSM
SQA
SCM
Goals
Common
Features
Activities
Commitment
Ability
Measurement
& Analysis
Verification
Key Practices
96
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 6
KPAs at the Repeatable Level
97
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 6 Objectives
• Name the KPAs in the Repeatable Level, Level 2
• Describe the purpose of each of the Level 2 KPAs
• Explain the terminology associated with each of the
Level 2 KPAs
98
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Moving from Level 1 to Level 2
• At level 1 the job gets done
• At level 2 management practices for getting the job
done are in place
• Level 2 projects have disciplined processes in place
99
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 6
KPAs at the Repeatable Level
• Requirements Management
• Software Project Planning
• Software Project Tracking and Oversight
• Software Subcontract Management
• Software Quality Assurance
• Software Configuration Management
100
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Requirements Management (RM)
The purpose of Requirements Management is 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.
Goal 1 System requirements allocated to software are controlled to
establish a baseline for software engineering and management
use.
Goal 2 Software plans, products, and activities are kept consistent
with the system requirements allocated to software.
101
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Key Aspects of RM
• Requirements
• Allocated to software
• Customer
• Baseline
• Software Engineering and Management Use
• Common understanding
• Controlled / documents
• Kept consistent (Implies changes MIGHT occur)
102
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Allocated Requirements
Hardware
Engineers
Customer
System
Engineering
Software
Engineers
User
People
(Users)
103
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Types of Requirements
• Functional
• Performance
• Non-Performance
• Design (Special case of GUI requirements)
• Non-Functional
• “Ilities” – Reliability, Maintainability, Scalability, etc.
• Efficiency
104
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Dimensions of a Requirements Set
• Necessary
• Sufficient
• Consistent
• Concise
• Testable
• Traceable
• Documented
• Agreed To
105
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Requirements Definition Exercise
Task: Prepare a written specification that will allow your partner to
recreate the objects drawn on your problem sheet. The objects
should be similarly sized, oriented and positioned.
Outcome: A written specification
Duration: 35 Minutes
• Prepare specification (20 minutes)
• Follow the specification (10 minutes)
• Make fun of the results (5 minutes)
106
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Requirements Management Inhibitors
107
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Requirements Management Inhibitors
• The right people are not involved in gathering
requirements
• The requirements group is not all inclusive
• Requirements management is assigned to people
who do not have other skills
• The people who should be assigned to requirements
management are too busy doing REAL jobs
• The customer does not want to document the
requirements
• The customer bypasses the manager and goes
straight to the developers
108
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Software Project Planning (SPP)
The purpose of Software Project Planning is to establish
reasonable plans for performing the software engineering and for
managing the software project.
Goal 1 Software estimates are documented for use in planning and
tracking the software project.
Goal 2 Software project activities and commitments are planned
and documented.
Goal 3 Affected groups and individuals agree to their commitments
related to the software project.
109
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Key Aspects of SPP
• Reasonable plans
• Documented
• Estimates
• Activities are planned
• Commitments are agreed to
• Affected groups and individuals
110
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
What Does a Software Plan Contain?
• Text book answer
Put everything in the plan that you consider important
enough to keep track of.
111
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
What Does a Software Plan Contain?
• Why we are doing this work
• What work did we agree to do
• Structure of organization doing work
• Roles and responsibilities needed to perform work
• Estimates (size, effort, resources, equipment, schedule)
• What processes/methods/tools will we use
• Progress and status reporting
• What could go wrong (Risk) and what to do about it
• Waivers if we decide to do it differently
• Change/update mechanism JUST IN CASE anything ever
changes over the course of the project
112
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
The First Rule of Risks
Unmitigated Risks do not Magically
Disappear;
They usually show up where you
least expect them !!!
113
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Software Project Planning Inhibitors
114
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Software Project Planning Inhibitors
• Authority vs Responsibility of project manager
• Person assigned to write the plan has insufficient
information
• We don’t need a plan, we only do it because it is a
contract deliverable
• No time to plan, we barely have time to do the work
• Unrealistic demands, what’s the point of planning
115
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Software Project Tracking and Oversight
(SPTO)
The purpose of Software Project Tracking and Oversight is 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.
Goal 1 Actual results and performances are tracked against the
software plans.
Goal 2 Corrective actions are taken and managed to closure when
actual results and performance deviate significantly from the
software plans.
Goal 3 Changes to software commitments are agreed to by the
affected groups and individuals.
116
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Key Aspects of SPTO
• Software plans
• Adequate visibility
• Actual results
• Significant deviation
• Corrective action
• Changes to commitments are agreed to
• Affected groups and individuals
117
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Know When to Take Corrective Action
(The First Rule of Holes)
HELP
When you find yourself in one, STOP DIGGING !!!
118
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
The Last Plan is Always Right
Retire
Support
Implement
Test
Code
Design
Analyze
Plan
5/99
6/99
7/99
8/99
9/99
10/99
11/99
12/99
1/00
2/00
3/00
4/00
5/00
6/00
7/00
8/00
9/00
10/00
11/00
12/00
1/01
2/01
3/01
4/01
5/01
6/01
7/01
Scope
1/01
12/00
11/00
10/00
9/00
8/00
7/00
6/00
5/00
4/00
3/00
2/00
1/00
12/99
11/99
10/99
9/99
119
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Software Project Tracking and Oversight Inhibitors
120
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Software Project Tracking and Oversight
Inhibitors
• Authority vs Responsibility of project manager
• No plan to manage to
• Plans are not kept up to date
• The plan was unrealistic to begin with
• Too busy working, no time for management
• So busy fighting fires, there is no time to be proactive
121
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Software Subcontract Management (SSM)
The purpose of Software Subcontract Management is to select
qualified software subcontractors and manage them effectively.
Goal 1 The prime contractor selects qualified software
subcontractors.
Goal 2 The prime contractor and the software subcontractor agree
to their commitments to each other.
Goal 3 The prime contractor and the software subcontractor
maintain ongoing communications.
Goal 4 The prime contractor tracks the software subcontractor's
actual results and performance against its commitments.
122
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Key Aspects of SSM
• Select qualified subcontractors
• Effective management
• Agreement on commitments
• Ongoing communications
• Actual results compared to commitments
123
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
CMM Definition of a Subcontractor
• An outside entity to whom you give a specification.
At the end of the agreed to period, the sub-contractor
gives you the contracted product. The product is at
an acceptable level of quality.
124
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Software Subcontract Management Inhibitors
125
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Software Subcontract Management Inhibitors
• No specifically assigned subcontract manager
• SOW ill-defined or missing critical information
• Volatile requirements
• Terminology focused misunderstandings
126
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Software Quality Assurance (SQA)
The purpose of Software Quality Assurance is to provide
management with appropriate visibility into the process being used
by the software project and of the products being built.
Goal 1 Software quality assurance activities are planned.
Goal 2 Adherence of software products and activities to the
applicable standards, procedures, and requirements is verified
objectively.
Goal 3 Affected groups and individuals are informed of software
quality assurance activities and results.
Goal 4 Noncompliance issues that cannot be resolved within the
software project are addressed by senior management.
127
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Key Aspects of SQA
• Appropriate visibility
• Process and products
• Activities are planned
• Standards, procedures, requirements
• Adherence verified objectively
• Affected groups and individuals are informed
• Resolution of non-compliance
• Senior management involvement
128
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Objective vs Independent
• Objectivity – SQA is able to ensure compliance with
organization standards in accordance with a
documented process and based on objective data.
• Independent – SQA does not have a supervisor /
supervisee relationship with the project manager they
are SQAing
129
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Software Quality Assurance Inhibitors
130
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Software Quality Assurance Inhibitors
• Lack of respect for SQA as a discipline
• Hostile relationship between developers and SQA
• Customer will not pay for SQA, therefore it is not
needed
• No time for independent reviews, the product is
already late
• Disbelief in the value of SQA
• Belief that SQA is responsible for quality
131
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Software Configuration Management (SCM)
The purpose of Software Configuration Management is to establish
and maintain the integrity of the products of the software project
throughout the project's software life cycle.
Goal 1 Software configuration management activities are planned.
Goal 2 Selected software work products are identified, controlled,
and available.
Goal 3 Changes to identified software work products are controlled.
Goal 4 Affected groups and individuals are informed of the status
and content of software baselines.
132
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Key Aspects of SCM
• Establish and maintain integrity of products
• Throughout lifecycle
• Activities are planned
• Work products
• Identified, controlled, available
• Changes are controlled
• Affected groups and individuals are informed of
status and content of baselines
• Baselines and Developmental Baseline
133
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Software Configuration Management Inhibitors
134
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Software Configuration Management Inhibitors
• Don’t know that SCM exists
• If I give it to SCM before it is done, I may never get it
back
• I want complete control of MY product
• Lack of automated support
• Schedule pressure
135
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Summary of Module 6 (1 of 3)
• RM
• Control the requirements
• Use the requirements as the basis to proceed
• Keep all of the work products in sync as the requirements
change
• SPP
• Develop and document estimates
• Develop and document the plan
• Get commitment to the plan
136
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Summary of Module 6 (2 of 3)
• SPTO
• Use the plan to manage the project
• Take corrective action when necessary
• Renegotiate commitments and update the plan
• SSM
• Define the work to be subcontracted
• Select capable subcontractors
• Manage the subcontract according to the contract
• Maintain ongoing communications
137
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Summary of Module 6 (3 of 3)
• SQA
• Plan the SQA activities
• Review and/or audit the software processes and products
• Report findings of non-compliance within the software group
• Escalate when necessary
• SCM
• Plan the SCM activities
• Identify and maintain configuration items
• Systematically control changes
• Maintain work product integrity throughout the lifecycle
138
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 6 Exercise A
Task: For your assigned KPA, describe the inputs,
tasks and outputs. This is an individual exercise.
Outcome: A description of the inputs, tasks and outputs
for your KPA
Duration: 15 Minutes
139
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 6 Exercise A Worksheet
Inputs
Tasks
Outputs
140
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 6 Exercise B
Task: Break into groups according you the KPA you
worked on and develop a group solution. Choose a
person to present to the group
Outcome: A presentation of the group’s solution
Duration: 30 Minutes
• Develop the presentation (20 minutes)
• Present to the class (3 minutes)
141
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 7
KPAs at the Defined Level
142
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 7 Objectives
• Name the KPAs in the Defined Level, Level 3
• Describe the purpose of each of the Level 3 KPAs
• Explain the terminology associated with each of the
Level 3 KPAs
143
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Moving from Level 2 to Level 3
• At Level 2 practices are repeatable at the project
level
• At Level 3 the organization takes a front seat and the
projects start using the organization processes
144
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 7
KPAs at the Defined Level
• Organization Process Focus
• Organization Process Definition
• Training Program
• Integrated Software Management
• Software Product Engineering
• Intergroup Coordination
• Peer Reviews
145
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Organization Process Focus (OPF)
The purpose of Organization Process Focus is to establish
the organizational responsibility for software process
activities that improve the organization's overall software
process capability.
Goal 1 Software process development and improvement
activities are coordinated across the organization.
Goal 2 The strengths and weaknesses of the software
processes used are identified relative to a process standard.
Goal 3 Organization-level process development and
improvement activities are planned.
146
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Key Aspects of OPF
• Organizational responsibility (SEPG, Process Action
Teams, Quality Circles)
• Software process improvement activities
• Coordination across the organization
• Comparison to a standard (Reference Model)
• Activities are planned
147
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Role of the SEPG
• Establish process standards
• Maintain the process database
• Serve as the focal point for technology transition
• Provide process education
• Provide project consultation
• Make periodic assessments and status report
148
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Organization Process Focus Inhibitors
149
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Organization Process Focus Inhibitors
• No time for improvement, too busy doing real work
• Who wants to be one of THOSE PROCESS PEOPLE
• Why can’t we just document our process later, then at
least it will match how we do it
• Lack of respect for Process Improvement as a
discipline
• Lack of dedicated resources
• Lack of senior management sponsorship
150
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Organization Process Definition (OPD)
The purpose of Organization Process Definition is 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.
Goal 1 A standard software process for the organization is
developed and maintained.
Goal 2 Information related to the use of the organization's standard
software process by the software projects is collected, reviewed,
and made available.
151
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Key Aspects of OPD
• Usable set of software process assets
• Organization’s standard software process
(see page 66 in the CMM)
• Information is collected, reviewed, shared
• The organization’s standard process must be tailored
for the project (See ISM)
• Across projects implies not only each project, but for
its duration (entire lifecycle) as well (See OPD Ac 3 &
SPP Ac 5)
• Software process database and library
152
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
What is Meant by Lifecycle
Scope
Plan
Analyze
Design
Construct
Test
SPP Ac 5 – A software lifecycle with
predefined stages of manageable
size is identified or defined.
Implement
Support
Retire
153
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Lifecycle Components
•
Purpose – Purpose of the Phase
•
Stakeholders – Who cares about the quality outcome
•
Entry Criteria – What needs to occur before we can start
•
Steps – What do we need to do during this phase
•
Exit Criteria – What needs to occur before we can declare completion
•
Process Records – How do we prove we followed the process
•
Methods – What are the acceptable ways to accomplish this phase
•
Templates – Are there any documentation guidelines
•
Tools – Is there automated tool support for the work products of this phase
•
Measurements – What data should we collect and analyze to improve the
products and processes
154
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Organization Process Definition Inhibitors
155
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Organization Process Definition Inhibitors
• Don’t understand process definition
• Don’t have any best practices to work from
• Process descriptions are too detailed
• Process descriptions are too abstract
• Process descriptions are too complex
156
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Training Program (TP)
The purpose of the Training Program key process area is to
develop the skills and knowledge of individuals so they can perform
their roles effectively and efficiently.
Goal 1 Training activities are planned.
Goal 2 Training for developing the skills and knowledge needed to
perform software management and technical roles is provided.
Goal 3 Individuals in the software engineering group and softwarerelated groups receive the training necessary to perform their roles.
157
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Key Aspects of TP
• Activities are planned
• Training (Coaching, Mentoring, Classes, Seminars)
• Training is provided
• Develop skills and knowledge needed
• At level 2 – receive training
• At level 3 – receive required training
• Management and technical training
• Receive necessary training
158
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Training – Three Different Flavors
• Organizational level training
• Training needed to be an effective member of the
organization (policies, time keeping, appraisals, etc.)
• Project specific training
• Training needed to be an effective contributor to the currently
assigned project (languages, tools, compilers, etc.)
• Personal development training
• Training needed/desired by the individual to advance their
career (management, technical, areas of interest, etc.)
159
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Training Program Inhibitors
160
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Training Program Inhibitors
• We don’t need no stinking training! – we only hire
qualified people 
• Time
• Money
• Lack of management support
• No incentives
• Not high priority
161
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Integrated Software Management (ISM)
The purpose of Integrated Software Management is 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, which are
described in Organization Process Definition.
Goal 1 The project's defined software process is a tailored version
of the organization's standard software process.
Goal 2 The project is planned and managed according to the
project's defined software process.
162
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Key Aspects of ISM
• Integrate engineering and management activities
• Tailored version of organization’s standard process
(see page 66 in the CMM)
• Projects are planned and managed accordingly
• Project management evolves
• Allows for anticipation of problems yet to come
163
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Integrated Software Management Inhibitors
164
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Integrated Software Management Inhibitors
• There is no organizational process to tailor from
• It is difficult to understand how the organization’s
process assets are organized
• Don’t understand or know how to tailor
• Organizational guidelines and customer requirements
are in conflict
165
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Software Product Engineering (SPE)
The purpose of Software Product Engineering is to consistently
perform a well-defined engineering process that integrates all the
software engineering activities to produce correct, consistent
software products effectively and efficiently.
Goal 1 The software engineering tasks are defined, integrated, and
consistently performed to produce the software.
Goal 2 Software work products are kept consistent with each other.
166
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Key Aspects of SPE
• Consistently perform standard process
• Software work products are kept consistent with each
other
• Produce correct, consistent software products
• Effectively and efficiently
167
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Tying the Level 3 Tripod Together
• OPD – Defines the organization’s process assets
• ISM – Plans the work, based on the process assets
• SPE – Performs the work according to the plans
Project
Process
168
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Software Product Engineering Inhibitors
169
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Software Product Engineering Inhibitors
• Incompatible tools and methods
• Ineffective tools and methods
• Schedule pressure to violate the standards just to get
the job done
170
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Intergroup Coordination (IC)
The purpose of Intergroup Coordination is 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.
Goal 1 The customer's requirements are agreed to by all
affected groups.
Goal 2 The commitments between the engineering groups
are agreed to by the affected groups.
Goal 3 The engineering groups identify, track, and resolve
intergroup issues.
171
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Key Aspects of IC
• Customer’s requirements are agreed to
• Agreement by all affected groups
• Commitments among groups are agreed to
• Issues are resolved internally
• Interdisciplinary teams
172
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Intergroup Coordination Inhibitors
173
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Intergroup Coordination Inhibitors
• Closed organization with rigid organizational barriers
(Stovepipes, Silos, Towers, etc.)
• Loss / lack of control
• Turf battles
174
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Peer Reviews (PR)
The purpose of Peer Reviews is to remove defects from
the software work products early and efficiently. An
important corollary effect is to develop a better
understanding of the software work products and of
defects that might be prevented.
Goal 1 Peer review activities are planned.
Goal 2 Defects in the software work products are
identified and removed.
175
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Key Aspects of PR
• Activities are planned
• Identify and remove defects
• Early and efficiently
• Identify common errors
• Cross training among projects
176
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Questions, Questions, Questions
Why Remove Defects Early?
Isn’t It Enough Just to Remove Them
Before We Deliver?
177
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Why Remove Defects Early
Example from the aerospace industry
Cost to Fix Defect
$1,000,000
$100,000
$10,000
$1,000
$100
$10
$1
•
•
•
•
•
•|
•
|
|
|
Scope Analysis Design Construct
|
|
Test
|
Implement Support
Project Lifecycle Phases
178
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Setting Up and Conducting Peer Reviews
• Plan the reviews
• Train the leaders and participants
• Hand out review material in advance
• Assign peer review roles
• Specify entry / exit criteria for the review
• During the review, use checklists
• Identify action items and track to closure
• Collect and analyze data for use in product / process
improvement
179
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Peer Review Inhibitors
180
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Peer Review Inhibitors
• Take too much time
• I don’t want my peers looking at my work
• Isn’t error detection why we do testing
• Schedule pressure
• Hostile review environment
181
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Summary of Module 7 (1 of 4)
• The focus shifts to the ORGANIZATION
• OPF
• Coordinate SPI activities
• Identify strengths and weaknesses of processes
• Plan the SPI efforts
• OPD
• Develop and maintain a standard process
• Collect, review and distribute data and documents
related to the standard process
182
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Summary of Module 7 (2 of 4)
• TP
• Plan training activities
• Provide training
• Ensure required training is taken or waivered
• ISM
• Develop the project’s defined process (tailor)
• Manage the project according to the plan, which is
based on the organization’s standard process
183
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Summary of Module 7 (3 of 4)
• SPE
• Perform the software activities in a defined,
integrated and consistent manner
• Ensure consistency among software work
products
• IC
• Involve all affected groups
• Ensure commitments are agreed to by all parties
• Identify, track and resolve intergroup issues
184
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Summary of Module 7 (4 of 4)
• PR
• Plan the peer review activities
• Conduct the peer reviews
• Identify and remove defects
• Collect and use data
185
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 8
KPAs at the Managed Level
186
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 8 Objectives
• Name the KPAs in the Managed Level, Level 4
• Describe the purpose of each of the Level 4 KPAs
• Explain the terminology associated with each of the
Level 4 KPAs
187
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Moving from Level 3 to Level 4
• At Level 3 the organizations are using their standard
processes and measuring the results
• At Level 4 the measurement data are used to
determine if errors are statistically significant and
whether their cause should be uncovered, of if they
are within statistical norms
188
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 8
KPAs at the Managed Level
• Quantitative Process Management
• Software Quality Management
189
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Statistical Process Control
T
i
m
e
T
o
R
e
p
a
i
r
Old Saying: May the best of your past be the worst of your future!
190
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Quantitative Process Management (QPM)
The purpose of Quantitative Process Management is to control the
process performance of the software project quantitatively.
Software process performance represents the actual results
achieved from following a software process.
Goal 1 The quantitative process management activities are
planned.
Goal 2 The process performance of the project's defined software
process is controlled quantitatively.
Goal 3 The process capability of the organization's standard
software process is known in quantitative terms.
191
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Key Aspects of QPM
• Quantitative control
• Process performance
• Activities are planned
• Process capability is known
192
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Software Quality Management (SQM)
The purpose of Software Quality Management is to develop a
quantitative understanding of the quality of the project's software
products and achieve specific quality goals.
Goal 1 The project's software quality management activities are
planned.
Goal 2 Measurable goals for software product quality and their
priorities are defined.
Goal 3 Actual progress toward achieving the quality goals for the
software products is quantified and managed.
193
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Key Aspects of SQM
• Quantitative understanding
• Activities are planned
• Progress is quantified and managed
194
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Summary of Module 8
• QPM
• Measurement data are used to make
quantitatively based process decisions
• SQM
• Develop a quantitative expectation for product
behavior
195
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 9
KPAs at the Optimizing Level
196
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 9 Objectives
• Name the KPAs in the Optimizing Level, Level 5
• Describe the purpose of each of the Level 5 KPAs
• Explain the terminology associated with each of the
Level 5 KPAs
197
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Moving from Level 4 to Level 5
• At Level 4 the measurement data were used identify
statistically significant errors
• At Level 5 the organization is able determine how
and when to modify its processes while it is following
them.
198
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 9
KPAs at the Optimizing Level
• Defect Prevention
• Technology Change Management
• Process Change Management
199
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Defect Prevention (DP)
The purpose of Defect Prevention is to identify the cause of defects
and prevent them from recurring.
Goal 1 Defect prevention activities are planned.
Goal 2 Common causes of defects are sought out and identified.
Goal 3 Common causes of defects are prioritized and
systematically eliminated.
200
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Key Aspects of Defect Prevention
• Activities are planned
• Common causes of defects are identified
• Common causes are prioritized and eliminated
201
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Technology Change Management (TCM)
The purpose of Technology Change Management is to identify new
technologies (i.e., tools, methods, and processes) and track them
into the organization in an orderly manner.
Goal 1 Incorporation of technology changes are planned.
Goal 2 New technologies are evaluated to determine their effect on
quality and productivity.
Goal 3 Appropriate new technologies are transferred into normal
practice across the organization.
202
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Key Aspects of TCM
• Activities are planned
• New technologies evaluated
• Incorporated in orderly manner
203
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Process Change Management (PCM)
The purpose of Process Change Management is 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.
Goal 1 Continuous process improvement is planned.
Goal 2 Participation in the organization's software process
improvement activities is organization wide.
Goal 3 The organization's standard software process and the
projects‘ defined software processes are improved
continuously.
204
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Key Aspects of PCM
• Activities are planned
• Organization wide participation
• Continuous improvement
205
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Summary of Module 9
• DP
• Identify the common causes of defects and
remove them
• TCM
• Evaluate then judiciously and efficiently
incorporate new technology and tools
• PCM
• Organization wide involvement in improving the
processes followed
206
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 10
Issues of Interpretation and Terminology
207
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 10 Objectives
• Where to go in the CMM for definitions and
explanations of terminology
208
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Interpreting the CMM
• Within the context of the organization
• Business needs
• Size
• Geographic distribution
• Maturity level
• The CMM is based on common sense
• Don’t over analyze
• Use professional judgement
If it ever seems the CMM is telling you to do too much, you are
probably reading something in that is not there!!
209
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Worth Repeating
If it ever seems the CMM is telling you to
do too much, you are probably reading
something in that is not there!!
210
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Terminology
• Glossary – the CMM contains an excellent resource
within itself for determining the meanings of the terms
it uses. (see Chapter 4, pages 41 – 79 in the CMM)
• SEPGs – Don’t expect your organizations to learn the
CMM terminology, map the CMM’s terms onto your
organization’s terminology.
211
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Module 11
Conclusion
212
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Last Question
What are the major themes in the
CMM
213
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Major Themes in the CMM (Last Exercise)
• __________________
• __________________
• __________________
• __________________
• __________________
• __________________
• __________________
• __________________
• __________________
• __________________
• __________________
• __________________
214
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Major Themes in the CMM
• Planning
• Agreeing
• Managing
• Documenting
• Performing
• Measuring
• Controlling
• Training
• Reviewing
• Re-Planning
• Committing
• Continuously Improving
215
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
What Does a Mature Organization Look Like
• Processes are defined, documented, and used
• Management - plans, monitors, and communicates
• Roles and responsibilities are clear
• Product and process are measured
• Quality, cost, and schedule are predictable
• Technology is planned and used effectively
• Continuous improvement is a way of life
216
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Things to Remember About the CMM
• Was / is user developed and supported
• Based on state of the practice not theory
• Scalable to your organization’s needs
• Tailorable for your organization’s needs
• Requires and demands professional judgement
217
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Things to Remember About Process Improvement
• Start slowly
• Start at a high level and work down
• Define roles and responsibilities
• Ask for help from those who have to follow the
processes
It’s Better to Not Get Started,
Than to Get Started and NOT Follow Through!!!
218
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
This is Really the Last Question, I Promise
Do You Have To Be At A Certain
Level to Follow the Key Practices of
That Level?
219
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Maturity Level and Key Practices
NO !!
• You really have to do all of them, all the time
• More mature organizations just execute them more
effectively
220
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
VERY IMPORTANT
Continuous Process Improvement
is
Continuous
221
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Process Improvement References
“Why Do Organizations have Assessments? Do They Pay Off?”
[CMU/SEI-99-TR-012]
• “Process Maturity Profile of the Software Community” published
semi-annually by the SEI
• “Moving On Up: Data and Experience Doing CMM-Based
Software Process Improvement” [CMU/SEI-95-TR-008]
• “After the Appraisal: A Systematic Survey of Process
Improvement, its Benefits, and Factors that Influence Success”
[CMU/SEI-95-TR-009]
• “Benefits of CMM-Based Software Process Improvement: Initial
Results” [CMU/SEI-94-TR-013]
http://www.sei.cmu.edu
222
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Expectations
• Did we cover everything?
223
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Questions / Comments
224
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Assess-IT
Working to Improve Software Development Processes
Administrivia
• Attendance
• Course and instructor critiques
• Certificates
225
(C) 2000 Assess-IT, Inc. All Rights Reserved.
Descargar

Executive Briefing