Archives par mot-clé : Méthode d’analyse

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.

 

Programmation graphique ?

Cela fait des années qu’on oppose programmation graphique à programmation textuelle.

A mon sens, c’est le même sujet, quand il s’agit de programmation ou d’analyse.

On peut faire de l’analyse avec des textes clairs, ou avec de joli schémas.

Donc, est-ce une bonne idée de faire de jolis dessins ?

Les dessins permettent-ils de complètement définir un sujet, plus facilement qu’avec du texte ?

Certains le pensent, comme ces solutions UML, qui promettent « la fin de la programmation » : Vous faites les différents schémas, et hop, un générateur de code va tout générer, et c’est fini.

Je dois dire que je ne suis pas en phase avec cette approche… Je n’y crois pas, et je pense que, quand on rentre dans les détails, les schémas finissent par être trop complexes.

Cela n’empêche pas que, pour moi, certains schémas sont très bien pour clarifier les échanges.

J’utilise principalement deux diagrammes UML : le diagramme de classe et les scénarios.

Le diagramme de classe est une bonne façon pour montrer la structure des données. C’est un modèle bien plus intuitif qu’un schéma relationnel.

Sa limite est qu’il intègre des données très différentes : l’héritage est une notion associée aux classes (ce sont les classes qui héritent les une des autres) alors que les liens sont en fait des liens entre les objets. Mais c’est pas grâve, on s’en sort très bien ;). Pour ma part, quand je peux, je sépare les schémas d’héritage des liens entre les objets.

L’autre schéma, les scénarios d’usages, permet de montrer un « exemple d’échanges » entre plusieurs objets.

C’est un schéma sympa, qui permet de comprendre la dynamique entre plusieurs objets.

Sa limite est de ne montrer qu’une option, parmi un ensemble de possible beaucoup plus vaste.

En particulier, il ne faut surtout pas utiliser de tels schémas pour les cas d’erreurs.

Sinon, je trouve qu’on fait de belles analyses avec… word.

Après pas mal d’années d’expérience, je trouve que le plus efficace, pour décrire un sujet, c’est de décrire, avec du texte donc, les différents cas.

Pour simplifier ces textes, je rajoute, en entête du « cas », un ensemble d’hypothèses.

C’est une manière, un peu artificielle, de simplifier le traitement d’un cas donné.

Exemple pour le e-commerce : processsus achat.

Et bien avec ma méthode, au lieu d’avoir un seul flux d’analyse, je découpe, en prenant les différentes hypothèses :

  • Compte existant et déjà identifié
  • Compte existant et non identifié
  • Nouveau client

L’énorme avantage est que cela permet de simplifier énormément la lecture de chaque cas.

Autre point : j’ai pris l’habitude, quand c’est possible, de séparer l’analyse « normale » de l’analyse des cas d’erreurs.

Là aussi, c’est un peu artificiel, mais ça permet de « séparer les variables » : on commence par s’intéresser au cas « normal », puis on s’intéresse aux cas « limites ».