Processus de Developpement Logiciel Et Amdec

Télécharger au format pdf ou txt
Télécharger au format pdf ou txt
Vous êtes sur la page 1sur 6

Processus de développement logiciel

et AMDEC
Stéphane REY – Mars 2006

Le processus de développement logiciel décrit • la méthode retenue pour assurer la tracabilité


les étapes nécessaires pour développer des fonctions des évolutions.
logicielles en garantissant maintenabilité et traçabilité.
Afin de conserver un niveau de documentation L’évaluation des solutions s’appuie sur une
minimum et utilisable, ce plan documentaire définit les étude de faisabilité tenant compte de l’expérience
documents qui doivent être remplis par les intervenants acquise et de la comparaison entre plusieurs solutions.
d’un projet. Cette évaluation est soumise à l’approbation du
responsable du développement logiciel qui pourra
Ce processus est inspiré des normes ISO/IEC estimer les risques et conséquences. Aucun
15288 et ISO/IEC 12207 dont le champ d’application est développement ne peut démarrer sans que les deux
réduit au cycle de développement des logiciels. parties soient d’accord et aient co-signé le cahier des
charges. La liste exhaustive des critères d’acceptation
1 PROCESSUS DE DEVELOPPEMENT est établie.
Le responsable de projet détermine le plan de
Le processus de développement décrit dans ces contrôle à toutes les phases de développement et de
pages s’appuie sur un modèle de cycle en V. validation, planifie les tâches ainsi que les revues de
projet.
Après la revue, toute évolution du cahier des
charges doit être tracée et soumise à analyse pour
Evaluation Validation évaluer son acceptation.
Cycle de Installation &
mise en développement
œuvre acceptation
Spécification
Spécification Tests fonctionnels
Qualification du
système Avant de commencer la conception, Il faut
Conception Tests d’intégration rédiger une spécification fonctionnelle. Cette
Qualification du logiciel spécification est une traduction technique du cahier des
charges. Elle doit comporter toutes les informations
Ecriture du code Tests unitaires permettant à n’importe quel intervenant du projet de
(essais du logiciel) comprendre les tenants et aboutissants de la fonction, et
elle doit être suffisamment détaillée pour permettre au
développeur de concevoir le logiciel sans information
Figure 1 : Cycle de développement complémentaire.
Ces spécifications traitent du fonctionnel, de
A chaque phase correspond un ou plusieurs l’interface, du diagnostique, des performances et des
documents. Le chapitre ‘Plan documentaire’ indique les modes dégradés.
documents qu’il convient de réaliser. Cependant, des
documents de travail intermédiaires peuvent être édités Conception
et ajoutés au dossier d’étude. Une revue a lieu à la fin
de chaque phase de conception. La spécification de conception décrit la manière
dont est architecturé le logiciel, la répartition des
Evaluation – Mise en oeuvre modules, l’enchaînement et l’échange d’informations
entre les modules. Cette spécification est indispensable
Il s’agît d’étudier le cahier des charges du client dans le cas de fonctions partagées ou complexes
ou de l’aider à l’élaborer afin d’analyser les exigences comme les bus de communication, la gestion des
du système. Ces exigences sont relatives à la sûreté, entrées/sorties, les séquenceurs de tâches,... Elle peut
sécurité, ergonomie, interface, diagnostique, être intégrée dans la spécification fonctionnelle s’il s’agît
exploitation, maintenance ainsi que les contraintes de d’une fonction autonome et simple.
développement (langage ou plate-forme utilisée, …).
Cette phase est très importante puisqu’elle va Ecriture du code
permettre de contractualiser l’expression du besoin.
Le planning sera établi, les missions des Cette étape permet à partir des spécifications de
intervenants seront définies et les critères d’acceptation conception de traduire les modules en langage source.
seront précisés : Le codage doit être réalisé en suivant les règles en
• les critères d’acceptation du logiciel en phase vigueur du langage sélectionné. Ces règles sont lorsque
d’exploitation, elles sont applicables indiquées dans des documents de
• les critères d’acceptation du logiciel en phase règles de codage.
de maintenance,
• les niveaux de testabilité pour chaque module et
pour l’intégration,
Tests unitaires (modules logiciels)
Dans les pages de garde suivantes il doit apparaître :
Les tests unitaires sont effectués avec des - un tableau récapitulatif des révisions
données d’entrée simulées. Cela permet de vérifier - un sommaire
qu’une fonction ou un module de code et ses interfaces
fonctionne tel que spécifié. Le plan de test est Documents applicables
clairement écrit dans le rapport de test. Si une anomalie
est détectée, c’est au développeur de décider si elle doit Phase de
être consignée ou non. Document de sortie Responsable
développement
Cahier des
Tests d’intégration Evaluation Client
Charges
Spécifications
L’objet de ces tests est de vérifier que tous les Spécification Resp. logiciel
fonctionnelles
modules fonctionnent une fois intégrés au sein du même Spécifications de
logiciel grâce à un plan d’intégration. Les données Conception Développeur
conception
d’entrée sont simulées. Le plan de test est clairement Fichiers sources
écrit dans le rapport de test. Ecriture du code Développeur
Code généré
Si une anomalie est détectée, il faut relancer les Fiche de tests
étapes correspondantes. C’est au développeur de Tests unitaires Développeur
unitaires
décider si l’anomalie doit être consignée dans une fiche
Fiche de tests
d’anomalie ou non. Ces tests devraient être déroulés de Testeur
Tests d’intégration
manière automatique.
d’intégration Fiches d’anomalie
Resp. Logiciel
Fiche de livraison
Tests fonctionnels
Fiche de tests
Tests
fonctionnels Testeur
Les tests fonctionnels sont effectués sur la fonctionnels
Fiches d’anomalie
plate-forme matérielle définitive avec des données
Rapport de
d’entrée réelles.
validation
Le but est de vérifier que l’intégralité du logiciel Validation Client
Questionnaire
fonctionne tel que spécifié sur le matériel ciblé.
interactif client
A l’issue de ces tests une livraison d’une version du
logiciel peut avoir lieu.
A partir de cette étape, toute anomalie ou Cahier des Charges : Il est habituellement sous la
demande de modification doit être tracée, toute responsabilité du client mais le responsable du
modification apportée dans le code doit relancer les développement logiciel peut apporter son soutien lors de
étapes correspondantes et l’indice de révision doit être son élaboration par son expertise voire le rédiger
incrémenté. intégralement dans certains cas. Il décrit le besoin et les
exigences du système. Il est indispensable d’avoir
Validation également toutes les annexes relatives qui permettent
d’expliquer ou détailler un aspect particulier du cahier
La validation est menée in-situ avec des clients des charges.
pilotes ciblés et choisis par le responsable de projet. Elle
vise à vérifier le respect des spécifications et du plan de Spécification fonctionnelle : Sous la responsabilité du
test. Si des anomalies sont détectées elle doivent être responsable logiciel, elle est la traduction technique du
tracées et une analyse doit démontrer les corrections à cahier des charges. Dans le cas de systèmes simples,
apporter. Les étapes correspondantes sont relancées. une seule spécification peut être rédigée. Dans le cas de
S’il s’agît d’une erreur majeure, c’est à dire un défaut de fonctions complexes ou multi-projets, il est préférable de
caractéristique ou de qualité, une nouvelle version de rédiger une spécification par fonction.
logicielle doit être livrée. Elle doit comporter un diagramme clair montrant
A l’issue de cette phase, tous les critères les entrées et sorties de la fonction, une description de
d’acceptation établis en phase d’évaluation doivent être ces entrées et sorties, une explication claire des
validés. traitements effectués et le détail des modes dégradés.

2 PLAN DOCUMENTAIRE Spécification de conception : Elle est rédigée par le


développeur. Elle décrit la manière dont est architecturé
le logiciel, la répartition des modules, l’enchaînement et
Chaque document doit être correctement renseigné l’échange d’informations entre les modules. Elle peut
pour permettre son utilisation future. également détailler le fonctionnement d’une partie du
Les informations suivantes doivent être reportées en code plus difficile à appréhender, ou expliquer une
première page : astuce utilisée qui n’est pas évidente. Dans le cas de
- le nom du projet fonctions simples, ce document peut être inclus dans la
- le numéro du projet spécification fonctionnelle.
- le titre du document
- le type de document Fichiers sources : l’écriture du logiciel est soumise aux
- la référence du document règles de codage en vigueur. Il doit permettre une
- l’indice de révision lecture aisée : code aéré, commentaires, structure….
- le nom de l’auteur
- la dernière date de mise à jour
Code généré : Le code généré est un fichier binaire 3 APR ET AMDEC
(intel, S1S9) ou exécutable issu de la compilation. Il est
le résultat du développement du logiciel. Un code est Analyse Préliminaire de Risques
caractérisé par son checksum ou son indice de version Analyse des Modes de DEfaillance et de Criticité
qu’il convient de tracer pour chaque version dans une
fiche de livraison. L'AMDEC est un moyen de vérifier que tous le
modes de défaillances ont bien étés pris en compte dans
Fiche de tests : On y trouve toutes les indications de la la conception. Cette étape est essentielle dans la
version du logiciel testé (Nom, version, taille, date, conception d'un produit.
checksum ou indice de version), le nom du testeur ainsi L'Analyse Préliminaire de Risque est la première
que le plan de test avec les résultats. Selon le degré évaluation réalisée avant de retoucher la conception du
d’importance des modifications apportées depuis la produit.
dernière révision testée, le développeur peut soumettre Dans un premier temps, il est supposé que la
un plan de test réduit. liste de tous les modes de défaillance possibles est
Dans le cas de systèmes simples, les fiches de établie.
tests unitaires, d’intégration ou fonctionnels peuvent être Un mode de défaillance est caractérisé par trois
réalisées sur le même document. points :
1. Gravité (Severity)
Fiche d’anomalie : Elle permet de consigner toutes les 2. Fréquence
anomalies détectées. Dès qu’une anomalie dénote un 3. Détection
dysfonctionnement ou un écart par rapport à la
spécification on parle d’erreur majeure conduisant à une Chaque point est évalué et affecté à un coefficient :
nouvelle livraison de logiciel et un nouveau test. Dans le
cas d’erreurs mineures, c’est au développeur de décider
si une nouvelle version du logiciel doit être livrée. Description de la Gravité (S) Niveau
L’industrialisation de machines ou prototypes n’entre Effet conséquent. Réduction du niveau de
1
pas obligatoirement dans ce cas. La fiche d’anomalie performance. Client insatisfait
fait parti de la fiche de tests. Effet très important. Défaut avec perte de la
fonction principale. Forte insatisfaction du 5
Fiche de livraison : La fiche de livraison permet de tracer client
les versions de logiciel. Elle comporte toutes les
informations pour identifier la version (nom, version, Effet aléatoire sans signe avant coureur.
date, checksum, …), les documents applicables ainsi Défaut de sécurité ou non conformité avec 10
qu’un descriptif des modifications apportées depuis la les normes.
dernière révision.
Description de la Fréquence (F) Niveau
Rapport de validation : Rédigé par ou avec le client, il
permet de tracer la recette du produit par le client, de Très faible. Très improbable défaillance 1
noter ses commentaires et éventuellement ses Modérée. Défaillances éventuelles 5
demandes de modification.
Très haute. Défaillances presque inévitables 10
Paramétrage / gestion deconfiguration
Description de la Détection (D) Niveau
Dans le cas de systèmes paramétrables à la fois
en production et par le client en production/utilisation, Les contrôles envisagés détecteront très
1
l’accès aux paramètres doit être sécurisé. Etablir des certainement la défaillance.
niveaux d’accès aux paramètres permet de faciliter la Probabilité moyenne de détecter la
5
conception des outils de diagnostique ou de production défaillance
et d’améliorer la sécurité. Les contrôles envisagés ne permettent pas
On distingue trois catégories d’accès différenciées 10
de détecter la défaillance.
par le type d’utilisateur :

- Application : Les paramètres sont déterminés Ensuite, un indice de risque préliminaire (PRI =
par le service R&D et permettent de caractériser Preliminary Risk Index) est déduit par la multiplication
le fonctionnement du système. des trois indices précédents :
- Client : Les paramètres sont déterminés par le PRI = S x F x D
client et lui permettent de gérer différentes
configurations et/ou d’enregistrer des numéros Maintenant, il ne reste qu'à définir le niveau
de référence (part numbers) par exemple. acceptable en fonction de l'application et de lister tous
- Utilisateur : Les paramètres permettent à les modes de défaillance dans un document. Un bon
chaque utilisateur de configurer son système. compromis qui évite toujours un risque sécuritaire est
100. Si l'indice PRI est égal ou supérieur à ce seuil, une
Dans le cas de systèmes paramétrables, il faut solution doit être envisagée pour réduire cet indice.
fournir une spécification de paramétrage au client qui
explicite et caractérise ces paramètres (adresse, nom,
taille, bit gain, offset, unité, description, niveau d’accès,
…)
Exemple :

Un module électronique possède un bouton


d'arrêt d'urgence. Ce module pilote en sortie un relais
qui arrête une machine. Nous analysons cette sortie du
module :

pin
Description Type Mode de défaillance Effet système et client Solution S F D PRI
number

Sortie relais Circuit ouvert Pas d'arrêt d'urgence


coupure numérique 5 Court-circuit à Vbatt Machine toujours arrêtée 10 5 10 500
d'urgence Court-circuit à GND Pas d'arrêt d'urgence

Dans cet exemple, la gravité de la défaillance


est maximale. Si cela ne fonctionne pas il y a un
problème de sécurité. Gravité (S) = 10. Comme la sortie
est câblée sur un relais et que les câbles ne sont pas
parfaits, la Fréquence = 5. Le concepteur n'a pas utilisé
de détection de défaillance par recopie de la sortie.
Donc Détection = 10. L'indice PRI= 500 ce qui est
inacceptable.
Le concepteur devra ajouter une détection de
court-circuit ou de circuit ouvert. La détection se fait à
100% donc le risque est minimum et la nouvelle côte est
de 1. L'AMDEC donne :
pin
Description Type Mode de défaillance Effet système et client Solution S F D PRI
number

Sortie relais Circuit ouvert Pas d'arrêt d'urgence


Ajout d'un circuit de
coupure numérique 5 Court-circuit à Vbatt Machine toujours arrêtée 10 5 1 50
lecture de la sortie
d'urgence Court-circuit à GND Pas d'arrêt d'urgence

Le nouvel indice PRI vaut 50 ce qui devient


acceptable. Cela signifie que la fonction à une haute Conclusion
criticité et que la gravité ne peut pas être réduite. La
fréquence est moyenne due à la technologie de Les processus sont indispensables au bon
connexion employée, mais nous sommes sûrs de déroulement des projets dans l’industrie. Ils permettent
détecter la défaillance et le logiciel pourra entrer dans d’assurer que les concepteurs se sont posées quelques
un mode approprié (il arrête la machine !) questions et auront prévus le maximum de cas de
figures possibles.
L’objectif est de faire gagner du temps, même si
Exemple d’AMDEC d’un premier abord cela requiert d’écrire un peu de
documentation ce qui semble rébarbatif à la majorité des
L’exemple des pages suivantes montre un cas techniciens et ingénieurs. Au bout du compte, on s’y
avec quelques fonctions choisies. L’analyse Préliminaire retrouve car on limite le nombre d’itérations dans un
de Risque fait ressortir un niveau de criticité non développement en essayant de faire correctement du
acceptable (>100) et l’AMDEC apporte des solutions premier coup.
pour réduire ce risque. Ce que j’ai décrit dans ces pages peut tout aussi
bien s’appliquer à l’amateur sur le principe, même s’il
s’attarde moins sur la partie documentaire. L’essentiel
est d’opter pour une méthode de développement fiable
et efficace.
Il existe une multitude de processus différents.
Celui ci mérite d’être amélioré bien entendu, mais il peut
servir de base de réflexion et donner des idées à
certains.

Stéphane REY – [email protected]


Analyse Préliminaire de Risque

Function 1.1. : System


Criticité 1

Description Type # pin Mode de défaillance Effet système et client Solution S F D PRI
Erreur logicielle inconnue (Bug ?) Etat imprédictible. Risque sécuritaire.
Déroulement du logiciel Logiciel - entraînant un dysfonctionnement Perte de la fonction principale 10 5 10 500
de tout ou partie du logiciel
Défaut d’alimentation Risque de reset du CPU. Altération de la
Alimentation matériel - (microcoupures, chutes, …) fonction principale. Risque de pertes de 5 5 10 250
données.
Altération du code en mémoire Etat imprédictible. Risque sécuritaire.
Déroulement du logiciel matériel - flash (CEM) Perte de la fonction principale 10 1 10 100

Function 2.1. : Acquisition analogique/numérique


Criticité 1

Description Type # pin Mode de défaillance Effet système et client Solution S F D PRI
Circuit ouvert Accélération à 100%. Risque sécuritaire.
Acquisition pédale matériel PTA1 Court-circuit à Vcc Accélération à 100%. Risque sécuritaire. 10 5 10 500
d’accélérateur Court-circuit à GND Accélération à 0%. Panne immobilisante
Circuit ouvert Baisse performances moteur
Acquisition capteur Matériel PTA2 Court-circuit à Vcc Baisse performances moteur 5 5 10 250
température Court-circuit à GND Baisse performances moteur
Valeur hors limite (-34.2 ;+34.2) Mauvais calcul compensation, risque de
Calcul coefficient Logiciel - pollution. Non respect des normes 10 1 10 100

Function 3.1. : Acquisition numérique


Criticité 1

Description Type # pin Mode de défaillance Effet système et client Solution S F D PRI
Circuit ouvert Lampe ne s’éclaire pas
Contacteur éclairage boite matériel PTB1 Court-circuit à Vcc Lampe toujours éclairée. Risque batterie 5 5 10 250
à gants Court-circuit à GND Lampe ne s’éclaire pas
Circuit ouvert Coupure moteur. Risque sécuritaire
Info cle de démarrage Matériel PTB2 Court-circuit à Vcc Pas de coupure moteur 10 5 10 500
activée Court-circuit à GND Coupure moteur. Risque sécuritaire
Analyse des Modes de défaillance et de Criticité

Function 1.1. : System


Criticité 1

Description Type # pin Mode de défaillance Effet système et client Solution S F D PRI
Erreur logicielle inconnue (Bug ?) Etat imprédictible. Risque sécuritaire. Activation du Watchdog hardware
Déroulement du logiciel Logiciel - entraînant un dysfonctionnement Perte de la fonction principale integer au CPU 10 5 1 50
de tout ou partie du logiciel
Défaut d’alimentation Risque de reset du CPU. Altération de la Activation du module de surveillance
Alimentation matériel - (microcoupures, chutes, …) fonction principale. Risque de pertes de tension. Génère en reset en cas de 5 5 1 25
données. problème
Altération du code en mémoire Etat imprédictible. Risque sécuritaire. Enregistrement du checksum lors de
Déroulement du logiciel matériel - flash (CEM) Perte de la fonction principale la programmation et vérification à 10 1 1 10
chaque intialisation du CPU

Function 2.1. : Acquisition analogique/numérique


Criticité 1

Description Type # pin Mode de défaillance Effet système et client Solution S F D PRI
Circuit ouvert Accélération à 100%. Risque sécuritaire. Relecture sortie et comparaison avec
Acquisition pédale matériel PTA1 Court-circuit à Vcc Accélération à 100%. Risque sécuritaire. la commande (détection seuils au 10 5 1 50
d’accélérateur Court-circuit à GND Accélération à 0%. Panne immobilisante dela desquels on considère un court-
circuit)
Circuit ouvert Baisse performances moteur Relecture sortie et comparaison avec
Acquisition capteur Matériel PTA2 Court-circuit à Vcc Baisse performances moteur la commande (détection seuils au 5 5 1 25
température Court-circuit à GND Baisse performances moteur dela desquels on considère un court-
circuit)
Valeur hors limite (-34.2 ;+34.2) Mauvais calcul compensation, risque de Gérer le débordement de la valeur.
Calcul coefficient Logiciel - pollution. Non respect des normes Retour à une valeur par défaut en cas 10 1 1 10
de débordement

Function 3.1. : Acquisition numérique


Criticité 1

Description Type # pin Mode de défaillance Effet système et client Solution S F D PRI
Circuit ouvert Lampe ne s’éclaire pas Relecture sortie et comparaison avec
Contacteur éclairage boite matériel PTB1 Court-circuit à Vcc Lampe toujours éclairée. Risque batterie la commande 5 5 1 25
à gants Court-circuit à GND Lampe ne s’éclaire pas
Circuit ouvert Coupure moteur. Risque sécuritaire Relecture sortie et comparaison avec
Info cle de démarrage Matériel PTB2 Court-circuit à Vcc Pas de coupure moteur la commande 10 5 1 50
activée Court-circuit à GND Coupure moteur. Risque sécuritaire

Vous aimerez peut-être aussi