"Finding and fixing a software problem after delivery is 100 times more expensive than finding and fixing it during the requirements and early design phases."

--Barry Boehm

Track Defects Against Quality Targets

In an ideal situation, defects would never be created. Unfortunately, this flies in the face of human nature. Defects are inevitable. Our record in software development certainly bears this out. But as we move into an age where software affects virtually every aspect of our lives, increasingly making its presence felt in safety-critical systems, defective software is unacceptable.

The situation gets worse as defects go undetected and remain in a system. Not only does it become more expensive to repair these individual defects the later they are identified, but the longer they remain, the more they cause other errors. Defects often grow exponentially with the evolution of the software's development as later products are built based upon a defective platform. 

For these reasons, we need to acknowledge that defects will creep in and to organize a project so that defects are identified and corrected as soon as possible after these errors are created. "Defect tracking against quality targets" is the practice that focuses management attention on this approach.

Intimately intertwined with this practice is the definition of software "quality." Like beauty, quality is often subject to interpretation. The prudent software manager will turn to the role the software product will play in the overall system. Systems questions such as these must be answered:

• What are the reliability requirements? 
• What is the impact of a software failure? 
• What are the performance requirements? 
• Are all features equally important? 
• How long is the software expected to remain in the inventory? 

Once the mission requirements for software quality have been determined, these requirements need to be translated into observable and measurable software characteristics of the product. A defect is defined then as an instance where the product does not meet a specified characteristic. Each type of defect (requirements definition, detailed design, code, integration, document creation, debug/rework) has its own characteristics. A requirements definition defect is most costly if not found quickly. These defects fall into two major categories: errors of omission and errors of commission. Errors of omission are often not detected until operational testing begins and can be extremely difficult to correct. The least costly defect to correct is the true "bug"; that is, a simple code error, a typo. 

Defects should be tracked formally at each project phase or activity. Configuration Management (CM) enables each defect to be recorded and traced through to removal. Data should be collected on effectiveness of methods used to discover defects and to correct the defects. In this approach, there is no such thing as a private defect; that is, one detected and removed without being recorded. Through defect tracking, an organization can characterize their error propensity and then focus their resources appropriately.

top

---