Sunteți pe pagina 1din 9

Tehnologiile informationale au rescris regulile mediului de afaceri.

Managementul relatiilor cu
clientii, planificarea, proiectarea si dezvoltarea productiei, cercetarile si strategiile de marketing,
planificarea, dezvoltarea si exploatarea lanturilor de distributie, managementul resurselor umane
depend de tehnologiile informationale.
Notiunea de sistem face parte din vocabularul current. Vorbim de sisteme mecanice, economice,
sociale, politice etc.
Definit foarte simplu, sistemul este un ansamblu de elemente aflate in interactiune. In general,
sistemul reprezinta un ansamblu de elemente, dependente intre ele, care formeaza un tot
organizat si care functioneaza impreuna in scopul realizarii unui obiectiv final comun.
In cadrul unui sistem interactioneaza trei component de baza:
1. Intrarile- orice sistem este supus actiunii mediului in care se afla, actiune care se
manifesta sub forma intrarilor;
2. Procesarile (prelucrarile)- transformarea inglobeaza ansamblul proceselor prin care din
intrari se obtin iesiri;
3. Iesirile- rezultatele proceselor care au loc in cadrul sistemelor.
Sistemele informationale se bazeaza pe trei resurse cheie: informatia, tehnologiile informationale
si oamenii. Tehnologiile informationale asigura factorului uman accesul la informative si fac
posibila gestionarea averii informationale, precum si desfasurarea eficienta a operatiunilor din
mediile de afaceri actuale.
In literature de specialitate, sistemul informational este definit ca reprezentand totalitatea
metodelor, procedeelor si mijloacelor utilizate in culegerea, stocarea, prelucrarea, analiza si
transmisia datelor pentru fundamentarea si urmarirea deciziilr la toate nivelurile unei entitati
economico-sociale.
In consecinta, in cadrul sistemului informational exista ntotdeauna un sistem de prelucrare a
datelor care poate fi manual, informatizat sau combinat. Atunci cand, la nivelul prelucrarii
datelor, al analizei si transmisiei informatiilor, se recurge la tehnologii informatice, sistemul este
informatics. Sistemul informational este identic cu sistemul informatics atunci cand toate
componentele informationale dintr-o organizatie, toate mijloacele si regulile sunt informatizate.
Informatizarea transforma sistemele informationale manual in sisteme informatice prin
substituirea mijloacelor de lucru cu echipamente modern, reducerea timpilor de lucru, eliminarea
erorilor, prelucrarea unui volum mare de date si distribuirea eficienta a informatiilor. Astfel,
sistemul informatics apare ca o component a sistemului informational in care mijloacele tehnice
de prelucrare sunt calculatoarele electronice.
Elaborarea unui produs informatic/ Ciclul de viata al dezvoltarii sistemelor informationale

Ciclul de viata al dezvoltarii sistemelor este o metodologie comuna de dezvoltare a sistemelor


din multe organizatii, caracterizata prin cateva faze care marcheaza evolutia eforturilor de analiza
si proiectare a sistemelor. Fazele sau etapele ciclului de viata sunt greu de prezentat, nu numai
ca nume, ci si ca numar.
In legatura cu numarul si numele etapelor ciclului de viata al dezvoltarii sistemelor, se observa,
la sfarsitul anilor 1980 si inceputul anilor 1990, o tendinta de preluare a unor etape specific
managementului proiectelor. De exemplu, identificare si selectia proiectului, planificarea si
initierea proiectului (numite de unii specialist etapele microanalizei) preced analiza, proiectarea
logica, proiectarea fizica, implementarea, intretinerea.
Indiferent de numarul si numele etapelor ciclului de viata al dezvoltarii sistemelor, o problema
este mult mai importanta, si anume ordinea si felul in care se parcurg etapele respective, ceea ce
in literature de specialitate se trateaza sub numele de modele ale ciclului de viata al dezvoltarii
sistemelor.
Ciclul de viata al unui produs software este reprezentat n figura de mai jos. Odata dezvoltat,
produsul intra ntr-un ciclu de utilizare si modificare, care continua pe toata durata sa de viata.
Tiparul nu este specific produselor software, el putnd fi generalizat pentru majoritatea
produselor industriale, cu diferenta ca n cazul acestora din urma etapa de modificare se numeste
etapa de reparare sau de ntretinere (ciclul este utilizare - modificare, pe masura ce componentele
se uzeaza).

Produsele software nu se uzeaza, n schimb, ele trec prin faza de modificare din alte motive:
corectarea erorilor care nu au fost detectate n faza de dezvoltare, schimbari n contextul n care
sunt utilizate, schimbari efectuate modificarea anterioara care au avut efecte nedorite n alte
puncte ale programului. De exemplu, modificarea legii impozitului necesita corectarea
programelor pentru salarii, iar adesea aceste modificari au efecte adverse n alte zone ale
programului efecte care sunt observate ulterior.

Indiferent de motivul pentru care un produs informatic intra n faza de modificare, acest stadiu
presupune ca o persoana (adesea alta dect autorul programului sa studieze programul si
documentatia aferenta pna cnd ajunge la un grad de ntelegere care sa i permita efectuarea
modificarilor. n caz contrar, este posibil ca modificarile efectuate sa cauzeze mai multe
probleme dect rezolva. ntelegerea unui program este adesea o sarcina foarte dificila, chiar n
conditiile n care acesta a fost bine proiectat si documentat. Nu sunt deloc rare cazurile n care n
aceasta faza renunta complet la un anumit program component, considerndu-se (si nu fara
temei) ca este mai usor sa se dezvolte de la zero un sistem nou, dect sa se modifice cu bune
rezultate sistemul existent.
Experienta arata ca un minim de efort n timpul dezvoltarii unui produs informatic poate sa
usureze mult sarcina modificarii produsului, atunci cnd acest lucru devine necesar. Majoritatea
cercetarilor n domeniul ingineriei software se concentreaza pe faza de dezvoltare a produselor;
eforturile investite n aceasta faza aduc cele mai nalte beneficii pentru toate fazele ulterioare de
viata.
Vom analiza acum mai ndeaproape etapele care intra n componenta primei faze din ciclul de
viata al produselor informatice: dezvoltarea. Aceste etape sunt analiza, proiectarea,
implementarea si testarea.

Analiza
Aceasta este etapa n care se constata ca ar fi utila o aplicatie informatica si se ia decizia
dezvoltarii unui sistem software. Fie ca se constata existenta unei piete pentru un produs de uz
general, fie ca o anumita organizatie are nevoie de o aplicatie specializata, n mare masura
aceasta prima etapa presupune mai degraba luarea unor decizii de management si marketing
dect abordarea unor problem legate de studiul algoritmilor. Dupa luarea deciziei de dezvoltare a
unui sistem informatic ncepe adevarata analiza, al carei scop principal este identificarea
necesitatilor utilizatorului potential al sistemului.
Proiectarea
n faza de proiectare sunt dezvoltate detaliile tehnice ale sistemului. n aceasta etapa, sistemul
este descompus n componente mai usor de controlat, numite module. Implementarea sistemelor
complexe devine posibila tocmai prin aceasta descompunere modulara. Altfel, multimea
detaliilor tehnice care trebuie luate n considerare ar fi imposibil de stapnit; prin proiectarea
modulara, este suficient sa avem n vedere pentru fiecare modul doar detaliile corespunzatoare

acestuia. Pe de parte, proiectarea modulara ajuta si la ntretinerea sistemului. O structura


modulara bine proiectata este importanta att pentru implementarea sistemului, ct si pentru
modificarea sa ulterioara. Acesta este unul dintre principalele motive pentru care paradigm
orientata spre obiecte cstiga teren: un sistem proiectat orientat spre obiecte este prin definitie un
sistem modular.
Implementarea
Aceasta faza se refera la scrierea efectiva a programelor, crearea fisierelor de date si dezvoltarea
bazelor de date.
Testarea
Aceasta faza este strns legata de faza anterioara, deoarece n normal fiecare modul al sistemului
este testat n timpul implementarii, ntr-un sistem bine proiectat, fiecare modul poate fi testat n
mod independent, utilizndu-se versiuni simplificate ale celorlalte module pentru a se simula
interactiunile dine modulul tinta si restul sistemului. Desigur, pe masura ce diferite module sunt
analizate si combinate, testarea individuala trebuie continuata cu testarea generala a ntregului
sistem.[1]
Analiza ciclului de viata este o metoda de a evalua aspectele de mediu si impacturile potentiale
associate cu un produs sau sistem. Este utilizat din ce n ce mai mult n faza de creare a noului
produs cu scopul de a reduce impactul total prin ciclul de via (material brut, manufactur,
distribuie, utilizare i meninere, reutilizare, reciclare i nlturarea final). Datele de ciclu de
via pot fi de asemenea foarte folositoare pentru informaiile aduse utilizatorilor finali, astfel c
impactul asupra mediului n faza de utilizare este redus, i pentru gestionarea sfritului vieii
unui produs (de exemplu identificarea materialelor cu potenial de hazard sau cele valoroase din
produs).
Un model de ciclu de via este o ncercare de a analiza stadiile prin care trece un program din
momentul n care a fost imaginat i pn la ultimele sale utilizri. Modelul tinde s fie mai
complex pentru software dect pentru alte tipuri de produse i are un numr de diferene majore
de exemplu, fazele de producie ale majoritii produselor presupun realizarea unui numr mare
de copii ale produsului, i astfel aceasta este partea cea mai consumatoare de timp i bani din
proces: pentru software, realizarea de copii este doar copierea de discuri sau casete o parte
foarte ieftin a ntregului proces.
1. Modelul in cascada
Modelul cascada este un proces secvential de creare, utilizat deseori in dezvoltarea proceselor
software in care progresul este considerat ca o cadere continua (ca o cascada) prin fazele de
Concepere, Analiza, Proiectare, Implementare, Testare, Utilizare si Mentenanta.

Modelul este lansat la inceputul anilor 1970 de catre W.W.Royce si consta intr-o descompunere a
ciclului de viata in faze secventiale. La randul lor, fazele sunt structurate pe activitati si
subactivitati. Trecerea de la o etapa la alta se realizeaza dup ace precedent a fost parcursa in
intregime. Modelul se aplica la nivel de sistem, ori, tocmai aici este punctual slab, intrucat
sistemele comlexe, cu un numar mare de aplicatii ce interactioneaza intre ele, sunt greu de
controlat. Desi nu este descurajata abordarea iterative a unor faze sau component ale lor,
restrictiile de timp impuse de programarea calendaristica a etapelor limiteaza efectele benefice
ale acesteia, ca si posibilitatile de revenire la etapele anterioare.

Definirea
cerintelor

Analiza

Proiectare
a
Implementar
ea

Testarea

Utilizarea si
mentenanta

Fig.1. Schema modelului in cascada

Modelului i se recunosc unele avantaje, cum ar fi:

un control total asupra fazelor, in sensul ca ele sunt ordonate si, firesc, previzibile, prin
evidentierea clara a ariei de intindere a fiecarei etape sau subcomponenta a ei;

este usor de insusit de catre membrii echipelor de analiza si proiectare, inclusive de cei
noi, cu o experienta mai putin vasta;
fiecare etapa este insotita de o documentatie perfect structurata (controlata).

Ca dezavantaje, amintim:

sistemul se preda doar dupa parcurgerea tuturor etapelor, ceea ce inseamna o lunga
perioada de timp, sufficient ca utilizatorii sa-si schimbe pretentiile;
nu corespunde intentiilor de abordare dinamica a sistemelor;
nu este deschis schimbarilor ce pot interveni pe parcurs.

2. Modelul V
Modelul V este o varianta a modelului cascada, prin care se introduce conceptele de sistem si
component (subsisteme), aplicandu-se teste explicite la un sistem ierarhic pentru cresterea
controlului asupra modului in care se desfasoara etapele. Tocmai aceasta inlesnire constituie o
latura a literei V. Prima este latura din stanga, parcursa descendent, si contine etapele propriuzise, iar cea de-a doua latura, din dreapta, se parcurge ascendant, pee a realizandu-se verificarile
si validarile elementelor create anterior.
Modelul, redat in figura. , puncteaza cu mai multa claritate separarile dintre ceea ce implica
participarea utilizatorului, modelul architectural sic el a implementarii. Utilizatorul este implicat
doar in fazele din partea superioara a V-ului. Arhitectura sistemului este surprinsa in partea de
mijloc a literei, iar partea inferioara a ei se refera la faza de implementare, care ar putea consta
fie din asamblarea componentelor software, fie din codificarea unor componente.
Modelul se preteaza si in mediul orientat-obiect, deoarece incurajeaza prototipizarea, reutilizarea
unor structure superioare. El ofera un control puternic asupra sistemului in curs de realizare, prin
structurile ierahice si modulare pe care le promoveaza, ceea ce il face utilizabil si in cazul
sistemelor complexe. La o analiza globala modelelor, un punct forte al fiecaruia dintre ele se
refera tocmai la posibilitatea abordarii pe component a sistemului, o forma incrementala utilizata
in dezvoltarea acestora. Modelul devine si mai puternic daca promoveaza iteratia, adica reluarea
unor faze, activitati sau subactivitati.
In cadrul acestui model se face distincte intre verificare si validare. Prima se refera la testarea
sistemului, in diverse stadia ale lui, daca s-a construit correct din punct de vedere logic, in timp
ce validarea va scoate in evidenta faptul ca sistemul, in forma lui finala, raspunde sau nu
cerintelor initiale.
3. Modelul prototipizarii

Pentru sisteme noi, in mod special daca ele sunt mari si complexe este putin probabil sa se
construiasca o specificatie completa, logica si valida inainte ca sistemul sa fie construit si utilizat.
Acest fapt a condus la ideea prototiparii. Ideea este de a permite viitorilor utilizatori sa exerseze
cu o prima versiune a sistemului, care poate fi obtinuta rapid prin tehnici de simulare si/sau de
interpretare a specificatiilor. In acest ultim caz, limbajele logico-functionale sunt in mod sigur
chemate sa joace un rol important.
Prototipul este o schita a viitorului sistem: el nu are performantele si nu raspunde exigentelor de
calitate ale unui produs finit. Prototipul ofera clientului functionalitati (nu in totalitate) ale
viitorului sistem si interfata sa. El este dezvoltat intr-o maniera iterativa. Cerintele sunt extrase si
validate iterativ prin utilizarea prototipului. In fiecare iteratie specificatia sistemului este
modificata si detaliata pana cand prototipul satisface necesitatile utilizatorilor. Un prototip care
este utilizat pentru a desprinde cerintele viitorilor utilizatori, este o "macheta exploratoare".
Activitatea de prototipare poate interveni de asemenea in etapa de proiectare, pentru a
experimenta si compara diferite variante. Astfel de prototipuri se numesc "machete
experimentale".

Fig. 1. Schema modelului cu prototipuri

Aceasta este o versiune ciclic a modelului liniar. Odat ce analiza cerinelor este ndeplinit i
proiectarea este terminat, procesul de dezvoltare este pornit. Odat ce prototipul este creat, este

dat consumatorului pentru evaluare. Consumatorul ofer feedback dezvoltatorului care rafineaz
produsul conform cu ateptrile consumatorului. Dup un numr finit de iteraii, pachetul final
este dat consumatorului. n aceast metodologie, software-ul evolueaz ca rezultat al schimbului
periodic de informaii dintre consumator i dezvoltator. Acesta este modelul cel mai popular din
industria IT. Majoritatea produselor software de succes au fost create folosind acest model,
ntruct este foarte dificil s nelegi toate cerinele utilizatorilor dintr-o singur ncercare. Exist
multe variante ale modelului, din cauza diverselor stilurilor manageriale ale companiilor.
Versiuni noi ale unui produs software apar ca rezultat al modelului cu prototipuri. n general
prototipul simuleaz numai cteva aspecte ale atributelor programului final i poate fi complet
diferit de implementarea final.
Scopul convenional al unui prototip este de a permite utilizatorilor de software s evalueze
propunerile dezvoltatorilor ncercndu-le practic i nu pe baza descrierilor. Utilizarea
prototipurilor poate fi util i end user-ilor pentru a descrie cerine pe care dezvoltatorii nu le-au
considerat, aadar controlarea prototipului poate fi un factor cheie n relaia comercial dintre
dezvoltatori i clieni. Folosirea prototipurilor are o serie de beneficii: proiectantul soft i
dezvoltatorul pot obine feedback de la utilizatori devreme n ciclul de via. Clientul i
contractorul pot vedea dac produsul software respect cerinele pe care se construiete
programul soft. De asemenea, ofer informaii inginerului soft legate de estimrile iniiale i de
acurateea lor, acesta putnd determina dac se pot respecta deadline-urile.
4. Modelul incremental
Modelul incremental este o alta forma a celui in cascada. De fapt, in modul de descriere a
etapelor incipiente nici nu exista vreo diferenta fata de modelul cascada, intrucat atat definirea
cerintelor, cat si analiza se efectueaza la nivelul intregului sistem. Dupa aceasta se efectueaza
descompunerea proiectuluiin subproiecte, ele fiind uramarie pe activitati care vor concur la
obtinerea componentelor necesare sistemului final. Fata de modelul V, cel incremental ofera
posibilitatea atingerii scopului final in doua variante: sistem global livrat la sfarsit sau
componente livrate distinct.
Din descrierea de pana acum rezulta cateva dintre avantajele modelului:

se incadreaza in principiul arhicunoscut divide et impera, prin posibilitatea abordarii


unor parti ale intregului;
sistemul poate fi livrat sip e component realizate la perioade scurte de timp;
proiectul sau sistemul final poate fi realizat de mai multe echipe sau personae datorita
modularizarii lui.

Dintre dezaantaje pot fi enumerate:

imposibilitatea aplicarii lui in toate cazurile, uneori neexistand elementele necesare


descompunerii intregului;

componentele pot fi realizate numai dupa ce intregului sistem i se defineste arhitectura,


totul derulandu-se dupa principiile metodei top-down, ceea ce inseamna inca o conditie
dura: cunoasterea si formularea cerintelor din faza incipienta de abordare a sistemului;
fiind posibil de realizat pe parti, eforturile de integrare a acestora in intreg sunt destul de
mari, vorbindu-se chiar despre o asa-zisa testare multipla de sisteme, cu trimitere la faptul
ca, de fiecare data cand se adauga o noua componenta, sistemul poate fi considerat unul
nou.

5. Modelul spirala
Modelul spirala al dezvoltarii si evolutiei software reprezinta riscul condus catre analiza si
structura procesului software. Aceasta abordare a fost dezvoltata de catre Barry Boehm si contine
elemente ale dezvoltarii pornite de la anumite specificatii, metode ale procesului de dezvoltare a
produselor pe baza unui prototip, impreuna cu clasicul ciclu de viata al produsului software.
Acestea se realizeaza prin reprezentarea dezvoltarii iterative a ciclului sub forma unei spirale
extinse, cu cicluri interne ce indica analiza din timp a sistemului si cu cicluri externe ce indica
ciclul de viata al software-ului. Dimensiunea radial indica costuri cumulate ale dezvoltarii, iar
dimensiunea unghiulara indica progresul facut pentru efectuarea fiecarai dezvoltari ale spiralei.
[2]
Analiza riscurilor, ce cauta sa identifica situatiile ce cauzeaza esuarea dezvoltarii apare in fiecare
ciclu al spiralei. In fiecare ciclu este reprezentat aproximativ aceeasi cantitate de inlocuiri
unghiulare, in timp ce volumul inlocuit indica cresterea nivelurilor de incercari pentru analiza.
Dintre avantajele modelului, in afara de posibilitaea evaluarii riscurilor in diferite momente, ar
mai fi de amintit si simplificarea operatiunilor de evaluare a ce este necesar in etapa (prototipul)
urmatoare, inclusive prin prisma costurilor.
Nu ca dezavantaje, ci mai degraba ca elemente ce conditioneaza folosirea modelului, amintim:

profesionalismul echipei de dezvoltare


flexibilitatea in actiune, inclusive in alocarea de fonduri, dar si in definirea activitatilor de
intreprins.