Inspections

This portion of the Waysys web-site is devoted to describing an approach to software inspections. Inspections are a method of identifying and eliminating defects in software development documents like requirements, design, and meta data. This site documents the processes and rules for performing inspections. It also provides templates for some of the forms used during inspections.

Inspections are recommended for:

• requirements
• test cases
• designs
• meta data
• other project documentation

Waysys does not recommend inspecting code, because other techniques like test driven development and paired programming can be more effective. Agile inspection is recommended for requirements and designs. Many new systems are metadata driven. Inspections of metadata can be an excellent application of agile inspections.

The procedure described here is based on Tom Gilb's Agile Specification Quality Control. This approach differs from traditional inspections. Traditionally, the goal of inspections is to find all defects in a document or other deliverable. Metrics on inspections generally indicated that they saved money. Almost all software process experts acknowledge that inspections are useful, but almost no one does them. One reason is that inspections often involve a great deal of time by developers, exactly the people who have the least amount of time during the development portion of the project.

Agile inspection has a different focus. The goal of agile inspection is to measure the level of defects in a document. Agile inspection uses a sampling approach, instead of reviewing the complete document. It involves only two or three people, versus five to seven usually recommended for traditional inspections. The time commitment per inspection is usually about one to one and a half hours per person. Therefore, there is much less impact on development time.

The results of agile inspections can provide stakeholders with information about the quality of deliverables. However, it should never be used as a tool for evaluating team members. Inspection participants should be drawn from the author's peers, not supervisors.

The procedure for agile inspections is located here.