Simona Motogna 
Arthur Molnar Ne propunem o serie de trei articole în care să supunem analizei "datoria tehnică", în engleză (și termenul mult mai des întâlnit) Technical Debt (TD). TD este o metaforă care însumează diferite probleme legate de calitatea sistemului software cauzate de prioritizarea dezvoltării de noi funcționalități în detrimentul activităților de întreținere și optimizare a codului sursă. Există mai multe modele de estimare a datoriei tehnice, unele dintre ele fiind implementate în instrumente software care facilitează managementul datoriei acumulate. Începem această serie printr-o prezentare a modelelor de estimare a datoriei tehnice pe care le-am considerat mai reprezentative, abordând principalele caracteristici, diferențele semnificative între modele, pentru ca în final să propunem niște recomandări care să ajute profesioniști în alegerea modelului potrivit. Următoarele articole vor discuta despre instrumentele software, respectiv despre modalități de control și de reducere a datoriei tehnice.
Împrumutat din domeniul financiar, termenul datorie tehnică încorporează toate activitățile legate de mentenanță, performanță și eficiență amânate în favoarea implementării de noi funcționalități în sistemele software, sau în alte cuvinte, corespunde neglijării aspectelor legate de calitatea internă a software-ului. Am putea aduna o colecție de fraze care caracterizează momentele în care se generează această datorie: "las' că merge și așa", "deadline-ul e la ușă", "nu fă azi ce poți lăsa pe mâine" ... Similaritatea cu termenul financiar continuă: datoria acumulată va introduce și o dobândă, respectiv o chestiune neglijată din punctul de vedere al calității generează alte probleme care sunt rezultatul ignorării celor dinainte, situație care, folosind terminologia financiară, reprezintă o dobândă compusă. Un studiu derulat în cadrul a cinci companii mari [1] a arătat că ignorarea pe termen lung a datoriei tehnice duce la apariția unor momente de criză, în care implementarea de noi funcționalități nu mai este posibilă până la rezolvarea problemelor existente. Din cauza factorilor bine-cunoscuți în industrie, precum prezența exigențelor contractuale, a termenelor limită și a lipsei de resurse umane, refactorizarea completă, cea care, în mod ideal, elimină datoria tehnică în întregime, nu este fezabilă. Astfel, calea de urmat este cea a refactorizărilor parțiale, efectuate în absența momentelor de presiune și care scad numărul punctelor de criză ce apar pe durata de viață a proiectului.
Care sunt factorii ce contribuie la apariția și proliferarea datoriei tehnice? Mai multe studii derulate în cadrul unor companii dezvoltatoare de produse complexe au relevat aspecte comune:
Lipsa de înțelegere legată de ramificațiile dezvoltării sau refactorizării unei componente.
Dezvoltarea în paralel a mai multor produse. Aceasta poate duce la duplicarea de funcționalități și chiar la apariția unor module între produse, în cazul în care comunicarea între echipele de dezvoltare este deficitară.
Presiunea timpului și cea dată de noi cerințe ale clientului. Acestea din urmă pot interveni în cele mai multe din fazele dezvoltării produsului și pot fi dificil de controlat.
Din punct de vedere al momentului apariției, presiunea privitoare la timp tinde să apară la demararea proiectului și în anumite momente-cheie, legate de punerea în funcțiune a unei noi versiuni sau refactorizări. În schimb, lipsa de înțelegere a produsului este tipică perioadei de început, iar cea legată de dezvoltarea în paralel reprezintă un risc pe toată durata proiectului. Tratate superficial, acestea pot genera situații catastrofice (vezi Knight Capital Group).
Cu toate că în acest moment există instrumente și metode de a gestiona datoria tehnică, adoptarea lor la scară largă și folosirea lor în mod programatic este încă un deziderat. Acest lucru se justifică parțial și prin interpretările existente în diferitele modele de estimare a datoriei tehnice, conducând în consecință la estimări care nu reflectă adevăratele probleme.
Echipele de dezvoltare software și managerii de proiect ar trebui să aleagă modelul de estimare a datoriei tehnice în funcție de specificul și caracteristicile proiectului.
| Model | An | Referință | Instrumente |
|---|---|---|---|
| SQALE | 2010 | Letouzey | SonarQube, NDepend, Squore |
| CQM | 2012 | CQM | Kiuwan |
| CAST | 2012 | Curtis | CAST Software |
| SIG | 2011 | SIG | SIG method |
| Design flaw | 2012 | Marinescu | inFusion (not available) |
Tabel 1: Modele de estimare a datoriei tehnice
Tabelul 1 sintetizează cele mai cunoscute modele de estimare a TD, referința semnificativă și o selecție de instrumente software care implementează modelul respectiv.
Introdus în 2010, SQALE[2] este, probabil, cea mai folosită metodă de estimare a datoriei tehnice și, în mod cert, cea mai des implementată. Metoda aplică reguli care se adresează atât datoriei tehnice principale, cât și dobânzii acumulate. Cuprinde nouă factori și subfactori de calitate: testabilitate, fiabilitate, modificabilitate, eficiență, utilizabilitate, securitate, mentenabilitate, portabilitate și reutilizabilitate. Acești factori sunt asociați cerințelor ce se referă la codul sursă și pe baza cărora se calculează un set de indici. În pasul următor, acestor indici li se asociază costuri exprimate în unități de timp corespunzătoare activităților de remediere, care sunt ponderate în funcție de severitatea lor. Timpul calculat se referă la remedierea până la o valoare de conformitate, dar nu garantează eliminarea completă a datoriei tehnice, ci descreșterea ei până la o valoare acceptabilă.
Metoda SQALE se concretizează într-o scală de la A la E, unde A corespunde situației în care timpul acordat aspectelor legate de datoria tehnică este mai mic de 1% din timpul total estimat pentru dezvoltarea sistemului.
Modelul de verificare a calității (Checking Quality Model - CQM) a fost dezvoltat de Kiuwan[3] și pleacă de la ideea de a extrage date analitice din codul sursă referitor la factorii de calitate ai standardului ISO25010. Aceste date analitice însumează metrici calculate, verificare de reguli privitoare la metrici, și, în final, evaluarea unor indicatori pentru a furniza o estimare a TD. Modelul evaluează indicatori pentru: securitate, fiabilitate, eficiență, mentenabilitate și portabilitate.
CAST [4] (2012) propune un model pentru estimare a datoriei tehnice principale și a dobânzii generate și a fost validat prin analize științifice pe un set de date extensiv reprezentat de date provenite din aplicații enterprise de la companii din întreaga lume, pentru o perioadă de peste 5 ani. Perspectiva obținută din analiza datelor a fost apoi utilizată pentru a formula datoria tehnică sub forma unei expresii care depinde de severitate, număr de aparții, timp și cost pentru remedierea fiecărei probleme. Factorii de calitate luați în considerare sunt: performanță, robustețe, securitate, transferabilitate (echivalentă cu reutilizabilitate) și modificabilitate.
Definit ca un model empiric pentru datoria tehnică principală și dobândă, modelul SIG [5] a fost propus în 2011 de către Software Improvement Group ca alternativă la Indexul de Mentanabilitate (Maintainability Index - MI). Evaluarea datoriei tehnice începe de la metrici definite la nivelul codului sursă, precum număr de linii de cod (KLOC), complexitate ciclomatică (Cc), duplicarea codului, măsura unitate (unit size, definită ca fiind cea mai mică bucată de cod care poate fi executată și testată individual) și unit testing. Aceste metrici sunt apoi mapate la sub-caracteristicile mentenabilității (respectiv: analizabilitate, modificabilitate, stabilitate și testabilitate) cu scopul de a cuantifica datoria tehnică prin două metrici: efortul de remediere și efortul de mentenanță.
Modelul include și o metrică ROI (Return Of Investment), dar neglijează unele caracteristici importante precum securitate, performanță și fiabilitate, fiind preponderent axat pe mentenabilitate.
Punctul cheie al metodei propuse de R. Marinescu [6] în 2012 este ipoteza conform căreia defectele de proiectare sunt responsabile de introducerea datoriei tehnice. Modelul se bazează pe patru pași: (1) selectarea defectelor de proiectare relevante, (2) asocierea de reguli pentru detectarea lor, (3) evaluarea influenței fiecărei apariții de defect și (4) determinarea unui scor general.
Dizarmoniile de proiectare sunt evaluate și, în consecință, se calculează un index general de simptome de datorii (overall debt symptom index). Lucrarea inițială care propunea modelul se referea și la un instrument inFusion, care pare să nu mai fie disponibil. Modelul oferă o perspectivă unică, aceea de a considera defectele de proiectare drept cauză primordială a datoriei tehnice.
După cum sugerează și secțiunea anterioară, modelele de estimare a datoriei tehnice se pot diferenția în funcție de două criterii: factorii de calitate software , respectiv modul de calcul a datoriei tehnice. Figura 1 însumează factorii de calitate prezenți în modelele prezentate anterior, observând că mentenabilitatea este prezentă în patru din cele cinci modele, modificabilitatea, securitatea și re-utilizabilitatea fiind evaluate în trei din cinci modele.
Figura 1: Factorii de calitate din modelele considerate
Un alt aspect care diferențiază modelele este legat de definiția corespunzătoare datoriei tehnice, de regulile folosite și de nivelul codului sursă. Figura 2 descrie termenii asociați datoriei tehnice de către fiecare model, regula de calcul a TD, respectiv modul de exprimare a rezultatului, reflectând eterogenitatea abordărilor din diferite modele.
Modele prioritizează diferiți factori de calitate în estimarea TD. Ca urmare, echipele de dezvoltare ar trebui să calculeze TD în funcție de factorii esențiali proiectului lor.
Costul datoriei tehnice este calculat diferit de către fiecare model.
Figura 2: Definiții și formule folosite pentru estimarea TD în modele
Pentru fiecare model, formula este calculată pe baza unor reguli definite pentru diferite probleme apărute în codul sursă, după cum se poate observa în Tabelul 2. Modelul SQALE pare să fie cel mai comprehensiv, acoperind opt tipuri de defecte, dar ignoră cuplarea care poate genera o datorie semnificativă, respectiv volumul codului sursă considerat. Acest tabel poate ajuta membrii echipelor software să aleagă modelul sau să combine mai multe modele care acoperă aspectele legate de codul sursă, esențiale în proiectul dezvoltat.
O încercare de a propune o soluție acestei eterogenități de formule și reguli este de a lua în considerare principiile esențiale și apoi de a construi instrumente menite să colecteze datele corespunzătoare. Un consorțiu format din zece companii și instituții, incluzând OMG, SEI Carnegie Mellon și CAST au propus un standard pentru datoria tehnică[7]. Modelul consideră că datoria tehnică este generată de defecte referitoare la: securitate (22 de tipuri de defecte), fiabilitate (29), performanță și eficiență (15), respectiv mentenabilitate (20).
Comparând acest standard cu modelele analizate, putem face următoarele observații: mentanabilitatea și securitatea sunt prezente ca factori de top, iar însumarea performanței cu eficiența o promovează între primii cinci factori. Singura excepție este fiabilitatea, care este definită drept abilitatea unui sistem de a rămâne în execuție pentru o perioadă de timp, mai exact de a fi capabil să depășească defectele și de a fi capabil să se redreseze. În unele cazuri, precum sistemele în timp real și critice, acest factor de calitate este esențial.
Tabel 2: Aspectele considerate în formulele pentru estimarea datorie tehnice
Factorii esențiali care ar trebui luați în considerare pentru estimarea datoriei tehnice trebuie să includă: mentenabilitate, securitate, respectiv performanță și eficiență.
Următorul episod al explorării datoriei tehnice va analiza instrumentele care implementează aceste modele și care pot susține dezvoltarea sistemelor software.
[1] A. Martini et al., Investigating Architectural Technical Debt accumulation and refactoring over time: A multiple-case study, Inform. Softw. Technol. (2015), http://dx.doi.org/10.1016/j.infsof.2015.07.005
[2] J -l. Letouzey, "The SQALE Method for Evaluating Tech- nical Debt", Proc. of 3rd International Workshop on Managing Technical Debt, 2012, pp. 31-36
[3] Kiuwan - Models and CQM. Online: www. kiuwan.com/docs/display/K5/Models+and+CQM
[4] B. Curtis, J. Sappidi and A. Szynkarski, "Estimating the Principal of an Application's Technical Debt", IEEE Soft- ware, vol. 29, no. 6, 2020, pp. 34-42
[5] A. Nugroho, J. Visser, and T. Kuipers, "An empirical model of technical debt and interest", Proc. of the 2nd Workshop on Managing Technical Debt, 2011, pp 1-8
[6] R. Marinescu, "Assessing technical debt by identifying design flaws in software systems," IBM Journal of Re- search and Development, vol. 56, no. 5, 2012, pp. 9:1- 9:13
[7] B. Curtis - New Automated Technical Debt Standard, webinar, 2018, https://www.it- cisq.org/ cisq- webinar- new- automated- technical- debt- standard/ index.htm
de John Bax
de Dan Suciu
