Information Technology Reference
In-Depth Information
that this software was always serving the same purpose. Starting with a
relatively high bug count of almost 1000 bugs in less than 150 TLOC, the
software “matures” after several release changes and is reaching a residual
bug density, which is less than a tenth of the initial bug density. During its
early life the absolute number of bugs is oscillating and stabilizes in its more
mature life period. At a later phase of the life cycle the absolute number of
bugs is slightly growing despite a decreasing bug density. The late life-cycle
bug density is mainly determined by the effectiveness and quality measures
taken on the one hand and the number of functional changes and adaptations
built in since last release on the other hand. The actual number of bugs is
often unknown and can only subsequently been determined.
Fig. 4. Bug fixing history and growth statistics of an AT&T communication server
software package over a life cycle of 17 releases [9], [13].
Even though that extensive testing has been and still is proposed as an
effective method for detecting errors, it has become evident, that by testing
alone the correctness of software cannot be proven, because tests can only
detect those errors for which the test engineer is looking for [14]. This means
ultimately that there is no way to base a safety case on testing alone, because
the goal is not to find errors, but to prove the absence of errors. One of the
great pioneers of software engineering, Edsgar W. Dijkstra, has put it into
the following words [15]:
“Program testing can be a very effective way to show the presence of bugs,
but is hopelessly inadequate for showing their absence.”
We have even to admit that at the current state of software technology,
there is no generally accepted single method to prove the correctness of soft-
ware that means, there is no way to prove the absence of bugs, at least not
