NOTES ON THE SOFTWARE INSPECTION:

Overview and Frequently Asked Questions

Prepared by Craig K. Tyran

Overview

Software plays a major role in modern organizations, as it is used to run the computer-
based systems which collect, store, transform, and organize the data used to conduct
business. Unfortunately, the development of software is a major headache for
organizations. Frequently software is delivered late and does not meet user requirements
due to defects.

Many software problems may be attributed to the development of low quality software
that is characterized by numerous defects. It has been suggested by software experts that
the way to address these types of software problems is to improve software quality
through quality assurance methods. Quality improvements will reduce defects and thus
speed up development time (due to less rework required prior to release) and decrease the
costs and personnel demands associated with program maintenance (due to fewer defects
in the released software).

One of the most well known software quality techniques is the software inspection. A
software inspection is a group meeting which is conducted to uncover defects in a
software "work product" (e.g., requirements specification, user interface design, code,
test plan). The software inspection approach is a formally defined process involving a
series of well defined inspection steps and roles, a checklist to aid error detection, and the
formal collection of process and product data.

Software inspections are conducted in industry because they have been found to be an
effective way to uncover defects. The detection rate for an inspection varies depending on
the type of work product being inspected and the specific inspection process used.
Studies have found that 30 to 90 percent of the defects in a work product may be
uncovered through the inspection process. Early detection of defects can lead to cost
savings. For example, one study has estimated that inspection-based techniques at
Hewlett-Packard have yielded a cost saving of $21 million. It should be noted that
inspections may take up a significant portion of a project's time and budget if performed
on a consistent basis throughout the life of a project. According to an industry estimate
from AT&T, project teams may devote four to fifteen percent of project time to the
inspection process. While allocating this amount of time on inspections may seem high,
the benefit of reducing software defects has been found to outweigh the cost of
conducting inspections.
The favorable attitude that many in the software development field have toward the
inspection process is underscored by a statement made by Barry Boehm (a well known
expert in the field of systems development), who has written that "the [software
inspection] has been the most cost effective technique to date for eliminating software
errors."

Software Inspections: Frequently Asked Questions

What is a software inspection?

• A group review of a software "work product" for the purpose of identifying

defects or deficiencies.

What is meant by a "work product"?

• A work product refers to the models, designs, programs, test plans, etc. that are
generated during the systems development process. Examples of work products
corresponding to some of the different system life cycle phases include:
o Analysis phase: DFDs, ER diagrams, project dictionary entries, process
specifications
o Design phase: input/output forms, reports, database design, structure
charts
o Implementation phase: program code, test plan for code

What is meant by "defects and deficiencies"?

o Anything that may ultimately hinder the quality of the final software
product is considered a defect. Defects may happen throughout the
development process. For example, errors regarding DFDs and the project
dictionary may occur during the analysis phase; poor user interfaces may
be generated during the design phase; and "buggy" code and incomplete
testing plans may be generated during the implementation phase.

Why perform software inspections?

• Inspections are justified on an economic basis. The earlier that a software defect
can be identified, the cheaper it is to fix. For example, studies show that a defect
that is found during system testing can be 10 to 100 times more expensive to fix
than defects found early in the development life cycle (e.g., analysis and design).
 • Data collected during the inspection process (e.g., the types and rates of defects)
can be used to help improve the software development process. For example, if
software developers in an organization tend to make the same types of errors on
multiple projects, the organization may wish to understand the root cause for
these problems and take action to improve the development process.
• Inspections can help to improve communication and learning
o Among IS personnel
o Between IS and user personnel

What is the "output" of an inspection review?

• An "Action List" of the errors/deficiencies that need to be fixed. This list is then
passed onto the person who produced the work product.

Does a software inspection entail error detection AND error correction, or just error
detection?

• Only error detection. Error correction is delegated to the person who produced the
work product.

Are inspections typically used for purposes of performance appraisal?

• No. Organizations that conduct inspections have found that it is best to use the
inspection process to improve the quality of a work product and not use the
inspection for performance appraisal. They have found that if inspections are used
to formally track performance of IS personnel for performance appraisals, then
the inspections become too much of a high-stress activity and some personnel do
not want to participate.

What is a good attitude for inspectors to have during an inspection?

• Consider the work product guilty until proven innocent.

• However, the producer is always innocent (i.e., focus on the product and not the
person who developed the product).

When should an inspection be conducted?

 • When a unit of work/documentation is completed and is still in a "bite size" piece,
then an inspection should be scheduled. For example, during analysis, it may be
appropriate to conduct an inspection once the first draft of DFDs for a subset of
the project have been completed. During programming, an inspection of code
could be conducted once the program for a new module has been coded.
• Conduct inspections frequently to find errors as early as possible.

Who participates in an inspection?

• IS personnel and users may be involved. The selection of participants depends on

the purpose of the inspection. For example, code inspections typically involve
only IS personnel. However, an inspection concerning analysis and design work
products may involve the users. In the latter case, prior to a review with the user,
there may be an internal MIS review involving only IS personnel where the work
product is checked to make sure it is accurate and clear. Once the work product is
"in shape" to be viewed by users, an external review and inspection involving
both IS and user personnel may take place (to determine if the system supports the
user needs).

What may be some of the potential problems that happen during inspection meetings?

• Group inspection meetings may be unproductive due to sidetracking and

domination by certain group members. Also, if inspectors are not "polite,"
inspections may lead to excessive criticism and conflict. Also, there is the chance
that inspectors can get bogged down on trying to correct problems.

How can these potential problems be addressed?

• To help address some of the potential problems with group inspections, successful
inspection teams follow a set of guidelines/ground rules. Specific guidelines
include:

The number of participants should be manageable

- Range: 3-6 people

Emphasize error detection, not correction

Participants should be "charitable critics" (don't be nasty)
 Follow organizational standards (e.g., diagramming/naming
conventions, etc.) to reduce misunderstandings or
disagreements.
Recognize that there may be some "open issues" that can
not be resolved at the inspection meeting (e.g., when
inspecting an analysis documents, there may be some
questions that need to be referred to the user)
Keep length of inspection to be less than two hours to
reduce fatigue factor.

Sources:

Ackerman, A., et al. "Software inspections: An effective verification process," IEEE

Software, May 1989, 31-36.

Boehm, V. "Indutrial sofware metrics top ten list," IEEE Software, September 1987, 84-
85.

Ebenau, R. and Strauss, S. Software Inspection Process, McGraw-Hill, New York, New
York, 1994.

Gilb, T. and Graham, D. Software Inspection, Addison-Wesley, Wokingham, England,

1993.

Grady, R. and Van Slack, T. "Key lessons in achieving widespread inspection use," IEEE
Software, 11(4), July 1994.