Notes

• [*1]
  Texte de la 295^e conférence de l’Université de tous les savoirs donnée le 21 octobre 2000.
• [*2]
  Commission on Critical Infrastructures Protection, Critical Foundations — Protecting America’s Infrastructures, Report of the President’s Commission on Critical Infrastructures Protection, oct. 1997.
• [*3]
  Laprie (J.-C), Arlat (J.), Blanquart (J.-P.), Costes (A.), Crouzet (Y.), Deswarte (Y.), Fabre (J.-C.), Guillermain (H.), Kaâniche (M.), Kanoun (K.), Mazet (C.), Powell (D.), Rabéjac (C.), Thévenod (P.), Guide de la sûreté de fonctionnement, Toulouse, Cépaduès Éditions, 1995.
• [*4]
  Cramp (R.), Vouk (M. A.), W. Jones, « On operational availability of a large software-based telecommunications system », Proc. 3^rd Int. Symp. on Software Reliability Engineering, Research Triangle Park, North Carolina, oct. 1992, p. 358-366.
  Gray (J.), « A census of Tandem system availability between 1985 and 1990 », IEEE Trans. on Reliability, vol. 39, n^o4, oct. 1990, p. 409-418.
  Wood (A.), « NonStop availability in a client/server environment », Tandem Technical Report 94.1, march 1994.
• [*5]
  Donnelly (M.), Everett (W.), Musa (J.), Wilson (G.), Best Current Practices : Software Reliability Engineering, AT Bell Labs, 1992.
• [*6]
  Craigen (D.), Gehrart (S.), Ralston (T.), « An international survey of industrial applications of formal methods », report NIST GCR 93/626, National Institute of Standards and Technology, march 1993.
• [*7]
  Craigen (D.), Gehrart (S.), Ralston (T.), op cit.
• [*8]
  Ramamoorthy (C.V.), Prakash (A.), Tsai (W.-T.), Usuda (Y.), « Software Engineering : Problems and Perspectives », IEEE Computer, vol. 17, n^o 10, 1984, p. 191-209.
• [*9]
  Paulk (M. C.), Curtis (B.), Chrissis (M. B.), Weber (C. V.), « Capability maturity model for software », Software Engineering Institute, report CMU/SEI-93-TR-24, ESC-TR-93-177, fév. 1993.
• [*10]
  Diaz (M.), Siglio (J.), « How software process improvement helped Motorola », IEEE Software, vol. 14, n^o 5, sept.-oct. 1997, p. 75-81.
• [*11]
  Schroebelen (P.), Berard (B.), Bidoit (M.), Laroussinie (F.), Petit (A.), Vérification de logiciels — Techniques du model-checking, Paris, Vuibert, 1999.
• [*12]
  Observatoire français des techniques avancées, Informatique tolérante aux fautes, ARAGO 15, Paris, Masson, 1994, chap. 13.
• [*13]
  Baber (R. L.), « Comparison of electrical “engineering” of Heaviside’s times and software “engineering” of our times », IEEE Annals of the History of Computing, vol. 19, n^o 4, 1997, p. 5-17.
• [*14]
  OFTA 1994, op. cit., chap. 14.
• [*15]
  Kantz (H.) et Koza (C.), « The ELEKTRA Railway Signalling-System : Field Experience with an Actively Replicated System with Diversity », in Proc. 25^th Int. Symp. on Fault-Tolerant Computing (FTCS-25), Pasadena, CA, USA, juin 1995, p. 453-458.
• [*16]
  Laprie (J.-C.), Arlat (J.), Béounes (C.), Kanoun (K.), « Definition and analysis of hardware- and software-fault-tolerant architectures », IEEE Computer, vol. 23, n^o 7, juillet 1990, p. 39-51.
• [*17]
  Gray, op. cit.
• [*18]
  Huang (Y.), Kintala (C.), « Software fault tolerance in the application layer », in Software Fault Tolerance, M. Lyu (éd.), New York, Wiley, 1995.
• [*19]
  Iyer (R. K.), Lee (I.), « Software fault tolerance in computer operating systems », in Software Fault Tolerance, M. Lyu (éd.), New York, Wiley, 1995.
• [*20]
  Arlat (J.) coord., Composants logiciels et sûreté de fonctionnement, Paris, Hermes Science, 2000.
• [*21]
  Salles (F.), Arlat (J.), Fabre (J.-C.), « Can we rely on COTS microkernels for building fault-tolerant systems ? », in Proc. 6^th IEEE Workshop on Future Trends of Distributed Computing Systems, Tunis, oct. 97, p. 189-194.