Universitatea din Bucuresti

Facutatea de Administratie si Afaceri

Specializarea Marketing
Anul II Semestrul II

Proiect Sisteme Informatice in

Marketing
Etapele de dezvolare a unei aplicatii.
Analiza globala.

Albu Andrei
Profesor coordonator :
Conf.Univ.Dr. Cosmin Olteanu

2016

Introducere

n aceast proiect voi prezenta detaliat demersul realizri unei aplicatii, despre ceea ce
trebuie cunoscut i ceea ce trebuie luat n considerare cnd se dezvolta un asemenea program.
Voi trece n revist principiile de design pentru interfee de web siteuri: layout, culori, tipografie
i limitele impuse de tehnologiile web i modul de implementare tehnic a design-urilor. Pe
parcursul lucrrii voi pune accent pe importana accesibilitii aplicatiilor. Voi defini
caracteristicile importante la nivel vizual i tehnic pentru diferite tipuri de aplicatii, clasificate
dup scop. Comportamentul i ateptrile utilizatorilor care navigheaz pe Internet sunt corelate
cu tipurile de aplicatii. Voi vorbi despre cum trebuie s fie redactate textele deoarece o aplicatie
nu se rezum doar la grafic sau design; orice vizitator pune accent pe calitatea coninutului.
Calitatea unei aplicatii se poate determina pe baza aspectelor vizuale, tehnice (programare) i
coninut. Voi face un studiu comparativ pe mai multe web site-uri academice strine i romneti.
Analiza se va efectua la nivel tehnic, vizual i de coninut cu scopul de a extrage concluzii n
vederea realizrii proiectului. Dup aceea voi face o prezentare analiznd aceleai aspecte ale
aplicatiei .
Programul informatic este reprezentarea sau implementarea unui algoritm ntr-un cod
surs, scris ntr-un anumit limbaj de programare. O colecie de programe individuale alctuite
pentru ndeplinirea unui scop comun se numete de obicei software. Programul este un produs
finit al activitii de programare informatic. Considerat formal, un program informatic este un
transformator de aseriuni ce descriu proprietile datelor corecte: att ale datelor de intrare n
sistem, ct i cele ale datelor de ieire din sistem. De obicei programele se creeaz pentru un
anumit tip de calculator sau aparat inteligent. Tot de obicei, o condiie pentru funcionare este
i ca pe calculator s existe un sistem de operare (SO).
Pentru ca un program s fie eficient (de ex. s livreze rezultatele n scurt timp), el trebuie
s aib la baz un algoritm eficient, iar tehnicile de implementare i programare s fie i ele
eficiente.
Sarcinile i funciile programelor au crescut i cresc permanent, simultan cu
dezvoltarea hardului i a sistemelor de operare. i totui, pentru rezolvarea unor probleme
complexe nu este suficient un singur program. Este nevoie de mai multe programe, care atunci,
mpreun, se numesc aplicaie.

Un program de calculator este format dintr-un ir de instruciuni alese dintr-un set

predefinit de instruciuni (numit limbaj de programare) prin care se comunic unui calculator, n
mod detaliat, care anume operaii i n ce ordine trebuie s efectueze. Cnd sunt scrise de
oameni, de obicei de ctre programatori specializai, irul de instruciuni se numete cod surs.
De obicei persoana care scrie programul folosete fie un editor text (pentru un program
simplu), fie un mediu integrat de dezvoltare.
Multe limbaje de programare cer ca, dup creare, sursa s fie transformat ntr-un alt
format, prelucrabil direct de ctre calculator, numit de obicei cod obiect, cod main sau i cod
binar. Acest proces de transformare al codului neles de oameni ntr-unul neles de calculator
poate fi de tip compilare sau de tip interpretare.
Asadar o aplicatie este un program (sau un pachet de programe) destinat dezvoltarii unor
probeme concrete si specifice , producerii unor rapoarte specfice , unor fisiere specifice necesare
rezolvarii ceritelor unuia sau a mai multor utilizatori .

Notiuni teoretice

tiina calculatoarelor este un domeniu relativ nou. Primele calculatoare au fost construite
la mijlocul anilor 1940 i de atunci au avut loc dezvoltri spectaculoase. n anul 1946 Goldstine
i von Neumann apreciau c 1000 de instruciuni reprezint o limit superioar rezonabil pentru
complexitatea problemelor ce pot fi concepute ca rezolvabile cu ajutorul calculatorului. Dup ce
a prevzut n 1981 c nici un program pentru calculatoare personale nu va necesita vreodat mai
mult de 640 KB de memorie RAM, Bill Gates admitea n 1995 c lucrurile s-au schimbat n
ultimele dou decenii.
Urmtoarele exemple ofer o imagine asupra gradului de complexitate la care au ajuns
programele n zilele noastre1 : - Un sistem de control al navetelor spaiale include aproximativ
25 milioane linii de cod i un efort pentru dezvoltare de 22.000 man-years (unitate de msur
pentru costul dezvoltrii software ex., dac un program presupune efortul a 100 de persoane iar
finalizarea dezvoltrii necesit 2 ani atunci costul total de dezvoltare va fi de 200 man-years); Un sistem de control al traficului aerian include aproximativ 1 milion de linii de cod i
1600 man-years pentru scriere i 500 man-years pentru dezvoltare; - Majoritatea produselor
software dezvoltare astzi, din cauza complexitii, nu pot fi pe deplin nelese de ctre o singur
persoan; - Testarea programelor reprezint o problem de imposibilitate (un program tipic, de

nivel mediu, avnd 100 de posibile intrri, 2100 posibile stri va presupune 1020 ani
presupunnd efectuarea a 100 de teste pe secund) nu e de mirare c apar bug-uri tot timpul.
Astfel, n anul 1968, apare termenul de ingineria programrii. Prin acest termen se dorea
ca arta programrii s mprumute din rigoarea tiinelor inginereti pentru a putea livra programe
la timp i n mod economic. Prima definiie dat ingineriei programrii a fost enunat astfel (F.
L. Bauer): Ingineria programrii este stabilirea i utilizarea de principii inginereti solide pentru a
obine n mod economic programe sigure i care funcioneaz eficient pe maini de calcul reale.
Astzi ingineria programrii este vzut ca abordarea sistematic a dezvoltrii, funcionrii,
ntreinerii i retragerii din funciune a programelor (cf. IEEE Standard Glossary of Software
Engineering Technology, 1983).
Aceast viziune nu face referiri la cost sau la eficien, ns adaug referiri la perioade
importante din viaa unui program, ce urmeaz crerii i funcionrii, i anume ntreinerea i
retragerea din funcionare. Ingineria software urmrete toate aspectele privind producia
software de la primele stagii ale specificaiilor de sistem i pn la mentenana sistemului dup
ce a fost dat n funciune. innd cont de toate cerinele organizaionale i de restriciile
financiare ale unei organizaii, ingineria software definete teorii, metode i instrumente de lucru
al cror numr sporete continuu i care devin tot mai complexe datorit ncercrilor de a
descoperi noi soluii la problemele specifice unor organizaii Considerm c ingineria
programrii are urmtoarele caracteristici importante: - este aplicabil n producerea de programe
mari; - este o tiin inginereasc; - scopul final este ndeplinirea cerinelor clientului.
Programele mici se pot scrie relativ uor, de ctre un singur programator, ntr-o perioad destul
de scurt de timp. Un program de 100 de instruciuni este cu siguran un program mic. Nu
putem identifica precis grania dintre un program mic i unul mare, ns pe msur ce
dimensiunea programului crete, apar provocri noi, calitativ diferite. ntruct un singur sau
civa programatori nu pot avea timpul fizic pentru terminarea programului, este necesar
crearea uneia sau mai multor echipe de lucru. Este necesar coordonarea i comunicarea ntre
echipe.
Complexitatea sistemului software i a organizaiei care realizeaz sistemul software
devine important, putnd depi capacitatea de nelegere a unui singur individ. Apare ca
dezirabil o abordare riguroas a acestor probleme, ce include stilul de lucru, modul de scriere a
codului, instrumente adecvante pentru dezvoltarea programelor. Alegerea instrumentelor de
dezvoltare adecvate n funcie de scopul i natura proiectului software devine cel puin la fel de
important precum alegerea unor stiluri de lucru sau metode de dezvoltare adecvate pentru c ele
sunt interdependente.
Introducerea unora dintre cele mai frecvent utilizate instrumente pentru dezvoltarea
programelor reprezint de altfel scopul acestui curs. Spunem c un produs software reprezint
programe i documentaia aferent. Produsele software pot fi generice (off-the-shelf)
dezvoltate pentru a fi vndute mai multor clieni - sau specifice (custom) dezvoltate pentru a fi
vndute unui singur client, conform cu specificaia acestuia. Un program bun este acela care: Ofer utilizatorilor funcionalitile cerute; - Este uor de meninut programul trebuie s
evolueze odat cu schimbarea nevoilor utilizatorilor; - Este sigur (nu conine defecte de

funcionare sau defectele sunt remediate imediat ce sunt descoperite de ctre productor); - Este
eficient (nu irosete resurse ale sistemului); - Este uor de folosit. Spunem c un program este
fiabil dac funcioneaz i continu s funcioneze fr ntreruperi un interval de timp.
Aceast noiune exprim de fapt rezistena la condiiile de funcionare.Un motor trebuie
s fie fiabil pentru c trebuie s funcioneze o perioad suficient de lung de timp fr
ntreruperi, chiar dac nu totdeauna la performane optime. Programul este sigur dac
funcioneaz corect, fr operaii nedorite. Un automat bancar trebuie s fie sigur, pentru a
efectua tranzaciile n mod absolut corect, chiar dac funcionarea sa poate fi ntrerupt din cnd
n cnd.
Atunci cnd funcioneaz ns, trebuie s funcioneze foarte bine. 4 Un program are o
eroare (engl. bug) dac nu se comport corect. Se presupune c dezvoltatorul tia ce ar fi
trebuit programul s fac, iar comportamentul greit nu este intenionat. Iat cteva erori
celebre34: - n primii ani n care calculatoarele au fost introduse la staiile de benzin din SUA,
consumatorii primeau cecuri pe sume enorme. Faptul era privit n general cu umor i reclamaiile
erau rezolvate repede; - Sistemul de operare IBM OS360 coninea aproximativ 1.000 de greeli
la fiecare nou versiune care ncerca s rezolve greelile din versiunea precedent; - Un vehicul
de explorare a planetei Venus a fost pierdut deoarece programul primit de pe Pmnt pentru
rectificarea orbitei coninea linia 'DO 3 I = 1.3'; instruciunea corect n limbajul FORTRAN ar fi
trebuit s conin virgul n loc de punct; - n 1979 s-a descoperit o eroare n programele pentru
sistemele de rcire n centralele nucleare din SUA; din fericire, nu fusese niciodat nevoie de
execuia rutinelor ce conineau erorile; - Din cauza unei erori n sistemul de avertizare mpotriva
atacului cu rachete balistice, procedurile de contraatac au fost declanate nainte de a se
descoperi c a fost o eroare; - Racheta Arianne 5 a explodat n iunie 1996 din cauza unei greeli
de programare; costurile s-au ridicat la 500 milioane dolari. Procesul software presupune
folosirea unor tehnici i instrumente adecvate avnd n vedere: - Problema care trebuie rezolvat;
- Restriciile impuse; - Resursele disponibile.
Exist patru faze fundamentale ale metodologiilor ingineriei programrii: - analiza (ce
dorim s construim); - proiectarea (cum vom construi); - implementarea (construirea propriuzis); - testarea (asigurarea calitii). Dei aceste faze se refer n mod special la ciclul de via al
produsului software, ele pot fi aplicate i altor stadii de existen prin care trece un program de la
natere pn la moarte: lansare, ntreinere, ieire din uz. 1. Faza de analiz Aceast faz
definete cerinele sistemului, independent de modul n care acestea vor fi ndeplinite. Aici se
definete problema pe care clientul dorete s o rezolve. Rezultatul acestei faze este documentul
cerinelor, care trebuie s precizeze clar ce trebuie construit.
Documentul ncearc s redea cerinele din perspectiva clientului, definind scopurile i
interaciunile la un nivel descriptiv nalt, independent de detaliile de implementare, cum ar fi, de
exemplu: formularea problemei, ateptrile clientului sau criteriile pe care trebuie s le
ndeplineasc produsul. Grania dintre descrierile de nivel nalt i cele de nivel sczut nu este
foarte bine trasat. Uneori, dac un detaliu tehnic important trebuie specificat, el va aprea n
document. Totui, aceasta trebuie s fie excepia i nu regula.

Aceste excepii pot fi determinate de necesitatea meninerii compatibilitii cu alte

sisteme deja existente, sau a unor anumite opiuni dorite de client, de exemplu utilizarea unui
anumit standard sau o constrngere asupra dimensiunilor imaginii aplicaiei, care poate fi
destinat unei categorii speciale de utilizatori sau care va rula pe nite sisteme cu o serie de
particulariti (monitoare care nu suport rezoluii mari). Faza de analiz poate fi vzut ca o
rafinare a detaliilor. Distincia dintre detaliile de nivel nalt i cele de nivel sczut sunt puse mai
bine n eviden de abordrile top-down (unde se merge ctre detaliile de nivel sczut) i bottomup (care tind ctre detaliile de nivel nalt). Documentul cerinelor poate fi realizat ntr-o manier
formal, bazat pe logic matematic, sau poate fi exprimat n limbaj natural.n mod tradiional,
el descrie obiectele din sistem i aciunile care pot fi realizate cu ajutorul obiectelor.Aici noiunea
de obiect nu trebuie confundat cu obiectul din programarea orientat obiect.
Descrierea obiectelor i aciunilor trebuie s fie general i s nu depind de o anumit
tehnologie. Desigur, ntr-o abordare POO, descrierile vor lua forma obiectelor i metodelor, ns
n alte abordri, obiectele pot fi de exemplu servicii care acceseaz baze de date. n general,
documentul cerinelor descrie ontologia proiectului, adic vocabularul de cuvinte cheie (n
special construcii substantivale i verbale) care va fi utilizat pentru definirea protocolului
specific aplicaiei. Descrierile acestea nu implic proiectarea arhitecturii aplicaiei, ci enumerarea
prilor componente i a modului n care acestea se comport.Mai trziu, n faza de proiectare,
acestea vor fi transformate n primitive informatice, precum liste, stive, arbori, grafuri, algoritmi
i structuri de date. Mai concret, documentul trebuie s conin descrieri pentru urmtoarele
categorii: - Obiecte: Documentul trebuie s defineasc mai nti ontologia sistemului, care este
bazat n mare parte pe construcii substantivale pentru identificarea pieselor, prilor
componente, constantelor, numelor i a relaiilor dintre acestea; - Aciuni:
Documentul trebuie s defineasc de asemenea aciunile pe care trebuie s le
ndeplineasc sistemul i care sunt sugerate n general de construcii verbale. Exemple de aciuni
sunt: metodele, funciile sau procedurile; - Stri: Sunt definite ca mulimi de setri i valori care
disting sistemul ntre dou ipostaze spaio-temporale. Fiecare sistem trece printr-o serie de
schimbri de stare. Exemple de stri sunt: starea iniial, cea final sau strile de eroare. Cele mai
multe stri depind de domeniul problemei.Strile sunt asociate cu obiectele sistemului.
Un eveniment declaneaz o tranziie de stare care poate conduce la ndeplinirea unei
aciuni de ctre sistem; 6 - Scenarii tipice: Un scenariu este o secven de pai urmai pentru
ndeplinirea unui scop. Cnd sistemul este terminat i aplicaia este disponibil, clientul trebuie
s poat utiliza, ntr-o manier ct mai facil i clar specificat, toate scenariile tipice ale
aplicaiei. Scenariile tipice trebuie s reprezinte majoritatea scenariilor de utilizare ale aplicaiei.
Ponderea acestora variaz de la un sistem la altul, dar 90% se consider o proporie acceptabil.
Bineneles c un sistem cu un singur scenariu de utilizare este relativ simplu de obinut, pe cnd
unul cu mii de scenarii posibile va fi mult mai dificil de analizat. Deseori este invocat regula
80/20: 80% din funcionalitatea sistemului se realizeaz cu 20% din efortul de munc.
Executarea restului minoritar de funcionalitate necesit marea majoritate a timpului de lucru; Scenarii atipice:

Un scenariu atipic trebuie s fie ndeplinit de sistem numai n cazuri speciale. Clientul
poate s spere, de exemplu, c o eroare neprevzut este un eveniment atipic. Totui, sistemul
trebuie s gestioneze un numr ct mai mare de categorii de erori, prin tehnici stabilite, precum
handler-ele de excepii, monitorizarea proceselor etc.; - Cerine incomplete sau nemonotone: O
enumerare complet a cerinelor pentru toate situaiile care pot aprea n condiii de lucru reale
nu este posibil. n logica tradiional, o teorie este definit de o mulime finit de axiome.
Teoremele din teoria respectiv sunt propoziii adevrate.
Dac se adaug ulterior noi axiome, teoremele existente rmn valide iar noile teoreme
dezvoltate sunt adugate teoremelor stabilite. n logica nemonoton, adugarea de noi axiome
poate invalida unele teoreme care au fost demonstrate anterior. O nou teorie nu mai este o
simpl extensie a teoriei vechi, ci o mulime de teoreme noi, mpreun cu o parte din teoremele
vechi. Procesul de stabilire a cerinelor are o natur iterativ i nemonoton. Mulimea iniial de
cerine (axiomele) definete posibilitile (teoremele) sistemului.Noile cerine pot infirma
soluiile vechi.
Pe msur ce un sistem crete n dimensiuni i complexitate, stabilirea cerinelor devine
din ce n ce mai dificil, mai ales cnd procesul de colectare a cerinelor este distribuit, fiind
realizat de indivizi cu specializri diferite. 2. Faza de proiectare Pe baza cerinelor din faza de
analiz, acum se stabilete arhitectura sistemului: componentele sistemului, interfeele i modul
lor de comportare: - Componentele sunt blocurile de construcie ale produsului. Acestea pot fi
create de la zero sau reutilizate dintr-o bibliotec de componente. Componentele rafineaz i
captureaz semnificaia detaliilor din documentul cerinelor; - Interfeele ajut la mbinarea
componentelor. O interfa reprezint grania dintre dou componente, utilizat pentru
comunicarea dintre acestea. Prin intermediul interfeei, componentele pot interaciona; Comportamentul, determinat de interfa, reprezint rspunsul unei componente la stimulii
aciunilor altor componente.Documentul de proiectare descrie planul de implementare a
cerinelor. Se identific detaliile privind limbajele de programare, mediile de dezvoltare,
dimensiunea memoriei, platforma, algoritmii, structurile de date, definiiile de tip globale,
interfeele, etc. 7
n aceast faz trebuie indicate i prioritile critice pentru implementare. Acestea
sugereaz sarcinile care, dac nu sunt executate corect, conduc la eecul sistemului. Totui, chiar
dac prioritile critice sunt ndeplinite, acest fapt nu duce automat la succesul sistemului, ns
crete nivelul de ncredere c produsul va fi o reuit. Folosind scenariile tipice i atipice, trebuie
realizate compromisurile inerente ntre performan i complexitatea implementrii. Analiza
performanelor presupune studierea modului n care diferitele arhitecturi conduc la diferite
caracteristici de performan pentru fiecare scenariu tipic. n funcie de frecven de utilizare a
scenariilor, fiecare arhitectur va avea avantaje i dezavantaje. Un rspuns rapid la o aciunea a
utilizatorului se realizeaz deseori pe baza unor costuri de resurse suplimentare: indeci,
managementul cache-ului, calcule predictive etc.
Dac o aciune este foarte frecvent, ea trebuie realizat corect i eficient. O aciune mai
rar trebuie de asemenea implementat corect, dar nu este evident care e nivelul de performan
necesar n acest caz. O situaie n care o astfel de aciune trebuie implementat cu performane

maxime este nchiderea de urgen a unui reactor nuclear. Planul de implementare i planul de
test pot fi considerate i ca aparinnd fazelor de implementare i respectiv testare. ns unul din
scopurile fazei de proiectare este stabilirea unui plan pentru terminarea sistemului. Planul de
implementare stabilete programul dup care se va realiza implementarea i resursele necesare
(mediul de dezvoltare, editoarele, compilatoarele etc.). Planul de test definete testele necesare
pentru stabilirea calitii sistemului. Dac produsul trece toate testele din planul de test, este
declarat terminat. Cu ct testele sunt mai amnunite, cu att este mai mare ncrederea n sistem
i deci crete calitatea sa. Un anume test va verifica doar o poriune a sistemului. Acoperirea
testului reprezint procentajul din produs verificat prin testare. n mod ideal, o acoperire de
100% ar fi excelent, ns este rareori ndeplinit.
De obicei, un test cu o acoperire de 90% este simpl, ns ultimele 10% necesit o
perioad de timp semnificativ. De exemplu, s considerm BIOS-ul (Basic Input/Output
System) construit de IBM la nceputul anilor 80 n strns legtur cu sistemul de operare DOS
(Disk Operating System) al firmei Microsoft. Din raiuni de performan, BIOS-ul a fost plasat
ntr-un chip ROM, i deci patch-urile pentru eventualele erori erau imposibile. Astfel, au fost
necesare teste cu acoperire de 100%.Codul propriu-zis al BIOS-ului era destul de mic, cteva mii
de linii. ns deoarece BIOS-ul are o natur asincron, testul a presupus mai nti crearea unui
mediu asincron care s aduc sistemul n starea dorit i apoi trebuia generat un eveniment care
s declaneze un test. Foarte repede, setul de test a devenit mult mai mare dect BIOS-ul.A
aprut astfel problema testrii nsui a mediului de test! n final, o acoperire de 100% a fost
atins, dar cu un cost foarte ridicat. O soluie mai ieftin a fost nscrierea BIOS-ului ntr-o
combinaie dintre EPROM (Electronic Programmable Read Only Memory) i ROM. Cea mai
mare parte a produsului era plasat n ROM, iar patch-urile erau plasate n EPROM. Aceasta a fost
abordarea adoptat de Apple pentru Macintosh. n general, este suficient ca testele s cuprind
scenariile tipice i atipice, fr s verifice ntregul sistem, cu absolut toate firele de execuie.
Acesta poate conine ramificaii interne, erori sau ntreruperi care conduc la fire de
execuie netestate.Majoritatea sistemelor sunt pline de bug-uri nedescoperite.De obicei, clientul
particip n 8 mod logic la testarea sistemului i semnaleaz erori care vor fi ndeprtate n
versiunile ulterioare. 3. Faza de implementare n aceast faz, sistemul este construit, ori plecnd
de la zero, ori prin asamblarea unor componente pre-existente. Pe baza documentelor din fazele
anterioare, echipa de dezvoltare ar trebui s tie exact ce trebuie s construiasc, chiar dac
rmne loc pentru inovaii i flexibilitate. De exemplu, o component poate fi proiectat mai
restrns, special pentru un anumit sistem, sau mai general, pentru a satisface o direcie de
reutilizare.
Echipa trebuie s gestioneze problemele legate de calitate, performan, biblioteci i
debug. Scopul este producerea sistemului propriu-zis. O problem important este ndeprtarea
erorilor critice. ntr-un sistem exist trei tipuri de erori: - Erori critice: mpiedic sistemul s
satisfac n mod complet scenariile de utilizare. Aceste erori trebuie corectate nainte ca sistemul
s fie predat clientului i chiar nainte ca procesul de dezvoltare ulterioar a produsului s poat
continua; - Erori necritice: Sunt cunoscute, dar prezena lor nu afecteaz n mod semnificativ
calitatea observat a sistemului.

De obicei aceste erori sunt listate n notele de lansare i au modaliti de ocolire bine
cunoscute; - Erori necunoscute: Exist ntotdeauna o probabilitate mare ca sistemul s conin un
numr de erori nedescoperite nc. Efectele acestor erori sunt necunoscute. Unele se pot dovedi
critice, altele pot fi rezolvate cu patch-uri sau eliminate n versiuni ulterioare. 4. Faza de testare
Calitatea produsului software este foarte important. Multe companii nu au nvat ns acest
lucru i produc sisteme cu funcionalitate extins, dar cu o calitate sczut. E mai simplu s-i
explici clientului de ce lipsete o anumit funcie dect s-i explici de ce produsul nu este
performant. Un client satisfcut de calitatea produsului va rmne loial firmei i va atepta noile
funcii n versiunile urmtoare. n multe metodologii ale ingineriei programrii, faza de testare
este o faz separat, realizat de o echip diferit dup ce implementarea s-a terminat. Motivul
este faptul c un programator nu-i poate descoperi foarte uor propriile greeli. O persoan nou
care privete codul poate descoperi greeli evidente care scap celui care citete i recitete
materialul de multe ori.
Din pcate, aceast practic poate determina o atitudine indiferent fa de calitate n
echipa de implementare. Tehnicile de testare sunt abordate preponderent din perspectiva
productorului sistemului. n mod ideal, i clientul trebuie s joace un rol important n aceast
faz. Testele de regresiune (engl. regression test) sunt colecii de programe care testeaz una
sau mai multe trsturi ale sistemului. Rezultatele testelor sunt adunate i dac exist erori, bugul este corectat. Un test de regresiune valid genereaz rezultate verificate, numite standardul de
aur. Validitatea rezultatului unui test ar trebui s fie determinat 9 de documentul cerinelor. n
practic, echipa de implementare este responsabil de interpretarea validitii. Testele sunt
colectate, mpreun cu rezultatele standardelor de aur, ntr-un pachet de test de regresiune. Pe
msur ce dezvoltarea continu, sunt adugate mai multe teste noi, iar testele vechi pot rmne
valide sau nu. Dac un test vechi nu mai este valid, rezultatele sale sunt modificate n standardul
de aur, pentru a se potrivi ateptrilor curente. Pachetul de test este rulat din nou i genereaz noi
rezultate. Acestea sunt comparate cu rezultatele standardelor de aur. Dac sunt diferite, n sistem
a aprut o greeal. Greeala este corectat i dezvoltarea continu. Acest mecanism detecteaz
situaiile cnd starea curent de dezvoltare a produsului invalideaz o stare existent. Astfel, se
previne regresiunea sistemului ntr-o stare de eroare.Exist patru puncte de interes n testele de
regresiune pentru asigurarea calitii.
Testarea intern trateaz implementarea de nivel sczut. Fiecare funcie sau component
este testat de ctre echipa de implementare. Aceste teste se mai numesc teste clear-box sau
white-box, deoarece toate detaliile sunt vizibile pentru test. Testarea unitilor testeaz o
unitate ca un ntreg. Aici se testeaz interaciunea mai multor funcii, dar numai n cadrul unei
singure uniti. Testarea este determinat de arhitectur. De multe ori sunt necesare aa-numitele
schele, adic programe special construite pentru stabilirea mediului de test. Numai cnd
mediul este realizat se poate executa o evaluare corect. Programul schel stabilete stri i
valori pentru structurile de date i asigur funcii externe fictive. De obicei, programul schel nu
are aceeai calitate ca produsul software testat i adesea este destul de fragil. O schimbare mic
n test poate determina schimbri importante n programul schel. Aceste teste se mai numesc
teste black-box deoarece numai detaliile interfeei sunt vizibile pentru test.Testarea intern i a
unitilor poate fi automatizat cu ajutorul instrumentelor de acoperire (engl. coverage tools),

care analizeaz codul surs i genereaz un test pentru fiecare alternativ a firelor execuie.
Depinde de programator combinarea acestor teste n cazuri semnificative care s valideze
rezultatelor fiecrui fir de execuie.
De obicei, instrumentul de acoperire este utilizat ntr-un mod oarecum diferit: el
urmrete liniile de cod executate ntr-un test i apoi raporteaz procentul din cod executat n
cadrul testului. Dac acoperirea este mare i liniile surs netestate nu prezint mare importan
pentru calitatea general a sistemului, atunci nu mai sunt necesare teste suplimentare. Testarea
aplicaiei testeaz aplicaia ca ntreg i este determinat de scenariile echipei de analiz. Aplicaia
trebuie s execute cu succes toate scenariile pentru a putea fi pus la dispoziia clientului. Spre
deosebire de testarea intern i a unitilor, care se face prin program, testarea aplicaiei se face
de obicei cu scripturi care ruleaz sistemul cu o serie de parametri i colecteaz rezultatele. n
trecut, aceste scripturi erau create manual. n prezent, exist instrumente care automatizeaz i
acest proces.Majoritatea aplicaiilor din zilele noastre au interfee grafice (GUI).Testarea
interfeei grafice pentru asigurarea calitii poate pune anumite probleme. Cele mai multe
interfee, dac nu chiar toate, au bucle de evenimente, care conin cozi de mesaje de la mouse,
tastatur, ferestre etc.
Asociate cu fiecare eveniment sunt coordonatele ecran. Testarea interfeei presupune deci
memorarea tuturor acestor informaii i elaborarea unei modaliti prin care mesajele s fie
trimise din nou aplicaiei, la un moment ulterior. 10 Testarea la stres determin calitatea aplicaiei
n mediul su de execuie. Ideea este crearea unui mediu mai solicitant dect cel n care aplicaia
va rula n mod obinuit. Aceasta este cea mai dificil i complex categorie de teste. Sistemul
este supus unor cerine din ce n ce mai numeroase, pn cnd acesta cade. Apoi produsul este
reparat i testul de stres se repet pn cnd se atinge un nivel de stres mai ridicat dect nivelul
ateptat de pe staia clientului. Deseori apar aici conflicte ntre teste. Fiecare test funcioneaz
corect atunci cnd este fcut separat. Cnd dou teste sunt rulate n paralel, unul sau ambele teste
pot eua. Cauza este de obicei managementul incorect al accesului la resurse critice. Mai apar i
probleme de memorie, cnd un test i aloc memorie i apoi nu o mai dezaloc. Testul pare s
funcioneze corect, ns dup ce este rulat de mai multe ori, memoria disponibil se reduce iar
sistemul cade. 2. Metodologii de dezvoltare a programelor Cnd pornim la dezvoltarea unui
program avem nevoie de: - nelegere clar a ceea ce se cere; - un set de metode i instrumente de
lucru; - un plan de aciune. Planul de aciune se numete metodologie de dezvoltare.
Dezvoltarea unui anumit program const ntr-un set de pai ce se fac pentru a-l realiza.
Lund n considerare tipul pailor ce se efectueaz se creeaz un model de lucru, ce poate fi
aplicat unei serii mai largi de proiecte. Acesta este motivul pentru care planul de aciune este
numit model: el poate fi privit ca un ablon al dezvoltrii de programe. n timpul dezvoltrii
programelor s-a constatat c exist anumite tipuri de activiti care trebuie fcute la un moment
dat: Analiza cerinelor: Se stabilete ce anume vrea clientul ca programul s fac. Scopul este
nregistrarea cerinelor ntr-o manier ct mai clar i mai fidel. Claritatea se refer la lipsa
ambiguitii iar fidelitatea la nregistrarea ct mai exact (posibil cuvnt cu cuvnt); - Proiectarea
arhitectural: Din motive de complexitate, programele mari nu pot fi concepute i implementate

ca o singur bucat. Programul va trebui construit aadar din module sau componente.
Proiectarea arhitectural mparte sistemul ntr-un numr de module mai mici i mai simple, care
pot fi abordate individual; - Proiectarea detaliat: Se realizeaz proiectarea fiecrui modul al
aplicaiei, n cele mai mici detalii; - Scrierea codului: Proiectul detaliat este transpus ntr-un
limbaj de programare. n mod tipic, aceasta se realizeaz modular, pe structura rezultat la
proiectarea arhitectural; - Integrarea componentelor: Modulele programului sunt combinate n
produsul final.
Rezultatul este sistemul complet. n modelul numit big-bang componentele sunt
dezvoltate i testate individual. Apoi ele sunt integrate n sistemul final. Avnd n vedere c
funcionarea corect a componentelor individuale a fost testat, integrarea 11 ar trebui s fie o
formalitate. Din pcate, componentele nu pot fi testate exhaustiv, iar cnd acestea lucreaz
mpreun pot s apar situaii pe care o anumit component nu le-a ntlnit n procesul de
testare sau conflicte ntre anumite componente (de exemplu, conflicte de partajare a resurselor).
S-a constatat c atunci cnd se aplic acest model, timpul de testare explodeaz, proiectul
devenind greu de controlat.Aceasta justific denumirea de big-bang. Modelul incremental
propune crearea unui nucleu al aplicaiei i integrarea a cte o component la un moment dat,
urmat imediat de testarea sistemului obinut. Astfel, se poate determina mai uor unde anume
apare o problema n sistem. Acest tip de integrare ofer de obicei rezultate mai bune dect
modelul big-bang; - Validarea: n procesul de validare ne asigurm c programul ndeplinete
cerinele utilizatorului. ntrebarea la care rspundem este: construim produsul corect? Un
exemplu de validare este testul de acceptare, n care produsul este prezentat clientului. Clientul
spune dac este mulumit cu produsul sau dac mai trebuie efectuate modificri; - Verificarea: n
procesul de verificare ne asigurm c programul este stabil i c funcioneaz corect din punctul
de vedere al dezvoltatorilor. ntrebarea la care rspundem este: construim corect produsul? ntreinerea:
Dup ce programul este livrat clientului, mai devreme sau mai trziu sunt descoperite
defecte sau erori ce trebuie reparate. De asemenea, pot apare schimbri n specificaiile
utilizatorilor, care vor diverse mbuntiri. ntreinerea const n gestionarea acestor probleme.
Se poate constata uor c aceste activiti sunt n strns legtur cu cele patru faze ale ingineriei
programrii: analiza, proiectarea, implementarea i testarea.
Dup cum a fost explicat anterior, un model al unui proces software reprezint o
reprezentare abstract a unui proces software. Un model de proces reprezint procesul privit
dintr-o anumit perspectiv. n continuare introducem cteva modele generale de proces (numite
i paradigme de proces). Modelele descrise sunt: - Modelul cascad. Activitile fundamentale de
proces specificaia, dezvoltarea, validarea i evoluia sunt reprezentate ca faze separate precum
specificarea cerinelor, proiectarea software, implementare, testare, etc. - Dezvoltarea
evoluionar. Abordarea prespune ntreptrunderea activitilor de specificaie, dezvoltare i
validare. Se pornete de la dezvoltarea unui sistem iniial pornind de la un set de specificaii
abstracte. Sistemul este ulterior rafinat pe baza intrrii furnizate de utilizator pentru a produce n
final un sistem ce satisface n totalitate cerinele utilizatorului. 12 - Dezvoltarea bazat pe
componente. Abordarea se bazeaz pe existena unui numr considerabil de componente

reutilizabile.Procesul de dezvoltare a sistemului se axeaz n acest caz pe integrarea acestor

componente n cadrul sistemului.Aceste trei modele generice de procese larg rspndite astzi n
practica ingineriei programelor. Ele nu sunt mutual exclusive i sunt adesea folosite mpreun,
ndeosebi n cazul dezvoltrii unor sisteme de mari dimensiuni. De asemenea, de-a lungul
timpului au fost derivate modele noi pornind de la aceste modele generale.De exemplu, cel mai
important model derivat poate fi considerat modelulul de dezvoltare formal. Modelul de
dezvoltare formal se bazeaz pe construirea unui model matematic al sistemului ce se dorete a
se implementa. Acest model este apoi transformat, folosind un aparat matematic corespunztor i
transformri ce pstreaz consistena, n cod executabil.
Modelul cascad n modelul cascad, cunoscut i sub numele de modelul secvenial,
are loc mai nti faza de analiz, apoi cea de proiectare, urmat de cea de implementare i testare,
iar n final operarea i mentenana. Echipele care se ocup de fiecare faz pot fi diferite, iar la
fiecare tranziie de faz poate fi necesar o decizie managerial. Principalele etape ale modelului
cascad sunt urmtoarele: - Analiza i definirea cerinelor. Serviciile, constrngerile i
obiectivele sistemului sunt iniial stabilite prin consultare cu utilizatorii sistemului.
Aceste cerine sunt definite n detaliu i servesc ca specificaie a sistemului. - Proiectarea
sistemului i a software-ului. Procesul de proiectare a sistemului partiioneaz cerinele ca fiind
de natur hardware sau software. Etapa aceasta are de asemenea rolul de a stabili arhitectura
general a sistemului. Proiectarea software-ului prespune identificarea i descrierea
abstractizrilor software ale sistemului fundamentale i a interaciilor ntre acestea. Implementarea i testarea sistemului. n aceast etap sunt integrate i testate diversele uniti
individuale de program n cadrul unui sistem complet pentru a se asigura faptul c cerinele
software cerute au fost ndeplinite.
Dup testare sistemului software este livrat clientului. - Operarea i mentenana. n mod
normal (dei nu i necesar) aceasta reprezint cea mai lung dintre fazele modelului. Sistemul
este instalat i dat spre folosire. Mentenana presupune corectarea erorilor ce nu au fost
descoperite n etapele anterioare a ciclului de dezvoltare, mbuntirea implementrii unitilor
sistemului i mbuntirea serviciilor oferite de sistem pe msur ce sunt descoperite i adoptate
noi cerine de exploatare. Rezultatul fiecrei etape reprezint unul sau mai multe documente ce
sunt aprobate (eng. signed off). Urmtoarea faz nu poate ncepe pn cnd faza anterioar nu
s-a terminat.n practic ns fazele pot fi ntresute astfel nct informaii din fiecare etap 13
pot influena rezultatele altei etape. n timpul proiectrii, de exemplu, pot fi identificate diverse
probleme legate de cerine incorecte formulate n etapa de analiz. Procesul software, n practic,
nu este un simplu model secvenial ci presupune o secven de iteraii ale activitilor de
dezvoltare.
Modelul cascad. Metodologia secvenial este potrivit cnd complexitatea sistemului
este mic iar cerinele sunt statice. Ea spune c mai nti trebuie s ne gndim ce trebuie
construit, apoi s stabilim un plan de lucru i apoi s realizm proiectul, innd cont de
standardele de calitate. De asemenea, se aliniaz metodelor de inginerie hardware. Foreaz
meninerea unei discipline de lucru care evit presiunea scrierii codului nainte de a cunoate
precis ce produs va trebui de fapt construit. De multe ori, echipa de implementare se afl n

situaia de a programa nainte de finalizarea analizei, ceea ce conduce inevitabil la descoperirea

unor pri de cod inutile sau care contribuie foarte puin (poate chiar i ineficient) la
funcionalitatea produsului final. Totui, acest cod devine un balast foarte costisitor: dificil de
abandonat i greu de schimbat. Aceast metodologie foreaz analiza i planificarea naintea
implementrii, o practic foarte nimerit n multe situaii.Un mare numr de sisteme software din
trecut au fost construite cu o metodologie secvenial. Multe companii i datoreaz succesul
acestui mod de realizare a programelor.Trebuie spus totui i c presiunea de schimbare din
partea surselor externe era destul de limitat la momentul respectiv. Unul din principalele
dezavantaje ale metodologiei secveniale este faptul c acord o foarte mare importan fazei de
analiz.
Membrii echipei de analiz ar trebui s fie probabil clarvztori ca s poat defini toate
detaliile aplicaiei nc de la nceput. Greelile nu sunt permise, deoarece nu exist un proces de
corectare a erorilor dup lansarea cerinelor finale. Nu exist nici feedback de la echipa de
implementare n ceea ce privete complexitatea codului corespunztor unei anumite cerine. O
cerin simplu de formulat poate crete considerabil complexitatea implementrii. n unele
cazuri, este 14 posibil s fie chiar imposibil de implementat cu tehnologia actual. Dac echipa
de analiz ar ti c o cerin nu poate fi implementat, ei ar putea-o schimba cu o cerin diferit
care s satisfac cele mai multe dintre necesiti i care s fie mai uor de efectuat. Comunicarea
dintre echipe este o problem. n mod tradiional, cele patru echipe pot fi diferite iar comunicarea
dintre ele este limitat.
Modul principal de comunicare sunt documentele realizate de o echip i trimise
urmtoarei echipe cu foarte puin feedback. Echipa de analiz nu poate avea toate informaiile
privitoare la calitate, performan i motivare. ntr-o industrie n continu micare, metodologia
secvenial poate produce sisteme care, la vremea lansrii, s fie deja nvechite. Accentul att de
mare pus pe planificare nu poate determina rspunsuri suficient de rapide la schimbare.Ce se
ntmpl dac clientul i schimb cerinele dup terminarea fazei de analiz? Acest lucru se
ntmpl ns frecvent; dup ce clientul vede prototipul produsului, el i poate schimba unele
cerine. Dezvoltarea evoluionar (Prototipizare) O problem general care apare la dezvoltarea
unui program este s ne asigurm c utilizatorul obine exact ceea ce vrea. Prototipizarea vine n
sprijinul rezolvrii acestei probleme. nc din primele faze ale dezvoltrii, clientului i se prezint
o versiune funcionala a sistemului.
Aceast versiune nu este ntregul sistem, ns este o parte a sistemului care cel puin
funcioneaz. Dezvoltarea evoluionar se bazeaz pe dezvoltarea unei implementri iniiale,
expus comentariilor utilizatorului i rafinarea ei i producerea de noi versiuni pn cnd este
dezvoltat sistemului final (Fig. 2). Activitile de specificare, dezvoltare i validare sunt
ntresute.Fig. 2.Dezvoltarea evoluionar.Prototipul ajut clientul n a-i defini mai bine
cerinele i prioritile. Prin intermediul unui prototip, el poate nelege ce este posibil i ce nu
din punct de vedere tehnologic. Prototipul, este de obicei produs ct mai repede; pe cale de
consecin, stilul de programare este de obicei (cel puin) neglijent. ns scopul principal al
prototipului este de a ajuta n fazele de analiz i proiectare i nu folosirea unui stil elegant. 15
Se disting dou feluri de prototipuri: - de aruncat (throw-away); - evoluionar. n cazul realizrii

unui prototip de aruncat, scopul este exclusiv obinerea unei specificaii. De aceea nu se acord
nici o importan stilului de programare i de lucru, punndu-se accent pe viteza de dezvoltare.
Odat stabilite cerinele, codul prototipului este aruncat, sistemul final fiind rescris de la
nceput, chiar n alt limbaj de programare.
n cazul realizrii unui prototip evoluionar, scopul este de a crea un schelet al aplicaiei
care s poat implementa n prim faz o parte a cerinelor sistemului. Pe msur ce aplicaia
este dezvoltat, noi caracteristici sunt adugate scheletului existent. n contrast cu prototipul de
aruncat, aici se investete un efort considerabil ntr-un design modular i extensibil, precum i n
adoptarea unui stil elegant de programare.
Aceast metod are urmtoarele avantaje: - permite dezvoltatorilor s elimine lipsa de
claritate a specificaiilor; - ofer utilizatorilor ansa de a schimba specificaiile ntr-un mod ce nu
afecteaz drastic durata de dezvoltare; - ntreinerea este redus, deoarece validarea se face pe
parcursul dezvoltrii; - se poate facilita instruirea utilizatorilor finali nainte de terminarea
produsului.
Dezavantajele principale ale prototipizrii sunt prezentate n continuare: - deoarece
prototipul ruleaz ntr-un mediu artificial, anumite dezavantaje ale produsului final pot fi scpate
din vedere de clieni; - clientul nu nelege de ce produsul necesit timp suplimentar pentru
dezvoltare, avnd n vedere c prototipul a fost realizat att de repede; - deoarece au n fiecare
moment ansa de a face acest lucru, clienii schimb foarte des specificaiile; - poate fi
nepopular printre dezvoltatori, deoarece implic renunarea la propria munc. Dezvoltarea
bazat pe componente n majoritatea proceselor software exist un grad de reutilizare software.
Acest aspect apare cu precdere atunci cnd dezvoltatorii ce lucreaz n cadrul unui
proiect cunosc proiecte sau module de cod ce realizeaz funcionaliti similare celor cerute de
proiectul curent.
Dezvoltatorii adesea ajung s caute astfel de componente reutilizabile i, prin eventuala
lor modificare, le integreaz n proiect. Dezvoltarea bazat pe componente se bazeaz aadar pe
refolosirea sistematic a unor componente anterior implementate sau pe modificarea unor
sisteme COTS (Commercialoff-the-shelf).
- Analiza componentelor. Plecnd de la specificarea cerinelor se realizeaz o cutare a
componentelor cu ajutorul crora se pot implementa acestea. Adesea e greu de gsit o
component care s se potriveasc exact unei anumite cerine sau componenta care ar putea fi
folosit adesea implementeaz funcionalitatea numai parial.
- Modificarea cerinelor. n aceast etap cerinele sunt analizate folosind diversele
informaii disponibile despre componente.Cerinele pot fi ulterior modificate n funcie de
componentele disponibile.Atunci cnd modificrile sunt imposibil de fcut poate fi reluat
activitatea de analiz a componentelor pentru gsirea unor soluii alternative.
- Proiectarea sistemului prin refolosire. n aceast etap este proiectat framework-ul
sistemului (sau se poate opta pentru refolosirea unui framework deja existent). Proiectanii

sistemului iau n considerare, n aceast etap, componentele refolosite i organizeaz sistemul

final n scopul acomodrii acestora.
n aceast etap poate aprea de asemenea necesitatea proiectrii software, ndeosebi
atunci cnd nu pot fi gsite componente reutilizabile. - Dezvoltare i integrare. n aceast etap
este dezvoltat software-ul ce nu a putut fi procurat i n final sunt integrate componentele i
sistemele COTS pentru creerea sistemului final. Integrarea sistemului, n acest model, poate fi
parte a procesului de dezvoltare (nu exist o delimitare clar ntre cele dou activiti
dezvoltare i integrare). Astzi abordarea de dezvoltare bazat pe componente este din ce n ce
mai popular datorit apariiei unui numr mare de standarde bazate pe componente .
Schimbrile sunt inevitabile n oricare proiect software de dimensiuni mari. Cerinele
sistemului se pot modifica pe msur ce afacerea clientului ce necesit produsul software se
adapteaz la presiuni i schimbri externe. Prioritile de management sunt i ele n continu
modificare. Pe msur ce noi tehnologii devin disponibile apar modificri n etapele de
proiectare i implementare.
Toate aceste schimbri trebuie luate n considerare n dezvoltarea unor produse software
activitile presupune de dezvoltarea unui produs software trebuie repetate pe msur ce
sistemul este refcut ca rspuns la diverse cerine de modificare. Modele proceselor software ce
suport schimbrile survenite pe parcursul ciclului de dezvoltare a unui produs software poart
denumirea de modele iterative. n aceast seciune sunt introduse dou modele de proces ce sunt
proiectate n mod explicit pentru a suporta iteraiile proceselor:
1. Livrarea incremental. Specificaia software, proiectarea i implementarea sunt
separate n serii de incrementri ce sunt dezvoltate pe rnd.
2. Dezvoltarea n spiral. Dezvoltarea spiralelor sistemului conduce de la un proiect
iniial pn la dezvoltarea sistemului final.
Dezvoltarea incremental Modelul n cascad prezentat anterior presupune c utilizatorii
sistemului furnizeaz un set de cerine nainte de nceperea etapei de proiectare i c proiectanii
furnizeaz strategii de proiectare particulare naintea fazei de implementare. Modificrile
cerinelor necesit ns refacerea tuturor etapelor de analiz a cerinelor, proiectare i
implementare. Totui, separarea fazelor de proiectare i implementare ar trebui s conduc la
crearea unui sisteme bine-documentate ce sunt uor de modificat. Prin contrast, o abordare
evoluionar permite ca deciziile de analiz a cerinelor i proiectare s fie ntrziate dar poate
conduce de asemenea la dezvoltarea de software slab structurat i dificil de neles i meninut.
Dezvoltarea incremental reprezint o abordare intermediar ce combin avantajele
ambelor modele. ntr-un proces de dezvoltare incremental clienii identific, n linii mari,
serviciile ce vor fi furnizate de ctre sistem. Ei identific apoi care dintre servicii sunt mai
importante i care sunt mai puin importante pentru sistemul final. Sunt definite apoi un numr
de livrri incrementale, fiecare incrementare furniznd un sub-set al funcionalitilor sistemului
final. Alocarea serviciilor ce sunt implementate cu fiecare nou increment depinde de prioritile
alocate, serviciile avnd cea mai mare prioritate pentru sistemului final (respectiv pentru

utilizator) fiind implementate cel mai devreme. Dup ce au fost identificate incrementrile
sistemului cerintele serviciilor ce trebuie implementate odat cu primul incrementat sunt
analizate n detaliu i se trece la implementarea respectivului increment. n timpul fazei de
dezvoltare alte analize ale cerintelor pentru incrementri viitoare pot aprea, dar nu se accept
modificri ale cerinelor pentru incrementarea curent.
Odat ce a fost finalizat i livrat un increment clienii pot trece la punerea n producie a
funcionalitii respective. Aceasta nseamn c utilizatorii pot trece la experimentarea n
producie a unora dintre funcionalitile cele mai prioritare, de baz, nainte ca ntreg sistemul s
fie dezvoltat.
Dezvoltarea incremental. Dezvoltarea incremental are i ea o serie de avantaje. Clienii
nu sunt obligai s atepte pn cnd ntregul sistem este livrat i pot trece la folosirea unor
funcionaliti prioritare nainte chiar ca ntreg sistemul s fie finalizat. Clienii pot, de asemenea,
folosi incrementrile iniiale ca prototip i pot experimenta cerinele ulterioare ce sunt propuse
apoi pentru dezvoltrile viitoare ale sistemului final. Riscul de eec al ntregului proces este
redus. Chiar dac n unele incrementri pot aprea probleme, totui unele incrementri, cu o
mare probabilitate, ajung s fie livrate clientului. n fine, deoarece serviciile avnd cea mai mare
prioritate sunt livrate iniial, inevitabil aceste servicii vor fi i testate cel mai ndelung nainte de
punerea n producie a sistemului final.Utilizatorii vor ntlni mai puine erori de funcionare n
cadrul unor dintre componentele critice ale sistemului final.
Modelul spiral Modelul spiral (Fig. 5) este un exemplu bine cunoscut de metodologie a
ingineriei programrii. Acest model ncearc s rezolve problemele modelului n cascad,
pstrnd avantajele acestuia: planificare, faze bine definite, produse intermediare. n locul
reprezentrii procesului software ca o secven de activiti, procesul este reprezentat n acest caz
sub forma unei spirale. Fiecare bucl a spiralei reprezint o faz a procesului software. Astfel,
bucla cea mai din centru corespunde activitii de stabilire a fezabilitii sistemului, urmtoarea
bucl corespunde definirii cerinelor, urmtoarea proiectrii sistemului i aa mai departe.
Fiecare bucl a spiralei este mprit n patru sectoare: 1. Stabilirea obiectivelor. Sunt definite
obiective specifice pentru faza curent a proiectului. Sunt identificate, de asemenea, constrngeri
asupra proceselor i 19 produsului i este trasat un plan detaliat de management. Tot aici sunt
stabilite riscurile asociate procesului. Pot fi planificate strategii alternative, n funcie de riscurile
identificate. 2. Evaluarea i reducerea riscurilor. n cazul fiecrui risc anterior identificat este
realizat o analiz detaliat. Sunt trasai pai pentru reducerea riscului.
De exemplu, dac apare un risc legat de faptul c cerinele sunt necorespunztoare atunci
se poate trece la dezvoltarea unui sistem prototip. 3. Dezvoltarea i validarea. Dup etapa de
evaluare a riscurilor se alege un model de dezvoltare. De exemplu, dac riscurile interfeelor
utilizator sunt dominante, atunci un model corespunztor de dezvoltare ar putea fi prototiparea
evoluionar. Dac riscurile legate de siguran sunt dominante atunci se poate alege un model de
dezvoltare formal a modelului. Modelul cascad poate fi ales atunci cnd riscul principal
identificat l reprezint integrarea sub-sistemelor. 4. Planificarea. Proiectul este revizuit i se ia o
decizie legat de posibila continuare cu o nou bucl a spiralei. Dac se ia decizia de continuare
atunci sunt trasate planuri pentru continuarea cu urmtoarea faz a proiectului.

Modelul spiral. Principala diferen ntre aceast abordare i ale modele de procese
software este dat de recunoaterea explicit a riscurilor. Riscul reprezint orice ar putea merge
ru. De exemplu, dac intenia este de a utiliza un nou limbaj de programare, un posibil risc ar
putea fi reprezentat de posibilitatea ca compilatoarele existente s nu fie de ncredere sau s nu
produc cod eficient. Riscurile duc la probleme legate de planificare i depirea costurilor.Un
ciclu al spiralei ncepe prin elaborarea obiectivelor precum performan i funcionalitate.
Modaliti alternative de atingere a acestor obiective i constrngerile impuse de fiecare obiectiv
sunt apoi enumerate. Fiecare alternativ este evaluat n termeni de riscuri posibile i sunt
identificate posibilele surse de riscuri. Urmtpatoarea etapa presupune rezolvarea acestor riscuri
prin activiti de informare precum analiza detaliat, prototiparea i simularea.

Studiu de caz

Amadeus CARE

"Amadeus CARE" (Customer Administration & Reporting Extranet) este un instrument

complex de tip ERP, dedicat administrarii fluxului de procese interne si gestiunii rapoartelor cu
clientii (agenti economici) din reteaua comerciala de turism si distributie Amadeus.
Compania Amadeus este liderul mondial in oferirea de solutii in domeniul turismului,
solutii destinate distributiei si vanzarii de servicii turistice. Solutiile si serviciile Amadeus sunt
folosite de clientii Amadeus in diverse moduri. Peste 90,000 de agentii turistice si aproximativ
30,000 puncte de vanzare apartinand liniilor aeriene folosesc sistemul Amadeus pentru a-si
desfasura activitatea.

Filiala romaneasca, Amadeus Romania, este de asemenea lider in domeniul turismului

din Romania prin tehnologia si solutiile de distributie furnizate. Cu o existenta de 20 ani si o cota
de piata de peste 70%, Amadeus Romania furnizeaza servicii pentru grupuri largi de clienti cum
ar fi: companii ariene, hoteluri, companii de inchirieri auto, companii feroviare, linii de feribot,
linii de croaziera, companii de asigurari si agentii de turism.

Provocare

Principala provocare a constat in construirea unei solutii care sa acopere integral si cu

eficienta de lunga durata, complexitatea si diversitatea activitatilor generate de modelul de

business Amadeus. In esenta, se identifica necesitatea integrarii de procese interne din categorii
tehnologice extrem de diferite din compania Amadeus, cum sunt: distributie si content, vanzari si
comert electronic, business management, servicii si consultanta. Alaturi de acestea, aplicatia a
trebuit sa faca posibila administrarea unei retele largi de clienti si parteneri cu profiluri si
necesitati diferite.

Rezolvare

Modalitatea in care specialistii Zitec au conceput si dezvoltat sistemul informatic "Amadeus

CARE" raspunde admirabil cerintelor de imbunatatire a productivitatii, comunicare si
management a fluxului de business, cerinte emise atat de personalul companiei Amadeus, cat si
de reteaua de clienti si parteneri ai acesteia.

Intranet

Elementul central in structura aplicatiei este dat de sistemul de administrare Intranet,

dedicat strict personalului Amadeus.
Prin intermediul acestei platforme, angajatii Amadeus pot gestiona intr-un mod simplu, eficient
si rapid seturi largi de date si informatii despre clientii sai - agentii de turism, companii aeriene,
hoteluri, companii ce fac parte din canalul de distributie Amadeus, si pot administra materiale cu
caracter informativ, cum sunt sesiuni de training, newslettere, activitati de suport pentru clienti si
alte facilitati privind activitatea interna a companiei.

De asemenea, aplicatia permite contabilizarea unor activitati cu caracter specific

industriei turismului, cum sunt vanzarea de bilete (in format electronic sau hartie) pe baza
solutiilor software Amadeus furnizate clientilor, precum si administrarea facila a unui complex
sistem de rezervari pentru o gama larga de categorii (companii aeriene, hoteluri, masini, cale
ferata, feribot etc.).

Schema de business Amadeus produce o serie de costuri si venituri legate de furnizarea

de echipamente hardware, licente software, si de conexiune internet, costuri " one-time "
specifice, costuri de mentenanta si stocare.
Pentru a raspunde necesitatii de management flexibil si orientat catre performanta a fluxului de
costuri si venituri generate in relatiile cu clientii, aplicatia "Amadeus CARE" are integrat un
mecanism de generare rapoarte si statistici, ce permite o actualizare la zi a datelor incarcate in
sistem, precum si realizarea de previziuni pe perioade determinate de timp.

Un punct de greutate al aplicatiei "Amadeus CARE" si, o premiera la nivel national in

cadrul retelei Amadeus, este implementarea unui complex sistem financiar de facturare. Prin
intermediul acestuia personalul Amadeus poate genera si administra la un inalt nivel de
productivitate, rapoarte complexe de facturare pentru categorii variate de servicii si produse
furnizate de compania Amadeus clientilor sai.
Eficienta si fiabilitatea acestui sistem permit companiei Amadeus atingerea unei performante
superioare, raportata prin evaluarea in timp real a productivitatii fiecarui client, manipularea unei
diversitati largi de tipuri de facturi si, nu in ultimul rand, rularea automata de statistici pentru o
multitudine de factori.

Extranet

Un alt element de baza al aplicatiei "Amadeus CARE" il constituie interfata de

administrare Extranet, dedicata companiilor clienti. Echipa Zitec a urmarit dezvoltarea unei
interfete web user-friendly care sa permita accesul rapid la date si transferul de informatii intre
client si furnizor intr-un mediu securizat, fara sa solicite cunostinte avansate din partea
utilizatorului.

In aceasta sectiune, clientii si partenerii Amadeus pot accesa cele mai recente informatii
despre serviciile si produsele Amadeus, stiri din industrie, newslettere, statistici (productivitatea
nivelului de rezervari, evidenta biletelor emise), chestionare, documentatie de training si alte
materiale cu caracter specific.

Rezultate

Aplicatia "Amadeus CARE", un instrument cu caracter de noutate in Grupul Amadeus, a

contribuit intr-un mod decisiv la perfectionarea managementului de procese si a bazei de date de
clienti din reteaua Amadeus prin functionalitatea superioara, gestiunea unitara, actualizarea
facila, si nu in ultimul rand, deschiderea catre clientii agentii de turism si asistenta oferita
acestora pe durata intregului proces.

Feedback

Gestionarea rapida si usoara a bazei de date de clienti, obtinerea automata a diferite tipuri
de rapoarte si statistici legate de productivitatea clientilor nostri, gestionarea automata a
sesiunilor de scolarizare sunt activitati esentiale pentru optimizarea activitatii noastre si pentru
succesul nostru. Prin parteneriatul cu ZITEC beneficiem de posibilitatea de a asigura permanent
clientilor nostri acces la informatiile de care acestia au nevoie pentru evaluarea activitatii lor
(rapoarte configuratie, statistici rezervari/bilete, inscrieri la curs, newsletter etc.). De-a lungul
celor peste 5 ani de colaborare, ZITEC s-a dovedit a fi un partener profesionist care actioneaza
proactiv, ajutandu-ne astfel sa imbunatatim functionalitatile aplicatiei dezvoltate.

Bibliografie

Notiuni teoretice :

1. http://andrei.clubcisco.ro/cursuri/f/f-sym/4idp/1_Etapele_dezvoltarii_doc.pdf

2. https://ro.wikipedia.org/wiki/Pagina_principal