By: David Golke

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

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

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

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

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

 Tagging

 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

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

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

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

 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.

 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

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

 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

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

 Must be correct  Mathematical verification  Statistical testing

 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”

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

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

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

 Prowell, Stacy J., Carmen J. Trammell, Richard C. Linger, and Jesse H. Poore. Cleanroom Software Engineering: Technology and Process. Reading, MA: Addison-Wesley, Print.  Becker, Shirley A., and James A. Whittaker. Cleanroom Software Engineering Practices. Harrisburg, PA: Idea Group Pub., Print.  Mills, Harlan D.; Dyer, M.; and Linger, R. C., "Cleanroom Software Engineering" (1987). The Harlan D. Mills Collection.  R. C. Linger "Cleanroom Software Engineering for Zero-Defect Software", Proc., 15th Int. Conf. on Software Eng., pp from f f  Garbett, S. P. (2003). Cleanroom software engineering. Dr.Dobb's Journal, 28(8), Retrieved from software-engineering/ software-engineering/