RE: Bug-free software (was: Re rant about viruses on VMS...)

["David Crocker" <dcrocker () eschertech com>]

Andreas,

> >
So we are in reality talking about different levels of "bugfree":
* specification
* implementation
* operation

How does this differ? As I see it:
* Bugfree at the specification level would mean that the software complies
to the specification, and works bugfree according to the specification
parameters.
* Bugfree at the implementation level would mean that the code is
technically bugfree
* Bugfree at the operation level would mean that the program is bugfree
whatever you do with it
<<

I'm still not sure what you mean by "bugfree at the operational level". Maybe
you mean that the software should behave reasonably for all possible inputs
(i.e. not crash, nor suffer from buffer overflows etc. that might expose
vulnerabilities or give rise to other undefined behaviour). If this what you
mean, then I agree that this is an important part of being "bug-free". A program
should be robust with respect to all possible inputs. This is certainly an area
that mathematically-based methods address.

On the other hand, maybe you mean that the requirements change over time, so
that the original specification no longer meets the new requirements. This is
not a problem with the software - the user presumably purchased or commissioned
the software to meet the requirements at the time, and if the requirements
change, the user must expect that the software originally chosen may not be up
to the job.

> >
We can compare this to building a house - even a statically 100% correct
design (implementation) may still be unusable because the specification is
incorrect or not fulfilled, and also may crumble after a time because of
shortcomings in the materials (operation).
<<

As software engineers we have the huge advantage over most other engineers that
the materials we use _don't_ degrade over time. The ways in which software is
used does change, but it is not necessary to anticipate all the changes. For
example, Internet Explorer has suffered from a number of buffer overflow
vulnerabilities. This I regard as inexcusable, because a complete package should
be robust for all possible inputs. OTOH the recently-patched "phishing" bug that
allowed a link to point to one page that appears (from the IE address box) to be
a different page is more understandable, because the requirement that the
address box should always be the address of the page displayed might have been
easily missed before "phishing" scams became widespread.

> >
You can write a technically 100% correct and bugfree code, yet it does not
work because of operational parameters or missing specifications. Is it
still bugfree then or not?
<<

Again, I'm not sure what you mean by "operational parameters". As for missing
specifications, they can be categorised into 2 general types:

1. The specification fails to say what will happen for some particular input.
This is easily detected by mathematically-based methods.

2. The specification fails to mention that some particular functionality is
required. This is a failure of the requirements analysis process.

For example, if the software is a word processor and the spec fails to mention
what happens if I press (say) control-alt-shift-Q, that falls in category (1).
But if the software fails to provide a mechanism for generating automatically a
table of contents, and I specifically need that function, it is probably my
fault for not checking whether then software I purchased provides this feature.

> >
Most string handling routines are technically bugfree in the given
specification, yet they cause problems because of operational failures
(parameters).
<<

I'm not sure what you mean by this - an example would be helpful. If you mean
that it is possible to crash them by providing invalid parameters, then this is
not a bug - provided that the specification clearly states the preconditions
under which parameters are acceptable. It is up to the person who uses the
string handling routines to ensure the preconditions are satisfied (the
mathematically-based methods we use here do that automatically). OTOH a complete
program, or a module that cannot trust its input, should be robust with respect
to all possible inputs (which, again, can be ensured using mathematically-based
methods).

> >
(I hope I made it understandable, am still having sometimes troubles to
express my thoughts in english.)
<<

I speak hardly any Spanish (if that is your native language), so I'm certainly
not going to criticize your English!

Regards,

David Crocker
Escher Technologies Ltd.
www.eschertech.com
Tel. +44(0)1252 336565  Fax +44(0)1252 320954