find and solve ||
Please wait.....

Overview of Clean Room Software Engineering

The Cleanroom approach (see Table 1.6) to software engineering was developed at IBM by Harlan Mills around 1982.

It uses a team-oriented model that focuses On enforcing the use of theoretically sound engineering processes and practices.

It has three foundations: incremental development. under statistical quality control; software development based on mathematical ­ principles; and software testing, based on statistical principles.

Its quality-control-driven philosophy is intended to improve the manageability and complete requirements leading to a significant reduction of risk.

The approach applies not only to newly developed systems but also to legacy environments by appropriately reengineering existing legacy) components.

Evolution of goalsFocus on accuracy, reliability, reducing ambiguity, incompleteness, inconsistency 
MethodologyMathematical transformation and statistical testing of usage profiles
TechnologyFacilitated by software automation
Critical factorSpecification language
Interdisciplinary effectsMathematical specification, statistical sampling, project management
Behavioral considerationsPeer-review teams
Problem natureComplex-systems
Application domainGeneral

The testing process in Cleanroom is intended to demonstrate the validity of the system under expected usage, rather than to detect and remove defects. First, a highly detailed usage profile or specification is defined; this serves as the basis for thorough random testing of the intermediate products with the final product therefore expected to represent a scientific level of quality certification.

In fact, the performance of the software on the tests is viewed as defining a statistical experiment in which a thorough set Of test cases [is] randomly generated from the usage model" (Oshana & Linger 1999). The test cases are selected to be a statistically representative sample of the system's expected usage, so the testing is arguably as reliable as any statistical sampling process.

This kind of sampling is a realistic approach, given that exhaustive testing is almost always computationally impossible because of the vast number of potential test cases.

The software components are viewed as defining mathematical functions in which the function domain is the set of possible input histories and the function range is the set of all correct outputs. The functions are described using different kinds of box structures.

In an object-oriented context, a so-called black box would correspond purely to the behavior of an object; a state box would correspond to the .object's" encapsulated data; and a clear box would correspond to the object's methods.

The specifications of system functions and their design decompositions are required to satisfy referential integrity, which means that the design and the specification correspond to the same mathematical function.

If referential integrity is satisfied, then the design is a provably correct implementation of the specification (Linger & Trammell 1996). The correctness is verified by the review teams by checking the correctness of the effects of individual control structures, an approach that turns out to be "remarkably effective in eliminating defects, and is a major factor in the quality improvements achieved" (Linger & Trammell 1996).

The Cleanroom Development Architecture comprises 14 processes and 20 work Products that ,in combination, implement the development technology (Mills, Dyer, & Linger 1987). Just to give a sense of What is involved in the development process these processes will be briefly mentioned.

• The Management Processes involve project planning; project management; performance improvement; and engineering change.

• The Specification Processes comprise requirements analysis; function specification; usage specification; architecture specification; and increment planning.

• The Development Processes consist of software reengineering; increment design; and correctness verification.

• The Certification Processes the usage modeling and test planning process and the statistical testing or certification process.

Linger and Trammell (1996) offers a detailed discussion of each Clean-room process and process element. Some highlights will be discussed briefly here.

• The performance improvement process is a reflection of the fact that the Cleanroom process structure is not static, but explicitly subjected to review and adjustment.

• In contrast, the engineering change process addresses modifications to the work product rather than the process. In collaboration with the customer, the requirements analysis process creates a software requirements document, which defines the system function, usage, and environment and obtains customer agreement.

• The function specification process transforms the requirements into a mathematically precise form and completely specifies possible customer usages.

The usage specification process identifies users and their usage scenarios and environments, as well as probability distributions for software usage. This can help prioritize development and facilitate

The architectural specification process defines the conceptual model for the architecture and spans the entire life cycle.

Increment planning is a process that supervises a revisable strategy for increment development.

The reengineering process adapts the system to reusable components possibly developed outside the Cleanroom framework. In such a case, The components are redesigned to Cleanroom standards, or the cleanroom software is protected from the preexisting components through what amount to ''firewalls."

As part of the increment design process, the development team develops an increment, although the certification team first executes the process

Using mathematical techniques, the development team performs correctness verification during team reviews to ensure that the software is a correct implementation of the specifications.

The usage and test planning process refines the usage models, defines the test plans, and statistically generates the test cases. In principle, the usage model allows an unlimited number of test cases, but only a finite sample is derived from the usage model on the basis of the usage probability distribution.

The statistical testing and certification process then statistically establishes the software's "fitness for use." Depending on the certification results, testing can, for example, be continued, and terminated or stopped to make engineering changes.

Like the Cleanroom Model, the Capability Maturity Model (CMM)..Represents a carefully disciplined approach to software development.

However, CMM focuses on the management of the entire development environment or process in a team or organizational context, emphasizing "process management and the principles and practices associated with software process maturity."

In contrast, the Cleanroom Model focuses on "rigorous engineering" and "enforces the mathematical basis of software development and the statistical basis of software testing" (Oshana & Linger 1999). In fact, these are issues from which the CMM prescinds precisely because it is intentionally "silent on the merits of various methods."

Nonetheless, although differently oriented, the Cleanroom and Capability Maturity models are compatible and even complementary.

Oshana and Linger observe that the key process areas of the CMM can be largely mapped to the activities in a Cleanroom environment. Thus, three of the six level-2 CMM key process areas (software project tracking and oversight, software project planning, and requirements management) are highly consistent with Cleanroom processes.

Five of the eight CMM level-3 process areas (peer reviews, intergroup communication, software product engineering, integrated software management, and training program) are closely consistent with Cleanroom activities.

Finally, the level-4 KPAs (software quality management and quantitative process management) and the CMM level-5 KPA of defect prevention are consistent with Cleanroom requirements.


The chapter started with the introduction to software engineering and then we discussed about the characteristics of the software development process. The various life-cycle models were discussed alo

Mahira  khanna

Mahira khanna

I have the skills you need for you company blog, website, or other content materials

If felt valuable to you, feel free to share it.


Report Response