Note de lecture : Patterns for Effective Use Cases, par Steve Adolph & Paul Bramble, with Alistair Cockburn & Andy Pols

Note: 7 ; Un (excellent) complément au « Writting Effective Use Cases » d’Alistair Cockburn.

Les cas d’utilisation sont un peu passés de mode depuis la grande époque UML, jusqu’au début des années 2000. C’est bien de cette époque que date cet ouvrage dont on peut pourtant dire qu’il serait injuste de le considérer comme passé de mode ! Il s’inscrit dans la lignée du « writting effective Use Cases » d’Alistair Cockburn qui promeut une écriture intentionnelle, courte et efficace par rapport aux Cas d’Utilisation « interactionnels » qui noircissent beaucoup de pages et ont donné une image si déplorable de cette pratique.

L’ouvrage a adopté le forme « Pattern Language ». Elle n’est pas toujours appropriée pour un livre d’environ 200 pages, mais on doit bien constater qu’ici cela ne pose guère de problème. Ceux-ci sont partitionnés sur 7 chapitres (auxquels il faut ajouter le chapitre introductif). Chaque pattern occupant environ 6 à 8 pages, donc assez pour être développé et pas trop pour ne pas devenir indigeste. Le premier chapitre investigue ce qu’est réellement un cas d’utilisation de qualité. C’est du moins la promesse faite par ce chapitre dont le titre est un peu trompeur. Si les auteurs nous montrent effectivement ce qu’est un bon Cas d’utilisation par rapport aux mauvais cas d’utilisation (toute ressemblance avec les bons et les mauvais chasseurs…), le chapitre sert surtout de table de matière et au langage de patterns et d’introduction à la forme pattern. Cela dit, il n’y a rien de mal à cela et c’est même nécessaire.

Le chapitre 2 nous prend un peu par surprise : « The Team » évoque les aspects collaboration et coopération gravitant autour de l’écriture des cas d’utilisation ! Ainsi, ParticipatingAudience met l’accent sur l’implication des utilisateurs et des parties prenantes, tandis que BalancedTeam détaille la pertinence de former des groupes d’écriture diversifiant les points de vue. En réalité, les éléments évoqués sont un peu des nouvelles d’hier, mais les expliciter ne peut pas faire de mal. Le chapitre 3 « The Process » s’inscrit dans la continuité. Le chapitre est assez riche et ne commet pas l’erreur de proposer un workflow de rédaction. BreathBeforeDepth est sans doute l’un des patterns cruciaux de ce chapitre. Les auteurs y référencent de très nombreux autres patterns, sans doute trop. Mais le propos est crucial pour la réussite d’une démarche « cas d’utilisation ». Je suis plus surpris d’y trouver TwoTierReview qui aurait d’avantage eu sa place dans le chapitre précédent, à mon avis. Le QuittingTime est une bonne idée : il rappelle que « pas trop n’en faut » et qu’ajouter du détail peut être contre-productif. C’est une mise en garde dont j’ai eu à faire bon usage, car je dois avouer avoir été coupable de ce travers !

Lire la suite
Publicité

Note de lecture : Use Cases : Requirements in Context, par Daryl Kulak & Eamonn Guiney

Note : 6 ; Bonne mise en pratique du cycle itératif et de bonnes idées, mais pas entièrement concluant.

Ce livre présente les cas d’utilisation dans le cadre d’un processus itératif, en fait celui d’Unfied Process. A ce titre, il propose une approche incrémentale pour la spécification des cas d’utilisation, basée sur celle de Craig Larman. Cet ouvrage taille aussi un short à la gestion des exigences, par rapport auxquels les auteurs préfèrent la spécification des règles métier, même si en fait c’est surtout la production de gros documents de spécification monoblocs qui est remise en cause. La description des spécifications incrémentale est réellement valable et concrète, et de plus desservie par des exemples concrets en annexe.

La construction du livre est un peu curieuse, car les annexes forment la moitié de l’ouvrage, le texte principal ne comptant que 170 pages structurées en 11 chapitres. Le premier d’entre-eux consacre ses 18 pages à l’identification des problèmes liés à l’approche classique. La prose manque un peu d’élan lyrique, mais s’efforce néanmoins de bien synthétiser ces points d’achoppement. Disons que le boulot est fait.

Le second chapitre s’étend sur 32 pages, il s’agit d’une introduction aux cas d’utilisation d’inspiration très « Gery Schneider ». On y aborde plutôt efficacement les basiques de la représentation des cas d’utilisation et les bonnes règles de conduite. Plus globalement on y traite aussi des cas d’utilisation dans l’environnement UML. Un chapitre rondement mené.

Lire la suite

User Stories … What else ?

Voici le support de ma présentation, faite lors d’Agile Grenoble 2013. Elle aborde le sujet épineux de l’emprunt de techniques issues du monde non-agile dans nos projets agiles !

Le teaser

Les users stories sont rapidement devenus la formulation convenue du besoin. Mais est-ce la seule ? Est-ce toujours la meilleure ? On dit que quand on a un marteau, tout ressemble à un clou. Notre communauté agile tend à ignorer ce qui vient d’ailleurs. Pourtant ce qu’on appelle l’ingénierie des exigences est un domaine riche de plusieurs décennies de connaissances et de techniques. Certaines peuvent être utilisées directement, d’autres doivent être adaptées ou peuvent servir d’inspiration.

Cette présentation va nous permettre d’étudier ensemble plusieurs techniques et concepts du recueil des besoins et les regarder par le prisme de nos pratiques agiles. A l’aide d’exemples, nous verrons comment elles peuvent renforcer nos pratiques actuelles.

Ce que vous allez en retirer

Découvrir l’ingénierie des exigences, prendre conscience de la profondeur de ce domaine de connaissance. A la fin de cette session les participants auront des clés pour enrichir leur maitrise de la capture du besoin en s’alimentant hors du champs de l’agilité, et j’espère le goût de le faire !

Si j’ai assez de courage, je produirais cette présentation sous forme d’article. Mais alors pas avant Janvier !

A la conquête du Story Mapping

Il n’y a pas (encore) d’ouvrages traitant du Story Mapping, un technique développée par Jeff Patton. Elle comble une lacune de l’approche fonctionnelle agile basée sur les User Stories qui proposent une manière de cartographier ceux-ci sur des axes orthogonaux : le processus et la réalisation incrémentale.
Pour moi, il s’agit d’un outil supplémentaire à embarquer dans ma besace de pratiques agiles. Je ne vais pas les considérer comme un passage obligé des projets agiles, tout comme je ne suis pas prêt à accepter l’idée que les User Stories sont le moyen unique d’exprimer un besoin utilisateur (ce qui nous conduit par ailleurs à la notion de “story technique” que je rejette purement et simplement).
Le Story Mapping se situe au même niveau d’usage que les Cas d’Utilisation, une technique écartée par la plupart des agilistes, mais pas par moi (je reste en bonne compagnie sur ce point). Cette technique présente certains avantages par rapport aux cas d’utilisation, et ces derniers exhibent d’autres atouts. Nous reviendrons peut-être un autre jour là-dessus : Jean-Claude Grosjean et moi-même avions même évoqué l’idée de faire une présentation commune sur ce sujet un jour !
Pour le story mapping :

  • Structuration bottom-up des user stories.
  • Agencement des stories dans un processus (quand celui-ci reste simple)
  • Agencement par itération visible dans la map.
  • Un processus de travail collectif.

Pour les cas d’utilisation :

  • Une structuration “divide and conquer” top-down du besoin fonctionnel.
  • Une bonne structuration par unité fonctionnelle cohérente en lien avec des acteurs.
  • Un bonne structuration fonctionnelle intrinsèque avec l’articulation des scénarios.
  • Un niveau de structuration fonctionnel qui peut servir de charnière avec de nombreuses activités : UX, acceptante testing, etc…

A défaut d’avoir la référence ultime, j’ai essayé de collecter ici des ressources sur le sujet. Notons d’ailleurs au passage que la 3ème édition du livre de Claude Aubry évoque cette technique.

L’article de référence de Jeff Patton

Il décrit les étapes de la technique. Il n’a pas simplement un “intérêt historique”. Il reste tout à fait pertinent. En fait, je conseille de commencer par lire cet article !

Jeff Patton présente également son approche sur son site.

Pour ceux qui préfèrent le format “slides”, c’est juste ici:

La présentation de Steve Rogalsky

C’est un peu le “Story Mapping from the Trenches” : une présentation très visuelle sur la façon de faire du story mapping, où le présentateur montre comment lui-même opère concrètement. Une bonne illustration de l’article de Jeff Patton !

Par ailleurs, Steve Rogalsky a développé la matière de cette présentation via une série de posts :

Laurence Hanot : construisez votre produit en racontant des histoires !

J’avais assisté à la présentation de Laurence à Agile France, c’est une occasion de mettre en avant sa présentation qui est une introduction à la technique

De l’impact mapping au Story Mapping

Cette présentation m’a été indiquée par Gojko Adzic. A voir et revoir car elle fait le lien avec l’impact Mapping

Autres ressources

Note de lecture : Use Case, patterns and blueprints, par Gunnar Övergaard & Karin Palmkvist

Note : 3 ; Des patterns qui n’en ont que le nom et des préoccupations exagérément focalisées sur la structuration.

En voyant le nom du disciple d’Ivar Jacobson en auteur de ce livre, je m’attendais à une vision Jacobsionienne, mais aussi à de bonnes choses. Très curieusement, je n’ai eu aucun des deux points.

Parlons déjà du volet « patterns », pour commencer. Franchement, je ne sais pas pourquoi on a laissé passer ce texte dans la SPS series, car si le livre de Steve Adolph et al. (Patterns for effective use cases) présente bien des patterns, celui-ci fait seulement semblant. Ceux-cis sont mal cadrés, aucune description de problème ne les introduisent, ils ne sont pas compréhensibles, et d’ailleurs ils ne servent en fait que d’introduction à la discussion qui s’en suit. Deux autres parties suivent la partie pattern, une partie « blueprint » qui sont des applications concrètes (en fait plus proches de ce que devraient être des use case patterns), mais toujours de peu d’intérêt, et une partie « mistakes » plus intéressante mais longue de seulement 30 pages (le livre en compte 420) !

Pour ce qui est du fond, ce livre est malheureusement un danger, car il se focalise excessivement sur les relations entre patterns : relations d‘inclusion et d’extension et généralisation, rendant les modèles de cas d’utilisation bien trop techniques et pas assez lisibles. Un véritable danger pour le pratiquant débutant !

Du coté des bonnes nouvelles, le livre intègre (outre les patterns) une introduction à la modélisation des cas d’utilisation assez bien faite et réduite à 100 pages (donc, bien). Si j’agonit de critiques l’excès de structuration, je dois aussi avouer qu’aucun texte ne détaille aussi bien la relation d’extension, et les possibilités offertes par les points d’extension. De même, les auteurs proposent une façon de documenter les cas d’utilisation parent et enfants dans une relation de généralisation qui est plutôt intelligente. Enfin, c’est le seul texte à ma connaissance qui décrive précisément et utilise les instances de cas d’utilisation. Ceci intéressera donc les académiciens d’UML (donc aussi le théoricien qui sommeille en moi).

Globalement, un livre que je déconseille, et qu’il faut absolument mettre hors de portée des non experts.

use-cases-patterns-blueprints

Référence complète : Use Case, patterns and blueprints – Gunnar Övergaard & Karin Palmkvist – Addison Wesley / Software Patterns series 2004 – ISBN: 0-13-145134-0

Use Cases: Patterns and Blueprints


http://www.goodreads.com/book/add_to_books_widget_frame/0131451340?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Succeeding with Use Cases, Working smart to deliver quality par Richard Denney

Note : 6 ; Excel à la rescousse des cas d’utilisation, ou comment les colorier au-delà du trait.

Ce livre ne va pas vous apprendre à modéliser avec les cas d’utilisation, mais il va vous apprendre à les utiliser plus avant, notamment dans une optique qualitative. Ce livre est découpé en 4 parties indépendantes, qui constituent autant de facettes d’utilisation améliorée des cas d’utilisation.

La première partie est consacrée aux « QFD » ou Quality Function Deployment, qui permet non seulement de tracer les cas d’utilisation vers les « business drivers » ou vers les exigences, mais permet d’en calculer les priorités. La méthode est simple et adaptable, et si l’on considère que l’auteur va jusqu’à montrer concrètement comment la matrice QFD se construit avec Excel, on ne voit guère ce qui empêche d’exploiter cette technique.

Excel est également utilisé dans la seconde partie dédiée aux SRE (Software Reliability Engineering), dont le but est d’adapter l’effort de développement et de test à la « qualité perçue » et à l’usage opérationnel réel des cas d’utilisation, ces ratios d’usage réel étant construit d’après les étapes de UC effectivement parcourues, et d’après la nature des relations entre cas d’utilisation lorsqu’il y en a. Si l’usage opérationnel réel est utile, entre autre pour se fixer des objectifs de disponibilité opérationnel et de fiabilité, les méthodes de calcul liées à l’effort de test sont complexes et la pertinence de leur mise en œuvre limitée à certains types de projets.

La troisième partie est dédiée aux préconditions, postconditions et invariants. Elle emprunte beaucoup aux méthodes formelles, ce qui explique probablement un certain désintérêt de ma part. Hélas, l’exemple appuyant cette partie n’aide pas à rendre le propos plus clair.

La quatrième partie est dédiée à la gestion de la configuration, dont un chapitre est dédié au calcul du ROI, et un autre au « project portfolio management ». Si ce dernier chapitre ne m’a guère convaincu, par contre celui dédié au ROI est particulièrement concret et utilisable.

Cet ouvrage se démarque clairement des autres livres consacrés aux cas d’utilisation, car il est dédié à « ce que l’on peut faire avec les cas d’utilisation ». Bien que certaines parties s’appuient sur un formalisme très poussé, une grande partie est directement utilisable sur pratiquement beaucoup de type de projet.

succeeding-use-cases

Référence complète : Succeeding with Use Cases, Working smart to deliver quality – Richard Denney – Addison Wesley / O.T. series 2005 – ISBN: 0-321-31643-6

Succeeding with Use Cases: Working Smart to Deliver Quality


http://www.goodreads.com/book/add_to_books_widget_frame/0321316436?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Aspect-Oriented Software Development with Use Cases, par Ivar Jacobson & Pan-Wei Ng

Note : 3 ; Ou comment aller trop loin avec les cas d’utilisation.

Jacobson a décidé de surfer sur la vague des aspects, et d’offrir une nouvelle tenue « coloriée aspects » à ses cas d’utilisation à cette occasion. Pour cela, il s’est adjoint les services de Pan-ei Ng, qui a d’ailleurs en fait écrit la très grande partie du texte. Cela n’est pas un problème, car ce dernier tient fort bien la plume.

Le point de départ de ce livre est un article d’Ivar Jacobson écrit en 1986 sur une idée proche des « crosscutting concerns ». Ayant exhumé cet article et développant à partir de celui-ci, les auteurs ont fait évoluer l’approche des cas d’utilisation dans deux directions :

  • Structuration intensive des cas d’utilisation, utilisant intensivement la relation « extend » qui est la pierre angulaire du rapprochement avec l‘AOD. Cette structuration intensive s’accompagne de l’émergence de cas d’utilisation d’infrastructure. Bref, à mon avis cette approche s’éloigne d’un média de communication avec les utilisateurs car elle complexifie à outrance les cas d’utilisation. A cet égard, cette direction se rapproche des « use case patterns » de Gunnar Övergaard. Les spécifications de l’extension sont aussi beaucoup plus développé afin de ressembler aux « join points », le reste est à l’avenant : intéressant pour l’informaticien, moins pour celui qui ne l’est pas.
  • Les « use case slices » et « use case modules » : sont la structuration objet d’analyse. Plutôt que développer une architecture orthogonale au modèle des besoins, les auteurs soutiennent une bijection entre les cas d’utilisation et la structuration en « use case slices ». On aboutit ainsi à un système architecturé par les cas d’utilisation (même si les auteurs ne dénient pas la factorisation), ce qui me plonge dans un abîme de perplexité.

C’est vrai, il y a une corrélation forte entre les points de jonction de l’AOD et la relation « extend », et si le sujet mérite certains développements, je n’adhère pas franchement aux extrémités des auteurs qui nous éloignent par trop de la simplicité et des qualités de communication inhérente des cas d’utilisation. D’ailleurs l’ouvrage lui-même devient parfois un peu obscur. Limiter volontairement son volume à moins de 250page aurait certainement pu le rendre plus limpide.

Bref, une lecture tout ce qu’il y a de plus facultative.

aspect-or-soft-dev-use-cases

Référence complète : Aspect-Oriented Software Development with Use Cases – Ivar Jacobson & Pan-Wei Ng – Addison wesley / O.T. series 2005 – ISBN : 0-321-26888-1

Aspect-Oriented Software Development with Use Cases


http://www.goodreads.com/book/add_to_books_widget_frame/0321268881?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Applying Use Cases 2nd edition, par Geri Schneider & Jason P. Winter

Note : 9 ; Un simple raffinement d’un livre déjà excellent, mais qui va dans le bon sens.

J’ai quelques références sur les Use Cases dans ma bibliographie. Ce texte-ci est l’un de mes préférés, sinon mon préféré. Historiquement, à mon échelle, c’est par la note de lecture de la 1ère édition de ce livre que j’ai commencé ma compilation bibliographique il y a maintenant 14 ans.

C’est un ouvrage succinct (environ 170 pages hors annexes), exclusivement destiné aux uses cases, à leur utilisation, leur développements (use case scénarios, diagrammes d’activité, liens vers la modélisation), leur documentation. Le propos est très clair, très direct et bien illustré à l’aide d’un exemple développé au long du livre. La taille réduite du livre fait partie de ses qualités, la substance utile étant très importante. 

Pour cette seconde édition, je m’attendais à d’avantage d’évolutions. En fait, les auteurs ont simplement repris leur matériel de base, en le réorganisant et en mettant à jour certains concepts (relations “includes” et héritage, ainsi que cas d’utilisation subordonnés).  La partie la plus faible de l’édition précédente (documentation des cas d’utilisation) a désormais atteint la qualité des autres chapitres et certains nouveaux thèmes ont été abordés comme les Use Case “CRUD” et les exigences complémentaires. La lourde description de l’étude de cas qui encombrait un peu l’ouvrage a été rejeté en annexe ou elle figure désormais de façon plus complète. Finalement, les auteurs ont réussi le tour de force de remettre à jour cet ouvrage sans nous pénaliser de l’augmentation de volume qui en est le corollaire. Toujours excellent, donc.

Un livre que je conseille très fortement, sans arrières pensés.

applying-usecases-2

Référence complète : Applying Use Cases, second edition, a practical guide – Geri Schneider & Jason P. Winter – Addison Wesley / O.T. series 2001 – ISBN: 0-201-70853-1

Nb: La première édition de cet ouvrage était mon “book of the year” 1998

Applying Use Cases: A Practical Guide


http://www.goodreads.com/book/add_to_books_widget_frame/0201708531?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Writing Effective Use Cases, par Alistair Cockburn

Note : 7 ; D’excellents conseils rédactionnels et une bonne approche “adaptative” de la modélisation des systèmes.

Ce livre se focalise entièrement sur la rédaction textuelle des cas d’utilisation. A ce titre, il relativise la description graphique comme étant une vue synthétique du périmètre fonctionnel. Alistair prêche une approche par décomposition fonctionnelle dans laquelle on part des business cases pour descendre jusqu’à des uses cases de type sous routines. A chaque niveau (représenté par une icône) on détermine l’objectif de l’acteur principal comme étant la force essentielle dans la détermination du cas d’utilisation.

Le livre est excellent pour ce qui est de décrire des Use Cases optimaux et clairs, donc suffisamment courts et concis pour être lus et compris. Qui plus est, des mémentos permettent de se rappeler quelles sont les règles à suivre dans l’écriture des Use Cases. Ce livre est d’avantage dédié aux personnes pratiquant déjà les cas d’utilisation et désireuses de progresser qu’aux nouveaux venus qui risquent de se retrouver quelque peu noyés. Enfin certains aspects tels que la décomposition fonctionnelle utilisant abondamment les relations d’inclusion sont critiquables voire dangereuses lorsque utilisées à mauvais escient.

writing-effective-use-cases

Référence complète : Writing Effective Use Cases – Alistair Cockburn – Addison Wesley / Crystal Collection for Software professionals 2001 – ISBN: 0-201-70225-8; EAN: 978-0-201-70225-5

Writing Effective Use Cases


http://www.goodreads.com/book/add_to_books_widget_frame/0201702258?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on