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

[Littlewood, Bev]

Where “As previously established” = “If I say it often enough it will be true”


On 23 Apr 2016, at 12:34, Nick Tudor <njt at tudorassoc.com<mailto:njt at tudorassoc.com>> wrote:

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<mailto: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<http://www.rvs.uni-bielefeld.de/>







--
Nick Tudor
Tudor Associates Ltd
Mobile: +44(0)7412 074654
www.tudorassoc.com<http://www.tudorassoc.com/>
[http://www.tudorassoc.com/wpimages/wpb4e71a5c_0f.jpg]

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

www.aeronautique-associates.com<http://www.aeronautique-associates.com/>

_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE<mailto:systemsafety at techfak.uni-bielefeld.de>

_______________________________________________

Bev Littlewood
Professor of Software Engineering
Centre for Software Reliability
City University London EC1V 0HB

Phone: +44 (0)20 7040 8420  Fax: +44 (0)20 7040 8585

Email: b.littlewood at csr.city.ac.uk<mailto:b.littlewood at csr.city.ac.uk>

http://www.csr.city.ac.uk/
_______________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20160423/e331f600/attachment-0001.html>