Clean Room SE

(1)

(2)

Question

 Is it possible to build software without any bug in it?

.

(3)

Causes for Bugs in Programs

 The main reasons for bugs in programs: * Design flaws

* Coding error

* Other (including human related error)

(4)

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

(5)

Cleanroom Software Engineering



CSE

yields software that is correct by

(6)

CSE: Characteristics

Objective: 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.

(7)

Comparison:

Craft-Based SE Cleanroom SE

Sequential 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

(8)

(9)

CSE: Management

Process

 _

Project Planning

 Cleanroom engineering guide

 Software development plan (incremental)

 _

Project Management

 Project record

 _

Performance Improvement

 Performance improvement plan

 _

Engineering Change

(10)

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

(11)

CSE: Specification Process

/2

 Usage Specification

 Identify and classify software users, usage scenarios, and environments of use

(operational modes).

 Architecture Specification

 Define the conceptual model, the

structural organization and the execution characteristics of the software.

(12)

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

(13)

(14)

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

(15)

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

(16)

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

(17)

Cleanroom Strategy /3

 _

Statistical use testing (SUT)

 _ Creating test case, execute them and collecting error

data.

 _

Certification (C)

 _{Conducting certification test to accept/reject developed} software components (using

(18)

Box Structure /1

Box structures are used to move from an abstract specification to

(19)

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

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

(20)

Example



_{Automated Teller Machine (}

_ATM

₎

 _{Requirements:}

(21)

(22)

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)

(23)

(24)

(25)

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

(26)

CSE: Evaluation

 Basic features of Cleanroom development

that

distinguishes it from other SE methodologies

are:

 Formal specification (Box structure).  Correctness verification.

(27)

Conclusion:

 Key Characteristics of Cleanroom SE

 Incremental Development Life Cycle.  Defect Prevention: Quality Assessment

through Statistical Testing.

 Disciplined SE methods required to create

(28)

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