Michael Fagan

Advances in Software Inspections

IEEE Transactions on Software Engineering, Vol. SE-12 (7),

1986
pp.744-751

M. Broy et al. (eds.), Pioneers and Their Contributions to Software Engineering

© Springer-Verlag Berlin Heidelberg 2001
 Advances in Software Inspections
MICHAEL E. FAGAN, MEMBER, IEEE

Manuscript received September 30, 1985.

The·author is with the mM Thomas J. Watson Research Center, York-
town Heights, NY 10598.
IEEE Log Number 8608192.

Abstract-This paper presents new studies and experiences that en-

hance the use of the inspection process and improve its contribution to
development of defect-free software on time and at lower costs. Ex-
amples of benefits are cited followed by descriptions of the process and
some methods of obtaining the enhanced results.
Software inspection is a method of static testing to verify that soft-
ware meets its requirements. It engages the developers and others in a
formal process of investigation that usually detects more defects in the
product-and at lower cost-than does machine testing. Users of the
method report very significant improvements in quality that are ac-
companied by lower development costs and greatly reduced mainte-
nance efforts. Excellent results have been obtained by small and large
organizations in all aspects of new development as well as in mainte-
nance. There is some evidence that developers who participate in the
inspection of their own product actually create fewer defects in future
work. Because inspections formalize the development process, produc-
tivity and quality enhancing tools can be adopted more easily and rap-
idly.

Index Terms-Defect detection, inspection, project management,

quality assurance, software development, software engineering, soft-
ware quality, testing, walkthru.

INTRODUCTION

T HE software inspection process was created in 1972,

in mM Kingston, NY, for the dual purposes of im-
proving software quality and increasing programmer pro-
ductivity. Its accelerating rate of adoption throughout the
software development and maintenance industry is an ac-
 338

knowledgment of its effectiveness in meeting its goals.

Outlined in this paper are some enhancements to the in-
spection process, and the experiences of some of the many
companies and organizations that have contributed to its
evolution. The author is indebted to and thanks the many
people who have given their help so liberally.
Because of the clear structure the inspection process has
brought to the development process, it has enabled study
of both itself and the conduct of development. The latter
has enabled process control to be applied from the point
at which the requirements are inspected-a much earlier
point in the process than ever before-and throughout de-
velopment. Inspections provide data on the performance
of individual development operations, thus providing a
unique opportunity to evaluate new tools and techniques.
At the same time, studies of inspections have isolated and
fostered improvement of its key characteristics such that
very high defect detection efficiency inspections may now
be conducted routinely. This simultaneous study of de·
velopment and design and code inspections prompted the
adaptation of the principles of the inspection process to
inspections of requirements, user information, and docu-
mentation, and test plans and test cases. In each instance,
the new uses of inspection were found to improve product
quality and to be cost effective, i.e., it saved more than it
cost. Thus, as the effectiveness of inspections are improv-
ing, they are being applied in many new and different ways
to improve software quality and reduce costs.

BENEFITS: DEFECT REDUCTION, DEFECT PREVENTION,

AND COST IMPROVEMENT
In March 1984, while addressing the IBM SHARE User
Group on software service, L. H. Fenton, IBM Director
of VM Programming Systems, made an important state-
ment on quality improvement due to inspections [1]:
 339

"Our goal is to provide defect free products and

product infonnation, and we believe the best way to
do this is by refining and enhancing our existing
software development process.
Since we introduced the inspection process in
1974, we have achieved significant improvements in
quality. mM has nearly doubled the number of lines
of code shipped for System/370 software products
since 1976, while the number of defects per thou-
sand lines of code has been reduced by two-thirds.
Feedback from early MVS/XA and VM/SP Release
3 users indicates these products met and, in many
cases, exceeded our ever increasing quality expec-
tations. "
Observation of a small sample of programmers sug-
gested that early experience gained from inspections
caused programmers to reduce the number of defects that
were injected.in the design and code of programs created
later during the same project [3]. Preliminary analysis of
a much larger study of data from recent inspections is pro-
viding similar results.
It should be noted that the improvements reported by
mM were made while many of the enhancements to in-
spections that are mentioned here were being developed.
As these improvements are incorporated into everyday
practice, it is probable that inspections will help bring fur-
ther reductions in defect injection and detection rates .
.Additional reports showing that inspections improve
quality and reduce costs follow. (In all these cases, the
cost of inspections is included in project cost. Typically,
all design and code inspection costs amount to 15 percent
of project cost.)
 340

AETNA Life and Casualty. -0 Defects in use.

4439 LOC [2] -25 percent reduction in
development resource.
IBM RESPOND, U.K. -0 Defects in use.
6271 LOC [3] -9 percent reduction In
cost compared to
walkthrus.
Standard Bank of South Af- -0.15 Defects/KLOC in
rica. 143 000 LOC [4] use.
-95 percent reduction in
corrective maintenance
cost.
American Express, -0.3 Defects in use.
System code). 13 000 LOC

In the AETNA and mM examples, inspections found 82

and 93 percent, respectively, of all defects (that would
cause malfunction) detected over the life cycle of the
products. The other two cases each found over 50 percent
of all defects by inspection. While the Standard Bank of
South Africa and American Express were unable to use
trained inspection moderators, and the former conducted
only code inspections, both obtained outstanding results.
The tremendous reduction in corrective maintenance at the
Standard Bank of South Africa would also bring impres-
sive savings in life cycle costs.
Naturally, reduction in maintenance allows redirection
of programmers to work off the application backlog, which
is reputed to contain at least two years of work at most
locations. Impressive cost savings and quality improve-
ments have been realized by inspecting test plans and then
the test cases that implement those test plans. For a prod-
uct of about 20 000 LOC, R. Larson [5] reported that test
inspections resulted in:
 341

• modification of approximately 30 percent of the

'functional matrices representing test coverage,
• detection of 176 major defects in the test plans and
test cases (i.e., in 176 instances testing would have missed
testing critical function or tested it incorrectly), and
• savings of more than 85 percent in programmer time
by detecting the major defects by inspection as opposed
to finding them during functional variation testing.
There are those who would use inspections whether or
not they are cost justified for defect removal because of
the nonquantifiable benefits the technique supplies to-
ward improving the service provided to users and toward
creating a more professional application development en-
vironment [6].
Experience has shown that inspections have the effect
of slightly front-end loading the committment of people
resources in development, adding to requirements and de-
sign, while greatly reducing the effort required during
testing and for rework of design and code. The result is
an overall net reduction in development resource, and
usually in schedule too. Fig. 1 is a pictorial description
of the familiar "snail" shaped curve of software devel-
opment resource versus the time schedule including and
without inspections.

THE SOFTWARE QUALITY PROBLEM

The software quality problem is the result of defects in
code and documentation causing failure to satisfy user re-
quirements. It also impedes the growth of the information
processing industry. Validity of this statement is attested
to by three of the many pieces of supporting evidence:
• The SHARE User Group Software Service Task
Force Report, 1983 [1], that recommended an order of
magnitude improvement in software quality over the next
 342

DEVELOPMENT PEOPLE RESOURCE

AND SCHEDULE

,
,, WITH
j _I.. INSPECTIONS
,
'I #1''',
III' ,
...... ,
, ,
#I'~'/
///
,I

"
" \
\
\
/" I" \\
, I I
p DESiGN-ICODINGI' TESTING
SCHEDULE-
"tSHIP
Fig. 1.

several years, with a like reduction in service. (Other

manufacturers report similar recommendations from their
users.)
• In 1979, 12 percent of programmer resource was
consumed in- post-shipment corrective maintenance alone
and this figure was growing [8]. (Note that there is also a
significant percentage of development and enhancement
niaintenance resource devoted to correcting defects. This
is probably larger than the 12 percent expended in correc-
tive maintenance, but there is no substantiating research.)
• The formal backlog of data processing tasks most
quoted is three years [7].
At this point, a very important definition is in order:
A· defect is an instance in which a requirement is
not satisfied.
Here, it must be recognized that a requirement is any
agreed upon commitment. It is not only the recognizable
 343

external product requirement, but can also include inter-

nal development requirements (e.g., the exit criteria of an
operation) that must be met in order to satisfy the require-
ments of the end product. Examples of this would be the
requirement that a test plan completely verifies that the
product meets the agreed upon needs of the user, or that
the code of a program must be complete before it is sub-
mitted to be tested.
While defects become manifest in the end product doc-
umentation or code; most of them are actually injected as
the functional aspects of the product and its quality attri-
butes are being cre~ted; during development of the re-
quirements, the design and coding, or by insertion of
changes. The author's research supports and supplements
that of B. Boehm et ale [9] and indicates that there are
eight attributes that must be considered when describing
quality in a software product:
• intrinsic code quality,
• freedom from problems in operation,
• usability,
• installability,
• documentation for intended users,
• portability,
• maintainability and extendability, and "fitness for
use"-that implicit conventional user needs are satisfied.

INSPECTIONS AND THE SOFTWARE QUALITY PROBLEM

Previously, each of these attributes of software quality

were evaluated by testing and the end user. Now, some
of them are being partly, and -others entirely, verified
against requirements by inspection. In fact, the product
requirements themselves are often inspected to ascertain
whether they meet user needs. In order to eliminate de-
fects from the product it is necessary to address their pre-
vention, or detection and resolution as soon as possible
 344

after their injection during development and maintenance.

Prevention is the most desirable course to follow, and it
~'app~oached in many ways inciuding the use of state
machme representation of de~ign, . systema~c program-
tiring,' proof of correctness, process control, development
standards, prototyping, and other methods. Defect detec-
tion, on the other hand, was once almost totally dependent
upon testing during development and by'the user. This
has changed, and over the past decade walkthrus and in-
spections have assumed a large part of the defect detec-
tion burden; inspections finding from 60 to 90 percent
defects. (See [2], '[3], and other unpublished product ex-
periences.) They are perfonned much nearer the point of
injection of the defects than is testing, using less resource
for rework and: thus, more than paying for themselves.
IQ. fact, inspection& have been applied to most phases of
development to verify that the key 'software attributes are
pre~ent immediately after the point at which they should
first be introduced into the product. They are also applied
to test plans and test cases to improve the defect detection
efficiency of testing. Thus, inspections 'have been instru-
mental in improving all aspects of software product qual-
ity, as well as ~e quality of logic design and code. In
fact, inspections supplement defect prevention methods in
improving quality.
Essential to the quality of inspection (or its defect de-
tection efficiency) is proper definition of the development
process. And, inspection quality is a direct contributor to
product quality, as will be shown later.

DEFINITION OF THE DEVELOPMENT PROCESS

The software development process is a series of oper-

ations so arranged that its execution will deliver the de-
sired end product. Typically, these operations are: Re-
quirements Definition, System Design, High Level
 345

Design, Low Level Design, Coding, Unit Testing, Com-

ponent or Function Testing, System Testing, and then user
support and Maintenance. In practice, some of these op-
erations are repeated as the product is recycled through
them to insert functional changes and fixes.
The attributes of software quality are invested along
with the functional characteristics of the product during
the early operations, when the cost to remedy defects is
10-100 times less than it would be during testing or main-
tenance [2]. Consequently, it is advantageous to find and
correct defects as near to their point of origin as possible.
This is accomplished by inspecting the output product of
each operation to verify that it satisfies the output require-
ments or exit criteria of the operation. In most cases, these
exit criteria are not specified with sufficient precision to
allow go/no verification. Specification of exit criteria
in unambiguous terms that are objective and preferably
quantitative is an essential characteristic of any well de-
fined process. Exit criteria are the standard against which
inspections measure completion of the product at the end
of an operation, and verify the presence or absence of
quality attributes. (A deviation from exit criteria is a de-
fect.)
Shown below are the essence of 4 key criteria taken
from the full set of 15 exit criteria items for the Coding
operation:
• The source code must be at the "first clean compi-
lation" level. That means it must be properly compiled
and be free of syntax errors.
• The code must accurately implement the low level
design (which was the verified output of the preceding
process operation).
• All design changes to date are included in the code.
• All rework resulting from the code inspection has
been included and verified.
 346

The code inspection, 12, must verify that all 15 of these

exit criteria have been satisfied before a module or other
entity of the product is considered to have completed the
Coding operation. Explicit exit criteria for several of the
other inspection types in use will be contained in the au-
thor's book in software inspections. However, there is no
reason why a particular project could not define its own
sets of exit criteria. What is important is that exit criteria
should be as objective as possible, so as to be repeatable;
they should completely describe what is required to exit
each operation; and, they must be observed by all those
involved.
The objective of process control is to measure comple-
tion of the product during stages of its development, to
compare the measurement against the project plan, and
then to remedy any deviations from plan. In this context,
the quality of both exit criteria and inspections are of vital
importance. And, they must both be properly described
in the manageable development process, for such a pro-
cess must be controllable by definition.
Development is often considered a subset of the main-
tenance process. Therefore, the maintenance process must
be treated in the same manner to make it equally manage-
able.
SOFTWARE INSPECTION OVERVIEW
This paper will only give an overview description of
the inspection process that is sufficient to enable discus-
sion of updates and enhancements. The author's original
paper on the software inspections process [2] gives a brief
description of the inspection process and what goes on in
an inspection, and is the base to which the enhancements
are added. His forthcoming companion books on this sub-
ject and on building defect-free software will provide an
implementation level description and will include all the
points addressed in this paper and more.
 347

To convey the principles of software inspections, it is

only really necessary to understand how they apply to de-
sign and code. A good grasp on this application allows
tailoring of the process to enable inspection of virtually
any operation in development or maintenance, and also
allows inspection for any desired quality attribute. With
this in mind, the main points of inspections will be ex-
posed through discussing how they apply in design and
code inspections.
There are three essential requirements for the imple-
mentation of inspections:
• definition of the DEVELOPMENT PROCESS in
terms of operations and their EXIT CRITERIA,
• proper DESCRIPTION of the INSPECTION PRO-
CESS, and
• CORRECT EXECUTION of the INSPECTION PRO-
CESS . (Yes, correct execution of the process is vital.)
THE INSPECTION PROCESS
The inspection process follows any development oper-
ation whose product must be verified. As shown below,
it consists of six operations, each with a specific objec-
tive:
Operation Objectives
PLANNING Materials to be inspected must meet
inspection entry criteria.
Arrange the availability of the right
participants.
Arrange suitable meeting place and
time.
OVERVIEW Group education of participants in
what is to be inspected.
Assign inspection roles to partici-
pants.
 348

PREPARATION Participants learn the material and

prepare to fulfill their assigned
roles.
INSPECTION Find defects. (Solution hunting and
discussion of design alternatives
is discouraged.)
REWORK The author reworks all defects.
FOLLOW-UP Verification by the inspection mod-
erator or the entire inspection
team to assure that all fixes are
effective and that no secondary
defects have been introduced.
Evaluation of hundreds of inspections involving thou-
sands of programmers in which alternatives to the above
steps have been tried has shown that all these operations
are really necessary. Omitting or combining operations
has led to degraded inspection efficiency that outweighs
the apparent short-term benefits. OVERVIEW is the only
operation that under certain conditions can be omitted with
slight risk. Even FOLLOW-UP is justified as study has
shown that approximately one of every six fixes are them-
selves incorrect, or create other defects.
From observing scores of inspections, it is evident that
participation in inspection teams is extremely taxing and
should be limited to periods of 2 hours. Continuing be-
yond 2 hours, the defect detection ability of the team
seems to diminish, but is restored after a break of 2 hours
or so during which other work may be done. Accordingly,
no more than two 2 hour sessions of inspection per day
are recommended.
To assist the inspectors in finding defects, for not all
inspectors start off being good detectives, a checklist of
defect types is created to help them identify defects ap-
propriate to the exit criteria of each operation whose prod-
uct is to be inspected. It also serves as a guide to classi-
 349

fication of defects found by inspection prior to their entry

to the inspection and test defect data base of the project.
(A database containing these and other data is necessary
for quality control of development.)

PEOPLE AND INSPECTIONS

Inspection participants are usually programmers who
are drawn from the project involved. The roles they play
for design and code inspections are those of the Author
(Designer or Coder), Reader (who paraphrases the design
or code as if they will implement it), Tester (who views
the product from the testing standpoint), and Moderator.
These roles are described more fully in [2], but that level
of detail is not required here. Some inspections types, for
instance those of system structure, may require more par-
ticipants, but it is advantageous to keep the number of
people to a minimum. Involving the end users in those
inspections in which they can truly participate is also very
helpful.
The Inspection Moderator is a key player and requires
special training to be able to conduct inspections that are
optimally effective. Ideally, to preserve objectivity, the
moderator should not be involved in development of the
product that is to be inspected, but should come from an-
other similar project. The moderator functions as a
"player-coach" and is responsible for conducting the in-
spection so as to bring a peak of synergy from the group.
This is a quickly learned ability by those with some in-
terpersonal skill. In fact, when participants in the mod-
erator training classes are questioned about their case
studies, they invariably say that they sensed the presence
of the "Phantom Inspector," who materialized as a feel-
ing that there had been an additional presence contributed
by the way the inspection team worked together. The
moderator's task is to invite the Phantom Inspector.
 350

When they are properly approached by management,

programmers respond well to inspections. In fact, after
they become familiar with them, many programmers have
been known to complain when they were not allowed
enough time or appropriate help to conduct inspections
correctly.
Three separate classes of education have been recog-
nized as a necessity for proper long lasting implementa-
tion of inspections. First, Management requires a class of
one day to familiarize them with inspections and their
benefits to management, and their role in making them
successful. Next, the Moderators need three days of ed-
ucation. And, finally, the other Participants should re-
ceive one half day of training on inspections, the benefits,
and their roles. Some organizations have started inspec-
tions without proper education and have achieved some
success, but less than others who prepared their partici-
pants fully. This has caused some amount of start-over,
which was frustrating to everyone involved.

MANAGEMENT AND INSPECTIONS

A definite philosophy and set of attitudes regarding in-

spections and their results is essential. The management
education class on inspections is one of the best ways
found to gain the knowledge that must be built into day-
to-day management behavior that is required to get the
most from inspections on a continuing basis. For exam-
ple, management must show encouragement for proper
inspections. Requiring inspections and then asking for
shortcuts will not do. And, people must be motivated to
find defects by inspection. Inspection results must never
be used for personnel performance appraisal. However,
the results of testing should be used for performance ap-
praisal. This promotes finding and reworking defects at
the lowest cost, and allows testing for verification instead
 351

of debugging. In most situations programmers come to

depend upon inspections; they prefer defect-free product.
And, at those installations where management has taken
and maintained a leadership role with inspections, they
have been well accepted and very successful.
INSPECTION RESULTS AND THEIR USES

The defects found by inspection are immediately re-

corded and classified by the moderator before being en-
tered into the project data base. Here is an example:
In module: XXX, Line: YYY, NAME-CHECK is per-
formed one less time than required-LOIWIMAJ
The description of the defect is obvious. The classifi-
cation on the right means that this is a defect in Logic,
that the logic is Wrong (as opposed to Missing or Extra),
and that it is a Major defect. A MAJOR defect is one that
would cause a malfunction or unexpected result if left un-
corrected. Inspections also find MINOR defects. They
will not cause malfunction, but are more of the nature of
poor workmanship, like misspellings that do not lead to
erroneous product perfonnance.
Major defects are of the same type as defects found by
testing. (One unpublished study of defects found by sys-
tem testing showed that more than 87 percent could have
been d,etected by inspection.) Because Major defects are
equivalent to test defects, inspection results can be used
to identify defect prone design and code. This is enabled
because empirical data indicates a directly proportional
relationship between the inspection detected defect rate in
a piece of code and the defect rate found in it by subse-
quent testing. Using inspection results in this way, it is
possible to identify defect prone code and correct it, in
effect, performing real-time quality control of the product
as it is being developed, before it is shipped or put into
use.
 352

There are, of course, many Process and Quality Control

uses for inspection data including:
• Feedback to improve the development process by
identification and correction of the root causes of system-
atic defects before more code is developed;
• Feed-forward to prepare the process ahead to handle
problems or to evaluate corrective action in advance
(e. g., handling defect prone code);
• Continuing improvement and control of inspections.
An outstanding benefit of feedback, as reported in [3]
was that designers and coders through involvement in in-
spections of their own work learned to find defects they
had created more easily. This enabled them to avoid caus-
ing these defects in future work, thus providing much
higher quality product.

VARIOUS ApPLICATIONS OF INSPECTIONS

The inspection process was originally applied to hard-
ware logic, and then to software logic design and code. It
was in the latter case that it first gained notice. Since then
it has been very successfully applied to software test plans
and test cases, user documentation, high level design,
system structure design, design changes, requirements
development, and microcode. It has also been employed
for special purposes such as cleaning up defect prone
code, and improving the quality of code that has already
been tested. And, finally, it has been resurrected to pro-
duce defect-free hardware. It appears that virtually any-
thing that is created by a development process and that
can be made visible and readable can be inspected. All
that is necessary for an inspection is to define the exit
criteria of the process operation that will make the product
to be inspected, tailor the inspection defect checklists to
the particular product and exit criteria, and then to exe-
cute the inspection process.
 353

What's in a Name?
In contrast to inspections, walkthrus, which can range
anywhere from cursory peer reviews to inspections, do
not usually practice a process that is repeatable or collect
data (as with inspections), and hence this process cannot
be reasonably studied and improved. Consequently, their
defect detection efficiencies are usually quite variable and,
when studied, were found to be much lower than those of
inspections [2], [3]. However, the name "walkthru" (or
"walkthrough") has a place, for in some management and
national cultures it is more desirable than the term "in-
spection" and, in fact, the walkthrus in some of these
situations are identical to formal inspections. (In almost
all instances, however, the author's experience has been
that the tenn walkthru has been accurately applied to the
less effi.cient method-which process is actually in use can
be readily detennined by examining whether a formally
defined development process with exit criteria is in effect,
and by applying the criteria in [2, Table 5] to the activity.
In addition, initiating walkthrus as a migration path to in-
spections has led to a lot of frustration in many organi-
zations because once they start with the informal, they
seem to have much more difficulty moving to the formal
process than do those that introduce inspections from the
start. And, programmers involved in inspections are usu-
ally more pleased with the results. In fact, their major
complaints are generally to do with things that detract
from inspection quality.) What is important is that the
same results should not be expected of walkthrus as is
required of inspections, unless a close scrutiny proves the
process a~ conduct of the "walkthru" is identical to that
required for inspections. Therefore, although walkthrus
do serve very useful though limited functions, they are
not discussed further in this paper.
 354

Recognizing many of the abovementioned points, the

IBM Infonnation Systems Management Institute course
on this subject is named: "Inspections: Fonnal Applica-
tion Walkthroughs." They teach about inspection.
CONTRIBUTORS TO SOFTWARE INSPECTION QUALITY
Quality of inspection is defined as its ability to detect
all instances in which the product does not meet its re-
quirements. Studies, evaluations, and the observations of
many people who have been involved in inspections over
the past decade provide insights into the contributors to
inspection quality. Listing contributors is of little value
in trying to manage them as many have relationships with
each other. These relationships must be understood in or-
der to isolate and deal with initiating root causes of prob-
lems rather than to waste effort dealing with symptoms.
The ISHIKAWA or FISHBONE CAUSE/EFFECT DIA-
GRAM [11], shown in Fig. 2, shows the contributors and
their cause/effect relationships.
As depicted in Fig. 2, the main contributors, shown as
main branches on the diagram, are: PRODUCT IN-
SPECTABILITY, INSPECTION PROCESS, MANAGERS,
and PROGRAMMERS. Subcontributors, like INSPEC-
TION MATERIALS and CONFORMS WITH STAN-
DARDS, which contribute to the PRODUCT INSPECTA-
BILITY, are shown as twigs on these branches.
Contributors to the subcontributors are handled similarly.
Several of the relationships have been proven by objective
statistical analysis, others are supported by empirical data,
and some are evident from project experience. For ex-
ample, one set of relationships very thoroughly estab-
lished in a controlled study by F. O. Buck, in "Indicators
of Quality Inspections" [10], are:
• excessive SIZE OF MATERIALS to be inspected
leads to a PREPARATION RATE that is too high.
 355

• PREPARATION RATE that is too high contributes

to an excessive RATE OF INSPECTION, and
• Excessive RATE OF INSPECTION causes fewer de-
fects to be found.
This study indicated that the following rates should be
used in planning the 12 code inspection:

OVERVIEW: 500 Noncommentary Source

Statements per Hour.
PREPARATION: 125 Noncommentary Source
Statements per Hour.
INSPECTION: 90 Noncommentary Source
Statements per Hour.
Maximum Inspection
Rate: 125 Noncommentary Source
Statements per Hour.

The rate of inspection seems tied to the thoroughness

of the inspection, and there is evidence that defect detec-
tion efficiency diminishes at rates above 125 NCSS/h.
(Many projects require reinspection if this maximum rate
is exceeded, and the reinspection usually finds more de-
fects.) Separate from this study, project data show that
inspections conducted by trained moderators are very
much more likely to approximate the permissible inspec-
tion rates, and yield higher quality product than modera-
tors who have not been trained. Meeting this rate is not a
direct conscious purpose of the moderator, but rather is
the result of proper conduct of the inspection. In any
event, as the study shows, requiring too much material to
be inspected will induce insufficient PRE PARA TION
which, in tum, will cause the INSPECTION to be con-
ducted too fast. Therefore, it is the responsibility of man-
 356

agement and the moderator to start off with a plan that

will lead to successful inspection.
The planning rate for high level design inspection of
systems design is approximately twice the rate for code
inspection, and low level (Logic) design inspection is
nearly the same (rates are based upon the designer's es-
timate of the number of source lines of code that will be
needed to implement the design). Both these rates may
depend upon the complexity of the material to be in-
spected and the manner in which it is prepared (e.g., un-
structured code is more difficult to read and requires the
inspection rate to be lowered. Faster inspection rates while
retaining high defect detection efficiency may be feasible
with highly structured, easy to understand material, but
further study is needed). Inspections of requirements, test
plans, and user documentation are governed by the same
rules as for code inspection, although inspection rates are
not as clear for them and are probably more product and
project dependent than is the case of code.
With a good knowledge of and attention to the contrib-
utors to inspection quality, management can profoundly
influence the quality, and the development and mainte-
nance costs of the products for which they are responsi-
ble.
SUMMARY

Experience over the past decade has shown software

inspections to be a potent defect detection method, find-
ing 60-90 percent of all defects, as well as providing
feedback that enables programmers to avoid injecting de-
fects in future work. As well as providing checkpoints to
facilitate process management, inspections enable mea-
surement of the performance of many tools and tech-
niques in individual process operations. Because inspec-
tion engages similar skills to those used in creating the
PRODUCT INSPECTION
INSPECTABILITV PROCeSS
"AOCISS UCECUTfON •

MODERATOR
• TO COVER LOCAL
PROJECT NEEDS.
PROGRAMME A E. G. EKIT/ENTRY
CRITERIA,
COMPETENCY
MATERIALS, ETC.

APPROVEDI
CERTIFIED

INSPECTION VJ
(J1
-..j
QUALITV

EOUCATION

MANAGERS PROGRAMMERS
Fig. 2. Fishbone diagram of contributors to inspection quality.
 358

product (and it has been applied to virtually every design

technique and coding language), it appears that anything
that can be created and described can also be inspected.
Study and observation have revealed the following key
aspects that must be managed to take full advantage of the
many benefits that inspections offer:
Capability Action Needed to Enhance the
Capability
• Defect Detection - Management understanding
and continuing support.
This starts with education.
- Inspection moderator training
(3 days).
- Programmer training.
- Continuing management of
the contributors to inspec-
tion quality.
- Inspect all changes.
- Periodic review of effective-
ness by management.
- Inspect test plans and test
cases.
- Apply inspections to main de-
fect generating operations
in development and main-
tenance processes.
• Defect Prevention
(or avoidance) - Encourage programmers to
understand how they cre-
ated defects and what must
be done to avoid them in
future.
- Feedback inspection results
promptly and removes root
causes of systematic de-
 359

fects from the development

or maintenance processes.
- Provide inspection results to
quality circles or quality
improvement teams.
- Creation of requirements for
expert system tools (for de-
fect prevention) based upon
analysis of inspection data.
• Process
Management - Use inspection completions as
checkpoints in the devel-
opment plan and measure
accomplishment against
them.

REFERENCES
[1] L. H. Fenton, "Response to the SHARE software service task force
report," IBM Corp., Kingston, NY, Mar. 6,1984.
[2] M. E. Fagan, "Design and code inspections to reduce errors in pro-
gram development," IBM Sy.YI. J., vol. 15, no. 3, 1979.
[3] IBM Technical Newsletter GN20-3814, Base Publication GC20-2000-
0, Aug. 15, 1978.
[4] T. D. Crossman, "Inspection teams, are they worth it?" in Proc. 2nd
Nat. Symp. EDP Quality Assurance, Chicago, IL, Mar. 24-26, 1982.
[5] R. R. Larson, "Test plan and test case inspection specification," IBM
Corp., Tech. Rep. TR21.585, Apr. 4, 1975.
[6] T. D. Crossman, "Some experiences in the use of inspection teams
in application development," in Proc. Applicat. Develop. Symp.,
Monterey, CA, 1979.
[7] G. D. Brown and D. H. Sefton, "The micro vs. the applications
logjam," Datamation, Jan, 1984.
[8] J. H. Morrissey and L. S.-Y. Wu, "Software engineering: An eco-
nomical perspective," in Proc. IEEE Con! Software Eng., Munich,
West Germany, Sept. 14-19, 1979.
191 8. Boehm et al., Characteristics of Software Quality. New York:
American Elsevier, 1978.
LIO] F. O. Buck, "Indicators of quality inspections," IBM Corp., Tech.
Rep. IBM TR21.802, Sept. 1981.
[11] K. Ishikawa, Guide to Quality Control. Tokyo, Japan: Asian Pro-
ductivity Organization, 1982.
 360

Michael E. Fagan (M'62) is a Senior Technical

Staff Member at the IBM Corporation, Thomas J.
Watson Research Center • Yorktown Heights, NY .
While at IBM, he has had many interesting man-
agement und techniculussignments in the fields of
engineering. nUlIlufucturing. soflwllre develop-
ment, and research. In 1972. he created the soft-
ware inspection process, and has helped imple-
ment it within IBM and also promoted its use in
the software industry. For this and other work, he
has received IBM Outstanding Contribution and
Corporate Achievement Awards. His area of interest is in studying and
improving all the processes that comprise the software life cycle. For the
past two years, he has been a Visiting Professor at, and is on the graduate
council of, the University of Maryland.