ConduiteProjet PDF

Eléments de gestion de projet informatique
Conduite de projets informatiques
Pr. Jean-Marc Jézéquel

IRISA - Univ. Rennes I
Campus de Beaulieu
F-35042 Rennes Cedex
Tel : +33 299 847 192 Fax : +33 299 842 532
e-mail : jezequel@irisa.fr
http://www.irisa.fr/prive/jezequel
28/02/2007 1
Problématique
• Qu'est ce qu'un projet ?

• Comment planifier un projet ?
• Quelles spécificités des projets informatique ?
– cycle de vie
– techniques
• d'estimation
• d'analyse/conception
• de tests
• de gestion de configuration
Pr. Jean-Marc Jézéquel - Conduite de projets informatiques 2
J.-M Jézéquel 1 2000


• Introduction à la culture projet
• Cycle de vie du logiciel
• Estimation de projet
• Planification et suivi
• Qualité du logiciel
• Gestion des risques
• Gestion de configuration et des changements
• Rôle du chef de projet
Introduction à la culture projet
• Pourquoi de la gestion de projet ?
• Qu'est-ce qu'un projet ?
• Qu'est-ce que la gestion de projet ?

Pourquoi de la gestion de projet ?
• Les projets n'atteignent pas souvent leurs objectifs

– dépassement de délais
– surcoûts importants
– qualité technique du produit insuffisante
• Les projets se déroulent dans un milieu complexe
– acteurs divers dans une entreprise : étude, production,
marketing
– environnement extérieur non maîtrisable : marché, social,
politique, concurrence
La solution : une méthode
• Le déroulement du projet est formalisé

– par l'entreprise qui capitalise son expérience
– par le client qui impose des contraintes pour garantir le bon
déroulement du projet
• Des spécifications de management sont édictées par
– des entreprises
– les états
• Stratégiques, beaucoup de ces informations sont
confidentielles ; elles représentent le savoir-faire
des entreprises.

Des principes fondateurs
• La gestion par objectifs

• La gestion des éléments critiques
• Des besoins clairement exprimés
• Les hommes, les méthodes, les moyens
• Un seul point de responsabilité
• La délégation d'autorité (confiance)
• La communication entre fonctions et niveaux
• Il est plus important d'être clair que parfait
• Le droit à l'erreur
Projet
Action spécifique, nouvelle, qui structure

méthodiquement et progressivement une réalité à
venir pour laquelle on n'a pas encore d'équivalent
exact.

Projet
• C'est une réponse apportée à une demande élaborée

pour satisfaire aux besoins d'un maître d'ouvrage.
• Il implique :
– un objectif physique ou intellectuel,
– des actions à entreprendre avec des ressources données.
Caractéristiques
• Généralement novateur
– technique, dimension, géographie, procédé,…
• Non répétitif
– donc organisation spécifique, temporaire
• Début et fin
– bilan non forcément annuel
Rôle du
• Tourné vers l'objectif final chef de projet
– Adaptable à des modifications fréquentes
• Equilibre entre contraintes techniques, coût et délais

Acteurs du projet
• Maître d'ouvrage personne physique ou morale

propriétaire de l'ouvrage. Il détermine les
objectifs, le budget et les délais de réalisation.
• Maître d'œuvre personne physique ou morale qui

reçoit mission du maître d'ouvrage pour assurer
la conception et la réalisation de l'ouvrage.
Phases et implication des acteurs
Maître d'œuvre
organisation
créativité
conception
mise en œuvre
verrouillage réalisation maintenance
exploitation
Maître d'ouvrage

Les types de contrat

• Forfaitaire (plutôt grands projet)
– le travail doit être clairement défini
– les interfaces entre contractants doivent être contrôlés
– le maître d'œuvre assume les risques
• Régie (plutôt étude)

– les coûts et la charge doivent être gérés par le client
– le maître d'ouvrage assume les risques
• Mixte
Gérer le projet
• Définir les objectifs, la stratégie, les moyens, Décider

l'organisation
Prévoir
Réagir
• Les adapter aux changements internes au projet mais

aussi externes (socio-politico-économique) Gérer
• Dans la mesure du possible les optimiser Apprendre

Objectifs et Moyens
• Les objectifs sont :

– Techniques Evaluation
Décider Estimation
– Economiques
Prévoir
– Délais Réagir gestion du risque
• Ils sont obtenus par des Gérer Planification

moyens : Contrôle
– Humains
– Matériels
– Financiers
Dilemme du management de projet
Coût Défaut =
non Qualité
Délais
A ressource égale, vouloir améliorer un paramètre,
influe négativement sur les autres …

Management de projet
Direction Conduite
de projet Pilotage
Synthèse et décision
Analyse et reporting
Gestion Gestion Gestion

des hommes technique des moyens
Organisation Objectif Planification

Communication Méthode Contrôle
Animation Qualité Coût-délais
Axes du management
Prévoir
• Planification
• Contrôle Suivre
• Management humain Animer

Planification
• Construction d'un scénario de référence décrivant :
– les objectifs
– le contenu (les activités,…)
– les moyens (ressources humaines, financières,…)
– l' organisation (circulation de l'information, …)
On contrôle par rapport à ce qui est prévu…

Contrôle
• mise en œuvre du système d'information
• mesurer la situation du projet

• comparer à la référence
• prévoir les conséquences (délais, coûts, qualité)

• définir des actions correctives si nécessaire
• appliquer ces actions
Détecter les problèmes et les anticiper

Management humain
• Mettre en place les conditions optimales de

participation au projet :
– définir clairement les responsabilités

– délimiter les zones conflictuelles
– motiver, animer
En bref
• Humain • Notions simples et techniques de gestion

• Technique de "bon sens" mais ...
• Risques
• Interaction complexe
• Coûts
• Délais • Vocabulaire commun, outil de
communication
• Arbitrage objectif en contexte
multiprojet


– Principes
– Techniques d’estimations
Estimation de projet

L'art de l'estimation
• Pourquoi estimer ?
• La démarche d'estimation
• Qualité
Il est difficile de prévoir...surtout l'avenir

B.Shaw
Pourquoi estimer ?
• Connaître le coût d'une "vue de l'esprit" qui
deviendra peut-être réalité
– au bout d'un temps qu'on espère fini.
• On estime :
– Les immobilisations corporelles (terrains, bâtiment,
équipement, ...)
– Les immobilisations incorporelles (frais d'études, frais de
démarrage, frais financiers,...)
– Les dépenses d'exploitation (frais liés à l'activité, frais
financiers,...)

Niveau d'information
volume nécessaire niveau de précision %
Ordre de grandeur
30 30
Avant projet
20 20
Préliminaire
10 10
Courants
5 5
Détaillé
- +
Type d'estimation
Objectifs Technique Temps
Etude préliminaire
Ordre de Faisabilité Tonne Heures
grandeur Courbe
Avant projet Facteur
Justifier l'engagement
des études Grands ensembles Jours
Autoriser les Facteurs
Préliminaire dépenses Semaine
Coûts unitaires
préliminaires
Quelques offres
Facteurs Semaine ou
Autoriser Coûts unitaires mois
Courants l'investissement
Nombreuses offres
Contrôler les coût Mètres Semaine ou
Détaillée d'exécution Coûts unitaires mois
Tarifs

Démarche d'estimation
Entrées
– Objectifs techniques
– Objectifs de délais
– Environnement
– Période Augmentation de l'information
– Historique Comparaison avec le résultat
– Références
Sortie
– Estimation
Techniques d’estimation du logiciel
• Quelques techniques
• La méthode Cocomo
• Les points de fonction

Méthodes d'estimations
• Par analogie
• Oracle
• PERT
• Bottom-Up
• Modèle paramétrique
Principe des modèles paramétriques

• Effort = a (Size)p
Avec :
– Effort en Personnes-Mois
– a impact des paramètres sur l'effort calibré
– Size quantité de travail (SLOC ou FP) estimé
– p exposant (proche de 1) calibré
Taille Estimation
facteurs

Principe des modèles paramétriques

• Effort = a (Size)p
Avec :
– Effort en Personnes-Mois
– a impact des paramètres sur l'effort calibré
– Size quantité de travail (SLOC ou FP) estimé
– p exposant (proche de 1) calibré
Taille Estimation Effort
facteurs
Taille
Estimation
• Quelques techniques
• La méthode Cocomo
• Les points de fonction

COCOMO
• Modèle paramétrique
• Facteurs dans le domaine public
• 3 modes de bases
– organique petite équipe, environnement stable

– semi-détaché équipe de taille moyenne
– détaché grande équipe, répartie, nouvel environnement
COCOMO simple
• mode organique : HM = 2,4 (KLSL) 1.05

• semi-détaché : HM = 3.0 (KLSL) 1.12
Effort
• détaché : HM = 3,6 (KLSL) 1.20
• mode organique : TDEV = 2.5 (HM) 0.38

• semi-détaché: TDEV = 2.5 (HM) 0.35 Durée
• détaché : TDEV = 2.5 (HM) 0.32
N = HM / TDEV HM : Hommes-Mois (152heures)

KLSL : Kilo de Ligne de Source Livrées

COCOMO intermédiaire
• Quinze facteur correctifs sont introduits
– valués de VeryLow à XtraHigh
• Pour le projet :
– fiabilité requise du logiciel
– taille de la base de donnée
– complexité du produit
• Pour les contraintes de l'environnement :
– contraintes de temps d'exécution / place mémoire
– stabilité de la machine virtuelle
– système de développement interactif ou non
COCOMO intermédiaire
• Pour le personnel :
– aptitude à l'analyse
– expérience du domaine
– expérience de la machine virtuelle
– aptitude à la programmation
– expérience du langage
• Pour les méthodes :

– méthode de programmation moderne
– outils logiciels
– durée du développement

COCOMO détaillé
• Les facteurs correctifs dépendent de la taille

(KLSL)
• Une répartition de l'effort sur les phases de

développement est réalisée


Objectifs
• du Projet : unique et mesurable, e.g.:

– prendre 1% du marché des cacahuètes salées grillées
– faire des études de faisabilité
– Intégrer deux systèmes informatiques
– Maintenir une gare
– Commercialiser une pâte dentifrice
• de la gestion du projet ; gérer :
– Ressources matérielles et humaines
– Finances
– Temps
Coût et intérêt
• La question fondamentale : où en est le projet ?
– Si un chef de projet sait répondre "intuitivement" et "fiablement"
à la question : où en est le projet ? ou si cette question est sans
fondement, la gestion de projet n'a pas lieu d'être.
• Comment répondre à cette question ?
– modéliser le scénario du projet (tableau de marche prévisionnel)
– déterminer périodiquement ce qu'il reste à faire
– indiquer où l'on en est sur le tableau de marche (avancement)
• La gestion de projet coûte de 2 à 5 % de la valeur
ajoutée du projet.

Analyse de projet
• Formalisme
• Product Breakdown Structure
• Work Breakdown Structure
• Planning
• Mettre en évidence les activités
• Organisation Breakdown Structure
• Réseau
• Scénario
• Tableau de marche
• Résumé
Formalisme
PROJET
PBS
(QUOI)
GESTION
de
RESEAU PROJET
OBS
(QUI)
WBS
(COMMENT)
SCENARIO

Product Breakdown Structure
fait partie est composé

système de ...
de ...
sous-système 1 sous-système 2 sous-système 3
ensemble 1 ensemble 2 ensemble 3
Découpage du système en unités "physiques"

hiérarchisées.
Work Breakdown Structure

définition
définition définition ensemble 21
système s-système 1
réalisation
ensemble 21
réalisation réalisation intégration
s-système 1 ensemble 21 ensemble 21
définition
réalisation réalisation ensemble 22
projet s-système 2 ensemble 22
réalisation
ensemble 22
réalisation réalisation intégration
s-système 3 ensemble 23 ensemble 22
définition
ensemble 23
intégration intégration
système s-système 2 réalisation
ensemble 23
Description structurée de toutes les tâches du projet, intégration
rapportées au découpage du produit. ensemble 23

Planning
def. sys
réalisation s-système 1
def. s-sys 2
ensemble 21
ensemble 22
ensemble 23
intégration s-sys 2
intégration système
t
Planning
def. sys
intégration sys
Plusieurs niveaux de planning déductibles du WBS

Mettre en évidence les activités
• Une des causes principales de dérive dans un projet est

que des travaux n'avaient pas été vus, et donc prévus
– Il n'est pas rare que ceci représente 30 % de la charge d'un projet.
• Le WBS permet de voir, et donc de mener des revues de
projet pour isoler les éventuels oublis.
• Les tâches annexes sont les plus souvent omises :
– logistique, mise en place de moyen de développement
– formation, négociation de la sous-traitance
– mise en place de l'environnement de test
=> WBS-type pour un type de projet dans une entreprise
Organisation Breakdown Structure

• Qui fait quoi ?
– Qui déclare telle activité achevée (réalisée) ?
– Qui déclare telle activité correctement achevée ?
(approuve, accepte)
– Qui est responsable de qui ?
• Principe :
UN SEUL point de responsabilité par activité

Réseau
C 20 j
R1 100% F 15 j
R1 50% I 10 j
A 10 j D 5j
R1 100%
R1 100% R2 100%
G 25 j
B 15 j J 20 j
R2 50%
R2 100% R2 100%
E 10 j H 20 j
R2 50%
R1 50%
Activités/dépendances
Ressources
Durées
Scénario
Planning Plan de charge
A
B H
R1 A C I
C F
D t0.............................................t0+80
E
F
G D
H R2 B J
E G
I
t0.............................................t0+80
J
t0.............................................t0+80

Au plus tôt
C 20 j
F 15 j
R1 100%
R1 50% I 10 j
A 10 j D 5j
G R1 100%
R1 100% R2 100% 25 j
B 15 j J 20 j
R2 50%
R2 100% E 10 j H 20 j
R2 100% Planning
R2 50%
R1 50%
A
B
C
On commence par D
placer les activités E
sans antécédents F
G
H
I
J
t0.............................................t0+80
Au plus tard
C 20 j
F 15 j
R1 100%
R1 50% I 10 j
A 10 j D 5j
G R1 100%
R1 100% R2 100% 25 j
B 15 j J 20 j
R2 50%
R2 100% E 10 j R2 100%
H 20 j
R2 50% Planning
R1 50%
A
B
C
On commence par D
placer les activités E
sans successeurs F
G
H
I
J
tf-80.........................................tf

Superposition ...
Planning
A
B
C
D
E
F
G
H
I
J
t0.............................................t0+80
tf-80.........................................tf
Chemin critique
Planning
A
B
C
D
E
F
G
H
I
J
t0.............................................t0+80
Ensemble des tâches de marge négative ou nulle

Tableau de marche
• Le tableau de marche est le scénario retenu

– Pas de surcharge pour les ressources,
– Délais et coûts satisfaisants.
• Comment agir sur les scénarios ?
– Problème de charge
• Lissage ou nivellement
– Délais et/ou charge
• Modification de priorités (réseau)
• Modification des ressources
• Modification des tâches (reprise de l'existant par exemple)
• Modification de la définition du produit
Résumé
PBS accord du client/
mise en cause du projet
WBS accord du client
OBS responsable de projet
Réseau ajustement technique
Scénario
Tableau de marche

Plan directeur/Plan de
développement
• Emis par le responsable du projet, le plan directeur
contient :
– les objectifs
– les clauses contractuelles (client externe, sous-traitance)
– organisation (responsabilité, hiérarchie)
– circuit d'information et de décision
– format et périodicité des comptes rendus
– codification des activités
– découpage du projet (organigramme technique)
Suivi de projet
• Suivre/contrôler
– les délais
Coût Défaut =
– les coûts non Qualité
– la qualité
• Analyse du suivi Délais
• Historique

Suivre
Tableau de marche Tableau de marche
points d'avancement points d'avancement
temps
• Choix d'une métrique ?
• Fréquence des points d'avancement ?
• Qui vérifie les informations ?
Coût Défaut =
non Qualité
Contrôle des délais

Délais
• Par rapport à la référence prévisionnelle, à une

date donnée, mesurer pour chaque activité :
– début
– fin
– avancement
• Le réseau montrera les implications pour les
tâches dépendantes
• A-t-on une surestimation (ou une sous-estimation)
systématique des durées ?
=> Nouvelles prévisions

Défaut =
Coût
non Qualité
Mesure de l'avancement
Délais
Ce qui est prévu

Ce qui est fait
Ce qui reste à faire
Ce qui est ré-estimé
• prise en compte de la valeur observé de la productivité

• ré-estimation budgétaire
• Objectif : Mettre en évidence et expliquer

– l'écart
– la dérive
– les tendances
Défaut =
Coût
non Qualité
Métriques d'avancement
Délais
• 0/100 Une chose est faite, ou non. On sous-

estime une activité en cours de réalisation.
• 20/80 Une chose commencée est mesurée à
20% tant qu'elle n'est pas finie.
• Par jalons Un pourcentage d'avancement est
associé à chaque jalon.
• Linéaire Associé à une mesure objective,
physique.

Défaut =
Coût
non Qualité
Analyse du suivi
Délais
date
prévues
A
D
date de la mise
à jour (mois) de
aujourd'hui la date prévue


La gestion technique :
Gestion de configuration
• Objectifs
• Gestion
– Des modifications
– Des matériels
– Des documents
Objectifs de la gestion de
configuration
• Garantir que tout les participants au projet savent
– ce qui est décidé
– ce qui est spécifié
– ce qui est développé
– ce qui est assemblé
– ce qui est testé
– ce qui est livré
• Etre la mémoire du projet
– traçabilité, réutilisabilité (capitalisation), documentation

La documentation
• Les documents ont une nomenclature centralisée

• Les liens entre documents doivent être gérés
• Un même document peut exister sous plusieurs
versions
• Les liens entre produit livrés et documents doivent
être gérés
• Les documents doivent être relus, validés, diffusés
• Les documents doivent êtres sauvegardés, archivés,
protégés
Organisation de la gestion de
documentation
• secrétariat du chef de projet

• documentation type
• procédures de relance
• outils de gestion de documentation

Documents
étude de étude étude étude Réalisation Recette
faisabilité préalable détaillée technique
Dossier
bilan Plan de Plan de
existant dévelop- recette
pement
Cahier
Fiche-Projet Synthèse
charges Plan de des
Dossier utilisateurs migration
Cahier recettes
de
choix charges
réalisation Plan de
mise en
œuvre
Rapport étude Rapport Bilan du
faisabilité étude projet
préalable
Rapport Rapport Rapport
étude étude de
détaillée technique réalisation
Les matériels
• Comme tous les documents, les matériels/produits

doivent
– être identifiés
– répertoriés
– leurs versions gérés
– la cohérence avec la documentation assurée

L'impact des modifications
• Pour maîtriser délais et coût, il faut maîtriser les

modifications, inévitables dans un projet.
Gestion des
• Processus décisionnel de modification documents
• Conserver une liste des modifications et le suivi du
processus décisionnel apporté.
• Certaines modifications peuvent amené à revoir des
choses déjà livrées…
Gestion de
configuration
Processus décisionnel de modification
1. Demande d'étude (par client ou membre du projet)

– description de l'état d'origine, de l'état final, et des motivations
– décision de poursuivre par le responsable du projet
2. Etude d’impact technique, puis sur délais et coûts
– noter la durée de validité de l'étude, date au delà de laquelle, si
aucune décision n'est prise, il faudra réévaluer la modification
3. Décision ou non après accord avec le client, et
diffusion aux participants concernés
4. Suivi de la mise en œuvre des modifications

Outil de Gestion de Configuration :

l ’exemple de CVS
• CVS : Concurrent Versions System
– logiciel libre disponible sous toute plate-forme

• mode local ou client/serveur au dessus TCP
• nombreuses GUI (WinCVS, WebCVS…)
– relativement simple et léger à mettre en œuvre

• vs. ClearCase, Continuus etc.
CVS Features
• Concurrent access by multiple developers
• Multiple development lines in a single repository
• Grouping sources into modules
• Symbolic source tagging
• Diffs between versions
• Configurable logging support
• Binary files support
• Repository event triggers

Client-server architecture
• separate server (UNIX or NT)

• no shared filesystems
• a server process per connection
ewacvs
The CVS Repository

ewacvs:/data1/cvsroot
CVSROOT shr project1 project2 project3 devkits
ar cgi doc install reports util web
cgipr unix nt esapps forms
• Resides on a server
• No working files inside the repository

CVS Usage Model

Checkout, Commit, Update
• Checkout
– Makes private copy in working directory
– Can check out anywhere
– Check out multiple copies, multiple versions
• Commit
– Commit changes to the repository when finished
– Working copies must be up to date with repository
• Update
– Brings working copy up to date with repository
Checkout does not lock

the files in repository
Concurrent checkout
Master Repository
foo.c
che
t cko
es ut b
lat ch ran
out ec ch
k rel_
ec ko 1_f
ch checkout checkout ut ix
V1.1 l
Karen V1.2 at
es
t Patrick
Michael Chris Brigid
Working
Working
Copy Working
Working Working Copy
V1.7 Copy
Copy V1.1 Copy V1.2 V1.2.2.1
V1.7
checkin
checkin
checkin
X X
V1.8 or 1.9 V1.2.2.2
checkin prohibited
V1.8 or 1.9

CVS and the Development Cycle

1. Check out source files in working directory.
2. Edit source files.
3. Unit test your code.
4. Update working files to merge in changes from other
developers (if necessary).
5. Test again if the sources were merged on step 4.
6. Commit changes.
7. Repeat from step 2 until you have a new release.
8. Tag the release.
9. Submit the module name and release tag for integration build.
Ideal development with CVS

development
checkout
checkin
update Developer A
repository
Developer B

Real development with CVS

checkin
conflict
checkin
update
resolution Developer A
repository
Developer B
X conflict
Common CVS commands

cvs [cvs-options] command [cmd-options] [files]
cvs init Initialize a new repository.
cvs checkout Check out source for editing.
cvs commit check files into the repository
cvs update Bring working files into sync with repository.
cvs add Add new file/directory to repository.
cvs remove Remove an entry from the repository.
cvs tag Label the sources.
cvs status Show status of checked out files.
cvs log Show revision history for files.
cvs diff Compare working files to version in repository or
versions inside the repository.

CVS online
• Official CVS site: http://www.cyclic.com

• CVS Bubbles: http://www.loria.fr/~molli/cvs-index.html
• CVS for Web development: http://durak.org:81/cvswebsites
• WinCvs: http://www.wincvs.org
• jCVS: http://www.jcvs.org/
• Netscape’s Mozilla under CVS:
http://cvs-mirror.mozilla.org/webtools/tindertest/showbuilds.cgi?tree=SeaMonkey
• FreeBSD CVS repository: http://www.freebsd.org/support.html#cvs


Missions et responsabilités
• Incarner l'identité du projet
– Ni plus (d'autres projets de l'entreprise),
– Ni moins (des sous ensembles du projet)
• Gérer la convergence du projet

– Définir l'objectif
– Etre la mémoire du projet
– Agir pour converger
Evolution d'un projet niveau de

connaissance
sur le projet
gels, décisions
l'entreprise se
exploration des compromet
possibilités :
objectif : mieux
connaître le projet
capacité passage à l'acte
d'action gestion des délais
et des coûts
risques
décisions globales d'obsolescence
simultanées et commerciale
tardives pour diminuer
les risques

Rôle en phase de créativité (1)

• Définition initiale : objectif et méthodes
– Participation à la définition du cahier des charges. Définition
(ou remise en cause) des méthodes de travail.
• Mobilisation
– Recrutement des ressources nécessaires.
• Adaptation des normes métiers
– Lien projet -> normes/stratégies des métiers participants;
adaptation
Rôle en phase de créativité (2)

• Recherche de compromis inter-métiers optimaux
– Styliste, ingénieur d'étude, commercial : pas mêmes critères

d'évaluation
– Le chef de projet a pour rôle d'accorder tous les points de vue.
• Homme de communication pour détecter les

problèmes avant que l'irréversibilité du projet ne
dicte une solution.

Rôle en phase de verrouillage

• Stabilisation progressive du projet
– Il faut clore les débats ouverts dans la première phase. Le désir
de retarder le plus possible les prises de décisions, pour avoir le
plus d'information possible, doit être tempérer.
– De même l'arrivée probable et incessante de nouvelles données
par la hiérarchie quant à la conjoncture, aux alliances, aux
stratégies ne doit pas faire oublier la nécessité de converger.
• Mise sous contrôle et mémorisation
– Une fois le projet stabilisé, le processus de développement doit
être continûment suivi.
Rôle en phase de mise en œuvre

• Améliorer la dynamique du système
– Fini le temps des prospectives, des prévisions,
voici venu le pompier.
– Le directeur de projet se mobilise sur les innombrables raisons
apparemment dérisoires qui pourraient entraîner des pertes
importantes. Il faut accroître la vitesse de réaction du système
quitte à modifier les procédures de fonctionnement standards :
• limiter les remonté hiérarchiques,
• gérer les problèmes par lots plutôt qu'au cas par cas,
• ...

Evolution du type de management
Ouvert
Propice à la création
Recherche de compromis chercher à stabiliser le projet
directif
arbitre
pompier
En bref
• Etendue des compétences du chef de projet large

– Maîtrise technique
– Maîtrise de gestion
– Capacité à motiver
• Improbable chez un seul individu
=> Equipe projet
• Mais l'équipe projet, si elle est le maillon le plus
visible, ne doit pas être le seul à être analysé et à
évoluer pour améliorer l'efficacité du
projet...direction, métiers doivent s'impliquer

Conclusion
• La technique est nécessaire...

Les outils type « project management » peuvent jouer un rôle (mineur)…
mais loin d'être suffisante pour garantir le succès
• Problèmes humains dominent !
• Organisation, management, communication,

planification, planification, ...
Bibliographie
R. E Westney, Gestion de petits projets, Techniques de planification, d'estimation et de contrôle, Paris, afnor
gestion, 1991
Christophe Midler, "L'acteur projet, portrait d'un rôle d'influence", in Actes de la 8e convention de l'AFITEP :
Direction et contrôle de projet", Paris, octobre 1992, pp 13-28
L. Sayles, M. Chandler, "The project Manager : Organizational Metronome", in Managing Large Systems, New
York, Harper & Row, 1971, pp 204-226
P.J. Benghozi, Innovations et gestion de projets, Paris, Eyrolles, 1990
Vincent Giard, "Les gestions du risque dans les projets", in Actes de la 8e convention de l'AFITEP : Direction et
contrôle de projet", Paris, octobre 1992, pp 175-191
Vincent Giard, Gestion de projet, Economica, 1992
Jean-Louis Muller, "L'estimation : un métier ou un art ?", in Actes de la 8e convention de l'AFITEP : Direction
et contrôle de projet", Paris, octobre 1992, pp 175-191
Progèspace, "Guide méthodologique de gestion de projet", Support de formation 1990
J.A. McCall, Quality factors, in Encyclopædia of Software Engineering, Vol 1, pp 958--969, John Wiley &
Sons, 1994
T. Forse, Qualimétrie des systèmes complexes, mesure de la qualité du logiciel, Les éditions d'organisation

ConduiteProjet PDF

Transféré par

Informations du document

Titre original

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

ConduiteProjet PDF

Transféré par

Droits d'auteur :

Formats disponibles

Eléments de gestion de projet informatique

Conduite de projets informatiques

Pr. Jean-Marc Jézéquel

• Qu'est ce qu'un projet ?

Pr. Jean-Marc Jézéquel - Conduite de projets informatiques 2

J.-M Jézéquel 1 2000

Conduite de projets informatiques

Pr. Jean-Marc Jézéquel - Conduite de projets informatiques 3

Introduction à la culture projet

• Pourquoi de la gestion de projet ?

• Qu'est-ce qu'un projet ?

• Qu'est-ce que la gestion de projet ?

Pr. Jean-Marc Jézéquel - Conduite de projets informatiques 4

J.-M Jézéquel 2 2000

Pourquoi de la gestion de projet ?

• Les projets n'atteignent pas souvent leurs objectifs

Pr. Jean-Marc Jézéquel - Conduite de projets informatiques 5

La solution : une méthode

• Le déroulement du projet est formalisé

J.-M Jézéquel 3 2000

Des principes fondateurs

• La gestion par objectifs

Action spécifique, nouvelle, qui structure

Pr. Jean-Marc Jézéquel - Conduite de projets informatiques 8

J.-M Jézéquel 4 2000

• C'est une réponse apportée à une demande élaborée

Pr. Jean-Marc Jézéquel - Conduite de projets informatiques 9

Pr. Jean-Marc Jézéquel - Conduite de projets informatiques 10

J.-M Jézéquel 5 2000

• Maître d'ouvrage personne physique ou morale

• Maître d'œuvre personne physique ou morale qui

Pr. Jean-Marc Jézéquel - Conduite de projets informatiques 11

Phases et implication des acteurs

verrouillage réalisation maintenance

Pr. Jean-Marc Jézéquel - Conduite de projets informatiques 12

J.-M Jézéquel 6 2000

Les types de contrat

• Régie (plutôt étude)

• Définir les objectifs, la stratégie, les moyens, Décider

• Les adapter aux changements internes au projet mais

• Dans la mesure du possible les optimiser Apprendre

Pr. Jean-Marc Jézéquel - Conduite de projets informatiques 14

J.-M Jézéquel 7 2000

• Les objectifs sont :

• Ils sont obtenus par des Gérer Planification

Dilemme du management de projet

J.-M Jézéquel 8 2000

Gestion Gestion Gestion

Organisation Objectif Planification

Pr. Jean-Marc Jézéquel - Conduite de projets informatiques 23

• Management humain Animer

Pr. Jean-Marc Jézéquel - Conduite de projets informatiques 24

J.-M Jézéquel 9 2000

• Construction d'un scénario de référence décrivant :

On contrôle par rapport à ce qui est prévu…

• mise en œuvre du système d'information

• mesurer la situation du projet

• prévoir les conséquences (délais, coûts, qualité)

J.-M Jézéquel 10 2000

• Mettre en place les conditions optimales de

– définir clairement les responsabilités

Pr. Jean-Marc Jézéquel - Conduite de projets informatiques 27

• Humain • Notions simples et techniques de gestion