THE PROCESS CAPABILITY BASELINE

2.2 THE PROCESS CAPABILITY BASELINE

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

         Productivity

         Schedule

         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	Parameter	Remarks	General Baseline, Development Projects
1	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)
2	Productivity	For Third-Generation Languages	4 31 FP/person-month (avg: 12)
		For Fourth-Generation Languages	10 129 FP/person-month (avg: 50)
3	Schedule Adherence		81% of projects delivered within 10% of the agreed schedule
4	Effort
4.1	Build Effort	Build effort for a medium program	Min Mean Max 2 4 6 person days
4.2	Effort Distribution		Min Mean Max
		Req. Analysis + Design	1 15 29%
		Build (Code + Code review + UT)	22 41 60%
		Coding	14 33 52%
		Review	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%
		Training	1 7 14%
		Others	1 10 26%
5	Defects
5.1	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)
5.2	Defect injection distribution	Requirements and Design	Approx. 30%
		Coding	Approx. 70%
5.3	In-process Defect Removal Efficiency	For the entire life cycle	78 100% (avg: 94%)
6	Cost of Quality	(Review effort + rework effort + test effort + training effort) as a percentage of total effort	32%
7	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%