La gestion de projets informatiques

Gestion des technologies de l’information –

GEST310

Pascale Vande Velde

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

|2
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

|3
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

|4
 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
2003 2004 2005
Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4
Activities 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 85 7 120 2212 MD + 1142 MD extract 608 1663 MD 200
Duration in months 2 1 2 10 4 10 4
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

|5
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
Phase I (in weeks)

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
|6
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

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

|8
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)

|9
 • Fixation et suivi de la stratégie et des plans à long
terme

Mois Comité IT • Décisions clés sur les gros programmes et les

projets transversaux

• Sponsorship & propriété des projets/programmes

Sponsor • Suivi de l’état d’avancement du projet et prise de
décision en matière de délivrables, périmètres,
Comité de problèmes, ressources, etc…
Mois
pilotage (*)
(*)
• Responsable pour la livraison du programme

Hebdo & Program • Rapporte l’état d’avancement au comité de

journalier pilotage
Manager
• Gère les interdépendances entre projets
 Coordination
architecture PMO
Architecture • Définit les processus et outils nécessaires pour la
 Support gestion du programme et des projets
Journalier
fonctionnel et Hebdomadaire • Aide/accompagne le program manager et les project
technique managers
• Assure la coordination et communication transversale

• Responsable pour le planning et la livraison des

Project Manager Project Manager Project Manager projets
Journalier
• Rapporte le statut des délivrables, le planning, les
risques et problèmes au program manager

Propal Dexia 040319 |10

Cas – Implémentation d’un système de gestion
de portefeuille dans une banque privée (3)

Program manager

Architecture

Implémentation
Change
Package Interfaces banque
Management

|11
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

|12
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

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

|14
 Gouvernance du projet
Comité de pilotage Définir les Résoudre les
objectifs problèmes

Gérer le
Valider les périmètre en
objectifs ligne avec
attentes métiers

Program Mgmt
Définir le Résoudre/escaler
périmètre du les problèmes
programme

Valider le Gérer le
périmètre du périmètre du
programme programme

Project
Management Définir le Résoudre/escaler
périmètre du les problèmes
projet

Valider le Exécution Gérer le

périmètre du périmètre du
projet du projet projet
|15
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

|16
Cas – Implémentation d’un système de gestion
de portefeuille dans une banque privée (5)
Maison-mère Banque Privée

Titres
Titres PMS
PMS

Rapports
Rapports
clients
Espèces clients
Espèces

Clients
Clients

Responsabilité des projets d’extraction Responsabilité

Responsabilitédu
duprojet
projet
Responsabilité des projets d’extraction

|17
 Les grandes phases d’un projet d’implémentation
• Tout projet d’implémentation suit la même séquence d’activités
Comité de pilotage
Conduite du changement
PMO

Infrastructure

Demande PROJECT

Design Développement Tests Tests Déploiement

fonctionnel et et tests d’intégration d’acceptation
technique unitaires

30-40% 20% 20% 20% 0-10%

|18
 Conduite du changement
Program Management Office
• Gestion des ressources • Suivi du budget
• Suivi du projet

Infrastructure

Design Build/Unit test Test Implementation

et Roll Out
•
•
Etablir le design fonctionnel de la solution
Etablir le design technique
• Développer les interfaces • Effectuer des tests d’intégration • Organiser les trainings
• Développer l’application • Mettre en place l’environnement de production
• Définir les éléments à développer (formats, écrans,….)
• Effectuer du nettoyage de données
• Effectuer les tests d’acceptation
• Définir l’approche de test et l’architecture technique • Effectuer un parallel run
• Définir le contenu des formations • Effectuer les tests unitaires de l’interface et de l’application • Mettre en place les environnements de • Effectuer la migration
• Définir les nouveaux processus, l’impact sur des processus existants
• Mettre en place l’environnement de développement • Mettre en place les environnements de test d’acceptation • Assurer le suivi post mise en production
Tasks

• Design fonctionnel • Les programmes • Les cas de tests • Le plan de formations

Deliverables

• Design technique • Les résultats de tests • Le plan de support post

• Design des processus
• Plans de tests/stratégie de tests • Validation des tests utilisateurs implémentation
• Design de l’architecture

|19
 Change
Infrastructure
PMO
Design Build Test Roll-out

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

|20
 Change
Infrastructure
PMO
Design Build Test Roll-out

La gestion des environnements

Projet Production

DEV TEST UAT PROD

Migration d’un Migration d’un Migration d’un

package de package de package de
développement développement développement

Maître pour les

développements

Correction d’un bug

|21
 Infrastructure
Change
PMO
Design Build Test Roll-out

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

|22
 Infrastructure
Change
PMO
Design Build Test Roll-out

La conduite du changement – d’une attitude négative

Efforts pour
Acceptation du
regagner le Bargaining changement, réalisme
Actif

contrôle de la Minimise l’impact du

situation
changement

Rejet réaction
défensive face à une
Test, essaye de
Immobilisation situation
nouvelles choses
crainte, confusion inacceptable
Passif

Dépression frustration, sentiment d’échec

Temps
Source: Kuebler-Ross, 1969: Conner, 1992

Changement négatif Changement positif

|23
 Infrastructure
Change
PMO
Design Build Test Roll-out

La conduite du changement – à une attitude

positive
Niveau d’acceptation du changement

“ Comment puis-je convaincre

Propriété/Buy in
d’autres de changer ? ”

Acceptation “Comment cela impacte-t-il mon

travail journalier ?”
Frontière de l’engagement
Test “Semble bien sur papier, mais nous
changeons tout le temps. Quand puis-je
l’essayer ?”
Compréhension
“Qu’est-ce que cette nouvelle organisation
Prise de conscience
signifie pour moi ?? ”
Contact
“Pourquoi remplace-t-on un bon système ?”
“De quoi s’agit-il ?”
Temps
Résistance Acceptation/Propriété
|24
 Infrastructure
Change
PMO
Design Build Test Roll-out

La conduite du changement – les moyens à

mettre en oeuvre
Niveau d’acceptation du changement

 Implémenter des formations centrées sur l’utilisation à

long terme du système
Propriété/Buy in  Communiquer les résultats du changement
 Revoir les bonus, etc… en fonction des changements

Acceptation  Développer un plan d’action pour lever les barrières

 Communiquer le planning d’implémentation
Frontière de l’engagement  Mener des formation sur les nouveaux concepts, …

Test
 Communiquer à chacun quelles opportunités le projet lui
offre
 Utiliser les sponsors du projet pour réduire la résistance
Compréhension
 Communiquer à chancun l’impact du changement
Prise de conscience  Utiliser les sponsors et des agents de changement pour délivrer
Contact des messages, …

Temps

Résistance Acceptation/Propriété
|25
 Infrastructure
Change
PMO
Design Build Test Roll-out

Les activités d’un PMO

12.
12. 2. Gère le
Communication périmètre
11.
11.
Coordination du
changement
Rapporte Suivi du 3.
3. Gère
Gère les
les
l’état périmètre risques
d’avancement

10.
10. Coordination
Coordination Identifie les
avec Architecture risques

1. Programme
Programme 4. Gestion
Follow-up sur financière
tracking & financière et
et
base de critères Fournit les
reporting
reporting business
business case
case
de qualité données pour les
budgets et calcul
9. Quality
des coûts
management
management
Suivi de
Planning définit le l’allocation des
contenu des ressources 5. Gestion des
releases ressources
8. Gestion des
contrats

7. Coordination 6. Gestion des

avec
avec les
les achats
achats releases
releases

|26
 Infrastructure
Change
PMO
Design Build Test Roll-out

Les processus gérés par le PMO

Processus de Besoins
Program management

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/ Un mécanisme de tracking doit être suivi par tous les project managers
Dependency management

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

|27
 Infrastructure
Change
PMO
Design Build Test Roll-out

L’estimation de l’effort
• L’estimation de l’effort est une activité itérative. Plus l’incertitude diminue,
meilleure est l’estimation
Estimating Facteurs Base
Accuracy
 Spécifications fonctionnelles – Nombre de fonctions business
impactées

– # employés et utilisateurs
 Complexité métier – Degré de changement des processus
+ – Qualité des données mainframe
20-25% 15-20% 10-15%
 Software “Fit” – Nombre de modifications
attendues/extensions

-  Technical “Fit” – Existence d’un environnement

technique approprié

 Capacité de la société à – Expérience avec les changements

accepter le changement passés
– Processus de prise de décision
– Sponsoring du projet
– Résistance au changement
Project Phases...
 Intégration et effort de – # interfaces & conversions
Global Build conversion – Complexité de l’ integration
Initial Conceptual
Assessment Design
Design and and – Approche de conversion
Prototype Rollout

|28
 Infrastructure
Change
PMO
Design Build Test Roll-out

L’estimation de l’effort
Activité Base d’estimation

Conception du modèle opératoire # de pratiques métiers

Conception des processus métiers # de conversions

(manuel / auto)
Configuration de l’application &
Estimation d’implémentation
Prototype avec utilisateurs
# d’interfaces entrantes
Spécifications fonctionnelles
Processus
# d’interfaces sortantes d’estimation
Développement & Test itératif

Equipe de support technique
Communication et Formation
Plan et exécution de tests systèmes
# de rapports
• Approche bottom -up
# de modules • Charge de travail/ état du projet
• Basé sur des benchmarks, points de
références
Taille approx de l’équipe

Planning de roll-out et exécution

Gestion du projet Durée du projet

|29
 Infrastructure
Change
PMO
Design Build Test Roll-out

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

|30
 Infrastructure
Change
PMO
Design Build Test Roll-out

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

|31
 Infrastructure
Change
PMO
Design Build Test Roll-out

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.
V6 - AVANCEMENT 2

Risques identifiés
Statut du Projet au 31/01/2002 Consommé % Gagné %

Pilotage V6 116% 100% - La nouvelle consultation CEVT a levée un problème

de pagination lié à l’architecture existante, ce point
DDL V6 135% 100%
sera traité lors d’une réunion entre DSI /Accenture
Développements V6 104% 100% /IFS le jeudi 07/02. (QR VR17)
TADocumentation/Préparation 182% 100%
TAExecution/Correction 102% 96%
Recette fonctionnelle V6 48% 85%

Total V6 107% 98%

Budget :
Forecast end: Ratio E/B :
Périmètre propositions V6-P1 : 871 jh
Périmètre propositions V6-P2 : 139 jh 1101 jh 1,09
Evolutions V6 validées : 58,5 jh (1) Evaluation

Hors version traité en V6 : 12 jh (1) CF Budget évolutions annexé
Respect du calendrier :
Proposition validée : 871 jh +139 jh+70,5 jh évolutions =>1080,5 jh
Total V6 ouvert P1&P2 : 1010 jh

Indicateurs physiques
Respect des budgets :
Dépassement budgétaire sur

Périmètre 1 :
- Recette fonctionnelle terminées sur les 10 sujets la composant..
certains projets (développement et TA).
Périmètre 2 :
- 2 dossiers de SFDlivrés (DAJNANTI2 et UGMADH01)
- 1 dossier validé par Predica(DAJNANTI2)
- Matrices de tests et cycles de tests validés par PREDICA.

|32
 Infrastructure
Change
PMO
Design Build Test Roll-out

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

|33
 Infrastructure
Change
PMO
Design Build Test Roll-out

Outils – Le suivi des ressources (time reports)

|34
 Infrastructure
Change
PMO
Design Build Test Roll-out

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

|35
 Infrastructure
Change
PMO
Design Build Test Roll-out

La gestion des “change requests”

• Illustration d’un rapport de suivi de l’état d’avancement
Charge
Référence (coeff.
CdC mis à Référence note Date de
CdC livré par note de managemen
Fiche Q/R Thème jour par de validation livraison Statut
PDK proposition t et
Accenture PREDICA prévue
Accenture supports
inclus)
V6
Cloturée - Non retenue par
QR MOA-10 Ajout de cas sur CEVT Non Non CF Q/R N/A 9 N/A
PREDICA
Cloturée - Pas de changement de
Supprimer l'exclusion "décès suite à
QR MOA-21 Non Non CF Q/R N/A 4 N/A barème pour la recette
maladie"
fonctionnelle
DEVGBFIN - Possibilité de choisir parmi Cloturée - Non retenue par
QR MOA-22 Non Non CF Q/R N/A 15 N/A
2 options 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
Génération de plusieurs lignes de
QR MOA-11 messages pour un même actes de Non Non CF Q/R DSI/01.0847/JML 7 31/12/2001 Cloturée
gestion sur CEVT
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
MOCB/MBAC : délégation des fonction
QR SV6-11 Non Non CF Q/R DSI/02.0098/MJL 0,5 18/02/2002 Cloturée
MOCB en fonction du type bénéficiaire
Précisions au cdc initial suite aux
QR Projets FR09 Non Non CF Q/R DSI/02.0083/MJL 7 18/02/2002 Cloturée
modifications des courriers et des flux
QR PDK-01 Evolution BCIE - Indicateur Support UC Non Non CF Q/R CF FM 12 18/02/2002 Cloturée
Total V6 validé 70,5

|36
 Infrastructure
Change
PMO
Design Build Test Roll-out

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)

|37
 Infrastructure
Change
PMO
Design Build Test Roll-out

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)

|38
 Infrastructure
Change
PMO
Design Build Test Roll-out

L’importance du design
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

Source 40% - 60% 20% - 40% 10% - 20%

Besoins Design Programmation Tests Tests
des erreurs utilisateurs tech & funct Tests unitaires d’intégration d’acceptance Maintenance

On découvre que le
design a été mal fait
pendant les tests … Besoins Design Programmation Tests Tests
Maintenance
Découverte utilisateurs tech & funct Tests unitaires d’intégration d’acceptance

des erreurs
10% - 20% 20% - 50% 40% - 60%

|39
 Infrastructure
Change
PMO
Design Build Test Roll-out

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

|40
 Infrastructure
Change
PMO
Design Build Test Roll-out

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

|41
 Infrastructure
Change
PMO
Design Build Test Roll-out

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

|42
 Infrastructure
Change
PMO
Design Build Test Roll-out

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

|43
 Infrastructure
Change
PMO
Design Build Test Roll-out

Les activités de tests

Test planning/Test Management

Mise en place des environnements de tests

Définition de Préparation des

Plans de tests Exécution des tests
l’approche de tests tests

•Objectifs •Conditions de tests •Outils de tracking •Exécution des jeux de

•Périmètre •Cycles de tests d’erreurs tests
•Risques •Jeux de tests
•Ressources
•Besoins d’environnement
•Metrics
•Critères d’acceptation
•Points de référence
•Planning
|44
 Infrastructure
Change
PMO
Design Build Test Roll-out

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

|45
 Infrastructure
Change
PMO
Design Build Test Roll out

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

|46