1. By: David Golke

2.  Introduction  Architecture Specification ◦ Requirements Analysis ◦ Function Specification ◦ Usage Specification ◦ Increment Planning

3.  Architecture Specification ◦ Software Reengineering, Increment Design, Correctness Verification ◦ Usage Modeling and Test Planning ◦ Statistical Testing and Certification  Examples Projects  Conclusion  Questions?

4.  Harlan Mills and colleagues from IBM  Where does the name come from?  Defect prevention  Quality Control

6.  Figure out what the customer wants  As usual, subject to change  We need requirements laid out in a way for future defect prevention

7.  Break down requirements (easily verifiable)  Tagging  Used in later steps ◦ With Box Structure Method ◦ For Function and Usage Specification ◦ For Increment Planning

8.  Tagging

9.  Both come directly after Requirements Analysis  How the system will function  How the users will interact with the system ◦ Who are users ◦ Different environments ◦ Usage scenarios

10.  Box Structure Development Method ◦ Black box ◦ State box ◦ Clear box  Differ from ◦ Black box ◦ Grey box ◦ White box

11.  Stimuli  Response  Keep track of all previous input/stimuli  Also subject to change throughout the project  Product: “Function Specification Document”

12.  Created from tagged requirements and Function Specification ◦ Aren’t these concurrent?  Used to make sure Function Specification is complete and accurate.

13.  Uses ◦ How much testing needs to be done ◦ Analyzing probabilities of failures ◦ How many resources are needed ◦ Along with Function Specification will later be used to determine probabilities of failure.

14.  Released in pieces  Must plan how “pieces” are released  “Increment Construction Plan” ◦ Subject to change  Once again uses previously produced documents to produce this document

15.  Subject to change (as always)  Uses of increments ◦ Identify failures ◦ form final product  Increments are made from previously discussed box structures

17.  Reusing old code ◦ Must meet cleanroom requirements  Was it developed using cleanroom?  Must get it certified  How much will this cost?  Figure out functionality ◦ create new reengineered software to our needs

18.  Follow through of the plan from Increment Specification  Use plan to produce design and code  Use Increment Construction Plan to do this

19.  Must be correct  Mathematical verification  Statistical testing

20.  Used together with Test Planning  Usage model ◦ Set up every possible way the program can be used ◦ Reason for input/stimuli/usage history ◦ Determine all possible “usages”

21.  Uses usage model  Must be able to produce statistics  This along with Usage Modeling will be used later for testing and certification

22.  Depends on previous correctness  Final step  Certification may be different in different cases/projects  Makes use of documents created in previous steps

24.  Unique software practice  Build off of previous steps  Must maintain correctness throughout steps  Probably only used when the system cannot afford failures/defects

26.  Prowell, Stacy J., Carmen J. Trammell, Richard C. Linger, and Jesse H. Poore. Cleanroom Software Engineering: Technology and Process. Reading, MA: Addison-Wesley, 1999. Print.  Becker, Shirley A., and James A. Whittaker. Cleanroom Software Engineering Practices. Harrisburg, PA: Idea Group Pub., 1997. Print.  Mills, Harlan D.; Dyer, M.; and Linger, R. C., "Cleanroom Software Engineering" (1987). The Harlan D. Mills Collection. http://trace.tennessee.edu/utk_harlan/18 http://trace.tennessee.edu/utk_harlan/18  R. C. Linger "Cleanroom Software Engineering for Zero-Defect Software", Proc., 15th Int. Conf. on Software Eng., pp.2 -13 1993 from http://cs.txstate.edu/~rp31/papersSP/LingerCleanroom1993.pd f http://cs.txstate.edu/~rp31/papersSP/LingerCleanroom1993.pd f  Garbett, S. P. (2003). Cleanroom software engineering. Dr.Dobb's Journal, 28(8), 24-28. Retrieved from http://www.drdobbs.com/architecture-and-design/cleanroom- software-engineering/184405405 http://www.drdobbs.com/architecture-and-design/cleanroom- software-engineering/184405405