[SystemSafety] Software reliability (or whatever you would prefer to call it)

Peter Bernard Ladkin ladkin at rvs.uni-bielefeld.de
Tue Mar 10 12:06:38 CET 2015


Bertrand,

Concerning the point of Annex D, I think there is likely to be a divergence of opinion.

I think Michael Pont was quite right in emphasising that Annex D says that it

[begin quote]
...provides initial guidelines on the use of a
probabilistic approach to determining software safety integrity for
pre-developed software based on operational experience. This approach is
considered particularly appropriate as part of the qualification of
operating systems, library modules, compilers and other system software.
[end quote]

and then querying whether it really can be used to "qualify" OS's and the other mentioned software
objects. The reasoning as to why the Bernoulli-process approach won't work for OS's is explicitly
addressed in Bev's and my "Practical" paper.

Also, I think one should use *all* available evidence when assessing critical SW. I don't think it
is appropriate to choose to ignore some of it. Suppose you have evidence A which suggests the SW is
marginally fit (or unfit) for purpose, and evidence B which suggests it roars along. You should not
be encouraged - indeed not be allowed, but that is beyond the scope of a mere standard - just to
produce evidence B, and leave A out, when the SW is being assessed.

The purpose of Annex D as I see it is to explain what you may infer from an operational history, if
the operational history has been logged under certain specified conditions (those conditions Bev and
I regard as very poorly specified in the current Annex D). Why not take it at face value?

PBL

Prof. Peter Bernard Ladkin, Faculty of Technology, University of Bielefeld, 33594 Bielefeld, Germany
Je suis Charlie
Tel+msg +49 (0)521 880 7319  www.rvs.uni-bielefeld.de






More information about the systemsafety mailing list