Write a management report to your boss who has asked you to research Cleanroom Software development. The report should help him understand what it is, what the advantages are and what the risks are if such a system were developed
1.Overview
2.Principles
3.Advantages and disadvantages.
4.Conclusion
5.Sources
Overview
Cleanroom software engineering is an engineering and
managerial process for the
development of high-quality software with certified reliability. Cleanroom was
originally developed by Dr. Harlan Mills . The name "Cleanroom" was
taken from the electronics industry, where a physical clean room exists to
prevent introduction of defects during hardware fabrication. Cleanroom software
engineering reflects the same emphasis on defect prevention rather than defect
removal, as well as certification of reliability for the intended environment of
use. The objective of the Cleanroom methodology is to achieve or approach zero
defects with certified reliability. The Cleanroom methodology provides a
complete discipline within which software
personnel can plan, specify, design, verify, code, test and certify software. In
a Cleanroom development, correctness verification replaces unit testing and
debugging. After coding is complete, the software immediately enters system test
with no debugging. All test errors are accounted for from the first execution of
the program with no private testing allowed. As opposed to many development
processes, the role of system testing is not to test in quality; the role of
system testing is to certify the quality of the software with respect to the
systems specification. This process
is built upon an incremental development approach. Increment N+1 elaborates on
the top down design of increment N. The Cleanroom process is built upon function
theory where programs are treated as rules for mathematical functions subject to
stepwise refinement and verification. Cleanroom specifications and designs are
built upon box structure specifications and design. Box structure specifications
begin with a black-box specification in which the expected behavior of the
system is specified in terms of the system stimuli, responses and transition
rules. Black boxes are then translated into state-boxes which define
encapsulated state data required to satisfy
black box behavior. Clear box designs are finally developed which define the
procedural design of services on state data to satisfy black box behavior. Team
reviews are performed to verify the correctness of every condition in the
specification. During the specification stage an expected usage profile is also
developed, which assigns probabilities or frequency of expected use of the
system components. During system correctness testing, the system is randomly
tested based on the expected usage of the system. In this process, software
typically enters system test with near
zero defects. The Cleanroom process places greater emphasis on design and
verification rather than testing. In this process errors are detected early in
the life cycle, closer to the point of insertion of the error.
Principles and Processes
 | Design Principle. Programming teams can and should strive to produce systems that are nearly error-free upon entry to testing. |
| Testing Principle. The primary purpose of testing is to measure the quality of the developed software product, not to test quality in. |
These fundamental principles lead to a number of specific practices, but
project-specific tailoring within the bounds of the above principles is the
rule, rather than the exception. The following are typical practices.
| Incremental development. An increment is a functional subset of the
system that is executable in a user-like environment. This end-to-end
executability requirement ensures that no effort is wasted in building
artificial scaffolding and drivers and that failure-rate results can be assessed
accurately. |
| Formal methods of specification and design. Although the original
Cleanroom practice required formal methods for specification and design,
practical usage has suggested that the level of formality will vary from project
to project and even within a single project. The box structures
approach is typical but not required. |
| Intensive review. Intensive team review has become the consensus of
Cleanroom us-age. The variable in practice is the level of formality, which to
some extent is tied to the choice of formal methods for specification and
design. A team that does not use functions to specify programs and program parts
cannot effectively use functional verification to assess correctness. However,
inspections can be applied in any case. The most frequent choice is to use some
level of functional specification plus verification-based inspection. |
| Testing. Cleanroom testing emphasizes reliability measurement over
bug-hunting. Testing is typically conducted from the black box user s view.
Although the orthodox view permits only statistical testing, the most
significant lesson learned from fifteen years of Cleanroom application is that
statistical testing should be supplemented by other forms of testing in the vast
majority of projects. This does not contradict the Cleanroom principles, it
merely challenges their typical implementation. In sum, there is enormous variation in Cleanroom practice, within the boundaries defined by its two fundamental principles. |
Advantages and disadvantages
The Cleanroom process enables organizations to make substantial improvements in
their software development performance, and to gain thereby competitive
advantage in both reliability and productivity.
Advantages of Cleanroom Software Development are obvious:
|
Quality Improvement Every Cleanroom case study reports fewer defects than expected; many projects reported as much as a 10-fold reduction. Each defect prevented represents a potential failure, crash, or outage avoided. |
| Cost Reduction Those case studies that measured productivity reported major improvements compared to similar projects. This is not unexpected: Every defect prevented is a defect that does not have to be found and fixed during testing or in the field. Furthermore, the Cleanroom techniques produce software that is simpler and easier to understand, so Cleanroom teams rarely introduce new bugs when fixing old ones. |
| Improved Software Maintainability Software developed using Cleanroom Process has clear, well-defined specifications with a less-complicated design allowing for easier maintenance. This is because CSE incorporates team reviews as part of the process and uses the box structure method for creating specifications. |
The following factors often cited as being disadvantageous to the Cleanroom
Software development:
1.A belief that the Cleanroom methodology is too theoretical, too
mathematical, and too radical for use in real software development.
2.It advocates no unit testing by developers but instead replaces it with
correctness verification and statistical quality control--concepts that
represent a major departure from the way most software is developed today.
3.The maturity of the software development industry. The use of Cleanroom
processes requires rigorous application of defined processes in all lifecycle
phases. Since most of the industry is still operating at the ad hoc level (as
defined by the Software Engineering Institute Capability Maturity Model), the
industry has not
been ready to apply those techniques.
All of these are based on misconceptions and poor knowledge of Cleanroom
concepts.
Conclusion
The typical software lifecycle is about 40% design, 20% code, and 40% unit
testing. The Cleanroom lifecycle is 80% design and 20% code and no unit test.
Cleanroom spans the entire software development life cycle. The traditional
approach of software design tends to culminate in a steady state error
population. This type of crafting often fails to provide the software quality
needed in today's society. Cleanroom software engineering allows errors to be
found earlier in the lifecycle, which minimizes expensive rework later on and
speeds time to market. Designs are simplified, straightforward, and verifiable,
resulting in less "spaghetti" code. Quality is achieved by design and
verification, not testing. This built in quality lowers the overall cost of the
product, and the designs also tend to be more concise and compact than average;
always a good thing for embedded developers. Cleanroom supports prototyping,
object orientation and reuse. The technology is platform and language
independent. And productivity is high. The methodology is based on structured
programming and is compatible with reuse. It is a formal, disciplined process,
composed of a set of stepwise refinements or transformations from the
requirements to the code, where each transformation is verified to the previous
level of refinement in order to minimize errors. 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.
(Top)
Sources:
An Introduction to Cleanroom Software Engineering for Managers
Chaelynne M. Wolak
Johnnie Henderson Why Isn't Cleanroom the Universal Software Development Methodology?
Harish Ananthpadmanabhan Cleanroom Software Development
Cleanroom Software Engineering
Cleanroom Software Engineering from Carnegie Mellon
Cleanroom Software Engineering Myths and Realities. Quality Week '97, San
Francisco, CA, May 27-30, 1997.
http://www.cleansoft.com/cleansoft_library.html
(Top)