Vous êtes sur la page 1sur 50

NF EN ISO 9000-3

avril 1999
AFNOR
Association Française
de Normalisation

www.afnor.fr

Toute reproduction ou représentation


intégrale ou partielle, par quelque
procédé que ce soit, des pages publiées
dans le présent document, faite sans
l'autorisation de l'éditeur est illicite et
constitue une contrefaçon. Seules sont
autorisées, d'une part, les reproductions
strictement réservées à l'usage privé
du copiste et non destinées à une
utilisation collective et, d'autre part,
les analyses et courtes citations Diffusé par
justifiées par le caractère scientifique
ou d'information de l'œuvre dans
laquelle elles sont incorporées (Loi du
1er juillet 1992 – art. L 122-4 et L 122-5,
et Code Pénal art. 425).
FA005122 ISSN 0335-3931

norme européenne NF EN ISO 9000-3


Avril 1999

Indice de classement : X 50-121-3

ICS : 03.120.10 ; 35.080

Normes pour le management


de la qualité et l'assurance de la qualité
Partie 3 : Lignes directrices pour l’application de l’ISO 9001:1994
au développement, à la mise à disposition, à l'installation
et à la maintenance du logiciel

E : Quality management and quality assurance standards — Part 3 : Guidelines


for the application of ISO 9001:1994 to the development, supply, installation
and maintenance of computer software
D : Qualitätsmanagement und Qualitätssicherungsnormen — Teil 3 : Leitfaden
für die Anwendung von ISO 9001:1994 auf die Entwicklung, Lieferung
© AFNOR 1999 — Tous droits réservés

und Wartung von Software

Norme française homologuée


par décision du Directeur Général d'AFNOR le 5 mars 1999 pour prendre effet
le 5 avril 1999.
Remplace la norme française homologuée NF EN 29000-3, de novembre 1993.

Correspondance La norme européenne EN ISO 9000-3:1997 a le statut d'une norme française. Elle
reproduit intégralement la norme internationale ISO 9000-3:1997.

Analyse Le présent document établit des lignes directrices facilitant l'application de


l'ISO 9001 pour les organisations de développement, de mise à disposition et de
maintenance du logiciel.
Il a pour but de donner des conseils lorsqu'un contrat entre deux parties requiert la
démonstration de l'aptitude du fournisseur à développer, mettre à disposition et
maintenir le logiciel.

Descripteurs Thésaurus International Technique : qualité, assurance de qualité, programme


d'assurance qualité, logiciel, gestion de processus.

Modifications Par rapport au document remplacé, le présent document présente une structure ali-
gnée selon la norme NF EN ISO 9001:1994.

Corrections

Éditée et diffusée par l’Association Française de Normalisation (AFNOR), Tour Europe 92049 Paris La Défense Cedex
Tél. : 01 42 91 55 55 — Tél. international : + 33 1 42 91 55 55

© AFNOR 1999 AFNOR 1999 1er tirage 99-04-P


Management de la qualité AFNOR X542

Membres de la commission de normalisation


Président : M SÉGOT
Secrétariat : MME MONTOYA et M MATHIEU — AFNOR

M AFFATICATI IRDQ
M ALBERT LEXMARK INTERNATIONAL
M ARENE IBM FRANCE
M ASSAIANTE RTC
M AUPETIT ABB ÉNERGIE
MME AYMARD-DUFOUR LABORATOIRES UPSA
M BARBIER AÉROSPATIALE
M BASSET SCHNEIDER ELECTRIC SA
M BAZINET EDF-GDF SERVICES
M BESSIN 3A CONSULTING
M BISSON SISHE
M BOELY FRANCE TELECOM
M BONNOME ANIA
M BOULANGER MFQ
M BRUNET AFNOR
M CALLONNEC RENAULT
M CANIS LIONEL CANIS CONSEIL
M CLAIR AUTOMOBILES CITROEN
M CLAVERIE COMPAGNIE GÉNÉRALE DES EAUX
MME CRUSILLEAU SQUALPI
M DALRYMPLE AFAQ/DIRECTION INTERNATIONALE
MME DE LUZE BNIF
M DEDEWANOU HOECHST MARION ROUSSEL
MME DEL CERRO AFNOR
M DELEVAL GAZ DE FRANCE
M DELPLACE EXECUTIVE CONSULTANTS
M DESVIGNES SNCF – NORHA
M DHAUSSY GEC ALSTHOM PROTECTION ET CONTROLE
M DUPUIS EDF : DION EQUIPEMENT
M FADY DE DIETRICH ET CIE
M FAURIE CETIM
M FRAGNÉ ANIA
M FRONTIGNY FRAMATOME SA
M FROSI ROHM AND HAAS
MME GAUTHIER BRENNTAG SPECIALISTES
M GEHIN FIEV
M GRAVIER COGEMA
M HENRY AFEXMAR
M JONQUIÈRES CABINET M 23000 +
M JOURDAN SCHNEIDER ELECTRIC SA
M JUREDIEU GIAT INDUSTRIES
MME KANDL IBM FFRANCE
MME KERGOMARD AGF VIE
M LACROIX COMMUNICATION STRUCTURE PERFECTIONNEMENT
M LAMBALIEU ÉCOLE DES MINES DE DOUAI
MME LAVALETTE THOMSON/CSF
M LE CLANCHE FRANCE TÉLÉCOM
M LE COUARHER ALCATEL CIT
M LE GALL SUEZ LYONNAISE DES EAUX
—3— NF EN ISO 9000-3:1999

M LIPIEC FRANCE TÉLÉCOM


M LOCHEN GEC ALSTHOM T & D
M LOISIER SNCF
M MAILLARD EDF-GDF
M MARMIGNON SNAP — GROUPE BACOU
M MAROLLEAU SOCIETE GENERALE — IBAQ
M MAUGUIÈRE THOMSON CSF COMMUNICATION
MME MEILLIER MATRA BAE DYNAMICS FRANCE
MME MESSEANT SOCIÉTÉ DES PÉTROLES SHELL
M MICHEL ELF ANTAR FRANCE
M MIGNOT THOMSON CSF
M MILLERET SOMELEC SA / SNEMI
M MIRANDA
M MOLLERON GITEP — SIT
M MOUTON HUTCHINSON SA
M MUSSO NESTLE FRANCE
MME NEEL DASSAULT AVIATION
M NELSON ISOTUB COATING
M NICOLAS FIM
M NICOUD ALUMINIUM PECHINEY
M NIGEON ITM QUALITÉ
M NOSSENT CSTB
M NOSSENT BINKS SAMES FRANCE SA
M PAILHES RHONE POULENC QUALITE SERVICE
M PETIT RENAULT VI
M QUINIO AFITEP
M RICHER ECOLE HEI
M ROUSSEL POUYET
M RUPIED COPACEL
M SAMPÈRE CEP SYSTÈMES
M SANS
M SÉCHAUD CNAM
M SÉGOT LA POSTE/DG/DC
M SOBOLEVICIUS CRCI HAUTE NORMANDIE
M SOROSTE
M TAILLIFET EDF DER
M TEISSEIRE EDF SEPTEN
M VAISENBERG AFAQ/ICA
MME VALORSO-GRANDIN DAEI/METT
M VINIT CGI INFORMATIQUE IBM GLOBAL SERVICES
M WENISCH SQIFE/RENAULT V.I

Avant-propos national
Références aux normes françaises
La correspondance entre les normes mentionnées à l'article «Références normatives» et les normes françaises
identiques est la suivante :
ISO 8402 : NF EN ISO 8402 (indice de classement : X 50-120)
ISO 9001 : NF EN ISO 9001 (indice de classement : X 50-131)
NORME EUROPÉENNE EN ISO 9000-3
EUROPÄISCHE NORM
EUROPEAN STANDARD Décembre 1997

ICS 03.120.10 Remplace : EN 29000-3:1993


Descripteurs : gestion de qualité, assurance de qualité, programme d'assurance qualité, système d'assurance
qualité, programme de calculateur, norme, norme internationale, mise en oeuvre, règlement.

Version française

Normes pour le management de la qualité et l'assurance de la qualité —


Partie 3 : Lignes directrices pour l'application de l'ISO 9001:1994 au développement,
à la mise à disposition, à l'installation et à la maintenance du logiciel
(ISO 9000-3:1997)

Qualitätsmanagement Quality management and quality assurance standards —


und Qualitätssicherungsnormen — Part 3 : Guidelines for the application
Teil 3 : Leitfaden für die Anwendung of ISO 9001:1994 to the development, supply,
von ISO 9001:1994 auf die Entwicklung, installation and maintenance of computer software
Lieferung und Wartung von Software (ISO 9000-3:1997)
(ISO 9000-3:1997)

La présente norme européenne a été adoptée par le CEN le 5 janvier 1998.

Les membres du CEN sont tenus de se soumettre au Règlement Intérieur du CEN/CENELEC qui définit les
conditions dans lesquelles doit être attribué, sans modification, le statut de norme nationale à la norme
européenne.

Les listes mises à jour et les références bibliographiques relatives à ces normes nationales peuvent être obtenues
auprès du Secrétariat Central ou auprès des membres du CEN.

La présente norme européenne existe en trois versions officielles (allemand, anglais, français). Une version faite
dans une autre langue par traduction sous la responsabilité d'un membre du CEN dans sa langue nationale, et
notifiée au Secrétariat Central, a le même statut que les versions officielles.

Les membres du CEN sont les organismes nationaux de normalisation des pays suivants : Allemagne, Autriche,
Belgique, Danemark, Espagne, Finlande, France, Grèce, Irlande, Islande, Italie, Luxembourg, Norvège, Pays-
Bas, Portugal, République Tchèque, Royaume-Uni, Suède et Suisse.

CEN
COMITÉ EUROPÉEN DE NORMALISATION

Europäisches Komitee für Normung


European Committee for Standardization

Secrétariat Central : rue de Stassart 36, B-1050 Bruxelles

© CEN 1997 Tous droits d’exploitation sous quelque forme et de quelque manière que ce soit réservés dans le monde
entier aux membres nationaux du CEN.
Réf. n° EN ISO 9000-3:1997 F
Page 2
EN ISO 9000-3:1997

Avant-propos

Le texte de la norme internationale ISO 9000-3:1997 a été élaboré par le Comité Technique ISO/TC 176 «Mana-
gement et assurance de la qualité» en collaboration avec le CEN/CS.
La présente norme européenne remplace l'EN 29000-3:1993.
Cette norme européenne devra recevoir le statut de norme nationale soit par publication d'un texte identique, soit
par entérinement au plus tard en juin 1998, et toutes les normes nationales en contradiction devront être retirées
au plus tard en juin 1998.
Selon le Règlement Intérieur du CEN/CENELEC, les instituts de normalisation nationaux des pays suivants sont
tenus de mettre cette norme européenne en application : Allemagne, Autriche, Belgique, Danemark, Espagne,
Finlande, France, Grèce, Irlande, Islande, Italie, Luxembourg, Norvège, Pays-Bas, Portugal, République Tchè-
que, Royaume-Uni, Suède et Suisse.

Notice d'entérinement

Le texte de la norme internationale ISO 9000-3:1997 a été approuvé par le CEN comme norme européenne sans
aucune modification.
ISO 9000-3:1997(F)

Sommaire

1 Domaine d’application ............................................................................................................................................ 1

2 Références normatives ........................................................................................................................................... 1

3 Définitions ................................................................................................................................................................ 1

4 Exigences en matière de système qualité............................................................................................................. 3

4.1 Responsabilité de la direction............................................................................................................................. 3

4.2 Système qualité..................................................................................................................................................... 4

4.3 Revue de contrat................................................................................................................................................... 6

4.4 Maîtrise de la conception ..................................................................................................................................... 8

4.5 Maîtrise des documents et des données.......................................................................................................... 16

4.6 Achats .................................................................................................................................................................. 17

4.7 Maîtrise du produit fourni par le client ............................................................................................................. 19

4.8 Identification et traçabilité du produit .............................................................................................................. 20

4.9 Maîtrise des processus ...................................................................................................................................... 22

4.10 Contrôles et essais ........................................................................................................................................... 24

4.11 Maîtrise des équipements de contrôle, de mesure et d'essai ...................................................................... 27

4.12 État des contrôles et des essais ..................................................................................................................... 28

4.13 Maîtrise du produit non conforme .................................................................................................................. 29

4.14 Actions correctives et préventives ................................................................................................................. 30

4.15 Manutention, stockage, conditionnement, préservation et livraison .......................................................... 31

4.16 Maîtrise des enregistrements relatifs à la qualité.......................................................................................... 33

4.17 Audits qualité internes ..................................................................................................................................... 34

4.18 Formation .......................................................................................................................................................... 34

ii
© ISO ISO 9000-3:1997(F)

4.19 Prestations associées ...................................................................................................................................... 34

4.20 Techniques statistiques................................................................................................................................... 36

Annexe A (informative) Bibliographie ..................................................................................................................... 38

Annexe B (informative) Références croisées entre l'ISO 9000-3 et l'ISO/CEI 12207........................................... 39

iii
ISO 9000-3:1997(F) © ISO

Avant-propos

L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux de
normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général confiée aux
comités techniques de l'ISO. Chaque comité membre intéressé par une étude a le droit de faire partie du comité
technique créé à cet effet. Les organisations internationales, gouvernementales et non gouvernementales, en
liaison avec l'ISO participent également aux travaux. L'ISO collabore étroitement avec la Commission
électrotechnique internationale (CEI) en ce qui concerne la normalisation électrotechnique.

Les projets de Normes internationales adoptés par les comités techniques sont soumis aux comités membres pour
vote. Leur publication comme Normes internationales requiert l'approbation de 75 % au moins des comités
membres votants.

La Norme internationale ISO 9000-3 a été élaborée par le comité technique ISO/TC 176, Management et assurance
de la qualité, sous-comité SC 2, Systèmes qualité.

Cette deuxième édition annule et remplace la première édition (ISO 9000-3:1991), dont elle constitue une révision
technique.

L’ISO 9000 comprend les parties suivantes, présentées sous le titre général Normes pour le management de la
qualité et l'assurance de la qualité:

 Partie 1: Lignes directrices pour leur sélection et utilisation

 Partie 2: Lignes directrices génériques pour l'application de l'ISO 9001, l'ISO 9002 et l'ISO 9003

 Partie 3: Lignes directrices pour l'application de l'ISO 9001:1994 au développement, à la mise à disposition, à
l'installation et à la maintenance de logiciel

 Partie 4: Guide de gestion du programme de sûreté de fonctionnement

Les annexes A et B de la présente partie de l’ISO 9000 sont données uniquement à titre d’information.

iv
© ISO ISO 9000-3:1997(F)

Introduction

La présente partie de l’ISO 9000 formule des lignes directrices concernant l'application des exigences de
l'ISO 9001:1994 lorsque la conception, le développement, l'installation et la maintenance du logiciel font partie
intégrante de l'activité d'un fournisseur:

a) dans le cadre d'un contrat commercial passé avec un organisme externe;

b) en vue de lancer un produit sur un marché spécifique;

c) en tant que support des processus métiers de l'entreprise du fournisseur;

d) en vue de produire un logiciel inclus dans un produit matériel.

Elle identifie les points qui doivent être abordés et s'applique indépendamment de la technologie, des modèles de
cycle de vie, des processus de développement, de la séquence des activités ou de la structure organisationnelle du
fournisseur.

Il convient de clairement documenter, au sein du système qualité de l'organisme, les relations entre les éléments
logiciels de ce système qualité et les autres aspects, lorsque le domaine d'application des activités de l'organisme
dépasse celui du développement de logiciels.

La présente partie de l'ISO 9000 formule des lignes directrices concernant l'application de l'ISO 9001:1994.
Lorsque le texte est extrait de l'ISO 9001:1994, celui-ci est encadré pour qu'il puisse être facilement
identifié.

Tout au long de la présente partie de l'ISO 9000, le verbe «devoir» est utilisé pour exprimer une obligation qui lie
une partie contractante à une ou plusieurs autres parties; le futur exprime une déclaration d'intention ou d'objectif
par une partie; l'expression «il convient que» ou «il est recommandé de» exprime une recommandation parmi
d'autres possibilités; le verbe «pouvoir» exprime une liberté d'action dans le cadre de la présente partie de
l'ISO 9000.

v
NORME INTERNATIONALE © ISO ISO 9000-3:1997(F)

Normes pour le management de la qualité et l'assurance de la


qualité —
Partie 3:
Lignes directrices pour l'application de l'ISO 9001:1994 au
développement, à la mise à disposition, à l'installation et à la
maintenance du logiciel

1 Domaine d’application

La présente partie de l’ISO 9000 établit des lignes directrices pour faciliter l'application de l’ISO 9001:1994 dans des
organismes qui développent, mettent à disposition, installent et maintiennent des logiciels. Elle ne modifie ou ne
renforce en rien les exigences de l’ISO 9001.

Elle n'est pas destinée à être utilisée en tant que critère d'évaluation pour la certification du système qualité.

2 Références normatives

Les normes suivantes contiennent des dispositions qui, par suite de la référence qui en est faite, constituent des
dispositions valables pour la présente partie de l’ISO 9000. Au moment de la publication, les éditions indiquées
étaient en vigueur. Toute norme est sujette à révision et les parties prenantes des accords fondés sur la présente
partie de l’ISO 9000 sont invitées à rechercher la possibilité d'appliquer les éditions les plus récentes des normes
indiquées ci-après. Les membres de la CEI et de l'ISO possèdent le registre des Normes internationales en vigueur
à un moment donné.

ISO 8402:1994, Management de la qualité et assurance de la qualité — Vocabulaire.

ISO 9001:1994, Systèmes qualité — Modèle pour l'assurance de la qualité en conception, développement,
production, installation et prestations associées.

3 Définitions

Pour les besoins de la présente partie de l’ISO 9000, les définitions données dans l’ISO 8402, ainsi que les
définitions suivantes s'appliquent.

3.1
produit
résultat d'activités ou de processus

NOTE 1 Le terme «produit» peut inclure les services, les matériels, les produits issus de processus à caractère continu, les
logiciels, ou une combinaison des deux.

NOTE 2 Un «produit» peut être matériel (par exemple assemblages ou produits issus de processus à caractère continu) ou
immatériel (par exemple, connaissances ou concepts), ou une combinaison des deux.

1
ISO 9000-3:1997(F) © ISO

NOTE 3 Dans le cadre de la présente Norme internationale, le terme «produit» s'applique au produit intentionnel et ne
s'applique pas aux sous-produits non intentionnels affectant l'environnement. Ceci diffère de la définition donnée dans
l'ISO 8402.

[ISO 9001]

3.2
offre
offre faite par un fournisseur en réponse à un appel d'offre en vue de l'attribution d'un contrat de fourniture d'un
produit

[ISO 9001]

3.3
contrat
exigences ayant fait l'objet d'un accord entre un fournisseur et un client et transmises par un moyen quelconque

[ISO 9001]

3.4
référentiel de configuration
version formellement approuvée d'un élément de configuration (quel que soit le support) qui est formellement
attribuée et attachée à un instant spécifique du cycle de vie de l'élément de configuration

[ISO/CEI 12207]

3.5
développement
processus du cycle de vie du logiciel qui comprend les activités d'analyse des besoins, de conception, de codage,
d'intégration, d'essai, d'installation et d'assistance en vue de l'acceptation des logiciels

3.6
modèle de cycle de vie
scénario, contenant les processus, les activités et les tâches mis en œuvre pour le développement, l'exploitation et
la maintenance d'un logiciel, englobant la totalité de la vie du système depuis l'expression des besoins jusqu'à la fin
de son exploitation

[ISO/CEI 12207]

3.7
phase
séquence définie d'activités

NOTE Une phase n'implique pas l'utilisation d'un modèle de cycle de vie particulier.

3.8
essai de non régression
essai visant à assurer que les modifications réalisées dans le but de corriger des défauts n'ont pas introduit de
défauts supplémentaires

3.9
reproduction
copie d'un logiciel d'un support vers un autre

2
© ISO ISO 9000-3:1997(F)

3.10
logiciel
ensemble des programmes, des procédures et de la documentation et des données éventuellement associées

[ISO/CEI 12207]

NOTE Dans la présente partie de l’ISO 9000, le terme «logiciel» se limite au logiciel informatique.

3.11
produit logiciel
NOTE 1 En français, le terme «logiciel» suffit; il n'est pas nécessaire d'introduire le terme «produit logiciel».
NOTE 2 Un logiciel peut être destiné à être livré; il peut également faire partie intégrante d'un autre produit ou être utilisé au
cours du processus de développement.

3.12
composant du logiciel
toute partie identifiable du logiciel

4 Exigences en matière de système qualité

4.1 Responsabilité de la direction

4.1.1 Politique qualité

La direction du fournisseur, qui a pouvoir de décision doit définir et consigner par écrit sa politique en
matière de qualité, y compris ses objectifs et son engagement en la matière. La politique qualité doit être
pertinente par rapport aux objectifs généraux du fournisseur et aux attentes et besoins de ses clients.
Le fournisseur doit assurer que cette politique est comprise, mise en œuvre et entretenue à tous les
niveaux de l'organisme.

Il n’y a aucune recommandation particulière concernant le logiciel.

4.1.2 Organisation

4.1.2.1 Responsabilité et autorité

La responsabilité, l'autorité et les relations entre les personnes qui dirigent, exécutent et vérifient des
tâches qui ont une incidence sur la qualité doivent être définies par écrit; cela concerne en particulier les
personnes qui ont besoin de la liberté et de l'autorité sur le plan de l'organisation pour
a) déclencher des actions permettant de prévenir l'apparition de toute non-conformité relative au produit,
au processus et au système qualité;
b) identifier et enregistrer tout problème relatif au produit, au processus et au système qualité;
c) déclencher, recommander ou fournir des solutions en suivant des circuits définis;
d) vérifier la mise en œuvre des solutions;
e) maîtriser la poursuite des opérations relatives au produit non conforme, sa livraison ou son installation
jusqu'à ce que la déficience ou la situation non satisfaisante ait été corrigée.

Il n’y a aucune recommandation particulière concernant le logiciel.

3
ISO 9000-3:1997(F) © ISO

4.1.2.2 Moyens

Le fournisseur doit identifier les exigences relatives aux moyens et fournir les moyens adéquats, y compris
la désignation de personnes formées (voir 4.18), pour le management, l'exécution et la vérification des
tâches, ainsi que les audits qualité internes.

Il n’y a aucune recommandation particulière concernant le logiciel.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphe 7.2.

4.1.2.3 Représentant de la direction

La direction du fournisseur, qui a pouvoir de décision, doit nommer un de ses membres qui, nonobstant
d'autres responsabilités, doit avoir une autorité définie pour
a) assurer qu'un système qualité est défini, mis en œuvre et entretenu conformément à la présente
Norme internationale; et
b) rendre compte du fonctionnement du système qualité à la direction du fournisseur pour en faire la
revue et servir de base à l'amélioration du système qualité.
NOTE 5 La responsabilité du représentant de la direction peut également comprendre les relations avec des
parties extérieures en ce qui concerne les sujets relatifs au système qualité du fournisseur.

Il n’y a aucune recommandation particulière concernant le logiciel.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphe 6.3.1.6.

4.1.3 Revue de direction

La direction du fournisseur, qui a pouvoir de décision, doit faire une revue du système qualité à une
fréquence définie et suffisante pour assurer qu'il demeure constamment approprié et efficace afin de
satisfaire aux exigences de la présente Norme internationale ainsi qu'à la politique et aux objectifs qualité
fixés par le fournisseur (voir 4.1.1). Des enregistrements de ces revues doivent être conservés (voir 4.16).

Il n’y a aucune recommandation particulière concernant le logiciel.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphe 7.1.4.

4.2 Système qualité

4.2.1 Généralités

Le fournisseur doit établir, consigner par écrit et entretenir un système qualité en tant que moyen pour
assurer que le produit est conforme aux exigences spécifiées. Le fournisseur doit établir un manuel qualité
couvrant les exigences de la présente Norme internationale. Le manuel qualité doit comprendre les
procédures du système qualité ou y faire référence, et exposer la structure de la documentation utilisée
dans le cadre du système qualité.
NOTE 6 L'ISO 10013 fournit des conseils relatifs à l'élaboration des manuels qualité.

Il n’y a aucune recommandation particulière concernant le logiciel.

4
© ISO ISO 9000-3:1997(F)

4.2.2 Procédures du système qualité

Le fournisseur doit
a) établir des procédures écrites cohérentes avec les exigences de la présente Norme internationale et
avec la politique qualité qu'il a formulée, et
b) mettre réellement en œuvre le système qualité et ses procédures écrites.
Dans le cadre de la présente Norme internationale, l'étendue et le niveau de détail des procédures qui font
partie du système qualité doivent dépendre de la complexité des tâches, des méthodes utilisées, des
compétences et de la formation nécessaires au personnel impliqué dans l'exécution de ces tâches.
NOTE 7 Les procédures écrites peuvent faire référence à des instructions de travail qui définissent comment une
tâche est réalisée.

Il n’y a aucune recommandation particulière concernant le logiciel.

4.2.3 Planification de la qualité

Le fournisseur doit définir et consigner par écrit comment satisfaire les exigences pour la qualité. La
planification de la qualité doit être cohérente avec l'ensemble des exigences du système qualité du
fournisseur et doit être consignée sous une forme adaptée aux méthodes de travail du fournisseur. Ce
dernier doit porter toute son attention sur les activités suivantes, s'il y a lieu, pour satisfaire aux exigences
spécifiées pour les produits, les projets ou les contrats:
a) l'établissement de plans qualité;
b) l'identification et l'acquisition de tous moyens de maîtrise des activités, processus, équipements (y
compris les équipements de contrôle et d'essai), dispositifs, ensemble des moyens et compétences qui
peuvent être nécessaires pour obtenir la qualité requise;
c) l'assurance de la compatibilité de la conception, du processus de production, de l'installation, des
prestations associées, des procédures de contrôle et d'essai et de la documentation applicable;
d) la mise à jour, autant que nécessaire, des techniques de maîtrise de la qualité, de contrôle et d'essai, y
compris le développement d'une nouvelle instrumentation;
e) l'identification, en temps voulu, de toute exigence en matière de mesurage mettant en jeu une aptitude
qui dépasse les possibilités actuelles de l'état de l'art, afin de développer l'aptitude nécessaire;
f) l'identification des vérifications adéquates aux phases appropriées de la réalisation du produit;
g) la clarification des normes d'acceptation pour toutes les caractéristiques et exigences, y compris celles
qui contiennent un élément subjectif;
h) l'identification et la préparation d'enregistrements relatifs à la qualité (voir 4.16).
NOTE 8 Les plans qualité mentionnés [voir 4.2.3 a)] peuvent faire référence aux procédures écrites appropriées qui
font partie intégrante du système qualité du fournisseur.

Il convient que la planification de la qualité aborde les points suivants, s'il y a lieu:

a) les exigences pour la qualité, exprimées en termes mesurables, lorsque cela est nécessaire;

b) le modèle de cycle de vie à utiliser pour le développement du logiciel;

c) les critères de début et de fin de chaque phase du projet;

d) l'identification des types de revues, de tests, et d'autres activités de vérification et validation à mener;

e) l'identification des procédures de gestion de la configuration à suivre;

5
ISO 9000-3:1997(F) © ISO

f) un planning détaillé (comprenant le calendrier, les procédures, les moyens et les approbations) ainsi que les
responsabilités et autorités spécifiques en vue de:

 la gestion de la configuration;

 la vérification et la validation des produits développés;

 la vérification et la validation des produits achetés;

 la vérification des produits fournis par le client;

 la maîtrise du produit non conforme et des actions correctives;

 l'assurance que les activités décrites dans le plan qualité sont réalisées.

Un plan qualité permet d'ajuster l'application d'un système qualité à un projet, à un produit ou à un contrat
spécifique.

Un plan qualité peut inclure ou faire référence à des procédures génériques et/ou à des procédures qui concernent
les contrats, produits ou projets, le cas échéant. Il est recommandé que le plan qualité soit mis à jour au fur et à
mesure de l'avancement du développement et que ce qui concerne chaque phase soit entièrement défini lorsque
celle-ci commence.

Il est recommandé qu'un plan qualité soit revu et accepté par toutes les organisations concernées par sa mise en
œuvre.

Le document qui décrit un plan qualité peut être distinct (intitulé plan qualité), faire partie d'un autre document, ou
être composé de plusieurs documents.

Un plan qualité peut inclure ou faire référence aux plans de tests unitaires, de tests d'intégration, d'essais du
système et d'essais d'acceptation. Des recommandations concernant la planification des tests et essais et
l'environnement de tests sont formulées dans le cadre des contrôles et des essais.

NOTE Des lignes directrices concernant les plans qualité sont données dans l’ISO 10005, et concernant la gestion de la
configuration, dans l’ISO 10007. Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphes 6.2 à 6.5.

4.3 Revue de contrat

4.3.1 Généralités

Le fournisseur doit établir et tenir à jour des procédures écrites de revue de contrat et de coordination de
ces activités.

Le logiciel peut être développé dans le cadre d'un contrat, en tant que produit destiné à un marché particulier, en
tant que logiciel incorporé à du matériel, ou en tant que support des processus métiers du fournisseur. La revue de
contrat est applicable dans tous ces cas.

6
© ISO ISO 9000-3:1997(F)

4.3.2 Revue

Avant soumission d'une offre ou acceptation d'un contrat ou d'une commande (formulation des exigences),
l'offre, le contrat ou la commande doit être revu(e) par le fournisseur afin d'assurer que
a) les exigences sont définies et documentées de façon adéquate; lorsqu'il n'existe pas d'exigences
écrites pour une commande verbale, le fournisseur doit assurer que les exigences de cette commande
ont fait l'objet d'un accord avant d'être acceptées;
b) toute différence entre les exigences d'un contrat ou d'une commande et celles de l'offre a fait l'objet
d'une solution;
c) le fournisseur présente l'aptitude à satisfaire aux exigences du contrat ou de la commande.

Les points suivants peuvent également s'appliquer au cours de la revue par le fournisseur d'offres, de contrats, ou
de commandes relatifs au logiciel.

a) Points concernant le client:

 la terminologie à utiliser est acceptée par les parties concernées;

 le client a la capacité et les moyens de satisfaire aux obligations contractuelles qui ont été établies;

 les critères d'acceptation ou de rejet du produit par le client sont approuvés;

 les responsabilités du client dans la fourniture de données et des moyens associés;

 la mesure dans laquelle le client s'implique dans le développement et dans la sous-traitance;

 les dispositions prises pour les revues conjointes afin de superviser le déroulement du contrat;

 la procédure convenue pour gérer l'évolution des exigences client lors du développement et/ou de la
maintenance;

 les processus de cycle de vie imposés par le client;

 le traitement des problèmes détectés après acceptation, y compris les plaintes du client et les
réclamations;

 la responsabilité de la suppression des non-conformités après l'expiration de la garantie;

 toute obligation pour le client de passer à une nouvelle version lorsque le fournisseur le décide, ou pour le
fournisseur de maintenir des anciennes versions;

 le déploiement du logiciel et la formation correspondante des utilisateurs.

b) Points techniques:

 la possibilité de répondre aux exigences;

 les normes de développement du logiciel et les procédures à utiliser;

 les moyens, les outils, les composants et données du logiciel, à fournir par le client, sont identifiés; les
méthodes sont définies et documentées afin d'évaluer leur pertinence;

 le système d'exploitation ou la plate-forme matérielle;

 l'accord sur la maîtrise des interfaces avec le logiciel;

 les exigences de reproduction et de diffusion.

7
ISO 9000-3:1997(F) © ISO

c) Points concernant la direction:

 les contingences ou les risques sont identifiés et leurs impacts sur les activités ultérieures sont estimés;

 la responsabilité du fournisseur concernant les travaux sous-traités (voir 4.6);

 l'échéancier, la planification des revues techniques et des livrables;

 les exigences concernant l'installation, la maintenance et le soutien;

 la disponibilité, en temps voulu, des moyens techniques, humains et financiers.

d) Points relatifs à la législation, à la sécurité et à la confidentialité:

 les informations traitées dans le cadre du contrat peuvent être sujettes aux droits de la propriété
intellectuelle, à des accords de licence, à la confidentialité et à la protection;

 la garde de l'original du produit et les droits du client d'y accéder ou de le vérifier;

 le niveau d'accès du client aux informations doit faire l'objet d'un accord entre les deux parties;

 la définition des conditions de la garantie;

 les responsabilités/pénalités associées au contrat.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphes 5.2.1, 5.2.6 et 6.4.2.1.

4.3.3 Avenant au contrat

Le fournisseur doit définir comment un avenant à un contrat est traité et comment il le transmet
correctement aux fonctions concernées de son organisation.

Il n’y a aucune recommandation particulière concernant le logiciel.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphes 5.1.3.5 et 5.2.3.2.

4.3.4 Enregistrements

Des enregistrements de ces revues de contrat doivent être conservés (voir 4.16).
NOTE 9 Il convient de constituer des circuits de communication et des interfaces avec l’organisation du client en
matière de contrat.

Il n’y a aucune recommandation particulière concernant le logiciel.

4.4 Maîtrise de la conception

4.4.1 Généralités

Le fournisseur doit établir et tenir à jour des procédures écrites pour maîtriser et vérifier la conception du
produit afin d'assurer que les exigences spécifiées sont satisfaites.

Le présent paragraphe donne des lignes directrices sur les activités, incombant au développement, d'analyse des
besoins, de conception de l'architecture, de conception détaillée et de codage. Il contient également des conseils
sur la planification du développement.

Il convient qu'un projet de développement de logiciel soit organisé selon un ou plusieurs modèles de cycle de vie. Il
convient de planifier les processus, les activités et les tâches et de les réaliser en fonction du type de cycle de vie
utilisé. Le modèle de cycle de vie utilisé peut être adapté aux besoins particuliers du projet. La présente partie de

8
© ISO ISO 9000-3:1997(F)

l’ISO 9000 est destinée à être appliquée indépendamment du modèle de cycle de vie et n'a pas pour objet
d'indiquer un modèle de cycle de vie particulier.

Un modèle de cycle de vie identifie un ensemble de processus et spécifie quand et comment ces processus
interviennent. L'ordre dans lequel ces processus sont décrits dans la présente partie de l’ISO 9000 ne suggère en
aucun cas l'ordre dans lequel ils doivent être réalisés.

Le processus de développement transforme les besoins en un logiciel. Il convient que ce processus soit réalisé
selon une approche structurée, afin d'empêcher l'introduction d'erreurs. En adoptant cette approche, on évite de
dépendre uniquement des processus de vérification et de validation pour identifier les problèmes. Il convient donc
que le fournisseur établisse et tienne à jour des procédures écrites pour s'assurer que les logiciels sont développés
conformément aux exigences spécifiées et au plan de développement et/ou au plan qualité.

Il convient de prendre en compte les aspects suivants, inhérents aux activités de conception:

a) Méthode de conception: il convient d'utiliser une méthode de conception de manière systématique. Il est
recommandé de veiller à ce que la méthode soit bien adaptée au type de tâche, de produit ou de projet et à ce
que l'application, les méthodes et les outils utilisés soient compatibles.

b) Retour d'expérience: il convient que le fournisseur évite la répétition des problèmes analogues, en tirant parti
des expériences antérieures, de l'analyse des indicateurs et des revues de fin de projet.

c) Processus ultérieurs: il convient, dans la mesure du possible, de concevoir le logiciel pour faciliter les essais,
l'installation, la maintenance et l'utilisation.

d) Sûreté et sécurité: il convient de porter une attention particulière à la conception en vue de la testabilité et de la
validation. En ce qui concerne les produits dont la défaillance est susceptible de porter atteinte à l'homme, au
matériel ou à l'environnement, il convient que la conception garantisse l'élaboration d'exigences spécifiques de
conception précisant, en fonction des conditions potentielles de défaillance, la protection attendue ainsi qu'un
système de parade adaptée.

Concernant le codage, il convient de spécifier et d'observer des règles d'utilisation de langages de programmation,
des règles cohérentes de nommage, de codage et des règles de commentaires adéquats. Il convient de
documenter et de maîtriser ces règles.

Le fournisseur peut utiliser des outils, des moyens et des techniques pour rendre opérationnelles les lignes
directrices de système qualité mentionnées dans la présente partie de l’ISO 9000. Ces outils, moyens et techniques
peuvent se révéler efficaces dans une optique de management aussi bien que pour le développement de produits
et/ou de prestations associées. Lorsque ces outils et techniques sont élaborés en interne ou achetés, il convient
que le fournisseur évalue leur adéquation à l'objet auquel ils sont destinés. Il convient que les outils utilisés lors de
la mise en œuvre du produit ainsi que les outils d'analyse et de conception, les compilateurs et assembleurs, soient
approuvés et pris en charge au niveau approprié par la gestion de la configuration avant d'être utilisés. Il convient
de documenter le domaine d'utilisation de ces outils et techniques et de procéder à la revue de leur utilisation, selon
le cas, pour déterminer s'il est nécessaire de les améliorer et/ou de procéder à leur mise à jour.

Il se peut que le personnel ait besoin d'être formé à l'utilisation de ces techniques et outils, en début d'utilisation ou
après toute amélioration/mise à jour.

4.4.2 Planification de la conception et du développement

Le fournisseur doit élaborer des plans pour chaque activité de conception et de développement. Ces plans
décrivent ces activités ou y font référence, et définissent les responsabilités pour leur mise en œuvre. Les
activités de conception et de développement doivent être affectées à du personnel qualifié doté de moyens
adéquats. Les plans doivent être mis à jour au fur et à mesure de l'évolution de la conception.

Pour les logiciels, il convient que la «planification du développement» détermine les activités d'analyse des besoins,
de conception, de codage, d'intégration, de test, d'installation et d'assistance à l'acceptation des logiciels. Il convient
de documenter la planification du développement dans un plan de développement.

9
ISO 9000-3:1997(F) © ISO

Il est recommandé qu'un plan de développement soit revu et approuvé. Un plan de développement peut également
être appelé «plan de développement logiciel» ou «plan de projet logiciel».

Un plan de développement peut définir la façon dont le projet doit être géré, les revues d'avancement requises ainsi
que le type et la fréquence des comptes rendus à la direction, au client et à d'autres parties intéressées, en prenant
en compte, s'il y a lieu, les exigences contractuelles.

Il convient que la planification du développement aborde les points suivants, lorsque cela est approprié:

a) la définition du projet, avec un rappel de ses objectifs et une référence à tout projet associé du client ou du
fournisseur;

b) la définition des données d'entrée et de sortie du projet pris dans son ensemble;

c) l'organisation des ressources du projet, comprenant la structure de l'équipe, les responsabilités, les sous-
contractants et les moyens matériels;

d) les interfaces organisationnelles et techniques entre les différents individus ou groupes, telles que

 les équipes de sous-projets,

 les sous-contractants,

 les utilisateurs,

 les représentants du client,

 les représentants de l'assurance de la qualité;

e) l'identification, ou la référence qui en est faite,

 des activités de développement à réaliser,

 des données d'entrée de chaque activité,

 des données de sortie de chaque activité,

 des activités de management et de soutien qui sont à réaliser;

f) l'analyse des risques, des hypothèses, des dépendances et des problèmes potentiels liés au développement;

g) le calendrier identifiant

 les phases du projet,

 les travaux à réaliser (les données d'entrée, de sortie et la définition de chaque tâche),

 les ressources associées,

 les interdépendances,

 les points clés;

10
© ISO ISO 9000-3:1997(F)

h) l'identification

 de normes, règles, pratiques et conventions,

 d'outils et techniques nécessaires au développement, y compris la qualification et la maîtrise de la


configuration de ces outils et techniques,

 de pratiques de gestion de la configuration,

 de méthodes de maîtrise des produits non conformes,

 de méthodes de maîtrise des logiciels non livrables utilisés comme support au développement,

 de procédures d'archivage, de secours et de reprise, y compris la planification des parades,

 de méthodes de maîtrise en vue de la protection contre les virus;

i) l'identification de plans associés (y compris les plans concernant le système) tels que

 le plan qualité,

 le plan de maîtrise des risques,

 le plan de gestion de la configuration,

 le plan d'intégration,

 le plan de tests,

 le plan d'installation,

 le plan de migration,

 le plan de formation,

 le plan de maintenance,

 le plan de réutilisation.

Le plan de développement et tout autre plan associé peuvent être des documents distincts, faire partie d'un autre
document ou être composés de plusieurs documents.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphe 5.2.4.

4.4.3 Interfaces organisationnelles et techniques

Les interfaces organisationnelles et techniques entre les différents groupes, qui contribuent au processus
de conception, doivent être définies et les informations nécessaires doivent être consignées par écrit,
transmises et revues régulièrement.

Il convient de définir clairement, dans les plans de développement des fournisseurs et des sous-contractants, la
limite des responsabilités pour chaque partie du logiciel et la manière dont les informations techniques seront
échangées entre les différents acteurs. Le fournisseur peut exiger que le sous-contractant lui remette un plan de
développement, pour revue.

Lors de la définition des interfaces, il convient de veiller à prendre en compte certaines parties intéressées, autres
que le client et le fournisseur, qui ont besoin de participer à l'installation, à la maintenance et aux activités de
formation. Il peut s'agir de sous-contractants, d'autorités réglementaires, de personnel des projets de

11
ISO 9000-3:1997(F) © ISO

développement associés et du support technique. Il se peut que les utilisateurs finaux et les exploitants aient
particulièrement besoin d'être impliqués pour assurer que les aptitudes et la formation sont adéquates et qu'elles
permettent d'atteindre les niveaux de service auxquels l'organisme s'est engagée.

Il se peut que le client se voie assigner certaines responsabilités dans le cadre du contrat. La nécessité pour le
client de coopérer avec le fournisseur, afin de fournir à temps l'ensemble des informations nécessaires et de
résoudre certains points, est un élément important. S'il convient de nommer un représentant du client, celui-ci peut
représenter l'utilisateur final du produit, tout comme la direction, et avoir l'autorité nécessaire pour traiter les
questions contractuelles qui comprennent, mais ne se limitent pas aux actions suivantes:

a) faire part au fournisseur des exigences du client;

b) répondre aux questions du fournisseur;

c) approuver les propositions du fournisseur;

d) conclure des accords avec le fournisseur;

e) s'assurer que l'organisme auquel appartient le client respecte les accords passés avec le fournisseur;

f) définir les critères et les procédures d'acceptation;

g) traiter les composants de logiciel, les données, les moyens et les outils fournis par le client, mais inaptes à
l'utilisation;

h) définir la responsabilité du client.

Les revues conjointes du fournisseur et du client, peuvent, lorsqu'elles font l'objet d'un accord réciproque, être
planifiées à intervalles réguliers ou lors d'événements clés du projet, pour traiter les aspects suivants, selon les
besoins:

a) l'avancement des travaux de développement du logiciel entrepris par le fournisseur;

b) l'avancement des activités entreprises par le client, comme convenu;

c) la conformité des produits à la spécification des besoins du client;

d) l'avancement des activités concernant les utilisateurs finals du système, telles que la migration et la formation;

e) les résultats de vérification;

f) les résultats des essais d'acceptation.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphes 5.2.6.1 et 6.6.2.

4.4.4 Données d'entrée de la conception

Les exigences concernant le produit relatives aux données d'entrée de la conception et comprenant les
exigences légales et réglementaires applicables doivent être identifiées et consignées par écrit, et leur
sélection doit être revue par le fournisseur quant à leur adéquation. Il faut apporter une solution aux
exigences incomplètes, ambiguës ou incompatibles avec ceux qui les ont imposées.
Les données d'entrée de la conception doivent prendre en compte les résultats de toutes les activités de
revue de contrat.

Il convient que la spécification des besoins provienne du client. Cependant, le fournisseur peut, en cas d'accord
réciproque, fournir ces spécifications. Dans ce cas, lorsque cela est nécessaire, il convient que le fournisseur:

12
© ISO ISO 9000-3:1997(F)

a) formalise des procédures pour l'élaboration de la spécification des besoins, incluant

 des méthodes permettant de se mettre d'accord sur des exigences et d'autoriser les modifications,
essentiellement au cours du développement itératif,

 des méthodes permettant d'évaluer les prototypes ou les simulations, le cas échéant,

 l'enregistrement et la revue des résultats issus des discussions, pour chaque partie;

b) élabore la spécification des besoins en étroite collaboration avec le client et fasse des efforts pour éviter tout
malentendu en donnant par exemple la définition des termes et en expliquant le contexte conduisant aux
besoins;

c) obtienne l'approbation du client sur la spécification des besoins.

Entretiens, enquêtes, études, prototypes, simulations et méthodes d'analyse peuvent être utilisés, s'il y a lieu, dans
le but d'élaborer la spécification des besoins.

La spécification des besoins peut être élaborée et faire l'objet d'un accord sous forme de spécification de système.
Dans ce cas, il convient que les procédures soient mises en place pour assurer l'attribution adéquate des
exigences de système aux aspects matériels et logiciels ainsi que les spécifications appropriées des interfaces.

La spécification des besoins peut ne pas être complète au moment de l'acceptation du contrat: elle peut être
développée au cours d'un projet. Le contrat peut comprendre un avenant lorsque la spécification des besoins
évolue. Il convient alors d'en maîtriser les modifications.

Il est recommandé que les exigences comprennent tous les aspects nécessaires à la satisfaction des besoins du
client. Il se peut que la spécification des besoins doive prendre en compte l'environnement d'exploitation. Les
exigences peuvent comprendre, mais ne sont pas limitées à, la capacité fonctionnelle, la fiabilité, la facilité
d'utilisation, le rendement, la maintenabilité et la portabilité (voir l’ISO/CEI 9126). Des sous-caractéristiques peuvent
être spécifiées, par exemple en matière de sécurité. Les questions relatives à la sécurité des personnes ainsi que
les obligations réglementaires peuvent également être spécifiées.

Si le logiciel doit comporter des interfaces avec d'autres logiciels ou matériels, il convient de spécifier autant que
possible ces interfaces entre le logiciel à développer et les autres logiciels ou matériels, soit de manière directe, soit
par référence dans la spécification des besoins.

Il convient d'exprimer les besoins dans des termes qui permettent la validation au cours de l'acceptation du produit.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphes 5.3.2 à 5.3.4.

4.4.5 Données de sortie de la conception

Les données de sortie de la conception doivent être consignées par écrit et exprimées de façon à pouvoir
être vérifiées et validées par rapport aux données d'entrée de la conception.
Les données de sortie de la conception doivent
a) satisfaire aux exigences des données d'entrée de la conception;
b) contenir ou faire référence à des critères d'acceptation;
c) identifier les caractéristiques de conception critiques pour le fonctionnement correct et en toute
sécurité du produit (par exemple, les exigences en matière d'exploitation, stockage, manutention,
maintenance et mise hors service).
Les documents relatifs aux données de sortie de la conception doivent être revus avant leur mise en
circulation.

Il y a lieu de définir et de documenter les données de sortie requises pour chaque activité de conception,
conformément à la méthode choisie. Il est recommandé que cette documentation soit correcte, complète et
cohérente par rapport aux exigences. Les données de sortie de la conception peuvent inclure:

13
ISO 9000-3:1997(F) © ISO

 la spécification de la conception de l'architecture;

 la spécification de la conception détaillée;

 le code source;

 les manuels d’utilisation.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphes 5.3.5 à 5.3.7.

4.4.6 Revue de conception

Des revues formelles et consignées par écrit des résultats de la conception doivent être planifiées et
conduites à des phases appropriées de la conception. Les participants à chacune de ces revues doivent
comprendre des représentants de toutes les fonctions concernées par la phase de conception, objet de la
revue, ainsi que tout autre expert, comme requis. Des enregistrements de ces revues doivent être
conservés (voir 4.16).

Il convient que le fournisseur planifie et mette en œuvre des processus de revue pour tous les projets de
développement de logiciels. Le degré de formalisme et la rigueur des activités associées à ces processus
correspondent généralement à la complexité du produit et au degré de risque associé à l'utilisation spécifiée du
logiciel concerné. Il convient que le fournisseur établisse des procédures écrites pour traiter les dysfonctionnements
des processus et du produit ou les non-conformités identifiées au cours de ces activités.

Au cours des revues de conception, il convient de prendre en compte les aspects inhérents aux activités de
conception, par exemple la faisabilité et la sécurité, les règles de programmation, la testabilité.

Les résultats des revues et de toute autre activité nécessaire pour assurer que les exigences spécifiées sont
satisfaites, sont en général enregistrés et vérifiés une fois que ces actions sont réalisées.

La plupart des revues de conception entreprises au cours du développement sont planifiées; certaines revues de
conception non planifiées peuvent cependant avoir lieu.

Il convient qu'une procédure écrite de revue de conception traite des points suivants:

a) l'objet de la revue, son type et le moment où elle doit avoir lieu;

b) quels groupes fonctionnels sont concernés pour tel type de revue et, si une réunion de revue a lieu, qui va la
présider;

c) quels enregistrements sont à fournir, par exemple les comptes rendus de réunions, les points abordés, les
problèmes soulevés, les actions à entreprendre et l'état de leur avancement.

Les points suivants peuvent également figurer dans la procédure de revue de conception:

a) les méthodes permettant de surveiller l'application des règles, pratiques et conventions, comme les revues par
les pairs, les lectures croisées et les inspections de codes, de manière à assurer la conformité;

b) ce qui doit être réalisé avant de procéder à la revue, comme l'établissement des objectifs, de l'ordre du jour de
la réunion, des documents requis et du rôle des participants;

c) ce qui doit être fait au cours de la revue, incluant les techniques à utiliser et les recommandations à donner à
tous les participants;

d) les critères de succès de la revue;

e) les méthodes de suivi à utiliser pour assurer que les points identifiés lors de la revue sont résolus.

14
© ISO ISO 9000-3:1997(F)

Lorsque cela est spécifié dans le contrat, il est recommandé que le fournisseur organise des réunions de revue de
conception en étroite collaboration avec le client. Il convient que les deux parties se mettent d'accord sur les
résultats de telles revues.

Il est recommandé de poursuivre les activités de conception uniquement lorsque les effets des dysfonctionnements
détectés sont corrigés ou que le risque de poursuivre sans correction est connu.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphes 5.3.4.2, 5.3.5.6, 5.3.6.7 et 6.6.3.

4.4.7 Vérification de la conception

La vérification de la conception doit être effectuée à des phases appropriées de la conception afin
d'assurer que les données de sortie de chacune de ces phases satisfont aux exigences des données
d'entrée de cette même phase. Les actions de vérification de la conception doivent être enregistrées (voir
4.16).
NOTE 10 En plus des revues de conception (voir 4.4.6), la vérification de la conception peut comprendre des tâches
telles que
— l'exécution de calculs par d'autres méthodes;
— la comparaison de la nouvelle conception avec une conception similaire éprouvée si elle existe;
— la réalisation d'essais et de modèles de démonstration;
— la revue des documents relatifs aux différentes phases de la conception avant leur mise en circulation.

Il convient de procéder à la vérification de la conception, selon le cas, au cours du processus de développement. La


vérification de la conception peut comprendre des revues de données de sortie de la conception, des
démonstrations (y compris des prototypes et simulations), ou des essais. La vérification peut être menée sur des
données de sortie d'autres activités de développement. Il convient de planifier et de mener ces activités de
vérification conformément au plan qualité ou aux procédures écrites pour s'assurer que ces données de sortie du
processus satisfont aux exigences des données d'entrée.

Les résultats issus de la vérification, et toute autre action supplémentaire visant à assurer que les exigences des
données d'entrée en phase de conception sont satisfaites, sont généralement enregistrés et vérifiés, une fois ces
actions terminées.

Il y a lieu de ne soumettre à acceptation, et de n’en autoriser une utilisation ultérieure, que les données de sortie de
la conception qui ont été vérifiées. Il convient de traiter de manière adéquate et de résoudre toute anomalie.

NOTE Pour de plus amples informations, voir aussi l’ISO/CEI 12207:1995, paragraphes 5.3.4.2, 5.3.5.6, 5.3.5.7, 5.3.7.5,
5.3.9 et 6.4.

4.4.8 Validation de la conception

La validation de la conception doit être effectuée pour assurer que le produit est conforme aux besoins
et/ou aux exigences définis de l'utilisateur.
NOTE 11 Cette validation fait suite à une vérification satisfaisante de la conception (voir 4.4.7).
NOTE 12 La validation est effectuée normalement dans des conditions de fonctionnement définies.
NOTE 13 La validation est effectuée normalement sur le produit final, mais peut être nécessaire à des phases
antérieures à l'achèvement du produit.
NOTE 14 Des validations multiples peuvent être exécutées si différentes utilisations sont prévues.

Avant de présenter le logiciel au client pour acceptation, il convient que le fournisseur valide le produit
conformément aux spécifications, par exemple lors des contrôles et essais finals.

En matière de développement de logiciel, il est important que les résultats issus de la validation, et toute action
supplémentaire requise visant à assurer la satisfaction des besoins spécifiés, soient enregistrés et vérifiés une fois

15
ISO 9000-3:1997(F) © ISO

ces actions terminées. Il y a lieu de ne soumettre à acceptation, et de n’en autoriser une utilisation ultérieure, que
les produits qui ont été validés.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphes 5.3.1 et 6.5.

4.4.9 Modification de la conception

Tous les changements et toutes les modifications de la conception doivent être identifiés, consignés par
écrit, revus et approuvés par des personnes habilitées avant d'être mis en œuvre.

Il convient que le fournisseur établisse et tienne à jour des procédures permettant de maîtriser la mise en œuvre de
toute modification dans la conception, à n'importe quel moment du cycle de vie du produit, afin de:

a) documenter et justifier les modifications;

b) évaluer les conséquences des modifications;

c) approuver ou contester ces modifications;

d) réaliser et vérifier ces modifications.

Dans l'environnement du développement du logiciel, la maîtrise des modifications de la conception est


généralement assurée par la gestion de la configuration.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphes 5.5.2, 5.5.3 et 6.2.3.

4.5 Maîtrise des documents et des données

4.5.1 Généralités

Le fournisseur doit établir et tenir à jour des procédures écrites pour maîtriser tous les documents et les
données relatifs aux exigences de la présente Norme internationale, y compris, dans les limites de ce qui
est applicable, des documents d'origine extérieure tels que les normes et les plans du client.
NOTE 15 Les documents et les données peuvent se présenter sur tout support, tel que support papier ou support
informatique.

Des procédures de gestion de la configuration peuvent être utilisées pour mettre en œuvre la maîtrise des
documents et des données. En établissant de telles procédures, il convient que le fournisseur identifie les données
et documents, y compris ceux d'origine externe tels que les normes et les données du client, qui rentrent
généralement dans le cadre de telles procédures.

Il convient que ces procédures soient appliquées aux données et documents appropriés tels que:

a) les documents contractuels, y compris la spécification des besoins;

b) les procédures décrivant le système qualité à appliquer au cours du cycle de vie du logiciel;

c) les documents de planification décrivant le calendrier et l'avancement des activités du fournisseur ainsi que les
interactions du fournisseur avec le client;

d) les documents et données décrivant, ou associés à, un logiciel.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphe 6.1.

16
© ISO ISO 9000-3:1997(F)

4.5.2 Approbation et diffusion des documents et des données

Avant leur diffusion, les documents et les données doivent être revus et approuvés en ce qui concerne leur
adéquation, par des personnes habilitées. Une liste de référence ou toute procédure de maîtrise de
documents équivalente indiquant la révision en vigueur des documents doit être établie et être facilement
accessible pour empêcher l'utilisation de documents non valables et/ou périmés.
Cette maîtrise doit assurer que
a) les éditions pertinentes des documents appropriés sont disponibles à tous les endroits où des
opérations essentielles au fonctionnement efficace du système qualité sont effectuées;
b) les documents non valables et/ou périmés sont aussitôt retirés de tous les points de diffusion ou
d'utilisation, ou sinon qu'ils ne peuvent pas être utilisés de façon non intentionnelle;
c) tout document périmé conservé à des fins légales ou de conservation des connaissances est
convenablement identifié.

Lorsque la maîtrise des documents est assurée par des moyens électroniques, il convient de veiller à mettre en
place des procédures appropriées d'approbation, d'accès, de diffusion, de support et d'archivage.

4.5.3 Modification des documents et des données

Les modifications des documents et des données doivent être revues et approuvées par les mêmes
fonctions/organismes qui les ont revus et approuvés à l'origine, à moins qu'il n'en soit spécifié autrement.
Les fonctions/organismes désignés doivent avoir accès à toutes informations appropriées sur lesquelles ils
peuvent fonder leur revue et leur approbation.
Lorsque cela est réalisable, la nature de la modification doit être identifiée dans le document ou dans les
annexes appropriées.

Il n’y a aucune recommandation particulière concernant le logiciel.

4.6 Achats

4.6.1 Généralités

Le fournisseur doit établir et tenir à jour des procédures écrites pour assurer que le produit acheté (voir 3.1)
est conforme aux exigences spécifiées.

Lors du développement, de la mise à disposition, de l'installation et de la maintenance d'un logiciel, les produits
achetés peuvent comprendre:

 un logiciel commercial standard;

 la sous-traitance d'un développement;

 du matériel informatique et de communication;

 un outil de développement du logiciel;

 la mise à disposition de personnel externe;

 des services de maintenance et d'assistance technique;

 de la formation et des supports de formation.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphe 5.1.

17
ISO 9000-3:1997(F) © ISO

4.6.2 Évaluation des sous-contractants

Le fournisseur doit
a) évaluer et sélectionner les sous-contractants sur la base de leur aptitude à satisfaire aux exigences de
la sous-commande, y compris les exigences de système qualité et toutes exigences spécifiques
d'assurance de la qualité;
b) définir le type et l'étendue de la maîtrise exercée par le fournisseur sur ses sous-contractants. Celle-ci
doit dépendre du type de produit commandé au sous-contractant, de l'incidence de ce produit sur la
qualité du produit final et, lorsque cela est applicable, des rapports d'audits qualité et/ou des
enregistrements relatifs à la qualité des sous-contractants relatifs aux aptitudes et performances dont
le sous-contractant a fait la démonstration précédemment;
c) établir, tenir à jour et conserver des enregistrements relatifs à la qualité des sous-contractants
acceptables (voir 4.16).

Il n’y a aucune recommandation particulière concernant le logiciel.

4.6.3 Données d'achat

Les documents d'achat doivent contenir des données décrivant clairement le produit commandé et
comprenant, lorsque cela est applicable,
a) le type, la catégorie, la classe ou toute autre identification précise;
b) le titre ou toute autre identification formelle et l'édition applicable des spécifications, plans, exigences
en matière de processus, instructions de contrôle et autres données techniques pertinentes, y compris
les exigences pour l'approbation ou la qualification du produit, des procédures, de l'équipement et du
personnel relatifs au processus;
c) le titre, le numéro et l'édition de la norme de système qualité à appliquer.
Le fournisseur doit revoir et approuver les documents d'achat en ce qui concerne l'adéquation des
exigences spécifiées avant de les diffuser.

Il convient que les documents d'achat en vue du développement d'un logiciel contiennent des données décrivant
clairement le produit acheté, y compris, lorsque cela est applicable:

a) l'identification précise du produit acheté, comme le nom et/ou le numéro du produit;

b) la spécification des besoins, ou son identifiant (ou la procédure permettant d'identifier la spécification des
besoins lorsqu'elle n'a pas été fournie au moment de la passation de commande);

c) les normes à appliquer (par exemple, les protocoles de communication, la spécification de l'architecture);

d) les procédures et/ou instructions de travail;

e) l'environnement de développement;

f) les exigences concernant le personnel.

Les points concernant la revue de contrat peuvent également s'appliquer aux contrats de sous-traitance.

18
© ISO ISO 9000-3:1997(F)

4.6.4 Vérification du produit acheté

4.6.4.1 Vérification par le fournisseur chez le sous-contractant

Lorsque le fournisseur a l'intention de vérifier le produit acheté chez le sous-contractant, il doit spécifier
dans les documents d'achat les dispositions à prendre pour la vérification et les modalités de mise à
disposition du produit.

Il n’y a aucune recommandation particulière concernant le logiciel.

4.6.4.2 Vérification par le client du produit sous-contracté

Lorsque cela est spécifié dans le contrat, le client du fournisseur ou son représentant doit avoir le droit de
vérifier dans les locaux du sous-contractant et du fournisseur que le produit sous-contracté est conforme
aux exigences spécifiées. Cette vérification ne doit pas être utilisée par le fournisseur comme preuve de la
maîtrise effective de la qualité par le sous-contractant.
La vérification par le client ne doit pas décharger le fournisseur de sa responsabilité de fournir un produit
acceptable, ni empêcher un rejet ultérieur du produit par le client.

Il n’y a aucune recommandation particulière concernant le logiciel.

4.7 Maîtrise du produit fourni par le client

Le fournisseur doit établir et tenir à jour des procédures écrites pour la vérification, le stockage et la
préservation du produit fourni par le client pour être incorporé dans les fournitures ou pour des activités qui
y sont liées. Tout produit de cette nature perdu, endommagé ou encore impropre à l'utilisation doit être
enregistré et le client doit en être informé (voir 4.16).
La vérification par le fournisseur ne décharge pas le client de sa responsabilité de fournir un produit
acceptable.

Le fournisseur peut se voir obligé d'acquérir et d'intégrer un produit, y compris des données, fournis par le client. En
voici quelques exemples:

a) des logiciels, y compris des logiciels commerciaux fournis par le client;

b) des outils de développement;

c) un environnement de développement, y compris des fonctions réseaux;

d) des jeux d'essai et des données d'exploitation;

e) une interface ou d'autres spécifications;

f) du matériel;

g) des informations détenues par le client, y compris des spécifications.

Il convient, dans tout accord de maintenance relatif au produit à livrer, de veiller particulièrement aux exigences du
contrat en matière de licence et au support qui accompagne un tel logiciel.

Il convient de définir la façon dont les mises à jour des composants fournis par le client sont reçues et intégrées. Le
fournisseur peut procéder aux mêmes types d'activités de vérification sur le produit fourni par le client que sur le
produit acheté.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphe 6.1.

19
ISO 9000-3:1997(F) © ISO

4.8 Identification et traçabilité du produit

Lorsque cela est approprié, le fournisseur doit établir et tenir à jour des procédures écrites pour
l'identification du produit à l'aide de moyens adéquats, de la réception jusqu'à la livraison et l'installation,
ainsi qu'au cours de toutes les phases de production.
Lorsque et dans la mesure où la traçabilité est une exigence spécifiée, le fournisseur doit établir et tenir à
jour des procédures écrites pour l'identification unique de produits ou de lots particuliers. Cette identification
doit être enregistrée (voir 4.16).

Il convient que le fournisseur établisse et tienne à jour des procédures permettant d'identifier les composants du
logiciel au cours de toutes les phases, depuis la spécification jusqu'à la livraison, en passant par le développement
et la reproduction. Lorsque cela est exigé dans le contrat, ces procédures peuvent également s'appliquer après
livraison du produit.

Tout au long du cycle de vie du produit, il convient de disposer de procédures pour garder la trace des composants
du logiciel ou du produit. La couverture de cette trace peut varier en fonction des exigences du contrat ou du
marché: cela va de savoir rattacher une demande de modification à une version spécifique, à enregistrer la
destination et l'utilisation de chaque variante du produit.

Dans le domaine du logiciel, la gestion de la configuration est un des moyens permettant d'obtenir l'identification et
la traçabilité. La gestion de la configuration consiste à appliquer des procédures administratives et techniques tout
au long du cycle de vie du logiciel. Cette activité est également applicable à la documentation et au matériel
associés. L'utilisation de la gestion de la configuration dépend de la taille et de la complexité du projet ainsi que du
niveau de risques.

Un des objectifs de la gestion de la configuration est de documenter et de donner une bonne visibilité sur la
configuration du produit ainsi que sur l'état de la couverture des besoins. Un autre objectif est l'utilisation
d'informations correctes et précises par toute personne travaillant sur le projet à un moment quelconque de son
cycle de vie.

Un système de gestion de la configuration peut permettre:

a) d'identifier de façon univoque les versions de chaque composant de logiciel;

b) d'identifier les versions de chacun des composants du logiciel qui, ensemble, constituent une version
spécifique d'un produit complet;

c) d'identifier l'état de finition des logiciels en cours de développement, livrés ou installés;

d) de maîtriser la mise à jour simultanée d'un composant de logiciel donné par une ou plusieurs personnes qui
travaillent indépendamment l'une de l'autre;

e) d'assurer la coordination de la mise à jour de produits différents en un ou plusieurs lieux, si nécessaire;

f) d'identifier et de suivre toutes les actions et modifications résultant d'une demande de modification ou d'un
problème, depuis sa formulation jusqu'à la mise à disposition de la version.

Il convient que le fournisseur identifie la configuration grâce aux éléments suivants:

a) la structure du produit et la sélection des éléments de configuration;

b) la documentation et les fichiers informatiques;

c) les règles de nommage;

d) l'établissement de référentiels de configuration.

20
© ISO ISO 9000-3:1997(F)

Les produits pouvant être traités par un système de gestion de la configuration comprennent:

a) des documents et données faisant partie du contrat, du processus, de la planification et du produit;

b) les codes sources, codes objets et codes exécutables;

c) des produits intégrés comprenant:

 des outils logiciels,

 des logiciels réutilisés, y compris des bibliothèques,

 des logiciels achetés,

 des logiciels fournis par le client.

Il convient que des procédures soient appliquées pour assurer que les points suivants puissent être identifiés pour
chaque composant du logiciel:

a) la documentation;

b) tout outil de développement associé;

c) les interfaces avec d'autres composants de logiciels et de matériels;

d) l'environnement matériel et logiciel.

Il convient que le fournisseur établisse et tienne à jour des procédures de vérification de l'état de la configuration
dans le but d'enregistrer, de gérer et de rendre compte de l'état des composants du logiciel, des demandes de
modifications et de la mise en œuvre des modifications qui ont été approuvées.

Il convient que le fournisseur développe et mette en œuvre un plan de gestion de la configuration qui comprenne
les points suivants:

a) les organismes impliqués dans la gestion de la configuration et les responsabilités qui sont attribuées à chacun
d'entre eux;

b) les activités de gestion de la configuration à mener;

c) les outils, techniques et méthodes de gestion de la configuration à utiliser;

d) le moment où il convient d'appliquer la gestion de la configuration aux différents composants.

NOTE Pour de plus amples informations concernant la gestion de la configuration, se reporter à l’ISO 10007 et à
l’ISO/CEI 12207:1995, paragraphes 6.1 et 6.2.

21
ISO 9000-3:1997(F) © ISO

4.9 Maîtrise des processus

Le fournisseur doit identifier et planifier les processus de production, d'installation et les processus relatifs
aux prestations associées qui ont une incidence directe sur la qualité, et il doit aussi assurer que ces
processus sont mis en œuvre dans des conditions maîtrisées. Ces dernières doivent comprendre
a) des procédures écrites définissant les pratiques de production, d'installation et les pratiques relatives
aux prestations associées lorsque l'absence de ces procédures pourrait avoir une incidence néfaste
sur la qualité;
b) l'utilisation d'équipements adéquats pour la production, l'installation et les prestations associées, ainsi
qu'un environnement de travail approprié;
c) la conformité aux normes et codes de référence, aux plans qualité et/ou aux procédures écrites;
d) le pilotage et la maîtrise des paramètres des processus et des caractéristiques du produit appropriés;
e) l'approbation des processus et de l'équipement, s'il y a lieu;
f) les critères d'exécution qui doivent être prescrits le plus clairement possible (par exemple au moyen de
normes écrites, d'échantillons représentatifs ou d'illustrations);
g) la maintenance appropriée de l'équipement de manière à assurer en permanence l'aptitude des
processus.
Quand les résultats des processus ne peuvent pas être entièrement vérifiés par des contrôles et des
essais du produit effectués a posteriori et pour lesquels, par exemple, des déficiences peuvent n'apparaître
qu'en cours d'utilisation du produit, les processus doivent être conduits par des opérateurs qualifiés et/ou
doivent exiger un pilotage continu des opérations et la maîtrise permanente des paramètres de processus,
de manière à assurer leur conformité aux exigences spécifiées.
Les exigences relatives à la qualification des processus, y compris l'équipement et le personnel associés
(voir 4.18), doivent être spécifiées.
NOTE 16 De tels processus qui nécessitent une préqualification de leur aptitude sont souvent appelés procédés
spéciaux.
Des enregistrements doivent être conservés pour les processus, équipements et personnels qualifiés, s'il y
a lieu (voir 4.16).

Comme indiqué dans les recommandations concernant le point «maîtrise de la conception» de l’ISO 9001, il
convient qu’un projet de développement de logiciel soit organisé selon un ensemble de processus qui transforment
les besoins en un logiciel. Le point «maîtrise des processus», tel qu'il est appliqué au développement du logiciel, est
applicable à la reproduction, à la livraison et à l'installation de composants du logiciel ou de produits.

Lorsque cela est spécifié dans le contrat, il convient que le fournisseur établisse et suive les procédures de
reproduction, en prenant en compte les éléments suivants, pour assurer que la reproduction est réalisée
correctement:

a) l'identification de l'original et des copies, y compris le format, la variante et la version;

b) le nombre de copies de chaque composant du logiciel devant être livrées;

c) des plans antisinistres, y compris la conservation de l'original et de copies de sauvegarde, lorsque cela est
nécessaire;

d) la période d'obligation du fournisseur de fournir des copies ainsi que sa capacité à lire les originaux;

e) le type de support pour chaque composant du logiciel et l'étiquetage associé;

f) des vérifications pour prévenir l'apparition de virus;

g) la mention de la documentation exigée, telle que les manuels et guides utilisateur, y compris l'identification et le
conditionnement;

22
© ISO ISO 9000-3:1997(F)

h) les problèmes concernant le droit de reproduction et les licences, qui ont été abordés et qui ont fait l'objet d'un
accord;

i) la maîtrise de l'environnement dans le cadre duquel la reproduction est effectuée, afin d'assurer la répétabilité.

Pour toute fourniture de version de logiciel, il convient que le fournisseur et le client se mettent d'accord sur des
procédures en vue de traiter les fournitures de versions initiales et ultérieures, et les documentent.

Il convient que la fourniture de version de logiciel comporte un référentiel de configuration permettant de déterminer
quels essais ont été entièrement réalisés ainsi que la solution apportée aux déficiences identifiées. Une analyse
quantitative, dans le but d'estimer la fiabilité du système, peut être menée pour des logiciels comportant des
exigences de sûreté et/ou de sécurité.

Il convient que ces procédures comprennent les éléments suivants:

a) les descriptions de types (ou de classes) des versions, en fonction de la fréquence et/ou de l'impact sur
l'exploitation du client et sa capacité à mettre en œuvre des modifications à un moment quelconque;

b) les méthodes selon lesquelles le client sera avisé des modifications actuelles ou futures déjà planifiées;

c) des méthodes pour confirmer que les modifications mises en œuvre n'engendreront pas d'autres problèmes;
de telles méthodes comprennent généralement la détermination du niveau des essais de non-régression à
appliquer à chaque version;

d) des règles de base pour déterminer si des solutions temporaires localisées peuvent être intégrées ou si une
mise à jour complète du logiciel est nécessaire;

e) des exigences pour les enregistrements indiquant les modifications mises en œuvre, ainsi que leur localisation
en cas de produits ou de sites multiples.

Lorsque l'installation du logiciel est prévue dans le contrat, il convient que le fournisseur et le client se mettent
d'accord sur leurs rôles, responsabilités et obligations respectifs; il convient que de tels accords soient documentés.
Lors de l'installation, il convient de prendre en compte les aspects suivants:

a) la nécessité de valider chaque installation exigée dans le contrat;

b) une procédure d'installation;

c) une procédure d'approbation de chaque installation achevée;

d) un calendrier;

e) l'accès aux installations du client (par exemple badges de sécurité, mots de passe, accompagnateurs);

f) la disponibilité du personnel qualifié;

g) la disponibilité et l'accès aux systèmes et équipements du client;

h) l'identification de ce que le client doit fournir sur le site;

i) la formation en vue de l'utilisation des nouvelles installations.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphes 5.3.12 et 6.3.3.

23
ISO 9000-3:1997(F) © ISO

4.10 Contrôles et essais

4.10.1 Généralités

Le fournisseur doit établir et tenir à jour des procédures écrites pour les opérations de contrôles et d'essais
afin de vérifier que les exigences spécifiées pour le produit sont respectées. Les contrôles et essais requis
ainsi que les enregistrements à effectuer doivent figurer dans le plan qualité ou dans des procédures
écrites.

Il peut s'avérer nécessaire de procéder à des essais à plusieurs niveaux, depuis un composant isolé jusqu'au
logiciel complet. Il existe différentes façons d'aborder les essais; en outre, leur étendue, le degré de maîtrise de leur
environnement, leurs données d'entrée et de sortie peuvent varier en fonction de l'approche, de la complexité du
produit ainsi que des risques. Des essais logiciels sont également réalisés au cours de l'intégration du logiciel. Les
techniques décrites sous l'intitulé «revue de conception» peuvent également se révéler pertinentes au cours des
activités d'essais.

Il convient que le fournisseur établisse par écrit et procède à la revue de plans pour les essais unitaires,
d'intégration, du système et d'acceptation, conformément au plan qualité ou aux procédures documentées, qui
traitent, s'il y a lieu:

a) des objectifs des essais;

b) des configurations à soumettre à l'essai;

c) des types d'essais à réaliser, tels que les essais fonctionnels, les essais aux limites, les essais de performance
et les essais d'aptitude à l'emploi;

d) de l'ordre des essais, des jeux d’essais, des procédures d'essais, des données d'essais et des résultats
attendus;

e) du champ des essais à réaliser, en termes de couverture et de volume;

f) de la pertinence des essais par rapport aux objectifs en matière d’essais et au fonctionnement opérationnel;

g) des problèmes particuliers tels que la sûreté et la sécurité;

h) de l'environnement d'essai, des outils et logiciels d'essai, y compris toute qualification et toute maîtrise
associée;

i) des essais de la documentation utilisateur;

j) du personnel requis et des exigences concernant la formation associée, y compris les supports de formation;

k) du degré d'indépendance entre le personnel développant les logiciels et le personnel réalisant les essais;

l) des responsabilités en matière de spécification et de réalisation des essais;

m) des critères d'achèvement des essais;

n) de la méthode d'enregistrement des résultats;

o) des procédures d'analyse et d'approbation des résultats;

p) des procédures permettant de traiter les problèmes détectés lors de l'exécution des essais, y compris les
critères de suspension et les exigences de reprise des essais;

24
© ISO ISO 9000-3:1997(F)

q) de la nécessité de procéder à des essais de non-régression ainsi que de leur étendue;

r) de la répétabilité des essais.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphes 5.1.5, 5.3.5.5, 5.3.6.5, 5.3.6.6, 5.3.7,
5.3.11 et 5.3.13.

4.10.2 Contrôle et essais à la réception

4.10.2.1 Le fournisseur doit assurer que le produit entrant n'est ni utilisé, ni mis en œuvre (sauf dans les
cas décrits en 4.10.2.3) tant qu'il n'a pas été contrôlé ou tant que sa conformité aux exigences spécifiées
n'a pas été vérifiée d'une autre manière. La vérification de la conformité aux exigences spécifiées doit être
effectuée conformément au plan qualité et/ou aux procédures écrites.
4.10.2.2 Lors de la détermination de l'importance et de la nature des contrôles à la réception, il faut
prendre en considération l'importance du contrôle exercé dans les locaux des sous-contractants et le fait
qu'une preuve enregistrée de la conformité a été fournie.
4.10.2.3 Lorsque, pour des raisons d'urgence, le produit entrant est lancé en production avant d'être
vérifié, il doit être identifié de façon formelle et enregistré (voir 4.16) afin de permettre son rappel immédiat
et son remplacement dans le cas de non-conformité aux exigences spécifiées.

Il peut être demandé au fournisseur d'acquérir et d'intégrer un logiciel, y compris des données, fourni par une tierce
partie. Il convient que le fournisseur établisse et tienne à jour des procédures documentées pour la vérification (à la
réception) d'un tel logiciel, en prenant en compte les exigences du contrat.

Le fournisseur peut réaliser les mêmes types d'activités de vérification sur le produit fourni par le client que sur le
produit acheté.

4.10.3 Contrôles et essais en cours de réalisation

Le fournisseur doit
a) contrôler le produit et faire des essais conformément au plan qualité et/ou aux procédures écrites;
b) bloquer le produit jusqu'à ce que les contrôles et les essais requis soient terminés ou jusqu'à ce que
les rapports nécessaires aient été reçus et vérifiés, excepté lorsque le produit est mis en circulation
conformément à des procédures de rappel préétablies (voir 4.10.2.3). La mise en circulation suivant
ces procédures ne doit pas empêcher de mener les activités prévues en 4.10.3 a).

Les considérations générales propres aux essais s'appliquent.

4.10.4 Contrôles et essais finals

Le fournisseur doit effectuer tous les contrôles et essais finals conformément au plan qualité et/ou aux
procédures écrites afin de démontrer la conformité du produit fini aux exigences spécifiées.
Le plan qualité et/ou les procédures écrites pour les contrôles et les essais finals doivent exiger que tous
les contrôles et essais spécifiés, y compris ceux spécifiés à la réception du produit ou pendant sa
réalisation, aient été menés à bien et que les résultats satisfassent aux exigences spécifiées.
Aucun produit ne doit être expédié avant que toutes les activités spécifiées dans le plan qualité et/ou dans
les procédures écrites aient été accomplies de façon satisfaisante et que les données et la documentation
qui y sont associées soient disponibles et acceptées.

Avant de présenter le produit au client pour acceptation, il convient que le fournisseur valide l'exploitation du produit
en fonction de son utilisation prévue spécifiée, dans des conditions similaires à l'environnement d'application,
comme spécifié dans le contrat. Toute différence entre l'environnement de validation et l'environnement réel
d'application, ainsi que les risques qui y sont associés, sont généralement identifiés et justifiés aussi tôt que
possible dans le cycle de vie, et enregistrés.

25
ISO 9000-3:1997(F) © ISO

Au cours de la validation, des audits de configuration ou des évaluations peuvent être réalisés lorsque cela est
nécessaire, avant la présentation d'un référentiel de configuration; l'examen des enregistrements de la revue, des
inspections et des essais permet de confirmer que le logiciel satisfait aux exigences contractuelles ou spécifiées.

Lors de l'étude de l'environnement d’essai, il convient d'aborder les points suivants:

a) les caractéristiques à tester;

b) la maîtrise de l'environnement d'essais, y compris des outils d'essai;

c) toute limitation aux essais imposée par l'environnement.

Lorsque des essais sur l'environnement cible sont requis, il convient d'aborder les points suivants:

a) les responsabilités spécifiques du fournisseur et du client pour mener et évaluer l'essai;

b) le rétablissement de l'environnement utilisateur (après essai).

Un soutien aux essais d'acceptation peut être exigé lorsque le fournisseur est prêt à livrer le produit validé. Il est
recommandé que le client juge si le produit est acceptable ou non selon les critères préalablement convenus et de
la manière spécifiée dans le contrat. Il convient que les essais d'acceptation soient réalisés par le client; ils peuvent
également être réalisés par le fournisseur ou une tierce partie, pour le compte du client. Il convient que le
fournisseur collabore avec le client en ce qui concerne les activités d'acceptation, comme stipulé dans le contrat.

Lorsque le contrat exige que les essais d'acceptation soient réalisés par le fournisseur, on peut considérer qu'ils
font partie des contrôles et essais finals, ainsi que de la validation. Dans certains cas, la validation, les essais sur
site et les essais d'acceptation peuvent constituer une seule et même activité.

Avant de mener les activités d'acceptation, il convient que le fournisseur aide le client à identifier les points suivants:

a) l'échéancier;

b) les procédures d'évaluation, y compris les critères d'acceptation;

c) les environnements matériels/logiciels, y compris leur maîtrise;

d) les ressources humaines nécessaires et la formation associée.

La méthode visant à gérer les problèmes détectés au cours de la procédure d'acceptation et à les traiter fait en
général l'objet d'un accord documenté entre le client et le fournisseur.

4.10.5 Enregistrement des contrôles et essais

Le fournisseur doit établir et conserver des enregistrements apportant la preuve que le produit a subi des
contrôles et /ou des essais. Ces enregistrements doivent montrer clairement si le produit a satisfait ou non
aux contrôles et/ou aux essais conformément à des critères d'acceptation définis. Lorsque le produit ne
passe pas avec succès les contrôles et/ou les essais, les procédures de maîtrise du produit non conforme
doivent s'appliquer (voir 4.13).
Les enregistrements doivent identifier la personne habilitée pour le contrôle et la mise en circulation du
produit (voir 4.16).

Il convient que le fournisseur s'assure que les résultats des essais sont enregistrés comme définis dans la
spécification correspondante.

26
© ISO ISO 9000-3:1997(F)

4.11 Maîtrise des équipements de contrôle, de mesure et d'essai

4.11.1 Généralités

Le fournisseur doit établir et tenir à jour des procédures écrites pour maîtriser, étalonner et maintenir en
état les équipements de contrôle, de mesure et d'essai (y compris les logiciels d'essais) utilisés par le
fournisseur pour démontrer la conformité du produit aux exigences spécifiées. Les équipements de
contrôle, de mesure et d'essai doivent être utilisés de façon à assurer que l'incertitude de mesure est
connue et compatible avec l'aptitude requise en matière de mesurage.
Lorsque des logiciels d'essai ou des références de comparaison, tels que des matériels d'essai, sont
utilisés comme moyens de contrôle appropriés, ils doivent être vérifiés pour démontrer qu'ils sont capables
de contrôler que le produit est acceptable, avant sa mise en circulation pour utilisation lors de la production,
de l'installation ou des prestations associées, et doivent être vérifiés de nouveau aux intervalles prescrits.
Le fournisseur doit fixer l'étendue et la fréquence de telles vérifications et conserver des enregistrements
comme preuve de sa maîtrise des équipements considérés (voir 4.16).
Lorsque la disponibilité des données techniques relatives aux équipements de contrôle, mesures et d'essai
est une exigence spécifiée, et dans les limites de cette exigence, de telles données doivent être mises à la
disposition du client ou de son représentant, à leur demande, afin de vérifier que les équipements de
mesure conviennent sur le plan fonctionnel.
NOTE 17 Pour les besoins de la présente Norme internationale, le terme équipement de mesure comprend les
appareils et instruments de mesure.

Lorsque le fournisseur utilise des outils, installations et techniques lors de la réalisation des essais visant à vérifier
la conformité du logiciel aux besoins spécifiés, il est recommandé que le fournisseur tienne compte de l'effet de tels
outils sur la qualité du logiciel au moment d'approuver les résultats de ces tests. En outre, de tels outils peuvent
être pris en charge par la gestion de la configuration avant utilisation.

Il est recommandé que le champ d'application des outils et techniques d'essai soit formalisé et que leur utilisation
soit régulièrement évaluée, afin de déterminer s'il est nécessaire de les améliorer et/ou de les mettre à jour.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphe 7.2.

27
ISO 9000-3:1997(F) © ISO

4.11.2 Procédure de maîtrise

Le fournisseur doit:
a) déterminer les mesurages à effectuer, l'exactitude requise et sélectionner l'équipement de contrôle, de
mesure et d'essai approprié capable d'apporter l'exactitude et la précision nécessaires;
b) identifier tous les équipements de contrôle, de mesure et d'essai qui peuvent avoir une influence sur la
qualité du produit; les étalonner et les régler aux intervalles prescrits, ou avant utilisation, par rapport à
des équipements certifiés reliés de façon valable à des étalons reconnus au plan international ou
national. Lorsque ces étalons n'existent pas, la référence utilisée pour l'étalonnage doit faire l'objet
d'une description écrite;
c) définir le processus utilisé pour l'étalonnage des équipements de contrôle, de mesure et d'essai en
détaillant le type d'équipement, l'identification spécifique, l'emplacement, la fréquence des vérifications,
la méthode de vérification, les critères d'acceptation et l'action à entreprendre lorsque les résultats ne
sont pas satisfaisants;
d) identifier les équipements de contrôle, de mesure et d'essai avec un marquage approprié ou un
enregistrement d'identification approuvé pour indiquer la validité de l'étalonnage;
e) conserver des enregistrements d'étalonnage pour les équipements de contrôle, de mesure et d'essai
(voir 4.16);
f) évaluer et consigner par écrit la validité de résultats de contrôle et d'essai antérieurs lorsque les
équipements de contrôle, de mesure et d'essai s'avèrent être en dehors des limites fixées pour
l'étalonnage;
g) assurer que les conditions d'environnement sont appropriées pour la réalisation des étalonnages,
contrôles, mesures et essais;
h) assurer que la manutention, la préservation et le stockage des équipements de contrôle, de mesure et
d'essai sont tels que l'exactitude et l'aptitude à l'emploi sont maintenues;
i) protéger les moyens de contrôle, de mesure et d'essai, y compris les matériels et les logiciels d'essai,
contre des manipulations qui invalideraient les réglages d'étalonnage.
NOTE 18 Les exigences en matière d'assurance de la qualité des équipements de mesure données dans
l'ISO 10012 peuvent être utilisées en tant que guide.

L'étalonnage est une technique de vérification qui n'est pas directement applicable au logiciel. Néanmoins, elle peut
s'appliquer aux matériels et outils utilisés pour tester et valider le logiciel. Par conséquent, les points b) à f)
énumérés ci-dessus ne sont pas applicables au logiciel lui-même mais peuvent l'être à l'environnement utilisé pour
tester le logiciel.

4.12 État des contrôles et des essais

L'état des contrôles et des essais du produit doit être identifié par des moyens appropriés qui indiquent la
conformité ou la non-conformité du produit par rapport aux contrôles et essais effectués. L'identification de
l'état des contrôles et des essais doit être tenue à jour, conformément au plan qualité et/ou aux procédures
écrites, tout au long de la réalisation, de l'installation du produit et des prestations associées, afin d'assurer
que seul le produit qui a subi avec succès les contrôles et essais requis [ou a été mis en circulation par
dérogation autorisée (voir 4.13.2)] est expédié, utilisé ou installé.

Il convient que le fournisseur dispose de moyens d'identification du stade de développement des composants du
produit ainsi que l'état d'essai de ces composants. Par exemple: non testé, testé avec erreur, testé avec succès ou
approuvé pour mise à disposition pour toute autre activité du développement. La création d'états d'avancement ou
le passage des composants du logiciel de l'environnement de développement, à celui d'essais puis à celui
d'exploitation peut servir à indiquer la nature de leur état. Les enregistrements concernant les contrôles et essais
peuvent être utilisés pour identifier l'état des contrôles et essais.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphe 6.2.

28
© ISO ISO 9000-3:1997(F)

4.13 Maîtrise du produit non conforme

4.13.1 Généralités

Le fournisseur doit établir et tenir à jour des procédures écrites afin d'assurer que tout produit non
conforme aux exigences spécifiées ne puisse être utilisé ou livré de façon non intentionnelle. Cette maîtrise
doit comprendre l'identification, la documentation, l'évaluation, l'isolement (lorsqu'il est possible), le
traitement du produit non conforme et la notification aux fonctions concernées.

En matière de développement logiciel, l'isolement des composants non conformes peut être réalisé par le passage
de ces composants d'un environnement de production ou d'essai vers un environnement dédié. Dans le cas d'un
logiciel intégré, il peut se révéler nécessaire d'isoler le composant (matériel) non conforme, qui contient le logiciel
non conforme.

Il est recommandé que le fournisseur identifie à quels moments du développement il est nécessaire de maîtriser et
d'enregistrer un produit non conforme. Lorsqu'un composant du logiciel révèle un défaut durant le développement
ou la maintenance, il est recommandé de maîtriser et d'enregistrer l'analyse de ces défauts ainsi que leur
résolution.

Un processus de gestion de la configuration peut être mis en œuvre pour répondre en partie ou en totalité à cette
exigence.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphes 6.2 et 6.8.

4.13.2 Examen et traitement du produit non conforme

La responsabilité relative à l'examen et à la décision pour le traitement du produit non conforme doivent
être définies.
Le produit non conforme doit être examiné selon des procédures écrites. Il peut être
a) repris pour satisfaire aux exigences spécifiées;
b) accepté par dérogation avec ou sans réparation;
c) déclassé pour d'autres applications, ou bien
d) rejeté ou mis au rebut.
Si le contrat l'exige, la proposition d'utilisation ou de réparation du produit [voir 4.13.2 b)] qui n'est pas
conforme aux exigences spécifiées doit être présentée pour dérogation au client ou à son représentant. La
description de la non-conformité qui a été acceptée et des réparations doit être enregistrée pour indiquer
l'état réel (voir 4.16).
Le produit réparé et/ou repris doit être contrôlé de nouveau conformément aux exigences du plan qualité
et/ou des procédures écrites.

Il convient de porter attention aux aspects suivants lors du traitement des non-conformités:

a) il convient de noter tous les problèmes recensés et leur impact potentiel sur les autres parties du logiciel et d'en
informer les personnes responsables, dans le but de suivre les problèmes jusqu'à ce qu'ils soient résolus;

b) il convient d'identifier les parties du logiciel touchées par des modifications, et de procéder à nouveau aux tests
sur ces parties; il convient également de décrire dans une procédure la méthode utilisée pour déterminer le
domaine de couverture des essais à réexécuter;

c) les priorités en matière de non-conformités.

Dans le cas du logiciel, la correction ou reprise du développement visant à satisfaire les besoins spécifiés génère
une nouvelle version de ce logiciel. Dans le cas du développement du logiciel, il existe plusieurs façons de traiter le
produit non conforme:

29
ISO 9000-3:1997(F) © ISO

a) la correction ou la reprise (par exemple l'élimination des défauts), de façon à satisfaire aux besoins;

b) l'acceptation, avec ou sans correction, par dérogation;

c) le traitement en tant que produit conforme après amendement des exigences;

d) le rejet.

4.14 Actions correctives et préventives

4.14.1 Généralités

Le fournisseur doit établir et tenir à jour des procédures écrites pour mettre en œuvre des actions
correctives et préventives.
Toute action corrective ou préventive conduite pour éliminer les causes des non-conformités réelles ou
potentielles doit l'être à un niveau correspondant à l'importance des problèmes et en rapport avec les
risques encourus.
Le fournisseur doit mettre en œuvre et enregistrer toutes les modifications des procédures écrites qui
résultent des actions correctives et préventives.

Lorsque les actions correctives affectent directement le logiciel, il est possible d'avoir recours au processus de
gestion de la configuration pour gérer les changements. Il convient que le management procède à la revue des
actions correctives impliquant des changements dans les processus du cycle de vie du logiciel, et qu'il mette en
œuvre ces actions correctives au moyen de procédures de maîtrise des documents et des données.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphes 6.2, 6.8 et 7.3.

4.14.2 Actions correctives

Les procédures d'actions correctives doivent comprendre


a) le traitement effectif des réclamations du client et des rapports de non-conformité du produit;
b) la recherche des causes de non-conformité relatives au produit, au processus et au système qualité
ainsi que l'enregistrement des résultats de cette recherche (voir 4.16);
c) la détermination des actions correctives nécessaires pour éliminer les causes de non-conformité;
d) l'application de moyens de maîtrise pour assurer que l'action corrective est mise en œuvre et qu'elle
produit l'effet escompté.

Il n’y a aucune recommandation particulière concernant le logiciel.

30
© ISO ISO 9000-3:1997(F)

4.14.3 Actions préventives

Les procédures d'action préventive doivent comprendre


a) l'utilisation de sources d'informations appropriées telles que processus et opérations affectant la
qualité du produit, dérogations, résultats d'audits, enregistrements relatifs à la qualité, rapports de
maintenance et réclamations des clients, de manière à détecter, analyser et éliminer les causes
potentielles de non-conformités;
b) la détermination des étapes appropriées pour traiter tout problème nécessitant une action préventive;
c) le déclenchement d'actions préventives et l'application de moyens de maîtrise pour assurer qu'elles
produisent l'effet escompté;
d) l'assurance qu'une information pertinente relative aux actions mises en œuvre est soumise à la revue
de direction (voir 4.1.3).

L'analyse des causes qui sont à l'origine de non-conformités peut contribuer à la mise en place d'actions
préventives. Les mesures prises pour inverser les tendances défavorables des valeurs des métriques peuvent être
considérées comme des actions préventives.

4.15 Manutention, stockage, conditionnement, préservation et livraison

4.15.1 Généralités

Le fournisseur doit établir et tenir à jour des procédures écrites pour la manutention, le stockage, le
conditionnement, la préservation et la livraison du produit.

Il n’y a aucune recommandation particulière concernant le logiciel.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphes 5.2.7.1, 5.3.13.2 et 6.2.6.

4.15.2 Manutention

Le fournisseur doit prévoir des méthodes et des moyens de manutention du produit qui empêchent son
endommagement ou sa détérioration.

Les dommages causés à un logiciel signifient altération de son contenu. Il convient de considérer les logiciels
infectés par des virus informatiques comme des logiciels altérés.

Les informations contenues dans le logiciel ne se détériorent pas; cependant, il convient que le fournisseur prenne
les précautions appropriées pour que les informations ne soient pas altérées du fait de la possibilité de la
détérioration du support de stockage du logiciel.

Les exigences en matière de protection contre les virus, telles qu'elles s'appliquent aux logiciels destinés à être
livrés, sont décrites dans le cadre des dispositions relatives à la reproduction.

31
ISO 9000-3:1997(F) © ISO

4.15.3 Stockage

Le fournisseur doit utiliser les aires ou les locaux de stockage désignés afin d'empêcher l'endommagement
ou la détérioration du produit lorsqu'il est en attente d'utilisation ou de livraison. Des méthodes appropriées
doivent être prescrites pour autoriser la réception dans ces aires et l'expédition à partir de celles-ci.
L'état du produit en stock doit être évalué à intervalles appropriés afin de détecter toute détérioration.

Il convient de mettre en place un système pour:

a) stocker les composants du logiciel;

b) maîtriser l'accès aux composants du logiciel;

c) mettre à jour les versions des produits dans le cadre de référentiels établis.

En vue de conserver l'intégrité du produit et de permettre la maîtrise des modifications, il est essentiel que les
composants du logiciel soient conservés dans un environnement qui:

a) les protège des modifications non autorisées ou de la corruption;

b) permette de maîtriser l'accès à l'original, son extraction et la production de copies.

Il convient de porter attention au stockage sur support informatique, particulièrement en ce qui concerne
l'environnement électromagnétique et électrostatique.

4.15.4 Conditionnement

Le fournisseur doit maîtriser les processus d'emballage, de conditionnement et de marquage (y compris les
matériaux utilisés) autant qu'il est nécessaire pour assurer la conformité aux exigences spécifiées.

Les exigences de conditionnement, applicables aux logiciels destinés à être livrés, sont décrites dans le cadre des
dispositions relatives à la reproduction. Dans les cas de stockage électronique, il est possible qu'il n'y ait aucune
activité physique relative à ce paragraphe. Lors du conditionnement, le logiciel peut être compressé ou crypté.

4.15.5 Préservation

Le fournisseur doit appliquer des méthodes appropriées pour la préservation et l'isolement du produit
lorsque le produit est sous le contrôle du fournisseur.

Il convient de définir un système permettant de préserver les composants du logiciel, par exemple:

a) réaliser régulièrement des copies de sauvegarde;

b) faire en sorte que le logiciel soit copié périodiquement sur un support de remplacement;

c) stocker les supports du logiciel dans un environnement protégé;

d) stocker les supports en des lieux distincts, dans le cadre de plans antisinistres.

4.15.6 Livraison

Le fournisseur doit prendre des dispositions pour la protection de la qualité du produit après les contrôles et
essais finals. Lorsque cela est spécifié contractuellement, cette protection doit être étendue pour inclure la
livraison à destination.

La livraison peut être réalisée par déplacement physique du support contenant le logiciel ou par transmission
électronique. Dans les cas de transmission électronique, il convient de porter attention à la protection contre les
virus.

32
© ISO ISO 9000-3:1997(F)

Il convient de définir et de tenir à jour des procédures pour vérifier l'exactitude et la complétude des copies du
logiciel livré. Il convient que ces procédures prévoient des actions préventives appropriées pour protéger le logiciel
des dommages susceptibles d'être occasionnés lors de la livraison. En outre, il convient de disposer de procédures
pour s'assurer qu'un contrôle antivirus suffisant a été réalisé et que des mesures appropriées sont prises pour
garantir l'intégrité du produit.

4.16 Maîtrise des enregistrements relatifs à la qualité

Le fournisseur doit établir et tenir à jour des procédures écrites d'identification, de collecte, d'indexage,
d'accès, de classement, de stockage, de conservation et d'élimination des enregistrements relatifs à la
qualité.
Les enregistrements relatifs à la qualité doivent être conservés pour démontrer la conformité aux exigences
spécifiées et que le système qualité est opérationnel. Des enregistrements pertinents relatifs à la qualité,
concernant les sous-contractants, doivent être un élément de ces données.
Tous les enregistrements relatifs à la qualité doivent être lisibles, stockés et conservés de façon à être
facilement retrouvés dans des installations qui offrent un environnement approprié pour éviter les
détériorations, les endommagements et les pertes. Les durées de conservation des enregistrements
relatifs à la qualité doivent être définies et enregistrées. Lorsque cela est convenu contractuellement, ces
enregistrements doivent être disponibles pour évaluation par le client ou son représentant, pendant une
durée convenue.
NOTE 19 Les enregistrements peuvent se présenter sur tout support, tel que support papier ou support informatique.

Ci-dessous figurent quelques exemples d'enregistrements relatifs à la qualité:

 des résultats de contrôle et d'essai documentés;

 des rapports relatifs à des problèmes rencontrés;

 des demandes de modification;

 des documents annotés;

 des enregistrements de revues;

 des procès-verbaux;

 des rapports d'audit.

Lorsque des enregistrements sont conservés sur support électronique, il convient, pour déterminer la durée de
conservation et l'accessibilité de ces enregistrements, de prendre en compte le degré de dégradation des images
électroniques ainsi que la disponibilité des dispositifs et logiciels nécessaires pour accéder à ces enregistrements.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphe 6.1.6.2.

33
ISO 9000-3:1997(F) © ISO

4.17 Audits qualité internes

Le fournisseur doit établir et tenir à jour des procédures écrites pour la planification et la réalisation des
audits qualité internes, afin de vérifier si les activités relatives à la qualité et les résultats correspondants
sont conformes aux dispositions prévues et de déterminer l'efficacité du système qualité.
Les audits qualité internes doivent être programmés en fonction de la nature et de l'importance de l'activité
soumise à l'audit. Ils doivent être conduits par des personnes indépendantes de celles qui ont la
responsabilité directe de l'activité auditée.
Les résultats des audits doivent être enregistrés (voir 4.16) et portés à la connaissance des personnes qui
ont la responsabilité du domaine soumis à l'audit. Les responsables de ce domaine doivent engager des
actions correctives en temps utile pour remédier aux déficiences trouvées lors de l'audit.
Les activités de suivi d'audit doivent comprendre la vérification et l'enregistrement de la mise en œuvre et
de l'efficacité des actions correctives engagées (voir 4.16).
NOTE 20 Les résultats des audits qualité internes font partie intégrante des activités de revue de direction (voir
4.1.3).
NOTE 21 L' ISO 10011 donne des informations relatives aux audits des systèmes qualité.

Lorsque les fournisseurs de logiciels travaillent en mode projet, il convient que le plan d'audit procède à une
sélection des projets. Il y a lieu de veiller à couvrir de manière progressive l'ensemble du système qualité du
fournisseur. Ceci peut être obtenu en procédant à l'audit de plusieurs projets à des stades différents du cycle de
vie. Lorsqu'un seul projet mobilise la plupart des ressources dont dispose l'organisme, des audits de ce projet
peuvent être programmés au fur et à mesure de son avancement. Lorsque les délais annoncés du projet sont
modifiés, il convient de revoir le calendrier d'audit interne, soit en modifiant la date de l'audit, soit en considérant un
projet différent.

Il convient que l'auditeur interne du fournisseur porte attention à la cohérence entre les plans qualité du projet et le
système qualité de l'organisme.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphes 6.7, 6.8 et 7.3.2.

4.18 Formation

Le fournisseur doit établir et tenir à jour des procédures écrites permettant d'identifier les besoins de
formation et de pourvoir à la formation de toutes les personnes chargées d'une activité ayant une incidence
sur la qualité. Les personnes chargées d'accomplir des tâches particulières doivent être qualifiées sur la
base d'une formation initiale appropriée, d'une formation complémentaire et/ou d'une expérience
appropriée, selon les exigences. Des enregistrements appropriés de la formation doivent être tenus à jour
(voir 4.16).

Il convient de déterminer les besoins en formation en fonction des outils, des techniques, des méthodes, des
ressources informatiques spécifiques à utiliser pour mener à bien le développement et la gestion du logiciel. Il peut
également être nécessaire d'inclure une formation pour acquérir des aptitudes particulières et des connaissances
ayant un rapport avec le domaine spécifique d'utilisation du logiciel. Il convient de documenter les qualifications et
les formations.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphe 7.4.

4.19 Prestations associées

Lorsque les prestations associées sont une exigence spécifiée, le fournisseur doit établir et tenir à jour des
procédures écrites pour effectuer, vérifier et rendre compte que ces prestations sont conformes aux
exigences spécifiées.

Pour les besoins de la présente partie de l’ISO 9000, on considère que les prestations associées recouvrent les
termes suivants relatifs au logiciel: maintenance et soutien au client. Le soutien au client est décrit dans
l’ISO 9000-2.

34
© ISO ISO 9000-3:1997(F)

Les activités de maintenance des logiciels sont traditionnellement classées de la manière suivante:

a) La résolution de problèmes: la résolution de problèmes comprend la détection et l'analyse des non-conformités


du logiciel entraînant des problèmes d'exploitation, ainsi que la correction des défauts sous-jacents du logiciel.
Lors de la résolution de problèmes, il est possible de faire appel à des solutions temporaires pour minimiser le
temps d'arrêt et de réaliser les changements définitifs ultérieurement.

b) La modification des interfaces: il peut se révéler nécessaire de modifier les interfaces lorsque des extensions
ou des modifications ont été réalisées sur le système matériel ou sur ses composants, interfacés par le logiciel.

c) L'extension des fonctionnalités ou l'amélioration des performances.

En ce qui concerne la modification des interfaces et l'extension des fonctionnalités, et en fonction de l'étendue des
travaux, il convient soit d'appliquer des procédures de maîtrise des modifications, soit de commencer un nouveau
projet de développement; la totalité de la présente partie de l’ISO 9000 devient alors applicable. Les activités de
maintenance décrites dans le présent paragraphe sont par conséquent limitées à la résolution des problèmes (ces
activités sont souvent appelées maintenance corrective).

Lorsque le client requiert la maintenance du logiciel, après livraison et installation initiales, il est recommandé de le
stipuler dans le contrat. Il est recommandé que le fournisseur établisse et mette à jour des procédures écrites pour
exécuter les activités de maintenance et qu'il vérifie que ces dernières répondent bien aux exigences spécifiées de
maintenance. Les activités de maintenance peuvent également être réalisées sur l'environnement de développe-
ment, sur les outils et sur la documentation.

Il est recommandé de spécifier dans le contrat les composants faisant l'objet de la maintenance ainsi que la durée.
Ci-après figurent quelques exemples de composants soumis à la maintenance:

a) le(s) programme(s);

b) les données et leur structure;

c) les spécifications;

d) les documents à l'usage du client et/ou de l'utilisateur;

e) les documents à l'usage du fournisseur;

f) les plans d'essais.

Il est recommandé que toutes les activités de maintenance soient exécutées et gérées conformément à un plan de
maintenance et/ou à des procédures définis et acceptés au préalable par le fournisseur et le client. Il y a lieu
d'inclure dans ce plan, selon le cas:

a) le champ d'application de la maintenance;

b) l'identification de l'état initial du produit;

c) l'(les) organisme(s) de soutien;

d) les activités de maintenance;

e) les enregistrements et rapports de maintenance;

f) les activités de gestion de la configuration;

g) une proposition de calendrier de mise à disposition des versions.

Lorsque cela est nécessaire, il convient que les activités de maintenance fassent l'objet d'un enregistrement, qui
sera conservé. Il convient que le fournisseur et le client établissent et se mettent d'accord sur les règles régissant la
fourniture des rapports de maintenance.

35
ISO 9000-3:1997(F) © ISO

Il est recommandé que les enregistrements de maintenance comprennent les points suivants, selon le cas, pour
chaque logiciel faisant l'objet d'une maintenance:

a) les notifications de problèmes ayant été reçues, ainsi que l'état de traitement de chacune de ces demandes;

b) l'organisme chargé de répondre aux demandes d'assistance ou de mettre en œuvre les corrections
appropriées;

c) les priorités qui ont été affectées aux corrections;

d) les résultats des corrections;

e) les données statistiques concernant les circonstances des défaillances et les activités de maintenance.

L'enregistrement des activités de maintenance peut être utilisé pour évaluer et améliorer le logiciel et pour améliorer
le système qualité lui-même.

NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphes 5.4.4, 5.5 et 6.8.

4.20 Techniques statistiques

4.20.1 Identification des besoins


Le fournisseur doit identifier les besoins en techniques statistiques requises pour établir, maîtriser et vérifier
l'aptitude de processus et les caractéristiques du produit.
4.20.1 Procédures
Le fournisseur doit établir et tenir à jour les procédures écrites pour mettre en œuvre et maîtriser
l'application des techniques statistiques identifiées en 4.20.1.

Les techniques statistiques peuvent être utilisées pour analyser l'aptitude des processus et les caractéristiques du
produit, avec pour objectif de produire des données utilisables lors de l'évaluation de la qualité du produit et de
l'aptitude de ces processus. Il est possible d'utiliser ces données pour évaluer la conformité aux exigences pour la
qualité, lorsque ces dernières sont exprimées de manière quantitative.

Ci-dessous figurent des caractéristiques du produit qui peuvent faire l'objet de calculs statistiques:

 la testabilité;

 la facilité d'utilisation;

 la fiabilité;

 la maintenabilité;

 la disponibilité.

Ci-dessous figurent des caractéristiques d'aptitude du processus qui peuvent faire l'objet de calculs statistiques:

 la maturité du processus;

 le nombre et le type de défauts qui ont été repérés dans les données de sortie du processus;

 l'efficacité de l'élimination des défauts;

 le dérapage des points clés.

Le terme «métrique» implique une caractéristique mesurable.

36
© ISO ISO 9000-3:1997(F)

Il convient que les métriques se conforment aux principes suivants:

a) la métrique apporte généralement de la valeur au processus ou au produit;

b) la métrique est clairement définie;

c) la signification de la métrique par rapport à la qualité du logiciel ou du processus de développement est bien
comprise;

d) la façon dont la métrique peut être influencée (par exemple par des modifications des techniques de
conception et de développement) est identifiée;

e) l'orientation des modifications de la métrique, indicateur d'amélioration de la qualité, est bien comprise.

Indépendamment des métriques utilisées, il est plus important de connaître et d'utiliser des niveaux à des fins de
maîtrise et d'amélioration des processus, plutôt que de s'attacher à la nature des métriques elles-mêmes.

Un même fournisseur peut utiliser de façon appropriée des métriques différentes selon les logiciels qu'il élabore.

NOTE Des recommandations complémentaires figurent dans l'ISO/CEI 9126.

37
ISO 9000-3:1997(F) © ISO

Annexe A
(informative)

Bibliographie

[1] ISO 9000-2:1997, Normes pour le management de la qualité et l'assurance de la qualité — Partie 2: Lignes
directrices génériques pour l'application de l’ISO 9001, l’ISO 9002 et l’ISO 9003.

[2] ISO 10005:1995, Management de la qualité — Lignes directrices pour les plans qualité.

[3] ISO 10006:1997, Management de la qualité — Lignes directrices pour la qualité en management de projet.

[4] ISO 10007:1995, Management de la qualité — Lignes directrices pour la gestion de configuration.

[5] ISO 10011-1:1990, Lignes directrices pour l'audit des systèmes qualité — Partie 1: Audit.

[6] ISO 10011-2:1991, Lignes directrices pour l'audit des systèmes qualité — Partie 2: Critères de qualification
pour les auditeurs de systèmes qualité.

[7] ISO 10011-3:1991, Lignes directrices pour l'audit des systèmes qualité — Partie 3: Gestion des programmes
d'audit.

[8] ISO 10012-1:1992, Exigences d'assurance de la qualité des équipements de mesure — Partie 1: Confir-
mation métrologique de l'équipement de mesure.

[9] ISO 10013:1995, Lignes directrices pour l'élaboration des manuels qualité.

[10] ISO/CEI 9126:1991, Technologies de l'information — Évaluation des produits logiciels — Caractéristiques de
qualité et directives d'utilisation.

[11] ISO/CEI 12207:1995, Technologies de l'information — Processus du cycle de vie du logiciel.

38
© ISO ISO 9000-3:1997(F)

Annexe B
(informative)

Références croisées entre l'ISO 9000-3 et l'ISO/CEI 12207

Ce tableau de références croisées

 identifie les paragraphes de l'ISO/CEI 12207 qui peuvent aider à construire un système qualité conforme à
l'ISO 9001;

 reprend les notes qui figurent dans le corps de la présente partie de l'ISO 9000;

 n'est pas destiné à fournir une description complète des liens entre l'ISO/CEI 12207 et l'ISO 9001, ni la façon
dont l'ISO/CEI 12207 couvre les exigences de l'ISO 9001 et vice versa.

ISO 9000-3 ISO/CEI 12207


4.1.2 7.2, 6.3.1.6
4.1.3 7.4
4.2.3 6.2, 6.3, 6.4, 6.5
4.3.2 5.2.1, 5.2.6, 6.4.2.1
4.3.3 5.1.3.5, 5.2.3.2
4.4.2 5.2.4
4.4.3 5.2.6.1, 6.6.2
4.4.4 5.3.2, 5.3.3, 5.3.4
4.4.5 5.3.5, 5.3.6, 5.3.7
4.4.6 5.3.4.2, 5.3.5.6, 5.3.6.7, 6.6.3
4.4.7 5.3.4.2, 5.3.5.6, 5.3.5.7, 5.3.7.5, 5.3.9, 6.4
4.4.8 5.3.1, 6.5
4.4.9 5.5.2, 5.5.3, 6.2.3
4.5.1 6.1
4.6.1 5.1
4.7 6.1
4.8 6.1, 6.2
4.9 5.3.12, 6.3.3
4.10.1 5.1.5, 5.3.5.5, 5.3.6.5, 5.3.6.6, 5.3.7, 5.3.8, 5.3.9, 5.3.10, 5.3.11, 5.3.13
4.11.1 7.2
4.12 6.2
4.13.1 6.2, 6.8
4.14.1 6.2, 6.8, 7.3
4.15.1 5.2.7.1, 5.3.13.2, 6.2.6
4.16 6.1.6.2
4.17 6.7, 6.8, 7.3.2
4.18 7.4
4.19 5.4.4, 5.5, 6.8

39
Page 3
EN ISO 9000-3:1998

Annexe ZA

(normative)

Références normatives aux publications internationales


avec leurs publications européennes correspondantes

Init numérotation des tableaux d’annexe [A]!!!


Init numérotation des figures d’annexe [A]!!!
Init numérotation des équations d’annexe [A]!!!

Cette norme européenne comporte par référence datée ou non datée des dispositions d'autres publications. Ces
références normatives sont citées aux endroits appropriés dans le texte et les publications sont énumérées ci-
après. Pour les références datées les amendements ou révisions ultérieurs de l'une quelconque de ces publication
ne s'appliquent à cette norme européenne que s'ils y ont été incorporés par amendement ou révision. Pour les
références non datées, la dernière édition de la publication à laquelle il est fait référence s'applique.

Publication Année Titre EN Année


ISO 8402 1994 Management de la qualité et assurance de EN ISO 8402 1995
la qualité — Vocabulaire
ISO 9001 1994 Systèmes qualité — Modèle pour l'assurance de EN ISO 9001:1994/AC:1997
la qualité en conception, développement,
production, installation et prestation associées
(ISO 9001:1994, Rectificatif Technique 1:1995
inclus)

Vous aimerez peut-être aussi