Chapitre 5 – Perspectives d’intégration dans un processus de développement
5.2 De l’utilisation des AMDEC
L’analyse des modes de défaillance, de leurs effets et de leur criticité (AMDEC) [32] [33] est une démarche dont le principe fondamental est d’analyser pour chaque composant d’un système les conséquences d’une défaillance et sa probabilité d’occurrence. Cette démarche doit être systématique et collective afin d’examiner avec précision chaque mode de défaillance. Idéalement cette démarche doit être effectuée par un groupe de personnes dont les compétences englobent tous les aspects du système (de la couche matérielle jusqu’aux interactions avec l’environnement) et doit permettre à chaque participant de représenter un point de vue ou une expertise.
Ainsi pour chaque mode de défaillance il faut identifier et évaluer : -Sa cause et son indice de fréquence.
-Ses effets et son indice de gravité.
-Les mesures mises en place pour détecter la défaillance et l’indice de détection. On calcule à partir de ces indices la criticité du mode de défaillance comme le produit des trois indices précédents. En fonction de cette criticité les concepteurs du système peuvent faire des choix d’architecture, définir des mécanismes de protection et de tolérance aux fautes ou encore imaginer des modes de fonctionnement dégradé.
Les indices sont définis suivant des échelles arbitraires qui dépendent du type de système étudié et qui varient généralement de 1 à 10 voire de 1 à 5. Le risque 0 n’existant pas cette valeur est d’ordinaire exclue des notations. Voici un exemple de notation :
Fréquence Gravité Détectabilité
Permanent 10 Pertes
humaines
10 Non détectable 10
Fréquent 5 Pertes
financières
5 Peut être détecté 5
Peu probable 1 Pas grave 1 Toujours détecté 1
Tableau 10 - Grilles d'évaluation pour AMDEC
A partir de ces données on peut calculer pour chaque mode de défaillance un indice de criticité. Par exemple un mode de défaillance fréquent, sans gravité mais non détectable possède un indice de priorité de risque de 5*1*10 = 50.
Une autre capacité des AMDEC est de classer les modes de défaillance en fonction de leur criticité. Il s’agit de fournir un barème selon lequel chaque mode de défaillance peut- être :
97 -Acceptable
-Indésirable -Inacceptable Cette notation
On obtient alors une matrice semblable à la matrice suivante par exemple : Gravité
Peu Grave Pertes financières Pertes
humaines
Permanent Indésirable Inacceptable Inacceptable
Fréquence Fréquent Acceptable Indésirable Inacceptable
Peu fréquent Négligeable Acceptable Indésirable
Peu probable Négligeable Négligeable Acceptable
Tableau 11 - Analyse de criticité
Chaque domaine d’application propose ses propres critères concernant la criticité mais il faut noter qu’aujourd’hui on utilise les AMDEC non seulement pour l’analyse fonctionnelle mais également pour vérifier la viabilité d’un produit, pour identifier les risques liés à un processus, pour identifier les risques liés au non-fonctionnement d’un moyen de production ou encore pour anticiper les risques liés à la rupture d’un flux (de matière ou d’informations).
Nous nous intéressons ici uniquement aux AMDEC fonctionnelles comme décrite précédemment et à la façon de les inclure dans un processus de développement.
5.2.2 Cycle en V
Nous nous focaliserons dans cette partie sur l’utilisation des AMDEC lors du développement de type cycle en V d’un système critique. Ce cycle de développement est un modèle conceptuel de gestion de projet qui permet de limiter au maximum le retour aux étapes précédentes. Il s’impose dès les années 80 comme un standard de l’industrie logicielle. On peut le représenter de la manière suivante :
98
La norme MIL-Std-1629A considère que l’utilisation des AMDEC doit se faire dès les premières phases de conception. Ainsi, chaque étape de la définition du projet doit permettre de préciser l’analyse des modes de défaillance puisque les fonctionnalités et les méthodes d’implémentation se précisent au fur et à mesure.
Notons également que lorsque le système est en phase d’opération et donc de maintenance il faut également mettre à jour les données de l’AMDEC afin d’intégrer les relevés opérationnels. En effet, un système peut rencontrer des défaillances non prévues ce qui peut conduire à un ensemble de procédure de maintenance afin de prendre en compte ces nouveaux modes de défaillance.
5.2.3 Méthodes Agiles
Les méthodes de développement agile sont un ensemble de pratique de gestion de projet qui se veulent plus pragmatiques que les méthodes dites traditionnelles (cycle en v, développement en cascade). L’émergence de ces méthodes date des années 1990, mais l’appellation « Agile » date de 2001 et tire son origine du manifeste Agile [34]. Parmi les méthodes agiles les plus utilisées on citera la méthode SCRUM [35] et la méthode Extrem Programming [36].
Ces méthodes reposent sur quatre valeurs fondamentales : - Individus et interactions plutôt que processus et outils
- Fonctionnalités opérationnelles plutôt que documentation exhaustive - Collaboration avec le client plutôt que contractualisation des relations - Acceptation du changement plutôt que conformité aux plans
De ces valeurs découlent douze principes que nous n’énoncerons pas ici. Ce qui est intéressant de noter c’est que les méthodes agiles sont avant tout des méthodes itératives et
99 incrémentales. Du point de vue de la sûreté de fonctionnement cela signifie que chaque étape produit un système livrable dont il faut faire l’analyse des modes de défaillances.
Cependant, il n’existe pas à l’heure actuelle de formalisation générique d’étude de risques pour le développement agile d’application critique. C’est ce que montrent des études de l’université de Carnegie Mellon telles que [37]. On note que même si les méthodes agiles permettent une qualité de code meilleure que celle des méthodes traditionnelles, la question de la sûreté de fonctionnement n’est pas au centre des préoccupations des concepteurs puisqu’il faut avant tout satisfaire les besoins fonctionnels du client.
Certaines études montrent que l’inclusion d’une AMDEC devrait prendre place à la fin de chaque sprint, c’est-à-dire pour chaque itération dont le produit final est considéré comme livrable [38]. On note également l’émergence de méthodes agiles qui incluent la sûreté de fonctionnement dans le développement. C’est le cas de SafeScrum [39] dont on peut résumer l’utilisation au schéma suivant :
Figure 36 - Cycle de développement de la méthode agile Safescum
Dans cette méthode, chaque sprint produit un ensemble de documentation (safety
product backlog) permettant d’avoir un suivi des propriétés non fonctionnelles du système.
Ce que nous proposerons dans la suite de ce chapitre c’est d’inclure les outils que nous avons développés au cours des chapitres précédents dans des processus de développement.
100