Les concepts de base de la gestion de projet

Les concepts de basede la gestion de projet MASTER IPI-NT Le 25/09/2013 Laurent DESCAMPS

Les concepts de basede la gestion de projet Mercredi 9/10 ------------------- • Alexis Boutrouille • Florian Bruffaert • Ophélie Debiève • Dimitri Descamps • Romain Frangi • Pierre Frayer • Maxence G. de Montauzan • Alizée Lebrun • Sylvain Magnier • ZouhairMakhout • Nicolas Vandemeulebrouck Mercredi 2/10 : --------------------- Thomas Aubry Maxime Boucher Franck David Karl Deleforterie Nassim Hassaine Pierrick Lesage Maxime Vanpeene François Lefebvre SoufianeAgadr Pierre Bailleul Alexandre Bienvenu

Les concepts de basede la gestion de projet • I - Comment aborder un projet • II - Les différents cycles de vies • Le modèle en cascade • Le modèle en V • Le modèle en Y • Les autres modèles • III – Les outils de planification • IV – Le diagramme de GANTT • V - Le PERT

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

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 produit à réaliser en composants ? • Quelles sont les tâches nécessaires à la réalisation de chaque composants du produit ?

I – Comment aborder un projet • Il n ’existe pas de méthode magique et universelle, mais des règles simples : • 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 ?

I – Comment aborder un projet • En répondant à ces 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, • L’installation d’un matériel, • La vérification d’un document, • La livraison d’une fonction, • Une réunion, • 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, • ....

I – Comment aborder un projet En répondant à ces questions, on peut mettre en place la nomenclature du projet :

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 composants (sous-produits), • Lister les tâches nécessaires à la réalisation de chaque composant, • 4 groupes : • ~ 10 minutes de préparation • ~ 5 minutes de restitution par groupe

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, • Il existe d’autres modélisations moins utilisées ou plus spécialisées telles que le modèle en spirale, le RAD … • On peut distinguer 3 types de cycles de vie : • 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)

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 • Ce modèle est 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 • 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 durant cette phase  à 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

II–1 Le modèle en cascade Ce modèle reste très bien adapté à des projets de type migration (an 2000, passage euro, migration technique, changement SGBD …) ou à l’industrie lourde (mise en place d’une chaine de montage) Faisabilité du système Planification Cahier des charges Conception Analyse détaillée Développement 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 tel due la loi « Lagarde » ou un changement de fiscalité …) Intégration Mise en œuvre Exploitation Maintenance

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

II–2 Le modèle en V • 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 que l'on se préoccupe des procédures de qualification • c'est en phase de conception globale que l'on se préoccupe des procédures d'intégration • c'est en phase de conception détaillée que l'on prépare les tests unitaires

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

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

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

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

II–5 Le RAD (Rapid Application Development) • Ce modèle de développement 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 , 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 type de développement 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 inhérent à la démarche, en effet la conception est calquée sur l'interface ce qui n'est pas forcément une bonne idée

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

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

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

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,

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

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

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

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, • Le timing : 15 minutes de préparation et présentation de la solution au tableau

V – Le PERT Program of Evaluation and ReviewTechnique : 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 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

V – Le PERT • Les notions de marge : • La marge : le retard qu'il est possible de tolérer dans la réalisation d’une tâche, sans que la durée optimale prévue du projet global en soit affectée • 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 début au plus tard et début au plus tôt d’une tâche • La marge totale : • C’est le retard que l’on peut prendre dans la réalisation de cette tâche sans retarder l’ensemble du projet • Différence entre le maximum des dates de début au plus tôt des tâches suivantes et la date de fin au plus tôt de la tâche considérée • Tâche critique : tâche de marge 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

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 :

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

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

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

Les concepts de base de la gestion de projet