Page 372 -

13.4 Dependable programming 355

behave. There cannot be scope for interpretation by the software developers. If
there are errors in this document, then these will be presented to all of the devel-
opment teams and implemented in all versions of the system.

One way to reduce the possibility of common specification errors is to develop
detailed specifications for the system independently, and to define the specifications
in different languages. One development team might work from a formal specifica-
tion, another from a state-based system model, and a third from a natural language
specification. This helps avoid some errors of specification interpretation, but does
not get around the problem of specification errors. It also introduces the possibility of
errors in the translation of the requirements, leading to inconsistent specifications.
In an analysis of the experiments, Hatton (1997), concluded that a three-channel sys-
tem was somewhere between five to nine times more reliable than a single-channel
system. He concluded that improvements in reliability that could be obtained by devot-
ing more resources to a single version could not match this and so N-version approaches
were likely to lead to more reliable systems than single version approaches.
What is unclear, however, is whether the improvements in reliability from a mul-
tiversion system are worth the extra development costs. For many systems, the extra
costs may not be justifiable as a well-engineered single version system may be good
enough. It is only in safety and mission critical systems, where the costs of failure
are very high, that multiversion software may be required. Even in such situations
(e.g., a spacecraft system), it may be enough to provide a simple backup with limited
functionality until the principal system can be repaired and restarted.

13.4 Dependable programming

Generally, I have avoided discussions of programming in this book because it is
almost impossible to discuss programming without getting into the details of a spe-
cific programming language. There are now so many different approaches and lan-
guages used for software development that I have avoided using a single language
for examples in this book. However, when considering dependability engineering,
there is a set of accepted good programming practices that are fairly universal and
which help reduce faults in delivered systems.
A list of good practice guidelines is shown in Figure 13.8. They can be applied in
whatever programming language is used for systems development, although the way
they are used depends on the specific languages and notations that are used for system
development.

Guideline 1: Control the visibility of information in a program

A security principle that is adopted by military organizations is the ‘need to know’
principle. Only those individuals who need to know a particular piece of information
in order to carry out their duties are given that information. Information that is not
directly relevant to their work is withheld.