1/132

Inginerie software

2/132

1 Fazele dezvoltrii unui produs software1.1 Ce este ingineria programrii?

tiina calculatoarelor este un domeniu relativ nou. Primele calculatoare au fostconstruite la mijlocul anilor 1940 i de atunci au avut loc dezvoltri spectaculoase, n anul1946 Goldstine i von Neumann apreciau c 1000 de instruciuni reprezint o limitsuperioar rezonabil pentru complexitatea problemelor ce pot fi concepute ca rezolvabile cuajutorul calculatorului. Dup ce a prevzut n 1981 c nici un program pentru calculatoarepersonale nu va necesita vreodat mai mult de 640 KB de memorie RAM, Bill Gates admiten 1995 c lucrurile s-au schimbat n ultimele dou decenii.

Urmtoarele exemple ofer o imagine asupra gradului de complexitate la care au ajunsprogramele n zilele noastre:

sistemul de rezervare a biletelor pentru compania aerian KLM coninea, n anul1992, dou milioane de linii de cod n limbaj de asamblare;

sistemul de operare System V versiunea 4.0 (UNIX) a fost obinut princompilarea a 3.700.000 linii de cod;

programele scrise pentru naveta spaial NASA au circa 40 de milioane de liniide cod;

pentru realizarea sistemului de operare IBM OS360 au fost necesari 5000 de ani-om.

Creterea programelor n dimensiune i complexitate a depit cu mult progresele fcuten domeniul tehnicilor de programare. De aceea, programarea a devenit i a rmas mai mult oart dect o meserie.

O paralel cu ingineria construciilor este atractiv. Dac dorim s construim o cucpentru cine, putem s mergem prin grdin, s cutam lemne i cuie, s lum un ciocan i sncepem s lucrm. Avem anse destul de bune s reuim, mai ales dac suntem ndemnatici.Dac totui nu reuim, putem ncerca a doua zi din nou cu alte lemne i alte cuie. Iar daccinele nu ncape n cuc, putem s ne cumprm alt cine.

Lucrurile stau radical diferit atunci cnd dorim s construim o cas pentru familianoastr. Atunci va trebui sau s angajm un arhitect care s ne fac un proiect, sau scumprm un proiect standard de cas. Va trebui s negociem cu o firm de construcii preul,durata de realizare, calitatea finisajelor. Nu ne permitem s riscm economiile familiei pe oconstrucie care se va drma la a doua rafal de vnt. n plus, dac membrilor familiei nu leplace orientarea ferestrelor sau peisajul, nu i putem schimba cu alii (n cel mai ru caz, neschimb ei pe noi).

Cu att mai mult, dac o firm pltete cteva milioane de dolari pentru a ridica unzgrie nori, reprezentanii acesteia vor fi foarte ateni cu cine i n ce condiii vor lucra. Ei vordori garanii c proiectul este viabil, vor angaja mai multe firme de arhitectur pentru a-1verifica. De asemenea, studii geologice, de fizic a pmntului sau meteorologie vor fiobligatorii. Vor fi folosite cele mai performante materiale i se vor angaja cei mai competenii cu experien constructori. Eecul nu mai este o opiune pentru contractantul proiectului.

tim c inginerii constructori ntocmesc planuri, construiesc machete, studiazproprietile materialelor folosite i fac rapoarte privind progresul operaiunilor. Construciide o complexitate foarte mare au fost realizate n acest fel ntr-un mod raional i economic.Inginerii de programe ar trebui s procedeze similar pentru ca dezvoltarea programelor s numai fie un proces impredictibil.

Pe msur ce complexitatea programelor cretea, la sfritul anilor '60 ncepea s seprefigureze deja o criz a programrii. Un raport prezentat de ctre o companie, n care erauanalizate cteva proiecte i stadiile lor de finalizare, a constatat c:

3/132

2% din sistemele software contractate au funcionat de la predare;3% din sistemele software au putut funciona dup cteva modificri;29% au fost predate dar n-au funcionat niciodat;19% au fost folosite dar au fost abandonate; 47% au fost pltite dar niciodat predate.Pentru a contracara aceste tendine, la conferina organizat de comitetul tiinific al

NATO n anul 1968, a fost propus termenul de ingineria programrii (engl. softwareengineering"), ntr-un mod oarecum provocator. Se dorea ca arta programrii s mprumutedin rigoarea tiinelor inginereti pentru a putea livra programe la timp i n mod economic.Prima definiie dat ingineriei programrii a fost enunat astfel (F. L. Bauer):

Ingineria programrii este stabilirea i utilizarea de principii inginereti solide pentru aobine n mod economic programe sigure i care funcioneaz eficient pe maini de calculreale.

In IEEE Standard Glossary of Software Engineering Technology (1983) ingineriaprogramrii este definit dup cum urmeaz:

Ingineria programrii reprezint abordarea sistematic a dezvoltrii, funcionrii,ntreinerii, i retragerii din funciune a programelor.

Remarcm c a doua definiie este mai vag dect prima, ntruct nu face referire la costi la eficien. Mai mult, se pare c experiena n general negativ acumulat a fcut s serenune la formularea principii inginereti solide", ntruct se pare c acestea nu pot fiidentificate fr a fi supuse contestaiilor. A doua definiie adaug ns referiri la perioadeimportante din viaa unui program, ce urmeaz crerii i funcionrii, i anume ntreinerea iretragerea din funcionare.

Considerm c ingineria programrii are urmtoarele caracteristici importante: este aplicabil n producerea de programe mari; este o tiin inginereasc; scopul final este ndeplinirea cerinelor clientului.

Programele mici se pot scrie relativ uor, de ctre un singur programator, ntr-o perioaddestul de scurt de timp. Un program de 100 de instruciuni este cu siguran un program mic.Nu putem identifica precis grania dintre un program mic i unul mare, ns pe msur cedimensiunea programului crete, apar provocri noi, calitativ diferite.

ntruct un singur sau civa programatori nu pot avea timpul fizic pentru terminareaprogramului, este necesar crearea uneia sau mai multor echipe de lucru. Este necesarcoordonarea i comunicarea ntre echipe. Complexitatea sistemului software i a organizaieicare realizeaz sistemul software devine important, putnd depi capacitatea de nelegere aunui singur individ. Apare ca dezirabil o abordare riguroas a acestor probleme, ce includestilul de lucru, modul de scriere a codului etc.

Nerespectarea cerinelor poate avea efecte serioase. Un sistem de livrare a insulineipentru diabetici poate provoca moartea pacientului dac nu funcioneaz corect. Funcionareaincorect a unui sistem de control al unui satelit poate provoca pagube de milioane de dolari.

Un program este fiabil dac funcioneaz i continu s funcioneze fr ntreruperi uninterval de timp. Aceast noiune exprim de fapt rezistena la condiiile de funcionare. Unsistem de operare trebuie s fie fiabil pentru c trebuie s funcioneze o perioad suficient delung de timp fr s cad, indiferent de programele care ruleaz pe el, chiar dac nutotdeauna la performane optime.

Programul este sigur dac funcioneaz corect, fr operaii nedorite. Un programpentru un automat bancar trebuie s fie sigur, pentru a efectua tranzaciile n mod absolutcorect, chiar dac funcionarea sa poate fi ntrerupt din cnd n cnd. Atunci cndfuncioneaz ns, trebuie s funcioneze foarte bine.

Programul este sigur dac funcioneaz corect, fr operaii nedorite. Un automat bancartrebuie s fie sigur, pentru a efectua tranzaciile n mod absolut corect, chiar dac funcionarea

4/132

sa poate fi ntrerupt din cnd n cnd. Atunci cnd funcioneaz ns, trebuie s funcionezefoarte bine.

Un program are o eroare (engl. bug") dac nu se comport corect. Se presupune cdezvoltatorul tia ce ar fi trebuit programul s fac, iar comportamentul greit nu esteintenionat. Iat cteva erori celebre:

n primii ani n care calculatoarele au fost introduse la staiile de benzin dinSUA, consumatorii primeau cecuri pe sume enorme. Faptul era privit n generalcu umor i reclamaiile erau rezolvate repede;

Sistemul de operare IBM OS360 coninea aproximativ 1.000 de greeli la fiecarenou versiune care ncerca s rezolve greelile din versiunea precedent;

Un vehicul de explorare a planetei Venus a fost pierdut deoarece programulprimit de pe Pmnt pentru rectificarea orbitei coninea linia 'DO 31= 1.3';instruciunea corect n limbajul FORTRAN ar fi trebuit s conin virgul n locde punct;

In 1979 s-a descoperit o eroare n programele pentru sistemele de rcire ncentralele nucleare din SUA; din fericire, nu fusese niciodat nevoie de execuiarutinelor ce conineau erorile;

Din cauza unei erori n sistemul de avertizare mpotriva atacului cu rachetebalistice, procedurile de contraatac au fost declanate nainte de a se descoperic a fost o eroare;

Racheta Arianne 5 a explodat n iunie 1996 din cauza unei greeli deprogramare; costurile s-au ridicat la 500 milioane dolari.

Ingineria programrii are ca scop obinerea de sisteme funcionale chiar i atunci cndteoriile i instrumentele disponibile nu ofer rspuns la toate provocrile ce apar. Inginerii faclucrurile s mearg, innd seama de restriciile organizaiei n care lucreaz i deconstrngerile financiare.

Problema fundamental a ingineriei programrii este ndeplinirea cerinelor clientului.Aceasta trebuie realizat nu punctual, nu n acest moment, ci ntr-un mod flexibil i pe termenlung. Ingineria programrii se ocup cu toate etapele dezvoltrii programelor, de la extragereacerinelor de la client pn la ntreinerea i retragerea din folosin a produsului livrat. Pelng cerinele funcionale, clientul dorete (de obicei) ca produsul final s fie realizat cucosturi de producie ct mai mici. De asemenea, este de dorit ca aceasta s aib performanect mai bune (uneori direct evaluabile), un cost de ntreinere ct mai mic, s fie livrat la timp,i s fie sigur. Rezumnd, atributele cheie ale unui produs software se refer la:

posibilitatea de a putea fi ntreinut: un produs cu un lung ciclu de via estesupus deseori modificrilor, de aceea el trebuie foarte bine documentat;

fiabilitate: produsul trebuie s se comporte dup cerinele utilizatorului i s nucad" mai mult dect e prevzut n specificaiile sale;

eficien: produsul nu trebuie s foloseasc n pierdere resursele sistemului camemoria sau ciclii procesor;

interfaa potrivit pentru utilizator: interfaa trebuie s in seama de capacitateai cunotinele utilizatorului.

Optimizarea tuturor acestor atribute e dificil deoarece unele se exclud pe altele (o maibun interfa pentru utilizator poate micora eficiena produsului), n cazurile n careeficiena este critic, acest lucru trebuie specificat explicit nc din faza de preluare acerinelor utilizatorului, precum i compromisurile pe care ea le implic privind ceilalifactori.

Trebuie spus c ingineria programrii nu rezolv toate problemele care apar atunci cndse scriu programe. Ingineria programrii nu ofer nici teorii. Inginerii fac lucrurile s mearg.Totui, n momentul de fa, ingineria programrii ne poate spune sigur ce s nu facem.

5/132

1.2 Fazele ingineriei programriiExist patru faze fundamentale ale metodologiilor ingineriei programrii:

analiza (ce dorim s construim); proiectarea (cum vom construi); implementarea (construirea propriu-zis); testarea (asigurarea calitii).

Dei aceste faze se refer n mod special la ciclul de via al produsului software, ele potfi aplicate i altor stadii de existen prin care trece un program de la natere" pn lamoarte": lansare, ntreinere, ieire din uz.1.2.1 Faza de analiz

Aceast faz definete cerinele sistemului, independent de modul n care acestea vor findeplinite. Aici se definete problema pe care clientul dorete s o rezolve. Rezultatul acesteifaze este documentul cerinelor, care trebuie s precizeze clar ce trebuie construit.

Documentul ncearc s redea cerinele din perspectiva clientului, definind scopurile iinteraciunile la un nivel descriptiv nalt, independent de detaliile de implementare, cum ar fi,de exemplu: formularea problemei, ateptrile clientului sau criteriile pe care trebuie s lendeplineasc produsul.

Grania dintre descrierile de nivel nalt i cele de nivel sczut nu este foarte bine trasat.Uneori, dac un detaliu tehnic important trebuie specificat, el va aprea n document. Totui,aceasta trebuie s fie excepia i nu regula. Aceste excepii pot fi determinate de necesitateameninerii compatibilitii cu alte sisteme deja existente, sau a unor anumite opiuni dorite declient, de exemplu utilizarea unui anumit standard sau o constrngere asupra dimensiunilorimaginii aplicaiei, care poate fi destinat unei categorii speciale de utilizatori sau care va rulape nite sisteme cu o serie de particulariti (monitoare care nu suport rezoluii mari). Fazade analiz poate fi vzut ca o rafinare a detaliilor. Distincia dintre detaliile de nivel nalt icele de nivel sczut sunt puse mai bine n eviden de abordrile top-down (unde se mergectre detaliile de nivel sczut) i bottom-up (care tind ctre detaliile de nivel nalt).

Documentul cerinelor poate fi realizat ntr-o manier formal, bazat pe logicmatematic, sau poate fi exprimat n limbaj natural, n mod tradiional, el descrie obiectele dinsistem i aciunile care pot fi realizate cu ajutorul obiectelor. Aici noiunea de obiect" nutrebuie confundat cu obiectul din programarea orientat obiect. Descrierea obiectelor iaciunilor trebuie s fie general i s nu depind de o anumit tehnologie. Desigur, ntr-oabordare POO, descrierile vor lua forma obiectelor i metodelor, ns n alte abordri,obiectele pot fi de exemplu servicii care acceseaz baze de date.

In general, documentul cerinelor descrie ontologia proiectului, adic vocabularul decuvinte cheie (n special construcii substantivale i verbale) care va fi utilizat pentru definireaprotocolului specific aplicaiei. Descrierile acestea nu implic proiectarea arhitecturiiaplicaiei, ci enumerarea prilor componente i a modului n care acestea se comport. Maitrziu, n faza de proiectare, acestea vor fi transformate n primitive informatice, precum liste,stive, arbori, grafuri, algoritmi i structuri de date.

Mai concret, documentul trebuie s conin descrieri pentru urmtoarele categorii: Obiecte: Documentul trebuie s defineasc mai nti ontologia sistemului, care

este bazat n mare parte pe construcii substantivale pentru identificareapieselor, prilor componente, constantelor, numelor i a relaiilor dintre acestea;

Aciuni: Documentul trebuie s defineasc de asemenea aciunile pe care trebuies le ndeplineasc sistemul i care sunt sugerate n general de construciiverbale. Exemple de aciuni sunt: metodele, funciile sau procedurile;

6/132

Stri: Sunt definite ca mulimi de setri i valori care disting sistemul ntre douipostaze spaio-temporale. Fiecare sistem trece printr-o serie de schimbri destare. Exemple de stri sunt: starea iniial, cea final sau strile de eroare. Celemai multe stri depind de domeniul problemei. Strile sunt asociate cu obiectelesistemului. Un eveniment declaneaz o tranziie de stare care poate conduce landeplinirea unei aciuni de ctre sistem;

Scenarii tipice: Un scenariu este o secven de pai urmai pentru ndeplinireaunui scop. Cnd sistemul este terminat i aplicaia este disponibil, clientultrebuie s poat utiliza, ntr-o manier ct mai facil i clar specificat, toatescenariile tipice ale aplicaiei. Scenariile tipice trebuie s reprezinte majoritateascenariilor de utilizare ale aplicaiei. Ponderea acestora variaz de la un sistem laaltul, dar 90% se consider o proporie acceptabil. Bineneles c un sistem cuun singur scenariu de utilizare este relativ simplu de obinut, pe cnd unul cu miide scenarii posibile va fi mult mai dificil de analizat. Deseori este invocatregula 80/20: 80% din funcionalitatea sistemului se realizeaz cu 20% dinefortul de munc. Executarea restului minoritar de funcionalitate necesit mareamajoritate a timpului de lucru;

Scenarii atipice: Un scenariu atipic trebuie s fie ndeplinit de sistem numai ncazuri speciale. Clientul poate s spere, de exemplu, c o eroare neprevzut esteun eveniment atipic. Totui, sistemul trebuie s gestioneze un numr ct maimare de categorii de erori, prin tehnici stabilite, precum tratarea excepiilor,monitorizarea proceselor etc.;

Cerine incomplete sau nemonotone: O enumerare complet a cerinelor pentrutoate situaiile care pot aprea n condiii de lucru reale nu este posibil. Inlogica tradiional, o teorie este definit de o mulime finit de axiome.Teoremele din teoria respectiv sunt propoziii adevrate. Dac se adaugulterior noi axiome, teoremele existente rmn valide iar noile teoremedezvoltate sunt adugate teoremelor stabilite. In logica nemonoton, adugareade noi axiome poate invalida unele teoreme care au fost demonstrate anterior. Onou teorie nu mai este o simpl extensie a teoriei vechi, ci o mulime deteoreme noi, mpreun cu o parte din teoremele vechi. Procesul de stabilire acerinelor are o natur iterativ i nemonoton. Mulimea iniial de cerine(axiomele) definete posibilitile (teoremele) sistemului. Noile cerine potinfirma soluiile vechi. Pe msur ce un sistem crete n dimensiuni icomplexitate, stabilirea cerinelor devine din ce n ce mai dificil, mai ales cndprocesul de colectare a cerinelor este distribuit, fiind realizat de indivizi cuspecializri diferite.

1.2.2 Faza de proiectarePe baza cerinelor din faza de analiz, acum se stabilete arhitectura sistemului:

componentele sistemului, interfeele i modul lor de comportare: Componentele sunt elementele constructive ale produsului. Acestea pot fi create

de la zero sau reutilizate dintr-o bibliotec de componente. Componentelerafineaz i captureaz semnificaia detaliilor din documentul cerinelor;

Interfeele ajut la mbinarea componentelor. O interfa reprezint grania dintredou componente, utilizat pentru comunicarea dintre acestea. Prin intermediulinterfeei, componentele pot interaciona;

Comportamentul, determinat de interfa, reprezint rspunsul unei componentela stimulii aciunilor altor componente.

7/132

Documentul de proiectare descrie planul de implementare a cerinelor. Se identificdetaliile privind limbajele de programare, mediile de dezvoltare, dimensiunea memoriei,platforma, algoritmii, structurile de date, definiiile de tip globale, interfeele etc.

In aceast faz trebuie indicate i prioritile critice pentru implementare. Acesteasugereaz sarcinile care, dac nu sunt executate corect, conduc la eecul sistemului. Totui,chiar dac prioritile critice sunt ndeplinite, acest fapt nu duce automat la succesulsistemului, ns crete nivelul de ncredere c produsul va fi o reuit.

Folosind scenariile tipice i atipice, trebuie realizate compromisurile inerente ntreperforman i complexitatea implementrii. Analiza performanelor presupune studiereamodului n care diferitele arhitecturi conduc la diferite caracteristici de performan pentrufiecare scenariu tipic. In funcie de frecvena de utilizare a scenariilor, fiecare arhitectur vaavea avantaje i dezavantaje. Un rspuns rapid la o aciunea a utilizatorului se realizeazdeseori pe baza unor costuri de resurse suplimentare: indeci, managementul cache-ului,calcule predictive etc. Dac o aciune este foarte frecvent, ea trebuie realizat corect ieficient. O aciune mai rar trebuie de asemenea implementat corect, dar nu este evident caree nivelul de performan necesar n acest caz. O situaie n care o astfel de aciune trebuieimplementat cu performane maxime este nchiderea de urgen a unui reactor nuclear.

Planul de implementare i planul de test, descrise mai jos, pot fi incluse de asemenea nfazele de implementare i respectiv testare. Ins unul din scopurile fazei de proiectare estestabilirea unui plan pentru terminarea sistemului, de aceea cele dou planuri au fost incluse nparagraful curent.

Planul de implementare stabilete programul dup care se va realiza implementarea iresursele necesare (mediul de dezvoltare, editoarele, compilatoarele etc.).

Planul de test definete testele necesare pentru stabilirea calitii sistemului. Dacprodusul trece toate testele din planul de test, este declarat terminat. Cu ct testele sunt maiamnunite, cu att este mai mare ncrederea n sistem i deci crete calitatea sa. Un anumetest va verifica doar o poriune a sistemului. Acoperirea testului este procentajul din produsverificat prin testare, n mod ideal, o acoperire de 100% ar fi excelent, ns este rareorindeplinit. De obicei, un test cu o acoperire de 90% este simpl, ns ultimele 10% necesit operioad de timp semnificativ.

De exemplu, s considerm BIOS-ul (Basic Input/Output System) construit de IBM lanceputul anilor '80 n strns legtur cu sistemul de operare DOS (Disk Operating System)al firmei Microsoft. Din raiuni de performan, BIOS-ul a fost plasat ntr-un chip ROM, ideci patch-urile pentru eventualele erori erau imposibile. Astfel, au fost necesare teste cuacoperire de 100%. Codul propriu-zis al BlOS-ului era destul de mic, cteva mii de linii. Insdeoarece BIOS-ul are o natur asincron, testul a presupus mai nti crearea unui mediuasincron care s aduc sistemul n starea dorit i apoi trebuia generat un eveniment care sdeclaneze un test. Foarte repede, setul de test a devenit mult mai mare dect BIOS-ul. Aaprut astfel problema testrii nsui a mediului de test! In final, o acoperire de 100% a fostatins, dar cu un cost foarte ridicat. O soluie mai ieftin a fost nscrierea BlOS-ului ntr-ocombinaie dintre EPROM (Electronic Programmable Read Only Memory) i ROM. Cea maimare parte a produsului era plasat n ROM, iar patch-urile erau plasate n EPROM. Aceasta afost abordarea adoptat de Apple pentru Macintosh.

In general, este suficient ca testele s cuprind scenariile tipice i atipice, fr s verificentregul sistem, cu absolut toate firele de execuie. Acesta poate conine ramificaii interne,erori sau ntreruperi care conduc la fire de execuie netestate. Majoritatea sistemelor sunt plinede bug-uri nedescoperite. De obicei, clientul particip n mod logic la testarea sistemului isemnaleaz erori care vor fi ndeprtate n versiunile ulterioare.

8/132

1.2.3 Faza de implementareIn aceast faz, sistemul este construit, ori plecnd de la zero, ori prin asamblarea unor

componente pre-existente. Pe baza documentelor din fazele anterioare, echipa de dezvoltare artrebui s tie exact ce trebuie s construiasc, chiar dac rmne loc pentru inovaii iflexibilitate. De exemplu, o component poate fi proiectat mai restrns, special pentru unanumit sistem, sau mai general, pentru a satisface o direcie de reutilizare.

Echipa trebuie s gestioneze problemele legate de calitate, performan, biblioteci idebug. Scopul este producerea sistemului propriu-zis. O problem important estendeprtarea erorilor critice, ntr-un sistem exist trei tipuri de erori:

Erori critice: mpiedic sistemul s satisfac n mod complet scenariile deutilizare. Aceste erori trebuie corectate nainte ca sistemul s fie predat clientuluii chiar nainte ca procesul de dezvoltare ulterioar a produsului s poatcontinua;

Erori necritice: Sunt cunoscute, dar prezena lor nu afecteaz n modsemnificativ calitatea observat a sistemului. De obicei aceste erori sunt listate nnotele de lansare i au modaliti de ocolire bine cunoscute;

Erori necunoscute: Exist ntotdeauna o probabilitate mare ca sistemul sconin un numr de erori nedescoperite nc. Efectele acestor erori suntnecunoscute. Unele se pot dovedi critice, altele pot fi rezolvate cu patch-uri saueliminate n versiuni ulterioare.

1.2.4 Faza de testareCalitatea produsului software este foarte important. Multe companii nu au nvat ns

acest lucru i produc sisteme cu funcionalitate extins, dar cu o calitate sczut. Totui, e maisimplu s-i explici clientului de ce lipsete o anumit funcie dect s-i explici de ce produsulnu este performant. Un client satisfcut de calitatea produsului va rmne loial firmei i vaatepta noile funcii n versiunile urmtoare.

In multe metodologii ale ingineriei programrii, faza de testare este o faz separat,realizat de o echip diferit dup ce implementarea s-a terminat. Motivul este faptul c unprogramator nu-i poate descoperi foarte uor propriile greeli. O persoan nou care privetecodul poate descoperi greeli evidente care scap celui care citete i recitete materialul demulte ori. Din pcate, aceast practic poate determina o atitudine indiferent fa de calitaten echipa de implementare.

Tehnicile de testare sunt abordate preponderent din perspectiva productoruluisistemului, n mod ideal, i clientul trebuie s joace un rol important n aceast faz. Testelede regresiune (engl. regression test") sunt colecii de programe care testeaz una sau maimulte trsturi ale sistemului. Rezultatele testelor sunt adunate i dac exist erori, bug-ul estecorectat. Un test de regresiune valid genereaz rezultate verificate, numite standardul deaur". Validitatea rezultatului unui test ar trebui s fie determinat de documentul cerinelor, npractic, echipa de implementare este responsabil de interpretarea validitii.

Testele sunt colectate, mpreun cu rezultatele standardelor de aur, ntr-un pachet de testde regresiune. Pe msur ce dezvoltarea continu, sunt adugate mai multe teste noi, iartestele vechi pot rmne valide sau nu. Dac un test vechi nu mai este valid, rezultatele salesunt modificate n standardul de aur, pentru a se potrivi ateptrilor curente. Pachetul de testeste rulat din nou i genereaz noi rezultate. Acestea sunt comparate cu rezultatelestandardelor de aur. Dac sunt diferite, n sistem a aprut o greeal. Greeala este corectat idezvoltarea continu. Acest mecanism detecteaz situaiile cnd starea curent de dezvoltare aprodusului invalideaz o stare existent. Astfel, se previne regresiunea sistemului ntr-o starede eroare anterioar.

Exist patru puncte de interes n testele de regresiune pentru asigurarea calitii.

9/132

Testarea intern trateaz implementarea de nivel sczut. Fiecare funcie sau componenteste testat de ctre echipa de implementare. Aceste teste se mai numesc teste clear-box" sauwhite-box", deoarece toate detaliile sunt vizibile pentru test.

Testarea unitilor testeaz o unitate ca un ntreg. Aici se testeaz interaciunea maimultor funcii, dar numai n cadrul unei singure uniti. Testarea este determinat dearhitectur. De multe ori sunt necesare aa-numitele schele", adic programe specialconstruite pentru stabilirea mediului de test. Numai cnd mediul este realizat se poate executao evaluare corect. Programul schel stabilete stri i valori pentru structurile de date iasigur funcii externe fictive. De obicei, programul schel nu are aceeai calitate ca produsulsoftware testat i adesea este destul de fragil. O schimbare mic n test poate determinaschimbri importante n programul schel. Aceste teste se mai numesc teste black-box"deoarece numai detaliile interfeei sunt vizibile pentru test.

Testarea intern i a unitilor poate fi automatizat cu ajutorul instrumentelor deacoperire (engl. coverage tools"), care analizeaz codul surs i genereaz un test pentrufiecare alternativ a firelor execuie. Depinde de programator combinarea acestor teste ncazuri semnificative care s valideze rezultatelor fiecrui fir de execuie. De obicei,instrumentul de acoperire este utilizat ntr-un mod oarecum diferit: el urmrete liniile de codexecutate ntr-un test i apoi raporteaz procentul din cod executat n cadrul testului. Dacacoperirea este mare i liniile surs netestate nu prezint mare importan pentru calitateageneral a sistemului, atunci nu mai sunt necesare teste suplimentare.

Testarea aplicaiei testeaz aplicaia ca ntreg i este determinat de scenariile echipei deanaliz. Aplicaia trebuie s execute cu succes toate scenariile pentru a putea fi pus ladispoziia clientului. Spre deosebire de testarea intern i a unitilor, care se face prinprogram, testarea aplicaiei se face de obicei cu scripturi care ruleaz sistemul cu o serie deparametri i colecteaz rezultatele. In trecut, aceste scripturi erau create manual. In prezent,exist instrumente care automatizeaz i acest proces. Majoritatea aplicaiilor din zilelenoastre au interfee grafice (GUI). Testarea interfeei grafice pentru asigurarea calitii poatepune anumite probleme. Cele mai multe interfee, dac nu chiar toate, au bucle deevenimente, care conin cozi de mesaje de la mouse, tastatur, ferestre etc. Asociate cu fiecareeveniment sunt coordonatele ecran. Testarea interfeei presupune deci memorarea tuturoracestor informaii i elaborarea unei modaliti prin care mesajele s fie trimise din nouaplicaiei, la un moment ulterior.

Testarea la stres determin calitatea aplicaiei n mediul su de execuie. Ideea estecrearea unui mediu mai solicitant dect cel n care aplicaia va rula n mod obinuit. Aceastaeste cea mai dificil i complex categorie de teste. Sistemul este supus unor cerine din ce nce mai numeroase, pn cnd acesta cade. Apoi produsul este reparat i testul de stres serepet pn cnd se atinge un nivel de stres mai ridicat dect nivelul ateptat de pe staiaclientului. Deseori apar aici conflicte ntre teste. Fiecare test funcioneaz corect atunci cndeste fcut separat. Cnd dou teste sunt rulate n paralel, unul sau ambele teste pot eua.Cauza este de obicei managementul incorect al accesului la resurse critice. Mai apar iprobleme de memorie, cnd un test i aloc memorie i apoi nu o mai dealoc. Testul pare sfuncioneze corect, ns dup ce este rulat de mai multe ori, memoria disponibil se reduce iarsistemul cade.1.3 Concluzii

n acest curs s-a fcut mai nti o introducere n problematica domeniului inginerieiprogramrii, insistndu-se pe cauzele care au determinat dezvoltarea sa: creterea continu acomplexitii sistemelor software. Apoi s-au descris cele patru faze fundamentale alemetodologiilor ingineriei programrii: analiza, proiectarea, implementarea i testarea,necesare pentru realizarea unor sisteme de calitate.

10/132

2 Metodologii de dezvoltare a programelor1. Etapele dezvoltrii programelor2. Metodologii generice2.1. Metodologia secvenial2.2. Metodologia ciclic2.3. Metodologia hibrid ecluz3. Metodologii concrete3.1. Metodologia cascad3.2. Metodologia spiral3.3. Metodologia spiral WinWin3.4. Prototipizarea3.5. Metodologia Booch3.6. Metode formale3.7. Extreme Programming4. Concluzii

2.1 Etapele dezvoltrii programelorCnd pornim la dezvoltarea unui program avem nevoie de:

nelegere clar a ceea ce se cere; un set de metode i instrumente de lucru; un plan de aciune.

Planul de aciune se numete metodologie de dezvoltare. Dezvoltarea unui anumitprogram const ntr-un set de pai ce se fac pentru a-1 realiza. Lund n considerare tipulpailor ce se efectueaz se creeaz un model de lucru, ce poate fi aplicat unei serii mai largi deproiecte. Acesta este motivul pentru care planul de aciune este numit model: el poate fi privitca un ablon al dezvoltrii de programe, n timpul dezvoltrii programelor s-a constatat cexist anumite tipuri de activiti care trebuie fcute la un moment dat:

Analiza cerinelor: Se stabilete ce anume vrea clientul ca programul s fac.Scopul este nregistrarea cerinelor ntr-o manier ct mai clar i mai fidel.Claritatea se refer la lipsa ambiguitii iar fidelitatea la nregistrarea ct maiexact (posibil cuvnt cu cuvnt);

Proiectarea arhitectural: Din motive de complexitate, programele mari nu pot ficoncepute i implementate ca o singur bucat. Programul va trebui construitaadar din module sau componente. Proiectarea arhitectural mparte sistemulntr-un numr de module mai mici i mai simple, care pot fi abordate individual;

Proiectarea detaliat: Se realizeaz proiectarea fiecrui modul al aplicaiei, ncele mai mici detalii;

Scrierea codului: Proiectul detaliat este transpus ntr-un limbaj de programare.De obicei, aceasta se realizeaz modular, pe structura rezultat la proiectareaarhitectural;

Integrarea componentelor: Modulele programului sunt combinate n produsulfinal. Rezultatul este sistemul complet, n modelul numit big-bang componentelesunt dezvoltate i testate individual, dup care sunt integrate n sistemul final.Avnd n vedere c funcionarea corect a componentelor individuale a fosttestat, integrarea ar trebui s fie o formalitate. Din pcate, componentele nu potfi testate exhaustiv, iar cnd acestea lucreaz mpreun pot s apar situaii pecare o anumit component nu le-a ntlnit n procesul de testare sau conflictentre anumite componente (de exemplu, conflicte de partajare a resurselor). S-a

11/132

constatat c atunci cnd se aplic acest model, timpul de testare explodeaz,proiectul devenind greu de controlat; aceasta justific denumirea de big-bang".Modelul incremental propune crearea unui nucleu al aplicaiei i integrarea acte o component la un moment dat, urmat imediat de testarea sistemuluiobinut. Astfel, se poate determina mai uor unde anume apare o problema nsistem. Acest tip de integrare ofer de obicei rezultate mai bune dect modelulbig-bang;

Validarea: n procesul de validare ne asigurm c programul ndeplinetecerinele utilizatorului, ntrebarea la care rspundem este: construim produsulcorect? Un exemplu de validare este testul de acceptare, n care produsul esteprezentat clientului. Clientul spune dac este mulumit cu produsul sau dac maitrebuie efectuate modificri;

Verificarea: n procesul de verificare ne asigurm c programul este stabil i cfuncioneaz corect din punctul de vedere al dezvoltatorilor, ntrebarea la carerspundem este: construim corect produsul?

ntreinerea: Dup ce programul este livrat clientului, mai devreme sau maitrziu sunt descoperite defecte sau erori ce trebuie reparate. De asemenea, potaprea schimbri n specificaiile utilizatorilor, care vor diverse mbuntiri,ntreinerea const n gestionarea acestor probleme.

Se poate constata uor c aceste activiti sunt n strns legtur cu cele patru faze aleingineriei programrii: analiza, proiectarea, implementarea i testarea.2.2 Metodologii generice

n acest paragraf, vor fi prezentate trei categorii importante de metodologii: secvenial,ciclic i hibrid, n metodologia secvenial (cascad), cele patru faze urmeaz una alteiantr-o modalitate serial, n metodologia ciclic (spiral), fazele sunt dispuse n cicluri care igenereaz incremental contribuiile la sistemul final. Metodologia hibrid (ecluz) combinprogresul constant al metodologiei secveniale cu incrementale iterative ale metodologieiciclice.2.2.1 Metodologia secvenial

n metodologia secvenial, cunoscut i sub numele de metodologia cascad", are locmai nti faza de analiz, apoi cea de proiectare, urmat de cea de implementare, iar n final serealizeaz testarea. Echipele care se ocup de fiecare faz pot fi diferite, iar la fiecare tranziiede faz poate fi necesar o decizie managerial.

Figura 2-1 Metodologia secvenialAvantajeMetodologia secvenial este potrivit cnd complexitatea sistemului este mic iar

cerinele sunt statice. Ea spune c mai nti trebuie s ne gndim ce trebuie construit, apoi sstabilim un plan de lucru i apoi s realizm proiectul, innd cont de standardele de calitate.De asemenea, se aliniaz metodelor de inginerie hardware. Foreaz meninerea uneidiscipline de lucru care evit presiunea scrierii codului nainte de a cunoate precis ce produsva trebui de fapt construit. De multe ori, echipa de implementare se afl n situaia de aprograma nainte de finalizarea analizei, ceea ce conduce inevitabil la descoperirea unor pride cod inutile sau care contribuie foarte puin (poate chiar i ineficient) la funcionalitateaprodusului final. Totui, acest cod devine un balast foarte costisitor: dificil de abandonat i

12/132

greu de schimbat. Aceast metodologie foreaz analiza i planificarea naintea implementrii,o practic foarte nimerit n multe situaii.

Un mare numr de sisteme software din trecut au fost construite cu o metodologiesecvenial. Multe companii i datoreaz succesul acestui mod de realizare a programelor.Trebuie spus totui i c presiunea de schimbare din partea surselor externe era destul delimitat la momentul respectiv.

DezavantajeUnul din principalele dezavantaje ale metodologiei secveniale este faptul c acord o

foarte mare importan fazei de analiz. Membrii echipei de analiz ar trebui s fie probabilclarvztori ca s poat defini toate detaliile aplicaiei nc de la nceput. Greelile nu suntpermise, deoarece nu exist un proces de corectare a erorilor dup lansarea cerinelor finale.Nu exist nici feedback de la echipa de implementare n ceea ce privete complexitateacodului corespunztor unei anumite cerine. O cerin simplu de formulat poate creteconsiderabil complexitatea implementrii, n unele cazuri, este posibil s fie chiar imposibilde implementat cu tehnologia actual. Dac echipa de analiz ar ti c o cerin nu poate fiimplementat, ei ar putea-o schimba cu o cerin diferit care s satisfac cele mai multedintre necesiti i care s fie mai uor de efectuat.

Comunicarea dintre echipe este o problem: cele patru echipe pot fi diferite iarcomunicarea dintre ele este limitat. Modul principal de comunicare sunt documentelerealizate de o echip i trimise urmtoarei echipe cu foarte puin feedback. Echipa de analiznu poate avea toate informaiile privitoare la calitate, performan i motivare.

ntr-o industrie n continu micare, metodologia secvenial poate produce sistemecare, la vremea lansrii, s fie deja nvechite. Accentul att de mare pus pe planificare nupoate determina rspunsuri suficient de rapide la schimbare. Ce se ntmpl dac clientul ischimb cerinele dup terminarea fazei de analiz? Acest lucru se ntmpl ns frecvent;dup ce clientul vede prototipul produsului, el i poate schimba unele cerine.2.2.2 Metodologia ciclic

Metodologia ciclic, cunoscut i sub numele de metodologia spiral", ncearc srezolve unele din problemele metodologiei secveniale. i aceast metodologie are patru faze,ns n fiecare faz se consum un timp mai scurt, dup care urmeaz mai multe iteraii printoate fazele. Ideea este de fapt urmtoarea: gndete un pic, planific un pic, implementeazun pic, testeaz un pic i apoi ia-o de la capt. In mod ideal, fiecrei faze trebuie s i se acordeatenie i importan egale.

Documentele de la fiecare faz i schimb treptat structura i coninutul, la fiecare ciclusau iteraie. Pe msur ce procesul nainteaz, sunt generate din ce n ce mai multe detalii. Infinal, dup cteva cicluri, sistemul este complet i gata de lansare. Procesul poate nscontinua pentru lansarea mai multor versiuni ale produsului.

Figura 2-2 Metodologia ciclicAvantajeMetodologia ciclic se bazeaz pe ideea perfecionrii incrementale ale metodologiei

secveniale. Permite feedback-ul de la fiecare echip n ceea ce privete complexitateacerinelor. Exist etape n care pot fi corectate eventualele greeli privind cerinele. Clientulpoate arunca o privire asupra rezultatului i poate oferi informaii importante mai ales n fazadinaintea lansrii produsului. Echipa de implementare poate trimite echipei de analiz

13/132

informaii privind performanele i viabilitatea sistemului. Acesta se poate adapta mai bineprogresului tehnologic: pe msur ce apar noi soluii, ele pot fi ncorporate n arhitecturaprodusului.

DezavantajeMetodologia ciclic nu are nici o modalitate de supraveghere care s controleze

oscilaiile de la un ciclu la altul. In aceast situaie, fiecare ciclu produce un efort mai mare demunc pentru ciclul urmtor, ceea ce ncarc orarul planificat i poate duce la eliminarea unorfuncii sau la o calitate sczut. Lungimea sau numrul de cicluri poate crete foarte mult. Devreme ce nu exist constrngeri asupra echipei de analiz s fac lucrurile cum trebuie deprima dat, acest fapt duce la scderea responsabilitii. Echipa de implementare poate primisarcini la care ulterior se va renuna. Echipa de proiectare nu are o viziune global asupraprodusului i deci nu poate realiza o arhitectur complet. Nu exist termene limit precise.Ciclurile continu fr o condiie clar de terminare. Echipa de implementare poate fi pus nsituaia nedorit n care arhitectura i cerinele sistemului sunt n permanen schimbare.2.2.3 Metodologia hibrid ecluz

Metodologia ecluz (engl. watersluice"), propus de Ronald LeRoi Burback (1998),separ aspectele cele mai importante ale procesului de dezvoltare a unui produs software dedetaliile mai puin semnificative i se concentreaz pe rezolvarea primelor. Pe msur ceprocesul continu, detaliile din ce n ce mai fine sunt rafinate, pn cnd produsul poate filansat. Aceast metodologie hibrid preia natura iterativ a metodologiei spiral, la careadaug progresul sigur al metodologiei cascad.

AnalizaProiectare

ImplementareTestare

ProiectareImplementare

Testare

ImplementareTestare

Testare

Produs

Schita de principiu

Prototip

Alfa / Beta

Produs

Figura 2-3 Metodologia hibrid ecluzLa nceput, ntr-un proces iterativ, fazele de analiz, proiectare, implementare i testare

sunt mprite n mai multe sarcini poteniale, fiecruia atribuindu-i-se o prioritate carereflect beneficiul ndeplinirii sarcinii respective pentru scopul final. La fiecare moment seexecut sarcina cu prioritate maxim. In funcie de dimensiunea echipelor, mai multe sarcinipot fi realizate n paralel. Sarcinile rmase, de prioritate minim, sunt pstrate pentru

14/132

examinare ulterioar. Descompunerea problemei este foarte important. Cu ctdescompunerea i stabilirea prioritilor sunt mai bune, cu att mai eficient este metodologia.

Pe msur ce sarcinile stabilite sunt ndeplinite, noi sarcini pot fi descoperite. Acesteasunt adugate sarcinilor rmase nesoluionate i se reatribuie prioritile. Procesul continupn cnd produsul este gata de lansare.

Prioritile se stabilesc pe baza unei funcii de prioritate, care depinde att de domeniulproblemei i de normele firmei. Ea trebuie s realizeze un compromis ntre cantitate icalitate, ntre funcionalitate i constrngerile privind resursele, ntre ateptri i realitate.Toate funciile de prioritate ar trebuie s aib ca prim scop lansarea produsului.

Pe lng rolul evident de a stabili prioritile i deci ordinea de execuie a sarcinilor delucru, funcia mai trebuie s gestioneze sarcinile conflictuale i nemonotone. Ea trebuie smpart aceste sarcini n grupuri consistente, s reglementeze selecia grupurilor consistente iapoi s dirijeze selecia sarcinilor din cadrul grupurilor. Pe msur ce sistemul crete, funciade prioritate trebuie s aleag sarcini consistente cu partea deja constituit din sistem. Osarcin nemonoton vine n contradicie cu sistemul realizat deja i trebuie eliminat dac nueste absolut necesar pentru succesul sistemului.

Odat ce o component este terminat i acceptat de echip, schimbrile asupra sa suntngheate. Componenta va fi schimbat numai dac modificrile sunt absolut necesare iarechipa este dispus s ntrzie lucrul la restul sistemului pentru a le efectua. Schimbriletrebuie s fie puine la numr, bine justificate i documentate.

Etapele principale ale metodei sunt: schia de principiu, prototipul, versiunile alfa/betai produsul final.

n prima etap, schia de principiu, echipele lucreaz simultan la toate fazele problemei.Echipa de analiz sugereaz cerinele. Echipa de proiectare le discut i trimite sarcinilecritice de implementare echipei de implementare. Echipa de testare pregtete i dezvoltmediul de test n funcie de cerine. Echipa de implementare se concentreaz asupra sarcinilorcritice, care n general sunt cele mai dificile. Aceast abordare contrasteaz cu practicacurent de realizare mai nti a sarcinilor simple. Totui, majoritatea produselor care urmeazacest model eueaz. Odat ce componentele critice au fost realizate, sistemul este gata de aface tranziia ctre stadiul de prototip. Unul din scopurile aceste etape este de a se convingeechipele c o soluie poate fi gsit i pus n practic.

n cea de a doua etap, de prototip, cerinele i documentul cerinelor sunt ngheate.Schimbrile n cerine sunt nc permise, ns ar trebuie s fie foarte rare i numai dac suntabsolut necesare, deoarece modificrile cerinelor n acest stadiu al proiectului sunt foartecostisitoare. Este posibil totui ajustarea arhitecturii, pe baza noilor opiuni datoratetehnologiei. Dup ce sarcinile critice au fost terminate, echipa de implementare se poateconcentra pe extinderea acestora, pentru definirea ct mai multor aspecte ale aplicaiei. Unuldin scopurile acestei etape este de a convinge persoanele din afara echipelor c o soluie esteposibil.

Acum produsul este gata pentru lansarea versiunilor alfa i beta. Arhitectura estengheat, iar accentul cade pe implementare i asigurarea calitii. Prima versiune lansat senumete n general alfa. Produsul este nc imatur; numai sarcinile critice au fostimplementate la calitate ridicat. Numai un numr mic de clieni sunt n general dispui saccepte o versiune alfa i s-i asume riscurile asociate. O a doua lansare reprezint versiuneabeta. Rolul su este de a convinge clienii c aplicaia va fi un produs adevrat i de aceea seadreseaz unui numr mai mare de clieni. Cnd o parte suficient de mare din sistem a fostconstruit, poate fi lansat n sfrit produsul. n aceast etap, implementarea este ngheat iaccentul cade pe asigurarea calitii. Scopul este realizarea unui produs competitiv. Inprodusul final nu se accept erori critice.

Avantaje

15/132

Metodologia ecluz recunoate faptul c oamenii fac greeli i c nici o decizie nutrebuie s fie absolut. Echipele nu sunt blocate ntr-o serie de cerine sau ntr-o arhitecturimobil care se pot dovedi mai trziu inadecvate sau chiar greite. Totui, pentru respectareatermenelor limit, metodologia impune date de ngheare a unor faze. Exist timp suficientpentru corectarea greelilor decizionale pentru atingerea unui nivel suficient de ridicat dencredere. Se pune mare accent pe comunicarea ntre echipe, ceea ce reduce cantitatea de codinutil la care ar trebui s se renune n mod normal. Metodologia ncearc s mute toate erorilela nceputul procesului, unde corectarea, sau chiar renceperea de la zero a lucrului, nu suntfoarte costisitoare.

DezavantajeMetodologia presupune asumarea unor responsabiliti privind delimitarea etapelor i

nghearea succesiv a fazelor de dezvoltare. Ea presupune crearea unui mediu de lucru ncare acceptarea responsabilitii pentru o decizie care se dovedete mai trziu greit s nu serepercuteze n mod negativ asupra individului. Se dorete de asemenea schimbarea atitudiniiechipelor fa de testare, care are loc nc de la nceput, i fa de comunicarea continu, carepoate fi dificil, ntruct cele patru faze reprezint perspective diferite asupra realizriiprodusului.2.3 Metodologii concrete2.3.1 Metodologia cascad

Metodologia cascad, propus de Barry Boehm, este una din cele mai cunoscuteexemple de metodologie de ingineria programrii. Exist numeroase variante ale acestuiproces. Intr-o variant detaliat, metodologia cascad cuprinde urmtoarele etape:

Cerinte sistem si validare

Cerinte software si validare

Analiza si validare

Proiectare detaliata si validare

Scriere cod si debug

Testare si validare

Intretinere si revalidare

Figura 2-4 Metodologia cascadDup fiecare etap exist un pas de validare. Procesul curge" de la etap la etap, ca

apa ntr-o cascad, n descrierea originar a lui Boehm, exist o ntoarcere, un pas napoiinteractiv ntre fiecare dou etape. Astfel, metoda cascad este de fapt o combinaie demetodologie secvenial cu elemente ciclice. Totui, n practica inginereasc, termenulcascad" este utilizat ca un nume generic pentru orice metodologie secvenial.

16/132

Acesta este modelul dup care de obicei sistemele sunt dezvoltate n practic. Deasemenea, reordonarea fazelor s-a dovedit a fi sub-optimal. Exist o mare atracie pentruacest model datorit experienei, tradiiei n aplicarea sa i succesului pe care 1-a implicat. Osarcin complex este mprit n mai muli pai mici, ce sunt mai uor de administrat.Fiecare pas are ca rezultat un produs bine definit (documente de specificaie, model, etc.)

Modelul cascad cu feedback propune remedierea problemelor descoperite n pasulprecedent. Problemele la pasul /' care sunt descoperite la pasul / + 3 rmn neremediabile. Unmodel realist ar trebui s ofere posibilitatea ca de la un anumit nivel s se poat reveni laoricare dintre nivelele anterioare.

Dezavantajul principal al modelului n cascad apare deoarece clientul obine o viziunepractic asupra produsului doar n momentul terminrii procesului de dezvoltare. Deasemenea, modelul nu are suficient putere descriptiv, n sensul c nu integreaz activiti camanagementul resurselor sau managementul configuraiei. Aceasta face dificil coordonareaproiectului.

Dup cum am menionat la prezentarea metodologiei generice secveniale, i modelulcascad impune nghearea specificaiilor foarte devreme n procesul de dezvoltare pentru aevita iteraiile frecvente (rentoarcerile n fazele anterioare atunci cnd n faza curent s-audetectat erori: n timpul analizei se descoper erori de specificaii, n timpul implementrii sedescoper erori de specificaii/proiectare etc., astfel nct procesul poate implica multiplesecvene de iteraii ale activitilor de dezvoltare), nghearea prematur a cerinelor conducela obinerea unui produs prost structurat i care nu execut ceea ce dorete utilizatorul.Conduce de asemenea la obinerea unei documentaii neadecvate deoarece schimbrileintervenite n iteraiile frecvente nu sunt actualizate n toate documentele produse.2.3.2 Metodologia spiral

Metodologia spiral, propus tot de Boehm, este un alt exemplu bine cunoscut demetodologie a ingineriei programrii. Acest model ncearc s rezolve problemele modeluluin cascad, pstrnd avantajele acestuia: planificare, faze bine definite, produse intermediare.El definete urmtorii pai n dezvoltarea unui produs:

studiul de fezabilitate; analiza cerinelor; proiectarea arhitecturii software; implementarea.

Modelul n spiral recunoate c problema principal a dezvoltrii programelor esteriscul. Riscul nu mai este eliminat prin aseriuni de genul: n urma proiectrii am obinut unmodel corect al sistemului", ca n modelul cascad. Aici riscul este acceptat, evaluat i se iaumsuri pentru contracararea efectelor sale negative. Exemple de riscuri:

n timpul unui proces ndelungat de dezvoltare, cerinele noi ale clientului suntignorate;

clientul schimb cerinele; o firm concurent lanseaz un program rival pe pia; un dezvoltator/arhitect prsete echipa de dezvoltare; o echip nu respect un termen de livrare pentru o anumit component.

In modelul spiral se consider c fiecare pas din dezvoltare conine o serie de activiticomune:

pregtirea: se identific obiectivele, alternativele, constrngerile; gestionarea riscului: analiza i rezolvarea situaiilor de risc; activiti de dezvoltare specifice pasului curent (de exemplu analiza

specificaiilor sau scrierea de cod);

17/132

planificarea urmtorului stadiu: termenele limit, resurse umane, revizuirea striiproiectului.

Metodologia spiral cuprinde urmtoarele etape, grupate pe patru cicluri:

12

3

4

5

6

78

9

10

11

12

13

14

15

16

17

18 1920

21

Figura 2-5 Metodologia spiral

Ciclul l - Analiza preliminar:1. Obiective, alternative, constrngeri2. Analiza riscului i prototipul3. Conceperea operaiilor4. Cerinele i planul ciclului de via5. Obiective, alternative, constrngeri6. Analiza riscului i prototipul

Ciclul 2 - Analiza final:7. Simulare, modele, benchmark-uri8. Cerine software i validare9. Plan de dezvoltare10. Obiective, alternative, constrngeri11. Analiza riscului i prototipul

Ciclul 3 - Proiectarea:12. Simulare, modele, benchmark-uri13. Proiectarea produsului software, validare i verificare14. Integrare i plan de test15. Obiective, alternative, constrngeri16. Analiza riscului i prototipul operaional

Ciclul 4 - Implementarea i testarea:17. Simulare, modele, benchmark-uri18. Proiectare detaliat19. Cod20. Integrarea unitilor i testarea acceptrii21. Lansarea produsului

18/132

Procesul ncepe n centrul spiralei. Fiecare ciclu terminat reprezint o etap. Pe msurce spirala este parcurs, produsul se maturizeaz. Cu fiecare ciclu, sistemul se apropie desoluia final. Dei este considerat ca un exemplu generic pentru metodologia ciclic, metodaare i elemente secveniale, puse n eviden de evoluia constant de la o etap la alta.2.3.3 Metodologia spiral WinWin

Aceast metodologie extinde spirala Boehm prin adugarea unui pas de stabilire aprioritii la nceputul fiecrui ciclu din spiral i prin introducerea unor scopuri intermediare,numite puncte ancor. Procesul WinWin identific un punct de decizie. Pentru fiecare punctde decizie, se stabilesc obiectivele, constrngerile i alternativele.

Punctele ancor stabilesc trei scopuri intermediare. Primul punct ancor, numitobiectivul ciclului de via, precizeaz cazurile sigure de funcionare pentru ntregul sistem,artnd c exist cel puin o arhitectur fezabil (adic posibil din punct de vedere practic)care satisface scopurile sistemului. Primul scop intermediar este stabilit cnd sunt terminateobiectivele de nivel nalt ale sistemului, arhitectura, modelul ciclului de via i prototipulsistemului. Aceast prim ancor spune de ce, ce, cnd, cine, unde, cum i estimeaz costulprodusului. Dup executarea acestor operaii, este disponibil analiza de nivel nalt asistemului.

Al doilea punct ancor definete arhitectura ciclului de via, iar al treilea - capacitateaoperaional iniial, incluznd mediul software necesar, hardware-ul, documentaia pentruclient i instruirea acestuia.

Aceste puncte ancor corespund etapelor majore din ciclul de via al unui produs:dezvoltarea iniial, lansarea, funcionarea, ntreinerea i ieirea din funciune.2.3.4 Prototipizarea

O problem general care apare la dezvoltarea unui program este s ne asigurm cutilizatorul obine exact ceea ce vrea. Prototipizarea vine n sprijinul rezolvrii acesteiprobleme, nc din primele faze ale dezvoltrii, clientului i se prezint o versiune funcionala sistemului. Aceast versiune nu reprezint ntregul sistem, ns este o parte a sistemului carecel puin funcioneaz.

Prototipul ajut clientul n a-i defini mai bine cerinele i prioritile. Prin intermediulunui prototip, el poate nelege ce este posibil i ce nu din punct de vedere tehnologic.Prototipul este de obicei produs ct mai repede; pe cale de consecin, stilul de programareeste de obicei (cel puin) neglijent. Ins scopul principal al prototipului este de a ajuta nfazele de analiz i proiectare i nu folosirea unui stil elegant.

Se disting dou feluri de prototipuri: de aruncat (throw-away); evoluionar.

n cazul realizrii unui prototip de aruncat, scopul este exclusiv obinerea uneispecificaii. De aceea nu se acord nici o importan stilului de programare i de lucru,punndu-se accent pe viteza de dezvoltare. Odat stabilite cerinele, codul prototipului estearuncat", sistemul final fiind rescris de la nceput, chiar n alt limbaj de programare.

n cazul realizrii unui prototip evoluionar, scopul este de a crea un schelet al aplicaieicare s poat implementa n prim faz o parte a cerinelor sistemului. Pe msur ce aplicaiaeste dezvoltat, noi caracteristici sunt adugate scheletului existent, n contrast cu prototipulde aruncat, aici se investete un efort considerabil ntr-un design modular i extensibil,precum i n adoptarea unui stil elegant de programare.

Aceast metod are urmtoarele avantaje: permite dezvoltatorilor s elimine lipsa de claritate a specificaiilor;

19/132

ofer utilizatorilor ansa de a schimba specificaiile ntr-un mod ce nu afecteazdrastic durata de dezvoltare;

ntreinerea este redus, deoarece validarea se face pe parcursul dezvoltrii; se poate facilita instruirea utilizatorilor finali nainte de terminarea produsului.

Dintre dezavantajele principale ale prototipizrii amintim: deoarece prototipul ruleaz ntr-un mediu artificial, anumite dezavantaje ale

produsului final pot fi scpate din vedere de clieni; clientul nu nelege de ce produsul necesit timp suplimentar pentru dezvoltare,

avnd n vedere c prototipul a fost realizat att de repede; deoarece au n fiecare moment ansa de a face acest lucru, clienii schimb

foarte des specificaiile; poate fi nepopular printre dezvoltatori, deoarece implic renunarea la propria

munc.2.3.5 Metodologia Booch

Aceast metodologie asigur o dezvoltare orientat obiect n fazele de analiz iproiectare. Faza de analiz este mprit n mai muli pai. Primul pas este stabilireacerinelor din perspectiva clientului, genernd o descriere de nivel nalt a funcionrii istructurii sistemului. Al doilea pas este analiza domeniului, realizat prin definirea claselor:atributele, metodele, motenirea. Faza de analiz este terminat cu un pas de validare. Aceastfaz itereaz cei trei pai pn cnd soluia este consistent.

i faza de proiectare este iterativ. Design-ul logic este transformat n design fizic, cudetalii privind firele de execuie, procesele, performanele, tipurile de date, structurile de dateetc. Se creeaz un prototip i apoi se testeaz. Faza itereaz design-ul logic, cel fizic,prototipurile i testarea.

Metodologia Booch este secvenial n sensul c mai nti este terminat analiza i apoiproiectarea. Ea este ciclic datorit iteraiilor din fiecare faz. Metoda se concentreaz nspecial asupra acestor dou faze, de analiz i proiectare, fr s insiste foarte mult asupraimplementrii i testrii.2.3.6 Metode formale

In acest model de dezvoltare, sunt folosite formalismul i rigoarea matematicii. In primafaz este construit o specificaie n limbaj matematic. Apoi, aceast specificaie estetransformat n programe, de obicei ntr-un proces incremental.

Avantaje: precizia obinut prin specificarea formal; pstrarea corectitudinii n timpul transformrii specificaiei n cod executabil; ofer posibilitatea generrii automate de cod; sunt potrivite pentru sisteme cu cerine critice.

Dezavantaje: specificarea formal este de obicei o barier de comunicare ntre client i analist; necesit personal foarte calificat (deci mai scump); folosirea impecabil a tehnicilor specificrii formale nu implic neaprat

obinerea de programe sigure, deoarece anumite aspecte critice pot fi omise dinspecificaiile iniiale.

2.3.7 Extreme ProgrammingExtreme Programming (Kent Beck, 1996) este o metodologie care propune rezolvri

originale pentru problemele care apar n dezvoltarea de programe. Fiind o tehnologie nou (i

20/132

extrem) are att adepi ct i critici. XP consider c dezvoltarea programelor nu nseamnierarhii, responsabiliti i termene limit, aa cum se afl acestea pe masa administratorului,ci nseamn colaborarea oamenilor din care este format echipa. Acetia sunt ncurajai s iafirme personalitatea, s ofere i s primeasc cunotine i s devin programatori strlucii.

De asemenea, XP consider c dezvoltarea de programe nseamn n primul rndscrierea de programe. Aceast sintagm banal se pare c este uitat de multe companii carese ascund n spatele proceselor de dezvoltare stufoase, a edinelor i a rapoartelor deactivitate. XP ne amintete cu respect ca fiierele PowerPoint nu se pot compila.

De altfel, inspirarea proceselor de dezvoltare a programelor din ingineria construciilorse pare c nu este cea mai fericit alegere. Este adevrat c un inginer care vrea sconstruiasc un pod peste un ru face mai nti msurtori, realizeaz un proiect i abia apoitrece la execuie, toate acestea ntr-un mod secvenial i previzibil. Dar dezvoltarea deprograme nu seamn cu aa ceva, orict am vrea s credem asta. Dac ingineruluiconstructor respectiv i s-ar schimba cerinele de rezisten i i s-ar muta malurile chiar cnd aterminat de construit jumtate de pod, putem fi siguri c acel inginer i-ar schimba modul delucru. Din pcate ns, nu tim (nc) cum.

Iniiatorii XP definesc urmtoarele dou carte, ca baz filosofic pentru aceastmetodologie.

Carta drepturilor dezvoltatorului: Ai dreptul s tii ceea ce se cere, prin cerine clare, cu declaraii clare de

prioritate; Ai dreptul s spui ct i va lua s implementezi fiecare cerin, i s i

revizuieti estimrile n funcie de experien; Ai dreptul s i accepi responsabilitile, n loc ca acestea s-i fie asignate; Ai dreptul s faci treab de calitate n orice moment; Ai dreptul la linite, distracie i la munc productiv i plcut. Carta drepturilor clientului: Ai dreptul la un plan general, s tii ce poate fi fcut, cnd, i la ce pre; Ai dreptul s vezi progresul ntr-un sistem care ruleaz i care se dovedete c

funcioneaz trecnd teste repetabile pe care le specifici tu; Ai dreptul s te rzgndeti, s nlocuieti funcionaliti i s schimbi

prioritile; Ai dreptul s fii informat de schimbrile n estimri, suficient de devreme pentru

a putea reduce cerinele astfel ca munca s se termine la data prestabilit. Poichiar s te opreti la un moment dat i s rmi cu un sistem folositor care sreflecte investiia pn la acea dat.

Aceste afirmaii, dei par de la sine nelese, conin semnificaii profunde. Multe dinproblemele aprute n dezvoltarea programelor pornesc de la nclcarea acestor principii.Enumerm pe scurt cteva dintre caracteristicile XP:

Echipa de dezvoltare nu are o structur ierarhic. Fiecare contribuie la proiectfolosind maximul din cunotinele sale;

Scrierea de cod este activitatea cea mai important; Proiectul este n mintea tuturor programatorilor din echip, nu n documentaii,

modele sau rapoarte; La orice moment, un reprezentant al clientului este disponibil pentru clarificarea

cerinelor; Codul se scrie ct mai simplu; Se scrie mai nti cod de test; Dac apare necesitatea rescrierii sau eliminrii codului, aceasta se face fr mil;

21/132

Modificrile aduse codului sunt integrate continuu (de cteva ori pe zi); Se programeaz n echip (programare n perechi). Echipele se schimb la

sfritul unei iteraii (1-2 sptmni); Se lucreaz 40 de ore pe sptmn, fr lucru suplimentar.

2.4 ConcluziiAu fost prezentate aici cele mai importante metodologii de dezvoltare a programelor.

Mai nti au fost descrise metodologiile generice: secvenial, ciclic i hibrid, cu avantajelei dezavantajele fiecreia. Apoi s-au amintit cteva metode concrete de dezvoltate: modelulcascad, modelul spiral, WinWin, prototipizarea, metodologia Booch, metodele formale iaa-numita programare extrem".

22/132

3 Managementul unui proiect software3.1 Managementul software

Multe proiecte de dezvoltare software au probleme, mai devreme sau mai trziudeoarece ori programul nu este livrat la timp, ori bugetul este depit, ori clienii suntnemulumii. De multe ori cauzele sunt de natur tehnic. Ins, n la fel de multe situaii,problemele i au originea n organizarea i managementul proiectului. Cnd un produs estelivrat prea trziu, motivele prezentate sunt n general urmtoarele:

programatorii nu au spus adevrul despre situaia real a codului; clientul nu tia ce vrea de fapt; echipa de management a subestimat timpul necesar terminrii proiectului; echipa de management nu a acordat suficient timp pentru planificarea atent a

proiectului; productivitatea programatorilor s-a dovedit mult inferioar ateptrilor.

Aparent, nu e simplu s termini cu succes un proiect de dezvoltare software. Pe lngaspectele tehnice, legate n general de cele patru faze prezentate anterior (analiz, proiectare,implementare, testare), s-a dovedit c aspectele privind organizarea i managementulproiectului sunt cel puin la fel de importante.

Un proiect de dezvoltare software nu este de obicei complet izolat. In cadrul firmei sepoate lucra i la alte proiecte i deci poate fi necesar identificarea unor legturi ntre proiecte,stabilirea de prioriti etc. Pentru acest proces de meta-planificare (planificare a planificrii)se folosete deseori termenul planificare informaional. Scopul su este precizarea unorcondiii sau constrngeri pentru fiecare proiect concret.

De asemenea, nici din punct de vedere tehnic programul nu este pornit de la zero. Eltrebuie s fie interfaat cu programe existente, s extind funcionalitatea altor programe, sfoloseasc biblioteci de funcii etc. De fapt, nsui termenul de dezvoltare software poate ficonsiderat nepotrivit. Nu doar programul este dezvoltat, ci un ntreg sistem. Software-ul este ocomponent principal, dar nu este unic.

S considerm un sistem pentru automatizarea unei biblioteci. El va conine diversecomponente soft, precum baze de date despre cri i persoane sau interfee pentru prelucrareainteractiv a cererilor utilizatorilor. Pe lng acestea, trebuie gsite modaliti de rezolvare aunor probleme de genul:

identificarea electronic a crilor prin coduri de bare; achiziionarea de componente hardware care s scaneze aceste coduri i s

creeze elemente de identificare pentru crile noi; instruirea bibliotecarilor pentru utilizarea noilor instrumente de lucru (cursuri,

instruire practic etc.); alctuirea unei documentaii prietenoase pentru abonai.

Un proiect de dezvoltare software poate fi vzut astfel:

23/132

ProgramProgram

Software

Oameni Documentatie

Proceduri

Intrare Iesire

Const

ranger

i

Figura 3-1 Abordarea sistemic a unui proiect de dezvoltare softwareSe observ c sistemul cuprinde un numr de componente. La rndul su, n sens mai

restrns, i componenta software poate include mai multe module de program careinteracioneaz i asigur funcionalitatea dorit n mod colectiv.

Pe baza constrngerilor, se ncepe lucrul la un anumit proiect concret. Primul pas, demare importan, este planificarea proiectului. Apoi, pe parcursul execuiei trebuie controlatecinci entiti: timpul, informaiile, organizarea, calitatea i banii.3.1.1 Planificarea proiectului

Planificarea proiectului presupune identificarea proprietilor care vor influenadezvoltarea. Aceste proprieti nu sunt foarte bine nelese dect dup terminarea fazei deanaliz. De aceea, planificarea are n mod necesar o natur dinamic.

Cooper (1984) subliniaz 13 elemente importante ale planului proiectului:b) Introducerea: Sunt descrise condiiile i istoricul proiectului, mpreun cu

scopurile, numele persoanelor responsabile i un sumar al proiectului;c) Implicarea utilizatorului: Viitorii utilizatori vor fi implicai din timp n timp

n proiect. Planul trebuie s cuprind ce informaii, servicii i resurse suntasigurate de utilizatori i cnd se va ntmpla acest lucru;

d) Riscurile: In orice moment exist riscuri: hardware-ul nu va fi livrat la timp,personalul calificat este insuficient, lipsesc informaii eseniale .a.m.d. n modideal, riscurile poteniale trebuie identificate ct mai devreme i echipa demanagement trebuie s ia msuri pentru eliminarea lor. Pe msur cenecunoscutele proiectului devin mai numeroase, crete i numrul riscurilor;

e) Standardele, tehnicile, procedurile: Proiectele software sunt proiecte mari, ncare sunt implicate multe persoane. De aceea, este nevoie de o disciplin delucru clar, bazat pe standarde i proceduri asupra crora toat lumea a czutde acord. O mare importan o are documentaia: cnd trebuie livrat, cum esteevaluat calitatea sa, cum se asigur permanenta sa actualizare;

24/132

f) Organizarea proiectului: n cadrul echipei proiectului se identific diverseroluri: project manager, tester, programator, analist etc. Aceste roluri trebuieclar delimitate iar atribuiile fiecruia trebuie bine precizate i clarificate. Inacest scop, poate fi necesar o perioad de instruire a membrilor echipei;

g) Fazele proiectului: n primul curs au fost amintite fazele de dezvoltare aleunui produs software. Metodologiile de aplicare a acestora sunt numeroase.Echipa de management trebuie s se decid care model va fi urmat i care suntpaii obligatorii. Proiectul trebuie divizat n pri gestionabile care pot fialocate unor echipe diferite. De asemenea, trebuie estimate timpul i costulfiecrei faze. Tipuri diferite de proiecte au diferite caracteristici i necesitdeci modele diferite;

h) Analiza cerinelor i proiectarea: Se indic metodele i tehnicile care vor fiutilizate n analiz i proiectare, precum i resursele i instrumentele necesarepentru acestea;

i) Implementarea: Se identific resursele i instrumentele necesare pentruimplementare i se precizeaz cum va fi gestionat volumul foarte mare dedocumentaie tehnic ce va rezulta de aici;

j) Testarea: Se descriu mediile i echipamentele de test necesare;k) Resursele: Sunt enumerate resursele hardware i instrumentele necesare

pentru proiect;l) Asigurarea calitii: Se identific procedurile care vor fi folosite pentru a

verifica dac proiectul ndeplinete standardele de calitate dorite;m) Modificrile: Pentru un proiect, modificrile sunt inevitabile. Echipa de

management trebuie s se asigure c aceste schimbri sunt tratate ntr-un modorganizat, pe baza unor proceduri bine definite. Fiecare modificare propustrebuie nregistrat i revzut. Cnd o modificare este aprobat, se estimeazcosturile corespunztoare. Dup ncorporarea sa n sistemul existent, trebuieredactate noi versiuni ale documentaiei pentru a reflecta schimbrile din cod;

n) Livrarea: n final, trebuie respectate procedurile necesare pentru livrareaprodusului ctre client.

Planul proiectului trebuie s furnizeze o imagine clar a ceea ce trebuie fcut, attpentru client ct i pentru echipa de realizare. Dac obiectivele nu sunt clare, ele nu vor finiciodat ndeplinite.3.1.2 Controlul proiectului

Dup ce planul proiectului a fost realizat i aprobat, poate ncepe executarea propriu-zis. Pe parcursul executrii, trebuie controlate urmtoarele dimensiuni:

timpul; informaiile; organizarea; calitatea; banii.

Cursul de evoluie al proiectului (aspectul timp) este greu de msurat. Afirmaiile degenul 90% din cod a fost deja scris" trebuie cntrite de dou ori nainte de a fi crezute. Deobicei, se prezint o situaie mai bun a proiectului dect este n realitate. Timpul necesarconstruirii unui sistem este n mod evident legat de dimensiunea sa i deci de fora de muncutilizat. Cu ct un sistem este mai mare, cu att este necesar mai mult timp pentrudezvoltarea sa, dei se poate ncerca scurtarea intervalului prin alocarea suplimentar depersonal. Una din problemele care apar aici este gsirea unui compromis ct mai bun ntretimpul de dezvoltare i resursele umane folosite. Totui, cu ct sunt implicate mai multe

25/132

persoane, cu att va crete timpul pentru coordonare i comunicare. Peste un anumit punct,mrirea personalului va avea ca efect creterea timpului de dezvoltare. n acest sens, legea luiBrooks afirm c adugarea de personal la un proiect ntrziat l va ntrzia i mai mult.

Din punctul de vedere al informaiilor, accentul principal cade pe realizareadocumentaiei: documentele utilizatorului, documentele tehnice i documentaia proiectuluinsui, care include starea curent de lucruri, modificrile convenite, deciziile luate.

n cadrul echipei, fiecare persoan trebuie s-i cunoasc foarte clar rolul. Dac rolurilenu sunt definite sau sunt neclare, fiecare individ i va stabili propriile scopuri, care pot intran contradicie cu scopurile proiectului. Project manager-ul trebuie s in seama de acesteaspecte organizaionale la alctuirea echipei i stabilirea atribuiilor.

Calitatea este foarte important, deoarece clienii nu se mulumesc cu soluii purtehnice, ci doresc sisteme adecvate nevoilor lor reale. De multe ori, cerinele de calitate pot ficonflictuale. Pe parcursul executrii proiectului, acestea trebuie mereu evaluate, pentru ca spoat fi luate msuri din timp pentru remedierea problemelor. Calitatea nu trebuie s fie otrstur adugat, ci o caracteristic intrinsec a sistemului.

Controlarea resurselor financiare nseamn n mare parte controlarea costurilor depersonal. Dei costurile asociate hardware-ului i diferitelor instrumente nu poate fi neglijat,acestea pot fi de obicei estimate destul de precis n fazele incipiente ale proiectului. Estimareacostului se reduce astfel la estimarea forei de munc necesare, care depinde de muli factori.Un factor important este dimensiunea software-ului (determinat de exemplu de mrimeacodului). Exist ns i ali factori care influeneaz costurile sau productivitatea. O echipbine echilibrat de persoane experimentate vor avea o productivitate mult mai mare dect oechip nou format de persoane fr experien.3.2 Managementul configuraiei

Pe parcursul ciclului de via al unui proiect de dezvoltare software sunt create iactualizate un mare numr de elemente, precum module de cod surs, cerine de modificareetc. Pentru gestionarea acestora trebuie s existe un set de proceduri bine definite, care poartnumele de managementul configuraiei.

De cele mai multe ori, un sistem .software nu este monolitic. Sistemele exist n diferiteversiuni i configuraii. Versiunile diferite apar atunci cnd sunt fcute modificri dup cesistemul a fost livrat clientului. Din timp n timp, clientul este confruntat cu o nou lansare.Diferite versiuni pot exista i pentru componentele din sistem. Dac o modificare a fostaprobat, un programator poate implementa schimbarea prin rescrierea unei componente, nacelai timp, un altul poate utiliza n continuare versiunea anterioar a aceleiai componente.

La orice moment trebuie s existe o singur versiune oficial setului de documentelegate de proiect. Aceasta se numete linie de baz (engl. baseline"), definit ca standardIEEE: o specificaie sau un produs care a fost analizat i acceptat n mod formal, careservete n continuare ca baz pentru dezvoltarea viitoare i care poate fi modificat numai prinproceduri formale de control al modificrilor". Linia de baz este deci o baz de date partajatcare conine toate entitile aprobate, denumite entiti de configurare (engl. configurationitems"). O entitate de configurare este definit de asemenea ca standard IEEE astfel: ocolecie de elemente hardware sau software tratate ca o unitate n scopul gestionriiconfiguraiei".

Exemple de entiti de configuraie sunt: modulele de cod surs; modulele de cod obiect; specificarea cerinelor; documentaia de proiectare; planul de test;

26/132

cazurile de test; rezultatele de test; manualul utilizatorului.

O sarcin fundamental a managementului configuraiei este meninerea integritiiacestui set de elemente, lucru deosebit de important atunci cnd modificrile sunt integrate nsistem. S presupunem c n faza de testare este descoperit o eroare major ntr-un modul.Atunci toi paii deja efectuai trebuie parcuri n ordine invers i pe lng modificareacodului trebuie modificate i documentele de proiectare sau chiar cerinele. Aceste schimbripot interaciona cu munca altor programatori, care folosesc versiunea anterioar. Mai ru, unalt programator poate efectua propriile sale modificri la acelai modul. Managementulconfiguraiei se ocup de gestionarea tuturor acestor schimbri pe parcursul ntregului ciclu devia al produsului.

Orice modificare propus pentru linia de baz se numete cerere de modificare i estetratat precum urmeaz:

Modificarea este trimis comisiei de control al configuraiei (CCC). Pentruevaluarea propunerii, comisia are nevoie de informaii privind modul n careschimbrile vor afecta produsul i procesul de dezvoltare: volumul de cod nousau modificat, cerine suplimentare de test, legtura cu alte schimbri, costurilepoteniale, complexitatea modificrii, severitatea erorii (dac e cazul), resurselenecesare etc.;

CCC evalueaz cererea, care poate fi aprobat, respins sau amnat dac suntnecesare mai multe informaii. Dac este aprobat, se stabilete un termen deimplementare;

CCC se asigur c toate entitile de configuraie afectate de schimbare vor fiactualizate corespunztor.

Am menionat c entitile din baza de date partajat pot fi utilizate fr restricii de toimembrii echipei. Dac o entitate trebuie modificat, persoana responsabil de schimbareprimete o copie a entitii i apoi entitatea este blocat temporar, astfel nct nimeni s nupoat o modifica n acelai timp. Persoana desemnat acioneaz asupra copiei. Dup cemodificarea este testat, este trimis napoi la CCC. Dup ce comisia o aprob, entitatea esteinclus n baza de date, schimbarea e documentat i apoi entitatea e deblocat. irul demodificri documentate formeaz istoricul reviziei entitii.

Cnd o entitate e modificat, este pstrat i versiunea veche. Aceasta poate fi ncutilizat de alte persoane pn cnd acestea se adapteaz schimbrii. Avnd versiuni diferitepentru aceeai entitate, trebuie s existe o modalitate de a le distinge. De obicei, se prefer oschem numeric, n care fiecare versiune urmtoare este identificat de urmtorul numr.Pentru o component X vom avea deci versiunile X.0, X.1, X.2 .a.m.d.

Schema GNU de numerotare denot versiunea unui produs software printr-un triplet dentregi: versiunea major, versiunea minor i patch-ul. ntre dou versiuni majore, n produsau loc schimbri majore ale funcionalitii i n acest caz nu este garantat compatibilitateanapoi.

Dimpotriv, ntre dou versiuni minore ale aceleiai versiuni majore trebuie s existecompatibilitate. De exemplu, formatele de fiiere suportate de o versiune ulterioar trebuie sfie suportate i de versiunea minor anterioar. Rolul unei versiuni minore este introducereaunor funcii noi. Funciile vechi nu vor fi ndeprtate; totui documentaia programului lpoate avertiza pe utilizator c la anumite funcii se va renuna n viitor.

Patch-ul nu poate realiza dect schimbri n implementarea unor funcii. De obicei,rolul su este corectarea unor erori ale programului.

Aceste reguli nu se aplic ns i pentru programele n versiuni alfa sau beta (O.F).nainte de versiunea 1.0, deoarece programul este n curs de formare, sunt permise modificri

27/132

importante ntre versiuni. Totui, versiunea 1.0 trebuie s reprezinte o platform stabil, cu ctmai puine bug-uri, care s poat fi utilizat cu ncredere de clieni. Nu e neaprat necesar caaceasta s conin ct mai multe funcionaliti, ci ca funciile implementate s fie ct maisigure. Noi funcionaliti pot fi adugate n versiunile urmtoare.

La nivelul codului surs, managementul configuraiei este sprijinit de instrumenteputernice, care blocheaz i deblocheaz elementele, asigur numerotarea automat areviziilor i furnizeaz utilizatorului ultima versiune disponibil.

Un astfel de instrument este CVS (Concurrent Versions System), care permite creareaistoricului schimbrilor din cod. Cnd sursele sunt modificate uneori apar erori, care pot fidetectate abia dup un interval mare de timp de la modificare, n aceste situaii este utilidentificarea versiunilor vechi i implicit a schimbrilor care au produs eroarea. CVS nusalveaz toate fiierele surs din diferitele versiuni, ci numai modificrile aduse fiierelor. Deasemenea, cnd mai muli programatori lucreaz la acelai proiect, trebuie evitatsuprascrierea de ctre o persoan a modificrilor alteia. O rezolvare a acestei probleme esteblocarea unui fiier astfel nct acesta s nu poat fi modificat dect de un singur dezvoltatorla un anumit moment de timp. Abordarea CVS se bazeaz pe izolarea programatorilor,astfel nct fiecare lucreaz n propriul su director, iar la sfrit, cnd toi au terminat,programele sunt integrate.3.3 Managementul echipei

n multe organizaii care dezvolt proiecte software, programatorii, analitii i aliprofesioniti lucreaz mpreun ntr-o echip. Stabilirea structurii adecvate a unei echipeidepinde de muli factori, precum numrul de persoane, experiena i gradul de implicare nproiect, tipul proiectului, diferenele individuale i stilul.

Orice tip de proiect implic un numr de sarcini de lucru. O responsabilitatefundamental a project manager-ului este coordonarea i distribuirea sarcinilor ctre toimembrii echipei. Pentru un proiect mic, echipa va consta n cteva persoane. Pe msur cecrete dimensiunea proiectului, i dimensiunea echipei va crete. Echipele mari sunt dificil decoordonat iar volumul comunicrii dintre membri tinde s creasc exponenial cu mrimeaechipei. De aceea, echipele mari sunt mprite n subechipe astfel nct majoritateacomunicrii i coordonrii s se desfoare la nivelul acestora.3.3.1 Managementul forei de munc

O echip este format din indivizi, fiecare cu scopurile sale personale. Este sarcinaproject manager-ului s formeze din acetia o echip, n care scopurile individuale suntsubscrise scopului proiectului ca ntreg. Identificarea nc de la nceput a scopurilorproiectului este foarte important, iar aceste scopuri trebuie aduse la cunotina membrilorechipei, n caz contrar, fiecare persoan i va stabili propriile scopuri, ceea ce poate cauzaprobleme serioase. De exemplu, un programator pune accent pe viteza programului, altuldorete s foloseasc ct mai puin memorie, iar altul consider c cel mai important este sscrie ct mai multe linii de cod.

Dup ce au fost stabilite scopurile, trebuie monitorizate i evaluate performanelemembrilor echipei. Acest lucru este dificil, deoarece mare parte din ceea ce se face esteinvizibil" iar progresul e greu de msurat. De aceea, n mod ideal, se defineteproductivitatea drept suma funcionalitilor realizate n unitatea de timp. Din punct devedere practic, productivitatea se definete ca numrul de linii de cod realizate pe lun-om.Toat lumea este de acord c nu este o msur optim, dar pn n prezent nu s-a gsit unamai bun. Una din marile pericole ale utilizrii acestei metode este faptul c programatoriitind s scrie ct mai mult cod cu putin, care are efecte negative. De asemenea, definiia

28/132

aceasta a productivitii nu ncurajeaz reutilizarea componentelor, care ar conduce la scriereaunui cod mai mic.3.3.1.1 Mecanisme de coordonare

Mintzberg (1983) distinge cinci configuraii organizaionale tipice: Structura simpl: ntr-o structur simpl exist unul sau numai civa manageri

i un nucleu de persoane care lucreaz la producia proiectului propriu-zis.Aceast configuraie este ntlnit de obicei n firmele noi, cu personal redus.Specializarea este limitat, la fel i instruirea i formalizarea. Mecanismul decoordonare corespunztor este supervizarea direct;

Birocraia automat: Cnd coninutul sarcinilor este complet specificat, esteposibil executarea acestora pe baz de instruciuni precise. Exemple tipice aleacestui tip de configuraie sunt producia de mas i liniile de asamblare.Instruirea este redus, n schimb se pune mare accent pe specializare iformalizare. Coordonarea se obine prin standardizarea proceselor de lucru;

Forma divizionalizat: n acest tip de configuraie fiecrei divizii (fiecruiproiect) i se acord o mare autonomie n ceea ce privete modul de atingere ascopurilor. Detaliile sunt stabilite de divizii. Coordonarea se obine prinstandardizarea produciei. Controlul se exercit regulat prin msurareaperformanelor diviziilor. Acest mecanism de coordonare este posibil numaiatunci cnd este specificat precis rezultatul final;

Birocraia profesional: Dac nu este posibil specificarea rezultatului sauconinutul sarcinilor, coordonarea poate fi realizat prin standardizareacalificrii. Profesionitii talentai se bucur de o autonomie considerabil privindmodul de ndeplinire a atribuiilor;

Adhocraia: n proiecte mari i/sau inovatoare, lucrul este divizat ntre maimuli specialiti, n acest caz, poate fi greu sau chiar imposibil de stabilit cuprecizie ce trebuie s fac fiecare specialist sau modul n care trebuie s-indeplineasc sarcinile. Succesul proiectului depinde de capacitatea grupului dea atinge un scop nespecificat ntr-un mod nespecificat. Coordonarea se obineprin ajustare reciproc.

Trebuie spus c majoritatea organizaiilor reale nu pot fi ncadrate ntr-un singur tip deconfiguraie. Diferite departamente ale firmei pot fi organizate diferit. De asemenea, tipurileprezentate reprezint idei abstracte, n realitate, organizaiile pot tinde spre unul din acestetipuri, pstrnd n acelai timp i caracteristici ale celorlalte.3.3.1.2 Stiluri de management

Teoria lui Reddin (1970) a stilurilor de management pune accent pe factorii interni.Autorul distinge dou dimensiuni ale managementului forei de munc:

gradul de dirijare a relaiei: se refer la atenia acordat individului i relaiilorlui cu ali indivizi din organizaie;

gradul de dirijare a sarcinii: privete atenia acordat rezultatelor care trebuieobinute i modului n care acestea trebuie obinute.

Gradele de dirijare pot fi sczute sau ridicate, ceea ce conduce la patru combinaii debaz, prezentate n Tabelul 3-1. Desigur, aceste combinaii corespund unor orientri extreme.Pentru fiecare dimensiune, exist n realitate o ntreag gam de nuane.

29/132

gradul de dirijare arelaiei

gradul de dirijare a sarciniisczut ridicat

sczut stil de separare stil de angajamentridicat stil de relaionare stil de integrare

Tabelul 3-1 Stilurile de management ale lui ReddinStilul cel mai potrivit pentru o anumit situaie depinde de tipul lucrrii:

Stilul de separare: Este cel mai potrivit pentru munca de rutin. Eficiena estetema central. Project manager-ul se comport ca un birocrat care aplic reguli iproceduri. Acest stil corespunde configuraiei birocraiei automate;

Stilul de relaionare: Este cel mai eficient n situaiile n care oamenii trebuiemotivai, coordonai i instruii. Sarcinile sunt clar atribuite indivizilor. Muncanu are un caracter de rutin, ci este inovatoare i specializat. Stilul esteasemntor configuraiei de adhocraie;

Stilul de angajament: Este cel mai eficient cnd se lucreaz sub tensiune.Project manager-ul trebuie s tie cum s se ating scopurile fr s trezeascresentimente. Stilul e asemntor configuraiei de birocraie profesional;

Stilul de integrare: Se potrivete situaiilor cnd rezultatul este nesigur. Muncaare o natur exploratorie i sarcinile au un puternic caracter de interdependen.Rolul project managerului este s stimuleze i s motiveze. i n acest caz,configuraia de adhocraie este cea mai apropiat.

Fiecare proiect de dezvoltare software poate necesita diferite mecanisme. De exemplu,pentru o echip experimentat, care trebuie s dezvolte o aplicaie bine specificat ntr-undomeniu familiar, coordonarea poate fi realizat prin standardizarea produciei. Pentru oaplicaie complex i novatoare, acest mecanism ar fi ineficient.3.3.2 Organizarea echipei

Indivizii coopereaz n cadrul unei echipe pentru a obine un rezultat optim, ntr-oechip se pot distinge diverse roluri: exist manageri, testeri, designeri, programatori .a.m.d.n funcie de dimensiunea proiectului, o persoan poate ndeplini mai multe roluri, sau diferitepersoane pot avea acelai rol. Este foarte important ca atribuiile rolurilor s fie bine precizatei delimitate. Este de asemenea important ca anumite roluri s fie separate; de exemplu, serecomand separarea echipei de test de echipa de implementare.

Echipele mari sunt greu de gestionat i deseori sunt mprite n subechipe. Prindefinirea clar a responsabilitilor subechipelor, comunicarea dintre membrii echipei selimiteaz la comunicarea n cadrul aceleiai subechipe, ceea ce mrete productivitatea.3.3.2.1 Organizarea ierarhic

n mediile dedicate producerii de software, se ntlnesc deseori structuri ierarhice. nfuncie de dimensiunea proiectului i/sau a organizaiei, pot exista diferite nivele demanagement.

Figura 3-2 prezint un exemplu de organizare ierarhic. Dreptunghiurile denotsubechipele n care se lucreaz efectiv. Cercurile reprezint managerii. Aici avem dou nivelede management. La nivelul inferior, subechipele sunt responsabile de dezvoltarea diferitelorpri ale proiectului. Managerii acestora au rolul de a le coordona activitatea. La nivelulsuperior, se coordoneaz activitatea subechipelor pe ansamblu.

30/132

Figura 3-2 Organizare ierarhicOrganizarea ierarhic reflect deseori structura global a sistemului care trebuie

dezvoltat. Dac sistemul are trei subsisteme majore, pot exista trei subechipe. De asemenea,pot exista uniti funcionale asociate cu responsabiliti specifice proiectului, cum ar fitestarea.

O problem a organizrii ierarhice este distana dintre nivelele superioare i inferioareale piramidei. Munca real" se face de obicei pe nivelele inferioare, unde sunt prelucratecunotinele concrete despre aplicaie. Pe msur ce ne ridicm n ierarhie, cunoaterea devinedin ce n ce mai puin specific; de aceea managementul de pe nivelele superioare tinde saplice coordonarea prin standardizare. Totui, chiar dac deciziile importante se iau la acestenivele, n multe cazuri sunt luate n considerare semnalele venite de pe nivelele de jos, caresunt de obicei nsumate pe nivele intermediare.

De multe ori, pe msur ce informaia urc n ierarhie, lucrurile tind s par din ce n cemai bune. Urmtorul scenariu nu este imposibil:

nivelul de jos: avem probleme serioase la implementarea modulului X; nivelul 1: sunt ceva probleme cu modulul X; nivelul 2: progresul este constant, nu prevd probleme reale; nivelul de sus: totul merge conform planului.

Aceste distorsiuni sunt totui dificil de mpiedicat. Ele sunt cauzate de faptul c liniaierarhic pe care se raporteaz progresul este aceeai cu cea utilizat pentru evaluareaperformanelor. Oamenii doresc evaluri pozitive i de aceea tind s-i modifice i rapoartelen consecin. Dac datele privind progresul proiectului sunt colectate i prelucrate depersoane neimplicate n evaluarea membrilor echipei, cresc mult ansele ca i informaiile sfie suficient de corecte.

Un alt aspect problematic al acestui tip de organizare este faptul c individul estejudecat, att din punct de vedere social ct i financiar, dup nivelul pe care l ocup nierarhie. Este de neles aspiraia de a ajunge pe nivele din ce n ce mai nalte, dei nu estefoarte clar dac acest lucru este de dorit. Principiul lui Peter din legile lui Murphy spune: ntr-o organizaie ierarhic, fiecare angajat urc pn la nivelul su de incompeten. Totui, unprogramator bun nu e neaprat i un bun manager. Programarea necesit competene diferitede cele ale managementului. Ideal ar fi stimularea oamenilor pentru meninerea lor penivelele la care lucreaz cel mai bine.3.3.2.2 Organizarea matrice

Acest tip de organizare este deseori ntlnit n situaia cnd la un proiect softwarelucreaz oameni din diferit