[SystemSafety] Does "reliable" mean "safe" and or "secure" or neither?

[Nick Tudor]

Peter

As previously established...software does not have a reliability.

Cheers

On Saturday, 23 April 2016, Peter Bernard Ladkin <
ladkin at rvs.uni-bielefeld.de> wrote:

> On Thursday 2016-04-21 05:00 , I wrote:
> >  On 2016-04-20 23:18 , Les Chambers wrote:
> >>> But here's the thing, any standards body that goes down this path will
> soon encroach upon the territory of
> >>> established religion whose moral codes often diverge even though their
> collective central core is probably the same.
> >
> >  That is utter nonsense.
>
> Les deprecated this as somehow lacking intellectual rigor. So here's a
> more rigorous derivation.
>
> Suppose you have a computer-based system S with function F on which you
> want to rely. You've done
> your best to write software So1 for S so that it executes F, but sometimes
> it doesn't. You run So1
> in environment E1, and mostly it executes F (75%) but sometimes it doesn't
> (25%). You run So1 in
> environment E2, and mostly it executes F (60%) but sometimes it doesn't
> (40%).
>
> Someone else has done their best to write software So2 for S so that it
> executes F, but sometimes it
> doesn't. You run So2 in environment E1, and mostly it executes F (70%) but
> sometimes it doesn't
> (30%). You run it in environment E2, and mostly it executes F (65%) but
> sometimes it doesn't (35%).
>
> You can talk about the reliability of So1 in E2 and in E2, and about the
> reliability of So2 in E1
> and in E2. Reliability is a function of software and its environment:
> reliability(So1,E) = 75%.
>
> Now suppose you have a new environment E3 and you want to know whether to
> choose So1 to run in it or
> So2. How do you choose? How So1 and So2 run in E1 and E2 might not be a
> reliable guide to how either
> is going to run in E3, although you'd imagine that there would be some
> kind of correlation. You want
> somehow a measure of So1 against So2 which is going to guide your choice.
>
> And then you've heard that someone else has written So3 to perform F, and
> has some reliability stats
> in some other environments, but not E1, E2 or E3. So now you want a guide
> to choosing from So1, So2
> and So3. And so on for So4 from yet another vendor, and ........
>
> What's that measure going to be? Let's call it XXXXXX. If you had software
> So7 and So8, and So7 ran
> more reliably in every environment you tried than did So8, you might want
> to conclude that So7 had
> more of XXXXXX than So8. You can't say that So1 has more XXXXXX than So2
> per se, if you just look at
> their reliabilities in E and E1, because one is not dominant over the
> other.
>
> And doesn't XXXXXX seem like a silly name? It's hard to pronounce, for one
> thing. So you might want
> to call it, I dunno, ... how about "integrity"?
>
> You know that whatever integrity is, it's not the same as reliability. You
> also have a pretty good
> hunch that it might be correlated with the care taken in developing the
> software. But you have no
> exact measure.
>
> So what you might do is say: I can't be exact, so I'll stick with five
> discrete categories of
> "integrity" for software: no-measure, low, medium, high and exceptionally
> high. You might even want
> to call these "levels" (except for the first). And give them numbers, say
> no-number, 1, 2, 3 and 4.
> And develop software for IL 1 by whatever means people think is
> appropriate for the cases where you
> need the kind of performance hopefully associated with IL 1-designated
> applications. Mutatis
> mutandis for IL 2, 3, 4.
>
> Well, actually, I've left a bit out. The developers already did that. So1
> and So2 were both
> developed using means thought appropriate for IL 2. So3 was developed
> using means thought
> appropriate for IL 4.
>
> So, which software do you procure for executing F in E2? Mutatis mutandis,
> I'd probably choose the
> one with IL 4. Of course, that doesn't mean So3 will actually perform more
> reliably in E3 than the
> others. I don't know that for sure and won't find out until I try (all
> three, and document carefully
> their performance over a long period of time).
>
> None of this is subjective, although some of it is vague and some is
> uncertain (irredeemable
> uncertain, according to some people). There is also a difference in what
> software is intended to do,
> what it is needed to do, and what it actually does. (Ingo Rolle has some
> insight into how this
> affects claims about the software, and has written it up. The final
> version is due to go up on my
> blog soon.) Still, it does a job right now which people need doing, but
> probably can't do perfectly.
>
> Then someone comes along, quotes a couple of common-language dictionary
> definitions of "integrity",
> and says something about established religion and moral codes. Utter
> nonsense you might say, and I did.
>
> 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
>
>
>
>
>
>

-- 
Nick Tudor
Tudor Associates Ltd
Mobile: +44(0)7412 074654
www.tudorassoc.com

*77 Barnards Green Road*
*Malvern*
*Worcestershire*
*WR14 3LR*
*Company No. 07642673*
*VAT No:116495996*

*www.aeronautique-associates.com <http://www.aeronautique-associates.com>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20160423/315739bb/attachment.html>