Le document présente la méthodologie de gestion de projet, détaillant les phases clés telles que l'analyse, la conception, le développement, les tests et le déploiement. Il souligne l'importance d'une gouvernance claire et d'une répartition des rôles entre les participants au projet pour garantir le succès. Enfin, il décrit les livrables attendus et les besoins en formation pour les utilisateurs finaux lors de la mise en production.

1. Méthodologie Projet
Benjamin ACHAB
Mars 2017

2. •Les phases du projet
•Structure d’un projet
•Gouvernance de projets
•Les phases du projet
– Le release management
– La conception
– Le développement
– Les tests
– Le roll out

3. Vue d’ensemble
Réunion de Lancement
Installation
Formation découverte
Formation administrateur
Analyse générale
- fonctionnelle
- reprise de
données
- Interface
Développement
Formation key users
Transfert au Support
et Service client
Etude d’adéquation
Initialisation Analyse Conception ExploitationMise en production
Assistance au démarrage
Reprise de données
définitives
Analyse des écarts
ParamétrageReprise de données test
Tests et validation du pilote
Formation end users
Vérification GO / NO GO
Réalisation
Tests unitaires
Codification et Paramétrage de base
Gestion de projetPQP Validation S1 Validation S2
Recette définitive

4. • Un projet a pour objectif de mener à bien le développement d’une
nouvelle application ou l’adaptation d’une application existante
• Un projet est caractérisé par :
– Un périmètre – quels sont les besoins clients auxquels on doit répondre
– Un deadline – le projet doit être terminé à une date fixe
– Des délivrables – les produits finis du projet
– Un planning indiquant quand chaque produit fini sera livré et comment les activités et donc la charge de travail sera
répartie dans le temps
– Des ressources dédiées partiellement ou totalement au projet
– Une structure de gouvernance

5. 5
 La phase d’analyse permettra de valider les points non encore détaillés du projet.
 Elle sera réalisée à partir des processus cibles communiqués par le client dans son cahier des
charges, complétés par les interviews des pilotes
 Le livrable Rapport d’adéquation définira les écarts entre le fonctionnement standard de la
solution logicielle et le système cible en proposant différentes solutions (développement,
modification d’organisation) pour le traitement de ces écarts
 La validation du livrable issue de cette étape est une condition nécessaire pour la poursuite du
projet et permet de définir l’ensemble du système d’information cible à réaliser durant le projet
 Il s’agit d’une réalisation d’analyse globale du périmètre projet, quel que soit ensuite le
découpage de la mise en œuvre. Ceci afin de bien appréhender l’ensemble de la problématique
avant de réaliser le paramétrage
La phase d’analyse

6. Le design (spécifications)
• Les spécifications détaillent les besoins métiers à un niveau suffisament détaillé que pour être non interprétables pour le développement de ces
spécifications
• Les spécifications détaillent les besoins métiers par rapport au système-cible
– Sur base d’une maquette
– Sur base d’un prototype
– Sur base d’une description détaillée
• Les spécifications doivent être formellement validées par le responsable du projet métiers
• Exemple de spécifications fonctionnelles pour des passages d’ordres
– Ecrans de passage d’ordres
– Listes d’ordres
– Mécanismes de validation des ordres
– Le flux des ordres
– Le calcul estimatif des frais de transactions
• Exemple de spécifications techniques
– Format des messages
– Mode de transmission des messages (synchrone, asynchrone)

7. L’importance du design
Besoins
utilisateurs
Design
tech & funct
Programmation
Tests unitaires
Tests
d’intégration
Tests
d’acceptance Maintenance
Source
des erreurs
Découverte
des erreurs
40% - 60% 20% - 40%
10% - 20% 20% - 50% 40% - 60%
On découvre que le design a été
mal fait pendant les tests …
Un mauvais design va générer beaucoup de travail en développement (re coding) après les tests et accroître les coûts
de développement du projet
10% - 20%
Besoins
utilisateurs
Design
tech & funct
Programmation
Tests unitaires
Tests
d’intégration
Tests
d’acceptance Maintenance

8. Le prototypage
• Méthode itérative pour spécifier et développer
• Applicable principalement pour des “packages”
• Sur base d’une première collecte des besoins, un prototype est développé et
passé en revue avec les utilisateurs
• Prérequis
– Une bonne anticipation des besoins métiers (expertise)
– Des utilisateurs raisonnables – le prototype doit permettre de valider les spécifications et non pas introduire une longue liste de
modifications
• Avantages
– Collecter les demandes de modifications pendant le design et non pendant le testing
– Développement en parallèle avec les spécifications
– Cadrer les spécifications – éviter le syndrôme de la page blanche (éviter des développements lourds sur des packages). Utiliser
des configurations prédéfinies

9. Le développement
• Se baser sur des configurations existantes (packages)
• Centraliser les configurations dans un fichier
– Réinitialisation des développements
– Baseline management – retour à une version précédente aisé
– Versioning aisé
• Version : état du développement
• Conservation des versions précédentes
– Documentation des développements

10. Les tests
• L’objectif de la phase de test est de valider que les spécifications ont correctement été implémentées
• Phases de test principales
– Tests unitaires
• Tests réalisés par le développeur
• Tests de chaque élément de développement
– Tests systèmes
• Tests réalisés par le développeur
• Tests de compatibilité de blocs de développement dans un même environnement
– Tests d’intégration
• Tests réalisés par une équipe de test projet
• Déroulement de jeux de tests fonctionnels
– Tests d’acceptation
• Tests réalisés par les utilisateurs
• Déroulement, une seconde fois, des jeux de tests fonctionnels
– Validation formelle par le responsable du projet de la mise en production

11. Les activités de tests
Test planning/Test Management
Définition de l’approche de
tests
Plans de tests Préparation des tests Exécution des tests
Mise en place des environnements de tests
•Objectifs
•Périmètre
•Risques
•Ressources
•Besoins d’environnement
•Metrics
•Critères d’acceptation
•Points de référence
•Planning
•Conditions de tests
•Cycles de tests
•Outils de tracking d’erreurs
•Jeux de tests
•Exécution des jeux de tests

12. Le roll out
• Le roll out est la mise en production d’une release. Il est conditionné à
l’approbation du métier (sur base des tests d’acceptation)
• Le roll out doit être accompagné
– D’un plan de formation des utilisateurs
– D’un accompagnement de l’équipe projet pendant les premiers mois de mise en production
• Résolution des problèmes
• Accompagnement utilisateurs
• On peut également avoir un “parallel run” avant une mise en production
effective. Les utilisateurs utilisent deux systèmes en parallèle (l’ancien et le
nouveau). Ils effectuent toutes leurs actions quotidiennes sur le système. Une
fois que le parallel run est validé par les utilisateurs, l’application peut être
mise en production
– Procédure lourde (production like)
– Allonge la période de test mais réduit le risque de problèmes en production

13. 13
La phase de conception
 La phase de conception permettra de valider les points non encore détaillés du projet.
 La complexité de cette phase est liée au nombre d’écarts qui pourraient être identifiés suite à la phase d’analyse
générale
 Tout écart est détaillé dans une fiche d’écart qui permettra d’évaluer la charge afférente et sa réalisation.
 Aucun développement n’est effectué sans Fiche d’écart validé par le Client.
13

14. 14
La phase de conception
14
Identifier les éléments non standards et de valider le périmètre et le budget afférent :
Fonctions non standard
Interfaces
Rapports
Reprise de données
La complexité de cette phase est liée au nombre d’écarts qui pourraient être identifiés suite à la phase
d’analyse générale
La démarche de conception se veut au plus proche de la solution standard
Qualification des besoins indispensables / cosmétiques
Cette phase sera également utilisée pour préparer la recette fonctionnelle
Identification des scénarios Métier
Construction des cas de tests
Collecte des jeux de données

15. 15
La phase de mise en production
La phase de mise en production acte du passage en exploitation la solution dans l’environnement de
production
La formation des utilisateurs finaux est effectuée à priori par l’équipe des pilotes client qui auront
préalablement rédigés les manuels utilisateurs.
Le décision du démarrage est validée par le comité de pilotage suite à la simulation en charge qui recrée
les conditions d’exploitation du démarrage.
La prestation de démarrage est systématiquement réalisée en fonction de la demande du client. Son
contenu et sa durée sont donc confirmés juste avant le go-live.

16. 16
La phase de réalisation
La phase de réalisation permettra de de paramétrer la solution et de réaliser les écarts exprimés en conception afin de
conduire à la validation du pilote.
 Elle nécessite une participation active de l’équipe projet du client
 Elle se caractérise par un transfert de compétence très fort entre les équipes de l’intégrateur et celle du client
 Elle intègre la réalisation des prestations liées à l’ingénierie qui sont menées en parallèle du paramétrage
 Elle se conclue par la présentation du prototype par l’équipe interne du client
16

17. 17
Vue d’ensemble
Réunion de Lancement
Installation
Formation découverte
Formation administrateur
Analyse générale
- fonctionnelle
- reprise de
données
- Interface
Développement
Formation key users
Transfert au Support
et Service client
Etude d’adéquation
Initialisation Analyse Conception ExploitationMise en production
Assistance au démarrage
Reprise de données
définitives
Analyse des écarts
ParamétrageReprise de données test
Tests et validation du pilote
Formation end users
Vérification GO / NO GO
Réalisation
Tests unitaires
Codification et Paramétrage de base
Gestion de projetPQP Validation S1 Validation S2
Recette définitive
17

18. 18
Livrables
Planning,
Plan Qualité Projet,
Compte rendu Réunion de
lancement,
Fiches d’écart,
Modèle Fichiers de reprise de
données
PV Reprise test, PV de recette
fonctionnelle
Dossier de paramétrage
PV de reprise de données
définitives,
Kit de déploiement
Rapport d’adéquation,
Tableau des écarts
PV de recette définitif
Procédure de support
Vue d’ensemble : LIVRABLES CLES
Initialisation Analyse Conception ExploitationMise en productionRéalisation
18

19. 19
Livrables
Planning,
Plan Qualité Projet,
Compte rendu Réunion de
lancement,
Fiches d’écart,
Modèle Fichiers de reprise de
données
PV Reprise test, PV de recette
fonctionnelle
Dossier de paramétrage
PV de reprise de données
définitives,
Kit de déploiement
Rapport d’adéquation,
Tableau des écarts
PV de recette définitif
Procédure de support
Vue d’ensemble : LIVRABLES CLES
Initialisation Analyse Conception ExploitationMise en productionRéalisation
19

20. Exemple de planning d’un programme
• Le macro planning montre l’étalement des releases, la charge hommes
liée à chaque release et les jalons principaux (milestones) du
programme
j f m a m j j a s o n d j f m a m j j a s o n d j f m a m j j a s o n d
Req's Performance Reporting
Visie Triple'A
Project Initiation Study
Release 1 - Client reporting
Release 1 - Branch Rollout
Release 2 - Order Entry
Release 3 - Performance attribution & GIPS
Total estimated effort in mandays 7
Duration in months 1
Major Milestones First Performance report sent to PCNL clients
AAA WUI available in branches
portfolio analysis supported by order entry and compliance checking
Client portfolio monitoring & performance attribution available
200
44
1663 MD
10
608
2 2
2212 MD + 1142 MD extract
10
85 120
Q3 Q4Q1 Q2Q3 Q4
Activities
2003 2004 2005
Q1 Q2 Q3 Q4 Q1 Q2

21. Exemple de planning détaillé
• Le planning reprend les activités principales, sous-activités, délivrables,
la fréquence des comités de pilotage
Activities W0 W1 W2 W3 W4 W5 W6 W7 W8 W9 W10
Kick off
Identify key focus areas
Inventorize and collect existing reusable materials
Identify high potential process/product combinations
Build the SEC metrics model
Assess SEC B cost model
Prepare input data
Perform data gathering
Analyze and allocate costs
Assess operational risks
Validate/cross check results with Fortis and experts
Evaluate SEC's performance through internal and external benchmarking
Apply internal and external benchmarking
Assess and identify low performance areas
Conduct solutions brainstorming workshop
Identify and shape potential solutions
Detail each identified solution
Evaluate impact on operational risks
For each solution, describe key actions
Assess feasibility
Assess impact of solution in terms of business model
Evaluate sourcing options
Provide insigth on Service Delivery models
Confirm, build business case & action plan
Prioritize initiatives
Conduct prioritization workshop
Confirm target business model
Build detailed action plan
Build business case
Project Management
Workshop
Kick off meeting
Steering committee
Deliverable / major milestone
Phase I (in weeks)
²

22. La structure d’un projet
• Un projet sera, si nécessaire, divisé en sous projets
– Chaque sous projet sera géré par un project manager
– Les project managers rapporteront à un program manager, en charge de l’ensemble du projet
– Le program manager rapportera l’état d’avancement du projet à un comité de pilotage
– Pour de gros projets, il existe un Program Management Office, en charge du suivi financier et administratif du projet
• La participation des métiers au projet
– Le sponsor du projet est, en général, un directeur du métier concerné
– Via un co management d’un projet par l’IT et le métier concerné
– Via une participation partielle ou à temps plein de représentants du métier dans le projet (définition des spécifications,
validation des prototypes, tests, validation des tests)

23. Project Manager Project Manager Project Manager
PMOArchitecture
• Sponsorship & propriété des projets/programmes
• Suivi de l’état d’avancement du projet et prise de décision en
matière de délivrables, périmètres, problèmes, ressources, etc…
• Responsable pour la livraison du programme
• Rapporte l’état d’avancement au comité de pilotage
• Gère les interdépendances entre projets
• Définit les processus et outils nécessaires pour la gestion du
programme et des projets
• Aide/accompagne le program manager et les project managers
• Assure la coordination et communication transversale
• Responsable pour le planning et la livraison des projets
• Rapporte le statut des délivrables, le planning, les risques et
problèmes au program manager
Comité de pilotage (*)Comité de pilotage (*)
SponsorSponsor
Comité ITComité IT
Program Manager
• Fixation et suivi de la stratégie et des plans à long terme
• Décisions clés sur les gros programmes et les projets
transversaux
Journalier
Journalier
Hebdo &
journalier
Hebdomadaire
Mois
Mois
Coordination
architecture
Support fonctionnel et
technique

24. 24
Les acteurs du projet

25. Gouvernance de projet
• Tout projet doit avoir un comité de pilotage approprié
• Une structure claire de projet et de gouvernance est nécessaire :
– Réalisation du projet avec succès
– Participation de toutes les parties impliquées
– Définition claire des rôles et responsabilités des personnes impliquées dans le projet et dans le comité de pilotage
– Contrôle et suivi étroit du progrès du projet
– Capacités à mitiger les risques
– Mécanismes clairs d’escalation des problèmes

26. Le rôle des membres du comité de pilotage
• Rôle
– Gardien de la vision et des objectifs du projet
– Gère la communication sur le projet vis-à-vis de tiers
– Suit le planning et les délivrables, pas les processus
• Responsabilités
– Règle les problèmes organisationnels et de ressources
– Gère l’allocation des ressources et les dépendances entre projets
– Est responsable de la communication au sein et en-dehors du projet
– Valide les délivrables
– Gère le périmètre et mitige les risques
• Fréquence de réunion : 1x/mois

27. Le rôle du program manager
• Rôle
– Gardien du planning du projet
– Assure la gestion du projet au jour le jour
– Gère le statut du projet
– Escale à temps et de manière appropriée les problèmes au comité de pilotage
• Responsabilités
– Coordonne les parties et s’assure de la réalisation du projet à temps
– Gère, planifie les ressources
– Gère les aspects financiers du projet
– Adhère aux best practices, méthodologies et outils de développement
– Gère le périmètre et les risques

28. Gouvernance du projet
Définir les objectifs
Valider les objectifs
Comité de pilotage
Program Mgmt
Définir le périmètre du
programme
Valider le périmètre du
programme
Project Management
Définir le périmètre du
projet
Valider le périmètre du
projet
Résoudre les
problèmes
Gérer le périmètre en
ligne avec attentes
métiers
Résoudre/escaler les
problèmes
Gérer le périmètre du
programme
Résoudre/escaler les
problèmes
Gérer le périmètre du
projet
Exécution
du projet

29. • Gestion des ressources
Implementation
et Roll Out
TasksDeliverables
• Organiser les trainings
• Mettre en place l’environnement de
production
• Effectuer un parallel run
• Effectuer la migration
• Assurer le suivi post mise en production
Test
• Effectuer des tests d’intégration
• Effectuer les tests d’acceptation
• Mettre en place les environnements de
d’acceptation
• Les cas de tests
• Les résultats de tests
• Validation des tests utilisateurs
• Le plan de formations
• Le plan de support post implémentation
• Suivi du budget
• Suivi du projet
Design Build/Unit test
Program Management Office
Conduite du changement
• Etablir le design fonctionnel de la solution
• Etablir le design technique
• Définir les éléments à développer (formats, écrans,….)
• Définir l’approche de test et l’architecture technique
• Définir le contenu des formations
• Définir les nouveaux processus, l’impact sur des processus
existants
• Mettre en place l’environnement de développement
• Design fonctionnel
• Design technique
• Design des processus
• Plans de tests/stratégie de tests
• Design de l’architecture
• Développer les interfaces
• Développer l’application
• Effectuer du nettoyage de données
• Effectuer les tests unitaires de l’interface et de
l’application
• Mettre en place les environnements de test
• Les programmes
Infrastructure

30. La gestion des environnements
• Plusieurs environnements sont nécessaires pour implémenter une nouvelle application
– Un ou plusieurs environnements de développement
– Un ou plusieurs environnements de test
– Un ou plusieurs environnements d’acceptation
– Un ou plusieurs environnements de production
• Chaque environnement supporte une version de l’application (application, base de données, interfaces..)
• Plusieurs environnements peuvent se trouver sur la même machine physique. En pratique, pour des applications lourdes, une
machine est utilisée par environnement
• L’installation d’une machine prend du temps (+/- 2 mois) et doit donc être bien planifiée. On commence d’abord par installer
la machine de développement
• La gestion des environnements de développement et de tests est, en général, effectuée par le projet
• La gestion des environnements d’acceptation et de production est, en générale, effectuée par le département qui “hostera”
les machines en production

31. La gestion des environnements
DEV TEST UAT PROD
Projet Production
Migration d’un package
de développement
Migration d’un package
de développement
Migration d’un package
de développement
Correction d’un bug
Maître pour les
développements

32. 6. Gestion des
releases
6. Gestion des
releases
5. Gestion des
ressources
5. Gestion des
ressources
4. Gestion financière
et business case
4. Gestion financière
et business case
7. Coordination avec les
achats
7. Coordination avec les
achats
8. Gestion des
contrats
8. Gestion des
contrats
9. Quality
management
9. Quality
management
10. Coordination avec
Architecture
10. Coordination avec
Architecture
12. Communication12. Communication
1. Programme
tracking & reporting
1. Programme
tracking & reporting
2. Gère le périmètre2. Gère le périmètre
3. Gère les risques3. Gère les risques
Suivi du
périmètre
Follow-up sur base de
critères de qualité
Rapporte l’état
d’avancement
Identifie les
risques
Suivi de l’allocation
des ressources
Fournit les données pour
les budgets et calcul des
coûts
11. Coordination du
changement
11. Coordination du
changement
Planning définit le
contenu des releases
Les activités d’un PMO

33. Les processus gérés par le PMO
Processus de
Program management
Besoins
Gestion du budget Monitoring du taux d’activité sur base du planning et du plan de staffing
Change control Contrôle strict sur les augmentations, réductions de périmètre, avec évaluation par rapport au business case, au planning et aux coûts.
Ces points doivent être escalés au Comité de Pilotage
Délivrables/milestones/
Dependency management
Un mécanisme de tracking doit être suivi par tous les project managers
Problèmes Une des priorités des project managers est de résoudre les problèmes
Réunions de projets Les réunions sont focalisées sur l’état d’avancement (par rapport au budget, au planning, aux délivrables), les problèmes et le change control
Qualité Des revues de qualité sont organisées afin de vérifier que le projet est géré selon de bonnes règles de gestion de projet
Gestion des ressources Besoin d’anticiper les besoins en ressources et allocation au bon moment aux différents sous projets
Risques Les risques doivent être bien documentés et escalés systématiquement au comité de pilotage
Suivi du temps passé Tout membre du projet doit rapporter son temps avec un niveau de détail suffisant que pour assurer un bon contôle financier du projet
Gestion du planning Utilisation d’un outil de planning commun pour tous les sous projets. Les planning sont gérés par chaque sous projet.
Tous les plannings alimentent un programme commun utilisé pour le suivi budgétaire

34.  Spécifications fonctionnelles
 Complexité métier
 Software “Fit”
 Technical “Fit”
 Capacité de la société à accepter le
changement
 Intégration et effort de conversion
Facteurs Base
– Nombre de fonctions business impactées
– # employés et utilisateurs
– Degré de changement des processus
– Qualité des données mainframe
– Nombre de modifications attendues/extensions
– Existence d’un environnement technique approprié
– Expérience avec les changements passés
– Processus de prise de décision
– Sponsoring du projet
– Résistance au changement
– # interfaces & conversions
– Complexité de l’ integration
– Approche de conversion
+
-
Estimating
Accuracy
Project Phases...
Initial
Assessment
Global
Design and
Prototype
Conceptual
Design
Build
and
Rollout
20-25% 15-20% 10-15%
L’estimation de l’effort
• L’estimation de l’effort est une activité itérative. Plus l’incertitude
diminue, meilleure est l’estimation

35. L’estimation de l’effort -méthode de chiffrae
Conception du modèle opératoire
Communication et Formation
Plan et exécution de tests systèmes
Planning de roll-out et exécution
Gestion du projet
Equipe de support technique
Développement & Test
Spécifications fonctionnelles
Configuration de l’application & Prototype avec
utilisateurs
Conception des processus métiers
Activité Base d’estimation
Estimation d’implémentation
# de pratiques métiers
# de conversions
(manuel / auto)
# d’interfaces entrantes
# d’interfaces sortantes
# de rapports
# de modules
Durée du projet
Taille approx de l’équipe
• Approche bottom -up
• Charge de travail/ état du projet
• Basé sur des benchmarks, points de références
Processus
d’estimation
itératif

36. Outils - Le suivi financier de projets
• Il est important de pouvoir suivre le coût du projet par rapport à un
budget initial (“baseline”) et de justifier les écarts

37. Outils - Les rapports d’avancement
• Rapporter de manière synthétique l’état d’avancement, les risques, les
problèmes....Identification des délivrables clés réalisés.
2
V6 - AVANCEMENT
Statut du Projet au 31/01/2002 Consommé % Gagné %
Pilotage V6
DDL V6
Développements V6
TA Documentation/Préparation
TA Execution/Correction
Recette fonctionnelle V6
Total V6
Budget :
Indicateurs physiques
Risques identifiés
Evaluation
Respect du calendrier :
Respect des budgets :
Dépassement budgétaire sur
certains projets (développement et TA).
116%
135%
104%
182%
102%
48%
100%
100%
100%
100%
96%
85%
Périmètre propositions V6-P1 : 871 jh
Périmètre propositions V6-P2 : 139 jh
Evolutions V6 validées : 58,5 jh (1)
Hors version traité en V6 : 12 jh
Forecast end :
1101 jh
Ratio E/B :
1,09
Proposition validée : 871 jh +139 jh + 70,5 jh évolutions => 1080,5 jh
Total V6 ouvert P1&P2 : 1010 jh
(1) CF Budget évolutions annexé
107% 98%
Périmètre 1 :
- Recette fonctionnelle terminées sur les 10 sujets la composant..
Périmètre 2 :
- 2 dossiers de SFD livrés (DAJNANTI2 et UGMADH01)
- 1 dossier validé par Predica (DAJNANTI2)
- Matrices de tests et cycles de tests validés par PREDICA.
- La nouvelle consultation CEVT a levée un problème
de pagination lié à l’architecture existante, ce point
sera traité lors d’une réunion entre DSI / Accenture
/ IFS le jeudi 07/02. (QR VR17)



38. Outils – Le suivi des ressources (time reports)
• Il est important de tracker le nombre d’heures passées sur le projet; ce
coût étant le principal coût d’un projet d’implémentation
• Chacun rapporte ses heures consommées dans un time report
• Ceci est utilisé pour le suivi financier du projet, la facturation du projet
et éventuellement, le paiement d’heures supplémentaires

39. Outils – Le suivi des ressources (time reports)

40. La gestion des “change requests”
• Le périmètre est fixé avant le démarrage du projet dans une phase de
préparation, cadrage du projet
• Il est fréquent que, de nouveaux besoins soient exprimés en cours de
projet.
• Ceux-ci influencent la charge de travail totale du projet et peuvent
mettre la date de livraison en péril. D’où l’importance pour un program
manager de :
– Bien qualifier chaque change request (un change request trop lourd doit être repoussé dans une release ultérieure)
– Suivre de manière spécifique les change requests (état d’avancement, charge de travail)
– Faire valider l’inclusion de change requests dans le périmètre du projet par le comité de pilotage

41. La gestion des “change requests”
• Illustration d’un rapport de suivi de l’état d’avancement
Fiche Q/R Thème
CdC livré par
PDK
CdC mis à
jour par
Accenture
Référence
note de
proposition
Accenture
Référence note
de validation
PREDICA
Charge
(coeff.
managemen
t et
supports
inclus)
Date de
livraison
prévue
Statut
V6
QR MOA-10 Ajout de cas sur CEVT Non Non CF Q/R N/A 9 N/A
Cloturée - Non retenue par
PREDICA
QR MOA-21
Supprimer l'exclusion "décès suite à
maladie"
Non Non CF Q/R N/A 4 N/A
Cloturée - Pas de changement de
barème pour la recette
fonctionnelle
QR MOA-22
DEVGBFIN - Possibilité de choisir parmi
2 options
Non Non CF Q/R N/A 15 N/A
Cloturée - Non retenue par
PREDICA
QR MOA-09 Modification de libellés sur CEVT Non Non CF Q/R DSI/01.0846/JML 8 31/12/2001 Cloturée
QR MOA-11
Génération de plusieurs lignes de
messages pour un même actes de
gestion sur CEVT
Non Non CF Q/R DSI/01.0847/JML 7 31/12/2001 Cloturée
QR MOA-12 Interdiction des VEEX classique sur 3 en 1Non Non CF Q/R DSI/01.0905/MJL 4 31/12/2001 Cloturée
QR MOA-14 Ajout de détail sur événement MORI Non Non CF Q/R DSI/01.0931/MJL 6 31/12/2001 Cloturée
QR Projets FR-20 Livraison MCD pacte adjoint Non Non CF Q/R DSI/01.0973/MJL 10 18/02/2002 Cloturée
QR Projets FR-22 DAJDCVIR problème objets communs Non Non CF Q/R DSI/01.1042/MJL 2 18/02/2002 Cloturée
QR Projets SV610 Reprise du montant minimum disponible Non Non CF Q/R DSI/02.0074/MJL 14 18/02/2002 Cloturée
QR SV6-11
MOCB/MBAC : délégation des fonction
MOCB en fonction du type bénéficiaire
Non Non CF Q/R DSI/02.0098/MJL 0,5 18/02/2002 Cloturée
QR Projets FR09
Précisions au cdc initial suite aux
modifications des courriers et des flux
Non Non CF Q/R DSI/02.0083/MJL 7 18/02/2002 Cloturée
QR PDK-01 Evolution BCIE - Indicateur Support UC Non Non CF Q/R CF FM 12 18/02/2002 Cloturée
70,5Total V6 validé

42. Le design (spécifications)
• Les spécifications détaillent les besoins métiers à un niveau suffisament détaillé que pour être non interprétables pour le développement de ces
spécifications
• Les spécifications détaillent les besoins métiers par rapport au système-cible
– Sur base d’une maquette
– Sur base d’un prototype
– Sur base d’une description détaillée
• Les spécifications doivent être formellement validées par le responsable du projet métiers
• Exemple de spécifications fonctionnelles pour des passages d’ordres
– Ecrans de passage d’ordres
– Listes d’ordres
– Mécanismes de validation des ordres
– Le flux des ordres
– Le calcul estimatif des frais de transactions
• Exemple de spécifications techniques
– Format des messages
– Mode de transmission des messages (synchrone, asynchrone)

43. L’importance du design
Besoins
utilisateurs
Design
tech & funct
Programmation
Tests unitaires
Tests
d’intégration
Tests
d’acceptance Maintenance
Source
des erreurs
Découverte
des erreurs
40% - 60% 20% - 40%
10% - 20% 20% - 50% 40% - 60%
On découvre que le design a été
mal fait pendant les tests …
Un mauvais design va générer beaucoup de travail en développement (re coding) après les tests et accroître les coûts
de développement du projet
10% - 20%
Besoins
utilisateurs
Design
tech & funct
Programmation
Tests unitaires
Tests
d’intégration
Tests
d’acceptance Maintenance

44. Le prototypage
• Méthode itérative pour spécifier et développer
• Applicable principalement pour des “packages”
• Sur base d’une première collecte des besoins, un prototype est développé et
passé en revue avec les utilisateurs
• Prérequis
– Une bonne anticipation des besoins métiers (expertise)
– Des utilisateurs raisonnables – le prototype doit permettre de valider les spécifications et non pas introduire une longue liste de
modifications
• Avantages
– Collecter les demandes de modifications pendant le design et non pendant le testing
– Développement en parallèle avec les spécifications
– Cadrer les spécifications – éviter le syndrôme de la page blanche (éviter des développements lourds sur des packages). Utiliser
des configurations prédéfinies

45. Le développement
• Se baser sur des configurations existantes (packages)
• Centraliser les configurations dans un fichier
– Réinitialisation des développements
– Baseline management – retour à une version précédente aisé
– Versioning aisé
• Version : état du développement
• Conservation des versions précédentes
– Documentation des développements

46. Les tests
• L’objectif de la phase de test est de valider que les spécifications ont correctement été implémentées
• Phases de test principales
– Tests unitaires
• Tests réalisés par le développeur
• Tests de chaque élément de développement
– Tests systèmes
• Tests réalisés par le développeur
• Tests de compatibilité de blocs de développement dans un même environnement
– Tests d’intégration
• Tests réalisés par une équipe de test projet
• Déroulement de jeux de tests fonctionnels
– Tests d’acceptation
• Tests réalisés par les utilisateurs
• Déroulement, une seconde fois, des jeux de tests fonctionnels
– Validation formelle par le responsable du projet de la mise en production

47. Les activités de tests
Test planning/Test Management
Définition de l’approche de
tests
Plans de tests Préparation des tests Exécution des tests
Mise en place des environnements de tests
•Objectifs
•Périmètre
•Risques
•Ressources
•Besoins d’environnement
•Metrics
•Critères d’acceptation
•Points de référence
•Planning
•Conditions de tests
•Cycles de tests
•Outils de tracking d’erreurs
•Jeux de tests
•Exécution des jeux de tests

48. Le roll out
• Le roll out est la mise en production d’une release. Il est conditionné à
l’approbation du métier (sur base des tests d’acceptation)
• Le roll out doit être accompagné
– D’un plan de formation des utilisateurs
– D’un accompagnement de l’équipe projet pendant les premiers mois de mise en production
• Résolution des problèmes
• Accompagnement utilisateurs
• On peut également avoir un “parallel run” avant une mise en production
effective. Les utilisateurs utilisent deux systèmes en parallèle (l’ancien et le
nouveau). Ils effectuent toutes leurs actions quotidiennes sur le système. Une
fois que le parallel run est validé par les utilisateurs, l’application peut être
mise en production
– Procédure lourde (production like)
– Allonge la période de test mais réduit le risque de problèmes en production