Coûts et risques

Back to raw metrics – Retour vers les métriques élémentaires.

Un client vous confie un audit de la qualité d’une application ou d’un portefeuille d’applications. Il en attend une réponse á une question bien précise. Par exemple :

  • Cette application représente une part importante de mon budget : est-il possible de réduire ses coûts et comment ?
  • On me demande de reprendre la maintenance de cette application. Je sais simplement qu’il s’agit d’une application complexe. A quoi dois-je m’attendre ?
  • Est-il possible d’outsourcer cette application ? Quels sont les risques ?
  • Nous allons fusionner avec cette autre entité. Quelles applications utiliser ? Les leurs ou les nôtres ?

Il y a deux questions distinctes dans ces questions:

  1. Quels sont les coûts ?
  2. Quels sont les risques ?

L’informatique produit des applications. Elle met á disposition des utilisateurs des applications qui leur permettent d’exercer le métier de l’entreprise. Si ces applications tombent en panne, connaissent des erreurs, fonctionnent trop lentement, perdent des données, les utilisateurs sont, á juste titre, mécontents.

Un audit de la qualité d’une application devrait toujours répondre á cette double question : comment optimiser les coûts sans sacrifier la qualité du produit ?

Commençons par les métriques quantitatives disponibles avec un outil d’analyse de code.

La taille de l’application, en nombre de lignes de code (LOC), ou de ses différents modules. Cette mesure est dépendante de la technologie : 200 000 lignes de code (ou encore 200 kLOC) représente une taille importante pour une application J2EE mais relativement minime pour du Cobol.

Le nombre d’objets. Par objet, j’entends bien sûr les fichiers, mais aussi les composants : classes et méthodes Java, pages JSP, fichiers Javascript, programmes et paragraphes Cobol, fonctions et procédures SQL, etc. En soi, ce nombre n’est pas significatif, mais rapporté au nombre de lignes de code, l’on obtient une mesure très importante : la granularité des objets.
200 kLOC dans 200 classes Java représente 1 000 lignes de code par classe : c’est énorme. Cette application est probablement peu ‘lisible’, et nécessitera un effort – donc un coût – plus important dès lors qu’on voudra la transférer á une autre équipe. A prendre en compte si notre client souhaite effectuer une reprise de maintenance applicative ou un outsourcing.

Le nombre de méthodes par classe : plus il sera élevé, plus les classes seront ‘lourdes’ de fonctionnalités. Cela peut indiquer un problème de design, qui va peser lá encore sur la compréhension de l’application, mais aussi sur la difficulté de faire évoluer celle-ci. Le risque devient plus élevé d’introduire des défauts lorsqu’un développeur effectue une modification. Prévoir une charge de test en conséquence. Ceci va peser sur les coûts de maintenance.

Regardez également le nombre de LOC par méthode, lá encore pour mesurer la portabilité de l’application. Mais surtout, le pourcentage de commentaires (lignes de commentaires / total LOC). Ces mesures permettent de préciser la charge de transfert de l’application.

Le nombre de lignes de code en commentaires. Un développeur met du code en commentaires afin de sauvegarder cette version du code. Cela indique qu’il n’est pas sûr, soit de la nouvelle fonctionnalité á implémenter, soit du code á produire pour implémenter celle-ci.
C’est généralement un bon indicateur de l’âge de l’application. Plus le code en commentaires est élevé, plus le nombre de développeurs qui se sont succédés sur l’application est important, plus l’application est ancienne. Une fois cependant, ce taux de code en commentaires était élevé dans une application qui en était á sa première version, ce qui indiquait une évolution des spécifications fonctionnelles en cours de développement.

Autres mesures intéressantes, lorsqu’elles sont disponibles : les commentaires vides. Ou les objets dont le code complet est en commentaires : le programme ou la méthode ne fait rien. A part ajouter de la charge de maintenance inutilement.

Le nombre de lignes dupliquées. Très dangereux pour la fiabilité de l’application. Si un même bloc de code est dupliqué N fois, toute modification de ce code devra être effectuée N fois. Non seulement cela pèse sur le coût de maintenance de l’application, mais si le développeur oublie de répercuter la modification sur un seul bloc, le risque de dysfonctionnement pour les utilisateurs est élevé. Donc lá encore, charge d’évolution importante et charge de tests également. Plutôt que de dupliquer une fonctionnalité, il serait plus judicieux de disposer d’un composant unique qui implémente celle-ci. Un composant réutilisable de qualité au lieu de N composants dupliqués : que préférez vous, pour votre budget et vos utilisateurs ?

La complexité cyclomatique (CC). Sans entrer dans le détail de cette mesure, disons que la CC est un bon indicateur du nombre de règles fonctionnelles ou techniques présentes dans un composant ou une application. Au-delà de 60 000 points de CC, une application embarque tellement de fonctionnalités qu’elle devient très difficile á tester. Prévoir un outil d’automatisation des tests, ou vous allez exploser votre budget et vos plannings.

Identifiez les composants avec la CC la plus élevée afin de repérez ceux qui seront les plus difficiles á faire évoluer.

Croisez la complexité avec le nombre de lignes de code, et vous aurez les composants les plus dangereux pour vos utilisateurs : le risque d’introduire un défaut est élevé puisque le composant est á la fois lourd et complexe. Là encore, tests rigoureux et exhaustifs obligatoires. Si de surcroît il est peu documenté, vous pouvez envisager de le réécrire.

On voit qu’il suffit de quelques métriques élémentaires (raw metrics) pour pouvoir commencer á répondre aux questions de notre client :

  • Quel est le coût de transfert de cette application ? Quel est l’effort pour un nouveau développeur afin qu’il soit opérationnel sur cette application ?
  • Quel est le coût d’une évolution ? Quelles charges de test prévoir ?
  • Quel est le risque d’introduire un défaut lorsqu’on réalise une évolution ? Quel est le risque de non-fiabilité pour les utilisateurs ?

Avec un peu d’expérience – ces nombres peuvent varier selon les technologies – mais surtout du simple bon sens, on apprend vite quelles sont les données intéressantes et comment les combiner afin d’optimiser ces quelques mesures.

Une métrique n’est qu’un nombre. C’est l’utilisation que nous en faisons qui lui donne toute sa valeur pour répondre á une question donnée : quels coûts / quels risques ?

Ce article est également disponible en Leer este articulo en castellano et Read that post in english.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *