Genielogiciel
5 j'aime2,556 vues
Le document traite des méthodes de gestion de projet en génie logiciel, en s'appuyant sur des concepts classiques et des méthodologies modernes comme le Rational Unified Process et l'Extreme Programming. Il aborde des thèmes essentiels d'optimisation de la gestion de projet, tels que la planification, les exigences, et le développement itératif, tout en soulignant l'importance de la communication et de l'implication des clients. Les différentes approches, comme Scrum, sont discutées pour leur impact sur la productivité et la gestion des équipes.
![User stories
• Une user story est une phrase du type :
• «En tant que [role], je [feature] pour [reason]»
• Ex : «En tant qu’utilisateur, je me connecte pour
entrer dans l’application»
• Certaines stories sont particulières :
• des «Epic» sont des futures stories trop larges et
destinées à être fragmentées
• des «Spike» sont des tâches de prototypages
techniques](https://image.slidesharecdn.com/genielogiciel-100124154229-phpapp02/85/Genielogiciel-95-320.jpg)
Genielogiciel
- 1. Génie logiciel Méthodes de conduite de projet Tester, optimiser, structurer ses applications Jean David Olekhnovitch [email protected] - www.olek.fr Support sous Licence Creative Commons Certains schémas sont issus de Wikipedia - www.wikipedia.org
- 2. Prologue : The Mythical Man Month • Livre écrit en 1975 • Témoignage sur l’expérience d’un projet s’engluant dans la complexité • Les conclusions sont un peu datées, mais les problèmes soulevés restent très actuels
- 3. Loi de Brooks • “Ajouter des ressources humaines à un projet en retard ne fait qu’accentuer ce retard” • Ces personnes doivent prendre le temps de se former au projet • Complexité des communications
- 4. L’effet “deuxième système” • Un informaticien n’ayant pas eu le temps d’inclure certaines fonctions dans un premier système va vouloir les inclure dans le second • Point de salut sans renoncement
- 5. L’unité conceptuelle • Préserver l’unité de la conception d’un projet en séparant son architecture de son implémentation • Accepter de rejeter une super idée si elle ne s’intègre pas vraiment au projet • On doit pouvoir décider qu’un programme possède moins de fonctions que possible
- 6. Le prototype • Toute nouvelle orientation technique est précédée d’un prototype • Sert à la conception du programme avec un certain “recul” • A pour vocation d’être jetable • Ne doit pas être livré au client
- 7. Documents de base • Rédigés par l’architecte du projet • Quels sont les objectifs • Comment les atteindre • Qui est responsable de quoi • Quand doivent ils être atteints • Combien chacun coûtera • Doivent révéler les incohérences d’un projet
- 8. Planification • Se souvenir du coût d’une tâche • Certaines tâches sont bien plus coûteuses que d’autres, techniquement parlant • Ex : concevoir un compilateur est 3 fois plus coûteux que concevoir une application classique
- 9. Le “chirurgien en chef” • En chirurgie, toute opération est hiérarchisée par les compétences de chacun • Un chirurgien en chef s’occupe des tâches essentielles et dirige son équipe • L’équipe l’appuie et s’occupe des tâches moins essentielles • Tenir compte des capacités de chacun
- 10. L’âge de glace • Chaque projet doit gérer des périodes de “gel”, caractérisés par des deadlines officielles : • Gel des spécifications, afin de pouvoir lancer un cycle de développement • Gel du développement, afin de pouvoir finaliser une version (debug)
- 11. Outils sur commande • Plutôt que chacun développe ses outils dans son coin • Inclure une personne dans le projet qui sera dédié à cette tâche • Mutualisera les besoins • Centralisera les développements et fournitures d’outils
- 12. Prologue-bis : les lois de Murphy • Une chose n’est jamais aussi simple qu’elle n’en a l’air • Tout prend plus de temps que vous le pensiez • S’il y a plus d’une façon de faire les choses, et que l’une d’elle aboutit à un désastre, alors quelqu’un procédera ainsi • Corrolaire de Finagle : Tout ce qui peut aller mal, ira mal
- 13. Encore pire • Cercle vicieux de Carvey : • La Loi de Murphy se vérifie toujours... sauf lorsqu’on cherche à la vérifier • Loi de Paquel : • La caractéristique la plus constante de l’informatique est la capacité des utilisateurs à saturer tout système mis à disposition
- 14. Industrialisation ? • Faut il industrialiser le développement logiciel ? • Utilisé ici par opposition à “artisanal” • Taylorisme, etc... • Analyser l’action de production dans le but de l’améliorer • Normalisation des outils et composants
- 15. Artisanat ? • Succès d’un projet encore essentiellement lié à la compétence de ses acteurs • Fabrication sur mesure • Difficile de reproduire une démarche d’un projet à l’autre • Technologies récentes, en pleine évolution
- 16. Normalisation et rationalisation • Cette transition de l’artisanat à “l’industrie” logicielle passe par différents efforts • En automatisant des tâches • En utilisant des normalisations • En rationalisant la création
- 17. Cycles de développement Ordonnancer son projet
- 18. Cycles de développement • L’informatique intervient dans des domaines de plus en plus complexes • Dès les années 50/60, on a commencé a théoriser sur les méthodes de conduites de projet • Grande question : dans quel ordre procéder ? • Théories sur les cycles
- 19. En cascade
- 20. En cascade • Directement hérité des méthodes utilisées dans les conceptions “en dur” • Bâtiment... • Simple bon sens : on ne peut faire les choses que dans l’ordre • Le toit se fait après les fondations
- 21. En cascade • Adapté à un processus logiciel ? • Oui : • Forcer à faire les choses dans l’ordre implique une certaine discipline • Non : • Le logiciel, immatériel par définition, permet des organisations plus souples
- 22. Cycle en V
- 23. Cycle en V • Méthode classique de “feedback” de projet : • Chaque étape fait écho à une étape précédente • Ex : les tests se réfèrent aux spécifications • ...et vice versa • Adapté lorsqu’un projet nécessite une certaine montée en puissance
- 24. Cycle en V • Plus le “V” descend profond, plus les erreurs de conceptions peuvent être importantes • Et le temps perdu important • Une certaine “autocritique” permettant de s’améliorer au fil du temps • Sans forcément en faire bénéficier le projet en cours
- 25. Cycles en spirales • Il s’agit simplement de cycles découpés en plusieurs “V” • Permet de prendre en compte la notion de “releases” successives et de plus en plus complètes/complexes • Le cycle dit «en W» est une toute petite spirale ;)
- 27. Cycle itératif • Objectif : livrer quelque chose d’incomplet, mais au plus vite • Apprendre par l’erreur • Doit accompagner des méthodes dites “agiles”
- 28. Cycle itératif
- 29. Cycle itératif • Nécessite une grande réactivité de la part du “client” • Bien adapté dans le cadre de projets “glissants” au niveau fonctionnel • De moins en moins adapté lorsque les équipes sont très importantes
- 30. RUP (Rational) Unified Process La première méthode liée aux concepts objets
- 31. Méthode liée à UML : RUP • Rational Unified Process • Suite des travaux des ‘three amigos’ • Méthode vendue par Rational • Particulièrement adapté à UML et au développement objet
- 32. Utilisation de RUP • Conçu dans le cadre de projets énormes • Gestion commerciale Ericsson • Très (trop) lourd pour des projets moyens • Mais peut s’adapter • Abord difficile car vocabulaire dense • Mais méthode validée à de nombreuses occasions
- 33. 4 P du développement objet • Personnes • Rôle joué par les acteurs d’une problématique • Projet • Le projet fait le produit • Produit • Un système logiciel • Processus • Dirige les projets
- 34. Fondement de RUP • RUP est : • Piloté par les cas d’utilisation • Centré sur l’architecture • Itératif et incrémental
- 35. Modélisation par les use cases • Notion introduite par Ivar Jacobson • Permetdu cahier des charges à une : comment passer de répondre à la question représentation rationnelle ?
- 36. Processus et cas d’utilisation • Le processus est piloté par les cas d’utilisations définis dans la première phase d’analyse • Permet d’appréhender les besoins • Dirige le processus tout au long de la vie du projet • Support de l’architecture logicielle
- 37. Les Use Cases • Analyse Fonctionnelle basée sur la notions d’acteurs • Compréhensibles à la fois par les développeurs et le client • Doit permettre de recenser la totalité des détails à traiter d’un problème
- 38. Quand exploiter les use cases ? • Les uses cases sont détaillés lors de l’analyse • Puis spécifiés en terme informatique • Réalisés par la conception • Concrètement implémentés par les développeurs • Vérifiés par les scénarios de tests
- 39. Notion d’acteur • Entité externe (être humain, mécanisme matériel, autre programme…) • Doit interagir avec le système à mettre en place • Préférer la notion d’acteur logique à celle d’acteur physique
- 40. Différents acteurs • Acteur ‘humain’ : le stick man • Acteur système : rectangle • Acteur principal : agit directement sur le système • Acteur secondaire : sollicité par le système pour obtenir des données
- 41. Exemple de use case
- 43. Description textuelle • Un use case efficace est complété d’une fiche signalétique • Résumé d’identification • Description des enchaînements • Autres renseignements (projets d’interface, liste de contraintes…)
- 44. Relations entre cas • Déclenche : entre un acteur principal et un cas d’utilisation • Utilise (include) : entre deux cas • obligatoire • Etend (extends) : entre deux cas • Impératif • Généralisation Héritage
- 46. Packages de use cases • Permet de simplifier des schémas de use cases • Utile dans le cas d’implémentation d’application métier
- 47. Notion d’architecture • Au sens de RUP, une architecture : • Sert à comprendre le système lorsqu’il est complexe • Pilote le projet en découpant les tâches • Favorise la réutilisation
- 48. Architecture • Fait le lien entre l’analyse et l’implémentation physique • Maîtrise technique • Elements structuraux • Effectué en parallèle avec l’analyse, avec un petit décalage
- 49. Notion d’artefact • Un artefact est un élément produit ou modifié dans le cadre d’un processus de développement • Ca peut être un document, un diagramme, un compte rendu de réunion... • ...mais aussi un code source, un écran, une base de données...
- 50. Notion de rôle • Ensemble d’activités et de responsabilités • Analystes • Développeurs • Testeurs • Managers
- 51. Notion de discipline • Une discipline est un agrégat d’activités, associé à : • Des artefacts • Un workflow (UML) • Il existe 6 disciplines d’ingénierie (voir cycles page suivante), et 3 disciplines de support (Project, Configuration, Environment)
- 52. Enchaînements d’activité • Expression des besoins • Use cases • Analyse • Refonte par l’informaticien des use cases • Conception • Architecture et modélisation • Implémentation • Tests
- 53. Gestion de projets par itération • Cycle complet : • Business Modeling • Requirements • Analysis and design • Implementations • Test • Deployement • Chaque itération ne contient pas forcément toutes les phases !
- 55. Business Modeling • Définir un modèle d’organisation • Identifier les acteurs • Identifier les processus métier, la vision métier • Etape pouvant être négligée si les processus métiers sont déjà parfaitement maîtrisés
- 56. Artefacts d’un business modeling • Business Glossary : recensement des termes métiers utilisés, permettant d’avoir un vocabulaire commun • Business Use Case Model : première version des use cases visant essentiellement a déterminer les acteurs et un premier découpage sommaire des cas d’utilisation
- 57. Gestion des exigences (requirements) • On passe ici des définitions métier aux exigences du projet • Rôle essentiel du client, puisque c’est ici qu’il donne ses exigences et recommandations
- 58. Artefact des requirements • Glossary : termes utilisés dans le projet • Business Case & Vision : Recensement des arguments sur l’intéret du projet (dont le retour sur investissement, ROI) • Risk List : Ensemble des risques identifiés et associés au projet • User Interface Prototype : première version de l’interface graphique (ex: maquette HTML)
- 59. Analyse et conception • Objectif principal : traduire les cas d’utilisation en artefacts de conception du système • On tient compte de l’environnement d’implémentation • Va permettre de piloter la conception de l’architecture
- 60. Artefacts Analysis & Design • Software architecture : description formelle de l’architecture du système • Design & deployment model : répartition physique des composants • Data model : structure logique et physique de la base de données
- 61. Implémentation • On affine ici le modèle de conception d’une manière très concrète : • Ecriture du code source • Ecriture des tests unitaires associés • Intégration du travail d’implémentation • Artefact : ‘Build’, exécutable contenant une version sommaire du produit final
- 62. Deployment • Activités liées au conditionnement du produit • Objectif : mise à disposition des utilisateurs • Pas forcément uniquement en fin de projet • Tests privés puis de plus en plus élargis • Artefact : le produit, avec une documentation de déploiement
- 63. Tests • Vérifier continuellement la qualité • Ecriture de tests de non régression • Tests unitaires • Tests fonctionnels • Artefacts : test plan (stratégie de tests), test suite (implémentation des tests)
- 64. Artefact test plan • Description de la stratégie de tests • Eléments à tester • Outil à utiliser suivant les tests • Mesures produites • Ressources affectées à cette tâche
- 65. eXtreme Programing La première des méthodes dites ‘agiles’
- 66. XP : Une alternative • eXtreme Programming • Issu projets ‘difficiles’ appliquer des méthodes a des de recherches pour • Cahier des charges mouvant • Délais courts • Technologies mal maîtrisées Réputation de méthode orientée « e-Business » !
- 67. Philosophies de XP • Réconcilier l’humain avec la productivité • Faciliter le changement social • Voie d’amélioration • Style de développement • Discipline de développement d’applications informatiques • Réduire les coûts du changement
- 68. Principes de base • Objectif : éviter le développement « cow-boy » • Principes : • Communication • Feed back • Simplicité • Courage • Peut être trop ‘militant’ ?
- 69. Pragmatisme extrême • La revue du code est une bonne chose • Elle est systématisée • Les tests sont indispensables • On les écrits dès le départ • La conception est importante • On la pratique tout au long du projet
- 70. Pragmatisme extrême -2 • La simplicité permet d’aller plus vite • On choisit toujours la solution la plus simple • La compréhension est importante • On définit des métaphores • L’intégration des modifications est cruciale • Effectuée plusieurs fois par jours
- 71. Cycle de développement XP
- 72. Client sur site • L’eXtreme Programming ne peut se mettre en place que si le client est fortement impliqué • Dans l’idéal, un représentant du client final doit être sur site pendant toute la durée du projet • Il connait l’utilisateur final • Il doit avoir une vision globale du projet • Il réalise son travail habituel et est à disposition de l’équipe de développement
- 73. Collaboration avec le client • Les users stories peuvent compléter les uses cases, en reprenant les cas d’utilisation point par point • Amorce de dialogue moins formelle • Utilisation de fiches au format A5 • Implication active dans chaque itération
- 74. Planning Game • Implique Client et Développeur • Le client crée des scénarios • Celà lui donne un certain ‘contrôle’ sur le projet, sans être rhédibitoire pour le dév • L’équipe estime les temps de réalisation • Le client sélectionne les scénarios à réaliser et définit les priorités
- 75. Intégration continue • Dès qu’une tâche est terminée, on inclut les modifications au produit final • Eviter une trop grosse tâche d’intégration pré-livraison • Rôle important et validant des tests
- 76. Petites livraisons • On limite au maximum la portée et l’importance d’une livraison • L’intégration continue doit faciliter cette tâche
- 77. Tests • L’écriture des tests unitaires précède le développement • Permet de prévenir les oublis • Anticipe les difficultés • ‘Documente’ le développement • Les tests de recette (tests fonctionnels) sont définis conjointement avec le client • Valident et clôturent une itération
- 78. Rythme de travail • Pas d’heures supplémentaires deux semaines de suite • Un développeur fatigué travaille mal • Chaque tâche doit être limitée à une journée • La journée doit se terminer par une fin de tâche • Le code est relu le lendemain matin • Permet de jauger “l’odeur” du travail de la veille
- 80. Refactoring de code • Autorisé et même conseillé • Jauger « l’odeur » d’un code • N’apporte rien au client, maisenvironnement développeur d’améliorer son permet au • Appropriation collective du code • L’équipe est responsable collectivement de l’application • On peut modifier un code qui n’est pas le sien • Les tests seront les juges de paix
- 81. Pair programming • Programmation en binômes • Binômes tournant • Améliorer la connaissance collective de l’application • Tout code est relu • Celui qui n’est pas au clavier prend du recul • Echanges de savoir faire et transfert de compétences
- 82. Changements • Ne sont pas vus comme une fatalité (gérée par les itérations) • Sont incorporés comme une notion naturelle • Accompagnent l’évolution d’un logiciel Et la maintenance logicielle ?
- 83. Convention de nommage • Pour permettre une appropriation collective • Il faut établir et respecter des conventions • Vocabulaire utilisé • Nommages des classes, méthodes,... • Utilisation de métaphores • Ne pas utiliser de termes savants là où une analogie peut clarifier la situation
- 84. Nonlinear management • Le mode de management non linéaire est présenté comme une évolution encore plus extrême des méthodes agiles • Une totale liberté est laissée sur la forme, seule l’objectif compte • Ex : «je vous laisse maître de l’implémentation d’une classe à condition que l’on conçoive ensemble son interface» • Beaucoup de projets communautaires fonctionnent ainsi • Ex : Linux, wikipedia..
- 85. Fonctionnement non linéaire • Le rôle du chef de projet est de dégager des “tickets”, avec une unité de temps <=1jour • Création de fonction • Modification/Refacto • Debug • Les développeurs gardent une marge de décision sur l’ordre des tâches à accomplir
- 86. Gestion du planning • On se fixe des sous projets (milestone) avec des dates limites • Des graphes de progression permettent de visualiser les progrès accomplis • On utilise le plus souvent des outils online pour gérer les projets (ex : TRAC, Sourceforge...)
- 87. Particularités • Nécessite une grande cohésion d’équipe et une motivation accrue • Le côté “liberté” et “on gagne ensemble” jour en la faveur de la motivation • Implique une préparation intense de la part du chef de projet • La liberté doit reposer sur un projet extrêmement bien cadré et préparé
- 88. SCRUM Agilité et travail d’équipe
- 89. Scrum : le jeu «collectif» • Scrum est, à l’instar de XP, une méthode agile de conduite de projets • Mais plus orientée «conduite d’équipes» • Contrairement à XP, le rôle du «chef d’équipe» est bien explicité • Scrum signifie «mêlée», au sens du Rugby • Aller de l’avant ensemble, avec un même objectif
- 90. Grands principes • Individus vs Processus/Outils • Collaboration du client vs contrat • Réponse au changement vs plan défini à l’avance • Logiciel vs documentation exhaustive
- 91. Les intervenants de Scrum
- 92. Les acteurs de Scrum • Directeur de produit : le ‘représentant’ du projet, la maîtrise d’ouvrage • L’équipe : sans hiérarchie particulière, chargée de l’exécution des tâches • Le ‘Scrum master’ : en charge de l’ordonnancement des tâches et ‘tampon’ entre le client et les exécutants • Les ‘Skateholders’ sont des intervenants extérieurs (consultants, experts, agents de direction..)
- 93. Planification • Sprints : entre 2 et 4 semaines • Releases : sorties effectives du logiciel • Une release est constituée de sprints • Quotidien : ScrumMeeting de mise au point
- 94. Contenu d’un sprint • Un sprint est constitué de tâches, piochées dans le Product Backlog • But du jeu : vider le product backlog • Les tâches peuvent être : • Des users stories (définies par le product owner) • Des technical stories (déf par l’archi technique)
- 95. User stories • Une user story est une phrase du type : • «En tant que [role], je [feature] pour [reason]» • Ex : «En tant qu’utilisateur, je me connecte pour entrer dans l’application» • Certaines stories sont particulières : • des «Epic» sont des futures stories trop larges et destinées à être fragmentées • des «Spike» sont des tâches de prototypages techniques
- 96. Notation des user stories • Chaque user story est ‘notée’ pour quantifier sa complexité • Par de lien direct avec une estimation en jours de travail • Permet ensuite de comptabiliser les points pour le suivi projet • On utilise souvent la suite de Fibonacci pour éviter les notes trop proches (1,2,3,5,8,13)
- 97. Planning Poker • Il existe des outils permettant de poser un consensus sur la complexité des divers User Stories • Sorte de ‘vote’ par les membres de l’équipe
- 98. Burndown chart • Chaque tâche est liée à un nombre de points • Le but du jeu d’une release est de réduire à zéro les points constités par le cumul de ses tâches • Permet une visualisation temps réel de l’avancée du projet • Il existe des graphiques pour visualiser une release, mais aussi un sprint
- 99. Scrum et conduite d’équipe • Une user story peut être allouée telle qu’elle à un développeur, mais il vaut mieux utiliser une méthode «XP» : • Une user story est alors découpée en tâches d’une journée maximum • Chaque tâche est ensuite allouée à selon la méthode de conduite d’équipe choisie : • Soit par le ScrumMaster • Soit par volontariat par le dév/exécutant
- 100. La Cathédrale et le Bazar Le modèle de développement du logiciel libre
- 101. Le premier ‘bazar’ : Linux • Un projet d’envergure, international • Un ‘leader’ très peu dirigiste (Linus Torvalds) • L’utilisation intensive d’outils de versioning et d’Internet • Opposition complète à la notion de ‘Cathédrale’, beaucoup plus hiérarchique et dirigiste
- 102. Ouvrir un bazar ? Les prérequis • Un coordinateur • Pas forcément le meilleur technicien • Mais apte à reconnaître le talent des autres...et leurs idées • Avec un certain charisme, un bon contact • Un amorçage avec une ‘promesse plausible’ • Le noyau 0.01 de Linux
- 103. Le noyau Linux • Des années de développement (presque 20 ans entre la 0.01 et la 2.6.32 !) • Linus se présente comme un «dictateur bienveillant» • Des milliers de contributeurs ! • Des ‘mainteners’ pour les versions stabilisées • Nouvelle version toutes les 8 semaines en moyenne • Après différents choix, l’équipe utilise aujourd’hui le gestionnaire de version Git
- 104. Quelques règles... • Chaque bon projet commence par un premier ‘draft’ lancé par l’initiateur • Les bons programmeurs savent écrire. Les excellents savent quoi réécrire • Préparez vous à jeter.Vous le ferez, de toute manière • Si vous perdez de l’intérêt, passez la main • ‘Releasez’ tôt et souvent • Abusez des beta-testeurs et classez les problèmes
- 105. Quelques règles (suite) • De bonnes structures de données et un code pourri fonctionneront mieux que l’inverse • Traitez au mieux vos beta-testeurs • Le design ‘parfait’ est atteint non pas quand plus rien n’est à implémenter, mais quand plus rien n’est à enlever • Un outil doit être utile, mais un vraiment bon outil vous amène des possibilités inattendues • Ecoutez vos utilisateurs
- 106. Boite à outils Utiliser le formalisme UML et divers autres outils dans la conduite de projets
- 107. Mener un projet en s’appuyant sur UML • Xième rappel : UML n’est pas une méthodologie objet • Mais c’est une “boîte à outils” permettant de tout envisager dans ce domaine • On peut donc aisément utiliser les divers diagrammes tout au long de la vie du projet
- 108. Séquence de tâches dans un projet UML Use cases Découpage Méthodes Interface Structure base de utilisateur données Données publiques Diagramme de Structure classes classes Diagrammes Corps dynamiques méthodes
- 109. Les éditeurs UML • Il en existe de nombreux • Certains génèrent le code objet à partir du diagramme de classes • Certains permettent même du ‘reverse engineering’
- 110. Maquettes d’interface • Pour concevoir les maquettes, un outil spécifique permet de les créer en disjoignant complètement les questions esthétiques • C’est un «mockup» • Ex : Balsamiq Mockups
- 111. Tests Limiter la régression et aller vers une meilleure qualité du logiciel
- 112. Tests unitaires • Principe : une batterie de tests (par classe, par méthode...) formalisés et réutilisables • Objectifs : • Regrouper vos tests • Pouvoir les appeler/rappeler en bloc • Tests de non régression
- 113. Conception par contrats • Pour valider le fonctionnement d’une classe • Principe de classe autotestable • Principes d’un contrat : • Destiné a formaliser des spécifications et de la documentation • Sert à la mise au point et aux tests
- 114. Contrats et langage • Notion de contrat introduite par Bertrand Meyer L’inventeur du langage Eiffel Travaille a l’intégration de ses technologies dans .Net Naturellement, on retrouve la notion de contrat dans Eiffel (et dans Python) Les autres langages objets peuvent s’adapter
- 115. Tests de classes • Tests unitaires : comportement d’un objet isolé • Pas toujours probant • Validation de composants • Suivi de scénario d’échange de messages entre quelques classes • Suivant le périmètre, on s’approche : • Des tests unitaires • Ou des tests d’intégration
- 116. Boîte blanche / noire • Boîte blanche : approche classique, procédurale • Permet de tester plus précisément certains points faibles d’une classe • Ne fera pas apparaître des oublis et incohérences vis à vis des specs • Contraire au principe d’encapsulation
- 117. Boîte noire • Conforme à l’encapsulation d’un objet • Privilégie l’interface sur l’implémentation • Principes d’oracles • Permettent de déterminer si un test s’effectue correctement ou non • Ont souvent besoin de données internes aux classes • On met en place des indicateurs (sous forme de méthodes) spécifiquement pour les tests
- 118. Tests de non régression • Composants objets réutilisables • Durée de vie parfois longue Importance de la validation des composants Chaque opération de maintenance entraîne de nouveaux tests
- 119. Assertions • Clause à vérification obligatoire • Assertions de contrat • S’insèrent dans l’interface • Tests de type boîte noire • Assertions internes • Tests de type boîte blanche • Contrats + Assertions Outils pour écrire des scénarios de tests
- 120. Design By Contract (DBC) • Mis au point par Bertrand Meyer • Langage Eiffel • Concept : notion de contrat entre le développeur d’API et l’utilisateur de ces APIs • Basé sur la notion d’assertions • Vérification de tests donnant “vrai” ou “faux”
- 121. Que tester ? • Il n’est pas très utile de systématiser les tests • Plutôt que de favoriser les “trains qui arrivent à l’heure”, favoriser les cas limites • “Crashs tests” • Musée des horreurs de l’utilisation de vos classes
- 122. Exemples de tests (TP formes géom.) • Paramètres à envoyer (style : “10 12 15”) • Envoyer trop de paramètres • Envoyer pas assez de paramètres • Envoyer des lettres au lieu de chiffres • Formes en dehors de la surface • Fichier • Fichier vide • Fichier inexistant • Nombre de lignes impairs
- 123. Versions logicielles Maîtrise de l’évolution du software dans le temps
- 124. Contrôle de version • Permet de gérer et de numéroter les versions d’un logiciel • Indispensable pour gérer du travail en groupe et l’historique d’un logiciel • Historiquement, on utilisait l’outil cvs • Aujourd’hui, on utilise plutôt svn
- 125. Exemple de versioning • svn add list txt • svn ci list.txt -m “ajout a la liste”
- 126. Synchronisation serveur/ version locale • svn co list.txt • svn ci list.txt • svn revert list.txt • svn co -r2 list.txt
- 127. Comparaison deux fichiers • La commande diff permet de visualiser les différences entre deux fichiers • svn diff -r3:4 list.txt
- 128. Création d’une branche • svn copy http://...trunk http://....branch
- 129. Fusion de versions • svn merge -r5:6 http://...trunk
- 130. Tagging • svn copy http://...trunk http://...tag
- 131. Qualité De la conduite de projet vers la qualification des livrables
- 132. Démarche qualité • Objectif : introduire des démarches de contrôle qualité au niveau du code source • On passe de plus en plus par des automates • Il existe aujourd’hui des “suites” de logiciels de contrôle et d’audit de code
- 133. Suites de qualité logicielle Java • Ex : XRadar, Sonar... • Compilation de plusieurs outils : • CheckStyle : vérification des nommages et styles de codes • PMD : contrôle qualité sur la nature même du code • JDepend : visualisation des dépendances entre classes • JavaNCSS : métrique de code
- 134. Exemple d’analyse avec PMD • PMD s’intègre a Eclipse • Mais pour systématiser les tests, il vaut mieux les inclure dans un système automatisant (chaque nuit ?) les audits
- 135. Etat récapitulatif avec Sonar
- 136. Tests de montée en charge
- 137. Montée en charge avec JMeter
- 139. Anti-Patterns • De la même manière que les Patterns sont des modèles de conception.. • ..des anti-patterns sont des modèles de ce qu’il ne faut pas faire • Sorte de “worst-of” des pratiques • dans le logiciel • dans l’entreprise en général
- 140. Anti-patterns de développeurs • Abstraction inverse : être obligé d’utiliser un objet dont l’interface est trop complexe par rapport à l’usage simple qui est le vrai besoin • Action à distance : emploi abusif de variables globales et de dépendances entre classes externes • Ancre de bateau : composant inutilisé mais gardé dans le code “au cas où”
- 141. Anti-patterns de développeurs • Copier/Coller : fameux syndrôme du développeur de duplication de code erroné ou de non-adaptation de code La programmation ‘Pizza’ • Programmation spaghetti est en revanche conseillée ! • Programmation plat de lasagnes : impossibilité d’intervenir sur les couches inférieures • Réinventer la roue carrée : réinventer une mauvaise solution
- 142. Anti-patterns de développeurs • Coulée de lave : Passer en prod un code immature, ce qui va ‘solidifier’ les bugs en empêchant leur modification • Surcharge des interfaces utilisateurs • Objet divin : composant effectuant trop de tâches essentielles
- 143. Anti-patterns de conduite de projets • 30,000 feet and climbing : Modèle ultra- pyramidal • Bleeding edge : recours systématique à des technologies immatures • Brain trust parking lot : cumulation inutile de “grosses têtes” • Buzzword driven architecture (ou Architecture by magazine) : accumulation de technos “à la mode” sans justification