Cleanroom Software Engineering

1
Cleanroom Software Engineering

• Crystal Donald

2
Origins

• Developed by Dr. Harlan Mills in 1987
• Name derived from hardware cleanrooms
• Goal is zero defect rate

3
What is it?

• Formal design and requirements methods
• Statistical Usage Testing
• ______________________________
• Little or No Defects

4
Why Cleanroom?

• Quality
• Most suitable for critical applications
• Increased Productivity
• Reduces Costs

5
Cleanroom Method Steps

• Requirements Analysis
• High-level Design
• Detailed Design
• Coding by increment
• Pretest by increment
• Statistical Testing by increment

6
Incremental Development Cycle

• Early and continual quality assessment
• Increased user feedback
• Repair any process related problems
• Allow requirements changes

7
Mathematically Based Design

• Referential Transparency (Linger, 1996)
• Mapping inputs/outputs of design actual
• Similar to function mappings
• Box Structures

8
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

9
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

10
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

11
Formal Methods Overlap

• Based on mathematical principles
• Focused on 100 quality
• F.M. Complete view of reqts 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

12
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
13
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)

14
Usage Considerations

• Small teams w/ peer review of work
• Time spent on design will be greater
• But will reduce testing
• Training requirements

15
Outside Software

• Must go through correctness verification
• Possible introduction of contaminant
• Likely re-engineering in Cleanroom format

16
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

17
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

18
Resources

• http//www.uta.edu/cse/levine/fall99/cse5324/cr/cl
  ean/page1.html UTA
• http//www.dacs.dtic.mil/databases/url/key.php?key
  code64 DACS
• http//www.criticaljunction.com/werbicki/SENG623/G
  roup/SENG623W03_Cleanroom.pdf Paper