GESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET

GESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET 1 Tianxiao LIU Licence Professionnelle Réseaux & Sécurité Université de Cergy-Pontoise http://depinfo.u-cergy.fr/~tliu/lpg.php

PLAN Objectif et définition des termes Modèles fondamentaux et génériques Modèles pratiques Modèles agiles ITIL et PRINCE2 2

OBJECTIF Définir la démarche à appliquer à un projet Attention : on parle ici des cycles de réalisation de projet, pas de notions marketing 4 facteurs majeurs : Minimiser les évolutions fonctionnelles en cours de projet Soutenir la démarche d assurance qualité (QA) Maîtriser les coûts et les risques Garantir sa conformité aux règles contractuelles et juridiques 3

OBJECTIF D autres éléments pouvant avoir une influence La culture de l entreprise Les équipes de projet Le niveau de connaissance des utilisateurs Le contexte du projet Les acteurs intervenant Le type du projet 4

DÉFINITIONS DES TERMES Cycle de vie d un projet informatique Une démarche globale de gestion d un projet informatique Activités minimales dans un cycle de vie du logiciel Définition des objectifs, analyse des besoins et faisabilité Conception générale, conception détaillée, développement Tests, recette, documentation Accompagnement, mise en production, assistance et maintenance Ceci est un rappel des étapes de projet 5

DÉFINITIONS DES TERMES Prototype L embryon du produit initial : "Je saurai ce que je veux quand je le verrai" Viser à livrer rapidement une maquette de la solution à développer avec un minimum de fonctions viables Clarifier les besoins afin d y arriver à une meilleure définition des spécifications fonctionnelles et techniques Eviter l écart entre les besoins réels, ceux exprimés et ceux interprétés Conseil Dans votre discours de présentation d un prototype, prenez soin de ne pas faire croire aux futurs utilisateurs que le produit est déjà terminé 6

DÉFINITIONS DES TERMES Effet tunnel Point de départ : connu Point d arrivée : inconnu Rester dans le tunnel noir Pour les utilisateurs Pendant très longtemps, pas de communication avec les membres de l équipe de projet Grand risque d avoir un résultat non satisfaisant! Conseil Eviter les effets tunnel à tous efforts possibles 7

MODÈLES FONDAMENTAUX ET GÉNÉRIQUES : EN CASCADE Expression des besoins retour validé? Spécifications retour validé? Conception retour validé? Développement retour validé? Test retour validé? Maintenance 8

MODÈLES FONDAMENTAUX ET GÉNÉRIQUES : EN CASCADE Principe Une suite de phases dans un déroulement linéaire Validé avancer, non validé retourner Avantages et inconvénients Bonne réduction de risques en minimisant l impact des incertitudes Bonne solution pour les projets peu complexes Problèmes non découverts avant les tests Pas de prise en compte des évolutions Difficulté d amélioration des performances Durée du projet inférieure à un an 9

MODÈLES FONDAMENTAUX ET GÉNÉRIQUES : EN V Expression des besoins Validation des besoins Spécifications Qualification Conception globale Tests d'intégration Conception détaillée Tests unitaires Développement 10

MODÈLES FONDAMENTAUX ET GÉNÉRIQUES : EN V Principe Modèle orienté tests Décomposition et recomposition Avantages et inconvénients Proposer au fur et à mesure une démarche de réduction des risques, en minimisant progressivement l impact des incertitudes Exclusion de l utilisateur dès la phase de conception car trop technique Contrôle qualité significatif seulement en fin de projet Dans un contexte compétitif, risque éventuel de ne pas respecter les délais 11

MODÈLES FONDAMENTAUX ET GÉNÉRIQUES: RAD (RAPID APPLICATION DEVELOPMENT) Analyse et conception rapide Tests Développement Construction Cycle prototype Raffinement Démonstration 12

MODÈLES FONDAMENTAUX ET GÉNÉRIQUES: RAD (RAPID APPLICATION DEVELOPMENT) Principes Livrer rapidement un minimum de fonctions viables Utilisation de prototype Démarche participative de tous les intervenants Priorité aux délais (limites de temps fixés pour chaque résultat souhaité) Avantages et inconvénients Préconisé pour des projets à fortes contraintes (architectures, coûts, délais) Contexte de participation active Temps de développement réduit Grosse pression quasi-constante 13

MODÈLES FONDAMENTAUX ET GÉNÉRIQUES: UP (UNIFIED PROCESS) Huit caractéristiques composant le modèle : Le pilotage par les cas d utilisation Centré sur l architecture Itératif et incrémental Gestion des besoins et des exigences La production de composants : modulaire La modélisation visuelle La qualité Piloté par les risques 14

MODÈLES FONDAMENTAUX ET GÉNÉRIQUES: UP (UNIFIED PROCESS) Quatre activités principales Initialisation : vision globale Analyse : représentation quasi idéale de la solution Conception : ensemble des éléments opérationnels Implémentation : développement des parties concrètes Modèle générique 5 modèles dérivés Catalysis ESA (Etreme System Analysis) RUP (Retional Unified Process) EUP (Entreprise Unified Process) 2TUP (2 Tracks Unified Process) 15

MODÈLES PRATIQUES : INCRÉMENTAL Expression des besoins Spécifications Conception système Conception incrément Conception incrément Conception incrément Développement Développement Développement Tests Tests Tests Maintenance Maintenance Maintenance 16

MODÈLES PRATIQUE : INCRÉMENTAL Principe Itération sur l'embryon du produit initial (prototype) jusqu'à obtention du produit final Un découpage en composant fonctionnel Livraisons successives Première livraison : composant qui représente les coûts les plus importants Deuxième livraison : de nouvelles fonctionnalités et les demandes de changements relatives à la première livraison Evolution de la fabrication du logiciel perceptible par la MOA (Maîtrise d'ouvrage) 17

MODÈLES PRATIQUE : INCRÉMENTAL Avantages / Inconvénients Permettre la correction des erreurs de développement, conception et spécification Apte pour les projets de grande taille ou d'une relative complexité Réduire l'impact des demandes d'évolution en cours de projet Technologies modulaires (composants) réutilisation des fonctionnalités élémentaires qualité du produit 18

LES MODÈLES AGILES Objectif Eviter les écarts importants entre le résultat obtenu et l'expression des besoins initiaux Concevoir des logiciels en impliquant au maximum le demandeur (MOA) Principe Priorité aux personnes et aux interactions sur les processus et les outils Applications fonctionnelles > documentation exhaustive Collaboration > négociation contractuelle, avec les utilisateurs Acceptation des changements > planning détaillé 19

MODÈLE AGILE : ASD (ADAPTATIVE SOFTWARE DEVELOPMENT) Spéculer Collaborer Apprendre Boucle d'apprentissage Initialisation Planification Planification Planification Planification Planification Planification Développement Planification des composants Planification Planification Planification Contrôle qualité Réunion finale 20

MODÈLE AGILE : ASD (ADAPTATIVE SOFTWARE DEVELOPMENT) Principe S'adapte particulièrement aux projets e-business Réalisation en des temps très cours Support de nombreux changements et incertitudes Focalisation : viser les résultats plutôt que les tâches Itération : Evolution en fonctions des retours d'utilisateurs Échéances (timeboxing) : chacune la fin d'une itération Gestion des risques : absence totale de stabilité! Changement : capacité à supporter un changement fonctionnel ou technique en cours de développement 21

MODÈLE AGILE : ASD (ADAPTATIVE SOFTWARE DEVELOPMENT) Avantages / Inconvénients Grande souplesse dans le changement Rapidité, respect des délais Implication de la MOA Nécessité toutefois d'être adaptée à chaque projet, selon le contexte Nécessité d'être enrichie d'autres caractéristiques des diverses méthodes agiles 22

MODÈLE AGILE : FDD (FEUTURE DRIVEN DEVELOPMENT) Définition d'un modèle global Inventaire des fonctionnalités Planification à partir des fonctionnalités Conception d'une fonctionnalité Linéaire Développement d'une fonctionnalité Mise à disposition d'une fonctionnalité 23 Itération

MODÈLE AGILE : FDD (FEUTURE DRIVEN DEVELOPMENT) Principe Mise en places des itérations très courtes Chaque itération produit un livrable fonctionnel Bases : caractéristiques de l'application (features) Avantages / Inconvénients Motiver les développeurs : livrable utilisable Sécuriser le chef de projet : état de l'avancement visible au gré des itérations Satisfaire les clients : livrables concrets, planning clair Maintenance de l'ensemble des composants peut parfois se muer en challenge quotidien programmation par binôme (pair-programming) 24

MODÈLE AGILE : SCRUM Point quotidien Initialisation Sprint Clôture Mise en production Itération Backlog 25

MODÈLE AGILE : SCRUM Principe Backlog : toutes les tâches à réaliser (correspondant aux fonctionnalités de la solution Sprint : Equipe de développement isolée pendant une période (ex. 30 jours) Point quotidien : 30 minutes max. Avantages / Inconvénients Méthode rigoureuse Concentration pleine sur les objectifs sans autre forme de perturbation Risque : changement par MOA pendant la phase de sprint 26

MODÈLE AGILE : XP (EXTREME PROGRAMMING) Analyse technique Itération Développement Mise en production Maintenance Planification Itération "Ajout de fonctionnalités 27

MODÈLE AGILE : XP (EXTREME PROGRAMMING) Principe Communication : programmeurs utilisateurs Simplicité : choisir la solution la plus simple Retour d'expérience : Implication des utilisateurs dans les tests dès le premier jour maturité des membres de l'équipe Livraison : avoir lieu dès que possible Cycle de vie s'apparentant à une méthodologie, une philosophie, voire une éthique critique et ouvert 28

MODÈLE AGILE : XP (EXTREME PROGRAMMING) Avantages / Inconvénients Efficace pour les petits projets Solutions collant aux besoins de la MOA Pas adaptée pour des projets de type forfaitaire ou pour des équipes de plus d'une dizaine de personnes Demande un bon niveau de MOA disponibilité permanente Le succès du projet n'est envisageable que si tous ses acteurs adhèrent pleinement à la méthode! 29

LES BONNES PRATIQUES Trois référentiels de bonnes pratiques COBIT (Control Objectives for Business & Related Technology) ITIL (Information Technology Infrastructure Library) CMMi (Capability Maturity Model integration) D'autres méthodologies de bonnes pratiques PMI (Project Management Institute) PRINCE2 (PRojects INControlled Environments) Spice (ISO 15504) ISO 17799 ISO 9000 30

BONNE PRATIQUE : ITIL Objectif Amélioration de la satisfaction client Réduction des coûts Une meilleure communication entre les acteurs de la direction informatique et les clients Amélioration de la productivité et la réutilisation de l'expérience Principe Un recueil cohérent de livres des meilleurs pratiques de la gestion de services informatiques 31

BONNE PRATIQUE : ITIL Modules proposés Service support Service Delivery Software Asset Management ICT (Information Communication Technology) Infrastructure Management Application Management Security Management Environmental Infrastructure Process Project management 32

BONNE PRATIQUE : PRINCE2 Principe Tenir compte des facteurs changeants de l'environnement du projet susceptibles d'influencer son succès Un langage commun aux participants d'un projet Fait l'objet de deux certifications Fondamental : l'examen qui vérifie qu'un collaborateur dispose des connaissances nécessaires pour participer à un projet géré selon la méthode PRINCE2 Praticien : suite à l'examen fondamental, donne la garantie d'une maîtrise parfaite de la méthode pour gérer un projet 33

BONNE PRATIQUE : PRINCE2 Diriger le projet Elaborer le projet Contrôler une étape Gestion de la livraison du produit Clôture Lancer le projet Gestion de la livraison du produit Planification 34

CONSEILS POUR CYCLE DE VIE Soyez pragmatique La seule étape incontournable: l épreuve de qualification par les utilisateurs Essayez de prévoir toutes les contraintes dès le début Ceux non-planifiés au début seront négligés à la fin Créez votre propre méthode Un mélange des bouts de chaque méthode répondant à vos besoins 35

CONCLUSION La production d'un projet informatique est : choisir un cycle de vie ne pas rester figé dans un modèle (changer, adapter) planifier (découpage, contrôles qualité, revues) autoriser une certaine souplesse prévoir : ce qui n'est pas fait aujourd'hui risque d'être oublié demain assurer une forte communication entre tous les intervenants adhérer à la méthodologie utilisée faire preuve de bon sens 36