1999 by CRC Press LLC

chapter twenty-three
Inspections and
walkthroughs
William S. Davis
Contents
23.1 Purpose
23.2 Strengths, weaknesses, and limitations
23.3 Inputs and related ideas
23.4 Concepts
23.4.1 The inspection team
23.4.2 The inspection process
23.4.2.1 Planning
23.4.2.2 Overview
23.4.2.3 Preparation
23.4.2.4 The inspection session
23.4.2.5 Rework
23.4.2.6 Follow-up
23.4.3 The management review
23.5 Key terms
23.6 Software
23.7 References
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 systems 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 accura-
cy 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 inspec-
tion 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 guaran-
tee 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 managers comments tend to take on added signifi-
cance 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.
Awalkthrough 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 individ-
uals: the moderator, the author, and two inspectors.
1999 by CRC Press LLC
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 involve-
ment in the project. Without managements authority, the moderator must
perform several management-like functions, so managements support is
essential.
The author is usually the person (or the project leader) who prepared the
documentation being inspected. The authors 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 con-
tacts 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 responsi-
bility. 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 documen-
tation. Note that the overview is optional.
The objective of the overview session is to save the moderator and the
inspectors some time. The authors 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 documenta-
tion, 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 par-
ticipants. The moderator and the inspectors read the documentation and
note any questions or potential problems. In some organizations, contact
1999 by CRC Press LLC
between the inspectors and the author during the preparation step is offi-
cially 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.
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 authors primary respon-
1999 by CRC Press LLC
Figure 23.1 The steps in the inspection process.
sibility 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 par-
ticipants 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 authors 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 inspec-
tion. An individual inspector might dominate the inspection by force of per-
sonality. It is the moderators 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 termi-
nate 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 inspec-
tion 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, esti-
mated 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 inspec-
tion session, rework, and follow-up steps are repeated. In some organiza-
tions, a reinspection is a formal part of the process, and the moderator is
given the authority to cancel this step if appropriate.
1999 by CRC Press LLC
23.4.3 The management review
Following the successful completion of an inspection, the moderator for-
mally 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 pre-
pared the documentation or the code being inspected.
Inspection A formal review of a set of exit criteria conducted by
technical personnel.
Inspector Atechnical 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.
1999 by CRC Press LLC