Centre national de la recherche scientifique Direction des systèmes d'information
Guide méthodologique
Gestion de la documentation des projets informatiques
Référence : CNRS/DSI/BQSD/conduite-projet/developpement/guide-gestion-doc
Date de dernière mise à jour : 19 février 2001
Etat : terminé
Auteurs : F.Villeneuve
Objet :
Ce document est un guide pour gérer la documentation au sein d'une équipe projet à la DSI : mettre en oeuvre des moyens pour référencer de manière homogène l’ensemble de la documentation relative à chaque projet, en organiser la production, le classement et l’accès.
| Version du document | Date | Objet de la mise à jour |
| V1.0 | 17 février 1995 | Création du document |
| v1.1 | 07 mars 1996 | Diverses mises à jour (noms de documents référencés...) Remplacement de la fiche de synthèse par la fiche de relecture Ajout du classement de la documentation papier (armoire et feuille d'emprunt) Ajout de la gestion des versions Compléments sur la gestion physique des fichiers Ajout du plan et dossier de tests de validation, mise à jour des définitions des niveaux de test |
| v1.2 | 01 septembre 99 | Changement de dénomination de la DSI : Délégation aux systèmes d'information devient "Direction des systèmes d'information". |
| v1.3 | 19 février 2001 | Mise en forme et ajustements |
Sommaire
4.1- LES ACTEURS ET LEURS RESPONSABILITÉS............................................................................. 4
4.2 CYCLE DE VIE D’UN DOCUMENT.............................................................................................. 5
4.2.1 Production du document................................................................................................ 6 4.2.2 Vérification/validation du document ............................................................................. 6
4.2.3 Archivage du document ................................................................................................. 7
4.3 IDENTIFICATION ET STRUCTURE DE LA DOCUMENTATION....................................................... 7
4.3.1 Identification.................................................................................................................. 7
4.3.2 Structure ........................................................................................................................ 8
4.4 GESTION DES VERSIONS - RÉVISIONS....................................................................................... 9
4.5 OUTILS DE PRODUCTION DE LA DOCUMENTATION.................................................................. 9
4.6 CLASSEMENT ........................................................................................................................ 9
4.7 GESTION PHYSIQUE DES FICHIERS CONTENANT LES DOCUMENTS........................................... 10
4.7.1 Répertoires................................................................................................................... 10 4.7.2 Noms des fichiers......................................................................................................... 10
4.7.3 Procédures de sauvegarde et archivage...................................................................... 10
5.1 DOCUMENTS DE GESTION DE PROJET..................................................................................... 11
5.2 DOCUMENTS D’ÉTUDE ET DÉVELOPPEMENT.......................................................................... 12 5.3 DOCUMENTS RELATIFS À LA MISE EN OEUVRE ...................................................................... 13 5.4 DOCUMENTS RELATIFS À LA QUALITÉ.................................................................................. 14
Rappel : documentation: ensemble de documents relatifs à un projet - notice - mode d’emploi action de sélectionner, classer, utiliser ou diffuser des documents. (Source : Le Petit Larousse 1994)
La documentation d’un projet a une importance primordiale : c’est l’outil de communication et de dialogue entre les membres de l’équipe projet et les intervenants extérieurs (membre des instances de pilotage, chef de projet, utilisateurs, etc...). Elle assure aussi la pérennité des informations au sein du projet.
Afin d’organiser la gestion de la documentation produite par projet, il convient au préalable d’identifier tous les types de documents relatifs aux diverses étapes d’un projet, de les référencer de manière homogène pour ensuite définir un mode de gestion commun à tous les projets.
• AFNOR Z 67 - 100-1 "Système d’information documentaire en ingénierie informatique" :
positionnement de la documentation dans le déroulement des projets et dans la relation ClientFournisseur.
• AFNOR Z 67 - 100-2 "Management de la documentation dans un contexte d’assurance qualité"
• AFNOR Z 67 - 100-3 "Contenus type de la documentation courante des projets informatiques"
• Plan type « Document de projet »
• Plan type « Fiche de relecture »
• Plan type « Journal de la documentation »
• Plan type « Fiche d'emprunt »
Les définitions des différents types de documents sont données en annexe du présent guide.
Ce chapitre précise les règles de gestion de la documentation à mettre en oeuvre dans tout projet.
Pour mieux comprendre la nécessité d’une gestion rigoureuse de la documentation, il convient en premier lieu de détailler les états par lesquels passe un document avant d’être diffusé ainsi que le rôle des différents acteurs.
Les différents acteurs sont :
• le chargé de la gestion documentaire (généralement le responsable qualité du projet),
• le(s) auteur(s) du document,
• les responsables de la vérification (membres de l’équipe projet ou intervenants extérieurs),
• les responsables de la validation (une ou plusieurs personnes désignées).
| ACTEUR | RESPONSABILITES |
| Chargé de la gestion de la documentation du projet | . diffusion homogène des outils de production de documents, . supervision du fonctionnement courant, . définition et respect des règles d’identification, de structuration et de classement, . contrôle de la cohérence et de l’homogénéité dans la gestion et les extensions de la documentation du projet, . décisions d’archivage ou de suppression de documents. |
| Auteur (un document peut être produit par plusieurs auteurs : un auteur princi- pal doit être désigné et référencé sur le document en tête de liste des auteurs) | . objectifs et contenu du document . diffusion vers les destinataires identifiés (cycle de vie prévu pour le document) . gestion des mises à jour et des versions-révisions successives du document . mise à jour du journal de la documentation (liste de tous les documents produits par le projet) . sauvegarde du document. |
| Responsable de la vérification . contrôle de la conformité par rapport aux standards méthodologiques (contenu attendu du document) et aux règles de présentation et structuration des documents. | |
| Responsable de la validation | . évaluation de la pertinence, la correction et la complétude du contenu, par rapport aux objectifs du document. |
Un document passe par un certain nombre d'états :
| Etat | Signification |
| travail | le document est en cours d'élaboration par l'auteur |
| terminé | le document satisfait l'auteur; il est prêt à être diffusé |
| vérifié (optionnel) | le document est approuvé par d'autres membres de l'équipe, des intervenants extérieurs et/ou le contrôle qualité |
| validé | le document est approuvé par les personnes habilitées et prend valeur de référence au sein du projet |
| périmé | le document n’est plus adapté et est donc retiré à tous ses détenteurs (retrait d'usage) |
| archivage | le document n'est plus consulté régulièrement, mais une trace de son existence demeure (pour une durée définie par le chargé de gestion de la documentation du projet) |
| destruction | - le document n'est pas archivé ou - le délai d'archivage est écoulé |
La conclusion de la vérification/validation doit être écrite dans un document, de sorte que l'auteur puisse garder une trace formelle de l'application du cycle de vie prévu pour le document.
Un document en cours de production est dans l'état "travail".
Lorsque l'auteur obtient une rédaction qui le satisfait et ne souhaite plus apporter de modifications, il l'indique en le faisant passer à l'état "terminé".
Avant de faire passer un document en l'état "terminé", l'auteur peut le soumettre à des lectures croisées au sein de son équipe.
Il joint à son document une fiche de relecture où les remarques éventuelles des vérificateurs ou validateurs sont formalisées (modifications souhaitées).
Toutes les remarques de fond sur le contenu du document (imprécision, ambiguïtés, incohérences...) doivent être consignées dans cette fiche sauf les remarques relatives à la forme du document (fautes de frappe, d'orthographe, problèmes de mise en page...) qui peuvent être signalées directement sur la copie papier du document.
Si les modifications du texte sont importantes, elles sont juste référencées dans la fiche de relecture puis décrites directement sur une copie papier du document.
La fiche de relecture comporte les éléments suivants :
• Une partie renseignée par l'auteur (avant transmission au vérificateur/validateur)
• nom du demandeur
• date de la demande
• nom et référence du document
• date de retour pour les remarques
• aspects à examiner (contenu, forme, totalité, partie...)
• Une partie renseignée par le vérificateur/validateur
• nom du vérificateur ou validateur • date de vérification ou validation
• conclusion de la vérification ou validation :
• document validé,
• document validé après intégration des modifications par l'auteur,
• document à revalider (nécessite un nouveau passage en vérification/validation après intégration des modifications par l'auteur),
• liste des points à modifier dans le document (numéro de §, page, description de la modification ou référence à une annotation dans la copie papier du document jointe).
Cette fiche (ainsi qu'éventuellement le document annoté joint) est transmise à l'auteur.
L'auteur répond aux remarques émises par les relecteurs dans la colonne "justification réponses" de la fiche prévue à cet effet.
L'auteur conserve une copie papier de la fiche.
L'auteur du document est chargé d'indiquer en page de garde du document l'état dans lequel le document se trouve, ainsi que les noms des vérificateurs/validateurs et les dates de vérification/validation.
NB : Pour chaque document à valider, une date de retour des remarques est convenue. Si aucun retour n'est parvenu à l'auteur à la date prévue, le document est considéré comme validé.
Lorsqu'un document est périmé, le responsable chargé de la gestion de la documentation l'archive et veille à informer tous les détenteurs du document de sa cessation d'applicabilité.
Afin d’assurer l’efficacité de la gestion de la documentation, il faut prévoir un mécanisme normalisé d’identification des documents (homogénéité).
Ainsi, chaque document reçoit une référence unique au sein du projet, constituée de plusieurs champs (cette référence apparaît en page de garde et sur chacune des pages du document) : nom_du_projet / nature_de_document / identification_du_document
a) nom du projet : CNRS/DSI/#PROJET#
b) nature de document (sur 2 caractères) :
. documents de gestion : GE
. documents de développement : en fonction de l'étape dans laquelle est produit ou utilisé le document technique :
* étape d'étude préalable : EP
* étape d'étude détaillée (ou fonctionnelle) : ED
* étape d'étude technique : ET
* étape de réalisation : RE
* étape de réception : RC
. documents de mise en oeuvre : MO, et plus spécifiquement :
* documents liés à la documentation utilisateur : DO
* documents liés à la formation des utilisateurs : FO
* documents liés au laboratoire d'évaluation : LE . documents qualité : QU
c) identification du document
. pour les documents techniques, de tests, ou liés à la qualité : nom du module ou de la procédure
PTUTI(document d'étude technique/Plan de Tests Unitaires et d'Intégration) PACQ(document qualité/Plan d'Assurance et Contrôle Qualité) . pour les documents de type courrier, utiliser l'outil NUMELEC.
Il est convenu que tout document doit comporter les éléments suivants sur la page de garde :
• le titre du document,
• la référence du document,
• la date de dernière mise à jour,
• le numéro de version de l'application concernée par le document (VX.x),
• l'indice de révision du document (numéro chronologique : 00, 01...) par rapport à la version de l'application,
• l’état du document (ex : travail),
• le nom de l’auteur (ou des auteurs),
• l’objet du document (présentation rapide du contenu)
• pour les documents faisant l'objet d'une vérification et/ou d'une validation, le cartouche de visa (noms des destinataires, objet de la diffusion - validation, vérification, information- , dates de visa).
D’autre part, sur chaque page du document préciser :
• le titre du document,
• la référence,
• la date de dernière mise à jour,
• le numéro de page / nombre de pages total.
Une table des mises à jour des documents (après la page de garde) permet de retracer les différentes étapes qu’a suivies le document et se décompose de la façon suivante : • le numéro de version de l'application concernée par le document (VX.x),
• l'indice de révision du document (00, 01...),
• la date de dernière mise à jour de cette révision,
• l’objet de la mise à jour du document par rapport à la révision précédente.
Chaque document comprend un sommaire, qui reprend les titres des chapitres et des différents paragraphes et précise les numéros de pages correspondants.
NB : GESTION DE LA DATE
Chaque modification de version d’un document doit être soumise aux mêmes dispositions d’approbation que les documents initiaux (voir chapitre 2.2 : "cycle de vie d’un document").
L’auteur de la modification est responsable :
• du respect du cycle de vérification et validation,
• de la modification de l'indice de révision, • de la diffusion de la nouvelle version,
• de la sauvegarde des modifications.
Le numéro de version qui apparaît sur un document correspond à la version de l'application logicielle concernée.
L'indice de révision est propre au document :
• il est remis à 00 lors à chaque nouvelle version de l'application
• il est incrémenté à chaque modification du contenu du document devant faire l'objet d'une diffusion (il n'est pas incrémenté pour des corrections portant sur la forme du document - fautes de frappe, d'orthographe, ...).
Pour certains documents, il est important de faire apparaître clairement les évolutions d'une révision à l'autre du document. A cet effet, l'option Outils/Suivi des modifications de Word est utilisée.
Les corrections de fautes d'orthographe, de frappe ou de mise en page ne doivent pas apparaître avec des marques de révision. Pour cela, effectuer ce type de modifications sur le document initial (exemple : dans ED_ASTTO2.doc) avant de le dupliquer.
Attention :
Le document original choisi pour effectuer la révision, est fonction du destinataire auquel s'adresse cette révision :
• soit le destinataire aura en main toutes les révisions successives du document ;
• soit le document transmis fera la somme de toutes les relectures successives.
4.5 Outils de production de la documentation
Tout nouveau document est produit sur PC, avec les logiciels WORD, EXCEL ou Powerpoint.
• référence du document,
• date de création,
• auteur(s),
• titre,
• outil de production du document (word, excel... - PC)
NB : Chaque auteur de document est responsable de la mise à jour du journal de la documentation du projet.
Un exemplaire papier de chaque document du projet est disponible dans l'armoire de la documentation du projet. Une feuille d'emprunt permet de connaître la localisation des documents sortis de l'armoire.
4.7 Gestion physique des fichiers contenant les documents
Les documents du projet sont accessibles en consultation à tous les membres de l'équipe projet sur serveur, dans un répertoire clairement identifié par le nom du projet.
Un sous-répertoire est créé par nature de document à gérer. Les noms de ces répertoires reprennent les codes de la nature du document : GE, EP, ED, ET, RE, RC, MO, QU.
Le nom de chaque fichier rappelle la référence du document : nature-de-document "_" identification-du-document
La nature du document est rappelée dans le nom de fichier afin qu'il n'y ait pas de confusion entre des documents ayant la même identification mais pas la même nature (exemple : identification STRUC mais nature ED ou ET).
Dérogation : la nature du document peut ne pas être inclue dans le nom du fichier si aucune confusion n'est possible entre 2 documents.
Remarque : lorsqu'il est nécessaire de sauvegarder plusieurs révisions de documents, l'indice de révision est ajouté en fin du nom de fichier.
Le répertoire du projet est sauvegardé chaque soir par la procédure automatique du serveur.
Lorsque le développement d'une version de l'application est terminée, la documentation est archivée. Les dernières révisions des documents applicables sont transférées dans un nouveau répertoire identifié par le numéro de la prochaine version.
Le tableau des principaux documents produits par le projet est donné ci-après.
• nom : titre du document (que l'on retrouvera en page de garde du document et dans le journal de la documentation)
• auteur : personne(s) chargée(s) dans le projet de produire le document, de le transmettre aux destinataires donnés et de le mettre à jour suite aux retours éventuels des destinataires
• périodicité : fréquence de production du document et étape du projet concernée • destinataires : liste des personnes auxquelles le document est destiné pour action
• missions : exploitation du document à faire par les destinataires :
• vérification : action de contrôle de la forme et du contenu pour commentaires ou enrichissements éventuels, et pour s'assurer de la conformité aux standards définis sur le projet (principalement dans le plan d'assurance et contrôle qualité)
• validation : action de donner un avis par rapport au contenu (fond) du document, permet d'établir le document comme une référence au sein du projet et de passer à l'étape suivante
• information : diffusion pour consultation, sans retour attendu de la part du destinataire
• action : diffusion pour application des recommandations/décisions données dans le document
N = Nature de document (GEstion - Etude Détaillée - Etude Technique - REalisation - RéCeption -
FOrmation - DOcumentation - Laboratoire d'Evaluation - Mise en Oeuvre - QUalité)
| Nom | Auteur | Périodicité | Destinataires | Missions | N | |||||
| 1. Gestion de projet | ||||||||||
| Planning | - resp. équipe ou - chef de projet | réunions de l'équipe | - équipe projet - chef de projet | - action - validation | GE | |||||
| Journal de bord (JBORD) | - chef de projet | réunions de l'équipe | - équipe projet | -information, action | GE (RISQ) | - chef de projet - resp. qualité | identification d'un risque | - direction DSI | -information, action (décision) | GE |
| Dossier instances de pilotage du projet - comités (comptes-rendus, convocations, doc de travail, liste des membres) | - chef de projet | tout au long du projet | - présidents descomités - membres descomités - équipe projet | - validation - information - information | GE | |||||
| Bilan de projet (interne DSI) (BILAN) | - chef de projet | fin du projet | - resp. qualité - équipe projet - direction DSI | - vérification - information - information | GE | |||||
| 2. Gestion des moyens financiers | ||||||||||
| Suivi du budget (consommé et prévisionnel) | - chef de projet | réunion de suivi de projet | - responsable gestion à la DSI | - information | GE | |||||
| Factures | - chef de projet | arrivée de factures | - secrétariat | - action (saisie XLAB) | GE | |||||
| 3. Gestion de la documentation et configuration logicielle | ||||||||||
| Journal de la documentation (JDOC) | - équipe projet | production de doc | - chef de projet - responsablequalité | - information - vérification | GE | |||||
| Etat de la configuration logiciel | - resp. réalisation | modification, livraison | - chef de projet - équipe réalisation - resp. qualité | - information - information - vérification | GE | |||||
| 4. Secrétariat / Logistique | ||||||||||
| Chrono courrier | - assistante | arrivée/départ de courrier | - équipe projet | - information | GE | |||||
| Nom | Auteur | Périodicité | Destinataires | Missions | N |
| Dossier d'étude préalable | - équipe spécification | étape d'étude préalable | - resp. qualité - chef de projet - comités | - vérification - validation - validation | |
| Dossier d'étude détaillée (spécifications fonctionnelles) | - équipe spécification | étape d'étude détaillée | - resp. qualité - chef de projet - comités - équiperéalisation - resp. mise enoeuvre | - vérification - validation - validation - action - information | ED |
| Dossier d'étude technique (spécifications techniques) | - équipe réalisation | étape d'étude technique | - resp. qualité - chef de projet - équiperéalisation | - vérification - validation - action (code) | ET |
| Dossier de programmes | - équipe réalisation | étape de réalisation | - resp. qualité - équiperéalisation | - vérification - action (tests) | RE |
| Plan de tests unitaires et d'intégration (PTUTI) | - équipe réalisation | étape d'étude technique | - resp. qualité - chef de projet - équiperéalisation | - vérification - validation - action (tests) | RE |
| Plan de tests de validation (PTV) | - équipe réalisation | étape d'étude technique | - resp. qualité - chef de projet - équiperéalisation | - vérification - validation - action (tests) | RE |
| Plan de tests de non régression (PTNR) | - équipe réalisation | étape d'étude technique | - resp. qualité - chef de projet - équiperéalisation | - vérification - validation - action (tests) | RE |
| Protocole de réception interne (recette) (PRCI) | - équipe réception | étape d'étude détaillée | - resp. qualité - chef de projet - équipeconception | - vérification - validation - action (tests) | RC |
| Dossier de réception interne (cahier de recette) (DRCI) | étape d'étude détaillée (préparation de tests) puis étape de réalisation (phase de réception) | - resp. qualité - chef de projet - équipeconception | - vérification - validation - information,action | RC |
| Nom | Auteur | Périodicité | Destinataires | Missions | N |
| 1. Communication | |||||
| Présentation générale de projet | - chargé de la communication | étape de préparation de la mise en oeuvre | - chef de projet - utilisateurs - comités | - validation - information - information | MO |
| 2. Documentation d'utilisation | |||||
| Manuel d'utilisation Manuel d'installation Manuel d'exploitation Manuel de référence | - chargé de la documentation | étape de préparation mise en oeuvre | - resp. qualité - chef de projet - comités - laboratoired'évaluation - sites pilotes - utilisateurs | - vérification - validation- information - action : utilisation/retours - action : utilisation/retours - action : utilisation | DO |
| 3. Formation des utilisateurs | |||||
| Plan de formation | - chargé de la formation | étape de préparation mise en oeuvre | - chef de projet - comités - interlocuteurs DS, DR | - validation - validation - information | FO |
| Calendrier des formations | - chargé de la formation | étape de préparation mise en oeuvre | - chef de projet - interlocuteurs DS, DR | - validation - information | FO |
| Support de formation (transparents + cahier d'exercice) | - chargé de la formation | étape de préparation mise en oeuvre | - équipe réalisation - resp. mise enoeuvre - utilisateurs - validation - action | FO | |
| Fiche d'évaluation de formation | - utilisateurs - formateurs | fin d'une session de formation | - chargé de la formation | - information | FO |
| Bilan de formation | - chargé de la formation | fin d'un ensemble de sessions de même type | - reponsable miseen oeuvre - chef de projet - comités | - information - information - information | FO |
| 4. Laboratoire d'évaluation | |||||
| Préparation du laboratoire d'évaluation | - ergonome DSI | avant le passage en laboratoire | - équipe projet - participants aupassage en laboratoire | - validation - action(tâches, scénarios) | LE |
| Synthèse des résultats | - ergonome DSI | après le passage en laboratoire | - chef de projet - équipe projet | - validation - action | LE |
| 5. Réception externe (passage en site pilote) | |||||
| Protocole de réception externe (PRCE) | - chargé des sites pilotes | avant la diffusion en sites pilote | - équipe réception - chef de projet - sites pilotes | - vérification - validation - action | MO |
| Dossier de récep tion externe (DRCE) | - chargé des sites pilotes | étape de sites pilotes | - sites pilotes - chef de projet | - action(tests) - validation | MO |
| Nom | Auteur | Périodicité | Destinataires | Missions | N |
| Plan d'assurance et contrôle qualité (PACQ) | - resp. qualité | début de projet | - chef de projet - équipe projet | - validation - action (application) | QU |
| Dossier de suivi qualité (bilans,CR revues, mesures) | - resp. qualité | tout au long du projet | - chef de projet - équipe projet | - information - information,action | QU A--------------------------------------------------------------------------------------------------AIDE-MEMOIRE OU "MEMO" (AIDE-MEMOIRE) Définition : Document présentant l'application informatique sur un support réduit (en général cartonné et/ou plastifié) contenant les modes d'accès aux différentes fonctions et les commandes disponibles. Domaine d'application : Documentation de mise en oeuvre - manuel d'utilisation AIDE EN LIGNE (AIDE EN LIGNE) Définition : Support documentaire fournissant à l'utilisateur les informations nécessaires à l'utilisation directe de l'application, par réponse interactive à toute question qu'il peut se poser lors de la manipulation des procédures mises à sa disposition. Cette information s'obtient en frappant sur une touche "aide" (ou "?") et apparaît dans une zone particulière de l'écran (lignes spécifiques ou fenêtre). Domaine d'application : Documentation de mise en oeuvre - manuel d'utilisation AVENANT (DOCUMENT D'ENGAGEMENT COMPLEMENTAIRE)Définition : Document contenant les éléments qui modifient les conditions initiales de la convention. Domaine d'application : Documentation de relation contractuelle B--------------------------------------------------------------------------------------------------BILAN DE PROJET (BILAN DE PROJET) Définition : Document analysant objectivement les succès ou les difficultés rencontrées et faisant part de toute disposition susceptible d'être retenue dans le futur pour l'amélioration de la qualité des produits et du déroulement des projets. Domaine d'application : Documentation de gestion de projet. BILAN QUALITE INTERNE (RAPPORTS D'AUDIT INTERNE) Définition : Document visant à vérifier la mise en oeuvre et l'efficacité du système qualité pour le projet. L'audit est mené indépendamment de l'avancement du projet. Domaine d'application : Documentation qualité Définition : Document fourni par le demandeur (client) au développeur (fournisseur), décrivant le plus explicitement possible le contenu de la prestation et de la fourniture attendue et des éventuelles contraintes concernant les conditions techniques de développement, d'exploitation et de qualité. En cas de sous-traitance avec engagement forfaitaire, doit être suffisamment précis, explicite et non évolutif pour que le fournisseur puisse s'engager sur un budget et un délai. Domaine d'application : Documentation de relation contractuelle D--------------------------------------------------------------------------------------------------DOSSIER D'ETUDE PREALABLE (RAPPORTS DE L'ETUDE PREALABLE)Définition : Dossier regroupant l’expression des besoins et les exigences de l’établissement puis décrivant de manière globale pour l’ensemble du domaine d’étude, les fonctions, l’organisation, l’architecture technique, les contraintes majeures de sécurité et de performance, les interfaces avec d’autres systèmes... Une étude de l’existant approfondie peut être menée si nécessaire. Différentes solutions d’organisation ou techniques peuvent être approfondies par les experts systèmes d’information. Domaine d'application : Documentation d'étude et de développement DOSSIER D'ETUDE DETAILLEE / SPECIFICATIONS DETAILLEES (FONCTIONNELLES) (RAPPORTS DE L'ETUDE DETAILLEE) Définition : • Si l'étude détaillée fait suite à une étude préalable, document consistant à décrire et compléter de manière exhaustive l'avant-projet qui en est issu. • Si l'étude détaillée n'est pas consécutive à une étude préalable (cas des petits-projets), document consistant à présenter la solution au plan fonctionnel avant d'en détailler les parties sous forme de spécifications de réalisation. Domaine d'application : Documentation d'étude et de développement DOSSIER D'ETUDE TECHNIQUE / SPECIFICATIONS TECHNIQUES (DOSSIER D'ANALYSE TECHNIQUE) Définition : Document prolongeant les dossiers de spécifications détaillées (fonctionnelles) et constituant la traduction informatique des fonctionnalités à réaliser. Domaine d'application : Documentation d'étude et de développement DOSSIER DE PROGRAMMES (DOSSIER DE PROGRAMMES) Définition : Dossier visant à donner une description technique de chaque programme à partir des spécifications techniques. Ceci constituera une référence pour la maintenance ou pour l'évolution ultérieure du système. Domaine d'application : Documentation d'étude et de développement DOSSIER DE RECEPTION (DOCUMENTS DE QUALIFICATION)Définition : La réception consiste à s'assurer de la conformité du logiciel aux spécifications externes, en fonction des modalités des tests. Selon les logiciels, elle peut porter sur : • le fonctionnement de modules particuliers • l'intégration • la qualification fonctionnelle. On retrouve dans ce document la trace des sessions effectuées par l'équipe de réception : • les observations qui ont été faites • la trace des défaillances dont la description a été transmise pour correction à l'équipe de développement • les retours d'information sur les modifications apportées par l'équipe de développement • le travail de réception fait et à faire. Domaine d'application : Documentation d'étude et de développement DOSSIER DE SUIVI DE PROJET (DOCUMENTS DE SUIVI DE PROJET) Définition : Domaine d'application : Documentation de gestion de projet M -------------------------------------------------------------------------------------------------MANUEL D'EXPLOITATION (MANUEL D'EXPLOITATION) Définition : Support permettant aux utilisateurs informaticiens (exploitants, opérateurs et pupitreurs) d'exploiter l'application informatique sur les systèmes (ordinateurs, réseaux, etc.) dont ils peuvent utiliser les ressources. Ce document comprend cinq modules : • un sous-dossier général qui sert à présenter l'application • un sous-dossier spécifique de mise en exploitation : complément du manuel d'installation pour toutes les procédures particulières de migration et de transition • un sous-dossier relatif aux traitements d'exploitation courante : un sous-dossier par traitement, qu'il s'agisse de batch, de TP (transactionnnel) ou mixte (ex. télétraitement, considéré comme un traitement se déroulant entre deux sauvegardes) • un sous-dossier sécurité, décrivant l'ensemble des procédures à mettre en oeuvre en cas d'incident • un sous-dossier archivage, décrivant les procédures d'archivage (en matière d'indicateur volumétrique, de date de validité ou de préemption, etc.) sur un support particulier tel que bande magnétique (ou "streamer") ainsi que les procédures de restauration pour retraitements éventuels. Domaine d'application : Documentation de mise en oeuvre MANUEL D'INSTALLATION (MANUEL D'INSTALLATION) Définition Document décrivant les étapes à suivre lors de la mise en oeuvre d'une application de taille moyenne ou importante sur un ou plusieurs gros systèmes (unité centrale ou serveur). Il peut être composé d'un ou plusieurs supports documentaires, par exemple : • le guide d'installation, • le guide d'installation en réseau, • paramétrage, • ... Documentation de mise en oeuvre MANUEL DE REFERENCE (pas d'équivalent AFNOR) Définition : Compilation des éléments contenus dans les documents d'étude et de développement du logiciel (i.e. description technique de chaque cas d'erreur possible, chaque écran, chaque co |
