Software Fault Tolerance: Achievement and Assessment Strategies (Research Reports Esprit / Project 300. REQUEST) (Research Reports Esprit (1)).

Kersken, Manfred:

ISBN 10: 354055212X / ISBN 13: 9783540552123

Published by Springer, 1992

About this Item

260 p. In very good condition. ISBN: 9783540552123 Sprache: Englisch Gewicht in Gramm: 446 17,0 x 1,5 x 24,2 cm, softcover.

Seller Inventory # 59593

Bibliographic Details

• Title: Software Fault Tolerance: Achievement and Assessment Strategies (Research Reports Esprit / Project 300. REQUEST) (Research Reports Esprit (1)).
• Publisher: Springer
• Publication Date: 1992
• Language: English
• ISBN 10: 354055212X
• ISBN 13: 9783540552123
• Binding: Soft cover
• Condition: Sehr gut
• Weight: 446 grams
• Seller catalogs:
  • Informatik, Hardware, Software

About this title

Synopsis

The first ESPRIT programme contained several ambitious projects. of which REQUEST. with its wide brief covering all issues of assessment of quality and reliability of software process and product. was one. Within REQUEST. the research described in this volume. concerning those special problems of software that is required to have extremely high reliability. was particularly difficult and ambitious. The problems of software reliability are essentially twofold. On the one hand there is a concern with methods for achieving adequate reliability. on the other hand there is a need to evaluate what has actually been achieved in a particular case. Naturally. far more effort has been spent over the years on the former problem; indeed. there is a sense in which all of conventional software engineering can be seen as a response to this problem. However. it is becoming clearer than ever that we can only claim to have a truly sCientific approach. and so justify the description software engineering. when we are able to measure the attributes of process and product. It is still common to find software development methods recommended to users on purely anecdotal grounds. This is not good enough. Rational choices between rival approaches can only be made on the basis of quantified costs and benefits. Even more worrying is the tendency to argue that a software product can be depended upon merely because it has been developed by honest men using such anecdotal 'good practice'.