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

[RICQUE Bertrand (SAGEM DEFENSE SECURITE)]

I think we are converging. Should we put a warning such as:

Without a detailed analysis linking the observed failures to their root causes (HW failure, non-adapted specification,  wrong software), it must be clear that the failure rate encompasses HW (and potentially other things...).

Bertrand Ricque
Program Manager
Optronics and Defence Division
Sights Program
Mob : +33 6 87 47 84 64
Tel : +33 1 58 11 96 82
Bertrand.ricque at sagem.com


-----Original Message-----
From: Peter Bernard Ladkin [mailto:ladkin at rvs.uni-bielefeld.de]
Sent: Tuesday, March 10, 2015 12:07 PM
To: RICQUE Bertrand (SAGEM DEFENSE SECURITE); The System Safety List
Subject: Re: [SystemSafety] Software reliability (or whatever you would prefer to call it)

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




#
" Ce courriel et les documents qui lui sont joints peuvent contenir des informations confidentielles, être soumis aux règlementations relatives au contrôle des exportations ou ayant un caractère privé. S'ils ne vous sont pas destinés, nous vous signalons qu'il est strictement interdit de les divulguer, de les reproduire ou d'en utiliser de quelque manière que ce soit le contenu. Toute exportation ou réexportation non autorisée est interdite Si ce message vous a été transmis par erreur, merci d'en informer l'expéditeur et de supprimer immédiatement de votre système informatique ce courriel ainsi que tous les documents qui y sont attachés."
******
" This e-mail and any attached documents may contain confidential or proprietary information and may be subject to export control laws and regulations. If you are not the intended recipient, you are notified that any dissemination, copying of this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly prohibited. Unauthorized export or re-export is prohibited. If you have received this e-mail in error, please advise the sender immediately and delete this e-mail and all attached documents from your computer system."
#