This book is essentially a collection of checklists of the components that should be included in a library of standards used to guide and control the quality of software development. The descriptive names of these eleven checklists follow:
:9N(1) Glossary of Software Engineering Terminology
(2) Software Quality Assurance Plans
(3) Software Configuration Management Plans
(4) Software Test Documentation
(5) Software Requirements Specifications
(6) Software Quality Assurance Planning
(7) Ada As a Program Design Language
(8) Taxonomy of Software Engineering Standards
(9) Software Unit Testing
(10) Software Verification and Validation Plans
(11) Software Design Descriptions
The standards represent independently usable tools that could be embraced one at a time as needed. In most organizations an attempt to use all the described tools would be overwhelming, but all could benefit from selective utilization. Organizations developing software to be used in critical situations where life is threatened and large losses are possible should take a careful look at these guidelines. The Institute of Electrical and Electronic Engineers (IEEE) has been the prime mover in the development of these guidelines. The American National Standards Institute (ANSI) approves all the items listed above except (7), (8), and (11). An impressive array of representatives from industry, government, and education participated in the development of these standards. The intended cycle for review and modification of the standards is five years.
The standards reflect the structured software development revolution that has occurred since the late 1960s. Industry has used structured methods to improve productivity and software quality. After reading the document (“not exciting reading” is an understatement), I was left with the distinct impression that quality control was the primary concern. Improving productivity is addressed only indirectly by the strong implication that high-quality software will not need to be redone and will require less maintenance over time.
These condensed software engineering standards should be in the library of any software development group with more than ten members. They represent an outline of items that could or should be included in in-house standards. Referring to them would allow a rapid start toward the development of in-house standards that describe the specifics to be used in an installation. They contain no specifics as to form, only content. For example, in the “Recommended Practice for Software Design Descriptions,” the following paragraph is found in section 5.3.9 (“Processing”):
This description should include timing, sequencing of events or processes, prerequisites for process initiation, priority of events, processing level, actual process steps, path conditions, and loop back or loop termination criteria. The handling of contingencies should describe the action to be taken in case of overflow conditions or in case of a validation check failure.
Elsewhere in the same document flowcharts, Nassi-Shneiderman charts, and program definition languages are mentioned as possible forms for expressing detailed processing. The standard does not explain any of these in detail. It also does not preclude the use of pseudocode, Warnier-Orr diagrams, or other such tools that express structure and logic in precise form. The decision concerning form is left to each installation to include in its standards. In general, this approach is taken in all the standards. What could or should be included is stipulated, but the form for expressing it is left open. This approach is the only one that could be taken in such an effort.
The document has no index, but each standard has a descriptive table of contents that makes it easy to find desired items. Each standard lists the individuals and organizations that participated in its development. References are sparse and, for such a document, perhaps unnecessary. The document itself contains an excellent synopsis of each standard in the introduction.
