La MOA pragmatique du SI (Business Analysis, Analyse d'Entreprise, Maitrise d'Ouvrage)

Aller au contenu | Aller au menu | Aller à la recherche

Tag - UML

Fil des billets - Fil des commentaires

dimanche, septembre 4 2011

Quelles certifications pour la MOA ?

Par Olivier Durand le dimanche, septembre 4 2011, 15:59 - Divers

Les certifications pour la MOA ne sont pas très nombreuses. Et il y en a encore moins si on parle des certifications francophones. Indépendamment du débat "Êtes vous pour ou contre les certifications ?", voici quelques idées de certifications utiles pour une MOA.

Les certifications en Business Analysis

Le International Institute of Business Analysis (IIBA) propose deux certifications portant clairement sur le métier de maitrise d'ouvrage :

  • La certification CBAP® (Certified Business Analyst Professional®) pour les “Business Analyst” expérimentés.
  • La certification CCBA™ (Certification of Competency in Business Analyst™) pour les profils intermédiaires.

(plus d'information ici : Certifications IIBA - CBAP et CCBA)

Ces certifications sont sérieuses, elles demandent à la fois des connaissances sur le Business Analysis Body of Knowledge (BABOK) et également une quantité importante d'expérience sur des activités de la Business Analysis. Je ne pense pas que la certification CBAP soit très connue en France, mais c'est certainement la certification qui me semble la plus intéressante et la plus valable pour une MOA.

Les certifications associées à des méthodologies

En tant que MOA on peut être amené à travailler en suivant différentes méthodologies. Il peut donc être intéressant d'obtenir une certification sur une ou plusieurs méthodologies en vogue. Par exemple, si vous travaillez en tant que Product Owner sur un projet en mode Scrum, pourquoi ne pas passer une certification sur ce thème proposée par la Scrum Alliance ?

On est sur un type de certification plus "light" que celles proposées par l'IIBA, mais cela permet de prendre un peu de recul sur sa compréhension de Scrum, et cela donne accès à une communauté qui saura vous aider sur certains aspects de Scrum si vous en avez besoin.

Les certifications plus ciblées sur des outils, des langages, des progiciels

Ensuite, en fonction d'éléments plus spécifiques à votre profil et domaine d'expertise, vous pouvez opter pour des certifications sur un langage de modélisation ou un progiciel.

Là on est sur des certifications d'expert. On s'éloigne un peu de la MOA, mais il est vrai qu'une MOA est souvent également un expert sur un domaine en particulier. Il peut donc être intéressant de valider cette expertise via une certification.

Il existe donc un choix intéressant de certifications pour la MOA, même si les certifications purement MOA sont encore limitées en nombre. Ensuite, chacun doit faire en fonction de son profil, de ses souhaits d'évolution et du temps qu'il souhaite et peut y passer. Finalement reste l'éternel débat, comme pour toutes les professions du système d'information, la certification est-elle valorisée dans l'entreprise ?

2 commentaires

mercredi, juillet 21 2010

Dans quels cas utiliser les cas d'utilisation ?

Par Olivier Durand le mercredi, juillet 21 2010, 21:59 - Spécifier

"Les cas d'utilisation, c'est bien, mais leur description détaillée est un peu lourde. Finalement, nous ce qui nous intéresse c'est la spécification des écrans.", voilà ce qu'un développeur m'a récemment dit concernant des spécifications fonctionnelles que j'avais rédigées. L'approche par cas d'utilisations (use case) pour expliciter les exigences fonctionnelles d'un système est un grand classique de la MOA. Mais alors si les développeurs les jugent indigestes, à qui et à quoi servent-ils ? C'est en lisant ce billet Use cases: a personal history (and a bit of a love affair) de Laura Brandenburg, que je me suis rendu compte que je n'étais pas le seul à me poser ces questions.

Rappels sur les cas d'utilisation

Un diagramme de cas d'utilisation en UML permet de figurer le comportement d'un système face aux stimulations d'acteurs externes, le tout avec un formalisme extrêmement simple.Voilà un exemple décrivant le fonctionnement d'un restaurant :

Diagramme de cas d'utilisation

Un cas d'utilisation est représenté par une "patate". Chaque cas d'utilisation peut ensuite être décrit de manière détaillée avec par exemple le formalisme suivant :

Description détaillée d'un cas d'utilisation

Les cas d'utilisation pour discuter avec le métier

L'avantage d'un diagramme de cas d'utilisation est qu'il est très simple à comprendre. Hormis les associations de type "extends" ou "includes", le formalisme se comprend de lui même. Donc pour appréhender un système existant ou pour expliciter le périmètre d'un projet, ce genre de diagramme me parait indispensable. Et même si on travaille avec des "user stories" dans le cadre d'une méthode agile, réaliser un diagramme de cas d'utilisation permet d'avoir une vision d'ensemble, nécessaire pour les discussions au niveau d'un processus.

Les cas d'utilisation comme outil d'analyse

A moins d'être sur une évolution très simple ou d'être un expert du sujet, il me parait impossible de passer directement du besoin exprimé par l'utilisateur à une maquette détaillée de l'interface prête à être réalisée par l'équipe de développement. Alors comment mener l'analyse qui permettra de rédiger une spécification fonctionnelle détaillée ? Et bien par exemple en utilisant le modèle présenté précédemment pour expliciter les cas d'utilisations car il permet de :

  • Formaliser l'exécution normale du cas d'utilisation ;
  • Découvrir les cas alternatifs, qui sont souvent oubliés par les différentes parties-prenantes ;
  • Découvrir les règles métiers, même celles qui ne se traduiront pas par une règle dans l'interface graphique.

Même si finalement les développeurs auront tendance à se focaliser sur la description des IHM, les cas d'utilisation facilitent la conception de ces IHM et permettent d'avoir rapidement une vision globale du système ou processus étudié. Alors oui, ils peuvent paraitre trop simplistes sous forme de diagramme et trop complexes lorsqu'ils sont explicités de manière détaillée, mais il me semble que c'est un outil indispensable à toute analyse fine du métier.

jeudi, mars 11 2010

La MOA doit elle comprendre SOA ?

Par Olivier Durand le jeudi, mars 11 2010, 20:38 - Etudier

L'architecture orientée services (SOA en anglais) est un ensemble de concepts aujourd'hui matures. Cette démarche est souvent poussée par les acteurs "techniques" du SI. Pourtant un des points clés de la mise en œuvre devrait être selon moi à la main de la MOA : la décomposition en services.

Les services définis doivent être réutilisables, c'est tout l'intérêt de l'architecture SOA. Mais ce ne sont pas de simples composants réutilisables. Un service doit être autonome, remplir une fonction dans sa globalité et être utilisable (ou mieux, utilisé) par plusieurs consommateurs. Différents niveaux de service peuvent être définis : données (services "simples" permettant par exemple de récupérer des clients, d'en créer, d'en rechercher...), métiers (un service complexe qui remplira des fonctions métiers comme calculer le chiffre d'affaire par comptes clients), applicatifs (par exemple un service qui permettra notamment de récupérer tous les chiffres d'affaires agrégés par comptes clients qu'un collaborateur gère afin de l'afficher dans la CRM). On parle de service composite lorsqu'il utilise plusieurs autres services de niveaux inférieurs.

Certaines méthodologies combinent une approche SOA & MDA, par exemple Praxeme. Dans ce cas la définition et la découverte des services va se faire par des itérations de modélisation. Que ce soit dans l'aspect sémantique, pragmatique ou logique, la MOA a un très grand rôle à jouer.

Pour le métier la SOA peut n'être qu'une tactique permettant d'atteindre un objectif d'agilité dans les processus métiers. La mise en place du BPM sera un objectif atteignable et intéressant uniquement si les services sont réutilisables d'un point de vue métier. Et pour cela la MOA a une forte valeur ajoutée afin de déterminer les frontières des différents services et pour anticiper sur les réutilisations métiers possibles.

En tant que MOA nous avons souvent tendance à penser directement à la solution. Il est vrai qu'il est plus naturel de parler des écrans d'une application, d'un batch qui va effectuer des traitements car on se raccroche alors à du concret, de l'existant. Mais c'est aussi rester un peu terre-à-terre. Quitte à prendre de la hauteur, autant essayer de penser services. Par exemple si vous être déjà habitués à travailler sur des exigences et des cas d'utilisation, vous pouvez très bien proposer dans une spécification détaillée un découpage du système en services métiers. Et dans un projet qui porte sur un processus métier, il est encore plus naturel d'identifier les services métiers qui correspondent souvent à une activité de ce processus (en tout cas dans une vision purement métier). Connaître ces services permet à la MOA de dynamiser la réutilisation au sein du SI et de comprendre les problématiques engendrées par la maintenance d'un service qui est utilisé par plusieurs consommateurs et donc de faire les bons choix dans l'utilisation des budgets.

dimanche, février 7 2010

Comment améliorer l'alignement IT/métier en utilisant un outil de gestion des exigences ?

Par Olivier Durand le dimanche, février 7 2010, 17:44 - Etudier

L'informatique ne doit plus simplement suivre le métier. On attend aujourd'hui d'un SI qu'il soit capable de s'adapter à toutes les évolutions du business même ceux qui n'ont pas été anticipés par les opérationnels. Dans une étude concernant l'état de l'art de l'aligement IT / Métier en France publiée en 2008 par le cabinet PAC - Pierre Audoin Consultants, on apprend que La collaboration entre maîtrises [maîtrises d'ouvrage et maîtrises d'œuvres] est un point crucial, qui pourrait être le fil rouge de cette étude. Elle est jugée critique à 94%. On note également dans cette étude que l'intégration MOA/MOE est le deuxième levier juste derrière le projet stratégique au niveau de l'entreprise pour améliorer l'alignement IT / Métier.

Il existe des outils qui peuvent aider à plusieurs niveaux sur ce sujet. Ce sont les outils de gestion des exigences (requirements management). Une exigence fait référence à un besoin d'une des parties prenantes du projet. Une exigence peut être fonctionnelle ou non fonctionnelle. Concernant les outils, on peut par exemple citer Entreprise Architect. Dans leur document Requirements Management with Enterprise Architect, ils expliquent comment UML est utilisé pour modéliser les exigences. Dans un autre style, moins graphique, IBM propose DOORS. Dans leur livre blanc Ten steps to better requirements management, IBM nous explique ce qu'une exigence doit être :

  • Correcte (techniquement et juridiquement possible) ;
  • Complète (exprime une idée ou un fait dans sa totalité) ;
  • Claire (sans ambiguïté) ;
  • Non contradictoire (pas en conflit avec une autre exigence ) ;
  • Vérifiable (il est possible de définir si le système répond à cette exigence) ;
  • Traçable (identifié de manière unique et tracé) ;
  • Faisable (peut être accompli dans les coûts et délais prévus) ;
  • Modulaire (peut être changé sans impact excessif) ;
  • Indépendant de la conception (ne parle pas de solution concernant la conception).

(la traduction est un métier)

Une fois que les exigences sont exprimées, tout l'intérêt d'un outil de gestion des exigences est de permettre la traçabilité afin de pouvoir répondre aux questions suivantes :

  • Est-ce que tous mes besoins ont été couverts par le système ?
  • Quels besoins étaient mal exprimés et donc volatiles ?
  • Quel est l'impact si je modifie une exigence ?

C'est en étant capable d'analyser ces points qu'on pourra ensuite améliorer l'alignement IT / Métier. Par exemple si un des besoins était trop volatile, l'IT ne pourrait pas s'aligner. Il peut donc être nécessaire par exemple de chercher une autre organisation qui permette d'avoir une expression des besoins plus pérenne. Un besoin peut-être exprimé sur un Post-It  (heu pardon je voulais dire papillon adhésif amovible) par une des parties prenantes du projet, mais la MOA se doit ensuite de formaliser ces besoins sous forme d'exigences. Un bon outil permettra de tirer profit d'une telle démarche.

Modernanalyst.com - There's an app for that!