- Fagan Inspections.
- Notes by Dr. Tony Cowling.
- Starting in the 1970's, Michael Fagan at IBM began to develop an
alternative approach, in which these informal reviews and
walkthroughs (but not actual testing) were replaced by more formally
structured inspections. These inspections were applied throughout
the development process, and were concerned with all aspects of the
quality of the documents being inspected, not just whether they
appeared to have errors in the logic or functionality that was being
described. Thus, Gilb illustrates (figure 12.1) the process model
for one system where 11 different inspections were applied, covering
the high and low-level designs, the source code, the test plans and
test cases, the plan for the manuals and the first and final drafts
of each manual. He also gives another example (chapter 21) of a
project where initially 13 inspection points were defined, and later
extended to 17, although only 5 of them were mandatory: these were
for inspection of the initial and full requirements documents (what
they called the requirements and product specifications
respectively), of the high-level design, of the module test plans
and of the code itself. The common feature in both of these is the
emphasis on inspecting the early documents, so as to reduce the
number of errors that need to be corrected later in the development
(cf figure 12.11), and hence the overall cost of the development (cf
figure 12.10, which illustrates how costs of fixing a defect
increase the later it is found).
- Fagan developed a number of rules for the procedures to be used
in carrying out these inspections, and these are listed in section
12.1: they are as follows.
- * Team members of all levels of seniority are involved.
- * There is a prescribed series of steps that must be followed.
- * Inspection meetings must be limited to 2 hours long (except
where a separate "third hour" is used, as described
- * Inspections must be led by a trained moderator (whose role is
- * Each inspector must have specific roles in the inspection.
- * The inspectors should use prepared checklists of questions to
be asked, where the lists must not be more than one page long, and
the questions will depend on the type of document being inspected.
- * The rate at which material is inspected must be controlled, so
as to achieve optimum detection of errors.
- * Discussion is not permitted as to whether something in the
document that is not clear is correct or not: lack of clarity is
itself a defect.
- * Discussion is not permitted as to how a defect might be
corrected: the role of the inspection is to identify it, so that
the moderator can subsequently assign responsibility for correcting
- * If the inspectors feel that they need to discuss how a defect
might be corrected, then they should convene a "third hour"
meeting for this purpose.
- * Statistics must be kept on types of defects found, and used to
monitor for weak points in the development process.
- In addition to these rules, the important parts of this process
are the standard set of steps that must be carried out during an
inspection, and the role of the moderator for an inspection. The
steps that are required are as follows.
- Planning - the amount of material to be inspected is determined,
the members of the inspection team are appointed, and (if necessary)
responsibilities for different aspects of the inspection allocated
to the inspectors.
- Overview - needed if the inspectors are not already familiar
with the background of the project - consists of a presentation to
give them than overall view of the project.
- Preparation - inspectors work through the material individually,
using the checklists, to identify possible defects.
- Meeting - inspectors collectively report suspected defects to
the meeting (which may help others to identify other defects), and
these are recorded.
- Rework - the list of suspected defects is assigned to a person
to repair the defects.
- Third hour - an optional stage, to allow the inspectors to
discuss how defects might be repaired.
- Follow-up - it is essential to ensure that the defects have been
- Typically, the moderators role in this will be to organise the
steps: that is:
- * lead the planning step;
- * arrange for the overview to be given if it is needed;
- * lead the meeting and ensure that the defects are properly
recorded (which often means they act as recorder);
- * control the rate at which the meeting works through the
material being inspected;
- * assign the responsibilities for rework;
- * lead the third hour meeting if one is held; and
- * check personally that the rework has been carried out.
- Thus, the moderator is responsible for ensuring that the whole
inspection process is carried out as efficiently as possible, except
for being responsible for checking how well the rework has been
done, since that should be done by holding another inspection.
However, it is the moderator's responsibility to ensure that there
is a subsequent inspection of the reworked documents, so that they
will not be signed off as fit for use in later stages of the
development until a moderator is satisfied that they have passed an
- The use of appropriate checklists is also an important part of
an inspection, but the format of these is not prescribed, and in
practice any organisation using these sorts of inspections will
develop its own checklists for the particular kinds of documents
that it is having to inspect. Thus, the checklists used for
inspecting a structured requirements document will contain very
different questions to checklists for inspecting program code. In
general, though, for any document there will be two types of
question on the checklists: one set will be concerned with the
internal consistency of the documents being inspected (items that
are not properly defined, or that appear to be contradictory), and
the other set will be concerned with whether these documents are
consistent with others that have already been approved: for
instance, checking whether the implementation of some code is
consistent with the design and specification for it.