Les méthodes «classiques»

18 Plan 1 Les cycles de vie de projet 2 Des méthodologies classiques 3 Des méthodologies agiles 4 Des activités communes 19 Les méthodes «classiques» Principales méthodes de développement de systèmes d information des 40 dernières années ont reposé sur un découpage temporel de référence «plutôt séquentiel» La plus répandues dans les entreprises MERISE : Méthode (1974 1978) initiée par les français Hubert Tardieu, Jean-Louis Lemoigne travaillant sur des projets au ministère de l industrie et dans les services de l équipement, relayés par des travaux de l université d Aix- Marseille et de l INRIA. Méthode d analyse et de conception Les fameux MCD! C est aussi une méthode de gestion de projets très utilisée dans les années 70-80 è 8 ETAPES 1

20 Les méthodes «classiques» 1 - Le schéma directeur (SD) Définir le scénario d évolution du patrimoine informatique, sous l un ou l autre de ces 3 angles Évolution de l architecture technique (matériels, réseaux) Évolution de l architecture applicative Evolution de la fonction informatique (méthodes, normes, outils) Livrables Photographie de la situation existante : cartographie des domaines applicatifs, modélisation des principaux concepts Diagnostic Définition des objectifs et priorités par domaine et par application Orientations d évolutions choisies, à partir de quelques scénarii. 21 Les méthodes «classiques» 2 - L étude préalable (EP) Faire les choix structurants pour la future application : évaluer l adéquation de la solution envisagée, évaluer l investissement Fournir une base de référence pour la suite du projet Livrables : Rapport d étude préalable, qui pourra servir de cahier des charges pour l étude détaillée. 2

22 Les méthodes «classiques» 3 - L étude détaillée (ED) Concevoir et décrire de façon exhaustive la solution sur tout le champ de l étude Livrables Spécifications de la solution, validées par les futurs utilisateurs et les informaticiens. Toute la vision externe du système (IHM : maquettes d écrans), les traitements, les sorties (maquettes d états). Représente le cahier des charges pour la réalisation 4 - L étude technique (ET) Optimiser les structures physiques de données et construire les traitements en anticipant la réutilisation de code Livrables : Dossiers programmes Normes techniques Structure physique des données 23 Les méthodes «classiques» 5 - La réalisation (REAL) ou «Développement» Produire un logiciel testé Programmation Élaboration de jeux d essais Test Recette provisoire Livrables Logiciel PV de recette (la recette conditionne en général le paiement, dans une relation contractuelle avec un fournisseur). 3

24 Les méthodes «classiques» 6 - La mise en œuvre (MEO) Préparer le démarrage effectif de la nouvelle application Paramétrage Reprise ou alimentation en données Développement des interfaces Formation des utilisateurs Installation d environnement d exploitation Livrables Un logiciel installé en production, prêt à être exploité Le plan de formation et les moyens associé 25 Les méthodes «classiques» 7 - La qualification (QUALIF) Réaliser des tests dans l environnement opérationnel et tirer un bilan du système installé. Livrables : Bilan des tests 8 - La maintenance Corriger et adapter le logiciel aux évolutions de l entreprise Livrables : patchs correctifs ou évolutifs 4

26 Les méthodes «classiques» Autres méthodes classiques MCP : Méthode de Conduite de Projet informatique créée par GEDIN en 1975, modifiée en 1986 en s'inspirant de MERISE La norme AFNOR Z67-101 (1984) reprend dans ses «recommandations pour la conduite de projets informatiques» les éléments des méthodes MERISE / MCP. NORME AFNOR Z67-101 Etude préalable Exploration Conception Appréciation Conception détaillée Réalisation Mise en œuvre Evaluation MERISE Schéma directeur Etude préalable Observation Conception/organisation Appréciation Etude détaillée Etude technique Réalisation Mise en œuvre Qualification 27 Plan 1 Les cycles de vie de projet 2 Des méthodologies classiques 3 Des méthodologies agiles 4 Des activités communes 5

28 Les méthodes agiles Définition et principes Définitions «Une méthode agile est une approche itérative et incrémentale, qui est menée dans un esprit collaboratif, avec juste ce qu il faut de formalisme. Elle génère un produit de haute qualité tout en prenant en compte l évolution des besoins des clients.» [Messager, 2013] «Le terme «Agile» définit une approche de gestion de projet qui prend le contre-pied des approches traditionnelles prédictives et séquentielles de type cycle en V ou waterfall (en cascade).» www.agiliste.fr «Les méthodes agiles sont des groupes de pratiques de projets de développement en informatique (conception de logiciel), pouvant s'appliquer à divers types de projets. Elles ont pour dénominateur commun l'agile Manifesto....» Wikipédia 29 Les méthodes agiles Définition et principe Construites sur les failles (avérées ou non) de l approche en cascade Rigidité de l approche cascade car pas de retours arrière possibles Peu de marge laissé au client pour préciser et faire évoluer ses attentes Effet tunnel (boite noire) : Des besoins è??? è Un produit Une mauvaise communication Levée tardive des facteurs de risques Tests d intégrité ou de performance à la fin par exemple Documentation pléthorique Pour se prémunir contre les risques, on documente tout, car une fois le codage commencé, c est «irréversible» 6

30 Les méthodes agiles Définition et principe Une approche itérative et incrémentale Découpage du projet en itérations = étapes d une durée de quelques semaines Au cours d une itération une version minimale du produit attendu est développée puis soumise, dans sa version intermédiaire, au client pour validation Les fonctionnalités sont intégrées au fur et à mesure du cycle de vie è mode incrémental Le système s enrichit progressivement pour atteindre le niveau de satisfaction et de qualité requis. Chaque itération est un mini-projet qui comporte les activités d analyse, de conception, de codage, de tests et de gestion de projet. A l issue de chaque itération, on a un sous-ensemble opérationnel du système cible Au terme de la dernière itération, la version finale du produit Les itérations se succèdent et ne peuvent être parallélisées, leur date de fin est généralement fixe Mobiliser les efforts sur des objectifs clairs à courts terme Si les objectifs ne sont pas atteints, les enseignements en sont tirés lors du bilan de l itération pour corriger les conditions de l itération suivante 31 Les méthodes agiles Définition et principe Un esprit collaboratif Placer les individus et leurs interactions au centre du dispositif Privilégier la communication entre l équipe mais aussi avec les interlocuteurs tels que client ou utilisateur Partage d information, échange de points de vue différents ou complémentaires, entraide et non concurrences Un formalisme léger Seulement quelque livrables à produire en plus de l essentiel (ie les versions intermédiaires de produits) Quelques rôles, quelques étapes, quelques réunions et la démarche est formalisée Ne pas doter l équipe d outils complexes auxquels elle devra s adapter et se former è approche adaptative 7

32 Les méthodes agiles Définition et principe Un produit de haute qualité Si l on considère que le niveau de qualité minimal d un produit est sa capacité à satisfaire le client, tant sur le plan fonctionnel que sur celui des exigences de performance, de facilité d utilisation ou d évolutivité Sélection des fonctionnalités à implémenter en priorité Feedback permanent recueilli du client Campagnes de tests et contrôle qualité à chaque itération Nettoyage régulier (quotidien? ) du code et respect de normes de codage partagées Adoption d un approche adaptative Comprendre autrement, en image : Comparaison approche prédictive et agile : http://youtu.be/adeohwgrysi https://youtu.be/vis8cwmm_ww 33 Les méthodes agiles Origines et valeurs En 2001, 17 experts en développement logiciel se sont réunis pour échanger et trouver un socle commun de valeurs et de bonnes pratiques è «Manifeste pour le développement logiciel agile» è Création de l Agile Alliance (www.agilealliance.org) chargée de promouvoir l agilité dans les organisations et d apporter du soutien aux équipes qui veulent démarrer un projet agile Les quatre valeurs du Manifeste Les individus et leurs interactions avant les processus et les outils Des fonctionnalités opérationnelles avant la documentation Collaboration avec le client plutôt que contractualisation des relations Acceptation du changement plutôt que conformité aux plans è cela ne signifie pas qu aucun processus n est défini, qu on ne se dote d aucun outil J ; des plans et une documentation, plus réduits, sont produits 8

34 Les méthodes agiles Origines et valeurs Origine et valeurs des méthodes agiles (suite) En 2005 a été publié la «déclaration d interdépendance» Signée par les acteurs majeurs de l Agile Alliance 6 concepts doivent être considérés de façon interdépendante : valeur, incertitude, client, individus, équipe, contexte «Vous ne pouvez créer de la valeur si vous ne collaborez pas avec un client, qui précisément, définit ce qu est sa valeur; vous ne pouvez attendre d une équipe qu elle soit performante si vous ne reconnaissez pas la contribution des individus qui la composent; vous ne pouvez maîtriser l incertitude si vous ne prenez pas en considération la spécificité du contexte.» 35 Les méthodes agiles Origines et valeurs 13 principes des méthodes agiles Manifeste agile www.agilemanifesto.org 1 - Notre priorité est de satisfaire le client en lui livrant très tôt et régulièrement des versions opérationnelles de l application, source de valeur Grace au développement itératif, chaque livraison intermédiaire donne lieu à une validation par le client; son feedback est essentiel pour garantir la conformité de la livraison avec ses attentes, pour prendre en compte ses remarques et (re)prioriser 2 Accepter le changement dans les exigences, même tard dans le cycle de vie, pour garantir la compétitivité du client Cet état d esprit caractérise une équipe agile qui démontre ainsi sa capacité à comprendre et apprendre comment satisfaire encore mieux la demande 3 Livrer le plus souvent possible des versions opérationnelles de l application, à une fréquence allant de deux semaines à deux mois Une version intermédiaire du produit final, visible et testable, satisfait davantage le client qu une documentation à valider. Il a, de ce fait, la preuve tangible que le projet avance et peut exprimer son point de vue sur le résultat présenté 4 Client et développeurs doivent coopérer quotidiennement tout au long du projet Les relations conflictuelles ne font pas partie de l esprit agile, on préférera des relations collaboratives et de partenariat basées sur la confiance et le consensus. Le client (ou son représentant) est accessible et disponible, totalement impliqué dans toutes les phases du projet. 9

36 Les méthodes agiles Origines et valeurs 5 Construire des projets autour d individus motivés. Leur donner l environnement et le support dont ils ont besoin et leur faire confiance pour remplir leur mission Le facteur clé de réussite d un projet est l équipe. Tout obstacle à son bon fonctionnement doit être levé; un changement, s il s avère nécessaire sera apporté aux processus, aux outils, à l environnement, à la composition de l équipe. 6 - La méthode la plus efficace de communiquer des informations à une équipe et au sein de celle-ci reste la conversation en face-à-face Par défaut, on privilégie l échange oral à l écrit, pour lever toute ambiguïté et favoriser la rapidité de compréhension. Tout ne peut être formalisé par écrit, notamment la «connaissance tacite», c est à dire l information «informelle», la culture de projet, détenues par chacun au sein d une équipe. 7 Le fonctionnement de l application est le premier indicateur de l avancement du projet Il n existe pas d autre indicateur plus pertinent que le pourcentage ou le nombre d exigences satisfaites; on ne mesure pas un projet à la quantité de documents produits ou au nombre de lignes de codes, non significatifs pour le client. 8 Les méthodes agiles recommandent que le projet avance à un rythme soutenable La qualité du travail fourni dépend du rythme de travail qui doit être adapté en fonction des spécificités du projet. Le rythme doit être soutenu et soutenable sur la durée du projet. 37 Les méthodes agiles Origines et valeurs 9 Sponsors, développeurs et utilisateurs devraient pouvoir maintenir un rythme constant indéfiniment Ce rythme est à déterminer par l ensemble des membres de l équipe et par le client en fonction de la productivité de l équipe et des priorités du client. Mais travailler en heures supplémentaires, surtout pour corriger des bogues ou des régressions, n apporte aucune valeur ajoutée. 10 Porter une attention continue à l excellence technique et à la conception améliore l agilité Maintenir un code propre, évolutif et performant est un objectif permanent de l équipe; il ne s agit pas de produire du code non exploitable par les autres, ni du «jetable». De plus, cela évité surtout d enliser les développements ultérieurs avec des modifications cassant un développement fragile, nécessitant des interventions à des endroits variés du code. 11 La simplicité art de maximiser la quantité de travail non fait est essentielle La simplicité garantit l évolutivité du système. La complexité, au contraire, coûte davantage et rend plus difficile les évolutions inhérentes au développement incrémental. La conception ne doit comporter que des éléments utiles. 12 Les meilleurs architectures, spécifications et conceptions sont le fruit d équipes qui s auto-organisent Le chef de projet agile n est plus celui qui attribue des tâches. L équipe, elle-même, se responsabilise et définit ses travaux à réaliser, le partage des tâches s effectuant sur la base du volontariat. 13 A intervalles réguliers, l ensemble de l équipe s interroge sur la manière de devenir encore plus efficace, puis ajuste son comportement en conséquence. L environnement d un projet n est pas constant; l équipe agile, qui en a conscience, s interroge en permanence sur la façon d améliorer son fonctionnement afin de s adapter aux nouvelles conditions. C aussi l acceptation du changement. 10

38 Les méthodes agiles Origines et valeurs Comprendre un peu plus en image avec une vidéo qui illustre la mise en action des méthodes agiles : http://youtu.be/lqficcsknis 39 3 Principales méthodes Les méthodes les plus connues (et reconnues) s appuient sur les principes du manifeste Tronc commun pratique Se différencient par leurs degrés de formalisme Poids de la méthodologie dans la documentation, étapes formelles, revues d itération, rythme du projet ou durée des itérations Principales méthodes agiles présentées dans ce chapitre RAD : Rapid Application Development ASD : Adaptive Software Development DSDM : Dynamic Software Development Method XP : extreme Programming Processus Unifié (PU) ou Unified Porcessing (UP) Scrum 11

40 Les méthodes agiles Principales méthodes Le cycle RAD (Rapid Application Development) Objectif : Développement rapide dans des délais réduits. Participation organisée et contrôlée des utilisateurs. Découpage temporel introduisant systématiquement une session participative entre l équipe projet et le groupe d utilisateurs au milieu de chaque phase Le cycle global conjugue modèles en cascade et en spirale. L étape construction se compose d un nombre variable de cycles de prototypage, mais strictement dans un temps limité (time box) à ne pas dépasser. 41 Les méthodes agiles Principales méthodes Le cycle ASD (Adaptative Software Development) Objectif : Approche collaborative pour gérer les projets complexes Modèle proposant une série de cycles en 3 volets : Spéculation : initier le projet, déterminer sa durée, le nombre d itérations (4 à 8 semaines par itération), affecter un objectif à chaque itération, dresser la liste des tâches. Collaboration : livraison des composants, communication forte et assez informelle Apprentissage : contrôle qualité, suivi et bilan d avancement, communication forte et assez informelle Caractéristiques : Focaliser sur l objectif ; se baser sur des composants; itérer ; time boxing ; pilotage par les risques ; accepter le changement. 12

42 Les méthodes agiles Principales méthodes DSDM (Dynamic Software Devlopment Method) Objectif : utilisation de RAD de façon structurée et indépendante (Grande Bretagne) Modèle temporel itératif : Etude de faisabilité : définition du problème, étude faisabilité technique, méthodologique et budgétaire. Etude du business : analyse des processus métier, hiérarchisation des besoins en ateliers avec les utilisateurs ; définition de l architecture globale et du plan global de prototypage. Modèle fonctionnel itératif : description des besoins en détail, identification des modules logiciels constituant un prototype fonctionnel Conception et développements itératifs : fourniture d un système conforme aux besoins définis. Mise en œuvre : livraison, prise en main pour test ; bilan. Caractéristiques : implication active des utilisateurs, livraisons fréquentes, développement itératif et incrémental, intégration des tests dans tout le cycle de vie. Modèle fonctionnel itératif Etude de faisabilité Etude du business Conception et développements itératifs Mise en oeuvre 43 Les méthodes agiles Principales méthodes XP (extreme Programming) Objectif : approche systématique (extrême) des tests, de l implication des utilisateurs, des livraisons fréquentes. Le développement au cœur du projet. Pratiques de programmation : Conception simple : concision, modularité, lisibilité ; faciliter la maintenance Développement piloté par les tests unitaires Tests de recette Remaniement continu ou refactorisation du code : rendre le code le plus «propre» possible Programmation en binôme Règles de codage Propriété collective du code Métaphore : afin de faciliter échanges entre techniciens et fonctionnels Intégration continue Client sur site Séances de planification Livraisons fréquentes Rythme soutenable par les équipes 13

44 Les méthodes agiles Principales méthodes Processus Unifié (PU) ou Unified Process (UP) Origine : Collaboration entre Ivar Jacobson, Grady Booch, et James Rumbaugh, tous trois à l origine des travaux sur l orienté objet et du langage de modélisation UML But : standardiser les bonnes pratiques en ingénierie logicielle Démarche itérative et incrémentale s'appuyant sur UML UML est un langage de modélisation (spécification, visualisation, construction et documentation) d un système logiciel Le problème est qu ont ne sait pas forcément bien comment mettre tous ces modèles en scènes ni à quels moments du cycle de vie d un projet informatique è «la méthode n est pas livrée avec la boite à outil» La méthodes élaborée = le Processus Unifié A voir comme le processus de développement logiciel, qui permet de répondre aux questions : qui? Quoi? Quand et Comment? 45 Les méthodes agiles Principales méthodes Utilise la modélisation UML pour la description de l'architecture du logiciel (fonctionnelle, logicielle et physique) la mise au point de cas d'utilisation permettant de décrire les besoins et exigences des utilisateurs 4 phases principales, qui se décomposent en itérations Inception : obtenir un consensus de l ensemble des parties prenantes sur la vision ou la portée du projet, le périmètre et l estimation globale Elaboration : établir et valider l architecture de référence, lever les principaux risques ainsi que spécifier en détail les exigences; c est une phase exploratoire Construction : livrer une première version opérationnelle du système, accompagnée de sa documentation Transition : déployer et mettre en production la version finale de l application, testée par les utilisateurs Chaque phase se compose d itérations Inception : itération 0 ou itération(s) préliminaire(s) Elaboration : itération 1 et 2 Construction : autant d itérations que nécessaires Transition : autant d itérations que nécessaires 14

46 Les méthodes agiles Principales méthodes Chaque itération s appuie sur 9 disciplines (ou processus) Décrites par des activités, des rôles et des outils 47 Les méthodes agiles Principales méthodes Dans chaque itération, et selon les phases et les processus, les diagrammes et modèles UML appropriés sont élaborés PU est centré autour des Cas d Utilisation (UML) Orienté Architecture Pour en savoir davantage sur le PU, un cours plus approfondi http://laurent.henocque.com/oldsite/doc/processus%20unifie%20rational %20Henocque%20Esil%20Info%202006.pdf Livres de référence sur le Processus Unifié, en français è disponible à la BU UPJV 15

48 Les méthodes agiles Principales méthodes SCRUM Objectif : Travailler en équipes pluridisciplinaires intégrées et soudées dans une stratégie flexible Principe des petits ajustements fréquents Caractéristiques ou piliers de SCRUM : Visibilité : une fonctionnalité implémentée est considérée comme terminée lorsque tous les acteurs s entendent sur les modalités d évaluation des résultats tangibles. Scrum met l'accent sur le fait d'avoir un langage commun entre l'équipe et le management. Ce langage commun doit permettre à tout observateur d'obtenir rapidement une bonne compréhension du projet. Inspection : vérifier les écarts par rapport à l objectif initial ; nombreux points de contrôle. Adaptation : en cas de constat d écarts, ajustements décidés immédiatement. Si une dérive est constatée pendant l'inspection, le processus doit alors être adapté. Scrum fournit des rituels, durant lesquels cette adaptation est possible. Il s'agit de la réunion de planification de sprint, de la mêlée quotidienne, de la revue de sprint ainsi que de la rétrospective de sprint. SCRUM en images : Explaining Scrum in Less than 120 seconds : http://youtu.be/wxiue-1ujcm 49 Les méthodes agiles Principales méthodes Modèle temporel itératif, reposant sur des sprints de 1 à 4 semaines : En amont du sprint : définition des Fonctionnalités attendues au cours du sprint (Sprint Backlog) en fonction des priorités du client (Customer Priority) et des fonctionnalités du produit dans son ensemble (Product Backlog) Sprint Backlog = Fonctionnalités définies pour 1 Sprint Sprint de 1 à 4 semaines pour produire ces fonctionnalités A la fin du Sprint : un nouvel incrément du produit 16

50 Les méthodes agiles Principales méthodes Organisation de l équipe pour 1 sprint Sprint planning meeting : au début pour définir et présenter le Sprint Backlog c est à dire sélection des exigences prioritaires pour le client Daily Scrum Meeting : Réunion d avancement quotidienne (le Scrum Manager, avec toute l équipe). Sprint Review Meeting : démonstration des derniers développements faite au client Rétrospective : revue de fin de Sprint, bilan qualitatif interne à l équipe sur le fonctionnement de l équipe. Rôles dans SCRUM Le Product Owner Représente des clients et des utilisateurs. Son objectif est de maximiser la valeur du produit développé. Explicite les éléments (Items) du Product Backlog. Ses composantes sont exprimées sous forme d'histoires Utilisateur (User Stories). Rédige les spécifications et les cas de tests Définit l ordre de priorité des développement, notamment les objectifs de chaque sprint Doit avoir le niveau de prise de décision nécessaire et doit être disponible Le Scrum Master Responsable de la méthode, et rien d autre!!! Rôle de facilitateur et son objectif est maximiser la valeur produite par l'équipe dans le respect des règles de la méthode Scrum Dans certains cas, il peut être assimilé à un coach. Le développeur Tous les autres! Il n y a pas de rôles prédéfinis puisque l équipe est «auto-gérée» et autonome 51 Les méthodes agiles Principales méthodes Avantages de Scrum Entièrement développé et testé pour de courtes itérations Simplicité des processus Organisation personnelle Responsabilisation de chacun Cohésion d équipe Combinaison possible avec XP Inconvénients de Scrum Peu, voire pas, de documentation écrite Violation de responsabilité (pas de hiérarchie) Pratiques assez nouvelles donc conduite du changement à prévoir Très difficile à mettre en place avec une équipe virtuelle Disponibilité accrue du client Livre DUNOD sur SCRUM, disponible à la BU UPJV Site web de la méthode Scrum www.scrum.org Téléchargez le Guide Scrum en français https://www.scrum.org/portals/0/documents/scrum%20guides/2013/scrum-guide- FR.pdf#zoom=100 17

52 Les méthodes agiles Bilan PU et RAD ne sont pas classés par tout le monde comme étant des méthodes agiles Certains concepts relèvent de l agilité, Le management de projet et leur application peuvent rendre leur utilisation «agile» ou pas Les méthodes agiles, au delà de démarches et de formalisme, véhiculent une certaine philosophie et un certain «art» de la gestion de projet On adhère ou on adhère pas Si l on adhère pas à l ensemble des préconisations du Manifeste, possibles échecs des projets Discours un peu chronique qui dirait que les «bons» sont du coté agile et les «méchants» sont du coté waterfall Un peu manichéen comme vision du monde Le principe est peut-être de garder un esprit critique vis à vis de tout ceci et se faire sa propre idée 53 Les méthodes agiles Bilan Attention au modèle avalanche! «Anti-modèle» de gestion de projet informatique Combinaison d'un cycle de vie de type cascade avec des méthodologies Agiles Ce qui surviendrait lorsqu un chef de projet tente d'appliquer des techniques agiles à un projet, quand tout ce qu il sait gérer ou a appris s apparente à un cycle de vie séquentiel Bien souvent, au lieu de découper le projet en plusieurs unités qui vont subir les différentes phases de développement, l'ensemble du projet suit toutes les phases de développement en même temps. Conséquence probables è confusion de masse, gaspillage d'efforts, voir produit ne pouvant pas répondre aux spécifications du cahier des charges 18

54 Les méthodes agiles Bilan http://www.versionone.com/state-of-agile-survey-results/ Sondage Version One 2012 Scrum serait la méthode agile la plus populaire (54% des usages de méthodes agiles se seraient orientés vers Scrum suivis à 11% par des usagers d une solution hybride Scrum/XP) 83% des personnes interrogées envisagent d utiliser une méthode agile (contre 53% l année précédente) Causes énoncées des échecs de projets agiles 12% pour cause de non alignement entre la philosophie ou la culture de l entreprise avec les valeurs agiles 11% pour des problèmes organisationnels ou de communication 11% suite à des pressions externes pour revenir à un cycle de vie plus séquentiel 18% affirment n avoir connu aucun échec de projet avec les méthodes agiles 55 Les méthodes agiles Bilan Autre vidéo à regarder sur Youtube : Conférence de Véronique Messager à l AgileTour2011 «Améliorez l efficacité de vos cérémonies agiles» : http://youtu.be/xvjz0vib78a A regarder chez vous car conférence de 50 min 19

56 Plan 1 Les cycles de vie de projet 2 Des méthodologies classiques 3 Des méthodes agiles 4 Des activités communes 57 4 Les activités communes Des modèles spécifiques dans chaque organisation Adaptation des modèles courant aux spécificités de l organisation Emploi d un vocabulaire «maison» propre : retrouver les concepts sous-jacents Beaucoup de cycles de vie sont le fruit du mélange de modèles standards Les modèles les mieux adaptés à un projet donné tiennent compte : De la taille et de la durée du projet De la maturité du besoin exprimé De l appel ou non à la sous-traitance De la complexité technique du projet De l utilisation ou non d un progiciel De la culture (latine, anglo-saxone, etc) du projet Du caractère international (multi-culturel) du projet De l expérience et du nombre de projets annuellement réalisés par l organisation Du niveau de maturité (éventuelles certifications, ex: CMMI niv3) des processus d ingénierie de l entreprise. Des techniques / outils de développement utilisés en réalisation 20

58 4 Les activités communes Expression du besoin et définition du périmètre è MOA Le besoin Est extérieur au produit Est du domaine de l utilisateur Les caractéristiques fonctionnelles Sont du domaine du produit Une fonction est l action d un produit (ou d un constituant du produit) exprimée en terme de finalité La finalité est la satisfaction du besoin ou le respect d une contrainte à remplir L analyse fonctionnelle externe concerne Tous les aspects relatifs à l environnement du produit Ce qui contraint le fonctionnement L analyse fonctionnelle interne concerne Les relations fonctionnelles entre les diverses parties internes du produit. A l issue de cette phase on considère la solution (ex : le logiciel) comme une boîte noire dont on ne connaît que les entrées et les sorties. Livrable en sortie : le cahier des charges 59 4 Les activités communes L analyse des besoin et conception è MOE Objectif : Définir de façon très précise les fonctions et services rendus et l architecture du logiciel Démontrer (tracer) la couverture des exigences, des besoins par les éléments conçus Activités Les choix techniques sont effectués Spécifications des fonctions et des services Regroupement en modules des éléments à produire Identification des algorithmes à mettre en œuvre Définition de l enchaînement des fonctions/services et les éléments déclencheurs Livrables : Dossiers de conception/spécification générale et détaillée, dossiers d architecture fonctionnelle, technique, spécification d interfaces, de traitement et d organisation des données 21

60 4 Les activités communes Réalisation Développement Construction : programmation, paramétrage, tests unitaires è MOE Objectif Développer, modifier et paramétrer le logiciel Procéder pour chaque module/composant aux tests unitaires Activités Etude algorithmique Codage du logiciel Relecture croisée du code Paramétrage Tests unitaires Livrables Logiciel : code source, procédure de génération, logiciel installable et exécutable, kit d installation etc Fiches de relecture de code Bilan des tests unitaires paramétrage 61 4 Les activités communes Qualification Tests Intégration Validation Objectif S assurer que le produit livré est adapté à son usage de destination et satisfait les exigences, les besoins vérifiables Activités Elaborer une stratégie de test Rédiger des dossiers de test Préparer les jeux de données de test Installer le logiciel, le paramétrage Exécuter les tests et signaler les écarts (anomalies, écarts par rapport aux besoins) Tracer les résultats obtenus Faire corriger les anomalies et faire livrer les correctifs Livrables Stratégie de test Dossier/cahiers de tests (Scénarios, fiches de test, description des jeux de données) Bilan des tests Procès Verbal des anomalies 22

62 4 Les activités communes Mise en production Site Pilote ou key-users è MOA Objectif Installer le logiciel en production (sur environnement technique, matériel, logiciel d infrastructure cible) Vérifier que l utilisation de l applicatif répond aux exigences définies et aux besoins utilisateurs et que l organisation pressentie pour le déploiement généralisé est opérationnelle Activités Préparation des sites pilotes Installation du logiciel à paramétrer Planification des activités pilotes Déroulement de la phase pilote Formation des utilisateurs Correction des anomalies et livraison des correctifs Livrables Documents de formation utilisateurs Bilan d installation Compte-rendu / bilan du pilote Remontée d incidents / anomalies Feu vert pour généralisation 63 4 Les activités communes Généralisation Vérifications de Service Régulier è MOA Objectif Utiliser en mode nominal, par toute la population d utilisateurs concernée, l ensemble des fonctions du logiciels Surveiller pendant une période définie l utilisation normale de la solution Activités Compléter les installations ou ouvrir les droits d accès à tous les utilisateurs Surveiller le service régulier Faire corriger les anomalies et faire livrer les correctifs Livrables : Compte-rendu / bilan de la période Remontée d incidents / anomalies Feu vert pour fin de surveillance spécifique. 23

64 4 Les activités communes Gérer le projet, et aussi accompagner le changement La réussite d un projet informatique se mesure notamment par l adhésion des utilisateurs finaux Ces derniers doivent comprendre et adhérer, puis au final utiliser! è Résistance au changement Lorsque le projet n est pas motivé par une demande qui émane d eux C est nul! Encore un truc qui a été pondu par les bureaucrates ou les informaticiens qui connaissent même pas notre boulot! Lorsque le projet va remettre en cause leurs procédures de travail Je vais perdre un temps fou maintenant avec ce nouveau machin alors qu avant ça m allait très bien L informatique et moi ça fait deux, je vais encore ramer. J ai mis un an à me faire à la procédure (ou à l outil) actuelle et je vais devoir tout réapprendre. Peur de l incertitude que va engendrer ce nouvel outil On sait ce qu on perd on ne sait pas ce qu on gagne! C était peut-être pas parfait, mais on a l habitude et ça fonctionnait pas si mal. Manque de visibilité sur l intérêt, le gain Qu est-ce que j y gagne finalement? Inquiétudes sur le sens caché de l outil Est-ce qu ils font pas ça finalement pour mieux nous contrôler! 65 4 Les activités communes Quelques clés pour la conduite du changement Analyser en amont les changements, étudier l impact Etudier qui sera impacté par ces changements et à quel degré Etablir des utilisateurs clés, premiers à convaincre, les impliquer dans le projet Seront des vecteurs forts d accompagnement dans le changement et des porte-paroles Communiquer pour informer, accompagner, convaincre Pendant le projet, en annonçant le projet en expliquant son impact Au moment du lancement : Réunion(s), affichages, e-mailings, journaux d entreprise etc. Pourquoi est-ce que l utilisation de ce nouvel outil est importante pour l entreprise? Pour l utilisateur? Qu est-ce que cela va lui apporter à court ou moyen terme? Rédaction d un plan de communication Accompagner les utilisateurs dans la prise en main de l outil Formation Support technique Utilisateurs clés 24

66 Références Bibliographie Guérin B.A., «Conduite de projets informatiques, Développement, analyse et pilotage 2 e édition», eni éditions, 2012. Messager V. «Gestion de projet Agile avec Scrum, Lean, extreme Programming», Eyrolles, 2013. Webographie Wikipédia Youtube VersionOne.com Ramsoft.com «Le projet, définition générale et première approche» http://www.gestion-projet-informatique.vivre-aujourdhui.fr/projet-definition-generale.html «La gestion de projet» de Xavier Liénart http://xavier.lienart.pagesperso-orange.fr/gdp/gdp.html 25