ISO 6592:1985

Norme internationale @ 6592
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION*MEXLYHAPOllHAR OPrAHi43AUHR fl0 CTAHLAPTM3AUHM*ORGANlSATlON INTERNATIONALE DE NORMALISATION
Traitement de l'information - Principes généraux relatifs
e
à la documentation des systèmes d'application
informatisés
Information processing - Guidelines for the documentation of computer-based application systems
Première édition - 1985-11-15
- G CDU 681.3.01 Ref. no : IS0 6592-1985 (FI
Descripteurs : traitement de i'information, échange d'information, documentation, instruction.
f
Prix basé sur 17 pages

---------------------- Page: 1 ----------------------
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale
d'organismes nationaux de normalisation (comités membres de I'ISO). L'élaboration
des Normes internationales est confiée aux comités techniques de I'ISO. Chaque
comité membre intéressé par une étude a le droit de faire partie du comité technique
à cet effet. Les organisations internationales, gouvernementales et non gouverne-
créé
mentales, en liaison avec I'ISO, participent également aux travaux.
Les projets de Normes internationales adoptés par les comités techniques sont soumis
aux comités membres pour approbation, avant leur acceptation comme Normes inter-
nationales par le Conseil de I'ISO. Les Normes internationales sont approuvées confor-
mément aux procédures de I'ISO qui requièrent l'approbation de 75 % au moins des
comités membres votants.
La Norme internationale IS0 6592 a été élaborée par le comité technique ISO/TC 97,
Systèmes de traitement de l'information.
L'attention des utilisateurs est attirée sur le fait que toutes les Normes internationales
à révision et que toute référence faite à une autre
sont de temps en temps soumises
Norme internationale dans le présent document implique qu'il s'agit, sauf indication
contraire, de la dernière édition.
0 Organisation internationale de normalisation, 1985 0
Imprimé en Suisse
ii

---------------------- Page: 2 ----------------------
Sommaire Page
1 Objet et domaine d'application .
1
2
Principes de la documentation . 1
3 Étude de faisabilité .
2
4 Étude de conception du système . 4
5 Conception et réalisation du système . 5
6 Suivi du système .
6
7 Miseen placedusystème .
7
8 Examensaprèsrniseenplace .
7
9 Gestion des documents .
8
Annexes
A Spécifications de la documentation des programmes . 9
B
Spécifications de la documentation relative aux données . 10
C Spécifications du manuel utilisateur .
15
...
111

---------------------- Page: 3 ----------------------
NORME INTERNATIONALE IS0 6592-1985 (FI
Traitement de l'information - Principes généraux relatifs
à la documentation des systèmes d'application
informatisés
La présente Norme internationale ne couvre pas les spécifica-
1 Objet et domaine d'application
tions concernant la documentation relative au matériel dont se
compose le système.
La présente Norme internationale établit les principes généraux
de la documentation des systèmes informatiques d'application.
Elle contient aussi des listes de contrôle visant à contribuer au
fonctionnement efficace des systèmes tout au long de leur
2 Principes de la documentation
a cycle de vie.
2.1 Généralités
Les principes généraux donnés dans la présente Norme interna-
tionale ont été développés dans le but de répondre aux objectifs
En dépit de leur diversité les applications informatisées présen-
:
suivants
tent des ressemblances fondamentales comme, par exemple, le
a) obtenir l'engagement nécessaire des parties concernées
fait évident qu'une application comporte toujours les phases
par l'élaboration du système d'application;
entrée, traitement et sortie. On a toujours besoin de définir et
de justifier les ressources (en personnel, en matériel et financiè-
b) contribuer à la mise sur pied d'une documentation bien
res) nécessaires pour élaborer et mettre en place un projet
planifiée et normalisée;
informatique, grand ou petit, et de créer une documentation
c) permettre d'obtenir pour la documentation une évolu- décrivant de facon adéquate tous les aspects du système pro-
posé.
tion parallèle à celle du système lui-même.
C'est dans ce contexte que les principes généraux ont été mis
Une définition correcte des règles applicables à la documenta-
au point. Le but visé étant de créer un ensemble documentaire
tion au cours de l'étude et de la réalisation du système devrait
fondamental constituant une base solide pour tout projet et
faciliter
permettant de l'élaborer et de le mettre en place au moyen de
a) la rédaction de la documentation elle-même;
mécanismes appropriés de réalisation et de contrôle, et d'avan-
cer ainsi selon un processus planifié et contrôlé.
l'évaluation des délais et des moyens nécessaires à
b)
l'achèvement d'un projet;
L'application de ces recommandations dépend du genre de
les échanges d'informations entre les parties intéres-
c) système adopté : par exemple, les méthodes d'exploitation peu-
e
sées, avec pour résultat
vent avoir une plus grande importance en contrôle des proces-
sus qu'en traitement de gestion par lots.
-
la définition d'objectifs réalistes pour un système
-
et de Tel document ou élément d'information peut être sans objet
une conception fonctionnelle plus complète
meilleure qualité pour un système et au contraire très important pour un autre.
Les listes de contrôle données dans la présente Norme interna-
les prises des décisions et les instructions données au
d)
tionale servent à vérifier que, si la documentation ne contient
personnel au cours de l'étude du projet.
pas le renseignement recherché, cela résulte d'une décision
bien arrêtée et non d'un oubli.
La documentation établie conformément à ces principes
généraux
Au fur et à mesure que le projet devient plus détaillé, la révision
de la documentation peut s'avérer nécessaire.
a) permet à la direction d'exercer son contrôle sur le
déroulement des travaux;
2.2 Nature des informations
b) permet aux utilisateurs du système de s'en servir cor-
rectement et avec un rendement satisfaisant;
Dans la présente Norme internationale, les informations sont clas-
c) permet aux informaticiens d'en planifier l'exploitation;
sées en deux grandes catégories: techniques ou administratives.
d) contribue aux diagnostics et à la correction des erreurs
Les informations administratives concernent le contrôle et la
et des anomalies;
gestion du projet et indiquent ce qui a été autorisé et ce qui a
été réalisé. Elle sont enregistrées, mais leur mise à jour peut ne
e) facilite la maintenance grâce aux renseignements
qu'elle fournit. pas être nécessaire une fois terminée la mise en place.
1

---------------------- Page: 4 ----------------------
Les informations techniques constituent une description à jour 3.3.2 Analyse des problèmes et des informations
de tous les aspects du système, matériel, logiciel et données.
Elles doivent être tenues à jour pendant toute la durée de vie du
a) problèmes posés:
système.
1 ) définitions, environnement, situation actuelle;
Certains documents peuvent contenir des informations de deux
2) contraintes techniques et financières:
catégories, mais il est alors recommandé de les enregistrer dans
des parties distinctes afin de faciliter la mise à jour des informa-
b) objectifs du système:
tions techniques.
1) définition et description;
2.3 Relation entre les étapes du projet et de la
2) délimitation;
documentation correspondante
3) synthèse;
Les principes généraux donnés dans la présente Norme interna-
tionale font ressortir les relations qui doivent exister entre les
c) renseignements sur le système:
étapes d'un projet et la documentation créée. Généralement,
chaque étape démarre et se termine par un document. Bien que
1) définition et description;
les principales étapes se déroulent en séquence, certaines éta-
pes et la préparation de certains documents peuvent se chevau-
2) relations;
il faut commencer la préparation des
cher; par exemple,
3) caractéristiques:
manuels d'appui du système au cours de l'étape d'étude et de
développement. Le nombre d'étapes et le nombre de docu-
d) fonctionnement du système:
ments peuvent varier d'une application à l'autre; ces principes
généraux donnent la liste des éléments de documentation qui
1) description;
apparaissent par exemple dans les documents émanant de
chaque étape du processus de développement.
2) entrées, mémorisation des données, sorties;
3) relations entre données;
3 Étude de faisabilité
4) périodicités;
3.1 Objectifs
5) volumes.
Les objectifs de l'étude de faisabilité sont les suivants
3.3.3 Organisation et spécifications du projet
a) déterminer exactement ce dont on a besoin à la suite
d'une étude préliminaire;
a) personnel nécessaire;
b) concevoir plusieurs solutions possibles et déterminer la
b) formation;
meilleure;
c) calendrier des opérations principales;
c) enregistrer dans la documentation les spécifications et
les contraintes du nouveau système.
d) effectifs;
e) matériel;
3.2 Demande d'étude de faisabilité
fi logiciel;
Ce document autorise l'emploi de ressources pour analyser un
g) locaux.
besoin, un objectif ou un problème de conception et pour pro-
poser une solution possible. Ce document est créé par ou pour
l'utilisateur avant le démarrage du projet.
3.3.4 Coûts et avantages
La rédaction de ce document peut nécessiter l'assistance d'un
a) coûts financiers;
spécialiste pour évaluer la durée et le coût de l'étude de faisabi-
b) avantages.
lité.
à l'étude même et à la
L'approbation de la demande conduit
3.3.5 Système proposé
rédaction d'un rapport d'étude de faisabilité.
a) description fonctionnelle;
3.3 Rapport d'étude de faisabilité
b) contrôles d'exactitude;
c) sécurité;
3.3.1 Objectif
d) interfaces;
de faisibilité doit permettre à l'utilisateur
Le rapport de i'étude
de décider s'il doit ou non passer à l'étape suivante du projet. e) organigrammes de données;
2

---------------------- Page: 5 ----------------------
IS0 6592-1985 (FI
Étapes Documents correspondants
Demande d'étude de
Étude de faisabilité faisabilité
(voir chapitre 3)
-
7 Rapport d'étude de
faisabilité
I
t
Demande d'étude de
Étude de conception du
.4 conception du système
système (voir chapitre 4)
(voir chapitre 4)
~ m
Rapport d'étude de
conception du système
1
(voir chapitre 4.3)
Conception et élaboration
I I
du système (voir chapitre 5)
I
.
Documentation sur la
conception du système:
ensemble et éléments
(voir 5.3, 5.4 et
annexes A, B, C)
Documentation de mise en
place: planning et tests
(voir 7.2.1 et 7.2.2)
1
Documentation d'appui du
Soutien du système
système: utilisateurs,
(voir chapitre 6)
I
exploitation, programmes,
données, caractéristiques,
techniques et modifications
I I
(voir 6.2)
0
II
I Mise en place du système
(voir chapitre 7) Rapport d'acceptation
- (voir 7.2.3)
Rapports d'évaluation
Examens après mise en place
D (voir 8.2)
(voir chapitres 8)
v
* Autres points de départ possibles dans le cas où une étude de faisabilité indépendante n'est pas nécessaire.
Figure - Schéma des relations entre les étapes de l'élaboration d'un projet et les documents produits
3

---------------------- Page: 6 ----------------------
IS0 6592-1985 (F)
4.2 Demande d'6tude de conception du système
f) possibilités d'évolution en volume, en opérations
nouvelles ;
Ce document indique la procédure à suivre une fois le rapport
g) calendrier et délais;
de l'étude de faisabilité examiné. Sous sa forme la plus simple,
il se contente d'approuver les recommandations du rapport et
h) fonctions non informatisées;
autorise l'exécution de l'étude.
ji effectifs;
4.3 Rapport d'étude de conception
k) matériel;
m) logiciel;
4.3.1 Objectifs
ni locaux.
Le rapport d'étude de conception devrait être suffisamment
détaillé afin que
3.3.6 Mise en place, critères de qualité et d'acceptation
a) l'utilisateur sache clairement ce que fera le système
a) essai du système;
(entrée, traitement, mémorisation des données de sorlie,
b) création et conversion des fichiers;
délais, etc.
c) intégration dans les systèmes existants;
b) l'utilisateur sache exactement comment faire fonction-
ner le système;
d) formation des utilisateurs;
ci les modifications ou adaptations d'organisation nécos-
e) émulation;
saires à la mise en place et à l'exploitation du système soiont
définies et puissent être entreprises séparément:
f) méthodes de transition proposées;
d) les spécifications fonctionnelles soient suffisamment
g) modifications de l'organisation;
claires afin que les caractéristiques du système puissent être
h) spécification du contrôle qualité;
défninies au cours de la phase suivante.
j) définition des responsabilités;
Planification
4.3.2
k) critères d'acceptation du système.
a) organisation;
3.3.7 Fonctionnement et suivi
b) calendrier :
a) récupération après panne;
C) principes ressources nécessaires;
b) maintenance;
contrôle qualité;
d)
c) disponibilité de rechange.
normes à utiliser.
e)
3.3.8 Glossaire: explication des termes nouveaux ou
et avantages
4.3.3 Coûts
inusités.
a) coûts d'étude;
3.3.9 Conclusions et recommandations
coûts de mise en place;
b)
a) spécifications du système:
coûts de formation;
C)
1 ) besoins de l'utilisateur;
coûts d'exploitation;
d)
2) satisfaction de ces besoins.
avantages, matériels et non matériels.
e)
b) solutions de rechange:
Description du système
1) description des solutions de rechange prises en 4.3.4
considération ;
vue générale du système dans son contexte;
a)
2) raisons du rejet de ces solutions.
matériel nécessaire;
b)
termi-
moyens de télécommunications nécessaires:
Cl
4 Étude de conception du système
naux, lignes, modems, concentrateurs;
4.1 Objectif
d) spécifications du logiciel: langages, base de données,
système d'exploitation, etc. ;
L'objectif de cette étape est de déterminer dans le détail le
schéma retenu. e) description des données;
4

---------------------- Page: 7 ----------------------
f) flux de données, y compris volumes moyens et maxi- 5) estimations financières;
maux;
6) sécurité;
g) tolérances concernant les volumes;
7) calendrier et délais:
h) contrôles de l‘exactitude des données;
d) glossaire des termes nouveaux ou inusités.
j) securité : intégrité du système, protection des données,
sécurité matérielle, disponibilité:
4.3.8 Présentation pour la direction
k) spécifications relatives à l’environnement et à I’alimen-
tation (y compris les dispositions concernant la consomma- a) personnel;
tion au repos);
b) matériel;
m) interfaces avec les autres systèmes, existants, en
ci besoins du contrôle qualité;
projet;
n) règles d’ordonnancement des travaux; d) besoins en locaux;
p) possibilité d’adjonctions;
e) estimation des coûts:
q) procédures non informatisées.
1) prochaine étape du projet;
0
2) totalité du projet;
4.3.5 Programmes de mise en place, de contrôle qualité
et de réception
fi estimation des avantages;
a) formation des utilisateurs;
g) calendrier.
b) création et conversion des fichiers;
5 Conception et réalisation du système
c) essais du système et évaluation des résultats;
di émulation;
5.1 Objectifs
e) modifications à apporter au service;
Les objectifs sont les suivants:
f) intégration dans les systèmes existants;
a) décrire dans le détail les procédures de traitement auto-
g) transition entre anciennes et nouvelles procédures;
matisées et manuelles, et en déterminer les limites;
hi besoins du contrôle qualité;
b) créer une documentation permettant d’écrire les
programmes;
j) limites de responsabilité du produit;
c) fournir les renseignements nécessaires pour exécuter
k) critères de réception du système.
les tests et mettre en place le nouveau système:
d) établir un plan détaillé de toutes les opérations à
0 4.3.6 Fonctionnement et suivi
effectuer au cours de l‘étape de mise en place;
a) récupération après panne;
e) assurer la préparation des manuels de suivi du système.
b) responsabilités relatives à la maintenance;
5.2 Documentation de conception
c) disponibilité des pièces de rechange et des moyens de
secours.
Cette documentation est destinée à présenter l‘ensemble de la
conception du système selon les principes suivants:
4.3.7 Présentation générale de l’application
a) à chaque partie du système correspond une fonction
qui doit être décrite;
définition des problèmes et solutions apportées;
a)
b) toutes les fonctions d’un système complet sont décrites
b) recommandations;
dans leur intégralité, le système étant découpé en parties,
qui sont présentées dans toutes leurs interactions et rela-
c) exploitation du système;
tions.
1 i personnel ;
La documentation doit comprendre au moins deux niveaux de
2) matériel;
détail, à savoir:
-
3) logiciel;
documentation générale du système (voir 5.3);
-
4) locaux; documentation des éléments du système (voir 5.4).
5

---------------------- Page: 8 ----------------------
IS0 6592-1985 (FI
5.3 Documentation générale du système II doit être bien entendu que ces opérations ne peuvent pas être
exécutées par le même personnel que celui qui a mis au point le
Le niveau de détail dans lequel doit entrer la documentation
système.
générale dépend des spécifications du système. On peut avoir
besoin de cette documentation pour constituer la base des
manuels de suivi du système.
6.2 Documentation de suivi du système
La documentation générale doit décrire en détail ce qui suit
La documentation de suivi doit être constituée à partir des
a) titre du projet; documents créés au cours de l'étape de conception et de réali-
sation. Toute modification apportée aux documents établis au
b) objectifs;
cours de cette étape doivent se refléter dans les documents de
suivi.
c) description (texte et schémas);
- désignation des sous-systèmes;
La documentation effectivement produite dépend des besoins
- interfaces avec les autres systèmes;
du système particulier, de la politique de maintenance et des
normes de documentation. Cependant, pour répondre à
d) sécurité:
l'objectif énoncé ci-dessus, il est recommandé de décomposer
la documentation comme suit:
e) contrôles (y compris vérification interne) ;
f) cadre d'exploitation;
ai Manuel utilisateur
O
g) récupération après panne:
Ce manuel doit décrire de façon claire et concise les droits et
h) fonctions de support nécessaires à l'exploitation du
responsabilités de l'utilisateur et du fournisseur du système.
système ;
j) spécifications relatives aux données; Voici quelques exemples de ce que peuvent être ces droits
et responsabilités:
k) procédures relatives aux essais;
1) Les droits de l'utilisateur peuvent inclure:
m) procédures relatives aux modifications.
-
le droit aux informations concernant l'utilisation
5.4 Documentation sur les éléments du système
du système;
Cette documentation doit décrire en détail les caractéristiques - le droit aux informations concernant les résultats
des programmes, des fichiers et des opérations manuelles. On
obtenus par le système et la correction des erreurs de
peut en avoir besoin pour servir de base aux manuels de sup-
données.
port du système.
Les responsabilités de l'utilisateur peuvent inclure:
2)
5.4.1 Caractéristiques des programmes
- la préparation correcte des données d'entrée;
Voir annexe A.
- la communication au fournisseur des erreurs
a
le système.
détectées dans
5.4.2 Caractéristiques des fichiers et de la base de
données
3) Les droits du fournisseur peuvent inclure:
Voir annexe B.
- le droit de modifier le système fourni par lui;
- le droit de procéder à des tests réguliers pour
5.4.3 Caractéristiques des procédures manuelles
vérifier que le système continue à fonctionner
Voir annexe C. correctement.
Les responsabilités du fournisseur peuvent inclure:
4)
6 Suivi du système
-
la tenue d'une documentation précise et à jour;
6.1 Objectif
-
la diffusion de l'expérience des utilisateurs du
système.
Cette étape a pour objectifs d'apporter une aide à l'exploitation
du système une fois qu'il a été réceptionné par l'utilisateur. Elle
revêt les aspects suivants: Tous ces droits et responsabilités, objet d'un accord entre
fournisseur et client, peuvent être influencés par les Iégisla-
a) utilisation normale du système;
tions et normes nationales et/ou internationales. Ce manuel
doit inclure des renseignements sur la réglementation rela-
b) détection et correction des erreurs:
tive au contrôle qualité et les limites de responsabilité du
c) modifications et améliorations éventuelles.
produit.
6

---------------------- Page: 9 ----------------------
IS0 6592-1985
b) Manuel d’exploitation c) formation des utilisateurs;
d) constitution des fichiers;
Ce manuel doit avoir pour objet l’exploitation du système, à
l’aide de l‘ordinateur et de ses accessoires dans tous les
e) mise à jour, assemblage et diffusion des documents;
modes prévus.
f) vérification des procédures de maintenance;
c) Dossiers de programmes
g) calendrier et méthode de mise en place;
Ces dossiers doivent indiquer le but de chaque programme
h) procédures de transition vers le nouveau système;
et fournir des renseignements tels que formules et algo-
j) procédures de reprise.
rithmes mathématiques utilisés, méthodes et planning de
traitement des erreurs. Ils doivent comprendre des listes de
programmes, avec commentaires utiles pour les modifica-
7.2.2 Essais de réception
tions et améliorations, ainsi que les jeux d’essais et leurs
résultats.
La documentation doit préciser comment seront effectués les
tests dans les divers cadres d‘exploitation définis. Elle doit aussi
d) Dossier des données
fournir une liste de contrôle des résultats attendus et indiquer
les tolérances éventuelles.
Ce dossier doit décrire la structure des données au niveau
de détail indiqué dans les spécifications du système.
@
7.2.3 Procès-verbal de réception
e) Notice technique du système
Ce document doit donner les résultats des essais de réception,
et être signé par tous les responsables concernés qui en
Cette notice doit permettre aux techniciens de comprendre
recoivent copie.
le fonctionnement du système, les aider à détecter et à corri-
ger les erreurs et à apporter les modifications et améliora-
Si, pour une raison quelconque, la réception ne peut être pro-
tions nécessaires. Si besoin est, ils se réfèrent aux notices
noncée, il faut si possible fournir une liste officielle des déficien-
du matériel.
cies et des remèdes proposés.
Journal des modifications du système
f)
8 Examens après mise en place
Ce document doit consigner quelles modifications ont été
autorisées et apportées à toute partie du système, et indi-
quer comment, pourquoi et par qui elles l’ont été.
8.1 Objectifs
Les objectifs à ce stade sont les suivants:
7 Mise en place du système
a) vérifier si le système répond aux objectifs;
7.1 Objectif b) assurer le suivi de la répartition des ressources et de
l‘estimation des coûts;
Cette étape a pour objectif d’exécuter des essais complets de
(3)
c) mentionner les effets non matériels positifs et négatifs
réception du système sous tous les aspects de son cadre
liés à l‘emploi du système;
d’exploitation, et de démontrer que toutes les conditions indi-
quées sont satisfaites.
d) analyser et enregistrer l‘expérience acquise au cours
des études de systèmes.
7.2 Spécifications de la documentation
8.2 Rapports d’évaluation
A cette étape, la documentation doit comprendre un pro-
gramme de mise en place et un programme d’essais de récep-
Pour les rapports d‘évaluation,
tion du système. La documentation issue de cette phase est un
procès-verbal de réception.
a) voir si les objectifs fixés à l’origine pour le système
étaient corrects et dans quelle mesure ils ont été satisfaits
dans la pratique;
7.2.1
Programme de mise en place
b) souligner les points susceptibles d’amélioration;
Bien que la mise en place se situe à la fin de l’étude du projet, sa
c) avaliser les opérations réussies;
planification doit commencer assez tôt et le document doit être
mis à jour aussi souvent que nécessaire au cours de l’étude.
d) cerner et évaluer les problèmes d’exploitation éven-
tuels;
Le plan doit par exemple donner des détails sur ce qui suit:
e) voir si les avantages annoncés ont bien été obtenus;
a) locaux et cadre de travail:
f) garder la trace d’expériences susceptibles d‘aider pour
b) organisation du personnel;
des projets de systèmes futurs.
7

---------------------- Page: 10 ----------------------
IS0 &92-1985 (FI
c
II est recommandé d'utiliser une documentation à base de feuil-
9 Gestion des documents
les mobiles.
9.1 Création et traitement des documents
Les procédures à suivre pour les rectificatifs doivent être adop-
tées d'un commun accord et être clairement définies. II est pri-
Un important aspect du travail de documentation est la création
mordial que tous les utilisateurs et les membres des équipes de
de documents répondant aux besoins de l'utilisateur. II est
projets aient connaissance des procédures adoptées.
primordial de définir clairement ces besoins et de présenter le
contenu d'un document de façon qu'il soit d'accès et de com-
9.2 Principe de la documentation centrale
préhension aisés pour le lecteur.
La documentation centrale doit contenir tous les renseigne-
A chaque document créé en rapport avec une étape de I'élabo-
ments relatifs aux opérations qui se déroulent pendant tout le
ration du système doit être affecté un numéro ou un code
cycle de vie du système.
d'identification unique pour en faciliter l'enregistrement et la
recherche. Ce code ou numéro doit indiquer clairement le
Ces renseignements restent valables dans la mesure où ils sont
la catégorie de documentation auxquels
système ou le projet et
mis à jour chaque fois qu'est approuvée une décision, une réali-
appartient le document. Les règles d'identification des systè-
sation, une modification, etc.
mes et sous-systèmes peuvent varier d'une entreprise à l'autre
mais doivent être décrites dans les instructions particulières à
Pour faciliter ces mises à jour, chaque renseignement ne doit
l'entreprise concernée.
normalement apparaître qu'une fois.
Pour faciliter la consultation et le contrôle des rectifications ou
9.3 Conseil concernant la diffusion de la docu-
mises à jour, il importe d'utiliser une méthode de pagination
mentation
claire et précise.
II est important de faire une nette distinction entre l'ensemble
L'expérience montre qu'il est nettement avantageux d'adopter
complet de la documentation, normalement stocké dans un lieu
un système documentaire qui assure que
central, et les sous-ensembles dont peuvent avoir besoin les
divers services et agents.
a) chaque page est désignée par un code indiquant le
système, le chapitre, le numéro de page du chapitre, le
Ces sous-ensembles comprennent généralement les docu-
numéro de version et la date de diffusion;
ments recopiés et compilés à partir de différentes parties de la
documentation centrale. Pour chaque document, on devra éta-
b) chaque section est identifiée en totalité;
blir une liste de distribution en fonction des besoins des divers
où l'on notera le nom ou le code de service du des-
c) les insertions et suppressions sont clairement dési- organismes,
gnées. tinaire de la documentation.
8

---------------------- Page: 11 ----------------------
IS0 6592-1985 (FI
Annexe A
Spécifications de la documentation des programmes
(Cette annexe fait partie intégrante de la norme.)
A.l Introduction A.3 Informations générales
La présente annexe constitute une ligne directrice quant au
A.3.1 Fonctions
niveau de la documentation nécessaire à la documentation de
programme.
Donner l‘adresse des organismes ou personnes chargés
Les éléments de documentation doivent être plus détaillés que - de l’élaboration;
le reste du texte de la présente Norme internationale.
- de l’exploitation;
Les exigences quant au niveau de détail sont par conséquent
- de l’entretien;
Q) publiées sous forme d’annexe.
-
de toute mise au point ultérieure du programme.
A.3.2 Obligations contractuelles
A.2 Identification
Donner suffisamment de renseignements sur les obligations
A.2.1 Nom du programme
contractuelles y compris les coûts, s’il y a lieu, c’est-à-dire:
-
les aspects juridiques des droits d‘auteur, de la confi-
Donne le titre ou le nom du programme ainsi qu‘un sous-titre
dentialité et de la sécurité, etc. ;
qui en résume les fonctions.
-
les modules fournis et le prix d’achat ou de location
correspondant;
A.2.2 Variantes
- la mise en service;
Donne les noms utilisés pour identifier les variantes au pro-
gramme existant simultanément.
- la formation;
- l’entretien;
A.2.3 Version
- le contr8le qualité.
En plus du nom du programme et des noms des variantes, elle
sert à identifier la version pour la distinguer des autres versions
A.3.3 Objet et domaine d‘application
0
obtenues par des modifications apportées successivement. La
documentation doit refléter les modifications apportées à la
A.3.3.1 Décrire brièvement les objectifs que peut permettre
version existante et être tenue à jour.
d’atteindre le programme.
A.2.4 Date
A.3.3.2 Indiquer le
...