Cleanroom Software
Engineering
Crystal Donald
Origins
Developed by Dr. Harlan Mills in 1987
 Name derived from hardware cleanrooms
 Goal is zero defect rate

What is it?
Formal design and requirements methods
+
Statistical Usage Testing
______________________________
Little or No Defects
Why Cleanroom?
Quality
 Most suitable for critical applications
 Increased Productivity
 Reduces Costs

Cleanroom Method Steps
Requirements Analysis
 High-level Design
 Detailed Design
 Coding by increment
 Pretest by increment
 Statistical Testing by increment

Incremental Development Cycle
Early and continual quality assessment
 Increased user feedback
 Repair any process related problems
 Allow requirements changes

Mathematically Based Design
Referential Transparency (Linger, 1996)
 Mapping inputs/outputs of design = actual
 Similar to function mappings
 Box Structures

Box Structures
Map system inputs to system outputs
 Black Box

((current stimulus, stimulus history) 
response)

State Box
((c. stimulus, c. state)  (response, new state))

Clear Box
State transition procedures are defined explicitly
Correctness Verification
Replaces unit testing and debugging
 No constraints on how code is written
 Code vs. Specification
 Function theoretic static code analysis
 Review done mentally and verbally
 Written proofs not required
 No compiling of code

Statistical Usage Testing
Description of how system will be used
 Defined for all possible code scenarios w/
probability of occurrence
 Hierarchical usage breakdown and
probability distribution
 Concentrates on finding defects that are
statistically most significant

Formal Methods Overlap







Based on mathematical principles
Focused on 100% quality
F.M. – Complete view of req’ts in advance
F.M. – Model entire system at once for quality
C.R. – Model system incrementally
F.M. – Logic as basis, C.R. – Function mapping
FM and CR can be integrated for higher quality
Comparison
Typical Development
Cleanroom Dev
Specification usually
incomplete for external
behavior
Precise and complete
description for ext. behavior
From specification, code is
informal, debug to verify
Box Structures used to refine
and verify
Failures are common and
accepted
Not accepted
Attempted coverage, poor
field reliability prediction
Usage model based, predict
field reliability
Capability Maturity Model (CMM)
Overlap
CR covers a larger number of (Key
Process Areas) KPAs
 CMM has 5 Levels
 Cleanrooms has high correspondence with
Levels 2-5 of CMM (No Ad-hoc processes)

Usage Considerations
Small teams w/ peer review of work
 Time spent on design will be greater
 But will reduce testing
 Training requirements

Outside Software
Must go through correctness verification
 Possible introduction of “contaminant”
 Likely re-engineering in Cleanroom format

Debate
Advance process of software development
 Theoretical foundation for SW
development
vs.
 Cleanroom is too radical for SW dev.
 Still too new and relatively unproven
claims

Conclusion

Key Characteristics of Cleanroom SE
Incremental Development Life Cycle
 Defect Prevention: Quality Assessment thru
Statistical Testing
 Disciplined SE methods required to create
correct, verifiable software

Resources
http://www.uta.edu/cse/levine/fall99/cse53
24/cr/clean/page1.html UTA
 http://www.dacs.dtic.mil/databases/url/key.
php?keycode=64 DACS
 http://www.criticaljunction.com/werbicki/SE
NG623/Group/SENG623W03_Cleanroom.
pdf Paper
