Sunteți pe pagina 1din 64

UNIVERSITATEA POLITEHNICA BUCURESTI Facultatea de Electronica, Telecomunicatii si Tehnologia Informatiei

PROIECT I.S.

CICLURI DE VIATA ALE PRODUSELOR SOFTWARE

Studenti: Laza Laura Stefanescu Yasmin Guta Ovidiu Popescu Razvan Lungu Mihail GRUPA 443A

Profesor indrumator: Prof. Dr. Ing. tefan Stncescu

UPB 2012

Sumar
1. Introducere Laza Laura 1.1 Ciclul de viata ca intreg 1.2 Dezvoltarea clasica a programelor 2. Modelul cascada Stefanescu Yasmin 2.1 Notiuni generale 2.2 Argumente 2.3 Modele modificate 2.4 Rezultatul proiectului n modelul cascad 2.5 Avantajele modelului de ciclu de via cascad 2.6 Limitri ale modelului de ciclu de via cascad 2.7 Etape 2.8 Aplicaii 3. Modelul in V Laza Laura 3.1 Obiective 3.2 Schema modelului in V 3.3 Fazele modelului in V 3.4 Avantaje si dezavantaje 4. Modelul spirala Laza Laura 4.1 Notiuni generale 4.2 Schema modelului spirala 4.3 Descrierea modelului spirala 4.4 Avantaje si dezavantaje 4.5 Aplicatii 5. Modelul incremental Guta Ovidiu 5.1 Cum se aplica 5.2 Avantaje si dezavantaje 5.3 Planificarea 5.4 Rational Unified Process 6. Modelul code-and-fix Stefanescu Yasmin 6.1 Notiuni generale 6.2 Avantaje si dezavantaje 6.3 Fazele modelului code-and-fix 6.4 Limitri ale modelului de ciclu de via code and fix 6.5 Compararea metodelor de dezvoltare software 7. Modelul cu prototipuri Popescu Razvan 7.1 Notiuni generale 7.2 Prototipuri cu aruncare 7.3 Prototipuri evolutive
2

8. Modelul cu subproiecte Popescu Razvan 8.1 Notiuni generale 8.2 Avantaje si dezavantaje 8.3 Exemplu 9. Modelul in etape Lungu Mihail 9.1 Introducere 9.2 Etapele distribuiei n ciclul de via 9.3 Produsele pentru dezvoltare software comercial 9.4 Etapele de dezvoltare 9.4.1 Pre-alfa 9.4.2 Alfa 9.4.3 Beta 9.4.4 Originile variantelor alfa i beta 9.4.5 Seigo 9.5 Release Candidate i Gold 9.6 RTM sau RTW 9.7 Versiuni stabile/nestabile 9.8 Concluzii 10. Modelul cu software commercial Lungu Mihail 10.1 Notiuni introductive 10.2 Msurarea mrimii proiectului i a dificultii nivelului 10.3 Performanele legate de software-ul commercial 10.4 Definirea problemei controlului ciclului de via a software-ului commercial 10.5 Determinarea calitii software-ului comercial 10.6 Msurarea succesului ntr-un mediu commercial, competitive 11. Modelul cu medii de dezvoltare Guta Ovidiu 11.1 Notiuni generale 11.2 Medii de dezvoltare in trei faze 11.3 Avantaje si dezavantaje 11.4 Sisteme Distribuite 11.5 Exemple de medii de dezvoltare 12. Concluzii Laza Laura 13. Bibliografie

1. Introducere Laza Laura


Conceptul fundamental al ingineriei software l constituie ciclul de viata. 1.1 Ciclul de viata ca ntreg Ciclul de viata al unui produs software este reprezentat n figura de mai jos. Odata dezvoltat, produsul intra ntr-un ciclu de utilizare si modificare, care continua pe toata durata sa de viata. Tiparul nu este specific produselor software, el putnd fi generalizat pentru majoritatea produselor industriale, cu diferenta ca n cazul acestora din urma etapa de modificare se numeste etapa de reparare sau de ntretinere (ciclul este utilizare - modificare, pe masura ce componentele se uzeaza).

Produsele software nu se uzeaza, n schimb, ele trec prin faza de modificare din alte motive: corectarea erorilor care nu au fost detectate n faza de dezvoltare, schimbari n contextul n care sunt utilizate, schimbari efectuate modificarea anterioara care au avut efecte nedorite n alte puncte ale programului. De exemplu, modificarea legii impozitului necesita corectarea programelor pentru salarii, iar adesea aceste modificari au efecte adverse n alte zone ale programului efecte care sunt observate ulterior. Indiferent de motivul pentru care un produs informatic intra n faza de modificare, acest stadiu presupune ca o persoana (adesea alta dect autorul programului sa studieze programul si documentatia aferenta pna cnd ajunge la un grad de ntelegere care sa i permita efectuarea modificarilor. n caz contrar, este posibil ca modificarile efectuate sa cauzeze mai multe probleme dect rezolva. ntelegerea unui program este adesea o sarcina foarte dificila, chiar n conditiile n care acesta a fost bine proiectat si documentat. Nu sunt deloc rare cazurile n care n aceasta faza renunta complet la un anumit program component, considerndu-se (si nu fara temei) ca este mai usor sa se dezvolte de la zero un sistem nou, dect sa se modifice cu bune rezultate sistemul existent. Experienta arata ca un minim de efort n timpul dezvoltarii unui produs informatic poate sa usureze mult sarcina modificarii produsului, atunci cnd acest lucru devine necesar. Majoritatea cercetarilor n domeniul ingineriei software se concentreaza pe faza de dezvoltare a produselor; eforturile investite n aceasta faza aduc cele mai nalte beneficii pentru toate fazele ulterioare de viata.

1.2 Dezvoltarea clasica a programelor Vom analiza acum mai ndeaproape etapele care intra n componenta primei faze din ciclul de viata al produselor informatice: dezvoltarea. Aceste etape sunt analiza, proiectarea, implementarea si testarea.

Analiza Aceasta este etapa n care se constata ca ar fi utila o aplicatie informatica si se ia decizia dezvoltarii unui sistem software. Fie ca se constata existenta unei piete pentru un produs de uz general, fie ca o anumita organizatie are nevoie de o aplicatie specializata, n mare masura aceasta prima etapa presupune mai degraba luarea unor decizii de management si marketing dect abordarea unor problem legate de studiul algoritmilor. Dupa luarea deciziei de dezvoltare a unui sistem informatic ncepe adevarata analiza, al carei scop principal este identificarea necesitatilor utilizatorului potential al sistemului. Proiectarea n faza de proiectare sunt dezvoltate detaliile tehnice ale sistemului. n aceasta etapa, sistemul este descompus n componente mai usor de controlat, numite module. Implementarea sistemelor complexe devine posibila tocmai prin aceasta descompunere modulara. Altfel, multimea detaliilor tehnice care trebuie luate n considerare ar fi imposibil de stapnit; prin proiectarea modulara, este suficient sa avem n vedere pentru fiecare modul doar detaliile corespunzatoare acestuia. Pe de parte, proiectarea modulara ajuta si la ntretinerea sistemului. O structura modulara bine proiectata este importanta att pentru implementarea sistemului, ct si pentru modificarea sa ulterioara. Acesta este unul dintre principalele motive pentru care paradigma orientata spre obiecte cstiga teren: un sistem proiectat orientat spre obiecte este prin definitie un sistem modular. Implementarea Aceasta faza se refera la scrierea efectiva a programelor, crearea fisierelor de date si dezvoltarea bazelor de date. Testarea Aceasta faza este strns legata de faza anterioara, deoarece n normal fiecare modul al sistemului este testat n timpul implementarii, ntr-un sistem bine proiectat, fiecare modul poate fi testat n mod independent, utilizndu-se versiuni simplificate ale celorlalte module pentru a se simula interactiunile dine modulul tinta si restul sistemului. Desigur, pe masura ce diferite module sunt analizate si combinate, testarea individuala trebuie continuata cu testarea generala a ntregului sistem.[1]

2. Modelul cascada Stefanescu Yasmin


Analiza ciclului de via (LCA, Life Cycle Assessment) este o metod de a evalua aspectele de mediu i impacturile poteniale asociate cu un produs sau sistem. Este utilizat din ce n ce mai mult n faza de creare a noului produs cu scopul de a reduce impactul total prin ciclul de via (material brut, manufactur, distribuie, utilizare i meninere, reutilizare, reciclare i nlturarea final). Datele de ciclu de via pot fi de asemenea foarte folositoare pentru informaiile aduse utilizatorilor finali, astfel c impactul asupra mediului n faza de utilizare este redus, i pentru gestionarea sfritului vieii unui produs (de exemplu identificarea materialelor cu potenial de hazard sau cele valoroase din produs). Un model de ciclu de via este o ncercare de a analiza stadiile prin care trece un program din momentul n care a fost imaginat i pn la ultimele sale utilizri. Modelul tinde s fie mai complex pentru software dect pentru alte tipuri de produse i are un numr de diferene majore de exemplu, fazele de producie ale majoritii produselor presupun realizarea unui numr mare de copii ale produsului, i astfel aceasta este partea cea mai consumatoare de timp i bani din proces: pentru software, realizarea de copii este doar copierea de discuri sau casete o parte foarte ieftin a ntregului proces.

2.1 Modelul de via cascad. Notiuni generale Modelul de via cascad este un proces secvenial de creare, utilizat deseori n dezvoltarea proceselor software n care progresul este considerat ca o cdere continu (ca o cascad) prin fazele de Concepere, Iniializare, Analiz, Creare, Construcie, Testare, Producie/Implementare i Meninere.

Concepere Iniializare Analiz Creare Construcie Testare Producie Meninere

Modelul cascad nemodificat. Progresul curge din vrf spre capt, ca o cascad. Dezvoltarea modelului cascad i are originea n industriile de manufactur i construcii: medii fizice foarte structurate n care schimbrile dup implementare pot fi foarte costisitoare, dac nu chiar imposibile. Din moment ce nu exist metodologii mai formale de dezvoltare software n acest moment, modelul orientat pe hardware a fost pur i simplu adaptat pentru dezvoltarea software. Prima prezentare cunoscut ce descrie faze similare n ingineria software a fost inut de Herbert D. Benington la Symposium on advanced programming methods for digital computers, n anul 1956. Aceast prezentare a fost despre dezvoltarea de software pentru SAGE. n 1983, lucrarea a fost republicat cu o not n care Benington evidenia faptul c procesul nu era de fapt realuzat n sens strict de sus n jos, ci depindea de un prototip. Prima descriere formal a modelului cascad este deseori citat ca un articol din 1970 de Winston W. Royce, dei Royce nu a folosit termenul cascad n articolul su. Royce a prezentat modelul ca un exemplu de model nefuncional, cu greeli. Acesta este, de fapt, modul n care termenul este utilizat n general n scris despre dezvoltarea software pentru a descrie un punct de vedere critic a unei practici software utilizate n mod comun. 2.2 Argumente Timpul petrecut la nceput n ciclul de producie software poate duce la economii mari n stadiile ulterioare. McConnell arat faptul c o eroare gsit n stadiile de nceput (cum ar fi specificarea necesitilor sau design/creare) este mai economic din punct de vedere al fondurilor, efortului i timpului de reparare dect aceeai eroare gsit utlerior n proces. De
7

exemplu, dac un concept de program se dovedete imposibil de implementat, este mai uor de reparat conceptul la stadiul de creare dect s se realizeze acest lucru cteva luni mai trziu, cnd componentele de program sunt interogate, astfel c toat munca realizat s fie aruncat din cauza unei erori de design. Aceasta este ideea central din spatele modelului cascad: timpul petrecut mai devreme n asigurarea faptului c necesitile i conceptul sunt corecte economisete mult mai mult timp i efort ulterios. Astfel, gndirea celor ce urmeaz procesul n cascad se asigur c acest stadiu este 100% complet i complet corect nainte de a trece la urmtorul stadiu. Necesitile de program ar trebui bine conturate nainte de a ncepe procesul de creare, altfel munca depus pentru un concept ce se bazeaz pe necesiti incorecte este pierdut. Designul programului ar trebui s fie perfect naintea nceperii implementrii, altfel implementarea produsului greit duce la munc pierdut. Un argument n plus pentru modelul n cascad este acela c pune accentul pe documentaie (cum ar fi documentele din care reies necesitile i documentele de design), la fel ca i codul surs. n metodologiile mai puin documentate, dac membrii echipei prsesc echipa, multe dintre cunotine se pierd i poate fi dificil continuarea proiectului. Dac exist o documentaie complet, membrii noi ai echipei pot s se familiarizeze cu proiectul prin citirea documentaiei. Unele persoane prefer modelul n cascad pentru abordarea sa simpl i aduc ca argument faptul c este mai disciplinat. Modelul n cascad asigur o abordare structurat; modelul n sine progreseaz liniar prin faze discrete, uor de neles i uor explicabile i astfel este uor de neles; de asemenea, asigur pietre de hotar n procesul de dezvoltare. Este poate motivul pentru care modelul cascad este utilizat ca exemplu de nceput pentru un model de dezvoltare n multe texte i cursuri de inginerie software. Muli consider c modelul cascad este o idee proasta n practic consider c e imposibil ca orice proiect ce nu este banal s termine o faz a ciclului de via al software-ului n mod perfect nainte de a trece la fazele urmtoare i de a nva din ele. De exemplu, clienii ar putea s nu tie cu exactitate necesitile ce apar nainte de a examina un prototip funcional i s comenteze pe baza lui. Ar putea schimba cerinele imediat. Creatorii i programatorii pot avea puin control asupra acestui lucru. Dac clienii schimb cerinele lor dup ce design-ul este finisat, design-ul trebuie s fie modificat pentru a acomoda noile cerine. Acest lucru nseamna s se invalideze efectiv un numar considerabil de ore de munc, ceea ce nseamn un cost crescut, n special dac o mare cantitate de resurse ale unui proiect au fost deja investite n design. Creatorii ar putea s nu fie contieni de dificultile viitoare de implementare atunci cnd realizeaz un design pentru un produs software neimplementat. Cu alte cuvinte, poate deveni clar n faza de implementare c o anumit zon a funcionalitii programului este extrem de greu de implementat. n acest caz, este mai bun revizuirea design-ului dect a se persista n ccrearea unui design bazat pe predicii greite, i acest lucru nu ia n considerare problemele nou descoperite.

Chiar i fr asemnea schimbare a specificaiei n timpul implementrii, exist opiunea fie de a ncepe un nou proiect de la zero, fie s se continue cel deja existent. Metodologia cascad poate fi utilizat pentur o mbuntire continu, chiar i pentru software existent, creat de o alt echip. La fel ca i n cazul n care un analist de sistem nu reuete s capteze necesitile clientului n mod corect, impacturile rezultate asupra fazelor urmtoare (n special codarea) pot fi nc ndulcite prin aceast metod n practic. Steve McConnell, n Code Complete (o carte ce critic utilizarea larg a modelului n cascad) se refer la design ca o problem afurisit o problem ale crei cerine i limitri nu pot fi cunoscute complet nainte de a fi terminat. Implicarea acesteia este c este imposibil s se perfecioneze o faz a dezvoltrii software, deci este imposibil dac se utilizeaz modelul cascad s se treac la urmtoarea etap. David Parnas, n A rational Design Process: How and Why to Fake It, scrie: Multe dintre detaliile sistemului devin cunoscute numai dup ce se progreseaz n implementarea sistemului. Unele dintre lucrurile pe care le nvm invalideaz design-ul nostru i trebuie s mergem napoi. Extinznd conceptul de deasupra, prile interesate (personal non-IT) pot s nu fie pe deplin contieni de capacitile tehnologiei ce este implementat. Acest lucru poate duce la ceea ce ei cred c este posibil, definind cerine i necesiti. Acest lucru piate duce la un design ce nu utilizeaz potenialul complet a ceea ce poate face noua tehnologie, sau s copieze pur i simplu aplicaia existent sau procesul cu noua tehnologie. Acest lucru poate cauza schimbri substaniale n cerinele de implementare odat ce prile interesate devin mai contiente de funcionalitile disponibile ale noii tehnologii. Un exemplu este acela n care o organizaie trece de la procese bazate pe hrtie la procese electronice. n timp ce livrabilele cheie ale procesului pe hrtie trebuie s fie meninute, beneficiile validrii datelor n timp real, urmrirea i deciziile automate pot fi s nu fie anticipate n fazele de nceput ale proiectului. Datorit tipurilor de critici aduse, unele organizaii, cum ar fi Departamentul de Aprare (DoD) a SUA au acum o preferin mpotriva metodelor de tip cascad, ncepnd cu MIL-STD498. Standardul curent DoD 5000.2, lansat n 2000, susine o preferin clar mpotriva cascadei: Exist dou abordri, cascad evoluionist i cu pas unic, pentru o capacitate complet. O abordare evoluionist este preferat, deoarece capabilitatea final asigurat utilizatorului este mprit n dou sau mai multe blocuri, cu incremente n cretere ale capabilitii. Dezvoltarea software va utiliza un proces de dezvoltare de tip spiral iterativ n care versiunile software ce se extind continuu se bazeaz pe nvarea din dezvoltarea iniial.

2.3 Modele modificate Ca rspuns la problemele ntlnite cu modelul cascad pur, au fost introduse multe modele cascad modificate. Aceste modele pot adesa unele sau toate criticile modelului de cascad pur. Multe modele diferite sunt acoperite de Steve McConnell n capitolul de
9

planificare a ciclului de via n cartea sa, Dezvoltarea rapid: mblnzirea programelor software slbatice. Etapele modelului cascad pot fi caracterizate n diverse moduri, inclusiv n modul urmtor: Planificarea proiectului, studii de fezabilitate: Stabilete o vedere de nivel nalt al proiectului dorit i i determin elurile. Analiza sistemului, definirea cerinelor: Rafineaz intele proiectului n funcii definite i operaii ale aplicrii dorite. Analizeaz informaiile despre necesitile utilizatorilor finali. Crearea sistemului: Descrie caracteristicile dorite i operaiile n detaliu, inclusiv reguli de afaceri, diagrame ale proceselor, pseudocod i alte documentaii. Implementarea: Codul real este scris aici. Integrare i testare: Aduce toate piesele laolalt ntr-un mediu special de testare, apoi verific existena erorilor i interoperabilitatea. Acceptarea, instalarea, dezvoltarea: Stadiul final al dezvoltrii iniiale, n care software-ul este pus n producie. ntreinerea: Ceea ce se petrece n timpul restului vieii software-ului: schimbri, corecii, adugri, micri la diferite platforme de computare i altele. Aceast etap se repet de nenumrate ori. Modelul cascad este bine neles, dar nu este la fel de util precum era nainte. El presupune c singurul rol al utilizatorilor este n specificarea cerinelor, i c toate cerinele pot fi specificate n avans. Din pcate, necesitile sunt n cretere i se schimb n timpul procesului i mai trziu, fiind nevoie de feedback considerabil i consultare iterativ. Modelul presupune c fazele sunt organizate ntr-o ordine liniar. Un proiect ncepe cu analiza dezabilitii. Dup demonstrarea cu succes a fezabilitii, analiza necesitilor i proiectarea proiectelor ncepe. Crearea ncepe dup ce se termin analiza necesitilor. Codarea ncepe dup realizarea design-ului. Odat ce programarea se termin, codul este integrat i testat. La completarea cu succes a testrii, sistemul este instalat. Dup aceasta are loc operarea regulat i ntreinerea. Cu modelul cascad, activitile realizate n proiectul de dezvoltare a software-ului sunt analiza necesitilor, planificarea proiectelor, design-ul sistemului, design-ul detaliat, codarea i testarea unitilor, integrarea sistemului i testarea. Ordonarea liniar a activitilor are anumite consecine importante. n primul rnd, pentru a identifica n mod clar finalul unei etape i ncepului alteia. Unele mecanisme de certificare trebuie s fie folosite la finalul fiecrei faze.acest lucru este de obicei realizat prin anumite verificri i validri. Validarea presupune confirmarea c rezultatul unei etape se potrivete cu nceputul su (care este rezultatul etapei anterioare) i c rezultatul etapei se potrivete cu necesitile totale ale sistemului. Consecinele necesitii de certificare sunt c fiecare faz trebuie s aib un rezultat definit ce poate fi evaluat i certificat. Astfel, atunci cnd activitile unei etape sunt complete, ar trebui s fie un produs rezultat al fazei i scopul etapei este de a produce acel produs. Rezultatul etapelor anterioare sunt deseori numite produse intermediare sau documentul de design. Pentru faza de codare, rezultatul este codul. Din acest punct de vedere, rezultatul unui produs software
10

este acela de a justifica programul final mpreun cu utilizarea documentaiei cu documentul de necesiti, documentul de design, planul de proiect, planul de testare i rezultatele testrii. O alt implicare a ordonrii liniare de etape este aceea c dup ce fiecare etap este completat i rezultatele sale sunt certificate, aceste rezultate devin date de intrare pentru urmtoarea etap i nu trebuie schimbate sau modificate. Totui, nu se poate evita schimbarea necesitilor i trebuie acionat corespunztor. Schimbrile efectuate asupra rezultatului unei etape afecteaz etapele ulterioare. Aceste schimbri trebuie fcute ntr-un mod controlat dup evaluarea efectului fiecrei schimbri asupra proiectului. Rezultatele certificate ale unei faze ce este lansat este numit o baz. Gestionarea configurrii asigur c orice schimbri ale unei baze sunt realizate dup o evaluare atent, deoarece interesele tuturor prilor sunt afectate de aceasta. Exist dou presupuneri de baz ce justific ordonarea liniar a etapelor n modul propus de modelul cascad. Pentru un proiect de succes ce duce la un produs de succes, toate fazele prezentate n modelul cascad trebuie efectuate oricum. Orice ordonare diferit a etapellor va duce la un produs software mai puin dect reuit. 2.4 Rezultatul proiectului n modelul cascad Setul de documente ce formeaz minimul ce ar trebui produs n fiecare proiect sunt: Document de cerine Planul proiectului Document de design al sistemului Document de design detaliat Plan de test i raport de test Cod final Manuale software (manualul utilizatorului, manual de instalare etc) Raporturi de evaluare Cu excepia ultimului, acestea sunt rezultatele etapelor. Pentru a certifica un rezultat al unui produs al unei etape naintea nceperii urmtoarei etape, se realizeaz deseori evaluri. Evalurile sunt necesare n special pentru etapele de realizarea cerinelor i a designului, din moment ce alte mijloace de certificare deseori nu sunt disponibile. Evalurile sunt ntlniri formale pentru a descoperi deficienele ntr-un produs. Rapoartele de evaluare sunt rezultatul acestor evaluri.

11

2.5 Avantajele modelului de ciclu de via cascad Uor de explicat utilizatorilor. Etapele i activitile sunt bine definite. Este util planificarea i programarea proiectului. Verificarea n fiecare etap asigur detecia timpurie a erorilor/nenelegerilor. Uor de manevrat datorit rigiditii modelului. Etapele sunt procesate i completate pe rnd. Funcioneaz bine pentru proiectele mai mici unde necesitile sunt foarte bine nelese sau pentru automatizarea unor sisteme deja existente.

2.6 Limitri ale modelului de ciclu de via cascad Ajustarea scopului n timpul ciclului de via poate omor un proiect. Nu se introduce software funcional pn spre finalul ciclului de via. Cantiti mari de risc i nesiguran. Model slab pentru proiectele complexe i obiect-orientate. Model slab pentru proiectele lungi i continue. Model slab acolo unde necesitile au un risc moderat spre ridicat de a se schimba.

Modelul cascad presupune c toate cerinele unui sistem pot fi ngheate naintea nceperii design-ului. Acest lucru este posibil pentru sistemele create s automatizeze un sistem manual deja existent. Dar pentru un sistem absolut nou, determinarea cerinelor este dificil, din moment ce nici chiar utilizatorul nu tie cerinele. Astfel, a avea cerine ce nu se schimb (sau se schimbp doar puin) este nerealist pentru un asemenea proiect. nghearea cerinelor necesit deseori alegerea hardware-ului (din moment ce formeaz o parte a specificaiilor necesitilor). Un proiect mare ar putea dura civa ani pn la finalizare. Dac hardware-ul este selectat timpuriu, apoi datorit vitezei la care tehnologia hardware se schimb, este foarte probabil ca software-ul final s necesite o tehnologie hardware ce este pe cale s devin nvechit. Acest lucru este n mod clar nedorit pentru software att de costisitor. Modelul cascad stipuleaz faptul c cerinele ar trebui specificate complet nainte ca restul dezvoltrii s poat ncepe. n anumite situaii ar putea fi de dorit ca mai nti s se dezvolte o parte a sistemului complet, iar apoi s se mbunteasc sistemul. Acest lucru este deseori efectuat pentru produsele software ce sunt realizate nu neaprat pentru un client (unde clientul joac un rol important n specificarea cerinelor), dar pentru piaa general, n care cerinele sunt determinate cel mai probabil de ctre dezvoltatori.

12

2.7 Etape Se poate considera un model cascad cu 7 etape ce se includ n cele patru ale unui model SDLC (Software Development Life Cycle): 1. Faza de decizie Faza de decizie a unui SDLC este atunci cnd se decide ce se dorete ss e implementeze ca software. n aceast faz sunt 3 etape:

Situaia de afaceri
Cerinele utilizatorilor Specificaiile sistemului Design-ul sistemului Design Design-ul componentelor Construcia compoenentelor Dezvoltare Testare Demonstrare

Decizie

Faza de Decizie Faza de Decizie a unui SDLC este atunci cnd se decide ce se dorete a se implementa ca software. n aceast faz sunt 3 etape: Situaia de afaceri ceea ce utilizatorul dorete s obin de la software. Cerinele utilizatorilor - ceea ce software-ul trebuie s fac pentru afacere. Specificaiile sistemului ceea ce software-ul trebuie s realizeze n termeni de computare pentru a ndeplini cerinele clienilor. Situaia de afaceri Aceasta este justificarea pentru a construi sistemul software i trebuie s acopere un numr de domenii, incluznd: Care este situaia curent a afacerii i software-ului. Care este oportunitatea de afaceri pe care software-ul o va rezolva.
13

Care sunt diversele strategii de soluii i fezabilitatea lor. Care este strategia de soluie preferat. Care este relaia costuri - beneficii. Care sunt presupunerile, riscurile i constrngerile posibile. Care este abordarea de implementare n linii mari.

O cantitate considerabil de munc trebuie s fie realizat de ctre utilizatori cu date de intrare oferite de dezvoltatori pentru a produce o situaie de afaceri. Beneficiile realizrii acestui lucru sunt oferirea tuturor din proiect a unei hri clare a locului n care se ndreapt utilizatorii i de ce. Cerinele utilizatorilor Urmtoarea etap este aceea de a defini un set de cerine ale utilizatorilor. Acestea definesc pentru strategia preferat de soluii ceea ce sistemul software trebuie s obin pentru a mplini oportunitatea de afaceri. Domeniile ce trebuie incluse sunt: Cerine funcionale ce trebuie s realizeze sistemul, de exemplu pentru a pstra detalii ale arhivelor utilizatorilor. Cerine non-funcionale sunt dou tipuri: o Constrngeri de performane ce performan este necesar din partea sistemului, de exemplu dac va aduce la zi arhivele clienior peste noapte. o Contrngeri de dezvoltare ce restricii asupra dezvoltrii se vor aplica, de exemplu dac sistemul trebuie s fie disponibil la un anumit moment. Obiectivele de design care sunt cele mai importante caracteristici ce se aplic sistemului. Specificaiile sistemului Specificaiile sistemului au loc atunci cnd se trece de la concentrarea pe utilizatori la sistemul n dezoltare. Este design-ul logic a sistemului software i modul de a-l realiza. Acoper: Procesele sistemului ce proces tehnic este necesar pentru a implementa fiecare proces de afaceri. Interfee externe ceea ce este necesar pentru sistem pentru a comunica n afar, inclusiv: o Interfee tranzacionale ceea ce este necesar pentru a comunica cu utilizatorii (cum ar fi monitoare). o Interfee de raport ce tipuri de rapoarte sunt necesare. o Interfee de aplicaii ce conexiuni sunt necesare pentru alte sisteme software. Cerine non-funcionale care sunt constrngerile asupra sistemului. Suprapunerea stadiilor Caracteristica distinctiv a tuturor celor trei etape n Decizie este faptul c se ocup de ceea ce se dorete. Totui, graniele dintre ele se pot suprapune. Utilizatorul dezvolt att situaia de afaceri ct i cerinele utilizatorului i probleme din oricare pot trece la cealalt etap sau chiar s fie acoperite de ambele. Cheia este de a asigura c ele sunt acoperite mcar ntr-un loc.

14

Grania dintre Cerinele utilizatorilor i Specificaiile sistemului poate avea o mare suprapunere, n special din moment ce ambele au ca scop informarea dezvoltatorilor. Diferenele cheie dintre cele dou sunt: Cerinele utilizatorilor sunt scrise de ctre utilizatori asistai de dezvoltatori, n timp ce Specificaiile sistemului sunt scrise de dezvoltatori asistai de utilizatori. Cerinele utilizatorilor exprim funcionalitatea necesar n termeni de ceea ce afacerea dorete s obin, n timp ce Specificaiile sistemului exprim funcionalitatea n termeni de ceea ce sistemele software ar putea realiza. Faza de Design Faza de Design are loc atunci cnd diverse cerine sunt mapate la mediul software i au loc deciziile de implementare. Aceast faz se concentreaz pe modul n care software-ul va fi realizat. Aceast versiune a modelului cascad are dou etape: Design-ul sistemului modul n care software-ul va fi structurat n componente. Design-ul componentelor modul n care o component va fi structurat. Design-ul sistemului Etapa de design a sistemului ia Specificaiile sistemului i creeaz arhitectura sistemului. Acest lucru este realizat prin definirea unei serii de componente mpreun cu ceea ce realizeaz i cum interacioneaz cu alte componente. Aceste componente pot fi alte sisteme, interfee, module de cod, ecrane, baze de date etc. ceea ce nu este definit este detaliul cu privire la modul n care va funciona fiecare component. Design-ul componentelor Etapa de design al componentelor este design-ul detaliat a modului n care o anumit component va funciona, i cum comunic rezultatele sale ctre alte componente prin interfee. Nu este probabil s existe un document ce acoper design-ul tuturor componentelor deoarece ele sunt create de persoane diferite. n multe cazuri, aceste design-uri sunt realizate de ctre cei ce codeaz. Faza de dezvoltare Faza de dezvoltare este etapa de Construcie a componentei n modelul cascad. Ea se ocup cu construcia componentelor necesare pentru software. Componentele software vin n multe forme i variaz de la software realizat pe comand dezvoltat n mod special pentru sistem, pn la pachetul software ce este configurat pentru a satisface cerinele. Exist dou principale tipuri de pachete software: COTS (Commercial Off The Shelf) Acestea sunt pachete de aplicaii ce acoper nevoi variate ale utilizatorilor ce sunt aduse i configurate de funrizori comerciali. Open Source Acestea sunt pachete variate de aplicaii dar sunt ntreinute de o comunitate de utilizatori. Software-ul realizat pe comand va putea ndeplini necesitile exacte, dar este costisitoare producia sa. n teorie, exist economii de pre utiliznd pachete software. n teorie, deoarece costurile de instalare pot fi mai mici, dar costul rulrii pachetului pe parcursul vieii sale poate fi mai mare.
15

Faza de demonstrare Faza de demonstrare este etapa de test i implic faptul c sistemul software ndeplinete toate etapele de design, specificaii i cerine din fazele de Decizie i Design. Observaii Aceste apte etape realizeaz modelul cascad aa cum este utilizat n mod tradiional, dar flexibilitatea n modul n care este utilizat afecteaz ct de succes va avea. Exist un numr de probleme cu modelul cascad, de aceea a evoluat n modelul n V. 2.8 Aplicaii Modelul cascad poate fi utilizat cu succes atunci cnd necesitile sunt bine nelese de la nceput i nu se ateapt s se schimbe sau evolueze pe parcursul vieii proiectului. Riscurile proiectului ar trebui s fie relativ joase.

16

3. Modelul in V Laza Laura


Modelul in V presupune un ciclu de viata secvential. Planificarile se fac o data cu parcurgerea primei ramuri. La fel ca modelul cascada, ciclul de viata in V este o cale secventiala de executie a proceselor. Fiecare faza trebuie sa fie finalizata inainte ca urmatoarea faza sa inceapa. Modelul in V reprezinta un proces de dezvoltare software care este, de asemenea, aplicabil in dezvoltarea hardware. Acest model arata legaturile dintre fazele dezvoltarii ciclului de viata si ii este asociat faza de testare. Axa orizontala si axa verticala reprezinta timpul sau exhaustivitatea proiectului (de la stanga la dreapta) si respectiv, nivelul de abstractizare. Conceptul modelul V a fost dezvoltat simultan, dar independent in Germania si in Statele Unite ale Americii la sfarsitul anilor 80. Modelul V german a fost dezvoltat de IABG in Ottobrunn in colaborare cu Ministerul Federal al Apararii in Koblenz. A fost preluat de catre Ministerul de Interne Federal pentru autoritatile de domeniu public in anul 1992. 3.1 Obiective Modelul in V ofera indrumare pentru planificarea si realizarea proiectelor. Urmatoarele obiective trebuie indeplinite pentru executia unui proiect: Reducerea riscurilor proiectului Imbunatatirea si garantia calitatii Reducerea costului total a intregului proiect si a ciclului de viata a sistemului Imbunatatirea comunicatiei intre toate partile interesate. 3.2 Schema modelului in V:

17

3.3 Fazele modelului in V Fazele de verificare Analiza cerintelor In faza de analiza a cerintelor, cerintele sistemului sunt cumulate in urma analizei nevoilor utilizatorului. Aceasta faza este are scopul de a stabili ce trebuie sa efectueze sistemul ideal. Totusi, nu determina cum va fi proiectat si construit software-ul. De obicei, este generat un document numit cererile utilizatorului. Acest document descrie functionalitatea, interfata, performanta etc a sistemului asa cum le doreste utlizatorul, ajutand la faza de proiectare a sistemului. Proiectarea sistemului Proiectarea sistemului este faza in care inginerii de sistem analizeaza scopul sistemului propus prin studierea documentului cu cerintele utilizatorului. Acestia gasesc posibilitati si tehnici prin care poti fi implementate aceste cerinte. Daca una din aceste cerinte nu poate fi implementata, utilizatorul este informat asupra acestei probleme. Se stabileste un compromis si se modifica corespunzator documentul cu cererile utilizatorului. Este generat un nou document cu precizarile software-ului ce foloseste ca plan pentru etapa de dezvoltare. Acest document contine organizarea generala a sistemului, structurile de date, ferestre esantionate, diagrame entitate, dictionar de date etc. Proiectarea arhitecturii Faza proiectarii arhitecturii calculatorului si a arhitecturii software-ului este o proiectare de nivel inalt. Selectarea initiala a arhitecturii trebuie sa realizeze tot ceea ce presupune lista de module, descriere scurta a fiecarui modul, interfetele dintre ele, dependentele, tabelele de date etc. Proiectarea modulului Faza de proiectare a modulului este o faza de proiectare de nivel scazut. Sistemul proiectat este impartit in unitati mai mici sau module, iar fiecare dintre ele este explicata astfel incat programatorul sa poata incepe codarea. Documentul proiectarii de nivel scazut contine o descriere detalitata a modulului in pseudocod: tabele de date, detaliile interfetei, lista mesajelor de eroare etc. Proiectarea unitatii de testare este dezvoltata tot in acest stadiu. Fazele de validare Testarea unitara In programare, testarea unitara este o metoda prin care fiecare unitate de cod sursa este testata pentru a determina daca sunt apte pentru utilizare. O unitate este cea mai mica componenta testabila a unei aplicatii. Scopul crearii unitatilor de test este de a verifica codul logic intern prin testarea tuturor sectoarelor din punct de vedere al functiilor acestora. Testarea integrata

18

In testarea integrata modulele separate vor fi testate impreuna pentru a expune defectele in interfete si in interactiunea dintre componentele integrate. Testarea este un fel de cutie neagra a codului. Testarea sistemului Testarea sistemului compara precizarile sistemului cu sistemul actual, Dupa ce testarea integrata este completa urmeaza testarea sistemului. Aceasta verifica daca produsul integrat indeplineste cerintele specificate. Testarea acceptarii utilizatorului Testarea acceptarii este faza testarii ce determina daca un sistem satisface cerintele specificate in faza de analiza a cerintelor. Proiectarea acestei testari este derivata din documentul de cerinte. Faza testarii acceptarii este faza in care clientul hotaraste daca accepta sau nu sistemul. Aceasta testare contine doua proceduri: definirea criteriului de acceptare si dezvoltarea unui plan de acceptare. Testarea lansarii Testarea lansarii este o faza care determina daca software-ul este potrivit pentru organizarea ultimului utilizator.

3.4 Avantaje si dezavantaje Avantaje: - Simplu si usor de utilizat, mai ales pentru proiecte mici. - Fiecare faza are lucruri specifice, controlabile, de livrat. - Este mai bun decat modelul in cascada deoarece planul de teste este facut inca de la inceput. Dezavantaje: - Rigid, greu de introdus modificari in caz ca acestea apar - Nu produce prototipuri timpurii. - Software-ul este dezvoltat in timpul fazei de implementare, deci nu sunt produse prototipuri anterioare. - Modelul nu asigura o cale sigura pentru rezolvarea problemelor gasite in urma fazelor de testare.

19

4. Modelul spirala Laza Laura


4.1 Notiuni generale Modelul spirala al dezvoltarii si evolutiei software reprezinta riscul condus catre analiza si structura procesului software. Aceasta abordare a fost dezvoltata de catre Barry Boehm si contine elemente ale dezvoltarii pornite de la anumite specificatii, metode ale procesului de dezvoltare a produselor pe baza unui prototip, impreuna cu clasicul ciclu de viata al produsului software. Acestea se realizeaza prin reprezentarea dezvoltarii iterative a ciclului sub forma unei spirale extinse, cu cicluri interne ce indica analiza din timp a sistemului si cu cicluri externe ce indica ciclul de viata al software-ului. Dimensiunea radial indica costuri cumulate ale dezvoltarii, iar dimensiunea unghiulara indica progresul facut pentru efectuarea fiecarai dezvoltari ale spiralei. [2] Analiza riscurilor, ce cauta sa identifica situatiile ce cauzeaza esuarea dezvoltarii apare in fiecare ciclu al spiralei. In fiecare ciclu este reprezentat aproximativ aceeasi cantitate de inlocuiri unghiulare, in timp ce volumul inlocuit indica cresterea nivelurilor de incercari pentru analiza.

4.2 Schema modelului spirala

4.3 Descrierea modelului spirala Evolutia spiralei consta in cele 4 cadrane din figura de mai sus. Primul cadran determina obiectivele, alternativele si constrangerile. Al doilea cadran evalueaza alternativele, identifica si rezolva riscurile. Al treilea cadran dezvolta si verifica produsul de la urmatorul nivel. Iar cadranul al patrulea planifica urmatoarele faze. De altfel, spirala este orientate catre dezvoltarea software, conceptul fiind egal aplicabil sistemelor hardware.

20

Cadranul 1 Activitatile desfasurate in acest cadran sunt urmatoarele: - Stabileste un acord al sistemului sau a obiectivelor produsului: performanta, functionalitate si abilitatea de adaptare la schimbari. - Investigheaza implementarile alternative: model, reutilizare, procurare si modificare. - Investigheaza constrangerile impuse cu privire la alternative: tehnologie, cost, program, suport si riscuri. O data ce toate acestea au fost stabilite, se trece la cadranul al doilea. Cadranul 2 Activitatile ingineresti reprezentate in acest cadran selecteaza o abordare alternative ce satisfice mai bine tehnologia, costul, programul, suportul si riscul constrangerilor. Aici se pune accentul pe atenuarea riscului. Este analizata fiecare alternativa si este folosita in asa fel incat sa reduca riscurile asociate dezvoltarii deciziilor. Boehm descrie aceste activitati spunand ca pot implica prototipuri, simulari, benchmarking, chestionare de administrare, modelare analitica si alte tehnici de rezolutie a riscului. Daca operatia critica si/sau problemele tehnice precum riscul performantei sau al interoperabilitatii ramane, este posibila adaugarea unor detalii in plus a prototipului inainte de trecerea la urmatorul cadran. Cadranul 3 Daca se determina ca prototipul anterior are rezolvate operatiile critice/problemele tehnice, activitatile de dezvoltare si verificare, se trece la urmatorul nivel. Ca rezultat, modul de baza cascada poate fi utilizat(descrierea, conceptual operatiilor, dezvoltarea, integrarea si testarea urmatorului sistem). Se poate utiliza si dezvoltarea incrementala. Cadranul 4 Modelul de dezvoltare in spirala are o caracteristica comuna cu toate celelalte modele: nevoia planificarii tehnice avansate si analize multidisciplinare la asteptarea critica. Fiecare ciclu al modelului culmina cu o analiza tehnica ce evalueaza starea, progresul, maturitatea, meritele si riscurile dezvoltarii.

Implementarile anterioare ale spiralei pot implica nivele mai joase ce pot urmari aceleasi cai ale cadranelor si aceleasi considerente de decizie. 4.4 Avantaje si dezavantaje Avantaje - Analiza crescuta a riscurilor - Ideal pentru proiecte mari - Software-ul este produs devreme in ciclul de viata - Dezvoltare completa a modelului software la proiectele cu cereri neclare - Flexibilitate.

21

Dezavantaje - Model costisitor - Analiza riscurilor necesita expertiza specifica de nivel inalt - Succesul proiectului depinde puternic de faza de analiza a riscurilor - Nu este potrivit pentru proiecte mici - Este greu de inteles de catre utilizatorii fara pregatire tehnica. 4.5 Aplicatii Modelul spirala se foloseste: Atunci cand crearea unui prototip este potrivita; Atunci cand costurile si evaluarea riscurilor este importanta; Pentru proiecte de risc mediu sau crescut; Pentru proiecte pe termen lung; Atunci cand utilizatorii nu sunt siguri de nevoile lor; Atunci cand cererile sunt complexe.

22

5. Modelul incremental Guta Ovidiu


Modelul ciclului de viata "Incremental" este opus modelului in cascada . El se bazeaza pe o idee foarte simpla: daca un sistem este prea complex pentru a fi inteles, conceput sau realizat intr-o singura faza este mai bine sa fie realizat in mai multe faze, prin evolutie.

5.1 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

23

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 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 iteratie a ciclului de viata iterativ si incremental reproduce ciclul de viata in cascada la o scara mai mica. Obiectivele unei iteratii sunt stabilite pe baza evaluarii iteratiilor precedente. Documentatia este construita treptat, in timpul fiecarei iteratii. La sfarsitul dezvoltarii, documentele obtinute au aceeasi forma cu cele obtinute in maniera conventionala.
24

5.2 Avantaje si dezavantaje 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 viata iterativ se bazeaza pe evolutia prototipurilor executabile, masurabile si deci pe evolutia elementelor concrete. El este opus din acest punct de vedere ciclului de viata in cascada care se bazeaza pe elaborarea de documente. Livrarile forteaza echipa sa dea rezultate concrete in mod regulat.
25

Integrarea diferitelor componente ale programului este realizata intr-o maniera progresiva in timpul constructiei. Progresele se masoara prin programe demonstrabile mai degraba decat prin documente sau estimari, ca in ciclul de viata in cascada;

In cursul dezvoltarii, clientul poate utiliza prototipurile. Demonstrarea prototipurilor prezinta numeroase avantaje: - utilizatorul este pus in fata situatiilor de utilizare concrete care-i permit sa-si defineasca mai bine dorintele si sa le comunice echipei de dezvoltare; - utilizatorul devine partener al proiectului; el isi ia partea de responsabilitate in noul sistem si de fapt il accepta mai usor;

Dezavantaje Ciclul de viata Incremental se bazeaza pe evoluaia prototipurilor executabile. Din nefericire, programele nu se preteaza in mod natural evolutiei, din contra, ele sunt deseori foarte "fragile" la modificari. Efectul unei modificari locale se poate propaga in ansamblul aplicatiei. Fiecare nou increment poate necesita reorganizarea structurii interne, degradand arhitectura initiala a programului, facandu-l greu de verificat si de intretinut. Erorile de proiectare sunt mai greu de eliminat. Abordarea obiect bazata pe modularitate si incapsulare conduce la programe mai robuste si mai rezistente fata de schimbari. Din acest punct de vedere, abordarea obiect furnizeaza un cadru confortabil pentru dezvoltarea prin evolutie, intr-o maniera iterativa. 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 ).

5.3 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
26

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. O varianta a modelului este Numai implementarea incrementala: Urmeaza modelul cascada pana in faza de implementare In timpul analizei cerintelor si proiectarii de sistem: o Se definesc subseturi / subsisteme care pot fi livrate o 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.

5.4 Rational Unified Process 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. Centrat pe arhitectura

27

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.

28

6. Modelul code-and-fix Stefanescu Yasmin


6.1 Notiuni generale Dezvoltarea code and fix nu este att o strategie deliberat ct este un artefact de naivitate i presiune datorat programului dezvoltatorilor software. Fr a fi un mare design, programatorii ncep imediat s produc codul. ntr-un anumit punct, testarea ncepe (deseori mai trziu n ciclul de dezvoltare), i erorile inevitabile trebuie apoi reparate nainte ca un produs s fie livrat. Acest model ncepe cu o idee general informal de produs i doar dezvolt cod pn cnd un produs este finalizat (sau cnd fondurile sau timpul disponibil se termin). Munca se realizeaz ntr-o ordine aleatoare. 6.2 Avantaje si dezavantaje Avantaje: Nu exist surplus administrativ. Apar semne de progres (cod) zilnic. Expertiz puin. Util pentru proiecte mici, de tipul dovad de concept, cum ar fi reducerea riscurilor. Dezavantaje: Periculos. Nu exist vizibilitate/control. Nu exist o planificare a resurselor. Nu exist termene limit. Greelile sunt greu de detectat/corectat. Imposibil pentru proiectele mari, posibila ntrerupere a comunicaiei, haos. 6.3 Fazele modelului code-and-fix Modelul code and fix este un model cu dou faze. Prima faz a modelului este scrierea codului, iar a doua este repararea lui. Partea negativ a modelului este aceea c codul devine greu de reparat n timp. n plus, modelul nu ofer loc pentru mubtiri viitoare. Acest model este nc utilizat deoarece, n aplicaiile din viaa real, timpul necesar pentru a identifica i repara problema este de obicei foarte limitat, de aceea nu se pierde timpul pentru analiz i redesign. Studiul asupra cerinelor este urmat de codare. Problemele privind specificaiile sau design-ul nu sunt niciodat adresate. n schimb, dezvoltatorii pur i simplu construiesc un produs ce este reconstruit nc o dat i nc o dat, pn cnd clientul este mulumit. Modelul code and fix probabil c este cea mai frecvent utilizat metod de dezvoltare n ingineria software. ncepe cu puin sau chiar fr planificare. Se ncepe imediat dezvoltarea, reparnd problemele pe msr ce apar, pn cnd proiectul este complet. Code and fix este o alegere tentant atunci cnd se are de-a face cu un program strns pentru dezvoltare datorat nceperii dezvoltrii imediat i dorina de a vedea rapid rezultatele. Din pcate, problemele arhitecturale majore apar mai trziu n timpul procesului. De obicei este necesar rescrierea unei mari pri din aplicaie. Modelele de dezvoltare alternativ pot ajuta gsirea problemelor n etapele timpurii ale conceptului, atunci cnd schimbrile sunt mai uoare i mai puin costisitoare.
29

Modelul code and fix este potrivit numai pentru proiecte mici ce nu sunt destinate a servi ca baz pentru o dezvoltare ulterioar. Dezvoltarea ncepe imediat, cu puine, sau deseori fr, planuri. Problemele sunt ntmpinate i defectele sunt fixate pe msur ce apar. Dei acest proces permite dezvoltrii s aib loc rapid, proiectul va ntmpina ntrzieri serioase dac se gsesc probleme arhitecturale majore. Problemele arhitecturale majore, n special acelea descoperite trziu n proces, vor necesita o rescriere a unei mari pri din cod. Code and fix este popular n companiile mici, dar utilizarea sa ar trebui descurajat. Unele din metodele de a descuraja utilizarea sunt: Crearea de echipe cu un amestec de dezvoltatori, personal de la departamentele de marketing i management, i mputernicirea lor pentru a lua decizii asupra caracteristicilor aplicaiei. Includerea managementului n procesul de dezvoltare software; multe ntrzieri sunt datorate faptului c managementul nu se consult cu echipa de dezvoltatori ai produsului i astfel se aleg date de lansare ce nu sunt posibil de obinut. Dup lansarea produsului, trebuie realizat o ntlnire a echipei de producie pentru a discuta ce a funcionat corect i ce a funcionat greit. 6.4 Limitri ale modelului de ciclu de via code and fix Aceast abordare poate s funcioneze bine pentru sistemele mici, dar este foarte nesatisfctor pentru sistemele mai mari. Pe msur ce mrimea codului crete, nelegerea i manipularea sistemului descrete. Puncte tari: Nu se pierde timp pentru planificare, documentaie, asigurarea calitii, aplicarea standardelor sau alte activiti ce nu implic codarea. Este necesar puin experien. Puncte slabe: Periculos. Nu exist mijloace de a evalua calitatea sau de a identifica riscurile. Greelile fundamentale n abordare nu apar rapid, deseori fiind necesar munc mult pentru a scpa de ele. Rezumat privind code and fix Code and fix este singura metod potrivit pentru proiectele mici ce nu au o importan major, cum ar fi demo-urile cu via scurt sau prototipuri la care se renun rapid.

30

6.5 Compararea metodelor de dezvoltare software. Metod Descriere


O metod parial agil ce se axeaz pe tehnici ce suport dezvoltarea evolutiv (iterativ i incremental) a bazelor de date. O metod parial, bazat pe practic, ce descrie tehnici pentru modelarea i documentarea eficient a sistemelor.

Cnd se utilizeaz

Artefacte primare de modelare

Agile Data (AD)

Se ajusteaz filozofiile i tehnicile AD n alte procese evolutive.

Modele Agile data

Agile Model Driven Development (AMDD)

Ajustarea principiilor AM i practicile n alte procese agile sau aproape agile.

Se aplic artefactul potrivit pentru situaia curent.

Agile MSF (Microsoft Solutions Framework)

TBD

TBD

TBD

Agile Unified Process (AUP)

O instan agil a UP (Unified Process), o simplificare dramatic a RUP.

Atunci cnd se dorete ceva ntre XP i tradiionalul RUP, un proces ce este agil dar include explicit activiti i artefacte cu care utilizatorii sunt acomodai, sau pur i simplu ceva gratuit.

Modelul use-case Diagrame de secven UML Modelul de clas UML Modelul fizic de date

Code and Fix

O abodare tipic ineficient de dezvoltare, de obicei urmat de dezvoltatori neexperimentai sau nepricepui, n care ei pur i simplu scriu

Pentru prototipuri ce nu au o durat mare de via.

Codul surs

31

codul fr s implice mult gndire. Denumit de asemenea hacking sau dezvoltare imatur.

Aceasta este o categorie generic de metode bazate pe date, populare n anii 1970 i 1980 Data-Driven cu descoperirea Approach metodelor structurate. Aceastp abordare este n mod tipic riguroas i serial. Aceasta este o metod agil ce a primit certificare ISO 9001. n multe Dynamic System moduri, este o Development formalizare a Method (DSDM) metodelor RAD (Rapid Application Development) din anii 1980. Un proces software riguros, n apte etape, ce include dezvoltarea, operarea i retragerea sistemelor bazate pe software. Enterprise Unified eforturile de Process (EUP) dezvoltare sunt iterative i incrementale. Include o vedere de multisistem ce include activitile de arhitectur de ntreprindere, de management al

Dezvoltarea unui Model de date depozit de date, dei o abordare centrat pe conceptual utilizare este de preferat. Model de date logic Dezvoltarea unei simple aplicaii de afaceri de tip CRUD (Create Read Update Delete). Dezvoltarea unui sistem intensiv de interfa cu utilizatorul. Aplicaie complex de afaceri. Arhitectur de dezvoltare Model fizic de date

Prototip funcional Prototip de design

Nevoia de a gestiona un portofoliu de proiecte, incluznd dar nu limitat la echipe folosind RUP. Atunci cnd au avut succes mai multe proiecte RUP i se dorete s se cunoasc cum s se ia n considerare ntregul ciclu de via al sistemului.

Modelul de afaceri de ntreprinderi Modelul de arhitectur al domeniului ntreprinderii Modelul de arhitectur tehnic a ntreprinderii Artefacte de nivel de proiect

32

reutilizrii, de management al portofoliului i de management al persoanelor. O metod de dezvoltare agil ce se axeaz pe activitile critice necesare pentru a construi softwareul. Echipe de proiect mici, co-localizate (410 persoane). Strategie arhitectural Cerinele sunt nesigure. O relaie potenial bun exist cu prile interesate ale proiectului. Echip mic de proiect (4-20 persoane). Cerinele sunt nesigure. Echipa este dispus s urmreasc o abordare condus de modelare.
TBD

Extreme Programming (XP)

Carduri CRC (Class responsibility collaborator).

Feature-Driven Development (FDD)

O metod de dezvoltare agil bazat pe iteraii scurte ce includ activitile de modelare explicit.

Model de domeniu clas/obiect Caracteristici Diagrame de secven UML Model de clas UML
TBD

Glacial Methodology

TBD

ICONIX

O metod simpl, condus de modelare ce poate fi instaniat ca o mbuntire a RUP sau pe msur ce o metod agil este de sine stttoare. Un proces software cu faze multiple ce includ dezvoltarea, operarea i retragerea sistemelor bazate pe software.

Modelul use-case Echipe de proiecte mici pn la medii (4 pn la 20 de persoane). Dezvoltare de aplicaii de afaceri. Echipe de proiect medii pn la mari (20 sau mai multe persoane) Mandatat (de exemplu de guvern)
33

Diagrame de robustee Diagrame de secven UML Model de clas UML Model logic de date Model logic de procese Model fizic de date

ISO/IEC 12207

s urmeze aceast abordare.


MSF for CMMI (Microsoft Solutions Framework for Capability Maturity Model Integrated)

Model fizic de procese

TBD

TBD

TBD

Object Oriented Software Process (OOSP)

Un CMM riguros de nivel 5 (atunci cnd este instantizat complet), proces a crui axare este pe dezvoltare, operaii, suport i ntreinere a sistemelor utiliznd tehnologii obiectorientate i/sau bazate pe componente. Un proces software prescriptiv pentru dezvoltatori individuali.

Modelul use-case Model de arhitectur de sistem Diagrame de secven UML Model de clas UML Mode de date fizic

Echipe de proiect medii pn la mari (10 sau mai multe persoane).

Personal Software Process (PSP)

TBD

Modelul use-case Model de arhitectur de sistem Diagrame de secven UML Model de clas UML Mode de date fizic
O metod agil ce se axeaz pe gestionarea proiectelor i gestionarea cerinelor. Deseori Proiecte de orice mrime Variaz, depinde de procesele de dezvoltare cu care se utlilizeaz Scrum.

Rational Unified Process (RUP)

Un proces de dezvoltare riguros, n patru faze ce este iterativ i incremental.

Echipe de proiect medii pn la mari (10 sau mai multe persoane).

Scrum

34

combinat cu XP. Team Software Process (TSP) TBD TBD TBD

O abordare evolutiv a dezvoltrii n care mai nti trebuie scris un test ce eueaz nainte de a scrie Test Driven noul cod funcional. Development (TDD) Cunoscut de asemenea ca programarea cu test iniial sau dezvoltarea cu test iniial.

Proiecte de orice mrime

Teste

Waterfall Modelul presupune (modelul cascad) c se pot nghea cerinele nainte de a ncepe crearea software-ului, sau o modificare foarte mic a cerinelor iniiale.

Proiecte mici i medii (4-20 persoane)

Teste

35

7. Modelul cu prototipuri Popescu Razvan


7.1 Notiuni generale Pentru sisteme noi, in mod special daca ele sunt mari si complexe este putin probabil sa se construiasca o specificatie completa, logica si valida inainte ca sistemul sa fie construit si utilizat. Acest fapt a condus la ideea prototiparii. Ideea este de a permite viitorilor utilizatori sa exerseze cu o prima versiune a sistemului, care poate fi obtinuta rapid prin tehnici de simulare si/sau de interpretare a specificatiilor. In acest ultim caz, limbajele logico-functionale sunt in mod sigur chemate sa joace un rol important. Prototipul este o schita a viitorului sistem: el nu are performantele si nu raspunde exigentelor de calitate ale unui produs finit. Prototipul ofera clientului functionalitati (nu in totalitate) ale viitorului sistem si interfata sa. El este dezvoltat intr-o maniera iterativa. Cerintele sunt extrase si validate iterativ prin utilizarea prototipului. In fiecare iteratie specificatia sistemului este modificata si detaliata pana cand prototipul satisface necesitatile utilizatorilor. Un prototip care este utilizat pentru a desprinde cerintele viitorilor utilizatori, este o "macheta exploratoare". Activitatea de prototipare poate interveni de asemenea in etapa de proiectare, pentru a experimenta si compara diferite variante. Astfel de prototipuri se numesc "machete experimentale".

Fig. 1. Schema modelului cu prototipuri Aceasta este o versiune ciclic a modelului liniar. Odat ce analiza cerinelor este ndeplinit i proiectarea este terminat, procesul de dezvoltare este pornit. Odat ce prototipul este creat, este dat consumatorului pentru evaluare. Consumatorul ofer feedback dezvoltatorului care rafineaz produsul conform cu ateptrile consumatorului. Dup un numr finit de iteraii, pachetul final este dat consumatorului. n aceast metodologie, software-ul evolueaz ca rezultat al schimbului periodic de informaii dintre consumator i dezvoltator. Acesta este modelul cel
36

mai popular din industria IT. Majoritatea produselor software de succes au fost create folosind acest model, ntruct este foarte dificil s nelegi toate cerinele utilizatorilor dintr-o singur ncercare. Exist multe variante ale modelului, din cauza diverselor stilurilor manageriale ale companiilor. Versiuni noi ale unui produs software apar ca rezultat al modelului cu prototipuri. n general prototipul simuleaz numai cteva aspecte ale atributelor programului final i poate fi complet diferit de implementarea final. Scopul convenional al unui prototip este de a permite utilizatorilor de software s evalueze propunerile dezvoltatorilor ncercndu-le practic i nu pe baza descrierilor. Utilizarea prototipurilor poate fi util i end user-ilor pentru a descrie cerine pe care dezvoltatorii nu le-au considerat, aadar controlarea prototipului poate fi un factor cheie n relaia comercial dintre dezvoltatori i clieni. Folosirea prototipurilor are o serie de beneficii: proiectantul soft i dezvoltatorul pot obine feedback de la utilizatori devreme n ciclul de via. Clientul i contractorul pot vedea dac produsul software respect cerinele pe care se construiete programul soft. De asemenea, ofer informaii inginerului soft legate de estimrile iniiale i de acurateea lor, acesta putnd determina dac se pot respecta deadline-urile. Pentru dezvoltarea prototipului se folosesc limbaje de nivel foarte inalt: Smalltalk, PROLOG, LISP, SETL si altele. In prezent exista limbaje si medii de dezvoltare specializate pentru construirea prototipurilor. Astfel de limbaje sunt limbajele de generatia a 4-a (4GL). Cu toate ca se poate folosi acelasi limbaj de programare, atat pentru realizarea prototipului cat si pentru dezvoltarea aplicatiei, se recomanda ca prototipul sa fie considerat un sistem "inchis", adica sa nu fie folosit ca baza pentru dezvoltarea aplicatiei. Aceasta deoarece: prototipul a fost dezvoltat prin modificari succesive, de aceea arhitectura sa initiala a fost alterata, ceea ce ingreuneaza intretinerea; prototipul trebuie sa corespunda cerintelor utilizatorilor numai din punct de vedere functional. De aceea, in dezvoltarea sa sunt neglijate aspecte ca: eficienta, adaptabilitatea, compatibilitatea si chiar fiabilitatea[1]. Exist dou mari categorii de utilizare a prototipurilor: Prototipuri cu aruncare Prototipuri evolutive 7.2 Prototipuri cu aruncare: Numite i prototipuri la captul apropiat. Prototipurile cu aruncare sau rapide se refer la crearea unui model care va fi pn la urm aruncat n loc s devin o parte integrat a softwareului final. Dup ce se termin adunarea cerinelor preliminare, un model funcional simplu al sistemului este construit pentru a arta vizual utilizatorilor cum arat cerinele lor aplicate ntr-un sistem finalizat. Prototipurile rapide implic crearea unui model al diferitelor pri ale sistemului ntr-o faz incipient, dup o investigaie relativ scurt. Metoda folosit la construirea modelului este de obicei informal, cel mai important factor fiind viteza cu care modelul este pus la dispoziie. Modelul devine apoi punctul de nceput de la care utilizatorii reexamineaz ateptrile i clarific cerinele. Apoi, modelul prototip este aruncat i sistemul este dezvoltat formal, bazat pe cerinele identificate. Motivul cel mai evident pentru folosirea acestei abordri este c poate fi ndeplinit repede. Dac utilizatorii primesc un feedback rapid al cerinelor lor, vor putea s le schimbe devreme n procesul dezvoltrii produsului.
37

Astfel de schimbri sunt foarte eficiente din punctul de vedere al costului din moment ce n momentul respectiv nu exist nimic de reluat. Dac un proiect este schimbat dup ce s-a efectuat o munc semnificativ, orice schimbare minor poate cauza eforturi mari pentru a fi implementat, din moment ce sistemele software pot avea dependene. Viteza este crucial n implementarea unui prototip de aruncat, deoarece cu un buget limitat de bani i timp se poate cheltui puin pe un prototip care nu va fi luat n considerare[1]. Un alt avantaj este abilitatea de a se construi interfee pe care utilizatorii le pot testa. Interfaa cu utilizatorul este ceea ce acesta vede ca fiind sistemul i vzndu-l n faa sa, i este mult mai uor s neleag cum va funciona. Prototipurile pot fi clasificai n funcie de gradul n care seamn cu adevratul produs ca aparen i interaciune. O metod de a crea un prototip de aruncat cu fidelitate redus este prototiparea pe hrtie. Prototipul este implementat cu creionul pe hrtie i mimeaz funcia adevratului produs, dar nu arat deloc ca acesta. O alt metod prin care se pot modela prototipuri de fidelitate crescut este de a folosi un GUI (Graphic User Interface) n care se creaz un prototip care arat ca produsul dorit dar nu are nicio funcionalitate[3]. Rezumatul acestui tip de prototipare este urmtorul: a) scrierea cerinelor preliminare; b) proiectarea prototipului; c) utilizatorul folosete prototipul i specific noile cerine; d) se repet paii b) i c) pn cnd cerinele nu se mai modific; e) scrierea cerinelor finale; f) dezvoltarea produselor reale; 7.3 Prototipuri evolutive: Prototiparea evolutiv este diferit de cea cu aruncare, ntruct scopul principal este de a construi un prototip foarte robust ntr-o manier structurat i de a-l rafina constant. Prototipul evolutiv, atunci cnd este construit va forma inima noul sistem. Cnd se dezvolt un sistem folosind aceast metod, acesta este constant rafinat i reconstruit. Tehnica permite echipei s adauge trsturi, sau s fac schimbri care nu ar fi putut fi concepute n faza de cerine i proiectare. Pentru ca un sistem s fie folositor, trebuie s evolueze prin folosire n mediul pentru care a fost proiectat. Un produs nu este niciodat terminat, el se maturizeaz constant pe msur ce mediul de operare se modific. Prototiparea evolutiv are avantajul c toate prototipurile sunt sisteme funcionale. Dei e posibil s nu aib toate funcionalitile pe care utilizatorii le-au dorit, ele pot fi folosite ca o baz intermediar pn la livrarea sistemului final[1]. Dezvoltatorii se pot concentra pe dezvoltarea prilor sistemului pe care le neleg, n loc s lucreze la dezvoltarea ntregului produs[2].

38

8. Modelul cu subproiecte Popescu Razvan


8.1 Notiuni generale Modelul cu subproiecte se bazeaza pe o idee foarte simpla: daca un sistem este prea complex pentru a fi inteles, conceput sau realizat intr-o singura faza este mai bine sa fie realizat in mai multe faze, prin evolutie.

Fig. 2. Modelul cu subproiecte Modelul cu subproiecte se aplica in felul urmator: 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.
39

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 sa fie 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 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 iteratie a ciclului de viata iterativ si incremental reproduce ciclul de viata in cascada la o scara mai mica. Obiectivele unei iteratii sunt stabilite pe baza evaluarii iteratiilor precedente. Documentatia este construita treptat, in timpul fiecarei iteratii. La sfarsitul dezvoltarii, documentele obtinute au aceeasi forma cu cele obtinute in maniera conventionala.

8.2 Avantaje si dezavantaje 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.
40

Ciclul de viata iterativ se bazeaza pe evolutia prototipurilor executabile, masurabile si deci pe evolutia elementelor concrete. El este opus din acest punct de vedere ciclului de viata in cascada care se bazeaza pe elaborarea de documente. Livrarile forteaza echipa sa dea rezultate concrete in mod regulat. Integrarea diferitelor componente ale programului este realizata intr-o maniera progresiva in timpul constructiei. Progresele se masoara prin programe demonstrabile mai degraba decat prin documente sau estimari, ca in ciclul de viata in cascada. In cursul dezvoltarii, clientul poate utiliza prototipurile. Demonstrarea prototipurilor prezinta numeroase avantaje: utilizatorul este pus in fata situatiilor de utilizare concrete care-i permit sa-si defineasca mai bine dorintele si sa le comunice echipei de dezvoltare; utilizatorul devine partener al proiectului; el isi ia partea de responsabilitate in noul sistem si de fapt il accepta mai usor; Dezavantaje: Ciclul de viata incremental se bazeaza pe evolutia prototipurilor executabile. Din nefericire, programele nu se preteaza in mod natural evolutiei, din contra, ele sunt deseori foarte "fragile" la modificari. Efectul unei modificari locale se poate propaga in ansamblul aplicatiei. Fiecare nou increment poate necesita reorganizarea structurii interne, degradand arhitectura initiala a programului, facandu-l greu de verificat si de intretinut. Erorile de proiectare sunt mai greu de eliminat. Abordarea obiect bazata pe modularitate si incapsulare conduce la programe mai robuste si mai rezistente fata de schimbari. Din acest punct de vedere, abordarea obiect furnizeaza un cadru confortabil pentru dezvoltarea prin evolutie, intr-o maniera iterativa. 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 ).

Principalul risc in utilizarea unui model incremental este de a lucra intr-o manierea "adhoc". 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 a cerintelor si constrangerilor mai importante, pt a construi un plan de dezvoltare. Se stabileste natura fiecarui increment si ordinea de construire a incrementelor[3]. O varianta a modelului este "Numai implementarea incrementala": Urmeaza modelul cascada pana in faza de implementare; In timpul analizei cerintelor si proiectarii de sistem: o Se definesc subseturi / subsisteme care pot fi livrate; o Se definesc interfete care permit adaugari iterative simple, cu un minim de modificari a arhitecturii existente;
41

o Diferitele parti sunt implementate, testate si livrate in functie de diferite prioritati si la diferite momente de timp 8.3 Exemplu Un exemplu de model cu subproiecte este modelul cascada cu subproiecte.

Fig. 3. Modelul cascada cu subproiecte Avantaje: Subsisteme independente din punct de vedere logic Fiecare subproiect poate continua in ritmul sau propriu Dezavantaje: Interdependente neprevazute Concluzii: Software-ul prototip, se refer la activitatea de creare de prototipuri ale aplicatiilor software, i anume, versiuni incomplete ale programului software n curs de dezvoltare. Este o activitate care poate s apar n dezvoltarea de software-uri i este comparabil cu prototipurile cunoscute din alte domenii, cum ar fi inginerie mecanic sau de fabricaie. Un prototip simuleaz de obicei doar cteva aspecte ale produsului final, i poate fi complet diferit de acesta. Prototiparea are cteva avantaje: designer-ul de software i implementatorul pot obine feedback valoros de la utilizatori la nceputul proiectului. Clientul i contractantul pot
42

evidenia dac software-ul se potrivete cu specificaiile dorite ale acestora, astfel programul software este construit. Modelul cu subproiecte al software-ului mparte funcionalitatea sistemului n trane (porii). Ideea de baz din spatele modelului cu subproiecte este de a dezvolta un sistem prin cicluri repetate (iterative), i n portii mai mici la un moment dat (incremental), permind dezvoltatorilor de software s profite de ceea ce s-a nvat n timpul dezvoltrii de versiuni anterioare ale sistemului. nvarea vine att din partea dezvoltrii ct i din partea utilizrii sistemului, n cazul n care msurile posibile din proces, ncep cu o punere n aplicare simpl a unui subset al software-ului i sporesc cerinele iterative ale versiunilor n evoluie pn cnd sistemul este implementat complet. La fiecare iteratie, modificrile de design sunt realizate i noi capabiliti funcionale sunt adugate.

43

9. Modelul in etape Lungu Mihail


9.1 Introducere O versiune software este o distribuie, public sau privat, a unei versiuni de produs software iniiale sau noi i mbuntite. De fiecare dat cnd un program sau un sistem sufer modificri, inginerii de software i companiile n lucru decid modul n care vor face distribuia programului su sistemului, sau schimbrile pe care le vor aduce acelui program sau sistem n timp. 9.2 Etapele distribuiei n ciclul de via Ciclu de via al distribuiei software este compus din diferite stagii care descriu stabilitatea unei componente de program i volumul de dezvoltare care este necesar nainte de lansarea produsului. Fiecare versiune major a unui produs de regul trece prin diferite stri pe msur ce noi caracteristici sunt adugate, sau prin stagiul alfa , cnd este activ depanat, sau beta, i n final un stagiu cu toate defectele eliminate numit i stagiu stabil. Stagiile intermediare pot fi recunoscute, sunt formal anunate n mod regulat de ctre dezvoltatorii de software, dar uneori aceti termeni sunt utilizai n scop informativ pentru descrierea strii produsului. Convenional, nume de cod sunt adesea utilizate de multe companii pentru versiuni prioritare n lansare produsului, dei actualele produse i caracteristici sunt rareori inute n secret. 9.3 Produsele pentru dezvoltare software comercial O alternativ care este uneori neglijat de entuziasmul datorat creerii unui nou sistem, este opiunea achiziiei de software universal. Produsele software universale rareori satisfac cerinele, dar sunt disponibile imediat i n timpul interveniei ntre momentul achiziionrii unui astfel de soft i lansarea propriului tu soft, utilizatorii vor avea cel puin cteva faciliti valoroase. Ei pot nva s lucreze n jurul limitrii produsului din moment ce beneficiaz de software particularizat i pe msur ce timpul trece, produsele software comerciale sunt revizuite i potrivite ndeaproape nevoilor . Aplicaiile software particularizate probabil nu se vor alinia viziunii mentale ale produsului software ideal, iar comparaiile ntre produsele software particularizate i cele universale tind s compare efectiv soft-ul universal cu idealul produs software particularizat. Cu toate acestea atunci cnd se proiecteaz un soft, trebuiesc fcute concesii de proiectare, cost sau programare i exist posibilitatea c produsul particular creat s ajung la nivelul ateptat.

44

9.4 Etapele de dezvoltare

Schema evoluiei unui produs software 9.4.1 Pre-alfa Este considerat o form incomplet a programului lansat iniial, nainte de emiterea variantelor alfa sau beta. Prin comparaie cu ultimile variante amintite, modelul pre-alfa nu conine toate caracteristicile i cnd este folosit se refer la toate activitile desfurate n timpul proiectului software nainte de testarea software. Aceste activiti pot include analiza cerinelor, proiectare software, dezvoltare de software i uniti de testare. n lumea Open Source, sunt cteva tipuri de versiuni pre-alfa. Versiunea Milestone include un set specific de funcionaliti i sunt lansate imediat ce acestea sunt completate. Nightly builds sunt acele versiuni care sunt de regul automat verificate de la sistemul de control al reviziei i construite, tipic peste noapte. Aceste versiuni permit celor ce le testeaz s verifice imediat funcionalitile recent implementate i s descoper noile probleme, defecte ale sistemului. 9.4.2 Alfa Realizarea variantei alfa a produsului software este forma nmnata celor ce se ocupa de testarea soft, care sunt persoane diferite de inginerii de software, dar uzual fac parte din organizaia sau comunitatea de dezvoltatori de software. Ocuparea rapid a poziiei softului pe piaa duce uneori la angajarea de ctre companiile dezvoltatoare a mai multor clieni externi sau parteneri valoroi pentru efectuarea testrilor alfa i acesta este considerat o extindere n faza de testare a produselor de tip alfa. n prima faz de testare, general dezvoltatorii testeaz produsul folosind o tehnic a cutiei-albe.
45

Validrile adiionale sunt apoi efectuate folosind tehnica cutiei-negre sau cea a cutiei-gri, de o alt echip de testare dedicat sistemului, uneori simultan. Trecerea la testarea cutiei-negre n interiorul organizaiei este cunoscut c lansarea alfa. 9.4.3 Beta O versiune Beta este prima variant lansat n afara organizaiei sau comunitii dezvoltatoare de software, cu scopul evalurii sau testrii cutiei-negre, gri de ctre lumea real. Procesul de livrare a versiunii beta ctre ali utilizatori poart numele de distribuie beta. Nivelul software beta n general conine toate caracteristicile, dar poate conine i elemente nedorite sau simple erori ntr-un mod variabil mai puin grav. Utilizatorii unei versiuni beta sunt numii testri beta i adesea sunt clieni obinuii sau poteniali clieni ai organizaiei care dezvolt software. Ei primesc software-ul gratuit sau la un pre redus, dar acioneaz ca testri liberi. Versiunile beta testeaz suportul produsului, mesajul introducerii pe pia ( n timpul recrutrii clienilor beta ), fabricaia produsului i fluxul de canal global i canal atins. Versiunile de software beta sunt cel mai probabil necesare demonstraiilor interne i selectrii clienilor, dar nestabile i nepregtite pentru lansarea definitiv. Unii dezvoltatori se refer la aceast etap ca o previzualizare, un prototip, sau o previzualizare tehnic sau ca un acces timpuriu. De multe ori aceste stagii beta iau natere cnd dezvoltatorii anuna o stagnare a unor caracteristici ale produsului, indicnd imposibilitatea acceptrii unor cerine caracteristice pentru versiunea produsului i numai problemele de soft , bug-urile sau facilitile neimplementate pot fi adresate. Dezvoltatorii lanseaz fie un beta nchis, fie un beta deschis, prima fiind o versiune dedicat unui grup select de utilizatori de test, n timp ce versiuna a doua se adreseaz unei comuniti mari de utilizatori, de obicei publicul larg. Testrii furnizeaz orice eroare ntlnita i uneori mici caracteristici pe care le-ar dori implementate n varianta final. Cnd o variant beta devine disponibil publicului general este adesea larg utilizat de tehnologii savvy i de cei familiarizai cu versiunile anterioare ca i cnd ar fi produsul finit. Dezvoltatorii uzuali ai variantelor gratuite sau open-source beta, le lanseaz publicului larg n timp ce proprietarii de beta se ndreapt ctre un grup restrns de testri. Beneficiarii de versiunile beta originale trebuie s semneze un contract de nedivulgare. O lansare poate fi numit caracteristica completa cnd echipa produsului este de acord cu cerinele funcionale ale sistemului i nicio ulteriora facilitate nu va fi inclus n distribuie, dar erori signifiante vor continua s existe. Companiile cu un proces software formal vor tinde s ptrund n perioada beta mpreuna cu o list de bug-uri care trebuie s fie fixate pentru prsirea perioadei beta, i unele companii pun aceste liste la dispoziia clienilor i testrilor. Internetul a permis distribuia de software ntr-un mod rapid i necostisitor, iar companiile au adoptat tehnici flexibile de abordare n vederea utilizrii sensului cuvntului beta. Cei de la Netscape Communications au lansat o versiune alfa a browserului cu aceeai denumire i au numit-o beta, n ideea pstrrii unui statut adecvat. n februarie 2005 , ZDNet a publicat un articol despre un fenomen recent al versiunilor beta adesea prelungite pe perioade de ani de zile i folosite ca fcnd parte din nivelul de producie, exemplul celor de la G-mail sau
46

Google care au fost sub forma beta o lung perioad de timp i nu au renunat la acest aspect lund n considerare utilizarea larg, dar n cele din urm Google a prsit aceast variant prin ianuarie 2006. Aceast tehnic permite unui dezvoltator s ntrzie oferind suport total i/sau responsabilitate pentru problemele rmase i uneori versiunea beta este considerat o variant final a produsului. 9.4.4 Originile variantelor alfa i beta Termenul de beta test aplicat softurilor provine de la un test fcut produselor hardware IBM convenie datnd din perioada cardurilor perforate i mainilor de sortat. Componentele hardware treceau iniial prin testul alfa pentru funcionalitatea preliminar i etapa de fezabilitate a fabricaiei, apoi urm testul beta care verifica dac funciile au fost realizate corect i dac sunt produse la o dimensiune necesar n comer i se ncheia cu un test C pentru fiabilitatea produsului. Odat cu apariia computerelor programabile i primele programe partajabile, IBM a continuat cu aceeai terminologie pentru testarea produselor software. Testele beta erau conduse de oameni sau grupuri altele dect dezvoltatorii, i cum alte companii au nceput crearea de software pentru propriile utilizri i distribuii ctre alii, evoluia terminologiei a stagnat i s-a pstrat pn n prezent. 9.4.5 Seigo Stagiul Seigo este un nivel al evoluiei software cnd librriile necesare produsului sunt finalizate (sau aproape gata) dar restul produsului necesita lustruire i finisare. Stagiul intervine ntre varianta beta i varianta final a dezvoltrii soft deoarece produsul este nc nepregtit pentru a intra n faza final de livrare, chiar dac librriile sunt de calitate. Termenul provine dup o controversata discuie pe tema linux n The Linux Action Show !, evenimentul lansrii celei de-a dou versiuni finale a KDE 4 neridicndu-se la standardul unei variante release candidate, discuie purtat pe Skype ntre 2 prezentatori i Aaron Seigo. 9.5 Release Candidate i Gold Termenul de release candidate se refer la o versiune cu potenial de produs final, gata s fie lansat chiar dac se ivesc erori. n acesta etap, produsul prezint n mod normal codul complet. Corporaia Microsoft adesea folosete termenul de release candidate ( distribuia final). n timpul anilor 1990, Apple Inc. a utilizat termenul de maestru de aur pentru distribuiile finale i maestrul de aur final reprezentnd distribuia general disponibil. Ali termeni includ gamma (i ocazional delta, sau alte litere greceti) pentru versiunile care sunt substanial complete, dar aflate nc sub test, i omega pentru testarea final a versiunilor care sunt considerate a fi bug-free, i pot intra n producie oricnd. O distribuie este numit cod complet cnd echipa de dezvoltare este de acord c nicio surs intern de cod nou nu va fi adugat acestei distribuii, nsa pot exista modificri de coduri pentru a nltura defecte i chiar schimbri de documentaie i fiiere de date, i de asemenea coduri pentru cazurile test sau alte utiliti.

47

Distribuia Gold sau distribuia general disponibil Versiunile gold lansate sau cele generale sunt formele finale a unui produs particular. Este tipic aproape identic cu distribuia final, cu bug-uri fixate n ultimul minut. O distribuie Gold este considerat foarte stabil i relativ un bug-free cu o calitate corespunztoare pentru distribuii largi i folosit de utilizatori finali. n distribuiile comerciale de software, aceast versiune poate fi semnat ( folosit s permit utilizatorilor finali posibilitatea verificrii codului ce nu a fost modificat de la lansare). Expresia ca un produs software a trecut de aur nseamn c partea de cod este complet i va fi produs n numr mare i valabil curnd pentru vnzare. Termenul de aur, anectodic se refer la utilizarea discului master de aur care a fost folosit n mod obinuit n trimiterea variantelor finale productorilor care l folosesc s creeze copii de vnzare n mas. n unele cazuri acest disc este realizat chiar din aur, att pentru estetic ct i rezistena la coroziune.[5] 9.6 RTM sau RTW Microsoft i alii folosesc termenul de distribuie final RTM (release to manufacturing) pentru a se referi la aceste versiuni( pentru produse comerciale ca Windows XP , ca n Build 2600 cu distribuia RTM Windows XP), i distribuii Web- RTW pentru produse gratuite descarcabile. Tipic, RTM reprezint sptmnile i lunile nainte de GA( disponibilitatea general) deoarece versiunea RTM trebuie stampilata pe disc. 9.7 Versiuni stabile/nestabile n programarea open source, numerele de versiuni sau termenii Stabil i Nestabil disting stagiile de dezvoltare. Termenul de stabil se refer la o versiune a unui software care este substanial identic cu o versiune care a trecut suficient printr o testare de ctre lumea-reala pentru asigurarea corectitudinii softului, sau acele mici probleme existente sunt cunoscute i detaliate. Pe de alt parte termenul nestabil, nu nseamn neaprat c exist probleme, mai degrab, acele mbuntiri sau schimbri efectuate produselor software care nu au fost riguros testate. Utilizatorii unui astfel de software sunt sftuii s foloseasc versiunile stabile dac vor s-i ating interesele dorite, i s utilizeze varianta instabil cnd apariia unor probleme nu ar afecta ntreg programul. n kernelul Linuxului, numerele de versiuni sunt compuse din 3 numere, separate de o perioad.ntre versiunile 1.0.0 .i 2.6.x, distribuiile stabile au al doilea numr par i cele instabile au unul impar. Practica utilizrii numerelor impare, pare pentru a indica stabilitatea distribuiei a fost utilizat de alte proiecte open/closed source .

48

Exemplificarea versiunilor lansate n perioada unui ciclu de viata software

49

9.8 Concluzii n concluzie, dezvoltarea cu succes a software-ului comercial pot fi realizat ntr-un mod coerent. Elementele necesare pentru a atinge succesul sunt experiena n management, un mediu care ofer o bun gestionare de control i rspuns, precum procedurile de gestionare executorii i standardele de control pentru meninerea proiectului. Aceste elemente sunt eseniale pentru realizarea de succes pe termen lung operaional i economic n dezvoltarea sistemelor de software fie ntr-un mediu militar sau comercial.

50

10.Modelul cu software commercial Lungu Mihail


10.1 Notiuni introductive Putem deduce faptul ca un set de pai este oferit mpreun cu cerinele i tehnicile pentru implementarea i meninerea controlului proiectului. n mod special, o msurare cantitativ a calitii software-ului comercial este propus pe baza valorii funcionale, disponibilitii i costurilor de ntreinere. Concluziile trase sunt bazate pe studiul diferitelor cazuri i sunt aplicabile att n sistemul militar ct i comercial. Rezultatele acestui studiu din acest fiier ar trebuie s fie aplicabile pentru majoritatea marilor proiecte de dezvoltare de software. Fie ca sistemul este dezvoltat ntr-un mediu competitiv de un comerciant care dorete s obin un profit(sau pe baza unui contract) , cu scopul de a mbunti performanele. 10.2 Msurarea mrimii proiectului i a dificultii nivelului Definirea managementului ciclului de via al sistemului este ntr-o mare msur dependenta de mediul luat n considerare. Aceasta este n mod special adevrat cnd evaluam metode de administrare a dezvoltrii software-ului, ntruct scopul problemelor ntlnite este dependent de variaia considerabil. De exemplu, urmtorii factori pot solicita cereri radicale legate de abordri de management: 1) numrul de instalaii separate geografic s fie meninut; 2) numrul diferitelor tipuri de utilizatori s interacioneze n cadrul sistemului; 3) nivelul automatizrii impementat anterior n cadrul aplicaiei; 4) cerinele disponibilitii sistemului; 5) nivelul de complexitate al sistemului; Majoritatea factorilor pe care managerul proiectului trebuie s le ia n considerare sunt de fapt subfactori a dou elemente majore care sunt critice. Acestea sunt calitatea produsului final i riscul eecul proiectului. Ca i pe alte piee, calitatea produsului i profiturile merg mana n mn. Calitatea produsului final depinde de disponibilitatea funciilor sistemului cerute de utilizator i de costul aferent meninerii disponibilitii. n mod normal, dezvoltatorul va lua msuri pentru a previziona i a controla calitatea de la nceputul ciclului de via al sistemului. Totui, n practic, msurarea final a calitii nu poate fi determinat pn cnd sistemul se afla n minile utilizatorilor reali n mai multe medii de operare. Riscul este de obicei definit de riscul de a nu obine profit s de a obine economii. Pentru sistemele din domeniul militar poate s fie vorba de riscul de a nu obine un nivel de performan adecvat. n ambele cazuri grija noastr este s minimizm riscul sau s l meninem la un nivel acceptabil . n riscul de msurare, trebuie s considerm procentajul de reurse care vor fi date n consum de organizaie pentru a aduce produsul n punctul de a fi profitabil. n plus, timpul pentru a obine profit, rata rentabilitii i probabilitatea de a fi n concordan cu programul avnd n vedere timpul i resursele alocate sunt factori pe care i lum n considerare pentru evaluarea riscului. Este
51

de datoria proiectantului s determine cnd riscul i calitatea sunt la nivele acceptabile i s evalueze dac organizaia trebuie s continue cu proiectul . n sistemul commercial investigat, comercianii de software nu au anticipat venituri profitabile pn cnd mai multe instalaii au funcionat cum trebuie n operaiuni live. n mod special, un sistem nu a fost profitabil pn cnd a 5-a instalare nu a fost produs. 10.3 Performanele legate de software-ul commercial Performanta comerciantului i managementul proiectului sau au fost evident msurabil de-a lungul ciclului de via al sistemului. Memoria corporativ despre cum au fost fcute estimrile asupra timpului i costurilor este bine conservat pentru a reduce viitoare riscuri. ntr-un mediu ce cuprinde mai multe instalri , cerinele legate de rezisten i mentenabilitate sunt de foarte mare importan. Dac numrul instalaiilor i costurile atribuite acestora cresc, cerinele de rezisten i mentenabilitate amplifica nevoia de calitate a design-ului. Adugm la acestea o cerin competitiv de satisfacere a utilizatorilor cu garania i rezultatul este un mediu care cere o calitate superioar a produselor i un control riguros de management.[1] Acesta este mediul investigat :

10.4 Definirea problemei controlului ciclului de via a software-ului commercial Pentru nceput, considerm un mod ideal de a descrie problema controlului ciclului de via , cum se poate vedea n Fig. 1. Presupunnd c capacitatea operaional poate fi msurat n acelai sens cu reursele utilizate astfel nct o micare (dolari i ceni) a performantei ROI s fie atins. O astfel de msur poate fi determinat precis n cazul unui comerciant de software care vinde un produs ambalat. Aceasta msurtoare este de asemenea valida pentru proiecte unde economiile pot fi uor de determinat. n cazul capacitilor operaiunilor militare , se pare c exist o mic ndoial legat de faputl c metodele i concluziile trase sunt direct aplicabile, ns evaluarea lor poate fi mai subiectiv.
52

Curbele din Fig.1 reprezint o soluie general la problema controlului ciclului de via. Soluia este una general ntruct pentru o problem de software dat, pot exista un infinit de curbe de soluionare. Forma lor va depinde de judecata managerului de proiect i a multor altor factori legai de ciclul de via. Obiectivul problemei tehnice este s conturm aceste curbe n aa fel nct s maximizm ROI. Exist multe constrngeri externe pe care un manager de proiect trebuie s le aib n vedere. n primul rnd, trebuie s determine care este perioada de timp necesar proiectului. n primul rnd, trebuie s determine perioada n care exista cerere pe pia a produsului. Cu alte cuvinte, trebuie s determine perioada n care veniturile pentru sistem vor crete . Trebuie s ia n considerare schimbrile din mediu, de tehnologie, i concurena. n cazul militar, aceasta corespunde cu perioada n care exista o capacitate operaional antecedenta unei nvingeri a unei ameninri. Dac exist deja o pia pentru sitemul n cauz, atunci IOC ( capacitatea iniial operaional) va depinde numai de timpul de dezvotare pentru atingerea scopului. Totui, perioada total pentru obinerea veniturilor este influenat de IOC i de uzur moral a sistemului (SOB). Evident, dac sunt cheltuii mai muli bani pentru a scurta timpul pentru IOC, veniturile vor aprea mai devreme. Cu toate acestea, un manager de proiect experimentat este contient c de fapt o accelerare a ritmului de produce va duce la costuri mai mari. Alte constrngeri financiare care trebuie luate n considerare sunt consumul maxim de resurse (MRC) i punctul de mprire egala (BEP). MRC are loc cnd veniturile i economiile depesc costurile prezente. Trebuie s existe destule resurse disponibile la rata cerut pentru a acoperi acelea utilizate pentru MRC. BEP are loc cnd costurile totale au fost acoperite din venituri sau economii. Profitul comerciantului nu poate fi definit n acest punct, exceptnd capitalizarea pe termen lung a costurilor superioare?. Dac un comerciant ntmpina mult timp BEP-ul acestea se va gndi n ce alte proiecte i poate nveti resursele. n concluzie, problema controlului ciclului de via este redus la una din curbele din Fig.1 , care ne arat maximizarea ROI constrnsa de factori cum ar fi calitatea, riscul, MRC, timpul pn la IOC i BEP.

53

10.5 Determinarea calitii software-ului comercial Calitatea software-ului trebuie s fie msurat n funcie de timp ntr-un mediu operaional. nainte de timp, calitatea software-ului poate fi previzionata i controlat de factori care o afecteaz. Totui, msurarea calitii oferite aici este considerat esenial n corelarea efetcelor acestor factori :

Vom ncepe cu noiunea intuitiv ca Qcalitatea este proporional pentru disponibilitatea sistemului A i invers proporional cu costurile de ntreinere disponibilitii valabile M3. Q= Costul pentru a menine un sistem este direct msurabil n mediile luate n considerare. Pentru a defini disponibilitatea aa cum este folosit n (1), am defini n primul rnd factorul fi care descrie importana relativ a tuturor funciilor sistemului astfel judecate de ctre utilizator. Aceti factori pot fi normalizai, astfel nct:

unde n este numrul de funcii care trebuie s fie la dispoziia utilizatorului. Noi definim li c nivelul de disponibilitate a funciei i, astfel nct : n cazul n care li este unul singur (zero), atunci sistemul este total disponibil, i nivelurile pot lua valori binare sau continue. Dac toate funciile sistemului sunt disponibile n totalitate, atunci

Acesta este ghidul de care trebuie s defineasc importana relativ a funciilor sistemului, precum i nivelul lor de disponibilitate la orice moment n timp. Referindu-ne la Fig. 2, considerm c vom lua msurtori succesive peste intervale de timp de lungime TF . O cretere practic poate fi o lun. n timpul acestor intervale vom msura continuu nivelul de disponibilitate al fiecrei funcii de sistem. Presupunem c toate funciile sunt complet disponibile cu excepia cazului n care se stabilete c
54

nivelul lor de disponibilitate scade sub o unitate. De exemplu, n Fig. 2, la timpul TKD, nivelul de disponibilitate a funciei i scade la o valoare mai mic de 1. La momentul TKU, problema este corectat i funcia este n totalitate la dispoziia utilizatorului. Pentru a facilita definirea disponibilitii medii pe intervalul (t0, tf), definim indisponibilitate ca: ui=1-li Msurile de calitate oferite nu sunt destinate s fie absolute. Deficienele lor, cum ar fi interdependenele dintre funcii, pot fi depite printr-o hotrre bun n determinarea nivelului de disponibilitate. Dac un jurnal este inut individual , ca valori de disponibilitate funcionale se poate calcula un nou set de factori de calitate la schimbarea ponderile relative ale funciei. Cu toate acestea, importana msurilor revine dup interpretarea lor. Reinei c disponibilitatea poate fi mbuntita prin scurtarea timpului necesar pentru a aduce o reducere nivelului de disponibilitate napoi la unitate. Cu toate acestea, astfel de eforturi pot crete costul de ntreinere i a potenialului, prin urmare, diferena mbuntiri n msura general a calitii. n mediul comercial furnizorul i potenialii cumprtori a unui sistem software vor dori s vorbeasc cu utilizatorii existeni cu privire la disponibilitatea funciilor sistemului dorit. Acest lucru reprezint calitatea produsului, cum este vzute de utilizator. Cu toate acestea, este doar o parte din imagine ca vzut de ctre un dezvoltator,de meninerea unui sistem de garanie. Din punctul de vedere al dezvoltatorului, el trebuie s ia n considerare costurile de ntreinere n determinarea ROI. Pentru a fi un produs de nalt calitate, sistemul de software din punct de vedere comercial trebuie s fie de asemenea ieftin. n scopul de a construi un produs de nalt calitate, astfel cum este definit mai sus, dezvoltator trebuie s investeasc mai mult timp i bani n timpul de dezvoltare, nainte de a IOC. Este lsat la managerul de proiect s determine un nivel adecvat de disponibilitate, sub care riscul de a pierde veniturile din economii anticipate s nu devin prea mare.[2] Managementul de proiect spune c un nivel acceptabil de calitate v depinde cu siguran mult mai mult pe nevoile utilizatorilor i de capacitatea de concuren. Cu toate acestea, un dezvoltator de software prudent nu va ignora astfel de msuri, deoarece, n calitate de utilizatori devin mai sofisticate.

55

10.6 Msurarea succesului ntr-un mediu commercial, competitive Avnd definit problema teoretic, considerm acum c managerul de proiect poate obine soluii practice. ntrebrile pe care le punem sunt: -Care sunt controalele care definesc curbele? -Cum putem previziona reaciile lor? -Cum putem valida previziunile ntr-un mediu n continu schimbare? Abordam aceste ntrebri prin compararea dezvoltatorilor de software dintr-un mediu comercial. (Fig. 3) . nainte de a ne axa pe cazuri specifice putem trage nite concluzii din observaiile fcute: 1.anumii dezvoltatori de software au fost mai de succes dect alii ; 2.exista o viziune comun c riscul poate fi redus printr-o evoluie mai lent, dac managementul este lipsit de experien. 3. rata de abrupt de utilizare a resurselor de ctre dezvoltator 1 necesit o cunoatere a modului de utilizare n mod eficient acestor resurse- cu alte cuvinte, experiena n management. 4. este important s nelegem cum i n cazul n care software-ul se nscrie n ciclul de via al sistemelor totale i n ce msur software-ul de gestionare a ciclului de via influeneaz sistemul de management total. n Introducere, s indicat c software-ul este diferit de la hardware-ul. Probabil cea mai important diferena este forma curbei de utilizare a resurselor la nivelul ciclului de via. Fig. 4 indic consumul de resurse n ntreagul ciclu de via pentru un sistem tipic hardware comercial. Reinem c maximu; este atins dac CIO este favorabil. Atunci cnd software-ul consum o mai mare parte a resurselor de sistem ale ciclului de via, este necesar pentru a obine nelegerea de top management i de aprobare anticipat de vrf de utilizare a resurselor. Dac acest lucru nu se face, i la fel IOC este ncercat s fie ndeplinit, c CIO va fi prematur. acesta duce la o capacitate operaional fictiv n care utilizatorul este condus s cread c o capacitate operaional real exist, atunci cnd n defapt nu. [3]

n plus fa de funcia de consumul de resurse fiind diferit de cea de hardware, software-ul ciclului de via comercial are un set diferit de repere naturale intrinseci. Cu excepia cazului n care acestea sunt mapate n mod corespunztor n ciclul total de via al sistemului, atunci o parte
56

din software-ul sistemului nu va fi controlat n mod corespunztor. Se pare c setul de componente ale sistemului ciclului de via n etape, activiti i evenimente n cadrul comecial nu necesit schimbare prea mare n ceea ce privete numele i realizarea general pentru a putea fi utilizat pentru software. Ceea ce ei au nevoie sunt interpretarea adecvat i un set diferit de msurare specific criterilor pentru realizarea lor. Aceast cerin pentru repere de management specifice software-ului comercial este foarte important s fie recunoscut.[4]

57

11.Modelul cu medii de dezvoltare Guta Ovidiu


11.1 Notiuni generale In acest subcapitol, vom trata problema mediilor de dezvoltare folosite pe parcursul ciclului de dezvoltare si de viata al unui produs software. Vom prezenta modul in care se aleg mediile de dezvoltare folosite si vom da cateva exemple subliniind caracteristicile lor. Atunci cand se lucreaza la un produs software, inevitabil, va trebuii sa dispunem de un proces de proiectare si implementare a aplicatiilor. Este un proces important si stresant in dezvoltarea software-ului deoarece poate afecta date importante, timpul de viata, si poate accentua erori in procesul de dezvoltare al produsului. Exista mai multe moduri de a structura procesul de implementa aplicatii software si cea mai mare parte din acest proces este dependent de gradul de importanta al aplicatiei dezvoltate. Voi incerca sa explic pe ce etape din ciclul de viata al dezvoltarii sa se bazeze medile de dezvoltare independent de metodologia si modelul ciclului de viata al software-ului ales. 11.2 Medii de dezvoltare in trei faze Vom incepe cu cea mai simpla, dar in acelas timp completa, configuratie a mediilor de dezvoltare.

58

Development Aceasta caseta reprezinta cel mai nou si cel mai complex ( desi instabil) cod, pe care programatorii il implementeaza sau il corecteaza la momentul curent. Acesta nu este mediul de dezvoltare local/client pe care programatorii implementeaza codul (ca de exemplu Visual Studio); ci este o caseta de sine statatoare care contine codul dezvoltat pana la un anumit grad. Poate avea asociata o baza de date care poate fi locala sau poate sta pe un mediu virtual de mentinere si verificare a versiunii surselor. Deseori, pregramatorii care lucreaza pe mediul de dezvoltare local, pot comunica direct cu aceasta baza de date si pot modifica direct codul sursa, dar alte ori, ei lucreaza doar local urmand sa modifice baza de date doar la anumine milestoneuri. Staging Aceasta caseta contine cod la nivelul de productie, care trebuie testat sau care doar trebuie aprobat pentru intrarea in productie. Mediul de dezvoltare in etape trebuie sa fie o replica fidela a mediului de productie in ceea ce priveste atributele fizice si software-ul aditional instalat pe server. Folosind medii de dezvoltare in trei etape, serverul pentru dezvoltarea in etape (staging) are de asemenea rolul de mediu pentru asigurarea calitaii (QA) si pentru acceptarea de catre utilizator (UAT). Odata ce toate testele sunt rulate si trecute iar utilizatorul si-a dat acceptul, codul poate fi trecut in urmatoarea etapa, si anume cea de testare a procedurii de livrare. Aceasta procedura va fi repetata in momentul livrarii efective a produsului. Production Aceasta caseta reprezinta sistemul real pe care utilizatorii il folosesc. Mediul de dezvoltare din productie este in totdeauna cel mai vechi si cel mai stabil medi. Modificari in cod, incluzand rezolvarea erorilor si patch-uri, trebuie facute doar dupa ce au fost trecute prin toate celelalte etape si au fost testate de de echipa de de programatori direct pe mediul de dezvoltare pe care vor rula. In cele mai multe cazuri, incluzand dezvoltarea Agile, mediu de dezvoltare de productie nu ar trebuii sa fie in continua schimbare datorita instabilitatii pe care o cauzeaza aces lucru. 11.3 Avantaje si dezavantaje Avantaje: Exista mai multe avantaje ale dezvoltarii cu medii in trei faze. In primul rand, sunt relativ simple in complexitate si destul de ieftine fata de alte modele, totodata oferind beneficiile modelului de ciclu de viata al produsului folosit. Avand un numar limitat de medii insemana mentenanta redusa a terminalelor si serverelor, costuri mai mici de licentiere si mai putine responsabilitati de a face backup-uri. Dezavantaje: Desigur, exista compromisuri. In medii mai mari, in care exista o echipa dedicata de QA care realizeaza testarea automata a codului se pot suprasolicita procesorul sau banda retelei, ceea ce poate afecta performanta mediului. In plus, cele mai multe pachete software de QA au nevoie de program aditionale instalate in caseta, ceea ce contrazice regula ca mediile de Staging si de Production sa fie identice.

59

11.4 Sisteme Distribuite Configurarea de medii de dezvoltare bazate pe cicluri de viate pentru sisteme distribuite este similar cu mediile de dezvoltare in trei faze, doar ca la o scara mult mai mare. In loc de trei casete, putem avea cate o caseta pentru fiecare strat din arhitectura produsului final (ca de exemplu accesul la date, logica de lucru cu datele, interfata etc). In acest caz, mediile de dezvoltare trebuie sa contina mai multe casete organizate stratificat.

11.5 Exemple de medii de dezvoltare In continuare, vom prezenta cateva din mediile de dezvoltare folosite in controlul versiuni surselor si in lucrul in echipa al programatorilor. 1. SVN Apache Subversion (cunoscut n trecut sub numele de Subversion[1]) este un sistem de revision control fondat i sponsorizat n anul 2000 de firma ColabNet Inc. Este folosit pentru meninerea versiunilor curente i istorice ale fiierelor cod surs, paginilor web i a documentaiei n proiectele software. A fost creat ca un nlocuitor modern al sistemului Concurrent Versions System (CVS). Subversion, sau pe scurt svn, este unul din principalele sisteme revision control folosite n dezvoltarea software liber. Este folosit de proiecte sau organizaii precum Apache Software Foundation, Free Pascal, FreeBSD, GCC, Django, Ruby, Mono, SourceForge, ExtJS, Tigris.org, PHP, Python i MediaWiki. Google Code ofer de asemenea hosting subversion.
60

Subversion este folosit pe larg i n dezvoltarea de software proprietar. Conform unui raport din 2007 al organizaiei Forrester Research, Subversion este leaderul absolut al categoriei Standalone Software Configuration Management (SCM) i unul leaderii categoriei Software Configuration i Change Management (SCCM).[2] Subversion este publicat sub licena Apache i este considerat software liber. Faciliti Operaiile commit sunt atomice. Fiierele terse/redenumite/mutate i pstreaz istoria. Versioning pentru directoare. Versioning pentru symbolic links. Suport nativ pentru fiiere binare, bazat pe stocarea diferenelor. Pe post de network server este folosit Apache HTTP Server, WebDAV/Delta-V este folosit pe post de protocol. Definete de asemenea i un protocol propriu construit n stiva TCP/IP folosit cu ajutorul serverului svnserve. Protocolul transmite ntotdeauna numai diferenele, minimiznd traficul de reea. Operaiile de branching i tagging sunt optimizate s consume foarte puin memorie. Design client-server, o bibliotec este disponibil pentru dezvoltarea clienilor, language bindings pentru C#, PHP, Python, Perl, i Java. Baz de date FSFS (foarte rapid pe directoare cu multe fiiere[6]) sau Berkeley DB. 2. Microsoft Visual SourceSafe Microsoft Visual SourceSafe (VSS) este un sistem de control al surselor orientat catre proiecte mici de dezvoltare de software. Ca si alte sistem de control al versiunii surselor, VSS creaza o biblioteca virtuala de fisiere. Chiar daca este folosit in special pentru fisiere de cod sursa, SourceSafe poate sa stocheze orice tip de fier fara a garanta insa functionare in conditiile in care se confrunta cu cantitati mari de fisiere non-text. VSS suporta dezvoltarea cross-platform permitant editarea in colaborare a surselor si impartirea datelor. Este proiectat sa se ocupe de problemele de control si portabilitate pentru a mentine o baza sigura de surse, ca de exemplu codul sursa al unei aplicatii care ruleaza pe mai multe sisteme de operare. Sistemul ofera urmatoarele facilitati: Protejeaza echipa de programatori impotriva pierderii de fisiere Permite intoarcerea la versiuni anterioare ale unui fisier Suporta stratificarea, inpartire, alipirea si managementul fisierelor adaugate Mentine baze de date cu versiuni ale proiectelor intregi si terminate Tine evidenta fisierelor folosite in mai multe proiecte ca module atasate

61

12.Concluzii Laza Laura


Stadiile procesului de dezvoltare a software-ului sunt cunoscute ca faze ale ciclului de viata software. Ciclul de via al unui produs software este o structur impus n procesul de dezvoltare al unui produs software. Exist mai multe modele de astfel de procese, iar fiecare abordare descrie o varietate de sarcini sau activiti care au loc n timpul procesului. Un model de ciclu de via software descrie etapele semnificative sau activitile unui proiect software de la concepie pn cnd produsul respectiv este retras. Acesta specific relaiile dintre etapele proiectului, inclusiv criteriile de tranziie, mecanismele de feedback, milestoneuri, liniile de baz, recenzii, i rezultatele. De obicei, un model de ciclu de via adreseaz fazele unui proiect software: etapa cerinelor, proiectarea, implementarea, integrarea, testarea, mentenana. O mare parte din motivaia folosirii unui model de ciclu de via este de a oferi structura pentru a evita problemele de genul hacker indisciplinat sau birocrat IT (care este de zece ori mai periculos dect un hacker indisciplinat). Au fost prezentate 10 modele ale ciclului de viata al unui produs software, fiecare cu avantaje si dezavantaje.

62

Bibliografie
Laza Laura: [1]Software Maintenance As Part of the Software Life Cycle - Prof. Stafford [2]Boehm, Barry W., A Spiral Model of Software Development and Enhancement, IEEE Computer, May 1988 Sorensen, Reed, A Comparison of Software Development Methodologies, Crosstalk, 1995 Maciaszek Practical Software Engineering, 2005 Laura Carnevali, Lorenzo Ridi, Enrico Vicario: Putting Preemptive Time Petri Nets to Work in a V-Model SW Life Cycle IEEE Computer Society, IEEE Trans. Software Engineering, VOL. 37, NO. 6, NOVEMBER/DECEMBER 2011 Basili, V. R., and A. J. Turner, Iterative Enhancement: A Practical Technique for Software Development, IEEE Trans. Software Engineering, 1,4, 390-396, 1975

Stefanescu Yasmin:
http://www.pdt.enea.it/doconline/documents/EN-DP-93-003.pdf http://userweb.port.ac.uk/~lesterk/sepmp/notes/N03a-LifeCys.html http://en.wikipedia.org/wiki/Waterfall_model http://www.computerworld.com/s/article/71151/System_Development_Life_Cycle?taxonomyI d=11&pageNumber=2 http://www.freetutes.com/systemanalysis/sa2-waterfall-software-life-cycle.html http://www.freetutes.com/systemanalysis/sa2-advantages-limitations-waterfall-model.html http://cs.njit.edu/~ryon/CIS490/Acrobat/490-03.pdf http://codebetter.com/raymondlewallen/2005/07/13/software-development-life-cycle-models/ http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=59 http://www.coleyconsulting.co.uk/waterfall-model.htm http://en.wikipedia.org/wiki/Software_development_process www.nada.kth.se/~karlm/prutt05/lectures/prutt05_lec6.ppt http://www.stsc.hill.af.mil/resources/tech_docs/gsam4/chap2.pdf Department of Computer Science,Tufts University,Software Maintenance As Part of the Software Life Cycle,Comp180: Software Engineering,Prof. Stafford,Prepared by:Kagan Erdil,Emily Finn,Kevin Keating,Jay Meattle,Sunyoung Park,Deborah Yoon,December 16, 2003 http://www.designingprojectmanagement.com/SoftwareProcessModels.html http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=752905 http://www.agiledata.org/essays/differentStrategies.html http://www.business-esolutions.com/islm.htm http://www.softwaretestingnow.com/software-development-life-cycle

Lungu Mihail:
http://users.csc.calpoly.edu/~jdalbey/205/Mgmt/SDP. http://www.onestoptesting.com/release-life-cycle/ http://www.perforce.com/perforce/papers/life.html 63

http://support.motioneng.com/Software-MPI_04_00/basics/releases/sw_life_cycle.htm http://en.wikipedia.org/wiki/Commercial_software [1]P. V. Norden, "Useful tools for project management," in Management ofProduction, M. K. Starr, Ed. Baltimore, MD: Penguin, 1970, pp. 71-101. [2]P. V. Norden, "Useful tools for project management," in Management ofProduction, M. K. Starr, Ed. Baltimore, MD: Penguin, 1970, pp. 71-101. [3]L. H. Putnam, "A macro-estimating methodology for software development," in Dig. Papers, Fall COMPCON '76, Thirteenth IEEE Computer Soc. Int. Conf., Sept. 1976, pp. 138-143. [4]A. L. Sherr, "Developing and testing a large programming system," in Program Test Methods, W. C. Hetzel, Ed. Englewood Cliffs, NJ: Prentice-Hall, 1972. [5]T. R. Snyder, "Rate charting," Datamation, pp.44-47, Nov. 1976.

Popescu Razvan: [1] - www.ieee.org - ieeexplore.ieee.org ("Knowledge-based software life cycle and architectures", Computer Science and Technology Research Survey; Knowledge in software life cycle) [2] - www.wikipedia.org [3] - www.softpanorama.org

64