![\"\"](\"http:\/\/qualilogy.com\/wp-content\/uploads\/2011\/11\/QualCostRisk21.jpg\" "\\"QualCostRisk2\\"")
<\/a>L\u2019informatique produit des applications. Elle met \u00e1 disposition des utilisateurs des applications qui leur permettent d\u2019exercer le m\u00e9tier de l\u2019entreprise. Si ces applications tombent en panne, connaissent des erreurs, fonctionnent trop lentement, perdent des donn\u00e9es, les utilisateurs sont, \u00e1 juste titre, m\u00e9contents.<\/p>\nUn audit de la qualit\u00e9 d\u2019une application devrait toujours r\u00e9pondre \u00e1 cette double question : comment optimiser les co\u00fbts sans sacrifier la qualit\u00e9 du produit ?<\/p>\n
Commen\u00e7ons par les m\u00e9triques quantitatives disponibles avec un outil d\u2019analyse de code.<\/p>\n
La taille de l\u2019application, en nombre de lignes de code (LOC), ou de ses diff\u00e9rents modules. Cette mesure est d\u00e9pendante de la technologie : 200 000 lignes de code (ou encore 200 kLOC) repr\u00e9sente une taille importante pour une application J2EE mais relativement minime pour du Cobol.<\/p>\n
Le nombre d\u2019objets. Par objet, j\u2019entends bien s\u00fbr les fichiers, mais aussi les composants : classes et m\u00e9thodes Java, pages JSP, fichiers Javascript, programmes et paragraphes Cobol, fonctions et proc\u00e9dures SQL, etc. En soi, ce nombre n\u2019est pas significatif, mais rapport\u00e9 au nombre de lignes de code, l\u2019on obtient une mesure tr\u00e8s importante : la granularit\u00e9 des objets.
\n200 kLOC dans 200 classes Java repr\u00e9sente 1 000 lignes de code par classe : c\u2019est \u00e9norme. Cette application est probablement peu \u2018lisible\u2019, et n\u00e9cessitera un effort \u2013 donc un co\u00fbt \u2013 plus important d\u00e8s lors qu\u2019on voudra la transf\u00e9rer \u00e1 une autre \u00e9quipe. A prendre en compte si notre client souhaite effectuer une reprise de maintenance applicative ou un outsourcing.<\/p>\n
Le nombre de m\u00e9thodes par classe : plus il sera \u00e9lev\u00e9, plus les classes seront \u2018lourdes\u2019 de fonctionnalit\u00e9s. Cela peut indiquer un probl\u00e8me de design, qui va peser l\u00e1 encore sur la compr\u00e9hension de l\u2019application, mais aussi sur la difficult\u00e9 de faire \u00e9voluer celle-ci. Le risque devient plus \u00e9lev\u00e9 d\u2019introduire des d\u00e9fauts lorsqu\u2019un d\u00e9veloppeur effectue une modification. Pr\u00e9voir une charge de test en cons\u00e9quence. Ceci va peser sur les co\u00fbts de maintenance.<\/p>\n
Regardez \u00e9galement le nombre de LOC par m\u00e9thode, l\u00e1 encore pour mesurer la portabilit\u00e9 de l\u2019application. Mais surtout, le pourcentage de commentaires (lignes de commentaires \/ total LOC). Ces mesures permettent de pr\u00e9ciser la charge de transfert de l\u2019application.<\/p>\n
Le nombre de lignes de code en commentaires. Un d\u00e9veloppeur met du code en commentaires afin de sauvegarder cette version du code. Cela indique qu\u2019il n\u2019est pas s\u00fbr, soit de la nouvelle fonctionnalit\u00e9 \u00e1 impl\u00e9menter, soit du code \u00e1 produire pour impl\u00e9menter celle-ci.
\nC\u2019est g\u00e9n\u00e9ralement un bon indicateur de l\u2019\u00e2ge de l\u2019application. Plus le code en commentaires est \u00e9lev\u00e9, plus le nombre de d\u00e9veloppeurs qui se sont succ\u00e9d\u00e9s sur l\u2019application est important, plus l\u2019application est ancienne. Une fois cependant, ce taux de code en commentaires \u00e9tait \u00e9lev\u00e9 dans une application qui en \u00e9tait \u00e1 sa premi\u00e8re version, ce qui indiquait une \u00e9volution des sp\u00e9cifications fonctionnelles en cours de d\u00e9veloppement.<\/p>\n
Autres mesures int\u00e9ressantes, lorsqu\u2019elles sont disponibles : les commentaires vides. Ou les objets dont le code complet est en commentaires : le programme ou la m\u00e9thode ne fait rien. A part ajouter de la charge de maintenance inutilement.<\/p>\n
Le nombre de lignes dupliqu\u00e9es. Tr\u00e8s dangereux pour la fiabilit\u00e9 de l\u2019application. Si un m\u00eame bloc de code est dupliqu\u00e9 N fois, toute modification de ce code devra \u00eatre effectu\u00e9e N fois. Non seulement cela p\u00e8se sur le co\u00fbt de maintenance de l\u2019application, mais si le d\u00e9veloppeur oublie de r\u00e9percuter la modification sur un seul bloc, le risque de dysfonctionnement pour les utilisateurs est \u00e9lev\u00e9. Donc l\u00e1 encore, charge d\u2019\u00e9volution importante et charge de tests \u00e9galement. Plut\u00f4t que de dupliquer une fonctionnalit\u00e9, il serait plus judicieux de disposer d\u2019un composant unique qui impl\u00e9mente celle-ci. Un composant r\u00e9utilisable de qualit\u00e9 au lieu de N composants dupliqu\u00e9s : que pr\u00e9f\u00e9rez vous, pour votre budget et vos utilisateurs ?<\/p>\n
La complexit\u00e9 cyclomatique (CC). Sans entrer dans le d\u00e9tail de cette mesure, disons que la CC est un bon indicateur du nombre de r\u00e8gles fonctionnelles ou techniques pr\u00e9sentes dans un composant ou une application. Au-del\u00e0 de 60 000 points de CC, une application embarque tellement de fonctionnalit\u00e9s qu\u2019elle devient tr\u00e8s difficile \u00e1 tester. Pr\u00e9voir un outil d\u2019automatisation des tests, ou vous allez exploser votre budget et vos plannings.<\/p>\n
Identifiez les composants avec la CC la plus \u00e9lev\u00e9e afin de rep\u00e9rez ceux qui seront les plus difficiles \u00e1 faire \u00e9voluer.<\/p>\n
Croisez la complexit\u00e9 avec le nombre de lignes de code, et vous aurez les composants les plus dangereux pour vos utilisateurs : le risque d\u2019introduire un d\u00e9faut est \u00e9lev\u00e9 puisque le composant est \u00e1 la fois lourd et complexe. L\u00e0 encore, tests rigoureux et exhaustifs obligatoires. Si de surcro\u00eet il est peu document\u00e9, vous pouvez envisager de le r\u00e9\u00e9crire.<\/p>\n
On voit qu\u2019il suffit de quelques m\u00e9triques \u00e9l\u00e9mentaires (raw metrics) pour pouvoir commencer \u00e1 r\u00e9pondre aux questions de notre client :<\/p>\n
\n- Quel est le co\u00fbt de transfert de cette application ? Quel est l\u2019effort pour un nouveau d\u00e9veloppeur afin qu\u2019il soit op\u00e9rationnel sur cette application ?<\/li>\n
- Quel est le co\u00fbt d\u2019une \u00e9volution ? Quelles charges de test pr\u00e9voir ?<\/li>\n
- Quel est le risque d\u2019introduire un d\u00e9faut lorsqu\u2019on r\u00e9alise une \u00e9volution ? Quel est le risque de non-fiabilit\u00e9 pour les utilisateurs ?<\/li>\n<\/ul>\n
Avec un peu d\u2019exp\u00e9rience \u2013 ces nombres peuvent varier selon les technologies \u2013 mais surtout du simple bon sens, on apprend vite quelles sont les donn\u00e9es int\u00e9ressantes et comment les combiner afin d\u2019optimiser ces quelques mesures.<\/p>\n
Une m\u00e9trique n\u2019est qu\u2019un nombre. C\u2019est l\u2019utilisation que nous en faisons qui lui donne toute sa valeur pour r\u00e9pondre \u00e1 une question donn\u00e9e : quels co\u00fbts \/ quels risques ?<\/p>\n","protected":false},"excerpt":{"rendered":"
Back to raw metrics – Retour vers les m\u00e9triques \u00e9l\u00e9mentaires. Un client vous confie un audit de la qualit\u00e9 d\u2019une application ou d\u2019un portefeuille d\u2019applications. Il en attend une r\u00e9ponse \u00e1 une question bien pr\u00e9cise. Par exemple : Cette application repr\u00e9sente une part importante de mon budget : est-il possible de r\u00e9duire ses co\u00fbts et […]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-89","post","type-post","status-publish","format-standard","hentry","category-qualite-des-applications"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/89"}],"collection":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/comments?post=89"}],"version-history":[{"count":3,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/89\/revisions"}],"predecessor-version":[{"id":91,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/89\/revisions\/91"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/media?parent=89"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/categories?post=89"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/tags?post=89"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}