Les concepts de base de la gestion de projet

1. Les concepts de basede la gestion de projet  MASTER IPI-NT Le 01/10/2014 Laurent DESCAMPS

2. Les concepts de basede la gestion de projet I - Comment aborder un projet II - Les différents cycles de vies III – Les outils de planification IV – Le diagramme de GANTT V - Le PERT

3. I – Comment aborder un projet « La chose la plus difficile au monde est décomposable en une multitude de choses faciles » LAO-TSEU « Diviser chacune des difficultés, que j’examinerai en autant de parcelles qu’il se pourrait et qu’il serait requis pour mieux les résoudre » DESCARTES

4. I – Comment aborder un projet • Toujours découperle projet • Le diviser pour mieux le maîtriser • Objectif de base : définir l’organisation technique du projet en répondant à 2 questions • Comment découper le produit à réaliser en sous-produits ou composants ? • Quelles sont les tâches nécessaires à la réalisation de chaque composants du produit ?

5. I – Comment aborder un projet • Il n ’existe pas de méthode magique et universelle, mais des règles simples en 11 questions : • Que devons nous faire ? (Action élémentaires) • Qui va le faire ? • Comment va-t-il le faire ? Quels moyens sont nécessaires pour le faire ? (Si on ne dispose pas directement de ceux-ci, leur mise en place devient une action élémentaire) • Qui va contrôler ? • Comment va t-il contrôler ? Quels moyens sont nécessaires pour contrôler (Si on ne dispose pas directement de ceux-ci, leur mise en place devient une action élémentaire) • Qui va coordonner les travaux ? • Comment va t-il coordonner ces travaux ? Par quels moyens ? • Qui va garantir la qualité de ces travaux ? • Comment va t-il faire pour le garantir ? Par quels moyens ? • Qui va exploiter le résultat des travaux ? • Comment va t-il faire pour l’exploiter ? Par quels moyens ?

6. I – Comment aborder un projet • En répondant à ces 11 questions : • On écrit ce qu’on connait et on écrit également ce qu’on ne connait pas  « tout ce qui n’est pas écrit n’existe pas » • En définissant tous les détails possibles, on peut identifier des tâches élémentaires du projet : • La réalisation d’un programme • La conception d’une fonction • La validation d’une conception • Le passage d’une commande de logiciel, d’un service • L’installation d’un matériel, d’une machine • La vérification d’un document • La livraison d’une fonction • Une réunion et son organisation • La mise en place d’une procédure de test • La préparation d’une formation • L’intégration d’une personne dans l’équipe • ....

7. I – Comment aborder un projet En répondant à ces questions, on définit la nomenclature du projet, son découpage et une planification de 1er niveau

8. I – Comment aborder un projet • Travaux pratiques : • Vous êtes une entreprise qui conçoit, produit et commercialise des véhicules automobiles • Votre projet : commercialiser un nouveau type de véhicule, au plus grand nombre possible de clients • Découper votre projet en tâches /sous-tâches • Lister les tâches nécessaires à la réalisation de chaque tâche • 3 groupes : • ~ 10 minutes de préparation • ~ 5 minutes de restitution par groupe

9. II Les différents cycles de vie • Différents modèles ont vu le jour au fil du temps pour gérer le cycle de vie d’un projet : • ~ 1970 : le modèle en cascade • ~ 1985 : le modèle en V • ~ 2000 : le modèle en Y • D’autres modélisations plus spécialisées ont vu le jour pour répondre à des organisations particulières : le modèle en spirale, le RAD … • On peut distinguer 3 types de modèles : • En cascade (issu du bâtiment) • Semi-itératif • une 1ère étape en cascade pour le cadrage et la conception • une 2nde étape itérative pour la construction de la solution • Itératif : chaque besoin est traité dans une itération complète (faisabilité, élaboration, fabrication, exploitation ou transition)

10. II–1 Le modèle en cascade • Les travaux se déroulent par phases successives, chacune étant caractérisée par la nature de l’activité principale et des produits correspondants  à chaque étape on a un livrable • Chaque phase se termine par une activité de vérification et de validation destinée à éliminer le plus d’anomalies possible dans les produits réalisés  à chaque étape on valide le livrable • Autant que possible les retours « arrière » sur les phases précédentes se limitent à un retour sur la phase immédiatement antérieure  sauf à remettre en cause le projet • Ce modèle est très bien adapté au développement d’un logiciel ne posant pas de gros problème de faisabilité, sans trop d’innovation et sans trop d’imprécision dans le besoin initial

11. II–1 Le modèle en cascade Ce modèle s’adapte très bien à des projets de type migration (an 2000, passage à l’euro, migration technique, changement SGBD …) ou à l’industrie (mise en place d’une chaine de production) Faisabilité du système Planification Cahier des charges Conception Analyse détaillée Développement Intégration Ce modèle n’est par contre pas adapté à des projets sur lesquels on doit être très réactif et très souple (nouvelle offre commerciale pour contrer un concurrent, projet réglementaire pour limiter les risque juridiques … Mise en œuvre Exploitation Maintenance

12. II–1 Le modèle en cascade • Les limites du modèle en cascade : • Trop de problèmes non découverts avant les tests • Pas de prise en compte des évolutions sur les longs projets • Apparition de besoins fonctionnels lors du codage • Pas de tests de performances avant la réalisation • Difficulté d'amélioration des performances •  Cause de l'échec de nombreux projets

13. II–2 Le modèle en V • C’est un concept de gestion de projet élaboré pour répondre au manque de réactivité du modèle en cascade • Le modèle en V part du principe que les procédures de vérification de la conformité du logiciel aux spécifications doivent être élaborées dès les phases de conception • Ce modèle tient d'avantage compte de la réalité, le processus de développement n'est pas réduit à un enchaînement de tâches séquentielles. Il montre que : • c'est en phase de spécification qu’on se préoccupe des procédures de qualification • c'est en phase de conception globale qu'on se préoccupe des procédures d'intégration • c'est en phase de conception détaillée qu'on prépare les tests unitaires

14. II–2 Le modèle en V temps Validation des besoins Faisabilité du projet Validation Recette utilisateur Cahier des charges Spécifications générales Validation de l’intégration Conception Validation des tests unitaires Analyse détaillée Construction Contrôle Développement Réalisation détail

15. II–3 Le modèle en Y • Le modèle en Y permet de piloter le projet par les risques en éliminant en priorité les causes majeures d ’échec • Le modèle en Y est centré sur l’architecture : on effectue le choix de l’architecture logicielle dès les premières phases du projet (la conception se basant sur ces choix) • Le modèle en Y propose un cycle de développement qui dissocie les aspects techniques des aspects fonctionnels et propose une étude parallèle des deux branches : • fonctionnelle : étude de l’application • technique : étude de l’implémentation

16. II–3 Le modèle en Y Préparation Faisabilité du projet Validation des besoins Branche fonctionnelle Cahier des charges Branche technique Définir les fonctions métier Elaborer l’architecture technique Macro chiffrage Les positionner dans l ’architecture Elaborer l ’architecture applicative Élaborer le cahier de recette Prototypage Conception Spécifs Tech Détaillées Dossier d ’exploitation Plan de configuration Développement Intégration Non régression Nouvelles fonctionnalités Tenue technique Vérif fonctions métier Vérif déploiement SAV Recette Homologation Préparer la mise à disposition des correctifs / évolutifs Livraison Doc applicative

17. II–4 Le modèle en spirale • Détermination des objectifs du projet et des alternatives possibles, et identification des contraintes • Évaluation des alternatives et l'identification des risques, l'alternative choisie est celle qui réduit les risques du projet • Développement et vérification du produit • Planification des phases suivantes Reprend les différentes étapes du cycle en V. Par l'implémentation de versions successives, le cycle recommence en proposant un produit de plus en plus complet et durable

18. II–5 Le RAD (Rapid Application Development) • Ce modèle tend à raccourcir le cycle de vie voire à le supprimer. La phase de spécification/conception est remplacée par une phase de prototypage menée conjointement avec le client • Cette approche est supportée par de nombreux outils RAD (outils de développement graphiques générant des prototypes de fonctions, procédures, classes d’objets …) • La phase de prototypagedébouche sur une interface validée par le client. L'outil génère des squelettes de fonctions, de classes d’objets. Le comportement de chaque objet de l'interface est ensuite décrit dans un langage approprié et ses fonctionnalités programmées • De nombreuses entreprises ont employé ce modèle dans les années 90 et ont eu des soucis lors de la maintenance des applications ainsi développées à cause du manque de conception car cette dernière est calquée sur l'interface ce qui n'est pas forcément une bonne idée

19. III – Les outils de planification Pourquoi planifier ? • Planifier pour définir les jalons, les dates de livraison • Planifier pour contrôler et piloter : et à chaque instant savoir qui fait quoi et ce qu’il reste à faire • Planifier pour mieux gérer les impondérables et s’adapter

20. III – Les outils de la planification Le diagramme de GANTT permet de modéliser graphiquement la planification des diverses tâches d’un projet

21. III – Les outils de la planification Le PERT permet d’identifier et de visualiser le ou les chemins critiques du projet d’un projet

22. IV – Le diagramme de GANTT • Mis au point par un américain du nom de Henri Laurence GANTT (1861 – 1919). Il était ingénieur mécanicien et consultant en management . Il a mis au point le diagramme portant son nom vers 1910 pour aider au développement de grand projets d’infrastructure (ponts, barrages …) • Ce diagramme fournit une synthèse graphique et le planning de toutes les activités, éléments et dépendances d’un projet, sous forme d’une décomposition hiérarchique structurée du travail à réaliser • Le diagramme de GANTT est construit avec • un axe horizontal représentant le temps (décomposé en incréments : jours, semaine, mois …) • un axe vertical représentant les tâches qui composent le projet

23. IV – Le diagramme de GANTT • Les étapes de la création : • Déterminer et énumérer les étapes du projet • Générer une 1ère version du diagramme sans affectation de ressource et sans lien • Déterminer les dépendances entre les différentes activités du projet • Générer une 2ème version du diagramme en intégrant ces dépendances (cela permet aux tâches de se réaliser dans l’ordre établie malgré les éventuelles modifications de planification) • Affecter les ressources disponibles aux différentes tâches • Générer une 3ème version du diagramme en gommant les conflits de ressources

24. IV – Le diagramme de GANTT Tâche A Tâche B Tâche A Tâche B Tâche A • Les types de liens : • Fin-Début : pour ne démarrer une tâche que lorsque la précédente est terminée • Début-Début : pour synchroniser le démarrage d’une tâche avec une autre • Fin-Fin : pour synchroniser la fin d’une tâche avec une autre Tâche B

25. IV – Le diagramme de GANTT • Les avantages du diagramme de GANTT : • Bonne synthèse graphique • Technique commune et facile à mettre en œuvre • Adapté aux projets de petites et moyennes taille (moins de 30 activités) • Les limites du diagramme de GANTT : • Les projets sont souvent plus complexes que ce qui peut être communiqué via un diagramme de GANTT • Ne représente qu’une seule dimension des contraintes (coût, qualité, délai) • Ne permet pas de rendre compte simplement des effets retards de certaines activités (surcoûts) • Trop vite illisible s’il y a de nombreuses dépendances

26. IV – Le diagramme de GANTT • Un exercice pratique : « le petit déjeuner » • Les tâches : • Mettre la table (2 minutes) • Débarrasser et Nettoyer la table encombrée depuis la veille (2 minutes) • Vider le lave vaisselle (4 minutes) • Aller chercher le lait à la cave (1 minute) • Faire bouillir le lait (3 minutes) • Verser le lait dans les bols (1 minutes) • Aller chercher les œufs dans le poulailler (2 minutes) • Casser les œufs (1 minute) • Faire cuire les œufs (4 minutes) • Servir les œufs (1 minute) • Presser les oranges (2 minutes) • Servir le jus d’orange (1 minutes) • Couper des tranches de bacon (4 minutes) • Faire cuire le bacon (2 minute) • Servir le bacon (1 minutes) • Les ressources : Riri, Fifi et Loulou dispo à 100 % et qui savent tout faire • Les contraintes : Tout doit servi chaud en même temps pour déjeuner et on ne peut mettre la table que lorsqu’elle est débarrassée et le LV vidé • Le timing : 15min de préparation puis présentation de la solution au tableau

27. V – Le PERT Program Evaluation and ReviewTechnic(technique d’évaluation et de révision de programme) : c’est une méthode consistant à mettre en ordre, sous forme de réseau, les tâches d’un projet qui grâce à leurs dépendances et à leurs chronologies concourent toutes à l’obtention d’un produit fini Méthode créée en 1958 par Willard FRAZARD à la demande de la marine américaine qui veut optimiser son programme de missiles nucléaires « Polaris » et rattraper le retard par rapport à l’URSS  plusieurs milliers d’acteurs et au final un gain de plus de 2 ans Contrairement au GANTT, le diagramme de PERT permet de montrer des liens plus complexes et les connections qui en découlent (partage de ressources, de matériels …) Le diagramme de PERT permet de calculer le meilleur temps de réalisation d’un projet

28. V – Le PERT • Les notions de marge : • La marge libre : • C’est le retardque l’on peut prendre dans la réalisation d’une tâche sans retarder la date de début au plus tôt de toute autre tâche qui suit • Différence entre la plus petite des dates de début au plus tôt (DTO) des tâches suivantes et la date de fin au plus tôt (FTO) de la tâche considérée • La marge totale : • C’est le retardque l’on peut prendre dans la réalisation d’une tâche sans que la durée totale du projet global en soit affectée • Différence entre la date de fin au plus tard (FTA) et la date de fin au plus tôt (FTO) de la tâche considérée • Tâche critique : tâche de marge totale minimale • Chemin critique : Chemin qui relie les tâches critiques du projet, correspondant à la durée du projet  il peut y avoir plusieurs chemin critiques

29. V – Le PERT Nom tâche Durée tâche Début au + tôt Début au + tard Fin au + tôt Fin au + tard Marge totale Marge libre • Pour construire un graphe PERT, on utilise la méthode des niveaux : • On détermine les tâches sans antécédents, qui constituent le niveau 1 • On identifie ensuite les tâches dont les antécédents sont exclusivement du niveau 1. Ces tâches constituent le niveau 2, et ainsi de suite… • Le formalisme :

30. V – Le PERT • Un exemple : • Quel est le chemin critique ? • Quelle est la durée minimale de ce projet ?

31. V – Le PERT • Un exercice pratique : « les crêpes »

32. V – Le PERT • Un autre exercice pratique : « un entrepôt »