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é.

Le chapitre 3 aborde enfin une des originalités de l’approche des auteurs : le « business rules catalog ». Ce chapitre sert aussi d’introduction aux chapitres suivants en présentant les 4 niveaux de raffinement de ce business catalog.

Justement, c’est à la première étape de raffinement, la « façade iteration » que le chapitre 4 est dédié. Ce niveau de complétion correspond à des cas d’utilisation de niveau « résumé », avec une identification sommaire des règles métier. Les auteurs ont en fait un idée très précise de ce que signifie ce niveau de complétion. Trop même, car le processus s’avère franchement prescriptif !

Le chapitre 5 consacré au niveau de complétion suivant, le « filled iteration » suit le même schéma que le chapitre précédent, d(ailleurs il a pratiquement la même longueur. La vue très « processus » des auteurs et l’aspect répétitif des chapitres (pour ne pas parler des suivants) s’avère même un peu ennuyeuse.

On poursuit au chapitre 6 qui couvre la « focused iteration ». Un chapitre plus léger de 14 pages qui va plus droit à l’essentiel que les deux précédents. Dans la même veine, le chapitre 7 « finished iteration » est même encore plus court avec 8 pages !

Le chapitre 8 « managing requirements » est véritablement une vue gestion de projet. On y couvre des thèmes tels que la nature itérative et incrémentale du travail, la gestion des risques et les estimations.

Avec 4 pages, le chapitre 9 « working in team » est le plus court du livre. Sans rentrer dans le détail, il semble que les auteurs se soient sentis obligés de dire quelques mots sur le sujet, mais le résultat n’est ni utile ni convainquant.

Le dernier chapitre « classic mistakes » nous donne sur 15 pages des points de repère pour progresser. Hormis la présentation en tableau un peu pénible, le contenu est tout à fait valable. L’annexe A qui suit « beyond use cases » aurait pu être un chapitre du livre : on y évoque les articulations que peuvent avoir les cas d’utilisation par rapport aux autres travaux d’ingénierie. Le 5 pages de cette première annexe ne sont pas suffisantes pour couvrir décemment cet aspect. Il est mieux couvert dans « Applying Use Cases ».

Les chapitres du livre s’appuient sur un cas d’utilisation. La documentation de celle-ci dans son état finalisé est disponible dans l’annexe B. On en prend pour 140 pages : qui a envie de lire cela ?

Du coté des regrets, je ne suis guère convaincu par la séparation règles métier (qui se mappent sur les cas d’utilisation mais dont on ne peut déterminer les critères de vérification) et des spécifications non fonctionnelles (qui ressemblent à des exigences, mais ne sont pas mises en relation avec les cas d’utilisation). Je pense également que les annexes sont par trop volumineuses (elles représentent la moitié du livre), entre autre 2 exemples concrets de 60 pages chacun c’est trop. Un seul aurait suffit, et faire apparaître les différences entre 2 itérations dans une autre couleur aurait été une bonne idée.

En conclusion, le livre est raisonnablement bon, mais je continue à préférer celui de Geri Schneider. A noter qu’une seconde édition de cet ouvrage existe.

image

Référence complète : Use Cases : Requirements in Context – Daryl Kulak & Eamonn Guiney – Addison Wesley / A.C.M. Press 2000 – ISBN : 0-201-65767-8

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s