Anda di halaman 1dari 20

Centre national de la recherche scientifique Direction des systmes d'information

REFERENTIEL QUALITE

Procdure Qualit

Gestion des modifications dun projet systme d'information

Rfrence : CNRS/DSI/conduite-projet/maintenance-evolution/proc-gestion-modification

Date de dernire mise jour : 30 octobre 2002 Version : 01 Etat : Termin

Auteurs : Y. Soler

Diffusion : DSI

Objet : Cette procdure a pour but de dcrire le processus de gestion des modifications au sein d'un projet de la DSI.

Procdure - Gestion des modifications

Table des mises jour du document

Version du document

Date

Objet de la mise jour

00

2 Mai 2001

Cration du document

01

30 octobre 2002

Suppression de rfrences trop prcises aux projets

CNRS/DSI/conduite-projet/maintenance-evolution/proc-gestion-modification.doc

30 octobre 2002

2/20

Procdure - Gestion des modifications

Sommaire

1 - OBJET ET DOMAINE DAPPLICATION..............................................................................................................4 2 - DOCUMENTS DE RFRENCE.............................................................................................................................4 3 - ABRVIATIONS ET TERMINOLOGIE ................................................................................................................4 4 - PRINCIPES DLABORATION ..............................................................................................................................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 DINTERVENTION ............................................................................................................................12 5.3 - MODIFICATION DE DOCUMENT APPLICABLE .................................................................................................15 5.4 - SUIVI DES DEMANDES DINTERVENTION ET DES MODIFICATIONS DE DOCUMENT APPLICABLE .............16 5.5 - PRCISION DE DOCUMENT APPLICABLE .........................................................................................................16 5.6 - SUIVI DES PRCISIONS DE DOCUMENTS APPLICABLES.................................................................................19 5.7 - FICHE DANOMALIES .........................................................................................................................................19 5.8 - TABLEAU RCAPITULATIF DES ANOMALIES ..................................................................................................20

CNRS/DSI/conduite-projet/maintenance-evolution/proc-gestion-modification.doc

30 octobre 2002

3/20

Procdure - Gestion des modifications

1 - OBJET ET DOMAINE DAPPLICATION Les demandes de modifications intervenant aprs la constitution du cahier des charges vers l'quipe de TMA font l'objet de procdures de gestion spcifiques. Les modifications peuvent tre de natures diffrentes : - adaptation ou volution du primtre fonctionnel, technologique ou organisationnel, - correction suite une non-conformit (anomalie dans le logiciel ou dgradation de la base de production). Sera considre comme urgente,(degr immdiat) toute demande de modification prsentant un caractre bloquant (sans solution de contournement existante) pour le systme d'information ou toute demande prsentant un caractre impratif en terme de dlai. Ces activits sont mises en uvre lors du dveloppement initial d'un systme d'information ou chaque itration de dveloppement 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 : Prcision de Document Applicable FA : Fiche d'Anomalie cf. Glossaire Conduite de projet Systmes dinformation 4 - PRINCIPES DELABORATION 4.1 Processus de gestion des adaptations et des volutions Le chef de produit DSI est charg des relations avec la matrise d'ouvrage. Il collecte et valide les nouvelles demandes et envoie les demandes d'intervention (DI) l'quipe de TMA. L'quipe de conception quant elle pour mission de collecter, de dcrire, de suivre, d'analyser les demandes de modification (DM) avant de les formaliser en demandes d'intervention (DI). Toutes les demandes collectes sont enregistres dans un " portefeuille des modifications " (SUIVI_DM).

CNRS/DSI/conduite-projet/maintenance-evolution/proc-gestion-modification.doc

30 octobre 2002

4/20

Procdure - Gestion des modifications


Instances dcisionnelles Comit utilisateurs, utilisateurs... Equipe produit DSI Equipe de TMA

Correspondant fonctionnel

depuis la phase dEXPLOITATION/ UTILISATION

Equipe produit DSI

demande d'volution expression de besoins 2 Donner son avis sur l'opportunit et les priorits
Comit utilisateurs

anomalie du logiciel ou 1 demande de modification

Collecter et analyser les DM


Chef de produit et quipe de conception

Avis, priorits 3 Valider les DM


comit de suivi et validation

et

Mise jour du portefeuille des DM

DM non valide

ou

DM valide

et

4 Rdiger la Demande d'Intervention (DI)


Equipe de conception

DM non prise en compte

et Enregistrer la DI sur le serveur 5 Envoi des DI


Chef de produit

Mise en attente pour un version future

Mise jour du tableau de suivi DM et DI_MDA

ml avec DI associe 6 Chiffrer les DI et mise jour de la version lectronique


Equipe de TMA

7 Vrifier le chiffrage
Chef de produit et quipe de conception

Chiffrage accept

ou Chiffrage non accept

ml avec DI complte et ml avec DI associe

et Mise jour du tableau de suivi DI_MDA

8 Correspondant fonctionnel Dfinir le cahier des charges


Chef de produit

9 Informer l'quipe de TMA du lancement de la ralisation


Chef de produit

10 Raliser les DI
Equipe de TMA

vers la phase de DEVELOPPEMENT (tape de rception interne)

CNRS/DSI/conduite-projet/maintenance-evolution/proc-gestion-modification.doc

30 octobre 2002

5/20

Procdure - Gestion des modifications

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 et tudier les demandes de modifications L'quipe de conception centralise toute les DM. Chaque demande est rfrence de la manire suivante : DM#code domaine#aa#nnn# ou aa correspond aux 2 chiffres de l'anne et nnn est un numro chrono remis zro chaque anne. Ensuite, chaque DM est analyse par l'quipe de conception afin d'identifier prcisment la nature de la demande, l'urgence et de dcrire clairement l'nonc. Des pices complmentaires (rapport, courrier, fax) peuvent tre jointes la demande. Dans ce cas, la rfrence de la demande est indique sur la pice jointe. Toutes les demandes de modifications sont centralises dans un "portefeuille de demandes de modification" propre chaque application. Ce document est tenu jour par l'quipe produit DSI et se trouve dans le rpertoire #projet#/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 et les priorits Si besoin est, les volutions majeures peuvent tre prsentes au comit des utilisateurs qui donne alors son avis sur l'opportunit d'effectuer ces modifications et sur les priorits de ralisation. Etape 3 : Valider les demandes de modification La liste complte des demandes de modification est propose au comit de suivi et de validation qui dcide pour chaque demande : - de la rajouter au cahier des charges de la version suivante de l'application, - de la mettre en attente pour une version future de l'application, - de ne pas prendre en compte la demande. Etape 5 : Mettre jour le portefeuille des DM Aprs rception des dcisions du comit de suivi et 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 : Rdiger la demande d'intervention (DI) Les demandes de modification valides sont alors formalises 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 spcification de l'adaptation ou de l'volution raliser ou qui fait rfrence un document d'tude dtaille qui contient la spcification de l'volution raliser. Chaque document DI est nomm DI_apl_xxxnnn.doc, avec : apl = code de l'application concerne xxx = facultatif, dcoupage propre l'application en sous-domaines ou modules nnn = numro chrono

En compltant la DI, l'quipe de conception cre ou met jour un document d'tude dtaille qui sera joint lors de l'envoi de la DI l'quipe de TMA. Les DI et les documents de spcification associs sont stocks dans un rpertoire propre l'application : #projet#/GE/suivi_TMA/DI_MDA/ DI_apl_xxxnnn.doc.
CNRS/DSI/conduite-projet/maintenance-evolution/proc-gestion-modification.doc 30 octobre 2002 6/20

Procdure - Gestion des modifications

Le portefeuille des demandes de modification (suivi_DM.xls) est complt par la rfrence de la DI qui a t gnre. L'quipe DSI doit galement actualiser le tableau de suivi des DI (suivi_DI_MDA.xls) qui est stock dans le rpertoire #projet#/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 ml l'quipe de TMA les DI et les documents associs. Il tient galement jour le tableau de suivi des DI (suivi_DI_MDA.xls). Etape 6 : Chiffrer la DI et mise jour de la version lectronique L'quipe de TMA renseigne la partie rponse des DI et les renvoie par ml au chef de produit DSI. Etape 7 : Vrifier le chiffrage Le chef de produit DSI et l'quipe de conception analysent les rponses de l'quipe de TMA. Des runions de prsentation/mise au point des spcifications peuvent tre organises avec l'quipe de TMA afin de finaliser les DI et d'viter des modifications futures de DI. Aprs vrification, le chiffrage de la DI peut tre accept ou refus. - Chiffrage refus : Dans ce cas, le chef de produit DSI renvoie par un ml d'explication et la DI associe l'quipe de TMA pour un nouveau chiffrage. Il tiens galement jour le tableau de suivi des DI (suivi_DI_MDA.xls). Chiffrage accept : Aprs accord dfinitif avec l'quipe de TMA sur le contenu et 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 signes par le chef de produit DSI et par le titulaire). Le tableau de suivi des DI (suivi_DI_MDA.xls) est tenu jour.

Etape 8 : Dfinir le cahier des charges Le cahier des charges est constitu par la liste des DI concernant la version. Cette liste est tablie en tenant comptes des exigences du comit utilisateur, du comit de suivi et validation et des contraintes en charge et dlai de ralisation 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 et constitue un document applicable. Le cahier des charges de chaque version peut tre dcoup en plusieurs lots, concernant des sousensembles fonctionnels homognes de l'application ou des demandes d'intervention de mme nature. Ce dcoupage en lots permet une prvision des charges et du planning du ct de l'quipe DSI aussi bien que du ct de l'quipe TMA, sans attendre un cahier des charges complet pour la version. Etape 9 : Informer l'quipe de TMA du lancement de la ralisation Le chef de produit adresse l'quipe de TMA le cahier des charges pour ralisation. Un bon de commande ou un ordre de service confirmant le contenu de la version et prcisant les charges par DI et le dlai de ralisation est ensuite adress par la DSI l'quipe de TMA. Etape 10 : Raliser les DI L'quipe de TMA est ensuite charge de raliser les DI puis livre la version. L'quipe de conception est charge de s'assurer de la conformit de la livraison avec le cahier des charges. (Cf. Phase de DEVELOPPEMENT : Protocole de rception interne).

CNRS/DSI/conduite-projet/maintenance-evolution/proc-gestion-modification.doc

30 octobre 2002

7/20

Procdure - Gestion des modifications

Aprs accord sur le cahier des charges : - les ajouts de nouvelles DI sont viter : elles peuvent remettre en cause les dlais de ralisation de la version, - de mme, les modifications des DI du cahier des charges sont viter. Si elles sont ncessaires, elles font l'objet d'un document spcifique la MDA (Modification de Document Applicable). Les MDA sont gres de la mme faon que les DI.

Equipe produit DSI

Equipe de TMA

Modification dune DI

Rdiger la MDA
Equipe de conception

et Enregistrer la MDA sur le serveur Mise jour du tableau de suivi DI_MDA

Envoi MDA
Chef de produit

ml avec MDA associe

Chiffrer la MDA et mise jour de la version lectronique


Equipe de TMA

Vrifier le chiffrage
Chef de produit et quipe de conception

ml avec MDA complte

Chiffrage accept

ou

Chiffrage non accept ml avec MDA associe

et Mise jour du tableau de suivi DI_MDA

et

Informer l'quipe de TMA du lancement de la ralisation


Chef de produit

Prendre en compte la MDA dans la ralisation de la DI


Equipe de TMA

Les MDA sont identifies en reprenant la rfrence de la DI concerne : MDA_apl_xxx_nnn.doc. Les MDA sont cres par l'quipe de conception et stockes avec les DI dans le rpertoire #projet#/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 rpertoire #projet#/GE/suivi_TMA/DI_MDA/suivi_DI_MDA/suivi_DI_MDA.xls.
CNRS/DSI/conduite-projet/maintenance-evolution/proc-gestion-modification.doc 30 octobre 2002 8/20

Procdure - Gestion des modifications

Pendant la ralisation, si l'quipe de TMA a besoin d'une prcision de la part de la DSI, elle exprime sa demande dans un document spcifique : la PDA (Prcision de Document Applicable). Elle est envoye par ml au chef de produit DSI. Celui-ci, aprs analyse, renvoie la rponse par ml l'quipe de TMA dans le mme document. Les PDA sont identifies en reprenant la rfrence de la DI concerne : PDA_apl_xxx_nnn.doc et sont stockes dans le rpertoire #projet#/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 rpertoire #projet#/GE/suivi_TMA/PDA/suivi_PDA/suivi_PDA.xls. Les PDA et leur tableau de suivi sont tenus jour par le responsable produit DSI.

CNRS/DSI/conduite-projet/maintenance-evolution/proc-gestion-modification.doc

30 octobre 2002

9/20

Procdure - Gestion des modifications

4.2 Processus de gestion des anomalies logiciel (modifications de type correctif)


Equipe produit DSI Equipe de TMA

Assistance utilisateur

dclaration d'anomalies

Commanditaire, utilisateurs...

dclaration d'anomalies

ou 1

Collecte et tude des demandes


Chef de produit et quipe de conception

2 Envoi de la Fiche d'Anomalie


Chef de produit

et Mise jour du tableau rcapitulatif des FA

ml avec FA associe 3 Rception de la FA


Equipe de TMA

ml avec accus de rception 4 Vrifier l'accus de rception de l'quipe de TMA


Chef de Produit

et

ou

Prise en compte de l'anomalie dans une autre version

et

urgent ou bloquant 5 livraison d'un patch Ralisation des corrections


Equipe de TMA

6 Rception de la correction
Equipe de cpnception

et

vers la phase de DEVELOPPEMENT (tape de rception interne)

Les dclarations 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-projet/maintenance-evolution/proc-gestion-modification.doc

30 octobre 2002

10/20

Procdure - Gestion des modifications

Etape 1 : Collecte et tudes des demandes Le chef de produit DSI et l'quipe de conception tudient le bien-fond de la demande et la formalisent dans une fiche d'anomalie. Pour distinguer les fiches d'anomalies dtectes en production de celles dtectes pendant la rception interne DSI, ces fiches possdent un code d'identification diffrent. Chaque anomalie est identifie par un code qui se prsente sous la forme suivante : FA_apl_nnn.doc avec : apl = code de l'application concerne nnn = numro chrono Des pices complmentaires (copies d'cran, tats, courrier) peuvent tre jointes la demande. Dans ce cas, le numro de la fiche d'anomalie est indiqu par son rdacteur sur la pice jointe et inversement le nom de la pice jointe est saisi dans la fiche d'anomalie. Les FA et les documents associs sont stocks dans un rpertoire propre l'application : #projet#/GE/suivi_TMA/FA/FA_apl_nnn.doc.

Etape 2 : Envoie de la fiche danomalie Les fiches d'anomalies sont envoyes par ml par le chef de produit l'quipe de TMA. En mme temps, il tient jour le tableau rcapitulatif des anomalies (Recap_FA.doc) qui est stock dans le rpertoire #projet#/GE/suivi_TMA/FA/suivi_FA/Recap_FA.doc. Etape 3 : Rception de la FA L'quipe de TMA accuse rception de la demande en renvoyant par ml un accus de rception au chef de produit DSI qui indique en particulier dans quelle version l'anomalie sera corrige : si la correction est urgente, un patch sera livr, sinon l'anomalie est corrige dans le cadre de la prochaine version contenant des volutions ou adaptations. Etape 4 : Vrifier l'accuss de rception Le chef de produit prend connaissance de l'accus de rception de l'quipe de TMA puis met jour le tableau rcapitulatif des anomalies en compltant notamment le champ "statut" du document. Etape 5 : Ralisation de la FA L'quipe de TMA ralise les corrections ncessaires puis livre un patch dans le cas d'une anomalie urgente ou bloquante. Etape 6 : Rception de la correction L'quipe de conception est charge de s'assurer de la conformit de la livraison (Cf. Phase de DEVELOPPEMENT : Protocole de rception interne). Le tableau rcapitulatif 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 prsente sous la forme d'un tableau Excel compos de neuf colonnes.

CNRS/DSI/conduite-projet/maintenance-evolution/proc-gestion-modification.doc

30 octobre 2002

11/20

Procdure - Gestion des modifications

Pour toutes les colonnes du document, des commentaires d'explications permettant de vous aider les complter ont t introduit. Ces commentaires sont matrialiss par un point rouge en haut droite de la colonne correspondante. Il suffit de pointer la souris sur ce point rouge pour faire apparatre le commentaire. 5.2 - Demande dintervention Une DI se prsente sous la forme d'un document Word dcoup en plusieurs parties : - un cartouche d'en-tte, - une partie description de la demande, - une partie rponse, - deux cartouches pour les signatures. Le cartouche d'en-tte Le cartouche d'en-tte est complt par le rdacteur de la DI. Il se prsente sous la forme suivante :
CNRS/DSI #projet# Application/sous-domaine : Page 1/1

DEMANDE DINTERVENTION Rfrence : DI_apl_xxxnnn

Date : #jj/mm/aa# Auteur : #DSI-NNN# ou

#projet# : remplacer #projet# par le nom du projet concern par la DI. Rfrence : DI_apl_xxxnnn : apl = code de l'application concerne xxx = facultatif, dcoupage propre l'application en sous-domaines ou modules, nnn = numro chrono. Date : remplacer #jj/mm/aa# par la date de cration de la DI. Auteur : inscrire le nom de la personne ayant rdiger la DI sous la forme DSI-NNN o NNN est le nom du rdacteur (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 DINTERVENTION Rfrence : DI_GCF_ENS005

Date : 11/05/00 Auteur : XXX Page 1/20

CNRS/DSI/conduite-projet/maintenance-evolution/proc-gestion-modification.doc

30 octobre 2002

12/20

Procdure - Gestion des modifications

Description de la demande Cette partie est complte par le rdacteur de la DI et se prsente sous la forme suivante : Description demande
Date de livraison au plus tard : Documents joints :

Libell court de la demande : Description dtaille de la demande :

Date de livraison au plus tard : prciser ici la date de livraison souhaite. Documents joints : si ncessaire, des documents peuvent tre joints la DI pour permettre une meilleure comprhension de la demande. Dans ce cas, crire dans cette partie la liste des documents joints la DI ainsi que leurs rfrences. Libell court de la demande : crire ici une phrase courte synthtisant la demande. Cela peut par exemple prendre la forme d'un "titre". Description dtaille de la demande : le rdacteur doit s'attacher faire une description prcise et complte 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 :

Contrler les saisies "libells du service" lors de saisies de dlgations pour les services centraux.
Description dtaille de la demande :

Il faut modifier la saisie des dlgations de crdit pour les services centraux. A ce jour les utilisateurs doivent saisir le libelle du service ...

Rponse la demande Cette partie permet l'quipe de TMA de rpondre la demande initiale. Elle est dcoupe en deux sous-parties. La premire est destine fournir une rponse claire la demande et la seconde permet de dcrire les lments impacts par les modifications et donne un chiffrage pour la tche raliser. Partie rponse Description de la rponse
Auteur : #titulaire-NNN# Analyse de la demande :

CNRS/DSI/conduite-projet/maintenance-evolution/proc-gestion-modification.doc

30 octobre 2002

13/20

Procdure - Gestion des modifications

Auteur : inscrire le nom de la personne ayant rdiger la rponse la DI sous la forme #titulaireNNN# o "titulaire" est le nom de la socit titulaire du march et NNN est le nom du rdacteur (initiales ou users). Analyse de la demande : fournir l'metteur une rponse claire et prcise sa demande.

Exemple Description de la rponse


Auteur :

XXX

Analyse de la demande :

Cration dune table de paramtre contenant la liste des services centraux Modification de la cinmatique : 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 Elments impacts

Dtail de la formule de calcul des charges :

Charge totale (jours) : Proposition de version :

Cot : Dlai ( jours) :

Dtail de la formule de calcul des charges : l'quipe de TMA dcrit ici comment ont t calcules les charges. Charge totale (jours) : rcapitulatif des charges totales en jours sur la DI. Cot : estimation du cot de la DI. Proposition de version : l'quipe de TMA propose ici une version pour la livraison des modifications. Dlai ( jours) : prciser le dlai en jours de livraison des modifications.

Exemple Elments impacts


CNRS/DSI/conduite-projet/maintenance-evolution/proc-gestion-modification.doc 30 octobre 2002 14/20

Procdure - Gestion des modifications

Dtail de la formule de calcul des charges : Composant Cration de la table des services centraux Liste des services centraux Modification de la saisie des dlgations de crdits Modification de l'cran de saisie des dlgations de crdits Rf DSL Type GDI SOR ENT SOR Rutilisation PF 7 (7) 80% 40% 80% 5 4 5 (1) (2,4) (1) Remarques

Nombre de jours = 11,4 PF * 0,72 = 8 jours

Charge totale (jour) : 8 jours Proposition de version : 4.2

Cot : Date et visa : Socit XXX NNN

Les cartouches de signatures Aprs accord entre le titulaire et la DSI sur le contenu, les dlais et le cot des modifications, les deux parties signent leur cartouche respectif. Ces cartouches se prsentent sous la forme suivante : Accord Titulaire Observations : Date et Visa Titulaire

Accord DSI Observations :

Date et Visa DSI

5.3 - Modification de document applicable Une MDA se prsente sous la mme forme qu'une DI. On y retrouve les parties : - un cartouche d'en-tte, - une partie description de la demande, - une partie rponse, - deux cartouches pour les signatures. Les MDA sont identifies en reprenant la rfrence de la DI concerne : MDA_apl_xxx_nnn. apl = code de l'application concerne, xxx = facultatif, dcoupage propre l'application en sous-domaines ou modules, nnn = numro chrono.

CNRS/DSI/conduite-projet/maintenance-evolution/proc-gestion-modification.doc

30 octobre 2002

15/20

Procdure - Gestion des modifications

5.4 - Suivi des demandes dintervention et des modifications de document applicable Les DI est les MDA sont suivies l'aide du mme document intitul "portefeuille des demandes d'intervention et 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 permettant de vous aider les complter ont t introduit. C'est pourquoi chaque colonne n'est pas dtaille une par une dans ce paragraphe. Ces commentaires sont matrialiss par un point rouge en haut droite de la colonne correspondante. Il suffit de pointer la souris sur ce point rouge pour faire apparatre le commentaire.

5.5 - Prcision de document applicable Une PDA est un document Word dcoup en trois parties : - un cartouche d'en-tte, - une partie description de la demande, - une partie rponse. Le cartouche d'en-tte Le cartouche d'en-tte est complt par le rdacteur de la PDA.
CNRS/DSI

#projet# Application/sous-domaine :

PRECISION DE DOCUMENT APPLICABLE Rfrence : PDA_apl_xxxnnn

Date : #jj/mm/aa# Auteur : #titulaire-NNN# Page 1/1

#projet# : remplacer #projet# par le nom du projet concern par la PDA. Rfrence : PDA_apl_xxxnnn : apl = code de l'application concerne, xxx = facultatif, dcoupage propre l'application en sous-domaines ou modules nnn = numro chrono Date : remplacer #jj/mm/aa# par la date de cration de la PDA. Auteur : inscrire le nom de la personne ayant rdiger la PDA sous la forme #titulaire-NNN# o "titulaire" est le nom de la socit titulaire du march et NNN le nom du rdacteur (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 Rfrence : PDA_GCF_ENS005

Date : 11/05/00 Auteur : XXX

CNRS/DSI/conduite-projet/maintenance-evolution/proc-gestion-modification.doc

30 octobre 2002

16/20

Procdure - Gestion des modifications

Application/sous-domaine : XXX Page 1/1

Description de la demande Cette partie est complte par le rdacteur de la PDA et se prsente sous la forme suivante : Description demande
Document impact et localisation exacte dans le document :

Libell court de la prcision : Description dtaille de la prcision demande :

Date et Visa Titulaire

- Document impact et localisation exacte dans le document : Le rdacteur de la PDA doit prciser ici le document concern par la PDA (nom + rfrence) et la localisation exacte de sa demande dans le document (paragraphe, page,).
-

Libell court de la prcision : crire ici une phrase courte synthtisant la demande de prcision. Description dtaille de la prcision demande : le rdacteur doit s'attacher faire une description prcise et complte de la demande de prcision qu'il souhaite recevoir de la part de l'autre quipe.

Exemple Description demande


Document impact et 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 prcision : Caractre poubelle de certains composants Description dtaille de la prcision demande : Caractre poubelle du composant CFFINC4R : Le composant CFFINC4R (Edition du cadre 4 du compte financier / regroupement par classe) est
CNRS/DSI/conduite-projet/maintenance-evolution/proc-gestion-modification.doc 30 octobre 2002 17/20

Procdure - Gestion des modifications

certainement un composant poubelle Date et Visa Titulaire Le XXX

Partie rponse Cette partie permet l'quipe DSI de rpondre la demande de prcision. Elle se prsente sous la forme suivante :
DESCRIPTION DE LA REPONSE Auteur : #DSI-NNN# Analyse de la prcision :

Date et Visa DSI

Auteur : inscrire le nom de la personne ayant rpondu la PDA sous la forme #DSI-NNN# o NNN est le nom du rdacteur (initiales ou users). Analyse de la prcision : Fournir l'metteur une rponse claire et prcise sa demande de prcision.

Exemple
DESCRIPTION DE LA REPONSE Auteur : XXX Analyse de la prcision : Caractre poubelle du composant CFFINC4R : Le composant CFFINC4R (Edition du cadre 4 du compte financier / regroupement par classe) est certainement un composant poubelle, car : Il nest appel par aucun autre composant alors quil utilise deux paramtres passs en entre, Lorsquon lui passe manuellement ces deux paramtres, le message derreur select criteria SECTEUR is not a field apparat car lattribut SECTEUR nexiste pas sur le fichier ACPPOSTE Date et Visa DSI Le XXX

CNRS/DSI/conduite-projet/maintenance-evolution/proc-gestion-modification.doc

30 octobre 2002

18/20

Procdure - Gestion des modifications

5.6 - Suivi des prcisions de documents applicables Les PDA sont suivies l'aide du document intitul "Suivi des prcisions 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 permettant de vous aider les complter ont t introduit. C'est pourquoi chaque colonne n'est pas dtaille une par une dans ce paragraphe. Ces commentaires sont matrialiss par un point rouge en haut droite de la colonne correspondante. Il suffit de pointer la souris sur ce point rouge pour faire apparatre le commentaire.

5.7 - Fiche danomalies Une fiche d'anomalies se prsente sous la forme d'un tableau Word comportant diffrents champs renseigner. Ces champs sont : N fiche d'anomalies : inscrire ici la rfrence de la fiche sous la forme : FA_apl_nnn o : - apl = code de l'application concerne - nnn = numro chrono Exemple FA_LAB_005 = Cinquime fiche d'anomalie concernant l'application LABINTEL. FA_RET_010 = Dixime fiche d'anomalie concernant l'application RETIS Libell : crire ici une phrase courte synthtisant l'anomalie. Auteur : inscrire le nom du rdacteur de la FA sous la forme DSI-NNN o NNN est le nom du rdacteur (initiales ou users). Date : remplacer #jj/mm/aa# par la date de cration de la FA. Code anomalie : ne rien inscrire dans cette colonne. Elle est destine aux anomalies dtectes durant la phase de rception interne. En effet durant cette phase, un tableau des codes anomalies est dfini dans le document "protocole de rception interne" qui permet l'quipe projet de suivre les diffrents types d'anomalies. Description anomalie : dcrire de manire prcise et complte l'anomalie dtecte. Contexte : prciser le contexte dans lequel l'anomalie a t dtecte. Cette colonne permet notamment de prciser que l'anomalie a t dtecte en production (pour les distinguer de celles dtectes pendant la rception interne).

CNRS/DSI/conduite-projet/maintenance-evolution/proc-gestion-modification.doc

30 octobre 2002

19/20

Procdure - Gestion des modifications

Gravit : identifier ici la gravit de l'anomalie. On peut trouver deux types de gravit : - Bloquant = sans solution de contournement existante, - Non-bloquant = le problme peut tre contourn.

5.8 - Tableau rcapitulatif des anomalies Ce tableau permet de recenser l'ensemble des anomalies et de suivre l'volution de leur "statut". Il se prsente sous la forme d'un tableau Word compos de sept colonnes : Colonne 1 : N Fiche d'anomalies Reprendre la rfrence de la fiche d'anomalies (Fa_apl_nnn). Colonne 2 : Code anomalie Ne rien inscrire dans cette 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 Livre, en cours de rception, F : anomalie corrige (fiche anomalie Ferme), V : anomalie prise en compte dans une prochaine Version. Complter la colonne par la lettre correspondant au statut de la FA. Colonne 7 : Date retour Remplacer #jj/mm/aa# par la date de retour des corrections de la FA.

CNRS/DSI/conduite-projet/maintenance-evolution/proc-gestion-modification.doc

30 octobre 2002

20/20