Background - Using Event-B for Critical Device Software Systems - page 23

risk level with different hazard's characteristics, it is impossible to know if software
is safe without considering the behaviour of the software as a part of the system
which it is controlling. Therefore, when considering the process for developing a
safe software, it is crucial that the whole system of which the software is a part is
considered, as well as the software itself [ 12 ].
2.6.1 The Software Safety Life-Cycle
In the past several years, different types of software development life-cycle have
been identified. All of them have their own merits and limitations according to the
problem complexity, size and type of the system. This topic will not enter into a
discussion about different life-cycle process models. A detailed description about
each life-cycle process model is available in [ 4 , 80 , 90 , 99 ]. Here, we only discuss
about life-cycle process model related to the safety critical software system.
In recognition of the distinctive nature of safety-related systems, there is a stan-
dard development process known as V-model, which is widely accepted by large
companies and defence. It is an extension of the standard Waterfall model [ 4 , 8 , 98 ,
108 ]. The V-model represents a software-development process, where the process
steps are bent upwards after the coding phase to form the typical V shape. The V-
model presents the relationships between each phase of the development life-cycle
and its associated phase of testing. V-model is also called verification and validation
model (V & V). This process uses a very intensive testing for removing bugs or
errors, which may appear during any stage of the system development.
The typical process of developing a safety-critical software system is generally
time-consuming. Most of the development processes are based on the V-model,
which is illustrated diagrammatically in Fig. 2.7 . This model identifies the major
elements of the development process and indicates the structured, and typically se-
quential, nature of the development process. The sequential nature of development
is generally considered essential for reasons of managing communication and scale,
for scheduling different phases and disciplines, for managing traceability (which is
mandated by relevant safety standards) and for the certification purposes.
In order to produce a safety-related software according to this framework, various
techniques are recommended. These include the application of structured analysis
techniques to generate a visible modular construction (the principles of modularity
are expounded in [ 89 ]), and diversity in design, implementation and maintenance to
avoid faults due to common mode failures. Many such techniques are very widely
applicable, and although they are usefully brought into the safety-critical context,
there is not so much literature devoted solely to their use in this specific area. Never-
theless, material is available: for instance, there have been reviews such as [ 28 , 103 ]
to help designers and managers as to the suitability of mainstream programming
languages for the safety-critical systems.
Safety requires a lot of integrity, and this is recognised in the safety life-cycle
model which separates the specification of safety requirements into purely func-