Littlewood [1] introduced the idea that software may be possibly perfect and that we can contemplate its probability of (im)perfection. We review this idea and show how it provides a bridge between correctness, which is the goal of software verification (and especially formal verification), and the probabilistic properties such as reliability that are the targets for system-level assurance. We enumerate the hazards to formal verification, consider how each of these may be countered, and propose relative weightings that an assessor may employ in assigning a probability of perfection.

Inference from statistical testing is the only sound method available for estimating software reliability. However, if one ignores evidence other than testing (e.g., evidence from the track record of a developer, or from the quality of the development process), the results are going to be so conservative that they are often felt to be useless for decision-making. Bayesian inference is the main mathematical tool for taking into account such knowledge. Evidence from sources other than testing is modelled as prior probabilities (for values of the failure rate of the program) and is updated on the basis of test results to produce posterior probabilities. We explain these methods and demonstrate their use on simple examples. The measure of interest is the probability that a program satisfies a given reliability requirement, given that it has passed a certain number of tests. The procedures of Bayesian inference explicitly show the weights of prior assumptions vs. test results in determining this probability. We also demonstrate how one can model different assumptions about the faultrevealing efficacy of testing. We believe that these methods are a powerful aid for improving the quality of decision-making in matters related to software reliability. 1.

This paper looks at the ways in which the reliability of software can be assessed and predicted. It shows that the levels of reliability that can be claimed with scientific justification are relatively modest 1

Previous work on structural software reliability modelling should be extended to account for data flow in software. A way forward is explained by contrasting two extremely simple examples of software structure. In addition to improving software reliability estimates, development of such an approach is important because it has the potential to provide guidelines for testable software and it would provide a formal meaning for the notion of coupling between software components. 1. Subject Area Very complex systems unavoidably contain unidentified systematic (i.e. designed-in) faults. Software systems exemplify this. Consequently, methods are needed which, prior to system operation, quantitatively assess the extent to which these faults will cause failures. In principle statistical system testing (SST) can provide these assessments by providing estimates of systematic reliability. However, many safety engineers are unconvinced by current SST models because the models ignore the nat...

should appear on the left and odd-numbered pages on the right when opened as a doublepage This report refines and extends an earlier paper by the first author [25]. It considers the problem of reasoning about the reliability of fault-tolerant systems with two “channels” (i.e., components) of which one, A, because it is conventionally engineered and presumed to contain faults, supports only a claim of reliability, while the other, B, by virtue of extreme simplicity and extensive analysis, supports a plausible claim of “perfection.” We begin with the case where either channel can bring the system to a safe state. The reasoning about system probability of failure on demand (pfd) is divided into two steps. The first concerns aleatory uncertainty about (i) whether channel A will fail on a randomly selected demand and (ii) whether channel B is imperfect. It is shown that, conditional upon knowing pA (the probability that A fails on a randomly selected demand) and pB (the probability that channel B is imperfect), a conservative bound on the probability that the system fails on a randomly selected demand is simply pA × pB. That is, there is conditional independence between the events “A fails ” and “B is imperfect. ” The second

The conclusions presented in the STUK report series are those of the authors and do not necessarily represent the official position of STUK.

Final report of the study group on the safety of operational computer systems The use of computers in safety-critical applications Final report of the study group on the safety of operational computer systems The use of computers in safety-critical applications The use of computers in safety-critical applications ii

Abstract—In recent work, we have argued for a formal treatment of confidence about the claims made in dependability cases for software-based systems. The key idea underlying this work is “the inevitability of uncertainty”: It is rarely possible to assert that a claim about safety or reliability is true with certainty. Much of this uncertainty is epistemic in nature, so it seems inevitable that expert judgment will continue to play an important role in dependability cases. Here, we consider a simple case where an expert makes a claim about the probability of failure on demand (pfd) of a subsystem of a wider system and is able to express his confidence about that claim probabilistically. An important, but difficult, problem then is how such subsystem (claim, confidence) pairs can be propagated through a dependability case for a wider system, of which the subsystems are components. An informal way forward is to justify, at high confidence, a strong claim, and then, conservatively, only claim something much weaker: “I’m 99 percent confident that the pfd is less than 10 5, so it’s reasonable to be 100 percent confident that it is less than 10 3. ” These conservative pfds of subsystems can then be propagated simply through the dependability case of the wider system. In this paper, we provide formal support for such reasoning. Index Terms—Bayesian probability, safety case, software reliability. Ç