laza stefanescu guta popescu lungu 443a ciclus

95
UNIVERSITATEA POLITEHNICA BUCURESTI Facultatea de Electronica, Telecomunicatii si Tehnologia Informatiei PROIECT I.S. CICLURI DE VIATA ALE PRODUSELOR SOFTWARE Studenti: Profesor indrumator: Laza Laura Prof. Dr. Ing. Ştefan Stăncescu Stefanescu Yasmin Guta Ovidiu Popescu Razvan Lungu Mihail

Upload: popa-gabriel

Post on 21-Jan-2016

35 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

UNIVERSITATEA POLITEHNICA BUCURESTIFacultatea de Electronica, Telecomunicatii si Tehnologia Informatiei

PROIECT I.S.

CICLURI DE VIATA ALE PRODUSELOR SOFTWARE

Studenti: Profesor indrumator:Laza Laura Prof. Dr. Ing. Ştefan StăncescuStefanescu YasminGuta OvidiuPopescu RazvanLungu Mihail

GRUPA 443A

UPB2012

Page 2: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

Sumar

1. Introducere – Laza Laura1.1 Ciclul de viata ca intreg1.2 Dezvoltarea clasica a programelor

2. Modelul cascada – Stefanescu Yasmin2.1 Notiuni generale2.2 Argumente2.3 Modele modificate2.4 Rezultatul proiectului în modelul cascadă2.5 Avantajele modelului de ciclu de viaţă cascadă2.6 Limitări ale modelului de ciclu de viaţă cascadă2.7 Etape2.8 Aplicaţii

3. Modelul in “V” – Laza Laura3.1 Obiective3.2 Schema modelului in “V”3.3 Fazele modelului in ‘V’3.4 Avantaje si dezavantaje

4. Modelul spirala – Laza Laura4.1 Notiuni generale4.2 Schema modelului spirala4.3 Descrierea modelului spirala4.4 Avantaje si dezavantaje4.5 Aplicatii

5. Modelul incremental – Guta Ovidiu5.1 Cum se aplica5.2 Avantaje si dezavantaje5.3 Planificarea5.4 Rational Unified Process

6. Modelul code-and-fix – Stefanescu Yasmin6.1 Notiuni generale6.2 Avantaje si dezavantaje6.3 Fazele modelului code-and-fix6.4 Limitări ale modelului de ciclu de viaţă code and fix6.5 Compararea metodelor de dezvoltare software

7. Modelul cu prototipuri – Popescu Razvan7.1 Notiuni generale7.2 Prototipuri cu aruncare7.3 Prototipuri evolutive

2

Page 3: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

8. Modelul cu subproiecte – Popescu Razvan8.1 Notiuni generale 8.2 Avantaje si dezavantaje8.3 Exemplu

9. Modelul in etape – Lungu Mihail9.1 Introducere9.2 Etapele distribuţiei în ciclul de viaţă9.3 Produsele pentru dezvoltare software comercial9.4 Etapele de dezvoltare9.4.1 Pre-alfa9.4.2 Alfa9.4.3 Beta9.4.4 Originile variantelor alfa şi beta9.4.5 Seigo9.5 Release Candidate şi Gold9.6 RTM sau RTW9.7 Versiuni stabile/nestabile9.8 Concluzii

10. Modelul cu software commercial – Lungu Mihail10.1 Notiuni introductive10.2 Măsurarea mărimii proiectului şi a dificultăţii nivelului 10.3 Performanţele legate de software-ul commercial10.4 Definirea problemei controlului ciclului de viaţă a software-ului commercial10.5 Determinarea calităţii software-ului comercial10.6 Măsurarea succesului într-un mediu commercial, competitive

11. Modelul cu medii de dezvoltare – Guta Ovidiu11.1 Notiuni generale11.2 Medii de dezvoltare in trei faze11.3 Avantaje si dezavantaje11.4 Sisteme Distribuite11.5 Exemple de medii de dezvoltare

12. Concluzii – Laza Laura13. Bibliografie

3

Page 4: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

1. Introducere – Laza Laura

Conceptul fundamental al ingineriei software îl constituie ciclul de viata.

1.1 Ciclul de viata ca întregCiclul 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 putând 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 încontextul î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 decât autorul programului sa studieze programul si documentatia aferenta pâna când 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 decât 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, considerându-se (si nu fara temei) ca este mai usor sa se dezvolte de la zero un sistem nou, decât 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 când 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.

4

Page 5: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

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.

AnalizaAceasta 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 decât 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 stapânit; prinproiectarea 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 atât pentru implementarea sistemului, cât si pentru modificarea sa ulterioara. Acesta este unul dintre principalele motive pentru careparadigma orientata spre obiecte câstiga teren: un sistem proiectat orientat spre obiecte este prin definitie un sistem modular.

ImplementareaAceasta faza se refera la scrierea efectiva a programelor, crearea fisierelor de date

si dezvoltarea bazelor de date.

TestareaAceasta faza este strâns 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, utilizându-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]

5

Page 6: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

2. Modelul cascada – Stefanescu Yasmin

Analiza ciclului de viaţă (LCA, Life Cycle Assessment) este o metodă de a evalua aspectele de mediu şi impacturile potenţiale 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ă, distribuţie, utilizare şi menţinere, reutilizare, reciclare şi înlăturarea finală). Datele de ciclu de viaţă pot fi de asemenea foarte folositoare pentru informaţiile aduse utilizatorilor finali, astfel că impactul asupra mediului în faza de utilizare este redus, şi pentru gestionarea sfărşitului vieţii unui produs (de exemplu identificarea materialelor cu potenţial 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 până la ultimele sale utilizări. Modelul tinde să fie mai complex pentru software decât pentru alte tipuri de produse şi are un număr de diferenţe majore – de exemplu, fazele de producţie ale majorităţii produselor presupun realizarea unui număr 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 generaleModelul de viaţă cascadă este un proces secvenţial de creare, utilizat deseori în

dezvoltarea proceselor software în care progresul este considerat ca o cădere continuă (ca o cascadă) prin fazele de Concepere, Iniţializare, Analiză, Creare, Construcţie, Testare, Producţie/Implementare şi Menţinere.

6

Page 7: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

Concepere

Iniţializare

Analiză

Creare

Construcţie

Testare

Producţie

Menţinere

Modelul cascadă nemodificat. Progresul „curge” din vârf spre capăt, ca o cascadă.

Dezvoltarea modelului cascadă îşi are originea în industriile de manufactură şi construcţii: medii fizice foarte structurate în care schimbările 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 evidenţia 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, deşi Royce nu a folosit termenul „cascadă” în articolul său. Royce a prezentat modelul ca un exemplu de model nefuncţional, cu greşeli. 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 ArgumenteTimpul petrecut la început în ciclul de producţie software poate duce la economii mari în

stadiile ulterioare. McConnell arată faptul că o eroare găsită în stadiile de început (cum ar fi specificarea necesităţilor sau design/creare) este mai economică din punct de vedere al fondurilor, efortului şi timpului de reparare decât aceeaşi eroare găsită utlerior în proces. De

7

Page 8: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

exemplu, dacă un concept de program se dovedeşte imposibil de implementat, este mai uşor de reparat conceptul la stadiul de creare decât să se realizeze acest lucru câteva luni mai târziu, când 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ă necesităţile şi conceptul sunt corecte economiseşte mult mai mult timp şi efort ulterios. Astfel, gândirea celor ce urmează procesul în cascadă se asigură că acest stadiu este 100% complet şi complet corect înainte de a trece la următorul stadiu. Necesităţile de program ar trebui bine conturate înainte de a începe procesul de creare, altfel munca depusă pentru un concept ce se bazează pe necesităţi incorecte este pierdută. Designul programului ar trebui să fie perfect înaintea începerii implementării, altfel implementarea produsului greşit duce la muncă pierdută.

Un argument în plus pentru modelul în cascadă este acela că pune accentul pe documentaţie (cum ar fi documentele din care reies necesităţile şi documentele de design), la fel ca şi codul sursă. În metodologiile mai puţin documentate, dacă membrii echipei părăsesc echipa, multe dintre cunoştinţe se pierd şi poate fi dificilă continuarea proiectului. Dacă există o documentaţie completă, membrii noi ai echipei pot să se familiarizeze cu proiectul prin citirea documentaţiei.

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, uşor de înţeles şi uşor explicabile şi astfel este uşor de înţeles; 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. Mulţi 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 următoare şi de a învăţa din ele. De exemplu, clienţii ar putea să nu ştie cu exactitate necesităţile ce apar înainte de a examina un prototip funcţional şi să comenteze pe baza lui. Ar putea schimba cerinţele imediat. Creatorii şi programatorii pot avea puţin control asupra acestui lucru. Dacă clienţii schimbă cerinţele lor după ce design-ul este finisat, design-ul trebuie să fie modificat pentru a acomoda noile cerinţe. 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 conştienţi de dificultăţile viitoare de implementare atunci când realizează un design pentru un produs software neimplementat. Cu alte cuvinte, poate deveni clar în faza de implementare că o anumită zonă a funcţionalităţii programului este extrem de greu de implementat. În acest caz, este mai bună revizuirea design-ului decât a se persista în ccrearea unui design bazat pe predicţii greşite, şi acest lucru nu ia în considerare problemele nou descoperite.

Chiar şi fără asemnea schimbare a specificaţiei în timpul implementării, există opţiunea fie de a începe un nou proiect de la zero, fie să se continue cel deja existent. Metodologia

8

Page 9: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

cascadă poate fi utilizată pentur o îmbunătăţire continuă, chiar şi pentru software existent, creat de o altă echipă. La fel ca şi în cazul în care un analist de sistem nu reuşeşte să capteze necesităţile clientului în mod corect, impacturile rezultate asupra fazelor următoare (î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 cărei cerinţe şi limitări nu pot fi cunoscute complet înainte de a fi terminată. Implicarea acesteia este că este imposibil să se perfecţioneze o fază a dezvoltării software, deci este imposibil dacă se utilizează modelul cascadă să se treacă la următoarea 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 învăţăm invalidează design-ul nostru şi trebuie să mergem înapoi.”

Extinzând conceptul de deasupra, părţile interesate (personal non-IT) pot să nu fie pe deplin conştienţi de capacităţile tehnologiei ce este implementată. Acest lucru poate duce la ceea ce ei “cred că este posibil”, definind cerinţe şi necesităţi. Acest lucru piate duce la un design ce nu utilizează potenţialul complet a ceea ce poate face noua tehnologie, sau să copieze pur şi simplu aplicaţia existentă sau procesul cu noua tehnologie. Acest lucru poate cauza schimbări substanţiale în cerinţele de implementare odată ce părţile interesate devin mai conştiente de funcţionalităţile disponibile ale noii tehnologii. Un exemplu este acela în care o organizaţie trece de la procese bazate pe hârtie la procese electronice. În timp ce livrabilele cheie ale procesului pe hârtie trebuie să fie menţinute, beneficiile validării datelor în timp real, urmărirea şi deciziile automate pot fi să nu fie anticipate în fazele de început ale proiectului.

Datorită tipurilor de critici aduse, unele organizaţii, cum ar fi Departamentul de Apărare (DoD) a SUA au acum o preferinţă împotriva metodelor de tip cascadă, începând cu MIL-STD-498.

Standardul curent DoD 5000.2, lansat în 2000, susţine o preferinţă clară împotriva cascadei: “Există două abordări, cascadă evoluţionistă şi cu pas unic, pentru o capacitate completă. O abordare evoluţionistă este preferată, deoarece capabilitatea finală asigurată utilizatorului este împărţită în două sau mai multe blocuri, cu incremente în creştere ale capabilităţii. Dezvoltarea software va utiliza un proces de dezvoltare de tip spirală iterativă în care versiunile software ce se extind continuu se bazează pe învăţarea din dezvoltarea iniţială.

2.3 Modele modificateCa răspuns la problemele întâlnite 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 planificare a ciclului de viaţă în cartea sa, “Dezvoltarea rapidă: Îmblânzirea programelor software sălbatice”.Etapele modelului cascadă pot fi caracterizate în diverse moduri, inclusiv în modul următor:

9

Page 10: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

Planificarea proiectului, studii de fezabilitate: Stabileşte o vedere de nivel înalt al proiectului dorit şi îi determină ţelurile.

Analiza sistemului, definirea cerinţelor: Rafinează ţintele proiectului în funcţii definite şi operaţii ale aplicării dorite. Analizează informaţiile despre necesităţile utilizatorilor finali.

Crearea sistemului: Descrie caracteristicile dorite şi operaţiile în detaliu, inclusiv reguli de afaceri, diagrame ale proceselor, pseudocod şi alte documentaţii.

Implementarea: Codul real este scris aici. Integrare şi testare: Aduce toate piesele laolaltă într-un mediu special de testare, apoi

verifică existenţa erorilor şi interoperabilitatea. Acceptarea, instalarea, dezvoltarea: Stadiul final al dezvoltării iniţiale, în care

software-ul este pus în producţie. Întreţinerea: Ceea ce se petrece în timpul restului vieţii software-ului: schimbări,

corecţii, adăugări, mişcări la diferite platforme de computare şi altele. Această etapă se repetă de nenumărate ori.

Modelul cascadă este bine înţeles, dar nu este la fel de util precum era înainte. El presupune că singurul rol al utilizatorilor este în specificarea cerinţelor, şi că toate cerinţele pot fi specificate în avans. Din păcate, necesităţile sunt în creştere şi se schimbă în timpul procesului şi mai târziu, fiind nevoie de feedback considerabil şi consultare iterativă.

Modelul presupune că fazele sunt organizate ăntr-o ordine liniară. Un proiect ăncepe cu analiza dezabilităţii. După demonstrarea cu succes a fezabilităţii, analiza necesităţilor şi proiectarea proiectelor începe.

Crearea începe după ce se termină analiza necesităţilor. Codarea începe după realizarea design-ului. Odată ce programarea se termină, codul este integrat şi testat. La completarea cu succes a testării, sistemul este instalat. După aceasta are loc operarea regulată şi întreţinerea. Cu modelul cascadă, activităţile realizate în proiectul de dezvoltare a software-ului sunt analiza necesităţilor, planificarea proiectelor, design-ul sistemului, design-ul detaliat, codarea şi testarea unităţilor, integrarea sistemului şi testarea. Ordonarea liniară a activităţilor are anumite consecinţe importante. În primul rând, pentru a identifica în mod clar finalul unei etape şi începului alteia. Unele mecanisme de certificare trebuie să fie folosite la finalul fiecărei faze.acest lucru este de obicei realizat prin anumite verificări şi validări. Validarea presupune confirmarea că rezultatul unei etape se potriveşte cu începutul său (care este rezultatul etapei anterioare) şi că rezultatul etapei se potriveşte cu necesităţile totale ale sistemului.

Consecinţele necesităţii de certificare sunt că fiecare fază trebuie să aibă un rezultat definit ce poate fi evaluat şi certificat. Astfel, atunci când activităţile 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 este acela de a justifica programul final împreună cu utilizarea documentaţiei cu documentul de necesităţi, documentul de design, planul de proiect, planul de testare şi rezultatele testării.

10

Page 11: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

O altă implicare a ordonării liniare de etape este aceea că după ce fiecare etapă este completată şi rezultatele sale sunt certificate, aceste rezultate devin date de intrare pentru următoarea etapă şi nu trebuie schimbate sau modificate. Totuşi, nu se poate evita schimbarea necesităţilor şi trebuie acţionat corespunzător. Schimbările efectuate asupra rezultatului unei etape afectează etapele ulterioare. Aceste schimbări trebuie făcute într-un mod controlat după evaluarea efectului fiecărei schimbări asupra proiectului.

Rezultatele certificate ale unei faze ce este lansată este numită o bază. Gestionarea configurării asigură că orice schimbări ale unei baze sunt realizate după o evaluare atentă, deoarece interesele tuturor părţilor 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 puţin decât reuşit.

2.4 Rezultatul proiectului în modelul cascadă

Setul de documente ce formează minimul ce ar trebui produs în fiecare proiect sunt: Document de cerinţe 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 excepţia ultimului, acestea sunt rezultatele etapelor. Pentru a certifica un rezultat al unui produs al unei etape înaintea începerii următoarei etape, se realizează deseori evaluări. Evaluările sunt necesare în special pentru etapele de realizarea cerinţelor şi a designului, din moment ce alte mijloace de certificare deseori nu sunt disponibile. Evaluările sunt întâlniri formale pentru a descoperi deficienţele într-un produs. Rapoartele de evaluare sunt rezultatul acestor evaluări.

2.5 Avantajele modelului de ciclu de viaţă cascadă

Uşor de explicat utilizatorilor.

11

Page 12: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

Etapele şi activităţile sunt bine definite. Este utilă planificarea şi programarea proiectului. Verificarea în fiecare etapă asigură detecţia timpurie a erorilor/neînţelegerilor. Uşor de manevrat datorită rigidităţii modelului. Etapele sunt procesate şi completate pe rând. Funcţionează bine pentru proiectele mai mici unde necesităţile sunt foarte bine înţelese

sau pentru automatizarea unor sisteme deja existente.

2.6 Limitări ale modelului de ciclu de viaţă cascadă

Ajustarea scopului ăn timpul ciclului de viaţă poate omorî un proiect. Nu se introduce software funcţional până spre finalul ciclului de viaţă. Cantităţi mari de risc şi nesiguranţă. Model slab pentru proiectele complexe şi obiect-orientate. Model slab pentru proiectele lungi şi continue. Model slab acolo unde necesităţile au un risc moderat spre ridicat de a se schimba.

Modelul cascadă presupune că toate cerinţele unui sistem pot fi îngheţate î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 cerinţelor este dificilă, din moment ce nici chiar utilizatorul nu ştie cerinţele. Astfel, a avea cerinţe ce nu se schimbă (sau se schimbp doar puţin) este nerealistă pentru un asemenea proiect.

Îngheţarea cerinţelor necesită deseori alegerea hardware-ului (din moment ce formează o parte a specificaţiilor necesităţilor). Un proiect mare ar putea dura câţiva ani până 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 atât de costisitor.Modelul cascadă stipulează faptul că cerinţele ar trebui specificate complet înainte ca restul dezvoltării să poată începe. În anumite situaţii ar putea fi de dorit ca mai întâi să se dezvolte o parte a sistemului complet, iar apoi să se îmbunătăţească sistemul. Acest lucru este deseori efectuat pentru produsele software ce sunt realizate nu neapărat pentru un client (unde clientul joacă un rol important în specificarea cerinţelor), dar pentru piaţa generală, în care cerinţele sunt determinate cel mai probabil de către dezvoltatori.

2.7 EtapeSe poate considera un model cascadă cu 7 etape ce se includ în cele patru ale unui model

SDLC (Software Development Life Cycle):

12

Page 13: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

Situaţia de afaceri

Cerinţele utilizatorilor

Specificaţiile sistemului

Design-ul sistemului

Design-ul componentelor

Construcţia compoenentelor

Testare

Decizie

Design

Dezvoltare

Demonstrare

1. Faza de decizie

Faza de decizie a unui SDLC este atunci când se decide ce se doreşte săs e implementeze ca software. În această fază sunt 3 etape:

Faza de Decizie

Faza de Decizie a unui SDLC este atunci când se decide ce se doreşte a se implementa ca software. În această fază sunt 3 etape:

Situaţia de afaceri – ceea ce utilizatorul doreşte să obţină de la software. Cerinţele utilizatorilor - ceea ce software-ul trebuie să facă pentru afacere. Specificaţiile sistemului – ceea ce software-ul trebuie să realizeze în termeni de

computare pentru a îndeplini cerinţele clienţilor.

Situaţia de afaceriAceasta este justificarea pentru a construi sistemul software şi trebuie să acopere un

număr de domenii, incluzând: Care este situaţia curentă a afacerii şi software-ului. Care este oportunitatea de afaceri pe care software-ul o va rezolva. Care sunt diversele strategii de soluţii şi fezabilitatea lor. Care este strategia de soluţie preferată. Care este relaţia costuri - beneficii. Care sunt presupunerile, riscurile şi constrângerile posibile.

13

Page 14: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

Care este abordarea de implementare în linii mari.

O cantitate considerabilă de muncă trebuie să fie realizată de către utilizatori cu date de intrare oferite de dezvoltatori pentru a produce o situaţie de afaceri. Beneficiile realizării acestui lucru sunt oferirea tuturor din proiect a unei hărţi clare a locului în care se îndreaptă utilizatorii şi de ce.

Cerinţele utilizatorilorUrmătoarea etapă este aceea de a defini un set de cerinţe ale utilizatorilor. Acestea

definesc pentru strategia preferată de soluţii ceea ce sistemul software trebuie să obţină pentru a împlini oportunitatea de afaceri. Domeniile ce trebuie incluse sunt:

Cerinţe funcţionale – ce trebuie să realizeze sistemul, de exemplu pentru a păstra detalii ale arhivelor utilizatorilor.

Cerinţe non-funcţionale – sunt două tipuri:o Constrângeri de performanţe – ce performanţă este necesară din partea sistemului, de

exemplu dacă va aduce la zi arhivele clienţior peste noapte.o Contrângeri de dezvoltare – ce restricţii asupra dezvoltării 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.

Specificaţiile sistemuluiSpecificaţiile sistemului au loc atunci când 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. Interfeţe externe – ceea ce este necesar pentru sistem pentru a comunica în afară,

inclusiv:o Interfeţe tranzacţionale – ceea ce este necesar pentru a comunica cu utilizatorii (cum

ar fi monitoare).o Interfeţe de raport – ce tipuri de rapoarte sunt necesare.o Interfeţe de aplicaţii – ce conexiuni sunt necesare pentru alte sisteme software.

Cerinţe non-funcţionale – care sunt constrângerile asupra sistemului.

Suprapunerea stadiilorCaracteristica distinctivă a tuturor celor trei etape în Decizie este faptul că se ocupă de

ceea ce se doreşte. Totuşi, graniţele dintre ele se pot suprapune.Utilizatorul dezvoltă atât situaţia de afaceri cât şi cerinţele 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 măcar într-un loc.Graniţa dintre Cerinţele utilizatorilor şi Specificaţiile sistemului poate avea o mare suprapunere, în special din moment ce ambele au ca scop informarea dezvoltatorilor. Diferenţele cheie dintre cele două sunt:

Cerinţele utilizatorilor sunt scrise de către utilizatori asistaţi de dezvoltatori, în timp ce Specificaţiile sistemului sunt scrise de dezvoltatori asistaţi de utilizatori.

14

Page 15: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

Cerinţele utilizatorilor exprimă funcţionalitatea necesară în termeni de ceea ce afacerea doreşte să obţină, în timp ce Specificaţiile sistemului exprimă funcţionalitatea în termeni de ceea ce sistemele software ar putea realiza.

Faza de DesignFaza de Design are loc atunci când diverse cerinţe 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 Specificaţiile sistemului şi creează arhitectura sistemului. Acest lucru este realizat prin definirea unei serii de componente împreună cu ceea ce realizează şi cum interacţionează cu alte componente. Aceste componente pot fi alte sisteme, interfeţe, module de cod, ecrane, baze de date etc. ceea ce nu este definit este detaliul cu privire la modul în care va funcţiona fiecare componentă.

Design-ul componentelor

Etapa de design al componentelor este design-ul detaliat a modului în care o anumită componentă va funcţiona, şi cum comunică rezultatele sale către alte componente prin interfeţe. 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 către cei ce codează.

Faza de dezvoltareFaza de dezvoltare este etapa de Construcţie a componentei în modelul cascadă. Ea se ocupă cu construcţia componentelor necesare pentru software. Componentele software vin în multe forme şi variază de la software realizat pe comandă dezvoltat în mod special pentru sistem, până la pachetul software ce este configurat pentru a satisface cerinţele.Există două principale tipuri de pachete software:

COTS (Commercial Off The Shelf) – Acestea sunt pachete de aplicaţii ce acoperă nevoi variate ale utilizatorilor ce sunt aduse şi configurate de funrizori comerciali.

Open Source – Acestea sunt pachete variate de aplicaţii dar sunt întreţinute de o comunitate de utilizatori.

Software-ul realizat pe comandă va putea îndeplini necesităţile exacte, dar este costisitoare producţia sa. În teorie, există economii de preţ utilizând pachete software. În teorie, deoarece costurile de instalare pot fi mai mici, dar costul rulării pachetului pe parcursul vieţii sale poate fi mai mare.

Faza de demonstrare

15

Page 16: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

Faza de demonstrare este etapa de test şi implică faptul că sistemul software îndeplineşte toate etapele de design, specificaţii şi cerinţe din fazele de Decizie şi Design.

ObservaţiiAceste şapte etape realizează modelul cascadă aşa cum este utilizat în mod tradiţional, dar flexibilitatea în modul în care este utilizat afectează cît de succes va avea. Există un număr de probleme cu modelul cascadă, de aceea a evoluat în modelul în V.

2.8 AplicaţiiModelul cascadă poate fi utilizat cu succes atunci când necesităţile sunt bine înţelese de la început şi nu se aşteaptă să se schimbe sau evolueze pe parcursul vieţii proiectului. Riscurile proiectului ar trebui să fie relativ joase.

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

16

Page 17: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

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”:

3.3 Fazele modelului in ‘V’

♦Fazele de verificare

17

Page 18: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

Analiza cerintelorIn 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 sistemuluiProiectarea 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 arhitecturiiFaza 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 modululuiFaza 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 unitaraIn 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 integrataIn 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

18

Page 19: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

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 utilizatoruluiTestarea 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 lansariiTestarea 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.

4. Modelul spirala – Laza Laura

4.1 Notiuni generaleModelul 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

19

Page 20: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

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 spiralaEvolutia 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.

Cadranul 1Activitatile 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.

20

Page 21: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

- 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 2Activitatile 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 3Daca 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 4Modelul 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 dezavantajeAvantaje

- 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.

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

21

Page 22: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

- 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.

5. Modelul incremental – Guta Ovidiu

Modelul ciclului de viata "Incremental" este opus modelului « in cascada ».

22

Page 23: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

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

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.

23

Page 24: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

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

Page 25: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

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

Page 26: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

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

Page 27: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

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: riscDiferite 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

Page 28: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

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

Page 29: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

6. Modelul code-and-fix – Stefanescu Yasmin

6.1 Notiuni generale

Dezvoltarea “code and fix” nu este atât o strategie deliberată cât este un artefact de naivitate şi presiune datorată programului dezvoltatorilor software. Fără a fi un mare design, programatorii încep imediat să producă codul. Într-un anumit punct, testarea începe (deseori mai târziu î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 până când un produs este “finalizat” (sau când fondurile sau timpul disponibil se termină). Munca se realizează într-o ordine aleatoare.

6.2 Avantaje si dezavantajeAvantaje:

Nu există surplus administrativ. Apar semne de progres (cod) zilnic. Expertiză puţină. 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ă. Greşelile sunt greu de detectat/corectat. Imposibil pentru proiectele mari, posibila întrerupere a comunicaţiei, haos.

6.3 Fazele modelului code-and-fixModelul 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 îmubătăţiri viitoare. Acest model este încă utilizat deoarece, în aplicaţiile din viaţa 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 cerinţelor este urmat de codare. Problemele privind specificaţiile 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ă, până când clientul este mulţumit. Modelul code and fix probabil că este cea mai frecvent utilizată metodă de dezvoltare în ingineria software. Începe cu puţină sau chiar fără planificare. Se începe imediat dezvoltarea, reparând problemele pe măsră ce apar, până când proiectul este complet.Code and fix este o alegere tentantă atunci când se are de-a face cu un program strâns pentru dezvoltare datorat începerii dezvoltării imediat şi dorinţa de a vedea rapid rezultatele.Din păcate, problemele arhitecturale majore apar mai târziu în timpul procesului. De obicei este necesară rescrierea unei mari părţi din aplicaţie. Modelele de dezvoltare alternativă pot ajuta găsirea problemelor în etapele timpurii ale conceptului, atunci când schimbările sunt mai uşoare şi mai puţin costisitoare.

29

Page 30: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

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 puţine, sau deseori fără, planuri. Problemele sunt întâmpinate şi defectele sunt fixate pe măsură ce apar.Deşi acest proces permite dezvoltării să aibă loc rapid, proiectul va întâmpina întârzieri serioase dacă se găsesc probleme arhitecturale majore. Problemele arhitecturale majore, în special acelea descoperite târziu în proces, vor necesita o rescriere a unei mari părţi 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 aplicaţiei.

Includerea managementului în procesul de dezvoltare software; multe întârzieri 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 obţinut.

După lansarea produsului, trebuie realizată o întâlnire a echipei de producţie pentru a discuta ce a funcţionat corect şi ce a funcţionat greşit.

6.4 Limitări ale modelului de ciclu de viaţă code and fix

Această abordare poate să funcţioneze bine pentru sistemele mici, dar este foarte nesatisfăcător pentru sistemele mai mari. Pe măsură ce mărimea codului creşte, înţelegerea şi manipularea sistemului descreşte.Puncte tari:

Nu se pierde timp pentru planificare, documentaţie, asigurarea calităţii, aplicarea standardelor sau alte activităţi ce nu implică codarea.

Este necesară puţină experienţă.Puncte slabe:

Periculos. Nu există mijloace de a evalua calitatea sau de a identifica riscurile. Greşelile fundamentale în abordare nu apar rapid, deseori fiind necesară muncă multă

pentru a scăpa 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

Page 31: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

6.5 Compararea metodelor de dezvoltare software.

Metodă Descriere Când se utilizează Artefacte primare de modelare

Agile Data (AD)

O metodă parţial agilă ce se axează pe tehnici ce suportă dezvoltarea evolutivă (iterativă şi incrementală) a bazelor de date.

Se ajustează filozofiile şi tehnicile AD în alte procese evolutive.

Modele Agile data

Agile Model Driven Development (AMDD)

O metodă parţială, bazată pe practică, ce descrie tehnici pentru modelarea şi documentarea eficientă a sistemelor.

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

Se aplică artefactul potrivit pentru situaţia 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 când se doreşte ceva între XP şi tradiţionalul RUP, un proces ce este agil dar include explicit activităţi şi artefacte cu care utilizatorii sunt acomodaţi, 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 neexperimentaţi sau nepricepuţi, în care ei pur şi simplu scriu

Pentru prototipuri ce nu au o durat mare de viaţă.

Codul sursă

31

Page 32: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

codul fără să implice multă gândire. Denumită de asemenea “hacking” sau “dezvoltare imatură”.

Data-Driven Approach

Aceasta este o categorie generică de metode bazate pe date, populare în anii 1970 şi 1980 cu descoperirea metodelor structurate. Aceastp abordare este în mod tipic riguroasă şi serială.

Dezvoltarea unui depozit de date, deşi o abordare centrată pe utilizare este de preferat.

Dezvoltarea unei simple aplicaţii de afaceri de tip CRUD (Create Read Update Delete).

Model de date conceptual

Model de date logic

Arhitectură de dezvoltare

Model fizic de date

Dynamic System Development Method (DSDM)

Aceasta este o metodă agilă ce a primit certificare ISO 9001. în multe moduri, este o formalizare a metodelor RAD (Rapid Application Development) din anii 1980.

Dezvoltarea unui sistem intensiv de interfaţă cu utilizatorul.

Aplicaţie complexă de afaceri.

Prototip funcţional

Prototip de design

Enterprise Unified Process (EUP)

Un proces software riguros, în şapte etape, ce include dezvoltarea, operarea şi retragerea sistemelor bazate pe software. eforturile de dezvoltare sunt iterative şi incrementale. Include o vedere de multisistem ce include activităţile de arhitectură de întreprindere, de management al

Nevoia de a gestiona un portofoliu de proiecte, incluzând dar nu limitată la echipe folosind RUP.

Atunci când au avut succes mai multe proiecte RUP şi se doreşte 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

Page 33: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

reutilizării, de management al portofoliului şi de management al persoanelor.

Extreme Programming (XP)

O metodă de dezvoltare agilă ce se axează pe activităţile critice necesare pentru a construi software-ul.

Echipe de proiect mici, co-localizate (4-10 persoane).

Cerinţele sunt nesigure.

O relaţie potenţial bună există cu părţile interesate ale proiectului.

Strategie arhitecturală

Carduri CRC (Class responsibility collaborator).

Feature-Driven Development (FDD)

O metodă de dezvoltare agilă bazată pe iteraţii scurte ce includ activităţile de modelare explicită.

Echipă mică de proiect (4-20 persoane).

Cerinţele sunt nesigure.

Echipa este dispusă să urmărească o abordare condusă de modelare.

Model de domeniu clasă/obiect

Caracteristici

Diagrame de secvenţă UML

Model de clasă UML

Glacial Methodology

TBD TBD TBD

ICONIX

O metodă simplă, condusă de modelare ce poate fi instanţiată ca o îmbunătăţire a RUP sau pe măsură ce o metodă agilă este de sine stătătoare.

Echipe de proiecte mici până la medii (4 până la 20 de persoane).

Dezvoltare de aplicaţii de afaceri.

Modelul use-case

Diagrame de robusteţe

Diagrame de secvenţă UML

Model de clasă UMLISO/IEC 12207 Un proces software

cu faze multiple ce includ dezvoltarea, operarea şi retragerea sistemelor bazate pe software.

Echipe de proiect medii până la mari (20 sau mai multe persoane)

Mandatat (de exemplu de guvern)

Model logic de date

Model logic de procese

Model fizic de date

33

Page 34: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

să urmeze această abordare.

Model fizic de procese

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

TBD TBD TBD

Object Oriented Software Process (OOSP)

Un CMM riguros de nivel 5 (atunci când este instantizat complet), proces a cărui axare este pe dezvoltare, operaţii, suport şi întreţinere a sistemelor utilizând tehnologii obiect-orientate şi/sau bazate pe componente.

Echipe de proiect medii până la mari (10 sau mai multe persoane).

Modelul use-case

Model de arhitectură de sistem

Diagrame de secvenţă UML

Model de clasă UML

Mode de date fizic

Personal Software Process (PSP)

Un proces software prescriptiv pentru dezvoltatori individuali.

1 TBD

Rational Unified Process (RUP)

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

Echipe de proiect medii până la mari (10 sau mai multe persoane).

Modelul use-case

Model de arhitectură de sistem

Diagrame de secvenţă UML

Model de clasă UML

Mode de date fizicScrum O metodă agilă ce se

axează pe gestionarea proiectelor şi gestionarea

Proiecte de orice mărime

Variază, depinde de procesele de dezvoltare cu care se utlilizează Scrum.

34

Page 35: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

cerinţelor. Deseori combinată cu XP.

Team Software Process (TSP)

TBD TBD TBD

Test Driven Development (TDD)

O abordare evolutivă a dezvoltării în care mai întâi trebuie scris un test ce eşuează înainte de a scrie noul cod funcţional. Cunoscut de asemenea ca programarea cu test iniţial sau dezvoltarea cu test iniţial.

Proiecte de orice mărime

Teste

Waterfall (modelul cascadă)

Modelul presupune că se pot “îngheţa” cerinţele înainte de a începe crearea software-ului, sau o modificare foarte mică a cerinţelor iniţiale.

Proiecte mici şi medii (4-20 persoane)

Teste

35

Page 36: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

7. Modelul cu prototipuri – Popescu Razvan

7.1 Notiuni generalePentru 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 cerinţelor 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 aşteptările consumatorului. După un număr finit de iteraţii, pachetul final este dat consumatorului. În această metodologie, software-ul evoluează ca rezultat al schimbului periodic de informaţii dintre consumator şi dezvoltator. Acesta este modelul cel

36

Page 37: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

mai popular din industria IT. Majoritatea produselor software de succes au fost create folosind acest model, întrucât este foarte dificil să înţelegi toate cerinţele 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 câteva aspecte ale atributelor programului final şi poate fi complet diferit de implementarea finală.

Scopul convenţional al unui prototip este de a permite utilizatorilor de software să evalueze propunerile dezvoltatorilor încercându-le practic şi nu pe baza descrierilor. Utilizarea prototipurilor poate fi utilă şi end user-ilor pentru a descrie cerinţe pe care dezvoltatorii nu le-au considerat, aşadar controlarea prototipului poate fi un factor cheie în relaţia comercială dintre dezvoltatori şi clienţi. Folosirea prototipurilor are o serie de beneficii: proiectantul soft şi dezvoltatorul pot obţine feedback de la utilizatori devreme în ciclul de viaţă. Clientul şi contractorul pot vedea dacă produsul software respectă cerinţele pe care se construieşte programul soft. De asemenea, oferă informaţii inginerului soft legate de estimările iniţiale şi de acurateţea lor, acesta putând 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 capătul apropiat. Prototipurile cu aruncare sau rapide se referă la crearea unui model care va fi până la urmă aruncat în loc să devină o parte integrată a software-ului final. După ce se termină adunarea cerinţelor preliminare, un model funcţional simplu al sistemului este construit pentru a arăta vizual utilizatorilor cum arată cerinţele lor aplicate într-un sistem finalizat. Prototipurile rapide implic crearea unui model al diferitelor părţi ale sistemului într-o fază incipientă, după o investigaţie relativ scurtă.

Metoda folosită la construirea modelului este de obicei informală, cel mai important factor fiind viteza cu care modelul este pus la dispoziţie. Modelul devine apoi punctul de început de la care utilizatorii reexaminează aşteptările şi clarifică cerinţele. Apoi, modelul prototip este aruncat şi sistemul este dezvoltat formal, bazat pe cerinţele identificate.

Motivul cel mai evident pentru folosirea acestei abordări este că poate fi îndeplinită repede. Dacă utilizatorii primesc un feedback rapid al cerinţelor lor, vor putea să le schimbe devreme în procesul dezvoltării produsului.

37

Page 38: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

Astfel de schimbări 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 dependenţe. Viteza este crucială în implementarea unui prototip de aruncat, deoarece cu un buget limitat de bani şi timp se poate cheltui puţin pe un prototip care nu va fi luat în considerare[1].

Un alt avantaj este abilitatea de a se construi interfeţe pe care utilizatorii le pot testa. Interfaţa cu utilizatorul este ceea ce acesta vede ca fiind sistemul şi văzându-l în faţa sa, îi este mult mai uşor să înţeleagă cum va funcţiona. Prototipurile pot fi clasificaţi în funcţie de gradul în care seamănă cu adevăratul produs ca aparenţă şi interacţiune. O metodă de a crea un prototip de aruncat cu fidelitate redusă este prototiparea pe hârtie. Prototipul este implementat cu creionul pe hârtie şi mimează funcţia adevăratului 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 funcţionalitate[3].

Rezumatul acestui tip de prototipare este următorul: a) scrierea cerinţelor preliminare; b) proiectarea prototipului; c) utilizatorul foloseşte prototipul şi specifică noile cerinţe; d) se repetă paşii b) şi c) până când cerinţele nu se mai modifică; e) scrierea cerinţelor finale;f) dezvoltarea produselor reale;

7.3 Prototipuri evolutive:

Prototiparea evolutivă este diferită de cea cu aruncare, întrucât scopul principal este de a construi un prototip foarte robust într-o manieră structurată şi de a-l rafina constant. Prototipul evolutiv, atunci când este construit va forma inima noul sistem. Când se dezvoltă un sistem folosind această metodă, acesta este constant rafinat şi reconstruit. Tehnica permite echipei să adauge trăsături, sau să facă schimbări care nu ar fi putut fi concepute în faza de cerinţe ş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 măsură ce mediul de operare se modifică. Prototiparea evolutivă are avantajul că toate prototipurile sunt sisteme funcţionale. Deşi e posibil să nu aibă toate funcţionalităţile pe care utilizatorii le-au dorit, ele pot fi folosite ca o bază intermediară până la livrarea sistemului final[1].

Dezvoltatorii se pot concentra pe dezvoltarea părţilor sistemului pe care le înţeleg, în loc să lucreze la dezvoltarea întregului produs[2].

38

Page 39: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

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

Page 40: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

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 dezavantajeAvantaje:

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

Page 41: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

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 "ad-hoc". Determinarea unui plan de actiuni este de prima importanta pt succesul abordarii incrementale. In faza de analiza preliminara se determina scopul proiectului si se incearca determinarea riscurilor majore ale proiectului, se determina o lista 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

Page 42: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

o Diferitele parti sunt implementate, testate si livrate in functie de diferite prioritati si la diferite momente de timp

8.3 ExempluUn 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 fabricaţie. Un prototip simulează de obicei doar câteva aspecte ale produsului final, şi poate fi complet diferit de acesta. Prototiparea are câteva avantaje: designer-ul de software şi implementatorul pot obţine „feedback” valoros de la utilizatori la începutul proiectului. Clientul şi contractantul pot

42

Page 43: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

evidenţia dacă software-ul se potriveşte cu specificaţiile dorite ale acestora, astfel programul software este construit.

Modelul cu subproiecte al software-ului împarte funcţionalitatea sistemului în tranşe (porţii). 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), permiţând dezvoltatorilor de software să profite de ceea ce s-a învăţat în timpul dezvoltării de versiuni anterioare ale sistemului. Învăţarea vine atât din partea dezvoltării cât şi din partea utilizării sistemului, în cazul în care măsurile posibile din proces, încep cu o punere în aplicare simplă a unui subset al software-ului şi sporesc cerinţele iterative ale versiunilor în evoluţie până când sistemul este implementat complet. La fiecare iteratie, modificările de design sunt realizate şi noi capabilităţi funcţionale sunt adăugate.

43

Page 44: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

9. Modelul in etape – Lungu Mihail

9.1 Introducere O versiune software este o distribuţie, publică sau privată, a unei versiuni de produs software iniţiale sau noi şi îmbunătăţite. De fiecare dată când un program sau un sistem suferă modificări, inginerii de software şi companiile în lucru decid modul în care vor face distribuţia programului său sistemului, sau schimbările pe care le vor aduce acelui program sau sistem în timp.

9.2 Etapele distribuţiei în ciclul de viaţă Ciclu de viaţă al distribuţiei 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 stări pe măsură ce noi caracteristici sunt adăugate, sau prin stagiul alfa , când 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 anunţate în mod regulat de către dezvoltatorii de software, dar uneori aceşti termeni sunt utilizaţi în scop informativ pentru descrierea stării produsului. Convenţional, nume de cod sunt adesea utilizate de multe companii pentru versiuni prioritare în lansare produsului, deşi 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 opțiunea achiziției de software universal. Produsele software universale rareori satisfac cerințele, dar sunt disponibile imediat și în timpul intervenției între momentul achiziționării unui astfel de soft și lansarea propriului tău soft, utilizatorii vor avea cel puțin câteva facilități valoroase. Ei pot învăța să lucreze în jurul limitării produsului din moment ce beneficiază de software particularizat și pe măsură ce timpul trece, produsele software comerciale sunt revizuite și potrivite îndeaproape nevoilor . Aplicațiile software particularizate probabil nu se vor alinia viziunii mentale ale produsului software ideal, iar comparațiile între produsele software particularizate și cele universale tind să compare efectiv soft-ul universal cu idealul produs software particularizat. Cu toate acestea atunci când se proiectează un soft, trebuiesc făcute concesii de proiectare, cost sau programare și există posibilitatea că produsul particular creat să ajungă la nivelul așteptat.

44

Page 45: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

9.4 Etapele de dezvoltare

Schema evoluţiei unui produs software9.4.1 Pre-alfa Este considerată o formă incompletă a programului lansată iniţial, înainte de emiterea variantelor alfa sau beta. Prin comparaţie cu ultimile variante amintite, modelul pre-alfa nu conţine toate caracteristicile şi când este folosit se referă la toate activităţile desfăşurate în timpul proiectului software înainte de testarea software. Aceste activităţi pot include analiza cerinţelor, proiectare software, dezvoltare de software şi unităţi de testare. În lumea Open Source, sunt câteva tipuri de versiuni pre-alfa. Versiunea Milestone include un set specific de funcţionalităţi ş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 funcţionalităţile recent implementate şi să descoperă noile probleme, defecte ale sistemului. 9.4.2 Alfa Realizarea variantei alfa a produsului software este forma înmânata celor ce se ocupa de testarea soft, care sunt persoane diferite de inginerii de software, dar uzual fac parte din organizaţia sau comunitatea de dezvoltatori de software. Ocuparea rapidă a poziţiei softului pe piaţa duce uneori la angajarea de către companiile dezvoltatoare a mai multor clienţi externi sau parteneri valoroşi pentru efectuarea testărilor 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

Page 46: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

Validările adiţionale 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 organizaţiei este cunoscută că lansarea alfa. 9.4.3 Beta O versiune Beta este prima variantă lansată în afara organizaţiei sau comunităţii dezvoltatoare de software, cu scopul evaluării sau testării cutiei-negre, gri de către lumea reală. Procesul de livrare a versiunii beta către alţi utilizatori poartă numele de distribuţie beta. Nivelul software beta în general conţine toate caracteristicile, dar poate conţine şi elemente nedorite sau simple erori într-un mod variabil mai puţin grav.

Utilizatorii unei versiuni beta sunt numiţi testări beta şi adesea sunt clienţi obişnuiţi sau potenţiali clienţi ai organizaţiei care dezvoltă software. Ei primesc software-ul gratuit sau la un preţ redus, dar acţionează ca testări liberi. Versiunile beta testează suportul produsului, mesajul introducerii pe piaţă ( în timpul recrutării clienţilor beta ), fabricaţia produsului şi fluxul de canal global şi canal atins. Versiunile de software beta sunt cel mai probabil necesare demonstraţiilor interne şi selectării clienţilor, dar nestabile şi nepregătite 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 naştere când dezvoltatorii anunţa o stagnare a unor caracteristici ale produsului, indicând imposibilitatea acceptării unor cerinţe caracteristice pentru versiunea produsului şi numai problemele de soft , bug-urile sau facilităţile 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 comunităţi mari de utilizatori, de obicei publicul larg. Testării furnizează orice eroare întâlnita şi uneori mici caracteristici pe care le-ar dori implementate în varianta finală. Când o variantă beta devine disponibilă publicului general este adesea larg utilizată de tehnologii savvy şi de cei familiarizaţi cu versiunile anterioare ca şi când 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ă către un grup restrâns de testări. Beneficiarii de versiunile beta originale trebuie să semneze un contract de nedivulgare. O lansare poate fi numită caracteristica completa când echipa produsului este de acord cu cerinţele funcţionale ale sistemului şi nicio ulteriora facilitate nu va fi inclusă în distribuţie, dar erori signifiante vor continua să existe. Companiile cu un proces software formal vor tinde să pătrundă în perioada beta împreuna cu o listă de bug-uri care trebuie să fie fixate pentru părăsirea perioadei beta, şi unele companii pun aceste liste la dispoziţia clienţilor şi testărilor. Internetul a permis distribuţia de software într-un mod rapid şi necostisitor, iar companiile au adoptat tehnici flexibile de abordare în vederea utilizării sensului cuvântului “beta”. Cei de la Netscape Communications au lansat o versiune alfa a browserului cu aceeaşi denumire şi au numit-o beta, în ideea păstrării 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 făcând parte din nivelul de producţie, exemplul celor de la G-mail sau

46

Page 47: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

Google care au fost sub forma beta o lungă perioadă de timp şi nu au renunţat la acest aspect luând în considerare utilizarea largă, dar în cele din urmă Google a părăsit această variantă prin ianuarie 2006. Această tehnică permite unui dezvoltator să întârzie oferind suport total şi/sau responsabilitate pentru problemele rămase ş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 făcut produselor hardware IBM convenţie datând din perioada cardurilor perforate şi maşinilor de sortat. Componentele hardware treceau iniţial prin testul alfa pentru funcţionalitatea preliminară şi etapa de fezabilitate a fabricaţiei, apoi urmă testul beta care verifica dacă funcţiile 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 apariţia computerelor programabile şi primele programe partajabile, IBM a continuat cu aceeaşi terminologie pentru testarea produselor software. Testele beta erau conduse de oameni sau grupuri altele decât dezvoltatorii, şi cum alte companii au început crearea de software pentru propriile utilizări şi distribuţii către alţii, evoluţia terminologiei a stagnat şi s-a păstrat până în prezent.9.4.5 Seigo Stagiul Seigo este un nivel al evoluţiei software când librăriile necesare produsului sunt finalizate (sau aproape gata) dar restul produsului necesita lustruire şi finisare. Stagiul intervine între varianta beta şi varianta finală a dezvoltării soft deoarece produsul este încă nepregătit pentru a intra în faza finală de livrare, chiar dacă librăriile sunt de calitate. Termenul provine după o controversata discuţie pe tema linux în “The Linux Action Show !”, evenimentul lansării celei de-a două versiuni finale a KDE 4 neridicându-se la standardul unei variante release candidate, discuţie 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 potenţial de produs final, gata să fie lansată chiar dacă se ivesc erori. În acesta etapă, produsul prezintă în mod normal codul complet. Corporaţia Microsoft adesea foloseşte termenul de release candidate ( distribuţia finală). În timpul anilor 1990, Apple Inc. a utilizat termenul de „maestru de aur” pentru distribuţiile finale şi maestrul de aur final reprezentând distribuţia generală disponibilă. Alţi termeni includ gamma (şi ocazional delta, sau alte litere greceşti) pentru versiunile care sunt substanţial complete, dar aflate încă sub test, şi omega pentru testarea finală a versiunilor care sunt considerate a fi bug-free, şi pot intra în producţie oricând. O distribuţie este numită cod complet când echipa de dezvoltare este de acord că nicio sursă internă de cod nou nu va fi adăugată acestei distribuţii, însa pot exista modificări de coduri pentru a înlătura defecte şi chiar schimbări de documentaţie şi fişiere de date, şi de asemenea coduri pentru cazurile test sau alte utilităţi.

Distribuţia Gold sau distribuţia general disponibilă

47

Page 48: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

Versiunile gold lansate sau cele generale sunt formele finale a unui produs particular. Este tipic aproape identic cu distribuţia finală, cu bug-uri fixate în ultimul minut. O distribuţie Gold este considerată foarte stabilă şi relativ un bug-free cu o calitate corespunzătoare pentru distribuţii largi şi folosită de utilizatori finali. În distribuţiile comerciale de software, această versiune poate fi semnată ( folosită să permită utilizatorilor finali posibilitatea verificării 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 număr mare şi valabil curând pentru vânzare. Termenul de aur, anectodic se referă la utilizarea discului master de aur care a fost folosit în mod obişnuit în trimiterea variantelor finale producătorilor care îl folosesc să creeze copii de vânzare în masă. În unele cazuri acest disc este realizat chiar din aur, atât pentru estetică cât şi rezistenţa la coroziune.[5]

9.6 RTM sau RTW Microsoft şi alţii folosesc termenul de „ distribuţie finală ” RTM (“release to manufacturing”) pentru a se referi la aceste versiuni( pentru produse comerciale ca Windows XP , ca în” Build 2600 cu distribuţia RTM Windows XP”), şi “distribuţii Web”- RTW pentru produse gratuite descarcabile. Tipic, RTM reprezintă săptămânile ş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 substanţial identic cu o versiune care a trecut suficient printr –o testare de către lumea-reala pentru asigurarea corectitudinii softului, sau acele mici probleme existente sunt cunoscute şi detaliate.

Pe de altă parte termenul nestabil, nu înseamnă neapărat că există probleme, mai degrabă, acele îmbunătăţiri sau schimbări efectuate produselor software care nu au fost riguros testate. Utilizatorii unui astfel de software sunt sfătuiţi să folosească versiunile stabile dacă vor să-şi atingă interesele dorite, şi să utilizeze varianta instabilă când apariţia 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, distribuţiile stabile au al doilea număr par şi cele instabile au unul impar. Practica utilizării numerelor impare, pare pentru a indica stabilitatea distribuţiei a fost utilizată de alte proiecte open/closed source .

48

Page 49: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

Exemplificarea versiunilor lansate în perioada unui ciclu de viata software

49

Page 50: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

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 experienţa în management, un mediu care oferă o bună gestionare de control şi răspuns, precum procedurile de gestionare executorii şi standardele de control pentru menţinerea proiectului. Aceste elemente sunt esenţiale pentru realizarea de succes pe termen lung operaţional şi economic în dezvoltarea sistemelor de software fie într-un mediu militar sau comercial.

50

Page 51: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

10.Modelul cu software commercial – Lungu Mihail

10.1 Notiuni introductive Putem deduce faptul ca un set de paşi este oferit împreună cu cerinţele şi tehnicile pentru

implementarea şi menţinerea controlului proiectului. În mod special, o măsurare cantitativă a calităţii software-ului comercial este propusă pe baza valorii funcţionale, disponibilităţii şi costurilor de întreţinere. Concluziile trase sunt bazate pe studiul diferitelor cazuri şi sunt aplicabile atât în sistemul militar cât şi comercial.

Rezultatele acestui studiu din acest fişier 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 doreşte să obţină un profit(sau pe baza unui contract) , cu scopul de a îmbunătăţi performanţele.

10.2 Măsurarea mărimii proiectului şi a dificultăţii nivelului Definirea managementului ciclului de viaţă al sistemului este într-o mare măsură dependenta de mediul luat în considerare. Aceasta este în mod special adevărat când evaluam metode de administrare a dezvoltării software-ului, întrucât scopul problemelor întâlnite este dependent de variaţia considerabilă. De exemplu, următorii factori pot solicita cereri radicale legate de abordări de management:

1) numărul de instalaţii separate geografic să fie menţinut;2) numărul diferitelor tipuri de utilizatori să interacţioneze în cadrul sistemului;3) nivelul automatizării impementat anterior în cadrul aplicaţiei;4) cerinţele disponibilităţii 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 eşecul proiectului. Ca şi pe alte pieţe, calitatea produsului şi profiturile merg mana în mână. Calitatea produsului final depinde de disponibilitatea funcţiilor sistemului cerute de utilizator şi de costul aferent menţinerii disponibilităţii. În mod normal, dezvoltatorul va lua măsuri pentru a “previziona” şi a “controla” calitatea de la începutul ciclului de viaţă al sistemului. Totuşi, în practică, măsurarea finală a calităţii nu poate fi determinată până când sistemul se afla în mâinile utilizatorilor reali în mai multe medii de operare.

Riscul este de obicei definit de riscul de a nu obţine profit să de a obţine economii. Pentru sistemele din domeniul militar poate să fie vorba de riscul de a nu obţine un nivel de performanţă adecvat. În ambele cazuri grija noastră este să minimizăm riscul sau să îl menţinem la un nivel acceptabil . În riscul de măsurare, trebuie să considerăm procentajul de reurse care vor fi date în consum de organizaţie pentru a aduce produsul în punctul de a fi profitabil. În plus, timpul pentru a obţine profit, rata rentabilităţii şi probabilitatea de a fi în concordanţă cu programul având în vedere timpul şi resursele alocate sunt factori pe care îi luăm în considerare pentru evaluarea riscului. Este

51

Page 52: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

de datoria proiectantului să determine când riscul şi calitatea sunt la nivele acceptabile şi să evalueze dacă organizaţia trebuie să continue cu proiectul .

În sistemul commercial investigat, comercianţii de software nu au anticipat venituri profitabile până când mai multe instalaţii au funcţionat cum trebuie în operaţiuni live. În mod special, un sistem nu a fost profitabil până când a 5-a instalare nu a fost produsă.

10.3 Performanţele legate de software-ul commercial

Performanta comerciantului şi managementul proiectului sau au fost evident măsurabil de-a lungul ciclului de viaţă al sistemului. Memoria corporativă despre cum au fost făcute estimările asupra timpului şi costurilor este bine conservat pentru a reduce viitoare riscuri. Într-un mediu ce cuprinde mai multe instalări , cerinţele legate de rezistenţă şi mentenabilitate sunt de foarte mare importanţă. Dacă numărul instalaţiilor şi costurile atribuite acestora cresc, cerinţele de rezistenţă şi mentenabilitate amplifica nevoia de calitate a design-ului. Adăugăm la acestea o cerinţă competitivă de satisfacere a utilizatorilor cu garanţia ş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, considerăm un mod “ideal” de a descrie problema controlului ciclului de viaţă , cum se poate vedea în Fig. 1. Presupunând că capacitatea operaţională poate fi măsurată în acelaşi sens cu reursele utilizate astfel încât o mişcare (dolari şi cenţi) a performantei ROI să fie atinsă. O astfel de măsură poate fi determinată precis în cazul unui comerciant de software care vinde un produs ambalat. Aceasta măsurătoare este de asemenea valida pentru proiecte unde economiile pot fi uşor de determinat. În cazul capacităţilor operaţiunilor 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

Page 53: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

Curbele din Fig.1 reprezintă o soluţie generală la problema controlului ciclului de viaţă. Soluţia este una generală întrucât pentru o problemă de software dată, pot exista un infinit de curbe de soluţionare. Forma lor va depinde de judecata managerului de proiect şi a multor altor factori legaţi de ciclul de viaţă. Obiectivul problemei tehnice este să conturăm aceste curbe în aşa fel încât să maximizăm ROI.

Există multe constrângeri externe pe care un manager de proiect trebuie să le aibă în vedere. În primul rând, trebuie să determine care este perioada de timp necesară proiectului. În primul rând, 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 creşte . Trebuie să ia în considerare schimbările din mediu, de tehnologie, şi concurenţa. În cazul militar, aceasta corespunde cu perioada în care exista o capacitate operaţională antecedenta unei învingeri a unei ameninţări.

Dacă există deja o piaţă pentru sitemul în cauză, atunci IOC ( capacitatea iniţială operaţională) va depinde numai de timpul de dezvotare pentru atingerea scopului. Totuşi, perioada totală pentru obţinerea veniturilor este influenţată de IOC şi de uzură morală a sistemului (SOB). Evident, dacă sunt cheltuiţi mai mulţi bani pentru a scurta timpul pentru IOC, veniturile vor apărea mai devreme. Cu toate acestea, un manager de proiect experimentat este conştient că de fapt o accelerare a ritmului de produce va duce la costuri mai mari.

Alte constrângeri financiare care trebuie luate în considerare sunt consumul maxim de resurse (MRC) şi punctul de împărţire egala (BEP). MRC are loc când veniturile şi economiile depăşesc costurile prezente. Trebuie să existe destule resurse disponibile la rata cerută pentru a acoperi acelea utilizate pentru MRC. BEP are loc când costurile totale au fost acoperite din venituri sau economii. Profitul comerciantului nu poate fi definit în acest punct, exceptând capitalizarea pe termen lung a costurilor superioare?. Dacă un comerciant întâmpina mult timp BEP-ul acestea se va gândi în ce alte proiecte îşi poate înveşti resursele. În concluzie, problema controlului ciclului de viaţă este redusă la una din curbele din Fig.1 , care ne arată maximizarea ROI constrânsa de factori cum ar fi calitatea, riscul, MRC, timpul până la IOC şi BEP.

10.5 Determinarea calităţii software-ului comercial

53

Page 54: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

Calitatea software-ului trebuie să fie măsurată în funcţie de timp într-un mediu operaţional. Înainte de timp, calitatea software-ului poate fi previzionata şi controlată de factori care o afectează. Totuşi, măsurarea calităţii oferite aici este considerată esenţială în corelarea efetcelor acestor factori :

Vom începe cu noţiunea intuitivă ca „Q”calitatea este proporţională pentru disponibilitatea sistemului A şi invers proporţională cu costurile de întreţinere disponibilităţii valabile M3.

Q=Costul pentru a menţine un sistem este direct măsurabilă în mediile luate în considerare. Pentru a defini disponibilitatea aşa cum este folosită în (1), am defini în primul rând factorul f i care descrie importanţa relativă a tuturor funcţiilor sistemului astfel judecate de către utilizator. Aceşti factori pot fi normalizaţi, astfel încât:

unde n este numărul de funcţii care trebuie să fie la dispoziţia utilizatorului. Noi definim l i că nivelul de disponibilitate a funcţiei i, astfel încât :

În cazul în care li este unul singur (zero), atunci sistemul este total disponibil,şi nivelurile pot lua valori binare sau continue. Dacă toate funcţiile sistemului sunt disponibile în totalitate, atunci

Acesta este ghidul de care trebuie să definească importanţa relativă a funcţiilorsistemului, precum şi nivelul lor de disponibilitate la orice moment în timp. Referindu-ne la Fig. 2, considerăm că vom lua măsurători succesive pesteintervale de timp de lungime TF . O creştere practică poate fi o lună. În timpul acestor intervale vom măsura continuu nivelul de disponibilitate al fiecărei funcţii de sistem. Presupunem cătoate funcţiile sunt complet disponibile cu excepţia cazului în care se stabileşte cănivelul lor de disponibilitate scade sub o unitate. De exemplu, în Fig.

54

Page 55: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

2, la timpul TKD, nivelul de disponibilitate a funcţiei i scade la o valoare mai mică de 1. La momentul TKU, problema este corectată şi funcţia este în totalitate la dispoziţia utilizatorului. Pentru a facilita definirea disponibilităţii medii pe intervalul (t0, tf), definim indisponibilitate ca:

ui=1-li

Măsurile de calitate oferite nu sunt destinate să fie absolute. Deficienţele lor, cum ar fi interdependenţele dintre funcţii, pot fi depăşite printr-o hotărâre bună în determinareanivelului de disponibilitate. Dacă un jurnal este ţinut individual , ca valori de disponibilitate funcţionale se poate calcula un nou set de factori de calitate la schimbarea ponderile relative ale funcţiei. Cu toate acestea, importanţa măsurilor revine după interpretarea lor. Reţineţi că disponibilitatea poate fi îmbunătăţita prin scurtarea timpului necesar pentru a aduce o reducerenivelului de disponibilitate înapoi la unitate. Cu toate acestea, astfel de eforturi pot creşte costul de întreţinere şi a potenţialului, prin urmare, diferenţa îmbunătăţiri în măsura generală a calităţii.În mediul comercial furnizorul şi potenţialii cumpărători a unui sistem software vor dori să vorbească cu utilizatorii existenţi cu privire la disponibilitatea funcţiilor sistemului dorit. Acest lucru reprezintă calitatea produsului, cum este văzute de utilizator. Cu toate acestea, este doaro parte din imagine ca văzută de către un dezvoltator,de menţinerea unui sistem de garanţie. Din punctul de vedere al dezvoltatorului, el trebuie să ia în considerare costurile de întreţinere î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 lăsată 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 măsuri, deoarece,în calitate de utilizatori devin mai sofisticate.

10.6 Măsurarea succesului într-un mediu commercial, competitive

55

Page 56: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

Având definită problema teoretic, considerăm acum că managerul de proiect poate obţine soluţii practice. Întrebările pe care le punem sunt: -Care sunt controalele care definesc curbele?

-Cum putem previziona reacţiile lor? -Cum putem valida previziunile într-un mediu în continuă schimbare? Abordam aceste întrebări prin compararea dezvoltatorilor de software dintr-un mediu

comercial. (Fig. 3) . Înainte de a ne axa pe cazuri specifice putem trage nişte concluzii din observaţiile făcute:1.anumiţi dezvoltatori de software au fost mai de succes decât alţii ;2.exista o viziune comună că riscul poate fi redus printr-o evoluţie mai lentă, dacă

managementul este lipsit de experienţă. 3. rata de abrupt de utilizare a resurselor de către dezvoltator 1

necesită o cunoaştere a modului de utilizare în mod eficient acestor resurse- cu alte cuvinte, experienţa în management. 4. este important să înţelegem cum şi în cazul în care software-ul se înscrie în ciclul de viaţă al sistemelor totale şi în ce măsură software-ul de gestionare a ciclului de viaţă influenţează sistemul de management total. În Introducere, să indicat că software-ul este diferit de la hardware-ul. Probabil cea mai importantă diferenţa 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. Reţinem că maximu; este atins dacă CIO este favorabil. Atunci când software-ul consumă omai mare parte a resurselor de sistem ale ciclului de viaţă, este necesar pentru a obţine înţelegerea de top management şi de aprobare anticipată de vârf de utilizare a resurselor. Dacă acest lucru nu se face, şi la fel IOC este încercat să fie îndeplinit, că CIO va fi prematură. acestaduce la o capacitate operaţională fictivă în care utilizatorul este condus să creadă că o capacitate operaţională reală există, atunci când în defapt nu. [3]

În plus faţă de funcţia 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 excepţia cazului în care acestea sunt mapate în mod corespunzător în ciclul total de viaţă al sistemului, atunci o parte din software-ul sistemului nu va fi controlat în mod corespunzător. Se pare că setul de

56

Page 57: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

componente ale sistemului ciclului de viaţă în etape, activităţi şi evenimente în cadrul comecial nu necesită schimbare prea mare în ceea ce priveşte numele şi realizarea generală pentru a putea fi utilizat pentru software. Ceea ce ei au nevoie sunt interpretarea adecvată şi un set diferit de măsurare specifică criterilor pentru realizarea lor. Această cerinţă pentru repere de management specifice software-ului comercial este foarte important să fie recunoscut.[4]

11.Modelul cu medii de dezvoltare – Guta Ovidiu

57

Page 58: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

11.1 Notiuni generaleIn 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 fazeVom incepe cu cea mai simpla, dar in acelas timp completa, configuratie a mediilor de

dezvoltare.

58

Page 59: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

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 milestone-uri.

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 dezavantajeAvantaje: 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.

11.4 Sisteme Distribuite

59

Page 60: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

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. SVNApache 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 menținerea versiunilor curente și istorice ale fișierelor cod sursă, paginilor web și a documentației î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 organizații 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.

Subversion este folosit pe larg și în dezvoltarea de software proprietar. Conform unui raport din 2007 al organizației Forrester Research, Subversion este leaderul absolut al categoriei

60

Page 61: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

Standalone Software Configuration Management (SCM) și unul leaderii categoriei Software Configuration și Change Management (SCCM).[2]

Subversion este publicat sub licența Apache și este considerat software liber.

Facilități Operațiile commit sunt atomice. Fișierele șterse/redenumite/mutate își păstrează istoria. Versioning pentru directoare. Versioning pentru symbolic links. Suport nativ pentru fișiere binare, bazat pe stocarea diferențelor. Pe post de network server este folosit Apache HTTP Server, WebDAV/Delta-V este

folosit pe post de protocol. Definește de asemenea și un protocol propriu construit în stiva TCP/IP folosit cu ajutorul serverului svnserve. Protocolul transmite întotdeauna numai diferențele, minimizând traficul de rețea.

Operațiile de branching și tagging sunt optimizate să consume foarte puțină memorie. Design client-server, o bibliotecă este disponibilă pentru dezvoltarea clienților, language

bindings pentru C#, PHP, Python, Perl, și Java. Bază de date FSFS (foarte rapidă pe directoare cu multe fișiere[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

12.Concluzii – Laza Laura

61

Page 62: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

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 activităţi care au loc în timpul procesului.Un model de ciclu de viaţă software descrie etapele semnificative sau activităţile unui proiect software de la concepţie până când produsul respectiv este retras. Acesta specifică relaţiile dintre etapele proiectului, inclusiv criteriile de tranziţie, mecanismele de feedback, milestone-uri, liniile de bază, recenzii, şi rezultatele. De obicei, un model de ciclu de viaţă adresează fazele unui proiect software: etapa cerinţelor, proiectarea, implementarea, integrarea, testarea, mentenanţa. O mare parte din motivaţia 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 decât un hacker indisciplinat).

Au fost prezentate 10 modele ale ciclului de viata al unui produs software, fiecare cu avantaje si dezavantaje.

Bibliografie

62

Page 63: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

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 1988Sorensen, 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?

taxonomyId=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 http://support.motioneng.com/Software-MPI_04_00/basics/releases/sw_life_cycle.htmhttp://en.wikipedia.org/wiki/Commercial_software

63

Page 64: Laza Stefanescu Guta Popescu Lungu 443A CICLUS

[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