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

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

Tag - Spécification fonctionnelle

Fil des billets - Fil des commentaires

mercredi, octobre 2 2013

Ecrire un livre via Leanpub - Maîtrise d'Ouvrage du Système d'Information en pratique

Attention, auto-promo à l'intérieur de ce billet :) !

Cela faisait longtemps que je n'avais pas écrit sur ce blog ! Je vais essayer de contribuer plus régulièrement.

J'ai profité de cette absence sur ce blog pour co-écrire un livre sur la maitrise d'ouvrage du SI. Pour cela, nous avons utilisé la plateforme Leanpub qui permet d'écrire un ouvrage de manière collaborative, en suivant les principes du Lean. L'idée c'est donc d'écrire une première version du livre que l'on publie assez tôt afin d'obtenir un retour rapide des lecteurs.

Donc si vous êtes intéressés par les sujets évoqués sur ce blog, vous aimerez ce livre qui présente des techniques très utiles pour réussir en tant que MOA. Il y est notamment question de : gestion des exigences, valeur métier, Minimum Viable Product, vision, business case, modélisation UML, story-board, maquette, user story, Behavior Driven Development, Acceptance Tests Driven Development, conduite du changement, rétrospective... En téléchargeant ce livre maintenant, vous pourrez l'avoir pour 0€ et en plus vous pourrez influencer son contenu en nous faisant vos commentaires sur ce qu'il faut étoffer, ajouter ou corriger. 

Si vous souhaitez plus d'information, c'est par ici :


mardi, avril 12 2011

Quelles astuces pour l'utilisation d'Axure RP Pro par la MOA ?

Comment utiliser au mieux un outil comme Axure RP Pro ? Le mieux c'est d'être curieux et fouiller dans les menus ! Mais voici quand même quelques petites "astuces" concernant l'utilisation des Widgets dans Axure.

Développez vos storyboards avec les composants Wireframe par défaut

Pour commencer, il faut utiliser les quelques composants disponibles par défaut dans Axure. Ceux-ci permettent d'effectuer des storyboards en mode fil de fer, c'est à dire sans prendre en compte l'aspect design (d'où le terme wireframe).

Axure

Axure

Utilisez des librairies de composants réalisés par d'autres pour vos spécifications détaillées - Axureland

Une fois que vous voulez passer dans une phase de spécifications fonctionnelles détaillées, les composants de base dans Axure sont un peu limitatifs. Mais vous pouvez étendre la liste de ces composants grâce aux librairies. Pour l'exemple, nous allons prendre la librairie Axure Better Defaults Library. Il vous faut télécharger cette librairie en cliquant sur le bouton Download Axure File à cette adresse :
http://axureland.com/index.php/site/entry/axure_better_defaults_library
Une fois le .zip téléchargé, dézippez le dans le répertoire :
...\Mes Documents\My Axure RP Libraries

Vous voyez alors apparaitre votre nouvel ensemble de widgets :

Axure

Ainsi vous aurez alors accès à de nouveaux composants pour définir vos écrans :

Axure

Créez vos propres librairies

Si vous avez un framework graphique maison, des best practices au niveau des IHM... vous pouvez créer vos propres librairies de composants à partager entre projets. Pour cela, dans le menu Widgets, cliquez sur Create library... :

Axure

Axure

Vous avez ainsi accès à un projet Axure qui représente votre librairie de Widgets :

Axure

Renommez le "New Widget 1" et dessinez votre propre widget :

Axure

Vous pouvez créer plusieurs widgets dans votre librairie. Ensuite vos widgets seront accessibles dans les autres projets :

Axure

J'espère que ces petites astuces vous seront utiles. En fait ce sont simplement des fonctionnalités standard de l'outil plus que de vraies astuces, mais parfois on oublie un peu de fouiller dans ce que permet de faire l'outil faute de temps, et on passe à côté de beaucoup de choses qui permettent pourtant de gagner un temps précieux.

jeudi, mars 17 2011

MOA et Scrum : Quels retours d'expériences ?

Cela fait quelques mois que je travaille sur un projet utilisant la méthodologie Scrum. Cette méthodologie dite "agile" bouleverse le travail de la MOA dans les organisations classiques où les rôles MOA et MOE sont gérés par des personnes distinctes, voire des équipes distinctes. Après vous avoir expliqué quelques bases sur l'agilité et la MOA dans un précédent billet (Le rôle de MOA est-il compatible avec les méthodes agiles ?), je me propose ici simplement de vous livrer mon retour d'expérience sur l'impact d'une telle méthodologie pour la MOA.

Ce qu'on a dit sur le rôle de la MOA dans les méthodes agiles...

On a beaucoup parlé des méthodes agiles depuis quelques années. Et on peut avoir l'impression par exemple que Scrum a été conçu par des développeurs, pour des développeurs. Je dis cela car la communauté agile s'est très vite rendue compte du problème que posait la MOA pour mettre en œuvre Scrum :

Scrum, Agilité et Rock'n roll : Se passer de la MOA ou se passer de l'agilité ?

J'ai dit à N. qu'une meilleure solution serait de supprimer la MOA. MOA et MOE c'est fait pour les travaux publics, pas pour le développement de logiciel. C'est le bon moment en période de crise pour éliminer les gaspillages...

Bon, c'était une boutade, on ne peut pas supprimer la MOA du jour au lendemain.

OCTO Talks! : Installer Scrum sur une organisation existante

L’autre population qui est mise en porte-à-faux lors du déploiement de SCRUM : la MOA. Là aussi, le rôle de MOA tel que nous le connaissons est en grande partie absorbé par l’équipe : clarification du besoin, qualification des demandes, tests, … Quelle position la MOA peut-elle alors adopter pour continuer à apporter de la valeur à un projet ?

La solution en laquelle nous croyons aujourd’hui est que la MOA soit partie intégrante de l’équipe.

Et ce n'est pas seulement un problème franco-français ou un problème de la métaphore MOA/MOE issue du BTP. C'est simplement que les méthodes agiles veulent mettre le client au cœur du process de développement d'un système informatique, en limitant les gaspillages : documentation inutile, intermédiaires superflus entre le développeur et le client. Ces sujets touchent principalement les activités de la MOA.

... et ce que j'ai expérimenté : User stories et storyboards,

Sur mon projet actuel, nous avons donc mis en place Scrum. En tant que MOA, on m'a dit : "Maintenant, tu rédiges des user stories.". Ok. J'ai en fait pris le rôle de Product owner, délégué. Avant cela, j'ai quand même fait une étude préalable qui a abouti sur la rédaction d'un cahier des charges chargé d'une étude de l'existant et d'une liste d'exigences. J'ai ensuite décliné ces exigences en user stories. Ces user stories sont un outil très pratique pour planifier les sprints. Au départ j'ai simplement accompagné ces user stories d'un storyboard et de maquettes réalisées via Axure.

quelques spécifications fonctionnelles "old school"

Pas suffisant. J'ai rapidement bifurqué vers une spécification fonctionnelle détaillée ! Aïe, de la documentation ? Mais pourquoi ? C'était impossible d'avoir une vision globale du système sans cela. Et la traçabilité n'était pas suffisante, j'avais toujours l'impression d'aller à l'encontre d'un choix de conception fonctionnel fait plus tôt dans le projet, faute de me rappeler des motifs de ce choix. De plus il était très difficile de discuter avec les projets non Scrum sans un document de spécifications fonctionnelles. J'ai donc décidé de maintenir ce document, enrichi au fil des sprints en essayant d'avoir toujours un ou deux sprints d'avance. De plus certaines réglementations demandent que le système d'information soit documenté, donc impossible de passer outre une documentation fonctionnelle.

et les critères d'acceptation !

Oops, malgré cela, je me suis rendu compte que j'avais oublié un élément capital dans les user stories : les critères d'acceptation ! Pour faciliter la recette au fil de l'eau, il est important d'avoir ces critères d'acceptation au niveau des users stories, même si ceux-ci font souvent référence aux spécifications fonctionnelles. Je pense aussi qu'une automatisation des tests fonctionnels est capitale pour tirer tous les bénéfices d'un mode de développement avec des itérations courtes.

Au final, un bilan positif ?

Finalement, nous avons mis en place Scrum, mais j'ai quand même gardé certains outils propres aux cycles en V. Pourquoi ? Surement parce qu'on ne peut pas changer ses habitudes aussi facilement, mais aussi parce que Scrum ne se suffit pas à lui-même. Comme toute méthodologie, il faut l'adapter au contexte. Tous les développeurs ne sont pas capables de gérer les aspects fonctionnels, les clients ne sont pas forcément prêts à rédiger des users stories, et les équipes avec lesquelles vous devez interagir ne sont pas forcément "agiles". Les itérations courtes, les démos, la collaboration, la recherche du consensus, le pilotage par la valeur ajoutée sont par contre autant d'éléments très positifs de la méthodologie.

Je pense donc que le rôle de MOA ou AMOA s'inscrit parfaitement dans cette méthodologie du moment que l'on accepte que le product owner puisse être en fait une équipe composée d'un sponsor métier, d'utilisateurs clés et d'un ou plusieurs MOA. Dans ce cas,  la ou les MOA doivent clairement avoir la délégation et la capacité pour arbitrer les points en temps réel, quitte à remonter ensuite les points les plus problématiques lors des comités de pilotage du projet. La MOA peut alors apporter toute son expertise en terme d'analyse, de modélisation et de construction de lien fort entre le SI et le métier.

mercredi, juillet 21 2010

Dans quels cas utiliser les cas d'utilisation ?

"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.

dimanche, janvier 24 2010

Comment spécifier une interface graphique sur un terminal à écran tactile multipoint ?

L'informatique est un secteur où les technologies évoluent très rapidement. Et en ce moment, la mode est aux terminaux à écrans tactiles multipoints : Apple iPhone, Palm Pixi, Microsoft Surface...

Selon le grand dictionnaire terminologique de l'office québécois de la langue française une écran tactile multipoint est un

Écran qui possède le matériel nécessaire pour détecter simultanément à plusieurs points de sa surface les pressions ou les déplacements des doigts, des mains ou des stylets, et qui est relié à un système informatique capable d'interpréter ces actions séparément et en même temps tout en coordonnant l'information.

Avec ces technologies, la sémantique de l'IHM est forcément différente. Si vous utilisez la tableau ICAR (Intention, Contrôle, Action, Réponse), vous devez oubliez les classiques Cliquer, Double cliquer...

Toucher
Cette action reste valable pour tout écran tactile. L'action de base c'est donc de toucher l'écran pour lancer une commande.

Pincer / Ecarter
Sur l'iPhone pour zoomer ou dézoomer, il suffit de pincer virtuellement avec deux doigts ou d'écarter ces mêmes doigts.

Secouer
Ces nouveaux terminaux mobiles amènent également des fonctions annexes comme un accéléromètre. Ainsi, secouer son terminal peut permettre de retourner à l'écran d'accueil par exemple.

Pencher
En penchant son terminal on va également pouvoir activer des commandes. Par exemple en penchant à droite ou à gauche, on va contrôler un personnage dans un jeu de plateforme pour le faire aller à droite ou à gauche.

A peine commençons-nous à nous faire à ces nouvelles interfaces que les chercheurs sont déjà sur des nouveaux systèmes de "pointage" comme par exemple le "Vision-based Input interface" qui consiste à reconnaitre les mouvements du doigt afin de permettre un pointage en "3D". Gageons que l'informatique ambiante (Ubiquitous computing) saura utiliser ces nouvelles technologies.

vendredi, février 27 2009

Comment spécifier une interface graphique de manière détaillée ?

L'étude fonctionnelle de cette application de gestion a été faite. Vous avez un beau cahier des charges. La spécification générale a été réalisée, vous connaissez vos cas d'utilisation sur le bout des doigts. Il est donc temps de passer à la spécification fonctionnelle détaillée, et l'un des éléments clé, quelque soit la méthodologie mise en œuvre, c'est la spécification des écrans.

1) Le papier et le crayon :

Pour mettre un peu ses idées au clair, rien de tel qu'une feuille, un crayon à papier et une gomme. Commencer par dessiner au brouillon ses IHM permet de poser ses idées.

2) L'outil pour designer ses écrans :

Une fois qu'on voit grosso modo ce que l'on souhaite faire, on peut utiliser un outil pour dessiner ses écrans en mode "fil de fer" voire pour effectuer un story board (un genre de prototype pour illustrer la navigation).

Une suite bureautique standard permet de réaliser des dessins sommaires (OpenOffice.org - http://fr.openoffice.org/) de même qu'un outil dédié à la réalisation de schémas (Visio - http://office.microsoft.com/fr-fr/visio/default.aspx). Seulement ces outils très généralistes ne sont pas les plus performants pour cette tâche spécifique.

Il est beaucoup plus efficace d'utiliser un outil dédié à la réalisation de maquettes et de prototypes d'écrans comme par exemple :
Axure RP - http://www.axure.com/.

Cet outil est plutôt fait pour les applications Web à la base, mais fait très bien son office pour les applications "lourdes" également. Il vous permettra :
- De designer vos écrans à l'aide contrôles simples et d'autres personnalisés que vous pouvez créer et réutiliser.
- De spécifier le fonctionnement de vos écrans à l'aide d'annotations personnalisables.
Par exemple, vous pouvez créer des annotations pour créer un tableau ICAR (Intention - Contrôle - Action - Réponse). Exemple :
Intention = Supprimer un billet du blog
Contrôle
= Menu contextuel, Item supprimer
Action
= Clic
Réponse
= Ouverture d'une fenêtre de confirmation "Etes vous sur de vouloir supprimer ce billet", puis suppression du billet si bouton OK cliqué.
- De définir la navigation entre vos écrans.
- De créer un prototype navigable en HTML pour présenter la navigation entre les écrans à vos utilisateurs par exemple.
- De générer un dossier de spécification fonctionnelle détaillée des écrans au format Word par exemple, à partir d'un template personnalisable.

Axure permet donc d'industrialiser la gestion des spécifications fonctionnelles détaillées des écrans. Il permet également de réaliser des prototypes à moindre coût. Les écrans sont une excellente base pour valider des concepts au départ un peu abstrait avec des utilisateurs. Organiser une réunion de validation des écrans permet de corriger certaines erreurs en tout début de projet, ce qui coute beaucoup moins cher que lorsque tous les développements on été effectués. Bien sur les écrans ne sont que la partie visible de l'iceberg, mais je pense que pour des projets d'applications de gestion classiques, une bonne spécification de l'IHM est un élément clé de la réussite. Un outil comme Axure est une bonne assurance contre les échecs dus à des spécifications trop imprécises.