Les concepts de base de la gestion de projet

Présentation au sujet: "Les concepts de base de la gestion de projet"— Transcription de la présentation:

1 Les concepts de base de la gestion de projet
MASTER IPI-NT Le 30/09/2015 Laurent DESCAMPS

2 Les concepts de base de 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écouper le 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 projet/le produit à réaliser en sous-produits ou composants ? Quelles sont les tâches nécessaires à la réalisation de chaque composants du projet/du produit ?

5 I – Comment aborder un projet
Il n ’existe pas de méthode magique et universelle, mais des règles simples qu’on peut appliquer en se posant 11 questions : Que devons nous faire ? (Actions é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 nouvelle 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 nouvelle 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, de service L’installation d’un disque dur supplémentaire, d’un serveur 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 projet Sous-projet 1 Sous-projet 2 Sous-projet 3 Fonction 1.1 Fonction 1.2 Fonction 2.1 Fonction 2.2 Fonction 3.1 Fonction 3.2 Sous-onction Sous-onction 12.1 Sous-onction Sous-onction Sous-onction Sous-onction Sous-onction Sous-onction Sous-onction Sous-onction Sous-onction Sous-onction Sous-onction Sous-onction Sous-onction Sous-onction Sous-onction Sous-onction Sous-onction Sous-onction Sous-onction Sous-onction Sous-onction Sous-onction

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 sous-projet / fonctions / 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 ~ 1995 : le modèle en Y ~ 2005 : les méthodes agiles 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 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 risques 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é 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 détail Construction Contrôle Réalisation
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 Branche fonctionnelle
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 Vérif fonctions métier Vérif déploiement Non régression Nouvelles fonctionnalités Tenue technique SAV Recette Homologation Préparer la mise à disposition des correctifs / évolutifs Livraison Doc applicative

17 II–4 Les méthodes « agiles »
Le principe de base des méthodes « Agile » est qu’il est contre-productif de planifier et de spécifier les moindres détails avant de développer un produit. Prévoir tous les aspects de la production entraîne dans la plupart des cas frustrations et pertes de temps car les aléas surviennent fréquemment C’est cette approche prédictive et séquentielle du type cycle en V que les méthodes « Agile » veulent casser au lieu de fixer les objectifs lointains, il est préférable de procéder par étapes : fixer des objectifs à court terme et commencer le développement sans perdre de temps chaque fois que cet objectif est atteint, on passe au prochain et ainsi de suite jusqu’à atteindre le but ultime

18 II–4 Les méthodes « agiles »
Au niveau d’un développement de logiciel, c’est le client qui transmet à l’équipe de développeurs sa vision du produit avec la liste des fonctionnalités qu’aurait ce produit. Il communique ainsi directement avec l’équipe et ensemble ils estiment le coût de chaque fonctionnalité pour aboutir à une idée approximative du budget final. De ce fait, on raisonne plus « produit » que « projet », d’où l’utilisation du terme « gestion de produit » au lieu de « gestion de projet »

19 II–4 Les méthodes « agiles »

20 II–5 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

21 II–6 Le RAD (Rapid Application Development)
C’est un peu l’ancêtre des méthodes « Agiles » : 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 prototypage dé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

22 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

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

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

25 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

26 IV – Le diagramme de GANTT
Les étapes de la création : 1 - Déterminer et énumérer les étapes du projet 2 - Générer une 1ère version du diagramme sans affectation de ressource et sans lien 3 - Déterminer les dépendances entre les différentes activités du projet 4 - 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) 5 - Affecter les ressources disponibles aux différentes tâches 6 - Générer une 3ème version du diagramme en gommant les conflits de ressources

27 IV – Le diagramme de GANTT
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 A Tâche B Tâche A Tâche B Tâche A Tâche B

28 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

29 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

30 V – Le PERT Program Evaluation and Review Technic (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

31 V – Le PERT Les notions de marge : 2 - La marge totale :
1 - La marge libre : C’est le retard que 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 2 - La marge totale : C’est le retard que 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 3 - Tâche critique : tâche de marge totale minimale 4 - Chemin critique : Chemin qui relie les tâches critiques du projet, correspondant à la durée du projet  il peut y avoir plusieurs chemin critiques

32 V – Le PERT 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 : 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

33 V – Le PERT Un exemple : Quel est le chemin critique ?
Quelle est la durée minimale de ce projet ? Tâche Durée prédécesseur A 2 / B 4 C D 5 A, B E 6 C, D

34 V – Le PERT Un exercice pratique : « les crêpes » Tâche Libellé Durée
Prédécesseur(s) A Mettre la farine dans le saladier 3 s B Mettre 2 œufs 30 s C Ajouter le lait et mélanger 600 s D Mettre du rhum dans une poêle E Couper les bananes 300 s F Mélanger les bananes au rhum D , E G Faire chauffer le mélange 120 s H Faire flamber 10 s I Faire cuire une crêpe J Verser le mélange sur la crêpe I , H K Manger la crêpe 60 s

35 V – Le PERT Un autre exercice pratique : « un entrepôt » Tâche A B C D
Libellé Durée Prédécesseur(s) A acceptation des plans par le propriétaire 4 j B préparation du terrain 2 j C commande des matériaux 1 j D creusage des fondations A, B E commande des portes et fenêtres F livraison des matériaux G coulage des fondations D, F H livraison des portes et fenêtres 10 j I pose des murs, de la charpente et du toit 4 j J mise en place des portes et fenêtres H, I