[CSUSB]>> [CNS]>> [CSE]>> [R J Botting]>> biba.php
Bibliographic Item (1.0)
- Daniel Jackson
- A Direct Path to Dependable Software
- Commun ACM V52n4(Apr 2009)pp78-88
[ 1498765.1498787 ]
[ publications.html ]
- =ESSAY RISKS COSTS not PROCESSES CRITICAL PROPERTIES CLAIMS QUALITIES REQUIREMENTS
- Based on a study done for NRC lead to
- Lots of examples of RISKS and how they occurred and how the effect reasoning about the dependability od a system.
- A dependability case provides evidence, in the form of claims, that certain critical properties will hold.
- The analysis of the critical properties and the claims that support them starts on day one of a project,
and guides architectural decisions.
Well chosen architecture -- modular, decoupled, simple --
makes it cheaper to establish a dependability case.
- Dependability cases should develop "hand-in-hand" with the product.
The developers chose techniques and technology to support the claims.
- Critical properties should be close to the user/client/real world.
- All claims depend on assumptions about the client's world: an air traffic control system can not stop a pilot
deliberately crashing into another aeroplane.
- Claims connect the developing system, via assumptions, to the critical properties.
- A dependability case must be auditable, complete, and sound.
- A rigorous process can help establish a dependability case -- but need not be burdensome.
- A risk-averse and meticulous culture will help.
- Need robust platforms and tools -- language design.
- The correctness of code is not the weakest link in the chain -- only 3% of the time...
- Testing and analysis contribute as well.
- Credible tools -- example of a broken proof: binary search when bounds > largest integer!
- See also
(Outer vs inner requirements)
Search for bibliographic items containing a matching string.
Search for a specific bibliographic item by name.
To see the complete bibliography (1Mb+) select:[Bibliography]