20 juil. 2006

Essais de Métriques

Voici donc une autre représentation qui fera plus appel à la faculté que possède notre cerveau à reconnaître des tâches plutôt que des lignes (c’est le premier type de vision qu’un être humain perçoit).

Les métriques sont la base d’un travail rationnel quelque soit l’activité : Mesurer c’est contrôler

Le Department de “ Informatics (IFI) at the University of Zurich” propose un papier [PIN] fort intéressant et riche en information. Il présente un modèle de graphique de type « Radar » appelé « Kiviat graphs », où

  • chaque axe représente une métrique,
  • chaque polygone une révision.



Figure 1 : graphique de type "radar"

L’objectif de ce document est d’indiquer comment on peut réaliser des métriques complexes, et bien plus lisibles que le [PIN].

Mode Opératoire

Disposant de SourceMonitor 2.0 [SOU] et de 48 mois/homme de données tri-hebdomaires, j’ai tenté avec Excel de reproduire partiellement ces schémas.

Les radars sous Excel ne permettant pas (?) d’avoir des

  • échelles différentes sur chaque axe,
  • valeurs non cumulées,

le résultat est plutôt médiocre car peu de dynamique visuelle.

J’ai donc choisi un graphique de type Surface.


Figure 2 : En couleur, l'évolution de chaque métrique au fil des révisions du projet

La Figure 2 présente un éclairage simulé en haut à gauche du graphique, ainsi on gagne une vision en pseudo 3D.

Pour rejoindre le principe de tâche, il faudrait d’avoir des nuances d’une seule couleur. Sur cette figure, l’effet d’ombrage est obtenu en accédant aux propriétés d’un symbole de légende


Figure 3 : Zoom de la partie "Légende" et click sur un symbole de légende pour accéder à l'effet d'ombrage

Pour réaliser ce type de métrique, j’ai

  • exporté les checkpoints de SourceMonitor vers un fichier CSV.
  • Créé un connecteur ODBC vers le fichier exporté
  • Remplacé les ‘,’ par des ‘;’ afin de pouvoir avoir une compatibilité avec Excel (!).
  • Sous Excel :
    • Sélectionné le menu « Données>Données Externes>Créer une requête »
    • Affiché les données dans Microsoft Query ( pour permettre de dépasser les 65536 lignes limitées par Excel)
    • Enregistré les données de la requête dans Excel
    • Renvoyé les données vers un rapport de tableau croisé dynamique (TCD)
    • Disposé les champs du TCD comme suit :


Figure 4 : Création du TCD

Le résultat est le suivant :


Figure 5 : Le TCD

A partir de ce tableau, on va normaliser les valeurs pour améliorer la lisibilité. Cette normalisation se fera par rapport à la valeur maximale de chaque ligne (ou révision). Cette opération consiste à

  • calculer pour chaque ligne le max(B2:B12) dans la cellule B14
  • recopier la structure du TCD en calculant chaque cellule avec la formule B2/B$14

En choisissant un ordre satisfaisant pour les séries de données et en travaillant un petit peu sur la présentation, on peut alors obtenir le résultat de la Figure 2.

On peut aussi s’en mettre plein les mirettes en changeant l’angle de vue :


Figure 6 : Vision 3D de la métrique

En affinant l’échelle c’est encore plus précis. On se croirait dans un paysage !


Figure 7 : Augmentation de la précision

La Figure 2 laisse clairement apparaître un plateau sur la droite creusé trois canyons avec quatre montagnes sur la gauche.

  • Les canyons orientés suivant une métrique particulière représentent la rapidité à laquelle la métrique évolue. La Figure 2 montre que la complexité (telle que définie dans SourceMonitor) évolue bien plus lentement que toutes les autres.
  • Les plateaux indiquent une stabilisation globale du produit.
  • Un maintient de profil d’une révision à l’autre indique un travail uniforme.
  • Des ornières le long d’une révision indiquent des refontes du code.

En fait, les canyons ou les pics orientés dans le sens des révisions indiquent une augmentation de complexité, d’ajout de fonctionnalité, ou de simplification suite à du refactoring. C’est le cas des révision #0688, #1279 et #2040

Les métriques représentées par les figures précédentes sont issues d’un projet en C++.

Voici un autre exemple de métrique sur un projet écrit en VB6 :


Figure 8 : Paysage d'un projet VB de 7 mois.homme

La chute qui a lieu vers la révision #660 correspond à une refonte architecturale profonde du projet qui a été éclaté en plusieurs parties.

Globalement, un projet sain devrait comporter nécessairement cette forme de plateau sur la droite. Il est un indicateur de stabilité des modifications.

Relativement au projet donc ces métriques sont le reflet, il révèle aussi une forme de maturité du projet.

Comparatif

Avec cette solution, vu que l’on a un TCD, il est facile d’obtenir ce type de métrique pour chaque fichier, mais les métriques sont étroitement liées aux statistiques. Il convient donc de disposer de beaucoup d’informations pour une appréciation correcte d’un phénomène.

Cette représentation s’avère plus avantageuse que les graphiques de Kiviat car en vue de dessus, on obtient une vision 2D sans recouvrement possible, alors que [PIN] est obligé de traiter ce cas pour éviter la lecture impossible de graphique. Avec ce jeu de données, on constatera facilement ce problème sur un radar, car la révision #0444 était quasiment au niveau des métriques de la révision #2288.

Par ailleurs, en cas de grande quantité de révision, les différentes surfaces du radar sont trop proches les unes des autres pour identifier des formes caractérisant un état particulier ; aussi, on n’identifie facilement que l’enveloppe externe du radar.

Quant à, la Figure 2, elle laisse clairement apparaître un plateau sur la droite creusé de deux à trois canyons avec quatre montagnes sur la gauche. Une telle description appartient au langage courant. Elle est facilement transmissible car simple à expliquer. Essayez donc d’expliquer qu’une étoile à sa quatrième branche d’une taille double de la neuvième mais que le radar de la révision #0688…trop compliqué ! :-7

Pour ce qui est des métriques concernant les dépendances inter modules, [SOU] n’est pas assez riche pour fournir ce type d’information. [PIN] est donc mieux positionné que cette représentation. Maintenant, pourquoi ne pas imaginer des routes entre ces paysages, le tout formant le décors du projet…

Le langage naturel concernant les paysages est suffisamment riche pour permettre suffisamment de poésie et de partage de la topologie intrinsèque du projet.

Christophe MOUSTIER
19/03/05

[SOU] : http://www.campwoodsw.com/
[PIN] : « Visualizing Multiple Evolution Metrics », Martin Pinzger et al. (http://www.ifi.unizh.ch/swe/research/publications/papers/pinzger05-relvis.pdf)

Commentaires

1. Le mercredi, janvier 10 2007, 17:22 par drez

tres bonne etude. C'est tres interressant.
Je me suis toujours contenté de la vue en étoile, sans faire trop de rapprochement avec les anciennes revisions. Juste une visu rapide sur les chiffres... Mais avec un graphe 3D c'est plus clair !!

Merci !

Ajouter un commentaire

Les commentaires peuvent être formatés en utilisant une syntaxe wiki simplifiée.

Fil des commentaires de ce billet