Inspections and walkthroughs

Inspections and walkthroughs

23.1 Purpose

An inspection is a formal review of a set of documentation conducted by technical personnel. The intent is to determine the technical accuracy of the documentation. When a set of documentation passes an inspection, it is reasonable to assume that the work is both technically acceptable and consistent with the system’s objectives. An inspection often marks the completion of a stage or activity in a larger project. In some companies, an inspection is a prerequisite to a management review.

A walkthrough is an informal inspection. Although valuable at any stage in the system development life cycle, walkthroughs are particularly useful during the implementation stage as a means of checking the accuracy of the code.

23.2 Strengths, weaknesses, and limitations

Because an inspection is a formal review of the exit criteria conducted by technical personnel, it is an excellent quality control tool. Passing an inspection can be viewed as an event that marks completion of a life cycle phase or an activity.

The formal nature of the process puts pressure on both the creators and the inspectors. Meeting objectives “to the letter” does not necessary guarantee quality, particularly when requirements and/or technology change. An inspection is performed by human beings, and people sometimes find it difficult to maintain objectivity.

Excessive management involvement can blunt the effectiveness of the inspection process. A manager’s comments tend to take on added significance simply because they come from a manager. Misusing the error reports generated during the inspection session is a particularly significant problem. People naturally fear that an error report will in some way be used against them and that error rates will eventually creep into personnel evaluations.

A walkthrough is, in effect, a “dry run” inspection without the formality. Consequently, walkthroughs provide many of the benefits with few of the problems. However, because they lack formality, walkthroughs cannot serve as dependable quality control mechanisms.

Inspections and walkthroughs are time consuming and, as is the case with any product, it is impossible to inspect quality into a set of documentation.

23.3 Inputs and related ideas

Inspections and walkthroughs can be conducted on the exit criteria from virtually any stage or any activity in the system development life cycle. Inspections are sometimes used as a part of the testing process (Chapter 74) and to support certain system controls (Chapter 77).

23.4 Concepts

An inspection is conducted by a team consisting of technical personnel and/or skilled-users. An inspection team normally consists of four individuals: the moderator, the author, and two inspectors.

23.4.1 The inspection team

The moderator runs the inspection, scheduling all meetings, distributing all necessary documentation, conducting all sessions, and making certain that the inspection is both thorough and fair. The ideal moderator enjoys the respect of his or her technical peers and is unbiased, with no direct involvement in the project. Without management’s authority, the moderator must perform several management-like functions, so management’s support is essential.

The author is usually the person (or the project leader) who prepared the documentation being inspected. The author’s primary responsibility is to answer technical questions and to avoid defending the work.

The inspectors are technical professionals or skilled users who, while not directly involved in preparing the documentation, have a stake in the outcome; e.g., the individual responsible for the previous step or a member of the group that will perform a subsequent step. Normally, two inspectors are assigned, but the team can be larger or smaller.

23.4.2 The inspection process

As soon as the documentation for a given step is completed, the author contacts the moderator and asks that the inspection process begin. The steps in the inspection process are summarized in Figure 23.1.

23.4.2.1 Planning

The first task is to select an inspection team. In many organizations, the moderator selects the team; in others, management assumes this responsibility. Once the team has been named, the moderator distributes all relevant documentation and schedules the inspection meeting or meetings.

23.4.2.2 Overview

If a project is particularly extensive or involves a number of concepts or techniques that are not apparent to the inspectors, the author might be asked to present a brief technical overview of the project and the documentation. Note that the overview is optional.

The objective of the overview session is to save the moderator and the inspectors some time. The author’s presentation should stick to the facts, stressing what and how, not why. Only later, after the other members of the team have had an opportunity to review and understand the documentation, should the reasons behind the technical decisions be considered.

23.4.2.3 Preparation

The preparation step calls for individual work on the part of each of the participants. The moderator and the inspectors read the documentation and note any questions or potential problems. In some organizations, contact between the inspectors and the author during the preparation step is officially prohibited, but such rules are difficult to enforce. At the very least the participants should be aware of the potential for bias, and should avoid non-essential contact with the author.

Figure 23.1  The steps in the inspection process.

23.4.2.4 The inspection session

The moderator conducts the inspection session. One of the inspectors (not the author) serves as the reader and reads aloud or paraphrases the documentation. During the inspection session, the author’s primary responsibility is to answer technical questions and to avoid defending his or her work.

The inspection session should be limited to perhaps 90 min, and all participants should be aware of the time limit. The objective is to find errors. All participants, including the moderator, the author, and the reader, are encouraged to identify errors. Note, however, that the inspection team should not suggest corrections. That is the author’s job.

During the inspection session, the moderator maintains an error log, noting each error and estimating its severity (trivial, moderate, significant, severe, or fatal). Estimating the severity of errors is a common point of contention. The author may see an error as trivial, while an inspector may consider it severe. The result could well be a protracted argument. After a reasonable discussion, the moderator must break in, arbitrarily assign a severity level to the error, and move on. The important thing is that the error be detected; its classification is secondary.

Several problems can occur during the inspection session. Rather than inspecting the work, the author might act as a proponent or defender and attempt to discredit the errors identified by the other committee members. One or more inspectors might conduct a “witch hunt” rather than an inspection. An individual inspector might dominate the inspection by force of personality. It is the moderator’s job to avoid or minimize the impact of these problems.

Inspecting incomplete or sloppy documentation is a waste of time, so if excessive errors are encountered the moderator has the authority to terminate and reschedule the inspection session. Finally, the moderator can, if necessary, schedule a reinspection after rework has been completed.

23.4.2.5 Rework

Following the inspection, the moderator and the author meet to discuss the results. The focus of this meeting is the error list compiled during the inspection session. Each error is discussed, and the rework time estimated.

The responsibility for actually doing the rework rests with the author. As each error is corrected, the author notes the actual rework time. Often, estimated and actual rework times are entered into an inspection database and combined with other historical data to help improve the estimation process.

23.4.2.6 Follow-up

When the rework is completed, the author and the moderator meet once again to review the results. If the moderator is satisfied with the rework, the inspection process ends. If not, the moderator may request additional rework and another follow-up session, or even schedule a reinspection. If a reinspection is necessary, the inspection team is reconvened, and the inspection session, rework, and follow-up steps are repeated. In some organizations, a reinspection is a formal part of the process, and the moderator is given the authority to cancel this step if appropriate.

23.4.3 The management review

Following the successful completion of an inspection, the moderator formally notifies management that the project has been technically reviewed and found acceptable by (depending on the organization) writing a memo, completing a standard form, or signing the error list (complete with rework notations). In the subsequent management review, technical aspects of the system can be assumed valid and management can concentrate on costs, benefits, and the schedule.

23.5 Key terms

Author —

In an inspection, the person (or the team leader) who prepared the documentation or the code being inspected.

Inspection —

A formal review of a set of exit criteria conducted by technical personnel.

Inspector —

A technical professional or a skilled user who participates in an inspection.

Moderator —

The individual who runs an inspection, scheduling all meetings, distributing all necessary documentation, conducting all sessions, and making certain that the inspection is both thorough and fair.

Walkthrough —

An informal inspection.

23.6 Software

Not applicable.

23.7 References

1.  Freedman, D. P. and Weinberg, G. M., Handbook of Walkthroughs, Inspections, and Technical Reviews, Little, Brown, Boston, 1982.

2.  IBM Corporation, Inspections in Application Development Introduction and Implementation Guidelines, IBM Pub. No. GC20-2000, White Plains, NY, 1977.