CHAPITRE 2 : CYCLES DE VIE ET MÉTHODES DE GESTION DE PROJET UE Gestion de Projet Master 1 STIC 2015/2016 Céline Joiron celine.joiron@u-picardie.fr 2 Introduction Un aspect fondamental de la conduite de projet repose sur les principes du découpage du projet Pour mener à bien les différentes étapes inhérentes à sa réalisation Pour réaliser une estimation globale de son coût la plus cohérente possible è Il existe différents niveaux de découpages è Découpage du projet pour en organiser la réalisation == étape préalable à la planification et nécessaire à l affectation des ressources, au calcul du coût etc. è Macro-découpage du projet en étapes == Cycle de vie 1
3 Introduction Il existe des modèles de développement génériques appelés cycles de vie des projet Des principes communs : Exprimer un besoin, définir un périmètre Concevoir la solution Construire la solution Tester Installer Surveiller è Il existe des méthodologies plus ou moins formalisées permettant d appliquer ces cycles de vie 4 Plan 1 Les cycles de vie de projet 2 Des méthodologies classiques 3 Des méthodologies agiles 4 Des activités communes 2
5 Découpages temporels génériques, appelés «modèles de développement» ou «cycle de vie» des projets Viennent d un besoin d adaptation au(x) contexte(s), du découpage temporel La démarche unique fonctionne mal sur certains types de projets Nécessité de construire le découpage temporel en fonction Des caractéristiques de l entreprise Des caractéristiques des projets 6 Il existe plusieurs types de cycles de vies (ou de modèles de développement) Les plus connus sont : Cascade En V En W Code and fix Développement évolutif En spirale Semi-itératif et Itératif 3
7 Le modèle en cascade Issu des études de ROYCE en 1970 Processus composé d une succession de phases Chaque phase est clôturée par une revue de fin de phase qui la valide officiellement on ne passe à la phase suivante qu en cas de satisfaction Pas de retour possible sur les validations à des phases précédentes. Phases Activités Livrables ETUDE PREALABLE Etude de faisabilité Analyse des besoins 2 PLANIFICATION et SPECIFICATION Organisation et mise en place du projet - Définition des besoins - Définition de la stratégie de test - Définition des interfaces utilisateurs 8 Rapport d'étude Schéma directeur Grandes lignes des besoins Cahier des charges Plan de développement (référentiel dont le planning) Spécification technique des besoins Spécification (ou plan) des tests d'acceptation Manuel utilisateur préliminaire CONCEPTION PRELIMINAIRE Ou GENERALE CONCEPTION DETAILLEE CODAGE INTEGRATION INSTALLATION Ou MISE EN PRODUCTION Conception de l'architecture - Définition des interfaces - Définition des tests d'intégration Analyse détaillée des modules - Définition des tests unitaires Codage ou programmation - Tests unitaires de chaque module Intégration - Tests d'intégration - Recette usine (tests de validation chez le fournisseur) Livraison chez le client - Installation et mise en œuvre - Recette (validation opérationnelle) Architecture des modules logiciels Spécification des interfaces Spécification (ou plan) des tests d'intégration Spécification des modules - Spécification (ou plan) des tests unitaires Code source des modules - Comptes rendus des tests unitaires Comptes rendus des tests d'intégration Comptes rendus des tests de validation Manuel utilisateur final Bordereau de livraison Comptes rendus des tests de validation Procès verbal d'acceptation par le client EXPLOITATION et MAINTENANCE Formation des utilisateurs - Corrections des anomalies - Améliorations ou évolutions - Gestion en configuration des livraisons Rapports d'anomalies Demandes d'évolutions - Versions du produit logiciel 4
9 Modèle en V Goldberg en 1986 Amélioration du modèle en cascade qui vise à réduire «l effet tunnel» Dans les étapes de début, on anticipe le travail à réaliser dans les étapes de fin Dans chacune des étapes de la branche gauche, on décrit les critères d appréciation et d acceptation du système aux étapes correspondantes de la branche droite 10 Le modèle en W Enrichissement du modèle V La 1ère partie du W dégager avec les utilisateurs des orientations solides pour la conception Développement de maquettes** ou prototypes* pour une validation plus concrète, voire une expérimentation *Prototype : logiciel de démonstration possédant certaines des fonctionnalités finales **Maquette : simulation de logiciel sans les fonctionnalités 5
11 Le modèle code-and-fix Hypothèse projet : détermination facile et rapide des besoins. Après une étape de compréhension du problème, l application est développée. Plusieurs cycles de mise au point, parfois en collaboration avec l utilisateur, permettent d atteindre le résultat visé. Compréhension du problème (besoin) Programmation Mise au point FIN Si non satisfait 12 Cycle de vie de projets Le modèle de développement évolutif On pense que les besoins ne peuvent s exprimer qu après une expérimentation Construction progressive du système de façon participative (intégration des utilisateurs) et itérative (à chaque étape le système s enrichit) Chaque cycle aboutit à une nouvelle version du système : on s arrête lorsque le client juge le système satisfaisant Détermination des besoins Programmation Expérimentation Version n 6
13 Le modèle en spirale Boehm en 1988 Même principe que le modèle évolutif, mais avec une relation contractuelle entre le client et le fournisseur. Un cycle est composé des étapes suivantes : Analyse du risque Développement d un prototype Simulation et essais du prototype Détermination des besoins (à des mailles différentes selon le cycle), à partir des résultats des essais. Validation des besoins par un comité de pilotage Planification du cycle suivant. Le dernier cycle permet de développer la version finale et d implémenter le logiciel. 14 Cycles de vie de projets Cycle de vie itératif (évolutif mais avec notion d itérations) Le projet est décomposé en itérations On applique un cycle de type (Planifier Développer Contrôler Ajuster) sur chaque itération Chaque itération est courte Né dépassant pas les huit semaines le plus souvent. L'idée est de livrer au plus tôt quelque chose qui puisse être testé par le client. Chaque itération est testée par le client et les retours sont pris en charge pour la prochaine itération 7
15 Cycle de vie semi-itératif Deux premières phases «classiques» d expression des besoins et de conception de la solution. Troisième grande phase de construction du produit par d itérations courtes Plusieurs méthodes connues reposent sur ces deux derniers types de cycle LES METHODES AGILES 16 - bilan (1) Il existe de nombreux cycles de vie décrits dans la littérature Seuls les plus «connus» sont présentés dans ce chapitre Leurs principes ne sont pas formels, ce sont plutôt des grands principes sur lesquelles une certaine philosophie de gestion de projet et des méthodes s appuient Les deux grandes classes de cycles de vie sont La modèles de types cascade et dérivés è approches séquentielles Les modèles de type itératifs 8
17 bilan (2) Pour des projets logiciels importants (par exemple réunissant des dizaines voire des centaines de personnes) les décisions impactent tellement d'ingénieurs pour de telles durées : Il vaut mieux s'assurer de la validité de chaque étape Il vaut mieux formaliser par des documents les besoins, les spécifications logicielles, l'architecture logicielle etc. è Opter plutôt pour des modèles séquentiels Dans le cas d'un projet logiciel plus modérés (moins d une douzaine de personnes pendant une année par exemple) on dispose d'une plus grande réactivité, due à : Une proximité géographique et une facilité (relative) de communication è Opter plutôt pour des modèles itératifs 18 Plan 1 Les cycles de vie de projet 2 Des méthodologies classiques 3 Des méthodologies agiles 4 Des activités communes 9