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

DEFINIRE
CERINŢE

ANALIZA

PROIECTARE

IMPLEMENTARE COD

TESTARE

UTILIZARE&MENTENANŢĂ

Fig. 4.1 Modelul în cascadă

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

Cerinţe utilizator

Cerinţe software

Proiectare arhitecturală

Proiectare de detaliu şi producţie

Transfer

Utilizare şi mentenanţă
timp

Fig. 4.2 Modelul incremental

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

Cerinţe utilizator

Cerinţe software

Proiectare arhitecturală

Proiectare de detaliu şi producţie

Transfer

Utilizare şi mentenanţă

timp

Fig. 4.3 Modelul evolutiv

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

SPECIFICAŢII DE
PROIECTARE CERINŢE

V1 V2 V3 V4 VERSIUNE
IMPLEMENTARE &
FINALĂ
TESTARE
INDIVIDUALĂ

INTEGRARE
Fig. 4.4 Modelul în spirală

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

efort
Testare

Implementare

Proiectare
Analiza

timp
Fig. 4.5 Diagrama efort-timp

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

Dezvoltare
EFORT ulterioară
Efort în
trecut Eliminare
efort

Efort în
viitor

TIMP

Propunere Etapa de Etapa de Codificare şi Integrare Experimentare Utilizare

de proiect proiect de proiect de testare şi testare curentă şi
ansamblu detaliu componente ansamblu mentenanţă

ANALIZĂ PROIECTARE IMPLEMENTARE ŞI TESTARE UTILIZARE

Fig. 4.6 Modificarea efortului

 Ciclul de viaţă al produselor program
EFORTURI CUMULATE PE ETAPE 40 % 30 % 30 %

DOCUMENTAŢIE TEMA DE PROIECT PROIECT LISTING SURSĂ RAPORT DE RAPORT DE

PE ETAPE REALIZARE LOGIC FIZIC DOCUMENTAŢIE TESTARE EXPERIMENTARE

PROGRAMARE INTEGRARE
EFORT PROIECTARE ŞI ŞI
DE TESTARE TESTARE
ANSAMBLU COMPONENTE GLOBALĂ

ANALIZA
STUDIUL EXPERIMENTARE
ORGANIZATORIC (BETA-TESTE)

PROIECTARE
DE
DETALIU EXPLOATARE
STUDIU ŞI
PRELIMINAR MENTENENŢĂ

MANAGEMENTUL PROIECTULUI

INIŢIALIZARE TIMP

VERIFICARE PREDARE SFÂRŞIT

START PROIECT

4-10
PROIECT
Fig. 4.7 Etapele de realizare, produse intermediare, efort absolut şi cumulat în timp
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.
VENITURI

Volum de Profit
Consum de desfacere
realizare

2 4 6 8 10 12 14 16 18
timp

Costuri de finanţare ( Etape cu venituri)

ETAPELE DE Etape utilizare şi achiziţionare

DEZVOLTARE
CICLU DE VIAŢĂ
CHELTUIELI

Fig. 4.8 Cheltuieli şi venituri

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.