Dans la section Informatique
Related articles
Top Articles
- Tutorial : Installer et configurer Homeplayer (freeplayer) (136111)
- Tutorial : Installer Windows Virtual PC et Windows XP Mode pour Windows 7 (Seven) (58612)
- Tutorial : Installer un dual boot avec Windows XP ou Vista et Windows 7 (Seven) (39132)
- Tutorial : Introduction à Jquery UI (34028)
- Tutorial : Migration de Windows Vista vers Windows 7 (Seven) (28258)
| Le pilotage par les cas d'utilisation |
|
|
| Computer Science - Méthodes | ||||||||||||
| Written by Vincent MARTIN | ||||||||||||
Page 1 of 4 There are no translations available. Aujourd’hui encore, dans mon activité de consultant, j’interviens trop souvent sur des projets où les cas d'utilisation sont peu ou mal utilisés. Voilà pourtant un concept simple qui, bien employé, peut apporter beaucoup. Voici une petite proposition de méthodologie pour faire le point sur votre maturité dans l’emploi des cas d'utilisation. Bref rappel
Les cas d'utilisation sont les grands services rendus par un système, ils sont la réponse à la question : « dans quel cas, dans quel but, dans quelle intention, vais-je utiliser le système ? » En UML, les cas d'utilisation se représentent dans un diagramme de cas d'utilisation.
Ces cas d’utilisation sont le résultat d’une première recherche effectuée sur les services du système, ce sont les cas d'utilisation principaux. Une deuxième analyse, plus poussée, permettra d’identifier ceux que j’appelle ici les cas d'utilisation dérivés, reliés aux principaux par des relations d’inclusion ou d’extension. Ils ne seront pas abordés dans le cadre de cet article.
Les cas d'utilisation principaux, par définition, laissent le système dans un état cohérent. A l’issue d’un cas d'utilisation, le système peut être sollicité pour un autre cas d'utilisation.
Dans le cas d’un développement itératif, type Processus Unifié, on attribuera à chaque itération un nombre entier de cas d'utilisation ; chaque itération pourra ainsi livrer une version utilisable du système, car contenant les services correspondants aux cas d'utilisation attribués. La version du système sera incomplète – on est encore en cours de projet – mais utilisable.
Ainsi, dans le cas toujours possible d’un retard, on peut garantir à la date de fin du projet l’existence d’une version opérationnelle du système. Elle ne sera peut-être complète qu’à 80 ou 90%, mais chaque service sera, lui, développé à 100%. Cela ne peut pas être garanti dans le cas d’un développement conduit fonctionnalité par fonctionnalité.
L’importance du feedback
En pilotant le projet par les cas d'utilisation, il est donc possible de livrer, à chaque itération, une version utilisable du système. Qui dit utilisable dit aussi testable. Le client reçoit ainsi, régulièrement, une version du système qu’il peut tester et sur laquelle il peut exprimer un retour.
Ce retour, ou feedback, pourra être pris en compte lors d’une itération ultérieure ; le système, lors de sa livraison finale, aura été modifié ou rectifié (correction des erreurs détectées) en fonction des feedbacks. Le système livré correspondra davantage au besoin du client, le taux de satisfaction de celui-ci sera plus élevé.
Un certain nombre d’évolutions et de corrections ayant été traitées pendant la phase de Construction – je reprends la terminologie du Processus Unifié – la phase de maintenance, qu’elle soit évolutive ou corrective, sera allégée et coûtera moins cher.
J’entends d’ici les objections : non, le coût ne sera pas moins élevé : les corrections seront juste déplacées, transférées de la phase de maintenance à celle de développement. La maintenance coûtera peut-être moins cher, mais le prix du développement, lui, sera majoré d’autant.
Ces objections sont recevables : les corrections sont effectivement déplacées de la maintenance vers le développement, mais leur coût n’est pas le même. En effet, plus une erreur est détectée tôt, moins elle est coûteuse à corriger (figure).
![]() Coût relatif de rectification d’une incompréhension des besoins (Grady, Robert B. 1999. « Modèles décisionnels d’économie des versions – Analyse du management des projets logiciels ». Travaux de la Conférence « Applications of Software Project Management »).
Powered by !JoomlaComment 4.0alpha3
!joomlacomment 4.0 Copyright (C) 2009 Compojoom.com . All rights reserved." |







