Je n’aime pas les organigrammes pour l’analyse

Comment faire une analyse ?

Dans un contexte donné, vous voulez « poser à plat » un problème.

Il y a besoin d’un « document de référence » qui doit permettre à tout le monde de se comprendre.

Une solution peut être de faire un beau graphe, du genre :

L’idée, c’est donc d’avoir un beau schéma pour rendre les choses explicites et claires.

Claires ? ça reste à voir !

D’abord, bien souvent, ces graphiques sont fait sans réel objectif de clarté. Exemple : un coup le « non » part à gauche, un coup à droite, un autre coup en dessous.

Ce qui fait que la lecture n’est en fait pas du tout implicite.

Ensuite, dès qu’on a un cas « normal » à traiter, on se retrouve à remplir une page A3 avec une police 6, si vous voyez ce que je veux dire ;).

Encore un point : le graphique devient vite « plat de nouille », et cela devient un exercise en soit que de faire le schéma sans que les traits se croisent trop.

Au final, je n’aime pas ces méthodes d’analyses. Je pense que seul le gars qui fait le graphique comprend réellement le truc.

J’aime mieux :

Les textes, qui expliquent de manière simple et concises ce qu’il faut comprendre.

Séparer les cas et décrire différents scénarios, dans des contextes différents.

Exemple : pour décrire le processus achat d’un site, au lieu de faire une seule analyse bien « prise de tête », on décrit se qui se passe, dans les différents cas : utilisateur identifié, nouvel utilisateur et utilisateur ayant un compte mais non identifié.

En « fixant » quelques variables en début de scénario, on rend son écriture bien plus simple.

 

5 commentaires

  1. « Au final, je n’aime pas ces méthodes d’analyses. Je pense que seul le gars qui fait le graphique comprend réellement le truc. »

    Je pense que tout est dit: écrire une doc, sous quelque format que ce soit, permet d’abord et avant tout au concepteur de finaliser le processus intellectuel de création.

    Ensuite, « Ce qui se conçoit bien s’énonce clairement – Et les mots pour le dire arrivent aisément »

  2. Je tempérerais ton opinion sur ce genre de graphe en disant qu’ils peuvent être utiles pour décrire des sous-problèmes d’un problème plus complexe. Ex : le processus de login est généralement assez simple pour être décrit par un graphe de décision mais vouloir décrire le parcours complet d’un utilisateur du login au logout revient quasiment à développer le site. Donc pour résumer : pour des évols : oui pour de la création from scratch : avec modération

  3. On est entre nous là 😉

    Olivier, je ne suis pas d’accord avec toi : bien sûr qu’on peut faire ce type de graphe, mais je n’ai pas vu de cas ou cela apportait un avantage, par rapport à une description de la solution.

    Après, il y a d’autres graphes que j’aime bien, dont les Uses cases UML.

  4. Je crois savoir pourquoi les use cases trouvent grâce à tes yeux.
    Ce sont des diagrammes dont Booch&al voulaient qu’ils soient compréhensibles par tous (donc en particulier par les donneurs d’ordre)
    (je ne trouve plus la référence mais je crois me souvenir d’un texte de Booch à ce sujet)
    A partir de la page Wikipedia sur les U-C et des ressources liées, quelques citations qui vont dans le sens d’une description « peu formatée »:
    Martin Fowler states « There is no standard way to write the content of a use case, and different formats work well in different cases.

    Jacobson’s original usage scenarios were intentionally informal. He found out that people did — and still do — resist writing them whenever they become more formal. In fact, when I once asked him about formal models for use cases, Jacobson replied, “Oh, I have a formal model for use cases, all right. The only problem is that no one wants to use it.”

    On part cependant loin dans l’epistémiologie de l’informatique, mais c’est intéressant 🙂

  5. Personnellement je pense qu’un bon diagramme vaut mieux qu’un long discours ! Bien évidemment il y a des règles à suivre et notamment une normalisation d’écriture pour éviter les effets « un coup à droite, un coup à gauche » ensuite il existe des « standards », les U-C bien sur. En terme d’archi j’aime bien la modélisation UML – ca demande un peu de « legend » mais ca reste pas mal pour décrire une base de donnée et ces sympathiques relations – notamment en cas de custo d’un modele d’éditeur (ATG ou WebSphere Commerce).
    TOGAF propose aussi une approche normalisée, mais le cercle se restreint aux « initiés » et rejoint assez la spécification « textuelle », l’approche TOGAF reste un incontournable – enfin pour Bibi 🙂 que je complète avec des « bons diagrammes »

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.