Path: utzoo!attcan!uunet!know!sdd.hp.com!wuarchive!udel!princeton!pucc!EGNILGES
From: EGNILGES@pucc.Princeton.EDU (Ed Nilges)
Newsgroups: comp.software-eng
Subject: Re: reliability theory in software engineering
Message-ID: <11847@pucc.Princeton.EDU>
Date: 9 Oct 90 17:21:42 GMT
References: <6139@ge-dab.GE.COM>
Reply-To: EGNILGES@pucc.Princeton.EDU
Organization: Princeton University, NJ
Lines: 33
Disclaimer: Author bears full responsibility for contents of this article

In article <6139@ge-dab.GE.COM>, coleman@sunny.DAB.GE.COM (Richard Coleman) writes:

>
>--
>  I have been rereading a paper that a prof gave me when
>I was taking a course in reliability theory.  It is titled
>'Fault Diversity in Software Reliabilty' by Boland,Proschan,and
>Tong.  I was just curious if anyone has had any success in using
>statistical reliablity techniques in a commercial software project.

I've seen some books on the subject, but I did not look at them.
Perhaps I should have: but statistical QC would seem to be a
blind alley in software reliability for these reasons:


     *  Bugs are by nature "outlier" events which fall outside
        the range at least of crude statistical predictions.
        Such predictions make a science of OMITTING "outlier"
        events in the name of curve fitting.

        Many bugs, that is, result from a group of designers
        deciding, quite rationally and often on the basis of
        good statistical evidence, that such and such a condi-
        tion is so improbable that it would be bad engineering
        to design-in ways to avoid it.  Murphy's Law then kicks
        in and boom...the bug occurs.

     *  I for one don't want to tell my management that I
        now am using statistical quality control because there
        are so many bugs in the software.  That is, if there
        are enough bugs for statistics to be meaningful there
        are too many bugs and your design needs to be thrown
        out and redone.