Centre national de la recherche scientifique Direction des systèmes d'information REFERENTIEL QUALITE Procédure Qualité Gestion des modifications d un proj système d'information Référence : CNRS/DSI/conduite-proj/maintenance-evolution/proc-gestion-modification Date de dernière mise à jour : 30 octobre 2002 Version : 01 Etat : Terminé Auteurs : Y. Soler Diffusion : DSI Obj : Cte procédure a pour but de décrire le processus de gestion des modifications au sein d'un proj de la DSI.
Table des mises à jour du document Version du document Date Obj de la mise à jour 00 2 Mai 2001 Création du document 01 30 octobre 2002 Suppression de références trop précises aux projs CNRS/DSI/conduite-proj/maintenance-evolution/proc-gestion-modification.doc 30 octobre 2002 2/20
Sommaire 1 - OBJET ET DOMAINE D APPLICATION...4 2 - DOCUMENTS DE RÉFÉRENCE...4 3 - ABRÉVIATIONS ET TERMINOLOGIE...4 4 - PRINCIPES D ÉLABORATION...4 4.1 PROCESSUS DE GESTION DES ADAPTATIONS ET DES ÉVOLUTIONS...4 4.2 PROCESSUS DE GESTION DES ANOMALIES LOGICIEL (MODIFICATIONS DE TYPE CORRECTIF)...10 5 - CONTENU TYPE DES DOCUMENTS...11 5.1 - PORTEFEUILLE DES DEMANDES DE MODIFICATION...11 5.2 - DEMANDE D INTERVENTION...12 5.3 - MODIFICATION DE DOCUMENT APPLICABLE...15 5.4 - SUIVI DES DEMANDES D INTERVENTION ET DES MODIFICATIONS DE DOCUMENT APPLICABLE...16 5.5 - PRÉCISION DE DOCUMENT APPLICABLE...16 5.6 - SUIVI DES PRÉCISIONS DE DOCUMENTS APPLICABLES...19 5.7 - FICHE D ANOMALIES...19 5.8 - TABLEAU RÉCAPITULATIF DES ANOMALIES...20 CNRS/DSI/conduite-proj/maintenance-evolution/proc-gestion-modification.doc 30 octobre 2002 3/20
1 - OBJET ET DOMAINE D APPLICATION Les demandes de modifications intervenant après la constitution du cahier des charges vers l'équipe de TMA font l'obj de procédures de gestion spécifiques. Les modifications peuvent être de natures différentes : - adaptation ou évolution du périmètre fonctionnel, technologique ou organisationnel, - correction suite à une non-conformité (anomalie dans le logiciel ou dégradation de la base de production). Sera considérée comme urgente,(degré immédiat) toute demande de modification présentant un caractère bloquant (sans solution de contournement existante) pour le système d'information ou toute demande présentant un caractère impératif en terme de délai. Ces activités sont mises en œuvre lors du développement initial d'un système d'information ou à chaque itération de développement d'une nouvelle version en phase de MAINTENANCE/EVOLUTION. 2 - DOCUMENTS DE REFERENCE Plans types : «plan-type-suivi-dm» «plan-type-di» «plan-type-mda» «plan-type-suivi-di-mda» «plan-type-pda» «plan-type-suivi-pda» «plan-type-fa» «plan-type-recap-fa» 3 - ABREVIATIONS ET TERMINOLOGIE DM : Demande de Modification DI : Demande d'intervention MDA : Modification de Document Applicable PDA : Précision de Document Applicable FA : Fiche d'anomalie cf. Glossaire «Conduite de proj Systèmes d information» 4 - PRINCIPES D ELABORATION 4.1 Processus de gestion des adaptations des évolutions Le chef de produit DSI est chargé des relations avec la maîtrise d'ouvrage. Il collecte valide les nouvelles demandes envoie les demandes d'intervention (DI) à l'équipe de TMA. L'équipe de conception quant à elle à pour mission de collecter, de décrire, de suivre, d'analyser les demandes de modification (DM) avant de les formaliser en demandes d'intervention (DI). Toutes les demandes collectées sont enregistrées dans un " portefeuille des modifications " (SUIVI_DM). CNRS/DSI/conduite-proj/maintenance-evolution/proc-gestion-modification.doc 30 octobre 2002 4/20
Instances décisionnelles Equipe produit DSI Equipe de TMA Correspondant fonctionnel Comité utilisateurs, utilisateurs... depuis la phase d EXPLOITATION/ UTILISATION Equipe produit DSI 2 Donner son avis sur l'opportunité les priorités Comité utilisateurs Avis, priorités 3 Valider les DM comité de suivi validation expression de besoins demande d'évolution ou anomalie du logiciel 1 Collecter analyser les DM Chef de produit équipe de conception demande de modification Mise à jour du portefeuille des DM DM non validée DM non prise en compte ou DM validée 4 Rédiger la Demande d'intervention (DI) Equipe de conception Mise en attente pour un version future Enregistrer la DI sur le serveur 5 Envoi des DI Chef de produit Chef de produit équipe de conception Chiffrage ou accepté 7 Vérifier le chiffrage Chiffrage non accepté Mise à jour du tableau de suivi DM DI_MDA mèl avec DI complétée mèl avec DI associée 6 Chiffrer les DI mise à jour de la version électronique Equipe de TMA mèl avec DI associée Correspondant fonctionnel 8 Définir le cahier des charges Chef de produit Mise à jour du tableau de suivi DI_MDA 9 Informer l'équipe de TMA du lancement de la réalisation Chef de produit vers la phase de DEVELOPPEMENT (étape de réception interne) 10 Réaliser les DI Equipe de TMA CNRS/DSI/conduite-proj/maintenance-evolution/proc-gestion-modification.doc 30 octobre 2002 5/20
Les demandes de modification (DM) peuvent être émises par le correspondant fonctionnel, des membres de l'équipe produit DSI ou par des utilisateurs (via le comité des utilisateurs, ou directement au cours de formations de l'assistance aux utilisateurs, du passage en laboratoire d'évaluation ou en sites pilotes par exemple). Etape 1 : Collecter étudier les demandes de modifications L'équipe de conception centralise toute les DM. Chaque demande est référencée de la manière suivante : DM#code domaine#aa#nnn# ou aa correspond aux 2 chiffres de l'année nnn est un numéro chrono remis à zéro chaque année. Ensuite, chaque DM est analysée par l'équipe de conception afin d'identifier précisément la nature de la demande, l'urgence de décrire clairement l'énoncé. Des pièces complémentaires (rapport, courrier, fax ) peuvent être jointes à la demande. Dans ce cas, la référence de la demande est indiquée sur la pièce jointe. Toutes les demandes de modifications sont centralisées dans un "portefeuille de demandes de modification" propre à chaque application. Ce document est tenu à jour par l'équipe produit DSI se trouve dans le répertoire #proj#/ge/suivi_tma/dm/suivi_dm.xls. Ce document n'est pas diffusé à l'équipe de TMA. Etape 2 : Donner son avis sur l'opportunité les priorités Si besoin est, les évolutions majeures peuvent être présentées au comité des utilisateurs qui donne alors son avis sur l'opportunité d'effectuer ces modifications sur les priorités de réalisation. Etape 3 : Valider les demandes de modification La liste complète des demandes de modification est proposée au comité de suivi de validation qui décide pour chaque demande : - de la rajouter au cahier des charges de la version suivante de l'application, - de la mtre en attente pour une version future de l'application, - de ne pas prendre en compte la demande. Etape 5 : Mtre à jour le portefeuille des DM Après réception des décisions du comité de suivi de validation, l'équipe de conception actualise le "portefeuille de demandes de modification" (suivi-dm.xls) afin de tenir à jour l'état de chaque DM. Etape 4 : Rédiger la demande d'intervention (DI) Les demandes de modification validées sont alors formalisées en demandes d'intervention par l'équipe de conception. Une demande d'intervention est une fiche à destination de l'équipe de TMA, dans laquelle se trouve la spécification de l'adaptation ou de l'évolution à réaliser ou qui fait référence à un document d'étude détaillée qui contient la spécification de l'évolution à réaliser. Chaque document DI est nommé DI_apl_xxxnnn.doc, avec : apl = code de l'application concernée xxx = facultatif, découpage propre à l'application en sous-domaines ou modules nnn = numéro chrono En complétant la DI, l'équipe de conception crée ou m à jour un document d'étude détaillée qui sera joint lors de l'envoi de la DI à l'équipe de TMA. Les DI les documents de spécification associés sont stockés dans un répertoire propre à l'application : #proj#/ge/suivi_tma/di_mda/ DI_apl_xxxnnn.doc. CNRS/DSI/conduite-proj/maintenance-evolution/proc-gestion-modification.doc 30 octobre 2002 6/20
Le portefeuille des demandes de modification (suivi_dm.xls) est complété par la référence de la DI qui a été générée. L'équipe DSI doit également actualiser le tableau de suivi des DI (suivi_di_mda.xls) qui est stocké dans le répertoire #proj#/ge/suivi_tma/di_mda/suivi_di_mda/suivi_di_mda.xls. Etape 5 : Envoi des DI à l'équipe de TMA Le chef de produit DSI envoie par mél à l'équipe de TMA les DI les documents associés. Il tient également à jour le tableau de suivi des DI (suivi_di_mda.xls). Etape 6 : Chiffrer la DI mise à jour de la version électronique L'équipe de TMA renseigne la partie réponse des DI les renvoie par mél au chef de produit DSI. Etape 7 : Vérifier le chiffrage Le chef de produit DSI l'équipe de conception analysent les réponses de l'équipe de TMA. Des réunions de présentation/mise au point des spécifications peuvent être organisées avec l'équipe de TMA afin de finaliser les DI d'éviter des modifications futures de DI. Après vérification, le chiffrage de la DI peut être accepté ou refusé. - Chiffrage refusé : Dans ce cas, le chef de produit DSI renvoie par un mél d'explication la DI associée à l'équipe de TMA pour un nouveau chiffrage. Il tiens également à jour le tableau de suivi des DI (suivi_di_mda.xls). - Chiffrage accepté : Après accord définitif avec l'équipe de TMA sur le contenu la planification de la prochaine version, l'ensemble des DI concernant l'application est rassemblé dans un cahier des charges (à ce stade, les DI sont signées par le chef de produit DSI par le titulaire). Le tableau de suivi des DI (suivi_di_mda.xls) est tenu à jour. Etape 8 : Définir le cahier des charges Le cahier des charges est constitué par la liste des DI concernant la version. Cte liste est établie en tenant comptes des exigences du comité utilisateur, du comité de suivi validation des contraintes en charge délai de réalisation établies lors du chiffrage. Le chef de produit DSI, en coordination avec le correspondant fonctionnel, valide le contenu de chaque version. Ce cahier des charges sera livré à l'équipe de TMA constitue un document applicable. Le cahier des charges de chaque version peut être découpé en plusieurs lots, concernant des sousensembles fonctionnels homogènes de l'application ou des demandes d'intervention de même nature. Ce découpage en lots perm une prévision des charges du planning du côté de l'équipe DSI aussi bien que du côté de l'équipe TMA, sans attendre un cahier des charges compl pour la version. Etape 9 : Informer l'équipe de TMA du lancement de la réalisation Le chef de produit adresse à l'équipe de TMA le cahier des charges pour réalisation. Un bon de commande ou un ordre de service confirmant le contenu de la version précisant les charges par DI le délai de réalisation est ensuite adressé par la DSI à l'équipe de TMA. Etape 10 : Réaliser les DI L'équipe de TMA est ensuite chargée de réaliser les DI puis livre la version. L'équipe de conception est chargée de s'assurer de la conformité de la livraison avec le cahier des charges. (Cf. Phase de DEVELOPPEMENT : Protocole de réception interne). CNRS/DSI/conduite-proj/maintenance-evolution/proc-gestion-modification.doc 30 octobre 2002 7/20
Après accord sur le cahier des charges : - les ajouts de nouvelles DI sont à éviter : elles peuvent remtre en cause les délais de réalisation de la version, - de même, les modifications des DI du cahier des charges sont à éviter. Si elles sont nécessaires, elles font l'obj d'un document spécifique la MDA (Modification de Document Applicable). Les MDA sont gérées de la même façon que les DI. Equipe produit DSI Equipe de TMA Modification d une DI Rédiger la MDA Equipe de conception Enregistrer la MDA sur le serveur Mise à jour du tableau de suivi DI_MDA Envoi MDA Chef de produit mèl avec MDA associée Vérifier le chiffrage Chef de produit équipe de conception mèl avec MDA complétée Chiffrer la MDA mise à jour de la version électronique Equipe de TMA Chiffrage accepté ou Chiffrage non accepté mèl avec MDA associée Mise à jour du tableau de suivi DI_MDA Informer l'équipe de TMA du lancement de la réalisation Chef de produit Prendre en compte la MDA dans la réalisation de la DI Equipe de TMA Les MDA sont identifiées en reprenant la référence de la DI concernée : MDA_apl_xxx_nnn.doc. Les MDA sont crées par l'équipe de conception stockées avec les DI dans le répertoire #proj#/ge/suivi_tma/di_mda/mda_apl_xxxnnn.doc. Les MDA sont des documents contractuels, leur suivi est effectuer par l'équipe produit DSI à l'aide du tableau suivi_di_mda.xls stocké dans le répertoire #proj#/ge/suivi_tma/di_mda/suivi_di_mda/suivi_di_mda.xls. CNRS/DSI/conduite-proj/maintenance-evolution/proc-gestion-modification.doc 30 octobre 2002 8/20
Pendant la réalisation, si l'équipe de TMA a besoin d'une précision de la part de la DSI, elle exprime sa demande dans un document spécifique : la PDA (Précision de Document Applicable). Elle est envoyée par mél au chef de produit DSI. Celui-ci, après analyse, renvoie la réponse par mél à l'équipe de TMA dans le même document. Les PDA sont identifiées en reprenant la référence de la DI concernée : PDA_apl_xxx_nnn.doc sont stockées dans le répertoire #proj#/ge/suivi_tma/pda/pda_apl_xxx_nnn.doc. Le suivi est effectué à l'aide du tableau suivi_pda.xls qui se trouve dans le répertoire #proj#/ge/suivi_tma/pda/suivi_pda/suivi_pda.xls. Les PDA leur tableau de suivi sont tenus à jour par le responsable produit DSI. CNRS/DSI/conduite-proj/maintenance-evolution/proc-gestion-modification.doc 30 octobre 2002 9/20
4.2 Processus de gestion des anomalies logiciel (modifications de type correctif) Procédure - Gestion des modifications Equipe produit DSI Equipe de TMA Assistance utilisateur déclaration d'anomalies Commanditaire, utilisateurs... déclaration d'anomalies ou 1 Collecte étude des demandes Chef de produit équipe de conception Mise à jour du tableau récapitulatif des FA 2 Envoi de la Fiche d'anomalie Chef de produit mèl avec FA associée 3 Réception de la FA 4 Vérifier l'accusé de réception de l'équipe de TMA Chef de Produit mèl avec accusé de réception Equipe de TMA ou urgent ou bloquant Prise en compte de l'anomalie dans une autre version 6 Réception de la correction Equipe de cpnception livraison d'un patch 5 Réalisation des corrections Equipe de TMA vers la phase de DEVELOPPEMENT (étape de réception interne) Les déclarations d'anomalies peuvent émaner des utilisateurs principaux (via la cellule assistance aux utilisateurs de la DSI) ou d'utilisateurs occasionnels (lors de la manipulation des applications en formation, passage en laboratoire d'évaluation ou sites pilotes par exemple). CNRS/DSI/conduite-proj/maintenance-evolution/proc-gestion-modification.doc 30 octobre 2002 10/20
Etape 1 : Collecte études des demandes Le chef de produit DSI l'équipe de conception étudient le bien-fondé de la demande la formalisent dans une fiche d'anomalie. Pour distinguer les fiches d'anomalies détectées en production de celles détectées pendant la réception interne DSI, ces fiches possèdent un code d'identification différent. Chaque anomalie est identifiée par un code qui se présente sous la forme suivante : FA_apl_nnn.doc avec : apl = code de l'application concernée nnn = numéro chrono Des pièces complémentaires (copies d'écran, états, courrier ) peuvent être jointes à la demande. Dans ce cas, le numéro de la fiche d'anomalie est indiqué par son rédacteur sur la pièce jointe inversement le nom de la pièce jointe est saisi dans la fiche d'anomalie. Les FA les documents associés sont stockés dans un répertoire propre à l'application : #proj#/ge/suivi_tma/fa/fa_apl_nnn.doc. Etape 2 : Envoie de la fiche d anomalie Les fiches d'anomalies sont envoyées par mél par le chef de produit à l'équipe de TMA. En même temps, il tient à jour le tableau récapitulatif des anomalies (Recap_FA.doc) qui est stocké dans le répertoire #proj#/ge/suivi_tma/fa/suivi_fa/recap_fa.doc. Etape 3 : Réception de la FA L'équipe de TMA accuse réception de la demande en renvoyant par mél un accusé de réception au chef de produit DSI qui indique en particulier dans quelle version l'anomalie sera corrigée : si la correction est urgente, un patch sera livré, sinon l'anomalie est corrigée dans le cadre de la prochaine version contenant des évolutions ou adaptations. Etape 4 : Vérifier l'accusés de réception Le chef de produit prend connaissance de l'accusé de réception de l'équipe de TMA puis m à jour le tableau récapitulatif des anomalies en complétant notamment le champ "statut" du document. Etape 5 : Réalisation de la FA L'équipe de TMA réalise les corrections nécessaires puis livre un patch dans le cas d'une anomalie urgente ou bloquante. Etape 6 : Réception de la correction L'équipe de conception est chargée de s'assurer de la conformité de la livraison (Cf. Phase de DEVELOPPEMENT : Protocole de réception interne). Le tableau récapitulatif des anomalies doit être tenu à jour. 5 - CONTENU TYPE DES DOCUMENTS 5.1 - Portefeuille des demandes de modification Le portefeuille des demandes de modification se présente sous la forme d'un tableau Excel composé de neuf colonnes. CNRS/DSI/conduite-proj/maintenance-evolution/proc-gestion-modification.doc 30 octobre 2002 11/20
Pour toutes les colonnes du document, des commentaires d'explications permtant de vous aider à les compléter ont été introduit. Ces commentaires sont matérialisés par un point rouge en haut à droite de la colonne correspondante. Il suffit de pointer la souris sur ce point rouge pour faire apparaître le commentaire. 5.2 - Demande d intervention Une DI se présente sous la forme d'un document Word découpé en plusieurs parties : - un cartouche d'en-tête, - une partie description de la demande, - une partie réponse, - deux cartouches pour les signatures. Le cartouche d'en-tête Le cartouche d'en-tête est complété par le rédacteur de la DI. Il se présente sous la forme suivante : CNRS/DSI #proj# Application/sous-domaine : DEMANDE D INTERVENTION Référence : DI_apl_xxxnnn Date : #jj/mm/aa# Auteur : #DSI-NNN# ou Page 1/1 - #proj# : remplacer #proj# par le nom du proj concerné par la DI. - Référence : DI_apl_xxxnnn : apl = code de l'application concernée xxx = facultatif, découpage propre à l'application en sous-domaines ou modules, nnn = numéro chrono. - Date : remplacer #jj/mm/aa# par la date de création de la DI. - Auteur : inscrire le nom de la personne ayant rédiger la DI sous la forme DSI-NNN où NNN est le nom du rédacteur (initiales ou users). - Application/sous-domaine : inscrire ici le nom de l'application ou le sous-domaine concerné par la DI. Exemple CNRS/DSI GCF Application/sous-domaine : BUDGET DEMANDE D INTERVENTION Référence : DI_GCF_ENS005 Date : 11/05/00 Auteur : XXX Page 1/20 CNRS/DSI/conduite-proj/maintenance-evolution/proc-gestion-modification.doc 30 octobre 2002 12/20
Description de la demande Cte partie est complétée par le rédacteur de la DI se présente sous la forme suivante : Description demande Date de livraison au plus tard : Documents joints : Libellé court de la demande : Description détaillée de la demande : - Date de livraison au plus tard : préciser ici la date de livraison souhaitée. - Documents joints : si nécessaire, des documents peuvent être joints à la DI pour permtre une meilleure compréhension de la demande. Dans ce cas, écrire dans cte partie la liste des documents joints à la DI ainsi que leurs références. - Libellé court de la demande : écrire ici une phrase courte synthétisant la demande. Cela peut par exemple prendre la forme d'un "titre". - Description détaillée de la demande : le rédacteur doit s'attacher à faire une description précise complète de la demande qu'il souhaite communiquer à l'autre équipe. Exemple Description demande Date de livraison au plus tard : 30/06/00 Documents joints : Ass23628/23804 Libellé court de la demande : Contrôler les saisies "libellés du service" lors de saisies de délégations pour les services centraux. Description détaillée de la demande : Il faut modifier la saisie des délégations de crédit pour les services centraux. A ce jour les utilisateurs doivent saisir le libelle du service à... Réponse à la demande Cte partie perm à l'équipe de TMA de répondre à la demande initiale. Elle est découpée en deux sous-parties. La première est destinée à fournir une réponse claire à la demande la seconde perm de décrire les éléments impactés par les modifications donne un chiffrage pour la tâche à réaliser. - Partie réponse Auteur : #titulaire-nnn# Description de la réponse Analyse de la demande : CNRS/DSI/conduite-proj/maintenance-evolution/proc-gestion-modification.doc 30 octobre 2002 13/20
- Auteur : inscrire le nom de la personne ayant rédiger la réponse à la DI sous la forme #titulaire- NNN# où "titulaire" est le nom de la société titulaire du marché NNN est le nom du rédacteur (initiales ou users). - Analyse de la demande : fournir à l'émteur une réponse claire précise à sa demande. Exemple Auteur : XXX Description de la réponse Analyse de la demande : Création d une table de paramètre contenant la liste des services centraux Modification de la cinématique : Demander de choisir AD ou services centraux avant la saisie du libellé DR. Si le choix est pour les services centraux, affichage de la liste des services centraux. Le choix est obligatoire. - Partie chiffrage Eléments impactés Détail de la formule de calcul des charges : Charge totale (jours) : Coût : Proposition de version : Délai ( jours) : - Détail de la formule de calcul des charges : l'équipe de TMA décrit ici comment ont été calculées les charges. - Charge totale (jours) : récapitulatif des charges totales en jours sur la DI. - Coût : estimation du coût de la DI. - Proposition de version : l'équipe de TMA propose ici une version pour la livraison des modifications. - Délai ( jours) : préciser le délai en jours de livraison des modifications. Exemple Eléments impactés CNRS/DSI/conduite-proj/maintenance-evolution/proc-gestion-modification.doc 30 octobre 2002 14/20
Détail de la formule de calcul des charges : Composant Réf DSL Type Réutilisation PF Remarques Création de la table des services GDI 7 (7) centraux Liste des services centraux SOR 80% 5 (1) Modification de la saisie des ENT 40% 4 (2,4) délégations de crédits Modification de l'écran de saisie des délégations de crédits SOR 80% 5 (1) Nombre de jours = 11,4 PF * 0,72 = 8 jours Charge totale (jour) : 8 jours Coût : Proposition de version : 4.2 Date visa : Société XXX NNN Les cartouches de signatures Après accord entre le titulaire la DSI sur le contenu, les délais le coût des modifications, les deux parties signent leur cartouche respectif. Ces cartouches se présentent sous la forme suivante : Accord Titulaire Date Visa Titulaire Observations : Accord DSI Date Visa DSI Observations : 5.3 - Modification de document applicable Une MDA se présente sous la même forme qu'une DI. On y rrouve les parties : - un cartouche d'en-tête, - une partie description de la demande, - une partie réponse, - deux cartouches pour les signatures. Les MDA sont identifiées en reprenant la référence de la DI concernée : MDA_apl_xxx_nnn. apl = code de l'application concernée, xxx = facultatif, découpage propre à l'application en sous-domaines ou modules, nnn = numéro chrono. CNRS/DSI/conduite-proj/maintenance-evolution/proc-gestion-modification.doc 30 octobre 2002 15/20
5.4 - Suivi des demandes d intervention des modifications de document applicable Les DI est les MDA sont suivies à l'aide du même document intitulé "portefeuille des demandes d'intervention des modifications de document applicable" aussi appelé suivi_di_mda. Ce document est un tableau Excel composé de plusieurs colonnes. Pour toutes les colonnes du document, des commentaires d'explications permtant de vous aider à les compléter ont été introduit. C'est pourquoi chaque colonne n'est pas détaillée une par une dans ce paragraphe. Ces commentaires sont matérialisés par un point rouge en haut à droite de la colonne correspondante. Il suffit de pointer la souris sur ce point rouge pour faire apparaître le commentaire. 5.5 - Précision de document applicable Une PDA est un document Word découpé en trois parties : - un cartouche d'en-tête, - une partie description de la demande, - une partie réponse. Le cartouche d'en-tête Le cartouche d'en-tête est complété par le rédacteur de la PDA. CNRS/DSI #proj# Application/sous-domaine : PRECISION DE DOCUMENT APPLICABLE Référence : PDA_apl_xxxnnn Date : #jj/mm/aa# Auteur : #titulaire-nnn# Page 1/1 - #proj# : remplacer #proj# par le nom du proj concerné par la PDA. - Référence : PDA_apl_xxxnnn : apl = code de l'application concernée, xxx = facultatif, découpage propre à l'application en sous-domaines ou modules nnn = numéro chrono - Date : remplacer #jj/mm/aa# par la date de création de la PDA. - Auteur : inscrire le nom de la personne ayant rédiger la PDA sous la forme #titulaire-nnn# où "titulaire" est le nom de la société titulaire du marché NNN le nom du rédacteur (initiales ou users). - Application/sous-domaine : inscrire ici l'application ou le sous-domaine concerné par la PDA. Exemple CNRS/DSI GCF PRECISION DE DOCUMENT APPLICABLE Référence : PDA_GCF_ENS005 Date : 11/05/00 Auteur : XXX CNRS/DSI/conduite-proj/maintenance-evolution/proc-gestion-modification.doc 30 octobre 2002 16/20
Application/sous-domaine : XXX Page 1/1 Description de la demande Cte partie est complétée par le rédacteur de la PDA se présente sous la forme suivante : Description demande Document impacté localisation exacte dans le document : Libellé court de la précision : Description détaillée de la précision demandée : Date Visa Titulaire - Document impacté localisation exacte dans le document : Le rédacteur de la PDA doit préciser ici le document concerné par la PDA (nom + référence) la localisation exacte de sa demande dans le document (paragraphe, page, ). - Libellé court de la précision : écrire ici une phrase courte synthétisant la demande de précision. - Description détaillée de la précision demandée : le rédacteur doit s'attacher à faire une description précise complète de la demande de précision qu'il souhaite recevoir de la part de l'autre équipe. Exemple Description demande Document impacté localisation exacte dans le document : DIAG_TTAPPLIS_M9-1 Comptes en dur_02 2.4 TABLEAU DES RESULTATS Lignes 132 à 134 Libellé court de la précision : Caractère «poubelle» de certains composants Description détaillée de la précision demandée : Caractère «poubelle» du composant CFFINC4R : Le composant CFFINC4R (Edition du cadre 4 du compte financier / regroupement par classe) est CNRS/DSI/conduite-proj/maintenance-evolution/proc-gestion-modification.doc 30 octobre 2002 17/20
certainement un composant «poubelle» Date Visa Titulaire Partie réponse Cte partie perm à l'équipe DSI de répondre à la demande de précision. Elle se présente sous la forme suivante : Le XXX Auteur : #DSI-NNN# DESCRIPTION DE LA REPONSE Analyse de la précision : Date Visa DSI - Auteur : inscrire le nom de la personne ayant répondu à la PDA sous la forme #DSI-NNN# où NNN est le nom du rédacteur (initiales ou users). - Analyse de la précision : Fournir à l'émteur une réponse claire précise à sa demande de précision. Exemple Auteur : XXX DESCRIPTION DE LA REPONSE Analyse de la précision : Caractère «poubelle» du composant CFFINC4R : Le composant CFFINC4R (Edition du cadre 4 du compte financier / regroupement par classe) est certainement un composant poubelle, car : Il n est appelé par aucun autre composant alors qu il utilise deux paramètres passés en entrée, Lorsqu on lui passe manuellement ces deux paramètres, le message d erreur «select criteria SECTEUR is not a field» apparaît car l attribut SECTEUR n existe pas sur le fichier ACPPOSTE Date Visa DSI Le XXX CNRS/DSI/conduite-proj/maintenance-evolution/proc-gestion-modification.doc 30 octobre 2002 18/20
5.6 - Suivi des précisions de documents applicables Les PDA sont suivies à l'aide du document intitulé "Suivi des précisions de documents applicables" aussi appelé suivi_pda. Ce document est un tableau Excel composé de dix colonnes. Pour toutes les colonnes du document, des commentaires d'explications permtant de vous aider à les compléter ont été introduit. C'est pourquoi chaque colonne n'est pas détaillée une par une dans ce paragraphe. Ces commentaires sont matérialisés par un point rouge en haut à droite de la colonne correspondante. Il suffit de pointer la souris sur ce point rouge pour faire apparaître le commentaire. 5.7 - Fiche d anomalies Une fiche d'anomalies se présente sous la forme d'un tableau Word comportant différents champs à renseigner. Ces champs sont : N fiche d'anomalies : inscrire ici la référence de la fiche sous la forme : FA_apl_nnn où : - apl = code de l'application concernée - nnn = numéro chrono Exemple FA_LAB_005 = Cinquième fiche d'anomalie concernant l'application LABINTEL. FA_RET_010 = Dixième fiche d'anomalie concernant l'application RETIS Libellé : écrire ici une phrase courte synthétisant l'anomalie. Auteur : inscrire le nom du rédacteur de la FA sous la forme DSI-NNN où NNN est le nom du rédacteur (initiales ou users). Date : remplacer #jj/mm/aa# par la date de création de la FA. Code anomalie : ne rien inscrire dans cte colonne. Elle est destinée aux anomalies détectées durant la phase de réception interne. En eff durant cte phase, un tableau des codes anomalies est défini dans le document "protocole de réception interne" qui perm à l'équipe proj de suivre les différents types d'anomalies. Description anomalie : décrire de manière précise complète l'anomalie détectée. Contexte : préciser le contexte dans lequel l'anomalie a été détectée. Cte colonne perm notamment de préciser que l'anomalie a été détectée en production (pour les distinguer de celles détectées pendant la réception interne). CNRS/DSI/conduite-proj/maintenance-evolution/proc-gestion-modification.doc 30 octobre 2002 19/20
Gravité : identifier ici la gravité de l'anomalie. On peut trouver deux types de gravité : - Bloquant = sans solution de contournement existante, - Non-bloquant = le problème peut être contourné. 5.8 - Tableau récapitulatif des anomalies Ce tableau perm de recenser l'ensemble des anomalies de suivre l'évolution de leur "statut". Il se présente sous la forme d'un tableau Word composé de sept colonnes : Colonne 1 : N Fiche d'anomalies Reprendre la référence de la fiche d'anomalies (Fa_apl_nnn). Colonne 2 : Code anomalie Ne rien inscrire dans cte colonne. Colonne 3 : Gravité Noter ici la gravité de la FA (Bloquant ou non-bloquant). Colonne 4 : Libellé de la fiche d'anomalies Reprendre ici le libellé de la fiche d'anomalies correspondantes. Colonne 5 : Date émission Remplacer #jj/mm/aa# par la date d'émission de la FA. Colonne 6 : Code statut Afin de suivre la correction de l'anomalie, un code statut a été mis en place : O : anomalie à corriger (fiche anomalie ouverte), L : Correction de l'anomalie Livrée, en cours de réception, F : anomalie corrigée (fiche anomalie Fermée), V : anomalie prise en compte dans une prochaine Version. Compléter la colonne par la ltre correspondant au statut de la FA. Colonne 7 : Date rour Remplacer #jj/mm/aa# par la date de rour des corrections de la FA. CNRS/DSI/conduite-proj/maintenance-evolution/proc-gestion-modification.doc 30 octobre 2002 20/20