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