What are requirements for Cleanroom Software Engineering? What is the need for CSE?

The process got its name from the term cleanroom which is part of the process that fabricates the semiconductors. The basic ideology behind the cleanroom software engineering process is that it is more focused up on avoiding the defects rather than removing them.  It makes use of a combination software quality methods and formal methods. Cleanroom software engineering has shifted the individual craftsmanship to peer reviewed process, from sequential development to incremental one, from informal designing to discipline specification and designing, from informal coverage to statistical usage testing and so on.

Cleanroom software engineering is actually an integration of the following three practices:

1. Program verification
2. Software engineering modeling
3. Statistical software quality assurance

The correctness of the design specifications is verified via mathematically based proof solutions. The role of the statistical usage testing here is to dig out the high impact errors. 

The following the stages through the incremental development:

1.   Establishing the requirements

2.   Formal specifications

3.   Development of the increment

4.   Delivery of the software

5.   Requirements change request

Why Cleanroom Software Enginnering is required?

- Cleanroom software engineering is required to develop software systems and application with zero defects. 

- Though it takes a lot of time to be implemented but the payoff is quite high and both quality and productivity are increased. 

- The actual cleanroom process begins after the formal specification has been done. 

- The focus then shifts towards building a more explicit design. 

- Next, the design is verified as per the specifications. 

- Two things namely statistical and mathematical reasoning are combined and used together by the cleanroom approach for test generation and testing as well. 

- Cleanroom software engineering has proven to be the first practical attempt for developing the software with statistical quality control and delivering the software product with a known MTTF.

Requirements of Cleanroom Software Engineering

- The key requirements of cleanroom approach are nothing but specifications, requirements and verification methods.

- These formal specifications and verifications are used for developing software of high quality and with a minimum of errors. 

- Statistical usage testing is also required for the evaluation of the reliability of the software product. 

Cleanroom software engineering is followed by a number of benefits:

1. Zero failures: This is the objective itself and the software is developed with a minimum number of errors if zero not possible.
2. Short development cycles: These are the resultant of the incremental process. The rework is avoided and therefore new teams get a chance to experience productivity increase that has increased by two folds.
3. Longer product life: The product life is kept longer with the help of a usage model and investments detailed specifications.

- It is also a fact that the cleanroom techniques are not much used since some people believe them to be too mathematical, theoretical, radical etc. to be used in the real development processes. 

- Also, these techniques rely heavily on the statistical quality control and correctness verification rather than relying on unit testing. 

- This means that there is a large deviation from the traditional software development approach. 

- Proving the program is always there in the option list but it requires a lot of intensive sophisticate mathematical work. 

- Therefore, in place of this, cleanroom uses an alternative.

- A team code inspection is structured in terms of verification conditions and program functions.

-  Then an informal review is carried out which confirms whether or not all the verification conditions have been satisfied. 

What is Cleanroom Software Engineering?

Cleanroom software engineering is one of the fastest emerging software development processes and has been designed for the production of the software systems and applications with a reliability of certificate level. The credit for the development of this process goes to Harlan Mills and a couple of his colleagues among which one was Alan Hevner at the IBM Corporation. 

What is Cleanroom Software Engineering?

- The cleanroom software engineering is focused on defect prevention rather than their effective removal. 

- The process was named so since the word cleanroom evoked the sense of cleanrooms that are used by the electronics industry for preventing the defects from entering the semiconductors during the fabrication process. 

- The first time when the cleanroom process was used was in the late 80s. 

- This process began to be used for military demonstration process in the early 1990s. 

Principles of Cleanroom Approach

Cleanroom process has its own principles which we have discussed below:

1. Development of software systems and applications based up on formal methods: Box structure method is what that is used by the cleanroom development for specifying and designing a software product. Later, team review is used for carrying out verification of the design i.e., whether it has been correctly implemented or not.
2. Statistical quality control through incremental implementation: An iterative approach is followed in the cleanroom software engineering process i.e., the software system is evolved through increments in which the implemented functionality gradually increases. Pre–established standards are used for measuring the quality of all the increments for making verification that the process is making acceptable process. In case the process fails to meet the quality standards, testing of the current increment is stopped and the process is returned to the designing phase.
3. Statistically sound testing: Software testing in cleanroom development process is carried as a disguise of a statistical experiment. A subset that represents software’s i/p and o/p trajectories is selected and then subjected to testing. The sample so obtained is  then considered for statistical analyzation so as to get an estimation  of the software’s reliability and level of confidence.

Features of Cleanroom Software Engineering

Software products developed using the cleanroom software engineering process have zero defects at the delivery time. Below mentioned are some of the characteristics features of the cleanroom software engineering:

1. Statistical modeling
2. Usage scenarios
3. Incremental development and release
4. Separate acceptance testing
5. No requirement of unit testing and debugging
6. Formal reviews with verification conditions

The defects rate was recorded as follows:

1. <3 .5=".5" and="and" delivered="delivered" kloc="kloc" o:p="o:p" per="per">

2.7 Per KLOC between first execution and first delivery.

Basic technologies thus used can be listed as:

1. Incremental development: Each increment is carried out from end – to – end and in some cases there is overlapping development of the increments. This whole process takes around 12 – 18 weeks and partitioning though being critical proves to be difficult.
2. Function – theoretical verification: A parser may check the constructed program for syntax errors but it cannot be executed by the program developer. Verification conditions drive the team review for verification. Verification is improved by 3- 5 times than debugging. Formal inspections also fall under this category.
3. Formal specifications: This further includes:

a)    Box structured specification: It includes 3 types of boxes namely:

Ø  Black box

Ø  State box

Ø  Clear box

b)    Verification properties

c)    Program functions

4. Statistical usage testing: It helps in implementing cost effective orientation and process control. It provides a stratification mechanism to deal with situations that are critical. 

Cleanroom Testing - Statistical Use Testing and Certfication

Clean room testing is different from conventional testing approaches. The goal of clean room testing is to validate software requirements by demonstrating that a statistical sample of use-cases have been executed successfully.

Statistical use testing tests the software in a way the users intend to use it. the clean room testing teams determine the usage probability distribution or the software. Each increment's specification is analyzed to define a set of inputs or events that cause the software to change its behavior. A probability of use is assigned to each input or event based on the interviews with users, the creation of usage scenarios and a general understanding o application domain. The testing team executes these use cases and verifies software behavior against the specification for the system. Using the recorded interval times, the certification team can compute mean time to failure.

Within the clean room software engineering approach, certification implies that the reliability can be specified for each component. Reusable software components can be stored along with their usage scenarios, program stimuli, and probability distributions. The certification approach involves :
- usage scenarios must be created.
- usage profile is specified.
- test cases are generated from profile.
- tests are executed and failure data are recorded and analyzed.
- reliability is computed and certified.

Certification for clean room software engineering requires creation of three models:
- Sampling Model : Certification is given if no failure or a specified number of failures occur after executing m random test cases. The value of m is derived mathematically.
- Component Model : This model enables the analyst to determine the probability that component i will fail prior to completion.
- Certification Model : The overall reliability of the system is projected and certified.

The Cleanroom Strategy and Functional Specifications

The cleanroom approach makes use of a specialized version of the incremental process model. A pipeline of software increments is developed by small independent software teams. As each increment is certified, it is integrated into the whole. Hence, functionality of the system grows with time.

- Increment Planning : adopts the incremental strategy.
- Requirements Gathering : defines a description of customer level requirements (for each increment).
- Box Structure Specification : describes the functional specification.
- Formal Design : specifications (called “black boxes”) are iteratively refined (with an increment) to become analogous to architectural and procedural designs (called “state boxes” and “clear boxes,” respectively).
- Correctness Verification : verification begins with the highest level box structure (specification) and moves toward design detail and code using a set of “correctness questions.” If these do not demonstrate that the specification is correct, more formal (mathematical) methods for verification are used.
- Code Generation, Inspection and Verification : the box structure specifications, represented in a specialized language, are transmitted into the appropriate programming language.
- Statistical Test Planning : a suite of test cases that exercise of “probability distribution” of usage are planned and designed.
- Statistical Usage Testing : execute a series of tests derived from a statistical sample (the probability distribution noted above) of all possible program executions by all users from a targeted population.
- Certification : once verification, inspection and usage testing have been completed (and all errors are corrected) the increment is certified as ready for integration.

Functional Specifications :
Cleanroom Software engineering compiles with the operational analysis principles by using a method called box structure specification. A "box" encapsulates the system at some level of detail. Three types of boxes are used :
- Black box : It specifies a set of transition rules that describe the behavior of system components as responses to specific stimuli, makes use of inheritance in a manner similar to classes. It also specifies system function by mapping all possible stimulus histories to all possible responses.
S*->R i.e. stimulus history->responses
- State box : It is a generalization of a state machine, encapsulates the data and operations similar to an object, the inputs (stimuli) and outputs (responses) are represented, data that must be retained between transitions is encapsulated. The state is the encapsulation of the stimulus history. State variables are invented to save any stimuli that need to retained.
S x T -> R x T i.e. stimuli X state data -> responses X state data
- Clear box : It contains the procedural design of the state box, in a manner similar to structured programming. It specifies both data flow and control flow.
S x T -> R x T i.e. stimuli X state data -> responses X state data

BOX PRINCIPLES :
- Transaction closure of stimuli and responses
* Users and uses are considered including security and error recovery.
- State migration within box hierarchy
* Downward migration of state data is possible whenever new black boxes are created inside a clear box.
* Upward migration of state date is desirable when duplicate data is updated in several places in the tree.
- Common services
* Reusable boxes from library.