Cours 5_Gestion de projets

1. La gestion de projets informatiques
Gestion des technologies de l’information –
GEST310
Pascale Vande Velde

2. |2
Agenda
• Introduction
• Structure d’un projet
• Gouvernance de projets
• Les grandes phases d’un projet d’implémentation
– La conduite du changement
– Le Program Management Office
– Le release management
– La conception
– Le développement
– Les tests
– Le roll out

3. |3
Introduction
• 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

4. |4
Introduction
• Typologie de projets
– < 50 jours hommes, maintenance
– 50 < X < 500 jours hommes – petit projet
– 500 < X < 3,000 jours hommes – projet moyen
– X > 3,000 jours hommes – large projet
– X > 20,000 jours hommes – mega projet

5. |5
Exemple de planning d’un 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
4
4
1663 MD
10
608
2 2
2212 MD + 1142 MD extract
10
85 120
Q3 Q4
Q1 Q2
Q3 Q4
Activities
2003 2004 2005
Q1 Q2 Q3 Q4 Q1 Q2
• Le macro planning montre l’étalement des releases, la charge hommes liée
à chaque release et les jalons principaux (milestones) du programme

6. |6
Exemple de planning détaillé
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)
²
• Le planning reprend les activités principales, sous-activités, délivrables, la
fréquence des comités de pilotage

7. |7
Cas – Implémentation d’un système de gestion
de portefeuille dans une banque privée (1)
• Release 1 : alimentation du package par des données back offices (titres,
espèces, comptes à terme) et production d’un rapport de gestion clients
• Release 2 : mise en place des fonctionnalités de gestion de portefeuille
(calculs de return, gestion des portefeuilles contre stratégies et contraintes,
benchmarking, passages d’ordres....), roll out du package sur 50 utilisateurs
répartis sur 5 agences
• Release 3 : enrichissement du flux d’ordres, roll out du package sur 200
utilisateurs répartis dans 20 agences
• Planning
– Release 1 : juin 2003 à août 2004
– Release 2 : septembre 2004 à juillet 2005
– Release 3 : juillet 2005 à fin 2005

8. |8
Cas – Implémentation d’un système de gestion
de portefeuille dans une banque privée (2)
• Quelques chiffres
– Nombre d’utilisateurs : 250
– Nombre de portefeuilles : 40,000
– Actifs en gestion : 40 milliards EUR
– Parts de marché private banking NL : 30%
– Coûts release 1 – 10,5 MEUR
• Coûts licences : 1,5 MEUR
• Coûts implémentation : 7 MEUR (+/- 7,000 jours hommes, 35 personnes sur un an)
• Coûts infrastructure : 2 MEUR
– Coûts release 2 – 8,5 MEUR
• Coûts de licence : 0,5 MEUR
• Coûts d’implémentation : 6 MEUR (+/- 6,000 jours hommes)
• Coûts infrastructure : 2 MEUR
– Coûts cumulés release 1 + 2 : 19 MEUR

9. |9
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)

10. |10
Project Manager Project Manager Project Manager
PMO
Architecture
• 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 (*)
Sponsor
Comité 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

11. |11
Cas – Implémentation d’un système de gestion
de portefeuille dans une banque privée (3)
Program manager
Implémentation
Package
Change
Management
Interfaces banque
Architecture

12. |12
• 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
Gouvernance de projet

13. |13
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

14. |14
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

15. |15
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

16. |16
Cas – Implémentation d’un système de gestion
de portefeuille dans une banque privée (4)
• Implémentation d’un outil de gestion de portefeuille dans une banque
privée, n’ayant pas d’IT mais se reposant sur les systèmes back office de sa
maison-mère (titres, espèces, money markets, administration clients)
• Les interdépendances avec les back offices sont très fortes étant donné la
nécessité d’interfacer le PM package avec ces back offices pour remonter
les clients, portefeuilles, transactions journalièrement
• Les interdépendances avec le département infrastructure de la maison-mère
sont également très fortes; étant donné que l’infrastructure du package
devra être installée et gérée par ce département
• Le comité de pilotage incluait
– Le COO de la banque privée
– Le Chief Investment Officer de la banque privée
– Le directeur du département infrastructure IT
– Les responsables métiers et IT de chaque back office

17. |17
Cas – Implémentation d’un système de gestion
de portefeuille dans une banque privée (5)
PMS
Titres
Espèces
Clients
Rapports
clients
Responsabilité des projets d’extraction Responsabilité du projet
Banque Privée
Maison-mère

18. |18
Les grandes phases d’un projet d’implémentation
• Tout projet d’implémentation suit la même séquence d’activités
Design
fonctionnel et
technique
Développement
et tests
unitaires
Tests
d’intégration
Déploiement
Tests
d’acceptation
PROJECT
Demande
30-40% 20% 20% 20% 0-10%
Comité de pilotage
Infrastructure
PMO
Conduite du changement

19. |19
• Gestion des ressources
Implementation
et Roll Out
Tasks
Deliverables
• 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

20. |20
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
PMO
Roll-out
Test
Design Build
Infrastructure
Change

21. |21
La gestion des environnements
PMO
Roll-out
Test
Design Build
Infrastructure
Change
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

22. |22
La conduite du changement
• Les facteurs d’échec :
– Un manque de communication ou une communication inappropriée
– Un manque d’implication du client dans le projet. Le projet est réalisé par l’IT ou
par une partie externe
– Manque de support du management pour l’utilisation du système
– Mismatch au niveau des attentes utilisateurs
– L’organisation n’est pas prête/revue pour la mise en production de l’application
– Les rôles, les compétences des utilisateurs ne sont pas adaptés à la nouvelle
manière de fonctionner
– Manque de prise de conscience des avantages du nouveau système
– Trop peu de formations ou des formations inappropriées
PMO
Roll-out
Test
Design Build
Change
Infrastructure

23. |23
La conduite du changement – d’une attitude négative
Source: Kuebler-Ross, 1969: Conner, 1992
Actif
Immobilisation
crainte, confusion
Rejet réaction
défensive face à une
situation
inacceptable
Efforts pour
regagner le
contrôle de la
situation
Bargaining
Minimise l’impact du
changement
Dépression frustration, sentiment d’échec
Test, essaye de
nouvelles choses
Acceptation du
changement, réalisme
Changement positif
Changement négatif
Temps
PMO
Roll-out
Test
Design Build
Change
Infrastructure

24. |24
La conduite du changement – à une attitude
positive
Niveau
d’acceptation
du
changement
Temps
“De quoi s’agit-il ?”
Contact
“Pourquoi remplace-t-on un bon système ?”
Prise de conscience
“Qu’est-ce que cette nouvelle organisation
signifie pour moi ?? ”
Compréhension
“Semble bien sur papier, mais nous
changeons tout le temps. Quand puis-je
l’essayer ?”
Test
Acceptation “Comment cela impacte-t-il mon
travail journalier ?”
Frontière de l’engagement
Propriété/Buy in
“ Comment puis-je convaincre
d’autres de changer ? ”
Acceptation/Propriété
Résistance
PMO
Roll-out
Test
Design Build
Change
Infrastructure

25. |25
La conduite du changement – les moyens à
mettre en oeuvre
Niveau
d’acceptation
du
changement
Temps
Contact
Prise de conscience
Compréhension
Test
Acceptation
Frontière de l’engagement
Propriété/Buy in
Acceptation/Propriété
Résistance
 Communiquer à chancun l’impact du changement
 Utiliser les sponsors et des agents de changement pour délivrer
des messages, …
 Communiquer à chacun quelles opportunités le projet lui
offre
 Utiliser les sponsors du projet pour réduire la résistance
 Développer un plan d’action pour lever les barrières
 Communiquer le planning d’implémentation
 Mener des formation sur les nouveaux concepts, …
 Implémenter des formations centrées sur l’utilisation à
long terme du système
 Communiquer les résultats du changement
 Revoir les bonus, etc… en fonction des changements
PMO
Roll-out
Test
Design Build
Change
Infrastructure

26. |26
6. Gestion des
releases
5. Gestion des
ressources
4. Gestion
financière et
business case
7. Coordination
avec les achats
8. Gestion des
contrats
9. Quality
management
10. Coordination
avec Architecture
12.
Communication
1. Programme
tracking &
reporting
2. Gère le
périmètre
3. 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
Planning définit le
contenu des
releases
Les activités d’un PMO
PMO
Roll-out
Test
Design Build
Change
Infrastructure

27. |27
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
PMO
Roll-out
Test
Design Build
Change
Infrastructure

28. |28
 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
PMO
Roll-out
Test
Design Build
Change
Infrastructure

29. |29
L’estimation de l’effort
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
PMO
Roll-out
Test
Design Build
Change
Infrastructure

30. |30
Cas – Implémentation d’un système de gestion
de portefeuille dans une banque privée (6)
• Estimation de la charge de travail par partie
• Exemple de montée en charge
PMO
Roll-out
Test
Design Build
Change
Infrastructure

31. |31
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
PMO
Roll-out
Test
Design Build
Change
Infrastructure

32. |32
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)


PMO
Roll-out
Test
Design Build
Change
Infrastructure

33. |33
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
PMO
Roll-out
Test
Design Build
Change
Infrastructure

34. |34
Outils – Le suivi des ressources (time reports)
PMO
Roll-out
Test
Design Build
Change
Infrastructure

35. |35
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
PMO
Roll-out
Test
Design Build
Change
Infrastructure

36. |36
La gestion des “change requests”
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 1
Non 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,5
Total V6 validé
• Illustration d’un rapport de suivi de l’état d’avancement
PMO
Roll-out
Test
Design Build
Change
Infrastructure

37. |37
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)
Roll-out
Test
Design Build
Change
PMO
Infrastructure

38. |38
Cas – Implémentation d’un système de gestion
de portefeuille dans une banque privée (7)
• Exemple de design de calcul de performance (basé sur un prototypage)
• Exemple de design de rapport de gestion (basé sur une maquette)
Roll-out
Test
Design Build
Change
PMO
Infrastructure

39. |39
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
Roll-out
Test
Design Build
Change
PMO
Infrastructure

40. |40
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
Roll-out
Test
Design Build
Change
PMO
Infrastructure

41. |41
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
PMO
Roll-out
Test
Design Build
Change
Infrastructure

42. |42
Cas – Implémentation d’un système de gestion
de portefeuille dans une banque privée (8)
• Exemple d’un fichier de développement
• Exemple d’un inventaire de développement
PMO
Roll-out
Test
Design Build
Change
Infrastructure

43. |43
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
PMO
Roll-out
Design
Change
Infrastructure
Build Test

44. |44
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
PMO
Roll-out
Design
Change
Infrastructure
Build Test

45. |45
Cas – Implémentation d’un système de gestion
de portefeuille dans une banque privée (8)
• Périmètre
• Critères d’acceptation
• Points de référence
• Tracking sheet
PMO
Roll-out
Design
Change
Infrastructure
Build Test

46. |46
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
PMO
Test
Design
Change
Infrastructure
Build Roll out