Ciclul de viaţă al produselor program 4-1

Capitolul 4: Ciclul de viaţă al produselor program Ciclul de viaţă al unui produs software reprezintă intervalul de timp de la momentul deciziei de realizare şi până la retragerea sau înlocuirea totală a acestuia cu un nou produs software, reprezentând orizontul de timp în care operează şi evoluează produsul program. După glosarul de termeni - terminologie software - ai IEEE (Institute of Electric and Electronic Engineering), ciclul de viaţă reprezintă o abordare sistemică începând cu dezvoltarea, utilizarea, mentenanţa şi până la retragerea software-lui.

Din punct de vedere al utilizatorilor cele mai importante părţi ale ciclului de viaţă sunt utilizarea curentă (operaţionalitate) şi mentenanţa; produsele software sunt dezvoltate pentru a satisface nevoile consumatorilor / utilizatorilor. Din punctul de vedere al realizatorilor, etapele cele mai importante sunt cele în care se construieşte produsul software.

Durata ciclului de viaţă al unui produs software depinde de caracteristicile de calitate şi performanţă ale acestuia, dar şi de o serie de factori externi produsului software cum sunt: stabilitatea funcţională, relaţiile sale cu mediul, dinamica metodelor, tehnicilor, conceptelor etc.

Ciclul de realizare este o noţiune derivată din cea de ciclu de viaţă acoperind intervalul dintre momentul deciziei iniţiale de realizare şi până la punerea în funcţiune a produsului software. Acest interval, împărţit în general în etape, presupune analiza problemei, proiectarea produsului software, implementarea de cod, testarea şi experimentarea acestuia, deci reprezintă o parte a ciclului de viaţă şi anume cea care are ca scop dezvoltarea produsului.

Dezvoltarea de software de înaltă calitate necesită procese de producţie software, utilizate pentru a dezvolta aceste produse, principii de inginerie software, pe care să se bazeze aceste procese şi care încorporează practici ale ingineriei software [BRU 95].

Principiile dezvoltării software sunt legate de calitate, de management şi de inginerie. Aceste principii se reflectă în calitatea produsului software, în termenele de realizare, precum şi în costurile implicate.

Referitor la principiile calităţii se poate spune că noţiunea de calitate nu înseamnă numai testarea acesteia pentru un produs software, ci şi construirea şi asigurarea calităţii în procesele software. Principiile generale sunt : � prevenirea defectelor; � asigurarea faptului că defectele au fost detectate şi corectate cât mai mult posibil; � stabilirea şi eliminarea cauzelor care produc anumite simptome; � audit şi conformitate cu standarde şi proceduri.

În ceea ce priveşte principiile de management putem aminti: � planificarea tuturor activităţilor necesare în realizare din punct de vedere al timpului , bugetului,

resurselor şi restricţiilor de calitate. � monitorizarea continuă, îmbunătăţirea progresivă a planurilor, revizuirea planurilor dacă anumite

limite de toleranţă au fost depăşite. � definirea clară a structurii, rolurilor, responsabilităţilor şi liniilor de comunicaţie între grupuri sau

indivizi, persoane implicate în realizare.

Ca principii de inginerie se pot preciza: � descrierea clară a problemei - care întâmpină două tipuri de dificultăţi majore:

- cerinţele sunt exprimate de obicei în termenii problemei reale (cerinţe reale) şi trebuie translatate în termenii uzuali contextului software;

- utilizatorul nu poate preciza complet cerinţele sale sau nu poate să găsească legătura dintre ele; � definirea şi selectarea soluţiei printr-o clară definire a componentelor; � controlul riguros al relaţiilor dintre componente.

4-2 Ciclul de viaţă al produselor program

Activităţile componente ale ciclul de viaţă al produselor software sunt grupate în mai multe moduri, în etape sau faze. O astfel de grupare a activităţilor componente ale ciclului de viaţă este prezentată în tabelul 4.1 [BRU 95]:

Tabelul 4.1 Etapele ciclului de viaţă ETAPE OBIECTIVE PRODUSE FINALE

Cerinţe utilizator Definirea problemei Specificaţii cerinţe utilizator Cerinţe software Analiza problemei Cerinţe şi specificaţii software Proiectarea arhitecturii Soluţii de ansamblu Proiect de ansamblu Producţie Implementare Proiect de detaliu,

Software testat Transfer Instalare Software instalat, training clienţi,

debugging Mentenanţă Evoluţie produs software Software întreţinut şi dezvoltat

Modul de grupare al activităţilor percum şi sucesiunea etapelor conduc la diferite modele de implementare ale ciclului de viaţă.

Un model al ciclului de viaţă pentru produse software descrie activitatea de realizare a produsului software şi fluxul procesului de dezvoltare. În decursul timpului au fost elaborate diferite strategii de implementare a conceptului de ciclu de viaţă concretizate în diferite modele: � Modelul în cascadă � Modelul incremental � Modelul evolutiv � Modelul în spirală � Inginerie software bazată pe model

4.1. Modelul în cascadă În mod tradiţional, activitatea de realizare a produsului software este structurată utilizând diferite tipuri ale modelului în cascadă care descrie fluxul procesului de dezvoltare.

Un model tipic în cascadă presupune că dezvoltarea începe cu definirea cerinţelor şi a specificaţiilor, care se pot realiza în secvenţă dar şi alternându-le. Urmează proiectarea care odată terminată se pot implementa module mici care pot fi testate individual, iar apoi împreună; când ultimul test de integrare este complet, întregul produs software poate fi testat şi livrat şi începe etapa de mentenanţă (figura 4.1).

Fiecare etapă a ciclului de viaţă are un scop bine precizat şi presupune unor activităţi specifice. La sfârşitul fiecărei etape se obţin componentele produsului program în diverse stadii de elaborare precum şi documentaţia de realizare a produsului. La trecerea de la o etapă la alta, rezultatele obţinute sunt evaluate şi avizate. Iniţial a existat ideea că o fază trebuie să fie complet terminată pentru a o începe pe următoarea. Acest principiu a fost abandonat

UTILIZARE&MENTENANŢĂ

DEFINIRE CERINŢE

ANALIZA

PROIECTARE

IMPLEMENTARE COD

TESTARE

Fig. 4.1 Modelul în cascadă

Ciclul de viaţă al produselor program 4-3

relativ repede şi s-a convenit ca o fază să poată începe înainte ca precedenta să fie complet terminată. Conţinutul şi rezultatele acestor etape este precizat în continuare.

Definire cerinţe - are ca scop identificarea şi formularea cerinţelor globale privind realizarea produsului program cât şi justificarea necesităţii şi oportunităţii acestuia. Rezultatul etapei este specificarea cerinţelor utilizatorului.

Analiza – are ca scop specificarea cerinţelor funcţionale şi de calitate ale viitorului produs, identificarea mijloacelor tehnice-suport, stabilirea fazelor şi activităţilor de elaborare, a procedurilor de control şi recepţie. Rezultatul etapei este „Tema de Realizare”.

Proiectarea – are drept scop stabilirea arhitecturii şi structurii viitorului produs. Pentru proiectele complexe această etapă se împarte în proiectare preliminară şi proiectare detaliată.

• Proiectarea preliminară are ca scop specificarea detaliată a cerinţelor funcţionale şi de calitate şi proiectarea arhitecturii funcţionale a produsului program. Documentaţia rezultată este „Specificaţia

de Definire”, care conţine: descrierea problemei de rezolvat şi a criteriilor de acceptare de către utilizator; destinaţia produsului; specificarea cerinţelor şi a restricţiilor de realizare; arhitectura produsului program; (funcţionalitate, componente, interfeţe, organizarea logică datelor); definirea formei de livrare, planul de realizare, planul de testare şi omologare. Rezultatul etapei este conţinut în „Proiectul de Ansamblu” sau „Proiectul Logic” al viitorului produs.

• Proiectarea detaliată are ca scop proiectarea structurii fizice a produsului program: module, programe, algoritmii acestora, interfeţe, fluxuri de date şi de control, structuri fizice de date, cât şi pregătirea testării. Rezultatul etapei este „Proiectul de detaliu” sau „Proiectul Fizic” care conţine următoarele documente: „Specificatia de Realizare” ce precizează: structura fizică, descrierea interfeţelor interne şi externe, descrierea componentelor, descriere datelor, condiţii şi restricţii tehnice şi „Specificatia de Testare” pentru testul de integrare care defineşte: planul de testare elaborat în etapa precedentă, cazurile de test, mediul de testare, procedurile de testare.

Elaborarea programelor are ca scop: realizarea modulelor/programelor conform specificaţiilor de realizare şi testare individuală a acestora. Testarea, aici este orientată spre depistarea erorilor de pro-gramare la nivel individual. Rezultatele etapei sunt: fişierele/bibliotecile cu programele/modulele testate individual, raportul de testare individuală şi listinguri martor. În această etapă se elaboreză o formă preliminară pentru „Documentaţia de Intreţinere” care conţine: a) specificatia structurii produsului program şi a documentatiei (lista manualelor şi documentelor însoţitoare, lista componentelor fizice ale produsului, lista componentelor ce se pot utiliza individual; b) descrierea produsului program (descriere funcţională, descrierea structurii, mijloace tehnice utilizate, moduri de apelare, încărcare, utilizare memorie, date de intrare/ieşire); c) textele programelor în limbaj sursă autodocumentate.

Integrarea şi testarea constă în integrarea şi testarea progresivă a produsului program în ansamblu. Testarea, în acest caz, este orientată spre validarea funcţiilor generale şi a performanţelor specificate, a interfeţelor dintre programe ↔ programe, programe ↔ echipamente, programe ↔ utilizator. Rezultatul testării este consemnat în „Raportul de Testare” a integrării ce conţine: scurta descriere a funcţiunilor, condiţiile de efectuare a testării, rezultatele testării, performanţele obtinute. Tot acum se aduc completări la „Documentatia de Intretinere” şi se întocmesc forme preliminare pentru: a) „Manual de Prezentare” care conţine: destinaţia produsului; descrierea problemei şi a metodelor de rezolvare, tipuri de date de intrare/ieşire, lista manualelor, performanţele şi caracteristicile de calitate, informaţii tehnico-comerciale; b) „Manualul de Utilizare” care conţine: destinaţia produsului, proceduri de utilizare (configuraţie, sistem de operare etc), caracteristicile produsului, proceduri de apelare, încărcare, execuţie, date de intrare/ieşire, interacţiunea utilizator-produs, alte informaţii; c) „Manual de Exploatare” care conţine: informaţii generale despre produsul program, structura fizică, procedurile de instalare / adaptare /generare, procedurile de verificare a instalării corecte şi mesajele specifice, modurile de execuţie, mesajele şi dialogul cu utilizatorul.

4-4 Ciclul de viaţă al produselor program

Experimentarea are ca scop verificarea în condiţii reale a functionalităţii şi performanţelor produsului program. Numărul de experimentări este în funcţie de complexitatea şi natura produsului şi se aleg pentru experimentare unitati cât mai reprezentative. Rezultatele experimentării se consemnează într-un „Raport de Experimentare” care conţine: descrierea sumara a produsului program, descrierea condiţiilor concrete de experimentare, evaluarea rezultatelor obţinute, anomaliile constatate şi modul de soluţionare, recomandări de perfecţionare.

Omologarea are ca scop certificarea functionalităţii şi a calităţii produsului program în scopul difuzării sale pe scară largă. Omologarea se desfăşoară pe baza Programei si metodicii de omologare care conţine: obiectul şi scopul omologării, cerinţe cu privire la produs preluate din „Tema de Realizare”, cerinţe cu privire la documentaţie, metodele şi procedurile concrete de omologare, forma de livrare a produsului.

Modelul în cascadă a avut un impact uriaş asupra metodelor ingineriei software şi a fost repede adoptat, chiar înainte de a fi bine descris.

În acest model intrările fiecărei etape sunt ieşirile alteia. Feedback-ul e format din erori care se răsfrâng asupra etapei următoare. Erorile se propagă indirect, în plus intervin costurile modificărilor fapt ce implică necesitatea testării foarte riguroase a fiecărei etape.

Dacă este utilizat în domenii puţin cunoscute se poate lucra mult pentru a acoperi cerinţele, uneori găsite prea târziu, situaţie în care, la nivel conceptual este necesară utilizarea de prototipuri în fazele iniţiale sau de strategii euristice, după caz.

Etapele modelului în cascadă necesită un personal cu pregătire diversă (analişti, programatori etc.) şi se poate spune că este deci o strategie de implementare aproape istorică.

4.2. Modelul incremental

Specific acestui model este faptul că etapele finale sunt realizate în mai mulţi paşi succesivi ceea ce permite obţinerea de versiuni preliminare ale produsului software (figura 4.2).

Modelul incremental are următoarele caracteristici: � analiza şi proiectul de ansamblu (arhitectural) se realizează într-o singură componentă; � proiectarea de detaliu, producţia, transferul şi mentenanţa sunt făcute în mai mulţi paşi succesivi; � elaborarea produsului software în paşi dă posibilitatea verificării dacă producţia va da rezultatele

dorite. � Modelul incremental este mai bun decât modelul în cascadă, necesită mai multă organizare, dar

permite versiuni preliminare ale produsului software pe care se pot verifica calităţile acestuia.

Fig. 4.2 Modelul incremental

Cerinţe utilizator

Cerinţe software

Proiectare arhitecturală

Proiectare de detaliu şi producţie

Transfer

Utilizare şi mentenanţă

timp

Ciclul de viaţă al produselor program 4-5

4.3. Modelul evolutiv

Comparativ cu modelele precedente, acest model, necesită un management mai mare, o organizare mai bună. Este foarte util când specificaţiile iniţiale nu sunt foarte clare sau când se realizează un sistem nou şi nu se pot da specificaţii precise şi complete sau când acestea sunt instabile.

Prin parcurgerea paşilor modelului evolutiv se realizeză un prototip iniţial care în final prin reluarea etapelor (paşilor) ajunge să satisfacă cerinţele clienţilor (figura 4.3). Modelul evolutiv poate fi aplicat printr-o strategie agresivă (sau revoluţionară) care ţine cont de cerinţele pieţei în sensul dezvoltării continue de noi produse sau de noi funcţii, racordate la cerinţele pieţei de produse software.

Bazat pe prototipizare, prin repetarea tuturor etapelor, modelul evolutiv naşte în timp mai îndelungat un produs, dar permite întotdeauna rezolvarea unor noi probleme sau includerea de noi funcţii cerute de piaţa utilizatorilor de produse software.

Adaptat la cerinţele pieţei, modelul evolutiv poate produce o soluţie evolutivă sau, prin strategia agresivă, o soluţie revoluţionară. Prin combinarea acestora şi în funcţie de studiile de piaţă se poate obţine o soluţie intermediară.

Deoarece modelele precedente folosesc noţiuni ca prototipizare şi prototip, vom preciza în continuare sensul acestora.

Prototipizarea este o tehnică de construire şi implementare parţială a unui sistem sau produs software astfel încât cumpărătorul, utilizatorul sau realizatorul să poată învăţa, cunoaşte mai mult despre problemă şi despre soluţionarea acesteia.

Prototipul este util pentru utilizatorul final care va înţelege mai bine ce vrea sau ce se aşteaptă de la produs şi este util pentru realizator pentru a testa unele tehnici, algoritmi aplicaţi, interfeţe realizate etc.

Referitor la prototip există două abordări : � prototip de încercare care trebuie să fie rapid, chiar dacă nu perfect şi care poate fi utilizat pentru validarea interfeţei, pentru particularizarea arhitecturii pentru a cuprinde cerinţele cât mai bine, sau pentru a valida algoritmi particulari; � prototip evolutiv care, dimpotrivă, dezvoltă produsul final astfel încât să se poată aprecia toate caracteristicile de calitate ale produsului software final; în general acest prototip nu poate fi rapid, dar permite îmbunătăţirea modelului prin asigurarea unei calităţi ridicate a produsului software.

timp

Cerinţe utilizator

Cerinţe software

Proiectare arhitecturală

Proiectare de detaliu şi producţie

Transfer

Utilizare şi mentenanţă

Fig. 4.3 Modelul evolutiv

4-6 Ciclul de viaţă al produselor program

4.4. Modelul în spirală Problemele majore în dezvoltarea produselor software apar, în cele mai multe cazuri, în etapa de mentenanţă care în realitate conţine definirea de noi cerinţe de specificare, de analiză, de proiectare.

Au fost dezvoltate în timp o serie de alte modele decât cele descrise anterior, cel mai utilizat actualmente fiind modelul în spirală al lui Boehm care încearcă să soluţioneze problema amintită anterior [JAC 96].

Modelul în spirală (figura 4.4) poate descrie cum un produs se dezvoltă pentru a forma o nouă versiune şi cum o nouă versiune se dezvoltă incremental de la un prototip la un produs complet.

Modelul propune aceleaşi etape de realizare, dar fiecare ciclu de dezvoltare începe prin studiul de

fezabilitate, apoi continuă cu specificarea cerinţelor şi analiza, proiectarea şi implementarea.

Pe de altă parte fiecare din etapele amintite anterior se realizează printr-o succesiune de activităţi: � determinarea obiectivelor etapei, a alternativelor şi restricţiilor; � evaluarea alternativelor, identificarea riscurilor şi rezolvarea lor; � dezvoltarea şi verificarea următorului nivel al produsului; � întocmirea planului următoarei etape, ales pe baza riscurilor.

Atât etapele cât şi activităţile lor componente sunt evaluate având drept criteriu de bază costurile implicate.

Modelul în spirală are următoarele caracteristici: � conţine aproape toate caracteristicile celorlalte modele; � celelalte modele pot fi considerate sau sunt cazuri particulare ale acestuia; � evaluează riscurile oricărei abordări în toate etapele de dezvoltare a produselor software, iar pe

baza acestora alege abordarea corectă.

Dezvoltarea produselor software conţine în mod uzual toate fazele şi activităţile prezentate anterior, chiar dacă ele poartă diferite nume în diferite metodologii şi dezvoltarea decurge incremental pe parcursul acestor etape, scenariu de dezvoltare care se poate aplica indiferent de metoda de realizare utilizată. Putem caracteriza dezvoltarea produsului ca pornind iniţial dintr-o fază nebuloasă, dar care se stabilizează în următorii paşi în subsecvenţe. Metodele de dezvoltare trebuie să ajute ca procesul de dezvoltare să fie stabil pe cât posibil. Se presupune că trebuie lucrat în etapa de analiză până când se va înţelege sistemul în totalitate, dar nu atât de mult încât să considerăm detaliile care vor fi modificate pe parcursul proiectării.

Acest lucru poate însemna că cea mai mare durată este alocată analizei, ceea ce este valabil în unele modelele de implementare a ciclului de viaţă prezentate anterior, cu variaţii de la un model la altul.

Fig. 4.4 Modelul în spirală

V1

PROIECTARE

IMPLEMENTARE &

TESTARE

INDIVIDUALĂ

INTEGRARE

ANALIZĂ

SPECIFICAŢII DE

CERINŢE

VERSIUNE

FINALĂ

V3 V2 V4

Ciclul de viaţă al produselor program 4-7

O împărţire a timpului alocat etapelor proiectului precum şi a relaţiei timp/efort pe etape se poate reprezenta ca în figura 4.5

Iniţial un grup redus de persoane efectuează analiza şi proiectarea. Aceste activităţi se realizează iterativ. Cu cât structura sistemului se stabilizează, un număr mai mare de oameni sunt antrenaţi în implementare şi testare. De obicei activităţile de analiză şi proiectare sunt clarificate atunci când începe testarea, deoarece în acest stadiu nu sunt posibile decât puţine modificări în ceea ce s-a realizat în etapa de analiză şi proiectare.

Dezvoltările din ultimii ani în domeniul tehnologiei informaţiei, mai ales în cel al metodelor şi tehnicilor de realizare a produselor software precum şi în cel al instrumentelor care asistă acest proces în toate etapele sale, au făcut posibile noi abordări ale ciclului de viaţă. Procesul de dezvoltare a sistemelor de informaţii şi a produselor software, văzut ca un proces industrial, presupune, aşa cum s-a amintit anterior, existenţa unor principii, procese şi practici ale ingineriei sistemelor, aplicaţiilor şi produselor program. Toate acestea sunt asigurate prin existenţa unor instrumente software - suport de dezvoltare.

Implementând metodologiile de realizare bazate pe structura funcţională sau pe structura datelor şi/sau metodologiile orientate obiect, instrumentele pentru inginerie software asistată de calculator permit construirea, verificarea, validarea, stocarea şi reutilizarea diferitelor modele componente ale aplicaţiilor şi produselor program.

Asigurând dezvoltarea, începând de la modelele de analiză-proiectare şi până la generarea automată de cod pentru modele, aceste produse pentru inginerie software asigură din punct de vedere calitativ produsele realizate şi permit respectarea şi/sau reducerea termenelor de livrare a produselor.

În ceea ce priveşte costurile, pentru a închide triunghiul amintit, calitate-termene-costuri, e greu de realizat o evaluare globală, acest lucru fiind posibil doar în fiecare caz concret şi la un anumit moment de timp prin balansarea intereselor firmei elaboratoare de software cu cerinţele şi costurile pieţei de software la un moment dat.

Această nouă manieră de dezvoltare a produselor program este denumită inginerie software bazată pe model - Model Based Software Engineering – şi poate fi considerată ca un nou model de implementare a ciclului de viaţă [BRU95].

4.5. Inginerie software bazată pe model

Propune dezvoltarea produsului software pornind de la un model, ceea ce face mai uşoară înţelegerea şi expandarea, construirea acestuia. Pentru aceasta se porneşte de la următoarele tipuri de modele:

Analiza

Proiectare

efort

timp

Implementare

Testare

Fig. 4.5 Diagrama efort-timp

4-8 Ciclul de viaţă al produselor program

• Modele de produse software Modelarea este o formă grafică de programare de nivel foarte înalt. Modelele pot fi simulate şi animate astfel încât să furnizeze feedback-uri şi suport pentru validare, verificare şi evaluarea performanţelor.

• Modele de procese/sisteme Modelele sunt utilizate în toate activităţile ciclului de viaţă. Modelele de procese şi sisteme pot fi construite la fel de bine ca şi cele de produse software.

• Generare de cod pentru modele Modelele pot fi rafinate şi stocate automatizat şi pot fi automat incluse în programe . Mentenanţa este inclusă în modele.

• Modele de mediu (testare) Testarea este realizată prin modelare şi simularea dispozitivelor externe.

Utilizarea modelelor presupune parcurgerea aceloraşi etape ale ciclului de viaţă, fiecare fază însemnând rafinarea modelului din etapa anterioară.

Această strategie permite o validare mult mai consistentă încă din primele etape de dezvoltare a produselor software, dar presupune existenţa acestor modele de obicei cuprinse în produse integrate pentru inginere software asistată de calculator.

Ingineria software bazată pe modele prezintă o importanţă deosebită deoarece: • modelul este o reprezentare abstractă a sistemului considerat, utilizată pentru a-i înţelege mai bine

caracteristicile, pentru a-i studia mai bine proprietăţile; • utilizarea modelelor ajută la formalizarea cerinţelor şi la punerea în evidenţă a inconsistenţei şi

incompletitudinii.

Referitor la produsele software sunt utilizate: modele funcţionale reprezentate prin DFD (diagrame de flux de date), modele de informaţii, de date, reprezentate prin ERD (diagrame entitate-relaţie), modele de

control reprezentate prin DTS (diagrame de tranziţie a stărilor), diagrame PETRI etc.

Din alt punct de vedere modelele pot fi: modele descriptive, care sunt statice şi modele operaţionale

- care sunt dinamice şi pot fi gândite cu date de I/O simulate dând naştere la prototipuri ale sistemului ce pot în acelaşi timp valida proprietăţile acestuia şi pot verifica prestaţiile sale.

Modelele operaţionale şi evolutive pot executa şi testa produse software în fiecare fază astfel încât controlul de calitate şi asigurarea calităţii să acopere ciclul de viaţă în întregime. Sistemul final conform principiului evolutiv şi operaţional va fi ultimul pas dintr-o transformare evolutivă care a îmbogăţit modelul abstract iniţial al sistemului cu detalii şi funcţii progresiv introduse în sistemul construit.

Strategia de dezvoltare bazată pe model necesită existenţa a doi factori cheie: • un limbaj de modelare riguros care să fie utilizat la toate nivelele (analiză, proiectare) şi de către

toţi cei implicaţi (analişti, programatori, utilizatori finali), cu o semantică neambiguă; • tehnologie prezentată astfel încât să poată fi utilizată practic şi să fie însoţită de manuale suport

avansate care să descrie un editor grafic, un generator de cod şi o bază de lucru pentru simulare şi aplicaţii.

Ingineria software bazată pe model presupune pentru oricare din tipurile de modele (funcţional, de date, de control) existenţa unor elemente ca : � formalismul - care implică un set de reguli semantice şi sintactice care să ajute analistul în

construirea descrierii statice; � limbajul - ca executabil sau operaţional al formalismului .

În concluzie, relativ la modalităţile de abordare a ciclului de viaţă pentru produse software, se pot face o serie de comentarii cu privire la efortul de realizare şi distribuirea lui pe etape, cu privire la durata afectată etapelor şi cu privire la costuri şi venituri [KUL 96].

Ciclul de viaţă al produselor program 4-9

Astfel, indiferent de modelul de ciclu de viaţă şi de metodologia de realizare alese, dar mai ales pentru variantele “clasice” ale acestora, se poate spune că fiecare fază din ciclul de realizare a produselor program necesită un efort diferit pentru obţinerea produselor intermediare şi a documentaţiei aferente. Acest efort creşte pînă la mijlocul ciclului de realizare, după care descreşte. O reprezentare grafică pentru variaţia efortului absolut şi cumulat de-a lungul ciclului de realizare ale produselor software este reprezentată în figura 4.7. Se observă că etapele se succed în timp şi se suprapun pe o perioadă mai mare sau mai mică.

Comparativ cu această situaţie, variaţia efortului în timp este diferită la metodele “moderne” faţă de metodele “clasice”. Astfel, dacă în etapa de analiză şi proiectare efortul creşte, în etapele de implementare de cod, integrare, experimentare şi mentenanţă efortul de realizare scade, în cazul noilor abordări. Din figura 4.6 se pot observa tendinţele modificării efortului în timpul de realizare a produselor program.

Fig. 4.6 Modificarea efortului

Efort în trecut

Efort în viitor

Dezvoltare ulterioară

Eliminare efort

TIMP

EFORT

Propunere de proiect

Etapa de proiect de ansamblu

Etapa de proiect de

detaliu

Codificare şi testare

componente

Integrare şi testare ansamblu

Experimentare Utilizare curentă şi

mentenanţă

ANALIZĂ PROIECTARE IMPLEMENTARE ŞI TESTARE UTILIZARE

EFORTURI CUMULATE PE ETAPE 40 % 30 % 30 %

DOCUMENTAŢIE PE ETAPE

TEMA DE REALIZARE

PROIECT LOGIC

PROIECT FIZIC

LISTING SURSĂ DOCUMENTAŢIE

RAPORT DE TESTARE

RAPORT DE EXPERIMENTARE

STUDIU PRELIMINAR

ANALIZA STUDIUL

ORGANIZATORIC

PROIECTARE DE

ANSAMBLU

PROIECTARE DE

DETALIU

PROGRAMARE ŞI

TESTARE COMPONENTE

INTEGRARE ŞI

TESTARE GLOBALĂ

MANAGEMENTUL PROIECTULUI

EXPERIMENTARE (BETA-TESTE)

EXPLOATARE ŞI

MENTENENŢĂ

INIŢIALIZARE

START PROIECT VERIFICARE PREDARE SFÂRŞIT PROIECT

TIMP

Fig. 4.7 Etapele de realizare, produse intermediare, efort absolut şi cumulat în timp

EFORT

Ciclu

l de v

iaţă a

l pro

du

selor p

rogra

m 4

-10

Realizarea produselor program

11

În ceea ce priveşte situaţia cheltuielilor, veniturilor şi profitului implicate de realizarea unui produs software, se poate observa că la începutul ciclului de viaţă apar cheltuieli cu realizarea produsului, iar venituri apar după încheierea ciclul de realizare. În funcţie de volumul vînzărilor se recuperează cheltuielile făcute şi se obţin şi profituri. Ilustrarea grafică a volumului veniturilor şi cheltuielilor precum şi a profitului obţinut se poate vedea în figura 4.8. Se poate observa cum se amortizează cheltuielile în timp şi astfel apare profitul mai devreme şi nu numai după recuperarea totală a cheltuielilor.

De asemenea, reprezentând cheltuielile din etapa de dezvoltare şi veniturile din etapa în care produsul devine marfă se poate concluziona că în mod normal un produs software aduce profit.

Fig. 4.8 Cheltuieli şi venituri

2 4 6 8 10 12 14 16 18

Profit

ETAPELE DE DEZVOLTARE

CICLU DE VIAŢĂ

Volum de desfacere Consum de

realizare

Costuri de finanţare

CHELTUIELI

Etape utilizare şi achiziţionare

( Etape cu venituri)

VENITURI

timp