🚀 go-pugleaf

In article <1991Jul26.230517.11695@digi.lonestar.org> jgay@digi.lonestar.org (john gay) writes:
|
| Do you really believe that taking an exam and becoming a 'professional'
| would make software any more reliable?  Now, just because a 'professional',
| licensed software stud wrote the program it want break, huh?  The only
| way to increase the reliability of software is to test the software in
| anyway that can be thought of - ever hear of alpha-testing, how about
| beta-testing?
---
There's a reasonably large branch of the CS community that would say
that NO amount of testing can ever make a program reliable, because no
program of real-world complexity can be *completely* tested.  That
branch of CS says that the only way to build reliable software is to
design-in reliability, to prove that the software does what its
specification says it should.  Now, I don't really hold with either side
of the argument -- you really *can't* test any program completely and
the specification camp doesn't solve the problem of testing/debugging
the specification so that you don't end up with a totally reliable
program that doesn't solve the problem it was intended for -- but I do
want to urge you not to rely on testing alone.

Alpha and beta testing are a particularly interesting thing to bring up,
though, because they aren't usually aimed at reliability.  Alpha and
beta testing are usually testing to see whether the program's
functionality meets users needs -- alpha testing on a small, tightly
controlled group, often outside the development group but inside the
developing company, and beta testing on a limited group of real users,
often outside the company.  In fairness, though, most of us do rely on
alpha and beta testing to find reliability problems induced by user's
habits of using the software in ways we hadn't intended.
---
| As far as primary and backup systems go, the only safe way to do this is
| the way the only software controlled nuclear power plant (in Canada I think)
| did this.  They had two independent systems groups design/write/test
| two systems that did the same thing.  This narrows the likelyhood that
| the same bug in the same part of a program will occur.  I think that
| it took them 3 years or so to finish.  After completion the company said
| they were very pleased with the finished results, but if they had to
| do it over again they would just do it the standard hardware way.
---
For what it's worth, the literature is pretty discouraging on
multi-version programming.  Several major studies have found that having
multiple, independently developed versions of a program did not
significantly increase overall reliability.  The independent teams
tended to produce programs that failed in similar ways.
---
| Most fault-tolerant systems are done that way in case the hardware goes
| out, not the software.  After all software doesn't wear out.  If it is
| well tested then it should be reliable.
---
The literature also provides frequent dialogues about whether software
wears out or not.  Even if the bits don't rot, the real-world
requirements tend to change over time -- the hardware may change, the
users' needs may change, the problem domain may change.  The Patriot
missile software, for instance, was designed for a significantly
different task than that it served in the Gulf War.  You couldn't expect
it to perform that role reliably no matter how thoroughly it was tested
in its original role.  So, had it worn out?  Depends on how you view the
total system.  The IRS lets you depreciate software because in most
cases it loses value over time as user needs change.

scott
--
scott preece
motorola/mcg urbana design center	1101 e. university, urbana, il   61801
uucp:	uunet!uiucuxc!udc!preece,	 arpa:	preece@urbana.mcd.mot.com
phone:	217-384-8589			  fax:	217-384-8550