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 below).

* Inspections must be led by a trained moderator (whose role is described below).

* 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 it.

* 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 repaired.

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 inspection.

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.