Page 231 -
P. 231
202 PART TWO MANAGING SOFTWARE PROJECTS
Audits designated software work products to verify compliance with those
defined as part of the software process. The SQA group reviews selected work
products; identifies, documents, and tracks deviations; verifies that corrections have
been made; and periodically reports the results of its work to the project manager.
Ensures that deviations in software work and work products are documented
and handled according to a documented procedure. Deviations may be encoun-
tered in the project plan, process description, applicable standards, or technical work
products.
Records any noncompliance and reports to senior management. Noncom-
pliance items are tracked until they are resolved.
In addition to these activities, the SQA group coordinates the control and manage-
ment of change (Chapter 9) and helps to collect and analyze software metrics.
8.4 SOFTWARE REVIEWS
Software reviews are a "filter" for the software engineering process. That is, reviews
are applied at various points during software development and serve to uncover errors
Like water filters, FTRs and defects that can then be removed. Software reviews "purify" the software engi-
tend to retard the neering activities that we have called analysis, design, and coding. Freedman and
“flow” of software Weinberg [FRE90] discuss the need for reviews this way:
engineering activities.
Too few and the flow Technical work needs reviewing for the same reason that pencils need erasers: To err is
is “dirty.” Too many human. The second reason we need technical reviews is that although people are good at
and the flow slows to catching some of their own errors, large classes of errors escape the originator more eas-
a trickle. Use metrics ily than they escape anyone else. The review process is, therefore, the answer to the prayer
to determine which
reviews work and of Robert Burns:
which may not be
effective. Take the O wad some power the giftie give us
ineffective ones out of to see ourselves as other see us
the flow.
A review—any review—is a way of using the diversity of a group of people to:
1. Point out needed improvements in the product of a single person or team;
2. Confirm those parts of a product in which improvement is either not desired or not
needed;
3. Achieve technical work of more uniform, or at least more predictable, quality than can
be achieved without reviews, in order to make technical work more manageable.
Many different types of reviews can be conducted as part of software engineer-
ing. Each has its place. An informal meeting around the coffee machine is a form of
review, if technical problems are discussed. A formal presentation of software design
to an audience of customers, management, and technical staff is also a form of