Lecture Software process improvement: Lesson 18A - Dr. Ghulam Ahmad Farrukh

Lecture Software process improvement: Lesson 18A provide students with knowledge about: CMMI staged – maturity level 4; the maturity levels; process areas of level 4 (quantitatively managed); organizational process performance; quantitative project management;... Please refer to the detailed content of the lecture!

1 1

CMMI Staged – Maturity Level 4

Lecture # 18­A

2 2

Staged Representation

• The staged representation is the approach used in  the Software CMM. It is an approach that uses 

Following slide to be inserted

The Maturity Levels

3

• At Level 4, the organization has achieved all of the goals of Levels 2 and 3

5

Level 4

• Processes, although qualitatively stable and  predictable  at Level 3, can be proved to be 

Level 4

6

Level 4

• To get “good” data, an organization usually has to collect data for several years, or at 

least through several projects and several 

life cycles of the projects. And when you 

first begin collecting data, they will not be consistent data

8

Level 4

• Measurement data are collected beginning with 

Level 2 in the staged representation, and in most  organizations, actually begin being collected at 

Level 1. The problem is the data are not clean and  consistent because the processes used on the 

projects (where the data are collected and used)  are not yet stable and consistent. Data in and of 

themselves are not magical. They simply reflect  what is going on in the projects

•  The point is, an organization cannot go to Level 4 

Level 4

• What problems do we see in organizations when they decide to move from Level 3 to Level 4?

Level 4

• At Level 4, the control limits are based on years of historical data and trends analyses done on those data. More data are collected, and, therefore, more limits are established, monitored, and refined as necessary

11

12

13

Following slide to be inserted

Process Areas of Level 4(Quantitatively Managed)

14

• At level 4, there are no additions to the list 

of generic goals at Level 4 from Level 3. 

What makes this maturity level different are the two process areas

• GG2 Institutionalize a Managed Process

• GG3 Institutionalize a Defined Process

16

• To satisfy the goals for Level 4, the goals for Levels 2 and 3 must be satisfied as well. This mandate holds true for both the 

specific goals and the generic goals

17

19

Specific Goal for Level 4

• SG1 Establish Performance Baselines and Models

20

SG1 Establish Performance  Baselines and Models – Specific 

Process Area

• This process area includes measurements for both process and product. Additionally, service has also been specifically presented 

as an area appropriate for measurement. 

This process area combines these measures 

to determine both the quality of the process and the product in quantitative terms

22

Process Performance Baselines

• Process performance baselines and process performance models are included in goals for this process area

Process Performance Model

• A process performance model (PPM) 

describes the relationships among attributes (for example, defects) of a process and its work products

• A PPM is used to estimate or predict a 

critical value that cannot be measured until later in the project’s life—for example, 

predicting the number of delivered defects 

Process Area

• The most common measurements in use for this process area are size, effort, cost, 

schedule, and product defect density

• The measurements for these data points are usually displayed in ranges and not by 

absolute points

26

• Performance­related measurements can 

include schedule variance (lateness), effort variance, and unplanned tasks

• Quality­related measurements may include rework and defects. These defects can be 

collected during all life­cycle phases, 

including requirements inspections, design inspections, code inspections, unit testing, integration testing, and system testing 27

28

Process Area

• This process area covers both project­level and organization­level activities. Selecting processes to measure and selecting 

appropriate measures themselves can be 

iterative to meet changing business needs. Establishing quality and process objectives can be iterative as well, based on fixing 

special causes of variation

30

• Measurements should be tied to business objectives of the  organization. So, if you are highly driven by time­to­

Things People Forget ­ 1

• The organization either builds too many 

models or not enough. This approach is the same approach we see when trying to select appropriate measures to collect at Level 2 and in trying to write effective process 

documentation when beginning the process improvement effort

32

“by the numbers”); and generating process 

Quantitative Project Management

PA 2

35

36

SG2 Statistically Manage Sub­ process Performance – Specific 

• SP 2.4 Record Statistical Management Data

39

Process Area

• In this process area, usage of the organizational  level measurement repository is refined. This 

• Training for each role needs to be addressed

41

• Project managers should do at least a 

weekly review of the project measures and how they are being used. This information 

is usually communicated to senior 

management

• A measurement group is usually needed to support measurement activities. Collection 

of data is easier if automated tools are used

42

• There can be several organizational 

measurement repositories, or layers within one overall repository, so as to not mix data that may lead to misleading numbers and 

bad decisions. Repositories require years of historical data using the same, normalized data, and reviews and analyses of these 

data. Training and practice in this effort 

need to occur. Running projects 

quantitatively is not an overnight transition 43

Things People Forget ­ 1

• Make sure the project manager (or whoever will actually use these data to manage the project) is involved in determining which measures he will need

• Train the people collecting the data and the people who will use the data

44

Quantitative Project Management

• Quantitative Project Management includes 

quantitatively defining project objectives; using  stable and consistent historical data to construct  the project’s defined process; selecting sub­

processes of the project’s defined process that will 

be statistically managed; monitoring the project  against the quantitative measures and objectives;  using analytical techniques to derive and 

understand variation; and monitoring performance  and recording measurement data in the 

organization’s measurement repository 46

• Level 4 is where senior management commitment and  participation really come to the fore. Business 

decisions are supposed to be made based on the 

numbers

• Have you ever sat in any senior­ and executive­level  meetings? You are lucky if you get ten minutes with  these people. And they are not overly fond of viewing  slide after slide of esoteric charts and graphs. They 

want to know the bottom line—are we making 

money? And the one chart that they all love, which is  not particularly popular in the world of statistics is the 

• Most small organizations will find this level very difficult to implement as written, based 

on the number of people needed to make 

this run smoothly and based on the type of expertise needed. And this level may not 

prove all that beneficial (using cost­benefit analyses) to these organizations anyway

48

Summary

49

References

• Interpreting the CMMI: A Process 

Improvement Approach, Second Edition, by Margaret K. Kulpa and Kent A. Johnson, 

Auerbach Publication, 2008 (electronic 

file), (Chapter 7)

50