MIAGE MASTER 1 Cours de gestion de projet

Présentation au sujet: "MIAGE MASTER 1 Cours de gestion de projet"— Transcription de la présentation:

1 MIAGE MASTER 1 Cours de gestion de projet
Session 3 : Méthodes de réalisation d’un Projet

2 Questions sur le cours précédent
Régie? Assistance Technique? Forfait? Projet de développement? TMA? TRA? Infogérance?

3 Sommaire Les disciplines standard d’un projet
…, Spécifications, Conception, Développement, Recette, … Les méthodes « classiques et obsolètes » (V, W) Intérêts Difficultés à postériori Les méthodes « itératives » (RUP, 2TUP) Les méthodes Agile Fondements Scrum, XP, Lean Problématiques soulevées et difficultés rencontrées Exemples

4 Les disciplines d’un projet : vue d’ensemble
Rappel (session 1) : Le cycle de vie du projet ne concerne que la réalisation du produit informatique (en rouge) Exp. Besoins Spécifica-tions Concep-tion Dévelop-pement Recette Déploie-ment Exploita-tion Maîtrise d’ouvrage Domaine Production Projet domaine « Etudes »

5 Les disciplines d’un projet

6 Les disciplines d’un projet : spécifications
Spécifications = manière dont l’application va implémenter les besoins (étape précédente = expression de besoin) Définir le périmètre de l’application : au niveau fonctionnel : activités métier à informatiser (souvent sous UML) Navigation dans l’application Description détaillé des écrans : maquettes, règles de gestion écran Organisation des traitements Description détaillée des traitements « batch » Gestion des habilitations Paramétrage et contrôle des traitements au niveau technique : interfaces techniques du projet (normes, flux de données, interfaces matérielles (info indus, imprimantes, équipements mobiles, …) Livrables Spécifications Fonctionnelles Générales (SFG) - option Spécifications Fonctionnelles Générales (SFD) - obligatoire Spécifications Techniques Générales (STG) - option Spécifications Techniques Détaillées (STD) - option 6

7 Les disciplines d’un projet : Architecture Technique
Peut être optionnel (si l’architecture est déjà en place et maîtrisée) Nécessaire s’il faut industrialiser les développements sur de gros projets Tâches : Sélectionner avec soin les outils de développement Récupérer un framework existant ou le créer Mettre en place des fonctions standard pour les DAO Identifier et contourner les contraintes techniques (ex : projets J2EE : comportements différents selon les navigateurs) Réaliser des modèles d’implémentation qui seront largement utilisés, exemple : Écran de saisie, navigation standard dans l’écran Fenêtres standard d’erreurs et gestion standard des retours d’erreur Livrables Dossier d’architecture logicielle 7

8 Les disciplines d’un projet : Conception Technique
Conception Technique = Passerelle entre SFD et Code Point d’entrée des développeurs Tâches : Analyser les SFD et détecter d’éventuelles anomalies Identifier les composants à développer (classes, écrans, services métier, …) Formaliser la navigation entre les écrans Formaliser sous forme de pseudo code les traitements Livrables Dossier de Conception Technique 8

9 Les disciplines d’un projet : développement
Tâches Développement, dans le respect : Des spécifications De la conception applicative Tests usine Tests Unitaires Tests d’intégration Tests par mutation, tests par propriétés Tests fonctionnels, Tests IHM Tests de montée en charge, de robustesse, de sécurité, de scalabilité, …. Livrables Code source Exécutables, dans un package de livraison complet Documentation du code (si intérêt) Documentation utilisateur (dérive spécifications fonctionnelles) Documentation des tests 9

10 Les disciplines d’un projet : recette
But Passage de ses tests avant mise en production Plusieurs niveaux : VT : Validation technique (non contractuelle) : porte sur des sous ensembles de l’application VA : Vérification d’Aptitude (ou VABF : VA au Bon Fonctionnement) : opération contractuelle : vérifier que l’application finale respecte scrupuleusement les spécifications. Cette validation déclenche la mise en production VSP : Vérification sur Site Pilote (optionnel) : correction de bugs éventuels en production sur une extraction des sites client VSR : Vérification pour Service Régulier (contractuel) : correction de bugs en production sur tous les sites clients. Déclenche le début de la garantie contractuelle Livrables Bordereaux de livraison (chaque étape) PV (procès verbal) de recette (chaque étape) « sans réserves » « avec réserves » : bugs à corriger (mineurs) 10

11 Les méthodes « classiques et obsolètes »

12 Les méthodes « classiques et obsolètes » : Le Modèle en V
Part d’une conception globale et décompose le système en sous-ensembles, qui sont développés et testés séparément. On fait ensuite l’intégration et les tests du système complet. Il ne prévoit pas de retour arrière.

13 Les méthodes « classiques et obsolètes » : Le Modèle en W
Il part du modèle en V, en y ajoutant des phases d’élaboration de maquettes permettant de valider la conception. Il ne prévoit pas de retour arrière.

14 Les méthodes « classiques et obsolètes » : Synthèse
Intérêts : Permettent de connaître « dès le départ » l’ensemble des fonctionnalités d’une application  Rassurant Fournies une documentation avancée du logiciel Simple à appréhender  Rassurant pour beaucoup de décideurs Difficultés à postériori : Savez-vous aujourd’hui définir dans le détail et par avance la maison de vos rêves ??  Réponse oui en théorie, et NON dans la pratique : au mieux vous en aurez une idée plus ou moins précise (votre 3ème maison sera la bonne!) Il en va de même avec la conception d’une application. Le besoin réel se construit au fur et à mesure de son utilisation. Cela implique la plus part du temps : Une application mal pensée par rapport aux besoins réels des utilisateurs Un dépassement des délais et des coûts établis au départ du projet

15 Les méthodes « itératives »

16 Les méthodes « itératives » : Principes
L'idée est simple : pour modéliser (comprendre et représenter) un système complexe, il vaut mieux s'y prendre en plusieurs fois, en affinant son analyse par étapes. Notion « itérative » Modèle souple, proche des réalités de terrain, non figé comme les modèles précédents évitant les cloisonnements stricts entre analyse et réalisation par exemple (dans les modèles précédents, on considère qu'il faut terminer 100% des spécifications avant de démarrer le développement => faux en pratique) Lié à une démarche de conception UML (scénario nominal, scénarii alternatifs, scénarii d’erreurs)

17 Ce qu’il y a de nouveau avec les méthodes itératives :
Les méthodes « itératives » : Comparaison avec les méthodes « classiques » Ce qu’il y a de nouveau avec les méthodes itératives : Avant : approche en lots (qui sont des sous-ensembles fonctionnels), chaque lot étant implémenté complètement Méthode itérative : chaque livraison a pour périmètre l’application globale, mais en incluant des raffinements successifs

18 Les méthodes « itératives » : Un cycle itératif
Les quatre phases : phase d'initialisation (Inception) : mise en place et finalisaton du SDP (Software Development Plan, ou Plan de Développement Logiciel) en définissant les itérations nécessaires. Début de la modélisation métier et de la réalisation de prototypes ; phase d'élaboration (Elaboration) : fixe le maximum de règles fonctionnelles (uses cases) et réaliser des prototypes permettant de lever les risques et les maquettes permettant de modéliser l'IHM générale de l'application ainsi que la cinématique d'accès, phase de construction (Construction) : développement et tests (unitaires, intégration, pré-qualification au gré de l'avancement des itérations de cette phase), phase de transition (Transition) : préparation du déploiement et conduite du changement.

19 Les méthodes « itératives » : Implémentation RUP
RUP (Rational Unified Process) : les principes Vue « pragmatique » : les tâches sont continues dans le temps (en pratique, les spécifications ne sont jamais totalement figées) Opérations de modélisation et d’analyse Opérations de développement Opérations connexes Démarche itérative

20 Les méthodes « itératives » : Evolution de la couverture applicative
Illustration de la souplesse de la méthode : exemple type d’évolution de la couverture des spécifications sur le projet Même en phase de pré-déploiement, les modifications de détail des spécifications sont possibles On démarre les développements alors que les cas d’exception des spécifications ne sont même pas encore abordés. On démarre les maquettes et prototypes avec uniquement 30% des spécifications

21 Les méthodes « itératives » : RUP, Répartition de charges
La répartition des charges selon les phases du RUP : Etape Initialisation Elaboration Construction Transition Charge de travail ~5 % 20 % 65 % 10% Proportion de temps dans le projet 10 % 30 % 50 %

22 Les méthodes « itératives » : Prise en compte d’évolutions dans RUP
Chaque évolution majeure du logiciel est traitée comme un projet à part entière, et consiste donc à redémarrer un cycle. A un instant donné, les différentes évolutions du logiciel peuvent être dans des phases différentes

23 Les méthodes « itératives » : Le cycle en « Y » ou 2 TUP : 2 Tracks Unified Process
Description des processus métier Spécifications Techniques Spécifications Fonctionnelles Architecture Technique Charte graphique Architecture Logicielle Maquette / Prototype Conception itération 1 Réalisation itération 1 Tests Techniques itération 1 Tests Fonctionnels itération 1 Recette Technique itération 1 Recette Fonctionnelle itération 1 Itération 2 Itération n Recette Technique itération n Recette Fonctionnelle itération n Mise en production Déploiement

24 Les méthodes « Itératives » : Comment contractualiser?
(en général) Le client envoi son cahier des charges plus ou mois flou Le prestataire effectuer une réponse chiffrée l’engageant sur le respect de besoin et de son estimation de charge Problème ! Cahier des charges flou => Nombreuses discussions contractuelles (= pertes de temps pour le projet) => Nombreux avenants => Non maîtrise du budget du projet Une fois le client satisfait de la qualité, il paie son prestataire De plus en plus les clients mettent des pénalités sur : Les retards de livraison (1 jour de retard = euros) Sur la non qualité (1 anomalie bloquante = euros)

25 Les méthodes « itératives » : Synthèse
Intérêts : Permettent de connaître rapidement les principales fonctionnalités d’une application  Rassurant Autorise de revoir une partie du besoin en cours de route Fournies une documentation avancée du logiciel Simple à appréhender et à contractualiser  Rassurant pour beaucoup de décideurs Difficultés à postériori : Méthode encore trop orientée sur une définition figée du besoin utilisateur Ne traite pas les problématiques de qualité de code, de non régression Ces méthodes s’approchent d’un processus de création incrémental

26 Les méthodes « Agile »

27 Les méthodes Agiles : Le manifeste
Extrait du manifeste Agile : Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. Ces expériences nous ont amenés à valoriser : Les individus et leurs interactions plus que les processus et les outils Des logiciels opérationnels plus qu’une documentation exhaustive La collaboration avec les clients plus que la négociation contractuelle L’adaptation au changement plus que le suivi d’un plan Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.

28 Les méthodes Agiles : Le manifeste
Projet classique Processus et outils Documentation exhaustive Négociation contractuelle Suivi d’un plan Projet agile Individus et interactions Logiciel opérationnel Collaboration cliente Réactivité face au changement

29 Les méthodes Agiles : plusieurs solutions
Scrum eXtreme Programming Lean Devops Kanban Crystal clear FDD ASD, DSDM, …………

30 Agile : Focus sur SCRUM La méthode Scrum est un processus itératif représenté par le diagramme suivant :

31 Agile : Focus sur SCRUM Le « Backlog de produit » est constitué d’une liste de « User story », à savoir des cas d’utilisation simples et représentatifs. Il est modifié tout au long du projet par le directeur de produit. Chaque « User story » est orienté « fonctionnel » et est identifié de façon unique.

32 Agile : Focus sur SCRUM

33 Agile : Focus sur SCRUM Les rôles dans Scrum sont :
Le « Directeur du produit ou Product Owner» est le représentant des clients et utilisateurs. C’est lui qui défini le produit au travers du « Backlog » de produit. Le « ScrumMaster » est chargé de protéger l'équipe de tous les éléments perturbateurs extérieurs à l'équipe et de résoudre ses problèmes non technique. L’ « Equipe » ne comporte pas de rôle prédéfini et est autogérée. Elle s’adresse directement au directeur de produit.

34 Agile : Focus sur SCRUM Le « Backlog de sprint » est réalisé à chaque début de sprint. Il contient l’ensemble des « User story » à réaliser pour celui ci. Le « Backlog de sprint » n’évolue jamais. La mêlée quotidienne (ou Daily Scrum) est effectuée chaque matin afin de vérifier qu’aucun élément ne perturbe le développement. Il s’agît d’un Stand-up Meeting (on reste debout pour que la réunion ne s’éternise pas…) Point court de 10 à 15min Exposer l’avancement de chacun et les problèmes rencontrés

35 Agile : Focus sur XP Méthode résolument incrémentale et focalisée sur la programmation qui met en œuvre les pratiques suivantes : TDD (Test Driven Developement) Refactoring Intégration Continue Propriété collective Normes de développement Pair programming Rythme soutenable Approche très complémentaire avec Scrum qui met en place l’organisation projet Scrum et XP se sont mutuellement inspirées 35

36 Agile : Focus sur Lean http://blog.octo.com/qu-est-ce-que-le-lean
Ensemble de principes et de pratiques issus de Toyota : Respect des gens : Le travail doit être motivant, épanouissant, inspirant Le personnel doit être formé, encouragé et responsabilisé Eliminer le gaspillage : Surproduction, Délai (exemple : temps d’organisation d’une réunion), Stock, Transport, mouvement inutile, processus inutile et défauts Amélioration continue : Innover : faire quelque chose de nouveau Imiter : reprendre quelque chose qui a déjà marché ailleurs Améliorer en continu pas à pas : partir de la situation actuelle et la changer petit à petit en s’assurant que chaque changement est une amélioration 36

37 Agile : Focus sur Lean Ensemble de principes et de pratiques issus de Toyota : Management visuel : Consiste à rendre visible les écarts par rapport au standard. Comme cela il n’est pas besoin d’être courageux pour parler de ces écarts, ils sont traités tout de suite soit en renforçant la formation aux bonnes pratiques, soit en ajustant le standard. Gemba : Avoir conscience du lieu où la valeur ajoutée est crée. Kanban : Méthode de planification de production d’un flux tendu Attention : Comme tout principe (méthode, dogme, religion, …), lorsque celui-ci est appliqué de manière excessive il devient néfaste! 37

38 Les méthodes « Agiles » : Comment contractualiser?
Rappel sur un contrat forfait classique : Le client porte le risque du besoin, tant dis que le fournisseur porte le risque du produit. Du fait qu’en ingénierie logicielle, le besoin évolue très fréquemment, mais que le contrat lui ne bouge pas, le client tente souvent de faire porter le risque du besoin sur le prestataire, ce qui donne souvent lieu à de nombreuses négociations contractuelles. Client Fournisseur

39 Les méthodes « Agiles » : Comment contractualiser?
Solution pour contractualiser en agile : Engagement de moyen (régie) sur une équipe complète (Scrum Master Architecte, Développeur) Les itérations étant courtes, en cas de non satisfaction de la part du client, celui-ci pourra remercier rapidement l’équipe constituée. Forfait basé sur une métrique de productivité 1ères itérations facturées au temps passé pour mesurer la vélocité de l’équipe L’équipe est capable de produire tant de points (si l’on est en SCRUM) Ensuite l’engagement forfaitaire porte sur un nombre d’itérations devant respecter un certaine vélocité Le besoin fonctionnel peut évoluer en cours, à condition que la vélocité des itérations à produire reste la même. D’autres formes contractuelles existent : Target Coast, Target Delay, Partage de profit Exemple de contrat Agile proposé par Xebia :

40 Les méthodes « Agiles » : Synthèse
Intérêts : Favorise clairement la productivité Permet aux utilisateurs de mieux appréhender leurs besoins Difficultés à postériori : Nécessite une forte implication du client Conceptuellement plus complexe à appréhender (pour le client et pour les prestataires) Nécessite des collaborateurs très compétents, capables d’être performants aussi bien sur le fonctionnel que sur le technique Nécessité absolue de mettre en œuvre des outils de contrôle de qualité et de non régression Méthodes (très) difficiles à mettre en œuvre sur des gros projets (30, 40, … ETP) La contractualisation est rendue plus difficile

41 Management et suivi de la prestation Maintenance Opérationnelle
Cycle de vie des TMA TMA Le Cycle de vie peut être spécifique à chaque métier Tierce Maintenance Applicative (exemple => ) Infogérance Etc. Management et suivi de la prestation Réversibilité Prise en compte Acquisition des connaissances Organisation Maintenance en mode assisté Maintenance Opérationnelle Maintenance en mode autonome Réalisation des services de maintenance Projets d’évolution Fin de TMA Recette Réversibilité Montée en charge équipe Client Transfert de l’activité O r g a n i s a ti o n Lancement Recette

42 Les TMA : Comment contractualiser?
(en général) La phase de prise en compte est forfaitaire Il arrive qu’elle soit offerte au client en tant que geste commercial En phase opérationnelle : Les activités de MCO, Support sont forfaitaires, mais basées sur un volume d’activité déjà constaté ou estimé (nombre d’anomalies, nombre d’incidents, …) Les évolutions sont forfaitaires et utilisent des Unités d’Œuvre pour les valoriser La phase de réversibilité est forfaitaire

43 En synthèse

44 Quelle méthode pour quel cas ?
Comment savoir quelle méthode appliquer ? Client CQFD ! Volontaire Peu impliqué Expérimenté « Votre » méthode Type de projet Technique ERP/Décisionnel Dév. Spécifique C/S Dév. Spécifique J2EE Taille du projet Petit (<500 j/h) Moyen Important (>5000 j/h) Risque Normal Élevé Très élevé

45 Prochaines sessions Session 4 : Découpage d’un projet
TP 1 : Outil de suivi d’un projet (L. Descamps) Session 5 : Estimation des charges Session 6 : Outils de planification Session 7 : Gestion des ressources d’un projet Session 8 : Suivi d’un projet TP2 : Suivi pratique d’un projet (L. Descamps) Session 9 : Coûts d’un projet / Gestion des risques Session 10 : Assurance Qualité Session 11 : Recette et AMOA Session 12 : Conduite du changement Session 13 : Bilan de projet Examen, correction