Evaluarea produselor software

A estima cât mai corect costurile si eforturile necesare dezvoltării unui produs software este adesea o conditie esentială a competitivitătii

Cătălin Floroiu

Analiza, proiectarea, implementarea, testarea si întretinerea aplicatiilor software ce sunt utilizate în diferite domenii de activitate, de la operatiuni bancare si până la functionarea sistemelor în timp real din industria nucleară sau aerospatială, reprezintă un intens efort de inteligentă asistat de unul organizatoric si financiar; aceste eforturi sunt de dimensiuni apreciabile si aflate într-o continuă crestere, ca pondere în totalul resurselor umane si materiale utilizate.

În vreme ce tehnica de calcul devine din ce în ce mai performantă ca urmare a utilizării tehnologiilor de vârf (prin miniaturizare si ieftinire), la elaborarea si întretinerea aplicatiilor software, în special a celor complexe, resursele consumate ajung să reprezinte 70-80% din costul total al sistemului (hardware si software) si chiar cu posibilitatea de crestere până la 90% în unele cazuri.

Fundamente ale ingineriei software

Volumul mare al activitătii necesare pentru a dezvolta si întretine programele (si deci implicit nivelul înalt al costurilor asociate), justifică interesul din ce în ce mai larg pentru asigurarea unei calităti corespunzătoare aplicatiilor precum si minimizarea costurilor de elaborare a acestora. Sunt utilizate metode si instrumente adecvate analizei în detaliu a cerintelor software si de elaborare sau testare a programelor, ce asigură un minimum de erori admisibile si o productivitate cât mai mare.

Aceste aspecte specifice ce însotesc elaborarea programelor, au determinat renuntarea la conceptul de programare "artistică", după instinct si imaginatie si au dat nastere unor încercări de abordare sistemică a problematicii elaborării aplicatiilor, conducând în mod firesc la formularea unor noi concepte, principii, metode si instrumente de construire a programelor, cunoscute si sub denumirea de inginerie software. Ingineria software urmăreste în esentă rezolvarea unor probleme specifice legate de analiza, proiectarea, implementarea, testarea si întretinerea programelor si anume:

Stabilirea etapelor si a sub-etapelor prin care trece secvential un produs software pe durata ciclului său de viată, definirea continutului acestor sub-etape precum si a parametrilor de demarcare între sub-etapele si etapele succesive.

Abordarea formală prin elaborarea unor metode riguroase si a unor instrumente asociate acestora, destinate asistării proiectării produsului software. Ele trebuiesc adaptate diferitelor sub-etape din ciclul de viată ale unui program, diferitelor tipuri de programe precum si complexitătii variate a programelor ce se realizează.

Elaborarea unor proceduri clare de organizare si conducere a diferitelor activităti legate de realizarea programului (calitate, performantă). Obiectivul final al ingineriei software este trecerea de la o activitate de elaborare a programelor, în care domina stilul artizanal, de intuitie si improvizatie, de creatie tip "artă a programării" la o activitate sistematică care să asigure - asa cum am mai subliniat - înalta calitate a programelor si un cost cât mai scăzut al elaborării si întretinerii acestora. Ingineria software se referă la utilizarea în mod riguros, sistematic si cu profesionalism a unor metode si instrumente software adecvate, având în vedere anumite obiective si principii de bază.

Rentabilitatea economică a procesului de dezvoltare software este un criteriu din ce în ce mai impus de către managerii financiari, reprezentând un aspect critic al activitătii de dezvoltare a proiectelor. În definitiv, obiectivul final al oricărei companii interesate în dezvoltarea si comercializarea produsului său informatic a fost si va rămâne profitul. În concurenta sălbatică de pe piată unde se înfruntă "monstri sacri" precum Microsoft, IBM, Sun si în care sunt aruncate în luptă resurse materiale si umane de proportii uriase interesul este lansarea pe piată cât mai repede si la costuri scăzute a unor aplicatii cât mai performante care să le "bată" pe cele ale concurentei. Prin urmare "fereastra de lansare" - intervalul după care un nou produs riscă să piardă piata datorită concurentei unor versiuni mai evoluate, se îngustează în mod dramatic, evoluând în timp de la câtiva ani în trecut la doar un an sau chiar câteva luni în prezent. Aceste presiuni permanente din partea managerilor financiari, obligă echipele de programatori să aplice noi metode de productie, cât mai moderne.

Ciclul de viată al produsului software poate fi exprimat prin procentul de timp alocat fiecărei etape din procesul de dezvoltare. Un exemplu tipic ar fi următorul:

Pentru a învinge concurenta produsele trebuie să coste cât mai putin, să fie de calitate si să apară pe piată cât mai repede. Acest obiectiv se poate atinge doar printr-o abordare organizată, planificată, a procesului de dezvoltare. Unul din primii pasi realizati atunci când se ia decizia de elaborare a unui nou program este evaluarea calitativă si cantitativă a acestuia pentru a stabili în mod corect necesarul de resurse umane, materiale si de timp. Iată în continuare o descriere a celor mai recente metode de evaluare, impuse pe scară largă. Atentia se va concentra în special asupra metodelor de evaluare dimensională si functională, acestea fiind cel mai des utilizate datorită performantelor lor.

Metode de evaluare

Produsul software poate fi evaluat în mod direct fie indirect. Prin evaluarea directă a procesului de inginerie software se întelege determinarea costurilor si a eforturilor asociate. Ea presupune calculul numărului liniilor de cod (LOC - lines of code) scrise, determinarea vitezei de executie, a dimensiunii memoriei, precum si a numărului de defecte raportat într-un anumit interval de timp.

Evaluarea indirectă a produsului reprezintă în fapt o analiză a functionalitătii, calitătii, complexitătii, eficientei, fiabilitătii, întretinerii si multor altor caracteristici.

Costul si efortul necesar pentru a dezvolta software, calculul numărului de linii de cod (LOC) precum si alte estimări directe sunt relativ usor de estimat initial. Totusi, calitatea si functionalitatea sau eficienta si întretinerea sunt mult mai dificil de evaluat si pot fi măsurate doar în mod indirect. Metodele de evaluare ale produsului pot fi descrise după cum urmează:

În continuare vom face o abordare detaliată a două dintre metodele de evaluare expuse ce sunt mai frecvent utilizate de către casele de soft.

Metoda evaluării dimensionale

Evaluarea dimensională a produsului software reprezintă o estimare directă a acestuia precum si a procesului prin care el este dezvoltat. Daca un manager de proiect mentine înregistrări simple, poate fi creat un tabel cu datele ordonate dupa criteriul dimensiunii. Pentru fiecare proiect, datele dimensionale uzuale sunt:

Din datele primare continute într-un astfel de tabel (vezi caseta "Evaluarea dimensională")poate fi realizată o evaluare a productivitătii si una a calitătii, orientate dimensional, pentru fiecare proiect în parte:

Productivitatea = KLOC / Programatori-pe-lună 
Calitatea = Număr de erori / KLOC 

În completare, pot fi calculati alti parametrii interesanti:

Cost = Valoare / KLOC 
Documentatie = Pagini de documentatie / KLOC 

Utilizarea parametrilor dimensionali (KLOC, efort, etc.) este controversată si ei nu sunt universal acceptati ca reprezentând cea mai bună metodă de evaluare a procesului de dezvoltare software. Controversa se învârte în jurul utilizării liniilor de cod LOC ca mărime principală. Sustinătorii variabilei LOC afirmă că aceasta este un artefact al tuturor proiectelor de dezvoltare software si poate fi usor calculată, că multe modele de estimare utilizează LOC sau KLOC ca date de intrare principale si că există deja o literatură imensă (plus date asociate) dedicată LOC. Pe de alta parte, opozantii reclamă că variabila LOC este dependentă de limbajul de programare, că LOC poate penaliza programe bine proiectate dar scurte, că nu se poate asocia usor limbajelor neprocedurale si că utilizarea ei în estimare necesită un nivel de detaliere care poate fi dificil de obtinut (ex: managerul de proiect trebuie să estimeze numărul de linii de cod ce trebuie produse cu mult înainte ca analiza si proiectul programului să fi fost încheiate).

Evaluarea Functională

Parametrii ce caracterizează din punct de vedere functional produsul software reprezintă o evaluare indirectă a acestuia si a procesului prin care el este dezvoltat. Evitând calculul LOC, parametri functionali se concentreaza asupra "functionabilitătii" sau "utilitătii" programului. Acest tip de evaluare a fost propus pentru o abordare prin măsurarea productivitătii, numită metoda scorului functional. Scorul functional (SF) este obtinut utilizând o relatie empirică bazată pe estimări calculabile ale domeniului de informatie al produsului precum si pe evaluări ale complexitătii aplicatiei.

Valorile domeniului de informatie se definesc în următorul mod:

Odată ce datele de mai sus au fost colectate, un indice de complexitate este asociat fiecărui calcul. Organizatiile care utilizează metoda scorului functional dezvoltă criterii pentru a stabili faptul dacă o anumită intrare este simplă, medie sau complexă. Bineinteles, determinarea complexitătii este un proces relativ subiectiv. Pentru a calcula scorul functional, este utilizată următoarea relatie:

SF = totalul-de-calcul * 0.65 + 0.01 * SUM (Fi); 

unde totalul-de-calcul este suma rezultatelor partiale obtinute prin ponderarea valorilor domeniului de informatie (vezi caseta "Calculul Scorului Functional"). Valorile constante din ecuatia de mai sus precum si factorii de influentă care sunt aplicati calculului domeniului de informatii sunt determinati empiric.

Valorile de ajustare a complexitătii (Fi, i=1...14) se determină evaluând influenta a 14 factori:

Necesită sistemul back-up si recovery? 
Sunt necesare facilităti de comunicatii de date? 
Sunt necesare functii de procesare distribuită? 
Este criteriul performantei critic? 
Va rula sistemul într-un mediu operational utilizat intens? 
Necesită sistemul intrări de date în regim on-line? 
Necesită sistemul de intrări de date în regim on-line, ca procesul de introducere al datelor să aibă loc pe ecrane sau prin operatiuni multiple? 
Sunt fisierele actualizate on-line? 
Sunt intrările, iesirile si interogările complexe? 
Este procesul intern complex? 
Este codul proiectat astfel încât să fie reutilizat? 
Sunt conversia si instalarea programului incluse în design? 
Este sistemul proiectat pentru instalări multiple în organizatii diferite? 
Este aplicatia proiectată astfel încât să faciliteze modificarea si usurinta în utilizare din partea beneficiarului? 

Fiecare factor este evaluat cu o notă de la 0 la 5, având semnificatiile:

0 - Nu influentează; 
1 - Incidental; 
2 - Moderat; 
3 - Mediu; 
4 - Semnificativ; 
5 - Esential; 

Odată ce scorul functional a fost calculat, el este utilizat într-o manieră asemănatoare cu metoda LOC ca o măsură a productivitătii, a calitătii si a altor atribute ce definesc programul:

Productivitatea = SF / Programatori-pe-lună 
Calitatea = Număr Defecte / SF 
Costul =Valoare / SF 
Documentatia = Pagini de Documentatie / SF 

Evaluarea pe baza scorului functional a fost concepută initial pentru a putea fi utilizată în sistemele de informatii pentru afaceri. Totusi, extinderea propusă ulterior, denumită scor caracteristic (SC), poate permite aplicarea acestei metode si în cazul programelor din domeniul sistemelor ingineresti. Scorul caracteristic este adecvat descrierii aplicatiilor în care complexitatea algoritmilor este înaltă. Aplicatiile în timp real, de control al proceselor precum si cele orientate spre obiecte au tendinta de a avea o complexitate algoritmică mare si sunt prin urmare potrivite evaluării prin metoda scorului caracteristic. Pentru a calcula acest scor valorile domeniului informational sunt din nou contorizate si ponderate. Spre deosebire de calculul scorului functional, scorul caracteristic ia în considerare încă un domeniu de informatie (algoritmi) iar valorile de ponderare sunt fixe (vezi caseta "Calculul Scorului Caracteristic"). Valoarea scorului caracteristic final se obtine din ecuatia:

SC = totalul-de-calcul * 0.65 + 0.01 * SUM (Fi); 

De remarcat că scorul caracteristic ia în considerare o nouă dimensiune a soft-ului, si anume algoritmii. Inversarea unei matrici, decodificarea unui sir de biti sau tratarea unei întreruperi sunt toate exemple de algoritmi. Trebuie de asemenea remarcat că scorul caracteristic si cel functional semnifică acelasi lucru, si anume "functionalitatea" sau "utilitatea" furnizate de către software. În fapt, amândouă evaluările au drept rezultat aceeasi valoare a SF-ului în situatia calculului ingineresc conventional sau a aplicatiilor de tip gestiune a informatiilor. Pentru sistemele în timp real, mult mai complexe, scorul caracteristic este adesea cu 20-35% mai mare decât cel calculat prin utilizarea în exclusivitate a scorului functional. Utilizarea scorului functional - sau a celui caracteristic - este controversată.

Partizanii ideii sustin că SF (SC) este independent de limbajele de programare, aceasta făcându-l ideal pentru aplicatii scrise în limbaje conventionale si neprocedurale. Ei sustin de asemenea că el este bazat pe date ce se presupun a fi cunoscute mult anterior în evolutia proiectului, făcând SF (SC) mult mai atractiv ca estimare. Pe de altă parte, oponentii ideii declară că metoda necesită putină prestidigitatie si că realizarea calculului se face în parte pe baza unor date mai degrabă subiective decât obiective; ei mai cred că informatiile pot fi dificil de strâns "după ce evenimentele au avut loc" si că SF (SC) nu are o semnificatie fizică directă - el este doar un simplu număr.

Tehnici de Decompozitie

Oamenii au dezvoltat o abordare naturală în rezolvarea problemelor: dacă problema ce urmează a fi rezolvată este prea complicată, avem tendinta să o divizăm într-o serie de sub-probleme până când ajungem la un nivel la care sub-problemele pot fi rezolvate. Rezolvăm apoi pe rând fiecare dintre sub-probleme în speranta că solutiile pot fi combinate pentru a forma o solutie globală. Estimarea proiectului software este o formă de rezolvare a problemei iar în majoritatea cazurilor, problema ce trebuie rezolvată (ex: dezvoltarea unei estimări de efort si cost pentru un proiect software) este mult prea complexă pentru a fi considerată ca un tot. Din acest motiv descompunem problema, o redefinim ca pe o colectie de sub-probleme cu o complexitate mai redusă si deci, sperăm, mai "rezolvabile".

Anterior am definit liniile de cod si scorul functional drept date initiale de la care pornindu-se poate fi calculată productivitatea. Datele LOC si SF sunt utilizate în două moduri pe parcursul estimării proiectului software:

Estimările LOC si FP sunt tehnici de estimare distincte. Totusi amândouă au un număr de caracteristici comune.

Managerul de proiect începe prin a prezenta o descriere sintetică a functiei finale a software-lui si, pornind de la această declaratie, încearcă să descompună proiectul viitorului produs informatic în mici subfunctii care pot fi estimate fiecare individual. Variabila de estimare LOC sau SC este apoi calculată pentru fiecare sub-functie. Măsurătorile de bază ale productivitătii (ex: LOC / programatori-pe-lună sau SC / programatori-pe-lună) sunt apoi aplicate celei mai potrivite variabile de estimare si este derivat efortul sau costul subfunctiei. Estimările subfunctiei sunt combinate în scopul de a furniza o estimare globală pentru întregul proiect. Tehnicile de estimare LOC si SC diferă la nivelul de detaliere necesar pentru decompozitie. Atunci când LOC este utilizată ca variabilă de estimare, decompozitia functională este absolut esentială si este adesea dusă la nivele considerabile de detaliere. Deoarece datele cerute pentru estimarea scorului functional sau mai mult macroscopice, nivelul de decompozitie atunci când SC este utilizat ca variabilă de estimare este considerabil mai putin detaliat. Ar trebui de asemenea luat în considerare faptul ca LOC este estimat direct în timp ce SC este determinat indirect prin estimarea numărului de intrări, iesiri, fisiere cu date, interogări si interfete externe cât si a celor 14 valori de ajustare a complexitătii descrise anterior.

Independent de variabila de estimare care este utilizată, managerul de proiect oferă în mod uzual un domeniu de valori pentru fiecare functie descompusă în subfunctii. Utilizând date istorice sau intuitia (atunci când orice altă metodă dă gres), managerul de proiect estimează o valoare LOC sau SC pentru fiecare functie, în cazul cel mai optimist, cel mai probabil si cel mai pesimist. O indicatie implicită a gradului de incertitudine este furnizată atunci când este specificată o gamă de valori.

Se calculează apoi o valoare asteptată pentru LOC si SC . Valoarea asteptată pentru variabila de estimare E poate fi calculată printr-o mediere a estimărilor LOC sau SF în cazurile optimist (a), probabil (m) si pesimist (b).

De exemplu, estimarea E= (a + 4m + b) / 6 dă cea mai mare credibilitate estimării celei mai probabile (m) si urmează o distributie de tip beta a probabilitătii. Presupunem ca există o foarte mică probabilitate ca LOC curent sau rezultatele SF să se afle în afara intervalului definit de valorile estimate în cazul optimist sau pesimist.

Utilizând tehnici statistice standard putem calcula estimările. Totusi, va trebui notat că o abatere bazată pe date incerte (estimate) trebuie utilizată judicios. Odată ce valoarea asteptată E pentru variabila de estimare a fost determinată, sunt utilizate productivitătiile LOC si SC. La acest moment, managerul de proiect poate aplica una sau două abordări diferite:

1. Valoarea variabilei de estimare totală pentru toate subfunctiile poate fi multiplicată cu productivitatea medie corespunzătoare acelei variabile de estimare. De exemplu, dacă presupunem că este estimat un scor functional total de 310 SF si că productivitatea este calculată pe baza relatiei SF / programatori-pe-lună având valoarea 5.5, atunci efortul total al proiectului este:

Efort = 310 / 5.5 = 56 programatori-pe-lună 

2. Valoarea variabilei de estimare pentru fiecare subfunctie poate fi multiplicată printr-o valoare ajustată a productivitătii bazată pe nivelul de complexitate estimat pentru fiecare subfunctie.

Exemplu

Să considerăm un produs software care poate fi descompus în felul următor: Interfata utilizator, Analiza 2-D, Analiza 3-D, Organizarea structurii de date, Afisarea graficii computerizate, Controlul perifericelor, Analiza proiectării.

În tabelul "Estimarea costului si a efortului", coloanele 1, 2 si 3 sunt completate de managerul de proiect. Coloana 4 ("Valoarea asteptată a LOC") este calculată după formula E = (a + 4m + b) / 6.

Coloanele 5 (Lei/LOC) si 6 (LOC/programator-pe-lună) exprimă productivitatea si sunt derivate din date istorice. În acest caz, managerul de proiect utilizează valori diferite ale productivitătii pentru fiecare functie, bazate pe gradul de complexitate.

În fine, pe baza datelor din tabel se pot calcula rubricile privind costul (7) si efortul (8), după formulele:

Cost = LOC asteptat * Lei / LOC 
Luni = LOC asteptat * LOC / Programatori-pe-lună 

Costul estimat al proiectului este de 6.570.000 lei iar efortul estimat este de 145 programatori-pe-lună.


(C) Copyright Computer Press Agora