cse 7315 - sw project management / module 35 - software process maturity copyright © 1995-2004,...

52
CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Slide 1 CSE7315M35 January 10, 2004 SMU CSE 7315 / NTU SE 584- N Planning and Managing a Software Project Module 35 Software Process Maturity

Upload: dorcas-poole

Post on 29-Jan-2016

222 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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

Page 2: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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)

Page 3: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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

Page 4: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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

Page 5: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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

Page 6: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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

Page 7: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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!

Page 8: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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

Page 9: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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!

Page 10: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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

Page 11: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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.

Page 12: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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.

Page 13: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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

Page 14: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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

Page 15: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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.

Page 16: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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

Page 17: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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.

Page 18: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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

Page 19: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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

Page 20: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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

Page 21: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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?

Page 22: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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

Page 23: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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?”

Page 24: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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

Page 25: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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

Page 26: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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.

Page 27: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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”

Page 28: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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.

Page 29: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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”

Page 30: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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

Page 31: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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

Page 32: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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.

Page 33: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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.

Page 34: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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.

Page 35: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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

Page 36: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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)

Page 37: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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

Page 38: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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

Page 39: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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

Page 40: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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)

Page 41: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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

Page 42: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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)

Page 43: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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.

Page 44: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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.

Page 45: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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.

Page 46: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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.

Page 47: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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.”

Page 48: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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.

Page 49: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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.

Page 50: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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

Page 51: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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

Page 52: CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

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