The role of structure: a dependability perspective

  • Cliff B Jones
  • Brian Randell

8 Summary

Any development aimed at producing a dependable system should pay careful attention to issues of structuring. Any old structuring will not do — poor structuring can harm system performance, and impede system maintenance and evolution. But weak structuring can directly impair dependability. Structuring is in fact not an option — it would seem that the only way that humans can recognise entities and attempt to cope with complexity is by presuming — and then relying on — structure. The problem is to ensure that there is an effective reality to back up such presumptions, and that this reality can survive and evolve as needed for the successful continued deployment of the system.

We have attempted to maximize the use of notions from technical systems on whole (computer-based) systems; this is in no way intended to deny or ignore the differences between the ways in which human “components” and technical components contribute to the dependability problems, and solutions, of computer-based systems. However it does, we believe, allow a number of useful general issues to be identified and addressed.


Fault Tolerance Technical System Personal Health Record Intended Function Fault Removal 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.


Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.


  1. [1]
    Avizienis A, Laprie J-C, Randell B, Landwehr C (2004) Basic Concepts and Taxonomy of Dependable and Secure Computing, IEEE Transactions on Dependable and Secure Computing, vol. 1, no. 1, pp 11–33CrossRefGoogle Scholar
  2. [2]
    Rt Hon Lord Cullen QC (2000) The Ladbroke Grove Rail Enquiry, HSE Books, see Scholar
  3. [3]
    Jones Cliff B, A Formal Basis for some Dependability Notions (2003) Formal Methods at the Crossroads: from Panacea to Foundational Support. In: Aichernig Bernhard K, Maibaum Tom (eds) Springer Verlag, Lecture Notes in Computer Science, vol. 2757 pp191–206Google Scholar
  4. [4]
    Lehman M, Belady LA, (1985) (eds) Program evolution: processes of software change, Academic Press, APIC Studies in Data Processing No. 27, ISBN 012442441-4Google Scholar
  5. [5]
    Randell B (1975) System Structure for Software Fault Tolerance, IEEE Trans. on Software Engineering, vol. SE-1, no. 2, pp.220–232Google Scholar
  6. [6]
    J. Reason (1990) Human Error. Cambridge University Press, ISBN 0521314194Google Scholar
  7. [7]
    Dame Janet Smith QC (2005) Sixth Report: Shipman — The Final Report, HSE Books, see Scholar
  8. [8]
    US Department of Transportation (1998) Audit Report: Advance Automation System, Report No. AV-1998-113, US Department of Transportation, Office of Inspector GeneralGoogle Scholar

Copyright information

© Springer-Verlag London Limited 2006

Authors and Affiliations

  • Cliff B Jones
    • 1
  • Brian Randell
    • 1
  1. 1.University of Newcastle upon TyneNewcastle upon Tyne

Personalised recommendations