Cap 5 9 Sifc

CAPITOLUL V
Studierea sistemului existent

şi determinarea cerinţelor noului sistem
Obiective:
 Cunoaşterea caracteristicilor proiectelor de dezvoltare a sistemelor informaţionale
 Descrierea componentelor sistemului existent (ieşiri, intrări, stocarea datelor, procese de
prelucrare), pentru identificarea punctelor tari şi slabe din sistem
 Înţelegerea evenimentelor la care sistemul trebuie să reacţioneze prin funcţiile de prelucrare,
precum şi a modalităţii de identificare a lor
 Prezentarea principalelor activităţi ce se realizează în timpul determinării cerinţelor
 Cunoaşterea principalelor surse de identificare a cerinţelor sistemului,
a persoanelor afectate, direct sau indirect, de implementarea noului sistem
 Identificarea principalelor categorii de cerinţe ale noului sistem
 Dobândirea de cunoştinţe privind modul de întocmire a specificaţiei de analiză,
a criteriilor calitative pe care trebuie să le îndeplinească
Capitolul de faţă se concentrează asupra activităţilor specifice etapei de analiză, în care

este studiat sistemul existent şi se identifică cerinţele noului sistem informaţional.
În timpul cercetării şi stabilirii cerinţelor, se vor obţine detaliile privind procesele şi
activităţile desfăşurate la nivelul sistemului curent, pe măsura intervievării, observării
utilizatorilor sau analizei documentelor şi procedurilor de lucru existente. În acest mod, se
încearcă obţinerea unei imagini cât mai clare şi obiective asupra problemelor cărora trebuie să
le răspundă noul sistem.
În etapa de anaiză se realizează legătura cea mai strânsă cu utilizatorii şi se câştigă
încrederea lor, pentru că se fac o serie de recomandări şi sugestii asupra modului în care se vor
satisface cerinţele lor informaţionale. Şi asta pentru că, în timpul analizei, „se merge unde
trebuie şi se discută ce trebuie”1 cu utilizatorii care participă la desfăşurarea operaţiunilor
economice, ceea ce face mult mai facilă acceptarea schimbării sistemului. Altfel, e posibil ca
echipa de analiză să fie văzută ca un intrus, care nu înţelege problemele cu care se confruntă
cei care exploatează sistemul.
Aproape toate metodologiile de dezvoltare a sistemelor specifică şi descriu activităţi
similare pentru etapa de analiză, diferenţele rezultând, de cele mai multe ori, din tehnicile
recomandate pentru desfăşurarea lor sau din denumirea dată. Însă, toate ar trebui să conducă la
atingerea aceloraşi obiective: înţelegerea deplină a modului de funcţionare a sistemului
existent, determinarea cerinţelor informaţionale şi modelarea noului sistem. Faza de analiză
presupune definirea mult mai detaliată a ceea ce trebuie să facă sistemul informaţional, pentru
a genera beneficiile economice şi avantajele tehnologice specificate în timpul etapei de
planificare a proiectului, oferindu-se mai multe soluţii, din care cea mai bună va fi supusă
proiectării.
Activităţile specifice analizei sunt complementare şi, de obicei, se pot desfăşura simultan.
De exemplu, analistul culege informaţii despre sistemul existent, definind în acelaşi timp
cerinţele informaţionale pentru cel nou, pe tot parcursul etapei şi nu numai la începutul ei.
Principalele întrebări la care trebuie să se găsească răspunsul în timpul etapei de analiză sunt:
1. Satzinger, J.W., Jackson, R.B., Burd, S.D. – Systems Analysis and Design in a Changing World, Second Edition,
Course Technology, Thomson Learning, Boston, 2002, p. 108.
80 ANALIZA SISTEMELOR INFORMAŢIONALE
 ce se realizează în sistemul existent şi care sunt intrările, ieşirile şi procesele de

prelucrare specifice?
 care sunt punctele tari, de păstrat în noul sistem, respectiv punctele slabe, care trebuie
înlocuite sau transformate în puncte tari?
 care sunt cerinţele noului sistem?
 ce variante pot fi luate în considerare pentru dezvoltarea noului sistem, pentru a
răspunde cât mai bine cerinţelor identificate?
 ar trebui continuată proiectarea şi implementarea noului sistem?
Principalele activităţi desfăşurate în timpul etapei de analiză sunt:
1. Studierea sistemului existent, care presupune, în primul rând, identificarea punctelor tari
şi slabe ale sistemului, respectiv a acelor elemente care au generat apariţia problemelor, pe
baza unor analize orientate spre principalele componente ale sistemului informaţional.
2. Determinarea cerinţelor informaţionale ale noului sistem. Activitatea implică
identificarea persoanelor care au nevoie de informaţii, momentele şi forma în care acestea
sunt solicitate. Analiştii trebuie să lucreze îndeaproape cu utilizatorii. Cerinţele
informaţionale se referă la:
 tipul, formatul, conţinutul, volumul şi frecvenţa fiecărei intrări/ieşiri, timpul de răspuns;
 procesele de prelucrare necesare transformării intrărilor în ieşiri;
 corectitudinea, exactitatea şi securitatea intrărilor, stocării, prelucrărilor şi ieşirilor
sistemului.
Pentru aceste două prime activităţi, analiştii de sistem au la dispoziţie o serie de tehnici
sau metode, grupate în două mari categorii, respectiv:
a. metodele tradiţionale de culegere a informaţiilor
 interviuri individuale;
 anchete realizate prin chestionare;
 intervievarea grupurilor de oameni cu interese comune;
 observarea personalului în momente bine definite pentru a vedea modul în care sunt
folosite informaţiile pentru exercitarea sarcinilor de serviciu;
 studierea documentaţiei firmei pentru a se cunoaşte conţinutul rapoartelor, al politicilor,
regulamentelor, precum şi direcţiile spre care se îndreaptă prelucrarea datelor.
b. metode moderne de determinare a cerinţelor sistemului: JAD (Joint Application
Design), RAD (Rapid Application Development), prototipizarea.
3. Structurarea sau modelarea cerinţelor sistemului urmăreşte crearea unor imagini ale
sistemului, prin intermediul unor modele, după cum urmează:
 modelul descompunerii funcţionale are ca scop evidenţierea principalelor funcţii,
procese, subprocese, proceduri de prelucrare a datelor etc. din cadrul sistemului. De
fapt, modelul prezintă, sub formă de diagramă, structura ierarhică a prelucrărilor din
sistemul analizat;
 modelul proceselor, prin care se reprezintă principalele procese de prelucrare şi
legăturile existente între sistemul analizat şi celelalte sisteme sau componente
organizatorice ale firmei, respectiv cu sistemele externe, prin intermediul fluxurilor de
date. Modelul proceselor este construit prin intermediul diagramelor fluxurilor de
date, care redau, sub formă grafică, sursa fiecărui flux de date, procesele de prelucrare
la care sunt supuse, precum şi destinaţia fluxurilor de informaţii obţinute în urma
prelucrărilor. Sursa şi destinaţia pot fi alte sisteme/aplicaţii, persoane, componente
organizatorice, parteneri de afaceri, dacă sunt fluxuri externe, respectiv locuri de
stocare/păstrare a datelor (fişiere, baze de date, dosare etc.), dacă fluxurile sunt
interne sistemului;
 modelul logicii proceselor presupune descrierea acestora astfel încât să poată fi
convertite în programe, prin intermediul limbajelor de programare, dar nu se va
STUDIEREA SISTEMULUI EXISTENT ŞI DETERMINAREA CERINŢELOR 81
respecta structura sau sintaxa unui anumit limbaj (aceasta se va realiza într-o etapă
ulterioară, proiectarea);
 modelul datelor, realizat prin intermediul diagramelor entitate-relaţie, reliefează
obiectele sau lucrurile din lumea reală, sub forma entităţilor de date, despre care
trebuie păstrate date în cadrul sistemului, o lungă perioadă de timp. Entităţile de date
sunt componentele unui sistem care au cea mai lungă perioadă de viaţă şi sunt cele
mai persistente.
4. Întocmirea raportului analizei de sistem reprezintă sinteza activităţilor anterioare şi va
conţine: lista problemelor şi restricţiile existente în sistemul curent; cerinţele noului
sistem; rezultatele modelării conceptuale; recomandări privind proiectarea noului sistem.
5. Analiza recomandărilor împreună cu reprezentanţii conducerii, care trebuie informaţi
cu privire la evoluţia proiectului, urmărindu-se luarea deciziei de continuare sau nu a
acestuia, alegerea celei mai bune variante de proiectare a sistemului, precum şi aprobarea
bugetului şi planurilor calendaristice revizuite pentru finalizarea proiectului.
5.1 Tipuri de proiecte de dezvoltare a sistemelor informaţionale

Din perspectiva analizei, activităţile specifice diferitelor proiecte sunt, în mare parte,
similare, însă fiecare tip de proiect surprinde unele lucruri diferite, în sensul că mediul curent
de lucru pe care analiştii trebuie să-l studieze este altul. De aici, rezultă trei mari categorii ale
proiectelor de dezvoltare a sistemelor2:
 sisteme manuale;
 proiecte de informatizare a sistemelor manuale;
 sisteme informatizate supuse modificărilor: modificări minore ale sistemului;
îmbunătăţirea şi întreţinerea sistemului; reproiectarea şi redezvoltarea sistemelor.
Diferenţele privind analiza, în contextul categoriilor de proiecte prezentate anterior, rezidă
în: elementele supuse analizei, responsabilităţile analiştilor, rezultatele analizei, factorii care
determină dezvoltarea noului sistem. În tabelul 5.1 sunt prezentate, în sinteză, aceste
caracteristici pentru fiecare dintre proiectele menţionate.
5.2 Studierea sistemului existent

Studierea sistemului este una din cele mai importante activităţi din ciclul de viaţă al
dezvoltării, iar în primii ani ai informatizării sistemelor nu exista nici o limită în desfăşurarea
acestei activităţi. În timp, atât specialiştii, cât şi utilizatorii au ajuns la concluzia că alocarea
unei perioade de timp mai mici pentru studierea sistemului existent nu ar afecta calitatea noului
sistem, pentru că se pornea de la ideea că, de cele mai multe ori, vechiul sistem trebuia înlocuit
şi nu ar mai fi fost necesară studierea lui. Dar, în ultimii ani, s-a demonstrat că multe dintre
sistemele dezvoltate, în special cele cu forţe proprii (dar nu numai), au generat numeroase
probleme, mai ales în timpul etapei de întreţinere, datorită inexistenţei unei documentaţii
complete privind caracteristicile şi funcţiile sistemului, generând costuri semnificative pentru
refacerea activităţii de analiză şi documentare. În plus, multe dintre sisteme trebuie integrate cu
altele, ceea ce înseamnă că efortul de studiere a sistemului existent este mai mare, pentru a
asigura un grad cât mai înalt de integrare şi compatibilitate.
Ca urmare, unii specialişti au ajuns la concluzia că trebuie să se găsească un echilibru
între eforturile şi timpul necesar pentru studierea sistemului existent şi cele de determinare a
cerinţelor noului sistem, pentru că reprezintă principala cale de identificare a nevoilor
informaţionale.
2. Modell, M. – A Professional’s Guide to Systems Analysis, Second Edition, McGraw-Hill Company, New York,
1996, pp. 20-36.
82
Tabel nr. 6.1 – Caracteristicile proiectelor de dezvoltare a sistemelor din perspectiva analizei
Tipul Diferenţe privind analiza
proiectului Elementele supuse analizei Responsabilităţi Rezultatele analizei Factori declanşatori
Modificare - Prelucrările manuale - Simplificarea fluxului - Standarde/proceduri noi - Întârzieri în prelucrări
sistem manual - Fluxurile şi etapele prelucrărilor informaţional - Reguli de performanţă - Noi forme de raportare
- Rezultatele prelucrărilor - Reducerea redundanţelor - Noi formulare, proceduri de - Flux greoi al documentelor
- Reordonarea prelucrărilor control, rapoarte - O nouă formă
- Conţinutul formularelor - Noi prelucrări sau fluxuri organizaţională
Informatizare - Modalităţile de înlocuire a - Impactul componentelor - Noi formulare de introducere a - Costurile mari ale prelucrării
sistem/ prelucrărilor manuale manuale asupra celor datelor manuale
componente - Procesele şi procedurile manuale automate - Stabilirea conţinutului - Erori în prelucrarea datelor
- Interacţiunea dintre fişierelor - Creşterea duratei de obţinere
despre funcţiile îndeplinite de acesta.

componentele informatizate - Fluxul prelucrărilor, mixaj de a rapoartelor
- Fezabilitatea înlocuirii procese noi şi manuale
procedurilor manuale - Noi procese de prelucrare
- Costurile informatizării
Modificări - Mediul economic - Optimizarea prelucrărilor - Modificarea structurii -Îmbunătăţirea prelucrărilor
minore ale - Funcţiile şi procedurile de - Trecerea programelor într-un fişierelor, rapoartelor
sistemului prelucrare nou limbaj - Eliminarea eventualelor erori,
concentrează atenţia asupra altor aspecte, şi anume:

a codurilor neutilizate
Îmbunătăţire/ - Domeniile de lucru ale - Adăugări de noi funcţionalităţi - Reproiectarea logicii - Modificări în mediul
Întreţinere utilizatorilor - Identificare interdependenţe cu aplicaţiilor economic
- Legăturile cu alte sisteme alte aplicaţii ce folosesc - Modificarea structurii bazei de - Solicitări ale utilizatorilor
- Structura programelor aceeaşi bază de date date; pentru noi funcţionalităţi
ANALIZA SISTEMELOR INFORMAŢIONALE
- Solicitări de rafinare sau

“cosmetizare” a sistemului,
din partea utilizatorilor
Reproiectare/ - O nouă analiză a întregului - Analiza nevoilor utilizatorilor - Reproiectarea procedurilor; - Migrarea de la o tehnologie
Redezvoltare sistem - Identificarea şi eliminarea - Conversia bazelor de date; la alta
problemelor ce apar odată - Reintegrarea sistemului - Trecerea de la prelucrarea pe
noile tehnologii reproiectat în sistemul firmei. loturi la cea online
- Convingerea conducerii de - Restructurarea
necesitatea redezvoltării organizaţională
Deşi este o activitate distinctă în cadrul analizei, studierea sistemului existent este foarte
asemănătoare, ca tehnică de lucru, cu determinarea cerinţelor noului sistem, însă specialiştii îşi
condiţiile în care sistemul curent este înlocuit în totalitate, analiştii au nevoie de informaţii
rapoarte şi ecrane, diagrame ale fluxurilor de date, diagrame entitate-relaţie etc. Aşadar, şi în
fiind nevoiţi să apeleze atât la discuţii cu utilizatorii şi la observarea modului în care aceştia îşi
Mai mult, sunt destul de rare cazurile când specialiştii în dezvoltarea sistemelor pot crea
desfăşoară activitatea, cât şi la analiza documentaţiei sistemului existent, care poate include
imaginea noului sistem doar pe baza cunoştinţelor sau experienţelor pe care le deţin, de obicei,
 înţelegerea activităţilor, obiectivelor şi procedurilor existente în sistem şi firmă;

 cunoaşterea fluxurilor de date şi informaţii, pentru a obţine perspectiva modului în care sunt
realizate funcţiile sistemului;
 identificarea punctelor tari şi slabe ale sistemului existent, pentru a se forma primele opinii
cu privire la modul de structurare şi proiectare a noului sistem;
 evaluarea resurselor hardware, software şi de personal disponibile.
De obicei, studierea sistemului existent apare strict necesară atunci când:
 se trece de la un sistem manual la unul informatizat;
 nu există nici un fel de documentaţie a sistemului existent supus redezvoltării;
 există destul de multe incertitudini asupra modului în care funcţionează sistemul.
Studierea sistemului curent presupune culegerea unui volum considerabil de informaţii de
la persoanele care utilizează şi vor utiliza sistemul, prin analiza documentelor şi a
regulamentelor firmei, a documentaţiei sistemului (dacă există) sau prin observarea a ce fac
alte firme care s-au confruntat cu aceleaşi nevoi. Pe scurt, analiştii trebuie să discute cu toţi cei
care utilizează sisteme similare şi trebuie să citească orice este disponibil despre sistemul
existent. Ei trebuie să devină experţi în domeniul economic pentru care sistemul se dezvoltă.
De exemplu, dacă se urmăreşte implementarea unui sistem de prelucrare a comenzilor primite
de la clienţi, este necesar să se cunoască absolut toate activităţile pe care le presupun preluarea
şi onorarea comenzilor. Dacă se urmăreşte implementarea unui sistem de gestiune a creditelor
bancare, atunci trebuie să se ştie orice detaliu privind regulile de aprobare şi acordare a
creditelor, modul de rambursare, politicile de creditare şi stabilire a dobânzilor, a
comisioanelor şi penalităţilor etc.
În acelaşi timp, analiştii, pe lângă informaţiile despre domeniul economic al sistemului,
trebuie să culeagă şi informaţii tehnice care au legătură cu acesta, în sensul identificării
locurilor în care utilizatorii îşi vor desfăşura activităţile, interfeţele sistemului cu alte sisteme,
echipamentele şi softul folosite.
Principalele elemente supuse analizei în timpul studierii sistemului existent sunt:
 informaţiile de ieşire obţinute din actualul sistem şi de care au nevoie persoanele din
unitate pentru exercitarea sarcinilor ce le revin;
 datele de intrare în sistem vehiculate în unitate pentru fiecare loc de muncă (descrierea lor,
volumul, periodicitatea ş.a.);
 modul în care sunt stocate şi păstrate datele;
 procesele de prelucrare la care sunt supuse datele, ordinea prelucrărilor şi dependenţa
dintre datele trecute prin diverse procese. De asemenea, se au în vedere evenimentele
marcante şi momentele declanşării lor, prin care se schimbă valoarea datelor.
În continuare, vom prezenta pe rând aceste elemente.
5.2.1 Analiza informaţiilor de ieşire

Principalele informaţii care se obţin în cadrul unui sistem apar sub forma listelor,
situaţiilor de ieşire, documentelor, ecranelor, a răspunsurilor la întrebări, toate încadrate în
termenul generic de rapoarte.
Un raport este un document economic, în care sunt incluse date predefinite, folosit
exclusiv pentru a fi citit sau vizualizat, fără a se confunda cu terminologia contabilă a unui
document primar. Sunt multe situații când un document contabil reprezintă o ieșire a unui
sistem și nu neapărat o intrare. De exemplu, factura emisă unui client reprezintă rezultatul unui
proces de prelucrare al sistemului vânzări (citirea informațiilor despre produsele facturate,
citirea informațiilor despre clientul căruia se emite, calcularea valorii produselor, a TVA,
calcularea totalului facturii, determinarea discount-ului etc.). Ca urmare, este o ieșire din
proces și nu o intrare, așa cum s-ar crede la prima vedere, dacă ne bazăm doar pe folosirea
noțiunii de document. Pe de altă parte, factura emisă poate reprezinta un document de intrare,
dar pentru alt sistem, de exemplu sistemul de încasări și plăți, pe baza căruia se vor actualiza și
urmări încasările de la clienți.
Dintre obiectivele prezentării detaliate a ieşirilor sistemului existent pot fi enumerate:
1. Determinarea formatului şi conţinutului ieşirilor
În funcţie de aceste elemente, se va constata, din discuţiile purtate cu utilizatorii, dacă
sunt mulţumiţi de ieşirile generate de sistem sau ele trebuie modificate, fie din punct de vedere
al conţinutului, fie al formei.
De exemplu, dacă un raport privind comenzile primite de la clienţi, într-o perioadă de
timp, este generat în mai multe exemplare şi conţine informaţii pe care o parte din utilizatori nu
le folosesc, este necesară regândirea conţinutului raportului, fie prin eliminarea acelor
informaţii, fie prin proiectarea a două tipuri de rapoarte, unul detaliat şi unul sintetic.
O altă situaţie poate fi cea în care raportul se obţine pe suport de hârtie, deşi el este
utilizat o singură dată, după care este arhivat, fără a se mai apela la conţinutul lui. O soluţie ar
fi generarea lui în format electronic, fără a mai fi tipărit.
Ca urmare, analiştii trebuie să urmărească dacă toate câmpurile din conţinutul raportului
sunt utile tuturor utilizatorilor, dacă suportul de prezentare este cel mai eficient mod de a pune
la dispoziţie informaţiile solicitate sau dacă ar trebui modificat din punct de vedere al formei
(de exemplu, din raport de tip tabel în raport de tip grafic, din raport detaliat într-unul de tip
drill-down etc.)
2. Modul de structurare a ieşirilor
Se va analiza dacă fiecare ieşire are în structură următoarele componente (asupra acestui
aspect se va reveni în capitolul de proiectare a rapoartelor):
 introducerea sugestivă (partea de titlu a raportului), care trebuie să fie clară, să scoată în
evidenţă numărul raportului şi data întocmirii lui, locurile în care trebuie să fie distribuite
exemplarele;
 informaţiile privind instrucţiunile de completare, destinaţiile fiecărui exemplar, evitarea
comentariilor lungi, prin rubrici sugestive;
 partea principală a raportului, care trebuie să fie echilibrată, cu folosirea corectă a
spaţierilor şi marginilor, etichetarea corectă a rubricilor şi gruparea lor logică, marcarea
fiecărei rubrici, accentuarea zonelor cheie prin linii sau culori;
 concluziile (finalul) ieşirii, care trebuie să fie plasate la sfârşitul raportului, să aibă spaţiu
suficient pentru semnături, să prezinte regimul de lucru cu documentul respectiv, să fie
accentuate totalurile.
3. Identificarea momentului elaborării rapoartelor
Obiectivul se referă la identificarea frecvenţei cu care se obţin ieşirile, criteriu în funcţie
de care se pot obţine următoarele categorii de rapoarte, prezentate şi în capitolul 2:
 rapoarte programate (la termen);
 rapoarte neprogramate, cu rol special (rapoarte ad-hoc);
 rapoarte declanşate de excepţi;
 rapoarte la cerere.
Prin acest obiectiv se doreşte evaluarea eficienţei generării rapoartelor în funcţie de modul
de sprijinire a procesului decizional şi de control. De obicei, rapoartele generate la termen sunt
solicitate mai mult pentru respectarea obligaţiilor legale, în timp ce altele sunt răspunsuri la
cererile managerilor. În aceste condiţii, se poate determina cât de flexibil este sistemul la
nevoile de informare ale utilizatorilor interni şi externi, indiferent de tipul raportului solicitat.
Astfel, este necesar să se identifice toţi utilizatorii informaţiilor şi să fie încadrate în una din
categoriile menţionate pentru a vedea dacă sunt satisfăcute cerinţele lor, dacă sunt necesare şi
alte tipuri de rapoarte.
4. Determinarea duratei necesare pentru generarea unei ieşiri
Unul dintre elementele în funcţie de care se stabileşte dacă procedura de prelucrare este
eficientă îl constituie durata necesară obţinerii informaţiilor, influenţată de mai mulţi factori,
dintre care mai importanţi sunt:
 prelucrarea se face pe loturi, ceea ce înseamnă că unele rapoarte, privind activităţile
desfăşurate într-o perioadă mai scurtă de timp decât cea în care are loc prelucrarea, nu pot
fi obţinute decât după perioada stabilită pentru culegerea şi prelucrarea datelor generate de
un set de operaţiuni. Acest lucru poate afecta procesul decizional prin lipsa informaţiilor
actualizate. De exemplu, personalul de vânzări nu poate accepta comanda unui client în
ziua primirii ei, ci numai după o săptămână, dacă actualizarea stocului de produse se face,
pe baza facturilor emise şi a bonurilor de predare a produselor finite de la secţiile de
producţie, doar la sfârşitul săptămânii;
 prelucrările se bazează pe un sistem de gestiune a bazelor de date ce nu mai face faţă
numărului de înregistrări. Dacă se solicită răspunsul la o întrebare de genul: „Care este
stocul produsului X”, iar utilizatorul trebuie să aştepte mai mult de 5 minute pentru
obţinerea răspunsului dorit, înseamnă că interogarea bazei de date se realizează greoi,
datorită lipsei de performanţă a sistemului de gestiune a bazelor de date sau a neoptimizării
acesteia;
 procedurile existente nu se desfăşoară în regim distribuit, astfel că la solicitarea unor
informaţii aflate în mai multe locuri ale firmei este necesar să se aştepte până se
centralizează şi sintetizează datele în forma dorită de utilizatori;
 performanţa echipamentelor nu este cea mai bună pentru a sprijini obţinerea rapoartelor în
formatul şi la momentul dorit de utilizatori. De exemplu, unităţile de prelucrare nu permit
generarea unor rapoarte de tip grafic, imprimantele nu au posibilitatea tipăririi în formatul
cerut (A3, A5 etc.) sau solicită mult timp pentru imprimare (cazul imprimantelor
matriceale încă folosite de unele firme pentru tipărirea statelor de salarii sau a balanţelor
de verificare, operaţiune care poate dura şi câteva ore).
5. Identificarea circuitului informaţiilor de ieşire la nivelul organizaţiei
Obiectivul se poate realiza răspunzând la următoarele întrebări:
 cine este beneficiarul listei/situaţiei, ecranului sau răspunsului la întrebare? Se identifică
locul/locurile din firmă unde sunt necesare informaţiile. De exemplu, situaţia comenzilor
primite de la clienţi poate fi solicitată de cei de la depozite, în vederea pregătirii produselor
pentru livrare, de cei de la producţie, pentru a planifica producţia, de marketing, pentru a
analiza tendinţele pieţei, de salarizare, pentru a calcula salariile agenţilor de vânzări etc. În
această situaţie, este important să se determine dacă este eficientă obţinerea unui singur
raport, în mai multe exemplare, care să fie transmis tuturor celor interesaţi, sau e mai bine
să fie generate rapoarte cu conţinut diferit, în funcţie de nevoile fiecărui beneficiar.
 câte persoane folosesc sau văd listele/situaţiile, ecranele sau răspunsurile la întrebări? Se
determină numărul exact al exemplarelor în care trebuie obţinut raportul, pentru că un tip
de beneficiar ar putea fi format din mai multe persoane. De exemplu, marketingul e posibil
să fie reprezentat de mai mulţi analişti ce urmăresc aspecte diferite în cadrul aceluiaşi
raport: o persoană este interesată de evoluţia generală a comenzilor pentru un anumit
produs, o alta de tendinţa unui client de a se axa pe anumite produse sau anumite perioade
de cumpărare etc.
 unde sunt transmise listele/situaţiile, ecranele sau răspunsurile la întrebări? Unele
rapoarte, potrivit regulamentelor interne sau legislaţiei în vigoare, trebuie să aibă
semnătura uneia sau mai multor persoane pentru asigurarea corectitudinii şi validităţii
informaţiilor pe care le conţin. De exemplu, bilanţul contabil trebuie să poarte semnătura
directorului economic, a unui expert contabil şi a directorului firmei pentru a certifica
exactitatea datelor. Acest lucru înseamnă că, până a ajunge la destinaţie (preşedintele
consiliului de administraţie, adunarea generală a acţionarilor sau asociaţilor, direcţia
finanţelor publice), bilanţul trebuie analizat şi verificat de mai multe persoane. Astfel de
aspecte sunt importante pentru a se asigura transmiterea la timp a rapoartelor la fiecare

beneficiar.
 când este solicitată obţinerea ieşirilor de fiecare beneficiar? Chiar dacă, la un moment dat,
conţinutul şi forma unei ieşiri sunt identice, există situaţii când fiecare beneficiar solicită
rapoartele la perioade diferite de timp. Ca urmare, sistemul trebuie să fie capabil să
genereze informaţiile în funcţie de cererile existente. De exemplu, situaţia comenzilor
primite de la clienţi este necesară producţiei la sfârşitul fiecărei săptămâni, pentru
planificarea producţiei din următoarea săptămână, în timp ce marketingul cere lunar
această situaţie, pentru stabilirea acţiunilor promoţionale ale lunii următoare.
 în ce scop sunt utilizate ieşirile? Este o întrebare în funcţie de care se determină dacă
informaţiile din structura ieşirii sunt suficiente sau nu, prea detaliate sau prea sintetice. De
exemplu, situaţia comenzilor primite de la clienţi ar putea fi folosită pentru luarea deciziei
de a creşte sau diminua producţia pentru anumite produse, caz în care sunt necesare
informaţii sintetice privind cererile de produse. Dacă situaţia este folosită pentru a controla
activitatea de livrare, atunci informaţiile sunt mult mai detaliate, cuprinzând cantitatea de
produse cerută, perioada de livrare, adresa pentru livrare, clientul căruia i se face livrarea
etc.
6. Verificarea aspectelor calitative ale conţinutului ieşirilor
Se au în vedere următoarele caracteristici:
 tipul datei cel mai indicat pentru atingerea scopului propus (date numerice, alfabetice,
memo, imagini, audio, hypertext);
 corectitudinea sau precizia datelor, astfel încât în urma unor verificări încrucişate să nu
rezulte diferenţe sau, pentru datele numerice, să nu fie folosite aproximări, decât în condiţii
bine specificate;
 actualitatea datelor, în sensul obţinerii la timp; altfel s-ar putea să-şi piardă din utilitate ca
urmare a transmiterii lor cu întârziere;
 orizontul de timp la care fac referire datele (perioade ale activităţilor desfăşurate). De
exemplu, informaţii privind vânzările din ziua curentă, săptămâna sau luna anterioară,
vânzările dintr-un an;
 gradul de sintetizare, prin care se urmăreşte dacă datele sunt prea sintetice sau detaliate.
De exemplu, obţinerea de către sistemul de gestiune a clienţilor a două liste privind clienţii
– una detaliată, sub forma balanţei analitice a clienţilor necesară contabilităţii generale, iar
cea de-a doua, sub formă sintetică, destinată financiarului;
 completitudinea datelor, din punct de vedere al insuficienţei sau excesivităţii lor, aşa cum
rezultă din conţinutul actual al ieşirilor. În acest caz, apar două situaţii. Prima se referă la
faptul că, pentru luarea deciziilor, găsirea unor soluţii sau prelucrarea în alte scopuri a
informaţiilor primite, persoanele sunt nevoite să folosească mai multe liste/rapoarte cu
conţinut asemănător, ceea ce evidenţiază că ieşirile sunt caracterizate de lipsă de
informaţii. A doua situaţie apare când o persoană foloseşte doar o mică parte din conţinutul
unui raport, deci e o abundenţă de informaţii;
 accesibilitatea datelor, în sensul disponibilităţii lor în orice moment, când sunt cerute;
 siguranţa sursei datelor, prin care se urmăreşte dacă asupra datelor pot exista incertitudini
sau reflectă în mod real şi exact operaţiunile economice care le-au generat.
5.2.2 Analiza datelor de intrare
Activitatea de analiză a datelor de intrare urmăreşte toate aspectele legate de documentele
sau datele care sunt supuse prelucrării în sistemul existent (intră în sistem). Abordarea datelor
se realizează separat, în următoarele două situaţii:
1. pentru documentele (inclusiv orice tip de raport) intrate în sistem pe suport de hârtie,
când se recurge la culegerea datelor conţinute de acestea, de către un operator;
2. pentru informaţiile provenite, în format electronic, din alte sisteme/ aplicaţii, care
presupun retratarea sub aspectul compatibilităţii cu formatul datelor existente în
aplicaţiile sistemului analizat.
1. Analiza documentelor de intrare
Din punct de vedere al documentelor, analiza trebuie să reliefeze o serie de aspecte cu
privire la gradul de optimizare a circuitului lor, momentul în care documentul este emis şi cel
al prelucrării efective a datelor, precum şi cu privire la necesitatea culegerii datelor de pe
documente pentru a fi supuse prelucrărilor. Astfel, se va pune accent pe următoarele elemente:
a) locul de provenienţă a documentelor (emitentul), indicându-se atât locurile din interiorul
organizaţiei, cât şi cele externe;
b) data emiterii documentului şi data preluării datelor în sistem, pentru a se şti care este
intervalul de timp dintre momentul apariţiei datelor de intrare şi cel al prelucrării efective;
c) numărul de exemplare în care se întocmeşte fiecare document şi circuitul fiecărui
exemplar al documentului, pentru a se depista eventualele locuri în care documentul ar
putea fi supus aceloraşi tipuri de prelucrări;
d) frecvenţa de apariţie a documentelor, în funcţie de care se va determina timpul necesar
pentru prelucrarea datelor, precum şi stabilirea tipului prelucrării (pe loturi sau on-line);
e) locul de arhivare a documentelor şi momentul în care intră în acest proces, pentru a se
stabili dacă arhivarea este un proces al sistemului sau aparţine altui sistem (cu alte cuvinte,
dacă documentul rămâne sau nu în sistemul analizat);
f) datele preluate din documente pentru a fi supuse prelucrării, astfel încât să se determine
dacă sunt suficiente sau prea detaliate în raport cu nevoile de informare;
g) criteriile de clasificare şi grupare a documentelor, mai ales în condiţiile în care
prelucrarea datelor se face pe loturi, pentru a şti care este ordinea de prelucrare şi care este
criteriul după care se face prelucrarea. Astfel, pot exista situaţii când prelucrarea se face
după data emiterii documentelor, după emitent sau operaţia economică pe care o reflectă.
De exemplu, facturile primite de la furnizori pot fi grupate după data primirii lor, după
furnizor sau după conţinutul facturilor (facturi pentru materii prime şi materiale, facturi
pentru prestări servicii, facturi pentru achiziţia de mijloace fixe);
h) codificările utilizate pentru înregistrarea datelor în documente, urmărind să existe
concordanţă între codurile utilizate în documente şi cele existente în sistem, pentru a uşura
procesul de prelucrare. De exemplu, existenţa corespondenţei între codificarea
personalului folosită de sistemul de personal-salarizare şi codificarea folosită de secţiile de
producţie, în cadrul fişelor normelor de muncă pentru fiecare salariat;
i) verificările sau controlul la care sunt supuse documentele, din punct de vedere al
legalităţii, completitudinii şi corectitudinii lor, vizează:
 semnarea documentelor de către persoanele responsabile;
 identificarea eventualelor neconcordanţe între valorile înregistrate şi cele stabilite prin
lege;
 completarea tuturor câmpurilor sau explicarea situaţiilor în care nu se solicită această
operaţiune;
 verificarea câmpurilor calculate, pentru a se elimina orice sursă de eroare;
j) durata medie a timpului de aşteptare al unui document pentru a fi supus prelucrării,
precum şi durata medie a prelucrării;
k) dependenţele existente între documente pentru a fi supuse proceselor de prelucrare. Cu
alte cuvinte, de stabilit dacă un document poate fi supus prelucrării numai atunci când un
alt document este deja introdus în sistem. De exemplu, factura primită de la furnizor nu
poate fi prelucrată până nu au fost preluate datele de pe notele de intrare-recepţie.
2. Analiza intrărilor din alte sisteme, în format electronic
Referitor la intrările care provin din aplicaţiile altor sisteme, este necesar să se
urmărească:
a) identificarea datelor care intră din aplicaţiile altor sisteme, pentru a determina formatul
de intrare, de exemplu sub forma unor fişiere temporare;
b) compatibilitatea structurii datelor, în sensul stabilirii tipului atributelor, a mărimii acestora
şi a formatului, astfel încât datele transmise să nu fie supuse unor retratări, ci direct
procesului de prelucrare;
c) momentele în care sistemul analizat solicită date de la aplicaţiile altor sisteme şi cele în
care sunt oferite efectiv, pentru a se identifica potenţialele întârzieri datorate unor
deficienţe ale aplicaţiilor din alte sisteme sau din sistemul analizat. În situaţia prelucrărilor
automate, trebuie urmărite tipurile de prelucrări (pe loturi sau on-line), platformele pe care
rulează aplicaţiile, pentru a fi rezolvată problema compatibilităţii procedurilor de
prelucrare;
d) identificarea datelor care trebuie supuse unor procese de pregătire (regrupări, reordonări
sau sortări, în funcţie de necesităţile sistemului care este supus analizei) şi a celor ce pot fi
prelucrate direct.
Analiza intrărilor trebuie să se facă în strânsă legătură cu analiza ieşirilor, pentru că

generarea acestora din urmă depinde de tipul, caracterul şi corectitudinea intrărilor în sistem.
De aceea, de cele mai multe ori, se apelează la o serie de matrice intrări/ieşiri, pe baza cărora
se determină dacă pentru obţinerea ieşirilor sunt suficiente datele culese şi prelucrate de
sistem. Un exemplu de astfel de matrice este redat în figura 5.1.
Date intrare Comanda client Lista preturi
Numar Data Cod Nume Adresa Denumire Unitate Cantitate Data Cod Denumire Pret
Date iesiri comanda comanda client client client produs masura comandata livrare produs produs vanzare
Data raport
Perioada de
raportare
Numar

comanda
Data

comanda
Data livrare
Cod client 
Nume client 
Adresa

client
Limita
creditare
Cod produs 
Denumire
 
produs
Unitate

masura
Cantitate

comandata
Valoare
 
produs
Valoare
comanda
Fig. 5.1 Matricea intrărilor/ieşirilor sistemului de gestiune a comenzilor

Se poate observa, din matrice, că unele câmpuri din sistemul de gestiune a comenzilor nu
au corespondent în datele existente pe documentele preluate, cum sunt Data raport, Perioada
de raportare, Limita creditare, Valoare comanda. Dar acest lucru nu înseamnă, obligatoriu, că
trebuie introduse noi date, ci faptul că pot fi preluate din alte surse sau generate automat de
sistem. De exemplu, Data raportului să fie data curentă a sistemului, Perioada de raportare se
introduce în funcţie de solicitările existente, Valoare comanda se calculează ca sumă a valorii
produselor comandate. Sunt şi situaţii când anumite date par a fi redundante, cum este cazul
Cod client şi Nume client, respectiv Cod produs şi Denumire produs, dar ele sunt folosite ca
elemente de control pentru eliminarea erorilor de introducere a datelor.
De asemenea, printr-o astfel de matrice se pot identifica şi eventualele date nepreluate
încă în sistem, dar necesare pentru generarea ieşirilor, aşa cum este cazul Limita creditare, care
este o dată ce nu se regăseşte în sistem, ceea ce înseamnă că la determinarea cerinţelor ar trebui
inclusă, fie pe baza eventualelor contracte/convenţii care se încheie cu clienţii, fie a unor reguli
economice interne.
Astfel de matrice şi verificări se pot realiza automat cu ajutorul instrumentelor CASE.
5.2.3 Analiza modului în care sunt stocate, accesate şi păstrate datele

Prin această activitate se urmăreşte:
1. modul de organizare a datelor (fişiere, baze de date), astfel încât să se identifice dacă este
necesară conversia datelor din formatul fişier în cel specific bazelor de date sau dintr-un
format al bazelor de date în altul;
2. descrierea atributelor, cu specificarea lungimii, formatului şi tipului fiecărui atribut din
fişierele şi bazele de date ale sistemului, relaţiile de dependenţă şi de calcul dintre ele;
3. codificarea utilizată pentru entităţile de date din fişiere şi baze de date, pentru a observa
dacă este necesară o recodificare a datelor înscrise în documente sau a celor existente în
înregistrările din fişiere sau baze de date;
4. criteriile de stocare şi păstrare a datelor, în vederea stabilirii modului de indexare,
sortare şi înregistrare a datelor, precum şi stabilirea tipului de fişiere sau tabele ale unei
baze de date (permanente sau temporare, tabele index, istorice ş.a.);
5. identificarea datelor necesare prelucrărilor care nu se regăsesc în fişierele sau bazele de
date ale sistemului. Această situaţie poate fi determinată de faptul că unele date sunt
rezultatul altor prelucrări (de exemplu, calculul valorii unei comenzi), când nu este
necesară memorarea lor, sau date care nu au fost preluate în sistem, dar ale căror valori
trebuie incluse în prelucrări, ceea ce impune modificarea structurii fişierelor sau bazelor
de date, aşa cum este cazul Limita creditare din matricea anterioară;
6. gradul de normalizare a datelor, pentru a se stabili eventualele probleme ce pot să apară
la prelucrarea datelor (adăugare, modificare, ştergere);
7. frecvenţa operaţiunilor de introducere, restaurare, ştergere, modificare a datelor, pentru
determinarea timpului necesar prelucrării, a performanţelor pe care trebuie să le aibă
echipamentele de calcul;
8. dimensiunea fişierelor sau a bazelor de date, din punct de vedere al numărului de
înregistrări şi al spaţiului de memorie ocupat, pentru evaluarea eficienţei prelucrărilor şi a
caracteristicilor tehnice ale echipamentelor;
9. timpul necesar pentru obţinerea unor răspunsuri prin interogarea fişierelor sau a bazelor
de date;
10. suportul de stocare şi păstrare a datelor (suporţi magnetici, optici, hârtie etc.), descriind
tipul şi numărul dispozitivelor de stocare aflate la dispoziţia utilizatorilor şi specificarea a
ceea ce se memorează pe fiecare suport;
11. identificarea frecvenţei cu care utilizatorii realizează copii de siguranţă pentru fişierele
cu care lucrează, precum şi suportul pe care se păstrează acestea;
12. pentru staţiile de lucru conectate la un LAN (Local Area Network) sau WAN (Wide Area
Network) trebuie să se identifice următoarele elemente:
 care sunt aplicaţiile şi fişierele accesibile prin intermediul reţelei;
 pe ce server sunt stocate fişierele şi bazele de date ale sistemului;
 dacă există fişiere stocate pe mai multe calculatoare, trebuie identificate acele fişiere şi
locaţiile lor;
 ce transferuri de fişiere au loc între calculatoarele utilizatorilor, precum şi între acestea
şi servere;
 ce utilizatori au acces la e-mail şi cât de des folosesc e-mailul (dacă sistemul apelează
la e-mail pentru preluarea sau transmiterea datelor);
 dacă există posibilitatea accesării Internetului, trebuie specificat cine are acces, pentru
ce îl accesează, ce servicii ale Internetului sunt folosite;
13. protecţia şi securitatea datelor, prin prezentarea drepturilor de acces ale utilizatorilor la
fişiere şi baze de date (cine, ce drepturi are), procedurile de asigurare a integrităţii datelor,
de realizare a copiilor de siguranţă.
5.2.4 Analiza proceselor de prelucrare a datelor

Un proces reprezintă o secvenţă de proceduri intercondiţionate sau acţiuni ce stau la baza
finalizării unei prelucrări. Aceste proceduri sunt, adesea, interdependente, având un flux de
date sau structuri de control bine definite de la o procedură la alta sau de la o acţiune la alta.
O procedură reprezintă un set de acţiuni organizate pentru a atinge un scop anume, cum ar
fi: culegerea datelor de pe un document, adăugarea unei înregistrări într-o tabelă a unei baze de
date, interogarea unui baze de date pentru obţinerea unei liste, calculul unei valori, verificarea
dreptului de acces la o informaţie etc.
O funcţie de prelucrare reprezintă un grup de procese şi proceduri prin care se constituie
o componentă funcţională a sistemului. Pentru fiecare funcţie identificată se specifică
procesele şi procedurile ce trebuie realizate, de una sau mai multe persoane, din unul sau mai
multe domenii funcţionale ale firmei.
Procesele de prelucrare pot fi grupate în mai multe categorii, în funcţie de scopul pe care
îl urmăresc, cum ar fi:
 preluarea datelor de pe documentele sursă, provenite de la componentele
organizaţionale, parteneri externi sau alte sisteme;
 preluarea datelor din alte procese de prelucrare ale sistemului, fie direct, fie prin
intermediul unor locuri de stocare (fişiere sau baze de date), printr-o procedură
specifică de citire a datelor;
 efectuarea de calcule, prin citirea sau preluarea unor date din sistem sau a celor
introduse de pe documentele sursă şi aplicarea relaţiilor de calcul specifice;
 adăugarea, ştergerea şi modificarea înregistrărilor din bazele de date;
 verificarea şi validarea datelor prelucrate;
 detectarea şi corectarea erorilor;
 pregătirea ieşirilor care urmează a fi supuse unor prelucrări ulterioare;
 generarea ieşirilor solicitate de componentele organizaţionale, parteneri sau alte
sisteme ş.a.
Din punct de vedere al rezultatului obţinut, procesele de prelucrare pot fi de tipul
tranzacţiilor sau transformărilor, cu următoarele particularităţi:
1. tranzacţiile constau în evaluarea datelor de intrare, în funcţie de care se vor declanşa
prelucrările. De obicei, rezultatul acestei categorii de prelucrări constă în actualizări ale
bazelor de date, în sensul că fiecare intrare va declanşa o tranzacţie de adăugare de noi
înregistrări, o tranzacţie de modificare a valorilor unor înregistrări sau o tranzacţie de
ştergere a înregistrărilor. De exemplu, un sistem informaţional bancar prelucrează
operaţiuni bancare de genul: depuneri în cont, retrageri din cont, calculul şi înregistrarea
dobânzilor etc. Toate au ca rezultat adăugări de înregistrări (crearea unui nou cont),
modificări ale valorii înregistrărilor (creşterea soldului unui cont, printr-o nouă depunere),
ştergeri ale înregistrărilor (lichidarea unui cont). Sistemul informaţional de gestiune a
stocurilor prelucrează datele privind recepţiile de materii prime şi materiale, consumul de
materii prime şi materiale, darea în folosinţă a obiectelor de inventar, scoaterea din uz a
obiectelor de inventar, transferuri de bunuri de la o gestiune la alta, vânzarea de produse
etc., care au ca rezultat actualizări ale bazei de date.
2. transformările presupun obţinerea informaţiilor din datele existente, fără a avea ca rezultat
modificări la nivelul înregistrărilor din baza de date. Sistemul de calcul al drepturilor
salariale reprezintă un exemplu tipic pentru acest tip de prelucrări: pe baza numărului de
ore lucrate (intrarea în sistem) se calculează drepturile salariale, prin efectuarea diferitelor
calcule privind tariful orar, sporurile şi reţinerile prevăzute, în final obţinându-se statul de
plată şi centralizatorul statelor de salarii. Un alt exemplu îl reprezintă sistemul de
contabilitate generală, a cărui funcţie principală o constituie înregistrarea cronologică şi
sistematică a mişcărilor de valori ce au loc în firmă. Notele contabile, preluate de la
sistemele de evidenţă analitică, sunt transcrise, mai întâi, în registrul jurnal, apoi ele sunt
prelucrate şi sistematizate în cartea mare, pe baza căreia se va întocmi balanţa de
verificare, prin aplicarea regulilor de transformare cunoscute. În final, se va obţine bilanţul,
ce reprezintă principala ieşire a sistemului de contabilitate generală.
La nivelul unui sistem se regăsesc ambele categorii de procese (tranzacţii şi transformări),
numai că unele sunt orientate cu preponderenţă spre tranzacţii, iar altele spre transformări, aşa
cum se va vedea şi în capitolul care tratează proiectarea programelor.
În cazul sistemelor automatizate, identificarea proceselor de prelucrare se realizează,
relativ uşor, prin citirea documentaţiei aplicaţiilor (dacă există) sau prin analiza aplicaţiei.
Astfel, pentru studierea modului de descompunere a sistemului, se urmăresc opţiunile
meniurilor şi submeniurilor din care sunt constituite aplicaţiile. Fiecare opţiune va fi analizată
din perspectiva acţiunilor pe care le realizează, pe baza citirii codului sursă sau a
documentaţiei utilizatorului. De multe ori, opţiunile unui meniu sunt grupate în două moduri:
1. în funcţie de operaţiile economice care au generat datele ce urmează a fi supuse prelucrării,
caz în care submeniurile reflectă operaţiile respective şi vor conţine proceduri pentru
introducerea datelor, proceduri de actualizare a bazelor de date, de verificare şi validare, de
pregătire şi generare a ieşirilor;
2. în funcţie de tipul prelucrărilor care se execută, când submeniurile sunt organizate plecând
de la principalele prelucrări care se vor executa (introducere date, actualizare baze de date,
generare rapoarte), în cadrul lor regăsindu-se operaţiile economice care urmează a fi
prelucrate.
În cazul sistemelor manuale, procesele de prelucrare trebuie identificate plecând de la
persoanele implicate, în sensul analizei acţiunilor pe care le realizează asupra documentelor,
ţinând cont de etapele ciclului prelucrărilor datelor, descris într-un capitolul anterior. Astfel, se
va urmări modul în care are loc transcrierea unor câmpuri de pe anumite documente în alte
documente, sub forma centralizatoarelor, însumarea câmpurilor ce solicită o astfel de
operaţiune, aplicarea unor formule de calcul pentru obţinerea şi completarea unor câmpuri de
pe documentul pe care îl folosesc ş.a.m.d.
De exemplu, în cazul prelucrării manuale a comenzilor primite de la clienţi, se pot
desfăşura următoarele procese:
 preluare, prin telefon sau poştă, a comenzilor de către o persoană de la vânzări;
 scrierea datelor pe un formular specific de comandă sau completarea celui primit cu
alte date necesare prelucrărilor ulterioare, cum ar fi codul clientului, codul produselor,
preţul de vânzare;
 căutarea şi citirea informaţiilor (de pe documente centralizatoare sau de altă natură)
privind stocul de produse existent (din fişa de magazie) şi limita de creditare acordată
clientului (din fişa de cont analitic);
 generarea notei de confirmare a comenzii;
 gruparea comenzilor în funcţie de codul clientului, data comenzii, codul produselor
etc.;
 centralizarea datelor privind produsele solicitate şi transmiterea lor la producţie şi/sau
depozite;
 arhivarea comenzilor în funcţie de codul clientului sau de dată;
 preluarea informaţiilor privind facturile emise pentru fiecare comandă;

 compararea facturilor cu comenzile primite (cantităţi livrate, ce a mai rămas de livrat);
 întocmirea rapoartelor necesare analizei comenzilor primite şi onorate şi a altor
categorii de ieşiri.
Despre identificarea proceselor de prelucrare ale unui sistem vom discuta detaliat în
paragraful următor.
Având în vedere comentariile anterioare, în activitatea de analiză a proceselor de
prelucrare trebuie să se evidenţieze următoarele aspecte:
1. descompunerea funcţională a sistemului în funcţii, procese, subprocese, proceduri
ş.a.m.d., pentru a se şti dimensiunea sistemului analizat, principalele prelucrări ale
acestuia. De asemenea, se vor specifica toate locurile din firmă unde sunt executate;
2. logica proceselor de prelucrare, în vederea determinării structurii lor, a paşilor necesari
pentru prelucrarea datelor şi a momentului declanşării prelucrării;
3. ieşirile obţinute în urma fiecărui proces de prelucrare. Orice raport generat de sistem
trebuie să fie documentat, iar un model al fiecărei pagini din raport se va ataşa la
documentaţia sistemului. De asemenea, trebuie incluse controalele şi auditările care stau
la baza realizării raportului;
4. formulele sau relaţiile de calcul utilizate pentru obţinerea unor valori necesare în cadrul
rapoartelor sau diferitelor situaţii;
5. specificarea tipului de prelucrare care se realizează: adăugări, modificări, ştergeri de
înregistrări la nivelul bazelor de date sau al fişierelor, obţinerea rapoartelor, verificarea şi
validarea datelor etc.;
6. evenimentele care declanşează procesul/procedura. Pentru fiecare eveniment se va
descrie documentul sursă, timpul, frecvenţa de apariţie, volumul, toate condiţiile de
excepţie şi orice alt aspect relevant pentru procesul de prelucrare. De asemenea, se va
descrie, în detaliu, prelucrarea declanşată, dacă se realizează imediat ce a apărut
evenimentul, este amânată sau condiţionată de alţi factori declanşatori. În acelaşi timp, se
va specifica dacă prelucrarea este dependentă de un proces anterior sau de existenţa unor
date deja prelucrate;
7. datele utilizate pentru prelucrare. Este necesar să se identifice orice sursă suplimentară a
aceloraşi date, ca şi regulile de validare şi verificare a lor;
8. modul în care fiecare proces intră în legătură cu alte procese ale aceleiaşi funcţii sau ale
altor funcţii, urmărind să se determine dacă legătura se realizează prin intermediul unei
baze de date sau direct prin trecerea datelor dintr-un proces în altul;
9. identificarea oricărei proceduri manuale folosită pentru prelucrarea datelor, care va fi
descrisă şi, dacă este posibil, inclusă într-o procedură informatizată;
10. stabilirea salvărilor de date intermediare între diferitele proceduri de prelucrare. Vor fi
preznetate metodele de salvare, precum şi datele supuse acestui proces;
11. procedurile de verificare şi control trebuie să fie clar identificate şi documentate;
12. descrierea procedurilor de detectare şi corectare a erorilor, precum şi acţiunile
întreprinse la detectarea erorilor.
*
* *
Pe un plan mai general, în urma acestor activităţi de studiere a sistemului existent, se va
realiza o documentaţie privind:
 modul în care au loc activităţile de culegere, prelucrare, stocare şi transmitere a
informaţiilor;
 modul de utilizare a echipamentelor, softului (dacă este cazul), a resurselor umane;
 dimensiunile şi natura schimbării, determinate prin analiza punctelor tari şi slabe ale
sistemului.
Exemple de puncte slabe: inoportunitatea sau inexactitatea informaţiilor obţinute de

sistem, organizarea ineficientă a datelor, costuri mari de stocare a datelor, slaba pregătire a
personalului în utilizarea tehnicii de calcul, slaba organizare a fluxurilor informaţionale.
Pe baza elementelor identificate şi descrise prin studierea sistemului existent, urmează
modelarea lui, cu ajutorul diagramelor fluxurilor de date, diagramelor entitate-relaţie,
diagramele stărilor de tranziţie etc., pentru a crea imaginea grafică a sistemului. Activitatea de
modelare este obligatorie în situaţia în care nu există nici o documentaţie, altfel se folosesc
specificaţiile existente. Modelarea va fi prezentată în capitolele viitoare.
5.3 Identificarea proceselor de prelucrare ale sistemului

Aşa cum am văzut, un rol important în analiza sistemului îl are studiul proceselor de
prelucrare, plecând de la activitățile economice ce au loc într-o anumită perioadă de timp şi
într-un anumit loc, ce ar trebui memorate de sistem. Evenimentele sunt cele care determină sau
declanşează procesele de prelucrare pe care le execută un sistem, ceea ce înseamnă că este
necesară inventarierea şi analiza lor, atenţia fiind concentrată asupra următoarelor aspecte3:
 mediul în care a avut loc evenimentul, extern sau intern firmei;
 modul de reflectare a evenimentelor prin scopul şi funcţiile sistemului;
 interfeţele cu utilizatorii şi cu alte sisteme, utilizatorii fiind cei mai în măsură să
descrie nevoile informaţionale din punct de vedere al evenimentelor la care trebuie să
răspundă sistemul.
O astfel de analiză permite descompunerea sistemului în componente, pentru a fi studiate
separat, mai uşor de înţeles şi gestionat, fiind una dintre căile cele mai sigure de atingere a
obiectivelor de către noul sistem.
La firma analizată de noi, câteva dintre evenimentele identificate pentru sistemul de
gestiune a clienţilor sunt prezentate în Caseta 5.1.
Caseta 5.1 – Exemple de evenimente ale sistemului de gestiune a clienţilor la firma ABC
Principalele evenimente de la care se poate pleca pentru identificarea proceselor de prelucrare
din cadrul sistemului de gestiune a clienţilor:
 solicitarea de cataloage de către clienţii potenţiali şi cei existenţi;
 transmiterea de către clienţi a comenzilor;
 livrarea comenzilor de către firmă;
 returnarea produselor de către clienţi;
 încasarea contravalorii produselor vândute.
Principalele date care ar trebui memorate de sistem, generate de evenimentele enumerate, sunt
cele privind clienţii, cataloagele transmise, produsele comandate şi livrate, dar şi cele care nu au putut
fi onorate, debitarea şi creditarea contului clienţilor.
Procesele de prelucrare pe care trebuie să le asigure sistemul se bazează pe evenimentele
enumerate anterior, trei dintre ele fiind declanşate de clienţi (debitarea contului prin livrarea
produselor, creditarea lui prin încasarea valorii produselor vândute sau returnarea produselor,
modificări ale datelor privind clienţii prin transmiterea comenzilor sau a solicitărilor de cataloage).
Alte trei procese sunt declanşate de factorul timp (generarea de rapoarte lunare, transmiterea de
înştiinţări clienţilor, generarea de rapoarte sintetice săptămânale).
5.3.1 Tipuri de evenimente

În analiza unui sistem, pentru identificarea funcţiilor de prelucrare, pot fi avute în vedere
trei mari categorii de evenimente: externe, temporale, de stare.
3. Satzinger, J.W., Jackson, R.B., Burd, S.D. – Systems Analysis and Design in a Changing World, Second Edition,
Course Technology, Thomson Learning, Boston, 2002, pp. 153-157.
Un eveniment extern reflectă o operaţiune ce are loc în afara sistemului, fiind iniţiat de un
agent, actor sau entitate externă (o persoană, un departament din interiorul firmei sau altă
firmă), care furnizează date sistemului sau primeşte informaţii de la el. Aici nu trebuie să se
facă confuzia între entităţile externe sistemului şi cele externe firmei, pentru că atenţia se
orientează spre ceea ce poate să declanşeze prelucrarea datelor în cadrul sistemului.
De exemplu, entitate externă sistemului de gestiune a aprovizionărilor este furnizorul, care
livrează materiile prime şi materiale, pentru că declanşează prelucrarea datelor privind facturile
primite. Însă, şi comisia de recepţie este entitate externă sistemului de aprovizionare, pentru că
oferă informaţii privind eventualele diferenţe ce apar între datele înscrise în facturile
furnizorilor şi cele identificate la verificarea faptică a cantităţilor primite, reflectate într-un
document specific (nota de intrare-recepţie) ce va fi prelucrat de sistem.
Un alt exemplu de entitate externă îl reprezintă clientul, care poate transmite o comandă,
prin care solicită unul sau mai multe produse. Un astfel de eveniment este esenţial pentru un
sistem de gestiune a clienţilor, dar lui îi sunt asociate şi alte evenimente, în sensul că un client
poate să returneze un produs, să plătească factura pentru comanda onorată ş.a.
Ca urmare, pentru analiza sistemului se vor identifica acele entităţi externe care ar putea
solicita informaţii de la sistem sau care pun date la dispoziţia lui.
Evenimentele externe stau la baza stabilirii principalelor funcţii de prelucrare ale
sistemului. La descrierea lor este indicat să fie folosite denumiri cât mai sugestive, astfel încât
entitatea externă să fie mai uşor de identificat, precum şi acţiunile realizate de aceasta şi care
pot afecta sistemul. De exemplu, operaţiunea Transmiterea comenzii de către client descrie
entitatea externă (Clientul) şi acţiunea pe care o realizează (Transmiterea comenzii), ce va
determina preluarea şi prelucrarea comenzilor, reprezentând una din funcţiile de bază ale
sistemului de gestiune a clienţilor.
Evenimentele externe pot fi declanşate şi de nevoile informaţionale ale unor persoane sau
componente organizaţionale din interiorul firmei, cum ar fi solicitarea unor informaţii privind
încasarea facturilor emise clienţilor, pentru actualizarea conturilor. Majoritatea evenimentelor
externe pot fi încadrate în una din următoarele categorii generale:
 entităţile externe transmit date, ca rezultat al unei operaţii economice;
 entităţile externe solicită anumite informaţii pentru derularea unor operaţii economice,
fără a se cunoaşte momentul solicitării;
 datele memorate, în urma unor evenimente anterioare, trebuie actualizate.
Evenimentele temporale sunt cele care au loc ca rezultat al atingerii unui moment dintr-o
perioadă de timp bine determinată. Multe sisteme generează informaţiile de ieşire la intervale
bine definite, cum ar fi statele de plată emise de sistemul de salarizare, chenzinal sau lunar,
lista achiziţiilor pe luna x, generată de sistemul de aprovizionare ş.a.m.d. Uneori, ieşirile sunt
rapoarte pe care conducerea doreşte să le primească periodic, cum ar fi rapoartele privind
eficienţa unei activităţi sau rapoarte cu titlu de excepţie.
Evenimentele temporale sunt diferite de cele externe, prin faptul că sistemul poate să
genereze automat informaţiile solicitate fără să i se specifice ce are de făcut. Cu alte cuvinte,
nici un agent extern sau entitate externă nu declanşează funcţiile de prelucrare ale sistemului,
ci factorul timp, entităţile externe urmând doar să primească informaţia. Identificarea acestui
tip de eveniment se poate face plecând de la găsirea răspunsurilor la o serie de întrebări de
genul: Ce informaţii trebuie obţinute la anumite perioade de timp? Ce prelucrări ar putea fi
solicitate în acele momente?
De exemplu, în cazul sistemului de salarizare, procesul prin care se obţin statele de salarii
ar putea fi denumit astfel: Generarea chenzinală/lunară a statelor de plată, ceea ce evidenţiază
informaţiile pe care ar trebui să le prelucreze sistemul şi perioada de timp la care ar trebui să
realizeze funcţia respectivă.
Aceste tipuri de evenimente nu este obligatoriu să fie declanşate la date calendaristice
fixe, ci pot fi declanşate şi la îndeplinirea anumitor condiţii, dependente de perioade
calendaristice. O situaţie de acest fel se întâlneşte atunci când un client nu-şi plăteşte factura la
data prevăzută, iar sistemul poate genera o înştiinţare privind întârzierea plăţii, după 15 zile de
la expirarea termenului de plată.
A treia categorie de evenimente este cea de stare. Ele apar când se întâmplă ceva în sistem
sau este îndeplinită o condiţie ce declanşează o prelucrare. De exemplu, dacă vânzarea unui
produs are ca rezultat scăderea stocului sub un anumit nivel, atunci este necesar să se emită o
comandă de reaprovizionare, iar evenimentul ar putea fi denumit Emitere comandă de
reaprovizionare. Adesea, evenimentele de stare sunt similare celor temporale, cu excepţia
faptului că nu sunt cunoscute momentele de timp când trebuie declanşate procedurile de
prelucrare şi depind de evenimentele externe, fiind executate şi ca rezultat al altor prelucrări.
Trebuie remarcat faptul că evenimentele temporale şi de stare presupun, în principal,
transpunerea datelor memorate în sistem într-o formă solicitată de diferiţii utilizatorii ai
informaţiei, spre deosebire de cele externe care implică adăugări, modificări sau ştergeri de
date.
5.3.2 Identificarea evenimentelor

Definirea evenimentelor care afectează un sistem nu este un demers uşor, dar sunt câteva
recomandări generale ce ar putea ajuta la identificarea şi analiza lor, dintre care mai importante
sunt:
 analiza condiţiilor şi răspunsurilor sistemului la anumiţi factori ce ar putea declanşa
procesele de prelucrare;
 urmărirea secvenţei de derulare a operaţiilor economice;
 dependenţa de tehnologie şi posibilităţile de realizare a prelucrărilor;
 analiza fiecărui eveniment independent de altele.
În unele cazuri, este dificil de făcut diferenţa dintre un eveniment şi o serie de acţiuni sau
condiţii care pot conduce la declanşarea lui. Se va lua exemplul unui client care cumpără
dintr-un magazin un produs. Din perspectiva clientului, această cumpărare presupune o lungă
secvenţă de acțiuni. Un prim eveniment ar putea fi acela că el avea nevoie de un bun, motiv
pentru care va merge la un magazin, va studia oferta de produse. Pentru că nici unul nu
corespunde cerinţelor sale va intra în alt magazin până va găsi produsul dorit. În final, clientul
va cumpăra acel obiect de care are nevoie. Dar analistul trebuie să gândească o astfel de
secvenţă din momentul în care evenimentul afectează sistemul. În exemplul dat, sistemul va
reacţiona numai atunci când clientul a intrat în magazin, a ales produsul şi spune „vreau să
cumpăr acest produs”. Tot ceea ce a fost descris până la achiziţia lui reprezintă doar o secvenţă
de condiţii ce ar putea declanşa un eveniment şi nu evenimentul ca atare.
În alte situaţii, nu este uşor să se distingă între un eveniment extern şi răspunsul
sistemului. De exemplu, după ce clientul s-a hotărât să cumpere produsul, i se solicită să îl
achite, iar clientul va putea opta pentru plata cu card sau în numerar. Este această acţiune un alt
eveniment? În acest caz, nu, pentru că face parte din interacţiunea care are loc pentru
finalizarea operaţiunii de finalizare a procesului de cumpărare a produsului.
Modalitatea prin care s-ar putea determina dacă o acţiune este un eveniment sau o
succesiune în cadrul acelui eveniment constă în găsirea răspunsului la întrebarea: Poate fi
finalizat procesul de prelucrare fără să fie întrerupt? sau Sistemul este pregătit pentru
următoarea operaţiune sau aşteaptă prelucrarea în continuare a datelor generate de evenimentul
curent? Din momentul în care clientul doreşte să cumpere produsul, procesul continuă până
când achiziţia este finalizată, sistemul putând să intre în perioada de aşteptare a următoarei
operaţiuni, deci a unui nou client care să cumpere un produs şi să plătească pentru el.
Pe de altă parte, pot să apară situaţii când acţiunile, prezentate ca făcând parte din acelaşi
eveniment, să fie tratate distinct, cum este cazul achiziţiilor pe bază de credit comercial. Se
pune întrebarea: Când clientul plăteşte mai târziu, la sfârşitul lunii, se poate considera că
acţiunea face parte din evenimentul de cumpărare a produsului? În acest caz, nu, pentru că
sistemul prelucrează operaţiunea de cumpărare, după care, până la sfârşitul lunii, când va avea
loc încasarea, prelucrează alte date. Nu se poate opri sistemul din prelucrarea datelor, generate
de alte tipuri de evenimente, până când are loc încasarea. În acest caz, avem două evenimente
externe: Cumpărarea, care declanşează procesul de prelucrare Emitere factură, respectiv
Efectuarea plăţii de către client, prin care se declanşează procesul Încasarea facturii, şi un
eveniment temporal care conduce la Generarea situaţiei lunare a contului clientului.
Pentru identificarea evenimentelor este util să se analizeze secvenţa lor, plecând de la
entitatea externă care le declanşează sau este afectată de către acestea. În cazul sistemului de
gestiune a clienţilor de la firma ABC, analistul ar trebui să se gândească la toate evenimentele
posibile care ar putea să aibă loc în legătură cu un client. În primul rând, clientul poate solicita
un catalog de produse sau anumite informaţii despre disponibilitatea unui produs, determinând
adăugarea unei noi înregistrări în baza de date cu numele şi adresa clientului, dacă el este un
client nou. Apoi, clientul ar putea să transmită o comandă, să modifice comanda (de exemplu,
să solicite o altă mărime a produselor sau un nou articol), după care doreşte să urmărească
starea comenzii şi momentul livrării. Este posibil ca acel client să-şi schimbe adresa, ceea ce
înseamnă înregistrarea noii adrese la care urmează a fi livrate produsele sau cataloagele firmei.
În final, clientul ar putea să returneze anumite produse care i-au fost livrate. O astfel de
abordare a secvenţei de derulare a evenimentelor poate ajuta la identificarea celor ce trebuie
luate în considerare la prelucrarea datelor.
În caseta 5.2 sunt prezentate cele mai importante evenimente în firma ABC şi pe care
sistemul de gestiune a clienţilor trebuie să le surprindă.
Caseta nr. 5.2 – Evenimentele specifice sistemului de gestiune a clienţilor la firma ABC
Sistemul de gestiune a clienţilor implică o mare varietate de evenimente, multe dintre ele similare
deja celor prezentate. Ca evenimente externe au fost identificate:
 verificarea de către client a disponiblităţii unui produs;
 transmiterea unei comenzi de către client;
 modificarea sau anularea de către client a unei comenzi;
 solicitarea de către client sau conducere a informaţiilor necesare verificării stării unei comenzi;
 livrarea/onorarea comenzii;
 returnarea produselor de către client (defecte, shimbarea părerii despre produs, returnare totală
sau parţială);
 solicitarea cataloagelor de produse de către potenţialii clienţi;
 solicitarea din partea departamentului de marketing de a transmite materiale promoţionale
clienţilor;
 schimbarea politicii de creditare a clienţilor (creşterea limitei de creditare, acordarea de
discounturi, reducerea penalităţilor etc.);
 obţinerea unor noi produse, modificarea caracteristicilor produselor existente sau a preţurilor;
 lansarea de acţiuni promoţionale pentru anumite produse sau anumiţi clienţi.
Se poate observa că multe dintre evenimente au ca entitate externă declanşatoare clientul, în timp
ce altele implică apariţia chiar a departamentelor sau conducerii firmei. Analistul trebuie să dezvolte o
listă a evenimentelor externe, urmărind toate persoanele sau componentele organizaţionale care pot
declanşa o anumită operaţiune de prelucrare sau care solicită anumite răspunsuri din partea sistemului.
Sistemul de gestiune a clienţilor include câteva procese temporale, declanşate de factorul timp,
respectiv:
 generarea rapoartelor privind comenzile primite;
 generarea rapoartelor privind activitățile desfăşurate într-o perioadă de timp;
 generarea rapoartelor privind comenzile onorate;
 obţinerea de rapoarte privind potenţialii clienţi;
 obţinerea de rapoarte privind modificările efectuate asupra contului clienţilor;
 generarea rapoartelor privind producerea şi distribuirea de cataloage.
Multe dintre aceste rapoarte sunt periodice, fiind destinate diferitelor compartimente, ceea ce
înseamnă că analistul trebuie să studieze toate rapoartele şi situaţiile pe care sistemul trebuie să le
genereze la anumite perioade de timp.
Pe măsura dezvoltării listei evenimentelor, analistul trebuie să observe şi noteze orice informaţie
suplimentară care poate prezenta interes, prin construirea unui tabel al evenimentelor, în care pe linii
sunt reprezentate evenimentele, iar pe coloane detaliile fiecăruia. Un exemplu de astfel de tabel pentru
evenimentul Solicitare informaţii disponibilitate produs este redat în figura C5.1.
Ce agent/actor extern
generată de sistem?
primeşte ieşirea
Destinaţia:
cazul) ar trebui să fie
generată de sistem?
Ce ieşire (dacă este
Destina?ia
Destinaţia
Client
Răspunsul:
Detalii privind
R?spunsul
sistemului
Răspunsul
sistemului
produsul
stoc
sursa pentru introducerea
existenţeiînînstoc
produs
agentul extern reprezintă
sistemului
Căutareprodus
sistemului
verificarea
Ac?iunea
Acţiunea
?işiverificarea
Pentru un eveniment
extern, actorul sau
existen?ei
datelor în sistem.
Cautare
când un eveniment
Ce face sistemul
Sursa:
Sursa
Acţiunea:
Client
areloc?
Declanşator
Declan?ator
declanşatorul constă în datele
evenimentele temporale, este
pentru un
Cum ştie sistemul că a avut
Cererea
introduse în sistem. Pentru
produs
momentul ce declanşează
loc un eveniment? Pentru
evenimentele externe,
prelucrarea în sistem.
disponibilitate produs
produs
informa?ii
Declanşatorul:
Solicitareinformaţii
Eveniment
disponibilitate
Solicitare
Ce determină
Evenimentul:
efectueze o
sistemul să
acţiune?
Fig. C5.1 Exemplu de tabel pentru descrierea unui eveniment

(prelucrare după Satzinger, J.W., Jackson, R.B., Burd, S.D. – Systems Analysis
and Design in a Changing World, Second Edition, Course Technology,
Thomson Learning, Boston, 2002, p. 161)
Câteva comentarii asupra termenilor utilizaţi.

Un semnal transmis sistemului atunci când un eveniment a avut loc poartă denumirea de
declanşator. Pentru un eveniment extern, declanşatorul îl reprezintă primirea datelor pe care
sistemul trebuie să le prelucreze. De exemplu, când un client transmite o comandă, detaliile din
noua comandă sunt intrări în sistem. De asemenea, este important să se identifice sursa datelor
(entitatea externă declanşatoare), care, în exemplul dat, este clientul. Însă, declanşatorul poate
să-l constituie şi un alt proces de prelucrare, care transmite o serie de date pentru a fi supuse
altor prelucrări. De exemplu, în urma introducerii datelor de pe comenzile primite de la clienţi,
se transmite un flux de date în procesul de verificare a situaţiei contului clienţilor, pentru a
vedea dacă noile comenzi se mai încadrează în limita de creditare acordată.
Pentru un eveniment temporal, declanşatorul este dat de momentul dintr-o perioadă de
timp bine delimitată când sistemul trebuie să obţină sau să prelucreze ceva. De exemplu, la
sfârşitul fiecărei zile, sistemul trebuie să genereze rapoartele privind operaţiile economice
desfăşurate în acea zi cu clienţii firmei.
În legătură cu întrebarea „Ce trebuie să facă sistemul când un eveniment are loc sau care
este reacţia sistemului la eveniment?”, se va identifica acţiunea pe care trebuie să o execute.
Acţiunea reprezintă prelucrările pe care sistemul le desfăşoară când a avut loc un eveniment şi
se concretizează într-o ieşire sau rezultat bine delimitat. De exemplu, când un client transmite o
comandă, sistemul execută procesul de prelucrare Înregistrare comandă nouă, prin care sunt
preluate detaliile din comanda primită şi se adaugă o nouă înregistrare în tabela de comenzi.
Atunci când trebuie să se genereze un raport privind activitățile/operațiile, sistemul execută o
procedură numită Generare raport activități/operații zilnice.
În final, trebuie să se identifice rezultatul/răspunsul obţinut de sistem în urma acţiunilor
desfăşurate, acesta fiind o ieşire a sistemului. Când sistemul generează rapoartele privind
activitățile/operațiile zilnice, înseamnă că se obţin ieşirile sistemului, dar printr-o acţiune se
pot genera mai multe rapoarte. De exemplu, când sistemul creează o înregistrare nouă în
fişierul de comenzi, sistemul poate transmite clientului o confirmare a comenzii, iar detaliile
privind comanda sunt trimise depozitelor pentru pregătirea livrării. Destinaţia este locul unde
răspunsul sistemului (ieşirea) este transmis, reprezentată de un agent sau actor extern. Tot ca
destinaţie sunt considerate şi locurile de stocare în care sunt înregistrate datele rezultate în
urma prelucrărilor.
Uneori, o acţiune a unui sistem este posibil să nu genereze imediat un răspuns. De
exemplu, dacă un client doreşte să-şi actualizeze informaţiile privind adresa, ele vor fi
modificate în baza de date, dar nu este necesar ca sistemul să dea un răspuns clientului la
această acţiune. Înregistrarea informaţiilor în baza de date reprezintă însă o parte a acţiunii
sistemului la evenimentul de transmitere de către client a noilor date, ce vor fi folosite la
apariţia altor evenimente.
Se poate spune că tabelul evenimentelor este un mijloc eficient de a culege o parte din
infomaţiile necesare stabilirii cerinţelor informaţionale ale sistemului.
În cazul sistemului de gestiune a clienţilor de la ABC, tabelul evenimentelor este redat în
caseta 5.3:
Caseta 5.3 – Tabelul evenimentelor pentru sistemul de gestiune a clienţilor la firma ABC
Eveniment Declanşator Sursa Acţiunea Rezultat Destinaţie

Solicitare Cererea Client Căutare existenţă Detalii privind Client
informaţii pentru un produs în stoc produsul solicitat
disponibilitate produs
produs
Transmitere de Comandă Client Crearea unei Date client Birou (credit
către client a comenzi noi comercial)
unei comenzi Confirmare comandă Client
Detalii comandă
Date operație Depozit
Bancă
Modificare sau Cerere Client Actualizare Confirmare modificare Client
anulare modificare/ comandă Detalii privind Depozit
comandă anulare modificările Bancă
comandă Date operație
Solicitare Sfârşit de Proceduri Generare rapoarte Rapoarte privind Conducere
rapoarte săptămână, automate privind comenzile comenzile

privind lună, primite
comenzile trimestru, an
primite
Solicitare Sfârşitul zilei Proceduri Generare rapoarte Rapoarte privind Contabilitate
rapoarte automate activități/operații activitățile zilei
operații
Verificare Solicitare Client sau Urmărirea Detalii privind starea Client sau
stare comandă informaţii Conducere traseului comenzii comenzii Conducere
privind starea
comenzilor
Onorare/ Notificare de Depozit Înregistrarea Date produse livrate Tabela comenzi
livrare onorare a onorării comenzii
comandă comenzii
Returnarea de Notificare de Client Crearea unei Confirmare returnare Client
către client a returnare comenzi pentru Date operații
produselor returnare Bancă
Solicitare Sfârşit de Proceduri Generare rapoarte Rapoarte privind Conducere
rapoarte săptămână, automate privind comenzile comenzile onorate
privind lună, onorate
comenzile trimestru, an
onorate
Solicitare de Cererea Client Preluarea Catalog Client potenţial
către clienţi a pentru catalog potenţial informaţiilor
cataloagelor de privind catalogul
produse
Solicitare Detalii Marketing Distribuire Pachet promoţional Clienţi şi potenţiali
transmitere privind informaţii promoţii clienţi
materiale acţiunile
promoţionale promoţionale
Schimbare Ajustarea Conducere Modificarea Notificare de ajustare Client
politică de contului contului clientului Date operație
creditare a clientului Bancă
clienţilor
Modificare Detalii Birou Actualizare date Date cataloage Tabela cataloage
preţuri, privind cataloage cataloage modificate
caracteristici modificările
produse, tipuri la nivelul
produse cataloagelor
5.4 Determinarea cerinţelor pentru noul sistem

O cerinţă a sistemului informaţional sau cerinţă informaţională reprezintă o funcţie sau o
caracteristică a noului sistem, un comportament cuantificabil şi verificabil pe care sistemul
trebuie să-l aibă, precum şi restricţiile sub influenţa cărora va fi exploatat, toate pentru a
răspunde obiectivelor unei organizaţii şi pentru a rezolva un set de probleme.
Cerinţa mai este definită şi din următoarea perspectivă4:
 condiţia sau abilitatea necesară unui utilizator pentru a rezolva o problemă sau pentru a
atinge un obiectiv;
 condiţia sau capacitatea pe care trebuie să o deţină un sistem sau o componentă a
sistemului pentru a satisface un contract, un standard, o specificaţie sau alt document;
 reprezentarea documentată a unei condiţii sau capacităţi/abilităţi, aşa cum a fost
definită la punctele 1 şi 2.
4. Christel, M., Kang, K.C. – Issues in Requirements Elicitation, Technical Report, CMU/SEI-92-TR-012, ESC-TR-
-92-012, 1992, p. 2.
Cerinţele nu constau doar din funcţii ale unui sistem sau ale unei componente, ci trebuie
urmărite mai multe caracteristici ale acestora, astfel încât să fie exploatat pentru a răspunde
eficient unei probleme sau unui domeniu de activitate.
Am văzut că pe parcursul etapei de planificare a sistemului se identifică scopul sistemului,
adică principalele funcţii şi caracteristici pe care trebuie să le deţină, detaliate în timpul
analizei.
Dintr-o perspectivă generală, la nivelul unui proiect de dezvoltare se identifică două
categorii majore de cerinţe ale unui sistem: funcţionale şi nefuncţionale sau tehnice. Însă, se
întâlnesc şi alte tipuri, văzute din perspectiva utilizatorilor sau a managementului de proiect,
aşa cum se va vedea într-un paragraf următor.
Activitatea de determinare a cerinţelor este considerată una din cele mai complexe din
faza de analiză, datorită dificultăţii de evaluare a necesarului de informaţii. În unele situaţii,
utilizatorii pot fi subiectivi când sunt chestionaţi pe o astfel de temă, iar în alte situaţii nu îşi
dau seama care sunt informaţiile de care au nevoie sau le identifică în mod eronat.
La această problemă se adaugă şi diversitatea surselor de informare: de la utilizatorii
sistemului curent, prin observarea a ceea ce fac aceştia, până la studierea documentelor
primare, a rapoartelor, a procedurilor folosite.
Cauzele care determină apariţia problemelor în procesul de culegere a cerinţelor sunt
grupate astfel:
 cauze legate de scop – graniţele sistemului sunt greşit stabilite sau utilizatorii/beneficiarii
sistemului specifică detalii tehnice inutile, care mai mult derutează decât să clarifice
obiectivele sistemului;
 cauze privind dificultatea înţelegerii dorinţelor utilizatorilor, de unde necesitatea bunei
cunoaşteri de către echipa de analiză a domeniului sistemului, pentru că utilizatorii:
– nu sunt foarte siguri asupra elementelor de care au nevoie;
– nu cunosc îndeajuns de bine performanţele şi limitele mediului lor de lucru;
– nu înţeleg în totalitate domeniul problemei;
– au probleme în comunicarea nevoilor;
– omit informaţii pe care le consideră „implicite”, „normale”;
– cerinţele specificate pot intra în conflict cu nevoile altor utilizatori;
– percep greu limbajul echipei de analiză, mai ales dacă se foloseşte un limbaj pur tehnic;
– formulează cerinţe ambigue sau netestabile.
 cauze legate de volatilitatea informaţiilor. Cerinţele, de multe ori, se modifică în timp.
Descrierile anterioare au evidenţiat faptul că multe dintre greutăţile care apar se datorează
comunicării dificile între utilizatori şi echipa de dezvoltare a sistemului. Neînţelegerile dintre
ei pot duce la grave probleme în dezvoltarea sistemului, fie prin eforturi umane şi financiare
ineficiente, fie prin nerezolvarea cerinţelor reale ale sistemului propus pentru dezvoltare.
Prin determinarea şi analiza cerinţelor se urmăreşte gruparea şi organizarea lor în seturi
interdependente, identificarea relaţiilor dintre o cerinţă cu altele şi asigurarea corespondenţei
dintre ele, depistarea eventualelor omisiuni sau ambiguităţi, precum şi ierarhizarea cerinţelor în
funcţie de nevoile utilizatorilor.
Din momentul în care începe analiza cerinţelor, este necesară examinarea următoarelor
aspecte:
 dacă au fost specificate toate cerinţele la un nivel corespunzător de abstractizare sau se
indică un nivel de detaliere tehnică necorespunzătoare acestei etape;
 cerinţele sunt cu adevărat necesare sau reprezintă caracteristici sau elemente
suplimentare ce nu sunt esenţiale atingerii scopului sistemului;
 fiecare cerinţă este bine delimitată şi nu este ambiguu formulată;
 cerinţele au identificate sursele (în general, o anumită persoană);
 o cerinţă să nu intre în conflict cu altele;
 să fie posibilă satisfacerea cerinţelor prin aplicaţia informatică care urmează să fie
dezvoltată;
 fiecare cerinţă să poată fi testată în momentul în care urmează să fie implementat
sistemul.
Fără a avea pretenția de a fi o listă exhaustivă, poate asigura o anumită certitudine asupra
cerințelor ce se vor regăsi la viitorul sistem.
5.4.1 Surse de identificare a cerinţelor

Principala sursă de informaţii privind cerinţele funcţionale ale sistemului o reprezintă
diferitele persoane interesate de implementarea cu succes a sistemului (stakeholder-ii), grupate
în patru mari categorii5:
1. utilizatorii, cei care vor folosi sistemul;
2. beneficiarii, cei care plătesc sau sunt proprietarii sistemului;
3. personalul tehnic care trebuie să asigure exploatarea şi întreţinerea sistemului;
4. organisme externe firmei, cum ar fi clienţii, furnizorii, băncile, interesate în obţinerea
diverselor informaţii care să vină în sprijinul dezvoltării relaţiilor de parteneriat.
În determinarea cerinţelor, un pas important constă în identificarea stakeholder-ilor,
încercându-se, pe cât posibil, o cât mai bună reprezentare a lor în echipa proiectului. Rolul
fiecărei categorii în timpul analizei va fi descris în continuare.
5.4.1.1 Utilizatorii sistemului
Rolul utilizatorilor trebuie identificat plecând de la analiza fluxurilor informaţionale care
apar în legătură cu sistemul, atât pe orizontală, cât şi pe verticală.
În cazul dimensiunii orizontale, dacă luăm exemplul unui nou sistem de gestiune a
stocurilor, care ar putea să afecteze comisia de recepţie, depozitul, vânzările şi producţia,
trebuie ca persoanele din aceste departamente să poată să-şi descrie propriile cerinţe. Comisia
de recepţie informează despre concordanţa scriptică şi faptică a produselor achiziţionate de
firmă, iar rezultatele oferite vor sta la baza actualizării stocului. Depozitul este cel care preia şi
distribuie produsele existente în stoc, primind informaţii de la comisia de recepţie,
departamentul de vânzări şi producţie. La nivelul departamentului de vânzări este necesar să se
determine când şi cine actualizează stocul în momentul vânzării unui produs, dar după livrare
şi emiterea facturii. Producţia s-ar putea să aibă nevoie de informaţii din sistemul de stocuri
pentru planificarea capacităţilor de producţie şi stabilirea planului de producţie.
Cerinţele identificate din analiza circuitului informaţional pe orizontală asigură includerea
diferitelor departamente, prin reprezentanţii lor, în echipa de analiză.
Dimensiunea verticală a fluxurilor permite înţelegerea nevoilor informaţionale ale
personalului de conducere de pe nivelul operaţional, tactic sau strategic al firmei.
Fiecare categorie de utilizatori îşi are propriile caracteristici, de care trebuie să se ţină
cont în timpul analizei şi proiectării, şi anume:
1. utilizatorii operaţionali sunt cei care folosesc sistemul pentru desfăşurarea activităţilor
zilnice, despre care trebuie să ofere informaţii şi să specifice modul în care sistemul ar
trebui să vină în sprijinul lor;
2. utilizatorii informaţionali sunt cei care solicită sistemului informaţii, care pot fi atât
utilizatorii operaţionali, cât şi alte persoane. Această categorie, de cele mai multe ori, nu
are dreptul de a introduce date, ci numai vizualizarea lor, oferind detalii privind tipurile
de informaţii care trebuie să fie disponibile şi formatul corespunzător;
3. utilizatorii decidenţi sunt cei responsabili cu analiza a ceea ce firma a realizat din punct
de vedere al performanţelor înregistrate în comparaţie cu planificările şi procedurile
5. Satzinger, J.W., Jackson, R.B., Burd, S.D. – op. cit., p. 113.

stabilite. Ca urmare, ei solicită informaţii statistice şi de sinteză din diferite sisteme.

Conducerea poate ajuta în etapa de analiză, răspunzând la următoarele întrebări:
– ce tipuri de rapoarte ar trebui să genereze sistemul?
– ce categorie de indicatori ar fi necesară pentru reflectarea performanţei activităţilor?
– care este volumul de informaţii pe care sistemul ar trebui să-l înregistreze?
– care este numărul de activități/operații într-o perioadă de timp?
– controalele incluse în sistem corespund regulilor de prevenire şi detectare a erorilor şi
fraudelor?
– care este frecvenţa cererilor de informaţii?
4. utilizatorii externi. Din ce în ce mai mult, se conturează tendinţa ca organizaţiile externe
să aibă acces direct la informaţiile din firmă. De exemplu, funizorii pot accesa sistemul
pentru a verifica nivelul stocurilor şi pentru a iniţia o operație de livrare a bunurilor
necesare firmei. Utilizatorii externi sunt cei mai dificil de identificat şi analizat, pentru că
au caracteristici şi particularităţi din cele mai diverse şi ale căror cerinţe se pot modifica
de la o perioadă la alta. Totuşi, prin dezvoltarea noilor modele de afaceri (electronice,
mobile), utilizatorii externi au devenit un grup important pentru determinarea cerinţelor.
5.4.1.2 Beneficiarii sistemului
Chiar dacă ţinta principală a echipei de dezvoltare a sistemului o constituie satisfacerea
nevoilor informaţionale ale utilizatorilor, trebuie să le aibă în vedere şi pe cele ale
beneficiarului, respectiv acea persoană sau acel grup de persoane care oferă fondurile necesare
derulării proiectului sau este proprietarul sistemului. În multe cazuri, beneficiarul este acelaşi
cu grupul utilizatorilor de la nivelul conducerii strategice, până la cel operaţional. Totuşi, el
poate fi reprezentat şi de un grup distinct, cum ar fi un consiliu de administraţie, o componentă
organizatorică etc. Echipa de proiect include beneficiarul în lista celor mai importante
persoane interesate de sistem, pentru că trebuie să-i ofere periodic analize privind evoluţia şi
rezultatele proiectului. Beneficiarul sau reprezentantul acestuia din comitetul de iniţiativă sau
coordonare a proiectului aprobă trecerea la următoarea etapă de dezvoltare şi asigură
finanţarea, în continuare, a proiectului, atunci când el este şi finanţator (total sau parţial).
5.4.1.3 Personalul tehnic
Deşi personalul tehnic nu este încadrat în categoria utilizatorilor, el poate afecta cerinţele
sistemului. În această categorie sunt incluşi cei care stabilesc şi asigură întreţinerea şi
extinderea infrastructurii informatice a firmei. De obicei, oferă recomandări în privinţa
platformelor de lucru şi echipamentelor ce trebuie utilizate. În unele proiecte, personalul tehnic
este inclus în echipă încă din faza de analiză, în altele este solicitat doar când sunt necesare
informaţii privind componentele tehnice ale sistemului.
*
* *
Pentru a înţelege abordarea cerinţelor, din perspectiva diferitelor persoane interesate de
implementarea sistemului, vom analiza, în caseta 5.4, cazul sistemului de gestiune a clienţilor
de la firma ABC.
Caseta nr. 5.4 – Stakeholder-ii sistemului de gestiune a clienţilor de la firma ABC
La ABC, utilizatorii operaţionali ai noului sistem sunt reprezentaţi de agenţii de vânzări care
preiau telefonic comenzile şi de cei care introduc comenzile primite prin poştă. Ei au diferite
perspective asupra sistemului şi a ceea ce trebuie să facă pentru desfăşurarea activităţilor zilnice.
Agenţii de vânzări ce preiau comenzile telefonic sunt interesaţi de informaţiile despre produsele
existente în stoc pentru a confirma disponibilitatea lor şi pentru stabilirea datei de livrare. Cei care
preiau comenzile primite prin poştă discută despre posibilitatea scanării lor pentru eliminarea
introducerii acestora de la tastatură. Salariaţii de la depozite au nevoie de informaţii privind comenzile
care au fost livrate, care urmează a fi livrate, ca şi posibilitatea accesării on-line a informaţiilor privind
comenzile de livrat, emiterea facturilor pentru încărcarea produselor în loturile pentru transport.
Patronescu şi Patroneasca, în calitatea lor de top-manageri, sunt interesaţi de obţinerea rapoartelor
privind produsele comandate şi livrate, determinarea tendinţelor pentru fiecare sezon, pentru că în
domeniul lor de activitate este important să se identifice din timp tendinţa modei, pentru a se adapta
rapid sau pentru a renunţa la unele produse, dacă acestea nu mai sunt cerute de piaţă.
Dezvoltarea sistemului este finanţată în parte din fonduri interne, dar şi prin obţinerea unei linii de
credit de la bancă. ABC are deschisă o linie de creditare pe termen scurt, dar, pentru că proiectul
presupune o investiţie de durată, s-a obţinut o linie de credit pe termen lung, ceea ce înseamnă că banca
(finanţatorul) va fi interesată de succesul proiectului. În acest caz, echipa trebuie să identifice care sunt
formatele pentru situaţiile financiare pe care banca ar dori să le primească în timpul exploatării şi
întreţinerii sistemului, până la rambursarea integrală a creditului.
În final, din moment ce noul sistem implică apelarea la noi tehnologii (Internet şi sisteme
distribuite), este importantă participarea personalului tehnic.
Se poate observa că sunt destul de multe persoane care ar trebui să pună la dispoziţie informaţii
privind diferite categorii de cerinţe pe care noul sistem trebuie să le satisfacă.
Revenind la structura organizatorică a firmei ABC (din caseta 5.1, capitolul 5), poziţiile
evidenţiate prin culoarea verde indică top managerii şi managerii de mijloc ce vor fi incluşi în calitate
de stakeholder-i în dezvoltarea sistemului (Preşedinte, director distribuţie, director marketing şi vânzări,
director economic, director vânzări cu amănuntul, şef birou promovare/publicitate, şef birou cataloage,
şef birou comenzi telefonice, şef linii de producţie, şef depozite/livrare, contabil şef, director
departament informatic, şef birou dezvoltare sisteme, şef birou întreţinere sisteme).
În determinarea cerinţelor, o importanţă deosebită o are identificarea persoanelor care pot

să ofere detalii esenţiale. Cerinţele sunt incomplete dacă utilizatorii, beneficiarii, organismele
externe sau personalul tehnic nu sunt consultaţi în momentul culegerii informaţiilor. De cele
mai multe ori, managerul de proiect este cel care întocmeşte lista utilizatorilor ce trebuie
implicat în definirea cerinţelor, iar pe măsura desfăşurării activităţii, lista poate fi completată şi
cu alţi salariaţi ce deţin poziţii cheie.
Problema cea mai dificilă o constituie modul în care echipa proiectului stabileşte aceste
persoane. Procesul începe cu studierea scopului noului sistem, după care se analizează cu
atenţie persoanele care ar putea solicita informaţii de la noul sistem. Este momentul în care e
mai bine să se includă mai multe persoane, decât să se omită surse importante pentru
identificarea cerinţelor.
Totuşi, pentru determinarea cerinţelor, persoanele implicate nu reprezintă singura sursă de
identificare. Echipa proiectului poate să se asigure că a folosit toate sursele posibile plecând de
la alocarea resurselor umane din etapa de planificare a proiectului, construind un tabel cu
metodele de culegere a informaţiilor, cine şi când va realiza activitatea6. Astfel, analiza
cerinţelor va avea ca rezultat seturi de documentaţii cu informaţiile colectate.
Întreaga documentaţie din tabel poate fi folosită pentru dezvoltarea matricei
funcţii/componente a sistemului informaţional. De exemplu, dacă sistemul curpinde baze de
date, module de generare a rapoartelor, interfeţe Web, va fi construită cel puţin câte o astfel de
matrice pentru fiecare dintre ele. Unele surse informaţionale sunt mai potrivite decât altele
pentru furnizarea anumitor cerinţe.
5.4.2 Tipuri de cerinţe
În timpul analizei, cerinţele pot fi grupate în trei mari categorii, în funcţie de percepţia pe
care o au utilizatorii asupra celor prezentate de analist, şi anume7:
6. McLeod Jr., R., Jordan, L. – Systems Development. A Project Management Approach, John Wiley & Sons, Inc.,
New York, 2002, p. 320.
7. Pressman, R.S. – Software Engineering. A Practioner’s Approach. European Adaptation, Fifth Edition, McGraw
Hill, London, 2000, pp. 273-274.
 cerinţe normale (obligatorii), prezentate de analist în timpul întâlnirilor cu utilizatorii,

considerate ca fiind obişnuite pentru un sistem care se dezvoltă. Exemple de astfel de
cerinţe se referă la tipurile şi formatele de ecrane pentru culegerea datelor, prezentarea
funcţiilor de prelucrare specifice noului sistem, descrierea performanţelor pe care le poate
asigura noul sistem;
 cerinţe dorite de utilizatori, considerate implicite pentru un sistem, motiv pentru care
utilizatorii nici nu mai consideră necesară prezentarea lor atunci când sunt întrebaţi. Însă,
neonorarea acestora poate determina o puternică nemulţumire. Exemple de astfel de cerinţe
ar putea fi descrierea interfeţelor-utilizator, corectitudinea şi siguranţa prelucrărilor,
instalarea lejeră a aplicaţiilor etc.;
 cerinţe „surpriză”, care vin în întâmpinarea aşteptărilor utilizatorilor şi oferă o mare
satisfacţie atunci când sunt prezentate de către analist. Exemple: posibilitatea de a avea la
dispoziţie utilitare incluse în aplicaţia nouă, care, în mod normal, sunt specifice softului de
sistem, disponibilitatea sistemului pentru configurarea de către utilizator a propriilor
rapoarte, pe baza instrucţiunilor clar definite în cadrul aplicaţiei.
Din punct de vedere al cerinţelor urmărite în etapele următoare de dezvoltare a
sistemului, de către membrii echipei de dezvoltare, se pot identifica patru mari categorii de
cerinţe, şi anume:
1. cerinţe funcţionale;
2. cerinţe nefuncţionale sau tehnice;
3. cerinţe privind managementul proiectului;
4. cerinţe economice.
5.4.2.1 Cerinţele funcţionale
Această categorie reflectă necesităţile de modificare a unor funcţii existente sau de
dezvoltare a unora noi. Cerinţele funcţionale sunt oferite, de cele mai multe ori, de către
utilizatorii finali.
Cerinţele funcţionale sunt activităţile pe care sistemul trebuie să le desfăşoare, adică
funcţiile, procesele, procedurile de prelucrare, ca răspuns la operaţiunile economice care au
loc8. De exemplu, dacă se dezvoltă un sistem de salarizare, el ar putea include funcţii cum sunt:
calculul sumei de plată, pregătirea fluturaşilor, calculul impozitului pe venit, actualizarea
informaţiilor despre salariaţi, obţinerea fişelor fiscale etc. Cerinţele funcţionale se determină
plecând de la principalele componente ale sistemului, şi anume9:
1. intrări – prezentarea unui exemplar din fiecare intrare (document sursă, ieşirea altui
sistem), descrierea conţinutului, sursei şi a persoanei responsabile cu preluarea lor,
momentul culegerii;
2. prelucrări – descrierea tuturor proceselor de prelucrare ale noului sistem, respectiv ce va
face sistemul şi de către cine va fi folosit;
3. ieşiri – crearea unui exemplar din fiecare ieşire a sistemului, descrierea scopului,
frecvenţei, destinaţiei şi stabilirea momentului generării;
4. date elementare – definirea datelor elementare (atributele intrărilor, ieşirilor sau locurilor
de stocare) din perspectiva numelui, dimensiunii, formatului, sursei şi semnificaţiei;
5. structuri de date – reprezentarea modului în care datele elementare vor fi organizate din
punct de vedere al înregistrărilor logice;
6. documentaţie – descrierea modului de exploatare şi întreţinere a sistemului;
7. restricţii – definirea constrângerilor legale de care trebuie să se ţină cont în funcţionarea
sistemului, din perspectiva prelucrărilor, intrărilor şi ieşirilor;
8. controale – definirea procedurilor de control, prin care se vor asigura corectitudinea şi
încrederea în date, prelucrări şi informaţii.
8. Satzinger, J.W., Jackson, R.B., Burd, S.D. – op. cit., pp. 112-113.
9. Romney, M.B., Steinbart, P.J. – op. cit., p. 591.
În unele cazuri, cerinţele funcţionale sunt bine documentate (regulile şi procedurile

existente pentru desfăşurarea activităţilor economice) şi sunt mult mai uşor de identificat şi
descris. Un exemplu ar putea fi „Toţi salariaţii trebuie să completeze un formular în care să fie
înregistrate informaţiile necesare sistemului de salarizare, cum ar fi ora intrării/ieşirii în/din
unitate, cantitatea de produse obţinută, activităţile prestate etc.”.
În schimb, sunt unele situaţii când regulile economice sunt destul de ambiguu formulate
sau dificil de identificat. Un astfel de exemplu este: „Un comision suplimentar de 2% va fi
acordat tuturor salariaţilor pentru promoţiile speciale adăugate la comenzile preluate de la
clienţi”. Din această formulare se ridică o serie de întrebări: Promoţiile speciale sunt cele care
reflectă produsele complementare vândute de agenţii de vânzări? Comisionul suplimentar se
adaugă la valoarea veniturilor (include comisioanele normale) sau se calculează la salariul de
bază?
De asemenea, există posibilitatea ca unele reguli să fie stabilite de către manageri, fără
însă să existe vreun document care să ateste existenţa lor, iar includerea în setul de cerinţe
funcţionale depinde de managerii respectivi, dacă îşi aduc aminte să le menţioneze.
Descoperirea regulilor de acest gen este esenţială pentru proiectarea finală a sistemului, pentru
că e posibil ca noul sistem să nu reflecte cele mai importante cerinţe, cu efecte negative asupra
activităţilor economice desfăşurate în firmă.
Plecând de la aceste consideraţii, pot fi amintite cele mai importante cerinţe pentru noul
sistem:
 cerinţe de modificare a circuitului informaţional, în sensul eliminării sau adăugării de noi
fluxuri informaţionale, în funcţie de nevoile reale ale utilizatorilor şi de cele de prelucrare
ale sistemului, ca rezultat al apariţiei unor noi reguli sau activităţi economice;
 cerinţe de modificare a structurii datelor, în funcţie de nevoile de organizare a datelor, cum
ar fi trecerea de la un model de organizare la altul, compatibilizarea structurilor de date ale
sistemului cu ale altor sisteme, între care urmează să se stabilească anumite interfeţe;
 cerinţe privind datele elementare, prin adăugarea, eliminarea sau modificarea celor
existente, plecând de la nevoile de generare a unor noi ieşiri, de preluare şi memorare a unor
noi date de intrare;
 cerinţe de schimbare a anumitor proceduri de prelucrare, prin adăugarea sau eliminarea
unor procese, pornind de la cerinţele de informare ale utilizatorilor sau de integrare cu alte
sisteme.
Cerinţele funcţionale se regăsesc, cel mai adesea, în reprezentarea sistemului cu ajutorul
diferitelor modele construite în timpul analizei.
5.4.2.2 Cerinţele nefuncţionale
Prin cerinţele nefuncţionale, numite şi tehnice, sunt urmărite mai multe obiective
operaţionale legate de mediul hardware şi software în care urmează să funcţioneze noul sistem.
Analistul determină aceste cerinţe, într-o anumită măsură, plecând de la cele funcţionale.
Cerinţele nefuncţionale specifică proprietăţile sistemului, cum ar fi restricţiile de
implementare, performanţa, dependenţa de o anumită platformă de dezvoltare,
mentenabilitatea, extensibilitatea, interoperabilitatea şi siguranţa exploatării. Siguranţa se
referă la caracteristici cum ar fi: disponibilitatea, acurateţea, timpul dintre căderile sistemului,
defectele la 1000 de linii de cod, defectele pe clasă de prelucrări. Cerinţele de performanţă fac
trimitere la eficienţa cu care se execută procesele de prelucrare, cum ar fi viteza, timpul de
răspuns şi memoria folosită.
Dintre cele mai importante cerinţe formulate de echipa tehnică pot fi amintite:
 disponibilitatea datelor, confidenţialitatea şi integritatea lor;
 viteza şi timpul de răspuns pentru obţinerea unei informaţii;
 modul de organizare şi stocare a datelor;
calitatea informaţiilor de ieşire, din punct de vedere al momentului obţinerii lor, al

formei de prezentare şi al modului de transmitere;
 introducerea unor noi tehnologii informaţionale, cum ar fi înlocuirea sistemului de
prelucrare de tip file/server cu arhitectura client/server, trecerea la prelucrările de date
bazate pe tehnologia orientată-obiect, implementarea unei soluţii de comerț electronic
ş.a.
 platformele de lucru privind sistemele de operare, sistemele de gestiune a bazelor de
date, softul de reţea, trecerea la cloud computing etc.
De obicei, cerinţele nefuncţionale sunt prezentate în etapa de analiză sub formă narativă,
urmând a fi detaliate în timpul proiectării sistemului.
5.4.2.3 Cerinţe privind managementul proiectului
Cerinţele privind managementul proiectului sunt utile în vederea determinării nevoilor
proiectului pe toată durata lui, respectiv:
 resurse necesare pentru desfăşurarea activităţilor în condiţii normale şi pentru
finalizarea la timp a proiectului, inclusiv momentele în care ele trebuie să fie alocate
sau realocate;
 planul comunicărilor între membrii echipei de dezvoltare, între aceştia şi beneficiarii
sistemului etc.;
 gestiunea modalităţilor în care proiectul poate fi coordonat, inclusiv politicile,
procedurile şi practicile cele mai bune pentru managementul proiectului.
Cele mai multe dintre aceste cerinţe sunt furnizate de către echipa de specialişti în
dezvoltarea sistemului.
5.4.2.4 Cerinţe economice
Cerinţele economice sunt cele prin care se identifică scopul şi viziunea generală a
proiectului, inclusiv scopul, obiectivele firmei, cerinţele privind creşterea eficienţei
activităţilor acoperite prin sistemul dezvoltat, rata de recuperare a investiţiei şi veniturile pe
care le generează.
Tot în această categorie se încadrează cerinţele de reorganizare a firmei, cum ar fi
înfiinţarea de noi locuri de muncă, restructurarea altora, eliminarea unor funcţii sau posturi,
astfel încât cerinţele informaţionale ale utilizatorilor să poată fi satisfăcute. Uneori, se solicită
chiar o modificare esenţială a tipului de structură organizatorică, aşa cum se întâmplă în cazul
implementării sistemelor ERP.
Cerinţele economice sunt formulate atât de către utilizatorii finali şi conducerea firmei,
cât şi de către specialiştii în dezvoltarea sistemelor.
*
* *
Produsul final al etapei de analiză îl reprezintă specificaţia de analiză sau specificaţia
cerinţelor, o formalizare a rezultatelor obţinute prin activităţile desfăşurate. Scopul îl
constituie comunicarea rezultatelor tuturor celor interesaţi, servind şi ca reper pentru etapele
următoarele, de proiectare şi implementare. Aşadar, descrierea precisă este preferată de cele
mai multe ori, dar trebuie să se ţină cont de faptul că specificaţia trebuie să fie uşor de înţeles
şi de către utilizatorii sistemului, ceea ce înseamnă apelarea la un limbaj natural şi la o serie de
imagini, mult mai uşor de perceput. Pentru utilizatori, specificaţia are rolul de definire a
funcţionalităţii sistemului, iar pentru proiectanţi reprezintă punctul de start al etapei de
proiectare.
Utilizatorii sunt mulţumiţi dacă li se oferă un document care „vorbeşte pe limba lor”,
limbaj care este folosit în domeniul lor de activitate. Proiectanţii, pe de altă parte, solicită o
specificaţie care să apeleze la concepte utilizate în domeniul lor de specialitate. În practică, se
ajunge de multe ori la un compromis sau pot fi prezentate forme diferite ale specificaţiilor în
funcţie de cei cărora li se adresează.
Specificaţia de analiză trebuie văzută ca un raport la fel de important precum cel care
prezintă, de exemplu, performanţele înregistrate de firmă într-un an, pe baza căruia se iau
deciziile privind continuarea activităţilor eficiente şi luarea măsurilor corective pentru cele
care nu au înregistrat rezultatele scontate. În acelaşi mod, pe baza raportului de analiză se ia
decizia de continuare a proiectului de dezvoltare a sistemului, se iau măsuri de îmbunătăţire a
modului de utilizare a resurselor sau de încadrare în bugetul şi timpul alocat. De aceea, din
specificaţiile de analiză trebuie să rezulte foarte clar scopul şi obiectivele sistemului, metodele
folosite pentru studierea sistemului existent şi determinarea cerinţelor, rezultatele obţinute,
inclusiv modelele construite, variantele de proiectare şi recomandările analiştilor, concluziile.
Rezumat
În timpul cercetării şi stabilirii cerinţelor se vor obţine detaliile privind procesele şi activităţile
desfăşurate la nivelul sistemului curent, pe măsura intervievării, observării utilizatorilor sau analizei
documentelor şi procedurilor de lucru existente. În acest mod, se încearcă obţinerea unei imagini cât mai
clare şi obiective asupra problemelor cărora trebuie să le răspundă noul sistem. De asemenea, se
urmăreşte identificarea modalităţilor în care pot fi atinse obiectivele economice cu ajutorul tehnologiilor
informaţionale, pe care utilizatorii, obişnuiţi cu modul de lucru al sistemului, aproape nu le mai sesizează.
Şi asta pentru că, în timpul analizei, „se merge unde trebuie şi se discută ce trebuie” cu utilizatorii care
participă la desfăşurarea operaţiunilor economice, ceea ce face mult mai facilă acceptarea schimbării
sistemului.
Principalele elemente supuse analizei în timpul studierii sistemului existent sunt: informaţiile de
ieşire obţinute din actualul sistem; datele de intrare în sistem; modul în care sunt stocate, memorate şi
păstrate datele în sistem; procesele de prelucrare la care sunt supuse datele.
Un rol important în analiza sistemului îl are analiza proceselor de prelucrare, care se bazează pe
studierea evenimentelor ce au loc într-o anumită perioadă de timp şi într-un anumit loc, ce pot fi descrise
şi ar trebui memorate de sistem. Evenimentele sunt cele care determină sau declanşează procesele de
prelucrare pe care le execută un sistem, ceea ce înseamnă că este necesară inventarierea şi analiza lor.
Există trei mari categorii de evenimente sau activități ce trebuie avute în vedere când se analizează
un sistem: externe, temporale, de stare. În urma studierii sistemului se pot determina ce funcţii se
păstrează şi care sunt eliminate, ce intrări şi ieşiri mai sunt necesare, care sunt componentele generatoare
de probleme şi cum ar putea fi ele rezolvate.
Activitatea de determinare a cerinţelor este considerată una din cele mai complexe din faza de
analiză, datorită dificultăţii de evaluare a necesarului de informaţii. În unele situaţii, utilizatorii pot fi
subiectivi când sunt abordaţi pe o astfel de temă, iar în alte situaţii nu ştiu care sunt informaţiile de care
au nevoie sau le identifică în mod eronat.
La această problemă se adaugă şi diversitatea surselor de informare: de la utilizatorii sistemului
curent, prin observarea a ceea ce fac aceştia, până la studierea documentelor primare, a rapoartelor, a
procedurilor folosite.
Principala sursă de informaţii privind cerinţele funcţionale ale sistemului o reprezintă diferitele
persoane interesate de implementarea cu succes a sistemului (stakeholder-ii), grupate în patru mari
categorii: utilizatorii, beneficiarii, personalul tehnic, organismele externe firmei.
În timpul analizei, cerinţele pot fi grupate în trei mari categorii, în funcţie de percepţia pe care o au
utilizatorii asupra celor prezentate de analist, şi anume: cerinţe normale, cerinţe dorite de utilizatori,
cerinţe „surpriză”.
Din punct de vedere al cerinţelor urmărite în etapele următoare de dezvoltare, de către membrii
echipei proiectului, se regăsesc următoarele tipuri: cerinţe funcţionale, cerinţe nefuncţionale sau tehnice,
cerinţe privind managementul proiectului, cerinţe economice.
Produsul final al etapei de analiză îl reprezintă specificaţia de analiză sau specificaţia cerinţelor, o
formalizare a rezultatelor obţinute în această fază.
Întrebări recapitulative
1. Care sunt elementele supuse cercetării în timpul studierii sistemului existent?
2. Ce obiective se urmăresc prin analiza sistemului existent?
3. Enumeraţi aspectele/obiectivele prezentării detaliate a ieşirilor sistemului curent.
4. Prin ce se verifică utilitatea informaţiilor conţinute de ieşirile sistemului curent?
5. Ce situaţii trebuie abordate distinct în cazul analizei datelor de intrare?
6. Enumeraţi elementele ce sunt supuse analizei din punct de vedere al documentelor de intrare sau
documentelor sursă.
7. Ce se urmăreşte la analiza intrărilor provenite din aplicaţiile altor sisteme?
8. Ce se evidenţiază prin analiza modului de stocare, accesare şi păstrare a datelor?
9. Enumeraţi elementele urmărite prin studierea prelucrărilor din sistemul curent.
10. Care sunt detaliile ce trebuie evidenţiate în timpul analizei proceselor de prelucrare?
11. Definiţi evenimentele pe baza cărora se identifică funcţiile de prelucrare din sistem.
12. Descrieţi categoriile de evenimente luate în considerare la analiza sistemului.
13. Descrieţi cauzele problemelor din timpul determinării cerinţelor informaţionale.
14. Care sunt cerinţele ce pot fi identificate în timpul etapei de analiză, în funcţie de percepţia
utilizatorilor?
15. Care sunt principalele tipuri de cerinţe de identificarea cărora depinde derularea următoarelor etape
de dezvoltare a sistemului?
16. Enumeraţi principalele categorii de cerinţe funcţionale ale unui sistem.
17. Care sunt principalele categorii de persoane care stau la baza identificării cerinţelor noului sistem?
18. Care sunt principalele surse de identificare a cerinţelor?
Probleme de echipă
1. Firma Turism pentru Studenţi (TS) face rezervări pentru tabere studenţeşti la diferite agenţii de
turism. În timpul semestrului de vară, agenţiile trimit firmei informaţii despre hotelurile disponibile,
camerele şi capacitatea lor, preţul pentru petrecerea unei săptămâni din vacanţa de iarnă. Fiecare
agenţie prezintă oferte pentru un număr diferit de săptămâni în fiecare sezon, precum şi preţuri
diferite pentru camere, în funcţie de săptămâna pentru care se face rezervarea. De obicei, agenţiile
oferă o mare varietate de camere, cu capacităţi diferite, astfel încât studenţii pot să-şi rezerve
camera pe care o doresc. Familiile pot rezerva apartamente sau camere de două persoane.
În septembrie, firma Turism pentru Studenţi generează o listă a agenţiilor, săptămânile
disponibile, preţul camerelor, listă pe care o transmite secretariatelor de la facultăţi. Când un grup
de studenţi depune o cerere de rezervare pentru o anumită săptămână şi o anumită agenţie, TS
atribuie studenţilor camere cu suficiente locuri şi transmite fiecărui student o notă de confirmare. Cu
o săptămână înainte de cea pentru care au fost făcute rezervările, TS trimite fiecărei agenţii lista
studenţilor pentru care s-au făcut rezervările pe fiecare cameră. Studenţii fac plata la hotelurile unde
şi-au făcut rezervările atunci când ajung. Agenţiile trimit comisioanele direct sistemului contabil al
firmei TS, sistem separat de cel care ţine evidenţa rezervărilor.
Se cer:
a. identificarea evenimentelor la care sistemul de rezervări de la TS trebuie să asigure declanşarea
prelucrărilor;
b. crearea unui tabel complet al evenimentelor, care să conţină evenimentul, declanşatorul, sursa,
acţiunea sistemului, răspunsul, destinaţia. Atenţie la evenimente, pentru a nu le surprinde pe
cele care sunt declanşate pentru a fi prelucrate de sistemul contabil al TS sau al agenţiilor.
2. „Casa” este o societate imobiliară cu mai multe birouri. Sistemul de evidenţă a imobilelor oferă
informaţii pe care agenţii imobiliari le folosesc pentru a-i ajuta în vânzarea de locuinţe. În timpul
lunii, agenţii listează casele disponibile pentru vânzare, prin contractarea lor cu proprietarii. Agenţii
sunt arondaţi la un birou imobiliar, care transmite informaţiile colectate către sistemul centralizat al
societăţii. De aceea, orice agent dintr-o anumită zonă poate obţine informaţiile de care are nevoie.
Informaţiile incluse în liste cuprind adresa, anul construirii, suprafaţa, numărul de dormitoare,
numărul de băi, numele proprietarului, numărul de telefon, preţul cerut, starea imobilului (vândut sau
disponibil). În orice moment al lunii, un agent poate contacta serviciul centralizat pentru a obţine
listele cu imobilele ce corespund cerinţelor unui cumpărător. Astfel, sunt oferite informaţii
suplimentare sau ar putea fi contactat direct proprietarul pentru a stabili o întâlnire ca să fie văzut
imobilul. De două ori pe lună (pe 15 şi pe 30 ale lunii), serviciul centralizat generează un registru ce
conţine informaţiile despre toate imobilele înregistrate şi incluse în listele cu descrierea fiecărui
imobil, registru transmis agenţilor imobiliari. Mulţi agenţi doresc acest registru pentru că este mult
mai uşor de utilizat, având la dispoziţie informaţii despre toate imobilele şi nu numai cele care
răspund cerinţelor unui anumit cumpărător. Uneori, agenţii şi proprietarii decid modificarea
informaţiilor pe o anumită listă, cum ar fi reducerea preţului, corectarea unor informaţii privind
imobilul sau pentru a indica vânzarea imobilului. Birourile imobiliare transmit aceste modificări
către serviciul centralizat atunci când agenţii vor acest lucru.
Se cer:
a. Care sunt evenimentele cărora trebuie să le răspundă sistemul de evidenţă a imobilelor?
b. Realizarea unui tabel complet al evenimentelor.
c. Identificarea cerinţelor funcţionale şi tehnice ale sistemului.
CAPITOLUL VI
Metode de culegere a cerinţelor sistemului

Obiective:
 Iniţierea analiştilor în arta intervievării pentru a putea stabili cât mai exact ce date
sunt cerute de sistemul propus
 Cunoaşterea modalităţilor de lucru cu chestionare pentru a se stabili cerinţele sistemului
 Înţelegerea avantajelor şi dezavantajelor observării activităţilor prestate de către
angajaţi, a analizei documentelor firmei pentru a se afla care sunt cerinţele sistemului
Aşa cum s-a văzut din capitolele anterioare, obiectivul de bază al etapei de analiză constă
în înţelegerea funcţiilor economice şi determinarea cerinţelor sistemului. Problema care se
ridică, de cele mai multe ori, este dacă să se studieze şi modeleze/documenteze şi sistemul
curent sau numai cel nou. Când a fost lansată metodologia structurată, ca şi alte metodologii,
analiştii mai întâi studiau şi documentau sistemul existent, după care încercau să identifice
cerinţele pentru cel nou pe baza caracteristicilor celui vechi. Pentru acea perioadă, în vederea
determinării cerinţelor, se desfăşurau patru mari patru mari activităţi:
 identificarea proceselor şi activităţilor fizice ale sistemului existent;
 extragerea, din punct de vedere logic, a funcţiilor corespunzătoare proceselor fizice;
 stabilirea, din punct de vedere logic, a funcţiilor ce urmează a fi incluse în noul sistem;
 definirea cerinţelor fizice de prelucrare pentru noul sistem.
După unii autori, unul din marile dezavantaje ale unei astfel de abordări îl constituie
timpul mare alocat activităţii de analiză, o adevărată problemă pentru că, adesea, dezvoltarea
sistemului constă doar în automatizarea celui existent şi, ca atare, nu conta cât de ineficient era
cel vechi, pentru că oricum vechile proceduri erau înlocuite.
În prezent, într-o lume a competitivităţii, multe firme urmăresc implementarea noilor
tehnologii, în vederea creşterii avantajelor lor strategice, reproiectând în totalitate procedurile
interne pentru a beneficia de avantajele aduse de acestea. Rămâne la fel de importantă
stabilirea setului corect şi complet al cerinţelor sistemului, dar, într-o lume a vitezei, se
consideră că nu este timp şi nu sunt nici resurse suficiente pentru a revedea şi documenta toate
procedurile ineficiente ale vechiului sistem, astfel că analiştii fac apel la o abordare mai rapidă,
prin echilibrarea procesului de revizuire a funcţiilor curente şi a celui de identificare a
cerinţelor noului sistem. De aceea, atenţia în timpul etapei de analiză se concentrează pe
dezvoltarea setului de cerinţe logice ale sistemului.
Analiştii studiază sistemul curent numai atunci când trebuie să înţeleagă cerinţele
economice şi nu pentru a defini procesele specifice vechiului sistem, deoarece trebuie să
cunoască în detaliu nevoile firmei (pe principiul „walk the walk and talk the talk”), dar nu
trebuie să cadă în capcana metodelor vechi, ineficiente. Aşadar, analistul va trebui să
demonstreze o deplină stăpânire de sine.
Dezvoltarea modelului logic al noului sistem are loc pe măsură ce se culeg informaţiile
despre cerinţele sistemului, modelarea fizică a acestuia (cum va fi construit sistemul) rămânând
o sarcină a etapei următoare, proiectarea. De bază sunt informaţiile care permit construirea
modelului logic al noului sistem, existând trei întrebări majore asupra cărora ar trebui să se
orienteze desfăşurarea activităţii de studiere a sistemului şi de determinare a cerinţelor:
1. Care sunt procesele şi funcţiile economice?
Se urmăreşte obţinerea unei liste atotcuprinzătoare a proceselor economice. În majoritatea
cazurilor, utilizatorii sunt cei care oferă informaţiile, plecând de la ce se întâmplă în vechiul
sistem, astfel că analiştii trebuie să discearnă cu atenţie care sunt funcţiile fundamentale ce se
vor păstra şi ce trebuie să se elimine sau să se adauge pentru îmbunătăţirea sistemului.
METODE DE CULEGERE A CERINŢELOR SISTEMULUI 111
De exemplu, personalul de vânzări poate să indice că primul lucru pe care îl realizează

când primesc o comandă este să verifice istoricul operațiilor cu acel client, pentru a determina
dacă se încadrează în limita de creditare, dacă nu au fost probleme în decontarea produselor,
care a fost valoarea medie a cumpărăturilor, dacă este un client fidel etc. În noul sistem, e
posibil ca această funcţie să nu mai fie realizată de personalul de vânzări, pentru că poate fi
efectuată automat, cu ajutorul diferitelor proceduri de prelucrare incluse în aplicaţia sistemului.
Funcţia rămâne o cerinţă a sistemului, dar realizarea ei nu mai este o responsabilitate a
personalului de vânzări, ci a aplicaţiei care se va dezvolta.
2. Cum sunt realizate procesele economice?
Se face trecerea de la studierea sistemului existent la analiza cerinţelor pentru cel nou.
Atenţia se concentrează acum asupra modului în care sistemul ar trebui să sprijine procesele
economice, astfel că primele două întrebări sunt legate între ele pentru a descoperi cerinţele
informaţionale. Utilizatorii vorbesc, în majoritatea cazurilor, despre vechiul sistem, dar este
deosebit de important pentru analişti să meargă mai departe, astfel că trebuie să fie capabili să-i
ajute pe utilizatori să prevadă şi înţeleagă abordări noi şi eficiente ale modului în care vor fi
realizate procesele economice în noul sistem, cu ajutorul unor noi tehnologii.
3. Care sunt informaţiile necesare desfăşurării proceselor economice?
Se porneşte de la a doua întrebare, prin definirea informaţiilor specifice pe care noul
sistem trebuie să le ofere. Ultimele două întrebări formează punctul de plecare în definirea şi
descrierea cerinţelor, cuvântul magic fiind „detaliul”, în sensul că trebuie să se înţeleagă în
detaliu fiecare aspect, pentru a se identifica şi dezvolta soluţia corectă.
Valoarea unui analist, în aceste condiţii, nu este dată de cunoştinţele pe care le deţine
asupra modului de dezvoltare a unui anumit model sau despre un anumit limbaj de programare,
ci de abilitatea de a analiza şi rezolva problemele informaţionale. Cu alte cuvinte, se are în
vedere culegerea informaţiilor pentru determinarea unor cerinţe reale, complete şi corecte, cu
resurse minime şi cu alocarea unui timp cât mai redus de către utilizatori. S-au dezvoltat mai
multe metode de culegere a informaţiilor privind cerinţele sistemului, ele fiind folosite, de
multe ori, în combinaţie, pentru creşterea eficienţei şi productivităţii etapei de analiză.
Timpul necesar culegerii informaţiilor este imens, iar cheltuielile pe măsură. Sloganul
care circulă printre analişti „analysis paralysis” (analizele paralizează) are un sâmbure de
adevăr, referindu-se la excesele de zel din această fază.
Ca efect al tendinţelor de mărire a timpului de analiză a sistemelor existente, în ultimii
ani, s-a efectuat trecerea spre analiza efectuată cu ajutorul unor tehnici mai rapide. Astfel,
tehnicile moderne, JAD (Join Application Design) şi prototipizarea, preiau tot mai puţine
elemente din sistemele existente. Altele, mai radicale, renunţă aproape total la analiza
sistemului existent. Este cazul proceselor controlate prin RAD (Rapid Application
Development), care apelează la JAD, prototipizare şi alte instrumente integrate de tip CASE.
Totuşi, nu trebuie să se ajungă la concluzia că analiza, chiar şi a sistemului existent, nu mai
este necesară. Ea rămâne piesa de bază în ciclul de dezvoltare, doar că tehnicile şi
instrumentele cu care se realizează permit reducerea timpului alocat acestei etape.
Metodele tradiţionale de colectare a cerinţelor sistemului sunt:
 interviuri individuale;
 anchete realizate prin chestionare;
 intervievarea grupurilor de oameni cu interese comune;
 observarea personalului în momente bine definite pentru a vedea modul în care sunt
folosite informaţiile pentru exercitarea sarcinilor de serviciu;
 studierea documentaţiei firmei pentru a se cunoaşte conţinutul rapoartelor, al
politicilor, al regulamentelor, precum şi direcţiile spre care se îndreaptă prelucrarea
datelor.
6.1 Intervievarea
Intervievarea este de departe una din cele mai bune metode de a înţelege funcţiile şi
regulile economice, dar şi activitatea cea mai consumatoare de timp şi alte resurse. Este o cale
relativ uşoară prin care utilizatorii pot să-şi exprime intenţiile în legătură cu sistemul dorit, cu
ajutorul propriului limbaj, şi pot controla perioada de timp pe care o alocă interviului.
Interviul, potrivit definiţiei date de Charles J. Stewart şi William B. Cash Jr.1, este
procesul comunicării diadice, de stabilire a unei relaţii cu o finalitate precisă, predeterminată,
proces conceput pe alternanţa rolurilor şi care implică formulări de întrebări şi obţinerea de
răspunsuri.
Formularea de întrebări şi obţinerea răspunsurilor constituie procesele esenţiale ale
interviului. Puţine sunt interviurile care să nu necesite o structurare prealabilă a întrebărilor.
6.1.1 Tipuri şi utilizări ale interviurilor

Interviurile au o utilizare foarte variată, în domenii diverse şi cu interese diferite, ceea ce
conduce la o structurare a tipologiei acestora, după cum urmează2:
1. Oferirea de informaţii se referă la interviurile folosite pentru orientarea angajaţilor sau
membrilor organizaţiilor sau pentru formarea, instruirea sau antrenarea lor într-o anumită
activitate. Se încadrează aici:
 orientarea;
 formarea, instruirea, antrenarea;
 prezentarea de manuale;
 prezentarea concluziilor unor acţiuni.
2. Colectarea de informaţii include interviurile destinate obţinerii datelor despre fapte,
opinii, sentimente, atitudini, motivarea unor acţiuni sau tendinţe comportamentale, în
următoarele situaţii:
 studii (anchete) şi exprimarea prin vot;
 la părăsirea locului de muncă;
 cu scop de cercetare;
 investigaţii de asigurare, ale poliţiei ş.a.;
 medicale, psihologice, cazuri ş.a.;
 jurnalistică.
3. Selecţia este utilizată pentru filtrarea, recrutarea şi angajarea unor persoane sau
primirea de noi membri într-o organizaţie sau echipă.
4. Problemele referitoare la comportamentul intervievatului se referă la interviurile de
apreciere pentru evaluarea comportamentului, performanţelor sau progreselor înregistrate,
pentru izolarea unor persoane din anumite colective, disciplinarea persoanelor, precum şi
pentru consilierea în vederea rezolvării unei probleme.
5. Problemele referitoare la comportamentul celui ce ia interviul se referă la interviurile
prin care o persoană primeşte o reclamaţie de la un beneficiar, o plângere de la un angajat sau o
sugestie pentru rezolvarea unei situaţii.
6. Rezolvarea problemelor conţine interviurile care se ocupă nu de probleme personale ale
celor două părţi ale interviului, ci de una care le preocupă pe amândouă, cum ar fi căderi ale
sistemelor, pierderea clienţilor, lipsa încrederii în sistem ş.a., încadrându-se aici:
 discutarea unor probleme de interes comun;
 primirea de soluţii la problemele existente.
1. Stewart, J.C., Cash, Jr., W.B. – Interviewing, Principles and Practices, Wm.C. Brown Publishers, Dubuque,
1991, p. 3.
2. Stewart, J.C., Cash, Jr., W.B. – op. cit., pp. 5-7.
7. Persuasiunea se referă la interviurile care îşi propun să schimbe modul de gândire, de a

percepe şi/sau acţiona al celui intervievat, având ca exemple:
 vânzarea produselor sau prestarea serviciilor;
 recrutarea de noi membri;
 găsirea de fonduri şi soluţii de dezvoltare;
 schimbarea modului în care simte, gândeşte sau acţionează o parte.
De regulă, interviul urmează chestionarului, cererilor de angajare sau unor răspunsuri în
scris. Rezultatele obţinute depind de instruirea celui ce îl iniţiază, dar şi de credibilitatea
părţilor.
6.1.2 Paşii intervievării

Pentru ca un interviu să dea rezultate bune, se cuvine să fie realizat în concordanţă cu
unele orientări-cadru, cum sunt:
1. Planificarea interviului, constând în:
 Pregătirea intervievaţilor: stabilirea momentului interviului, a subiectului de discuţie ş.a.
 Pregătirea unei liste de control a agendei de lucru, precum şi a întrebărilor.
2. Ascultarea cu atenţie şi consemnarea lucrurilor importante (dacă este permisă, se poate
efectua şi înregistrarea interviului).
3. Revizuirea consemnărilor făcute în cel mult 48 de ore de la interviu.
4. Menţinerea stării de neutralitate.
5. Căutarea mai multor puncte de vedere.
De aceea, se consideră că etapele de bază ale unui interviu sunt: planificarea (pregătirea)
interviului, desfăşurarea propriu-zisă, ultima fiind finalizarea şi stabilirea activităţilor
postinterviu.
În desfăşurarea interviului este bine să se construiască o schemă a interviului (fig. 6.1),
care nu trebuie să fie respectată întocmai, dar care poate ajuta în derularea eficientă a acestuia
şi prin intermediul căreia se pot evita unele omisiuni în ceea ce priveşte obiectivele şi
întrebările stabilite iniţial.
SCHEMA DERULĂRII INTERVIULUI
INTERVIEVAT: OPERATOR INTERVIU:
Numele persoanei intervievate, funcţia/ Numele realizatorului interviului: Intervievescu şi
poziţia pe care o deţine: Vânzătorescu, Întrebărescu
director departament marketing-vânzări
LOC/MODALITATE: DATA STABILITĂ: 7 octombrie 2005
Localizare, nr. telefon: Sala de protocol, Ora de începere: 9.00
221133 Ora terminării: 9.45
Întâlnire, convorbire telefonică: întâlnire
OBIECTIVE: DE AFLAT:
Determinarea regulilor de prelucrare a Cine poate primi comisioane pentru vânzări
comisioanelor pentru vânzări Care este baza de calcul a comisioanelor, respectiv
procentele care se acordă
Cum se calculeaza comisioanele în cazul refuzului
parţial de produse
Care sunt limitele de acordare a comisioanelor
Care sunt excepţiile
AGENDA: TIMPUL APROXIMAT
Introducere (protocolul de început) 1 minut
Prezentarea cadrului general al proiectului 2 minute
Aspecte generale ale interviului
Teme de acoperit 1 minut
Permisiunea de înregistrare
Tema 1: întrebări 5 minute

Tema 2: întrebări 7 minute
…
Sinteza problemelor majore 2 minute
Întrebări ale intervievaţilor 5 minute
Închiderea operaţiunii 1 minut
OBSERVAŢII GENERALE:
Intervievatul pare extrem de ocupat – probabil că este necesar un telefon în zilele următoare pentru a
continua întrebările care au răspunsuri laconice.
Calculatorul este închis – fie că nu este un utilizator permanent al PC-ului, fie că prelucrează date cu
regim special şi nu doreşte să le expună pe ecran.
PROBLEME NEREZOLVATE, DOMENII NEACOPERITE:
Are nevoie de urmărirea vânzărilor din ultimii patru ani. A pus problema bunurilor refuzate de
clienţi, dar n-a fost timp suficient pentru lămuriri suplimentare. Mai este necesar să citească politicile
firmei privind acordarea comisioanelor.
Aspectele nerezolvate: returnările de produse şi comisioanele, respectiv comisioanele acordate pentru
promoţiile speciale.
Data şi ora următoarei întâlniri: 24 octombrie 2005, la 9.00
Fig. 6.1 Ghid de derulare a interviului
Tipurile de întrebări3 posibil de utilizat în structura unui interviu sunt redate în tabelul 6.3.
Sfaturi finale pentru operatorii interviului
 Indiferent de tipul întrebărilor, nu le formulaţi astfel încât să poată conduce la
răspunsuri convenabile sau condamnabile.
 Ascultaţi cu atenţie tot ce se afirmă în timpul interviului.
 După terminarea interviului, în cel mult 48 de ore, sintetizaţi rezultatele la care aţi
ajuns.
 În timpul interviului, nu vă pronunţaţi asupra a ceea ce va fi cu siguranţă în viitor.
Scade rolul interviului.
 Abordaţi sistemul analizat din mai multe perspective (a potenţialilor utilizatori, a
utilizatorilor unor sisteme similare, a celor afectaţi de schimbarea sistemului, a
managerilor, a controlorilor, a informaticienilor).
 Indiferent de stilul folosit la intervievare, nu uitaţi că politeţea joacă rolul cel mai
important.
 Chiar dacă aţi efectuat multe interviuri, de fiecare dată alcătuiţi un plan de derulare a
următorului interviu.
 Nu abuzaţi de drăgălăşenia (se poate citi şi politeţea) celui intervievat, prelungind cu
mult timpul planificat pentru derularea acestuia.
 Nu ezitaţi să reveniţi cu un telefon scurt, însoţit de scuzele de rigoare, pentru a lămuri
ceva ce nu vă este prea clar; nu improvizaţi răspunsuri în contul intervievaţilor.
3. Prelucrare după colectiv FIMAN, Centrul de consiliere în cariera profesională – Manual de înfiinţare şi operare,
Ed. Expert, Bucureşti, 1997, pp. 94-97.
Tabel nr. 6.3 – Tipuri de întrebări şi caracteristici ale acestora

Elemente Întrebare Întrebare Întrebare Contra- Întrebare
relevante închisă deschisă sugerată întrebare alternativă
Descoperire Un fapt O opinie Oferă idei Inversarea rolurilor Tehnică de
Serveşte strategia Întârzierea concluzionare
noastră răspunsurilor Acord asupra unei
propuneri
Răspuns Scurt Lung, dens Induce răspunsul Precizări asupra Alegere între două
Interlocutorul subiectului posibilităţi. Se
aprobă sau nu omite o a treia sau
refuzul.
Suport Întrebări care „Ce credeţi?” „Ştiaţi că…?” „Dvs. ce părere „Preferaţi… sau
încep cu „Ce, Cine, „Care este „Ce gândiţi aveţi despre?” …?”
Unde, Când…?” opinia…?” despre…?”
„De ce?” „Speraţi să…?”
Avantaje Rapiditate, precizie Multe informaţii Progresează dialogul Informaţii suplimentare Orientare spre
Climat de Se introduc argumente, înaintea răspunsului alegere, nu spre
încredere avantaje noi Dirijarea dialogului obiectul întrebării
Ocolirea obiecţiunilor Refuzul propunerii
Dezavantaje Ascunde informaţii Stimulează Răspunsul poate Poate părea o Totul se reduce la
Ştie interogatoriul vorbăreţii fi NU eschivă doar două variante
6.2 Chestionarele
Spre deosebire de interviuri, chestionarele sunt mai puţin costisitoare şi, într-un timp
relativ scurt, pot oferi un volum mare de informaţii necesare analizei sistemului. Cu ajutorul
chestionarelor, analiştii pot studia atitudinea, comportamentul şi caracteristicile persoanelor-
cheie din firmă afectate de sistemul curent sau de cel nou. Atitudinea înseamnă identificarea a
ceea ce spun utilizatorii că şi-ar dori de la sistem, comportamentul – ce fac utilizatorii, iar
caracteristicile – trasăturile utilizatorilor.
Prin utilizarea chestionarelor se urmăreşte obţinerea de detalii preliminare privind
cerinţele informaţionale ale diferitelor persoane interesate de sistem, ajutând la identificarea
domeniilor ce necesită cercetări suplimentare cu ajutorul interviurilor, analizei documentelor şi
al observării. Chestionarele permit obţinerea unor informaţii de natură cantitativă, plecând de
la întrebări de genul: „Ce formulare folosiţi pentru introducerea datelor despre clienţii noi?”,
„În medie, cât durează introducerea datelor de pe o comandă?”. De asemenea, sunt folosite
pentru a identifica opinia utilizatorilor faţă de anumite aspecte privind sistemul, cu ajutorul
unor întrebări de forma: „Pe o scară de la 1 la 7, specificaţi cât de importantă este
disponibilitatea sistemului privind accesul la istoricul operațiilor cu clienţii?”. Astfel de
întrebări direcţionează persoanele chestionate să răspundă numai la întrebarea pusă, fără să
lase loc de interpretări sau discuţii.
Chestionarul este folosit când este necesar să se culeagă informaţii de la un număr mai
mare de persoane din cadrul organizaţiei. El poate fi folosit când4:
 persoanele importante pentru sistem sunt dispersate teritorial;
 volumul informaţiilor ce trebuie culese este relativ mic, dar există foarte multe
persoane implicate în proiect;
 este necesară o acţiune de cercetare, înainte ca interviurile să aibă loc, de exemplu
atunci când trebuie identificate problemele sistemului;
 se verifică datele culese cu ajutorul altor metode.
Una din problemele pe care le ridică utilizarea chestionarului constă în faptul că
utilizatorilor s-ar putea să li se pară dificil să-şi specifice cerinţele sub formă scrisă pentru o
4. Flynn, D. – Information Systems Requirements: Determination & Analysis, 2nd Edition, McGraw Hill Companies,
London, 1998, p. 138.
serie de întrebări deschise, pentru că procesul poate să le ia mai mult timp decât dacă ar fi
răspuns acelor întrebări prin intermediul unui interviu. De asemenea, chestionarul s-ar putea să
nu conţină exact întrebările la care se aşteptau să răspundă pentru a-şi specifica cerinţele.
La prima vedere, chestionarele par a fi cea mai rapidă modalitate de culegere a unui
volum relativ mare de informaţii despre modul în care utilizatorii văd sistemul curent, despre
problemele cu care se confruntă în activitatea lor şi despre ce se aşteaptă de la noul sistem.
Chiar dacă este într-o anumită măsură adevărat că se pot culege mai multe informaţii într-un
timp mai scurt faţă de interviu, elaborarea unor chestionare eficiente solicită un timp destul de
mare pentru pegătirea şi conceperea lor. În primul rând, este necesar să se stabilească cu
claritate ce se doreşte să se obţină prin utilizarea sondajului pe bază de chestionar. De
exemplu, dacă se încearcă să se identifice care este procentul de utilizatori ce preferă existenţa
unei pagini cu întrebări frecvente (FAQs) ca mijloc de învăţare a noilor aplicaţii, un chestionar
ar fi cea mai adecvată tehnică. Dacă însă se doreşte să se analizeze detaliat procesul pe care îl
parcurge un manager pentru luarea unei decizii, interviul ar fi o opţiune mai bună.
Deoarece conceperea chestionarului este mai mult o artă decât o ştiinţă, specialiştii s-au
străduit să-şi prezinte experienţa sub forma unor reguli, recomandate îndeosebi începătorilor;
cei cu state vechi le pot utiliza drept elemente de comparaţie pentru a-şi evalua paşii întregii
proceduri. Din aceste motive, considerăm de bun augur descrierea paşilor parcurşi pentru
conceperea unui chestionar în viziunea lui Gilbert Churchill, Jr.5, conform figurii nr. 6.3.
Pas 1 Identificarea informaţiilor ce vor fi căutate
Pas 2 Stabilirea tipului de chestionar

şi a metodei de administrare
Pas 3 Determinarea conţinutului

fiecărei întrebări
Pas 4 Stabilirea formei de redactare a

răspunsului pentru fiecare întrebare
Pas 5 Formularea întrebărilor
Pas 6 Stabilirea secvenţei derulării întrebărilor
Pas 7 Stabilirea caracteristicilor

tehnice ale chestionarului
Pas 8 Reevaluarea paşilor 1-7 şi revizuirea lor,

dacă este cazul
Pas 9 Efectuarea pretestului şi revizuirea finală,

dacă este cazul
Fig. 6.3 Procedura conceperii chestionarului
5. Churchill, Jr., G.A. – Basic Marketing Research, The Dryden Press, Chicago, 1988, pp. 269-297.
Alegerea între interviu şi chestionar se poate efectua prin luarea în considerare a

caracteristicilor prezentate în tabelul 6.4.
Tabel nr. 6.4 – Caracteristicile interviului şi chestionarului
Caracteristici Interviu Chestionar
Cantitatea de informaţii Mare (deoarece se pot folosi mai Medie spre joasă (se folosesc
obţinute multe canale) doar răspunsurile)
Personal angajat în Redus (în comparaţie cu
Relativ numeros
operaţiune interviurile)
Număr de persoane implicate Mic, dar posibilitatea de a avea Mare, dar numărul răspunsurilor
în operaţiune (testate) toate răspunsurile este foarte mare primite poate fi foarte mic
Valoare cheltuieli Mare Moderată
Timp de pregătire Redus Mare
Timp de operare Mare Scăzut-mediu
Timp de prelucrare finală Mic Mediu-mare
Posibilitatea evitării
Mare-foarte mare (dinamică) Mică (limitată)
neînţelegerilor
Confidenţialitate Respondentul poate să fie
Se cunoaşte intervievatul
necunoscut
Grad de reuşită a operaţiunii,
Mare Modest
prin implicarea părţii testate
Procent de reuşită a testului Mare-foarte mare Redus
6.3 Intervievarea grupurilor

Un inconvenient al aplicării interviurilor şi chestionarelor pentru colectarea cerinţelor
sistemelor îl constituie apariţia unor contradicţii aparente între datele colectate; reconcilierea
lor presupune intervenţia analistului.
Multe neclarităţi pot fi lămurite prin alte interviuri sau convorbiri telefonice, ceea ce
constituie o activitate anevoioasă şi nu prea agreată de interlocutori, transformând activitatea
de colectare a cerinţelor sistemului într-una ineficientă. Operaţiunea salvatoare este cea a
intervievării grupurilor. Printr-un interviu al grupului are loc intervievarea concomitentă a unui
grup de persoane-cheie. Operaţiunea se efectuează de unul sau mai mulţi analişti, situaţie în
care se realizează o împărţire a sarcinilor: o persoană va avea rolul de operator al interviului,
alta va consemna răspunsurile obţinute, în timp ce alte persoane pot avea rolul de urmărire a
unor probleme bine definite, mai specializate (una urmăreşte cererea de date, alta oportunitatea
şi declanşatorii evenimentului ş.a.m.d.).
Paşii de parcurs pentru planificarea şi desfăşurarea interviurilor de grup sunt:
 determinarea obiectivelor proiectului pentru care se intervievează grupul şi definirea
problemei;
 specificarea obiectivelor acţiunii care se va întreprinde (ale interviului);
 stabilirea obiectivelor/întrebărilor la care vor răspunde participanţii;
 redactarea unui plan de interviu;
 dezvoltarea rolului moderatorului;
 conducerea interviului de grup;
 revederea casetelor şi analiza datelor;
 sintetizarea elementelor identificate în urma interviului de grup.
Caracteristicile unui interviu de grup sunt prezentate în tabelul 6.56.
6. Malhotra, N.K. – Marketing Research – An Applied Orientation, Prentice Hall, Upper Saddle River, New Jersey,
1996, pp. 166-167.
Tabel nr. 6.5 – Caracteristicile interviului de grup

Nr. Caracteristici Explicaţii
crt.
1 Mărimea Se consideră că numărul optim al unui grup este de la 8 la 12 persoane. Mai
grupului puţin de opt persoane nu asigură dinamica grupului, iar mai mult de 12
persoane pot să determine o serie de discuţii neconcludente pentru problemele
puse în discuţie.
2 Structura Grupul trebuie să fie omogen din punct de vedere al participanţilor, pentru că
grupului în acest fel sunt evitate conflictele asupra unor probleme ce pot să aibă
semnificaţii diferite. Participanţii grupului trebuie să fie analizaţi şi selectaţi
pe baza anumitor criterii, care să asigure nivelul de coeziune. Participanţii
trebuie să aibă o anumită experienţă în ceea ce priveşte problemele puse în
discuţie. De asemenea, nu este recomandată includerea în grup a unor
persoane care au participat la foarte multe interviuri de grup.
3 Mediul fizic de O atmosferă relaxată, informală, încurajează comentariile spontane. Servirea
lucru băuturile răcoritoare trebuie să aibă loc înainte de a începe interviul de grup,
dar poate fi realizată şi în timpul lui.
4 Durata Deşi interviurile de grup pot să dureze de la o oră la trei ore, de cele mai
interviului multe ori ele se desfăşoară într-o oră sau o oră şi jumătate. Această durată este
necesară pentru a stabili raportul cu participanţii şi de a explora credinţele,
sentimentele lor, ideile, atitudinile cu privire la problemele puse în discuţie.
5 Înregistrarea Interviurile de grup sunt înregistrate, adesea pe casete video, pentru revederea
imaginilor, transcriere şi analiză.
6 Moderatorul Moderatorul joacă un rol cheie în interviurile de grup. El trebuie să
stabilească legătura cu participanţii, să asigure continuarea discuţiilor şi
posibilitatea de exprimare a fiecărui participant. În plus, moderatorul poate să
aibă un rol esenţial în analiza şi interpretarea datelor, ceea ce implică anumite
competenţe din partea acestuia, respectiv: puterea de observare, relaţii
interpersonale, comunicare.
În faţa unui grup, tracul este normal, cu atât mai mult în cazul în care membrii lui sunt
persoane necunoscute. Atitudinea grupului va fi diferită, după cum prezenţa lor la o acţiune
este percepută ca o constrângere sau ca o alegere liberă. În primul caz, trebuie să ne aşteptăm
la reacţii de respingere şi să învăţăm să le stăpânim.
Caracteristicile unui grup sunt următoarele:
 grupul are un mod simplu de a gândi: el este mai lent decât cel al fiecărui individ.
Nivelul său este inferior nivelului fiecărui membru al grupului. Atitudinea sa este mai
apropiată de un comportament adolescentin;
 sensibilitatea unui grup de persoane este instabilă: nu suportă critica colectivă. Grupul
este sensibil la umor şi simte nevoia de a se destinde;
 atenţia grupului este mobilă: distragerile sunt multiple, trebuie evitate zgomotele
exterioare, întreruperile pe parcursul interviului;
 un grup are o slabă rezistenţă la oboseală: este necesar un confort deosebit;
 un grup este mai xenofob decât fiecare individ în parte: după ce grupul s-a constituit,
toţi participanţii care se alătură ulterior grupului vor întâmpina dificultăţi în a se
integra.
În concluzie, este dificil de lucrat cu un grup.
Paralel cu caracteristicile proprii, pentru toate grupurile trebuie ţinut cont de
personalităţile individuale ale participanţilor care compun acest grup.
Comportamentele individuale tip apar spontan în formarea grupului. Fiecare îndeplineşte
un anumit rol, adoptând o anumită atitudine (mediator, lider, perturbator, pol al atenţiei
celorlalţi etc.). Este important pentru mediator să ştie să recunoască aceste diferenţe
individuale, să le folosească sau să le neutralizeze, astfel încât grupul să poată progresa.
Un interviu în grup are câteva avantaje:
 folosirea mai eficientă a timpului alocat interviului decât în varianta unei serii de
interviuri individuale;
 intervievarea concomitentă a mai multor persoane le permite acestora să-şi asculte
reciproc declaraţiile, fie pentru a le susţine, fie pentru a le combate, fie pentru a se
formula noi păreri;
 prin interviuri colective se pot efectua delimitări clare între punctele de vedere
acceptate de toţi intervievaţii şi cele ce stârnesc mari divergenţe.
Ca dezavantaj principal: dificultatea planificării calendaristice a desfăşurării interviului,
datorită implicării mai multor persoane care trebuie să participe concomitent la acest proces.
Tehnologiile moderne, îndeosebi diferitele forme ale videoconferinţelor, pot simplifica
procesul intervievării colective, minimizând influenţa nefastă a dispersiei geografice care face
dificilă întâlnirea membrilor grupului.
6.4 Observarea directă a utilizatorilor

Nu întotdeauna consultarea persoanelor conduce la obţinerea celor mai bune rezultate,
chiar şi atunci când acestea afirmă că oferă cele mai sigure informaţii sau au impresia că deţin
adevărul absolut asupra sistemului analizat. Părerile sunt subiective. Explicaţia constă în
apariţia ocazională a unor evenimente, în punerea amprentei timpului asupra unor sentimente
sau chiar în apariţia elementului pasional. Anularea efectelor subiectivismului se poate realiza
prin urmărirea a ceea ce personalul execută sau prin evaluări obiective ale efectului activităţii.
Observarea este utilă pentru a determina modul în care lucrează actualul sistem şi mai
puţin pentru a stabili cum ar trebui să funcţioneze cel nou, ajutând la înţelegerea funcţiilor
economice. Totuşi, există şi posibilitatea de a se crea o imagine despre noul sistem, asociind
procesele economice identificate, în sensul că atunci când se observă procesele economice
curente, nu trebuie să se uite că pot şi trebuie să fie modificate pentru a fi mai eficiente7. De
asemenea, prin observare, analiştii încearcă să stabilească care sunt relaţiile dintre o anumită
persoană implicată în luarea unor decizii sau desfăşurarea unei activităţi şi alte persoane din
firmă sau din afara ei8. În plus, prin observarea mediului în care se desfăşoară diferitele
activităţi, se pot identifica factorii care pot influenţa procesul decizional (echipamente folosite,
ambianţa biroului, ergonomia locului de muncă).
Observarea presupune înregistrarea comportamentului de bază al persoanelor, obiectelor
sau evenimentelor, într-o manieră sistematică, pentru obţinerea informaţiilor despre un anumit
element (fenomen) de interes din cadrul sistemului. Observatorul nu întreabă şi nici nu
comunică cu persoanele observate.
Observarea se poate face în câteva moduri, de la a merge prin birouri sau secţii şi până la
desfăşurarea de către analişti a activităţilor utilizatorilor. Prin deplasarea prin diferite locuri din
firmă, se formează o perspectivă asupra activităţilor desfăşurate acolo, eventualele nevoi
privind utilizarea unor echipamente şi fluxul general de lucru. Prin petrecerea câtorva ore
alături de utilizatori, pentru a observa cum îşi desfăşoară activităţile, se obţin detalii privind
modul în care sunt folosite anumite echipamente şi cum sunt realizate funcţiile economice. Prin
transpunerea în ipostaza de utilizator şi realizând o parte din activităţile specifice, se descoperă
dificultăţile întâmpinate în înţelegerea şi învăţarea procedurilor noului sistem, importanţa
uşurinţei în exploatarea sistemului, unde se împotmolesc utilizatorii în folosirea unor proceduri
specifice, precum şi respectarea regulilor economice.
Nu este necesar ca toate procesele să fie supuse observării la acelaşi nivel de detaliere. O
simplă trecere prin birouri poate fi suficientă pentru un anumit proces, în timp ce pentru altul,
de importanţă capitală sau mai dificil de înţeles, ar putea să fie nevoie de o perioadă mai mare

8. Kendall, K.E., Kendall, J.E. – op. cit., p. 181.
de timp. Ca şi în cazul interviurilor, este mult mai benefic dacă la observare ar participa doi
analişti, pentru a combina eforturile şi rezultatele procedurilor de observare9.
Observarea utilizatorilor poate fi clasificată după mai multe criterii, şi anume:
1. după modul în care sunt stabilite elementele ce vor fi supuse observării10:
 structurată, când analiştii specifică în detaliu ce va fi supus observării şi cum vor fi
înregistrate rezultatele observării. Acest lucru reduce tendinţa ca analistul să afecteze
credibilitatea datelor. Observarea structurată este recomandată atunci când problema
analizată a fost foarte clar definită şi s-au stabilit cu exactitate informaţiile necesare
rezolvării ei. În aceste circumstanţe, se desprind cu lejeritate detaliile despre
activităţile supuse observării.
 nestructurată, când analistul monitorizează toate aspectele despre activităţile de interes
care par a fi relevante pentru problema identificată. Această formă de observare se
aplică atunci când problema urmează să fie formulată în mod explicit şi când, pentru
identificarea componentelor cheie ale problemei şi pentru dezvoltarea ipotezelor de
lucru, este cerut un anumit grad de flexibilitate. În observarea nestructurată, tendinţa
analistului de a fi influenţat de aspectele observate este foarte mare. Din această cauză,
elementele supuse observării trebuie să fie tratate ca ipoteze de verificat şi nu ca
aspecte concludente ale problemei analizate.
2. după modul în care se stabileşte momentul desfăşurării11:
 observarea pe bază de intervale de timp, prin alegerea aleatoare a unor perioade din zi,
ceea ce înseamnă că pot fi observate activităţile pe care le desfăşoară în mod curent
utilizatorii. Însă, printr-o astfel de modalitate, se culeg date fragmentate ce nu asigură
analiza completă a unui eveniment, de la iniţierea şi până la finalizarea lui. De
asemenea, în cazul unor evenimente ce au loc la intervale mai mari de timp, e posibil
ca acestea să nu poată fi surprinse prin momentul stabilit;
 observarea pe bază de evenimente, ce permite analiza completă a comportamentului în
contextul natural, de la iniţierea evenimentului şi până la studierea efectelor acestuia.
Însă, nici această formă de observare nu este lipsită de dezavantaje, datorită duratei
relativ mari de aşteptare până la apariţia unui eveniment sau a perioadei mari de timp
pe care o presupune realizarea lui; apare şi riscul de a omite activităţile curente care au
loc în cadrul sistemului. Ca atare, analiştii apelează, de multe ori, la o combinaţie a
celor două tipuri de observări, pentru a analiza atât activităţile curente, cât şi pe cele
care au loc doar în anumite condiţii.
3. în funcţie de înştiinţarea sau nu a utilizatorilor:
 camuflată, ceea ce presupune că persoanele observate nu sunt înştiinţate că vor fi
supuse observării. Această formă dă posibilitatea utilizatorilor de a avea un
comportament natural, pentru că oamenii au întotdeauna tendinţa de a se comporta
diferit când ştiu că sunt supuşi observării.
 necamuflată, care presupune înştiinţarea utilizatorilor că vor fi supuşi unei observări.
De exemplu, li se poate spune că analistul va sta o perioadă de timp printre ei. Acest
tip de observare nu este foarte des practicat. Se consideră că persoanele observate îşi
vor modifica comportamentul pe perioada prezenţei analistului printre ele.
4. după cadrul în care se va desfăşura observarea:
 naturală, constă în observarea comportamentului în mediul de lucru al utilizatorilor.
De exemplu, observarea celor care lucrează cu o anumită aplicaţie în cadrul biroului în
care ei îşi desfăşoară activitatea zi de zi. Avantajul observării naturale îl constituie
faptul că activităţile observate vor reflecta adevărata lor valoare. Dezavantajul constă

10. Malhotra, N.K. – op. cit., pp. 213-214.
în costul aşteptării desfăşurării activităţilor şi dificultatea evaluării acestora în mediul

natural de lucru.
 construită, în care comportamentul utilizatorilor este observat într-un mediu creat, cum
ar fi un birou în care se fac testele diferitelor aplicaţii.
Observarea activităţilor utilizatorilor presupune parcurgerea paşilor12:
 stabilirea a ceea ce va fi supus observării (activităţile, procesele, mediul de lucru);
 determinarea gradului de detaliere a observării, care va influenţa modul de interacţiune
cu utilizatorii, precum şi timpul necesar analizei şi interpretării activităţilor observate;
 pregătirea listelor de verificare şi a altor materiale necesare desfăşurării observării
propriu-zise;
 stabilirea momentului observării;
 desfăşurarea observării;
 interpretarea şi analiza informaţiilor înregistrate pe parcursul acţiunilor specifice.
Ca tehnici de realizare a observării pot fi enumerate13:
 observarea personală, când o persoană urmăreşte comportamentul utilizatorilor.
Observatorul nu încearcă să controleze sau să manipuleze activităţile supuse
observării, ci numai înregistrează ceea ce are loc. De exemplu, analistul poate să
înregistreze circuitul fluxurilor de informaţii din cadrul unui compartiment.
 observarea mecanică, ceea ce implică utilizarea mai mult a dispozitivelor mecanice
decât a observatorilor umani, prin care se înregistrează activităţile observate. Aceste
dispozitive pot să înregistreze continuu comportamentul utilizatorilor, chiar şi pentru o
analiză ulterioară.
 auditarea, care presupune din partea analistului să colecteze datele prin examinarea
înregistrărilor fizice sau executarea unei analize asupra activităţilor derulate de-a
lungul timpului.
 analiza de conţinut este cea mai adecvată metodă atunci când activităţile supuse
observării apelează foarte mult la comunicare şi mai puţin la comportament. Unitatea
de analiză ar putea fi cuvintele, caracterele persoanelor, măsurile de timp şi spaţiu.
 analiza înregistrărilor, prin care colectarea datelor se realizează pe baza evidenţelor
fizice sau a unui comportament studiat anterior.
Desfăşurarea operaţiunii de observare directă depinde şi de acceptul sau bunele intenţii
ale organizaţiei supuse analizei. Uneori, chiar dacă există un astfel de accept, prezenţa
analiştilor printre angajaţi îi determină pe aceştia din urmă să manifeste un comportament
anormal, cu scopul de a crea o anumită impresie. Astfel, pot fi emoţionaţi, stresaţi, se pot forţa
să efectueze lucrările mai repede, să simuleze ocuparea completă a timpului de muncă. Alteori,
dacă au un alt obiectiv, ei pot lucra mai încet, pot bruia noul sistem ş.a.
O altă problemă se referă la imposibilitatea observării pe termen lung a sistemului.
Discutabile sunt şi momentele surprinse, şi persoanele ce ar putea fi urmărite – ca număr.
Aşadar, observarea presupune pentru analişti luarea în considerare a unei palete foarte
largi de factori ce ar putea influenţa rezultatul acţiunii.
6.5 Analiza procedurilor de lucru şi a altor documente

Metodele amintite anterior pot fi completate cu cea din paragraful curent, pentru obţinerea
celor mai relevante date despre sistemul analizat, prin examinarea documentaţiei sistemului şi
a organizaţiei.
Pentru procedurile şi formularele existente apar două principale surse de informaţii:
externe şi interne14.
12. Kendall, K.E., Kendall, J.E. – op. cit., pp. 182-183.

13. Malhotra, N.K. – op. cit., pp. 214-218.
Sursele externe sunt cele provenite de la organizaţiile profesionale din domeniul în care
activează firma sau de la alte firme din aceeaşi ramură de activitate. Uneori, revistele de
specialitate prezintă studii privind „cele mai bune practici” şi rezultatele obţinute de diferite
firme în dezvoltarea şi implementarea unor sisteme, cum ar fi relatarea cazurilor de succes în
implementarea sistemelor ERP. De asemenea, prin extinderea graniţelor organizaţionale,
sursele externe devin din ce în ce mai importante pentru identificarea cerinţelor informaţionale,
presupunând investigarea practicilor şi procedurilor partenerilor de afaceri implicaţi în lanţul
valoric al firmei.
Sursele interne servesc pentru atingerea a două obiective. Primul este de a înţelege, în
special de către membrii echipei ce nu cunosc îndeajuns de bine firma, procesele economice
ale acesteia, dar şi pentru stabilirea întrebărilor din interviuri şi chestionare. Al doilea scop îl
constituie utilizarea documentelor existente în timpul interviurilor pentru a asigura o mai bună
comunicare şi înţelegere a întrebărilor şi răspunsurilor de către ambele părţi. Formularele şi
rapoartele pot servi la vizualizarea unor aspecte ce sunt subiectul interviurilor, dar şi ca
documente de lucru pentru discuţiile dintre membrii echipei proiectului, care se concentrează
pe utilizarea fiecărui formular, obiectivele utilizării lui, distribuţia, conţinutul, precum şi
evenimentele ce declanşează folosirea acestuia. Este posibil ca evenimente economice diferite
să solicite acelaşi formular, iar identificarea informaţiilor despre evenimentele şi procesele
economice devine esenţială. În această activitate, este util ca echipa să apeleze la formulare ce
sunt completate cu date reale pentru a se asigura că s-a obţinut o imagine clară şi s-a înţeles
rolul fiecărui element din formular şi conţinutul său în ansamblu.
Analiza documentaţiei privind procedurile existente ajută la identificarea regulilor
economice care e posibil să nu poată fi desprinse în timpul interviurilor, precum şi la
descoperirea unor redundanţe ce apar la nivelul proceselor economice. Totuşi, se întâmplă ca
unele manuale ce descriu procedurile de lucru să nu fie actualizate şi să conţină anumite erori
care nu au fost eliminate. De aceea, pentru a se asigura că ipotezele de lucru şi regulile
economice identificate în documentaţia existentă sunt corecte, este necesar ca analiza lor să se
efectueze împreună cu utilizatorii.
Documentele ce pot fi studiate sunt de o mare diversitate. Tratamentul lor în materialul de
faţă nu poate fi exhaustiv. Dintre documentele mai des solicitate fac parte: declararea viziunii,
misiunii şi strategiei organizaţiei, obiectivele acesteia, planurile de afaceri, studiile de
fezabilitate, structura organizatorică (organigrama), planul sistemului informaţional anterior
sau curent, regulamentele de organizare şi funcţionare, a celor de ordine interioară, normele
interne de fabricaţie, standardele folosite, fişele posturilor, corespondenţa internă şi externă,
rapoartele de analiză obţinute din studii anterioare ş.a. Astfel, documentele analizate pot fi
grupate în mai multe categorii15:
 rapoartele generate de sistemul actual;
 procedurile de lucru pentru activităţi individuale sau ale grupurilor. Prin ele se descrie
modul în care se exercită o anumită activitate, prezentându-se şi datele şi/sau informaţiile
pe care le solicită sau le generează. Analiza procedurilor poate evidenţia:
 repetarea activităţilor în două sau mai multe locuri de muncă declarate cu sarcini
diferite;
 absenţa procedurilor de lucru pentru unele activităţi;
 depăşirea valabilităţii în timp a procedurii;
 procedurile formale contrazise de realitatea constatată prin interviuri, chestionare şi
alte metode folosite la studierea sistemului;
 formularele utilizate de unitate pentru toate operațiile interne şi externe;
 documentaţia folosită în sistemul informatic (numai în cazul sistemelor de prelucrare
automată a datelor).
15. Hoffer, J.A., George, J.F., Valacich, J.S. – Modern Systems Analysis and Design, The Benjamin/Cummings
Publishing Company, Inc., Sand Hill Road, Menlo Park, 1998.
Din documentele analizate se va încerca să se obţină informaţii despre:

 problemele existente în sistemul curent, cum ar fi prezenţa unor informaţii
redundante, a unor „puncte de ştrangulare” sau absenţa unor informaţii;
 posibilităţile de obţinere condiţionată a unor informaţii, cum ar fi lansarea în execuţie
a unor programe speciale;
 preocupări pe linia schimbării politicii privind tratarea unor categorii de informaţii.
De exemplu, trecerea la sistemele de afaceri electronice pentru îmbunătățirea relaţiilor
cu partenerii de afaceri;
 numele şi funcţiile persoanelor direct interesate de soarta sistemului;
 obiectivele-cheie ale organizaţiei sau/şi ale persoanelor sau grupurilor de persoane,
atât pe termen scurt, cât şi pe termen lung;
 procedurile speciale de prelucrare a unor informaţii din sistem;
 motivele proiectării sistemului curent, aşa cum este el în faza analizei;
 datele, regulile de prelucrare a lor, principiile pe baza cărora funcţionează sistemul
informaţional.
Analiza documentelor şi procedurilor de lucru ajută la descrierea modului în care se
intenţionează să lucreze sistemul, echipa având posibilitatea să identifice diferenţele dintre
funcţiile sistemului actual şi cele propuse pentru noul sistem.
Metoda este folosită pentru a documenta rezultatele obţinute în timpul intervievării şi
observării utilizatorilor, permiţând descrierea fluxurilor de date, documentelor şi procedurilor,
cunoscute sub denumirea de fluxuri informaţionale.
O comparaţie a observării directe cu analiza documentelor este prezentată în tabelul 6.6.
Tabel nr. 6.6 – Analiza comparativă a observării directe şi analizei documentelor
Caracteristici Observarea Analiza documentelor
Cantitatea de informaţii obţinute Mare (deoarece se pot folosi
Scăzută (pasivă) şi veche
multe canale)
Personal angajat în operaţiune Rezonabil ca număr Ridicat ca număr
Număr persoane implicate în
Mediu Scăzut
operaţiune (testate)
Valoare cheltuieli Poate fi ridicată Scăzută spre moderată
Timp de pregătire Ridicat Scăzut spre moderat
Timp de operare Mediu Lung
Timp de prelucrare finală Ridicat Mediu
Posibilitatea evitării
Mare Mediu
neînţelegerilor
Confidenţialitate Persoana este remarcată şi cei
Depinde de natura
observaţi îşi pot schimba
documentelor observate
comportamentul
Grad de reuşită a operaţiunii, Depinde dacă cei observaţi ştiu că
Nu implică partea testată
prin implicarea părţii testate sunt supuşi observării
Procent de reuşită a testului Mare Redus-mediu
Rezumat
Timpul necesar culegerii informaţiilor este imens, iar cheltuielile sunt pe măsură. Este necesară
cunoaşterea sloganului care circulă printre analişti „analysis paralysis” (analizele paralizează), referindu-
se la excesele de zel din faza de analiză.
Ca efect al tendinţelor de mărire a timpului de analiză a sistemelor existente, în ultimii ani, s-a
efectuat trecerea spre analiza cu ajutorul unor tehnici mai rapide. Astfel, tehnicile moderne, JAD şi
prototipizarea, preiau tot mai puţine elemente din sistemele existente, ca urmare a analizelor efectuate.
Altele, mai radicale, renunţă aproape total la analiza sistemului existent. Este cazul proceselor controlate
prin RAD (Rapid Application Development), care apelează la JAD, prototipizare şi alte instrumente
integrate de tip CASE.
Metodele tradiţionale de colectare a cerinţelor sistemului sunt: interviuri individuale; anchete
realizate prin chestionare; intervievarea grupurilor de oameni cu interese comune; observarea
personalului; studierea documentaţiei firmei.
Intervievarea este de departe una din cele mai bune metode de a înţelege funcţiile şi regulile
economice, dar şi activitatea consumatoare de timp şi alte resurse, fiind calea relativ uşoară prin care
utilizatorii pot să-şi exprime planurile lor pentru sistemul dorit, cu ajutorul propriului limbaj, şi pot
controla perioada de timp pe care o alocă interviului.
Etapele de bază ale unui interviu sunt: planificarea (pregătirea) interviului, desfăşurarea propriu-
zisă şi finalizarea şi stabilirea activităţilor postinterviu.
Indiferent de tipul interviului, unele principii şi tehnici au o aplicabilitate generală. Acestea sunt
împărţite în trei părţi majore: deschiderea, partea principală, închiderea.
Spre deosebire de interviuri, chestionarele sunt mai puţin costisitoare şi, într-un timp relativ scurt,
pot oferi un volum mare de informaţii necesare analizei sistemului. Prin utilizarea chestionarelor se
urmăreşte obţinerea de detalii preliminare privind nevoile informaţionale ale diferitelor persoane
interesate de sistem, ajutând la identificarea domeniilor ce necesită cercetări suplimentare cu ajutorul
interviurilor, analizei documentelor şi al observării.
Paşii pentru conceperea unui chestionar sunt: identificarea informaţiilor ce vor fi căutate, stabilirea
tipului de chestionar şi a metodei de administrare, determinarea conţinutului fiecărei întrebări,
stabilirea formei de redactare a răspunsului la fiecare întrebare, formularea întrebărilor, stabilirea
secvenţei derulării întrebărilor, stabilirea caracteristicilor tehnice ale chestionarului, reevaluarea
paşilor anteriori şi revizuirea lor, efectuarea pretestului şi revizuirea finală.
Un inconvenient al aplicării interviurilor şi chestionarelor pentru colectarea cerinţelor sistemelor îl
constituie apariţia unor contradicţii aparente între datele colectate; reconcilierea lor presupune intervenţia
analistului. Operaţiunea salvatoare este cea a intervievării grupurilor. Printr-un interviu al grupului are
loc intervievarea concomitentă a unui grup de persoane-cheie.
Paşii care se parcurg pentru planificarea şi desfăşurarea interviurilor de grup sunt: determinarea
obiectivelor proiectului pentru care se intervievează grupul şi definirea problemei; specificarea
obiectivelor acţiunii care se va întreprinde (ale interviului); stabilirea obiectivelor/întrebărilor la care
vor răspunde participanţii grupului; redactarea unui plan de interviu; dezvoltarea rolului
moderatorului; conducerea interviului de grup; revederea casetelor şi analiza datelor; sintetizarea
elementelor identificate în urma interviului de grup.
Observarea uilizatorilor presupune înregistrarea comportamentului de bază al persoanelor,
obiectelor sau evenimentelor într-o manieră sistematică pentru obţinerea informaţiilor despre un anumit
element (fenomen) de interes din cadrul sistemului. Observatorul nu întreabă şi nici nu comunică cu
persoanele observate.
Metodele amintite anterior pot fi completate cu examinarea documentaţiei sistemului şi a
organizaţiei, pentru obţinerea celor mai relevante date despre sistemul analizat. Analiza documentaţiei
privind procedurile existente ajută la identificarea regulilor economice care e posibil să nu poată fi
desprinse în timpul interviurilor, precum şi la descoperirea unor redundanţe ce apar la nivelul proceselor
economice.
Metodelor tradiţionale, prezentate anterior, li se adaugă aşa-zisele metode moderne, dintre care
amintim: Joint Application Design (JAD), sistemele de sprijinire a grupurilor, instrumentele CASE şi
prototipizarea. Toate aceste metode sprijină procesul de culegere şi structurare a informaţiilor prin
diminuarea substanţială a timpului dedicat analizei de sistem.
1. Enumeraţi paşii specifici derulării unui interviu.
2. Care sunt paşii care se parcurg pentru conceperea unui chestionar?
3. Prezentaţi comparativ caracteristicile interviului şi chestionarului.
4. În ce situaţii se impune utilizarea interviului de grup?
5. Enumeraţi şi descrieţi principalele caracteristici ale unui grup de care trebuie să se ţină cont în
intervievarea lui.
6. Ce paşi se parcurg pentru planificarea şi desfăşurarea interviurilor de grup?

7. Care sunt avantajele şi dezavantajele interviului de grup faţă de cel individual?
8. Enumeraţi motivele pentru care observarea este utilă în determinarea cerinţelor sistemului.
9. Specificaţi tipurile de observări posibil de efectuat în timpul etapei de analiză.
10. Enumeraţi avantajele observării bazată pe evenimente.
11. Prezentaţi avantajele şi dezavantajele observării.
12. Care este utilitatea analizei procedurilor de lucru şi a altor documente?
13. Ce tipuri de informaţii se pot obţine din analiza procedurilor şi documentelor?
14. Descrieţi principalele surse de informaţii folosite în analiza procedurilor şi documentelor.
15. Care sunt principalele aspecte urmărite în timpul analizei procedurilor?
Probleme de echipă
1. A fost planificat un interviu cu managerul de vânzări al unei firme de papetărie, care doreşte să
prezinte o serie de informaţii despre produse şi vânzări pe Intranet, astfel încât toţi angajaţii să aibă
acces la ele pentru îmbunătăţirea prognozelor privind vânzările. Reformulaţi următoarele întrebări,
ştiind că, aşa cum sunt prezentate, nu au fost formulate corespunzător:
a) Personalul de vânzări din subordine a specificat faptul că aveţi reţineri în privinţa utilizării
calculatorului. Este adevărat?
b) Ce surse de informaţii folosiţi cel mai mult pentru analiza vânzărilor şi cât de frecvent?
c) Sunteţi de acord cu plasarea lunară a informaţiilor privind vânzările pe Intranet pentru realizarea
analizelor de vânzări şi îmbunătăţirea esenţială a sistemului de vânzări?
d) Nu credeţi că este o cale mult mai bună decât cea folosită până acum?
2. Ca echipă de analiză pentru un proiect de îmbunătăţire a funcţiilor sistemului contabil al unei firme
de ceasuri, urmează să-l intervievaţi pe contabilul-şef. Formulaţi 4-6 obiective ale interviului care să
acopere sursele de informaţii pe care le foloseşte, formatul rapoartelor, frecvenţa luării deciziilor,
calitatea informaţiilor dorite.
a) Într-un paragraf, precizaţi cum îl veţi aborda pe contabilul-şef pentru planificarea interviului.
b) Stabiliţi structura interviului pe care o veţi alege şi motivaţi propunerea.
c) Contabilul-şef are în subordine 3 salariaţi care folosesc sistemul. Îi veţi intervieva şi pe ei?
Motivaţi dacă este necesar sau nu.
d) Formulaţi 3 întrebări deschise pe care le veţi transmite prin e-mail contabilului-şef înainte de a
se desfăşura interviul. Explicaţi de ce este de preferat să se realizeze interviul faţă-în-faţă şi nu
prin intermediul e-mailului.
e) Formulaţi cel puţin 5 întrebări închise prin care să obţineţi informaţiile privind formatul
rapoartelor şi calitatea informaţiilor solicitate.
CAPITOLUL VII
Modelarea logică, grafică,

a proceselor de prelucrare
Obiective:
 Înţelegerea conceptului de modelare a proceselor de prelucrare a datelor, redat
prin intermediul diagramelor fluxurilor de date (DFD)
 Descrierea principalelor simboluri utilizate în construirea DFD de către două
din cele mai utilizate tehnici de modelare: Gane & Sarson şi Yourdon & DeMarco
 Prezentarea paşilor care se parcurg şi a recomandărilor pentru construirea DFD
 Definirea regulilor care stau la baza construirii DFD
 Cunoaşterea aspectelor privind descrierea modelului logic al sistemului cu ajutorul
depozitelor de metadate
Toate informaţiile culese despre cerinţele sistemului trebuie să fie înregistrate sub o formă
sau alta, fie că este vorba despre cele funcţionale (CE trebuie să facă sistemul), fie despre cele
tehnice (CUM trebuie să facă sistemul), iar pentru acest lucru se apelează la diferite modele, ce
permit păstrarea lor într-un format structurat. Modelele care se construiesc au şi rolul de a
asigura comunicarea mai uşoară între cei care participă la dezvoltarea sistemului sau sunt
afectaţi de el (beneficiari, utilizatori, finanţatori, echipa de dezvoltare).
Procesul de modelare poate fi considerat ca un proces de învăţare, pentru că pe măsura
creării modelului, echipa de analiză învaţă tot mai mult despre sistem, continuând pe măsura
culegerii cerinţelor, modelele fiind revizuite împreună cu utilizatorii pentru a le verifica,
corecta şi completa.
De asemenea, crearea unor modele grafice ale sistemului, cu ajutorul diferitelor diagrame,
este utilă pentru a obţine o imagine mult mai clară asupra principalelor componente ale
acestuia. Modelarea conceptuală (logică) a sistemului reprezintă începutul activităţilor cu
caracter tehnic din dezvoltarea acestuia, cu scopul de a completa documentaţia de analiză şi de
a reda cuprinzător elementele ce vor fi supuse proiectării.
7.1 Introducere în modelarea sistemelor

Documentaţia descriptivă a sistemului este un mijloc de comunicare între toţi cei implicaţi
în dezvoltarea acestuia, dar nu este, de multe ori, cea mai bună cale pentru a-i descrie cerinţele.
Modelarea foloseşte o combinaţie între formele descriptive şi grafice pentru redarea funcţiilor
(proceselor), datelor şi comportamentului sistemului de o manieră relativ uşor de înţeles. Dar
poate cel mai important aspect al modelării îl constituie flexibilitatea pentru corectarea,
completarea şi asigurarea concordanţei reprezentării sistemului.
În plus, pentru validarea cerinţelor este necesar ca acestea să fie analizate din perspectiva
celor implicaţi în dezvoltarea sistemului (utilizatori, beneficiari, finanţatori, proiectanţi), iar
modelarea poate fi mijlocul prin care cele patru puncte de vedere sunt reunite, conducând la
creşterea probabilităţii de detectare a erorilor încă din faza de analiză, de eliminare a
inconsistenţelor, precum şi de depistare a eventualelor omisiuni.
Abordarea sistemului prin intermediul diferitelor modele permite obţinerea unor avantaje,
în comparaţie cu descrierea narativă, şi anume:
MODELAREA LOGICĂ, GRAFICĂ, A PROCESELOR DE PRELUCRARE 127
 înţelegerea mult mai uşoară a relaţiilor care există între sistem şi mediul extern,
deosebit de importantă pentru identificarea frontierelor acestuia şi a funcţiilor pe care
trebuie să le îndeplinească;
 comunicarea eficientă şi lejeră cu utilizatorii, analiştii putând să solicite efectuarea
unor observaţii suplimentare, pentru completarea şi corectarea modului de
conceptualizare a sistemului, încorporând modificările solicitate de utilizatori, astfel
încât sistemul să redea cât mai bine punctul lor de vedere. Chiar dacă majoritatea
autorilor consideră că prin intermediul diagramelor (modelelor) este mult mai uşor să
se comunice cu utilizatorii, ceea ce este adevărat, acest avantaj nu se obţine automat,
pentru că ei trebuie să fie pregătiţi, în prealabil, pentru a înţelege scopul şi rolul
diagramelor, nicidecum de a crea o şi mai mare confuzie;
 analiza sistemului propus pentru identificarea corectă a datelor şi proceselor
necesare, astfel încât analiza să fie o etapă prin care să se asigure că toate ieşirile
solicitate pot fi obţinute din datele de intrare preluate de sistem şi că logica
prelucrărilor este reflectată prin intermediul diagramelor. Spre deosebire de analiza
fluxului activităţilor, care prezintă modul de derulare a acestora în formă manuală sau
automată, în ordine cronologică, diagramele pun accentul pe prelucrarea datelor şi
transformarea acestora, pe măsura trecerii lor prin diferite procese, fără a se face nici o
diferenţiere între cele manuale sau automate şi fără a se reda secvenţa lor cronologică,
urmărindu-se doar o eventuală grupare a lor, din punct de vedere al logicii
prelucrărilor;
 neincluderea aspectelor tehnice de implementare în etapa de analiză, în sensul că nici
un simbol, cel puţin în modelul logic, nu abordează elementele tehnice de
implementare, care ar putea îngreuna nivelul de înţelegere a utilizatorilor. De
asemenea, acest avantaj elimină riscul stabilirii, încă din etapa de analiză, a unor
tehnologii care se pot dovedi inadecvate în momentul proiectării şi implementării. De
exemplu, chiar dacă prin diagrame se semnalează faptul că datele sunt memorate într-
un loc de stocare, nu se redă sistemul de gestiune a datelor și/sau suportul fizic de
stocare a lor. Astfel, analistul poate conceptualiza fluxurile de date necesare, evitând
redarea aspectelor ce ţin de realizarea lor tehnică.
Există două mari categorii de modele ale sistemului1:
Modelul logic prin care se reprezintă Ce trebuie să facă sistemul, concentrându-se asupra
operaţiilor economice şi a modului în care funcţionează firma sau o anumită componentă
economică a sa, fără a se face trimitere la nici o tehnologie. Echipa de analiză îşi va orienta
eforturile spre ceea ce este necesar şi nu asupra modului în care urmează să se contureze
sistemul. De exemplu, un model poate specifica o ieşire a sistemului ca pe o listă de date
elementare, fără a face trimitere dacă va fi pe hârtie sau afişată pe ecran. Modelul logic are ca
scop reprezentarea informaţiilor de care au nevoie utilizatorii, descriind evenimentele care au
loc şi datele cerute sau generate de fiecare eveniment.
Modelul fizic redă modul în care sistemul va fi implementat, astfel că va deţine mai multe
detalii despre formatul ieşirilor, al ecranelor de preluare a datelor, a modului de interconectare
a reţelelor etc. De aceea, el va surprinde aspectele legate de echipamente, software, baze de
date şi sisteme de gestiune a lor, resurse umane pe care le presupun implementarea şi
exploatarea sistemului.
În tabelul 7.1 sunt prezentate caracteristicile urmărite prin cele două modele. De reţinut că
modelul logic reflectă componenta economică pe care sistemul trebuie să o redea, în timp ce
modelul fizic descrie componentele fizice necesare realizării funcţiilor acestuia. Diferenţa
dintre cele două scoate în evidenţă diferenţa dintre analiza sistemului şi proiectarea lui. În
1. Kendall, K.E., Kendall, J.E. – Systems Analysis and Design, 5th Edition, Prentice Hall, Upper Saddle River, New
Jersey, 2002, p. 251; Satzinger, J.W., Jackson, R.B., Burd, S.D. – Systems Analysis and Design in a Changing
World, Second Edition, Course Technology, Thomson Learning, Boston, 2002, p. 110.
general, analiza presupune crearea de modele logice detaliate, în timp ce proiectarea se bazează
pe cele fizice. Variantele de proiectare create în timpul analizei sunt modele fizice, dar nu
surprind detaliile specifice etapei de proiectare.
Tabel nr. 7.1 – Caracteristicile modelului logic şi fizic al sistemului
Caracteristici Model logic Model fizic
Scopul modelului Ce trebuie să facă sistemul şi cum Cum va fi implementat sistemul sau cum
funcţionează organizaţia sau o va funcţiona el.
componentă economică a sa.
Componentele Activităţile/evenimentele Programele, modulele şi procedurile
reprezentate economice. manuale sau automate ce vor fi executate.
Locurile de stocare Colecţiile de date cu privire la Fişiere şi baze de date sau dosare, registre
redate operaţiile economice, fără a în situaţia sistemelor manuale.
surprinde modul în care datele sunt
memorate şi gestionate.
Tipul datelor La definirea datelor se utilizează În funcţie de sistemul de gestiune a
memorate tipuri comune de date (numeric, bazelor de date, se aleg cele mai potrivite
caracter, tip dată calendaristică). tipuri de date
Controlul sistemului Redă politicile de control economic. Redă controlul pentru validarea datelor de
intrare, obţinerea înregistrărilor, pentru
asigurarea finalizării unui proces, pentru
asigurarea securităţii.
Indiferent de tipul sistemului analizat, manual sau informatizat, o problemă este comună: el
va fi înlocuit de un nou sistem. Oricât de ineficient ar fi, vechiul sistem trebuie să transfere celui
nou o serie de elemente, cum sunt datele folosite, procedurile existente. Deci, sistemul fizic actual
efectuează, în parte sau în întregime, ceea ce-şi propune să facă noul sistem fizic, dar la alt nivel
de performanţă. Tocmai necesitatea trecerii de la vechiul la noul sistem ne obligă să decidem
asupra celor două elemente specificate anterior, date şi proceduri, ceea ce conduce la
obligativitatea constituirii unui model logic al sistemului propus, care să conţină una sau mai
multe DFD, un model de date şi logica proceselor de prelucrare. Problema comună ar consta în
identificarea unei căi de realizare a modelului logic al sistemului propus.
O modalitate ar consta în prezentarea detaliată a sistemului fizic curent, după care să se
încerce conturarea noului model logic, prin abstractizarea celui fizic existent. Se va continua cu
scoaterea în relief a ceea ce trebuie neapărat schimbat din sistemul curent şi ceea ce trebuie să se
realizeze în cel nou. De regulă, se cer mai multe date de cules şi păstrat, precum şi noi
caracteristici ale prelucrărilor: mai complexe, mai rapide, mai sigure. Aşadar, modelul logic
propus poate fi conceput pe baza modelului logic curent. Paşii următori pot fi efectuaţi
parcurgând căi diverse. Ţelul lor este implementarea modelului logic propus pentru a se ajunge la
proiectul noului sistem fizic.
Chiar dacă este o activitate ce solicită timp şi eforturi suplimentare în analiza sistemului,
un argument al utilizării diagramelor fizice şi logice ale sistemului curent constă în faptul că
cele pentru noul sistem sunt mult mai uşor de construit, pentru că este înţeles deja modul lui de
funcţionare, analiştii trebuind să identifice care sunt procesele ce nu mai sunt necesare, pentru
a fi eliminate, şi să adauge noi procese, intrări, ieşiri sau locuri de stocare2. Această manieră de
lucru oferă o modalitate prin care se asigură păstrarea principalelor funcţii şi caracteristici ale
vechiului sistem, efectuându-se o trecere graduală către proiectarea noului sistem. După ce este
construit modelul logic al sistemului nou, acesta poate fi folosit pentru a-l dezvolta pe cel fizic,
aşa cum rezultă din figura 7.1.

Realizarea diagramelor fizice ale sistemului

Diagramele fizice ale curent, pentru inventarierea interfeţelor,
sistemului curent echipamentelor, fişierelor sau bazelor de date
şi a modului lor de exploatare
Diagramele logice ale Construirea diagramelor logice pentru

sistemului curent sistemul curent prin analiza diagramelor fizice
şi identificarea activităţilor economice unice
Diagramele logice ale Crearea diagramelor logice pentru sistemul

sistemului nou nou, prin adăugarea de noi intrări, ieşiri şi
procese solicitate de acesta
Construirea diagramelor fizice, prin analiza

Diagramele fizice ale proceselor din noile diagrame logice, pentru
sistemului nou determinarea interfeţelor–utilizator, a naturii
proceselor (manuale sau automate) şi a fişierelor
sau bazelor de date necesare implementării
noului sistem
Fig. 7.1 Trecerea de la modelele sistemului curent la cele ale noului sistem
Modelarea sistemului curent se impune atunci când se efectuează analiza sistemului
existent şi nu există documentaţie pentru acesta. După modelarea sistemului existent,
diagramele obţinute se vor modifica pentru a fi adaptate la cerinţele noului sistem.
Modelele construite în faza de analiză depind de metodologia utilizată, astfel:
 abordarea structurată apelează la diagramele fluxurilor de date, diagramele entitate-relaţie;
 ingineria programării foloseşte diagrama dependenţelor şi diagrama entitate-relaţie;
 abodarea orientată-obiect se bazează pe diagrama cazurilor de utilizare şi diagrama claselor.
În acest capitol vor fi prezentate numai diagramele specifice metodologiei structurate.
În tabelul 7.2 sunt prezentate diferenţele dintre abordarea structurată şi cea orientată-
obiect, în privinţa modelării sistemului în timpul analizei.
Tabel nr. 7.2 – Diferenţe între metodologia structurată şi orientată-obiect în faza de analiză
Caracteristici Metodologia structurată Metodologia orientată-obiect
Cum este văzut sistemul O colecţie de procese şi date O colecţie de obiecte
Interacţiunile sistemului Procesele interacţionează cu locurile Obiectele interacţionează cu
de stocare şi entităţile externe, prin utilizatorii şi alte obiecte
intermediul fluxurilor de date
Modalităţile de Procesele solicită introducerea Obiectele transmit şi răspund la
interacţiune datelor şi generarea ieşirilor pe baza mesajele primite de la alte obiecte
datelor memorate în locurile de sau de la utilizatori
stocare
Modelele de Diagramele fluxurilor de date Diagrame ale cazurilor de utilizare
reprezentare a sistemului Diagramele entitate relaţie Diagrame ale claselor de obiecte
Engleza structurată
Arbori şi tabele decizionale
Revenind la modelarea din timpul analizei, putem spune că cerinţele sistemului privind
funcţiile (procesele), datele şi comportamentul sistemului sunt modelate apelând la diferite
forme de reprezentare grafică. Astfel, pentru obţinerea viziunii de ansamblu asupra sistemului
se creează modelul descompunerii funcţionale3, după care, pentru detaliere, se construiesc
diagramele fluxurilor de date (DFD), indicând transformarea datelor care intră sau sunt stocate
în sistem pentru obţinerea ieşirilor. Pentru reprezentarea lucrurilor/obiectelor, atributelor şi
3. Nu se va confunda cu metodologia descompunerii funcţionale, ca metodologie incipientă utilizată în dezvoltarea

sistemelor, cu descompunerea funcţională sau descompunerea pe funcţii a sistemelor, care reprezintă o tehnică
folosită pentru simplificarea reprezentării grafice a sistemului.
relaţiilor dintre ele, se folosesc diagramele entitate-relaţie (DER), iar modelarea

comportamentului, a impactului diferitelor evenimente asupra proceselor (ce şi când
declanşează procesele de prelucrare) se face cu ajutorul diagramelor stărilor de tranziţie,
arborilor/tabelelor decizionale etc.
7.2 Descompunerea sistemului pe funcţii de prelucrare

Unul dintre principalele obiective ale analistului de sistem constă în extragerea cerinţelor
din studierea activităţilor curente ale utilizatorilor şi transpunerea lor sub forma procedurilor
din cadrul aplicaţiilor. De exemplu, dacă un utilizator specifică faptul că primeşte facturile de
la furnizori şi le plăteşte 30 de zile mai târziu, el explică activităţile curente specifice primirii şi
plăţii facturilor. Atunci când analistul creează specificaţiile tehnice pentru cerinţele
utilizatorilor, el le formulează astfel încât să poată fi transpuse într-un mediu informatizat. În
aceste condiţii, sistemul trebuie să surprindă, din punct de vedere logic, activităţile fizice
desfăşurate de utilizatori. Soluţiile logice nu permit întotdeauna redarea acestora în acelaşi
mod în care ele se realizează în lumea reală. De aceea, sistemele informaţionale sunt
considerate ca reprezentări logice ale lumii reale. Procesul prin care analiştii modelează
funcţiile unui sistem reprezintă o abstractizare a activităţilor fizice, cunoscută şi sub numele de
echivalenţă logică.
Un pas important în procesul de abstractizare îl constituie descompunerea funcţională,
prin care se identifică principalele componente ale unui sistem (funcţii, procese, proceduri de
prelucrare ş.a.), în urma căreia se obţine o diagramă a descompunerii funcţionale.
Aşa cum am văzut în capitolul 5, la analiza proceselor de prelucrare a datelor, în cadrul
unui sistem se regăsesc tranzacţiile şi transformările, ce vor fi conţinute de diagrama
descompunerii funcţionale.
În cadrul diagramei, sistemul este văzut ca o funcţie pe nivelul cel mai înalt, apelând o
singură dată la simbolul dreptunghi pentru redarea acestuia, după care, pe celelalte niveluri de
descompunere, se foloseşte un alt simbol (dreptunghi cu colţurile rotunjite) de reprezentare a
proceselor, diferit de cel al funcţiei, aşa cum se va vedea în continuare. O altă regulă, care se
va menţine şi în modelul proceselor, o constituie denumirea unică a fiecărui proces.
Descompunerea funcţională este utilă atunci când se doreşte înţelegerea modului în care
este structurat sistemul, permiţând realizarea şi controlul mult mai uşor al modificărilor sau
completărilor la nivelul acestuia.
Diagrama descompunerii funcţionale este similară cu organigrama unei firme, în care
poziţia de pe cel mai înalt nivel o constituie sistemul, văzut ca funcţie de bază, iar nivelurile
inferioare de descompunere sunt procesele din care este alcătuit, aşa cum rezultă şi din fig. 7.2.
În figură s-a reprezentat un sistem pentru care s-au identificat mai multe tranzacţii şi
transformări (funcţiile principale ale sistemului), din care doar două se descompun pe
următorul nivel în procese de prelucrare, iar dintre acestea doar unul se descompune în
proceduri. Nu este o situaţie standard, pentru că toate funcţiile, procesele şi procedurile se pot
descompune pe niveluri inferioare, în funcţie de complexitatea lor. În terminologia construirii
modelului sistemului pentru redarea conceptului de prelucrare, indiferent de nivelul pe care se
situează, se foloseşte noţiunea de proces, cu referire inclusiv la tranzacţii/transformări,
proceduri, module, grupuri de instrucţiuni, pentru că toate urmăresc prelucrarea datelor, aşa
cum s-a văzut în capitolul 5.
Procesele de prelucrare care sunt logic legate sau au loc în acelaşi timp pot fi grupate într-
o funcţie distinctă a sistemului, urmând a fi reflectate separat pe următoarele niveluri de
descompunere. Însă, niciodată nu se vor include într-o singură funcţie sau un singur proces
elemente între care nu există nici o relaţie. Dacă datele nu sunt prelucrate în acelaşi timp sau
au regimuri diferite de prelucrare, este indicat ca procesele să fie separate, chiar dacă
prelucrează date conţinute de un singur flux sau provin de la aceeaşi sursă (loc de stocare sau
entitate externă).
descompunere
Nivel „0” de
prelcurare 4
Tranzactie 4
Tranzactie
Contextul sistemului
descompunere
Nivel „1” de
3.2
Proces 3.2
Proces
prelucrare 3
Tranzactie 3
Tranzactie
3.1
Proces 3.1
Proces
Sistem
Sistem
1.2.3
Procedura 1.2.3
Nivelul „2” de
descompunere
Tranformare 2 2
Tranformare
Procedura
1.3
Proces 1.3
Proces
1.2.2
Procedura 1.2.2
Procedura
1.2
Proces 1.2
Proces
1.2.1
prelucrare 1
Tranzactie 1
Procedura 1.2.1
Tranzactie
Procedura
1.1
Proces 1.1
Proces
Fig. 7.2 Diagramă generalizată a descompunerii funcţionale a unui sistem
Câteva observaţii asupra modelului prezentat în figura 7.2:

 elipsele care delimitează nivelurile de descompunere sunt doar didactice, de
evidenţiere a lor (nu apar în realizarea propriu-zisă a diagramei!);
 denumirile de niveluri, ca şi în cazul elipselor, apar pentru a reliefa doar procesul de
descompunere. Nivelurile se numerotează de la 0 la 9, conform sistemului zecimal.
Astfel, primul nivel, „0”, este nivelul cel mai înalt, care conţine principalele funcţii de
prelucrare ale sistemului. Următorul nivel, „1”, este folosit pentru descompunerea în
procese de prelucrare a unei funcţii ce se află pe nivelul 0 ş.a.m.d.;
 numerotarea pe trepte de cifre (1, 1.1, 1.1.1, 1.1.2 etc., 1.2, 1.2.1, 1.2.2, 2, 2.1, 2.1.1
etc.) redă tocmai secvenţa operaţiunilor de descompunere, conform notaţiei militare.
Aceste comentarii ar trebui reţinute, pentru că nivelurile obţinute prin descompunere vor
fi folosite mai târziu în construirea modelului proceselor cu ajutorul diagramelor fluxurilor de
date, pentru că „scheletul” acestor diagrame se construieşte plecând de la diagrama

descompunerii funcţionale.
Diagrama descompunerii funcţionale poate fi construită apelând la două metode: bottom-
up sau top-down, uneori mixtă. Însă, de cele mai multe ori, se foloseşte metoda top-down.
În cazul bottom-up, analistul trebuie să identifice cele mai de jos proceduri de prelucrare,
pe care să le grupeze apoi, în funcţie de anumite caracteristici comune, în procese, până se
ajunge la clase de tranzacţii/transformări, şi se consideră că sistemul este complet. În acest caz,
diagrama descompunerii funcţionale poate fi obţinută după ce au fost construite DFD-urile.
În cazul top-down, se parcurge sensul invers al acţiunilor, cu alte cuvinte sistemul se
descompune până la cel mai de jos nivel. În acest caz, diagrama descompunerii funcţionale stă
la baza construirii DFD-urilor, adică se va obţine câte o diagramă a fluxurilor de date pentru
fiecare nivel şi ramură de descompunere şi va exista un control mai riguros asupra descrierii
proceselor din cadrul sistemului.
Cazul mixării celor două metode apare atunci când există deja modelul funcţional al
sistemului şi sunt necesare diverse ajustări, prin adăugarea de noi procese sau eliminarea
altora, în funcţie de cerinţele noului sistem.
În identificarea principalelor tranzacţii/transformări, procese, proceduri ale sistemului,
pentru construirea diagramei descompunerii funcţionale, se pleacă de la tabelul evenimentelor,
realizat în timpul studierii sistemului existent şi determinarea cerinţelor.
În caseta 7.1 sunt prezentate tranzacţiile şi procesele sistemului de gestiune a clienţilor,
grupate pe baza asemănărilor existente între diferite evenimente, a interacţiunilor proceselor de
prelucrare cu actorii şi locurile de stocare.
Caseta nr. 7.1 – Tranzacţiile şi procesele sistemului de gestiune a clienţilor la firma ABC
Principalele tranzacţii şi procese de prelucrare identificate pe baza listei activităților/
evenimentelor în cadrul sistemului de gestiune a clienţilor:
Introducere comandă
Verificare existenţă produs
Înregistrare comandă nouă
Actualizare comandă
Generare rapoarte privind comenzile
Onorare comandă
Verificare stare comandă
Înregistrare livrare comandă
Înregistrare produse returnate (defecte, schimbare cerinţe client, returnări totale etc.)
Generare rapoarte privind onorarea comenzilor
Actualizare date clienţi
Înregistrare comandă catalog
Înregistrare clienţi potenţiali
Înregistrare materiale promoţionale
Înregistrare ajustări (corectare erori, modificare limite creditare, perioadă de plată)
Generare rapoarte
Întreţinere date cataloage
Actualizare catalog (modificare date produse, ştergere, introducere produse noi)
Înregistrare promoţii noi
Înregistrare cataloage noi
Generare rapoarte privind cataloagele
Pe baza acestor grupări a evenimentelor în procese de prelucrare se poate construi
diagrama descompunerii funcţionale a sistemului analizat, aşa cum este prezentată în figura
C7.1.
Sistem asistenţă
clienţi
Introducere Onorare comenzi Actualizare Întreţinere

comenzi date clienţi date cataloage
Verificare Înregistrare Generare Inregistrare Înregistrare Înregistrare Înregistrare Generare

existenţă comandă Actualizare rapoarte comanda clienţi materiale rapoarte
produs nouă comenzi catalog potenţiali promoţii ajustări clienţi
comenzi
fluxurilor de date, fiind unul dintre cele mai utilizate.

Verificare Înregistrare Înregistrare Generare Înregistrare Înregistrare Generare
stare produse rapoarte Actualizare pr omoţii cataloage rapoarte
comandă livrare returnate livrări cataloage cataloage
noi noi
Înregistrare Înregistrare Prelucrare Confirmare

date date
clienţi comandă comandă comandă
MODELAREA LOGICĂ, GRAFICĂ, A PROCESELOR DE PRELUCRARE
7.3 Diagramele fluxurilor de date (DFD)

Fig. C7.1 Diagrama descompunerii funcţionale pentru sistemul de gestiune clienţi
133
dovedit a fi deosebit de valoros pentru modelarea proceselor, îl reprezintă diagramele

Metodologia structurată a dezvoltării sistemelor informaţionale descrie activităţile ca
procese care sunt realizate manual sau cu ajutorul calculatorului. Un model grafic, ce s-a
Într-o definiţie restrânsă, DFD-urile sunt o metodă de prezentare grafică a traseului logic
pe care îl parcurg datele prin diverse procese până sunt transformate în ieşiri, redând toate
componentele logice ale unui sistem într-o singură reprezentare grafică, respectiv intrările,
ieşirile, prelucrările şi locurile de stocare, precum şi graniţele sistemului4.
Indiferent de metodologiile folosite în realizarea unui sistem/aplicaţie, toate apelează la
operaţiunea de modelare logică a prelucrărilor sub formă de diagrame, diferenţele constând
doar în folosirea mai pronunţată a diagramelor pentru descrierea sistemului, încadrându-le în
diagrame de context, diagrame ale fluxurilor de date fizice şi diagrame ale fluxurilor de date
logice. Altele apelează la combinaţii de diagrame, tabele şi forme descriptive.
Diagrama de context scoate în relief aria de întindere a sistemului analizat, prin
specificarea elementelor din interiorul organizaţiei şi a celor externe, sub denumirea de
entităţi externe, însemnând entităţi externe sistemului analizat.
Diagrama fluxurilor de date ale sistemului fizic curent specifică persoanele şi
tehnologiile folosite pentru fiecare proces de transfer şi transformare a datelor, acceptându-se
unele intrări şi descriindu-se ieşirile din procesele menţionate.
Diagrama fluxurilor de date ale sistemului logic curent, independentă de tehnologie,
reliefează funcţiile de prelucrare a datelor executate de către sistemul informaţional curent.
Diagrama fluxurilor de date ale sistemului logic nou va prezenta circuitul datelor,
structura lor şi cerinţele funcţionale ale noului sistem.
Descrieri ale obiectelor DFD se regăsesc în aşa-zisele dicţionare ale proiectelor sau
depozite CASE (repository), ce reprezintă depozitul de date despre ... datele, obiectele şi
procesele diagramelor, pe scurt depozitul de metadate.
În literatura de specialitate, toate se regăsesc sub denumirea generică de diagrame ale
fluxurilor de date şi, ca atare, sub această semnificaţie, le tratăm şi noi în continuare.
Se cuvine o remarcă: întrucât diagramele fluxurilor de date (DFD) au ca obiectiv
urmărirea modului de transfer al datelor între procesele de prelucrare, astfel de diagrame se
mai numesc şi modele ale proceselor de prelucrare, iar operaţiunea se numeşte modelarea
proceselor.
Tehnica de redare a proceselor de prelucrare prin intermediul diagramelor fluxurilor de
date a căpătat noi accepţiuni prin încorporarea ei în instrumentele de analiză şi proiectare cu
ajutorul calculatorului, adică în produsele CASE, deşi în acelaşi timp putem vorbi şi de o
anumită complicare a problemei.
Cu ajutorul diagramelor fluxurilor de date se pot stabili graniţele unui sistem apelând doar
la patru simboluri:
 locul în care se vor duce informaţiile sau de unde vin ele, văzut ca alt sistem sau altă
persoană care interacţionează cu sistemul;
 locul în care sunt păstrate/memorate datele care circulă în sistem;
 fluxul de date;
 procesul care asigură transformarea datelor.
Aşa cum se va vedea mai târziu, primele două simboluri sugerează sursa, respectiv
destinaţia datelor la un moment dat. DFD-urile pot fi folosite în locul unei descrieri narative a
sistemului, ce vine în sprijinul analiştilor în timpul dialogului cu utilizatorii. Acest lucru se
datorează faptului că analiştii sunt confruntaţi de multe ori, în timpul întâlnirilor cu utilizatorii,
cu problema explicării modului de funcţionare a sistemului, când utilizatorii sunt puşi în
situaţia de a accepta sau refuza soluţiile propuse pentru dezvoltarea unui sistem şi nu pot da un
răspuns pentru că nu reuşesc să înţeleagă specificaţiile prea ample şi complex formulate. Din
4. Kendall, K.E., Kendall, J.E. – op. cit., p. 241; McLeod Jr., R., Jordan, L. – Systems Development. A Project
Management Approach, John Wiley & Sons, Inc., New York, 2002, p. 94; Oprea, D. – Premisele şi consecinţele
informatizării contabilităţii, Ed. Graphix, Iaşi, 1995, p. 179; Romney, M.B., Steinbart, P.J. – Accounting
Information Systems, 9th Edition, Prentice Hall, Upper Saddle River, New Jersey, 2003, p. 156; Satzinger, J.W.,
Jackson, R.B., Burd, S.D. – op. cit., p. 195.
experienţă, s-a constat că oamenii reuşesc să-şi amintească 100% din imaginile văzute, dar
numai 50% dintr-un text. De aceea, reprezentarea grafică a unui sistem poate oferi utilizatorilor
o modalitate mai simplă de a-l înţelege, precum şi modul în care el le va rezolva problemele.
DFD-urile pot fi utilizate pentru reprezentarea unui sistem sau a unui software la orice
nivel de abstractizare. Propriu-zis, DFD-urile pot fi descompuse pe niveluri ce indică o creştere
a detalierii fluxurilor de date şi a prelucrărilor. De aceea, DFD-urile oferă un mecanism pentru
modelarea atât a fluxurilor de date, cât şi a proceselor, aşa cum rezultă din figura 7.3.
Enitate externa 1
Date-de-intrare-1
Entitate externa 2
Date-
Tranzactie 1 intermediare -1
prelucrare 1
3 Date-de-ieşire-1
Tranzactie 3
prelucrare 3
Date- Date-
intermediare -2 intermediare -3
-
2 3
Date- 4
Date-
Transformare 2 memorare
pentru-
memorare
Tranzactie 4
prelucrare 4
Date-de-
intrare-2 Loc de stocare date
Date-de-ieşire-2
Entitate externa 3
Enitate externa 1
Fig. 7.3 Model al fluxului informaţional şi al prelucrărilor
În figura anterioară, pătratul folosit redă o entitate externă, adică o persoană, o aplicaţie
sau alt sistem care produce informaţii pentru a fi supuse transformărilor sau primeşte
informaţii generate de sistem. Cercul reprezintă un proces sau o transformare aplicat(ă)
datelor, prin care datele sunt modificate. Linia cu săgeată reprezintă una sau mai multe
structuri de date, indicând modul în care circulă datele în sistem. Cele două linii paralele
înseamnă un loc de stocare a datelor, prin care informaţiile sunt păstrate pentru a fi folosite de
către procesele sistemului.
Simplitatea simbolurilor folosite pentru construirea DFD-urilor reprezintă un alt motiv
pentru care sunt folosite în modelarea şi descrierea sistemului. Însă, trebuie remarcat faptul că
nu există indicaţii explicite asupra secvenţei prelucrărilor sau a condiţiilor logice de execuţie a
acestora. Procedura sau secvenţa procedurilor este considerată implicită în cadrul DFD-urilor,
iar explicaţiile detaliate sunt lăsate pentru etapa de proiectare. De aceea, se consideră că DFD
prezintă, sub formă grafică, activităţile sistemului, ca răspuns la apariţia unui eveniment.
De exemplu, în cazul sistemului de gestiune a clienţilor, evenimentul este Clientul doreşte

verificarea disponibilităţii unui produs, declanşatorul constă în Cerere informaţii despre
produse, sursa datelor o reprezintă Clientul, răspunsul sistemului la eveniment constă în
Informaţii detaliate privind produsul, iar destinaţia este reprezentată tot de Client.
De asemenea, DFD-urile reprezintă primul pas către realizarea schiţei de proiectare a
sistemului, semnificând transpunerea sub formă grafică a cerinţelor utilizatorilor.
Aşa cum am prezentat anterior, tehnica diagramelor fluxurilor de date apelează la patru
simboluri de bază pentru a reprezenta sistemele informaţionale logice, înlocuind „clasicele”
scheme logice. Se consideră, totuşi, că schemele logice de sistem, prin care se redă configuraţia
fizică a sistemului informatic, sunt mai sugestive decât o diagramă; însă, pentru toate celelalte
cazuri, diagramele sunt net superioare, îndeosebi pentru reprezentarea logicii sistemelor
informaţionale. Dar şi schemele de sistem atrag anumite critici întrucât, prin apelarea în faza
proiectării logice la unele simboluri speciale pentru discuri, CD-uri ş.a., se preiau unele
caracteristici specifice proiectării fizice (doar în această etapă trebuie să se specifice concret
echipamentele viitoare şi suporturile).
Revenim asupra principiului de bază al analizei: trebuie să scoată în evidenţă Ce face
sistemul şi nu Cum. De aceea, prin intermediul diagramelor fluxurilor de date, se scoate în
evidenţă logica sistemului şi operaţiunile care se efectuează asupra datelor, fără să se acorde
atenţie detaliilor fizice specifice proiectării.
De aici trebuie reţinut că procesele de prelucrare, schimbul de date şi memorarea lor sunt
aspectele importante de care trebuie să se ţină cont în modelarea sistemului şi nu modul în care
sunt transpuse din punct de vedere fizic, cum ar fi un fişier indexat păstrat pe un CD, o
interfaţă grafică etc.
7.3.1 Construirea diagramelor fluxurilor de date

De cele mai multe ori, construirea diagramelor fluxurilor de date pleacă de la
descompunerea funcţională a sistemului, în care a fost identificată structura din care este
alcătuit, respectiv funcţiile, procesele, procedurile de prelucrare.
Nu există o modalitate ideală de construire a DFD, datorită diferitelor probleme care apar
la nivelul sistemului şi a particularităţilor de abordare a acestora. Totuşi, există o serie de
recomandări, redate în tabelul 7.3.
Tabel nr. 7.3 – Recomandări privind construirea DFD
Nr. Recomandare Explicaţii
crt.
1. Înţelegerea sistemului Se pleacă de la tabelul evenimentelor, pentru a înţelege ce urmează să
prelucreze sistemul, declanşatorii, sursa şi destinaţia datelor şi
informaţiilor. Evenimentele şi modul lor de grupare în procese ale
sistemului ar trebui să fie deja identificate, prin diagrama descompunerii
funcţionale.
2. Ignorarea anumitor Scopul DFD este de a reprezenta grafic sursa datelor, fluxurile de
aspecte ale sistemului intrare, prelucrările, locurile de stocare, fluxurile de ieşire şi destinaţia
informaţiilor. De aceea, toate procesele de control al securităţii şi
acţiunile specifice ar putea fi ignorate, în această primă fază, şi doar
elementele de verificare a erorilor şi de validare a datelor să fie
reprezentate.
3. Stabilirea graniţelor Trebuie să se stabilească ce va fi inclus sau exclus din sistem, în sensul
sistemului că trebuie să se identifice care sunt datele elementare ce intră sub
incidenţa prelucrărilor sistemului, astfel încât să fie incluse în DFD
numai acele elemente strict necesare pentru a fi luate în considerare în
timpul proiectării. Când există dubii asupra unor elemente care par a fi
importante pentru sistem, este bine să fie încorporate în DFD, până se ia

crt.
decizia eliminării sau păstrării lor, eventual după discuţii suplimentare
cu utilizatorii.
4. Crearea diagramei de Sunt reprezentate entităţile externe şi fluxurile de date care intră/ies
context în/din sistem, fără a prezenta funcţiile, procesele şi locurile de stocare.
Se pleacă de la principalele elemente stabilite a fi incluse în sistem, prin
identificarea entităţilor externe, a principalelor fluxuri de date prin
intermediul cărora sistemul interacţionează cu mediul său extern.
5. Identificarea fluxurilor După construirea diagramei de context, alături de fluxurile ce fac
de date interne legătura cu mediul extern sistemului, trebuie să se identifice şi cele care
sistemului circulă în interiorul sistemului, respectiv cele care trec printr-un proces
de prelucrare, pentru a ajunge într-un loc de stocare sau în alt proces,
precum şi cele care sunt citite dintr-un loc de stocare pentru a fi supuse
prelucrărilor. Se vor identifica elementele care iniţiază procesul: ce intră
în proces? E de preferat ca tot ce intră în proces să fie plasat la stânga
lui, pentru că, mai târziu, în timpul îmbunătăţirii modelului, este foarte
uşor să se concentreze atenţia spre intrări numai prin simpla lor
localizare. De asemenea, se determină ieşirile fiecărui proces sau a ceea
ce ar trebui să se obţină şi plasarea lor la dreapta procesului.
6. Gruparea fluxurilor de Un flux constă din una sau mai multe structuri de date. Datele
date elementare care circulă împreună ar putea să fie grupate şi reprezentate
într-un singur flux până la separarea lor, în momentul descompunerii pe
mai multe niveluri de detaliere a sistemului. Dacă datele elementare nu
circulă împreună, ar trebui reprezentate prin fluxuri distincte.
7. Identificarea Plecând de la diagrama descompunerii funcţionale, se identifică pe
proceselor de nivelul 0 funcţiile prin care unul sau mai multe fluxuri de date intră
prelucrare în/din care pentru a fi supuse prelucrărilor în vederea obţinerii ieşirilor. Toate
intră/ies fluxurile de funcţiile trebuie să aibă unul sau mai multe fluxuri de intrare şi ieşire. În
date plus, este momentul în care se stabilesc cu exactitate fluxurile ce fac
legătura între procese sau locuri de stocare sau aşa-numitele fluxuri
interne sau intermediare ale sistemului.
8. Stabilirea locurilor de Fiecare flux care circulă în sistem are ca sursă sau destinaţie locurile de
stocare a datelor stocare unde ar trebui să fie înregistrate sau de unde pot fi extrase. Este
momentul când se stabilesc exact fişierele, formularele sau alte
componente de care procesul are nevoie pentru realizarea completă a
transformărilor pe care le presupune. Aceste componente sunt, de
obicei, locuri de stocare a datelor apelate în timpul prelucrărilor, fiind
plasate deasupra sau sub proces.
9. Denumirea tuturor Cu excepţia fluxurilor de date care intră/ies în/din locurile de stocare,
elementelor din DFD celelalte fluxuri de date ar trebui să aibă nume unice şi descriptive
pentru a surprinde cât mai bine structurile pe care le reprezintă, făcând
mult mai uşoară citirea şi înţelegerea DFD. Prin stabilirea numelor
pentru fluxurile de date, analiştii sunt forţaţi să-şi concentreze atenţia
asupra tuturor fluxurilor de date importante pentru sistem şi mai puţin
asupra proceselor şi locurilor de stocare. Din momentul în care fluxurile
au fost etichetate, denumirea proceselor şi locurilor de stocare se
realizează relativ uşor, pentru că, de multe ori, preiau cuvintele cheie ale
fluxurilor de intrare şi ieşire. De asemenea, numele locurilor de stocare
este dat pentru a sugera datele memorate. În privinţa proceselor, se
recomandă ataşarea unui nume şi număr plecând de la rezultatele pe
care le oferă. De exemplu, dacă un proces conduce la obţinerea
facturilor, el poate fi etichetat cu denumirea „Crearea facturilor”. Dacă
procesul presupune mai mult de un singur eveniment, el poate fi
denumit folosind conjuncţia „şi”, ceea ce va permite să se determine
dacă procesul este o procedură primitivă (ce nu mai necesită

crt.
descompunere) sau poate fi descompus mai departe. De asemenea,
numele procesului ar trebui să fie cât mai apropiat de ceea ce utilizatorul
face în activitatea sa curentă. Numărul ataşat procesului permite
analistului să-l identifice în cadrul sistemului şi, ce e mai important, să
stabilească legătura cu nivelurile superioare sau inferioare identificate în
timpul descompunerii funcţionale.
10. Descompunerea DFD O diagramă de nivel 0 este dificil de citit şi înţeles. Dacă există mai mult
de 5-7 procese pe o singură pagină de diagramă este mai bine să se
apeleze la reprezentarea sistemului pe trepte de descompunere, aşa cum
sunt redate în diagrama descompunerii funcţionale. Astfel, diagrama de
context este descompusă în principalele funcţii ale sistemului,
obţinându-se diagrama de nivel 0, după care fiecare funcţie este
„explodată” succesiv în procese de nivel inferior, creându-se aşa-
numitele diagrame-copil.
11. Verificarea Construirea diagramelor presupune respectarea mai multor reguli, ce vor
diagramelor pentru fi descrise mai târziu, ceea ce înseamnă că la finalizarea fiecărei
depistarea erorilor diagrame trebuie să se verifice dacă au fost respectate, iar, în cazul
apariţiei erorilor, trebuie corectate, pentru a nu fi propagate în
următoarele diagrame sau în specificaţiile de proiectare. De asemenea,
se va urmări dacă numele atribuite fluxurilor de date şi proceselor sunt
relevante pentru a evidenţia cât mai exact ceea ce se întâmplă în sistem.
12. Reluarea procesului de Analiştii sunt nevoiţi să lucreze mai mult timp cu fluxurile de date, pe
construire a DFD măsura evaluării diagramelor, împreună cu utilizatorii. Fiecare reluare a
DFD înseamnă rafinarea lor şi identificarea elementelor care au fost
omise sau eliminarea celor care nu prezintă importanţă sau nu constituie
scopul sistemului.
13. Pregătirea formei Se va realiza o copie finală a fiecărei DFD astfel încât să poată fi
finale folosită ca parte distinctă în documentaţia sistemului. Fiecare pagină de
diagramă trebuie să aibă un nume, plecând chiar de la numele procesului
de pe nivelul superior din care s-a obţinut prin descompunere.
Recomandările din tabel nu reprezintă paşi succesivi ce trebuie parcurşi pentru construirea
DFD-urilor, pentru că unii dintre ei se pot desfăşura paralel (de exemplu, identificarea
elementelor din diagramă şi denumirea lor), altele se reiau în funcţie de necesităţile de
moment. Detalii privind aceste recomandări şi modul efectiv de construire a diagramelor vor fi
prezentate în paragrafele ce urmează.
7.3.2 Simboluri utilizate în construirea DFD
În practică, cele mai multe produse CASE apelează la două tehnici de redare a
diagramelor fluxurilor de date: Gane & Sarson5 şi Yourdon6 & DeMarco7. Firesc, numele lor
sunt combinaţii ale numelor realizatorilor acestora. Din prezentările ulterioare sperăm să
atenuăm teama de diversitate. Tehnicile sunt foarte asemănătoare, iar diferenţele le vom puncta
la momentul potrivit.
7.3.2.1 Entităţile externe (EE)
Entităţile externe mai poartă numele şi de sursă/destinaţie sau agenţi externi, fiind
locurile de unde intră sau către care ies documente, liste, situaţii, informaţii. Entităţile externe
5. Gane, C., Sarson, T. – Structured Systems Analysis: Tools and Techniques, Prentice Hall, Englewood Cliffs, New
Jersey, 1979.
6. Yourdon, E., Constantine, L.L. – Structured Design, Prentice Hall, Englewood Cliffs, New Jersey, 1979.
7. DeMarco, T. – Structured Analysis and Design Specification, Prentice Hall, Englewood Cliffs, New Jersey, 1979.
sunt reprezentări fizice ale grupurilor de persoane, cum sunt clienţii, furnizorii sau ale altor
sisteme, ca de exemplu Gestiunea stocurilor, Salarizare. Uneori, o entitate externă poate fi o
singură persoană (contabil-şef, preşedinte etc.).
Legăturile care se realizează între procesele de prelucrare şi entităţile externe, prin
intermediul fluxurilor de date (interfeţele sistemului cu mediul extern), au ca suport circuitul
unor astfel de documente în cadrul organizaţiei, purtând de multe ori şi denumirea de fluxuri
externe sau fluxuri finale, pentru că ele vin din afara sistemului (fluxurile de intrare, provenite
de la entităţi) sau nu rămân în interiorul sistemului (fluxurile de ieşire, care au ca destinaţie
entităţile externe). O entitate poate fi, la un moment dat, dar nu în același timp, atât sursă, cât şi
destinaţie.
Enităţile sunt considerate externe sistemului pentru că nu intră în aria de modelare a
acestuia, adică a proceselor de prelucrare prin care entităţile pun la dispoziţia sistemului
fluxurile de intrare sau prin care preiau fluxurile de ieşire.
Simbolurile convenţionale folosite de cele două tehnici sunt redate mai jos:
Gane & Sarson Yourdon & DeMarco
Pătrat îngroşat Pătrat simplu
Fiecare entitate va avea un nume corespunzător, marcat printr-un substantiv, pentru a reda
cât mai bine ceea ce reprezintă pentru sistem. Aceeaşi entitate poate fi folosită ori de câte ori
este nevoie de ea în cadrul unei DFD, pentru a se evita încrucişarea fluxurilor de date.
7.3.2.2 Fluxuri de date
Fluxurile de date, redate printr-o linie cu o săgeata la unul din capete (reprezentând
destinaţia datelor), sunt utilizate cu scopul de a sugera o cale pe care se pot suprapune una sau
mai multe structuri de date, în momente nespecificate, care intră în procesele de prelucrare sau
sunt rezultatul lor. Momentul prelucrării datelor unui proces poate fi specificat prin descrierea
procesului respectiv în depozitul metadatelor.
De regulă, fiecare flux de date primeşte un nume sugestiv, care descrie numai o structură
de date, reprezentând un document, un raport, date citite sau scrise dintr-un/într-un loc de
stocare, precum şi date care sunt transmise între procese cu prelucrări on-line. De aceea,
denumirea fluxurilor începe cu un substantiv care să redea cât mai bine faptul că se preia sau
se transmite o structură de date necesară:
 unui proces, când trebuie să fie supusă prelucrărilor şi este preluată de la o entitate
externă sau este rezultatul citirii unor înregistrări anterioare dintr-un loc de stocare;
 unei entităţi externe, când este rezultatul unui proces de prelucrare şi este cerută de o
persoană, un alt sistem, o aplicaţie, un birou etc.;
 unui loc de stocare, când, în urma prelucrărilor, pe baza ei se adaugă noi înregistrări, se
modifică sau se şterg înregistrările anterioare.
În anumite situaţii se impune însă prezentarea câtorva structuri de date pe o singură
săgeată (flux), după cum rezultă din figura 7.4 (fluxul Istoric-incasari-si-Facturi-emise).
Incasare
Date-
incasare-
client
Limita- 1
Istoric-inacasari-si-
creditare Facturi-emise
Clienti Inregistrare
Verificare limita comanda noua
creditare
Date-facturi-
client Date-comanda
Facturi emise Comenzi
Fig. 7.4 Structuri multiple de date pe un singur flux
O astfel de situaţie apare atunci când dintr-un proces de prelucrare rezultă două structuri
de date care trebuie să ajungă simultan într-un alt proces de prelucrare sau la o entitate externă.
Un caz asemănător se întâlneşte atunci când într-un proces de prelucrare intră în acelaşi timp,
de la aceeaşi sursă, fluxuri diferite ca structură (de exemplu, de la depozit vin documentele
privind mişcările de materiale dintr-o perioadă de timp, care au structuri de date diferite, dar
sunt necesare toate pentru actualizarea stocului de materiale). Însă, trebuie să se determine
dacă acestea circulă întotdeauna împreună, altfel fiind necesară reprezentarea lor diferită,
pentru că e posibil ca documente distincte să fie ascunse interpretărilor şi analizei, făcând mai
dificilă înţelegerea diagramelor.
Structurile multiple de date se pot descompune, la un moment dat, pe nivelurile inferioare
ale DFD, pentru a evidenţia că fiecare intră sau iese într-o/ dintr-o altă procedură de prelucrare.
Se mai întâlneşte o situaţie aparte, atunci când se doreşte redarea unei ramificaţii a
aceleiaşi structuri de date, ceea ce înseamnă că un flux se poate descompune, la cerere, având o
singură origine şi multiple destinaţii, aşa cum ilustrează şi exemplul din fig. 7.5.
1
Client
Factura-vanzare
Emitere factura
Facturi emise
Fig. 7.5 Flux de date cu o singură origine şi cu mai multe destinaţii
Trebuie reţinut că prin fluxurile de date nu se redau circuitele bunurilor fizice, ci numai
datele care reflectă aceste circuite. De exemplu, este incorect să se includă într-o diagramă
fluxul „Produse livrate” sau „Bani încasaţi”. Fluxurile corect denumite şi care ar trebui
reflectate sunt „Documente/date privind livrarea produselor”, respectiv „Documente/date
privind încasarea”.
Aşa cum s-a menţionat şi la descrierea entităţilor externe, fluxurile de date se pot încadra
în două categorii:
 externe, care provin de la entităţile externe şi sunt supuse proceselor de prelucrare,
respectiv cele care sunt rezultatul unui proces de prelucrare şi au ca destinaţie entităţile
externe;
 interne sau intermediare, cu referire la fluxurile care circulă între două procese de
prelucrare sau între un proces şi un loc de stocare. Sunt considerate interne pentru că
ele provin din interiorul sistemului (un proces de prelucrare sau un loc de stocare),
respectiv nu părăsesc sistemul (merg într-un alt proces de prelucrare sau într-un loc de
stocare). Atunci când un proces are nevoie de informații dintr-un loc de stocare pentru
a face o prelucrare (de exemplu, pentru stabilirea limitei de creditare a unui client
presupune citirea datelor din tabela clienti) înseamnă că în proces intră un flux intern.
Dacă în urma prelucrării unor date rezultatul trebuie să asigure adăugarea, modificarea
sau actualizarea unei înregistrări într-un loc de stocare, înseamnă că din proces se
obține un flux intern de ieșire.
Cei care modelează sistemul, prin intermediul diagramelor fluxurilor de date, trebuie să
ţină cont de faptul că orice flux trebuie să treacă printr-un proces de prelucrare, fie că intră în
el pentru a fi prelucrat, fie că este rezultatul prelucrării.
În privinţa simbolisticii folosite de cele două tehnici, nu există diferenţe.
7.3.2.3 Locuri de stocare a datelor
Locul de stocare a datelor reprezintă o „magazie” pentru datele care sunt înregistrate
temporar sau permanent în cadrul sistemului, adică cele care se păstrează în sistem pentru
utilizări viitoare. Ca şi în cazul fluxurilor de date, locurile de stocare nu urmăresc redarea unui
format fizic de păstrare a datelor, ci reprezintă locaţii sau metode prin care datele sunt păstrate
în sistem. Un loc de păstrare poate fi un fişier, un director, o tabelă a unei baze de date, o bază
de date, un dosar, un registru, o înregistrare din agenda unei persoane, căsuţa de e-mailuri a
unei persoane. Locurile de stocare pot conţine date despre clienţi, stocuri, comenzi, facturi
primite, facturi emise, state de salarii, plăţi, încasări etc. Direcţia fluxurilor de date către sau de
la locul de stocare indică faptul că datele sunt scrise sau citite în/din acel loc de stocare. În
plus, orice ştergere sau modificare a unei înregistrări dintr-o bază de date este reprezentată tot
ca un flux de date, în sensul că o astfel de operaţiune cere ca datele să fie citite înainte de a fi
şterse sau modificate. Ca urmare, stocarea datelor se referă atât la fişierele sistemelor de
prelucrare manuală, cât şi la cele create în medii informatizate, inclusiv una sau mai multe
tabele ale bazelor de date.
Simbolurile utilizate de cele două tehnici sunt:
Dreptunghi neînchis la dreapta Linii paralele
În varianta Gane & Sarson, locurile de stocare au câte un identificator unic, prezentat sub
formă generală Dnn, cum ar fi D1, D7. Când se intenţionează redarea cu claritate a operaţiunii
de stocare, simbolul ce poartă acelaşi identificator (Dnn) poate fi multiplicat. În acest sens, la
stânga dreptunghiului alungit se plasează un triunghi care va purta acelaşi număr. El reprezintă
numărul de apariţii ale aceluiaşi simbol.
Exemplu:
D1 CLIENTI D1 CLIENTI
3 3
D1 CLIENTI
3
Prezenţa într-o diagramă a fluxului de date a unui loc de stocare, care are o singură intrare
şi o singură ieşire, conduce la o examinare mai atentă, pentru a se trage concluzia dacă acel
loc, din punct de vedere economic, este logic necesar. S-ar putea ca prezenţa lui să sugereze un
fişier fizic temporar, utilizat ca mediu de comunicare a datelor.
De exemplu, dacă anumite date se salvează pe un anumit suport doar pentru a fi
transportate de la o filială la sediul firmei, operaţiunea nu este logic necesară, cât timp datele
pot fi transferate şi telefonic. Deci, scopul creării fişierului este acela de a ajuta la operaţiunea
de transfer date. Pe de altă parte, dacă pe acelaşi suport s-ar păstra datele despre clienţii rău
platnici pentru a fi prezentaţi responsabilului cu vânzările, peste câteva zile, operaţiunea este
logic necesară, chiar dacă ea are doar o intrare şi o ieşire (fig. 7.6 şi 7.7).
1 2
Comanda-noua
Cont de client valid
Verificare client Validare client
Date-
client
Date-
client
Clienti incerti
Fig. 7.6 Exemplu de loc de stocare temporar
Clienti
Date-
sold
1 2
Cont-de-client-
Comanda-noua Date-client valid
Verificare client Validare client
Fig. 7.7 Exemplu de loc de stocare logic necesar
7.3.2.4 Procese de prelucrare

Un proces de prelucrare este o funcţie exercitată cu scopul transformării datelor, utilizarea
lor pentru crearea unor noi date sau pentru reunirea mai multor date în vederea obţinerii unor
informaţii, sub forma rapoartelor, documentelor, situaţiilor etc. De aceea, se recomandă ca
fluxurile de date care părăsesc procesul să fie întotdeauna etichetate diferit faţă de cele care
intră în proces, chiar dacă ele redau, într-o anumită măsură, aceeaşi structură de date, ele
nefiind, totuşi, identice, pentru că au suferit modificări.
Atunci când se modelează un proces, din punct de vedere logic, nu are importanţă dacă el
este executat de un calculator, un alt echipament sau de către o persoană. Procesele sunt
organizate în cadrul diagramelor fluxurilor de date într-o secvenţă corespunzătoare ordinii lor
de execuţie. Aşa cum s-a discutat la descompunerea funcţională, un proces poate fi descompus
în componente pentru a se scoate în evidenţă cât mai multe detalii privind prelucrarea datelor.
Procesele de prelucrare care se răsfrâng asupra fluxurilor de date pot fi grupate în patru
categorii:
1. crearea unui set nou al fluxurilor de date, pe baza celor de intrare. Fluxurile noi de date
reprezintă o ieşire a procesului şi intrare în alt proces, înregistrare într-un loc de stocare
sau ieşire către o entitate externă. Un exemplu al unui astfel de tip de proces îl constituie
intrarea informaţiilor privind salariile angajaţilor (tarif/oră, sporuri etc.) într-un proces prin
care se creează statul de plată a salariilor;
2. citirea unor informaţii din fluxul de intrare, fără modificarea lui, informaţii ce vor fi
folosite pentru obţinerea unei ieşiri. O situaţie des întâlnită o constituie verificarea codului
unui client din înregistrările anterioare, pentru a determina dacă este un client vechi sau nu.
Aceasta înseamnă o prelucrare la nivelul înregistrărilor dintr-un loc de stocare, în sensul că

în proces va intra codul clientului de pe un document (ca flux de intrare), din care va
rezulta tot codul clientului care se duce în locul de stocare;
3. reorganizarea datelor de intrare, cum ar fi sortarea datelor, reformatarea sau filtrarea
lor. De exemplu, obţinerea unei liste a salariaţilor în ordine alfabetică pe baza datelor
preluate dintr-un fişier al salariaţilor, în care ordonarea a fost făcută după marcă;
4. preluarea datelor şi transferarea unora dintre ele către alt proces de prelucrare. Un
exemplu de astfel de proces constă în preluarea preţului produselor prin intermediul POS-
ului şi transmiterea lor în procesul de calcul al valorii facturii.
Într-o formă generalizată, denumirea proceselor se face sub forma verb (substantiv verbal)
+ descrierea funcţiei (rolului) procesului, fără însă a oferi prea multe detalii. De exemplu, este
improprie următoare denumire de proces: „Verificarea contului pentru determinarea limitei de
creditare şi stabilirea situaţiei contului clientului”. Un nume corect de proces ar putea fi:
„Verificarea clientului”. Astfel, se pot utiliza următoarele formate de atribuire a numelor de
procese:
 denumirea procesului cu numele sistemului, atunci când se face referire la procesul de pe
cel mai înalt nivel de descompunere (diagrama de context), cum ar fi sistemul de gestiune a
stocurilor, sistemul de gestiune a clienţilor, sistemul de aprovizionare etc.
 specificarea subsistemelor din care este format sistemul, apelând la denumiri de forma:
subsistem de generare rapoarte, subsistem de prelucrare comenzi, subsistem lansare
comenzi aprovizionare sau, mai simplu, generare rapoarte, prelucrare comenzi etc. Printr-o
astfel de formulare se pot reda principalele funcţii de prelucrare, aflate pe nivelul 0 de
descompunere;
 utilizarea formei generale verb+descrierea funcţiei pentru reprezentarea proceselor aflate pe
nivelurile detaliate de descompunere a sistemului. Verbul descrie tipul prelucrării pe care îl
execută, de genul Calculare, Verificare, Pregătire, Tipărire, Adăugare etc. Descrierea
funcţiei ilustrează ieşirea specifică procesului, cum ar fi: stoc, comandă, raport, înregistrare.
Câteva exemple complete de nume ale proceselor aflate pe niveluri inferioare ale
sistemului: Calculare TVA vânzări, Verificare client, Pregătire factură livrare, Tipărire
raport comenzi aprovizionare, Transmitere confirmare de acceptare a comenzii, Verificare
sold client, Adăugare înregistrare stoc etc.
Un proces trebuie să aibă, aşa cum am văzut deja, un număr unic de identificare, prin care
se indică poziţia sa în cadrul nivelurilor de descompunere.
Simbolurile folosite pentru redarea proceselor de prelucrare sunt:
Dreptunghi cu colţuri rotunjite Cerc
Ca regulă generală, se recomandă ca erorile sau excepţiile să nu fie tratate în diagrama

fluxului de date, mai ales în cele foarte ample. Obiectivul diagramei fluxului de date este de a
scoate în relief fluxul normal al datelor, iar erorile şi excepţiile pot fi descrise ulterior.
7.3.2.5 Descrierea legăturii dintre procesele de prelucrare şi locurile de stocare
Un loc deosebit de important în cadrul sistemului îl reprezintă datele ce sunt păstrate
pentru a asigura prelucrări ulterioare şi pentru generarea ieşirilor, elemente ce vor avea o
pondere semnificativă în activităţile etapei de proiectare şi implementare. În timpul analizei se
foloseşte un model distinct pentru reprezentarea modului în care datele sunt memorate şi
utilizate în/din locurile de stocare, respectiv matricea procese-date sau matricea CRUD
(Create, Read, Update, Delete), de la iniţialele folosite pentru redarea acestor operaţiuni.
Modelul va fi folosit în timpul modelării conceptuale a datelor, fiind punctul de plecare în

identificarea principalelor entităţi de date din diagramele entitate-relaţie, dar şi în timpul
proiectării fizice, când se structurează modulele programelor, plecând de la operaţiunile care
trebuie să fie executate asupra datelor păstrate în sistem.
O astfel de matrice, pentru sistemul de gestiune a clienţilor de la firma ABC, este
prezentată în caseta 7.2.
Caseta nr. 7.2 – Matricea legăturilor dintre locurile de stocare
şi procesele de prelucrare din sistemul de gestiune a clienţilor
Livrari
CRUD
CRU
RU
C
R
R
R
returnate
Tranzactii Pachet Nomenclator Produse
C
R
comandate comanda promotii produse
R
R
R
R
R
R
R
CRU
RU
R
R
R
Locuri de stocare
CRUD
RUD
C
R
Produse
RUD
RU
RU
C
R
R
Catalog Client Stoc Comanda
RU RUD
RU
CRU RU C
R
R
R
R
R
R
R
R
CRUD
CRU
RU
RU
R
R
R
RU
Inregistrare comanda catalog R
Inregistrare materiale promotii R
R
C
R
Inregistrare produse returnate
Inregistrare clienti potentiali
Generare rapoarte cataloage

Generare rapoarte comenzi
Verificare existenta produs
Inregistrare comanda noua
Verificare stare comanda
Generare rapoarte livrari
Generare rapoarte clienti
Inregistrare promotii noi

Inregistrare catalog nou
Inregistrare back order
Inregistrare ajustari
Actualizare comenzi
Inregistrare livrare
Procese
Actualizare catalog
Câteva exemple de citire a matricei:

 procesul Verificare existenţă produs efectuează o Citire (Read) de date din fişierul
Stoc, pe baza comenzii primite de la client şi a produselor solicitate, pentru a identifica
dacă produsele cerute sunt sau nu în depozitele firmei;
 procesul Inregistrare comanda noua poate Crea (Create) o nouă înregistrare în fişierul
Client, dacă noua comandă este primită de la un client cu care nu s-a mai înregistrat
nici o operație, sau Citeşte (Read) datele pentru identificarea clientului, eventual
Actualizează (Update) datele despre el. De asemenea, se Creează (Create) câte o nouă
înregistrare în fişierele Comanda (pentru ţinerea evidenţei comenzilor primite),
Produse comandate (pentru a şti ce produse au fost comandate), Tranzacţii comandă
(pentru păstrarea unui istoric al operațiilor cu clienţii, până la încheierea lunii sau a
anului) şi Livrări (pentru a înregistra data la care urmează să se facă livrările). Apoi,
Citeşte (Read) înregistrări din fişierele Pachet promoţii (pentru a se şti dacă noua
comandă se încadrează într-un pachet promoţional) şi Nomenclator produse (pentru a
afla preţul produselor comandate).
7.3.3 Descompunerea diagramelor fluxurilor de date

În paragraful 7.1 se specifica faptul că diagrama descompunerii funcţionale stă la baza
construirii „scheletului” diagramelor fluxurilor date, pentru că din ea se generează o serie de
diagrame ale fluxurilor de date, şi anume:
 o singură DFD pentru simbolul redat sub denumirea de Sistem, cunoscută sub numele
de diagramă de context;
 o singură DFD de nivel 0, în care sunt preluate principalele funcţii în care se
descompune sistemul pe primul nivel;
 câte o DFD de nivel 1, numărul acestor diagrame fiind egal cu numărul funcţiilor de pe
nivelul superior care se descompun. În exemplul dat, se vor obţine două diagrame de
nivel 1, una pentru procesele obţinute din descompunerea Tranzacţie 1 şi o diagramă
pentru procesele rezultate din descompunerea Tranzacţie 3. Dacă ar fi fost descompuse
şi Transformare 2, respectiv Tranzacţie 4, s-ar fi obţinut 4 diagrame de nivel 1;
 câte o DFD de nivel 2, numărul diagramelor fiind dat de numărul proceselor de pe
nivelul 1 care s-ar fi descompus în proceduri. Pentru cazul luat, se obţine doar o
diagramă de nivel 2, pentru redarea procedurilor în care s-a descompus Proces 1.2;
 câte o DFD de nivel 3, dacă sistemul este descompus în continuare, pe acelaşi
principiu, ca în cazul diagramelor de nivel 1 şi 2.
Plecând de la aceste consideraţii generale, vom descrie specificul fiecărei diagrame.
7.3.3.1 Diagrama de context
Diagrama de context este prima diagramă de fluxuri de date care se construieşte din setul
obţinut în urma descompunerii funcţionale. Prezintă cele mai puţine detalii, urmărind să scoată
în evidenţă graniţele sistemului, prin identificarea legăturilor cu entităţile externe, prin
intermediul fluxurilor externe de date (de intrare şi de ieşire). Ca urmare, diagrama de context
conţine un singur simbol de proces, denumit cu numele sistemului şi are atribuită cifra 0 ca
identificator. Nu sunt prezente locurile de stocare, pentru că nu sunt cuprinse procesele prin
care se pot face prelucrările specifice scrierii sau citirii din aceste locuri. Dacă apar situaţii
când sunt prezentate locuri de stocare, înseamnă că ele ies de sub sfera de influenţă a
sistemului modelat şi trebuie reprezentate sub forma entităţilor externe. Diagrama de context,
fără a fi particularizată, plecând de la descompunerea funcţională, este redată în fig. 7.8.
Pentru sistemul de gestiune a clienţilor de la firma ABC, diagrama de context este redată
în caseta 7.3.
Entitate externa
1
Entitate externa
2
Date-de-
intrare-1
Date-de-
iesire-1
Date-de-iesire-2
0
Sistem
Date-de-intrare-2
Entitate externa
3
Fig. 7.8 Exemplu generalizat pentru diagrama de context
Caseta nr. 7.3 – Diagrama de context pentru sistemul de gestiune a clienţilor
Departament
marketing
Sistem vanzari
Raport-
privind- Informatii- Rapoarte-privind-
potentialii- limita- vanzarile
clienti Informatii-
creditare-
clienti-noi-
clienti
Detalii- pentru-limita-
campanii- creditare
promotionale
Birou distributie
Date-de-identificare
Client Rapoarte-privind-
cataloagele
Cataloage
Comenzi-retururi
0
Confirmari-cataloage
SGC
Rapoarte-comenzi-
livrari-ajustari
Decizii-politici-
creditare-clienti
Detalii-tranzactii-clienti
Conducere
Raport-
privind- Detalii- Comenzi-
operațiile livrari de-onorat
Conturi-
analitice
Banca
Contabilitate Depozit-livrari
Fluxurile de date şi entităţile externe din diagrama de context sunt preluate din tabelul
evenimentelor, dar, aşa cum se ştie, sistemul trebuie să răspundă celor 20 de evenimente identificate,
ceea ce înseamnă că figura prezintă o combinaţie a fluxurilor de date pentru principalele evenimente,
tocmai pentru a asigura viziunea de ansamblu asupra sistemului.
7.3.3.2 Diagrama fluxurilor de date de nivel 0

Singurul proces redat în diagrama de context este descompus în principalele funcţii ale
sistemului pe următorul nivel, respectiv diagrama de nivel 0. Procesul de trecere de la
diagrama de context la următoarele niveluri de detaliere este numit generic „explodare”. Prin
diagrama de nivel 0 sunt prezentate secvenţa funcţiilor de prelucrare, locurile de stocare
accesate, precum şi enităţile externe cu care sistemul interacţionează. Fiecare funcţie are un
identificator numeric care corespunde secvenţei în care se execută.
Decizia privind funcţiile incluse de sistem este una deosebit de importantă, dar plasarea
lor în diagrama de nivel 0 este o decizie care se bazează pe subiectivitate. Deşi nu există reguli
stricte din acest punct de vedere, pot fi urmate câteva recomandări, în sensul că procesele care
se includ în diagrama de nivel 0 sunt cele care redau una sau mai multe dintre următoarele
acţiuni:
 un proces care asigură scrierea şi/sau citirea dintr-unul sau mai multe locuri de
stocare a datelor;
 un proces direct responsabil de obţinerea şi/sau transmiterea de date către una sau mai
multe entităţi externe;
 un proces care preia datele de la una sau mai multe entităţi externe;
 un proces care serveşte ca un descriptor de pe cel mai înalt nivel al paşilor prin care
trec datele în timpul transformării lor.
O altă modalitate de abordare a funcţiilor ce pot fi incluse într-o astfel de diagramă se
aplică în cazul sistemelor care se bazează pe aplicaţii informatice, caz în care opţiunile din
meniul principal al aplicaţiilor pot sta la baza reprezentării funcţiilor pe nivelul 0.
O caracteristică importantă a tuturor nivelurilor de reprezentare a DFD-urilor constă în
faptul că tot ceea ce este reprezentat pe un nivel superior, cu excepţia proceselor, care sunt
unice, trebuie să se regăsească şi pe nivelurile inferioare. Cu alte cuvinte, toate entităţile
externe, fluxurile de date din diagrama de context trebuie să fie reprezentate şi în diagrama de
nivel 0 şi pe următoarele niveluri. Odată ce un loc de stocare sau entitate a fost identificat(ă),
este necesar să se regăsească pe toate nivelurile inferioare, obţinute din descompunerea
proceselor cu care locul de stocare are o legătură.
Diagrama de context este explodată pentru a reda de la 3 până la maxim 9 procese,
obţinându-se un prim nivel de detaliere a sistemului, astfel încât să încapă pe o singură pagină.
Prin explodarea proceselor în subprocese, analiştii încep să reprezinte detaliile despre trecerea
datelor prin diferite prelucrări. Excepţiile sunt, în continuare, ignorate, cel puţin pentru primele
2-3 niveluri de descompunere ale sistemului. Se consideră că includerea a mai mult de 9
procese pe o pagină îngreunează înţelegerea ei, devenind prea încărcată cu fluxuri de date şi
locuri de stocare. Exemplul general al unei diagrame de nivel 0 a fost prezentat în fig. 7.3.
Atunci când sistemul este descompus pentru obţinerea diagramei de nivel 0, cu
principalele funcţii/procese de prelucrare, construirea ei se va baza pe identificarea logică a
fluxurilor externe (de intrare şi ieşire) şi conectarea lor la procesele corespunzătoare pentru a
face legătura cu entităţile externe, aşa cum au fost reprezentate în diagrama de context. Sunt
situaţii când, pentru simplificarea diagramei de context, s-a recurs la reunirea mai multor
fluxuri de date într-unul generalizat, dar care în DFD-0 intră sau ies în/din procese diferite. De
aceea, se impune descompunerea fluxului generalizat în două sau mai multe subfluxuri, pentru
a reda exact procesul în care intră sau din care ies.
Începând cu DFD-0, îşi fac apariţia fluxurile de date interne, adică cele care fac legătura
dintre procesele de prelucrare şi locurile de stocare sau dintre procese. Aceste fluxuri se vor
regăsi, în mod obligatoriu, pe următoarele niveluri ale DFD, în funcţie de procesul din DFD-0
care se explodează. Dacă nu se ştie ce ar trebui să fie inclus în DFD-0, se poate pleca de la o
entitate externă, un proces sau un loc de stocare şi apoi să se înceapă construirea diagramei de
la unul din aceste elemente. Se poate începe8:
 de la un flux de date ce intră în sistem de la o entitate externă, urmărind să se răspundă
la întrebări de genul: „Ce se întâmplă la intrarea datelor în sistem?”, „Trebuie să fie
memorate?”, „Reprezintă o intrare pentru mai multe procese?”;
 de la un flux de ieşire, analizându-se câmpurile lui, iar pentru fiecare câmp ce trebuie
generat de sistem se pun întrebările: „De unde poate fi obţinut?”, „Este un câmp
calculat sau este memorat într-un fişier?”. De exemplu, când ieşirea este Fluturaş,
atunci Nume salariat, Marcă, Funcţie ar trebui să se regăsească în fişierul Salariaţi,
Numărul de ore lucrate în fişierul Pontaje, iar Salariul brut, Impozitul, Reţinerile
legale să fie câmpuri calculate etc. Fiecare fişier va putea fi conectat la procesul care
generează fluturaşul;
 cu analiza fluxurilor care intră sau ies dintr-un loc de stocare. Se ridică întrebările:
„Prin ce procese sunt înregistrate/actualizate datele?”, „Ce procese apelează la datele
din locul de stocare respectiv?”;
 cu analiza proceselor definite în timpul descompunerii funcţionale. Se vor umări datele
de intrare de care are nevoie fiecare proces şi datele de ieşire pe care ar trebui să le
genereze, după care se vor conecta intrările şi ieşirile la locurile de stocare şi entităţile
corespunzătoare, prin intermediul fluxurilor de date care reflectă acele intrări/ieşiri;
 prin notarea tuturor aspectelor asupra cărora există anumite incertitudini, urmărindu-se
formularea unor întrebări pentru o nouă serie de interviuri cu utilizatorii-cheie ai
sistemului.
O altă manieră de abordare a descompunerii diagramei de context în DFD-0 este cea a
„fragmentării” sau „partiţionării” sistemului, plecând de la evenimente9. Astfel, se creează câte
un fragment de DFD pentru fiecare eveniment din tabelul evenimentelor sau proces identificat
la descompunerea funcţională, prin care se reliefează modul în care sistemul răspunde acestuia,
redându-se în detaliu interacţiunile procesului cu locurile de stocare şi entităţile externe. Apoi,
fiecare fragment de DFD poate fi combinat pentru obţinerea DFD de nivel 0.
Totuşi, de multe ori, se evită construirea diagramei de nivel 0 în varianta care se bazează
pe fragmentare, din cel puţin două motive:
1. sunt dublate informaţiile pe care le conţin atât fragmentele de DFD, cât şi DFD de
nivel 0, precum şi eforturile de construire a mai multor diagrame care conduc, în final,
la acelaşi rezultat;
2. adesea o astfel de manieră de construire pentru sistemele de dimensiuni mari este
complexă, surprinzând evenimente multiple şi diversificate.
În caseta 7.4 este redată diagrama de nivel 0 pentru sistemul de gestiune a clienţilor ABC.
Diagrama de nivel 0 este folosită şi în timpul proiectării diagramelor entitate-relaţie
(DER), pentru că prezintă fluxurile de date şi locurile de stocare pe baza cărora se pot
identifica entităţile de date şi relaţiile dintre ele. Conceperea celor două diagrame se poate
realiza în paralel.
7.3.3.3 DFD de nivel 1 până la n
După ce diagrama de nivel 0 a fost finalizată şi verificată, pentru eliminarea erorilor şi
asigurarea reprezentării corecte a fluxurilor sistemului, procesul de descompunere continuă cu
nivelurile de la 1 la n. Acest lucru înseamnă că nivelul 0 este descompus pe nivelul 1 şi, dacă e
necesar, nivelul 1 pe nivelul 2 ş.a.m.d., până când se atinge cel mai mare nivel de detaliere
pentru toate procesele şi subprocesele asociate. La procesele din DFD de nivel 0 se face
referire, de cele mai multe ori, sub denumirea de procese-părinte (parent processes), iar

9. Satzinger, J.W., Jackson, R.B., Burd, S.D. – op. cit., pp. 201-205.
processes).
Catalog Catalog
Client Conducere
Date- Nomenclator
Comanda-noua produs produse Decizii-politici-creditare-clienti
Cantitate- Date- Departament
Nota-confirmare- existenta Cantitate- Promotii noi- marketing
modificare-comanda Rapoarte-privind-comenzile
Nota-confirmare- comandata catalog
Date-modificare-comanda comanda Visible Systems Corporation Demonstration Version
Date- Date- Detalii-
1 promotii-
Sistem cataloage- campanii-
Client derulate existente promotionale
Informatii-limita- vanzari
Introducere creditare-clienti
comanda
Comenzi-de-
onorat
4
Date-comenzi- Date-promotii-noi
Informatii- Comanda-
Date- Tip- inregistrate
clienti-noi- catalog
Depozit- comanda- comanda
pentru-limita- Catalog
livrari noua Date- Tranzactii Intretinere date
creditare
comenzi-existente comenzi cataloage
Informatii- Detalii-comenzi-
si-clienti
Date- clienti-
Detalii- Comenzi 3
client noi
livrari Date- Date-
Detalii- Data-cataloage-
produs tranzactii- Cataloage
comenzi- Catalog Actualizare date trimise
Date- cataloage
de-
Clienti
comenzi-onorate clienti Rapoarte-
onorat privind-
Informatii-clienti-noi
Date- cataloagele
asemănător situaţiei subfluxurilor din DFD de nivel 0.

2 Tip-comanda- Tranzactii
catalog-
onorata comenzi Date-
Clienti comandate
ajustari
Onorare Stare- Tranzactii
comanda comanda catalog Birou
Nota-de-retur Rapoarte- distributie
Detalii-operații- privind-ajustarile Raport-
Notificare- clienti privind- Conturi-
receptie-retur potentialii- analitice
Client Conducere clienti
Raport-
Rapoarte-
privind- privind-
Banca
operațiile
vanzarile
Departament Contabilitate
marketing
Rapoarte-
privind- Sistem Contabilitate

livrarile vanzari
Conducere
149
Dacă procesul-părinte este conectat la un loc de stocare, şi diagrama-copil va conţine acel

poate primi sau nu poate genera un flux pe care procesul-părinte nu-l primeşte sau nu-l
fişier care să facă legătura între două procese ale diagramei-copil. În plus, pot să-şi facă
generează. Excepţie face situaţia în care fluxul primit/generat de procesul-părinte este
descompus în subfluxuri, pentru a se stabili legături distincte pentru fiecare subproces,
loc, dar şi altele ce nu sunt reprezentate în diagrama de nivel 0. De exemplu, poate fi inclus un
Prima regulă de construire a diagramelor de nivel 1 constă în faptul că un proces-copil nu
rezultatul explodării lor, respectiv subprocesele, sunt denumite procese-copil/proces-fiu (child
Caseta nr. 7.4 – Diagrama fluxurilor de date de nivel 0 pentru sistemul de gestiune a clienţilor
apariţia şi alte fluxuri de date, de importanţă mai mică sau de excepţie, cum ar fi un flux cu
erori, dar, aşa cum am specificat, nu este obligatoriu să se regăsească în diagrama de context şi
cea de nivel 0, dar obligatoriu trebuie să fie fluxuri interne şi nu externe.
De asemenea, pentru asigurarea principiului de balansare a diagramelor, fiecare proces-
copil din DFD de nivel 1 este legat de procesul-părinte, din care a fost obţinut, printr-un sistem
de numerotare secvenţial, plecând de la cifrele alocate în DFD de nivel 0, conform
descompunerii din figura 7.3. De exemplu, procesul Tranzacţie 1, de pe nivelul 0, este
reprezentat pe nivelul 1 cu trei procese-copil 1.1, 1.2, şi 1.3. Din figura 7.9, se poate observa că
aceleaşi fluxuri de date externe, care intră sau ies din procesul-părinte, sunt reprezentate în
diagrama de nivel 1.
Entitate externa 1
Date-de-intrare-1b
1.1
1.3
Proces 1.1
Date-
prelucrate-1 Proces 1.3
Date-prelucrate-2
1.2
Date-
intermediare-1
Proces 1.2
Date-de-
intrare-1a
Entitate externa 1
Fig. 7.9 Exemplu generalizat de diagramă a fluxurilor de date de nivel 1

Notă: În diagrama din exemplu, fluxul de date din DFD de nivel 0, Date-de-intrare-1, a
fost descompus în două subfluxuri: Date-de-intrare-1a şi Date-de-intrare-1b.
Pentru sistemul de gestiune a clienţilor de la firma ABC, diagrama de nivel 1 este redată
în caseta 7.5., iar în caseta 7.6 este prezentat un exemplu de diagramă, mult mai detaliată,
pentru procesul 1.2 din diagrama de nivel 1 (Inregistrare comanda noua), din cadrul sistemului
de gestiune a clienţilor de la firma ABC.
Câteva comentarii privind diagrama din caseta 7.6:
 aşa cum se observă, procesul 1.2 se descompune în 4 subprocese: Inregistrare date
clienti, Inregistrare date comanda, Prelucrare comanda, Confirmare comanda, fiind
văzute ca patru paşi principali necesari finalizării activităţii de primire a unei comenzi.
Această descompunere este doar o modalitate de divizare a prelucrării, alţi analişti
putând să vină cu soluţii diferite;
 primul pas începe când un client transmite o serie de date de identificare; dacă este un
client nou, procesul 1.2.1 înregistrează datele despre client în locul de stocare Clienti,
prin crearea unei noi înregistrări, iar în cazul clienţilor existenţi, prin actualizarea
datelor, în funcţie de situaţie. Apoi, procesul 1.2.1 transmite informaţiile despre
comandă prin fluxul Date clienti comanda către procesul 1.2.2, pentru a avea
elementele prin care să fie înregistrate detaliile privind comenzile primite;
Caseta nr. 7.5 – Diagrama de nivel 1 pentru funcţia Introducere comandă,

din diagrama de nivel 0 a sistemului de gestiune a clienţilor
Tranzactii comenzi
Conducere
Nomenclator
produse
Date-comenzi-
Rapoarte-privind-
inregistrate
Date-comezi-
modificate
comenzile
modificata
comanda-
Cantitate-
rapoarte comenzi
Actualizare
comenzi
Generare
1.3
1.4
Date-comenzi-modificate
comenzi-
existente
Date-
Nomenclator
produse
Date-produs
Sistem vanzari
Nomenclator
Date-client
produse
Comenzi
Catalog
Informatii-clienti-noi
Informatii-limita-
creditare-clienti
Cantitate-comanda-noua
Catalog
Cantitate-
existenta
Clienti
comanda-noua
produs
Date-
Date-comenzi-noi
Date-
Date-
client
si-modificate
existenta produs
inregistrate
Verificare
comenzi-
comanda noua
1.1
Date-
Inregistrare
Tranzactii comenzi
1.2
Comanda-noua
comanda
Tip-
modificare-
comanda
Date-client
Date-
creditare-clienti
Decizii-politici-
modificare-comanda
Nota-confirmare-
Nota-confirmare-
Comenzi-de-onorat
comanda
Conducere
Client
Clienti
Depozit-livrari
Client
 procesul 1.2.2 preia fluxurile Date clienti comanda, de la procesul 1.2.1, şi Date
comenzi noi si modificate, de la procesul 1.1, Verificare existenta produs, de pe nivelul
anterior de descompunere, pe baza cărora creează o nouă înregistrare în locul de
stocare Comenzi. Informaţii detaliate despre comenzi sunt transmise şi procesului
1.2.3, Prelucrare comanda, pentru a se înregistra cantitatea solicitată prin comanda
nouă şi pentru a trimite datele necesare procesului 1.3, Actualizare comenzi. Tot pe
baza prelucrărilor din acest proces, se adaugă o înregistrare în fişierul Tranzacţii
comenzi, cu ajutorul fluxului Comanda posibil de onorat, obţinut prin descompunerea
fluxului Tip comanda. Un ultim flux (Date comenzi de onorat) este trimis în procesul
1.2.4, Confirmare comanda. În cadrul acestui proces se calculează valoarea comenzii,
care este transmisă prin fluxul Date comenzi de onorat;
 în final, procesul 1.2.4 trebuie să verifice limita de creditare acordată clientului şi, dacă
noua comandă sau cea modificată se încadrează în această limită, se vor emite
documentele de acceptare a comenzii (fluxurile Nota confirmare comanda, Nota
confirmare comanda modificata). Cu ajutorul acestor informaţii şi pe baza celor

existente în fişier (fluxul Date comenzi înregistrate), are loc actualizarea comenzilor
înregistrate în fişierul Tranzactii comenzi (cu ajutorul fluxului Comanda confirmata,
cel de-al doilea subflux din Tip comanda). Tot din acest proces rezultă informaţiile
necesare pentru pregătirea livrărilor (Comenzi de onorat), care sunt transmise entităţii
Depozit-livrari.
Caseta nr. 7.6 – Diagrama de nivel 2 pentru funcţia Inregistrare comanda noua,
din diagrama de nivel 1 a sistemului de gestiune a clienţilor
Client Date-de-
identificare Clienti
Date-
client
Informatii-
1.2.1
clienti-noi
Client
Sistem vanzari
Inregistrare date
clienti
Nota- Nota- Informatii-limita

confirmare- confirmare-
creditare-cliednti
modificare- comanda
Date-
comanda
clienti-
comanda 1.2.4
Confirmare Comenzi- Depozit-livrari

1.2.2 comanda de-onorat
Date-comenzi-noi-
si-modificate
Inregistrare date Comanda-
comanda Date- confirmata
comenzi-de- Date-
Detalii- onorat comenzi-inregistrate
comenzi
Date-
Tranzactii comenzi
comanda-
noua Date-comenzi-
1.2.3 modificate
Comenzi
Prelucrare Cantitate-
comanda comanda-
noua
Comanda-
posibil-de-
Nomenclator
onorat Date- produse
comenzi-
inregistrate
Tranzactii comenzi
7.3.3.4 Recomandări privind oprirea procesului de descompunere a sistemului

Se ridică o problemă în privinţa momentului în care ar trebui să se oprească
descompunerea. Este o decizie la fel de subiectivă, ca şi cea privind stabilirea principalelor
funcţii ale sistemului, dar o recomandare generală sugerează că ultimul nivel de descompunere
n-ar trebui să depăşească nivelul 7. Procesul de descompunere ar trebui să continue până când
toate funcţiile şi procesele au fost explodate pentru a evidenţia un nivel de detaliere suficient
de relevant analizei. Când un proces a fost descompus la nivelul solicitat de detaliere, el este
referit ca o primitivă funcţională, în sensul că primeşte un singur flux de intrare şi generează
un singur flux de ieşire.
O altă recomandare privind descompunerea face referire la faptul că funcţiile (aplicaţiile)
trebuie să fie explodate, pe această cale, până ce detaliile logicii procesului sau „primitivele”
pot fi scrise pe cel mult o pagină de pseudocod. În cazul sistemelor complexe, apar totuşi ca
necesare nivelurile 3 şi chiar 4.
Chiar dacă la prima vedere ar părea că nu există reguli pentru a stabili momentul încetării
procesului de descompunere, pot fi luate în considerare următoarele recomandări:
 când întregul proces s-a redus la o singură decizie sau o singură operaţiune specifică
bazelor de date (restaurare, actualizare, creare, ştergere sau citire);
 când utilizatorii sistemului apreciază că nu au nevoie de detalii mai multe sau când
analiştii consideră că, prin documentaţie, au oferit suficiente amănunte, astfel încât
activităţile următoare din sistem să se deruleze fără probleme;
 când un flux de date nu mai trebuie să fie descompus pentru a arăta că unor date li se
aplică un tratament, iar altora, unul diferit;
 când se consideră că analistul a scos în relief fiecare formular, tranzacţie, ecran de
calculator, raport printr-un flux de date, ceea ce ar putea să însemne că un nume de
ecran sau de raport ş.a.m.d. este atribuit şi ca nume al unui flux;
 când analistul apreciază că s-a atins cel mai de jos nivel al procesului de
descompunere a opţiunilor meniurilor sistemului şi pentru fiecare dintre ele există
câte un proces distinct.
Din prezentările făcute rezultă ca procesul de descompunere este destul de subiectiv. El
poate înceta în orice moment, cu intenţia de oprire definitivă, dar poate fi şi reluat ulterior,
dacă se consideră utilă descompunerea.
În sinteză, un sistem trebuie să fie reprezentat printr-un set de diagrame, de genul celui
prezentat în fig. 7.10, şi anume:
1. o diagramă de context;
2. o diagramă de nivel 0, indicând principalele subsisteme ale sistemului;
3. până la 7 diagrame de nivel 1, indicând principalele funcţii (aplicaţii) ale fiecărui
subsistem;
4. până la 49 de diagrame de nivel 2, indicând detaliile fiecărei funcţii sau ale fiecărei
aplicaţii ş.a.m.d.
Diagrama de
context
4 Diagrama de
1
nivel 0
2 3
3.1
3.2 3.5 Diagrama de

3.4 nivel 1
3.3
Diagrama de
3.3.1
nivel 2
3.3.2 etc.
3.3.3
3.3.4
Fig. 7.10 Tehnica descompunerii diagramelor în concepţia Yourdon & DeMarco

7.3.4 Reguli de construire a diagramelor fluxurilor de date

Diagrama fluxurilor de date poate fi utilizată în două moduri: pentru documentarea unui
sistem existent sau pentru schiţarea unuia în curs de proiectare.
Sub formă narativă, sistemele sunt descrise prin text, din care, în urma analizei şi
selectării unei metode (de exemplu, Gane&Sarson sau Yourdon& DeMarco), pot fi sesizate
simbolurile de utilizat pentru construirea DFD.
După redactarea textului, primul pas va consta în crearea diagramei de context (în varianta
Yourdon&DeMarco) sau a unui tabel de entităţi şi activităţi (în varianta Gane&Sarson),
prezentat în figura 7.11 ca „Lista intrărilor/ieşirilor din/spre entităţile externe”.
Entităţi externe (EE) Intrări de la EE Ieşiri spre EE

Entitate externă 1 Date-de-intrare-1 Date-de-ieşire-2
Entitate externă 2 – Date-de-ieşire-1
Entitate externă 3 Date-de-intrare-2 –
Fig. 7.11 Lista intrărilor şi ieşirilor în varianta Gane&Sarson
Pentru evitarea din start a construirii eronate a diagramelor fluxurilor de date s-a instituit
un set de reguli aplicabile procesului de dezvoltare a diagramelor, indiferent că ele sunt
efectuate manual sau cu instrumente CASE10. O variantă prelucrată de literatura de specialitate
prezintă regulile de respectat în procesul de creare a DFD, conform tabelului 7.4 şi a figurii
7.12, privite concomitent.
Tabel nr. 7.4 – Reguli de construire a DFD
Procese
1. Nici un proces nu va putea avea doar ieşiri. Aceasta ar însemna obţinerea datelor din nimic.
Dacă un obiect are numai ieşiri, el este o sursă.
2. Nici un proces nu poate avea doar intrări. Dacă un obiect are numai intrări, el poate fi o
destinaţie.
3. Un proces este etichetat printr-o expresie care începe cu un verb urmat de prezentarea obiectului
la care se referă verbul. Exemplu: creare (verb) raport vânzări (obiect).
Stocare
4. Datele nu pot fi transferate direct dintr-un loc de stocare în altul. Datele pot fi transferate doar
prin intermediul unui proces.
5. Datele nu pot fi transferate direct dintr-o sursă externă într-un loc de stocare a datelor. Datele
pot fi transferate printr-un proces care primeşte datele de la o sursă şi le transmite unui loc de
stocare.
6. Datele nu pot fi transferate spre o destinaţie externă dintr-un loc de stocare. Datele pot fi mutate
prin intermediul unui proces.
7. Un loc de stocare este etichetat printr-un substantiv.
Entitate externă (sursă/destinaţie)
8. Datele nu pot fi transferate direct de la o sursă la o destinaţie. Trebuie folosit un proces de
trecere.
9. O sursă/destinaţie este etichetată printr-un substantiv.
Fluxuri de date
10. Un flux al datelor are doar o singură direcţie de flux între simboluri. Chiar dacă el poate fi şi
bidirecţional, între un proces şi un loc de stocare date, pentru a sugera o citire înainte de
10. Celko, J. – „Data Flow Diagrams”, in Computer Language, 4, January 1987, pp. 41-43.
actualizare, este indicată folosirea a două săgeţi de sensuri contrare, şi nu una singură cu
vârfuri la ambele capete, deoarece procesul se realizează în momente diferite.
11. Ramificaţia într-un flux de date înseamnă că aceleaşi date se transferă dintr-un loc comun în
două sau mai multe procese, locuri de stocare sau surse/destinaţii (de regulă, înseamnă copii
diferite ale aceloraşi date).
12. Asocierea (unirea) dintr-un flux de date înseamnă că exact aceleaşi date vin dintr-unul sau mai
multe procese sau locuri de stocare, sau sursă/destinaţie spre un loc de stocare comun.
13. Un flux de date nu poate reveni direct la procesul pe care l-a părăsit. Trebuie să existe cel puţin
un alt proces prin care să treacă, să se efectueze trecerea prin alte procese şi de aici să revină
fluxul iniţial de date la procesul iniţial.
14. Un flux de date spre un loc de stocare înseamnă actualizare (ştergere sau schimbare).
15. Un flux de date dinspre un loc de stocare înseamnă restaurare sau folosire date.
16. Un flux de date este etichetat printr-un substantiv. Pe o săgeată de flux pot apărea mai multe
substantive însemnând un transfer gen pachet.
Simbol Incorect Corect
Proces
1.
2.
Stocare
3.
4.
5.
Simbol Incorect Corect
Sursă/Destinaţie
6.
Transfer produse
7. Magazie
Flux de date
8.
A A
9. B A
A A
10. B A
A B
11.
A A
Fig. 7.12 Exemplificări incorecte şi corecte ale unor reguli din tabelul 7.5
În continuare, sunt redate, prin exemple, cele mai frecvente erori în construirea DFD:
1. omiterea unui flux de date sau direcţionarea greşită a sensului, astfel că poate rezulta un
proces care să aibă numai fluxuri de intrare sau numai fluxuri de ieşire. Fiecare proces
transformă date şi de aceea trebuie să primească cel puţin un flux de intrare şi să
genereze cel puţin un flux de ieşire. Această eroare poate afecta şi alte procese, în sensul
că, atunci când un flux de ieşire este reprezentat ca intrare, iar al doilea proces, care e
dependent de acea ieşire, e posibil să nu aibă intrări. Şi invers, dacă un flux de intrare este
redat ca ieşire, un alt proces e posibil să nu genereze ieşiri, aşa cum rezultă din figura
7.13.
Procesul 1.2.1 nu are

Comanda Client
nici o ieşire, ci
noua
numai intrări
1.2.1
Inregistrare Date clienti Clienti
date existenti
client
Cantitate Stoc
Detalii acceptata
comanda
1.2.2 1.2.3
Inregistrare Detalii Prelucrare
date comanda comanda
comanda
Procesul 1.2.2 nu are decât

ieşiri. Fluxul „Detalii comanda”
este greşit direcţionat, fiind
de fapt o ieşire din 1.2.1 şi
intrare pentru 1.2.2
Fig. 7.13 Exemplu de eroare cu procese care au numai fluxuri de intrare şi numai de ieşire
2. conectarea locurilor de stocare şi a entităţilor externe între ele. Legăturile între două
locuri de stocare se pot stabili numai prin intermediul unui proces de prelucrare. Datele
nu pot să treacă dintr-un fişier în altul sau de la o entitate la alta fără ajutorul unei
secvenţe de program sau al unei persoane, care execută manual un proces. În mod
similar, apare eroarea atunci când se stabileşte o legătură directă între o entitate externă
şi un loc de stocare, în sensul că entitatea nu poate interveni direct asupra înregistrărilor
dintr-un fişier fără să fie lansat în execuţie un proces care să asigure acea acţiune. De
exemplu, nu este posibil ca un client să intervină direct în fişierul de stocuri să vadă dacă
un produs este disponibil decât prin intermediul unei interfeţe (secvenţă de prelucrare).
La fel, două entităţi externe nu se pot afla în relaţie directă, chiar dacă ele trebuie să
comunice. În acest caz, fie comunicarea nu intră în aria de interes a sistemului modelat,
fie dacă sistemul trebuie să asigure acest lucru este necesar să intervină un proces. De
exemplu, transmiterea unui raport privind comenzile nu poate fi realizată direct de la
entitatea Departament livrari la Conducere din două motive: Departamentul nu are la
dispoziţie decât informaţiile privind livrările efectuate şi nu despre toate comenzile
primite de firmă la un moment dat, iar, în al doilea rând, pentru obţinerea raportului sunt
necesare procese de culegere a datelor de pe toate comenzile primite, sortarea şi filtrarea
lor în funcţie de anumite criterii, citirea unor informaţii din locurile de stocare şi abia
după aceea generarea raportului. Exemple de astfel de erori sunt redate în figura 7.14.
3. denumirea incorectă a proceselor sau fluxurilor de date. Un proces ar trebui să indice
numele sistemului, subsistemului sau să se folosească forma deja prezentată verb
(substantiv verbal) + descrierea funcţiei. Fiecare flux ar trebui să fie denumit printr-un
substantiv. Însă nu trebuie exagerat, având în vedere semnificaţiile şi formele multiple pe
care le pot lua cuvintele din limba română. De exemplu, „înregistrare” poate semnifica
atât procesul de înregistrare a datelor într-un fişier, cât şi setul de atribute ce formează o
înregistrare în fişier. La fel, „cerere” poate însemna acţiunea de interogare a unui fişier
sau de solicitare a unor informaţii, dar poate reprezenta şi un document de genul „Cerere
de aprovizionare”;
Clientul nu poate să-şi
modifice singur datele
Comanda Client
Date clienti în locul de stocare, ci
noua
modificate trebuie să intervină
un proces
1.2.1
Date clienti Clienti
Inregistrare
date existenti
client Un loc de stocare nu
poate fi actualizat
Cantitate Comanda direct pe baza datelor
Detalii acceptata dintr-un alt loc de
comanda Date produse stocare, ci printr-un
comandate proces.
1.2.2
Produse
Inregistrare comandate
date
comanda Detalii
comenzi
1.2.3
Date comanda
Prelucrare
de confirmat
comenzi
1.2.4
Generare
confirmare
comanda
Comanda
Comenzi
Contabilitate Client confirmata
transmise
O entitate externă nu poate

comunica direct cu altă entitate.
În cazul de faţă, Clientul nu are
responsabilitatea transmiterii
către Contabilitate a unui
astfel de flux, fiind necesar
un proces prin care fluxul
de date să poata ajunge
la acea entitate.
Fig. 7.14 Erori privind conectarea entităţilor externe şi locurilor de stocare
4. utilizarea unui număr prea mare sau prea mic de fluxuri, în sensul că o serie de fluxuri nu
sunt necesare pentru a fi preluate de un proces sau procesul nu poate genera ieşirile
indicate numai pe baza fluxurilor pe care le primeşte. În figura 7.15 este redată o astfel de
situaţie;
Cantitate Comanda
Detalii acceptata
comanda
Date produse
1.2.2 comandate Produse
Inregistrare comandate Procesul 1.2.2 nu
date poate genera toate
comanda detaliile despre
comenzile primite
Detalii
pentru că nu dispune
comenzi
de informaţii
1.2.3
privind preţul
Prelucrare produselor
comenzi
Fig. 7.15 Exemplu de fluxuri insuficiente pentru obţinerea unei ieşiri

5. descompunerea nebalansată a diagramelor superioare în diagrame-copil. Fiecare

diagramă-copil trebuie să aibă aceleaşi fluxuri externe de date ca şi cele conectate la
procesul-părinte, din explodarea căruia a fost obţinută. Pot să apară excepţii de la această
regulă, atunci când un flux este descompus în două subfluxuri sau când apar fluxuri noi
interne la nivelul diagramei-copil. Când două diagrame ale fluxurilor de date – de
exemplu, diagrama de context şi de nivel 0 – au fluxuri de date externe echivalente, se
spune despre ele că sunt diagrame ale fluxurilor de date balansate. Sunt corecte doar
seturile de diagrame ale fluxurilor de date balansate. În figura 7.16 sunt prezentate câteva
DFD balansate, din care se observă că nivelul 0 al DFD (punctul b) are aceeaşi intrare (A)
şi aceeaşi ieşire (B) ca şi diagrama de context (punctul a). La punctul c) este prezentată
explozia cercului numerotat cu 1.0. Se observă că există aceeaşi intrare (A) şi aceleaşi
ieşiri (C şi D) ca la punctul b). Această relaţie trebuie să existe, pentru că diagrama 1.0,
respectiv punctul c), este o explozie a cercului 1.0, din punctul b). Acelaşi lucru se poate
spune despre punctul d), descompunerea cercului 3.0. În fine, punctul e) prezintă
diagrama 3.1, o descompunere a cercului 3.1.
Sursa Sistem Destinaţie
a) Diagramă de context
Sursa A C
2.0 A E
1.2
1.0
1.1 G
Fişier
D F 1.3
3.0
B 1.4 C
Destinaţie D
b) DFD de nivel 0 c) Diagrama 1.0
D
3.1 I Fişier
D
I
3.1.1
H
3.2
J
B 3.1.2
H
d) Diagrama 3.0 e) Diagrama 3.1
Fig. 7.16 Un set de DFD balansate
Notă: Nu există diagrama 2.0, cât timp procesul 2.0 este unul elementar
Se poate observa că apar şi casetele entităţilor din diagrama de context, precum şi din
diagrama de nivel 0, dar care, de regulă, nu mai apar în diagramele de nivel 0 sau cele de
pe nivelurile inferioare acestuia, mai ales când sunt construite cu ajutorul instrumentelor
CASE, fiind deja memorate în sistem.
7.4 Depozitul metadatelor

În afara prezenţei elementelor necesare într-o DFD, se va urmări ca acestea să fie descrise
detaliat în dicţionarul proiectului, numit depozit de metadate (repository). El mai este întâlnit
şi sub numele de bază de date a proiectului, enciclopedia proiectului, dicţionar al datelor.
Pentru a se evita confuzia legată de termenul depozite de date (data warehouse), ca tehnologie
de interogare şi extragere date pentru analize, sau legată de dicţionarul datelor, aşa cum este
regăsit în lumea bazelor de date, vom folosi cu precădere depozit de metadate.
În cele mai multe produse CASE, acest depozit este legat de diagramă, ceea ce înseamnă
că pentru orice simbol al diagramei se va crea automat o poziţie în depozit, poziţie ce urmează
să fie completată de analist.
Depozitul metadatelor colectează şi descrie termeni specifici, asigurând înţelegerea, de
către diferite persoane din firmă, a semnificaţiei noţiunilor folosite în modelele sistemului,
fiind folosit pentru:
 oferirea documentaţiei sistemului şi eliminarea redundanţei în privinţa descrierii
elementelor acestuia, care ar putea proveni din diferite surse;
 validarea diagramelor fluxurilor de date din punct de vedere al completitudinii şi
corectitudinii lor;
 descrierea fluxurilor de date din perspectiva structurii lor şi a datelor elementare pe care le
conţin;
 oferirea punctului de plecare pentru proiectarea ecranelor şi rapoartelor;
 determinarea structurii locurilor de stocare şi utilizarea lor în realizarea diagramelor
entitate-relaţie şi în proiectarea logică a datelor;
 identificarea relaţiilor dintre date sau cum o structură de date se află în legătură cu o altă
structură;
 descrierea logicii proceselor de prelucrare, ce vine în sprijinul generării modulelor
programelor sistemului;
 păstrarea informaţiilor privind managementul proiectului, respectiv cerinţele proiectului şi
rezultatele aşteptate, planificarea resurselor, a perioadelor calendaristice pentru fiecare
etapă şi activitate, echipa de dezvoltare a sistemului etc.
Depozitul metadatelor este creat prin analiza şi descrierea conţinutului fluxurilor de date,
a locurilor de stocare, a proceselor, entităţilor externe şi a datelor elementare. Fiecare loc de
stocare şi flux de date ar trebui descrise prin prisma structurii corespunzătoare, după care
analiza trebuie extinsă pentru a include detalii despre datele elementare pe care le conţin.
Logica fiecărui proces de prelucrare poate fi descrisă cu ajutorul englezei structurate, plecând
de la datele care intră sau ies din el, precum şi de la matricea CRUD, pentru reflectarea
operaţiunilor care se execută asupra locurilor de stocare. Prin depozit se pot identifica
eventualele omisiuni sau erori care ar putea afecta proiectarea.
În general, descrierile în depozit cu privire la componentele diagramelor sunt:
1. numele componentei: sunt incluse toate numele prin care se identifică fiecare element din
diagrame, inclusiv alias-urile (pseudonime) sub care mai pot fi întâlnite aceste
componente, cu excepţia proceselor, ale căror denumiri sunt unice;
2. tipul componentei: proces, flux de date, loc de stocare, entitate externă, dată elementară;
3. structura: diferită în funcţie de tipul componentei, şi anume:
 în cazul fluxurilor de date şi al locurilor de stocare, descrierea se realizează prin
prezentarea datelor elementare (câmpuri, atribute) din care sunt alcătuite;
 dacă tipul este o dată elementară, atunci descrierea se realizează prin prezentarea
dimensiunii şi tipului de caractere folosite pentru redarea datei elementare, precum şi
intervalul de valori în care trebuie să se încadreze (de exemplu, AA9999).;
 un proces se descrie prin engleză structurată sau pseudocod, pentru redarea operaţiunilor
care se execută prin intermediul acelui proces;
 pentru entităţile externe se apelează la descrierea rolului pe care îl au, ce reprezintă pentru
sistem, când şi cum interacţionează cu sistemul etc.
4. caracteristici: este prezentată lista proceselor care interacţionează cu un flux de date. În
cazul datelor elementare, este prezentat fluxul sau locul de stocare din care provin. De
asemenea, pot fi oferite detalii privind frecvenţa apariţiei unui flux de date, execuţiei unui
Societatea:______________________________________________________
Localitate:________________ Judet: __________________Cod postal______
Strada:__________________________ Nr.________ Telefon/fax____________
Cod fiscal: ___________________________
Cont bancar:__________________________
Banca:_______________________________
COMANDA
Data Catre: __________________________________________________________

Cod operatii Cod beneficiarNr. comanda
Zi Luna An Localitate:________________ Judet: __________________Cod postal______
Strada:__________________________ Nr.________ Telefon/fax___________
Cod fiscal: ___________________________
Cont bancar:__________________________
Banca:_______________________________
Denumire produs si Unitate Termen de livrare

Nr. crt. Cod Produs Cantitate Pret unitar Valoare
caracteristici masura Zi Luna An
aceleaşi. Formularul de comandă este prezentat în caseta 7.7.
Adresa de expeditie:
Aceste date ar trebui să fie memorate pentru a putea fi utilizate ulterior.

Localitatea: __________________________ Strada: _________________________ Cod postal: _________________ Judetul: _________________
Expeditia se va face prin: _____________________________________
Plata se va face prin: CEC _____________, Ordin de plata ____________, Numerar _________, Compensare__________
Va rugam sa transmiteti confirmarea comenzii
Director, Contabil sef,

ideea că vor ajuta proiectanţii în stabilirea caracteristicilor fizice ale noului sistem.
161
elementele specifice produselor comandate: denumirea produselor şi caracteristicile lor

unor formulare speciale. Indiferent de tipul comenzii, datele care trebuie preluate în sistem sunt
Pentru a ilustra cum este completat depozitul metadatelor se va apela la continuarea
comenzile primite de la clienţi pot fi preluate prin poştă, fax, telefon sau Internet, cu ajutorul
exemplului privind sistemul de gestiune a clienţilor de la firma ABC. Aşa cum s-a prezentat,
proces, apelării unui loc de stocare, aspecte privind volumul datelor şi securitatea, în
(mărimea, culoarea), unitatea de măsură, cantitatea, precum şi metoda de plată ce va fi folosită.

numele, adresa, numărul de telefon al clienţilor care au lansat o comandă, după care urmează
În primul rând, din formularul de comandă, rezultă că trebuie preluate şi memorate
Caseta nr. 7.7 – Formular de comandă folosit de firma ABC pentru preluarea comenzilor
7.4.1 Descrierea fluxurilor de date

De obicei, în completarea depozitului se pleacă de la descrierea fluxurilor de date,
identificate în timpul intervievării, observării utilizatorilor sau analizei procedurilor şi altor
documente ale sistemului. Informaţiile despre fiecare flux de date ar trebui să surprindă:
1. un număr de identificare a fluxului sau un cod (opţional);
2. un nume descriptiv, ce apare în diagramă şi la care se poate face trimitere în toate
descrierile acelui flux;
3. descrierea generală a ceea ce reprezintă pentru sistem;
4. sursa fluxului de date, care ar putea fi o entitate externă, un loc de stocare sau un
proces de prelucrare;
5. destinaţia fluxului de date (entitate externă, loc de stocare sau proces);
6. specificarea dacă fluxul este o înregistrare ce intră sau iese dintr-un fişier sau o
înregistrare dintr-un raport, formular sau ecran. Dacă fluxul conţine date utilizate între
două procese sau între un proces şi loc de stocare, vor fi indicate ca fluxuri interne;
7. structura sau conţinutul fluxului, care poate să aibă la bază una sau mai multe date
elementare;
8. perioada de timp la care se înregistrează datele (zilnic, săptămânal, imediat), dacă este
vorba de un flux ce intră într-un loc de stocare;
9. alte comentarii şi observaţii privind fluxul.
În caseta 7.8 este prezentat un exemplu de descriere a fluxului de date ce reprezintă
documentul folosit pentru adăugarea unei comenzi noi şi pentru actualizarea locurilor de
stocare Clienti, Nomenclator Produse, Comenzi. De remarcat faptul că entitatea externă Client
reprezintă sursa, iar procesul Introducere comanda reprezinta destinaţia, aşa cum rezultă din
diagrama de nivel 0 din caseta 7.4.
La un moment dat, un flux poate fi descris doar printr-un singur câmp (dată elementară),
cum ar fi codul clientului folosit de o procedură de interogare pentru găsirea înregistrărilor
despre un anumit client.
Caseta nr. 7.8 – Exemplu de descriere a unui flux de date
pentru sistemul de gestiune a clienţilor la firma ABC
ID _________________________________________________________________
Denumire Comandă nouă
Descriere Conţine informaţii despre comanda clientului şi este folosită pentru
actualizarea fişierului Client, crearea unei înregistrări în Comenzi, Nomenclator
produse
Sursa Destinaţia
Client (entitate externa) Procesul 1.2 Introducere comanda
Tipul fluxului
Document Ecran Formular Raport Înregistrare fişier
Structura datelor Perioada de prelucrare
Informaţiile specifice formularului de comandă La sfârşitul zilei
Observaţii: Se va crea câte o înregistrare cu informaţiile despre comandă pentru
fiecare comandă a fiecăruia dintre clienţii firmei. Comanda poate fi primită prin poştă,
fax, telefon sau Web
Dacă se apelează la un instrument CASE, formularul de descriere a fluxurilor de date este

redat în figura 7.18, realizat cu ajutorul Visible Analyst (VA).
Fig. 7.18 Ecranul Visible Analyst de descriere a fluxurilor de date
7.4.2 Descrierea structurii de date

De cele mai multe ori, structurile de date sunt descrise cu ajutorul unor notaţii
matematice11:
1. semnul egal (=) înseamnă că fluxul de date este „compus din”;
2. semnul plus (+) semnifică „şi”
3. acoladele {} (în alte notaţii asteriscul *) indică grupurile repetitive, care pot include şi
anumite condiţii, cum ar fi un număr fix de repetiţii sau limite minime şi maxime
pentru numărul repetiţiilor;
4. parantezele rotunde () sau – în alte notaţii – cele drepte [] redau posibilitatea de
apariţie a unui element sau a altuia, toate incluse între paranteze, dar excluzându-se
unul pe altul;
5. parantezele drepte [], în alte notaţii cele rotunde ( ), înseamnă prezenţa unui element
opţional, ce poate fi omis în cazul ecranelor de introducere a datelor sau poate conţine
spaţii sau zero pentru câmpurile numerice din structura fişierelor.
Semnele diferă de la o tehnică la alta, iar în cazul Gane&Sarson, respectiv
Yourdon&DeMarco ele sunt exemplificate în figura 7.19, prin redarea structurii datelor pentru
introducerea comenzii unui client. Fiecare Ecran introducere comandă nouă este compus din
elementele ce se regăsesc la dreapta semnului egal. Unele dintre ele sunt date elementare, iar
altele sunt grupuri de elemente, cum ar fi Nume Client, Adresa, Telefon. Astfel, Nume Client
este alcătuit din Nume, Prenume, în cazul clienţilor persoane fizice, sau Denumire societate,
Tip societate, în cazul clienţilor persoane juridice. Fiecare grup de elemente trebuie să fie
descris până când întregul set este descompus în date elementare.
Câteva explicaţii la figura 7.19:
 Yourdon şi DeMarco apelează la parantezele rotunde, (...), pentru a sugera construcţiile
opţionale, şi acoladele, {...}, pentru repetiţii.
11. Kendall, K.E., Kendall, J.E. – op. cit., p. 310; Oprea, D., Dumitriu, F., Meşniţă, G. – CASE – proiectarea
asistată de calculator a sistemelor informatice, Ed. Universităţii „Al. I. Cuza” Iaşi, 1995, pp. 55-56; Satzinger,
J.W., Jackson, R.B., Burd, S.D. – op. cit., p. 217.
 în varianta Gane&Sarson, se observă că parantezele rotunde sunt înlocuite de cele

drepte, iar repetiţia este redată prin semnul * (asterisc), apelându-se, uneori, şi la
descrierea indentată a câmpurilor elementare. În plus, Gane&Sarson recomandă ca
structurile datelor să fie reduse la a treia formă normalizată, iar conţinutul locurilor de
stocare a datelor să fie prezentat prin reduceri la unul sau mai multe tabele relaţionale
în forma a treia normalizată.
Atunci când structurile de date sunt definite pentru prima dată, vor fi incluse numai datele
elementare pe care utilizatorii le pot vedea, cum ar fi nume, adresă, sold. Cele care sunt
folosite după cum au fost definite în alte sisteme sau aplicaţii nu vor fi vizibile, pentru că ele
sunt deja cunoscute, dar nu trebuie omise la descrierea structurilor. În această situaţie de
încadrează, de exemplu, atributele Oras, Judet, Cod postal, indiferent de faptul că se referă la
orasul furnizorului, al clientului sau salariatului, pentru că valorile se încadrează în acelaşi
format.
Gane&Sarson Yourdon&DeMarco
Comanda client = Cod client + Nume client + Comanda client = Cod client + Nume client +
Adresa + Telefon + Nr. comanda + Data Adresa + Telefon + Nr. comanda + Data
comanda+ Produse comandate* + Total valoare comanda+ {Produse comandate} + Total valoare
produs + Valoare livrare + Total valoare produs + Valoare livrare + Total valoare
comanda + [TVA] + Metoda de plata + [Tip comanda + (TVA) + Metoda de plata + (Tip
credit card] + [Nr. credit card] + [Data expirare credit card) + (Nr. credit card) + (Data expirare
card] card)
Nume client = Nume + [Initiala] + Prenume Nume client = Nume + (Initiala) + Prenume
Adresa = Stradă + [Apartament] + Oras + Judet + Adresa = Stradă + (Apartament) + Oras + Judet +
Cod Cod
Telefon = Prefix+Nr.local Telefon = Prefix+Nr.local
Produse comandate = Cod produs + Denumire Produse comandate = Cod produs + Denumire
produs + Marime + Culoare + Unitate masura + produs + Marime + Culoare + Unitate masura +
Cantitate + Pret + Total valoare produs Cantitate + Pret + Total valoare produs
Metoda de plata = (Cec ¦ Credit card ¦ Cash) Metoda de plata = [Cec ¦ Credit card ¦ Cash]
Tip credit card = (MasterCard ¦ VisaCard) Tip credit card = [MasterCard ¦ VisaCard]
Fig. 7.19 Exemplu de descriere a structurii datelor în tehnicile Gane & Sarson
şi Yourdon & DeMarco
Acest pas de descriere a structurii datelor poate fi considerat deja o activitate de

proiectare logică, pentru că reprezintă baza de plecare în proiectarea structurilor fizice de date,
care vor include şi ale elemente, cum ar fi:
 cheia primară, folosită pentru a identifica o înregistrare într-un fişier, cum ar fi codul
produsului, care nu este solicitat de o anumită activitate economică, dar este necesar
pentru identificarea mult mai uşoară a datelor despre produsul respectiv, fără riscul de
încălcare a unor restricţii privind bazele de date;
 câmpuri de stare, prin care se identifică dacă o anumită înregistrare este activă sau nu,
câmpuri ce sunt păstrate într-un fişier distinct, în funcţie de valoarea cărora se fac sau
nu anumite prelucrări asupra înregistrărilor respective;
 coduri pentru identificarea operațiilor/tranzacţiilor, folosite pentru a stabili tipul

înregistrărilor, atunci când un fişier conţine mai multe tipuri. De exemplu, un fişier ce
conţine soldul clienţilor poate conţine şi valoarea produselor returnate, valoarea
plăţilor efectuate;
 controlul grupurilor repetitive cu ajutorul unui contor al numărului de câmpuri care
fac parte din grup;
 limitele minime şi maxime pentru datele elementare ce fac parte din grupul repetitiv;
 parola folosită pentru accesarea din exterior a valorii datelor elementare păstrate în
fişiere şi baze de date.
7.4.3 Descrierea datelor elementare

Fiecare dată elementară ar trebui să fie definită o singură dată în depozitul metadatelor,
după care poate fi folosită ori de câte ori apare într-o altă structură de date (flux de date sau loc
de stocare). Aspectele comune ce trebuie surprinse la descrierea datelor elementare sunt:
1. identificatorul, opţional, ce permite analistului să găsească mult mai uşor data elementară,
în situaţia completării automate a depozitului şi nu numai;
2. numele datei elementare, care trebuie să fie cât mai sugestiv şi să se bazeze pe denumirile
comune utilizate de majoritatea programatorilor şi utilizatorilor;
3. alias-urile (pseudonime), reprezentând numele sub care mai pot fi întâlnite în sistem. Alias-
urile sunt nume folosite de diferiţi utilizatori din diferite sisteme pentru aceleaşi lucruri. De
exemplu, Cod_cl poate fi regăsit şi sub forma Ct_client sau Nr_client, având aceeaşi
semnificaţie.
4. o scurtă descriere a datei elementare, în sensul prezentării semnificaţiei ei pentru sistem;
5. specificarea dacă este o dată elementară de bază sau derivată. Este de bază atunci când
este introdusă ca atare în sistem, cum ar fi Nume, Adresa, Oras, fiind memorată în fişiere
sau baze de date. Elementele derivate sunt cele create prin intermediul unui proces de
prelucrare, adică al unor operaţii matematice sau logice, cum ar fi Valoarea totală a
comenzii, care este rezultatul aplicării funcţiei de însumare asupra Valorii produselor dintr-
o comandă. Analiza datelor elementare de bază sau derivate diferă, oferind un mijloc de
identificare a câmpurilor sistemului ce necesită analize suplimentare.
6. lungimea, respectiv dimensiunea fiecărei date, care trebuie asigurată la memorare.
Lungimea datelor din ecranele de introducere a datelor sau cele tipărite pot să difere de cea
memorată, însă procedurile responsabile cu afişarea lor vor insera spaţiile sau vor elimina
zerourile nesemnificative. Problema esenţială o constituie stabilirea lungimii fiecărei date
elementare, pentru că unele dintre ele au o lungime standard, cum ar fi abrevierea judeţelor,
codurile poştale, numerele de telefoane. Pentru altele, lungimea trebuie stabilită de comun
acord între analişti şi utilizatori, având în vedere următoarele consideraţii:
 lungimea datelor numerice trebuie să fie determinată prin identificarea celui mai mare
număr care ar putea să apară. Lungimea stabilită pentru totaluri ar trebui să fie mai mare
pentru a putea cuprinde toate cifrele rezultate din însumarea celorlalte date elementare;
 câmpurile pentru nume şi adrese se stabilesc în funcţie de cele mai frecvente apariţii sau
de cele mai comune nume. De exemplu, a rezultat dintr-o statistică faptul că numele de
familie cu 7-9 caractere sunt cel mai des întâlnite;
 pentru alte câmpuri este util să se analizeze datele istorice din cadrul firmei pentru a
determina lungimea corespunzătoare. De exemplu, examinând o listă cu prezentarea
produselor, se poate identifica denumirea care conţine cele mai multe caractere,
urmărindu-se şi determinarea unei valori medii;
Importanţa stabilirii lungimii datelor elementare rezidă din faptul că, dacă
lungimea este prea mică, datele introduse vor fi trunchiate, ceea ce înseamnă că s-ar
putea să afecteze valorea informaţiilor de ieşire. De exemplu, dacă numele unui client
este trunchiat, o notificare transmisă prin poştă poate să ajungă totuşi la acel client,
datorită adresei. În schimb, dacă se trunchează adresa de e-mail, atunci mesajul va fi
returnat sistemului pentru că nu poate să găsească o adresă de e-mail validă.
7. tipul datelor: numeric, dată calendaristică, alfabetic, caracter (alfanumeric sau de tip text),
şi, în ultimul timp, imagine, sunet.
8. formatul pentru intrare şi ieşire, folosind simboluri speciale, pentru a indica modul în care
vor fi prezentate datele, şi anume:
X – introducerea sau afişarea/tipărirea datelor alfanumerice
9 – introducerea sau afişarea datelor numerice
Z – afişarea zerourilor de la începutul atributului ca spaţii (suprimarea zerourilor
nesemnificative)
V – indică poziţia zecimalelor (când nu este inclus punctul zecimal), virgula virtuală;
, – inserarea unei virgule la afişarea unui număr
. – inserarea unei punct la afişarea unui număr
/– inserarea unui slash la afişarea unui număr
- – inserarea unei cratime la afişarea unui număr
9. criteriile de validare pentru a se asigura corectitudinea datelor preluate în sistem. Datele
elementare sunt fie „discrete”, adică cu valori fixe, fie „continous”, încadrate într-un
interval de valori;
10. orice valoare predefinită pe care o poate lua o data elementară. Valoarea predefinită
este afişată pe ecranele de introducere şi folosită pentru a reduce volumul datelor de preluat şi
al erorilor de introducere. Când se apelează la liste de tip drill-down, valorea predefinită este
cea selectată curent sau afişată cu altă culoare. Când se folosesc butoane radio, este selectată
opţiunea pentru valoarea predefinită, iar în cazul apelării la check box-uri, valoarea
predefinită este indicată prin bifare sau nu.
11. alte observaţii folosite pentru a indica formatul datei calendaristice, validările
specifice solicitate, metoda cifrei de control ş.a.
Un model de descriere a datelor elementare este redat în figura 7.20.
ID _________________________________________________________________
Denumire Cod client
Alias Ct_client, Nr. client
Descriere Identifică unic un client care a realizat cel puţin o operație/activitate în ultimii 5 ani
Caracteristici
Lungime ___6___ Nr. poziţii zecimale ____ Alfabetic
Format intrare ___9(6)__ Alfanumeric
Format ieşire ___9(6)__ Dată calendaristică
Valori predefinite _______ Numeric
Continous sau Discrete Bază Derivat
Criterii de validare
Continous Discrete
Limita superioară: <999999 Valoare Semnificaţie
_______ _______________
Limita inferioară: >0 _______ _______________
Observaţii: Cod client trebuie să treacă printr-o funcţie de verificare pe bază de
cheie de control modulo 11. Este derivat pentru că este generat automat, secvenţial la adăugarea
clientului în fişierul Clienti, fiind adăugată şi cifra de control
Fig. 7.20 Exemplu de formular de descriere a unei date elementare numerice
În varianta CASE (Visible Analyst), formularul de descriere a datelor elementare este

prezentat în figura 7.21.
Fig. 7.21 Ecranul Visible Analyst pentru descrierea datelor elementare
Pentru descrierea unei date elementare de tip alfabetic este prezentat exemplul din figura
7.22, care este o dată discretă, cu o listă de coduri de selectat pentru atribuirea valorilor. Când
această dată elementară va fi implementată în baza de date, şi utilizatorii vor fi instruiţi pentru
exploatarea sistemului, va fi necesar să se listeze un tabel cu valorile pe care ar putea să le ia şi
cu semnificaţia abrevierilor folosite.
ID _________________________________________________________________
Denumire Culoare
Alias
Descriere Culoarea pentru fiecare tip de articol de îmbrăcăminte
Caracteristici
Lungime ___2___ Nr. poziţii zecimale ____ Alfabetic
Format intrare ___X(2)__ Alfanumeric
Format ieşire ___X(2)__ Dată calendaristică
Valori predefinite _______ Numeric
Continous sau Discrete Bază Derivat
Criterii de validare
Continous Discrete
Limita superioară: ______ Valoare Semnificaţie
Limita inferioară: ___AB____ _Albastru______
___AL____ _Alb__________
___VR____ _Verde________
Observaţii:___________________________________________________________
Fig. 7.22 Formular descriere dată elementară de tip alfabetic, discret
7.4.4 Descrierea locurilor de stocare

Aşa cum am mai specificat, datele elementare de bază şi o parte din cele derivate ar trebui
să fie memorate în sistem. Cu alte cuvinte, atunci când datele elementare ale fluxurilor de date
sunt grupate, pentru a forma un grup de înregistrări, este creat un loc de stocare. Pentru că un
flux de date poate să conţină doar o parte din datele care formează structura unei înregistrări,
este necesar să se analizeze mai multe structuri de fluxuri pentru a avea o descriere completă a
locurilor de stocare. De exemplu, când se adaugă o înregistrate pentru un client nou, se pot
include iniţial numai informaţiile cunoscute. Soldul contului, data tranzacţiei şi alte informaţii
pot fi adăugate în locul de stocare Clienti, după ce au avut loc anumite operaţii economice,
regăsindu-se în diferitele fluxuri de date, pe baza cărora se fac prelucrările specifice.
Descrierea locurilor de stocare se realizează prin intermediul elementelor:
1. identificatorul locului de stocare, obligatoriu în tehnica Gane&Sarson, pentru a
preveni înregistrarea datelor redundante;
2. denumirea semnificativă;
3. alias-urile sub care mai poate fi regăsit;
4. o scurtă descriere;
5. tipul de fişier, respectiv dacă este informatic sau specific sistemelor manuale (pe
suport de hârtie). Dacă este automat, trebuie specificat formatul, fie că este vorba de o
bază de date relaţională, o tabelă a acesteia sau un fişier clasic. Dacă este manual,
atunci se va specifica modul şi criteriile în care se vor adăuga informaţiile prelucrate
de pe documente;
6. numărul maxim şi minim de înregistrări, informaţie care ajută la estimarea spaţiului de
memorie solicitat şi determinarea sistemului de gestiune a datelor şi a echipamentelor
de folosit;
7. numele sub care mai poate fi identificat în cadrul actualelor aplicaţii, dacă este
cunoscut sau dacă este cazul;
8. structura datelor, care ar trebui să aibă denumirea deja în depozitul datelor, astfel încât
să se realizeze legătura cu datele elementare din structura fluxurilor de date sau a
celorlalte locuri de stocare. De asemenea, este necesar să se stabilească cheile primare
sau secundare.
9. observaţiile folosite pentru adăugarea de informaţii care nu se încadrează în nici una
din categoriile anterioare, cum ar fi momentul actualizării datelor, al realizării copiilor
de siguranţă, drepturile de acces etc.
În figurile 7.23 şi 7.24 se prezintă formularul de descriere a locurilor de stocare, respectiv
ecranul specific Visible Analyst.
ID _________________________________________________________________
Denumire Clienti
Alias Nom_Clienti, Fisier principal Clienti
Descriere Conţine câte o înregistrare pentru fiecare client al firmei
Caracteristicile locului de stocare
Tipul Informatic Manual
Format Bază de date Fişier indexat Fişier secvenţial
Mărimea înregistrării (caractere) _200_ Mărimea blocului 4000
Număr de înregistrări: Maxim 45000 Mediu 4200
Procent creştere a înregistrărilor pe an: 6%
Nume structură de date: Client.dbf
Structura datelor: Înregistrare client
Cheie principală: Cod client
Cheie secundară: Nume client
Cod poştal
Observaţii: Înregistrările din Nomenclatorul Clienti sunt copiate într-un fişier
istoric şi eliminate dacă un anumit client nu a mai cumpărat nimic în ultimii 5 ani.
Un client poate fi păstrat chiar dacă nu a cumpărat pe bază de catalog.
Fig. 7.23 Formular de descriere a unui loc de stocare

Fig. 7.24 Ecranul Visible Analyst pentru descrierea locului de stocare Clienti
7.4.5 Descrierea proceselor

Descrierea proceselor de prelucrare – numită, uneori, şi minispecificaţie, datorită faptului
că este o mică parte din specificaţia întregului proiect – este realizată pentru primitivele din
DFD-uri, explicând logica şi formulele prin care sunt transformate intrările în ieşiri (asupra
acestor aspecte vom reveni în capitolul privind modelarea logicii proceselor). Fiecare dată
elementară derivată trebuie să aibă la bază o operaţie logică sau matematică, pentru a reda
modul în care este obţinută din datele elementare de bază sau altele derivate, create anterior, ce
sunt intrări în procesul curent.
Întocmirea specificaţiilor proceselor urmăreşte trei obiective12:
 reducerea ambiguităţii proceselor, forţând analistul să depisteze cât mai multe detalii
asupra modului de realizare a fiecărui proces, prin identificarea componentelor vagi,
neclare şi reluarea interviurilor cu utilizatorii;
 obţinerea unei descrieri cât mai exacte a ceea ce se execută în sistem, urmând a fi
inclusă în specificaţiile necesare programatorilor;
 validarea proiectării sistemului, asigurându-se că un proces are toate intrările necesare
obţinerii ieşirilor şi că ele au fost reprezentate în DFD.
Se pot întâlni multe situaţii în care specificaţiile proceselor nu sunt create, fie pentru că
sunt foarte simple, fie pentru că există deja codul sursă al acestora, dar, în ultimul caz, se va
atenţiona echipa de proiectare că acele procese au deja codul sursă. Categoriile de procese,
care, în general, nu solicită descriere sunt:
 reprezentarea fizică a intrărilor şi ieşirilor, cum ar fi scrierea şi citirea, fiind doar
operaţii logice simple;
 redarea unei validări a datelor, fiind relativ uşor de executat. Criteriile de validare
sunt deja incluse în dicţionar, la descrierea formularelor de introducere a datelor.
Totuşi, specificaţiile sunt necesare pentru procesele de editare complexe;
12. Kendall, K.E., Kendall, J.E. – op. cit., p. 348.

 cele care folosesc un cod sursă deja existent, adică cele incluse într-un alt sistem sau
în sistemul curent ca subprograme sau funcţii. Subprogramele sunt scrise, testate şi
memorate, executând o funcţie generală a sistemului, cum ar fi validarea unei date
calendaristice sau a unei cifre de control, astfel că ele sunt descrise numai o dată şi
utilizate ori de câte ori este necesar.
Fiecare specificaţie de proces trebuie să includă un formular de descriere, cu următoarele
elemente:
1. numărul procesului, care trebuie să fie identic cu cel din DFD;
2. denumirea procesului, care trebuie să coincidă cu cel din DFD;
3. scurtă descriere a ceea ce realizează procesul;
4. lista fluxurilor de intrare, apelând la numele regăsite în DFD. Numele datelor
elementare folosite în relaţiile de calcul sau operaţiile logice trebuie să fie identice cu
cele din depozitul metadatelor, pentru a asigura consistenţa lor şi o bună comunicare;
5. lista fluxurilor de ieşire, apelând la denumirea din depozit;
6. indicarea tipului de proces: pe loturi, on-line, manual. Toate procesele on-line solicită
proiectarea de ecrane, iar cele manuale trebuie să aibă proceduri foarte bine definite,
astfel încât salariaţii să-şi poată desfăşura activităţile specifice;
7. numele subprogramului sau funcţiei corespunzătoare pentru procesul care are deja
codul sursă existent;
8. logica procesului, care statuează regulile economice într-un limbaj natural şi nu într-
un limbaj de programare. Regulile economice sunt proceduri sau un set de condiţii şi
formule ce permit firmei să-şi desfăşoare activităţile specifice. Formatul comun al
unei reguli include:
 definiţiile termenilor economici folosiţi;
 condiţiile şi acţiunile economice;
 restricţiile privind integritatea datelor;
 formulele matematice;
 operaţiile logice;
 secvenţa prelucrărilor;
 relaţiile dintre diferite evenimente;
9. dacă nu există suficient spaţiu pentru descrierea completă a procesului cu ajutorul
englezei structurate sau dacă logica procesului se realizează cu ajutorul arborilor sau
al tabelelor de decizie, se va face trimitere la numele lor şi se vor ataşa specificaţiilor
procesului;
10. se vor comunica aspectele nerezolvate, părţile incomplete ale descrierii proceselor,
pentru a fi clarificate în timpul unor noi interviuri.
În figura 7.25, este redat un formular de descriere a unui proces de prelucrare, iar, în 7.26,
ecranul din Visible Analyst.
ID _1.1_____________________________________________________________
Denumire Verificare existenţă produs
Descriere Se determină dacă un produs este disponibil sau nu pentru vânzare
Fluxurile de intrare
Comanda noua
Date modificare comanda
Date client
Date produs
Cantitate existenta
Fluxurile de ieşire
Date comenzi noi si modificate

Tipul procesului Numele programului/funcţiei
On-line Pe loturi Manual
Logica procesului
Dacă Cantitate produs comandă < Cantitate existentă
Atunci transferă Cantitate produs comandă în Cantitate produs disponibil
transferă Cod produs comandă în Cod produs disponibil
Altfel
scade Cantitate existentă din Cantitate produs comandă
rezultând Cantitate posibil de onorat
transferă Cantitate posibil de onorat în Cantitate produs comandă
transferă Cod produs comandă în Cod produs posibil de onorat
Sfârşit dacă
Referire la: Nume descriere
Engleză structurată Tabel decizional Arbore decizional
Observaţii: Este necesar să se ia în considerare cantitatea existentă în stoc pentru a
accepta o comandă pentru un anumit produs sau ar trebui să se aibă în vedere şi data la
care clientul doreşte livrarea produselor din comandă. În aceste condiţii, cum se
modifică şi se calculează cantitatea disponibilă?
Fig. 7.25 Formular de descriere a unui proces de prelucrare
Fig. 7.26 Ecranul Visible Analyst pentru specificaţiile unui proces
Deşi construirea depozitului de metadate, cu toate detaliile şi descrierile fiecărei

componente a sistemului, până la nivel de dată elementară, solicită un efort imens, rezultatele
şi beneficiile obţinute se vor vedea în timpul proiectării, implementării şi întreţinerii, în special
în prezenţa instrumentelor CASE. În aceste etape, orice modificare efectuată asupra
elementelor din diagrame se propagă la nivel de întreg depozit, fără să mai fie necesar ca
analistul să reţină toată schimbările intervenite. Mai mult, depozitul metadatelor constituie
suportul esenţial pentru generarea specificaţiilor de analiză.
Rezumat
Crearea unor modele grafice ale sistemului este utilă pentru a obţine o imagine mult mai clară
asupra principalelor componente ale acestuia, cu ajutorul diferitelor diagrame. Modelarea conceptuală
(logică) a sistemului reprezintă începutul activităţilor cu caracter tehnic din dezvoltarea unui sistem, cu
scopul de a completa specificaţiile de analiză şi pentru o redare cuprinzătoare a elementelor ce vor fi
supuse proiectării.
Procesul prin care analiştii modelează funcţiile unui sistem reprezintă o abstractizare a activităţilor
fizice, cunoscută şi sub numele de echivalenţă logică. Un pas important în procesul de abstractizare îl
constituie descompunerea pe funcţii de prelucrare a sistemului sau descompunerea funcţională, prin care
se identifică principalele componente ale unui sistem (funcţii, procese, proceduri de prelucrare ş.a.),
obţinându-se o diagramă a descompunerii funcţionale.
Un model grafic ce s-a dovedit a fi deosebit de valoros pentru modelarea proceselor îl reprezintă
diagramele fluxurilor de date, fiind unul din cel mai utilizate. Într-o definiţie restrânsă, DFD-urile sunt o
metodă de prezentare grafică a traseului logic pe care îl parcurg datele prin diverse procese până sunt
transformate în ieşiri, redând toate componentele logice ale unui sistem într-o singură reprezentare
grafică, respectiv intrările, ieşirile, prelucrările şi locurile de stocare, precum şi graniţele sistemului.
Indiferent de metodologiile folosite în realizarea unui sistem/aplicaţie, toate apelează la operaţiunea
de modelare logică a datelor şi prelucrărilor sub formă de diagrame, diferenţele constând doar în folosirea
mai pronunţată a diagramelor pentru descrierea sistemului, încadrându-le în diagrame de context,
diagrame ale fluxurilor de date fizice şi diagrame ale fluxurilor de date logice. Altele apelează la
combinaţii de diagrame, tabele şi forme descriptive.
Diagrama descompunerii funcţionale stă la baza construirii „scheletului” diagramelor fluxurilor
date, pentru că pot fi generate automat, mai ales cu ajutorul instrumentelor CASE, şi anume: o diagramă
de context; o singură DFD de nivel 0; câte o DFD de nivel 1 pentru fiecare proces care se descompune
din diagrama de nivel 0; câte o DFD de nivel 2 pentru fiecare proces care se descompune din diagrama
de nivel 1; câte o DFD de nivel 3 pentru fiecare proces care se descompune din diagrama de nivel 2 etc.
Atunci când se construiesc DFD, pot să apară mai multe erori, dintre care cele mai comune sunt:
omiterea unui flux de date sau direcţionarea greşită a sensului; conectarea locurilor de stocare şi
entităţilor externe între ele; denumirea incorectă a proceselor sau fluxurilor de date; utilizarea unui
număr prea mare sau prea mic de fluxuri; descompunerea nebalansată a diagramelor superioare în
diagramele-copil.
În afara prezenţei elementelor necesare într-o DFD, se va urmări ca acestea să fie descrise detaliat în
dicţionarul proiectului, numit depozit de metadate (repository). În cele mai multe produse CASE, acest
depozit este legat de diagramă, ceea ce înseamnă că pentru orice simbol al diagramei se va crea automat o
poziţie în depozit, poziţie ce urmează să fie completată de analist.
1. Ce rol are diagrama descompunerii funcţionale în modelarea sistemului?
2. Definiţi tipurile de diagrame ale fluxurilor de date ce pot fi construite în timpul analizei?
3. Enumeraţi cel puţin patru avantaje ce pot fi obţinute din modelarea sistemului cu ajutorul
diagramelor fluxurilor de date comparativ cu descrierea narativă a acestuia. Motivaţi avantajele.
4. Care sunt cele patru simboluri utilizate în modelarea sistemului cu ajutorul DFD?
5. Care este semnificaţia conceptului de „explodare” a DFD?
6. Enumeraţi regulile privind procesele ce trebuie respectate la construirea DFD.
7. Enumeraţi regulile privind locurile de stocare ce trebuie respectate la construirea DFD.
8. Enumeraţi regulile privind entităţile externe ce trebuie respectate la construirea DFD.
9. Care este rolul depozitului de metadate?
10. Care este conţinutul formularului de descriere a unui flux de date?
11. Care este conţinutul formularului de descriere a unei date elementare?
Probleme de echipă
1. Plecând de la experienţa avută din momentul înscrierii la ultimul concurs de admitere şi până la un
eveniment ce a avut loc după doi ani, încercaţi să:
a) construiţi un tabel al evenimentelor;

b) dezvoltaţi o diagramă a descompunerii funcţionale, cu 2 niveluri;
c) construiţi diagrama de context şi diagrama de nivel 0;
d) scoateţi în evidenţă fluxurile care presupuneţi că ar fi interne sistemului şi care sunt vizibile
din exterior.
2. Descrieţi, pe scurt, tranzacţiile de prelucrare specifice pentru comenzi, plecând de la următoarea
prezentare:
Red Pizza doreşte să implementeze un sistem pentru înregistrarea comenzilor primite prin
telefon. Când un client obişnuit al firmei telefonează, i se solicită să specifice numărul său de telefon,
care, odată introdus, determină apariţia pe ecran a numelui, adresei şi data ultimei comenzi. Odată
preluată comanda, se calculează valoarea ei şi TVA-ul, după care este transmisă la bucătărie. Pe baza
comenzii, este emis şi bonul de casă (chitanţa sau factura, după caz). Cu diverse ocazii, sunt tipărite
diferite oferte speciale (cupoane) pe baza cărora clienţii pot obţine unele reduceri. Cei care
transportă comanda la adresa specificată de client predau acestuia un exemplar din bonul de casă şi
un cupon (dacă este cazul). Săptămânal se obţin rapoarte privind livrările efectuate pentru a face
comparaţie cu performanţele din perioadele anterioare.
3. Construiţi diagrama de context şi diagrama de nivel 0 pentru sistemul descris la punctul anterior.
4. Construiţi o diagramă-copil pentru procesul prin care se adaugă un nou client, din diagrama de nivel
0 anterioară.
5. Creaţi diagramele fluxurilor de date pentru următoarea situaţie:
Job Part Time este o firmă specializată în plasarea personalului la diferite firme, pe perioade
scurte de timp. Firma urmăreşte plasarea personalului cu un grad ridicat de pregătire în utilizarea de
aplicaţii, cum ar fi procesare texte, baze de date, programare etc. Angajaţii trebuie să treacă de un
test de demonstrare a performanţelor şi abilităţilor profesionale, pe baza căruia obţin un certificat de
recunoaştere a competenţei profesionale. Sistemul descris în continuare este responsabil cu
pregătirea angajaţilor solicitaţi pentru diverse posturi în regim part-time:
 firmele apelează la Job Part Time pentru a solicita personal în regim de program scurt de lucru.
Cererea este folosită pentru a crea o înregistrare privind solicitarea de angajări temporare. Dacă
firma care a formulat cererea nu este înregistrată în fişierul Angajatori, se va crea o nouă
înregistrare;
 salariaţii sunt selectaţi în funcţie de calificările şi disponibilitatea lor. Locurile de stocare
Salariaţi part-time şi cel al Cererilor de angajări temporare sunt folosite pentru a lista toţi
candidaţii calificaţi pentru locurile de muncă oferite de angajatori;
 se transmit contracte salariaţilor selectaţi. Informaţiile se obţin din Salariaţi part-time,
Angajatori şi cereri de angajări temporare;
 contractele semnate sunt folosite pentru actualizarea locurilor de stocare anterioare cu informaţii
privind personalul angajat şi perioada de angajare;
 lunar, se tipăreşte un program de lucru pentru fiecare salariat. Informaţiile sunt obţinute din cele
3 locuri de stocare, fiind ordonate după data angajării fiecărei persoane;
 sunt transmise notificări către firmele care au solicitat personal temporar, pentru a confirma data
de la care pot să se prezinte personalul ce deţine calificările necesare.
6. Creaţi o matrice CRUD pentru diagrama de nivel 0 de la problema anterioară.
CAPITOLUL VIII
Modelarea conceptuală a datelor

(diagramele entitate-relaţie, DER)
Obiective:
 Discutarea necesităţii şi conţinutului modelării conceptuale a datelor
 Prezentarea conceptelor utilizate în construirea diagramelor entitate-relaţie
 Înţelegerea modului de transpunere a regulilor economice în modelul conceptual al datelor
 Prezentarea unui model general al DER pentru sistemele informaţionale economice
După o abordare multiplă a sistemelor informaţionale, a importanţei lor într-un organism

economic, am continuat cu prezentarea elementelor-cheie ale dezvoltării sistemelor
informaţionale, şi chiar am redat modalităţile determinării cerinţelor unui sistem. În momentul
de faţă discutăm despre structurarea lor, aflându-ne la unul dintre cele mai importante
momente şi obiecte din viaţa sistemului. Importanţa rezidă, îndeosebi, în statutul obiectului
supus discuţiei: datele.
În capitolul anterior ne-am referit doar la structurarea logică a proceselor de prelucrare din
organizaţie (enumerarea şi legarea lor), regăsită şi cu denumirea de modelarea logică a
prelucrărilor.
Elementele esenţiale erau diagramele – ca instrument de lucru – şi datele ca obiect de
prelucrare. Insistăm asupra acestui aspect, deoarece se produce un salt esenţial în abordarea
sistemelor: abandonarea proceselor ce au loc în sisteme (ca importanţă în activităţile de
analiză şi proiectare) şi trecerea datelor pe primul plan. De fapt, era chiar un paradox: se
încerca realizarea unor sisteme cât mai stabile pe baza celor mai instabile componente ale lor,
procesele.
Ideea de structurare a sistemului oricum va rămâne. Din această cauză considerăm că se
cuvine să evidenţiem poziţia datelor în abordarea sistemelor.
8.1 Aplicarea principiului abstractizării în modelarea datelor

În acest paragraf vom încerca să evidenţiem necesitatea şi conţinutul modelării
conceptuale a datelor. În acest sens, va trebui să explicăm în ce constă aplicarea principiului
abstractizării în modelarea datelor. De fapt, acesta reprezintă unul din principiile fundamentale
aplicate în proiectarea sistemelor informatice, el fiind utilizat şi la proiectarea arhitecturii
programelor. Aplicarea principiului abstractizării permite stăpânirea complexităţii sistemului,
prin luarea în considerare, în mod eşalonat, a diferitelor aspecte ale acestuia. La un moment
dat, analiştii se vor concentra doar asupra anumitor aspecte, ignorându-le pe celelalte, dar care
vor fi luate în considerare ulterior.
Concret, aplicarea principiului abstractizării în modelarea datelor presupune operarea pe
trei niveluri, prezentate în figura 8.1: conceptual, logic şi fizic. Corespunzător celor trei
niveluri, pot fi identificate trei activităţi esenţiale în proiectarea bazelor de date:
 analiza cerinţelor sistemului şi modelarea conceptuală a datelor,
 modelarea logică a datelor sau proiectarea logică a bazei de date şi
 modelarea fizică a datelor sau proiectarea fizică a bazei de date.
MODELAREA CONCEPTUALĂ A DATELOR 175
Cerinţele de date ale

sistemului
Modelul conceptual al datelor

(modelul entitate - relaţie)
Regulile şi conceptele Cerinţele de calitate
modelului relaţional (flexibilitate, stabilitate etc.)
Modelul logic al datelor

(modelul relaţional pur)
Cerinţele nefuncţionale şi Facilităţile SGBD-ului ales
de performanţă
Modelul fizic al datelor

(structura fizică a da telor)
Fig. 8.1 Nivelurile de abstractizare a datelor
Prin modelarea conceptuală a datelor se urmăreşte construirea unui model al datelor care
să asigure transpunerea exactă a realităţii din domeniul analizat, fără a lua în considerare
cerinţele specifice unui model de organizare a datelor (cum este modelul relaţional), criteriile
de calitate privind organizarea datelor, cerinţele nefuncţionale ale sistemului şi criteriile de
performanţă privind stocarea şi accesarea datelor. Modelul conceptual al datelor înseamnă o
formă de reprezentare a datelor organizaţiei astfel încât el să reflecte regulile de derulare a
afacerilor în firma respectivă. Rolul său este de a scoate în relief toate regulile privind
identitatea şi legăturile existente între date.
Cea mai cunoscută formă utilizată pentru modelarea conceptuală a datelor este diagrama
entitate-relaţie (DER). O modalitate aproape identică este folosită şi în analiza şi proiectarea
orientate-obiect.
Modelul conceptual este unul abstract, care nu poate fi implementat direct pe calculator.
De exemplu, modul în care vor fi implementate legăturile dintre entităţile de date nu
interesează în acest moment, atenţia fiind îndreptată doar spre identificarea şi descrierea lor.
Ulterior, acest model trebuie transformat într-o schemă a bazei de date sub formă de tabele,
coloane şi restricţii de integritate, reprezentând modelul logic al datelor.
Modelarea logică presupune organizarea datelor în tabele şi coloane, conform regulilor
modelului relaţional (acesta fiind cel mai popular model de organizare a datelor). După cum se
poate observa din figura 8.1, proiectarea logică a bazei de date presupune transformarea
modelului conceptual al datelor, prin aplicarea regulilor şi conceptelor specifice modelului
relaţional şi a criteriilor de calitate ale modelului logic al datelor, aspecte ignorate în etapa
modelării conceptuale. De exemplu, modelul relaţional nu permite implementarea relaţiilor
multe-la-multe dintre două entităţi de date, motiv pentru care acestea trebuie transformate în
două relaţii unu-la-multe.
Scopul urmărit constă în obţinerea unui model relaţional pur, nealterat de cerinţele
nefuncţionale şi cele de performanţă în stocarea şi accesarea datelor, nici de facilităţile oferite
de diferite SGBDR-uri existente pe piaţă. Toate aceste aspecte vor fi considerate abia la
construirea modelului fizic al datelor. Principalele criterii de calitate utilizate la evaluarea
modelului logic al datelor se referă la completitudine, non-redundanţă, reutilizare, flexibilitate
şi simplitate.
Modelul fizic al datelor, rezultat în urma proiectării fizice, este invizibil utilizatorilor şi
programatorilor. El specifică modul de stocare şi accesare fizică a datelor, utilizând facilităţile
oferite de un anumit SGBD. De exemplu, date din tabele diferite pot fi stocate pe disc
împreună pentru a putea fi transferate în memoria calculatorului printr-o singură operaţiune.
Aşadar, obiectivul principal urmărit în cadrul acestei activităţi constă în optimizarea

performanţelor bazei de date, în ceea ce priveşte stocarea fizică şi accesul la date.
Luarea în considerare a acestor aspecte poate implica „alterarea” modelului logic (adică a
modelului relaţional pur), presupunând uneori prejudicierea aspectelor calitative ale acestuia.
În unele situaţii, timpii de acces ceruţi pot fi obţinuţi prin intermediul indecşilor, însă, de multe
ori, este necesară modificarea structurii logice a datelor, prin procesul denormalizării. Dacă, la
proiectarea schemei logice, s-a urmărit prezervarea integrităţii datelor, prin procesul de
normalizare, acum poate deveni necesară introducerea unui anumit nivel de redundanţă a
datelor sau a câmpurilor calculate în schema bazei de date. Principala provocare constă în
găsirea compromisului între uşurinţa păstrării integrităţii datelor şi performanţele bazei de date,
prin prisma stocării şi accesării datelor. Soluţia ideală ar presupune obţinerea performanţelor
cerute în condiţiile păstrării aspectelor calitative ale modelului logic, ceea ce este posibil
numai în condiţiile separării nivelului logic al bazei de date de cel fizic. O astfel de facilitate
este oferită doar de unele SGBD-uri din categoria Sql-Base, precum Oracle.
De asemenea, la proiectarea fizică vor fi luate în considerare şi facilităţile oferite de
SGBD-ul ales. Diferenţele dintre diferite SGBD-uri se referă adesea la tipurile de date
suportate, reprezentarea sau nu a relaţiilor dintre clase şi subclase, implementarea relaţiilor
recursive. De exemplu, în mediul Oracle nu se poate lucra cu date de tip boolean (logic).
Aşadar, construirea modelului conceptual al datelor constituie doar o primă activitate în
proiectarea bazei de date. În continuare, ne vom concentra asupra analizei cerinţelor sistemului
şi construirea modelului conceptual al datelor, respectiv a diagramei entitate-relaţie. Mai întâi
vom vedea care sunt informaţiile care trebuie colectate, în scopul modelării conceptuale a
datelor, iar apoi care sunt conceptele, regulile şi demersul pentru transpunerea lor în diagrama
entitate-relaţie.
8.2 Culegerea informaţiilor pentru modelarea

conceptuală a datelor
Culegerea cerinţelor informaţionale se realizează în faza de analiză a sistemului, prin
intervievarea utilizatorilor sau pe alte căi. Metodele de determinare a cerinţelor trebuie să fie
orientate, prin întrebările puse, prin anchetele efectuate, şi asupra datelor, nu numai asupra
proceselor şi logicii lor. La început, chiar fără utilizarea unei terminologii de specialitate,
analistul va fi preocupat de modul în care va afla cât mai multe informaţii despre datele
necesare viitorului sistem pentru a funcţiona la parametrii proiectaţi. Întrebările vor fi astfel
formulate încât să se realizeze o bună înţelegere a regulilor după care vor fi folosite datele în
noul sistem, ce politici vor fi utilizate. Nu trebuie, încă, să se intre în detalii de genul: când şi
cum sunt prelucrate sau folosite datele, pentru a se realiza modelarea datelor.
Obiectivele majore ale analizei cerinţelor privind datele vizează1:
 descrierea cerinţelor de date ale sistemului în termenii entităţilor de date;
 colectarea informaţiilor care descriu entităţile de date şi relaţiile dintre ele;
 determinarea tranzacţiilor de prelucrare ce vor fi efectuate asupra bazei de date şi
descrierea interacţiunii dintre tranzacţii şi entităţile de date;
 definirea cerinţelor nefuncţionale ale bazei de date, cum ar fi cele legate de
performanţe, integritate, securitate, administrarea datelor;
 specificarea platformei hardware şi software pe care va fi implementată baza de date.
Modelarea datelor se realizează printr-o combinaţie a punctelor de vedere.
Un prim punct de vedere, formulat în literatură sub numele de metoda top-down, va scoate
în evidenţă regulile derulării activităţii firmei, printr-o înţelegere foarte clară a naturii afacerii,
1. Teorey, T.J. – Database Modeling & Design, Morgan Kaufmann Publishers, Inc, San Francisco, 1999, p. 46-47.
şi nu se va opri asupra detaliilor privind modul în care sunt folosite în organizaţie ecranele,
rapoartele sau documentele.
Literatura2 recomandă mai multe modalităţi de formulare a întrebărilor astfel încât să se
obţină informaţiile necesare. În sinteză, ele pot fi redate astfel:
1. Ce obiecte/subiecte sunt într-o întreprindere? Ce tipuri de persoane, locuri, lucruri,
materiale ş.a. se folosesc sau interacţionează într-o unitate economică şi este necesară
culegerea datelor despre ele pentru a fi păstrate o anumită perioadă de timp? Câte
cazuri (instanţe) pot exista pentru fiecare obiect? – entităţi de date şi descrierea lor.
2. Ce caracteristică (caracteristici) unică (unice) ajută la diferenţierea obiectelor de
acelaşi tip? Elementul care ajută la diferenţierea obiectelor de acelaşi tip are caracter
permanent sau este unul temporar? Elementul caracteristic al unui obiect poate lipsi
atunci când noi ştim cu certitudine că obiectul există? – cheia primară.
3. Ce caracteristici se folosesc pentru descrierea fiecărui obiect? În ce mod se vor
efectua referirile, selecţiile, calificările, sortările şi clasificările obiectelor? Ce trebuie
să se ştie despre fiecare obiect astfel încât să se asigure buna funcţionare a unităţii? –
chei secundare.
4. Cum vor fi folosite datele nominalizate? Care este sursa datelor? Cine va face referire
la ele? Cine le poate modifica sau distruge? Cine nu are drept de folosire a lor? Cine
este responsabil cu corectitudinea datelor? – controale de securitate şi cunoaşterea
celor care au controlul semnificaţiei datelor.
5. Care ar fi perioada de apartenenţă a datelor ce ne interesează? Este necesară
cunoaşterea trendului datelor sau numai valoarea lor la un moment dat şi/sau valorile
estimate/proiectate ale lor? Când o caracteristică a unui obiect se schimbă în timp,
trebuie cunoscută ulterior valoarea anterioară? – cardinalitatea şi dimensiunea
temporală a datelor.
6. Toate cazurile („instanţierile”) sub care poate să existe un obiect sunt identice?
Există obiecte cu un comportament special în organizaţie? Există unele obiecte care
sintetizează sau reflectă forma combinată a altor obiecte mult mai detaliate? –
supertipuri, subtipuri şi agregări.
7. Ce evenimente contribuie la asocierea obiectelor între ele? Ce activităţi fireşti sau
care activități economice presupun folosirea datelor despre câteva obiecte de acelaşi
tip sau de tipuri diferite? – relaţiile, precum şi cardinalitatea şi gradul lor.
8. Fiecare activitate sau eveniment are aceeaşi formă de manifestare sau există şi forme
ce caracterizează anumite circumstanţe? Un eveniment presupune implicarea doar a
unor obiecte asociate sau acestea trebuie să existe în totalitate? Asocierile dintre
obiecte se schimbă de-a lungul timpului? Valorile ce scot în relief caracteristicile unor
date sunt exprimabile în cadrul unor limite? – reguli de integritate, cardinalitate
minimă şi maximă, dimensiunea temporală a datelor.
În afara tehnicilor enumerate anterior, informaţiile necesare construirii modelului datelor
se pot obţine şi prin urmărirea documentaţiei firmei, ecrane, rapoarte, formulare, din interiorul
sistemului. Acest proces este cunoscut în literatura de specialitate sub numele de metoda
bottom-up.
În caseta 8.1 se regăseşte un model de descriere narativă pentru sistemul de gestiune a
clienţilor, prezentat în capitolele anterioare, însă el este uşor orientat spre cerinţele privind
datele. Pe baza lui, vom încerca să punem în evidenţă, pe parcursul paragrafelor următoare,
activităţile desfăşurate pentru construirea DER şi modul în care poate fi citită această
documentaţie.
2. Aranow, E.B. – „Developing Good Data Definitions”, in Database Programming & Design, 2, August 1988, pp.
36-39; Sandifer, A., Von Halle, B. – „A Rule by Any Other Name”, in Database Programming & Design, 4,
March 1991, pp. 11-13; Sandifer, A., Von Halle, B. – „Linking Rules to Models”, in Data and Knowledge
Engineering, 7, 1991, pp. 47-83.
În cazul utilizării produselor CASE, construirea DER porneşte de la analiza diagramelor

fluxurilor de date şi a detaliilor cuprinse în depozitul de metadate.
Caseta nr. 8.1 – Descrierea cerinţelor sistemului de gestiune a clienţilor
A. Descrierea activităților/operațiilor şi a prelucrărilor din sistem
Principalele clase de operații înregistrate în sistemul de gestiune a clienţilor sunt:
1. Primirea comenzilor de la clienţi. Livrarea produselor se face numai în baza unei comenzi, emisă
de un client, iar o comandă poate conţine unul sau mai multe produse. La primirea comenzii,
sistemul va verifica situaţia contului pentru clientul respectiv şi existenţa unor stocuri suficiente
pentru produsele de livrat. În funcţie de rezultatele celor două operaţiuni de verificare, se va stabili
starea comenzii, respectiv de onorat, amânată sau respinsă. Din momentul acceptării comenzii, se
înregistrează obligaţia firmei de a o onora, conform termenelor de livrare specificate.
2. Onorarea comenzilor. În cazul în care comanda a fost acceptată, ea va fi onorată la termenul
specificat prin livrarea produselor şi a cantităţilor prevăzute, operaţiune înregistrată pe baza
facturii emise la depozit. Conform politicii firmei, nu se acceptă decât onorarea printr-o singură
livrare a întregii comenzi, însă pot exista situaţii în care printr-o singură livrare să fie onorate mai
multe comenzi, dar ale aceluiaşi client. De asemenea, întreaga livrare se va efectua de la un singur
depozit, chiar dacă un produs poate exista în stoc la mai multe depozite. Odată cu înregistrarea
livrării, se vor efectua următoarele operaţiuni de actualizare:
 modificarea stării comenzii în onorată, pentru ca sistemul să permită o evidenţă clară a
comenzilor onorate şi a celor de onorat;
 modificarea stocului pentru fiecare produs livrat, în sensul diminuării lui cu cantităţile livrate;
 modificarea soldului clientului, în sensul incrementării lui cu valoarea livrării.
 modificarea tipului clientului, dacă este prima livrare, iar clientul respectiv a fost înregistrat
anterior drept client potenţial.
3. Returnarea produselor de către clienţi. În cazul în care clientul constată unele defecţiuni la
produsele primite sau că ele nu corespund cu cele comandate, el va avea posibilitatea returnării lor,
însoţite de nota de refuz. Sunt posibile atât situaţia returnării parţiale, cât şi integrale, a produselor
livrate. Clientul este obligat să efectueze toate demersurile pentru returnare în cel mult trei zile de
la primirea produselor şi să specifice factura în baza căreia s-a făcut livrarea. În acest fel, sistemul
va fi în măsură să ofere informaţii despre livrările cărora le corespunde o returnare, în vederea
stabilirii persoanelor vinovate. În baza notei de refuz, pentru fiecare returnare se va întocmi o
factură de stornare, parţială sau integrală, de către depozitul care a emis factura, ce corespunde
unei singure livrări. Odată cu înregistrarea facturii de stornare, se va actualiza soldul clientului şi
stocul de produse.
Legendă: roşu = entitate; verde = relaţie; albastru = cardinalitate
B. Descrierea documentelor primare din sistem
În cadrul sistemului, se utilizează următoarele documente:
1. Comanda este emisă de client şi conţine următoarele categorii de date: datele de identificare a
comenzii (numărul şi data), datele de identificare a clientului (numele şi adresa), datele privind
produsele comandate (codul, denumirea, unitatea de măsură, cantitatea comandată) şi condiţiile de
livrare (termenul de livrare).
2. Factura reprezintă documentul de însoţire a produselor livrate şi conţine: datele de identificare a
facturii (număr şi data), datele de identificare a clientului (nume, adresa, cod fiscal, număr registru
comerţ), datele privind produsele livrate (cod, denumire, unitate de măsură, cantitate livrată, preţ,
valoare) şi alte date (valoare TVA, valoare totală factură). Acest document este utilizat şi pentru
consemnarea produselor returnate.
3. Nota de refuz este întocmită de client în cazul returnării parţiale sau integrale a produselor livrate.
Acest document conţine următoarele categorii de date: date de identificare a documentului (număr
şi data), datele de identificare a clientului (numele şi adresa), datele de identificare a produselor
returnate (cod, denumire, unitate de măsură, cantitate returnată) şi alte date (motivele returnării,
numărul facturii cu care au fost livrate anterior produsele).
C. Descrierea principalelor rapoarte generate de sistem
În urma solicitării utilizatorilor, sistemul va furniza următoarele rapoarte:
1. Raportul privind comenzile de onorat este elaborat la începutul fiecărei săptămâni şi conţine
informaţii despre comenzile ce urmează a fi onorate în săptămâna respectivă. Aceste informaţii se
referă la: codul, numele şi adresa clientului; codul, denumirea şi unitatea de măsură a produselor;
cantităţile de livrat; data livrării.
2. Raport privind potenţialii clienţi, întocmit lunar sau la cererea conducerii, conţine informaţii
despre clienţii care au solicitat cataloage de produse, dar care nu au iniţiat încă nici o comanda de
cumpărare. În acest raport se includ numele şi adresa .
3. Raport privind vânzările, întocmit la cererea utilizatorilor, conţine informaţii despre livrările
efectuate într-o perioadă dată, pe depozite sau la nivelul firmei. În raport se includ codul şi numele
depozitului; numărul şi data facturii; codul, denumirea, unitatea de măsură şi preţul produselor;
cantităţile livrate; valoarea vânzării; totalul vânzărilor pe depozite şi totalul general al vânzărilor.
8.3 Introducere în cadrul conceptual al

diagramelor entitate-relaţie (DER)
Deşi diagramele entitate-relaţie (DER) se cunosc de către mulţi specialişti din lumea
bazelor de date, ele constituie unul din conceptele esenţiale ale analizei şi proiectării
structurate şi, ca atare, provin din acest domeniu. De fapt, una din lucrările de referinţă ale lui
P.P. Chen, autorul modelului, este destul de relevantă: Entity-Relationship Approach to
Systems Analysis and Design (Metoda entitate-relaţie în analiza şi proiectarea sistemelor),
apărută în anul 1980, deşi modelul a fost conceput în anii 1976-1977.
După cum reiese și din citirea numelui diagramei, scopul ei este de a evidenţia entităţile
de date (obiectele despre care se solicită păstrarea datelor) şi relaţiile ce există între ele.
De remarcat diferenţa dintre diagrama fluxului de date şi diagrama entitate-relaţie. În timp
ce diagrama fluxurilor de date indică atât procesele de prelucrare, cât şi entităţile de date
(redate sub forma locurilor de stocare), DER tratează doar entităţile de date. Din această cauză,
DER poate fi considerată şi ca diagrama modelului datelor sau diagrama conceptuală a datelor.
În plus, DER evidenţiază şi descrie relaţiile dintre entităţile de date, aspecte ignorate în DFD.
Întotdeauna, crearea unei DER presupune găsirea răspunsului la întrebarea: „Care sunt
entităţile despre care sunt necesare datele de stocat?”. Răspunsul poate fi destul de simplu.
Depinde de aria de întindere a sistemului analizat. Ele ar putea fi: CLIENT, PRODUS,
SALARIAT, STOC, FURNIZOR ş.a.
În sistemul analizat, pentru descrierea DER se apelează la simbolul dreptunghi, pentru
fiecare entitate. Se recomandă ca numele entităţii să fie redat printr-un substantiv la singular
(CLIENT, PRODUS, SALARIAT etc.).
După ce se identifică entităţile, se continuă cu împerecherea lor, fiecare cu fiecare, pentru
a descrie ce relaţii există între ele. Relaţiile dintre entităţi pot fi reprezentate printr-un romb.
De exemplu, pentru a arăta că o anumită vânzare se referă doar la un client, deşi există
mult mai multe acte de vânzare, implicit mai mulţi clienţi, relaţia poate fi redată schematic ca
în fig. 8.2. Acest aspect face referire la cardinalitate, concept care va fi detaliat în unul din
paragrafele următoare şi care este pus în evidenţă prin cele două perechi de valori cuprinse
între paranteze.
(1,1) (0,M)
CLIENT Participă VÂNZARE
Fig. 8.2 DER pentru relaţia Participă între entităţile CLIENT şi VÂNZARE
O vânzare, la rândul ei, constă din unul sau mai multe produse, dar şi produsele pot
constitui subiecte ale mai multor vânzări, deci între entităţile VÂNZARE şi PRODUS ambele
perechi de valori ce reprezintă cardinalitatea vor conţine valoarea M (adică multe). Continuăm
cu descrierea legăturilor/relaţiilor posibile: un PRODUS este în legătură directă doar cu o
singură înregistrare STOC, şi invers. Antrenând în sfera discuţiilor şi comanda de

aprovizionare, COMANDĂ_APROVIZIONARE, şi furnizorul, FURNIZOR, s-ar putea
construi diagrama entitate-relaţie din fig. 8.3.
Entităţile conţin în structura lor atributele (caracteristicile) prin care ele sunt descrise. De
exemplu, entitatea CLIENT este descrisă prin intermediul atributelor nume, adresa, cod fiscal
etc. În acest caz se pune, firesc, întrebarea: dacă o entitate poate avea unul sau mai multe
atribute, relaţiile pot avea atribute? Dacă da, prin ce diferă ele de cele ale entităţilor?
Sublinierile sunt binevenite, întrucât problema pusă în discuţie este de o importanţă deosebită.
O serie de analişti fac distincţie netă între cele două tipuri de atribute, ale entităţilor şi ale
relaţiilor, în timp ce alţii nici nu le sesizează prezenţa. Elementele de derută provin şi din
existenţa unor entităţi despre care se poate spune că descriu relaţii. În exemplul de mai sus,
despre entitatea COMANDĂ_APROVIZIONARE se poate spune că deţine informaţii despre
relaţia „cumpărat de la” dintre PRODUS şi FURNIZOR. Concluzia la care se poate ajunge:
există entităţi „purtătoare” de relaţii dintre alte entităţi; deci, cu alte cuvinte, printr-o entitate se
poate prezenta o relaţie.
(1,1) (0,M)
CLIENT Participă VÂNZARE
(0,M)
Conţine
(1,M)
(0,1) (1,1)
STOC Are PRODUS
(1,M)
Conţine
(0,M)
(1,1) (0,M) COMANDĂ_

FURNIZOR Implică
APROVIZIONARE
Fig. 8.3 Diagrama entitate-relaţie pentru operaţiunea

de vânzare-cumpărare
Analiza entitate-relaţie este o operaţiune deosebit de importantă pentru scoaterea în relief

a datelor, de fapt a structurii lor. În unele metodologii, cum ar fi „ingineria informaţiei”,
aceasta constituie principalul instrument analitic, în timp ce în altele analizele entitate-relaţie
se folosesc în combinaţie cu analizele fluxurilor de date.
8.4 Conţinutul şi etapele activităţii de modelare

conceptuală a datelor
După cum s-a putut observa anterior, DER este construită pe baza a trei tipuri de obiecte:
entităţi de date, relaţii între entităţi şi atribute care descriu entităţile şi relaţiile. Prin urmare,
modelarea conceptuală a datelor presupune parcurgerea următoarelor etape:
 identificarea entităţilor de date,
 descrierea entităţilor de date prin intermediul atributelor,
 definirea relaţiilor dintre entităţi şi
 descrierea relaţiilor, apelând la conceptele grad, cardinalitate, rol, atribut.
În continuare, vom descrie pe larg fiecare din aceste etape, ocazie cu care vom introduce
atât conceptele, cât şi regulile pentru construirea DER.
8.4.1 Identificarea entităţilor de date

După exemplele date, considerăm că semnificaţia entităţii este destul de clară. Să spunem
doar că o entitate este o persoană, un loc, un obiect, eveniment sau concept din domeniul de
activitate al utilizatorului despre care organizaţia doreşte să păstreze anumite date.
Se cuvine precizată diferenţa dintre tipurile entităţilor (entity types) şi cazurile/instanţele
entităţii (entity instances).
Tipul entităţii, cunoscut şi sub numele de clasa entităţii, este o colecţie de entităţi care au
proprietăţi sau caracteristici comune. Fiecărui tip de entitate i se atribuie un nume, conform
descrierilor şi exemplelor anterioare. Cât timp numele reprezintă o clasă sau un set de cazuri, el
este singular. Şi încă o convenţie. Cum referirea generală la elementele ce pot fi catalogate ca
entităţi se face prin noţiunea de obiect (deşi sensul lui poate fi altul în contextul analizei şi
proiectării orientate- obiect), referirea la acesta se va realiza printr-un substantiv la singular. Se
vor folosi litere majuscule, plasate în interiorul dreptunghiului corespunzător entităţii.
O instanţiere a entităţii sau o instanţă, numită de noi, în continuare, caz al entităţii sau
caz, este o manifestare singulară a unui tip de entitate. Un tip de entitate se descrie o singură
dată prin modelul datelor, în timp ce mai multe cazuri ale acelui tip de entitate pot fi
reprezentate prin datele stocate în bazele de date. De exemplu, există o singură entitate
CLIENT, dar ea poate să aibă sute sau mii de cazuri/instanţe stocate în baza de date. Noi vom
utiliza termenii de entitate şi instanţă a entităţii.
În sistemele informaţionale economice, majoritatea entităţilor de date pot fi clasificate în
trei categorii distincte3: resursele utilizate în cadrul firmei, evenimentele (activităţile
economice) în care este angajată firma şi agenţii participanţi la aceste evenimente.
Resursele sunt acele obiecte care au valoare economică şi care sunt necesare pentru
desfăşurarea activităţii din firmă. Stocurile de materii prime şi produse, mijloacele fixe,
disponibilităţile băneşti sunt exemple comune de entităţi-resursă.
Evenimentele se referă la activităţile economice care afectează resursele şi în legătură cu
care conducerea doreşte să se colecteze informaţii, în vederea exercitării funcţiilor de
planificare şi control. Majoritatea evenimentelor reţinute în DER se încadrează în una din
următoarele două categorii: activități/operații economice (economic exchanges) şi obligaţii-
angajamente (commitments). Activitățile economice sunt acele acțiuni care afectează în mod
direct resursele. De exemplu, operația de vânzare implică scăderea stocurilor, iar cea de
încasare va genera o sporire a disponibilităţilor băneşti. În schimb, angajamentele nu afectează
imediat nici o resursă, ele reprezentând o promisiune din partea firmei de participare la
activitatea viitoare. De exemplu, comanda primită de la un client va genera ulterior una sau mai
multe operații de vânzare. În afara faptului că aceste entităţi stochează date despre obligaţiile
firmei derivate din relaţiile de afaceri, ele sunt importante şi în activităţile de control şi
planificare. De regulă, astfel de evenimente preced activitățile economice, iar modelul
conceptual poate îngloba cerinţele de implementare a unor proceduri de control. De exemplu,
nu se va admite derularea unei operații de vânzare fără existenţa în prealabil a unei comenzi.
De asemenea, astfel de entităţi oferă informaţiile necesare activităţii de planificare. Pe baza
informaţiilor despre comenzi se va realiza planificarea vânzărilor.
Agenţii reprezintă persoane sau organizaţii care participă în evenimentele reţinute în
sistem şi în legătură cu care se doreşte memorarea de date, din considerente de planificare,
control sau evaluare. Angajaţii, clienţii sau furnizorii, băncile sunt exemple de entităţi-agent.
3. Romney, M.B., Steinbart, P.J. – Accounting Information Systems, 9th Edition, Prentice Hall, Upper Saddle River,
New Jersey, 2003, p. 116.
Unii autori propun o a patra categorie de entităţi, respectiv locul în care se realizează un
eveniment, în timp ce alţii consideră că nu mai este necesară introducerea acestei categorii,
deoarece astfel de entităţi se referă adesea la resursele angajate în evenimentul respectiv4 sau la
agenţii angajaţi într-un eveniment (completarea noastră). Exemple de astfel de entităţi sunt
depozite, secţie de producţie etc. Depozitul reprezintă locul în care este înregistrată o operație
de intrare sau ieşire a bunurilor materiale din stoc.
În afara acestor entităţi, să le spunem concrete, există şi alte entităţi care nu se încadrează
în nici una din cele trei categorii şi pe care noi le numim entităţi-abstracte. Entitatea
CONSUM-SPECIFIC, care memorează date despre consumurile specifice de materiale pentru
obţinerea fiecărei unităţi de produs finit, reprezintă un astfel de exemplu.
Identificarea entităţilor reprezintă o activitate dificilă, mai puţin formalizată. Realizarea ei
presupune citirea cu atenţie a documentaţiei sistemului, în special a părţii în care sunt descrise
activitățile şi prelucrările din sistem. Se vor urmări activitățile (evenimentele economice) în
legătură cu care se doreşte memorarea de informaţii sau documentele care le consemnează,
resursele şi agenţii implicaţi în derularea fiecărui eveniment reţinut în sistem. De exemplu, din
analiza documentaţiei prezentată în caseta 8.1, pentru evenimentul primirea comenzii se vor
reţine în sistem, pe lângă entitatea-eveniment Comanda, entitatea-agent Client şi entitatea-
resursă Produs.
Entităţile de date potenţiale sunt evidenţiate în caseta 8.1 prin utilizarea caracterelor de
culoare roşie. Ele vor fi trecute într-o listă separată, din care vor fi eliminate cele care se
repetă, fiind păstrată o singură dată, sau cele care apar sub nume diferite, cum este cazul pentru
livrare şi factură.
Rezultatul acestei activităţi este prezentat în caseta 8.2.
Caseta nr. 8.2 – Lista entităţilor de date pentru sistemul de gestiune a clienţilor
Entităţi-eveniment:
1. Comanda,
2. Livrare
3. Returnare
Entităţi-resursă:
4. Produs
Entităţi-agent:
5. Client
6. Depozit.
8.4.2 Descrierea entităţilor de date prin intermediul atributelor

Fiecare entitate are un set de atribute asociate lui.
Un atribut este o proprietate sau o caracteristică a unei entităţi care prezintă interes pentru
organizaţie.
Iată câteva nume de entităţi şi unele dintre atributele lor posibile:
ANGAJAT: MARCA, NUME, CNP, ADRESA, MESERIA
CONT: SIMBOL, TIP, DENUMIRE
Ca şi numele entităţilor, numele atributelor sunt substantive scrise cu majuscule, plasate
în interiorul elipselor, legate de entitatea căreia i se asociază. De multe ori, însă, chiar şi în
cazul folosirii produselor CASE, pentru a nu se încărca o diagramă entitate-relaţie, se evită
prezentarea atributelor. Operaţiunea se face, în schimb, în repository, depozitul de date despre
proiect. Aici orice atribut se descrie separat, ca orice obiect distinct.
Entitatea ANGAJAT poate fi reprezentată în diagramă, conform unuia din modelele
prezentate în figura 8.4. În reprezentarea sub formă de tabel (figura 8.4.a), pe prima linie se
4. Romney, M.B., Steinbart, P.J. – op.cit., p. 117.

află numele entităţii, urmată de atributele care o descriu, primul reprezentând cheia primară,
scrisă cu caractere îngroşate.
CNP
NUME ADRESA
MARCA ANGAJAT MESERIA
a) reprezentarea sub formă de diagramă

ANGAJAT
MARCA
NUME
CNP
ADRESA
MESERIA
b) reprezentarea sub formă de tabel

ANGAJAT(MARCA, NUME, CNP, ADRESA, MESERIA)
c) reprezentarea sub formă de listă
Fig. 8.4 Modele de reprezentare a entităţilor în DER

Cheie-candidat şi cheie-primară
O entitate este descrisă prin intermediul a două tipuri de atribute: identificatori (chei) şi
descriptori. Un identificator sau o cheie candidat este un atribut sau o combinaţie de atribute
prin care se poate identifica în mod unic un caz (o instanţă) a entităţii respective. Fiecare
entitate trebuie să aibă un identificator prin care să se efectueze diferenţierea instanţelor de
acelaşi tip. În schimb, descriptorii specifică proprietăţi ne-unice ale instanţelor unei entităţi.
Redăm mai jos, ca exemplu, entitatea ANGAJAT cu două instanţe. Ele au valori diferite
pentru caracteristica MARCA, aceasta fiind identificatorul entităţii (cheia primară), chiar dacă
este vorba despre doi angajaţi care au acelaşi nume.
MARCA NUME CNP ADRESA MESERIA
1001 Ion I Ion 1700806040021 Florilor, 54 Strungar
1002 Ion I Ion 1670904372271 Nationala,194 Sudor
Sunt entităţi care pot avea două sau mai multe chei-candidat. În exemplul nostru, pot fi
chei-candidat MARCA şi CNP. Atunci când sunt mai multe chei-candidat, analistul trebuie să
decidă care dintre ele va fi folosită drept cheie-primară. O cheie-primară este o cheie-candidat
care a fost selectată pentru a servi ca identificator al instanţelor în cadrul unei entităţi.
Selecţia cheii-primare trebuie efectuată după anumite proceduri5, grupate în caseta 8.3.
Caseta nr. 8.3 – Proceduri de selecţie a cheii-primare
SELECŢIA CHEII-PRIMARE
1. Alegeţi o cheie-candidat care să nu-şi schimbe propria valoare în timpul vieţii cazului/instanţei entităţii
respective.
2. Alegeţi acea cheie-candidat care, pentru fiecare caz/instanţă al/a entităţii, garantează faptul că atributul
sau grupul de atribute are o valoare corectă şi nu este nulă.
5. Bruce, T.A. – Designing Quality Databases with IDEF1X Information Models, Dorset House Publications, New
York, 1992.
3. De evitat aşa-zisele chei-secrete, care preiau în structura lor părţi ale unor atribute care semnifică
clasificări, locuri, coduri ş.a., întrucât ele se pot schimba frecvent, şi nici nu sunt publice.
4. Preferaţi formele scurte în locul celor complexe, formate din mai multe atribute, dacă este posibil.
În reprezentările din DER, în elipsa sau elipsele aferente atributului sau atributelor ce
formează cheia primară, numele respective se subliniază (vezi MARCA din entitatea
ANGAJAT). În cel de-al doilea model, prezentat în figura 8.4, cheia primară este plasată pe a
doua linie şi scrisă cu caractere îngroşate, după numele entităţii respective, iar în al treilea, ea
este subliniată.
Depistarea entităţilor unui sistem nu reprezintă o activitate tocmai uşoară. În multe situaţii
analistul trebuie să decidă dacă un obiect reprezintă o entitate sau un atribut al unei entităţi. Să
luăm, drept exemplu, obiectul LOCALITATE; el reprezintă o entitate sau un atribut? În
sistemul de aprovizionare, el ar putea reprezenta o entitate sau doar atributul entităţii furnizor.
La clasificarea entităţilor şi atributelor, trebuie respectate următoarele două reguli:
 entităţile trebuie să conţină informaţii descriptive. Conform acestei reguli, dacă pentru
un obiect există informaţii descriptive (adică mai multe atribute care să o
caracterizeze), atunci el constituie o entitate, altfel acel obiect va reprezenta un atribut
al unei entităţi. Dacă pentru obiectul LOCALITATE sunt necesare mai multe
informaţii descriptive (cum ar fi judeţul, comuna, codul poştal etc.), atunci el trebuie
clasificat ca entitate. Dacă se solicită doar numele localităţii, atunci el va fi doar un
atribut al unei entităţi (cum ar fi FURNIZOR, ANGAJAT etc.).
 un atribut trebuie ataşat acelei entităţi pe care o descrie în modul cel mai direct. De
regulă, o proprietate se referă la o singură entitate, deci un atribut va fi regăsit doar la o
singură entitate. În sistemul de aprovizionare, de exemplu, entitatea COMANDA nu va
conţine nici numele furnizorului (sau codul acestuia), nici denumirea materialului (sau
codul acestuia); aceste atribute caracterizează mai direct entităţile FURNIZOR,
respectiv Material. Nu intră sub incidenţa acestei reguli sinonimele. Un exemplu, în
acest sens, poate fi atributul adresa: el poate caracteriza atât entitatea ANGAJAT, cât
şi entitatea FURNIZOR.
Aşadar, clasificarea unui obiect ca entitate sau atribut presupune analiza cu multă atenţie a
documentaţiei sistemului în care sunt formulate şi detaliate cerinţele informaţionale.
Identificarea atributelor descriptive ale entităţilor presupune, în primul rând, analiza
documentaţiei privind intrările şi ieşirile din sistem, respectiv a documentelor primare şi a
rapoartelor. Mai concret, în acestă activitate ne interesează cerinţele privind structura acestora.
Aşadar, în caseta 8.1, vor fi analizate părţile B şi C din documentaţie.
O atenţie deosebită trebuie acordată alegerii entităţii căreia îi va fi ataşat fiecare atribut.
Nu trebuie uitat că unele atribute nu reprezintă caracteristica nici unei entităţi, ci a unei relaţii
dintre entităţi, aşa cum este cazul atributelor cantitate comandată sau cantitate livrată. Mai
trebuie reţinut că fiecare atribut trebuie asociat unei singure entităţi şi că atributele calculate,
precum valoarea vânzării, nu vor fi păstrate în DER. Problema includerii câmpurilor calculate
se pune abia în faza proiectării fizice a bazei de date, ea urmând a fi discutată în capitolul
dedicat acestei teme în volumul următor.
Identificarea atributelor necesare sistemului este mult uşurată în cazul utilizării CASE,
deoarece se poate analiza direct structura fluxurilor care accesează locurile de stocare, puse în
evidenţă în diagramele fluxurilor de date.
După identificarea atributelor fiecărei entităţi, trebuie ales unul sau mai multe dintre
acestea care vor juca rolul de cheie primară (simplă sau compusă). Dacă nici unul dintre
atribute nu poate fi cheie, atunci se introduce un atribut special care să joace acest rol. O astfel
de situaţie găsim în exemplul nostru la entitatea Comanda.
Rezultatul acestei activităţi, pentru sistemul analizat, este prezentat în figura 8.5. Cheile
primare sunt evidenţiate prin caractere îngroşate.
O problemă importantă legată de descrierea entităţilor se referă la completitudinea

modelului. Altfel spus, cum putem fi siguri că nu am omis nici un atribut necesar sistemului.
Rezolvarea acestei probleme este extrem de simplă în cazul utilizării produselor CASE,
majoritatea lor oferind facilităţi pentru a verifica dacă diagramele fluxurilor de date, pe de o
parte, şi DER, pe de altă parte, sunt balansate. În urma acestei verificări, analistul va putea să
vizualizeze o listă cu atributele din DER care nu sunt utilizate în diagramele fluxurilor de date
(adică nu apar în structura nici unui flux de accesare a locurilor de stocare), dar şi invers.
Produs Client Comanda
CodProdus CodClient CodComanda
DenProdus NumeClient NrComanda
UM Adresa DataComanda
StocCurent CodFiscal TermenLivrare
PretUnitar Sold StareComanda
LimitaCredit
TipClient
Returnare
NrFactura
Livrare Depozit
DataFactura
NrNotaRefuz NrFactura
DataRefuz CodDepozit
DataFactura
Motivatie NumeDepozit
Figura 8.5 Descrierea entităţilor sistemului de gestiune a clienţilor
8.4.2.1 Atribute cu valori multiple

Un atribut cu valori multiple poate să aibă mai mult decât o valoare pentru fiecare
caz/instanţă al/a tipului entităţii. De exemplu, atributul MESERIA poate lua valorile
ZUGRAV, MOZAICAR, FAIANŢAR, ZIDAR pentru o singură persoană (adică pentru o
singură instanţă a entităţii ANGAJAT). Din această cauză, în timpul proiectării conceptuale se
foloseşte un simbol sau o notaţie specială pentru a reflecta prezenţa atributelor cu valori
multiple sau multivaloare. Sunt utilizabile două modalităţi:
1. Folosirea liniilor duble pentru marcarea conturului elipsei, ceea ce s-ar concretiza într-
o diagramă ca în figura 8.6.
CNP
NUME ADRESA
MARCA ANGAJAT MESERIA
Fig. 8.6 Reprezentarea atributelor cu valori multiple în DER

2. Separarea datelor care se repetă într-o entitate distinctă şi va purta numele de entitate
slabă sau entitate atributivă. Ea va fi unită printr-o legătură de asociere de entitatea
iniţială.
Metoda este folosită şi în cazul câtorva atribute care se repetă laolaltă, formând un grup
repetat. Dacă aceleiaşi entităţi i-am asocia şi atributul ÎNTREŢINUT, care se referă la
persoanele aflate în întreţinere, fiecare dintre acestea fiind reperate prin
NUME_ÎNTREŢINUT, VÂRSTA_ÎNTREŢINUT, noua formă ar putea fi redată prin
modalităţile din figura 8.7, a) şi b).
CNP ADRESA
NUME MESERIA
NUME_ÎNTREÞINUT,
MARCA ANGAJAT VÂRSTA_ÎNTREŢINUT
a) Reprezentarea unui grup repetat, cu valori multiple, prin elipsă dublată

CNP ADRESA
NUME_ÎNTREŢINUT VÂRSTA_ÎNTREŢINUT
NUME MESERIA
MARCA ANGAJAT Are ÎNTREŢINUT

(1,1) (0,M)
b) Reprezentarea unui grup repetat, cu valori multiple, printr-o entitate atributivă

Fig. 8.7 Modalităţi de redare în DER a grupurilor repetate cu valori multiple
Observaţi că separarea grupului repetat conduce la obţinerea unei relaţii a cărei

cardinalitate de partea entităţii atributive este „zero sau multe”, reflectând faptul că unui
angajat îi pot corespunde zero sau mai multe persoane aflate în întreţinere.
8.4.3 Identificarea şi descrierea relaţiilor dintre entităţi

O relaţie reprezintă legătura care există în lumea reală între una, două sau mai multe
entităţi. Relaţiile nu au o existenţă fizică sau conceptuală, ci depind de entităţile asociate.
Altfel spus, existenţa relaţiilor depinde de existenţa entităţilor asociate (în schimb, existenţa
unei entităţi nu depinde de existenţa unei relaţii cu o altă entitate). Un caz particular al unei
relaţii se mai numeşte instanţa relaţiei sau ocurenţa relaţiei. Instanţa relaţiei se referă la
legătura dintre instanţele entităţilor asociate. De regulă, relaţiile sunt redate prin verbe şi sunt
simbolizate printr-un romb. Pentru simplificarea realizării DER, îndeosebi în produsele CASE,
nu se mai foloseşte un simbol anume pentru redarea relaţiei (cum este rombul), ci se scriu
verbele direct pe liniile care surprind existenţa relaţiilor dintre entităţi. Alteori, nici acestea nu
se mai scriu, relaţia fiind evidentă sau lăsată la interpretarea celui ce citeşte diagrama.
Exemple de relaţii sunt: EMITE, între entităţile FACTURA şi FURNIZOR; CONŢINE,
între entităţile FACTURA şi PRODUS; CONDUCE, între entităţile ANGAJAT şi
DEPARTAMENT sau orice verb care descrie conexiunea dintre entităţi. O instanţă a relaţiei
EMITE face referire la legătura dintre o anumită factură şi furnizorul care a emis-o.
Descrierea unei relaţii presupune specificarea următoarelor elemente: gradul (ordinul),
cardinalitatea, rolul şi eventualele atribute care o caracterizează. În continuare, ne vom opri pe
rând asupra fiecărui element descriptiv.
8.4.3.1 Gradul relaţiilor
Gradul unei relaţii (degree of a relationship) este dat de numărul de entităţi care participă
la relaţie. Cele mai întâlnite relaţii în modelele entitate-relaţie sunt:
 unare (grad unu), numite şi recursive sau relaţii ale entităţii cu ea însăşi; acest tip de
relaţie leagă două instanţe ale aceleiaşi entităţi.
 binare (grad doi); acest tip de relaţii sunt de departe cele mai întâlnite în lumea reală.
Mai mult, unele metode utilizează doar relaţii binare la construirea DER.
 ternare (grad trei); relaţiile ternare sunt mai rar întâlnite în lumea reală, ele fiind
utilizate atunci când nu este suficientă utilizarea relaţiilor binare pentru descrierea cu
acurateţe a semanticii relaţiei respective.
Pot exista relaţii cu grade şi mai mari, dar în practică acestea sunt foarte greu de întâlnit.
Cele trei tipuri de relaţii sunt prezentate în exemplul din figura 8.8 (cardinalitatea relaţiilor nu
a fost reprezentată). Asupra relaţiilor ternare vom reveni spre sfârşitul acestui capitol.
Este
PERSOANA căsătorit ANGAJAT Conduce
cu
Unu-la-unu Unu-la-multe
a) Relaţie unară
FURNIZOR Emite FACTURA
b) Relaţie binară
Fig. 8.8 Exemple de relaţii unare, binare, ternare
PIESA
FURNIZOR Transportat DEPOZIT
CANTITATE
c) Relaţie ternară
Fig. 8.8 Exemple de relaţii unare, binare, ternare
Referirea la gradul unei relaţii se mai face şi în alte moduri, cum ar fi ordin sau rang al
relaţiilor.
8.4.3.2 Cardinalitatea relaţiilor

Următorul concept utilizat pentru descrierea relaţiilor îl reprezintă cardinalitatea.
Presupunem că există două entităţi, A şi B, între care există o linie de legătură pentru a marca
relaţia. Cardinalitatea unei relaţii este dată de un număr al cazurilor/instanţelor entităţii B care
pot sau care ar putea să fie asociate cu fiecare caz al entităţii A. Pentru o relaţie dată, trebuie
specificată cardinalitatea pentru fiecare entitate asociată. Cardinalitatea relaţiei pentru o
entitate este sugerată printr-o pereche de valori, în cazul relaţiilor binare trebuind specificate
două astfel de perechi de valori. Valorile care compun o astfel de pereche semnifică:
 cardinalitatea minimă, pentru care sunt posibile valorile „0” sau „1”,
 cardinalitatea maximă, pentru care sunt posibile valorile „1” sau „M” (adică „multe”).
Trimiterea la cardinalitate se face în moduri destul de diferite, în funcţie de notaţia
folosită. Recomandăm citirea cu atenţie a diagramelor şi descifrarea elementelor strict necesare
înţelegerii, îndeosebi pentru reflectarea cardinalităţii. De exemplu, ea poate fi notată cu semne
(0, 1, M, N) sau prin simboluri (linie cu vârf simplu de săgeată pentru 1, linie cu vârf dublu de
săgeată pentru M. Alteori, 1 se reprezintă prin linie simplă şi M prin vârf de săgeată). În multe
materiale, inclusiv produse CASE, se foloseşte notaţia model-date, cunoscută mai mult sub
numele laba-gâştei, conform căreia cardinalitatea se reprezintă prin următoarele simboluri:
obligatoriu 1
opţional 0 sau 1
n obligatoriu multe (n; unde n ia valori de la 1 la M)

n opţional 0 sau multe (n poate lua valori de la 0 la M).
În continuare, vom utiliza semnele 0, 1, M şi N pentru reprezentarea cardinalităţii care,
considerăm noi, face o DER mai uşor de citit.
Să luăm drept exemplu relaţia emitere dintre entităţile FURNIZOR şi FACTURA,
prezentată în figura 8.9. Cardinalitatea minimă a relaţiei pentru entitatea FACTURA este „1”,
iar cea maximă este tot „1”; cardinalitatea relaţiei pentru entitatea FURNIZOR este „0”,
respectiv „M”. Prin urmare, în relaţia emitere, unui furnizor (care este o instanţă a entităţii
FURNIZOR) îi poate corespunde minim „0” şi maxim „multe” facturi (adică instanţe ale
entităţii FACTURA), în timp ce unei facturi îi corespunde un furnizor şi numai unul.
Factura (0,M) (1,1) Furnizor

Emitere
Figura 8.9 Cardinalitatea relaţiilor

Observaţi reprezentarea grafică inversă a cardinalităţii. Cardinalitatea entităţii FACTURA
este plasată lângă entitatea FURNIZOR şi invers. Aplicarea acestei reguli facilitează citirea
unei DER.
Clasificarea relaţiilor în funcţie de cardinalitatea maximă
O importanţă deosebită în proiectarea bazelor de date o prezintă clasificarea relaţiilor în
funcţie de cardinalitate, atât cea maximă, cât şi minimă. Astfel, în cazul relaţiilor unare
(recursive) şi al celor binare, vom avea trei tipuri de relaţii, în funcţie de cardinalitatea
maximă:
 relaţii de tipul 1:1 (unu-la-unu), adică o instanţă a entităţii X este asociată unei singure
instanţe a entităţii Y şi reciproc. Un exemplu se regăseşte în figura 8.10.
 relaţii de tipul 1:M (unu-la-multe), însemnând că o instanţă a entităţii X poate fi
asociată la n instanţe ale entităţii Y, în timp ce o instanţă a entităţii Y va fi asociată
doar unei singure instanţe a entităţii X. Acest tip de relaţii este cel mai des întâlnit în
lumea reală, un exemplu fiind deja prezentat în figura 8.9.
 relaţii de tipul M:N (multe-la-multe), care presupun că orice instanţă a entităţii X poate
fi asociată mai multor instanţe ale entităţii Y, iar o instanţă a entităţii Y poate, de
asemenea, să aibă asociate mai multe instanţe ale entităţii X (vezi figura 8.11).
(1,1) (0,1)
FACTURA Are RECEPŢIE
Figura 8.10 Relaţie de tipul 1:1(unu-la-unu)
(0,M) (1,M)
FACTURA Conţine PRODUS
Figura 8.11 Relaţie de tipul M:N (multe-la-multe)
Relaţii opţionale şi obligatorii

Uneori, relaţiile dintre entităţi nu-şi fac simţită prezenţa în toate situaţiile. Astfel, relaţiile
dintre entităţi pot fi clasificate după cardinalitatea minimă în două tipuri: relaţii opţionale şi
relaţii obligatorii. Altfel spus, participarea unei entităţi într-o relaţie poate să existe sau nu;
participarea opţională este pusă în evidenţă prin cardinalitatea minimă „0”, iar cardinalitatea
minimă „1” semnifică faptul că acea entitate este obligatoriu să participe într-o relaţie.
Cardinalitatea minimă are o semnificaţie importantă în proiectarea bazelor de date, ea
fiind legată de conceptul de restricţie de dependenţă6. Dacă existenţa instanţei x din entitatea
X depinde de existenţa instanţei y din entitatea Y, se spune că x este dependentă de y. Ea
indică dacă o instanţă dintr-o entitate trebuie legată de cel puţin o instanţă a entităţii aflate la
celălalt capăt al relaţiei. Cardinalitatea minimă „0” ne arată că pentru entitatea respectivă poate
exista o instanţă fără ca ea să fie legată de vreo instanţă a celeilalte entităţi. Dimpotrivă, în
cazul cardinalităţii minime „1” fiecare instanţă a entităţii respective trebuie să fie legată de cel
puţin o instanţă a celeilalte entităţi. Rezultă că ştergerea entităţii y atrage automat ştergerea
6. Korth, H.F., Silberschatz, A. – Sistemes de gestion de bases de donees, McGraw-Hill, Paris, 1988, citat în
Fotache, M. – Baze de date relaţionale. Organizare şi interogare, Ed. Junimea, Iaşi, 1996, p. 69.
entităţii x din baza de date. Se spune că existenţa instanţei x depinde de existenţa instanţei y.
Entitatea Y este denumită entitate dominantă, iar entitatea X este numită entitate dependentă.
Revenind la exemplul din figura 8.9, se observă că, în relaţia Emitere, entitatea
FACTURA are cardinalitatea minimă „1”, deci este obligatorie participarea oricărei instanţe
(facturi) într-o relaţie, în timp ce cardinalitatea minimă pentru entitatea FURNIZOR este „0”,
ceea ce înseamnă că nu este obligatorie participarea fiecărui furnizor în relaţia emitere (va
putea exista un furnizor care să nu aibă în corespondenţă nici o factură). De asemenea, putem
spune că entitatea FACTURA este dependentă de entitatea FURNIZOR, sau că FURNIZOR
este entitatea dominantă. Ştergerea unei facturi nu atrage automat şi ştergerea furnizorului care
a emis-o, deoarece este posibil ca în baza de date să mai rămână facturi primite de la furnizorul
respectiv. În schimb, ştergerea unui furnizor atrage după sine ştergerea tuturor facturilor
aferente acestuia. De asemenea, adăugarea unei facturi noi poate fi făcută numai dacă ea este
legată de un furnizor.
Cardinalitatea minimă poate fi redată şi grafic. Cercul suprapus pe latura entităţii indică,
de fapt, poziţia zero (valoarea minimă poate fi şi zero), conferind relaţiei caracterul opţional.
Simbolul folosit pentru a marca relaţiile obligatorii este acelaşi cerc, cu deosebirea că este
haşurat.
8.4.3.3 Rolul relaţiilor
Rolul defineşte funcţia care atrage două sau mai multe entităţi într-o relaţie. Pentru o
relaţie se poate specifica rolul fiecărei entităţi asociate, iar prin combinarea rolurilor jucate de
entităţile asociate se obţine numele relaţiei. De exemplu, revenind la relaţia dintre FACTURA
şi FURNIZOR, numele acestei relaţii poate fi descris sub forma emite/este emisă, după cum se
poate observa şi în figura 8.12. Rolul entităţii FURNIZOR este Emite, iar cel al entităţii
FACTURA este este emisă.
Factura (0,M) Emite/este (1,1) Furnizor
emisa
Figura 8.12 Rolul relaţiilor

Specificarea rolurilor jucate de entităţi în DER nu prezintă o importanţă deosebită în
proiectarea bazelor de date, însă ajută la clarificarea aspectelor semantice ale modelării datelor,
precum şi la citirea relaţiilor. Relaţia dată poate fi citită în ambele sensuri, după cum urmează:
„Fiecare factură este emisă de un furnizor şi numai unul.”
„Fiecare furnizor emite 0 sau mai multe facturi.”
Toate relaţiile dintre entităţi pot fi exprimate sintetic prin două fraze scurte, fiecare fiind
inversa celeilalte, dar fiecare încadrându-se în forma generală:
„Fiecare nume-entitate
descrierea-relaţiei-lângă-entitate
marcaj-legătură-celălalt-capăt
celălalt-nume-entitate”.
În exemplul nostru, am utilizat două nume pentru a pune în evidenţă rolul fiecărei entităţi
în cadrul relaţiei. Unele metode recomandă utilizarea unui singur nume pentru o relaţie, stabilit
prin alegerea unui verb care să reflecte logica legăturii dintre entităţile respective. De exemplu,
pentru aceeaşi relaţie, în figura 8.8 am utilizat numele Emitere. În această variantă, rolul
fiecărei entităţi nu mai este specificat în mod explicit, însă el rezultă implicit din numele
atribuit relaţiei. În lipsa unui verb semnificativ pentru logica relaţiei, se poate alege un nume
format din iniţialele entităţilor asociate. În cazul în care se utilizează doar o linie simplă pentru
reprezentarea relaţiilor (fără simbolul romb), rolurile sunt plasate pe linie, de o parte şi/sau de
cealaltă a ei.
Necesitatea specificării rolului relaţiilor este evident atunci când între două entităţi există
mai multe relaţii. De exemplu, s-ar putea spune că „FURNIZOR oferă PRODUS”, dar şi
„PRODUS este cumpărat de la FURNIZOR”, ceea ce s-ar putea reprezenta ca în fig. nr. 8.13.
Oferă
(0,M) (0,M)
PRODUS FURNIZOR
(0,M) (0,M)
Este
cumpărat
de la
Fig. 8.13 Descrierea relaţiilor multiple între două entităţi
8.4.3.4 Relaţii purtătoare de atribute (entităţi asociative)

În sfârşit, descrierea relaţiilor impune şi specificarea atributelor asociate, dacă ele există.
Considerăm concludente următoarele exemple:
1) Cazul prezentat la relaţia ternară, în figura 8.8(c). Se observă că relaţia ternară nu
înseamnă acelaşi lucru cu trei relaţii binare. De exemplu, atributul CANTITATE este asociat
relaţiei Transportă. Atributul nu poate fi asociat nici uneia dintre cele trei posibile relaţii
binare dintre cele trei tipuri de entităţi (FURNIZOR, PIESA, DEPOZIT), întrucât
CANTITATE reprezintă o valoare atribuită unei PIESA anume transportată de la un
FURNIZOR anume la un DEPOZIT anume.
2) Cazul „Are componente” (Has Components) al relaţiei unare multe-la-multe, redat în
figura 8.14.
(0,M)
Are
ARTICOL componente CANTITATE
(0,M)
a) Relaţie unară multe-la-multe

A B
V (1) X (2) Y (1) X (1) Y (2) Z (1)
U (2) Z (1) U (3) T (1) U (3) V (1)
b) Două cazuri/instanţe ale relaţiei a)

Fig. 8.14 Relaţia unară de tip „Are componente”
Notă: Valorile din parantezele ataşate componentelor reprezintă cantităţile înglobate în componenta
superioară.
Să punem în discuţie un alt exemplu, cel al relaţiei Emite dintre entităţile FACTURA şi
PRODUS. Un produs poate fi conţinut în mai multe facturi, după cum şi o factură poate
conţine mai multe produse. Prezentăm, mai jos, câteva dintre datele concrete:
NUMĂR_FACTURĂ DENUMIRE_PRODUS CANTITATE
1111 Produs A 25
1111 Produs B 15
2222 Produs A 70
2222 Produs C 40
Din analiza cazurilor rezultă că factura 1111 conţine două produse, A şi B, cu cantităţi
diferite (25, respectiv 15), deci CANTITATE nu este o proprietate a entităţii FACTURA. Dar
nu este nici o proprietate a entităţii PRODUS, cât timp acelaşi produs poate fi conţinut în două
sau mai multe facturi cu cantităţi diferite (produsul A se regăseşte pe ambele facturi, cu
cantităţile 25 şi 70). În schimb, CANTITATE este o proprietate a relaţiei dintre FACTURA şi
PRODUS. Atributul se asociază relaţiei şi se prezintă sub formă de diagramă, ca în figura 8.15.
CANTITATE
(0,M) (1,M)
FACTURA Conţine PRODUS
Fig. 8.15 Asocierea unui atribut la o relaţie
De aici rezultă un caz aparte de entitate, numită gerundivă sau compusă sau asociativă
care, de fapt, este o relaţie folosită de analist în model ca un tip de entitate. În astfel de cazuri,
se foloseşte un simbol special: dreptunghi cu romb în interior, în care se scrie numele entităţii
(fig. 8.16).
CANTITATE
(0,M) (1,M)
FACTURA Con ţine PRODUS
Fig. 8.16 Redarea unei entităţi gerundive (asociative)
Relaţii purtătoare de atribute pot fi întâlnite doar în cazul relaţiilor de tipul „multe-la-
multe” sau al relaţiilor ternare. Relaţiile binare de tipul „unu-la-unu” sau „unu-la-multe” nu pot
avea atribute.
8.4.4 Modelul general al DER pentru sistemele informaţionale

În figura 8.17, este prezentat un model general al DER pentru sistemele informaţionale
economice, care evidenţiază relaţiile existente între cele trei tipuri de entităţi, precum şi
cardinalitatea tipică a acestor relaţii. Prin acest model7 dorim să oferim un punct de plecare în
modelarea conceptuală a datelor din sistemele informaţionale economice şi construirea DER.
Desigur, trebuie luate în considerare şi analizate cu atenţie particularităţile ce pot interveni în
regulile de derulare a afacerilor din firme.
7. Modelul prezentat este adaptat şi completat după Romney, M.B., Steinbart, P.J. – op.cit.
(1,1)
Particip ă Agent extern
(0,M)
(1, ?) (0,M)
Obţinere
Resursa A Intrare
resursã A
(?,?) (1,1)
(0,M) Particip ă
Dualitate Agent intern
(0,M)
Particip ă (1,1)
(?,?)
Furnizare
Resursa B Ieşire
(1, ?) (0,M) resursă B
(0,M)
Particip ă Agent extern

(1,1)
Fig. 8.17 Modelul general al DER pentru sistemele informaţionale economice
În figura 8.17 se regăsesc toate cele trei tipuri de entităţi specifice sistemelor
informaţionale economice: evenimente, resurse şi agenţi. La identificarea entităţilor trebuie
acordată o atenţie deosebită obiectelor (evenimente, resurse sau agenţi) diferite dar omogene
(adică descrise de aceleaşi atribute), care pot fi reunite în aceeaşi entitate. De exemplu,
entităţile-resursă MATERIAL, OBIECT_INVENTAR_DEPOZIT şi PRODUS_FINIT pot fi reunite
în aceeaşi entitate, numită eventual BUN_MATERIAL, deoarece toate aceste resurse sunt
descrise de regulă prin aceleaşi atribute (Cod, Denumire, UM, Preţ, Stoc). Asemănător, pot fi
reunite entităţile-agent FURNIZORI şi CLIENŢI.
În modelul propus, se regăsesc trei tipuri de relaţii din punctul de vedere al entităţilor
implicate. În primul rând, fiecare entitate-eveniment este legată de o entitate-resursă. De
exemplu, entitatea-eveniment VÂNZARE este legată de entitatea-resursă PRODUS, pentru a
reflecta diminuarea stocului de produse finite. Un alt eveniment, COMANDA, care reflectă un
angajament pe viitor al firmei, va fi legat tot de resursa PRODUS, ce va fi afectată la o dată
ulterioară prin respectarea angajamentului.
În al doilea rând, fiecare entitate-eveniment este legată de două entităţi-agent. Agentul
intern este reprezentat de angajatul care are responsabilitatea gestionării resursei afectate sau a
autorizării evenimentului respectiv şi care, implicit, va avea dreptul să introducă sau să
modifice datele în baza de date. De regulă, ea este regăsită sub forma entităţii UTILIZATOR,
care va avea ca instanţe angajaţii firmei, inclusiv datele privind responsabilităţile acestora. Tot
ca agenţi interni se vor regăsi şi diferitele subunităţi organizatorice implicate în efectuarea
operațiilor interne. De exemplu, în evenimentul consum de materiale sunt implicate depozitul,
care eliberează materialele, şi departamentul care le solicită. Agentul extern se referă la terţul
din afara firmei care este implicat în derularea evenimentului respectiv. Entitatea-eveniment
VÂNZARE va fi legată de entitatea-agent CLIENT.
Al treilea tip de relaţie se referă la legăturile dintre entităţile-eveniment, care reflectă
natura economică duală a majorităţii evenimentelor din cadrul sistemelor informaţionale
economice de tipul intrare-ieşire. De exemplu, evenimentul VANZARE, care implică
decrementarea resursei PRODUS, este legat de evenimentul ÎNCASARE, care presupune
incrementarea resursei FOND_BĂNESC. Se reflectă astfel principiile de desfăşurare a
afacerilor care implică adesea consumarea unor resurse în vederea obţinerii altora. De
asemenea, pot să apară relaţii între entităţile-eveniment care reflectă un angajament pe viitor şi
cele care privesc activitățile economice realizate în baza angajamentului. O astfel de relaţie
este cea dintre entităţile COMANDA şi VÂNZARE. Prin introducerea unor asemenea relaţii în
modelul conceptual al datelor şi specificarea cardinalităţii, se poate arăta faptul că nu se
acceptă înregistrarea unei operații (vânzări) fără existenţa unui angajament anterior (comanda).
Alte aspecte relevante privind modul de desfăşurare a afacerilor de către organizaţii sunt
reflectate prin cardinalitatea relaţiilor. În continuare, vom pune în discuţie cardinalitatea pentru
fiecare dintre cele trei tipuri de relaţii amintite anterior.
Cardinalitatea relaţiilor dintre entităţile agent şi eveniment
În figura 8.17 se poate observa că atât minimul, cât şi maximul cardinalităţii asociate
entităţilor-eveniment în fiecare relaţie eveniment-agent este 1 (după cum ştiţi deja,
cardinalitatea este reprezentată invers în diagramă). Această situaţie este întâlnită aproape
întotdeauna, reflectând faptul că trebuie să existe un agent, şi numai unul, care să fie implicat
în orice eveniment pentru ca organizaţia să evidenţieze responsabilitatea derulării
evenimentului respectiv. O instanţă VÂNZARE trebuie să aibă în corespondenţă un CLIENT şi
numai unul, astfel încât să se poată identifica în mod cert creanţa creată. Aceeaşi cardinalitate
va fi şi în relaţia cu agentul intern, pentru a se putea şti cu exactitate angajatul responsabil de
operaţia respectivă de vânzare.
Perechea (0,M) reprezintă cardinalitatea tipică asociată entităţii agent în relaţiile agent-
eveniment. Cardinalitatea maximă M asociată unui agent intern este pe deplin justificată,
deoarece este de aşteptat ca un angajat să autorizeze mai multe evenimente de un anumit tip
(de exemplu vânzări). De asemenea, un agent extern va avea cardinalitatea maximă M pentru
că organizaţia se angajează în relaţii de afaceri repetate cu acelaşi furnizor sau client.
Cardinalitatea minimă 0 este explicată prin două raţionamente. Mai întâi, organizaţia doreşte să
poată adăuga date despre un client sau furnizor chiar dacă el nu a fost implicat încă în nici un
eveniment. Cel de-al doilea motiv este legat de faptul că entităţile-eveniment reprezintă de fapt
fişiere de tranzacţii (sau temporare), în timp ce entităţile-agent sunt fişiere nomenclatoare (sau
permanente). La anumite intervale regulate de timp (de exemplu, la sfârşitul anului), conţinutul
fişierelor de tranzacţii este şters după ce s-a efectuat arhivarea, în timp ce informaţiile despre
agenţi sunt permanente. Prin urmare, la începutul unei perioade de timp (de exemplu, la
începutul anului) nici un agent nu va avea în corespondenţă vreun eveniment.
Cardinalitatea relaţiilor dintre entităţile resursă şi eveniment
După cum rezultă din figura 8.17, perechea (0,M) este cardinalitatea tipică asociată
entităţilor-resursă în relaţiile resursă-eveniment, din aceleaşi motive prezentate anterior pentru
entităţile-agent. Un anumit produs poate face obiectul mai multor operaţii de vânzare, la fel
cum poate să nu se regăsească pe nici una.
Cardinalitatea minimă asociată entităţilor-eveniment este de regulă 1, ceea ce înseamnă că
fiecare eveniment trebuie să implice cel puţin o instanţă a entităţii-resursă cu care este în
legătură, adică el va afecta cel puţin o resursă. O vânzare va conţine cel puţin un produs, iar o
încasare va afecta cel puţin un cont de disponibilităţi. Excepţii de la această regulă generală
apar în cazul relaţiilor alternative dintre entităţi, însă aceste tipuri de relaţii le vom prezenta în
paragraful următor. În schimb, nu există o regulă generală în ce priveşte cardinalitatea maximă
asociată entităţilor-eveniment, motiv pentru care am apelat la simbolul „?”. Ea depinde de
natura resursei implicate sau de regulile de desfăşurare a afacerilor din organizaţie. De
exemplu, o încasare va avea în corespondenţă un singur cont de disponibilităţi băneşti
(cardinalitatea maximă va fi 1), în timp ce o vânzare poate conţine mai multe produse
(cardinalitatea maximă va fi M).
Cardinalitatea relaţiilor dintre entităţile eveniment
Pentru relaţiile dintre două entităţi-eveniment orice cardinalitate este posibilă, neexistând
reguli generale, tipice. Totuşi, o regulă ce poate fi reţinută pentru relaţiile dintre două
evenimente este cea care relevă caracterul temporal: cardinalitatea minimă a evenimentului
care se realizează primul în timp va fi 0, deoarece la momentul respectiv celălalt eveniment nu
a avut loc; cel mai adesea, dar nu întotdeauna, cardinalitatea minimă corespunzătoare celui de-
al doilea eveniment ca desfăşurare în timp va fi 1, reflectând faptul că desfăşurarea celui de-al

doilea eveniment poate avea loc numai dacă primul eveniment s-a realizat anterior. Pentru
exemplificare, să luăm relaţia dintre evenimentele COMANDA şi VÂNZARE: ca ordine de
desfăşurare, operaţiunea de vânzare are loc după primirea comenzii, deci entitatea COMANDA
va avea cardinalitatea minimă 0, dat fiind că operaţiunea de vânzare are loc ulterior şi, până
atunci, comanda respectivă nu va avea în corespondenţă nici o vânzare, iar entitatea
VÂNZARE va avea cardinalitatea minimă 1. Totuşi, dacă regulile afacerii din organizaţie
acceptă derularea de vânzări fără primirea unei comenzi ferme în prealabil, atunci şi
cardinalitatea minimă asociată entităţii VÂNZARE va fi 0.
Acum, după ce ne-am familiarizat cu conceptele utilizate pentru descrierea relaţiilor dintre
entităţi, precum şi cu modelul general al DER pentru sistemele informaţionale economice,
suntem în măsură să finalizăm DER-ul pentru sistemul nostru. Rezultatul este prezentat în
figura 8.18.
Câteva comentarii mai sunt necesare în legătură cu modul de construire a diagramei.
Mai întâi, identificarea relaţiilor dintre entităţi reprezintă o activitate extrem de
anevoioasă, solicitând multă experienţă din partea analistului. Dificultatea este cu atât mai
mare, cu cât în diagramele fluxurilor de date şi în depozitul de date nu se face nici o referire la
relaţiile dintre entităţi. Singurul model care le evidenţiază este diagrama entitate-relaţie. Pe de
altă parte, orice relaţie specificată în plus sau în minus va avea consecinţe, uneori grave, asupra
proiectării bazei de date. Un demers mai formal nu există, aşa că nu ne rămâne decât să citim
cu multă atenţie documentaţia sistemului.
În caseta 8.1, partea de text care sugerează relaţii între entităţi este scrisă cu caractere de
culoare verde. Acelaşi text va sugera şi rolul (numele) fiecărei relaţii.
În al doilea rând, după identificarea unei relaţii, se va mai citi o dată textul pentru a
desprinde informaţiile necesare pentru stabilirea cardinalităţii relaţiei. În cazul în care nu
găseşte astfel de informaţii, analistul va trebui să le afle şi să completeze documentaţia.
În al treilea rând, se poate observa că, odată cu introducerea relaţiilor, s-au specificat şi
atributele asociate relaţiilor.
În caseta 8.1, informaţiile relevante pentru stabilirea cardinalităţii relaţiilor sunt scrise cu
caractere de culoare albastră.
Odată ce am obţinut forma finală a DER pentru sistemul nostru, se cuvine să mai zăbovim
un pic asupra legăturii dintre diagrama fluxurilor de date şi DER. Dacă vom compara diagrama
din figura 8.18 cu diagrama de nivel 0 din caseta 5.4, vom constata că există multe asemănări,
dar şi unele diferenţe. Între cele două modele există o legătură directă, în sensul că entităţile de
date se vor regăsi în diagrama fluxurilor de date sub forma locurilor de stocare. În general, se
poate urmări obţinerea unei relaţii biunivoce între mulţimea entităţilor de date şi cea a locurilor
de stocare, dar nu este obligatorie.
Dacă DER conţine prea multe entităţi, prevederea a câte unui loc de stocare pentru fiecare
din ele ar spori complexitatea şi încărcarea diagramelor fluxurilor de date, nu doar prin
numărul mare de locuri de stocare, ci şi printr-un număr mult mai mare de fluxuri de accesare a
lor. Aşadar, se poate opta pentru gruparea logică a două sau mai multe entităţi, cărora să le
corespundă un singur loc de stocare. În exemplul nostru, entităţile Livrare, Returnare şi
Produs au fost reunite într-un singur loc de stocare, Nomenclator produse.
Comanda
Returnare
CodComanda Livrare NrFactura
NrComanda (1,M) (0,1) (1,1) (0,1) DataFactura
DataComanda Onorare NrFactura Corespunde
DataFactura NrNotaRefuz
TermenLivrare DataRefuz
StareComanda (0,M) (0,M) Motivatie
(0,M) (0,M)
Cantitate
Emite returnata
Emite Conţine
Stoc
(1,1) curent
(1,1) Depozit (1,M)
(1,M)
Client CodDepozit Produs
NumeDepozit Este în
CodClient stoc CodProdus
NumeClient (0,M) DenProdus
Adresa UM
CodFiscal Conţine PretUnitar
(1,M)
Sold
LimitaCredit
TipClient Cantitate
comandata
Figura 8.18 Diagrama entitate-relaţie pentru sistemul

de gestiune a clienţilor
Pe de altă parte, se poate observa că există locuri de stocare care nu-şi găsesc
corespondentul în DER, cum ar fi Promoţii şi Catalog. Explicaţia este următoarea: funcţiile
(procesele de prelucrare) care accesează acele locuri de stocare nu sunt vizate pentru
informatizare, deci nu prezintă interes imediat din perspectiva dezvoltării sistemului
informatic. Prin urmare, s-a considerat că nu este nevoie de memorarea datelor în legătură cu
cele două entităţi. Aceste date se vor regăsi doar pe hârtie.
Legătura strânsă dintre cele două tipuri de diagrame, şi într-un sens, şi în celălalt, reclamă
construirea lor în paralel. Se va începe mai întâi cu diagrama fluxurilor de date pentru a pune
în evidenţă principalele funcţii şi procese din sistem, însă, când se ajunge la un nivel suficient
de detaliere, se poate trece la construirea DER. Apoi se revine cu modificări şi completări
asupra diagramei fluxurilor de date. Astfel de treceri, de la un model la altul, vor fi realizate ori
de câte ori este nevoie.
8.4.5 Alte situaţii întâlnite în modelarea conceptuală a datelor

Scopul diagramelor entitate-relaţie este de a surprinde cele mai complete sensuri posibile
ale datelor necesare sistemului informaţional din organizaţie. Aplicarea tuturor conceptelor
prezentate anterior permite descrierea suficient de clară a entităţilor şi relaţiilor identificate în
domeniul analizat, însă, problematica poate fi mult mai amplă decât a fost redată în capitolul
de faţă. În acest paragraf, vom reda alte câteva situaţii ce pot fi întâlnite în lumea modelată şi
maniera în care ele pot fi reprezentate în DER.
8.4.5.1 Cardinalitatea relaţiilor ternare
Dacă, în cazul unei relaţii de ordinul 2, avem trei tipuri de relaţii din punctul de vedere al
cardinalităţii maxime, pentru relaţiile ternare vom avea patru tipuri de relaţii: 1:1:1 (unu-la-
unu-la-unu), 1:1:M (unu-la-unu-la-multe), 1:M:N (unu-la-multe-la-multe) şi M:N:P(multe-la-
multe-la-multe). Generalizând, se poate afirma că o relaţie de ordinul n va înregistra n+1 tipuri
de relaţii din punctul de vedere al cardinalităţii maxime, cu excepţia relaţiilor unare.
Disciplina
Profesor Examineaza Student

1 N
Fig. 8.19 Exemplu de relaţie ternară de tipul 1:M:N

În figura 8.19 este prezentată un exemplu de relaţie ternară de tipul 1:M:N. Această relaţie
poate fi citită astfel:
„un profesor poate examina un student la mai multe discipline” (de aici M-ul din partea
entităţii DISCIPLINA),
„un profesor examinează la o disciplină mai mulţi studenţi”,
„un student este examinat la o disciplină de un singur profesor”.
Se observă că, la determinarea cardinalităţii, se ia în considerare numărul maxim (unu sau
multe) de instanţe ale unei entităţi care corespund unei perechi formate din câte o instanţă a
celorlalte două entităţi. De exemplu, întrebarea poate fi formulată astfel: Câte discipline pot
corespunde unui anumit profesor şi unui anumit student?
8.4.5.2 Relaţii redundante
Două sau mai multe relaţii sunt considerate redundante atunci când ele sunt utilizate
pentru a reprezenta acelaşi concept. Un exemplu de relaţie redundantă este cea dintre
FURNIZOR şi DOCUMENT_PLATĂ din figura 8.20. Această relaţie este mai curând una
indirectă, dacă plăţile sunt urmărite pe fiecare factură în parte. În momentul în care unei plăţi i
se asociază o anumită factură, implicit i se va asocia şi furnizorul care a emis factura
respectivă, prin intermediul legăturii dintre entităţile FURNIZOR şi FACTURA. Dacă s-ar ţine
o evidenţă globală a datoriilor către furnizori, neinteresând factura ce este plătită, ci doar
furnizorul, atunci ar trebui eliminată relaţia dintre FACTURA şi DOCUMENT_PLATĂ.
Oricum, indiferent de tipul de evidenţă utilizat în firmă, una din cele două relaţii trebuie
eliminată. Existenţa unei relaţii redundante poate fi sesizată şi din urmărirea rolurilor celor trei
relaţii, observându-se că ambele relaţii au acelaşi nume, respectiv Se plăteşte.
(1,1) Se (0,M) DOCUMENT_
FURNIZOR plăteşte PLATĂ
(1,1) (0,M)
(0,M) (1,M) Se
Emite FACTURA plăteşte
Fig. 8.20 Exemplu de relaţie redundantă

În schimb, în figura 8.21 nici una dintre cele trei relaţii nu este redundantă atât timp cât
membrii unei asociaţii pot locui în altă localitate decât cea în care îşi are sediul asociaţia. Dacă
ar exista restricţia ca toţi membrii unei asociaţii să locuiască în localitatea de reşedinţă a
asociaţiei, atunci relaţia dintre MEMBRU şi LOCALITATE ar fi redundantă.
(0,M) (1,1)
MEMBRU Locuieşte LOCALITATE
(1,M) (1,1)
(0,M) (0,M) Are

Aparţine ASOCIAŢIE Sediul
în
Fig. 8.21 Exemplu de relaţii neredundante

Pentru o mai bună clarificare, revenim la sistemul de gestiune a relaţiilor cu clienţii şi la
DER prezentată în figura 8.18. La o primă vedere, s-ar putea considera că unele relaţii au fost
omise. Este vorba, îndeosebi, despre relaţia dintre entităţile Livrare şi Client, considerându-se
că, prin lipsa ei, nu se va putea şti care este clientul către care s-a efectuat o anumită livrare.
O astfel de observaţie nu ar fi tocmai corectă, atât timp cât între entităţile Livrare şi Comandă,
pe de o parte, Comanda şi Client, pe de altă parte, există relaţii. Vom putea face legătura între
o livrare şi un client, dar indirect, prin intermediul entităţii Comanda.
Observaţia ar fi fost întemeiată dacă firma ar fi acceptat livrări şi fără primirea prealabilă
a unei comenzi. Într-o asemenea situaţie, legătura indirectă între client şi livrare nu mai poate fi
stabilită, atât timp cât comanda poate să lipsească. Atunci, cardinalitatea relaţiei dintre Livrare
şi Comanda ar trebui modificată, în sensul înlocuirii cardinalităţii minime „1”, aflată în partea
entităţii Comanda, cu „0”, şi adăugării relaţiei dintre entităţile Livrare şi Client.
Să mai spunem că relaţii redundante pot apare numai în modelul fizic al datelor, în scopul
creşterii vitezei de acces la baza de date. Însă, acum ne aflăm abia în faza elaborării modelului
conceptual al datelor.
Rezumat
Aplicarea principiului abstractizării presupune modelarea datelor pe trei niveluri: conceptual, logic
şi fizic. Modelarea pe aceste trei niveluri de abstractizare este justificată de necesitatea stăpânirii
complexităţii sistemului, analistul având posibilitatea de a se concentra, la un moment dat, doar asupra
anumitor aspecte, ignorându-le momentan pe celelalte. În faza de analiză se efectuează doar modelarea
conceptuală a datelor, celelalte două modele fiind realizate pe parcursul fazei de proiectare.
Modelarea conceptuală a datelor presupune transpunerea exactă a realităţii din domeniul analizat,
fără a lua în considerare cerinţele specifice unui model de organizare a datelor sau criteriile de
performanţă privind stocarea şi accesarea datelor. Modelul rezultat trebuie să reflecte regulile de derulare
a afacerilor în firma respectivă sub forma entităţilor de date şi a legăturilor dintre ele.
Pentru reprezentarea modelului conceptual se apelează la diagrama entitate relaţie (DER),
construită prin utilizarea a trei tipuri de obiecte: entităţi de date, relaţii între entităţi şi atribute.
Realizarea DER implică parcurgerea a patru etape: identificarea entităţilor de date, descrierea lor prin
intermediul atributelor, definirea relaţiilor dintre entităţi şi descrierea lor prin specificarea eventualelor
atribute, dar şi prin apelarea la conceptele grad, cardinalitate şi rol.
O entitate este o persoană, un loc, un obiect, eveniment sau concept din domeniul de activitate a
utilizatorului despre care organizaţia doreşte să păstreze anumite date. Entităţile pot fi încadrate în una
din următoarele patru categorii: resurse, evenimente, agenţi şi entităţi-abstracte.
O relaţie reprezintă legătura care există în lumea reală între una, două sau mai multe entităţi, ea
neavând o existenţă fizică sau conceptuală de sine stătătoare, ci depinde de entităţile asociate. Din acest
motiv, identificarea relaţiilor reprezintă o activitate dificilă, care solicită multă experienţă şi atenţie.
Odată identificate, relaţiile sunt descrise prin intermediul gradului, cardinalităţii, atributelor şi rolului.
1. Explicaţi de ce este importantă modelarea conceptuală a datelor ca activitate de dezvoltare a
sistemelor informaţionale.
2. Realizaţi o comparaţie între diagrama fluxurilor de date şi diagrama entitate-relaţie.
3. Enumeraţi şi definiţi principalele concepte utilizate în modelarea conceptuală a datelor.
4. Care sunt tipurile de relaţii ternare din punctul de vedere al cardinalităţii?
5. Explicaţi cum poate fi pus în evidenţă caracterul temporal al legăturii dintre două entităţi-eveniment.
6. Explicaţi de ce relaţia între entităţile Livrare şi Produs ar fi redundantă, dacă ar fi introdusă în DER
pentru sistemul de gestiune a clienţilor, prezentată în figura 8.18. Specificaţi ce modificare trebuie
realizată în politica de afaceri a firmei, inclusiv în DER din figura 8.18, pentru ca relaţia dintre cele
două entităţi să nu mai fie redundantă.
Probleme de echipă
1. Redactaţi o scurtă documentaţie asupra unei componente, la liberă alegere, a sistemului
informaţional dintr-o firmă care să conţină informaţiile necesare modelării conceptuale a datelor.
2. Daţi câte două exemple de entităţi-resursă, entităţi-eveniment şi entităţi-agent din următoarele
subsisteme informaţionale: Urmărirea vânzărilor, Urmărirea achiziţiilor, Gestiunea producţiei.
3. Puneţi în evidenţă, printr-un exemplu, importanţa rolului relaţiilor dintre entităţi. Comentaţi exemplul
ales.
4. Daţi un exemplu de relaţie ternară şi interpretaţi cardinalitatea ei.
5. Puneţi în evidenţă, printr-un exemplu, importanţa cardinalităţii minime a relaţiilor.
6. Construiţi DER pe baza documentaţiei redactate la punctul 1.
7. Daţi două exemple de relaţii între două entităţi-eveniment şi explicaţi în ce constă dualitatea celor
două relaţii.
CAPITOLUL IX
Selectarea variantei strategice de proiectare

a sistemelor informaţionale
Obiective:
 Discutarea necesităţii formulării mai multor variante de proiectare
 Prezentarea procedurilor de selecţie a celei mai bune variante strategice de proiectare
 Cunoaşterea şi stăpânirea problemelor în legătură cu care se pot genera variante de
strategii de proiectare pentru un sistem informaţional
 Descrierea posibilelor surse de obţinere a softului
 Prezentarea metodelor de evaluarea a propunerilor de proiect
 Cunoaşterea conţinutului planului de bază al unui proiect de sistem informaţional
Întregul efort depus până în momentul de faţă s-a concretizat într-o bogată acumulare de
informaţii despre cerinţele sistemului, structurate sub diverse forme, precum şi despre modul în
care am dori să fie conceput noul sistem sau ce corecţii să i se aducă celui vechi.
Obiectivul principal urmărit în faza de analiză l-a reprezentat definirea a „ceea ce este” şi
a „ceea ce ar trebui să fie” sistemul informaţional. În acest sens, au fost realizate două activităţi
importante: determinarea cerinţelor sistemului şi structurarea (formalizarea) acestora. Prin
determinarea cerinţelor sistemului s-a urmărit, mai întâi, descrierea a ceea ce face sistemul
existent, prin prezentarea proceselor de prelucrare, a fluxurilor informaţionale, a procedurilor
de lucru, a documentelor şi rapoartelor din sistem. Apoi, s-a urmărit identificarea a ceea ce
doresc utilizatorii de la noul sistem. Structurarea cerinţelor sistemului a vizat dezvoltarea
modelului logic al sistemului. Fluxurile informaţionale dintre procesele de prelucrare au fost
reprezentate prin diagrama fluxurilor de date, logica prelucrării datelor a fost descrisă prin
intermediul tabelelor de decizie sau a englezei structurate, modelul conceptual al datelor a fost
transpus prin intermediul diagramei entitate-relaţie.
9.1 Aspecte generale privind raportul cerinţelor sistemului

şi selectarea variantei strategice de proiectare
Odată finalizată faza de analiză, trebuie aleasă calea de urmat pentru obţinerea noului
sistem. Obiectivul principal al proiectării constă în a determina exact „cum” se va parcurge
drumul de la „ceea ce este” la „ceea ce ar trebui să fie” sistemul pentru a se îngloba toate
cerinţele identificate anterior. Proiectarea trebuie să ofere soluţia optimă de înglobare a tuturor
cerinţelor în noul sistem. Trecerea de la analiză la proiectare presupune trecerea de la „ce” la
„cum” se va obţine noul sistem. Toate informaţiile colectate până acum trebuie transformate în
idei şi soluţii de proiectare pentru noul sistem.
Aşadar, ne aflăm în aşa-zisa fază a definirii strategiei proiectului.
Direcţia care va fi urmată în continuare, în dezvoltarea noului sistem, este numită
strategie de proiectare. Chiar dacă, după parcurgerea fazei de analiză, multe lucruri s-au
clarificat, asupra variantei noului sistem planează încă unele incertitudini generate de
contradicţiile care pot exista între utilizatori privind cerinţele funcţionale, variantele privind
platformele hardware şi software, cerinţele funcţionale care să fie incluse în noul sistem, în
funcţie de restricţiile de costuri şi timp, sursele de obţinere a softului etc.
Un cuvânt greu îl au utilizatorii şi finanţatorii proiectului. Pentru a-i ajuta să ajungă la o
concluzie finală comună, echipa de realizare trebuie să identifice şi să definească clar câteva
strategii concurente de proiectare, dintre care doar una va fi continuată în pasul următor al
ciclului de viaţă al sistemului, faza de proiectare, în funcţie de performanţele ei şi de

încadrarea în resursele disponibile.
În prezentul capitol, ne vom ocupa de principalele aspecte care privesc definirea strategiei
de proiectare. Vor fi prezentate activităţile care trebuie parcurse, consideraţiile care stau la
baza generării variantelor strategice de proiectare, criteriile utilizate la evaluarea lor, modul de
selectare a celei mai bune variante de sistem, conţinutul planului de bază al proiectului.
Rezultatul final al studiului de identificare a cerinţelor de informaţii se concretizează într-
un raport detaliat al cerinţelor sistemului, în care vor fi prezentate informaţiile necesare noului
sistem. Raportul cuprinde tot ceea ce trebuie să fie produs de către sistem. El va lăsa fazei de
proiectare o imagine clară a modului în care se vor obţine cerinţele sistemului.
Raportul va conţine următoarele elemente:
 descrierea funcţiilor principale executate în noul sistem, inclusiv ce trebuie făcut şi de
către cine, cum se realizează interfaţa funcţiilor cu întregul sistem şi cum funcţiile noi
vor afecta utilizatorii;
 descrierea tuturor datelor necesare sistemului, inclusiv nume, mărime, format, sursă,
importanţă, precum şi o listă a regulilor folosite pentru a se asigura securitatea şi
controlul datelor;
 o structură preliminară a datelor, prin care se va arăta cum datele vor fi organizate în
înregistrări logice şi care este legătura dintre date;
 o descriere şi un model de exemplar pentru fiecare ieşire din sistem (rapoarte,
documente). Descrierea trebuie să prezinte numele ieşirii, scopul ei, frecvenţa şi
distribuţia, precum şi toate datele ce le va conţine;
 descrierea şi prezentarea unui exemplar al tuturor intrărilor în sistem, inclusiv numele
fiecărei intrări, sursa, cine îl completează, ce date va conţine şi cum vor fi culese datele
din el;
 volumul minim, mediu şi maxim de date şi determinarea numărului de operaţiuni de
intrare, al documentelor de ieşire şi al înregistrărilor stocate. Estimările trebuie să fie
făcute pe baza frecvenţei apariţiei de noi înregistrări, a schimbărilor, ştergerilor ş.a.;
 descrierea modului de funcţionare a noului sistem şi a subsistemelor componente,
precum şi a modului în care vor fi atinse obiectivele de către întregul organism;
 descrierea unor norme interne de conduită privind raportările, programarea
activităţilor, securitatea şi protecţia, personalul implicat şi zona de acces pe categorii
ale acestuia;
 prezentarea restricţiilor existente în sistem, cum ar fi statutele şi regulamentele de
organizare;
 o listă a problemelor de politică curentă a organizaţiei şi conflictele existente cu
utilizatorii, ca şi modul lor de soluţionare;
 punctele de control al datelor, pentru a se asigura siguranţa şi controlul realizării
operaţiunilor (pentru intrări, ieşiri şi prelucrarea datelor privind activitățile
economice). Se vor menţiona tipul controlului şi utilitatea lui (dacă are rolul de a
preveni, a detecta sau corecta);
 necesităţile de reorganizare a unităţii pentru a răspunde cerinţelor utilizatorilor.
Reorganizarea se poate referi la problemele personalului, incluzând adăugarea de noi
funcţii, reconfigurarea locurilor de muncă sau desfiinţarea altora. Se va schiţa o nouă
structură organizatorică.
În afara raportului detaliat, se va înainta o sinteză pentru conducere, fără să se apeleze la
limbajul tehnic, pentru a se prezenta cerinţele utilizatorilor şi efortul de elaborare a noului
sistem. Dacă este posibil, raportul poate fi însoţit de exemple de structuri ale înregistrărilor,
exemple de ieşiri sau grafice, pe variante strategice ale proiectelor propuse.
Odată ce au fost determinate cerinţele utilizatorilor, echipa de proiectare va avea misiunea
să continue munca de obţinere a acordului şi aprobării utilizatorilor şi conducerii. Se vor
SELECTAREA VARIANTEI STRATEGICE DE PROIECTARE A SISTEMELOR 201
organiza întâlniri pentru a se explica noul sistem, pe baza prezentărilor orale, a sintezei
conducerii privind cerinţele utilizatorilor şi a unor documente dintre cele întocmite anterior.
După acceptul utilizatorilor, conducerile departamentelor implicate vor semna documentele
necesare aprobării rezultatelor fazei desfăşurate.
Analiza de sistem se finalizează cu raportul analizei de sistem, prin care se sintetizează şi
se documentează constatările etapei de analiză. Un raport sintetic şi un exemplar din
documentaţie servesc drept elemente de bază pentru proiectanţii de sistem.
Raportul analizei conţine:
 scopul, domeniul, obiectivele şi restricţiile proiectului;
 legătura proiectului cu planul strategic al întregului sistem informaţional;
 criticile aduse sistemului de către analişti;
 o sinteză a problemelor existente în sistemul curent şi restricţiile lui;
 recomandări pentru îmbunătăţirea sistemului existent şi proiectarea celui nou;
 descrierea informaţiilor necesare luării deciziilor;
 o sinteză a tuturor studiilor de fezabilitate (tehnică, economică ş.a.), cu recomandarea
ca sistemul să fie continuat sau nu;
 estimarea timpului, a costurilor şi a resurselor necesare noului sistem;
 planurile preliminare ale fazei de proiectare a sistemului.
Decizia de a merge sau nu mai departe se ia, în principiu, de trei ori în timpul analizei
sistemului: în timpul investigării iniţiale pentru a se stabili dacă se va trece mai departe la
studierea sistemului; la sfârşitul studiului de fezabilitate, pentru a se stabili dacă se va trece la
etapa de determinare a necesarului de informaţii; după terminarea fazei de analiză, pentru a se
hotărî dacă se va continua cu faza de proiectare.
9.2 Procedura de selecţie a celei mai bune variante

strategice de proiectare
Până acum, în faza de analiză, au fost determinate şi structurate cerinţele sistemului, iar
acum ne ocupăm de ultima subfază, care premerge trecerea la faza de proiectare. Dar de ce este
nevoie să definim mai multe variante de proiectare?
În primul rând, decizia asupra variantei optime aparţine utilizatorilor şi conducerii firmei,
datorită importanţei ei deosebite. Pentru a fi în măsură să decidă, ei trebuie să aibă în faţă mai
multe variante decizionale. De cele mai multe ori, variantele de sistem sunt rezultatul
compromisului între trei dimensiuni ale proiectului: calitatea, costurile şi timpul de realizare.
Un vechi dicton ingineresc spune că „Un proiect poate fi bun, ieftin şi realizat în timp
scurt . . . alege două dintre ele”. Accentul pus pe unul din cele trei aspecte se va răsfrânge
asupra unuia din celelalte două sau chiar asupra ambelor aspecte. De exemplu, accentul pus pe
calitatea sistemului (cum ar fi includerea tuturor cerinţelor funcţionale şi nefuncţionale în
sistem) ar presupune costuri şi timp de realizare mai mari. Dacă se doreşte minimizarea
costurilor şi reducerea timpului de realizare, atunci calitatea sistemului va fi mult afectată.
Obţinerea unui sistem de calitate şi într-o perioadă scurtă de timp duce la sporirea
considerabilă a costurilor (vor fi angajaţi numeroşi specialişti din afara firmei). Prin urmare, se
poate interveni doar asupra a două din cele trei aspecte importante care privesc dezvoltarea
sistemelor informaţionale.
Un alt motiv, care justifică necesitatea elaborării mai multor variante de proiectare, este
legat de pericolul familiarizării excesive a membrilor echipei cu anumite tipuri de probleme1.
Dacă ei sunt specializaţi cu precădere în tehnologia bazelor de date, atunci soluţia lor se va
baza pe această tehnologie, chiar dacă cel mai indicat mod de rezolvare ar consta în utilizarea
unui program de calcul tabelar. De asemenea, dacă în trecut au avut o soluţie anume la un gen
1. Oprea, D. – Analiza şi proiectarea sistemelor informaţionale economice, Ed. Polirom, Iaşi, 1999, p. 277.
similar de problemă, varianta propusă de ei va fi ultima lor realizare la dezvoltarea unui alt
sistem. Dacă ea ar fi şi cea mai bună soluţie nu ar fi nimic grav, însă, de multe ori, propunerea
este subiectivă.
Date fiind aceste tendinţe, s-a ajuns la concluzia că o echipă de analiză trebuie să propună
cel puţin două soluţii la problema supusă analizei. În teorie se spune că, dacă există trei seturi
de formulări ale cerinţelor, trei medii de implementare şi patru surse ale softului de aplicaţii,
rezultă în total 36 de strategii posibile de proiectare. În practică însă, multe dintre acestea pot fi
nefezabile sau lipsite de interes, ceea ce se rezumă, în final, la acordarea atenţiei cuvenite doar
pentru trei variante. Numărul este agreat de cei mai mulţi specialişti, întrucât prin el s-ar
surprinde punctele esenţiale ale unui spectru posibil de soluţii: cele două extremităţi ale lui şi
mijlocul. În cele ce urmează, vom face o scurtă descriere a fiecăreia dintre cele trei variante.
Varianta 1 reprezintă partea de jos a spectrului şi poate fi caracterizată astfel:
 este cea mai conservatoare în ceea ce priveşte costurile, efortul depus şi tehnologiile
implicate;
 de cele mai multe ori, soluţionarea problemei nu înseamnă numai folosirea
calculatorului;
 este puternic orientată spre realizarea, pe hârtie, a fluxurilor informaţionale mai
eficiente sau spre eliminarea redundanţelor din procesele curente;
 oferă tot ceea ce a solicitat utilizatorul, printr-un sistem care diferă foarte puţin de cel
existent.
Varianta 2, de la celălalt capăt al spectrului, superior, merge mult mai departe decât
simpla rezolvare a problemei şi conţine performanţe pe care probabil că utilizatorul şi le-ar
dori. Caracteristicile esenţiale sunt:
 orientarea spre funcţionalitate;
 costurile nu constituie problema cea mai importantă;
 se oferă cele mai performante sisteme bazate pe cele mai avansate tehnologii;
 sistemul este deschis unor posibile extensii viitoare;
 utilizatorul este copleşit de varianta propusă, dar nu întotdeauna poate să identifice o
astfel de variantă din cauza resurselor limitate.
Varianta 3, situată între cele două prezentate, se află la mijlocul spectrului.
Caracteristicile ei sunt:
 combină trăsăturile celorlalte două variante, renunţând la obsesia încadrării în anumite
costuri şi preluând ca obiectiv central funcţionalitatea de înalt nivel;
 este varianta de compromis.
Încadrarea în cele trei soluţii se realizează printr-o minuţioasă analiză a cerinţelor
sistemului.
Selectarea celei mai bune dintre ele se efectuează cu ajutorul procedurilor cantitative.
Analiştii pot sugera varianta percepută de ei ca fiind cea mai bună, dar echipa managerială va
avea ultimul cuvânt. Un proiect poate fi, de asemenea, oprit în această etapă.
Oricum, în această subfază trebuie să se realizeze următoarele activităţi:
1. Generarea strategiilor posibile de proiectare.
2. Selectarea celei mai bune strategii.
3. Prezentarea planului de bază al proiectului pentru regăsirea strategiei selectate în
sistemul informaţional în curs de realizare.
În continuare, vom aborda, pe rând, aceste trei activităţi.
9.3 Generarea variantelor strategice ale proiectului

Pentru generarea variantelor strategice ale proiectului trebuie luate în considerare
următoarele probleme:
 aria de întindere şi nivelul de informatizare;
 sursele softului
 selecţia softului şi a hardului;
 implementarea;
 limitele organizaţiei.
Variantele proiectului trebuie să respecte două categorii de condiţii, prezentate sub forma:
 funcţiilor obligatorii ale noului sistem;
 restricţiilor impuse.
1. Stabilirea minimului necesar de informaţii solicitate de noul sistem
Trăsăturile pe care le poate dobândi sistemul sunt împărţite, uneori, în trei categorii:
obligatorii, importante şi dorite.
Trăsăturile sau caracteristicile sistemului se concretizează în:
 datele reţinute în sistem;
 ieşirile sistemului (rapoarte, ecrane, documente, răspunsuri la întrebări);
 analizele pe baza cărora se obţin noi informaţii;
 accesibilitatea, timpul de răspuns, modul de exploatare (în timp real, partajat ş.a.).
2. Determinarea restricţiilor din noul sistem
Restricţiile pot fi generate de factori ca:
 un termen anume când sistemul trebuie schimbat;
 resursele financiare şi umane disponibile;
 elementele din sistemul curent ce nu pot fi schimbate;
 restricţii impuse de cadrul legislativ sau de contracte;
 importanţa datelor şi dinamica problemei supuse analizei impun limite referitoare la
modul de realizare a sistemului (de exemplu, dacă se gestionează date strict secrete,
sistemul nu poate fi realizat de alte firme).
Ambele considerente trebuie să fie identificate şi ierarhizate după importanţa lor,
explicându-se clar care sunt motivele ordonării lor într-o anumită formă.
În continuare, vom pune în discuţie principalele probleme care stau la baza generării
variantelor strategice de proiectare. În acest sens, vom demonstra modul în care pot fi
formulate diferite strategii în legătură cu o anumită problemă, dar vom oferi şi o scurtă
descriere a celor mai importante variante întâlnite în practică, ce o considerăm utilă în
activitatea de evaluare şi selecţie a celei mai bune strategii.
9.3.1 Variantele de proiectare privind aria de întindere şi nivelul de

informatizare
Aşa cum am văzut, una dintre activităţile realizate în faza de analiză constă în definirea
ariei de întindere a sistemului. Obiectivul urmărit atunci era definirea graniţelor sistemului
prin identificarea funcţiilor ce vor fi incluse şi a legăturilor cu mediul său extern. Toate aceste
informaţii au fost structurate cu ajutorul diagramelor fluxurilor de date.
Acum, înainte de a se trece la proiectarea sistemului, trebuie luată decizia cu privire la
funcţiile care vor fi incluse în sistem. De regulă, utilizatorii solicită mai multe cerinţe
funcţionale, a căror satisfacere ar duce la depăşirea bugetului alocat şi/sau a timpului de
realizare planificat. Mai mult, se întâmplă ca utilizatorii să ceară adăugarea unor noi funcţii
după ce s-a trecut la faza de proiectare.
Astfel de situaţii pot fi evitate prin formalizarea procesului de identificare, grupare şi
stabilire a priorităţii cerinţelor informaţionale. În acest sens, echipa de realizare a sistemului va
întocmi un document cu care utilizatorii să fie de acord şi pe care-l vor semna. În el vor fi
consemnate toate cerinţele acestora.
Pentru a decide asupra funcţiilor (cerinţelor funcţionale) ce vor fi incluse în sistem este
necesară formularea unor variante de proiectare. Fiecare variantă va îngloba mai puţine sau
mai multe din cerinţele utilizatorilor. Această sarcină poate fi uşurată prin gruparea cerinţelor
sistemului în trei categorii: obligatorii, importante şi dorite. Stabilirea priorităţii fiecărei
cerinţe este efectuată împreună cu utilizatorii şi poate fi realizată chiar în faza de analiză, pe
măsură ce acestea sunt identificate.
Determinarea priorităţii fiecărei funcţii se face, de regulă, în strânsă legătură cu descrierea
nivelului de informatizare a sistemului. Nivelul de informatizare priveşte suportul pe care
sistemul informatic îl va oferi pentru fiecare funcţie în parte. Pentru cele mai multe funcţii ale
unui sistem, pot fi definite cel puţin trei niveluri de informatizare: mic, mediu şi mare.
În cazul unui nivel mic de informatizare, sistemul se va limita la gestiunea înregistrărilor
care privesc acea funcţie. Aplicaţia va conţine formulare pentru introducerea, modificarea,
validarea şi salvarea datelor; va furniza unele informaţii sub forma rapoartelor programate. Un
nivel mare de informatizare presupune ca sistemul să realizeze cât mai multe din prelucrările
specifice funcţiei respective. Definirea acestui nivel este foarte dificilă. Dacă în cazul unui
nivel mic de informatizare se urmăreşte, de regulă, doar automatizarea procedurilor manuale
existente, acum trebuie sesizate noi moduri de lucru, trebuie regândit complet modul de
realizare a acelei funcţii, cu scopul îmbunătăţirii radicale a performanţelor. Acest cadru mai
este întâlnit sub numele de reproiectarea proceselor economice (Business Process
Reengineering – BPR).
Varianta nivelului mediu de informatizare reprezintă, de obicei, o combinaţie a
caracteristicilor celorlalte două. Prin această variantă, care este cel mai probabil să fie
selectată, analistul încearcă să facă cea mai bună alegere între ceea ce este necesar şi ceea ce
este posibil, ţinând cont de restricţiile privind bugetul şi timpul de realizare.
După definirea variantelor de proiectare, pe baza priorităţii şi nivelurilor de informatizare
pentru fiecare funcţie, se trece la evaluarea acestora. Drept criterii de evaluare vor fi utilizate,
în primul rând, restricţiile rezultate din studiile de fezabilitate a proiectului. Este evident că
extinderea funcţională a sistemului şi un nivel ridicat de informatizare vor implica costuri mari
şi timp îndelungat.
În această fază, informaţiile despre cerinţele sistemului şi dificultatea dezvoltării unor
capacităţi ale acestuia sunt mai detaliate, echipa de dezvoltare fiind în măsură să evalueze mai
exact decât în fazele anterioare costurile pentru fiecare variantă strategică de proiectare,
urmărindu-se încadrarea în bugetul aprobat. Datorită şi restricţiilor de timp, noul sistem nu va
putea satisface toate cerinţele utilizatorilor. Însă, pe măsură ce utilizatorii capătă experienţă în
lucrul cu noul sistem, acesta poate fi extins până ce se acoperă toate cerinţele şi se obţine
nivelul de informatizare dorit.
În continuare, vom prezenta un exemplu (Caseta 9.1) prin care să punem în evidenţă
modul în care pot fi identificate şi definite variantele de proiectare legate de aria şi nivelul de
informatizare. În acest sens, vom apela tot la sistemul de gestiune a clienţilor, dar propunem o
altă viziune a utilizatorilor, care să ofere o bază mai largă de discuţie privind posibilităţile de
informatizare. De asemenea, acum vom considera cazul unei firme distribuitoare de carte.
Caseta nr. 9.1 – Definirea ariei de întindere a sistemului
În urma definirii ariei de întindere, s-a considerat că sistemul realizează următoarele funcţii:
 Evidenţa comenzilor. După primirea comenzii se verifică situaţia clientului şi a stocului
pentru produsele solicitate, iar în cazul avizării se calculează valoarea comenzii, se emite şi
transmite o înştiinţare către client şi se înregistrează comanda.
 Prelucrare stocuri. Pe baza solicitării clientului se confirmă existenţa stocului necesar, se
emite avizul de expediţie, un exemplar fiind transmis la depozit, şi se actualizează stocul.
 Onorare comenzi. Avizul de expediţie stă la baza întocmirii facturii, după care are loc
înregistrarea şi transmiterea ei către client. Datele privind facturile sunt prelucrate zilnic în
vederea întocmirii notei contabile, ce va fi transmisă, împreună cu documentele justificative,
către sistemul de contabilitate generală.

 Evidenţă analitică clienţi. Acest proces este necesar pentru întocmirea situaţiei clienţilor de
încasat şi determinarea clienţilor în litigiu. În acest sens, se deschide câte o fişă analitică
pentru fiecare client important.
 Analiza vânzărilor. Acest proces presupune agregarea datelor privind vânzările şi analiza lor
multidimensională.
La definirea variantelor de proiectare, DFD se dovedesc extrem de utile.

În figura 9.1, este prezentată diagrama de nivel 0 pentru sistemul nostru, în care toate
funcţiile (procesele de prelucrare) se regăsesc în interiorul liniei punctate, ceea ce înseamnă că
s-a optat pentru informatizarea întregului sistem.
Informatizarea poate începe din momentul în care se primeşte comanda de la client
(eventual prin poştă), însă poate merge până la dezvoltarea unei aplicaţii Web care să permită
clienţilor, care au acces la Internet, să introducă comanda direct în sistem. Astfel, clienţii vor
putea comanda produse 7 zile din 7, 24 din 24 de ore, reprezentat sumar sub forma 7/24. În
plus, s-ar putea crea un site în care clienţii să găsească informaţii cu privire la produse sau la
starea comenzilor lansate de ei. Eventual, sistemul ar putea să recomande clienţilor şi alte cărţi,
în funcţie de cele comandate (de exemplu, cărţi de aceeaşi autori, cu subiecte asemănătoare sau
complementare).
Instiintare-
client Limita-de-credit-
Client Date-clienti Factura
si-sold-client
Clienti 5
Date-
Analiza vanzari
1 Client-nou vanzari
Comanda- Comenzi-
client clienti
Evidenta
comenzi Date-comanda-noua
Date- Conducere
analiza-vanzari
Comanda
Date-
Solicitare- preturi
stoc
Clienti-
Stoc Comanda- in-
neonorata Clienti 4 litigiu
Stoc-
actualizat Evidenta
Stoc-
existent Date- analitica
3 clienti Sold- clienti
nou
Prelucrare 2
stocuri Date-
Aviz-de-expeditie Onorare factura- Date-
Aviz- comenzi noua vanzari
de- Clienti-
expeditie de-
Factura incasat
Factura
Depozit Nota-
Client contabila
Sistem
contabilitate
Fig. 9.1 Informatizarea completă a sistemului de urmărire a vânzărilor
În continuare, avizarea comenzilor se poate face tot automat, prin implementarea în

aplicaţie a unor reguli şi politici de creditare, stabilite de conducere, precum şi calculul valorii
comenzii şi emiterea înştiinţării. Nivelul de informatizare poate fi sporit prin transmiterea
electronică a înştiinţării.
Pe baza comenzii primite, şi după avizarea acesteia, se emite automat avizul de expediţie
şi factura, după care urmează înregistrarea lor şi generarea automată a notei contabile la
sfârşitul fiecărei zile. O facilitate suplimentară legată de prelucrarea stocurilor ar consta în
comandarea automată, către edituri, a cărţilor pentru care există cerere şi stocul este sub limită.
Informatizarea completă a evidenţei analitice a clienţilor ar putea presupune şi

determinarea profilului clienţilor pe baza datelor privind istoricul vânzărilor, ceea ce ar permite
generarea unor oferte personalizate pentru fiecare client.
Informatizarea analizei vânzărilor poate viza doar simpla generare a unor rapoarte pentru
conducere, însă se poate opta pentru dezvoltarea unei aplicaţii OLAP care să acceseze un
depozit de date (data warehouse), oferind astfel posibilitatea efectuării unor analize
multidimensionale asupra datelor.
În figura 9.2 este pusă în evidenţă o variantă de informatizare parţială a sistemului. Se
poate observa că prelucrarea stocurilor nu mai este informatizată, ceea ce înseamnă că avizul
de expediţie se întocmeşte manual la depozit, la fel ca şi operarea stocurilor. De asemenea, s-a
renunţat la generarea automată a notelor contabile, această funcţie fiind preluată de sistemul de
contabilitate, căruia îi va fi transmisă factura. Şi analiza vânzărilor este plasat în afara ariei de
informatizare, optându-se pentru generarea manuală a unor rapoarte ad-hoc cerute de
conducere.
Instiintare-
Client client Limita-de-credit-
si-sold-client Date-clienti Factura
Clienti 5
Date-
Analiza vanzari
1 vanzari
Comanda- Client -nou
client Comenzi-
Evidenta clienti
comenzi Date-comanda-noua
Date-
Conducere
Comanda analiza-vanzari
Date-
Solicitare- preturi
stoc
Clienti-
Stoc Comanda- in-
neonorata Clienti 4 litigiu
Stoc-
Solicitare- actualizat
stoc Stoc- Evidenta
existent Date- analitica
3 clienti Sold- clienti
nou
2
Prelucrare Aviz-de-expeditie
stocuri Date-
Onorare factura- Date-
comenzi noua vanzari
Aviz- Clienti-
de- Factura de-
expeditie incasat
Factura
Aviz-de-expeditie Factura
Depozit
Client
Sistem
contabilitate
Fig. 9.2 Informatizarea parţială a sistemului de urmărire a vânzărilor
Atunci când se pune în discuţie definirea ariei de informatizare, se poate lucra la un nivel
de descompunere mai fin. Altfel spus, această discuţie nu se limitează la stabilirea proceselor
din diagrama de „nivel 0” care să fie sau nu informatizate, ci trebuie luate în considerare şi
subprocesele fiecărei funcţii din diagrama de „nivel 0”. Prin urmare, vor fi luate în considerare
şi diagramele de pe nivelurile inferioare.
În general, pentru fiecare funcţie pot fi definite cel puţin trei niveluri de informatizare:
inferior, mediu şi l superior. În tabelul 9.1 sunt prezentate atât aria de cuprindere, prin
încadrarea funcţiilor sistemului în una din cele trei categorii de prorităţi, cât şi nivelul de
informatizare pentru fiecare funcţie în parte, prin prezentarea variantelor de informatizare.
Stabilirea priorităţii se efectuează în funcţie de cerinţele utilizatorilor şi obiectivele sistemului.
De exemplu, dacă unul din obiectivele sistemului vizează îmbunătăţirea relaţiilor cu clienţii,
atunci funcţiile care permit firmei să răspundă mai rapid şi mai bine la cerinţele clienţilor vor fi
obligatorii şi se va lua în considerare un nivel de informatizare cât mai bun.
Tabel nr. 9.1 – Priorităţile şi nivelul de informatizare al principalelor funcţii

Funcţiile Categoria de Nivelul inferior de Nivelul mediu de Nivelul superior de
sistemului prioritate informatizare informatizare informatizare
Înregistrare Obligatorie Introducerea datelor de Introducerea în timp Introducerea on-line a
comandă către un angajat la real comenzii direct de către
intervale regulate de timp client
Controlul Dorită Oferirea răspunsului Oferirea răspunsului Notificarea automată
stării după un anumit timp în timp real de către
comenzii un angajat sau
verificarea directă de
către client prin Web
Verificare Importantă Generarea periodică a Verificarea în timp Verificarea în timp real de
situaţie client listelor real la preluarea către clienţi prin Web
comenzii
Verificare Dorită Generarea periodică a Verificarea în timp Verificarea în timp real de
stoc listelor cu stocuri real la preluarea către clienţi prin Web
comenzii
Înştiinţare Importantă Tipărire şi transmitere Generare şi transmitere Generare şi transmiterea
client prin poştă prin e-mail după un automată prin e-mail
anumit timp
Transmitere Dorită Materiale generale Materiale Materiale personalizate pe
materiale personalizate pe baza baza analizei istoricului
promoţionale chestionarelor vânzărilor
Determinare Dorită Chestionare şi Analiza istoricului Combinarea ambelor
profil clienţi prelucrarea lor vânzărilor variante
Actualizare Dorită Actualizarea periodică a Actualizarea în timp Rezervarea stocului de
stoc stocurilor real odată cu avizarea către client odată cu
comenzii transmiterea comenzii prin
Web
Generare Obligatorie Tipărire la cerere Afişare on-line în timp
situaţie clienţi real
de încasat
Generare Obligatorie Tipărire la cerere Afişare on-line în timp
situaaţie real
clienţi în
litigiu
Generare fişă Importantă Tipărire la cerere Afişare on-line în timp
client real
Generare notă Dorită Generare recapitulaţie Generare lunară a Generare notă contabilă
contabilă operații notei contabile pentru fiecare operație
Analiză Dorită Tipărire rapoarte Instrumente OLAP pentru
vânzări diverse analiza datelor
Fiecare celulă din ultimele trei coloane trebuie detaliată într-o documentaţie separată.
După cum se poate sesiza cu uşurinţă, informatizarea anumitor funcţii depinde de nivelul
de informatizare a altor funcţii. De exemplu, transmiterea de materiale promoţionale
personalizate nu ar fi posibilă fără definirea profilului clienţilor pe baza analizei istoricului
vânzărilor. De aceea, diagramele fluxurilor de date trebuie urmărite cu multă atenţie, altfel se
poate ajunge la obţinerea unui sistem ineficient. De regulă, se renunţă la informatizarea

activităţilor situate la extremitatea fluxului logic al activităţilor din sistem.
În concluzie, diagrama fluxurilor de date joacă un rol important nu doar în reprezentarea
logică a prelucrărilor din sistem, ele stând şi la baza definirii variantelor strategice de
proiectare a sistemului, permiţând selectarea corectă a proceselor ce vor fi informatizate şi a
modului în care va fi realizată.
Evaluarea variantelor de proiectare se face pe baza studiilor de fezabilitate efectuate,
urmărindu-se în primul rând încadrarea în bugetul aprobat şi perioada de timp stabilită. Echipa
de realizare poate cere suplimentarea bugetului şi prelungirea timpului necesar pentru
dezvoltare, justificând conducerii necesitatea înglobării anumitor funcţii în sistem.
Funcţiile care vor fi informatizate, precum şi nivelul de informatizare ales sunt evidenţiate
în tabelul 9.1.
9.3.2 Formularea variantelor de implementare

Implementarea unei soluţii poate fi realizată în mai multe moduri. De exemplu, aplicaţiile
standard (cum sunt aplicaţiile de gestiune a stocurilor, evidenţa clienţilor, contabilitate
generală, resurse umane-salarizare etc.) pot fi achiziţionate de pe piaţă de la o firmă
producătoare de software. Dacă această soluţie nu este agreată de firmă, se poate opta pentru
dezvoltarea noului sistem în cadrul firmei, fie cu specialiştii proprii, fie prin contractarea unor
specialişti din afara firmei pentru realizarea unor activităţi, care presupun un nivel de expertiză
tehnică deosebită (cum ar fi proiectarea şi programarea aplicaţiilor Web, dezvoltarea
sistemelor distribuite, dezvoltarea aplicaţiilor data warehouse etc.).
Prin urmare, există mai multe variante de implementare a noului sistem, pe care echipa de
dezvoltare trebuie să le ia în considerare, să le evalueze şi să aleagă pe cea care corespunde cel
mai bine condiţiilor din firmă şi caracteristicilor sistemului informaţional.
Diferitele variante de implementare a sistemului se regăsesc în spaţiul definit de două
dimensiuni: opţiunea achiziţionare/dezvoltare şi opţiunea în cadrul firmei/în afara firmei.
Cadrul astfel format şi poziţionarea celor mai importante variante de implementare sunt puse în
evidenţă în figura 9.3.
Externalizarea
serviciilor
informaţionale
Achiziţionare
Soluţii Soluţii
ERP la cheie
Dezvoltare
Software la comandă
În cadrul firmei În afara firmei
Fig. 9.3 Variante de implementare

(adaptare după Satzinger, J.W., Jackson, R.B., Burd, S.D. – Systems Analysis and Design in a Changing
World, Course Technology, Thomson Learning, Boston, 2002, p.314)
Fiecare din cele două axe conţine un spectru de valori, nu doar valorile extreme
evidenţiate în figura 9.3. Se poate opta pentru achiziţionarea întregului sistem sau pentru
dezvoltarea în totalitate a acestuia, însă, între aceste două extreme, pot fi identificate şi alte
soluţii, în care o parte a sistemului să fie cumpărată, iar cealaltă parte să fie dezvoltată. De
exemplu, se poate opta pentru achiziţionarea unei soluţii de pe piaţă, dar care să necesite
modificarea unor componente sau adăugarea altora în vederea adaptării la anumite cerinţe
specifice firmei sau pentru crearea interfeţelor cu sistemele existente în firmă.
În mod similar, există mai multe opţiuni în ce priveşte cealaltă dimensiune, situate între
cele două extreme: dezvoltarea integrală a sistemului în cadrul firmei şi dezvoltarea sa
integrală în afara firmei.
9.3.2.1 Externalizarea serviciilor informaţionale
Externalizarea a devenit una din metodele cele mai eficiente de reducere a costurilor şi de
îmbunătăţire a performanţelor unui grup de activităţi din cadrul firmei. Externalizarea
sistemelor informaţionale (sau a serviciilor informaţionale) presupune transferul către un
furnizor a managementului sistemului, respectiv a dezvoltării şi exploatării lui. Externalizarea
sistemelor informaţionale cuprinde o paletă mai largă de posibilităţi, de la externalizarea în
totalitate a sistemelor informaţionale şi până la externalizarea dezvoltării parţiale a noului
sistem.
La o extremă se află situaţia contractării unui agent pentru dezvoltarea şi exploatarea
aplicaţiilor pe calculatoarele acestuia, firma preocupându-se numai de furnizarea datelor de
intrare şi preluarea ieşirilor sistemului. În acest caz, agentul contractat se va ocupa de toate
serviciile informaţionale, inclusiv prelucrarea datelor, calculatoarele, programele, reţeaua şi
personalul aparţinând acestuia. În fapt, agentul va reprezenta departamentul informatic al
firmei pentru care prestează serviciile. O variantă apropiată presupune angajarea unei companii
care să furnizeze aplicaţiile necesare şi să le execute în cadrul firmei contractante pe
calculatoarele acesteia.
Se poate opta pentru externalizarea doar a activităţilor de dezvoltare a sistemelor
informaţionale, cu scopul dezvoltării complete sau parţiale a sistemului, cumpărării de pachete-
program şi, eventual, adaptarea acestora la cerinţele specifice ale clientului, sau obţinerea de
asistenţă pe parcursul tuturor fazelor de dezvoltare a sistemului. Un exemplu tradiţional constă
în contractarea unui agent pentru testarea aplicaţiilor la nivel de sistem.
După cum rezultă din figura 9.3, în acest paragraf, prin externalizare facem referire la
întregul sistem, inclusiv punerea în funcţiune şi exploatarea sa de zi cu zi. Situaţia contractării
unei firme doar pentru dezvoltarea noului sistem sau a unei părţi din acesta nu se încadrează
aici. Ea este evidenţiată în acea parte a formei „Soluţia dezvoltării” care corespunde opţiunii
„În afara firmei”.
Externalizarea sistemelor informaţionale reprezintă, în general, o decizie strategică, pe
termen lung (de regulă 8-10 ani), şi nu se aplică doar asupra unui proiect de dezvoltare, ci la
nivelul întregii organizaţiei. De aceea, ea nu reprezintă propriu-zis o variantă de implementare,
decizia fiind luată la nivelul conducerii superioare.
Externalizarea serviciilor informaţionale este posibilă prin apelarea la Application Service
Providers (ASP). Un ASP este o companie care dezvoltă şi furnizează servicii folosite în
comun de mai mulţi utilizatori, care plătesc un abonament sau taxe de folosire, serviciile fiind
furnizate dintr-o locaţie centrală prin Internet sau printr-o reţea privată. ASP presupune acces
partajat, sub control, la anumite servicii.
9.3.2.2 Surse ale softului
Dacă soluţia externalizării serviciilor informaţionale ar putea părea una prea radicală,
firmele au la dispoziţie şi alte variante de implementare a sistemului. Ne referim la diferitele
surse ale softului.
În general, programele informatice pot fi obţinute pe două căi principale: achiziţia unui
pachet de aplicaţii de pe piaţă de la diferiţi furnizori, numit şi soft la cheie, sau dezvoltarea
acestuia prin parcurgerea tuturor fazelor specifice ciclului de viaţă al sistemelor
informaţionale, soluţie numită şi soft la comandă. Acestea două nu reprezintă decât valorile
extreme ale unui spectru, între ele putând fi identificate alte soluţii.
Softul necesar sistemului poate fi obţinut pe următoarele căi:
 cu forţe proprii;
 la comandă;
 la cheie;
 la cheie modificat.
Softul realizat cu forţe proprii
Din faza incipientă a utilizării calculatoarelor, aproape toate organizaţiile şi-au proiectat şi
au scris propriile lor aplicaţii. În multe cazuri, operaţiunea este impusă, unitatea neavând de
ales altă modalitate. De cele mai multe ori, nu existau decât câteva tipuri de programe
disponibile pe piaţă, care nu satisfăceau întotdeauna necesităţile organizaţiilor. Deşi acum la
dispoziţia utilizatorului se află o largă varietate de soft la cheie, mai există încă unităţi care
consideră că problemele lor specifice nu se pot rezolva achiziţionând un soft de pe piaţă. Alte
organizaţii sunt atât de mari şi de complexe încât singura modalitate de a-şi satisface cerinţele
o constituie elaborarea propriului soft de aplicaţii.
Soft realizat la comandă
O altă variantă de procurare a softului poate fi angajarea din afara unităţii a
programatorilor/analiştilor sau a unei companii de software pentru a elabora pentru client un
pachet-program de aplicaţii. O astfel de modalitate poate să utilizeze şi componente din
programele existente deja la client, bineînţeles, prin adaptarea, completarea şi combinarea lor,
astfel încât să răspundă noilor cerinţe.
Elaborarea programelor de către clienţi este, deseori, un proces dificil şi poate să se
concretizeze în risipă de timp şi de resurse. O problemă deosebită apare între utilizatorii finali,
care îşi definesc propriile cerinţe, şi analist, care trebuie să le interpreteze şi să le adapteze în
structuri de programe, fişiere de date, intrări şi ieşiri. Analistul trebuie să lucreze cu utilizatorii
pentru a determina cu exactitate toate formatele de rapoarte şi ecrane. Împreună vor identifica
intrările sistemului, datele necesare fiecărei intrări, precum şi datele din structura fişierelor.
Analistul trebuie, de asemenea, să elaboreze descrieri detaliate ale tuturor prelucrărilor interne,
logic necesare obţinerii formei dorite a ieşirilor. Aceste specificaţii de program trebuie să fie
apoi interpretate şi codificate prin programe.
Datorită numeroaselor şi variatelor obiective de realizat, întregul proces presupune o
disciplină deosebită şi un control permanent. Unităţile trebuie să-şi exercite controlul cu mare
atenţie, mai ales atunci când se lucrează cu personal din exteriorul ei. Realizatorul softului
trebuie să înţeleagă în profunzime modul cum lucrează unitatea.
Pentru activitatea prestată se va încheia un contract care va consemna responsabilitatea
contractantului de a rezolva cerinţele utilizatorului şi care să-i permită unităţii să-l interpună
atunci când, în anumite condiţii, n-au fost onorate clauzele contractuale. Toate aspectele
proiectului privind softul trebuie să fie prezentate în detaliu şi astfel să se poată verifica pe
parcurs întregul proiect. Relaţia dintre colaborator şi unitate trebuie să fie definită cu
rigurozitate şi de aceea trebuie să existe o legătură permanentă între părţi. Costurile trebuie să
fie îndeaproape controlate, iar cheltuielile băneşti minimizate, până când proiectul a fost
completat şi acceptat.
Softul la cheie
Softul la cheie, realizat de către producătorii de calculatoare sau de către companii
specializate în realizarea de software, este vândut pe piaţă pentru o mare diversitate de
utilizatori cu cerinţe similare. Unii producători de software combină softul cu hardul şi le vând
ca pachete. Această combinaţie este numită sistem la cheie, deoarece furnizorul instalează
întregul sistem, iar utilizatorul trebuie doar să „răsucească” cheia pentru a beneficia de
funcţiile acestuia.
De remarcat faptul că, la nivelul anilor 1990, în topul primelor 10 firme, cu veniturile cele
mai mari din software, cinci sunt firme producătoare şi de echipamente: IBM – locul I (înaintea
firmei Microsoft), Computer Associates – locul III, Digital – locul VI, Unisys – locul VIII,
Hewlett Packard – locul X.
Producerea softului la comandă presupune o muncă anevoioasă şi de aceea scumpă. Ca
urmare, tot mai multă lume se îndreaptă spre pachetele la cheie, mai puţin costisitoare. Deja s-a
ajuns la concluzia că nu este cazul „să se reinventeze roata”, scriind programe care deja se
comercializează pe piaţă. De fapt, estimările arată că peste 70% din costul instalării
calculatoarelor de astăzi provin fie din utilizarea, fie din procurarea pachetelor-program la
cheie. Odată cu trecerea timpului, apar pachete-program tot mai performante, răspunzând
cerinţelor unităţilor, ca şi când ele ar fi elaborate cu propriile forţe sau atingând cele mai
diverse pretenţii ale organizaţiilor mari şi complexe.
Modificarea softului la cheie
Numeroase persoane consideră că este mai bună calea de a satisface cerinţele utilizatorilor
prin procurarea sistemului la cheie şi modificarea lui conform unor cerinţe anume.
Modificările pot fi făcute de către cel care a livrat softul, de către personalul unităţii
cumpărătoare sau de către o altă companie furnizoare de software sau de către un alt utilizator
al pachetului. În această categorie sunt incluse soluţiile ERP (Entreprise Resource Planning).
Din relatările anterioare se pune întrebarea: Care metodă este mai bună? Datorită
situaţiilor şi condiţiilor diferite, nu există o cale anume, catalogată ca fiind cea mai bună.
Fiecare situaţie trebuie luată în calcul separat. De regulă, softul la cheie tinde să fie cea mai
bună soluţie, când răspunde exigenţelor unităţii sau când el poate fi uşor modificat, ceea ce
corespunde sistemelor mici şi cazului în care cerinţele nu sunt complexe. Odată cu creşterea
mărimii şi complexităţii sistemului sau a cerinţelor lui, există slabe speranţe ca soluţia softului
cumpărat să fie cea mai bună. Mulţi specialişti consideră că, dacă softul nu poate fi realizat cu
forţe proprii, varianta apelării la persoane din afară pentru a-l scrie este mai scumpă decât
softul la cheie. Soluţia trebuie să vină, totuşi, de la fiecare unitate, după ce-şi evaluează
propriile cerinţe, prin analiză, şi după ce cunoaşte softul existent pe piaţă.
Soft realizat cu forţe proprii
Avantaje Dezavantaje
1. Programele pot fi concepute astfel încât să 1. Este foarte scump, munca de elaborare este foarte
răspundă cu exactitate cerinţelor unităţii. mare, chiar şi cele mai simple aplicaţii pot costa
2. Unitatea poate funcţiona conform căii dorite şi nu mii de dolari.
cum este prezentată prin pachetele la cheie. 2. De regulă, durează mult, însemnând luni sau ani de
3. Pachetele proprii sunt mult mai compatibile cu alt zile.
software din organizaţie, deci integrarea poate fi 3. Posibilitatea de a eşua, la primele încercări de
uşor realizată. utilizare, este mai mare.
4. Demarajul şi iniţierea în tehnica de utilizare a 4. Solicită costuri deosebite, timp şi control exigent.
pachetelor sunt mult mai uşor realizabile. Trebuie să se apeleze la o programare standard,
5. Moralul angajaţilor în prelucrarea automată a precum şi la elaborarea şi documentarea pachetelor
datelor este mai ridicat, loialitatea lor faţă de conform standardelor existente, ceea ce înseamnă o
propriul sistem este mult sporită. mare concentrare de forţe umane.
5. Procesul de elaborare solicită prea mult utilizatorii
şi conducerea, deoarece aceştia trebuie să analizeze
cerinţele, să sprijine proiectarea, să revizuiască, să
testeze sistemul, să identifice defecţiunile ş.a.
6. Soluţia cu specialişti din afară este foarte riscantă.
Soft la cheie
1. Costul este mult mai redus faţă de celelalte 1. Cerinţele firmei nu pot să se regăsească perfect în
variante, deoarece costul elaborării şi întreţinerii ceea ce oferă pachetul-program, fiind necesare
se împarte la numeroşi utilizatori. schimbări în modul de lucru, modificări ale unor
2. Practic nu există timp de aşteptare până la forme folosite anterior, chiar revizuirea stilului de
utilizarea lui. afaceri al firmei, ceea ce nu aduce efecte benefice.

3. Cumpărătorul minimizează riscul prin testarea 2. Evaluarea pachetelor disponibile pe piaţă înseamnă
softului înainte şi prin chestionarea altor consum de timp şi de bani, sporind astfel preţul
utilizatori ai aceluiaşi pachet. pachetului procurat.
4. Utilizatorul poate să aleagă pachetul care să 3. Programele ultrageneralizate nu sunt la fel de
răspundă cel mai bine propriilor cerinţe. eficiente ca pachetele clientului sau cele
5. Programele sunt mult mai puţin producătoare de modificate.
erori, ele fiind testate anterior, conform cerinţelor 4. Nu oferă posibilitatea specialiştilor unităţii să
utilizatorilor. intervină în caz de eşec.
6. Furnizorul poate să-şi actualizeze pachetul cu 5. Există riscul ca realizatorul softului să dea faliment
cheltuieli mult mai reduse decât ale oricărui sau să nu poată efectua actualizarea.
client, dacă ar face acelaşi lucru.
7. Întrucât astfel de produse sunt realizate de către
experţi, imitarea lor implică cheltuieli imense.
8. Documentaţia lor este mai bună.
9. Utilizatorul nu are nevoie de prea mulţi analişti şi
programatori, uneori chiar nu este nevoie de ei
pentru a proiecta şi întreţine softul.
Soft la cheie modificat
1. Răspunde mai bine cerinţelor unităţii decât softul 1. Deseori, programatorii competenţi sunt dificil de
la cheie. găsit, întrucât, nu de puţine ori, modificarea
2. Compania poate lucra conform modalităţii pe care programelor este mai dificilă decât scrierea lor
şi-o doreşte şi nu cum se impune prin programul iniţială.
la cheie. 2. Mulţi furnizori nu acceptă modificarea
3. Pot fi mai ieftine şi solicită mai puţin timp decât programelor lor.
softul realizat cu forţe proprii. 3. Documentaţia despre schimbări poate fi incompletă
4. Modificările pot fi făcute de către cel ce l-a sau inexistentă.
realizat, apropiindu-se astfel de exigenţele 4. Modificările substanţiale pot fi la fel de scumpe ca
oricărui utilizator cu un standard de elaborare şi programele scrise de client.
ridicat. 5. Modificările pot genera erori logice de control,
precum şi alte efecte neaşteptate.
9.3.3 Selectarea furnizorilor

Orice organizaţie poate selecta de pe piaţă furnizorul dorit, prin consultarea cărţilor de
telefon, prin pliante de prezentare, urmărind reviste comerciale sau de calculatoare, participând
la conferinţe, apelând la organizaţii specializate pe consultanţă ş.a.
Există o multitudine de tipuri de furnizori, alături de producătorii de calculatoare.
Segmente majore de activităţi se ocupă cu producerea mini- şi microcalculatoarelor, furnizarea
sistemelor la cheie. Există birouri de servicii, furnizori specializaţi pe aplicaţii în timp partajat,
companii de închiriere calculatoare, producători de periferice, furnizori de tehnici moderne de
conducere, precum şi furnizori de software. Când se trece la conceperea unui sistem de
prelucrare automată a datelor sau la modificarea celui existent trebuie să se ia în considerare
segmentele descrise anterior. Furnizorii, în funcţie de tipul lor, oferă servicii sau bunuri
diferite, după cum urmează:
Producătorii de calculatoare mari realizează şi vând o mare varietate de sisteme de calcul
cu destinaţie generală. Calculatoarele mari sunt solicitate numai de unităţi mari şi de organisme
guvernamentale sau locale. Multe dintre companiile producătoare oferă, de asemenea, şi
servicii. Este cazul firmelor IBM, DEC şi Unisys.
Producătorii de minicalculatoare urmăresc obţinerea de echipamente cu dimensiuni mai
mici faţă de categoria precedentă. Minicalculatoarele solicită limbaje mai puţin puternice decât
cele mari. Cei mai mulţi producători de calculatoare mari oferă şi minicalculatoare.
Producătorii de microcalculatoare sau calculatoare personale sau desktop-uri sunt cei mai
numeroşi, dar dintre ei se desprind firmele IBM, APPLE, Compaq, Dell, Hewlett-Packard,
inclusiv firmele japoneze.
Producătorii de echipamente periferice produc o mare varietate de echipamente de

intrare, de ieşire şi de stocare.
Companiile pentru închirierea calculatoarelor sau oferirea lor în sistem leasing pun la
dispoziţia utilizatorilor sisteme de calcul pe termen scurt sau lung.
Furnizorii sistemelor la cheie procură echipamente de la producători şi le revând în
combinaţie cu softul de aplicaţie adecvat, precum şi în conformitate cu necesităţile clienţilor.
Furnizorii de software elaborează şi vând aplicaţii, programe de uz general, utilitare,
sisteme de gestionare a bazelor de date şi alte tipuri de programe pentru toate mărimile de
calculatoare.
Furnizorii de furnituri produc articole din categoria benzilor, discurilor, dischetelor şi alte
suporturi de stocare.
Furnizorii de tehnici de conducere, contra unei taxe, oferă astfel de servicii în
concordanţă cu doleanţele utilizatorilor.
Birourile de servicii asigură servicii de prelucrare a datelor cu propriile echipamente
contra unor tarife. Serviciile sunt mai ieftine decât atunci când s-ar apela la propriile lor
calculatoare, întrucât cheltuielile se împart la mai mulţi utilizatori. Totuşi, securitatea datelor
nu mai este la fel de bine asigurată.
Furnizorii de aplicaţii în timp real asigură calculatoarele pentru prelucrări, echipamente
de stocare on-line şi acces la bănci de date contra unor tarife. Utilizatorii accesează
calculatoarele în mod interactiv, prin intermediul terminalelor plasate la distanţă şi al liniilor
de telecomunicaţii. Tarifele percepute depind de durata utilizării şi de resursele cerute pentru
facilitarea accesului.
O atenţie deosebită trebuie acordată evaluării furnizorului, situaţie în care se vor avea în
vedere următoarele criterii:
 Este un furnizor cu multă experienţă şi este bine consolidat? Mai are instalate sisteme
asemănătoare?
 Furnizorul poate să ofere o listă a clienţilor vechi, de la care să poată fi obţinute
informaţiile dorite?
 Are o reputaţie deosebită pentru siguranţa sistemelor oferite? Sunt satisfăcuţi clienţii
de serviciile prestate?
 Poate asigura furnizorul hardul, softul şi întreţinerea?
 Poate asigura furnizorul sprijinul necesar pentru implementare şi instalare?
 Furnizorul este de acord să consemneze promisiunile făcute printr-un contract ferm?
 Va fi semnat un contract care să protejeze interesele unităţii beneficiare?
 Care este situaţia financiară a furnizorului?
 Asigură o garanţie adecvată ofertei?
 Oferă încredere calitatea personalului furnizorului, prin experienţa lui?
 Asigură instruirea necesară?
 Cât de puternic va fi sprijinul ulterior şi cât de eficient?
9.3.4 Selectarea hardului

Cei mai mulţi primi-utilizatori de microcalculatoare nu ştiu să răspundă la întrebarea „Ce
fel de calculator ar trebui să-mi cumpăr?”. Desigur, răspunsul la o asemenea întrebare depinde
de cerinţele utilizatorului, precum şi de alte circumstanţe; dar, cu certitudine, există mai multe
tipuri de calculatoare care să le satisfacă necesităţile. Răspunsul cel mai corect ar fi
„Cumpăraţi un micro-calculator care să vă satisfacă toate cerinţele şi care să ofere, cu un cost
redus, siguranţă în funcţionare, precum şi servicii cât mai bune şi diversificate”. Cu alte
cuvinte, întâi trebuie selectat softul şi furnizorul şi apoi se va lua în discuţie problema
echipamentului.
Şi pentru o corporaţie se pun aceleaşi probleme. Numai că ele vor cumpăra

microcalculatoare şi calculatoare mari. Mai mult, progresul tehnologic deosebit de rapid face
ca un sistem cumpărat astăzi să devină depăşit peste doi sau cinci ani. Unităţile economice şi
populaţia interesate să cumpere calculatoare diferă atât în esenţă, cât şi ca necesităţi şi
obiective încât este, practic, imposibil să se ofere o listă exactă de criterii pentru o selecţie
bună. Totuşi, unele dintre cele mai comune criterii pot fi:
 cost;
 capacitatea de a lucra cu softul dorit;
 viteza de prelucrare a unităţii centrale de prelucrare şi capacitatea ei;
 posibilităţile memoriei auxiliare;
 echipamentele de intrare/ieşire;
 capacitatea de a lucra în regim de comunicaţii;
 capacitatea sistemului şi posibilitatea de extensie;
 vârsta tehnologică (model nou sau vechi);
 compatibilitatea cu alte componente ale sistemului şi cu alte sisteme;
 evaluarea performanţelor;
 întreţinere uşoară;
 garanţia lui;
 probleme de natură financiară (reduceri, scutiri ş.a.).
9.3.5 Formularea cererilor de ofertă

Odată definite cerinţele sistemului, organizaţia este pregătită să invite furnizorii sau
consultanţii pentru a propune echipamentele şi programele ce răspund cerinţelor ei. Furnizorii
potenţiali sunt selectaţi pentru a se alege cei cu produsele cele mai convenabile pentru unitate.
Celor selectaţi li se va transmite un document numit Cerere de ofertă, prin care furnizorii să
poată emite oferte adecvate la datele concrete prezentate. Ofertele sunt evaluate şi se face
reţinerea celei mai bune variante de sistem sau a primelor două. Aceste sisteme se analizează în
profunzime pentru a testa modul cum răspund exigenţelor organizaţiei.
O cerere de ofertă poate fi formulată în două moduri. Ea poate să se refere la un software
anume şi la un anumit tip de hardware, situaţie în care furnizorii emit propuneri însoţite de
costurile sistemelor solicitate. Avantajul propunerilor concrete constă în costul mai mic,
precum şi în intervalul de timp mai redus necesar furnizorului să emită propunerile. Totuşi,
există dezavantajul că furnizorul nu poate propune tehnologii pe care clientul nu le ştie,
responsabilitatea selecţiei rămânând numai la latitudinea beneficiarului.
A doua modalitate de formulare a cererilor de ofertă constă în prezentarea unei forme
generalizate de definire a problemei şi cerinţelor sistemului. Varianta oferă furnizorilor
posibilitatea să propună diverse soluţii. Dezavantajul: o mai mare dificultate în selectarea cu
exactitate a ofertelor făcute.
Conţinutul cererii de ofertă constă în:
 informaţii generale introductive;
 descrierea actualului sistem de prelucrare automată a datelor, inclusiv a principalelor
echipamente şi aplicaţii existente în firmă;
 specificaţii pentru hardul şi softul strict necesare şi pentru cele ce ar fi dorite;
 cerinţele de securitate, protecţie ş.a.;
 o listă a elementelor pe care furnizorul să le ofere în propunerea lui;
 criterii de evaluare a propunerilor ce vor fi făcute;
 programul de realizare a implementării;
 restricţii de costuri;
 creşterea economică proiectată şi eventualele schimbări;
 solicitarea unor informaţii strict necesare clientului, descrierea programelor de

instruire şi contractul propus furnizorului (proforma).
9.4 Selectarea strategiei de proiectare

De cele mai multe ori, selectarea strategiei de proiectare reprezintă o sarcină dificilă, mai
ales în condiţiile diversificării continue a ofertei de produse şi servicii informaţionale de pe
piaţă, a oportunităţilor de informatizare existente astăzi.
De exemplu, în cazul variantelor de implementare, o soluţie poate fi ieftină, dar nu
acoperă toate funcţiunile cerute. Altă soluţie poate satisface toate cerinţele funcţionale, dar
rulează pe platforme hardware şi software nedorite sau implică o perioadă prea mare de
implementare. Dificultatea acestei activităţi este sporită de numărul mic de puncte comune
între diferitele variante, cum ar fi între cele de externalizare şi dezvoltarea sistemului în cadrul
firmei sau între soluţiile diferiţilor furnizori.
Cu toate acestea, analistul va trebui să identifice un set de criterii comune care să permită
compararea cât mai exactă a variantelor de implementare viabile. Este evident că nu toate
criteriile se pot aplica tuturor variantelor, însă există trei categorii de aspecte care trebuie luate
în considerare2: cerinţele generale, cerinţele funcţionale şi cerinţele tehnice.
Cerinţele generale privesc unele consideraţii care nu au legătură directă cu sistemele
informatice, dar care sunt importante. În primul rând, este vorba despre analizele de
fezabilitate, puse în discuţie în faza de analiză. Fiecare variantă luată în considerare trebuie să
fie fezabilă din punct de vedere economic, tehnic, juridic şi al programării în timp. De
asemenea, se vor lua în considerare criteriile de evaluare a furnizorilor, a stabilităţii şi
performanţelor lor. În cazul dezvoltării în cadrul firmei, se va ţine seama de riscurile asociate
proiectelor de dezvoltare a sistemelor informaţionale, precum timpul solicitat sau personalul de
specialitate disponibil. Câteva dintre criteriile care pot fi considerate aici sunt prezentate în
tabelul 9.2.
Cerinţele funcţionale se referă la funcţiile pe care trebuie să le îndeplinească sistemul. Ele
sunt evidenţiate în diagramele fluxurilor de date şi au fost puse în discuţie la generarea
variantelor de proiectare pe baza ariei şi nivelului de informatizare.
În categoria cerinţelor tehnice se includ toate celelalte cerinţe ale sistemului, care privesc
modul de operare, performanţele sale etc. O listă a criteriilor care pot fi încadrate în această
categorie se găseşte în tabelul 9.2.
Tabel nr. 9.2 – Criterii de evaluare a variantelor de implementare
Cerinţe generale Cerinţe tehnice
Performanţele înregistrare de furnizor Robusteţea (siguranţa în funcţionare)
Garanţiile şi facilităţile de service acordate Frecvenţa erorilor
de furnizor Calitatea programelor (uşurinţa întreţinerii)
Angajaţii cu experienţă disponibili Calitatea documentaţiei
Costul dezvoltării Uşurinţa instalării
Valoarea beneficiilor aşteptate Flexibilitatea (uşurinţa adăugării unor noi
Timpul necesar până la punerea în funcţiune funcţionalităţi)
Costurile estimate pentru conversia datelor Uşurinţa în exploatare (interfeţe prietenoase)
Impactul asupra firmei (instruirea Performanţe (timpul de răspuns)
utilizatorilor, schimbarea procedurilor Compatibilitatea cu platforma hardware şi software
interne etc)
O listă detaliată de criterii pentru evaluarea sistemului poate conţine următoarele aspecte:
 Pachetul selectat răspunde specificaţiilor obligatorii din cerere? Cât de bine?
2. Satzinger, J.W., Jackson, R.B., Burd, S.D. – Systems Analysis and Design in a Changing World, Course
Technology, Thomson Learning, Boston, 2002, p. 317.
 Va răspunde pachetul exigenţelor sistemului pe toată durata lui de utilizare? Va avea

nevoie de modificări?
 Softul conţine elemente adecvate de control?
 Caracteristicile tehnice sunt adecvate (viteză, precizie, siguranţă)?
 Alţi utilizatori sunt mulţumiţi de pachet? Ce probleme au avut? Ce limite au observat
la el?
 Documentaţia pachetului este bună? Va asigura furnizorul o altă documentaţie
concomitent cu modificările ce vor fi făcute asupra pachetului?
 Softul este compatibil cu ceea ce mai există în unitate?
 Pachetul este prietenos utilizatorului?
 Softul este disponibil oricând? Poate fi văzut şi testat?
 Pachetul are asigurată o garanţie?
 Softul este modularizat, flexibil şi uşor de întreţinut?
 Este posibilă exploatarea fişierelor prin sistemul interactiv (on-line)?
 Poate furnizorul să asigure actualizarea continuă a pachetului?
 Cât de eficient este softul? Cât timp ia în execuţie? De câtă memorie principală şi
secundară ar fi nevoie?
Propunerile de sistem pot fi evaluate prin diverse metode pentru a fi selectată cea mai
bună. O variantă este cea a cotelor de nivel, prin care este necesară executarea operaţiunilor
similare de intrare, prelucrare şi ieşire pe calculatoare diferite, selectându-se cele cu timpul de
prelucrare cel mai redus; a doua variantă – utilizarea modelelor matematice de simulare a
realizărilor fiecărui sistem propus; a treia – a punctajelor, în care sunt listate criteriile luate în
studiu, fiecare cu o greutate specifică în totalul criteriilor, acordându-se, pentru diferiţi
furnizori sau sisteme anume, note, în funcţie de modul în care este atins criteriul respectiv.
Selecţia se face după ce se ponderează greutatea specifică şi nota acordată, alegându-se suma
cea mai mare.
A patra variantă de evaluare se bazează pe aşa-zisele costuri necesare. Se întocmeşte o
listă a tuturor performanţelor ce ar trebui să fie îndeplinite de noul sistem. Dacă unele
performanţe nu există în anumite sisteme, se va calcula costul asigurării acestora. Costul total
va însuma costul de achiziţie a sistemului, precum şi costurile pentru atingerea performanţelor
care lipsesc. Sumele obţinute sunt elemente de comparabilitate, cât de cât unitare.
În finalul acestui paragraf, vom prezenta un exemplu de evaluare a variantelor strategiei
de proiectare, prin care vom lua în calcul doar variante legate de sursele softului. În acest sens,
vom utiliza metoda punctajelor.
Aplicarea metodei punctajelor presupune, mai întâi, identificarea criteriilor de evaluare şi
stabilirea importanţei relative a fiecăruia. Unele criterii sunt mai importante pentru organizaţie
decât altele. De exemplu, firma poate dori să cumpere doar de la un furnizor cu reputaţie, cu
multă experienţă. În altă situaţie, este posibil să existe suficient timp la dispoziţie până la
punerea în funcţiune a noului sistem, aşa că restricţiile de timp nu reprezintă o cerinţă critică.
Trebuie determinate nu doar importanţa relativă a criteriilor în cadrul categoriei din care
fac parte, ci şi importanţa relativă a categoriilor de cerinţe. O firmă poate considera mai
importante cerinţele generale decât cele funcţionale.
După identificarea criteriilor de evaluare şi determinarea importanţei lor relative, se trece
la evaluarea fiecărei variante, prin acordarea unei note pentru fiecare criteriu, apoi se
ponderează nota corespunzătoare fiecărui criteriu cu factorul ce reprezintă importanţa sa
relativă şi se însumează rezultatele obţinute în vederea obţinerii punctajului total. În final, va fi
selectată varianta cu punctajul cel mai bun.
În tabelul 9.3 sunt prezentate, pentru trei variante de implementare, criteriile de evaluare,
importanţa lor specifică, notele acordate şi punctajul obţinut. Atât pentru importanţa relativă,
cât şi pentru note, a fost utilizată o scară de valori de la 0 la 5.
Tabel nr. 9.3 – Evaluarea variantelor de implementare pentru sistemul de gestiune a clienţilor
Importanţa Varianta 1 Varianta 2 Varianta 3
Criterii de evaluare specifică (soft la comandă (soft la cheie) (soft la comandă
– în firmă) – specialişti din
afara firmei)
Criterii generale
Existenţa personalului 4 3 12 4 16 5 20
specializat
Costul dezvoltării 5 4 20 2 10 5 25
Valoarea aşteptată a 5 5 25 3 15 4 20
beneficiilor
Timpul de dezvoltare 4 3 12 5 20 2 8
Garanţii şi service 3 5 15 3 9 3 9
Total criterii generale 84 70 82
Criterii funcţionale
Înregistrarea comenzii 5 5 25 3 15 5 25
Crearea materialelor 4 5 20 0 0 5 20
promoţionale
Determinarea profilului 3 5 15 0 0 5 15
clienţilor
Urmărire clienţi în litigiu 3 5 15 5 15 5 15
Analiză vânzări 3 5 15 0 0 5 15
Controlul stocurilor 5 5 25 5 25 5 25
Generarea notei contabile 4 5 20 5 20 5 20
Avizare comenzi 4 5 20 0 0 5 20
Total criterii funcţionale 155 75 155
Cerinţe tehnice
Robusteţea 5 3 15 5 25 3 15
Erori de programare 4 3 12 4 16 3 12
Calitatea codului 4 4 16 5 20 4 16
Documentaţia 3 3 9 5 15 3 9
Uşurinţa instalării 2 5 10 4 8 4 8
Calitatea interfeţei 4 5 20 4 16 5 20
Total criterii tehnice 82 100 80
Total general 321 245 317
Din tabelul 9.3, rezultă că varianta cea mai bună o constituie dezvoltarea sistemului cu
specialiştii proprii. Varianta achiziţionării softului la cheie este cea mai slabă, datorită faptului
că multe din cerinţele funcţionale ale sistemului nu sunt satisfăcute de programele existente pe
piaţă. Pentru varianta a doua a fost luat în considerare cel mai bun program de pe piaţă. O altă
variantă, care putea fi luată în calcul, o reprezintă modificarea programului achiziţionat de pe
piaţă.
9.5 Conţinutul planului de bază al proiectului

După parcurgerea activităţilor menţionate anterior, finalizate prin cea mai importantă
dintre ele, selecţia variantei ce urmează a fi implementată, planul proiectului capătă alte
dimensiuni, ceea ce, în practică, poartă numele de planul de bază al proiectului. Structura unui
astfel de plan este redată în continuare:
1. Introducere
A. Prezentarea generală a proiectului. Se oferă o prezentare sintetică a proiectului, din care să
rezulte aria de întindere a proiectului, justificarea lui, necesarul de resurse şi planificarea
calendaristică. În plus, se face o scurtă prezentare a problemei, a cadrului în care urmează să se
implementeze proiectul, a restricţiilor ce pot afecta proiectul.
B. Recomandări. Se prezintă un sumar al principalelor aspecte ale procesului planificării şi se
formulează recomandări pentru activităţile următoare.
2. Descrierea sistemului
A. Variantele. O sumară descriere a variantelor de configuraţie a sistemului.
B. Descrierea sistemului. Descrierea configuraţiei selectate şi prezentarea detaliată a datelor de
intrare, a activităţilor executate, a informaţiilor care au rezultat.
3. Studiile de fezabilitate
A. Analize economice. Se oferă o justificare economică a sistemului, prin analizele cost-
beneficiu.
B. Analize tehnice. Se prezintă aspectele edificatoare ale factorilor de risc tehnic şi o ierarhizare
a factorilor de risc la nivel de proiect.
C. Analiza operaţională. Se oferă o analiză a modului în care vor fi rezolvate problemele
unităţii, fie interne, fie în relaţie cu competitorii, efectuându-se o evaluare a activităţilor zilnice în
noile condiţii.
D. Analiza legalităţii şi a contractelor. Sunt prezentate aspecte ale cadrului legal sau ale
riscurilor contractelor referitoare la proiect.
E. Analiza politicilor. Sunt oferite descrieri ale celor interesaţi de soarta proiectului şi ale
percepţiilor acestora faţă de ceea ce se propune.
F. Analiza desfăşurării calendaristice. Sunt puse la dispoziţie diferite variante ale planificării
calendaristice în strânsă concordanţă cu modul de alocare a resurselor.
4. Probleme ale managementului
A. Configuraţia şi managementul echipei. Sunt arătate rolurile membrilor echipei şi relaţiile
dintre ei în ceea ce priveşte raportarea.
B. Planul comunicării. Sunt oferite detalii despre procedurile de comunicare ce trebuie să fie
urmate de echipa managerială, de membrii echipei, precum şi de către beneficiari.
C. Standardele şi procedurile proiectului. Se descrie modul în care vor fi evaluate şi acceptate
rezultatele proiectului de către beneficiari.
D. Alte aspecte specifice proiectului. Sunt abordate orice alte probleme referitoare la proiect
care nu au fost descrise în punctele anterioare.
Rezumat
Până acum, în faza de analiză, ne-am ocupat de determinarea şi structurarea cerinţelor sistemului.
Altfel spus, s-a urmărit descrierea a „ceea ce este” şi a „ceea ce ar trebui să fie” sistemul informaţional.
Acum, ne aflăm înaintea fazei de proiectare, în care trebuie găsit răspunsul la întrebarea „cum” se va
parcurge drumul de la „ceea ce este” la „ceea ce ar trebui să fie” sistemul. În acest sens, o ultimă
activitate a fazei de analiză priveşte definirea strategiei de proiectare.
Strategia de proiectare specifică direcţia care va fi urmată, în continuare, în dezvoltarea noului
sistem. Definirea ei presupune parcurgerea a două activităţi principale: generarea variantelor strategiei
de proiectare şi selecţia celei mai bune strategii. Decizia finală, privind varianta de proiectare care va fi
urmată, aparţine utilizatorilor şi finanţatorului, acest aspect constituind motivul principal pentru care
trebuie ca echipa de realizare să formuleze mai multe variante de sistem. Cei mai mulţi specialişti
recomandă definirea a trei variante de proiectare.
Generarea variantelor strategice ale proiectului presupune considerarea unor probleme legate de
sistem, precum: aria de întindere şi nivelul de informatizare, sursele softului, selecţia furnizorilor.
Oricare ar fi ele, variantele proiectului trebuie să respecte două categorii esenţiale de condiţii, prezentate
sub forma funcţiilor obligatorii ale noului sistem şi a restricţiilor impuse.
Din punctul de vedere al soluţiilor de implementare, variantele posibile se regăsesc în cadranul
rezultat prin combinarea a două dimensiuni corespunzătoare opţiunilor achiziţionare/dezvoltare şi în
cadrul firmei/în afara firmei.
După formularea clară a variantelor de proiectare, se trece la evaluarea lor în vederea selectării celei
mai bune. Analiştii vor trebui să găsească criteriile de evaluare cele mai potrivite. În general, aceste
criterii pot fi grupate în trei categorii: cerinţe generale, funcţionale şi tehnice.
Pentru evaluare, poate fi aplicată metoda cotelor de nivel, modelele matematice de simulare,
metoda punctajelor sau cea bazată pe aşa-zisele costuri necesare.
Rezultatele activităţii de definire a strategiei de proiectare se concretizează în ceea ce, în practică,
poartă numele de planul de bază al proiectului. El conţine descrierea variantelor de sistem, recomandări,
studiile de fezabilitate efectuate şi alte probleme legate de managementul proiectului
1. Definiţi strategia de proiectare a sistemelor informaţionale.
2. Explicaţi necesitatea subfazei de definire a strategiei de proiectare.
3. Prezentaţi elementele componente al raportului detaliat ale cerinţelor sistemului.
4. De ce este recomandată formularea a trei variante de proiectare?
5. Descrieţi succint activităţile subfazei de definire a strategiei de proiectare.
6. Faceţi o scurtă prezentare a problemelor în legătură cu care se pot genera variante de proiectare.
7. Explicaţi rolul diagramelor fluxurilor de date în definirea strategiei de proiectare.
8. Care sunt opţiunile posibile de externalizare a serviciilor informaţionale?
9. Realizaţi o comparaţie între sursele de obţinere a softului.
10. Enumeraţi 7 criterii utilizate la evaluarea furnizorilor şi realizaţi o ierarhie a lor, din punctul de
vedere al importanţei.
11. Cum pot fi grupate criteriile de evaluare a variantelor de implementare? Daţi exemple din fiecare
categorie.
12. Care sunt metodele de evaluare a variantelor strategiei de proiectare?
13. Prezentaţi conţinutul planului de bază al proiectului.
Probleme de echipă
1. Definiţi trei variante de proiectare în legătură cu aria şi nivelul de informatizare pentru sistemul
analizat în propriul studiu de caz. Se va utiliza modelul prezentat în paragraful 9.3.1.
2. Formulaţi o cerere de ofertă pentru achiziţia de echipamente şi programe necesare sistemului
analizat în propriul studiu de caz.
3. Formulaţi trei variante de implementare pentru sistemul analizat în propriul studiu de caz, luând în
considerare sursele softului.
4. Evaluaţi cele trei variante prezentate la punctul anterior, utilizând metoda punctajelor. Se va utiliza
modelul prezentat în tabelul 9.3. Specificaţi varianta cea mai bună şi argumentaţi rezultatul obţinut.
Bibliografie generală
1. Adamec, F. – Project Management, apud Project and Grant Management, ETP Slovakia
Foundation, Budapest, Hungary, July 19, 1997.
2. Airinei, D. – Depozite de date, Ed. Polirom, Iaşi, 2002.
3. Ambler, S.W. – „In Search of a Generic SDLC for Object Systems”, in Object Magazine, 1994,
4(6).
4. Belanger, T.C. – Successful Project Management, American Management Association, USA, 1995.
5. Bîrjovanu, R.A. – „Cybermarket, cyberplăţi, bani digitali, frauda şi spălarea electronică a benilor în
Cyberspace”, în Computerworld, nr. 16 (86), 1997.
6. Boehm, B.W. – „A Spiral Model of Software Development and Enhancement”, in IEEE Computer,
1988, 21(5).
7. Bourne, K.C. – „Putting Rigour Back in RAD”, in Database Programming & Design, 7(8) (August
1994).
8. Bouzeghoub, M., Gardarin, G., Valduriez, P. – Object Technology – Concepts and Methods,
International Thomson Computer Press, Boston, 1997.
9. Brady, J.A., Monk, E.F., Wagner, B.J. – Concepts in Enterprise Resource Planning, Course
Technology, Thomson Learning, Boston, 2001.
10. Brown, D. – An Introduction to Object-Oriented Analysis: Objects in Plain English, John Wiley &
Sons, Inc., New York, 1997.
11. Carey, J. – Quality Management and Performance Measurement in Information Services, Carey
Project Organization, Ardmore, 1991.
12. Carmichael, A.R. – Object Development Methods, Andy Carmichael (ed.), SIGS Books, New York,
1994.
13. Celko, J. – „Data Flow Diagrams”, in Computer Language, 4, January 1987.
14. Chaffey, D. – E-Business and E-Commerce Management, Prentice Hall, Harlow, 2002.
15. Christel, M., Kang, K.C. – Issues in Requirements Elicitation, Technical Report, CMU/SEI-92-TR-
012, ESC-TR--92-012, 1992.
16. Churchill, Jr., G.A. – Basic Marketing Research, The Dryden Press, Chicago, 1988.
17. Coad, P., Yourdon, E. – Object-Oriented Analysis, Second Edition, Yourdon Press, Prentice Hall
Building, Englewood Cliffs, New Jersey, 1991.
18. Colectiv FIMAN, Centrul de consiliere în cariera profesională – Manual de înfiinţare şi operare,
Ed. Expert, Bucureşti, 1997.
19. Conger, S. – The New Software Engineering, Wadsworth Publishing Company, Belmont, 1994.
20. Curtis, G., Cobham, D. - Business Information Systems. Analysis, Design and Practice, Prentice
Hall, Upper Saddle River, New Jersey, 2002.
21. Cushing. B.E., Romney, M.B. – Accounting Information Systems, 6th Edition, Addison-Wesley
Publishing Company, Reading, Menlo Park, 1994.
22. Dawson, M.L. – The Accountability of an Enterprise Resource Planning System, May 7, 2002,
http://erp.ittoolbox.com (accesat pe 4 august 2004).
23. DeMarco, T. – Structured Analysis and Design Specification, Prentice Hall, Englewood Cliffs, New
Jersey, 1979.
24. Digital – A Guide to USE Digital Program Methodology, 1996.
25. Donaldson, S.E., Siegel, S.G. – Successful Software Development, Prentice Hall, Upper Saddle
River, New Jersey, 2001
26. Drăghici, M. – Noile tehnologii de vârf şi societatea, Ed. Politică, Bucureşti, 1980.
27. Farcaş, D. – Cui i-e frică de calculatorul electronic?, Ed. Albatros, Bucureşti, 1987.
28. Finkelstein, R. – „Understanding the need for on-line analytical servers”, in Ann Arbor,Comshare,
1994.
29. Finkelstein, R. – „When OLAP Does Not Relate”, in Computerworld, December 12, 1994.
30. Fotache, D., Hurbean, L. – Soluţii informatice integrate pentru gestiunea afacerilor – ERP, Ed.
Economică, Bucureşti, 2004
31. Gane, C., Sarson, T. – Structured Systems Analysis: Tools and Techniques, Prentice Hall,
Englewood Cliffs, New Jersey, 1979.
32. Garsombke, H.P., Trussell, L., Oprea, D. – The Accounting Profession and Education in
Romania, Midwest Accounting Society Meeting, Chicago, 1993.
33. Geller, D.P. – The Yin and Yang of Electronic Commerce, http://idm.internet.com.
34. Gibson, M.L., Hughes, C.T. – Systems Analysis and Design: A Comprehesive Methodology with
CASE, Boyd & Fraser Publishing/Company, Danvers, 1994.
35. Harel, D. – „Statecharts. A Visual Formalism for Complex Systems”, in Science of Computer
Programming, 8, 1987.
36. Hayes, E.M. – Project Management, CRISP Publication, Inc., California, 1989.
37. Henderson-Sellers, B. – Object-Oriented Metrics – Measures of Complexity, Prentice Hall PTR,
Upper Saddle River, New Jersey, 1996.
38. Henderson-Sellers, B., Edwards, J.M. – „The Fountain Model for Object-Oriented Systems
Development”, in Object Magazine, 3(2), 1993.
39. Hoffer, J.A., George, J.F., Valacich, J.S. – Modern Systems Analysis and Design, The
Benjamin/Cummings Publishing Company, Inc., Sand Hill Road, Menlo Park, 1998.
40. Hossain, L., Patrick, J.D., Rashid, M.A. – Enterprise Resource Planning. Global Opportunities &
Challenges, IDEA Group Publishing, Hershey PA, 2002.
41. Humphries, M., Hawkis, W.M., Dy, C.M. – Data Warehousing. Architecture and Implementation,
Prentince Hall PTR, New Jersey, 1999.
42. Hutt, A.T.S. – Object Analysis and Design: Foundation of Methods, John Wiley & Sons, Inc., New
York, 1994.
43. Igbaria, M, Anandarajan, M., Chen, C.C-H. – „Global Information Systems”, in Encyclopedia of
Information Systems, vol. 2, Academic Press, San Diego, 2003.
44. Ives, B., Jaravenpaa, S.L. – „Applications of Global Information Technology: Key Issues for
Management”, in MIS Quarterly, 159, 1991.
45. Jaba, E. – Statistica, Ed. Economică, Bucureşti, 1998.
46. Jacobson, I., Christerson, M., Jonsson, P., Övergoard, G. – Object-Oriented Software
Engineering: A Use Case Driven Approach, Addison-Wesley Publishing Company, Wokingham,
1992.
47. Kalakota, R., Whinston, A.B. – Frontiers of Electronic Commerce, Addison Wesley, Reading,
1996.
48. Kendall, K.E., Kendall, J.E. – Systems Analysis and Design, 5th Edition, Prentice Hall, Upper
Saddle River, New Jersey, 2002.
49. Kestenbaum, M.I., Straight, R.L. – „Paperless grants via the Internet”, in Public Administration
Review, 1996 56(1).
50. Kezsbom, D.S., Edward, K.A. – The New Dynamic Project Management, John Wiley & Sons, Inc.,
New York, 2001.
51. Koch, C. – The ABCs of ERP, Enterprise Resource Planning Research Center, March 7, 2002,
www.cio.com (accesat pe 3 august 2004).
52. Koory, J.L., Medley, D.B. – Management Information Systems: Planning and Decision Making,
South Western College Publishing, Cincinnati, 1990.
53. Kornai, J. – Antiequilibrium, Ed. Ştiinţifică, Bucureşti, 1974.
54. Kulik, P., Samuelsen, R. – „e-Project Management for the New Reality”, in PM Network, March
2001.
55. Laudon, K., Laudon, J.P. – Essentials of Management Information Systems: Organization &
Technology in the Networked Entreprise, 4th Edition, Prentice Hall, Upper Saddle River, New
Jersey, 2001.
56. Lewis, J.P. – The Project Manager’s Desk Reference, McGraw-Hill, New York, 2000.
57. Lientz, B.P., Rea, K.P. – Guide to Successful Project Management, Harcourt Brace Professional
Publishing, San Diego, 1999.
58. Luftman, J.N., Papp, R., Brier, T. – „Enablers and Inhibitors of Business-IT Alignment”, in
Communication of the Association for Information Systems, Volume 1, Article 11, 1999.
59. Malhotra, N.K. – Marketing Research – An Applied Orientation, Prentice Hall, Upper Saddle
River, New Jersey, 1996.
60. Marakas, G. M. - Systems Analysis and Design: An Active Approach, Prentice-Hall, New Jersey,
2001.
61. Marc, L., Songini, M. – „Procter&Gamble Unit Aims IT as Contract Monitoring”, in

Computerworld, January 28, 2002, www.computerworld.com
62. Martin, J. – Information Engineering, Prentice Hall, Inc., Englewood Cliffs, New Jersey, 1990.
63. Martin, J. – Rapid Application Development, Macmillan Publishing Company, New York, 1991.
64. Martin, J., McClure, C. – Structured Techniques: The Basis for CASE, Revised Edition, Prentice
Hall, Englewood Cliffs, New Jersey, 1988.
65. Martin, J., Odell, J.J. – Object-Oriented Methods: A Foundation, PTR Prentice Hall, Englewood
Cliffs, New Jersey, 1995.
66. McLeod Jr., R., Jordan, E. – System Development. A Project Management Approach, John Wiley
& Sons, Inc., New York, 2002.
67. McLeod Jr., R., Schell, G. – Management Information Systems, 8th Edition, Prentice Hall, Upper
Saddle River, New Jersey, 2001.
68. Meşniţă, G. – Introducere în afaceri electronice, Ed. Junimea, Iaşi, 2002.
69. Meşniţă, G., Dumitriu, F. – „Outsourcing of Information System Development”, în volumul
Innovative Applications of Information Technologies in Business and Management, Ed.
Tehnopress, Iaşi, 2002.
70. Meyer, B. – Object-Oriented Software Construction, Prentice Hall, New York, 1988.
71. Modell, M. – A Professional’s Guide to Systems Analysis, Second Edition, McGraw-Hill Company,
New York, 1996.
72. Moscove, S.A., Simkie, M.G., Bagranoff, N.A. – Core Concepts of Accounting Information
Systems, 8th Edition, Wiley&Sons, Inc., 2003.
73. Mowshowitz, A. – „Virtual Organization”, in Communications of the ACM, 40 (9), 1997.
74. Neagu, T., Oprea, D. – „Perfecţionarea programării calculatoarelor utilizând tabelele de decizie”, în
Analele Universităţii „Al. I. Cuza”, Iaşi, 1980.
75. O’Leary, D.E. – Enterprise Resource Planning Systems. Systems, Life Cycle, Electronic Commerce,
and Risk, Cambridge University Press, New York, 2000.
76. Oprea, D. – „De la ciclul de viaţă al sistemelor la cel al obiectelor”, în Tribuna Economică nr.
46/1998, 50/1998, 51/1998, 52/1998, 1/1999, 2/1999.
77. Oprea, D. – „Metode de abordare a sistemelor”, în Tribuna Economică nr. 40/1998, 42/1998,
43/1998, 44/1998.
78. Oprea, D. – Analiza şi proiectarea sistemelor informaţionale economice, Ed. Polirom, Iaşi, 1999
79. Oprea, D. – Managementul proiectelor. Teorie şi cazuri practice, Ed. Sedcom Libris, Iaşi, 2002.
80. Oprea, D. – Premisele şi consecinţele informatizării contabilităţii, Ed. Graphix, Iaşi, 1995.
81. Oprea, D. – „Globalizarea şi securizarea informaţională”, în Prelegeri Academice, Academia
Română, Filiala Iaşi, aprilie 2004.
82. Oprea, D. – Protecţia şi securitatea informaţiilor, Ed. Polirom, Iaşi, 2003.
83. Oprea, D., Dumitriu, F., Meşniţă, G. – CASE – proiectarea asistată de calculator a sistemelor
informatice, Ed. Universităţii „Al. I. Cuza” Iaşi, 1995.
84. Oprea, D., Meşniţă, G. – Sisteme informaţionale pentru manageri, Ed. Polirom, Iaşi, 2002.
85. Patriciu, V.V. – Sisteme electronice de plăţi, www.afaceri.net.
86. Plant, R. – eCommerce formulation of Strategy, Prentice Hall PTR, Upper Saddle River, New
Jersey, 2000.
87. Pressman, R.S. – Software Engineering, 3rd Edition, McGraw-Hill, New York, 1992.
88. Pressman, R.S. – Software Engineering. A Practioner’s Approach. European Adaptation, Fifth
Edition, McGraw-Hill Companies, London, 2000.
89. Priestley, M. – Practical Object-Oriented Design, The McGraw-Hill Companies, London, 1996.
90. Project Management Institute – A Guide to the Project Management Body of Knowledge, Upper
Darby, 1996.
91. Rappa, M. – „Business Models on the Web”, in Managing the Digital Enterprise,
http://digitalenterprise.org/models, April 10, 2002.
92. Restian, A. – Homo ciberneticus, Ed. Ştiinţifică şi Enciclopedică, Bucureşti, 1981.
93. Restian, A. – Unitatea lumii şi integrarea ştiinţelor sau INTEGRONICA, Ed. Ştiinţifică şi
Enciclopedică, Bucureşti, 1989.
94. Romney, M.B., Steinbart, P.J. – Accounting Information Systems, 9th Edition, Prentice Hall,
Upper Saddle River, New Jersey, 2003.
95. Royce, W.W. – „Managing the Development of Large Software Systems”, in Proceedings of IEEE,
WESTCON, San Francisco, 1970. Reprinted in Proceedings of the 9th International Conference on
Software Engineering, Monterey, 1987.
96. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorenson, W. – Object-Oriented Modelling
and Design, Prentice Hall International, Inc., New York, 1991.
97. Satzinger, J.W., Jackson, R.B., Burd, S.D. - Systems Analysis and Design in a Changing World,
Course Technology, Thomson Learning, Boston, 2002.
98. Schaaf, J.M. – „Building A Partnership Mosaic”, in The Forrester Report, January 2001,
www.channelwave.com/news_and_events/documents.
99. Shlaer, S., Mellor, S.J. – Object Lifecycles: Modeling the World in States, Prentice Hall,
Englewood Cliffs, New Jersey, 1992.
100. Skidmore, S. – Introduction Systems Analysis, Second Edition, Macmillan, London, 1997.
101. Skidmore, S. – Introduction Systems Design, Ncc Blackwell, Oxford, 1996.
102. Sommerville, I. – Software Engineering, 1st Edition, Addison-Wesley, Reading, 1989.
103. Songini, M.L. – „Global Supply Chains Rife with Challenges”, in Computerworld, March 12, 2001,
accesat la www.computerworld.com.
104. Sowa, J.F., Zachman, J.A. – „Extending and Formalizing the Framework for Information Systems
Architecture”, in IBM Systems Journal, 31(3), 1992.
105. Sperley, E. – The Enterprise Data Warehouse. Planning, Building and Implementation, Hewlett-
Packard Professional Books, Prentince Hall PTR, Upper Saddle River, New Jersey, 1999.
106. Stair, R.M., Reynolds, G.W. – Principles of Information Systems, 6th Edition, Course Technology,
Thomson Learning, Boston, 2003.
107. Stancovici, V. – „Filosofia informaţiei”, în Inteligenţa artificială şi robotică, Ed. Academiei R.S.R.,
Bucureşti, 1983.
108. Standish Group – CHAOS Report (1994), 1999, www.standishgroup.com.
109. Stewart, J.C., Cash, Jr., W.B. – Interviewing, Principles and Practices, Wm. C. Brown Publishers,
Dubuque, 1991.
110. Subramanian, G.H., Nosek, J., Raghuanthan, S.P., Kanitkar, S.S. – „A Comparison of Decision
Table and Tree”, in Communications of the ACM, 35, January 1992.
111. Sudman, S., Blair, E. – Marketing Research. A Problem-Solving Approach, Irwin/McGraw-Hill,
Boston, 1998.
112. Sully, P. – Modelling the World with Objects, Prentice Hall, New York, 1993.
113. Tardieu, H., Rochfeld, A., Colleti, R. – La Méthode Merise: Principes et Outils, 2e Édition,
Éditions & Organisation, Paris, 1991.
114. Turban, E., McLean, E., Wetherbe, J. – Information Technology for Management. Making
Connections for Strategic Advantage, John Wiley & Sons, Inc., New York, 2001.
115. Vanthienen, J. – „Technical Correspondence”, in Communications of the ACM, 37, February 1994.
116. Vessey, I., Weber, R. – „Structured Tools and Conditional Logic”, in Communication of the ACM,
29, January 1986.
117. Weisman, J. – „The Making of E-Commerce: 10 Key Moments”, in E-Commerce Times, August
2000, www.ecommercetimes.com/perl/printer/4085.
118. Whitmire, S.A. – Object Oriented Design Measurement, John Wiley & Sons, Inc., New York, 1997.
119. Wood, J., Silver, D. – Joint Application Design, John Wiley & Sons, New York, 1989.
120. Wysocki, R.K., DeMichiell, R.L. – Managing Information Across the Enterprise., John Wiley &
Sons, Inc., New York, 1997.
121. Yourdon, E., Argila, C. – Case Studies in Object Oriented Analysis & Design, Yourdon Press,
Prentice Hall Building, Upper Saddle River, New Jersey, 1996.
122. Yourdon, E., Constantine, L.L. – Structured Design, Prentice Hall, Englewood Cliffs, New Jersey,
1979.
123. Zwass, V. – Management Information Systems, ECB-Wm, C. Brown Publishers, Dubuque, 1992.
124. Zwass, V. – „Structure and macro-level impacts of electronic commerce: from technological
infrastructure to electronic marketplaces”, in Emerging Information Technologies, ed. K. Kendall,
Sage Publications, Thousand Oaks, 1998.
125. *** – Buyer’s Guide to Electronic Commerce. Glossary of Terms, www.wentworth.com.
126. *** – Electronic Commerce. An Introduction, Student Manual, ZD University, 1999.

Cap 5 9 Sifc

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Cap 5 9 Sifc

Încărcat de

Drepturi de autor:

Formate disponibile

CAPITOLUL V

Studierea sistemului existent

Capitolul de faţă se concentrează asupra activităţilor specifice etapei de analiză, în care

 ce se realizează în sistemul existent şi care sunt intrările, ieşirile şi procesele de

5.1 Tipuri de proiecte de dezvoltare a sistemelor informaţionale

5.2 Studierea sistemului existent

despre funcţiile îndeplinite de acesta.

concentrează atenţia asupra altor aspecte, şi anume:

- Solicitări de rafinare sau

 înţelegerea activităţilor, obiectivelor şi procedurilor existente în sistem şi firmă;

5.2.1 Analiza informaţiilor de ieşire

aspecte sunt importante pentru a se asigura transmiterea la timp a rapoartelor la fiecare

Analiza intrărilor trebuie să se facă în strânsă legătură cu analiza ieşirilor, pentru că

Fig. 5.1 Matricea intrărilor/ieşirilor sistemului de gestiune a comenzilor

5.2.3 Analiza modului în care sunt stocate, accesate şi păstrate datele

5.2.4 Analiza proceselor de prelucrare a datelor

 preluarea informaţiilor privind facturile emise pentru fiecare comandă;

Exemple de puncte slabe: inoportunitatea sau inexactitatea informaţiilor obţinute de

5.3 Identificarea proceselor de prelucrare ale sistemului

5.3.1 Tipuri de evenimente

5.3.2 Identificarea evenimentelor

evenimentele temporale, este

Fig. C5.1 Exemplu de tabel pentru descrierea unui eveniment

Câteva comentarii asupra termenilor utilizaţi.

Eveniment Declanşator Sursa Acţiunea Rezultat Destinaţie

rapoarte săptămână, automate privind comenzile comenzile

5.4 Determinarea cerinţelor pentru noul sistem

5.4.1 Surse de identificare a cerinţelor

5. Satzinger, J.W., Jackson, R.B., Burd, S.D. – op. cit., p. 113.

stabilite. Ca urmare, ei solicită informaţii statistice şi de sinteză din diferite sisteme.

În determinarea cerinţelor, o importanţă deosebită o are identificarea persoanelor care pot

 cerinţe normale (obligatorii), prezentate de analist în timpul întâlnirilor cu utilizatorii,

În unele cazuri, cerinţele funcţionale sunt bine documentate (regulile şi procedurile

calitatea informaţiilor de ieşire, din punct de vedere al momentului obţinerii lor, al

Metode de culegere a cerinţelor sistemului

De exemplu, personalul de vânzări poate să indice că primul lucru pe care îl realizează

6.1.1 Tipuri şi utilizări ale interviurilor

7. Persuasiunea se referă la interviurile care îşi propun să schimbe modul de gândire, de a

6.1.2 Paşii intervievării

Tema 1: întrebări 5 minute

Fig. 6.1 Ghid de derulare a interviului

Tabel nr. 6.3 – Tipuri de întrebări şi caracteristici ale acestora

Pas 1 Identificarea informaţiilor ce vor fi căutate

Pas 2 Stabilirea tipului de chestionar

Pas 3 Determinarea conţinutului

Pas 4 Stabilirea formei de redactare a

Pas 5 Formularea întrebărilor

Pas 6 Stabilirea secvenţei derulării întrebărilor

Pas 7 Stabilirea caracteristicilor

Pas 8 Reevaluarea paşilor 1-7 şi revizuirea lor,

Pas 9 Efectuarea pretestului şi revizuirea finală,

Fig. 6.3 Procedura conceperii chestionarului

Alegerea între interviu şi chestionar se poate efectua prin luarea în considerare a

6.3 Intervievarea grupurilor

Tabel nr. 6.5 – Caracteristicile interviului de grup

6.4 Observarea directă a utilizatorilor

7. Satzinger, J.W., Jackson, R.B., Burd, S.D. – op. cit., p. 126.

9. Satzinger, J.W., Jackson, R.B., Burd, S.D. – op. cit., p. 126.

în costul aşteptării desfăşurării activităţilor şi dificultatea evaluării acestora în mediul

6.5 Analiza procedurilor de lucru şi a altor documente

12. Kendall, K.E., Kendall, J.E. – op. cit., pp. 182-183.

Din documentele analizate se va încerca să se obţină informaţii despre:

6. Ce paşi se parcurg pentru planificarea şi desfăşurarea interviurilor de grup?