Usages

Modélisation des besoins et MOA

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

Le premier billet sur la modélisation a voulu démythifier cette activité mal perçue dans le monde informatique. Ce deuxième billet se focalise sur l’activité essentielle du développement logicielle qu’est l’expression du besoin et met en perspective comment la mauvaise compréhension de l’acte de modélisation lui est fortement préjudiciable.

On sépare communément la maîtrise d’ouvrage (MOA) responsable de l’expression du besoin d’un système et la maîtrise d’œuvre (MOE) responsable de la réalisation de ce système. Bien que les rôles semblent bien définis, il n’en va pas vraiment de même dans la réalité. Un lieu commun est de trouver un cahier des charges produit par la MOA suivi d’une spécification du besoin réalisée par la MOE ; chaque document traitant à sa manière du besoin.

Pourtant si on respectait la délimitation des rôles, la MOE n’aurait pas à produire un document d’expression du besoin !  Quelles sont les raisons avancées pour justifier cet état de fait :

  • La spécification du besoin rédigée par la MOE est plus détaillée et plus formalisée ;
  • En rédigeant cette spécification, la MOE s’approprie le besoin ;
  • Le  cahier des charges propose une vue d’ensemble du besoin mais manque de précision ;
  • Et  sous le couvert, la MOE  indique qu’avec seulement le cahier des charges, elle serait bien en peine  d’avoir une vision du besoin suffisamment claire et précise pour bâtir une solution.
  • Certaines MOA avouent aussi que la formalisation complète du besoin à l’aide des langages de modélisation (UML, E/A, BPMN, etc.) n’est pas de leur ressort.

Le problème ici est psychologique. La MOA perçoit la formalisation à l’aide de cadres de pensée et de formalismes clairement définis et standards comme étant trop technique. C’est dommage car l’expression du besoin est, nous l’avons dit, essentielle et se doit d’être abordée avec les meilleures armes possibles et cela pour deux raisons :

  • Réaliser une bonne expression du besoin cohérente, complète et sans ambiguïté est l’activité la plus difficile du développement logiciel. Exprimer le besoin,  c’est le modéliser et le faire sans l’aide de techniques et de bonnes pratiques est une gageure.
  • L’expression du besoin est à la base du développement logiciel. Si celle-ci est bancale  alors le projet sera pénible à vivre et le résultat sera lui aussi bancal. En 2002, le Standish Group a publié une statistique très intéressante  issue de l’étude de plusieurs milliers de projets aux Etats-Unis : 45% des fonctions développées sont inutiles !!

Quels sont les cadres de pensées qui peuvent aider à une bonne expression du besoin ?

Dans le contexte des systèmes d’information, il suffit de s’en remettre aux fondamentaux : le système informatique à réaliser doit permettre des échanges d’informations avec ses utilisateurs. On doit donc s’intéresser

  • Aux  informations échangées, leur structuration et leur sémantique;
  • Aux échanges qui traduisent une dynamique entre le système et ses utilisateurs lors des tâches qu’ils réalisent.

Ces deux domaines doivent chacun être modélisés à l’aide d’un cadre de pensée et un formalisme adapté. Pour les informations, on peut prendre le cadre de pensée objet sans sa dimension comportementale et pour les échanges, on peut prendre le cadre de pensée des processus pour une vision globale multi-utilisateurs et le cadre de pensée des cas d’utilisation pour se centrer sur une application et ses utilisateurs.

Mettre en œuvre de telles pratiques et de telles techniques nécessite toutefois une formation car la simple rédaction d’une expression du besoin en titrant certains chapitres processus ou cas d’utilisation n’en garantit pas la bonne maîtrise et la qualité. UML n’est rien sans méthodologie pour le mettre en pratique et ne l’oublions pas, exprimer le besoin est une activité difficile qui prend du temps à bien maîtriser.

  • ego

    Ben toujours d’accord avec tout ça 🙂