An approach to preserving sufficient correctness in open resource coalitions

Most software that most people use most of the time needs only moderate assurance of fitness for its intended purpose. Unlike high-assurance software, where the severe consequences of failure justify substantial investment in validation, everyday software is used in settings in which occasional degraded service or even failure is tolerable. Unlike high-assurance software, which has been the subject of extensive scrutiny, everyday software has received only meager attention concerning how good it must be, how to decide whether a system is sufficiently correct, or how to detect and remedy abnormalities. The need for such techniques is particularly strong for software that takes the form of open resource coalitions - loosely-coupled aggregations of independent distributed resources. We discuss the problem of determining fitness for purpose, introduce a model for detecting abnormal behavior, and describe some of the ways to deal with abnormalities when they are detected.

[1]  M. Beers,et al.  The Merck Manual of Diagnosis and Therapy , 1982 .

[2]  Anish Arora,et al.  Component Based Design of Multitolerant Systems , 1998, IEEE Trans. Software Eng..

[3]  M. Shaw Sufficient Correctness and Homeostasis in Open Resource Coalitions: How Much Can You Trust Your Software System? , 2000 .

[4]  Virginie Wiels,et al.  V&V through inconsistency tracking and analysis , 1998, Proceedings Ninth International Workshop on Software Specification and Design.

[5]  Steve Easterbrook,et al.  Learning from inconsistency , 1996, Proceedings of the 8th International Workshop on Software Specification and Design.

[6]  Francesca Saglietti,et al.  Software Fault Tolerance: Achievement and Assessment Strategies , 1992 .

[7]  Alan Fekete,et al.  Modular reasoning about open systems: a case study of distributed commit , 1993, Proceedings of 1993 IEEE 7th International Workshop on Software Specification and Design.

[8]  W. T. Farris,et al.  Software requirements specifications , 1993 .

[9]  Mary Shaw Architectural Requirements for Computing with Coalitions of Resources , 1999 .

[10]  Shari Lawrence Pfleeger,et al.  Software Metrics : A Rigorous and Practical Approach , 1998 .

[11]  Robert Balzer Tolerating inconsistency (software development) , 1991, [1991 Proceedings] 13th International Conference on Software Engineering.

[12]  William G. Griswold,et al.  Dynamically discovering likely program invariants to support program evolution , 1999, Proceedings of the 1999 International Conference on Software Engineering (IEEE Cat. No.99CB37002).

[13]  Mary Shaw,et al.  When Good Models Meet Bad Data: Applying Quantitative Economic Models to Qualitative Engineering Judgments , 2000 .

[14]  Shari Lawrence Pfleeger,et al.  Software metrics (2nd ed.): a rigorous and practical approach , 1997 .

[15]  Michael R. Lyu,et al.  Handbook of software reliability engineering , 1996 .

[16]  M.S. Feather,et al.  Reconciling system requirements and runtime behavior , 1998, Proceedings Ninth International Workshop on Software Specification and Design.

[17]  Mary Shaw,et al.  Truth vs. knowledge: the difference between what a component does and what we know it does , 1996, Proceedings of the 8th International Workshop on Software Specification and Design.

[18]  Bashar Nuseibeh,et al.  To be and not to be: on managing inconsistency in software development , 1996, Proceedings of the 8th International Workshop on Software Specification and Design.

[19]  Robert Balzer,et al.  Tolerating Inconsistency , 1991, [1989] Proceedings of the 5th International Software Process Workshop.

[20]  Mark Klein,et al.  An experimental evaluation of domain-independent fault handling services in open multi-agent systems , 2000, Proceedings Fourth International Conference on MultiAgent Systems.

[21]  Michael A. Jackson,et al.  Software requirements and specifications - a lexicon of practice, principles and prejudices , 1995 .

[22]  Yennun Huang,et al.  Software Fault Tolerance in the Application Layer , 1995 .