Conducerealor software - Evaluarea costurilorlor software

Conducerea Proiectelor software

Evaluarea costurilor proiectelor software

Principiile de baza ale evaluarii costurilor proiectelor software, tipurile de resurse necesare, principalele metrici de evaluare si cele mai raspandite tehnici de evaluare a costurilor.

Stefan Stelian Diaconescu

Este normal ca o companie care doreste sa realizeze un proiect software indiferent daca este vorba sa raspunda astfel la o cerere de oferta a unui client anumit sau daca este vorba sa raspunda la o cerere generala a pietei) sa se intereseze din capul locului de costurile elaborarii acelui proiect. In felul acesta, compania respectiva va fi nevoita sa raspunda la intrebarea dificila: cum poti masura un lucru care nu exista (inca)? Daca ar fi vorba de proiecte nu de realizat un produs software ci de realizat, sa zicem, o casa, lucrurile ar fi (poate) mai simple. Nici casa nu exista la momentul realizarii proiectului. Dar se pot estima destul de exact cantitatile de materiale (iar ponderea acestora in costurile totale este de regula foarte mare), se poate estima necesarul de mana de lucru, se cunosc productivitatile,

Un proiect software este insa ceva mai greu de definit. 'Materialele' care intra in realizarea sa sunt mult mai putin diverse si in cantitati mult mai mici. Stabilirea necesarului este in ce le priveste o sarcina nu chiar atat de dificila (dar nici elementara daca este vorba de a stabili ce configuratii se preteaza mai bine pentru o anumita aplicatie). In schimb, 'inteligenta' inclusa in proiect este (cel putin procentual) mult mai importanta. In mod (poate) simplist cantitatea de 'inteligenta' se va masura intr-o maniera detul de prozaica: prin numarul de zile de lucru acordate acelei activitati de niste oameni ('inteligenti') avand diverse specializari si cunostinte.

Lucrurile nu par insa a se fi simplificat prea mult caci intrebarea ramane (acum intr-o forma modificata): cum poti spune cat timp va lua realizarea unui lucru care nu exista inca?

La aceasta intrebare (dar si la altele cateva) vom incerca sa raspundem in cele de mai jos.

Este adevarat ca experienta joaca un rol important, iar cele peste 400 de proiecte software dezvoltate de echipele departamentului Software al SOFTWIN (unde autorul prezentului articol lucreaza) constituie o serioasa expertiza.

Sa incepem insa cu inceputul si sa vedem care sunt

Resursele consumate de un proiect software

Va trebui sa pornim de la postulatul, ca 'din nimic, nimic rasare' (fara sa ne avantam aici in dispute mai mult sau mai putin filozofice) si deci daca investim ceva intr-o anumita activitate atunci este posibil (dar asta nu poate garanta nimeni) sa obtinem ceea ce dorim. Intr-un proiect software trebuie sa investim anumite resurse.

Exista trei tipuri de resurse (software, hardware, si umane) pe care le vom trece in revista dar vom insista numai asupra unuia din aceste tipuri (resursele umane).

a) Resurse software. Acestea constau in programele si licentele corespunzatoare de utilizare. Exista numeroase astfel de resurse software ce pot fi implicate direct in elaborarea unui proiect software: sisteme de operare, servere de diverse feluri, scule de gestiune proiect, scule suport (editoare de text, posta electronica, sisteme de grupware, software de retea), scule de programare (compilatoare, SGBD-uri), scule CASE, scule de test, scule de simulare. Daca unele scule sunt prea specifice si nefiind gasite ca atare pe piata, vor trebui elaborate si ele odata cu proiectul (sau, uneori, inainte de elaborarea proiectului), vor fi considerate ca parti colaterale ale proiectului insusi si deci nu vor fi plasate in categoria de resurse.

b) Resurse hardware. Resursele hardware pot fi clasificate pe tipuri (calculatoare cu configuratiile lor, linii si dispozitive de comunicatii, imprimante, scannere, unitati de banda magnetica, echipamente multimedia, etc.) sau pe destinatii (pentru dezvoltare, pentru testare, pentru prototipuri, pentru implemenari pilot daca este cazul)

c) Resurse umane. Pentru a realiza in cele din urma un proiect software avem nevoie de resurse umane: specialisti cu anumite competente si cu o anumita experienta. Resursele umane se pot clasifica la randul lor pe profile (sef de proiect, analist, programator, testor, responsabil cu documentatia, responsabil cu asigurarea calitatii) sau pe specialitati (limbaje, sisteme, instrumente de dezvoltare).

Asa cum am mentionat mai sus, costurile privind resursele umane reprezinta principalele elemente de cost ale unui proiect software. Dar nu singurele, asa ca vom trece, pe scurt, in revista diversele

Elemente ale costurilor unui proiect software

Nu vom face decat o simpla enumerare a principalelor elemente de cost ale unui proiect software. Aceasta enumerare este utila acelora care vor face o evaluare a costurilor unui proiect software pentru a verifica daca nu sunt cumva elemente pe care au uitat sa le ia in consideratie.

Elemanetele de cost pot fi clasificate in doua grupe:

a) Activitati (masurate prin timp de lucru multiplcat cu costul corespunzator specializarii pe care trebuie sa o aiba cel care indeplineste aceasta activitate) Astfel de elemente de cost sunt: studiul problemei, documentarea, formarea personalului, analiza, conceptia, codificarea, testarea, elaborarea documentatiei, elborarea documentatiei on line (help), implementarea, formarea personalului de exploatare, garantia, gestiunea de proiect.

b) Alte costuri (masurate conform caracteristicilor lor intrinseci): costuri de deplasare, costuri pentru echipamente (amortizari), regii, consumabile, procurare de documentatii, costuri de comunicatii (altele decat cele cuprinse in regie), costuri legate de fluctuatia valutara.

Desigur, la toate costurile implicate de un proiect trebuie adusa si o corectie care tine de coeficientul de risc.

Un lucru trebuie insa precizat inca de pe acum: costul efectiv al proiectului asa cum apare el in oferta nu este de regula egal cu pretul rezultat din evaluarea proiectului. Este posibil ca asupra costului la client sa intervina si alti factori, mai mult sau mai putin conjuncturali cum ar fi: clientul are suficiente fonduri pentru a acoperi cheltuieli mai mari; clientul nu are fonduri suficiente dar proiectul prezinta interes pentru realizator deoarece prin elaborarea lui castiga expertiza intr-un anumit domeniu sau prin realizarea proiectului obtine o serie de subproduse care vor fi utile si in alte proiecte; costurile sunt mai mari decat cele trecute in oferta dar clientul reprezinta pentru realizator un interes strategic, etc.

Vom insista asupra evaluarii costurilor care deriva din resursele umane implicate in proiect printr-un ansamblu de activitati. Pentru a putea evalua cantitativ resursele umane necesare unui proiect avem insa nevoie sa cunoastem

Metricile folosite in evaluarea proiectelor software

Pentru a putea masura proiectele software se folosesc mai multe metrici. O metrica pentru un proiect software este o metoda de a caracteriza din punct de vedere cantitativ un proiect software. Exista doua tipuri de metrici mai folosite pentru proiectele software: metrici orientate pe dimensiune (size oriented metrics) si metrici orientate pe functii (function oriented metrics).

a) Metricile orientate pe dimensiune constau in estimarea numarului de linii sursa.

b) Metricile orientate pe functii constau in estimarea complexitatii functiilor realizate de programul (aplicatia) rezultat(a) in urma realizarii proiectului. Printre metricile orientate pe functii enumeram: metrici orientate pe puncte functionale (function point oriented metrics) si metrici orientate pe puncte caracteristice (feature point oriented metrics).

Vom aborda mai intai

Metricile orientate pe dimensiune

Metricile orientate pe dimensiune folosesc ca masura numarul de linii sursa sau numarul de linii sursa livrate. De regula numarul de linii sursa este mai mare decat numarul de linii sursa livrate din doua motive: pe de o parte, in cursul elaborarii exista posibiltatea ca unele module ale proiectului sa fie codificate de mai multe ori (daca este vorba de cautarea si testarea unor algoritmi complicati, de exemplu, in scopul de a-l alege pe cel mai potrivit), pe de alta parte unele module elborate s-ar putea sa fie necesare numai pentru anumite simulari si experimentari deci sa nu se mai regaseasca deloc in produsul final.

Unitatile de masura folosite sunt numarul de linii sursa LOC (line of code) sau numarul de kilolinii sursa KLOC (kilolines of code), respectiv numarul de linii sursa livrare DSI (delivered source instructions) sau KDSI (kilo delivered source instructions).

Pentru a aplica o metrica bazata pe dimensiune se procedeaza in felul urmator (vezi caseta 'Metrici orientate pe dimensiune'):

a) Se descompune proiectul in sarcini (taskuri) de codificare cat mai fine.

b) Se estimeaza taskurile in LOC (KLOC, DSI, KDSI) in trei feluri: pesimist, mediu, optimist.

c) Se mediaza ponderat costul fiecarui task (dand o pondere mai mare evaluarii medii). De exemplu: cost task = (cost pesimist + 4 * cost mediu + cost optimist) / 6.

d) Se insumeaza costurile astfel obtinute ale tuturor taskurilor rezultand costul total T.

Pornind de la aceasta valoare T (costul total al proiectului in, sa zicem in KLOC, se pot calcula diverse metrici pentru proiectul respectiv, cum ar fi:

Productivitatea = T / (persoane*zile)

Calitatea = Numarul de fise de anomalie / T

Costul = $ / T

Documentatie = pagini / T

Evident, aceste valori se estimeaza la inceputul proiectului si se masoara efectiv la sfarsitul proiectului.

Sa vorbim acum si despre metricile orientate pe functii incepand cu

Metricile orientate pe puncte functionale

Metricile orientate pe puncte functionale au fost propuse cu mult timp in urma de Albrecht, A. J. in Measuring Development Productivity, Proc. IBM Applic. Dev. Symposyum, Monterey, CA, October 1979, pp. 83-92.

Aplicarea acestui tip de metrica se face in trei pasi, dupa cum urmeaza:

Pas1. Se plaseaza aplicatia intr-una din trei categorii posibile de program:program simplu, program mediu, program complex.

Exista o lista de caracteristici globale ale programului (sau de parametri): numar de intrari utilizator, numar de iesiri utilizator, numar de interogari utilizator, numar de fisiere, numar de interfete externe. Se stabileste pentru aplicatia respectiva numarul corespunzator fiecarui parametru (vezi caseta: 'Metrici bazate pe puncte functionale - tabelul 1'). Se multiplica fiecare parametru cu ponderea corespunzatoare tipului de program (simplu, mediu, complex) si se insumeaza rezultatele. Rezulta un total T1.

Pas2. Exista un alt numar de caracetristici generale ce se pot aplica programului (vezi caseta : 'Metrici bazate pe puncte functionale - tabelul 2'):

Se determina gradul de influenta al fiecarei asemenea caracteristici asupra programului (valori intre 0 si 5) si se insumeaza aceste valori obtinandu-se un total T2.

Pas3. Se aplica formula:

FP = T1 * (0,65 + 0,001 * T2)

Valoarea FP astfel obtinuta se poate apoi folosi pentru a stabili diferite metrici, cum ar fi cele de la 'Metrici orientate pe dimensiune' in care se inlcuieste T cu FP.

O actualizare a metricilor orientate pe puncte functionale este reprezentata de

Metricile orientate pe puncte caracteristice

Metricile orientate pe puncte caracteristice au fost propuse de Jones C. A. (A short History of Function Points and Feature Points, Software Productivity Research, Inc., Burlington, MA, June 1986).

Aceste metrici nu difera de metricile orientate pe puncte functionale decat intr-o foarte mica masura, dupa cum se va vedea mai jos:

Pas 1. Programele nu se mai impart in cele trei clase de dificultate.

Valoarea T1 se calculeaza pe baza unui alt tabel (vezi caseta: 'Metrici orientate pe puncte caracteristice') in care s-a adaugat inca un parametru 'Algoritmi'.

Sunt alte ponderi acordate diferitilor parametri.

Pas 2.Este identic cu cel de la metricile orientate pe puncte functionale.

Inainte de a intra in prezentarea propriu-zisa a unor tehnici de evaluare a proiectelor software vom aminti si cateva lucruri privind unele

Moduri de apreciere a costurilor unui proiect software

Pentru a aprecia costurile unui proiect software un cuvant foarte greu il are experienta celui care face aceasta evaluare. Faptul de a fi vazut mai multe proiecte in desfasurare si de a fi evaluat a posteriori mai multe proiecte reprezinta un set de informatii ce au o foarte mare valoare in procesul de evaluare. Cu toate acestea, evaluarea a posteriori trebuie privita cu grija si discernamant deoarece in domeniul proiectelor software functioneaza asa numita lege a lui Parkinson care spune, pe scurt, ca 'un proiect software se intinde cat cuprinde'. Oricat de paradoxal ar parea, unul si acelasi proiect software se poate realiza si in, sa zicem, 4 luni om si in 8 luni om, lucrandu-se la fel de serios ('fara a trage chiulul'). Cum este posibil asa ceva si ce valoare mai are evaluarea anterioara a unui proiect in aceste conditii? Explicatia este urmatoarea: un proiect realizat intr-un timp mai scurt (dar nu sub o anumita limita minima) va fi mai putin finisat, mai putin testat, mai sarac in functionalitati de natura, de exemplu, ergonomica, s. a. m. d. in timp ce un proiect realizat intr-un timp mai lung nu va avea aceste neajunsuri. La dept vorbind, un proiect software complex nu este niciodata terminat. El poate suferi noi imbunatatiri, perfectionari, cresteri de performanta, adaptari, etc. De aceea produsele software pot avea numeroase versiuni si se afla intr-o continua evolutie. Exista desigur un anumit stadiu de la care produsul software devine utilizabil (momentul in care el raspunde cerintelor specificate in caietul de sarcini) si deci se poate considera proiectul incheiat. O dezvoltare, o imbunatatire, va fi un nou proiect. Cand se face, deci, evaluarea a posteriori a unui proiect in scopul de a culege invataminte utile pentru evaluarea a priori a altor proiecte, va trebui sa se ia in considerare numei acele costuri minimale implicate de proiect pentru a satisface cerintele stipulate in caietul de sarcini.

Uneori experienta unui singur om poate sa nu fie suficienta. Oricum, corelarea experientei mai multor evaluatori care fac evaluari separate este un factor ce poate duce la rezultate mai apropiate de adevar. Erorile vor fi si mai mici daca aceasta experienta este legata chiar de proiecte asemanatoare.

Evaluarea trebuie sa tina cont si de posibilitatile de plata ale clientului. Pornind de la un pret impus (atunci cand acesta se cunoaste) se poate face evaluarea astfel ca proiectul sa se incadreze in aceasta limitare (daca se poate face acesta incadrare - altfel proiectul este imposibil). Desigur, clientul va primi in acest caz atat cat poate plati (de cati bani, atata peste

Strategiile generale de evaluare se pot clasifica in cele doua grupe cunoscute: estimare de sus in jos (top down) in care se porneste de la o estimare globala si se rafineaza prin detaliere sau estimare de jos in sus (bottom-up) in care se porneste de la costurile elementelor marunte. De fapt, cele doua metode se combina in felul urmator: 1. se face o analiza top-down a sarcinilor implicate de proiect pana la gradul de detaliere la care se poate ajunge; 2. Se evalueaza aceste sarcini 'mici'; 3. Se construiesc costurile bottom-up; 4. Se ajusteaza sumele totale redistribuind (de sus in jos) costurile pe sarcini. Pasii 3-4 se pot repeta de mai multe ori.

Tehnicile propriu-zise de evaluare sunt de doua feluri: tehnici (sau modele) de evaluare prin descompunere si tehnici (sau modele) algoritmice. Tehnicile de evaluare prin descompunere pun accentul pe descompunerea proiectului in taskuri cat mai mici si evaluarea lor separata. Tehnicile de evaluare algoritmice pun accentul pe utilizarea unui anumit algoritm (si a anumitor formule) pentru a stabili o legatura intre cerinte si costuri. Trebuie spus insa ca si tehnicile algoritmice pornesc tot de la niste evaluari primare bazate pe experienta si care se pot face tot prin descompuneri.

Trebuie sa facem o precizare importanta: in evaluarea costurilor unui proiect software o mare importanta are calibrarea metodei utilizate. Prin calibrare se intelege utilizarea metodei in conditii asemanatoare pe un numar de proiecte (cel putin 2-3). Prin conditii asemanatoare se intelege: aceeasi companie elaboratoare, aceleasi echipe (sau aceiasi specialisti), aceleasi scule de dezvoltare. Prin aplicarea unor metode necalibrate eroarea poate fi de 85-610 %. Prin calibrare se poate ajunge la 50-100%. Nici o metoda (calibrata sau nu) nu poate garanta o eroare zero.

Vom incepe prezentarea modelelor de evaluare a proiectelor software prin

Modelul EE de evaluare a proiectelor software

Modelul EE (Effort Estimation) este un model prin descompunere. El consta in descompunerea proiectului pe doua coordonate (vezi caseta: 'Modelul EE de evaluare a unui proiect software): se descompune mai intai proiectul in taskuri functionale mici apoi fiecare task functional este descompus la randul sau in subtaskurile corespunzatoare fazelor globale ale unui proiect. Taskurile functionale sunt caracteristice proiectului. Taskurile corespunzatoare fazelor globale ale proiectului sunt: analiza, conceptia preliminara, conceptia detaliata, codificarea, testarea. Se estimeaza costurile pentru fiecare subtask. Se vor putea apoi determina costurile pe functii sau pe faze si costul total.

In aceasta reprezentare se pot evidentia mai clar si costurile pe faze, lucru important deoarece, deseori, costurile unitare sunt diferite pe tipuri de faze diferite . De exemplu, de obicei cost analist > cost conceptor > cost codificator> cost testor (toate costurile fiind in moneda / (zi*om)).

Aceasta metoda de evaluare este relativ simpla si foarte eficienta (adica duce la rezultate foarte bune cu grad de eroare foarte mic). Pentru a fi aplicata este insa necesara o anumita experienta (dar unde nu este nevoie de experienta mai ales cand este vorba de aprecierea proiectelor software?).

Un alt tip de modele prin descompunere este reprezentat de

Modelele LOC si FP

Modelel LOC si FP sunt tot modele de evaluare prin descompunere. Ele sunt asemanatoare cu exceptia metodei de apreciere a LOC (vezi 'Metricile orientate pe dimensiune') si respectiv FP (vezi 'Metricile orientate pe puncte functionale' si 'Metricile orientate pe puncte functionale'). Vom vorbi prin urmare doar despre unul dintre ele, sa zicem LOC.

Ca si modelul EE de evaluare, se porneste de la descompunerea proiectului in taskuri functionale (vezi Caseta 6: 'Modelul LOC de evaluare a proiectelor software'). Se evalueaza apoi volumul fiecarei functii in LOC. Cunoscandu-se productivitatea medie in LOC/zi se determina durata de elaborare pentru fiecare functie. Cunoscandu-se costul unitar in Cost/LOC se determina costul pentru fiecare functie. Prin insumare se pot apoi determina durata totala si respectiv Costul total. Durata efectiva va fi desigur mai mica daca vor lucra mai multi oameni in paralel.

Aplicarea modelului LOC trebuie sa tina cont si de faptul ca productivitatea depinde de limbajul de programare folosit (se scriu mai multe linii de cod assembler decat linii de cod C++, de exemplu). Modelul LOC se aplica mai dificil cand este vorba de utilizarea unor scule vizuale de elaborare. In acest caz modelul FP este mai potrivit.

Vom trece acum la familia de modele COCOMO si vom incepe cu

Modelul COCOMO de baza

Modelul COCOMO in varianta sa numita 'de baza' a fost dezvoltat de B.W.Boehm (Software Engineering Economics, Englewood Cliffs, Prentice Hall, 1981) Boehm lucreaza actualmente la University of Southern Califonina, in acelasi domeniu (Center of Software Engineering).

Vom prezenta direct pasii ce trebuie urmati in aplicarea acestui model.

Pas 1. Se incadreaza proiectul de realizat intr-una dintre urmatoarele trei tipuri de program: organic, embeded si semidetached. Pentru a realiza acest lucru se porneste de la urmatoarele patru caracteristici: dimensiune, noutate, constangeri de timp, mediu de lucru (vezi caseta: 'Modelul COCOMO - tipuri de programe'). In general un proiect organic este de complexitate mica, un proiect embeded este de complexitate mare iar un proiect semidetached este de complexitate medie.

Pas 2. Conform tipului de proiect stabilit se aleg constantele (notate a, b, c, d) de calcul ce vor fi folosite ulterior (vezi caseta: 'Modelul COCOMO de baza - Constante de calcul').

Pas 3. Se aplica formulele (care sunt numerice si nu dimensionale):

effort = a * dimensiune b

durata = c * effort d

numar de persoane = effort / durata.

unde: dimensiunea este in KLOC, efortul este in persoane * luna si durata este in luni.

O perfectionare a modulului COCOMO de baza este

Modelul COCOMO intermediar

In scopul de a aduce o caracterizare mai fina a proiectului, modelul COCOMO intermediar adauga un numar de factori de ajustare a efortului necesar pentru realizarea proiectului. Acesti factori sunt repartizati in 4 grupe: atribute produs, atribute hardware, atribute ale persoanelor care relalizeaza proiectul, atribute ale proiectului insusi (vezi caseta: 'Modelul COCOMO intermediar - Factori de ajustare a efortului'). Fiecare factor are maximum 6 categorii posibile de valori notate simbolic cu VL (very low), LO (low), NM (normal), HI (high), VH (very high), XH (extremely high). Fiecare categorie are o anumita valoare efectiva pentru un anumit factor de ajustare a efortului.

Factorii de ajustare a efortului au urmatoarele semnificatii si categorii de valori (deoarce in diverse abordari acesti factori apar prezentati in diverse ordini si grupari si pentru a nu aparea confuzii s-a pastrat denumirea englezeasca):

1.Required Software Reliability cuantifica gradul de incredere in produsul finit (cat de grav este impactul unei defectiuni a lui). Un grad mai mare de incredere cerut implica effort mai mare in proiectare si testare. Valori posibile:

VL Nu este foarte grava o defectiune a aplicatiei [0.75]

LO Pierderile provocate de o eventuala defectiune se pot recupera usor [0.88]

NM Pierderile eventuale se pot recupera cu un anumit efort [1.00]

HI Pierderile sunt de natura militara sau de inalta importanta financiara [1.15]

VH Defectiunile pot provoca si pierderi de vieti omenesti [1.40]

2. Database Size determina efectul pe care il are asupra aplicatiei de dezvoltat dimensiunea bazei de date ce trebuie proiectata, intretinuta, manipulata. Valori posibile:

LO Efort foarte mic [0.94]

NM Efort normal [1.00]

HI Efort mare si complex [1.08]

VH Efort deosebit de mare si complex [1.16]

3. Software Product Complexity masoara complexitatea produsului ce urmeaza a fi realizat. Valori posibile:

VL Programe simple de iesire lucrand off-line [0.70]

LO Prelicrari de date off-line [0.85]

NM Prelucrari de date si rutine matematice [1.00]

HI Prelucrari complexe de date [1.15]

VH Prelucrari de timp real si prelucrari matematice complexe [1.30]

XH Prelucrari stiintifice extrem de complexe [1.65]

4. Execution Time Constraints masoara cu aproximatie procentajul de timp unitate centrala (CPU) disponibil ce va fi folosit de aplicatie. Valori posibile:

NM 60% utilizare [1.00]

HI 70% utilizare [1.11]

VH 85% utilizare [1.30]

XH 95% utilizare sau mai mult [1.66]

5. Main Storage Constraints masoara gradul de constrangere impus aplicatiei datorat limitarilor de memorie centrala (pe calculatorul pe care aplicatia se va folosi, in raport cu o memorie maxima). Valori posibile:

NM Nu sunt constrangeri de memorie [1.00]

HI Constrangeri mici [1.06]

VH Constrangeri medii [1.21]

XH Constrangeri mari [1.56]

6. Virtual Machine Volatility masoara perspectiva modificarilor in mediile de dezvoltare si in mediul tinta al aplicatiei in timpul fazelor de proiectare si dezvoltare. Valori posibile:

LO O schimbare la 6 luni [0.87]

NM O schimbare la 3 luni [1.00]

HI O schimbare pe luna [1.15]

VH Mai multe schimbari pe luna [1.30]

8. Computer Turnaround Time reprezinta o masura a timpului folosit pe calculator pentru a compila, a lista, etc. si a consumului de timp neproductiv. Valori posibile:

LO Sub 30 minute [0.87]

NM Sub 4 ore [1.00]

HI Peste 4 ore [1.07]

VH Peste 12 ore [1.15]

9. Analysts Capability reprezinta o masura a gradului de pregatire a echipei care face analiza, a competentei privind elaborarea conceptiei preliminare si a experientei privind limbajul (limbajele) folosit(e). Valori posibile:

VL Personal nou, fara experienta [1.46]

LO Echipa care functioneaza dar are eficienta slaba [1.19]

NM Echipa medie cu eficienta medie [1.00]

HI Echipa puternica cu buna eficienta [0.86]

VH Echipa puternica ce are si oameni deosebit de capabili [0.71]

10. Programming Capability este o masura a capacitatii echipei care realizeaza conceptia detaliata, codificarea si testarea. Se ia de asemenea in considerare si experienta cu limbajele de programare folosite precum si cu metodologia de elaborare folosita. Voalori posibile:

VL Personal nou fara experienta [1.42]

LO Echipa functionala cu eficienta scazuta [1.17]

NM Echipa normala cu eficienta normala [1.00]

HI Echipa puternica cu eficienta buna [0.86]

VH Echipa puternica cu mai multe persoane de exceptie [0.70]

11. Application Experience masoara experienta echipei in aplicatii asemanatoare. Valori posibile:

VL Fara experienta (sub 4 luni) [1.29]

LO Experienta limitata (1 an) [1.13]

NM Experienta normala (3 ani) [1.00]

HI Experienta peste medie (6 years) [0.91]

VH Experti (peste 12 ani experienta) [0.82]

12. Virtual Machine Experience masoara experienta echipei de proiectanti si programatori cu mediul de dezvoltare dar si cu mediul tinta al aplicatiei. Trebuie tinut cont si de curba de invatare a echipei privind sculele CASE, sculele de depanare, etc. Valori posibile:

VL Respectivele medii nu au mai fost folosite niciodata [1.21]

LO Sub 6 luni [1.10]

NM Sub 1 an [1.00]

HI Peste un an [0.90]

13. Language Experience masoara experienta echipei care codifica in ceea ce priveste limbajul de programare folosit. Valori posibile:

VL Limbajul nu a mai fost folosit inainte [1.14]

LO Sub un an experienta [1.07]

NM Cel putin un an experienta [1.00]

HI Doi sau mai multi ani experienta [0.95]

14. Use of Software Tools masoara gradul de utilizare a unor scule automate (CASE). Se ia in consideratie experienta globala a echipei. Valori posibile:

VL Scule foarte putine si primitive [1.24]

LO Scule modeste [1.10]

NM Scule medii [1.00]

HI Scule la un nivel inalt [0.91]

VH Scule de dezvoltare integrate [0.83]

15. Application of software engineering methods cuantifica gradul de folosire a unor tehnici de programare moderne in raport cu momentul elaborarii aplicatiei. Se ia in considerare experienta intregii echipe de programatori.

VL Nu se folosesc asemenea tehnici [1.24]

LO Programatorii sunt incepatori [1.10]

NM Programatorii au mai folosit asemenea tehnici [1.00]

HI Tehnicile au fost folosite de toti membrii echipei [0.91]

VH Membrii echipei au o buna experienta [0.82]

Aplicarea modelului CCOMO intermediar se face in urmatorii pasi :

Pas 1. Este analog cu pasul 1 de la modelul COCOMO de baza.

Pas 2. Se determina fae (factorul de ajustare a efortului) folosindu-se o tabela de tipul celei din caseta. Factorul va fi produsul valorilor alese pentru toti factorii individuali.

Pas 3. Se determina constantele a', b' de calcul conform tipului de proiect stabilit in Pas 1 folosind tabela din caseta 'Modelul COCOMO intermediar - Constante de calcul'. Se determina constantele de calcul c, d ca la Pas1 de la modelul COCOMO de baza.

Pas 4. Se aplica formulele:

efort = a' * fae * dimensiune b'

durata= c * efort d

numar de persoane= efort/durata

unde: dimensiunea este in KLOC, efortul este in persoane * luna si durata este in luni.

Vom prezenta in continuare sumar si

Alte modele de evaluare a costurilor proiectelor software

Fara a insista asupra lor vom da numai ideile generale ale altor cateva modele de evaluare a costurilor proiectelor software:

a) Modelul COCOMO detaliat este asemanator cu modelul COCOMO intermediar. Diferenta consta in folosirea de factori de ajustare a efortului (fae) diferiti pe fiecare faza a unui proiect. Sunt definite 6 faze: cerinte, proiectare produs, proiectare detaliata, codificare si teste unitare, teste de integrare, mentenanta.

b) Modelul REVIC face parte de fapt tot din familia COCOMO. El a fost dezvoltat de Raymond L. Kyle de la Hughes Aerospace. Modelul adauga inca un alt tip de proiect (proiecte ADA specifica domeniului aviatiei care se foloseste mai mult de limbajul ADA)precum si alte elemente pentru calculul fae: Required Reusability (masoara efortul suplimentar necesar pentru a generaliza modulele software in asa fel incat sa se poata reutiliza in alte aplicatii), Requirements Volatility (Masoara volumul de munca necesar pentru a reface proiectarea produsului ca urmare a unei eventuale modificari in specifcatiile clientului - implica masura timpului folosit pentru evaluarea cerintelor de modificare, estimarea impactului asupra procesului de elaborare, modificarea conditiilor contractuale), Risk (permite adaugarea unui coeficient care ia in considerare diversele nivele ale riscului), Classified Security Application (masuri ce trebuie luate in desfasurarea activitatii pentru a raspunde unor cerinte de securitate deosebite, in sensul de secretizare).

c) Modelul Putnam este derivat din studierea unor proiecte mari. Foloseste curbele Raileigh-Norden (descrise analitic de Raighley si completate cu date empirice culese de Norden). Acest model proneste de la ideea ca exista o anumita distributie a efortului pe parcursul unui proiect in raport cu diversele sale faze.Efortul de dezvoltare K (in persoane-an) este, conform acestui model, dat de formula:

K = (dim/C) ³ (1/T) ⁴

unde dim este dimensiunea proiectului in KLOC iar C e o constanta tehnologica (combina efectul sculelor de dezvoltare, limbajelor, metodologiilor, asigurarii calitatii, etc.) iar T este timpul de dezvoltare in ani. Valoarea lui C variaza intre 2000-11000 (de exemplu C = 2000 pentru mediu de dezvoltare sarac, C = 8000 pentru mediu de dezvoltare potrivit si C =11000 : mediu de dezvoltare excelent).

La toate cele de mai sus sa incercam acum sa tragem si cateva

Concluzii

In articolul de mai sus au fost prezentate elemente privind metricile si evaluarea costurilor pentru proiectele software. Aceste elemente pot fi folosite ca atare sau prin intermediul unor aplicatii specializate. Exista numeroase astfel de aplicatii, atat comerciale, cat si din domeniul public.

Dintre aplicatiile comerciale amintim: ACE_IT realizat de US Army and Navy (www.aceit.com), COSTAR realizat de SoftStar Systems (www.softstarsystems.com), Cost*Xpert realizat de Marotz, Inc. (www. marotz.com), Price_S realizat de Gaborath (www.gaseer.com), Knowledge Plan si Check Point realizate de Software Productivity research (www.spr.com), Estimate Profesional realizat de Software Productivity Center (www.spc.ca/estimate/ index.htm), GA SEER realizat de Galborath (www.gaseer.com), SLIM (Software Lifecycle Management) realizat de Quantitative Software Management (www.qsm.com), Price_S realizat de Price Systems (www.pricesystems.com).

Aplicatiile din domeniul public provin in general de la universitati cum ar fi:

Cocomo 2 de la University of Southern California (sunset.usc.edu/COCOMOII/cocomo.html),

COSMOS (www-cs.etsu.edu/faculty/ henryj/ dsstud/cosmos.exe) iar

SEAT (www-cs.etsu.edu/faculty/henryj/ dsstud/seat/seat24_2.zip) de la East Tenessee State University.

Activitatea de evaluare a unui proiect precede realizarea propriu-zisa a proiectului. Diversele scule de evaluare este bine sa permita ca informatiile legate de evaluare sa fie folosite si in timpul desfasurarii proiectului. In felul acesta se poate urmari mai usor in ce masura proiectul se incadreaza in costurile estimate, unificandu-se evaluarea cu planificarea si urmarirea.

Indiferent de metodele folosite, indiferent de sculele folosite, nu trebuie scapat din vedere un lucru foarte important: experienta in evaluari este determinanta pentru a obtine rezultate corecte. Si aceasta deoarece, indiferent de metoda, exista de la cativa parametrii pana la cateva sute, parametri care trebuie sa fie apreciati de catre expert.

In fine, indiferent de metoda, trebuie sa aiba loc un proces de calibrare in care cei trei factori: expertul;, sistemul (metoda) folosita si echipa realizatoare sa ajunga sa se 'potriveasca' astfel ca rezultatele sa fie cat mai apropiate de adevar. Iar in acest proces, culegerea de informatii cantitative detaliate din proiectele terminate (prin bilantul de proiect) permite atat acumularea experientei cat si calibrarea metodelor.