[SystemSafety] Software reliability (or whatever you would prefer to call it)
C. Michael Holloway
c.m.holloway at nasa.gov
Tue Mar 10 11:34:22 CET 2015
I can't speak for Nick, but I object to the use of the term
"reliability" being applied to anything other than failures (using the
term loosely) resulting from physical degradation over time. I believe
it is important to maintain a clear distinction between undesired
behavior designed into a system, and undesired behavior that arises
because something ceases to function according to its design. (Here
"designed / design" is used broadly. It includes all intellectual
activities from requirements to implementation.)
--
/*cMh*/
*C. Michael Holloway*
The words in this message are mine alone; neither blame nor credit NASA
for them.
On 3/10/15 5:50 AM, Peter Bishop wrote:
> Now I think I understand your point.
> You just object to the term *software* reliability
>
> If the term was *system* reliability in an specified
> operational environment, and the system contained software
> and the failure was always caused by software
> - I take it that would be OK?
>
> A alternative term like *software integrity* or some such would be
> needed to describe the property of being correct or wrong on a given
> input.
> (In a lot of mathematical models this is represented as a "score
> function" that is either true or false for each possible input)
>
> Peter Bishop
>
> Nick Tudor wrote:
>> Now back in the office...for a short while.
>>
>> Good point David - well put.
>> I would have responded: There exists a person N who knows a bit about
>> mathematics. Person N applies some mathematics and asserts Truth.
>> Unfortunately, because of the incorrect application of the
>> mathematics, the claims N now makes cannot be relied upon. The maths
>> might well be correct, but the application is wrong because - and I
>> have to say it yet again - the application misses fails to
>> acknowledge that it is the environment that is random rather than the
>> software. Software essentially boils down to a string of one's and
>> nought's. Given the same inputs (and that always comes from the
>> chaotic environment) then the output will always be the same. It
>> therefore makes no sense to talk about 'software reliability'.
>>
>> Nick Tudor
>> Tudor Associates Ltd
>> Mobile: +44(0)7412 074654
>> www.tudorassoc.com <http://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>*
>>
>> On 9 March 2015 at 12:26, David Haworth <david.haworth at elektrobit.com
>> <mailto:david.haworth at elektrobit.com>> wrote:
>>
>> Peter,
>>
>> there's nothing wrong with the mathematics, but I've got
>> one little nit-pick about its application in the real world.
>>
>> The mathematics you describe gives two functions f and g,
>> one of which is the model, the other is the implementation.
>>
>> In practice, your implementation runs on a computer and so the
>> domain and range are not "the continuum". If your model is
>> mathematical
>> (or even runs on a different computer), the output of one will
>> necessarily be different from the output of the other. That
>> may not be a problem in the discrete sense - you simply specify a
>> tolerance t > 0 in the form of:
>>
>> Corr-f-g(i) = 0 if and only if |f(i)-g(i)| < t
>>
>> etc.
>>
>> The problem becomes much larger in the real world of control
>> systems where the output influences the next input of the
>> sequence. The implementation and the model will tend to drift
>> apart. In the worst case what might be nice and stable in the
>> model might exhibit unstable behaviour in the implementation.
>>
>> You're then in the subject of mathematical chaos, where a
>> perfectly deterministic system exhibits unstable and unpredictable
>> behaviour. However, this email is too small to describe it. :-)
>>
>> Cheers,
>> Dave
>>
>> On 2015-03-09 11:48:57 +0100, Peter Bernard Ladkin wrote:
>> > Nick,
>> >
>> > Consider a mathematical function, f with domain D and range R.
>> Given input i \in D, the output is f(i).
>> >
>> > Consider another function, g, let us say for simplicity with the
>> same input domain D and range R.
>> >
>> > Define a Boolean function on D, Corr-f-g(i):
>> >
>> > Corr-f-g(i) = 0 if and only if f(i)=g(i);
>> > Corr-f-g(i) = 1 if and only if f(i) NOT-EQUAL g(i)
>> >
>> > If X is a random variable taking values in D, then f(X), g(X) are
>> random variables taking values in
>> > R, and Corr-f-g(X) is a random variable taking values in {0,1}.
>> >
>> > If S is a sequence of values of X, then let Corr-f-g(S) be the
>> sequence of values of Corr-f-g
>> > corresponding to the sequence S of X-values.
>> >
>> > Define Min-1(S) to be the least place in Corr-f-g(S) containing a
>> 1; and to be 0 if there is no such
>> > place.
>> >
>> > Suppose I construct a collection of sequences S.i, each of length
>> 1,000,000,000, by repeated
>> > sampling from Distr(X). Suppose there are 100,000,000 sequences I
>> construct.
>> >
>> > I can now construct the average of Min-1(S) over all the
>> 1,000,000,000sequences S.i.
>> >
>> > All these things are mathematically well-defined.
>> >
>> > Now, suppose I have deterministic software, S. Let f(i) be the
>> output of S on input i. Let g(i) be
>> > what the specification of S says should be output by S on input
>> i. Corr-f-g is the correctness
>> > function of S, and Mean(Min-1(S)) will likely be very close to
>> the mean time/number-of-demands to
>> > failure of S if you believe the Laws of Large Numbers.
>> >
>> > I have no idea why you want to suggest that all this is
>> nonsensical and/or wrong. It is obviously
>> > quite legitimate well-defined mathematics.
>> >
>> > 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>
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > The System Safety Mailing List
>> > systemsafety at TechFak.Uni-Bielefeld.DE
>> <mailto:systemsafety at TechFak.Uni-Bielefeld.DE>
>>
>> --
>> David Haworth B.Sc.(Hons.), OS Kernel Developer
>> david.haworth at elektrobit.com <mailto:david.haworth at elektrobit.com>
>> Tel: +49 9131 7701-6154 <tel:%2B49%209131%207701-6154> Fax:
>> -6333 Keys: keyserver.pgp.com
>> <http://keyserver.pgp.com>
>> Elektrobit Automotive GmbH Am Wolfsmantel 46, 91058
>> Erlangen, Germany
>> Geschäftsführer: Alexander Kocher, Gregor Zink Amtsgericht
>> Fürth HRB 4886
>>
>> Disclaimer: my opinion, not necessarily that of my employer.
>>
>> _______________________________________________
>> The System Safety Mailing List
>> systemsafety at TechFak.Uni-Bielefeld.DE
>> <mailto:systemsafety at TechFak.Uni-Bielefeld.DE>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> The System Safety Mailing List
>> systemsafety at TechFak.Uni-Bielefeld.DE
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20150310/dce1aa21/attachment-0001.html>
More information about the systemsafety
mailing list