Cleanroom Software Engineering Crystal Donald

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

What is it? Formal design and requirements methods + Statistical Usage Testing ______________________________ Little or No Defects

Why Cleanroom? Quality Quality Most suitable for critical applications Most suitable for critical applications Increased Productivity Increased Productivity Reduces Costs Reduces Costs

Cleanroom Method Steps Requirements Analysis Requirements Analysis High-level Design High-level Design Detailed Design Detailed Design Coding by increment Coding by increment Pretest by increment Pretest by increment Statistical Testing by increment Statistical Testing by increment

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

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

Box Structures Map system inputs to system outputs Map system inputs to system outputs Black Box Black Box ((current stimulus, stimulus history)  response) State Box State Box ((c. stimulus, c. state)  (response, new state)) Clear Box Clear Box State transition procedures are defined explicitly

Correctness Verification Replaces unit testing and debugging Replaces unit testing and debugging No constraints on how code is written No constraints on how code is written Code vs. Specification Code vs. Specification Function theoretic static code analysis Function theoretic static code analysis Review done mentally and verbally Review done mentally and verbally Written proofs not required Written proofs not required No compiling of code No compiling of code

Statistical Usage Testing Description of how system will be used Description of how system will be used Defined for all possible code scenarios w/ probability of occurrence Defined for all possible code scenarios w/ probability of occurrence Hierarchical usage breakdown and probability distribution Hierarchical usage breakdown and probability distribution Concentrates on finding defects that are statistically most significant Concentrates on finding defects that are statistically most significant

Formal Methods Overlap Based on mathematical principles Based on mathematical principles Focused on 100% quality Focused on 100% quality F.M. – Complete view of req’ts in advance F.M. – Complete view of req’ts in advance F.M. – Model entire system at once for quality F.M. – Model entire system at once for quality C.R. – Model system incrementally C.R. – Model system incrementally F.M. – Logic as basis, C.R. – Function mapping F.M. – Logic as basis, C.R. – Function mapping FM and CR can be integrated for higher quality 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 CR covers a larger number of (Key Process Areas) KPAs CMM has 5 Levels CMM has 5 Levels Cleanrooms has high correspondence with Levels 2-5 of CMM (No Ad-hoc processes) Cleanrooms has high correspondence with Levels 2-5 of CMM (No Ad-hoc processes)

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

Outside Software Must go through correctness verification Must go through correctness verification Possible introduction of “contaminant” Possible introduction of “contaminant” Likely re-engineering in Cleanroom format Likely re-engineering in Cleanroom format

Debate Advance process of software development Advance process of software development Theoretical foundation for SW development Theoretical foundation for SW developmentvs. Cleanroom is too radical for SW dev. Cleanroom is too radical for SW dev. Still too new and relatively unproven claims Still too new and relatively unproven claims

Conclusion Key Characteristics of Cleanroom SE Key Characteristics of Cleanroom SE Incremental Development Life Cycle Incremental Development Life Cycle Defect Prevention: Quality Assessment thru Statistical Testing Defect Prevention: Quality Assessment thru Statistical Testing Disciplined SE methods required to create correct, verifiable software Disciplined SE methods required to create correct, verifiable software

Resources 24/cr/clean/page1.html UTA 24/cr/clean/page1.html UTA 24/cr/clean/page1.html 24/cr/clean/page1.html php?keycode=64 DACS php?keycode=64 DACS php?keycode=64 php?keycode=64 NG623/Group/SENG623W03_Cleanroom. pdf Paper NG623/Group/SENG623W03_Cleanroom. pdf Paper NG623/Group/SENG623W03_Cleanroom. pdf NG623/Group/SENG623W03_Cleanroom. pdf