Software for Dependable Systems Sufficient Evidence? (2007) / Chapter Skim
Currently Skimming:
2 Proposed Approach
2 Proposed Approach
Pages 51-88
The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.
From page 51... ...
This evidence will take the form of a "dependability case," arguing that the required properties follow from the combination of the properties of the system itself (that is, the implementation) and the environmental assumptions.
|
From page 52... ...
For physical artifacts, limited testing provides compelling evidence of quality, with the continuity of physical phenomena allowing widespread inferences to be drawn from only a few sample points. In contrast, limited testing of software can rarely provide compelling evidence of behavior under all conditions.
|
From page 53... ...
First, the articulation of explicit dependability claims suggests that software systems requirements should be structured differently, with requirements being prioritized (separating the crucial dependability properties from other desirable, but less crucial, ones) and environmental assumptions being elevated to greater prominence.
|
From page 54... ...
ExPLICIT DEPENDAbILITy CLAIMS What Is Dependability? Until now, this report has relied on the reader's informal understanding of the term "dependable." This section clarifies the way in which the term is used in the context of this report.
|
From page 55... ...
For these reasons, the dependability of a software system cannot be judged by a simple metric. A system is dependable only with respect to particular claimed properties; unless these properties are made explicit, dependability has little meaning.
|
From page 56... ...
Software is merely one component of a system and a software component may be dependable in the context of one system but not dependable in another.4 3 See, for example, warranty and disclaimer information at the following Web pages for each of the companies mentioned: |
From page 57... ...
of a system -- may also be viewed as system components. If a system meets its dependability criteria only if people act in certain ways, then those people should be regarded as part of the system, and an estimate of the probability of them behaving as required should be part of the evidence for dependability.5 For example, if airline pilots are assumed to behave in a certain way as part of the dependability claim for an aircraft, then their training and the probability of human error become part of the system dependability analysis.
|
From page 58... ...
The result can be suboptimal whole-body stabilization6 and legitimate concern that faults in a device, or in its operation, may propagate to other devices. Because they are designed in isolation, the devices have separate operator interfaces and may present similar information in different ways and require similar operations to be performed in different ways, thereby inviting operator errors.
|
From page 59... ...
It is also important to rerun the system test suite (including additional tests showing that any known faults have indeed been corrected) as software maintenance can subtly violate the assumptions on which the dependability case was originally based.
|
From page 60... ...
Second, any claim about a service offered by a software component will be contingent on assumptions about the environment, and these assumptions will need to be made explicit. Stating the requirements for a particular software component will generally involve three steps: • first step is to be explicit about the desired properties: to articu The late the functional dependability properties precisely.
|
From page 61... ...
. Requirements, Specifications, and Domain Assumptions The properties of interest to the user of a system are typically located in the physical world: that a radiotherapy machine deliver a certain dose, that a telephone transmit a sound wave faithfully, that a printer make appropriate ink marks on paper, and so on.
|
From page 62... ...
The dependability properties of a software system, therefore, should be expressed as requirements, and the dependability case should demonstrate how these properties follow from the combination of the specification and the environmental assumptions. In some cases, the requirements, specification, and environmental and domain assumptions will talk about the same set of phenomena.
|
From page 63... ...
PROPOSED APPROACH FIGURE 2.1 Specification and requirements. The dependability case will involve m, s, and r.
|
From page 64... ...
The software system interacts with the operator through user interfaces and with the physical devices that control and monitor the beam settings. Assumptions include that the physical devices behave in certain ways and obey commands issued to them within certain tolerances, that the patient behaves in a certain way (not moving during irradiation, for example)
|
From page 65... ...
Had the dependability of the system been expressed and evaluated in terms of this property, attention might have been drawn to the domain assumption that lack of compression always accompanies being airborne, and the construction of a dependability case might have revealed that this assumption was invalid.9 The inevitable gap between specification and requirements properties speaks directly to the dependability of a service provision. At a minimum, software developers must appreciate this distinction, and as part of developing a dependable case there should be accountability for ensuring that the specification properties guarantee the requirements properties and for providing evidence (in the form of justifiable environmental assumptions)
|
From page 66... ...
; the evidence will need to be produced as part of the development process. Beta-testing, controlled release, and other field-testing strategies may provide some evidence that software is acceptably dependable in applications that only require low dependability, but even in these less-critical applications, the evidence obtained through field-testing will rarely be sufficient to provide high confidence that the software has the required properties.
|
From page 67... ...
This can lead to a culture where software producers follow the standard and then claim that their software has achieved the required dependability without providing any direct evidence that the resulting product actually has the required properties. In contrast, goal-based standards require the developers to state their dependability targets and to justify why these are adequate for the application, and then to choose development and assurance methods and to show how these methods provide sufficient evidence that the dependability targets have been achieved.
|
From page 68... ...
What constitutes sufficient evidence for dependability depends on the nature of the claim and the degree of dependability that is required. In general, however, the evidence will constitute a dependability case that takes into account all components of the system as a whole: the software, physical devices with which it interacts, and assumptions about the domain in which it operates (which will usually include both assumptions about the physical environment and assumptions about the behavior of human operators)
|
From page 69... ...
The case that the system satisfies a property has three parts: • An argument that the requirements properties will be satisfied by the specification of the system, in conjunction with the domain assumptions. As explained above, this requires that the domain assumptions are made explicit and shown to be justified.
|
From page 70... ...
(There is some evidence, however, that unit tests are not particularly effective or necessary if code is developed from a formal specification and is subject to static analysis.12) Testing is often an inexpensive way to catch major flaws, especially in areas (such as user interfaces)
|
From page 71... ...
If a test suite covers the entire state space, then every possible configuration has been tested, and the test is complete. In practice, however, the state space is usually so large that only a small proportion is exercised by a test suite.
|
From page 72... ...
In short, testing is a powerful and indispensable tool, and a development that lacks systematic testing should not be regarded as acceptable in any professional setting, let alone for critical systems. How a software supplier uses testing is important information in assessing the credibility of its dependability claims (see the discussion of transparency in Chapter 3)
|
From page 73... ...
Testing will be an essential component of a dependability case but will not in general suffice, because even the largest test suites typically used will not exercise enough paths to provide evidence that the software is correct and have little statistical significance for the levels of confidence usually desired. It is erroneous to believe that a rigorous development process in which testing and code review are the only verification techniques would justify claims of extraordinarily high levels of dependability.
|
From page 74... ...
But a custom test suite, however credible, may place an unreasonable burden on those assessing the dependability case. Until major advances are made, therefore, testing should be regarded in general as only a limited means of finding flaws, and the evidence of a clean testing run should carry weight in a dependability argument only to the extent that its implications for critical properties can be explicitly justified.
|
From page 75... ...
At the start, the domain assumptions and the required properties of the system should be made explicit; they should be expressed unambigu 20 For example, Robin Bloomfield and Bev Littlewood, 2006, "On the use of diverse arguments to increase confidence in dependability claims," in Structure for Dependability, D Besnard, C
|
From page 76... ...
At the other extreme, systems with highly critical assurance goals (such as airplanes) have driven their dependability cases down into the details of their components and have lacked regulatory mechanisms to support use of prequalified critical components, which would allow the case for the larger system
|
From page 77... ...
, 2004, "Reusable software components," AC 20-148, FAA, Washington, D.C. Available online at |
From page 78... ...
ExPERTISE Building software is hard; building dependable software is harder. Although the approach advocated in this report is designed to be as free as possible from the fetters of particular technologies, it also assumes that developers are using the very best techniques and tools available.
|
From page 79... ...
For the most part, these practices represent minimal standards of software engineering. In some cases, for development of a noncritical system in which high dependablity is not required, less stringent practices may make sense, as noted in the list.
|
From page 80... ...
Yoffie, 1998, Competing on Internet Time: Lessons from Netscape and Its Battle with Microsoft, Free Press, New York. 25 See Charles Perrow, 1999, Normal Accidents, Princeton University Press, Princeton, N.J.
|
From page 81... ...
:11-28. Available online at |
From page 82... ...
SOFTWARE FOR DEPENDABLE SYSTEMS • Trusted base. If the dependability properties of a system can be confined to a small trusted base consisting of only a few components so that the properties can be guaranteed without analyzing the rest of the system (except perhaps to establish certain noninterference properties)
|
From page 83... ...
Include an explicit description of the environment, with a glossary that covers the domain-specific terms used throughout the document. Articulate precisely and fully any environmental assumptions and have them reviewed by domain experts.
|
From page 84... ...
SOFTWARE FOR DEPENDABLE SYSTEMS their correctness. In noncritical developments this may involve little more than using tools that check for consistent use of names.
|
From page 85... ...
• Defensie programming. Make liberal use of runtime assertions to detect flaws in the code and incorrect environmental assumptions, and disable them in the deployed code only after careful consideration.
|
From page 86... ...
A robust and clear quality management system that is appropriate to the development organization and the character of the software being developed should be chosen, documented, and adhered to. Individuals should be trained in the aspects of the system that are relevant to their roles, and the process should encompass verification that its requirements are being adhered to and a systematic effort to review the costs and benefits of the process and improve it as appropriate.
|
From page 87... ...
All bug fixes should be fully documented and indexed against the appropriate bug report, and should result in reverification, including reexecution of regression test suites and the creation of new regression test cases. In any important application, each bug should be traced to its origin in the development, and a review should ensue to determine whether there are other similar bugs and what modifications to the development process could reduce the likelihood of such bugs occurring in the future.
|
From page 88... ...
SOFTWARE FOR DEPENDABLE SYSTEMS sis of a number of commercial projects is contained in a paper in IEEE Transactions on Software Engineering.34 The importance and effectiveness of capturing environmental assumptions is explained with reference to an e-commerce system, a safety protection system, and a railway signaling system in a 2001 conference report.35 Evidence-based dependability cases and explicit claims are widely used in safety-critical software development but have also been shown to be cost-effective when building commercial applications.36 The common experience, from these reports and others, is that these technical recommendations are practical to adopt and effective in use by experts. As with all engineering, cost-effectiveness is a primary objective; making dependability claims explicit allows developers to ensure that they achieve the necessary dependability without overengineering.
|
Key Terms
This material may be derived from roughly machine-read images, and so is provided only to facilitate research.
More
information on Chapter Skim is available.