Dette technique - exposée

Le sens et l’origine de la « dette technique »

La métaphore de la dette technique (TD) dans le contexte des logiciels a été inventée par Ward Cunningham qui travaillait à l'époque au codage d'un système financier. Il a utilisé la métaphore pour expliquer à ses collègues financiers le raisonnement pour refactoriser et réécrire des parties de codes à mesure que la connaissance des exigences évoluait.

« Lorsqu'elle prend des raccourcis et livre du code qui n'est pas tout à fait adapté à la tâche de programmation du moment, une équipe de développement encourt du TD. Cette dette diminue la productivité. Cette perte de productivité est dans l’intérêt du TD.»

L’explication initialement prévue par Ward était assez étroite et spécifique, mais la métaphore a désormais pris sa propre vie :

De nos jours, la dette technique signifie plusieurs choses :

• Code qui doit être modifié pour éliminer les raccourcis problématiques, qui ont été créés avant notre compréhension évoluée de ce qui est nécessaire. (sens originel).
• Code bogué.
• Défauts d'architecture et de conception qui étaient des raccourcis créés par des décisions tactiques
• Code difficile à maintenir
• Code qui dépend de bibliothèques, de systèmes d'exploitation ou d'autres composants techniques obsolètes
• Défauts dans les exigences qui ont été créés parce que des raccourcis ont été pris pour comprendre les exigences.

La distinction entre dette technologique, héritage et obsolescence logicielle :

Systèmes hérités

TD concerne généralement des raccourcis techniques qui ont été pris et qui posent des problèmes. Les applications logicielles et les composants vieillissants qui reposent sur une technologie que l'on ne choisirait pas aujourd'hui sont souvent classés comme systèmes existants. Au moment de leur construction, aucun raccourci n’avait peut-être été pris, il n’y aurait donc pas de dette technologique. Souvent, les gens classent à tort un système existant comme une dette technologique, alors qu’en réalité il pourrait être sur le point d’être obsolète. Si un système existant dispose d'interfaces appropriées avec d'autres systèmes et qu'il remplit parfaitement son rôle principal, il peut être hérité, mais il ne peut être ni TD ni obsolète. Lorsqu'un système ne sert plus l'entreprise, même si cela a duré un certain temps, nous considérons qu'il s'agit d'un problème. obsolète système, pas nécessairement TD.

Obsolescence des logiciels

La valeur d’un logiciel pour une organisation diminuera avec le temps. Après des années d’utilisation, la rentabilité du maintien de l’ancien système risque de diminuer. L’application a une durée de vie et il est finalement plus économique de la retirer ou de la remplacer que de la maintenir en activité. Un logiciel devient obsolète soit lorsque l'environnement d'exploitation qu'il doit exécuter n'est plus pris en charge (matériel, système d'exploitation, bibliothèques), soit lorsque le logiciel lui-même ne répond plus à l'objectif pour lequel il est nécessaire.

Une fois qu'un nouveau logiciel est écrit et déployé, il est prudent pour les dirigeants de planifier quelques années de mises à niveau et de planifier son éventuel retrait/remplacement. La durée de vie économique d’un logiciel varie. Certains types de logiciels deviennent obsolètes après quelques années seulement (de nombreux logiciels grand public), tandis que d'autres ne le deviennent qu'après des décennies (par exemple les systèmes bancaires COBOL ou les systèmes d'enregistrement en général). L’obsolescence n’est pas la même chose que la dette technologique. Un logiciel très fiable peut devenir obsolète et pourtant ne pas avoir de TD.

Le coût de la dette technique

En poursuivant la métaphore financière, nous pouvons dire que pour certaines applications logicielles, le taux d'intérêt sur ce TD peut être très élevé, tandis que pour d'autres, il peut être inférieur. Si le coût pour l’entreprise de ne pas résoudre le problème est faible, alors le taux d’intérêt du TD est faible. Le coût global de TD varie en fonction de son impact sur les opérations et les orientations de l'entreprise. Prenons par exemple un projet où des raccourcis sont pris avec les exigences de qualité. La conséquence est que le logiciel devra être réécrit avant d’être mis en ligne. Il s’agit d’une création stupide de TD, qui pourrait probablement être évitée – et qui explique en grande partie pourquoi certains projets logiciels qui négligent les exigences sont en retard ou échouent. Une approche au cas par cas est nécessaire pour l'analyse d'impact, mais une approche plus générique peut être envisagée pour le dimensionnement de la dette.

Dimensionnement COSMIC de la dette technique

Le code TDin peut être mesuré en CFP.

La manière dont le TD apparaît peut provenir de mauvaises exigences, de décisions et de raccourcis en matière d'architecture et de conception. Cela se traduit ensuite par un code qui fait la mauvaise chose ou le fait d'une manière qui entraînera une fonctionnalité inappropriée.

Quantifier la dette technique

Voici les questions que les dirigeants prudents devraient se poser :

• Quelle est la taille du TD ?
• Quel est le coût si nous ne le réparons pas ?
• Quel est le coût si nous le faisons ?

Pour les organisations qui exécutent des centaines d’applications avec des données opérationnelles et stratégiques, il est utile de normaliser la réponse à ces questions afin que les investissements destinés à répondre aux problèmes de TD puissent être priorisés.

Taille et coût de réparation

Le dimensionnement fonctionnel est une excellente approche pour standardiser le dimensionnement des TD. L'unité de mesure est le point de fonction COSMIC ou point de fonction. Par exemple, l'application a une taille totale de 1 000 CFP, dont 100 CFP sont des interfaces nécessitant une réécriture (TD). Le coût par CFP ou le coût par FP pour remplacer ou réécrire le raccourci peut généralement être déterminé facilement à l'aide de données de référence. Le coût de réparation peut être de $800 à $1500 par CFP. L'utilisation d'une approche de dimensionnement universelle signifie qu'elle peut être appliquée dans l'ensemble de TD en termes de code, de conception, d'architecture et même d'exigences. Il est très important de prendre également en compte le coût de la migration depuis l'état avant et après, ainsi que tout impact non technique, tel que les changements de personnes et de processus.

Impact sur les entreprises

Lorsque vous déterminez le coût global du TD, vous devez tenir compte à la fois du montant de son impact sur votre entreprise et du coût de sa réparation. L’approche au cas par cas de l’évaluation d’impact est appropriée. Et cela ne peut généralement être déterminé que par la collaboration des professionnels et des techniciens pour déterminer « dans quelle mesure les raccourcis techniques empêchent l'entreprise d'atteindre ses objectifs ».

Exposer la dette technique

Exposer TD est utile car cela peut aider à fournir des informations précoces pour les décisions stratégiques concernant les systèmes logiciels. Par exemple, un système chargé de TD peut être candidat à un remplacement anticipé. Alors qu’un autre logiciel dont le TD est limité peut être mieux adapté pour prolonger sa durée de vie.

Repérer la dette technique dans votre organisation

Si une application logicielle est constamment décrite comme inflexible en raison de la manière dont elle stocke/gère/structure les données, alors c'est peut-être TD qui vous retient. En d’autres termes, des raccourcis techniques ou de mauvaises décisions de conception qui n’ont jamais changé pour répondre aux besoins des entreprises.

Si un projet visant à implémenter des nouveautés ou des modifications apportées au logiciel connaît de longues périodes de correction de bogues ou de refactorisation, cela peut être dû à travail aux exigences médiocres qui a généré une dette technique.

Éviter la dette technique

C’est l’approche la plus prudente. L’idée est qu’il est moins coûteux de développer le logiciel correctement du premier coup. Cependant, compte tenu de la définition originale du terme donnée par Ward Cunningham, cela n'est pas possible. Si le besoin (stratégique) et l'utilisation du logiciel n'étaient pas connus au moment de l'écriture du code, alors certains TD étaient inévitables. Cependant, tous les efforts doivent être faits pour limiter cette refonte au strict minimum. L’approche pour y parvenir consiste à prévoir suffisamment de temps et de ressources pour effectuer le travail sur les exigences, l’architecture et la conception de manière adéquate avant le début du codage. Cela devrait exposer les inconnues connaissables afin d'éviter la création et l'élimination de TD.

Réduire la dette technique

Il existe deux approches générales pour réduire le TD :

1. Effectuez la réécriture détaillée pour éliminer le raccourci ou les défauts problématiques.

2. Évitez la dette. Effectuez un remplacement complet de TD par un code réutilisable approprié. (« Leapfrog the Legacy », l'idée de sauter l'héritage n'est pas nouvelle, même si j'ai inventé cette expression car je pense qu'elle aide les personnes non techniques à comprendre le bien-fondé de certaines décisions techniques impliquées.)