Any quantitative control of a project depends critically on the measurements made during the project. To perform measurements during project execution, you must plan carefully regarding what to measure, when to measure, and how to measure. Hence, measurement planning is a key element in project planning. This section discusses the way standard measurements are done in projects at Infosys. Project managers may add to these measurements if their projects require it.

7.2.1 Collecting Effort Data

To help a project manager monitor the effort, each employee records in a weekly activity report (WAR) system the effort spent on various tasks. This online system, developed in-house, stores all submitted WARs in a centralized database. Each person submits his WAR each week. On submission, the report goes to the individual's supervisor for approval. Once it is approved, the WAR submission is final and cannot be changed. Everyone submits a WAR, including the CEO, and if a WAR is not submitted within a given time period, leave is deducted.

A WAR entry consists of a sequence of records, one for each week. Each record is a list of items, with each item containing the following fields:

         Program code

         Module code

         Activity code

         Activity description

         Hours for Monday through Sunday

The activity code characterizes the type of activity. The program code and module code permit separation of effort data with respect to modules or programs, a consideration that is important for component-level monitoring. To support analysis and project comparisons, it is important to standardize the activities against which effort is reported. Having a standardized set of activity codes helps to achieve this goal. Table 7.1 shows the activity codes used in Infosys projects. (These are different from the ones given in my earlier book because the codes were changed with the introduction with a new Web-based WAR system.)

In the activity codes, a separate code for rework effort is provided for many phases. This classification helps in computing the cost of quality. With this level of refinement, you can carry out a phase-wise analysis or a subphase-wise analysis of the effort data. The program code and module code, which are specified by the project, can be used to record effort data for different units in the project, thereby facilitating unit-wise analysis.

To facilitate project-level analysis of planned versus actual effort spent, the WAR system is connected to the Microsoft Project (MSP) depiction of the project. Project staff can begin submitting WARs for a project only after the MSP for the project has been submitted (once the MSP is submitted, the system knows which people are supposed to be working on the project). Planned activities are defined as those listed in the MSP and assigned to an authorized person in the project. Unplanned activities are all other project activities.

When entering the WAR for a week, the user works with a screen that is divided into two sections: planned activities and unplanned activities. All activities that are assigned in the MSP to a particular person for this week show up in her planned activities section for that project. The user cannot add or modify activities that show up in this section. She can enter only the hours spent each day for the different activities provided. To log the time spent on activities not listed in the planned section, the user can enter a code, its description, and the hours spent each day on these activities in the unplanned section for the project.

7.2.2 Logging and Tracking Defects

In an Infosys project, defect detection and removal proceed as follows. A defect is found and recorded by a submitter. The defect is then in the state "submitted." Next, the project manager assigns the job of fixing the defect to someone, usually the author of the document or code in which the defect was found. This person does the debugging and fixes the reported defect, and the defect then enters the "fixed" state. A defect that is fixed is still not closed. Another person, typically the submitter, verifies that the defect has been fixed. After this verification, the defect can be marked "closed." In other words, the general life cycle of a defect has three states: submitted, fixed, and closed (see Figure 7.2). A defect that is not closed is also called open.

Figure 7.2. Life cycle of a defect


Table 7.1. Activity Codes for Effort

Activity Code





Rework after acceptance testing


Project catch-all


Coding and self unit testing


Code walkthrough/review


Rework after code walkthrough


Configuration management




Customer support activities


Database administration activities


Detailed design


Detailed design review


Rework after detailed design review




Review of models and drawings


Rework of models and drawings


Execution of modeling and drafting


High-level design


High-level design reviews


Rework after high-level design review


Impact analysis


Installation/customer training


Integration testing


Rework after integration testing


Project initiation


Project closure activities


Project planning and tracking


Research on technical problems


Requirement specification activities


Review of requirements specifications


Rework after requirements review


Strategic planning activities


System testing


Rework after system testing


Project-specific trainee activities


Independent unit testing


Rework after independent unit testing


Waiting for resources


Effort during warranty

A defect control system (DCS) is used in projects for logging and tracking defects. The system permits various types of analysis. Table 7.2 shows the information that is recorded for each defect logged in to the system.

To determine the defect injection stage requires analysis of the defect. Whereas defect detection stages consist of the review and testing activities, defect injection stages include the stages that produce work products, such as design and coding. Based on the nature of the defect, some judgments can be made about when it might have been introduced. Unlike the defect detection stage, which is known with certainty, the defect injection stage is more ambiguous; it is estimated from the nature of the defect and other related information. Using stage injected and stage detected information, you can compute the defect removal efficiencies, percentage distributions, and other metrics.

Sometimes it is desirable to understand the nature of defects without reference to stages, but rather in terms of the defect category. Such a classification can help you to understand the distribution of defects across categories. For this reason, the type of defect is also recorded. Table 7.3 shows the types of defects possible, along with some examples. A project can also define its own type classification.

Table 7.2. Recording Defect Data




Project code

Code of the project for which defects are captured



Description of the defect


Module code

Module code


Program name

Name of program in which the defect was found


Stage detected

Stage in which the defect was detected


Stage injected

Stage at which the defect was injected/origin of defect



Classification of the defect



Severity of the defect


Review type

Type of review



Current status of the defect



Name of the person who detected the defect



Name of the person who owns the defect


Submit date

Date on which the defect was submitted to the owner


Close date

Date on which the submitted defect was closed


Finally, the severity of the defect is recorded. This information is important for the project manager. For example, if a defect is severe, you will likely schedule it so that it gets fixed soon. Also, you might decide that minor or unimportant defects need not be fixed for an urgent delivery. Table 7.4 shows the classification used at Infosys.

From this information, various analyses are possible. For example, you can break down the defects with respect to type, severity, or module; plot trends of open and closed defects with respect to modules, severity, or total defects; determine the weekly defect injection rate; determine defect removal efficiency; determine defect injection rates in different phases, and so on. In Chapter 11 you will see some uses of this data for monitoring the quality dimension and for preventing defects. That chapter also describes an example of the defect data entered in the case study.

Table 7.3. Defect Types

Defect Type



Insufficient/incorrect errors in algorithms used; wrong conditions, test cases, or design documents


Problems with coding/documentation standards such as indentation, alignment, layout, modularity, comments, hard-coding, and misspelling

Redundant code

Same piece of code used in many programs or in the same program

User interface

Specified function keys not working; improper menu navigation


Poor processing speed; system crash because of file size; memory problems


Inability to reuse the code

Design issue

Specific design-related matters

Memory management defects

Defects such as core dump, array overflow, illegal function call, system hangs, or memory overflow

Document defects

Defects found while reviewing documents such as the project plan, configuration management plan, or specifications


Failure to updating or delete records in the same order throughout the system


Lack of traceability of program source to specifications


Code not independent of the platform


Table 7.4. Defect Severity

Severity Type

Explanation for Categorization


Defect may be very critical in terms of affecting the schedule, or it may be a showstopper that is, it stops the user from using the system further.


The same type of defect has occurred in many programs or modules. We need to correct everything. For example, coding standards are not followed in any program. Alternatively, the defect stops the user from proceeding in the normal way but a workaround exists.


This defect is isolated or does not stop the user from proceeding, but it causes inconvenience.


A defect that in no way affects the performance of the software product for example, esthetic issues and grammatical errors in messages.

7.2.3 Measuring Schedule

Measuring schedule is straightforward because you use calendar time. The detailed activities and the schedule are usually captured in the MSP schedule, so the estimated dates and duration of tasks are given in the MSP. Knowing the actual dates, you can easily determine the actual duration of a task.

7.2.4 Measuring Size

If the bottom-up estimation technique is used, size is estimated in terms of the number of programs of different complexities. Although this metric is useful for estimation, it does not permit a standard definition of productivity that can be meaningfully compared across projects. The same problem arises if lines of code (LOC) are used as a size measure; productivity differs with the programming language. To normalize and employ a uniform size measure for the purposes of creating a baseline and comparing performance, function points are used as the size measure.

The size of delivered software is usually measured in terms of LOC through the use of regular editors and line counters. This count is made when the project is completed and ready for delivery. From the size measure in LOC, as discussed before, size in function points is computed using published conversion tables.12


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: