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.

AnalizaAceasta 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. Proiectarean 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. ImplementareaAceasta faza se refera la scrierea efectiva a programelor, crearea fisierelor de date si dezvoltarea bazelor de date.TestareaAceasta 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 cascadaModelul 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

Proiectarea

Implementarea

Utilizarea si mentenantaTestarea

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 VModelul 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 propriu-zise, 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 prototipizariiPentru 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 incrementalModelul 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 spiralaModelul 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.