Quantification de La Fiabilité Des Logiciels

Réf.
: SE2520 V2
Quantification de la fiabilité
Date de publication :
10 octobre 2012 des logiciels
Date de dernière validation :
01 mars 2015
Cet article est issu de : Technologies de l'information | Technologies logicielles

Architectures des systèmes
par Frédérique VALLÉE
Mots-clés Résumé Les modèles de quantification de la fiabilité d’un logiciel sont encore très peu
fiabilité | taux de défaillance | utilisés dans l'industrie et restent même un sujet assez controversé. Cet article décrit les
exigences de fiabilité | modèles
de croissance fondements théoriques de la modélisation de la fiabilité et en explique les modes
d'utilisation. Son objectif est de montrer qu'il s'agit d'une technique statistique valide et
applicable aux logiciels. Il est également fait un bilan des pratiques industrielles actuelles
et, pour finir, sont données des pistes potentielles d'amélioration de ces pratiques dans
l'avenir.
Keywords Abstract Software reliability models are today seldom used in industry and remain a
reliability | failure rate | rather controversial topic. This article describes the theoretical bases of software
reliability requirements |
reliability growth models reliability modeling and explains how to put them into practice. Its goal is to demonstrate
that it is a statistical technique that is valid and adapted to the software. This article also
provides a review of the current industrial practices and presents potential means of
improvement for these practices in the future.
Pour toute question :

Service Relation clientèle
Techniques de l’Ingénieur
Immeuble Pleyad 1 Document téléchargé le : 06/11/2019
39, boulevard Ornano
93288 Saint-Denis Cedex Pour le compte : 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Par mail :
infos.clients@teching.com
Par téléphone :
00 33 (0)1 53 35 20 20 © Techniques de l'Ingénieur | tous droits réservés
Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
Quantification de la fiabilité
des logiciels
Parution : octobre 2012 - Dernière validation : mars 2015 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
par Frédérique VALLÉE

Agrégée de mathématiques
Docteur en statistiques
Directeur associé de la société ALL4TEC, Massy
1. Problématique générale de la fiabilité du logiciel ........................ SE 2 520v2 2

1.1 Qu’est-ce que la fiabilité du logiciel ?....................................................... — 2
1.2 Fiabilité du logiciel et sûreté de fonctionnement des systèmes
programmés ............................................................................................... — 2
1.3 Quel mode de quantification adopter ?.................................................... — 2
1.4 Fiabilité prévisionnelle et fiabilité expérimentale ................................... — 3
2. Modèles de croissance de fiabilité .................................................... — 3
2.1 Évolution des modèles .............................................................................. — 3
2.2 Principaux modèles ................................................................................... — 3
3. Mise en œuvre des modèles ................................................................ — 5
3.1 Processus de collecte et d’étude............................................................... — 5
3.2 Données d’entrée de la modélisation....................................................... — 8
3.3 Exemple type d’étude de fiabilité ............................................................. — 9
3.4 Allocations de fiabilité et formalisation d’exigences de fiabilité ........... — 9
3.5 Recommandations pour la mise en œuvre des modèles ....................... — 10
4. Pratiques industrielles actuelles........................................................ — 11
4.1 Bilan mitigé................................................................................................. — 11
4.2 Intérêt certain du côté des donneurs d’ordre .......................................... — 11
4.3 Regain d’intérêt grâce à l’automatisation des tests ................................ — 12
Pour en savoir plus ......................................................................................... Doc. SE 2 520v2
ien que les modèles de quantification de la fiabilité du logiciel soient un

B sujet controversé [1], ils restent les seuls à permettre une évaluation
objective du niveau de fiabilité obtenu en fin de développement. De ce fait, ce
point n’est jamais explicitement traité, ou est abordé de manière subjective, ou
encore est remplacé par des exigences sur le processus de réalisation. Dans
tous les cas, les techniques de substitution utilisées ne permettent pas d’avoir
une idée précise du risque que l’on prend en mettant un logiciel en opération,
ce qui est, par essence, le but de la quantification de la fiabilité.
Cet article décrit les fondements théoriques de la quantification de la fiabilité
du logiciel et en explique les modes d’utilisation. Il s’efforce de lever les princi-
pales réticences rencontrées vis-à-vis de la quantification de fiabilité du logiciel
en expliquant notamment le processus qui est à l’origine de l’apparition des
défaillances et la manière dont les mathématiciens ont proposé de le modé-
liser. Il explique également comment les donneurs d’ordre pourraient mettre
en œuvre des exigences de fiabilité du logiciel qui concourraient nettement à
obtenir une meilleure qualité opérationnelle des composantes informatiques
des systèmes complexes qu’ils acquièrent.
L’objectif de l’article est de montrer que la modélisation de fiabilité est une
technique statistique valide et applicable aux logiciels quelle que soit leur
nature : logiciels embarqués, logiciels temps réels, logiciels de système d’infor-
mation de tout domaine. L’article fait également un bilan des pratiques
industrielles actuelles et donne des pistes potentielles d’évolution de ces
pratiques dans l’avenir.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. – © Editions T.I. SE 2 520v2 – 1
tiwekacontentpdf_se2520 v2 Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84
QUANTIFICATION DE LA FIABILITÉ DES LOGICIELS ________________________________________________________________________________________
1. Problématique générale Nota : de fait, avant que ne soit institué le terme « sûreté de fonctionnement », terme
assez récent paru dans les années 1980, on utilisait l’acronyme « FMDS ».
de la fiabilité du logiciel Si l’on examine de plus près ces quatre caractéristiques, il est
facile de démontrer que les trois premières sont liées (FMD) alors
que la sécurité (S) est focalisée sur les défaillances du système
pouvant nuire aux biens ou aux personnes. En d’autres termes, on
1.1 Qu’est-ce que la fiabilité du logiciel ? peut considérer que les critères de sûreté de fonctionnement
auxquels sont sensibles les clients peuvent être ramenés à
La fiabilité d’un logiciel, ou plus généralement d’un système,

« disponibilité » et « sécurité ».
désigne, selon l’UTE (Union technique de l’électricité), son aptitude
à assurer sa mission dans des conditions d’environnement Concernant la contribution de la fiabilité à la disponibilité, il est
données et pendant une durée donnée. La fiabilité caractérise ainsi important de noter que celle-ci est d’autant moins élevée que le
la confiance que l’utilisateur peut placer dans le service rendu par système est maintenable. Or c’est très souvent le cas pour les
un système. logiciels qui sont en général assez rapidement remis en service
après une défaillance (on reboot le système) et qui n’ont pas
Dans cet article, la définition de la fiabilité du logiciel qui fait
besoin d’opération de maintenance lourde en cas de défaillance
référence est : « La probabilité d’un logiciel à accomplir l’ensemble
lorsque cette dernière n’est pas bloquante. Il résulte de cela que la
des fonctions spécifiées dans son document de référence, dans un
fiabilité du logiciel n’est pratiquement jamais remise en cause pour
environnement donné et pour un temps de fonctionnement
des raisons de disponibilité et donc qu’elle n’est pas contrainte par
donné. » C’est une définition de fiabiliste, qui peut être évaluée par
les exigences usuelles de FMDS.
une expression mathématique et qui est donc beaucoup plus
restrictive que la définition de la fiabilité du logiciel donnée, par Pourtant les défaillances logicielles perturbent de plus en plus
exemple, dans la norme ISO/IEC 25 010 comme étant « l’aptitude les fonctionnements des systèmes complexes modernes et sont
du logiciel à maintenir un niveau de performance requis lorsqu’il bel et bien perçues de manière désagréable par les opérateurs
est utilisé dans les conditions spécifiées ». desdits systèmes. Pour que les exigences de sûreté de fonctionne-
Cette définition soulève, dans le monde informatique, principalement induisent des contraintes de fiabilité des logiciels, il faudrait
ment deux réticences : compléter les exigences classiques de disponibilité par une
contrainte relative par exemple au nombre maximum de défaillan-
– la première réticence, mise en avant dans les principales ces dues au logiciel par an ou toute autre contrainte équivalente.
normes de sécurité fonctionnelle, et notamment la norme
ISO/CEI 61508, repose sur la considération que le logiciel produit Concernant la contribution du logiciel à la sécurité, du fait de
des défaillances « systématiques » dont la probabilité d’occurrence l’impossibilité de démontrer des taux de défaillance du logiciel très
ne peut pas être quantifiée. Pourtant le caractère stochastique du faibles (cf. les recommandations de mise en œuvre données à la
processus d’apparition des défaillances du logiciel ne peut pas être fin de cet article), les techniques présentées dans cet article ne
nié et il est même possible d’associer deux types d’aléas à ce sont pas applicables. De ce fait, les normes de sécurité fonction-
processus. Le premier aléa est celui qui fait qu’un défaut a une nelle des systèmes programmés considèrent que les défaillances
certaine probabilité d’être introduit dans le code avec bien sûr des du logiciel sont déterministes et s’appuient sur des processus
causes multiples : des spécifications floues, incompréhension robustes et des techniques qualitatives [SE 2 500] qui assurent aux
entre clients et fournisseurs, perturbations de l’environnement du concepteurs et au client une bonne confiance dans le fait que les
codeur, etc. Le second aléa est celui qui fait qu’un défaut, généré modes de défaillances redoutés n’apparaîtront vraisemblablement
par le premier aléa, a une certaine probabilité d’être activé lors de pas dans l’environnement de fonctionnement spécifié du système.
l’utilisation du logiciel et ainsi de produire une défaillance. En ce
sens, la fiabilité du logiciel peut tout à fait être comparée à la fiabi-
lité d’un composant électronique que l’on pondère par des facteurs 1.3 Quel mode de quantification adopter ?
de qualité (le premier aléa) et de stress ou d’environnement (le
second aléa) (cf. les normes de fiabilité prévisionnelle électronique La quantification de fiabilité d’un logiciel doit impérativement
telles que la MIL HDBK 217 ou FIDES) ; être replacée dans le contexte d’évaluation de la fiabilité du
– la seconde réticence est due à l’espoir longtemps entretenu de système qui l’utilise. Pour bien s’en convaincre, il suffit de
corriger tous les défauts du logiciel pour ramener son taux de remonter à l’origine du besoin exprimé par l’utilisateur : le logiciel
défaillance à 0. Cette réticence est également liée à l’amalgame n’est pas pour lui une pure vision de l’esprit mais il est matérialisé
souvent fait implicitement entre la fiabilité du logiciel et le par un système dans lequel le code binaire est exécuté avec un
comptage de ses défauts. De fait, dans de nombreux projets, pour objectif de service à rendre.
évaluer le niveau de fiabilité atteint par le logiciel, les ingénieurs
font souvent appel à des métriques qui s’appuient principalement Ce qui intéresse l’utilisateur, c’est la confiance qu’il va pouvoir
sur le comptage des défauts dans le code : nombre de défauts mis avoir dans la qualité du service rendu par le système indépendam-
en évidence en relecture, en test unitaire, etc. Ce dernier point ment de son architecture.
s’inscrit tout à fait dans la problématique du mode de quantifica- Au départ, le besoin est donc exprimé au niveau du système.
tion de la fiabilité du logiciel développée ultérieurement. Dans le cas de la fiabilité, il s’exprime par exemple en termes de
MTTF (Mean Time To Failure ), de taux de défaillance ou de proba-
bilité de réussite de mission. Comme le système est composé de
1.2 Fiabilité du logiciel et sûreté matériels et de logiciels, et quelquefois d’hommes aussi, chacun
pouvant être à l’origine d’une défaillance, la manière naturelle
de fonctionnement des systèmes d’évaluer la fiabilité du système consiste à évaluer la part prise par
programmés chacune de ses composantes dans la fiabilité globale.
La sûreté de fonctionnement d’un système est en général Il s’ensuit donc qu’il est indispensable de pouvoir exprimer
exprimée à l’aide des quatre principales caractéristiques suivantes : chacune de ces contributions dans un même référentiel permettant
de les combiner pour obtenir une valeur au niveau du système. Or
– la fiabilité (F) ; le référentiel assez communément admis depuis de nombreuses
– la maintenabilité (M) ; années pour les systèmes matériels est le taux de défaillance par
– la disponibilité (D) ; heure. C’est donc le mode de quantification de la fiabilité du
– la sécurité (S) du système. logiciel qui est le mieux adapté (ou des modes équivalents).

SE 2 520v2 – 2 est strictement interdite. – © Editions T.I.
_________________________________________________________________________________________ QUANTIFICATION DE LA FIABILITÉ DES LOGICIELS
1.4 Fiabilité prévisionnelle et fiabilité – hypothèse 1 : la correction des défauts est immédiate,
c’est-à-dire qu’une défaillance due à un défaut donné n’apparaît
expérimentale qu’une seule fois ;
– hypothèse 2 : cette correction est parfaite, c’est-à-dire qu’elle
Que ce soit pour du matériel ou du logiciel, selon les phases du
ne crée pas de nouveaux défauts dans le code.
cycle de vie où sont appliquées les techniques de fiabilité, elles
sont qualifiées de prévisionnelles ou d’expérimentales. La première hypothèse est rarement vérifiée dans la réalité : les
développeurs ont l’habitude en effet de faire en séquence, et non
Les techniques prévisionnelles se situent en amont dans les
en parallèle, le test et les corrections. De ce fait, une même
phases du cycle de vie et ont pour objectif principal de valider la

défaillance peut apparaître plusieurs fois dans une séquence de
conception du système par rapport aux objectifs de fiabilité visés.
test. Il est néanmoins facile de simuler cette hypothèse en filtrant
Dans le cas du logiciel, les techniques actuellement proposées
les défaillances avant d’appliquer les modèles.
pour évaluer la fiabilité prévisionnelle s’appuient en général sur la
maturité du processus de développement ou sur sa caractérisation La véracité de la seconde hypothèse est aussi incertaine : la
paramétrique [2] [3]. Elles sont souvent peu matures, difficilement preuve en est des efforts importants que consacrent les industriels
applicables et assez peu corrélées avec le système cible. Il y a dans aux tests de non-régression, sans être pour autant arrivés à une
ce domaine un vrai gisement de recherches à entreprendre. efficacité de 100 %. Il apparaît cependant dans la pratique que l’on
peut supposer cette hypothèse « presque vérifiée » sans trop de
Les techniques expérimentales, quant à elles, consistent à problèmes avec les résultats de modélisation.
évaluer le niveau de fiabilité atteint par le système à partir des
essais réalisés sur ce système dès qu’il peut fonctionner. Elles se Ces deux hypothèses, vérifiées ou simulées, produisent néces-
situent en aval dans les phases du cycle de vie et ont pour objectif sairement une croissance de fiabilité du logiciel.
principal de vérifier l’obtention du niveau de fiabilité requis en Entre les années 1970 et 1980, de très nombreux modèles de
analysant les faits techniques observés. quantification de la fiabilité du logiciel ont été proposés dans la lit-
Dans le cas du logiciel, il existe depuis une vingtaine d’années térature, chacun se voulant plus efficace que les précédents. Musa,
des méthodes et modèles qui commencent à être reconnus et qui Iannino et Okumoto [9] ont démontré que ces modèles étaient
permettent de mener à bien des études de fiabilité expérimentale. presque tous basés sur des processus binomiaux ou de Poisson.
Ils ont ainsi pu construire une classification des modèles en
Par extrapolation du comportement déjà observé du logiciel, les fonction de la nature des processus régissant l’apparition des
modèles de quantification de la fiabilité du logiciel apportent des défaillances et de la forme mathématique du taux de défaillance
éléments quantifiés de la qualité de service, présente et à venir, associé. Cette classification est reproduite dans le tableau 1.
sur lesquels il est par exemple très intéressant de s’appuyer pour
conduire le test [4].
2.2.2 Valeurs caractéristiques
On retrouve en fiabilité du logiciel les caractéristiques usuelles à
savoir : le MTTF (Mean Time To Failure ) et le taux de
2. Modèles de croissance défaillance [AG 4 670]. On trouve aussi les deux fonctions particu-
de fiabilité lières à l’étude des processus stochastiques que sont : le nombre
cumulé de défaillances observées, noté H(t ) dans cet article et
l’intensité de défaillance, notée h(t ) (figure 1).
2.1 Évolution des modèles Nota : comme le montre la figure 1, l’intensité de défaillance est la « vitesse »
d’apparition des défaillances. Elle n’a donc pas du tout la même définition que le taux de
défaillance et il faut bien prendre garde de ne pas confondre les deux notions, sauf si leur
Les premiers travaux sur la fiabilité des logiciels se sont équivalence est démontrée mathématiquement (ce qui est le cas pour les processus de
intéressés à l’évaluation du nombre de défauts présents dans le Poisson [9]).
code. Ainsi en 1972, Mills a proposé un modèle basé sur la
technique d’essaimage de défauts (introduction volontaire avant le 2.2.3 Principes de modélisation
test de défauts prédéfinis dans le code) [5]. En 1978, Nelson a éga-
lement proposé un modèle d’évaluation de la fiabilité des Une fois la forme mathématique du modèle choisie, la modélisa-
logiciels [6]. Mais ce modèle présentait l’inconvénient majeur de tion fait appel à :
ne pas tenir compte de l’amélioration de fiabilité liée à la correc- – une procédure d’inférence permettant de calibrer le modèle,
tion des défauts dans le logiciel. c’est-à-dire d’estimer ses paramètres en fonction des données
Les autres techniques utilisées pour évaluer la fiabilité des recueillies lors des essais ;
logiciels se sont alors largement inspiré des techniques employées – une procédure de prévision qui consiste à remplacer, dans
sur les composantes matérielles, tout en veillant à les adapter l’expression des caractéristiques de la fiabilité, les paramètres par
spécialement au cas particulier de l’informatique qui fait appel à leurs valeurs estimées ;
un processus de conception/correction [SE 2 500]. Cet aspect avait – un ou plusieurs critères de validation qui permettent de vérifier
déjà été traité par Duane [7], dont le modèle prenait en compte la l’adéquation des estimations obtenues aux valeurs observées et de
« croissance de fiabilité » et qui a inspiré la plupart des modèles de comparer plusieurs modèles pour choisir le « meilleur » d’entre eux.
quantification de la fiabilité du logiciel dont quelques-uns sont En d’autres termes, la modélisation consiste à utiliser des outils
décrits ci-après. mathématiques permettant de calibrer un modèle d’une forme
donnée sur le processus mis en évidence par les essais et à utiliser
la meilleure fonction ainsi déterminée.
2.2 Principaux modèles Les techniques statistiques de calcul des paramètres sont
connues sous le nom de méthodes du « maximum de vraisem-
2.2.1 Hypothèses blance », des « moindres carrés » ou des « moments ». Ces techni-
ques déterminent les paramètres qui s’ajustent le mieux aux
De très nombreux modèles de quantification de la fiabilité du données observées selon différentes distances statistiques. La
logiciel ont été proposés dans la littérature [8]. Ils s’appuient, pour méthode du maximum de vraisemblance est celle qui est la plus
la plupart, sur deux hypothèses de base ayant un fort impact fréquemment utilisée pour calculer les paramètres des modèles de
mathématique : quantification de la fiabilité du logiciel.

Tableau 1 – Classification des modèles de quantification de la fiabilité du logiciel

Forme du taux de panne Processus binominal Processus de Poisson Autre
Modèles à nombre de défaillances fini
Musa (1975) Moranda Goel-Okumoto (1978)

Jelinski-Moranda (1972)
Exponentielle (1975) Schneidewind Musa (1979)

Shooman (1972)
(1975) Goel-Okumoto (1979) Keiller-Littlewood (1983)
Schick-Wolverton (1973)
Weibull
Wagoner (1973)
Pareto Littlewood (1981)
Gamma Yamada-Ohba-Osaki (1983)
Autre Schick-Wolverton (1973)
Modèles à nombre de défaillances infini
Géométrique Musa-Okumoto (1984) Moranda (1975)
Inverse linéaire ou polynomiale Littlewood-Verrall (1973)
Puissance Crow (1974)
Autre Kanoun-Laprie (1985)
* en caractères gras, noms des modèles détaillés dans la suite.
corrigé, et ce jusqu’à ce qu’il n’y ait plus de défaut dans le code.

Dans ce modèle :
Nombre de défaillances cumulé
Hi (t ) = λi exp (– λi t )
hi = (N – (i – 1)) Φ
70
h(t)
60 2.2.4.2 Modèle de Musa-Okumoto
50 h(0)
(ou « modèle logarithmique »)
40 Ce modèle, proposé par ses auteurs en 1984, suppose que
µ(t) = espérance mathématique de H(t) l’intensité décroît exponentiellement avec le nombre de défail-
30
lances. Cela signifie que la correction des premiers défauts mis en
20 évidence réduit plus l’intensité de défaillance que la correction des
10 défauts suivants. Dans ce modèle, le nombre de défaillances
possibles est infini et la fiabilité est croissante (figure 2) :
0
0 200 400 600 800 1 000
H (t ) = λ 0 log (θt + 1) où λ 0 et θ > 0
Temps de fonctionnement (h)
λ0
H(t) h(t ) =
λ 0 θt + 1
µ(t)
2.2.4.3 Modèle de Littlewood-Verral

Figure 1 – Courbe du nombre cumulé de défaillances
Contrairement aux modèles précédents qui sont poissoniens, il
s’agit ici d’un modèle bayésien, proposé par son auteur en 1973.
2.2.4 Équations des modèles Selon la vision bayésienne, le logiciel est d’autant plus fiable qu’on
le voit fonctionner longtemps sans défaillance. De plus, ce modèle
tient compte de la nature aléatoire du processus de correction des
Nous donnons ci-après les caractéristiques de trois modèles aux fautes : on peut en effet considérer qu’il est impossible de
hypothèses distinctes (un modèle pour chaque colonne du déterminer quelle est l’incidence réelle de la correction d’une faute
tableau 1). sur le taux de défaillance global du logiciel. Dans ce modèle :
2.2.4.1 Modèle de Jelinski-Moranda – β0 + β20 + 2t (α − 1)β1

H (t ) =
β1
Ce modèle, proposé par son auteur en 1972, est l’un des
premiers modèles à taux de panne proposé pour le logiciel. Il fait α −1
h(t ) =
« naturellement » l’hypothèse que le taux de défaillance décroît β20 + 2t (α − 1)β1
d’une valeur constante Φ à chaque fois qu’un défaut est détecté et

3. Mise en œuvre
des modèles
Nombre de défaillances cumulées
60
3.1 Processus de collecte et d’étude

40
20 3.1.1 Présentation générale du processus
0 La démarche de quantification de la fiabilité des logiciels impose

0 25 50 75 100 de mettre en œuvre deux types d’actions différentes : une action
continue de collecte de données et des actions ponctuelles d’étude
Date des défaillances (h) de fiabilité.
a
La collecte des données est complétée périodiquement par une
Nombre de défaillances cumulées
étape permettant de débroussailler les données, appelée « analyse

4
a priori ». Après quoi les études de fiabilité du logiciel se déroulent
en trois étapes successives : étude des tendances, modélisation et
3 prévision. Elles se terminent par la rédaction d’un rapport
présentant les travaux réalisés et les résultats obtenus. La figure 3
2 résume ce processus dont chaque étape est décrite en détail dans
les paragraphes qui suivent.
1
Nota : J. D. Musa propose un processus tout à fait similaire dans ses travaux sur le
SRE (Software Reliability Engineering ) [10].
0
0 25 50 75 100
3.1.2 Recueillir les données
b Date des défaillances (h)
Dès que le logiciel est dans une phase relativement stable, en
λ0 = 2,5 ; θ = 0,05 λ0 = 4 ; θ = 0,05 λ0 = 2 ; θ = 0,05 général en phase de test d’intégration ou de validation, il faut
relever le signal d’apparition de ses défaillances.
Nota : rappelons que les modèles employés sont des modèles de fiabilité expérimen-
Figure 2 – Courbes du nombre cumulé de défaillances tale (par opposition aux modèles de fiabilité prévisionnelle) puisqu’il est nécessaire de
et de l’intensité de défaillance du modèle logarithmique disposer d’un logiciel exécutable pour en évaluer la fiabilité.
Organisation Objectifs
de SdF
Cahier de bord
Jeux de test de test Corrections
Recueillir Analyser Collecte
les données a priori des données
Logiciel Rapports
à tester d'anomalies
Données exploitables
Courbes de tendance
Étudier
les tendances
Infos sur la croissance
Rapport
Courbes de modélisation Formaliser
Études les résultats
Modéliser
de fiabilité Décision
Objectifs
Modèle le mieux de SdF
adapté
Prévoir
Résultats
quantitatifs
SdF = sûreté de fonctionnement
Figure 3 – Processus de collecte et d’étude de fiabilité des logiciels

La collecte de ce signal peut être réalisée de deux manières : 3.1.5 Modéliser

– soit en relevant le temps de sollicitation cumulé lors de
l’apparition de chaque défaillance, on disposera alors de
3.1.5.1 Choix du modèle en trois étapes
« données unitaires » ;
– soit en relevant le nombre de défaillances qui se sont Rappelons que la modélisation consiste à utiliser des outils
produites lors de sollicitations pour une durée donnée, on mathématiques permettant de calibrer un modèle d’une forme
disposera alors de « données groupées par intervalle de temps ». donnée sur le processus révélé par l’échantillon.
Dans la pratique, les données émanent en général de deux
sources différentes : Nota : l’emploi des modèles dits « de croissance de fiabilité » impose que l’hypothèse
de croissance ait été au préalable confirmée par l’étude des tendances.
– les données relatives à la sollicitation du logiciel lors du test
peuvent être trouvées dans les cahiers de bord ou les log de test ; Comme il n’existe pas de modèle universel, il faut choisir le
– les données relatives aux anomalies apparues lors du test sont modèle le plus adapté aux données collectées. L’expérience a
enregistrées dans des rapports d’anomalies eux-mêmes gérés par démontré qu’il suffisait pour cela d’utiliser quelques modèles
des outils de gestion dédiés. parmi les plus représentatifs. On peut ensuite procéder selon trois
Il est alors possible de les fusionner pour obtenir des « données étapes successives qui éliminent petit à petit les modèles n’offrant
groupées par intervalles de temps ». pas toutes les qualités requises.
Nota : alors que le relevé des anomalies est presque toujours réalisé systématique-
ment par les équipes de validation, il n’est pas encore rentré dans les mœurs de garder 3.1.5.2 Première étape
une trace détaillée de la manière dont le logiciel a été sollicité pendant les tests. Pourtant
cette information est fondamentale en fiabilité.
Cette étape consiste à comparer, en les superposant, les courbes
réelles et les courbes du modèle (courbes du nombre cumulé de
3.1.3 Analyser a priori défaillances en fonction du temps et, si nécessaire, courbes des
MTTF ou taux de défaillance par sous-intervalles). Les modèles
L’analyse a priori permet de détecter et d’éliminer les données présentant des courbes trop éloignées des courbes réelles ou
douteuses. ayant une forme trop différente des formes des courbes réelles
La saisie informatique des données est conseillée. Elle permet peuvent être éliminés.
d’en vérifier plus facilement la complétude et la cohérence. Elle
permet de détecter les erreurs de collecte qui entraînent l’appari- Exemple : dans la figure 4, la première étape conduit ainsi à
tion de valeurs a priori douteuses : il est alors nécessaire de supprimer les modèles de Crow, Kanoun-Laprie (hyper-exponentiel) et
retrouver les intervenants ayant participé aux saisies liées à ces Littlewood-Verrall qui n’ont pas la même forme que la courbe des
erreurs afin d’expliciter ces valeurs et, éventuellement, de les données réelles (statistique).
corriger. De plus, elle permet de vérifier l’homogénéité des
données collectées : même unité de temps (heure, jour, mois),
même ensemble de sigles, etc. 3.1.5.3 Deuxième étape
Nota : il est recommandé de commencer l’analyse des données dès que la quantité Pour choisir des modèles qui prévoient bien le comportement
de données est suffisante pour l’interprétation des premiers résultats, afin de vérifier très futur, on recalcule les paramètres des modèles à partir des
tôt la cohérence de l’information.
données de sous-ensembles croissants de l’échantillon total
Dans le cas où les données douteuses sont ponctuelles et (modélisations successives avec des données « cachées ») et l’on
noyées dans la masse, il est conseillé de ne pas y toucher car les compare avec la réalité les prévisions successives. Les modèles
modèles de quantification de la fiabilité ne sont pas sensibles à qui sont trop éloignés de la réalité ou qui convergent trop tardive-
quelques fluctuations intempestives clairsemées. ment peuvent être éliminés.
3.1.4 Étudier les tendances

Nombre de défaillances
Après s’être assuré de la qualité et de la représentativité des Nombre de défaillances modélisées

données, l’analyste peut passer à l’étude des tendances dont
l’objectif est de mettre en évidence les zones de croissance et de 80
décroissance de fiabilité.
70
Pour cela, il examine la courbe d’apparition des défaillances en
fonction de la sollicitation. Si la courbe du nombre cumulé de 60
défaillances présente une pente en diminution, il y a vraisembla-
blement croissance de fiabilité. Il examine aussi les courbes de 50
MTTF par sous-intervalle. Le MTTF est une caractéristique de fiabi- 40
lité exprimant la moyenne des temps de fonctionnement jusqu’à
défaillance. Si cette moyenne augmente, il y a vraisemblablement 30
croissance de fiabilité.
20
Enfin, dans le cas de « données unitaires » ou « groupées par
intervalle de temps constant », le statisticien dispose d’un outil 10
mathématique permettant de tester la tendance (croissance ou
0
décroissance de fiabilité) : il s’agit du test de Laplace [8].
0 200 400 600 800 1 000
Nota : le test de Laplace compare la moyenne des milieux des intervalles entre Temps de fonctionnement (h)
défaillances avec le milieu de l’intervalle d’observation. Il fait l’hypothèse qu’il y a
croissance de fiabilité lorsque cette moyenne est significativement inférieure au milieu. Statistique Crow
Musa - Okumoto Hyper - exponentiel
Cette étape facilite les étapes suivantes puisqu’elle permet
Goel - Okumoto Littlewood - Verrall
d’améliorer la qualité des estimations en indiquant les zones de
croissance effective de la fiabilité sur lesquelles peuvent
s’appliquer les modèles dits « de croissance ». Figure 4 – Exemple de superposition des courbes

Nombre de défaillances modélisées

Nombre de défaillances
(Musa - Okumoto)
Erreur absolue sur le nombre de défaillances modélisées
100 à la dernière observation 70
60
80 50
75
40
60 30
20
40 10
0
20 0 200 400 600 800 1 000
0 Statistique
0 90 161 267 475 735 1 100 Modélisation complète
Temps de fonctionnement (h) Modélisations successives
Musa - Okumoto Goel - Okumoto Figure 6 – Exemple de convergence des modélisations successives
Figure 5 – Exemple de comparaison des prévisions
Nombre de défaillances modélisées

(Goel - Okumoto)
Exemple : dans la figure 5, le modèle de Musa-Okumoto prévoit,
avec les données connues après 161 heures de test, qu’il y aura 91 70
défaillances après 1 100 heures de test (en réalité, on en a relevé 75), 60
X <-> Y
alors que le modèle de Goel-Okumoto n’en prévoit que 50. Ensuite, 50
après 267 heures de test, le modèle de Musa-Okumoto prévoit 80
défaillances pour 1 100 heures de test alors que le modèle de 40 X= 1600 1600
Valeur
Goel-Okumoto n’en prévoit toujours que 53, et ainsi de suite. La 30 effectives
deuxième étape conduit ainsi à choisir le modèle de Musa-Okumoto. 20 Y= 82,77
Fermer
10
3.1.5.4 Troisième étape
0
Cette dernière étape s’assure que les modèles sont bien repré- 0 200 400 600 800 1 000 1 200 1 400 1 600
sentatifs du processus modélisé, et notamment que l’on n’est pas
en présence d’une simple suite d’ajustements statistiques. Pour
cela, on vérifie que les paramètres estimés lors des modélisations Statistique
successives sont cohérents et convergent. Les modèles qui Modélisation complète
semblent trop incohérents peuvent être éliminés.
Nota : cette dernière étape est souvent une confirmation de choix. En effet, il est rare Figure 7 – Exemple de prévision du nombre de défaillances à venir
d’éliminer un modèle à ce stade car les deux premières étapes sélectionnent en général
des modèles qui vérifient cette dernière condition.
mieux appréhender les risques de dérapage. Les calculs de risques
se font, à l’aide du meilleur modèle choisi au préalable par l’utilisa-
Exemple : dans la figure 6, les modélisations successives de
teur, soit en conservant l’hypothèse d’évolution de fiabilité, ce qui
Musa-Okumoto convergent bien vers la modélisation finale
correspond à la simulation de la poursuite de mise au point du
(complète). La troisième étape confirme ainsi le choix du modèle de
logiciel, soit en supposant la fiabilité constante, ce qui correspond
Musa-Okumoto.
à la simulation de mise en exploitation du logiciel.
À la fin de cette étape, le modèle choisi va permettre de
quantifier la fiabilité du logiciel et faire des prévisions. Exemple : la figure 8 montre la courbe de probabilité de dépasser
le nombre de défaillances cumulé déjà obtenu de une, deux ou x
défaillances pour un temps de fonctionnement prévisionnel donné,
3.1.6 Prévoir avec une hypothèse de fiabilité constante.
Les modèles de quantification de la fiabilité des logiciels
permettent de prévoir la fiabilité en termes de nombre de Outre l’évaluation des mesures de fiabilité, les modèles offrent
défaillances à venir, d’intensité de défaillance ou de MTTF. en général la possibilité de calculer le temps nécessaire pour
atteindre un objectif. On peut, par exemple, estimer le temps de
Exemple : la figure 7 montre un exemple de prévision du nombre test encore nécessaire pour obtenir un taux de défaillance prédé-
de défaillances cumulées Y pour un temps de fonctionnement futur terminé. Ils permettent également d’estimer la probabilité de
X, réalisée à l’aide de l’atelier de calculs de fiabilité M-élopée [11]. passer avec succès des essais de réception dans la mesure où l’on
connaît la nature de la sollicitation que le logiciel subira lors de ces
Nota : © M-élopée est une marque déposée de France Télécom.
essais et qu’elle peut être déduite de la sollicitation pour laquelle
on dispose déjà d’un retour d’expérience. Ils permettent de la
En complément, les modèles permettent également de calculer même manière d’estimer le nombre moyen de défaillances qu’un
des intervalles de confiance sur les données fournies, afin de logiciel est susceptible de produire lors de sa mise en opération.

– les ingénieurs fiabilistes définissent les procédures de collecte,

supervisent la collecte, enregistrent les données et les vérifient,
Risque pour un taux de défaillance constant
(Musa-Okumoto)
font les calculs, valident et testent les objectifs de fiabilité. Ils font
1
donc les études et les interprètent pour les chefs de projet ;
– les ingénieurs de test ou de maintenance, avec les utilisateurs
0,8 si nécessaire, tiennent le journal de bord, repèrent les défaillances
et leurs dates, corrigent ces défaillances, remplissent les fiches de
défaillance et de correction associées. Ils font donc les essais, la
0,6
collecte des données sur le terrain et ils font remonter les anoma-
lies aux deux acteurs précédents.
0,4
0,2
3.2 Données d’entrée de la modélisation
0 3.2.1 Données minimales nécessaires

75 80 85 90 95 100 105 110
Quels que soient les objectifs et la nature du projet, il existe un
Nombre de défaillances à la date : 2000 sous-ensemble minimal de données dont il faut absolument
pouvoir disposer pour réaliser des études de fiabilité. Ainsi, les
Figure 8 – Calcul du risque de dépassement des prévisions informations indispensables à recueillir sont :
moyennes – en ce qui concerne la sollicitation : la date (ou période de test),
la sollicitation du logiciel (durée effective du test, ou nombre de
Nota : dans le cadre d’un engagement contractuel, il est important que toutes les
tests élémentaires, ou nombre de transactions, etc.) ;
hypothèses attachées aux objectifs soient bien réunies ou simulées pour procéder à une – en ce qui concerne la défaillance : un identifiant unique, la date
prévision à l’aide d’un modèle de fiabilité. Ces hypothèses concernent en général : d’apparition (ou période de test), le type de défaillance.
– le profil opérationnel considéré pour la fiabilité objectif, qui permettra de définir la
nature et la quantification de la sollicitation à prendre comme référence pour la prévision ; Afin de ne prendre en compte que les données relatives au
– la nature des défaillances à prendre en compte pour la prévision ; logiciel, l’origine de chaque défaillance détectée doit être précisée
– la définition précise de l’objectif à mesurer (MTTF instantanée, taux de défaillance). (cette défaillance est-elle bien due au logiciel ?). Il s’agit aussi de
Pour que les prévisions soient correctes, il est souhaitable pouvoir reconnaître les défaillances ayant la même origine ou
qu’elles portent sur un temps de fonctionnement du même ordre celles dues à des corrections imparfaites. Il est donc nécessaire
de grandeur que le temps de fonctionnement déjà connu sur d’avoir accès aux informations relatives aux corrections effectuées
lequel elles s’appuient. Autrement dit, le temps connu (de test) et et de pouvoir relier entre elles les données relatives aux défaillan-
le temps estimé (opérationnel) doivent rester dans le même ordre ces et celles relatives aux corrections.
de grandeur.
3.2.2 Mesure de la sollicitation
Exemple : dans les données des figures 4, 5 et 6, le modèle de
Musa-Okumoto fait 21 % d’erreur pour un rapport 7 entre le temps Cette variable doit être choisie en fonction de la nature du
prévu et le temps connu, 7 % d’erreur pour un rapport 4 et 2 % logiciel et de ses objectifs de fiabilité. Ce choix est en général un
d’erreur pour un rapport 2. travail d’expert.
Le temps calendaire correspondant à la durée des essais est une
variable utilisable, mais il est important d’en déterminer le biais
3.1.7 Formalisation des résultats
pour représenter effectivement la sollicitation du logiciel.
Une étude de fiabilité se termine classiquement par la rédaction Nota : le temps calendaire est une mesure de sollicitation qui n’est pas recom-
d’un rapport présentant les travaux réalisés et les résultats mandée. C’est la variable à utiliser quand on ne dispose vraiment d’aucune autre
obtenus. Selon l’étape dans laquelle il se situe, ce rapport peut information !
avoir la forme d’une simple note technique présentant les
données, les courbes et modèles de quantification de la fiabilité, Le temps CPU d’exécution est une variable représentative de la
les valeurs prévues ou la forme d’un rapport plus complet rappe- durée horaire des exécutions du logiciel et constitue une meilleure
lant les concepts de fiabilité expérimentale et la manière dont ils approximation que le temps calendaire. Il peut s’avérer cependant
ont été appliqués sur le projet, ainsi que les résultats obtenus aux difficile ou coûteux à collecter.
différentes étapes d’étude. Cette dernière partie peut être tout La quantité d’informations traitées est une variable plus spécifi-
simplement une concaténation des notes techniques intermé- quement adaptée aux logiciels pour lesquels le nombre d’éléments
diaires rédigées sur le projet. manipulés est plus significatif que les instructions exécutées pour
Dans tous les cas de figure, et notamment lors d’une prise de représenter finement la sollicitation du logiciel.
décision s’appuyant sur les résultats présentés, le lecteur devra Une fois que la variable de sollicitation adéquate a été choisie, il
être familiarisé avec les principes de base de la fiabilité expérimen- est en général assez facile de la relier, souvent par une simple
tale, ses tenants et aboutissants, et surtout les pièges et erreurs à règle de 3, au temps de fonctionnement du système de manière à
éviter. pouvoir utiliser les résultats de fiabilité obtenus sur le logiciel dans
une consolidation au niveau du système.
3.1.8 Acteurs du processus Nota : rappelons que, dans cet article, nous faisons l’amalgame entre « temps de
fonctionnement » et « sollicitation » qui recouvrent les mêmes concepts.
En général, trois types d’acteurs interviennent dans la démarche
de collecte et d’étude :
3.2.3 Données unitaires ou données groupées
– les chefs de projet interviennent à haut niveau. Ils rappellent
les délais, allouent les ressources, valident les objectifs de fiabilité Une fois la variable de mesure de la sollicitation choisie, il
et prennent les décisions ad hoc à la lumière des résultats des étu- importe de déterminer la précision de la datation de l’apparition
des de fiabilité ; des défaillances dans cette sollicitation. Cette précision

déterminera la nature des données soumises à l’étude : données À l’aide de ces valeurs, le chef de projet calcule qu’il lui faudra
« unitaires » ou données « groupées ». 1 mois de délai pour passer le complément de test et 15 jours sup-
Chacun de ces types de données a ses avantages et ses inconvé- plémentaires (10 jours ouvrés) pour corriger les 9 défauts prévus
nients. en faisant l’hypothèse d’une charge de correction d’un jour par
défaut en moyenne.
Les données « unitaires » sont plus coûteuses à recueillir. En
revanche, elles permettent l’utilisation du test de Laplace pour Il a prévu assez large pour le temps de passage du complément
l’étude des tendances. Statistiquement, elles produisent un de test qui n’est pas le plus grand consommateur de délai. En
revanche, chaque défaut étant en moyenne assez long à corriger,
échantillon de taille plus grande que celui obtenu avec des

données « groupées». et 9 étant une valeur moyenne, que se passerait-il s’il y avait plus
de 9 défauts qui apparaissaient pendant ce temps ?
Les données « groupées » sont les plus faciles à recueillir et ce
sont celles qui correspondent le plus aux habitudes industrielles Là encore, l’outil M-élopée renseigne le chef de projet en lui
courantes. Si le test de Laplace ne peut pas être utilisé dans ce cas, donnant une valeur qui ne sera pas dépassée avec une probabilité
il peut être remplacé par le simple examen de la courbe des MTTF maximum fixée. Ainsi, pour un risque inférieur à 10 %, l’outil lui
par sous-intervalles dont les fluctuations apportent une informa- propose une valeur maximum de 13 défauts à corriger. Le chef de
tion similaire. projet s’octroie donc une semaine de délai supplémentaire et
annonce avec confiance à son client qu’il sera livré en temps et en
Par ailleurs, certains modèles n’acceptent que des données de heure, et qu’il pourra lui démontrer que la fiabilité objectif est
type « unitaire » ou de type « groupé » en entrée. atteinte.
Il continue à manager le test par la fiabilité, s’arrêtant dès que le
modèle lui indique que la fiabilité objectif est atteinte. Il arrête
3.3 Exemple type d’étude de fiabilité ainsi le test au bout de 1 030 heures en ayant corrigé 13 défauts
Supposons qu’un chef de projet soit en phase de test d’un logi- supplémentaires. Il lui reste une semaine pour peaufiner sa
ciel dont l’objectif de fiabilité de service est fixé à 2 × 10–2 livraison. Il tient ainsi parfaitement ses délais et son objectif de
défaillance/heure. fiabilité.
Au bout de 3 mois de test selon le profil opérationnel, il a déjà La tenue de l’objectif de fiabilité permet aussi au client de faire
détecté 61 défauts et cumulé 620 heures de sollicitation. Il souhaite ses propres prévisions. Connaissant la sollicitation totale prévue
savoir s’il tiendra son délai total de 5 mois de test en ayant atteint pour ce logiciel pendant sa première année d’exploitation, le client
la fiabilité objectif. peut en déduire le nombre moyen de défaillances prévues,
éventuellement avec une marge de risque comme l’a fait le chef de
Le modèle de Musa-Okumoto s’avère être le modèle qui projet en test. Il peut alors utiliser cette valeur pour dimensionner
s’adapte le mieux à ses données. son besoin en maintenance pour ce logiciel.
L’atelier de calculs de fiabilité M-élopée [11] lui indique qu’il doit
cumuler au moins 958 heures de sollicitation pour atteindre son
objectif (figure 9). 3.4 Allocations de fiabilité et
Étant donné qu’il a déjà cumulé 620 heures de test, il en déduit formalisation d’exigences de fiabilité
qu’il lui faut encore en réaliser 338 heures. L’outil M-élopée prévoit
également qu’en moyenne 70 défaillances (valeur entière par Comme dit précédemment (§ 1.2), la fiabilité du logiciel
excès) seront cumulées à l’issue de ces 958 heures de test. Étant progressera lorsque les donneurs d’ordre imposeront sur leurs
donné qu’il a déjà mis en évidence et corrigé 61 défaillances, il en systèmes programmés des exigences ayant véritablement un
déduit qu’il lui faudra encore corriger en moyenne neuf défail- impact sur la fiabilité du logiciel. Cela fait, dans le cas de systèmes
lances jusqu’à la fin du test. complexes faisant appel à de nombreux logiciels diversement
distribués dans leur architecture, il faut savoir ramener l’exigence
de niveau système à une exigence sur chacun des constituants
logiciels dudit système. Nous expliquons dans les paragraphes qui
suivent comment allouer les exigences de fiabilité à chaque
Intensité de défaillance
logiciel élémentaire et comment formaliser cela sous forme d’une

0,6 exigence vérifiable.
X <-> Y
0,5
X= 957,16
3.4.1 Méthode d’allocation
Valeur
effectives
Pour pouvoir faire des allocations de fiabilité des logiciels, il est
0,4 Y= 0,02 2.E-02
nécessaire de disposer d’informations précises, d’une part, sur
Fermer
l’architecture « logicielle » du système et, d’autre part, sur la
0,3 contribution de chacun des composants de ladite architecture au
fonctionnement global du système.
0,2 L’architecture « logicielle » du système doit être formalisée par un
découpage en sous-ensembles de logiciels pour chacun desquels :
– il est possible de connaître sa sollicitation (différentes phases
0,1
de fonctionnement et différents temps de fonctionnement dans ces
phases) ;
0 – il est possible de connaître son nombre d’occurrences dans le
0 100 200 300 400 500 600 système ;
Temps de fonctionnement (h) – il y a une certaine « homogénéité » du point de vue de la fiabi-
lité, par exemple il s’agit d’un « composant » logiciel développé
Statistique par une même entreprise (c’est-à-dire dans un même contexte de
Modélisation complète développement).
Pour pouvoir faire des allocations de fiabilité des logiciels, il est
Figure 9 – Calcul du temps nécessaire pour atteindre l’objectif ensuite nécessaire de disposer d’informations sur la sollicitation

des composants ainsi déterminés. Pour cela, il faut déterminer La procédure d’acceptation de fiabilité à mettre en œuvre est
successivement les différentes phases de fonctionnement du similaire à celle proposée par la norme CEI 62628. Elle est schéma-
système, puis les contributions de chaque composant logiciel à ces tisée à la figure 10.
phases.
La formule d’allocation d’un taux de défaillance à un composant Exemple : les méthodes d’allocation de fiabilité du logiciel préco-
est alors de la forme suivante : nisées dans ce paragraphe ont été par exemple mises en œuvre avec
succès par le CEA dans le cadre du développement du contrôle
commande du laser MégaJoules [12].
λ système C composant T
λ composant = Le CEA a ainsi pu élaborer des exigences de fiabilité en sortie de
∑Ci Ti qualification usine qui ont été rarement inférieures à 10–2 défaillances
par heure pour chacun des 14 contrôle-commandes principaux
où Ci facteur de complexité du composant i, identifiés. Le CEA a accompagné ses ensembliers dans la mise en
Ti temps total de fonctionnement du composant i, œuvre de son cahier des charges. Il a explicité notamment son besoin
aux ensembliers et les a aidés à soumettre des cahiers de recette de
T temps de fonctionnement du système. fiabilité acceptables.
Le temps de fonctionnement d’un composant est calculé comme Ainsi, les industriels ont eu l’obligation de réaliser des « tests de
suit : fiabilité » qui permettaient de démontrer que leur exigence de fiabilité
était tenue.
Nombre d’occurences du composant × Σ (durée de la phase
Dans la plupart des cas, une heuristique de réduction du temps de
× contribution du composant à la phase) test basée sur la notion de « cas de tests équivalents » a permis de
ne pas dépasser l’ordre de grandeur d’une cinquantaine d’heures de
Le facteur de complexité du composant est une valeur choisie test pour valider l’objectif.
empiriquement et qui, si possible, rend la fiabilité du composant
raisonnable (par exemple fiabilité mesurée par retour d’expérience
sur des composants équivalents).
3.5 Recommandations
pour la mise en œuvre des modèles
3.4.2 Formalisation de l’exigence finale
Les cahiers des charges doivent renseigner, pour chaque 3.5.1 Impossibilité de démonstration
sous-ensemble, l’exigence de fiabilité quantifiée issue des alloca- de certains taux de défaillance
tions système ainsi que la démarche à mettre en œuvre pour la
démontrer et les documents attendus en réception de fiabilité. Même abordés avec toute la rigueur voulue, les modèles de
quantification de la fiabilité héritent des limitations propres à
Plus précisément, les cahiers des charges doivent contenir au l’utilisation du retour d’expérience pour valider l’obtention d’un
minimum les informations suivantes : objectif de fiabilité, à savoir : les heures de fonctionnement à
– le rappel de l’exigence de fiabilité allouée au logiciel, sous forme cumuler dans ce retour d’expérience sont inversement proportion-
d’un taux de défaillance par heure de fonctionnement par exemple ; nelles à la valeur du taux de défaillance à estimer.
– la méthode de mesure des critères de succès des tests de fiabi- Cela signifie que, pour évaluer un taux de défaillance de 10–5 par
lité qui permettront de vérifier que l’objectif est atteint ; heure, il faut cumuler un temps d’expérience sans défaillance d’au
– la définition du profil opérationnel à reproduire lors du test de moins 100 000 heures et même 400 000 heures si l’on veut avoir
fiabilité. Il est nécessaire que le test de fiabilité soit réalisé dans un une bonne confiance dans l’évaluation. Or, 400 000 heures repré-
contexte le plus représentatif possible de l’utilisation future du sentent 45 ans à plein temps !
logiciel. Cette notion est importante dans le cas d’un logiciel puis-
Par ailleurs, les techniques d’accélération de test utilisées pour le
que sa fiabilité de service dépend fondamentalement de la
matériel ne sont pas applicables au logiciel : d’une part, on sait rare-
manière dont l’utilisateur le fait fonctionner.
ment accélérer le temps de fonctionnement, notamment quand il
Le profil opérationnel est une caractérisation quantitative de la s’agit de logiciels réactifs nécessitant l’intervention humaine
manière dont le système sera utilisé sur le terrain. Il est en général continuelle pour fonctionner et, d’autre part, 100 logiciels en paral-
obtenu par retour d’expérience et collecte de données sur des lèle sous la même sollicitation réagissent en général de la même
systèmes similaires. Il est représenté par l’ensemble des scénarios manière. En d’autres termes, pour le logiciel : 100 × 1 000 heures de
d’utilisation du système avec leurs probabilités d’occurrence. fonctionnement = 1 000 heures de fonctionnement.
Définition
Développement Calcul Objectif
du profil Test
des cas de test de la fiabilité atteint ?
opérationnel
NON OUI
Reprise du test
Acceptation
du logiciel
Figure 10 – Procédure d’acceptation de fiabilité

Il découle de ce qui précède que, dans le domaine de la fiabilité

du logiciel, il est illusoire d’imposer sérieusement une exigence 4. Pratiques industrielles
telle que 10–6 défaillance/heure. Dans le cas où une telle exigence actuelles
s’avèrerait fondée, il paraît plus raisonnable de considérer que
10–6 ≈ 0, c’est-à-dire que la probabilité d’occurrence d’un événe-
ment redouté doit être pratiquement ramenée à zéro et procéder
par une approche qualitative [SE 2 500] qui donne aux concepteurs 4.1 Bilan mitigé
et au client une bonne confiance dans le fait que les défaillances
redoutées ne se produiront vraisemblablement pas dans l’environ- Force est de reconnaître que, depuis la publication du modèle de
nement de fonctionnement spécifié du système. Jelinski-Moranda en 1978 [13], les modèles de quantification de la
fiabilité du logiciel n’ont pas autant fait d’émules chez les indus-
triels qu’ils l’auraient dû. Certes, ces techniques ont été adoptées
3.5.2 Prise en compte d’un contexte complexe par un certain nombre d’entreprises prestigieuses telles que AT&T,
Lucent, IBM, Raytheon ou la NASA [14] mais c’est un bien faible
nombre lorsqu’on le compare au nombre d’entreprises produisant
3.5.2.1 Présence de plusieurs logiciels interfacés des logiciels dans le monde. Ces techniques ne font pas non plus
l’objet de normes suffisamment reconnues et diffusées, ce qui est
Tous les modèles de quantification de la fiabilité sont para- en général révélateur de leur adoption par la communauté. Il sem-
métrés (§ 2.2). Dans la plupart des cas, ces paramètres sont au blerait que les informaticiens perçoivent surtout le coût de la mise
nombre de deux ou, exceptionnellement, trois. Cela signifie que en œuvre de techniques de fiabilité sans bien en distinguer le
l’on ne dispose que de deux constantes (trois dans le meilleur des retour sur investissement. Souvent, la fiabilité est considérée
cas) pour caractériser les deux variables aléatoires concourant à la comme une caractéristique secondaire par rapport à l’apport de
fiabilité du logiciel et liées respectivement à la qualité intrinsèque fonctionnalités innovantes et le « time to market ». Et quand c’est
du code et à son environnement d’utilisation. Les modèles ne l’inverse, c’est-à-dire que la fiabilité du logiciel est primordiale, ce
peuvent donc pas supporter trop de diversité. qui est le cas notamment pour des systèmes programmés
réalisant des opérations de sécurité ou liés à la sécurité, les
D’un point de vue opératoire, il est donc indispensable de s’assu- techniques de quantification de fiabilité sont inopérantes et
rer du respect de ces règles ou, pour s’y ramener, de structurer les rejetées par les normes. On espère cependant que les efforts faits
données à modéliser en plusieurs sous-ensembles les respectant. actuellement par les industriels en termes d’amélioration de
Une fois les modélisations partielles effectuées, il est alors possible processus, qui ont pour objectif d’améliorer la qualité des produits,
de les combiner mathématiquement pour obtenir l’évaluation de ouvriront des opportunités de mise en œuvre des techniques
fiabilité du système complet dans son environnement cible. présentées dans cet article. La capacité à maîtriser la qualité de la
production de logiciel est en effet non seulement une nécessité
mais également un facteur clé pour garder un avantage
3.5.2.2 Présence de différents modes d’utilisation
du logiciel commercial compétitif. Dans ce contexte, le World Quality
Report [15], publié par Capgemini et HP, rapporte que « les respon-
sables informatiques perçoivent la qualité de leurs applications
Outre la différence entre fiabilité prévisionnelle et fiabilité expé-
comme un facteur d’efficacité et un réel différentiateur. Le vérita-
rimentale, la sûreté de fonctionnement fait aussi la distinction
ble challenge consiste à mesurer la qualité des applications de
entre fiabilité intrinsèque et fiabilité de service :
manière objective et pertinente pour optimiser leur stratégie et
– la fiabilité intrinsèque dépend de la qualité du logiciel et de mieux motiver leurs décisions ».
son processus de réalisation. Elle est le résultat du premier aléa Les plans d’amélioration des responsables informatiques
décrit dans l’introduction ; devraient donc se préoccuper non seulement de mettre en place
– la fiabilité de service dépend des conditions d’utilisation et de des processus de développement rigoureux qui permettent de
maintenance du logiciel. Elle est, entre autres, le résultat du réduire drastiquement la densité de défauts mais également de
second aléa décrit dans l’introduction. déployer les processus et outils de mesure de la croissance de
fiabilité du logiciel présentés dans cet article.
Cette distinction est importante dans le cas d’un logiciel puisque
sa fiabilité de service dépend fondamentalement de la manière
dont l’utilisateur le fait fonctionner. De nos jours, les logiciels sont 4.2 Intérêt certain du côté des donneurs
de plus en plus complexes et proposent des dizaines de fonctions d’ordre
qui ne sont en général pas toutes également employées par les
différents utilisateurs. La plupart des entreprises font, à la demande de leurs donneurs
d’ordre ou pour leur propre compte, des efforts considérables pour
La plupart du temps, le client a du mal à définir très exactement augmenter le niveau de maturité de leurs processus en s’appuyant
le profil opérationnel. De plus, les environnements d’essais ne entre autres sur les bonnes pratiques proposées par le référentiel
peuvent pas toujours être totalement représentatifs des environne- CMMI-Dev (Capability Maturity Model Integration for
ments opérationnels. Puisque l’environnement d’évaluation doit Development ) mis au point par le SEI (Software Engineering
être bien représentatif de l’environnement cible (profil d’utilisa- Institute ). Or, les mesures de fiabilité présentées dans cet article
tion), il faudra bannir notamment des évaluations utilisant les s’inscrivent parfaitement dans la mise en œuvre de métriques
résultats de tests de non régression, tests de couverture, tests aux permettant d’évaluer et prévoir les performances telles que le
bornes, etc. préconise le CMMI-Dev à partir du niveau 2 jusqu’au niveau 4.
Ces difficultés ne sont cependant pas insurmontables puisqu’en Les donneurs d’ordre s’intéressent également au CMMI-Acq
général, sous réserve que ces aspects aient été effectivement (Capability Maturity Model Integration for Acquisition ) qui leur
abordés, les experts arrivent à se mettre d’accord sur une mesure propose des bonnes pratiques pour mieux définir et maîtriser leurs
de sollicitation représentative et un profil moyen d’utilisation acquisitions de produits et services. Là encore, les méthodes
acceptable. En revanche, le pire cas est celui où ces points ne sont d’allocation d’exigences de fiabilité présentées précédemment
pas – ou sont mal – traités car ils sont absolument cruciaux pour la s’inscrivent tout à fait dans un objectif de maîtrise prédictive des
qualité des résultats à exploiter in fine. développements complexes.

4.3 Regain d’intérêt grâce Pour chaque stratégie, les essais ont duré 5 000 heures. La straté-
gie S1 a produit 70 défaillances, la stratégie S2 a produit 103 défaillan-
à l’automatisation des tests ces et la stratégie S3 en a produit 36.
Les travaux de modélisation de fiabilité du logiciel tendent à prou- A priori, on pourrait penser que la meilleure stratégie est la straté-
ver que les techniques usuelles de test du logiciel (basées sur des gie S2 parce qu’elle a fait apparaître un grand nombre de défaillances.
critères tels que le taux de couverture, la recherche des défauts aux Pourtant lorsque l’on évalue la fiabilité obtenue en fin de test, on
limites, etc.) ne permettent pas en général de bien évaluer la fiabilité trouve les taux de défaillance suivants : 1,2 × 10–2 ; 1,3 × 10–2 et
0,4 × 10–3 défaillance/heure respectivement pour les stratégies S1,
que le logiciel sera susceptible de présenter lors de son utilisation

opérationnelle. Il est même apparu dans de nombreux cas qu’une S2 et S3.
grosse partie de l’effort consacré au test d’un logiciel ne contribuait
Ces chiffres montrent que le raisonnement a priori était erroné. En
que faiblement à l’amélioration de sa fiabilité opérationnelle.
fait, la stratégie S2 a fait apparaître des défaillances dont la probabilité
Comme nous l’avons vu précédemment, le test selon le profil d’occurrence dans l’environnement opérationnel est excessivement
opérationnel est non seulement l’unique moyen permettant de faible et contrairement à ce que l’on aurait pu imaginer en se basant
garantir que le logiciel a atteint le niveau de fiabilité requis mais il uniquement ses qualités de « debuggage », elle n’a pas été plus effi-
est également l’un des moyens le plus efficace pour y cace pour améliorer la fiabilité. C’est la stratégie S3 (test selon le
parvenir [16]. profil opérationnel) qui contribue le plus à l’amélioration de la fiabilité
opérationnelle bien que ce soit celle qui ait fait apparaître le moins de
Prenons l’exemple d’un concepteur de logiciel ayant effectué des défaillances.
essais de validation selon trois stratégies différentes :
– la première stratégie (S1) générait aléatoirement les entrées de
manière à couvrir uniformément les fonctions ; De nos jours, avec l’arrivée des nouvelles techniques de MDT
– la deuxième stratégie (S2) tirait aléatoirement des valeurs (Model Driven Testing ) [17], la génération de test selon le profil
d’entrée aux bornes du domaine d’entrées spécifié ; opérationnel est facilitée. Les outils de génération de test automa-
– la troisième stratégie (S3) générait aléatoirement les entrées tique permettent de faire plus de test et donc d’accéder à des
exactement selon le profil d’utilisation prévu. chiffres de fiabilité plus performants [18].

P
O
U
Quantification de la fiabilité R
des logiciels
E
N
par Frédérique VALLEE
Agrégée de mathématiques
Docteur en statistiques S
Directeur associé de la société ALL4TEC, Massy
A
V
Sources bibliographiques
[1] EVERETT (W.), KEENE (S.) et NIKORA (A.). – par courbe d’apprentissage). IEEE Transac- [13] JELINSKI (Z.) et MORANDA (P.B.). – Software
O
[2]
Applying Software Reliability in the 1990s.
IEEE Transactions on Reliability, sept. 1998.
CARER (P.) et LECLERCQ (P.). – Maîtrise de
[8]
tions on Aerospace, AS-2 (1964).
KANOUN (K.). – Croissance de fiabilité du
reliability research. Proceedings of the Statis-
tical Methods for the Evaluation of Computer
System Performance, Academic Press
I
logiciel : caractérisation, modélisation et éva-
la fiabilité des nouveaux systèmes numéri-
ques à ERDF, application au futur système
« compteurs communicants ». Avignon
luation. Doctorat ès Sciences, Thèse LAAS,
Rapport de recherche no 89-320, sept. 1989. [14]
(1972).
LYU (M.R.). – Software reliability
R
[9] MUSA (J.), IANNINO (A.) et OKUMOTO (K.). engineering : a roadmap. Proceedings of Fu-
(2008). – Software Reliability : measurement, predic- ture Of Software Engineering, Minneapolis,
[3] KEENE (S.). – Keene development process tion, application. McGraw-Hill Book mai 2007.
SW reliability model : an early prediction Company (1990).
method. IEEE Reliability Society Newsletter,
vol. 57, no 2, mai 2011.
[10] MUSA (J.D.). – Operational profile in
software reliability engineering : more relia-
[15] HOWERY (R.) et RENDE (J.). – World quality
report. © Capgemini, Sogeti, HP (2011). P
[16] VALLÉE (F.) et VERNOS (D.). – Le test et la
[4] VALLÉE (F.) et VERNOS (D.). – Comment uti-
liser la fiabilité du logiciel comme critère
d’arrêt du test. 13e Colloque national de Fia-
ble software faster and cheaper (2nd edition).
AuthorHouse (2004). fiabilité du logiciel sont-ils antinomiques ?
12e Colloque national de Fiabilité et Mainte-
L
[11] LEBORGNE (V.). – M-élopée : un atelier de nabilité, Montpellier (2000).
[5]
bilité et Maintenabilité, Lyon (2002).
MILLS (H.D.). – On the statistical validation of
computer programs (validation statistique
calculs de fiabilité des logiciels. Revue Phoe-
bus, no 16, © M-élopée est une marque dé- [17] SCHIEFERDECKER (I.). – Model-based tes-
ting. IEEE Software, vol. 29, no 1, janv.-fév.
U
posée de France Télécom, janv. 2001.
des programmes informatiques). IBM Rep.
72-6015 (1972).
[12] FORNIER (A.), LOUSTALET (N.), NICOLOSO
(J.) et VALLÉE (F.). – Étude de la contribution [18]
2012.
LE GUEN (H.). – Validation d’un logiciel par
S
[6] NELSON (B.C.). – Software Reliability. Rep. du logiciel à la disponibilité du contrôle-com- le test statistique d’usage : de la modélisa-
TRW SS-75-05, nov. 1975. mande du Laser MégaJoules. 17e Colloque tion à la décision de livraison. Thèse Univer-
[7] DUANE (J.T.). – Learning curve approach to national de Fiabilité et Maintenabilité, La Ro- sité Rennes 1, Mention Informatique, juin
reliability monitoring (contrôle de la fiabilité chelle (2010). 2005.
À lire également dans nos bases

MORTUREUX (Y.). – La sûreté de fonctionnement : KAHN (P.). – Normalisation en matière de sûreté de VALLEE (F.). – Sécurité informatique pour la ges-
méthodes pour maîtriser les risques. [AG 4 670] fonctionnement des logiciels. [SE 2 510] Sécu- tion des risques. [SE 2 500], Sécurité et gestion
Conception et production (2001). rité et gestion des risques (2012). des risques (2010).
Supports numériques
ENSIMAG 3e année – Fiabilité des systèmes et des logiciels – Notes de cours Lou Gullo, Raytheon : Software Reliability Growth Approach
– Olivier Gaudoin http://www.dtic.mil/ndia/2010systemengr/ThursdayTrack8_10997Gullo.pdf
http://www.ljk.imag.fr/membres/Olivier.Gaudoin/FSL.pdf
Outils logiciels
CASRE (Computer Aided Software Reliability Estimation) Tool M-élopée
http://www.openchannelsoftware.com/projects/CASRE_3.0 http://www.all4tec.net
Événements
ERTS Embedded Real Time Software and Systems Lambda Mu – Congrès de l’IMDR (Institut de maîtrise des risques)
ISSRE International Symposium on Software Reliability Engineering

est strictement interdite. – © Editions T.I. Doc. SE 2 520v2 – 1
P QUANTIFICATION DE LA FIABILITÉ DES LOGICIELS ________________________________________________________________________________________
O
U Normes et standards
R CMMI-Acq 11-07 Capability Maturity Model Integration for Acquisi-

tion, Version CMMI-ACQ V1.2 Technical Report –
CMU/SEI-2007-TR-017
IEC 62 628
ISO/IEC 61 508
2010
2010
Guidance on Software Aspects of Dependability
Sécurité fonctionnelle des systèmes électriques/
électroniques/électroniques programmables rela-
CMMI-Dev 08-06 Capability Maturity Model Integration for Develo- tifs à la sécurité
pment, Version CMMI-DEV V1.2 Technical Report
– CMU/SEI-2006-TR-008 ISO/IEC 25 010 2011 Ingénierie des systèmes et du logiciel – Exigen-
ces de qualité et évaluation des systèmes et du
E FIDES 2004 Méthodologie de fiabilité pour les systèmes élec-
troniques
logiciel (SQuaRE) – Modèles de qualité du sys-
tème et du logiciel
IEEE 1633 2008 IEEE Recommended Practice on Software Reliabi- MIL HDBK 217 F 1995 Reliability Prediction of Electronic Equipment,
N lity (SR) Reliability Analysis Center and Rome Laboratory
Réglementation
S Il n’existe pas de règlementation relative à la fiabilité du logiciel mais plutôt
des règlementations relatives à la sécurité des systèmes programmés qui
sont hors scope du présent article.
A
Annuaire
V
Constructeurs – Fournisseurs – Distributeurs Formation « Fiabilité logicielle » de la société APSYS
O (liste non exhaustive)
ALL4TEC – Distributeur de l’outil M-élopée
http://www.apsys.eads.net
Formation « SYS 002 Sécurité des systèmes » de l’EUROSAE
http://www.eurosae.com/
I http://www.all4tec.net
Organismes – Fédérations – Associations
Laboratoires – Bureaux d’études – Écoles – Centres de
recherche (liste non exhaustive)
(liste non exhaustive)
R IMDR – Institut de Maîtrise Des Risques
http://www.imdr.fr
ENSIMAG – Grenoble IMP
http://www.ensimag.grenoble-inp.fr/
ISTIA – École d’ingénieurs de l’université d’Angers
UTE – Union technique de l’électricité http://www.istia.univ-angers.fr/
http://www.ute-fr.com/
Documentation – Formation – Séminaires
P (liste non exhaustive)
Formation « Fiabilité du logiciel » de la société ALL4TEC
L http://www.all4tec.net
U
S

Doc. SE 2 520v2 – 2 est strictement interdite. – © Editions T.I.
GAGNEZ DU TEMPS ET SÉCURISEZ VOS PROJETS
EN UTILISANT UNE SOURCE ACTUALISÉE ET FIABLE
Techniques de l’Ingénieur propose la plus importante

collection documentaire technique et scientifique
en français !
Grâce à vos droits d’accès, retrouvez l’ensemble
des articles et fiches pratiques de votre offre,
leurs compléments et mises à jour,
et bénéficiez des services inclus.
   
RÉDIGÉE ET VALIDÉE MISE À JOUR 100 % COMPATIBLE SERVICES INCLUS
PAR DES EXPERTS PERMANENTE SUR TOUS SUPPORTS DANS CHAQUE OFFRE
NUMÉRIQUES
 + de 350 000 utilisateurs

 + de 10 000 articles de référence
 + de 80 offres
 15 domaines d’expertise
Automatique - Robotique Innovation
Biomédical - Pharma Matériaux
Construction et travaux publics Mécanique
Électronique - Photonique Mesures - Analyses
Énergies Procédés chimie - Bio - Agro
Environnement - Sécurité Sciences fondamentales
Génie industriel Technologies de l’information
Ingénierie des transports
Pour des offres toujours plus adaptées à votre métier,

découvrez les offres dédiées à votre secteur d’activité
Depuis plus de 70 ans, Techniques de l’Ingénieur est la source

d’informations de référence des bureaux d’études,
de la R&D et de l’innovation.
www.techniques-ingenieur.fr
CONTACT : Tél. : + 33 (0)1 53 35 20 20 - Fax : +33 (0)1 53 26 79 18 - E-mail : infos.clients@teching.com
LES AVANTAGES ET SERVICES
compris dans les offres Techniques de l’Ingénieur
  
ACCÈS
Accès illimité Téléchargement des articles Consultation sur tous

aux articles en HTML au format PDF les supports numériques
Enrichis et mis à jour pendant Pour un usage en toute liberté Des contenus optimisés
toute la durée de la souscription pour ordinateurs, tablettes et mobiles
 
SERVICES ET OUTILS PRATIQUES
Questions aux experts* Articles Découverte Dictionnaire technique multilingue

Les meilleurs experts techniques La possibilité de consulter des articles 45 000 termes en français, anglais,
et scientifiques vous répondent en dehors de votre offre espagnol et allemand
 
Archives Impression à la demande Alertes actualisations
Technologies anciennes et versions Commandez les éditions papier Recevez par email toutes les nouveautés
antérieures des articles de vos ressources documentaires de vos ressources documentaires
*Questions aux experts est un service réservé aux entreprises, non proposé dans les offres écoles, universités ou pour tout autre organisme de formation.
ILS NOUS FONT CONFIANCE
www.techniques-ingenieur.fr
CONTACT : Tél. : + 33 (0)1 53 35 20 20 - Fax : +33 (0)1 53 26 79 18 - E-mail : infos.clients@teching.com

Quantification de La Fiabilité Des Logiciels

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Quantification de La Fiabilité Des Logiciels

Transféré par

Droits d'auteur :

Formats disponibles

Réf.

Cet article est issu de : Technologies de l'information | Technologies logicielles

par Frédérique VALLÉE

Pour toute question :

par Frédérique VALLÉE

1. Problématique générale de la fiabilité du logiciel ........................ SE 2 520v2 2

ien que les modèles de quantification de la fiabilité du logiciel soient un

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie