Cleam Room Software Engineering A developer perspective approch
Manoj Chander
Electrical Engineering
Drexel University
Philadelphia, USA
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
.