{"id":2066,"date":"2014-09-26T10:51:18","date_gmt":"2014-09-26T09:51:18","guid":{"rendered":"http:\/\/qualilogy.com\/fr\/?p=2066"},"modified":"2014-09-29T07:01:49","modified_gmt":"2014-09-29T06:01:49","slug":"application-legacy-refactoring-reengineering-7","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/fr\/application-legacy-refactoring-reengineering-7\/","title":{"rendered":"Application Legacy \u2013 Refactoring ou reengineering? (VII)"},"content":{"rendered":"<p><a href=\"http:\/\/500px.com\/Vicken\" target=\"_blank\"><img loading=\"lazy\" decoding=\"async\" class=\"alignleft size-full wp-image-2067\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/09\/Qualilogy_Legacy_ActionPlan1.jpg\" alt=\"Qualilogy Legacy Application Refactoring Reengineering\" width=\"320\" height=\"320\" srcset=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/09\/Qualilogy_Legacy_ActionPlan1.jpg 320w, http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/09\/Qualilogy_Legacy_ActionPlan1-150x150.jpg 150w, http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/09\/Qualilogy_Legacy_ActionPlan1-300x300.jpg 300w\" sizes=\"(max-width: 320px) 100vw, 320px\" \/><\/a>Nous avons montr\u00e9 dans <a title=\"Application Legacy \u2013 Refactoring ou reengineering? (VI)\" href=\"http:\/\/qualilogy.com\/fr\/application-legacy-refactoring-reengineering-6\/\" target=\"_blank\">le post pr\u00e9c\u00e9dent<\/a> comment utiliser le dashboard SonarQube afin d\u2019estimer l\u2019effort de tests de caract\u00e9risation, tests pr\u00e9conis\u00e9s par Michael Feathers dans son livre \u2018Working Effectively with Legacy Code\u2019.<\/p>\n<p>Nous avons cat\u00e9goris\u00e9 les diff\u00e9rents composants de notre application Legacy (Microsoft Word 1.1a) en diff\u00e9rents groupes, des fonctions les plus simples avec une Complexit\u00e9 Cyclomatique (CC) inf\u00e9rieure \u00e0 20 points, aux fonctions complexes \u00e0 tr\u00e8s complexes, jusqu\u2019\u00e0 200 points de CC, et finalement 6 composants \u2018monstres\u2019.<\/p>\n<p>Nous avons construit une formule bas\u00e9e sur la Complexit\u00e9 Cyclomatique et un facteur de lisibilit\u00e9 afin d\u2019\u00e9valuer l\u2019effort de test sur chacun de ces groupes. <!--more--><\/p>\n<h2>Appr\u00e9ciation des r\u00e9sultats<\/h2>\n<p>Nous avons obtenu un r\u00e9sultat total de 234 jours, qui se r\u00e9partissent de la fa\u00e7on suivante :<\/p>\n<p style=\"text-align: center\"><strong><em>Tableau 1 \u2013 Distribution de l&rsquo;effort de tests par cat\u00e9gorie de composants\u00a0<\/em><\/strong><br \/>\n<a href=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/09\/Qualilogy-Legacy-TestEffort-Synthesis2.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-2090\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/09\/Qualilogy-Legacy-TestEffort-Synthesis2.jpg\" alt=\"Qualilogy-Legacy-TestEffort-Synthesis\" width=\"482\" height=\"179\" srcset=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/09\/Qualilogy-Legacy-TestEffort-Synthesis2.jpg 482w, http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/09\/Qualilogy-Legacy-TestEffort-Synthesis2-300x111.jpg 300w\" sizes=\"(max-width: 482px) 100vw, 482px\" \/><\/a><\/p>\n<ul>\n<li>\u00a093.5 jours pour une couverture de 60% des fonctions avec une CC inf\u00e9rieure \u00e0 20 points, repr\u00e9sentant 40% de l\u2019effort total et 44% de la Complexit\u00e9 Cyclomatique totale de l\u2019application.<\/li>\n<li>92 jours (39% du temps total) pour les 503 fonctions entre 20 et 100 points de CC, repr\u00e9sentant 44% de la CC totale.<\/li>\n<li>25 j (11% du temps total) pour les 30 fonctions entre 100 et 200 points de CC, repr\u00e9sentant 9% de la CC totale.<\/li>\n<li>23.5 j ou 10% de l\u2019effort total pour les 6 fonctions les plus complexes, repr\u00e9sentant 3% de la CC de l\u2019ensemble de l\u2019application.<\/li>\n<\/ul>\n<p>Cet effort nous permet une couverture de tests de 65.5% des fonctions, soit les 2\/3 de notre application.<\/p>\n<p>J\u2019avais pass\u00e9 pas mal de temps sur la formule de calcul de l\u2019effort de test, de mani\u00e8re \u00e0 obtenir une r\u00e8gle d\u2019\u00e9valuation qui soit logique, coh\u00e9rente, et donc compr\u00e9hensible, en se basant sur le nombre de chemins logiques dans une fonction, repr\u00e9sent\u00e9 par la Complexit\u00e9 Cyclomatique, ainsi que la plus ou moins grande facilit\u00e9 de lecture. C\u2019est ainsi que proc\u00e9derait un d\u00e9veloppeur auquel on demanderait d\u2019estimer le nombre de jours qui lui serait n\u00e9cessaire pour d\u00e9velopper des tests unitaires sur un code qu\u2019il ne conna\u00eet pas.<\/p>\n<p>Je voulais \u00e9galement que la r\u00e8gle soit pr\u00e9cise (tout en restant simple), de mani\u00e8re \u00e0 pouvoir moduler la formule en fonction de la taille et la complexit\u00e9 des composants. J\u2019ai jou\u00e9 un peu avec les diff\u00e9rents <a title=\"Application Legacy \u2013 Refactoring ou reengineering? (VI)\" href=\"http:\/\/qualilogy.com\/fr\/application-legacy-refactoring-reengineering-6\/\" target=\"_blank\">param\u00e8tres &lsquo;Readibility Factor%&rsquo; et &lsquo;Characterization Test time&rsquo;<\/a> afin de parvenir \u00e0 un r\u00e9sultat unitaire pour chaque cat\u00e9gorie de composants qui me paraisse satisfaisant : 54 minutes d\u2019\u00e9criture de tests pour une fonction entre 12 et 20 points de CC, 120 minutes pour une fonction entre 40 et 50 points de CC et 200 \u00e0 300 lignes de code, 240 minutes (soit une demi-journ\u00e9e) pour une fonction entre 60 et 70 points de CC et entre 500 et 700 lignes de code, etc.<\/p>\n<p>Une fois les diff\u00e9rents tableaux r\u00e9alis\u00e9s avec cette formule, ma premi\u00e8re r\u00e9action au vu des r\u00e9sultats finals, a \u00e9t\u00e9 de trouver ceux-ci assez r\u00e9alistes. 234 jours, pour une couverture de tests des 2\/3 des 3 936 fonctions r\u00e9partis dans 349 programmes C : cela ne me para\u00eet pas invraisemblable.<br \/>\nJe pense m\u00eame que ce n\u2019est pas sous-\u00e9valu\u00e9, si on consid\u00e8re que les temps de r\u00e9alisation de tests sur les composants les plus simples (&lt; 20 CC) \u00e0 moyennement complexe (20 &lt; CC &lt; 50) sont, je pense, estim\u00e9s assez g\u00e9n\u00e9reusement. Au-del\u00e0, pour les composants les plus lourds, j\u2019ai du mal \u00e0 me faire une id\u00e9e tr\u00e8s pr\u00e9cise de la justesse de notre \u00e9valuation. Mais 3 jours pour une fonction tr\u00e8s complexe avec environ 200 points de CC et 750 lignes de code ne me paraissent pas non plus incoh\u00e9rents.<\/p>\n<p>La r\u00e9partition de l\u2019effort de test me semble \u00e9galement int\u00e9ressante :<\/p>\n<ul>\n<li>Deux chiffres tr\u00e8s proches d\u2019environ 90 jours pour chacune des deux premi\u00e8res cat\u00e9gories, avec environ 19 000 points de CC pour chaque cat\u00e9gorie, sur 3 400 composants simples et \u00e9galement pour 500 composants complexes.<\/li>\n<li>Deux chiffres proches \u00e0 nouveau, de 25 jours pour 30 composants tr\u00e8s complexes et 23 jours pour 6 \u2018monster components\u2019.<\/li>\n<\/ul>\n<p>Quand je dis que ces r\u00e9sultats me paraissent r\u00e9alistes, je ne veux pas dire qu\u2019ils sont d\u2019une pr\u00e9cision absolue et d\u2019une fiabilit\u00e9 et \u00e0 toute \u00e9preuve, sinon qu\u2019ils peuvent supporter quelques objections.<\/p>\n<h2>Objections<\/h2>\n<p>J\u2019avais termin\u00e9 le post pr\u00e9c\u00e9dent en demandant si cette estimation semblait correcte et les r\u00e9actions ont \u00e9t\u00e9 plut\u00f4t positives. On m\u2019a dit que c\u2019\u00e9tait \u2018Ok\u2019, et que la \u2018scalability\u2019, c\u2019est-\u00e0-dire la variation d\u2019\u00e9chelle entre les diff\u00e9rentes cat\u00e9gories, croissante en fonction de la CC, semblait assez juste.<br \/>\nN\u00e9anmoins, en tant que consultant, je dois me pr\u00e9parer \u00e0 toute objection lors de la pr\u00e9sentation de ces r\u00e9sultats \u00e0 un client. Quelles pourraient \u00eatre celles-ci ?<\/p>\n<p style=\"padding-left: 30px\"><em>Un responsable fonctionnel ou utilisateurs de l\u2019application (stakeholder) : \u00ab\u00a0 Je ne comprends pas : vous dites qu\u2019il faut 4 minutes par point de complexit\u00e9 pour les composants les plus simples et 2 minutes par point de complexit\u00e9 pour les composants les plus complexes. Est-ce que ce ne devrait pas \u00eatre l\u2019inverse ? \u00bb<\/em>.<\/p>\n<p>En fait, l\u2019\u00e9criture d\u2019un test va n\u00e9cessiter le d\u00e9veloppement d\u2019une fonction sp\u00e9cifique \u00e0 ce test, afin de v\u00e9rifier une ou plusieurs valeur(s) pour chaque chemin logique et donc chaque point de complexit\u00e9. Si je n\u2019ai qu\u2019un unique point de CC, je vais passer moins de temps \u00e0 \u00e9crire une ligne de test et proportionnellement plus de temps \u00e0 d\u00e9velopper la fonction, \u00e0 la compiler, \u00e0 l\u2019ex\u00e9cuter, \u00e0 v\u00e9rifier le r\u00e9sultat du test, \u00e9ventuellement \u00e0 modifier la fonction et la tester \u00e0 nouveau. Si j\u2019ai plusieurs points de CC, je vais passer un peu plus de temps pour tester diff\u00e9rentes valeurs et proportionnellement moins de temps dans l\u2019\u00e9criture et l\u2019ex\u00e9cution de la fonction.<\/p>\n<p>D\u2019ailleurs, on ne constate pas vraiment de gap lorsque l\u2019on passe d\u2019une fonction simple entre 12 et 20 points de CC et 54 minutes de temps de r\u00e9alisation des tests, \u00e0 une fonction moyennement complexe entre 20 et 30 points de CC, et 50 \u00e0 60 minutes de tests (en fonction de taille de la fonction, en lignes de code).<\/p>\n<p style=\"padding-left: 30px\"><em>Un membre de l\u2019\u00e9quipe de projet : \u00ab Votre formule me para\u00eet correcte, mais je pense que le Readibility Factor n\u2019est pas assez progressif. D\u2019ailleurs, vous passez brusquement le RF% de 4 \u00e0 10 pour les fonctions extr\u00eamement complexes \u00bb.<\/em><\/p>\n<p>Je suis d\u2019accord. Afin de disposer \u00e9galement d\u2019une seconde hypoth\u00e8se, d\u2019une fourchette haute pour notre \u00e9valuation, j\u2019ai rehauss\u00e9 ce facteur de la mani\u00e8re suivante :<\/p>\n<ul>\n<li>Pour les fonctions inf\u00e9rieures \u00e0 100 lignes de code (LOC), je laisse le RF% = 1.<\/li>\n<li>De 100 \u00e0 200 LOC, le RF% passe de 1.5 \u00e0 2.<\/li>\n<li>De 200 \u00e0 300 LOC, le RF% passe de 2 \u00e0 3.<\/li>\n<li>De 300 \u00e0 500 LOC, le RF% passe de 2.5 \u00e0 4.<\/li>\n<li>De 500 \u00e0 700 LOC, le RF% passe de 4 \u00e0 6.<\/li>\n<li>Au-del\u00e0 de 700 LOC, j\u2019ai conserv\u00e9 les param\u00e8tres actuels.<\/li>\n<\/ul>\n<p>Voici le nouveau tableau obtenu avec ces param\u00e8tres :<\/p>\n<p style=\"text-align: center\"><em><strong>Tableau 2 \u2013 Calcul de l\u2019effort de test sur les fonctions tr\u00e8s complexes (hypoth\u00e8se haute) <\/strong><\/em><\/p>\n<p><a href=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/09\/Qualilogy-Legacy-TestEffort-CCSup20_NweRF.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-2080\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/09\/Qualilogy-Legacy-TestEffort-CCSup20_NweRF.jpg\" alt=\"Qualilogy-Legacy-TestEffort-CCSup20_NewRF\" width=\"671\" height=\"555\" srcset=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/09\/Qualilogy-Legacy-TestEffort-CCSup20_NweRF.jpg 671w, http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/09\/Qualilogy-Legacy-TestEffort-CCSup20_NweRF-300x248.jpg 300w, http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/09\/Qualilogy-Legacy-TestEffort-CCSup20_NweRF-624x516.jpg 624w\" sizes=\"(max-width: 671px) 100vw, 671px\" \/><\/a><br \/>\nNous passons de 117.2 jours \u00e0 131.8 jours, soit une augmentation de 14.6 jours, ou encore un effort suppl\u00e9mentaire d\u2019environ 12% de la charge initiale. Donc l\u2019impact de cette modification est relativement mod\u00e9r\u00e9. On constate d\u2019ailleurs qu\u2019il est plus important sur les composants de taille plus \u00e9lev\u00e9e (c\u2019est logique), mais qui ne sont pas les plus nombreux. Par exemple, on passe de 4 heures \u00e0 5 heures pour un composant de 60 \u00e0 70 points de CC avec plus de 500 LOC, mais comme nous n\u2019en avons qu\u2019un seul dans l\u2019application \u2026<\/p>\n<p style=\"padding-left: 30px\"><em>Le CIO : \u00ab Quelle fiabilit\u00e9 accordez-vous \u00e0 vos r\u00e9sultats ? Dans quelle mesure puis-je me baser sur ces chiffres afin de d\u00e9cider de lancer un outsourcing pour cette application ? \u00bb.<\/em><\/p>\n<p>Je vais pr\u00e9ciser cela en vous pr\u00e9sentant le plan d\u2019actions.<\/p>\n<h2>Plan d\u2019actions<\/h2>\n<p>Nous avons un total de 234 jours pour cette op\u00e9ration de transfert de connaissances, ou 248.8 jours si on modifie le param\u00e8tre RF% comme pr\u00e9c\u00e9demment, ce qui repr\u00e9sente entre 11.7 et 12.5 mois \/ personne sur la base de 20 jours par mois. Nous allons baser notre plan d\u2019actions sur ces deux hypoth\u00e8ses, la premi\u00e8re \u2018hypoth\u00e8se moyenne\u2019, la seconde \u2018hypoth\u00e8se haute\u2019.<\/p>\n<p>En fait, il ne faut pas compter 20 jours par mois, car cela suppose que personne ne s\u2019absente ou ne prenne de cong\u00e9s. On consid\u00e8re (en France) qu\u2019une personne b\u00e9n\u00e9ficie de 5 semaines de cong\u00e9s et 2 semaines de jours f\u00e9ri\u00e9s. Ceci nous donne donc un total de :<\/p>\n<p style=\"text-align: center\"><em>52 semaines par an &#8211; 7 semaines d\u2019absence = 45 semaines travaill\u00e9es.<\/em><br \/>\n<em>45 semaines x 5 jours par semaine = 225 jours de travail par an. <\/em><br \/>\n<em>225 jours travaill\u00e9s \/ 12 mois = 18.5 jours travaill\u00e9s par mois.<\/em><\/p>\n<p>Notre charge totale de projet est de 234 jours (hypoth\u00e8se 1) ou 248.8 jours (hypoth\u00e8se 2) ce qui repr\u00e9sente respectivement 2.5 ou 2.65 mois \/ hommes pour une \u00e9quipe de 5 personnes et 18.5 jours de travail par mois.<br \/>\n5 personnes me paraissent une \u00e9quipe de taille correcte pour reprendre cette application et en assurer la maintenance future : je doute que l\u2019\u00e9quipe originale de Microsoft ait \u00e9t\u00e9 moins nombreuse. Sur la base de cette \u00e9quipe, notre projet de transfert de connaissances serait inf\u00e9rieur \u00e0 3 mois.<\/p>\n<p>Or 3 mois est la dur\u00e9e syst\u00e9matiquement utilis\u00e9e pour une phase de \u2018knowledge transfer\u2019, dans toute r\u00e9ponse \u00e0 un appel d\u2019offres ou RFP. En dessous de 3 mois, ce n\u2019est pas cr\u00e9dible : il faudrait un nombre de personnes plus important pour assurer ce transfert que le nombre de personnes n\u00e9cessaire lors des phases suivantes de maintenance correcte et \u00e9volutive. Ce qui voudrait dire, soit ne pas compl\u00e9ter correctement cette phase de transfert, et donc compromettre \u00e9norm\u00e9ment la prestation d\u2019outsourcing, soit\u00a0 former des personnes sur une application qu\u2019ils abandonneront ensuite. Dangereux et stupide dans les deux cas.<br \/>\nAu-del\u00e0 de 3 mois, vous prenez le risque d\u2019alourdir la charge et donc le co\u00fbt du projet au-del\u00e0 de ce que proposeront vos concurrents, et par cons\u00e9quence de perdre le contrat. Donc tout le monde va proposer un d\u00e9lai de 3 mois, et ce d\u00e9lai est tout \u00e0 fait acceptable pour un CIO.<\/p>\n<p>Nous allons ainsi baser notre plan d\u2019action sur un planning de 3 mois, avec une charge de 2.5 (ou 2.65 mois \/homme) pour une \u00e9quipe de 5 personnes. Ceci nous donne une marge de 20% (3 \u2013 2.5 = 0.5 = 20% de 2.5) ou 13% (pour une charge de 2.65 mois \/ hommes).<\/p>\n<p>Le tableau suivant synth\u00e9tise ces r\u00e9sultats :<\/p>\n<p><a href=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/09\/Qualilogy_Legacy_ActionPlanTable.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-2082\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/09\/Qualilogy_Legacy_ActionPlanTable.jpg\" alt=\"Qualilogy_Legacy_ActionPlanTable\" width=\"371\" height=\"162\" srcset=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/09\/Qualilogy_Legacy_ActionPlanTable.jpg 371w, http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/09\/Qualilogy_Legacy_ActionPlanTable-300x130.jpg 300w\" sizes=\"(max-width: 371px) 100vw, 371px\" \/><\/a><\/p>\n<p>On \u00e9value g\u00e9n\u00e9ralement la charge de gestion du projet \u00e0 20% du total projet, mais je pense que sur une phase de transfert de connaissances, le besoin de gestion de projet sera inf\u00e9rieur. Dans tous les cas, nous devrions b\u00e9n\u00e9ficier d\u2019un peu de marge de man\u0153uvre, si nous partons sur un planning de 3 mois.<\/p>\n<p>Donc je ferai les propositions suivantes :<\/p>\n<h3>Commencer par les fonctions les plus complexes<\/h3>\n<p>Les 30 fonctions tr\u00e8s complexes n\u00e9cessitent 25.1 jours dans notre hypoth\u00e8se 1, ou 26.9 dans notre hypoth\u00e8se 2. Les 6 fonctions \u2018monster\u2019 n\u00e9cessitent 23.5 j. Au total, je vais arrondir \u00e0 50 jours de charge, soit 10 jours \/ homme pour une \u00e9quipe de 5 personnes.<\/p>\n<p>Notre conseil est d\u2019utiliser les deux premi\u00e8res semaines du planning afin d\u2019\u00e9crire les tests et de documenter les fonctions les plus complexes, avec des points d\u2019avancement r\u00e9guliers (au moins 2 par semaine) afin de v\u00e9rifier si cette premi\u00e8re partie du planning peut \u00eatre tenue, normalement en 2 semaines. Si c\u2019est le cas, nous pouvons \u00eatre confiants pour la suite de notre projet de transfert de connaissances et d\u2019\u00e9criture de tests.<\/p>\n<h3>Partager les t\u00e2ches entre les deux \u00e9quipes<\/h3>\n<p>Une autre recommandation que j\u2019aimerais sugg\u00e9rer pour cette premi\u00e8re phase : diviser le travail de d\u00e9veloppement de tests sur ces composants les plus complexes entre les deux \u00e9quipes, l\u2019actuelle qui conna\u00eet d\u00e9j\u00e0 le code, et la seconde vers laquelle doit s\u2019effectuer le transfert de connaissance. Nous pouvons travailler de deux mani\u00e8res :<\/p>\n<ul>\n<li>D\u00e9veloppement conjoint : un d\u00e9veloppeur de la nouvelle \u00e9quipe \u00e9crit les tests avec l\u2019aide d\u2019un d\u00e9veloppeur de l\u2019actuelle \u00e9quipe.<\/li>\n<li>D\u00e9veloppement s\u00e9par\u00e9 avec partage de connaissances : chaque d\u00e9veloppeur programme chacun de son c\u00f4t\u00e9 des tests sur les fonctions les plus complexes (pas les m\u00eames en m\u00eame temps, \u00e9videmment). Les deux se retrouvent en fin de journ\u00e9e afin de pr\u00e9senter leur travail, le commenter, l\u2019expliquer et ainsi faciliter le transfert de connaissances vers le d\u00e9veloppeur de la nouvelle \u00e9quipe.<\/li>\n<\/ul>\n<p>La premi\u00e8re option est probablement celle qui permettra une qualit\u00e9 optimale de notre couverture de tests, puisque nous allions les b\u00e9n\u00e9fices de la d\u00e9couverte et de la compr\u00e9hension du code par un d\u00e9veloppeur de la nouvelle \u00e9quipe, avec l\u2019aide d\u2019un d\u00e9veloppeur qui conna\u00eet d\u00e9j\u00e0 ce code. L\u2019inconv\u00e9nient est qu\u2019elle n\u00e9cessite des ressources additionnelles de la part de l\u2019\u00e9quipe actuelle, non directement productives comme dans la seconde option.<\/p>\n<p>Je dois dire que j\u2019ai une pr\u00e9f\u00e9rence pour cette seconde option, qui me para\u00eet pr\u00e9senter plus d\u2019avantages. Le d\u00e9veloppeur de la nouvelle \u00e9quipe effectue des tests de caract\u00e9risation qui lui permettent de d\u00e9couvrir et comprendre le comportement de l\u2019application. En parall\u00e8le, un d\u00e9veloppeur de l\u2019\u00e9quipe actuelle \u00e9crit des tests unitaires sur un code qu\u2019il conna\u00eet, avant de passer celui-ci au d\u00e9veloppeur de la nouvelle \u00e9quipe. Il est important cependant de r\u00e9server du temps afin que chacun partage son travail et que le d\u00e9veloppeur de l\u2019\u00e9quipe actuelle, soit v\u00e9rifie et compl\u00e8te le travail du d\u00e9veloppeur de la nouvelle \u00e9quipe, soit lui explique les tests qu\u2019il a lui-m\u00eame d\u00e9velopp\u00e9s. Ce temps de partage doit \u00e9galement permettre de documenter les tests r\u00e9alis\u00e9s. Je pense qu\u2019une heure par jour de travail en commun, au d\u00e9but, devrait permettre ce partage de connaissances. Il faudra probablement passer \u00e0 2 heures par jour assez rapidement toutefois.<\/p>\n<p>Dans les deux cas, cette r\u00e9partition des t\u00e2ches doit permettre :<\/p>\n<ul>\n<li>D\u2019assurer le transfert de connaissance et la qualit\u00e9 des tests sur les fonctions les plus complexes.<\/li>\n<li>Un meilleur suivi sur cette phase de projet, probablement la plus d\u00e9licate pour l\u2019avenir.<\/li>\n<li>D\u2019assurer le planning et d\u2019\u00e9viter tout d\u00e9rapage au d\u00e9but du projet, en b\u00e9n\u00e9ficiant de la connaissance du code de l\u2019\u00e9quipe actuelle.<\/li>\n<\/ul>\n<h3>Moduler les ressources de mani\u00e8re la plus efficace<\/h3>\n<p>Dans les deux cas, nous aurons besoin de ressources de la part de l\u2019\u00e9quipe actuelle, mais encore une fois, sur une p\u00e9riode relativement courte de deux semaines environ. Il est cependant possible de moduler, plus facilement d\u2019ailleurs dans notre seconde option, en employant moins de d\u00e9veloppeurs de l\u2019\u00e9quipe actuelle. Nous pouvons m\u00eame mixer les deux options : par exemple, d\u00e9veloppement conjoint pour les 6 fonctions \u2018monstres\u2019 et d\u00e9veloppement s\u00e9par\u00e9 pour les 33 autres fonctions tr\u00e8s complexes.<\/p>\n<p>Je pense que c\u2019est le type de recommandation que nous pouvons proposer en comit\u00e9 de projet, et voir ce qu\u2019en pensent les diff\u00e9rents participants. Entre d\u00e9veloppement partag\u00e9 ou s\u00e9par\u00e9, avec plus ou moins de ressources diff\u00e9rentes. En fait, toutes les variantes possibles sont imaginables.<br \/>\nPar exemple : 2 d\u00e9veloppeurs de l\u2019\u00e9quipe actuelle et 3 d\u00e9veloppeurs de la nouvelle \u00e9quipe, pour un total de 5 personnes, se partagent le travail d\u2019\u00e9criture de tests sur ces composants les plus complexes. Pendant le m\u00eame temps, les 2 autres d\u00e9veloppeurs de la nouvelle \u00e9quipe commencent \u00e0 travailler sur les composants \u2018moins\u2019 complexes. Ceci permettrait :<\/p>\n<ul>\n<li>D\u2019assurer le planning sur la caract\u00e9risation des composants les plus complexes, avec 2 personnes qui en ont la connaissance \u2026<\/li>\n<li>\u00a0\u2026 tout en acqu\u00e9rant un premier aper\u00e7u du travail d\u2019\u00e9criture de tests sur les composants entre 20 et 200 points de CC, pour une meilleure visibilit\u00e9 sur l\u2019ensemble de l\u2019application et donc du projet.<\/li>\n<\/ul>\n<p>En fonction des diff\u00e9rents choix, il faudra \u00e9videmment calculer la charge additionnelle pour l\u2019\u00e9quipe actuelle et le planning.<\/p>\n<h3>Modifier la couverture de tests<\/h3>\n<p>Je pense que d\u00e9buter par les composants les plus complexes, en visant une couverture compl\u00e8te de ces composants \u00e9gale \u00e0 100% de leur Complexit\u00e9 Cyclomatique devrait permettre d\u2019assurer le transfert de connaissances sur la partie la plus difficile, la plus lourde et la plus complexe de l\u2019application, et donc du projet. Ensuite, nous pouvons passer aux 503 fonctions de \u2013 relativement \u2013 moindre complexit\u00e9.<\/p>\n<p>Que se passe-t-il cependant si nous prenons du retard ? Si nous souhaitons respecter le planning de 3 mois que nous nous sommes assign\u00e9s, il nous faudra diminuer la charge de travail et donc la couverture de tests.<\/p>\n<p>Nous avons \u00e9valu\u00e9 celle-ci \u00e0 66% de la Complexit\u00e9 Cyclomatique de l\u2019application, 100% pour les composants de plus de 20 CC et 60% pour les autres. Nous avons dit dans notre post pr\u00e9c\u00e9dent que l\u2019effort de test correspondait (plus ou moins) \u00e0 une loi de Pareto, et qu\u2019il fallait \u00e0 peu pr\u00e9s autant de temps pour d\u00e9velopper 70% ou 80% des tests pour un composant que pour les 20% ou 30% restants. C\u2019est \u00e0 relativiser, mais une diminution mineure de notre couverture de tests devrait nous permettre de diminuer la charge travail de mani\u00e8re proportionnellement plus importante.<\/p>\n<p>Par exemple, si au lieu de 100% de couverture des composants entre 20 et 200 points de CC, nous planifions une couverture moindre de 80%, notre charge de travail \u00e9volue de la mani\u00e8re suivante :<\/p>\n<ul>\n<li>93.7 jours au lieu de 117.2 jours dans notre hypoth\u00e8se 1, soit 23.5 jours, soit un gain de 20% de la charge initiale.<\/li>\n<li>105.4 jours au lieu de 131.8 jours dans notre hypoth\u00e8se 2, soit 26.4 jours pour un gain encore une fois de 20%.<\/li>\n<\/ul>\n<p>En fait, on peut moduler l\u00e0 encore de diff\u00e9rentes mani\u00e8res. Par exemple, 80% de couverture pour les composants de moins de 50 points de CC et 100% pour ceux entre 50 et 200 points de CC nous donnent les r\u00e9sultats suivants :<\/p>\n<ul>\n<li>105 jours au lieu de 117.2 jours dans notre hypoth\u00e8se 1, soit un gain de 12.2 jours, environ 10% de la charge initiale.<\/li>\n<li>118.7 jours au lieu de 131.8 jours dans notre hypoth\u00e8se 2, soit 13.1 jours pour environ 10% de gain.<\/li>\n<\/ul>\n<p>On voit donc qu\u2019en fonction d\u2019un retard \u00e9ventuel, il est possible de r\u00e9duire celui-ci en gagnant des jours contre une r\u00e9duction minimale de la couverture de tests, et donc de la qualit\u00e9 du transfert de connaissances.<\/p>\n<h2>Synth\u00e8se<\/h2>\n<p>Une des <a title=\"Application Legacy en C \u2013 Refactoring ou r\u00e9ing\u00e9nierie ? (I)\" href=\"http:\/\/qualilogy.com\/fr\/application-legacy-c-refactoring-reingenierie-1\/\" target=\"_blank\">missions qui nous est assign\u00e9e<\/a> consiste \u00e0 calculer le co\u00fbt de transfert de connaissance de cette application vers une autre \u00e9quipe et proposer une strat\u00e9gie pour un tel projet.<\/p>\n<p>Nous nous sommes appuy\u00e9s sur la notion de tests de caract\u00e9risation de Michael Feathers, avec le double avantage de disposer d\u2019une couverture de tests pour notre application Legacy et d\u2019en assurer le transfert de connaissances.<\/p>\n<p>Nous avons construit une formule bas\u00e9e sur la Complexit\u00e9 Cyclomatique ainsi qu\u2019un facteur de lisibilit\u00e9, en tentant de trouver le bon compromis entre simplicit\u00e9 et pr\u00e9cision. Nous avons examin\u00e9 les objections possibles quant aux r\u00e9sultats obtenus avec cette formule.<\/p>\n<p>Enfin, nous avons b\u00e2ti un plan d\u2019actions, avec diff\u00e9rentes propositions qui permettent de convaincre (ou de rassurer) un CIO de la fiabilit\u00e9 de notre analyse et de la faisabilit\u00e9 de notre projet.<\/p>\n<p>Dans notre prochain post, nous travaillerons notre deuxi\u00e8me sc\u00e9nario : le refactoring de notre application Legacy, avec l\u2019aide du plugin Sqale de SonarQube.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Nous avons montr\u00e9 dans le post pr\u00e9c\u00e9dent comment utiliser le dashboard SonarQube afin d\u2019estimer l\u2019effort de tests de caract\u00e9risation, tests pr\u00e9conis\u00e9s par Michael Feathers dans son livre \u2018Working Effectively with Legacy Code\u2019. Nous avons cat\u00e9goris\u00e9 les diff\u00e9rents composants de notre application Legacy (Microsoft Word 1.1a) en diff\u00e9rents groupes, des fonctions les plus simples avec une [&hellip;]<\/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-2066","post","type-post","status-publish","format-standard","hentry","category-qualite-des-applications"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/2066"}],"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=2066"}],"version-history":[{"count":17,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/2066\/revisions"}],"predecessor-version":[{"id":2091,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/2066\/revisions\/2091"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/media?parent=2066"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/categories?post=2066"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/tags?post=2066"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}