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 pn la retragerea sau nlocuirea total a acestuia cu un nou produs software, reprezentnd 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 ncepnd cu dezvoltarea, utilizarea, mentenana i pn la retragerea software-lui. Din punct de vedere al utilizatorilor cele mai importante pri ale ciclului de via sunt utilizarea curent (operaionalitate) i mentenana; 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 construiete 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 funcional, relaiile sale cu mediul, dinamica metodelor, tehnicilor, conceptelor etc. Ciclul de realizare este o noiune derivat din cea de ciclu de via acoperind intervalul dintre momentul deciziei iniiale de realizare i pn la punerea n funciune a produsului software. Acest interval, mprit 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 producie 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 dezvoltrii 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 calitii se poate spune c noiunea de calitate nu nseamn numai testarea acesteia pentru un produs software, ci i construirea i asigurarea calitii n procesele software. Principiile generale sunt : prevenirea defectelor; asigurarea faptului c defectele au fost detectate i corectate ct mai mult posibil; stabilirea i eliminarea cauzelor care produc anumite simptome; audit i conformitate cu standarde i proceduri. n ceea ce privete principiile de management putem aminti: planificarea tuturor activitilor necesare n realizare din punct de vedere al timpului , bugetului, resurselor i restriciilor de calitate. monitorizarea continu, mbuntirea progresiv a planurilor, revizuirea planurilor dac anumite limite de toleran au fost depite. definirea clar a structurii, rolurilor, responsabilitilor i liniilor de comunicaie ntre grupuri sau indivizi, persoane implicate n realizare. Ca principii de inginerie se pot preciza: descrierea clar a problemei - care ntmpin dou tipuri de dificulti majore: - cerinele sunt exprimate de obicei n termenii problemei reale (cerine reale) i trebuie translatate n termenii uzuali contextului software; - utilizatorul nu poate preciza complet cerinele sale sau nu poate s gseasc legtura dintre ele; definirea i selectarea soluiei printr-o clar definire a componentelor; controlul riguros al relaiilor dintre componente.

4-2

Ciclul de via al produselor program

Activitile componente ale ciclul de via al produselor software sunt grupate n mai multe moduri, n etape sau faze. O astfel de grupare a activitilor componente ale ciclului de via este prezentat n tabelul 4.1 [BRU 95]:
Tabelul 4.1 Etapele ciclului de via
ETAPE Cerine utilizator Cerine software Proiectarea arhitecturii Producie Transfer Mentenan OBIECTIVE Definirea problemei Analiza problemei Soluii de ansamblu Implementare Instalare Evoluie produs software PRODUSE FINALE Specificaii cerine utilizator Cerine i specificaii software Proiect de ansamblu Proiect de detaliu, Software testat Software instalat, training clieni, debugging Software ntreinut i dezvoltat

Modul de grupare al activitilor 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 tradiional, activitatea de realizare a produsului software este structurat utiliznd diferite tipuri ale modelului n cascad care descrie fluxul procesului de dezvoltare. Un model tipic n cascad presupune c dezvoltarea ncepe cu definirea cerinelor i a specificaiilor, care se pot realiza n secven dar i alternndu-le. Urmeaz proiectarea care odat terminat se pot implementa module mici care pot fi testate individual, iar apoi mpreun; cnd ultimul test de integrare este complet, ntregul produs software poate fi testat i livrat i ncepe etapa de mentenan (figura 4.1).
DEFINIRE CERINE ANALIZA PROIECTARE IMPLEMENTARE COD TESTARE UTILIZARE&MENTENAN

Fiecare etap a ciclului de via are un scop bine precizat i presupune unor activiti specifice. La sfritul fiecrei etape se obin componentele produsului program n diverse stadii de elaborare precum i documentaia de realizare a produsului. La trecerea de la o etap la alta, rezultatele obinute sunt evaluate i avizate. Iniial a existat ideea c o faz trebuie s fie complet terminat pentru a o ncepe pe urmtoarea. Acest principiu a fost abandonat

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. Coninutul i rezultatele acestor etape este precizat n continuare. Definire cerine - are ca scop identificarea i formularea cerinelor globale privind realizarea produsului program ct i justificarea necesitii i oportunitii acestuia. Rezultatul etapei este specificarea cerinelor utilizatorului. Analiza are ca scop specificarea cerinelor funcionale i de calitate ale viitorului produs, identificarea mijloacelor tehnice-suport, stabilirea fazelor i activitilor de elaborare, a procedurilor de control i recepie. 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 cerinelor funcionale i de calitate i proiectarea arhitecturii funcionale a produsului program. Documentaia rezultat este Specificaia de Definire, care conine: descrierea problemei de rezolvat i a criteriilor de acceptare de ctre utilizator; destinaia produsului; specificarea cerinelor i a restriciilor de realizare; arhitectura produsului program; (funcionalitate, componente, interfee, organizarea logic datelor); definirea formei de livrare, planul de realizare, planul de testare i omologare. Rezultatul etapei este coninut 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, interfee, fluxuri de date i de control, structuri fizice de date, ct i pregtirea testrii. Rezultatul etapei este Proiectul de detaliu sau Proiectul Fizic care conine urmtoarele documente: Specificatia de Realizare ce precizeaz: structura fizic, descrierea interfeelor interne i externe, descrierea componentelor, descriere datelor, condiii i restricii tehnice i Specificatia de Testare pentru testul de integrare care definete: 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 specificaiilor de realizare i testare individual a acestora. Testarea, aici este orientat spre depistarea erorilor de programare la nivel individual. Rezultatele etapei sunt: fiierele/bibliotecile cu programele/modulele testate individual, raportul de testare individual i listinguri martor. n aceast etap se elaborez o form preliminar pentru Documentaia de Intreinere care conine: a) specificatia structurii produsului program i a documentatiei (lista manualelor i documentelor nsoitoare, lista componentelor fizice ale produsului, lista componentelor ce se pot utiliza individual; b) descrierea produsului program (descriere funcional, descrierea structurii, mijloace tehnice utilizate, moduri de apelare, ncrcare, utilizare memorie, date de intrare/ieire); 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 funciilor generale i a performanelor specificate, a interfeelor dintre programe programe, programe echipamente, programe utilizator. Rezultatul testrii este consemnat n Raportul de Testare a integrrii ce conine: scurta descriere a funciunilor, condiiile de efectuare a testrii, rezultatele testrii, performanele obtinute. Tot acum se aduc completri la Documentatia de Intretinere i se ntocmesc forme preliminare pentru: a) Manual de Prezentare care conine: destinaia produsului; descrierea problemei i a metodelor de rezolvare, tipuri de date de intrare/ieire, lista manualelor, performanele i caracteristicile de calitate, informaii tehnico-comerciale; b) Manualul de Utilizare care conine: destinaia produsului, proceduri de utilizare (configuraie, sistem de operare etc), caracteristicile produsului, proceduri de apelare, ncrcare, execuie, date de intrare/ieire, interaciunea utilizator-produs, alte informaii; c) Manual de Exploatare care conine: informaii generale despre produsul program, structura fizic, procedurile de instalare / adaptare /generare, procedurile de verificare a instalrii corecte i mesajele specifice, modurile de execuie, mesajele i dialogul cu utilizatorul.

4-4

Ciclul de via al produselor program

Experimentarea are ca scop verificarea n condiii reale a functionalitii i performanelor produsului program. Numrul de experimentri este n funcie de complexitatea i natura produsului i se aleg pentru experimentare unitati ct mai reprezentative. Rezultatele experimentrii se consemneaz ntr-un Raport de Experimentare care conine: descrierea sumara a produsului program, descrierea condiiilor concrete de experimentare, evaluarea rezultatelor obinute, anomaliile constatate i modul de soluionare, recomandri de perfecionare. Omologarea are ca scop certificarea functionalitii i a calitii produsului program n scopul difuzrii sale pe scar larg. Omologarea se desfoar pe baza Programei si metodicii de omologare care conine: obiectul i scopul omologrii, cerine cu privire la produs preluate din Tema de Realizare, cerine cu privire la documentaie, 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 intrrile fiecrei etape sunt ieirile alteia. Feedback-ul e format din erori care se rsfrng asupra etapei urmtoare. Erorile se propag indirect, n plus intervin costurile modificrilor fapt ce implic necesitatea testrii foarte riguroase a fiecrei etape. Dac este utilizat n domenii puin cunoscute se poate lucra mult pentru a acoperi cerinele, uneori gsite prea trziu, situaie n care, la nivel conceptual este necesar utilizarea de prototipuri n fazele iniiale sau de strategii euristice, dup caz. Etapele modelului n cascad necesit un personal cu pregtire divers (analiti, 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 muli pai succesivi ceea ce permite obinerea de versiuni preliminare ale produsului software (figura 4.2).
Cerine utilizator Cerine software Proiectare arhitectural Proiectare de detaliu i producie Transfer Utilizare i mentenan timp

Fig. 4.2 Modelul incremental

Modelul incremental are urmtoarele caracteristici: analiza i proiectul de ansamblu (arhitectural) se realizeaz ntr-o singur component; proiectarea de detaliu, producia, transferul i mentenana sunt fcute n mai muli pai succesivi; elaborarea produsului software n pai d posibilitatea verificrii dac producia va da rezultatele dorite. Modelul incremental este mai bun dect modelul n cascad, necesit mai mult organizare, dar permite versiuni preliminare ale produsului software pe care se pot verifica calitile 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 cnd specificaiile iniiale nu sunt foarte clare sau cnd se realizeaz un sistem nou i nu se pot da specificaii precise i complete sau cnd acestea sunt instabile. Prin parcurgerea pailor modelului evolutiv se realizez un prototip iniial care n final prin reluarea etapelor (pailor) ajunge s satisfac cerinele clienilor (figura 4.3).
Cerine utilizator Cerine software Proiectare arhitectural

Proiectare de detaliu i producie Transfer Utilizare i mentenan timp

Fig. 4.3 Modelul evolutiv

Modelul evolutiv poate fi aplicat printr-o strategie agresiv (sau revoluionar) care ine cont de cerinele pieei n sensul dezvoltrii continue de noi produse sau de noi funcii, racordate la cerinele pieei de produse software. Bazat pe prototipizare, prin repetarea tuturor etapelor, modelul evolutiv nate n timp mai ndelungat un produs, dar permite ntotdeauna rezolvarea unor noi probleme sau includerea de noi funcii cerute de piaa utilizatorilor de produse software. Adaptat la cerinele pieei, modelul evolutiv poate produce o soluie evolutiv sau, prin strategia agresiv, o soluie revoluionar. Prin combinarea acestora i n funcie de studiile de pia se poate obine o soluie intermediar. Deoarece modelele precedente folosesc noiuni ca prototipizare i prototip, vom preciza n continuare sensul acestora. Prototipizarea este o tehnic de construire i implementare parial a unui sistem sau produs software astfel nct cumprtorul, utilizatorul sau realizatorul s poat nva, cunoate mai mult despre problem i despre soluionarea acesteia. Prototipul este util pentru utilizatorul final care va nelege mai bine ce vrea sau ce se ateapt de la produs i este util pentru realizator pentru a testa unele tehnici, algoritmi aplicai, interfee realizate etc. Referitor la prototip exist dou abordri : prototip de ncercare care trebuie s fie rapid, chiar dac nu perfect i care poate fi utilizat pentru validarea interfeei, pentru particularizarea arhitecturii pentru a cuprinde cerinele ct mai bine, sau pentru a valida algoritmi particulari; prototip evolutiv care, dimpotriv, dezvolt produsul final astfel nct s se poat aprecia toate caracteristicile de calitate ale produsului software final; n general acest prototip nu poate fi rapid, dar permite mbuntirea modelului prin asigurarea unei caliti 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 conine definirea de noi cerine de specificare, de analiz, de proiectare. Au fost dezvoltate n timp o serie de alte modele dect cele descrise anterior, cel mai utilizat actualmente fiind modelul n spiral al lui Boehm care ncearc s soluioneze 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

PROIECTARE

SPECIFICAII DE CERINE

V1 V2 V3 V4
IMPLEMENTARE & TESTARE INDIVIDUAL

VERSIUNE FINAL

INTEGRARE

Fig. 4.4 Modelul n spiral

Modelul propune aceleai etape de realizare, dar fiecare ciclu de dezvoltare ncepe prin studiul de fezabilitate, apoi continu cu specificarea cerinelor i analiza, proiectarea i implementarea. Pe de alt parte fiecare din etapele amintite anterior se realizeaz printr-o succesiune de activiti: determinarea obiectivelor etapei, a alternativelor i restriciilor; evaluarea alternativelor, identificarea riscurilor i rezolvarea lor; dezvoltarea i verificarea urmtorului nivel al produsului; ntocmirea planului urmtoarei etape, ales pe baza riscurilor. Att etapele ct i activitile lor componente sunt evaluate avnd drept criteriu de baz costurile implicate. Modelul n spiral are urmtoarele caracteristici: conine aproape toate caracteristicile celorlalte modele; celelalte modele pot fi considerate sau sunt cazuri particulare ale acestuia; evalueaz riscurile oricrei abordri n toate etapele de dezvoltare a produselor software, iar pe baza acestora alege abordarea corect. Dezvoltarea produselor software conine n mod uzual toate fazele i activitile 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 iniial dintr-o faz nebuloas, dar care se stabilizeaz n urmtorii pai n subsecvene. Metodele de dezvoltare trebuie s ajute ca procesul de dezvoltare s fie stabil pe ct posibil. Se presupune c trebuie lucrat n etapa de analiz pn cnd se va nelege sistemul n totalitate, dar nu att de mult nct s considerm detaliile care vor fi modificate pe parcursul proiectrii. 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 variaii de la un model la altul.

Ciclul de via al produselor program

4-7

O mprire a timpului alocat etapelor proiectului precum i a relaiei timp/efort pe etape se poate reprezenta ca n figura 4.5 efort Testare

Implementare

Analiza

Proiectare timp

Fig. 4.5 Diagrama efort-timp

Iniial un grup redus de persoane efectueaz analiza i proiectarea. Aceste activiti se realizeaz iterativ. Cu ct structura sistemului se stabilizeaz, un numr mai mare de oameni sunt antrenai n implementare i testare. De obicei activitile de analiz i proiectare sunt clarificate atunci cnd ncepe testarea, deoarece n acest stadiu nu sunt posibile dect puine modificri n ceea ce s-a realizat n etapa de analiz i proiectare. Dezvoltrile din ultimii ani n domeniul tehnologiei informaiei, 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 fcut posibile noi abordri ale ciclului de via. Procesul de dezvoltare a sistemelor de informaii i a produselor software, vzut ca un proces industrial, presupune, aa cum s-a amintit anterior, existena unor principii, procese i practici ale ingineriei sistemelor, aplicaiilor i produselor program. Toate acestea sunt asigurate prin existena unor instrumente software - suport de dezvoltare. Implementnd metodologiile de realizare bazate pe structura funcional 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 aplicaiilor i produselor program. Asigurnd dezvoltarea, ncepnd de la modelele de analiz-proiectare i pn 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 privete 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 cerinele i costurile pieei 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 uoar nelegerea i expandarea, construirea acestuia. Pentru aceasta se pornete de la urmtoarele 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 nct s furnizeze feedback-uri i suport pentru validare, verificare i evaluarea performanelor. Modele de procese/sisteme Modelele sunt utilizate n toate activitile 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 . Mentenana este inclus n modele.

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

Utilizarea modelelor presupune parcurgerea acelorai etape ale ciclului de via, fiecare faz nsemnnd rafinarea modelului din etapa anterioar. Aceast strategie permite o validare mult mai consistent nc din primele etape de dezvoltare a produselor software, dar presupune existena 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 nelege mai bine caracteristicile, pentru a-i studia mai bine proprietile; utilizarea modelelor ajut la formalizarea cerinelor i la punerea n eviden a inconsistenei i incompletitudinii. Referitor la produsele software sunt utilizate: modele funcionale reprezentate prin DFD (diagrame de flux de date), modele de informaii, de date, reprezentate prin ERD (diagrame entitate-relaie), modele de control reprezentate prin DTS (diagrame de tranziie a strilor), diagrame PETRI etc. Din alt punct de vedere modelele pot fi: modele descriptive, care sunt statice i modele operaionale - care sunt dinamice i pot fi gndite cu date de I/O simulate dnd natere la prototipuri ale sistemului ce pot n acelai timp valida proprietile acestuia i pot verifica prestaiile sale. Modelele operaionale i evolutive pot executa i testa produse software n fiecare faz astfel nct controlul de calitate i asigurarea calitii s acopere ciclul de via n ntregime. Sistemul final conform principiului evolutiv i operaional va fi ultimul pas dintr-o transformare evolutiv care a mbogit modelul abstract iniial al sistemului cu detalii i funcii progresiv introduse n sistemul construit. Strategia de dezvoltare bazat pe model necesit existena a doi factori cheie: un limbaj de modelare riguros care s fie utilizat la toate nivelele (analiz, proiectare) i de ctre toi cei implicai (analiti, programatori, utilizatori finali), cu o semantic neambigu; tehnologie prezentat astfel nct s poat fi utilizat practic i s fie nsoit de manuale suport avansate care s descrie un editor grafic, un generator de cod i o baz de lucru pentru simulare i aplicaii. Ingineria software bazat pe model presupune pentru oricare din tipurile de modele (funcional, de date, de control) existena 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 operaional al formalismului . n concluzie, relativ la modalitile 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 obinerea produselor intermediare i a documentaiei aferente. Acest efort crete pn la mijlocul ciclului de realizare, dup care descrete. O reprezentare grafic pentru variaia 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 situaie, variaia efortului n timp este diferit la metodele moderne fa de metodele clasice. Astfel, dac n etapa de analiz i proiectare efortul crete, n etapele de implementare de cod, integrare, experimentare i mentenan efortul de realizare scade, n cazul noilor abordri. Din figura 4.6 se pot observa tendinele modificrii efortului n timpul de realizare a produselor program.
Dezvoltare ulterioar Eliminare efort

EFORT Efort n trecut

Efort n viitor

TIMP
Propunere Etapa de Etapa de de proiect proiect de proiect de ansamblu detaliu ANALIZ PROIECTARE Codificare i testare componente Integrare Experimentare i testare ansamblu Utilizare curent i mentenan UTILIZARE

IMPLEMENTARE I TESTARE

Fig. 4.6 Modificarea efortului

Ciclul de via al produselor program

EFORTURI CUMULATE PE ETAPE 40 % DOCUMENTAIE TEMA DE PE ETAPE REALIZARE EFORT PROIECT LOGIC

30 %

30 %

PROIECT LISTING SURS RAPORT DE RAPORT DE EXPERIMENTARE FIZIC DOCUMENTAIE TESTARE

PROGRAMARE I TESTARE COMPONENTE INTEGRARE I TESTARE GLOBAL

PROIECTARE DE ANSAMBLU ANALIZA STUDIUL ORGANIZATORIC

EXPERIMENTARE (BETA-TESTE)

STUDIU PRELIMINAR

PROIECTARE DE DETALIU

EXPLOATARE I MENTENEN

MANAGEMENTUL PROIECTULUI

INIIALIZARE START PROIECT VERIFICARE PREDARE SFRIT PROIECT

TIMP

4-10

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

Realizarea produselor program

11

n ceea ce privete situaia 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 funcie de volumul vnzrilor se recupereaz cheltuielile fcute i se obin i profituri. Ilustrarea grafic a volumului veniturilor i cheltuielilor precum i a profitului obinut 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 desfacere Profit

Consum de realizare

10

12

14

16

18

timp

Costuri de finanare
ETAPELE DE DEZVOLTARE

( Etape cu venituri) Etape utilizare i achiziionare CICLU DE VIA

CHELTUIELI

Fig. 4.8 Cheltuieli i venituri

De asemenea, reprezentnd 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.