Whereas the PDB contains data for each project, the process capability baseline represents a snapshot of the capability of the process at some point in time in quantitative terms. The capability of a process is essentially the range of outcomes that can be expected by a project if the process is followed.5 The capability of a stable process can be determined from past performance of the process. If baselines are regularly established, trends in the process capability can easily be obtained a key reason for having a PCB.

The first issue that must be resolved is what the PCB should contain that is, what types of "outcomes" the PCB should include. The PCB at Infosys contains the process performance stated primarily in terms of productivity, quality, schedule, and effort and defect distributions. It specifies the following:

         Delivered quality



         Effort distribution

         Defect injection rate

         In-process defect removal efficiency

         Cost of quality

         Defect distribution

This information can be used in project planning. For example, a project manager can use productivity and the estimated size to estimate the effort for the project and can use the distribution of effort to predict the effort for various phases and to make staffing plans. Similarly, you can use the defect injection rate to predict the total number of defects and can use the distribution of defects to predict the defect levels for various defect detection activities. Overall defect removal efficiency or quality can be used to forecast the number of defects that may crop up after the software is delivered and to plan for maintenance.

The PCB also serves an important role in overall process management in the organization. For example, you can easily measure process improvements by analyzing the trends in the PCB over time. You can also improve the planning of improvement initiatives by using information on distribution of effort and defects, defect injection rates, removal efficiencies, and other measures.

Because a baseline indicates the capability of a process, you must create a separate baseline for each process in the organization. At Infosys, separate processes are defined for maintenance, reengineering, and development projects; a separate baseline is therefore defined for each of these processes. Even these processes are too broad, however, and they provide only general guidelines. If projects of a certain type are executed frequently, a PCB for that type of project is created. This focused baseline gives a much tighter range, in terms of expected results, for that type of project.

The PCB given in Table 2.5 is applicable for development projects and for projects done in a third-generation language (3GL). The PCB for maintenance projects, for example, differs not only in terms of actual figures in the PCB but also in the information included (to suit the maintenance process). (The numbers used in this PCB have been sanitized to protect confidentiality.)

The interpretation of this PCB is straightforward. The PCB states that for development projects, the average productivity is about 12 function points per person-month, with the range being from 4 to 31 function points. The average quality of these projects is 0.02 defects per function point, with the range being between 0.00 and 0.094. The PCB also gives the average and range for other parameters, such as defect injection rate and total defect removal efficiency. Overall defect injection rate is given with respect to size as well as effort, so effort as well as size estimates can be used for estimating defects. The cost of quality includes the cost of all activities that help prevent or remove defects. For effort, defect, and defect injection rates, it also specifies a distribution among the various stages.

Table 2.5. Process Capability Baseline for Development Process

Sequence Number



General Baseline, Development Projects


Delivered Quality

Delivered Defects /FP (Delivered Defects = Acceptance Defects + Warranty Defects)

0.00 0.094 Delivered Defects/FP (avg: 0.021)



Quality expressed in terms of effort

0.00 0.012 Delivered Defects/Person-hour (avg: 0.003)



For Third-Generation Languages

4 31 FP/person-month (avg: 12)



For Fourth-Generation Languages

10 129 FP/person-month (avg: 50)


Schedule Adherence


81% of projects delivered within 10% of the agreed schedule






Build Effort

Build effort for a medium program

Min Mean Max

2 4 6 person days


Effort Distribution


Min Mean Max



Req. Analysis + Design

1 15 29%



Build (Code + Code review + UT)

22 41 60%




14 33 52%




1 4 11%



Unit Testing

1 5 14%



Integration Testing + System Testing

1 9 20%



Acceptance Testing & Warranty

1 8 23%



Project Mgmt + Config. Mgmt

1 10 20%




1 7 14%




1 10 26%






Defect Injection Rate

Overall LC defect injection rate in terms of size

0.02 1.12 Defects/FP (avg: 0.33)



Overall LC defect injection rate in terms of effort

0.00 0.1516 Defects/person-hour (avg: 0.052)



Defect injection rate in the coding phase (in terms of effort)

0.02 0.57 Defects/person-hour (avg: 0.155)


Defect injection distribution

Requirements and Design

Approx. 30%




Approx. 70%


In-process Defect Removal Efficiency

For the entire life cycle

78 100% (avg: 94%)


Cost of Quality

(Review effort + rework effort + test effort + training effort) as a percentage of total effort



Defect Detection Distribution

% of Total Defects Min Mean Max




Req. Spec Review + HLD Review + Detail Design Review

2 13 20%



Code review + Unit Testing

21 53 83%



Integration Testing + System Testing

3 28 56%



Acceptance Testing

1 6 17%


Software Project Management in Practice
Linux Annoyances for Geeks: Getting the Most Flexible System in the World Just the Way You Want It
ISBN: 0596008015
EAN: 2147483647
Year: 2005
Pages: 83
Authors: Michael Jang

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: