Page 49 -

32 Chapter 2 Software processes

Cleanroom software engineering

An example of a formal development process, originally developed by IBM, is the Cleanroom process. In the
Cleanroom process each software increment is formally specified and this specification is transformed into an
implementation. Software correctness is demonstrated using a formal approach. There is no unit testing for
defects in the process and the system testing is focused on assessing the system’s reliability.
The objective of the Cleanroom process is zero-defects software so that delivered systems have a high level
of reliability.
http://www.SoftwareEngineering-9.com/Web/Cleanroom/

The waterfall model is consistent with other engineering process models and docu-
mentation is produced at each phase. This makes the process visible so managers can
monitor progress against the development plan. Its major problem is the inflexible par-
titioning of the project into distinct stages. Commitments must be made at an early stage
in the process, which makes it difficult to respond to changing customer requirements.
In principle, the waterfall model should only be used when the requirements are
well understood and unlikely to change radically during system development.
However, the waterfall model reflects the type of process used in other engineering
projects. As is easier to use a common management model for the whole project,
software processes based on the waterfall model are still commonly used.
An important variant of the waterfall model is formal system development, where
a mathematical model of a system specification is created. This model is then
refined, using mathematical transformations that preserve its consistency, into exe-
cutable code. Based on the assumption that your mathematical transformations are
correct, you can therefore make a strong argument that a program generated in this
way is consistent with its specification.
Formal development processes, such as that based on the B method (Schneider,
2001; Wordsworth, 1996) are particularly suited to the development of systems that
have stringent safety, reliability, or security requirements. The formal approach sim-
plifies the production of a safety or security case. This demonstrates to customers or
regulators that the system actually meets its safety or security requirements.
Processes based on formal transformations are generally only used in the devel-
opment of safety-critical or security-critical systems. They require specialized
expertise. For the majority of systems this process does not offer significant cost-
benefits over other approaches to system development.

2.1.2 Incremental development

Incremental development is based on the idea of developing an initial implementa-
tion, exposing this to user comment and evolving it through several versions until an
adequate system has been developed (Figure 2.2). Specification, development, and