Panel Session On Limits In Dependability

model that makes a few broad assumptions, than of a detailed model that depends on many intricate details: in fact, it may be easier and more convincing to test sequential code in execution, rather than validate the highly detailed model of its execution environment that would support its formal verification. It therefore seems to me that for maximum utility in contributing to assurance at the limits of dependability, formal methods should mainly be applied in a "fully formal" manner to problems where: Other techniques are absent or ineffective, The problems are crucial to overall success, and . Validation of the accuracy and utility of the modeled assumptions and properties is relatively straightforward. The problems that best meet these criteria are likely to be the hurdest parts of the overall design problem, treated early in the life cycle and at a relatively high level of abstraction. Examples include problems of distributed and parallel execution, timing, fault-tolerance, and the combinations of these. Testing can explore only a tiny fraction of the possible behaviors of such elements of design, and can in any case only be performed relatively late in the development life cycle. By working early in the life cycle, on relatively abstracted representations of the problem, fully formal methods can provide compelling evidence that these crucial elements of design are correct; furthermore they can provide this evidence early enough to be useful, cheaply enough to be feasible, and on the basis of modeling that is simple enough to be credible. I know of no other method that offers comparable assurance for these elements of