Méthodologie d ingénierie logicielle adaptée à une PME

Transcription

1 Méthodologie d ingénierie logicielle adaptée à une PME Auteur : Thiessoz Yannick Responsable InfoTeam : Beat Ackermann Responsables UNIFR : Jean Hennebert et Patrik Fuhrer Type : Travail de master de l université de Fribourg Document principal : - Début : Fin :

2

3 Manifesto for Agile Software Development Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas 2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice.

4 Résumé Résumé Ce projet est le fruit d une collaboration entre les groupes Génie logiciel et DIVA 1 du département d informatique de l université de Fribourg et une PME Fribourgeoise, InfoTeam. Le Sujet du présent travail a été proposé par InfoTeam, car cette entreprise, qui utilise à l heure actuelle plusieurs méthodologies de développement, est désireuse de connaître leurs évolutions afin de permettre à leurs clients de disposer des concepts les plus novateurs et les mieux adaptés à chaque situation. En effet, la conception de logiciels est un domaine de plus en plus complexe. Il s avère actuellement nécessaire, voir même indispensable pour une entreprise active dans le développement logiciel, de suivre une ou plusieurs méthodologies de développement. Il existe une multitude de méthodologies et de techniques de développement qui ont toutes leurs qualités et leurs défauts, mais aucune d entre elles n est universellement applicable à tout type de projets/entreprises. Le cadre de ce travail est donc l étude des méthodologies existantes pour en déterminer une qui soit adaptée à une PME comme InfoTeam. Le préambule de cette étude des méthodologies de développement consiste en l analyse de l usine à logiciels (Microsoft Visual Studio Team System). Cela afin de fournir à InfoTeam un outil capable de supporter la méthodologie définie. Le processus de tests est une des parties essentielles des méthodologies de développement logiciel. C est pour cette raison que les processus de tests ont été approfondis dans le cadre de ce projet. La finalité de ce travail est la mise en place et le développement d un projet interne à InfoTeam afin de valider la méthodologie défini dans ce travail. Mots clés : Méthodologie de développement logiciel, agilité, Scrum, Extreme Programming, gestion de projet, suivi de projet, test, usine à logiciels, Microsoft Visual Studio Team System, InfoTeam. 1 Document, Image and Voice Analysis :

5 Remerciements Remerciements Cette partie vise à exprimer mes remerciements envers toutes les personnes qui ont contribué à ce travail de master. En espérant n avoir omis personne, j espère que vous avez apprécié la lecture de ce document et que celle-ci vous a été profitable. Jean Hennbert : Pour ses recommandations avisées, ses remarques toujours constructives, ses connaissances des méthodologies agiles dont il m a fait profiter et son enthousiasme constant pour mon travail. Patrik Fuhrer : Pour ses relectures approfondies de mon travail, ses conseils toujours judicieux, son encadrement idéal et l intérêt qu il a sans cesse exprimé pour mon travail. Beat Ackermann : Pour l accueil qu il m a fait au sein d InfoTeam, son soutien, son expérience ainsi que l intérêt qu il a porté vis-à-vis de mon travail. Olivier Neuhaus : Pour sa collaboration au projet SuiviStreamX et surtout pour son jugement de la méthodologie définie. Romain Roy : Pour l apport qu il m a fourni lors du développement de l application web de SuiviStreamX et plus particulièrement de la partie CSS ou il a pu apporter sa grande expérience. Mario Ramalho et Fredy Martuccio : Pour toute l aide qu ils ont pu m apporter lors de la réalisation de projet SuiviStreamX. L équipe d InfoTeam : Pour l accueil qu ils m ont fait au sein de leur entreprise et pour l ambiance de travail qui a été toujours très agréable. Rachel Thiessoz-Barras et Fanchette Oberson : Pour leurs relectures attentives de mon travail de master ainsi que celles des divers documents annexés. Sans elles et leurs remarques détaillées et pertinentes ce document ne serait pas ce qu il est. Je tiens aussi à remercier ma famille et mes amis pour leur aide et leur soutien tout au long de la réalisation de ce projet.

6 Table des matières Table des matières 1. INTRODUCTION CONTEXTE D ENTREPRISE CONTEXTE DU DEVELOPPEMENT DE LOGICIELS CAHIER DES CHARGES USINE À LOGICIELS FONCTIONNALITES DE CES OUTILS MICROSOFT VISUAL STUDIO TEAM SYSTEM Introduction à MVSTS Fonctionnement de MVSTS Les fonctions de MVSTS Conclusions ALTERNATIVES CONCLUSIONS DÉFINITION D UNE MÉTHODOLOGIE DE DÉVELOPPEMENT INTRODUCTION ETAT DE L ART DES METHODOLOGIES DE DEVELOPPEMENT Cycles de développement logiciel Constat actuel de l état et des problématiques du développement logiciel Méthodologie de développement agile MISE EN EVIDENCE DES METHODOLOGIES UTILES A UNE PME CHOIX D UNE METHODOLOGIE QUELQUES METHODOLOGIES AGILES Unified Process (UP) and Rational Unified Process (RUP) Extreme Programming (XP) Scrum MSF Agile COMPARAISON DES METHODES VUES METHODOLOGIE DEFINIE POUR INFOTEAM Introduction Quelle méthodologie agile Fonctionnement de base Apports au fonctionnement de base Conclusion DEFINITION DE LA PROCEDURE DE TEST INTRODUCTION ETAT DE L ART DES PROCÉDURES DE TEST Vérification versus validation Tests «boîte blanche» vs tests «boîte noire» Analyse statique vs analyse dynamique Les niveaux et types de tests logiciels Cycle de test d un développement logiciel PROCESSUS UTILES À UNE PME Tester avant de développer Tester que si nécessaire Pertinences des tests Tests de non régression / 149

7 Table des matières 5. PROJET PILOTE INTRODUCTION DESCRIPTION DU PROJET LES OBJECTIFS MISE EN PLACE DE L ENVIRONNEMENT DE DEVELOPPEMENT MISE EN PLACE DE LA METHODOLOGIE PROPOSEE Création de l équipe Cahier des charges Nombre de Sprints Phase de planification Déroulement des Sprints Scrum Meeting Graphiques d avancement Pratiques de développements APPLICATION FINALE Accès au site Interface principale RESULTATS Points positifs Points négatifs CONCLUSION CONCLUSIONS REFERENCES BIBLIOGRAPHIE WEBOGRAPHIE A CAHIER DES CHARGES A.1 DESCRIPTION DU PROJET A.2 LES OBJECTIFS A.3 ACTIVITES A.4 PLANNING A.5 ACCEPTATION DU CAHIER DES CHARGES B PLANNING FINAL C JOURNAL DE BORD D NDA E CD F PAGE WEB / 149

8 Table des figures Table des figures FIGURE 1 ARCHITECTURE DE MICROSOFT VISUAL STUDIO TEAM SYSTEM...18 FIGURE 2 VISION DE L'USINE A LOGICIELS DE BORLAND...24 FIGURE 3 MODELE EN CASCADE...30 FIGURE 4 MODELE EN V...31 FIGURE 5 MODELE PAR INCREMENTS...32 FIGURE 6 MODELE ITERATIF...33 FIGURE 7 MODELE ITERATIF...34 FIGURE 8 MODELE UTILISE EN PRATIQUE...35 FIGURE 9 METHODOLOGIES AGILES VS METHODOLOGIES CLASSIQUES...37 FIGURE 10 ANALYSE DU COUT D'UN CHANGEMENT EN FONCTION DE SON MOMENT D'APPARITION...41 FIGURE 11 METHODOLOGIES AGILES EN FONCTION DE LA TAILLE DU PROJET TIREE DE [W73]...46 FIGURE 12 METHODOLOGIES AGILES EN FONCTION DES CONTRAINTES TIREE DE [W73]...47 FIGURE 13 METHODOLOGIES AGILES EN FONCTION DES CONTRAINTES TIREE DE [W57]...47 FIGURE 14 UTILISATION DES METHODOLOGIES AGILES TIREE DE [W52]...48 FIGURE 15 HISTORIQUE DE RUP TIREE DE [W83]...48 FIGURE 16 UTILISATION DES METHODOLOGIES AGILES...50 FIGURE 17 LES PRATIQUES D XP TIREE DE [W91]...52 FIGURE 18 ETAPES DU CYCLE DE DEVELOPPEMENT XP...54 FIGURE 19 INTERACTION ET APPRENTISSAGE EN XP...55 FIGURE 20 FONCTIONNEMENT DE SCRUM...58 FIGURE 21 ETAT TRANSITION D UN SENARIO MSF AGILE...61 FIGURE 22 ETAT TRANSITION D UN IMPERATIF DE QUALITE MSF AGILE...61 FIGURE 23 ETAT TRANSITION D UNE TACHE MSF AGILE...62 FIGURE 24 ETAT TRANSITION D UN BUG MSF AGILE...63 FIGURE 25 ETAT TRANSITION D UN RISQUE MSF AGILE...63 FIGURE 26 RAPPORT D AVANCEMENT QUANTITATIF MSF AGILE...64 FIGURE 27 RAPPORT D AVANCEMENT QUALITATIF MSF AGILE...64 FIGURE 28 FONCTIONNEMENT DE SCRUM [W104]...69 FIGURE 29 COUT D'UN CHANGEMENT EN FONCTION DU TEMPS...78 FIGURE 30 PROCESSUS DE VERIFICATION - VALIDATION...79 FIGURE 31 BOITE NOIRE VS BOITE BLANCHE...80 FIGURE 32 EXEMPLE COUVERTURE DE CODE SOUS MICROSOFT VISUAL STUDIO TEAM SYSTEM...81 FIGURE 33 RESULTAT DE L'EXECUTION DES TESTS UNITAIRES...83 FIGURE 34 EXEMPLE DU PROFILER DE CODE SOUS MICROSOFT VISUAL STUDIO TEAM SYSTEM...84 FIGURE 35 CYCLE DE TEST...85 FIGURE 36 PLANIFICATION DES TESTS...86 FIGURE 37 TABLEAU DES TACHES...94 FIGURE 38 SPRINT 1 CUMULATIVE FLOW DIAGRAM...97 FIGURE 39 SPRINT 1 BURDOWN CHART...98 FIGURE 40 MAQUETTE DE L INTERFACE GRAPHIQUE GENERALE...98 FIGURE 41 SCHEMA DE LA BASE DE DONNEES...99 FIGURE 42 SPRINT 2 CUMULTIVE FLOW DIAGRAM FIGURE 43 SPRINT 2 BURDOWN CHART / 149

9 Table des tableaux FIGURE 44 SPRINT 3 BURDOWN CHART FIGURE 45 SPRINT 4 CUMULATIVE FLOW CHART FIGURE 46 SPRINT 3 BURDOWN CHART FIGURE 47 PRODUCT BACKLOG BURDOWN CHART FIGURE 48 SUIVISTREAMX : FENETRE DE LOGIN FIGURE 49 SUIVISTREAMX : INFORMATION DE LOCALISATION D'UN POSTE FIGURE 50 SUIVISTREAMX : INFORMATION SUR LES LOGICIELS INSTALLES FIGURE 51 SUIVISTREAMX : INFORMATION SUR L INSTALLATION DU POSTE FIGURE 52 SUIVISTREAMX : SUPPRESSION D UN POSTE FIGURE 53 SUIVISTREAMX : GESTION DES CLIENTS FIGURE 54 SUIVISTREAMX : RECHERCHE PREDEFINIE MODULES STREAMX FIGURE 55 L'ARBORESCENCE DU CD FIGURE 56 SITE WEB DU PROJET Table des tableaux TABLEAU 1 TAUX D'ECHEC DES DEVELOPPEMENTS DE LOGICIELS...13 TABLEAU 2 COMPARATIF BATIMENT ET LOGICIEL...42 TABLEAU 3 FAIRE LE CHOIX ENTRE LES MODELES ADAPTATIF ET PREDICTIF...43 TABLEAU 4 TYPES DE METHODOLOGIES ET EXEMPLES...45 TABLEAU 5 COMPARAISON AGILE VS CASCADE (WATERFALL)...45 TABLEAU 6 COMPARATIF DE XP, RUP, MSF AGILE ET SCRUM...67 TABLEAU 7 EXEMPLE DE TEST UNITAIRE SOUS MICROSOFT VISUAL STUDIO TEAM SYSTEM...83 TABLEAU 8 PRODUCT BACKLOG AFTER CLIENT ESTIMATION...95 TABLEAU 9 PRODUCT BACKLOG ESTIME PAR L'EQUIPE...96 TABLEAU 10 PRODUCT BACKLOG DU SPRINT TABLEAU 11 AVANCEMENT DU SPRINT 1 (DU 2 JUILLET AU 6 JUILLET)...97 TABLEAU 12 SPRINT BACKLOG DU SPRINT TABLEAU 13 AVANCEMENT DU SPRINT 2 (DU 9 JUILLET AU 13 JUILLET) TABLEAU 14 SPRINT BACKLOG DU SPRINT TABLEAU 15 AVANCEMENT DU SPRINT 3 (DU 16 JUILLET AU 20 JUILLET) TABLEAU 16 SPRINT BACKLOG DU SPRINT TABLEAU 17 AVANCEMENT DU SPRINT 4 (DU 23 JUILLET AU 27 JUILLET) / 149

10

11 Introduction 1. Introduction Poor management can increase software costs more rapidly than any other factor. Barry Boehm 11 / 149

12 Introduction 1.1 Contexte d entreprise Le contexte de ce travail de master est un peu particulier car il est réalisé d entente entre l Université de Fribourg et la société informatique InfoTeam. L entreprise InfoTeam est basée à Villars-sur-Glâne dans le canton de Fribourg. Elle compte, à l heure actuelle, une vingtaine d employés. Elle est active dans de nombreux domaines et est divisée en quatre Teams: Automatisation et Génie logicielle : Qui met en place des systèmes de supervision et contrôle d application industriel. Par exemple, la supervision de la chaîne de production de l usine d incinération Saidef. Web : Energie : IT : Qui met en place des projets web techniques pour des communes, mais aussi la mise en œuvre de plateformes web tel que le site de l aéroport de Genève. Qui développe et maintient un système de contrôle de commande pour poste de haute tension dans le domaine de la distribution énergétique. Qui s occupe de toute l informatique technique pour les PME. Récemment, ils ont mis en place le réseau informatique et bureautique des nouveaux bains de la Gruyère. Cette société est principalement en contact avec des clients du monde industriel ou institutionnel. Elle est reconnue pour ses compétences et son expérience dans le développement, l utilisation et la mise en place de solution Microsoft. Ce contexte est très intéressant, car il me permet de me familiariser plus amplement avec le monde professionnel. De plus, le sujet de mon travail de master ainsi que la collaboration avec une entreprise me permettra d avoir non seulement une vision théorique de ce domaine mais aussi une vision pratique des solutions qui sont réellement mises en œuvre et utiles pour une entreprise. Ce contexte amène entre autre à la problématique de la confidentialité. En effet, certains documents ([B7], [B8], [B9], [B10]) créés durant mon travail de master ainsi que leurs annexes sont soumis aux conditions du NDA (cf. annexe D NDA). Ces documents contiennent les informations supplémentaires listées ci-dessous: i. Une description plus détaillée des fonctionnalités de MVSTS, de son utilisabilité par une PME et des valeurs ajoutées/pertes découlant de son utilisation. ii. Une description détaillée du fonctionnement de la méthodologie, des conseils d utilisation ainsi que le descriptif des besoins qu elle couvre. 12 / 149

13 Introduction 1.2 Contexte du développement de logiciels Le développement de l informatique s accélérant de manière exponentielle, la complexité des solutions techniques et logicielles ne cesse de croître. De part le fait de cette complexité, la manière dont les solutions logicielles sont conçues évolue. Tout a commencé avec la méthode «code and debug» pour aboutir à des méthodes intégrant plus de conception, de tests et surtout d adaptabilité aux changements. Cette évolution a été nécessaire non seulement pour faire face à l augmentation de la complexité mais aussi à la réduction du temps de développement ainsi qu à la demande croissante en matière de qualité. Toutes ces problématiques auxquelles doivent faire face les entreprises, obligent celles-ci à mettre en place des méthodes et principes de développement rigoureux pour minimiser le risque d échec. Ces méthodes et principes sont regroupés sous le terme Méthodologie de développement logiciel. Une des exigences principales du client vis-à-vis d un développement logiciel, outre les impératifs de prix et de temps de développement, est imputée à la qualité du logiciel développé. Cette demande de qualité s intensifiant, le meilleur moyen de garantir la qualité d un programme est de le tester ardemment à l aide de processus de tests bien définis. La mise en place de méthodologies et de processus de tests au sein d une entreprise est un bon procédé mais faut-il encore pouvoir permettre leurs exploitations à l aide d outils. Ces outils permettant le développement de logiciels, la gestion de projet et le suivi de méthodologies et de processus de tests sont connus sous le terme Usine à logiciels. Aujourd hui, la maîtrise des développements logiciels reste largement aléatoire selon les différents rapports chaos du Standish Group [W54]. Le succès des projets informatiques se résume ainsi : Années Succès Mitigés Echec % 53% 31% % 49% 23% % 53% 18% Tableau 1 Taux d'échec des développements de logiciels Un projet étant considéré comme Succès s il est livré à temps, à l intérieur du budget et des spécifications originales. Il est considéré comme Mitigé s il est livré et opérationnel, mais qu il contient moins de fonction que prévu et/ou qu il dépasse les budgets et/ou les échéanciers. Pour finir il est considéré comme Echec s il est abandonné. 13 / 149

14 Introduction Ce constat montre aux entreprises qu il faut dans la mesure du possible limiter le risque d échec ou de résultat mitigé. Pour cela, la mise en place et le suivi de méthodologies de développement et de processus de test est impérative. C est en partant de cette constation que ce travail de Master a vu le jour. Ce travail de master consiste donc en l étude de l état de l art des méthodologies de développement logiciel et des processus de tests. Cela dans le but de déterminer une ou plusieurs méthodologies et processus adaptés à l entreprise InfoTeam. De plus, une étude des outils existants permettant la mise en place de ces méthodologie/processus devra être réalisée en mettant plus particulièrement l accent sur la solution Microsoft Visual Studio Team System [W9] (solution envisagée par InfoTeam). 1.3 Cahier des charges Voici les objectifs finaux tels que décris plus spécifiquement dans le cahier des charges de ce travail de Master (cf. annexe A Cahier des charges). Ils peuvent être divisés en trois grandes parties : Evaluation du logiciel de Microsoft «Microsoft Visual Studio Team System» o Déterminer son utilisabilité par une PME. o Déterminer les valeurs ajoutées qui découleraient de l utilisation de ce logiciel. Définition de deux processus de développement. o Adaptés à la taille du projet (un processus pour les projets de petite taille et un pour ceux de plus grande envergure). o Orientés qualité. o Prenant en compte l intégration constante du client. o S appuyant sur le fait que le début du projet peut se produire à un état d avancement arbitraire. o Basés sur des approches existantes. Définition d une procédure de tests prenant en compte : o Les approches existantes. o La diversité des unités de l entreprise et de ses champs d activité. o L hétérogénéité des technologies et des produits utilisés au sein d InfoTeam. 14 / 149

15 Usine à logiciels 2. Usine à logiciels How does a project get to be a year late? One day at a time. Frederick P. Brooks 15 / 149

16 Usine à logiciels Commençons par une petite définition de l usine logicielle tirée du site [W30] : Usine à logiciels : Une usine logicielle peut être définie comme l'ensemble des outils mis en oeuvre dans le cadre d'un développement logiciel, ainsi que les démarches associées à l'utilisation de ces outils. Cela ne se limite pas à la production du code source, mais à tous les éléments qui participent à la bonne réalisation du projet (tests, documents, suivis, versions,...). Avec la complexité croissante du développement applicatif, la mise en place d usines à logiciels devient un impératif. En effet, un grand nombre de projets ne respectent pas les délais, le budget, la spécification ou encore la qualité. Pour palier à ces problèmes, de grands éditeurs tels qu IBM, Microsoft ou Borland ont prévu de mettre en place des suites de développement logiciel intégrant des outils de collaboration et de gestion de projet. Ces suites de développement aussi appelées usine logicielle devrait permettre d orchestrer le travail d équipe ainsi que la couverture de tout le cycle de vie d un projet de l'analyse du besoin jusqu à la mise en production. 2.1 Fonctionnalités de ces outils L introduction des usines à logiciels cache une révolution du développement. En effet, elles regroupent les fonctionnalités suivantes : La gestion de projet Le suivi de projet ainsi que la génération de rapports d avancement L usage des bonnes pratiques La mise en place de processus et méthodologies La modélisation d architecture L intégration continue Les tests dès la phase de conception Une collaboration accrue Une automatisation des tâches rébarbatives Un déploiement contrôlé. 16 / 149

17 Usine à logiciels 2.2 Microsoft Visual Studio Team System Dans ce chapitre nous allons passer en revue la suite logicielle Microsoft Visual Studio Team System (MVSTS dans la suite de ce document). Cette usine à logiciel a été étudiée plus en profondeur car l entreprise InfoTeam envisage son utilisation. Le document [B7] offre un plus grand complément d information sur ce produit Introduction à MVSTS Pour la première fois, Microsoft crée une gamme d outils de développement permettant de gérer tout le cycle de vie d un logiciel «Microsoft Visual Studio Team System». MVSTS découle de l intégration de plusieurs composants de gestion de cycle de développement de logiciels au sein de l IDE Visual Studio. Cette gamme de produit est centrée sur les individus et leurs rôles au sein du team de création de logiciels. Elle prend en charge la gestion des sources, des tests, de l architecture, du déploiement, le contrôle de la qualité ainsi que le suivi de méthodologie. Microsoft a développé cet outil pour répondre aux besoins suivants : Améliorer la qualité Faciliter la collaboration entre les différents rôles Piloter le projet : connaître l avancement du projet, être capable d anticiper Fonctionnement de MVSTS MVSTS est constitué de deux blocs : une partie cliente et la partie serveur «Team foundation server» (TSF dans la suite de ce document). La partie cliente est actuellement disponible en quatre éditions spécifiques aux différents rôles des acteurs de l équipe de développement (Software Architects, Software Developers, Software Testers, Database Professionals). Il existe aussi une version cliente Team Suite qui regroupe ces quatre éditions. Les parties clientes sont totalement intégrées dans l IDE de développement Visual Studio et proposent des outils destinés à chaque rôle. La partie TFS héberge les aspects de cycle de vie, tels que le contrôle des versions, le suivi des éléments de travail, Team Build, le portail d équipe et le magasin de données qui contient les documents relatifs aux projets. Cette gamme de produit est donc basée sur le rôle des utilisateurs au sein du cycle de développement d un logiciel. Cela est clairement visible dans la Figure 1 tirée du site [W9]: 17 / 149

18 Usine à logiciels Figure 1 Architecture de Microsoft Visual Studio Team System Cette figure nous permet de voir les composants de MVSTS à savoir les quatre éditions clientes (en haut) et le TFS (en bas). Chaque type d édition contient des outils spécifiques au rôle de l utilisateur. Par exemple l "Analyse dynamique de code" pour l édition «for software Developers». Chaque type d édition possède aussi des outils communs à toutes les éditions comme le "Concepteur de classe" ou "Visual studio 2005 Professional". La gestion de projet de MVSTS est basée sur un suivi des éléments de travail (work item) représentant des tâches élémentaires. MVSTS fait l hypothèse que chaque tâche présente dans le processus de développement d un logiciel peut et doit être exprimée en tant qu élément de travail. Contrairement à la gestion réalisée habituellement avec Excel ou de Project, où la plupart du temps seule la création des tâches est effectuée, MVSTS permet le suivi de ces tâches (qui fait quoi, quand et pourquoi). C est ce qui permet au chef de projet de collecter des données relatives au projet afin d en générer des rapports d avancement ou de qualité. Ces rapports lui permettront d informer le client de manière simple et compréhensible. 18 / 149

19 Usine à logiciels Les fonctions de MVSTS Ce chapitre donne une brève description des fonctionnalités offertes MVSTS. Plus de détails sur le fonctionnement de chaque option sont fournis dans le document [B7] selon les conditions du NDA (cf. annexe D NDA) Partie Cliente Concepteur d application (Application Designer) Ce type de diagramme est très similaire à la notion de diagramme de composant d UML. Le concepteur d application permet de visualiser : Les applications, les services et les bases de données utilisées. Les points (interfaces) par lesquels ces applications communiquent. Les connexions entre les points de communication qui mettent en évidence les interdépendances entre ces applications. Il offre aussi la possibilité de générer du code et de mettre à jour automatiquement les modifications effectuées dans le code ou dans le concepteur. Concepteur d infrastructure (Logical Datacenter Designer) Ce concepteur permet de modéliser une infrastructure logique de déploiement en incluant les réseaux (zones), les serveurs logiques, les protocoles de communication et les contraintes de sécurité. Concepteur de déploiement (Deployment Designer & System Designer) Il permet de regrouper les parties définies sur des diagrammes d application en unités de déploiement (System diagram). Puis le concepteur de déploiement permet d évaluer le déploiement de ces unités au sein d une infrastructure (logical Datacenter Design). Analyse statique du code Cet outil permet d analyser le code à la compilation pour assurer le respect des conventions de codage : règles de nommage, règles d architecture, failles de sécurité potentielles. Analyse dynamique du code et Profiler de code Cet outil permet aux développeurs de mesurer, d évaluer et de cibler les problèmes de performance de leur code. 19 / 149

20 Usine à logiciels Test web et test fonctionnel Permet d enregistrer une session d activités réalisées sur une page web (série de requêtes http). Après création, il est possible de modifier ces tests (par exemple de les piloter par les données) ou alors de les assembler dans des tests de charge. Test de montée en charge Ces tests sont composés d une série de tests web ou de tests unitaires pour simuler une utilisation en production. Test manuel Ce type de test permet de définir les étapes qu un être humain doit suivre pour réaliser un test qui ne peut pas être automatisé. Test générique Ce type de test permet d encapsuler un test (programme ou outil tiers) qui peut être exécuté en ligne de commande et qui retourne une valeur réussite ou échec. Test ordonné Permet de regrouper et de séquencer un certain nombre d autres tests au sein d un test ordonné. Tests unitaires Cette fonction est disponible pour les éditions Developers, Testers et Database Professionals. Cette fonction permet de générer des tests unitaires (basés sur les assertions) qui invoquent des méthodes et vérifient leurs valeurs de retour. Peut être appliqué à des classes mais aussi à des pages web ou encore à des procédures stockées. Couverture de code Cet outil permet donc de distinguer rapidement les lignes de code qui ont été parcourues au moins une fois pendant les tests de celles qui n ont jamais été balayées. Gestion des campagnes de test Organise les tests pour déterminer lesquels sont exécutés dans quel ordre et à quel moment. 20 / 149

21 Usine à logiciels Comparaison de schémas et de données Permet la comparaison entre les différentes versions des schémas de développement et de production. Permet de générer les scripts T-SQL pour appliquer les différences. Gestion des déploiements Lorsqu une version de développement stable est finalisée, on peut générer les scripts de déploiement/mise à jour ou déployer directement la base en sélectionnant le serveur cible (souvent en local pendant le développement). Génération de jeux d essais Permet de populer les tables de la base de données en respectant la structure et les types de données, ainsi que la répartition de la volumétrie. Cette génération peut se faire à l aide de séquences, d expressions régulières, de binding. Concepteur de classes Le concepteur de classe permet de visualiser sous forme graphique le code à la manière des diagrammes de classe UML. Ces diagrammes permettent la génération du code et sont en permanence synchronisés avec le code Partie serveur Modèles de projet (MSF Agile et CMMI) MSF Agile et CMMI sont des modèles de projet fournissant des exemples de méthodologies utilisables depuis MVSTS. Gestion de configuration et de version Le contrôle des sources est effectué avec Team Foundation Version Control (TFS-VC). TFS- VC stocke toutes les modifications (diagramme, fichiers de configuration, source, documentation,..) dans une base de données SQL Server 2005 et non pas seulement le code source. Gestion du changement L objectif de cette partie est de permettre le suivi de l état du projet. MVSTS utilise des work items (tâche élémentaire) pour gérer le travail devant être effectué au cours du cycle de vie d un produit (cf Fonctionnement de MVSTS). Ces work items permettent de réaliser des listes représentant le "reste à faire". Il est possible d associer ces work items à des actions sur le code (check-in, correction d un bug, découverte d un problème d intégration, ), sur les 21 / 149

22 Usine à logiciels builds et les tests. Ce qui permet la traçabilité du processus de développement et la génération de rapports répondant à la question qui a fait quoi et pourquoi. Serveur d intégration (Build) Team Foundation Build permet à l'équipe de créer et de gérer régulièrement des builds de produit. Rapports d avancement Les rapports permettent de suivre l avancement qualitatif et quantitatif du projet au travers d indicateurs (bugs actifs ou corrigés, évolution du nombre de tests unitaires, évolution du taux de couverture et de réussite des tests, temps moyen de résolution d un bug, ). Portail projet Chaque projet d équipe est associé à un portail de projet de type SharePoint Services. Il permet le partage de documents et d informations (agendas, discussions, actualités) entre les membres de l équipe projet. Gestion de projet Les éléments de travail son stockés dans une base de donnée sur TFS. Toutefois, pour faciliter la gestion de projet, il est possible de les importer dans Project ou Excel Conclusions Dans MVSTS, Microsoft intègre à son IDE de développement Visual Studio un ensemble de fonctionnalités très intéressantes. L évolution du développement logiciel va clairement en direction des usines à logiciels lesquelles représentent l'ensemble des outils mis en œuvre dans le cadre d'un développement logiciel. Cela ne se limite pas à la production du code source, mais à tous les éléments qui participent à la bonne réalisation du projet (tests, documents, suivis, versions,...). De grandes entreprises comme IBM, Microsoft ou Borland ont compris cet état de fait et sont en train de mettre en place des solutions dans ce domaine. Le monde open source s intéresse aussi à ce domaine. Mais la mise en place de tels systèmes étant très complexe, il va être difficile de rivaliser avec des solutions proposées par IBM, Microsoft ou Borland qui n ont clairement pas les mêmes moyens. A l heure actuelle, le monde open source offre ses fonctionnalités mais à l aide de différents produits qui ne sont pas tous intégrés dans une usine à logiciels. Ce qui pose certains problèmes comme la 22 / 149

23 Usine à logiciels sélection/intégration de différents outils ou encore la centralisation des données et des métriques du projet. L avantage principal de MVSTS est l intégration de tous les outils nécessaires au développement logiciel dans Visual Studio. Ce qui en fait, dans le cadre d un développement.net, la plateforme de référence. De plus, l ouverture de TFS permet l utilisation de ces outils de gestion de projet avec d autres plateformes de développement. Il est par exemple intéressant pour une entreprise de pouvoir se diversifier tout en travaillant de la même manière sur toutes les technologies. En ce qui concerne la problématique du prix, il est à déterminer si les avantages découlant de l utilisation de MVSTS (temps de développement réduit, qualité améliorée, ) peuvent combler ce problème. Dans tous les cas, Microsoft offre une version d évaluation valable six mois. Cela peut être une bonne solution pour mettre en place et tester MVSTS. Enfin, s il faut retenir quelque chose sur MVSTS ce serait l amélioration qu il peut apporter dans les domaines suivants : Qualité logicielle (tests, analyse de code, profiler, intégration continue) Collaboration (work item, portail) Pilotage des projets (work item, rapport, project excel) 2.3 Alternatives Jazz Eclipse Le projet Jazz initié par Rational et IBM tend à être le future de l IDE d Eclipse. En effet, Jazz vise à étendre l IDE d Eclipse à une plateforme de collaboration. Cette plateforme de collaboration serait en faite une Usine à logiciels comme décrite au début du chapitre 2 Usine à logiciels. Elle est très similaire à MVSTS, elle est composée d une partie serveur et d une partie cliente, elle intègre un gestionnaire des sources, la création de rapports, Elle est basée sur des méthodologies agiles. Elle est désignée pour être utilisable depuis un autre IDE que Eclipse comme par exemple Visual Studio. Mais, actuellement, elle est en cours de développement et sa sortie ne sera sûrement pas annoncée avant 2008 [W3]. 23 / 149

24 Usine à logiciels TeamCity TeamCity est indépendant de L IDE et peut aussi bien fonctionner sur IntelliJ (JAVA) que sur Visual Studio2005 (.NET). TeamCity est cependant moins abouti que MVSTS est s avère être plus un moteur d intégration continue qu une réelle usine à logiciels. En effet, il n intègre pas les options suivantes : suivi de méthodologies, rapport d avancement, diagrammes de conception, analyse du code, plusieurs types de tests et gestion du changement (workitem). De plus, presque toutes les fonctions sont limitées vis-à-vis de MVSTS à l exception du principe de Build. Son principal avantage reste le prix et l utilisabilité aussi bien depuis java que.net Borland Borland se lance aussi dans la vision d usine à logiciels. Mais sa vision de l usine à logiciels est constituée de rassemblements de plusieurs produits et de la tentative de les faire collaborer par un certain nombre d engrenages visibles dans la Figure 2 tirée du site [W8]. Figure 2 Vision de l'usine à logiciels de Borland Cette vision intègre les produits suivants : Borland Tempo (Plan), Borland Caliber DefineIT (Define), Borland CaliberRM (Define), Borland Together Technologies (Design, Develop/Configure), Borland Gauntlet (Test), Borland SilkCentral Test Manager (Test), Borland SilkTest (Test), Borland SilkPerformer (Test), Borland StarTeam (Manage). Malgré l intégration de plusieurs produits pouvant amener aux mêmes résultats que MVSTS, la suite de Borland n est pas une alternative directe car elle est spécifique au monde java. 24 / 149

25 Usine à logiciels IBM Tout comme Borland, IBM offre une suite de produits permettant de gérer tous le cycle de développement logiciel. Cette suite de produits est identifiée sous la gamme rational qui vient se greffer sur la plate-forme "Open-source" Eclipse. Mais la vision future d IBM semble tournée vers Jazz. 2.4 Conclusions Vu la tournure que prend actuellement le développement logiciel ainsi que les apports qui découlent de l utilisation d un tel produit, les PME vont se tourner vers des usines à logiciel. Et en termes d usine à logiciels, MVSTS est actuellement la plus performante si ce n est la seule pour le monde.net. Les autres systèmes disponibles ne couvrent pas tous les besoins et les outils isolés communiquent mal entre eux. Personnellement, je conseillerais l utilisation de MVSTS ou tout du moins la prise en compte et le test de cette usine par une PME. La seule problématique autre que le prix devrait venir de l acceptation de ce produit par les utilisateurs (développeurs). En effet, il est toujours difficile de changer ses habitudes, même si le produit proposé est plus intéressant que les produits utilisés actuellement, le changement est toujours problématique. Mais je le rappelle, à terme se changement risque d être inéluctable. Donc, à mon sens, il est préférable d anticiper et prendre les devants. 25 / 149

26

27 Définition d une méthodologie de développement 3. Définition d une méthodologie de développement Agile methods derive much of their agility by relying on the tacit knowledge embodied in the team, rather than writing the knowleadge down in plans. Kent Beck 27 / 149

28 Définition d une méthodologie de développement 3.1 Introduction Tout d abord commençons par une petite définition [B5]: MÉTHODOLOGIE n. f. XIXe siècle. Composé à l'aide de méthode et de -logie, tiré du grec logos, «discours, traité». Étude des méthodes de recherche et d'analyse propres à une science, à une discipline. Dans le cas plus concret du développement logiciel, les méthodologies sont une sous partie du génie logiciel qui vise à rassembler l ensemble des méthodes, des techniques et des outils servant à la production d un logiciel. Une méthodologie de développement logiciel doit tenir compte de la création du logiciel à proprement parler mais aussi de tous les composants relatifs au cycle de vie d un logiciel. Le cycle de vie d un logiciel commence à la définition des objectifs et dure jusqu à la fin de son exploitation. De part ce fait, les méthodologies de développement logiciel et la gestion du cycle de vie du développement logiciel sont deux notions très liées si ce n est équivalentes. Les méthodologies de développement logiciel peuvent donc être vues comme l assemblage de techniques et de méthodes permettant la gestion de toutes les phases du cycle de développement logiciel. Une méthodologie de développement logiciel doit être couplée à un outil permettant son suivi. En effet, certains outils de développement supportent des méthodologies mais ces deux notions forment un tout. L utilisation d un outil ne garantit pas le suivi d une méthodologie mais l outil peut rendre possible ce suivi. Enfin, une méthodologie doit regrouper un certain nombre de bonnes pratiques du développement logiciel qui ont été éprouvées. Cela peut aller de pratiques sur la gestion de projet (planification) ou l organisation des équipes de développement (pair programming), mais aussi les motifs de conception (design patterns) pour la modélisation du code. La notion de méthodologie de développement logiciel devient omniprésente dans un domaine où seulement un tiers des projets peuvent être considérés comme des succès [W54]. Un projet est réussi s il est en adéquation avec les trois concepts suivants ; il est livré à temps, à l intérieur du budget et des spécifications originales tout en correspondant aux besoins du client. Les méthodologies sont donc une alternative au développement dit «chaotique» où la caractéristique principale est «coder et deboguer». Elles imposent un processus discipliné permettant de rendre le développement logiciel plus prévisible et plus efficace. 28 / 149

29 Définition d une méthodologie de développement 3.2 Etat de l art des méthodologies de développement En guise d introduction à l état de l art des méthodologies de développement logiciel, il est nécessaire de les distinguer de la modélisation logicielle. En effet, on fait souvent l erreur de penser que la méthodologie se résume à la modélisation, ce qui est totalement erroné. En ce qui concerne la modélisation, l état de l art s appuie sur le modèle objet et le standard incontournable qu est UML. Les méthodologies quant à elles couvrent bien évidemment la modélisation mais aussi tout le cycle de développement de logiciel. C est pour cette raison que nous allons commencer l état de l art par un aperçu des types de cycles existants Cycles de développement logiciel. Le cycle de développement d un logiciel ne se résume pas à la seule phase de codage mais peut être considéré comme toute la période partant de la définition des besoins et allant jusqu à l arrêt de l exploitation du logiciel. Mais dans tous les cas de figure, certaines phases sont inévitables : 1. Expression des besoins : Description informelle des besoins exprimés par l utilisateur. Cela permet de définir le cahier des charges. 2. Spécification : Description formelle du problème par l équipe de développement. Cela permet de définir le quoi en fonction du cahier des charges. 3. Analyse et conception : Recherche de solutions tenant compte de l architecture technique. Cela permet de définir le comment. La conception est souvent découpée en deux phases : la conception générale et la conception détaillée. La conception détaillée représente la conception du système global, composant par composant. 4. Développement : Production du code en se référant à l analyse et la conception mais sans avoir besoin de remettre ceux-ci en question. Permet aussi la mise en place des tests unitaires (cf ). 5. Test/recette Validation par le client des fonctionnalités du système. 6. Déploiement/maintenance. Souvent certaines de ces activités sont regroupées, mais elles sont toujours présentes et se déroulent presque toujours dans l ordre précité. L ordre est souvent respecté mais cela n empêche pas d organiser le déroulement de ces phases de nombreuses manières. Les deux grandes familles d organisation sont les cycles séquentiels et les cycles itératifs. Ces cycles seront détaillés dans les chapitres suivants. Il est intéressant de noter que selon certains chiffres la phase de conception devrait représenter 35% de l effort total de développement, la phase de test 30%, tandis que la phase de 29 / 149

30 Définition d une méthodologie de développement développement pourrait être réduite à 20%. Bien évidement ces données sont très variables en fonction des projets et des processus de développement mis en place. Mais elles illustrent que la phase de développement (codage) n est pas forcément la phase la plus gourmande en effort de travail Modèle en cascade (séquentiel) C est l un des premiers modèles apparu en 1966 et formalisé aux alentours de 1970 par W. Royce. Il est issu de la construction du bâtiment où les fondations sont construites avant les reste de la maison. Les activités y sont exécutées les unes après les autres de manière totalement successive. Dans sa version de base ce modèle était basé sur le principe de nonretour (il n y a donc pas de remise en cause d une phase précédente). Dans la version actuelle, la fin de chaque phase a lieu à une date prédéterminée et s achève par la production d un certain nombre de documents ou logiciels. Ces livrables sont produits pour réaliser la Vérification/Validation (cf Vérification versus validation) qui permet d approuver le passage à la phase suivante ou la correction de l étape précédente. Il est très bien adapté aux petits projets simples avec peu d incertitude et où les besoins sont clairement identifiés et stables. Figure 3 Modèle en cascade Avantages : Modèle simple Tests entre chaque phase Gestion des phases en temps et ressources Définition des tâches et des livrables Inconvénients : Effet tunnel (identification tardive des problèmes, preuve tardive du bon fonctionnement). Difficulté de cerner les besoins dès le début, refus de tout changement. Frustration de l attente de la première version (lenteur). Les projets informatiques sont rarement séquentiels. 30 / 149

31 Définition d une méthodologie de développement Modèle en V (séquentiel) Mc Dermid et Ripkin proposèrent ce modèle en Il découle d une amélioration du modèle en cascade où chaque phase du projet a une phase de test qui lui est associée. Cette association découle de l idée que chaque phase en amont du développement doit préparer une phase correspondante de vérification en aval de la production du logiciel. Par exemple, la description d un composant est accompagnée des tests qui permettront de s assurer qu il correspond à sa description. Il a été mis en place pour améliorer le problème lié au manque de réactivité du modèle en cascade (on ne s aperçoit que lors de la phase de test que cette propriété ne peut pas être vérifiée objectivement). Elle est basée sur les deux approches (Top- Down et Bottom-Up). Dans les premières phases descendantes, on décompose le projet pour faciliter la partie développement (Top-Down). Tandis que dans les secondes phases, on recompose l ensemble du logiciel en le testant du détail vers l ensemble (Bottom-Up). Figure 4 Modèle en V Avantages : Réactivité accrue vis-à-vis du modèle en cascade (évite d énoncer une propriété non vérifiable objectivement une fois le logiciel réalisé) Modèle industriel classique éprouvé Validation systématique de chaque étape avec retour en arrière possible La mise en place de la vérification lors de la conception oblige à une réflexion supplémentaire très utile. Inconvénients : Pas de prototypage (code/validation tardive) risque d effet tunnel Prise en compte des modifications du cahier des charges difficile Obligation de définir la totalité des besoins au départ Projet rarement séquentiel 31 / 149

32 Définition d une méthodologie de développement Modèle par incréments Le principe de base du modèle par incréments est de découper l expression des besoins en sous-parties (lots ou incréments). Chaque lot sera réalisé successivement ou en se chevauchant selon un modèle en cascade ou en V. Figure 5 Modèle par incréments Avantages : Diminution de la durée d un cycle et donc de l effet tunnel Diminution de la complexité (vision uniquement d un incrément) Les intégrations sont progressives. Inconvénients : Difficulté de l intégration Difficulté de la conception globale Inadapté aux besoins d évolution en cours de projet, problème en cas de remise en cause du noyau. 32 / 149

33 Définition d une méthodologie de développement Modèle en spirale (itératif) Ce modèle a été proposé par Barry W. Boehm en Il reprend les différentes étapes du cycle en V. Il est basé sur des itérations. Par l'implémentation de versions successives (une version par cycle), le cycle recommence en proposant un produit de plus en plus complet. Chaque nouvelle phase permet d ajuster ce qui a déjà été réalisé durant le cycle précédent et d ajouter de nouvelles fonctionnalités. Il est grandement basé sur une analyse des risques pouvant à tout moment remettre en cause le développement. Figure 6 Modèle Itératif Avantages : Retour plus tôt sur l avancée du projet donc meilleure estimation des budgets Gestion du changement (les besoins sont affinés à chaque cycle) Mise en œuvre d une analyse des risques. Inconvénient : Les cycles peuvent être indépendants les uns des autres ce qui peut provoquer un big-bang lors de l intégration. 33 / 149

34 Définition d une méthodologie de développement Modèle itératifs Le principe de base du modèle itératif est assez simple, à chaque nouveau besoin un cycle de type «roue de Deming [W55]» est appliqué. La roue de Deming représente le principe «Plan Do Check Ack» (PDCA). Ce cycle est effectué de manière itérative où à chaque itération (mini-cascade) sont présents : l étude de la faisabilité, l élaboration, la fabrication et la livraison. L idée principale étant de pouvoir livrer au plus tôt une version qui puisse être testée par le client. Donc les itérations se doivent d être les plus courtes possibles. Puis à chaque nouvelle itération les nouveaux besoins sont examinés et les erreurs de l itération précédente sont corrigées. Cela signifie que la version livrée au client n est pas une version finale et qu il peut manquer beaucoup de fonctionnalités mais il a au moins la possibilité de vérifier et de valider rapidement. Figure 7 Modèle Itératif Avantages : Adaptation au changement (retour plus rapide) Prototype (plus simple de voir que de lire de la documentation) Plus forte intégration du client (meilleure expression des besoins) Motivation de l équipe par des objectifs proches Inconvénient : Difficulté de traiter les gros projets possibilité d erreur dans la conception et refactoring difficile 34 / 149

35 Définition d une méthodologie de développement Evolution La description des différents types de cycles de développement logiciel qui a été réalisée dans les parties précédentes suit l évolution de ces cycles. En effet, tout au début il n y avait pas vraiment de cycle de développement logiciel, la méthode «code and debug» était utilisée. Puis on s est rendu compte que cette méthode n était pas adaptée à l évolution des projets informatiques. Les projets devenant de plus en plus grands, un certain nombre de phases ont été mis en évidence (cf Cycles de développement logiciel.). Puis le premier type de cycle de développement (cf Modèle en cascade (séquentiel)) a été déterminé. Cela fut une vraie amélioration de la gestion de projets informatiques toutefois ce modèle était limité car il produisait un grand effet tunnel. Afin de minimiser ce problème le modèle en V a été développé, mais ce modèle, tout comme son prédécesseur, ne fournissait une version à valider que tardivement. Le modèle par incrément a donc été mis en place. Mais une grande problématique du développement logiciel est l évolution constante des besoins des utilisateurs. Comme cette problématique du changement n étant pas prise en compte dans le modèle par incrément, le modèle en spirale a été pensé. Le cycle du modèle de spirale étant indépendant, un problème d effet big-bang subsistait durant l intégration. Le modèle itératif, qui consiste à la mise en place successive d une version de l application à laquelle de nouvelles fonctionnalités sont ajoutées durant les itérations suivantes, a donc été mis en place. La prise en compte de l évolution incessante des besoins dans le développement informatique aboutit, à l heure actuelle, à un développement itératif reflétant l état de l art Constat actuel de l état et des problématiques du développement logiciel Ces différents cycles de développement logiciel sont purement théoriques. Dans la pratique, la situation la plus fréquente est la suivante : Figure 8 Modèle utilisé en pratique La plupart du temps il n y a aucune distinction entre l expression des besoins et les spécifications. De plus, la conception est souvent réalisée par les développeurs en même temps que le développement. Une autre variable du constat actuel vient du fait que les clients ont de grandes difficultés à exprimer leurs besoins sous une forme exploitable par les équipes de développement. Dans 35 / 149

36 Définition d une méthodologie de développement les premiers modèles de cycle de vie tout comme dans le modèle utilisé en pratique, la plupart des décisions (expression des besoins, mise en place de la spécification, conception) sont concentrées en début de projet dans le but de donner des garanties aux clients sur ce qu ils obtiendront. Cette démarche part d une bonne intention mais elle ne tient pas compte du fait que les besoins des utilisateurs changent et que leurs stratégies évoluent. Cela implique qu une bonne méthodologie de développement logiciel doit être réactive aux besoins changeants du client. A l inverse, il ne faut pas tomber dans un chaos du changement permanent, mais il faudra donc nécessairement adapter la granularité des changements. Enfin, les méthodologies de développement logiciel dites classiques (cycle en cascade, V, ) sont grandement basées sur des livrables (documentation) qui sont fournis entre chaque étape du cycle afin de permettre un meilleur suivi du projet. Cela les rend peu populaires car très bureaucratiques. En effet, le surplus de travail à effectuer pour suivre la méthodologie ne fait que ralentir le développement. De plus, dans la pratique tous ces documents ne sont que très rarement lus et quasiment jamais mis à jour. Ce qui remet en question leurs intérêt Méthodologie de développement agile Ce type de méthodologie constitue l état de l art actuel des méthodologies de développement logiciel. Cela signifie qu elle représente ce qui se fait de mieux en matière de développement logiciel, toutefois cela ne signifie pas qu elles sont les méthodologies les plus utilisées. Elles ont vu le jour suite aux problèmes posés dans le constat actuel. Ces méthodes sont issues d un mélange entre le modèle en incrément et le modèle itératif visant à réduire le cycle de développement logiciel (donc à accélérer le développement). Elles sont très bien adaptées à la problématique d avancement d un projet pour lequel les spécifications ne sont pas stables grâce à leur implication constante du client. De plus, elles sont très pragmatiques et visent la réelle satisfaction du client et non pas celle d un contrat établi préalablement. Pour y parvenir, elles nécessitent d'impliquer d'avantage le client et d'être à son écoute afin d'être le plus proche possible de ses demandes. Elles se distinguent des méthodes classiques sur plusieurs niveaux qui sont exprimés dans la Figure 9 tirée du site [W80]. 36 / 149

37 Définition d une méthodologie de développement Figure 9 Méthodologies Agiles VS Méthodologies Classiques La notion de méthode agile est née à travers un manifeste [W68] signé par dix-sept personnalités (parmi lesquelles Ward Cunningham, l'inventeur du Wiki), créateurs de méthodes ou dirigeants de sociétés Les valeurs des méthodologies agiles Les méthodologies agiles prônent quatre valeurs fondamentales : Communication : Personnes et interactions plutôt que procédures et outils. La gestion de projet a longtemps établi la «méthode/procédure» comme le vecteur essentiel de succès d un projet. Alors que dans les faits, la meilleure garantie de succès sont les personnes. Même une bonne méthode ne sauvera pas un projet de l échec si l équipe n est pas constituée de personnes adéquates et impliquées dans le projet. Il est préférable d avoir une équipe soudée de développeurs moyens qui communiquent et collaborent plutôt qu une équipe composée d individualistes même brillants. 37 / 149

38 Définition d une méthodologie de développement Simplicité : Applications fonctionnelles plutôt que documentation complète. Il est vital d avoir une application finale fonctionnelle (c est finalement le but du client). Le reste (documentation, ) est secondaire, bien qu une documentation succincte et précise est utile comme moyen de communication. De plus, l écriture et la mise à jour de documents sont extrêmement consommatrices de ressources. Un document qui n est pas mis régulièrement à jour peut devenir inutile ou même trompeur. Il est préférable de bien commenter le code qui est l élément clé de la documentation. Il est aussi plus simple de demander un feedback à un client sur un produit fonctionnel que sur une documentation. Par ailleurs, il faut toujours développer la façon la plus simple car la plus compliquée ne sera sûrement pas utilisée. Feedback : Collaboration avec le client plutôt que négociation de contrat. Les changements sont inévitables au sein d un projet informatique. De part ce fait, il est utopique de penser que les exigences, le planning et le coût peuvent être spécifiés à l avance et qu ils ne changeront pas. En partant de ce principe, la manière la plus juste de répondre effectivement aux besoins du client est de travailler en étroite collaboration avec celui-ci. Cela permet de répondre directement aux changements de besoins du client et donc d obtenir sa satisfaction. Cela reste néanmoins difficile à mettre en œuvre car cela implique une grande confiance réciproque. Courage : Acceptation du changement plutôt que suivi d un plan. La qualité d un projet pour le client est souvent étroitement liée à la capacité d adaptation de l équipe de développement aux exigences de celui-ci. Ses exigences vont certainement changer en cours de projet et il est indispensable d avoir un planning flexible et adaptable à ces changements. Cette problématique demande au client le courage de donner des priorités à ses besoins et d accepter que certains besoins ne soient finalement pas très clairs. Elle demande au responsable le courage d entamer un projet avant que tout ne soit clairement précisé dans un document. 38 / 149

39 Définition d une méthodologie de développement Ces quatre valeurs fondamentales de l agilité sont déclinées en douze principes généraux communs à toutes les méthodes agiles : 1. «Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles». Les méthodes agiles recommandent de livrer très tôt une version rudimentaire puis de livrer souvent des versions auxquelles s ajoute les fonctionnalités progressivement. Cela permet un feedback rapide du client et donc une prise en compte immédiate du changement de ses exigences. Ainsi qu un bon suivi des risques. 2. «Le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client». Les changements d exigences doivent être pris comme une bonne chose car ils signifient que l équipe a compris et appris comment satisfaire le client encore mieux. Les systèmes développés avec des méthodologies agiles se veulent flexibles et évolutifs car ils doivent minimiser l impact d un changement. 3. «Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte». Contrairement à la livraison de document décrivant l application, la livraison la plus fréquemment possible d une application fonctionnelle offre au client une meilleure vision du produit et un feedback plus rapide. 4. «Le client et les développeurs doivent collaborer quotidiennement au projet». L interaction entre le client et les développeurs doit être permanente pour guider continuellement le projet. 5. «Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leurs capacités à faire le travail». Avec les méthodologies agiles, les personnes sont le facteur clé de la réussite d un projet. Tout le reste, processus, environnement, technologie peuvent être changés s ils entravent le bon fonctionnement de l équipe. 6. «La méthode la plus efficace de transmettre l'information est une conversation en face à face». Les méthodologies agiles partent du principe que la meilleure manière de communiquer n est pas la production de documents pour tout ce qui est dit (cela étant impossible), mais belle et bien une discussion ouverte entre les membres de l équipe. 39 / 149

40 Définition d une méthodologie de développement 7. «Un logiciel fonctionnel est la meilleure unité de mesure de progression d un projet». Le client n a finalement que faire de savoir dans quelle phase du projet se trouve l équipe, quels documents ont été réalisés Le client veut un produit fini qui répond aux exigences qu il a fixées. Le meilleur moyen pour mesurer cette progression est tout simplement de voir effectivement quel pourcentage des fonctionnalités sont implémentées. 8. «Les processus agiles incitent à un rythme de développement soutenable. Sponsors, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment». Les méthodologies agiles veulent supprimer le stress post déploiement. Pour qu un développement soit de bonne qualité, il faut qu il le soit tout le temps. Il est donc logique de penser que le travail ne peut se faire en sprints successifs mais plutôt en une course régulière comme dans un marathon. 9. «Porter une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité». Le code source de l application doit toujours rester propre pour améliorer la rapidité et la qualité du développement. Les membres de l équipe doivent donc porter une attention continue à la qualité et la clarté du code qu ils produisent en effectuant de la refactorisation (refactoring). 10. «La simplicité "l'art de maximiser la quantité de travail à ne pas faire" est essentielle». Comme le disait à juste titre Einstein «Les choses devraient être faites aussi simples que possible, mais pas plus simples.». Cela s applique très bien au développement logiciel. En effet, il est préférable de ne pas anticiper les besoins du client et de rendre le système le plus simple possible, répondant aux besoins actuels pour que ceux-ci soient facilement adaptables si nécessaire dans le futur. 11. «Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent» Qui mieux que l équipe elle-même peut déterminer qui est le plus à même d effectuer une tâche au sein d une équipe? 12. «À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens». Le principe même de l agilité est d être réactif aux changements qui sont inévitables. Il est donc clair que, aussi bien pensée qu elle soit, une méthodologie de développement agile est soumise à des modifications. Les méthodologies de développement agile définissent des développements qui sont agiles mais elles doivent l être elles-mêmes. 40 / 149

41 Définition d une méthodologie de développement Conclusion La conclusion est simple, contrairement aux méthodes classiques, les méthodologies agiles sont très intéressantes pour le développement logiciel pour plusieurs raisons : Elles intègrent le client pour être plus proches de ses besoins. Elles sont adaptives plutôt que prédictives. Elles sont orientées vers l humain, plutôt que vers les processus et outils. Ces quelques points sont un avantage certain des méthodes agiles vis-à-vis des méthodes classiques. En règle générale, elles permettent aussi de minimiser le coût d un changement au travers du temps contrairement à une méthodologie classique. En effet, dans les méthodologies classiques, plus un changement est découvert tardivement, plus le coût lié à ce changement augmente. Tandis que ce coût a tendance à se stabiliser dans une méthodologie agile telle que extreme programming (cf ) comme le montre la Figure 10 tirée du site [W100]: Figure 10 Analyse du coût d'un changement en fonction de son moment d'apparition 41 / 149

42 Définition d une méthodologie de développement 3.3 Mise en évidence des méthodologies utiles à une PME Nous avons vu dans la partie Constat actuel de l état et des problématiques du développement logiciel que les méthodologies classiques ne sont pas bien adaptées au développement logiciel. Cela peut s expliquer par le fait qu elles sont issues d autres domaines de l ingénierie comme le génie civil. Ces domaines étant très différents, un modèle applicable pour le génie civil ne l est pas forcément pour l ingénierie du logiciel. Faisons la comparaison entre le développement d un logiciel et la construction d un bâtiment : Bâtiment Des dessins décrivent de manière précise la construction du bâtiment Il est assuré que le processus de construction suivra les dessins Les besoins du client sont clairement définis Le coût se situe au niveau de la construction Logiciel Des schémas spécifient le logiciel de manière globale Le processus de construction va remettre en question les dessins (erreurs de conception inévitables) Les besoins du client évoluent Le coût se situe partout sauf au niveau de la construction Tableau 2 Comparatif bâtiment et logiciel Ces quelques points montrent que le développement logiciel est une activité différente. Cela implique donc que le développement logiciel demande une méthodologie différente. Et les méthodologies qui, à l heure actuelle, semblent les plus indiquées pour répondre aux besoins du développement logiciel d une PME sont les méthodologies agiles. Ces méthodes sont utiles car les développements que réalisent les PME se situent souvent dans un contexte de besoins changeants. Et même si les besoins sont stables, une méthode agile doit pouvoir s adapter à ces besoins fixes. Un autre point utile pour une PME est que ces méthodologies placent l humain comme le facteur principal dans le succès des projets et ne le voient pas comme un composant remplaçable. En effet, la notion des individus en tant que ressource est profondément incrustée dans la pensée industrielle. Et si cette notion de remplacement est applicable pour une usine [W56] elle ne l est clairement pas pour un travail autrement créatif et professionnel qu est le développement de logiciel d une PME. Cette mise en avant des individus est une source de motivation pour les développeurs. Et cette motivation a un impact direct sur la productivité. Ce qu il ne faut surtout pas perdre de vue vis-à-vis de l utilisabilité d une méthodologie par une PME est qu elles ne doivent pas être des contraintes pour les gens qui les utilisent mais 42 / 149

43 Définition d une méthodologie de développement plutôt des supports. Cela découle d une acceptation de la méthodologie par les utilisateurs plutôt que l imposition de celle-ci. Et il est plus facile de faire accepter une méthodologie de développement agile qui prend en compte les utilisateurs et qui est simple à mettre en œuvre qu une méthodologie lourde, compliquée et bureaucratique. En règle générale, les problèmes du développement logiciel peuvent être qualifiés selon les trois critères suivant : Dépassements de délais Dépassements de budget Fonctionnalités inadéquates Qualité Coût Délais Les méthodologies agiles s attaquent principalement au dernier critère. En intégrant le client et en appliquant ses demandes de modification cette problématique disparaît. En contrepartie comme les besoins ne sont pas entièrement connus à l avance, il est difficile d établir un temps et un budget fixes. C est une problématique importante car cela demande une confiance réciproque entre le client et l entreprise ainsi qu une adaptation des délais et du budget en fonction des modifications. Mais il est clair que pour un client si les besoins peuvent changer il est plus risqué pour lui d utiliser un processus prédictif. Enfin voici un tableau comparatif qui peut aider à choisir entre une méthodologie agile ou une méthodologie prédictive : Adaptatif Besoins incertains et volatiles Prix et délais fixes mais pas la portée Développeurs responsables et motivés Utilisateurs qui comprennent et s impliquent Prédictif Equipe de plus de 50 personnes Prix, délais et portée fixés dans un contrat Tableau 3 Faire le choix entre les modèles adaptatif et prédictif 3.4 Choix d une méthodologie Comme l ont démontré les chapitres précédents, les méthodologies les mieux adaptées au développement logiciel pour une PME sont de type agile. D une part parce que les méthodologies classiques concentrent la partie décisionnelle au début du projet pour donner au client des garanties sur ce qu il obtiendra en fin de projet sans tenir compte de la variabilité des besoins du client. D autre part parce que ces méthodologies visent à rendre les choses le plus simple possible mais pas plus simples. Ce qui diminue la documentation et permet aux développeurs de se concentrer sur des tâches à plus haute valeur ajoutée. Enfin, elles sont basées sur deux points essentiels : l intégration du client pour répondre à ses besoins réels et 43 / 149

44 Définition d une méthodologie de développement une vision basée sur les individus et non pas sur les processus ce qui améliore les performances de développement en conservant la motivation de l équipe. Tous ces points amènent donc à faire le choix d une méthodologie agile. Toutefois, le choix d une méthodologie n est pas une chose aisée. Elle dépend de beaucoup de facteurs de l entreprise. Il faut garder à tout moment en tête que la méthodologie choisie ne doit pas être une contrainte pour ces utilisateurs mais plutôt un support à leur capacité de développement. D une autre manière il faut aussi éviter d utiliser une méthodologie pour utiliser une méthodologie. Aucune méthodologie ne peut garantir le succès d un projet. En se focalisant sur le respect aveugle d une méthodologie, le but principal qui est finalement la réussite du projet risque bien d être perdu de vue. En définitive, la bonne méthodologie est celle qui permet le succès du projet. De plus, la méthodologie idéale serait celle qui serait tellement en osmose avec l équipe que celle-ci ne se rendrait plus compte du poids de la méthodologie utilisée. Il faut donc que la méthodologie soit le moins intrusive possible et le plus facile à prendre en main. Bien évidemment la mise en place d une méthodologie par une équipe n est pas aisée, elle doit être mise en place par le support d outils. Mais il ne faut pas surcharger les équipes avec un grand nombre d outils difficiles à mettre en œuvre, il y a déjà bien d autres problèmes que doivent régler les équipes sans rajouter celui-là. C est plutôt à la méthodologie de se diffuser dans les outils du quotidien. Ce qui peut être réalisé avec "Microsoft Visual Studio Team System"[B7]. Finalement, il est inutile de passer des mois à réfléchir sur la mise en place d une nouvelle méthodologie pour la PME. Il est plus utile d étudier les méthodologies existantes qui ont été réfléchies et qui ont mûri. Puis suite à cette étude, il est alors possible de concocter une méthodologie tenant compte des spécificités de la PME. En conclusion, le choix d une méthodologie utile à une PME se fait selon les critères suivants : Réactivité au changement Simplicité, facilité à prendre en main et à utiliser. Elle doit éviter les contraintes voir, si possible, elle doit les rend invisibles pour l équipe Intégrabilité du client Basée sur les individus et non pas sur le processus ou les outils Prise en charge par les outils du quotidien Adaptabilité à l entreprise 44 / 149

45 Définition d une méthodologie de développement Si une méthodologie répond parfaitement à ces critères, elle est tout simplement la plus à même pour permettre à l équipe de développement d atteindre le succès d un projet. Le Tableau 4 tiré du site [W137] fait un comparatif des méthodologies de développement : Type Cascade Semi-itératif Itératif Approche Approche en cascade dans le Totalement itérativeincrémentale avec une totalement première partie. Puis approche Explication cascade itérative-incrémentale pour la préphase d exploration Exemple Merise, SDM/S gestion des besoins RAD, RUP, DSDM Tableau 4 Types de Méthodologies et exemples XP, FDD, Crystal Le Tableau 5 tiré du site [W81] fait un comparatif des méthodologies agiles et du modèle en cascade : Cascade (WaterFall) Orienté planification Communications client épisodiques Livraison unique ( Big bang ), en général au bout de 9 à 12 mois Définition initiale et unique des exigences Développement multiphase (avec livraisons papier intermédiaires) Développement multicouche : présentation, persistance, métier, etc. Programmation = Construction Intégration des couches à l issue de la phase de construction Isolation des tests (essentiellement fonctionnels) en fin de projet Coûts de modification prohibitifs Développement agile Orienté apprentissage/expérience Communications client continues Cycle de livraison rapide et orienté métier le plus souvent possible Exigences juste à temps Développement et livraison de code opérationnel par itérations courtes Développement par tranches fonctionnelles complètes Programmation = Conception Intégration continue du code ( builds horaires) Tests automatisés et continus (fonctionnels et unitaires) Coûts de modification réduits Tableau 5 Comparaison agile vs cascade (Waterfall) 45 / 149

46 Définition d une méthodologie de développement 3.5 Quelques méthodologies agiles Ce chapitre permet de mettre en évidence quatre méthodologies agiles. La première, extreme Programming (XP), a été choisie car elle est tout simplement la méthodologie agile la plus connue. Quant à la méthodologie Unified Process (UP), elle est certainement la plus utilisée. MSF Agile est une méthodologie fournie avec l usine à logiciel de Microsoft. Et pour finir, Scrum est actuellement la méthodologie agile qui monte. Il existe bien évidemment un grand nombre d autres méthodologies agiles qui ne seront pas traitées ici. En effet, le but n étant pas d être exhaustif et de parler de toutes ces méthodologies mais plutôt de mettre en évidence celles qui sont les mieux adaptées ou les plus utilisées par les PME. Cependant les méthodologies suivantes méritent d être citée ; Rapid Application Development (RAD) [W122] qui est un précurseur des méthodologies agiles, Dynamic Software Development Method (DSDM) [W123], Feature-Driven Development (FDD) [W124], Crystal ou encore Adaptive Software Development (ASD) [W125]. Ce chapitre n a pas pour but de définir dans les détails toutes ces méthodologies mais plutôt de donner un aperçu global de leurs fonctionnements. La Figure 11, la Figure 12 et la Figure 13 permettent de situer ces méthodologies les unes par rapport aux autres. Figure 11 Méthodologies agiles en fonction de la taille du projet tirée de [W73] 46 / 149

47 Définition d une méthodologie de développement Figure 12 Méthodologies agiles en fonction des contraintes tirée de [W73] Figure 13 Méthodologies agiles en fonction des contraintes tirée de [W57] 47 / 149

48 Définition d une méthodologie de développement Unified Process (UP) and Rational Unified Process (RUP) RUP est l une des plus célèbres implémentations de la méthode UP. Cette introduction sera donc plus spécifique à RUP. De plus, d après une étude effectuée en 2005, RUP est à l heure actuelle la méthodologie de développement la plus utilisée (cf. Figure 14) Introduction Figure 14 Utilisation des méthodologies agiles tirée de [W52] RUP est une méthodologie de développement logiciel orienté objets qui est apparue en 1998 et peut être considérée comme un avatar de UP. Elle spécifie les activités à mener pour transformer les besoins d un utilisateur en système logiciel. Elle utilise UML (Unified Modeling Language) pour la création de différents diagrammes (plan de construction du système logiciel). Elle peut être considérée comme une méthodologie agile car elle est itérative et incrémentale et qu elle s adapte au changement. La Figure 15 retrace un petit historique de RUP. Figure 15 Historique de RUP tirée de [W83] 48 / 149

49 Définition d une méthodologie de développement RUP répond aux exigences fondamentales préconisées pas les créateurs d UML vis-à-vis d une méthodologie de développement logiciel : Guidée par les besoins des utilisateurs. Centrée sur l architecture. Itérative et incrémentale. RUP est conforme à UP et présente donc les caractéristiques suivantes, permettant de transformer les besoins utilisateurs en logiciel : UP est à base de composants. UP utilise UML. UP est piloté par les cas d utilisation. UP est centré sur l architecture. UP est itératif et incrémental Fonctionnement Le principe de RUP présenté en introduction définit grandement son fonctionnement. RUP est piloté par les cas d utilisation : Chaque besoin fonctionnel du client est exprimé par le développeur sous forme de diagrammes de cas d utilisation. Un cas d utilisation est une fonctionnalité du système produisant un résultat satisfaisant pour l utilisateur. L ensemble des diagrammes de cas d utilisation représente les fonctionnalités finales du système, ils sont la réponse à la question «Qu est censé faire le système?». C est à partir de ces cas d utilisation que va être guidé tout le reste du processus afin de garantir la cohérence avec les besoins des utilisateurs. RUP est centré sur l architecture : l architecture propose une vue globale de la conception faisant ressortir les caractéristiques essentielles en laissant de coté les détails secondaires. Tous les problèmes complexes sont réduis en systèmes plus petits, plus simples et modulaires (les composants) afin de garantir une maintenance et une évolution facilitées. L architecture complète du système est représentée par les différents diagrammes UML réalisés. RUP est itératif et incrémental : Comme les projets peuvent être grands, il est souvent intéressant de les découper en plusieurs parties qui sont autant de mini-projets. Chaque miniprojet représente une itération et produit un incrément (partie exécutable du système final). Chaque mini-projet est vu comme une itération car il regroupe toutes les principales étapes (cas d utilisation, analyse, conception, implémentation, tests). Ces itérations permettent de converger vers un système satisfaisant grâce au concept de feedback et d évolution des besoins défini par les méthodes agiles. 49 / 149

50 Définition d une méthodologie de développement Ces trois parties sont d égale importance. L architecture fournit la structure qui servira de cadre au travail effectué au cours des itérations, tandis que les cas d utilisation définissent les objectifs et orientent le travail de chaque itération. Il est possible d y ajouter une quatrième partie qui serait la conduite par les risques. En effet, dans RUP il est important d identifier les risques au plus tôt et surtout de les lever le plus rapidement possible. Les risques ont donc un impact direct sur l ordre des itérations. Les points précédents ont déterminé les parties principales de RUP. Son cycle de développement, allant de la naissance à la mort du logiciel, est découpé en cycles (versions du logiciel). Chaque cycle fait intervenir les trois phases suivantes : Elaboration, Construction, et Transition, la phase d Inspection étant réalisée préalablement. Chaque cycle est aussi découpé en itération comme précédemment décrit. La Figure 16 tirée du site [W89] montre approximativement l importance des différentes activités durant chaque phase. Figure 16 Utilisation des méthodologies agiles Inception : L inspection (initialisation) détermine en quelque sorte la «vision» du projet afin de décider de sa poursuite ou de son arrêt. Permet de déterminer en substance ce que va faire le système pour les utilisateurs (modèle simplifié des cas d utilisation), à quoi peut bien ressembler l architecture d un tel système ainsi qu une étude de rentabilité. Cette phase permet d identifier les risques majeurs, de planifier la phase d élaboration et d estimer approximativement le projet dans son ensemble. Elaboration : Description plus détaillé et complète des cas d utilisation et de l architecture du système (premier squelette ou prototype). A l issue de cette phase le projet dans son ensemble est estimé plus justement et les risques majeurs sont levés. 50 / 149

51 Définition d une méthodologie de développement Construction : Cette phase vise à développer le logiciel, à métamorphoser l architecture en un système complet en concevant, en implémentant et en testant l ensemble des éléments. Transition : Cette phase permet le passage de l application des mains des développeurs aux utilisateurs finaux en mettant en place la formation des utilisateurs, le déploiement ainsi que les béta-tests Evaluation Avantages Méthodologie Agile (tous les avantages de ce type de méthodologie). 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. Gestion des risques dans le projet (risque financier et de retard limité). Inconvénients Lourd, bureautique (mise à jour des schémas), rigoureux et couteux. Très axé processus, au détriment du développement : peu de place pour le code et la technologie. Vision non évidente ni immédiate. Projet de plus de dix personnes Conclusion RUP peut être considérée comme une méthodologie de développement agile car elle est itérative et incrémentale, qu elle se base sur les besoins des clients et qu elle est adaptive au changement. En revanche, RUP est une méthode nettement basée sur les processus et la documentation UML, ce qui a tendance à l alourdir. Cette méthode peut être intéressante pour de gros projets car elle spécifie absolument tout. Par contre, pour de petits projets, la rigueur et la documentation à outrance qu impose cette méthodologie n est pas adaptée. 51 / 149

52 Définition d une méthodologie de développement Extreme Programming (XP) Introduction Extreme Programming est une méthodologie proposée par Kent Beck dans les années 1990, avec l aide de Ward Cunningham et de Ron Jeffries. Elle est la méthodologie agile la plus connue. Elle regroupe un ensemble de bonnes pratiques de développement découlant des principes de l agilité et les poussent à l extrême. Elle vise en premier lieu à remettre le développeur et le client au centre du processus de développement. Elle est applicable pour des équipes de petite taille de l ordre d une douzaine de personnes. Elle semble de prime abord simple d utilisation mais elle réclame beaucoup de discipline et de communication Fonctionnement Elle repose sur les quatre principes du développement agile à savoir : la communication, le feedback, la simplicité et le courage. Il s agit dès lors d appliquer à l extrême les (les tests sont souvent regroupés sous une seule pratique) bonnes pratiques suivantes (découlant aussi des pratiques agiles) : Figure 17 Les pratiques d XP tirée de [W91] Les pratiques XP 1. Client sur le Site (Whole Team) : Les développeurs sont assistés par une personne dédiée qui est chargée de déterminer les besoins, fixer les priorités, rédiger les cahiers de recette et répondre aux questions des programmeurs. Cette personne dédiée doit se trouver sur le même site que les développeurs. 2. Séance de Planification (Planning Game) : Le client définit les scénarios utilisateurs. Les développeurs discutent le contenu de ces scénarios, définissent les tâches techniques sous-jacentes, estiment ces tâches (temps/effort) et y souscrivent. 52 / 149

53 Définition d une méthodologie de développement Le client choisi les scénarios prioritaires de façon à se focaliser uniquement sur les buts principaux à atteindre et différer les objectifs secondaires d une itération. 3. Intégration Continue (Continuous Integration) : Le système n est pas vu comme un bloc mais comme un système simple auquel s ajouteront de petits modules. Ces modules sont intégralement assemblés et testés une à plusieurs fois par jour. Ce qui rend le système stable et opérationnel plus rapidement. 4. Livraisons Fréquentes (Small Releases) : Le rythme des livraisons doit être le plus court possible ce qui permettra d accélérer le feedback du client en lui fournissant rapidement des fonctionnalités utilisables. Cette accélération du feedback va réduire au minimum les mésententes entre le client et les développeurs. Cela aura plusieurs effets positifs : accélération du développement, satisfaction du client car ses besoins sont enfin compris et augmentation de la motivation des développeurs. 5. Rythme Soutenable (Sustainable Pace) : L'équipe ne fait pas d'heures supplémentaires deux semaines de suite. Car un programmeur fatigué fait plus d erreurs. 6. Tests de Recette (Customer Tests) : Retours d'informations rapides sur le système, en général automatisé, constitué à partir de critères de tests définis par le client. 7. Basé sur les tests (Test-Driven Development) : Les tests sont écrits avant le code. En effet, ceci accélère le développement car cela force la concentration sur les interfaces, réduit les défauts et évite la régression (ensemble de tests unitaires). 8. Conception Simple (Simple Design) : L attention doit être mise sur les besoins actuels du client ni plus ni moins. Un acronyme anglais célèbre résume très bien cela «You Arent Gonna Need It (YAGNI)» qui signifie «tu ne vas pas en avoir besoin». Un travail propre, simple et minimal aujourd hui est facile à améliorer par la suite. Cette philosophie s applique aussi à la documentation. 9. Métaphore (Metaphor) : La métaphore est utilisée pour modéliser conceptuellement le système en cours de développement afin de clarifier les fonctionnalités à atteindre à l aide du vocabulaire du client. 10. Remaniement Continu de Codage (Refractoring): Le code étant en constante modification et n ayant pas de conception en amont, il doit être remanié constamment pour être propre sans modifier son comportement (Tests de non régression). 11. Convention de Code (Coding Standard) : Le code doit suivre une convention de nommage et de présentation afin d'être lisible par tous les membres de l'équipe. Cela dans le but de permettre le codage par paire et le partage de code. 53 / 149

54 Définition d une méthodologie de développement 12. Programmation En Binôme (Pair Programming) : Le code est toujours écrit par deux développeurs. Cela permet d avoir une relecture de code permanente et donc plus de qualité et de robustesse. Mais cela permet aussi une dynamique de projet, une motivation des développeurs accrue ainsi qu un partage et un transfert des connaissances. Les binômes changent au cours du projet. 13. Propriété Collective du Code (Collective Ownership) : Chaque développeur peut modifier chaque partie du code si le besoin s'en fait sentir. Les principes fondamentaux du fonctionnement de la méthodologie XP ayant été parcourus, la partie suivante montrera le cycle idéal d un développement utilisant XP. Le cycle de développement XP Les étapes principales du cycle de développement de la méthodologie XP peuvent être représentées par la figure suivante (un cycle plus détaillé est présent sur le site [W92]) : Figure 18 Etapes du cycle de développement XP Exploration : Cette phase permet au client d exprimer ses besoins à l aide de User Stories. Les User Stories sont de petites histoires simples, écrites dans le langage du client (Métaphore) et décrivant les fonctionnalités demandées sur des fiches. Un projet peut compter une centaine de User Stories. Planning : Dans cette phase, les développeurs estiment le coût de développement de chaque User Storie en utilisant un système de points. Puis le client choisit les User Stories qui seront développées pendant la prochaine itération en fonction du coût des User Stories, de la vélocité (nombre de points réalisables durant une itération) ainsi que de la valeur (priorité) qu attribue le client à chaque User Storie. Si une User Storie ne peut pas être estimée un Spike est créé. Ce Spike permet de définir plus clairement une User Storie. Une User Storie trop longue sera découpée. C est aussi durant cette période que le client définit les tests d acceptances. L itération : permet d implémenter les User Stories. D abord les binômes sont créés, puis les tests sont codés, le code est réorganisé pour intégrer les fonctionnalités issues des User Stories puis les fonctionnalités sont codées. C est la partie itérative et incrémentale principale de la méthodologie XP. A chaque itération, le processus de 54 / 149

55 Définition d une méthodologie de développement l étape planning est recommencé en tenant compte des informations retournées par l itération précédente. La Figure 19 montre les interactions entre les acteurs du développement XP ainsi que ce qu ils acquièrent durant le cycle de développement: Build value Customer Define value learn report Programmer facilitate Manager coordinate Programmer learn communicate Chose value Customer Estimate value Figure 19 Interaction et apprentissage en XP Evaluation Avantages Méthodologie Agile (tous les avantages de ce type de méthodologie). Relativement 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, Très bon pour le travail en équipe (motivation). Inconvénients Élude la phase d analyse, si bien qu on peut dépenser son énergie à faire et défaire. Acceptation difficile par les clients externes. Mise en œuvre assez dure (changement de mentalité, adaptation). Le refactoring est loin d être une technique simple. Difficile de fixer les prix et délais à l avance pour des fonctionnalités car elles ne sont pas disponibles directement. Adapté uniquement aux petites équipes. 55 / 149

56 Définition d une méthodologie de développement Conclusion Cette méthodologie peut paraître simple à mettre en place, mais elle nécessite la plupart du temps un changement de mentalité et une acceptation par l ensemble de l équipe impliquée (client compris). Elle n est pas évidente à appliquer et à maîtriser car elle réclame beaucoup de discipline et de communication. Mais elle est, dès que le processus est bien accepté et maîtrisé, une méthodologie très appréciée par l ensemble de l équipe pour la productivité accrue, la dynamique et la motivation qu elle apporte aux équipes. Elle reste la méthode agile la plus radicale (extrême). Mais elle permet la mise en place de projets de qualité grâce aux tests systématiques, en plus elle permet d être certain de coller aux besoins du client. 56 / 149

57 Définition d une méthodologie de développement Scrum Introduction Scrum est une méthodologie de développement logiciel mise au point dans les années 1990 par Ken Schwaber (un des créateurs de l agilemanifesto [W68]). Elle est principalement basée sur la gestion des ressources humaines et peut être adaptée à d autres contextes où il existe un besoin de travailler en équipe. Le terme Scrum signifie «mêlée» en anglais et vient du rugby, au moment où toute l équipe doit se souder pour atteindre un but (avancer avec le ballon). Scrum est une méthodologie de développement logiciel itérative et incrémentale, mais elle est plus basée pratique de management et n impose aucune pratique de développement comme le fait RUP. Scrum peut donc être vue comme le cadre de développement venant par exemple appuyer des pratiques XP. Pour mieux appréhender les notions de Scrum, voici un peu de vocabulaire : Product backlog : Liste regroupant les exigences du client. Ce référentiel évolue au cours du développement pour prendre en charge au mieux les besoins du client. Chaque exigence du client possède une priorité et un coût de développement qui permet de produire le Product burndown chart. Sprint backlog: Sprint : Scrum: Scrum Master : Product owner : Scrum Team : Liste des tâches à effectuer pendant un Sprint. Les items du product backlog affectés au sprint sont divisés en tâches appelées les Sprint item. Itération de trente jours (en théorie et deux à quatre semaines en pratique) durant laquelle l équipe développe le Sprint backlog. Réunion quotidienne de quinze minutes. Le but étant de faire le point sur ce qui a été fait, ce qu il reste à faire et les problèmes rencontrés. Facilitateur de projet Scrum. C est un membre de l équipe comme un autre (pas de hiérarchie) qui doit protéger l équipe des perturbations extérieures. Il doit permettre à l équipe de travailler de façon autonome et en s améliorant constamment. Mais il doit aussi veiller à ce que les valeurs de Scrum soient appliquées. C est le propriétaire du produit ou le client. Responsable de définir et de maintenir à jour le product backlog. Il détermine les priorités et prend les décisions concernant l orientation du projet. Représente tous les membres de l équipe sans distinction de fonction (développeur, architecte, ). L équipe est autonome et s autogère. Burndown chart : Représente graphiquement le travail restant à faire au fur et à mesure des Sprint ou au sein d un Sprint. 57 / 149

58 Définition d une méthodologie de développement Fonctionnement La Figure 20 tirée du site [W102] représente le fonctionnement de Scrum : Figure 20 Fonctionnement de Scrum Le principe de base de Scrum est de focaliser l équipe sur un ensemble de fonctionnalités à réaliser durant une itération appelée Sprint durant théoriquement trente jours mais dans la pratique plutôt deux à quatre semaines. Tout d abord, durant une phase de planification débutant le Sprint, le Product Owner ordonne en fonction de leurs priorités les exigences représentées par des items dans le Product backlog. Ensuite, toujours dans la phase de planification, la Scrum Team estime ces exigences en points et détermine quels sont les exigences qui feront partie du Sprint. La première phase de planification est ainsi achevée et elle a permis au Product Owner et à la Scrum Team de définir le périmètre du Sprint. Une deuxième phase de planification permettra à la Scrum Team de décomposer les items choisis en tâches formant la Sprint backlog. La phase de planification du Sprint étant finie il est temps de passer à l exécution du Sprint. Durant cette exécution, une Scrum (réunion) à lieu quotidiennement pour contrôler le bon déroulement. La Scrum Team développe le logiciel, sans que la méthodologie Scrum ne lui impose aucun processus. Il est par exemple possible ici d y intégrer les bonnes pratiques de XP. Durant le Sprint, le client est entièrement intégré et peut en tout temps modifier le product backlog mais il ne peut pas modifier ce qui est en cours de développement (Sprint backlog). Un membre de l équipe appelé le Scrum master s assure que durant un Sprint l équipe de développement ne soit pas touchée par les perturbations extérieures. De plus, il détermine grâce au Scrum quotidien l avancement du Sprint et l ajuste (modifie le Backlog de Sprint avec l accord du Product Owner) pour assurer le succès du Sprint. Pour finir, un Sprint aboutit toujours à la livraison d une version fonctionnelle du produit potentiellement utilisable. Une revue de Sprint a lieu la fin de celui-ci afin de montrer au Product Owner le produit réalisé. Suite à cette revue de Sprint la Scrum Team effectue une rétrospéctive pour faire un bilan du sprint qui se termine. 58 / 149

59 Définition d une méthodologie de développement Evaluation Avantages Avantage des méthodes agiles (itération, changement, équipe, ). Vision rugby (chaque match est différent et chaque logiciel développé également). Pas de distinction des rôles au sein du Scrum Team. Ce qui est souvent le cas dans une PME. Indépendant des activités d ingénierie (on peut par exemple utiliser XP). Faire confiance à l équipe en l isolant durant le Sprint et en la rendant autogérée. Equipes soudées. Les règles de Scrum favorisent l esprit d équipe. Réunion journalière (état d avancement, partage du savoir, ). Inconvénients Une préphase de création du Product backlog doit être mise en place. Le temps d un Sprint doit être proportionnel au projet et non pas figé à trente jours, mais fixe pour un projet donné. Il faut un système d intégration des éléments perturbateurs. Prise en compte au sein du Sprint de modifications urgentes Conclusion L avantage de Scrum par rapport aux autres méthodologies de développement logiciel est qu elle s intéresse plutôt à l organisation du projet qu aux aspects techniques. Elle peut donc être couplée avec une méthodologie telle que XP pour prendre en compte tous les aspects. De plus, sa vision rugby est bien adaptée au développement logiciel où l équipe doit avancer ensemble vers un but commun. Certains aspects doivent néanmoins être adaptés et non pas simplement pris à la lettre pour rendre Scrum utilisable. Principalement le temps d un Sprint ne doit pas être d exactement un mois mais il doit être adapté au projet. 59 / 149

60 Définition d une méthodologie de développement MSF Agile Introduction Microsoft offre par défaut deux méthodologies de développement logiciel dans Microsoft Visual Studio Team System. L une d entre elles est MSF Agile. Ces méthodologies sont issues du Microsoft Solutions Framework (MSF) qui est un regroupement de principes, de modèles, de concepts et de lignes directrices pour la conception d'applications [W114] Fonctionnement La méthodologie MSF Agile est basée sur trois concepts principaux : les workitems, les rôles et les itérations. workitems Les workitems représentent toute opération élémentaire induite au projet. Ils permettent un suivi de l assignation et de l état du projet. Les workitems définis par la méthodologie MSF Agile sont de cinq type différents : Scénarios : Permet de décrire le déroulement d une interaction entre l utilisateur et le système. Son cycle de vie est composé des trois états (actif, résolu, fermé). Il est actif lors de sa création par l analyste métier ainsi que pendant le développement. Le responsable du développement le passe à l état résolu dans les cas suivants : Son développement est terminé et il est alors affecté à un testeur. On doit le fractionner car il est trop volumineux. On doit le différer à l itération suivante. Il est supprimé car cette fonctionnalité n est plus utile. Le scénario peut alors passer de résolu à fermé lorsque le testeur indique que les tests ont été correctement passés. Si les tests ne sont pas correctement passés, il repasse dans l état Actif. Ces différentes transitions sont définies dans le schéma suivant : 60 / 149

61 Définition d une méthodologie de développement Figure 21 Etat Transition d un sénario MSF Agile Cette figure est tirée du «Process Guidance» de Team System. Qualité : Les impératifs de qualité de service documentent les caractéristiques impératives des qualités du système telles que les performances, la charge, la disponibilité, les contraintes, l accessibilité ou encore la facilité de maintenance. Ils prennent généralement la forme de contrainte sur la manière dont le système doit fonctionner. Son cycle de vie est composé des trois mêmes états que le cycle d un scénario. De plus, les transitions sont les mêmes hormis le fait qu il n est pas possible de fractionner un impératif de qualité. Voici le schéma des transitions entre les états: Figure 22 Etat Transition d un impératif de qualité MSF Agile Cette figure est tirée du «Process Guidance» de Team System. Tâches : Détermine un travail à effectuer. Elle peut donc représenter beaucoup de choses comme par exemple une tâche de développement pour assigner à un développeur un travail découlant d un scénario, une tâche de test pour l écriture et l exécution d un test par le testeur Son cycle de vie est composé des deux états (actif, fermé). Elle est active lors de sa création ainsi que pendant sa réalisation. Elle passe à l état fermée dans les cas suivants : Lorsqu il n y a plus de travail à effectuer (Terminé). 61 / 149

62 Définition d une méthodologie de développement On doit le différer à l itération suivante. Lorsque le travail effectué pour cette tâche devient obsolète pour le produit global. Il est supprimé car cette fonctionnalité n est plus utile. Une tâche peut être réactivée suite à une modification de ses fonctionnalités. Voici le schéma des transitions entre les états: Figure 23 Etat Transition d une tâche MSF Agile Cette figure est tirée du «Process Guidance» de Team System. Bug : Permet de définir un problème découvert dans le système. Son cycle de vie est composé des trois états (actif, résolut, fermé). Il est actif lors de sa découverte ainsi que durant son traitement. Il passe à l état fermé dans les cas suivants : Lorsque celui-ci est corrigé. Si ce n est pas un bug et que cela correspond aux spécifications. On doit le différer à l itération suivante. Lorsque ce bug est la duplication d un bug existant. Si le problème n est plus applicable au produit (obsolète). S il est impossible à reproduire. Un Bug peut repasser de l état résolu à l état actif dans les conditions suivantes: La résolution n est pas acceptable. Le bug n est pas corrigé. Un test prouve que le bug existe toujours. Il passe néanmoins de l état résolu à l état fermé dans les conditions suivantes: La résolution est en place dans un build (corrigé). L auteur reconnaît que le bug décrit quelque chose de prévu dans la conception. Si l auteur accepte que le bug soit différé ou qu il est obsolète, dupliqué ou encore impossible à reproduire. 62 / 149

63 Définition d une méthodologie de développement Un bug peut être réactivé s il y a eu un problème de régression du système (un test indique que le bug existe à nouveau). Voici le schéma des transitions entre les états: Figure 24 Etat Transition d un Bug MSF Agile Cette figure est tirée du «Process Guidance» de Team System. Risque : Un risque représente n importe quel élément susceptible d avoir un impact négatif sur le projet. Son cycle de vie est composé des deux états (actif, fermé). Il est actif dès son identification. Il passe à l état fermé dans les cas suivants : Lorsque sa survenue ou que son impact a été atténué à un niveau acceptable. Lorsque sa probabilité d apparition est négligeable (inactif). Lorsque le risque a été transféré (par exemple à un consultant externe). Lorsque le risque ne peut pas être annulé mais qu il est accepté. Lorsque le risque a été évité. Un risque peut néanmoins être réactivé dans une itération suivante. Voici le schéma des transitions entre les états: Figure 25 Etat Transition d un Risque MSF Agile Cette figure est tirée du «Process Guidance» de Team System. 63 / 149

64 Définition d une méthodologie de développement Grâce à ces workitems, il est possible de générer des rapports répondant aux questions relatives à l état du projet. Pour que ces rapports soient pertinents, il faut bien comprendre et gérer les différents types de workitems. Il est par exemple possible de générer des rapports de qualité ou des rapports quantitatifs comme ceux-ci : Figure 26 Rapport d avancement quantitatif MSF Agile Cette figure est tirée du «Process Guidance» de Team System. Figure 27 Rapport d avancement qualitatif MSF Agile Cette figure est tirée du «Process Guidance» de Team System. Rôles La méthodologie MSF Agile met l accent sur les membres de l équipe de développement. Elle définit pour cela six groupes d utilisateurs qui ont chacun leurs propres responsabilités mais ont tous la même importance. 64 / 149

65 Définition d une méthodologie de développement Analyste métier : Il a pour but principal de définir les scénarios et les impératifs de qualité de l application en accord avec la vision du client. Il représente l expérience de l utilisateur et défend les intérêts des commanditaires du projet. Chef de projet : Architecte : Développeur : Testeur : Livreur : Il a pour but de superviser la création d une application ayant une valeur commerciale en respectant l agenda et le budget convenus. Il établit les tâches, planifie les scénarios présents dans les itérations, contrôle l avancement du projet. Il doit garantir le succès en concevant les fondations de l application. Son but est de réduire la complexité en divisant le système en sous-systèmes simples. Il doit entre autre déterminer les interfaces, créer un prototype architectural, Il doit implémenter l application en respectant les délais. Il doit aussi estimer le temps et l effort nécessaire à la réalisation de chaque fonctionnalité. Il doit déterminer les problèmes pouvant avoir un impact négatif sur la valeur du produit. Il doit découvrir et signaler les bugs, il est en quelque sorte le garant de la qualité du produit. Le responsable de la livraison doit gérer la livraison et le déploiement du produit. Itérations MSF Agile est une méthodologie de développement itérative et incrémentale. Elle définit un certain nombre de cycles au sein desquels les phases de définition des besoins, de développement et de test sont réalisées : Lors de l utilisation de la méthodologie MSF Agile au sein de Team System, la première itération contient déjà un certain nombre de tâches d administration (choix de l équipe, mail aux utilisateurs, énoncé de vision, description de projet, déterminer la durée d itération, 65 / 149

66 Définition d une méthodologie de développement explorer et classer par priorité la liste des scénarios et des impératifs de qualité, créer la structure du projet, créer un plan d itération). Par la suite, un certain nombre de flux de travail définis dans le document de Processus Guidance sont suivis. Typiquement l analyste métier va suivre le flux de travail «Extraire la vision du projet» tandis que le chef de projet suivra le flux de travail «Planifier la première itération». Ces flux de travail en entraîneront d autres et le projet sera alors commencé Evaluation Avantages Méthodologie Agile (tous les avantages de ce type de méthodologie). Son intégration dans Team System. Sa bonne documentation dans Team System. Inconvénients Sa compréhension qui n est pas vraiment évidente. A priori, toute la marche à suivre est décrite. Cependant, le cycle de développement n est pas clair Conclusion MSF Agile est la méthodologie de développement agile présente par défaut dans Team System. Elle est assez simple à prendre en main dès que les principes de rôle et de workitems ont été assimilés. Elle est bien détaillée dans le document de Process Guidance et permettra à chaque intervenant du projet de rapidement se mettre en place. Elle définit un certain nombre de flux de travail pour chaque rôle, ces flux sont divisés en activités qui sont décrites dans le Process Guidance. Le Process Guidance décrit aussi les éléments de travail, les produits de travail (diagramme et documentation) ainsi que les différents rapports et requêtes accessibles. Cette méthodologie semble être un bon début à l agilité avec Team System. 66 / 149

67 Définition d une méthodologie de développement 3.6 Comparaison des méthodes vues Toutes les méthodologies de développement agile vues dans le chapitre 3.5 Quelques méthodologies agiles ont comme valeur commune l agilité. Cela signifie que toutes ces méthodologies intègrent les douze principes généraux de l agilité (cf. chapitre Méthodologie de développement agile). Mais elles ont quand même des différences qui poussent à choisir une méthodologie plutôt qu un autre. Tout d abord elles ont une complexité de compréhension et de mise en œuvre très variée. Allant de la méthode la plus difficile RUP à la méthode la plus simple Scrum. Elles ont aussi des niveaux de spécification variés. RUP vise à tout définir, le cycle de développement mais aussi les documents créés (UML) ; ce qui devient assez rapidement lourd et donc pousse les utilisateurs à ne plus suivre la méthodologie. Il y aussi MSF Agile qui définit très clairement le processus, mais cette méthodologie est tout de même un peu excessive. Le niveau d implication dans le développement est aussi différent, RUP s implique à la fois dans la partie management (cycle, phase, itération, ) et dans la partie pratique de développement (modélisation, conception, développement, test), tandis que XP est plus basée sur la pratique de développement et que Scrum s oriente vers le management. Tout cela nous amène à dire qu il est difficile de faire un choix entre ces méthodologies. Il n y a à l heure actuelle, et il n y aura sûrement jamais, une bonne méthodologie. Elles ont toutes leurs avantages et leurs inconvénients. Néanmoins, le choix d une méthodologie pour une PME doit se référer à un certain nombre de critères mis en évidence dans le Tableau 3 Faire le choix entre les modèles adaptatif et prédictif. Le Tableau 6 représente un comparatif des méthodologies étudiées en fonction des critères du Tableau 3. RUP XP Scrum MSF Agile Réactivité au changement. Bon Bon Moyen Bon Simple et facile à prendre en main et à utiliser. Evite les contraintes voir si Mauvais Moyen Bon Moyen possible invisible pour l équipe. Intégration du client Bon Bon Bon Bon Basée sur les individus et non pas sur le processus ou les outils Moyen Bon Bon Moyen/Bon Les outils quotidiens doivent prendre en charge la méthodologie (MVSTS) Bon Moyen Bon Bon Adaptable à l entreprise Moyen Moyen/Bon Bon Moyen Tableau 6 Comparatif de XP, RUP, MSF Agile et Scrum Ce tableau est bien évidemment très subjectif et découle d une impression personnelle vis-àvis de ces méthodologies. 67 / 149

68 Définition d une méthodologie de développement 3.7 Méthodologie définie pour InfoTeam Introduction Suite à l état de l art décris dans les chapitres précédents, il est clair que la méthodologie de développement logiciel la mieux adaptée à une PME se doit d être agile. InfoTeam utilise actuellement plusieurs méthodologies, mais cette entreprise est désireuse de connaître leurs évolutions afin d intégrer les concepts les mieux adaptés à son domaine. Les attentes d InfoTeam envers une méthodologie sont basées sur les points suivants : Simplicité/souplesse : La méthodologie définie doit être simple et souple. Elle doit être simple pour garantir son utilisation sachant qu une méthodologie compliquée et rigide ne sera sûrement pas appliquée. Elle doit être souple pour s adapter aux habitues de l entreprise mais aussi des clients (la taille des projets, les unités d InfoTeam, ). Suivi de l avancement : Elle doit permettre une visualisation de l avancement technique du projet. Afin d être plus à même de gérer les dépassements de délai, ou tout du moins de faciliter leurs détection. Tout cela sans avoir à rajouter une importante charge de travail aux membres de l équipe. Si possible une interaction avec la BD de gestion d affaire existante serait intéressante. Contrat de type forfaitaire : La méthodologie doit être en accord avec le type des contrats de rémunération d InfoTeam qui veut que dans plus de 90% des cas, les projets d InfoTeam utilisent le système à forfait. Prise en compte des tests : La méthodologie doit mettre l accent sur la mise en place d un processus de test clairement défini. Adapté aux habitudes : C est à la méthodologie à s adapter aux habitudes de développement de l entreprise et non pas l inverse. Orienté besoins du client : La méthodologie doit orienter le travail vers un résultat conforme aux demandes du client plutôt que de la documentation, des études de cas, qui seront, dans la plupart des cas, inutiles pour le client. Orienté qualité : La méthodologie doit permettre la création de logiciel de qualité. Les attentes d InfoTeam ne sont de loin pas en contradiction avec les fondements de l agilité, elles regroupent même les principes fondamentaux de l agilité. Il reste néanmoins à trouver une méthodologie agile qui accepte les contrats de type forfaitaire. 68 / 149

69 Définition d une méthodologie de développement Quelle méthodologie agile Il est possible de partir de rien pour réaliser la méthodologie qui sera la mieux adaptée à InfoTeam. Cependant, il semble plus judicieux de s inspirer de l existant. D une part car il n est quasiment jamais judicieux de réinventer la roue. Et d autre part, les méthodes existantes bien que relativement modernes ont été suffisamment éprouvées pour être plus satisfaisantes. A partir des connaissances acquises suite à l état de l art des méthodologies de développement logiciel (cf. 3.2 Etat de l art des méthodologies de développement), la méthodologie qui me semble la plus à même de répondre aux besoins d InfoTeam résulte d un mélange entre Scrum (cf Scrum) et extreme Programming (cf Extreme Programming (XP)) Scrum sera utilisé comme cadre général pour la méthodologie dédiée à InfoTeam. Le choix de Scrum est en partie dû à sa simplicité qui en fait une méthodologie facile à comprendre et peu contraignante. De plus, Scrum offre une excellente vision sur le management de projet. XP sera utilisé comme cœur de la méthodologie plus basée sur les techniques de développement pures. En effet, Scrum étant un cadre général de management de projet, il est intéressant de lui appliquer les bonnes pratiques de développement définies dans XP. La méthodologie définie pour InfoTeam n appliquera pas XP à la lettre car cela serait trop contraignant. Par contre, elle utilisera un sous ensemble des bonnes pratiques décrites dans XP sans les pousser à l extrême. Cette utilisation des pratiques d XP sera à adapter à la taille du projet, la taille de l équipe, le domaine de développement, ainsi qu aux contraintes et exigences du client Fonctionnement de base La Figure 28 représente le fonctionnement de Scrum: Figure 28 Fonctionnement de Scrum [W104] Tous les composants de Scrum ainsi que les avantages de son utilisation seront introduits dans les chapitres suivants. 69 / 149

70 Définition d une méthodologie de développement Le «Product Backlog» correspond aux besoins du client (fonctionnels et non-fonctionnels). Il n est déterminé qu après avoir réalisé toutes les étapes précédant le chapitre «Validation de la prise en main d un mandat» décrit dans le Manuel qualité d InfoTeam [B17]. Il faut donc avoir déjà réalisé une offre, reçu une commande, avoir initialisé le mandat et avoir mis en place le cahier des charges. Ce cahier des charges devra être aussi précis que possible pour éviter d avoir des malentendus avec le client sur les fonctionnalités, les délais et le coût. La première version du «Product Backlog» sera déterminée en prenant les exigences décrites dans le cahier des charges. Le principe de base de Scrum est de focaliser l équipe sur un ensemble de tâches à réaliser «Sprint Backlog» durant une itération appelée «Sprint» durant théoriquement 30 jours. Dans la pratique ces itérations ont une durée de l ordre de 2 à 4 semaines. Pour déterminer la durée d un «Sprint» des critères tels que la taille de l équipe et celle du projet seront pris en compte. Dès que la durée du «Sprint» est déterminée, elle reste inchangée pour toute la durée du projet. Ce qui permet d avoir des dates d échéance précises et stables. Comme dans la plupart des cas, il y aura plusieurs itérations, seulement un certain nombre d items du «Product Backlog» seront considérés durant une itération. Ces items du «Product Backlog» choisi pour le «Sprint» seront découpés en tâches. Ces tâches devront être assez simplifiées pour être réalisables en quelques heures. Cela permettra d améliorer empiriquement les estimations. L expérience a montré qu une tâche nécessitant plus de deux jours de travail n est que très rarement estimée correctement. Le regroupement de ces tâches représente le «Sprint Backlog» de la Figure 28. Le «Sprint» aboutit à un «produit partiellement utilisable». Cela signifie que toutes les parties de la réalisation, des tests et de la documentation doivent être réalisées durant le «Sprint». Toutes ces parties doivent donc se retrouver dans le «Sprint Backlog» introduit précédemment. Pour garantir une bonne communication au sein de l équipe, une petite réunion quotidienne la «Scrum Meeting» sera réalisée. Cette réunion d une quinzaine de minutes permettra d informer l ensemble de l équipe de l avancement global du projet ainsi que des problèmes rencontrés. Le «produit partiellement utilisable» sera évalué à la fin du «Sprint» par une démonstration au client et éventuellement une livraison à quelques clients. Ces étapes (définition du «Sprint Backlog», réalisation du «Sprint» et de la démonstration) sont réitérées jusqu à l obtention de la satisfaction du client qui, en règle générale, coïncidera avec un «Product Backlog» vide. 70 / 149

71 Définition d une méthodologie de développement Apports au fonctionnement de base Le fonctionnement de base de la méthodologie proposée et très similaire à Scrum. Néanmoins un certain nombre d améliorations et d adaptations ont été réalisés pour rendre cette méthodologie applicable par InfoTeam. En effet, le descriptif détaillé fournit à InfoTeam comprend pas moins de 24 conseils d utilisation et 14 compléments d informations sur les besoins que cette méthodologie couvre. Pour ne pas être en conflit avec le NDA (Non-disclosure agreement) signé entre l université de Fribourg et l entreprise InfoTeam, il ne m est pas possible de citer toutes les adaptations réalisées. Cependant je vais tout de même en présenter trois Planning Poker La première adaptation est relative à la planification du projet. La planification du projet est souvent la phase critique d un projet. En effet, durant cette phase l estimation du temps et des ressources nécessaires à l élaboration du projet est réalisée. Cette estimation est ensuite présentée au client sous forme d offre. Le point critique de cette phase est clairement le fait que l estimation n est pas toujours exacte. Si elle était trop petite, les frais de dépassement seront à la charge de l entreprise et le client sera mécontent d attendre une solution qui lui avait été promise en un temps plus court. Le cas de figure inverse, à savoir une estimation trop grande, n engendre aucun problème. Malheureusement ce cas de figure n arrive quasiment jamais. En effet, on essaie dans la pratique de faire au plus juste pour ne pas se faire prendre le contrat par un concurrent. L estimation est donc une tâche difficile et qui demande de l expérience. Pour réduire les risques d une mauvaise estimation une pratique dite de planning poker a été proposée. Cette pratique part du principe selon lequel la personne qui va réaliser le projet est la plus à même d estimer le temps que cela lui prendra. De plus, cette pratique part du principe que plus il y a d avis plus l estimation sera juste. Mais il ne faut pas non plus tomber dans l extrême et perdre du temps en faisant les estimations. Une estimation n est bonne uniquement si elle n a pas fait perdre de temps à l équipe et qu elle est le plus proche possible de la réalité. Le déroulement du planning poker est le suivant. L ensemble de l équipe se réuni pour réaliser un petit jeu d estimation. Chaque membre de l équipe dispose d une main de carte représentant les valeurs possibles pour l estimation des items du Product Backlog. Le Scrum Master explique l item du Product Backlog (une des exigences du client). Une petite discussion a lieu si le besoin n est pas compris. Chaque membre de l équipe dépose face cachée sur la table la carte représentant son estimation de l exigence. Ensuite toutes les cartes sont retournées en même temps. S il n y a pas un compromis immédiat, la personne dont l estimation est la plus faible et à la personne dont l estimation est la plus forte expriment 71 / 149

72 Définition d une méthodologie de développement leurs points de vue. Si un compromis est rapidement trouvé, la valeur issue de celui-ci est utilisée sinon la valeur la plus grande est prise en compte. Pour faciliter ces estimations, un compromis est réalisé sur une exigence du client de taille moyenne. Afin de parfaire la technique de planning poker, une estimation par analogie y sera intégrée. A la fin de l estimation d une exigence, celle-ci sera collée sur un tableau dans la colonne correspondante à son estimation. Cela permettra aux membres de l équipe d estimer par analogie les exigences suivantes Prise en compte d un bug Souvent lors du développement d une solution s étalant sur plusieurs versions, les versions suivantes prennent en compte des améliorations et des ajouts. Mais comme dans la plupart des produits informatiques, leurs utilisations quotidiennes mettent en évidence certains défauts non détectés durant le développement. Ces défauts couramment appelés bugs doivent la plupart du temps être résolus le plus rapidement possible. En effet, dès qu un problème mineur est décelé par un utilisateur il devient subitement son centre d intérêt et celui-ci n est donc plus à même d utiliser les autres fonctionnalités du système. Pour palier à ce problème et dans le but de répondre le plus rapidement possible aux exigences des clients, il est fréquent de voir dans les planifications une marge réservée à la correction des bugs de la version précédente. Cette marge part d une bonne intention mais elle pose deux problèmes majeurs. Le premier vient lorsque cette marge n est pas assez importante car un grand nombre de défauts son découverts. A ce moment là, il n est pas possible de les corriger tous, ce qui entraîne inévitablement la non-satisfaction du client. Ou alors des ressources supplémentaires sont engagées pour la correction de ces bugs ce qui provoquera inévitablement des coûts supplémentaires. Le deuxième problème intervient dans la situation inverse. A savoir la surestimation de cette marge. Cela ne semble pas poser de problème, mais en regardant de plus près on s apercevra que lorsque cette marge est surestimée, le temps prévu pour la correction des bugs est gaspillé en travail inutile ou encore pire pour l employeur en inactivité. Pour prendre en compte ces bugs dans la méthodologie aucune marge ne sera définie afin d éviter les problèmes précédemment cités. Mais lorsque un bug est découvert les étapes suivantes devront être réalisées : 1. Le Scrum Master réunit l équipe pour estimer la prise en compte du bug. Cette estimation est réalisée de la même manière identique à l estimation d un item du Product Backlog (Planning Poker). 72 / 149

73 Définition d une méthodologie de développement 2. Le Scrum Master communique ces informations au Product Owner. 3. Si le Product Owner veut que l équipe prenne en compte le bug durant le Sprint, il retire des items non commencés du Sprint Backlog pour un nombre de points équivalent à l estimation du bug. Sinon le bug ne sera pris en compte que lors d un Sprint suivant. Cette technique apporte plusieurs avantages. Le premier incombe au fait que les estimations sont les plus proches possible de la réalité et n intègrent pas des marges aléatoires. Les problèmes précédemment cités n ont plus lieu d être. Et pour finir, le client ne se focalise plus sur des petits détails fonctionnels mais réellement sur les aspects qui ont un véritable intérêt pour lui. Cette opération doit néanmoins être réalisée uniquement pour des bugs urgents, car elle aura indéniablement une répercussion négative sur la vélocité de l équipe et donc sur les fonctionnalités livrées à la fin du Sprint Scrum meeting La pratique de Scrum étant à mon sens la plus importante est le Scrum Meeting. Il s agit d une petite réunion quotidienne avec tous les membres du projet afin de contrôler le bon déroulement de celui-ci. Cela permet à tous les membres d avoir une vision globale du projet et d exprimer leurs travails et leurs problèmes. Ce qui a indéniablement un effet positif sur l esprit d équipe et sur la motivation du projet. Pourtant cette pratique n est pas facile à mettre en œuvre, car pour être optimale cette réunion doit se dérouler tous les jours avec tous les membres de l équipe et en peu de temps. Afin de faciliter cette pratique quelques petits conseils ont été introduits à Scrum. Tout d abord, le Scrum Master fait office d animateur de la séance. Il aura comme rôle de poser les trois questions suivantes à chaque membre de l équipe : 1. Qu as-tu fait depuis la dernière fois? 2. Que prévois-tu de faire jusqu à la prochaine réunion? 3. Qu est-ce qui pourrait t empêcher d y arriver? Il devra dès lors éviter que la réponse à ces questions ne parte en débat. En effet, lors d un Scrum meeting uniquement la personne à laquelle le Scrum Master a posé les questions est autorisée à parler. Afin de faciliter cette approche, l utilisation d une mascotte a été proposée. Cette mascotte est passée d un membre de l équipe à l autre au fur et à mesure de l avancement de la réunion. Cette pratique assez ludique tend à améliorer l ambiance au sein de l équipe. 73 / 149

74 Définition d une méthodologie de développement Une autre pratique proposée afin de faciliter le déroulement de ce meeting est l utilisation d un tableau. Ce tableau servant d appui visuel sur lequel toutes les tâches du Sprint sont réparties en différentes catégories. Lors de son tour de parole, le membre de l équipe déplace les post-it représentant les tâches pour lesquels il est en train de réaliser du travail. Cela est assez intéressent car cela permet de faire remarquer que lors de l utilisation de cette méthodologie les tâches ne sont pas forcément imposées aux membres de l équipe mais ceux-ci les choisissent pendant le Scrum Meeting Conclusion Comme précisé précédemment il reste encore 11 autres conseils d utilisation qui ont été prescris dans la méthodologie de développement proposée à InfoTeam. De plus, InfoTeam peut tirer les avantages suivants de l utilisation de cette méthodologie : Adaptée aux exigences : Motivation : Qualité : Risques : Les exigences du client sont réellement prises en compte et le prototype développé répond effectivement à ces exigences. La méthodologie est agile et donc basée sur les individus plus que sur le processus lui-même ce qui a comme conséquence directe un accroissement de la motivation de l équipe. De plus, un certain nombre de concepts tels que le planning poker sont bien adaptés à renforcer l attrait de la méthodologie et donc l envie de l équipe. L introduction de concepts tels que les tests unitaires, l intégration continue, le refractoring aide à améliorer la qualité des solutions développées. Le développement incrémental ainsi que les graphiques de suivi d avancement permettent la réduction des risques. Enfin, la méthodologie réalisée pour InfoTeam répond à tous les besoins cités dans le point d introduction. 74 / 149

75 Définition de la procédure de test 4. Définition de la procédure de test A test that reveals a bug has succeeded, not failed. Boris Beizer 75 / 149

76 Définition de la procédure de test 4.1 Introduction Tout d abord commençons par une petite définition [B6]: Test n. m. (Anglicisme). 3. Épreuve, expérience qui permet de se faire une opinion sur quelqu un, sur quelque chose. Dans le cas plus concret du développement logiciel, les tests sont l étape du cycle de développement logiciel qui permet d atteindre un certain niveau de qualité. Voici quelques définitions spécifiques au domaine du logiciel : «Le test est l exécution ou l évaluation d un système ou d un composant par des moyens automatiques ou manuels, pour vérifier qu il répond à ses spécifications ou identifier les différences entre les résultats attendus et les résultats obtenus.» [B13] «Tester, c est exécuter le programme dans l intention d y trouver des anomalies ou des défauts.» [B14] «Testing can reveal the presence of errors but never their absence.» [B11] «Le processus de test consiste en une collection d activités qui visent à démontrer la conformité d un programme par rapport à sa spécification. Ces activités se basent sur une sélection systématique des cas de test et l exécution des segments et des chemins du programme.» [B15] «L objectif du processus de test est limité à la détection d éventuelles erreurs d un programme. Tous les efforts de localisation et de correction d erreurs sont classés comme des tâches de débogage. Ces tâches dépassent l objectif des tests. Le processus de test est donc une activité de détection d erreurs, tandis que le débogage est une activité plus difficile consistant en la localisation et la correction des erreurs détectées.» [B16] Il n existe pas réellement de processus de test clairement défini en tant que tel. Le plus souvent, le processus du test n est rien d autre qu une sous-partie de la méthodologie de développement logiciel. Par exemple, la méthodologie Rational Unified Process (RUP)[W148] définit un certain nombre de documents pour les tests. D autres méthodologies telles que Extreme Programming (XP)[W149] sont grandement basées sur les tests. En effet, la méthodologie XP introduit le concept de Test-Diven Development (TDD)[W151]. Le TDD consiste en l écriture des tests avant de réaliser le code lui-même. En conséquence, les processus de test ne sont rien d autre qu un principe découlant du cycle de développement logiciel. De plus, ils sont spécifiques à la méthodologie utilisée. Ils doivent être vus comme un processus d investigation plutôt que le suivi d une procédure. 76 / 149

77 Définition de la procédure de test Cependant, indépendamment de la méthodologie de développement utilisée, le concept de Validation/Vérification (V&V) revient sans cesse dans le domaine des tests logiciel. D autres concepts sont aussi souvent cités tels que les tests unitaires, les tests d intégration, les tests du système, les analyses statiques, les analyses dynamiques, les tests boîtes noires, les tests boîtes blanches, Les tests étant sans conteste une partie primordiale du développement logiciel, ces concepts seront approfondis dans les chapitres suivants. Les tests peuvent avoir deux intérêts distincts ; la mise en évidence d un problème ou l information vis-à-vis d une des métriques suivantes : Utilisabilité : Aptitude du logiciel à être compris, appris, utilisé et attrayant par/pour les utilisateurs. Compatibilité : Aptitude du logiciel à pouvoir être combiné à d autres logiciels. Maintenabilité : Aptitude du logiciel à être facilement modifié. Portabilité : Facilité d un logiciel à être porté sur de nouveaux environnements matériels et/ou logiciels. Efficacité : Aptitude du logiciel à bien utiliser les ressources matérielles (mémoire, CPU, devices). Robustesse : Aptitude du logiciel à rester fonctionnel même dans des conditions anormales extrêmes. Fonctionnalité : Aptitude du logiciel à fournir des fonctions qui répondent à des besoins explicites ou implicites. Réutilisabilité : Aptitude du logiciel et de ses composants à être réutilisés pour de nouvelles applications. Un test est donc réussi, s il découvre une erreur ou s il informe sur une des métriques précédemment citées. Souvent lors du développement logiciel uniquement une sous partie de ces métriques est prise en compte. Finalement, les tests permettent de mettre à jour des erreurs, mais malheureusement ils ne permettent pas d affirmer qu il n y a pas d erreur. De plus, ils ne localisent et ne résolvent pas non plus les problèmes découverts, cela étant fait dans une étape de débogage. 77 / 149

78 Définition de la procédure de test 4.2 Etat de l art des procédures de test Comme introduit précédemment, les processus de tests sont souvent dépendants de la méthodologie de développement logiciel. Ce document ne produira donc pas un descriptif des processus de tests mais plutôt des principes qui sont inclus ou issus de ces processus. Il est aussi nécessaire de préciser que les processus de tests mis en œuvre lors d un développement logiciel ne servent qu à déterminer d éventuelles erreurs. En aucun cas, le processus de test ne corrigera l erreur. De plus, le test d un programme permet de mettre en évidence un éventuel bug, mais il ne permet pas de prouver l absence de bug. En effet, il est pratiquement impossible de vérifier tous les cas d utilisation d un système complexe (problématique des chemins). Tout comme il est impossible de tester toutes les valeurs d entrée (ex. fonction d addition de 2 Int de 32 bits à raison de 1000 tests par seconde) 2. D autres constats sont à faire vis-à vis des tests, notamment la tendance visant à repousser la réalisation des tests le plus tard possible par manque de temps. Ce qui est en contradiction avec la règle qui veut que le coût d un changement évolue en fonction du temps [W100]. Figure 29 Coût d'un changement en fonction du temps Les tests devraient donc être réalisés le plus rapidement possible = années ,25 78 / 149

79 Définition de la procédure de test Vérification versus validation La vérification et la validation incluent toutes les activités permettant de s assurer au mieux que le logiciel créé corresponde aux spécifications et que les spécifications répondent aux besoins du client. Même si ces mots sont très proches phonétiquement, leurs sens diffèrent grandement. Boehm leur donna une interprétation simple en 1979 : Validation : Construisons-nous le bon produit? Vérification : Le construisons nous bien? La partie vérification contrôle donc la conformité entre le logiciel créé et ses spécifications. Tandis que la validation permet au client de confirmer que le logiciel correspond à ses attentes. Ce processus de vérification/validation avait lieu tout à la fin avec les méthodologies de développement logiciel suivant le modèle en cascade. Cependant avec l arrivée des méthodologies de développement agile, ce processus est appliqué tout au long du développement. Figure 30 Processus de Vérification - Validation 79 / 149

80 Définition de la procédure de test Tests «boîte blanche» vs tests «boîte noire» Les tests «boîte noire» considèrent le système à tester comme une boîte dont les seules informations connues sont les entrées et les sorties. Le fonctionnement interne de la boîte est totalement inconnu. La seule chose qui est alors testable est le fait que le résultat obtenu pour une entrée donnée est conforme à notre attente. Il n est donc en aucun cas possible de tester la façon dont le résultat est obtenu. De plus, les entrées doivent être choisies pour être les plus représentatives possibles du domaine. Car il ne sera pas possible d être exhaustif. Les tests «boîte blanche» testent un système dont la totalité du fonctionnement interne est connue. Cela permet au développeur de réaliser les tests en étant conscient de la structure interne du programme. En connaissant la structure interne d un programme il est possible de déterminer les chemins possibles (cela devient difficile pour des programmes complexes) au travers de ce programme et de les tester. Ces tests ne visent donc pas les fonctionnalités du système, mais l aspect structurel (le détail de l implémentation «Structure du programme»). Finalement, les tests «boîte noire» vérifient ce qu est censé faire le programme tandis que les tests «boîte blanche» vérifient ce qu il fait réellement. Souvent les tests «boîte noire» sont aussi nommés «Test fonctionnel» car ils ne testent que le fonctionnement du logiciel. Les tests «boîte blanche» se nomment «Test structurel» car ils permettent un accès direct à la structure du code. Figure 31 Boîte noire vs Boîte blanche 80 / 149

81 Définition de la procédure de test Analyse statique vs analyse dynamique Deux types d analyse sont principalement effectués durant la phase de vérification. Les analyses statiques de code permettent d étudier le logiciel sans l exécuter. Elles sont utilisées en particulier pour assurer une normalisation du code produit, une revue de code, Les analyses dynamiques de code requièrent quand à elles l exécution du logiciel. Elles sont utilisées en particulier pour l analyse des performances dans le but de déterminer les parties du programme qui doivent être optimisées. En outre, l analyse dynamique peut permettre de faire une corrélation entre les tests «boîte noire» et les tests «boîte blanche». En effet, il est possible d effectuer les Tests fonctionnels (boîte noire) puis avec une analyse dynamique appelée «couverture de code» de contrôler la partie structurelle (boîte blanche) et ainsi d adapter les tests en conséquence. La couverture de code met en évidence les lignes de code qui ont été parcourues durant les tests. Figure 32 Exemple couverture de code sous Microsoft Visual Studio Team System 81 / 149

82

83 Définition de la procédure de test using System; using System.Collections.Generic; using System.Text; namespace BankAccountDemo.Business { public class BankAccount { // Properties private float _currentbalance; public float CurrentBalance { get { return _currentbalance; } } // Constructors public BankAccount(float initialbalance) { this._currentbalance = initialbalance; } // Methods public void DepositMoney(float depositamount) { this._currentbalance += depositamount; } public void MakePayment(float paymentamount) { this._currentbalance -= paymentamount; } } } using BankAccountDemo.Business; using Microsoft.VisualStudio.QualityTools.UnitTesting.Framework; namespace BankAccountDemo.Business.Tests { [TestClass()] public class BankAccountTest { [TestInitialize()] public void Initialize() { } [TestCleanup()] public void Cleanup() { } [TestMethod()] public void ConstructorTest() { float currentbalance = 500; BankAccount target = new BankAccount(currentBalance); Assert.AreEqual(currentBalance, target.currentbalance, "Balances are not equal upon creation"); } [TestMethod()] public void DepositMoneyTest() { float currentbalance = 500; BankAccount target = new BankAccount(currentBalance); float depositamount = 10; target.depositmoney(depositamount); Assert.IsTrue( (currentbalance + depositamount) > target.currentbalance, "Deposit not applied correctly"); } [TestMethod()] public void MakePaymentTest() { float currentbalance = 500; BankAccount target = new BankAccount(currentBalance); float paymentamount = 250; target.makepayment(paymentamount); Assert.IsTrue(currentBalance - paymentamount == target.currentbalance, "Payment not applied correctly"); } } } Tableau 7 Exemple de test unitaire sous Microsoft Visual Studio Team System Figure 33 Résultat de l'exécution des tests unitaires 83 / 149

84 Définition de la procédure de test Tests d intégration Ce type de test est effectué au niveau supérieur des tests unitaires. En effet, ces tests visent à contrôler les interactions entre différents modules ou composants de l application en les intégrant au sein d un sous-système. Ces tests ne sont plus vraiment des tests en boîte blanche la structure interne de chaque composant n est pas nécessairement connue, néanmoins, la connaissance de la structure modulaire et des interfaces des composants est nécessaire. Le terme test en boîte grise est alors utilisé Tests du système A ce stade, les tests sur les composants (tests unitaires) ont été réalisés, puis ces composants ont été assemblés en sous-systèmes qui ont été testés (tests d intégration). Dès lors, il ne reste plus qu à tester le système dans sa globalité à l aide des tests du système. Ces tests sont de type boîte noire et visent à assurer l acceptation de l application développée par les utilisateurs Tests de performance Ce genre de test n est réellement utile que pour certains types de logiciels en particulier les systèmes travaillant en temps réel. Toutefois, si un niveau de performance est requis, il est possible d effectuer des tests de performance dans tous les niveaux précédemment décrits. Un certain nombre d outils tels que des profiler de code permettent de mettre en évidence quelles méthodes ont été appelées, ainsi que le temps d exécution de ces méthodes durant les tests ou la quantité de mémoire utilisée. Cela permet de cibler les problèmes de performance et donc d optimiser les composants spécifiés. Figure 34 Exemple du Profiler de code sous Microsoft Visual Studio Team System 84 / 149

85 Définition de la procédure de test Tests de validation (tests de l usager, recette) Ces tests sont, en principe, la dernière phase de test. En effet, ce stade n est atteint uniquement lorsque tous les niveaux de tests précédents ont été passés. Les tests des niveaux précédents ayant été effectués sans le client, ils ont établis que le logiciel est fonctionnel et qu il répond aux spécifications. Maintenant les tests de validation vont permettre d avoir la vision de l utilisateur final qui est, malheureusement, souvent différente de la vision du développeur. Ils mettront en évidence certains points de spécification qui n étaient pas compris de la même manière par l utilisateur et le développeur. C est pour ces raisons qu ils doivent être effectués le plus tôt possible. Finalement, ils valideront le logiciel par rapport aux besoins de l utilisateur. Ce qui aboutira sur l acceptation, l acceptation conditionnelle ou le refus du produit Cycle de test d un développement logiciel Le cycle se décompose principalement en quatre : Planification des tests. Exécution de tests pertinents sur le programme et observation de son comportement. Comparaison du comportement observé (Résultats effectifs) avec le comportement attendu (résultats attendus définis lors de la planification). Déboguer (localisation et correction de l erreur). Ce cycle est montré dans la Figure 35: Figure 35 Cycle de test Ces parties sont de même priorité et ne sont valides que si les autres parties sont réalisées. 85 / 149

86 Définition de la procédure de test Planification La planification des tests doit intervenir à tous les stades du développement. Selon les méthodologies de développement logiciel agiles, les tests sont extrêmement importants. Des méthodologies sont même conçues uniquement sur la notion de test «Test Drivent Development (TDD)», d autres intègrent les tests comme une bonne pratique de développement «Extreme Programming (XP)». Néanmoins, dans toutes ces méthodologies un principe est toujours présent «Le développement des tests doit avoir lieu avant le développement de l application». Ce principe peut sembler étrange de prime abord, mais la pratique montre qu il s avère fort efficace. En effet, la pré création des tests permet de se pencher plus en détail sur les aspects d interfaçage et d abstraction ce qui garanti une meilleure approche lors de la création de la logique métier. Dans la planification, il faut donc tenir compte du fait que les tests doivent, dans la mesure du possible, être développés avant le code. Un autre avantage non négligeable de cette pratique vient du fait que souvent, dans la pratique si les tests ne sont pas créés avant le code, ils sont omis faute de temps. La planification des tests permet de spécifier qui effectuera le test à quel moment et ce qui doit être testé. Cette planification dépend aussi du type de test (voir Figure 36) : Tests unitaires : Ce type de test est planifié par le développeur et doit être incorporé dans le temps de développement d un composant. Tests d intégration : Là aussi le test est effectué par les développeurs et sa création doit être intégrée dans le développement des composants. Tests du système : Les tests du système doivent refléter le fonctionnement des exigences. Ils sont aussi réalisés par les développeurs mais les conditions d acceptation sont définies par le client. Tests de performance : Ils sont aussi définis par le client et réalisés par les développeurs. Tests de recette : Ces tests sont décrits et réalisés par le client. Figure 36 Planification des tests 86 / 149

87 Définition de la procédure de test Exécution L exécution des tests doit être aussi automatisée que possible pour ne pas entraver le travail du développeur. Il est totalement insensé de créer une multitude de tests inutiles. Un test ne sera nécessaire que s il teste une nouvelle partie du programme. Si dix tests sont exécutés mais qu ils ne testent qu une seule partie du logiciel, un seul test aurait été nécessaire. L exécution des tests demande l utilisation de données d entrée. Il est donc important de réaliser les tests avec des données d entrée pertinentes. Pour cela le principe dit de partitionnement qui vise à catégoriser les entrées (une catégorie groupe des valeurs d entrée censées produire le même comportement) est utilisé. Par exemple le test d un composant stipulant que les données d entrée sont des entiers à cinq chiffres, le partitionnement pourrait regrouper les trois classes suivantes ; c 1 ="n<10000", c 2 ="10000<=n<=99999", c 3 ="n>99999". Il suffit ensuite de tester un seul cas par classe. Une autre optique d optimisation de la pertinence des tests est l introduction de la notion de test aux bornes. Le plus grand nombre d erreurs se trouvent dans les valeurs limites d entrée. Il est alors intéressant d effectuer un certain nombre de tests ayant des valeurs d entrée entourant les limites du système. Pour l exemple précédent les valeurs d entrées limites seraient (i1=9999, i2=10000, i3=99999, i4=100000). Cela permet de tester le bon fonctionnement du programme (avec des valeurs incluses limites) ainsi que la robustesse de celui-ci (avec les valeurs d entrée invalides) Comparaison La partie comparaison permet de dépouiller les résultats de l exécution pour définir le succès ou l échec des tests. Comme défini dans la partie planification, les conditions d acceptation sont définies par les développeurs (tests unitaires, tests d intégration) et par le client (tests du système, tests de performance, tests de recette). En partant de ces conditions d acceptation, les résultats d exécution prévus doivent être définis afin de les comparer avec les résultats obtenus. Il faut aussi faire la nuance entre tests réussi et échecs. Tout étant assez relatif, un test réussi peut-être soit un test qui met en évidence le bon fonctionnement d un composant soit un test qui met en évidence un bug. Car le but d un test étant d atteindre une certaine qualité, la mise en évidence d un bug permet sa résolution et donc l augmentation de la qualité du programme Déboguer Cette phase ne fait pas, à proprement parler, partie des tests. En effet, les tests sont là pour mettre en évidence un défaut du système ou pour donner un renseignement sur une métrique 87 / 149

88 Définition de la procédure de test de qualité. Suite à la mise en évidence d un défaut dans le système, il serait sûrement intéressant de pouvoir prendre en compte ce défaut dans l optique de le corriger. La phase déboguer consiste en la prise en compte du défaut. Elle est composée d une phase de localisation du défaut et d une phase de correction de l application pour corriger ce défaut. 4.3 Processus utiles à une PME Il est difficile de mettre en place un processus adapté pour une entreprise. En effet, le processus de test est extrêmement dépendant du projet. Néanmoins certaines valeurs fondamentales ont été recommandées pour InfoTeam : Tester avant de développer La réalisation des tests avant de développer un composant ou un module est certainement la meilleure pratique de développement incluse dans les méthodologies agiles. Elle améliore la qualité des composants créés et elle garanti la mise en place des tests Tester que si nécessaire L un des principes essentiels du développement agile est la simplicité. Ce principe peut être dispensé dans les processus de test. En effet, il ne sert à rien d effectuer un grand nombre de tests si ceux-ci n apportent pas une plus-value. De plus, tout ne doit pas être forcément testé. Par exemple, un test unitaire d une classe ne doit pas être forcement exhaustif en testant toutes les méthodes. Certaines méthodes n ont pas besoin d être testées soit parce qu elles ne correspondent pas à une fonction métier ou qu elles sont peu complexes (p. ex. getter/setter) Pertinences des tests Un test n est utile que s il est pertinent. Il faut donc bien réfléchir sur les données soumises en input aux tests (partitionnement des données [W139]) ainsi qu au différents cas de tests à prévoir. Il n est pas rare de constater qu un certain nombre de cas de test sont omis. Par exemple, «the art of software testing» [B14] met en évidence le développement d un programme qui détermine le type d un triangle (scalène, isocèle ou équilatéral) en fonction des longueurs de ses trois cotés. Ce programme ne parait pas forcément compliqué pourtant 14 cas de tests ont pu être définis en se référant aux problèmes constatés dans des implémentations réalisées par des développeurs expérimentés. En moyenne 7.8 cas de tests ont été passés par les implémentations réalisées. Cela montre la complexité des tests mais aussi qu une réflexion pertinente sur les entrées de tests permet de mettre en lumière un plus grand nombre de défauts. 88 / 149

89 Définition de la procédure de test Tests de non régression Pour les projets s étalant sur plusieurs versions, il est nécessaire de mettre en place un système de tests de non-régression. Les tests de non-régression sont l activation de tous les types de tests précédemment discutés (unitaire, intégration, système, ) lors de la modification du code source. Ces tests permettent de s assurer qu une modification du programme ne crée pas de défauts dans le système déjà testé. 89 / 149

90

91 Projet pilote 5. Projet pilote Good customer relations double productivity. Larry Bernstein 91 / 149

92 Projet pilote 5.1 Introduction Suite à la définition d une méthodologie de développement pour InfoTeam, il semble naturel de la mettre à l épreuve sur un projet concret. Cette mise à l épreuve permettra de contrôler si la méthodologie définie est bien adaptée au contexte d InfoTeam et si un certain nombre de modifications doivent encore y être apportées pour garantir son utilisabilité. Le projet proposé est interne à l entreprise InfoTeam et plus précisément à l unité Energie. Ce projet était prévu depuis un certain temps, mais il n avait jusqu à présent pas pu être effectué faute de temps et de ressources. Ce projet s adapte bien à la situation car il peut être développé par un petit groupe en un laps de temps réduit. Les chapitres suivants permettront d introduire le projet réalisé, puis de décrire les différentes étapes de la méthodologie mise en œuvre. 5.2 Description du projet Après avoir développé un produit de contrôle-commande de poste haute tension, la société InfoTeam SA a la charge d assurer la maintenance et le suivi de ce produit dans les différents postes dans lesquels il est installé. Pour effectuer cette tâche de manière efficace, InfoTeam SA propose de développer une application web liée à une base de données contenant toutes les informations relatives à chaque poste. Cette application devra aussi bien gérer le suivi des versions installées dans chaque poste que les données techniques du hardware, les données administratives liées à l installation, les données géographiques ou les personnes responsables du site. Une interface conviviale permettra de visualiser les données poste par poste ou d effectuer des recherches selon des critères prédéfinis et d afficher les données de manière à avoir une vue d ensemble de tous les postes. 92 / 149

93 Projet pilote 5.3 Les objectifs Voici une liste un peu plus étoffée des attentes découlant de ce projet : Mise en place d une application de suivi de la maintenance du produit StreamX présent sur des postes à haute tension. o Accessible par le web. o Informations stockées et gérées par une base de données. Cette application de gestion de la maintenance devra permettre de : o L affichage de la liste des postes. o La recherche d un poste selon un certain nombre de filtres : Recherches prédéfinies. Recherches personnalisables. o L affichage des données détaillées pour un poste spécifique : Nom Numéro d affaire commentaire. Informations sur l accès au poste. Informations sur la personne de contact (Choix du client et choix de la personne de contact [liste déroulante]). Informations sur l installation (StreamX et autres logiciels). Suivi de la maintenance pour un poste donné (interventions [date, type, participants]). Informations sur un certain nombre de données commerciales relatives au poste. Informations sur le matériel du poste à haute tension. Description de l installation du poste (+ schéma de principe). Adresses IP et nom des différents éléments de l installation + nom d utilisateur et mot de passe d authentification sur les éléments. o L ajout d un poste. o La suppression d un poste. o La modification des données d un poste. o La modification des données communes à plusieurs postes (ex : données sur le responsable de maintenance). 93 / 149

94 Projet pilote 5.4 Mise en place de l environnement de développement Afin d évoluer dans un environnement propice à l application de la méthodologie proposée, certains aménagements ont dû être réalisés. Tout d abord un tableau de bord permettant de suivre des tâches à effectuer au fil des jours a été mis en place. Figure 37 Tableau des tâches Afin de faciliter le planning poker, un jeu de carte avec les valeurs : 5, 10, 15, 20, 30 a été conçu pour tous les membres de l équipe. Un serveur virtuel a été installé avec la partie Serveur de Microsoft Visual Studio Team System, à savoir Team Foundation Server. De plus, Microsoft Sql Server 2005 et Microsoft Sharepoint Services y ont aussi été installés. Le plugin de Scrum pour Team System a également été mis en place sur ce serveur. Toute la description de cette installation est présente dans les annexes du document [B10]. Un ordinateur portable a été mis à disposition pour réaliser le développement. La version cliente de Microsoft Visual Studio Team System y a été installée. Les contraintes posées m ont amené à faire une légère remise à niveau de mes connaissances de certaines technologies (C#, ASP.Net et SQL). 94 / 149

95 Projet pilote 5.5 Mise en place de la méthodologie proposée Création de l équipe Pour ne pas se limiter à réaliser un projet pour réaliser un projet, une équipe de travail devait être mise en place. En effet, il aurait été inutile que je sois le seul à appliquer la méthodologie et donc à l évaluer. L équipe de développement mise en place est formée de deux membres, Olivier Neuhaus et moi-même. J ai fait office de Scrum master et de membre de l équipe de développement, tandis qu Olivier était membre de l équipe de développement. Bien que la taille de l équipe ne soit pas optimale, le fait d intégrer un collaborateur lui a permis de se familiariser avec la méthodologie et de donner son avis sur celle-ci. Le client était représenté par des collaborateurs d InfoTeam à savoir Jérôme Page et en seconde partie de projet Denis Muller Cahier des charges Un petit cahier des charges relatif au projet a été mis en place. Ce cahier des charges est très sommaire et avait pour but, uniquement la découverte et la rédaction des exigences du client (il correspond en fait à la liste étoffée en 5.3). Effectivement, la mise en place d un cahier des charges concret et très précis n était pas nécessaire ici car le but de ce projet n est pas d avoir un produit totalement opérationnel mais de valider ou non la méthodologie préconisée. L élaboration de ce cahier des charges a néanmoins permis d aboutir à un Product Backlog regroupant les vingt exigences du client ordonnées selon leur importance. Relative Value Backlog Item Name 1 Création de la base de données 2 Ajout d'un poste 2 Création de l'interface graphique générale 3 Sauvegarde des modifications de données simples (données dépendantes du poste ex: Nom du poste) 4 Affichage de la liste des postes 5 Affichage des données générales d'un poste 6 Affichage des modules du produit StreamX installés sur un poste 6 Affichage de la localisation d'un poste 7 Affichage d'informations sur les adresses IP des éléments d'un poste + nom et mot de passe 8 Affichage des informations sur l'installation logicielle d'un poste 9 Affichage du suivi de maintenance d'un poste donné 10 Affichage des informations d'accès à un poste 11 Recherches prédéfinies 12 Recherches spécifiques 13 Affichage des personnes de contact pour un poste 14 Affichage de la description de l'installation d'un poste 15 Affichage du matériel d'un poste 16 Affichage des données commerciales sur un poste 17 Sauvegarde des modifications de données complexes (données utilisées par plusieurs postes ex: Personnes de contact) 18 Suppression d'un poste Tableau 8 Product Backlog after client estimation 95 / 149

96 Projet pilote Nombre de Sprints Comme le temps de développement de cette petite application était limité à 3-4 semaines et qu une bonne évaluation de la méthodologie exigeait d avoir plusieurs itérations, nous avons décidé de fixer le nombre de Sprints à quatre. Soit un Sprint par semaine de travail Phase de planification Les exigences du client ayant été établies et ordrées selon ses priorités, il a été possible de passer à l estimation de leur envergure par les membres de l équipe. Pour cela la technique d estimation par analogie associée au planning poker a été mise en œuvre. Une réunion de planification a donc eu lieu. Durant cette réunion, j ai présenté les différentes exigences à Olivier. Puis nous avons utilisé la méthode préconisée pour estimer ces exigences en points. Nous avons procédé de la manière suivante : o Une exigence de taille moyenne a été choisie comme référentielle. o Les autres exigences ont été estimées à l aide du planning poker et de la méthode d estimation par analogie. L estimation des exigences n a pas posé de problème et la méthode utilisée nous a permis de réaliser ces estimations en un temps raisonnable. De plus, le coté ludique de cette méthode d estimation lui a permis d être facilement adoptée. L estimation des exigences a permis d aboutir à une version complète du Product Backlog. Relative Value Backlog Item Name Estimated Effort 1 Création de la base de données 10 2 Ajout d'un poste 5 2 Création de l''interface graphique générale 20 3 Sauvegarde des modifications de données simples (données dépendantes du poste) 15 4 Affichage de la liste des postes 5 5 Affichage des données générales d'un poste 5 6 Affichage des modules du produit StreamX installés sur un poste 5 6 Affichage de la localisation d'un poste 10 7 Affichage d'informations sur les adresses IP des éléments d'un poste + nom et mot de passe 5 8 Affichage des Informations sur l'installation logicielle d'un poste 5 9 Affichage du suivi de maintenance d'un poste donné 5 10 Affichage des informations d'accès à un poste 5 11 Recherches prédéfinies Recherches spécifiques Affichage des personnes de contact pour un poste 5 14 Affichage de la description de l'installation d'un poste 5 15 Affichage du matériel d'un poste 5 16 Affichage des données commerciales sur un poste Sauvegarde des modifications de données complexes (données utilisées par plusieurs postes) Suppression d'un poste 15 Tableau 9 Product Backlog estimé par l'équipe Comme le nombre de points total est d environ 200 et que nous avons prévu de faire 4 Sprints, la vélocité a été fixée à 50 points par Sprint. 96 / 149

97 Projet pilote Déroulement des Sprints Sprint 1 Les items suivants ont été choisis pour le premier Sprint : Relative Value Backlog Item Name Estimated Effort 1 Création de la base de données 10 2 Création de l''interface graphique générale 20 3 Sauvegarde des modifications de données simples (données dépendantes du poste) 15 Tableau 10 Product Backlog du Sprint 1 En début de sprint une réunion a été mise en place pour subdiviser ces items du Product Backlog en Sprint Backlog (qui représente un raffinement des exigences en tâches de quelques heures). Le Tableau 11 représente le Sprint et son avancement au fil des jours de la semaine : Sprint Backlog Id, Name and Owned By 2/7 3/7 4/7 5/7 6/ Définition de la structure des tables (Yannick Thiessoz) Création des tables (Yannick Thiessoz) Création de la hiérarchie d'objets (Yannick Thiessoz) Classe d'accès à la base de données (Yannick Thiessoz) Fenêtre de base (Yannick Thiessoz) Arborescence "vide" liste des postes (Yannick Thiessoz) Fenêtre de login "accès au site" (Yannick Thiessoz) Création des éléments de chaque onglet (Yannick Thiessoz) Préparation des onglets (Yannick Thiessoz) Lien entre sélection dans l'arborescence et l'élément à afficher (Yannick Thiessoz) sauvegardes des données générales (Yannick Thiessoz) sauvegarde données d'accès "sans image" (Yannick Thiessoz) sauvegardes des données commerciales (Yannick Thiessoz) sauvegarde des informations matérielles (Yannick Thiessoz) sauvegarde information sur le suivi (Yannick Thiessoz) sauvegarde info sur les adresses IP (Yannick Thiessoz) sauvegarde info sur les contacts (Yannick Thiessoz) sauvegarde version streamx (Yannick Thiessoz) Tableau 11 Avancement du Sprint 1 (du 2 juillet au 6 juillet) Le Tableau 11 montre que ce Sprint a pris plus de temps que prévu et que les items du Product Backlog de sauvegarde des modifications de données simples n ont pas pu être achevés. Les deux graphiques proposés par Scrum for Team System nous ont permis de rapidement nous apercevoir que la totalité des items du Sprint ne pourraient pas être pris en compte. Figure 38 Sprint 1 Cumulative Flow Diagram 97 / 149

98 Projet pilote Figure 39 Sprint 1 Burdown Chart Il aurait été judicieux (comme le décrit d ailleurs la méthodologie) de modifier le contenu du Sprint le mercredi afin de l adapter à la vélocité réelle de l équipe. Le premier Sprint n a pas eu la vélocité attendue et cela principalement pour deux raisons. La première étant la non prise en compte du fait qu une journée de travail avait été dédiée à la mise en place de la méthodologie (installation des postes, création de Product Backlog, ). La seconde étant la mauvaise estimation de la mise en place de la base de données et de la réalisation de l interface graphique de base. Ce Sprint a été conclu par une petite rétrospective mais n a pas fait l objet d une revue avec démonstration au client. Il n était en effet pas possible à la fin du premier Sprint de réaliser une démonstration convaincante pour le client. Néanmoins, la maquette de l interface graphique a été présentée au client ainsi que le schéma de la base de données crée. Liste des postes Onglets d un poste Sauvegarde Liste des postes Contenu d un poste Figure 40 Maquette de l interface graphique générale 98 / 149

99 Projet pilote Figure 41 Schéma de la base de données 99 / 149

100 Projet pilote Sprint 2 La composition du Sprint 2 est la suivante (Sprint Backlog et le Product Backlog) : Sprint Name Sprint 2 Product Backlog Item Name Sprint Backlog Item Name Effort Affichage de la liste des postes 5 IHM - Affichage de la liste des postes Logique métier - Affichage de la liste des postes Affichage des données générales d'un poste IHM - Affichage des données générales d'un poste Logique métier - Affichage des données générales d'un poste Affichage des Informations sur l'installation logicielle d'un poste 5 IHM - Affichage des Informations sur l'installation logicielle d'un poste Logique métier- Affichage des Informations sur l'installation logicielle d'un poste Affichage des modules du produit StreamX installés sur un poste IHM Affichage des modules du produit StreamX installés sur un poste Logique Métier - Affichage des modules du produit StreamX installés sur un poste Affichage d'informations sur les adresses IP des éléments d'un poste + nom et mot de passe 5 IHM - Affichage d'informations sur les adresses IP des éléments + nom et mot de passe Logique métier - Affichage d'informations sur les adresses IP des éléments + nom et mot de passe Affichage du suivi de maintenance d'un poste donné IHM - Affichage du suivi de maintenance d'un poste donné logique métier - Affichage du suivi de maintenance d'un poste donné Ajout d'un poste 5 IHM - Ajout d'un poste logique métier - Ajout d'un poste gestion exception - Ajout d'un poste redirection page principale du poste - Ajout d'un poste Sauvegarde des modifications de données simples (données dépendantes du poste ex: Nom du poste) sur un poste 15 sauvegarde des données générales sauvegarde données d'accès "sans image" sauvegarde des informations matérielles sauvegarde informations sur le suivi sauvegarde info sur les adresses ip sauvegardes des informations d'identification sauvegardes des informations d'installation sauvegardes des logiciels Tableau 12 Sprint Backlog du Sprint 2 Ce Sprint Backlog est issu de la réunion de début de sprint. On peut voir que les items réalisés durant le Sprint précédant ne sont plus présents et que la sauvegarde des modifications de données simples qui n avait pas pu être effectuée dans le Sprint précédant est reprise ici. Le Tableau 13 représente le Sprint et son avancement au fil des jours de la semaine : Sprint Backlog Id, Name and Owned By 9/7 10/7 11/7 12/7 13/ sauvegarde des données générales (Yannick Thiessoz) sauvegarde données d'accès "sans image" (Yannick Thiessoz) sauvegardes des données commerciales (Yannick Thiessoz) sauvegarde des informations matérielles (Yannick Thiessoz) sauvegarde information sur le suivi (Yannick Thiessoz) sauvegarde info sur les adresses IP (Yannick Thiessoz) sauvegarde info sur les contacts (Yannick Thiessoz) sauvegarde version StreamX (Yannick Thiessoz) IHM Affichage des modules du produit StreamX installés sur un poste (Yannick Thiessoz) Logique Métier - Affichage des modules du produit StreamX installés sur un poste IHM - Affichage du suivi de maintenance d'un poste donné (Yannick Thiessoz) logique métier - Affichage du suivi de maintenance d'un poste donné (Yannick Thiessoz) IHM - Ajout d'un poste (Yannick Thiessoz) logique métier - Ajout d'un poste (Yannick Thiessoz) gestions exception - Ajout d'un poste (Yannick Thiessoz) redirections page principale du poste - Ajout d'un poste (Yannick Thiessoz) 1 0 Tableau 13 Avancement du Sprint 2 (du 9 juillet au 13 juillet) 100 / 149

101 Projet pilote Comme le montre le Tableau 13 ce Sprint s est clairement mieux déroulé que le premier. En effet, presque toutes les tâches définies ont pu être accomplies et l avancement a été régulier. Cependant ce Sprint nous a permis de nous pencher sur la problématique des estimations pour chaque item du Backlog de Sprint. En effet, nous n avions jusqu alors pas fait de rapprochement entre les estimations des items du Product Backlog et les items du Sprint BackLog. De plus, nos estimations des items du Product Backlog ont été réalisées en nombre de points mais Scrum for Team System travaille uniquement en heures. Il fallait donc à ce stade faire une mise au point. En ce qui concerne l estimation des items du Product Backlog, il n y a pas de réelle problématique dans notre situation. En effet, nous avions prédit une vélocité de 50 points. Comme Scrum for Team System travaille en heures, cela n a pas posé de problème particulier nous avons donc admis qu un point équivalait à une heure de travail et que les semaines contenaient 50 heures de travail. Pour l estimation des tâches nous avions été un peu plus souples et nous estimions les tâches en heures. Malheureusement la somme de ces heures n était pas toujours équivalente aux 50 heures prévues (nous n avons pas adapté l estimation des tâches du Sprint Backlog aux estimations des exigences du Product Backlog), ce qui ne garantissait pas de bons graphiques. En effet, les graphiques commençaient avec le nombre d heures estimés (par exemple pour le Sprint deux le total des heures est de 16h alors qu il devrait être de 50h). Les deux graphiques proposés par Scrum for Team System ont néanmoins permis de remarquer que l avancement était bon. Figure 42 Sprint 2 Cumultive Flow Diagram Figure 43 Sprint 2 Burdown Chart 101 / 149

102 Projet pilote Contrairement au Sprint précédant, il était plus difficile ici de déterminer si une partie des tâches prévues durant le Sprint ne serait pas réalisées. Comme le montre la Figure 43, l avancement du premier jour laissait présumer une fin prématurée et donc une possibilité d accroître le périmètre du Sprint. Malheureusement quelques problèmes rencontrés durant la deuxième journée ont rendu l avancement moins rapide. Il était donc difficile d adapter le périmètre du Sprint. Finalement à l aide de la Figure 42, il est facile de remarque que la majorité du travail a pu être réalisée et qu une minorité n a pas pu être conclue à temps. Cette minorité sera reportée au Sprint suivant. Ce Sprint a abouti à une version plus élaborée qui a pu être démontrée avec succès auprès du client. C est à ce moment qu un autre client a été désigné pour suivre la suite de l avancement du projet Sprint 3 La composition du Sprint 3 est la suivante : Sprint Name Sprint 3 Product Backlog Item Name Sprint Backlog Item Name Affichage de la description de l'installation d'un poste Logique métier - Affichage description d'installation d'un poste IHM - Affichage description d'installation d'un poste Affichage des données commerciales sur un poste Logique métier - Affichage données commerciales d'un poste IHM - Affichage données commerciales d'un poste Affichage des informations d'accès à un poste IHM localisation d'un poste Logique métier localisation d'un poste Affichage des personnes de contact pour un poste Logique métier - Affichage personnes de contact d'un poste IHM - Affichage personnes de contact d'un poste Affichage du matériel d'un poste Logique métier - Affichage matériel d'un poste IHM - Affichage matériel d'un poste Sauvegarde des modifications de données simples (données dépendantes du poste ex: Nom du poste) sur un poste sauvegardes des données commerciales sauvegarde info sur les contacts sauvegarde version streamx Sauvegarde des modifications de données complexes (données utilisées par plusieurs postes ex: Personnes de contact) gestion client gestion image gestion responsable accès bd propre ajout commande suppression commande ajout responsable Maintenance suppression responsable maintenance ajout garanti suppression garanti Suppression d'un poste Suppression d'un poste Tableau 14 Sprint Backlog du Sprint / 149

103 Projet pilote Ce Sprint Backlog est issu de la réunion de début de sprint. Les trois tâches encore non réalisées pour la sauvegarde des modifications de données simples qui n avaient pas pu être achevées durant le Sprint suivant ont été reportées pour ce Sprint. Le Tableau 15 représente le Sprint et son avancement au fil des jours de la semaine : Sprint Backlog Id, Name and Owned By 16/7 17/7 18/7 19/7 20/ sauvegarde info sur les contacts (Yannick Thiessoz) Logique métier - Affichage données commerciales d'un poste (Yannick Thiessoz) IHM - Affichage données commerciales d'un poste (Yannick Thiessoz) Logique métier - Affichage personnes de contact d'un poste (Yannick Thiessoz) IHM - Affichage personnes de contact d'un poste (Yannick Thiessoz) Logique métier - Affichage localisation d'un poste (Yannick Thiessoz) IHM - Affichage localisation d'un poste (Yannick Thiessoz) Ajout responsable de maintenance (Yannick Thiessoz) Suppression responsable maintenance (Yannick Thiessoz) Accès Bd propre (Yannick Thiessoz) gestion responsable (Yannick Thiessoz) gestion client (Yannick Thiessoz) gestion image (Yannick Thiessoz) Ajout garantie (Yannick Thiessoz) suppression garantie (Yannick Thiessoz) ajout commande (Yannick Thiessoz) suppression commande (Yannick Thiessoz) Logique métier - Affichage materiel d'un poste (Yannick Thiessoz) IHM - Affichage materiel d'un poste (Yannick Thiessoz) Logique métier - Affichage description d'installation d'un poste (Yannick Thiessoz) IHM - Affichage description d'installation d'un poste (Yannick Thiessoz) Suppression d'un poste (Yannick Thiessoz) 3 0 Tableau 15 Avancement du Sprint 3 (du 16 juillet au 20 juillet) Comme le montre le Tableau 15 ainsi que la Figure 44 ce Sprint a avancé plus rapidement que prévu. Ce qui nous a même permis de rajouter un item du Product Backlog à savoir la suppression d un poste. Ce fut donc le premier Sprint achevé avec un Sprint Backlog vide. Et qui plus est en ajoutant un item du Product Backlog. Cela peut s expliquer par le fait que les estimations ont été plus précises. En effet, le Tableau 15 amène à constater que durant la première journée, des tâches pour une équivalence de 14h de travail on été réalisées, pour la deuxième journée, nous sommes à 8h de travail, pour la troisième à 9h et 17h pour les deux dernières. Une autre explication pourrait venir de l avancement du projet. En effet, le projet étant à un stade avancé, les membres de l équipe commencent à prendre des automatismes et le projet avance plus vite. Figure 44 Sprint 3 Burdown Chart 103 / 149

104 Projet pilote Ce Sprint a lui aussi abouti à une version opérationnelle qui a pu être démontrée avec succès auprès du client. La version développée jusque là offre les mêmes possibilités que la solution existante et en plus gère une centralisation des données, ce qui était la motivation principale de mise en place de ce projet pour le client Sprint 4 La composition du Sprint 4 est la suivante : Sprint Name Product Backlog Item Name Sprint Backlog Item Name Sprint 4 Recherches prédéfinies Recherche de la liste des postes en fonction d'une date de setup Recherche de la liste des modules pour tous les postes Recherche de la liste des Ips pour tous les postes Recherche des versions et des dates de setup pour tous les postes Recherches spécifiques logique de recherche spécifique Affichage général filtre d'affichage Affichage général filtre de recherche Affichage général pour les résultats d'une recherche spécifique complexe Création d'onglets de recherche spécifique Affichage général des résultats de recherche spécifique simple Tableau 16 Sprint Backlog du Sprint 4 Ce Sprint Backlog est issu de la réunion de début de sprint. Ces items issus du Product Backlog sont les derniers. Cela signifie que si ces items sont correctement réalisés pour la fin du Sprint les exigences du client seront entièrement satisfaites. De plus, l application réalisée jusqu à présent reprend déjà toutes les fonctionnalités de la solution que le client utilisait tout en y ajoutant certaines fonctionnalités. La finalisation de ce Sprint permettra donc au client de disposer d une version plus évoluée du système de Suivi de maintenance de StreamX. Le Tableau 17 représente le Sprint et son avancement au fil des jours de la semaine : Sprint Backlog Id, Name and Owned By 23/7 24/7 25/7 26/7 27/ Recherche de la liste des postes en fonction d'une date de setup (Yannick Thiessoz) Recherche de la liste des modules pour tous les postes (Yannick Thiessoz) Logiques de recherche spécifique (Yannick Thiessoz) Affichage général filtre d'affichage (Yannick Thiessoz) Affichage général filtre de recherche (Yannick Thiessoz) Affichage général pour les résultats d'une recherche spécifique complexe Création d'onglets de recherche spécifique (Yannick Thiessoz) Affichage général des résultats de recherche spécifique simple (Yannick Thiessoz) Tableau 17 Avancement du Sprint 4 (du 23 juillet au 27 juillet) Comme le montrent le Tableau 17 ainsi que la Figure 45 et la Figure 46 ce Sprint a avancé plus rapidement que le rythme escompté. Il a dès lors été possible de consacrer le vendredi à des tests pour s assurer que l application développée était conforme aux attentes du client. 104 / 149

105 Projet pilote Figure 45 Sprint 4 Cumulative Flow Chart Figure 46 Sprint 3 Burdown Chart Ce Sprint a abouti à la version finale du produit SuiviStreamX qui est totalement opérationnelle et qui a pu être démontrée avec succès auprès du client Scrum Meeting Chaque jour une réunion de Scrum Meeting a été réalisée en présence des deux membres de l équipe. Cette réunion s est déroulée selon les prescriptions de la méthodologie et a permis aux deux membres d avoir une vision précise de l avancement du projet et des problèmes rencontrés. Elle a été, bien qu à prime abord contraignante du fait de son application journalière, très bien acceptée par l équipe et a contribué pour beaucoup à la réussite du projet Graphiques d avancement Mis à part les graphiques exposés dans les chapitres montrant l avancement d un Sprint, la méthodologie Scrum définit aussi un graphique appelé Product Backlog Burdown. Ce graphique permet d avoir une vision de l avancement global du projet. Après le premier Sprint, l avancement n était pas conséquent mais les Sprint 2 et 3 ont fortement rattrapé le retard accumulé durant le premier Sprint. 105 / 149

106 Projet pilote Figure 47 Product Backlog Burdown Chart Les graphiques nous ont permis de suivre correctement l avancement du projet. Il nous ont même permis dans le Sprint 3 de rajouter du travail Pratiques de développements Certaines pratiques ont été entièrement mises en place et d autres uniquement partiellement. En effet, la mise en place des pratiques de développement issues de la méthodologie Extreme Programming est très variable d un projet à l autre. Pour ce projet, les pratiques suivantes ont été totalement intégrées : «Simple Design», «Refractoring» et «Coding Standard». Tandis que les pratiques «Customer Test» et «Test-Driven Development» n ont été que partiellement mises en œuvre car l application développée ne requérait pas de tests poussés. Une autre pratique «Sustainable Pace» n a pas été mise en œuvre, car le projet demandait plus d heures de travail que le temps à disposition. 106 / 149

107 Projet pilote 5.6 Application Finale Comme décrit précédemment, ce projet a abouti à une version fonctionnelle de l application SuiviStreamX. Cette application est constituée d une interface web qui communique avec une base de données. L installation de cette application ainsi que son utilisation sont décrit dans les annexes du document [B10] qui est protégé par le NDA (cf. annexe D NDA). Néanmoins ce chapitre permet d exposer un aperçu des fonctionnalités disponibles. Les fonctionnalités citées ici ne sont qu une partie des toutes les possibilités offertes par cette application web. Le but de cette présentation n est donc pas de les citer toutes mais plutôt de faire un rapide tour d horizon afin de montrer que l application développée en suivant la méthodologie a une certaine complexité Accès au site L accès au site se fait par l intermédiaire d une fenêtre de login comme le montre la Figure 48. Deux types d utilisateurs sont définis et ont des droits différents. Un dispositif de gestion de session a été mis en place afin d améliorer les possibilités de sauvegarde. Figure 48 SuiviStreamX : Fenêtre de login 107 / 149

108 Projet pilote Interface principale L interface principale permet de visualiser et de modifier les informations sur le suivi de maintenance d un poste où le logiciel StreamX est installé. Un principe d onglet permet de naviguer au sein des informations du poste sélectionné. Des boutons de sauvegarde et d annulation permettent à l utilisateur de valider ou non les modifications apportées au poste. Figure 49 SuiviStreamX : Information de localisation d'un poste Figure 50 SuiviStreamX : Information sur les logiciels installés 108 / 149

109 Projet pilote Figure 51 SuiviStreamX : Information sur l installation du poste Il est entre autre possible d ajouter et de supprimer des postes. Figure 52 SuiviStreamX : Suppression d un poste 109 / 149

110 Projet pilote Mis à part la gestion des informations spécifiques à un poste, la gestion d information relative à plusieurs postes tels que la gestion des clients a été mise en place. Figure 53 SuiviStreamX : Gestion des clients Cette interface web permet aussi de réaliser des recherches. Il est par exemple possible de connaître la configuration exacte de tous les modules StreamX installés sur tous les postes. Figure 54 SuiviStreamX : Recherche prédéfinie modules StreamX 110 / 149