Upload
dorcas-poole
View
222
Download
0
Embed Size (px)
Citation preview
CSE 7315 - SW Project Management / Module 35 - Software Process MaturityCopyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
Slide 1
CSE7315M35
January 10, 2004
SMU CSE 7315 / NTU SE 584-NPlanning and Managing a
Software Project
Module 35Software Process Maturity
Slide # 2 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Objectives of This Module
• To examine several models of software process maturity
• To introduce the SEI CMM (Capability Maturity Model)
Slide # 3 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Desirable Characteristics of a Software Development Process
(*)
• Predictable– Cost and schedule commitments can be
made on the basis of reliable techniques, and then can be counted on
• Productive– Efficient relative to other processes
(*) These are also desirable characteristics of software
Slide # 4 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Other Desirable Characteristics
• Effective– Requirements or expectations can be
met, if committed to– Quality meets accepted standards
• Improvable– Can increase predictability,
productivity, and effectiveness in an orderly and reliable manner
Slide # 5 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
How to Achieve These Characteristics?
• The principles of process management, such as statistical quality control, have been used to manage other processes to achieve these characteristics
• In concept, there seems to be no reason why the principles should not be applicable to software development
Slide # 6 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Fitting the Techniques to Software
• There are some unique issues to be taken care of– Software really is different in many ways
• As a result, the techniques might vary
• And the techniques may be less well established
• But we are learning that, if used effectively, these techniques can work for software processes
Slide # 7 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Basic Steps of Statistical Quality Control
• Define measures that tell you something about the process
• Measure what you are doing– Minimize disruption – If the measurement changes the
process too much, it is not telling you what you need to know
• Learn from the measurements• Apply what was learned to improve the
process – not to punish the practitioners!
Slide # 8 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Measure the Right Thing
Watts Humphrey’s
model of why it is easy to measure the wrong thing
Watts Humphrey’s
model of why it is easy to measure the wrong thing
WhatActually
Happened
What is Supposed
toHappen
What You Think
ActuallyHappened
Slide # 9 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Don’t Focus on the PractitionersExample - Father Teaching Son to Drive
David, I’ll be watching closely you as you park the car to see how well you are doing and help
you improve.
David is more likely to: -- be more careful than
usual (and therefore NOT behave as usual)
-- be nervous and therefore possibly error prone
NowI’m reallynervous!
Slide # 10 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Don’t Punish or Blame the Practitioners
David, this disaster isall your fault!
I’ll show you!
David is likely to be: -- defensive -- uncooperative
Slide # 11 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Focus on the Process
David will helpto improve andwill become a
better driver aswell.
David, your parking technique needs
improvement. Let’s work together to
improve it.
I had a lot of trouble with some parts, and I think I know some things
to try.
Slide # 12 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Frailey’s Maxim forLife in the Real World
You must succeed with normal, average people. Unlike the
university, you cannot reward the top students and flunk out
the rest.
Slide # 13 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
The Normal Distribution Curve
0
0.005
0.01
0.015
0.02
0.025
0.03
0.035
0.04
0.045
0.05
Mean
+ 1 - 1
+ 2
Individual Capability
Number of People with This Capabilit
y
Slide # 14 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
The Process for Improving a Process (last step of SQC)
1) Understand the current status of the process
2) Develop a vision of the desired process3) Establish a (prioritized) list of required
process improvements4) Produce a plan to accomplish these
improvements5) Commit the resources to execute the
plan6) Carry out the plan7) Repeat with step 1
Slide # 15 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
STUDENT CHALLENGE• Apply the process improvement process to
something in your everyday life• Each time, document the improvements
and the results
Example: cooking dinner1) Current status: the chicken is always
overdone and bland2) Vision: somewhat spicier, cooked just right3) a) don’t cook so long; b) try some other spices.
Slide # 16 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Example (continued)
4) a) try turning after 15 minutes b) try adding sage to the sauce5) Buy some sage, buy the other
ingredients; plan to cook it again6) Cook it again and see how it goes Not crispy enough Spices still not right7) Repeat with a revised plan
Slide # 17 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Possible Exam Question
List the steps of the process improvement process; give an example of how this process might be applied to the software design process.
Slide # 18 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
A Pitfall of Measurement
If you measure people without their knowing it– You may get accurate data
until they find out about it– Then you lose accuracy and the
trust of the people
Slide # 19 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
A Preferred Approach (part 1)
• Educate your staff in the principles of process improvement
• Work with them to develop effective measures that they do not fear and will not “fudge”
• Collect and analyze data in a cooperative manner
Slide # 20 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
A Preferred Approach (part 2)
• Use the data only to evaluate the process– Resist the urge to use the data to
evaluate the people• Demonstrate use of the data– When people see it in action, as you
told them it would be used, they gain confidence that the measures are worth collecting and not being misused
Slide # 21 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Another Pitfall
You can measure against goals
or
You can measure to determine facts about the process
Have we met our quota yet?
Are we performing effective tests?
Slide # 22 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Be Careful What You Measure
If you measure against goals, your staff may change behavior and the process to improve the metric
“We can meet the target by cutting corners and using a relaxed
standard of quality”
You want them to use the data to improve actual performance
Slide # 23 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Organizational Process Maturity
• Several authors have devised models of organizational effectiveness
• Many have learned that effectiveness depends on proper use of processes, which tends to be more prevalent in organizations with experience and maturity
• So most models use a maturity scale to measure organizational effectiveness (or potential effectiveness)
“How effective is your organization?”
Slide # 24 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Philip Crosby’s Model
• Philip Crosby first introduced the concept of a five level maturity model
• Crosby’s model was a measure of management maturity
• Crosby believed that this could be measured by evaluating effective use of processes, based on the work of Edwards Deming
Slide # 25 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Philip Crosby’s Five Patterns of Management Attitude
1 Uncertainty -- Do not understand the task
2 Awakening -- Understand the problems, not
the solutions
3 Enlightenment -- Understand how to solve
known problems
4 Wisdom -- Understand why the solutions
work
5 Certainty -- Can solve unexpected problems
Slide # 26 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Humphrey’s Model of Software Organizational
Maturity (1)• Humphrey’s model of process maturity is based on the work of Crosby and Deming
• Humphrey applied Crosby’s concept of levels to form a model of software process management maturity– He found that Crosby’s “management
attitude” approach did not work with technical people
(1) See Humphrey for additional information. Chapters 1.2.1 through 1.2.5 cover each level in detail.
Slide # 27 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Humphrey’s Five Levels1) Initial(1) - Ad-hoc and unmanaged; not
under control; depends on heroes.2) Repeatable - Stable via rigorous
management and control; can be predicted provided you use the same people and the same kind of problem
3) Defined - Stable due to knowledge and definition of processes. Predictable even if entirely new people are used. Automation begins to pay off.
(1) Originally, this was called “chaotic”
Slide # 28 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Humphrey’s Five Levels4) Managed - comprehensive
measurement and analysis. Manage by fact.
5) Optimizing(2) - significant improvements on a regular basis, in a controlled fashion.
(2) Originally, this was called “optimized”, but they realized no process is ever optimized -- the key characteristic is regular improvement.
Slide # 29 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Key Process Areas (KPAs)
• Within each level, Humphrey defined a series of capabilities that ought to be mastered
• These capabilities were designated “key process areas”
Slide # 30 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Humphrey’s ModelFocus Key Process Areas ResultLevel
Productivityand Quality
RISK
4
Managed
3
Defined
2
Repeatable
1
Initial
5
Optimizing
ProjectManagement
EngineeringProcess
Product andProcess Quality
ContinuousProcessImprovement
Heroes
Process Meas/Anal
Quality Management
Process Focus&Def’n;
Integrated SW Mgmt;
Peer Reviews; Training;
Intergroup Coord; SW
Product Engineering
Project Mgmt; Planning;
Rqmts Mgmt; SQA;SCM; Subcont. Mgmt
Defect Prevention
Technology Innovation
Process Change Mgmt
Slide # 31 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
What You Know at Each Level1 -- You make guesses and rely on heroism2 -- You know what to do3 -- You know why it should be done (based
on theory); -- You know when not to do it (exceptions
that prove the rule)4 -- You know exactly why and what (based
on factual data to supplement the theory)5 -- You keep up to date and improve; -- you anticipate what changes are
coming and how to cope with them
Slide # 32 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Rationale for the Five Levels• Historical experience (Crosby, et. al.)
with other processes• A reasonable sequence of measurable
and attainable improvement goals– You know what to do first
• Interim improvement plateaus– You don’t take on too much at a time
• They assist in setting priorities• Each level is the foundation for the next
CAVEAT: do one level at a time. Skipping levels risks ultimate failure.
Slide # 33 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Possible Exam Question
Name and describe the essential characteristics of each level in Humphrey’s five-level scale of software process maturity.
Note: you must read the text to answer properly. The class notes only cover the
highlights. This question is traditionally one of the ones I use to see if the student read
the book.
Slide # 34 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Why Get to Level 5?
• Because it’s there• Because your competitor will do it• Because it will make you one of the
most productive and highest quality organizations
Ultimately, the only reason most companies strive to improve is
that they must do so to survive.
Slide # 35 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
The Test of Commitment
Does the organization provide the necessary:– Resources– Management support and
reinforcement– Willingness to change– Actual change of the culture of the
organization
Slide # 36 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
The SEI Software Capability Maturity
Model (CMM)• This is an effort by the SEI to flesh
out the Humphrey model with best practices from the software development community
• There have been two releases to date:– Release 1.0 (1991) - Paulk91 (CMU/SEI-
91-TR-24), Weber91 (CMU/SEI-91-TR-25)– Release 1.1 (1993) - Paulk93a/b
(CMU/SEI-93-TR-24/25)
Slide # 37 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Release 2.0 of The SEI Software Capability Maturity
Model (CMM)• Release 2.0 was scheduled for 1997,
then delayed, and finally merged into the CMM Integration project (CMMI)
• Significant changes in structure from Release 1.0– Consistent with CMMs for other
disciplines– Too soon to tell whether it is an
improvement or not
Slide # 38 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Further Information on CMM• Information available from:
http://www.sei.cmu.edu/managing/managing.html
• Current release of CMM available from:
http://www.sei.cmu.edu/cmm/ cmm.html
Slide # 39 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Electronic Access to SEI
ftp.sei.cmu.edu
128.237.2.179
Slide # 40 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Why The SEI CMM? (SW Capability Maturity
Model) • The idea is to characterize an
organization at each level in terms of goals, practices, etc.
• The model is used as the basis for appraisals and other evaluations (covered in a later module)
Slide # 41 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Why Develop Such a Model
• To help organizations achieve a more capable software development organization
• The basic problem is that most organizations are immature in their software development practices, and this leads to expensive, unreliable software
• SEI was created to help industry extract itself from this condition
Slide # 42 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
What are the Characteristics of an Immature Organization?• “In an immature organization, there is no
objective basis for judging product quality or for solving product or process problems.
• “Therefore, product quality is difficult to predict.
• “Activities intended to enhance quality such as reviews and testing are often curtailed or eliminated when projects fall behind schedule.” (1)
(1) Paulk, 1993a.
NOTE: much of what follows is derived from Paulk, 1993a and 1993b (SEI CMM 1.1)
Slide # 43 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
What are the Characteristics of a Mature Organization?
• “... a mature software organization possesses an organization-wide ability for managing software development and maintenance processes.
• “The software process is accurately communicated to both existing staff and new employees, and work activities are carried out according to the planned process.
• “The processes mandated are fit for use (1) and consistent with the way the work actually gets done.
Slide # 44 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Mature Organization (continued)
• “These defined processes are updated when necessary, and improvements are developed through controlled pilot-tests and/or cost benefit analyses.
• “Roles and responsibilities within the defined process are clear throughout the project and across the organization.” (2)
(1) Humphrey, 1991 (2) Paulk, 1993.
Slide # 45 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Basic Terms
• The software process capability of an organization provides one means of predicting the most likely outcomes to be expected from the next software project the organization undertakes
• With a capable organization, you have higher confidence that the outcome will be as predicted
Software process capability describes the range of expected results that can be achieved by following a software
process.
Slide # 46 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Basic Terms
• Thus, software process performance focuses on the results achieved, while software process capability focuses on results expected.
• Recall that you need a good process model (capability) and good execution (performance) to have a good process
Software process performance represents the actual results achieved
by following a software process.
Slide # 47 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Achievement May or May Not Reflect Capability
• The capability of the project is constrained by the specific attributes of the project and the context or environment in which it is carried out.
• Capability is defined in a specific context, such as “building client-server tools in Cobol for the defense industry.”
Slide # 48 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Some Reasons Why Performance May Not Live Up
to Capability• Heavy use of new personnel• Radical changes in the application or
technology
Either of these may place a project's staff on a learning curve that causes their
project's capability and performance to fall short of the organization's full process
capability.
Slide # 49 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Process Maturity
• Maturity implies a potential for growth in capability and indicates both the richness of an organization's software process and the consistency with which it is applied in projects throughout the organization.
Software process maturity is the extent to which a specific process is
explicitly defined, managed, measured, controlled, and effective.
Slide # 50 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Possible Exam Question
Explain the difference between process maturity, process capability, and process performance
Slide # 51 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
Module Summary
• Maturity models attempt to represent the potential of an organization to be effective at software development
• The SEI CMM is an attempt to add specific practices and best practices to the Humphrey model
Slide # 52 January 10, 2004
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M35
END OFMODULE 35