Search

In manufacturing, agriculture and transportation, inspections are a routine part of business, making our lives safer and more comfortable. Yet in software, we generally leave inspections to companies that are quite advanced in their process maturity. Why do most companies skip inspections when their is so much to gain? In 1991, the author began the National Software Quality Experiment, an ongoing database of software defects and inspections practice. In his study, participants from dozens of organizations described defects and these were entered into the experiment's database. In this article, the author makes a case for implementing inspections at all levels of software development practice, based on what he has learned thus far.

Do you use software peer reviews? Are you happy with your current code review practices? Even though formal inspection is recognized as one of the most effective ways to improve software quality, many software organizations struggle to effectively implement a formal inspection regime. Open source projects use an agile peer review process-based on asynchronous, frequent, incremental reviews that are carried out by invested codevelopers-that contrasts with heavyweight inspection processes. The authors describe lessons from the OSS process that transfer to proprietary software development. They also present a selection of popular tools that support lightweight, collaborative, code review processes and nonintrusive metric collection.

To control projects, managers need accurate and timely feedback on the quality of the software product being developed. I propose subjective team estimation models calculated from individual estimates and investigate the accuracy of defect estimation models based on inspection data.

Inspections are among the most mature and best-studied practices in software engineering. People, especially when they bring objective viewpoints, are among the most powerful tools for finding problems in systems. The inspection process mitigates the fact that, although the human brain is powerful, relying on it has drawbacks. It is interesting to look at how such a practice catches on among busy professionals.

Software inspections are considered a cheap and effective way to detect and remove defects from software. Still, many people believe that the process can be improved and have thus proposed alternative methods. We reviewed many of these proposals and detected a disturbing pattern: too often competing methods are based on conflicting arguments. The existence of these competing views indicates a serious problem: we have yet to identify the fundamental drivers of inspection costs and benefits. We first built a taxonomy of the potential drivers of inspection costs and benefits. Then we conducted a family of experiments to evaluate their effects. We chose effort and interval, measured as calendar time to completion, as our primary measures of cost. Defects discovered per thousand lines of code served as our primary measure of inspection benefits.

Inspection data is difficult to gather and interpret. At ATT average lines of code inspected; average preparation rate; average inspection rate; average effort per KLOC; average effort per fault detected; average faults detected per KLOC; percentage of reinspections; defect-removal efficiency. >

The use of code inspection to detect errors in ultralarge software projects is discussed. In particular, quantitative results based on a 1988 study of inspection of 2.5 million lines of high-level code at Bell-Northern Research are presented. The data represent one of the largest published studies in the industry and confirm that code inspection is still one of the most efficient ways to remove software defects. How to introduce inspections in large-scale production environments successfully is described. >