Documente noi - cercetari, esee, comentariu, compunere, document
Documente categorii

Ciclul de viata al produsului program

Ciclul de viata al produsului program

Elaborarea unui produs program (PP), numita si ciclul de viata al unui produs program, reprezinta multimea tuturor activitatilor, impreuna cu rezultatele asociate lor, care au ca efect final obtinerea unui PP.


Aceste activitati includ:


Analiza cerintelor

Are ca obiectiv obtinerea unei descrieri cat mai complete a problemei de rezolvat si a cerintelor impuse de catre mediul in care va functiona PP.

Rezultatul acestei activitati este specificatia cerintelor.




Proiectarea

Are ca obiectiv obtinerea unui model al PP care, daca este transpus intr-un limbaj de programare, rezolva problema data.

Desi analiza cerintelor si proiectarea sunt privite deseori ca o introducere greoaie in programare, scrierea instructiunilor fiind considerata "adevarata problema", aceasta atitudine are un efect negativ asupra calitatii unui PP.

Proiectarea se face la un nivel abstract, independent de detaliile de implementare, iar rezultatul sau este concretizat intr-o specificatie tehnica sau proiect.


Implementarea

Are ca obiectiv transpunerea proiectului intr-un limbaj de programare.

Accentul este pus in primul rand pe obtinerea unui program bine documentat, fiabil, lizibil, flexibil si corect si mai putin pe aspecte secundare ca obtinerea unui program foarte eficient sau apliocarea unor trucuri de programare.

Rezultatul acestei activitati este un program executabil.

Activitatile: proiectare si implementare se grupeaza deseori sub denumirea generica de dezvoltare.


Testarea

Este gresit sa se considere testarea ca etapa succesoare implementarii, deoarece acest lucru ar insemna sa ne preocupam de ea numai dupa ce programul a fost implementat.

Corect este sa fie efectuata dupa fiecare activitate in parte, sub forma verificarii si validarii.

Verificarea: stabilirea corectitudinii tranzitiei din etapa i in etapa i + 1

Validarea: stabilirea faptului ca nu ne-am indepartat de cerintele stabilite initial.


Intretinerea

Are ca obiective indepartarea erorilor raportate in faza de exploatare a PP si evolutia PP pentru a satisface eventuale cerinte noi.

Activitatile de intretinere se clasifica in:


intretinere corectiva: inlaturarea erorilor,

intrtinere adaptiva: adaptarea PP la schimbarile mediului in care opereaza (hardware nou, o noua versiune a sistemului de operare sau a sistemului de gestiune al datelor, etc.),

intretinere perfectiva: adaptarea PP la noile cerinte ale utilizatorilor,

intretinere preventiva: actualizarea documentatiei, imbunatatirea structurii modulare, adaugarea de comentarii.etc. Are ca obiectiv imbunatatirea mentenabilitatii viitoare.



Modele ale ciclurilor de viata ale unui produs program (PP)


Scopul elaborarii unui model al ciclului de viata al produsului program este optimizarea diverselor atribute ale sale.




Deoarece nu exista un model general care sa permita simultan optimizarea tuturor atributelor acestuia, s-au propus mai multe astfel de modele (vom relua prezentarea unora deja cunoscute, dar din punctul de vedere al dezvoltarii PP, noua abordare a elaborarii PP. Nu mai vorbim de programare, ci de dezvoltare).


Modelul liniar

Este un model al ciclului de viata al PP in care activitatile sunt ordonate liniar, sub forma unei succesiuni de etape, fiecare etapa trebuind sa fie incheiata pentru a se putea trece la urmatoarea.

Fiecare etapa este o realizata de o anumita categorie de specialisti:


- analisti: culeg cerintele, fac analiza de sistem,

- proiectanti: definesc arhitectura si structura PP,

- programatori: codifica rezultatul proiectarii (scriu programul intr-un limbaj de

programare ales),

- operatori: ruleaza programul.

Modelul liniar este figurat mai jos:


ANALIZA Se analizeaza cerintele utilizatorului, cerintele de sistem, si

cerintele software-ului


PROIECTARE Proiectare de ansamblu si de detaliu



CONSTRUCTIE Implementare/codificare, testare pe componenete, testare sistem



UTILIZARERulare, intretinere, evolutie desfasurate in ciclu


Avantajele modelului liniar:


- se pot stabili termene precise pentru terminarea fiecarei etape,

- se pot angaja specialisti pentru fiecare etapa in parte,

- ordonarea liniara usureaza planificarea,

- ordonarea liniara este agreata de manageri, fiind considerata practica,

- ordonarea liniara este potrivita pentru proiecte in care sunt implicati multi oameni,

- ordonarea liniara se potriveste metodologiilor clasice de analiza/proiectare/implementare.


Dezavantaje:


- nu se poate reveni asupra deciziilor luate in etapele deja incheiate, deoarece nu

exista "feed-back" (iteratie),

- structura modelului in ansamblul ei este foarte rigida.


De exemplu, daca se descopera in faza de implementare erori in proiectare, nu se reconsidera proiectarea, incercandu-se rezolvarea probelemelor prin solutii ad-hoc in faza de implementare.


Modelul cascada

Se obtine din modelul liniar, prin introducerea unei activitati de verificare si validare (VV) la sfarsitul fiecarei etape si a unor reveniri in etapele anterioare, in cazul in care VV nu permite trecerea la etapa urmatoare.



Acest model a fost introdus de Royce in 1970. Mai jos prezentam structura acestui model:



Acest model are avantajul ca inlatura rigiditatea modelului liniar prin introducerea unor legaturi de "feed-back" (iteratii).

Dezavantaje:


- daca in proiect sunt implicate resurse multe, iteratia poate fi dificila si costisitoare,

- coordonarea multor persoane in prezenta iteratiilor poate crea dificultati,

- repetarea anumitor etape poate lasa anumiti perticipanti la proiect in asteptare

- desi este un model foarte raspandit, este consuderat una din principalele cauze ale

aparitiei crizei software, deoarece incurajeaza dezvoltarea prin descompunere

functionala, nu ia in considerare evolutia si nu incurajeaza reutilizabilitatea,

ignora importanta datelor punand accent pe aspectul procedural.


Modelul evolutional

Se bazeaza pe ideea dezvolarii unei implementari initiale, prezentarea ei utilizatorului si apoi rafinarea ei in versiuni ulterioare, pana cand se obtine un PP adecvat.

Prezentam mai jos structura acestui model:





Exista doua modele evolutionale care difera prin obiective: modelul programarii exploratorii si modelul prototipizarii.


Modelul programarii exploratorii

Are ca obiectiv lucrul cu beneficiarul pentru a-l ajuta sa inteleaga cerintele problemei.

In acest caz, PP este o unealta de explorare a universului problemei.



Acest model se utilizeaza in special pentru implementarea programelor de inteligenta artificiala.

Acestea incearca sa simuleze inteligenta naturala, care la ora actuala nu este suficient inteleasa, fiind astfel dificil de simulat.

Modelul prototipizarii

Are ca obiectiv intelegerea de catre contractor a cerintelor beneficiarului in scopul efectuarii unei analize cat mai complete a cerintelor.

In acest caz, versiunile intermediare se numesc prototipuri.

Trasaturile specifice ale modelului prototipizarii sunt:


- este foarte potrivit pentru echipe mici de dezvoltare (sub 10 membri),

- este folosit la dezvoltarea aplicatiilor moderne interactive, in care o mare importanta

o are interfata cu utilizatorul,

- este potrivit pentru metodologia de dezvoltare orientata obiect,

- contine idea buna de rescriere completa a prototipului pentru acrea PP final,

- necesita lucru in echipa de calitate.


Avantajele acestui model sunt urmatoarele:


- inlatura complet modelul in cascada,

- modul de derulare este flexibil,

- raspunsul la schimbarile cerintelor este rapid,

- problemele aparute in cadrul unor etape se pot rezolva multumitor in cadrul altor

etape,

- in orice moment exista un PP functional, chiar daca este incomplet,

- se pot arata beneficiarului versiuni preliminare ale PP in vederea preluarii

feed-back-ului,

- este foarte potrivit pentru dezvoltarea interfetelor utilizator, parte componenta a

tuturor PP moderne,

- este agreat de programatori.


Dezavantajele acestui model sunt:


- calitatea proiectului este greu de mentinut ridicata datorita schimbarilor frecvente

(codul rezultat nu este perfect, structurarea este slaba..),

- gestiunea proiectului este dificila,

- nu exista termeneclare si progresul este greu de urmarit (are vizibilitate redusa),

- estimarea resurselor necesare (timp, oameni, efort) este greu de realizat,

- este greu de estimat cand se va termina elaborarea PP, oricand poate fi ceva de

adaugat,

- echipele de dezvoltare fiind mici, aplicatia va fi mica,

- necesita aptitudini si motivatii speciale din partea participantilor.


Modelul reutilizarii

Reprezinta de fapt o categorie de modele care incearca maximizarea si sistematizarea refolosirii elementelor de analiza, proiectare si implementare deja existente, in scopul reducerii elementelor noi necesare in elaboraea PP.

Aceste modele promoveaza ideea dezvoltarii aplicatiilor din componente software reutilizabile.