| CATEGORII DOCUMENTE |
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).
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
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.
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…
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…
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 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…
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.
|
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 2064
Importanta: 
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved
