Cours Gestion de projet

Cours Gestion de projet Méthodes de conduite de projet Version Date Auteur V1.8 Septembre 2007 Pascal HEYER 1

Méthodes de conduite de projet Ce document est publié sous la licence libre Creative Commons-BY-NC-SA http://creativecommons.org/licenses/by-nc-sa/2.0/fr/ BY : Paternité. Vous devez citer le nom de l'auteur original. NC : Pas d'utilisation Commerciale. Vous n'avez pas le droit d'utiliser cette création à des fins lucratives et commerciales. SA : Partage des Conditions Initiales à l'identique. Si vous modifiez, transformez ou adaptez cette création, vous n'avez le droit de distribuer la création qui en résulte que sous un contrat identique à celui-ci. En outre, à chaque réutilisation ou distribution, vous devez faire apparaître clairement aux autres les conditions contractuelles de mise à disposition de cette création. Chacune de ces conditions peut être levée si vous obtenez l'autorisation du titulaire des droits. 2

Méthodes de conduite de projet Sommaire Rappel sur les activités de développement Plan de conduite Cycle de vie du logiciel Les principales méthodes Synthèse Recommandations 3

Rappel sur les activités d un projet informatique de développement Activités d ingénierie logiciel : Conception Développement Test Activités de gestion : Gestion de projet Gestion des tests Activités support : Assurance de la Qualité Gestion de configuration logiciel Documentation, traduction, formation Système, réseaux, base de données Conception Réalisation Test Gestion AQL GCL Documentation. Infrastructure (système, réseaux, SGBDR) 4

Le plan de conduite = scénario du projet Le scénario du projet dépend : De la méthode de conduite de projet utilisée qui définit les activités d ingénierie logicielle : Découpage Projet en Phases/étapes/tâches Pour chaque étape : entrée, activités (acteurs/responsabilité), sorties (produits), V&V Le cycle de vie De la Méthode de conception (modélisation) 5

Précisions sur le vocabulaire Les méthodes de conception (modélisation) permettent de décrire un système d information et ses évolutions : UML Les méthodes de conduite de projet décrivent un processus de développement qui s appuie sur une méthode de modélisation : UP RAD Des adhérences entre conception et conduite de projet : Merise/Merise, UML/(UP et ses déclinaisons) 6

Les objectifs du cours Il s agit de : Comprendre les grands concepts des principales méthodologies de conduite de projet et leurs cas d utilisation Il ne s agit pas de : De maîtriser ces méthodologies 7

Le processus de développement Phases, étapes, activités de spécification, de conception, réalisation et test avec des activités de V&V Le cycle de vie 8

Le processus de développement Est constitué de Phases/étapes/activités de spécification, de conception, réalisation et test avec des activités de V&V Leur enchaînement = Le cycle de vie Management de Projet et activités Support Lancement Version Cadrage Spécifications Conception Réalisation Tests Mise en production Approche d'ensemble Clôture 9

«Pré-historique?» Cycles de vie (1/5) Codage Utilisation Cascade simple Analyse Conception Codage Tests Maintenance 10

Cycles de vie (2/5) FC Cascade «évoluée» : Processus en V Expression des besoins Tests d acceptation Spécification du système Tests du système Conception générale Tests intégrés Conception détaillée Tests unitaires Implémentation 11

Risques et amélioration du cycle de vie en cascade (3/5) Risques élevés et non contrôlés Identification tardive des problèmes Preuve tardive de bon fonctionnement => Effet «Tunnel» Améliorations : Découplage entre phases et activités Construction du système par incréments (phases) Chaque itération a pour but de maîtriser une partie des risques et apporte une preuve tangible de faisabilité ou d adéquation Enrichissement d une série de prototypes Les versions livrées correspondent à une étape de la chaîne des prototypes 12

Amélioration du cycle de vie en cascade (4/5) Processus itératif et incrémental Un processus itératif implique la gestion d'une succession des activités de développement. Un processus incrémental signifie que l'architecture du système est constamment améliorée pour produire ces nouvelles versions qui apportent toutes des améliorations incrémentales par rapport à la précédente. Un processus à la fois itératif et incrémental doit être centré sur les risques, c'est-à-dire que chaque nouvelle version se concentre sur la prise en charge et la réduction des risques les plus importants qui pourraient menacer la réussite du projet. 13

Cycle de vie (5/5) En spirale Analyse Conception Spécifications Besoins Proto type V1 V2 Implémentation Validation Tests 14

Cycle de vie et méthodes de conduite Cascade (Merise, SDM/S) Semi-itératif (RAD) Itératif (UP, XP) 15

Merise/Historique Méthode d Étude et de Réalisation Informatique pour les Systèmes d Entreprise En 1977/1978, demande du Ministère de l'industrie : choix de sociétés de conseil en informatique pour la constitution d'une méthode de conception des systèmes d'information Équipe de J.-L. Lemoigne (Univ. d'aix / Marseille) CTI (Centre Technique d'informatique) CETE (Centre d'études Techniques de l'équipement) 16

Merise/Principes de base Principes de base de la méthode Merise Vision globale : la mise en place d'un S.I. est liée à la refonte de l'organisation Vision systémique de l'entreprise : travaux de J.-L. Lemoigne, J. Melese, J. de Rosnay 17

Merise/Approche 1. Approche par niveaux et par étapes Niveaux : en contribuant à la stratégie de l'entreprise en mettant en œuvre les règles de gestion en tenant compte des aspects organisationnels en tenant compte des aspect techniques => formalise le système futur Etapes : conception développement mise en œuvre généralisation de l'emploi du S.I. futur évolution du S.I. futur => hiérarchise les décisions au cours de la vie du projet 2. Séparation des données et des traitements 18

Merise/Principes de base FC 1. Passage par différents étapes : "le cycle d'abstraction pour la conception des S.I." >système d'information manuel >expression des besoins >modèle conceptuel (quoi) >modèle logique (qui, quand, ou) >modèle physique (comment) >système d'information automatisé 2. La séparation des données et des traitements l'agencement des données est plutôt stable les traitements sont fréquemment remaniés la séparation des données et des traitements assure une longévité au modèle 19

Merise/Chronologie des étapes 20

Merise/cycle de vie Le cycle de vie se décompose en phases : Spécifications des besoins, Conception générale, Conception détaillée, Codage et tests unitaires, Tests intégrés (intégration des modules), Tests système (intégration du logiciel), Recette. Ces phases sont échelonnées dans le temps. Une phase se termine par la remise de Livrables(s) validé(s). Une phase se termine lorsque la revue de cette phase est faite. Une phase ne peut commencer que lorsque la précédente est terminée. =>La décomposition en phases permet donc le suivi du projet. 21

Cycle de vie Processus de développement d'un logiciel classique : 22

Merise/Processus de conception La courbe du soleil (cycle complet) 23

Merise/Modélisation Merise intègre sa propre méthode de modélisation Niveau conceptuel Modèle Conceptuel de Données Modèle Conceptuel des Traitements Niveau Organisationnel Modèle Logique de Données Modèle Organisationnel des Traitements Niveau Physique Modèle Physique de Données Modèle Opérationnel des Traitements 24

Les Méthodes Agiles (AM = Agile Modeling)! " #$ %&$ & '() *+,,-($ $% './/0001 1 / $)1 2! $ % 3 4. priorité aux personnes et aux interactions sur les procédures et les outils, priorité aux applications fonctionnelles sur une documentation pléthorique, priorité à la collaboration avec le client sur la négociation de contrat, priorité à l'acceptation du changement sur la planification. 4 -+&# $ 1 25

Nombreuses Les Méthodes Agiles S appliquent en fonction de la taille et la typologie des projets 26

Historique : 1997 Principes : UP (Unified Process) Approche itérative et incrémentale L ordonnancement des itérations est basée sur les priorités entre cas d utilisation et sur l étude du risque Chaque prototype réduit une part du risque Un prototype est un programme exécutable qui peut s évaluer quantitativement Un prototype donné est construit avec des buts précis et clairement exprimés Les priorités et l ordonnancement de construction des prototypes peuvent changer avec le déroulement du plan 27

UP/Phases et itérations Des phases Inception (étude d'opportunité) Elaboration (architecture, planification) Construction Transition Des itérations Chaque cycle donne une génération Chaque cycle est décomposé en phases Chaque phase comprend des itérations Des incréments Le logiciel évolue par incrément Une itération correspond à un incrément Les itérations peuvent évoluer en parallèle 28

UP/Phases et itérations! "!# 29

UML UP/Modélisation Diagrammes de contexte Diagrammes de cas d utilisation Diagrammes d objet Diagrammes de classes Diagrammes de composants Diagrammes de déploiement Diagrammes de collaboration Diagrammes d état-transition Diagrammes d activités Diagrammes de séquences 30

UP->RUP (Rational Unified Process) Promu par IBM Rational C est un outil qui propose des gabarits partagés dans un référentiel 31

Historique XP (extreme Programming) Initiative de Kent BECK en 1996 Projet vitrine à la DRH Chrysler Principes : Pousser à l extrême les bonnes pratiques de génie logiciel Respecte le manifeste des méthodes Agiles 4 valeurs de base -> 12 pratiques 32

extreme Programming Les 4 valeurs fondamentales : Communication : tout doit être prétexte à communiquer. Privilégier les échanges directs (face à face) Simplicité : faire simple avant tout Rétroaction (feedback) : utiliser les expériences du passé et les remarques du client le plus possible Courage : il faudra peut être jeter des semaines de travail pour suivre les nouvelles exigences du client (accepter le re-work) 33

Les 12 pratiques : extreme Programming Livraisons fréquentes Planification itérative Intégration continue Tests permanents Métaphore système Conception simple Remaniement Programmation en binôme Responsabilité collective du code Rythme durable Client sur le site Standard d écriture 34

Cycle de vie extreme Programming 35

Synthèse (1/4) MERISE (conduite de projet) (ou SDM/S) : Approche «par la structure» (systémique). Inconvénients (liés à la validation en cascade) : rigidité, manque d'adaptation, éloignement des besoins détaillés des utilisateurs, on valide que du papier, «effet tunnel». UP/RUP (ou RAD) : Approche «par la structure» avec validation en cascade (pour maintenir la cohérence global) lors du premier tiers du projet. Puis, approche «par les besoins» avec construction-validation de type itératif-incrémentiel (pour assurer la conformité de l'application aux besoins de l'utilisateur). Inconvénients : pas d inconvénient «structurel», mais implique d adapter le processus à la typologie du projet. Gestion des besoins «béton». XP (ou FDD, Crystal) : Approche «par les besoins» se voulant totalement incrémentielle et itérative mais finalement débutant par une phase exploratoire (comme UP). Inconvénients : risques d'incohérences, de redondances et de déstructuration des programmes par de trop fréquentes modifications. Gestion des besoins «béton». 36

Synthèse (2/4)! Merise " #$ " #% " # " " #&$ #&% " # " #&$ 37

Synthèse (3/4) Description Points forts Points faibles Cascade Merise Propose de dérouler les phases projet de manière séquentielle Distingue clairement les phases projet Simple à mettre en œuvre Partagé par la communauté informatique Non itératif Effet tunnel Ne propose pas de modèles de Documents RUP Rational Unified Process Promu par Rational. A la fois une méthodologie et un outil prêt à l emploi (documents types partagés dans un référentiel Web) Cible des projets de plus de 10 personnes Itératif Spécifie le dialogue entre les différents intervenants du projet : les livrables, les plannings, les prototypes Propose des modèles de documents et des canevas pour des projets types Coûteux à personnaliser : batterie de consultants Très axé processus, au détriment du développement : peu de place pour le code et la technologie 38

Synthèse (4/4) Description Points forts Points faibles XP extreme Programming Ensemble de «Bests Practices» de développement (travail en équipes, transfert de compétences, etc.) Cible des projets de moins de 10 personnes Itératif Simple à mettre en œuvre Fait une large place aux aspects techniques : prototypes, règles de développement, tests Innovant: programmation en duo, kick-off matinal debout Ne couvre pas les phases en amont et en aval au développement : capture des besoins, support, maintenance, tests d intégration Elude la phase d analyse, si bien qu on peut dépenser son énergie à faire et défaire Assez flou dans sa mise en œuvre: quels intervenants, quels livrables? 39

Recommandations (Best Practices?) *. 5 '67,) 5 5 82 # *. 5 9 #( $: 1 : ; <. 5 :=' $$ ($( ) 40