Simona Motogna 
Arthur Molnar Continuăm discuția privitoare la datoria tehnică, analizând câteva dintre cele mai utilizate instrumente existente pentru estimarea datoriei. Diferențele dintre modele ( prezentate în prima parte) se reflectă și la nivelul uneltelor dezvoltate, astfel că nu putem spune că există un "câștigător". Alegerea trebuie determinată de scopul pentru care se măsoară datoria tehnică.
Ne propunem o trecere în revistă a acelor unelte care au produs un impact semnificativ în modul în care este percepută datoria tehnică, respectiv au sensibilizat comunitatea Ingineriei Software în a urmări acest indicator al calității software și a căuta soluții de îmbunătățire. În plus, dorim să reliefăm caracteristicile esențiale, împreună cu punctele tari și cele slabe ale acestor instrumente. Punctul comun de pornire este faptul că toate instrumentele detaliate efectuează analiză statică a codului sursă, adică o examinare efectuată fără a rula programul. Avantajul principal este faptul că acest lucru este posibil fără a configura un mediu de rulare și fără a avea toate dependențele software pregătite (servere de baze de date, componente mock ș.a.m.d.). Cel mai mare dezavantaj comun este legat de precizia acestor analize, care în general e invers proporțională cu dinamicitatea limbajului - relativ precis pentru limbaje statice precum Java și C, mai puțin precis în cazul JavaScript și Python.
SonarQube este probabil cel mai folosit instrument de urmărire a diferitelor aspecte legate de calitatea sistemelor software. Implementând modelul SQALE, SonarQube permite monitorizarea mentenabilității (inclusiv estimarea datoriei tehnice), a fiabilității, precum și detectarea vulnerabilităților de securitate. Fiind deja la versiunea 9.1, a devenit un instrument matur, cu multe funcționalități și posibilități de configurare. Dezvoltatorii pun la dispoziție o versiune gratuită și open-source (Community edition), dar și variante contra cost de tipul Enterprise și Data Center. Acestea din urmă furnizează facilități adiționale utile în contextul existenței unei ierarhii complexe de proiecte, rularea analizelor folosind mai multe noduri de calcul ș.a.m.d.
Modul de calcul al datoriei tehnice pornește de la un set de reguli specifice fiecărui limbaj. În momentul în care o regulă este încălcată se generează o problemă (eng. issue) care este caracterizată prin tip, severitate și efortul necesar reparării. Tipul depinde de unul dintre cele trei domenii: fiabilitate (buguri), securitate (vulnerabilități), respectiv mentenabilitate (code smells). Severitatea este atribuită în funcție de estimarea riscului asociat și este detaliată în Tabelul 1. Regulile includ și o funcție de estimare pentru timpul necesar remedierii problemei respective, fie un timp constant pentru o problemă, fie o funcție liniară. De exemplu, regula java:S3776, descrisă prin "Complexitatea cognitivă a metodelor nu ar trebui să fie prea mare" (eng. "Cognitive Complexity of methods should not be too high") generează un code smell de severitate critică cu un timp liniar de remediere constând în 5 minute/issue, la care se adaugă câte 1 minut pentru fiecare punct adițional de complexitate peste pragul maxim.
Tabel 1: Gradele de severitate asociate regulilor, conform documentației SonarQube [1]
Instrumentul este foarte prietenos în a diagnostica și ghida programatorul în remedierea problemei detectate, după cum se poate observa și în Figura 1: localizare în cod, mesaj sugestiv, posibilitatea de a oferi informații suplimentare, timp estimat de remediere, tip și severitate.
Figura 1: Identificarea și localizarea unei probleme de cod în SonarQube
Ca parte din analiză, SonarQube calculează și rația de datorie tehnică TDR = TD/DevTime, unde DevTime este timpul estimat pentru dezvoltarea sistemului, considerând 30 de minute pentru dezvoltarea unei linii de cod ce intră în producție. TDR este clasificat conform scalei SQALE între A (cel mai bun, TDR < 5%) și E (cel mai rău, TDR ≥ 50%). Astfel, un proiect clasificat ca A presupune că durata de timp necesară remedierii tuturor aspectelor semnalate este mai mic decât 5% din durata timpului total necesar dezvoltării aplicației. Un raport la nivel de proiect arată precum cel din Figura 2, reprezentând un sumar sugestiv al parametrilor calculați. Bara de butoane permite utilizatorului să intre în mai mult detaliu, atât la nivelul aspectelor de cod (dimensiune, complexitate ș.a.m.d.) precum și la nivelul pachetelor și a fișierelor sursă.
Figura 2: Raport SonarQube incluzând datoria tehnică
Puncte tari:
acoperă peste 20 dintre cele mai populare limbaje de dezvoltare software .
existența unei versiuni gratuite și open-source (community edition), pe lângă versiuni mai complexe de tipul Enterprise și Data Center.
o soluție bazată pe cloud și instrumente integrate sub formă de pluginuri în mai multe medii de dezvoltare;
Puncte slabe:
NDepend este un instrument de analiză statică specializat .NET care include și estimarea datoriei tehnice, bazat pe modelul de estimare SQALE. Fiind un instrument specific alintat "briceagul elvețian" pentru programatorii .NET, atrage după sine și existența unui set semnificativ de resurse utile (documentații, forumuri etc.). Unul dintre punctele tari este faptul că este ușor de configurat și extensibil prin interogări LINQ, pe baza unor metrici definite de utilizator sau a setului foarte exhaustiv de metrici definite de instrument. Dezavantajul principal este că deservește doar limbaje .NET și varianta gratuită este doar una pe durată limitată de 14 zile.
Estimarea datoriei tehnice și a dobânzii anuale este total transparentă și configurabilă, codul pentru acesta fiind prezentat în Figura 3. Datoria este calculată pe baza complexității ciclomatice, respectiv dobânda depinde de acoperirea codului prin teste. Chiar dacă estimarea este una simplificată, ea poate detecta cel puțin acele cazuri care sunt alarmante din punctul de vedere al complexității codului, respectiv poate fi extinsă de către utilizatori. Dobânda anuală poate fi considerată ca o măsură a severității, documentația NDepend [2] definind cinci grade: Blocker, Critical, Major, Minor, respectiv Info (de exemplu, gradul Blocker înseamnă o problemă pentru care aplicația nu poate fi lansată în execuție, trebuie în mod obligatoriu remediată iar dobânda corespunzătoare este mai mare de 10 ore-om pe an).
warnif count > 0
from m in Methods
where m.CyclomaticComplexity > 10
select new {
m,
m.CyclomaticComplexity,
Debt = (3*(m.CyclomaticComplexity -10))
.ToMinutes().ToDebt(),
AnnualInterest = (m.PercentageCover
age == 100 ? 10 : 120)
.ToMinutes().ToAnnualInterest()
}Fragment de cod C# LINQ pentru estimarea datoriei tehnice [2]
NDepend folosește aceeași scală SQALE precum SonarQube, între A și E, iar raportul generat, precum exemplul din Figura 4, cuprinde informații sumative referitoare la dimensiunea proiectului și la defectele detectate.
Figura 4: Raport NDepend incluzând datoria tehnică
Kiuwan este un instrument care implementează Modelul de Verificare al Calității (eng. CQM sau Checking Quality Model), a cărui reputație se bazează pe modul exhaustiv în care evaluează securitatea, fiind unul dintre instrumentele recomandate de OWASP . Instrumentul calculează datoria tehnică în forma "efortului către țintă" (Figura 5), și anume de a atinge valori de prag pentru factorii de calitate și nu de a elimina integral datoria tehnică. Modelul asumă anumite valori de prag pentru caracteristicile de calitate urmărite, pentru a analiza, ulterior, pentru fiecare defect prioritatea, efortul de remediere și valoarea de prag, însumând efortul total în ore/om. Această abordare este conformă cu ideile prezentate în episodul 1 al seriei noastre, în care subliniam importanța reducerii nivelului de datorie tehnică până la un prag convenabil față de încercarea eliminării complete a acesteia.
Figura 5: Exemplu de raport de analiză a codului generat de Kiuwan [3]
Instrumentul oferă rapoarte utile cu privire la aceste defecte detectate: factorul de calitate implicat, limbajul, prioritatea, respectiv număr de defecte, reguli încălcate și riscul asociat, ca în exemplul din Figura 6.
Figura 6: Exemplu de raport referitor la defecte generat de Kiuwan [3]
Chiar dacă atributele principale sunt legate de analiza securității împreună cu suport pentru peste 30 de limbaje de programare, Kiuwan aduce și alte puncte tari privind estimarea datoriei tehnice: analiza de risc, respectiv posibilitatea de a construi un plan de acțiune relativ la efortul de remediere pentru a atinge valorile prag pentru fiecare factor de calitate.
Platforma CAST Application Intelligence Platform - AIP implementează modelul de analiză CAST și este disponibil pentru peste 60 de limbaje de programare.
CAST Engineering Dashboard este produsul responsabil pentru calculul datoriei tehnice și de urmărirea evoluției sale pe parcursul duratei de viață al proiectului. După cum se observă și în exemplul din Figura 7, instrumentul returnează o paletă întreagă de caracteristici.
Modul de calcul al datoriei tehnice conform modelului CAST presupune următorii pași: (1) detectarea defectelor generate de încălcarea regulilor privitoare la securitate, performanță, robustețe, transferabilitate și modificabilitate; (2) clasificarea acestor încălcări în funcție de severitate (scăzută, medie, mare); (3) estimarea timpului și costurilor asociate acestora: indiferent de severitate, se consideră implicit un efort de remediere de o oră, respectiv un cost de 75$ pe oră; (4) datoria tehnică este suma costurilor asociate pentru 50% dintre probleme cu severitate ridicată, 25% dintre cele cu severitate medie, respectiv 10% dintre cele cu severitate scăzută.
Figura 7: Exemplu din raportul de analiză generat de CAST Engineering Dashboard
Unul dintre punctele tari ale acestei platforme este Appmarq[^11], o colecție de aplicații analizate, ce oferă servicii de reper pentru decizii organizaționale legate de calitatea software. Unul dintre punctele slabe l-ar putea reprezenta formula de calcul a datoriei tehnice, care se bazează pe un prag care nu ia în calcul toate probleme referitoare la cod, ci doar procente din acestea, cum au fost descrise mai sus.
Tabelul 2 sumarizează instrumentele prezentate, împreună cu punctele tari, respective slabe despre care considerăm că pot fi folosite ca factori de diferențiere în decizia privind folosirea acestor instrumente.
Tabelul 2: Comparația principalelor instrumente de estimare a datoriei tehnice
Sperăm că această analiză va fi utilă echipelor de dezvoltare software în alegerea unui instrument, sau, în funcție de situație, în a descoperi caracteristici și a utiliza instrumentul ales la potențial maxim.
Alegerea trebuie determinată de scopul pentru care se măsoară datoria tehnică, lucru explorat într-un recent studiu sumativ [6]. Cele mai multe dintre instrumentele descrise mai sus permit analizarea statică a codului sursă și determinarea unor metrici de calitate (complexitate ciclomatică, numărul de parametri ai metodelor, structura ierarhiei de moștenire ș.a.m.d.). Doar unele unelte permit însă defalcarea datoriei tehnice în cea principală și dobândă, unde, la fel ca în cazul celei financiare, dobânda se referă la datoria acumulată adițional din cauza datoriei principale. Printre aceste unelte amintim CAST AIP și NDepend, cu mențiunea că modul de calcul este diferit, acesta fiind, de asemenea, un factor de luat în calcul. Atât CAST AIP, cât și SonarQube permit analizarea aspectelor legate de securitate, în timp ce modificabilitatea și mentenabilitatea sunt luate în calcul de toate uneltele.
Credit: Mulțumiri studenților specializării de master Inginerie Software (Facultatea de Matematică și Informatică, UBB): figurile corespunzătoare instrumentelor SonarQube și NDepend sunt preluate din proiectele lor de la cursul "Software Quality".
[1] https://docs.sonarqube.org/latest/
[2] https://www.ndepend.com/features/technical-debt#Debt
[3] https://www.kiuwan.com/docs/display/K5/Documentation
[4] https://www.castsoftware.com/products/engineering-dashboard
[5] https://www.castsoftware.com/solutions/control-your-technical-debt
[6] P. C. Avgeriou et al., "An Overview and Comparison of Technical Debt Measurement Tools," in IEEE Software, vol. 38, no. 3, pp. 61-71, May-June 2021, doi: 10.1109/MS.2020.3024958.
de Ovidiu Mățan
de Victor Popa
