L'informatique orientée métier (bis)
Suite de l'article précédent.L’utilisateur peut avoir envie de fonctions supplémentaires pour, par exemple, stocker ces CD audio dans une bibliothèque.
1/ Sur le plan fonctionnel
Nous avions donc la fonction :
F1 Copier le contenu du CD audio vers le lecteur mp3
Notre utilisateur imagine les fonctions supplémentaires suivantes :
F2 Copier le contenu du CD audio vers la bibliothèque
F3 Copier un CD audio de la bibliothèque vers le lecteur mp3
F4 Supprimer un CD audio de la bibliothèque
La grande question à se poser est : est-ce que ces fonctions sont vraiment utiles, c'est-à-dire contribuent-elles ou non à la création de valeur ajoutée pour le client de l’entreprise (je fais du zig-zag entre l’exemple amusant du mp3 et le cas réel en entreprise !).
L’utilisateur vous dira toujours que les fonctions qu’il imagine lui seront extrêmement utiles : c’est donc à vous à vous faire votre propre opinion.
Essayons d’analyser F2 F3 F4 en ce sens.
F4 est un peu « limite » : à priori, il n’y a aucune raison pour que l’utilisateur « non informaticien » ait l’initiative de supprimer un CD audio de la bibliothèque. Qu’est ce que ca lui apporterait ?
Cependant, il n’empêche que, dans le cadre de F2, quand la bibliothèque est pleine, cette suppression peut être proposée à l’utilisateur. Mais proposer la fonction « en direct » à l’utilisateur, ne leur en déplaise, c’est un raisonnement d’informaticien. J
F4 est retiré de la liste !
F2/F3 : quel est l’avantage de gérer une bibliothèque ? F1 dure 20 minutes. On peut donc gagner ce temps sur F1 en ayant sous la main un CD audio déjà prêt. On est d’accord. Seulement avant de gagner du temps on commence par … en perdre, précisément en cherchant dans la bibliothèque. C’est pourquoi on peut raisonnablement se demander si cette fonction vaut le coup sur le plan opérationnel : elle se justifie si la recherche en bibliothèque n’excède pas en moyenne 20 minutes !
Alors quelle décision ? OK on garde F2/F3
Nous venons de faire l’analyse fonctionnelle et de définir la vue fonctionnelle de l’urbanisme !
2/ Sur le plan applicatif, notre application ressemblerait maintenant à ceci :
Chaque bouton donne accès à un échange avec l’utilisateur spécifique, qui le guide dans la réalisation de la tâche.
Les experts d’UML reconnaîtront … les Use Cases.
Chaque fonction demandée sur la vue fonctionnelle correspond à un Use Case de l’application à développer.
Nous enrichissons donc la règle :
1 tâche = 1 fonction
1 fonction = 1 use case UML
1 fonction = 1 use case UML
A l’intérieur de chaque fonction/Use Case, on doit décrire les spécifications détaillées. Pour ce faire, on peut mettre en pratique les méthodes agiles, type XP, qui s’applique plutôt mieux sur de petits périmètres.
3/ Sur le plan métier
Chacune de ces fonctions sont liées à une tâche.
Ces tâches sont symbolisées par une même activité métier : « Sélectionner et écouter un CD audio en mp3 ».
On dit que l’intitulé de cette activité « fait abstraction du mode opératoire » : c'est-à-dire que l’on passe sous silence la façon pratique dont cette activité est faite (avec/sans bibliothèque, …)
Cette activité métier est l’une des activités d’un processus métier plus général.
Dans le message précédent, l’activité contenait une tâche. Maintenant, elle en contient trois. Ici, l’activité métier a changée mais pas le processus métier. Mais on rencontre aussi le cas où le processus métier change !
A bien regarder, l’activité « Sélectionner et écouter un CD audio en mp3 » est encore incomplète car nous avons oublié de mentionner une tâche, pourtant essentielle : « écouter le CD audio vers le lecteur mp3 » (la tâche super astreignante !).
Cette tâche n’est pas associée à une fonction !
On rencontre beaucoup ce cas en analyse métier : une bonne partie des tâches se font hors du Système d’Information. C’est un point très important.
C’est une des raisons pour laquelle, IMHO, il est tout à fait impossible de passer du processus métier au processus technique (voir les articles dans mon historique de Mars/Avril)
Nous pouvons encore compléter notre règle :
3/ Sur le plan métier
Chacune de ces fonctions sont liées à une tâche.
Ces tâches sont symbolisées par une même activité métier : « Sélectionner et écouter un CD audio en mp3 ».
On dit que l’intitulé de cette activité « fait abstraction du mode opératoire » : c'est-à-dire que l’on passe sous silence la façon pratique dont cette activité est faite (avec/sans bibliothèque, …)
Cette activité métier est l’une des activités d’un processus métier plus général.
Dans le message précédent, l’activité contenait une tâche. Maintenant, elle en contient trois. Ici, l’activité métier a changée mais pas le processus métier. Mais on rencontre aussi le cas où le processus métier change !
A bien regarder, l’activité « Sélectionner et écouter un CD audio en mp3 » est encore incomplète car nous avons oublié de mentionner une tâche, pourtant essentielle : « écouter le CD audio vers le lecteur mp3 » (la tâche super astreignante !).
Cette tâche n’est pas associée à une fonction !
On rencontre beaucoup ce cas en analyse métier : une bonne partie des tâches se font hors du Système d’Information. C’est un point très important.
C’est une des raisons pour laquelle, IMHO, il est tout à fait impossible de passer du processus métier au processus technique (voir les articles dans mon historique de Mars/Avril)
Nous pouvons encore compléter notre règle :
1 tâche = 0 à 1 fonction
1 fonction = 1 use case UML
1 fonction = 1 use case UML
4/ Conclusion
L’air de rien, ce petit exemple permet de donner un petit aperçu de la démarche d’urbanisation.
Contrairement aux idées reçues, la théorie reste très facile d’accès.
C’est la mise en pratique qui donne du fil à retordre … il faut la pratiquer beaucoup pour la maîtriser pleinement.
Quand on met tout ceci en pratique à haute dose, on arrive à rendre lisible le lien Processus => Activité => Tâche => Fonction => Application informatique. On réalise alors ce qu’on appelle pompeusement « l’alignement métier/informatique »
Christophe Thiry
posted by Christophe Thiry @ 6/12/2006
8 Comments:
En réaction au commentaire de Oaz sur la première partie de cet article, je suis complètement d'accord avec lui sur le fait que la possibilité de revenir sur les besoins de façon itérative dans un projet (comme dans les méthodes Agiles par exemple) apporte une plusvalue métier considérable.
En fait, l'idéal serait d'arriver à combiner les concepts d'urbanisation avec ceux des méthodes Agiles, en récupérant ce qu'il y a de meilleur dans chacun d'entre eux. Du peu que je connaisse les deux, je ne crois pas qu'il y ait de pratiques incompatibles ou opposées. Au contraire les deux cherchent à atteindre le même but (un logiciel utile, évolutif, et qui répond vraiment aux besoins), mais sous deux angles légèrement différents, et je pense qu'ils sont complémentaires.
Vos points de vue d'experts sur cette idée m'intéressent beaucoup. Je lance la polémique ;)
PS : Allez hop, on se fait le Urbano-Agile Manifesto :) ?
OK pour le "Urbano-Agile Manifesto" :)
Alors je commence.
Je ne suis pas très d'accord sur ce coté itératif et voic pourquoi. J'ai connu un projet qui a itéré pendant 1 an comme ca : 2 personnes passant leur temps à customiser un progiciel de GED pour l'ajuster finement à chaque micro besoin des utilisteurs.
it 1 : pas satisfaisante
it 2 : encore des trucs qui ne vont pas, et ça, on pourrait pas le mettre à gauche
it 3 : toujous pas OK, et puis on ajoute une fonction supplémentaire
it 4 ... mais quand est-ce que ca va s'arrêter b...el ?
Personne n'était jamais satisfait.
On paie les gens 1 an à faire et défaire sans visibilité sur la fin de tout ce manège.
C'est un peu comme si vous construisez une maison sans faire de plan. Quand vous achetez une maison sur plan vous n'avez pas le choix : il vous faut apprendre à juger sur plan! parce que, une fois les travaux finis, comment pouvez-vous couper une chambre ici, en ajouter deux là, etc. Tout au plus vous pouvez surveiller les travaux et faire varier des éléments de plus petite importance (sans que ce soit péjoratif), les matériaux, la place des lavabo, à condition de ne pas trop bouleverser la tuyauterie...
J'ai donc le fort sentiment que les méthodes agiles / itératives commence quand l'urbanisation finit : c'est à dire on se trouve déjà à un certain niveau de détail, dans le cadre d'un "petit" projet, qui couvre plusieurs fonctions, en prenant garde que les adaptations fonctionnelles qui apparaîtront ne remettre pas en question les plans d'ensemble.
Quelle brillante démonstration de ce Mr Thiry sur un sujet aussi ardu !!
Je crois que je vais très rapidement prendre contact avec la société Dreamsoft pour urbaniser le SI de ma société (du métier jusqu'au plan technique comme le raconte ce Mr Thiry qui a lu avec attention les ouvrages qui existent sur le sujet) et engraisser une pauvre petite boite de tech lourdingue qui semble chercher désespérement à se sortir de leur petite technique !!
Une des raisons (sinon la principale) pour lesquelles les méthodes agiles fonctionnent c'est que justement l'analogie construire un logiciel/construire une maison ne tient pas la route. Ceci pour 2 raisons :
- en termes de besoin utilisateur/description fonctionnelle, la plupart des logiciels sont bien plus complexes que l'immense majorité des maisons. Cette complexité est généralement impossible à appréhender d'un seul tenant (alors que, n'habitant pas au chateau de Versailles, j'ai vite fait le tour du plan de ma maison...). La seule solution est de l'appréhender morceau par morceau, donc d'itérer.
- en termes de techniques de construction, un logiciel est infiniment plus souple. Quand un mur de la maison est bati, je peux difficillement le déplacer. Pour le logiciel, ce problème n'existe pas, je peux défaire certains morceaux et en faire d'autres à moindre coût.
Si on reprend l'exemple du progiciel de GED, rien ne garantit qu'une réflexion sur le métier préalable sans aucune prise en compte du feedback utilisateur après mise en oeuvre d'une 1ère version aurait donné de meilleurs résultats.
Si les 4 itérations n'ont au final pas donné un résultat satisfaisant, c'est peut être tout simplement parce qu'il n'y a pas du tout eu d'analyse des besoins applicatifs par rapport au métier et que les gens se sont contenter d'itérer façon cow-boy ("je vois quelque chose qui ne va pas dans l'application, je vise, je tire et le problème est réglé").
Le fait de parler de "méthodes agiles / itératives" est en soi très intéressant. L'itérativité n'est qu'un aspect de l'agilité mais il semble que, en fonction de l'endroit duquel on regarde, cet aspect soit grossi comme si on le regardait à travers une loupe.
Un point important de l'aspect itératif est qu'il peut être vu à divers niveaux : au niveau du développeur individuel qui itère son code avec ses jeux de tests (échelle de temps : la minute), au niveau de l'équipe de développement qui intègre le code dans des versions de travail (échelle de temps : la journée), au niveau de l'interaction avec un client ou un représentant de celui-ci pour décider des fonctionnalités à un implémenter dans une itération (échelle de temps : quelques semaines), au niveau d'une version finalisée d'un produit qui va être déployée à grande échelle (échelle de temps : quelques mois).
Le tout est de savoir à quel moment il est opportun de remettre en cause une modélisation du métier du client. Comme d'habitude, il est difficile voire inutile de décider une fois pour toute de ce moment : un des aspects importants de l'agilité, c'est de savoir s'adapter. En ce qui me concerne je pense qu'un bon point de départ se situe entre l'itération et la version tout en sachant qu'il faut être capable à tout instant de se remettre en cause en prenant en compte un feedback sur le métier du client plus souvent quand cela est possible et moins souvent si cela mène à des impasses.
Mr l'anonyme, vous connaissez peut être la maxime "la critique est aisée mais l’art est difficile" ?
Quand on critique quelque chose, il faut au moins avoir le courage de le faire au grand jour pour que l'ensemble des lecteurs de ce blog puissent voir que vous en savez bien plus sur le sujet et que, bien évidemment, vous savez beaucoup mieux l'expliquer.
Juste un mot pour le brillant anonyme : Jean Christophe, arrête ton cirque. Merci.
PS pour OAZ : Laisse tomber, c'est qqn qui a quitté la société, pour le dire poliment.
Juste un mot sur l'exemple du GED, sans vouloir en rajouter une couche. Les méthodes Agiles n'ont pas été conçues pour les clients qui ne savent pas ce qu'ils veulent, et aucune autre méthode d'ailleurs. Le degré de liberté introduit par les itérations est intéressant pour apporter des ADAPTATIONS aux besoins, pas pour les remettre en question sans arrêt.
Je pense que dans ce cas, le problème venait davantage du fait que les clients ne savaient pas ce qu'ils voulaient au niveau METIER : la meilleure méthode de développement du monde ne pourra jamais lutter contre ça. Si c'était une méthode classique, au bout de 4 mois, ils auraient mis le projet à la poubelle !
C'est pour ça qu'il est toujours important avant de démarrer un projet de se poser les bonnes questions : quelles étapes va-t-on informatiser dans notre processus métier ? Quels délais se donne-t-on pour une livraison de release ? Etc.
Reprendre l'outil pour l'aligner mieux sur le métier, ça c'est Agile. Reprendre le processus métier à chaque livraison, c'est pas Agile du tout, c'est stupide. C'est pour ça qu'il est indispensable d'avoir une vue globale du logiciel à créer avant de lancer le projet, et de définir une architecture globale provisoire et surtout flexible.
Peut-être aussi qu'il est intéressant dans cette phase de déterminer quelles activités de notre processus métier ne sont pas stables et de prévoir les adaptations nécessaires dans l'architecture et le processus (se donner une limite pour les changements majeurs par exemple).
Mon blog été attaqué par un vendeur de viagra !!!
Argghh
Heureusement qu'il y a la fonction "suppression de message" !
@+
Christophe
Enregistrer un commentaire
Links to this post:
Créer un lien
<< Home