Les Métriques Software

Un support méthodologique pour la compréhension intrinsèque de la qualité des développements objets

Instinctivement, nous pouvons deviner que les « métriques du logiciel » impliquent des chiffres et des mesures des différents aspects du processus de développement logiciel. Si nous nous tournons vers la littérature, nous pouvons trouver plusieurs définitions, qui donnent une interprétation plus ou moins différentes du même terme.

Goodman (1993)[1] définit les métriques logicielles comme « l’application continue de techniques de mesures sur le processus de développement pour fournir des informations de gestion pertinentes et opportunes, ainsi que l’utilisation de techniques pour améliorer ce processus et ses produits ». Le champ est donc vaste mais le but concerne bien l’amélioration de tous les aspects de la réalisation des logiciels.

Grady (1992)[2] souligne pour sa part que les « métriques de logiciels sont utilisées pour mesurer des attributs spécifiques d’un développement logiciel afin de nous aider à prendre de meilleures décisions ». Cette définition met en évidence l’un des problèmes liés aux développements logiciels, le manque d’informations pour prévoir et évaluer les projets.

D’autres auteurs, comme Zuse (1991)[3], font une distinction entre « mesures logicielles » et « métriques logicielles » ! Cela implique que la mesure et la métrique sont des termes plus mathématiquement corrects lors de l’examen de la valeur empirique de différents objets mesurés dans le processus de développement logiciel. En outre, ils constatent qu’une métrique est un critère utilisé pour déterminer la différence ou la distance entre deux entités, par exemple la métrique d’Euclide, qui mesure la distance la plus courte entre deux points.

Parfois, nous trouvons des tentatives de classification des différents types de métriques logiciels. Une telle distinction est faite entre les mesures primitive et celle qui sont calculées. Les métriques primitives sont directement mesurables ou dénombrable, comme le comptage des lignes de code. Les métriques calculées utilisent une sorte de formule mathématique pour obtenir la valeur d’un attribut déterminé.

Pour différentier les mesures qui sont utilisés pour la prise de décision de haut niveau il est fait référence à des « métriques globales ». Cette expression renvoi à des informations sur la taille, le produit, et la qualité du développement qui influent sur la maintenabilité des logiciels. Cette première notion implique qu’il pourrait également y avoir des « métriques locales » ou « métriques de phase », plus liées à des cycles particuliers du développement.

En tout état de cause nous pouvons proposer de synthétiser la métrique software comme :

Une mesure de différents attributs du processus de développement logiciel dans le but d’obtenir des informations utiles et pertinentes pour améliorer l’efficience globale du processus de développement.

Je pense qu’il est important de reconsidérer la place de ces métriques dans nos processus de développement et qu’il faut appliquer les métriques en fonction des différents buts de mesure. Certaines métriques et méthodes de mesure sont plus utiles à une phase spécifique du développement logiciel :

  • Dans les phases préliminaires comme l’analyse des exigences et la conception du système
  • Dans la phase d’implémentation pour capturer le statut réel du projet afin d’en mesurer la progression
  • Dans la phase des tests dans la remontée du nombre de défauts ainsi que la densité de défauts

Il faut appliquer les métriques pertinentes selon les différentes exigences en matière d’objectifs de qualité du produit final. Si on évalue la convivialité du logiciel, par exemple, le degré de satisfaction des clients en termes de facilité d’utilisation est la mesure la plus parlante !

Enfin il faut appliquer les métriques en regard des différents rôles des membres d’une équipe de développement. Les développeurs choisissent des métriques comme l’effort contribué au projet, la durée estimée pour leur tâche, la complexité du module sur lequel ils travaillent, le nombre de lignes de code produit ou la densité de défauts. Le chef de projet mettra l’emphase sur la complexité ou le volume estimé du projet afin de planifier les tâches, les dates et l’effort global prévus. Le management de l’entreprise s’intéresse plutôt aux métriques incluant la valeur commerciale du produit final en fonction de l’investissement avant le projet, le degré de satisfaction des clients, la comparaison entre le temps prévu et le budget disponible et les valeurs obtenues au cours de la construction.

Le sujet est approfondi dans un document que vous pouvez télécharger.


[1] Goodman, P., « Practical implementation of software metrics”, 1993, McGraw-Hill publication

[2] Grady, R.B., « Practical software metrics for project management and process improvement », 1992, Prentice Hall

[3] Zuse, H., « Software complexity – measures and methods », 1991, Walter de Gruyter & Co

Advertisements

Agilité : Mythe ou Réalité

Adopter la bonne organisation de développement logiciel est ce possible ?

En 1975, Frederick Brooks a écrit un livre sur la gestion de projets informatiques intitulé « The Mythical Man-Month (le mythe du mois-homme) ». Dans cet ouvrage, il démontrait brillamment qu’ajouter des personnes à un projet de développement le ralentissait au lieu de l’accélérer. La raison était mécanique et il démontrait que l’ajout de nouvelles personnes aboutissait à une augmentation non linéaire du temps consacré à la réalisation.

Cinq années avant le livre de Brooks (en 1970), une méthodologie de développement logiciel, appelée le « cycle » en cascade (Waterfall cycle), était inventée. Cette approche appliquait les idées de l’ingénierie (mécanique, civile, etc…) au logiciel. Le principe consistait à commencer par recueillir les spécifications, puis faire le design, puis l’implémenter, enfin le tester, et finalement obtenir un logiciel de manière linéaire.

Il a coulé beaucoup d’eau sous les ponts depuis et nous avons beaucoup appris dans le domaine du développement logiciel. Le modèle en cascade est maintenant de plus en plus désuet car il est trop rigide et irréaliste. Dans notre quotidien, les projets de logiciels sont mal définis et ont des fonctionnalités en constante évolution, ce qui ne permet pas de tout envisager dès le départ. Avec l’avènement des langages de programmation modernes de 4ième ou de 5ième génération (Java, PHP, Python, Perl, C# ou Ruby), les nombreuses bibliothèques et un nombre sans précédent d’infrastructures nous sommes arrivés à la fin des années 90 à un nouveau pallié de l’évolution de l’ingénierie logicielle.

C’est alors que sont apparues de nouvelles méthodes regroupées sous l’appellation de techniques de « conceptions agiles ». Le principe en est simple : pour concevoir un logiciel aujourd’hui, vous n’avez besoin que de quelques bons développeurs ! De plus cette approche permet aux développeurs de réajuster constamment le logiciel en fonction du marché et des exigences des clients.

Mais est-ce si simple ? (Lire la suite …) (Document au format Pdf)