Metrici Soft Pentru Evaluarea Termenului Necesar Realizarii Unui Proiect

Metrici soft pentru evaluarea termenului necesar realizării unui proiect

1. Introducere

1.1 Ce sunt metricile soft?

În anii ’40 când a început era calculatorului, erau doar câteva calculatoare în funcțiune și cele mai multe aplicații erau mici, fiind proiecte de o singură persoană. O dată cu trecerea timpului, calculatoarele au devenit foarte răspândite, aplicațiile au crescut în număr, mărime si importanță, costul dezvoltării programelor a crescut și el. Ca rezultat al acestei creșteri consecințele estimărilor produselor soft greșite au devenit și ele mult mai grave.

Astăzi, calculatoarele joacă un rol important în aproape fiecare sector din viața noastră. Creșterea importanței softului duce la creșterea necesității de a avea un control precis, predictibil și repetabil asupra procesului de dezvoltare și producere a softului.

Domeniul măsurătorilor soft este unul din sectoarele ingineriei programării unde cercetările sunt active de mai bine de 30 de ani. Domeniul măsurătorilor soft este cunoscut și sub numele de metrici soft. Poate fi creată o situație confuză prin folosirea atât a termenului de măsurători soft cât și a celui de metrici soft. Dacă folosim terminologia teoriei măsurătorilor folosim termenul de măsurare. În literatură termenii de metric și măsurare sunt sinonimi. Metric aici nu este considerat în sensul de spațiu metric, ci este considerat în sensul că măsurarea este o reprezentare a obiectelor empirice cu obiecte numerice printr-un homomorfism. Un homomorfism este o reprezentare care păstrează toate relațiile și structurile unei stări. Cu alte cuvinte, calitatea trebuie relaționată liniar la o măsură soft. Acesta este un concept de bază al tuturor măsurărilor. 1

1.2 Importanța măsurătorilor soft

Din punct de vedere al unui client, investiția în soft are sens doar dacă costul achiziției este mai mic decât valoarea câștigată. Deși valoarea câștigată este greu de cuantificat, costurile sunt ușor de evaluat ca fiind suma plăților către dezvoltatorul de programe. “Costurile” pentru client sunt “valoare caștigată” pentru producătorul soft. Costurile acestuia pe de altă parte sunt în principal costurile cu forța de muncă necesară dezvoltării și întreținerii softului. Un alt parametru care trebuie luat în considerare este timpul, durata necesară lansării pe piață este un factor foarte important, hotărâtor pentru succes sau eșec. În contextul ingineriei programelor avem trei parametri: cost/efort, durata, produs. Observația pe care o putem să o facem instantaneu este că fiecare parametru este puternic dependent de ceilalți. De aceea nu putem dezvolta același produs în jumătate de timp și cu jumătate de efort . Afirmații analoage pot fi făcute și pentru ceilalți doi parametri.

Controlul procesului soft atinge două zone fundamentale (care țin cont de cei trei parametri ) : • expectativa, speranța rezultatului viitor ;

• cunoașterea a ceea ce a fost deja obținut.

Prima zonă este punctul de plecare pentru tehnicile de estimare. Este de asemenea un domeniu de negocieri și compromisuri în care sunt implicați de obicei toți cei trei parametri. Arta controlării expectativei este de a avea valorile estimative pentru cei trei parametri într-o balanță rezonabilă, în ciuda tuturor presiunilor făcute de clienți, departamentul vânzări și manageri.

Al doilea domeniu conduce la măsurători. Deși efortul măsurării și scurgerea timpului nu ridică dificultăți teoretice deosebite măsurarea produselor soft este încă la început. În afara livrării datelor indispensabile administrării proiectului, ea imbunătățește și calitatea estimării, pentru că vom fi estimatori mai buni atunci cand vom ști ce am efectuat în trecut. Numai prin măsurarea a numeroase procese trecute suntem capabili să concluzionăm statistic cum sunt cei trei parametri relaționați și care este balanța rezonabilă a lor. Observațiile efectuate în anii ’80 au demonstrat că, calitatea estimării este unul din factorii corelați cel mai mult cu succesul proiectului, factor ce depășește tehnologia folosita și experiența personalului. Acest lucru este ilustrat în exemplul următor: să presupunem că organizația A produce 10 unităti de produs pe zi PU/D și organizația B produce 15 PU/D. Dar clienții organizației A sunt mult mai satisfăcuti: de ce? Este pentru că A își face planurile pe baza productivității ei reale de 10 PU/D, în timp ce B se bazeaza pe 15 PU/D și prin urmare face grave erori de planificare. 2

1.3 Există limite pentru modelele de estimare soft?

Deși au fost propuse mai mult de 1000 de etaloane soft de către specialiștii din acest domeniu, și s-au publicat mai mult de 5000 de lucrări despre acest subiect, cercetătorii în măsurătorile soft sunt împarțiți în două tabere: cei care susțin că softul poate fi masurat, și cei care afirmă ca softul nu poate fi analizat cu ajutorul măsurătorilor.

În Iulie 2001 J.P. Lewis3 publica un articol în care afirma că sunt limite în privința abilității noastre de a estima timpul necesar dezvoltării unui produs soft. Datorită concluziei atât de incomode, articolul a generat discuții aprinse în comunitatea inginerilor soft. Lewis pretinde că nu poate exista o metodă obiectivă care să conducă la o estimare bună a complexității dezvoltării de soft anterioară încheierii acestei sarcini. Pentru el
”obiectiv” înseamnă o metodă mecanică, formală care nu se bazeaza pe intuiția umana. El își sustine afirmațiile cu ajutorul unor dovezi matematice.

Argumentul lui Lewis se bazează pe noțiunea de “complexitate algoritmică”, care este o măsură a celui mai scurt program care va produce un șir dat. Complexitatea algoritmică, cunoscută și sub numele de complexitatea Kolmogorov este un domeniu bine stabilit din teoria informației și știinta calculatoarelor. Lewis observa că fiecare program soft poate fi gândit ca o tabelă care trasează intrările programului cu ieșirile corecte corespunzătoare. Această caracterizare a programării presupune un număr finit de intrări finite, care este corect pentru rezultate practice. Lewis subliniază că o tabelă poate fi reprezentată ca și un șir care consta din liniile tabelei. De aceea fiecare sarcină de programare are asociată complexitatea algoritmică — lungimea celui mai scurt program care va produce tabela care trasează datele de intrare ale proiectului și datele de ieșire. Lewis declara un rezultat standard din teoria complexității: nu există nici un algoritm pentru a calcula complexitatea algoritmică a unui șir arbitrar. Cu alte cuvinte nu poate exista nici un program care să ne spună lungimea celui mai scurt program care rezolvă o problemă arbitrară de dezvoltare soft. Lewis afirma că efortul și timpul necesar dezvoltării programelor sunt strâns legate de complexitatea algoritmică a proiectului. Punând toate împreună rezultă că nu există nici o metodă riguroasă pentru calcularea timpului necesar dezvoltării unui proiect soft anterior execuției efective a acestuia. 4

Are Lewis dreptate? Lewis are dreptate din punct de vedere matematic, dar doar în cadrul definiției înguste a problemei de estimare soft. Definiția folosită în acest articol este prea restrânsă. Programatorii reali, și cercetătorii din câmpul proceselor soft nu încearcă să rezolve problema pe care Lewis o expune.

În ciuda celor enunțate de Lewis, nici un cercetător serios din ingineria soft nu încearcă să găsească o metoda garantată care să estimeze timpul și efortul într-un mod corect. Nici măcar, nimeni nu se străduie să găseasca metode care să producă estimări garantate a fi corecte, decât doar în cadrul unei marje de eroare cunoscută. Problema reală a estimării soft este mult mai puțin strictă decât afirma Lewis. Noi doar incercăm să ajungem cumva la o estimare rezonabilă.

Presupunem că cineva descoperă o metodă fomală, mecanică de a estima efortul realizării unui program cu o corectitudine de 80% în 80% din cazuri. Pentru restul de 20% din cazuri metoda produce rezultate foarte greșite. Comunitatea soft ar fi în extaz dacă o astfel de metodă ar exista. Probabil că am fi încântați chiar dacă am găsi o metodă care să fie corectă 50% în 50% din cazuri. Lewis afirma că timpul și efortul sunt strâns legate de complexitatea algoritmică a sarcinii de programat. Aceasta poate fi adevărat, apelând fie și numai la intuiție, dar Lewis nu stabilește o relație directă între ele. Este posibil să existe un proiect soft asociat cu un program scurt care să creeze tabela potrivită de intrări/ieșiri, dar care sa fie greu pentru un om să-l descopere. Un asemenea proiect ar fi de o slabă complexitate algoritmică dar de o înaltă complexitate umană (timp si efort). Sau poate exista un proiect soft asociat cu un program mare dar pe care un programator să-l vadă de la început cum trebuie dezvoltat.

Lewis spune că, având in vedere rezultatele ar trebui sa avem mai mare încredere în oameni atunci când estimăm timpul necesar proiectelor. “O buna estimare..necesita experiență și judecată. Industria programării trebuie sa prețuiască experiența umană, intuiția și întelepciunea.5

2. Metode de estimare tradiționale

2.1 Relația dintre metodele de estimare și metricile soft

Măsurarea celor trei parametri (cost/efort, durata, produs) nu ne conduce direct la estimări mai bune. Chiar dacă cunoaștem productivitatea, raportul mediu al efortului, raportul dintre produs și timp, nu putem oferi valori rezonabile pentru parametri înainte să fie efectuată, cel puțin o dată, o estimare. Prima idee despre estimare este că ea pre-construiește un model al produsului final. O dată ce avem modelul, putem să-i masurăm parametrii: efortul și timpul necesar modelării lui. A doua idee este că trebuie facută apoi o corelare între parametrii procesului de premodelare și cei ai procesului de producție, în speranța că primii îi vor prezice pe ceilalți. Aceste idei nu sunt restricționate la ingineria soft și nici măcar nu își au originea aici, ele provenind din domeniile tradiționale a ingineriei cum ar fi arhitectura, constructia de nave si de mașini. Cel mai proeminent exemplu pentru estimarea rațională sunt planurile făcute de arhitecți înainte ca o casă să fie construită. Nu numai că planurile servesc ca și specificație pentru ceea ce va fi construit dar, lucru important pentru obiectivul nostru, ele servesc și ca un model predictiv pentru costul și timpul procesului de producție. Această estimare este realizată prin: măsurarea volumului clădirii, multiplicarea acestei valori cu alți factori (de obicei publicați de asociațiile arhitecților care le determină statistic) și adaptând valoarea rezultată la condițiile specifice ale proiectului.6

Estimarea bazată pe aceste trei puncte se numește estimare bazată pe masurări. Aceasta este singura abordare rațională a estimării. Ea este folosită explicit în modelul FP și implicit în COCOMO.

Modelele de estimare a proiectelor soft chiar dacă sunt încă departe de a fi foarte precise sunt sisteme complexe construite pe baza unor analize solide a mai multor proiecte încheiate și considerate ca fiind reprezentative, care își fundamentează estimările referitoare la proiectele viitoare pe baza unor informații inițiale furnizate de cel care dorește evaluarea. Aproape toate metodele de evaluare soft solicită introducerea unor date de intrare referitoare la mărimea proiectului care se dorește a fi estimat, aceste date fiind ele însăși reprezentări numerice ale unor cantități de metrici soft.

În această lucrare ne vom referi la sistemele care folosesc metrici soft de bază (mărimea proiectului soft) pentru a furniza estimări referitoare la metrici soft complexe (efortul și durata necesară realizării produsului soft) ca fiind metode sau modele de estimare a softului. Aceste modele de estimare pot fi privite și ele la rândul lor ca fiind metrici soft deoarece scopul lor este acela de a dezvălui caracteristicile e singura abordare rațională a estimării. Ea este folosită explicit în modelul FP și implicit în COCOMO.

Modelele de estimare a proiectelor soft chiar dacă sunt încă departe de a fi foarte precise sunt sisteme complexe construite pe baza unor analize solide a mai multor proiecte încheiate și considerate ca fiind reprezentative, care își fundamentează estimările referitoare la proiectele viitoare pe baza unor informații inițiale furnizate de cel care dorește evaluarea. Aproape toate metodele de evaluare soft solicită introducerea unor date de intrare referitoare la mărimea proiectului care se dorește a fi estimat, aceste date fiind ele însăși reprezentări numerice ale unor cantități de metrici soft.

În această lucrare ne vom referi la sistemele care folosesc metrici soft de bază (mărimea proiectului soft) pentru a furniza estimări referitoare la metrici soft complexe (efortul și durata necesară realizării produsului soft) ca fiind metode sau modele de estimare a softului. Aceste modele de estimare pot fi privite și ele la rândul lor ca fiind metrici soft deoarece scopul lor este acela de a dezvălui caracteristicile proiectelor soft, deci într-o viziune mult simplificată ele au rolul de a ”măsura” produsele soft.

Evaluările proiectelor soft și modul de calculare a acestora de către modelele de estimare sunt dependente de datele de intrare, deci înainte de a prezenta metodele de estimare am considerat că ar fi potrivit să analizăm doua metrici care sunt folosite ca mijloc de cuantificare a mărimii produsului soft.

Modelul metric al liniilor de cod vede un sistem implementat ca fiind un set de linii de cod izolate. De obicei, dar nu întotdeauna, liniile de comentarii și liniile goale nu sunt considerate a fi linii de cod.

LOC (Line of Code) reprezintă pur și simplu cardinalitatea setului de linii de cod. Raportul dintre LOC si volumul de efort (persoană / zile) este o unitate de măsură a productivității destul de comună în procesele soft. Valori tipice pentru mijlocul anilor ’80 referitoare la COBOL erau de 5-10 LOC/PD. Înainte de implementare, estimarea LOC poate sluji ca ajutor pentru efortul de întreținere. Aspecte care nu pot fi surprinse de această metrică sunt: relațiile structurale dintre obiectele din aceeași categorie, distincția dintre perspectiva internă sau externă asupra obiectelor, distincția componentelor reutilizate din mediul de programare (limbaj și librării, componente de fereastră ). Prin urmare LOC nu poate cuprinde funcționalitatea unui sistem. Aceasta nu se datorează unor deficiențe structurale a paradigmei LOC ci datorită faptului că se adresează unui singur nivel soft, nivelul implementării. Aceasta previne ca măsura LOC să fie o bună măsură a productivității deoarece măsurarea doar a producției codului nu înseamnă măsurarea producției de funcții utilizabile. Timp de valabilitate: liniile de cod ale produsului final testat sunt stabilite doar după fazele de implementare și testare. LOC inițiale netestate pot fi obținute înainte de ciclurile de testare. Dar este depus un efort considerabil și înainte ca LOC să devină o entitate măsurabilă. Se poate face o estimare a eforturilor de întreținere și testare. Rigiditate: acesta este unul dintre aspectele cele mai slabe ale metricii LOC. Valorile LOC ale unui limbaj nu pot fi comparate direct cu cele ale altuia. Pentru sisteme eterogene este de aceea imposibil să se ofere o valoare semnificativă a mărimii folosind LOC și pentru că o singură linie de cod nu este egală cu exact un obiect lexical al limbajului (categorisirile sunt lăsate la îndemâna interpretării). Este de asemenea interpretabil dacă comentariile, semnele care marchează blocurile, etichetele, declarațiile trebuie considerate linii de cod. Mai mult, liniile de cod care conțin mai mult de o singură declarație lexicală este discutabil dacă să fie considerate mai mult decât o linie de cod. Pe baza acestor lucruri există numeroase ghiduri pentru dialecte si numărarea LOC. Pentru vechile limbaje cum ar fi Asamblare, Basic si Fortran, care sunt orientate linie (o declarație înseamnă o linie) paradigma LOC este bine situată. Un alt aspect slab al metricii LOC este că deoarece modelul este simplist si non rigid programatorii isteți pot genera linii de cod suplimentare pentru a mări productivitatea LOC/PD. Pe de altă parte atunci când se urmărește obținerea unei valori LOC, ca și funcționalitatea, programatorii pot produce cod ilizibil în care mai multe declarații sunt ingrămădite într-o singură linie. Măsurarea LOC presupune o simplă numărare și de aceea operațiile aritmetice și statisitce pot fi aplicate în siguranță. Măsura LOC poate fi aplicată la o singură linie, dar menținând o valoare constantă de 1 înseamnă că ignoră semantica liniei și complexitatea ei interioară. Pentru multe medii moderne de programare (mediile vizuale) o linie de cod nu este echivalentă cu o construcție a limbajului respectiv. Atunci când măsurăm părți de sisteme avem întotdeauna de a face cu probleme de interpretare a specificului limbajului. LOC este definită uniform pentru toate tipurile de linii de cod, LOC ignoră secvența din cadrul sistemului deoarece ea analizează sau vede liniile de cod în izolare. În practică LOC este folosită mai frecvent decât oricare altă metrică deoarece LOC este foarte ușor de măsurat. Ideea de linie de cod este de asemenea foarte intuitivă și ușor de înțeles, de aceea estimările pentru testare și întreținere ar trebui bazate pe măsurări LOC. Deoarece modelul LOC este puternic dependent de limbajul de programare și de interpretare atunci când este folosit pentru estimarea eforturilor timpurii de dezvoltare nu se poate obține ca și valoare în sine ci mai degrabă trebuie estimat (intuitiv sau rațional ) el insuși, de aceea nu contribuie substanțial la estimările inițiale. Caracterul sau intuitiv și usor accesibil îl poate face să fie utilizat cu succes ca și o metrică de bază pentru o varietate de metrici.7

Sistemele continuă să crească în mărime și complexitate, ele devin din ce în ce mai greu de înțeles. Îmbunătățirile aduse instrumentelor de implementare permit dezvoltatorilor de programe să producă cantități mari de soft care întâmpină o nevoie în continuă creștere a utilizatorilor. Odată cu creșterea sistemelor trebuie folosită o metodă de a înțelege și comunica mărimea. Analiza punctelor funcționale este o tehnică care rezolvă această problemă, ea împarte sistemele în componente mici care pot fi analizate și înțelese mai bine.

2.2 Modelul COCOMO

Modelul de estimare COCOMO a fost dezvoltat de dr. Barry Boehm, prima sa ediție fiind publicată in 1981, numele sistemului este un acronim derivat din primele doua litere ale fiecarui cuvant din expresia Constructive Cost Model. Termenul de “constructiv” se referă la faptul că modelul ajută estimatorul să înțeleagă mai bine complexitățile muncii de evaluare și prin deschiderea sa permite estimatorului să înteleagă care sunt cauzele care influențează rezultatul final, respectiv estimările produselor soft (să cunoască exact de ce modelul produce estimările pe care le produce).

COCOMO nu este un model patentat și este descris de Boehm in cartea sa “Software Engineering Economics”. Deși sunt multe versiuni sofisticate disponibile pe piață, pentru a executa calculele acestui model de estimare este nevoie doar de un simplu calculator care dispune de funcția exponențială. O versiune imbunătățită a acestui model a fost folosită de U.S. Air Force de la sfârșitul anilor ’80 până în mijlocul anilor ’90. De-a lungul anilor Boehm a făcut revizuiri substanțiale asupra modelului COCOMO, aceste modificări culminând cu lansarea in 1996 a modelului COCOMO II.

COCOMO conține trei nivele de estimare (de bază, intermediar si detaliat), fiecare din ele asigurând în mod progresiv estimări mai precise datorită acurateții crescânde a datelor de intrare necesare. Fiecare nivel are la randul său trei tipuri de modele (organic, detașat, înrădăcinat), prin intermediul cărora se permit caracteristicilor proprii proiectului studiat să influențeze procesul de estimare.

Nivelul de bază constă în trei modele simple cu un singur parametru în ecuațiile efortului și duratei. Ecuația efortului leagă om – luni (MM) de numărul de mii de instrucțiuni sursă livrată (KDSI), ecuația duratei relaționează timpul necesar (in luni, M) de MM, care sunt calculate de ecuația efortului.

În cadrul nivelului de bază modelele sunt organizate in felul următor: modelul organic este pentru proiecte care au o echipă de dezvoltare redusă numeric și experimentată și care dezvoltă aplicații obișnuite într-un mediu bine cunoscut, modelul înrădăcinat este pentru proiecte mari și în special atunci când proiectul este nefamiliar sau sunt constrângeri severe de timp, modelul semi-detașat este pentru proiecte care au atributele situate undeva între cele două prezentate mai sus.

figura 2.2.1

Efortul este prezentat în persoană-luni, marimea este estimată în KSLOC (mii de linii de cod), timpul este estimat în luni.

COCOMO intermediar conține ecuații nominale care sunt similare ecuațiilor modelului de bază (mai puțin coeficienții pentru efort care sunt diferiți), cu excepția faptului că conține 15 coeficienți care ajustează rezultatele ecuațiilor nominale pentru a reflecta atributele unice ale produsului.

Nivelul intermediar se bazează pe relații între ecuația 1 și ecuația 2:

Ecuația 1: efortul dezvoltării este relaționat la mărimea sistemului

MM=aKDSI b

Ecuația 2: efortul și timpul dezvoltării

TDEV=cMMd

unde variabilele folosite au următoarea semnificație:

MM-efortul în om-luni

KDSI-numărul de mii de instrucțiuni sursa livrată

TDEV-timpul dezvoltării

Coeficienții a, b, c, d sunt dependenți de alegerea unuia dintre modurile de dezvoltare:

organic, pentru proiectele care implică echipe mici care lucrează în medii familiare și stabile (de exemplu sisteme de gestiune economică), semi-detașat, care ilustrează o mixtură de experiență în cadrul echipei proiectului (de exemplu sisteme bancare interactive), înrădăcinat, pentru proiecte care sunt dezvoltate sub constrângeri stricte, inovatoare, complexe și care au un grad înalt de volatilitate a cerințelor (de exemplu sisteme de control a unui reactor nuclear).8

Coeficienții a,b,c,d, corespunzători nivelului intermediar și celor trei modele conținute de acesta, sunt cei din tabelul de mai jos:

figura 2.2.2

Cele 15 atribute adiționale pot fi clasificate în următoarele 4 categorii:

atribute ale produsului, descrie mediul în care programul operează. Atributele din această categorie sunt: cerințele de siguranță in exploatare (RELY), mărimea bazei de date (DATA ) și complexitatea produsului (CPLX)

atributele calculatorului, descrie relația dintre produsul software și sistemul hardware pe care acesta este dezvoltat. Atribute: constrângerea timpului execuției (TIME), constrângerile de stocare principale (STORE), volatilitatea mașinii virtuale (VIRT), timpul de execuție al calculatorului (TURN).

Atributele de personal descriu priceperea și experiența personalului repartizat proiectului. Atributele: capacitatea de analizare (ACAP), experiența în aplicații (AEXP), capacitatea de programare (PCAP), experiența limbajului de programare (LEXP), experiența mașinii virtuale (VEXP).

Atributele proiectului descrie aspectele managementului proiectului. Atribute: utlizarea practicilor moderne de programare (MODP), utilizarea instrumentelor software (TOOL), graficul, schema necesară dezvoltării (SCED).

Acestor coeficienți li se atribuie valori de la “foarte slab” până la “extraordinar de mare”. De exemplu factorul de siguranță în exploatare (RELY) va fi calificat ca fiind “foarte slab” dacă o eroare a sistemului software va produce o neplăcere neînsemnată, “nominal” dacă eroarea va avea ca rezultat pierderi moderate recuperabile și “foarte înalt” dacă este posibilă pierderea de vieți omenești. De remarcat că toate atributele “nominale” nu vor avea nici un efect asupra estimărilor.

Coeficienții atribuiți celor 15 atribute sunt multiplicați pentru a se obține factorul de ajustare a efortului (EAF). Apoi, MM din ecuația nominală este înmulțită cu EAF pentru a se calcula MM necesar pentru produsul soft.

De exemplu presupunem că avem un program de tipul înrădăcinat de mărime 20 KDSI. Ecuația nominală înrădăcinată va fi MM=2.8(20) 1.20, care va avea rezultat 102 MM. Să presupunem apoi că toate atributele sunt evaluate la nivelul nominal cu excepția siguranței (RELY) care are atribuită caracterizarea de “foarte mare” și valoarea de 1.40.

P va fi atunci 1.40. Nivelul de efort calculat de COCOMO va fi atunci (102*1.4)=143 om-luni.

Durata (bazându-ne pe ecuațiile din tabelul prezentat in figura 2.2.1 ) va fi M=2.5(143)0.32=12.2 luni.

Modelul detaliat ajustează coeficienții pentru fiecare fază din ciclul de viață al produsului soft. Toate nivelele iau în considerare fazele din ciclul de viață al produsului dezvoltate anterior, ele permit ajustarea KDSI în cazul utilizării de soft modificat și reutilizat.

Intrările COCOMO

Cele mai importante probleme în utilizarea COCOMO sunt estimarea precisă a mărimii softului și atribuirea unor calificative potrivite celor 15 atribute.

COCOMO poate trata reutilizarea softului existent în noul proiect a prin adaptarea mărimii (KDSI) softului care trebuie măsurat. Ecuația este EDSI=ADSI(AAF/100), unde:

EDSI = echivalentul numărului de instrucțiuni sursă

ADSI = numărul de instrucțiuni care trebuie adaptate (modificate sau reutilizate) de la softul existent pentru utilizarea lor în noul proiect

AAF = factorul de ajustare a adaptării. AAF = 0.40(DM)+0.30(CM)+0.30(IM). Este posibil ca DM, CM sau IM sa depășească procentul de 100% indicând astfel că efortul necesar reutilizării softului poate fi mai mare decât cel al dezvoltării unui nou program.

DM = procentul de design software adaptat care va fi modificat

CM = procentul de cod software adaptat care va fi modificat

IM = procentul de efort necesar pentru integrarea softului adaptat în produsul final și testarea sistemului rezultat.

Pașii in producerea unei estimări folosind modelul COCOMO sunt:

identificarea modului de dezvoltare a noului proiect

estimarea mărimii proiectului în KDSI pentru a obține o predicție de efort

ajustarea celor 15 drivere de cost pentru a reflecta particularitățile proiectului, producerea unui factor de ajustare a erorii

calcularea estimării efortului proiectului folosind ecuația 1 si EAF

estimarea duratei proiectului folosind ecuația 2

Ieșirile COCOMO

Sunt MM pentru proiectul estimat și durata în luni.

In urma unor testări intensive s-a ajuns la concluzia că acuratețea estimărilor modelului COCOMO sunt într-o marjă de eroare de ± 200% în 60% din cazuri pentru nivelul de bază, pentru nivelul intermediar ± 20% în 68% din cazuri și ± 20% în 70% din cazuri pentru nivelul detaliat.

Dezavantajele modelului sunt ilustrate de faptul că este greu de estimat cu acuratețe KDSI în fazele inițiale ale proiectului, când sunt cerute cele mai multe estimări ale efortului, sistemul este extrem de vulnerabil la o clasificare greșită a modului de dezvoltare, succesul depinde în mare măsură de ajustarea modelului la nevoile organizației folosind date istorice (ale proiectelor anterioare) care nu sunt întotdeauna disponibile.

Aprecierile de care se bucură COCOMO sunt bazate pe faptul că este transparent, se poate vedea cum lucrează spre deosebire de alte modele cum ar fi SLIM, driverele sunt deosebit de folositoare estimatorului pentru a înțelege impactul diferiților factori care afectează proiectul.9

2.3 Modelul lui Albrecht: Puncte funcționale (FP)

Modelul FP a fost dezvoltat de Allan J Albrecht la mijlocul anilor 70’ ca și o încercare de a depăsi dificultățile asociate cu liniile de cod ca metodă de măsurare a marimii softului, și de a sprijini dezvoltarea unui mecanism pentru prezicerea efortului asociat dezvoltarii software.

Modelul se diferențiază fundamental de celelalte metrici deoarece măsurarea mărimii proiectului software nu se adresează nivelului de implementare ci nivelului de analiză sau de cereri ale clientului. Metoda a fost publicată prima data in 1973, și apoi în 1983. In 1984 Albrecht perfecționează metoda, în 1986 se înființează IFPUG (Grupul International al Utilizatorilor Punctelor Funcționale), care elaborează mai multe versiuni.

Modelul FP presupune parcurgerea următorilor pași:

a) Punctele functionale sunt numărate pe baza următorului concept fundamental al sistemelor: pe de o parte există structuri de baze de date și pe de cealaltă parte funcții care accesează aceste structuri cu ajutorul a patru operații de bază: (CRUD) creare, citire, update, ștergere. Amândouă parțile (bazele de date si funcțiile) primesc puncte (pe baza unor studii anterioare) pentru fiecare element și accesare conform unei evaluări a complexității (simplă, medie, complexă) asociată elementului (de exemplu crearea accesului la o dată complexă primește 6 FP). În cazul în care sistemul avut în vedere face mai mult sau mai puțin decât CRUD se oferă un set limitat de factori de influență. Acești factori de influență sunt de asemenea bazați pe observații ale unor proiecte încheiate și modifică numărul punctelor functionale cu până la ± 30%.

b) Se accesează o bază de date empirică din care se iau factorii de aproximare adecvați situatiei, apoi se calculează o estimare a efortului inițial.

c) În final se adaptează efortul inițial la specificul proiectului, și aici sunt disponibile câteva ajustări, ele diferind de la unele modificări minore făcute de Albrecht însuși, la diferite versiuni de calculare oferite de IFPUG, sau la schimbări majore în modelele FPA MK II și Task Points, fundamentele de bază ale FP rămânând nemodificate.

Vom prezenta în continuare varianta originală FP elaborată de Albrecht în 1984 datorită răspândirii ei.10

Ca și o alternativă la problemele identificate cu SLOC, Albrecht a derivat o metodă de estimare măsurând funcționalitatea sistemului și nu mărimea sa. Abordarea propusă este de a identifica și număra numărul de funcții unice reprezentate de:11

intrări externe (procese în care datele circulă dinspre exterior spre interior; datele pot proveni fie din partea utilizatorului aplicației, fie de la o altă aplicație)

ieșiri externe (procese în care datele derivate circulă dinspre interior spre exterior; datele reprezintă rapoarte-mesaje sau sunt informații trimise altor aplicații)

interogări externe (procese care conțin componente atât de intrare cât și de ieșire; fluxul de ieșire nu conține date derivate)

(fiecare dintre acestea se execută asupra fisierului de aceea sunt numite tranzacții)

fișiere interfață externe (un grup de date relaționate logic folosite doar în scopuri de referință, datele sunt localizate în afara aplicației fiind întreținute de o altă aplicație)

fișiere logice interne (un grup identificabil de date relaționate logic localizate numai în cadrul aplicației)

(sunt locații unde datele sunt înmagazinate și combinate pentru a forma informații logice).

Fișierul este conceptul esențial al părții de date. Un fișier constă din mai multe elemente data pe care sistemul le recunoaște ca fiind date dinspre sau date spre orice alt sistem utilizator. Unele dintre aceste elemente data pot fi doar citite. Dacă toate elementele data dintr-un fisier pot fi doar citite întregul fișier este clasificat ca putând fi doar citit. Fișierele sunt clasificate în “ușoare, medii și complexe” conform numărului de elemente data lizibile și numărului de elemente data referențiale conținute. Acest model de data reprezintă o perspectivă a utilizatorului asupra informației pe care un sistem o poate stoca și/sau (re)produce.

Concentrându-se asupra documentului specificării cerințelor, estimatorul poate calcula funcționalitatea sistemului care trebuie dezvoltat prin identificarea tipurilor de funcții prezentate mai sus. Suma funcțiilor unice (UFC) este calculată ca fiind suma tuturor aparițiilor fiecărei funcții, fiecare apariție fiind multiplicată cu un coeficient care reflectă complexitatea trăsăturii care este calculată. Albrecht clasifică acești coeficienți astfel:12

figura 2.3.1

Problema neadaptată este apoi ajustată prin măsurarea ei în relație cu 14 factori de complexitate a proiectului, aceștia fiind:

comunicarea de date: câte facilități de comunicare trebuie adăugate pentru transferul sau schimbul de informații cu aplicația;

procesarea de date distribuite: cum sunt datele distribuite și funcțiile de procesare tratate;

performanța: există un timp de răspuns sau rezultat inpus de către utilizator;

utilizarea configurației: cât de mult solicită aplicația platforma hardware pe care va fi executată;

rata tranzacției: cât de frecvent sunt executate tranzacții (zilnic, săptămânal, lunar);

intrări de date on-line: care este procentul informației introdusă on-line;

eficiența utilizator-final: este aplicația proiectată pentru a fi eficientă pentru utlizatorul-final;

modificări on-line: câte fișiere logice interne sunt modificate de tranzacțiile on-line;

procesări complexe: conține aplicația procesări matematice sau logice extinse?

reutilizare: este aplicația dezvoltată pentru a satisface o singură nevoie a utilizatorului sau mai multe?

ușurința instalării: cât de dificilă este instalarea;

ușurința operațională: cât de eficace și/sau automatizate sunt procedurile de lansare, salvare și recuperare;

localizări multiple: este aplicația proiectată și dezvoltată pentru a fi instalată în mai multe locuri și pentru mai multe organizații?

faclitarea schimbării: este aplicația proiectată și dezvoltată pentru a ușura schimbările?

Fiecare factor de complexitate a proiectului este evaluat pe baza gradului său de influență, care variază de la 0 (nici o influență) până la 5 (foarte influent). Totalul factorilor de complexitate (TCF) poate fi calculat cu formula:

TCF=0.65+(suma coeficienților factorilor)/100

TCF poate lua o valoare în domeniul 0.65-1.35 deoarece valoarea 0.65 va rezulta dacă toți factorii de complexitate nu au nici o influență, valoarea 1.35 va indica că toți factorii de complexitate au o influență semnificativă. De aceea dacă din documentul specificării cerințelor va rezulta că sistemul este relativ simplu, cu un singur procesor și fără constrângeri de performanță, TCF va fi <1 deoarece majoritatea factorilor de complexitate vor avea o influență minimă. Pe de altă parte dacă sistemul trebuie dezvoltat ca un sistem distribuit și performanța este o cerință cheie atunci este probabil ca suma factorilor de complexitate să conducă la un TCF >1.

Dupa obținerea UFC și TCF, punctele funcționale (FP) pot fi calculate astfel:

FP = UFC * TCF

Modelul estimează efortul necesar dezvoltării proiectului software în unităti om-zile după următoarea formulă:

Efortul = 0.6*FP + 0.001*FP2

care a fost stabilită pe baza a numeroase proiecte studiate, estimându-se o marjă de eroare a formulei de ± 15%.

Formula de mai sus a estimării efortului este relativă deoarece evaluarea termenului necesar realizării unui proiect depinde de mediul în care acesta este dezvoltat. De exemplu, în mediul COBOL durata medie de implementare a unei funcții punct este între 4 și 12 funcții pe lună în timp ce pentru aplicațiile dezvoltate într-un mediu GUI rata productivității poate fi până la 20 de ori mai mare.

Printre avantajele modelului se numără faptul că datele necesare sunt disponibile de timpuriu în proiect, tot ce este nevoie este o specificație detaliată, modelul este independent de limbaj și unitatea folosită pentru estimarea mărimii proiectului este mai precisă decât estimările care au la baza SLOC.

Dezavantajele nu sunt puține și constau în subiectivitatea evaluării (într-un studiu

s-a ajuns la concluzia că există o variație de 30% între analiști în numărarea FP), modelul este greu de automatizat, se ignoră calitatea datelor de ieșire, orientarea către aplicații de tip tradițional, terminologia de modă veche care nu permite interpretarea de concepte noi (refolosire, existența librăriilor și a altor componente pentru unele părti ale cerințelor formulate în model), limitarea lui la aplicații cu baze de date. 13

Un punct slab este absența rigidității. Nu putem să spunem că modelul de estimare FP este o măsură obiectivă care poate fi masurată automat, deoarece este necesară disponibilitatea specificării cerințelor. Conform lui Kemerer CF [Reliability of Function Points Measurement] aceasta conduce la o inclinație pentru intermodel și interevaluare. Interevaluarea se poate observa atunci cand diferiți evaluatori umani analizează același sistem fără a ajunge la consens. Înclinația intermodel este introdusă de definițiile formale slabe ale entităților modelului, cum ar fi “fișier”, “element data”, “funcția utilizator”, fiind lăsată o libertate prea mare pentru interpretare.

Terminologia depășită și factorii nenecesari fac ca aceasta metrică să fie greu de folosit în mediile moderne, în plus este reproșată disponibilitatea relativ târzie (aproximativ 15% din efort este deja consumat) a modelului. Rezultate bune ale estimării folosind acest model pot fi obtinute doar când sistemele sunt modelate cu aceeași metodă și masurate de aceeași persoană.

2.4 Modelul PRICE S

Modelul comercial PRICE S a fost dezvoltat de Price Systems, modelul este parțial patentat, fapt pentru care producătorul are drepturi de proprietate aproape complete asupra lui lucru reflectat și prin aceea că nu toate ecuațiile pe care se bazează modelul sunt publicate, deși multe dintre ele sunt descrise în manualul de utilizare. Modelul este aplicabil la toate tipurile de proiecte software și ia în considerare toate ciclurile de viață al produsului soft.

Intrările PRICE S

Datele de intrare sunt grupate în următoarele nouă categorii:

mărimea proiectului: reflectă mărimea proiectului care urmează a fi dezvoltat, mărimea poate fi introdusă în mărimi ca și SLOC, elemente funcție sau elemente obiect;

aplicația programului APPL: asigură o măsură pentru tipurile de soft descrise de una dintre următoarele categorii: matematic, manipulare de stringuri, stocare și recuperare de date, on-line, în timp real, interactiv sau sistem de operare;

factorul de productivitate PROFAC: este un parametru de calibrare care leagă programul soft de productivitatea și eficiența personalului și practicilor manageriale;

inventarul designului: furnizează volumul de soft disponibil pentru utilizare (reutilizare), doi parametri: design nou (NEWD) și cod nou (NEWC) indică gradul de noutate pentru fiecare tip soft;

utilizarea UTIL reflectă măsura de solicitare a procesorului relativ la viteza și capacitatea memoriei, valori peste 50% presupun de obicei creșterea efortului;

specificațiile clientului și siguranța cerințelor: parametrul de platformă PLTFM furnizează o măsură pentru gradul de testare și documentare care va fi necesar;

mediul de dezvoltare: trei parametri de complexitate CPLX1, CPLX2 și CPLXM măsoară calitățile unice ale proiectului cum ar fi volatilitatea cerințelor, utlizarea de instrumente (de exemplu CASE), dezvoltarea proiectului în mai multe locații și alți factori;

clasificarea dificultății pentru integrare internă INTEGI și externă INTEGE;

procesul dezvoltării: reflectă procesul care este utilizat;

Posibilitățile include dezvoltarea în cascadă, spirală, evoluționară, incrementală.

În plus există date de intrare specifice activităților de suport software.

Procesarea PRICE S

Modelul calculează volumul de soft(VOL) bazându-se pe mărimea produsului și APPL. Folosește apoi VOL și PROFAC pentru a determina o estimare inițială a efortului dezvoltării în muncă ore (LH). Ecuația este :

LH = [ E PROFAC ] [VOL f(PROFAC)]/ 1000

Modelul ajustează această estimare cu ajutorul parametrului PLATFM care are un efect liniar asupra lui LH. Celelalte date de intrare sunt folosite pentru reglări suplimentare a acestei estimări și pentru calcularea duratei necesare dezvoltării proiectului.

Datele de ieșire PRICE S

Modelul calculează estimarea efortului în persoană-luni care poate fi convertit dacă se dorește în cost monedă. Efortul este repartizat între trei etape de dezvoltare soft: design, codificare și testare. Efortul este de asemenea divizat în cinci activități: ingineria sistemelor, programare, configurare și controlul calității, documentație și managementul programului. PRICE S calculează de asemenea durata dezvoltării în luni și furnizează o opțiune care compară durata introdusă de către estimator cu cea calculată de către model. Această opțiune arată de asemenea penalizările pentru comprimarea duratei de către utilizator comparativ cu durata estimată de către model.14

2.5 Modelul SLIM

Modelul SLIM (Software Life Cycle Management) este un “model de estimare macro” automat pentru estimare soft bazat pe funcția Norden/Rayleigh. SLIM folosește programarea liniara, simularea statistică, evaluarea programului și tehnici generale pentru a deriva estimările soft. SLIM pune la dispoziția unui estimator următoarele funcții:

calibrare – o ajustare fină a modelului pentru a reprezenta mediul de dezvoltare soft local prin interpretarea unei baze de date care conține informații referitoare la proiectele anterioare;

structura – un model de informație al sistemului soft, care colectează caracteristicile soft, atributele personalului, atributele calculatorului

dimensionarea soft: SLIM folosește o versiune automată de tehnica a costului care folosește liniile de cod.

Modelul SLIM se bazează pe analiza lui Putman asupra ciclurilor de viată soft în termenii distribuției Raleigh a nivelului personalului proiectului contra timp.

Algoritmul folosit este: k=(marime/(CC* t 4/3))3

Mărimea este în linii de cod, k este efortul total al ciclului de viată (în ani lucrători),

t este durata dezvoltării (in ani). C este o constanta tehnologică care combină efectul folosirii instrumentelor, limbajelor, metodologiilor și procedurilor. Valoarea constantei tehnologice poate varia de la 610 la 57 314. Pentru utilizarea modelului SLIM mărimea proiectului trebuie identificată în avans. Un studiu efectuat de PENGELLY indică că SLIM nu are rezultate corecte, precise pentru proiectele mici, dar LONDIEX afirma în urma studiilor că SLIM este adecvat pentru dezvoltările soft care îndeplinesc următoarele criterii: mărimea softului este mai mare de 5 000 de linii, efortul este mai mare decât 1.5 om-ani, timpul dezvoltării mai mare de 6 luni.

Dezavantaje:

estimările SLIM sunt extrem de sensibile la factorul tehnologic;

nu este indicat pentru proiectele mici;

Avantaje:

folosește programarea liniară pentru a lua în considerare constrângerile de dezvoltare atât asupra costului cât și asupra efortului.15

2.6 COCOMO II

COCOMO II a fost dezvoltat la mijlocul anilor ’90 de un consorțiu de organizații conduse de dr Barry Boehm și de câțiva absolvenți ai University of Southern California (USC). Scopul COCOMO II era “dezvoltarea unui model de estimare a costurilor și a duratei proiectelor soft adaptat la practicile ciclurilor de viață ale anilor ’90 și 2000, pentru aceasta el a fost calibrat pe baza unor proiecte reale desfășurate și colectate din domeniul comercial, aerospațial, guvernamental și ale organizațiilor non-profit.

Spre deosebire de COCOMO, COCOMO II este mult mai compatibil cu metodologiile de design soft curente (de exemplu tehnicile orientate obiect), noul model include și o nouă bază de date formată din date oferite de membrii consorțiului.

COCOMO II cuprinde trei etape de estimare: prima etapă, numită structura aplicației suportă prototipul sau efortul structurii aplicației și folosește elemente obiect ca și unitate de măsură a mărimii, etapa a doua intitulată designul timpuriu oferă suport estimării de-a lungul fazelor de design inițiale ale proiectului și folosește elemente funcție sau mii de linii sursă de cod (KSLOC) ca și metrici de mărime. În plus folosește șapte atribute care sunt bazate pe combinații ale atributelor identificate mai jos; etapa a treia numită post arhitectura oferă estimările ulterioare fazei designului timpuriu. Etapa a treia este de fapt o modificare a modelului COCOMO, astfel că vom reprezenta doar diferențele dintre COCOMO II și COCOMO.

Descrieri generale ale COCOMO II (etapa a treia)

Ecuațiile COCOMO II sunt revizuiri ale ecuațiilor modelului COCOMO. Aceste revizuiri se manifestă prin variabile exponențiale și tratarea diferită a reutlizării software.

Ecuația efortului este: PM = [A(mărimea’)B(EM)] + PMAT unde:

PM este efortul estimat în persoană- luni;

A este coeficientul care este setat provizoriu la 2.5 (valoarea inițială), dar trebuie calibrat pentru a reflecta cultura și costurile specifice organizației;

mărimea’ = mărimea (1+BRAK/100) unde BRAK este pierderea, sau procentajul de cod îndepărtat datorită volatilității cerințelor. De exemplu, mărimea este de 10.000 SLOC și 20% din cod a fost îndepărtat datorită volatilității cerințelor, echivalentul de 2000 instrucțiuni rezultă într-o setare a valorii BRAK la 20. Aceasta este folosită pentru a ajusta mărimea efectivă a proiectului la 12.000 de instrucțiuni.

B este o variabilă exponențială cu ecuația B = 0.91 + 0.01(SF), unde SF este suma unor factori care pot lua valori între 0 și 5. Cei cinci factori sunt precedența (PREC), flexibilitatea dezvoltării (FLEX), gradul de risc al deciziilor (RESL), gradul de coeziune al echipei (TEAM), maturitatea procesului (PMAT). La fel ca și coeficienții de efort din COCOMO, pot primi valori de la “foarte slab” până la “extraordinar de mare”. Pentru PREC, de exemplu, “foarte slab” corespunde “fără nici un precedent”, în timp ce “extraordinar de mare” corespunde la “foarte familiar”.

EM este produsul a 17 coeficienți de efort, similar celor folosiți în COCOMO intermediar.

PMAT este efortul pentru componentele interpretate automat.

Ecuația duratei are o variabilă exponențială și este următoarea:

M = [ 3.0 * PM (0.33+0.2(B-0.91)) ] (SCED%/100), unde

PM = persoană-luni al efortului estimat

SCED% = procentajul de comprimare sau expansiune a duratei. Așa cum am amintit COCOMO II tratează reutilizarea codului în mod diferențial. Ecuația reutilizării ia în considerare faptul că un anumit grad de efort este necesar pentru aceasta, indiferent de mărimea codului care este modificat.

AAM (coeficientul de ajustare al adaptării ) = (AAF + AA + SU + UNFM)/100, unde

AAF = factorul de ajustare al adaptării, AAF= 0.40(DM) + 0.30(CM) = 0.30(IM), este posibil ca DM, CM și IM să depășească 100% indicând astfel că efortul pentru reutilizare poate fi mai mare decât cel necesar dezvoltării unui nou program.

AA = gradul de estimare și asimilare pentru a determina oportunitatea refolosirii și integrarea softului reutilizat în produs.

SU = cantitatea de pricepere software necesară;

UNFM = gradul de nefamiliarizare a programatorului cu software-ul;

COCOMO II – Intrări (etapa a treia)

Pentru etapa a treia, mărimea exprimată în KSLOC constituie principala dată de intrare, în plus există 17 coeficienți de efort, acești parametri diferențiază doua produse soft cu aceeași mărime dar cu procese , produse patforme si personal diferite. Cei mai mulți sunt similari celor folosiți în COCOMO intermediar, cu excepția noilor coeficienți pentru cerințele reutilizării (RUSE), cerințele documentării (DOCU), continuitatea personalului (PCON), dezvoltarea în locații multiple (SITE), volatilitatea platformei (PVOL) din COCOMO II înlocuiește coeficientul VIRT din COCOMO iar experiența în platformă (PEXP) și experiența în instrumente și limbaj (LTEX) înlocuiesc LEXP și VEXP. COCOMO II nu mai folosește doi dintre coeficienții modelului original: MDOP și TURN.

COCOMO II – Intrări (etapa a doua)

Pentru etapa a doua, mărimea exprimată în puncte funcționale este principala dată de intrare, modelul convertește elementele funcției în KSLOC folosind o tabelă de limbaj. Pe lângă aceasta mai există șapte coeficienți care sunt fie reproduceri, fie combinații ale unor coeficienți din etapa a treia amintită mai sus. Aceste atribute sunt:

– siguranța și complexitatea produsului RCPX, RCPX este o combinație a coeficienților RELY, CPLX, DATA și DOCU;

– dificultatea platformei PDIF, este o combinație a TIME, STORE, PVOL;

– capacitatea personalului PERS, este o combinație a ACAP, PCAP, PCO;

– experiența personală PREX, este o combinație între AEXP, PEXP și LTEX;

– reutilizarea necesară (RUSE) și graficul necesar dezvoltării SCED sunt aceleași atribute ca și în etapa a treia;

– facilități (FCIL), este o combinație între TOOL și SITE;

COCOMO II – Intrări (prima etapa)

Datele de intrare includ elementele obiect și nivelul productivității (PROD). PROD este o măsură a capacității și experienței dezvoltatorului cu instrumente CASE și are atribuită o valoare între 4 și 50, 4 fiind cel mai înalt nivel al experienței și 50 reflectând cel mai inferior nivel.

COCOMO II – Procesare

La fel ca și în COCOMO principalele probleme ale utilizatorului constau în determinarea mărimii proiectului și în atribuirea unor valori coeficienților. Pentru etapa întâi modelul folosește o ecuație simplă:

PM = NOP/PROD, unde

NOP = noile obiecte element;

PROD = rata productivității;

Determinarea NOP și PROD poate fi o problemă dificilă.

În prezent etapa a treia a fost automatizată în modelul USC COCOMO II, lucrându-se la aceasta și pentru etapele unu și doi, munca utilizatorului fiind mult ușurată.

Datele de ieșire pentru etapele doi și trei sunt efortul în persoană-luni și durata proiectului soft în luni, pentru etapa întâi singura dată de ieșire disponibilă este efortul. COCOMO II oferă o estimare în termeni optimisti dar cel mai probabil și estimări pesimiste.

Implementarea din 1997, cu 83 de puncte de dat,e a fost precisă în estimările referitoare la efort cu o marjă de eroare de 20% în 46% din cazuri, iar în estimările referitoare la durata proiectului cu o marjă de eroare de 20% in 48% din cazuri.

Versiunea din 1998, cu 161 de puncte de date, a demonstrat o acuratete cu o marjă de eroare de 30% în 75% din cazuri pentru estimarea efortului și cu o marjă de 30% în 72% din cazuri pentru estimarea duratei proiectului soft. 16

Caracteristici COCOMO II:

modelul a fost îmbunătățit de-a lungul anilor;

estimările parametrilor sunt subiective și dificil de estimat corect;

promite să fie flexibil pentru noile tehnologii;

3. Metode de estimare recente

3.1 Soluția experților

Majoritatea muncii de cercetare depusă în domeniul estimării soft este dedicată modelelor algoritmice. Totuși, în foarte multe dintre cazuri este utilizat modelul care se bazează pe judecata experților. Un studiu olandez a arătat că mai mult de 62% din organizații folosesc și această tehnică intuitivă. In forma ei cea mai bruta metoda expertizei specialiștilor implică consultarea cu unul sau mai multi experți locali care sunt specialiști în mediul de dezvoltare și în domeniul aplicației, pentru a estima efortul și durata necesară îndeplinirii proiectului soft. Metoda se bazeaza cu precădere pe experiența acestor specialiști în medii de dezvoltare similare, în proiecte încheiate și pe acuratețea acestor proiecte anterioare. Dacă este consultat mai mult de un expert este luată în considerare media estimărilor lor. Există riscuri evidente în folosirea acestor metode deoarece proiectul poate avea unele trăsături unice care pot conduce la prelungirea duratei de executare anticipate. În ciuda unei folosiri destul de răspândite metoda are reputatie slabă și este deseori privită ca fiind subiectivă și nestructurată, vulnerabilă în fața unor metode structurate.

Printre avantajele metodei se numără utilizarea experienței proiectelor anterioare pentru a estima factorii din noul proiect și adaptarea cu ușurintă la circumstanțele excepționale dar un dezavantaj major îl constituie dependența metodei de competența estimatorului.17

3.2 Abordarea Delphi

O formă structurată a metodei care se bazează pe judecata experților este

Abordarea Delphi. Această tehnică încearcă să adune opiniile unui grup de experți cu scopul de a produce o estimare echilibrată și precisă. Tehnica implică o procedură în mai multe etape, prezentată mai jos:

1) experții sunt informați de către coordonator cu privire la specificarea și forma estimării

2) se formează o comisie pentru a dezbate problemele referitoare la produs și estimare

3) experții elaborează estimări independente

4) evaluările individuale sunt folosite pentru a se calcula estimarea medie si apoi sunt restituite

5) se întruneste din nou comisia pentru a discuta rezultatele

6) experții pregătesc o estimare independenta revizuită

7) pașii 3-6 sunt repetați până când comisia de experți ajunge la un consens.

Un aspect pozitiv al metodei este acela că experții nu comunică estimările lor individuale precum și faptul că metoda elimină opiniile extreme, făcând estimarea echilibrată, evitându-se astfel o greșealâ care se întamplă deseori în multe alte tehnici de estimare. Discuțiile din cadrul grupului sunt deosebit de avantajoase deoarece garantează faptul ca nici un aspect al estimării nu este scapat din vedere.

Dezavantajele modelului sunt: este un consumator de timp (deoarece sunt mulți oameni implicați) și necesitatea ca grupul de specialiști să fie foarte experimentat.18

Rețele neurale

Performanțele slabe înregistrate de modelele de estimare statistice au fost puse în evidență. Inabilitatea lor de a manevra categoriile de date, lipsa de capacități, aptitudini raționale au cauzat creșterea numărului de studii care se concentrează asupra metodelor netradiționale, ultimele dintre acestea sunt tehnicile care pot fi grupate sub numele de “mașini care învață”.

Acest model se bazează pe un pionierat într-un domeniu nou care promite producerea unor estimări consistent corecte. Tehnica își propune ca sistemul să învețe efectiv cum să estimeze, pe baza setului de lecții format din proiecte încheiate. În teorie această abordare este mult mai robustă față de informațiile eronate ceea ce înseamnă că aceste tehnici sunt adecvate pentru estimarea proiectelor soft.

Rețeaua neurală este o tehnică din cadrul celor grupate sub numele de “mașini care învață”. Rețelele neurale sunt organizate pe nivele, fiecare constând din neuroni, sau elemente care procesează, care sunt interconectate. Neuronii calculează o sumă medie a intrărilor lor, generând o ieșire. Dacă suma depășește un anumit nivel, atunci se produce ieșirea (de exemplu se generează ieșirea 1 dacă suma este mai mare decât nivelul, sau 0 altfel ). Primul nivel se numește nivelul de intrare și conține neuroni care reprezintă setul de variabile de intrare. Nivelul de ieșire reprezintă o variabilă de ieșire care este efortul necesar îndeplinirii proiectului. Conexiunile dintre neuroni au intrări numerice asociate cu ele. Aceste intrări sunt inițial aleatorii dar sunt ajustate pe măsură ce neuronii învață din setul de proiecte efectuate anterior. Există mai multe variante ale metodei de învățare pentru a antrena rețelele neuronale dar paradigma propagării înapoi a devenit cel mai popular mecanism de învățare. Metoda back-prop lucrează prin măsurarea diferenței dintre ieșiri și a valorilor ieșirilor observate. Valorile calculate la nivelul de ieșire sunt propagate la nivelul anterior și sunt folosite pentru ajustarea influenței conexiunii. Unele studii au ajuns la concluzia că rețelele neurale pot depăși ca performanță modelele statisitice. Aceste rezultate au fost concluzia unui studiu care a folosit o rețea neurală multinivel și care a produs rezultate foarte precise, dar studiul a indicat că a fost nevoie în prealabil de o instruire vastă.

Conform rezultatelor obținute rețelele neurale sunt o abordare comparabilă dacă nu chiar mai bună decât modelele statistice, în plus ele pot face față la seturi de date eterogene, iar îmbunătățirea lor este posibilă datorită diversității de algoritmi de învățare din care se poate alege.

Slăbiciunile modelului constau în faptul că nu există o îndrumare clară despre cum să concepem rețelele neurale, de exemplu de câte nivele este nevoie pentru construirea unei rețele, acuratețea rezultatelor este strâns legată de mărimea antrenamentului (numărul de lecții), seturi mari de antrenament nu sunt întotdeauna disponibile, logica din spatele estimării este greu de explicat utilizatorului; metoda este ca și o cutie neagră, o dată date intrările trebuie acceptate, ieșirile generate.19

3.4 Sisteme logice fuzzy

Numai câteva publicații au arătat până acum utilizarea logicii fuzzy. Un sistem fuzzy implică desemnarea unui număr între 0 și 1 pentru variabilele introduse pentru a indica valoarea de adevăr, 1 reprezentând adevărul absolut. De exemplu putem spune că programul Y este mic și să-i atribuim o valoare de adevăr: la un nivel de 0.7. un sistem bazat pe reguli fuzzy poate fi apoi construit, bazându-ne pe variabila de adevăr de mai sus:

DACA programul Y mic (0.7) ATUNCI efortul dezvoltării= timp scurt (0.8)

Regula fuzzy de mai sus înseamnă că dacă valoarea de adevăr este mai mare decât 0.7 atunci regula va produce un timp scurt de dezvoltare cu o siguranță de 0.8. Pentru a face predicțiile mult mai sigure sunt necesare mai multe reguli fuzzy. Este de asemenea posibil sa clasificăm nivelul logicii evaluate mult mai aproape de setul de date. De exemplu daca știm că dezvoltarea va fi in jurul a 10 000 LOC atunci nivelul logicii evaluate poate fi de tipul: destul de mare, mare, foarte mare. Un exemplu de sistem logic fuzzy asigură valorile de adevăr pentru mărimea modelului data (30), numărul de ecrane (26) și mărimea modelului procesului (74). (vezi figura 3.4.1)

În acest exemplu au fost folosite trei nivele de logică: mic, mediu si mare. Funcția mărimii modelului datei indică o intersecție între mediu și mare astfel că valoarea de adevăr pentru amândouă nivele logice este de gradul 0.5. Funcția numărului de ferestre indică o intersecție între mic și mediu astfel că valoarea de adevăr pentru amândouă nivele logice este de gradul 0.5. Funcția finală, mărimea modelului procesului nu mai intersectează secțiunea mică și are valoarea de adevăr de 0.8. Valoarea de adevăr a fiecărei funcții este apoi folosită pentru crearea fundamentului legii fuzzy. Gradul de apartenență la fiecare categorie (mică, medie, mare) determină cât de multă influență să-i atribuim regulii fuzzy. Consecințele fiecărei reguli sunt apoi combinate pentru a produce o singură valoare de ieșire, în exemplul nostru 254 (nu toate legile sunt descrise în acest grafic).

Este greu să colectezi date pentru funcțiile multiple. Clasificând nivelele de valoare logică, care pot face sistemul mult mai precis, îngreunează menținerea gradului de semnificativitate deoarece este greu să diferențiezi între anumite nivele de valoare logică (destul de mare– mare). Metoda este dezavantajoasă pentru că solicită cunoașterea fiecărei etape. Avantajul acestui model îl constituie faptul că acesta este o tehnică foarte intuitivă și nu este nevoie de o antrenare formală. O altă utilizare a conceptului fuzzy este combinarea lui cu tehnologia rețelei neurale pentru a dezvolta sisteme neural-fuzzy hibride.20

figura 3.4.1

3.5 Raționamentul orientat pe caz

Este o metodă de a acumula, înmagazina observații despre proiectele anterioare. Un asemenea efort necesită implementarea proiectului, platforma de programare ș.a.m.d. Atunci când într-un proiect soft suntem confruntați cu o situație nouă este posibil să folosim cea mai apropiată observație înmagazinată.

figura 3.5.1

Studierea performanțelor sistemelor orientate pe caz a arătat rezultate încurajatoare. În urma unui experiment care urmărea compararea rezultatelor acestei metode cu modelele COCOMO și FP s-a ajuns la concluzia că solutiile furnizate de acest model sunt mai precise decât cele ale modelelor algoritmice și au fost foarte aproape de nivelul de expert. Deoarece sistemul folosește cazuri stocate este evident că o dată cu construirea observațiilor sistemul va avea o bază de cunoaștere mai extinsă cu care noile observații să poata fi comparată. Aceasta sugerează că sistemele de raționament orientate pe caz vor deveni în timp mai exacte decât experții, deoarece experții nu posedă capacitatea de a-și rechema toate experiențele anterioare și sunt potențial influențabili.

Slăbiciunile modelului ar fi acelea că datele necesare pot fi uneori greu de adunat și că estimările sunt limitate de cazurile care au fost observate anterior. Dintre beneficii amintim faptul că pentru utilizarea acestui model nu este necesară prezența unui expert, procesele care se desfăsoară sunt foarte asemănătoare cu gândirea umană, sistemul poate trata cazurile eșuate (acele cazuri pentru care nu a fost facută o predicție corectă).

Sistemele de raționament orientate pe caz se bazează în mod fundamental pe imitarea procesului prin care un expert ia decizii bazându-se pe experiența sa. Tehnica modelului este de aceea foarte similară cu tehnica de estimare soft analogică.21

3.6 Modelul analogic

Tehnica analogiei implică compararea unuia sau a mai multor proiecte executate într-un domeniu similar ca și mijloc de a produce noi estimări. Aceasta poate fi atinsă prin analizarea datelor colectate din aceste proiecte încheiate și compararea lor cu cele din noile proiecte, evaluând asemănările. Efortul dezvoltării este știut că este utilizat ca și bază pentru estimarea proiectului curent. Estimarea prin analogie pare corectă, dar sunt căteva probleme care trebuie tratate, de exemplu cum să determini trăsăturile proiectului? Acestea sunt restrânse la informația care este disponibilă la începutul procesului de estimare, exemplele putând include domeniul aplicației, procesul soft ș.a.m.d. O altă problemă este câte proiecte trebuie măsurate pentru a putea face comparații. Prea puține proiecte pot conduce la utilizarea unor proiecte neconforme, prea multe proiecte pot slăbi efectul celei mai apropiate analogii. Cu această metodă de estimare nevoia unui expert este eliminată, de aceea etapele care necesită o cunoaștere specială dispar deoarece sistemele analogice examinează probleme care au avut loc, spre deosebire de alte tehnici de estimare care trebuie să facă față la toate problemele posibile anticipate într-un proiect. Procesul implicat estimării soft poate fi divizat în următoarele etape: selecția analogiilor, evaluarea similarităților și a diferențelor, estimarea calității analogiei, considerațiile în cazurile speciale, crearea estimării.

Prima etapă a procesului constă în alcătuirea unei baze de date corespunzătoare proceselor încheiate din care vom măsura similaritățile comparativ cu noul nostru proiect. Procesul selecției implică de aceea alegerea proiectelor similare care reflectă atât mediul de dezvoltare cât și trăsăturile specifice noului proiect.

Dispunem acum de o bază de date adecvată, următoarea etapă constă în estimarea asemănărilor cu noul proiect, sunt determinate numărul de caracteristici dependente de datele disponibile.

Shepperd relatează seturi de date mergând de la o singura caracteristică a proiectului până la 29 de caracteristici, ca fiind utilizate în această etapă. Procesul selectării analogiilor poate fi obținut prin asemănările în spațiul n dimensional în care fiecare dimensiune corespunde unei trăsături a proiectului. Cele mai similare proiecte vor fi cele mai apropiate în spatiul n dimensional.

Pentru a determina calitatea analogiei executate putem aplica etaloane pentru estimarea calității predicției: eroarea absolută, procentajul de erori și media procentajului de erori, mărimea erorii relative (MRE) și media mărimii erorii relative (MMRE).

Rezultatele din măsurarea calității pot fi introduse înapoi în procesul analogiei pentru a examina de ce unele estimări sunt mai bune decât altele.

Câteodată nu trebuie să luăm în considerare unele proiecte. Deși proiectul a fost selectat în etapa a doua pentru similarități, acel proiect poate să aibă o trăsătură care se dorește a fi ignorată. De exemplu proiectul în cauză poate să fi folosit o metodologie de design neobișnuită.

Dezavantajele modelului constau în nevoia de detalii corecte, precise, cu privire la proiectele anterioare, lucru care nu este întotdeauna posibil, precum și în impunerea gradului de asemănare dintre proiectul real și cel din baza de date .

Trăsăturile pozitive ale modelului sunt reprezentate de faptul că folosirea acestuia nu presupune prezența unui expert, problema analizată este cea reală, spre deosebire de modelele algoritmice, sistemul este adaptiv deoarece putem adăuga noi proiecte.

Alte motive pentru a folosi analogia sunt rezultatele slabe obținute cu alte metode, faptul că poate trata date discontinue, abilitatea ei de a raționa. 22

Sisteme bazate pe reguli

Sistemele bazate pe reguli au fost utilizate în foarte puține cazuri de estimare a proiectelor soft. Acest model de sistem compară datele referitoare la noul proiect cu un set de reguli stocate. Cand se găsește o potrivire, legea se declanșează creând un efect în serie prin care oferă posibilitatea unei alte legi de a se declanșa. Procesul continuă până când nu mai sunt legi care pot fi declanșate, datele finale fiind prezentate utilizatorului.

figura 3.7

O lege tipica pentru un sistem bazat pe reguli este asemănătoare cu următoarea:

1. DACA mărimea_modulului > 100 SI mărimea_interfeței>5 ATUNCI

modulul_predispus_eroare

2. DACA modulul_predispus_eroare SI experiența_dezvoltator< 2 ATUNCI

necesară_reproiectarea

Dacă prima regulă de mai sus este declanșată, aceasta creează o noua stare a modulul_predispus_eroare. Noua circumstanță poate fi apoi utilizată ca și premiza pentru a doua regulă, creându-se astfel un efect în lanț.

Sistemele bazate pe reguli sunt în dezavantaj atunci când sunt comparate cu sistemele fuzzy deoarece nu este disponibil nici un grad de comparație pentru adevărul implicat, toate variabilele de intrare trebuind să aibă valoarea fie de fals, fie de adevărat.

Greutățile în utilizarea modelului provin din dificultatea de a deriva reguli, adevărul nu este scalabil, este greu de întreținut un asemenea sistem, în timp ce avantajul constă în simplitatea variabilelor de intrare.23

Arbori regresivi

Au fost câteva încercări de a folosi, în estimări, arborii de regresie, rezultatele obținute sunt comparabile cu cele ale modelelor cunoscute: COCOMO, SLIM. De aceea ei merită a fi menționați și trebuie luați în serios ca și o metoda de estimare soft.

–––––––––-desen––––––––––––––––––––-

Arborele regresiv este creat prin examinarea atributelor care pot clasifica datele și apoi un algoritm construiește arborele creând nodurile adecvate. Modelul este foarte simplu deoarece fiecare nod are doar doi fii, un format foarte utilizat, ușor de înțeles și de verificat pentru depistarea erorilor logice.

Totuși, dependența modelului de algoritmul folosit pentru construirea arborelui, imposibilitatea de a elimina o valoare în afara categoriei furnizată de datele de formare sunt aspecte care nu trebuie neglijate.

Avantajele sistemului constau în faptul că acesta poate fi ajustat pentru noi date, este ușor de înțeles și adecvat pentru variabile nenumerice.24

Sistemele neurale fuzzy hibride

Caracteristica modelului este aceea că datele de intrare într-o rețea neurală sunt transformate în valori de adevăr de către nivelul de intrare. Această abordare este un domeniu neexplorat în câmpul estimărilor. Teoria pe care se bazează sistemul afirmă că rețelele neurale vor primi astfel date de intrare mult mai semnificative și astfel se vor îmbunătăți datele de ieșire și calitatea estimărilor rețelei neurale. Un exemplu de astfel de sistem hibrid este prezentat mai jos:

figura 3.9

În acest sistem sunt două date de intrare (mărimea modelului de date și mărimea modelului procesului) cărora li se atribuie valori de adevăr în cadrul primului nivel. Datele de ieșire spre al doilea nivel reprezintă gradul de apartenență în fiecare logică evaluată (mic, mediu și mare) care poate conduce la nivelul de reguli în care acestea reprezintă valoarea datelor de intrare. Datele de ieșire din acest nivel indică dacă regula a declanșat un eveniment sau nu, determinând nivelul de activizare la ieșirea nivelului care reflectă starea. În final rezultatele sunt combinate pentru a oferi o singură estimare a duratei necesare dezvoltării.

Ca și rețelele neurale obișnuite, rețeaua învață dintr-un set de lecții, și o dată ce sistemul a fost antrenat este posibil să modifice reguli pentru a verifica acceptabilitatea. Aceasta este o trăsătură foarte importantă deoarece este astfel eliminată posibilitatea conform căreia rețeaua învață relații nedorite din noile date și poate ajunge astfel să neglijeze vechile relații din datele anterioare.

Avantajele țin de faptul că potențial sunt mai sigure decât rețelele neurale, există posibilitatea de îndepărtare a legilor inacceptabile și se pot reduce erorile datelor de intrare.

Problemele posibile sunt aceleași ca și la sistemele fuzzy, în plus poate apărea pericolul unor erori majore dacă se uită îndepărtarea unei reguli nedorite.

Viitorul modelului este încă incert deoarece face parte dintr-un domeniu relativ neexplorat, și până în prezent nu se cunosc evidențe reale ale succesului estimărilor sale.25

3.10 Rețelele bayesiene

Sunt o rețea grafică care are asociată o tabelă cu un set de probabilități. Nodurile reprezintă variabilele nesigure iar arcurile relațiile cauză/relevanță dintre variabile. Tabelele de probabilități pentru fiecare nod furnizează probabilitățile pentru fiecare stare a variabilei pentru acel nod. Pentru nodurile fără părinți acestea sunt probabilitățile marginale iar pentru cele cu părinți acestea sunt probabilitățile condiționale pentru fiecare combinație a valorilor stărilor părinților. Deși teoria care stă la baza modelului (probabilitățile bayesiene) sunt cunoscute de un timp îndelungat, construirea și executarea de modele de rețele bayesiene reale a fost posibilă datorită algoritmilor recenți și instrumentelor soft care i-au implementat. Modelul s-a dovedit folositor în aplicații practice cum ar fi diagnosticarea medicală sau cea a defectelor mecanice, cea mai recentă folosire a sa fiind de către Microsoft în “help wizards” din Microsoft Office. Tabelele de probabilități au fost construite folosind o mixtură de date empirice și de păreri ale experților.

În toate procesele de estimare soft se întâmplă ca la un anumit moment să existe date lipsă. Avantajul rețelei bayesiene este că ea va calcula probabilitatea fiecărei stări a fiecărei variabile, indiferent de volumul de informații.

figura 3.10

Fiecare din dreptunghiurile de mai sus reprezintă subrețele. De exemplu există o rețea preocupată cu mărimea problemei, care conține variabile ca și funcționalitate și complexitate. Problema mărimii influențează atât soluția mărimii cât și resursele necesare. Subrețelele care fac acest model atât de diferit față de abordările clasice sunt subrețelele care fac corespondența dintre resursele actuale și calitatea soluției. Ideea de bază este că resursele necesare pentru o problemă dată sunt întotdeauna un fel de ideal bazat pe cea mai buna practică. Ceea ce contează de fapt este cum aceste resurse ideale se relaționează la resursele reale disponibile. Această legatură este calculată în adecvarea resurselor efective și determină calitatea soluției. Un lucru crucial despre rezultatele oferite de rețelele bayesiene este că pot fi folosite ca răspuns la toate tipurile de probleme, chiar și la cele care nu pot fi tratate cu abordările tradiționale.

O provocare pentru toate metricile este aceea de a oferi rezultatele investigației lor la nivelul la care care pot fi utilizate de manageri fără sa fie necesar ca aceștia să înțeleagă fundamentul teologic al modelului. În cazul rețelei bayesiene managerii trebuie doar să înteleaga modelul cazual de bază pentru domeniul aplicației.

Dintre avantajele sistemului amintim: modelarea explicită a nesiguranței în calcule, ne oferă posibilitatea de combinare a diverselor tipuri de informații, face explicite acele presupoziții care erau înainte ascunse adăugând astfel vizibilitate și deschidere față de procesul luării deciziilor, formatul grafic intuitiv face mai ușor de înteles lanțul complex și aparent contradictoriu al deciziilor, abilitatea de a estima chiar și cu date lipsă, utilizarea tipului de analiză “dar-dacă?” și estimarea efectelor schimbărilor asupra procesului, semantica matematică, riguroasă, nu este necesară efectuarea calculelor bayesiene complexe deoarece există instrumente care fac aceasta.

Desigur că rețelele bayesiene nu pot rezolva, singure, toate problemele cantitative legate de deciziile manageriale, cărora metricile soft trebuie să li se adreseze. De aceea se propune o abordare care le combină cu MCDA (Multi-Criteria Decision Aid), care ajută în alegerea criteriilor financiare, de mediu, tehnice, politice, și cu ingineria soft empirică.26

4. Estimarea efortului pentru diferite aplicații utilizând Punctele Funcționale

Înainte de a trece la aplicarea modelului lui Albrecht pentru câteva aplicații consider că se impune clarificarea unui aspect important care poate influența decisiv estimarea.

O dată cu creșterea proiectului soft care trebuie dezvoltat, efortul necesar dezvoltării unei unități nu rămâne constant și aceasta deoarece o dată cu mărimea lui crește și complexitatea produsului, funcționalitatea lui, numărul de membri ai echipei devin astfel mai dificil de organizat. Putem vedea aceste lucruri și din următorul grafic:27

figura 4.1

Factorul care influențează cel mai mult productivitatea este mărimea proiectului. Este interesant de observat că aproape 75% dintre proiectele cu peste 8000 de puncte funcție eșuează și/sau sunt anulate.

În urma unui studiu efectuat pe parcursul a șapte ani au fost adunate informații de la 100 de companii implicate în dezvoltarea soft referitoare aproape la 1000 de proiecte. Pe baza lor s-a ajuns la elaborarea tabelului următor care poate fi un bun ghid pentru evaluarea efortului necesar dezvoltării unui produs soft.28

Datorită vastei colecții de informații pe care este fundamentat, consider tabelul de mai sus a fi reprezentativ în privința productivității proiectelor soft evaluate pe baza FP și prin urmare îl voi folosi în estimările referitoare la proiectele de mai jos.

4.1 Evidența notelor la o facultate

Se cere un program care creează, actualizează și exploatează:

un fișier conținând date despre studenții facultății (studenți.dat)

un fișier conținând date despre note obținute de studenți (note.dat)

un fișier conținând date despre cursurile facultății (cursuri.dat)

Datele caracteristice unui student ce vor fi reținute în fișierul studenți.dat sunt:

numărul matricol (unic pentru fiecare student)

numele (maxim 15 caractere)

prenumele (maxim 15 caractere)

codul grupei (întreg de forma xyz, unde x reprezintă secția căreia aparține grupa, y reprezintă anul din care face parte grupa, iar z identifică grupele în cadrul aceluiași an )

Datele reținute în fișierul note.dat vor avea structura:

numărul matricol al studentților care a obținut nota (întreg)

codul cursului la care a obținut nota (întreg, maxim 15 caractere)

nota obținută (întreg din intervalul [1,10])

Fișierul cursuri.dat va conține elemente cu următoarea structură:

codul cursului (întreg, unic în raport cu alte cursuri)

denumirea cursului (maxim 25 de caractere)

semestrul în care se predă cursul (întreg din intervalul [1..12])

(s-a presupus că facultatea poate avea 6 ani= 12 semestre)

Programul va putea afișa tabele cu note pentru:

o grupă specificată (specificarea se face prin codul grupei iar tabelul va conține informațiile pentru toți studentții din grupă pe parcursul tuturor sesiunilor anterioare )

un an specificat (specificarea constă într-un întreg din intervalul [1..65], iar tabelul va conține notele obținute de toți studenții din acel an pe parcursul tuturor sesiunilor anterioare )

un curs specificat (specificarea se va face prin codul cursului iar tabelul va conține notele obținute de toți studenții la acel curs )

un student specificat (specificarea se va face prin numărul matricol iar tabelul va conține notele obținute de student în toate sesiunile)

Programul va permite:

adăugarea de studenți în fișierul studenți.dat

ștergerea unui student cu număr matricol specificat din fișierul studenți.dat

modificarea codului grupei pentru un student cu număr matricol specificat (necesară la promovarea într-un nou an)

adăugarea unui set de informații (număr matricol, cod curs, notă obținută) în fișierul note.dat

modificarea notei obținute pentru un student cu număr matricol specificat la un curs specificat prin cod (modificare a fișierului note.dat)

adăugarea unui set de informații (cod curs, denumire curs, semestru) în fișierul cursuri.dat

ștergerea unui curs din fișierul cursuri.dat, curs specificat prin codul său

ștergerea tuturor informațiilor reținute în fișierul note.dat pentru un student specificat prin număr matricol (necesară după absolvire când facultatea nu mai are nevoie de datele respective în baza de date curentă)

În urma parcurgerii specificațiilor acestei probleme observăm că tranzacțiile conținute în această aplicație pot fi divizate în următoarele două categorii: tranzacții care operează asupra datelor conținute în cele trei fișiere (studenți.dat, cursuri.dat, note.dat), respectiv operațiile adaugă, șterge, modifică și tranzacții care returnează utilizatorului informații conținute în cele trei fișiere.

Între tranzacțiile din prima categorie le remarcăm pe acelea care adaugă date în fișiere, în continuare vom considera că aceste operații verifică existența fișierelor asupra cărora operează înainte de operația propriu-zisă de adăugare a datelor și în cazul în care acestea nu există le creează.

Observăm că din această categorie mai fac parte și următoarele operații: ștergerea unui student, modificarea codului grupei pentru un student, modificarea notei obținute de un student la un curs (fișierul note.dat), ștegerea unui curs din fișierul cursuri.dat, ștergerea înregistrărilor pentru un student din fișierul note.dat.

Deoarece tranzacțiile de mai sus sunt procese care conțin numai componente de intrare (informațiile introduse de utlizator) vom considera aceste operații ca fiind de tipul intrări externe și datorită complexității lor scăzute le vom clasifica ca fiind simple. Prin urmare pentru aceste tranzacții avem:

UFC (suma funcțiilor unice) = 3 * 8 = 24

Tranzacțiile din a doua categorie conțin atât componente de intrare (informațiile introduse de utilizator pe baza cărora se vor selecta datele din fișiere) cât și de ieșire (rezultatele interogării fișierelor), în plus interogările efectuate în cadrul lor sunt de o dificultate redusă, putem deci să le încadrăm ca aparținând interogărilor externe simple. Pentru acestea

UFC = 3 * 4 = 12

Suma funcțiilor unice (UFC) pentru această aplicație este: 24 + 12 = 36.

Datorită faptului că nu avem restricții referitoare la această aplicație vom considera factorii de complexitate a proiectului ca fiind 0 (nu influențează dezvoltarea aplicației).

TCF (totalul factorilor de complexitate) = 0.65 + 0/100 = 0.65

Punctele funcționale adiacente aplicației sunt deci:

FP = UFC * TCF = 36 * 0.65 = 23.4

Pe baza observațiilor referitoare la productivitatea proiectelor care au mărimea până la 50 FP s-a ajuns la concluzia că durata medie de implementare a unei funcții punct este de 1.3 ore. În cazul aplicației de mai sus estimăm timpul necesar dezvoltării la 23.4 * 1.3 = 30.4 ore.

4.2 Evidența colecției personale de CD-uri

Se cere un program care crează, actualizează și exploatează un fișier de informații despre CD-urile unei colecții personale (în final acesta va conține date reale pentru cel puțin 100 de CD-uri).

Pentru fiecare CD se va reține:

titlul CD-ului (maximum 50 de caractere);

autorul CD-ului (maximum 50 de caractere);

tipul CD-ului (audio sau soft- de tip char);

anul apariției și prețul în mii lei (doi întregi);

conținutul (redat prin cel mult 10 cuvinte cheie);

codul de inventar al CD-ului (p caractere)

În plus programul va putea tipări:

un tabel cu toate CD-urile din colecție și valoarea lor totală

un tabel cu toate CD-urile unui autor dat

un tabel cu toate CD-urile apărute între doi ani dați

un tabel cu toate CD-urile caracterizate prin n cuvinte cheie precizate, unde 1≤n≤20; se vor lista toate CD-urile care au cel puțin un cuvânt cheie dintre cele n cuvinte precizate.

Precondiții: La introducerea unui nou obiect CD vom avea următoarele precondiții:

titlul și autorul vor fi de tip string de maximum 50 de caractere

tipul CD-ului va fi un char ‘A’ sau ‘S’ simboluri pentru audio sau soft

anul apariției va fi un întreg pozitiv de patru cifre

prețul va fi un număr întreg pozitiv

conținutul va fi un String cu maximum10 cuvinte

codul de inventar va fi un string de exact 8 caractere și va fi distinct pentru fiecare CD din colecție.

Postcondiții:

pentru afișarea unui tabel cu toate CD-urile unui autor dat;

(CD ε lista ) Λ (CD.autor = autor.dat)

pentru afișarea CD-urilor apărute între an1 și an2;

(CD ε lista ) Λ (an1≤CD.an≤an2)

pentru afișarea întregii colecții și valoarea totală a CD-urilor;

CD[i] ε lista, i=1,lista.size() suma+=CD.preț

pentru afișarea unui tabel cu CD caracterizate prin n cuvinte cheie date. Se vor include în tabel CD-urile care conțin în unul din câmpuri cel puțin unul dintre cele n cuvinte introduce;

Funcționalitatea aplicației de mai sus constă în crearea fișierului de informații care conține colecția de CD-uri și tranzacțiile care returnează utilizatorului diverse informații referitoare la această colecție. Considerăm crearea fișierului ca fiind o intrare externă deoarece este un proces în care datele circulă dinspre exterior spre interior, și datorită complexității lui scăzute o considerăm ca fiind simplă. Interogările asupra colecției sunt interogări externe deoarece sunt procese care conțin atât componente de intrare (datele introduse de utlizator, adică criteriile după care se va căuta în colecția de CD-uri) cât și componente de ieșire (elementele selectate din fișier), iar dificultatea lor redusă ne permite să le încadrăm în categoria de complexitate simplă.

UFC = 3 * 1 (intrare externă) + 3 * 4 (interogări externe ) = 15

Datorită faptului că nu avem restricții referitoare la această aplicație vom considera factorii de complexitate a proiectului ca fiind 0 (nu influențează dezvoltarea aplicației).

TCF (totalul factorilor de complexitate) = 0.65 + 0/100 = 0.65

Punctele funcționale adiacente aplicației sunt deci:

FP = UFC * TCF = 15 * 0.65 = 9.75

Așa cum am observat durata medie de implementare a unei funcții punct este de 1.3 ore. În cazul aplicației de mai sus estimăm timpul necesar dezvoltării la 9.75 * 1.3 = 12.675 ore.

4.3 Evidența cheltuielilor casnice

Se cere un program care crează, actualizează și exploatează un fișier cu informații despre cheltuielile casnice ale unei familii (în final acesta va conține date reale pentru cel puțin 100 de cheltuieli).

Pentru o cheltuială se va reține:

categoria (ex: taxe, alimente, îmbrăcăminte, cosmetice etc )

numele persoanei care a făcut cheltuiala (cumpărătorul)

data cumpărării

valoarea cheltuielii

conținut (cel mult 10 cuvinte cheie, a maximum 10 caractere; exemplu: pâine, lapte, unt- categoria alimente)

numărul de inventar al cheltuielii

În plus programul va putea tipări:

un tabel cu toate cheltuielile și valoarea lor totală

un tabel cu toate cheltuielile făcute de un anume membru al familiei

un tabel cu toate cheltuielile prin n cuvinte cheie (1≤n≤10) care descriu conținutul; se vor lista toate cheltuielile care au cel puțin un cuvânt cheie în conținut

un tabel cu toate cheltuielile făcute între două date.

Precondiții: La adăugarea unor noi cheltuieli se vor avea în vedere următoarele specificații:

Cheltuială:

– categoria este un string de max 50 de caractere

cumpărătorul este un string de max 50 de caractere (aparține membrilor familiei)

data este un string de 8 caractere (zi/lună/an)

valoarea cheltuielii este un întreg pozitiv

conținutul are max 10 cuvinte de 10 caractere (String)

cod: este un întreg distinct pentru fiecare cheltuială; chiar dacă celelalte câmpuri pot coincide (categoria, data…); codul este cel care face imperativ diferența dintre cheltuieli

Postcondiții:

tabel cu toate cheltuielile făcute de un membru al familiei; dintre cheltuieli se afișează doar acelea care au drept, cumpărător – membrul familiei respective

orice cheltuială cu cumpărător= membru introdus

tabel cu cheltuielile făcute între două date (data1 și data2); dintre cheltuieli se afișează cele cu data1≤ data ≤data2

tabel cu cheltuielile caracterizate prin cuvinte cheie; dintre cheltuieli se vor alege acelea în al căror conținut se vor regăsi cel puțin unul dintre cuvintele cheie

Conform specificațiilor de mai sus operațiile care se efectuează asupra fișierului cu informații despre cheltuielile casnice ale unei familii constau în crearea (adăugarea) și exploatarea acestui fișier. Considerăm crearea fișierului ca fiind o intrare externă deoarece este un proces în care datele circulă dinspre exterior spre interior, și datorită complexității lui scăzute o considerăm ca fiind simplă. Interogările asupra fișierului cu informații despre cheltuielile casnice sunt interogări externe deoarece sunt procese care conțin atât componente de intrare (datele introduse de utlizator) cât și componente de ieșire (elementele selectate din fișier), iar dificultatea lor redusă ne permite să le încadrăm în categoria de complexitate simplă.

UFC = 3 * 1 (intrare externă) + 3 * 4 (interogări externe ) = 15

Datorită faptului că nu avem restricții referitoare la această aplicație vom considera factorii de complexitate a proiectului ca fiind 0 (nu influențează dezvoltarea aplicației).

TCF (totalul factorilor de complexitate) = 0.65 + 0/100 = 0.65

Punctele funcționale adiacente aplicației sunt deci:

FP = UFC * TCF = 15 * 0.65 = 9.75

În cazul acestei aplicații estimăm timpul necesar dezvoltării la 9.75 * 1.3 = 12.675 ore.

4.4 Gestiune conturi într-o bancă comercială

Se va gestiona:

tranzacțiile bancare (transferal de bani dintr-un cont în altul)

dobânda lunară

depuneri

extrageri

Fișiere:

depunători – date despre depunători (cod, nume, prenume, cont)

de conturi – (cont, cod depunător, soldul current, tip dobândă, data ultimei mișcări)

de tranzacții (zilnic, suma) cont sursă-> cont destinație

Salvare pe support extern: depunători ->clienti.dat (cod, nume, prenume, cont)

conturi -> conturi.dat (cont, coddep, sold, datalim,tip dob)

tranzacții -> tranzacții.dat (conts, contd, suma, data)

Funcționalitate:

crearea și actualizarea celor trei fișiere

actualizarea fișierului de conturi cu tranzacții zilnice

tabel cu toți depunătorii

tabel cu conturile în care au avut loc tranzacții

creare sau ștergere cont cu actualizarea fișierelor corespunzătoare

Observații: 1) Tip dobândă: – dobândă la vedere, dobândă lunară, dobândă 3 luni, dobândă 6 luni, dobândă anuală

2) La extragerea din contul sursă și depunerea în cel destinație se pierde dobânda (sau se reduce cu câteva procente) din contul destinație

3) După actualizare un depunător poate avea soldul din cont=0

Specificare:

Cont: cont ε N *; coddep este un string maximum de 5 caractere; sold current este un integer, sold currnt ≥ 0; data ultimei modificări este un string maximum de 10 caractere; tip dobândă: integer>0, tip dobândă ε {10,25,30,38,50)

Depunător: cont: Cont; nume: string [15], prenume: string[15]; cod parolă: string[5]

Tranzacții: contsursă: integer >0, contdest: integer>0, suma: integer>0

La o tranzacție se actualizează fișierele tranzacții.dat, conturi.dat. La o depunere se actualizează fișierul conturi.dat.

Analizând specificațiile remarcăm funcțiile care actualizează (adaugă) date în fișiere, în continuare vom considera că aceste operații verifică existența fișierelor asupra cărora operează înainte de operația propriu-zisă de adăugare a datelor și în cazul în care acestea nu există le creează. Aceste tranzacții, împreună cu cea de ștergere a conturilor le considerăm ca fiind intrări externe deoarece sunt procese în care datele circulă dinspre exterior spre interior. Tranzacțiile care returnează depunătorii și conturile le considerăm a fi interogări externe deoarece conțin componente de ieșire (elementele selectate din fișier), iar dificultatea lor redusă ne permite să le încadrăm în categoria de complexitate simplă.

UFC = 3 * 5 (intrări externe) + 3 * 2 (interogări externe ) = 21

Referitor la restricțiile acestei aplicații, datorită faptului că modificările on-line sunt preponderente acordăm acestui factor de complexitate valoarea 4.

TCF (totalul factorilor de complexitate) = 0.65 + 4/100 = 0.69

Punctele funcționale adiacente aplicației sunt deci:

FP = UFC * TCF = 21 * 0.69 = 14.49

Pe baza observațiilor referitoare la productivitatea proiectelor care au mărimea până la 50 FP s-a ajuns la concluzia că durata medie de implementare a unei funcții punct este de 1.3 ore. În cazul aplicației de mai sus estimăm timpul necesar dezvoltării la 14.49 * 1.3 = 18.837 ore.

4.5 Agenda personală

Se cere un program care creează, actualizează și exploatează informații despre o listă de persoane și un program personal, întâlniri, evenimente.

Pentru o persoană se reține: cod persoană (unic), nume, prenume, adresă

Pentru nr telefon se reține: nr telefon, cod persoana

Pentru o adresă de email se reține: email, cod persoan

Pentru lista de acțiuni se reține: cod acțiune, data, ora, cod persoana

Pentru tipul de acțiune se reține: cod acțiune, descriere

Programul are următoarele funcții:

generează tabel cu toate persoanele din agendă și informații despre ele (adresă, telefon, email)

generează tabel cu toate întâlnirile

toate nr de telefon și email pentru o persoană dată

toate întâlnirile cu o persoană dată

toate întâlnirile dintr-un interval dat

căutare în agendă după nr de telefon sau email

Specificare: date de intrare: programul citește intrarea din 5 fișiere ale căror nume este specificat într-un fișier configurare

date de ieșire: scrie pe disc aceste fișiere în caz de modificare sau afișează niște tebele în caz de interogare

Specificare operații program:

tabel persoana:

Date: persoana, telefon, email

Rezultate: tabel cu persoanele și toate informațiile despre ele, sortate după un camp selectabil; posibilitate de adăugare, ștergere, modificare a unei persoane

tabel întâlniri:

Date: acțiuni, tip acțiuni, persoane

Rezultate: tabel cu toate acțiunile programate, sortate după dată; funcții de adăugare, ștergere, modificare

tabel informații persoană:

Date: persoana, telefon, email

Rezultate: adresa, toate nr de telefon și adresa de email al persoanei date

căutare după telefon sau email:

Date: persoana, telefon, email

Rezultate: persoana a cărei adresă de email sau nr de telefon se potrivește cu cea dată

căutare în lista de înâlniri:

Date: întâlniri, tip întâlniri, persoana

Rezultate: tabel cu toate persoanele din lista de întâlniri a căror nume se potrivește

căutare în lista întâlniri într-un interval specificat:

Date: întâlniri, tip întâlniri, persoana

Rezultate: tabel cu întâlnirile din intervalul specificat

Funcția aplicației care încarcă informațiile necesare agendei personale (citirea celor 5 fișiere) este de tipul intrare externă deoarece este o tranzacție în care datele circulă dinspre exterior spre interior, are complexitatea medie deci îi atribuim valoarea 4. Tranzacțiile corespunzătoare generării tabelului cu toate persoanele din agendă și informații despre ele, generării tabelului cu toate întâlnirile, generării unui tabel cu toate numerele de telefon și email pentru o persoană dată, generării unui tabel cu toate întâlnirile cu o persoană dată, generării unui tabel cu toate întâlnirile dintr-un interval dat, căutării în agendă după numărul de telefon sau email le considerăm interogări simple atribuind fiecăreia valoarea 3.

UFC = 4 * 1 (intrare externă) + 3 * 6 (interogări externe ) = 22

Datorită faptului că nu avem restricții referitoare la această aplicație vom considera factorii de complexitate a proiectului ca fiind 0 (nu influențează dezvoltarea aplicației).

TCF (totalul factorilor de complexitate) = 0.65 + 0/100 = 0.65

Punctele funcționale adiacente aplicației sunt deci:

FP = UFC * TCF = 22 * 0.65 = 14.3

Timpul necesar dezvoltării acestei aplicații îl putem estima la 14.3 * 1.3 = 18.59 ore.

5. Test on-line

Aplicația Test on-line este formată din două părți distincte: oferă unor utilizatori înregistrați în baza de date posibilitatea de utilizare a serviciilor oferite de aplicație și totodată oferă persoanei autorizate cu gestionarea acestei aplicații (administratorul) posibilitatea de a opera asupra informațiilor conținute în baza de date.

Utilizatorul se poate conecta la serviciu prin introducerea numelui de utlizator și a parolei, după confirmarea identității, acesta are acces la următoarele operații: parcurgerea unui test de verificare a cunoștințelor, care poate fi selectat din cele câteva domenii disponibile (geografie, informatică, limba engleză, statistică matematică); consultarea arhivei care conține testele efectuate anterior de către toți utilizatorii prezentate sub forma: numele utlizatorului, grupa din care acesta face parte, testul selectat, punctajul obținut (numărul de răspunsuri corecte din numărul de întrebări), data la care s-a efectuat testul; schimbarea parolei.

Administratorul are la dispoziție următoarea funcționalitate: adăugarea unui utilizator în baza de date, datele care trebuie introduse fiind: numele și prenumele, grupa, nume utilizator, parola; ștergerea unei persoane din tabela de utilizatori, consecința fiind pierderea accesului la serviciul de testare on-line, ștergerea testelor efectuate de un utilizator din arhivă; schimbarea numelui și a parolei.

Datele folosite de aplicație sunt înregistrate într-o bază de date locală Acces, în cinci tabele prezentate mai jos.

Tabela utilizatori conține datele persoanelor autorizate să utilizeze aplicația și are următoarele câmpuri:

numele (string, maximum 50 caractere)

parola (string, maximum 50 caractere)

grupa (number)

id-ul utilizatorului (string, maximum 50 caractere)

calitatea utlizatorului: student sau administrator (string, maximum 50 caractere);

Tabela arhiva reține datele persoanei care a efectuat un test cu următoarea strucutură:

numele (string, maximum 50 caractere)

grupa (string, maximum 50 caractere)

testul (string, maximum 50 caractere)

punctajul (string, maximum 50 caractere)

data (string, maximum 50 caractere)

Tabela întrebări conține întrebările puse utilizatorului cu următoarele câmpuri:

id-ul întrebării (number)

enunțul întrebării (string, maximum 100 caractere)

id-ul secțiunii din care face parte întrebarea (number)

Tabela secțiuni reține secțiunile puse la dispoziție pentru verificarea cunoștințelor cu următoarele date:

id-ul secțiunii (number)

numele secțiunii (string, maximum 50 caractere)

numărul de întrebări disponibile pentru fiecare secțiune (number)

Tabela variante conține variantele pentru fiecare întrebare din care utilizatorul trebuie

să o selecteze pe cea corectă, și are următoarea structură:

id-ul întrebării (number)

valoarea de adevăr: 0 dacă este o variantă greșită și 1 dacă aceasta este corectă (number)

id-ul secțiunii (number)

enunțul (string, maximum 50 caractere)

Funcționalitatea aplicației este implementată în următoarele clase.

Clasa Utilizator conține variabilele private nume, grupa și calitatea care pot primi valori în cadrul procedurii Autentificare() apelată cu parametrii utilizator, parolă

în momentul accesării aplicației, dacă rezultatul căutării în baza de date a celor doi parametri este pozitiv. Clasa mai conține și procedura de schimbare a parolei Pass() care înregistrează în tabela utilizatori pentru persoana care ruleaza aplicația noua parolă primită ca parametru. Procedura setUtilizatori() înregistreaza în tabela arhiva rezultatul efectuării testului, iar funcția getUtilizatori() returnează toate înregistrările din această tabela pentru a fi consultate de utilizator.

Clasa Varianta reprezintă o variantă a unei întrebari dintr-un test, conține câmpurile enunț (enunțul variantei) și truth (valoarea de adevăr a variantei).

Clasa Intrebare implementează o întrebare dintr-un test, reține variantele întrebării în lista variante (în care se vor depune obiecte de tipul Varianta) și enunțul întrebării în variabila enunț.

Clasa Test este inițializată (funcția setTest()) cu testul ales de utilizator în momentul în care acesta dorește parcurgerea unui test și gestionează derularea acestuia prin returnarea întrebării următoare și a variantelor ei (funcția getQ()) și verificarea răspunsurilor(funcția Verifica()). Clasa conține variabilele întrebări de tip lista (în care se vor adăuga obiecte de tip Intrebare), secțiune (care reprezintă numele secțiunii selectate), raspbune (care reprezintă numărul de răspunsuri bune, inițial 0), nrq (numărul de întrebări din test).

Operațiile puse la dispoziția administratorului sunt implementate în clasa Admin(). Procedura Sterge() primește ca parametru un nume de utilizator și execută această operație pentru numele respectiv asupra tabelei selectate (utilizatori sau arhiva). Procedura Adauga() adaugă o persoană în tabela utilizatori pe baza datelor introduse de administrator (nume, parola, grupa, ut_id, calitatea); procedura ChangePass() schimbă numele de utilizator și parola.

Aplicația Test-on-line este o aplicație Internet. Pentru a calcula suma funcțiilor unice vom lua în considerare atât implementarea claselor Java cât și cea a bazei de date împreună cu partea de prezentare a aplicațiilor JSP.

Analizând tabelul de mai jos (figura 5.1) observăm că suma funcțiilor unice (UFC) este egală cu 31.

Pentru această aplicație nu avem restricții și prin urmare vom avea factorii de complexitate a proiectului egală cu 0 (nu influențează dezvoltarea aplicației).

TCF (totalul factorilor de complexitate) = 0.65 + 0/100 = 0.65

Punctele funcționale adiacente aplicației sunt deci: FP = UFC * TCF = 31 * 0.65 = 20.15

Pe baza tabelului prezentat în secțiunea anterioară unde am văzut că productivitatea proiectelor până la 50 FP au durata medie de implementare a unei funcții punct de 1.3 ore. În cazul acestei aplicații estimăm timpul necesar dezvoltării la 20.15 * 1.3 = 26.195 ore.

Figura 5.1

6. Concluzii

Analiza datelor referitoare la accidentele de mașină din SUA și UK au arătat că ianuarie și februarie sunt lunile în care se produc cele mai puține accidente rutiere. De aceea dacă am avea o bază de date care înregistrează accidentele rutiere, organizate pe luni, și am folosi-o ca să construim un model regresiv, modelul obținut ar prevesti că este mai sigur să conduci atunci când vremea este rece și drumurile sunt atât de înșelătoare. O asemenea concluzie este perfect deductibilă ținând cont de datele disponibile, dar intuitiv noi știm că este greșită. Problema este că nu avem la dispoziție toate datele relevante pentru a lua o decizie corectă referitoare la perioada cea mai sigură de șofat. Modelele regresive conduc deseori la o interpretare greșita despre cauză și efect. O corelație, cum este aceea dintre lunile anului și numărul de accidente nu asigură o evidență a unei relații cauzale. Desigur că vremea este cel mai probabil să fie rea în perioada lunilor de iarnă și ea poate provoca condiții grele de circulație. În aceste circumstanțe numărul celor care conduc mașini este mai mic și au tendința de a conduce mult mai încet. Avem aici distincția dintre o abordare naivă bazată pe regresie și abordarea mai recentă a unei modelări cazuale. Modelul cazual “spune povestea” care lipsește din abordarea naivă, și se poate folosi în luarea unor decizii inteligente precum și pentru identificarea factorilor care pot fi controlați sau influențați. Dacă decizi să conduci mașina în februarie tot atât de des ca și în iulie, și dacă conduci la fel de repede indiferent de condițiile de drum, atunci este mult mai probabil să produci un accident în februarie. Modelul naiv regresiv nu este capabil să furnizeze această informație importantă, spre deosebire de modelul cazual. Metricile soft au fost dominate de modelele statistice, cum sunt modele regresive, când de fapt este nevoie de modele cauzale.

De exemplu o mare parte din metricile soft au fost create de nevoia pentru modele de predicție a resurselor. De obicei această muncă se baza pe modele de regresie de forma efort = f(mărime). Se ignoră faptul că mărimea nu poate cauza mărirea efortului, asemenea modele nu pot fi folosite efectiv pentru a asigura suportul deciziilor pentru evaluarea riscului. Aceasta pentru că ele nu au un cadru explicativ. Fără acesta managerii nu știu cum să acționeze asupra proiectului pentru a îmbunătăți lucrurile. Modelul cauzal poate asigura o structură explicativă pentru a lămuri evenimentele care pot fi cuantificate.

Sunt multe beneficii atribuite metricilor soft. Dar cel mai semnificativ este acela că ele se presupune a asigura informația necesară luării deciziilor manageriale de-a lungul ciclului de viață a softului.

Deși prima carte dedicată metricilor soft nu a fost publicată decât în 1976 istoria metricilor soft datează de la mijlocul anilor ’60 când metricile LOC erau folosite ca bază pentru măsurarea efortului și productivității.

Metricile soft este un termen colectiv utilizat pentru a descrie gama foarte largă a activităților preocupate de măsurare în ingineria soft. Aceste activități diferă de la cele care produc cifre care caracterizează proprietățile codului soft (acestea sunt metricile soft clasice) până la modele care ajută la predicția resurselor necesare proiectului soft. Subiectul include de asemenea și aspectele cantitative ale controlului calității și siguranței, acoperind activități cum ar fi monitorizarea și înregistrarea defectelor de-a lungul perioadei de dezvoltare și testare. Pentru că ingineria soft este în cele din urmă (esențialmente) un subiect empiric, metricile soft ar fi trebuit ca până acum să-ți fi câștigat un rol central în cadrul ei, dar ele continuă să fie marginalizate. Mai mult de atât ele sunt de multe ori înțelese și folosite greșit și chiar criticate, Glass ajungând la concluzia că “ceea ce teoria face cu privire la domeniul metricilor soft și ceea ce se întampla în practică sunt în două plane diferite, plane care se deplasează în direcții diferite. Recenta creștere a activității metricilor soft industriale nu este în mod necesar rezultatul faptului că companiile sunt convinse de eficacitatea lor.

Putem împărți subiectul în două componente:

componenta preocupată de definirea metricilor

componenta care studiază cum colectăm, administrăm și folosim aceste metrici.

În mod esențial fiecare metrică soft este o încercare de a măsura sau prezice atributele (interne sau externe) ale unui produs, proces sau resursă. Deși au fost mii de metrici definite rațiunea pentru aproape toate dintre ele au fost motivate de una din următoarele două activități:

dorința de a estima sau a prezice efortul/costul procesului de dezvoltare

dorința de a estima sau prezice calitatea produselor soft

Soluția propusă în amândouă cazurile a fost presupunerea că “mărimea” produsului va conduce la modele predicitve. Prima metrică folosită pentru aceasta a fost LOC sau KLOC (pentru mii de linii de cod). A fost și încă mai este rutină obișnuită pentru măsurarea productivității programatorului (LOC/programator/lună), și prin urmare s-a presupus că LOC este cheia pentru estimarea efortului necesar dezvoltării soft. LOC a fost folosit prin urmare ca și o metrică surogat pentru noțiuni diferite ale mărimii produsului (efort,funcționalitate, complexitate). Dezavantajele evidente ale folosirii unei metrici atâ de brute cum este LOC pentru noțiuni atât de diferite ale produsului soft, au fost recunoscute la mijlocul anilor ’70. Nevoia pentru metrici mult mai subtile a devenit și mai urgentă o dată cu creșterea diversității limbajelor de programare. La urma urmei LOC în limbaj de asamblare nu este comparabilă ca efort, funcționalitate sau complexitate cu un LOC într-un limbaj de nivel înalt. De aceea decada începută la mijlocul anilor ’70 a cunoscut explozia interesului în măsurarea complexității softului și în măsurarea mărimii funcționale (pioneratul lui Albrecht cu FP) care s-au dorit a fi independente de limbajele de programare. Munca în acest domeniu a inclus și definirea de metrici care sunt relevante pentru noile paradigme cum ar fi limbajele orientate obiect,

stabilirea unei baze teoretice a măsurătorilor pentru activitățile metrice soft.

Marea provocare pentru comunitatea metricii soft este de a produce modele care să poată trata:

procese diverse și produse în schimbare

evidențe empirice și judecata experților

relații autentice de cauză și efect

nesiguranța

informații incomplete

În același timp modelele nu trebuie să introducă cheltuieli suplimentare datorită cantităților de date colectate sau complexității metricii.

Bibliografie

1 http://irb.cs.tu-berlin.de/~zuse/metrics/History_13

2 Measurement and Estimation of Software and Software Process, Simon Moser, pag 50

3 http://www.developer.com/tech/article.php

4 http://www.developer.com/tech/article.php

5 http://www.developer.com/tech/article.php

6 Measurement and Estimation of Software and Software Process, Simon Moser, pag51

7 Measurement and Estimation of Software and Software Process, Simon Moser, pag 51

8 http://www.ecfc.u-net.com/cost/index.htm

9 Parametric Estimating Handbook, Join Industry, Government- capitolul 6-Commercial Software Models, pag 23

10 http://www.ecfc.u-net.com/cost/index.htm

11 http://www.ifpug.com/fpafund.htm

12 http://www.ecfc.u-net.com/cost/index.htm

13 http://www.ecfc.u-net.com/cost/index.htm

14 Parametric Estimating Handbook, Join Industry, Government- capitolul 6-Commercial Software Models, pag 33

15 http://www.ecfc.u-net.com/cost/index.htm

16 Parametric Estimating Handbook, Join Industry, Government- capitolul 6-Commercial Software Models, pag 32

17 http://www.ecfc.u-net.com/cost/index.htm

18 http://www.ecfc.u-net.com/cost/index.htm

19 http://www.ecfc.u-net.com/cost/index.htm

20 http://www.ecfc.u-net.com/cost/index.htm

21 http://www.ecfc.u-net.com/cost/index.htm

22 http://www.ecfc.u-net.com/cost/index.htm

23 http://www.ecfc.u-net.com/cost/index.htm

24 http://www.ecfc.u-net.com/cost/index.htm

25 http://www.ecfc.u-net.com/cost/index.htm

26 Software Metrics: Roadmap, Norman E. Fenton & Martin Neil, pag 9

27 http://davidfrico.com/longstreet01b.htm

28 http://davidfrico.com/longstreet01b.htm