SlideShare une entreprise Scribd logo
Méthodologie Projet
Benjamin ACHAB
Mars 2017
•Les phases du projet
•Structure d’un projet
•Gouvernance de projets
•Les phases du projet
– Le release management
– La conception
– Le développement
– Les tests
– Le roll out
Vue d’ensemble
Réunion de Lancement
Installation
Formation découverte
Formation administrateur
Analyse générale
- fonctionnelle
- reprise de
données
- Interface
Développement
Formation key users
Transfert au Support
et Service client
Etude d’adéquation
Initialisation Analyse Conception ExploitationMise en production
Assistance au démarrage
Reprise de données
définitives
Analyse des écarts
ParamétrageReprise de données test
Tests et validation du pilote
Formation end users
Vérification GO / NO GO
Réalisation
Tests unitaires
Codification et Paramétrage de base
Gestion de projetPQP Validation S1 Validation S2
Recette définitive
• Un projet a pour objectif de mener à bien le développement d’une
nouvelle application ou l’adaptation d’une application existante
• Un projet est caractérisé par :
– Un périmètre – quels sont les besoins clients auxquels on doit répondre
– Un deadline – le projet doit être terminé à une date fixe
– Des délivrables – les produits finis du projet
– Un planning indiquant quand chaque produit fini sera livré et comment les activités et donc la charge de travail sera
répartie dans le temps
– Des ressources dédiées partiellement ou totalement au projet
– Une structure de gouvernance
5
 La phase d’analyse permettra de valider les points non encore détaillés du projet.
 Elle sera réalisée à partir des processus cibles communiqués par le client dans son cahier des
charges, complétés par les interviews des pilotes
 Le livrable Rapport d’adéquation définira les écarts entre le fonctionnement standard de la
solution logicielle et le système cible en proposant différentes solutions (développement,
modification d’organisation) pour le traitement de ces écarts
 La validation du livrable issue de cette étape est une condition nécessaire pour la poursuite du
projet et permet de définir l’ensemble du système d’information cible à réaliser durant le projet
 Il s’agit d’une réalisation d’analyse globale du périmètre projet, quel que soit ensuite le
découpage de la mise en œuvre. Ceci afin de bien appréhender l’ensemble de la problématique
avant de réaliser le paramétrage
La phase d’analyse
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)
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
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
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
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
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
Le roll out
• Le roll out est la mise en production d’une release. Il est conditionné à
l’approbation du métier (sur base des tests d’acceptation)
• Le roll out doit être accompagné
– D’un plan de formation des utilisateurs
– D’un accompagnement de l’équipe projet pendant les premiers mois de mise en production
• Résolution des problèmes
• Accompagnement utilisateurs
• On peut également avoir un “parallel run” avant une mise en production
effective. Les utilisateurs utilisent deux systèmes en parallèle (l’ancien et le
nouveau). Ils effectuent toutes leurs actions quotidiennes sur le système. Une
fois que le parallel run est validé par les utilisateurs, l’application peut être
mise en production
– Procédure lourde (production like)
– Allonge la période de test mais réduit le risque de problèmes en production
13
La phase de conception
 La phase de conception permettra de valider les points non encore détaillés du projet.
 La complexité de cette phase est liée au nombre d’écarts qui pourraient être identifiés suite à la phase d’analyse
générale
 Tout écart est détaillé dans une fiche d’écart qui permettra d’évaluer la charge afférente et sa réalisation.
 Aucun développement n’est effectué sans Fiche d’écart validé par le Client.
13
14
La phase de conception
14
Identifier les éléments non standards et de valider le périmètre et le budget afférent :
Fonctions non standard
Interfaces
Rapports
Reprise de données
La complexité de cette phase est liée au nombre d’écarts qui pourraient être identifiés suite à la phase
d’analyse générale
La démarche de conception se veut au plus proche de la solution standard
Qualification des besoins indispensables / cosmétiques
Cette phase sera également utilisée pour préparer la recette fonctionnelle
Identification des scénarios Métier
Construction des cas de tests
Collecte des jeux de données
15
La phase de mise en production
La phase de mise en production acte du passage en exploitation la solution dans l’environnement de
production
La formation des utilisateurs finaux est effectuée à priori par l’équipe des pilotes client qui auront
préalablement rédigés les manuels utilisateurs.
Le décision du démarrage est validée par le comité de pilotage suite à la simulation en charge qui recrée
les conditions d’exploitation du démarrage.
La prestation de démarrage est systématiquement réalisée en fonction de la demande du client. Son
contenu et sa durée sont donc confirmés juste avant le go-live.
16
La phase de réalisation
La phase de réalisation permettra de de paramétrer la solution et de réaliser les écarts exprimés en conception afin de
conduire à la validation du pilote.
 Elle nécessite une participation active de l’équipe projet du client
 Elle se caractérise par un transfert de compétence très fort entre les équipes de l’intégrateur et celle du client
 Elle intègre la réalisation des prestations liées à l’ingénierie qui sont menées en parallèle du paramétrage
 Elle se conclue par la présentation du prototype par l’équipe interne du client
16
17
Vue d’ensemble
Réunion de Lancement
Installation
Formation découverte
Formation administrateur
Analyse générale
- fonctionnelle
- reprise de
données
- Interface
Développement
Formation key users
Transfert au Support
et Service client
Etude d’adéquation
Initialisation Analyse Conception ExploitationMise en production
Assistance au démarrage
Reprise de données
définitives
Analyse des écarts
ParamétrageReprise de données test
Tests et validation du pilote
Formation end users
Vérification GO / NO GO
Réalisation
Tests unitaires
Codification et Paramétrage de base
Gestion de projetPQP Validation S1 Validation S2
Recette définitive
17
18
Livrables
Planning,
Plan Qualité Projet,
Compte rendu Réunion de
lancement,
Fiches d’écart,
Modèle Fichiers de reprise de
données
PV Reprise test, PV de recette
fonctionnelle
Dossier de paramétrage
PV de reprise de données
définitives,
Kit de déploiement
Rapport d’adéquation,
Tableau des écarts
PV de recette définitif
Procédure de support
Vue d’ensemble : LIVRABLES CLES
Initialisation Analyse Conception ExploitationMise en productionRéalisation
18
19
Livrables
Planning,
Plan Qualité Projet,
Compte rendu Réunion de
lancement,
Fiches d’écart,
Modèle Fichiers de reprise de
données
PV Reprise test, PV de recette
fonctionnelle
Dossier de paramétrage
PV de reprise de données
définitives,
Kit de déploiement
Rapport d’adéquation,
Tableau des écarts
PV de recette définitif
Procédure de support
Vue d’ensemble : LIVRABLES CLES
Initialisation Analyse Conception ExploitationMise en productionRéalisation
19
Exemple de planning d’un programme
• Le macro planning montre l’étalement des releases, la charge hommes
liée à chaque release et les jalons principaux (milestones) du
programme
j f m a m j j a s o n d j f m a m j j a s o n d j f m a m j j a s o n d
Req's Performance Reporting
Visie Triple'A
Project Initiation Study
Release 1 - Client reporting
Release 1 - Branch Rollout
Release 2 - Order Entry
Release 3 - Performance attribution & GIPS
Total estimated effort in mandays 7
Duration in months 1
Major Milestones First Performance report sent to PCNL clients
AAA WUI available in branches
portfolio analysis supported by order entry and compliance checking
Client portfolio monitoring & performance attribution available
200
44
1663 MD
10
608
2 2
2212 MD + 1142 MD extract
10
85 120
Q3 Q4Q1 Q2Q3 Q4
Activities
2003 2004 2005
Q1 Q2 Q3 Q4 Q1 Q2
Exemple de planning détaillé
• Le planning reprend les activités principales, sous-activités, délivrables,
la fréquence des comités de pilotage
Activities W0 W1 W2 W3 W4 W5 W6 W7 W8 W9 W10
Kick off
Identify key focus areas
Inventorize and collect existing reusable materials
Identify high potential process/product combinations
Build the SEC metrics model
Assess SEC B cost model
Prepare input data
Perform data gathering
Analyze and allocate costs
Assess operational risks
Validate/cross check results with Fortis and experts
Evaluate SEC's performance through internal and external benchmarking
Apply internal and external benchmarking
Assess and identify low performance areas
Conduct solutions brainstorming workshop
Identify and shape potential solutions
Detail each identified solution
Evaluate impact on operational risks
For each solution, describe key actions
Assess feasibility
Assess impact of solution in terms of business model
Evaluate sourcing options
Provide insigth on Service Delivery models
Confirm, build business case & action plan
Prioritize initiatives
Conduct prioritization workshop
Confirm target business model
Build detailed action plan
Build business case
Project Management
Workshop
Kick off meeting
Steering committee
Deliverable / major milestone
Phase I (in weeks)
²
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)
Project Manager Project Manager Project Manager
PMOArchitecture
• Sponsorship & propriété des projets/programmes
• Suivi de l’état d’avancement du projet et prise de décision en
matière de délivrables, périmètres, problèmes, ressources, etc…
• Responsable pour la livraison du programme
• Rapporte l’état d’avancement au comité de pilotage
• Gère les interdépendances entre projets
• Définit les processus et outils nécessaires pour la gestion du
programme et des projets
• Aide/accompagne le program manager et les project managers
• Assure la coordination et communication transversale
• Responsable pour le planning et la livraison des projets
• Rapporte le statut des délivrables, le planning, les risques et
problèmes au program manager
Comité de pilotage (*)Comité de pilotage (*)
SponsorSponsor
Comité ITComité IT
Program Manager
• Fixation et suivi de la stratégie et des plans à long terme
• Décisions clés sur les gros programmes et les projets
transversaux
Journalier
Journalier
Hebdo &
journalier
Hebdomadaire
Mois
Mois
Coordination
architecture
Support fonctionnel et
technique
24
Les acteurs du projet
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
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
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
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
• Gestion des ressources
Implementation
et Roll Out
TasksDeliverables
• Organiser les trainings
• Mettre en place l’environnement de
production
• Effectuer un parallel run
• Effectuer la migration
• Assurer le suivi post mise en production
Test
• Effectuer des tests d’intégration
• Effectuer les tests d’acceptation
• Mettre en place les environnements de
d’acceptation
• Les cas de tests
• Les résultats de tests
• Validation des tests utilisateurs
• Le plan de formations
• Le plan de support post implémentation
• Suivi du budget
• Suivi du projet
Design Build/Unit test
Program Management Office
Conduite du changement
• Etablir le design fonctionnel de la solution
• Etablir le design technique
• Définir les éléments à développer (formats, écrans,….)
• Définir l’approche de test et l’architecture technique
• Définir le contenu des formations
• Définir les nouveaux processus, l’impact sur des processus
existants
• Mettre en place l’environnement de développement
• Design fonctionnel
• Design technique
• Design des processus
• Plans de tests/stratégie de tests
• Design de l’architecture
• Développer les interfaces
• Développer l’application
• Effectuer du nettoyage de données
• Effectuer les tests unitaires de l’interface et de
l’application
• Mettre en place les environnements de test
• Les programmes
Infrastructure
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
La gestion des environnements
DEV TEST UAT PROD
Projet Production
Migration d’un package
de développement
Migration d’un package
de développement
Migration d’un package
de développement
Correction d’un bug
Maître pour les
développements
6. Gestion des
releases
6. Gestion des
releases
5. Gestion des
ressources
5. Gestion des
ressources
4. Gestion financière
et business case
4. Gestion financière
et business case
7. Coordination avec les
achats
7. Coordination avec les
achats
8. Gestion des
contrats
8. Gestion des
contrats
9. Quality
management
9. Quality
management
10. Coordination avec
Architecture
10. Coordination avec
Architecture
12. Communication12. Communication
1. Programme
tracking & reporting
1. Programme
tracking & reporting
2. Gère le périmètre2. Gère le périmètre
3. Gère les risques3. Gère les risques
Suivi du
périmètre
Follow-up sur base de
critères de qualité
Rapporte l’état
d’avancement
Identifie les
risques
Suivi de l’allocation
des ressources
Fournit les données pour
les budgets et calcul des
coûts
11. Coordination du
changement
11. Coordination du
changement
Planning définit le
contenu des releases
Les activités d’un PMO
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
 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
L’estimation de l’effort -méthode de chiffrae
Conception du modèle opératoire
Communication et Formation
Plan et exécution de tests systèmes
Planning de roll-out et exécution
Gestion du projet
Equipe de support technique
Développement & Test
Spécifications fonctionnelles
Configuration de l’application & Prototype avec
utilisateurs
Conception des processus métiers
Activité Base d’estimation
Estimation d’implémentation
# de pratiques métiers
# de conversions
(manuel / auto)
# d’interfaces entrantes
# d’interfaces sortantes
# de rapports
# de modules
Durée du projet
Taille approx de l’équipe
• Approche bottom -up
• Charge de travail/ état du projet
• Basé sur des benchmarks, points de références
Processus
d’estimation
itératif
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
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)


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
Outils – Le suivi des ressources (time reports)
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
La gestion des “change requests”
• Illustration d’un rapport de suivi de l’état d’avancement
Fiche Q/R Thème
CdC livré par
PDK
CdC mis à
jour par
Accenture
Référence
note de
proposition
Accenture
Référence note
de validation
PREDICA
Charge
(coeff.
managemen
t et
supports
inclus)
Date de
livraison
prévue
Statut
V6
QR MOA-10 Ajout de cas sur CEVT Non Non CF Q/R N/A 9 N/A
Cloturée - Non retenue par
PREDICA
QR MOA-21
Supprimer l'exclusion "décès suite à
maladie"
Non Non CF Q/R N/A 4 N/A
Cloturée - Pas de changement de
barème pour la recette
fonctionnelle
QR MOA-22
DEVGBFIN - Possibilité de choisir parmi
2 options
Non Non CF Q/R N/A 15 N/A
Cloturée - Non retenue par
PREDICA
QR MOA-09 Modification de libellés sur CEVT Non Non CF Q/R DSI/01.0846/JML 8 31/12/2001 Cloturée
QR MOA-11
Génération de plusieurs lignes de
messages pour un même actes de
gestion sur CEVT
Non Non CF Q/R DSI/01.0847/JML 7 31/12/2001 Cloturée
QR MOA-12 Interdiction des VEEX classique sur 3 en 1Non Non CF Q/R DSI/01.0905/MJL 4 31/12/2001 Cloturée
QR MOA-14 Ajout de détail sur événement MORI Non Non CF Q/R DSI/01.0931/MJL 6 31/12/2001 Cloturée
QR Projets FR-20 Livraison MCD pacte adjoint Non Non CF Q/R DSI/01.0973/MJL 10 18/02/2002 Cloturée
QR Projets FR-22 DAJDCVIR problème objets communs Non Non CF Q/R DSI/01.1042/MJL 2 18/02/2002 Cloturée
QR Projets SV610 Reprise du montant minimum disponible Non Non CF Q/R DSI/02.0074/MJL 14 18/02/2002 Cloturée
QR SV6-11
MOCB/MBAC : délégation des fonction
MOCB en fonction du type bénéficiaire
Non Non CF Q/R DSI/02.0098/MJL 0,5 18/02/2002 Cloturée
QR Projets FR09
Précisions au cdc initial suite aux
modifications des courriers et des flux
Non Non CF Q/R DSI/02.0083/MJL 7 18/02/2002 Cloturée
QR PDK-01 Evolution BCIE - Indicateur Support UC Non Non CF Q/R CF FM 12 18/02/2002 Cloturée
70,5Total V6 validé
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)
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
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
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
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
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
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

Contenu connexe

Tendances

Mon cours Agile scrum.ppt
Mon cours Agile scrum.pptMon cours Agile scrum.ppt
Mon cours Agile scrum.ppt
amani75494
 
Initiation à la gestion de projet
Initiation à la gestion de projetInitiation à la gestion de projet
Initiation à la gestion de projet
mahassine_med_amine
 
Les différentes phases d’un projet - La phase de planification
Les différentes phases d’un projet - La phase de planificationLes différentes phases d’un projet - La phase de planification
Les différentes phases d’un projet - La phase de planification
Communauté d'agglomération du Pays de Grasse
 
Management de Projet: piloter, animer, conduire des projets
Management de Projet: piloter, animer, conduire des projetsManagement de Projet: piloter, animer, conduire des projets
Management de Projet: piloter, animer, conduire des projets
Pascal Méance
 
Formation Gestion de projet
Formation Gestion de projetFormation Gestion de projet
Formation Gestion de projet
Echecs et Stratégie
 
Gestion de projet, méthodologie
Gestion de projet, méthodologieGestion de projet, méthodologie
Gestion de projet, méthodologie
Gilles Le Page
 
Les différentes phases d’un projet - La phase d’initialisation
Les différentes phases d’un projet - La phase d’initialisationLes différentes phases d’un projet - La phase d’initialisation
Les différentes phases d’un projet - La phase d’initialisation
Communauté d'agglomération du Pays de Grasse
 
Gestion de projet
Gestion de projetGestion de projet
Gestion de projet
naziha harrag
 
iso 9001
 iso 9001 iso 9001
iso 9001
Mohammed Rassai
 
MÃthode-agile-SCRUM.pptx
MÃthode-agile-SCRUM.pptxMÃthode-agile-SCRUM.pptx
MÃthode-agile-SCRUM.pptx
JaweherBN
 
La Conduite de projet
La Conduite de projetLa Conduite de projet
La Conduite de projet
Echecs & Stratégie
 
Introduction Cours Gestion de projets.pdf
Introduction Cours Gestion de projets.pdfIntroduction Cours Gestion de projets.pdf
Introduction Cours Gestion de projets.pdf
YasushiTsubakik
 
Introduction gestion de projet
Introduction gestion de projetIntroduction gestion de projet
Introduction gestion de projet
Mohamed Amine BOURHIL
 
Synthese iso 9001 2015
Synthese iso 9001 2015Synthese iso 9001 2015
Synthese iso 9001 2015
olec kovalevsky
 
Gestion des coûts d'un projet
Gestion des coûts d'un projetGestion des coûts d'un projet
Gestion des coûts d'un projet
Communauté d'agglomération du Pays de Grasse
 
Gestion de projet
Gestion de projetGestion de projet
Gestion de projet
Echecs et Stratégie
 
Charte d'équipe
Charte d'équipeCharte d'équipe
Charte d'équipe
Clotilde Mbolo-Eteme, PMP
 
Initiation à la gestion de projet
Initiation à la gestion de projetInitiation à la gestion de projet
Initiation à la gestion de projet
Samer EL SAWDA, Ph.D.
 
Tableaux de bord
Tableaux de bordTableaux de bord
Tableaux de bord
stephaneGillieron
 
Chp1 - Introduction aux ERP
Chp1 - Introduction aux ERPChp1 - Introduction aux ERP
Chp1 - Introduction aux ERP
Lilia Sfaxi
 

Tendances (20)

Mon cours Agile scrum.ppt
Mon cours Agile scrum.pptMon cours Agile scrum.ppt
Mon cours Agile scrum.ppt
 
Initiation à la gestion de projet
Initiation à la gestion de projetInitiation à la gestion de projet
Initiation à la gestion de projet
 
Les différentes phases d’un projet - La phase de planification
Les différentes phases d’un projet - La phase de planificationLes différentes phases d’un projet - La phase de planification
Les différentes phases d’un projet - La phase de planification
 
Management de Projet: piloter, animer, conduire des projets
Management de Projet: piloter, animer, conduire des projetsManagement de Projet: piloter, animer, conduire des projets
Management de Projet: piloter, animer, conduire des projets
 
Formation Gestion de projet
Formation Gestion de projetFormation Gestion de projet
Formation Gestion de projet
 
Gestion de projet, méthodologie
Gestion de projet, méthodologieGestion de projet, méthodologie
Gestion de projet, méthodologie
 
Les différentes phases d’un projet - La phase d’initialisation
Les différentes phases d’un projet - La phase d’initialisationLes différentes phases d’un projet - La phase d’initialisation
Les différentes phases d’un projet - La phase d’initialisation
 
Gestion de projet
Gestion de projetGestion de projet
Gestion de projet
 
iso 9001
 iso 9001 iso 9001
iso 9001
 
MÃthode-agile-SCRUM.pptx
MÃthode-agile-SCRUM.pptxMÃthode-agile-SCRUM.pptx
MÃthode-agile-SCRUM.pptx
 
La Conduite de projet
La Conduite de projetLa Conduite de projet
La Conduite de projet
 
Introduction Cours Gestion de projets.pdf
Introduction Cours Gestion de projets.pdfIntroduction Cours Gestion de projets.pdf
Introduction Cours Gestion de projets.pdf
 
Introduction gestion de projet
Introduction gestion de projetIntroduction gestion de projet
Introduction gestion de projet
 
Synthese iso 9001 2015
Synthese iso 9001 2015Synthese iso 9001 2015
Synthese iso 9001 2015
 
Gestion des coûts d'un projet
Gestion des coûts d'un projetGestion des coûts d'un projet
Gestion des coûts d'un projet
 
Gestion de projet
Gestion de projetGestion de projet
Gestion de projet
 
Charte d'équipe
Charte d'équipeCharte d'équipe
Charte d'équipe
 
Initiation à la gestion de projet
Initiation à la gestion de projetInitiation à la gestion de projet
Initiation à la gestion de projet
 
Tableaux de bord
Tableaux de bordTableaux de bord
Tableaux de bord
 
Chp1 - Introduction aux ERP
Chp1 - Introduction aux ERPChp1 - Introduction aux ERP
Chp1 - Introduction aux ERP
 

Similaire à Methodologie projet

RA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptxRA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptx
testuser715939
 
cours-gratuit.com--id-12146.ppt
cours-gratuit.com--id-12146.pptcours-gratuit.com--id-12146.ppt
cours-gratuit.com--id-12146.ppt
FatiMa243348
 
001GESTION DE PROJET INFO-Cours-GPI.pptx
001GESTION DE PROJET INFO-Cours-GPI.pptx001GESTION DE PROJET INFO-Cours-GPI.pptx
001GESTION DE PROJET INFO-Cours-GPI.pptx
blackmambaettijean
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
Erradi Mohamed
 
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
jkebbab
 
Génie Logiciel.pptx
Génie Logiciel.pptxGénie Logiciel.pptx
Génie Logiciel.pptx
LatifaBen6
 
Atelier Genie Logiciel Developement.pptx
Atelier Genie Logiciel  Developement.pptxAtelier Genie Logiciel  Developement.pptx
Atelier Genie Logiciel Developement.pptx
ssusercb2b311
 
1.pdf
1.pdf1.pdf
1.pdf
DabiYonko
 
Accéder au développement Dot.Net et Asp.Net
Accéder au développement Dot.Net et Asp.NetAccéder au développement Dot.Net et Asp.Net
Accéder au développement Dot.Net et Asp.Net
Frédéric Vandenbriele
 
Développement d'un grand projet piloté par les tests (BDD)
Développement d'un grand projet piloté par les tests (BDD)Développement d'un grand projet piloté par les tests (BDD)
Développement d'un grand projet piloté par les tests (BDD)
Laurent PY
 
L'Approche SMV de COGENIT
L'Approche SMV de COGENITL'Approche SMV de COGENIT
L'Approche SMV de COGENIT
Sany_M
 
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
Christophe HERAL
 
20070320 05 - Squale Portail qualimétrie
20070320 05 - Squale Portail qualimétrie20070320 05 - Squale Portail qualimétrie
20070320 05 - Squale Portail qualimétrie
LeClubQualiteLogicielle
 
20100608 03 - Retour d'experience PSA Squale
20100608 03 - Retour d'experience PSA Squale20100608 03 - Retour d'experience PSA Squale
20100608 03 - Retour d'experience PSA Squale
LeClubQualiteLogicielle
 
20171122 04 - Automatisation - formation et certifications
20171122 04 - Automatisation - formation et certifications20171122 04 - Automatisation - formation et certifications
20171122 04 - Automatisation - formation et certifications
LeClubQualiteLogicielle
 
Proposition_commerciale_ISARTIS-PERENCO_VF
Proposition_commerciale_ISARTIS-PERENCO_VFProposition_commerciale_ISARTIS-PERENCO_VF
Proposition_commerciale_ISARTIS-PERENCO_VF
Thierry Serranou
 
Esg lesson 4
Esg lesson 4Esg lesson 4
Esg lesson 4
Alban Oujagir
 
Cycles de vie d'un logiciel
Cycles de vie d'un logicielCycles de vie d'un logiciel
Cycles de vie d'un logiciel
Rabia AZIZA
 
Bonnes pratiques : la hiérarchie des exigences
Bonnes pratiques : la hiérarchie des exigencesBonnes pratiques : la hiérarchie des exigences
Bonnes pratiques : la hiérarchie des exigences
Caroline de Villèle
 

Similaire à Methodologie projet (20)

RA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptxRA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptx
 
cours-gratuit.com--id-12146.ppt
cours-gratuit.com--id-12146.pptcours-gratuit.com--id-12146.ppt
cours-gratuit.com--id-12146.ppt
 
001GESTION DE PROJET INFO-Cours-GPI.pptx
001GESTION DE PROJET INFO-Cours-GPI.pptx001GESTION DE PROJET INFO-Cours-GPI.pptx
001GESTION DE PROJET INFO-Cours-GPI.pptx
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
 
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
 
Génie Logiciel.pptx
Génie Logiciel.pptxGénie Logiciel.pptx
Génie Logiciel.pptx
 
Atelier Genie Logiciel Developement.pptx
Atelier Genie Logiciel  Developement.pptxAtelier Genie Logiciel  Developement.pptx
Atelier Genie Logiciel Developement.pptx
 
1.pdf
1.pdf1.pdf
1.pdf
 
Accéder au développement Dot.Net et Asp.Net
Accéder au développement Dot.Net et Asp.NetAccéder au développement Dot.Net et Asp.Net
Accéder au développement Dot.Net et Asp.Net
 
Développement d'un grand projet piloté par les tests (BDD)
Développement d'un grand projet piloté par les tests (BDD)Développement d'un grand projet piloté par les tests (BDD)
Développement d'un grand projet piloté par les tests (BDD)
 
L'Approche SMV de COGENIT
L'Approche SMV de COGENITL'Approche SMV de COGENIT
L'Approche SMV de COGENIT
 
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
 
20070320 05 - Squale Portail qualimétrie
20070320 05 - Squale Portail qualimétrie20070320 05 - Squale Portail qualimétrie
20070320 05 - Squale Portail qualimétrie
 
20100608 03 - Retour d'experience PSA Squale
20100608 03 - Retour d'experience PSA Squale20100608 03 - Retour d'experience PSA Squale
20100608 03 - Retour d'experience PSA Squale
 
20171122 04 - Automatisation - formation et certifications
20171122 04 - Automatisation - formation et certifications20171122 04 - Automatisation - formation et certifications
20171122 04 - Automatisation - formation et certifications
 
Proposition_commerciale_ISARTIS-PERENCO_VF
Proposition_commerciale_ISARTIS-PERENCO_VFProposition_commerciale_ISARTIS-PERENCO_VF
Proposition_commerciale_ISARTIS-PERENCO_VF
 
Esg lesson 4
Esg lesson 4Esg lesson 4
Esg lesson 4
 
Esg lesson 4
Esg lesson 4Esg lesson 4
Esg lesson 4
 
Cycles de vie d'un logiciel
Cycles de vie d'un logicielCycles de vie d'un logiciel
Cycles de vie d'un logiciel
 
Bonnes pratiques : la hiérarchie des exigences
Bonnes pratiques : la hiérarchie des exigencesBonnes pratiques : la hiérarchie des exigences
Bonnes pratiques : la hiérarchie des exigences
 

Methodologie projet

  • 2. •Les phases du projet •Structure d’un projet •Gouvernance de projets •Les phases du projet – Le release management – La conception – Le développement – Les tests – Le roll out
  • 3. Vue d’ensemble Réunion de Lancement Installation Formation découverte Formation administrateur Analyse générale - fonctionnelle - reprise de données - Interface Développement Formation key users Transfert au Support et Service client Etude d’adéquation Initialisation Analyse Conception ExploitationMise en production Assistance au démarrage Reprise de données définitives Analyse des écarts ParamétrageReprise de données test Tests et validation du pilote Formation end users Vérification GO / NO GO Réalisation Tests unitaires Codification et Paramétrage de base Gestion de projetPQP Validation S1 Validation S2 Recette définitive
  • 4. • Un projet a pour objectif de mener à bien le développement d’une nouvelle application ou l’adaptation d’une application existante • Un projet est caractérisé par : – Un périmètre – quels sont les besoins clients auxquels on doit répondre – Un deadline – le projet doit être terminé à une date fixe – Des délivrables – les produits finis du projet – Un planning indiquant quand chaque produit fini sera livré et comment les activités et donc la charge de travail sera répartie dans le temps – Des ressources dédiées partiellement ou totalement au projet – Une structure de gouvernance
  • 5. 5  La phase d’analyse permettra de valider les points non encore détaillés du projet.  Elle sera réalisée à partir des processus cibles communiqués par le client dans son cahier des charges, complétés par les interviews des pilotes  Le livrable Rapport d’adéquation définira les écarts entre le fonctionnement standard de la solution logicielle et le système cible en proposant différentes solutions (développement, modification d’organisation) pour le traitement de ces écarts  La validation du livrable issue de cette étape est une condition nécessaire pour la poursuite du projet et permet de définir l’ensemble du système d’information cible à réaliser durant le projet  Il s’agit d’une réalisation d’analyse globale du périmètre projet, quel que soit ensuite le découpage de la mise en œuvre. Ceci afin de bien appréhender l’ensemble de la problématique avant de réaliser le paramétrage La phase d’analyse
  • 6. Le design (spécifications) • Les spécifications détaillent les besoins métiers à un niveau suffisament détaillé que pour être non interprétables pour le développement de ces spécifications • Les spécifications détaillent les besoins métiers par rapport au système-cible – Sur base d’une maquette – Sur base d’un prototype – Sur base d’une description détaillée • Les spécifications doivent être formellement validées par le responsable du projet métiers • Exemple de spécifications fonctionnelles pour des passages d’ordres – Ecrans de passage d’ordres – Listes d’ordres – Mécanismes de validation des ordres – Le flux des ordres – Le calcul estimatif des frais de transactions • Exemple de spécifications techniques – Format des messages – Mode de transmission des messages (synchrone, asynchrone)
  • 7. L’importance du design Besoins utilisateurs Design tech & funct Programmation Tests unitaires Tests d’intégration Tests d’acceptance Maintenance Source des erreurs Découverte des erreurs 40% - 60% 20% - 40% 10% - 20% 20% - 50% 40% - 60% On découvre que le design a été mal fait pendant les tests … Un mauvais design va générer beaucoup de travail en développement (re coding) après les tests et accroître les coûts de développement du projet 10% - 20% Besoins utilisateurs Design tech & funct Programmation Tests unitaires Tests d’intégration Tests d’acceptance Maintenance
  • 8. Le prototypage • Méthode itérative pour spécifier et développer • Applicable principalement pour des “packages” • Sur base d’une première collecte des besoins, un prototype est développé et passé en revue avec les utilisateurs • Prérequis – Une bonne anticipation des besoins métiers (expertise) – Des utilisateurs raisonnables – le prototype doit permettre de valider les spécifications et non pas introduire une longue liste de modifications • Avantages – Collecter les demandes de modifications pendant le design et non pendant le testing – Développement en parallèle avec les spécifications – Cadrer les spécifications – éviter le syndrôme de la page blanche (éviter des développements lourds sur des packages). Utiliser des configurations prédéfinies
  • 9. Le développement • Se baser sur des configurations existantes (packages) • Centraliser les configurations dans un fichier – Réinitialisation des développements – Baseline management – retour à une version précédente aisé – Versioning aisé • Version : état du développement • Conservation des versions précédentes – Documentation des développements
  • 10. Les tests • L’objectif de la phase de test est de valider que les spécifications ont correctement été implémentées • Phases de test principales – Tests unitaires • Tests réalisés par le développeur • Tests de chaque élément de développement – Tests systèmes • Tests réalisés par le développeur • Tests de compatibilité de blocs de développement dans un même environnement – Tests d’intégration • Tests réalisés par une équipe de test projet • Déroulement de jeux de tests fonctionnels – Tests d’acceptation • Tests réalisés par les utilisateurs • Déroulement, une seconde fois, des jeux de tests fonctionnels – Validation formelle par le responsable du projet de la mise en production
  • 11. Les activités de tests Test planning/Test Management Définition de l’approche de tests Plans de tests Préparation des tests Exécution des tests Mise en place des environnements de tests •Objectifs •Périmètre •Risques •Ressources •Besoins d’environnement •Metrics •Critères d’acceptation •Points de référence •Planning •Conditions de tests •Cycles de tests •Outils de tracking d’erreurs •Jeux de tests •Exécution des jeux de tests
  • 12. Le roll out • Le roll out est la mise en production d’une release. Il est conditionné à l’approbation du métier (sur base des tests d’acceptation) • Le roll out doit être accompagné – D’un plan de formation des utilisateurs – D’un accompagnement de l’équipe projet pendant les premiers mois de mise en production • Résolution des problèmes • Accompagnement utilisateurs • On peut également avoir un “parallel run” avant une mise en production effective. Les utilisateurs utilisent deux systèmes en parallèle (l’ancien et le nouveau). Ils effectuent toutes leurs actions quotidiennes sur le système. Une fois que le parallel run est validé par les utilisateurs, l’application peut être mise en production – Procédure lourde (production like) – Allonge la période de test mais réduit le risque de problèmes en production
  • 13. 13 La phase de conception  La phase de conception permettra de valider les points non encore détaillés du projet.  La complexité de cette phase est liée au nombre d’écarts qui pourraient être identifiés suite à la phase d’analyse générale  Tout écart est détaillé dans une fiche d’écart qui permettra d’évaluer la charge afférente et sa réalisation.  Aucun développement n’est effectué sans Fiche d’écart validé par le Client. 13
  • 14. 14 La phase de conception 14 Identifier les éléments non standards et de valider le périmètre et le budget afférent : Fonctions non standard Interfaces Rapports Reprise de données La complexité de cette phase est liée au nombre d’écarts qui pourraient être identifiés suite à la phase d’analyse générale La démarche de conception se veut au plus proche de la solution standard Qualification des besoins indispensables / cosmétiques Cette phase sera également utilisée pour préparer la recette fonctionnelle Identification des scénarios Métier Construction des cas de tests Collecte des jeux de données
  • 15. 15 La phase de mise en production La phase de mise en production acte du passage en exploitation la solution dans l’environnement de production La formation des utilisateurs finaux est effectuée à priori par l’équipe des pilotes client qui auront préalablement rédigés les manuels utilisateurs. Le décision du démarrage est validée par le comité de pilotage suite à la simulation en charge qui recrée les conditions d’exploitation du démarrage. La prestation de démarrage est systématiquement réalisée en fonction de la demande du client. Son contenu et sa durée sont donc confirmés juste avant le go-live.
  • 16. 16 La phase de réalisation La phase de réalisation permettra de de paramétrer la solution et de réaliser les écarts exprimés en conception afin de conduire à la validation du pilote.  Elle nécessite une participation active de l’équipe projet du client  Elle se caractérise par un transfert de compétence très fort entre les équipes de l’intégrateur et celle du client  Elle intègre la réalisation des prestations liées à l’ingénierie qui sont menées en parallèle du paramétrage  Elle se conclue par la présentation du prototype par l’équipe interne du client 16
  • 17. 17 Vue d’ensemble Réunion de Lancement Installation Formation découverte Formation administrateur Analyse générale - fonctionnelle - reprise de données - Interface Développement Formation key users Transfert au Support et Service client Etude d’adéquation Initialisation Analyse Conception ExploitationMise en production Assistance au démarrage Reprise de données définitives Analyse des écarts ParamétrageReprise de données test Tests et validation du pilote Formation end users Vérification GO / NO GO Réalisation Tests unitaires Codification et Paramétrage de base Gestion de projetPQP Validation S1 Validation S2 Recette définitive 17
  • 18. 18 Livrables Planning, Plan Qualité Projet, Compte rendu Réunion de lancement, Fiches d’écart, Modèle Fichiers de reprise de données PV Reprise test, PV de recette fonctionnelle Dossier de paramétrage PV de reprise de données définitives, Kit de déploiement Rapport d’adéquation, Tableau des écarts PV de recette définitif Procédure de support Vue d’ensemble : LIVRABLES CLES Initialisation Analyse Conception ExploitationMise en productionRéalisation 18
  • 19. 19 Livrables Planning, Plan Qualité Projet, Compte rendu Réunion de lancement, Fiches d’écart, Modèle Fichiers de reprise de données PV Reprise test, PV de recette fonctionnelle Dossier de paramétrage PV de reprise de données définitives, Kit de déploiement Rapport d’adéquation, Tableau des écarts PV de recette définitif Procédure de support Vue d’ensemble : LIVRABLES CLES Initialisation Analyse Conception ExploitationMise en productionRéalisation 19
  • 20. Exemple de planning d’un programme • Le macro planning montre l’étalement des releases, la charge hommes liée à chaque release et les jalons principaux (milestones) du programme j f m a m j j a s o n d j f m a m j j a s o n d j f m a m j j a s o n d Req's Performance Reporting Visie Triple'A Project Initiation Study Release 1 - Client reporting Release 1 - Branch Rollout Release 2 - Order Entry Release 3 - Performance attribution & GIPS Total estimated effort in mandays 7 Duration in months 1 Major Milestones First Performance report sent to PCNL clients AAA WUI available in branches portfolio analysis supported by order entry and compliance checking Client portfolio monitoring & performance attribution available 200 44 1663 MD 10 608 2 2 2212 MD + 1142 MD extract 10 85 120 Q3 Q4Q1 Q2Q3 Q4 Activities 2003 2004 2005 Q1 Q2 Q3 Q4 Q1 Q2
  • 21. Exemple de planning détaillé • Le planning reprend les activités principales, sous-activités, délivrables, la fréquence des comités de pilotage Activities W0 W1 W2 W3 W4 W5 W6 W7 W8 W9 W10 Kick off Identify key focus areas Inventorize and collect existing reusable materials Identify high potential process/product combinations Build the SEC metrics model Assess SEC B cost model Prepare input data Perform data gathering Analyze and allocate costs Assess operational risks Validate/cross check results with Fortis and experts Evaluate SEC's performance through internal and external benchmarking Apply internal and external benchmarking Assess and identify low performance areas Conduct solutions brainstorming workshop Identify and shape potential solutions Detail each identified solution Evaluate impact on operational risks For each solution, describe key actions Assess feasibility Assess impact of solution in terms of business model Evaluate sourcing options Provide insigth on Service Delivery models Confirm, build business case & action plan Prioritize initiatives Conduct prioritization workshop Confirm target business model Build detailed action plan Build business case Project Management Workshop Kick off meeting Steering committee Deliverable / major milestone Phase I (in weeks) ²
  • 22. La structure d’un projet • Un projet sera, si nécessaire, divisé en sous projets – Chaque sous projet sera géré par un project manager – Les project managers rapporteront à un program manager, en charge de l’ensemble du projet – Le program manager rapportera l’état d’avancement du projet à un comité de pilotage – Pour de gros projets, il existe un Program Management Office, en charge du suivi financier et administratif du projet • La participation des métiers au projet – Le sponsor du projet est, en général, un directeur du métier concerné – Via un co management d’un projet par l’IT et le métier concerné – Via une participation partielle ou à temps plein de représentants du métier dans le projet (définition des spécifications, validation des prototypes, tests, validation des tests)
  • 23. Project Manager Project Manager Project Manager PMOArchitecture • Sponsorship & propriété des projets/programmes • Suivi de l’état d’avancement du projet et prise de décision en matière de délivrables, périmètres, problèmes, ressources, etc… • Responsable pour la livraison du programme • Rapporte l’état d’avancement au comité de pilotage • Gère les interdépendances entre projets • Définit les processus et outils nécessaires pour la gestion du programme et des projets • Aide/accompagne le program manager et les project managers • Assure la coordination et communication transversale • Responsable pour le planning et la livraison des projets • Rapporte le statut des délivrables, le planning, les risques et problèmes au program manager Comité de pilotage (*)Comité de pilotage (*) SponsorSponsor Comité ITComité IT Program Manager • Fixation et suivi de la stratégie et des plans à long terme • Décisions clés sur les gros programmes et les projets transversaux Journalier Journalier Hebdo & journalier Hebdomadaire Mois Mois Coordination architecture Support fonctionnel et technique
  • 25. Gouvernance de projet • Tout projet doit avoir un comité de pilotage approprié • Une structure claire de projet et de gouvernance est nécessaire : – Réalisation du projet avec succès – Participation de toutes les parties impliquées – Définition claire des rôles et responsabilités des personnes impliquées dans le projet et dans le comité de pilotage – Contrôle et suivi étroit du progrès du projet – Capacités à mitiger les risques – Mécanismes clairs d’escalation des problèmes
  • 26. Le rôle des membres du comité de pilotage • Rôle – Gardien de la vision et des objectifs du projet – Gère la communication sur le projet vis-à-vis de tiers – Suit le planning et les délivrables, pas les processus • Responsabilités – Règle les problèmes organisationnels et de ressources – Gère l’allocation des ressources et les dépendances entre projets – Est responsable de la communication au sein et en-dehors du projet – Valide les délivrables – Gère le périmètre et mitige les risques • Fréquence de réunion : 1x/mois
  • 27. Le rôle du program manager • Rôle – Gardien du planning du projet – Assure la gestion du projet au jour le jour – Gère le statut du projet – Escale à temps et de manière appropriée les problèmes au comité de pilotage • Responsabilités – Coordonne les parties et s’assure de la réalisation du projet à temps – Gère, planifie les ressources – Gère les aspects financiers du projet – Adhère aux best practices, méthodologies et outils de développement – Gère le périmètre et les risques
  • 28. Gouvernance du projet Définir les objectifs Valider les objectifs Comité de pilotage Program Mgmt Définir le périmètre du programme Valider le périmètre du programme Project Management Définir le périmètre du projet Valider le périmètre du projet Résoudre les problèmes Gérer le périmètre en ligne avec attentes métiers Résoudre/escaler les problèmes Gérer le périmètre du programme Résoudre/escaler les problèmes Gérer le périmètre du projet Exécution du projet
  • 29. • Gestion des ressources Implementation et Roll Out TasksDeliverables • Organiser les trainings • Mettre en place l’environnement de production • Effectuer un parallel run • Effectuer la migration • Assurer le suivi post mise en production Test • Effectuer des tests d’intégration • Effectuer les tests d’acceptation • Mettre en place les environnements de d’acceptation • Les cas de tests • Les résultats de tests • Validation des tests utilisateurs • Le plan de formations • Le plan de support post implémentation • Suivi du budget • Suivi du projet Design Build/Unit test Program Management Office Conduite du changement • Etablir le design fonctionnel de la solution • Etablir le design technique • Définir les éléments à développer (formats, écrans,….) • Définir l’approche de test et l’architecture technique • Définir le contenu des formations • Définir les nouveaux processus, l’impact sur des processus existants • Mettre en place l’environnement de développement • Design fonctionnel • Design technique • Design des processus • Plans de tests/stratégie de tests • Design de l’architecture • Développer les interfaces • Développer l’application • Effectuer du nettoyage de données • Effectuer les tests unitaires de l’interface et de l’application • Mettre en place les environnements de test • Les programmes Infrastructure
  • 30. La gestion des environnements • Plusieurs environnements sont nécessaires pour implémenter une nouvelle application – Un ou plusieurs environnements de développement – Un ou plusieurs environnements de test – Un ou plusieurs environnements d’acceptation – Un ou plusieurs environnements de production • Chaque environnement supporte une version de l’application (application, base de données, interfaces..) • Plusieurs environnements peuvent se trouver sur la même machine physique. En pratique, pour des applications lourdes, une machine est utilisée par environnement • L’installation d’une machine prend du temps (+/- 2 mois) et doit donc être bien planifiée. On commence d’abord par installer la machine de développement • La gestion des environnements de développement et de tests est, en général, effectuée par le projet • La gestion des environnements d’acceptation et de production est, en générale, effectuée par le département qui “hostera” les machines en production
  • 31. La gestion des environnements DEV TEST UAT PROD Projet Production Migration d’un package de développement Migration d’un package de développement Migration d’un package de développement Correction d’un bug Maître pour les développements
  • 32. 6. Gestion des releases 6. Gestion des releases 5. Gestion des ressources 5. Gestion des ressources 4. Gestion financière et business case 4. Gestion financière et business case 7. Coordination avec les achats 7. Coordination avec les achats 8. Gestion des contrats 8. Gestion des contrats 9. Quality management 9. Quality management 10. Coordination avec Architecture 10. Coordination avec Architecture 12. Communication12. Communication 1. Programme tracking & reporting 1. Programme tracking & reporting 2. Gère le périmètre2. Gère le périmètre 3. Gère les risques3. Gère les risques Suivi du périmètre Follow-up sur base de critères de qualité Rapporte l’état d’avancement Identifie les risques Suivi de l’allocation des ressources Fournit les données pour les budgets et calcul des coûts 11. Coordination du changement 11. Coordination du changement Planning définit le contenu des releases Les activités d’un PMO
  • 33. Les processus gérés par le PMO Processus de Program management Besoins Gestion du budget Monitoring du taux d’activité sur base du planning et du plan de staffing Change control Contrôle strict sur les augmentations, réductions de périmètre, avec évaluation par rapport au business case, au planning et aux coûts. Ces points doivent être escalés au Comité de Pilotage Délivrables/milestones/ Dependency management Un mécanisme de tracking doit être suivi par tous les project managers Problèmes Une des priorités des project managers est de résoudre les problèmes Réunions de projets Les réunions sont focalisées sur l’état d’avancement (par rapport au budget, au planning, aux délivrables), les problèmes et le change control Qualité Des revues de qualité sont organisées afin de vérifier que le projet est géré selon de bonnes règles de gestion de projet Gestion des ressources Besoin d’anticiper les besoins en ressources et allocation au bon moment aux différents sous projets Risques Les risques doivent être bien documentés et escalés systématiquement au comité de pilotage Suivi du temps passé Tout membre du projet doit rapporter son temps avec un niveau de détail suffisant que pour assurer un bon contôle financier du projet Gestion du planning Utilisation d’un outil de planning commun pour tous les sous projets. Les planning sont gérés par chaque sous projet. Tous les plannings alimentent un programme commun utilisé pour le suivi budgétaire
  • 34.  Spécifications fonctionnelles  Complexité métier  Software “Fit”  Technical “Fit”  Capacité de la société à accepter le changement  Intégration et effort de conversion Facteurs Base – Nombre de fonctions business impactées – # employés et utilisateurs – Degré de changement des processus – Qualité des données mainframe – Nombre de modifications attendues/extensions – Existence d’un environnement technique approprié – Expérience avec les changements passés – Processus de prise de décision – Sponsoring du projet – Résistance au changement – # interfaces & conversions – Complexité de l’ integration – Approche de conversion + - Estimating Accuracy Project Phases... Initial Assessment Global Design and Prototype Conceptual Design Build and Rollout 20-25% 15-20% 10-15% L’estimation de l’effort • L’estimation de l’effort est une activité itérative. Plus l’incertitude diminue, meilleure est l’estimation
  • 35. L’estimation de l’effort -méthode de chiffrae Conception du modèle opératoire Communication et Formation Plan et exécution de tests systèmes Planning de roll-out et exécution Gestion du projet Equipe de support technique Développement & Test Spécifications fonctionnelles Configuration de l’application & Prototype avec utilisateurs Conception des processus métiers Activité Base d’estimation Estimation d’implémentation # de pratiques métiers # de conversions (manuel / auto) # d’interfaces entrantes # d’interfaces sortantes # de rapports # de modules Durée du projet Taille approx de l’équipe • Approche bottom -up • Charge de travail/ état du projet • Basé sur des benchmarks, points de références Processus d’estimation itératif
  • 36. Outils - Le suivi financier de projets • Il est important de pouvoir suivre le coût du projet par rapport à un budget initial (“baseline”) et de justifier les écarts
  • 37. Outils - Les rapports d’avancement • Rapporter de manière synthétique l’état d’avancement, les risques, les problèmes....Identification des délivrables clés réalisés. 2 V6 - AVANCEMENT Statut du Projet au 31/01/2002 Consommé % Gagné % Pilotage V6 DDL V6 Développements V6 TA Documentation/Préparation TA Execution/Correction Recette fonctionnelle V6 Total V6 Budget : Indicateurs physiques Risques identifiés Evaluation Respect du calendrier : Respect des budgets : Dépassement budgétaire sur certains projets (développement et TA). 116% 135% 104% 182% 102% 48% 100% 100% 100% 100% 96% 85% Périmètre propositions V6-P1 : 871 jh Périmètre propositions V6-P2 : 139 jh Evolutions V6 validées : 58,5 jh (1) Hors version traité en V6 : 12 jh Forecast end : 1101 jh Ratio E/B : 1,09 Proposition validée : 871 jh +139 jh + 70,5 jh évolutions => 1080,5 jh Total V6 ouvert P1&P2 : 1010 jh (1) CF Budget évolutions annexé 107% 98% Périmètre 1 : - Recette fonctionnelle terminées sur les 10 sujets la composant.. Périmètre 2 : - 2 dossiers de SFD livrés (DAJNANTI2 et UGMADH01) - 1 dossier validé par Predica (DAJNANTI2) - Matrices de tests et cycles de tests validés par PREDICA. - La nouvelle consultation CEVT a levée un problème de pagination lié à l’architecture existante, ce point sera traité lors d’une réunion entre DSI / Accenture / IFS le jeudi 07/02. (QR VR17)  
  • 38. Outils – Le suivi des ressources (time reports) • Il est important de tracker le nombre d’heures passées sur le projet; ce coût étant le principal coût d’un projet d’implémentation • Chacun rapporte ses heures consommées dans un time report • Ceci est utilisé pour le suivi financier du projet, la facturation du projet et éventuellement, le paiement d’heures supplémentaires
  • 39. Outils – Le suivi des ressources (time reports)
  • 40. La gestion des “change requests” • Le périmètre est fixé avant le démarrage du projet dans une phase de préparation, cadrage du projet • Il est fréquent que, de nouveaux besoins soient exprimés en cours de projet. • Ceux-ci influencent la charge de travail totale du projet et peuvent mettre la date de livraison en péril. D’où l’importance pour un program manager de : – Bien qualifier chaque change request (un change request trop lourd doit être repoussé dans une release ultérieure) – Suivre de manière spécifique les change requests (état d’avancement, charge de travail) – Faire valider l’inclusion de change requests dans le périmètre du projet par le comité de pilotage
  • 41. La gestion des “change requests” • Illustration d’un rapport de suivi de l’état d’avancement Fiche Q/R Thème CdC livré par PDK CdC mis à jour par Accenture Référence note de proposition Accenture Référence note de validation PREDICA Charge (coeff. managemen t et supports inclus) Date de livraison prévue Statut V6 QR MOA-10 Ajout de cas sur CEVT Non Non CF Q/R N/A 9 N/A Cloturée - Non retenue par PREDICA QR MOA-21 Supprimer l'exclusion "décès suite à maladie" Non Non CF Q/R N/A 4 N/A Cloturée - Pas de changement de barème pour la recette fonctionnelle QR MOA-22 DEVGBFIN - Possibilité de choisir parmi 2 options Non Non CF Q/R N/A 15 N/A Cloturée - Non retenue par PREDICA QR MOA-09 Modification de libellés sur CEVT Non Non CF Q/R DSI/01.0846/JML 8 31/12/2001 Cloturée QR MOA-11 Génération de plusieurs lignes de messages pour un même actes de gestion sur CEVT Non Non CF Q/R DSI/01.0847/JML 7 31/12/2001 Cloturée QR MOA-12 Interdiction des VEEX classique sur 3 en 1Non Non CF Q/R DSI/01.0905/MJL 4 31/12/2001 Cloturée QR MOA-14 Ajout de détail sur événement MORI Non Non CF Q/R DSI/01.0931/MJL 6 31/12/2001 Cloturée QR Projets FR-20 Livraison MCD pacte adjoint Non Non CF Q/R DSI/01.0973/MJL 10 18/02/2002 Cloturée QR Projets FR-22 DAJDCVIR problème objets communs Non Non CF Q/R DSI/01.1042/MJL 2 18/02/2002 Cloturée QR Projets SV610 Reprise du montant minimum disponible Non Non CF Q/R DSI/02.0074/MJL 14 18/02/2002 Cloturée QR SV6-11 MOCB/MBAC : délégation des fonction MOCB en fonction du type bénéficiaire Non Non CF Q/R DSI/02.0098/MJL 0,5 18/02/2002 Cloturée QR Projets FR09 Précisions au cdc initial suite aux modifications des courriers et des flux Non Non CF Q/R DSI/02.0083/MJL 7 18/02/2002 Cloturée QR PDK-01 Evolution BCIE - Indicateur Support UC Non Non CF Q/R CF FM 12 18/02/2002 Cloturée 70,5Total V6 validé
  • 42. Le design (spécifications) • Les spécifications détaillent les besoins métiers à un niveau suffisament détaillé que pour être non interprétables pour le développement de ces spécifications • Les spécifications détaillent les besoins métiers par rapport au système-cible – Sur base d’une maquette – Sur base d’un prototype – Sur base d’une description détaillée • Les spécifications doivent être formellement validées par le responsable du projet métiers • Exemple de spécifications fonctionnelles pour des passages d’ordres – Ecrans de passage d’ordres – Listes d’ordres – Mécanismes de validation des ordres – Le flux des ordres – Le calcul estimatif des frais de transactions • Exemple de spécifications techniques – Format des messages – Mode de transmission des messages (synchrone, asynchrone)
  • 43. L’importance du design Besoins utilisateurs Design tech & funct Programmation Tests unitaires Tests d’intégration Tests d’acceptance Maintenance Source des erreurs Découverte des erreurs 40% - 60% 20% - 40% 10% - 20% 20% - 50% 40% - 60% On découvre que le design a été mal fait pendant les tests … Un mauvais design va générer beaucoup de travail en développement (re coding) après les tests et accroître les coûts de développement du projet 10% - 20% Besoins utilisateurs Design tech & funct Programmation Tests unitaires Tests d’intégration Tests d’acceptance Maintenance
  • 44. Le prototypage • Méthode itérative pour spécifier et développer • Applicable principalement pour des “packages” • Sur base d’une première collecte des besoins, un prototype est développé et passé en revue avec les utilisateurs • Prérequis – Une bonne anticipation des besoins métiers (expertise) – Des utilisateurs raisonnables – le prototype doit permettre de valider les spécifications et non pas introduire une longue liste de modifications • Avantages – Collecter les demandes de modifications pendant le design et non pendant le testing – Développement en parallèle avec les spécifications – Cadrer les spécifications – éviter le syndrôme de la page blanche (éviter des développements lourds sur des packages). Utiliser des configurations prédéfinies
  • 45. Le développement • Se baser sur des configurations existantes (packages) • Centraliser les configurations dans un fichier – Réinitialisation des développements – Baseline management – retour à une version précédente aisé – Versioning aisé • Version : état du développement • Conservation des versions précédentes – Documentation des développements
  • 46. Les tests • L’objectif de la phase de test est de valider que les spécifications ont correctement été implémentées • Phases de test principales – Tests unitaires • Tests réalisés par le développeur • Tests de chaque élément de développement – Tests systèmes • Tests réalisés par le développeur • Tests de compatibilité de blocs de développement dans un même environnement – Tests d’intégration • Tests réalisés par une équipe de test projet • Déroulement de jeux de tests fonctionnels – Tests d’acceptation • Tests réalisés par les utilisateurs • Déroulement, une seconde fois, des jeux de tests fonctionnels – Validation formelle par le responsable du projet de la mise en production
  • 47. Les activités de tests Test planning/Test Management Définition de l’approche de tests Plans de tests Préparation des tests Exécution des tests Mise en place des environnements de tests •Objectifs •Périmètre •Risques •Ressources •Besoins d’environnement •Metrics •Critères d’acceptation •Points de référence •Planning •Conditions de tests •Cycles de tests •Outils de tracking d’erreurs •Jeux de tests •Exécution des jeux de tests
  • 48. Le roll out • Le roll out est la mise en production d’une release. Il est conditionné à l’approbation du métier (sur base des tests d’acceptation) • Le roll out doit être accompagné – D’un plan de formation des utilisateurs – D’un accompagnement de l’équipe projet pendant les premiers mois de mise en production • Résolution des problèmes • Accompagnement utilisateurs • On peut également avoir un “parallel run” avant une mise en production effective. Les utilisateurs utilisent deux systèmes en parallèle (l’ancien et le nouveau). Ils effectuent toutes leurs actions quotidiennes sur le système. Une fois que le parallel run est validé par les utilisateurs, l’application peut être mise en production – Procédure lourde (production like) – Allonge la période de test mais réduit le risque de problèmes en production