Vous êtes sur la page 1sur 46

La gestion de projets

informatiques
Gestion des technologies de
linformation GEST310
Pascale Vande Velde

Agenda

Introduction
Structure dun projet
Gouvernance de projets
Les grandes phases dun projet dimplmentation

La conduite du changement
Le Program Management Office
Le release management
La conception
Le dveloppement
Les tests
Le roll out

|2

Introduction
Un projet a pour objectif de mener bien le dveloppement dune
nouvelle application ou ladaptation dune application existante
Un projet est caractris par :

Un primtre quels sont les besoins clients auxquels on doit rpondre


Un deadline le projet doit tre termin une date fixe
Des dlivrables les produits finis du projet
Un planning indiquant quand chaque produit fini sera livr et comment
les activits et donc la charge de travail sera rpartie dans le temps
Des ressources ddies 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 dun programme


Le macro planning montre ltalement des releases, la charge
hommes lie chaque release et les jalons principaux
(milestones) du programme

|5

Exemple de planning dtaill


Le planning reprend les activits principales, sous-activits,
dlivrables, la frquence des comits de pilotage
Phase I (in weeks)
Activities
Kick off

W0

W1

W2

W3

W4

W5

W6

W7

W8

W9

W10

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 Implmentation dun systme de


gestion de portefeuille dans une banque
prive
Release(1)
1 : alimentation du package par des donnes back offices

(titres, espces, comptes terme) et production dun rapport de


gestion clients
Release 2 : mise en place des fonctionnalits de gestion de
portefeuille (calculs de return, gestion des portefeuilles contre
stratgies et contraintes, benchmarking, passages dordres....), roll
out du package sur 50 utilisateurs rpartis sur 5 agences
Release 3 : enrichissement du flux dordres, roll out du package sur
200 utilisateurs rpartis dans 20 agences
Planning
Release 1 : juin 2003 aot 2004
Release 2 : septembre 2004 juillet 2005
Release 3 : juillet 2005 fin 2005

|7

Cas Implmentation dun systme de


gestion de portefeuille dans une banque
(2)chiffres
prive
Quelques

Nombre dutilisateurs : 250


Nombre de portefeuilles : 40,000
Actifs en gestion : 40 milliards EUR
Parts de march private banking NL : 30%
Cots release 1 10,5 MEUR

Cots licences : 1,5 MEUR


Cots implmentation : 7 MEUR (+/- 7,000 jours hommes, 35 personnes sur
un an)
Cots infrastructure : 2 MEUR

Cots release 2 8,5 MEUR

Cots de licence : 0,5 MEUR


Cots dimplmentation : 6 MEUR (+/- 6,000 jours hommes)
Cots infrastructure : 2 MEUR

Cots cumuls release 1 + 2 : 19 MEUR

|8

La structure dun projet


Un projet sera, si ncessaire, divis en sous projets

Chaque sous projet sera gr par un project manager


Les project managers rapporteront un program manager, en charge
de lensemble du projet
Le program manager rapportera ltat davancement 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 mtiers au projet

Le sponsor du projet est, en gnral, un directeur du mtier concern


Via un co management dun projet par lIT et le mtier concern
Via une participation partielle ou temps plein de reprsentants du
mtier dans le projet (dfinition des spcifications, validation des
prototypes, tests, validation des tests)

|9

Mois

Comit IT

Fixation et suivi de la stratgie et des plans


long terme

Dcisions cls sur les gros programmes et


les projets transversaux

Sponsorship & proprit des


projets/programmes

Suivi de ltat davancement du projet et


prise de dcision en matire de dlivrables,
primtres, problmes, ressources, etc

Responsable pour la livraison du


programme

Rapporte ltat davancement au comit de


pilotage

Gre les interdpendances entre projets

Sponsor
Mois

Hebdo &
journalier

Coordination
architecture
Support
fonctionnel et
technique

Journalier

Comit de
pilotage (*)
(*)
Program
Manager
PMO

Architecture

Journalier

Hebdomadaire

Project Manager

Project Manager

Project Manager

Dfinit les processus et outils ncessaires 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 dlivrables, le


planning, les risques et problmes au
program manager

Propal Dexia 040319|10

Cas Implmentation dun systme de


gestion de portefeuille dans une banque
prive (3)
Program manager

Architecture

Implmentation
Package

Change
Management

Interfaces banque

|11

Gouvernance de projet
Tout projet doit avoir un comit de pilotage appropri
Une structure claire de projet et de gouvernance est ncessaire :
Ralisation du projet avec succs
Participation de toutes les parties impliques
Dfinition claire des rles et responsabilits des personnes impliques
dans le projet et dans le comit de pilotage
Contrle et suivi troit du progrs du projet
Capacits mitiger les risques
Mcanismes clairs descalation des problmes

|12

Le rle des membres du comit de pilotage


Rle
Gardien de la vision et des objectifs du projet
Gre la communication sur le projet vis--vis de tiers
Suit le planning et les dlivrables, pas les processus

Responsabilits

Rgle les problmes organisationnels et de ressources


Gre lallocation des ressources et les dpendances entre projets
Est responsable de la communication au sein et en-dehors du projet
Valide les dlivrables
Gre le primtre et mitige les risques

Frquence de runion : 1x/mois

|13

Le rle du program manager


Rle

Gardien du planning du projet


Assure la gestion du projet au jour le jour
Gre le statut du projet
Escale temps et de manire approprie les problmes au comit de
pilotage

Responsabilits

Coordonne les parties et sassure de la ralisation du projet temps


Gre, planifie les ressources
Gre les aspects financiers du projet
Adhre aux best practices, mthodologies et outils de dveloppement
Gre le primtre et les risques

|14

Gouvernance du projet
Comit de pilotage

Dfinir les
objectifs

Rsoudre les
problmes
Grer le
primtre en
ligne avec
attentes mtiers

Valider les
objectifs

Program Mgmt

Dfinir le
primtre du
programme

Rsoudre/escaler
les problmes

Valider le
primtre du
programme
Project
Management

Grer le
primtre du
programme

Dfinir le
primtre du
projet
Valider le
primtre du
projet

Rsoudre/escaler
les problmes
Excution
du projet

Grer le
primtre du
projet

|15

Cas Implmentation dun systme de


gestion de portefeuille dans une banque
(4)
prive
Implmentation
dun outil de gestion de portefeuille dans une banque

prive, nayant pas dIT mais se reposant sur les systmes back office de
sa maison-mre (titres, espces, money markets, administration clients)
Les interdpendances avec les back offices sont trs fortes tant donn
la ncessit dinterfacer le PM package avec ces back offices pour
remonter les clients, portefeuilles, transactions journalirement
Les interdpendances avec le dpartement infrastructure de la maisonmre sont galement trs fortes; tant donn que linfrastructure du
package devra tre installe et gre par ce dpartement
Le comit de pilotage incluait

Le COO de la banque prive


Le Chief Investment Officer de la banque prive
Le directeur du dpartement infrastructure IT
Les responsables mtiers et IT de chaque back office

|16

Cas Implmentation dun systme de


gestion de portefeuille dans une banque
prive (5) Maison-mre
Banque Prive
Titres
Titres

Espces
Espces

PMS
PMS

Rapports
Rapports
clients
clients

Clients
Clients

Responsabilit des projets dextraction


Responsabilit des projets dextraction

Responsabilit
Responsabilitdu
duprojet
projet

|17

Les grandes phases dun projet


dimplmentation

Tout projet dimplmentation suit la mme squence dactivits


Comit de pilotage
Conduite du changement
PMO

Infrastructure
Demande

PROJECT

Design
fonctionnel et
technique

30-40%

Dveloppement
et tests
unitaires

20%

Tests
dintgration

20%

Tests
dacceptation

20%

Dploiement

0-10%

|18

Conduite du changement
Program Management Office

Gestion des ressources

Suivi du budget
Suivi du projet

Infrastructure
Design
Etablir le design fonctionnel de la solution
Etablir le design technique
Dfinir les lments dvelopper (formats, crans,.)
Dfinir lapproche de test et larchitecture technique
Dfinir le contenu des formations
Dfinir les nouveaux processus, limpact sur des processus existants
Mettre en place lenvironnement de dveloppement

Dvelopper les interfaces


Dvelopper lapplication
Effectuer du nettoyage de donnes
Effectuer les tests unitaires de linterface et de lapplication
Mettre en place les environnements de test

Implementation
et Roll Out

Test
Effectuer des tests dintgration
Effectuer les tests dacceptation
Mettre en place les environnements de
dacceptation

Les cas de tests


Les rsultats de tests
Validation des tests utilisateurs

Le plan de formations
Le plan de support post
implmentation

Organiser les trainings


Mettre en place lenvironnement de production
Effectuer un parallel run
Effectuer la migration
Assurer le suivi post mise en production

Deliverables

Tasks

Build/Unit test

Design fonctionnel
Design technique
Design des processus
Plans de tests/stratgie de tests
Design de larchitecture

Les programmes

|19

Change
Infrastructure
PMO
Design

Build

Test

Roll-out

La gestion des environnements

Plusieurs environnements sont ncessaires pour implmenter une nouvelle


application

Un
Un
Un
Un

ou
ou
ou
ou

plusieurs
plusieurs
plusieurs
plusieurs

environnements
environnements
environnements
environnements

de dveloppement
de test
dacceptation
de production

Chaque environnement supporte une version de lapplication (application, base de


donnes, interfaces..)
Plusieurs environnements peuvent se trouver sur la mme machine physique. En
pratique, pour des applications lourdes, une machine est utilise par
environnement
Linstallation dune machine prend du temps (+/- 2 mois) et doit donc tre bien
planifie. On commence dabord par installer la machine de dveloppement
La gestion des environnements de dveloppement et de tests est, en gnral,
effectue par le projet
La gestion des environnements dacceptation et de production est, en gnrale,
effectue par le dpartement qui hostera les machines en production

|20

Change
Infrastructure
PMO
Design

Build

Test

La gestion des environnements


Projet

Production

TEST

DEV

Migration dun
package de
dveloppement

UAT

Migration dun
package de
dveloppement

PROD

Migration dun
package de
dveloppement

Matre pour les


dveloppements

Correction dun bug

|21

Roll-out

Infrastructure
Change
PMO
Design

Build

Test

Roll-out

La conduite du changement
Les facteurs dchec :
Un manque de communication ou une communication inapproprie
Un manque dimplication du client dans le projet. Le projet est ralis
par lIT ou par une partie externe
Manque de support du management pour lutilisation du systme
Mismatch au niveau des attentes utilisateurs
Lorganisation nest pas prte/revue pour la mise en production de
lapplication
Les rles, les comptences des utilisateurs ne sont pas adapts la
nouvelle manire de fonctionner
Manque de prise de conscience des avantages du nouveau systme
Trop peu de formations ou des formations inappropries

|22

Infrastructure
Change
PMO
Design

Build

Test

Roll-out

Passif

Actif

La conduite du changement dune attitude


ngative
Efforts pour
regagner le
contrle de la
situation

Immobilisation
crainte, confusion

Bargaining

Minimise limpact du
changement

Rejet raction
dfensive face une
situation
inacceptable

Acceptation du
changement, ralisme

Test, essaye de
nouvelles choses
Dpression frustration, sentiment dchec

Source: Kuebler-Ross, 1969: Conner, 1992

Changement ngatif

Temps

Changement positif

|23

Infrastructure
Change
PMO
Design

Build

Test

Roll-out

Niveau dacceptation du changement

La conduite du changement une


attitude positive
Proprit/Buy in
Acceptation

Comment puis-je convaincre


dautres de changer ?
Comment cela impacte-t-il mon
travail journalier ?

Frontire de lengagement

Test
Comprhension

Semble bien sur papier, mais nous


changeons tout le temps. Quand puis-je
lessayer ?

Quest-ce que cette nouvelle organisation


signifie pour moi ??
Contact
Pourquoi remplace-t-on un bon systme ?
De quoi sagit-il ?
Prise de conscience

Rsistance

Acceptation/Proprit

|24

Temps

Infrastructure
Change
PMO
Design

Build

Test

Roll-out

Niveau dacceptation du changement

La conduite du changement les moyens


mettre en oeuvre

Proprit/Buy in

Acceptation

Frontire de lengagement

Test

Implmenter des formations centres sur lutilisation


long terme du systme
Communiquer les rsultats du changement
Revoir les bonus, etc en fonction des changements

Dvelopper un plan daction pour lever les barrires


Communiquer le planning dimplmentation
Mener des formation sur les nouveaux concepts,

Communiquer chacun quelles opportunits le projet lui


offre
Utiliser les sponsors du projet pour rduire la rsistance

Comprhension
Contact

Prise de conscience

Communiquer chancun limpact du changement


Utiliser les sponsors et des agents de changement pour dlivrer
des messages,

Temps

Rsistance

Acceptation/Proprit

|25

Infrastructure
Change
PMO
Build

Design

Test

Les activits dun PMO


12.
12.
Communication
Communication
11.
11.
Coordination
Coordination du
du
changement
changement

Rapporte
ltat
davancement

10.
10. Coordination
Coordination
avec
avec Architecture
Architecture

2.
2. Gre
Gre le
le
primtre
primtre

Suivi du
primtre

3.
3. Gre
Gre les
les
risques
risques

Identifie les
risques
Follow-up sur
base de critres
de qualit

1.
1. Programme
Programme
tracking
tracking &
&
reporting
reporting

9. Quality
management
management

8.
8. Gestion
Gestion des
des
contrats
contrats

Planning dfinit le
contenu des
releases

7.
7. Coordination
Coordination
avec
avec les
les achats
achats

Fournit les
donnes pour les
budgets et calcul
des cots
Suivi de
lallocation des
ressources

4.
4. Gestion
Gestion
financire
financire et
et
business
business case
case

5.
5. Gestion
Gestion des
des
ressources
ressources

6.
6. Gestion des
des
releases
releases

|26

Roll-out

Infrastructure
Change
PMO
Design

Build

Test

Roll-out

Les processus grs par le PMO


Processus de
Program management

Besoins

Gestion du budget

Monitoring du taux dactivit sur base du planning et du plan de staffing

Change control

Contrle strict sur les augmentations, rductions de primtre, avec valuation par rapport au business case, au planning et aux cots.
Ces points doivent tre escals au Comit de Pilotage

Dlivrables/milestones/
Dependency management

Un mcanisme de tracking doit tre suivi par tous les project managers

Problmes

Une des priorits des project managers est de rsoudre les problmes

Runions de projets

Les runions sont focalises sur ltat davancement (par rapport au budget, au planning, aux dlivrables), les problmes et le change
control

Qualit

Des revues de qualit sont organises afin de vrifier que le projet est gr selon de bonnes rgles de gestion de projet

Gestion des ressources

Besoin danticiper les besoins en ressources et allocation au bon moment aux diffrents sous projets

Risques

Les risques doivent tre bien documents et escals systmatiquement au comit de pilotage

Suivi du temps pass

Tout membre du projet doit rapporter son temps avec un niveau de dtail suffisant que pour assurer un bon contle financier du projet

Gestion du planning

Utilisation dun outil de planning commun pour tous les sous projets. Les planning sont grs par chaque sous projet.
Tous les plannings alimentent un programme commun utilis pour le suivi budgtaire

|27

Infrastructure
Change
PMO
Design

Build

Test

Roll-out

Lestimation de leffort
Lestimation de leffort est une activit itrative. Plus lincertitude
diminue, meilleure est lestimation
Facteurs

Base

Spcifications fonctionnelles

Nombre de fonctions business


impactes

Complexit mtier

# employs et utilisateurs
Degr de changement des processus
Qualit des donnes mainframe

Software Fit

Nombre de modifications
attendues/extensions

Existence dun environnement


technique appropri

Exprience avec les changements


passs
Processus de prise de dcision
Sponsoring du projet
Rsistance au changement

# interfaces & conversions


Complexit de l integration
Approche de conversion

Technical Fit

Capacit de la socit
accepter le changement

Intgration et effort de
conversion

|28

Infrastructure
Change
PMO
Design

Build

Test

Roll-out

Lestimation de leffort
Activit

Conception du modle opratoire


Conception des processus mtiers
Configuration de lapplication &
Prototype avec utilisateurs
Spcifications fonctionnelles
Dveloppement & Test
Equipe de support technique
Communication et Formation
Plan et excution de tests systmes

Base destimation

# de pratiques mtiers
# de conversions
(manuel / auto)
Estimation dimplmentation

# dinterfaces entrantes
# dinterfaces sortantes

Processus
destimation
itratif

# de rapports
# de modules

Approche bottom -up


Charge de travail/ tat du projet
Bas sur des benchmarks, points de
rfrences

Taille approx de lquipe

Planning de roll-out et excution


Gestion du projet

Dure du projet

|29

Infrastructure
Change
PMO
Design

Build

Test

Cas Implmentation dun systme de


gestion de portefeuille dans une banque
prive (6)
Estimation de la charge de travail par partie
Exemple de monte en charge

|30

Roll-out

Infrastructure
Change
PMO
Design

Build

Test

Outils - Le suivi financier de projets


Il est important de pouvoir suivre le cot du projet par rapport
un budget initial (baseline) et de justifier les carts

|31

Roll-out

Infrastructure
Change
PMO
Design

Build

Test

Roll-out

Outils - Les rapports davancement


Rapporter de manire synthtique ltat davancement, les
risques, les problmes....Identification des dlivrables cls raliss.
V6 - AVANCEMENT
Statut du Projet au 31/01/2002

Consomm %

Gagn %

Pilotage V6
DDL V6
Dveloppements V6
TA Documentation/Prparation
TA Execution/Correction
Recette fonctionnelle V6

116%
135%
104%
182%
102%
48%

100%
100%
100%
100%
96%
85%

Total V6

107%

98%

Budget :
Primtre propositions V6-P1 : 871 jh
Primtre propositions V6-P2 : 139 jh
Evolutions V6 valides : 58,5 jh (1)
Hors version trait en V6 : 12 jh

Forecast end :

Ratio E/ B :

1101 jh

1,09

(1) CF Budget volutions annex

Proposition valide : 871 jh +139 jh +70,5 jh volutions =>1080,5 jh


Total V6 ouvert P1&P2 : 1010 jh
Primtre 1 :
-

Indicateurs physiques

Recette fonctionnelle termines sur les 10 sujets la composant..

Risques identifis
- La nouvelle consultation CEVT a leve un problme
de pagination li larchitecture existante, ce point
sera trait lors dune runion entre DSI / A ccenture
/ IFS le jeudi 07/ 02. (QR VR17)

Evaluation
Respect du calendrier :

Respect des budgets :


Dpassement budgtairesur
certains projets (dveloppement et TA).

Primtre 2 :
-

2 dossiers de SFD livrs (DAJNANTI2 et UGMADH01)

1 dossier valid par Predica (DAJNANTI2)

Matrices de tests et cycles de tests valids 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 dheures passes sur le
projet; ce cot tant le principal cot dun projet dimplmentation
Chacun rapporte ses heures consommes dans un time report
Ceci est utilis pour le suivi financier du projet, la facturation du
projet et ventuellement, le paiement dheures supplmentaires

|33

Infrastructure
Change
PMO
Design

Build

Test

Outils Le suivi des ressources (time


reports)

|34

Roll-out

Infrastructure
Change
PMO
Design

Build

Test

Roll-out

La gestion des change requests


Le primtre est fix avant le dmarrage du projet dans une phase
de prparation, cadrage du projet
Il est frquent que, de nouveaux besoins soient exprims en cours
de projet.
Ceux-ci influencent la charge de travail totale du projet et peuvent
mettre la date de livraison en pril. Do limportance pour un
program manager de :
Bien qualifier chaque change request (un change request trop lourd
doit tre repouss dans une release ultrieure)
Suivre de manire spcifique les change requests (tat davancement,
charge de travail)
Faire valider linclusion de change requests dans le primtre du projet
par le comit de pilotage

|35

Infrastructure
Change
PMO
Design

Build

Test

La gestion des change requests


Illustration dun rapport de suivi de ltat davancement
Fiche Q/R

Thme

CdC livr par


PDK

Charge
Rfrence
(coeff.
CdC mis
Rfrence note
note de
managemen
jour par
de validation
proposition
t et
Accenture
PREDICA
Accenture
supports
inclus)

Date de
livraison
prvue

Statut

V6
QR MOA-10

Ajout de cas sur CEVT

Non

Non

CF Q/R

N/A

QR MOA-21

Supprimer l'exclusion "dcs suite


maladie"

Non

Non

CF Q/R

N/A

Non

CF Q/R

N/A

15

Non

CF Q/R

DSI/01.0846/JML

Cloture - Non retenue par


PREDICA
Cloture - Pas de changement de
N/A
barme pour la recette
fonctionnelle
Cloture - Non retenue par
N/A
PREDICA
31/12/2001 Cloture

Non

CF Q/R

DSI/01.0847/JML

31/12/2001 Cloture

QR MOA-12

DEVGBFIN - Possibilit de choisir parmi


Non
2 options
Modification de libells sur CEVT
Non
Gnration de plusieurs lignes de
messages pour un mme actes de
Non
gestion sur CEVT
Interdiction des VEEX classique sur 3 en 1Non

QR MOA-14

Ajout de dtail sur vnement MORI

QR MOA-22
QR MOA-09
QR MOA-11

N/A

Non

CF Q/R

DSI/01.0905/MJL

31/12/2001 Cloture

Non

Non

CF Q/R

DSI/01.0931/MJL

31/12/2001 Cloture

QR Projets FR-20 Livraison MCD pacte adjoint

Non

Non

CF Q/R

DSI/01.0973/MJL

10

18/02/2002 Cloture

QR Projets FR-22 DAJDCVIR problme objets communs

Non

Non

CF Q/R

DSI/01.1042/MJL

18/02/2002 Cloture

QR Projets SV610 Reprise du montant minimum disponible Non


MOCB/MBAC : dlgation des fonction
QR SV6-11
Non
MOCB en fonction du type bnficiaire
Prcisions au cdc initial suite aux
QR Projets FR09
Non
modifications des courriers et des flux

Non

CF Q/R

DSI/02.0074/MJL

14

18/02/2002 Cloture

Non

CF Q/R

DSI/02.0098/MJL

0,5

18/02/2002 Cloture

Non

CF Q/R

DSI/02.0083/MJL

18/02/2002 Cloture

QR PDK-01

Non

CF Q/R

CF FM

12

18/02/2002 Cloture

Total V6 valid

Evolution BCIE - Indicateur Support UC

Non

70,5

|36

Roll-out

Infrastructure
Change
PMO
Design

Build

Test

Roll-out

Le design (spcifications)

Les spcifications dtaillent les besoins mtiers un niveau suffisament dtaill que
pour tre non interprtables pour le dveloppement de ces spcifications
Les spcifications dtaillent les besoins mtiers par rapport au systme-cible

Les spcifications doivent tre formellement valides par le responsable du projet


mtiers
Exemple de spcifications fonctionnelles pour des passages dordres

Sur base dune maquette


Sur base dun prototype
Sur base dune description dtaille

Ecrans de passage dordres


Listes dordres
Mcanismes de validation des ordres
Le flux des ordres
Le calcul estimatif des frais de transactions

Exemple de spcifications techniques

Format des messages


Mode de transmission des messages (synchrone, asynchrone)

|37

Infrastructure
Change
PMO
Design

Build

Test

Roll-out

Cas Implmentation dun systme de


gestion de portefeuille dans une banque
prive (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

Limportance du design
Un mauvais design va gnrer beaucoup de travail en dveloppement (re coding) aprs
les tests et accrotre les cots de dveloppement du projet

Source
des erreurs
On dcouvre que le
design a t mal fait
pendant les tests
Dcouverte
des erreurs

40% - 60%
Besoins
utilisateurs

Besoins
utilisateurs

Design
tech & funct

Design
tech & funct

10% - 20%

20% - 40%
Programmation
Tests unitaires

Programmation
Tests unitaires

10% - 20%

Tests
Tests
dintgration dacceptance

Maintenance

Tests
Tests
dintgration dacceptance

20% - 50%

Maintenance

40% - 60%

|39

Infrastructure
Change
PMO
Design

Build

Test

Roll-out

Le prototypage
Mthode itrative pour spcifier et dvelopper
Applicable principalement pour des packages
Sur base dune premire collecte des besoins, un prototype est
dvelopp et pass en revue avec les utilisateurs
Prrequis

Une bonne anticipation des besoins mtiers (expertise)


Des utilisateurs raisonnables le prototype doit permettre de valider les
spcifications et non pas introduire une longue liste de modifications

Avantages

Collecter les demandes de modifications pendant le design et non pendant


le testing
Dveloppement en parallle avec les spcifications
Cadrer les spcifications viter le syndrme de la page blanche (viter
des dveloppements lourds sur des packages). Utiliser des configurations
prdfinies

|40

Infrastructure
Change
PMO
Design

Test

Build

Le dveloppement
Se baser sur des configurations existantes (packages)
Centraliser les configurations dans un fichier
Rinitialisation des dveloppements
Baseline management retour une version prcdente ais
Versioning ais
Version : tat du dveloppement
Conservation des versions prcdentes

Documentation des dveloppements

|41

Roll-out

Infrastructure
Change
PMO
Design

Test

Build

Cas Implmentation dun systme de


gestion de portefeuille dans une banque
prive (8)
Exemple dun fichier de dveloppement
Exemple dun inventaire de dveloppement

|42

Roll-out

Infrastructure
Change
PMO
Design

Build

Test

Les tests

Lobjectif de la phase de test est de valider que les spcifications ont


correctement t implmentes
Phases de test principales

Tests unitaires

Tests raliss par le dveloppeur


Tests de chaque lment de dveloppement

Tests systmes

Tests raliss par le dveloppeur


Tests de compatibilit de blocs de dveloppement dans un mme environnement

Tests dintgration

Tests raliss par une quipe de test projet


Droulement de jeux de tests fonctionnels

Tests dacceptation

Tests raliss par les utilisateurs


Droulement, une seconde fois, des jeux de tests fonctionnels

Validation formelle par le responsable du projet de la mise en production

|43

Roll-out

Infrastructure
Change
PMO
Design

Build

Test

Roll-out

Les activits de tests


Test planning/Test Management

Mise en place des environnements de tests

Dfinition de
lapproche de tests
Objectifs
Primtre
Risques
Ressources
Besoins denvironnement
Metrics
Critres dacceptation
Points de rfrence
Planning

Plans de tests

Conditions de tests
Cycles de tests

Prparation des
tests
Outils de tracking
derreurs
Jeux de tests

Excution des tests

Excution des jeux de


tests

|44

Infrastructure
Change
PMO
Design

Build

Test

Cas Implmentation dun systme de


gestion de portefeuille dans une banque
prive (8)

Primtre
Critres dacceptation
Points de rfrence
Tracking sheet

|45

Roll-out

Infrastructure
Change
PMO
Design

Test

Build

Roll out

Le roll out
Le roll out est la mise en production dune release. Il est conditionn
lapprobation du mtier (sur base des tests dacceptation)
Le roll out doit tre accompagn
Dun plan de formation des utilisateurs
Dun accompagnement de lquipe projet pendant les premiers mois de
mise en production
Rsolution des problmes
Accompagnement utilisateurs

On peut galement avoir un parallel run avant une mise en


production effective. Les utilisateurs utilisent deux systmes en
parallle (lancien et le nouveau). Ils effectuent toutes leurs actions
quotidiennes sur le systme. Une fois que le parallel run est valid par
les utilisateurs, lapplication peut tre mise en production

Procdure lourde (production like)


Allonge la priode de test mais rduit le risque de problmes en production

|46