Cleam Room Software Engineering A developer perspective approch

Manoj Chander

Electrical Engineering

Drexel University

Philadelphia, USA

mt823@drexel.edu

Abstract—the objective of the paper is about cleanroom

software engineering, the series of procedures which need to be

followed to develop a life critical reliable system which is error

free in the real time working environment. The error free

condition is achieved through following a certain number

methods such as the incremental implementation procedure,

formal methods of verification and certification of the software

with the standardized quality conformance at each and every

step of the implementation. The process is done iteratively in

order to achieve the zero state error with increase in the

functionality of the system in each and every step.

Keywords—Clean room software engineering; iterative

methods; zero error state

I. CLEAN ROOM SOFTWARE ENGINEERING

The clean room software engineering is a standardized process of developing a dependable software system which fulfills the specifications of a customer with the life critical reliability system. The system history dates back to the time of 1990’s where the professor from Florida institute of technology named Harlan.D.mills with some a bunch of his colleagues started experimenting about the development of a dependable software system on a reliable method in the IBM research laboratories .

Professor Harlan with his team came up with an idea of clean room software engineering which was originally been followed in the fabrication of the semi-conductor chips to maintain a level of purity during the fabrication in order to avoid the defective outputs during the working conditions.

The same ideology was been adopted by the team led by the professor in the software development to produce a reliable piece of software which has zero defects or almost during the run time environment. The team came up with a set of rules to be followed in order to produce a defect free software which are as follows

For each and every system being developed there are different stages of quality conformance and specification correctness needed to be achieved in order to be advanced to the next iteration of the development life cycle to implement more features and integrate them to the new functions

developed. To achieve this, the development has to undergo many certification tests to imply the reliability of the system.The different stages present in the development of the system are (1) software development life cycle (2) System specification & requirement gathering (3) Correctness verification of the system using formal method.

II. SOFTWARE DEVELOPMENT LIFE CYCLE

The software development life cycle starts with the basic functions of the system to be implemented on the basis of the customer specifications. The development team and the customers get in agreement with the documented specifications and functionality of the system.

The initial development process such as the coding and implementation in the working environment is done for the function. The verification is done using the formal methods of mathematical verification.

In this type of verification the system functions are converted into a form of a mathematical design in which the manual verification of the each and every function is done in order to verify the function is in conformance with the function of the system.

This method might seem to be not efficient in a large complex function implementation but the efficiency of testing and finding the bugs in the code is much more than 90 percent of that of the standard testing procedures of the code.

This helps to reduce the run time errors in the system to a great extent and at the same time in accordance to the customer needs. This type of certification is needed at each and every step of the process in the clean room environment cycle.

Incremental life cycle :

The next stage of the software development life cycle is the incremental plan where the system with the basic function with the quality conformance certification is used to implement the next proposed function of the system. The same step of iterative development is done to implement in the system and integration with the already existing system is done. For each

and every function desired to be in the system is implemented by using the incremental life cycle following the iterative step and quality conformance after every function implementation. .

III. SYSTEM SPECIFICATION AND REQUIREMENTS

Before the onset of every project the project manager and client have several meeting to understand the needs of the customer and the exact expectation from the system is needed called as the system requirement specification(SRS). This is done in order to check whether the development team of the project is on track with the functions of the software.

The detailing is done in the resolution to which both the physical and technical specifications of the system’s working environment are mentioned. The systems failure due to the environmental physical aspects will seek the maximum attention as these system are developed to work under extreme operational conditions. The technical aspects of the systems must also be specified such as the minimum system configurations required to support the system being developed. A stand-by system is always present as back up in the case of the primary system fails.

IV.CORRECTNESS VERFICATION OF SYSTEM

The crucial step in any software development cycle is the verification of the system to check whether the desired output functions are developed for the system. In the clean room software development instead of the traditional path verification where the testing is done by tracing through the different paths of the program. In the real world scenario for any more than a complex code been structured in such a way that it has infinite number of paths for single function, in order to avoid any paths been missed during the testing of the system we follow the formal methods using the mathematical correctness of the system.

For all the functions been developed in the system are converted into a mathematical function and these functions are human verified for any errors. This method might sound that it is time consuming and not an efficient way to test large and complex functions, but the return on investment on these methods are really high with almost all the bugs or errors in the functions are addressed in this method which is in conformance with the quality demanded by the critical systems.

The below is the clean room process flow model which results in the 14 different steps for the clean room software to be implemented . They are as follows,

Project Planning

Project Management

Performance Improvement and Engineering change

Architecture specification

Requirement analysis

Function Specification

Usage specification

Increment Planning

Software reengineering

Usage modelling and test planning

Statistical testing and certification

The clean room reference model starts with the different steps of project planning which are as follows,

A. Clean room reference model(CRM)

The clean room reference model is the standardized model

which is follows a set of protocols to be followed which will

result in a required quality standards needed by the critical

system. The clean room reference model will be modified in

accordance to the specifications of the system in order to

deliver the needs of the customer.

B. Project Planning of the clean room engineering

The project planning is the very first step of the clean room

process where the work flow of the system is developed in

order to have the tasks to achieve during the development life

cycle of the system. The main purpose of project planning is

to modify the CRM in accordance with the system

requirements and identifying the requirements for the system

specifications. The various steps present in project planning

are,

Project Mission statement

Project work architecture

Scheduling and resource allocation

Training plan

Recycle plan

Risk Identification plan

Configuration management plan

1. Project Mission statement:

The project mission statement consist of all the goals and the

missions need to be accomplished by the management at the

end of the system development. The main purpose of the

project mission statement is to motivate the team members of

the project and stay focused towards the goal.

2. Project work architecture:

The project work architecture is basic structure of the work

organization of the project. It consists of the assigned roles

and responsibilities of every single member in the team. The

work break down structure and the project work architecture

come hand in hand for the actual realization of this.

3. Scheduling and resource allocation:

The Scheduling is the process of assigning tasks to the earlier

assigned roles of the team members in the project and setting

up deadlines in order to give the customer deliverables within

the stipulated deadline. The resource allocation is the task of

allocating funds to the each task of the development life cycle,

this task is a pivotal one as the project needs to be completed

within the allocated resources.

4. Training Plan:

The training plan documents the necessary training needed for

the team members of the project in order to work on the

developing system environment domain applications and be

aware of the clean room environment methods.

5. Recycle Plan:

The recycle plan is a strategy of reusing the developed

functions or code structures in order to reduce the work load

on the development life cycle and increase the time efficiency

on other tasks. The recycle plan is implemented by tailoring

the code on accordance to the needs of the system function

and testing it with norms of the quality control of clean room

environment.

6. Risk Identification Plan:

Risk involved in the failure of the projects such as the failure

to meet the deadlines or the functionality of the system not

meeting the customer requirements will be spotted and work

around plans will be charted out in order to avoid the failure of

the project at unexpected situations.

7. Configuration management Plan:

The system developed needs to be implemented into the client

environment based on control manner in and change

management must be logged for all the changes accounted for

the system environment. This is a history log of all the events

occurred during the software life cycle development.

C. The project management of the clean room engineering

The project management is the only process in any software

development management team will be involved throughout

the development of the system. These are the various project

management steps involved in the clean room engineering,

Client Interactions

Peer organization Interactions

Teams formations

Counter active measures to errors.

1. Client Interactions:

The project manager plays a key role of bridging between the project team and the client and interacts in regular scheduled basis updating on the progress and project and obtains agreement with the every step of the project before moving to the next task.

2. Peer organization Interactions:

To have an insight view of the methods and to obtain an alternate plan of view of the problem, the interactions with the similar kind of organizations will lead to a better understanding and choices to be made based on picking up the best solutions for the current problem.

3. Team formations:

With the project planning phase various roles and responsibilities being assigned to every team member in this step we intend to group a similar kind of work tasks into a single group for better managerial purposes. This will lead to better utilization of the available time and resources to achieve the mission statement of the project. There are four different types of teams being formed in basics of the tasks performed by each team as,

*Management Team

*Specification Team

*Development Team

*Certification Team

(i) Management Team:

The team has the overall control and view of all the teams present in the project, these teams are constantly monitored that the each team is in accordance with the work plan and corrective actions are performed in case of anomalies in the products being developed.

(ii) Specification Team:

The team is the one which is involved during the requirements gathering and system specification phase where the team is responsible for the SRS document fabrication by understanding the client requirements. This team is led by a chief specification officer who will play an role of projecting the actual outlook of the project which will be the ultimate finish product to the customer. The team is responsible to give inputs to the development team and update them if the client changes his mind at any point of time about certain specifications and functions of the system.

(iii)Development Team:

The actual coding and design of the functions are done by this team for the inputs given by the specification team and coded on the environment the system need to run on by choosing the best developed and designed for optimization of the function code. Generally the complex code are broken down into simple building blocks from which these codes are integrated to check the functionality of each and every single block.

(IV)Certification Team:

The functionalities after being implemented into the system by the development team is passed on to the certification team where the mathematical modelling for all the functions are developed and applied to the in the system. The errors are being detected and reported back to the development team who will make changes in accordance and again tested back by the certification team. The development team and certification team work in close contact with each other in order expel all the errors and produce an error free system in the run time environment.

4. Counter active measures to errors:

The counter active measures is the work around plan needed to be done in order to correct the errors occurred during the software development life cycle. The errors can occur at any level of hierarchy in the work organization and actions are taken on the level above them as a point of authority defined during the project planning stages.

D. Performance Improvement:

The performance of the overall project is studied after the

every cycle of the software development life cycle and the

areas to be improved are being identified in order to

implement them in the next iteration of the software

development life cycle. The key functionalities of this stage is

to evaluate and introduce new methods or technologies in the

successive iterations for a constant improvement of the

performance.

E. Change authorization:

The change authorization stage is the after the first software

development cycle the software has to be deployed into the

client environment for the production purposes. This change

of system into the client environment is done by a separate

team called as the Release management team. A centralized

board for approving the changes being made to the client

environment called as the Change authority board (CAB) is

formed.

The board consists of members from both the client and the

environment in order to have a mutual agreement of the

specifications being met before the changes go into the client

environment. The release management team can be defined as

follows:

Release Management Team:

The team works in parallel with the testing and the

development team and make sure that the codes are

configured by using the version controlling tools and avoid

any kind of unauthorized changes being made to the code.

Another key responsibility of the release management team is

to deploy the products developed into the client server after

getting the agreement from the CAB in a controlled manner

without affecting the normal productions of the client

operations.

F. Functional Specifications:

The functional specification is one of the stages in the

certification task where the functionality of each and every

block developed is being tested and certified as in

conformance to the quality of the clean room development.

The clean room development follows a method called as the

formal method or the mathematical modelling in which the

functions are converted into a mathematical functions and

tested. The most sought method is the box structured formal

method.

(i) The Box method:

The box method is a type of mathematical model method

in which the functions of the system are verified in a

mathematical model and not in a traditional path model. The

box method has the following three components such as the,

*Black Box

*State Box

*Clear Box

Black Box:

The black box is considered to be the basic unit of the function

which defines the function by giving the user information of

about all the responses the function will produce when a

corresponding input or stimuli is given to the function.

This will address all the garbage and erroneous inputs to the

function and what output should be provided in order to avoid

a bug. This also has all the history of the function for the

previous stimuli and the outputs if in case the function is being

updated or modified.

State Box:

The state box represents the particular state at which the

function is right now and it captures all the value of the

corresponding present state the function is present. But the

state box will produce a set of variables to which the each

stimuli is mapped on so that the particular variable is called

when a corresponding stimuli is given as an input to the

function.

Clear Box:

The clear box is a combination of the data and control as it

specifies in which way the data and control must be structured

for a particular program so that a clear picture of the stimuli

and the responses for the particular functions to be performed

are stated. This will be the final box created after the first two

boxes for the specific function.

The functional specification is made in such a way that all the

stimuli possible for a function such as the software stimuli and

the hardware stimuli are being clearly mentioned in order to

avoid an error during the run time conditions.

G. Usage specification:

For any system being developed is targeted at a heterogeneous

mix of users which vary at different points of time. To address

this issue the specification phase of the project must have the

rough estimate of the user who are supposed to use the system

and develop specifications of the system accordingly.

To represent the usage it is specified normally using the

markov’s chain, where the flow process of the system usage is

represented. Since the chain is needless to store the flow

process from the start, the present state just points to the next

state and the next state contains the flow to the following state

which makes the chain memoryless.

This representation allows the development team to get an

overall idea of the software requirements for the system being

developed and identify where the resource allocation should

be higher to address the need s of the system during the run

time.

Depending upon the patterns from the markov’s chain we can

design our system in accordance to that and at the same time

we can produce a pattern of regular usage resources which can

be formed as an default blocks or functions which will

increase the computational speed of the system. The other

specifications that has to be identified during this stage is the

environmental specifications such as the networks been

integrated and the physical specification environments as well.

H. Architecture Specification:

The architectural specification of the system is to give an idea of the different structural relationships between the components present in the system. The architecture presents the different layers present in the system, which will come in handy during the development of the system. The software architecture refers to the common model of hierarchy which is been modelled on the basics of the system in accordance to the client specifications. This will act as a base reference model for the input to the incremental model where the several iterations of this base model is repeated until the specified requirement has been reached by the system.

The architecture also talks about the design of the mathematical model verification, usually in the clean room software engineering process done with the help of the box methods. The box methods consists of the different flow methods as in the case of the clear box method.

The box of each and every unit is been disintegrated on to the smaller steps which leads to the next step and the process of disintegration is continued until the full decomposition of the architecture is done which eventually revels the flow of data in the function which is modelled.

I. Usage Modeling and test planning:

The usage modelling is the done in order to build test cases for

the testing of the developed system. The usage modelling has

to address the usage specifications from the requirement

specification phase so that the usage models are used for the

testing of the components and functions. This kind of analysis

on the system being developed will lead to the simulation of

the environments which are to be faced by the system during

the real time environments and weed out the possible errors of

the system during the testing and development phase of the

system.

The statistical test cases can be developed in accordance to the

system being tested, such as some systems may always be

under the vulnerability of attack and the system should be

tested in such a way that the test cases are attacking the system

constantly to see the stability of the system such as the DOS

attack.

J. Incremental Procedure :

The incremental plan is to implement the complex software

system broken into a smaller functional parts, these functional

parts are implemented in each and every step of increment in

the system. The incremental procedure is done with the help

of the both client specification and the developer methods

with the basic structure of the system being implemented at

the first step of the iteration.

There are two steps involved in the process of break down

such as the resource allocation for each iterative step and the

clients approval for the defining the functional break down

based on the priority of the functions the client is in need.

There are different types of incremental methods which can

implemented such as the,

Water fall model

Evolutionary model

Spiral model

Incremental development model

The most common method is the waterflow model which is very simple and elegant method to implement, but the other methods will come in handy when the system referring to demands for some complex or different type of incremental steps.

The figure shows the different iterative method required to be carried out for the clean room software engineering process.

In the waterfall model the eight steps are repeated iteratively until the client specification of all the functions being implemented. The eight steps re as follows,

System feasibility

Software requirements

Product design

Detailed design

Code

Integration

Implementation

Operations/Maintenance

Evolutionary model:

The evolutionary model of the increment is done with the full imp mentation of the system in the client environment such as the development of the prototype of the system and then changing the functions of the system according the client specifications.

This method follows the feedback methodology from the client and changes are made accordingly to the feedback given. After the client feels like the maximum functionality has been implemented in the system the client declares the fulfilment of the project.

Spiral Model:

The spiral model as the diagram depicts is divided into four quadrants such as the,

Determination of objectives & alternatives

Evaluation of the alternatives & Risk identification

Development & verification

Planning of the next phase

This method starts from the center of the circle and crosses each stage inside out and produces an output at the end verification and plans for the next cycle. For each and every cycle corresponds to the next iteration in the development cycle.

Incremental Development model:

In the incremental development model is kind of similar to that of the waterfall model, but in this case the customer feedback is taken into account before they start for the next

cycle and implement the changes in the system according the customer feedback of the prototype developed earlier.

K. Software Re-engineering:

The software re-engineering is a counter active step being

followed in order to reduce the number of iterations while

following the general methodology of tailoring the existent

methods in order to meet the expectations of the current

system. There are two things which should be re-engineered

for the purpose of being compatible with the system in

reference, they are

(i) The old or the existent systems variables must be declared

in such a way the new systems is able to identify these

variables and there are no errors arising due to the undeclared

variables in the system and the incomplete functions of the

system must be completed in order to address the new system

function requirements

(ii) The quality conformance of the existing function must be

in accordance to the clean room software engineering level

certifications so that these functions can be used in order to

the particular system under development.

L. Industrial usage of the clean room:

The clean room as mentioned earlier was developed in the lab

of IBM and it was used in critical projects such as the redwing

project and other space mission projects in the NASA

missions.

In the year of March 1990 the NASA made a case study on

the clean environment on the basis of taking development of

the Corse/fine attitude determination subsystem of the upper

atmosphere research satellite.

The case study was to determine how efficient the process was

to develop the project using a normal method of software

development life cycle than in developing the project in the

clean room environment.

The project team was chosen in such a way that the normal

project team had an upper hand on the experience aspect as

compared to the normal software development team. This is

because of the fact that there is no much experience in the

clean room environment process as it was not very popular

during that period of time.

But still the methodologies followed by the clean room

environment clearly leads to the high efficiency at the later

stages of the software life cycle development

Both the methods of software development was done in the

parallel and the project with traditional method had to put in

less efforts when compared to the clean room team at any

point of time in the project. This was compared with the graph

below where the efforts had high. At the end of the case study

we had taken some points which helped in moving forward of

the decision making

For the clean room projects in the future. The clean room

projects taxed much work effort from the team members

present in the project but at the end the system had a higher

rate of efficiency when compared to the normal traditional

method this case study lead to the decision making for the

future projects of the NASA with the clean room environment.

In another case study done at the IBM laboratories with the

inventor of the clean room environment was the program in

COBOL to change the unstructured data into structured data

automatically.

This program was to be implemented in the clean room

environment and the results of the project had to be compared

to the normal methods of software development process. The

program was being implemented in incremental steps of 5 for

full functionality and compared with the normal methods in

the below tabular column

The table compares anticipated errors that would have

occurred when the system is been developed using the

normal methods and then using the clean room

environment methods.

We can clearly see that the anticipated errors are much

more low than that of the normal methods and error ratio

for this kind of implementation was always less than 6

leading to the high efficiency in the functions being

developed by the system.

The table also show the errors which are found in the real

time or the run time environment where the methods total

number of errors in the all the incremental cycles was not

greater than 10 which indicates that the msystem has

behaved in a highly reliable state and all the possible errors

or bug s has been reported using the formal methods and

rectified during the devlopment stage of the system.

But the on the other hand with the projects which are being

developed for the commercial purposes doesn’t follow this

method as this is supposed to be a more time consuming and

work hours demanding. This method is used only in the life

critical systems and not used in the normal software projects

which are not in the critical range.

M. Writer’s Verdict:

The clean room software engineering is the intense process of developing a life critical dependent system which will be such as an flight radar system or an GPS system showing the location of a ship. These kind of system has zero percent tolerance for the errors produced by them as these systems are guiding millions of life in every scenario.

So for a system with that kind of reliability the development process should be in such a way that all the possible ways in which the system can fail must be addressed to be fully certain on the system.

The system must undergo rigorous testing methods, quality standards and robust enough to be operated in any kind of situation. The clean room method of developing the software is the one way through which the end-user and the developer can be certain of the system

The overall process is been well fabricated and the minute detailing is given to each and every aspect of the system so that the failing percentage of the system is been almost brought to zero. But, on the other hand the level of precision and the amount of efforts required to build a system using a clean room software is not comparable to the normal traditional methods of software developing systems.

Therefore the usage of the clean room software method of system development is purely based on the type of the system being developed. For instance a piece of software being developed for the playing a music in phone can have an delay which is tolerant to a certain extent doesn’t require

a clean room method. So the clean room environment is always a better and a safe bet when it comes to development of the critical dependable systems.

Pros:

The developer and the end user can be certain about the reliability of the system which leads to the increased efficiency of the user.

This method constantly looks for the different methods which are needed for the performance development of a system which leads to discovery of new techniques and methods contributing to the better code development in the future

The developed system doesn’t require an update at regular intervals when compared to the normal system where the bugs are being fixed as updates now and then in the system which increases time for a system to reach a stable steady state and at the same time redundancy of the work is reduced.

Cons:

The method requires much time and effort when compared to the normal methods.

The budget of the project will be slightly higher than the normal methods due to the extended work hours and time for completion

The resource finding is not easy as highly focused and dedicated workers are needed in order to produce such kind of system with the specification required domain expertise.

REFERENCES

[1] Cleanroom software engineering refernce model by Richard C.

Linger & Carmen J.Trammell .

[2] The incremental development process in cleanroom software engineering by Carmen J Trammell, Mark G. Pleszkoch, Richard C .linger, Alan R. Henver.

[3] The cleanroom case study in the software engineering laboratory : project description and early anaylis by Scott Green,Ara Kouchakdjian, Victor Basili, David weidow

[4] A case study in cleanroom software engineering : The IBM cobol structuring facility by Richard C.Linger & Haralan D. Mills

.