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
2003 Q1 Q2 Q3 Q4 j f m a m j j a s o n d 2004 Q1 Q2 Q3 Q4 j f m a m j j a s o n d 2005 Q1 Q2 Q3 Q4 j f m a m j j a s o n d

Activities 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 Duration in months Major Milestones

85 2

7 1

120 2

2212 MD + 1142 MD extract 10

608 4

1663 MD

200 4

10

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 dtaill

Le planning reprend les activits principales, sous-activits, dlivrables, la frquence des comits de pilotage
Phase I (in weeks) Activities 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 W0 W1 W2 W3 W4 W5 W6 W7 W8 W9 W10

Workshop Kick off meeting Steering committee Deliverable / major milestone

|6

Cas Implmentation dun systme de gestion de portefeuille dans une banque prive (1)

Release 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 prive (2)
Quelques chiffres
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 release 2 8,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 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 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)

La participation des mtiers au projet

|9

Fixation et suivi de la stratgie et des plans long terme Dcisions cls sur les gros programmes et les projets transversaux

Mois

Comit IT

Sponsorship & proprit des projets/programmes

Sponsor
Mois

Comit de pilotage (*)

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

Hebdo & journalier

Program Manager PMO

Journalier

Coordination architecture Support fonctionnel et technique

Architecture Hebdomadaire

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

Journalier

Project Manager

Project Manager

Project Manager

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

Responsabilits

|14

Gouvernance du projet
Comit de pilotage

Dfinir les objectifs

Rsoudre les problmes Grer le primtre en ligne avec attentes mtiers Rsoudre/escaler les problmes

Valider les objectifs

Program Mgmt

Dfinir le primtre du programme Valider le primtre du programme

Grer le primtre du programme Rsoudre/escaler les problmes

Project Management

Dfinir le primtre du projet Valider le primtre du projet Excution du projet

Grer le primtre du projet |15

Cas Implmentation dun systme de gestion de portefeuille dans une banque prive (4)
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
Titres PMS

Banque Prive

Espces

Rapports clients

Clients

Responsabilit des projets dextraction

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

Dveloppement et tests unitaires

Tests dintgration

Tests dacceptation

Dploiement

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
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 Design fonctionnel Design technique Design des processus Plans de tests/stratgie de tests Design de larchitecture

Build/Unit test
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

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

Implementation et Roll Out

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

Tasks

Deliverables

Les programmes

Les cas de tests Les rsultats de tests Validation des tests utilisateurs

Le plan de formations Le plan de support post implmentation

|19

Change Infrastructure PMO

Design Build Test
Roll-out

La gestion des environnements

Plusieurs environnements sont ncessaires pour implmenter une nouvelle application
Un ou Un ou Un ou Un ou plusieurs environnements de dveloppement plusieurs environnements de test plusieurs environnements dacceptation plusieurs environnements 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
Roll-out

La gestion des environnements

Projet Production

DEV

TEST

UAT

PROD

Migration dun package de dveloppement

Matre pour les dveloppements

Migration dun package de dveloppement

Migration dun package de dveloppement

Correction dun bug |21

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

La conduite du changement dune attitude ngative

Efforts pour regagner le contrle de la situation
Actif

Bargaining

Minimise limpact du changement

Acceptation du changement, ralisme

Immobilisation crainte, confusion

Rejet raction dfensive face une situation inacceptable

Test, essaye de nouvelles choses

Dpression frustration, sentiment dchec

Source: Kuebler-Ross, 1969: Conner, 1992

Temps

Changement ngatif

Changement positif
|23

Infrastructure Change PMO

Design Build Test Roll-out

La conduite du changement une attitude positive

Niveau dacceptation du changement Comment puis-je convaincre dautres de changer ? Comment cela impacte-t-il mon travail journalier ? Semble bien sur papier, mais nous changeons tout le temps. Quand puis-je lessayer ?

Proprit/Buy in

Acceptation
Frontire de lengagement

Test

Comprhension 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

La conduite du changement les moyens mettre en oeuvre

Niveau dacceptation du changement
Implmenter des formations centres sur lutilisation long terme du systme Communiquer les rsultats du changement Revoir les bonus, etc en fonction des changements

Proprit/Buy in

Acceptation
Frontire de lengagement

Dvelopper un plan daction pour lever les barrires Communiquer le planning dimplmentation Mener des formation sur les nouveaux concepts,

Test

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

Design Build Test Roll-out

Les activits dun PMO

12. Communication 11. Coordination du changement 2. Gre le primtre

Rapporte ltat davancement

Suivi du primtre

3. Gre les risques

10. Coordination avec Architecture

Follow-up sur base de critres de qualit

Identifie les risques

1. Programme tracking & reporting

9. Quality management
Planning dfinit le contenu des releases

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

4. Gestion financire et business case

8. Gestion des contrats

5. Gestion des ressources

7. Coordination avec les achats

6. Gestion des releases

|26

Infrastructure Change PMO

Design Build Test Roll-out

Les processus grs par le PMO

Processus de Program management Gestion du budget Change control Dlivrables/milestones/ Dependency management Problmes Runions de projets Qualit Gestion des ressources Risques Suivi du temps pass Gestion du planning Besoins
Monitoring du taux dactivit sur base du planning et du plan de staffing 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 Un mcanisme de tracking doit tre suivi par tous les project managers

Une des priorits des project managers est de rsoudre les problmes Les runions sont focalises sur ltat davancement (par rapport au budget, au planning, aux dlivrables), les problmes et le change control

Des revues de qualit sont organises afin de vrifier que le projet est gr selon de bonnes rgles de gestion de projet Besoin danticiper les besoins en ressources et allocation au bon moment aux diffrents sous projets Les risques doivent tre bien documents et escals systmatiquement au comit de pilotage Tout membre du projet doit rapporter son temps avec un niveau de dtail suffisant que pour assurer un bon contle financier du projet

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

Facteurs
Spcifications fonctionnelles Complexit mtier

Base
Nombre de fonctions business impactes # employs et utilisateurs Degr de changement des processus Qualit des donnes mainframe 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

+
20-25% 15-20% 10-15%

Software Fit

Technical Fit Capacit de la socit accepter le changement

Project Phases...
Initial Assessment Conceptual Design Global Design and Prototype Build and Rollout

Intgration et effort de conversion

|28

Infrastructure Change PMO

Design Build Test Roll-out

Lestimation de leffort
Activit Base destimation

Conception du modle opratoire Conception des processus mtiers Configuration de lapplication & Prototype avec utilisateurs Spcifications fonctionnelles

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

Estimation dimplmentation

# dinterfaces entrantes # dinterfaces sortantes Dveloppement & Test Equipe de support technique Communication et Formation Plan et excution de tests systmes Planning de roll-out et excution Gestion du projet Dure du projet

Processus destimation itratif

Approche bottom -up Charge de travail/ tat du projet Bas sur des benchmarks, points de rfrences

# de rapports
# de modules Taille approx de lquipe

|29

Infrastructure Change PMO

Design Build Test Roll-out

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

Infrastructure Change PMO

Design Build Test Roll-out

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

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
Pilotage V6 DDL V6 Dveloppements V6 TA Documentation/Prparation TA Execution/Correction Recette fonctionnelle V6 Consomm % 116% 135% 104% 182% 102% 48% 107% Forecast end : 1101 jh Gagn % 100% 100% 100% 100% 96% 85% 98% Ratio E/B : 1,09
2

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

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

(1) CF Budget volutions annex

Evaluation Respect du calendrier :

Proposition valide : 871 jh +139 jh + 70,5 jh volutions => 1080,5 jh Total V6 ouvert P1&P2 : 1010 jh
Primtre 1 : 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.

Indicateurs physiques

Recette fonctionnelle termines sur les 10 sujets la composant..

Respect des budgets : Dpassement budgtaire sur certains projets (dveloppement et TA).

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

Outils Le suivi des ressources (time reports)

|34

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

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) Non Non Non Non Non Non Non Non Non Non Non Non Non CF Q/R CF Q/R CF Q/R CF Q/R CF Q/R CF Q/R CF Q/R CF Q/R CF Q/R CF Q/R CF Q/R CF Q/R CF Q/R N/A N/A N/A DSI/01.0846/JML DSI/01.0847/JML DSI/01.0905/MJL DSI/01.0931/MJL DSI/01.0973/MJL DSI/01.1042/MJL DSI/02.0074/MJL DSI/02.0098/MJL DSI/02.0083/MJL CF FM 9 4 15 8 7 4 6 10 2 14 0,5 7 12 70,5 Date de livraison prvue Statut

V6 QR MOA-10 QR MOA-21 QR MOA-22 QR MOA-09 QR MOA-11 QR MOA-12 QR MOA-14 Ajout de cas sur CEVT Supprimer l'exclusion "dcs suite maladie" Non Non 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 N/A 31/12/2001 Cloture 31/12/2001 Cloture 31/12/2001 Cloture 18/02/2002 Cloture 18/02/2002 Cloture 18/02/2002 Cloture 18/02/2002 Cloture 18/02/2002 Cloture 18/02/2002 Cloture

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 1 Non Ajout de dtail sur vnement MORI Non Non Non

QR Projets FR-20 Livraison MCD pacte adjoint QR Projets FR-22 DAJDCVIR problme objets communs

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 QR PDK-01 Total V6 valid Evolution BCIE - Indicateur Support UC Non

|36

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
Sur base dune maquette Sur base dun prototype Sur base dune description dtaille

Les spcifications doivent tre formellement valides par le responsable du projet mtiers Exemple de spcifications fonctionnelles pour des passages dordres
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 Design tech & funct

20% - 40%
Programmation Tests unitaires

10% - 20%
Maintenance

Tests Tests dintgration dacceptance

Besoins utilisateurs

Design tech & funct

Programmation Tests unitaires

Tests Tests dintgration dacceptance

Maintenance

10% - 20%

20% - 50%

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 Build Test Roll-out

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

Infrastructure Change PMO

Design Build Test Roll-out

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

|42

Infrastructure Change PMO

Design Build Test Roll-out

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 raliss par le dveloppeur Tests de compatibilit de blocs de dveloppement dans un mme environnement Tests raliss par une quipe de test projet Droulement de jeux de tests fonctionnels Tests raliss par les utilisateurs Droulement, une seconde fois, des jeux de tests fonctionnels

Tests systmes

Tests dintgration

Tests dacceptation

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

|43

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

Prparation des tests

Outils de tracking derreurs Jeux de tests

Excution des tests

Conditions de tests Cycles de tests

Excution des jeux de tests

|44

Infrastructure Change PMO

Design Build Test Roll-out

Cas Implmentation dun systme de gestion de portefeuille dans une banque prive (8)
Primtre Critres dacceptation Points de rfrence Tracking sheet

|45

Infrastructure Change PMO

Design Build Test 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