Cleanroom Software Engineering Getting it right the first time.

  • Published on

  • View

  • Download


<ul><li><p>Cleanroom Software EngineeringGetting it right the first time</p></li><li><p>A Spectrum of MethodsLess FormalMore FormalCleanroomOCL and ZTraditional Models:Waterfall, Spiral, IncrementalAgile Methods:FDD and SCRUM</p></li><li><p>Characteristics of Formal MethodsWell-defined specification languageTypically based on set-theoretical conceptsEmphasis on verificationOf program correctnessOf completeness of descriptionOf refinements to different abstractionsTesting/Debugging De-emphasizedProcess idea borrowed from manufacturingworth the cost to ensure process delivers acceptable products rather than remove defects to achieve quality</p></li><li><p>Why Use Cleanroom Process?ClaimsVerification and testing are synergisticReasoning faults are easier to find than debugging faultsTesting based on usage scenarios focuses on important errorsNot all faults are of equal significance Bottom Line: software developed under the cleanroom process has fewer errors</p></li><li><p>The Cleanroom ApproachBased on the Incremental Process Model with the twist that formal verification is applied to engineering models and the code.SubprocessesSystem Engineering, Requirements Gathering, Test Planning, Box Structure Specification, Formal Design, Correctness Verification, Code Generation, Code Inspection and Verification, Statistical Usage Testing, Certification</p></li><li><p>Additional Points of EmphasisWhy the cleanroom process is not widely used (pg 797)Stereotyped perception, departure from standard practice, and process maturityHow cleanroom differs from OO development (pg 800)Statistical QC, mathematical verification, usage-driven testing.Functional Specification Types (pg 801)Black Box (concerned only with I/O)State Box (similar to a UML class diagram)Clear Box (procedural design, e.g., pseudocode)</p></li></ul>


View more >