copyright 1995-2009, dennis j. frailey cse7315 – software project management cse7315 m35 - version...
TRANSCRIPT
Copyright 1995-2009, Dennis J. Frailey CSE7315 – Software Project ManagementCSE7315 M35 - Version 9.01
SMU CSE 7315Planning and Managing a Software Project
Module 35
Software Process Maturity
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 2
Objectives of This Module
To examine several models of software process maturity
To introduce the SEI CMM and CMMI (Capability Maturity Model)
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 3
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
(*) These are also desirable characteristics of software
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 4
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
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 5
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
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 6
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
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 7
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!
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 8
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
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 9
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
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!
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 10
Don’t Punish or Blame the Practitioners
David, this disaster isall your fault!
I’ll show you!
David is likely to be: -- defensive -- uncooperative
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 11
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.
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 12
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.
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 13
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
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 14
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 process
3) Establish a (prioritized) list of required process improvements
4) Produce a plan to accomplish these improvements
5) Commit the resources to execute the plan
6) Carry out the plan
7) Repeat with step 1
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 15
STUDENT CHALLENGE
Apply the process improvement process to something in your everyday life
Each time, document the improvements and the results
Example: cooking dinner
1) Current status: the chicken is always overdone and bland
2) Vision: somewhat spicier, cooked just right
3) a) don’t cook so long;
b) try some other spices.
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 16
Example (continued)
4) a) try turning after 15 minutes
b) try adding sage to the sauce
5) Buy some sage, buy the other ingredients;
plan to cook it again
6) Cook it again and see how it goes
Not crispy enough
Spices still not right
7) Repeat with a revised plan
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 17
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.
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 18
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
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 19
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
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 20
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
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 21
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?
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 22
Be Careful What You Measure
If you measure against goals, your staff may change behavior and the process to improve the measurements instead of their actual performance
“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
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 23
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?”
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 24
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
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 25
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
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 26
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.
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 27
Humphrey’s Five Levels
1) 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”
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 28
Humphrey’s Five Levels
4) 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.
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 29
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”
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 30
Humphrey’s Model
Focus 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
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 31
What You Know at Each Level
1 -- You make guesses and rely on heroism
2 -- You know what to do
3 -- 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
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 32
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
WARNING: do one level at a time.Skipping levels risks ultimate failure.WARNING: do one level at a time.
Skipping levels risks ultimate failure.
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 33
Possible Exam Question
Describe the essential characteristics of each level in Humphrey’s five-level scale of software process maturity.
Note: you must read the Humphrey book to answer properly. The class notes only cover the highlights. This question will not be on
the exam. But you ought to know the answer.
Note: you must read the Humphrey book to answer properly. The class notes only cover the highlights. This question will not be on
the exam. But you ought to know the answer.
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 34
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.
Ultimately, the only reason most companies strive to improve is that they must do so to
survive.
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 35
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
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 36
The SEI Software Capability Maturity Model (CMM)
This was an effort by the SEI to flesh out the Humphrey model with best practices from the software development community
There were two releases:
– 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)
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 37
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
– It is not clear whether it represents a significant improvement
– But it does require more work to comply with the model
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 38
CMM CMMI
After the CMM, the SEI sponsored development of other CMM models, such as the People CMM, acquisition CMM, systems engineering CMM, and Integrated Product Development CMM.
In 1998 the SEI began work on a new model called the CMMI, which integrated these models into a more comprehensive model
The CMMI was released in 2001
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 39
Sunsetting of the CMM
The software CMM was "sunsetted" (no longer supported) as of 2003
Software organizations were urged to adopt the software portion of the CMMI, which is being maintained and updated to reflect current best practices
CMM is still used but no longer supported or current
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 40
The CMMI (CMM Integrated)
Integrated CMM models for software, systems engineering and various other disciplines involved in effective project management
Available in several variants
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 41
CMMI Concept
Software and Systems
Engineering (Core of Model)
Complete CMMI Model
Integrated Product
Development Model
Supplier Selection
Model
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 42
Further Information on CMM/CMMI
Information available at:
http://www.sei.cmu.edu
Search for CMM or CMMI
Current information on CMMI available at:
http://www.sei.cmu.edu/cmmi/
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 43
Why The SEI CMM/CMMI? (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)
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 44
Why Develop Such a Model
To help organizations achieve a more capable product development organization
The basic problem is that most organizations are immature in their development practices, and this leads to expensive, unreliable products
SEI was created to help industry extract itself from this condition, initially with software development but later with other aspects of product development
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 45
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)
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 46
What are the Characteristics of a Mature Organization?
“... a mature … organization possesses an organization-wide ability for managing … development and maintenance processes.
“The [development] 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.
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 47
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.
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 48
Basic Terms
The process capability of an organization provides one means of predicting the most likely outcomes to be expected from the next project the organization undertakes
With a capable organization, you have higher confidence that the outcome will be as predicted
Process capability describes the range of expected results that can be
achieved by following a process.
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 49
Basic Terms
Thus, process performance focuses on the results achieved, while process capability focuses on results expected.
Recall that you need a good process model (capability) and good execution (performance) to have a good process
Process performance represents the actual results achieved by following a
process.
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 50
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.”
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 51
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.
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.
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 52
Process Maturity
Maturity implies a potential for growth in capability and indicates both the richness of an organization's processes and the consistency with which they are applied in projects throughout the organization.
Process maturity is the extent to which a specific process is explicitly defined, managed, measured, controlled, and
effective.
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 53
Possible Exam Question
Explain the difference between process maturity, process capability, and process performance
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 54
Module Summary
Maturity models attempt to represent the potential of an organization to be effective at software development
The SEI CMM and CMMI are attempts to add specific practices and best practices to the Humphrey model
Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M35 - Version 9.01 55
END OF
MODULE 35