[SystemSafety] Paper on Software Reliability and the Urn Model

[jean-louis Boulanger]

2015-02-25 10:00 GMT+01:00 Peter Bernard Ladkin <ladkin at rvs.uni-bielefeld.de
>:

> I have recently been involved in discussions concerning rewriting IEC
> 61508-7:2010 Annex D, a short
> informative section attempting to explain the statistical evaluation of
> the reliability of SW for
> which there is an operational history.
>

For the software, no evaluation of reliability are acceptable or
representative.

Software contain bug (no idea of the number)
the change process are not monitored (not the same team, not the same
method, ...)
each time we modified the software to correct a bug we add some bug
not the same tools (new version appear, with many changement)
We don't have no operational history of software ....
the length between error and failure can be short or very long ...


> Lots of things come up. People don't understand what the urn model has to
> do with software
> evaluation. I have recently experienced reliability experts making
> incorrect claims, and non-experts
> finding it difficult to adjudicate those claims.


experienced reliability expert making incorrect claims because software
reliability assessment is not a subject
software are not reliable ...


> I've been discussing these matters with Bev Littlewood and Jens Braband.
>
> I think there is a need for some clarity. I am (amongst other things) an
> experienced mathematician,
>

I am not an experienced mathematician but I understand that is not a good
idea to apply the basic mathematics to a complexe product
 - hypothesis for production : not the same
 - hypothesis for method : depend of the modification (small, big) depend
of the time (when system is in operation, we need to develop new version in
very short time to correct a critical bug, ...)
 - hypothesis on human : not the same people, many sub-contractors
(different competencies, different background, minimal cost, etc., the
quality change with the time (increase/decrease)
 - software complexity many variables, memorization, parameter, many
interaction with another software, ....
 - ...

 the known defect is not representative of the unknown defect

 For some software, I am the assessor from 10 years, and i confirm that the
number of known bug increase after each version ....




> but I find most applied-statistics textbooks almost impenetrable, and it's
> clear that it's worse for
> people who don't have even my background. The very best explanation I have
> ever found of the basics
> of statistical inference was written by a philosopher, Ian Hacking.
>
> Some professionals don't even like the urn model for explaining SW
> reliability (you know who you
> are! :-) ). But I think it's pretty good for some purposes, even though in
> Annex D it just seems to
> be stuck on like a Post-It note.
>
> I think there are good reasons for explaining software reliability
> engineering in straightforward
> terms to people who are not expert. So I wrote a note using the urn model
> and the interpretation of
> (some kinds of) software into the urn model. I use it to refute two
> mistaken claims that I have
> recently heard and read.
>
>
> http://www.rvs.uni-bielefeld.de/publications/Papers/SWasBernoulliProcess20150225V3.pdf
>
> 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
>
>
>
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
>



-- 
Mr Jean-louis Boulanger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20150225/efe0ac1f/attachment.html>