cleanroom montaser hamza iraq2016
TRANSCRIPT
Question
• Is it possible to build software without any bug in it?
. Answer: Maybe, By using Cleanroom software development.
Causes for Bugs in Programs
• The main reasons for bugs in programs: * Design flaws. * Coding error. * Other (including human related error). human oriented (as he said dr.celal)
Cleanroom Software Engineering CSE: History- 1983: Original idea of Cleanroom came from one of Dr. Harlan Mills’ published papers.- 1987: Proposed by Dr. Mills as a SE methodology. The name “Cleanroom” was borrowed from the electronics industry- 1988: Defense Advanced Research Projects Agency (DARPA) Software Technology for Adaptable Reliable Systems (STARS) focus on Cleanroom.- 1991-1992: Prototyping of Cleanroom Process Guide- 1992: A book of CSE published, foundation of CSE- 1992-1993: Army and Air Force Demonstration of Cleanroom
Technology.- 1993-1994: Prototyping of Cleanroom tools- 1995: Commercialization of a Cleanroom Certification Tool-1995: Cleanroom and CMM (Capability Maturity Model) Consistency Review
Cleanroom Software Engineering
Cleanroom software engineering (CSE) is an engineering process for the development of high quality software with certified reliability with the emphasis on design with no defects and test based on software reliability engineering concepts.
• CSE focuses on defect prevention instead of defect correction, and certification of reliability for the
intended environment of use.
Cleanroom Software Engineering
• CSE yields software that is correct by mathematically sound design, and software that is certified by statistically valid testing.
• CSE represents a paradigm shift from traditional, craft-based SE practices to rigorous, engineering-based practices.
CSE: CharacteristicsObjective: Achieve zero defects with certified reliability.Focus: Defect prevention rather than defect correction.Process: Incremental (short) development cycles; long product life.Quality.Most suitable for critical applications.Increased Productivity.Reduces Costs.
Comparison:Craft-Based SE Cleanroom SE
Sequential or chaos development Incremental development
Informal design Disciplined engineering specification and design
Unknown reliability Measured reliability
Individual development Peer reviewed engineering
Individual unit testing Team correctness verification
Informal load or coverage testing Statistical usage testing
CSE: Processes• 1. Management process.• 2. Specification process.• 3. Development process.• 4. Certification process.
CSE: Management Process• Project Planning Cleanroom engineering guide Software development plan (incremental)• Project Management Project record• Performance Improvement Performance improvement plan• Engineering Change Engineering change log
CSE: Specification Process /1
• Requirements Analysis• Elicitation(deriving) and analysis of requirements• Define requirements for the software product• Obtain agreement with the customer on the
requirements.• Function Specification• Base on the result of Requirements Analysis
Specify the complete functional behavior of the software in all possible modes of use.
CSE: Specification Process /2• Usage Specification• Identify and classify software users, usage scenarios, and environments of use (operational modes).• Establish and analyze the probability distribution for software usage models.• Architecture Specification• Define the conceptual model, the structural organization, and the execution characteristics of the software.• Architecture definition is a multi-level activity that spans the life cycle.
CSE: Specification Process /3
• Increment Planning• Allocate customer requirements defined in the Function Specification to a series of software increments that satisfy the Software Architecture,• Define schedule and resource allocations for increment development and certification• Obtain agreement with the customer on the increment plan
CSE: Development Process
CSE: Certification Process • Usage modeling and test planning• A usage model represents a possible usage scenario of the
software• Usage model is based on usage specification and is used for
testing• Statistical Testing and Certification• Testing is conducted in a formal statistical design under
experimental control.• Management decisions on continuation of testing and certification of the software are based on statistical estimates of software quality.
Cleanroom Strategy /1
• Requirement gathering (RG)• A detailed description of customer level requirements for each increment.• Box structure specification (BSS)• Functional specification using box structure to separate behavior, data and procedures.• Formal design (FD) Specifications (black boxes) are refined to become analogous to architectural (state boxes) and procedural (clear boxes) design.
Cleanroom Strategy /2• Correctness verification (CV)• A set of correctness verification activities on the design and
moves later to code. First level verification is via application of a set of “correctness questions”.
• Code generation, inspection & verification (CG &CI) The box structure transformed to a programming language. Walkthrough and code inspection techniques are used to ensure semantic conformance with the box structure.
Cleanroom Strategy /3
• Statistical test planning (TP)• Planning the test based on operational modes, operational profiles and reliability.• Statistical use testing (SUT)• Creating test case, execute them and collecting error data.• Certification (C)• Conducting certification test rather than reliability growth to accept/reject developed software components (using reliability demonstration chart, etc).
Box Structure /1 Box structures are used to move from an abstract specification to
a detailed design providing implementation details.
Box Structure /2
Black box Specifies the behavior of a system or a part of a system. The system responds to specific stimuli (events) by applying a set
of transition rules that map the stimuli to response. (specifications ).
State box Encapsulates state data and services (operations). Input to the
state box and outputs are represented. (architectural designs).
Clear box Transition function that are implied by the state box. It contains
the procedural design of the state box. (component designs).
Example• Automated Teller Machine (ATM)
• Requirements:• The customer has a PIN number and access-card to use the ATM.• The customer can deposit, withdraw money from the account.• Transaction involves no bank employee.
Example: Usage Model
Example: Black Boxes• Black boxes• Card Processor• In: ValidCard(cardNum)• Out: showMessage(message) Boolean• Cash Dispenser• In: enoughCashInMachine(amount) dispenseCash(amount)• Out: showMessage(message) dispense(amount) Boolean• Transaction Manager• In: ValidCustomer(cardNum, pin) AmountLimit(amount) EnoughCashInAccount(amount)• Out: showMessage(message) Boolean
Example: State Box
Example: Clear Box Spec
CSE: Team• Specification team:• Responsible for developing and maintaining the system
specification.• Development team:• Responsible for developing and verifying the software.• The software is not executed during this process.• Certification team:• Responsible for developing a set of statistical tests to
exercise the software after development.• Use reliability growth models to assess reliability.
CSE: Evaluation
• Basic features of Cleanroom development that distinguishes it from other SE methodologies are:• Formal specification (Box structure).• Correctness verification.• Statistical certification test.
Conclusion:
• Key Characteristics of Cleanroom SE– Incremental Development Life Cycle.– Defect Prevention: Quality Assessment thru
Statistical Testing.– Disciplined SE methods required to create correct,
verifiable software.
Conclusion:
• Cleanroom approach is a rigorous approach to software engineering that has emphasis on:• Formal specification.• Mathematical verification of correctness of design.• Certification of software reliability.• Cleanroom approach is yet to become a common
practice in software development industry because of emphasis on the above three points.
Resources• Linger, R. and Trammel, C. (1996). Cleanroom.• Software Engineering Reference Model Version 1.0.• http://www.sei.cmu.edu/pub/documents/96.reports/pdf/tr022.• 96.pdf• Wolack, C. (2001). Taking The Art Out of Software• Development – An In-Depth Review of Cleanroom.• Software Engineering.• http://www.scisstudyguides.addr.com/papers/cwdiss725paper• 1.htm• Pressmen and Associates (2000). Cleanroom.• Engineering Resources.• [email protected] 83• http://www.rspa.com/spi/cleanroom.html
Resources• http://www.uta.edu/cse/levine/fall99/cse5324/cr/clean/
page1.html UTA.• http://www.dacs.dtic.mil/databases/url/key.php?keycode=64
DACS.• http://www.criticaljunction.com/werbicki/SENG623/Group/
SENG623W03_Cleanroom.pdf
Any Question ?
Thank you for your
listening and viewing.