The philosophy of the “cleanroom” in hardware fabrication technologies is really quite simple: It is cost-effective and time-effective to e...
The philosophy of the “cleanroom” in hardware fabrication technologies is really quite simple: It is cost-effective and time-effective to establish a fabrication approach that precludes the introduction of product defects. Rather than fabricating a product and then working to remove defects, the cleanroom approach demands the discipline required to eliminate defects in specification and design and then fabricate in a “clean” manner.
The cleanroom philosophy was first proposed for software engineering by Mills, Dyer, and Linger during the 1980s. Although early experiences with this disciplined approach to software work showed significant promise , it has not gained widespread usage. Henderson suggests three possible reasons:
1. A belief that the cleanroom methodology is too theoretical, too mathematical, and too radical for use in real software development.
2. It advocates no unit testing by developers but instead replaces it with correctness verification and statistical quality control—concepts that represent a major departure from the way most software is developed today.
3. The maturity of the software development industry. The use of cleanroom processes requires rigorous application of defined processes in all life cycle phases. Since most of the industry is still operating at the ad hoc level (as defined by the Software Engineering Institute Capability Maturity Model), the industry has not been ready to apply thosetechniques.
Despite elements of truth in each of these concerns, the potential benefits of cleanroom software engineering far outweigh the investment required to overcome the cultural resistance that is at the core of these concerns.
The Cleanroom Strategy
The cleanroom approach makes use of a specialized version of the incremental software model . A “pipeline of software increments” is developed by small independent software engineering teams. As each increment is certified, it is integrated in the whole. Hence, functionality of the system grows with time.
The sequence of cleanroom tasks for each increment is illustrated in figure. Overall system or product requirements are developed using the system engineering methods . Once functionality has been assigned to the software element of the system, the pipeline of cleanroom increments is initiated. The following tasks occur:
Increment planning. A project plan that adopts the incremental strategy is developed. The functionality of each increment, its projected size, and a cleanroom development schedule are created. Special care must be taken to ensure that certified increments will be integrated in a timely manner.
Requirements gathering. Using techniques , a more-detailed description of customer-level requirements (for each increment) is developed.
Box structure specification. A specification method that makes use of box structures is used to describe the functional specification. Conforming to the operational analysis principles , box structures “isolate and separate the creative definition of behavior, data, and procedures at each level of refinement.”
Formal design. Using the box structure approach, cleanroom design is a natural and seamless extension of specification. Although it is possible to make a clear distinction between the two activities, specifications (called black boxes) are iteratively refined (within an increment) to become analogous to architectural and component-level designs (called state boxes and clear boxes, respectively).
Correctness verification. The cleanroom team conducts a series of rigorous correctness verification activities on the design and then the code. Verification begins with the highest-level box structure (specification) and moves toward design detail and code. The first level of correctness verification occurs by applying a set of “correctness questions” . If these do not demonstrate that the specification is correct, more formal (mathematical) methods for verification are used.
Code generation, inspection, and verification. The box structure specifications, represented in a specialized language, are translated into the appropriate programming language. Standard walkthrough or inspection techniques are then used to ensure semantic conformance of the code and box structures and syntactic correctness of the code. Then correctness verification is conducted for the source code.
Statistical test planning. The projected usage of the software is analyzed and a suite of test cases that exercise a “probability distribution” of usage are planned and designed. Referring to figure, this cleanroom activity is conducted in parallel with specification, verification, and code generation.
Statistical use testing. Recalling that exhaustive testing of computer software is impossible , it is always necessary to design a finite number of test cases. Statistical use techniques execute a series of tests derived from a statistical sample of all possible program executions by all users from a targeted population.
Certification. Once verification, inspection, and usage testing have been completed (and all errors are corrected), the increment is certified as ready for integration.
Like other software process models discussed elsewhere in this book, the cleanroom process relies heavily on the need to produce high-quality analysis and design models. Box structure notation is simply another way for a software engineer to represent requirements and design. The real distinction of the cleanroom approach is that formal verification is applied to engineering models.
What Makes Cleanroom Different
Dyer alludes to the differences of the cleanroom approach when he defines the process:
Cleanroom represents the first practical attempt at putting the software development process under statistical quality control with a well-defined strategy for continuous process improvement. To reach this goal, a cleanroom unique life cycle was defined which focused on mathematics- based software engineering for correct software designs and on statistics-based software testing for certification of software reliability.
Cleanroom software engineering differs from the conventional and object-oriented views presented in Parts Three and Four of this book because
1. It makes explicit use of statistical quality control.
2. It verifies design specification using a mathematically based proof of correctness.
3. It relies heavily on statistical use testing to uncover high-impact errors.
Obviously, the cleanroom approach applies most, if not all, of the basic software engineering principles and concepts presented throughout this book. Good analysis and design procedures are essential if high quality is to result. But cleanroom engineering diverges from conventional software practices by deemphasizing (some would say, eliminating) the role of unit testing and debugging and dramatically reducing (or eliminating) the amount of testing performed by the developer of the software.
In conventional software development, errors are accepted as a fact of life. Because errors are deemed to be inevitable, each program module should be unit tested (to uncover errors) and then debugged (to remove errors). When the software is finally released, field use uncovers still more defects and another test and debug cycle begins. The rework associated with these activities is costly and time consuming. Worse, it can be degenerative—error correction can (inadvertently) lead to the introduction of still more errors.
In cleanroom software engineering, unit testing and debugging are replaced by correctness verification and statistically based testing. These activities, coupled with the record keeping necessary for continuous improvement, make the cleanroom approach unique.
