Fiabilité des Systèmes et des Logiciels

déclenchée quelques heures après la mise en place d’une nouvelle version de Mosaic.

La défaillance a été causée par un programme de contrôle installé ponctuellement

pour s’assurer de la qualité des transmissions entre le central de réservation et les

postes de travail. Son fonctionnement, combiné à la forte charge de transmission de

données liée a la période de grands départs, a saturé le systeme et provoqué l’ensemble

Chapitre 1 - Problématique de la sûreté de fonctionnement des systèmes

informatiques

6

de ces perturbations (communiqué de la SNCF). Le bug a provoqué de longues files

d’attente devant les guichets, mais n’a pas affecté les finances de la SNCF, car 90%

des voyageurs de cette période avaient acheté leurs billets à l’avance.

• 30 et 31 Octobre : une panne de plus d’une journée est survenue sur le réseau fixe de

France Télécom. 26 commutateurs sur 600 ont été affectés dans la région parisienne,

le nord et l’ouest de la France. Quelques milliers d’appels ont été rejetés ou ne sont

pas parvenus à leur destinataire. La panne provenait d’une anomalie logicielle dans

un équipement de traitement de la voix sur IP (VoIP) situé à Reims. Cette anomalie

logicielle a provoqué des anormalités dans le formatage de la numérotation de certains

appels, qui ont déclenché des protections de sécurité pour éviter une panne du réseau

(communiqué de France Télécom).

• 17-18 Novembre : une panne de plus d’une journée est survenue sur le réseau mo-

bile de Bouygues Télécom. 1.37 millions de clients n’ont pas pu du tout utiliser

leur portable et 5.6 millions ont eu des difficultés pour accéder au réseau. La fac-

ture de la panne s’est élevée à 16 millions d’euros : une journée de chiffre d’affaires

perdue et l’équivalent en non facturé aux clients en compensation du désagrément

subi. La panne provenait du dysfonctionnement de la base de données qui sert à

repérer le mobile du client, lui permet d’acheminer ses appels et d’en recevoir. Deux

serveurs centraux jumeaux sont tombés en panne au même moment, dans deux en-

droits différents. Les deux serveurs sont du matériel classique et largement utilisé

par de nombreux opérateurs de téléphonie mobile avec, jusqu’à ce jour, une fiabilité

sans faille. En fonctionnement normal, ils se secourent en prenant le relais l’un de

l’autre. La panne est de nature exceptionnelle (communiqué de Bouygues Télécom).

• 3 Décembre : 800 terminaux de vente de la SNCF (sur 4000) ont été paralysés pendant

plus d’une journée. La panne provenait d’un algorithme défectueux qui a progressi-

vement contaminé les terminaux de vente en gare. Cet algorithme a pour objectif de

définir la zone de travail informatique de la transaction de paiement (communiqué

de la SNCF). Un nouveau bug du même type est survenu en novembre 2009.

Dans ces 4 cas, les problèmes ont été causés par des défaillances logicielles. Le site

www5.in.tum.de/∼huckle/bugse.html recense une impressionnante collection de défail-

lances logicielles. Parmi celles-ci :

• 4 Juin 1996 : la fusée Ariane 5 a explosé à cause d’une faute de conception logicielle,

et plus précisément un problème de réutilisation. Un programme de contrôle d’un

gyroscope de la fusée (en ADA) avait été transféré sans modification d’Ariane 4 à

Ariane 5. Or les trajectoires de vol d’Ariane 5 sont sensiblement différentes de celles

d’Ariane 4. Cela a provoqué un dépassement de mantisse qui a induit en erreur le

calculateur de pilotage et fini par faire exploser le lanceur. Cette erreur a coûté 500

millions de dollars uniquement en matériel, sans parler des retards engendrés et des

conséquences sur l’image de marque d’Arianespace.

• 3 mai 2000 : la moitié des ressources du réseau national de France Télécom ont été

paralysées.

• 3 juin 2004 : le trafic aérien britannique a été fortement perturbé pendant plusieurs

heures suite a une défaillance du systeme informatique de contrôle aérien, qui a privé

tous les appareils en vol de ressources informatiques pendant deux heures.

1.1 Contexte

7

• 8 octobre 2005 : un défaut dans le système de contrôle en vol de la fusée russe Rockot

provoque la perte du satellite CryoSat chargé d’étudier l’influence du réchauffement

climatique sur la fonte des glaces polaires. Coût de la mission : 136 millions d’euros.

• Septembre 2007 : un bug dans Excel 2007 provoque des résultats de multiplication

fantaisistes comme 77.1 × 850 = 100000 (au lieu de 65535)i.

• 2007 : les retards de livraisons de l’Airbus A380 sont en partie dus a un probleme

logiciel dont l’origine tient au fait que les sites d’Hambourg et Toulouse ont utilisé

deux versions différentes du logiciel de CAO de Dassault Systèmes CATIA. Les

pénalités versées aux compagnies aériennes se chiffrent à plusieurs milliards d’euros.

• Mars 2008 : Chrysler rappelle 25000 Jeeps Cherokee et Commander pour corriger

un défaut dans le logiciel de transmission automatique.

• Janvier 2010 : un bug dans le logiciel de lecture des puces électroniques des cartes

bancaires fabriquées par Gemalto a empêché 30 millions d’allemands de se servir de

leur carte de crédit pendant près d’une semaine. Pour certains, ce “bug de l’an 2010”

a largement surpassé le fameux “bug de l’an 2000”...

Ces pannes majeures et répétées ont sérieusement entamé la confiance du public dans

la sûreté des réseaux de télécommunication et des systèmes informatiques en général.

Dans de nombreux secteurs, on a pu constater que les défaillances sont de plus en plus

fréquentes. En effet, dans un contexte fortement concurrentiel, les entreprises cherchent à

réduire leurs coûts et avancer les dates de lancement de leurs produits, au détriment en

particulier de la sûreté de fonctionnement.

Par exemple, la fiabilité des ordinateurs de bureau a énormément chûté, en même temps

que les coûts. La garantie constructeur est passée de 3 ans à 1 an en quelques années et

les extensions de garantie sont tres cheres, ce qui indique clairement que les pannes des

PC sont très fréquentes.

Extraits d’un article de Libération du 19 novembre 2004 (voir document sur le Kiosk),

suite à la succession de pannes des réseaux informatiques français :

• A la racine de toutes ces pannes, on trouve des défaillances de l’informatique.

• Il s’agit d’anomalies logicielles.

• On contrôle la qualité des services ou encore la couverture des réseaux, mais pas la

vulnérabilité des systèmes.

• Si la panne survient, c’est que les opérateurs rognent sur tout, y compris sur la

fiabilité de leur système.

• Le consommateur est bien en droit de réclamer aujourd’hui la garantie d’une fiabilité

absolue. Celle-ci doit devenir un motif d’achat, donc un argument de vente impératif.

Pour que la fiabilité devienne un argument de vente impératif, il faut être capable de

l’évaluer ou la mesurer. C’est l’objectif essentiel de ce cours.

Chapitre 1 - Problématique de la sûreté de fonctionnement des systèmes

informatiques

8

1.2 Terminologie générale de la sûreté de fonction-

nement

Toutes les entreprises et les collectivités locales, nationales et internationales, sont

concernées par la mesure, la gestion et la prévention des risques. Cela englobe les risques

industriels, environnementaux, sanitaires, financiers, etc... Une des composantes princi-

pales de la gestion des risques est la sûreté de fonctionnement.

Un systeme est un ensemble de composants en interaction destiné a accomplir une

tâche donnée. C’est le cas par exemple des systemes de production, systemes de transport,

systèmes informatiques, etc...

La sûreté de fonctionnement (SdF, en anglais dependability) d’un système est la

propriété qui permet à ses utilisateurs de placer une confiance justifiée dans le service

qu’il leur délivre. On dit aussi que la SdF est la science des défaillances.

Un système subit une défaillance quand il ne peut plus délivrer le service attendu. La

panne est l’état du système résultant d’une défaillance.

La sûreté de fonctionnement comprend 5 composantes : la fiabilité, la disponibilité, la

maintenabilité, la sécurité-innocuité et la sécurité-confidentialité :

• La fiabilité (reliability) est la caractéristique du système exprimée par la probabilité

qu’il délivre le service attendu dans des conditions données et pendant une durée

déterminée. La fiabilité exprime l’aptitude à la continuité du service.

• La disponibilité (availability) est exprimée par la probabilité que le système délivre

le service attendu dans des conditions données et à un instant donné. La disponibilité

caractérise donc l’aptitude du systeme a fonctionner quand on a besoin de lui.

• La maintenabilité (maintainability) caractérise l’aptitude du systeme a être réparé

quand il est défaillant, ou à évoluer.

• La sécurité-innocuité (safety) caractérise l’aptitude du systeme a ne pas encourir

de défaillances catastrophiques.

• La sécurité-confidentialité (security) caractérise l’aptitude du systeme a se prémunir

contre les accès ou manipulations non autorisées (virus, attaques,...).

Un systeme non réparable est un systeme qui est mis au rebut dès qu’il tombe en

panne. C’est le cas des petits systemes (par exemple des ampoules) ou des systemes qui

coûtent plus cher a réparer qu’a remplacer.

Un systeme réparable est un systeme qui, après sa défaillance, peut être remis en

état de marche par des actions de réparation ou maintenance. C’est le cas de tous les

systemes complexes et en particulier des systemes informatiques. Pour ces derniers, au

lieu de réparation, on parle plutôt de correction, débogage ou mise à jour.

La maintenance des systèmes est de deux types :

• La maintenance corrective ou réparation remet en fonctionnement un système

après sa défaillance.

1.3 Fiabilité des matériels ou des logiciels

9

• La maintenance préventive est effectuée alors que le système fonctionne et a pour

but de retarder l’occurrence des défaillances futures.

Dans les études de sûreté de fonctionnement, on distingue les approches boˆıte noire et

boˆıte blanche :

• Approche boˆıte blanche ou structurelle : on considere qu’un systeme complexe

est constitué de composants et que sa fiabilité dépend à la fois de la fiabilité de

ses composants et de la façon dont le bon fonctionnement ou la panne de chaque

composant influe sur le bon fonctionnement ou la panne du système tout entier. En

particulier, on considere souvent qu’un systeme réparable est constitué de compo-

sants non réparables. Quand un composant tombe en panne, on le remplace par un

neuf, mais le systeme complet, lui, n’est pas remis a neuf.

• Approche boˆıte noire ou globale : on considere le systeme comme un tout, qu’on

ne cherche pas a décomposer en composants. On s’intéresse alors a la suite des

défaillances et réparations successives du système.

1.3 Fiabilité des matériels ou des logiciels

A priori, les défaillances des systèmes informatiques peuvent être soit d’origine matérielle,

soit d’origine logicielle. En pratique, plus de 80 % sont d’origine logicielle. C’est le cas

de tous les exemples présentés dans la section 1.1. On s’intéressera donc en priorité aux

problèmes logiciels. Mais on peut noter qu’il existe des différences fondamentales entre la

fiabilité des matériels et celle des logiciels.

• Les défaillances des matériels sont essentiellement dues à l’usure (ou vieillissement)

et aux facteurs environnementaux, tandis que celles des logiciels sont dues à des

fautes de conception (ou bugs), c’est-a-dire a des erreurs humaines.

• Un matériel s’use, un logiciel ne s’use pas.

• La maintenance des matériels ralentit le vieillissement des systèmes mais ne l’empêche

pas, tandis que la correction des logiciels augmente leur fiabilité.

• Un logiciel non utilisé ne tombe pas en panne (le terme de panne est d’ailleurs peu

utilisé pour le logiciel). Un matériel non utilisé peut tomber en panne du fait de

l’usure ou des facteurs environnementaux.

• En logiciel, une faute bien repérée et corrigée est éliminée définitivement et ne peut

plus se manifester. En matériel, on peut observer des défaillances répétables ou chro-

niques.

• La sensibilité d’un matériel à son environnement est assez forte, mais on peut

néanmoins considérer qu’un matériel a une fiabilité en soi : les constructeurs quan-

tifient la fiabilité d’une ampoule électrique quel que soit son environnement. En re-

vanche, la sensibilité d’un logiciel a son environnement, à travers son profil opération-

nel, est extrêmement forte. Un logiciel truffé de fautes peut très bien fonctionner sans

défaillance si le profil opérationnel n’active pas ces fautes. Un matériel ayant beau-

coup de défauts ou tres usé tombera fatalement en panne, quelle que soit la maniere

dont on l’utilise.

Chapitre 1 - Problématique de la sûreté de fonctionnement des systèmes

informatiques

10

• Quand un matériel est en panne, il ne peut pas fonctionner tant qu’on ne l’a pas

réparé. Au contraire, un logiciel peut être relancé immédiatement après une défaillance.

On voit que les différences sont nombreuses entre fiabilité des matériels et fiabilité des

logiciels. On ne pourra donc pas traiter les deux aspects de la même manière. Historique-

ment, les concepts de la fiabilité ont été introduits pour les matériels. On commencera

donc par introduire ces concepts pour les matériels, puis on présentera les spécificités des

logiciels.

1.4 Le risque logiciel

Les défaillances des logiciels sont causées par des fautes dans les programmes. Or,

d’une part, une étude [16] a montré qu’un programmeur professionnel fait en moyenne 6

fautes pour 1000 lignes de code (LOC) écrites, et d’autre part, la taille et la complexité

des logiciels ne cesse d’augmenter. Par exemple :

• la navette spatiale américaine a besoin pour voler de 500 000 LOC logiciel embarqué

et 3 millions et demi de LOC au sol.

• les réseaux téléphoniques utilisent des millions de LOC pour fonctionner.

• le nombre de LOC est passé de moins de 5 millions pour Windows 95 à plus de 50

millions pour Windows Vista.

• plus généralement, un logiciel commercial standard fait en moyenne 350 000 LOC.

Par conséquent, cela fait environ 2000 fautes potentielles pour un logiciel standard, 24

000 pour la navette spatiale et 300 000 pour Vista !

Evidemment, tout est fait pour éliminer ces fautes, essentiellement par le test du

logiciel. Mais il est extrêmement difficile et coûteux de détecter et corriger des fautes

dans un logiciel. En effet, une étude de Microsoft [16] a établi qu’il fallait en moyenne 12

heures de travail pour détecter et corriger une faute. Si un logiciel contient 2000 fautes,

il faut donc passer 24 000 heures pour le déboguer, soit presque 3 ans de travail cumulé.

C’est pourquoi Microsoft emploie autant de personnel pour tester, vérifier et valider les

programmes que pour les créer. Et malgré cela, chacun a pu expérimenter qu’il subsiste

des erreurs dans les logiciels de Microsoft. Une étude plus récente [17] évalue à 60% du

budget total d’un projet informatique le coût de la détection et correction des erreurs

logicielles (ou maintenance du logiciel).

Malgré tous ces efforts, la complexité de la tâche fait qu’il reste toujours des fautes

dans un logiciel. Comme partout, et peut-être même moins que partout, le zéro défaut est

impossible. Quand ces fautes résiduelles se manifestent, leurs conséquences peuvent aller

du minime au franchement catastrophique, comme on l’a vu dans la section 1.1.

Il est donc impératif de tout faire pour éviter que des pannes informatiques majeures

se produisent. Pour cela, on dispose de nombreuses méthodes dont le but est de produire

des logiciels de fonctionnement sûr. On peut classer ces méthodes en 4 catégories [10, 11] :

• La prévention des fautes : ces méthodes ont pour but d’empêcher l’occurrence et

l’introduction de fautes dès la conception du logiciel. Par exemple, on a de plus en

plus souvent recours à des méthodes formelles pour développer les spécifications.

1.5 Méthodes d’évaluation de la fiabilité des logiciels selon les étapes du

cycle de vie

11

• L’élimination des fautes : ces méthodes ont pour but de détecter des fautes dans

un programme déjà écrit. Elles comprennent les preuves de programmes, les inspec-

tions formelles, la vérification et surtout le test du logiciel.

• La tolérance aux fautes : ces méthodes ont pour but de permettre au système de

fonctionner correctement même en présence de fautes. On peut par exemple utiliser

de la redondance.

• La prévision des fautes : ces méthodes ont pour but d’estimer la présence des

fautes et de prévoir les défaillances futures du sytème.

Les méthodes présentées dans ce cours rentrent dans la dernière catégorie. En effet, il

ne suffit pas d’avoir utilisé tous les moyens possibles pour développer un logiciel fiable,

encore faut-il s’assurer qu’il l’est effectivement : il faut des méthodes pour atteindre des

objectifs de fiabilité (les trois premières catégories, qui concernent le génie logiciel) et

faire appel a d’autres méthodes pour savoir si ces objectifs sont atteints (la quatrieme

catégorie, qui fait intervenir des concepts probabilistes et statistiques). Par conséquent,

il est très important de pouvoir prévoir l’occurrence des défaillances, et donc d’évaluer,

mesurer ou quantifier la fiabilité d’un logiciel. Notons que cette quatrième catégorie de

méthodes est aujourd’hui moins utilisée dans l’industrie que les trois autres [19], mais que

cela va évoluer, notamment avec la prise en compte de ces notions dans les normes [2].

Pour les logiciels, on réduit parfois le concept de sûreté de fonctionnement à celui de

sécurité-confidentialité. Cependant la sécurité-confidentialité concerne exclusivement les

dysfonctionnements dus à des actes de malveillance volontaires (virus, attaques, etc.) alors

que la sûreté de fonctionnement prend également en compte les dysfonctionnements non

volontaires : pannes matérielles, fautes logicielles, erreurs humaines non intentionnelles,

etc.

1.5 Méthodes d’évaluation de la fiabilité des logiciels

selon les étapes du cycle de vie

Les méthodes d’évaluation de la fiabilité des logiciels varient suivant la nature des

informations disponibles. Celles-ci sont étroitement liées au cycle de vie du logiciel, comme

on le voit dans le tableau 1.1 [16] .

Phase du cycle de vie Pourcentage d’erreurs Pourcentage d’erreurs

introduites

55%

30%

10%

5%

Analyse

Conception

Codage et test

Vie opérationnelle

détectées

18%

10%

50%

22%

Table 1.1 – Pourcentages d’erreurs introduites et détectées selon les phases du cycle de

vie du logiciel

Les types d’erreurs dans les différentes phases sont les suivantes :

Chapitre 1 - Problématique de la sûreté de fonctionnement des systèmes

informatiques

12

• Analyse : le logiciel ne répond pas à l’attente des utilisateurs.

• Conception : mauvaise traduction des spécifications.

• Codage et test : erreurs de programmation ou de correction.

• Vie opérationnelle : erreur dans les mises a jour du systeme.

On constate que la majeure partie des erreurs sont introduites dans les premières phases

du cycle de vie (85% en analyse et conception) et détectées dans les dernières phases (72%

en codage, test et vie opérationnelle).

Dans les phases d’analyse, conception et codage, le système n’est pas encore construit,

donc il ne peut pas être utilisé et aucune défaillance n’est observée. Les éléments pouvant

être utilisés pour des prévisions de fiabilité sont la structure du système et les métriques

logicielles (nombre de lignes de code, nombre cyclomatique du graphe de contrôle, mesures

d’architecture et de spécifications, etc... [8]). A ce niveau, on peut évaluer la qualité du

logiciel, mais pas sa fiabilité. Or on ne sait pas mesurer la corrélation entre qualité et

fiabilité d’un logiciel.

En phase de test et en vie opérationnelle, le système fonctionne, des défaillances sont

observées et des corrections sont apportées au logiciel pour remédier aux fautes apparues.

L’essentiel des méthodes d’évaluation de la fiabilité repose sur l’observation et l’analyse

statistique de cette suite de défaillances et corrections successives.

Tout comme les matériels, les logiciels complexes sont constitués de modules unitaires

que l’on assemble. Si on est capable d’évaluer la fiabilité de chaque module et d’analyser

les liens entre les différents modules, on peut appliquer les méthodes structurelles (boˆıte

blanche) d’évaluation de fiabilité. Ce n’est pas du tout facile en pratique. Aussi considère-

t-on en général un logiciel comme un tout et on évalue sa fiabilité par une approche boˆıte

noire. C’est ce que nous ferons dans ce cours.

1.6 Utilisation des évaluations de fiabilité des logi-

ciels

Dans un premier temps, les évaluations de fiabilité permettent de quantifier la confiance

d’un utilisateur envers un systeme informatique, c’est-a-dire d’évaluer quantitativement

le risque que l’on prend en le faisant fonctionner. Puis elles permettent de s’assurer

que le logiciel a atteint un niveau de fiabilité conforme aux objectifs exprimés dans les

spécifications. Un objectif de fiabilité est usuellement exprimé en termes de taux de

panne ou taux de défaillance. Par exemple, pour le récent métro parisien sans conduc-

teur Meteor, les objectifs annoncés étaient un taux de panne par rame et par heure

inférieur a 10−9 pour le matériel et inférieur a 10−11 pour le logiciel.

Pour les systèmes faisant l’objet d’une garantie, les évaluations de fiabilité permettent

de déterminer la durée et le coût de la garantie.

Si les mesures de fiabilité montrent que l’objectif n’est pas atteint, elles peuvent per-

mettre d’évaluer l’effort de test à fournir pour atteindre l’objectif, et en particulier d’es-

timer le temps nécessaire pour y parvenir. Par conséquent, les mesures de fiabilité four-

nissent un critere d’arrêt des tests : on arrête les tests des qu’on peut prouver, avec

un niveau de confiance raisonnable, qu’un objectif donné de fiabilité est atteint. Une

expérience menée à AT&T a montré que la mise en place des mesures de fiabilité a permis

1.7 Terminologie spécifique aux logiciels

13

une réduction de 15% de la durée de la période de tests, ce qui a entrainé un gain de 4%

sur le coût total du projet, alors que le surcoût du aux mesures n’a représenté que 0.2%

de ce coût total [16]. D’autres exemples sont mentionnés dans [20].

Par ailleurs, une mesure de fiabilité est un moyen d’évaluer quantitativement la qualité

d’une méthode de génie logiciel donnée. Elle peut aussi fournir un indicateur de perfor-

mance d’un programmeur ou d’un testeur. Cette dimension humaine délicate est parfois

un frein à l’utilisation effective des évaluations de fiabilité.

1.7 Terminologie spécifique aux logiciels

En première approche, la fiabilité d’un logiciel est la probabilité qu’il fonctionne sans

défaillances pendant une durée donnée et dans un environnement spécifié. C’est donc

une notion temporelle. Le temps considéré peut être le temps d’exécution CPU (temps

effectivement passé par la machine pour exécuter le programme), le temps calendaire, voir

également un nombre d’opérations ou de transactions. A terme, seul le temps calendaire

est important. Notons que pour certains systemes (les systemes réactifs), le temps n’est

pas l’élément primordial : ce qui compte, c’est qu’une exécution se déroule correctement.

Alors, la fiabilité est définie comme la probabilité qu’une exécution soit correcte. Dans la

suite, nous ne nous intéresserons pas a ce type de systeme et nous conserverons donc la

définition temporelle de la fiabilité.

Une défaillance se produit quand le résultat fourni par le logiciel n’est pas conforme

au résultat prévu par les spécifications. Pour éclaircir cette notion, on peut considérer

qu’un logiciel est un système qui, par l’intermédiaire d’un programme, transforme des

données d’entrée en résultats ou données de sortie. Un programme est une suite

finie d’instructions codées qui exécute une ou plusieurs tâches spécifiées. L’exécution d’un

programme peut donc être vue (voir figure 1.1) comme une application de l’ensemble des

données d’entrée dans l’ensemble des données de sortie (appelés espace des entrées et

espace des sorties).

(cid:99)

......................................

Programme

......................................

(cid:99)

Espace des entrées

Espace des sorties

Figure 1.1 – L’exécution d’un programme

Les spécifications définissent quelle doit être la donnée de sortie pour chaque donnée

d’entrée possible. Si, pour une donnée d’entrée particulière, la sortie fournie par le pro-

Chapitre 1 - Problématique de la sûreté de fonctionnement des systèmes

informatiques

14

gramme n’est pas celle prévue par les spécifications, il y a défaillance. On voit ainsi

apparaˆıtre une relation forte entre donnée d’entrée et défaillance, sur laquelle nous re-

viendrons.

Une faute logicielle ou bug est un défaut du programme qui, exécuté dans certaines

conditions, entraˆınera une défaillance. Une faute est un phénomene intrinseque au pro-

gramme, elle existe même quand le logiciel n’est pas utilisé. A l’inverse, une défaillance

est un phénomène dynamique : le programme doit être exécuté pour qu’elle se manifeste.

Une faute est créée suite à une erreur humaine de l’analyste, du concepteur ou du pro-

grammeur. Aussi, on emploie le terme de faute de conception. Les erreurs peuvent être

de spécification, de conception ou de codage. Il est également possible qu’une défaillance

d’un systeme informatique soit due a un problème matériel. Ce type de défaillance est en

général facilement identifiable. Nous ne le traiterons pas dans la suite, où nous supposerons

que toutes les défaillances sont dues à des fautes de conception (au sens large).

Si on pouvait tester toutes les entrées possibles d’un logiciel, on détecterait fatalement

toutes les fautes. Mais le nombre d’entrées possibles est beaucoup trop grand pour cela.

Il faut donc déterminer dans l’espace des entrées un sous-ensemble d’entrées à tester.

Le profil opérationnel définit le choix des entrées et la fréquence de sollicitation du

logiciel, en associant à chaque entrée ou groupe d’entrées sa probabilité d’être fournie

au programme a un instant donné. Le profil opérationnel est en général tres différent en

phase de test et en vie opérationnelle.

Quand une défaillance survient, on cherche à détecter la faute qui a provoqué cette

défaillance et à l’éliminer. On effectue alors une correction ou débogage. Parfois, un

logiciel est amené a changer radicalement certaines de ses fonctionnalités. On procede

alors a un changement de spécifications, qui va aboutir a une nouvelle version du

logiciel. Les corrections et les changements de spécifications peuvent être interprétés de

la même manière comme des modifications du programme. Une modification d’un logiciel

est parfois appelée une maintenance logicielle. La correction a pour but de réduire l’oc-

currence d’apparition des défaillances, donc elle devrait augmenter la fiabilité du logiciel.

1.8 Exemple de données

Le système observé est une machine UNIX sur laquelle tourne un gros logiciel de bases

de données en phase de test. Le systeme a été observé sur un an, du 14 juin 1995 a 16h14

au 11 juin 1996 à minuit.

Un démon a noté tous les instants de panne, les causes des pannes et les instants de

redémarrage de la machine. Suivant la nature des interruptions, des corrections ont été

apportées ou pas au logiciel. Le temps pris en compte est le temps calendaire. Le tableau

1.2 présente un extrait du rapport de fiabilité brut généré automatiquement par le démon.

On peut facilement en extraire les durées de bon fonctionnement et de non fonctionnement

successives.

On constate que les durées de non fonctionnement de la machine sont, d’une part

négligeables par rapport aux durées de bon fonctionnement, et d’autre part difficilement

exploitables : on a une valeur a...