Les techniques d’analyse et de modélisation

Les techniques d'analyse et de conception

(temps de lecture moyen : 2 m 45 s)

Méthodologie UML
Méthode MERISE
Méthodologie RUP

Vous trouverez ici un aperçu de certaines des techniques d’analyse utilisables en Business Analysis pour décrire de manière pertinente, complète et non ambiguë la future solution.

Je vous conseille de faire régulièrement de la veille informationnelle, car ce domaine est en constant renouvellement.

En réalité, toutes les nouvelles techniques d’analyse émergentes ne sont pas nouvelles. Ce sont souvent d’anciennes méthodes remises au goût du jour pour des besoins précis (projet, secteur…) et  qui font tâche d’huile par le biais d’internet. Ce media accélère de facto leur application à de nombreux secteurs d’activités dans le monde entier, le point de départ étant fréquemment les pays anglo-saxons ou le Japon.

Prenez l’exemple du Kanban. Initialement pensée pour optimiser la production en flux tendu des usines Toyota dans les années 1960, la logique a été reprise et appliquée à la refonte des processus métier en entreprise, y compris du secteur tertiaire.

D’autre part, de nombreuses techniques ont leurs variantes (à l’exemple des méthodologies Agile comptant une dizaine de représentantes, dont les célèbres SCRUM et XP).

Aussi, un conseil : si vous arrivez dans une organisation qui applique une méthodologie particulière, vérifiez-en le degré de personnalisation. Cela vous évitera de tomber dans les écueils de l’ambigüité et vous permettra de parler le même langage que vos interlocuteurs.

Voici trois exemples de techniques utilisables en Business Analysis.

UML

Ou Unified Modeling Language. C’est clairement « le » standard de référence, la technique la plus connue et enseignée à ce jour. Il est vrai qu’elle permet de visualiser et de conceptualiser à peu près toutes les facettes d’une demande de changement, et qu’elle est compréhensible autant par les interlocuteurs métier que technique.

En business analysis, cette boîte à outils permet de modéliser les cas d’utilisation, les fonctionnalités, les processus, de représenter les interactions entre composants, acteurs, de préparer la stratégie de déploiement de la solution cible…

Bien entendu, il faut en apprendre la syntaxe, mais même sans l’appliquer stricto sensu, ses diagrammes et vues permettent au Business Analyst d’analyser et de rédiger la plupart de ses livrables.

MERISE

Merise est une méthode séquentielle, par opposition aux méthodes itératives et incrémentales (RUP, SCRUM…)

Je l’ai apprise en Master 2 de la bouche même d’un de ses pères fondateurs, ce qui en fait, en quelque sorte, ma « madeleine de Proust »…

Abstraction faite de toute subjectivité mal placée, et bien que passée de mode (car la gestion de projet a évolué depuis les années 1970), cette technique est très intéressante pour analyser, concevoir et réaliser des systèmes d’information.

Il faut bien entendu en apprendre la syntaxe, tout comme l’UML, mais sa maîtrise en fait un outil puissant et rigoureux si elle est partagée entre développeurs et Business Analysts.

Cependant, elle est de plus en plus rarement enseignée en école d’ingénieur ou en master informatique, au profit de l’UML, et sa « lourdeur » ne se prête pas aux projets agiles.

RUP

Ou Rational Unified Process

Je suis une grande fan de cette méthode, qui est générique, itérative et incrémentale (par opposition, vous l’aurez compris, aux méthodes séquentielles comme Merise).

L’intérêt de cette méthode, pour le Business Analyst, est qu’elle permet de penser « objet » tout en analysant les besoins du point de vue utilisateur et en restant centré sur l’architecture de la future solution.

Les statistiques démontrent que les échecs des projets informatiques sont majoritairement liés à une mauvaise compréhension et restitution des besoins métiers, ainsi qu’à une architecture inappropriée et non évolutive.

La méthodologie RUP améliore donc considérablement les chances de succès, puisqu’elle encadre les activités (voir la rubrique Contexte du projet) en se focalisant sur ces deux axes.

Bien qu’étant incrémentale et itérative, comme le requièrent les projets agiles, il ne s’agit pas faire de l’analyse métier « agile ». En effet, la méthode RUP conserve les caractéristiques d’un projet en V (phase de Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment). Le rôle du Business Analyst y est donc clairement identifié et central, contrairement aux projets en contexte agile.

N’hésitez pas à poster vos commentaires pour enrichir cette rubrique de vos expériences personnelles, afin que je la complète avec d’autres techniques fréquemment utilisées !

Poster un Commentaire

avatar
  S’abonner  
Notifier de