Casey Ehlers April 28 th, 2011

Outline of Presentation 1. Background and History of Cleanroom 2. Who Uses Cleanroom Software Development? 3. Basics of Cleanroom Software Process 4. Analysis of the Cleanroom Process

What is a Cleanroom?

Cleanroom Nearly pollutant free environment used for scientific research and manufacturing. Some statistics on air pollutants: Pollutants (.5 micrometers or larger) in environment: 35,000,000 particles per cubic meter (urban) Pollutants (.5 micrometers or larger) in Cleanroom: 0 particles per cubic meter Pollutants (.3 micrometers or smaller) in Cleanroom: No more than 12 particles per cubic meter

What is the goal of Cleanrooms? Prevention! Errors and defects are not allowed into the system during it’s initial design and construction

Dr. Harland Mills IBM – mid ’80’s Took the goals of a hardware Cleanroom and applied them to the software design process. Mills wanted to prevent the entry of errors into software instead of just detecting them after they are designed. Published a paper in 87 on his new methodology and called it “Cleanroom Software Engineering”

Who Uses Cleanroom S.E.? Mission and Life-Critical Systems NASA and the Military are a few of the organizations who have reported using the Cleanroom process. Companies who are willing to trade-off efficiency for certifiable reliability. I will re-examine this comment later. Limited use otherwise. Too rigorous in a lot of cases.

Cleanroom In A Nutshell Cleanroom is an adaptation of the Incremental model. Increments are defined using formal methods which can be checked for correctness. Correctness Verification: Does the system do what it is designed to do? How the increment is designed and verified is what makes Cleanroom different from normal

Incremental Software Development

Cleanroom Software Development

Defining Increments Formal methods are used to rigorously define what the increment are suppose to do. From there, it is easy to verify that the specifications meet the designed result. Additional tests can be ran on the increments to produce “statistical quality control.” The results can be shown to the customer for approval or reworking.

Box Structure Programs regarded as rules or mathematical functions Maps specify how transformations take place from inputs to outputs Allows for easy verification. Scalable You can have a box structure for a whole software system, a specific class, or even a specific function or statement 3 Generally used box structures for Cleanroom

Box Structure - Black Input, and history needed to for transition to occur. Transition function: ((current stimulus, current history)  response ) Example of Black Box: Calculator Function Identical input could yield different responses based on current history of the system.

Box Structure - State History and current state of system needed to be transitioned into a response and a new state. Transition Function: ((current stimulus, current state)  (response, new state))

Box Structure - Clear Derived from State Box Same transition function, but each transition is specified by a procedure. Transition Function: ((current stimulus, current state)  (response, new state)) by procedure

Box Structure Applied to OO Assume any Object-Oriented system Decomposition strategy of Box Structures when designing increments: Black Box- specifies behavior of an object State Box – specifies data encapsulation Clear Box – procedures and methods

Design Example Page 66 of Dyer A program that determines the type of triangle based on inputs 3 inputs 4 outcomes: equilateral, scalene, isosceles, not a triangle Box terminology not used, but design is close to a clear- box

Correctness Verification Basic Steps to Software Verification: 1. Specify the function (or increment) 2. Select the design construct (pseudo-code) 3. Use a correctness proof to show equivalence 4. Decide next step based on results: Rework/Reiterate the increment Proceed to next function or increment

Correctness Proof What questions do we ask to proof that a function is correct? Step through the increment and prove correctness of each construct (if, for, while, etc) Page 88, Dyer How can we verify the correctness of the triangle solver? Page 93-95, Dyer

Testing an Increment Results of correctness proofs offer statistical certainty that the system is doing what it was designed to do. Results can be show percent correct and percent covered. These results are really easy to report to a customer for feedback Page 137, Dyer

Additional Usage Testing Path-Based Testing Structured Path Testing limits unnecessary based by used a specified set of inputs. Boundary and loop Testing Linear Code Sequence/Jump Testing Similar to using a debugger. Statements are broken down into sequences which then can be stepped through and tested for defects.

Evaluation of Cleanroom Rigorous! Look at the example of the triangle solver. Imagine using this process one your senior project… Effective Statistically proven to increase software reliability

“Pro’s” of Cleanroom Reliability Current reports claim that Cleanroom increases quality of software around times. Greater Quality  Higher profit margins Happier users One study reports: 90 percent of defects were found BEFORE testing phase of incremental development (1,000 – 50,000 L.o.C. systems)

“Pro’s” continued… Efficiency??? How can a process that is so intense and rigorous yield better efficiency? Less ambiguity on design Less time spent testing and re-engineering We know that testing is one of the most time consuming and expensive parts of software development. With fewer defects entering the testing phase, less time is spent in this phase. NASA reported a 4.6 productivity increase

“Con’s” of Cleanroom Unnecessary a lot of the times. Traditional methods of software develop are a lot of the times sufficient or more logical. Training Everyone of the development team needs to be formally trained in the Cleanroom method. What if the design is wrong? Cleanroom seems to imply that the formal and usage specifications are designed correctly…

Summary Cleanroom: Rigorous and thorough modification of the incremental software process. Offers certifiable reliable software with minimum defects Requires training and unnecessary in the majority of design scenarios

Resources [1] Michael Dyer. (1992) The Cleanroom Approach To Quality Software Development New York, NY: John Wiley & sons [2] Richard C. Linger and Carmen J. Trimmell (1996) Cleanroom Software Engineering Reference ModelVersion 1.0 Pittsburgh, PN [3] Roger S. Pressmen (1992) Software Engineering: A Practitioner’s Approach (3 rd Edition) New York, NY: McGraw-Hill Inc [4] Shawn P. Garbett (2003) Cleanroom Software Engineering Retrieved from [5] Chaelynne M. Wolak (2001) Taking the Art out of Software Development: An In Depth Review of Cleanroom Software Engineering Retrieved From