[Curs nr.3]

Stabilirea unui proces rational de dezvoltare

Nu este suficient sa se cunoasca doar produsele care rezulta in decursul dezvoltarii unui sistem software: este necesar si un proces bine definit care sa precizeze cum si cand se genereaza produsele respective.

S-a constatat ca toate proiectele soldate cu succes au fost dezvoltate intr-o succesiune ciclica compusa din 3 tipuri de activitati:

• descoperire
• creatie (inventie)
• materializare (implementare)

In figura de mai jos sunt redate cele 3 tipuri de activitati, aratandu-se evolutia ponderii lor in decursul ciclului de viata:

Descoperirea este activitatea de investigare care are ca scop intelegerea comportamentului dorit pentru sistemul software. Varful acestei activitati se atinge in timpul fazei de analiza, dar ea nu inceteaza cu totul niciodata, deoarece este imposibil sa se stie totul cu privire la comportarea sistemului. Uneori, la sfarsitul ciclului de viata este posibil ca descoperirea sa inregistreze o noua crestere: acest lucru se datoreaza faptului ca sistemul care tocmai a fost produs introduce el insusi o modificare a mediului inconjurator, in sensul ca poate determina utilizatorii sa descopere noi cerinte, pe care nu le-ar fi putut sti dinainte.

Creatia este activitatea care conduce la obtinerea arhitecturii sistemului. Varful acestei activitati se atinge in timpul fazei de proiectare, cand se adopta deciziile strategice majore precum si deciziile tactice care, impreuna, contureaza forma sistemului. La inceputul ciclului de viata creatia se poate manifesta ca o experimentare a unor tehnologii sau concepte noi. De asemenea, pe parcursul evolutiei sistemului creatia se poate manifesta la nivelul proiectarii detaliilor aplicatiei.

Implementarea este activitatea de programare, testare si integrare care are ca rezultat aplicatia executabila. Varful acestei activitati se atinge pe durata fazei de evolutie, dar ea poate sa aiba loc si la inceputul ciclului de viata, cand se pregatesc instrumentele software ce urmeaza a fi folosite si se creaza diverse seturi de componente de uz general.

De regula activitatile de descoperire, creatie si implementare se desfasoara una dupa alta, sub forma unor unde ce se suprapun partial, asa cum se vede si in figura de mai sus. Produsele rezultate pe durata ciclului de viata al proiectului vor evolua iterativ si incremental de-a lungul acestor unde.

Pentru o organizatie producatoare de software este foarte important ca activitatile mentionate mai sus si produsele rezultate sa se realizeze in contextul unui proces matur si repetabil. Elaborarea de sisteme software la nivel industrial este dificila tocmai din cauza caracterului sau iterativ si incremental:

• iterativ in sensul ca descoperirea, creatia si implementarea au loc ciclic,
• incremental in sensul ca produsele rezultate sunt construite prin adaugari succesive, fiecare "cuanta" adaugata aducand produsul mai aproape de stadiul de aplicatie livrabila.

Abordarea productiei industriale de software necesita existenta unor metode de dezvoltare.

O metoda cuprinde: O notatie, care serveste ca mijloc de exprimare a deciziilor strategice si tactice. Un proces, care precizeaza cum si cand trebuie dezvoltate anumite produse.

Metodele OO constituie o categorie particulara a metodelor de dezvoltare software, care privesc construirea sistemelor pentru care clasa reprezinta unitatea arhitecturala fundamentala.
O notatie utila trebuie sa indeplineasca 3 roluri:

• serveste drept limbaj de comunicare a deciziilor care nu pot fi deduse din cod;
• are o semantica suficient de bogata incat sa poata capta toate deciziile strategice si tactice importante;
• ofera o forma concreta care poate constitui obiect al rationamentului uman si al prelucrarii de catre unelte automate.

In cazul metodelor OO s-a impus notatia UML.

Un proces bine definit are 4 roluri:

• precizeaza ordinea in care se desfasoara activitatile echipei;
• specifica ce produse trebuie sa se creeze;
• directioneaza sarcinile membrilor individuali si ale echipei in ansamblu;
• ofera criterii de urmarire si masurare a produselor si activitatilor unui proiect.

Fiecare organizatie producatoare de software poate fi clasificata in functie de maturitatea procesului pe care il urmeaza. Exista 5 nivele distincte ale maturitatii procesului de dezvoltare:

• initial;
• repetabil;
• definit;
• controlat;
• in curs de optimizare.

Asa cum s-a aratat intr-un capitol precedent, unul din factorii care disting un proiect sanatos de unul nesanatos este utilizarea unui ciclu de viata iterativ si incremental. Acest proces trebuie sa fie dirijat de riscuri, adica la fiecare iteratie mai intai se evalueaza riscurile majore, apoi se directioneaza resursele in sensul surmontarii riscurilor respective.
Macro-procesul unui proiect OO trebuie sa realizeze o detaliere succesiva a arhitecturii sistemului. Exista 3 elemente importante ce caracterizeaza macro-procesul:

• Macro-procesul unui proiect OO este un proces de continua integrare a diverselor parti ale sistemului elaborat (atat software cat si hardware).
• La intervale regulate, in procesul de integrare rezulta versiuni executabile, fiecare noua versiune avand functiuni noi fata de cea precedenta. Aceste versiuni, impreuna cu alte produse rezultate in procesul de dezvoltare, servesc ca repere (jaloane)  ale macro-procesului.
• Prin intermediul reperelor managerii de proiect pot masura progresul inregistrat de proiect, precum si calitatea acestuia. In felul acesta pot fi anticipate anumite riscuri.

• Conceptualizarea = stabilirea unui nucleu de cerinte esentiale.
• Analiza = dezvoltarea unui model al comportamentului dorit al sistemului.
• Proiectarea = crearea unei arhitecturi.
• Evolutia = realizarea implementarii si dezvoltarea acesteia, prin detaliere succesiva.
• Intretinerea = controlul evolutiei dupa livrare.

• Conceptualizare = identificarea riscurilor si evidentierea lor prin realizarea unui prototip.
• Analiza = dezvoltarea unui vocabular comun si a unei viziuni comune asupra comportamentului dorit al sistemului, prin explorarea scenariilor impreuna cu utilizatorii finali si cu experti in domeniu.
• Proiectarea = stabilirea unui schelet al solutiei si adoptarea unor decizii tactice in vederea implementarii, prin schitarea arhitecturii sistemului.
• Evolutia = detalierea arhitecturii versiunii curente.
• Intretinerea = continuarea evolutiei sistemului tinand cont de noi cerinte care apar pe parcurs (pe masura ce se adanceste intelegerea sistemului de catre echipa de proiectanti).

• Scop
• Produse
• Activitati
• Agenti
• Jaloane si masuratori.

Conceptualizarea

Scop: stabilirea cerintelor esentiale ale sistemului de dezvoltat.
Nu fiecare proiect necesita aceasta faza. Recomandarea este de a efectua conceptualizarea doar atunci cand riscurile unui proiect sunt relativ mari sau cand este necesar sa se stabileasca o legatura initiala intre beneficiar si proiectant. Altfel, este indicat sa se treaca direct la analiza.
Riscurile asociate cu un proiect pot sa fie mai ridicate ca de obicei, in anumite circumstante, si anume: abordarea unui domeniu necunoscut al problemei, introducerea unei tehnologii noi (o noua platforma, un nou limbaj, noi instrumente software sau chiar noi modele ale procesului de dezvoltare). De asemenea, riscurile devin mai mari in conditiile existentei unor cerinte deosebite: performante sau capacitate crescute.
Demararea unui proiect software reprezinta aproape intotdeauna o sursa de cheltuieli, atat din partea beneficiarului, cat si din partea proiectantului. De aceea, uneori este necesara faza de conceptualizare pentru ca cei 2 sa stabileasca clar care sunt limitarile si necesitatile fiecaruia.
In legatura cu riscurile unui proiect exista urmatoarea regula:

Riscurile unui proiect incep sa atinga proportii critice din momentul in care se schimba mai mult decat 2 factori care caracterizeaza practica existenta in organizatia respectiva: echipa, baza tehnologica, platforma, metoda, instrumentele, limbajul de programare si cerintele sistemului.

In fine, conceptualizarea serveste ca un prototip al proiectului in ansamblu. La terminarea acestei faze, managerii trebuie sa poata raspunde la urmatoarele 2 intrebari:

• Care sunt riscurile majore ale proiectului?
• Sunt aceste riscuri suficient de controlabile astfel incat sa se poata proceda la alocarea resurselor necesare in continuare, sau se impune o investigare mai atenta (uneori mergandu-se chiar la abandonarea proiectului)?

Produse: pe durata conceptualizarii se genereaza 3 produse:

• Un prototip executabil. Este cel mai important produs, deoarece constituie o proba palpabila pentru stabilirea corectitudinii unor ipoteze legate de functionalitatea, performanta, marimea, complexitatea proiectului, inca din fazele incipiente. Un asemenea prototip trebuie sa aiba 2 caracteristici:
• arie larga de cuprindere, adica sa ia in considerare cat mai multe functiuni ale sistemului;
• lipsa detaliilor; un prototip este in mod implicit un produs incomplet, care trebuie realizat repede si cu costuri minime, in nici un caz nu trebuie sa-si propuna sa contina cod de calitate. De cele mai multe ori aceste prototipuri se arunca.
• O evaluare a riscurilor. Este o simpla enumerare a riscurilor tehnice si non-tehnice identificate care sa evidentieze obstacolele care ii asteapta pe proiectanti.
• O viziune generala asupra cerintelor sistemului.

Activitati:
Activitatea de baza care se efectueaza consta in elaborarea unui prototip in vederea evidentierii riscurilor. Aceasta presupune urmatorii pasi:

• stabilirea unui set de obiective pentru prototip, precum si un termen de executie. La stabilirea setului de obiective trebuie enumerat explict ce anume va face prototipul, ce NU va face, si care trebuie sa fie costurile. Stabilirea termenului de predare este important deoarece conceptualizarea este, prin natura sa, o activitate intens creativa, pe care multi proiectanti o gasesc de-a dreptul amuzanta. Nefiind constransi de conditiile din timpul dezvoltarii propriu-zise, exista riscul de a nu mai termina. Daca intreg ciclul de viata al unui proiect arata la fel ca faza de conceptualizare, se poate spune ca proiectul respectiv e scapat de sub control. De aceea, managerii trebuie sa fie foarte fermi in ceea ce priveste termenele. Experienta arata ca, de regula, pentru proiecte cu ciclul de viata de aprox. 1 an, conceptualizarea dureaza cam 1 luna.
• asamblarea unei echipe adecvate pentru elaborarea prototipului. Aceasta echipa va fi lasata sa lucreze, constransa fiind doar de termenul de executie. Practica a demonstrat ca o data stabilite obiectivele si termenul de executie pentru prototip, cel mai bun lucru pe care il are managerul de facut pe durata conceptualizarii este sa stea deoparte. Aceasta nu presupune incitarea la anarhie, ci doar evitarea aplicarii unor reguli rigide asupra echipei care elaboreaza prototipul.
• evaluarea prototipului si adoptarea unei decizii explicite privind trecerea la dezvoltarea sistemului sau continuarea investigatiilor.

Agenti: pentru elaborarea prototipului cel mai eficient este sa se utilizeze o echipa mica, formata din arhitectul sistemului si 1-2 proiectanti, care vor participa si mai departe, la analiza si proiectare. Arhitectul va participa efectiv la construirea prototipului, nu se va margini doar la a schita planuri.
 

Jaloane si masuratori: cel mai important reper in aceasta faza este predarea prototipului. Daca echipa depaseste termenul, e clar ca planificarea termenelor reprezinta in continuare un factor de risc, Aceasta inseamna ca fie trebuie relaxate anumite restrictii (termene sau functionalitati), fie explorate alte alternative.
Cea mai importanta masuratoare in aceasta faza este evaluarea gradului in care prototipul a acoperit toate obiectivele stabilite la inceput. Daca prototipul nu indeplineste unele din cerintele enumerate, acesta e un semn ca cerintele respective prezinta un risc tehnic ridicat.

Analiza

Scop: dezvoltarea unui model al comportarii dorite a sistemului.
Fiecare proiect are nevoie de aceasta faza. Ignorarea sau fusarirea ei va duce in mod sigur la situatia in care sistemul rezultat nu va fi ceea ce a cerut beneficiarul.
Analiza se concentreaza asupra comportamentului, nu a structurii. La terminarea acestei faze, managerii trebuie sa poata raspunde la urmatoarele intrebari:

• Care sunt functiile majore ale sistemului?
• Cum se manifesta sistemul in cadrul fiecareia din aceste functii?
• Ce comportari alternative pot sa apara, pe langa cele principale?
• Care sunt rolurile si responsabilitatile claselor esentiale si ale obiectelor care contribuie la aceste comportari?
• Ce relatii exista intre sistem si alte sisteme externe?
• Exista factori de risc noi sau cunoscuti care inca nu au fost depasiti in procesul de descoperire?

Procesul de cautare a raspunsurilor la aceste intrebari reprezinta un impuls pentru utilizatorii sistemului de a formula mai bine ceea ce doresc. Primele 5 intrebari din lista de mai sus servesc, in particular, la stabilirea unui vocabular comun intre expertii in domeniu, utilizatori si proiectanti.
Concentrandu-ne asupra comportamentului, vom putea identifica punctele de functionare (function points) ale sistemului. Acestea reprezinta ansamblul comportarii observabile din exterior si testabile a unui sistem. Din perspectiva utilizatorului, un punct de functionare reprezinta o actiune primara a sistemului, ca raspuns la un eveniment extern. Din perspectiva analistului, un punct de functionare reprezinta o anumita cuanta de comportament. Punctele de functionare sunt o masura a complexitatii: cu cat sunt mai multe, cu atat sistemul e mai complex. Captarea semanticii unui punct de functionare se realizeaza prin intermediul unui scenariu.
Analiza nu este o faza inchisa, in sensul ca nu putem avea pretentia de a obtine o intelegere completa asupra sistemului inainte de a trece la proiectare. Este suficient daca pentru inceput se realizeaza analiza celor mai importante functii ale sistemului, considerandu-se comportamentul primar si secundar implicat.