What Makes Cleanroom Different?
26.1.2 What Makes Cleanroom Different?
Dyer [DYE92] 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 improve- ment. To reach this goal, a cleanroom unique life cycle was defined which focused on math- ematics-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
The most important distinguishing
1. It makes explicit use of statistical quality control. characteristics of
2. It verifies design specification using a mathematically based proof of correct- cleanroom are proof of
ness. correctness and
statistical use testing.
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 analy- sis 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. 1
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
“It’s a funny thing uncover errors) and then debugged (to remove errors). When the software is finally about life: if you
refuse to accept released, field use uncovers still more defects and another test and debug cycle begins. anything but the
The rework associated with these activities is costly and time consuming. Worse, it best, you very often
can be degenerative—error correction can (inadvertently) lead to the introduction of get it.”
still more errors.
W. Somerset
In cleanroom software engineering, unit testing and debugging are replaced by
Maugham
correctness verification and statistically based testing. These activities, coupled with the record keeping necessary for continuous improvement, make the cleanroom approach unique.
26.2 F U N C T I O N A L S P E C I F I C AT I O N
Regardless of the analysis method that is chosen, the operational principles presented in Chapter 11 apply. Data, function, and behavior are modeled. The resultant
1 Testing is conducted but by an independent testing team.
models must be partitioned (refined) to provide increasingly greater detail. The over- all objective is to move from a specification that captures the essence of a problem to a specification that provides substantial implementation detail.
Cleanroom software engineering complies with the operational analysis princi- ples by using a method called box structure specification. A “box” encapsulates the system (or some aspect of the system) at some level of detail. Through a process of stepwise refinement, boxes are refined into a hierarchy where each box has referen- tial transparency. That is, “the information content of each box specification is suffi- cient to define its refinement, without depending on the implementation of any other box” [LIN94]. This enables the analyst to partition a system hierarchically, moving from essential representation at the top to implementation-specific detail at the bot- tom. Three types of boxes are used:
? Black box. The black box specifies the behavior of a system or a part of a
How is
refinement
system. The system (or part) responds to specific stimuli (events) by applying
accomplished as
a set of transition rules that map the stimulus into a response.
part of box structure
State box. The state box encapsulates state data and services (operations)
specification?
in a manner that is analogous to objects. In this specification view, inputs to the state box (stimuli) and outputs (responses) are represented. The state box also represents the “stimulus history” of the black box; that is, the data encapsulated in the state box that must be retained between the transitions implied.
Clear box. The transition functions that are implied by the state box are defined in the clear box. Stated simply, a clear box contains the procedural design for the state box.
Figure 26.2 illustrates the refinement approach using box structure specification.
A black box (BB 1 ) defines responses for a complete set of stimuli. BB 1 can be refined into a set of black boxes, BB 1.1 to BB 1.n , each of which addresses a class of behav- ior. Refinement continues until a cohesive class of behavior is identified (e.g., BB 1.1.1 ).
A state box (SB 1.1.1 ) is then defined for the black box (BB 1.1.1 ). In this case, SB 1.1.1 contains all data and services required to implement the behavior defined by BB 1.1.1 . Finally, SB 1.1.1 is refined into clear boxes (CB 1.1.1.n ) and procedural design details are specified.
Box structure As each of these refinement steps occurs, verification of correctness also occurs. refinement and
State-box specifications are verified to ensure that each conforms to the behavior verification of
defined by the parent black-box specification. Similarly, clear-box specifications are correctness occur
verified against the parent state box. simultaneously.
It should be noted that specification methods based on formal methods (Chapter
25) can be used in lieu of the box structure specification approach. The only require- ment is that each level of specification can be formally verified.
F I G U R E 26.2
Box structure CB 1.1.1.1 refinement
BB 1.1.1 SB 1.1.1 CB 1.1.1.2
BB 1.1 BB 1.1.2 CB 1.1.1.3
BB 1 BB 1.2 BB 1.1.3
BB 1. n
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