CLEAN ROOM SOFTWARE ENGINEERINGCSC-532

(Srinivasa Yanaparti)

Abstract:

Clean room software engineering (CSE) is a process model that removes defects before they can precipitate serious hazards .It is a team-oriented, theory based software, which is developed using the formal methods, correctness verification and Statistical Quality Assurance (SQA). Clean room management is based on the incremental model of software development, which accumulates into the final product. The approach combines mathematical-based methods of software specification, design and correctness verification with statistical, usage-based testing to certify software fitness for use. The main goal of clean room engineering is to produce zero error-based software by allowing correct designs, which avoid rework. In this paper we will discuss the Cleanroom software Engineering process and describe the various processes involved in it.

1. Introduction: Clean room engineering is an approach that emphasizes the need to build the

correctness into software as it is being deployed. It goes against the traditional approach of software engineering, which is based on analyzing, design, code, and test and debug cycle [1].

“The philosophy behind clean room engineering is to avoid dependence on cost defect removal processes by writing code increments right the first time and verifying there correctness before testing. Its process model incorporates the statistical quality verification of code increments as they accumulate into a system.” [2]

Clean room process emphasizes rigor in specification and design, and formal verification of each element of the resultant design model using correctness proofs that are mathematically based, like any other formal Software engineering process. Extending the approach taken in formal methods, the Cleanroom approach also emphasizes techniques for statistical quality control, including testing that is based on the anticipated use of the software by customers [1].

2. Clean room Process Flow:

The three management processes affect all Cleanroom operations, and are shown across the top. Likewise, the Architecture Specification spans the entire life cycle. The Requirements Analysis Process, Function Specification Process and Increment Planning Process may be revisited to validate requirements and incorporate feedback from customer assessment of prior increments, prior to development and certification of each increment.

3. Clean room Management process:

3.1 Project Planning:The main objective of this process is to ensure the software engineering processes

are tailored for the project and they are well documented. This also ensures that project plan is well documented and defined [4]. Another important objective is to ensure that the customer, the project team and the peer groups agree to the review plans [3].

The inputs required for this process of software engineering are the Cleanroom Engineering Guide and the Software Development plan. Software manager, chief specification engineer, the peer organizations and the customer himself carry out project planning process.

3.2. Project Management Process:

The main objective of the project management process is to manage the project which is implemented using cleanroom to deliver the software on schedule and within the budget. To establish and train Cleanroom teams, initiate tracking, control planned Cleanroom processes, eliminate or reduce risks, revise plans as necessary to accommodate changes and actual results, and continually improve Cleanroom team performance [3].

The main people who are involved in the project management process are the project manager, development team, certification team, peer organizations and the customer. The inputs that are required for the software management process are the agreement of the customer, the review groups and the project members on the software Development Plan and The Cleanroom Engineering Guide. All the project works must be available for use in the process as they are being developed.

3.3. Performance Improvement Process:

The main objectives of the performance improvement process is to continually evaluate and improve team performance by causal analysis of deviations from plans and faults found through the Correctness Verification and the Statistical Testing and Certification processes and evaluation and introduction of appropriate new technologies and processes [3]. The main participants who are involved in this process are the project software manager, specification team, development team and the certification team.

The following are the tasks to be performed in the performance improvement process [4]:

1. To evaluate the cleanroom team performance and develop some improvements plans to increase the team’s performance.

2. Evaluate new technologies and processes and develop implementation plans for implementing the new technologies.

4. Clean room Specification Process

4.1 Requirement Analysis Process

The main objective of the Requirement Analysis Process is to define requirements for the software product that include function, usage, environment, and performance as well as to obtain agreement with the customer on the requirements as the basis for function and usage specification. Requirements analysis may identify opportunities to simplify the customer’s initial product concept and to show the requirements that the customer has not addressed [3].

The participants in the requirement analysis process are Specification team and the customer. The main inputs for the requirement analysis process are when the statement of work or any other initial artifacts is available, or whenever some changes are to be incorporated to the software requirements, or whenever a completed version of the software is ready for execution and evaluation [4].

4.2 Functional Specification Process

To make sure the requirement behavior of the software in all possible circumstances of use is defined and documented. The function specification is complete,

consistent, correct, and traceable to the software requirements. The customer agrees with the functional specification as the basis for software development and certification. This process is to express the requirements in a mathematically precise, complete, and consistent form. [3]. the main participants in the functional specification process are the specification team and the customer [4].

The following are the different tasks to be performed in the functional specification process [4]:

1. We must clearly define the format of the functional specification.2. The software boundaries and stimuli and their response interfaces with the

hardware must be defined clearly. All the software boundaries and external stimuli should be very well documented in the Functional Specification.

3. The external behavior of the software in the black box function form of stimulus and the history mappings must be clearly specified.

4.3 Usage Specification Process:

The main objective of the usage specification process is to identify and classify software users, usage scenarios, and environments of use, to establish and analyze the highest level structure and probability distribution for software usage models, and to obtain agreement with the customer on the specified usage as the basis for software certification [3].

The members of the Usage Specification Process are the Specification team and the customer. The process of Usage Specification begins when the input to it is either the Software Requirements or the Functional Specification have been partially or fully completed. The second case is when the input is The Usage Specification requires some changes to the Software Requirements or Function Specification or may be the development process or the certification process [4]. The Usage Specification must be reviewed with the customer, the certification team and the affected peer groups and they must come to a common agreement.

4.4 Architecture Specification Process:

The main objective of the architecture specification is to define the 3 key dimensions of architecture: Conceptual architecture, module architecture and execution architecture. The Cleanroom aspect of architecture specification is in decomposition of the history-based black box Function Specification into state-based state box and procedure-based clear box descriptions. It is the beginning of a referentially transparent decomposition of the function specification into a box structure hierarchy, and will be used during increment development [3].

The main members involved in the architectural specification are the Specification team, the Design team and the customer. This process begins when any one of the following is available as input to the function. When the Software Requirement and the Functional Specification are partially completed or when the Software Architecture requires changes in the Software Requirement or the Functional Specification.

4.5 Incremental Planning Process.

The main objective of Incremental Planning Process is to allocate customer requirements defined in the Function specification to a series of software increments that satisfy the Software Architecture, and to define schedule and resource allocations for increment development and certification. In the incremental process, a software system grows from initial to final form through a series of increments that implement user function, execute in the system environment, and accumulate into the final system [3].

The main participants in the incremental planning process are the Specification team, Chief development engineer, chief certification engineer, project manager and the customer. This process begins when The Software Requirements, Function Specification, Usage Specification, Software Architecture, Reuse Analysis Plan, Risk Analysis Plan, and Schedule and Resource Plan are partially or fully completed or when The Increment Construction Plan requires revision for changes or development.

5. Clean room Development Processes5.1. Software Reengineering Process:

Main objective of this process is to make sure that the reengineered software satisfies requirements for the software product in which it is used [4]. Reengineering allows intellectual over the reengineered software. This process of Software Reengineering is carried out by development, specification and certification teams [4]. Reused software can originate in Cleanroom or non-Cleanroom environments [3].

Reused software must satisfy two requirements: The functional semantics and interface syntax of the reused software must be

understood and documented, and if incomplete, can be recovered through function abstraction and correctness verification.

The certification goals for the project must be achieved by determining the fitness for use of the reused software through usage models and statistical testing.

Reused software and its supporting documentation are used as the basis for creating the Reengineered software. The Software Requirements, Function Specification, Usage specification, Software Architecture, and Increment Construction Plan are used to define requirements for reengineering reused software.

The exit criterion for this process is, the Reengineered software has been completed abstraction of functional semantics and certification of fitness for use.

5.2 Increment Design Process:

Main objective of this process is to design and code a software increment that conforms to Cleanroom design principles [3]. The software increment must satisfy the Increment Construction Plan, Function Specification, and Software Architecture. The development team documents each increment in the Increment Design [4].

This process of Increment Design is carried out by Development team, with specification team available for consultation and review [4]. The Development team does not execute the increment implementation. Increments are designed and implemented as usage hierarchies through box structure decomposition. Increment designs can be expressed in object, functional, or other forms.

Increment specifications are expressed in stimulus history-based black box and state-based state box forms. Increment designs and implementations are expressed in procedure based clear box forms that can introduce new black boxes for further decomposition. Team reviews during the Increment Design Process focus on issues such as clarity, maintainability, reuse, and conformance to style.

5.3. Correctness Verification Process:

Main objective of this process is to verify the correctness of a software increment using mathematically based techniques [3], to enter testing with no faults in the implemented design. Correctness verification is carried out in development team reviews using function-theoretic reasoning. Faults and inadequacies found in correctness verification are documented to permit subsequent analysis for process improvement.

Correctness Verification Process is carried out by Development team, with specification team available for consultation [4].

The Correctness Verification Process is concurrent with the Increment Design Process. Correctness Verification is the last intellectual pass at each level of decomposition, the last line of defense against failures in statistical testing and certification [4].

6. Clean room Certification Processes6.1. Usage Modeling and Test Planning Process:

The process of Usage Modeling and Certification is done by Certification team and customer, with specification team available for consultation and review. In this process, valid usage models are defined, which represent all possible uses of the software under expected or other usage conditions and also a statistical testing plan based on the usage models is defined and validated through model analysis and simulation.

The tasks that are performed under this process are [4]: Define the usage models to be developed Define the structure of each usage model Define the transition probabilities of each usage model Validate the usage models Develop a plan for certification testing of the software increment. Document testing

plans in the Increment Test Plan. Generate the statistical test cases, that are to be used in statistical testing

Prepare the statistical testing environment

When the Increment Test Plan and Usage Models have been completed and agreed by the customer as the basis for software certification, the next process of Statistical Testing and Certification starts.

6.2. Statistical Testing and Certification Process:

The main goal of this process is to derive statistically valid estimates of the properties addressed by the certification goals, for the software. Management decisions on continuing of testing and certification of the software are based on statistical estimates of software quality [4].

This is where the software’s fitness for use (defined with respect to the usage models and certification goals) is demonstrated in a format statistical experiment [3]. The certification goals may be expressed in terms of software reliability, reliability growth rate, and coverage of the usage defined in the usage models [4]. Software increments undergo first execution in this process. The success or failure of test cases is determined by comparison of actual software behavior with the required behavior [3].

Failures found in the statistical testing are documented in the Statistical Testing Report. Evaluations and decisions regarding product quality and process control are documented in the Increment Certification Report. Certification team, Development team, and Project Software Manager are the main participants in this process.

Advantages of CSE: 

CSE has three main advantages. 1. Improve quality, 2. Increase productivity3. Improve software maintainability.

Disadvantages of CSE:

First, there is the belief that CSE is too theoretical, too mathematical, and just plain too radical for software development. Even the correctness proof portion of CSE can be difficult and time consuming especially for non-safety-critical programs [8].CSE does require incremental development, the use of box structures for well-defined specifications, and statistical testing for verification. CSE use requires intensive training.

Second, unit testing is not part of the CSE process. Denying the programmer access to the compiler is unrealistic and can be counterproductive. This is especially true if the programmer does not even know the language or environment, when the software program is started [8].

There is the belief that the software industry is still in its infancy to incorporate such a rigorous process as CSE [3]. The software development paradigm must change from one of art to one of science. In many engineering disciplines, failures are not an

option and definitely are not considered the norm. In order to implement CSE successfully, one must not only have formal training but commitment from management.

Conclusion:

Defect prevention is more cost effective than defect removal. Therefore, in software development, the CSE methodology uses controlled and measurable statistics to eliminate or avoid as many defects as possible before software execution. Cleanroom supports prototyping, object orientation and reuse. Cleanroom can be applied to new systems as well as existing systems. For example, poor quality sections of software in existing systems can be re-engineered using certain Cleanroom techniques such as formal correctness verification.

References:

[1] Roger S. PressMan – “Software Engineering – A Practitioner’s Approach (4/e).”.[2] Linger, R., “Cleanroom Process Model”, IEEE Software, March 1994, pp. 50-58.[3] Harish Ananthpadmanabhan, Chetan Kale, Mujtaba Khambatti, Ying Jin, Shaun Taufiq Usman, Shu Zhang – “Cleanroom Software Development”, Arizona State University.[4] Richard C. Linger, Carmen J. Trammell – “Cleanroom Software Engineering Reference Model, Version 1.0”, November 1996.[5] Kelly, D. P., & Oshana, R. S. (1996, November). “Integrating Cleanroom Software Methods Into an SEI Level 4-5 Program.” U.S. Air Force's Software Technology Support Center. [6] Stavely, A. M. (1999, March 22-24). “High-Quality Software Through Semiformal Specification and Verification.” Paper presented at the 12th Conference on Software Engineering Education and Training, New Orleans, Louisiana.[7] Head, G. E. (1994, June 1). “Six-sigma Software Using Cleanroom Software Engineering Techniques.” Electric Library: Hewlett-Packard Journal.[8] Deck, M. (1997, May 27-30). “Cleanroom Software Engineering Myths and Realities.” Paper presented at the Quality Week, San Francisco, CA.[9] Deck, M. (1994, October). “Cleanroom Software Engineering: Quality Improvement and Cost Reduction”. Paper presented at the Proc. 12th Pacific Northwest Software Quality Conference.[10] Henderson, J. (1995, May). “Why Isn't Cleanroom the Universal Software Development Methodology?” U.S. Air Force's Software Technology Support Center.[11] Richard C. Linger, “Cleanroom Software Engineering for Zero-Defect Software”, IBM Cleanroom Software Technology Center.[12] Foreman, J. (1997, October 27). “Cleanroom Software Engineering: Software Technology Review.” Carnegie Mellon Software Engineering Institute