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
   226   227   228   229   230   231   232   233   234   235   236