ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 144
Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 112
Abonament PDF

Instrumente de estimare a datoriei tehnice (II)

Simona Motogna
Conferențiar @ Facultatea de Matematică și Informatică, Universitatea Babeș-Bolyai



Arthur Molnar
Lector @ Facultatea de Matematică și Informatică, Universitatea Babeș-Bolyai



PROGRAMARE


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ă.

Instrumente pentru 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:

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.

Concluzii

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".

Referințe:

[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.

LANSAREA NUMĂRULUI 144

Modern Agile

joi, 20 iunie, ora 18:00

sediul msg systems Romania

Facebook Meetup StreamEvent YouTube

NUMĂRUL 143 - Software Craftsmanship

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Colors in projects