SUMMARY Cleanroom software engineering is a formal approach to software development that
26.5 SUMMARY Cleanroom software engineering is a formal approach to software development that
can lead to software that has remarkably high quality. It uses box structure specifi-
CHAPTER 26 C L E A N R O O M S O F T WA R E E N G I N E E R I N G
cation (or formal methods) for analysis and design modeling and emphasizes cor- rectness verification, rather than testing, as the primary mechanism for finding and removing errors. Statistical use testing is applied to develop the failure rate infor- mation necessary to certify the reliability of delivered software.
The cleanroom approach begins with analysis and design models that use a box structure representation. A “box” encapsulates the system (or some aspect of the sys- tem) at a specific level of abstraction. Black boxes are used to represent the exter- nally observable behavior of a system. State boxes encapsulate state data and operations. A clear box is used to model the procedural design that is implied by the data and operations of a state box.
Correctness verification is applied once the box structure design is complete. The procedural design for a software component is partitioned into a series of subfunc- tions. To prove the correctness of the subfunctions, exit conditions are defined for each subfunction and a set of subproofs is applied. If each exit condition is satisfied, the design must be correct.
Once correctness verification is complete, statistical use testing commences. Unlike conventional testing, cleanroom software engineering does not emphasize unit or integration testing. Rather, the software is tested by defining a set of usage scenar- ios, determining the probability of use for each scenario, and then defining random tests that conform to the probabilities. The error records that result are combined with sampling, component, and certification models to enable mathematical com- putation of projected reliability for the software component.
The cleanroom philosophy is a rigorous approach to software engineering. It is a software process model that emphasizes mathematical verification of correctness and certification of software reliability. The bottom line is extremely low failure rates that would be difficult or impossible to achieve using less formal methods.
REFERENCES [CUR86] Curritt, P.A., M. Dyer, and H.D. Mills, “Certifying the Reliability of Software,”
IEEE Trans, Software Engineering, vol. SE-12, no. 1, January 1994. [DYE92] Dyer, M., The Cleanroom Approach to Quality Software Development, Wiley, 1992. [HAU94] Hausler, P.A., R. Linger, and C. Trammel, “Adopting Cleanroom Software Engineering with a Phased Approach,” IBM Systems Journal, vol. 33, no.1, January 1994, pp. 89–109. [HEN95] Henderson, J., “Why Isn’t Cleanroom the Universal Software Development Methodology?” Crosstalk, vol. 8, No. 5, May 1995, pp. 11–14. [HEV93] Hevner, A.R. and H.D. Mills, “Box Structure Methods for System Develop- ment with Objects,” IBM Systems Journal, vol. 31, no.2, February 1993, pp. 232–251. {LIN79] Linger, R.M., H.D. Mills, and B.I. Witt, Structured Programming: Theory and Practice, Addison-Wesley, 1979.
[LIN88] Linger, R.M. and H.D. Mills, “A Case Study in Cleanroom Software Engi- neering: The IBM COBOL Structuring Facility,” Proc. COMPSAC ’88, Chicago, October 1988. [LIN94] Linger, R., “Cleanroom Process Model,” IEEE Software, vol. 11, no. 2, March 1994, pp. 50–58. [MIL87] Mills, H.D., M. Dyer, and R. Linger, “Cleanroom Software Engineering,” IEEE Software, vol. 4, no. 5, September 1987, pp. 19–24. [MIL88] Mills, H.D., “Stepwise Refinement and Verification in Box Structured Sys- tems,” Computer, vol. 21, no. 6, June 1988, pp. 23–35. [MUS87] Musa, J.D., A. Iannino, and K. Okumoto, Engineering and Managing Software with Reliability Measures, McGraw-Hill, 1987. [POO88] Poore, J.H. and H.D. Mills, “Bringing Software Under Statistical Quality Con- trol,” Quality Progress, November 1988, pp. 52–55. [POO93] Poore, J.H., H.D. Mills, and D. Mutchler, “Planning and Certifying Software System Reliability,” IEEE Software, vol. 10, no. 1, January 1993, pp. 88–99. [WOH94] Wohlin, C. and P. Runeson, “Certification of Software Components,” IEEE Trans. Software Engineering, vol. SE-20, no. 6, June 1994, pp. 494–499.
Parts
» The Concurrent Development Model
» SUMMARY Software engineering is a discipline that integrates process, methods, and tools for
» PEOPLE In a study published by the IEEE [CUR88], the engineering vice presidents of three
» THE PROCESS The generic phases that characterize the software process—definition, development,
» THE PROJECT In order to manage a successful software project, we must understand what can go
» METRICS IN THE PROCESS AND PROJECT DOMAINS
» Extended Function Point Metrics
» METRICS FOR SOFTWARE QUALITY
» INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
» METRICS FOR SMALL ORGANIZATIONS
» ESTABLISHING A SOFTWARE METRICS PROGRAM
» Obtaining Information Necessary for Scope
» An Example of LOC-Based Estimation
» QUALITY CONCEPTS 1 It has been said that no two snowflakes are alike. Certainly when we watch snow
» SUMMARY Software quality assurance is an umbrella activity that is applied at each step in the
» R diagram 1.4 <part-of> data model; data model <part-of> design specification;
» SYSTEM MODELING Every computer-based system can be modeled as an information transform using an
» Facilitated Application Specification Techniques
» Data Objects, Attributes, and Relationships
» Entity/Relationship Diagrams
» Hatley and Pirbhai Extensions
» Creating an Entity/Relationship Diagram
» SUMMARY Design is the technical kernel of software engineering. During design, progressive
» Data Modeling, Data Structures, Databases, and the Data Warehouse
» Data Design at the Component Level
» A Brief Taxonomy of Styles and Patterns
» Quantitative Guidance for Architectural Design
» Isolate the transform center by specifying incoming and outgoing
» SUMMARY Software architecture provides a holistic view of the system to be built. It depicts the
» The User Interface Design Process
» Defining Interface Objects and Actions
» D E S I G N E VA L U AT I O N
» Testing for Real-Time Systems
» Organizing for Software Testing
» Criteria for Completion of Testing
» The Transition to a Quantitative View
» The Attributes of Effective Software Metrics
» Architectural Design Metrics
» Component-Level Design Metrics
» SUMMARY Software metrics provide a quantitative way to assess the quality of internal product
» Encapsulation, Inheritance, and Polymorphism
» Identifying Classes and Objects
» The Common Process Framework for OO
» OO Project Metrics and Estimation
» Event Identification with Use-Cases
» SUMMARY Object-oriented analysis methods enable a software engineer to model a problem by
» Partitioning the Analysis Model
» Designing Algorithms and Data Structures
» Program Components and Interfaces
» SUMMARY Object-oriented design translates the OOA model of the real world into an
» Testing Surface Structure and Deep Structure
» Deficiencies of Less Formal Approaches 1
» What Makes Cleanroom Different?
» Design Refinement and Verification
» SUMMARY Cleanroom software engineering is a formal approach to software development that
» Structural Modeling and Structure Points
» Describing Reusable Components
» SUMMARY Component-based software engineering offers inherent benefits in software quality,
» Guidelines for Distributing Application Subsystems
» Middleware and Object Request Broker Architectures
» An Overview of a Design Approach
» Consider expert Web developer will create a complete design, but time and cost can be appropriate
» A Software Reengineering Process Model
» Reverse Engineering to Understand Data
» Forward Engineering for Client/Server Architectures
» SUMMARY Reengineering occurs at two different levels of abstraction. At the business level,
Show more