Usages

Expression et analyse du besoin : MOA versus MOE ?

Publié le : Auteur: Hugues VAN EYLEN Un commentaire
usages

Ce troisième billet sur la modélisation du besoin va s’attacher à préciser les différences existantes entre l’activité d’expression du besoin destinée à la MOA et celle d’analyse du besoin prise en charge par la MOE ; du moins quand celle-ci ne passe pas directement à l’implémentation logicielle.

On l’a vu précédemment, bien souvent, la MOA bâtit une expression du besoin sous la forme d’un cahier des charges et la MOE établit une expression du besoin en utilisant un cadre de pensée plus précis tel que les cas d’utilisation et la modélisation objet. Toutefois, dans les deux cas, on s’intéresse à la description du besoin du système d’un point de vue externe.  Le cahier des charges n’étant pas assez précis, complet et cohérent, il est devenu une habitude que la MOE le complète d’une spécification du besoin plus formelle.

En dehors de l’avantage de permettre à la MOE de prendre connaissance du besoin, les inconvénients de cette approche sont les suivants :

  • On se retrouve avec plusieurs documents d’expression du besoin ! Lequel fait foi et reste à jour ?
  • On effectue parfois deux fois le travail d’expression du besoin ;
  • la MOE s’accapare la maîtrise du besoin qui pourtant devrait rester dans le giron de la MOA ;
  • Plus technique, il n’est pas rare que la spécification vue par la MOE noie le besoin avec des considérations de l’ordre de la solution technique.

En fait, concernant le besoin, UP prévoit pour la MOE une activité de transition vers la conception : l’analyse du besoin. Cette activité permet de prendre connaissance du besoin non pas en effectuant une nouvelle expression mais en analysant l’expression du besoin sous un angle de structuration logique du système suivant le paradigme retenu (objet, service, etc.).

L’avantage de cette activité est de ne pas être une redite plus précise du cahier des charges, de permettre une validation de l’expression fournie en entrée et de préparer la conception logicielle qui suit.

Le tableau suivant liste les principales différences entre expression et analyse :

Caractéristique

Expression du besoin

Analyse du besoin

Vue du système Vue externe : le système est une boîte noire Vue interne logique suivant le paradigme retenu :Objet : stéréotype de jacobson (entité, contrôle et frontière)SOA : service entité, service procédure, etc.Urbanisation : POS

Lisible par qui ?

Utilisateur final, MOA et MOE MOE principalement

Cadre de pensée

Cas d’utilisation, objet métier, règles de gestion, contraintes, maquette IHM Modèle objet, modèle de service, modèle logique de données, diagramme de robustesse, etc.

Technologique

Agnostique sauf dans les contraintes Agnostique

 

La spécification du besoin s’intéresse aux échanges des acteurs avec le système d’un point de vue externe. Les cas d’utilisation pour les échanges mais aussi le modèle objet pour la modélisation d’informations sont les cadres de pensée de cette activité. L’expression est à un carrefour et représente le contrat avec l’usage attendu du système. L’expression doit donc être lisible de toutes les parties prenantes au développement et à l’usage du système.

Sur le plan technologique, l’expression comme l’analyse doivent en être le plus agnostiques afin de ne pas se noyer dans des éléments de solution. Du point de vue de l’expression, la technologie est cantonnée aux contraintes ce qui la délimite clairement et évite la confusion, ennemie principale de cette activité.

L’analyse s’intéresse à bâtir une architecture logique modulaire du système et à projeter les éléments de l’expression sur cette architecture afin de préparer la conception qui,  ajoutera l’aspect technologique.  Cet éclairage du besoin sous un angle différent permet de lever les incohérences, d’identifier les manques et les imprécisions. Bref, elle possède une plus-value plus importante qu’une simple réécriture même plus formelle et plus approfondie du cahier des charges.

En résumé, la MOA a pour charge d’effectuer l’expression du besoin à l’aide de cadre de pensée et de formalisme adéquat (cas d’utilisation, etc.) et la MOE a pour charge d’effectuer l’analyse afin de s’imprégner du besoin, de structurer logiquement le système cible et ce faisant de valider l’expression. Une synergie vertueuse s’installe alors permettant une meilleure maîtrise du développement.

  • Missud Daniel

    Bonjour Hugues,
    A la lecture de ton article je reste un peu dubitatif sur la frontière que tu poses. Mon souci reste au niveau de la définition de ce qu’est l’expression du besoin d’un système informatique. Tu limites le sujet à l’étude des échanges des acteurs avec le système. Mon souci c’est que si tu en es à cette étape c’est que tu as déjà élaboré une solution en définissant le rôle du système informatique dans la mise en œuvre opérationnelle d’un processus métier.
    Une des causes d’insatisfaction de l’utilisation d’un système informatique (et donc que de nombreuse demande d’évolution sont faites) est justement que l’ensemble des parties prenantes n’a pas réussi à s’entendre sur cette vision de la mise en œuvre opérationnelle de leur processus métiers avec le nouveau système informatique. Le système ne répondant pas à leurs attentes
    Pour favoriser les échanges utilisateurs, MOA et MOE, mon positionnement actuel est d’encourager la MOA à étudier les processus métiers des utilisateurs et de définir qu’elles sont les attentes en assistance et aide de l’informatique dans la mise en œuvre opérationnel de ces processus métiers et d’élaborer conjointement avec la MOE la vision de ce que doit être le système à l’aide des cas d’utilisation et de la modélisation objet. Lors de cette activité un soin particulier doit être porté sur l’étude de l’utilisation du système informatique dans la mise en œuvre des processus métiers.
    Maintenant que nous avons enrichi la notion d’expression du besoin je ne suis pas sure que la MOE doit être que consommatrice des cas d’utilisation d’un système. Il est bon qu’elle comprenne les tenants et les aboutissants de chaque fonctionnalité. Le fait de responsabilisé la MOE sur l’écriture des cas d’utilisation va dans sens. Je ne suis pas sure que de la limité à l’analyse permette de remplir cette objectif.
    Pour moi la rédaction des cas d’utilisations et leur analyse sont plus sous la responsabilité de la MOE, avec d’un coté une modélisation qui permet d’échanger avec les utilisateurs et la MOA et de l’autre une activité (l’analyse) qui permet de bien maîtriser la compréhension du système au sein de la MOE.
    Enfin sujet à débattre 😉

    Cordialement

    Daniel Missud