SISTEME INFORMATICE DE GESTIUNE

Unitatea de învăţare 1

Tipologia,arhitecturasi
proceselededezvoltare
asistemelor
informaticedegestiune
1.1 Obiectivele unităţii de învăţare

1. Dobândirea cunoştinţelor privind tipologia şi arhitectura sistemelor informatice de

gestiune.
2. Însuşirea noţiunilor teoretice fundamentale aferente proceselor de dezvoltare a
sistemelor informatice de gestiune.
3. Dobândirea cunoştinţelor privind modele ale procesului de dezvoltare.
4. Dobândirea cunoştinţelor despre metodele de proiectare a sistemelor informatice de
gestiune şi evoluţia acestora.
5. Însuşirea principiilor de bază aplicabile în realizarea sistemelor informatice de
gestiune.

1.2 Tipologia şi arhitectura sistemelor informatice de

gestiune

1.2.1 Sisteme informaţionale şi sisteme informatice

Sistemul informaţional al organizaţiei cuprinde:

• ansamblul de informaţii organizate;
• evenimentele care au efecte asupra acestora;
• persoanele care acţionează asupra informaţiilor sau le utilizează cu finalităţi de
gestiune;
• procedurile urmate;
• resursele puse în lucru.

Sistemul informaţional face obiectul creării, modificării, managementului, auditării, ca

orice altă componentă a organizaţiei şi poate fi evaluat din perspectiva contribuţiei pe care o
are la atingerea obiectivelor acesteia.

Sistemul informatic de gestiune reprezintă o soluţie informatică pentru sarcinile,

lucrările, problemele (unei porţiuni a) sistemului informaţional, aptă de a funcţiona pe o
anumită platformă (o configuraţie de echipamente şi software de exploatare şi gestionare
a acestora), folosind un anume software de aplicaţie.
 Figura Error! No text of specified style in document..1 Sistemele informatice de gestiune şi
sistemul informaţional al organizaţiei

1.2.2 Relaţia dintre sistemul informaţional şi sistemul informatic de

gestiune

1. sistemul informatic de gestiune are rolul de infrastructură a

sistemului informaţional: setul de informaţii ce fac obiectul prelucrării şi
memorării, procedurile şi procesele urmate, personalul implicat sunt în
totalitate determinate de sistemul informaţional, fiind expresia modului specific
în care acesta îşi îndeplineşte funcţiile în cadrul organizaţiei; sistemul informatic
de gestiune nu face decât să asigure funcţionarea sistemului informaţional în
aceşti parametri;

2. sistemului informaţional al organizaţiei comunică cu sistemele

informatice de gestiune, cărora le transmite informaţii şi solicitări şi de la
care primeşte rezultate, pe care le încorporează şi le utilizează mai departe;

3. sistemele informatice comunică între ele, transmiţându-şi reciproc date şi

solicitări;

4. particularităţile tehnice de funcţionare a sistemelor informatice antrenează

inserarea în sistemul informaţional a unor prelucrări specifice, dintre
care cele mai frecvente sunt procedurile de asigurare a protecţiei,
confidenţialităţii şi securităţii datelor;

5. tehnologiile folosite în sistemele informatice pot aduce noi

potenţialităţi şi oportunităţi pentru organizaţie, ceea ce determină
 schimbări la nivelul proceselor de gestiune şi, inevitabil, ale sistemului
informaţional, unul dintre cele mai relevante exemple de acest tip fiind
comerţul electronic în toate formele sale;

6. software-ul de bază şi configuraţia de echipamente folosite de sistemele

informatice pot fi comune sau diferite, parţial sau în totalitate; cu alte cuvinte,
sistemele informatice de gestiune funcţionează pe platforme omogene sau
eterogene, ceea ce ridică o problemă suplimentară, aceea a tranzitării datelor
şi a solicitărilor de la o platformă la alta;

7. sistemul informaţional evoluează pentru a răspunde schimbărilor survenite

în organizarea şi realizarea activităţilor din organizaţie, a modificărilor în
orientările strategice şi de management etc; această evoluţie antrenează fie
modificări şi adaptări corespunzătoare ale sistemelor informatice de gestiune
aflate în funcţiune, fie înlocuirea acestora cu altele noi, corespunzătoare noilor
cerinţe;

8. sistemele informatice trebuie să se adapteze la evoluţia platformei

sau platformelor – noi generaţii şi versiuni ale sistemului sau sistemelor de
operare, ale sistemului sau sistemelor de gestiune a bazelor de date, înlocuirea
unor echipamente, modificări în configuraţia sistemelor de comunicaţie.
Această adaptare nu trebuie să fie sesizabilă de către sistemul informaţional al
organizaţiei decât ca o îmbunătăţire a performanţelor de exploatare, fără a
afecta funcţionalităţile şi coerenţa datelor deja memorate.

1.2.3 Managementul afacerii şi tehnologia informaţiei

În prezent, u n avantaj concurenţial semnificativ este asigurat prin utilizarea unui

puternic suport informaţional, bazat pe cele mai noi instrumente ale tehnologiei informaţiei
(TI).
Modul de desfăşurare a afacerii în cadrul oricărei organizaţii este influenţat prin
acţiunea conjugată a mai multor factori, cum ar fi:
• globalizarea;
• competiţia de nivel înalt;
• informaţia, devenită resursă organizaţională cheie;
• derularea activităţii în condiţiile companiei virtuale;
• comerţul electronic;
• existenţa, în cadrul firmei, a personalului specializat în procesarea datelor şi
analiză (knowledge worker);
• un nou tip de relaţie cu banca, prin care se obţin servicii şi produse noi, ca
urmare a promovării noilor soluţii TI etc.

TI oferă soluţii pentru reingineria modului de organizare a afacerii cu scopul menţinerii

competitivităţii.
Reingineria presupune regândirea şi reproiectarea proceselor d e afaceri, pentru
obţinerea de îmbunătăţiri substanţiale privind costurile, calitatea, viteza de reacţie a
decidenţilor. Reingineria aplicată modului de a face afaceri este influenţată şi găseşte,
totodată, răspunsuri în noile soluţii TI.
 În elaborarea strategiei de afaceri este necesară asimilarea următoarelor premise:
• în conducerea şi controlul activităţii organizaţiei, sistemul informatic furnizează
informaţii esenţiale;
• sistemele informatice sunt deschise şi flexibile;
• promovarea soluţiilor TI susţine organizaţia în consolidarea şi dezvoltarea
afacerii (de exemplu, comerţul electronic, e-banking etc);
• sistemul informatic oferă informaţiile necesare controlului, îndeplinirii şi
adaptării planurilor operaţionale şi strategice ale organizaţiei;
• organizaţia trebuie să cunoască şi să controleze riscurile asociate implementării
noilor tehnologii şi adaptării sistemului informatic la noile cerinţe;
• stabilirea unor standarde privind metodologiile şi elementele TI - hardware şi
software de utilizat în dezvoltarea sistemului informatic.

Figura Error! No text of specified style in document..2.Tipuri de sisteme informatice şi

utilizatorii acestora

Sistemul informatic se structurează astfel încât să corespundă necesităţilor mai multor

grupuri de utilizatori (Figura Error! No text of specified style in document..2).
Nivelurile managementului strategic şi tactic se caracterizează prin solicitarea de
informaţii:
• ad hoc, neanticipate, determinate de un anumit context creat, în care
managerul este obligat să-şi fundamenteze decizia;
• sintetizate, după o selecţie şi o sintetizare treptate;
• previzionale, permiţând anticiparea tendinţelor de evoluţie a procesului condus;
• externe, care să definească mediul economic, financiar, concurenţial al
companiei.
În cazul managementului operaţional, căruia îi sunt caracteristice deciziile structurate,
informaţiile oferite sunt:
• de rutină;
• detaliate, privind modul de derulare a activităţii dintr-o arie de responsabilitate;
• interne;
• punctuale;
• cu caracter istoric;
• cu o frecvenţă bine definită de obţinere, momentul furnizării informaţiilor fiind
prestabilit.
 În contextul tuturor acestor elemente, sistemul informatic de gestiune include:
• ansamblul informaţiilor interne şi externe, formale sau informale utilizate în
cadrul organizaţiei, precum şi datele care au stat la baza obţinerii lor;
• software-ul necesar procesării datelor şi difuzării informaţiilor în cadrul
organizaţiei (software de aplicaţie sau produse program);
• procedurile şi tehnicile de obţinere (pe baza datelor primare) şi de difuzare a
informaţiilor;
• platforma hardware şi software necesară prelucrării datelor şi diseminării
informaţiilor;
• documentaţii destinate personalului specializat în culegerea, transmiterea,
stocarea şi prelucrarea datelor.

1.2.4 Clasificarea sistemelor informatice

Sistemele informatice pot fi clasificate în funcţie de diverse criterii.

După aria de cuprindere:

• Subsisteme informatice acoperind arii distincte, definite pe criterii funcţionale în
cadrul organizaţiei:
• subsistemul producţiei;
• subsistemul comercial;
• subsistemul resurselor umane.
• subsistemul contabilităţii;
• subsistemul financiar etc.;

• Subsisteme inter-organizaţionale, concepute să asigure fluxuri informaţionale

între:
• organizaţie şi partenerii săi (furnizori, clienţi, bancă etc): e-banking,
comerţ electronic etc.;
• firma-mamă şi subdiviziunile sale organizatorice.

Ariile funcţionale şi fluxurile informaţionale menţionate pot fi tratate independent sau

integrat. Pentru acestea din urmă, se disting:
• sistemele integrate de gestionare a resurselor (ERP Enterprise Resource
Planning);
• sistemele de e-business.

După natura activităţilor susţinute:

• Sisteme destinate conducerii (MSS - Management Support Systems), care
cuprind:
• sisteme destinate conducerii curente (MIS – Management Information
Systems);
• sisteme suport pentru decizii (DSS – Decision Support Systems),
probabilistice ori deterministe, de optimizare ori descriptive;
• sisteme informatice executive (EIS – Executive Information Systems).
• Sisteme destinate nivelului operaţional:
• sisteme destinate activităţii de birou (OAS – Office Automation
Systems);
 • sisteme pentru procesarea tranzacţiilor (TPS – Transaction Processing
Systems);
• sisteme pentru controlul proceselor (PCS – Process Control Systems).
• Sisteme destinate gestiunii cunoştinţelor (KWS – Knowledge Work Systems)

1.2.5 Arhitectura sistemelor informatice de gestiune

Termenul arhitectură se referă, în acest context, la aspectele de structurare și de

organizare generală. Este necesară, în primul rând, distincţia între arhitectura sistemului
informatic şi arhitectura software-ului aplicativ, care este doar o parte din acesta. În al
doilea rând, complexitatea celor două face să nu poată fi abordate dintr-o singură
perspectivă. În consecinţă, atât pentru unul cât şi pentru celălalt, există, inevitabil, mai
multe arhitecturi, care nu sunt altceva decât reprezentări ale aceluiaşi „produs”, din puncte
de vedere diferite. Pentru a putea întreprinde o asemenea delimitare, este necesar să se
recurgă la abstractizare. Modelarea este, în informatică, modalitatea cea mai folosită în acest
scop. În consecinţă, pentru acelaşi software aplicativ, respectiv acelaşi sistem informatic, se
definesc mai multe modele arhitecturale, care nu pot compune, decât împreună, imaginea
completă a acestuia.
În literatura de specialitate, sistemele informatice de gestiune sunt abordate:
a) din perspectiva informaţiei şi a suportului acesteia;
b) din perspectiva funcţiei asociate sistemul.
În primul caz, sistemele informatice de gestiune reprezintă ansamblul informaţiilor
utilizate în cadrul firmei, a mijloacelor şi procedurilor de identificare, culegere, stocare şi
prelucrare a informaţiilor.
În cea de a doua abordare, se analizează scopul acestora: furnizarea informaţiei
solicitate de utilizator în forma dorită şi la momentul oportun, în vederea fundamentării
deciziilor.

Sistemele informatice de gestiune (SIG) presupun definirea domeniilor de gestiune, a

datelor, modelelor, regulilor de gestiune.

Domeniile de gestiune corespund fiecăreia dintre activităţile omogene

desfăşurate în cadrul organizaţiei - cercetare-dezvoltare, comercială, de producţie, de
personal, financiar-contabilă – cu luarea în considerare a interacţiunilor dintre ele.
Abordarea acestor domenii se realizează într-o viziune ierarhică, pe următoarele niveluri:
• Tranzacţional, în cadrul căruia se efectuează operaţii elementare;
• Operaţional, unde se desfăşoară operaţii curente; deciziile luate la acest
nivel sunt curente, de rutină;
• Tactic, corespunzând activităţilor de control şi deciziilor pe termen scurt;
• Strategic, caracteristic deciziilor pe termen lung şi/sau care angajează global
organizaţia.

Datele reprezintă „materia primă” a oricărui sistem informatic de gestiune. Prin

excelenţă, SIG sunt sisteme care tratează intensiv volume mari şi foarte mari de date.

Modelele de gestiune regrupează procedurile proprii unui domeniu (de exemplu,

modelul contabil, specific domeniului financiar-contabil; tehnologia de fabricaţie, specifică
domeniului producţiei; modelul vânzărilor, specific domeniului comercial etc.).
 Regulile de gestiune cuprind normele, condiţiile, limitările fixate şi aplicate de
conducerea organizaţiei, respectiv a domeniului respectiv, pentru desfăşurarea activităţilor
curente.

Prin noţiunea de domeniu, se ajunge la conceptul de subsistem informatic de

gestiune, determinat pe criterii funcţionale, pe care se grefează celelalte două concepte:
modelul de gestiune şi regulile de gestiune.

Sistemele informatice de gestiune actuale aplică principiul preluării unice a datelor şi

prelucrării multiple a acestora în concordanţă cu nevoile informaţionale specifice fiecărui
utilizator. Pentru contabilitate, spre exemplu, datele din fiecare document primar sunt
preluate și actualizează baza de date unică, din care sunt, pe măsura necesităţilor, extrase
și prelucrate datele necesare atât pentru lucrările specifice contabilităţii financiare
(Consultare 2 - Figura Error! No text of specified style in document..3) cât şi pentru
contabilitatea de gestiune (Consultare 1 -Figura Error! No text of specified style in
document..3).

Figura Error! No text of specified style in document..3. Structura generică a SIG pentru
contabilitate

În realizarea unui sistem informatic, se poate opta pentru una din următoarele soluţii
arhitecturale:
• sistem informatic centralizat;
• sistem informatic descentralizat.

Sistemul informatic centralizat se caracterizează prin faptul că întregul proces de

stocare şi prelucrare a datelor, precum şi de dezvoltare a sistemului, se realizează la nivelul
unui singur sistem electronic de calcul (de regulă, un mainframe), care stochează o bază de
date unică, precum şi ansamblul programelor de aplicaţie. Utilizatorii interacţionează cu
sistemul prin intermediul terminalelor de lucru.

Avantajele centralizării sunt reprezentate de:

• controlul efectiv asupra utilizării şi dezvoltării software-ului;
• controlul asupra securităţii şi integrităţii datelor;
• partajarea resurselor şi a datelor între utilizatori;
• eliminarea riscului incompatibilităţii hardware şi software în cadrul sistemului;
 • promovarea cu uşurinţă a standardelor (tehnice, de proiectare, procedurale
etc) la nivelul întregului sistem;
• asigurarea serviciilor solicitate de către utilizatori prin puterea de calcul a
sistemului central (mainframe-ul).

Dezavantaje ale centralizării pot fi:

• „căderea” sistemului de calcul blochează toţi utilizatorii;
• alterarea datelor şi a programelor, voită sau accidentală, afectează toţi
utilizatorii;
• sistemul se poate dovedi lent şi inflexibil la nevoile utilizatorilor, adesea fiind
insuficient adaptat nevoilor locale sau de grup ale utilizatorilor;
• poate înregistra un timp mare de răspuns, în cazul unor solicitări simultane ale
mai multor utilizatori.

În cazul sistemelor informatice descentralizate, elementele software şi puterea de

calcul sunt dispersate în diferite locaţii ( site-uri) ale organizaţiei. Prelucrarea se realizează
pe calculatoare personale independente sau în cadrul unor reţele locale.

Avantajele descentralizării:
• datele sunt stocate şi prelucrate local;
• aplicaţiile sunt mai bine adaptate nevoilor locale;
• defecţiuni ale bazei de date la nivelul unei locaţii nu afectează celelalte locaţii;
• configuraţia sistemului poate fi gândită în funcţie de nevoile diferitelor
departamente din cadrul organizaţiei sau chiar a utilizatorilor locali;
• mai marea autonomie şi motivare la nivelul utilizatorului local.
Dezavantajele descentralizării:
• riscuri mari legate de incompatibilităţi hardware şi software între diferite locaţii;
• apariţia inerentă a unor duplicări ale datelor şi aplicaţiilor în diferite locaţii;
• dificultatea realizării unor proiecte complexe la nivel local;
• riscul de fragmentare a politicii TI;
• costuri mai mari în comparaţie cu sistemul centralizat.
Tendinţa actuală este net orientată către descentralizare, care trebuie să se realizeze
astfel încât:
• întreaga responsabilitate şi autoritate pentru funcţiile descentralizate ale SI să
aparţină managementului local;
• să se asigure alinierea la standardele utilizate la nivelul SI global al
organizaţiei;
• la nivel central, să se asigure:
- elaborarea strategiei la nivelul întregului SI al organizaţiei;
- managementul comunicaţiilor în cadrul reţelei locale ale organizaţiei;
- administrarea datelor;
- refacerea în caz de defecţiuni ale echipamentelor.

Astăzi, arhitectura promovată în realizarea sistemelor descentralizate este

arhitectura client- server, caracterizată prin faptul că aplicaţiile şi datele puse la
dispoziţia utilizatorilor sunt dispersate pe diferitele componente hardware în funcţie de
numărul utilizatorilor care trebuie să aibă acces şi de puterea de calcul necesară.
Componentele hardware sunt reprezentate de:
• staţii de lucru (calculatoare personale), folosite de utilizatori individuali;
• servere departamentale, partajate de utilizatori caracterizaţi prin aceleaşi nevoi
de prelucrare;
• server central, partajat de toţi utilizatorii.
 Software-ul exploatat în cadrul organizaţiei este reprezentat de:
• Aplicaţiile la nivelul clienţilor, care:
• rulează pe staţia de lucru pusă la dispoziţia clientului;
• exploatează date stocate pe calculatorul clientului;
• sunt reprezentate, în principal, de: procesoare de tabele, procesoare de
texte, aplicaţii exploatând baze de date.
• Aplicaţii departamentale; acestea:
• rulează pe serverul departamental;
• exploatează la nivelul departamentului, datele stocate pe serverul
acestuia;
• sunt partajate de utilizatorii aceluiaşi departament;
• Aplicaţii la nivelul organizaţiei, care:
• rulează pe serverul central;
• exploatează datele de interes general, stocate pe serverul central;
• sunt partajate de utilizatorii mai multor departamente;
• necesită putere mare de prelucrare.

1.2.6 Sisteme şi subsisteme

Din punct de vedere funcţional, sistemul informatic se descompune în subsisteme,

fiecare dintre acestea acoperind un domeniu.
La rândul său, fiecare subsistem se decupează în aplicaţii aferente activităţilor
distincte derulate în cadrul domeniului. De exemplu, subsistemul informatic pentru domeniul
comercial se va descompune în aplicaţii distincte pentru: aprovizionare, desfacere,
marketing.
Procesul de descompunere continuă şi, pentru fiecare aplicaţie, se vor defini proceduri
realizând funcţiuni distincte (de exemplu, proceduri pentru dirijarea prelucrărilor, proceduri
pentru actualizarea şi consultarea bazei de date). La rândul lor, procedurile se descompun în
module. Acestea cuprind secvenţe de cod corespunzătoare unei funcţii distincte în cadrul
procedurii. De exemplu, o procedură de actualizare a bazei de date va cuprinde: un modul
pentru adăugare de înregistrări, un modul de modificare a înregistrărilor, un modul de
ştergere a înregistrărilor.

În definirea arhitecturii unui SIG se recurge la una dintre următoarele strategii:

• abordarea descendentă sau top-down, centrată pe descompunerea SIG în
elemente de complexitate mai redusă, alcătuind o structură funcţional-
ierarhică;
• abordarea ascendentă sau bottom-up, centrată pe compunerea de
subsisteme dezvoltate independent pe fiecare domeniu de gestiune, de unde şi
riscul de a nu fi posibilă o bună integrare a aplicaţiilor la nivel de organizaţie;
• abordarea mixtă, care reprezintă o combinare a celor două menţionate
anterior; în acest demers, se optează pentru o primă definire a componentelor
sistemului informatic, aplicând strategia descendentă, urmată de conceprea şi
realizarea fiecăreia dintre aceste componente conform strategiei ascendente.
Indiferent de varianta selecţionată, trebuie să se ia în considerare că SIG trebuie să se
poată adapta, în timp, la schimbările ce vor surveni în exigenţele interne ori impuse din
mediul economic exterior, cu atât mai mult cu cât dinamismul mediului economic-social le
face foarte probabile. O astfel de abordare conduce la definirea de arhitecturi deschise
pentru sistemele informatice.
1.3 Procese de dezvoltare a sistemelor informatice de
gestiune

1.3.1 Ciclul de viaţă al sistemului

Introducerea unui SIG nu se rezumă la apariţia de noi programe aplicative şi, eventual,
de noi echipamente. Apariţia sa antrenează inevitabil modificări în procesele de business, în
gama, profilul şi sarcinile alocate posturilor de lucru, în organizarea activităţii şi, nu de puţine
ori, în comportamentul faţă de clienţi şi de ceilalţi parteneri.
La fel de valabilă este şi percepţia inversă şi anume recurgerea la sisteme informatice
noi sau la modificarea acestora ca suport al adaptării organizaţiei la provocările şi
oportunităţile apărute în mediul socio-economic, în evoluţie permanentă şi din ce în ce mai
rapidă.
Indiferent de natura lor, identificarea necesităţii acestor schimbări şi a modului în care
urmează a fi realizate aparţin managementului organizaţiei. Pornind de la problemele pe
care conducerea organizaţiei doreşte să le rezolve şi, în funcţie de ceea ce există în materie
de organizare, resurse, echipamente şi aplicaţii în funcţiune, se identifică obiectivele
urmărite, principalii utilizatori şi informaţiile de care trebuie să dispună aceştia, limitările,
restricţiile sau cerinţele tehnice şi, în raport cu toate acestea, modul de realizare: printr-un
sistem nou sau prin modificarea sistemului existent.
Din perspectiva organizaţiei, un sistem nou se poate obţine prin achiziţie sau prin
dezvoltare.
Achiziţia este aplicabilă dacă pe piaţă există o ofertă de software aplicativ de uz
general cu funcţionalităţile dorite. Acesta este un pachet de programe deja disponibil,
destinat, de la bun început cumpărării şi utilizării de către (cât) mai mulţi clienţi. Asemenea
produse se adresează domeniilor comune oricăror afaceri sau specifice unei anumite
industrii, cum sunt calculul salariilor, urmărirea stocurilor, contabilitatea financiară ş.a.m.d.
Ceea ce are de făcut organizaţia, în această situaţie, este să obţină o listă cât mai
completă a ofertelor de pe piaţă şi să aleagă acel produs şi acel furnizor de software care
răspund cel mai bine cerinţelor sale în materie de lucrări şi operaţii tratate, condiţii şi limite
de funcţionare, preţ, costuri de instalare şi exploatare ș.a.m.d. Furnizorul poate fi chiar
dezvoltatorul software-ului sau un terţ agreat.
Recurgerea la un produs program de uz general impune, înaintea începerii exploatării
propriu-zise, un proces de parametrizare şi adaptare la organizaţie dar, în acelaşi timp,
antrenează şi alinierea sistemului informaţional al organizaţiei la viziunea şi regulile după
care operează acesta, ceea ce trebuie avut în vedere şi examinat cu atenţie înaintea oricărei
decizii de achiziţie.
Dezvoltarea conduce la obţinerea unui sistem "personalizat*", conceput şi construit
conform nevoilor şi condiţiilor specifice organizaţiei. Are avantajul de a fi adaptat din start
acestora, dar costurile şi durata de obţinere vor fi mai mari. Modificarea unui sistem existent
poate fi făcută numai prin dezvoltare.
După obţinere, sistemul este lansat şi începe să fie utilizat în mod curent.
Lansarea în exploatare numită, de asemenea, introducere în producţie, asigură
amplasarea echipamentelor şi a reţelelor de comunicaţie (dacă este cazul), instalarea
software-ului de aplicaţie în structurile adecvate, crearea şi încărcarea iniţială a bazei sau
bazelor de date, instruirea utilizatorilor, testarea sistemului în condiţiile reale de utilizare etc.
Exploatarea curentă denotă perioada în care sistemul este folosit în cadrul
organizaţiei pentru efectuarea prelucrărilor şi obţinerea rezultatelor urmărite prin

*
Se mai foloseşte, în acest caz şi sintagma "sistem pe măsură".
introducerea sa. Deţine, în ansamblul existenţei sistemului, durata cea mai mare şi ia sfârşit
odată cu scoaterea definitivă din funcţiune şi înlocuirea cu un alt sistem.
În cursul exploatării curente apar situaţii care solicită intervenţii de menţinere în
funcţiune a sistemului. Acestea sunt determinate de două cauze principale:
• erori nesesizate în procesul dezvoltării, care trebuie eliminate;
• schimbări survenite în timp, la care sistemul trebuie să se adapteze, cum sunt
cele produse de evoluţia tehnologiilor folosite (echipamente şi programe).

Figura Error! No text of specified style in document..4 Ciclul de viaţă al sistemelor

informatice de gestiune cuprinde următoarele stadii: definirea necesităţii/oportunităţii, obţinerea,
introducerea în exploatare, exploatarea curentă şi menţinerea în funcţiune.

1.3.2 Activităţi de bază în dezvoltare

Diversitatea condițiilor în care are loc dezvoltarea unui sistem informatic de gestiune
are consecinţe directe asupra activităţilor necesare pentru realizarea sa.
Dincolo de această diveristate, există un set comun de procese de bază,
corespunzătoare logicii de realizare a sistemului ca produs uman: definirea cerinţelor pe
care trebuie să le satisfacă sistemul, proiectarea, construcţia şi testarea.
 Figura Error! No text of specified style in document..5 Activităţile de bază dezvoltarea
sistemelor informatice de gestiune

Definirea cerinţelor
Cerințele descriu comportamentul dorit al viitorului sistem, prin specificarea serviciilor
pe care acesta urmează să le asigure şi al condiţiilor şi restricţiilor de funcţionare.
Definirea cerinţelor este procesul în care beneficiarii sistemului şi echipa de dezvoltare
stabilesc împreună şi convin asupra produsului care urmează a fi realizat. Din perspectiva
beneficiarilor, se pot distinge două categorii de cerinţe: de business şi de utilizare.

Teoretic, proiectarea, construcţia şi testarea ar trebui să respecte în totalitate

specificaţia definită şi aprobată împreună cu beneficiarul, pentru a obţine software-ul şi
sistemul dorite. Practic a demonstrat însă că această aserţiune, în care specificaţia este
completă și rămâne valabilă până la obţinerea şi livrarea sistemului, este nerealistă.
Principalele motive ale acestei stări de fapt sunt următoarele:
• cererile se modifică în timp ce are loc proiectarea, construcţia şi tastarea
sistemului, din cauza schimbărilor survenite în mediul socio-economic în care
operează organizaţia, în obiectivele managementului, în legislaţia în vigoare,
ş.a.m.d.;
• cererile formulate iniţial sunt incomplete sau nu reflectă nevoile reale ale
utilizatorilor, deoarece aceştia nu realizează, decât după ce iau contact cu
viitorul sistem sau cu o parte a acestuia, noile condiţii de funcţionare,
posibilităţile şi oportunităţile oferite;
• cererile nu sunt corect interpretate şi înţelese din cauza dificultăţilor de
comunicare dintre utilizatori şi echipa de dezvoltare: semnificaţia precisă a
termenilor şi conceptelor de specialitate folosiţi de fiecare dintre părţi poate să
scape celeilalte, din cauza formaţiei şi experienţei lor profesionale diferite.

Constituind fundamentul viitorului sistem şi confruntându-se cu dificultăţile obiective

menţionate, definirea cerinţelor este considerat un proces critic pentru dezvoltarea
sistemelor informatice iar gestionarea sistematică, coordonată şi controlată a dinamicii
cerinţelor şi ajustării software-ului în curs de realizare la acestea conturează un domeniu
distinct de preocupare – managementul cerinţelor.

Proiectarea
Proiectarea are menirea de a defini o soluţie informatică care să răspundă cerinţelor
utilizatorilor. Aceasta înseamnă transpunerea cerinţelor într-un ansamblu de unităţi de
program (sau de programe) şi de date folosite de către acestea, care să fie executabile pe
tipul de platformă şi configuraţia avute în vedere.
Definirea cerințelor este procesul prin care viitorul sistem informatic sau software-ul de
aplicație este descris sub aspectul comportamentului pe care ar trebui să-l aibă faţă de
utilizatori şi faţă de restul sistemelor, de toate tipurile, pe care le va utiliza sau cu care va
interacţiona. În continuarea sa, proiectarea determină şi descrie ce elemente de natură
informatică, aflate deci în interiorul sistemului, sunt necesare pentru a asigura acest
comportament. Prin urmare, definirea cerinţelor şi proiectarea realizează, împreună,
conceperea sistemului (Figura Error! No text of specified style in document..5).

Construirea
Construirea (numită de asemenea, implementare), porneşte de la elementele definite
în cursul proiectării şi asigură crearea programelor de calculator şi a procedurile informatice
necesare, până la forma finală, cea executabilă.
Scrierea programelor este departe de a fi o muncă mecanică. Înaintea formulării în
structurile sintactice cerute de limbajul de programare folosit, orice situaţie, orice acţiune,
orice funcţionalitate trebuie gândită, rafinată în cele mai mici detalii. Ceea ce la nivelul
proiectării face obiectul unei fraze sau aserţiuni, poate genera, la nivelul scrierii programului,
mai multe module, având fiecare zeci sau sute de linii de cod. Acest efort de detaliere, de
rafinare, de definire este, de asemenea, de natura proiectării, dar pe un alt nivel şi la o altă
scară.
Trecerea în forma executabilă a textului de program sursă este automatizată, fiind
efectuată de programe de calculator specializate şi, în funcţie de mediul informatic utilizat,
trebuie cerută explicit sau se poate realiza implicit, în totală transparenţă pentru cel care
lucrează.

Testarea
Testarea este cea care face validarea proiectării şi se află, în consecinţă, în aceeaşi
situaţie: pentru a fi realizată, trebuie concepută în prealabil, şi aceasta în strictă corelaţie cu
modul în care s-a proiectat funcţionarea sistemului, de la nivelul cel mai general până la cel
mai detaliat.
Disfuncţionaltăţile şi erorile constatate la testare sunt înlăturate prin modificarea
adecvată a programelor sursă, după care noile programe sunt aduse din nou în forma
executabilă şi verificate şi acest ciclu se repetă până când se ajunge la funcţionarea dorită.
Identificarea sursei erorilor şi disfuncţionalităţilor şi înlăturarea lor presupune revenirea
la oricare dintre nivelele de proiectare, inclusiv la programele sursă şi implică un efort
creator, care conduce la ajustarea, la amelioarea proiectului.
După ce programele sursă au fost testate şi corectate (puse la punct), se generează
formatul executabil final, ce se livrează alături de documentaţia de utilizare şi de exploatare
a sistemului.

1.3.3 Activităţi suport

Demersul concret de dezvoltare a sistemului, care utilizează şi consumă resurse,
trebuie să fie gestionat, pentru a se asigura încadrarea în limitele de timp şi cheltuieli fixate
şi obţinerea unui produs de calitate. Există, prin urmare, un proces complementar, de
management al proiectului. La acesta se adaugă o serie de alte procese, cu rolul de a
susţine dezvoltarea sistemului: managementul calităţii, verificarea şi validarea, gestiunea
configuraţiei, documentarea.

Managementul proiectului cuprinde suita de activităţi necesare constituirii echipei

de dezvoltare, stabilirii setului de metrici utilizat pentru cuantificarea şi evaluarea efortului de
dezvoltare a sistemului, planificării şi urmăririi curente a derulării proiectului. Pricipalele
aspecte urmărite privesc asigurarea şi utilizarea resurselor umane, financiare şi materiale,
încadrarea în termene, monitorizarea şi diminuarea, respectiv, eliminarea riscurilor

Managementul calităţii are menirea de a asigura o cât mai bună calitate a

software-ului produs. În acest scop, se recurge la definirea unui set de proceduri
organizaţionale şi standarde privitoare la activităţile efectuate şi la rezultatele intermediare şi
finale furnizate de echipa de dezvoltare, şi, bineînţeles, la urmărirea permanentă a
respectării acestora şi, dacă este necesar, a operării ajustărilor necesare.

Validarea și verificarea, ca proces, include două aspecte esenţiale pentru realizarea

software-ului de aplicaţie: faptul că în cursul proiectării şi construcţiei se respectă cerinţele
formulate iniţial (validarea) şi faptul că aceste cerinţe şi software-ul realizat pe baza lor
corespund nevoilor sau aşteptărilor reale ale viitorilor utilizatori (verificarea). Există, aşadar,
o diferenţă netă între semnificaţia celor doi termeni care apar în denumirea procesului şi, nu
mai puţin, în modul concret în care se efectuează şi în implicaţiile pe care le au asupra
rezultatului final.

Gestionarea configuraţiei se concentrează asupra evoluţiei software-ului de

aplicaţie, respectiv a variantelor şi versiunilor interne şi a versiunilor livrate utilizatorilor.
Pentru facilitarea construirii, se recurge la descompunerea sistemului în părţi de întindere şi
complexitate limitate, abordate succesiv sau în paralel, de grupuri diferite din cadrul echipei
de dezvoltare. Erorile sau deficienţele constatate în urma testărilor unitare şi de integrare
sunt corectate sau eliminate, obţinându-se noi versiuni sau variante, care intră din nou în
testare şi integrare. Produsul final sau părţi mai mari ale acestuia se obţin prin asamblarea
acestor unităţi, după care sunt supuse testării şi controalelor de calitate. Acele componente
care au erori sau deficienţe sunt remediate, obţinând noi versiuni sau variante, care
participă din nou la asamblare. Prin urmare, o nouă versiune apare în urma efectuării de
corecţii, în urma adăugării de noi funcţionalităţi sau ca o consecinţă a modificării cerinţelor
(şi, prin urmare, şi a proiectului sau unei părţi a acestuia). De asemenea, pot fi produse
versiuni distincte atunci când anumite componente sau întregul sistem urmează a fi
exploatate pe platforme informatice diferite. Rezultatul obţinut prin asamblarea anumitor
versiuni ale componentelor constituie, la rândul său, o nouă versiune a sistemului sau a unui
subsistem, livrabilă către utilizator sau cu caracter intern, de lucru. Cum aceste versiuni pot
fi numeroase şi pot apărea cu frecvenţă mare, este necesară o gestionare strictă a lor, ceea
ce face obiectul acestui proces, cu atât mai mult cu cât evoluţia continuă şi în cursul
exploatării curente, prin intervenţiile de întreţinere sau menţinere în funcţiune.

Documentarea este procesul consacrat elaborării și menținerii la zi a documentației

privitoare la sistem. Există două categorii majore de documentaţie: cea internă, destinată
membrilor echipei de dezvoltare şi, ulterior, de întreţinere, care cuprinde toate detaliile
tehnice privitoare la conceperea şi realizarea sistemului şi cea de utilizare (manualele
produsului software), care oferă toate detaliile necesare instalării, folosirii în realizarea
lucrărilor curente şi administrării sale la beneficiar. Deşi uneori neglijată, documentaţia este
una dintre piesele esenţiale, atât pentru dezvoltare, cât şi pentru operarea curentă. Formele
şi momentele în care se realizează sunt diverse şi, pentru obţinerea unui nivel adecvat de
calitate, pot face obiectul unor reguli şi standarde interne.

1.3.4 Nivele de abstractizare în dezvoltarea sistemelor informatice

de gestiune
 Un software de aplicaţie constituie o soluţie bazată pe tehnologii ale informaţiei pentru
un anume grup de cerinţe formulate de către utilizator.
Indiferent de natura utilizatorului – individualizat sau generic (aşa cum este cazul
produselor de tip pachet), termenii cu care operează cerinţele - de genul clienţi, produse,
comenzi, facturi, plăţi, conturi, debitări, creditări etc - aparţin unui anumit domeniu, activităţi
sau profesii, care formează spaţiul problemei. Conceptele, termenii, scopurile, procesele
de prelucrare sunt extrem de variate şi depind de domeniul în care operează organizaţia şi
de specificitatea acesteia: spre exemplu, cu totul altele vor fi problemele cu care se
confruntă o bancă decât cele aferente unui spaţiu comercial de mari dimensiuni sau ale unei
companii aeriene.
Rezolvarea pe care software-ul o aduce acestor cerinţe operează cu concepte, termeni
şi "obiecte" total diferite – de genul baze de date, table, chei primare şi externe, interogări,
unităţi de program, evenimente declanşatoare ş.a.m.d. – specifice tehnologiilor informatice
şi de comunicaţie folosite, care formează spaţiul soluţiei. Soluţia livrată trebuie să
funcţioneze pe o anumită platformă informatică. Platformele sunt diverse, având fiecare
propriile particularităţi, limitări, restricţii şi compatibilităţi, care trebuie luate în considerare şi
încorporate în software-ul aplicativ livrat.
Cele două spaţii sunt net diferite, atât din punct de vedere al conceptelor folosite, cât
şi al comportamentului şi funcţionării. Golul semantic dintre ele este acoperit de către echipa
de dezvoltare printr-un demers intelectual de punere în corespondenţă, de traducere a
fiecărui element din spaţiul problemei, evocat de cerinţe, în termenii şi structurile specifice
spaţiului soluţiei.
Utilizatorul formulează cerinţele faţă de viitorul sistem în termeni specifici activităţii sau
sarcinilor sale profesionale. Aceşti termeni diferă de la un domeniu de activitate la altul.
Pentru o diversitate practic nelimitată de activităţi, domenii şi profesii, spaţiul soluţiei este
unic, fiind acela al tehnologiilor informatice. Este necesar, prin urmare, să se obţină o
reprezentare uniformă a cerinţelor, în care detaliile şi particularităţile fiecărui domeniu şi
activitate să fie exprimate printr-un set similar şi limitat de concepte. Reprezentarea astfel
obţinută este denumită conceptuală, în sensul că ignoră orice detaliu de tehnologie a
informaţiei, cu excepţia prezenţei subînţelese, implicite a recurgerii la aceasta.
Reprezentarea conceptuală este o abstractizare a realităţii de la utilizator. Pentru
fiecare sistem şi caz în parte va exista câte o reprezentare specifică, particulară, proprie, dar
toate acestea recurg la acelaşi set de concepte şi tehnici. O asemenea expresie abstractizată
formează modelul conceptual al viitorului sistem.
Trecând în domeniul soluţiei, vom regăsi şi aici o mare diversitate de elemente de
tehnologie informaţională. Există, la nivel fizic, mai multe platforme, aducând fiecare
propriile caracteristici, particularităţi, puncte forte şi puncte slabe, de care trebuie ţinut
seama la realizarea sistemului. În spaţiul acestor particularităţi, gradul de complexitate adus
de interacţiunile dintre programe şi componente software este foarte ridicat, ceea ce face
foarte dificilă şi riscantă tentativa de a trece direct la realizarea software-ului urmărit. Soluţia
rezidă, şi în acest caz, în abstractizare. Elementele şi detaliile diverselor tehnologii ale
informaţiei sunt reduse la un set uniform şi limitat de concepte şi reprezentări. Această
abstractizare este denumită, mai curând din raţiuni istorice, logică, iar expresia soluţiei
informatice definită, concepută pe acest nivel pentru software-ul aplicativ urmărit constituie
modelul logic al acestuia.
 Figura Error! No text of specified style in document..6 Abstractizarea cerinţelor şi a
caracteristicilor tehnologiilor informatice simplifică trecerea de la spaţiul problemei la spaţiul soluţiei

Deoarece atât reprezentarea conceptuală cât şi cea logică recurg la seturi limitate şi
predeterminate de concepte şi tehnici, punerea lor în corespondenţă este ușurată şi, ceea ce
este mai important, poate fi dirijată de reguli studiate în cadru general şi care să ofere un
grad ridicat de siguranţă privitor la corectitudinea traducerii, a tranzitării de la una la
cealaltă.
Conceperea se face parcurgând aceste trei nivele de abstractizare în ordinea
conceptual – logic – fizic iar rezultatele obţinute formează modele ale viitorului sistem.

Figura Error! No text of specified style in document..7 Suita stadiilor urmate în

dezvoltarea sistemelor informatice de gestiune
 Cerinţele formulate pentru viitorul sistem sunt reprezentate în modelul conceptual. Din
acesta derivă, prin transformare şi detaliere, modelul logic al sistemului. Urmează adaptarea
modelului logic la particularităţile platformei/platformelor adoptate pentru realizare şi
execuţie şi dezvoltarea detaliilor necesare pentru construcţia sistemului.
Definirea cerințelor este, din această perspectivă, procesul dedicat modelării
conceptuale a viitorului sistem. Nivelele logic şi fizic delimitează două stadii succesive ale
proiectării, numite, respectiv, proiectare generală şi proiectare de detaliu. Proiectarea
generală mai este denumită "de ansamblu" iar proiectarea de detaliu mai este denumită
"tehnică".

1.3.5 Date şi prelucrări

Funcţionalităţile oferite utilizatorilor reprezintă, din punct de vedere al sistemului

informatic, prelucrări pentru a căror efectuare sunt necesare anumite date.
Practica a demonstrat că este mult mai utilă prevederea, de la bun început, a unei
configuraţii a datelor care să ofere o reprezentare fidelă a ariei de business ce face obiectul
său, independent de exigenţele particulare ale uneia sau alteia dintre prelucrări. Acest lucru
este cu atât mai adevărat cu cât s-a constat că cerinţele de prelucrare se modifică frecvent,
în mod obiectiv, în timp ce structura datelor, fiind dependentă numai de natura activităţii sau
activităţilor organizaţiei, rămâne stabilă şi se modifică doar atunci când business-ul se
schimbă. În această viziune, datele se delimitează de prelucrări.

Datele şi prelucrările sunt studiate şi modelate separat, în paralel, pe fiecare

dintre cele trei nivele - conceptual, logic şi fizic - cu puncte periodice de confruntare şi
corelare.

Modelarea datelor vizează conţinutul şi structura „memoriei” sistemului, definite la

nivel conceptual şi transpusă apoi în formele cerute de constituirea sa informatică, pe
nivelele logic şi fizic.
Modelul conceptual al datelor are menirea de a prezenta conceptele cu care se
operează în domeniul problemei, legăturile semantice ce se stabilesc între acestea,
proprietăţile sau caracteristicile prin care sunt descrise şi caracterizate, regulile de gestiune
aplicate.
Modelul logic al datelor descrie structurile de memorare informatică a datelor,
stabilite în funcţie de tipul tehnologiilor de gestionare şi de prelucrare avute în vedere.
Modelul fizic al datelor dă reprezentarea structurii finale a bazei sau bazelor de
date în termenii SGBD folosit, după ce aceasta a fost adaptată la caracteristicile de volum şi
periodicitate ale operaţiilor de actualizare şi consultare la care va participa efectiv.

Modelarea prelucrărilor urmează un traseu asemănător, cu deosebirea că aici operează

în primul rând principiul descompunerii şi recompunerii, pe o scală ce porneşte de la lucrările
umane de informatizat şi se încheie cu delimitarea şi definirea unităţilor de program
executabil, a amplasării şi interacţiunilor dintre acestea.
Modelul conceptual al prelucrărilor descrie funcţionarea urmărită în domeniul
problemei, cu specificarea lucrărilor ce vor fi preluate sau asistate de viitorul sistem
informatic şi a resurselor materiale şi umane mobilizate în acest scop.
Modelul logic al prelucrărilor prezintă modul în care este concepută din
perspectivă informatică efectuarea lucrărilor stabilite pe nivelul precedent. Aceasta conduce
la descopunerea fiecărei utilizări unitare şi coerente a sistemului de către personalul
organizaţiei în unităţi de prelucrare coerente informatic.
 Modelul fizic al prelucrărilor dă expresie transpunerii unităţilor logice de prelucrare
în spaţiul platformei de dezvoltare şi de exploatare, luând în considerare caracteristicile
limbajului de programare folosit, aspectele de modularizare şi de distribuire fizică a
prelucrărilor ş.a.m.d.

Această viziune, axată pe existenţa a două tipuri de componente – memoria, respectiv

datele stocate informatic şi prelucrările care recurg la ea sau o menţin la zi – nu este unica
practicată. O a doua viziune, de dată mai recentă, apelează la un singur tip de componentă
– obiectul (informatic) - care reuneşte, în spatele unei bariere virtual impenetrabile, un
anumit grup de date şi prelucrări cu ajutorul cărora reacţionează la stimuli. Această viziune a
preluat numele componentei sale definitorii, fiind referită prin sintagma abordare obiectuală
sau bazată pe obiecte.
Abordarea obiectuală a sistemelor informatice de gestiune este studiată la o altă
disciplină, în cadrul ciclului de materat.

1.3.6 Modele ale procesului de dezvoltare a sistemelor informatice

În căutarea unor soluţii de accelerare a dezvoltării sistemelor informatice şi a

ameliorării continue a managementului acestora, în paralel cu acumularea de experienţă şi
cu evoluţia conceptelor şi instrumentelor puse în lucru, au fost propuse mai multe modele de
proces. Aceste modele sunt abstractizări care avansează o anumită modalitate de definire şi
derulare în timp a activităţilor necesare dezvoltării sistemelor. Înaintea prezentării câtorva
dintre cele mai utilizate, sunt necesare două precizări:
• nu există un model ideal: în faţa diversităţii enorme de situaţii şi solicitări ce
apar în practică, trebuie ales modelul care se potriveşte cel mai bine fiecărui
caz în parte;
• modelele pot fi combinate, scopul fiind acela de a obţine rapid, cu riscuri şi
costuri cât mai reduse, sistemele aşteptate de utilizatori şi nu acela de a
respecta riguros demersul propus de un model sau altul.

1.3.6.1 Modelul în cascadă

Modelul în cascadă (Waterfall Model) a fost elaborat de W.W. Royce la începutul
anilor ’70. Este un model frecvent invocat în literatura de specialitate, caracterizat prin
parcurgerea secvenţială a fazelor ciclului de viaţă, faze care la rândul lor sunt formate din
activităţi, iar acestea din urmă din subactivităţi.
 Figura Error! No text of specified style in document..8 Modelul în cascadă

Modelul prezintă următoarele avantaje:

• controlul total al fazelor, datorită modului de ordonare a acestora;
• uşor de însuşit de către membrii echipelor de analiză şi proiectare;
• fiecare fază se încheie cu o verificare a soluţiei oferite şi asigură o
documentaţie prezentând soluţia elaborată.
În timp au fost propuse variante îmbunătăţite ale modelului:
• modelul cu revenire la pasul anterior (waterfall model with back flow);
• modelul cu reluare de la faza iniţială („Da Capo” Waterfall Model).

În versiuni mai noi ale modelului în cascadă, primele faze grupează activităţi specifice
gestiunii proiectului aceste elemente lipsind în modelul iniţial.
Modelul prezintă următoarele avantaje:
• controlul total al fazelor, datorită modului de ordonare a acestora;
• uşor de însuşit de către membrii echipelor de analiză şi proiectare;
• fiecare fază se încheie cu o verificare a soluţiei oferite şi asigură o
documentaţie prezentând soluţia elaborată.
În timp au fost propuse variante îmbunătăţite ale modelului:
• modelul cu revenire la pasul anterior (waterfall model with back flow);
• modelul cu reluare de la faza iniţială („Da Capo” Waterfall Model).
1.3.6.2 Modelul în V

Modelul în V este o variantă a modelului cascadă care aduce elemente calitative noi
importante. Un element caracteristic al modelului este introducerea conceptelor de sistem şi
component (subsisteme) aplicându-se teste explicite pentru creşterea controlului asupra
modului în care se desfăşoară etapele. Fazele plasate în partea superioară a modelului se
caracterizează prin implicarea directă a viitorului utilizator.

Braţul stâng al diagramei, parcurs descendent, reuneşte fazele în cadrul cărora se

realizează, pas cu pas, proiectarea şi realizarea sistemului informatic. Detalierea
activităţilor de proiectare, codificare şi asamblare a componentelor se realizează gradual.
Braţul drept al diagramei cuprinde reprezentarea fazelor asigurând asamblarea
progresivă a componentelor sistemului pe măsura testării lor individuale, până la obţinerea
sistemului global şi acceptarea acestuia de către beneficiar.
În cadrul modelului se remarcă realizarea distincţiei dintre verificare şi validare. Prima
se referă la testarea sistemului în diversele stadii pe care le parcurge, iar validarea
urmăreşte să identifice în ce măsură sistemul corespunde cerinţelor iniţiale, ceea ce
constituie un punct slab al modelului datorită întârzierii cu care se produce această
validare.
 Figura Error! No text of specified style in document..9 Modelul în V

1.3.6.3 Modelul incremental

Modelul incremental este o altă variantă a modelului cascadă care promovează ideea
proiectării şi realizării independente a componentelor după definirea arhitecturii globale a
sistemului informatic. Proiectarea şi realizarea se realizează astfel în conformitate cu
principiile metodelor top - down. Sistemul va putea fi livrat beneficiarului şi etapizat pe
măsura realizării componentelor (în funcţie de priorităţile formulate de beneficiar) dar
într-o astfel de abordare pot apărea dificultăţi legate de integrarea componentelor în
sistemul final.
 Figura Error! No text of specified style in document..10 Modelul incremental

În figura Error! No text of specified style in document..10, unde este prezentat

schematic modelul, se observă faptul că primele două etape – definirea cerinţelor şi
analiza – sunt identice cu cele două etape de început ale modelului cascadă, însă din
momentul definirii arhitecturii SI fiecare componentă îşi urmează propriul ciclu de viaţă.
Spre deosebire de modelul în V care presupunea integrarea componentelor, testarea şi
validarea acestuia, de această dată se oferă şi posibilitatea livrării independente a
componentelor SI către beneficiar fără a se exclude şi posibilitatea livrării SI final având
toate componentele integrate.
1.3.6.4 Modelul spirală

Figura Error! No text of specified style in document..11 Modelul în spirală

Modelul spirală, elaborat de Barry Boehm, se bazează pe acelaşi principiu ca şi

modelul evolutiv. Modelul presupune construirea mai multor prototipuri succesive în
condiţiile realizării unei analize a riscului pe fiecare nivel. Fazele de dezvoltare sunt
reluate la fiecare iteraţie în aceeaşi succesiune şi presupun:

1. analiza riscurilor;
2. realizarea unui prototip;
3. simularea şi testarea prototipului;
4. determinarea cerinţelor în urma rezultatelor testării;
 5. validarea cerinţelor;
6. planificarea ciclului următor.

Ultimul ciclu conduce la realizarea versiunii finale a sistemului informatic.

În centrul spiralei este plasată cunoaşterea cerinţelor şi estimarea costurilor la nivel
preliminar. Evoluţia SIG urmează desfăşurarea spiralei înregistrând acumulări succesive ale
costurilor şi este marcată de succesiunea prototipurilor, fiecare dintre acestea valorificând
acumulările realizate al nivelul prototipului anterior. Interacţiunea dintre faze nu este
reliefată direct atâta timp cât modelul prevede o succesiune continuă a rafinării legate de
decizii pe care riscurile proiectului le asociază cu următoarea detaliere.
Modelul evidenţiază atenţia acordată planificării, căutării de soluţii alternative,
evaluării riscurilor şi validării soluţiilor pentru fiecare prototip, văzut ca un stadiu distinct în
realizarea sistemului informatic.
Prototipul este folosit atât pentru identificarea cât şi pentru validarea cererilor
utilizatorilor, pentru verificarea soluţiei de proiectare şi constituirea bazei dezvoltării
ulterioare a proiectului de sistem informatic. Apelarea la prototip se explică prin aceea că un
model funcţional este mai uşor de înţeles de către viitorul utilizator decât un set de diagrame
însoţite de documentaţie.
Prototipul funcţional presupune proiectarea sistemului, realizarea primului prototip
funcţional, verificarea măsurii în care răspunde cererilor formulate de utilizator şi rafinarea
acestei prime soluţii, prin dezvoltări viitoare care adaugă noi funcţionalităţi până la obţinerea
variantei finale a sistemului.

1.3.6.5 Dezvoltarea rapidă

Dezvoltarea rapidă (RAD Rapid Application Development) a fost definită la începutul

anilor '90, în intenţia de a oferi o alternativă la abordările structurate. Denumirea ce i-a fost
atribuită evidenţiază orientarea sa de esenţă: obţinerea de software aplicativ care să
corespundă cerinţelor utilizatorilor, într-un interval cât mai scurt de timp.
Pentru atingerea acestui scop, se aplică un demers ce combină abordarea iterativă,
prototipurile şi instrumentele sau mediile de proiectare şi dezvoltare asistată de calculator
(CASE – Computer Aided Software Engineering).
Prototipurile sunt folosite esenţialmente pentru captarea cerinţelor viitorului sistem.
Dezvoltarea se face incremental, prin iteraţii succesive, fiecare dintre acestea fiind de
durată cât mai mică – între o zi şi trei săptămâni.
Una dintre premisele de bază ale acestei abordări constă în participarea activă a
utilizatorilor la dezvoltarea sistemului. În acest scop, se organizează sesiuni mixte de
proiectare – JAD Joint Application Development - la care participă utilizatorii şi echipa de
dezvoltare, în care se dezbat, se rafinează şi se acceptă rezultatele şi produsele fiecărei
iteraţii.
Pentru limitarea şi controlul duratei de dezvoltare, procesul recurge la o organizare
bazată pe o structură numită timebox – un interval strict, în cursul căruia trebuie obţinut un
rezultat (parte din produs) executabil şi livrabil. Un timebox este precedat de o sesiune
mixtă de definire şi planificare a funcţionalităţilor şi este urmată de o sesiune de evaluare a
rezultatului. Iteraţiile au loc în interiorul "cutiei" şi se bazează pe un mediu de dezvoltare de
prototipuri evolutive.
Ciclul de dezvoltare parcurge patru etape:
• planificarea cerinţelor;
• proiectarea funcţională;
• construirea;
 • instalarea la utilizator.

Figura Error! No text of specified style in document..12 Modelul de dezvoltare rapidă

Prima etapă, numită de asemenea "de definire a conceptelor", urmăreşte să delimiteze

aria de cuprindere a sistemului şi să identifice, în cadrul acesteia, funcţiile de business
vizate, procesele de prelucrare, entităţile structurale de bază şi interacţiunile dintre ele.
Durata este cuprinsă între una şi patru săptămâni şi se realizează cu participarea
utilizatorilor cheie.
Proiectarea funcţională urmăreşte să detalieze şi să precizeze cerinţele sistemului. În
acest scop, se organizează mai multe sesiuni mixte de proiectare, cu participarea echipei de
dezvoltare şi a utilizatorilor. Durata etapei este de trei până la cinci săptămâni şi furnizează,
ca rezultat, o reprezentare a cerinţelor, compusă dintr-un model al datelor, o listă a regulilor
de gestiune, machete de ecran şi înlănţuiri ale acestora pentru prelucrările esenţiale. Tot în
această etapă se stabileşte modul în care va fi testat sistemul.
Construirea asigură dezvoltarea software-ului în cicluri iterative. După ce este creat,
prototipul se testează în maniera fixată în cursul proiectării funcţionale. Urmează una sau
mai multe reuniuni ale dezvoltatorilor şi utilizatorilor, în urma cărora se evidenţiază, de
comun acord, funcţionalităţile adiţionale necesare, după care se iniţiază o nouă iteraţie de
dezvoltare. Se continuă în acest mod, până la obţinerea software-ului în forma sa finală.
Instalarea la utilizator cuprinde paşii şi activităţile uzuale acestei etape.

1.3.7 Evoluţia metodelor de proiectare

Complexitatea problemelor ridicate de realizarea sistemelor informatice a condus, încă

din anii 60, la definirea de metode de dezvoltare (numite frecvent şi metode de proiectare).
În termenii cei mai generali, o metodă preconizează un ansamblu de modele prin care
se defineşte viitorul sistem, ordonate conform unor reguli şi principii, mai mult sau mai puţin
detaliate, acompaniate de recomandări şi restricţii în elaborarea lor şi o anumită etapizare şi
eşalonare în timp a întregii activităţi, astfel încât să se ajungă cu un grad cât mare de
siguranţă şi cu costuri cât mai reduse la un sistem funcţional. Multe dintre metodele
existene, în special cele din ultimele decade, beneficiază şi de instrumente informatice
dedicate, care preiau o parte dintre sarcinile de rutină, sprijină elaborarea modelelor, asigură
gestionarea lor în condiţii de coerenţă şi, deseori, au capacitatea de generare automată a
unei părţi a programelor, în unul sau mai multe limbaje şi medii de dezvoltare diferite.
Recurgerea la metode de proiectare prezintă mai multe avantaje:
• introduc o anumită disciplină de lucru;
 • definesc produsele intermediare ale fiecărei activităţi sau subactivităţi –
artefactele procesului;
• permit amplasarea de puncte de control pentru evaluarea progresului
înregistrat şi evaluarea nivelului de risc.

În timp, s-au conturat mai multe curente de gândire care au promovat şi dezvoltat
diverse metode de proiectare.

O clasificare bazată pe cronologie include:

• metode timpurii, metode nestructurate specifice perioadei ’50 – ’60;
• metode orientate spre ieşiri (sfârşitul anilor ’60) caracterizate prin faptul că
proiectarea sistemului informatic avea ca punct de plecare ieşirile pe care
acesta trebuia să le asigure: rapoarte, grafice etc. Pe baza ieşirilor
identificate se determinau apoi datele de intrare şi prelucrările;
• metode orientate spre procese, utilizate în deceniul şapte, prezentând
drept caracteristică utilizarea diagramelor fluxurilor de date;
• metode orientate spre date, specifice anilor ’80, prezentând ca element
caracteristic utilizarea diagramelor entitate-relaţie;
• metode orientate obiect promovate în anii ’90 caracterizate prin
promovarea conceptului de obiect care încapsulează date şi metode.

O altă clasificare, bazată pe paradigma conform căreia este perceput sistemul,

evidenţiază:
• metode ierarhice (generaţia I a metodelor de proiectare);
• metode sistemice (generaţia a II-a);
• metode obiectuale, numite şi metode orientate obiect (generaţia a III-a).

Metodele ierarhice au la bază analiza funcţională a întreprinderii. Astfel, sistemul

informatic cuprinde în arhitectura sa subsisteme definite la nivel de funcţii ale întreprinderii.
Cum fiecare funcţie este subdivizată ierarhic în subfuncţii, iar acestea la rândul lor, se
descompun succesiv până la definirea unor componente elementare uşor de programat,
arhitectura SI va urma această ierarhie, fiecare componentă a sa acoperind o subdiviziune
funcţională.
Avantajele metodelor ierarhice constau în simplitate şi o bună adaptare la cerinţele
formulate de utilizator.
Dezavantajele pornesc de la concentrarea efortului de analiză şi proiectare asupra
prelucrărilor în condiţiile în care, tocmai acestea sunt cele mai expuse la modificări în timp.

Metodele sistemice se bazează pe aplicarea teoriei sistemelor în descrierea

funcţionării întreprinderii. Sistemul informatic este abordat sub două aspecte
complementare – datele şi prelucrările – analizate şi modelate independent, reunirea celor
două modele realizându-se cât mai târziu cu putinţă.
Spre deosebire de metodele ierarhice, metodele sistemice acordă prioritate datelor
faţă de prelucrări şi respectă cele trei niveluri de abstractizare introduse de raportul
ANSI/SPARC: conceptual, logic, fizic.
Avantajele metodelor sistemice decurg din promovarea tehnologiei bazelor de date.
Dezavantajele sunt datorate deficienţelor care pot apărea în modelarea prelucrărilor şi a
riscului apariţiei unor discordanţe între modelele datelor şi prelucrărilor.

Metodele obiectuale sau bazate pe obiecte au fost formulate la începutul anilor

’80. După o perioadă iniţială, în cursul căreia s-au propus mai multe metode diferite, s-a
ajuns la o selecţie a celor mai bune practici, larg acceptată, pornind de la care s-a definit un
cadru unificat de modelare denumit UML – Unified Modeling Language şi un proces unificat
corespunzător.
Caracteristic acestor metode este faptul că SIG este conceptualizat ca un ansamblu
de obiecte autonome, care se organizează şi cooperează între ele. Pentru prima dată,
datele şi prelucrările (metodele) se găsesc în cadrul aceleiaşi structuri, denumite obiect.
Fiecărui obiect îi este caracteristic un anumit comportament, definit prin ansamblul
operaţiilor pe care le poate realiza. Datele şi prelucrările sunt încapsulate în cadrul
obiectului.
Avantajele metodelor obiectuale decurg din posibilitatea reutilizării componentelor
de program, în mod direct sau prin mecanisme mai mult sau mai puţin evoluate de
moştenire şi din posibilitatea compunerii, simple şi sigure, de obiecte complexe prin
asamblarea obiectelor existente.
Dezavantajele acestor metode decurg din faptul că nu întotdeauna reprezentarea sub
formă de obiecte este naturală, adecvată sau avantajoasă.

1.3.8 Principii de bază în realizarea sistemelor informatice de

gestiune

Desfăşurarea unei activităţi riguroase şi performante de modelare şi dezvoltare de

sisteme informatice de gestiune impune respectarea următoarelor principii:
1. abordarea globală a problemei de rezolvat;
2. utilizarea unei metodologii unitare în proiectarea şi realizarea sistemului informatic;
3. aplicarea celor mai moderne abordări în modelarea şi dezvoltarea sistemului
informatic;
4. structurarea sistemului informatic ţinând seama de organigrama firmei;
5. participarea nemijlocită a viitorului beneficiar la activităţile de analiză, proiectare şi
implementare a sistemului informatic, în vederea formulării clare a cerinţelor utilizatorului,
necesare proiectării şi validarea eşalonată a soluţiilor propuse de proiectant;
6. respectarea cadrului legislativ; fiind vorba de sisteme informatice de gestiune,
devine obligatorie realizarea evidenţelor, calcularea indicatorilor şi întocmirea lucrărilor de
sinteză în conformitate cu reglementările aflate în vigoare;
7. realizarea unor sisteme informatice corespunzătoare resurselor disponibile la
utilizator;
8. întrucât, prin natura sa, aplicaţiile sunt adaptabile, schimbările trebuie anticipate şi
controlate;
9. compromisurile sunt inerente în dezvoltarea de software; ele trebuie explicitate şi
documentate.

Studiile de specialitate au încercat să evidenţieze factorii de succes în dezvoltarea

proiectelor software. Raportul Standish, spre exemplu, plasează ca primi factori de succes:
• implicarea utilizatorului final;
• sprijinul managementului executiv;
• claritatea cerinţelor;
• planificarea.
1.4 Sinteza noţiunilor studiate

Tipologia şi arhitectura sistemelor informatice de gestiune

Sistemul informaţional al organizaţiei reprezintă ansamblul de informaţii

organizate, evenimente, persoane, proceduri şi resurse alocate.
Sistemul informatic de gestiune este definit ca o soluţie informatică pentru
sarcinile, lucrările, problemele (unei porţiuni a) sistemului informaţional, concepută pentru a
funcţiona pe o anumită platformă, folosind un anume software de aplicaţie.
Tehnologia informaţiei (TI) înglobează componente hardware, software, de
comunicaţii, de reţele, de automatizarea a lucrărilor de birou, baze de date, orice alte
echipamente şi componente software necesare prelucrării informaţiei.
Criterii de clasificare a sistemelor informatice:
• aria de cuprindere;
• natura activităţilor susţinute.
Arhitectura sistemului informatic se referă la aspectele de structurare și de
organizare generală şi reprezintă soluţia generică de prelucrare a datelor.
Sistemele informatice de gestiune (SIG) presupun definirea domeniilor de
gestiune, a datelor, modelelor, regulilor de gestiune.
Soluţii arhitecturale de realizare a unui sistem informatic pot fi:
• sistem informatic centralizat;
• sistem informatic descentralizat.
În definirea arhitecturii unui SIG se poate recurge la una dintre următoarele
strategii:
• descendentă sau top-down;
• ascendentă sau bottom-up;
• mixtă.
Cele trei componente majore care formează un sistemul informatic sunt:
• intrările;
• prelucrările;
• ieşirile.

Procese de dezvoltare a sistemelor informatice de gestiune

Ciclul de viaţă al unui SIG cuprinde următoarele stadii:

• definirea necesităţii/oportunităţii;
• obţinerea;
• introducerea în exploatare;
• exploatarea curentă;
• menţinerea în funcţiune.
Activităţi de bază în dezvoltarea SIG:
• definirea cerinţelor;
• proiectarea;
• construirea;
• testarea.
Activităţi suport în dezvoltarea SIG:
• managementul proiectului;
• managementul calităţii;
• verificarea şi validarea;
• gestiunea configuraţiei;
 • documentarea.
Nivele de abstractizare în dezvoltarea SIG:
• conceptual;
• logic;
• fizic.
Datele şi prelucrările sunt studiate şi modelate separat, în paralel, pe fiecare dintre
cele trei nivele - conceptual, logic şi fizic -, cu puncte periodice de confruntare şi corelare.

Modele ale procesului de dezvoltare a SIG:

• modelul în cascadă;
• modelul în V;
• modelul incremental;
• modelul spirală;
• dezvoltarea rapidă – RAD.

Clasificarea metodelor de proiectare:

Cronologică:
• metode timpurii;
• metode orientate spre ieşiri;
• metode orientate spre procese;
• metode orientate spre date;
• metode orientate obiect.
În funcţie de paradigma conform căreia este perceput sistemul:
• metode ierarhice (generaţia I a metodelor de proiectare);
• metode sistemice (generaţia a II-a);
• metode obiectuale numite şi metode orientate obiect (generaţia a III-a).

Principii de bază în realizarea sistemelor informatice de gestiune:

• abordarea globală a problemei de rezolvat;
• utilizarea unei metodologii unitare în proiectarea şi realizarea SIG;
• aplicarea celor mai moderne abordări în modelarea şi dezvoltarea SIG;
• structurarea SIG ţinând seama de organigrama firmei;
• participarea nemijlocită a viitorului beneficiar la activităţile de analiză,
proiectare şi implementare a SIG;
• respectarea cadrului legislativ;
• realizarea unor SIG corespunzătoare resurselor disponibile la utilizator;
• anticiparea şi controlul schimbărilor;
• documentarea tuturor soluţiilor integrate în SIG.

1.5 Teste de autoevaluare

1. Precizaţi care dintre următoarele afirmaţii este falsă:

a) Sistemul informaţional al unei organizaţii include sisteme informatice de
gestiune (SIG).
b) SIG are rol de infrastructură pentru sistemul informaţional.
c) Sistemul informaţional nu comunică cu SIG.
d) Adaptarea SIG la evoluţia platformei pe care funcţionează nu trebuie să
afecteze coerenţa datelor.
e) SIG comunică între ele, transmiţându-şi reciproc date şi solicitări.
2. Precizaţi care dintre următoarele afirmaţii este adevărată:
a) Dezvoltarea unui SIG adaptat nevoilor specifice unei organizaţii nu generează
costuri suplimentare.
b) Introducerea unui SIG nu antrenează modificări în organizarea activităţii unei
organizaţii.
c) Strategie ascendentă sau bottom-up este centrată pe descompunerea de
subsisteme dezvoltate independent pe fiecare domeniu de gestiune.
d) Aplicaţiile software departamentale rulează pe serverul central al organizaţiei.
e) Reingineria modului de organizare a afacerii presupune reproiectarea
proceselor de afaceri.

3. Precizaţi care dintre elementele enumerate mai jos nu face parte din ciclul de viaţă al
sistemelor informatice de gestiune:
a) definirea necesităţii/oportunităţii;
b) corelarea facilităţilor cu funcţiunile SIG ale clienţilor şi furnizorilor;
c) obţinerea;
d) introducerea în exploatare;
e) menţinerea în funcţiune.

4. Regulile de gestiune specifice unui SIG:

a) se definesc la finalul proceselor de dezvoltare a SIG;
b) descriu desfăşurarea activităţii numai în subsistemul de gestiune a stocurilor;
c) se stabilesc doar de manageri;
d) cuprind normele, condiţiile, limitările fixate şi aplicate de conducerea
organizaţiei, respectiv a domeniului aferent SIG, pentru desfăşurarea
activităţilor curente;
e) sunt luate în considerare în momentul introducerii în exploatare a SIG.

5. Determinaţi care dintre elementele enunţate nu se regasesc printre factorii de succes

menţionaţi în raportul Standish:
a) implicarea utilizatorului final;
b) sprijinul managementului executiv;
c) claritatea cerinţelor;
d) planificarea;
e) ergonomia locului de muncă.

1.6 Bibliografie
Zaharie, D., Roşca, I. (2002), „Proiectarea obiectuală a sistemelor informatice", ed. Dual
Tech, Bucureşti

Anica-Popa, L.-E. (2005), „Conducerea intreprinderii prin costuri: recursul la modelele

contabilitatii manageriale: cazul metodei ABC-Activity Based Costing”, Editura Economica,
Bucureşti
Răspunsuri grile:
1-c
2-e
3-b
4-d
5-e