Faculté d'Ingénierie en Langue Etrangeres - Année universitaire 2010/2011

Fiabilité des logiciels

Préparé par: Grigore Roxana Irina Stanciucu Ana Maria

groupe 1230F

1. Présentation.............................................................................................. 2. Modèles à croissance de fiabilité........................................................ 2.1 Évolution des modèles................................................................................ — 2.2 Principaux modèles ..................................................................................... — 3. Mise en pratique des modèles de fiabilité........................................ 3.1 Apports ......................................................................................................... 3.2 Processus de collecte et d’étude ................................................................ — 3.3 Nature des données d’entrée ..................................................................... — 3.4 Exemple type d’étude de fiabilité............................................................... — 3.5 Limitations.................................................................................................... — Références bibliographiques.........................................................................

1. Présentation■Qu’est-ce que la fiabilité des logiciels ?La fiabilité d’un logiciel, ou plus généralement d’un système, désigne son aptitude à assurer sa mission dans des conditions d’environnement données et pendant une durée donnée. En d’autres termes, la fiabilité caractérise la confiance que l’utilisateur peut placer dans le service confiance que l’utilisateur peut placer dans le service rendu par un système.Dans cet article, la définition de la fiabilité du logiciel qui fait référence est : «La probabilité d’un logiciel à accomplir l’ensemble des fonctions spécifiées dans son document de référence, dans un environnement donné et pour un temps de fonctionnement donné. ». C’est une définition de fiabiliste, qui peut être évaluée par une expression mathématique et qui est donc beaucoup plus restrictiveque la définition de la fiabilité du logiciel donnée par exemple dans la norme ISO/IEC 9126 [2] comme étant «l’aptitude du logiciel à maintenir un niveau de performance requis lorsqu’il est utilisé dans les conditions spécifiées».Cette définition soulève dans le monde informatique principalement deux réticences [3].•La première réticence concerne l’utilisation des probabilitésSur un objet (le code) qui apparaît, à première vue, parfaitement déterministe.Pourtant le caractère aléatoire lié à la fiabilité du logiciel peut être expliqué. De fait, il y a même deux types d’aléas que l’on peut associer au processus d’apparition d’une défaillance du logiciel.Le premier aléa est celui qui fait qu’un défaut a une certaine probabilité d’être introduit dans le code. Les origines peuvent en être multiples : les spécifications étaient floues, les clients et fournisseurs se sont mal compris, le téléphone sonnait sans cesse dans le bureau du codeur, etc.Le deuxième aléa est celui qui fait qu’un défaut, généré par le premier aléa, a une certaine probabilité d’être activé lors de l’utilisation du logiciel et ainsi de produire une défaillance.•La deuxième réticence est due à l’existence, dans le domaine du logiciel, d’une autre approche très séduisante qui va totalement en contradiction aveccelle proposée en fiabilité du logiciel : il s’agit de l’approche qui consiste à dire qu’il suffit de corriger tous les défauts du code pour éliminer ainsi toute possibilité de défaillance du logiciel associé etramener le taux de défaillance à 0. Cette réticence est en fait liée à un autre point fondamental, à savoir, que l’amalgame entre fiabilité et comptage des défauts est fréquent. De fait, dans denombreux projets, pour évaluer le niveau de fiabilité atteint par le logiciel, les ingénieurs font souvent appel à des métriques qui s’appuient principalement sur le comptage des défauts dans le code : nombre de défauts mis en évidence en relecture, en test unitaire,etc. Ce dernier point s’inscrit tout à fait dans la problématique du mode de quantification de la fiabilité du logiciel développée ciaprès.

■Quel mode de quantification adopter ?La notion de fiabilité du logiciel n’a pas de signification dans l’absolu mais ne vaut que replacée dans le contexte d’évaluation de la fiabilité du système qui le contient. Pour bien s’en convaincre, il suffit de remonter à l’origine du besoin exprimé par l’utilisateur : le logiciel n’est pas pour lui une pure vision de l’esprit mais il est matérialisé par un système dans lequel le code binaire est exécuté avec un objectif de service à rendre.Ce qui intéresse l’utilisateur, c’est la confiance qu’il va pouvoir avoir dans la qualité du service rendu par le système indépendamment de son mode de réalisation.Au départ, le besoin est donc exprimé par le client au niveau du système.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 probabilité de réussite de mission. Comme le système est composé de matériels et de logiciels, et quelquefois d’hommes aussi, chacun pouvant être à l’origine d’une défaillance, la manière naturelle d’évaluer la fiabilité du système consiste à évaluer la part prise par chacune de ses composantes dans la fiabilité globale.Il s’ensuit donc clairement qu’il est indispensable de pouvoir exprimer 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 le référentiel assez communément admis depuis de nombreuses années pour les systèmes matériels est le taux de défaillance par heure. C’est donc le mode de quantification de la fiabilité dulogiciel qui est le mieux adapté (ou des modes équivalents).■Fiabilité prévisionnelle ou fiabilité expérimentale ?Que ce soit pour le matériel ou le logiciel, suivant les phases du cycle de vie où sont appliquées les techniques de fiabilité, elles sont qualifiées de prévisionnelles ou d’expérimentales.●Les techniques prévisionnelles se situent en amont dans les phases du cycle de vie et ont pour objectif principal de valider la conception du système parrapport aux objectifs de fiabilité visés.Dans le cas du logiciel, il n’existe actuellement pas de technique suffisamment mature pour évaluer la fiabilité prévisionnelle. Cette dernière relève donc encore du domaine de la recherche.●Les techniques expérimentalesconsistent à é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 situent en aval dans les phases du cycle de vie et ont pour objectif principal de vérifier l’obtention du niveau de fiabilité requis en analysant les faits techniques observés.Dans le cas du logiciel, il existe depuis une vingtaine d’années des méthodes et modèles qui commencent à être reconnus et qui permettent de mener à bien des études de fiabilité expérimentale. Par extrapolation du comportement déjà observé du logiciel, les modèles de fiabilité du logiciel apportent des éléments

quantifiés de la qualité de service, présente et à venir, sur lesquels il est intéressant, notamment, de s’appuyer pour conduire les tests [4].■Quelle pratique industrielle ?Les normes abordent très peu la quantification de la fiabilité : elles se placent sous l’angle du processus et imposent des méthodes de développement prédéfinies pour justifier l’obtention des différents niveaux de fiabilité requis.De ce fait, les principaux acteurs industriels restent très frileux pour appliquer les techniques de quantification de fiabilité des logiciels. Que ce soit en France ou à l’étranger, cette approche est actuellement très peu utilisée: par réticence, par manque d’exigences émanant des clients, par manque de normes.Le domaine de prédilection de l’emploi des modèles de fiabilité est le monde des télécoms qui a permis l’émergence des principaux modèles [5] et dont les systèmes sont de plus en plus complexes et doivent présenter une bonne disponibilité. Mais, même dans ce domaine, les exemples d’utilisation restent encore rares.Cela peut cependant évoluer dans les années à venir . En effet, les industriels se trouvant confrontés aux coûts exorbitants de mise en oeuvre des méthodes purement qualitatives (voir l’article TI [SE 2 500] [13]), ils souhaitent, quand cela est possible, pouvoir qualifier leurs logiciels comme cela se fait pour les matériels. Par ailleurs, la norme ISO/CEI 61508 [6] qui fait maintenant référence dans le domaine, associe des taux de défaillance quantifiés aux niveaux d’intégrité des systèmes, logiciels compris. Cela incite le industriels à essayer de justifier ce niveau, quand cela est possible, à l’aide d’essais de qualification employant les techniques présentées dans cet article.La fiabilité des logiciels est différent de la fiabilité matérielle.Sont deux facteurs:-introduction d’un défaut;-activation du défaut;Se relie à trois mesures:-complexité du texte du programme;-complexité structurelle du programme;-taux d’exécution des parties du programme.Il y a des tests: statique, symbolique, dynamique (structurel ou « boîte blanche »; fonctionnel ou « boîte noire »; fondé sur les défauts à détecter ).Quand les arrȇter?-Critère en fonction des jeux de tests;-Critère en fonction du nombre de défauts trouvés;-Critère en fonction du taux marginal de détection.But de l’évaluation de la SDF d’un logiciel: chiffrer l’impact des fautes deconception sur le fonctionnement du logiciel.Correction des fautes diagnostiquées, signifie améliorer la fiabilité = croissance .Modèles d’évaluation de la fiabilité signifie modèles de croissance de fiabilité.

2. Modèles à croissance de fiabilitéPrincipe de l’évaluation:-Observer le comportement du logiciel;-Effectuer les traitements statistiques sur les données relatives aux défaillances observées (phase de test, REX).Il faut avoir un support pour améliorer la fiabilié du logiciel.Collecte des données:Phase primordiale:il faut enregistrer:-la phase du cycle de vie;-le moment précis du début d’observation;-l’instant précis de chacune des défaillances et ses caractéristiques;-durée d’observation : temps CPU, nombre d’instructions etc;-environnement;-nature des solicitations.Analyse de la pertinence des données Les données collectées sont fiables et complétes.Il faut examiner les conditions d’utilisation et la collecte des données.Il doit utiliser des critères statistiques ( effectif, moyenne... ) : rechercher les données douteuses dans les valeurs extrȇmes.Comportement du logiciel -Domaine de défaillance;-Profil d’utilisation;-Modifications : correction; changement de spécification;Test de tendanceLe but est de:-évaluer l’évolution de la fiabilité;-choisir un modéle adapté.Les moyens sont: -les tests empiriques ( interprétations graphiques ); -tests statistiques : test de Laplace;Utilisation pratique de ces testsAnalyse globale de l’évolution: -Décroissance sur une période longue : problème; -Croissance brutale et de durée conséquante(ralentissement de l’activité de test).Guide dans le choix d’un modèle de croissance de fiabilité. 2.1 Évolution des modèlesLes premiers travaux sur la fiabilité des logiciels se sont intéressés à l’évaluation du nombre de défauts présents dans le code. Ainsi en 1972, Mills [7] a proposé un modèle basé sur la technique d’essaimage de défauts (introduction volontaire avant le test de défauts prédéfinis dans le code). En 1978, Nelson [8] a également proposé un modèle d’évaluation de la fiabilité des

logiciels. Mais ce modèle présentait l’inconvénient majeur de ne pas tenir compte de l’amélioration de fiabilité liée à la correction des défauts dans le logiciel.Les autres techniques utilisées pour évaluer la fiabilité des logiciels se sont alors largement inspiré des techniques employées sur les composantes matérielles, tout en veillant à les adapter spécialement au cas particulier de l’informatique qui fait appel à un processus de conception/correction (cf. l’article TI [SE 2 500] [13]). Cet aspect avait déjà été traité par Duane [9], dont le modèle prenait en compte la « croissance de fiabilité » et qui a inspiré la plupart des modèles de fiabilité du logiciel dont quelques-uns sont décrits ci-après.2.2 Principaux modèles■HypothèsesLes modèles de fiabilité du logiciel proposés dans la littérature [5] s’appuient, pour la plupart, sur deux hypothèses de base ayant un fort impact mathématique: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 qu’une seule fois.Hypothèse 2: cette correction est parfaite, c’est-à-dire qu’elle ne crée pas de nouveaux défauts dans le code. 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 en parallèle, les tests et les corrections.De ce fait, une même défaillance peut apparaître plusieurs fois dans une séquence de test. Il est néanmoins facile de simuler cette hypothèse en filtrant les défaillances avant d’appliquer les modèles. La véracité de la seconde hypothèse est aussi incertaine : la preuve en est des efforts importants que consacrent les industriels aux tests de non-régression, sans être pour autant arrivés à une 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 problèmesavec les résultats de modélisation.Ces deux hypothèses, vérifiées ou simulées, produisent nécessairement une croissance de fiabilité du logiciel.Entre les années 1970 et 1980, de très nombreux modèles de fiabilité du logiciel ont été proposés dans la littérature, chacun se voulant plus efficace que les précédents. Musa, Iannino et Okumoto [5] ont démontré que ces modèles étaient presque tous basés sur des processus binomiaux ou de Poisson. Ils ont ainsi pu construire une classification des modèles en fonction de la nature des processus régissant l’apparition des défaillances et de la forme mathématiquedu taux de défaillance associé. Cette classification est reproduite dans le tableau1.■Valeurs caractéristiques

On retrouve en fiabilité du logiciel les caractéristiques usuelles à savoir :le MTTF ( Mean Time To Failure ) et le taux de défaillance (cf. l’article TI [AG 4 670] [12]).On trouve aussi les deux fonctions particulières à l’étude des processus stochastiques que sont : le nombre cumulé de défaillances observées, noté dans cet article H ( t ) et l’intensité de défaillance, notée h ( t ) (figure 1). 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 équivalence est démontrée mathématiquement (ce qui est le cas dans les processus de Poisson [5]).

Tableau 1 – Classification des modèles de fiabilité du logicielForme du taux de panne

Processus binomial

Processusde Poisson

Autre

Modèles à nombre de défaillance finiExponentielle Jelinski-

Moranda(1972)Shooman(1972)

Musa(1975)Moranda(1975)Schneidewind(1975)Goel-Okumoto(1979)

Goel-Okumoto(1978)Musa(1979)Keiller-Littlewood(1983)

Weibull Schick-Wolverton(1973)Wagoner(1073)

Pareto Litlewood(1981)Gamma Yamada-Ohba-

Osaki(1983)Autre Shick-

Wolverton(1973)Modèles à nombre de défaillance infini

Géométrique Musa-Okumoto(1984)

Moranda(1975)

Inverse linéaire ou polynomiale

Litlewood-Verrall(1973)

Puissance Crow(1974)Autre Kanoun-

Laprie(1985)(1) En caractères gras dans le tableau, noms des modèles détaillés dans la suite.

Une clasification des modèlesMarkoviens : le processus de défaillance est supposé ȇtre un processus Markovien;NHPP : Processus de Poison Non Homogène;

Bayésiens : combine les informations connues et les informations issus des tests;Métriques : Relation entre les mesures de la complexité et le nombre de défaillance.Quelques modèles de croissance de fiabilité:Conditions préalables à l’application d’un modèle:-recueil de collecte de données;-« objectifs » spécifiés;-analyse des observations en 3 phases.Les trois phases de l’analyse sont:-présentation des données;-recherche des paramètres représentatifs;-preuve du modèle en trois étapes.Les trois étapes de la preuve du modèle sont:-caractérisation d;une variable aléatoires indépendante;-vérification de la tendance de croissance par des tests;-choix d’un modèle approprié.Il y a des modèles classiques :-modèles basés sur le taux de défaillance;-modèles basés sur l’intensité de defaillance.Principes de modélisationUne fois la forme mathématique du modèle choisie, la modélisation fait appel à :- une procédure d’inférence permettant de calibrer le modèle, c’est-à-dired’estimer ses paramètres en fonction des données recueillies lors des essais ;- une procédure de prévision qui consiste à remplacer, dans l’expression des caractéristiques de la fiabilité, les paramètres par leurs valeurs estimées ;- un ou plusieurs critères de validation qui permettent de vérifier l’adéquation des estimations obtenues aux valeurs observées et de comparer plusieurs modèles pour choisir le « meilleur » d’entre eux.En d’autres termes, la modélisation consiste à utiliser des outils 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.Les techniques statistiques de calcul des paramètres sont connues sous le nom de méthodes du « maximum de vraisemblance », des « moindres carrés » ou des « moments ». Ces techniques déterminent les paramètres qui s’ajustent le mieux aux données observées selon différentes distances statistiques. La méthode du maximum de vraisemblance est celle qui est la plus fréquemment utilisée pour calculer les paramètres des modèles de fiabilité du logiciel.■

Équations des modèlesNous donnons ci-après les caractéristiques de trois modèles aux hypothèses distinctes (un modèle pour chaque colonne du tableau 1).Difference fondamentale entre les deux catégories :-la première suppose une amélioration discontinue de la fiabilité

Taux de défaillance

t

-la seconde intègres cette discontinuité

Intensité de défaillance

t

Modèles à taux de défaillance

●Modèle de Jelinski-Moranda (1972)Ce modèle est l’un des premiers modèles à taux de panne proposé pour le logiciel. Il fait « naturellement » l’hypothèse que l’intensité de défaillance décroît d’une valeur constante Φ à chaque fois qu’un défaut est détecté et corrigé, et ce jusqu’à ce qu’il n’y ait plus de défaut dans le code. Dans ce modèle :Hi(t) = λiexp(−it)hi = (N−(i−1)) Φ avec N nombre total de défauts, supposé fini.-les intervalles de temps entre deux défaillance consécutives suivent une loi exponentielle;

-les taux de défaillance est proportionnel au nombre de défauts dans le programme.

Jelinski-Moranda

-allure du taux de déffailance

λ(t)

t

Jelinski-Moranda – Résultats

-fiabilité aprés n défaillances;

-MTTF;

-temps pour trouver les erreurs restantes.

Modèle de Musa-Okumoto (ou « modèle logarithmique ») (1984)Ce modèle suppose que l’intensité décroît exponentiellement avec le nombre dedéfaillances (figure2). Cela signifie que la correction des premiers défauts mis en évidence réduit plus l’intensité de défaillance que la correction des défauts suivants. Dans ce modèle, le nombre de défaillances possibles est infini et la fiabilité est croissante :H(t) =λ0ln(λ0θt+ 1) où λ0 et θ> 0.

h(t) = λ 0

λ 0 θt+1Modèle de Littlewood-Verrall (1973)Il s’agit ici d’un modèle bayésien. Selon la vision bayésienne, le logiciel est d’autant plus fiable qu’on le voit fonctionner longtemps sans défaillance. Deplus, ce modèle tient compte de la nature aléatoire du processus de correction des fautes : on peut en effet considérer qu’il est impossible de déterminer quelle est l’incidence réelle de la correction d’une faute sur le taux de défaillance global du logiciel.Dans ce modèle :-les intervalles de temps entre deux défaillances consécutives suivent une loi de Pareto de paramètres α et Ψ;

-α et Ψ(i) sont estimés par la méthode du maximum de vraisemblance.

Littlewood-Verral

-allure du taux de défaillance

λ(t)

t

Littlewood-Verral – Résultats

-fiabilité après n défaillances;

-MTTF;

-nombre moyen de défaillances à un instant t.

CROW :

-modèle NHPP;

-l’intensité de défaillance suit une loi puissance du temps t de paramètres α et β;

-modélisation de la croissance ou de la décroissance.

Crow - Résultats :

-fonction de fiabilité;

-nombre moyen de défaillance à l’instant t.

Principe bayésien

Pourquoi l’approche bayésienne ?

-prise en compte d’informations subjectives;

-application à des systèmes de haute fiabilité où l’observation des défaillances est difficile;

-la fonction de vraisemblance a ses limites.

L’avantage de l’approche bayésienne est d’utiliser les deux sources d’information disponibles :

-ce que « pensent » les experts;

-l’observation du système.

RGA: Logiciel d'Analyse de Croissance de Fiabilité

Croissance de fiabilité et analyse des systèmes réparables

Le logiciel RGA de ReliaSoft donne accès à de puissantes fonctions qui vous permettront d'utiliser les modèles de croissance de fiabilité pour l'analyse des données issues aussi bien de systèmes réparables en exploitation que d'essais de développement. L'utilisation du logiciel en phase développementale vous permet de quantifier la croissance de fiabilité accomplie grâce à chaque prototype de modèle. Il fournit également des méthodes avancées de projection de croissance, gestion et planification de la fiabilité. Pour les systèmes en opération, RGA vous permet de calculer le temps de révision optimal ainsi que d'autres résultats sans avoir besoin des ensembles de données qui sont normalement requis.

Le développement de RGA est le fruit d'une collaboration entre la société ReliaSoft, le Dr. Larry Crow (EN), qui est la plus haute autorité en matière d'analyse de croissance de fiabilité, ainsi que plusieurs représentants industriels et gouvernementaux. Ce partenariat a permis de développer un progiciel axé sur les applications et qui comprend tous les principaux modèles de croissance de fiabilité ainsi que des formules de calcul qui ne sont disponibles nulle part ailleurs. 

Caractéristiques du Logiciel

RGA prend pleinement en charge les analyses de croissance de fiabilité traditionnelles utilisant les modèles appropriés tels que Crow-AMSAA (NHPP), Duane, Gompertz, Gompertz modifié, Logistique ou Lloyd-Lipow pour différents types de données de développement comme temps avant défaillance, discrètes (succès/échec) et données de fiabilité. De plus, le logiciel est le seul à prendre en charge des approches innovatrices qui facilitent les projections de croissance de fiabilité, le développement d'un programme de croissance de fiabilité et l'analyse de croissance de fiabilité à plusieurs phases. RGA permet de créer des plans d'essais opérationnels qui rationalisent tous les profils de mission

qui doivent être testés pour s'assurer de l'adéquation des données recueillies aux critères de l'analyse de croissance de fiabilité. Le logiciel permet également de réaliser des analyses sur les systèmes réparables en exploitation, au moyen d'un utilitaire de Conception d'Essais de Fiabilité (DRT en anglais) ainsi qu'une méthode conçue pour analyser le comportement de la fiabilité dans le temps pour pouvoir calculer les temps de révision optimaux et d'autres résultats particulièrement indicatifs.

Formation

ReliaSoft offre un programme de formation de trois jours qui couvre de manière approfondie l'application des modèles d'analyse de croissance de fiabilité pour évaluer les données issues aussi bien d'essais de développement que de systèmes réparables en exploitation. En combinant des bases théoriques solides à des exemples d'application pratiques et l'utilisation concrète du logiciel, ce cours vous apportera les connaissances et les compétences nécessaires à l'application de ces techniques de fiabilité primordiales.

Caractéristiques de RGA

RGA de ReliaSoft est un progiciel tout particulièrement destiné à l'application des principaux modèles de croissance de fiabilité, ainsi que de méthodes d'analyse avancées qui ne sont disponibles nulle part ailleurs.

Analyses et Résultats de Croissance de Fiabilité Traditionnels

RGA prend en charge tous les modèles de croissance de fiabilité traditionnels :

Crow-AMSAA (NHPP) Duane Gompertz standard et modifié Lloyd-Lipow Logistique

Le logiciel offre des options de Temps Avant Défaillance (continu), discret (succès/échec) et pour les données de fiabilité provenant de différents types d'essais de développement (de croissance de fiabilité). Ces modèles sont disponibles en fonction du type de données analysé.

Projection, Planification et Gestion de Croissance de Fiabilité

RGA est le seul logiciel à prendre en charge plusieurs approches innovatrices qui vont au-delà des méthodes habituelles de croissance de fiabilité pour mieux représenter les techniques d'essai et d'application pratiques.

Le modèle Crow Etendu classifie les modes de défaillance en fonction de si et quand une correction peut être effectuée. Cette analyse permet de réaliser des projections de croissance de fiabilité et d'évaluer la stratégie de gestion de la croissance de fiabilité.

Le Folio de Planification de Croissance vous aide à créer un plan d'essai de croissance de fiabilité multiphase. De plus, vous pouvez utiliser le modèle Crow Etendu – Evaluation Continue pour analyser les données provenant d'essais ayant plusieurs phases et générer un Tracé Multiphase qui permet de comparer les résultats des essais par rapport au plan. Cette analyse vous aide à déterminer s'il sera nécessaire d'ajuster les futures phases d'essai pour vous permettre d'atteindre le niveau de fiabilité voulu.

Le Folio de Profil de Mission facilite la création d'un plan d'essai opérationnel équilibré et d'effectuer un suivi comparatif continu des essais par rapport au plan pour s'assurer de l'adéquation des données recueillies aux critères de l'analyse de croissance de fiabilité.

Exploiter Pleinement un Ensemble de Données Limité pour l'Analyse d'un Système Réparable en Exploitation

RGA prend également en charge l'analyse des systèmes en exploitation. Les différents outils d'analyse comprennent un nouvel utilitaire de Conception d'Essais de Fiabilité (DRT en anglais) pour les systèmes réparables (basé sur le processus de Poisson non homogène) ainsi que des feuilles de données conçues exclusivement pour l'analyse des données issues de systèmes en exploitation. Vous pourrez réaliser plusieurs types d'analyses en fonction des caractéristiques de votre ensemble de données, telles que :

Analyser les temps de défaillance des systèmes réparables en exploitation, de manière à connaître la fiabilité dans le temps et calculer les indicateurs les plus révélateurs (tels que le temps de révision optimal ou encore le nombre de défaillances présumées), sans avoir besoin des ensembles de données détaillés qui sont normalement requis.

Evaluer l'amélioration de fiabilité générée par le déploiement de réparations sur un parc d'unités en exploitation chez le client.

Utiliser l'analyse des données groupées (censurées par intervalle) pour évaluer les données de garantie issues d'un parc d'unités pour réaliser une estimation des retours sous garantie auxquels on peut s'attendre.

Pourquoi se mettre à niveau vers RGA 7

La Version 7 offre une interface utilisateur complètement remodelée et de nombreuses nouvelles fonctions, telles que :

Planification de croissance de fiabilité et analyse des essais comprenant plusieurs phases

Profils de missions opérationnels Conception d'essais de fiabilité (DRT) pour les systèmes réparables Génération de données de Monte Carlo et SimuMatic® 3. Mise en pratique des modèles de fiabilité 3.1 Apports Les modèles de fiabilité du logiciel permettent de faire des calculs

prévisionnels du nombre moyen de défaillances ou de la probabilité d’apparition de problèmes ultérieurs en fonctionnement opérationnel.

L’intérêt de la prévision fournie par les modèles de fiabilité est multiple : - en cours de test, elle permet de dimensionner l’équipe de correction en

conséquence. Dans le cas où la même équipe passe les tests et effectue les corrections, il est possible, grâce à cet indicateur, de savoir quelle charge affecter au test par rapport à la charge affectée à la correction ;

- en fin de test, elle permet de savoir si les objectifs de fiabilité sont atteints et, si ce n’est pas le cas, de réviser la politique de test en conséquence ;

- enfin, au moment de la mise en service du logiciel, elle permet d’annoncer au client quel sera le comportement le plus probable de logiciel pendant ses premiers mois de fonctionnement.

Toutes les valeurs chiffrées fournies par les modèles sont assorties des valeurs chiffrées du risque associé qui permettent ainsi de choisir

entre une confiance élevée dans un niveau de fiabilité minoré et une confiance moindre dans un niveau plus élevé.

3.2 Processus de collecte et d’étude La démarche de quantification de la fiabilité des logiciels impose de

mettre en oeuvre deux activités de natures différentes : une action continue de collecte de données et des actions ponctuelle d’étude de fiabilité.

La collecte des données

se termine par une étape permettant de débroussailler les données, appelée « analyse a priori ». Après quoi les études de fiabilité du logiciel se déroulent en trois étape successives : étude des tendances, modélisation et 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 résume cette démarche dont chaque étape est décrite en détail dans les paragraphes qui suivent.

■ Recueillir les données Dès que le logiciel est dans une phase relativement stable, en général en

phase de test d’intégration ou de validation, il faut releve le signal d’apparition des défaillances.

Nota :rappelons que les modèles employés sont des modèles de fiabilité expérimentale (par opposition aux modèles de fiabilité prévisionnelle)

puisqu’il est nécessaire de disposer d’un logiciel exécutable pour en évaluer la fiabilité . Cela peut être réalisé de deux manières :

- soit en relevant la date d’apparition de chaque défaillance, on dit alors que l’on a des données unitaires;

-soit en relevant le nombre de défaillances qui se sont produites dans une durée de sollicitation donnée, on dit alors que l’on a des données groupées par intervalle de temps.

Dans la pratique, connaissant les objectifs de fiabilité alloués, il est possible de déterminer quelles sont les données à recueillir, avec quelle précision et granularité elles doivent être recueillies, et quelles analyses elles doivent subir. Au minimum, ces données concernent la sollicitation du logiciel lors du test (cahier de bord de test) et les anomalies qu’il a présentées lors de cette exécution (rapports d’anomalies).

Nota : alors que le relevé des défaillances est presque toujours réalisé systématiquement par les équipes de validation, il n’est pas encore rentré dans les moeurs de garder une trace détaillée de la manière dont le logiciel a été solicitè pendant les tests.

De plus amples informations sur la nature des données à collecter sont données au paragraphe 3.3.■Analyser a prioriL’analyse a priori permet de détecter et d’éliminer les données douteuses. Lasaisie informatique des données est conseillée. Elle permet 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’apparition de valeurs a priori douteuses : il est alors nécessaire de retrouver les intervenants ayant participé aux saisies liées à ces erreurs afin d’expliciter ces valeurs et, éventuellement, de les 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.Nota : il est recommandé de commencer l’analyse des données dès que la quantité de données est suffisante pour l’interprétation des premiers résultats, afin de vérifier très tôt la cohérence de l’information. Dans le cas où les données douteuses sont ponctuelles et noyées dans la masse, il est conseillé de ne pas y toucher car les modèles de fiabilité ne sont pas trop sensibles à quelques fluctuations intempestives clairsemées.■Étudier les tendancesAprès s’être assuré de la qualité et de la représentativité des données, l’analyste peut passer à l’étude des tendances dont l’objectif est de mettre en évidence les zones de croissance et de décroissance de fiabilité.Pour cela, il examine la courbe d’apparition des défaillances en fonction de la sollicitation. Si la courbe du nombre cumulé de défaillances présente une pente en diminution, il y a vraisemblablement croissance de fiabilité. Il examine aussi les courbes de MTTF par sous-intervalle. Le MTTF est une caractéristique de fiabilité exprimant la moyenne des temps de fonctionnement jusqu’à défaillance. Si cette moyenne augmente, il y a vraisemblablement croissance de fiabilité.Enfin, dans le cas de données de type « unitaires » ou « groupées par intervalle de temps constant », le statisticien dispose d’un outil mathématique permettant de tester la tendance (croissance ou décroissance de fiabilité) : il s’agit dutest de Laplace [10].Nota : le test de Laplace compare la moyenne des milieux des intervalles entredé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 suffisamment inférieure au milieu.Cette étape facilite les étapes suivantes puisqu’elle permet 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 ».■ModéliserRappelons que la modélisation consiste à utiliser des outils mathématiques permettant de calibrer un modèle d’une forme donnée sur le processus révélé par l’échantillon.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.Comme il n’existe pas de modèle universel, il faut choisir le modèle le plus adapté en regardant celui qui correspond le mieux aux données connues. Pour cela, on peut procéder selon trois étapes successives qui éliminent petit à petit les modèles n’offrant pas toutes les qualités requises.

● La première étape consiste à superposer les courbes réelles et les courbes du modèle (courbes du nombre cumulé de défaillances en fonction du temps et, si nécessaire, courbes des MTTF ou taux de défaillance par sous-intervalles). Les modèles présentant des courbes trop éloignées des courbes réelles ou ayant une forme trop différente des formes des courbes réelles peuvent être éliminés.● Dans la deuxième étape , pour choisir des modèles qui prévoient bien le comportement futur, on recalcule les paramètres des modèles à partir des données de sous-ensembles croissants de l’échantillon total (modélisations successives avec données (« cachées ») et l’on compare avec la réalité les prévisions successives.Les modèles qui sont trop éloignés de la réalité ou qui convergent trop tardivement peuvent être éliminés.Exemple :dans la figure 4 , la première étape conduit ainsi à supprimer les modèles de Crow, Kanoun-Laprie (hyper-exponentiel) et Littlewood-Verrall qui n’ont pas la même forme que la courbe des données réelles (statistique).Outre l’évaluation des mesures de fiabilité, les modèles offrent en général la possibilité de calculer le temps nécessaire pour atteindre un objectif. On peut, par exemple, estimer le temps de test encore nécessaire pour obtenir un taux de défaillance prédéterminé. Ils permettent également d’estimer la probabilité de passer avec succès des essais de recette dans la mesure où l’on connaît la nature de la sollicitation que le logiciel subira lors de ces 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 même manière d’estimer le nombre moyen de défaillances qu’un logiciel est susceptible de produire lors de sa mise en opération.Nota : dans le cadre d’un engagement contractuel, il est important que toutes les hypothèses attachées aux objectifs soient bien réunies ou simulées pour procéder à une prévision à l’aide d’un modèle de fiabilité. Ces hypothèses concernent en général :-le profil d’utilisation 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 ;- la nature des défaillances à prendre en compte pour la prévision ;- la définition précise de l’objectif à mesurer (MTTF instantanée, taux de défaillance).Pour que les prévisions soient correctes, il est souhaitable qu’elles portent sur un temps de fonctionnement du même ordre de grandeur que le temps de fonctionnement déjà connu sur lequel elles s’appuient. Autrement dit, le temps connu (de test) et le temps estimé (opérationnel) doivent rester dans le même ordre de grandeur.■ Formalisation des résultatsUne étude de fiabilité se termine classiquement par la rédaction d’un rapport présentant les travaux réalisés et les résultats obtenus.

Selon l’étape dans laquelle on se situe, ce rapport peut avoir la forme d’une simple note technique présentant les données, les courbes et modèles de fiabilité, les valeurs prévues ou la forme d’un rapport plus fourni rappelant les concepts de fiabilité expérimentale et la manière dont ils ont été appliqués sur le projet, ainsi que les résultats obtenus aux différentes étapes d’étude. Cette dernière partie peut être tout simplement une concaténation des notes techniquesintermédiaires rédigées sur le projet. Dans tous les cas de figure, et notamment lors d’une prise de décision s’appuyant sur les résultats présentés, le lecteur devra être familiarisé avec les principes de base de la fiabilité expérimentale,ses tenants et aboutissants, et surtout ses pièges et erreurs à éviter.■ Les principaux acteurs de la démarcheEn général, trois types d’acteurs interviennent dans la démarche de collecte et d’étude :- les chefs de projet interviennent à haut niveau. Ils rappellent les délais, allouent les ressources, valident les objectifs de fiabilité et prennent les décisions ad-hoc à la lumière des résultats des études de fiabilité ;- les ingénieurs fiabilistes définissent les procédures de collecte, supervisent la collecte, enregistrent les données et les vérifient, font les calculs, valident et testent les objectifs de fiabilité. En résumé, ils font des études et les interprètent pour les chefs de projet ;- les ingénieurs de test ou de maintenance, avec les utilisateurs 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. En résumé, ils font les essais, la collecte des données sur le terrain et ils font remonter les problèmes aux deux acteurs précédents.En général, les ingénieurs fiabilistes font partie d’un service indépendantdes projets et sont affectés au cas par cas sur les projets.3.3 Nature des données d’entrée■ Définition de la variable de mesure de sollicitationCette variable doit être choisie en fonction de la nature du logiciel et de ses objectifs de fiabilité. Ce choix est en général un 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 pour représenter effectivement la sollicitation du logiciel.Nota : le temps calendaire est une mesure de sollicitation qui n’est pas recommandée.C’est la variable à utiliser quand on ne dispose vraiment d’aucune autre information !– Le temps CPU d’exécution est une variable représentative de la durée horaire des exécutions du logiciel et constitue une meilleure approximation que le temps calendaire. Il peut s’avérer cependant difficile ou coûteux à collecter.

– La quantité d’informations traitées est une variable plus spécifiquement adaptée aux logiciels pour lesquels le nombre d’éléments manipulés est plus significatif que les instructions exécutées pourreprésenter finement la sollicitation du logiciel. Une fois que la variable de sollicitation adéquate a été choisie, il est en général assez facile de la relier, souvent par une simple règle de 3, au temps de fonctionnement du système de manière à pouvoir utiliser les résultats de fiabilité obtenus sur le logiciel dans une consolidation au niveau du système.Nota : rappelons que, dans cet article, nous faisons l’amalgame entre « temps de fonctionnement » et « sollicitation » qui recouvrent les mêmes concepts.■ Précision de la datationUne fois la variable de mesure de la sollicitation choisie, il importe de déterminer la précision de la datation de l’apparition des défaillances dans cette sollicitation. Cette précision déterminera la nature des données soumises à l’étude : données « unitaires » ou données « groupées » (cf. paragraphe 3.2).Chacun de ces types de données a ses avantages et ses inconvénients.● Les données « unitaires » sont plus coûteuses à recueillir. En revanche, elles permettent l’utilisation du test de Laplace pour l’étude des tendances. Statistiquement, elles produisent un échantillon de taille plus grande que celui obtenu avec des données « groupées ».● Les données « groupées » sont les plus faciles à recueillir et ce sont celles qui correspondent le plus aux habitudes industrielles courantes. Si le test de Laplace ne peut pas être utilisé dans ce cas, il peut être remplacé par le simple examen de la courbe des MTTF par sous intervalles dont les fluctuations apportent une information similaire.Par ailleurs, certains modèles n’acceptent que des données de type « unitaire » ou de type « groupé » en entrée.■ Données minimales nécessairesQuels que soient les objectifs et la nature du projet, il existe un sous-ensemble minimal de données dont il faut absolument pouvoir disposer pour réaliser des études de fiabilité. Ainsi, les informations indispensables à recueillir sont :- 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 tests élémentaires, ou nombre de transactions, etc.) ;- en ce qui concerne la défaillance : un identifiant unique, la date d’apparition (ou période de test), le type de défaillance. Afin de ne prendre en compte que les données relatives au logiciel, l’origine de chaque défaillance détectée doit être précisée (cette défaillance est-elle bien due au logiciel ?). Il s’agit aussi de pouvoir reconnaître les défaillances ayant la même origine ou celles dues à des corrections imparfaites. Il est donc nécessaire d’avoir accès aux informations relatives aux corrections effectuées et de pouvoir relier entre elles les données relatives aux défaillances et celles relatives aux correction.

■ Formulaires de collecteLes deux supports de collecte habituellement employés pour caractériser les défaillances et les corrections sont respectivement : la fiche de défaillance (ou fiche d’anomalie) et la fiche de correction. Les informations sur la sollicitation doivent être extraites d’un journal de bord de test ou d’exploitation. Nous présentons sur la figure 9, à titre indicatif, un exemple de fiche de défaillance. Elle pourra être modifiée, allégée ou complétée, selon les types de logiciels, les procédures en vigueur dans l’entreprise et les objectifs de la collecte des données.3.4 Exemple type d’étude de fiabilitéSupposons qu’un chef de projet soit en phase de test d’un logiciel dont l’objectif de fiabilité de service est fixé à 2 · 10−2 défaillance/ heure. Au bout de 3 mois de test selon le profil d’utilisation, il a déjà détecté 61 défauts et cumulé 620 heures de sollicitation. Il souhaite savoir s’il tiendra son délai total de 5 mois de test en ayant atteint la fiabilité objectif.Le modèle de Musa-Okumoto s’avère être le modèle qui s’adapte le mieux à ses données. 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 (cf. figure 10). Étant donné qu’il a déjà cumulé 620 heures de test, il en déduit 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 excès) seront cumulées à l’issue de ces 958 heures de test. Étant donné qu’il a déjà mis en évidence et corrigé 61 défaillances, il en déduit qu’il lui faudra encore corriger en moyenne 9 défaillances jusqu’à la fin du test.À l’aide de ces valeurs, le chef de projet calcule qu’il lui faudra 1 mois de délai pour passer le complément de test et 15 jours supplémentaires (10 jours ouvrés) pour corriger les 9 défauts prévus en faisant l’hypothèse d’une charge de correction d’un jour par défaut en moyenne. Il a prévu assez large pour le temps de passage du complément de test qui n’est pas le plus grand consommateur de délai. En revanche, chaque défaut étant en moyenne assez long à corriger, et 9étant une valeur moyenne, que se passerait-il s’il y avait plus de 9 défauts qui apparaissaient pendant ce temps ? Là encore, l’outil M-élopée renseigne le chef de projet en lui donnant une valeur qui ne sera pas dépassée avec une probabilité maximale fixée. Ainsi, pour un risque inférieur à 10 %, l’outil lui proposeune valeur maximum de 13 défauts à corriger. Le chef de 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 heure, et qu’il pourra lui démontrer que la fiabilité objectif est 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 ainsile test au bout de 1 030 heures en ayant corrigé 13 défauts supplémentaires.Il lui reste une semaine pour peaufiner sa livraison. Il tient ainsi parfaitement ses délais et son objectif de fiabilité. La tenue de l’objectif de fiabilité permet aussi

au client de faire ses propres prévisions. Connaissant la sollicitation totale prévue pour ce logiciel pendant sa première année d’exploitation, le client 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 projet en test. Il peut alors utiliser cette valeur pour dimensionner son besoin en maintenance pour ce logiciel.3.5 Limitations■ Limitations du retour d’expérienceMême abordés avec toute la rigueur voulue, les modèles de fiabilité héritent des limitations propres à l’utilisation du retour d’expérience pour valider l’obtention d’un objectif de fiabilité, à savoir : les heures de fonctionnement à acumuler dans ce retour d’expérience sont inversement proportionnelles à la valeur du taux de défaillance à estimer. Cela signifie que pour évaluer un taux de défaillance de 10−5 par heure, il faut cumuler un temps d’expérience sans défaillance d’au moins 100 000 heures et même 400 000 heures si l’on veut avoir une bonne confiance dans l’évaluation. Or 400 000 heures représentent45 ans à plein temps !Par ailleurs, les techniques d’accélération de test utilisées pour le matériel ne sont pas applicables au logiciel : d’une part, on sait rarement accélérer le temps de fonctionnement, notamment quand il s’agit de logiciels réactifs nécessitant l’intervention humaine continuelle pour fonctionner, et d’autre part 100 logiciels en parallèle sous la même sollicitation réagissent en général de la même manière. En d’autres termes, pour le logiciel : 100 × 1 000 heures de fonctionnement = 1 000 heures de fonctionnement.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 telle que 10−6 défaillance/heure. Dans le cas où une telle exigence 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énement redouté doit être pratiquement ramenée à zéro.Pour vérifier cela, il vaut mieux alors utiliser les techniques qualitatives (cf. l’article TI [SE 2 500] [13]) qui donnent aux concepteurs et au client une bonne confiance dans le fait que les défaillances redoutées ne se produiront vraisemblablement pas dans l’environnement de fonctionnement spécifié du système.■ Impact de l’environnement sur la fiabilitéOutre la différence entre fiabilité prévisionnelle et fiabilité expérimentale, la sûreté de fonctionnement fait aussi la distinction entre fiabilité intrinsèque et fiabilité de service :- la fiabilité intrinsèque dépend de la qualité du logiciel et de son processus de réalisation. Elle est le résultat du premier aléa décrit dans l’introduction ;- la fiabilité de service dépend des conditions d’utilisation et de maintenance du logiciel. Elle est, entre autres, le résultat du second aléa décrit dans l’introduction.

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 de plus en plus complexes et proposent des dizaines de fonctions qui ne sont en général pas toutes également employées par les différents utilisateurs.La plupart du temps le client a du mal à définir très exactement le profil opérationnel. De plus, les environnements d’essais ne peuvent pas toujours être totalement représentatifs des environnements opérationnels.Ces difficultés ne sont cependant pas insurmontables puisqu’en général, sous réserve que ces aspects aient été effectivement abordés, les experts arrivent à se mettre d’accord sur une mesure de sollicitation représentative et un profil moyen d’utilisation acceptable.En revanche, le pire cas est celui où ces points ne sont pas – ou sont mal – traités car ils sont absolument cruciaux pour la qualité des résultats à exploiter in fine.■ Limitations du nombre de paramètres des modèlesTous les modèles de fiabilité sont paramétrés (cf. § 2.2). Dans la plupart des cas, ces paramètres sont au nombre de deux ou, exceptionnellement, trois. Cela signifie que l’on ne dispose que de deux constantes (trois dans le meilleur des cas) pour caractériser les deux variables aléatoires concourant à la fiabilité du logiciel, et liées respectivement à la qualité intrinsèque du code et à son environnement d’utilisation.Les modèles ne peuvent donc pas supporter trop de diversité :- Il faut que le code ait une qualité intrinsèque peu dispersée.C’est en général le cas mais il faut se méfier des gros systèmes pouvant intégrer des sous-ensembles d’origines différentes, ou ayant été développés par des équipes, avec des méthodes ou des langages différents ;- Il faut que l’environnement d’évaluation soit bien représentatif de l’environnement cible (profil d’utilisation). Sont à bannir notamment des évaluations utilisant les résultats de tests de non régression, tests de couverture, tests aux bornes, etc.D’un point de vue opératoire, il est donc indispensable de s’assurer du respect de ces règles ou, pour s’y ramener, de structurer les données à modéliser en plusieurs sous-ensembles les respectant. Une fois les modélisations partielles effectuées, il est alors possible de les combiner mathématiquement pour obtenir l’évaluation de fiabilité du système complet dans son environnement cible.

Références bibliographiques

1. Fiabilite des Systemes et des Logiciels - Olivier Gaudoin 2. Sur la modelisation structurelle markovienne en fiabilite du logiciel, 1995 - James Ledou 3. http:// www.groupe-all4tec.net