Modele ale Procesului de dezvoltare softwareCa orice produs fabricat complex, un program este realizat urmnd un anume proces. Un proces de dezvoltare a programelor se bazeaz pe o formalizare a activitilor specifice, la care ne-am referit. Scopul formalizrii este obinerea unui ansamblu de mecanisme care, n cazul n care sunt aplicate sistematic permit obinerea ntr-un mod repetitiv i fiabil de produse software de calitate constant. Descrierea procesului rmne general, pentru c nu este posibil s se defineasc un standard unic adaptat la toate tipurile de aplicaii i la toate persoanele. Dezvoltarea unui program poate fi vzut ca stabilirea unui ir de descrieri din ce n ce mai precise i din ce n ce mai apropiate de un program executabil i de documentaia sa. Trecerile de la o descriere la alta sunt deseori numite rafinri succesive. Aceasta este o vedere simplificat, pentru ca nu ia n considerare natura iterativ a procesului de dezvoltare. O dat dezvoltat un program, este pus n exploatare. Se pun atunci probleme de ntreinere, de corectare a defectelor, de ameliorare a anumitor caracteristici sau de urmrire a evoluiei cerinelor. Intreinerea poate impune modificarea funciilor sistemului i deci, un proces de redezvoltare. Din aceasta cauz se vorbete despre ciclul de via al unui program, cnd considerm exploatarea i ntreinerea n plus fa de dezvoltare.

Ce este ciclul de viata al unui program (Software life cycle)?

O secventa de etape in existenta produsului software. Sunt incluse toate activitatile necesare pentru dezvoltarea produsului temporale dintre ele. si relatiile

Fiecare etapa din ciclul de viata este caracterizata prin activitati specifice si produsele rezultate din activitatile respective.

1

Modele ale ciclului de viata software (Software development life cycle models or process models): Waterfall model (Modelul cascada) V model (modelul in V) ESA ( European Space Agency) model Incremental model (Modelul iterativ si incremental) Dezvoltarea agila Prototyping (Dezv pe baza de prototip) Spiral model (Modelul in spirala)

Modelul cascada Numit si modelul clasic al ciclului de viata sau modelul liniar Descris de Royce n 1970, a fost larg utilizat de atunci, pentru descrierea general a procesului de dezvoltarea programelor. Ciclul de via n cascad prezint dezvoltarea unui program ca o succesiune de faze ce se nlnuie ntr-o derulare liniar, de la analiza cerinelor i pn la livrarea produsului ctre client. Fiecare faz corespunde unei activiti i trebuie s se termine la o anumit dat prin producerea anumitor documente sau programe. Rezultatele fazei sunt supuse unei revizii aprofundate i nu se trece la faza urmtoare dect atunci cnd sunt considerate satisfctoare.

2

In prima sa versiune, modelul avea numai sgei descendente, care materializeaz nlnuirea etapelor; el nu prevedea iteraii. Sgeile ascendente au fost adugate mai trziu pentru a ilustra principiul c o etap repune n discuie numai etapa precedent.

Limitele modelului n cascad

Modelul n cascad se bazeaz pe o secven de faze bine delimitate.Documentele produse de fiecare faz sunt evaluate n cadrul reviziilor care valideaz trecerea de la o faz la alta. Din pcate, proba efectiv a bunei sau a proastei functionri a sistemului este realizat numai n cadrul fazei de integrare, cnd este posibil evaluarea concret a programului. Inaintea acestei faze au fost produse numai documente.

3

Abordarea n cascad d rezultate satisfctoare numai n cazul n care este efectiv posibil nlnuirea fazelor fr prea multe probleme. Aceasta presupune ca ansamblul cerinelor s fie perfect cunoscut i problema complet nteleas de analiti. Trebuie de asemenea ca soluia s fie uor de determinat de proiectani i codificarea simpl - redus ideal la generarea automat a codului plecnd de la documentele de proiectare. In realitate se constat c partea de necunoscut poate fi nsemnat n anumite dezvoltri, n special datorit: - nenelegerii cerinelor de ctre client sau analist; - instabilitii cerinelor; -alegerilor tehnologice; -schimbrilor de personal. Din toate aceste motive sunt necesare reveniri n etape anterioare ale procesului de dezvoltare. Aceste reveniri sunt de fapt o reflectare a realitii. Dac aceste reveniri sunt ocazionale i limitate la faze adiacente, modelul n cascad este pertinent. In caz contrar, modelul n cascad nu corespunde realitii.

Avantaje: Sistemul este bine documentat Permite un bun management al proiectului: planificarea resurselor umane pe etape estimari de cost mai exacte Dezavantaje: Un produs executabil, care sa demonstreze functionarea sistemului este disponibil destul de tarziu, dupa integrare. Pana atunci s-au produs numai documente. Deoarece modelul este secvential, exista numai uhn feedback local, la tranzitiile intre faze. Multe erori sunt descoperite tarziu cost crescut Toate riscurile sunt incluse intr-un singur ciclu de dezvoltare

4

Adecvat pentru proiectele in care cerintele sunt bine intelese de la inceput si nu se modifica pe parcursul procesului de dezvoltare. Experienta ultimelor decenii a demonstrat ca modelul este valoros. Este utilizat si in prezent de multe organizatii mari.

Modelul in V Este o varianta a modelului cascada, care pune in evidenta corelarea dintre activitatile de specificare si cele de testare, inlantuirea in timp a activitatilor fiind aceeasi.

Partea din stanga reprezinta lantul de specificare a sistemului iar cea din dreapta lantul de testare. Partea de jos a v-ului reprezinta implementarea In acest model exist dou tipuri de dependene ntre etape:

5

-cele reprezentate prin liniile care formeaza V-ul, care corespund nlanuirii i eventualei iteraii din modelul cascad; etapele se deruleaz deci secvenial, urmnd V-ul de la stnga la dreapta; -cele reprezentate prin linii orizontale, care indic faptul c o parte din rezultatele etapei din care pleac sgeata sunt utilizate direct n etapa int. De exemplu, la terminarea etapei de proiectare arhitectural, cazurile de teste de integrare trebuie s fie complet descrise.

PrototipareaPentru sisteme noi, n mod special dac ele sunt mari i complexe este puin probabil s se construiasc o specificaie complet, logic i valid nainte ca sistemul sa fie construit i utilizat. Acest fapt a condus la ideea prototiprii. Ideea este de a permite viitorilor utilizatori s exerseze cu o prim versiune a sistemului, care poate fi obinut rapid prin tehnici de simulare i/sau de interpretare a specificaiilor. In acest ultim caz, limbajele logico-funcionale sunt n mod sigur chemate s joace un rol important.

6

Prototipul este o schi a viitorului sistem: el nu are performanele i nu rspunde exigenelor de calitate ale unui produs finit. Prototipul ofer clientului functionaliti (nu n totalitate) ale viitorului sistem i interfaa sa utilizator. El este dezvoltat ntr-o manier iterativ. Cerinele sunt extrase i validate iterativ prin utilizarea prototipului. In fiecare iteraie specificaia sistemului este modificat i detaliat pn cnd prototipul satisface necesitile utilizatorilor. Un prototip care este utilizat pentru a desprinde cerinele viitorilor utilizatori, este o "machet exploratoare". Activitatea de prototipare poate interveni de asemenea n etapa de proiectare, pentru a experimenta i compara diferite variante. Astfel de prototipuri se numesc "machete experimentale". Figura urmtoare red procesul de prototipare dedicat extragerii cerinelor:

Pentru dezvoltarea prototipului se folosesc limbaje de nivel foarte nalt: Smalltalk, PROLOG, LISP, SETL i altele. In prezent exist limbaje i medii de

7

dezvoltare specializate pentru construirea prototipurilor. Astfel de limbaje sunt limbajele de generaia a 4-a (4GL). Cu toate c se poate folosi acelai limbaj de programare, att pentru realizarea prototipului ct i pentru dezvoltarea aplicaiei, se recomand ca prototipul s fie considerat un sistem "nchis", adic s nu fie folosit ca baz pentru dezvoltarea aplicaiei. Aceasta deoarece: - prototipul a fost dezvoltat prin modificri succesive, de aceea arhitectura sa iniial a fost alterat, ceea ce ngreuneaz ntreinerea; - prototipul trebuie s corespund cerinelor utilizatorilor numai din punct de vedere funcional. De aceea, n dezvoltarea sa sunt neglijate aspecte ca: eficiena, adaptabilitatea, compatibilitatea i chiar fiabilitatea.

Modelul Incremental Modelul ciclului de via "Incremental" este opus modelului in cascada . El se bazeaz pe o idee foarte simpl: dac un sistem este prea complex pentru a fi neles, conceput sau realizat intr-o singura faz este mai bine sa fie realizat n mai multe faze, prin evoluie.

8

Cum se aplica Intr-o faza initiala: o Se studiaza scopul proiectului si fezabilitatea sa. In cazul deciziei de continuare a proiectului: o Se detaliaza cerintele utilizatorilor si se efectueaza o analiza de nivel inalt, pentru a se determina cerintele software la un nivel general. o Se determina o arhitectura generala a sistemului. o Se impart cerintele in subseturi care pot fi implemenate in incremente separate. Se stabileste planificarea in timp a incrementelor. Fiecare increment implementeaza un subset de cazuri de utilizare de nivel inalt, care exprima cerintele utilizatorilor. El este construit urmand abordarea cascada: analiza detaliata a cerintelor din subset, proiectarea, implementarea si testarea. Rezultatul este un produs care satisface un subset al cerintelor si este livrat utilizatorilor. Un produs tipic consta din 10-50 incremente.

Se incepe cu o implementare simpla a unui subset al cerintelor software. Rezulta o prima livrare. Scopul primei implementari este de a crea un produs la care utilizatorul poate reactiona. El trebuie sa puna in evidenta aspectele cheie ale problemei si sa furnizeze o solutie sufient de simpla pentru a fi inteleasa si usor de implementat. Fiecare noua iteratie include analiza ultimei versiuni si adaugarea de noi functionalitati, ceea ce presupune reproiectarea, codificarea si testarea. Se urmareste ca proiectarea sa fie directa, modulara, sa suporte reproiectarea. Analiza unei iteratii se bazeaza pe feedback-ul utilizatorului si pe instrumentele de analiza disponibile. Ea se refera la: modularitea produsului, cuplarea modulelor, utilizabilitatea, fiabilitatea, eficienta si realizarea scopurilor. Fiecare iteratie este o varianta imbunatatita a celei anterioare, de aceea metoda se mai numeste imbunatatirea iterativa (iterative enhancement). Se utilizeaza masuri pentru evaluarea evolutiei sistemului. Masurile prin care se evalueaza un software sunt dificil de inteles ca valori absolute, dar schimbarile 9

valorilor lor in evolutia unui sistem sunt o baza de comparatie. Astfel de masuri sunt: numarul de defecte, efortul de actualizare, dimensiune, complexitatea, cuplarea modulelor. Schimbarile diferitelor aspecte se pot monitoriza si se pot stabili limite pentru anumite masuri, pentru a semnala probleme sau anomalii. Utilizarea analizei si a masuratorilor ca ghid in procesul iterativ este o diferenta majora intre aceasta metoda si metodele de dezvoltare agila (agile software development). Ele sunt suportul pentru determinarea eficientei procesului si a calitatii produsului. Fiecare iteraie a ciclului de via iterativ si incremental reproduce ciclul de via n cascad la o scar mai mic. Obiectivele unei iteraii sunt stabilite pe baza evalurii iteraiilor precedente. Documentaia este construit treptat, n timpul fiecrei iteraii. La sfritul dezvoltrii, documentele obinute au aceeai form cu cele obinute n maniera convenional.

Avantaje: In fiecare etapa este livrat un produs executabil, care satisface o parte din cerintele utilizator. Opus modelului cascada in care se elaboreaza documente. Prototipurile sunt livrate clientului/utilizatorilor. Feedback-ul utilizatorilor este distribuit pe intreg parcursul dezvoltarii. In cazul aparitiei unor schimbari in cerinte acestea pot fi incoporate in urmatorul prototip. Ciclul de via iterativ se bazeaz pe evoluia prototipurilor executabile, msurabile i deci pe evoluia elementelor concrete. El este opus din acest punct de vedere ciclului de viata n cascad care se bazeaz pe elaborarea de documente. Livrrile foreaz echipa s dea rezultate concrete n mod regulat. Integrarea diferitelor componente ale programului este realizat ntr-o manier progresiv n timpul construciei. Progresele se msoar prin programe demonstrabile mai degrab dect prin documente sau estimri, ca n ciclul de via n cascad;

10

In cursul dezvoltrii, clientul poate utiliza prototipurile. Demonstrarea prototipurilor prezint numeroase avantaje: - utilizatorul este pus n faa situaiilor de utilizare concrete care-i permit s-i defineasc mai bine dorinele i s le comunice echipei de dezvoltare; - utilizatorul devine partener al proiectului; el si ia partea de responsabilitate n noul sistem i de fapt l accept mai uor;

Dezavantaje Ciclul de via Incremental se bazeaz pe evoluia prototipurilor executabile. Din nefericire, programele nu se preteaz n mod natural evoluiei, din contr, ele sunt deseori foarte "fragile" la modificri. Efectul unei modificri locale se poate propaga n ansamblul aplicaiei. Fiecare nou increment poate necesita reorganizarea structurii interne, degradand arhitectura initiala a programului, facndu-l greu de verificat i de ntreinut. Erorile de proiectare sunt mai greu de eliminat. Abordarea obiect bazat pe modularitate i ncapsulare conduce la programe mai robuste i mai rezistente fa de schimbri. Din acest punct de vedere, abordarea obiect furnizeaza un cadru confortabil pentru dezvoltarea prin evoluie, ntr-o manier iterativ. Clientul poate vedea ce se poate face si poate cere mai mult! Abordarea incrementala se poate transforma usor intr-una codifica si repara ( build and fix ).

Planificarea Principalul risc in utilizarea unui model incremental este de a lucra intr-o manierea ad-hoc. Determinarea unui plan de actiuni este de prima importanta pt succesul abordarii incrementale. In faza de analiza preliminara se determina scopul proiectului si se incearca determinarea riscurilor majore ale proiectului, se determina o lista o cerintelor si constrangerilor mai importante, pt a construi un plan de dezvoltare. Se stabileste natura fiecarui icrement si ordinea de construire a incrementelor.

11

O varianta a modelului este Numai implementarea incrementala: o o Urmeaza modelul cascada pana in faza de implementare In timpul analizei cerintelor si proiectarii de sistem: Se definesc subseturi / subsisteme care pot fi livrate Se definesc interfete care permit adaugari iterative simple, cu un minim de modificari a arhitecturii existente Diferitele parti sunt implementate, testate si livrate in functie de diferite prioritati si la diferite momente de timp

Construirea in paralel a incrementelor: risc Diferite incremente pot fi construite in paralel de diferite echipe.Dupa inceperea fazei de proiectare a primului increment, echipa de specificare incepe specificarea celui de-al 2-le increment. Riscul este ca cele 2 incremente sa nu se potriveasca. In mod norma, al 2-lea trebuie sa-l includa pe primul. Fiecare increment are parti comune cu altele. Este necesara o buna comunicare si coordonare intre echipele care construiesc in paralel incrementele care au parti comune (privind implementarea partilor comune). Aceste probleme cresc exponential cu numarul de incremente.

Rational Unified Process (RUP: www.rational.com) Este un proces de dezvoltare iterativ. Cei care l-au definit, Ivar Jacobson, Grady Booch, and James Rumbaugh, il caracterizeaza astfel: Dirijat de cazurile de utilizare Modelul cazurilor de utilizare descrie complet functionalitatea sistemului. Cazurile de utilizare dirijeaza procesul de dezvoltare: dezvoltatorii creaza modele de proiectare si implementare pentru a realiza cazurile de utilizare iar testorii testeaza sistemul pentru a verifica daca sistemul implementeaza corect cazurile de utilizare. 12

Centrat pe arhitectura Arhitectura sistemului este aspectul cel mai important al sistemului. Arhitectul selecteaza cazurile de utilizare care reprezinta functile cheie ale sistemului (5%-10% din cazurile de utilizare), le specifica in detaliu si le realizeaza in termeni de subsisteme, clase, componente. Inerativ si incremental Proiectul de dezvoltare software este divizat in mini-proiecte, fiecare fiind o iteratie din care rezulta un increment. Fiecare iteratie are de-a face cu cele mai importante riscuri si realizeaza un grup de cazuri de utilizare care impreuna extind utilizabilitatea produsului. In fazele initiale, un proiect initial poate fi extins cu unul mai detaliat. In fazele urmatoare, incrementele sunt in mod tipic aditive.

Agile software development Este un cadru conceptual pentru proiectele software. Exista mai multe metode de dezvoltare agila, cum sunt cele expuse de Agile Alliance, o organizatie nonprofit. Pentru orice proiect software exista o serie de factori de risc care pot periclita finalizarea cu succes a proiectului, cum ar fi: factori de experienta ( conducatorului de proiect, a echipei), factori de planificare, factori tehnologici, factori externi (modificarea cerintelor, modificarea interfetelor externe). Cele mai multe metode de dezvoltare agila incearca sa minimizeze riscul dezvoltand software-ul in intervale scurte de timp, numite timeboxes, constand din 1-4 saptamani. Data de sfarsit a unui timebox nu poate fi modificata. Daca echipa depaseste data, iteratia este anulata si replanificata. Fiecare iteratie este un proiect software in miniatura si include toate activitatile necesare livrarii mini-incrementului unei noi functionalitati: planificare, analiza cerintelor, proiectare, codificare, testare, documentare. Fiecare noua iteratie trebuie sa livreze un nou produs. La sfarsitul fiecarei iteratii echipa re-evalueaza prioritatile proiectului. 13

Timebox-urile sunt utilizate in ,metodele de dezvoltare agila ca o forma de management al riscului in dezvoltarea unui software. Metodele agile pun in evidenta comunicarea directa intre participantii la elaborarea unei iteratii, in locul documentelor scrise. Acestia lucreaza in aceeasi locatie, intre ei fiind cel putin programatorii si clientii lor (cei care definesc produsul). Echipa poate include testori, proiectanti de interactiune, echipe de documentare tehnica si manageri. Principala masura a progresului este considerata software-ul functional. Se produce foarte putina documentatie, motiv pentru care metodele sunt criticate. Pentru mai multe informatii despre metodele de dezvoltare agila: http://www.agilealliance.org/. Comparatie cu alte metode Considerand ca metodele de dezvoltare pot fi plasate pe o scara continua de la cele adaptive la cele predictice, metodele agile se situeaza la extremitatea celor adaptive. Adaptive Predictive

Metodele adaptive sunt focalizate pe adaptarea rapida la schimbari. Nu se au in vedere cu exactitate ce se va intampla in viitor. O echipa adaptiva poate raporta exact ce sarcini vor fi realizate saptamana urmatoare si ce este planificat pentru luna urmatoare. Metodele predictive sunt focalizate pe planificarea in detaliu a activitatilor, in timp. O echipa predictiva poate raporta exact ce este planificat pentru intreagul proces de dezvoltare. Echipa predictiva are dificultati in schimbarea directiei. Planul este optimizat pentru desinatia originala iar schimbarea directiei poate necesita renuntarea la rezultatele curente si replanificarea activitatilor. Numai schimbarile considerate importante sunt luate in considerare.

14

In comparatie cu metodele incrementale: asemanare- creaza produse livrabil in perioade de timp scurte deosebiri: perioadele de timp sunt masurate in saptamani si nu luni perioadele de timp sunt stricte (time-box-uri) in metodele incrementale procesul este ghidat de analiza si masurare a caracteristicilor produsului. Ele sunt suportul pentru determinarea eficientei procesului si a calitatii produsului

In comparatie cu modelul cascada Dezvoltarea agila are foarte putine in comun cu dezvoltarea cascada. Modelul cascada are si in prezent o utilizare larga.. Modelul cascada este cel mai predictiv, activitatile sunt pre-planificate intr-o secventa. Progresul este masurat prin produse intermediare (specificatii, doc de proiectare, planuri de testare, revizii ale codului, etc). Efortul de integrare si testare poate fi foarte mare (cateva luni cativa anui!), fiind una dintre cauzele de esec ale unei dezvoltari cascada. Prin dezv agila se produc produse executabile intervale de cateva saptamani sau luni. Se pune accentul pe obtinerea de executabile cat mai repede apoi imbunatatirea lor continua! Extreme Programming, este o metoda de dezvoltare agila care a crescut popularitatea metodelor agile. Extreme Programming (XP) este un model incremental bazat pe iteratii scurte, testare intensiva si simplitate. Este adecvata pentru echipe mici si proiecte caracterizate prin schimbari rapide ale cerintelor. Informatii suplimantare despre XP pot fi gasite la: www.extremeprogramming.org, www.xprogramming.com.

15

Modelul spiralaBarry Boehm a definit acest model plecand de la slabiciunile modelului cascada, in special lipsa sa de flexibilitate la schimbari ale cerintelor. Este focalizat pe analiza riscurilor in mod incremental, repetand modelul cascada intr-o serie de cicluri, ca in figura urmatoare. Fiecare ciclu consta din 4 faze. 1. Determinarea obiectivelor: definirea produsului, determinarea scopurilor si a constrangerilor, generarea alternativelor. 2. Evaluarea alternativelor: analiza riscurilor, prototiparea 3. Dezvoltarea produsului: proiectarea de detaliu, testarea unitara, integrarea, . 4. Planificarea urmatorului ciclu: evaluarea de catre client, planificarea dezvoltarii si a livrarii catre client. Este o imbunatatire a modelului cascada deoarece prevede mai multe livrari si mai multe posibilitati de implicare a clientului. Raza spiralei reprezinta costul acumulat.

Informatii suplimentare: http://www.stsc.hill.af.mil/crossTalk/2001/05/boehm.html.

16

Ulterior Boem a sugerat o versune modificata a modelului modelul spirala WinWin, care adauga la inceputul fiecarui ciclu activitati de identificare a partilor interesate in proiect (stakeholders) si conditiile lor de castig (win conditions).

17