Modelisation agile 03122011

4,994 views
4,867 views

Published on

Présenation faite pour le TogoJUG le 3 décembre 2011

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,994
On SlideShare
0
From Embeds
0
Number of Embeds
469
Actions
Shares
0
Downloads
400
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • Analyse pilotée par les processus métiers et surtout les exigences et les cas d’utilisation Centrée sur l’architecture
  • Modelisation agile 03122011

    1. 1. Modélisation Agile & UML TogoJUG 3 décembre 2011 Agnès CREPET @agnes_crepet
    2. 2. Objectifs de la session <ul><li>Pas un cour UML! </li></ul><ul><ul><li>Pré-requis : connaître les principaux diagrammes UML </li></ul></ul><ul><ul><li>Pas d’expertise requise! </li></ul></ul><ul><li>Plutôt un retour d’expérience de modélisation dans un contexte de projet « agile » </li></ul><ul><ul><li>Bonnes pratiques de modélisation. Quand utiliser quel diagramme? </li></ul></ul><ul><li>Comprendre comment formulation des exigences, analyse, conception, implémentation et tests s’intègrent dans un processus de développement logiciel itératif </li></ul><ul><li>Perspective sur d’autres vecteurs de réussite </li></ul><ul><ul><li>UML n’est pas la réponse à tous les problèmes de modélisation! </li></ul></ul>
    3. 3. Qui suis-je? <ul><li>Agnès CREPET </li></ul><ul><li>Java/JEE Architect </li></ul><ul><li>hooked on Agile </li></ul><ul><li>@duchessfr & @LyonJUG Leader </li></ul><ul><li>Curator of @mixIT_lyon conf & @cast_it podcast </li></ul><ul><li>Curator of www.avataria.org </li></ul>
    4. 4. <ul><li>Quelques rappels sur l'agilité </li></ul><ul><li>Modéliser et concevoir </li></ul><ul><li>Vers une modélisation agile </li></ul><ul><li>UML pragmatique & Retour d'expériences </li></ul>Sommaire
    5. 5. Le manifeste des méthodes agiles
    6. 6. Le manifeste des méthodes agiles <ul><li>En rupture avec les méthodes classiques (cascade, cycle en V, etc.) de gestion de projet logiciel </li></ul><ul><li>Août 2001, publication du manifeste des méthodes agiles </li></ul><ul><ul><li>Par 17 personnalités éminentes du développement </li></ul></ul><ul><ul><li>Ward Cunningham (Wiki), Kent Beck (eXtreme Programming), Ken Schwaber, Jeff Sutherland (SCRUM), Alistair Cockburn, Martin Fowler </li></ul></ul>
    7. 7. Les valeurs de l'agilité
    8. 8. <ul><li>Quelques rappels sur l'agilité </li></ul><ul><li>Modéliser et concevoir </li></ul><ul><li>Vers une modélisation agile </li></ul><ul><li>UML pragmatique & Retour d'expériences </li></ul>Sommaire
    9. 9. Préambule <ul><li>Personne n’est parfait = tout le monde est imparfait </li></ul><ul><li>L’erreur peut venir du développeur, mais pas uniquement. </li></ul><ul><li>Tous les acteurs du projet peuvent se tromper ... à leur manière </li></ul>&quot;Une erreur de spécification est une forme de bug. Un utilisateur, un décideur et un responsable métier ont aussi le droit de se tromper.&quot;  (Responsable métier chez Boiron) &quot;Il n’existe pas de bug qui ne soit issu du cerveau humain. La conception c’est tout ce qui permet de prévenir ou contourner les bugs du cerveau (outil, méthode, design pattern, modélisation, schéma, doc, wiki, commentaire dans le code, …)&quot;  (Mix-IT 2011) Laurent Bossavit @Morendil Responsable de l' institut-agile.fr
    10. 10. Préambule <ul><li>Les besoins métier évoluent dans le temps, même pendant la vie d'un projet </li></ul><ul><li>On doit savoir et pouvoir s’adapter au changement... </li></ul>
    11. 11. Itératif, incrémental, adaptatif Modélisation selon Jeff Patton
    12. 12. Itératif, incrémental, adaptatif <ul><li>Les besoins se précisent voire évoluent continuellement </li></ul><ul><li>pendant le projet, même quand on croit toucher au but </li></ul>
    13. 13. <ul><li>Quelques rappels sur l'agilité </li></ul><ul><li>Modéliser et concevoir </li></ul><ul><li>Vers une modélisation agile </li></ul><ul><li>UML pragmatique & Retour d'expériences </li></ul>Sommaire
    14. 14. Quelques fausses idées sur la modélisation <ul><li>Modèle = Documentation </li></ul><ul><li>Processus lourd </li></ul><ul><li>Les modèles sont figés </li></ul><ul><li>Les Outils sont complexes et onéreux! </li></ul><ul><li>Modéliser c’est facile! </li></ul><ul><li>Modéliser est une perte de temps ... </li></ul>
    15. 15. Vers une modélisation agile <ul><li>Comment documenter / modéliser un besoin ? </li></ul><ul><li>2 approches semblent opposées : </li></ul><ul><ul><li>l'approche Model-Driven, préconisée par l'OMG, s'appuyant sur une modélisation UML très poussée visant à une génération automatique de code quasi-complète, </li></ul></ul><ul><ul><li>certaines méthodes agiles mettent plus l'accent sur la production rapide de code opérationnel que sur la documentation et minimisant donc la modélisation en amont </li></ul></ul>
    16. 16. Vers une modélisation agile <ul><li>Trouver le juste milieu entre : </li></ul><ul><ul><li>Pas de modélisation du tout </li></ul></ul><ul><ul><li>Trop de modélisation </li></ul></ul><ul><li>Deux objectifs : </li></ul><ul><ul><li>Comprendre le système à faire </li></ul></ul><ul><ul><li>Communiquer en interne et externe </li></ul></ul>
    17. 17. Agilité et UML <ul><li>L'agilité se passe de plus en plus d'UML mais possible de privilégier une modélisation UML pragmatique! </li></ul><ul><li>Pas trop de doc… Un peu d’UML! </li></ul>
    18. 18. UML <ul><li>Unified Modeling Language </li></ul><ul><li>Notation standard de l’industrie pour les modèles d’analyse et de conception orientées objet </li></ul><ul><li>UML propose de nombreux diagrammes (Diagramme de classes, Diagramme de séquence, …) </li></ul><ul><li>C’est un langage et non une méthode ou un processus de développement! </li></ul>
    19. 19. Les digrammes UML <ul><li>UML 2.3 propose 13 types de diagrammes (9 en UML 1.3) </li></ul><ul><ul><li>leur utilisation est laissée à l'appréciation de chacun </li></ul></ul>
    20. 20. <ul><li>Quelques rappels sur l'agilité </li></ul><ul><li>Modéliser et concevoir </li></ul><ul><li>Vers une modélisation agile </li></ul><ul><li>UML pragmatique & Retour d'expériences </li></ul>Sommaire
    21. 21. Contexte retour d’expérience <ul><li>Laboratoire pharmaceutique (homéopathie) : Boiron </li></ul><ul><li>Contexte de refonte du Système d’Information </li></ul><ul><li>Nouvelles technos (stack Java, Spring, Hibernate, etc.) </li></ul><ul><li>Application de production (pharmaciens, etc.) </li></ul><ul><li>1500 utilisateurs </li></ul><ul><li>10000 jours/hommes </li></ul><ul><li>2 ans et demi </li></ul><ul><li>J’étais architecte logiciel de ce projet </li></ul>
    22. 22. <ul><li>Nous avons utiliser Enterprise Architect (EA) </li></ul><ul><ul><li>Sparx Systems : http:// www.sparxsystems.com </li></ul></ul><ul><li>Un outil opensource intéressant : Modelio </li></ul><ul><ul><li>http://www.modeliosoft.com/ </li></ul></ul><ul><ul><li>Non utilisé dans le projet </li></ul></ul><ul><li>Ces deux outils assurent: </li></ul><ul><ul><li>Gestion des exigences </li></ul></ul><ul><ul><li>Modélisation UML 2.x </li></ul></ul><ul><ul><li>Nice features (Intégration SCM, reverse-forward engineering, etc.) </li></ul></ul>L’analyse et la conception UML avec quel outil ?
    23. 23. <ul><li>Tout n’est pas à modéliser! </li></ul><ul><li>Modélisation UML pour l’analyse, très peu pour la conception </li></ul><ul><li>Modélisation en mode reverse pour la conception </li></ul><ul><ul><li>Génération des modèles à partir du code </li></ul></ul><ul><li>Modélisation progressive </li></ul><ul><ul><li>Activité d’analyse et donc de modélisation à chaque itération, donc tout au long du projet! </li></ul></ul>Démarche d’analyse et de conception (1/3)
    24. 24. <ul><li>Enrichissement des modèles à chaque itération! </li></ul><ul><li>Nous allons voir quels modèles utilisés sur ces disciplines </li></ul>Temps Analyse affinage Déploiement Maintenance Exigences initiales Itérations 1.0 1.1 2.0 Analyse Reformulation des besoins 1.2 Démarche d’analyse et de conception (2/3) Recette DSI Recette métier Développement & test unitaires Test dev Conception technique
    25. 25. Démarche d’analyse et de conception (3/3) Exigences Diagrammes d’états Diagrammes d’activité (si nécessaire)… Cas d’utilisation Maquette IHM (powerpoint ou Pencil) Modèle du domaine (Diagramme de classe d’analyse) Diagrammes de séquences (si nécessaire)… Analystes Concepteurs Cahier des charges Interviews Outil UML Diag. de classe conception Cas d’utilisation
    26. 26. Les diagrammes UML que l’on a utilisé <ul><li>Les diagrammes structurels ou statiques (Structure Diagram) : </li></ul><ul><ul><li>Diagramme de classes (2 niveaux) : il représente les classes intervenant dans le système. </li></ul></ul><ul><li>Les diagrammes comportementaux (Behavior Diagram) : </li></ul><ul><ul><li>Diagramme des cas d'utilisation (use-cases) : toutes les fonctionnalités que doit fournir le système. </li></ul></ul><ul><ul><li>Diagramme états-transitions (State Machine Diagram) : permet de décrire sous forme de machine à états finis le comportement du système </li></ul></ul><ul><ul><li>Diagramme d'activité (Activity Diagram) : permet de décrire sous forme de flux ou d'enchaînement d'activités le comportement du système ou de ses composants. </li></ul></ul><ul><li>Les diagrammes d'interaction ou dynamiques (Interaction Diagram) : </li></ul><ul><li>Diagramme de séquence (Sequence Diagram) : représentation séquentielle du déroulement des traitements et des interactions entre les éléments du système </li></ul>
    27. 27. Par où commencer? <ul><li>Les exigences (pas UML!) </li></ul><ul><ul><li>Pas obligatoire mais conseillé! </li></ul></ul><ul><ul><li>Les exigences commencent à être rédigées dès l’écriture du cahier de charges </li></ul></ul><ul><ul><li>On pourra lier les exigcnes à tous les diagrammes UML </li></ul></ul><ul><ul><ul><li>Pour faciliter l’analyse d’impact </li></ul></ul></ul><ul><ul><li>Pour faciliter l’écriture des exigences : possibilité de réaliser des diagrammes d’activité </li></ul></ul>Reformulation des besoins Reformulation des besoins
    28. 28. Modélisation des exigences : retour d’expériences <ul><li>Saisie des exigences dans EA </li></ul>
    29. 29. Exigences dans Modelio
    30. 30. Diagramme de cas d’utilisation (obligatoire) <ul><li>UC = Use Cases = Cas d'utilisation </li></ul><ul><li>Première phase de projet </li></ul><ul><ul><li>Cette phase va conditionner toutes les autres </li></ul></ul><ul><li>Les cas d'utilisation sont à la fois le concept le plus simple d'UML, le moins technique, mais aussi souvent le plus mal utilisé </li></ul>Reformulation des besoins Analyse Reformulation des besoins Analyse
    31. 31. UC et User Story <ul><li>User Story (Scrum) : description textuelle (sans diagramme) haut niveau du besoin </li></ul><ul><ul><li>« En tant que ... Je veux ... Pour ...&quot; </li></ul></ul><ul><li>UC : très similaire mais un peu plus détaillé </li></ul><ul><ul><li>Ajoute les pré et post-contions dans la description </li></ul></ul><ul><ul><li>Plusieurs scénarios (nominal, alternatifs) </li></ul></ul><ul><li>Un UC référence plusieurs stories </li></ul><ul><ul><li>Ex : Le UC « Planifier une itération » référence les stories : créer une itération, définir le but, identifier les tâches, estimer les tâches, démarrer l’ itération... </li></ul></ul>
    32. 32. Retour d’expériences : les UC
    33. 33. Conseils pour les UC <ul><li>Un cas d’utilisation </li></ul><ul><ul><li>Doit être simple: Utiliser le vocabulaire des utilisateurs </li></ul></ul><ul><ul><li>Ne pas spécifier comment (quoi!=comment) un système doit être réalisé, mais le service qu'il rend à l'utilisateur </li></ul></ul><ul><ul><ul><li>Faire exprimer les besoins, pas des solution (analyse != conception) </li></ul></ul></ul><ul><li>Accompagner ce diagramme de texte descriptif </li></ul><ul><li>En règle générale un seul acteur principal par cas d’utilisation </li></ul><ul><li>Faire valider par le client </li></ul>
    34. 34. Les cas d’utilisation : le point d’entrée! <ul><li>Fil conducteur du projet : définition des itérations par UC classés par priorité. </li></ul><ul><li>Les UC étaient les unités du Backlog (SCRUM) </li></ul>
    35. 35. Les cas d’utilisation : priorisation <ul><li>Classement (Analyse de la valeur) </li></ul><ul><ul><li>Par degré de priorité pour le client </li></ul></ul><ul><ul><li>Par activité/domaine fonctionnel </li></ul></ul><ul><ul><li>Par les risques encourus durant l’implémentation </li></ul></ul><ul><ul><li>Par risques technique, organisationnel, fonctionnel </li></ul></ul>
    36. 36. Traçabilité des exigences (conseillée) <ul><li>On lie ensuite les exigences aux Use case </li></ul><ul><li>Pour obtenir une matrice de couverture des exigences / UC </li></ul><ul><li>Intérêt : assurer la traçabilité des exigences par rapport à l’analyse </li></ul>
    37. 37. Enjeu: traçabilité des exigences dans le code <ul><li>Idéal pour l’analyse d’impact d’une demande changement </li></ul><ul><li>Solutions : </li></ul><ul><ul><li>Dans les commentaires ? Pas top ! </li></ul></ul><ul><ul><li>Ecrire ses propres annotations (Java) ? Mieux </li></ul></ul><ul><li>En place sur 2 projets chez Boiron depuis début 2011 </li></ul><ul><li>Une annotation = une exigence, un UC, une règle de gestion </li></ul><ul><li>Facilite l’analyse d’impact outillée </li></ul>
    38. 38. Synthèse : les livrables de l’analyse (1/4) <ul><li>Evidemment les UC! </li></ul>Reformulation des besoins Analyse Reformulation des besoins Analyse
    39. 39. Synthèse : les livrables de l’analyse (2/4) <ul><li>Diagrammes d’activité si nécessaire mais conseillé! </li></ul>Reformulation des besoins Analyse Reformulation des besoins Analyse
    40. 40. Le comportement d’un système <ul><li>2 possibilités pour modéliser le comportement d’un système </li></ul><ul><ul><li>Description de la succession des activités (ayant une durée) </li></ul></ul><ul><ul><ul><li>Utiliser des diagrammes d’activités (diag. comportemental) </li></ul></ul></ul><ul><ul><ul><li>Plutôt de haut niveau : appréhension du besoin métier </li></ul></ul></ul><ul><ul><li>Description de collections de scénarios d’interaction entre objets </li></ul></ul><ul><ul><ul><li>On s’intéresse aux objets qui échangent des messages. </li></ul></ul></ul><ul><ul><ul><li>Utiliser des diagrammes de séquence </li></ul></ul></ul><ul><ul><ul><li>Plutôt dédiés aux concepteurs/développeurs </li></ul></ul></ul><ul><ul><ul><li>On les utilise, à tort, souvent en lieu et place des diag. d’activités </li></ul></ul></ul>
    41. 41. Synthèse : les livrables de l’analyse (3/4) <ul><li>Eventuellement : diagramme d’état/ transition (facultatif) </li></ul><ul><li>Pour cerner les traitements métier (transition) </li></ul>Diagramme d’état/transition (facultatif) Eventuellement : diagramme d’état/ transition (facultatif) Pour cerner les traitements métier (transition) Eventuellement : diagramme d’état/ transition (facultatif) Pour cerner les traitements métier (transition) Reformulation des besoins Analyse Reformulation des besoins Analyse Reformulation des besoins
    42. 42. Synthèse : les livrables de l’analyse (4/4) <ul><li>Vision statique du système </li></ul><ul><li>Ex. de diagramme de classe d’analyse : </li></ul>Analyse
    43. 43. Diagramme de classe d’analyse <ul><li>Regroupe les concepts (entités) métiers </li></ul><ul><ul><li>Il s’agit du modèle du domaine </li></ul></ul><ul><li>Avant de faire des choix de solutions (conception logicielle), il faut bâtir un modèle du problème (analyse) </li></ul><ul><ul><li>Pour mieux comprendre le problème à résoudre </li></ul></ul><ul><ul><li>Pour obtenir un modèle aussi indépendant que possible des choix technologiques </li></ul></ul><ul><li>Remarque : le mapping 1 à 1 des objets métier et des objets logiciels ne sera pas systématique </li></ul><ul><li>Il comporte: </li></ul><ul><ul><li>les concepts du monde réel (entités métier) </li></ul></ul><ul><ul><li>leurs attributs </li></ul></ul><ul><ul><li>leurs associations logiques </li></ul></ul>Analyse
    44. 44. Du diagramme de classe d’analyse au diagramme de classe de conception (1/2) <ul><li>Le modèle de conception est déduit du modèle d’analyse (de domaine) </li></ul><ul><li>Les classes métier existantes sont détaillées, parfois divisées </li></ul><ul><ul><li>De nouvelles classes sont créées à caractère purement informatique (IHM, persistance des données,…) </li></ul></ul><ul><ul><li>Ajout de Design Pattern (Facory, Builder, etc.) </li></ul></ul><ul><li>L’élaboration du modèle de conception compte deux tâches clés: </li></ul><ul><ul><li>Attribuer des responsabilités aux objets </li></ul></ul><ul><ul><li>Concevoir des interactions entre les objets </li></ul></ul>
    45. 45. Du diagramme de classe d’analyse au diagramme de classe de conception (2/2) <ul><li>Le modèle de conception permet de: </li></ul><ul><ul><li>Ajouter des méthodes au diagramme </li></ul></ul><ul><ul><li>Rendre compte de la visibilité </li></ul></ul><ul><ul><li>Définir et faire ressortir les attributs de référence et les attributs simples </li></ul></ul><ul><li>Le modèle de conception représente vos classes java réelles de votre projet </li></ul>
    46. 46. Synthèse : les livrables de la conception <ul><li>Vision statique du système </li></ul><ul><li>Diagramme de classe de conception (obligatoire) </li></ul><ul><li>Stratgéie d’implémentation </li></ul><ul><ul><li>Commencez par la classe la moins connectée pour aller vers la + connectée </li></ul></ul><ul><ul><li>Implémentez et testez chaque classe de façon complète avant de passer à la suite </li></ul></ul>Conception Développement Preparation Lancer ( () Souche … Driver PersistanceMgr mettreAJourPrep() Classe de conception
    47. 47. Diagramme de classe de conception et code! <ul><li>Modèle de domaine </li></ul><ul><ul><li>Un pour l’analyste, un pour le concepteur </li></ul></ul><ul><li>Il est important que le diagramme de classe de conception soit toujours cohérent avec le code. </li></ul><ul><li>A cet effet : « forward » ou « reverse » engineering » </li></ul>
    48. 48. Forward et Reverse Engineering <ul><li>L’opération de « forward engineering » </li></ul><ul><ul><li>Consiste à générer du code à partir d’un modèle de classes. </li></ul></ul><ul><ul><li>N’a de sens que si les classes sont suffisamment concrètes </li></ul></ul><ul><ul><li>On connaît tous les attributs et toutes les méthodes publiques avec leur signature. </li></ul></ul><ul><li>L’opération de « reverse engineering » </li></ul><ul><ul><li>Consister à analyser du code (un ensemble de classes) et à construire un diagramme de classes. </li></ul></ul><ul><ul><li>Produit souvent beaucoup d’informations de bas niveau « inutiles » qu’il faudra masquer dans l’outil UML. </li></ul></ul>
    49. 49. Synthèse : les livrables de la conception <ul><li>Le diagramme de séquence (facultatif) </li></ul><ul><li>Vision dynamique du système </li></ul>Développement Conception
    50. 50. Diagrammes d'interaction ou dynamiques <ul><li>Rendent compte des messages et des interactions entre objets </li></ul><ul><li>Support pour concevoir la collaboration entre objets </li></ul><ul><ul><li>Les messages vont permettre de déduire les méthodes des objets </li></ul></ul><ul><li>UML en fournit deux types: </li></ul><ul><ul><li>Le diagramme de communication reflétant à la fois les échanges de messages et les relations entre objets </li></ul></ul><ul><ul><li>Le diagramme de séquence qui proposent un déroulement chronologique facile à suivre </li></ul></ul><ul><li>Nous privilégierons les diag. de séquence, plus intuitifs, mais ils restent facultatifs (coding direct possible!) </li></ul>Conception Développement Conception Développement Conception Développement
    51. 51. Pas que UML! <ul><li>Possibilité de remplacer les Use Cases par de simples User Stories </li></ul><ul><li>Les spécifications restent importantes: </li></ul><ul><ul><li>Format texte </li></ul></ul><ul><ul><li>Format Test d’acceptance (Behavior Driven Development): mieux! </li></ul></ul><ul><li>Les maquettes autant voire plus importantes que le diagramme en lui-même! </li></ul>
    52. 52. Modélisation en mode itératif <ul><li>Modéliser par incréments! </li></ul><ul><ul><li>Un modèle de domaine (classe) s’enrichit à chaque itération </li></ul></ul><ul><ul><li>Ne pas attendre d’avoir fini un diagramme avant de coder </li></ul></ul><ul><ul><li>Coder c’est modéliser, modéliser c’est coder! </li></ul></ul><ul><li>En mode peer-review : participatif </li></ul><ul><li>Comme la gestion du code source, il est important; </li></ul><ul><ul><li>que toute l’équipe partage un seul référentiel de modèles </li></ul></ul><ul><ul><li>de versionner les modèles </li></ul></ul><ul><ul><li>D’utiliser des outils SCM dédiés : SVN, GIT </li></ul></ul>
    53. 53. Modelio et le support SVN
    54. 54. Cas concret : Je suis développeur! <ul><li>Je travaille en mode itératif </li></ul><ul><li>Mon itération commence et j’ai un UC à développer </li></ul><ul><li>De quoi je dispose pour commencer mon développement? </li></ul><ul><li>Comment je travaille avec les modèles? </li></ul><ul><li>Qu’est-ce que je livre? </li></ul>
    55. 55. En entrée je dispose (dans SVN ou Git!) : <ul><li>Du diagramme de classe d’analyse à jour vis-à-vis de mon UC (analysé dans l’itération précédente) </li></ul><ul><li>Du diagramme de classe de conception non à jour vis-à-vis de mon UC </li></ul><ul><li>De manière facultative d’autres diagrammes d’analyse : </li></ul><ul><ul><li>Diagrammes d’activité, d’état-transition </li></ul></ul><ul><li>De mon UC et de la spec de mon UC </li></ul><ul><li>De la maquette </li></ul>
    56. 56. Pendant mon développement <ul><li>Je peux faire quelques diagrammes de séquence </li></ul><ul><li>En itératif: </li></ul><ul><ul><li>Je peux mettre à jour à la main le diagramme de classe de conception et faire du forward engineering sur ce que j’ai modifié </li></ul></ul><ul><ul><li>Je code </li></ul></ul><ul><ul><li>Je teste </li></ul></ul><ul><li>En mode reverse, je met à jour le diagramme de classe de conception </li></ul><ul><li>Je commite dans SVN ou Git mon code ET les diagrammes modifiés </li></ul>
    57. 57. Conclusion <ul><li>UML est : </li></ul><ul><ul><li>Un langage intuitif, homogène et cohérent pour visualiser, spécifier, construire et documenter un système informatique. </li></ul></ul><ul><li>UML n’est pas : </li></ul><ul><ul><li>Un processus de développement ni une méthode de gestion de projet </li></ul></ul><ul><ul><li>D’où l’importance de la méthodologie associée : l'agilité! </li></ul></ul><ul><li>UML est le standard, mais adoptez juste le sous-ensemble nécessaire et suffisant ! (Règle des 80 / 20) </li></ul><ul><li>La valeur ajoutée principale est dans l’activité de modélisation elle-même, non dans le modèle obtenu! </li></ul><ul><li>Every model is wrong! and that’s OK (Larman) </li></ul>
    58. 59. Livres : Les agilistes et UML <ul><li>Martin Fowler “UML Distilled: A Brief Guide to the Standard Object Modeling Language” </li></ul><ul><li>Alistair Cockburn “Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process” </li></ul>
    59. 60. Livres : Les agilistes et UML <ul><li>Alistair Cockburn “Writing Effective Use Cases” </li></ul><ul><li>Le livre et le site de Scott Ambler www.agilemodeling.com </li></ul>

    ×