CleanRoom Software Engineering

1. CleanRoom Software Engineering By Jonathon Fischer

2. Overview • What is Cleanroom SE • The Cleanroom process • Cleanroom results

3. Created by IBM in the early 80’s Named after cleanrooms used in Semiconductor Industry What is CleanRoom SE?

4. What is Cleanroom SE? (cont.) • Iterative 14 step process • Goal of 0 or near 0 errors • All errors account for by compile time • No Unit testing • Developers don’t compile the system.

5. 4 teams of Cleanroom SE • 4 teams • Management • Tracks progress and budget • Specification • Defines required functions and usage of system • Development • Creates the system • Certification Team • Tests the system against specifications

6. Cleanroom Flow

7. Project Planning Process • Adapt process model to project • Cleanroom Engineering Guide • Create project Plan • Software Development Plan • Review Plan with customer and team members

8. Project Management Process • Begins the Cleanroom process • Defines incremental development and certification • Measures for correctness testing defined

9. Project Improvement Process • Find ways to improve performance and facilitate changes • Create Performance Improvement Plan • Made prior to a change • Outline additional training for change • Revise Cleanroom Engineering Guide • Usually, changes started at milestones

10. Engineering Change Process • Make changes to the product • Faults or failures are found • Must be compliant with the Configuration Management Plan • Changes recorded in Engineering Change Log • Change evaluated for correctness and impact

11. Architecture Specification Process • Decomposes the project • Requirements and Specifications must be partially complete • Start at high level of abstraction and go lower • “Black box” to “Clear box” • Generate analysis models

12. Requirements Analysis Process • Started immediately after work order is received • Work with customers to determine • What the system does • How it will be used • Preferred Environment • Repeated each iteration or if requirements added • Most stable requirements implemented first

13. Function Specification Process • Determine unambiguous user scenarios regardless of probability of occurrence • Recorded in Function Specification Doc • Mathematically representation of reqs • Each spec linked to at least 1 req • Written in “Black box” style

14. Usage Specification Process • Determine info about the users • Type of user • User environment • Started when Functions Specifications is partially complete. • Provides a way to effectively allocate resources • Helps to complete and validate Function Specs.

15. Increment Planning Process • Create/revise Increment Construction Plan • Helps to determine • Elements to complete immediately • Elements to stub out and finish on a different iteration • Using incrementation allows for mistakes to be caught and fixed earlier.

16. Software Reengineering Process • Used when incorporating reused software • Prior to integration determine • Reliability of software • Benefits outweigh cost of integration • Integration can be done • As is • With a wrapper for limited access • Reengineered to better fit project

17. Incremental Design Process • Implements Incremental Construction Plan • Input code here! • Multiple reviews • Assess progress of current increment • Determine changes to keep verification and project maintainability • Goal: few faults as possible before Correctness Verification

18. Correctness Verification Process • Verifies the program will work to specifications without running the system • Uses proofs and mathematical methods for verification • Program structures broken down to mathematic equivalence • Correctness Verification is more effective and efficient than Unit testing • Can accurately predict almost infinite number of execution paths • Unit testing can only do so much

19. Usage Model and Test Planning Process • Usage model created from refined specs • Cover a broad range of modules • Especially ones where failure is unacceptable • Shows each state and transitions • Create Incremental Test Plan • Models and test Plan determine • Test cases • Testing environment

20. Statistical Testing and Certification Process • Final phase for each increment • Code is run for the first time. • Tests are performed according to Incremental Test Plan • Test results compared to function specs • Each result used to determine measurement of system for Certification • Failure => return to Incremental Design • Success => proceed according to Increment Construction Plan

21. First Cleanroom Project • IBM 1988 • Program automatically restructured COBOL code • Contained 33 KLOC • In first 3 years of use • 7 errors found • All were easy fixes.

22. NASA and Cleanroom SE • 1989: FORTRAN satellite controller • 40 KLOC, only 4.5 errors / 1KLOC • 40% increase in quality • 80% increase In productivity • 780 LOC per person month!! • Ave. embedded system 40 – 160 LOC/pm • Ave. commercial system 200 – 800 LOC/pm

23. Review • 14 step iterative process • Goal of 0 or near 0 errors • No Unit testing • Seems difficult, but can have amazing results

24. Questions ?

25. Sources • Hausler, P. A., & Linger, R. C. (1994). Adopting Cleanroom Software Engineering With a Phased Approach. IBM Systems Journal, Volume 33, Issue 1, p89. EBSCOhost. • Linger, R. C., & Trammell, C. J. (November 1996). Cleanroom Software Engineering Reference Model, Verison 1.0. found at: http://www.sei.cmu.edu/pub/documents/96.reports/pdf/tr022.96.pdf • Oshana, R. Quality Software Via a CleanRoom Methodology. Embedded Systems Programming. Found at: http://www.embedded.com/97/feat9609.htm • Steward, Donald V. (1987). Software Engineering with Systems Analysis and Design.Monterey, CA, Brooks/Cole Publishing Company. • Uta.edu. Cleanroom Sotware Engineering. Found at: http://www.uta.edu/cse/levine/fall99/cse5324/cr/clean/page.html