Présentation

Article

1 - PROCESSUS DE BASE

2 - PROCESSUS DE SUPPORT

  • 2.1 - Processus de documentation
  • 2.2 - Processus de gestion de configuration
  • 2.3 - Processus d’assurance de la qualité
  • 2.4 - Processus de vérification
  • 2.5 - Processus de validation
  • 2.6 - Processus de revues
  • 2.7 - Processus d’audits
  • 2.8 - Processus de résolution de problème

3 - PROCESSUS ORGANISATIONNELS

4 - CONCLUSION

5 - ANNEXE A. LES TESTS DU LOGICIEL

  • 5.1 - Étapes de test
  • 5.2 - Familles de tests
  • 5.3 - Techniques de tests

6 - ANNEXE B. LES NORMES, LES STANDARDS, LES RÉFÉRENTIELS

  • 6.1 - DO-178B/ED-12B
  • 6.2 - DoD-STD-2167

7 - ANNEXE C. LA QUALIMÉTRIE

Article de référence | Réf : R8080 v1

Annexe B. Les normes, les standards, les référentiels
Qualité des logiciels industriels

Auteur(s) : Élisabeth WALTI

Date de publication : 10 juin 1998

Pour explorer cet article
Télécharger l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !

Sommaire

Présentation

Version en anglais En anglais

Auteur(s)

  • Élisabeth WALTI : Consultant en qualité des logiciels - Responsable de secteur à la Société Qualience

Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.

Lire l’article

INTRODUCTION

Parler de qualité est le plus souvent trop abstrait. Il semble plus facile d’aborder la question de la qualité par la non-qualité. Chacun a pu voir dans la vie de tous les jours ou dans le milieu professionnel, les effets de la non-qualité. Les conséquences sont aussi bien au niveau des coûts, des délais que des personnes et des biens.

Comme exemple grand public, le logiciel Socrate de la SNCF, dont la mise en œuvre a été laborieuse, a beaucoup compliqué la vie des utilisateurs et des usagers, et a profondément nui à l’image de l’entreprise. L’exemple du premier tir d’Ariane 5 vient également à l’esprit. Ces deux faits sont connus de tous, en raison de leur importante couverture médiatique, mais de nombreux autres exemples se rencontrent tous les jours et par tout un chacun.

Un état d’esprit encore assez répandu dans le domaine du logiciel laisse entendre que la qualité coûte trop cher, retarde le développement, ... et la décision de réaliser en premier le produit (exécutable) et ensuite le reste (documentation, tests, etc.) en fonction du temps restant est encore très souvent d’actualité.

En fait, la qualité n’est pas une entité précise et délimitée à un instant du développement mais doit faire partie intégrante de la manière d’être, et se faire tout au long du cycle de vie d’un produit.

Il semble intéressant de préciser que des secteurs industriels, développant des logiciels sécuritaires comme l’aéronautique par exemple, ont depuis longtemps mis en place des méthodes répondant à des besoins de rigueur et donc de qualité. L’apparition de standards a permis de quantifier les besoins et les attentes de chacun et servent de référence au moment des phases d’acceptation.

Depuis quelques années, le concept de qualité totale est apparu sur le marché. Les entreprises voulant rattraper leur retard se sont lancées dans des recherches d’amélioration à travers l’ISO 9000, CMM, SPICE, etc. Ces démarches sont loin d’être négatives, les apports sont plus que positifs. Il faut cependant signaler des échecs cuisants, induits le plus souvent par une non-communication interne à l’entreprise. Faire avancer à marche forcée tout le personnel, sans explication et sans tenir compte de leur point de vue, est la garantie d’un échec. La mise en place d’un système qualité propre à une entreprise, ou à un secteur déterminé, s’il est bien compris et approprié, ne peut être que positive.

Pour faciliter l’approche, et dans un souci de normalisation, il paraît plus simple de prendre le cycle de vie du logiciel et de passer en revue tous les processus le constituant pour en faire ressortir les points qualité. La norme internationale ISO 12207 « Processus du cycle de vie du logiciel » peut servir de trame dans la suite de la présentation. Cette norme regroupe les activités qui doivent être mises en œuvre pendant le cycle de vie, en cinq processus de base, huit processus de support et quatre processus organisationnels.

L’avantage de cette norme est de ne pas se limiter au développement pur du logiciel, mais de le mettre dans le contexte de l’entreprise. Un autre avantage, qui peut être déstabilisant au premier abord, est de ne proposer aucun modèle de cycle de vie, laissant à l’utilisateur la liberté de choix en fonction de son besoin.

Cet article est réservé aux abonnés.
Il vous reste 95% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

DOI (Digital Object Identifier)

https://doi.org/10.51257/a-v1-r8080


Cet article fait partie de l’offre

Automatique et ingénierie système

(138 articles en ce moment)

Cette offre vous donne accès à :

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques

Des services

Un ensemble d'outils exclusifs en complément des ressources

Un Parcours Pratique

Opérationnel et didactique, pour garantir l'acquisition des compétences transverses

Doc & Quiz

Des articles interactifs avec des quiz, pour une lecture constructive

ABONNEZ-VOUS

Lecture en cours
Présentation
Version en anglais En anglais

6. Annexe B. Les normes, les standards, les référentiels

6.1 DO-178B/ED-12B

Considérations sur le logiciel en vue de la certification des systèmes et équipements de bord

Édition de décembre 1992.

But : ce document fournit à la communauté aéronautique des directives pour déterminer, de manière cohérente et avec un degré acceptable de confiance, si les aspects relatifs aux logiciels des systèmes et équipements de bord satisfont les exigences de navigabilité.

Ce document, se basant sur les règlements de l’aviation, définit des catégories de panne :

  • catastrophique (risque sur la sécurité du vol et de l’atterrissage) ;

  • dangereuse (réduction importante des capacités de l’aéronef) ;

  • majeure (réduction significative des capacités de l’aéronef) ;

  • mineure (réduction non significative des capacités de l’aéronef) ;

  • sans effet.

Le niveau du logiciel est basé sur la faculté de celui-ci à rencontrer certaines catégories de panne. Ce niveau implique l’effort nécessaire à fournir pour pallier le risque de survenue de ces pannes.

Il existe 5 niveaux de A à E, correspondant aux 5 catégories. On parle du niveau de criticité du logiciel. Pour chacun de ces niveaux, ce document définit les exigences à respecter.

Ce document demande de prouver que l’environnement de développement, dans la mesure où il allège le travail, ne peut introduire des erreurs dans le logiciel.

HAUT DE PAGE

6.2 DoD-STD-2167

Defence system software development

Ce document du Department of Defence américain décrit l’ensemble des activités à réaliser pour être conforme à ce standard.

Il est annexé à ce document un ensemble de plans-type très directifs décrivant les documents à fournir pour être conforme.

À l’heure actuelle, ce document est en révision, les plans-type ne font plus partie du standard pour permettre de s’adapter plus facilement aux nouvelles méthodes de travail, comme les méthodes à objets par exemple.

Il est quand même intéressant de regarder ces plans-type car ils sont assez complets et peuvent servir de base de départ lors de la mise en place d’un nouvel environnement...

Cet article est réservé aux abonnés.
Il vous reste 93% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

Cet article fait partie de l’offre

Automatique et ingénierie système

(138 articles en ce moment)

Cette offre vous donne accès à :

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques

Des services

Un ensemble d'outils exclusifs en complément des ressources

Un Parcours Pratique

Opérationnel et didactique, pour garantir l'acquisition des compétences transverses

Doc & Quiz

Des articles interactifs avec des quiz, pour une lecture constructive

ABONNEZ-VOUS

Lecture en cours
Annexe B. Les normes, les standards, les référentiels
Sommaire
Sommaire

NORMES

  • Technologies de l’information – Concepts et guide d’introduction – Évaluation de processus de logiciel – Partie 1. - ISO/CEI XP TR 15504-1:1998 -

  • Technologies de l’information de référence pour les processus et l’aptitude de processus – Évaluation de processus de logiciel – Partie 2. - ISO/CEI XP TR 15504-2:1998 -

  • Technologies de l’information – Réalisation d’une évaluation – Évaluation de processus de logiciel – Partie 3. - ISO/CEI XP TR 15504-3:1998 -

  • Technologies de l’information pour la réalisation d’évaluations – Évaluation de processus de logiciel – Partie 4. - ISO/CEI XP TR 15504-4:1998 -

  • Technologies de l’information – Modèle d’évaluation et guide des indicateurs – Évaluation de processus de logiciel – Partie 5. - ISO/CEI XP TR 15504-5:1999 -

  • Technologies de l’information de la compétence des évaluateurs – Évaluation de processus de logiciel – Partie 6. - ISO/CEI XP TR 15504-6:1998 -

  • ...

ANNEXES

  1. 1 Modèles

    1 Modèles

    Capability Maturity Model for Software (CMM)

    Software Process Improvement and Capability DEtermination (SPICE) (ISO)

    HAUT DE PAGE

    Cet article est réservé aux abonnés.
    Il vous reste 94% à découvrir.

    Pour explorer cet article
    Téléchargez l'extrait gratuit

    Vous êtes déjà abonné ?Connectez-vous !


    L'expertise technique et scientifique de référence

    La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
    + de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
    De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

    Cet article fait partie de l’offre

    Automatique et ingénierie système

    (138 articles en ce moment)

    Cette offre vous donne accès à :

    Une base complète d’articles

    Actualisée et enrichie d’articles validés par nos comités scientifiques

    Des services

    Un ensemble d'outils exclusifs en complément des ressources

    Un Parcours Pratique

    Opérationnel et didactique, pour garantir l'acquisition des compétences transverses

    Doc & Quiz

    Des articles interactifs avec des quiz, pour une lecture constructive

    ABONNEZ-VOUS