Cas d'utilisation agiles : de l'Expression à l'Élaboration des Besoins
|
Site Web
Thierry Cros Cas d'utilisation agiles : de l'Expression à l'Élaboration des Besoins |
| | Accueil | Extreme Programming | UML, Objet | Formation | Consulting | Liens | Contact | |
| Cet article présente une "boite
à outils" destinée à doter les projets
des moyens nécessaires à l'expression de
besoins. Cela dépasse largement le cadre strict des
formalismes et concepts des cas d'utilisation de l'UML
pour aborder la question des convictions ou bien de
l'environnement du projet (sa logistique). Il s'adresse
à tous ceux (MOA, MOE et représentants)
engagés dans l'expression de besoins, que ce soit pour
les rédiger ou bien pour les réaliser. L'essentiel se situe dans les ressources : rôles, concepts, pratiques,etc. Toutefois, il s'agit de bien comprendre la problématique et de fixer un objectif. Ces aspects sont présentés dans les autres chapitres. Le modèle SCORE est appliqué pour mieux cerner la question fondamentale : comment mieux exprimer les besoins ? Sommaire
Les symptômesL'expression des besoins, des exigences, n'est généralement pas une activité perçue comme étant "facile". La relation aux "besoins" est parfois mal vécue : ils changent trop, ils sont en réalité difficiles à exprimer, ils ne sont pas clairs, pas "au bon niveau". Autrement dit, cette activité technique (bien qu'elle ne soit pas toujours perçue en tant que telle) est d'autant plus délicate qu'elle met "face à face" les deux parties prenantes les plus importantes du projet : le maître d'ouvrage et le maître d'oeuvre, ou bien leurs représentants. Plus encore, l'expression de besoins est parfois "court-circuitée" au point d'être reportée aux activités ou phases suivantes du projet.^ top ^ Les causesIl semble que les causes essentielles de ce dysfonctionnement résident dans des certitudes ou représentations mentales erronées :— les besoins devraient être figés une fois pour toutes — le client sait exactement ce qu'il veut, la question réside simplement dans l'expression. — un changement dans les demandes du client est "forcément" un problème — l'expression de besoins est une activité naturelle et évidente qui ne demande pas de formation ou de talent particulier — le développeur (le maître d'oeuvre) connaît bien le métier du client et sait lire entre les lignes — l'interaction entre le futur logiciel et le métier - ses procédures - est négligeable — une lecture de documents suffit à comprendre l'expression de besoins — un changement, sans être un problème est malgré tout une déviation du plan projet initial : cela ne se passe pas comme prévu, ce n'est plus "nominal" — le projet se termine lors de la mise en service de la v1, ensuite ce sera la "maintenance" : démobilisation de toutes les ressources — le client disparaît des phases de développement et ne réapparaît qu'à la fin du projet, c'est normal, il n'a rien à faire lors du développement. Ces croyances ou convictions génèrent des pratiques, une logistique. Et le résultat est celui que nous connaissons sur les projets. ^ top ^ L'objectifLa finalité n'est pas simplement d'expliquer une nième fois la mise en oeuvre des cas d'utilisation, plutôt proposer une ébauche de ce qui pourrait être la boite à outils de l'expression de besoins. Il s'agit bien d'outils, de ressources destinées à tous les acteurs parties prenantes dans cette activité.Cette boite à outils pourrait être considérée comme ressource des processus CMMi tels que "Gestion des exigences" du niveau 2 et "Développement des exigences" du niveau 3. ^ top ^ Les ressourcesNous examinerons successivement les rôles, les convictions ou certitudes nouvelles, les concepts techniques, les pratiques de chaque participant, la logistique nécessaire.Les rôlesSans entrer dans les détails spécifiques à chaque projet, chaque domaine, deux rôles essentiels s'identifient clairement dans le projet :
Chaque situation engendre ensuite ses propres nécessités en termes d'intervenants. Citons par exemple l'ingénieur qualité coté MOE ou bien un spécialiste juridique pour la MOA, etc. ^ top ^ Convictions nouvellesIl est crucial de communiquer de nouvelles certitudes ou croyances aux intervenants. Il ne s'agit de croire sur parole, simplement montrer d'autres façons de concevoir ce qu'est un projet de développement, en particulier l'expression de besoins dans le cadre de cet article. De façon générale, le vécu, l'expérience des participants constitue un vivier dans lequel puiser les preuves a posteriori. Par exemple, une bonne communication entre MOA et MOE est souvent reconnue comme atout dans la réussite du projet. Il faut alors considérer cette expérience vécue - un projet réussi grâce à une bonne communication - en tant que référence, qu'ancrage important pour les personnes engagées dans le succès de l'entreprise.Les valeurs des méthodes agilesParmi les croyances-fondations de cet article citons les valeurs des méthodes agiles : répondre aux changements contraint le plan, etc. Toutefois, la technique préconisée par l'Extreme Programming n'est pas directement reprise ici : les histoires-utilisateur ou scénarios ou user stories supposent un haut niveau de communication, une certaine unité d'espace et de temps rhédibitoires, souvent absentes de bien des projets. Plus profondément, les cas d'utilisation offrent une valeur ajoutée en terme de modélisation de l'expression de besoins.L'expression de besoins est un travail collectif : client et développeurLes besoins changent et c'est normalLe changement... En ce qui concerne les besoins exprimés par un client, plusieurs éléments sont à considérer. Le premier point à bien comprendre est que le client ne connaît pas toujours précisément les besoins et cela est légitime de sa part. En effet, le nouveau logiciel objet du projet est peut-être composant d'un plan plus vaste de réorganisation ou amélioration chez le client. Dès lors, il s'agit de bien mesurer l'aspect évolutif des processus métier et donc l'impact sur les spécifications du logiciel.Dans le même ordre d'idées, il est difficile pour le client de spécifier en aveugle, autrement dit d'écrire des pages et des pages d'exigences sans aucun feedback. Or, le seul feedback réaliste est celui fourni par l'utilisation du produit lui-même. D'où l'intérêt de principes de l'Extreme Programming : petit investissement de départ ou bien feedback rapide. ^ top ^ Modéliser offre une valeur ajoutée"Modéliser" consiste à représenter un système selon un certain point de vue. C'est la définition UML du modèle. De façon générale, l'activité même générale d'ingénierie suppose une modélisation : plans de l'architecte, équations, etc. Il suffit de consulter quelques appels d'offres pour constater l'utilisation massive et anarchique de la modélisation non standard. L'intérêt majeur de l'UML est d'offrir a contrario un standard, donc plus facilement communiqué. Il convient dès à présent de bien distinguer l'UML en tant que langage de modélisation unifié et les outils dits "modeleurs" qui ne sont qu'une modalité possible d'écriture de l'UML. Si les diagrammes sont la partie "visible" du langage ou de son utilisation, il reste que cette ressource permet aussi de penser, comme tout langage, grâce aux concepts également standards.Les concepts : connaissances techniquesLes cas d'utilisation de l'UMLL'article Lecture des Cas d'utilisation constitue une introduction aux concepts et formalismes des cas d'utilisation. Rappelons brièvement qu'un cas d'utilisation est une situation dans laquelle un acteur (ie un élément externe qui interagit avec le système) est amené à effectivement interagir avec le logiciel. Une utilisation effective de cette technique suppose généralement la mise en oeuvre de l'ensemble des concepts et formalismes proposés par UML.
^ top ^ Les niveaux de cas d'utilisationUne autre clé est qu'un ensemble d'interactions peut se situer à plusieurs niveaux. Ces niveaux apparaissent très clairement dès lors que l'on met en oeuvre effectivement cette technique des cas d'utilisation sur un projet. Le client, naturellement, décrit les interactions à un niveau qui correspond généralement à la plus forte valeur ajoutée. Autrement dit à un "moment" de l'utilisation de l'application qui "oublie" des interactions (typiquement, la connexion est souvent parfaitement ignorée par le client qui se concentre naturellement sur le véritable "plus" du système). Les développeurs aimeraient bien pouvoir "embrasser" l'ensemble du système, mieux appréhender le métier, les procédures sous-jacentes aux différentes situations d'utilisation.Selon Alistair Cockburn, il existe ainsi trois niveaux principaux qu'il situe allégoriquement par rapport à un niveau de référence qui est "celui de la mer". J'appelle ces niveaux :
^ top ^ ScénariosSi UML préconise un processus de développement piloté par les cas d'utilisation (ce qui est hors contexte de cet article), il est clair que la gestion du projet s'entend plus précisément par scénario. Cela apparaît clairement dans la pratique "analyse" de la MOE. Il est donc important de bien comprendre ce qu'est un scénario et la différence qui existe ainsi entre cas et scénario. D'un point de vue technique, nous pourrions dire qu'un scénario est au cas ce qu'un objet est à la classe. Plus précisément, un scénario est une lecture spécifique, dans laquelle il est recommandé de fixer simplement des valeurs aux interactions de tel ou tel acteur. De façon générale, les parties prenantes s'attacheront à définir les scénarios pertinents, nécessaires et suffisants, dans les modes : nominal, limite, erreur.InteractionsEncore une fois, comprendre la modélisation par les interactions entre acteurs et système est réellement un atout majeur, catalyseur de la réussite de l'expression de besoins. Le client doit alors se mettre en position d'utilisation imaginée, visualisée du système et ainsi décrire les interactions qu'il souhaite.Une interaction est un échange et à ce niveau de modélisation, le système est une boite noire. Ainsi, une description textuelle sera constituée d'étapes qui représenteront les apports de l'acteur vers le système (les "entrées") et inversement les apports du système vers les acteurs. Notons qu'il convient de décrire la signification des échanges et non pas leur forme. Pour cela, le maquettage est une activité complémentaire et particulièrement efficace pour mettre le client "en situation" d'utilisation. ^ top ^ CARA : des ressources pour une expression agile des besoinsVivre un changement de savoir-faire suppose quelques ressources personnelles pour que ce soit un succès de chaque individu. CARA : Courage, Attention, Responsabilité, Assertivité est un exemple de qualités personnelles qu'une éthique professionnelle devrait promouvoir pour plus d'efficacité - et donc de rentabilité - dans les projets.Les pratiquesLes pratiques proposées ici se concentrent sur l'expression de besoins. Bien d'autres activités : techniques, managériales, doivent compléter les travaux de l'équipe projet. De même, le macro-processus - ou cycle de vie - dans lequel s'inscrit l'expression de besoins est hors cadre de cette étude, bien qu'intimement lié.Les rôles, les convictions, les concepts étant posés, attaquons-nous à la mise en oeuvre, aux pratiques. Nous étudierons les pratiques de la MOA, celles de la MOE et les pratiques communes aux deux collèges. ^ top ^ Pratiques de la MOAExprimer les besoinsLe client ou MOA doit tenir une responsabilité inéluctable : exprimer les besoins. Trop souvent, les équipiers restent sur cette idée fausse que le développeur peut deviner ce qui correspond aux demandes de l'utilisateur. Il convient donc de s'en tenir à cette règle stricte : le client exprime les besoins. Le développeur est à la fois catalyseur, guide, force de proposition.Pratiquement, comment faire dans le cadre des cas d'utilisation ? Il existe plusieurs degrés : — identifier les situations d'utilisation, les acteurs (humains ou non), — décrire textuellement les interactions, ce qui implique un "effort" de visualisation, de projection dans le futur : faire comme si le système existait déjà. Notons quelques fils conducteurs qu'il est capital de garder à l'esprit. Ces deux activités techniques sont reprises plusieurs fois, il n'est pas question de découvrir d'abord et définitivement tous les acteurs, puis tous les cas d'utilisation, enfin toutes les descriptions textuelles. Au contraire, de nombreuses itérations sur ces activités, associées aux pratiques de travaux et relectures collectives, auront pour objectif de border, d'encercler toujours plus finement l'expression de besoins. Dans le même ordre d'idées, il ne faut pas confondre le moyen et la fin. Cette technique est un moyen. L'accent doit être mis sur l'expression. Peu importe finalement le niveau des cas d'utilisation exprimés au départ. Souvent, la MOA décrit l'essence du système, sa valeur ajoutée maximale, via des cas "crabe". Peu importe. Une description textuelle est déjà une victoire. Définir les acteurs consiste à fixer les limites du système, son périmètre fonctionnel (ce qui est décrit dans UML par le rectangle qui représente le système dans un diagramme de cas d'utilisation). Suivant le projet, la question de la limite du système étudié peut représenter un projet de par elle-même. La description s'attache à la signification des interactions, pas à leur forme qui reste du domaine du maquettage (story-board, maquette informatique...). Gérer et mettre à jour les caractéristiques des casUn cas d'utilisation ne se "conçoit" pas seul et indépendamment du système. Il possède quelques propriétés qui sont sous la responsabilité (exclusive ou non) du client.
^ top ^ Exprimer les besoins non fonctionnelsAttachés ou non à un cas d'utilisation (par exemple sous forme de "tagged value"), ces besoins non fonctionnels (disponibilité, précision... ou bien contraintes d'architecture) sont partie intégrante de l'expression de besoins. Si les cas d'utilisation ne sont plus d'un grand secours, il existe d'autres modes d'expression, dans ou hors UML.Choisir les scénarios à analyser et/ou maquetterLa MOA, en fonction des propriétés telles que fiabilité et priorité, détermine le périmètre de l'étude prise en charge par la MOE, semaine après semaine.^ top ^ Pratiques de la MOEMaintenir le modèle d'expression des besoinsL'expérience montre que, la plupart du temps, la MOA n'a ni "le temps", ni les talents pour maintenir le modèle d'expression de besoins par les cas d'utilisation. C'est un rôle qui en pratique revient au développeur (MOE). La notion même de "modèle" au sens UML n'est pas si triviale. Un modèle est une représentation du système physique selon un certain point de vue. Cette représentation possède un et un seul paquetage au plus haut niveau : le système lui-même selon le point de vue du modèle. Ce paquetage "système" contient alors les trois types d'items connus : éléments de modélisation (ici cas d'utilisation, acteur, relation), diagrammes et autres (sous-)paquetages.Point important : les relations entre cas (include, extend, spécialisation) ne devraient être injectées dans le modèle qu'après une évidente nécessité. Autrement dit, ce sont les interactions qui imposent une telle réorganisation et non pas une vision a priori du modèle. Veiller à obtenir des cas "mer" au moment opportunNous avons vu que la MOA a généralement tendance à démarrer avec des cas "crabe". Or, la théorie des cas d'utilisation repose sur des cas "mer". Persister au niveau "crabe" engendre un risque, celui d'ignorer des interactions, qui, si elles n'offrent pas de valeur ajoutée importante, n'en sont pas moins indispensables. Le cas typique est celui des interactions de "connexion". Ainsi, il est nécessaire, au bout de "quelque temps" (typiquement quelques semaines) de réorienter l'expression de besoins vers les cas plus définitifs : les cas "mer". Cela peut s'obtenir en injectant - uniquement à ce moment-là - des relations inter-cas pour réorganiser le modèle.Visuellement, UML permet de distinguer les cas, par exemple en jouant sur la couleur de fond ou bien sur la police de caractère. Ainsi, les cas "mer" peuvent apparaître en police 14 et les "crabe" en 10 par exemple. Visualiser permet de communiquer plus facilement. ^ top ^ MaquetterCréer une maquette permet à tous les intervenants de débattre sur des éléments plus concrets, c'est une aide appréciable qui offre plus de facilité de visualisation.AnalyserAnalyser consiste à "entrer dans le système", ne plus rester à l'extérieur des frontières et le considérer comme une boite noire. Ainsi, la clé est la collaboration entre objets d'analyse, ce que l'on retrouve dans différentes approches : processus unifié ou bien CRC Cards. La MOE produit alors des diagrammes de collaboration (communication dans UML v2), qui sont au départ des diagrammes d'objets : objets à la frontière du système mais dans le système (typiquement les interfaces utilisateur, ce sont les "boundary" du processus unifié), mais aussi les objets qui sont les "miroirs" des objets métier manipulés. A ce stade, tout dépend de l'avancement de l'architecture. Dans bien des cas, la forme, le squelette de la solution est d'ores et déjà fixé. Alors, pourquoi ne pas gagner du temps et appeler les choses par leur nom ?Cette analyse s'effectue scénario par scénario. C'est le pilotage du projet par les scénarios des cas d'utilisation. Au fur et à mesure, la partie structurelle du modèle évolue, par contribution des modélisations de la dynamique que nous venons d'aborder. Voir à ce sujet le support d'apprentissage de l'UML. Les livrables du projet sont, dans cet ordre d'idée, le modèle d'expression des besoins par les cas d'utilisation et le modèle d'analyse. Pratiques communes MOA/MOE ou Client/DéveloppeurL'une des valeurs ou convictions reprises ici est la communication, issue directement des méthodes agiles. Si les pratiques que nous venons de décrire sont sous la responsabilité claire de tel ou tel collège dans le projet, il est nécessaire de dialoguer, communiquer très régulièrement sur les travaux.^ top ^ Réunion de travail : expression de besoinsCe type de réunion, qui suppose la présence de tous les intervenants, permet de
Les engagementsIl est crucial de formaliser, expliciter, exprimer avec le moins d'ambiguïté, l'engagement entre MOA et MOE. Typiquement, l'engagement est constitué de scénarios, dans les différents cas, formant le périmètre de chaque version à développer.Pourquoi plusieurs engagements ? Simplement, l'engagement initial permet de fixer un plan projet initial (périmètre = {scénarios}, calendrier, coût, qualité). Or, ce plan projet est amené à évoluer, il est adaptatif pour reprendre la vision "agile" et non pas prédictif au sens définitif du terme. Il vivra donc plusieurs évolutions et c'est dans l'ordre naturel des choses. La variable "la plus variable" est le périmètre. Adapter ces pratiquesIl convient de bien distinguer les exemples de pratiques et le fond, l'essntiel qui réside dans plus de communication, de simplicité. Dans cet ordre d'idée, l'adaptation de ces pratiques à un contexte projet, organisationnel donné, devrait être mené dans le respect des convictions, des valeurs exprimées.^ top ^ La logistique, l'environnementLes convictions et pratiques décrites spécifient l'environnement du projet, sa logistique.Fluidifier la communicationIl est clair que la communication, en tant que valeur ou conviction, se traduit dans l'environnement du projet : salle de réunion pour les sessions de travail, murs dédiés à l'affichage du projet (diagrammes...). Si la pratique "client sur site" de l'Extreme Programming est en quelque sorte un idéal parfois peu réaliste dans l'organisation, il convient alors de s'en rapprocher. Une visio-conférence est préférable à une conférence téléphonique, une conférence téléphonique est préférable à un courrier, etc. Car il est bien question de fluidifier la communication. Dans cet ordre d'idée, un site Web de type "wiki wiki web" ou bien un outil "mindmanager" peuvent être efficaces.Outiller UMLUML se pratique essentiellement au tableau blanc ou bien au tableau-papier. Un logiciel "modeleur" peut être installé afin d'obtenir des diagrammes plus "présentables" en particulier au top-management. Il faudra alors veiller à plusieurs points importants :
^ top ^ EffetL'effet est à deux niveaux.Premièrement, le vécu des équipiers. Percevoir une avancée dans l'activité d'expression de besoins, une valeur ajoutée réelle de cette activité en tant que fondation du développement. Deuxièmement, le résultat est un ensemble de livrables qui définit les exigences. Le modèle d'expression de besoins, repris dans un document type "Dossier des exigences", le modèle d'analyse repris dans un document tel que "Dossier de Spécifications" (lorsque ce type de document est requis), la maquette sont autant de résultats de ces travaux. De façon complémentaire, une trace des changements, le wiki web ou bien les comptes-rendus de réunion peuvent être conservés pour rassurer les parties prenantes et/ou faciliter la gestion des changements dans le projet. De l'expression à l'élaboration des besoinsAinsi, il est plus question d'élaboration des besoins, des exigences, que de leur expression. En effet, s'en tenir à une activité hypothétique d'expression revient à nier l'interdépendance qui existe entre les exigences elles-mêmes et la faisabilité, les "possibles" : nous avons à gérer les variables projet (budget...) et également les réalités techniques (infrastructure existante, composants disponibles ou non...). Cette prise de conscience des dépendances croisées entre besoins et solutions, apparue clairement dans le processus unifié, trouve ici une évolution définie dans la gestion et le développement des exigences.De même que la réussite du projet est une affaire collective : client, manager, développeur, de même les fondations du produit - ses spécifications - sont-elles l'aboutissement d'un travail communautaire. Quand le développeur devient miroirDans cet exercice le client s'exprime. Il est important de ne pas sous-estimer cet aspect particulièrement et profondément humain de l'activité. Le développeur devient alors miroir à la fois des certitudes et des doutes. Chacun devrait faire preuve de simplicité, voire d'humilité dans cet échange. Ce sont des valeurs de l'Agile Modeling.Vos commentaires, opinionsLa page expression de besoins agile de la partie interactive du site vous permet de contribuer au sujet.Références- l'ouvrage "Modélisation objet avec UML" de Pierre-Alain Muller et Nathalie Gaertner (Edition Eyrolles)- l'ouvrage "UML en action" de Pascal Roques (Edition Eyrolles) - l'ouvrage "Unified Software Development Process" de Jacobson, Rumbaugh, Booch (Addison-Wesley) - le site Web de Alistair Cockburn - les pages wiki de ce site. ^ top ^ Commentaires bienvenus. Révisions 12/02/2005 Ajout d'un lien vers la page de discussion sur le wiki 20/11/2004 Ajout du paragraphe "Quand le développeur devient miroir" 06/11/2004 Création Retour page d'accueil ^ top ^ © 2004 - 2005 Contact |