HCL Technologies
A Stitch in Time Saves Nine – Economics of defect prevention
A Stitch in Time Saves Nine – Economics of defect prevention
Abstract
Do you think ‘high quality’ means more money and more time? Many organizations think so. In a way it is true for the simple fact that one half of most software development project budgets and two thirds of the typical development team’s time are spent fixing poor quality or software defects. A study conducted by National Institute of Standards and Technology (NIST) reports that software defects cost the U.S. economy $59.5 billion annually. Caper Jones in his 2001 IEEE paper, “Measuring Software Process Improvement,” gave a hope to software executives around the world by revealing that software process improvement leads to 80% reduction in post-release defects and a 65% increase in productivity, while reducing project schedules and costs by 20%. This paper highlights the need for an early detection of defects, its impact on the business & also emphasizes on the cost of fixing a defect.
Excerpts from the Paper
Not all defects in the software development are caused by coding errors. Some examples of defects coming upstream in the software development lifecycle (SDLC) are defects due to misunderstanding of requirements, contradicting requirements, missing requirements, wrong analysis of requirements, incomplete requirements and more importantly unable to identify non-functional requirements such as testability, scalability, maintainability, usability, performance etc.
A programmer makes a mistake, which results in a defect in the software source code. If this defect is executed, in certain situations the system will produce false results, causing a failure. However all defects will not necessarily result in failures. For example, defects in dead code will never result in failures. A defect can turn into a failure when the environment is changed. For example, software being run on a new hardware platform, changes in source data or interacting with different software. A single defect may result in a wide range of failure symptoms.
A programmer makes a mistake, which results in a defect in the software source code. If this defect is executed, in certain situations the system will produce false results, causing a failure. However all defects will not necessarily result in failures. For example, defects in dead code will never result in failures. A defect can turn into a failure when the environment is changed. For example, software being run on a new hardware platform, changes in source data or interacting with different software. A single defect may result in a wide range of failure symptoms.
It takes courage and commitment to make a ‘Zero defect’ policy. But with focused effort one can certainly commit to achieving minimal defects and reduce the cost associated with them. Product managers can absolve themselves from the dilemma of whether we need to do one more round of testing. Defect prevention simplifies the test cycles, reduces overall cost and improves product quality.