CLEANROOM SOFTWARE ENGINEERING

2. Question
• Is it possible to build software without any
bug in it?
. Answer: Maybe, By using Cleanroom software development.

3. 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)

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

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

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

7. 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.
Reduces Costs.

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

9. CSE: Processes
• 1. Management process.
• 2. Specification process.
• 3. Development process.
• 4. Certification process.

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

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

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

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

14. CSE: Development Process

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

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

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

18. 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).

19. Box Structure /1
Box structures are used to move from an abstract specification to
a detailed design providing implementation details.

20. 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).

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

22. Example: Usage Model

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

24. Example: State Box

25. Example: Clear Box Spec

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

27. CSE: Evaluation
• Basic features of Cleanroom development that
distinguishes it from other SE methodologies
are:
• Formal specification (Box structure).
• Correctness verification.
• Statistical certification test.

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

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

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

31. Resources
• http://www.uta.edu/cse/levine/fall99/cse5324/cr/clean/page
1.html UTA.
• http://www.dacs.dtic.mil/databases/url/key.php?keycode=64
DACS.
• http://www.criticaljunction.com/werbicki/SENG623/Group/SE
NG623W03_Cleanroom.pdf

32. Any Question ?
Thank you
for your
listening and viewing.