Page 83 -

members is that they would have built the software differently had they been given a bet-
ter understanding of what was needed from the beginning. One important root cause of
these problems is defects in work products that are not caught until long after those work
products have been used as the basis for later project activities.
The most important reason to inspect documents is to prevent defects. If the team starts
building software based on a vision and scope document that has a serious defect, eventu-
ally the entire project will have to stop and reverse course. This can be very expensive in
both effort and morale, because the team will need to backtrack and revise the require-
ments, design, code, test plans, and other work products that they have already put a lot
of effort into implementing. The same goes for defects that were caught in other work
products—defects missed in a design specification, for example, will have to be corrected
later after they have been coded. The longer a defect goes uncorrected, the more
entrenched it is in other work products; the more entrenched it is, the more time and
effort it will take to fix.
According to a report by the Software Engineering Institute, it costs more to not do inspec-
tions than it does to do them. A national survey of software engineering teams found that
in a typical inspection, four to five people spend one to two hours preparing for inspec-
tions, followed by one to two hours to hold an inspection meeting. The total effort
required for the inspection, therefore, is 10 to 20 person-hours; this effort results in the
early detection of an average of 5 to 10 defects. (On the average, these defects, if left in the
document, would require either 250 to 500 lines of new code or modification of 1000 to
1500 lines of legacy code to repair if they were eventually caught—which would almost
certainly require well over 20 person-hours of programmers’ time!) This is a very high
return on investment; few tools, techniques, or practices are as effective as inspections for
increasing the quality of the software.

Inspections are easy to implement, and have an immediate effect on quality and consen-
sus-building. A small team spending a few hours inspecting a work product will catch
errors that could potentially save weeks, or even months, of wasted effort. An effective
inspection requires a well-chosen team, a moderator who is able to run the meeting, and
an author who is willing to listen to criticism and fix the work product being inspected.

Choose the Inspection Team
The job of the inspection team is to work with the author of the document in order to
identify any defects. A defect is any problem in the document that will prevent an inspector
from approving it. Once a problem is identified, the inspection team must work to come
up with a solution that will fix the problem. When the team meets to inspect the docu-
ment, they will be expected to come up with solutions to the defects that they find. The
project manager must select a team that can perform this function. This means that each
inspector needs to have enough familiarity with the project and the way the work product
will be used to understand its problems and propose changes. (Team members who use
the document in their day-to-day work should have no problem with this.)

REVIEWS 75