OEPA Traduction de la norme IEEE 730 Nb de Pages : 11 Taille : 250 368 octets Version : 1.0 Référence : oepa_ieee730_20050120 Auteurs : Pierre Gallice Validé par : Antoine Tallon, chef de projet Destinataires : Membres d'orphée, Ch. Chevallier, Ch Fourdrinier Sans objet Remarques
Participants à ce document: Nom Fonction Trigramme Courrier électronique Téléphone Laurent Bocquet LBO rultane@free.fr Nicolas Demange NDG nicolas.demange@gmail.com Thomas Ferry TFE ferry.thomas@free.fr Pierre Gallice PGA efence4242@hotmail.fr 0615777518 Antoine Tallon Secrétaire ATA at@architecture-maironi.fr 0683693097 Historique du document : N de version Date Auteur Description des modifications 1.0 20/01/05 Pierre Gallice Création Glossaire : SIGL #$ #$ () ()$ (## (+ (+ ($$ ($( ( ($ ($ -#$ Abréviation Description Système d Information et Génie Logiciel % & ' & (*% * (*% * & (*% (*,'% (*,'% (*,, & (*,, %*% (*&*% & (*&*% & & (*&*% & -% &
Sommaire : 1VUE D'ENSEMBLE... 4 1.1PORTÉE... 4 3DÉFINITIONS... 4 4PLAN ASSURANCE QUALITÉ... 4 4.1BUT (SECTION 1 DU PAQ)... 5 4.2DOCUMENTS DE RÉFÉRENCE (SECTION 2 DU PAQ)... 5 4.3MANAGEMENT (SECTION 3 DU PAQ)... 6 4.4DOCUMENTATION (SECTION 4 DU PAQ)... 6 4.5STANDARDS, PRATIQUES, CONVENTIONS ET MÉTRIQUES (SECTION 5 DU PAQ)... 6 4.6RÉVISIONS ET AUDITS (SECTION 6 DU PAQ)... 7 4.7TEST (SECTION 7 DU PAQ)... 10 4.8RAPPORT D'ERREURS ET ACTION CORRECTIVE (SECTION 8 DU PAQ)... 10 4.9OUTILS, TECHNIQUES, ET MÉTHODOLOGIES (SECTION 9 DU PAQ)... 10 4.10CONTRÔLE DU CODE (SECTION 10 DU PAQ)... 10 4.11CONTRÔLE DES MOYENS DE COMMUNICQTION (SECTION 11 DU PAQ)... 11 4.12CONTRÔLES DES FOURNISSEURS (SECTION 12 DU PAQ)... 11 4.13COLLECTION D'ENREGISTREMENTS, MAINETANCE ET RÉTENTION (SECTION 13 DU PAQ)... 11 4.14FORMATION (SECTION 14 DU PAQ)... 11 4.15MANAGEMENT DU RISQUE (SECTION 15 DU PAQ)... 11.
Introduction Ce standard décrit la préparation et le contenu du Plan Assurance qualité d un logiciel et apporte un standard permettant de préparer les plans et de les évaluer. Il est directement orienté vers le développement et la maintenance de logiciel critique ; c est à dire où toute défaillance pourrait impacter sur la sureté ou causer de lourdes pertes financières. Dans cette norme, le firmware est considéré être du software et doit donc être traité comme tel. Il y a trois groupes qui sont concernés par ce standard : l utilisateur, le développeur et le public. 1 Vue d ensemble Le but de ce standard est d apporter les besoins minimum acceptables pour la préparation et le contenu du PAQ. En considérant l adoption de ce standard, les utilisateurs doivent prendre garde au fait que l application spécifique de ce standard peut déjà avoir été couvert par un ou plusieurs documents IEEE reliés à la qualité, aux définitions Le but de ce standard n est en aucun cas de réaliser une mise à jour des normes existantes guidant certaines industries ou applications spécifiques. Ce standard s applique au développement et à la maintenance de logiciels critiques. En ce qui concerne les logiciels non critiques, ou encore pour les logiciels déjà développés, une sous-partie de ce standard peut être appliquée. L existence de ce standard ne doit pas être comprise comme une interdiction d ajout de contenu au PAQ. Une évaluation doit être réalisée pour le logiciel spécifique afin de s assurer de son adéquation avec la zone de couverture du standard. Si une organisation produit plusieurs parties logicielles, l applicabilité du standard devra être spécifiée pour chacune de ces parties. 3 Définitions Branch metric : Le résultat de la division entre le nombre total de modules pour lesquels chaque branche a été exécutée au moins une fois et le nombre total de modules. Critical software : Logiciels pour lesquels toute défaillance causera de lourdes pertes financières et sociales. Decision point metric : Le résultat de la division entre le nombre total de modules pour lesquels chaque point de décision a eu 1) toutes les validations, et 2) au moins une condition invalide, correctement menée par le nombre total de modules. Domain metric : Le résultat de la division du nombre total de modules pour lesquels un échantillon valide et un invalide de chaque classe d items d entrée ont été correctement traités par le nombre total de modules. Error message metric : Le résultat de la division entre le nombre total de messages d erreurs qui ont été démontrés de manière formelle par le nombre total de messages d erreurs. /
Quality assurance : Un modèle planifié et générique de toutes les actions nécessaires pour obtenir les preuves suffisantes de l adéquation d un produit avec les besoins établis. Requirements demonstration metric : Le résultat de la division du nombre total de besoins identifiés séparément dans le SRS qui ont été démontrés avec succès par le nombre total de besoins identifiés séparément dans le SRS. 4 Plan d assurance qualité du logiciel Le PAQ doit inclure les sections listées ci-dessous pour être en accord avec le standard. Les sections pourraient être traitées dans l ordre donné. Si ce n est pas le cas, alors une table doit être produite à la fin du PAQ pour produire les références croisées entre le standard et son adaptation. S il n y a pas d information pertinente dans une section, la motion suivante doit apparaître en dessous de l en tête de la section : «cette section n est pas applicable au plan», avec les raisons appropriées de son exclusion. a) but b) documents de référence c) Management d) Documentation e) Normes, conventions et mesures f) Révisions et audits g) Test h) Rapport des problèmes et action corrective i) Outils, techniques et méthodes j) Contrôle du code k) Contrôles des moyens de communication l) Contrôles des fournisseurs m) Rassemblement des enregistrements, maintenance et conservation n) Entraînement o) Management du risque D autres sections peuvent êtres ajoutées. Une partie de ce contenu peut apparaître dans d autres documents. Si c est le cas, les références à ces documents doivent être ajoutées dans le corps du PAQ. Le PAQ doit être approuvé par le chef opératoire de chaque phase de l organisation ou par un de ses représentants. 4.1 But (Section 1 du PAQ) Cette section doit delimiter le but et la portée spécifique du PAQ adapté au logiciel. Il doit lister les noms des parties du logiciel couverts par le PAQ et l intention d utilisation du logiciel. Il doit determiner la portion du cycle de vie du logiciel couvert par le PAQ pour chaque partie spécifiée du logiciel. 4.2 Documents de référence (Section 2 du PAQ) Cette section propose une liste exhaustive des documents référencés partout ailleurs dans le PAQ du logiciel. "
4.3 Management (Section 3 du PAQ) Cette section décrit l organisation, les tâches et les responsabilités. 4.3.1 Organisation Ce paragraphe doit décrire la structure organisationnelle qui influence et contrôle la qualité des logiciels. Cela doit inclure une description de chaque élément majeur de l organisation avec les responsabilités sous-jacentes. La dépendance comme l indépendance de l organisation de ces éléments relatids au PAQ et ceux relatifs au développement vont être clairement décrits et détaillés. 4.3.2 Tâches Ce paragraphe doit décrire a) La portion du cycle de vie du logiciel couverte par le PAQ b) Les tâches à réaliser avec une attention spéciale sur les activités d assurance qualité c) Les relations entre les tâches et les vérifications majeures planifiées 4.3.3 Responsabilités Ce paragraphe doit identifier les elements d organisation spécifique à chaque tâche. 4.4 Documentation (Section 4 du PAQ) 4.4.1 But Cette section doit effectuer les fonctions suivantes : a) Identifier la documentation guidant le développement, la vérification et la validation, l utilisation, et la maintenance du logiciel. b) Faire état de la façon dont l adéquation des documents va être vérifiée. Cela doit inclure les critères d audit permettant de vérifier cette adéquation. 4.4.2 Documents minimum requis Pour assurer que l implémentation du logiciel satisfait les besoins, les documents suivants sont nécessaires : 4.4.2.1 Spécifications des besoins du logiciel (SRS) Le SRS doit décrire de manière claire et précise les besoins essentiels (fonctions, performances, design, contraintes, et attributs) du logiciel et de ses interfaces. Chaque besoin doit être décrit de façon à ce qu il puisse y avoir un moyen de le vérifier et de le valider par une méthode choisie (inspection, analyse, démonstration, ou test). 0
4.4.2.2 Description du design du logiciel (SDD) Le SDD doit décrire comment le logiciel va être structuré afin de répondre aux besoins du SRS. Le SDD doit décrire les composants et sous-composants du design, en incluant les bases de données ainsi que les interfaces internes. Le SDD doit d abord être ébauché sous la forme d une version préliminaire pour ensuite être détaillé dans la version finale. 4.4.2.3 Plan de verification et de développement du logiciel (SVVP) Le SVVP doit identifier et décrire les méthodes à utiliser pour : a) vérifier que 1) Les besoins du SRS ont été approuvés par les autorités compétentes 2) Les besoins du SRS sont implémentés suivant le design du SDD 3) Le design exprimé dans le SDD est implémentés à travers le code b) valider le code, une fois exécuté, correspond aux attentes exprimées dans le SRS. 4.4.2.4 Rapport de verification et validation du logiciel (SVVR) Le SVVR doit décrire les résultats de l exécution du SVVP. 4.4.2.5 Documentation utilisateur La documentation utilisateur doit spécifier et décrire les entrées attendues et les entrées de contrôle, les séquences d entrée, les options, les limitations du programme, et les autres activités nécessaires à la bonne exécution du logiciel. Tous les messages d erreur doivent être identifiés et leur action corrective exprimée 4.4.2.6 Plan de management du logiciel (SCMP) Le SCMP doit documenter les méthodes à utiliser pour identifier toutes les parties du logiciel, contrôler et implémenter des changements, et enregistrer et rapporter des changements de status d implémentation. 4.4.3 Autres La documentation restante pourrait inclure : a) Le plan de développement du logiciel b) Le manuel des standards et procédures c) Le plan de management du projet logiciel d) Le manuel de maintenance du logiciel. 1
4.5 Standards, pratiques, conventions et mesures (Section 5 du PAQ) 4.5.1 Mesures Cette section doit : a) Identifier les standards, les pratiques, et les mesures à appliquer b) Faire état de la façon de contrôler et vérifier l adéquation avec ces items. 4.5.2 Contenu Les sujets couverts doivent inclure les techniques basiques, le design, les activités de programmation mises en jeu, les variables et le nom des modules, la programmation, l inspection et les tests. Au minimum, les informations suivantes doivent être produites : a) Standards de documentation b) Standards de structures logiques c) Standards de code d) Standards de commentaires e) Standards de test et de pratiques f) Les mesures et l assurance qualité du logiciel choisi : a. Branch metric b. Decision point metric c. Domain metric d. Error message metric e. Requirements demonstration metric 4.6 Révisions et audits (Section 6 du PAQ) 4.6.1 But Cette section doit a) Définir les révisions techniques et managériales à mener b) Faire état de comment les révisions et audit doivent être menés c) Faire état des prochaines actions à mener et comment elles vont être implémentées et vérifiées. 4.6.2 Besoins minimums requis Au minimum, les révisions et audits suivants doivent être conduits. 4.6.2.1 Révisions des besoins du logiciel (SRR) Le SRR est utilisé pour assurer l adéquation avec les besoins présents dans le SRS. 2
4.6.2.2 Révision du design préliminaire (PDR) Le PDR est utilisé pour évaluer l adéquation technique du design préliminaire du logiciel comme détaillé dans le SPP préliminaire. 4.6.2.3 Révision du design critique (CDR) Le CDR est utilisé pour déterminer l acceptabilité du design détaillé du logiciel tel qu il est dans le SPP satisfaisant au besoin du SRS. 4.6.2.4 Révision du plan de verification et de valifation du logiciel (SVVPR) Le SVVPR est utilisé pour évaluer l adéquation et la complétude des méthodes de vérification et de validation définies dans le SVVP. 4.6.2.5 Audit fonctionnel Cette audit a lieu avant la livraison du logiciel pour vérifier que tous les points spécifiés dans le SRS ont été respectés. 4.6.2.6 Audit physique Cet audit est présent pour vérifier que le logiciel et sa documentation sont logiques et prêts à être livrés. 4.6.2.7 Audits internes aux processus Les audits internes aux processus d un échantillon du design sont présents pour vérifier la logique de celui-ci, ce qui inclut : a) La documentation du code face à celle du design. b) Les spécifications de l interface (matérielle et logicielle). c) Les implémentations du design face aux besoins fonctionnels d) Les besoins fonctionnels face aux descriptions des tests. 4.6.2.8 Révisions managériales Les révisions managériales sont tenus périodiquement pour évaluer l exécution de toutes les actions et articles identifiés dans le PAQ. Ces révisions doivent être tenus par un élément de l organisation indépendant de l unité qui fait l objet de la révision ou bien pars un tiers parti qualifié. Cette révision peut être la source de changements additionnels dans le PAQ lui-même. 4.6.2.9 Révision du plan de management des configurations du logiciel (SCMPR) 4()$* 5!&5!, %!! % *!* () 3
4.6.2.10 Révision post-mortem & 6*!&%&!!% % % %! 4.6.2.11 Autres 4!& & %& % 7-#$8 &!&5!, 7%!9%!9:%9;!8 % 4.7 Test (Section 7 du PAQ) Cette section doit identifier tous les tests non inclus dans le SVVP pour le logiciel couvert paer le PAQ et doit faire états des methods à utiliser. 4.8 Rapport d erreurs et action corrective (Section 8 du PAQ) Cette section doit a) Décrire les pratiques et procedures à suivre pour les rapports, le traçage, et la resolution de problèmes identifiés à la fois dans les parties du logiciel et dans le développement et les processus de maintenances de celui-ci. b) Faire état des responsabilités spécifiques organisationnelles avec leur implementation. 4.9 Outils, techniques, et méthodologies (Section 9 du PAQ) Cette section doit identifier les outils spéciaux du logiciel, les techniques, et methods qui supportent l assurance qualité du logiciel, fait état de leurs buts, et décrit leur utilization. 4.10 Outils, techniques, et méthodologies (Section 10 du PAQ) Cette section doit définir les methods et moyens mis en oeuvre pour maintenir, conserver, sécuriser, et documenter les versions contrôlées du logiciel identifié pendant toutes les phases du cycle de vie de ce logiciel. Cela peut être implémenté en conjonction avec une bibliothèque de programmation. Cela peut être apporté en tant que partied u SCMP. Si c est le cas, une référence appropriée doit être réalisée.
4.11 Contrôle des moyens de communication (Section 11 du PAQ) Cette section doit faire état des méthodes et moyens à utiliser pour a) Identifier les media pour chaque produit et la documentation nécessaire pour sauvegarder les media, incluant la copie et le processus de restauration b) Protéger les programmes sur support physique d accès interdits ou de dommages accidentels ou de dégradation durant toutes les phases du cycle de vie du logiciel Cela peut être apporté comme une partied u SCMP. Si c est le cas, une reference appropriée doit être faite. 4.12 Contrôle des fournisseurs (Section 12 du PAQ) Cette section doit faire état des provisions pour assurer que le logiciel apporté par les fournisseurs correspond aux besoins établis. Le fournisseur peut avoir à preparer un PAQ et à developer son logiciel en accord avec ce standard. 4.13 Collection d enregistrements, maintenance, et rétention (Section 13 du PAQ) Cette section doit identifier la documentation d assurance qualité à retenir, doit faire état des méthodes et moyens à mettre en jeu pour rassembler, sauvegarder et maintenir cette documentation; et doit préciser la durée de retention. 4.14 Collection d enregistrements, maintenance, et rétention (Section 14 du PAQ) Cette section doit identifier les activités de formations pour satisfaires les besoins du PAQ. 4.15 Management du risque (Section 15 du PAQ) Cette section doit spécifier les méthodes et procedures employees pour identifier, évaluer, suivre, et contrôler les aires de risque augmentant sur la portion de cycle de vie du logiciel couvert par le PAQ.