Proc Gestion Modification

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
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
30 octobre 2002
3/20
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).
30 octobre 2002
4/20

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
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)
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 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
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).
30 octobre 2002
7/20
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
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.
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.
30 octobre 2002
9/20
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

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).
30 octobre 2002
10/20
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.
30 octobre 2002
11/20
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
30 octobre 2002
12/20
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 :
30 octobre 2002
13/20
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

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.
30 octobre 2002
15/20
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
30 octobre 2002
16/20
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
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
30 octobre 2002
18/20
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).
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 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.
30 octobre 2002
20/20

Proc Gestion Modification

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Proc Gestion Modification

Enviado por

Direitos autorais:

Formatos disponíveis

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

Gestion des modifications dun projet systme d'information

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

Procdure - Gestion des modifications

Table des mises jour du document

Objet de la mise jour

Suppression de rfrences trop prcises aux projets

Procdure - Gestion des modifications

Procdure - Gestion des modifications

Procdure - Gestion des modifications

depuis la phase dEXPLOITATION/ UTILISATION

Equipe produit DSI

anomalie du logiciel ou 1 demande de modification

Collecter et analyser les DM

Avis, priorits 3 Valider les DM

Mise jour du portefeuille des DM

4 Rdiger la Demande d'Intervention (DI)

DM non prise en compte

et Enregistrer la DI sur le serveur 5 Envoi des DI

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

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

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

vers la phase de DEVELOPPEMENT (tape de rception interne)

Procdure - Gestion des modifications

Procdure - Gestion des modifications

Procdure - Gestion des modifications

Equipe produit DSI

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

ml avec MDA associe

Chiffrer la MDA et mise jour de la version lectronique

ml avec MDA complte

Chiffrage non accept ml avec MDA associe

et Mise jour du tableau de suivi DI_MDA

Informer l'quipe de TMA du lancement de la ralisation

Prendre en compte la MDA dans la ralisation de la DI

Procdure - Gestion des modifications

Procdure - Gestion des modifications

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

Collecte et tude des demandes

2 Envoi de la Fiche d'Anomalie

et Mise jour du tableau rcapitulatif des FA

ml avec FA associe 3 Rception de la FA

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

Prise en compte de l'anomalie dans une autre version

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

vers la phase de DEVELOPPEMENT (tape de rception interne)

Procdure - Gestion des modifications

Procdure - Gestion des modifications

DEMANDE DINTERVENTION Rfrence : DI_apl_xxxnnn

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

GCF Application/sous-domaine : BUDGET

DEMANDE DINTERVENTION Rfrence : DI_GCF_ENS005

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

Procdure - Gestion des modifications

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

Exemple Description demande

Procdure - Gestion des modifications

Exemple Description de la rponse

Partie chiffrage Elments impacts