cleanroom montaser hamza iraq2016

CleanRoom Software Engineering

Montaser hamza MSC Student

University of ErciyesMontaser_hamza@yahoo.com

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.• far@ucalgary.ca 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.