copyright 1995-2009, dennis j. frailey cse7315 – software project management cse7315 m35 - version...

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)


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


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


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


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


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!


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


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!


Don’t Punish or Blame the Practitioners

David, this disaster isall your fault!

I’ll show you!

David is likely to be: -- defensive -- uncooperative


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.


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.


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


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


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.


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


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.


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


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


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


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?


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


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


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


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


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.


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”


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.


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”


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


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


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.



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.


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.


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


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)


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


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


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


The CMMI (CMM Integrated)

Integrated CMM models for software, systems engineering and various other disciplines involved in effective project management

Available in several variants


CMMI Concept

Software and Systems

Engineering (Core of Model)

Complete CMMI Model

Integrated Product

Development Model

Supplier Selection

Model


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/


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)


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


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)


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.


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.


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.


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.


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


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.


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.



Explain the difference between process maturity, process capability, and process performance


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


END OF

MODULE 35

copyright 1995-2009, dennis j. frailey cse7315 – software project management cse7315 m35 - version...

Documents

software processes

software project module

software development

care of software

software development

process measure

reliable manner slide

basis of reliable techniques