Technique

AUMONIERS DU TRAVAIL Antonis BOULAFENTIS
_______________________________________________________________________________
AUMONIERS DU TRAVAIL
Bachelier en Informatique de Gestion
INFORMATIQUE
TECHNIQUES DE GESTION DE PROJET
Professeur : Antonis BOULAFENTIS
________________________________________________________________________
Informatique – Techniques de Gestion de Projet Page 1
_______________________________________________________________________________
1 Table des Matières

1 Table des Matières ............................................................................................................. 2
1 Introduction ........................................................................................................................ 9
1.1 Développement d’un logiciel ................................................................................... 9
2 Définitions (oui) ............................................................................................................... 11
2.1 Projet ....................................................................................................................... 11
2.2 Mode « Projet » <> Mode « Opération » (oui)..................................................... 12
2.3 Management de projet (oui) .................................................................................. 13
Le triangle de projet (oui) ................................................................................. 14
Méthodes (oui) ................................................................................................. 15
2.4 Le Projet au « centre » (oui) – 17/09/2017 ............................................................ 16
2.5 Les différents niveaux (oui) ................................................................................... 17
Niveau économique € ....................................................................................... 17
Niveau social .................................................................................................... 19
Niveau organisationnel ..................................................................................... 19
Niveau technique .............................................................................................. 19
Niveau des ressources humaines ...................................................................... 20
2.6 Un nombre important de situations différentes (oui) ......................................... 21
2.7 Le cycle de vie d’une application Informatique (oui) ......................................... 22
Processus de développement ............................................................................ 22
Les grandes phases ........................................................................................... 22
2.7.2.1 La conception (DESIGN) ......................................................................... 22
2.7.2.2 La réalisation (DEVELOPPEMENT) ...................................................... 23
2.7.2.3 La Livraison (DELIVERY) ...................................................................... 23
2.7.2.4 Superposition des 3 phases ....................................................................... 23
La maintenance (oui) – 19/09/2017 ................................................................. 24
3 Projets (oui) – le 20/09 ..................................................................................................... 25
3.1 Les trois axes ........................................................................................................... 25
3.2 Deux Rôles Clés (oui) ............................................................................................. 27
Maîtrise d’Ouvrage (MOA) ............................................................................. 27
Maîtrise d’Œuvre (MOE) ................................................................................. 27
3.3 Les modèles de développements (oui) ................................................................... 28
Les disciplines dites « d’ingénierie » ............................................................... 28
3.3.1.1 L’analyse business [business analysis] .................................................... 28
3.3.1.2 L’analyse fonctionnelle [functional analysis] .......................................... 28
3.3.1.3 La conception [technical design] .............................................................. 28
3.3.1.4 L’implémentation [implementation ou coding] ....................................... 29
3.3.1.5 Les tests fonctionnels [functional testing] ................................................ 29
3.3.1.6 Les autres activités ??? ............................................................................. 29
3.3.1.7 Les proportions de « Charge » sur les 5 disciplines (oui) ........................ 30
Le modèle « en chûte d’eau » [Waterfall] (Oui) .............................................. 31
Le modèle « en V » (Non) ................................................................................ 33
________________________________________________________________________
_______________________________________________________________________________
Les modèles « Itératifs » dit AGILE (Oui) ...................................................... 34

3.3.4.1 Modèle RAD « Rapid Application Developement » ............................... 35
3.3.4.2 Modèle XP « eXtrem Programming » 26/09/2017 .................................. 36
3.3.4.3 Modèle « Rational Unified Process – RUP » (3/10/2017) ....................... 38
3.3.4.3.1 Historique ............................................................................................. 38
3.3.4.3.2 Principales caractéristiques .................................................................. 38
3.3.4.4 SCRUM (Oui) .......................................................................................... 45
3.3.4.4.1 Principes : ............................................................................................. 46
3.3.4.4.2 User Stories [US] : ............................................................................... 47
3.3.4.4.3 L’équipe : ............................................................................................. 48
3.3.4.4.4 Planning Poker : ................................................................................... 50
3.3.4.4.5 Burn Down Chart : ............................................................................... 51
4 Les risques (oui) le 10/10/2017 ........................................................................................ 52
4.1 Techniques d’identifications.................................................................................. 53
4.2 Expression du risque .............................................................................................. 53
4.3 Quantification du risque ........................................................................................ 54
4.4 Planification de la réponse ..................................................................................... 55
4.5 Implémentation de la réponse ............................................................................... 56
4.6 Registre des risques ................................................................................................ 57
5 Notion de base pour évaluer (oui).................................................................................... 58
5.1 Budget ...................................................................................................................... 58
5.2 La Charge................................................................................................................ 58
5.3 La capacité .............................................................................................................. 59
5.4 Délai ......................................................................................................................... 59
5.5 Conclusion ............................................................................................................... 59
6 Le schéma directeur (oui) 17/10/2017 ............................................................................. 60
6.1 Définition ................................................................................................................. 60
6.2 Les Niveaux ............................................................................................................. 60
6.3 Méthodologies ......................................................................................................... 61
6.4 En pratique ............................................................................................................. 61
7 Lancement d’un projet (Oui) ............................................................................................ 62
7.1 Objectifs .................................................................................................................. 62
Déterminer sa complexité................................................................................. 62
7.2 Comité de pilotage [Steering Comitee] (oui)18/10/2016...................................... 63
Sa Composition ................................................................................................ 63
Les Extensions possibles (Oui) ........................................................................ 64
Fonctionnement ................................................................................................ 64
Agenda type d’une réunion de comité de pilotage ........................................... 65
7.2.4.1 Validation du rapport de la réunion précédente ....................................... 65
7.2.4.2 Présentation de l’état d’avancement ......................................................... 65
7.3 Constitution de l’équipe (oui) ................................................................................ 70
________________________________________________________________________
_______________________________________________________________________________
Equipe ‘fournisseur’ ......................................................................................... 70

Equipe ‘client’ (oui) ......................................................................................... 72
7.4 Plan de communication (Oui)................................................................................ 73
Vers l’extérieur ................................................................................................. 73
Vers l’intérieur ................................................................................................. 73
Cas spécifique : réunion/discussion ................................................................. 74
7.5 Méthodologie/Normes/Standards (Non) ............................................................... 75
Méthodologie ................................................................................................... 75
Normes et standards ......................................................................................... 75
7.6 Assurance qualité (Oui) 25/10/2016 ...................................................................... 76
Introduction ...................................................................................................... 76
Rédaction d’un plan ......................................................................................... 76
Suivi du plan..................................................................................................... 76
7.7 Aspects organisationnels (Oui) .............................................................................. 78
Introduction ...................................................................................................... 78
Au niveau du personnel .................................................................................... 78
Au niveau du matériel ...................................................................................... 78
Au niveau du bâtiment et des locaux ............................................................... 78
7.8 Responsabilités (Oui) ............................................................................................. 79
7.9 Critères d’acceptance (Oui)................................................................................... 80
7.10 Critères d’achèvement ........................................................................................... 80
8 Planning (Oui).................................................................................................................. 81
8.1 Etablir le planning .................................................................................................. 81
Introduction ...................................................................................................... 81
Activités minimisées ou oubliées (Non) .......................................................... 83
8.1.2.1 présentation/démo .................................................................................... 83
8.1.2.1.1 Préparation ........................................................................................... 83
8.1.2.1.1.1 Activités .......................................................................................... 83
8.1.2.1.1.2 Temps .............................................................................................. 84
8.1.2.1.1.3 Ressources ....................................................................................... 84
8.1.2.1.2 Réalisation ............................................................................................ 85
8.1.2.1.2.1 Activités .......................................................................................... 85
8.1.2.1.2.2 Temps .............................................................................................. 85
8.1.2.1.2.3 Ressources ....................................................................................... 85
8.1.2.1.3 Débriefing............................................................................................. 86
8.1.2.1.3.1 Activités .......................................................................................... 86
8.1.2.1.3.2 Temps .............................................................................................. 86
8.1.2.1.3.3 Ressources ....................................................................................... 86
8.1.2.1.4 Suivi ..................................................................................................... 87
8.1.2.1.4.1 Activités .......................................................................................... 87
8.1.2.1.4.2 Temps .............................................................................................. 87
8.1.2.1.4.3 Ressources ....................................................................................... 87
8.1.2.1.5 Conclusion ............................................................................................ 87
8.1.2.2 Réunions de coordination ......................................................................... 88
8.1.2.2.1 Réunions de coordination externe ........................................................ 88
8.1.2.2.2 Réunions de coordination interne ......................................................... 88
________________________________________________________________________
_______________________________________________________________________________
8.1.2.3 Indisponibilité des ressources humaines .................................................. 89

8.1.2.4 Phase 1er suivi ........................................................................................... 89
Etablir le planning (Oui) .................................................................................. 90
8.1.3.1 Les estimations ......................................................................................... 90
8.1.3.1.1 Décomposition (15/11/2016)................................................................ 91
8.1.3.1.2 Se baser sur l’expérience du passé (personnelle ou non) ..................... 92
8.1.3.1.3 Validation ............................................................................................. 92
8.1.3.1.4 Diagramme de GANTT ........................................................................ 93
8.2 Suivi du planning (Oui).......................................................................................... 94
Introduction ...................................................................................................... 94
Informations nécessaires .................................................................................. 94
8.2.2.1 Information sous le contrôle du chef de projet ......................................... 94
8.2.2.2 Informations en possession d’autres acteurs ............................................ 95
8.2.2.3 Conclusion ................................................................................................ 95
8.3 Gestion des ressources (Non) ................................................................................. 96
Ressources matérielles ..................................................................................... 96
8.4 Ressources humaines (Non) ................................................................................... 98
8.4.1.1 Introduction .............................................................................................. 98
8.4.1.2 Au niveau du projet .................................................................................. 98
8.4.1.2.1 Avant le démarrage lui-même .............................................................. 98
8.4.1.2.2 En cours de projet ................................................................................. 98
8.5 Exemple (Non) ...................................................................................................... 100
Enoncé ............................................................................................................ 100
Approche ........................................................................................................ 101
Représentation graphique ............................................................................... 104
9 Etude préalable (Non) .................................................................................................... 105
9.1 Généralités (Non) .................................................................................................. 105
Etude préalable ............................................................................................... 105
Résultat ........................................................................................................... 105
Base de décision ............................................................................................. 105
Contenu .......................................................................................................... 106
La réalité ......................................................................................................... 107
9.2 Les différentes phases .......................................................................................... 109
Phase préparatoire .......................................................................................... 109
9.2.1.1 Activités de réalisation ........................................................................... 109
9.2.1.2 Activités de gestion de projet ................................................................. 110
9.2.1.3 Activités d’Assurance qualité................................................................. 110
Etude de l’existant (Non) ............................................................................... 112
9.2.2.1 Etape 1 .................................................................................................... 112
9.2.2.2 Etape 2 .................................................................................................... 112
9.2.2.2.1 Cas concrets ........................................................................................ 113
9.2.2.2.2 Support d’informations utiles à la gestion interne du poste de travail 113
9.2.2.2.3 Système de classement ....................................................................... 114
9.2.2.2.4 Machines utilisées .............................................................................. 114
9.2.2.2.5 Descriptif du poste de travail ............................................................. 114
9.2.2.2.6 Arrivée de nouvelles personnes dans le service ................................. 115
9.2.2.3 Etape 3 .................................................................................................... 115
________________________________________________________________________
_______________________________________________________________________________
10 Développement (Non) ..................................................................................................... 116

10.1 Introduction .......................................................................................................... 116
10.2 Les activités ........................................................................................................... 117
Analyse d’impact ............................................................................................ 117
Design détaillé ................................................................................................ 117
Coding ............................................................................................................ 118
Test unitaire .................................................................................................... 118
Assurance qualité ........................................................................................... 118
Outil de versioning ......................................................................................... 119
11 Procédure de contrôle des demandes de changement (Non) ......................................... 120
12 Sécurité (Non) ................................................................................................................ 123
12.1 Introduction .......................................................................................................... 123
12.2 Sécurité interne ..................................................................................................... 123
Les droits d’accès ........................................................................................... 123
Les copies de sauvegarde ............................................................................... 124
12.2.2.1 Introduction ............................................................................................ 124
12.2.2.2 Cas normal.............................................................................................. 124
12.2.2.3 Cas du ‘Disaster recovery’ ..................................................................... 124
12.3 Sécurité externe .................................................................................................... 125
13 Performances/Volumes (Oui) ......................................................................................... 126
13.1 Performances ........................................................................................................ 126
13.2 Volumes ................................................................................................................. 126
14 Tests (Oui) ...................................................................................................................... 127
14.1 Introduction .......................................................................................................... 127
14.2 Tests unitaires ....................................................................................................... 128
But .................................................................................................................. 128
Définition ....................................................................................................... 128
Comment ? ..................................................................................................... 128
Qui ? ............................................................................................................... 129
Quand ? .......................................................................................................... 129
14.3 Tests d’intégration................................................................................................ 130
But .................................................................................................................. 130
Définition ....................................................................................................... 130
Comment ? ..................................................................................................... 130
Qui ? ............................................................................................................... 131
Quand ? .......................................................................................................... 131
14.4 Tests fonctionnels ................................................................................................. 132
But .................................................................................................................. 132
Définition ....................................................................................................... 132
Comment ? ..................................................................................................... 132
Qui ? ............................................................................................................... 132
Quand ? .......................................................................................................... 132
14.5 Tests organisationnels .......................................................................................... 133
________________________________________________________________________
_______________________________________________________________________________
But .................................................................................................................. 133

Définition ....................................................................................................... 133
Comment ? ..................................................................................................... 133
Qui ? ............................................................................................................... 133
Quand ? .......................................................................................................... 134
14.6 Tests de non régression ........................................................................................ 135
But .................................................................................................................. 135
Définition ....................................................................................................... 135
Comment ? ..................................................................................................... 135
Qui ? ............................................................................................................... 136
Quand ? .......................................................................................................... 136
14.7 Tests ‘Fail over’ .................................................................................................... 137
But .................................................................................................................. 137
Définition ....................................................................................................... 137
Comment ? ..................................................................................................... 137
Qui ? ............................................................................................................... 137
Quand ? .......................................................................................................... 137
14.8 Tests de charge (stress tests) ................................................................................ 138
But .................................................................................................................. 138
Définition ....................................................................................................... 138
Comment ? ..................................................................................................... 138
Qui ? ............................................................................................................... 138
Quand ? .......................................................................................................... 138
14.9 Tests d’acceptance ................................................................................................ 139
But .................................................................................................................. 139
Définition ....................................................................................................... 139
Comment ? ..................................................................................................... 139
Qui ? ............................................................................................................... 140
Quand ? .......................................................................................................... 140
15 Documentation (Non) ..................................................................................................... 141
15.1 Introduction .......................................................................................................... 141
15.2 Une bonne documentation ................................................................................... 141
17 Les principales causes d’échec (Non) ............................................................................ 143
17.1 Phase de conception ............................................................................................. 143
Insuffisante maîtrise des attentes du client ..................................................... 143
Contrat à prix fixe .......................................................................................... 143
Client non préparé à assumer ses responsabilités ........................................... 144
Pas de compréhension partagée des requirements ......................................... 144
Pas de compréhension partagée de la solution ............................................... 144
Echec dans le rédaction d’un bon contrat ....................................................... 144
17.2 Phase de réalisation .............................................................................................. 145
Impossibilité de disposer de ressources qualifiées pour le projet .................. 145
Démarrage inefficace du projet ...................................................................... 145
Organisation du projet/rôles peu clairs .......................................................... 145
Project Management inadéquat ...................................................................... 146
Insuffisance de suivi du Project Management ................................................ 146
________________________________________________________________________
_______________________________________________________________________________
18 Vos projets dans le cadre du Bach Info (Non) ............................................................... 147

18.1 Projet développement WEB <> épreuve intégrée (TFE) .................................. 147
18.2 Rédaction du rapport ........................................................................................... 147
Points indispensables...................................................................................... 147
18.2.1.1 Introduction du sujet............................................................................... 147
18.2.1.2 L’existant ................................................................................................ 148
18.2.1.3 Autres points .......................................................................................... 148
Support ........................................................................................................... 149
18.3 Techniques de présentation (Non) ...................................................................... 150
Introduction .................................................................................................... 150
Analyse ........................................................................................................... 150
18.3.2.1 Pas d’improvisation ................................................................................ 150
18.3.2.2 Contenu .................................................................................................. 150
18.3.2.3 Contraintes supplémentaires .................................................................. 151
Développement ............................................................................................... 151
18.3.3.1 Outil 151
18.3.3.2 Réalisation de la présentation ................................................................. 152
Tests ............................................................................................................... 152
La Mise en Production. .................................................................................. 152
19 ANNEXES (Non) ............................................................................................................ 154
19.1 Annexe 1 : fiche signalétique ............................................................................... 154
19.2 Annexe 3: Rapport de réunion d’équipe ............................................................ 155
________________________________________________________________________
_______________________________________________________________________________
1 Introduction
1.1 Développement d’un logiciel (non)
Est-ce que l’histoire qui suit évoque quelque chose pour vous ?
En effet, le développement d’un logiciel n’est pas une chose triviale:

➢ C’est une expérience unique, jamais tentée
Sinon on réutiliserait un logiciel existant…
➢ C’est un exercice de communication avec le client business
Comprendre et se faire comprendre,
➢ Travail de création d’un produit nouveau
➢ Maitrise de différentes techniques,
➢ C’est un travail d’équipe
➢ Combiner les talents de chacun autour d’un objectif commun.
 C’est un art
________________________________________________________________________
_______________________________________________________________________________
Pour vous aider à réaliser un développement d’un logiciel :

➢ Autant profiter des leçons apprises « lessons learned »
Bénéficier des leçons de projets déjà réalisés…
➢ Appliquer les bonnes pratiques « best practices »
➢ Reproduire ce qui marche, éviter ce qui a conduit à un échec.
➢ Ne pas se lancer à l’aventure
➢ Adopter une ligne de conduite, suivre une méthode…
➢ Se mettre d’accord sur l’objectif à atteindre
➢ Comprendre les attentes, analyser le besoin, imaginer, modéliser, réaliser et valider la
solution.
L’objectif de ce cours est d’apporter au futur bachelier en informatique de gestion:

➢ Une méthode de travail
➢ Une organisation
➢ Une ligne de conduite pour le développement de projets, tout en réutilisant et en
renforçant des compétences déjà précédemment abordées ou acquises:
➢ La modélisation, appliquée à l’analyse et au design
➢ Le travail en équipe
➢ La documentation
➔Etre capable d’intégrer une équipe Projet afin d’y jouer son rôle.
________________________________________________________________________
_______________________________________________________________________________
2 Définitions (oui)
2.1 Projet
Etymologie (du latin projectum)
Préfixe « pro » qui signifie « avant »
Signifie « jeter quelque chose vers l’avant »
Projeter, c’est penser un inexistant possible, à réaliser [Jean-Pierre Boutinet]
Projet: Un projet est une « entreprise temporaire décidée dans le but de créer un produit, un
service ou un résultat unique.
Un projet est un processus professionnel limité dans le temps, et qui fédère les contributions
de ses membres pour atteindre un but.
Projet [project]:
Dans le contexte du développement d'applications informatiques, le projet est :
un regroupement de ressources (humaines, matérielles, logicielles, etc.) réalisant des activités
en vue de produire un nouveau système ou maintenir (ajouter de nouvelles fonctionnalités) un
système existant (= processus de développement), à l'intérieur d'un intervalle de temps fini.
________________________________________________________________________
_______________________________________________________________________________
2.2 Mode « Projet » <> Mode « Opération » (oui)
On oppose souvent le mode Projet avec le mode Opération alias Production:
Le Mode Opération est le temps de la vie productive du produit logiciel, celui où il est en
opération. On y retrouve des activités suivantes :
 Activité de maintenance
 Suivi
 Support
 …
Mode Projet Mode Opération càd en Production

Fournir un produit ou un service nouveau Fournir un produit ou un service connu
Equipe temporaire Equipe permanente
Unicité, complexité, incertitude élevée Répétitif, bien compris, peu d'incertitude
Date de fin et coûts totaux difficiles à prévoir Temps et coût basés sur l'expérience
Intervalle temps fini Continu
Sur une ligne du temps :
Mode Projet Mode Opération
________________________________________________________________________
_______________________________________________________________________________
2.3 Management de projet (oui)

Le management de projet [project management] est l’application de connaissances, de
compétences, d’outils et de techniques liées aux activités du projet afin d’en respecter les
exigences:
Cela comprend:
➢ Déterminer les exigences
➢ Définir des objectifs clairs et réalisables
➢ Equilibrer les exigences concurrentes de qualité, de scope, de planning et de budget.
➢ Adapter les spécifications, les plans et l’approche aux différentes préoccupations et
attentes des diverses parties prenantes.
➢
Un projet est la vision instantanée d’un processus qui vise à concrétiser son propre produit.
La conduite de projet est la maîtrise de ce processus.
Elle doit d’abord assurer la conformité du produit à ses exigences fonctionnelles et

techniques, mais pas à n’importe quel prix.
________________________________________________________________________
_______________________________________________________________________________
Le triangle de projet (oui)
PROJET
Appelé également la triple contrainte :
La conduite de projet doit en permanence adapter les paramètres (Scope, Planning et Budget)
en vue de livrer ses produits dans la qualité tel que décrite dans le cahier des charges.
La conduite de projet est une activité qui repose sur un ensemble de techniques précises et
éprouvées.
En les maîtrisant, le Chef de Projet (CdP) :
• minimise le risque d’échec
• maximise les profits souhaités de l’entreprise
• maximise la satisfaction générale
Il contribue à amener son organisation vers la qualité totale.
________________________________________________________________________
_______________________________________________________________________________
Méthodes (non)
Pourquoi une méthode ?

Il faut réfléchir avant d’agir !
Ne pas se ruer sur l’écriture de code sans "analyser" ni "concevoir ».
Apports d'une méthode

 Un vocabulaire commun à ceux qui l'appliquent
 Une façon de faire et donc répétable à souhait
 Un fil rouge pour piloter le processus de développement
 Favorise la créativité en se débarrassant de certaines tâches organisationnelles
 Nécessite un investissement en "temps" à la première application
Soit une "perte" de temps pour en gagner ensuite …
 Mettre en œuvre des « bonnes pratiques » pour réduire les risques et augmenter la
prédictibilité.
Différentes méthodes de « project management »

Ils existent plusieurs, mais deux d’entre elles ont actuellement tendance à s’imposer et
dominer le marché.
 PMI – Project Management Institute
Origine: US (www.pmi.org)
Livre: PMBoK, Project Management Body of Knowledge ®
 Prince2 – PRoject IN Controlled Environment 2

Origine: UK (OGC – Office of Government Commerce)
Livre: Managing Successful Projects with PRINCE2 ™
________________________________________________________________________
_______________________________________________________________________________
2.4 Le Projet au « centre » (oui) – 17/09/2017
Tolérance sur la Revenus

Qualité des Théoriques
Produits 0..* «€»
Génère >
Cahier des 1..* Produits

Clients Soutien >
0..* Charges Théoriques
Produits
Temps - Délai
Produits
Projet Livre >
0..* Livrés
Planning Génère >
Qualité des Revenus Réels

Produits Livrés 0..* «€»
Moyens « € »
Moyens Moyens Ressources

Techniques Logistiques Humaines
Ressources Ressources
Serveur de Poste de
Autres Sales Autres Humaines Humaines
Documentation Développement
Internes Externes
________________________________________________________________________
_______________________________________________________________________________
2.5 Les différents niveaux (oui)
ECONOMIQUE SOCIAL
€ CHANGEMENT
Projet informatique
TECHNIQUE ORGANISATIONNEL
RESSOURCES
HUMAINES
FIGURE 1 : Les 5 niveaux
Niveau économique €
Développer une nouvelle application a un coût. Si une entreprise décide d’y consacrer des
moyens c’est parce qu’elle compte bien en retirer un bénéfice.
Le bénéfice peut se mesurer aussi bien en termes d’économie que de gain.
Le gain n’est pas toujours directement chiffrable. Il peut s’agir d’un gain qualitatif dans un
premier temps, dans l’espoir de le voir se concrétiser en chiffres ultérieurement.
ROI ➔ Return On Investissement
Exemple :
1 application qui coûte 100.000€ au niveau du budget

15000€ de maintenance annuel
40000€ de revenu annuel généré
________________________________________________________________________
_______________________________________________________________________________
ROI : 100000/ (40000-15000)= 4 ans
________________________________________________________________________
_______________________________________________________________________________
Niveau social
Impact du CHANGEMENT sur le personnel lié aux nouveautés
Une nouvelle application est souvent à l’origine d’inquiétude, d’incertitude d’une partie du
personnel. Tout changement a un effet déstabilisateur. Ceci est également vrai pour une
nouvelle application.
Attention : ceci ne s’adresse pas uniquement aux services autres qu’informatique.

L’introduction de nouveaux outils, de nouveaux langages, de nouveaux modes de
raisonnement peut également s’adresser aux informaticiens (ex : passage à une DB
relationnelle, au langage orienté objet).
Niveau organisationnel
L’organisation de l’entreprise, en tout ou en partie, sera plus ou moins impactée par une
nouvelle application.
Exemple 1 :
En matière administrative, le fait de réduire fortement l’utilisation de papier comme support
va bouleverser des services entiers dont l’activité principale était l’édition, mise sous
enveloppe, classement, recherche de toute une série de documents
Ex : déclaration multifonctionnelle par Internet : communiquer 1 seule fois les informations

valables pour différents organismes
Exemple 2 :
Centralisation/ Décentralisation des services
 Impact sur la délocalisation du personnel.
Niveau technique
La technique évolue constamment dans le monde informatique. Une nouvelle application
peut être l’occasion d’implémenter dans une entreprise des évolutions plus ou moins majeures
que ce soit en termes d’outils, de langages, d’architecture, de base de données,
d’infrastructure.
Exemple :
Vivre dans son temps en exploitant les nouveautés techniques qui permettent de créer de
nouveaux services (Bancomat)
Création de http ➔ création de site WEB qui permet d’accéder à une application centralisée à
travers différents terminaux à travers le monde entier
________________________________________________________________________
_______________________________________________________________________________
C’est une opportunité d’automatiser différents services
Niveau des ressources humaines

Une application est rarement neutre sur ce sujet. Comme déjà évoqué dans les points ci-
dessus, un nombre plus ou moins grand de personnes dans un ou plusieurs services vont
connaître des situations diverses qui nécessitent une prise de conscience et des actions de la
part des personnes responsables.
On peut évoquer les cas suivants :

- disparitions de fonction
- formations nécessaires (en interne, en externe)
- pas de formation nécessaire parce que maintien dans des technologies toujours
utilisées mais plus anciennes
- recrutement de nouveaux profils
________________________________________________________________________
_______________________________________________________________________________
2.6 Un nombre important de situations

différentes (oui)
Différents types de situation peuvent se présenter
- conception ‘pure’ : activité inexistante/pas de logiciel existant
- conception sur base d’une activité existante peu ou pas du tout informatisée
- conception sur base d’une activité existante informatisée
- conception comprenant le recours ou non à des logiciels existants
- conception nécessitant des interfaçages avec des systèmes existants
- conception dans un cadre matériel et/ou logiciel imposé
- présence ou non de documentation préalable
- demandeurs disponibles et motivés
- timing limité ou moins
- éducation des interlocuteurs
- moyens de communication (existants ou à mettre en place)
Ces différentes situations sont toutes liées à des aspects variables dans le temps.
Par contre, ce qui ne change pas c’est le fait qu’une application informatique réponde à un
besoin.
Le succès du développement d’une application informatique dépend de beaucoup de

paramètres mais il y en a un qui conditionne tous les autres :
Obtenir dès le départ les réponses à des questions clés
- quel est le but de cette application ?

- quel est le temps prévu pour la réaliser ?
- quel est le budget disponible ?
- quelle est la technologie à mettre en œuvre ?
Ces 4 questions permettront de déterminer rapidement la maturité du projet sur les 3

dimensions fondamentales :
- le contenu (but et technologie)
- le temps
- le coût
________________________________________________________________________
_______________________________________________________________________________
2.7 Le cycle de vie d’une application

Informatique (oui)
Processus de développement
Un processus de développement [development process] est un ensemble d’activités réalisées
par une équipe pour transformer un ensemble d’exigences du client en un produit logiciel.
Cela définit:
 Qui fait quoi, quand et comment pour atteindre un certain objectif ?
Les grandes phases

Une application passe par différentes phases :
- la conception (design)
- la réalisation (développement)
- la livraison (delivery)
CONCEPTION REALISTION LIVRAISON

Design Developpement Delivery
2.7.2.1 La conception (DESIGN)
La conception est la partie qui reprend toutes les étapes de réflexion nécessaires et préalables
avant de se lancer dans le développement proprement dit.
Il s’agit donc d’avoir suffisamment balisé le cadre du projet ➔ périmètre ou scope :

 Décrire l’objectif du projet ➔ finalité
 Décrire les contraintes de temps
 Décrire les contraintes budgétaires
 Choix des techniques utilisées
Faite valider des choix organisationnels, techniques, fonctionnels de façon à pouvoir se lancer
dans la réalisation.
Dans cette phase, il y a une importante nécessité d’échanges et de communication avec le

client et l’utilisateur principale.
________________________________________________________________________
_______________________________________________________________________________
De manière plus concrète, cela signifie se sentir assez à l’aise que pour être capable de signer
un contrat à prix fixe (= sur base d’un devis).
2.7.2.2 La réalisation (DEVELOPPEMENT)
Il s’agit ici, sur base des informations recueillies, de concrétiser la demande du client.
Attention, ceci n’exclut nullement que de l’analyse soit encore nécessaire. Mais celle-ci se
fera dans un cadre défini sur base de règles préalablement acceptées par le client (voir Gestion
des demandes de changement).
2.7.2.3 La Livraison (DELIVERY)
Il s’agit de mener toutes les actions utiles pour implémenter la solution en production.
Exemple :
➢ Formation du personnel
➢ Installation des logiciels
➢ Accompagnement des premiers pas de vos utilisateurs à l’utilisation de la solution
➢ Création de support de formation – de procédures d’utilisation
2.7.2.4 Superposition des 3 phases
Les trois phases ne doivent pas se succéder en mode séquentiel.

La phase de réalisation du projet peut démarrer alors que la phase de conception n’est pas
encore terminée.
De même la phase de livraison peut également démarrer alors que le projet n’est pas encore
terminé..
Ligne du temps
CONCEPTION
Design
REALISTION
Developpement
LIVRAISON
Delivery
________________________________________________________________________
_______________________________________________________________________________
La maintenance (oui) – 19/09/2017

Lorsque l’on parle de maintenance, il faut distinguer 2 choses bien différentes :
- la maintenance corrective (Bug)
- la maintenance évolutive (Nouveaux besoins)
- Refactoring
La maintenance corrective correspond à la correction d’erreurs,

soit parce que le programme ne s’exécute pas correctement (➔ bug),
soit parce que le programme, bien que fonctionnant correctement, ne correspond pas aux
spécifications (➔ mauvaises compréhension des besoins).
La maintenance évolutive, elle, a pour but de maintenir l’application en phase avec

l’évolution de l’activité. Elle peut être volontaire ou imposée.
La fréquence et l’importance de la maintenance dépendent totalement de la vitesse
d’évolution du système d’informations.
Une entreprise dont l’activité est stabilisée aura un système d’information à évolution lente.
Ceci rendra d’autant plus facile une informatisation importante des activités.
Par contre, une entreprise soumise à un environnement perturbé, dont l’activité est en
constante adaptation, aura un système d’information à évolution rapide. Ceci va engendrer
des opérations de maintenance quasi continuelles. La conséquence sera soit une limitation de
l’informatisation de l’entreprise soit à concevoir des systèmes d’informatisation « jetables ».
Les maintenances évolutives peuvent être imposées ou volontaires

Par imposée, on entend la maintenance imposées par de nouvelles obligations légales ou
l’obligation de passer à une nouvelle release d’un logiciel.
Par volontaire, on entend le souhait de la direction de l’entreprise
exemple : une compagnie d’assurance qui lancer un nouveau produit.
CONCEPTION REALISATION LIVRAISON

Design Developpement Delivery
MAINTENANCE
________________________________________________________________________
_______________________________________________________________________________
3 Projets (oui) – le 20/09
3.1 Les trois axes
Axe « Développement » :
Il décrit les différentes phases d’un développement informatique
Axe « Abstraction » :
Il indique le niveau d’abstraction du projet.
Plus l’ordonnée est haute, plus grande est l’abstraction.
Plus l’ordonnée est faible, plus le niveau de détail est élevé.
Axe « Pilotage » :
On y représente les Aléa, les points de contrôle, les prises de décision.
Il s’agit de l’axe de pilotage du projet.
Pour réaliser le produit attendu, il ne faut pas négliger aucun de ces trois axes.
Si on néglige l’axe de développement ?

On obtiendra une application :
• non réalisable techniquement
• déployée en production sans être suffisamment validée
• ..
________________________________________________________________________
_______________________________________________________________________________
Si on néglige l’axe « Abstraction » ?

On obtiendra une application qui
• rencontre pas ou partiellement les besoins
• pas adaptée au mode « Opération »
• inutilisable sur le terrain
• …
Si on néglige l’axe de Pilotage ?

On obtiendra une application qui
• a couté plus chère que budgétisé
• Choix non conforme à l’ambition de l’entreprise
• Conduite de changement non intégré dans la solution
• …
________________________________________________________________________
_______________________________________________________________________________
3.2 Deux Rôles Clés (oui)
Maîtrise d’Ouvrage (MOA)

Le MOA est chargé de gérer l’aspect fonctionnel du projet. (donc le scope)
Il est le responsable de la définition du/des produit(s) que le projet doit livrer.
Ses responsabilités résident dans :

 la définition des besoins
 la validation des produits livrés
 la validation de changements de spécifications
Il représente le « Client » et surtout l’ « Utilisateur Principale ».
Maîtrise d’Œuvre (MOE)

Le MOE regroupe les analystes, les développeurs les architectes techniques.
Elle est chargée d’
 écrire les spécifications détaillées
 réaliser les codes
 réaliser les tests unitaires et d’intégration
 livrer les produits demandés
Le maître d’œuvre est donc le « Fournisseur » du projet.
________________________________________________________________________
_______________________________________________________________________________
3.3 Les modèles de développements (oui)
Les disciplines dites « d’ingénierie »

On dénombre généralement 5 disciplines principales intervenant dans un projet de
développement:
➢ L’analyse business [Business analysis]
➢ L’analyse fonctionnelle [Functional analysis]
➢ La conception [Technical design]
➢ L’implémentation [Implementation]
➢ Les tests [Testing]
3.3.1.1 L’analyse business [business analysis]

L’analyse business encadre la réception et la formalisation de la demande de l’ »utilisateur
principale » pour :
➢ Comprendre et capturer le besoin business,
➢ Exigence business [Business requirements]
➢ Processus business [Business processes]
➢ Le positionner dans son contexte (par exemple, la stratégie qui en est à l’origine),
➢ Identifier les principales « parties prenantes » du projet:
➢ Le sponsor business (le client),
➢ Le coordinateur business (son représentant au jour le jour),
➢ Les utilisateurs finaux, des tiers éventuels, etc.
➢ Etablir un premier planning (peu détaillé) tel qu’il est souhaité.
3.3.1.2 L’analyse fonctionnelle [functional analysis]

L’analyse fonctionnelle est la description formelle de comment le futur produit va se
comporter.
➢ On utilise le concept de cas d’utilisation [use-case]:
Un use-case est une histoire qui raconte au lecteur comment le produit va être utilisé
pour réaliser un objectif ou une fonction particulière
➢ Les use-cases sont structurés en des séquences d’événements qui prises dans leur
ensemble, vont conduire le système à faire quelque chose d’utile.
Une analyse fait appel à la modélisation, le plus souvent au moyen du langage UML et/ou de
Merise
3.3.1.3 La conception [technical design]

Le design technique vise à définir :
➢ comment le produit logiciel va se structurer
➢ identifier ses principaux composants
➢ comment ils interagissent les uns avec les autres
________________________________________________________________________
_______________________________________________________________________________
Nous allons y retrouver des activités liées à :

➢ Modélisation des données
➢ Accès aux données et la persistance de celles-ci
➢ Interfaces, protocoles, middleware
➢ Technologie et composants techniques ou frameworks, éventuels…
➢ Modèle de navigation dans la présentation, design de l’interface utilisateur, …
➢ Modèle de sécurité.
3.3.1.4 L’implémentation [implementation ou coding]

C’est la construction du produit logiciel proprement dit:
➢ Mise en place du design à un échelon plus détaillé
➢ Réalisation de la Programmation et tests unitaires par les développeurs eux-mêmes
➢ Révision ou relecture croisée du code
➢ Refactorisation
➢ …
3.3.1.5 Les tests fonctionnels [functional testing]

Les tests fonctionnels visent à valider:
➢ la bonne intégration des différents composants les uns par rapport aux autres.
➢ La bonne intégration de l’application produite dans ses interfaces de et vers
l’extérieur.
➢ La réalisation correcte de ce qui est décrit dans les use-cases.
➢ L’adéquation du produit délivré avec les exigences business qui ont été définies.
➢ La non-régression de fonctionnalités existantes ou délivrées antérieurement en cas de
nouvelle version.
3.3.1.6 Les autres activités ???

Bien entendu il existe d’autres disciplines dites de « support » qui sont tout aussi importantes:
➢ La gestion des releases [Release management]
➢ Le déploiement [Deployment]
➢ La gestion du projet [Project Management]
➢ Configuration & gestion du changement [Configuration & Change Management]
➢ Etc…
________________________________________________________________________
_______________________________________________________________________________
3.3.1.7 Les proportions de « Charge » sur les 5 disciplines (oui)
Comme chaque projet est unique, il n’y a pas de norme de charge définie.
Pour démarrer une planification du projet cohérente, nous pouvons partir de cette clé de
répartition de charge.
Clé de répartition des charges par phase

Gestion du Projet
15% 15%
Analyse Business
10% Analyse Fonctionnelle

15% La Conception
L'implémentation
Tests Fonctionnelles
Les autres activités
30% 15%
Les charges pourront évoluer par la suite tout le long du projet suivant les particularités du
projet.
________________________________________________________________________
_______________________________________________________________________________
Le modèle « en chûte d’eau » [Waterfall]

(Oui)
Ce modèle est aussi appelé :
➢ modèle « cascade »
➢ modèle « linéaire »
➢ modèle « nominal »
Modèle historiquement le plus généralisé.
Cette approche a pour idée fondamentale que les étapes se suivent de manière chronologique,
sans se recouvrir et sont faites une fois pour toutes.
 Les actions sont effectuées chronologiquement en séquence.
 Chaque étape suit la précédente, sans autre nécessité que d’attendre son issue.
 Aucune étape n’est traitée parallèlement aux autres.
Business
Analyst
Fonctionnal
Analyst
Technical
Analyst
Code
Implementation
Test Installation
Déploiement
Ligne du temps
Avantage:
On part sur des spécifications solides, et chaque étape ultérieure peut s’appuyer complètement
sur la précédente.
 Le niveau d’incertitude est réduit étape par étape.
 La planification est relativement aisée.
________________________________________________________________________
_______________________________________________________________________________
Critiques:
➢ Presque impossible à appliquer en pratique dans des projets complexes.
Beaucoup d’aspects se découvrent ou s’affinent à postériori.
➢ Manque de souplesse :
Il est extrêmement difficile de fixer de manière exhaustive toutes les spécifications
nécessaires dès le départ du développement du produit logiciel.
➢ Le temps nécessaire avant de pouvoir entamer le développement réel et donc de

pouvoir montrer un résultat concret au client et à l’utilisateur principale est long.
➢ Effet « tunnel », un long temps s’écoule sans rien voir, avant de découvrir le résultat.
Entre-temps, les besoins ont peut-être changés…!
➢ Une erreur, un oubli d’une spécification découverte dans la phase d’implémentation

coutera 10x plus chère que s’il avait été décrit au départ.
Une erreur, un oubli d’une spécification découverte dans la phase de Test-Installation
coutera 100x plus chère que s’il avait été décrit au départ:
➢ Plus en phase avec les besoins d’entreprise moderne qui doivent constamment adapter
leurs produits
________________________________________________________________________
_______________________________________________________________________________
Le modèle « en V » (Non)
Dans le modèle en cascade, les phases de validation sont finalement extrêmement éloignées
des phases de spécifications.
Chaque personne impliquée dans la réalisation du projet se trouve piégée
Au lieu de différé au maximum les tests fonctionnels, le cycle en V les anticipe en déroulant
le processus de telle manière que ces tests sont réalisés en parallèle sur « Papier » de manière
vituelle.
Condition de réussite :
➢ La sous-traitance des tests pour être plus objectif et éviter d’être « juge et partie »
En terme de charge, le coût du projet suivi par le modèle en V est de 30% à 40% plus
couteux que le même projet suivi par le modèle en Cascade.
➢ L’anticipation des tests sur papier est une charge supplémentaire.
Avantage:
➢ Réduit l’effet « Tunel » mais ne le supprime pas complètement
➢ Détection plus rapide des manques de spécifications
➢ Réduit le cout de développement des erreurs et d’oubli de spécifications
➢ Implication d’une autre personne pour valider (consolide les spécifications)
Inconvénient:
➢ Coût de base plus élevé
➢ Allonge la durée de livraison
➢ Difficile à appliquer (plusieurs ressources disponibles)
________________________________________________________________________
_______________________________________________________________________________
Les modèles « Itératifs » dit AGILE (Oui)

Le principe est de découper le besoin global en petits modules qui pourront être développés et
livrés au fil de l’eau.
Cette approche essaie de répondre aux inconvénients de l’approche waterfall & modèle en V.
Si les étapes de l’approche « waterfall » sont toujours bien présentes, par contre, il n’est plus
question de les réaliser une seule fois mais de réaliser des cycles.
➢ 1 cycle reprenant chacune de ces 5 étapes.
➢ 1 cycle s’appuye sur le précédent.
Les modèles itératifs sont des modèles dont l’objectif est :

➢ Supprimer l’effet « Tunel »
➢ Livrer les produits au fil de l’eau
de livrer au plus tôt des produits en cours de construction
➢ Souplesse dans l’évolution des produits et donc des besoins fonctionnels
Avantages
Il n’est plus besoin de devoir tout connaître et tout décrire avant de commencer le design.
Des résultats sont plus rapidement disponibles pour le client.
Des validations partielles du système auront lieu et pas une seule, tout à la fin.
Inconvénients
L’insécurité est plus grande
________________________________________________________________________
_______________________________________________________________________________
3.3.4.1 Modèle RAD « Rapid Application Developement »

Ce modèle fonctionne sur le principe de l’exploration fonctionnelle avec une prédominance
du maquetage graphique.
Ce modèle est fortement utilisé pour développer des POC « Proof of Concept »
Si le POC est approuvé, on passe à la phase de développement de la solution globale.
Cette approche consiste à produire un modèle réduit du système final.

Ceci signifie donc que le prototype possède toutes les fonctionnalités du système final.
Le mot ‘prototypage ‘ est souvent utilisé erronément. Il s’agit dans ce cas de maquette,
càd une image visuelle relativement proche de tout ou partie du système futur mais qui
reprend peu ou pas du tout des fonctionnalités.
Le maquettage est un outil puissant de communication, mais il ne faut pas en abuser.

Il ne doit pas être utilisé comme premier moyen d’établir les besoins du client mais bien
comme un moyen de validation.
Le côté visuel est extrêmement important.

Il permet au client de se rendre compte de ce qu’il aura comme interface.
Il s’agit réellement de mettre des images sur des mots.
Avantages
Moyen puissant de communication.
Il permet au client de visualiser rapidement le résultat final.
Inconvénients
Il y a un risque important que le client pense que tout est déjà pratiquement réalisé et ne
comprenne pourquoi il subsiste encore un si long laps de temps avant de pouvoir disposer de
l’application.
________________________________________________________________________
_______________________________________________________________________________
3.3.4.2 Modèle XP « eXtrem Programming » 26/09/2017
XP est une méthode « AGILE » basée sur le bon sens.
XP est basé sur 4 variables :
La qualité est une variable fixe, qui contrairement aux autres, ne peut varier avec le temps.
Elle se veut être continuellement optimum.
L’étendue de l’application, le nombre de fonctionnalités développés, dépend du budget et du

temps alloué par le client.
Les principes :
1. Livraisons fréquentes :
via le découpage de l’application en différents modules qui sont livrés à un rythme
régulier (= itération)
2. Rythme de travail constant & durable
3. Utilisateur Principale/Maître ouvrage/Utilisateur sur site de développement

pour répondre directement au questionnement des développeurs et réduire les pertes de
temps. Il est également le responsable de la qualité des produits livrés.
4. Conception simple
« Développez de façon la plus simple possible pour répondre correctement au besoin »
5. Règle de codage
Définition de norme et de bonne pratique pour rendre homogène le code afin de
gagner en performance et en qualité.
6. Nommage parlant
Le nom des classes, attributs, méthodes doit être compréhensible par tous
7. TDD Test Driven Developement

Développement piloté par les tests.
________________________________________________________________________
_______________________________________________________________________________
Avant l’encodage, le développeur doit rédiger deux cas de test :

1 causant une erreur
1 réalisant correctement la demande
Ces tests sont conservés et rejoué à chaque itération pour valider la non régression du
code.
8. Tests de Recette
Réalisation des tests fonctionnels par les analystes ou client à chaque itération de
l’application. Le déploiement est réalisé s’il n’y a pas de régression détectée.
9. Itération Continue
10. « Refactoring de Code »

Remaniement du code régulièrement afin de le rendre plus fiable
11. Programmation par Binome « Driver et le Parner »

Travaille par binôme « mixité Expert et Débutant »
12. Estimation via Planning POKER

Estimation de la charge par les développeurs via un jeu de cartes appelé « Planning
Poker ».
Le Cycle :
Client Développeur(s)
Définition des Transition

scénarii d’architecure
Définition des Conception

Tests d’une nouvelle
d’acceptance version
Production de la
Tests
version
Nouveau
Scénarii ?
________________________________________________________________________
_______________________________________________________________________________
3.3.4.3 Modèle « Rational Unified Process – RUP » (3/10/2017)
3.3.4.3.1 Historique
Le Processus Unifié (UP) :
Cadre méthodologique général de processus de développement, extensible, c’est à dire qu’il
peut être adapté par les entreprises.
La publication originale date de 1999 par Ivar Jacobson, Grady Booch et James Rumbaugh –
les mêmes auteurs qu’UML.
La plus célèbre adaptation en a été faite par Rational, c’est le Rational Unified Process (RUP).
UP est vu comme le complément d’UML.
3.3.4.3.2 Principales caractéristiques

UP se caractérise par quatre grands paradigmes. On dit d’UP qu’il est:
1. Itératif et Incrémental [Iterative and Incremental]

Le projet est découpé en itérations identiques de courte durée (environ 1 mois) qui aident à
mieux suivre l’avancement global.
A la fin de chaque itération, une partie exécutable du système final est produite, de façon
incrémentale.
________________________________________________________________________
_______________________________________________________________________________
2. Conduit par les cas d’utilisations [Use Case driven]

Le projet est mené en tenant compte des besoins et des exigences des utilisateurs.
Les cas d’utilisations du futur système sont identifiés, décrits avec précision et priorisés.
3. Centré sur l’architecture [Architecture Centric]

Tout système complexe doit être décomposé en parties modulaires afin de garantir une
maintenance et une évolution facilitées.
Cette architecture (fonctionnelle, logique, matérielle, …) doit être modélisée en UML et pas
seulement documentée en texte. ➔ via le diagramme de Package
________________________________________________________________________
_______________________________________________________________________________
4. Piloté par les risques [Risk Focused]

Les risques majeurs du projet doivent être identifiés au plus tôt, mais surtout levés le plus
rapidement possible.
Les mesures à prendre dans ce cadre déterminent l’ordre des itérations.
5. Les quatre phases :

UP divise donc le temps en petites itérations, chacune résultant en un incrément.
Les itérations se structurent dans le temps en quatre phases successives qui rythment
l’avancement du projet:
1. Phase 1 : Inception [inception]

Objectif :
Life-Cycle Objectives = accord sur les spécifications et la rentabilité du projet.
Comment ?
Phase de démarrage du projet, elle doit établir la viabilité du system proposé:
➢ Définir le scope (ce qui en fait partie, ce qui n’en fait pas partie), et les exigences et
processus « haut niveau » du business.
➢ Esquisser une ébauche d’architecture.
➢ Identifier les risques critiques et quand les atténuer.
➢ Démarrer un « business case »:
Estimer le coût, l’effort, le calendrier…
________________________________________________________________________
_______________________________________________________________________________
➢ Valider l’intérêt de faire le projet.
2. Phase 2 : Elaboration [elaboration]

Objectif :
Life-Cycle Architecture = L’essentiel de l’analyse est faite + l’essentiel de l’architecture est
en place.
Comment ?
Etablir la capacité à construire le système dans le périmètre des contraintes (fonctionnelles,
financières, calendrier, …) issues des objectifs:
➢ Capture détaillée des spécifications fonctionnelles et non fonctionnelles.
➢ Analyse fonctionnelle du produit à développer.
➢ Modélisation d’une architecture détaillée du système.
➢ Atténuer les risques les plus significatifs (ex: « proof of concept » = prototype)
3. Phase 3 : Construction [construction

Objectif :
Initial Operational Capability = Système complet déployé en pré-production et accessible à un
sous-ensemble d’utilisateurs « beta ».
Comment ?
Construire un système capable d’opérer dans un environnement de pré-production.
➢ Phase ou l’approche itérative et incrémentale est la plus critique pour faire ne sorte
que le système reste dans une forme exécutable évidente et accessible pour éviter
l’effet « tunnel ».
4. Phase 4 : Transition [transition]

Objectif :
Product release = Système complet disponible en production et productif.
Phase finale du projet, elle doit déployer le système complètement fonctionnel en production
pour les utilisateurs.
Comment ?
➢ Tests d’acceptance.
➢ Correction des défauts ou des incohérences non-encore identifiées.
➢ Double circuit, pilote, …
________________________________________________________________________
_______________________________________________________________________________
En synthèse :
Phase Produit
La phase d’inception Activité lié à la Conception du produit
Cahier des charges - Analyse Métier
La phase d’élaboration Analyse fonctionnel & Design
La phase de construction Développement

Test
Documentations
La phase de transition Livraison du produit.
Constitution de la release qui contient les nouveaux
développements
Formation des utilisateurs
Accompagnement en production des premier pas de
l’application
La plupart des itérations incluent des activités de différentes disciplines :

analyse business, analyse fonctionnelle, design, implémentation, testing, etc.
La charge de travail relative des quatre phases dans un projet typique.
________________________________________________________________________
_______________________________________________________________________________
________________________________________________________________________
_______________________________________________________________________________
Le cycle de vie logiciel

En toute généralité, un projet peut lui-même être vu comme une simple étape de la vie du
produit logiciel,
L’étape entre la mise à disposition de deux versions successives du produit aux utilisateurs.
Un projet représente alors un cycle, dans le cycle de vie du logiciel [software life-cycle].
Les projets successifs conduisent à délivrer une version 1.0, 2.0, 3.0… du produit logiciel.
Les jalons du projet

Puisque les activités des différentes disciplines chevauchent les quatre phases…
Comment définir l’objectif à atteindre pour accomplir une phase ?
Chaque phase se clôture par l’atteinte d’un jalon [milestone].
Un jalon se définit par la production d’un certain nombre de livrables.
Les livrables obtenus à chaque jalon constituent les artéfacts du projet.
________________________________________________________________________
_______________________________________________________________________________
3.3.4.4 SCRUM (Oui)
Scrum (melée) est avant tout basée sur la cohésion d’équipe et les relations humaines
________________________________________________________________________
_______________________________________________________________________________
3.3.4.4.1 Principes :
➢ La qualité au centre
➢ Maîtrise des coûts et des délais
➢ Equipe auto gérée et responsabilisée - Pas de relation hiérarchique
➢ Privilégie la CO Responsabilité
➢ Usage de Post-it
Ecriture des besoins sur une étiquette
________________________________________________________________________
_______________________________________________________________________________
➢ Priorisation des besoins

➢ Limiter la quantité de travail (maîtrise de la capacité de l’équipe)
➢ Livraisons fréquentes et régulière.
Rythme connu et fixe des Sprints (exemple : 3,4 semaines)
➢ Utilisation du planning poker pour évaluer la charge
3.3.4.4.2 User Stories [US] :

Ne pas confondre une US et des diagrammes UML.
Canevas d’une US :
En tant que …. Je peux Afin de ….
Exemple :
En tant que client de la banque je peux réaliser des versements afin de gérer mes comptes.
En tant qu’utilisateur, je peux consulter la liste de film afin de connaître les nouveautés.
« SCRUM préconise l’utilisation de document plutôt que des diagrammes UML. »
La règle des « 3 C » :
Carte une US doit être rédigée sur une carte, post-it de 8CM/5CM
Conversation Une US doit déclencher une conversation entre utilisateurs
Confirmation la confirmation d’une US est réalisée via les tests d’acceptation
________________________________________________________________________
_______________________________________________________________________________
La qualité passe par « INVEST »
I Indépendant Minimiser les dépendances inter US

N Négociable Une US n’est pas figée dans le temps. Il ne faut pas y mettre
tous les détails
V Valeur chaque US a une valeur ajoutée pour les utilisateurs « Business
Value »
E Estimable l’équipe SCRUM doit pouvoir l’estimer
S Succinct la description d’une US doit pouvoir être rédigée en quelques
mots
T Testable les tests d’acceptation doivent être rédigés pour valider une US
3.3.4.4.3 L’équipe :
Le Product Owner :
Il est le responsable du produit.
Il représente les utilisateurs, le client.
Il gère le Portefeuille Produit ➔ Backlog Produit.
Il priorise les besoins à fournir.
Il gère le plan de Release
Il valide les résultats du Sprint.
Le Scrum Master :
Il est le facilitateur de l’équipe.
Le scrum master n’est pas un chef de projet.
Il s’assure que la méthode « scrum » est respectée.
Il est garant que l’équipe est fonctionnelle et productive.
Il anime les réunions composant le cérémonial Scrum :
➢ Planification de Sprint (phase de préparation de Sprint)
➢ Le « Daily Scrum »
➢ La revue de Sprint (en fin de Sprint)

➢ La rétrospective de Sprint (en fin de Sprint)
________________________________________________________________________
_______________________________________________________________________________
L’équipe de réalisation :
Equipe qui rassemble toutes les compétences utiles pour concrétiser le développement d’un
besoin.
➢ Analyste Fonctionnelle
➢ Analyste Technique
➢ Programmeurs
➢ Testeurs
3.3.4.4.4 Sprint :
C’est une période pendant laquelle toute l’équipe projet est concentrée sur le développement
(au sens large) des user stories planifiées dans le sprint en cours.
C’est en général une période constante de 3 à 4 semaines calendrier.
Le Sprint est suivie d’une semaine dite « Inter Sprint » pendant laquelle les développements
réalisées par l’équipe projet sont rassemblées en vue finaliser la version qui pourra être
déployée en production à condition que la version soit validées par les différents tests
fonctionnelles ainsi que les tests de non régression.
Pendant la semaine d’inter sprint, nous retrouvons deux réunions :
1) La réunion de clôture de sprint
2) La réunion d’ouverture du sprint suivant
La capacité du sprint est le nombre de Jours/Homme que l’équipe projet dispose pour réaliser
les activités de développement des users stories assignée au sprint
La capacité du Sprint est déterminée par le SCRUM Master.
Exemple du calcul de capacité d’un sprint :
Calculez la capacité du sprint x qui commence le 7 Novembre 2016 :

• Un Sprint dure 4 semaines et elle est suivie d’1 semaine d’inter sprint.
• Votre équipe se compose de 4 personnes (Pierre, Jacques, Arthur et Julie)
• Tous sont temps plein excepté Pierre qui est à 4/5. Il ne travaille pas le vendredi.
• Arthur et Jacques sont est en formation du 09 au 10 Novembre inclus
• Julie est en congé du 07 novembre au 10 novembre inclus
• Le 11 novembre est un jour férié et l’entreprise est don fermée.
• Les WE l’entreprise est fermée.
Voici le calendrier du mois de novembre et de décembre 2016 :
________________________________________________________________________
_______________________________________________________________________________
1 2 3 4
07-nov 14-nov 21-nov 28-nov total
pierre 4 4 4 4 16
Jacques 2 5 5 5 17
Arthur 2 5 5 5 17
Julie 0 5 5 5 15
total 8 19 19 19 65
La capacité du sprint est de 65 J/H
Quelle est la date de début du prochain sprint ?

Le Sprint en cours se terminera le vendredi 2 décembre.
La semaine du 5 décembre sera consacrée à l’InterSprint.
Le prochain SPRINT commencera donc le lundi 12 décembre.
3.3.4.4.5 Planning Poker :

➢ Utilisation du planning Poker pour évaluer la charge d’une user storie.
Basée de la suite de FIBONACCI (adaptée)
________________________________________________________________________
_______________________________________________________________________________
3.3.4.4.6 Burn Down Chart :

C’est un graphique qui montre au quotidien l’état d’avancement des points d’effort à réaliser
dans le Sprint.
P
o
i
n
t
s
Courbe réelle
E
f Courbe idéale
f
o
r
t
s
Jour du Sprint
Le Scrum master est en charge de le produire au quotidien.

Un point d’effort est déduit de la découpe en tâche d’une « user storie ».
Le calcul de la vélocité du sprint en cours :

Phase 1 : calculer les ressources réelles disponibles pour le sprint
Phase 2 : calcul du coefficient de focalisation (du sprint précédent)
Le pourcentage de vélocité =
Nombre de tache réalisée / Nombre de jour homme disponible
Phase 3 : calcul de la vélocité estimée du sprint à venir :
= Nombre de J/H disponible * le coefficient de focalisation
➢ Nombre de tâches qui sera réalisée pendant le Sprint
________________________________________________________________________
_______________________________________________________________________________
4 Les risques (oui) le 23/02/2021

Un risque est un événement ou un ensemble d’événements, qui, s’il se produisait, affecterait
la réalisation des objectifs.
Un risque se mesure en combinant :
➢ la probabilité de survenance
➢ l’ampleur de son impact sur les objectifs
OBJECTIF: identifier, évaluer et contrôler les incertitudes sur les différentes variables :
→ Augmente la probabilité de réussite du projet
Stratégie de risque = attitude de l’organe de décision « Comité de Pilotage » vis-à-vis de la

prise de risque
________________________________________________________________________
_______________________________________________________________________________
4.1 Techniques d’identifications

Techniques d’identification des risques:
➢ Lessons learned: revoir des projets similaires qui ont eu lieu pour en capturer
l’expérience.
➢ Check-list: liste de risques courants (dans l’entreprise, le secteur, des projets
similaires) à parcourir.
➢ Brainstorming: réflexion de groupe où la perception de chaque participant est stimulée
pour une prise en compte de la vue de chacun.
➢ Risk breakdown structure: Décomposition hiérarchique de l’environnement du projet
pour parcourir les sources potentielles de risques.
4.2 Expression du risque

Un risque doit s’exprimer de manière claire et non ambigüe.
Une bonne façon est de le structurer en trois parties:

➢ La cause du risque: ce qui en décrit la source, c’est-à-dire la situation qui pourrait lui
donner naissance.
➢ L’évènement du risque: c’est-à-dire ce qui pourrait survenir, de manière incertaine, et
affecter un des objectifs du projet.
➢ L’effet du risque: ce qui en décrira l’impact si le risque se matérialise.
Autrement dit :
________________________________________________________________________
_______________________________________________________________________________
Exemples de risque:
➢ Parce que les transports en commun sont fréquemment en grève (cause),
il est possible que certains étudiants arrivent en retard (événement),
ce qui pourrait augmenter le taux d’échecs du cours (effet).
➢ Parce que Java 8 est encore très récent (cause),

il est possible que le framework jDoSomething soit mal intégré (événement),
ce qui pourrait rendre l’application instable pour les utilisateurs (effet).
4.3 Quantification du risque

L’évaluation vise à estimer la menace ou l’opportunité représentée par le risque en termes de:
➢ La probabilité [probability] de survenance de l’évènement,
➢ L’ampleur de son impact [impact] sur les objectifs du projet si le risque se matérialise.
Différentes échelles existent:

➢ Le mieux est de quantifier en euros.
Risque Coûts Coût Total Probabilité Coût Réel

Id Impact Implémentation de survenance
de la Réponse du Risque
1 € 60.000,00 € 8.000,00 € 68.000,00 30% € 20.400,00
2 € 30.000,00 € 6.000,00 € 36.000,00 25% € 9.000,00
3 € 40.000,00 € 5.000,00 € 45.000,00 50% € 22.500,00
Total € 51.900,00
➢ Plus pragmatiquement: High / Medium / Low
Tolérance aux
risques
 Concept de « ligne de tolérance aux risques » [risktolerance line] = délimitation des

risques acceptés.
________________________________________________________________________
_______________________________________________________________________________
4.4 Planification de la réponse

Quelle réponse pour quels risques ?
Réponse au risque [risk response]: c’est se préparer à agir s’il survient, ou agir pour éviter
qu’il ne survienne
Types de réponses
Quelques exemples de réponses aux menaces:

Eviter [avoid]:
Il présente l’avantage de réduire l’impact à 0
➢ Remplacer par du covoiturage
➢ Rester en Java 7
Réduire [reduce]:
Il concerne la cause ou l’impact
➢ Enregistrer le cours
➢ Faire un « Proof of Concept » pour anticiper les problèmes
________________________________________________________________________
_______________________________________________________________________________
Repli [fallback]:
Il est considéré comme un contournement
➢ En cas de grève, les étudiants prendront un taxi
➢ En cas d’instabilité, on repassera à Java 7
Transférer [transfer]:
Le transfert à un tiers qui en assume la totalité des conséquences
➢ Une assurance mobilité couvrira les frais de séances de rattrapages en cas d’absence.
➢ Une assurance responsabilité professionnelle est souscrite pour couvrir les pénalités
dues au client en cas de problèmes.
Partager [share]:
Le partage du risque avec un tiers à comme avantage de réduire l’impact
➢ Les étudiants motorisés se chargeront du rattrapage des étudiants affectés par la grève.
➢ Le client et le fournisseur partageront les frais engendrés en cas de problèmes.
Accepter [accept]:
On décide de ne rien faire.
L’acceptation du risque n’empêche pas la surveillance de celui-ci.
4.5 Implémentation de la réponse

Rôles et responsabilités
Un aspect important est d’assigner des rôles et responsabilités claires aux acteurs du projet:
➢ Le surveillant du risque [risk owner]:
responsable de la gestion, du suivi et du contrôle de tous les aspects du risque, incluant
l’implémentation de la réponse.
➢ L’exécuteur du risque [risk actionee]:

responsable de l’exécution des actions décidée pour répondre au risque.
➢ Il reste le risque résiduel [residual risk] :

le niveau de risque qu’il reste après implémentation de la réponse.
________________________________________________________________________
_______________________________________________________________________________
4.6 Registre des risques

Produit de Management : Registre des risques (repris dans un fichier Excel)
➢ Qui à soumis le risque
➢ Quand a-t-il été identifié
➢ Quel est sa catégorie
➢ La description (Cause – Evènements – Effets)
➢ Probabilité, l’impact
➢ Proximité
➢ Catégorie de réponse au risque
➢ Etat du risque
➢ Surveillance du risque
➢ Exécuter l’action de réponse au risque
________________________________________________________________________
_______________________________________________________________________________
5 Notion de base pour évaluer (oui le

02/03/2021)
Il ne faut pas confondre les 4 notions « Budget - Charge – Capacité – Délai ».
En termes d’évaluation, l’échelle de mesure est le « Jour/Homme ».

1J/H représente la charge de travail qu’une personne est à même de réaliser seul.
5.1 Budget
Le budget représente la somme d’argent que l’on dispose pour réaliser un projet.
Le budget doit servir à financer les moyens Techniques, Logistiques & Humains du projet.
C’est notre enveloppe reprenant notre disponible financier.
Le budget de développement de tâche informatique peut également être traduit en J/H.
Exemple :
je dispose de 50.000€ pour réaliser les tâches de développement de mon projet.
Un analyste programmeur interne est facturé 300€ par jour.
Un analyste programmeur externe est facturé 500€ par jour
Profil Cout / Jour Budget J/H

Analyste Programmeur Interne 300 50000 166
Analyste Programmeur Externe 500 50000 100
En fonction du profil interne ou externe, je dispose de 166 J/H ou 100 J/H pour développer
mon projet.
Au niveau du budget global d’un projet, il faudra également y ajouter les besoins logistiques
et techniques.
5.2 La Charge
La charge d’une tâche informatique est le nombre de J/H nécessaire pour réaliser une tâche.
La charge est calculée de manière neutre sans tenir compte qu’une personne experte ou non
réalise les développements.
La charge est évaluée une première fois au début du projet et ensuite à chaque itération de
sprint.
Les charges initiales servent à déterminer le budget initial du projet.
________________________________________________________________________
_______________________________________________________________________________
5.3 La capacité
La capacité d’un sprint est le nombre de J/H que l’on dispose en mixant toutes les ressources
de l’équipe.
Exemple :
L’équipe se compose de 5analystes programmeurs (Pierre, Lucien, Valérie, Isabelle et Marc)
Le sprint se compose de 4 semaines et elle est systématiquement suivie d’une semaine « Inter
Print ». La semaine d’intersprint sert à la réalisation de la version qui sera livrée pour la
production.
La semaine 3 comporte un jour Férié.

Pierre et Isabelle sont en formation 2 jours à la semaine 2
Valérie est en congé parental 4/5.
Marc prend une semaine de congé à la semaine 3.
Eq Scrum Semaine 1 Semaine 2 Semaine 3 Semaine 4 Semaine Inter Sprint

Pierre 5 3 4 5 5
Lucien 5 5 4 5 5
Valérie 4 4 3 4 4
Isabelle 5 3 4 5 5
Marc 5 5 0 5 5
Total 24 20 15 24 23
Capacité 83
La capacité du sprint est de 83 J/H.
5.4 Délai
Le délai est le nombre de jour calendrier que l’on dispose pour réaliser le projet ou une tâche.
Le délai est calculé à partir des paramètres : date de début du projet et l’échéance de celui-ci.
5.5 Conclusion
En mixant les différentes notions, nous pouvons avoir plusieurs cas de figure.
Si notre capacité est insuffisante pour réaliser la charge demandée dans les délais fixés.
Dans ce cas de figure, nous pouvons :
 soit augmenter l’équipe pour retrouver une capacité suffisante
 soit réduire les tâches à réaliser dans le sprint
 soit augmenter le délai et donc répartir la charge sur deux sprints
 …
Le rôle du CdP est de veuillez à ce que les paramètres « budget, charge, capacité & délai »
soient en adéquation avec les contraintes du projet.
________________________________________________________________________
_______________________________________________________________________________
6 Le schéma directeur (oui) 17/10/2017
6.1 Définition
Un schéma directeur est une description globale et stratégique de la vision informatique à
court, moyen et long terme d’une organisation ou d’une partie de celle-ci.
Il est le référentiel permettant de situer chaque nouveau développement.
6.2 Les Niveaux

4 Niveaux :
➢ Stratégiques
Généralement discuté en comité de direction,
l’objectif est d’avoir une vision à long terme de la stratégie d’entreprise en termes de
développement de produits, techniques informatiques, digitalisation, automaticité,
connectivité, flexibilité…
➢ Programme
Vision à moyen terme de développent d’un des axes de la stratégie d’entreprise.
Il rassemble un ensemble de projet selon un axe prédéfini.
➢ Projet
Vision à moyen terme de développent définis de produits définis.
➢ Opérationnel
Représente les développent en cours.
Ces développements seront livrés en vue d’être exploité en production.
________________________________________________________________________
_______________________________________________________________________________
6.3 Méthodologies
6.4 En pratique
Le schéma directeur est loin de toujours exister, ou il ne vous est communiqué que
partiellement ou même pas du tout.
Dans les cas où l’information est inexistante ou non communiquée, le concepteur doit
d’autant plus s’assurer d’une délimitation précise du domaine couvrant la partie du système
d’information à informatiser.
________________________________________________________________________
_______________________________________________________________________________
7 Lancement d’un projet (Oui)
7.1 Objectifs
- Identification de choix stratégiques dans le cadre d’un scénario global d’évolution
- sur le plan fonctionnel (applications et interfaces)
- sur le plan des moyens (techniques, humains, organisation)
- Lancer des actions
- Cadre référentiel permettant le contrôle
Déterminer sa complexité
Il est essentiel de se donner une idée de la complexité du projet.
A cette fin, il faut apporter des réponses à des questions telles que :
- la date de livraison est-elle critique pour l’activité du client ?

- le projet concerne-t-il une fonctionnalité spécifique au client ?
- l’application doit-elle produire des bénéfices quantifiés par elle-même (réduction
de 2 personnes, x tonnes de papier, …)
- le contrat reprend-il des termes et conditions standards ?
- le contrat est-il à prix fixe ?
- y a-t-il des pénalités prévues en cas de retard ?
- y a-t-il des performances spécifiques à rencontrer ?
- y a-t-il de nombreuses interfaces ?
- faut-il utiliser des produits peu maîtrisés ?
- y aura-t-il utilisation de sous-traitant (connus, inconnus) ?
- y aura-t-il une reprise de l’existant (manuelle/automatique) ?
- l’application/documentation doit –elle être multilingue ?
Les réponses à ces questions vont permettre de déterminer

- à quels aspects il faut être attentif dans le cadre de ce projet
- les risques que l’on va ou non prendre
- la façon dont on va déterminer le prix.
- des points de contrôle spécifiques à mettre en place
________________________________________________________________________
_______________________________________________________________________________
7.2 Comité de pilotage [Steering Comitee]

(oui)09/03/2021
Sa Composition
Ceci est un élément fondamental. De sa composition dépendra en grande partie des
conditions adéquates ou non.
Pour chaque projet on doit être capable de reconnaître les 3 intérêts
En effet, le comité de pilotage est l’organe suprême dans un projet. Il est donc vital que les
bonnes personnes y soient présentes
- le sponsor du projet alias l’Exécutif : il représente l’entreprise
- le fournisseur principal
- l’utilisateur principal = Utilisateur du produit
Le chef de Projet ne fait pas partie du comité de pilotage, mais il est l’acteur indispensable
pour le bon fonctionnement de celui-ci. C’est une personne « neutre ».
Le CdP anime les réunions du comité de pilotage avec l’état d’avancement des projets, les
risques, les résultats des groupes de travail, ….
Le CdP peut/doit faire des propositions et une recommandation mais ce n’est pas lui qui
décide.
La décision est prise de commun accord entre les membres du comité de pilotage et en cas de
conflit, l’exécutif tranche et prend la décision finale.
________________________________________________________________________
_______________________________________________________________________________
Les Extensions possibles (Non)
L’assurance projet est une personne neutre qui représente les trois intérêts.
Son rôle est de conseiller, rappeler les bonnes pratiques. Il est une personne de référence et
reconnue de tous.
Le support Projet est une personne qui soutient le projet au niveau de l’opérationnel.
Fonctionnement (Oui)
Une des premières décisions du comité de pilotage doit être de déterminer son mode de
fonctionnement :
- fréquence de réunion
- lieu de réunion
- contenu et présentation du rapport d’activités
- délai à respecter avant la réunion pour la diffusion du rapport
- personne chargée de rédiger le PV de la réunion
- possibilité d’une réunion spéciale en cas de nécessité
En ce qui concerne la fréquence de réunion, celle-ci sera notamment dépendante de la durée

prévue du projet et de la phase dans laquelle on se trouve.
________________________________________________________________________
_______________________________________________________________________________
Agenda type d’une réunion de comité de

pilotage
Même si le contenu peut varier d’un comité à l’autre, l’agenda reprend très souvent les points
suivants :
- validation du rapport de la réunion du comité précédent
- présentation de l’état d’avancement
- points sur lesquels des décisions doivent être prises
7.2.4.1 Validation du rapport de la réunion précédente

Ce point est tout à fait vital car c’est un des rares moyens que dispose le CdP pour officialiser
par écrit des décisions essentielles pour le projet.
Ceci est clairement un moyen de mettre chacun face à ses responsabilités. En effet, le comité
de pilotage reprend l’ensemble des acteurs d’un projet (client, fournisseur). Toutes les parties
se trouvent dès lors engagées et chacune pourra se servir du contenu.
7.2.4.2 Présentation de l’état d’avancement

Il est évident que le but n’est pas de présenter la situation dans chacun de ses détails. Il y aura
donc un regroupement de tâches en quelques intitulés significatifs permettant de se rendre
compte de la situation.
Ce n’est que lorsque des problèmes importants surgissent qu’il est parfois nécessaire de
rentrer dans plus de détails.
Un comité de pilotage est composé de personnes dont le temps est compté. Il faut donc que la
présentation soit la plus efficace possible et donc très visuelle.
Un moyen simple est de présenter des tableaux de synthèse comme ceux-ci :
________________________________________________________________________
_______________________________________________________________________________
Via un tableau de synthèse « high level » du Planning, Budget, Capacité et les recettes
________________________________________________________________________
_______________________________________________________________________________
Via un Diagramme de GANTT pour évaluer le délai des livrables
________________________________________________________________________
_______________________________________________________________________________
________________________________________________________________________
_______________________________________________________________________________
Via un tableau de synthèse de charge pour évaluer les dépenses du projet
Charge Charge Charge

Consommé Ecart
Intitulé Initiale Restante Revue
(J/H) (J/H)
(J/H) (J/H) (J/H)
Etude préalable 50 55 0 55 5
Phase 1 analyse 100 90 20 110 10
Phase 1 dvpt 150 50 140 190 40
Phase 1 test 20 0 20 20 0
Phase 1 acceptance 20 5 10 15 -5
Phase 1 mise en prod 5 0 5 5 0
Phase 1 1er suivi 5 0 5 5 0
Phase 1 documentation 30 12 10 22 -8
Sous total Ph 1 380 212 210 422 42
Phase 2 analyse 80 0 80 80 0
Phase 2 dvpt 60 0 60 60 0
Phase 2 test 15 0 15 15 0
Phase 2 acceptance 15 0 15 15 0
Phase 2 mise en prod 2 0 2 2 0
Phase 2 1er suivi 4 0 4 4 0
Phase 2 documentation 20 0 20 20 0
Sous total Ph 2 196 0 196 196 0
TOTAL 576 212 406 618 42
Charge Revue = Consommé + Charge restante
Ecart = Charge Revue – Charge Initiale

 Un écart négatif représente une surestimation.
 Un écart positif représente une sous-estimation.
 Un écart nul représente une estimation juste
________________________________________________________________________
_______________________________________________________________________________
7.3 Constitution de l’équipe (non)
Equipe ‘fournisseur’
Afin de pouvoir déterminer la taille et les compétences nécessaires, il faut dès le début se
demander quels sont les profils dont on a besoin.
A priori, 3 domaines doivent toujours être couverts.

- gestion de projet
- aspect fonctionnel
- aspect technique
Le nombre de personnes à affecter à un projet dépend de plusieurs facteurs

- l’état d’avancement
- la taille du projet
- la durée du projet
Prenons chacun de ces éléments un par un
Etat d’avancement
Le nombre de personnes, ainsi que les profils nécessaires, sont tout à fait liés aux différentes
phases du projet.
Ex : Il est inutile de demander d’avoir à disposition des programmeurs si le projet n’est pas
assez mûr pour cela.
La taille du projet
Un petit projet permettra à une même personne de jouer plusieurs rôles simultanément.
Ex : chef de projet et analyste fonctionnel
Architecte et programmeur
Analyste et testeur
Au contraire, un projet important ne permet pas de cumuler les rôles.
Durée du projet
La durée du projet a un impact direct sur le nombre de ressources à mettre oeuvre.
Plus le délai de réalisation sera court (tout en restant possible), plus il sera nécessaire de
maximiser le nombre de tâches à réaliser en parallèle.
Cependant, une telle contrainte n’est pas sans risque :
1) coordination et contrôle doivent être renforcés
Il y a clairement un risque que le parallélisme le soit de moins en moins au fil du

temps.
En supposant même que les spécifications de départ étaient claires, au cours de la
réalisation, chaque équipe se trouvera confrontée à des problèmes spécifiques.
________________________________________________________________________
_______________________________________________________________________________
Afin de les résoudre, il se pourrait que des spécifications de départ, base de travail
d’une autre équipe, soient modifiées sans que cette dernière n’en soit informée.
Au moment d’intégrer ces 2 parties, il se peut que l’on constate des
incompatibilités.
Prenons un exemple dans le monde automobile :

Une équipe travaille sur le châssis, une autre sur le moteur.
Les spécifications en matière de compartiment moteur ont été établies avant que
chacune des équipes se mette à leur réalisation respective.
L’équipe ‘châssis’ pour répondre à une contrainte d’aérodynamisme se décide à
modifier ces spécifications.
L’équipe ‘moteur’ devant répondre à une contrainte de norme antipollution
modifie également les spécifications.
On peut aisément imaginer certains problèmes lors de l’assemblage, soit qui le
rende impossible (moteur trop gros pour le châssis) soit moins efficace (le moteur
aurait pu être conçu de manière plus optimale si l’équipe avait été informée à
temps de l’élargissement du compartiment moteur).
2) Temps de réflexion, maturation réduit

L’obligation de faire de nombreuses tâches en parallèle non seulement implique
plus de contrôle et de coordination mais réduit considérablement le temps
disponible pour la réflexion, l’analyse, l’intégration de tous les aspects.
________________________________________________________________________
_______________________________________________________________________________
Equipe ‘client’
De même que le Comité de pilotage, en tant qu’organe suprême de décision, est un élément
fondamental, la constitution d’une équipe ‘client’ adéquate l’est aussi.
Un des moyens d’en déterminer sa constitution est de se baser sur le schéma de l’équipe
interne.
Trop souvent, le chef de projet ‘client’ est choisi non pas pour ses qualités de ‘moteur’ et pour
sa connaissance métier mais pour son niveau hiérarchique.
S’il est vrai que d’importantes responsabilités pèsent sur ses épaules, ce n’est pas pour autant
qu’il doit avoir le pouvoir de décider de tout.
Un mauvais choix à ce niveau peut avoir des conséquences importantes tout au long du projet.
En effet, si son niveau hiérarchique est trop important, cela implique qu’il a bien d’autres
problèmes à régler que ceux relatifs à votre projet. Ceci induit plusieurs aspects négatifs :
1) Disponibilité
2) les décisions sont lentes
3) la connaissance du projet n’est pas optimale
4) la connaissance métier n’est plus assez proche du terrain
Le lieu pour inclure des personnes avec un haut pouvoir de décision est clairement le Comité
de pilotage.
________________________________________________________________________
_______________________________________________________________________________
7.4 Plan de communication (Oui)

Le plan de communication a pour objectif d’assurer que toutes les parties prenantes sont
tenues informées du projet depuis sa préparation jusqu’à la clôture.
Le plan définit toutes les parties qui ont un intérêt dans le projet et la fréquence de diffusion
du reporting.
Vers l’extérieur
Ici il s’agira essentiellement de la communication à mettre en œuvre
Vis-à-vis du comité de pilotage
Vis-à-vis de l’utilisateur principale du client
Le comité de pilotage a un côté formel. La communication doit s’y adapter.
Rappel
Le comité de pilotage est l’organe suprême en matière de décision sur un projet. Pour cette
même raison les personnes qui le composent (pouvoir de décision) ont un emploi du temps
chargé.
Il est donc essentiel de déterminer une fréquence suffisante (minimum 1fois par mois) où l’on
est sûr de pouvoir réunir toutes ces personnes.
Ceci ne signifie pas qu’elle ne doit se faire que de manière orale.
Vers l’intérieur
La communication avec l’équipe interne est fondamentale. Par équipe interne, il faut
comprendre tous les intervenants potentiels (autres services, direction, réseau, télécom, …)
 Parties Prenantes du projet
________________________________________________________________________
_______________________________________________________________________________
En ce qui concerne l’équipe du projet, il est assez simple d’établir un plan de communication
- résumé de chaque comité de pilotage
- réunion régulière avec les membres de l’équipe
Ce dernier point est fondamental. Cette réunion doit permettre la communication dans les 2
sens. Il est essentiel d’être à l’écoute des membres de l’équipe. Il faut prendre en compte
leurs remarques ou questions et, toujours, y apporter un feedback même, et surtout, si celui-ci
est négatif.
Ex : temps de réponse de l’environnement de développement insatisfaisant
La réponse peut être : oui, mais pas de budget disponible
Cas spécifique : réunion/discussion

De manière générale, toute réunion ou discussion doit faire l’objet d’un compte-rendu même
si la réunion/discussion n’a débouché sur aucune décision.
Dans ce cas, des actions ont été décidées.
Un compte-rendu doit reprendre systématiquement les éléments suivants :

➢ la date à laquelle la réunion/discussion a eu lieu
➢ les personnes invitées
➢ les personnes qui y ont réellement participé
➢ un motif pour les personnes invitées mais non présentes
➢ Pour chaque point à l’ordre du jour
o Explication du problème et du questionnement
o La/les décisions
➢ les actions attendues [TODO List]
Ces actions attendues peuvent être de différentes natures mais pour chacune d’entre elles, on
doit retrouver :
➢ la personne devant réaliser l’action
➢ un intitulé
➢ une date de réalisation prévue
➢ Statut
Responsable Action échéance Etat

ABL Réaliser analyse US5 20/05/2015
EPQ Développer US3 15/06/2015 en cours
EVH Développer US4 15/06/2015
FVL Réaliser les tests fonctionnels US2 31/05/2015 Terminé
________________________________________________________________________
_______________________________________________________________________________
7.5 Méthodologie/Normes/Standards (Non)
Méthodologie
Plusieurs cas de figure sont possibles :
- le client n’a pas de méthodologie
o dans ce cas, il est généralement prêt à utiliser la vôtre
- le client a une méthodologie mais n’en fait pas une fixation
- le client impose sa méthodologie
Normes et standards
Généralement, plusieurs personnes différentes travaillent sur un projet.
Il est également fréquent que plusieurs personnes occupent la même fonction (analyste
fonctionnel, développeur, …).
Toutes ces personnes doivent avoir une vue identique sur le projet.
Le moyen d’atteindre cet objectif est de définir des processus, des standards, des templates.
Ceci s’applique à chacune des étapes du projet ainsi qu’à chacun des acteurs :
- formulaire pour les rapports de réunion
- formulaire pour les documents d’analyse
- formulaire pour les documents de design détaillé
- processus pour traiter les demandes de changement
- processus pour valider les documents
- standard en matière de code
- standard en matière de création d’écrans
- standard en matière d’utilisation d’outil
o en matière de choix d’outil
o en matière d’utilisation d’un outil spécifique
Tout document doit avoir un responsable (owner). Il est le seul habilité à pouvoir y apporter
des modifications.
Tout ceci n’est pas une garantie de qualité en matière de contenu. De même qu’un texte peut
être grammaticalement correct, il n’en est pas forcément compréhensible pour autant.
Cependant, si la grammaire impose des règles, ce n’est pas pour autant que la créativité n’est
pas possible. Bien sûr, elle l’est mais dans un autre domaine.
________________________________________________________________________
_______________________________________________________________________________
7.6 Assurance qualité (Non)
Introduction
Les différents points de ce chapitre sont des éléments essentiels pour un bon démarrage d’un
projet.
Mais le seul fait d’y penser ne suffit pas à les rendre réels. Et les rendre réels ne suffit pas à
les rendre efficaces.
Pour s’assurer de tout cela, il est nécessaire de concrétiser 2 actions :

- rédaction d’un plan qualité
- assigner une ou des ressources à son suivi
Rédaction d’un plan

Le plan d’assurance qualité doit définir de manière concrète les moyens et moments de
vérification de la qualité.
Exemples :
Rapport systématique de réunion
- établir l’existence d’un formulaire standard pour les rapports de réunions (moyen)
- prendre quelques réunions par échantillon et vérifier l’existence du rapport y
afférent (moment)
Standards en matière de code
- établir l’existence d’un document reprenant les standards à appliquer (moyen)

- s’assurer qu’un versioning1 du document est prévu (moyen)
- s’assurer que des actions sont effectivement décidées et planifiées en cas de
modification du document (moyen)
- s’assurer de la réalisation effective des actions (moment)
- procéder à des contrôles par échantillonnage (moyen)
Suivi du plan
De même qu’il ne suffit pas d’établir des standards pour que ceux-ci soient respectés,
l’existence d’un plan qualité ne suffit pas en lui-même.
1
Par versioning, il faut comprendre que le document est sous sontrôle et que chaque modification doit générer
une nouvelle version du document. En plus de la version, il faut évidemment la date et l’auteur de la
modification
________________________________________________________________________
_______________________________________________________________________________
Pour qu’il ait un sens il faut y assigner des ressources compétentes et motivées.
Si, en général, tout le monde est d’accord en ce qui concerne le principe de qualité, il n’en est
pas pour autant évident de pouvoir y affecter des ressources.
De plus, il ne faut que ces ressources deviennent théoriques. Il est en effet fréquent que la
bonne volonté du début ne fasse que peu de poids face à des contraintes réelles et que dès lors,
pour les personnes chargées de cette mission, celle-ci ne devienne qu’une tâche parmi tant
d’autres.
________________________________________________________________________
_______________________________________________________________________________
7.7 Aspects organisationnels (Oui)
Introduction
lI est extrêmement rare qu’un projet informatique n’ait pas de conséquences
organisationnelles. Celles-ci peuvent se situer à différents niveaux.
Il est de votre responsabilité de faire part de ces éléments et d’attirer l’attention du client sur
ces points.
En effet, il est important qu’il réalise que, d’une part, dans le cadre du projet, ces aspects
nécessitent des ressources et que, d’autre part, certaines conditions peuvent nécessiter un
temps plus ou moins long pour être rencontrées (câblage, commande, réception et installation
de nouveaux matériels, formation du personnel).
Voyons un peu plus en détail les différents niveaux concernés
Au niveau du personnel
Différentes situations peuvent se produire :
- réduction du personnel
- formation du personnel en place
- recrutement de personnel spécialisé
- une combinaison d’un ou plusieurs des points ci-dessus.
Au niveau du matériel
Il peut s’agir de
- l’équipement entier d’un service avec des PC ou du remplacement de ceux-ci.
- l’installation d’imprimantes laser couleurs
- l’achat de nouveaux bureaux et chaises mieux appropriés
Au niveau du bâtiment et des locaux

Le câblage peut être à revoir en matière de technologie (fibre de verre), de connexions (en
nombre suffisant).
________________________________________________________________________
_______________________________________________________________________________
7.8 Responsabilités (Oui)

Dès le début du projet, il est essentiel que certains points aient fait l’objet d’une mention
claire et écrite et d’un accord formel.
Ici, il ne s’agit évidemment pas de piéger le client. Les responsabilités doivent être exprimées
pour chacune des 2 parties : client ET fournisseur.
Exemple de responsabilités
Project manager du fournisseur
- construire l’équipe projet, ce qui signifie que les membres du team auront les
qualifications requises, seront assignés aux tâches relevantes pour eux, que le
Project Manager les gardera comme une équipe soudée entièrement dirigée vers un
but commun
- définir le planning de référence du projet et en assurer le suivi
- agréer, implémenter et gérer le projet
- définir et agréer le processus définissant la gestion des demandes de changement
- définir et gérer le périmètre pour l’ensemble du projet en ceci inclus les problèmes
administratifs
- s’assurer de la qualité du projet sur base journalière et contrôler l’adéquation entre
la production et les spécifications
- rapporter régulièrement au comité de pilotage sur base du plan de communication
Project manager du client
- est l’interface entre le fournisseur et l’ensemble des départements du client

participant au projet
- en collaboration avec le chef de projet fournisseur, administre les demandes de
changement sur base du processus défini
- participe aux réunions dont le but est de définir le statut
- obtient et fournit l’information, données, décisions et accords dans les x jours de la
demande formulée par le fournisseur, sauf si le fournisseur et le client ont défini un
autre délai
- solutionne les déviations par rapport au plan initial et qui seraient dues au client
- aide à résoudre les problèmes du projet et, si nécessaire, en appel à l’organisation
du client (hiérarchie)
Le projet peut être dépendant de la fourniture d’un logiciel par un sous-traitant du client.
Vous n’avez en tant que fournisseur aucun lien avec ceci, si ce n’est que cela conditionne une
partie de votre projet.
C’est dans le cadre des responsabilités du client qu’il faudra préciser que la gestion de ce
point est entièrement assurée par lui, que ce logiciel doit être disponible au plus tard à la date
x et qui si tel n’est pas le cas, le planning ainsi que le budget pourraient être remis en cause.
________________________________________________________________________
_______________________________________________________________________________
Pour ne pas oublier ce point, il doit être clairement indiqué comme milestone (= point de
contrôle) dans le planning du projet en marquant clairement le lien entre la mise à disposition
de ce logiciel et les activités qui en dépendent.
7.9 Critères d’acceptance (Oui)

Ce point va se retrouver à chaque étape importante et particulièrement lors de ‘délivrables’.
En effet, il est important de définir pour chaque élément à livrer la manière dont celui-ci sera
formellement accepté par le client.
Pour un document, il s’agit évidemment de remettre le document au client.

Mais ceci est loin d’être suffisant. Il faut également définir le temps qui lui est accordé pour
faire ses remarques, limité le cycle à 1 ou 2.
Pour une partie de l’application, un jeu de tests doit avoir été défini par le client et approuvé
par le fournisseur et les tests ont été exécutés de manière positive.
Remarque : lorsque l’on parle de client, il ne s’agit pas forcément d’un client externe réel.
Dans le cas de la conception d’un logiciel devant être vendu, le client réel sera simulé en
interne par une équipe chargée de jouer ce rôle.
7.10 Critères d’achèvement

Il s’agit ici de définir les critères qui doivent être remplis afin de pouvoir considérer que le
projet est terminé.
Ces critères vont varier en fonction de la nature et des conditions du projet.
Il y a 2 grands types de cas :

- projet en régie
- projet à prix fixe
Si dans un projet en régie, vous pouvez indiquer que vos tâches seront terminées lorsque les
heures prévues auront été prestées, il n’en est pas de même dans un projet à prix fixe où vous
devrez prester autant qu’il le faudra pour réaliser ce qui a été convenu.
________________________________________________________________________
_______________________________________________________________________________
8 Planning (Oui)
8.1 Etablir le planning
Introduction
Le planning est un outil de gestion et de communication extrêmement puissant mais il ne le
sera que s’il est établi avec soin et en concertation avec les différents acteurs, qu’il sert de
référentiel permanent, qu’il est diffusé, accessible et que chacun s’en approprie le contenu et
s’en sent responsable.
De manière générale, les postes suivants doivent s’y retrouver :

➢ gestion de projet
➢ lancement
➢ analyse
➢ développement
➢ tests
➢ installation/mise en production
➢ 1er suivi
Suivant le modèle de développement SCRUM ou RUP :
CRITICAL PATH
Critical path ou chemin critique
Le critical path est un ensemble de succession de tâches qui conditionne le succès du projet en
terme de planning (mais pas de budget).
C’est en fait, en partant de là où les tâches qui déterminent la fin du projet en termes de
planning, déterminer les tâches qu’il faut surveiller de manière à prendre immédiatement toute
action correctrice pour remédier ou éviter tout dérapage.
________________________________________________________________________
_______________________________________________________________________________
Attention : si un critical path existe toujours, les tâches qui le composent peuvent changer en
cours de projet. En effet, le retard sur certaines tâches qui ne paraissaient pas critiques peut
les amener sur le critical path.
Rappel : Durée et charge
Voici 2 notions fondamentales qu’il ne faut pas confondre.
La charge, généralement exprimée en jours/homme, indique le temps à prester sur une tâche
sans préjuger du fait que les prestations soient ininterrompues ou non.
La durée est le nombre de jours calendrier qui sépare le début des prestations sur une tâche de
la fin des prestations.
La durée est fonction :
Disponibilité ressources affectées (100%, 50%, …)

Réalité est-ce possible de travailler de manière ininterrompue sur cette tâche ?
est-ce possible de faire travailler plusieurs personnes simultanément ?
Quantité y a-t-il plusieurs personnes à affecter ?
On peut donc avoir

Charge Durée
10 J/H 15 1 personne à 100%
10 J/H 7 2 personnes à 100%
10 J/H 30 1 personne à 50%
Exemple de tableau de Charge
________________________________________________________________________
_______________________________________________________________________________
Activités minimisées ou oubliées (Non)
8.1.2.1 présentation/démo
Une démo comporte 4 phases :

- préparation
- réalisation
- débriefing
- suivi
Pour chacune de ces phases, nous allons voir

les activités qui y sont incluses
les personnes impliquées
le temps en ‘elapsed time’2 et ‘en charge’
8.1.2.1.1 Préparation
Dans certaines situations, il n’est pas toujours simple d’avoir une acceptation pour une charge.
En effet, un argument visant à supprimer cette partie serait de dire que la préparation est
inutile étant donné qu’elle serait faite par des membres de l’équipe projet ayant une parfaite
connaissance du projet.
Le contre argument est en fait le même : justement que l’équipe projet est au quotidien avec
toutes les infos, il ne lui est pas facile de prendre du recul et d’imagine une démo qui soit
compréhensible par des personnes qui ne sont impliquées dans le projet que ponctuellement.
Cet effort nécessite du temps.
8.1.2.1.1.1 Activités
Les activités liées à cette phase sont de 3 ordres
- définir le contenu
o que va-t-on présenter ?
o quels sont les points à clarifier ?
- définir la méthodologie de présentation
o introduction : donner un état des lieux3
o présentation et, ensuite, séance questions-réponses
o questions autorisées tout au long de la présentation
- assurer l’organisation
o définir une date, un lieu, une période en accord avec le client
2
elapsed time : c’est le temps effectif qui s’écoule entre le début d’une action et la fin de celle-ci. Si l’action est
effectuée de manière ininterrompue, le temps de réalisation est identique au temps écoulé
3
ceci afin d’éviter toute confusion sur l’état d’avancement réel : ex : un enchaînement d’écrans se faisant en
cliquant sur des boutons peut faire croire au client que tout le développement y afférent est présent alors que le
but de la démo est justement de valider la compréhension actuelle du besoin à travers des maquettes d’écrans
dont une navigation simplifiée mais présente permet de se rapprocher le plus possible de ce que verra
l’utilisateur
________________________________________________________________________
_______________________________________________________________________________
o envoyer les invitations et l’agenda

o s’assurer que les personnes-clé seront présentes (client et fournisseur)
o réserver une salle, le matériel requis (tableau, marqueur, projecteur,
boissons, …)
8.1.2.1.1.2 Temps
1 jour en ‘elapsed time’

* 3 personnes = 3 jours en charge
8.1.2.1.1.3 Ressources
Une démo est un investissement important qui nécessite l’apport de 3 profils :

- Connaissance globale du projet
- connaissance fonctionnelle
- connaissance technique
Selon les projets, ceci peut représenter 1, 2 ou 3 personnes.
Dans mon expérience, dans cette phase de préparation, 3 personnes sont recommandées,
couvrant à elles trois l’ensemble des profils.
La présence de 3 personnes représente plusieurs avantages

- il y a plus d’idées dans 3 têtes que dans une
- les points de vue sur l’application sont différents
- création d’un esprit d’équipe
- même information sur l’état d’avancement et sur ce qui sera présenté
________________________________________________________________________
_______________________________________________________________________________
8.1.2.1.2 Réalisation
- réaliser la démo
- prendre des notes
o points éclaircis
o points à éclaircir
o décisions prises
- obtenir un engagement pour les points à traiter par le client
- s’engager pour les points à traiter par le fournisseur
8.1.2.1.2.2 Temps
0,5 jour en elapsed time

*3 personnes = 1,5 jour en charge
Une démo doit avoir un caractère interactif et est souvent un lieu propice pour aborder
- des points déjà identifiés
- des points qui surgissent durant la réunion
Même s’il est souvent recommandé de ne pas répondre à des questions concernant l’impact de
changements demandés, il est important de pouvoir discuter immédiatement de ces points afin
de réunir assez d’éléments pour en faire une évaluation ultérieure.
Pour cela, différents profils sont nécessaires :
Chef de projet :
indiquer que la demande est soit hors périmètre, soit en contradiction avec une décision prise
au préalable
Analyste fonctionnel
Peut détecter une demande trop imprécise et poser des questions en matière de fréquence, de
complexité, de réelle nécessité en indiquant que ceci est déjà couvert par un autre
traitement
Développeur
Peut avoir des questions spécifiques lui permettant de déjà imaginer différentes solutions ou
indiquer immédiatement l’impossibilité technique
________________________________________________________________________
_______________________________________________________________________________
8.1.2.1.3 Débriefing
Après la réunion, il est important de partager les impressions des différents participants, de
clarifier certains points, clairs pour certains et pas pour d’autres.
- organiser une réunion de débriefing dans les plus brefs délais
- rédiger un rapport (chef de projet)
- lancer les actions nécessaires en matière de réponse à donner au client
8.1.2.1.3.2 Temps
0,5 jour
*3 personnes
= 1,5 jour en charge
Les ressources vont dépendre de l’activité à accomplir
organiser une réunion de débriefing dans Tous les participants

les plus brefs délais
rédiger et distribuer le rapport Chef de projet/analyste
lancer les actions nécessaires en matière de Dépendra de l’action
réponse à donner au client
________________________________________________________________________
_______________________________________________________________________________
8.1.2.1.4 Suivi
- prise de connaissance et réactions éventuelles sur le rapport
- édition du rapport final
- suivi des actions entreprises
- feed back vers le client
- réception du feed back du client, analyse et info au reste de l’équipe
8.1.2.1.4.2 Temps
Etant donné que les aspects temporels ont été déterminés soit lors de la démo, soit lors du
débriefing, l’objectif est connu.
Attention : il s’agit essentiellement de date limite fixée en ‘elapsed time’ et non en charge.
prise de connaissance et réactions Tous les participants sauf le rédacteur

éventuelles sur le rapport
Édition et distribution du rapport final Le rédacteur
suivi des actions entreprises Chef de projet
feed back vers le client Chef de projet
réception du feed back du client, analyse et Chef de projet
info au reste de l’équipe
8.1.2.1.5 Conclusion
Sans prendre en compte l’activité ‘suivi’ plus difficile à estimer mais à ne pas ignorer,
ceci nous donne donc pour une démo une charge totale sur le projet de 6 jours.
Sur un projet, même de taille modeste, 3 démos ne sont pas un chiffre exagéré. Vous voilà
donc avec une charge totale, uniquement pour les démos de 18 jours en charge.
________________________________________________________________________
_______________________________________________________________________________
8.1.2.2 Réunions de coordination
8.1.2.2.1 Réunions de coordination externe
Elles sont généralement de 2 types :

- comité de pilotage (2j/mois)
- chef de projet client (1j/semaine)
Ces réunions impliquent également les mêmes étapes que pour une démo avec les mêmes
conséquences : temps à prévoir pour toutes les personnes impliquées même si elles ne
participent pas directement aux réunions, y compris pour les informer .
8.1.2.2.2 Réunions de coordination interne
Chaque personne impliquée dans le projet est concernée par ce type de réunion que ce soit
pour donner ou recevoir des informations.
Ces réunions sont indispensables pour le suivi du projet mais également pour traiter les
réunions externes.
________________________________________________________________________
_______________________________________________________________________________
8.1.2.3 Indisponibilité des ressources humaines
Plusieurs facteurs peuvent rendre indisponible des ressources :

- maladie/accident
- congés
- formation
- affectation à un autre projet
- démission
Il y a des facteurs plus faciles à maîtriser que d’autres. Il est facile de demander à chaque
personne de planifier ses congés ainsi que de lui demander les formations déjà connues ou
futures qu’elle sera amenée à suivre durant le projet.
En ce qui concerne l’absence pour maladie, vous pouvez prévoir, selon la durée du projet, un
chiffre pour chaque personne.
Par contre, une démission ou une affectation sur un autre projet sont des éléments que vous ne
maîtrisez pas.
Ils seront simplement plus faciles à gérer si vous disposez d’un planning précis. Vous pourrez
alors plus aisément faire des simulations sur les conséquences de tel ou tel événement.
8.1.2.4 Phase 1er suivi
Le projet ne s’arrête ni à la remise de l’application pour acceptance, ni à la date de sa mise en

production effective mais après une période raisonnable de mise en service. Ceci pourrait être
assimilé à une garantie minimale d’intervention incluse dans le planning, le budget et donc le
prix.
Ceci est un élément important permettant également de garder des ressources affectées au
projet disponibles jusqu’à ce moment.
________________________________________________________________________
_______________________________________________________________________________
Etablir le planning (Oui)

Ceci n’est pas une chose simple à établir particulièrement lorsqu’un grand nombre de
personnes sont impliquées.
Il faut également savoir qu’il y a certaines tâches qui peuvent se faire en parallèle et d’autres
pas.
Une erreur à ne pas commettre est d’établir votre planning en fonction de charges liées
directement à des personnes spécifiques. En effet, comme déjà mentionné dans un autre
point, les indisponibilités cela existe. Vos chiffres, réalistes si des personnes précises étaient
disponibles comme annoncé, deviennent beaucoup trop optimistes.
Une personne n’est pas équivalente à une autre.
Ma recommandation est toujours de faire les estimations en se basant sur un profil normal, ni
un surdoué, ni un sous doué
Toutes les tâches ayant été

- identifiées,
- estimées en charge et elapsed time,
- associée au moins à une ressource
- placées entre la tâche qui doit obligatoirement la précédé et celle qui doit
obligatoirement la suivre
il est alors possible de construire le planning.
Rappel : il ne faut pas oublier d’indiquer dans le planning les dépendances intérieures (entre
tâches) mais également les dépendances extérieures.
Ces dépendances extérieures peuvent être :

- matériel et locaux à mettre à disposition par le client
- interface à réaliser par le client et nécessaire pour les tests
- logiciel à livrer par un sous-traitant du client
8.1.3.1 Les estimations
Faire des estimations est l’activité la moins appréciée. Cependant, elle est indispensable.
A mon sens, il n’y a pas de règle magique en cette matière. Mais, ici, comme ailleurs, une
méthodologie est d’un grand secours.
________________________________________________________________________
_______________________________________________________________________________
8.1.3.1.1 Décomposition (15/11/2016)
La 1ère condition qui doit être rencontrée est de décomposer au maximum en tâches les
activités à accomplir.
Cette approche à 2 avantages :
1) il est plus facile d’associer une estimation à des activités modestes
2) la décomposition permet de se faire une meilleure idée de ce qui a réellement à
accomplir
ex : analyse jusqu’à la rédaction du document à valider
Num Activité Analyste CdP Resp Technique

1 Interview (4 pers. * 0.5j) 2
2 Rédaction du rapport de chaque interview (4 * 0.5) 2
3 Validation du contenu de chaque rapport (4*0.25) 2
4 Rédaction du rapport de chaque validation (4*0.25) 2
5 Réunion interne de coordination (0.5j) 0,5 0,5 0,5
6 Rassembler la documentation existante 2
7 Prendre connaissance et traiter la documentation 3
8 Rédaction du document d’analyse (3j) 3
9 Validation interne (1j) 1 1 1
Total J/H 17,5 1,5 1,5
ex : validation des spécifications fonctionnelles
Utilisateur
Num Activité Analyste CdP Resp Technique Principale
1 vérification de l’existence du document
2 envoi du document
3 temps nécessaire à la prise de connaissance 3
4 réunion de validation 1 1
rédaction d’un rapport de réunion en indiquant les
5 remarques acceptées 0,5
6 réunion interne de coordination 1 1 1
7 Rapport de réunion 1
8 modification, si nécessaire, du rapport modifié 0,5
9 envoi de la version finale
10 suivi
Total J/H 3,5 2,5 1 3
Au niveau du planning, vous avez ici 2 types d’éléments : charge et elapsed time
- activités à réaliser par l’équipe de développement = charge et elapsed time
________________________________________________________________________
_______________________________________________________________________________
- activités à réaliser par le client = elapsed time (à ne pas facturer)

- activités à réaliser ensemble = charge et elapsed time
Ce n’est pas parce qu’une des étapes n’impliqgue pas de charge pour l’équipe de
développement qu’elle n’est pas importante pour le planning (milestone).
Pour chaque activité, qu’elle soit à réaliser par vous ou par le client, il est important de fixer et
de communiquer un délai maximum (ex : réactions dans les 2 jours ouvrables de la remise du
rapport).
8.1.3.1.2 Se baser sur l’expérience du passé (personnelle ou non)

L’important est de s’améliorer et de retenir les leçons du passé.
Vous trouverez des personnes naturellement optimistes, d’autres plus pessimistes.
Il faut donc pouvoir se raccrocher à des faits.
Dans un projet, il y a des activités répétitives et présentes dans pratiquement tous les projets :
rédactions de rapport, réunions de coordination, démonstrations, …
Il est alors assez facile de trouver des informations vous permettant de faire une première
estimation basée sur un ‘standard’. Ce sera ensuite à vous de vérifier si cela correspond à la
réalité ou non et le cas échéant de vous créer votre propre standard.
Il y a également des activités plus spécifiques au projet (ex : étude d’un logiciel spécialisé).
Mon conseil serait dans ce cas d’essayer d’établir des minimas.
Pour telle activité, il faut compter un minimum de 5 jours pour 2 personnes à plein temps.
L’étude de projets plus ou moins similaires réalisés dans le passé est également une bonne
base.
Attention : assurez-vous que les chiffres qui vous seront communiqués reflètent bien la
réalité et ne sont pas le reflet d’un planning initial non adapté par la suite.
8.1.3.1.3 Validation
Si possible, particulièrement si vous n’avez aucune expérience d’un projet semblable, il est
important de faire valider les estimations par une personne extérieure au projet (afin d’avoir le
maximum d’indépendance) mais ayant de l’expérience sur un tel type de projet.
Fait également partie de la validation, la vérification de l’adéquation de la solution, y compris

la faisabilité technique, au besoin du client.
________________________________________________________________________
_______________________________________________________________________________
8.1.3.1.4 Diagramme de GANTT

Le diagramme de GANTT est un outil de planification efficace.
On y retrouve les éléments suivants :

• L’acteur de la tâche
• Le chef d’équipe (càd le responsable)
• L’activité à réaliser ainsi que la tâche liée à cette activité
• La date de début
• La date de fin
Via un diagramme de GANTT nous pouvons facilement visualiser les tâches qui se suivent
ainsi que les tâches qui sont réalisées en même temps.
________________________________________________________________________
_______________________________________________________________________________
8.2 Suivi du planning (Oui)
Introduction
Etablir un planning n’est pas une chose aisée mais lors de l’établissement vous êtes en
statique. Vous disposiez des éléments nécessaires sans que ceux-ci ne soient (trop) sujet à
modification.
Lorsque le projet aura commencé, et parfois même avant, toutes sortes d’éléments peuvent
venir perturber la belle mécanique qui avait été mise sur papier.
Il s’agit alors de travailler en plusieurs étapes :

- prendre en compte la modification
- analyser les conséquences
- déterminer les actions nécessaires afin de revenir au plan initial
- réaliser et mesurer le résultat de ces actions
Attention
A ce stade, le projet est en vie, plusieurs éléments peuvent se produire en même temps.
Le gain obtenu par certaines actions peut être perdu à la suite de la survenance d’un nouvel
élément.
Ex : bénéfice du travail du week-end annihilé par la maladie d’un ou de plusieurs participants
ou l’arrivée d’une nouvelle personne par le départ d’une autre
Informations nécessaires
Le suivi du planning, c’est à dire sa mise à jour, n’est possible que si les données nécessaires
vous parviennent.
Certaines dépendent du chef de projet, d’autres dépendent d’acteurs parfois fort différents.
8.2.2.1 Information sous le contrôle du chef de projet
Le planning ayant été établi, les données suivantes existent pour chaque tâche :
- date de début
- date de fin
- charge à prester
- charge déjà prestée
- charge restante
- ressources affectées
Il est évident qu’à l’établissement du planning, le poste ‘charge déjà prestée’ est à zéro, tandis
que ‘charge à prester’ et ‘charge restante’ ont des valeurs identiques.
________________________________________________________________________
_______________________________________________________________________________
Le projet ayant commencé, ces données vont subir des modifications.

Comment le savoir ?
Il s’agit ici de mettre en place un système de récolte de ces informations.

Mais de qui peuvent provenir de telles informations ?
Les seules à même de les fournir sont les ressources affectées à ces tâches.
C’est donc à ces personnes qu’il faut s’adresser.
Afin de systématiser cela, chaque personne devra remplir un formulaire indiquant pour une
semaine déterminée son activité pour chacun des jours qui la composent.
Ce formulaire est fréquemment appelé ‘time sheet’.
Bien entendu, un formulaire informatisé alimentant une base de données est la solution idéale.
Mais quelles informations doit-on retrouver sur ce formulaire :

- les nom et prénom de la personne
- le n° de la semaine
- par jour
o chaque tâche sur laquelle du temps a été presté
o le temps presté (par 30 minutes)
o le temps encore à prester
En tant que chef de projet ou responsable d’une équipe, un tel outil est indispensable.
En effet, non seulement celui-ci vous permet d’obtenir une partie essentielle des informations
qui vous sont nécessaires mais également un rapport écrit de chacune des personnes.
8.2.2.2 Informations en possession d’autres acteurs
D’autres informations ne sont pas directement dans la sphère du projet.

Il peut s’agir
- d’une réaffectation d’une ressource sur un autre projet
- de la démission d’une personne
- d’une maladie ou d’un accident
- de la décision du client de temporiser
8.2.2.3 Conclusion
Le planning n’est pas une garantie de succès. C’est un outil de gestion qui permet de savoir
où l’on est précisément et de pouvoir mettre des actions en place pour réduire l’impact
négatif.
Mais il n’est pas toujours possible d’en revenir au planning initial. Des actions comme la
renégociation des délais avec le client peuvent être initiées suffisamment tôt car le dérapage,
son ampleur et ses raisons ont pu être détectées à temps grâce au suivi du planning.
________________________________________________________________________
_______________________________________________________________________________
8.3 Gestion des ressources (Non)

La gestion des ressources est un élément essentiel à la réussite d’un projet et ceci qu’il
s’agisse de ressources matérielles ou humaines.
Ressources matérielles
Pour pouvoir développer une nouvelle application, il faut disposer du matériel adéquat et
suffisant.
Ex : si 3 programmeurs sont nécessaires, cela implique qu’il puisse disposer chacun
- d’un bureau
- d’une chaise
- d’un ordinateur performant (écran , clavier, processeur)
- des logiciels nécessaires (attention aux licences)
- des droits d’accès nécessaires
- des ressources nécessaires en matière de temps machine (CPU)
- des ressources nécessaires en matière d’espace mémoire
Même si le coût de certains composants (disque) est devenu dérisoire, vous seriez étonné par
le nombre de problèmes que vous pouvez rencontrer suite à des déficiences ou insuffisances
de matériel, même peu coûteux.
Dans le cadre de la vie d’un projet, il est important de pouvoir disposer de 3 environnements :
- environnement de développement
- environnement de tests ou d’acceptance
- environnement de production
Environnement de développement
C’est l’environnement le moins stable car c’est lui qui reçoit l’ensemble des développements
n’ayant fait l’objet que de tests unitaires.
Il est donc important mais difficile de gérer les ajouts successifs de manière à pouvoir plus
facilement identifier une source d’instabilité.
Environnement de tests ou d’acceptance
Cet environnement doit permettre de réaliser des tests d’intégration. L’intégration consiste à
mettre ensemble des éléments développés et testés séparément4.
C’est une étape essentielle qui nécessite un environnement dédicacé et contrôlé.
Dans cet environnement, des règles nettement plus strictes que dans l’environnement de
développement doivent être suivies.
4
le développement d’un nouveau moteur va nécessité la réalisation de différents composants ; même si, par
composant le cahier des charges est respecté et les tests positifs, il n’est pas certain que mis tous ensemble le
résultat sera parfait
une voiture de Formule 1 ne sera une réussite que si le moteur et le châssis s’allie parfaitement
des écuries ont raté leur saison parce que cette alliance ne s’est pas faite comme espérée
________________________________________________________________________
_______________________________________________________________________________
En matière de code, il n’est pas question d’ajouter n’importe quoi n’importe comment.
De même en matière de données, les actions doivent faire l’objet d’un contrôle (remise de la
base à zéro, utilisation/modification de données déjà présentes, …)
Des problèmes importants surgissent toujours au moment de l’intégration, il est essentiel de
pouvoir en délimiter rapidement et précisément les causes.
Pour cela, il faut être capable de reproduire de manière certaine les mêmes conditions.
Environnement de production
Lors du développement d’une nouvelle application, les 2 environnements précédents sont là
pour minimiser les problèmes qui surviendront en production.
Il est donc vital que l’environnement de tests et celui de production soient aussi identiques
que possible :
- mêmes machines
o taille mémoire
o vitesse du processeur
- mêmes version de logiciel
- capacité de simuler le nombre d’utilisateurs finaux
- capacité de traiter les volumes dans les mêmes conditions5
Expériences vécues
Des problèmes ‘réseau’ survenaient de manière régulière mais personne ne pouvait expliquer
pourquoi.
Dans ce cas, la seule attitude à adopter est une approche systématique qui consiste à
déterminer une liste de pistes possibles, de les examiner une à une (si possible en parallèle).
Parfois, pour progresser, la seule solution est de procéder par élimination.
Si ceci ne donne rien, il n’y a pas de honte à suggérer le recours à des spécialistes extérieurs.
Pour que leur intervention soit efficace et la moins coûteuse possible, un diagnostic précis est
essentiel. L’étape précédente fournira des informations fort utiles.
Ceci fut tout à fait efficace mais :

- il a fallu des mois avant que la décision soit prise de recourir à un expert
- pendant ces mois, un effort de standardisation fut entrepris de manière à ne plus
avoir des produits que d’un seul fournisseur
- la raison principale fut que le disque dur du serveur avait une capacité insuffisante,
ce qui obligeait des swaps permanents
Dans le cadre d’un autre projet, je fus confronté à un problème avec un logiciel. Ayant essayé
différentes choses mais sans succès, j’ai demandé et obtenu l’aide d’un expert. Même si ceci
ne permit pas de résoudre le problème (l’expert eu le même que moi), ceci nous donna la
possibilité de changer de stratégie, sans perdre trop de temps.
5
en production, l’application actuellement en cours de développement peut se trouver en concurrence avec
d’autres, ceci peut influencer les performances, la disponibilité du service
________________________________________________________________________
_______________________________________________________________________________
8.4 Ressources humaines (Non)
8.4.1.1 Introduction
Cet aspect est extrêmement important et, malheureusement, parfois un peu négligé.
En effet, il ne suffit pas de remplir des cases avec des noms.
Même si a priori toutes les conditions sont remplies, ce n’est que lorsque les personnes seront
réellement affectées au projet que vous pourrez savoir si la symbiose nécessaire entre les
personnes se fera ou non.
Ex :
À la recherche de ressources humaines sur un projet, la 1ère sélection se fait sur base du CV,
ensuite, et même si toutes les qualités techniques requises sont présentes chez les candidats,
un entretien en face à face est nécessaire de manière à se faire une meilleure idée du candidat
et de s’assurer que la fonction offerte correspond à ses aspirations.
A plusieurs reprises, des candidats avaient bien le profil requis mais ne désiraient plus faire la
même activité. A contrario, vous avez des personnes qui ne correspondent pas tout à fait mais
qui sont très motivées.
A certains moments, il faut donc savoir revoir ses exigences à la baisse.
8.4.1.2 Au niveau du projet
8.4.1.2.1 Avant le démarrage lui-même

Dès le début, il s’agit de s’assurer :
- que les personnes prévues sont en nombre suffisant
- qu’elles possèdent les connaissances requises ou qu’elles les posséderont6
- qu’elles seront disponibles au moment opportun
- qu’elles le resteront jusqu’au terme de leur mission
Il est clair que ceci ne peut être déterminé que si un planning précis a été établi.
8.4.1.2.2 En cours de projet

Mais, attention, un planning peut subir des modifications. Il ne faut pas oublier de tenir
compte des conséquences sur les points cités ci-dessus.
Si votre projet prend du retard, il se peut que certaines ressources ne soient plus requises
comme initialement prévu. La personne responsable doit en être informée, de même qu’il est
fort probable que sa mission ne se terminera pas non plus à la date initialement prévue.
Un autre projet en retard sur lequel des ressources qui vous sont nécessaires sont affectées
peut à son tour vous causez des problèmes.
6
un projet ne commençant pas forcément immédiatement et toutes les personnes n’intervenant pas en même
temps, un plan de formation peut être prévu
________________________________________________________________________
_______________________________________________________________________________
Votre projet n’est pas le seul en cours. Il en est un parmi d’autres. Il y a des interactions
entre les projets et pas forcément dans le sens que vous souhaiteriez.
Il y a aussi des événements sur lesquels vous n’avez que très peu de prise :
- démission
- affectation à un autre projet
Il y a des événements sur lesquels vous n’avez aucune prise

- maladie7
- accident
Cependant, si vous avez mis en place une bonne organisation, vous serez plus facilement à
même de faire face à ce genre de situation et de déterminer très rapidement les conséquences
qui en découlent.
Dans ce cadre, il est important d’établir un tableau qui permet de déterminer pour chaque
domaine du projet et d’une équipe qui en est le responsable et qui en est le back up.
Domaine Responsable Backup 1 Backup 2

Gestion projet Dupont Martin ---
Interfaces Jules François Dupont
Fonctionnel François Martin Dupont
Sécurité François Jules --
Simplement en établissement une telle liste, vous pouvez déjà vous rendre compte de
problèmes importants :
- pas de personne responsable
- pas de backup
- trop souvent les mêmes personnes se retrouvent dans cette liste
- …
Par contre, il est de la responsabilité du chef de projet, et, en général, de chaque personne, qui
coordonne l’activité de plusieurs autres de fournir régulièrement les informations qui leur sont
nécessaires.
Informations nécessaires ne signifie pas uniquement celles permettant le travail quotidien.
Il est fondamental que chacun se sente partie du projet. Pour cela, des occasions régulières et
systématiques doivent être prévues de manière
- à informer toute l’équipe sur le cadre général et les conditions du projet (ex : PV
du comité de pilotage, résultat d’une démo au client,…)
- à permettre à chacun de faire part de ses problèmes, de ses préoccupations
7
Quoique, dans certains cas, des personnes deviennent malades parce que le stress et la pression sont trop
importantes, parce que les efforts demandés sont trop importants sur une trop longue période, parce que des
congés ont été refusés, …
________________________________________________________________________
_______________________________________________________________________________
8.5 Exemple (Non)
Enoncé
Soit la situation suivante :
Après plusieurs discussions avec un client, le responsable commercial vous remet un

document.
Pour la prochaine réunion avec le client, il faut produire un document reprenant notamment
un planning et un budget.
Nous sommes le 17 mars 2003.
Le client souhaite disposer fin septembre 2003 d’une application « Internet » qui permettra de
passer des commandes en ligne. Le but est de diminuer le temps passé au téléphone pour des
renseignements en termes de prix, de disponibilité de marchandise, de délai de livraison, de
prise de commande.
Une fois la commande validée (disponibilité des produits/produits commandés, compte client
OK), l’information alimente directement le service logistique.
A partir de ce point, il n’y pas de différence de traitement avec les données en provenance du
service ‘commande clients’.
Lorsqu’une commande arrive au service ‘logistique’, celui-ci s’assure de la disponibilité des
produits et commande, si nécessaire, les produits manquants.
Pour commander, il faut d’abord s’être enregistré comme client et disposer d’un mot de passe.
Ensuite, le client peut parcourir le catalogue des produits. Différents critères de recherche
doivent être prévus : par thème, par nom, par code, ….
Le client doit immédiatement connaître le prix, le nombre d’exemplaires disponible, la
possibilité ou non de commander.
Le paiement ne se fait pas par Internet mais sur base d’une facture jointe à la livraison.
Les données transmises par Internet doivent alimenter directement le back office. Les
différents services concernés sont : achat, logistique (livraison+stock), comptabilité.
Le client doit pouvoir suivre par Internet le traitement de sa commande (enregistrée, préparée
pour être livrée le, livrée)
Le client demande qu’on lui dise la configuration requise en termes de hardware et de

software. Le client se chargera aussi bien de la commande de ce matériel que de son
installation.
Une réunion préparatoire est prévue avec le commercial le 24 mars.

Pour cette date, vous devez avoir établi une proposition de planning aussi bien en termes de
tâches que de ressources.
________________________________________________________________________
_______________________________________________________________________________
Approche
Périmètre de la demande
Il s’agit d’ajouter un nouveau canal pour effectuer des commandes. Il ne s’agit donc pas de
remplacer les canaux existants.
Le fait qu’il s’agisse d’un canal supplémentaire et non d’un canal remplaçant les autres est un
facteur diminuant la criticité.
Le but de ce nouveau canal est de minimiser l’intervention humaine en matière de commande

et de renseignements produit mais aussi de permettre au client internet de savoir où en est sa
commande.
Questions ouvertes
Y a-t-il déjà un système informatique traitant les commandes actuelles ?
L’énoncé dit seulement que ‘le traitement sera le même que celui des commandes par
téléphone, fax, bon de commande’ mais ne précise pas le degré d’informatisation de ce
traitement.
Délai
Délai souhaité par le client : avril-mai-juin-juillet-août-septembre = 6 mois
Rem :
étant donné que dans les 6 mois, il y a juillet et août, il faut considérer que vous ne disposez
en fait que de 5 mois.
De plus, nous sommes déjà mi-mars. Il ne faut pas sous-estimer le temps nécessaire à la
rédaction du contrat, aux dernières négociations, à la mise en place d’une équipe.
Dès lors, débuter début avril semble un peu irréaliste. N’oubliez pas de tenir compte du fait
qu’avril = vacances scolaires de Pâques.
Dépendances (➔ milestones dans le planning)
Il y a des dépendances :
- niveau hardware --> définir quand le matériel doit être disponible (le client en
ayant la responsabilité, c’est à lui de s’assurer que ce délai est réaliste
- niveau software --> même question que pour le matériel
- interface : la comptabilité installe un nouveau package ; ceci peut avoir un
impact puisqu’il faudra vérifier que les commandes arrivent bien dans la comptabilité
ainsi que les paiements ultérieurs et ceci non seulement pour la gestion interne de
l’entreprise mais également pour mettre ces infos à disposition du client Internet
Il semblerait qu’il n’y ait aucune expertise interne en matière d’Internet.

La question des formations se posent donc.
________________________________________________________________________
_______________________________________________________________________________
Certitudes
Il faut développer la partie ‘catalogue’.

- création du catalogue
- gestion du catalogue (ajout, modif, suppression)
- lien avec la base de données centrale
-
Il y a plusieurs interfaces :
- achat
- logistique
- comptabilité
- facturation
Le nombre d’interfaces est un facteur augmentant la complexité.
Il y a non seulement un flux descendant (client Internet → commande → logistique →

facturation → gestion compte client) comme dans les autres moyens de commande
Mais aussi des informations qui doivent venir par un flux ascendant en provenance de la
logistique et de la comptabilité (gestion compte clients).
Il est donc évident que l’installation d’un nouveau package comptable a une influence.
Le fait d’avoir un flux ascendant est un facteur augmentant la complexité.
Les postes suivants sont nécessaires :

- gestion de projet
- analyse
- conception
- développement
- test
- mise en production
- 1er suivi
Analyse
- interviews pour déterminer plus précisément le périmètre du projet
- gestion des accès
- s’assurer que les données en provenance de commandes saisies manuellement et
venant d’Internet sont bien identiques en libellé, taille, signification
- mise en place du catalogue
- interface : info en provenance de la compta si situation not OK
- interface : info sur la situation : commande enregistrée, livraison demandée,
facture payée
- possibilité d’accès pour modifier cette info (somme modique, geste commercial)
Constitution de l’équipe
Plus le temps est réduit, plus il faudra faire des tâches en parallèle, plus il faudra de
ressources.
Profil
________________________________________________________________________
_______________________________________________________________________________
- un webdesigner
- un web développeur
- un DBA
- un chef de projet
- un analyste
Comité de pilotage :
- étant donné le court laps de temps, il faudrait une fréquence supérieure à celle du
mois
Gestion des risques
Temps réduit Avoir les ressources suffisantes pour travailler

en parallèle
Obtenir rapidement des réponses du client
(voir responsabilités du client)
Tâches en parallèle Temps de coordination suffisant
Personne dédicacée = chef de projet
Ressources spécialisées Le nombre ne suffit pas, il faut directement les
bonnes personnes avec le bon profil
Pas de connaissance technique suffisante du Ressources adéquates du fournisseur
client
Disponibilité ressources client (équipe réduite) Voir responsabilité du client
Dépendance externe Voir responsabilités du client
Logiciel comptable Milestones clairs dans le planning
Matériel
________________________________________________________________________
_______________________________________________________________________________
Représentation graphique
S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11 S12 S13 S14 S15 S16 S17 S18 S19 S20 S21 S22 S23 S24 S25
réception du contrat
Analyse
HW/SW installé
Développement
SW compta
Tests
Acceptance
MEP
1er suivi
________________________________________________________________________
_______________________________________________________________________________
9 Etude préalable (Non)
9.1 Généralités (Non)
Etude préalable
Ce chapitre pourrait s’intituler de plusieurs manières :
- prise de connaissance
- étude de faisabilité
- établissement d’un devis (ex : application Vormelek)
Le plus important dans le nom de ce chapitre est le mot ‘préalable’.

Préalable signifie ‘ qui se déroule avant’ mais avant quoi ?
Résultat
Cette phase doit produire quelque chose.
Ceci sera un rapport qui fera l’état

- des connaissances acquises
- des problèmes rencontrés
- des questions restées ouvertes et de leur influence sur la conclusion
- des interfaces nécessaires
- différents scénarios.
Ce rapport doit s’inscrire dans le cadre du schéma directeur, il doit clairement y faire
référence.
Base de décision
Les spécialistes ayant fait leur travail, ce rapport doit permettre à des décideurs de prendre
une décision fondamentale :
- STOP
- GO
- Compléments
________________________________________________________________________
_______________________________________________________________________________
Contenu
Il est essentiel de comprendre l’importance que prend la forme utilisée pour la rédaction par
rapport au fond.
Tout ceci doit être pensé dans un langage compréhensible par des non informaticiens qui, sans
doute, pour la plupart, n’ont pas participé à toutes les discussions, réflexions, études qui ont
permis la rédaction d’un tel document.
Il y a donc un certain nombre de sujets qu’il faut impérativement aborder de manière à

permettre au lecteur de suivre l’entièreté du raisonnement et de comprendre les fondements de
la conclusion. Il en va de votre crédibilité.
Quels sont les points importants qui doivent figurer dans un tel rapport ?
Exemple de plan :
- indiquer les personnes qui ont contribué à cette étude en indiquant à quel titre ils
sont intervenus ainsi que leur fonction habituelle
- indiquer le contexte dans lequel l’étude a eu lieu

o définition du périmètre
o lien avec le schéma directeur
- indiquer la démarche qui a été suivie

o définition du périmètre
o interviews
o lecture de documents
o présentation d’outils ou de process déjà existants
- indiquer les questions restées sans réponses et, éventuellement des suggestions
o ex : recherche et étude de logiciels existants
- indiquer les limites de l’étude (aspects non abordés, indisponibilité de personnes,

de documents, …)
- indiquer, s’il y a lieu, différents scénarios avec leurs implications
- indiquer vos recommandations
________________________________________________________________________
_______________________________________________________________________________
La réalité
Dans les points précédents de ce chapitre, nous avons pu aborder le problème fondamental
face auquel se trouve tout responsable de la réalisation d’une nouvelle application, pour autant
que cette personne intervienne au tout début du processus.
Il est évident que cette situation ne se présente pas toujours et que vous serez amené à
intervenir dans des développements d’application qui ont dépassé ce stade.
Exemples :
Exemple 1
On vous demande de réaliser un Website qui a juste pour but de montrer que l’entreprise en
possède un et, s’il y a des utilisateurs, de recueillir des données à l’aide d’un formulaire.
Voilà le scope tel qu’il est décrit. On pourrait alors dire qu’il n’y a pas d’étude préalable
nécessaire.
La question est : le scope est-il suffisamment précis ?
- Si la réponse est oui, alors il n’y a pas besoin d’étude préalable.
- Si la réponse est non, alors une étude préalable est nécessaire.
Sa durée dépendra des questions que vous poserez et des réponses que vous
obtiendrez.
Dan cet exemple, il est fondamental de ce faire préciser ce que devient ce formulaire une fois
complété.
Question que devient le formulaire une fois complété

Réponse le formulaire ainsi complété sera simplement imprimé et reviendra
dans le circuit normal
Conclusion il n’est pas question d’interface avec le reste du SI de l’entreprise
Question Quel est le but de ce document ?

Réponse Faire une commande
Question N’importe qui peut-il faire une commande pour n’importe qui ?
Réponse Non
Conclusion L’aspect sécurité, identification avec certitude que la personne
passant la commande a autorité pour le faire.
Ceci implique toute une gestion qui va bien au-delà de mettre un
website à disposition.
Exemple 2
Un client vous demande la réalisation d’un website et pour ce faire a établi un Cahier de
Charges. A la lecture de celui-ci, vous, en tant que professionnel, vous apercevez que des
points essentiels sont manquants, peu clairs, non tranchés. En prenant contact avec le client,
cette impression de flou est confirmée par les réponses que vous recevez.
________________________________________________________________________
_______________________________________________________________________________
A ce moment, alors que le client et vous-même pensiez que le projet pouvait démarrer (car ici
l’étude préalable avait été réalisée par le client), vous devez amener le client à s’apercevoir
lui-même que le temps n’est pas encore venu de commencer le projet proprement dit mais
qu’il faut retourner au stade d’une étude préalable.
Cependant, cette étape a forcément existé. Cela ne signifie pas que vous trouverez
obligatoirement un document répondant aux critères ci-dessus.
Dans certains cas, le processus qui permet de passer de la réflexion à la décision peut être
extrêmement bref et uniquement basé sur des arguments tels que :
- je l’ai décidé
- la concurrence nous y oblige
- il faut réduire les coûts
- le logiciel n’est plus supporté
- …
Il se pourrait également que la phase d’étude préalable prévoie également l’étude de logiciel
existant.
Si tel est le cas, voici une liste de critères à prendre en compte de manière à établir une
comparaison :
Prix Y compris l’achat, les upgrades, les formations

Solidité financière L’éditeur et/ou le distributeur sont-ils fiables d’un point de vue
financier
Ergonomie Facilité d’utilisation, possibilités du choix de la langue (y
compris pour la documentation)
Volume Quelle est la capacité maximale ?
Evolutivité Si mes besoins augmentent, y a-t-il des moyens d’évoluer
Technologie La technologie utilisée est-elle conforme au plan stratégique de
l’entreprise
Distribution Combien y a-t-il de licences actuellement ? En Europe, en
Belgique ?
Support Se fait-il en Belgique ? Se fait-il dans ma langue ?
________________________________________________________________________
_______________________________________________________________________________
9.2 Les différentes phases

- Phase préparatoire
- Phase ‘étude de l’existant’
- Phase de conception générale
- Phase de conception détaillée
- Sélection d’un sous-traitant ou d’un progiciel
Phase préparatoire
Cette phase est essentielle pour garantir un résultat de qualité.
C’est déjà ici que les chances de succès sont préservées ou non.
A cette fin, cette phase doit

- définir le cahier des charges de l’étude préalable
- préciser les modalités pratiques ainsi que les personnes qui seront impliquées
- informer les personnes concernées
o de manière à ce qu’elles se préparent
o de manière à être sûr qu’elles ont bien été informées
Différents types d’activités peuvent être identifiés :

- activités de réalisation
- activités de gestion de projet
- activités d’assurance qualité
9.2.1.1 Activités de réalisation
Les réalisations seront

La détermination du périmètre de l’étude
Ce qui est inclus
Ce qui ne l’est pas8
La définition de manière précise de l’objectif du système d’information (SI)
L’établissement des caractéristiques principales que le SI devra respecter
• cohérence par rapport au schéma directeur
• utilisation de technologies prédéfinies
• …
l’attente en matière de degré de détail de l’étude de l’existant
8
Ceci est un moyen d’éviter des ambiguïtés. Par exemple, indiquer que la recherche de logiciels existants ne fait
pas partie du périmètre, ou encore qu’une reprise de l’existant a été explicitement exclue.
________________________________________________________________________
_______________________________________________________________________________
Pour ce dernier point, le degré de détail sera inférieur si le recours à un progiciel a déjà été
décidé ou s’il s’agit d’utiliser un autre mode de travail (ex : similaire à celui d’une autre
société du groupe)
9.2.1.2 Activités de gestion de projet
Il est fondamental que cette phase détermine :

- le chef de projet
- la composition du Comité de Pilotage
- la méthodologie à suivre
- les livrables (= output de la phase)
- le timing
- les moyens nécessaires
o workshop
o lecture de document
o interviews
o disponibilité requise des intervenants
- les risques ainsi que leur qualification (important, moyen, faible) et la liste des
actions pour les réduire
Exemple de risques et d’actions pour les réduire
une seule personne compétente dans un Prévoir la formation d’une autre

domaine personne ; prévoir le recrutement d’une
personne possédant déjà cette
connaissance
situation financière difficile d’un Rechercher un autre fournisseur
fournisseur
disponibilité nécessaire de personnes en Vérifier que le planning permet la
période de vacances disponibilité requise (présence effective
sans devoir remplacer d’autres personnes
absentes)
9.2.1.3 Activités d’Assurance qualité
Rédiger et faire valider le ‘Plan Qualité’ du projet
Qu’entend-on par Assurance Qualité

- en général
- pour cette phase spécifique ?
________________________________________________________________________
_______________________________________________________________________________
- établir les objectifs de qualité9

- déterminer les responsables de la mesure et du suivi de la qualité
- s’assurer du respect des procédures et méthodes de réalisation10
- prévoir des points et des règles de contrôles11
- suivi de la disponibilité effective des ressources
- déterminer des points de revue formelle12 (par opposition au contenu)
9
établissement systématique de PV de réunion, utilisation de format standard en matière de documentation (voir
normes et standards)
10
obtention des accords nécessaires (du DBA, d’une cellule d’architecture technique, …) = la règle ; moyen de
le vérifier, une des premières pages du document doit répertorier toutes les personnes devant approuver le
document et leur signature doit être présente.
11
particulièrement en matière de réception ou de validation (version ‘brouillon’, remarques, version définitive
avec un seul cycle possible)
12
présence de PV de réunions, du respect du formalisme en matière de documentation
________________________________________________________________________
_______________________________________________________________________________
Etude de l’existant (Non)

L’étude de l’existant rempli plusieurs rôles importants
- apprendre le métier
- apprendre le fonctionnel
- apprendre la technique
- nouer des contacts avec les gens de terrain dans les différents domaines (dans une
entreprise, l’informatique est perçue comme un tout, un domaine peu accessible)
Il importe d’avoir une démarche cohérente, suffisante pour obtenir les informations
nécessaires mais qui minimise, en temps, la contribution du client.
Il est important d’avoir une vue globale et d’être connu et reconnu à différents niveaux de la
hiérarchie.
Comment y arriver ?
9.2.2.1 Etape 1
Pour chacun des services entrant dans le cadre de l’étude, obtenez une présentation par son
responsable sur site.
Vous pourrez ainsi immédiatement vous rendre compte du cadre de travail, de la disposition
des personnes, de l’aménagement des bureaux, de la présence de matériel tel que imprimante,
photocopieuse, scanner, …
Ceci vous permettra de poser des questions sur des éléments non mentionnés (outil, bureaux
vides, …) mais sera aussi un bon aide-mémoire pour la personne qui effectue la présentation.
Vous pourrez également déterminer les différents postes de travail (secrétaire, gestionnaire de
dossier, commercial, responsable d’équipe, …)
S’il y a une découpe en tâches bien définie, demandez que la présentation suive cet ordre. Il
est alors plus facile de déterminer s’il y a ou non des oublis.
Par la force des choses, on vous présentera également des personnes du service. Si elles vous
sont présentées spontanément par le responsable, il est important de nouer des contacts avec
elles car il s’agit souvent de personnes reconnues pour leur compétence par le responsable.
9.2.2.2 Etape 2
L’étape 1 vous ayant permis d’identifier les différents postes de travail et d’avoir fait
connaissance avec certains de leur représentant, il vous sera plus facile de demander et
d’obtenir un entretien avec un représentant de chaque poste et ceci sans la présence de son
responsable.
________________________________________________________________________
_______________________________________________________________________________
Afin de faciliter la communication avec cette personne, il est essentiel d’aborder l’entretien en
restant le plus près possible de son vécu. En effet, il est très courant d’avoir des personnes
très compétentes dans leur activité mais rencontrant d’énormes difficultés à exprimer de
manière structurée et complète le contenu.
A cette fin, il faut matérialiser le plus possible les actions décrites par votre interlocuteur.
9.2.2.2.1 Cas concrets

Ceci se fera en demandant et en obtenant copie de cas concrets (= remplis) :
- documents reçus et envoyés
- print d’écrans
Il est étonnant de constater le nombre d’informations que l’on peut recueillir grâce à cela.
- champs non remplis (cas d’exception ou plus utilisés)
- mention ajoutée (cas non prévu = non géré ou utilisation détournée du document)
- plusieurs exemplaires : utilité de chacun d’entre eux ?
Egalement, par le fait de suivre le plus concrètement possible l’activité, vous remarquerez
immédiatement si des faits ne vous sont pas mentionnés
Ex : sur base d’un document reçu, le recours à un écran permet d’indiquer une décision ; en
demandant sur quels critères cette décision est prise vous apprenez qu’un recours à un
listing, un appel téléphonique, la consultation de la base de données d’un autre service
est fait
Conseil pratique :
Il est fréquent qu’un document ait connu plusieurs versions. Assurez-vous pour chacun des
documents que vous avez bien la dernière version.
9.2.2.2.2 Support d’informations utiles à la gestion interne du poste de travail
- recensement (listing, fichier spécifique, fichier personnel, plannings muraux)

- par support, il est important de connaître
o l’utilité du support
o l’utilité de chaque champ
o les valeurs possibles de chaque champ
o le support est-il partagé ou spécifique à l’agent ?
o les documents servant à son alimentation (input)
o les documents produits grâce à lui (output)
o nbre d’infos notées sur le document
o fréquence (plusieurs fois par jour/rare13)
o utilisation réelle des informations
13
le fait qu’un événement se produise rarement peut impliquer la nécessité de noter cette information afin de
pouvoir y recourir parfois après plusieurs mois et d’être ainsi à même de donner des éléments importants comme
la date, le client, une description courte mais précise, le montant, une référence
ex : geste commercial dans le cadre d’une indemnisation : en cas de contrôle, comment le gestionnaire du dossier
peut-il encore se rappeler précisément qui a pris la décision, les raisons de cette décision, l’impact de la décision,
…
________________________________________________________________________
_______________________________________________________________________________
Lorsque la nouvelle application s’adresse soit à une activité peu ou partiellement informatisée,
soit à la révision d’une application existante mais ancienne et ayant peu ou pas évolué, vous
rencontrerez presque toujours des supports non officiels.
Après analyse et synthèse, il s’agira de déterminer si de tels process feront ou non parties du
périmètre de l’application à développer.
Il est important que les personnes utilisant ces process soient informés du fait qu’ils ont été
recensés et qu’ils feront ou non partie de l’application.
Etant donné que nous ne sommes encore qu’au début, il est possible pour ces personnes
d’entreprendre des actions afin de modifier la décision.
9.2.2.2.3 Système de classement
- recensement (armoires, tiroirs de bureau, classeurs, fichiers, …)

- informations stockées
o utilité14 théorique, légale, réelle
o volume
o fréquence de mise à jour
o ordre de classement
▪ par demandeur
▪ par gestionnaire
redondances éventuelles
9.2.2.2.4 Machines utilisées

Exemples : téléphone, fax, imprimante, photocopieuse, scanner
Ici aussi, il est important

De les recenser
De s’assurer de leur utilité
De déterminer leur fréquence d’utilisation
De déterminer leur caractère critique (que se passe-t-il en cas de panne ?)
9.2.2.2.5 Descriptif du poste de travail

Dans certains cas, vous pourrez obtenir des descriptifs de poste de travail.
14
des informations sont parfois stockées ‘au cas où’ mais dans les faits jamais utilisée, d’autres ne sont pas
utilisées mais doivent être gardées pour respecter des obligations légales
________________________________________________________________________
_______________________________________________________________________________
9.2.2.2.6 Arrivée de nouvelles personnes dans le service
Afin d’accélérer l’intégration d’une nouvelle personne, un dossier de formation lui est parfois
remis.
Si un tel dossier existe, il est extrêmement utile d’en demander un exemplaire. Ceci vous
permettra :
- de vous rendre compte de la perception en interne
- des points jugés importants et de points absents
D’autres organisations prévoient des sessions d’information. Il serait utile de pouvoir assister
à l’une d’entre elles ou au moins vous faire remettre le matériel en servant de base.
9.2.2.3 Etape 3
Sur base de toutes les informations réunies, il est à présent possible de constituer une
documentation aussi bien en matière de données que de traitements.
Il se peut que la documentation existe déjà mais il est rare qu’elle soit à jour et sous la forme
que vous souhaiteriez.
Cependant, si une telle documentation existe, il peut s’avérer utile de la parcourir de manière
à vérifier que des éléments importants ne vous ont pas échappé.
________________________________________________________________________
_______________________________________________________________________________
10 Développement (Non)
10.1 Introduction
Le démarrage de cette phase ne peut se faire que lorsque les fondations de l’application sont
connues.
Tant qu’il n’est pas commencé, il est encore possible de modifier des orientations à moindre
coût. Cependant, ce n’est pas une raison pour ne pas gérer de telles demandes (voir le
chapitre Procédure de contrôle des demandes de changement)
En cours de développement, les demandes de modification peuvent toujours être examinées

mais avec une extrême prudence.
En effet, alors que la préparation avait permis des validations successives, une réflexion
globale, vous vous trouvez confronté à des demandes ponctuelles.
Il est alors souvent peu aisé de s’assurer de tous les impacts que pourraient avoir cette
demande. Dans certains cas, il est tout simplement impossible d’en tenir compte.
L’exemple de la construction d’une maison permet aisément de comprendre ceci.

Tant que la construction n’a pas démarré, la modification des plans, dans une certaine mesure,
peut se faire à un coût modéré.
Par contre, une fois la construction entamée, certaines modifications, parce que mineures,
peuvent toujours être prises en compte et parfois sans surcoût, d’autres seront tout simplement
impossibles (modifier l’emplacement, la hauteur d’un mur porteur, changer la cuisine de
place, vouloir des caves, …).
Le développement ne signifie pas que la tâche de l’analyste fonctionnel est terminée.
En cours de développement, il est fréquent de buter

- sur des problèmes techniques (selon la documentation du fournisseur, ceci était
possible mais dans la réalité non),
- sur des ambiguïtés (plusieurs façons d’interpréter une spécification)15,
ex : cuisson à four moyen
micro onde à pleine puissance
- sur des contradictions,
- sur des inconsistances (dans les mêmes circonstances, un traitement est décrit de
manière différente à 2 endroits)
Pour éclaircir tous ces points et prendre une décision, l’intervention de l’analyste fonctionnel
est nécessaire.
15
l’enregistrement sera détruit dans la base : parle-t-on d’un delete physique ou logique ?
Y a-t-il un besoin d’historisation ?
________________________________________________________________________
_______________________________________________________________________________
10.2 Les activités

A mon sens, 5 activités peuvent être identifiées
- analyse d’impact
- élaboration ou mise à jour d’un design détaillé
- coding proprement dit
- tests unitaires
- assurance qualité
Analyse d’impact
Le but de cette activité est de s’assurer que tous les éléments sont réunis avant d’entamer la
réalisation proprement dite.
Les conditions suivantes doivent être réunies :

- les spécifications sont claires et sans ambiguité
- une solution permet de les réaliser
Ces documents doivent être distribués à toutes les personnes impliquées dans le processus
(spécification, solution, développement, testing, sécurité, …).
Chaque groupe concerné doit créer sa partie d’un document d’analyse d’impact.
Lorsque ceci est fait pour l’ensemble des intervenants, l’information est communiquée à tout
le monde et une réunion doit avoir lieu afin de s’assurer qu’il ne reste pas de points litigieux.
Le travail de réalisation concrète peut alors commencer.
Design détaillé
Le travail de réalisation doit commencer par une phase de réflexion aboutissant dans un
document.
Ce document va décrire en détail en quoi cette partie de développement consiste, son

implémentation et comment les parties existantes vont en être affectées.
Cette phase activité est essentielle d’une point de vue documentation (particulièrement en cas
de changement de ressources) mais également en matière de réflexion pour le développeur
(notamment pour la maintenabilité → réutilisation, respects de normes et standard
Il s’agit ici, au niveau technique, de la même démarche suivie au niveau de l’analyse

fonctionnelle. En effet, là aussi, il faut passer d’un niveau ‘high level’ vers un niveau
‘detailed’.
________________________________________________________________________
_______________________________________________________________________________
Ex : saisie d’une facture = high level

Accès à l’écran xxx
Encodage des données
Validation des données
Enregistrement de la facture
Chacun de ces points doit faire l’objet d’un détail.

Encodage des données
Saisie se fait par le clavier ou choix dans une liste
Déterminer les données obligatoires et facultatives
Déterminer comment on passe d’une zone à l’autre
Déterminer l’ordre de passage
Coding
Le maximum de précaution ayant été prise, il est à présent possible d’écrire le code.
Ceci doit se faire en appliquant les standards préalablement définis.
Test unitaire
Il ne suffit pas de coder encore faut-il vérifier que le résultat est bien conforme aux attentes.
Pour cela des tests doivent être réalisés. Il s’agit ici de tests limités.
Ex : développement d’un contrôle empêchant l’introduction d’une date dans le passé
Le test unitaire sera de vérifier que, par introduction sur l’écran d’une date dans le passé, le
message d’erreur apparaît bien.
Ce test ne préjuge pas de l’endroit où ce test sera utilisé. S’il est utilisé dans un cas non
souhaité, l’erreur ne sera pas au niveau du contrôle mais de l’appel intempestif à ce contrôle.
Assurance qualité
Une autre personne que le développeur (ex : responsable du team) va vérifier que, pour
chaque partie du code indiquée comme terminée, les différents éléments (analyse d’impact,
respects des standards et de l’analyse d’impact dans le coding, tests unitaires) sont bien
présents.
________________________________________________________________________
_______________________________________________________________________________
Outil de versioning
Il s’agit ici de gérer les sources et de pouvoir déterminer quelle version de code se trouve
dans quel release.
Ceci est évidemment essentiel dans le cadre de grands projets mais également de plus en plus
dans des projets plus limités.
En effet, de plus en plus souvent, même pour des projets de taille limitée, une découpe en
release est faite.
Il est donc fréquent de se retrouver avec un release en production, un release en ‘acceptance’

et un release en développement.
Lorsqu’une erreur est détectée dans une de ces releases, il faut pouvoir déterminer le code
précis qui s’y trouve afin de pouvoir d’une part déterminer la source de l’erreur et la façon de
la corriger.
Ainsi, parfois, il est possible de simplement attendre la fourniture de la release suivante pour
que le problème soit résolu s’il s’avère qu’il ne se produit plus avec le nouveau code.
Attention, comme le code n’est pas identique d’un release à l’autre, même si le problème se
produit dans les 3, il se peut que la correction soit différente dans les 3.
________________________________________________________________________
_______________________________________________________________________________
11 Procédure de contrôle des demandes

de changement (Non)
Une fois que les 2 parties ont validé un document, toute modification à y apporter doit faire
l’objet du suivi d’une procédure.
Ceci est valable que la modification soit demandée par le client ou par le fournisseur.
Cette procédure poursuit différents buts :
- documenter les demandes de changement
- permettre une évaluation correcte
- obtenir un accord des 2 parties
o oui + conséquences (délai, coût)16
Exemple :
Une demande de changement sur le projet (DCP) sera le moyen de traiter tout changement.
DCP doit décrire
- le changement
- la raison du changement
- l’effet du changement sur le projet
Le Project Manager de la partie demanderesse, après examen, transmettre la demande au

project manager de l’autre partie
Les 2 Project Manager (client et fournisseur) examineront la demande et soit l’approuveront

pour investigation plus détaillée, soit la rejetteront.
Si l’investigation est autorisée, les Project Managers signeront la demande. Ceci sera la
preuve de leur approbation des charges résultant de l’investigation.
Le fournisseur facturera le client pour toutes charges semblables.
L’investigation déterminera l’impact qu’aura la réalisation de cette demande sur le prix, délai
et autres clauses de l’accord.
Une Autorisation de Changement et/ou une DCP doivent être signées par les 2 chefs de projet
afin d’autoriser l’implémentation des changements.
16
selon la demande, il peut aussi s’agir d’une réduction (abandon d’une fonctionnalité, contrôles manuels et non
plus automatiques, …)
________________________________________________________________________
_______________________________________________________________________________
Step Other
Calendar Step/Trace
# process/procedure
When needed 1 Raise change request
Change request
raised
2 Perform initial assessment of

change request
Change request Change request Change request

assessed deferred rejected
Based on change
board schedule
3 Accept change request
for analysis
Change request
Change request Change request
accepted for
deferred rejected
analysis
Based on 4 Analyze impact

timeframe
validated by
change board
Change request
analyzed
Based on decision
board schedule
5 Approve change
Change request
Change request Change request
approved for
deferred rejected
implementation
Change management procedure 1
________________________________________________________________________
_______________________________________________________________________________
Step Other
Calendar Step/Trace
# process/procedure
Change request
approved for
implementation
6 Create change orders
Change orders
raised
Based on
implementation 7 Launch change orders
schedule
Change order
started
Record completion of change

Periodically and/or
when completion
8 order
is notified
Change order
closed
On completion of
last change order
9 Record completion of change
request
Change request
implemented
Change management procedure 2
Source : IBM
________________________________________________________________________
_______________________________________________________________________________
12 Sécurité (Non)
12.1 Introduction
La sécurité couvre différents domaines mais surtout il y a 2 types de sécurité :
- la sécurité interne
- la sécurité externe
12.2 Sécurité interne

Cette sécurité se subdivise en 2 domaines :
Les droits d’accès
Les copies de sauvegarde
Les droits d’accès

Il est rare que dans une application tout le monde ait les mêmes droits en matière d’accès de
données. On entend par là la visualisation, la modification, la destruction de données.
Il n’est pas rare d’avoir 3 niveaux :

- l’utilisateur de base
- l’utilisateur avec pouvoir de décision
- l’administrateur
Il est important de créer des catégories ou profils d’utilisateur, de manière à ne pas devoir
créer et gérer un profil par utilisateur.
Ainsi, lorsqu’une nouvelle personne arrive, il suffit de lui associer le profil adéquat pour lui
donner tous les accès requis.
S’il est évident que lorsqu’une personne nouvelle arrive une requête sera introduite pour lui
donner accès au système, il en va tout différemment lorsqu’une personne ne devrait plus avoir
d’accès.
Il n’est pas rare de voir des applications reprenant des personnes qui ont depuis longtemps soit
changé de fonction ou même quitté l’entreprise.
________________________________________________________________________
_______________________________________________________________________________
Les copies de sauvegarde
12.2.2.1 Introduction
Dans le monde actuel, l’informatique a pris un rôle tout à fait déterminant. A tel point que
lorsque le système informatique n’est pas opérationnel c’est pratiquement toute l’activité
d’une entreprise qui se retrouve paralysée.
Je pense que chacun d’entre vous a vécu l’une ou l’autre expérience de ce type avec une
administration, une banque, …
Ceci est le seul moyen de garantir qu’un problème rendant l’application inutilisable n’aura
que des conséquences les plus limitées possibles et ceci aussi bien en matière de perte de
données que de temps d’indisponibilité
12.2.2.2 Cas normal
La perfection n’étant pas de ce monde, il est impossible de pouvoir garantir une fiabilité à
100%. Cependant, des mesures peuvent être prises de manière à minimiser l’impact d’un
problème.
La prise régulière et fréquente de copies de sauvegarde est une de ces mesures.
Attention, il ne suffit pas d’en prendre, il faut encore pouvoir s’en servir dans un délai le plus
court possible.
Ex : problème du système à 11h30

Dernière copie de sauvegarde prise : la veille à 20h00
Temps s’écoulant entre la survenance du problème et la restauration de la copie : 1h00
Ceci implique que toutes les opérations traitées entre la veille 20h00 et aujourd’hui 11h30
sont perdues.
Pour certaines entreprises, cela est acceptable ; pour d’autres non.
En fonction des moyens que l’on veut mettre et du risque que l’on est prêt à prendre, les
modalités seront différentes.
Quelle que soit l’entreprise, il est vital de constituer plusieurs jeux identiques de copie :
- un destiné à la salle informatique
- un destiné à une pièce sécurisée en matière incendie
- un dans un autre lieu que celui de l’entreprise.
12.2.2.3 Cas du ‘Disaster recovery’
Le principe de copies de sauvegarde étant acquis, il faut encore penser à la situation de

‘disaster recovery’.
Ceci traite de la destruction totale du site informatique aussi bien le bâtiment, que les
machines, que les copies de sauvegarde.
________________________________________________________________________
_______________________________________________________________________________
La question à traiter est de savoir en combien de temps un système informatique peut être
rétabli.
Cette question n’est évidemment pas propre à votre application. Cependant, il se peut que
votre projet concerne une future application tout à fait cruciale pour l’entreprise et qu’une
telle réflexion n’ait encore jamais eu lieu.
Même si ce plan existe déjà, il faut s’assurer que la nouvelle application en fera bien partie
intégrante. Des tests devront donc être réalisés à ce sujet.
12.3 Sécurité externe

Il s’agit ici d’empêcher que des personnes extérieures ne puissent s’introduire dans le système
d’information de l’entreprise.
Selon les activités gérées, le type d’application développée (Internet,…), la sensibilité des
données gérées, la sécurité, toujours présente, sera plus ou moins forte.
Attention, ceci peut conduire à des obligations en matière d’architecture technique (firewall)
de manière à protéger le système d’information de l’entreprise.
Dans les dernières années, des cas célèbres de ‘hackers’17 ont été révélés.
17
personne ayant pour but de pénétrer le système d’information d’une organisation soit ‘seulement’ pour en
démontrer l’insécurité soit pour des buts bien moins avouables (espionnage industriel, …)
________________________________________________________________________
_______________________________________________________________________________
13 Performances/Volumes (Oui)
13.1 Performances
Si le contenu fonctionnel est généralement défini, il en est plus rarement de celui des
performances.
Or, même si une action se déroule parfaitement d’un point de vue technique et en toute
sécurité, elle peut nécessiter tellement de temps qu’elle en devient non fonctionnelle.
En général, on retrouve tous les éléments ayant trait à cette matière dans un SLA (Service
Level Agreement).
Ce document est essentiel puisqu’il définit à quoi le fournisseur s’engage en matière de
service.
Ce document couvrira des domaines tels que :

- le temps moyen d’une transaction
- la disponibilité du service
- le temps d’intervention du fournisseur en cas de problème (Prise en Charge)
- toute la problématique de recovery18 et de disaster recovery19
13.2 Volumes
Dès le début d’un projet, il est important de déterminer les volumes à traiter.
Les volumes de données à gérer, accéder, stocker sont un des éléments importants influençant
la performance.
Ceci est une aide précieuse pour le responsable de la base de données qui doit concevoir ses
tables, index, de manière à minimiser les temps d’accès.
18
problème n’affectant qu’une partie du système
19
problème affectant l’entièreté du système et du site ‘entièrement détruit’
________________________________________________________________________
_______________________________________________________________________________
14 Tests (Oui)
14.1 Introduction
Cet aspect est souvent sous-estimé, notamment pour le temps que ce point nécessite.
Non seulement le temps est sous-estimé mais, en plus, lorsqu’un projet a dû retard le temps de
test se trouve déjà entamé alors qu’en fait le développement est toujours en cours.
Ceci peut se marquer soit par un jeu de vases communicant : diminuer le temps de test pour
augmenter celui de développement a due concurrence, soit de commencer à consommer le
temps de test mais sans le dire.
Le but d’un développement est toujours d’ordre fonctionnel avec, la plupart du temps, des
conséquences organisationnelles. L’aspect technique n’est là que pour rendre le fonctionnel
possible.
Il faut éviter de se laisser enfermer dans des considérations uniquement techniques.

C’est pourquoi le fait de tester le côté fonctionnel à chaque étape permet de garantir ce point
essentiel et d’éviter qu’une solution ne soit que technique.
Ex : une solution peut être parfaite d’un point de vue technique mais inacceptable
fonctionnellement en raison d’un temps de réponse beaucoup trop long.
Les tests sont le moyen par lequel on valide le système. Ici, il ne peut être question de
découverte. Le système ayant été parfaitement spécifié et validé, ce qu’il doit faire est donc
connu.
Tout test doit donc inclure le résultat attendu à l’issue de ce test. Ce résultat attendu sera le
point de comparaison avec le résultat réel obtenu.
Chaque type de test doit faire l’objet de la rédaction d’un document.
Ce document doit faire contenir une description :

- de l’objet du test
- de la façon dont le test va s’effectuer (= scénario)
- des résultats attendus
- de la façon dont la preuve sera apportée
________________________________________________________________________
_______________________________________________________________________________
14.2 Tests unitaires
But
Les tests unitaires se font tout au long du développement. Ils ont pour but de garantir que
chaque partie développée a été testée avec succès de manière indépendante.
Définition
Tests unitaires = tests d’une fonctionnalité spécifique prise isolément sans tenir compte de
l’amont et de l’aval de celle-ci.
Comment ?
Ex :
Identification d’un membre
introduction du n° Vérification uniquement chiffre accepté

Accès à la base de données La table est lue
Retour de l’information sur Affichage soit d’un message indiquant la
écran non validité et la raison (n° inconnu, validité
expirée, …) soit du signalétique
correspondant au membre
Pour tester ces différents points, le testeur va décrire dans un document comment il va faire :
Prévoir la saisie d’un n° non entièrement numérique
Prévoir la saisie d’un n° entièrement numérique
Existant
Non existant
Prévoir dans la base de données au moins
Un n° d’un membre OK
Un n° d’un membre résilié
Ex : saisie et enregistrement d’une date qui ne peut être antérieure à la date du jour
introduction de la date Vérification qu’il s’agit bien d’une date

Vérification que la date est au moins égale à
la date du jour
Retour de l’information sur Affichage soit d’un message indiquant la
écran non validité et la raison (n° inconnu, validité
expirée, …) soit enregistrement de la date
________________________________________________________________________
_______________________________________________________________________________
Pour tester ces différents points, le testeur va décrire dans un document comment il va faire :
Prévoir la saisie
d’une date < date du jour (cas n°1)
d’une date = date du jour (cas n°2)
d’une date > date du jour (cas n°3)
Vérifier que
(cas n°1) est refusé et que le message d’erreur adéquat apparaît
(cas n°2) est accepté et l’enregistrement a bien lieu dans la DB
(cas n°3) est accepté et l’enregistrement a bien lieu dans la DB
Qui ?
La personne qui a développé est également en charge des tests unitaires. Il ne s’agit ici que de
garantir que le travail effectué correspond bien, y compris dans les résultats, à ce qui a été
demandé.
Quand ?
Ceci fait partie de l’ensemble des opérations à réaliser par le développeur avant de remettre
une partie de code pour intégration dans ce qui a déjà été produit.
Cette tâche se fait donc soit en même temps que le coding de la partie concernée soit
directement après.
________________________________________________________________________
_______________________________________________________________________________
14.3 Tests d’intégration
But
Les tests d’intégration ont pour but de s’assurer que des parties de l’application développées
et unitairement testées, une fois mises ensemble s’intègrent correctement de manière à
produire le résultat global souhaité.
Lorsque toutes les parties ont été développées, les tests d’intégration sont alors des tests end-
to-end. Cela signifie qu’il s’agit de tester l’application depuis la saisie de données par un
utilisateur jusqu’à la comptabilisation et la sortie de statistiques prévues.
Définition
Tests d’intégration = tests d’un ensemble de fonctionnalités, chacune ayant été au préalable
testée séparément avec succès.
Comment ?
Ex :
Enregistrement d’une location
Identification du membre°
Identification du/des support(s)
Présence en stock
Réception au comptoir des Pas testable si manuel
supports
Confirmation de la location de
chaque support
Calcul du montant dû
Traitement du paiement
Pour tester ces différents points, le testeur va décrire dans un document comment il va faire.
Chacune de ces fonctions a été préalablement testée séparément avec succès.
Cependant il est de la responsabilité du testeur de s’assurer que toute la fonctionnalité est OK,
y compris les tests normalement déjà validés.
________________________________________________________________________
_______________________________________________________________________________
Qui ?
Selon la taille du projet, différentes situations peuvent se présenter :
- présence d’une équipe de tests dédicacée
- par l’analyste fonctionnel dédicacé
- par la personne tout à la fois chef de projet/analyste/programmeur
Quand ?
Une partie de ces tests peut se faire en même temps que le développement progresse.
Cependant, l’intégration complète ne pourra être possible que lorsque l’entièreté du
développement sera terminée.
Ex : saisie d’une facture

Le test unitaire consistera à vérifier que tous les contrôles demandés ont bien été prévus
(client présent dans la base de donnée, devise indiquée, date >= date du jour, …).
Le test d’intégration consistera à vérifier que lorsqu’une nouvelle facture est saisie,
l’impression et l’envoi de cette même facture auront bien lieu avec les données saisies
________________________________________________________________________
_______________________________________________________________________________
14.4 Tests fonctionnels
But
Les tests fonctionnels ont pour but de vérifier que les spécifications fournies par le client ont
bien été respectées.
Il s’agit de tests d’intégration pour l’ensemble d’une fonction selon le point de vue de
l’utilisateur et sans considération technique.
L’attention se focalisera donc sur des aspects tels que :
- l’ergonomie (l’application est-elle facile, agréable à utiliser ?)
- le temps de réponse (même si non explicitement fixé)
- la navigation (est-il facile de se déplacer et d’atteindre l’élément désiré ?
- le temps de saisie (est-ce compatible avec la charge de travail ?)
Définition
Test fonctionnel : test qui s’adresse aux fonctions
Comment ?
Il faut établir des scénarios des tests permettront de déterminer que le système produit bien les
résultats attendus.
Il faut donc définir l’ensemble des opérations à effectuer et le résultat que ces opérations
doivent produire.
Qui ?
Les tests fonctionnels sont effectués par l’analyste.
Quand ?
Il faut procéder en 2 phases.
La 1ère a lieu une fois les spécifications connues. A ce moment, il est possible d’établir des
scénarios de tests qui décrivent ce qu’il faut tester, la séquence à suivre et les résultats
attendus.
La 2ème phase a lieu lorsque le développement est terminé. Il est alors possible d’exécuter ces
scénarios et de vérifier si les résultats attendus sont bien ceux produits par l’application.
________________________________________________________________________
_______________________________________________________________________________
14.5 Tests organisationnels
But
Les tests organisationnels ont pour but une réflexion sur les implications concrètes et terre à
terre de la nouvelle application.
Ex : prévoir la centralisation des impressions sur une grosse imprimante pour réduire les
coûts peut apparaître comme une bonne idée
Elle le sera dans certaines situations et pas dans d’autres.

Elle n’en est pas une si des personnes réparties géographiquement loin de cette
imprimante y recourent souvent durant la journée pour des besoins immédiats.
Elle l’est s’il s’agit d’imprimer des lettres qui peuvent être envoyées telles quelles à
leur destinataire.
Elle peut l’être à condition que les risques d’indisponibilité aient été minimisés (ex :
contrat de maintenance prévoyant une intervention dans l’heure et une mise à
disposition d’une machine de dépannage au cas où l’indisponibilité dépasse 24h).
Définition
Test organisationnel : test qui s’adresse à l’organisation (disposition des locaux, des bureaux,
des machines).
Comment ?
Il s’agit dans un premier temps d’imaginer et de simuler sur le terrain la nouvelle organisation
de manière à s’assurer qu’il n’y aura pas de problèmes importants.
Dans un deuxième temps, et aussi vite que possible, de faire les tests en conditions réelles.
Attention
L’informaticien n’est pas toujours le bienvenu en ce domaine. Les aspects organisationnels
ne sont pas toujours considérés comme faisant partie intégrante d’un projet ou, s’ils le sont, ils
relèvent de la seule compétence du client.
Qui ?
Ceci nécessite une collaboration entre le chef de projet/analyste fonctionnel et son équivalent
chez le client.
________________________________________________________________________
_______________________________________________________________________________
Quand ?
Il n’est pas aisé de répondre à cette question.
- changement de locaux
- aménagement de locaux
- nécessité de matériel qui doit être livré
- avancement de l’application
________________________________________________________________________
_______________________________________________________________________________
14.6 Tests de non régression
But
Le but des tests de régression est de s’assurer que toute partie de l’application déjà testée avec
succès le restera même si des nouvelles parties de code sont ajoutées.
Les tests de non régression ont donc un aspect systématique et répétitif. L’humain n’est pas le
moyen le plus sûr de le garantir. En effet, d’une part la charge est lourde, d’autre part la tâche
est complexe (prévoir tous les cas) et répétitive. Il est donc indiqué de recourir à un logiciel
qui se chargera de cette mission.
Attention
Les tests de non régression sont basés sur des scénarios. Si l’application évolue, il ne suffit
pas d’ajouter de nouveaux scénarios mais il faut aussi peut-être adapter ceux déjà existants.
Définition
Tests de non régression : tests couvrant l’ensemble des fonctionnalités déjà développées de
manière à s’assurer que toute modification ultérieure n’influence pas de manière non désirée
le fonctionnement de l’application tel qu’il était avant la modification.
Comment ?
Etant donné le nombre grandissant de tests à exécuter au fur et à mesure que l’application se
construit, la seule solution est d’utiliser un outil soit existant sur le marché soit développé
spécifiquement.
Cet outil va donc simuler les comportements des différents acteurs de manière à réaliser une
série d’actions.
Le résultat attendu est défini et fait partie de l’outil. Après exécution, les anomalies sont
identifiées et doivent faire l’objet d’investigation.
Sur base de celles-ci, il s’agira :

- soit de modifier la partie de code récemment ajoutée
- soit de modifier la partie de code déjà existante mais pour laquelle une adaptation
aurait été oubliée
- soit de modifier les 2
- soit de retourner vers l’analyse fonctionnelle ou l’architecture
________________________________________________________________________
_______________________________________________________________________________
Qui ?
L’exécution de ces tests devrait se faire de manière la plus automatique possible, y compris le
contrôle des résultats.
L’analyse des résultats doit être faite par quelqu’un qui a une bonne maîtrise de l’application.
Quand ?
Idéalement, ces tests devraient être exécutés à chaque fois que le code existant fait l’objet de
modification (ajout, suppression, modification).
________________________________________________________________________
_______________________________________________________________________________
14.7 Tests ‘Fail over’
But
Les tests de ‘fail over’ ont pour but de s’assurer qu’un problème quelconque d’interruption
dans l’application soit prévu et géré.
Il est au courant aujourd’hui que des applications utilisent des process qui impliquent le
fonctionnement de différentes machines.
Le but est donc de s’assurer que si une des ces machines a un problème, les informations qui
étaient en cours de traitement auront bien un traitement adéquat et que l’on pourra
précisément déterminé les données correctement traitées, les données non traitées et les
données éventuellement perdues.
Définition
Les tests de ‘fail over’ consiste à provoquer volontairement des interruptions du service à
différents endroits et à différents moments de manière à s’assurer que tout événement de cette
nature a d’une part bien été prévu mais également que le traitement adéquat aura bien lieu
(ex : restore sur base de backup).
Comment ?
Il faut provoquer des pannes.
Ex : débrancher un serveur
Qui ?
Ces tests sont directement liés à l’architecture et sont de nature technique. Ils doivent donc
être réalisés par les techniciens du fournisseur.
Quand ?
De tels tests sont possibles dès qu’au moins une partie de l’architecture est en place et que des
fonctionnalités ont été développées.
________________________________________________________________________
_______________________________________________________________________________
14.8 Tests de charge (stress tests)
But
Les tests de charge ont pour but de tester le système en conditions extrêmes en termes de
volume et de nombre d’utilisateurs.
Ex : 200 utilisateurs maximum connectés en même temps, des tables reprenant des millions de
lignes.
Définition
Les tests de charge sont des tests qui permettent de s’assurer que le système donne toujours
satisfaction dans les conditions limites fixées dans le contrat.
La plupart du temps ceci concerne le maintien des performances dans des conditions
combinant une base de données bien remplies et des accès simultanés.
Comment ?
Pour réaliser ce genre de tests, il faut se rapprocher le plus possible de la situation de
production portée à son maximum
Il faut donc alimenter la DB de manière à simuler une charge extrême ainsi que simuler les
accès simultanés conformément au maximum accepté dans le contrat.
.
Qui ?
Comme il s’agit de mesurer la conformité et la qualité de l’application dans des conditions
extrêmes, ces tests doivent être réalisés par le fournisseur. Attention, rien n’empêche le client
d’inclure ce genre de tests dans ceux d’acceptance.
Quand ?
De tels tests doivent avoir lieu préventivement à chaque fois qu’une partie du logiciel doit être
acceptée par le client.
Selon l’importance de l’application, ils auront lieu de une à n fois .
________________________________________________________________________
_______________________________________________________________________________
14.9 Tests d’acceptance
But
Les tests d’acceptance ont pour but de donner un outil objectif et des résultats mesurables
permettant d’arriver à une acceptance par le client.
Ex : conversion d’une base de données relative au calcul de salaires de BEF en EURO : si la

différence entre le montant net de l’employé de la paie en BEF (résultat converti en Euro) et
de la paie en Euro est plus petit ou égal à 0,15 €, le résultat sera accepté.
Définition
Les tests d’acceptance sont des tests, définis au moins en accord avec le client, permettant de
déterminer si l’application délivrée est conforme aux spécifications et d’un niveau de qualité
suffisant.
Pour plus de facilités, il est possible de définir des catégories au niveau des ‘bugs’
- Type 1 : bugs bloquants : l’application ne fonctionne pas
- Type 2 : bugs partiellement bloquants : une partie de l’application ne fonctionne
pas
- Type 3 : bugs à corriger mais sans impact important sur l’application
- Type 4 : bugs de ‘confort’ : la couleur n’est pas la bonne, l’emplacement d’une
zone n’est pas correct
Comment ?
Pour réaliser ce genre de tests, il faut se rapprocher le plus possible de la situation de
production.
Des aspects comme les volumes, la complexité des cas et le temps de réponse doivent faire
partie de ces tests.
Attention : ceci requiert un investissement important de la part du client en temps et en

ressource.
Il sera notamment nécessaire d’alimenter la base de données. Il est fréquent que le client
finisse par demander s’il n’est pas possible de récupérer les données pour la production.
Mon conseil est de refuser ce genre de demande. En effet, des tests d’acceptance sont
toujours des tests. En tant que concepteur, vous devez garder le contrôle de la base de
données et, plus particulièrement, la possibilité de l’initialiser à nouveau entièrement.
________________________________________________________________________
_______________________________________________________________________________
Qui ?
Comme il s’agit de mesurer la conformité et la qualité de l’application, ces tests doivent être
réalisés par le client.
Rappel : ceci nécessite du temps et des ressources côté client
Quand ?
De tels tests doivent avoir lieu à chaque fois qu’une partie du logiciel doit être acceptée par le
client.
Selon l’importance de l’application, ils auront lieu de une à n fois .
________________________________________________________________________
_______________________________________________________________________________
15 Documentation (Non)
15.1 Introduction
La documentation d’une application informatique est aussi essentielle que difficile à réaliser.
Si des éléments fondamentaux, telles que les spécifications fonctionnelles, n’ont pas été repris
dans un document avec accord formel du client, elle le sera d’autant plus.
Personne n’aime recommencer la même chose à plusieurs reprises, a fortiori lorsque l’on est
pas motivé au départ.
Or, il faut bien le constater, si disposer d’une documentation à jour et bien faite est une
exigence de chacun, en rédiger concrètement une, trouve déjà beaucoup moins de volontaires.
C’est pourquoi sans un plan bien clair et des points de contrôle aussi bien sur l’existence que
sur le contenu, de la documentation existera sans doute, mais certainement pas La
documentation.
La documentation doit être considérée comme une activité de chacune des étapes importantes
du projet :
- étude préalable
- étude détaillée
- développement
- maintenance
Si tel est le cas, cela implique que des ressources et du temps y soit consacré.
Attention : pour qu’une documentation soit efficace, elle doit être indépendante de la
personne qui la rédige. Ceci signifie que n’importe quel lecteur, avec un minimum de
connaissance, doit être capable de l’exploiter. Elle doit donc être la plus explicite possible,
sans sous-entendu ni pré-supposés.
Tout ceci doit être précisé dans des documents repris dans les normes et standards du projet.
15.2 Une bonne documentation

En effet, documenter ne consiste pas seulement à noircir du papier.
La documentation n’a qu’un seul but :
Permettre à toute personne ayant une base minimale de connaissance d’être à même de
comprendre rapidement et avec certitude une application informatique
________________________________________________________________________
_______________________________________________________________________________
‘toute personne’
Ces 2 mots sont là pour indiquer qu’une documentation ne se limite ni au(x) rédacteur(s) de
celle-ci, ni aux seules personnes participant au projet.
Une documentation doit être conçue pour toute personne qui sera amenée à devoir s’intéresser
à l’application concernée que ce soit aux niveaux métier, fonctionnel ou technique
‘ayant une base minimale’ :

de même que dans un texte technique, les mots spécifiques seront expliqués tandis que le
vocabulaire courant est considéré comme maîtrisé par le lecteur, il sera également considéré
que les mots courants du langage informatique ne doivent plus être explicités
‘rapidement’
par rapidement, il faut comprendre tout d’abord que la documentation doit être suffisante en
elle-même ; elle doit éviter des recherches complémentaires et fastidieuses
‘avec certitude’
Ici, on touche vraiment la difficulté majeure de toute documentation.
En effet, même si une application n’a pas subi de modifications depuis longtemps, rien ne
garantit que la documentation initiale était exacte.
L’unique moyen de vouloir garantir ce point est de mettre en place tout un processus
d’assurance qualité qui débutera dès avant le début de la rédaction et devra être poursuivi tout
au long de la vie de l’application.
________________________________________________________________________
_______________________________________________________________________________
17 Les principales causes d’échec (Non)
17.1 Phase de conception

Insuffisante maîtrise des attentes du client
Il faut être très prudent en cette matière. A cette fin, différentes actions sont possibles :
- inclure dès le début des personnes expérimentées et compétentes
- inclure dans le budget un poste pour les changements
- informer le client aussi vite que possible des mauvaises nouvelles
- établir en début de projet un ‘Plan de satisfaction du Client’ qui décrit les attentes et
les priorités du client
Some time ago, at the request of a country services executive, Quality Assurance HQ reviewed a
project that was in fairly serious difficulty. The review revealed several issues; weak project
management, not meeting some deliverables commitments, resource problems, etc. All of these
contributed to the contract's troubled project status. But customer interviews revealed that the primary
cause of their dissatisfaction was not these factors at all (these were, after all, fixable once identified
and action plans correspondingly implemented).
The primary (and not fixable) cause of this customer's dissatisfaction were the expectations which had
been set during the marketing and closing of the original opportunity. The marketing team had
assured the customer that IBM had numerous consulting "experts" in the client's industry that could be
made available to assist with long term industry strategy and business planning. In reality, only a few
such industry resources existed in IBM, all of whom were fully utilized on long-term contracts. So,
despite ongoing requests from the customer, no industry consulting "experts" were ever made
available. The customer was also assured that the vast resources of the IBM Corporation would be
made quickly available to help solve any IT or business problem encountered during the term of the
contract. However, the customer's extremely remote location in the world made leveraging the "vast
resources of the IBM Corporation" a very difficult and unrealistic challenge. In its eagerness to close
the deal, the marketing team had set expectations that were unrealistic and could not be met, thus
assuring this would be a troubled contract - and an unsatisfied customer - even before delivery began.
Lesson Learned:
Setting improper or unrealistic customer expectations usually occurs by being overly optimistic about
our ability to deliver something the customer wants. Quite often, it's not a contract deliverable, but
rather a less tangible impression of what a customer can expect by signing with IBM. In our anxiety to
close the deal, it's easy to think "we'll promise it now and figure out how to do it later", especially
considering the size and considerable resources of IBM and the intense desire to win and grow the
business. But the way to truly win is by setting realistic customer expectations during marketing, and
then focusing efforts on exceeding them during delivery. This is how we delight our customers, and
deliver the highest possible quality of service. This is the true measure of success.
Contrat à prix fixe

- limitation à des projets courts, relativement simple ou à des phases
- limitation à des projets dont l’équipe en a déjà réaliser de similaires
- diviser les grands projets en petits
________________________________________________________________________
_______________________________________________________________________________
- se limiter à la phase de spécification et de design
Client non préparé à assumer ses

responsabilités
Le client est-il prêt à être un partenaire ? Le client est-il conscient qu’il va devoir investir du
temps et des ressources ? Des formations sont éventuellement à prévoir.
Pas de compréhension partagée des

requirements
Dès le début, il faut impliquer dans la phase ‘marketing’ et ensuite dans le développement de
la proposition des personnes expérimentées et qualifiées.
Il faut absolument soit passer en revue de manière détaillée les requirements avant signature,
soit prévoir comme première phase une validation des requirements.
Pas de compréhension partagée de la

solution
Les éléments valables pour les requirements le sont également pour ce point-ci.
Echec dans le rédaction d’un bon contrat

Imprécision dans les mots, dans les processus de vérification.
Insuffisance dans les responsabilités du client.
Hypothèses non spécifiées.
________________________________________________________________________
_______________________________________________________________________________
17.2 Phase de réalisation
Impossibilité de disposer de ressources

qualifiées pour le projet
Ceci est malheureusement assez fréquent. En effet, entre le moment où les discussions ont
débuté et le moment où le projet peu enfin démarrer, il peut s’écouler de quelques jours à
plusieurs mois.
Même si à un moment donné, les personnes nécessaires (= nombre et qualification) étaient

disponibles, il se peut qu’une ou plusieurs de ces personnes ne le soi(en)t plus (elles ont quitté
l’entreprise, elles ont été affectées à un autre projet, le projet sur lequel elles se trouvent a pris
du retard, …).
Démarrage inefficace du projet

Ceci peut évidemment résulter du point ci-dessus mais cela peut également venir du non
respect par le client de ses engagements :
- impossibilité de constituer le comité de pilotage
- impossibilité de disposer des ressources humaines et matérielles nécessaires au
démarrage
(personnes non disponibles, documentation inexistante, locaux inadéquats,
matériel absent, …)
Organisation du projet/rôles peu clairs

L’organisation du projet en terme de comité de pilotage, sponsor, chefs de projet client et
fournisseur ne peut être ambiguë.
De plus, il faut s’assurer en permanence que ce qui a été convenu est bien respecter.
________________________________________________________________________
_______________________________________________________________________________
Project Management inadéquat

Le rôle du project manager est tout à fait crucial. Cependant, le terme ‘inadéquat’ ne permet
pas de donner de recette miracle.
En effet, au prise avec un client difficile, par exemple quelqu’un qui remet en cause ce qu’il a
approuvé la veille, il n’est pas toujours aisé de savoir quelle attitude adopter. Faut-il se
montrer tout à fait strict quitte à se créer des problèmes supplémentaires avec le client ou
vaut-il mieux se montrer plus ‘souple’ au risque de passer pour un faible ?
Il n’y a pas de réponse simple a une telle question. La bonne attitude sera celle qui mènera au
succès. Le problème est qu’on ne peut le savoir que plus tard et, si le choix n’était pas le bon,
trop tard.
Pour ma part, je pense qu’il faut aborder tout projet de manière neutre et avoir une approche
la plus factuelle possible et la moins émotionnelle.
Un moyen est de présenter clairement la méthodologie qui va être suivie, y compris dans des
aspects moins agréables (escalation, demande de changement, …). Ensuite, il faut l’appliquer
et ceci depuis le début afin de ne pas créer des précédents. Enfin, il faut le faire de manière
raisonnable.
Ce caractère raisonnable se déterminera en fonction du client et des circonstances.
Insuffisance de suivi du Project

Management
Ici, le rôle de l’équipe QA ‘Quality Assuance’ prend toute son importance. EN effet, cette
équipe a notamment pour mission de revoir régulièrement les projets de manière à faire un
état des lieux, de décider d’actions et d’en assurer le suivi.
Attention : la plupart des actions sont à réaliser soit par le project manager soit par la
hiérarchie.
________________________________________________________________________
_______________________________________________________________________________
18 Vos projets dans le cadre du Bach Info

(Non)
18.1 Projet développement WEB <> épreuve

intégrée (TFE)
Si ces 2 éléments ont comme point commun la rédaction d’un rapport et la présentation
devant un jury, il y a également des différences importantes.
Projet de développement WEB Epreuve intégrée

Vous travaillez seul Vous travaillez en groupe
Vous ne réalisez qu’une partie de Les membres d’un groupe travaillent sur la
l’application sur laquelle vous êtes le seul à même application
travailler ➔ interactions et dépendances
Le jury est composé uniquement de Le jury est composé de professeur du graduat
professeur du graduat mais également de membres extérieurs,
représentant du monde professionnel.
➢ Ils ne vous connaissent pas
Dans les 2 cas, mais encore plus dans le cas d’un jury composé en partie de personnes
extérieures, il faut que la présentation, tout en restant synthétique, permette clairement et
rapidement de comprendre de quoi on parle.
Moins l’assistance aura d’efforts à faire pour comprendre votre propos, plus il sera facile
d’apprécier tout le travail que vous avez dû accomplir.
18.2 Rédaction du rapport

Points indispensables
18.2.1.1 Introduction du sujet
Vous devez partir du principe que le lecteur ne connaît pas votre sujet. Il est donc
indispensable de commencer par donner des informations sur le secteur d’activité concerné.
Ensuite, il faudra expliquer au lecteur en quoi consiste le sujet que vous avez choisi. Soyez
particulièrement attentif à une bonne compréhension des termes que vous allez utiliser.
________________________________________________________________________
_______________________________________________________________________________
En effet, chaque secteur à son jargon. Parfois, il s’agit d’une terminologie n’existant que dans
le secteur, parfois il s’agit de termes existant aussi ailleurs mais pas du tout avec la même
signification.
Exemples :
un ‘kot’ d’étudiant est une terminologie belge ; un Français ne comprend pas ce terme qui
n’existe pas pour lui
les valves en Belgique signifie aussi un tableau d’affichage, le mot ‘valve’ existe aussi pour
un Français mais pas du tout dans le sens ‘tableau d’affichage’.
Ne perdez jamais de vue que vous ne connaissez pas forcément le référentiel de votre lecteur.
Si vous appliquez ce qui précède, vous éviterez :

- soit la perplexité d’un lecteur qui ne comprend pas de quoi vous parlez
- soit la confusion d’un lecteur qui utilise également du vocabulaire repris dans votre
rapport mais avec une signification différente.
18.2.1.2 L’existant
S’il y a un existant, autrement dit, que l’activité qui fait l’objet de votre informatisation existe
déjà, vous devez faire 2 choses :
- la première est une description de cet existant
- la seconde est une critique de cet existant
La critique de l’existant doit permettre de connaître les motivations de votre projet. Celles-ci
peuvent être fort différentes :
- informatisation de tâches entièrement manuelles
- améliorer un système informatique existant par l’informatisation de tâches restées
manuelles
- faire évoluer un système informatique existant par l’ajout de nouvelles
fonctionnalités (voir aussi maintenance évolutive)
- remplacer ‘à l’identique’ des fonctionnalités existantes mais par le recours à une
nouvelle technologie (ex. OO) et/ou un nouveau langage
- …
18.2.1.3 Autres points
Suivant vos projets, voici une liste de sujets qui doivent se retrouver dans votre rapport :
- Use Case
- MCD (avec explications des cardinalités)
- Diagrammes de Classe
- Diagrammes « Etat Transition »
- Diagrammes de Séquence
- Diagrammes d’Activité
- Dictionnaires des données
- Description des fonctions
- Description des écrans
- Enchaînement des écrans
________________________________________________________________________
_______________________________________________________________________________
- Aspects théoriques liés à la programmation20

- Conclusion
- Annexe avec le code
Support
Si le contenu est essentiel, le contenant n’en est pas moins important. Pour s’en convaincre, il
suffit d’observer les efforts des responsables du marketing sur ce qu’on appelle le
‘packaging’, autrement dit la façon dont le produit est mis en valeur uniquement de par son
emballage.
Le rapport doit avoir un aspect professionnel.

Il sera donc relié, aura une page de garde, une table des matières, une numérotation des pages.
Le caractère professionnel se traduit aussi dans une orthographe et une syntaxe grammaticale
sans reproche.
20
Il s’agit de préciser sur quoi repose votre code (menus, classes) ; point d’attention de J. Stevenne.
________________________________________________________________________
_______________________________________________________________________________
18.3 Techniques de présentation (Non)
Introduction
Dans le cadre de ce graduat vous allez être amenés à présenter des projets.
L’expérience a montré que ceci ne peut se faire sans guidance préalable. Le but de ce
chapitre est donc d’attirer votre attention sur des éléments importants à prendre en compte.
Une présentation n’est pas quelque chose d’accessoire qui se fera facilement dès que l’analyse
et la programmation seront faites.
Au contraire, elle doit être vue comme une phase importante de votre travail, au même titre
que l’interface graphique pour un client, au même titre que le rapport que vous devez rédiger.
La présentation est le moyen par lequel vous vendez votre produit.
Il faut donc passer par une phase d’analyse, de développement, de tests et de mise en
production.
Analyse
18.3.2.1 Pas d’improvisation
Une présentation ne s’improvise pas mais se prépare.
La première chose à faire est d’obtenir les contraintes dans lesquelles cette présentation doit
se faire, notamment en matière de timing : théorie, démo, questions
Ceci étant connu, vous devez vous organiser de manière à respecter ces contraintes. Le seul
moyen pour cela est de faire des répétitions et de vérifier si vous respectez ou non la durée.
18.3.2.2 Contenu
Il ne faut pas confondre le rapport écrit que vous rendez et la présentation que vous allez faire.
Il ne faut pas essayer de mettre dans votre présentation tout ce qui se trouve dans votre
rapport.
Dès le départ, l’auditoire doit avoir une vue claire de ce à quoi il va assister.
________________________________________________________________________
_______________________________________________________________________________
Pour cela, commencez par montrer l’agenda de la présentation :

- contexte
- méthode suivie
- difficultés rencontrées (en termes d’analyse, de programmation, d’organisation, de
timing)
- démo
- questions-réponses
N’oubliez pas de tester cette présentation auprès d’autres personnes. Lorsque l’on est plongé
dans une problématique, il est difficile de s’imaginer la perception de quelqu’un qui découvre
pour la première fois votre travail.
Attention : votre présentation ne devrait pas apporté d’éléments qui ne se trouvent pas dans
votre rapport.
Exemples :
- si vous n’étiez pas complètement satisfait d’un traitement mais que celui-ci
fonctionnait et que vous avez préféré avancer, cela doit se trouver dans votre rapport
(Concrètement, lorsqu’un utilisateur n’a pas accès à une option on ne la lui montre pas
alors qu’il serait plus satisfaisant qu’elle apparaisse mais en grisé)
- si vous avez pensé à des options possibles mais que par manque de temps vous ne les
avez pas investiguées ou parce que techniquement vous n’avez pas trouvé de solution,
cela doit également clairement apparaître dans votre rapport
18.3.2.3 Contraintes supplémentaires
Il n’est pas certain que les couleurs telles que vous les avez définies apparaîtront de la même
façon lors de la présentation. Vous êtes dépendants du matériel qui sera mis à votre
disposition.
Il faut donc s’assurer du matériel à utiliser et faire un test de manière à vérifier que tout
fonctionne bien (couleurs), que les versions de logiciels sont compatibles, qu’il faut d’abord
brancher l’appareil de projection sur le PC avant d’allumer celui-ci, que je vois en même
temps que la projection l’image sur l’écran du PC.
Développement
18.3.3.1 Outil
Aujourd’hui, ne pas utiliser un outil comme Powerpoint pour faire une présentation n’est
pratiquement plus acceptable.
________________________________________________________________________
_______________________________________________________________________________
18.3.3.2 Réalisation de la présentation
Mais, même à l’aide de PowerPoint, il est possible de faire de mauvaises présentations. En

effet, l’outil vous donne des possibilités mais ne vous donne pas le contenu.
Ici aussi, il y a un certains nombres de normes et standards à respecter :

- les diapositives ne peuvent pas être des copiés-collés de partie de votre rapport
- une diapositive ne peut être trop chargée, elle doit rester lisible
- une diapositive doit marquer les esprits sur les points importants, le détail qui le
complète sera énoncé oralement.
Tests
Comme déjà mentionné ci-dessous, des tests sont nécessaires. Ceux-ci se situent à différents
niveaux :
Forme Le texte est-il clair, aéré, lisible ?

Timing Le timing imposé est-il respecté ?
Contenu Le contenu répond-il à ce qui a été demandé ? La présentation est-elle
facile et agréable à suivre ? Ne va-t-on pas trop vite par ex pour expliquer
le modèle entité-association ?
Attitude Est-ce que je m’adresse bien à mon auditoire et non à l’écran ?
Est-ce que je n’hésite pas ?
La Mise en Production.
C’est votre présentation devant le jury, le jour « J »)
Il est essentiel de faire attention aux points suivants :

- adressez-vous à votre auditoire et non à l’écran
- faites la présentation debout
- prenez un rythme de parole ni trop rapide, ni trop lent
- ne perdez pas de vue que votre auditoire découvre votre projet, laissez-lui le temps
d’absorber certaines informations
Vous serez d’autant plus à l’aise que vous maîtriserez votre sujet. Vous devez avoir imaginé
les questions qui vous seront posées de manière à avoir préparé les réponses et à ne pas être
pris au dépourvu.
Ex : vous n’avez pas trouvé le moyen de réaliser un traitement tel que vous l’auriez souhaité
Question : qu’avez-vous faite pour trouver ? Réponse : livre, forum sur Internet, professeur
S’il faut anticiper les questions, ce n’est pas pour cela qu’il faut forcément d’emblée
reconnaître les limites ou les éléments incomplets de votre réalisation.
________________________________________________________________________
_______________________________________________________________________________
(ex : partir dans une logique de delete physique et s’apercevoir ultérieurement qu’un delete
logique aurait permis la gestion d’un historique ne doit pas forcément être annoncé si dans
votre démo votre but est de montrer la prise en compte par l’application de modifications ;
En_effet, que le delete soit logique ou physique, au niveau de la visualisation de la dernière
situation, il n’y a pas de différence).
De même, ne diminuez pas vous-même la valeur de ce que vous avez réalisé.

(ex : déclarer spontanément : ‘j’ai rencontré le problème X et je n’ai pas trouvé de solution’
n’est pas la meilleure façon d’aborder le problème ; il vaut mieux indiquer un manque de
temps ou le degré satisfaisant dans un premier temps de la situation actuelle).
________________________________________________________________________
_______________________________________________________________________________
19 ANNEXES (Non)
19.1 Annexe 1 : fiche signalétique

Nom : Prénom :
GSM : ___________________________________ Date de naissance : ____________
Email : ___________________________________
Etudes
Activités professionnelles
Qu’attendez-vous de ce cours ?
________________________________________________________________________
_______________________________________________________________________________
19.2 Annexe 3: Rapport de réunion d’équipe

TEAM : DVP module 1 Date 06/09/2001
0. Participants
Nom Remarques
Belmondo Jean-Paul Y
Carmet Jean N holiday
Duteuil Yves Y
Boutsen Thierry Y
1. Approbation du rapport précédent

Le rapport est approuvé.
2. Actions de la réunion précédente

N Sujet Date intro Qui Quand Reporté Statut
3. Progression
Etat d’avancement
4. Points de discussion
Reprend les points à aborder lors de la réunion Problèmes/Risques
5. Décision
.6 Actions pour la réunion suivantes
Qui Action Echéance Etat
7. Prochaine réunion
date, heure et lieu
________________________________________________________________________

Technique

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Technique

Transféré par

Droits d'auteur :

Formats disponibles

AUMONIERS DU TRAVAIL Antonis BOULAFENTIS

Bachelier en Informatique de Gestion

TECHNIQUES DE GESTION DE PROJET

Professeur : Antonis BOULAFENTIS

1 Table des Matières

Les modèles « Itératifs » dit AGILE (Oui) ...................................................... 34

Equipe ‘fournisseur’ ......................................................................................... 70

8.1.2.3 Indisponibilité des ressources humaines .................................................. 89

10 Développement (Non) ..................................................................................................... 116

But .................................................................................................................. 133

18 Vos projets dans le cadre du Bach Info (Non) ............................................................... 147

En effet, le développement d’un logiciel n’est pas une chose triviale:

Pour vous aider à réaliser un développement d’un logiciel :

L’objectif de ce cours est d’apporter au futur bachelier en informatique de gestion:

Projeter, c’est penser un inexistant possible, à réaliser [Jean-Pierre Boutinet]

2.2 Mode « Projet » <> Mode « Opération » (oui)

On oppose souvent le mode Projet avec le mode Opération alias Production:

Mode Projet Mode Opération càd en Production

Sur une ligne du temps :

Mode Projet Mode Opération

2.3 Management de projet (oui)

Elle doit d’abord assurer la conformité du produit à ses exigences fonctionnelles et

Le triangle de projet (oui)

Appelé également la triple contrainte :

Il contribue à amener son organisation vers la qualité totale.

Pourquoi une méthode ?

Apports d'une méthode

Différentes méthodes de « project management »

 Prince2 – PRoject IN Controlled Environment 2

2.4 Le Projet au « centre » (oui) – 17/09/2017

Tolérance sur la Revenus

Cahier des 1..* Produits

Planning Génère >

Qualité des Revenus Réels

Moyens Moyens Ressources

2.5 Les différents niveaux (oui)

FIGURE 1 : Les 5 niveaux

ROI ➔ Return On Investissement

1 application qui coûte 100.000€ au niveau du budget

ROI : 100000/ (40000-15000)= 4 ans

Attention : ceci ne s’adresse pas uniquement aux services autres qu’informatique.

Ex : déclaration multifonctionnelle par Internet : communiquer 1 seule fois les informations

C’est une opportunité d’automatiser différents services

Niveau des ressources humaines

On peut évoquer les cas suivants :

2.6 Un nombre important de situations

Le succès du développement d’une application informatique dépend de beaucoup de

Obtenir dès le départ les réponses à des questions clés

- quel est le but de cette application ?

Ces 4 questions permettront de déterminer rapidement la maturité du projet sur les 3

2.7 Le cycle de vie d’une application

Les grandes phases

CONCEPTION REALISTION LIVRAISON

2.7.2.1 La conception (DESIGN)

Il s’agit donc d’avoir suffisamment balisé le cadre du projet ➔ périmètre ou scope :

Dans cette phase, il y a une importante nécessité d’échanges et de communication avec le

2.7.2.2 La réalisation (DEVELOPPEMENT)

2.7.2.3 La Livraison (DELIVERY)

2.7.2.4 Superposition des 3 phases

Les trois phases ne doivent pas se succéder en mode séquentiel.

La maintenance (oui) – 19/09/2017

La maintenance corrective correspond à la correction d’erreurs,

La maintenance évolutive, elle, a pour but de maintenir l’application en phase avec

Les maintenances évolutives peuvent être imposées ou volontaires