Master IMA - Gestion de projet Pascal ESTRAILLIER 1.

Master IMA - Gestion de projet

Pascal ESTRAILLIER 1



Gestion de Projets

pascal.estraillier @ univ-lr.frpascal.estraillier @ univ-lr.fr

Département Informatique - Laboratoire L3i Université de La Rochelle

Master IMA

La gestion de projetLa gestion de projet

OBJECTIFS:Introduction de l’activité et de ses caractéristiques

Décrire et discuter l’activité de planification

Montrer l’utilisation de représentations graphiques dans cette activité

Description de l’activité

(on apprend que sur le terrain)



Gestion de projet : définitionsGestion de projet : définitions

Organisation, planification et établissement des échéances d’un projet (logiciel)

Regroupement des activités assurant que le logiciel est livré dans les temps en accord avec les exigences des organismes impliqués

C’est une activité importante!!!

– le GL est une activité économique (qui donc implique des contraintes non techniques)

– Les projets bien gérés échouent parfois, les projets mal gérés échouent toujours



Rédaction de propositions Evaluation du coût des projets Planification et construction de l’échancier du projet Pilotage et révision (contrôle des évolutions) du projet Recrutement et évaluation du personnel Rédaction de rapports et préparation de présentations Observations sur ces activités

– Elles ne sont pas propres à la gestion de projets logiciels

– Les techniques d’ingéniérie classique sont applicables au Génie logiciel et vice-versa

– Les projets complexes (bâtiment etc) souffrent de problèmes similaires à ceux du Génie Logiciel

Les activités de la gestion de projetLes activités de la gestion de projet



Gestion de projets : les risquesGestion de projets : les risques

Echecs de projets dûs à des facteurs technique, mais la plupart des échecs viennent aussi des facteurs de gestion

causes typique pour l’échec d’un projet:– estimation de temps trop basse– productivité des programmeurs plus basse que prévue– une manque de connaissance de l’avancement actuel,

peut-être à cause des comptes inexacts– un manque de connaissance des besoins réels– on a pas prévoit assez de temps pour concevoir le projet

La conception et l’entretien d’une planification sont indispensables



Un plan de projet définit Un plan de projet définit (1)(1)

ce qu’on va construire

– un contexte et sommaire du système, et le but éssentiel (de point de vue de l’entreprise)

le processus

– il faut qu’on choisisse un modèle du cycle de vie cohérent aux objectifs du projet

– des méthodes ou techniques spéciales et les outils necessaires la structure

– les rôles et responsabilités des membres d’équipe, et les relations entre l’équipe et autres organisations externes (y compris le client)



Un plan de projet définitUn plan de projet définit (2)(2)

les normes, directives et procédures– très important pout les projets fait par une contracteur externe– il faut identifier les questions de documentation de façon assez

précise les activités d’administration

– les rôles et responsabilités d’équipe de gestion– y compris les reports d’avancement et le gestion des risques

les risques– l’identification et classification des risques au projet et les

strategies d’attenuation la qualité

– comment s’assurer des besoins de la qualité



Un plan de projet définit Un plan de projet définit (3)(3)

les ressources

– le matériel, les outils, et l’appareillage d'essai

– les types et nombres de personnel requis les lots de travaux

– la division du travail en morceaux maniable le budget et le programme

– une allocation des fondes et du temps aux lots de travaux

– les techniques d’estimation et de traquage le gestion des changements

– les procédures claires pour s’occuper des changements



Principles de basePrinciples de base

crée de façon itérative et entretenue– on commence par trouvant une piste des besoins vagues

aux besoins précis– on crée un plan conceptuel du produit– chaque fois que les besoins deviennent plus précis, on

raffine les estimations et le programme – quand les besoins deviennent clairs, on élabore une

conception détaillée et une strategie d’exécution et les incorpore dans le plan

– le plan fournit une structure avec laquelle on peut négocier pour les ressources et le temps nécessaires



Il faut se souvenir que …Il faut se souvenir que …

les premiers estimations des ressource et du programme sont presque toujours inacceptables

– il faut réduire l’ampleur , augmenter le temps ou les ressources

on a toujours besoin des entités avant qu’il soit possible de les avoir

Alors : le plan devient un processus de négociation entre les désirs et les ressources du client

il faut conclure la négociation aussitôt que possible



Les paradoxes du contrôle Les paradoxes du contrôle

si on ajoute des programmeurs au projet, la productivité va presque certainement diminuer

“… More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster” Fred Brooks

d’habitude, l’insistance de haute qualité aide à réduire le tempsŝ nécessaire pour achever le projet

si on a plus de temps pour le projet, on crée parfois un système moins utile



1) couverture2) Page de titre3) Table des matières4) Domaines d’application5) Documents cités en références6) Gestion du développement du

logiciel7) Génie Logiciel

8)Test de qualification officielle9) Evaluation du produit logiciel10) Gestion des configurations du logiciel11)Autres fonctions de développement du logiciel12) Notes13) Annexes

Norme DOD-STD-2167A (Software Development Plan)

Rédaction de plan de développement du Rédaction de plan de développement du logiciellogiciel



2) Page de titre2) Page de titre

Numéro de contrôle du documentDateNuméro de révision et dateTitreRéférence du système (<identification>)Référence du contrat (<identification>, <nom du client>)AuteurAuthentifié par <donneur d’ordre>, <date>Approuvé par <fournisseur>, <date>

Permettre une classification

rapide et aisée du document



4) Domaine d’application4) Domaine d’application

Identification• numéro d’identification du projet (éventuellement abréviation)

Généralités sur le système• Rôle du système faisant l’objet du développement

Généralités sur le document• Objectif et résumé du contenu du document

Liens avec les autres plans• plan de gestion des configurations du système

• plan d’archivage du logiciel

• plan du programme qualité

• plan de tests du logiciel

• plan de gestion technique du système



6) Gestion du développement du logiciel6) Gestion du développement du logiciel

Identification des ressources du projet– inventaire des ressources nécessaires (locaux, matériels et logiciels)

– structure organisationnelle (rôle et responsabilité des acteurs)

– personnels Echéanciers et jalons (activités (Gantt) et réseau d’activités (Pert)) Gestion des risques (domaines à risques, facteurs, procédures de

contrôle et d’urgence) Interface avec les partenaires (contractants associés, sous-traitants) Revues formelles Bibliothèque de développement du logiciel (procédures et méthodes) Processus d’actions correctives et rapports d’anomalies



7) Génie Logiciel7) Génie Logiciel

Organisation des ressourcesStructure organisationnelle de développement (autorité et responsabilité des partenaires)personnel (titre et qualification, exigences spécifiques)environnement de génie logiciel (outils automatisés et matériel)

Normes et procédures applicablestechniques et méthodologies pour chaque étape du cycle de viefichiers de développement du logiciel (opérations et contraintes, documentation, échéancier, tests et jeux d’essais,...)

Logiciel non développéinventaire et justification des logiciels du marché et des logiciels réutilisés envisagés



Recrutement du personnelRecrutement du personnel

Problème: il est souvent difficile de recruter le personnel “idéal” sur un projet

– Budget: impossible de payer les gens à la hauteur de leur qualification

– Indisponibilité: impossible de trouver des gens ayant l’expérience appropriée sur le marché

– Stratégie: l’organisation peut souhaiter développer un savoir-faire propre sur un projet logiciel

D’a

prè

s I.

Som

merv

ille

©19

95



Planification d’un projetPlanification d’un projet

Probablement l’une des activités les plus chronophages Activité continue depuis le démarrage du projet jusqu’à la

mise à disposition du produit

Les planning doivent êtrerégulièrement réactualisés

(nouvelles contraintes)(nouvelles données)

D’a

prè

s I.

Som

merv

ille

©19

95



Plans de projetPlans de projet

Plan

Plan qualité

Plan de validation

Plan de gestion dela configuration

Plan de maintenance

Plan de formation etde développement

Description

décrit les procédures et standards mis en œuvre pourassurer la qualité du logiciel

décrit l’approche, les ressources, les procédures et leséchéances (tests, recettes) relatives à la validation du système

Décrit les procédures de gestion de la configuration

Décrit et prévoit les besoins de maintenance du système, lescoûts et les efforts requis

Décrit comment le savoir faire et l’expérience des ingénieursseront développés

D’a

prè

s I.

Som

merv

ille

©19

95



Le processus de planificationLe processus de planification

Définir les contraintes qui pèsent sur le projetEffectuer une première estimation des paramètres du projet (degrés de liberté)Etablir des échéances et des fournituresTANT QUE le projet n’est pas fini ou annulé FAIRE

Etablir un planning du projetDémarrer les activités en fonction de ce planningATTENDRE (durée déterminée)Faire une revue d’avancement du projetRe-estimer les paramètres du projetAppliquer ces révisions au planning du projetRe-négocier les contraintes et les fournitures (s’il y a lieu)SI problème ALORS

démarrer une revue technique et une éventuelle révisionFSI

FTQ

Définir les contraintes qui pèsent sur le projetEffectuer une première estimation des paramètres du projet (degrés de liberté)Etablir des échéances et des fournituresTANT QUE le projet n’est pas fini ou annulé FAIRE

Etablir un planning du projetDémarrer les activités en fonction de ce planningATTENDRE (durée déterminée)Faire une revue d’avancement du projetRe-estimer les paramètres du projetAppliquer ces révisions au planning du projetRe-négocier les contraintes et les fournitures (s’il y a lieu)SI problème ALORS

démarrer une revue technique et une éventuelle révisionFSI

FTQ

D’a

prè

s I.

Som

merv

ille

©19

95



Organisation des activitésOrganisation des activités

Critères: L’organisation doit être effectuée en vue de produire des résultats tangibles du point de vue de l’évaluation

– les échéances marquent la fin d’une activité– les fournitures sont des produits délivrés aux “clients”

Etude defaisabilité

rapport defaisabilité

Analysedes besoins

Cahier des charges

Maquettage

Rapportd’évaluation

Etude deconception

Conceptiongénérale

Spécificationdes besoins

Spécificationdes besoins

Echéances [+Fournitures]

Activités

D’a

prè

s I.

Som

merv

ille

©19

95



Planification d’un projetPlanification d’un projet

Division du projet en tâches séparées + estimation:

– des ressources requises pour les mener à bien– de la durée nécessaire pour les accomplir

Organiser les tâches en parallèle afin d’optimiser la puissance de travail de l’équipe

Minimiser la dépendance entre tâches afin de limiter le nombre de tâches critiques suceptibles de retarder le projet

Dépend de l’intuition et de l’expériencedu chef de projet

D’a

prè

s I.

Som

merv

ille

©19

95



Les problèmes de la planificationLes problèmes de la planification

Estimation de la complexité d’un problème et du coût du développement de sa solution

La productivité n’est pas proportionnelle à la taille de l’équipe

Ajouter du personnel à un projet en retard risque fort d’engendrer un retard supplémentaire dû à un surcroit de communications

L’inattendu arrive toujours, il faut donc savoir le planifier (et ménager de la marge)

D’a

prè

s I.

Som

merv

ille

©19

95



Diagrammes et graphes d’activitésDiagrammes et graphes d’activitéswww.er.uqam.ca/nobel/d201020/www.er.uqam.ca/nobel/d201020/

– Notations graphiques & planification d’un projet– Un graphe d’activité indique:

les inter-dépendances entre tâches dans le projet:– les tâches ne doivent pas être trop courtes– ordre de grandeur: de quelques jours à deux semaines

le chemin critique entre les tâches

– Le diagramme indique: les responsables des tâches les dates de début et fin de ces tâches

– estimées (a priori)– réelles (mesurées)

Tableau de bord

d’un projet

D’a

prè

s I.

Som

merv

ille

©19

95



startT2M3T6FinishT10M7T5T7M2T4M5 T8

4/7/948 days14/7/9415 days4/8/9415 days25/8/947 days5/9/9410 days19/9/9415 days11/8/94

25 days10 days20 days5 days25/7/9415 days25/7/9418/7/9410 days

T1M1T3T9M6T11M8T12M4

Chemin

critiq

ue

Gros projets => hiérarchisation de s tâches

Exemple:Exemple:Graphe des activitésGraphe des activités

D’a

prè

s I.

Som

merv

ille

©19

95



Le graphique PERTLe graphique PERT

«Program Evaluation and Review Technique» aussi connu comme «planification par recherche du chemin critique»

(Critical Path Planning) une exemple d’un réseau «activité sur noeud»

– le poids de chaque noeud est la durée d’activité

– une flèche d’un noeud A à un noeud B dit qu’il faut que A termine avant que B commence

Gagne le contrat (0)

Création du plan des tests (5)

Conception de IUG (7)

Codagede IUG (15)

Testagede IUG (3)

La bière (1)

Étuded’usagers(5)



Une graphique PERT nous donneUne graphique PERT nous donne

le premier moment pour commencer une tâche

– étude d’usager - jour 0

– conception d’interface - jour 5 le dernier moment pour commencer une tâche (sans délai inutile)

– création du plan de tests - jour 23 la date optimale de la terminaison du projet

– 31 jours ces valeurs ne sont pas tout à fait évidentes

à partir du graphique; alors on a besoin d’une autre répresentation

Gagne le contrat (0)

Création du plan des tests (5)

Conception de IUG (7)

Codagede IUG (15)

Testagede IUG (3)

La bière (1)

Étuded’usagers(5)



Le diagramme de GanttLe diagramme de Gantt

représente la durée de chaque activité sur une graduation horaire on représente la précedence par la position de tâche: une tâche

commence juste après les tâches nécessairement précendentes on peut voir la marge de chaque tâche

– si une tâche a de la marge, on peut la commencer plus tard que nécessaire

– les tâches sans marge sont sur le chemin critique les tâches ou activités avec une longeur de zero sont représentées

comme jalons

– par exemple, le livraison d’un document



Exemple, diagramme de GanttExemple, diagramme de Gantt



De PERT à GanttDe PERT à Gantt

5 10 15 20 25 30

Jours

Gagne le contrat

Étude d’usagers

Plan de tests

Conception d’IUG

Codage d’IUG

Testage d’IUG

Le bière

5

5

7

15

3

1

marge

dernier moment de commencement possible (22)

5

activités sur le chemin critique



Les outilsLes outils

Project Get Rich Quick GUI Project Legend Project Milestone

Starting Date 31-Aug Uncompleted part of task

Completion Date 01-Oct Completed part of task

Present Date 02-Oct Overdue part of task

Task Starting Ending % No. of Sep

Description Date Date Comp. Days31 3 4 5 6 7

10

11

12

13

14

17

18

19

20

21

24

25

26

27

28 1 2 3

1Get Rich Quick GUI ProjectWin Contract 31-Aug 31-Aug 100 0Interview User 01-Sep 05-Sep 60 5Create Test Plan 06-Sep 10-Sep 0 5Design GUI 06-Sep 12-Sep 0 7Code GUI 13-Sep 27-Sep 0 15Test GUI 28-Sep 30-Sep 0 3Drink Beer 01-Oct 01-Oct 0 1

il y a beacoup d’outils de planification qui peut crée ces graphiques, surtout le diagramme de Gantt

– par exemple, voir le progiciel ProjeX pour Excel à http://www.waa-inc.com/projex/index.htm



Exemple:Exemple:Diagramme d’affectation du personnelDiagramme d’affectation du personnel4/711/718/725/1/88/815/822/829/85/912/919/9T4T8 T11T12T1T3T9T2T6T10T7T5FredJaneAnneMaryJim

D’a

prè

s I.

Som

merv

ille

©19

95



9) Evaluation du produit logiciel9) Evaluation du produit logiciel

Organisation et ressourcesProcédures et outils d’évaluationProduits de la sous-traitanceEnregistrement des évaluationsEvaluations de produits liées à une activité



10) Gestion des configurations du 10) Gestion des configurations du logiciellogiciel

Identification et rédaction des caractéristiques fonctionnelles et physique des articles de configuration

organisation et ressourcesidentification de configuration (documents pour le référentiel)procédures de maîtrise des configurationssuivi des états des configurationsaudits de configurationjalons de la gestion des configurations



Organisation du travail,Organisation du travail,remarque 1remarque 1

Le processus de développement est une suite d’opérations séquentielles parfois parallélisables entre elles

STR (2,3)

STR (2,2)

STR (2,1)Analyse

STR (3)

STR (2)

STR (1)Analyse

Cahier des charges

Application

IntégrationModule (1)

Module (2)

Module (3)

IntégrationModule (2,1)

Module (2,2)

Module (2,3)

Conception (descendante)augmentation du “parallélisme”

Réalisation (ascendante)diminution du “parallélisme”




Il est possible de “pipe-liner” le processus de développementen fonction des numéro de version des composants

réalisation intégration éval. perf.

module v0.0

module v0.1 module v0.0

module v0.2 module v0.1 module v0.0






“L’enfer, c’est les autres”

Le travail en équipe implique une discipline

Support par des outils (AGL)

partage de donnéesnon respect des règles

“turn over”



Points clefsPoints clefs

Une bonne gestion de projet est essentielle pour réussir La nature du logiciel pose des problèmes particuliers de gestion Les chefs de projet ont différents rôles mais le plus important consiste en

la planification, l’estimation et la mise en place d’échéances Planification et estimation sont des activités itératives et continues

pendant toute la durée du projet Une échéance est une date “prévisible” pour la présentation d’un rapport

à la hiérarchie Utilisation de techniques graphiques pour faciliter l’activité d’évaluation



Conclusion:Conclusion:être un “chef de projet”être un “chef de projet” Difficile

– Compréhension des aspects techniques du projet (surtout s’il est vaste)– Rapport à la hiérarchie (gestion des délais, coûts, évaluations diverses

etc.)– Beaucoup de “paperasse”

Comment s’en sortir Etre un bon “public relation”

– Maintenir la cohésion d’une équipe Savoir se faire “respecter” Avoir une bonne culture informatique

– “sentir” les bonnes solutions– faire des choix techniques sans appréhender un problème dans les

détails

Master IMA - Gestion de projet Pascal ESTRAILLIER 1.

Documents

Transcript of Master IMA - Gestion de projet Pascal ESTRAILLIER 1.