A useful tool for visualising software process improvement, fault grids, or defect grids, are a simple way of portraying the effectiveness of a product development process in terms of how soon faults are discovered in the product, a key factor in reducing the cost of rework.

Fault Grids

By Jeremy Dick.

Last updated: 5 Nov 2002

It is evident that the cost of rectifying a fault increases hugely the longer it goes undetected. The goal of any effective process must be to discover defects in the early stages of development, i.e. in the requirements definition or specification stages, while the cost of fixing the problem remains small. Minimising the amount of costly rework can reduce the overall cost of development.

Fault Grids, or Defect Grids, are a simple way of portraying the effectiveness of a product development process in terms of how soon faults are discovered in the product. The only data that is required to draw a Fault Grid is a register of faults recording:




On the right is an example of a Fault Grid. It shows the process steps down the left-hand side, labelling a "honey-comb" of data.

The honeycomb guides the eye in three directions through the cells. Each cell aligns which two process steps: the one in which the fault was discovered, and the one in which it was introduced.

For instance, the 2 at the top represents 2 faults discovered during the "Specification" step that were introduced during the "Requirements" step. The 1 diagonally below that represents a fault discovered in during the "Design" step that was introduced during "Requirements", and so forth.

The eye is also drawn vertically downwards to the totals at the bottom. In this example, there were 13 faults discovered after just one process step, 5 discovered after 2 steps, and so on. This is a summary of the effectiveness of the process.

Example of a fault grid

Obviously, the most worrying faults are those that are portrayed in the extreme right of the fault grid. These are those have taken the longest to discover, require the most costly rework, and are thus the most expensive to correct. The goal of the process must be to discover those faults earlier.

Here is a fault grid drawn from real project data. It was the development of part of CICS at IBM Hursley.

Fault grid for a CICS project

The process involved formal specification and code generation for a prototype in the C language, followed by a redesign in PL/X, the target programming language for the project.

The patterns on the grid speak volumes about the effectiveness of the process. Note the following:



The above examples are screen-shots taken from a tool developed as add-ins to DOORS, the requirements management tool.

The tool runs from the menu of a "Fault Register" module, in which all faults are listed and classified according to where in the process each was discovered and introduced.

For details and availability, email jeremy.dick @ integrate.biz