"As practiced by IBM FSC, the formal inspection is the cornerstone of software verification and process improvement [at IBM FSC]. All software products must submit to and pass a formal inspection prior to acceptance into configuration control or submission for execution testing."
—IBM Federal Systems Company

Inspect Requirements and Design

Michael Fagan introduced the idea of formal inspections almost three decades ago in an effort to find a way to improve the software development process. While there have been improvements made over time, the formal inspections used today by a number of organizations are remarkably similar to those proposed by Fagan.

Formal inspections are based on a simple approach to dealing with problems that naturally arise in software development. As described by Fagan and expanded upon by others, inspections are an organized, systematic way of reviewing development artifacts to determine if mistakes have been made. While this review process could be treated in a more casual manner, evidence shows that the structure of the Fagan inspection yields better results.

A formal (Fagan-type) inspection is accomplished by a team of reviewers. Each member is provided with the material to be inspected and a checklist of features the artifact should have. The members review their products independently and then come back as a team to discuss their findings. The model put together by Fagan called for certain team members to play specific roles. There should be a chairperson, who moderates the meeting; a recorder, who documents the discussion and results; and a reader, who walks the team through the product. Rules of conduct also exist, such as everyone arrives at the meeting prepared, management is not included, and meetings are less than two hours in length.

The focus of the inspection is to determine if the artifact meets the standards and criteria established for it. Defects are defined as a case where the artifact does not comply with a guideline. Defects are categorized according to the impact they would have on the product under consideration. Defects are tracked to closure to make sure the product is corrected.

The inspection typically ends with one of three situations:

• Accept the artifact as is, allowing it to be used for future work
• Accept the artifact conditionally, allowing it to be used for future work, but requiring that it be corrected.
• Reject the artifact.

Statistics are kept on the process, allowing management to determine whether the development process should be improved, if it has changed, or if the inspection steps are worthwhile.

Inspections can be a significant drain on a project's resources. Inspections have been shown to increase the cost of a particular step as much as 15 to 20 percent. The payoff, however, comes from the reduced rework that comes from building the product "right" the first time. Even though inspections may return only a small number of defects in any given review, fixing these defects early can cost as little as one-thousandth as much as it would be fix them during final integration stages.

Inspections are not perfect. They are, after all, human endeavors. Well run inspections can find as many as 80 percent of the existing errors.

Inspections can be applied to any artifact of the development process. However, because of the high return on investment inspections have proven to have, they benefit the organization the most when applied to the requirements and design stages. Eliminating defects early in a program creates a far more stable platform on which to build the rest of the system.

The very process of installing inspections has substantial benefit for the program. First, it causes the organization to identify what features a unit should have. Second involvement by the development staff helps clarify how they should interpret guidelines

Inspections stand out as an anomaly. They have been repeatedly shown to reduce errors in the software development process, yet they are frequently not applied. We need to change the way we build software!

top

---