Software Defect Prevention in a Nutshell

Occurence of defects is the greatest contributor to significant increases in product cost due to correction and rework.
Many defects occur from process failures. Identifying and correcting process defects we prevent many product defects from recurring.
In general, DP activities are a mechanism for propagating the knowledge of lessons learned in a project.

The earlier we discover the faults the better. Late error discovery results in signifcant rework.

Features of Defect Prevention:

1. Written policy for defect prevention at organization and project level.
2. Group members should undergo training
3. Creation of an action plan plays a key role in implementation process. At the beginning of the task, the members of the team meet to prepare for the task and the related DP activties.
4.Periodic reviews are conducted by each of the teams assigned to coordinate DP activities. During the review, action items are identified and priorities set based on causal analysis that determines:

  - the causes of defects
  - the implications of not addressing the defects
  - the cost to implement process improvement to prevent the defects
  - the expected impact on software quality

5. A pareto analysis is helpful in setting priorities and provides direction for assignment of action items, making changes to activities and documenting rationale for decision.

Additional DP activities involve reviewing the results of defect prevention experiments  and taking actions to incorporate the result of successful experiences into rest of project or organization.

Data Documentation and Measurement

Defect prevention data are documented in a centralized repository and tracked across the DP teams , providing  details of the defects and resulting action plan proposed.

The status of action items are also documented along with.

The organization's activities for defect prevention are reviewed with senior management on a periodic basis to provide a basis of insight into software process activties at an appropriate level of abstraction and in a timely manner.

Taxonomy was used as a classification vehicle.

The Beizer Taxonomy included 10 major categories , each of which was divided into three levels , resulting in a 4 digit number specified unique defect. The ten categories are :

Planning
 Requirement and Features
Functionality
Structural Bugs
Design
Implementation
Integration
Real-time and OS
Test definition and execution bugs
Other