Software quality assurance & management

Reviewer: Stanley G. Siegel

This book treats the management aspects of software development and maintenance. The emphasis is on what has to be done to produce and maintain quality software products (i.e., products that satisfy customer requirements). This 300-page work is divided into 12 chapters, which are grouped into three parts, and one appendix. The first three chapters (42 pages) constitute Part I, which is titled Life Cycle Software Engineering Activities. This material provides motivation for the remainder of the book by discussing the challenges to management in producing quality software. It gives an overview of the software life cycle, first from an idealized perspective (i.e., the so-called “waterfall” perspective where development is viewed as a serial process) and then from the perspective of “real life” (i.e., where software development is viewed as “a series of parallel miniprojects, each building on an incomplete data set, providing a specific piece or category of data to other miniprojects and requiring data from prior or concurrent [life cycle] phases” [p. 25]). Part II of the book, consisting of Chapters 4–8 (140 pages), is titled Software Quality. It is a top down treatment of the management issues associated with quality software development and maintenance. The treatment is top down in the sense that within and across chapters issues are treated in progressively greater levels of detail. For example, Figure 5-12 specifies data control and production measures and shows seven separate attribute categories that management needs to consider to control and produce software products (these categories include quality assessment, baseline integrity, and data release). Subsequently, in Chapter 5 (Quality Evaluation of the Software Development Process), each of these attribute categories is defined in terms of a series of questions (e.g., for the baseline integrity category, one question is, “Are there formal baselines established in the project after completion of a formal customer review__?__”). Figure 5-12 also breaks down “data control and production measures” into a lower level of three activities: (1) approved end-item control, (2) data standards and production, and (3) engineering data product control. Each of these activities is further broken down in a separate figure. These activities are each further discussed in Chapter 6 (Software Process Metrics). Reading Part II is thus like reading a top-level specification for a system and then reading a more detailed specification of that system. Part III of the book, consisting of Chapters 9–12 (81 pages), is titled Special Topics in Software Quality Management and offers some “how-to-do-it” insight into some of the activities discussed in Part II. For example, Chapter 10 (Quality Evaluation Techniques—The Tools of the Trade) describes the mechanics of doing software product reviews, walk-throughs, audits, inspections, verification, and validation. A 15-page appendix, written by the Air Force and the Mitre Corporation, contains material on software reporting metrics. This material is intended to provide management with metrics and rules of thumb for interpreting metric data as an aid to gaining visibility into the status of software development. For example, software personnel indicators are discussed in the context of how they can indicate the ability to apply resources to a project. It is suggested that a plot be made of the total software staff and the experienced software staff (i.e., individuals with a minimum of five years of experience in software development) as a function of time from project initiation (say, every month). Based on this plot, the rule of thumb is suggested that “the ratio of total to experienced personnel should never exceed 6:1 (3:1 is a typical ratio for most real-time systems)” (p. 270). Following the Appendix, a 33-page glossary defines terms such as “audit,” “design review,” “system life cycle,” and “work breakdown structure.” A three-page bibliography and a nine-page index conclude the book. The book jacket asserts that “experienced software engineers and quality representatives get a complete arsenal of proven tools for maintaining product and process quality, evaluating software quality, and applying the latest technological advances directly to their projects.” I would not take issue with this assertion since the book does contain much that clearly reflects the real-world experience of the book's authors. However, the book jacket also contains the claim that the book “also serves as an industry survival guide for newly assigned software personnel and students.” Because the book is a little short on providing a rationale for many of the ideas presented, and because the book does not present too many examples to illustrate these ideas, “newly assigned software personnel and students” may often be left wondering about the “why” and benefits of doing some of the things the book calls for. For example, in the discussion of data control and production referred to earlier, the book suggests that the following question needs to be answered regarding data release (p. 84): Are there procedures in place to release data from the project after quality has been assured__?__ An example illustrating the reason for and importance of addressing such a question would have been helpful (in this case, both for the software veteran and the software novice). The book's quality suffers from an apparent lack of editing. For example, Figure 10-1 on p. 218 is a suggested form for announcing a walk-through. Within the form, the word “walk-through” is spelled two different ways (in the title of the form and the figure caption, “walk-through” is used, while in the form itself, “walkthrough” is used). Similarly, Figure 10-2 on p. 221 is a suggested form for a walk-through action item list. In the title of the form, “walkthrough” is used, while in the figure caption, “walk-through” is used. As a third example, the first sentence of the third paragraph on p. 54 begins as follows: “As illustrated in Figure 4-7, The [sic] product attributes. . . .” A more subtle example appears on p. 204 as follows: “Changes that effect [my emphasis] program baselines are transmitted to the CCB. . . .” The context appears to suggest that “affect” is intended rather than “effect.” The book is an important contribution to the growing software quality literature. While newcomers to the quality assurance field may wonder at some of its assertions and veterans may tire of its somewhat tedious presentation, both audiences will find much worthwhile to consider.