Suport Curs ASI 2016 - Online

Dumitru Oprea
Gabriela Meni Florin Dumitriu
ANALIZA SISTEMELOR
INFORMAIONALE
Suport de curs
Contabilitate i informatic de gestiune, anul 3, ZI

Informatic Economic, anul 3, ZI
Editura Universitii "Alexandru Ioan Cuza" din Iai

2016
2 ANALIZA SISTEMELOR INFORMAIONALE
SISTEM, SISTEM ECONOMIC, SISTEM INFORMAIONAL 3
Cuprins
CAPITOLUL I ...................................................................................................................... 7
Sisteme informaionale economice ....................................................................................... 7
1.1 Evoluia sistemelor informaionale economice .......................................................... 8
1.2 Tipologia sistemelor informaionale ......................................................................... 10
1.3 Ciclul prelucrrii datelor ........................................................................................... 13
1.3.1 Faza de culegere a datelor .................................................................................. 15
1.3.2 Pregtirea datelor ............................................................................................... 17
1.3.3 Prelucrarea propriu-zis a datelor ...................................................................... 18
1.3.4 Faza de stocare a datelor i ntreinere a fiierelor ............................................ 21
1.3.5 Obinerea ieirilor .............................................................................................. 22
Rezumat ...................................................................................................................... 22
ntrebri recapitulative ................................................................................................ 23
Probleme de echip ..................................................................................................... 23
CAPITOLUL II ................................................................................................................... 24
Sisteme informaionale pentru conducere .......................................................................... 24
2.1 Sistemele de prelucrare a tranzaciilor...................................................................... 24
2.1.1 Caracteristicile sistemelor de prelucrare a tranzaciilor .................................... 25
2.1.2 Obiectivele sistemelor de prelucrare a tranzaciilor .......................................... 25
2.1.3 Funciile sistemelor de prelucrare a tranzaciilor .............................................. 27
2.1.4 Componentele sistemelor de prelucrare a tranzaciilor ..................................... 28
2.2 Sistemele de informare a conducerii......................................................................... 29
2.2.1 Caracteristicile sistemelor de informare a conducerii ....................................... 30
2.2.2 Obiectivele sistemelor de informare a conducerii ............................................. 31
2.2.3 Funciile sistemelor de informare a conducerii ................................................. 32
2.2.4 Componentele sistemelor de informare a conducerii ........................................ 34
Rezumat ...................................................................................................................... 35
CAPITOLUL III.................................................................................................................. 37
Introducere n dezvoltarea sistemelor informaionale ........................................................ 37
3.1 Ciclul de via al dezvoltrii sistemelor informaionale ........................................... 38
3.1.1 Modelul cascad ................................................................................................ 39
3.1.2 Modelul V .......................................................................................................... 40
3.1.3 Modelul incremental .......................................................................................... 41
3.2 Definirea metodologiilor, modelelor, tehnicilor i instrumentelor ........................... 43
3.3 Prezentarea general a etapelor ciclului de via al sistemelor informaionale ........ 45
3.4 Participanii la dezvoltarea sistemelor informaionale ............................................. 49
Rezumat ...................................................................................................................... 52
CAPITOLUL IV ................................................................................................................. 54
Microanaliza sistemelor informaionale ............................................................................. 54
4.1 Identificarea i selecia proiectelor de dezvoltare a sistemelor informaionale ........ 54
4.1.1 Potenialele proiecte de dezvoltare .................................................................... 55
4.1.2 Clasificarea, ierarhizarea i selecia proiectelor de dezvoltare .......................... 57
4.1.2 Planificarea sistemului informaional ................................................................ 59
4.3 Iniierea i planificarea proiectelor de dezvoltare a sistemelor ................................ 68
4.4 Analizele de fezabilitate ........................................................................................... 75
Rezumat ...................................................................................................................... 76

CAPITOLUL V .................................................................................................................. 79
Studierea sistemului existent i determinarea cerinelor noului sistem .............................. 79
5.1 Tipuri de proiecte de dezvoltare a sistemelor informaionale .................................. 81
5.2 Studierea sistemului existent .................................................................................... 81
5.2.1 Analiza informaiilor de ieire ........................................................................... 83
5.2.2 Analiza datelor de intrare................................................................................... 86
5.2.3 Analiza modului n care sunt stocate, accesate i pstrate datele ...................... 89
5.2.4 Analiza proceselor de prelucrare a datelor ........................................................ 90
5.3 Identificarea proceselor de prelucrare ale sistemului ............................................... 93
5.3.1 Tipuri de evenimente ......................................................................................... 93
5.3.2 Identificarea evenimentelor ............................................................................... 95
5.4 Determinarea cerinelor pentru noul sistem.............................................................. 99
5.4.1 Surse de identificare a cerinelor ..................................................................... 101
5.4.2 Tipuri de cerine ............................................................................................... 103
Rezumat .................................................................................................................... 107
ntrebri recapitulative .............................................................................................. 108
Probleme de echip ................................................................................................... 108
CAPITOLUL VI ............................................................................................................... 110
Metode de culegere a cerinelor sistemului ...................................................................... 110
6.1 Intervievarea ........................................................................................................... 112
6.2 Chestionarele .......................................................................................................... 115
6.3 Intervievarea grupurilor .......................................................................................... 117
6.4 Observarea direct a utilizatorilor .......................................................................... 119
6.5 Analiza procedurilor de lucru i a altor documente ................................................ 121
Rezumat .................................................................................................................... 123
CAPITOLUL VII .............................................................................................................. 126
Modelarea logic, grafic, a proceselor de prelucrare ...................................................... 126
7.1 Introducere n modelarea sistemelor ....................................................................... 126
7.2 Descompunerea sistemului pe funcii de prelucrare ............................................... 130
7.3 Diagramele fluxurilor de date (DFD) ..................................................................... 133
7.3.1 Construirea diagramelor fluxurilor de date ..................................................... 136
7.3.2 Simboluri utilizate n construirea DFD............................................................ 138
7.3.3 Descompunerea diagramelor fluxurilor de date .............................................. 145
7.3.4 Reguli de construire a diagramelor fluxurilor de date ..................................... 154
7.4 Depozitul metadatelor ............................................................................................. 159
7.4.1 Descrierea fluxurilor de date ........................................................................... 162
7.4.2 Descrierea structurii de date ............................................................................ 163
7.4.3 Descrierea datelor elementare.......................................................................... 165
7.4.4 Descrierea locurilor de stocare ........................................................................ 167
7.4.5 Descrierea proceselor....................................................................................... 169
Rezumat .................................................................................................................... 172
CAPITOLUL VIII............................................................................................................. 174
Modelarea conceptual a datelor (diagramele entitate-relaie, DER) .............................. 174
8.1 Aplicarea principiului abstractizrii n modelarea datelor ..................................... 174
8.2 Culegerea informaiilor pentru modelarea conceptual a datelor........................... 176
8.3 Introducere n cadrul conceptual al diagramelor entitate-relaie (DER) ................ 179
8.4 Coninutul i etapele activitii de modelare conceptual a datelor ....................... 180

8.4.1 Identificarea entitilor de date ........................................................................ 181
8.4.2 Descrierea entitilor de date prin intermediul atributelor .............................. 182
8.4.3 Identificarea i descrierea relaiilor dintre entiti ........................................... 186
8.4.4 Modelul general al DER pentru sistemele informaionale .............................. 191
8.4.5 Alte situaii ntlnite n modelarea conceptual a datelor ............................... 195
Rezumat .................................................................................................................... 197
CAPITOLUL IX ............................................................................................................... 199
Selectarea variantei strategice de proiectare a sistemelor informaionale ........................ 199
9.1 Aspecte generale privind raportul cerinelor sistemului i selectarea variantei
strategice de proiectare ......................................................................................................... 199
9.2 Procedura de selecie a celei mai bune variante strategice de proiectare ............... 201
9.3 Generarea variantelor strategice ale proiectului ..................................................... 202
9.3.1 Variantele de proiectare privind aria de ntindere i nivelul de informatizare 203
9.3.2 Formularea variantelor de implementare ......................................................... 208
9.3.3 Selectarea furnizorilor ..................................................................................... 212
9.3.4 Selectarea hardului........................................................................................... 213
9.3.5 Formularea cererilor de ofert ......................................................................... 214
9.4 Selectarea strategiei de proiectare .......................................................................... 215
9.5 Coninutul planului de baz al proiectului .............................................................. 217
Rezumat .................................................................................................................... 218
Bibliografie general .................................................................................................... 220
CAPITOLUL I
Sisteme informaionale economice
Obiective:
Prezentarea sistemelor economice i a componentelor generale ale acestora
Definirea sistemelor informaionale i prezentarea evoluiei lor
Clasificarea sistemelor informaionale
Descrierea ciclului prelucrrii datelor
Conceptul de sistem informaional economic a fost definit n moduri diferite. De cele mai
multe ori, el este sinonim cu sistem informaional pentru conducere, iar cele mai dese referiri
se fac la aceast ultim variant, aa cum vom proceda i noi n continuare. Din toate
definiiile, rezult c el este un ansamblu de resurse umane i de capital, investite ntr-o
unitate economic, n vederea colectrii i prelucrrii datelor necesare producerii
informaiilor, care vor fi folosite la toate nivelurile decizionale ale conducerii i controlului
activitilor organizaiei.
Sistemul informaional pentru conducere nu trebuie tratat numai prin prisma
calculatorului electronic, deoarece i unitile care nu dispun de el beneficiaz de serviciile
unui astfel de sistem.
Termenul de sistem este deosebit de popular n domeniul informaticii, sub forma
diferitelor componente specifice: echipamente, persoane, software, date, funcii. Cu alte
cuvinte, el este alctuit din multiple elemente care interacioneaz pentru atingerea unui scop
comun.
Exist o strns legtur ntre sistemele fizice, existente la nivelul unei firme, i sistemul
informaional, considerat sistem logic, din urmtoarele considerente1:
sistemul fizic (real) este alctuit din bunurile corporale prin intermediul crora se
desfoar activitile oriecrei organizaii (firm, instituie guvernamental, banc,
instituie de nvmnt etc). Componentele sistemului fizic sunt cldirile, angajaii,
echipamentele, resursele materiale, banii, toate folosite pentru atingerea unor
obiective, cum ar fi obinerea profitului, recuperarea investiiilor, ctigarea unui
segment de pia, creterea cotaiei aciunilor pe piaa bursier etc.;
sistemul logic (reglat) reprezint mijloacele prin care se pot reda, din punct de vedere
logic, componentele sistemului fizic. Un astfel de sistem este, de exemplu, sistemul
de gestiune a stocurilor, n sensul c datele i informaiile pstrate de ctre acesta
reprezint articolele fizice de stoc, existente n diferite depozite ale firmei. Sistemul
stocurilor ofer rapoarte (pe hrtie sau n format electronic) ce conin informaii
despre existena diferitelor articole n stoc, despre operaiunile care s-au efectuat
asupra stocurilor. Diferii utilizatori autorizai vizualizeaz rapoartele pentru a urmri
evoluia stocurilor, ceea ce nseamn c nu este necesar s se deplaseze la fiecare
depozit pentru a vedea dac un anumit articol exist sau nu n stoc. Presupunnd c
raportul privind stocurile conine informaii corecte, managerii nu trebuie dect s-l
citeasc pentru a lua deciziile cuvenite.
1. McLeod Jr., R., Jordan, E. System Development. A Project Management Approach, John Wiley & Sons, Inc.,
New York, 2002, pp. 29-30.
Altfel spus, datele stocate n sistemele informaionale descriu elementele patrimoniale

afectate de diferitele activiti ale unei firme, iar programele, cu ajutorul crora sunt prelucrate,
redau, din punct de vedere logic, activitile pe care o firm le efectueaz.
n esen, componentele de baz ale unui sistem informaional economic sunt:
datele, ce reflect activitile economice desfurate ntr-o anumit perioad de ctre
o organizaie;
procedurile de prelucrare, manuale sau automate, prin care se culeg, prelucreaz i
stocheaz datele;
persoanele care folosesc (exploateaz) sistemul i execut diferite activiti cu
ajutorul sistemului;
programele utilizate pentru realizarea procedurilor de prelucrare a datelor;
echipamentele sau infrastructura fizic cu ajutorul crora se culeg, prelucreaz,
stocheaz, se transmit datele.
Importana sistemelor informaionale economice a crescut pe msur ce datele au devenit
resurs cheie pentru orice organizaie, alturi de resursele umane i materiale. Decidenii au
neles c informaia nu este numai un rezultat n sine, ci, mai curnd, materia prim a unei
afaceri i poate fi considerat factor hotrtor n determinarea succesului sau eecului acesteia.
ns, trebuie avut n vedere c producerea, distribuirea, asigurarea securitii, stocarea i
utilizarea informaiilor nseamn un efort financiar, de resurse umane, materiale din partea
oricrei firme. Dei informaia este peste tot, ea nu se ofer gratis, iar utilizarea ei, pentru
obinerea unei poziii competitive, trebuie s fie asociat cu un cost.
Reelele de calculatoare, accesul la Internet i dezvoltarea Web-ului au determinat o
explozie informaional fr precedent, att la nivelul societii, n general, ct mai ales la
nivelul afacerilor. Administrarea informaiilor generate automat, cu ajutorul calculatoarelor,
difer esenial de modalitatea manual de obinere a acestora. Costul pe care l presupune
organizarea i ntreinerea lor poate s creasc ntr-un ritm alarmant, iar utilizatorii trateaz,
adesea, acest aspect cu mai puin atenie dect s-ar cuveni.
1.1 Evoluia sistemelor informaionale economice

Este unanim acceptat ideea c informatica este unul dintre domeniile cu cele mai mari
schimbri nregistrate n ultimul timp. Cauza este clar: noile tehnologii, redate sintetic n
domeniu prin IT&C; astfel, se acrediteaz ideea c nimic nu este mai constant dect
schimbarea. n aceste condiii, specialitii i pun fireasca ntrebare: am reuit, oare, s
surprindem toate efectele ei, prin ceea ce ntreprindem?
Literatura de specialitate informatic, n spe, economic despre care nu se poate spune
c nu a existat nu a ajuns, nc, la un consens... noional. Se mai poart discuii dac
angrenajul utilizat pentru a oferi informaii celor interesai trebuie s fie numit sistem
informaional sau sistem informatic, cu referire la utilizarea calculatoarelor n acest scop. Cum
sistemul informaional cuprinde i sistemul informatic, folosirea primei forme ar fi mai
inspirat, mai ales n condiiile din ara noastr, unde, dup cum se tie, informatizarea n-a
atins cotele rilor dezvoltate, iar partea de prelucrare uman are nc o pondere substanial.
Cum, de regul, ne place s ne raportm la rile cu o bogat experien, s o facem i de
aceast dat, spunnd c, n literatura anglo-american, information system nseamn sistem
informaional, iar computer based information system este ceea ce noi considerm sistem
informatic. Adevrul este urmtorul: datorit nivelului tehnologic la care s-a ajuns n SUA, toi
autorii, dup ce fac delimitarea amintit, folosesc termenul de information system, motivnd
gradul ridicat de automatizare a activitilor care lucreaz cu informaia. Credem c este
normal, de vreme ce au trecut de mult timp la abordarea sistemelor n contextul fenomenului
de globalizare, preocupndu-se de hiul reelelor locale, metropolitane, naionale i
internaionale. Oare ne aflm n aceeai situaie?
Poate c n-am fi convingtori, dac n-am ncerca s lmurim lucrurile n continuare. n

ultimii 30 de ani, n literatura de specialitate, i-a facut apariia conceptul executive
information system, care ar trebui s dea mult de gndit celor care au tradus management
information system sub forma sistem informaional pentru conducere, pentru c i noua
apariie nseamn tot sistem informaional pentru conducere, numai c se refer la nivelul de
vrf al ei. Procesul de conducere se realizeaz pe cele trei niveluri: operativ, tactic i strategic,
deci nominalizarea unuia dintre ele constituie o condiie esenial a nelegerii tipului de sistem
informaional/informatic la care se face referire.
Oare, atunci cnd s-a tradus conceptul de management information system, aa cum am
menionat anterior, nu s-a inut cont de nivelurile la care se realizeaz procesul de conducere?
Ar fi o explicaie, ns putem aduce ca argument i nelegerea greit a cuvintelor
management, manager. De multe ori, se consider c managerul, printr-o traducere n form
superlativ, este similar cu director, conductor, ceea ce nu denot prea mult inspiraie,
prin ambiguitatea provocat. S nu uitm c, n limbajul americanilor, manager este i eful
unui depozit sau magazin, i administratorul unui bloc de locuine .a.m.d.
Din cele relatate, rezult dou posibile variante de utilizat pentru management information
system. O prim soluie ar consta n specificarea nivelului de conducere cruia i se adreseaz,
numindu-l sistem informaional al conducerii operative i/sau tactice, dei pentru conducerea
operativ exist o alt categorie a sistemelor informaionale, transaction processing system,
dup cum vom vedea n continuare. Aadar, trebuie fcut referire numai la nivelul de mijloc
al conducerii, cel tactic, ceea ce, s recunoatem, nu prea intr n uzanele noastre.
A doua variant, mai scurt i suficient de plauzibil, ar consta n utilizarea conceptului de
sistem informatic de gestiune, ntruct acesta este obiectivul lor prioritar. De multe ori, n loc
de management information system se folosete management reporting system, apropiindu-se
mai mult de forma sistem al rapoartelor de gestiune.
Probabil c, prin prezentarea n primul rnd a formelor de existen a sistemelor
informatice/informaionale, n ordinea apariiei lor, vom contribui la punctarea cu mai mare
claritate a diferenelor dintre ele.
Pentru faza embrionar a activitilor informatizate, la nivel operativ sau funcional, sau
de execuie, apare noiunea de Transaction Processing Systems (Sisteme de prelucrare a
tranzaciilor). Ele au aprut ndeosebi n domeniul contabilitii, ntruct, dup cum se tie,
utilizeaz un imens volum de date i are un sistem propriu perfect de verificare a corectitudinii
rezultatelor obinute. Ulterior, sfera acestor sisteme s-a extins i asupra marketingului,
personalului, fabricaiei .a. Ele i-au fcut apariia pe la mijlocul anilor 1950, avnd ca scop
principal colectarea datelor din domeniile specificate i sprijinirea activitilor curente prin
oferirea de informaii sub forma rapoartelor operative (de exemplu, centralizatorul intrrilor de
mrfuri).
Odat culese, datele au nceput a fi valorificate n mai multe moduri, unul constituindu-l
onorarea cererilor de informaii formulate de ctre nivelul superior de conducere, adic tactic,
fcndu-i apariia Management Information Systems (MIS) sau Management Reporting
Systems (MRS), despre care am discutat anterior. Obiectivul propus era de furnizare a
informaiilor pentru conducerea tactic, sub forma rapoartelor de gestiune i a altor situaii. Ele
i-au fcut apariia la nceputul anilor 1960. Prin apariia sistemelor integrate de tip ERP,
aproape c nu se mai face o delimitare net ntre TPS i MIS.
La nceputul anilor 1970, se ncearc trecerea spre uurarea procesului decizional, prin
preluarea unei pri din efortul organelor de decizie. Obiectivul prioritar nu mai era simpla
culegere a datelor, nici sintetizarea lor sub forma rapoartelor, ci uurarea procesului de luare a
deciziilor. i-au fcut astfel apariia Decision Support Systems (DSS), cunoscute la noi ca
sisteme suport pentru decizie, dei s-ar putea considera mai inspirat forma sisteme de
sprijinire a procesului decizional, evitndu-se, astfel, posibila concluzie c, pn la apariia
acestor sisteme, deciziile n-ar fi avut suport. Ulterior, aceste sisteme s-au specializat, prin
apariia sistemelor de sprijinire a proceselor decizionale de grup (Group Decision Support

Systems GDSS), ce ofer, n plus fa de DSS-uri, faciliti de negociere i comunicare ce nu
necesit prezena fizic a decidenilor n acelai loc. De asemenea, n aceeai categorie au
aprut sistemele de sprijinire a deciziilor la nivel organizaional (Organizational DSS), ce
permit fundamentarea unei decizii ce afecteaz mai multe componente organizaionale.
Nivelul strategic al conducerii este sprijinit, ntr-un mod aparte, prin noile Executive
Information Systems (EIS), dezvoltate puternic ncepnd cu mijlocul anilor 1980. Ele i
propun mult mai mult dect clasicul tablou de bord sau arhiuzitatele sisteme de rapoarte,
despre care muli conductori spuneau cu maliiozitate c i adormeau nainte de a apuca s le
citeasc n ntregime. Nici formele moderne de informare mult mai succint, prin grafice,
tabele, scheme, nu i-au mulumit. Veritabilii conductori, buni strategi, de multe ori sunt
interesai mai nti s tie ce fac alii, ce se ntmpl pe piaa global i abia apoi doresc s tie
detalii despre firma lor. O astfel de optic a deranjat pe muli realizatori de sisteme informatice
de gestiune, care i vd neglijat efortul muncii lor de ani de zile.
O explicaie se gsete tot n tehnologiile informaionale i de comunicaii (IT&C), de la
care am nceput discuia, fiindc odat cu apariia attor forme de ieire n lume, prin attea
tipuri de reele, care mai de care mai performante, este normal ca top-managerii s doreasc
s vad mai nti ce se ntmpl n ograda vecinilor lor, chiar dac ei se afl peste mri i
ri, fie i numai pentru a putea spune, conform afirmaiei lui Pascal, cnd m compar sunt
mulumit; cnd m analizez m detest.
Dup prezentrile fcute, considerm sugestiv fig. 1.1, care scoate n relief componentele
mediului de lucru al sistemelor informaionale folosite n conducerea organizaiilor economice.
SISTEME INFORMAIONALE PENTRU CONDUCERE
Sisteme de sprijinire a conducerii strategice

Sisteme de Birotica
Sisteme de sprijinire a procesului decizional, Sistemele
sprijinire a
inclusiv a celui de grup i organizaional grupurilor
experilor
de lucru
Sisteme de informare a conducerii
Sisteme de prelucrare a tranzaciilor
Date ii
Resurse umane
Software Comunica
Echipamente
speciale
MEDIUL INTERN
Informa
ii Structur
Resurse umane,
Sisteme pe funcii
materiale, financiare
Conducere organizatoric
MEDIUL EXTERN
Furnizori stitu ii
Clieni Investitori Organisme Diverse in
Concureni Bnci/Creditori guvernamentale
(Acionari)
Fig. 1.1 Componentele mediului de lucru al sistemelor informaionale
1.2 Tipologia sistemelor informaionale

ntruct n practic exist o diversitate de puncte de vedere privind sistemele
informaionale, ele depinznd de elementul dup care se face ncadrarea acestora, n cele ce
urmeaz ncercm s efectum o sintez a lor, n mod firesc, discutabil, dar i s propunem
noi criterii de clasificare, dup cum urmeaz:
1) Dup scopul urmrit prin sistemul informaional:

automatizarea activitilor de rutin;
informarea conducerii;
sprijinirea proceselor de comunicare;
sprijinirea procesului decizional;
sprijinirea grupurilor de lucru (inclusiv experi);
sprijinirea top-managerilor.
2) n funcie de elementul supus analizei:
sisteme informaionale orientate spre funcii;
sisteme informaionale orientate spre procese;
sisteme informaionale orientate spre date;
sisteme informaionale orientate spre obiecte;
sisteme informaionale orientate spre mesaje/comunicri;
sisteme informaionale orientate spre informaii tiinifice;
sisteme informaionale orientate spre cunotine specializate.
3) Dup modul de prelucrare a datelor:
sisteme de prelucrare manual;
sisteme de prelucrare mecanografic;
sisteme de prelucrare automat/electronic;
sisteme de prelucrare mixt.
4) Dup modul de organizare a datelor:
sisteme bazate pe fiiere clasice;
sisteme bazate pe tehnica bazelor de date: ierarhice, reea, relaionale, orientate-obiect,
neuronale;
sisteme mixte.
5) Dup metoda folosit n analiza i proiectarea sistemelor:
sisteme dezvoltate dup metoda sistemic;
sisteme dezvoltate dup metoda structurat;
sisteme dezvoltate dup metoda orientat-obiect;
sisteme dezvoltate dup metoda rapid (RAD);
sisteme dezvoltate dup metoda echipelor mixte (JAD);
sisteme dezvoltate dup metoda participativ (PD);
sisteme dezvoltate dup metoda prototipurilor.
6) Dup gradul de centralizare:
sisteme centralizate;
sisteme descentralizate.
7) Dup gradul de dispersie a resurselor sistemului informaional:
sisteme informaionale locale:
bazate pe sala calculatorului central;
bazate pe calculatoare de-sine-stttoare;
bazate pe reea local.
sisteme informaionale distribuite:
sisteme de prelucrare a datelor distribuite;
sisteme de prelucrare distribuit a datelor;
sisteme bazate pe Web.
8) Dup forma de exercitare a responsabilitilor de coordonare a activitilor de
informatic:
sisteme informatice coordonate de componente informatice proprii (centre, staii, oficii

de calcul);
sisteme informatice coordonate prin centre informaionale;
sisteme informatice coordonate prin teri (cunoscute sub numele de servicii
externalizate = outsourcing).
9) Dup beneficiarii activitii de informatizare:
sisteme informatice orientate spre utilizatorii finali;
sisteme informatice orientate spre factorii de decizie;
sisteme informatice orientate spre utilizatorii finali informatizai;
sisteme informatice orientate spre manageri informatizai.
10) Dup gradul de structurare a problemei de rezolvat, modul de formulare a
obiectivelor sistemului informaional i a cerinelor utilizatorilor sunt:
sisteme informaionale perfect structurate (PS, OC, CUC);
sisteme informaionale aproape structurate (PS, OC, CUN);
sisteme informaionale parial structurate (PS, ON, CUN);
sisteme informaionale total nestructurate (PS, ON, CUN);
sisteme informaionale complexe (incertitudine multipl);
unde:
PS = problem structurat;
OC = obiective clare;
ON = obiective neclare;
CUC = cerinele utilizatorilor sunt clare;
CUN = cerinele utilizatorilor sunt neclare.
11) Dup gradul de integrare:
sisteme neintegrate (insule de informaii);
sisteme parial integrate:
pe orizontal la acelai nivel decizional;
pe vertical la nivel de component a sistemului informaional (de regul, funcie a
ntreprinderii);
sisteme total integrate i pe orizontal (la nivelul tuturor palierelor decizionale) i pe
vertical (la nivelul tuturor componentelor sistemului informaional, de regul, funcii
ale ntreprinderilor):
cu integrare pe principiul fiierelor clasice;
cu integrare pe principiul bazelor de date.
12) Dup legtura cu tipul de structur organizatoric:
sisteme informaionale grefate pe structura funcional a unitii;
sisteme informaionale structurate pe compartimente/departamente (pe produse, pe
centre de profit, geografic, matriceal .a.);
sisteme informaionale mixte.
13) Dup tipul calculatoarelor care stau la baza sistemului informatic:
sisteme informatice bazate pe calculatoare foarte mari;
sisteme informatice bazate pe calculatoare mari;
sisteme informatice bazate pe minicalculatoare;
sisteme informatice bazate pe microcalculatoare.
14) Dup gradul de automatizare a activitilor de analiz i proiectare a sistemului
informaional:
sisteme informaionale dezvoltate pe baza analizei i proiectrii clasice (manuale);
sisteme informaionale analizate cu instrumente automate i proiectate clasic;
sisteme informaionale bazate pe instrumente diverse de automatizare a analizei i

proiectrii;
sisteme informaionale dezvoltate cu instrumente de tip:
CASE orizontal;
CASE vertical;
CASE integrat;
OPEN CASE;
EXPERT CASE.
15) Dup generaiile de calculatoare (x), limbajelor de programare (y) i reelelor (z)
folosite n sistemul informatic:
sisteme informatice de tip xyz
Exemplu: 110 generaia I de calculatoare;
generaia I de limbaje;
generaia 0 de reele.
16) Dup tipul reelei pe care se bazeaz sistemul informatic:
sisteme informatice bazate pe LAN (Local Area Network);
sisteme informatice bazate pe MAN (Metropolitan Area Network);
sisteme informatice bazate pe WAN/IAN (Wide/International Area Network);
sisteme informatice bazate pe reele fr fir (Wireless, gen Wi-Fi, WiMax, WideBand
.a.).
1.3 Ciclul prelucrrii datelor

Din definiia sistemelor informaionale se poate observa c ele ndeplinesc patru funcii
eseniale pentru activitatea unei firme:
1. colectarea datelor despre activitile desfurate ntr-o organizaie, elementele
patrimoniale afectate, precum i actorii care au participat la realizarea acestor
activiti, astfel nct angajaii, conducerea, alte entiti externe firmei pot analiza ce s-
a ntmplat n cadrul firmei ntr-o anumit perioad de timp;
2. prelucrarea datelor, transformarea lor n informaii (ieiri ale sistemului), precum i
stocarea lor;
3. asigurarea elementelor necesare efecturii controlului, prin care s se asigure
protejarea activelor firmei, inclusiv a datelor, i respectarea standardelor i regulilor
interne, care urmresc ca datele s fie disponibile atunci cnd sunt solicitate, sunt
corecte i prezint un grad mare de ncredere;
4. sprijinirea procesului decizional, avnd n vedere c cele mai multe dintre decizii se
bazeaz pe informaiile reflectate n sistemul informaional.
Sistemul informaional este un mijloc important de monitorizare a evenimentelor
(tranzaciilor/proceselor economice) care au avut loc, fiind o modalitate sigur de a determina
care au fost rezultatele activitilor desfurate, efectele acestora asupra elementelor
patrimoniale ale firmei, entitile care au participat la aceste aciuni, pentru a ti cui i este
atribuit responsabilitatea lor.
Schematic, modul n care sistemul informaional ar trebuie s reprezinte informaiile
generate de tranzaciile economice este redat n figura 1.2.
Tranzaciile economice genereaz o serie de date care trebuie s fie rezultatul unui set de
operaiuni, din momentul apariiei lor, pentru a permite obinerea de informaii semnificative,
referite la un loc prin noiunea de ciclu al prelucrrii datelor. Ciclul cuprinde cinci faze (fig.
1.3): culegerea datelor, pregtirea datelor, prelucrarea datelor, ntreinerea fiierelor i
obinerea informaiilor de ieire.
Faza de culegere a datelor este declanat, de obicei, de desfurarea unei activiti
economice i trebuie s urmreasc trei aspecte de baz:
identificarea fiecrui eveniment sau activitate care a avut loc;

elementele patrimoniale afectate de fiecare eveniment;
entitile (ageni, actori) interne sau externe care au participat la fiecare eveniment.
Exemplu general de reprezentare a unei tranzacii
Entitate
implicat 1
Element
patrimonial Eveniment
afectat
Entitate
implicat 2
Reprezentarea tranzaciei de vnzare
Client
Stoc produse
Vnzare
finite (mrfuri)
Personal desfacere
(agent vnzare,
vnztor)
Reprezentarea tranzaciei de plat a unui furnizor
Responsabil
financiar
Disponibiliti
Efectuare plat
bneti
Furnizor
Fig. 1.2 Informaiile despre activitile firmei pstrate de sistemul informaional

(prelucrare dup Romney, M.B., Steinbart, P.J. Accounting Information Systems, 9th Edition, Prentice
Hall, Upper Saddle River, New Jersey, 2003, p. 10)
De exemplu, n cazul vnzrii de produse (eveniment) ar fi util s se culeag urmtoarele

date:
data vnzrii;
momentul din zi n care a avut loc vnzarea (dac este o vnzare ntr-un magazin);
clientul cruia i s-au vndut produsele;
salariatul care a efectuat vnzarea;
valoarea total a vnzrii;
denumirea i cantitatea fiecrui produs vndut;
preul de nregistrare al fiecrui produs vndut;
preul de vnzare al fiecrui produs.
Dac are loc o vnzare pe baz de credit comercial, atunci sistemul ar trebui s surprind
i alte date, cum ar fi instruciunile privind livrarea produselor (data livrrii, modalitatea de
transport, delegatul), adresa unde se factureaz produsele i, dac este necesar, adresa unde se
vor livra produsele, dac nu este aceeai cu adresa sediului clientului etc.
Ca urmare, prin prelucrarea datelor trebuie s fie abordate dou mari categorii de
tranzacii economice:
att tranzaciile (evenimentele) interne, respectiv cele care au ca entiti/ actori

departamentele firmei, cum este cazul stabilirii necesarului de aprovizionat, lansarea
comenzii de aprovizionare, determinarea timpului lucrat de fiecare salariat, plata
salariilor, planificarea produciei etc.;
ct i tranzaciile externe, respectiv cele care implic participarea cel puin a unei
entiti din exteriorul firmei, ca de exemplu primirea comenzii de la un client,
primirea facturii de la furnizor, ncasarea contravalorii produselor vndute .a.m.d.
CULEGEREA
DATELOR
PREGTIREA DATELOR
PRELUCRAREA
DATELOR
NTREINEREA
FIIERELOR
OBINEREA INFORMAIILOR DE IEIRE
Fig. 1.3 Ciclul prelucrrii datelor
Fiecare ciclu tranzacional prelucreaz un numr mai mare sau mai mic de evenimente,
multe dintre ele fiind, totui, divizate n categorii mai mici, datorit numrului prea mare, a
particularitilor pe care le prezint sau a complexitii procesului de prelucrare. De exemplu,
majoritatea tranzaciilor prelucrate n ciclul privind vnzrile i ncasrile sunt legate fie de
vnzarea produselor, fie de ncasarea contravalorii bunurilor vndute.
1.3.1 Faza de culegere a datelor

Aceast faz cuprinde dou activiti fundamentale: observarea mediului care genereaz
datele, fie printr-un observator uman, fie prin diverse echipamente, respectiv nregistrarea
datelor fie prin scrierea lor n documentele surs, fie prin captarea i stocarea lor cu ajutorul
diferitelor echipamente.
Metodele de colectare a datelor pot fi grupate n directe (culegerea la surs) i indirecte

(culegerea tradiional a datelor).
Metoda tradiional de colectare a datelor presupune realizarea unui numr mare de
activiti, cele mai multe fiind manuale, cum ar fi culegerea de pe comenzile primite de la
clieni sau de pe listele de inventar, atunci cnd intervin modificri n structura stocurilor.
Introducerea datelor se realizeaz prin intermediul unor ecrane (formulare de preluare a
datelor) care sunt similare ca form, coninut i denumire cu documentul surs pe care l
reflect. Prin intermediul ecranelor de introducere a datelor se mbuntesc att controlul, ct
i corectitudinea datelor despre activitile economice. Controlul este mai eficient prin faptul
c se poate apela la:
1. achiziia de documente prenumerotate (facturi, chitane), urmrindu-se s nu fie omis
nici un document prin verificarea secvenei de numerotare;
2. secvenierea automat, prin atribuirea de numere pentru fiecare tranzacie nou.
Corectitudinea datelor este asigurat prin instruciunile sau mesajele privind datele ce
trebuie introduse, gruparea logic a categoriilor de informaii care se culeg, utilizarea check-
box-urilor pentru bifarea unui cmp sau a meniurilor de tip pull-down, pentru selecia de valori,
apelarea la diferite stiluri, culori, linii pentru separarea clar a cmpurilor care trebuie
completate.
Datorit numrului mare de activiti i a suporturilor pentru nregistrare utilizate, a
caracterului preponderent manual al acestor activiti i a numrului mare de persoane
implicate, metoda este costisitoare i produce numeroase erori.
Aceste deficiene reprezint motivul principal pentru care dezvoltarea sistemelor
informatice s-a orientat ctre metode directe de colectare a datelor, numite i metode de
culegere a datelor la surs. Aceste metode i propun automatizarea activitii de colectare a
datelor prin reducerea sau eliminarea majoritii activitilor, personalului i a suporturilor
pentru nregistrarea datelor necesare n metodele tradiionale.
O importan deosebit prezint echipamentele pentru introducerea direct a datelor,
respectiv scannerele de imagini i scannerele pentru recunoaterea optic a caracterelor OCR
(Optical Character Recognition Recunoaterea optic a caracterelor), schimbul electronic
de date (EDI Electronic Date Interchange), utilizarea codurilor bar pentru punctele de
vnzare (POS Point of Sale), tehnologia RFID (Radio-Frequency Identification),
echipamente de numrare sau cntrire a produselor obinute, echipamente de citire a
legitimaiilor salariailor pentru nregistrarea timpului la care au intrat/ieit din unitate etc.
De exemplu, citirea codului bar al unui produs cu ajutorul dispozitivelor de scanare este
mult mai rapid, asigurnd un grad de corectitudine mult mai mare dect dac s-ar introduce
manual. Scannerul citete codul bar al fiecrui articol i caut preul n tabela de produse. n
acelai timp, prin intermediul POS-urilor se interogheaz baza de date pentru determinarea
preului de vnzare al produselor cumprate i calcularea valorii pe care trebuie s o plteasc
un client, determinarea automat a cotei de TVA sau a taxei pe vnzri n rile unde nu se
folosete TVA, precum i posibilitatea de ncasare pe baz de card i nu cu numerar. Tipul
produselor i cantitatea din fiecare produs, data, momentul din zi i valoarea achiziiilor sunt
informaii folosite mai departe pentru actualizarea datelor privind stocurilor de produse,
identificarea profilului clientului etc. n continuare, pe baza tabelei de stocuri actualizat, se
poate genera un raport de atenionare a gestionarului c este necesar s se aprovizioneze cu noi
cantiti, atunci cnd stocul scade sub un anumit nivel. De asemenea, informaiile culese
privind vnzrile efectuate ctre un anumit client sau ale unui produs pot fi folosite pentru
realizarea de analize detaliate a vnzrilor, de genul cel mai bine vndut produs, momentele
din zi, sptmn cnd un produs a fost cumprat cel mai bine etc.
O situaie similar apare n cazul utilizrii cardurilor pentru evidena timpului lucrat de
salariai. Pe lng informaiile privind timpul lucrat pentru calculul salariilor, un astfel de
sistem poate ajuta firma s determine cte ore s-a lucrat pentru fiecare activitate sau proiect,
astfel c pot fi fcute ajustri i planificri mai bune ale timpului pentru viitoarele proiecte.
Metoda culegerii directe a datelor nu este lipsit ns de dezavantaje, n sensul c, la
apariia erorilor, e destul de dificil de identificat cauza sau locul de provenien a lor, costurile
dezvoltrii unui astfel de sistem nu sunt mici, dar comparabile cu cele pe care le presupune
metoda tradiional.
O alt cale, mai practic (pentru ntreprinderile noastre), de colectare direct a datelor
const n instalarea unei reele de calculatoare i dispunerea de terminale n diferite puncte din
ntreprindere (secii de producie, magazie, birouri) care s permit culegerea datelor la locul
producerii lor i transmiterea lor n vederea unei prelucrri centralizate, metod considerat
mixt i care combin avantajele celorlalte dou.
1.3.2 Pregtirea datelor

Pregtirea datelor const ntr-un numr de operaii executate asupra datelor pentru a
facilita prelucrarea lor ulterioar, i anume:
Clasificarea datelor, care implic atribuirea de coduri de identificare (simbol cont, cod
secie .a.), astfel nct datele s fie incluse n submulimile corespunztoare. De exemplu, este
mult mai uor s fie prelucrate datele privind facturile emise clienilor, dac facturile vor fi
numerotate conform unor reguli interne, respectnd i legislaia n vigoare, iar clienii vor fi
codificai dup o serie de criterii ct mai relevante, cum ar fi clieni externi/interni, clieni
strategici/clieni ocazionale. i gsirea informaiilor despre un client este mult mai rapid dac
se face dup un cod de 5-6 caractere i nu dup numele clienilor, care poate s aib i pn la
30 de caractere.
Gruparea datelor, adic acumularea intrrilor similare, pentru a fi prelucrate n grup (de
exemplu, gruparea facturilor emise fiecrui client sau pe perioade calendaristice etc.). Prin
grupare, prelucrarea datelor va fi eficientizat, asigurnd inclusiv posibilitatea obinerii de
informaii pe intervale de valori. Cineva din conducere ar putea fi interesat s afle care a fost
valoarea facturilor emise clienilor n prima decad a lunii. n condiiile n care prelucrrile se
fac manual, atunci gruparea datelor dup data emiterii facturii este unul din criteriile cele mai
bune pentru a transmite informaiile solicitate de conducere. Dac prelucrarea se face cu
ajutorul aplicaiilor informatice, atunci aceast operaiune de grupare nu este sesizabil de
utilizator, dar ea trebuie s fie disponibil prin procedurile aplicaiilor.
Verificarea datelor cuprinde o mare varietate de proceduri pentru controlul corectitudinii
datelor, nainte ca ele s fie prelucrate, cunoscut fiind principiul GIGO/GIGI (Garbage-In,
Garbage-Out sau, n varianta limbii romne, Gunoi-la-Intrare, Gunoi-la-Ieire). Cu alte
cuvinte, dac la culegerea datelor se apeleaz la varianta tradiional, atunci exist toate
ansele ca la erorile umane de introducere a datelor, informaiile regsite n rapoarte s fie
eronate. De exmplu, dac la introducerea unei facturi emise unui client se inverseaz dou cifre
ntre ele, atunci clientul s-ar putea s apar cu o datorie mai mare dect n realitate (risc de
neseriozitate n faa clientului i de reziliere a contractelor) sau cu o datorie mai mic (risc de
pierdere pentru firm). Prin aplicaii exist posibilitatea stabilirii unor proceduri de control i
verificare ncruciat, cum ar fi verificarea cifrei de control la introducerea CNP-urilor,
limitarea numrului de ore posibil de efectuat ntr-o lun de ctre un angajat, verificarea
soldurilor din conturile analitice comparativ cu soldul contului sintetic etc.
Sortarea datelor, prin care grupurile de date sunt aranjate n loturi de nregistrri, dup
criterii de ordonare numeric, alfabetic, alfanumeric sau de timp (cronologic). Operaiunea
este important pentru a extrage ntr-o anumit ordine informaiile necesare. De exemplu,
poate fi necesar la un moment dat s se evidenieze clienii care au datoriile cele mai mari ctre
firm sau produsele al cror stoc este mai mic dect o anumit cantitate. Sortarea datelor poate
fi fcut la cererea utilizatorilor sau poate fi realizat automat, prin aplicaii, n funcie de
modul n care au fost gndite prelucrrile de date i nevoile de informaii.
Cuplarea (fuziunea) a dou sau mai multor loturi de nregistrri ntr-unul singur. Aceast
operaiune, n situaia prelucrrilor automate, nu apare ca fiin necesar, ns n cazul
prelucrrilor manuale sunt strict necesare. De exemplu, se cupleaz toate loturile ce conin
nregistrrile privind facturile primite de la furnizori i plile ctre acetia. n felul acesta, se
asigur o cretere a eficienei prelucrilor propriu-zise de date, nemafiind necesar cutarea
datelor de un anumit tip.
Transmiterea datelor de la un punct la altul i transcrierea lor dintr-o form n alta, astfel
nct s se efectueze trecerea de la scrierea de mn la cea tipizat sau de la documentele scrise
la mediile specifice calculatoarelor. Sunt situaii cnd firmele nu au sisteme informatice
performante, nu sunt integrate, nu exist suficiente echipamente de prelucrare, motiv pentru
care de la un punct de lucru la sediul central datele se transmit pe un suport electronic, urmnd
a fi ncrcate n baza de date i prelucrate la nivelul ntregii firme. Altfel, dac sistemul este
integrat, iar infrastructura fizic permite comunicarea n timp real, datele generate de
tranzaciile economice de la un punct de lucru al firmei se vor reflecta automat n situaiile
generale ale acesteia, fr a mai fi necesar transcrierea i/sau transmiterea datelor dintr-un
format n altul.
Poate cea mai important activitate o reprezint verificarea datelor pentru validarea i
asigurarea corectitudinii lor, pentru a detecta orice problem ce ar fi putut interveni la
culegerea lor. De exemplu, datele privind cantitatea i preul produselor vndute trebuie s fie
numerice, iar denumirea produselor alfabetice sau alfanumerice, altfel datele neputnd fi
validate.
Adesea, codurile asociate unei anumite tranzacii trebuie s fie verificate n baza de date
pentru a controla existena datelor de identificare ale acelei categorii de tranzacii. Dac se
introduce un cod care nu se regsete n baza de date, tranzacia este refuzat pentru
prelucrrile ulterioare. Refuzarea la prelucrare a unei tranzacii nu este suficient, pentru c
sistemul trebuie s transmit mesaje prin care s specifice ce problem a aprut, ce corecii
trebuie fcute, dac este necesar s se reintroduc datele depistate a fi eronate n timpul
verificrii etc. De exemplu, un cod bar scanat trebuie s existe n tabela de produse. Dac el
nu poate fi citit sau nu exist n tabel, persoana care realizeaz operaiunea de scanare
primete instruciuni fie pentru rescanarea produsului, fie pentru introducerea manual a
codului.
1.3.3 Prelucrarea propriu-zis a datelor

Prelucrarea datelor poate s includ o varietate de activiti, cum sunt:
calculaiile cuprind formele de tratare matematic a datelor (calculul TVA pe o factur
emis unui client);
compararea supune unei examinri simultane dou sau mai multe tipuri de date ntre
care exist o legtur logic (soldul iniial i cel final);
sintetizarea este o activitate important prin care se comaseaz informaiile (generarea
totalului facturilor emise unui client, ntr-o perioad de timp);
filtrarea este o alt operaiune prin care se extrag datele ce vor fi supuse prelucrrilor
urmtoare (numai produsele a cror valoare de vnzare se ncadreaz ntr-un anumit
interval);
restaurarea, prin care sunt aduse datele din memorie ntr-o form accesibil omului,
pentru prelucrarea manual n continuare sau ntr-o form prelucrabil mai departe tot
pe calculator.
Prelucrarea datelor din tranzacii se poate face conform uneia din urmtoarele metode
elementare: prelucrarea pe loturi (batch processing) i prelucrarea n timp real (on-line
processing). Aceste dou metode privesc nu numai prelucrarea propriu-zis a datelor, ci i

celelalte faze ale ciclului de prelucrare (colectarea datelor, actualizarea bazei de date).
Prelucrarea pe loturi presupune, mai nti, acumularea datelor privind tranzaciile pe o
anumit perioad, dup care urmeaz prelucrarea lor periodic, chiar i n ceea ce privete
actualizarea bazei de date. n acest mod, se realizeaz utilizarea mai eficient a resurselor
informatice dect n cazul prelucrrii n timp real, mai ales n situaia n care tranzaciile
economice nu au o frecven mare, i se asigur un mai bun control asupra datelor.
Schematic, prelucrarea pe loturi a datelor este redat n figura 1.4.
Informaii (nu
Date privind Intoducere date reflect starea
tranzaciile, (pe loturi) curent, doar
cumulate perioade
pe loturi anterioare)
Prelucrare pe loturi
Fig. 1.4 Prelucrarea datelor pe loturi
Dezavantajele acestui tip de prelucrare deriv din faptul c datele din tabelele principale
ale bazei de date i informaiile din rapoarte sunt perimate n momentele prelucrrii lor, deci nu
se pot obine informaii la zi despre activitatea firmei. De aceea, prelucrarea pe loturi este
recomandat doar pentru acele aplicaii care nu necesit actualizarea bazei de date pe msur
ce au loc tranzaciile i atunci cnd sunt solicitate rapoarte doar la anumite intervale de timp
bine definite.
Este motivul pentru care se ncearc renunarea la prelucrrile pe loturi n favoarea
prelucrrilor n timp real (OLTP On-Line Transaction Processing). Acest tip de prelucrare
presupune colectarea i prelucrarea datelor n timp ce are loc o tranzacie, fr acumularea
datelor i tratarea lor periodic. n acest fel, se elimin activitile de grupare, sortare i
transcriere specifice prelucrrii pe loturi. Imediat ce are loc o tranzacie, datele sunt colectate
cu ajutorul diferitelor echipamente i stocate n fiiere cu acces direct, apoi sunt prelucrate n
vederea actualizrii tabelelor permanente ale bazei de date sau obinerii diverselor rapoarte.
Numai c introducerea prelucrrii n timp real necesit instalarea unei reele locale sau extinse
care s lege ntre ele terminalele i calculatoarele aflate la diferite posturi de lucru din
organizaie.
Cele mai ntlnite sisteme informaionale bazate pe prelucrri n timp real se regsesc n
bncile care au instalate ATM-uri (bancomate) i n sistemele de rezervare ale companiilor
aeriene.
Sistemele informaionale bazate pe prelucrarea n timp real ofer marele avantaj al
furnizrii imediate de informaii actuale. n schimb, ele presupun i o serie de dezavantaje
legate de integrarea numeroaselor proceduri de control privind protejarea coninutului bazei de
date mpotriva accesului neautorizat sau a distrugerii accidentale a datelor (multe organizaii
in un jurnal de control n care sunt nregistrate toate tranzaciile care au avut loc).
n realitate, puine sisteme informaionale se bazeaz doar pe prelucrri n timp real. Cele
dou metode de prelucrare a datelor pot fi combinate, n funcie de obiectivele urmrite i de
particularitile organizaiei.
O comparaie ntre cele dou tipuri de prelucrri este realizat n tabelul 1.1.
Odat cu dezvoltarea tehnologiilor data warehouse i a data marts-urilor, prelucrarea on-
line nu mai era suficient, pentru c nu permitea cutarea i interogarea bazelor de date
multidimensionale. Ca rezultat, i-a fcut apariia o nou modalitate de prelucrare a datelor,
cea analitic on-line (OLAP On-Line Analytical Processing), pentru a memora, prelucra i
transmite informaii specifice depozitelor de date. OLAP permite utilizatorilor s exploreze
datele firmei din mai multe perspective/dimensiuni.
Tabel nr. 1.1 Comparaie ntre prelucrarea pe loturi i prelucrarea n timp real
Caracteristic Prelucrarea pe loturi Prelucrarea n timp real
Prelucrarea Datele tranzaciilor sunt colectate, Datele tranzaciiilor sunt prelucrate
datelor grupate, sortate, transcrise i apoi imediat ce ele au fost produse.
prelucrate periodic.
Actualizarea Dup prelucrarea lotului. Dup prelucrarea tranzaciei.
fiierelor
Timpul de rspuns Mai multe ore sau zile, dup ce lotul Cteva secunde dup producerea
de date a fost prelucrat. tranzaciei
Instrumentele i serverele OLAP sprijin analiza datelor incluse n relaii complexe, cum
ar fi combinaii ntre produsele firmei, regiuni geografice unde au fost vndute, canale de
distribuie, perioade de vnzri etc. Dac la nceput OLAP era folosit n special pentru
planificrile financiare, ulterior a devenit din ce n ce mai utilizat n domeniile ce solicit
analize rapide, aa cum este cazul investiiilor pe piaa aciunilor, marketingului, lansrii pe
pia a unui nou produs, determinrii profitabilitii unui client etc.
Caracteristicile OLAP sunt2:
ofer posibilitatea analizei datelor de tip drill-down (descompunere pe niveluri din ce
n ce mai detaliate), bazate pe interogri n baze de date multidimensionale, pe mai
multe dimensiuni ale problemei ce urmeaz a fi studiat;
presupun o mare ingeniozitate uman i o puternic interaciune cu bazele de date
pentru gsirea informaiilor necesare;
solicit testarea repetitiv a ipotezelor emise de utilizatori pentru identificarea
faptelor.
n figura 1.4 sunt ilustrate componentele necesare pentru efectuarea analizelor cu
instrumentele OLAP.3
OLAP Server
Client PC
Baza de date a
corporaiei
Baza de date
operaional
Baza de date Minidepozite de date
multidimensional Depozite de date
Foi de calcul
Pachete statistice
Software OLAP ce poate
rula cu browsere Web
Fig. 1.4 Componentele necesare unui sistem pentru analize OLAP
Datele sunt extrase din baza de date a firmei i depozitate ntr-o baz de date
multidimensional, de unde vor fi interogate de aplicaiile instalate la utilizatori. Interogrile
OLAP presupun efectuarea unor analize asupra datelor, cum ar fi4:
Consolidarea implic agregarea datelor, care poate nsemna o simpl adunare sau poate fi
o grupare dup criterii complexe ce in de relaiile dintre date. Ca exemplu, vnzrile locale pot
fi cumulate la nivel de zon i ulterior la nivel de regiune.
Analiza drill-down (pe niveluri de detaliere) reprezint operaia invers consolidrii, prin
care datele consolidate sunt analizate n detaliu, ajungndu-se la datele care le-au compus. Ca
2. Stair, R.M., Reynolds, G.W. op. cit., p. 211.

3. Finkelstein, R. Understanding the need for on-line analytical servers, in Ann Arbor, Comshare, 1994.
4. Oprea, D., Meni, G. Sisteme informaionale pentru manageri, Ed. Polirom, Iai, 2003, pp. 63-64.
exemplu, analiza vnzrilor unui produs sau ale unui agent de vnzri din totalul vnzrilor
nregistrate ntr-o regiune;
Analiza de tip slicing and dicing (feliere la ntmplare/aleatoare) se refer la
posibilitatea de a efectua analize din diferite puncte de vedere, innd cont de diferite criterii.
De exemplu, se pot analiza toate vnzrile unui anumit tip de produs ntr-o anumit regiune (o
felie din total), n timp ce o alt interogare poate arta totalul vnzrilor produsului respectiv
printr-un anumit canal de ditribuie. Aceste analize sunt efectuate, de regul, n funcie de
anumite axe (cum ar fi axa timpului) pentru a determina anumite tendine sau tipare.
Dintre cei mai cunoscui furnizori de software OLAP se numer Cognos, Hyperion
Solutions, Oracle, MineShare, WhiteLight, Microsoft.
n ultima perioad, tot n scopul prelucrrii cantitilor mari de date, au aprut noi
tehnologii, ntre care mai importante sunt Cloud Computing i Data Analytics, care vin n
sprijinul Big Data.
Cloud Computing-ul este o combinaie de conexiuni rapide Internet, cu puteri de calcul,
multe i ieftine, bazate pe Web, prin folosirea de soft complex pentru monitorizarea i
gestiunea activitilor de prelucrare, indiferent de locaia geografic. Cloud Computing
reprezint un set distribuit de servicii de prelucrare, aplicaii, acces la informaii i stocarea
datelor, fr ca utilizatorii s cunoasc amplasarea i configuraia fizic a sistemelor care
asigur aceste servicii. Mai este vzut i ca un sistem de resurse de tip low cost.
Data Analytics reprezint modalitatea de a analiza date brute cu scopul de a extrage o
serie de concluzii pe baza acestor informaii. Data Analytics se utilizeaz n multe domenii,
pentru a permite organizaiilor s ia cele mai bune decizii n domeniul lor de activitatea, iar n
cazul diferitelor tiine s se verifice i valideze modele i teorii. Data Analytics difer de data
mining prin domeniul de aplicare, scopul i orientarea analizelor efectuate. Analitii sorteaz
seturi uriae de date folosind software specializat pentru a identifica modele noi i pentru a
descoperi conexiuni imposibil altfel de determinat. Data Analytics se bazeaz pe deducie i
inferenele logice cunoscute de cei care sunt implicai n procesul de analiz.
1.3.4 Faza de stocare a datelor i ntreinere a fiierelor

n faza de ntreinere a fiierelor exist mai multe activiti, dintre care amintim:
stocarea datelor n vederea utilizrii lor viitoare;
actualizarea datelor memorate astfel nct s surprind cele mai recente evenimente;
indexarea datelor pentru a nlesni o uoar regsire a lor;
protecia datelor memorate, care cuprinde o mare varietate de proceduri i tehnici
pentru prevenirea distrugerii lor sau a accesului neautorizat.
Aceast activitate este necesar pentru a organiza datele ntr-o manier uor accesibil
pentru prelucrrile ulterioare.
Baza de date actualizat n cadrul sistemelor de prelucrare a tranzaciilor va oferi datele
necesare utilizrii n celelalte tipuri de sisteme informaionale (de informare a conducerii, de
sprijinire a procesului decizional, de informare a top-managerilor).
n sistemele informatice se ntlnesc dou tipuri de fiiere5:
1. fiiere de tranzacii, numite i fiiere temporare, care reflect activitatea curent a
organizaiei i conin date privind tranzaciile pe o anumit perioad (de regul, un an
sau o lun). Un fiier de tranzacii este temporar i prin faptul c este solicitat pn la
actualizarea celor permanente (uneori, numai datorit legii pot fi reinute). Fiiere
temporare pot fi cele de vnzri, cumprri, pli etc.;
2. fiiere permanente, care reflect starea curent a unor elemente din organizaie, stare
care se schimb ca rezultat al tranzaciilor efectuate, motiv pentru care fiierele de
5. Oprea, D. op. cit., 1995, p. 55.

tranzacii vor fi prelucrate n vederea actualizrii fiierelor permanente. Un fiier este

permanent i prin aceea c el este nedefinit ca timp de utilizare, chiar dac nregistrri
individuale pot fi frecvent introduse, terse sau modificate. Fiierele permanente,
numite i nomenclatoare, pot fi fiierele de materiale, clieni, personal etc.
Simplificnd puin lucrurile, putem spune: datele privind tranzaciile sunt memorate n
fiiere temporare, iar prin prelucrarea acestora se actualizeaz fiierele permanente.
Actualizarea datelor din fiierele permanente se poate realiza i n mod direct, atunci cnd
este necesar modificarea adresei unui furnizor sau client, preul unui produs, salariile
angajailor etc.
1.3.5 Obinerea ieirilor

n urma prelucrrii i stocrii datelor, se pot obine trei mari categorii de ieiri:
documente, rapoarte ori rspunsuri la ntrebri. Termenul ieiri le cuprinde pe toate, fiecare
dintre ele putnd fi obinute pe suport de hrtie sau afiate pe ecran. n principiu, documentele,
cu excepia cazului n care se apeleaz la EDI (Electronic Data Interchange), se genereaz pe
suport de hrtie, cum ar fi factura emis pentru vnzarea produselor, obinut pe baza datelor
nregistrate de pe comanda primit de la un client.
Un raport privind facturile emise ntr-o perioad de timp pentru un anumit client sau
pentru toi clieni ar putea fi obinut pe hrtie sau afiat pe ecran.
Rspunsurile la ntrebri, de cele mai multe ori, sunt generate pentru afiarea lor pe
ecranul calculatorului, pentru c adesea ele reprezint o solicitare temporar a unei informaii
privind o anumit tranzacie, o anumit resurs sau un anumit actor, care nu este necesar s fie
pstrat sau arhivat.
Adesea, ieirile unui sistem sunt folosite ca intrri n alte sisteme. De exemplu,
actualizarea tabelei de stocuri permite crearea unui raport de excepie pentru acele produse ale
cror stocuri au sczut sub un anumit nivel i care necesit o reaprovizionare.
n sintez, se poate spune c, de cele mai multe ori, datele nu parcurg toate activitile de
prelucrare, iar unele dintre ele pot chiar s nu treac prin cele cinci stadii (faze). De exemplu,
unele date pot fi colectate, prelucrate i stocate simultan, fr s mai parcurg alte operaiuni
de pregtire. Pe de alt parte, anumite date externe (despre concureni) ajung direct la
manageri, fr s mai fie supuse altor prelucrri. Dar astfel de cazuri constituie mai degrab
excepii, i nu reguli. De aceea, studiul sistemului informaional trebuie s se concentreze
asupra tuturor stadiilor de prelucrare a datelor.
Rezumat
O categorie aparte a sistemelor o constituie sistemul informaional, ntlnit deseori n viaa de zi cu
zi, fiind caracterizat de cele trei aspecte comune regsite la orice sistem: sunt constituite din mai multe
componente, ce interacioneaz ntre ele, n vederea realizrii unui scop comun. Sistemul informaional al
unei organizaii este cel care red, din punct de vedere logic, componentele fizice ale organizaiei i
aciunile care au loc n interiorul sau cu exteriorul ei.
Sistemul informaional este un ansamblu de resurse umane i de capital, investite ntr-o
organizaie, n vederea colectrii i prelucrrii datelor necesare producerii informaiilor, care vor fi
folosite la toate nivelurile decizionale ale conducerii i controlului activitilor organizaiei.
Evoluia sistemului informaional de la primele forme, n care prelucrarea se fcea primordial
manual, pn la noile forme, bazate pe Web reflect progresul tehnologiilor informaionale i de
comunicaii, schimbrile intervenite n strategiile i cerinele organizaionale, creterea luptei pentru
ctigarea avantajelor competitive etc.
Din definiie se poate observa c sistemul informaional ndeplinete patru funcii eseniale pentru
activitatea unei firme: (1) colectarea datelor despre activitile desfurate ntr-o organizaie, (2)
prelucrarea datelor, transformarea lor n informaii i stocarea, (3) asigurarea elementelor necesare
efecturii controlului, (4) sprijinirea procesului decizional.
Pentru realizarea funciilor specifice, datele generate de tranzaciile economice sunt supuse unui set
de operaiuni, din momentul apariiei lor, pentru a permite obinerea de informaii semnificative, cuprinse
la un loc prin noiunea de ciclu al prelucrrii datelor. Ciclul cuprinde cinci faze: culegerea datelor,
pregtirea datelor, prelucrarea datelor, ntreinerea fiierelor i obinerea informaiilor de ieire.
ntrebri recapitulative
1. Care sunt principalele elemente componente ale unui sistem informaional?
2. Exemplificai cel puin 3 criterii de clasificare a sistemelor informaionale.
3. Explicai de ce un tabel i un grafic privind evoluia vnzrilor unui produs reprezint componentele
logice ale unui sistem.
4. Care sunt principalele categorii de sisteme informaionale, plecnd de la criteriul managerial?
5. Enumerai sistemele informaionale care nu se ncadreaz pe nici un nivel decizional, dar le sprijin
activitatea.
6. Care sunt elementele unei tranzacii economice pe care un sistem informaional trebuie s le reflecte?
7. Exemplificai fiecare activitate din ciclul prelucrrii datelor.
8. Prezentai diferenele dintre prelucrarea datelor pe loturi i prelucrarea n timp real.
Probleme de echip
1. Descriei principalele caracteristici ale sistemelor informaionale ce pot fi identificate mtr-o
organizaie i ncadrai-le n cel puin trei criterii de clasificare cunoscute. Motivai alegerile fcute.
2. Prezentai principalele tranzacii economice pe care ar trebui s le suprind sistemele informaionale
identificate ntr-o organizaie. Se cer:
analiza modului n care aceste tranzacii sunt prelucrate i explicarea a ceea ce se ntmpl n
fiecare etap a ciclului de prelucrare a datelor;
identificarea principalelor documente pe care firma le folosete pentru a culege date relevante
despre tranzaciile identificate la punctul anterior;
enumerarea principalelor rapoarte obinute. Ce decizii pot fi influenate de aceste rapoarte?
CAPITOLUL II
Sisteme informaionale pentru conducere
Obiective:
Descrierea principalelor categorii de sisteme informaionale
Cunoaterea principalelor tipuri de sisteme de prelucrare a tranzaciilor
Identificarea elementelor ce caracterizeaz sistemele de informare a conducerii
n cele ce urmeaz, vom descrie principalele sisteme informaionale, n deplin

concordan cu practica firmelor, respectiv dup scopul pentru care au fost dezvoltate, cu
referire la sprijinirea nivelurilor de conducere.
La prezentarea fiecrei categorii de sisteme (sistemele de prelucrare a tranzaciilor,
sistemelor de informare a conducerii, sistemele de sprijinire a procesului decizional) vom avea
n vedere caracteristicile specifice, obiectivele urmrite, funciile ndeplinite, precum i alte
elemente, n funcie de particularitile lor.
2.1 Sistemele de prelucrare a tranzaciilor

Orice organizaie care desfoar zilnic activiti financiare, contabile, de producie i
altele este supus unor sarcini repetitive i de rutin. De exemplu, salariaii sunt pltii la
intervale regulate de timp (chenzina I i chenzina a II-a, sau o dat pe lun), clienii comand
produse i li se factureaz valoarea lor la livrare, iar cheltuielile de producie i administraie
sunt monitorizate i comparate periodic cu nivelul bugetat.
Scopul de baz al sistemelor de prelucrare a tranzaciilor l constituie culegerea, validarea
i nregistrarea datelor despre tranzaciile economice. De fapt, se urmrete cunoaterea
modului n care sunt utilizate resursele unei organizaii economico-sociale. De asemenea,
sistemele de prelucrare a tranzaciilor pun la dispoziie date de intrare pentru aplicaiile
specifice altor componente ale sistemelor informaionale, cum sunt sistemele de informare a
conducerii tactice i cele de sprijinire a procesului decizional.
Pentru abordarea acestei categorii de sisteme este necesar s se neleag conceptul de
tranzacie economic, adic principalele activiti i funcii ntlnite la nivelul unei firme, n
care intervin doi sau mai muli participani din interiorul sau exteriorul ei, i prin care este
afectat, la un moment dat, structura patrimonial a acesteia. Ca exemple pot fi date plata
salariilor, angajarea sau disponibilizarea salariailor, achiziia de resurse materiale sau de
echipamente, plata furnizorilor, vnzarea de produse, ncasarea facturilor emise clienilor,
obinerea produselor finite, amortizarea echipamentelor etc.
La nivelul sistemelor de prelucrare a tranzaciilor, exist mai multe subsisteme (aplicaii),
care lucreaz independent unele de altele sau sunt integrate ntr-un sistem performant, ce
permit prelucrarea tuturor tranzaciilor, indiferent de natura lor. Important este c fiecare
component reflect tranzaciile economice specifice, prin prelucrarea datelor generate de
acestea, i nu reflect componenta organizatoric n care au loc acele tranzacii. De multe ori,
apar confuzii ntre ceea ce realizeaz fiecare dintre compartimentele funcionale ale unei firme
i funciile pe care le ndeplinesc sistemele informaionale pentru a reflecta operaiunile
economice ale acestora. Este adevrat c finalizarea multor tranzacii economice presupune
implicarea mai multor componente organizatorice, dar prelucrarea datelor privind acele
tranzacii nu este obligatoriu s se realizeze acolo unde au avut loc. De exemplu, sistemul
SISTEME INFORMAIONALE PENTRU CONDUCERE 25
privind gestiunea clienilor presupune culegerea datelor de la biroul desfacere, depozite, biroul
financiar, ceea ce nseamn c acest sistem nu poate fi localizat ntr-un singur birou,
prelucrarea datelor putndu-se realiza n oricare dintre cele trei birouri sau n toate, n funcie
de responsabilitile de prelucrare alocate fiecruia. Un alt exemplu este cel n care prelucrarea
datelor se face centralizat, ntr-un departament specializat, gen oficiu sau staie de calcul. Ca
urmare, nu putem identifica sau pune semnul egal ntre sistemul de eviden a clienilor i
biroul desfacere sau departamentul informatic.
Sistemele de prelucrare a tranzaciilor rmn, cu toate evoluiile tehnologice, cea mai
important categorie de sisteme informaionale dintr-o organizaie, pentru c reprezint
principalul instrument prin care firma poate s interacioneze direct cu mediul extern i asigur
informaii despre ceea ce se ntmpl n firm. Pentru c managerii sunt tentai s solicite tot
mai mult informaii de ultim or i nu informaii despre evenimentele trecute, este esenial ca
aceste sisteme s funcioneze fr ntreruperi i fr erori. Este cazul sistemelor de comer
electronic, pentru c, n esen, sistemele de prelucrare a tranzaciilor sunt cele pe care trebuie
s se bazeze funcionarea comerului electronic.
Plecnd de la aceste consideraii generale, ncercm s prezentm principalele
caracteristici, obiective, funcii i aplicaii ale sistemelor de prelucrare a tranzaciilor.
2.1.1 Caracteristicile sistemelor de prelucrare a tranzaciilor

Caracteristicile de baz ale sistemelor de prelucrare a tranzaciilor (SPT), prin prisma
datelor i informaiilor cu care lucreaz, sunt:
repetitivitate datele folosite n prelucrare, precum i informaiile generate au caracter
repetitiv, ncadrndu-se n anumite intervale de timp (zilnic, sptmnal, decadal,
chenzinal etc.);
predictibilitate informaiile ce se obin nu au un caracter surprinztor pentru cei care le
utilizeaz sistematic, fiind scontate;
temporalitate bazate pe trecut, urmrind descrierea unor activiti care au avut loc deja
n cadrul organizaiei;
detaliere informaiile puse la dispoziie trebuie s fie att de analitice, nct s permit
realizarea controlului valorilor patrimoniale i al modului n care au fost utilizate
resursele;
structurare att datele de intrare, ct i informaiile rezultate sunt puternic structurate,
pentru c exist posibilitatea predefinirii i anticiprii lor. Ca urmare, o mare parte a
deciziilor de la acest nivel sunt programabile, fcnd posibil automatizarea proceselor
de prelucrare;
exactitate decurge att din formularea corect i fr ambiguitate a cerinelor
informaionale, ct i din multiplele verificri la care sunt supuse datele nainte, n timpul
i dup procesul de prelucrare.
2.1.2 Obiectivele sistemelor de prelucrare a tranzaciilor

Dintre obiectivele care trebuie atinse prin utilizarea sistemelor de prelucrare a
tranzaciilor, cele mai importante sunt:
1. Asigurarea unui nivel ridicat al corectitudinii i integritii datelor
Obiectivul poate fi ndeplinit prin eliminarea erorilor de introducere a datelor i a celor de
prelucrare. Chiar nainte de introducerea tehnologiilor informaionale, salariaii verificau toate
documentele i rapoartele preluate i generate de ctre sistemele de eviden existente.
Pentru c eroarea este uman, n perioada prelucrrilor manuale, de multe ori,
corectitudinea informaiilor oferite era pus sub semnul incertitudinii, genernd eforturi
suplimentare pentru verificarea i validarea lor.
n condiiile prelucrrilor automate, o aplicaie privind calculul salariilor ar trebui s aib

capacitatea de a semnala sau bloca operaiunea de introducere a numrului 400 n loc de 40,
pentru c este o valoare eronat atunci cnd reprezint numrul de ore lucrate de un salariat
ntr-o sptmn (o astfel de verificare intr n categoria validrilor logice ale datelor).
Pe lng corectitudinea datelor, sistemele operaionale trebuie s asigure i integritatea
lor, prin care se ncearc depistarea i evitarea prelucrrii frauduloase a tranzaciilor. De
exemplu, firmele de comer electronic se confrunt poate cel mai mult cu o astfel de problem,
n special n ceea ce privete acceptarea plilor prin carduri de debit sau de credit. Una dintre
marile ntrebri care s-a ridicat n momentul proliferrii comerului electronic a fost: Cum pot
aceste firme s fie sigure c persoana care cumpr este cea care pretinde c este? O
modalitate de verificare const n utilizarea certificatului digital, adic a unui fiier ce servete
att ca identificator al cardului, ct i ca o semntur a celui care l deine.
Pe msur ce volumul datelor prelucrate i memorate a crescut, a devenit din ce n ce mai
dificil s fie verificate toate datele de intrare. Dar cum datele i informaiile generate de
sistemele de prelucrare a tranzaciilor sunt utilizate de alte sisteme informaionale, este esenial
s se asigure corectitudinea i integritatea datelor. Prin controlul tranzaciilor se realizeaz, de
fapt, controlul organizaiei.
2. Generarea la timp a documentelor i rapoartelor cerute de utilizatori
Prelucrarea manual a tranzaciilor, pentru a pune la dispoziia celor interesai informaiile
cerute, chiar i de rutin, poate dura cteva zile. Din fericire, apelarea la tehnologiile
informaionale i de comunicaii reduce deosebit de mult timpul de rspuns al sistemelor, astfel
c prelucrarea tranzaciilor se poate face ntr-un timp foarte scurt (de multe ori, n timp real,
aa cum s-a vzut n capitolul anterior), ceea ce constituie un avantaj competitiv al firmei.
De exemplu, dac facturile emise clienilor sunt transmise acestora cu cteva zile mai
devreme dect de obicei, ncasarea poate avea i ea loc ntr-un timp mai scurt. Dac plata se
face n n zile de la data facturrii, iar aceasta se realizeaz mai devreme cu m zile, plata va fi
onorat tot cu m zile mai devreme, deci o vitez de circulaie mult mai mare a fluxurilor
monetare.
Timpul este esenial pentru aplicaiile ce asigur prelucrarea comenzilor primite de la
clieni, facturarea, ncasarea, controlul stocurilor, efectuarea plilor, mbuntind, cel mai
adesea, fluxurile de trezorerie ale firmei.
3. Creterea productivitii muncii
nainte de apariia calculatoarelor, prelucrrile manuale presupuneau existena unui numr
mare de salariai care s asigure prelucrarea tuturor datelor despre tranzaciile economice. n
prezent, implementarea tehnologiilor informaionale i de comunicaii conduce la reducerea
substanial a personalului i a altor cerine specifice prelucrrilor manuale, firmele fiind din
ce n ce mai interesate de eficientizarea activitii personalului.
De exemplu, Procter&Gamble1 a implementat un sistem de contractare i gestionare a
relaiilor comerciale, astfel nct atunci cnd un nou contract este semnat de o anumit divizie,
aplicaia calculeaz automat valoarea serviciile/produselor oferite, valoarea discount-urilor i
alte elemente specifice vnzrilor, dup care este verificat fiecare tranzacie pentru a se
asigura c au fost respectai toi termenii contractuali. Sistemul a eliminat multe dintre
problemele privind facturrile i a redus substanial efortul personalului pentru rezolvarea
acelor probleme.
4. Ajutor oferit pentru servicii de calitate
Fr discuie, am devenit o societate orientat ctre servicii. Chiar i marile companii
orientate spre producie au realizat c nu numai produsul livrat este important pentru a te
1. Marc, L., Songini, M. Procter&Gamble Unit Aims IT as Contract Monitoring, in Computerworld, January 28,
2002, www.computerworld.com.
menine sau ctiga un segment de pia, ci i calitatea serviciilor care nsoesc acel produs. De
aceea, sistemele de prelucrare a tranzaciilor trebuie s sprijine firma n identificarea celor mai
bune soluii pentru asigurarea unor servicii eficiente i de calitate.
De exemplu, prin implementarea sistemelor EDI (Electronic Data Interchange) se ofer
clienilor un mijloc mai comod i mai eficient de transmitere a comenzilor, eliminndu-se
astfel metodele tradiionale (telefon, fax, pot), greoaie i generatoare de erori. Acum,
varianta comerului electronic i aplicaiile mobile fac acest proces mult mai eficient i mai
rapid.
5. Sprijin n construirea i meninerea loialitii clienilor
Sistemele de prelucrare a tranzaciilor ofer un mijloc eficient de comunicare cu clienii,
iar asigurarea unei interaciuni eficiente cu celelalte sisteme ale firmei contribuie la
satisfacerea cerinelor clienilor i i determin s revin la serviciile acesteia.
6. Obinerea de avantaje competitive
Sistemele de prelucrare a tranzaciilor pot veni n sprijinul firmei pentru a obine beneficii
semnificative pe termen lung. Dintre cele mai importante avantaje ce pot fi obinute prin
implementarea sistemelor de prelucrare a tranzaciilor, amintim: creterea loialitii clienilor,
oferirea unor servicii de calitate superioar, relaii mai bune cu furnizorii, reducerea costurilor
i a nivelului stocurilor etc.
n funcie de natura i scopul firmelor, oricare dintre obiectivele enumerate anterior pot
avea un grad de importan mai mare sau mai mic. Prin atingerea lor, sistemele de prelucrare a
tranzaciilor pot sprijini obiectivele generale ale firmei, respectiv reducerea costurilor,
creterea productivitii, a calitii produselor i serviciilor, a gradului de satisfacere a
cerinelor clienilor, realizarea mult mai eficient a activitilor economice.
2.1.3 Funciile sistemelor de prelucrare a tranzaciilor

La nivelul conducerii operaionale, care urmrete asigurarea desfurrii n condiii
normale a activitilor economice, sistemul informaional trebuie s realizeze urmtoarele trei
funcii:
1. prelucrarea tranzaciilor;
2. obinerea rapoartelor;
3. realizarea controlului.
Prelucrarea tranzaciilor este esenial pentru orice activitate, ea realizndu-se zilnic. Ce
s-ar ntmpla dac o firm ar trebui s funcioneze fr sisteme de prelucrare a tranzaciilor
chiar i pentru o zi? Cum s-ar cunoate cu exactitate ce salarii ar trebui pltite tuturor
salariailor pentru o lun? Care au fost vnzrile unei zile, care trebuie s fie prelucrate i
nregistrate?2
Obinerea rapoartelor reprezint principalul mijloc prin care managerii de pe nivelurile
de mijloc i strategic intr n posesia informaiilor privind performanele firmei, pe baza crora
au posibilitatea stabilirii planurilor i pot identifica principalele tendine din evoluia viitoare a
firmei.
Realizarea controlului trebuie s asigure c informaiile generate de aceste sisteme
ndeplinesc o serie de caracteristici, prin care se ofer utilizatorilor un mare grad de ncredere
asupra rapoartelor primite.
2. Stair, R.M., Reynolds, G.W. Principles of Information Systems, 6th Edition, Course Technology, Thomson
Learning, Boston, 2003, p. 21.
2.1.4 Componentele sistemelor de prelucrare a tranzaciilor

Principalele componente (subsisteme) ce se regsesc n cadrul unui sistem de prelucrare a
tranzaciilor sunt: creane (vnzri), datorii (aprovizionare), gestiune comenzi primite de la
clieni, stocuri, salarii, producie .a. Dar structurarea sistemelor de prelucrare a tranzaciilor
depinde de mai muli factori, dintre care cei mai importani sunt:
domeniul de activitate al firmelor (producie, comer, turism, hotelier, bancar etc.);
modul de organizare a unitii (structura organizatoric);
mrimea firmei (microntreprinderi, ntreprinderi mici i mijlocii, firme mari, companii
naionale, trusturi, grupuri de firme etc., conform legislaiei n vigoare);
structura conducerii (centralizat sau descentralizat);
modul de organizare a prelucrrii datelor (centralizat sau descentralizat);
gradul de integrare a sistemelor.
n cele ce urmeaz, prezentarea principalelor sisteme de prelucrare a tranzaciilor va
reflecta o structurare principial, regsit pentru o firm cu activitate de producie, o structura
organizatoric funcional3, centralizarea puterii decizionale i a prelucrrii, dar i un grad
redus de integrare a componentelor sistemului.
n tabelul 2.1, sunt redate, n sintez, principalele subsisteme de prelucrare a tranzaciilor,
cu aplicaiile specifice fiecrui subsistem.
Tabel nr. 2.1 Aplicaiile de baz ale subsistemelor de prelucrare a tranzaciilor
Subsisteme de prelucrare a tranzaciilor Principalele aplicaii ale subsistemelor
Subsistemul privind gestiunea creanelor Gestiunea vnzrilor
Gestiunea comenzilor
Facturare i ncasare
Gestiunea clienilor
Subsistemul privind gestiunea datoriilor Gestiunea comenzilor de aprovizionare
Recepia bunurilor
Gestiunea achiziiilor
Gestiunea furnizorilor
Pli
Subsistemul de producie Proiectare produse
Programare producie
Lansare i execuie producie
Gestiune stocuri
Planificarea resurselor materiale
Raportarea produciei
Sistem de gestiune a calitii
Aplicaii pentru proiectarea produciei (CAD, CAM)
Subsistemul privind gestiunea resurselor Eviden personal
umane Pregtire i perfecionare
Urmrirea normelor (de timp sau cantitative) efectuate
Calcul drepturi salariale
Calcul reineri
Eviden performane profesionale
Eviden programe de pregtire i instruire profesional
Subsistemul financiar-contabil Contabilitate general
Calculaie costuri
Impozite i taxe
Bugetare
Analize economico-financiare
Conturi de ncasri i pli (prin cont curent sau banc)
3. Structura n care angajaii cu activiti similare cum sunt marketing, producie, contabilitate sunt grupai ntr-o
subunitate (departament, serviciu sau birou) a organizaiei.
n final, se poate spune c sistemele de prelucrare a tranzaciilor reflect cel mai bine
operaiile i activitile economice de rutin, repetitive, ns critice pentru funcionarea zilnic
a unei firme.
2.2 Sistemele de informare a conducerii

Acest nivel al sistemelor se cldete pe sistemele de prelucrare a tranzaciilor. Beneficiile
oferite de ultimele sunt cuantificabile i necuantificabile. Beneficiile din prima categorie pot fi
uor identificate pentru justificarea costurilor implicate de echipamente, programe informatice,
personal specializat i alte resurse folosite n funcionarea lor. Cele din a doua categorie sunt
mai greu de evaluat, pentru c sunt de natur calitativ, iar impactul lor nu se vede imediat.
Totui, exist anumite modaliti prin care i beneficiile necuantificabile pot fi evaluate i
msurate. De exemplu, prin generarea n regim on-line a rapoartelor privind relaiile cu clienii,
managerii pot lua anumite decizii de cretere a profitabilitii, prin stabilirea unor politici
difereniate de tratare a lor. n final, rezultatul deciziilor poate fi o sporire a tranzaciilor cu
clienii, implicit obinerea de venituri mai mari.
Aa cum am vzut, sistemele de prelucrare a tranzaciilor determin o cretere a vitezei de
derulare a activitilor economice i reducerea costurilor cu personalul administrativ. Dar, cu
timpul, firmele au realizat c datele stocate la nivelul acestor sisteme pot fi utilizate i pentru a
ajuta managerii n luarea celor mai bune decizii n sfera lor de aciune, nu numai la nivel
operaional, ci i la nivelul managementului tactic i strategic. Satisfacerea cerinelor
informaionale a fost i este un factor determinant pentru dezvoltarea sistemelor de informare a
conducerii.
La acest nivel, sistemele informaionale trebuie s asigure informaiile necesare stabilirii
planurilor i bugetelor de desfurare a activitilor, care, n majoritatea cazurilor, sunt decizii
ce privesc gestionarea resurselor ntreprinderii, supravegherea i controlul.
Sistemele de informare a conducerii nu le nlocuiesc pe cele de prelucrare a tranzaciilor.
Principala lor int const n eficientizarea activitilor operaionale, fiind un ansamblu de
persoane, proceduri, software, baze de date i echipamente folosite pentru a oferi managerilor
informaii periodice i de rutin. Marketingul, producia, financiarul i alte domenii funcionale
sunt sprijinite de sistemele de informare a conducerii, prin exploatarea bazei de date integrate
la nivel de organizaie.
Un alt mod de a defini sistemele de informare a conducerii este cel n care acestea pun la
dispoziie informaii tuturor utilizatorilor care au nevoi similare, utilizatori care se regsesc la
nivelul componentelor funcionale ale unei firme. Informaiile oferite prezint firma sau una
din subunitile ei sub forma a ceea ce s-a ntmplat, ce se ntmpl i ce se va ntmpla4. Cu
alte cuvinte, sistemele de informare a conducerii pot asigura obinerea de avantaje competitive
oferind informaia potrivit, omului potrivit, n formatul potrivit, la momentul potrivit (the
right information to the right people in the right format and at the right time)5.
n figura 2.1 este redat locul pe care l ocup sistemul de informare a conducerii n cadrul
unei firme, din perspectiva surselor de date i a informaiilor pe care le poate oferi celorlalte
sisteme, n sensul c le sprijin i sunt folosite de toi cei care au nevoie pentru luarea
deciziilor i rezolvarea unor probleme cu caracter structurat.
4. McLeod Jr., R., Schell, G. Management Information Systems, 8th Edition, Prentice Hall, Upper Saddle River,
New Jersey, 2001, pp. 239-240.
5. Stair, R.M., Reynolds, G.W. op. cit., p. 415.
30
Extranet Internet Intranetul

firmei
Alte surse
externe de date Date
Date Date
Informaii
Informaii
Baze de date Baze de date
cu informaii cu informaii
sprijinire a procesului decizional.

externe interne
Date Date
Informaii
Sisteme de sprijinire
Rapoarte Management Interogri a top-managerilor
strategic
Date Sisteme de Date Sistemele de Rapoarte Informaii/

Tranzacii Date Baze de date
prelucrare informare a Management scenarii
economice cu tranzaciile
conducerii sunt caracterizate de urmtoarele trsturi:

a tranzaciilor tactic Sisteme de sprijinire a
conducerii Interogri
validate procesului decizional
Informaii Rapoarte
Informaii Management Informaii/
operational scenarii
Interogri
ANALIZA SISTEMELOR INFORMAIONALE
Financiar Resurse Cercetare- Informatic

Comercial
Baze de date Lista erorilor contabil Productie umane dezvoltare
operaionale
2.2.1 Caracteristicile sistemelor de informare a conducerii

Fig. 2.1 Relaia sistemului de informare a conducerii
cu celelalte sisteme informaionale ale firmei
(prelucrare dup Stair, R.M., Reynolds, G.W. Principles of Information Systems,
6th Edition, Thomson Course Technology, Boston, 2003, p. 416)
activitile desfurate, urmnd ca decidenii s identifice cauzele care au generat problema i

strict necesare pentru rezolvarea unor probleme, ci prezint informaii generale privind
Exist i un neajuns al sistemelor de informare a conducerii, pentru c nu se adreseaz
unor probleme specifice ale anumitor categorii de persoane. Deseori, nu ofer informaiile
s gseasc soluiile. Dar, pentru eliminarea acestui neajuns, i-au fcut apariia sistemele de
Din punct de vedere al datelor utilizate i al informaiilor oferite, sistemele de informare a

repetitivitate informaiile se obin n mod periodic, cunoscndu-se aproape cu exactitate

momentele n care ele sunt necesare;
predictibilitate fiind cunoscute perioadele de timp la care informaiile se vor obine,
coninutul rapoartelor de ieire este, de cele mai multe ori, acelai. Dar pot s apar i
informaii cu caracter surpriz, care s nu fi fost prevzute de ctre manageri;
temporalitate informaiile se refer att la trecut (pentru a controla modul n care s-au
utilizat resursele), la prezent (pentru a ti ce s-a realizat comparativ cu ceea ce se
prevzuse n planuri), ct i la viitor (pentru obinerea planurilor de aciuni). Informaiile
urmresc s scoat n relief, n primul rnd, abaterile de la normalitate;
sintetizare informaiile nu abund n detalii, ca n cazul sistemelor de prelucrare a
tranzaciilor, ci iau forma unor rapoarte ct mai concise;
sursa informaiile se obin pe baza datelor oferite de sistemele de prelucrare a
tranzaciilor, dar i pe baza celor oferite de mediul extern n care organizaia i
desfoar activitatea (concuren, legislaie .a.);
structurare pe de o parte, datele i informaiile au un caracter structurat i
semistructurat, pentru c nu exist posibilitatea predefinirii i anticiprii n totalitate a
datelor, n special a celor din mediul extern, iar pe de alt parte managerii pot solicita
rapoarte care nu au un coninut dinainte stabilit i cunoscut. Ca urmare, caracterul
deciziilor la nivelul tactic al conducerii este parial strucurat deoarece acestea presupun
intervenii i judeci subiective, n cuplaj cu date certe i modele formalizabile;
exactitate informaiile preluate de la sistemele de prelucrare a tranzaciilor, prin
structura lor, au un grad foarte mare de exactitate, dar nu acelai lucru se poate spune
despre informaiile provenite din exterior, ceea ce nseamn c sistemele de informare a
conducerii se bazeaz i pe anumite aproximri i estimri.
2.2.2 Obiectivele sistemelor de informare a conducerii

Planificarea pe termen scurt, organizarea i controlul sunt principalele activiti pe care
sistemele de informare a conducerii trebuie s le sprijine. n acest scop, obiectivele de baz pe
care trebuie s le aib n vedere sunt:
1. Sprijinirea analizelor comparative
Aceste sisteme sunt proiectate pentru a evalua, pe de o parte, activitile desfurate, iar
pe de alt parte pentru a oferi informaii necesare efecturii controlului i planificrii. Pentru
acest lucru sunt colectate date n vederea determinrii nivelului de performan a activitii
(standard, previzionat, bugetat). n acelai timp, sunt efectuate analize comparative legate de
poziia competitorilor sau cu standardele domeniului n care funcioneaz firma.
2. Elaborarea planurilor
Spre deosebire de sistemele de prelucrare a tranzaciilor, a cror orientare este cu
precdere spre datele istorice, cele de informare a conducerii au posibilitatea de a sprijini
activitile viitoare. Prin aceasta se urmrete, n principal, realizarea planurilor i bugetelor
pentru perioade scurte de timp, cum ar fi prognozarea vnzrilor, planificarea fluxurilor de
trezorerie, planificarea produciei i a stocurilor, elaborarea bugetelor de venituri i cheltuieli
pe componente funcionale i proiecte etc.
3. Identificarea i rezolvarea eventualelor probleme
Prin compararea i analiza datelor pot fi detectate, n timp util, problemele aprute n
desfurarea activitilor firmei, astfel nct s fie ct mai puin afectate rezultatele prevzute.
De fapt, se identific abaterile de la rezultatele planificate, cauzele care le-au determinat,
precum i posibilele decizii sau aciuni de urmat. De cele mai multe ori, se apeleaz la
rapoartele de excepie, care scot n eviden nencadrarea n anumite reguli sau standarde,
oferind posibilitatea managerilor s acioneze pentru corectarea situaiilor i aducerea la starea

de normalitate a activitilor desfurate.
4. Sprijinirea lurii deciziilor cu caracter structurat
Fiind plasate la nivelul managerilor de pe nivelul tactic, sistemele de informare a
conducerii trebuie s aib capacitatea de a oferi informaiile necesare procesului decizional,
caracterizat prin repetitivitate i rutin. n acest sens, se apeleaz la o serie de modele
matematice, statistice i financiare, uor de standardizat i informatizat.
2.2.3 Funciile sistemelor de informare a conducerii

n principiu, funciile realizate de sistemele de informare a conducerii sunt similare celor
de prelucrare a tranzaciilor, numai c scopul i rezultatele sunt diferite. Astfel, ntlnim
funcia de prelucrare a datelor, de raportare i control.
1. Prelucrarea datelor
Prelucrrile sunt relativ simple, presupunnd interogri ale bazelor de date ale sistemelor
de prelucrare a tranzaciilor, a celor cu date externe, calcule matematice sau aplicarea de
formule statistice, precum i crearea sau actualizarea nregistrrilor din bazele de date proprii.
Datele supuse prelucrrilor n sistemele de informare a conducerii provin att din mediul
intern, ct i din cel extern. Cea mai important surs o constituie sistemele de prelucrare a
tranzaciilor. Sursele externe sunt preluate de la clieni, furnizori, concureni, acionari, care nu
se regsesc n sistemele de prelucrare a tranzaciilor, precum i alte surse, cum ar fi Internetul,
revistele de specialitate, documente ale instituiilor guvernamentale etc. n plus, prin
dezvoltarea Extranet-urilor, schimbul de informaii direct cu partenerii de afaceri a devenit
mult mai facil, prin conectarea direct la bazele lor de date.
2. Raportarea
n privina funciei de raportare, se poate spune c reprezint, dup cum arat i numele
sub care mai sunt ntlnite (sisteme de raportare), nucleul operaiunilor realizate de ctre
aceast categorie de sisteme. Principalele ieiri ale sistemelor de informare a conducerii sunt
listele de control, situaiile operative, rapoartele periodice, de excepie, neplanificate, analizele
speciale, prelucrrile interactive (tabelul 2.2).
Prin listele de control managerii urmresc identificarea eventualelor erori strecurate n
prelucrarea datelor privind activitile curente, dar mai ales depistarea eventualelor nereguli
aprute n operaiunile desfurate la nivelul firmei.
Pentru analiza performanei unei firme, sistemele de informare a conducerii pot pune la
dispoziie o serie de situaii operative sau rapoarte cu indicatori economico-financiari, prin
care se sintetizeaz activitile dintr-o anumit perioad de timp. Aceste rapoarte pot s
cuprind nivelul stocurilor, indicatori privind activitatea de producie, volumul vnzrilor,
fiind folosite de manageri pentru a lua ct mai repede msuri corective asupra principalelor
aspecte din activitatea firmei, dac se impune o astfel de situaie.
ns, cele mai multe rapoarte ale sistemelor de informare a conducerii sunt cele
planificate, obinute pe baza datelor i informaiilor existente la nivelul sistemelor de
prelucrare a tranzaciilor. n trecut, aceste rapoarte aveau caracter sptmnal, lunar sau anual.
Din momentul n care tehnologiile informaionale i de comunicaii au evoluat, managerii au
realizat c ar fi mult mai eficient s aib la dispoziie rapoarte zilnice sau n timp real pentru
creterea eficienei activitilor de care rspund. De exemplu, un raport general privind
costurile totale cu salariile poate ajuta un manager al departamentului contabil s controleze
costurile viitoare cu aceast categorie bugetar. n plus, valoarea salariilor totale ar putea s
prezinte interes i pentru directorul de producie, n vederea monitorizrii costurilor cu fora de
munc i a locurilor de munc. Alte rapoarte de acest gen pot fi folosite de directorii diferitelor
departamente pentru a controla limitele creditului comercial acordat clienilor, plata

furnizorilor, performanele nregistrate de agenii de vnzri, nivelul stocurilor .a.m.d.
Tabel nr. 2.2 Tipuri de rapoarte ale sistemelor de informare a conducerii
Orientat Funcia
Tip raport Sursa spre luarea Descriere managementului pe
deciziilor care o servete
Control introducere SPT Nu Pentru detectarea erorilor aprute n Execuie
date (Liste de procesele de culegere a datelor i n
control) timpul derulrii tranzaciilor.
Control funcional SPT Nu Pentru urmrirea activitilor Execuie,
(Situaii operative) principale necesare bunei funcionri Control
a unui organism. Un rezultat indirect
al deciziilor de planificare i control.
Planificate cu SIC Da Pentru sprijinirea eforturilor Execuie,
regularitate manageriale de luare a deciziilor. Se Control
obin automat, la intervale predefinite
i ntr-un format fix.
Excepii SIC Da Pentru semnalarea condiiilor de Control
excepie, depiri ale unor limite
predefinite. Sunt generate automat i
au un format fix.
Neplanificate SIC Da Pentru sprijinirea eforturilor Control,
manageriale de luare a deciziilor. Se Planificare
obin la cerere, pe baza datelor
existente n fiierele unitii. Nu se
genereaz automat, dar sunt
predefinite ca structur.
Analize speciale SSPD Da Pentru sprijinirea eforturilor Planificare
manageriale de luare a deciziilor ntr-
un caz aparte. Se obin la cerere, pe
baza datelor proprii din fiiere.
Prelucrri SSPD Da Sprijin procesul decizional. Un caz Planificare
interactive aparte al analizelor speciale.
Utilizatorii dialogheaz direct cu
sistemul de la un terminal.
Legend:
SPT sisteme de prelucrare a tranzaciilor
SIC sisteme de informare a conducerii
SSPD sisteme de sprijinire a procesului decizional
Rapoartele de excepie descriu situaii neobinuite sau critice pentru un anumit domeniu
din firm, fiind obinute (dup cum arat i numele) numai dac este ndeplinit o condiie. De
exemplu, n cazul stocurilor, scderea sub o anumit limit determin generarea unui astfel de
raport pe baza cruia se poate lua o decizie de reaprovizionare, chiar dac nu era prevzut n
planul de aprovizionare, pentru c altfel e posibil s fie afectat producia i, implicit, onorarea
comenzilor ctre clieni.
Parametrii sau condiiile de declanare (trigger-e) a unui raport generat de excepii trebuie
s fie stabilii cu mare atenie. Dac acetia sunt fixai la un nivel sczut, exist riscul de a se
obine prea multe rapoarte, care s nu ajute cu nimic n procesul de luare a msurilor de
eficientizare a activitilor; invers, pot s apar situaii cnd probleme ce solicit aciuni rapide
sunt trecute cu vederea pentru c nu au fost reflectate prin intermediul acestui tip de rapoarte.
De exemplu, dac un manager dorete un raport care s cuprind toate proiectele care au
depit un buget de 1000 RON, e posibil s se constate c toate proiectele firmei depesc
aceast limit; de aici rezult c a stabilit necorespunztor condiiile de declanare a raportului.
O alt categorie de rapoarte o constituie rapoartele la cerere (neplanificate sau analizele
speciale) prin care se pot oferi managerilor diverse informaii n funcie de necesitile lor de
moment. De exemplu, nainte de a accepta comanda unui client, un agent de vnzri ar trebui
s obin un raport privind cantitatea de produse existent n stoc pentru produsele solicitate,
un raport privind limita de creditare acordat clientului i n ce sum se mai poate ncadra cu
noua comand, astfel nct s fie n msur s accepte sau nu comanda respectiv.
Prin folosirea tehnologiilor avansate de extragere i interpretare a datelor (OLAP On-
line Analitycal Processing, data warehouse, data mining .a.), sistemele de informare a
conducerii au la dispoziie instrumente ce permit prelucrri interactive ale utilizatorilor, multe
dintre rapoarte putnd fi generate n varianta rapoartelor de tip drill-down6, adic a rapoartelor
cu grade diferite de detaliere, n funcie de necesitile utilizatorilor. Astfel, managerii pot s
analizeze, iniial, date sintetice, dup care pot obine informaii din ce n ce mai analitice, prin
navigare n cadrul unei ierarhii a descompunerii raportului. Un exemplu de raport de acest tip
este prezentat n fig. 2.2.
Profit pe trimestre (mii RON)

Valoarea Valoare
curenta planificat Variaie (%)
Trim. I 2004 12.6 11.8 6.8
Trim. II 2004 10.8 10.7 0.9
Trim. III 2004 14.3 14.5 1.4
Trim. IV 2004 12.8 13.3 3.8
a) Primul nivel al raportului drill down
Vnzri i cheltuieli (mii RON)

Valoarea Valoare
Trim. I 2004 Variaie (%)
curenta planificat
Vnzri 110.9 108.3 2.4
Cheltuieli 98.3 96.5 1.9
Profit 12.6 11.8 6.8
b) Al doilea nivel de detaliere
Vnzri pe divizii (mii RON)
Trim. I 2003 Valoarea Valoare Variaie (%)

curenta planificat
Divizia produse cosmetice 34.5 33.9 1.8
Divizia produse sanitare 30.0 28.0 7.1
Divizia spunuri 22.8 23.0 0.9
Divizia snacks-uri 12.1 12.5 3.2
Divizia electronice 11.5 10.9 5.5
Total 110.9 108.3 2.4
c) Al treilea nivel de detaliere
Fig. 2.2 Exemplu de raport de tip drill-down
3. Controlul
Ca i n cazul sistemelor operaionale, prin control se urmrete asigurarea corectitudinii
i calitii informaiilor generate de sistem, prin detectarea i eliminarea erorilor aprute n
timpul culegerii i prelucrrii datelor.
2.2.4 Componentele sistemelor de informare a conducerii

De cele mai multe ori, sistemele de informare a conducerii sunt structurate plecnd de la
principalele domenii funcionale ale unei firme. Componentele specifice pot fi integrate n
cadrul unui singur sistem sau pot funciona n mod independent. Sistemele de informare a
conducerii cuprind n structura lor:
planificarea vnzrilor, prin care se urmrete identificarea tendinelor pieei, a
profilului clienilor, analiza profitabilitii clienilor i produselor, identificarea
posibilitilor de lansare pe pia a unui produs nou, ctigarea unui segment de pia
nou;
6. Stair, R.M, Reynolds, G.W. op. cit., p. 418.

planificarea produciei, prin care se asigur alocarea eficient a resurselor necesare

obinerii produselor, avndu-se n vedere aici planificarea calendaristic a produciei,
antecalculaia produciei, planificarea resurselor umane pe faze de producie sau
schimburi;
planificarea aprovizionrilor are n vedere stabilirea ritmicitii de alocare a resurselor
financiare pentru achiziia bunurilor, stabilirea criteriilor de selecie a furnizorilor
firmei, analiza eficienei relaiilor cu furnizorii etc.;
managementul resurselor umane presupune stabilirea necesarului de for de munc, a
competenelor i calificrilor necesare, planificarea programului de pregtire continu
a personalului, evaluarea performanelor nregistrate de fiecare salariat etc.;
planificarea activitilor de marketing i analiza impactului campaniilor de
promovare/publicitate asupra vnzrilor;
gestiunea financiar presupune previzionarea fluxului de trezorerie, analiza
cheltuielilor de capital, gestiunea i planificarea investiiilor.
Rezumat
Pentru redarea operaiunilor curente desfurate la nivelul unei firme i pentru asigurarea unui
control riguros al resurselor pe care le solicit, sunt implementate sistemele de prelucrare a tranzaciilor,
fr de care nici o firm nu poate s-i desfoare n condiii normale activitile. Aceste sisteme se afl
pe nivelul operaional al conducerii unei firme, dar reprezint suportul esenial pentru generarea
informaiilor necesare celorlalte niveluri decizionale.
Firmele au realizat c datele stocate la nivelul sistemelor de prelucrare a tranzaciilor pot fi utilizate
i pentru a ajuta managerii n luarea celor mai bune decizii n sfera lor de aciune, nu numai la nivel
operaional, ci i la nivelul managementului tactic i strategic. Satisfacerea cerinelor informaionale a
fost i este un factor determinant pentru dezvoltarea sistemelor de informare a conducerii tactice.
La acest nivel, sistemele informaionale trebuie s asigure informaiile necesare stabilirii planurilor
i bugetelor de desfurare a activitilor, care, n majoritatea cazurilor, sunt decizii ce privesc
gestionarea resurselor ntreprinderii, supravegherea i controlul.
Sistemele de informare a conducerii permit obinerea mai multor categorii de rapoarte, i anume:
liste de control, situaii operative, rapoarte periodice, de excepie, neplanificate, analize speciale,
prelucrri interactive, cu scopul sprijinirii deciziilor ce se iau la nivelul componentelor funcionale ale
firmei, avnd un caracter parial structurat.
Prin prezentarea principalelor categorii de sisteme informaionale, s-a ncercat evidenierea
caracteristicilor eseniale ce trebuie avute n vedere la dezvoltarea lor. Dei principalele etape i activiti
pot fi identice, aspectele de care trebuie s se in cont la dezvoltarea lor difer, n special, din
perspectiva utilizatorilor i nevoilor lor informaionale, a tehnologiilor i arhitecturilor pe care le
presupune implementarea fiecrei categorii de sisteme.
1. Prin ce se difereniaz sistemele de prelucrare a tranzaciilor de compartimentele/ departamentele
din structura organizatoric a unei firme?
2. Care sunt aspectele ce scot n eviden importana sistemelor de prelucrare a tranzaciilor?
3. Prin ce se difereniaz sistemele de prelucrare a tranzaciilor de sistemele de informare a
conducerii?
4. Care este rolul i prin ce se caracterizeaz sistemele de informare a conducerii?
5. Prezentai tipurile de rapoarte ce pot fi obinute cu ajutorul sistemelor de informare a conducerii.
6. Care sunt trsturile sistemelor de sprijinire a procesului decizional?
7. Care sunt principalele funcii pe care le poate ndeplini un sistem de sprijinire a procesului
decizional?
Probleme de echip
1. Plecnd de la informaiile pe care le gsii n diferite reviste economice sau de informatic
economic, identificai pachete software care pot fi implementate pentru asigurarea funcionalitii
sistemelor de sprijinire a procesului decizional, sistemelor de informare a top-managerilor i
birotic.
2. Presupunnd c suntei o echip ce a nfiinat o firm nou, care vinde aparatur electrocasnic,
specificai care sunt aplicaiile sistemelor de prelucrare a tranzaciilor de care ai avea nevoie i
motivai.
3. Echipa trebuie s culeag informaii despre o aplicaie (un pachet software) specific sistemelor de
prelucrare a tranzaciilor. Realizai un raport de dou pagini prin care s descriei acea aplicaie.
4. Echipa a fost desemnat s propun un sistem de informare a conducerii pentru o firm mic, ce
produce 10 tipuri de modele de nclminte pentru copii. Aceste produse sunt vndute
distribuitorilor i magazinelor de nclminte specializate din Regiunea Nord-Est. Una din
principalele probleme cu care se confrunt firma o reprezint faptul c nu are un control eficient
asupra stocurilor de produse. ntotdeauna se confrunt cu faptul c o parte din modele rmn n stoc
o perioad prea mare de timp, n timp ce stocul pentru alte modele este epuizat foarte repede.
Patronul firmei a sugerat c ar dori s rezolve aceast problem. Realizai o scurt prezentare a
principalelor subsisteme i a rapoartelor corespunztoare unui sistem de informare a conducerii care
s-ar preta acestei firme. Construii o schem prin care s evideniai modul n care subsistemele pot
fi integrate. Enumerai cteva din beneficiile pe care le-ar putea obine firma printr-un control mai
riguros al stocurilor de nclminte.
5. Imaginai-v c suntei o echip care trebuie s decid asupra dezvoltrii unui sistem de informare a
top-managerilor pentru firma de la problema 4. Care sunt principalele decizii pe care conducerea
strategic ar trebui s le ia? Realizai o list a principalelor caracteristici pe care trebuie s le ofere
un astfel de sistem. Identificai cel puin trei surse externe de date care vor fi utile decidenilor
strategici.
6. Mergei la o firm i ncercai s aflai urmtoarele aspecte:
a. tipurile de sisteme informaionale existente i ncadrarea lor dup criteriul managerial;
b. alegei dou dintre sisteme i prezentai principalele informaii care sunt obinute cu ajutorul lor;
c. enumerai deciziile care pot fi luate pe baza informaiilor oferite de cele dou sisteme.
CAPITOLUL III
Introducere n dezvoltarea
sistemelor informaionale
Obiective:
Caracterizarea celor mai cunoscute modele ale ciclurilor de via ale dezvoltrii
sistemelor informaionale
Crearea unei imagini generale asupra etapelor proiectului de dezvoltare a unui sistem
Datorit existenei unui context din ce n ce mai competitiv i a unei lumi aflat n
continu schimbare, firmele trebuie s fac fa provocrilor prin cutarea de noi soluii, bazate
pe obinerea rapid de informaii. Pentru a rspunde acestei nevoi, sistemul informaional
trebuie supus unor modificri continue, plecnd de la mici ajustri sau adaptri pn la
schimbri substaniale sau chiar nlocuirea lui. Schimbrile sunt att de constante i frecvente,
nct majoritatea firmelor sunt ntr-un proces continuu de mbuntire sau transformare a
sistemelor. Ele sunt nevoite s efectueze diferite modificri, cel puin datorit unuia dintre
urmtoarele motive:
ca parte a unui program mai amplu de modernizare a ntregului sistem. Multe firme
ntreprind o serie de proiecte pentru modernizarea tehnologiei de prelucrare a datelor
hardware, sisteme de operare, programe utilitare, aplicaii informatice. Un astfel de
proiect este iniiat, de obicei, ca parte a inteniei de a nlocui aplicaiile vechi,
centralizate, cu altele noi, bazate pe tehnologia client/server, a sistemelor distribuite
sau a celor bazate pe web;
modificarea unor aspecte funcionale de baz. Firmele i reproiecteaz procesele de
baz fie ca rezultat al efortului continuu de mbuntire permanent a activitilor, fie
mult mai radical, ca efect al reproiectrii proceselor economice;
schimbarea obiectivelor strategice ale organizaiei. De multe ori, firmele sunt nevoite
s-i regndeasc nu numai modul n care i desfoar activitile, dar i ceea ce ar
trebui s fac pentru a rezista competiiei. n unele cazuri, firmele de producie se
transform n firme prestatoare de servicii, productorii primari devin uniti de
asamblare a componentelor realizate de alii, se modific liniile lor de afaceri i se
reexamineaz nevoile clienilor. Marile firme se lipsesc de propriile divizii i linii de
producie, pstrnd ceea ce consider a fi nucleul de baz al afacerii lor;
nevoia creterii performanelor aplicaiilor informatice, funcionalitii diferitelor
caracteristici de exploatare sau mbuntirea interfeelor utilizator. Pe msur ce
condiiile economice se schimb, cerinele utilizatorilor sunt din ce n ce mai mari, n
ceea ce privete extinderea funcionalitii sistemelor existente. Creterea numrului
utilizatorilor de calculatoare i dezvoltarea aplicaiilor cu interfee grafice schimb
ateptrile acestora n ceea ce privete tolerana la erori;
necesitatea accesrii directe i ntr-un timp ct mai scurt a datelor firmei.
Majoritatea utilizatorilor de staii de lucru sau PC-uri au din ce n ce mai multe date
stocate n fiiere proprii. Datele din aceste fiiere provin din informaii prelucrate de
utilizator, sunt transferate de pe calculatorul lui pe alt calculator, cu ajutorul
diferiilor supori de stocare, al diferitelor mecanisme de transfer al fiierelor. Aceste
transferuri sunt mari consumatoare de timp i destul de greoaie. De aceea, utilizatorii
doresc un acces la date mult mai performant;
modernizarea sistemului pentru valorificarea avantajelor oferite de tehnologiile de

ultim or. Productorii de hardware cresc performanele produselor oferite, din
punct de vedere al vitezei i al capacitii de stocare i prelucrare. Utilizatorii sunt n
continu cutare de noi instrumente care s conduc la creterea eficienei activitilor
pe care le desfoar, solicitnd tot mai multe aplicaii noi, adaptate noilor
echipamente.
n concluzie, motivele pentru iniierea unui proiect de dezvoltare a unui nou sistem
informaional sunt legate de:
rezolvarea unei probleme;
obinerea de avantaje de pe urma apariiei unei noi oportuniti;
pentru a rspunde unor obiective definite prin planul strategic al organizaiei sau prin
planul sistemului informaional.
n acest capitol, vom aborda cteva aspecte eseniale privind dezvoltarea sistemelor, ce
vor fi detaliate n urmtoarele capitole. n primul rnd, se vor prezenta diferitele modele ale
ciclurilor de via ale dezvoltrii sistemelor. Apoi, vor fi descrise principalele metodologii,
modele, instrumente i tehnici necesare parcurgerii ciclului de dezvoltare, pentru ca n partea
final s se descrie, ntr-o manier general, etapele ciclului de dezvoltare ce vor fi folosite pe
parcursul acestui volum i al celor care urmeaz.
3.1 Ciclul de via al dezvoltrii sistemelor informaionale

n acest paragraf dorim s surprindem doar o sintagm esenial n activitatea de analiz i
proiectare a sistemelor, ciclul de via al dezvoltrii sistemelor (CVDS) sau ciclul dezvoltrii
sistemelor (CDS).
nc de la nceput, facem meniunea c, indiferent de etapa istoric sau metodologic,
sistemele sunt abordate prin prisma ciclului lor de via. Ele apar, se dezvolt, descresc i pier
sau, printr-un nou ciclu, se perfecioneaz, dnd natere unei alte versiuni sau chiar unui nou
sistem. Nu prezena ciclului de via al dezvoltrii sistemelor trebuie discutat, ci formele de
regsire a acestuia n timp, n funcie de cadrul n care se realizeaz sistemul. Mutaiile din
domeniul tehnologiilor informaionale i al metodelor de abordare a sistemelor s-au reflectat i
n ciclul de via al dezvoltrii sistemelor, fie prin schimbarea etapelor acestuia, fie prin
modificarea opticii de parcurgere a lor.
Ciclul de via al dezvoltrii sistemelor este o metodologie comun de dezvoltare a
sistemelor din multe organizaii, caracterizat prin cteva faze care marcheaz evoluia
eforturilor de analiz i proiectare a sistemelor1. Fazele sau etapele ciclului de via sunt greu
de prezentat, nu numai ca nume, ci i ca numr.
Cu convingerea c sunt puine persoanele care contest nefondat iminenta prezen a
ciclului de via al dezvoltrii sistemelor n activitile specifice dezvoltrii/realizrii
sistemelor, vom ncerca s punctm cteva dintre modelele concrete n care se poate regsi
acesta.
Prin parcurgerea materialelor de specialitate, se poate constata c numrul fazelor variaz
de la trei (de exemplu: analiz, proiectare, implementare) la peste douzeci. Firesc, n cel de-al
doilea caz, nici simpla enumerare a lor nu este edificatoare. La un moment dat, se poate vorbi
chiar de o concuren n domeniu. Fiecare autor ncearc s fie original, fie prin schimbarea
numrului de etape, fie prin modificarea numelor acestora. Totui, s-ar putea formula o
concluzie.
1. Hoffer, J.A., George, J.F., Valacich, J.S. Modern Systems Analysis and Design, The Benjamin/Cummings
Publishing Company, Inc., Menlo Park, 1996, p. 22.
INTRODUCERE N DEZVOLTAREA SISTEMELOR INFORMAIONALE 39
n fazele incipiente de abordare a sistemelor, numrul etapelor se situa la aproximativ

ase. Ele erau descompuse pe activiti, subactiviti, operaiune fireasc, apreciem noi,
datorit influenei gndirii bazate pe descompunerea funcional, care era la mod.
Prin trecerea la orientarea-procese i orientarea-date, considerm c s-au nregistrat dou
fenomene:
a) diversificarea etapelor;
b) revizuirea modelului sub care se manifest ciclicitatea.
Aadar, se nregistreaz apariia, uneori, a peste douzeci de etape.
Odat cu tehnicile de dezvoltare rapid a aplicaiilor, prin sistemul prototipizrii sau RAD
(Rapid Application Development), cu varianta european PD (Participatory Design), numrul
fazelor/etapelor s-a redus din nou, operndu-se chiar schimbri ale numelor acestora2. James
Martin enumer urmtoarele faze ale ciclului de via RAD: planificarea cerinelor, proiectul
utilizatorului, construcia, finisarea/fasonarea. Dac facem trimitere la cele ase etape regsite
n majoritatea opiniilor (analiza sistemelor, achiziia sistemelor, proiectarea conceptual,
proiectarea fizic, implementarea i conversia, exploatarea i ntreinerea), se observ cu
uurin diferenele dintre ele.
n legtur cu numrul i numele etapelor ciclului de via al dezvoltrii sistemelor, se
observ, la sfritul anilor 1980 i nceputul anilor 1990, o tendin de preluare a unor etape
specifice managementului proiectelor. De exemplu, identificarea i selecia proiectului,
planificarea i iniierea proiectului (numite de unii specialiti etapele microanalizei) preced
analiza, proiectarea logic, proiectarea fizic, implementarea, ntreinerea. Apar i alte puncte
de vedere. Ele pot fi asociate curentului creat de Yourdon prin lucrarea, din 1989, privind
analiza modern structurat.
Indiferent de numrul i numele etapelor ciclului de via al dezvoltrii sistemelor, o
problem este mult mai important, i anume ordinea i felul n care se parcurg etapele
respective, ceea ce n literatura de specialitate se trateaz sub numele de modele ale ciclului de
via al dezvoltrii sistemelor.
Datorit simplei enumerri a etapelor, se poate trage concluzia, la prima vedere, c
ordinea lor este secvenial, ceea ce nu este confirmat de realitate. Revenirile la etapele
anterioare sunt foarte dese, sfidnd secvenialitatea. E drept c, uneori, etapele se pot derula
secvenial, alteori iterativ, cu posibilitatea revenirii la etapele anterioare, conform variantei
sugerate de modelul cascad, sau unele etape se pot derula n paralel. Ali specialiti vd
ciclul de via ca pe o spiral, alii ca pe un proces circular.
Ca urmare a marii diversiti a opiniilor, considerm binevenit o descriere sumar a mai
multor modele.
3.1.1 Modelul cascad

Modelul cascad este unul de referin, asigurnd trecerea de la o etap la alta ce-i
drept, mai mult teoretic n ordine secvenial. Realitatea a demonstrat c parcurgerea
etapelor/fazelor ntr-o astfel de ordine nu este o regul, ntruct, de cele mai multe ori, se
nregistreaz reveniri la etapele anterioare sau parcurgerea n paralel a unora dintre ele.
Modelul este lansat la nceputul anilor 1970 de ctre W.W. Royce3 i const ntr-o
descompunere a ciclului de via n faze secveniale. La rndul lor, fazele sunt structurate pe
activiti i subactiviti. Trecerea de la o etap la alta se realizeaz dup ce precedenta a fost
parcurs n ntregime. Modelul se aplic la nivel de sistem; or, tocmai aici este punctul slab,
ntruct sistemele complexe, cu un numr mare de aplicaii ce interacioneaz ntre ele, sunt
2. Martin, J. Rapid Application Development, Macmillan Publishing Company, New York, 1991.
3. 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, pp. 328-338.
greu de controlat. Dei nu este descurajat abordarea iterativ a unor faze sau componente ale
lor, restriciile de timp impuse de programarea calendaristic a etapelor limiteaz efectele
benefice ale acesteia, ca i posibilitile de revenire la etape anterioare. Modelul este redat n
fig. 3.1.
Modelului i se recunosc unele avantaje, cum ar fi:
un control total asupra fazelor, n sensul c ele sunt ordonate i, firesc, previzibile, prin
evidenierea clar a ariei de ntindere a fiecrei etape sau subcomponent a ei;
este uor de nsuit de ctre membrii echipelor de analiz i proiectare, inclusiv de cei
noi, cu o experien mai puin vast;
fiecare etap este nsoit de o documentaie perfect structurat (controlat).
Definirea
cerinelor
Analiza
Proiectarea
Implementarea
Testarea
Utilizarea i
ntreinerea
Fig. 3.1 Modelul cascad

Ca dezavantaje, amintim:
sistemul se pred doar dup parcurgerea tuturor etapelor, ceea ce nseamn o lung
perioad de timp, suficient ca utilizatorii s-i schimbe preteniile;
nu corespunde inteniilor de abordare dinamic a sistemelor;
nu este deschis schimbrilor ce pot interveni pe parcurs.
ntr-un anumit fel, modelul este folosit de ctre Booch, n 1991, n proiectarea sa
orientat-obiect (OOD Object-Oriented Design), n fazele de proiectare i implementare,
precum i de ctre Ivar Jacobson, n modelul OOSE (Object-Oriented Software Engineering),
n 1992, acoperind toate etapele. Am putea spune c i aliatul ulterior al celor doi, Rumbaugh,
folosete ntr-o form oarecare valenele modelului cascad, doar c ele se regsesc ntr-un
mod aparte n modelul V, utilizat parial.
Ideea de baz a modelului este regsit i n altele, cum ar fi modelul X, fntn artezian
sau cel incremental. Firesc, i numai cronologic, dac am face analiza acestora, ele ar trebui s
fie mai performante dect strmoul lor.
3.1.2 Modelul V
Modelul V este, aa cum am menionat anterior, o variant a modelului cascad, prin care
se introduc conceptele de sistem i componente (subsisteme), aplicndu-se teste explicite la un
sistem ierarhic pentru creterea controlului asupra modului n care se desfoar etapele.
Tocmai aceast nlesnire constituie o latur a literei V. Prima este latura din stnga, parcurs
descendent, i conine etapele propriu-zise, iar cea de-a doua latur, din dreapta, se parcurge
ascendent, pe ea realizndu-se verificrile i validrile elementelor create anterior.
Modelul, redat n figura 3.2, puncteaz cu mai mult claritate separrile dintre ceea ce
implic participarea utilizatorului, modelul arhitectural i cel al implementrii. Utilizatorul este
implicat doar n fazele din partea superioar a V-ului. Arhitectura sistemului este surprins n
partea de mijloc a literei, iar partea inferioar a ei se refer la faza de implementare, care ar
putea consta fie din asamblarea componentelor software, fie din codificarea unor componente.
Definirea
Validare
cerinelor
Proiectare Testare
sistem sistem
Proiectare Testare
subsistem subsistem
(component) (component)
Codificare/
asamblare
componente
Fig. 3.2 Modelul V
Modelul se preteaz i n mediul orientat-obiect, deoarece ncurajeaz prototipizarea,

reutilizarea unor structuri superioare. El ofer un control puternic asupra sistemului n curs de
realizare, prin structurile ierarhice i modulare pe care le promoveaz, ceea ce l face utilizabil
i n cazul sistemelor complexe. Modelul devine i mai puternic dac promoveaz iteraia,
adic reluarea unor faze, activiti sau subactiviti. De fapt, acesta este stilul adoptat de cei
trei autori ai UML Unified Modeling Language (Booch, Jacobson i Rumbaugh), modelul
iterativ-incremental, anunat de anumite performane ale modelului V.
n cadrul acestui model se face, de asemenea, distincie evident ntre verificare i
validare. Prima se refer la testarea sistemului, n diverse stadii ale lui, dac s-a construit corect
din punct de vedere logic, n timp ce validarea va scoate n eviden faptul c sistemul, n
forma lui final, rspunde sau nu cerinelor iniiale4. Tocmai din aceast cauz, i se reproeaz
c las validarea prea trziu, dup ce sistemul s-a construit, ceea ce l face ineficient.
3.1.3 Modelul incremental

Modelul incremental este o alt form a celui cascad. De fapt, n modul de descriere a
etapelor incipiente nici nu exist vreo diferen fa de modelul cascad, ntruct att definirea
cerinelor, ct i analiza se efectueaz la nivelul ntregului sistem. Dup ce se parcurg aceste 2
etape, se efectueaz descompunerea proiectului n subproiecte, ele fiind urmrite pe activiti
care vor concura la obinerea componentelor necesare sistemului final. Aceasta este, de fapt,
filosofia de baz a modelului. Fa de modelul V, cel incremental ofer posibilitatea atingerii
scopului final n dou variante: sistem global livrat la sfrit sau componente livrate distinct,
conform figurii 3.3.
Din descrierea de pn acum rezult cteva dintre avantajele modelului:
se ncadreaz n principiul arhicunoscut divide et impera, prin posibilitatea abordrii
unor pri ale ntregului;
sistemul poate fi livrat i pe componente realizate la perioade scurte de timp;
4. Vezi i Sommerville, I. Software Engineering, 1st Edition, Addison-Wesley, Reading, 1989.

proiectul sau sistemul final poate fi realizat de mai multe echipe sau persoane datorit
modularizrii lui.
Dintre dezavantaje pot fi enumerate:
imposibilitatea aplicrii lui n toate cazurile, uneori lipsind elementele necesare
descompunerii ntregului;
componentele pot fi realizate numai dup ce ntregului sistem i se definete arhitectura,
totul derulndu-se dup principiile metodei top-down, ceea ce nseamn nc o
condiie: cunoaterea i formularea cerinelor din faza incipient de abordare a
sistemului;
fiind posibil de realizat pe pri, eforturile de integrare a acestora n ntreg sunt destul
de mari, vorbindu-se chiar despre o aa-zis testare multipl de sisteme, cu trimitere la
faptul c, de fiecare dat cnd se adaug o nou component, sistemul poate fi
considerat unul nou.
Proiectare
Definirea component-1 Instalare
cerinelor component-1
Analiz Implementare ntreinere

component-1 component-1
Arhitectura
sistemului
Proiectare Instalare
component-n component-n
Implementare ntreinere
component-n component-n
Fig. 3.3 Modelul incremental
*
* *
Dup descrierea a trei dintre principalele modele ale ciclului de via al dezvoltrii
sistemelor, se pot trage unele concluzii, dup cum urmeaz:
modelele sunt diferite, n funcie de tehnologiile folosite n procesul de realizare a
sistemelor, saltul considerabil nregistrndu-se n mediile orientate-obiect;
modelele depind i de mrimea proiectelor, dar i de domeniile crora le aparin
sistemele;
diferenele dintre modele constau, ndeosebi, n modul de parcurgere a etapelor, ca
ordine, dar i n ceea ce privete modalitatea de abordare a sistemului (n ntregime sau
pe pri componente);
n selectarea modelului, un rol important l are echipa ce efectueaz aceast operaiune,
referindu-ne la experiena ei de a lucra cu diverse modele;
cerinele funcionale i pun, de asemenea, amprenta pe tipul de model; sistemul poate
fi abordat n ntregime sau pe componente funcionale;
complexitatea sistemului se va reflecta, n mare msur, n tipul modelului selectat;
nivelul de implicare a utilizatorilor n realizarea sistemului va impune opiunea pentru
modelele cu performane diferite pe acest plan.
3.2 Definirea metodologiilor, modelelor,

tehnicilor i instrumentelor
Ciclul de via al dezvoltrii sistemelor ofer un cadru general pentru procesul de
dezvoltare, dar el presupune cunoaterea mult mai multor aspecte dect etapele din care este
alctuit, elemente care fac referire la metodologii, modele, instrumente i tehnici, de a cror
nelegere depinde modul de derulare a activitilor specifice ciclului de via.
Metodologia dezvoltrii unui sistem ofer principii care ghideaz echipa de dezvoltare n
realizarea activitilor ciclului de via, cuprinznd modele, instrumente i tehnici specifice. n
timp, s-au conturat mai multe metodologii, dintre care mai importante sunt metodologia
structurat i cea orientat-obiect, despre care vom discuta n paragrafele urmtoare. Plecnd
de la acestea, firmele fie adopt una dintre ele, fie le adapteaz la particularitile proprii,
dezvoltndu-i o metodologie proprie.
Unele metodologii dispun de o bogat documentaie privind modul de derulare a
activitilor, ce anume s se urmreasc i obin din fiecare etap, inclusiv cum ar trebui s fie
conceput documentaia sistemului, rapoartele privind evoluia proiectului. Alte metodologii
sunt, ns, mult mai informale, n sensul c pun la dispoziie doar descrieri generale asupra a
ceea ce ar trebui fcut, lsnd la latitudinea echipei de dezvoltare metodele, modelele sau
tehnicile pe care s le utilizeze, precum i coninutul documentaiei sistemului 5.
Pentru a comunica n timpul dezvoltrii sistemelor, echipa de proiectare apeleaz, de
multe ori, la modele. Modelele asigur reprezentarea unor elemente din lumea real, purtnd
denumirea i de abstractizare, pentru c presupune extragerea celor mai importante aspecte ce
caracterizeaz sistemul. Unele modele sunt destul de apropiate de produsul real, altele sunt
reprezentri grafice ale celor mai importante detalii sau sunt notaii abstracte matematice. n
domeniul sistemelor informaionale, spre deosebire de altele (industria constructoare de
maini, a construciilor de locuine etc.), modelele nc nu sunt standardizate sau att de
precise, pentru c un sistem informaional, uneori, este mai puin tangibil, prin el
reprezentndu-se logic, aa cum am vzut n capitolul 1, lucrurile i fluxurile fizice.
Modelele utilizate n dezvoltarea sistemelor includ reprezentri ale intrrilor, ieirilor,
proceselor, obiectelor, interaciunilor dintre obiecte, reelelor, echipamentelor. Cele mai multe
modele sunt grafice, apelndu-se la convenii i simboluri agreate de aproape toi dezvoltatorii
de sisteme, purtnd denumirea de diagrame sau scheme, despre care vom discuta n capitolele
de analiz i proiectare a sistemelor.
De exemplu, pentru modelarea comportamentului sistemului se pot folosi schemele pe
vertical a documentelor, diagramele fluxurilor de date, diagramele entitate-relaie, diagramele
de structur, diagrama cazurilor de utilizare, diagrama claselor de obiecte etc.
Un alt tip de model, la fel de important, este cel al planificrii proiectului, cu ajutorul
diagramelor Gantt sau PERT, prin care se reprezint activitile i subactivitile, cu datele de
nceput i sfrit ale proiectului, sau al diagramei de alocare a resurselor pe fiecare activitate n
parte. Tot pentru planificarea proiectului pot fi folosite i modele financiare necesare studierii
fezabilitii economice a proiectului.
Un prim avantaj al utilizrii modelelor const n simplificarea reprezentrii sistemului i
uurina nelegerii principalelor aspecte ale acestuia, prin apelarea doar la cteva simboluri, ce
nu presupun prea multe cunotine n domeniul informaticii. Acest lucru faciliteaz
participarea utilizatorilor i a tuturor celor afectai, direct sau indirect, de dezvoltarea
sistemului, alturi de echipa de specialiti, asigurndu-se un grad de comunicare mai mare ntre
toi participanii i, ca urmare, un potenial mai ridicat de atingere a cerinelor utilizatorilor. Nu
n ultimul rnd, modelele se constituie i ntr-un limbaj de comunicare ntre specialitii n
5. 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. 74-75.
dezvoltarea sistemelor, pentru c ei, de obicei, i au propriile reprezentri pe care nu toi

ceilali le neleg.
Modelele, ca i componentele sistemului, pot fi create cu ajutorul instrumentelor, regsite,
adesea, sub form de programe. Cele mai simple ofer faciliti de realizare grafic a
diagramelor, iar aplicaiile complexe includ depozite de metadate despre etapele parcurse
pentru dezvoltarea sistemelor, cum ar fi descrieri ale fluxurilor de date, proceselor de
prelucrare, scheme ale bazelor de date etc.
Programatorii au i ei la ndemn suficiente instrumente ce le sprijin activitatea, cele
mai noi asigurnd inclusiv generarea codului aplicaiilor, reverse-engineering-ul, depanarea
programelor etc.
Dar cele mai cuprinztoare instrumente disponibile pentru specialitii n dezvoltarea
sistemelor sunt cele de tip CASE (Computer Assisted/Aided Software/Systems Engineering),
care sprijin crearea celor mai importante modele ale unui sistem informaional, inclusiv
verificarea automat a completitudinii i corectitudinii lor, precum i generarea schmei bazei
de date i/sau a codului programelor pentru modelele dezvoltate.
Att instrumentele automatizate, ct i cele manuale se bazeaz pe o serie de tehnici, adic
o colecie de recomandri ce vin n sprijinul dezvoltatorilor pentru desfurarea activitilor
specifice. O tehnic include instruciunile care trebuie s fie urmate pas-cu-pas n crearea unui
model sau sfaturi generale privind, de exemplu, modul de culegere a cerinelor de la utilizatorii
sistemului. n aceast categorie se includ tehnicile de intervievare a utilizatorilor, de modelare
a datelor, de testare a softului, de proiectare a bazelor de date relaionale etc.
Uneori, o tehnic poate face referire la o ntreag etap a ciclului de via i include
cteva modele, iar altele fac referire doar la un model sau la documentaia sistemului.
Se poate spune c o metodologie cuprinde o colecie de modele, instrumente i tehnici
utilizabile n fiecare din etapele ciclului de dezvoltare al sistemului. Ca n aproape orice
domeniu, specialitii sistemelor informaionale apeleaz la instrumente software ce i sprijin
n desfurarea multora dintre activitile care se preteaz la automatizare.
Existena unei mari varieti de modele, instrumente, inclusiv metodologii, poate crea
confuzii, n special, pentru cei care sunt noi n domeniu. Uneori, se pare c fiecare firm i are
propria abordare a dezvoltrii sistemelor informaionale, iar n cadrul aceleiai firme se poate
ntmpla ca echipele de specialiti s foloseasc metodologii diferite. ns, ei trebuie s fie
familiarizai cu cele mai utilizate i cunoscute metodologii de dezvoltare, motiv pentru care
prezentm, n continuare, cteva dintre caracteristicile eseniale ale acestora.
Metodele ar putea fi grupate, prin prisma celor mai muli autori, astfel:
metode orientate spre funcii, numite i metode ale descompunerii funcionale;
metode orientate spre fluxuri de date, deci metode orientate spre procese, deoarece
diagramele fluxurilor de date se ntrebuineaz pentru descrierea proceselor;
metode orientate spre informaii sau date, orientate-informaii, probabil i datorit
popularizrii puternice a ingineriei informaiei a lui James Martin, dar i a diagramelor
entitate-relaie ale lui Chen;
metode orientate-obiect.
Pe de alt parte, considerm c este destul de motivat i o grupare de genul:
metode empirice, nefundamentate sistemic;
metode orientate spre sistem, n care ar fi incluse metodele orientate spre funcii,
procese i informaii sau date;
metode orientate-obiect.
Dar, n acelai timp, i metodele orientate-obiect ar putea fi incluse n categoria metodelor
sistemice, ca i cele orientate spre funcii, procese sau spre date/informaii, pentru c sistemul
este vzut prin prisma funciilor, proceselor, datelor sau obiectelor componente.
3.3 Prezentarea general a etapelor

ciclului de via al sistemelor informaionale
Pentru a avea o imagine general asupra etapelor care se parcurg n dezvoltarea unui
sistem informaional, plecnd de la principiile metodologiei structurate i ale ciclului de via
n cascad, vom face o trecere n revist a principalelor obiective urmrite n cadrul fiecrei
etape, urmnd a fi detaliate n capitolele ce urmeaz.
Dezvoltarea sistemului ncepe prin identificarea unei probleme, a oportunitilor care
impun un astfel de proces, precum i prin stabilirea obiectivelor noului sistem, dup care are
loc planificarea fiecrei activiti i a resurselor solicitate, ceea ce se constituie n aa-numita
microanaliz a sistemului. Urmeaz celelalte etape de dezvoltare propriu-zis, respectiv
analiza, proiectarea, implementarea, exploatarea i ntreinerea, aa cum rezult din fig. 3.4.
Etapa de microanaliz a proiectului are drept int stabilirea unei strategii generale de
dezvoltare a sistemului informaional la nivelul ntregii firme, identificarea celor mai
importante proiecte care ar trebui desfurate n urmtoarea perioad de timp, selectarea unuia
sau mai multora dintre ele, n funcie de resursele de care dispune firma, dar i de efectele sau
urgena implementrii lor, planificarea activitilor proiectului selectat, a resurselor necesare,
elaborarea studiilor de fezabilitate.
Dup selecia proiectului, cea mai important activitate o constituie definirea clar a
problemei i a scopului pentru sistemul cerut, n sensul c trebuie s se neleag ce se ntmpl
la nivelul firmei, ce obiective are firma i cum noul sistem poate conduce la atingerea lor. n
aceast etap, nu se vor cunoate toate funciile i procesele de prelucrare de inclus n sistem,
dar este important s se identifice exact care sunt avantajele pe care le aduce noul sistem, ce
activiti economice sprijin i ce probleme pot fi rezolvate cu ajutorul lui.
Activitile de planificare i alocare a resurselor sunt strns legate ntre ele, presupunnd
evidenierea clar a sarcinilor, activitilor i personalului necesar. Proiectele mari solicit
elaborarea unor planificri riguroase, cu jaloane i proceduri de control specifice fiecrei etape
sau fiecrui grup de activiti.
Urmtorul pas l constituie determinarea fezabilitii. Multe proiecte sunt iniiate ca parte
a unui plan strategic de dezvoltare a sistemului informaional la nivelul ntregii firme, n cadrul
cruia pentru fiecare proiect este necesar s se demonstreze c este cu adevrat necesar i c se
justific eforturile depuse pentru finalizarea lui. Analizele de fezabilitate urmresc aspectele
financiare, juridice, operaionale, tehnice i de timp pentru a stabili dac proiectul poate fi
continuat sau nu, n funcie de resursele solicitate, perioada necesar recuperrii investiiilor,
beneficiile cantitative i calitative pe care le aduce, modul n care rspunde obiectivelor firmei.
n final, planul de dezvoltare a sistemului este supus spre analiz conducerii. Dac se
obine aprobarea, proiectul poate fi iniiat, n sensul c vor fi alocate fondurile necesare, se va
organiza echipa de dezvoltare i vor fi puse la dispoziie toate celelalte resurse solicitate, cum
ar fi instrumentele de dezvoltare, birourile, echipamentele.
A.
IDENTIFICAREA I
SELECIA PROIECTULUI
MICROANALIZA
B. INIIEREA I
PLANIFICAREA
PROIECTULUI
FA
ZE
LE
C.
C
IC
LU
ANALIZA
L
UI
DE
VI
A

AL
D.
DE
TREI ACTIVITI PRINCIPALE
PROIECTAREA LOGIC
ZV
OL
T
RI
I SIS
E.
TE
M
PROIECTAREA FIZIC
EL
OR
F.
IMPLEMENTAREA
G.
NTREINEREA
1. Identificarea potenialelor proiecte de dezvoltare
2. Clasificarea i ierarhizarea proiectelor
3. Selecia proiectelor de dezvoltare
Fig. 3.4 Ciclul de via al dezvoltrii sistemelor
Dup ce planul iniial al proiectului a fost finalizat, se merge mai departe cu etapa de
analiz, prin care se urmrete identificarea i documentarea cerinelor funcionale i
nonfuncionale ale noului sistem. Cuvintele cheie ale acestei etape sunt identificare i
nelegere6, care presupun studierea sistemului existent, determinarea cerinelor pentru noul
sistem, ierarhizarea cerinelor, generarea i evaluarea variantelor de proiectare, elaborarea
documentaiei de analiz, evaluarea proiectului i soluiilor identificate pentru a obine
aprobarea necesar continurii cu etapa de proiectare.
6. Satzinger, J.W., Jackson, R.B., Burd, S.D. op. cit., p. 36.

Culegerea informaiilor se desfoar pentru a nelege ct mai bine domeniul problemei,

nevoile informaionale ale utilizatorilor, cunoaterea n detaliu a modului n care funcioneaz
actualul sistem, n sensul identificrii celor 5 C7:
1. Ce persoane sunt afectate de actualul i noul sistem?
2. Ce activiti economice realizeaz fiecare dintre persoanele identificate?
3. Care este mediul n care se desfoar activitile economice?
4. Care sunt momentele n care au loc procesele de prelucrare a datelor generate de
activitile economice?
5. Ce presupune realizarea procedurilor din sistemul curent?
Din obinerea rspunsurilor la cele cinci ntrebri se poate identifica modul cum
funcioneaz actualul sistem, scopul lui, punctele tari care trebuie pstrate n noul sistem i
cele slabe care ar trebui eliminate sau nlocuite.
Analiza sistemului este o activitate esenial n aflarea situaiei existente i a ceea ce se
dorete n viitor. Informaiile privind sistemul curent i cerinele pentru noul sistem se pot
obine prin intermediul mai multor tehnici, cum ar fi observarea a ceea ce fac utilizatorii,
intervievarea lor sau sondarea pe baz de chestionare, analiza documentelor i a procedurilor
de lucru, a regulilor economice i a responsabilitilor fiecrui loc de munc care este
influenat sau influeneaz funcionarea sistemului, a documentaiei sistemul informatic
existent. Pe lng utilizatorii sistemului, este necesar s se culeag informaii i de la alte
persoane interesate, respectiv reprezentanii conducerii tactice i strategice, partenerii de
afaceri, finanatorii proiectului. De asemenea, se poate apela i la ceea ce se ntlnete sub
denumirea de metode moderne de culegere a cerinelor, respectiv sesiunile JAD (Joint
Application Design), sistemele de sprijinire a grupurilor de lucru, prototipizarea i RAD (Rapid
Application Development).
Dar nu este suficient simpla culegere a informaiilor. Analitii trebuie s le revizuiasc,
analizeze i structureze astfel nct cerinele noului sistem s fie uor nelese. Aceast
activitate este cunoscut sub numele de structurarea cerinelor i implic construirea unor
modele specifice: modelul proceselor, modelul logicii proceselor i modelul conceptual al
datelor.
Obiectivul crerii modelelor este de a transpune sub form de diagrame principalele
componente ale sistemului (procese de prelucrare, intrri, ieiri, locuri de stocare a datelor). Pe
baza lor se construiete un aa-zis dicionar (depozit) al metadatelor, prin care sunt surprinse
toate detaliile privind elementele regsite n diferitele modele create. De exemplu, se descrie
formatul fluxurilor de date (tipul atributelor pe care le conin, mrimea lor, momentul n care
se obin sau sunt supuse proceselor de prelucrare .a.m.d.).
Atunci cnd apar restricii de fonduri sau resurse, unele cerine identificate nu vor putea fi
cuprinse n noul sistem, ceea ce nseamn c echipa de dezvoltare, mpreun cu utilizatorii i
reprezentanii conducerii, trebuie s stabileasc o ierarhie a lor, iar, mai departe, se identific
diferite soluii de proiectare a sistemului: dezvoltarea n interiorul firmei, cumprarea unui
pachet software existent pe pia, externalizare. Soluiile sunt supuse ateniei conducerii,
urmnd s fie aleas cea care rspunde cel mai bine analizelor cost/beneficiu.
n finalul etapei de analiz, se pregtete o documentaie necesar proiectrii, prin care
sunt surprinse toate aspectele privind modul de funcionare a sistemului curent, cror nevoi i
cerine trebuie s rspund noul sistem, ce funcii trebuie s cuprind i ce obiective trebuie s
sprijine.
n etapa de proiectare logic se urmrete dezvoltarea arhitecturii sistemului, pregtirea
specificaiilor de proiectare a ieirilor, intrrilor, bazelor de date, interfeelor-utilizator,
controalelor i procedurilor de realizare a copiilor de siguran, programelor etc., independent
de platformele pe care urmeaz s fie instalat sistemul. Aceste activiti se bazeaz pe
utilizarea informaiilor culese i a modelelor create n timpul analizei.
7. Kendall, K.E., Kendall, J.E. op. cit., p. 12.

Proiectarea logic se deruleaz prin intermediul a trei pai sau subfaze:

proiectarea formularelor/formatelor (pentru preluarea datelor) i a rapoartelor, prin
intermediul crora utilizatorii vor avea imaginea intrrilor i ieirilor noului sistem;
proiectarea interfeelor i a dialogurilor, pentru evidenierea modului de comunicare
a utilizatorului cu programele i echipamentele;
proiectarea logic a bazelor de date, prin care este descris structura bazei de date a
sistemului, ce va fi uor de implementat prin multitudinea de tehnologii existente n
acest domeniu.
Toate intrrile i ieirile vor fi prezentate, n etapa proiectrii logice, ca fluxuri ale datelor
ntre procesele de prelucrare sau ntre o surs/destinaie i un proces, aa cum au fost redate n
diagramele fluxurilor de date. De regul, se poate proiecta cte un formular sau raport pentru
fiecare flux de date.
Totui, punctul de plecare n modelarea logic l constituie diagramele entitate-relaie,
dei, n plus, vor fi utilizate nu numai datele din acestea, ci i cele descoperite n timpul
proiectrii logice. Similar, din diagrama de aciuni vor fi preluate evenimentele ce declaneaz
aciunile utilizatorului, semnalate prin meniuri, butoane, comenzi date calculatorului.
De menionat c subfazele acestei etape nu trebuie s fie parcurse secvenial, ele aflndu-
se ntr-o strns interdependen.
Dup parcurgerea etapei de proiectare logic, n multe metodologii cunoscut i ca
proiectare conceptual sau, adesea, mai simplu, proiectarea sistemelor, o formulare destul de
ambigu, se trece la o nou etap, proiectarea fizic, la rndul ei numit i proiectare de
detaliu. Ultimul nume este n legtur cu proiectarea general, o alt variant de definire a
proiectrii logice. De fapt, printr-o astfel de referire se scoate n relief faptul c n timpul
proiectrii logice se prezint o imagine de ansamblu (general) a sistemului, n timp ce
proiectarea fizic nseamn o abordare detaliat a acestuia. Cu alte cuvinte, n etapa de
proiectare logic se acumuleaz informaiile de natur s sintetizeze cerinele utilizatorilor
noului sistem, operaiune prestat de analitii de sistem, iar n timpul proiectrii fizice se
prezint punctele de vedere ale specialitilor, cum ar fi cei din domeniile bazelor de date,
securitii sistemelor, reelelor de calculatoare, controlului i auditrii sistemelor, programrii
.a. pe scurt, ale tehnicienilor. Ca atare, i specificaiile acestei etape nu vor avea un
pronunat caracter tehnic, preocuprile fiind ndreptate spre schiarea structurii sistemului, i
nu spre modul concret de realizare a lui.
Proiectarea fizic implic parcurgerea urmtorilor pai:
1. proiectarea fiierelor fizice i a bazelor de date. O astfel de activitate nseamn
descrierea modului n care vor fi stocate i accesate datele n/din memoriile secundare
i cum se va asigura controlul lor pentru a se oferi o securitate maxim.
2. proiectarea arhitecturii programelor. Se descriu programele sau modulele acestora
care s fie n strns concordan cu diagramele fluxurilor de date i cu celelalte piese
ale documentaiei realizate n etapele anterioare.
3. proiectarea strategiilor de prelucrare distribuit. Se vor prezenta modalitile n care
utilizatorul poate s dispun de datele i facilitile de prelucrare oferite de reelele de
calculatoare.
Cum etapa care urmeaz este implementarea, orice situaii care nu convin specialitilor
trebuie s fie rezolvate n timpul proiectrii fizice, evitndu-se cheltuielile suplimentare, mult
mai mari, care ar putea s apar dup aceast etap.
n timpul etapei de implementare, sistemul este construit, testat i instalat. Obiectivul
activitilor specifice nu este numai de asigurare a funcionrii sistemului, n concordan cu
nevoile identificate, ci i a faptului c utilizatorii sunt instruii astfel nct firma s beneficieze
de rezultatele prevzute prin exploatarea corespunztoare a acestuia. Principalele activiti care
se desfoar n cadrul etapei sunt:
realizarea i testarea programelor;
conversia sistemului prin nlocuirea vechilor proceduri i a datelor n formatul cerut

de noul sistem;
instalarea sistemului, prin care echipamentele sunt plasate n configuraia proiectat,
softul de sistem i de aplicaii este instalat pe echipamente;
instruirea utilizatorilor pentru oferirea tuturor explicaiilor i cunotinelor necesare
exploatrii sistemului la parametrii la care a fost proiectat;
elaborarea documentaiei sistemului i a manualelor de utilizare, exploatare i
ntreinere.
n final, sistemul se poate considera a fi funcional, dar el trebuie supus revizuirilor
periodice pentru a se asigura ntreinerea acestuia, fie pentru corectarea eventualelor erori
aprute n exploatarea lui, fie pentru mbuntirea caracteristicilor sau funciilor, ca rspuns la
modificarea unor cerine organizaionale. Aceast etap este, de obicei, cea mai costisitoare,
avnd n vedere c timpul pe care i-l petrec specialitii din departamentele informatice
repezint cam 48-60% din totalul timpului alocat pentru dezvoltarea sistemului8.
Din punct de vedere al derulrii unui proiect, fazele de identificare i selecie, iniiere i
planificare a proiectelor reprezint microanaliza sistemului informaional, completat cu faza
de analiz. Proiectarea i implementarea se refer la execuia propriu-zis a proiectului.
Terminarea proiectului este etapa care reliefeaz modalitatea de finalizare a acestuia, care
poate fi una natural, normal, de nchidere a proiectului, sau una nenatural, impus sau
forat atunci cnd se constat c nu se poate merge mai departe (nc din faza de selecie a
proiectelor) sau cnd scopul pentru care a fost realizat sistemul a disprut.
3.4 Participanii la dezvoltarea sistemelor informaionale

Dezvoltarea sistemelor presupune efortul unei echipe, mai mari sau mici, n funcie de
complexitatea i dimensiunea proiectului. Echipa are responsabilitatea determinrii
obiectivelor sistemului i a construirii lui, astfel nct funcionarea lui s conduc la atingerea
lor, la rezolvarea problemelor economice sau exploatarea oportunitilor care au stat la baza
iniierii proiectului.
Echipa are un manager de proiect, care coordoneaz eforturile de dezvoltare cu ajutorul
diverselor mijloace i tehnici specifice managementului proiectelor. Alturi de managerul de
proiect, n echipa de dezvoltare sunt inclui stakeholder-ii (persoanele afectate, direct sau
indirect, de dezvoltarea sistemului, cum ar fi beneficiarii sau finanatorii proiectului),
utilizatorii sistemului, specialitii n dezvoltarea sistemelor, reprezentani ai conducerii i alte
categorii de persoane ce sprijin activitile ciclului de via al sistemului.
Managerul de proiect are responsabilitatea coordonrii resurselor umane, gestionrii
fondurilor financiare i a celorlalte resurse, finalizarea la timp a proiectului, stabilirea
planurilor de comunicare ntre membrii echipei, a momentelor i modului de monitorizare i
evaluare a derulrii proiectului. n plus, pentru asigurarea finalizrii la timp a proiectului i n
bugetul alocat, managerul de proiect are ca responsabilitate i controlul calitii proiectului,
managementul riscurilor, gestiunea contractelor de achiziie.
El poate fi o persoan din cadrul departamentului informatic, un reprezentant al
utilizatorilor sau un consultant extern, angajat pe perioada proiectului. Indiferent de unde
provine, managerul de proiect trebuie s dein competene economice, tehnice i tehnologice,
de gestiune a resurselor umane.
Stakeholder-ii sunt persoane care, direct sau indirect, beneficiaz de proiectul de
dezvoltare a sistemului. Metodologiile moderne apeleaz din ce n ce mai mult la participarea
activ, n procesul de dezvoltare a sistemului, a beneficiarilor i altor persoane interesate.

Utilizatorii sunt acele persoane care vor interaciona direct i n mod curent cu sistemul,
putnd fi angajaii firmei, managerii sau partenerii firmei. Utilizatorii au diferite roluri n
timpul proiectului:
sunt cei care explic modul de funcionare a sistemului curent i formuleaz nevoile i
cerinele informaionale pentru cel nou;
particip la evaluarea rezultatelor fiecrei etape din ciclul de dezvoltare al sistemului,
oferind feedback-ul de care au nevoie specialitii pentru completarea, modificarea sau
nelegerea mai bun a ceea ce trebuie s fac sistemul;
controleaz i monitorizeaz periodic evoluia proiectului;
particip la testarea sistemului.
Pentru sistemele complexe, n care investiiile i valoarea dezvoltrii sistemului sunt mari,
este benefic s existe n echip i un reprezentant al managementului strategic sau tactic,
pentru c un prim semnal de acceptare a noului sistem vine de aici. Din acest punct de vedere,
cel mai important rol al conducerii este de a sprijini i ncuraja proiectele de dezvoltare a
sistemelor i de aliniere a lor la strategiile firmei. De asemenea, ei particip la stabilirea
scopului i obiectivelor sistemului, analiza performanelor nregistrate de departamentul
informatic, selectarea proiectelor propuse i a politicilor privind luarea celor mai importante
decizii legate de dezvoltarea sistemelor.
Din punct de vedere al calitii de utilizatori ai sistemului, managerii particip la definirea
cerinelor informaionale pentru proiectele departamentelor pe care le coordoneaz, asist
analitii n estimarea costurilor i beneficiilor, aloc membrii-cheie n echipele de dezvoltare a
sistemelor, ca i fondurile necesare dezvoltrii i exploatrii lor.
Din categoria specialitilor n dezvoltarea sistemelor informaionale, echipa proiectului ar
putea avea n componen analiti de sistem, proiectani, programatori, administratori de reea.
Analitii de sistem, n prima etap a ciclului de via, particip la identificarea
oportunitilor i obiectivelor sistemului, dup care determin cerinele informaionale ale
utilizatorilor i asigur modelarea acestora cu ajutorul diferitelor tehnici pe care le au la
dispoziie. Ei sunt cei care trebuie s asigure cele dou concepte de baz ale etapei de analiz:
identificare i nelegere. De capacitatea lor de a surprinde toate aspectele relevante ale
sistemului curent i ale celui nou, de a nelege modul de funcionare, depind celelalte etape de
dezvoltare i, ca urmare, succesul implementrii i exploatrii noului sistem. n finalul etapei
de analiz, ei sunt responsabili cu elaborarea specificaiilor necesare etapei de proiectare.
Pentru c sunt mai apropiai de utilizatori, analitii asigur legtura dintre acetia i ceilali
specialiti, legtur esenial pentru reuita sistemului, pentru c, de cele mai multe ori,
proiectanii i programatorii folosesc un limbaj tehnic, ce nu este la ndemna i pe nelesul
utilizatorilor. Acest lucru face mult mai dificil comunicarea dintre ei i ar putea s afecteze
reflectarea cerinelor utilizatorilor n proiectarea i implementarea a sistemului. Nu n ultimul
rnd, analitii particip la testarea i conversia sistemului, fiind cei care tiu cel mai bine
particularitile domeniului economic cruia sistemul trebuie s-i rspund, precum i la
elaborarea documentaiei finale i a manualelor de utilizare.
Proiectanii asigur transpunerea cerinelor sistemului sub forma procedurilor de
prelucrare, prin apelarea la tehnici i principii specifice proiectrii interfeelor-utilizator,
bazelor de date, programelor. Tot ei sunt cei care proiecteaz procedurile de control i de
asigurare a securitii sistemului, realiznd i specificaiile necesare etapei de implementare.
Calitatea de proiectant poate fi deinut de proiectani ai interfeelor, administratori i
proiectani de baze de date, chiar i de ctre analitii de sistem.
Programatorii modific sau dezvolt programele pentru satisfacerea cerinelor
utilizatorilor, prelund specificaiile de proiectare pentru a dezvolta arhitectura programelor i
pentru scrierea efectiv a codului surs al acestora, apelnd la limbaje de programare
convenionale, la generatoare de coduri sau la limbaje orientate-obiect. De asemenea, ei
particip la activitile de testare pentru a se asigura c programele ruleaz fr erori sau c nu
au fost omise anumite funcii sau proceduri. Un rol important le revine n timpul exploatrii i
ntreinerii sistemului, atunci cnd trebuie s intervin pentru eliminarea anumitor erori
neidentificate pn la exploatarea sistemului, mbuntirea unor componente sau adugarea
unora noi.
Administratorii de reea sunt implicai n dezvoltarea arhitecturii sistemului, n situaia n
care acesta presupune o extindere la nivelul ntregii organizaii, participnd la etapa de
proiectare, prin definirea proiectului de reea, la etapa de implementare, asigurnd configurarea
reelei necesare rulrii programelor i exploatrii bazelor de date n regim distribuit, astfel
nct s se asigure accesul utilizatorilor la informaiile solicitate i la care au drept de acces,
indiferent de poziia lor geografic.
n sintez, activitile la care particip membrii echipei de dezvoltare a sistemului sunt
redate n tabelul 4.1.
Tabel nr. 4.1 Implicarea membrilor echipei n dezvoltarea sistemului
Manager Utilizatori
Manager Administrator
Activiti strategic (inclusiv Analiti Proiectani Programatori
proiect reea
sau tactic stakeholderi)
Identificarea problemelor i
obiectivelor firmei
Realizarea planului strategic de
dezvoltare a sistemelor
informaionale
Iniierea i selectarea
proiectelor
Planificarea proiectului
Studierea sistemului existent
Determinarea cerinelor noului
sistem
Modelarea sistemului
Ierarhizarea cerinelor
Generarea i evaluarea
variantelor strategice
Elaborarea specificaiilor de
analiza
Proiectarea logic a datelor
Proiectarea interfeelor i
formularelor
Proiectarea structurii
programelor
Proiectarea arhitecturii
sistemului
Proiectarea procedurilor de
control
Elaborarea specificaiilor de
proiectare
Scrierea programelor
Testarea programelor i
sistemelor
Conversia sistemului
Instruirea utilizatorilor
Elaborarea documentaiei i
manualelor sistemului
Exploatarea i ntreinerea
sistemului
Modul de implicare a fiecrui membru al echipei de dezvoltare a sistemului va fi prezentat
i n capitolele ce urmeaz, atunci cnd se vor detalia activitile specifice fiecrei etape i se
vor descrie tehnicile posibil de utilizat.
Rezumat
Firmele sunt nevoite s modifice sau s nlocuiasc sistemele datorit urmtoarelor cauze: ca parte
a unui program mai amplu de modernizare a ntregului sistem; schimbarea unor aspecte de baz n
responsabilitile i activitile utilizatorilor; redefinirea obiectivelor strategice ale organizaiei; nevoia
creterii performanelor aplicaiilor informatice, a funcionalitii de exploatare sau mbuntirea
interfeelor-utilizator; necesitatea accesrii directe i ntr-un timp ct mai scurt a fiierelor firmei;
mbuntirea sistemului pentru valorificarea avantajelor oferite de tehnologiile de ultim or.
Sistemele sunt abordate prin prisma ciclului lor de via. Ele apar, se dezvolt, descresc i pier sau,
printr-un nou ciclu, se perfecioneaz, dnd natere unei alte versiuni sau chiar unui nou sistem. Problema
cea mai important o constituie ordinea i felul n care se parcurg etapele respective, ceea ce n literatura
de specialitate se abordeaz sub numele de modele ale ciclului de via al dezvoltrii sistemelor. Dintre
acestea, cele care i-au pus cu adevrat amprenta asupra evoluiei modului de dezvoltare a sistemelor
sunt: cascad, modelul V, incremental, spiral, evolutiv, tridimensional, modelul X, fntn artezian,
pinball, minge de baseball sau dezvoltarea concurent, piramid.
Ciclul de via al dezvoltrii sistemelor ofer un cadru general pentru procesul de dezvoltare, dar el
presupune cunoaterea mult mai multor elemente dect etapele din care este alctuit, elemente care fac
referire la metodologii, modele, instrumente i tehnici, de a cror nelegere depinde modul de derulare a
activitilor specifice ciclului de via.
Plecnd de la prezentarea opiniei mai multor autori, considerm c metodele de abordare a
sistemelor ar putea fi grupate astfel: metode orientate spre funcii; metode orientate spre fluxuri de date;
metode orientate spre informaii sau date, orientate-informaii; metode orientate-obiect.
Dezvoltarea sistemului ncepe prin identificarea unei probleme, a oportunitilor care impun un
astfel de proces, precum i prin stabilirea obiectivelor noului sistem, urmnd planificarea fiecrei
activiti i a resurselor solicitate, ceea ce se constituie n aa-numita microanaliz a sistemului, dup care
au loc celelalte etape specifice dezvoltrii propriu-zise, respectiv analiza, proiectarea, implementarea,
exploatarea i ntreinerea.
1. Definii ciclul de via al dezvoltrii sistemelor informaionale.
2. Care este diferena dintre un model i un instrument? Dar ntre tehnic i metodologie?
3. Care sunt obiectivele urmrite prin fiecare etap a ciclului de via al sistemelor?
4. Enumerai principalii membri ai unei echipe de dezvoltare a unui sistem informaional.
5. Descriei rolul fiecrui membru al echipei de dezvoltare n cadrul principalelor etape ale ciclului de
via.
Probleme de echip
1. Plecnd de la discuiile cu diverse persoane din firm, ncercai s identificai ce metodologie
folosesc pentru dezvoltarea sistemelor. Ai observat existena unei documentaii a sistemului
existent?
2. Cutai site-uri Web pentru cel puin 3 firme de consultan din domeniul dezvoltrii sistemelor
informaionale. ncercai s gsii informaii despre metodologia folosit pentru dezvoltarea
sistemelor. Au descris modelul ciclului de via? Este menionat pe site dac folosesc instrumente
care s le automatizeze anumite activiti din ciclul de dezvoltare?
3. ntr-o zi, Noulescu i-a parcat maina i mergea spre biroul su din Universitate. Se simea bine
pentru a-i ncepe activitatea de analist de sistem, urmnd s se ntlneasc cu ali salariai ai
departamentului informatic.
Ajungnd n birou, Noulescu este ntmpinat de Analescu, avnd urmtorul dialog:
Analescu: Am fost desemnai s lucrm ca analiti pentru un nou proiect. Am s-i spun toate
detaliile i apoi vom merge prin cldire.
Noulescu: Sun bine. De ct timp lucrezi aici?
Analescu: De aproape 5 ani. Am nceput ca analist-programator, dar n ultimii ani m-am dedicat
analizei i proiectrii. Sper s gsim cteva soluii de cretere a productivitii pentru departamentul
de informatic.
Noulescu: Spune-mi ceva despre noul proiect.
Analescu: Ca multe alte organizaii, avem un numr foarte mare de calculatoare, cu diferite
programe instalate. n anii '90 erau doar cteva microcalculatoare i cteva programe, dar numrul
lor a crescut n ultimii ani. Sistemul curent folosit pentru ntreinerea softului i hardului e complet
depit.
Noulescu: Dar despre utilizatori ce poi spune? Pe cine ar trebui s cunosc? Ce crezi c ar fi
important pentru noul sistem?
Analescu: Te vei ntlni cu fiecare, dar sunt cteva persoane-cheie cu care am discutat deja i am
s-i spun ce am constatat, pentru a ti cte ceva despre fiecare atunci cnd te vei ntlni cu ele.
Informaticescu este directorul departamentului informatic. Pare c se poate lucra foarte bine cu el.
Este foarte competent i e potrivit pentru mbuntirea comunicrii dintre utilizatori i analiti.
Noulescu: Va fi o plcere s-l cunosc.
Analescu: Apoi este Calculatorescu, expert n ntreinerea calculatoarelor. Este un tip drgu, dar
foarte ocupat. Va trebui s-l ajutm s scape de suprancrcarea cu care se confrunt. Pe partea de
ntreinere a softului este Softulescu, fire libertin i puin cam zpcit, dar nu m nelege greit, i
cunoate foarte bine meseria.
Noulescu: Pare distractiv s lucrezi cu el.
Analescu: Ar putea fi. Te vei ntlni, de asemenea, cu responsabilul financiar, Finanescu, cu
care nc nu am avut nici o discuie.
Noulescu: Cred c te pot ajuta eu cu ceva n sensul sta.
Analescu: n final, ar trebui s te ntlneti cu Prelucrrescu, care coordoneaz activitatea de
prelucrare a datelor i care e dispus s lucreze cu noi pe tot parcursul proiectului de dezvoltare a
noului sistem de ntreinere.
Noulescu: Sun promitor.
Se cere s se identifice, din conversaia anterioar, rolul pe care ar putea s-l aib fiecare
persoan descris.
CAPITOLUL IV
Microanaliza sistemelor informaionale

Obiective:
Prezentarea modului de identificare a potenialelor proiecte de dezvoltare
a sistemelor informaionale
Oferirea criteriilor necesare clasificrii i ierarhizrii proiectelor
Stabilirea modalitilor i criteriilor de selecie a proiectelor de dezvoltare
Specificarea activitilor efectuate n timpul iniierii proiectelor de dezvoltare
Prezentarea procesului de planificare a proiectului de dezvoltare
Descrierea analizelor de fezabilitate necesare pentru luarea deciziei de demarare
sau continuare a proiectului de dezvoltare a unui sistem
Dezvoltarea sistemelor este iniiat, aa cum am mai specificat, atunci cnd noul sistem
este parte a planului strategic al firmei, ce vine n sprijinul atingerii obiectivelor generale ale
acesteia, sau ca rspuns la o nevoie imediat legat de o problem de prelucrare, de obinerea
unor beneficii din exploatarea oportunitilor aprute n mediul de afaceri etc.
Iniiativele de dezvoltare a sistemului pot veni de la orice nivel al firmei i pot fi
planificate sau nu, n funcie de politicile i regulile existente, de complexitatea proiectului, de
urgena rezolvrii unei probleme. ns, trebuie avut n vedere faptul c planificarea riguroas i
implicarea managerial permit susinerea planului strategic al firmei. De aceea, este important
ca fiecare firm, pentru eficientizarea i mbuntirea condiiilor de competitivitate, s aib
planuri strategice att pentru atingerea obiectivelor generale ale organizaiei, ct i pentru
dezvoltarea sistemelor informaionale. De fapt, planul strategic al sistemelor informaionale
este parte integrant din planificarea strategic a firmei.
Odat dezvoltat planul strategic, urmeaz identificarea potenialelor proiecte de dezvoltare
a sistemelor, ce vor fi supuse ierarhizrii i seleciei, moment n care se trece la iniierea i
planificarea proiectului ales pentru a fi derulat n perioada urmtoare.
n etapa de microanaliz a sistemului, ca de altfel pe tot parcursul dezvoltrii sistemului,
un proces esenial n asigurarea succesului implementrii l reprezint managementul
proiectului.
4.1 Identificarea i selecia proiectelor de dezvoltare

Identificarea i selecia proiectelor de dezvoltare a sistemelor informaionale reprezint
prima etap din ciclul de via al dezvoltrii sistemelor care, mpreun cu iniierea i
planificarea proiectelor, constituie microanaliza, component preluat din managementul
proiectelor. Dup cum am prezentat n capitolul anterior, n vederea asigurrii unui control al
tuturor etapelor i a ncadrrii celei de fa n ntregul ciclu de dezvoltare, este folosit modelul
cascad, din care rezult cu claritate c orice etap se descompune n activiti, ceea ce, pentru
identificarea i selecia proiectelor, nseamn: identificarea potenialelor proiecte de
dezvoltare, clasificarea i ierarhizarea lor, selecia proiectelor.
Aceast faz este mai puin formalizat, n sensul stabilirii unor activiti clare i a
succesiunii n care acestea trebuie realizate, a definirii produselor ce trebuie s rezulte. Mai
MICROANALIZA SISTEMELOR INFORMAIONALE 55
mult, unele dintre activiti pot s nu fie necesare (sau ele s fi fost deja realizate), dac n
cadrul organizaiei exist o planificare strategic din care s rezulte cerinele informaionale
ale organizaiei, care s se concretizeze n definirea unui plan al sistemului informatic.
4.1.1 Potenialele proiecte de dezvoltare

La un moment dat, mbuntirea unui sistem informaional se impune cu acuitate, caz n
care trebuie realizat o investigare, pentru a determina dac sistemul nou va fi sau nu angajat.
Parcurgerea acestei faze trebuie s ofere rspunsul la urmtoarele probleme eseniale: De ce
este necesar proiectul unui nou sistem?, Ce se urmrete prin proiect?, Poate fi realizat
proiectul?, Ce trebuie fcut pentru realizarea proiectului?.
Proiectele de dezvoltare a sistemelor pot fi clasificate dup scop n:
1. proiecte care sunt susinute de o singur categorie de utilizatori i se orienteaz spre o
singur aplicaie sau un grup de aplicaii;
2. proiecte care sunt globale, ce urmresc dezvoltarea sistemelor integrate i acoper
domenii funcionale multiple dintr-o firm. n aceast categorie pot fi ncadrate cele
care abordeaz sistemele de informare a conducerii, sistemele de sprijinire a proceselor
decizionale, sistemele pentru conducerea strategic, reproiectarea proceselor
economice etc.
Proiectul este, de cele mai multe ori, iniiat prin cererea unui utilizator pentru un anumit
serviciu, recunoaterea de ctre utilizator a existenei unei probleme sau ca o propunere din
domeniul prelucrrii datelor, ca rspuns la o analiz ce a abordat fie o problem, fie
posibilitatea de a automatiza o anumit funcie.
Scopul i mrimea modificrilor funcionale i procedurale din cadrul sistemelor pot fi
aproape nesemnificative sau deosebit de complexe. n unele cazuri, n afar de reproiectarea
ntregului sistem, pot fi i modificri pariale, care s nu influeneze funcionalitatea lui.
Identificarea tipurilor de proiecte este necesar ca urmare a apariiei unor probleme, aa
cum am vzut n capitolul anterior, probleme care au diferite forme de manifestare. O
modalitate de identificare a lor i a modului n care i fac simit prezena este cea de a urmri
ce obiective ale firmei nu au fost realizate niciodat sau nc nu au fost atinse. Apelarea la
analiza planificat/realizat ofer suficient de multe informaii despre discrepanele existente
ntre performana nregistrat de firm i cea dorit sau planificat, astfel nct pot fi
evideniate cauzele care au generat diferenele respective, o parte din ele referindu-se la
sistemele informaionale.
De asemenea, o form prin care se pot gsi posibile dificulti n funcionarea unui sistem
informaional const n preluarea i analiza feed-back-ului de la partenerii de afaceri, sub
forma sugestiilor sau a reclamaiilor.
Simptomele apariiei problemelor care determin iniierea unor proiecte de dezvoltare a
sistemelor informaionale sunt redate n tabelul 4.1.
n unele situaii, simptomele sunt evidente, din lipsa de eficien i utilitate a informaiilor
generate de sistem, ce conin prea multe erori, sunt obinute ntr-o perioad prea mare de timp,
sunt incomplete sau incorecte. Alte semne ale apariiei problemelor devin sesizabile atunci
cnd salariaii nu mai nregistreaz performane deosebite, comparativ cu responsabilitile pe
care le au. Modificarea comportamentului lor, cum ar fi absenteismul, un nivel ridicat al
insatisfaciei la locul de munc, ar trebui s alerteze managerii i s-i determine s reevalueze
modul n care sistemul informaional sprijin ndeplinirea atribuiilor fiecrui loc de munc.
Avnd n vedere diversitatea cauzelor ce determin iniierea unui proiect, punctul de
plecare poate fi, de asemenea, destul de diferit de la un proiect la altul. Aceste puncte de start
reflect diferenele existente n mediile de prelucrare ale utilizatorilor i ale gradului de
automatizare, motiv pentru care proiectele de dezvoltare a sistemelor informaionale se pot
grupa n trei mari categorii:
1. complet manuale;
2. parial manuale i parial informatizate;
3. informatizate complet, cu urmtoarele patru subtipuri:
a. modificri minore ale sistemului, de genul rescrierii aplicaiilor cu ajutorul altor
limbaje de programare;
b. mbuntirea i ntreinerea sistemului;
c. reproiectarea i redezvoltarea sistemului.
Tabel nr. 4.1 Identificarea potenialelor probleme la nivelul firmei i al sistemului informaional
Mod de identificare Simptome ale apariiei problemelor
Compararea rezultatelor cu Prea multe erori
performanele dorite Activiti derulate ntr-un timp mai mare dect ar fi normal
Activiti generatoare de date eronate, incomplete
Activiti nefinalizate
Analiza feedback-ului de la clieni, Reclamaii din partea clienilor i furnizorilor

distribuitori, furnizori Numr prea mare de sugestii primite privind mbuntirea
unor activiti
Pierderi nregistrate din vnzarea unor produse
Volum sczut al vnzrilor
Pierderi de parteneri tradiionali
Observarea comportamentului Absenteism mare

salariailor Insatisfacie la locul de munc
Fluctuaie mare a forei de munc
Sursa: prelucrare dup Kendall, K.E., Kendall, J.E. Systems Analysis and Design, 5th Edition, Prentice
Hall, Upper Saddle River, New Jersey, 2003, p. 56.
Cauzele pot fi identificate prin evaluarea periodic a sistemului, iar problemele pot s fie
ridicate de ctre utilizatori, conducere sau de ctre un compartiment specializat n sisteme
informatice.
O astfel de problem poate fi supus ateniei, formal sau informal, celor ndreptii s ia
decizii n privina dezvoltrii sistemelor. Calea informal (de obicei, verbal) este urmat de
cele mai multe ori de o cerere formal, adic a unui memoriu sau a unei cereri scrise. Indiferent
de forma luat, ea trebuie s conin numele celui care solicit, natura solicitrii (fie natura
problemei economice care trebuie rezolvat, fie tipul serviciului solicitat), motivul solicitrii,
precum i timpul n care se dorete rezolvarea problemei. Cererea trebuie, de asemenea, s aib
semnturile persoanelor autorizate, informaii privind sursa de finanare a proiectului i oricare
alte elemente ce scot n eviden prioritatea solicitrii.
Este de preferat ca nici un proiect s nu fie propus fr aceste informaii. Dei structura
solicitrii poate s varieze, coninutul unei cereri de dezvoltare a sistemului informaional
trebuie s dea posibilitatea surprinderii urmtoarelor aspecte:
identificarea, n mod clar, a cauzelor care impun schimbarea;
nominalizarea obiectivelor urmrite;
specificarea avantajelor i costurilor preconizate;
identificarea finanatorului i a celui ce va prelua sistemul la finalizarea lui.
Cererea va fi analizat de compartimentul care se ocup cu dezvoltarea/ ntreinerea
sistemelor, dac exist, sau de cei care iau decizii n aceast privin i se va hotr dac poate
fi satisfcut de sistemul existent, cu eventuale mici modificri, sau sunt necesare modificri
majore care impun trecerea la operaia de analiz a sistemului.
Problema principal a activitii de identificare a potenialelor proiecte de dezvoltare
const n nominalizarea celor ce pot fi abilitai s fac propuneri pertinente. Din experiena
acumulat n practic, rezult c acetia pot fi grupai n patru categorii distincte, dup cum
urmeaz:
un reprezentant al top-managerilor, fie directorul general al ntreprinderilor mici i
mijlocii, fie un director al ntreprinderilor mari;
un comitet de organizare creat cu un scop special de ctre managerii unor
compartimente interesate;
compartimentele utilizatorilor, fie printr-un ef al grupului solicitant, fie printr-un
comitet de iniiativ, care decid ce proiecte s fie propuse (Noi, n calitate de analiti,
vom ajuta utilizatorii s-i formuleze cerinele!);
un grup de dezvoltare a sistemului sau reprezentantul compartimentului de
informatic.
Caracteristicile eseniale ale variantelor de proiecte propuse, n cele patru situaii, sunt
prezentate n tabelul 4.2.
Tabel nr. 4.2 Variante de propuneri de proiecte
Propuneri Metoda de selecie Caracteristicile proiectului
a proiectului
orientare puternic spre strategie;
Top-managerii cele mai mari dimensiuni ale proiectului;
cele mai de durat proiecte.
De sus n jos orientare mixt (a diferiilor reprezentani);
Comitetul de vizeaz schimbrile organizaionale cele mai mari;
iniiativ analiz riguroas a costurilor i avantajelor proiectelor;
proiecte mai mari i mai riscante.
limitat, neorientat strategic;
Departamentul realizare mai rapid;
utilizatorilor civa utilizatori reprezint niveluri ale conducerii,
De jos n sus precum i funciile ntreprinderii.
integrare n sistemul existent;
Grupul de
puine ntrzieri n realizarea proiectului;
dezvoltare
mai puin interesat de analizele cost/beneficii.
4.1.2 Clasificarea, ierarhizarea i selecia proiectelor de dezvoltare

Procesul de clasificare a proiectelor are ca scop scoaterea n eviden a importanei
propunerii. De regul, aceasta este sugerat de cei ce fac propunerile i, n mod firesc, reflect
punctele lor de vedere.
De aceea, este bine s se asigure c motivaia propunerii unui proiect nu reprezint o
modalitate de mbuntire a reputaiei unei persoane sau de cretere a puterii de influen a
unui grup de persoane, pentru c exist riscul ca un astfel de proiect s fie prost conceput i,
eventual, greu acceptat de ceilali.
n vederea uniformizrii operaiunii de evaluare a proiectelor propuse, se recomand
respectarea criteriilor din tabelul 4.3.
Momentele evalurii proiectelor sunt diferite, dar, de regul, Comitetele de organizare se
ntrunesc lunar sau trimestrial, pentru evaluarea noilor propuneri fa de cele deja existente i
pentru urmrirea proiectelor n curs de execuie. Aprecierile se dau prin note, pentru
ierarhizare.
Datorit efectelor diferite i amplitudinii lor, se recomand evidenierea distinct a
proiectelor pe termen lung i a celor pe termen scurt. Dintre acestea, se selecteaz cele ce ating
obiectivele organizaiei. De asemenea, se va urmri modul n care proiectele se aliniaz
dinamicii unitii. Decizia de selecie este un proces complex prin care sunt luai n considerare
mai muli factori, conform figurii 4.1.
Tabel nr. 4.3 Criterii recomandate pentru evaluarea proiectelor

Criteriul de evaluare Scurt descriere
Aliniere strategic Msura n care proiectul vizeaz atingerea obiectivelor strategice ale
organizaiei, precum i scopurile ei pe termen lung.
Ctiguri posibile Gradul n care proiectul contribuie la creterea profitului, la
mbuntirea calitii serviciilor, precum i pe ce durat se nregistreaz
acestea.
Disponibilitatea resurselor Tipurile i mrimea resurselor solicitate, precum i disponibilitatea lor.
Dimensiunea (mrimea) Numrul de persoane necesare, durata desfurrii proiectului, costurile
proiectului/durata lui i rezultatele sale.
Dificulti tehnice/riscuri Nivelul dificultilor tehnice de realizare cu succes a proiectului ntr-un
anumit timp i cu restriciile de resurse date.
NEVOILE RESURSELE
PERCEPUTE I EXISTENTE I
CELE REALE DISPONIBILE
DECIZIA LUAT:
PROIECT ACCEPTAT
PROIECT RESPINS
PROIECT AMNAT
LISTA DECIZIA DE
PROIECTELOR SELECIE A PROIECT REORIENTAT
POTENIALE PROIECTULUI
I N EXECUIE REALIZAT DE
UTILIZATORUL FINAL
VERIFICAREA/PROBA
PROIECTULUI
MEDIUL
ORGANIZAIONAL CRITERII DE
CURENT EVALUARE
Fig. 4.1 Factorii de selecie a proiectelor
Rezultatele primei etape a ciclului de via al dezvoltrii sistemelor se concretizeaz ntr-

o planificare calendaristic a proiectelor, venite de sus-n-jos i de jos-n-sus, pentru a fi
trecute n a doua etap a ciclului de via (iniierea i planificarea proiectului), dup cum reiese
i din figura 4.2.
DE SUS N JOS
TOP MANAGEMENT
COMITET DE INIIATIV
PLANIFICAREA
CALENDARISTIC A
EVALUARE PROIECTELOR
STABILIRE PRIORITI 1. .
PLANIFICARE CALENDARISTIC 2. .
A PROIECTELOR 3. .
DE JOS N SUS
DEPARTAMENT UTILIZATORI
GRUP DE DEZVOLTARE
Fig. 4.2 Rezultatele primei etape a ciclului de via

4.1.2 Planificarea sistemului informaional

Al doilea proces de planificare, ce joac un rol major n realizarea operaiunilor de
identificare i selecie a proiectelor, este planificarea sistemului informaional.
Planificarea sistemului informaional este un ansamblu ordonat de mijloace de evaluare a
cerinelor informaionale ale unei organizaii i de definire a sistemelor informaionale, a
bazelor de date, precum i a tehnologiilor ce vor satisface aceste cerine.
Datorit rolului vital pe care tehnologiile informaionale l au n creterea eficienei i
performanei activitii firmei, n succesul elaborrii i aplicrii strategiilor, planificarea
sistemelor informaionale prezint o importan deosebit, cel puin din urmtoarele motive:
permite firmelor s fac fa diverselor mize generate de progresul rapid al
tehnologiilor informaionale;
asigur ncadrarea obiectivelor sistemului informaional n obiectivele generale ale
firmei i integrarea n planul de afaceri al acesteia;
nlesnete o mai bun integrare a diferitelor componente ale sistemului informaional
i, astfel, o reducere a costurilor legate acestea;
faciliteaz obinerea acceptului conducerii i implicarea utilizatorilor, evitnd astfel
apariia unor probleme de natur comportamental;
sprijin conducerea n asigurarea resurselor viitoare ale sistemului.
Ca urmare, planificarea sistemelor informaionale se nscrie n procesul de planificare
strategic, tactic i operaional din cadrul organizaiei, putnd vorbi, i n cazul sistemelor
informaionale, de o planificare pe cele trei niveluri.
Planificarea strategic a sistemelor informaionale definete politicile, obiectivele i
strategiile necesare distribuirii serviciilor informaionale i a repartizrii resurselor
informaionale astfel nct sistemul informaional s contribuie la atingerea obiectivelor din
planul strategic al firmei. O asemenea planificare presupune analiza stadiului de informatizare
al firmei i a cerinelor legate de resursele informatice, precum i o analiz mai general a
mediului n care-i desfoar activitatea organizaia i care privete studierea conjuncturii
economice i tehnologice (n planul tehnologiilor informaionale).
Planificarea tactic a sistemelor informaionale presupune identificarea i evaluarea
detaliat a nevoilor curente i viitoare de resurse informatice, pe baza crora se definesc mai
multe proiecte individuale de dezvoltare a unui nou sistem informatic, a unor noi componente
sau de mbuntire a sistemului. Aceste proiecte sunt integrate ntr-un plan de dezvoltare,
defalcat pe o perioad de mai muli ani. n acest plan se prevede i alocarea resurselor
financiare, fizice, logice i umane necesare.
Planificarea operaional a sistemelor informaionale vizeaz ntocmirea bugetului anual
de exploatare i planificarea detaliat a proiectelor individuale prevzute n cadrul planificrii
tactice. n bugetul anual de exploatare se repartizeaz resursele financiare i de alt natur
necesare desfurrii activitii curente din cadrul sistemelor informaionale, precum i
dezvoltrii sau ntreinerii lor. Planificarea proiectelor este legat de gestiunea proiectelor
individuale, respectiv planificarea i controlul realizrii proiectelor de dezvoltare a sistemului.
Rezult c, n timpul planificrii, trebuie s se realizeze:
modelarea cerinelor informaionale ale organizaiilor (prezente i viitoare);
elaborarea strategiilor i planurilor proiectelor pentru realizarea deplasrii sistemului
informaional curent i a tehnologiilor existente spre o stare viitoare dorit.
Paii procesului de planificare a sistemelor informaionale sunt redai n figura 4.3.
Majoritatea metodologiilor de sprijinire a procesului de planificare a sistemului
informaional conin trei activiti principale:
descrierea situaiei curente;
descrierea situaiei int, a trendurilor, precum i a restriciilor;
elaborarea unei strategii de tranziie i a planurilor.
Situaia curent
Lista prelucrrilor manuale i automate
Pas 1 Lista datelor obinute manual i automat
Inventarul tehnologiilor
Inventarul resurselor umane
Situaia viitoare
Planul prelucrrilor manuale i automate
Pas 2 Planul datelor obinute manual i automat
Planul tehnologiilor
Planul resurselor umane
Planificarea calendaristic a proiectelor
Pas 3
B
...
1 2 3 4 5 ... 15
Fig. 4.3 Paii procesului de planificare

Cea mai rspndit modalitate de descriere a situaiei curente a organizaiei este cunoscut
sub numele de planificarea top-down. Prin ea se urmrete determinarea cerinelor
informaionale ale unitii. Se ncepe cu o analiz mai profund a misiunii organizaiei, a
obiectivelor ei i a strategiei, pentru a stabili cu exactitate informaiile necesare atingerii
obiectivelor. Metoda presupune o puternic implicare a top-managerilor. Avantajele acestei
metode fa de altele sunt prezentate n tabelul 4.5.
Opus metodei de sus-n-jos este metoda planificrii bottom-up, de jos-n-sus. Ea
presupune identificarea problemelor organizaiei i a posibilitilor oferite pentru definirea
proiectelor. Metoda cere un timp mai scurt i este mai ieftin, avnd i avantajul de a se ti cu
exactitate problemele cu care se confrunt unitatea. Ca dezavantaj se consider lipsa unui
punct de vedere de ansamblu, la nivel de unitate.
Tabel nr. 4.5 Avantajele metodei de planificare top-down
Tip avantaj Descriere
Perspectiv mai larg Dac n-ar fi vzut n primul rnd de sus, organizaia ar fi considerat ca
un sistem informaional lipsit de imagine de ansamblu.
Integrare mai bun Dac nu ar fi vzut pe ansamblu (de sus), sistemul informaional ar fi
unul nou, i nu unul integrat n cel existent.
Sprijin managerial mai Dac n-ar fi implicai factorii de decizie de pe nivelul superior,
bun planificarea sistemului informaional ar avea mai puine anse de reuit.
nelegere mai bun Dac nu s-ar vedea unitatea de sus, ar crete tendinele de abordare a unor
componente izolate ale acesteia.
Pentru obinerea informaiilor concludente asupra situaiei curente, este necesar s se
identifice i locurile de amplasare a organizaiei, unitile componente, funciile, procesele,
datele (entitile), sistemele informaionale.
Exemplu:
Locurile de amplasare a afacerii sunt descrise printr-o list a tuturor zonelor geografice n
care i desfoar activitatea.
Unitile organizatorice sunt persoane sau componente economice care presteaz activiti
n unitate. Ca uniti organizatorice pot fi amintite: fabricaie, manager vnzri, vnztori,
funcionari.
Funciile se pot regsi n ntreaga unitate i ele se exercit n cadrul activitilor zilnice,
cum ar fi: aprovizionare, producie, desfacere, personal, cercetare-dezvoltare.
Procesele sunt reprezentate printr-o list a procedurilor manuale sau automate prin care
sunt exercitate funciile ntreprinderii, ca de exemplu: prelucrare pli, prelucrare ncasri,
facturare clieni, expediie mrfuri/transport produse .a.
Entitile de date reprezint componentele altei liste din care s rezulte informaiile
obinute, actualizate, terse sau folosite n procesele de prelucrare.
Sistemele informaionale vor specifica dac se folosesc sisteme manuale sau automate
pentru transformarea datelor n informaii.
Exemplu: Sintetic, plecnd de la exemplul anterior, se pot descrie cteva funcii ale
ntreprinderii, entitile de date i sistemele informaionale, astfel:
Funcii Entiti de date Sisteme informaionale
planificare economic client prelucrare salarii
dezvoltare produse produs prelucrare pli
marketing i desfacere vnztor prelucrare creane
producie material prelucrare pontaje
finane contabilitate comand gestiune stocuri
resurse umane facturi .
echipament

Dup identificarea informaiilor de nivel superior, ele se descompun n pri mai mici
pentru a nlesni o planificare mai detaliat. De exemplu, funciile economice pot fi descompuse
n funcii ajuttoare. Sub form de schem, acest lucru este reprezentat ca n figura 4.4.
Funcii economice Funcii ajuttoare
Planificare economic
Analize ale pieelor
Prognoze vnzri
Dezvoltare produse
Cercetri de marketing
Comenzi onorate
Distribuie
Producie
Programare producie
Fabricaie
Asamblare
Finisare
Financiar-contabil
Bugetare capital
Conturi de creane
Conturi de pli
Resurse umane
Recrutare
Instruire (Training)
Antrenare (Coaching)
Fig. 4.4 Descompunerea funciilor economice n funcii ajuttoare
Dup alctuirea listelor menionate anterior, se construiesc seturi de matrice pentru a
evidenia legturile existente ntre diferitele elemente ale organizaiei. Matricele tipice sunt:
Amplasare Funcie. Se identific funciile ntreprinderii executate n diferite locuri
de amplasare a afacerii.
Amplasare Unitate (component) organizatoric. Se identific toate componentele
organizatorice amplasate ntr-un anumit loc sau care au legtur cu locul respectiv.
Component organizatoric Funcie. Identific relaiile existente ntre entitile

organizatorice i fiecare funcie a ntreprinderii.
Funcie Obiectiv. Identific funciile eseniale sau pe cele dorite n viitor pentru
atingerea fiecrui obiectiv.
Funcie Proces. Identific fiecare proces folosit pentru realizarea fiecrei funcii.
Funcie Entitate de date. Identific toate funciile care folosesc toate tipurile de date
necesare lor. Un exemplu de matrice Funcie Entitate de date este redat n fig. 4.5.
Proces Entitate de date. Identific datele culese, folosite, actualizate sau terse de
fiecare proces n parte (fig. 4.6).
Proces Sistem informaional. Identific obiectivele de prelucrare i modul n care
sistemele informaionale conduc la realizarea lor. Dac ar fi s lum n considerare ce
obiective se urmresc n privina prelucrrii datelor la nivel de firm, o astfel de
matrice ar putea fi similar cu cea prezentat n fig. 4.7.
Sistem informaional Obiectiv. Identific sistemele informaionale dup modul n
care ele contribuie la atingerea obiectivelor organizaiei.
Funcie Sistem informaional. Identific relaiile dintre funciile ce apeleaz la datele
oferite de fiecare sistem informaional (fig. 4.8)
Funcii Comercial Financiar- Producie Resurse Informatic Cercetare-
Entiti contabil umane dezvoltare
Comand
Produs
Vnztor
Factur
Material
Salariat
Furnizor
Client
.
Fig. 4.5 Matricea funcie entitate de date

Entitati Comand Produs Vnztor Factur Material Salariat Furnizor Client
Procese
Prelucrare comenzi
prin pot

Prelucrare comenzi
telefonice

Prelucrare comenzi
cataloage

Prelucrare vnzri

amnuntul
Prelucrare salarii
Prelucrare stocuri
Prelucrari
contabilitate
general
.
Fig. 4.6 Matricea proces entitate de date

Sisteme Prelucrare Prelucrare

Vnzare Resurse Contabilitate
Distribuie comenzi comenzi
Obiective procesede amnuntul umane general
pot telefonice
prelucrare
Creterea vitezei de
prelucrare

mbuntirea prelucrrii
datelor

Integrarea proceselor de
prelucrare

Reducerea erorilor
Reducerea redundanei
Eliminarea dublarii ieirilor
mbuntirea sistemului
Fig. 4.7 Matricea proces sistem informaional
Funcii Comercial Financiar- Producie Resurse Informatic Cercetare-

Sisteme contabil umane dezvoltare
Distribuie
Prelucrare comenzi

prin pot
Prelucrare comenzi

telefonice
Vnzri cu amnuntul
Resurse umane
Contabilitate
general

Fig. 4.8 Matricea funcie sistem informaional
Pentru a nelege mai bine tehnicile specifice dezvoltrii sistemelor informaionale, vom
ncepe, din acest capitol, prezentarea unui proiect de dezvoltare a sistemului de gestiune a
clienilor pentru o firm ABC, productor i distribuitor de articole de mbrcminte 1. Toate
referirile la acest proiect se vor face prin intermediul unor casete. Aadar, ncepem cu o prima
caset, Caseta 4.1, n care facem o trecere n revist a obiectului de activitate i a modului de
derulare a activitilor, pentru a nelege modul de definire a planului strategic al sistemului
informaional i pentru stabilirea obiectivelor de baz ale sistemului de gestiune a clienilor
(SGC), ca parte a planului strategic.
Caseta 4.1 Descrierea firmei ABC i planul strategic al sistemului informaional
1. Prezentarea general a firmei ABC
ABC i-a nceput activitatea n anul 1990, avnd ca iniiatori pe Patronescu i pe Patroneasca, din
Oraul 1. Ea a fost ntotdeauna pasionat de mod i mbrcminte, lucrnd n timpul facultii ca
designer i vnztor de articole de mbrcminte la magazinele din ora. El a lucrat civa ani la un
depozit de produse de mbrcminte dup terminarea facultii. mpreun, s-au decis s ncerce s
extind afacerea ei att din punct de vedere al segmentului de clieni, ct i al tipurilor de produse
vndute.
Primul pas l-a constituit dezvoltarea sistemului de vnzri prin pot pe baz de cataloage de
produse, astfel c Patroneasca a fost nevoit s-i mreasc activitatea de producie, angajnd un creator
de mod i un director de producie, care s supravegheze activitatea de pe liniile de producie. Pe
1. Exemplul se bazeaz pe modelul prezentat n 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.
msur ce interesul clienilor pentru vnzarea prin intermediul cataloagelor a crescut, firma i-a adugat
noi linii de produse i accesorii i a deschis un magazin propriu n Oraul 1.
La nceputul anului 2000, ABC a devenit unul din cei mai importani distribuitori de articole de
mbrcminte n Oraul 1 i zonele limitrofe, astfel c firma i-a dezvoltat liniile de producie pentru a
rspunde solicitrilor pieei, iar catalogul de vnzri a luat o nou form de prezentare, incluznd o gam
mult mai variat de produse.
ABC are acum 600 de angajai i vnzri de aproape 10 milioane RON anual. Vnzrile prin pot
dein ponderea cea mai mare din venituri, aproximativ 6 milioane RON, iar vnzrile prin magazinul
propriu nu depesc 0,25 milioane RON, n Oraul 1, i 0,5 milioane RON n magazinul deschis recent n
Oraul 2. n anul 1995, ABC a deschis i o linie de vnzri prin intermediul prelurilor de comenzi
telefonice, din care obine acum aproximativ 3 milioane RON. Clienii tradiionali au considerat acest
serviciu ca o extindere natural a activitii firmei, ns ABC trebuie s fac o serie de modificri
substaniale la nivelul sistemului de prelucrare a comenzilor primite n variant telefonic.
2. Aspecte privind strategia ABC
ABC a fost printre primii distribuitori de articole de mbrcminte pe Web. Iniial, site-ul a fost
conceput doar pentru mbuntirea imaginii firmei i pentru a permite potenialilor clieni s solicite
catalogul de produse i pe aceast cale. De asemenea, a servit ca un portal pentru a asigura legtura cu
principalele evenimente i festivaluri de mod. Prima mbuntire a site-ului a constat n adugarea de
informaii suplimentare pentru fiecare produs, inclusiv oferte speciale ce puteau fi comandate prin
telefon. Apoi a fost fcut disponibil on-line catalogul de produse, ns clienii, n continuare, pot s-i
formuleze comenzile numai prin pot sau telefon.
Proprietarii firmei au fost de acord s ncerce dezvoltarea comerului electronic B2C, dar
Patroneasca era ngrijorat n privina riscului de cretere neateptat a cererilor de produse, tiind c
muli productori i distribuitori mici nu au fcut fa prelucrrilor on-line i onorrii la timp a
comenzilor. O proast gestionare a stocurilor, servicii necorespunztoare, neacceptarea returnrii
produselor, emiterea de facturi duble ctre acelai client au fost cteva dintre aspectele care au fost
identificate ca poteniale riscuri.
Cei doi au recunoscut potenialul pe care l poate oferi comerul electronic, dar voiau s fac cu
pruden ceea ce trebuia fcut i s nu treac la aciune peste noapte, fr nici un plan sau o strategie. Ei
au apelat ntotdeauna la planuri i cunosc foarte bine care este impactul tehnologiilor asupra firmei, astfel
nct au dorit s acorde atenia cuvenit noii iniiative, abordnd-o la nivel strategic. De aceea, s-au decis
s analizeze atent ntreaga infrastructur tehnologic a firmei i s creeze un plan strategic de dezvoltare
a sistemului informaional, apelnd, pentru planificarea sistemului, la o firm de consultan. Firma le-a
sugerat s-i concentreze atenia asupra a dou inte strategice:
gestiunea lanului de aprovizionare, prin care s se asigure procesele necesare integrrii
activitilor de proiectare a produselor, de aprovizionare, producie i gestiunea stocurilor.
gestiunea relaiilor cu clienii, prin care s se dezvolte procesele de sprijinire a activitilor de
marketing, vnzri i servicii oferite clienilor, implicnd interaciunea direct sau indirect cu
acetia.
Ambele strategii sprijin firmele, n special comercianii cu amnuntul, prin eficientizarea
activitilor de vnzare i asisten a clienilor.
n planul strategic al sistemului informaional au fost incluse dou componente:
1. planul arhitecturii aplicaiilor, detaliindu-se proiectele de dezvoltare a sistemului pe care
firma trebuie s le pun n practic;
2. planul arhitecturii tehnologice, descriind infrastructura fizic necesar funcionrii sistemului.
Ambele componente au la baz obiectivele privind gestiunea lanului de aprovizionare i a relaiilor
cu clienii, definite pentru urmtorii 5 ani.
3. Structura organizatoric a firmei
ABC se bazeaz foarte mult pe aciunile i controlul proprietarilor ei. Patronescu este preedintele
consiliului de administraie, iar Patroneasca directorul cu distribuia. Ceilali top-manageri sunt:
Vnzrescu, director de vnzri i marketing, Economescu, director economic. Departamentul informatic
este subordonat i raporteaz directorului economic. Structura organizatoric este redata n figura C4.1.
Sunt 113 salariai care lucreaz la departamentele merchandising/distribuie, resurse umane,
financiar-contabil, vnzri i marketing, informatic la sediul central al firmei din Oraul 1. Exist dou
magazine de desfacere, n Oraul 1 i Oraul 2. Seciile de producie sunt localizate n Oraul 1 i, mai
recent, n Oraul 2. De asemenea, firma dispune de 3 depozite: Oraul 1, Oraul 2, Oraul 3. Prelucrarea
comenzilor primite prin pot este asigurat de 58 de salariai, aflai ntr-un alt corp de cldire din Oraul
1. Centrul de preluare a comenzilor telefonice are 20 de angajai, fiind situat lng cldirile n care sunt
liniile de producie din Oraul 1.
Preedinte
Patronescu
Director marketing Director economic

Director distribuie vnzri
Patroneasca Economescu
Vnztorescu
ef birou importuri ef vnzri amnuntul Contabil ef

Importescu Amnunescu Contabilicescu
Director producie ef birou promovri Resurse umane

publicitate Umanicescu
Producescu
Promovrescu
Director departament
ef achiziii interne ef birou cataloage
informatic
Achiziescu Catalogescu
Informaticescu
ef centru
ef birou proiectare ef birou
comenzi telefonice
Conceptescu dezvoltare sisteme
Telefonescu
Dezvoltrescu
ef linii producie ef birou

Liniescu ntreinere sisteme
ntreinrescu
ef depozit livrri
Livrrescu
Fig. C4.1 Structura organizatoric a firmei ABC
4. Descrierea departamentului de informatic

Departamentul este condus de Informaticescu, n calitate de asistent al directorului economic, avnd
n subordine aproape 50 de angajai, dup cum urmeaz:
Director departament de informatic (1)
Secretar (1)
ef birou dezvoltare sisteme (1)
Manageri de proiect (4)
Analiti de sistem (6)
Analiti-programatori (10)
Secretariat/personal administrativ (2)
ef birou ntreinere sisteme (1)
Manageri de proiect (4)
Administrator reea (2)
Analist/administrator baze de date (2)
Exploatare sistem (6)
Sprijinire utilizatori (4)
Secretariat/personal administrativ (2)

Exploatare sisteme alte locaii (4)
n calitate de asistent al directorului economic, directorul departamentului informatic se gndete
cum s duc la bun sfrit proiectele incluse n planul strategic. Nu are aceleai responsabiliti ca un
director plin de departament, dar poziia sa a devenit din n ce n ce mai important n firm.
Informaticescu raporteaz directorului economic, liceniat n Contabilitate i informatic de gestiune i
cu master n Informatic economic. De asemenea, departamentul trebuie s raporteze direct i
preedintelui firmei, n privina evoluiei proiectelor din planul strategic.
Informaticescu i-a organizat departamentul pe dou domenii: dezvoltarea sistemelor i ntreinerea
lor. ntreinrescu este eful biroului de ntreinere, fiind implicat n asigurarea comunicaiilor,
administrarea bazelor de date, exploatarea sistemului i acordarea de asisten utilizatorilor.
5. Sistemele informaionale existente n ABC
Cea mai mare parte din personalul i tehnologia specific sistemelor informaionale se gsete la
sediul central din Oraul 1. Pe un server central ruleaz aplicaiile privind stocurile, comenzile primite
prin pot, contabilitatea general, resursele umane, prin conectare la centrele de distribuie i la cel de
preluare a comenzilor prin pot, cu ajutorul unor linii de telecomunicaii dedicate. Seciile de producie
au posibilitatea s se conecteze la server n regim dial-up.
Birourile centrale, depozitele i producia au la dispoziie o reea local de tip file/server.
Magazinele folosesc un pachet-program de tip POS, cu ajutorul unui server local, actualizarea stocurilor
realizndu-se pe loturi, n regim de conectare dial-up la serverul central.
Centrul de preluare a comenzilor telefonice are o mic reea local, cu aplicaii ce ruleaz n regim
client/server sub Windows. Actualizarea stocurilor se face pe loturi.
Site-urile Web ale ABC sunt gzduite de un furnizor de servicii Internet, care ntreine i coninutul
static al site-ului.
Sistemele informatice i tehnologia specific sunt:
Distribuie aplicaie dezvoltat de departamentul informatic, ce apeleaz la un sistem nvechit
de gestiune a bazelor de date. A fost implementat acum 10 ani.
Prelucrare comenzi prin pot aplicaie dezvoltat n aceeai manier ca i cea de distribuie.
Personalul care preia comenzile folosete terminale dedicate. Aplicaia este rapid i eficient,
dar nu permite i preluarea comenzilor telefonice. A fost implementat acum 9 ani.
Vnzri cu amnuntul se bazeaz, aa cum s-a vzut, pe un pachet-program specializat n
prelucrrile de tip POS, actualizarea stocurilor fcndu-se pe loturi, la sfritul fiecrei zile. A
fost implementat acum 8 ani.
Administraie aplicaie sprijinit de o reea local, cu soft specific muncii de birou, acces la
Internet i e-mail, fiind implementat acum 3 ani la sediul central i la alte locaii din Ora 1.
Resurse umane aplicaie proprie pentru calculul salariilor, dezvoltat acum 12 ani, ce ruleaz
pe serverul central.
Contabilitate general aplicaie cumprat de la o firm local de software, acum 10 ani.
6. Planul strategic al sistemelor informaionale
Aa cum am vzut, planul strategic a fost realizat cu ajutorul unei firme de consultan i conine
planul infrastructurii tehnologice necesare i planul aplicaiilor. Echipa de planificare a analizat atent
sistemele existente i obiectivele economice ale firmei. Cele dou propuneri iniiale, gestiunea lanului de
aprovizionare i gestiunea relaiilor cu clienii, au oferit o viziune general privind coninutul planului.
Aceste idei sprijin obiectivele strategice ale ABC, de a construi relaii directe i stabile cu clienii i de
a-i mbunti imaginea pe pia i n vestul rii. Principalele caracteristici ale planului sunt:
1. din punct de vedere al infrastructurii tehnologice:
dezvoltarea unui sistem distribuit, pstrnd actualul server, prin care s se acopere multiplele
locaii ale firmei, ca i aplicaiile existente sau care vor fi dezvoltate, instalarea unui server
Web i reconfigurarea arhitecturii de comunicaii pentru a crete capacitatea de prelucrare;
orientarea ctre strategia competitiv a proceselor economice, prin intermediul Internetului,
mai nti sprijinind gestiunea lanului de aprovizionare, apoi asigurarea prelurii directe a
comenzilor de la clieni, prin site-ul Web i, n final, prin dezvoltarea funciilor sistemului de
gestiune a relaiilor cu clienii, prin care se vor realiza legturile cu sistemele i bazele de date
din partea de back-end a comerului electronic;
planificarea trecerii la o soluie Intranet, pentru desfurarea unor funcii economice, cum ar fi
resursele umane, financiar-contabil, sistemul de raportare ctre conducere;
2. din punct de vedere al aplicaiilor:
managementul lanului de aprovizionare: implementarea unui sistem care s integreze
proiectarea produselor, achiziiile, producia i gestiunea stocurilor, pentru a veni n sprijinul
creterii rapide a vnzrilor. Dezvoltare intern.
sistemul de gestiune a clienilor: implementarea unui sistem de prelucrare i onorare a
comenzilor care s fie integrat cu cel de gestiune a lanului de aprovizionare, astfel nct s se
asigure prelucrarea rapid a comenzilor primite prin cele trei modaliti (pot, telefon, Web),
dar cu reflectare imediat n nivelul stocurilor i planificarea produciei. Dezvoltare intern.
sistemul de sprijinire a conducerii strategice: implementarea unui sistem informaional care s
permit extragerea i analiza informaiilor privind lanul de aprovizionare i gestiunea
relaiilor cu clienii n vederea eficientizrii procesului decizional operaional i strategic, dar
i pentru efectuarea unui control mai riguros. Soluie de pe pia.
sistemul de gestiune a vnzrilor cu amnuntul: nlocuirea vechiului sistem cu unul care s
permit integrarea cu cel de gestiune a clienilor. Soluie de pe pia.
sistemul de contabilitate general: achiziia unei soluii de pe pia, posibil o aplicaie Intranet
cu arhitectur client/server.
sistemul de resurse umane: achiziia unei soluii, cu arhitectur client/server de tip Intranet,
pentru a asigura un acces eficient la formularele, procedurile i informaiile specifice
domeniului funcional.
Perioadele de timp n care urmeaz s se implementeze planul privind aplicaiile sunt prezentate n
tabelul C4.1.
Tabel nr. C4.1 Perioadele de implementare a aplicaiilor din planul strategic
Sistemul Perioada Descriere
Gestiunea lanului de 2004-2005 n curs de finalizare, urmrindu-se integrarea proiectrii,
aprovizionare aprovizionrii, produciei i gestiunii stocurilor.
Sistemul de gestiune a 2004-2005 Urmrete implementarea unui nou sistem de prelucrare i
clienilor onorare a comenzilor care s poat fi integrat cu cel de
gestiune a lanului de aprovizionare i care s sprijine toate
cele 3 modaliti de preluare a comenzilor: pot, telefon,
Web.
Sistemul de sprijinre a 2005 Soluie la cheie, pentru extragerea i analiza informaiilor
conducerii strategice din celelalte sisteme, n vederea sprijinirii procesului
decizional att la nivel strategic, ct i la nivel operaional,
pentru efectuarea activitilor de control.
Sistemul de gestiune a 2005 Soluie la cheie, care s poat fi integrat cu sistemul de
vnzrilor cu amnuntul gestiune a clienilor
Sistemul de contabilitate 2005 Soluie la cheie
general
Sistemul resurselor 2006 Soluie la cheie
umane
Celelalte sisteme din plan se vor baza pe alegerea de soluii la cheie, dar care s corespund
cerinelor de integrare ale ntregului sistem informaional al ABC.
n final, se urmrete ca ntregul sistem s foloseasc o nou baz de date distribuit, care s
integreze toate datele firmei.
7. Sistemul de gestiune a clienilor
Proiectul de dezvoltare a sistemului este cel de gestiune a clienilor. ABC i-a concentrat atenia
asupra clienilor, orientndu-i activitile n funcie de cerinele acestora. Una din competenele
strategice ale ABC a fost abilitatea de a dezvolta i pstra relaiile de loialitate cu clienii. Preedintele
Consiliului de Administraie a fost la zi, totdeauna, cu cele mai importante aspecte ale activitilor
desfurate de firm, fiind pe deplin convins c, pentru dezvoltarea eficient i competitiv a activitilor
firmei, atenia trebuie acordat clienilor. Chiar dac n sistemul de gestiune a clienilor au fost incluse
toate componentele necesare desfurrii n condiii normale a activitilor de vnzare i marketing,

Patronescu a dorit ca oricine din firm s neleag c obiectivul principal al sistemului este s sprijine
clienii ABC. Viziunea sa, cu privire la rolul clienilor pentru o firm, a devenit att de popular n
rndul consultanilor i furnizorilor de soft, nct este solicitat n oferirea de explicaii i sfaturi despre
ceea ce ar trebui s cuprind un astfel de sistem.
Planul strategic de dezvoltare a sistemului la nivelul firmei ABC a scos n eviden unele obiective
specifice ale sistemului de gestiune a clienilor, n sensul c el trebuie s includ toate funciile asociate
cu oferirea produselor, de la primirea comenzilor i pn la onorarea lor, respectiv:
solicitarea de cataloage de ctre clieni;
preluarea comenzilor de la clieni;
verificarea i urmrirea modului de onorare a comenzii;
livrarea produselor;
acceptarea returnrilor de produse;
analiza vnzrilor.
Clienii trebuie s aib posibilitatea s comande prin pot, telefon sau Internet. Toate cataloagele
de produse trebuie s fie disponibile att n format tradiional, ct i on-line i s existe coresponden
ntre coninutul cataloagelor, astfel nct, atunci cnd un produs este cutat, el s poat fi gsit att n
varianta pe hrtie, ct i n cea on-line.
Preluarea i introducerea comenzilor s poat fi realizat prin intermediul interfeelor grafice, n
regim on-line, pentru a exista rspunsuri rapide din partea agenilor de vnzri care se ocup de primirea
comenzilor prin pot i telefon. Informaiile privind returnrile, anulrile de comenzi, precum i
urmrirea lor trebuie s fie accesibile att salariailor, ct i clienilor, prin intermediul Web-ului.
Cu toate c au fost identificate o serie de obiective ale sistemului, este necesar o analiz mai
detaliat care s permit definirea complet a cerinelor informaionale, obiectivele identificate fiind doar
cteva puncte de reper necesare pentru demararea proiectului.
4.3 Iniierea i planificarea proiectelor de dezvoltare a sistemelor

Dup ce s-a decis asupra proiectului ce urmeaz a fi desfurat, se parcurg alte dou
activiti importante din faza de microanaliz, respectiv iniierea i planificarea proiectului,
eseniale pentru asigurarea atingerii scopului i obiectivelor identificate prin propunerea de
proiect.
Activitatea de iniiere a unui proiect este una din cele mai laborioase, pentru c este
momentul n care se definesc elementele privind echipa de iniiere a proiectului, modul de
comunicare i stabilire a bunelor relaii cu beneficiarii sistemului, se stabilesc procedurile
manageriale privind modalitile de raportare, atribuirea de sarcini, se definesc procedurile prin
care se pot efectua schimbri la nivelul proiectului etc. Activitatea de iniiere este prestat de
un responsabil, cunoscut sub numele de manager de proiect, care rspunde de:
elaborarea unor studii de fezabilitate generale;
elaborarea planurilor detaliate ale proiectelor;
gsirea celor mai buni membri ai echipei proiectului.
Activitatea de iniiere a proiectului de dezvoltare a sistemului de gestiune a clienilor este
prezentat n caseta 4.2.
Caseta 4.2 Iniierea sistemului de gestiune a clienilor la firma ABC
Aa cum s-a vzut, conducerea executiv a firmei ABC, cu ajutorul unei firme de consultan, a
dezvoltat un plan strategic pentru sistemul informaional. Planul de implementare a nceput cu iniierea
proiectului privind gestiunea lanului de aprovizionare. Patronescu i Patroneasca au neles c, pentru
meninerea unor bune relaii cu clienii, trebuie s aib la dispoziie un sistem care s asigure onorarea
comenzilor prin extinderea geografic a vnzrilor, precum i a celor bazate pe Internet. Firma nu poate
s beneficieze pe deplin de avantajele sistemului de gestiune a lanului de aprovizionare pn nu are un
sistem on-line de gestiune a clienilor. Cel de gestiune a lanului de aprovizionare ar trebui s conduc
la reducerea costurilor prin creterea eficienei, dar beneficiile economice reale se vor obine din
creterea vnzrilor, prin extinderea capacitilor de vnzare i marketing, cu ajutorul noului sistem.
Sistemul de gestiune a lanului de aprovizionare s-a derulat pn acum conform planificrilor,
proiectul solicitnd cteva activiti suplimentare, n sensul participrii la activitile de adaptare a
sistemelor specifice a partenerilor ABC, furnizorii tradiionali, astfel nct s se asigure
compatibilitatea lor. Prima faz a fost realizat conform planului: cerinele sistemului au fost
definitivate, proiectarea conceptual finalizat, urmnd ca la nceputul anului viitor s se treac la
implementarea noului sistem. Patronescu a stabilit o ntlnire special cu comitetul executiv al firmei,
pentru a analiza evoluia proiectelor curente i pentru a evalua posibilitatea trecerii la cel nou. nainte de
ntlnire, i-a cerut directorului economic s-i prezinte o analiz financiar detaliat privind bugetul
sistemului la care se lucreaz i previziunile impactului financiar pe care l-ar avea nceperea noului
proiect. De asemenea, l-a invitat pe directorul departamentului de informatic pentru evaluarea gradului
de ncrcare a personalului din biroul Dezvoltare sisteme i disponibilitatea de a ncepe un alt proiect.
Dup o lung discuie, comitetul executiv a decis s se nceap proiectul acum, chiar dac nu sunt
suficiente resurse, fiind ns vital pentru ABC s aib o prezen puternic pe Internet. Ca urmare, s-a
hotrt ca directorul departamentului de informatic s nceap proiectul. Astfel, el s-a ntlnit cu eful
biroului Dezvoltare sisteme, cruia i-a cerut s stabileasc un manager de proiect i un analist de sistem
cu experien pentru demararea proiectului. De asemenea, a solicitat, din partea preedintelui,
formularea unei cereri prin care s se confirme decizia luat de conducere. Patronescu a nceput prin
contactarea membrilor comitetului executiv pentru a obine acceptul lor de participare, n calitate de
membri ai comitetului de supraveghere a proiectului. De asemenea, tiind ct de importante sunt
obinerea acceptului i implicarea utilizatorilor, a cutat s includ utilizatorii cei mai afectai de noul
sistem. Directorului departamentului marketing i vnzri i s-a solicitat s fie finanatorul proiectului,
din moment ce domeniul lui funcional este directat vizat, fiind numit preedintele comitetului de
supraveghere. Ceilali membri desemnai au fost: eful biroului cataloage, eful liniilor de producie,
preedintele consiliului de administraie i directorul departamentului informatic.
Proiectul a fost demarat prin numirea ca manager de proiect a unei persoane din Biroul Dezvoltare
sisteme, Proiecteasca, angajat de civa ani n firm.
nainte, ea a lucrat, n calitate de consultant pe sisteme informaionale, la o firm de contabilitate.
Conducerea ABC are deplin ncredere n calitile i abilitile ei de a conduce proiectul de dezvoltare
a sistemului de gestiune a clienilor.
Alturi de Proiecteasca, a fost inclus n proiect i Analizescu, un analist de sistem experimentat, ei
lucrnd i la alte proiecte, avnd stiluri de lucru compatibile. Datorit importanei proiectului, n echipa
de iniiere a proiectului au mai fost implicai nc 2 analiti de sistem. Figura C4.3 red o scurt
prezentare a proiectului, prin care se justific activitile preliminare efectuate de echipa de iniiere a
proiectului.
Nume proiect: Sistem de gestiune a clienilor
Scop proiect: Creterea performanei gestiunii relaiilor cu clienii, fiind necesar s includ
toate funciile privind activitile desfurate cu acetia, de la primirea comenzilor, pn
la livrare, incluznd aici solicitarea cataloagelor de produse, preluarea comenzilor,
urmrirea lor, livrarea, acceptarea returnrilor, analiza vnzrilor.
Durata: 18 luni de la data iniierii
Buget aprobat: pn la 0,15 milioane RON
Participani cheie:
Proiecteasca manager de proiect, din cadrul Biroului Dezvoltare sisteme, va conduce
ntregul proiect.
Dezvoltrescu ef Birou Dezvoltare sisteme, va superviza activitatea managerului de
proiect, va analiza sptmnal evoluia proiectului, va participa la edinele comitetului
de supraveghere.
Informaticescu director Departament de informatic, va participa la ntlnirile comitetului
de supraveghere.
Vnzrescu director Departament Marketing-vnzri, beneficiarul principal al sistemului,
aprob bugetul i planurile proiectului, preedinte al comitetului de supraveghere.
Catalogescu ef Birou Cataloage, membru al comitetului de supraveghere, va oferi resurse
i sprijin utilizatorilor sistemului.
Liniescu ef linii producie membru al comitetului de supraveghere.
Livrrescu ef depozite/livrri, ofer sprijin i resurse utilizatorilor sistemului.

Aa cum s-a vzut, obiectivul principal al sistemului este de a sprijini scopul firmei n
construirea loialitii clienilor i oferirea tuturor instrumentelor necesare pentru gestiunea
relaiilor cu ei. Sistemul va veni n ntmpinarea acestui obiectiv prin sprijinirea tuturor tipurilor
de servicii oferite clienilor comenzi, returnri, cataloage on-line pentru vnzarea prin telefon
i Internet. Clienii nu trebuie s aib doar acces la catalogul on-line, prin Internet, sau la cel
tradiional, prin intermediul agenilor de vnzri, ci s aib i posibilitatea de a-i vizualiza
istoricul cumprturilor, soldul contului, facilitile obinute pentru diferitele achiziii etc.
Fig. C4.3 Prezentarea principalelor aspecte ale noului proiect
Planificarea proiectului este un proces diferit de planificarea general a sistemului

informaional i va cuprinde o evaluare a cerinelor informaionale ale sistemului supus
dezvoltrii la nivelul ntregii organizaii.
Planificarea proiectului este procesul prin care are loc definirea clar a activitilor i a
eforturilor necesare nfptuirii lor n cadrul fiecrui proiect.
Activitile incluse n planificarea proiectului sunt, n cea mai mare parte, specifice
managementului proiectelor. Planificarea proiectului este realizat de 2-3 persoane ce au o
vast experien n dezvoltarea de sisteme, cu puternice competene analitice, de gestiune i
control al proiectelor. Cei care particip la planificarea proiectului devin persoane cheie pe
parcursul dezvoltrii sistemului, asigurnd coordonarea eforturilor celorlali membri ai echipei.
Cteva dintre cele mai importante activiti ale planificrii proiectului cuprind:
1. Descrierea problemei, a ariei de ntindere, a variantelor de lucru i a fezabilitii
proiectului
Scopul activitii este de a scoate n relief coninutul i complexitatea proiectului.
Realizarea ei solicit operaii de investigare n vederea culegerii de informaii suplimentare
pentru definirea problemei i ariei de ntindere a proiectului, restriciile de realizare a
proiectului i, eventual, identificarea cerinelor funcionale i nefuncionale ale sistemului,
identificarea uneia sau a mai multor soluii generale.
Definirea problemei este una din cele mai importante activiti ale proiectului, avnd ca
scop identificarea clar a problemelor economice ce urmeaz a fi rezolvate, deci a scopului
noului sistem. Dac aceast int nu este definit corect, toate celelalte activiti vor avea
obiective de atins greit formulate.
n cadrul activitii trebuie gsite rspunsuri la urmtoarele ntrebri:
Ce problem se rezolv sau ce oportunitate se ofer prin proiect?
Ce rezultate cuantificabile i comparabile cu nivelul pieei vor fi obinute?
Ce necesiti vor fi rezolvate?
La ce standarde de calitate va fi realizat proiectul?
Care sunt costurile aproximative ale proiectului?
Care este situaia resurselor necesare realizrii proiectului?
Cum va fi evaluat succesul?
n cam ct timp este ncheiat proiectul?
Un prim pas n cadrul acestei activiti l constituie revizuirea nevoilor firmei din planul
iniial de dezvoltare a sistemelor informaionale. Dac proiectul a fost iniiat ca parte a planului
strategic, atunci sunt reanalizate documentaiile care au stat la baza iniierii lui. Dac proiectul
a fost propus plecnd de la cerinele departamentelor, vor fi consultai utilizatorii cheie, astfel
nct membrii echipei de proiect s neleag ct mai bine problemele economice.
Din momentul identificrii nevoilor, se va dezvolta o list detaliat a beneficiilor
ateptate, adic a avantajelor economice, descrise n sensul influenei asupra situaiei
financiare (reducerea costurilor sau creterea veniturilor).
Apoi se trece la identificarea principalelor caracteristici ale noului sistem, respectiv

definirea problemei din perspectiva cerinelor sistemului informaional, prin care se poate
rezolva problema identificat.
Membrii echipei vor combina cele trei componente descrierea problemei, beneficiile
economice i caracteristicile sistemului pentru a documenta scopul sistemului, mpreun cu
utilizatorii i beneficiarii lui. n unele situaii, documentul este integrat cu o schem a
proiectului, alteori este indepedent.
n caseta 4.3 este prezentat un exemplu al unui astfel de document.
Caseta 4.3 Document pentru evidenierea scopului sistemului la firma ABC
Descrierea problemei
Vnzrile prin intermediul cataloagelor de produse a fost la nceput un mic experiment, care s-a
dezvoltat foarte rapid, reflectndu-se n creterea volumului activitii departamentului responsabil cu
preluarea comenzilor i a celui cu elaborarea cataloagelor. Mai nti au fost realizate cu ajutorul
procedurilor manuale sau cu unele programe dezvoltate de angajai pentru a asigura preluarea i
onorarea comenzilor.
Din 2002, creterea vnzrilor prin intermediul cataloagelor, inclusiv a solicitrilor pe Internet, a
ridicat mari probleme actualului sistem. Pe baza planului strategic, firma s-a decis s iniieze dou
proiecte importante: unul pentru gestiunea lanului de aprovizionare, demarat n 2004 i aflat n lucru,
conform planificrilor; iar al doilea, cel de gestiune a clienilor, prin care se va asigura evidena
vnzrilor, promovarea i o gam larg de activiti de gestiune a clienilor. Acest ultim proiect face
parte integrant din planul strategic prin care firma ncearc s-i menin poziia de lider pe pia.
Avantajele economice anticipate
Alturi de pstrarea poziiei de lider, firma mai urmrete:
reducerea erorilor cauzate de prelucrarea manual a comenzilor;
onorarea rapid a comenzilor, ca urmare a prelurii i prelucrrii lor ntr-un timp mult mai
scurt;
meninerea sau reducerea personalului angajat pentru prelucrarea comenzilor primite prin
pot sau telefon;
creterea vnzrilor pe Internet, prin dezvoltarea unui site Web interactiv;
creterea cifrei de afaceri din vnzarea celor mai cutate produse;
creterea gradului de loialitate a clienilor, prin informaii i asisten continu;
diminuarea timpului necesar derulrii unei tranzacii, avantajos ndeosebi pentru firm, dar i
pentru client.
Caracteristicile sistemului
s asigure asisten clienilor on-line, prin prelucrarea rapid a informaiilor privind comenzile,
produsele existente, returnrile de produse etc.;
sprijinirea prelurii comenzilor telefonice i prin pot cu ajutorul unor ecrane cu interfa
grafic, pentru prelucrarea rapid i eficient a acestora;
ncorporarea posibilitilor de prelucrare a informaiilor provenite de la clieni prin Internet i
prin cataloagele de produse, inclusiv urmrirea comportamentului clientului i a comenzilor
care au fost onorate pn acum;
meninerea informaiilor istorice i a unei baze de date adecvate care s permit efectuarea
analizelor de pia;
oferirea unui istoric al tranzaciilor efectuate de clieni, la solicitarea acestora i a conducerii
firmei;
capacitatea de a vehicula un volum mai mare de date (n cretere cu peste 300%), fr a suferi
calitatea datelor prelucrate;
asigurarea livrrii comenzilor n 24 de ore de la acceptarea lor;
coordonarea livrrii comenzilor din mai multe depozite, indiferent de locul de unde vine
comanda;
asigurarea derulrii vnzrilor n sistemul 24/7 (24 de ore din 24, 7 zile din 7), adic non-stop.
Dup stabilirea scopului sistemului, echipa de planificare urmrete s identifice care sunt
graniele sistemului ce urmeaz a fi dezvoltat, adic definirea ariei de ntindere, prin care se
stabilesc legturile cu celelalte sisteme ale firmei sau compartimente, pentru a determina
gradul de complexitate, dar i nivelul de integrare cu sistemele existente sau cele care urmeaz
a se dezvolta. Definirea ariei de ntindere are ca punct de plecare matricele realizate n timpul
descrierii situaiei curente, apelndu-se, de cele mai multe ori, la realizarea unei diagrame,
numit diagrama de context, cu ajutorul creia sunt evideniai principalii utilizatori ai
sistemului i informaiile care sunt schimbate ntre ei i sistem. Pentru c este momentul n
care echipa definete doar scopul sistemului, diagrama va evidenia numai principalele legturi
i nevoi informaionale ale altor sisteme sau utilizatori, fr a intra n detalii, concentrndu-se
mai mult asupra informaiilor de ieire pe care trebuie s le ofere. Despre modelarea sistemului
cu ajutorul unor astfel de diagrame ale fluxurilor de date se va discuta detaliat ntr-un capitol
viitor, acum fiind prezentat doar o diagram de context simplificat pentru sistemul de
gestiune a clienilor (fig. 4.9).
Departament
Departament Vanzari
Marketing
Informatii-clienti-
potentiali
Rapoarte- Rapoarte-de-
privind- performanta
vanzarile
Rapoarte-privind-
onorarea-comenzilor
Comanda-noua
Notificare-produse- Rapoarte-privind- Conducere
returnate 0 vanzarile
Notificare-modificare-
Client date-identificare Sistem de
asistenta a
clientilor Raport-de-activitate
Notificare-
acceptare-comanda
Factura
Comenzi-de-
livrat
Informatii-
privind-
incasarile
Serviciu
Banca transport
Fig. 4.9 Diagrama de context pentru definirea ariei de ntindere

a sistemului de eviden a clienilor
Cercul din mijlocul diagramei reprezint sistemul ce urmeaz a fi dezvoltat. Ptratele sunt
entitile (sistemele, compartimentele sau alte firme, persoane) care ofer sau primesc
informaii de la sistem, deci interacioneaz cu acesta. Liniile cu sgei indic principalele
intrri i ieiri n/din sistem. Obiectivul este crearea unei imagini generale asupra sistemului
propus i nu detaliile. Diagrama va fi utilizat i n timpul analizei, fiind punctul de plecare n
studierea detaliat a sistemului.
ntrebarea cheie la care trebuie s se rspund la finalizarea definirii problemei i ariei de
ntindere este: s-a neles ceea ce urmeaz s fie fcut?
Restriciile de realizare a proiectului pot fi legate de resursele financiare, umane, fizice
sau logice necesare realizrii proiectului, precum i de apariia unor factori de natur
economic, juridic sau organizatoric, prin care s fie afectat realizarea proiectului. Se poate
observa c restriciile pot fi ncadrate n dou mari categorii: interne i externe. Se rspunde la
ntrebarea: e posibil de realizat?
Restriciile interne sunt anumite limite ce pot afecta performanele sistemului ce se
datoreaz unor factori legai, n special, de alocarea resurselor umane, materiale, tehnologice,
financiare etc. Sistemul poate fi influenat de una sau mai multe restricii, cum ar fi:
departamentul de informatic nu poate s aib n schema de personal mai mult de 3

salariai angajai permanent, aceasta fiind o restricie bugetar;
achiziiile de materiale consumabile nu pot s depeasc 150 RON/lun;
nu este permis nici o aciune de extindere a sistemului imediat dup implementare;
bugetul anual pentru exploatarea sistemului nu poate depi 20 mii RON;
personalul de vnzri nu trebuie s lucreze la introducerea datelor privind comenzile
mai mult de 30 de minute zilnic;
informaiile oferite pentru sistemul de sprijinire a top-managerilor, prin intermediul
unor ecrane predefinite, vor fi actualizate zilnic sau on-line.
Restriciile externe pot fi vzute att din punct de vedere al resurselor, dar i din
perspectiva elementelor juridice sau de natur economic. De exemplu, firma nu poate s
atrag personal specializat n echipa de dezvoltare sau nu poate obine finanarea pe baz de
credite pentru acoperirea unei pri din buget. De asemenea, furnizorii s-ar putea s nu poat
asigura echipamentele i softul necesar n perioada de timp specificat pentru a se putea
implementa la timp sistemul. n plus, exist posibilitatea ca, printr-o serie de msuri juridice
sau de politic economic, luate la nivel local, naional sau internaional, anumite funcii ale
sistemului s fie restricionate sau s impun modificarea lor n timpul derulrii proiectului. De
exemplu, introducerea n sistemul legislativ a obligativitii raportrii documentelor contabile
de sintez pe Internet sau dezvoltarea unor noi sisteme de impozitare ar putea s afecteze
componentele care abordeaz aceste problematici economice, ceea ce nseamn c e necesar s
se urmreasc, nc din faza de planificare a sistemului, propunerile legislative i impactul
potenial asupra funcionalitii lui.
Toate aceste aspecte trebuie analizate i evideniate n studiile de fezabilitate economic,
juridic, tehnic, a programrii n timp etc.
Din definirea scopului sistemului i identificarea restriciilor se pot evidenia principalele
cerine funcionale i nefuncionale. Cerinele funcionale privesc funciile sistemului, adic
ceea ce va face sistemul, iar cele nefuncionale se refer la extinderea viitoare a sistemului,
securitatea i sigurana lui etc. Cerinele sistemului, aa cum sunt formulate acum, au caracter
general, urmnd a fi detaliate n cadrul fazei de analiz.
Dup stabilirea ariei de ntindere a proiectului, obiectivul ce urmeaz este identificarea i
documentarea soluiilor posibile pentru dezvoltarea sistemului, evalundu-se fiecare variant
prin studii de fezabilitate.
De exemplu, dac a fost identificat un program posibil de achiziionat, atunci o parte din
activitile din timpul analizei ar trebui s includ evaluarea programului pentru a vedea dac
rspunde cerinelor sistemului. Dac soluia dezvoltat de ctre firm pare s fie mai fezabil,
atunci vor fi planificate detaliat activitile de analiz i proiectare.
Pentru sistemul de gestiune a clienilor decizia privind modul de dezvoltare a sistemului
este redat n caseta 4.4.
Caseta 4.4 Soluie posibil pentru sistemul de gestiune a clienilor la ABC
Dup definirea problemei, un membru al echipei a fcut cteva investigaii preliminare asupra
soluiilor posibile, prin cutarea de informaii n reviste de specialitate, pe Internet i alte surse, pentru
a determina dac sistemul ar putea fi cumprat i instalat ct mai repede posibil. Dei au fost gsite
cteva soluii, se pare c nici una nu asigur, n totalitate, caracteristicile sistemului. Ca umare, dup
mai multe discuii la nivelul echipei, s-a decis c cea mai bun variant este de a desfura etapa de
analiz nainte de a lua o hotrre final n privina soluiei de adoptat, urmnd s se revad, mult mai
detaliat, posibilitile existente dup finalizarea analizei.
2. Descompunerea proiectului n activiti uor executabile i controlabile

De regul, proiectele mari se descompun n subproiecte, iar acestea pot fi descompuse pe
repere/jaloane (realizri/rezultate pariale ale acestuia). Jaloanele se descompun pe activiti
.a.m.d. n cele ce urmeaz, pentru simplificare, am renunat la aceast form de

descompunere.
Operaiunea este foarte important i const n descompunerea proiectului n activiti
fireti ce urmeaz a fi prezentate ntr-o secven logic. Unele activiti pot fi efectuate paralel,
n timp ce altele se realizeaz secvenial. Activitile pot fi descompuse n continuare n
subactiviti (nu trebuie s fie prea detaliate deoarece ngreuneaz urmrirea lor). De exemplu,
nu se recomand subactiviti executabile n mai puin de o or.
Cnd se definesc activitile i subactivitile, se recomand s se in cont de faptul c
ele trebuie:
s fie executate de ctre o persoan sau de un grup bine definit;
s aib o singur i identificabil form de concretizare;
s dispun de o metod sau tehnic cunoscut;
s fie precedate, eventual urmate de pai bine controlai;
s fie msurabile, astfel nct s poat fi determinate procentele de realizare a acestora.
n timpul planificrii proiectului, este aproape imposibil s se stabileasc toate
activitile/subactivitile ntregului proiect, pentru c este prea devreme pentru a le ti pe cele
cu adevrat necesare. Totui, unul din obiectivele fazei de planificare a proiectului este de a
estima timpul necesar pentru finalizarea lui, precum i costul total pe care l presupune.
Descompunerea pe activiti a proiectului este esenial pentru planificarea i execuia lui,
pentru c reprezint baza stabilirii planului calendaristic, identificrii rezultatelor/jaloanelor i
gestiunii costurilor.
3. Estimarea resurselor i crearea unui plan al resurselor
Obiectivele activitii sunt:
estimarea necesarului de resurse pentru fiecare activitate din proiect;
folosirea informaiilor anterioare pentru crearea unui plan al resurselor proiectului, cea
mai important resurs fiind fora de munc. Echipa de realizare a proiectului poate fi
format din angajai ai firmei, specialiti din afara firmei (din cadrul unor firme
specializate n analiza i proiectarea de sisteme informatice) sau din reprezentani ai
ambelor pri. Fiecare variant are propriile avantaje i dezavantaje, ultima variant
fiind cea mai des ntlnit n practic (mai rar la noi). Din echipa de realizare a
proiectului trebuie s fac parte efii compartimentelor funcionale implicate n
dezvoltarea noului sistem, specialiti care cunosc activitile specifice sistemului ce
urmeaz a fi dezvoltat (din rndul utilizatorilor) i specialiti din domeniul informatic
(analiti de sisteme, proiectani, programatori etc.). n prima faz, echipa poate fi
format doar din personalul necesar fazei de analiz i completat ulterior n funcie de
rezultate;
estimarea timpului necesar derulrii proiectului prin corelarea activitilor cu resursele
umane necesare. Se recomand atribuirea unui singur tip de sarcini sau a unui numr
redus al acestora pentru fiecare persoan care lucreaz n cadrul proiectului. Dac
munca devine plictisitoare, se poate extinde paleta sarcinilor (exemplu: nu numai
programator de ecrane sau rapoarte). Atenie! Nu trebuie redus eficiena muncii. Se
recomand un echilibru ntre specializarea i diversificarea activitilor prestate de o
persoan.
4. Realizarea unei prime planificri calendaristice
Obiectivul l constituie folosirea informaiilor despre activitile i resursele disponibile,
pentru a se atribui timpul necesar fiecrui membru al echipei, printr-o structur a diviziunii
muncii. Atribuirile respective permit crearea punctelor de nceput i de sfrit ale proiectului.
Prin planificarea calendaristic se asigur o mai uoar monitorizare i un control mai riguros
asupra derulrii activitilor. Pentru realizarea documentaiei planificrii se apeleaz la mai
multe tehnici, dintre care cele mai folosite sunt diagramele Gantt i PERT, pentru c
modificrile termenelor, activitilor .a. pot fi uor efectuate i corelate imediat cu celelalte, n
condiiile folosirii softului specializat (de exemplu, Microsoft Project).
5. Definitivarea planului de baz al proiectului
Planul de baz reflect cel mai bine activitile prestate n cadrul proiectului, precum i
resursele solicitate. El va fi folosit ca pies de baz n etapa urmtoare a proiectului, execuia,
n timpul creia proiectul poate fi schimbat, n sensul actualizrii lui. Planul de baz conine
toate documentele obinute n urma derulrii activitilor specifice etapei de planificare a
proiectului.
4.4 Analizele de fezabilitate

Elaborarea unui sistem complex poate costa milioane de dolari i se poate realiza pe
parcursul a trei pn la ase ani pentru a fi complet. Din aceste motive, este normal ca factorii
de conducere s demareze proiectarea unui nou sistem dup ce se efectueaz studii de
fezabilitate.
Un studiu de fezabilitate are rolul de a asigura informaiile obiective necesare pentru a
cunoate dac un proiect poate fi demarat sau nu, sau dac un proiect deja nceput mai poate fi
continuat. Proporiile i durata studiilor de fezabilitate variaz, n funcie de mrimea i natura
sistemului de implementat. n cazul sistemelor bazate pe calculatoare mari, studiul are cu totul
alte dimensiuni fa de varianta utilizrii microcalculatoarelor.
Echipele de studiu trebuie s includ att persoane cu nalte cunotine tehnice, ct i
persoane cu bogate cunotine i experien n activitile firmei studiate. Dac ea nu dispune
de personalul adecvat pentru partea tehnic a studiului, atunci va putea angaja din afar astfel
de specialiti. De asemenea, echipele trebuie s aib n structur att reprezentani ai
conducerii, ct i ai echipelor de control sau audit intern. Nu n ultimul rnd, trebuie ca din
echip s fac parte reprezentanii utilizatorilor.
Totui, fezabilitatea proiectului poate fi studiat n orice faz a elaborrii lui, dar studiile,
de regul, se efectueaz n momente certe. Cnd este propus un proiect, se efectueaz un studiu
preliminar de fezabilitate pentru a se stabili dac proiectul atinge obiectivele propuse de
unitate. Studiul, n prima lui faz, poate fi orict de subiectiv, ntruct proiectul nu este
prezentat cu lux de amnunte. ns, ndat ce se obine o situaie mai clar despre sistem,
despre natura problemei de rezolvat, precum i despre doleanele utilizatorilor, msurarea
preliminar a fezabilitii poate fi determinat odat cu faza de analiz a sistemului. Cnd
proiectanii ofer dou sau trei variante de elaborare a sistemului, numai studiile de fezabilitate
o pot scoate n relief pe cea optim.
Dup ce a avut loc proiectarea conceptual a sistemului, pot fi determinate n detaliu
elementele de cost al proiectrii, implementrii i exploatrii. Este ultima ans a organizaiilor
de a mai putea renuna la sistem, naintea implementrii lui.
Pe parcurs, odat cu progresul nregistrat n dezvoltarea sistemului, se obin informaii din
ce n ce mai certe, oferindu-se posibilitatea unor analize de fezabilitate mult mai concludente,
ceea ce atrage studierea fezabilitii n diverse faze ale ciclului de via al sistemelor. De
fiecare dat, studiile de fezabilitate trebuie s aib la baz o foarte bun documentaie. Aceasta
va conine:
definirea problemei (o scurt descriere a proiectului i explicarea a ceea ce-i propune
el s realizeze);
descrierea cerinelor sistemului;
descrierea soluiilor sistemului propus;
explicaia critic a motivrii studiului ntreprins;
cuantificarea tuturor costurilor materiale i beneficiilor aferente;
o list a costurilor i beneficiilor necuantificabile.
Se contureaz cteva dimensiuni ale fezabilitii, care trebuie evaluate prin studiul de
fezabilitate ntreprins, incluznd fezabilitatea tehnic, economic, de exploatare (operaional),
a legalitii i a programrii n timp.
Fezabilitatea tehnic. Problema fundamental este: poate fi elaborat i implementat
sistemul planificat n organizaia respectiv folosind tehnologia existent? Aceasta deoarece
progresele tehnologice sunt mai rapide dect posibilitile unitilor de a le implementa. i nc
o ntrebare: ofer unitatea condiii persoanelor care vor proiecta, implementa i exploata
sistemul propus?
Fezabilitatea economic. Dou probleme de baz apar n acest caz. Prima: justific
sistemul propus timpul, banii, alte resurse i costurile necesare pentru a fi implementat? A
doua: are unitatea fondurile necesare pentru elaborarea i implementarea sistemului, date fiind
cerinele de capital i pentru alte proiecte existente? Pentru a rspunde acestor ntrebri,
trebuie s fie estimate i analizate diverse costuri i beneficii asociate fiecrei variante.
Fezabilitatea economic necesit un tratament, ulterior, complet.
Fezabilitatea organizaional sau a exploatrii pornete de la o prim ntrebare, i
anume: este posibil ca noul sistem s fie utilizat de ctre persoanele crora le este adresat?
Rspunsul poate fi dat numai n condiiile din ntreprindere, de ceea ce se ntmpl cu
persoanele din sistem nainte de implementarea celui nou, n sensul participrii efective,
motivate, la realizarea lui, precum i dorina lor de transformare. Se are n vedere reacia
angajailor firmei sau anumite modificri de natur organizatoric posibile sau propuse. Dac
proiectul are susinerea conducerii i a utilizatorilor, noul sistem are toate condiiile s fie
implementat i exploatat cu succes. Oricum, schimbarea implic i o doz de risc. Dintre cele
mai frecvente riscuri care trebuie avute n vedere, enumerm:
competene sczute n utilizarea calculatoarelor;
fobie general n privina exploatrii calculatoarelor;
percepia pierderii controlului de ctre salariai sau conducere asupra activitilor
desfurate;
poteniala schimbare a puterii politice i organizaionale datorit noului sistem;
teama de modificare a responsabilitilor ce revin fiecrui loc de munc;
teama de pierdere a locului de munc datorit automatizrii;
obinuina cu anumite proceduri de lucru.
Este destul de dificil de identificat toate riscurile organizaionale care ar putea s apar la
nivelul firmei, dar echipa de gestiune a proiectului trebuie s fie foarte atent pentru a le
identifica din timp i a le elimina sau atenua efectele dac ele i-au fcut deja apariia.
Fezabilitatea legalitii urmrete s determine dac se pot nregistra conflicte ntre
sistemul propus i anumite obligaii legale. De asemenea, sistemul trebuie s respecte toate
statutele, deciziile, regulamentele, legile i alte acte normative i juridice, att la nivel local, ct
i naional i internaional. Pentru aceasta, se analizeaz scopul sistemului i se identific
principalele reglementri ale domeniului economic abordat prin sistem.
Fezabilitatea programrii rspunde, n primul rnd, la urmtoarea ntrebare: poate fi
proiectat i implementat sistemul n timpul alocat? Dac rspunsul este nu, sistemul trebuie s
fie modificat sau va fi luat n studiu o alt variant, sau data implementrii va fi schimbat.
Din nefericire, nici tehnologiile moderne nu aduc o reducere substanial a timpului de
proiectare i implementare, motivul fiind posibilitile de adaptare a personalului la nou.
Rezumat
Dezvoltarea sistemelor este iniiat atunci cnd noul sistem este parte a planului strategic al firmei,
ce vine n sprijinul atingerii obiectivelor generale ale firmei, sau ca rspuns la o nevoie imediat, legat
de o problem de prelucrare, de obinerea unor beneficii din exploatarea unor oportuniti aprute n
mediul firmei etc.
Identificarea i selecia proiectelor de dezvoltare a sistemelor informaionale reprezint prima etap

din ciclul de via al dezvoltrii sistemelor care, mpreun cu iniierea i planificarea proiectelor,
constituie microanaliza, component preluat din managementul proiectelor.
Proiectul este, de cele mai multe ori, iniiat prin cererea unui utilizator pentru un anumit serviciu,
recunoaterea de ctre utilizator a unei probleme sau ca o propunere din domeniul prelucrrii datelor, ca
rspuns la o analiz ce nu a abordat fie o problem, fie posibilitatea de a automatiza o anumit funcie.
Urmeaz clasificarea proiectelor, care are ca scop scoaterea n eviden a importanei propunerii. De
regul, aceasta este sugerat de cei ce fac propunerile i, n mod firesc, reflect punctele lor de vedere.
Rezultatele primei etape a ciclului de via al dezvoltrii sistemelor se concretizeaz ntr-o
planificare calendaristic a proiectelor, venite de sus-n-jos i de jos-n-sus, pentru a fi trecute n a doua
etap a ciclului de via (iniierea i planificarea proiectului).
Proiectele propuse pentru rezolvarea unor probleme trebuie s fie identificate i selectate n strns
concordan cu cadrul organizatoric existent, ceea ce presupune abordarea concomitent a planificrii
strategice a organizaiei i planificrii sistemelor informaionale. O astfel de planificare reprezint un
ansamblu ordonat de mijloace de evaluare a cerinelor informaionale ale unei organizaii i de definire a
sistemelor informaionale, a bazelor de date, precum i a tehnologiilor ce vor satisface aceste cerine.
Dup ce s-a decis asupra proiectului ce urmeaz a fi desfurat, se parcurg dou activiti
importante din faza de microanaliz, respectiv iniierea i planificarea proiectului, activiti eseniale
pentru asigurarea atingerii scopului i obiectivelor identificate prin propunerea de proiect.
Activitatea de iniiere a unui proiect este una din cele mai laborioase, pentru c este momentul n
care se definesc elementele privind echipa de iniiere a proiectului, modul de comunicare i stabilirea
bunelor relaii cu beneficiarii sistemului, se stabilesc procedurile manageriale privind modalitile de
raportare, atribuirea de sarcini, se definesc procedurile prin care se pot efectua schimbri la nivelul
proiectului etc.
Planificarea proiectului este procesul prin care are loc definirea clar a activitilor i a eforturilor
necesare nfptuirii lor n cadrul fiecrui proiect.
Odat cu planificarea proiectului, factorii de conducere trebuie s demareze o serie de studii de
fezabilitate, care au rolul de a asigura informaiile obiective necesare pentru a cunoate dac un proiect
poate fi demarat sau nu, sau dac un proiect deja nceput mai poate fi continuat. Se contureaz cteva
dimensiuni ale fezabilitii, care trebuie s fie evaluate prin studiul de fezabilitate ntreprins, incluznd
fezabilitatea tehnic, economic, de exploatare (operaional), a legalitii i a programrii n timp.
Dac n urma studiilor de fezabilitate se constat c proiectul poate fi continuat, urmeaz ca echipa
s-i orienteze eforturile ctre etapele de proiectare, implementare, documentare i ntreinere a
sistemului informaional.
1. Care sunt modalitile de identificare a unor noi proiecte de dezvoltare a sistemului?
2. Identificai, ntr-o organizaie cunoscut, potenialele persoane care sunt abilitate s propun proiecte
de dezvoltare a sistemelor informaionale, ncadrndu-le n una din categoriile descrise anterior.
3. Ce se urmrete prin realizarea matricelor din etapa planificrii strategice a sistemului?
4. Ce criterii pot fi avute n vedere la ierarhizarea i selecia proiectelor de dezvoltare?
5. Enumerai cel puin 3 propuneri de proiecte de dezvoltare a sistemelor informaionale, ce s-ar putea
regsi ntr-o organizaie cunoscut, i specificai criteriile pe care le-ai utiliza pentru evaluarea lor.
Motivai.
6. Enumerai i descriei principalele activiti desfurate n timpul iniierii proiectului.
7. Care este scopul diagramei de context n etapa de planificare a sistemului?
8. Specificai tipurile analizelor de fezabilitate ce trebuie efectuate n timpul planificrii proiectului.
9. n ce etape ale ciclului de dezvoltare al unui sistem este necesar s se reia o parte din analizele de
fezabilitate? De ce?
Probleme de echip
1. Noul sistem de gestiune a clienilor i ncasrilor de la Beta constituie un factor esenial pentru
sprijinirea dezvoltrii i ctigrii unui segment ct mai mare pe pia.
Componenta de vnzri cu amnuntul a sistemului trebuie s urmreasc fiecare vnzare i s
ofere posibilitatea stabilirii unei legturi directe cu sistemul de stocuri, pentru obinerea de informaii
privind existena produselor n stoc, costurile lor de producie, astfel nct s se poat genera zilnic
un raport privind beneficiile sau pierderile nregistrate din vnzarea diferitelor produse.
Baza de date a clienilor trebuie s permit obinerea istoricului vnzrilor pentru a ajuta
conducerea n formularea unor scrisori speciale i stabilirea unor aciuni promoionale personalizate
pentru fiecare client.
Pentru rezolvarea problemei privind soldul foarte mare al contului de clieni, sistemul trebuie s
permit obinerea unor fie de cont analitice, pe baza lor putnd s se transmit conducerii rapoarte
detaliate privind istoricul creditului fiecrui client.
Se cere identificarea principalelor funcii care ar trebui s fie incluse n noul sistem de gestiune a
clienilor i ncasrilor.
2. Concepei un document pentru descrierea propunerii noului sistem informaional de gestiune a
clienilor, plecnd de la aspectele identificate la problema 1.
3. Plecnd de la studierea misiunii, obiectivelor i strategiilor, a sistemelor informaionale i structurii
organizatorice a unei firme, construii principalele matrice din care ar putea fi identificate eventualele
proiecte de dezvoltare a sistemelor i stabilii un plan strategic al sistemelor informaionale.
CAPITOLUL V
Studierea sistemului existent

i determinarea cerinelor noului sistem
Obiective:
Cunoaterea caracteristicilor proiectelor de dezvoltare a sistemelor informaionale
Descrierea componentelor sistemului existent (ieiri, intrri, stocarea datelor, procese de
prelucrare), pentru identificarea punctelor tari i slabe din sistem
nelegerea evenimentelor la care sistemul trebuie s reacioneze prin funciile de prelucrare,
precum i a modalitii de identificare a lor
Prezentarea principalelor activiti ce se realizeaz n timpul determinrii cerinelor
Cunoaterea principalelor surse de identificare a cerinelor sistemului,
a persoanelor afectate, direct sau indirect, de implementarea noului sistem
Identificarea principalelor categorii de cerine ale noului sistem
Dobndirea de cunotine privind modul de ntocmire a specificaiei de analiz,
a criteriilor calitative pe care trebuie s le ndeplineasc
Capitolul de fa se concentreaz asupra activitilor specifice etapei de analiz, n care

este studiat sistemul existent i se identific cerinele noului sistem informaional.
n timpul cercetrii i stabilirii cerinelor, se vor obine detaliile privind procesele i
activitile desfurate la nivelul sistemului curent, pe msura intervievrii, observrii
utilizatorilor sau analizei documentelor i procedurilor de lucru existente. n acest mod, se
ncearc obinerea unei imagini ct mai clare i obiective asupra problemelor crora trebuie s
le rspund noul sistem.
n etapa de anaiz se realizeaz legtura cea mai strns cu utilizatorii i se ctig
ncrederea lor, pentru c se fac o serie de recomandri i sugestii asupra modului n care se vor
satisface cerinele lor informaionale. i asta pentru c, n timpul analizei, se merge unde
trebuie i se discut ce trebuie1 cu utilizatorii care particip la desfurarea operaiunilor
economice, ceea ce face mult mai facil acceptarea schimbrii sistemului. Altfel, e posibil ca
echipa de analiz s fie vzut ca un intrus, care nu nelege problemele cu care se confrunt
cei care exploateaz sistemul.
Aproape toate metodologiile de dezvoltare a sistemelor specific i descriu activiti
similare pentru etapa de analiz, diferenele rezultnd, de cele mai multe ori, din tehnicile
recomandate pentru desfurarea lor sau din denumirea dat. ns, toate ar trebui s conduc la
atingerea acelorai obiective: nelegerea deplin a modului de funcionare a sistemului
existent, determinarea cerinelor informaionale i modelarea noului sistem. Faza de analiz
presupune definirea mult mai detaliat a ceea ce trebuie s fac sistemul informaional, pentru
a genera beneficiile economice i avantajele tehnologice specificate n timpul etapei de
planificare a proiectului, oferindu-se mai multe soluii, din care cea mai bun va fi supus
proiectrii.
Activitile specifice analizei sunt complementare i, de obicei, se pot desfura simultan.
De exemplu, analistul culege informaii despre sistemul existent, definind n acelai timp
cerinele informaionale pentru cel nou, pe tot parcursul etapei i nu numai la nceputul ei.
Principalele ntrebri la care trebuie s se gseasc rspunsul n timpul etapei de analiz sunt:
Course Technology, Thomson Learning, Boston, 2002, p. 108.
ce se realizeaz n sistemul existent i care sunt intrrile, ieirile i procesele de

prelucrare specifice?
care sunt punctele tari, de pstrat n noul sistem, respectiv punctele slabe, care trebuie
nlocuite sau transformate n puncte tari?
care sunt cerinele noului sistem?
ce variante pot fi luate n considerare pentru dezvoltarea noului sistem, pentru a
rspunde ct mai bine cerinelor identificate?
ar trebui continuat proiectarea i implementarea noului sistem?
Principalele activiti desfurate n timpul etapei de analiz sunt:
1. Studierea sistemului existent, care presupune, n primul rnd, identificarea punctelor tari
i slabe ale sistemului, respectiv a acelor elemente care au generat apariia problemelor, pe
baza unor analize orientate spre principalele componente ale sistemului informaional.
2. Determinarea cerinelor informaionale ale noului sistem. Activitatea implic
identificarea persoanelor care au nevoie de informaii, momentele i forma n care acestea
sunt solicitate. Analitii trebuie s lucreze ndeaproape cu utilizatorii. Cerinele
informaionale se refer la:
tipul, formatul, coninutul, volumul i frecvena fiecrei intrri/ieiri, timpul de rspuns;
procesele de prelucrare necesare transformrii intrrilor n ieiri;
corectitudinea, exactitatea i securitatea intrrilor, stocrii, prelucrrilor i ieirilor
sistemului.
Pentru aceste dou prime activiti, analitii de sistem au la dispoziie o serie de tehnici
sau metode, grupate n dou mari categorii, respectiv:
a. metodele tradiionale de culegere a informaiilor
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 informaiile pentru exercitarea sarcinilor de serviciu;
studierea documentaiei firmei pentru a se cunoate coninutul rapoartelor, al politicilor,
regulamentelor, precum i direciile spre care se ndreapt prelucrarea datelor.
b. metode moderne de determinare a cerinelor sistemului: JAD (Joint Application
Design), RAD (Rapid Application Development), prototipizarea.
3. Structurarea sau modelarea cerinelor sistemului urmrete crearea unor imagini ale
sistemului, prin intermediul unor modele, dup cum urmeaz:
modelul descompunerii funcionale are ca scop evidenierea principalelor funcii,
procese, subprocese, proceduri de prelucrare a datelor etc. din cadrul sistemului. De
fapt, modelul prezint, sub form de diagram, structura ierarhic a prelucrrilor din
sistemul analizat;
modelul proceselor, prin care se reprezint principalele procese de prelucrare i
legturile 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 fiecrui flux de date, procesele de prelucrare
la care sunt supuse, precum i destinaia fluxurilor de informaii obinute n urma
prelucrrilor. Sursa i destinaia pot fi alte sisteme/aplicaii, persoane, componente
organizatorice, parteneri de afaceri, dac sunt fluxuri externe, respectiv locuri de
stocare/pstrare a datelor (fiiere, baze de date, dosare etc.), dac fluxurile sunt
interne sistemului;
modelul logicii proceselor presupune descrierea acestora astfel nct s poat fi
convertite n programe, prin intermediul limbajelor de programare, dar nu se va
STUDIEREA SISTEMULUI EXISTENT I DETERMINAREA CERINELOR 81
respecta structura sau sintaxa unui anumit limbaj (aceasta se va realiza ntr-o etap
ulterioar, proiectarea);
modelul datelor, realizat prin intermediul diagramelor entitate-relaie, reliefeaz
obiectele sau lucrurile din lumea real, sub forma entitilor de date, despre care
trebuie pstrate date n cadrul sistemului, o lung perioad de timp. Entitile 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 activitilor anterioare i va
conine: lista problemelor i restriciile existente n sistemul curent; cerinele noului
sistem; rezultatele modelrii conceptuale; recomandri privind proiectarea noului sistem.
5. Analiza recomandrilor mpreun cu reprezentanii conducerii, care trebuie informai
cu privire la evoluia proiectului, urmrindu-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 informaionale

Din perspectiva analizei, activitile 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 analitii 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 modificrilor: modificri minore ale sistemului;
mbuntirea i ntreinerea sistemului; reproiectarea i redezvoltarea sistemelor.
Diferenele privind analiza, n contextul categoriilor de proiecte prezentate anterior, rezid
n: elementele supuse analizei, responsabilitile analitilor, rezultatele analizei, factorii care
determin dezvoltarea noului sistem. n tabelul 5.1 sunt prezentate, n sintez, aceste
caracteristici pentru fiecare dintre proiectele menionate.
5.2 Studierea sistemului existent

Studierea sistemului este una din cele mai importante activiti din ciclul de via al
dezvoltrii, iar n primii ani ai informatizrii sistemelor nu exista nici o limit n desfurarea
acestei activiti. n timp, att specialitii, ct 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 fore proprii (dar nu numai), au generat numeroase
probleme, mai ales n timpul etapei de ntreinere, datorit inexistenei unei documentaii
complete privind caracteristicile i funciile sistemului, genernd costuri semnificative pentru
refacerea activitii 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 ct mai nalt de integrare i compatibilitate.
Ca urmare, unii specialiti au ajuns la concluzia c trebuie s se gseasc un echilibru
ntre eforturile i timpul necesar pentru studierea sistemului existent i cele de determinare a
cerinelor noului sistem, pentru c reprezint principala cale de identificare a nevoilor
informaionale.
2. Modell, M. A Professionals 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 Diferene privind analiza
proiectului Elementele supuse analizei Responsabiliti Rezultatele analizei Factori declanatori
Modificare - Prelucrrile manuale - Simplificarea fluxului - Standarde/proceduri noi - ntrzieri n prelucrri
sistem manual - Fluxurile i etapele prelucrrilor informaional - Reguli de performan - Noi forme de raportare
- Rezultatele prelucrrilor - Reducerea redundanelor - Noi formulare, proceduri de - Flux greoi al documentelor
- Reordonarea prelucrrilor control, rapoarte - O nou form
- Coninutul formularelor - Noi prelucrri sau fluxuri organizaional
Informatizare - Modalitile de nlocuire a - Impactul componentelor - Noi formulare de introducere a - Costurile mari ale prelucrrii
sistem/ prelucrrilor manuale manuale asupra celor datelor manuale
componente - Procesele i procedurile manuale automate - Stabilirea coninutului - Erori n prelucrarea datelor
- Interaciunea dintre fiierelor - Creterea duratei de obinere
despre funciile ndeplinite de acesta.

componentele informatizate - Fluxul prelucrrilor, mixaj de a rapoartelor
- Fezabilitatea nlocuirii procese noi i manuale
procedurilor manuale - Noi procese de prelucrare
- Costurile informatizrii
Modificri - Mediul economic - Optimizarea prelucrrilor - Modificarea structurii -mbuntirea prelucrrilor
minore ale - Funciile i procedurile de - Trecerea programelor ntr-un fiierelor, rapoartelor
sistemului prelucrare nou limbaj - Eliminarea eventualelor erori,
concentreaz atenia asupra altor aspecte, i anume:

a codurilor neutilizate
mbuntire/ - Domeniile de lucru ale - Adugri de noi funcionaliti - Reproiectarea logicii - Modificri n mediul
ntreinere utilizatorilor - Identificare interdependene cu aplicaiilor economic
- Legturile cu alte sisteme alte aplicaii ce folosesc - Modificarea structurii bazei de - Solicitri ale utilizatorilor
- Structura programelor aceeai baz de date date; pentru noi funcionaliti
ANALIZA SISTEMELOR INFORMAIONALE
- Solicitri 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 redezvoltrii organizaional
fiind nevoii s apeleze att la discuii cu utilizatorii i la observarea modului n care acetia i
condiiile n care sistemul curent este nlocuit n totalitate, analitii au nevoie de informaii
Dei este o activitate distinct n cadrul analizei, studierea sistemului existent este foarte
Mai mult, sunt destul de rare cazurile cnd specialitii n dezvoltarea sistemelor pot crea
rapoarte i ecrane, diagrame ale fluxurilor de date, diagrame entitate-relaie etc. Aadar, i n
desfoar activitatea, ct i la analiza documentaiei sistemului existent, care poate include
asemntoare, ca tehnic de lucru, cu determinarea cerinelor noului sistem, ns specialitii i

imaginea noului sistem doar pe baza cunotinelor sau experienelor pe care le dein, de obicei,
nelegerea activitilor, obiectivelor i procedurilor existente n sistem i firm;

cunoaterea fluxurilor de date i informaii, pentru a obine perspectiva modului n care sunt
realizate funciile 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 cnd:
se trece de la un sistem manual la unul informatizat;
nu exist nici un fel de documentaie a sistemului existent supus redezvoltrii;
exist destul de multe incertitudini asupra modului n care funcioneaz sistemul.
Studierea sistemului curent presupune culegerea unui volum considerabil de informaii de
la persoanele care utilizeaz i vor utiliza sistemul, prin analiza documentelor i a
regulamentelor firmei, a documentaiei sistemului (dac exist) sau prin observarea a ce fac
alte firme care s-au confruntat cu aceleai nevoi. Pe scurt, analitii trebuie s discute cu toi cei
care utilizeaz sisteme similare i trebuie s citeasc orice este disponibil despre sistemul
existent. Ei trebuie s devin experi n domeniul economic pentru care sistemul se dezvolt.
De exemplu, dac se urmrete implementarea unui sistem de prelucrare a comenzilor primite
de la clieni, este necesar s se cunoasc absolut toate activitile pe care le presupun preluarea
i onorarea comenzilor. Dac se urmrete 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 dobnzilor, a
comisioanelor i penalitilor etc.
n acelai timp, analitii, pe lng informaiile despre domeniul economic al sistemului,
trebuie s culeag i informaii tehnice care au legtur cu acesta, n sensul identificrii
locurilor n care utilizatorii i vor desfura activitile, interfeele sistemului cu alte sisteme,
echipamentele i softul folosite.
Principalele elemente supuse analizei n timpul studierii sistemului existent sunt:
informaiile de ieire obinute 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 pstrate datele;
procesele de prelucrare la care sunt supuse datele, ordinea prelucrrilor i dependena
dintre datele trecute prin diverse procese. De asemenea, se au n vedere evenimentele
marcante i momentele declanrii lor, prin care se schimb valoarea datelor.
n continuare, vom prezenta pe rnd aceste elemente.
5.2.1 Analiza informaiilor de ieire

Principalele informaii care se obin n cadrul unui sistem apar sub forma listelor,
situaiilor de ieire, documentelor, ecranelor, a rspunsurilor la ntrebri, 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, fr a se confunda cu terminologia contabil a unui
document primar. Sunt multe situaii cnd un document contabil reprezint o ieire a unui
sistem i nu neaprat o intrare. De exemplu, factura emis unui client reprezint rezultatul unui
proces de prelucrare al sistemului vnzri (citirea informaiilor despre produsele facturate,
citirea informaiilor despre clientul cruia se emite, calcularea valorii produselor, a TVA,
calcularea totalului facturii, determinarea discount-ului etc.). Ca urmare, este o ieire din
proces i nu o intrare, aa cum s-ar crede la prima vedere, dac ne bazm doar pe folosirea
noiunii de document. Pe de alt parte, factura emis poate reprezinta un document de intrare,
dar pentru alt sistem, de exemplu sistemul de ncasri i pli, pe baza cruia se vor actualiza i
urmri ncasrile de la clieni.
Dintre obiectivele prezentrii detaliate a ieirilor sistemului existent pot fi enumerate:
1. Determinarea formatului i coninutului ieirilor
n funcie de aceste elemente, se va constata, din discuiile purtate cu utilizatorii, dac
sunt mulumii de ieirile generate de sistem sau ele trebuie modificate, fie din punct de vedere
al coninutului, fie al formei.
De exemplu, dac un raport privind comenzile primite de la clieni, ntr-o perioad de
timp, este generat n mai multe exemplare i conine informaii pe care o parte din utilizatori nu
le folosesc, este necesar regndirea coninutului raportului, fie prin eliminarea acelor
informaii, fie prin proiectarea a dou tipuri de rapoarte, unul detaliat i unul sintetic.
O alt situaie poate fi cea n care raportul se obine pe suport de hrtie, dei el este
utilizat o singur dat, dup care este arhivat, fr a se mai apela la coninutul lui. O soluie ar
fi generarea lui n format electronic, fr a mai fi tiprit.
Ca urmare, analitii trebuie s urmreasc dac toate cmpurile din coninutul raportului
sunt utile tuturor utilizatorilor, dac suportul de prezentare este cel mai eficient mod de a pune
la dispoziie informaiile 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 ieirilor
Se va analiza dac fiecare ieire are n structur urmtoarele 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 numrul raportului i data ntocmirii lui, locurile n care trebuie s fie distribuite
exemplarele;
informaiile privind instruciunile de completare, destinaiile fiecrui exemplar, evitarea
comentariilor lungi, prin rubrici sugestive;
partea principal a raportului, care trebuie s fie echilibrat, cu folosirea corect a
spaierilor i marginilor, etichetarea corect a rubricilor i gruparea lor logic, marcarea
fiecrei rubrici, accentuarea zonelor cheie prin linii sau culori;
concluziile (finalul) ieirii, care trebuie s fie plasate la sfritul raportului, s aib spaiu
suficient pentru semnturi, s prezinte regimul de lucru cu documentul respectiv, s fie
accentuate totalurile.
3. Identificarea momentului elaborrii rapoartelor
Obiectivul se refer la identificarea frecvenei cu care se obin ieirile, criteriu n funcie
de care se pot obine urmtoarele categorii de rapoarte, prezentate i n capitolul 2:
rapoarte programate (la termen);
rapoarte neprogramate, cu rol special (rapoarte ad-hoc);
rapoarte declanate de excepi;
rapoarte la cerere.
Prin acest obiectiv se dorete evaluarea eficienei generrii rapoartelor n funcie de modul
de sprijinire a procesului decizional i de control. De obicei, rapoartele generate la termen sunt
solicitate mai mult pentru respectarea obligaiilor legale, n timp ce altele sunt rspunsuri la
cererile managerilor. n aceste condiii, se poate determina ct de flexibil este sistemul la
nevoile de informare ale utilizatorilor interni i externi, indiferent de tipul raportului solicitat.
Astfel, este necesar s se identifice toi utilizatorii informaiilor i s fie ncadrate n una din
categoriile menionate pentru a vedea dac sunt satisfcute cerinele lor, dac sunt necesare i
alte tipuri de rapoarte.
4. Determinarea duratei necesare pentru generarea unei ieiri
Unul dintre elementele n funcie de care se stabilete dac procedura de prelucrare este
eficient l constituie durata necesar obinerii informaiilor, influenat de mai muli factori,
dintre care mai importani sunt:
prelucrarea se face pe loturi, ceea ce nseamn c unele rapoarte, privind activitile
desfurate ntr-o perioad mai scurt de timp dect cea n care are loc prelucrarea, nu pot
fi obinute dect dup perioada stabilit pentru culegerea i prelucrarea datelor generate de
un set de operaiuni. Acest lucru poate afecta procesul decizional prin lipsa informaiilor
actualizate. De exemplu, personalul de vnzri nu poate accepta comanda unui client n
ziua primirii ei, ci numai dup o sptmn, dac actualizarea stocului de produse se face,
pe baza facturilor emise i a bonurilor de predare a produselor finite de la seciile de
producie, doar la sfritul sptmnii;
prelucrrile se bazeaz pe un sistem de gestiune a bazelor de date ce nu mai face fa
numrului de nregistrri. Dac se solicit rspunsul la o ntrebare de genul: Care este
stocul produsului X, iar utilizatorul trebuie s atepte mai mult de 5 minute pentru
obinerea rspunsului dorit, nseamn c interogarea bazei de date se realizeaz greoi,
datorit lipsei de performan a sistemului de gestiune a bazelor de date sau a neoptimizrii
acesteia;
procedurile existente nu se desfoar n regim distribuit, astfel c la solicitarea unor
informaii aflate n mai multe locuri ale firmei este necesar s se atepte pn se
centralizeaz i sintetizeaz datele n forma dorit de utilizatori;
performana echipamentelor nu este cea mai bun pentru a sprijini obinerea rapoartelor n
formatul i la momentul dorit de utilizatori. De exemplu, unitile de prelucrare nu permit
generarea unor rapoarte de tip grafic, imprimantele nu au posibilitatea tipririi n formatul
cerut (A3, A5 etc.) sau solicit mult timp pentru imprimare (cazul imprimantelor
matriceale nc folosite de unele firme pentru tiprirea statelor de salarii sau a balanelor
de verificare, operaiune care poate dura i cteva ore).
5. Identificarea circuitului informaiilor de ieire la nivelul organizaiei
Obiectivul se poate realiza rspunznd la urmtoarele ntrebri:
cine este beneficiarul listei/situaiei, ecranului sau rspunsului la ntrebare? Se identific
locul/locurile din firm unde sunt necesare informaiile. De exemplu, situaia comenzilor
primite de la clieni poate fi solicitat de cei de la depozite, n vederea pregtirii produselor
pentru livrare, de cei de la producie, pentru a planifica producia, de marketing, pentru a
analiza tendinele pieei, de salarizare, pentru a calcula salariile agenilor de vnzri etc. n
aceast situaie, este important s se determine dac este eficient obinerea unui singur
raport, n mai multe exemplare, care s fie transmis tuturor celor interesai, sau e mai bine
s fie generate rapoarte cu coninut diferit, n funcie de nevoile fiecrui beneficiar.
cte persoane folosesc sau vd listele/situaiile, ecranele sau rspunsurile la ntrebri? Se
determin numrul exact al exemplarelor n care trebuie obinut 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 muli analiti ce urmresc aspecte diferite n cadrul aceluiai
raport: o persoan este interesat de evoluia general a comenzilor pentru un anumit
produs, o alta de tendina unui client de a se axa pe anumite produse sau anumite perioade
de cumprare etc.
unde sunt transmise listele/situaiile, ecranele sau rspunsurile la ntrebri? Unele
rapoarte, potrivit regulamentelor interne sau legislaiei n vigoare, trebuie s aib
semntura uneia sau mai multor persoane pentru asigurarea corectitudinii i validitii
informaiilor pe care le conin. De exemplu, bilanul contabil trebuie s poarte semntura
directorului economic, a unui expert contabil i a directorului firmei pentru a certifica
exactitatea datelor. Acest lucru nseamn c, pn a ajunge la destinaie (preedintele
consiliului de administraie, adunarea general a acionarilor sau asociailor, direcia
finanelor publice), bilanul 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.
cnd este solicitat obinerea ieirilor de fiecare beneficiar? Chiar dac, la un moment dat,
coninutul i forma unei ieiri sunt identice, exist situaii cnd fiecare beneficiar solicit
rapoartele la perioade diferite de timp. Ca urmare, sistemul trebuie s fie capabil s
genereze informaiile n funcie de cererile existente. De exemplu, situaia comenzilor
primite de la clieni este necesar produciei la sfritul fiecrei sptmni, pentru
planificarea produciei din urmtoarea sptmn, n timp ce marketingul cere lunar
aceast situaie, pentru stabilirea aciunilor promoionale ale lunii urmtoare.
n ce scop sunt utilizate ieirile? Este o ntrebare n funcie de care se determin dac
informaiile din structura ieirii sunt suficiente sau nu, prea detaliate sau prea sintetice. De
exemplu, situaia comenzilor primite de la clieni ar putea fi folosit pentru luarea deciziei
de a crete sau diminua producia pentru anumite produse, caz n care sunt necesare
informaii sintetice privind cererile de produse. Dac situaia este folosit pentru a controla
activitatea de livrare, atunci informaiile sunt mult mai detaliate, cuprinznd cantitatea de
produse cerut, perioada de livrare, adresa pentru livrare, clientul cruia i se face livrarea
etc.
6. Verificarea aspectelor calitative ale coninutului ieirilor
Se au n vedere urmtoarele caracteristici:
tipul datei cel mai indicat pentru atingerea scopului propus (date numerice, alfabetice,
memo, imagini, audio, hypertext);
corectitudinea sau precizia datelor, astfel nct n urma unor verificri ncruciate s nu
rezulte diferene sau, pentru datele numerice, s nu fie folosite aproximri, dect n condiii
bine specificate;
actualitatea datelor, n sensul obinerii la timp; altfel s-ar putea s-i piard din utilitate ca
urmare a transmiterii lor cu ntrziere;
orizontul de timp la care fac referire datele (perioade ale activitilor desfurate). De
exemplu, informaii privind vnzrile din ziua curent, sptmna sau luna anterioar,
vnzrile dintr-un an;
gradul de sintetizare, prin care se urmrete dac datele sunt prea sintetice sau detaliate.
De exemplu, obinerea de ctre sistemul de gestiune a clienilor a dou liste privind clienii
una detaliat, sub forma balanei analitice a clienilor necesar contabilitii generale, iar
cea de-a doua, sub form sintetic, destinat financiarului;
completitudinea datelor, din punct de vedere al insuficienei sau excesivitii lor, aa cum
rezult din coninutul actual al ieirilor. n acest caz, apar dou situaii. Prima se refer la
faptul c, pentru luarea deciziilor, gsirea unor soluii sau prelucrarea n alte scopuri a
informaiilor primite, persoanele sunt nevoite s foloseasc mai multe liste/rapoarte cu
coninut asemntor, ceea ce evideniaz c ieirile sunt caracterizate de lips de
informaii. A doua situaie apare cnd o persoan folosete doar o mic parte din coninutul
unui raport, deci e o abunden de informaii;
accesibilitatea datelor, n sensul disponibilitii lor n orice moment, cnd sunt cerute;
sigurana sursei datelor, prin care se urmrete dac asupra datelor pot exista incertitudini
sau reflect n mod real i exact operaiunile economice care le-au generat.
5.2.2 Analiza datelor de intrare
Activitatea de analiz a datelor de intrare urmrete toate aspectele legate de documentele
sau datele care sunt supuse prelucrrii n sistemul existent (intr n sistem). Abordarea datelor
se realizeaz separat, n urmtoarele dou situaii:
1. pentru documentele (inclusiv orice tip de raport) intrate n sistem pe suport de hrtie,
cnd se recurge la culegerea datelor coninute de acestea, de ctre un operator;
2. pentru informaiile provenite, n format electronic, din alte sisteme/ aplicaii, care
presupun retratarea sub aspectul compatibilitii cu formatul datelor existente n
aplicaiile 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 prelucrrii efective a datelor, precum i cu privire la necesitatea culegerii datelor de pe
documente pentru a fi supuse prelucrrilor. Astfel, se va pune accent pe urmtoarele elemente:
a) locul de provenien a documentelor (emitentul), indicndu-se att locurile din interiorul
organizaiei, ct i cele externe;
b) data emiterii documentului i data prelurii datelor n sistem, pentru a se ti care este
intervalul de timp dintre momentul apariiei datelor de intrare i cel al prelucrrii efective;
c) numrul de exemplare n care se ntocmete fiecare document i circuitul fiecrui
exemplar al documentului, pentru a se depista eventualele locuri n care documentul ar
putea fi supus acelorai tipuri de prelucrri;
d) frecvena de apariie a documentelor, n funcie de care se va determina timpul necesar
pentru prelucrarea datelor, precum i stabilirea tipului prelucrrii (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 aparine altui sistem (cu alte cuvinte,
dac documentul rmne sau nu n sistemul analizat);
f) datele preluate din documente pentru a fi supuse prelucrrii, astfel nct 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 condiiile 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 situaii cnd prelucrarea se face
dup data emiterii documentelor, dup emitent sau operaia economic pe care o reflect.
De exemplu, facturile primite de la furnizori pot fi grupate dup data primirii lor, dup
furnizor sau dup coninutul facturilor (facturi pentru materii prime i materiale, facturi
pentru prestri servicii, facturi pentru achiziia de mijloace fixe);
h) codificrile utilizate pentru nregistrarea datelor n documente, urmrind s existe
concordan ntre codurile utilizate n documente i cele existente n sistem, pentru a uura
procesul de prelucrare. De exemplu, existena corespondenei ntre codificarea
personalului folosit de sistemul de personal-salarizare i codificarea folosit de seciile de
producie, n cadrul fielor normelor de munc pentru fiecare salariat;
i) verificrile sau controlul la care sunt supuse documentele, din punct de vedere al
legalitii, completitudinii i corectitudinii lor, vizeaz:
semnarea documentelor de ctre persoanele responsabile;
identificarea eventualelor neconcordane ntre valorile nregistrate i cele stabilite prin
lege;
completarea tuturor cmpurilor sau explicarea situaiilor n care nu se solicit aceast
operaiune;
verificarea cmpurilor calculate, pentru a se elimina orice surs de eroare;
j) durata medie a timpului de ateptare al unui document pentru a fi supus prelucrrii,
precum i durata medie a prelucrrii;
k) dependenele existente ntre documente pentru a fi supuse proceselor de prelucrare. Cu
alte cuvinte, de stabilit dac un document poate fi supus prelucrrii numai atunci cnd un
alt document este deja introdus n sistem. De exemplu, factura primit de la furnizor nu
poate fi prelucrat pn nu au fost preluate datele de pe notele de intrare-recepie.
2. Analiza intrrilor din alte sisteme, n format electronic
Referitor la intrrile care provin din aplicaiile altor sisteme, este necesar s se
urmreasc:
a) identificarea datelor care intr din aplicaiile altor sisteme, pentru a determina formatul
de intrare, de exemplu sub forma unor fiiere temporare;
b) compatibilitatea structurii datelor, n sensul stabilirii tipului atributelor, a mrimii acestora
i a formatului, astfel nct datele transmise s nu fie supuse unor retratri, ci direct
procesului de prelucrare;
c) momentele n care sistemul analizat solicit date de la aplicaiile altor sisteme i cele n
care sunt oferite efectiv, pentru a se identifica potenialele ntrzieri datorate unor
deficiene ale aplicaiilor din alte sisteme sau din sistemul analizat. n situaia prelucrrilor
automate, trebuie urmrite tipurile de prelucrri (pe loturi sau on-line), platformele pe care
ruleaz aplicaiile, pentru a fi rezolvat problema compatibilitii procedurilor de
prelucrare;
d) identificarea datelor care trebuie supuse unor procese de pregtire (regrupri, reordonri
sau sortri, n funcie de necesitile sistemului care este supus analizei) i a celor ce pot fi
prelucrate direct.
Analiza intrrilor trebuie s se fac n strns legtur cu analiza ieirilor, pentru c

generarea acestora din urm depinde de tipul, caracterul i corectitudinea intrrilor n sistem.
De aceea, de cele mai multe ori, se apeleaz la o serie de matrice intrri/ieiri, pe baza crora
se determin dac pentru obinerea ieirilor 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 intrrilor/ieirilor sistemului de gestiune a comenzilor

Se poate observa, din matrice, c unele cmpuri 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 funcie de solicitrile existente, Valoare comanda se calculeaz ca sum a valorii
produselor comandate. Sunt i situaii cnd 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 ieirilor, aa cum este cazul Limita creditare, care
este o dat ce nu se regsete n sistem, ceea ce nseamn c la determinarea cerinelor ar trebui
inclus, fie pe baza eventualelor contracte/convenii care se ncheie cu clienii, fie a unor reguli
economice interne.
Astfel de matrice i verificri se pot realiza automat cu ajutorul instrumentelor CASE.
5.2.3 Analiza modului n care sunt stocate, accesate i pstrate datele

Prin aceast activitate se urmrete:
1. modul de organizare a datelor (fiiere, baze de date), astfel nct s se identifice dac este
necesar conversia datelor din formatul fiier 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 fiecrui atribut din
fiierele i bazele de date ale sistemului, relaiile de dependen i de calcul dintre ele;
3. codificarea utilizat pentru entitile de date din fiiere i baze de date, pentru a observa
dac este necesar o recodificare a datelor nscrise n documente sau a celor existente n
nregistrrile din fiiere sau baze de date;
4. criteriile de stocare i pstrare a datelor, n vederea stabilirii modului de indexare,
sortare i nregistrare a datelor, precum i stabilirea tipului de fiiere sau tabele ale unei
baze de date (permanente sau temporare, tabele index, istorice .a.);
5. identificarea datelor necesare prelucrrilor care nu se regsesc n fiierele sau bazele de
date ale sistemului. Aceast situaie poate fi determinat de faptul c unele date sunt
rezultatul altor prelucrri (de exemplu, calculul valorii unei comenzi), cnd nu este
necesar memorarea lor, sau date care nu au fost preluate n sistem, dar ale cror valori
trebuie incluse n prelucrri, ceea ce impune modificarea structurii fiierelor sau bazelor
de date, aa 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 (adugare, modificare, tergere);
7. frecvena operaiunilor de introducere, restaurare, tergere, modificare a datelor, pentru
determinarea timpului necesar prelucrrii, a performanelor pe care trebuie s le aib
echipamentele de calcul;
8. dimensiunea fiierelor sau a bazelor de date, din punct de vedere al numrului de
nregistrri i al spaiului de memorie ocupat, pentru evaluarea eficienei prelucrrilor i a
caracteristicilor tehnice ale echipamentelor;
9. timpul necesar pentru obinerea unor rspunsuri prin interogarea fiierelor sau a bazelor
de date;
10. suportul de stocare i pstrare a datelor (supori magnetici, optici, hrtie etc.), descriind
tipul i numrul dispozitivelor de stocare aflate la dispoziia utilizatorilor i specificarea a
ceea ce se memoreaz pe fiecare suport;
11. identificarea frecvenei cu care utilizatorii realizeaz copii de siguran pentru fiierele
cu care lucreaz, precum i suportul pe care se pstreaz acestea;
12. pentru staiile de lucru conectate la un LAN (Local Area Network) sau WAN (Wide Area
Network) trebuie s se identifice urmtoarele elemente:
care sunt aplicaiile i fiierele accesibile prin intermediul reelei;
pe ce server sunt stocate fiierele i bazele de date ale sistemului;
dac exist fiiere stocate pe mai multe calculatoare, trebuie identificate acele fiiere i
locaiile lor;
ce transferuri de fiiere au loc ntre calculatoarele utilizatorilor, precum i ntre acestea
i servere;
ce utilizatori au acces la e-mail i ct de des folosesc e-mailul (dac sistemul apeleaz

la e-mail pentru preluarea sau transmiterea datelor);
dac exist posibilitatea accesrii Internetului, trebuie specificat cine are acces, pentru
ce l acceseaz, ce servicii ale Internetului sunt folosite;
13. protecia i securitatea datelor, prin prezentarea drepturilor de acces ale utilizatorilor la
fiiere i baze de date (cine, ce drepturi are), procedurile de asigurare a integritii datelor,
de realizare a copiilor de siguran.
5.2.4 Analiza proceselor de prelucrare a datelor

Un proces reprezint o secven de proceduri intercondiionate sau aciuni ce stau la baza
finalizrii unei prelucrri. Aceste proceduri sunt, adesea, interdependente, avnd un flux de
date sau structuri de control bine definite de la o procedur la alta sau de la o aciune la alta.
O procedur reprezint un set de aciuni organizate pentru a atinge un scop anume, cum ar
fi: culegerea datelor de pe un document, adugarea unei nregistrri ntr-o tabel a unei baze de
date, interogarea unui baze de date pentru obinerea unei liste, calculul unei valori, verificarea
dreptului de acces la o informaie etc.
O funcie de prelucrare reprezint un grup de procese i proceduri prin care se constituie
o component funcional a sistemului. Pentru fiecare funcie identificat se specific
procesele i procedurile ce trebuie realizate, de una sau mai multe persoane, din unul sau mai
multe domenii funcionale ale firmei.
Procesele de prelucrare pot fi grupate n mai multe categorii, n funcie de scopul pe care
l urmresc, cum ar fi:
preluarea datelor de pe documentele surs, provenite de la componentele
organizaionale, parteneri externi sau alte sisteme;
preluarea datelor din alte procese de prelucrare ale sistemului, fie direct, fie prin
intermediul unor locuri de stocare (fiiere 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 relaiilor de calcul specifice;
adugarea, tergerea i modificarea nregistrrilor din bazele de date;
verificarea i validarea datelor prelucrate;
detectarea i corectarea erorilor;
pregtirea ieirilor care urmeaz a fi supuse unor prelucrri ulterioare;
generarea ieirilor solicitate de componentele organizaionale, parteneri sau alte
sisteme .a.
Din punct de vedere al rezultatului obinut, procesele de prelucrare pot fi de tipul
tranzaciilor sau transformrilor, cu urmtoarele particulariti:
1. tranzaciile constau n evaluarea datelor de intrare, n funcie de care se vor declana
prelucrrile. De obicei, rezultatul acestei categorii de prelucrri const n actualizri ale
bazelor de date, n sensul c fiecare intrare va declana o tranzacie de adugare de noi
nregistrri, o tranzacie de modificare a valorilor unor nregistrri sau o tranzacie de
tergere a nregistrrilor. De exemplu, un sistem informaional bancar prelucreaz
operaiuni bancare de genul: depuneri n cont, retrageri din cont, calculul i nregistrarea
dobnzilor etc. Toate au ca rezultat adugri de nregistrri (crearea unui nou cont),
modificri ale valorii nregistrrilor (creterea soldului unui cont, printr-o nou depunere),
tergeri ale nregistrrilor (lichidarea unui cont). Sistemul informaional de gestiune a
stocurilor prelucreaz datele privind recepiile 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, vnzarea de produse
etc., care au ca rezultat actualizri ale bazei de date.
2. transformrile presupun obinerea informaiilor din datele existente, fr a avea ca rezultat

modificri la nivelul nregistrrilor din baza de date. Sistemul de calcul al drepturilor
salariale reprezint un exemplu tipic pentru acest tip de prelucrri: pe baza numrului de
ore lucrate (intrarea n sistem) se calculeaz drepturile salariale, prin efectuarea diferitelor
calcule privind tariful orar, sporurile i reinerile prevzute, n final obinndu-se statul de
plat i centralizatorul statelor de salarii. Un alt exemplu l reprezint sistemul de
contabilitate general, a crui funcie principal o constituie nregistrarea cronologic i
sistematic a micrilor de valori ce au loc n firm. Notele contabile, preluate de la
sistemele de eviden analitic, sunt transcrise, mai nti, n registrul jurnal, apoi ele sunt
prelucrate i sistematizate n cartea mare, pe baza creia se va ntocmi balana de
verificare, prin aplicarea regulilor de transformare cunoscute. n final, se va obine bilanul,
ce reprezint principala ieire a sistemului de contabilitate general.
La nivelul unui sistem se regsesc ambele categorii de procese (tranzacii i transformri),
numai c unele sunt orientate cu preponderen spre tranzacii, iar altele spre transformri, aa
cum se va vedea i n capitolul care trateaz proiectarea programelor.
n cazul sistemelor automatizate, identificarea proceselor de prelucrare se realizeaz,
relativ uor, prin citirea documentaiei aplicaiilor (dac exist) sau prin analiza aplicaiei.
Astfel, pentru studierea modului de descompunere a sistemului, se urmresc opiunile
meniurilor i submeniurilor din care sunt constituite aplicaiile. Fiecare opiune va fi analizat
din perspectiva aciunilor pe care le realizeaz, pe baza citirii codului surs sau a
documentaiei utilizatorului. De multe ori, opiunile unui meniu sunt grupate n dou moduri:
1. n funcie de operaiile economice care au generat datele ce urmeaz a fi supuse prelucrrii,
caz n care submeniurile reflect operaiile respective i vor conine proceduri pentru
introducerea datelor, proceduri de actualizare a bazelor de date, de verificare i validare, de
pregtire i generare a ieirilor;
2. n funcie de tipul prelucrrilor care se execut, cnd submeniurile sunt organizate plecnd
de la principalele prelucrri care se vor executa (introducere date, actualizare baze de date,
generare rapoarte), n cadrul lor regsindu-se operaiile economice care urmeaz a fi
prelucrate.
n cazul sistemelor manuale, procesele de prelucrare trebuie identificate plecnd de la
persoanele implicate, n sensul analizei aciunilor pe care le realizeaz asupra documentelor,
innd cont de etapele ciclului prelucrrilor datelor, descris ntr-un capitolul anterior. Astfel, se
va urmri modul n care are loc transcrierea unor cmpuri de pe anumite documente n alte
documente, sub forma centralizatoarelor, nsumarea cmpurilor ce solicit o astfel de
operaiune, aplicarea unor formule de calcul pentru obinerea i completarea unor cmpuri de
pe documentul pe care l folosesc .a.m.d.
De exemplu, n cazul prelucrrii manuale a comenzilor primite de la clieni, se pot
desfura urmtoarele procese:
preluare, prin telefon sau pot, a comenzilor de ctre o persoan de la vnzri;
scrierea datelor pe un formular specific de comand sau completarea celui primit cu
alte date necesare prelucrrilor ulterioare, cum ar fi codul clientului, codul produselor,
preul de vnzare;
cutarea i citirea informaiilor (de pe documente centralizatoare sau de alt natur)
privind stocul de produse existent (din fia de magazie) i limita de creditare acordat
clientului (din fia de cont analitic);
generarea notei de confirmare a comenzii;
gruparea comenzilor n funcie de codul clientului, data comenzii, codul produselor
etc.;
centralizarea datelor privind produsele solicitate i transmiterea lor la producie i/sau
depozite;
arhivarea comenzilor n funcie de codul clientului sau de dat;
preluarea informaiilor privind facturile emise pentru fiecare comand;

compararea facturilor cu comenzile primite (cantiti livrate, ce a mai rmas de livrat);
ntocmirea rapoartelor necesare analizei comenzilor primite i onorate i a altor
categorii de ieiri.
Despre identificarea proceselor de prelucrare ale unui sistem vom discuta detaliat n
paragraful urmtor.
Avnd n vedere comentariile anterioare, n activitatea de analiz a proceselor de
prelucrare trebuie s se evidenieze urmtoarele aspecte:
1. descompunerea funcional a sistemului n funcii, procese, subprocese, proceduri
.a.m.d., pentru a se ti dimensiunea sistemului analizat, principalele prelucrri ale
acestuia. De asemenea, se vor specifica toate locurile din firm unde sunt executate;
2. logica proceselor de prelucrare, n vederea determinrii structurii lor, a pailor necesari
pentru prelucrarea datelor i a momentului declanrii prelucrrii;
3. ieirile obinute n urma fiecrui proces de prelucrare. Orice raport generat de sistem
trebuie s fie documentat, iar un model al fiecrei pagini din raport se va ataa la
documentaia sistemului. De asemenea, trebuie incluse controalele i auditrile care stau
la baza realizrii raportului;
4. formulele sau relaiile de calcul utilizate pentru obinerea unor valori necesare n cadrul
rapoartelor sau diferitelor situaii;
5. specificarea tipului de prelucrare care se realizeaz: adugri, modificri, tergeri de
nregistrri la nivelul bazelor de date sau al fiierelor, obinerea rapoartelor, verificarea i
validarea datelor etc.;
6. evenimentele care declaneaz procesul/procedura. Pentru fiecare eveniment se va
descrie documentul surs, timpul, frecvena de apariie, volumul, toate condiiile de
excepie i orice alt aspect relevant pentru procesul de prelucrare. De asemenea, se va
descrie, n detaliu, prelucrarea declanat, dac se realizeaz imediat ce a aprut
evenimentul, este amnat sau condiionat de ali factori declanatori. n acelai timp, se
va specifica dac prelucrarea este dependent de un proces anterior sau de existena unor
date deja prelucrate;
7. datele utilizate pentru prelucrare. Este necesar s se identifice orice surs suplimentar a
acelorai date, ca i regulile de validare i verificare a lor;
8. modul n care fiecare proces intr n legtur cu alte procese ale aceleiai funcii sau ale
altor funcii, urmrind s se determine dac legtura se realizeaz prin intermediul unei
baze de date sau direct prin trecerea datelor dintr-un proces n altul;
9. identificarea oricrei proceduri manuale folosit pentru prelucrarea datelor, care va fi
descris i, dac este posibil, inclus ntr-o procedur informatizat;
10. stabilirea salvrilor 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 aciunile
ntreprinse la detectarea erorilor.
*
* *
Pe un plan mai general, n urma acestor activiti de studiere a sistemului existent, se va
realiza o documentaie privind:
modul n care au loc activitile de culegere, prelucrare, stocare i transmitere a
informaiilor;
modul de utilizare a echipamentelor, softului (dac este cazul), a resurselor umane;
dimensiunile i natura schimbrii, determinate prin analiza punctelor tari i slabe ale
sistemului.
Exemple de puncte slabe: inoportunitatea sau inexactitatea informaiilor obinute de

sistem, organizarea ineficient a datelor, costuri mari de stocare a datelor, slaba pregtire a
personalului n utilizarea tehnicii de calcul, slaba organizare a fluxurilor informaionale.
Pe baza elementelor identificate i descrise prin studierea sistemului existent, urmeaz
modelarea lui, cu ajutorul diagramelor fluxurilor de date, diagramelor entitate-relaie,
diagramele strilor de tranziie etc., pentru a crea imaginea grafic a sistemului. Activitatea de
modelare este obligatorie n situaia n care nu exist nici o documentaie, altfel se folosesc
specificaiile existente. Modelarea va fi prezentat n capitolele viitoare.
5.3 Identificarea proceselor de prelucrare ale sistemului

Aa cum am vzut, un rol important n analiza sistemului l are studiul proceselor de
prelucrare, plecnd de la tranzaciile economice/evenimentele 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 declaneaz procesele de prelucrare pe care le execut un sistem, ceea ce
nseamn c este necesar inventarierea i analiza lor, atenia fiind concentrat asupra
urmtoarelor aspecte3:
mediul n care a avut loc evenimentul, extern sau intern firmei;
modul de reflectare a evenimentelor prin scopul i funciile sistemului;
interfeele cu utilizatorii i cu alte sisteme, utilizatorii fiind cei mai n msur s
descrie nevoile informaionale din punct de vedere al evenimentelor la care trebuie s
rspund sistemul.
O astfel de analiz permite descompunerea sistemului n componente, pentru a fi studiate
separat, mai uor de neles i gestionat, fiind una dintre cile cele mai sigure de atingere a
obiectivelor de ctre noul sistem.
La firma analizat de noi, cteva dintre evenimentele identificate pentru sistemul de
gestiune a clienilor sunt prezentate n Caseta 5.1.
Caseta 5.1 Exemple de evenimente ale sistemului de gestiune a clienilor la firma ABC
Principalele evenimente de la care se poate pleca pentru identificarea proceselor de prelucrare
din cadrul sistemului de gestiune a clienilor:
solicitarea de cataloage de ctre clienii poteniali i cei existeni;
transmiterea de ctre clieni a comenzilor;
livrarea comenzilor de ctre firm;
returnarea produselor de ctre clieni;
ncasarea contravalorii produselor vndute.
Principalele date care ar trebui memorate de sistem, generate de evenimentele enumerate, sunt
cele privind clienii, cataloagele transmise, produsele comandate i livrate, dar i cele care nu au putut
fi onorate, debitarea i creditarea contului clienilor.
Procesele de prelucrare pe care trebuie s le asigure sistemul se bazeaz pe evenimentele
enumerate anterior, trei dintre ele fiind declanate de clieni (debitarea contului prin livrarea
produselor, creditarea lui prin ncasarea valorii produselor vndute sau returnarea produselor,
modificri ale datelor privind clienii prin transmiterea comenzilor sau a solicitrilor de cataloage).
Alte trei procese sunt declanate de factorul timp (generarea de rapoarte lunare, transmiterea de
ntiinri clienilor, generarea de rapoarte sintetice sptmnale).
5.3.1 Tipuri de evenimente

n analiza unui sistem, pentru identificarea funciilor de prelucrare, pot fi avute n vedere
trei mari categorii de evenimente: externe, temporale, de stare.
Course Technology, Thomson Learning, Boston, 2002, pp. 153-157.
Un eveniment extern reflect o operaiune ce are loc n afara sistemului, fiind iniiat de un
agent, actor sau entitate extern (o persoan, un departament din interiorul firmei sau alt
firm), care furnizeaz date sistemului sau primete informaii de la el. Aici nu trebuie s se
fac confuzia ntre entitile externe sistemului i cele externe firmei, pentru c atenia se
orienteaz spre ceea ce poate s declaneze prelucrarea datelor n cadrul sistemului.
De exemplu, entitate extern sistemului de gestiune a aprovizionrilor este furnizorul, care
livreaz materiile prime i materiale, pentru c declaneaz prelucrarea datelor privind facturile
primite. ns, i comisia de recepie este entitate extern sistemului de aprovizionare, pentru c
ofer informaii privind eventualele diferene ce apar ntre datele nscrise n facturile
furnizorilor i cele identificate la verificarea faptic a cantitilor primite, reflectate ntr-un
document specific (nota de intrare-recepie) 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 esenial pentru un
sistem de gestiune a clienilor, dar lui i sunt asociate i alte evenimente, n sensul c un client
poate s returneze un produs, s plteasc factura pentru comanda onorat .a.
Ca urmare, pentru analiza sistemului se vor identifica acele entiti externe care ar putea
solicita informaii de la sistem sau care pun date la dispoziia lui.
Evenimentele externe stau la baza stabilirii principalelor funcii de prelucrare ale
sistemului. La descrierea lor este indicat s fie folosite denumiri ct mai sugestive, astfel nct
entitatea extern s fie mai uor de identificat, precum i aciunile realizate de aceasta i care
pot afecta sistemul. De exemplu, operaiunea Transmiterea comenzii de ctre client descrie
entitatea extern (Clientul) i aciunea pe care o realizeaz (Transmiterea comenzii), ce va
determina preluarea i prelucrarea comenzilor, reprezentnd una din funciile de baz ale
sistemului de gestiune a clienilor.
Evenimentele externe pot fi declanate i de nevoile informaionale ale unor persoane sau
componente organizaionale din interiorul firmei, cum ar fi solicitarea unor informaii privind
ncasarea facturilor emise clienilor, pentru actualizarea conturilor. Majoritatea evenimentelor
externe pot fi ncadrate n una din urmtoarele categorii generale:
entitile externe transmit date, ca rezultat al unei operaii economice;
entitile externe solicit anumite informaii pentru derularea unor operaii economice,
fr a se cunoate momentul solicitrii;
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 informaiile de ieire la intervale
bine definite, cum ar fi statele de plat emise de sistemul de salarizare, chenzinal sau lunar,
lista achiziiilor pe luna x, generat de sistemul de aprovizionare .a.m.d. Uneori, ieirile sunt
rapoarte pe care conducerea dorete s le primeasc periodic, cum ar fi rapoartele privind
eficiena unei activiti sau rapoarte cu titlu de excepie.
Evenimentele temporale sunt diferite de cele externe, prin faptul c sistemul poate s
genereze automat informaiile solicitate fr s i se specifice ce are de fcut. Cu alte cuvinte,
nici un agent extern sau entitate extern nu declaneaz funciile de prelucrare ale sistemului,
ci factorul timp, entitile externe urmnd doar s primeasc informaia. Identificarea acestui
tip de eveniment se poate face plecnd de la gsirea rspunsurilor la o serie de ntrebri de
genul: Ce informaii trebuie obinute la anumite perioade de timp? Ce prelucrri ar putea fi
solicitate n acele momente?
De exemplu, n cazul sistemului de salarizare, procesul prin care se obin statele de salarii
ar putea fi denumit astfel: Generarea chenzinal/lunar a statelor de plat, ceea ce evideniaz
informaiile pe care ar trebui s le prelucreze sistemul i perioada de timp la care ar trebui s
realizeze funcia respectiv.
Aceste tipuri de evenimente nu este obligatoriu s fie declanate la date calendaristice
fixe, ci pot fi declanate i la ndeplinirea anumitor condiii, dependente de perioade
calendaristice. O situaie de acest fel se ntlnete atunci cnd un client nu-i pltete factura la
data prevzut, iar sistemul poate genera o ntiinare privind ntrzierea plii, dup 15 zile de
la expirarea termenului de plat.
A treia categorie de evenimente este cea de stare. Ele apar cnd se ntmpl ceva n sistem
sau este ndeplinit o condiie ce declaneaz o prelucrare. De exemplu, dac vnzarea unui
produs are ca rezultat scderea 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 excepia
faptului c nu sunt cunoscute momentele de timp cnd trebuie declanate procedurile de
prelucrare i depind de evenimentele externe, fiind executate i ca rezultat al altor prelucrri.
Trebuie remarcat faptul c evenimentele temporale i de stare presupun, n principal,
transpunerea datelor memorate n sistem ntr-o form solicitat de diferiii utilizatorii ai
informaiei, spre deosebire de cele externe care implic adugri, modificri sau tergeri de
date.
5.3.2 Identificarea evenimentelor

Definirea evenimentelor care afecteaz un sistem nu este un demers uor, dar sunt cteva
recomandri generale ce ar putea ajuta la identificarea i analiza lor, dintre care mai importante
sunt:
analiza condiiilor i rspunsurilor sistemului la anumii factori ce ar putea declana
procesele de prelucrare;
urmrirea secvenei de derulare a operaiilor economice;
dependena de tehnologie i posibilitile de realizare a prelucrrilor;
analiza fiecrui eveniment independent de altele.
n unele cazuri, este dificil de fcut diferena dintre un eveniment i o serie de aciuni sau
condiii care pot conduce la declanarea lui. Se va lua exemplul unui client care cumpr
dintr-un magazin un produs. Din perspectiva clientului, aceast cumprare presupune o lung
secven de aciuni. 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 cerinelor sale va intra n alt magazin pn va gsi produsul dorit. n final, clientul
va cumpra acel obiect de care are nevoie. Dar analistul trebuie s gndeasc o astfel de
secven din momentul n care evenimentul afecteaz sistemul. n exemplul dat, sistemul va
reaciona numai atunci cnd clientul a intrat n magazin, a ales produsul i spune vreau s
cumpr acest produs. Tot ceea ce a fost descris pn la achiziia lui reprezint doar o secven
de condiii ce ar putea declana un eveniment i nu evenimentul ca atare.
n alte situaii, nu este uor s se disting ntre un eveniment extern i rspunsul
sistemului. De exemplu, dup ce clientul s-a hotrt s cumpere produsul, i se solicit s l
achite, iar clientul va putea opta pentru plata cu card sau n numerar. Este aceast aciune un alt
eveniment? n acest caz, nu, pentru c face parte din interaciunea care are loc pentru
finalizarea operaiunii de finalizare a procesului de cumprare a produsului.
Modalitatea prin care s-ar putea determina dac o aciune este un eveniment sau o
succesiune n cadrul acelui eveniment const n gsirea rspunsului la ntrebarea: Poate fi
finalizat procesul de prelucrare fr s fie ntrerupt? sau Sistemul este pregtit pentru
urmtoarea operaiune sau ateapt prelucrarea n continuare a datelor generate de evenimentul
curent? Din momentul n care clientul dorete s cumpere produsul, procesul continu pn
cnd achiziia este finalizat, sistemul putnd s intre n perioada de ateptare a urmtoarei
operaiuni, deci a unui nou client care s cumpere un produs i s plteasc pentru el.
Pe de alt parte, pot s apar situaii cnd aciunile, prezentate ca fcnd parte din acelai
eveniment, s fie tratate distinct, cum este cazul achiziiilor pe baz de credit comercial. Se
pune ntrebarea: Cnd clientul pltete mai trziu, la sfritul lunii, se poate considera c
aciunea face parte din evenimentul de cumprare a produsului? n acest caz, nu, pentru c
sistemul prelucreaz operaiunea de cumprare, dup care, pn la sfritul lunii, cnd va avea
loc ncasarea, prelucreaz alte date. Nu se poate opri sistemul din prelucrarea datelor, generate
de alte tipuri de evenimente, pn cnd are loc ncasarea. n acest caz, avem dou evenimente
externe: Cumprarea, care declaneaz procesul de prelucrare Emitere factur, respectiv
Efectuarea plii de ctre client, prin care se declaneaz procesul ncasarea facturii, i un
eveniment temporal care conduce la Generarea situaiei lunare a contului clientului.
Pentru identificarea evenimentelor este util s se analizeze secvena lor, plecnd de la
entitatea extern care le declaneaz sau este afectat de ctre acestea. n cazul sistemului de
gestiune a clienilor de la firma ABC, analistul ar trebui s se gndeasc la toate evenimentele
posibile care ar putea s aib loc n legtur cu un client. n primul rnd, clientul poate solicita
un catalog de produse sau anumite informaii despre disponibilitatea unui produs, determinnd
adugarea unei noi nregistrri 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 mrime a produselor sau un nou articol), dup care dorete s urmreasc
starea comenzii i momentul livrrii. 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 secvenei 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 clienilor trebuie s le surprind.
Caseta nr. 5.2 Evenimentele specifice sistemului de gestiune a clienilor la firma ABC
Sistemul de gestiune a clienilor implic o mare varietate de evenimente, multe dintre ele similare
deja celor prezentate. Ca evenimente externe au fost identificate:
verificarea de ctre client a disponiblitii unui produs;
transmiterea unei comenzi de ctre client;
modificarea sau anularea de ctre client a unei comenzi;
solicitarea de ctre client sau conducere a informaiilor necesare verificrii strii unei comenzi;
livrarea/onorarea comenzii;
returnarea produselor de ctre client (defecte, shimbarea prerii despre produs, returnare total
sau parial);
solicitarea cataloagelor de produse de ctre potenialii clieni;
solicitarea din partea departamentului de marketing de a transmite materiale promoionale
clienilor;
schimbarea politicii de creditare a clienilor (creterea limitei de creditare, acordarea de
discounturi, reducerea penalitilor etc.);
obinerea unor noi produse, modificarea caracteristicilor produselor existente sau a preurilor;
lansarea de aciuni promoionale pentru anumite produse sau anumii clieni.
Se poate observa c multe dintre evenimente au ca entitate extern declanatoare clientul, n timp
ce altele implic apariia chiar a departamentelor sau conducerii firmei. Analistul trebuie s dezvolte o
list a evenimentelor externe, urmrind toate persoanele sau componentele organizaionale care pot
declana o anumit operaiune de prelucrare sau care solicit anumite rspunsuri din partea sistemului.
Sistemul de gestiune a clienilor include cteva procese temporale, declanate de factorul timp,
respectiv:
generarea rapoartelor privind comenzile primite;
generarea rapoartelor privind tranzaciile desfurate ntr-o perioad de timp;
generarea rapoartelor privind comenzile onorate;
obinerea de rapoarte privind potenialii clieni;
obinerea de rapoarte privind modificrile efectuate asupra contului clienilor;
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 situaiile pe care sistemul trebuie s le
genereze la anumite perioade de timp.
Pe msura dezvoltrii listei evenimentelor, analistul trebuie s observe i noteze orice informaie
suplimentar care poate prezenta interes, prin construirea unui tabel al evenimentelor, n care pe linii
sunt reprezentate evenimentele, iar pe coloane detaliile fiecruia. Un exemplu de astfel de tabel pentru
evenimentul Solicitare informaii disponibilitate produs este redat n figura C5.1.
Ce agent/actor extern
generat de sistem?
primete ieirea
Destinaia:
cazul) ar trebui s fie
generat de sistem?
Ce ieire (dac este
Destina?ia
Destinaia
Client
Rspunsul:
Detalii privind
R?spunsul
sistemului
Rspunsul
sistemului
produsul
stoc
sursa pentru introducerea
existeneinnstoc
produs
agentul extern reprezint
sistemului
Cutareprodus
sistemului
verificarea
Ac?iunea
Aciunea
?iiverificarea
Pentru un eveniment
extern, actorul sau
existen?ei
datelor n sistem.
Cautare
cnd un eveniment
Ce face sistemul
Sursa:
Sursa
Aciunea:
Client
areloc?
Declanator
Declan?ator
declanatorul const n datele
evenimentele temporale, este
pentru un
Cum tie sistemul c a avut
Cererea
introduse n sistem. Pentru
disponibilitate produs produs

momentul ce declaneaz
loc un eveniment? Pentru
evenimentele externe,
prelucrarea n sistem.
produs
informa?ii
Declanatorul:
Solicitareinformaii
Eveniment
disponibilitate
Solicitare
Ce determin
Evenimentul:
efectueze o
sistemul s
aciune?
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)
Cteva comentarii asupra termenilor utilizai.

Un semnal transmis sistemului atunci cnd un eveniment a avut loc poart denumirea de
declanator. Pentru un eveniment extern, declanatorul l reprezint primirea datelor pe care
sistemul trebuie s le prelucreze. De exemplu, cnd un client transmite o comand, detaliile din
noua comand sunt intrri n sistem. De asemenea, este important s se identifice sursa datelor
(entitatea extern declanatoare), care, n exemplul dat, este clientul. ns, declanatorul poate
s-l constituie i un alt proces de prelucrare, care transmite o serie de date pentru a fi supuse
altor prelucrri. De exemplu, n urma introducerii datelor de pe comenzile primite de la clieni,
se transmite un flux de date n procesul de verificare a situaiei contului clienilor, pentru a
vedea dac noile comenzi se mai ncadreaz n limita de creditare acordat.
Pentru un eveniment temporal, declanatorul este dat de momentul dintr-o perioad de
timp bine delimitat cnd sistemul trebuie s obin sau s prelucreze ceva. De exemplu, la
sfritul fiecrei zile, sistemul trebuie s genereze rapoartele privind operaiile economice
desfurate n acea zi cu clienii firmei.
n legtur cu ntrebarea Ce trebuie s fac sistemul cnd un eveniment are loc sau care
este reacia sistemului la eveniment?, se va identifica aciunea pe care trebuie s o execute.
Aciunea reprezint prelucrrile pe care sistemul le desfoar cnd a avut loc un eveniment i
se concretizeaz ntr-o ieire sau rezultat bine delimitat. De exemplu, cnd 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 cnd trebuie s se genereze un raport privind tranzaciile, sistemul execut o procedur
numit Generare raport tranzacii zilnice.
n final, trebuie s se identifice rezultatul/rspunsul obinut de sistem n urma aciunilor
desfurate, acesta fiind o ieire a sistemului. Cnd sistemul genereaz rapoartele privind
tranzaciile zilnice, nseamn c se obin ieirile sistemului, dar printr-o aciune se pot genera
mai multe rapoarte. De exemplu, cnd sistemul creeaz o nregistrare nou n fiierul de
comenzi, sistemul poate transmite clientului o confirmare a comenzii, iar detaliile privind
comanda sunt trimise depozitelor pentru pregtirea livrrii. Destinaia este locul unde
rspunsul sistemului (ieirea) este transmis, reprezentat de un agent sau actor extern. Tot ca
destinaie sunt considerate i locurile de stocare n care sunt nregistrate datele rezultate n
urma prelucrrilor.
Uneori, o aciune a unui sistem este posibil s nu genereze imediat un rspuns. De
exemplu, dac un client dorete s-i actualizeze informaiile privind adresa, ele vor fi
modificate n baza de date, dar nu este necesar ca sistemul s dea un rspuns clientului la
aceast aciune. nregistrarea informaiilor n baza de date reprezint ns o parte a aciunii
sistemului la evenimentul de transmitere de ctre client a noilor date, ce vor fi folosite la
apariia altor evenimente.
Se poate spune c tabelul evenimentelor este un mijloc eficient de a culege o parte din
infomaiile necesare stabilirii cerinelor informaionale ale sistemului.
n cazul sistemului de gestiune a clienilor de la ABC, tabelul evenimentelor este redat n
caseta 5.3:
Caseta 5.3 Tabelul evenimentelor pentru sistemul de gestiune a clienilor la firma ABC
Eveniment Declanator Sursa Aciunea Rezultat Destinaie

Solicitare Cererea Client Cutare existen Detalii privind Client
informaii pentru un produs n stoc produsul solicitat
disponibilitate produs
produs
Transmitere de Comand Client Crearea unei Date client Birou (credit
ctre client a comenzi noi comercial)
unei comenzi Confirmare comand Client
Detalii comand
Date tranzacii Depozit
Banc
Modificare sau Cerere Client Actualizare Confirmare modificare Client
anulare modificare/ comand Detalii privind Depozit
comand anulare modificrile Banc
comand Date tranzacii
Solicitare Sfrit de Proceduri Generare rapoarte Rapoarte privind Conducere
rapoarte sptmn, automate privind comenzile comenzile

privind lun, primite
comenzile trimestru, an
primite
Solicitare Sfritul zilei Proceduri Generare rapoarte Rapoarte privind Contabilitate
rapoarte automate tranzacii tranzaciile zilei
tranzacii
Verificare Solicitare Client sau Urmrirea Detalii privind starea Client sau
stare comand informaii Conducere traseului comenzii comenzii Conducere
privind starea
comenzilor
Onorare/ Notificare de Depozit nregistrarea Date produse livrate Tabela comenzi
livrare onorare a onorrii comenzii
comand comenzii
Returnarea de Notificare de Client Crearea unei Confirmare returnare Client
ctre client a returnare comenzi pentru Date tranzacii
produselor returnare Banc
Solicitare Sfrit de Proceduri Generare rapoarte Rapoarte privind Conducere
rapoarte sptmn, automate privind comenzile comenzile onorate
privind lun, onorate
comenzile trimestru, an
onorate
Solicitare de Cererea Client Preluarea Catalog Client potenial
ctre clieni a pentru catalog potenial informaiilor
cataloagelor de privind catalogul
produse
Solicitare Detalii Marketing Distribuire Pachet promoional Clieni i poteniali
transmitere privind informaii promoii clieni
materiale aciunile
promoionale promoionale
Schimbare Ajustarea Conducere Modificarea Notificare de ajustare Client
politic de contului contului clientului Date tranzacie
creditare a clientului Banc
clienilor
Modificare Detalii Birou Actualizare date Date cataloage Tabela cataloage
preuri, privind cataloage cataloage modificate
caracteristici modificrile
produse, tipuri la nivelul
produse cataloagelor
5.4 Determinarea cerinelor pentru noul sistem

O cerin a sistemului informaional sau cerin informaional reprezint o funcie sau o
caracteristic a noului sistem, un comportament cuantificabil i verificabil pe care sistemul
trebuie s-l aib, precum i restriciile sub influena crora va fi exploatat, toate pentru a
rspunde obiectivelor unei organizaii i pentru a rezolva un set de probleme.
Cerina mai este definit i din urmtoarea perspectiv4:
condiia sau abilitatea necesar unui utilizator pentru a rezolva o problem sau pentru a
atinge un obiectiv;
condiia sau capacitatea pe care trebuie s o dein un sistem sau o component a
sistemului pentru a satisface un contract, un standard, o specificaie sau alt document;
reprezentarea documentat a unei condiii sau capaciti/abiliti, aa 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.
Cerinele nu constau doar din funcii ale unui sistem sau ale unei componente, ci trebuie
urmrite mai multe caracteristici ale acestora, astfel nct s fie exploatat pentru a rspunde
eficient unei probleme sau unui domeniu de activitate.
Am vzut c pe parcursul etapei de planificare a sistemului se identific scopul sistemului,
adic principalele funcii i caracteristici pe care trebuie s le dein, detaliate n timpul
analizei.
Dintr-o perspectiv general, la nivelul unui proiect de dezvoltare se identific dou
categorii majore de cerine ale unui sistem: funcionale i nefuncionale sau tehnice. ns, se
ntlnesc i alte tipuri, vzute din perspectiva utilizatorilor sau a managementului de proiect,
aa cum se va vedea ntr-un paragraf urmtor.
Activitatea de determinare a cerinelor este considerat una din cele mai complexe din
faza de analiz, datorit dificultii de evaluare a necesarului de informaii. n unele situaii,
utilizatorii pot fi subiectivi cnd sunt chestionai pe o astfel de tem, iar n alte situaii nu i
dau seama care sunt informaiile 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 acetia, pn la studierea documentelor
primare, a rapoartelor, a procedurilor folosite.
Cauzele care determin apariia problemelor n procesul de culegere a cerinelor sunt
grupate astfel:
cauze legate de scop graniele sistemului sunt greit stabilite sau utilizatorii/beneficiarii
sistemului specific detalii tehnice inutile, care mai mult deruteaz dect s clarifice
obiectivele sistemului;
cauze privind dificultatea nelegerii dorinelor utilizatorilor, de unde necesitatea bunei
cunoateri de ctre echipa de analiz a domeniului sistemului, pentru c utilizatorii:
nu sunt foarte siguri asupra elementelor de care au nevoie;
nu cunosc ndeajuns de bine performanele i limitele mediului lor de lucru;
nu neleg n totalitate domeniul problemei;
au probleme n comunicarea nevoilor;
omit informaii pe care le consider implicite, normale;
cerinele specificate pot intra n conflict cu nevoile altor utilizatori;
percep greu limbajul echipei de analiz, mai ales dac se folosete un limbaj pur tehnic;
formuleaz cerine ambigue sau netestabile.
cauze legate de volatilitatea informaiilor. Cerinele, de multe ori, se modific n timp.
Descrierile anterioare au evideniat faptul c multe dintre greutile care apar se datoreaz
comunicrii dificile ntre utilizatori i echipa de dezvoltare a sistemului. Nenelegerile dintre
ei pot duce la grave probleme n dezvoltarea sistemului, fie prin eforturi umane i financiare
ineficiente, fie prin nerezolvarea cerinelor reale ale sistemului propus pentru dezvoltare.
Prin determinarea i analiza cerinelor se urmrete gruparea i organizarea lor n seturi
interdependente, identificarea relaiilor dintre o cerin cu altele i asigurarea corespondenei
dintre ele, depistarea eventualelor omisiuni sau ambiguiti, precum i ierarhizarea cerinelor n
funcie de nevoile utilizatorilor.
Din momentul n care ncepe analiza cerinelor, este necesar examinarea urmtoarelor
aspecte:
dac au fost specificate toate cerinele la un nivel corespunztor de abstractizare sau se
indic un nivel de detaliere tehnic necorespunztoare acestei etape;
cerinele sunt cu adevrat necesare sau reprezint caracteristici sau elemente
suplimentare ce nu sunt eseniale atingerii scopului sistemului;
fiecare cerin este bine delimitat i nu este ambiguu formulat;
cerinele au identificate sursele (n general, o anumit persoan);
o cerin s nu intre n conflict cu altele;
s fie posibil satisfacerea cerinelor prin aplicaia informatic care urmeaz s fie
dezvoltat;
fiecare cerin s poat fi testat n momentul n care urmeaz s fie implementat
sistemul.
Fr a avea pretenia de a fi o list exhaustiv, poate asigura o anumit certitudine asupra
cerinelor ce se vor regsi la viitorul sistem.
5.4.1 Surse de identificare a cerinelor

Principala surs de informaii privind cerinele funcionale 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 pltesc sau sunt proprietarii sistemului;
3. personalul tehnic care trebuie s asigure exploatarea i ntreinerea sistemului;
4. organisme externe firmei, cum ar fi clienii, furnizorii, bncile, interesate n obinerea
diverselor informaii care s vin n sprijinul dezvoltrii relaiilor de parteneriat.
n determinarea cerinelor, un pas important const n identificarea stakeholder-ilor,
ncercndu-se, pe ct posibil, o ct mai bun reprezentare a lor n echipa proiectului. Rolul
fiecrei categorii n timpul analizei va fi descris n continuare.
5.4.1.1 Utilizatorii sistemului
Rolul utilizatorilor trebuie identificat plecnd de la analiza fluxurilor informaionale care
apar n legtur cu sistemul, att pe orizontal, ct i pe vertical.
n cazul dimensiunii orizontale, dac lum exemplul unui nou sistem de gestiune a
stocurilor, care ar putea s afecteze comisia de recepie, depozitul, vnzrile i producia,
trebuie ca persoanele din aceste departamente s poat s-i descrie propriile cerine. Comisia
de recepie informeaz despre concordana scriptic i faptic a produselor achiziionate de
firm, iar rezultatele oferite vor sta la baza actualizrii stocului. Depozitul este cel care preia i
distribuie produsele existente n stoc, primind informaii de la comisia de recepie,
departamentul de vnzri i producie. La nivelul departamentului de vnzri este necesar s se
determine cnd i cine actualizeaz stocul n momentul vnzrii unui produs, dar dup livrare
i emiterea facturii. Producia s-ar putea s aib nevoie de informaii din sistemul de stocuri
pentru planificarea capacitilor de producie i stabilirea planului de producie.
Cerinele identificate din analiza circuitului informaional pe orizontal asigur includerea
diferitelor departamente, prin reprezentanii lor, n echipa de analiz.
Dimensiunea vertical a fluxurilor permite nelegerea nevoilor informaionale ale
personalului de conducere de pe nivelul operaional, tactic sau strategic al firmei.
Fiecare categorie de utilizatori i are propriile caracteristici, de care trebuie s se in
cont n timpul analizei i proiectrii, i anume:
1. utilizatorii operaionali sunt cei care folosesc sistemul pentru desfurarea activitilor
zilnice, despre care trebuie s ofere informaii i s specifice modul n care sistemul ar
trebui s vin n sprijinul lor;
2. utilizatorii informaionali sunt cei care solicit sistemului informaii, care pot fi att
utilizatorii operaionali, ct 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 informaii care trebuie s fie disponibile i formatul corespunztor;
3. utilizatorii decideni sunt cei responsabili cu analiza a ceea ce firma a realizat din punct
de vedere al performanelor nregistrate n comparaie cu planificrile i procedurile

stabilite. Ca urmare, ei solicit informaii statistice i de sintez din diferite sisteme.

Conducerea poate ajuta n etapa de analiz, rspunznd la urmtoarele ntrebri:
ce tipuri de rapoarte ar trebui s genereze sistemul?
ce categorie de indicatori ar fi necesar pentru reflectarea performanei activitilor?
care este volumul de informaii pe care sistemul ar trebui s-l nregistreze?
care este numrul de tranzacii ntr-o perioad de timp?
controalele incluse n sistem corespund regulilor de prevenire i detectare a erorilor i
fraudelor?
care este frecvena cererilor de informaii?
4. utilizatorii externi. Din ce n ce mai mult, se contureaz tendina ca organizaiile externe
s aib acces direct la informaiile din firm. De exemplu, funizorii pot accesa sistemul
pentru a verifica nivelul stocurilor i pentru a iniia o tranzacie de livrare a bunurilor
necesare firmei. Utilizatorii externi sunt cei mai dificil de identificat i analizat, pentru c
au caracteristici i particulariti din cele mai diverse i ale cror cerine se pot modifica
de la o perioad la alta. Totui, prin dezvoltarea noilor modele de afaceri (electronice,
mobile), utilizatorii externi au devenit un grup important pentru determinarea cerinelor.
5.4.1.2 Beneficiarii sistemului
Chiar dac inta principal a echipei de dezvoltare a sistemului o constituie satisfacerea
nevoilor informaionale 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
derulrii proiectului sau este proprietarul sistemului. n multe cazuri, beneficiarul este acelai
cu grupul utilizatorilor de la nivelul conducerii strategice, pn la cel operaional. Totui, el
poate fi reprezentat i de un grup distinct, cum ar fi un consiliu de administraie, 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 evoluia i
rezultatele proiectului. Beneficiarul sau reprezentantul acestuia din comitetul de iniiativ sau
coordonare a proiectului aprob trecerea la urmtoarea etap de dezvoltare i asigur
finanarea, n continuare, a proiectului, atunci cnd el este i finanator (total sau parial).
5.4.1.3 Personalul tehnic
Dei personalul tehnic nu este ncadrat n categoria utilizatorilor, el poate afecta cerinele
sistemului. n aceast categorie sunt inclui cei care stabilesc i asigur ntreinerea i
extinderea infrastructurii informatice a firmei. De obicei, ofer recomandri n privina
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 cnd sunt necesare
informaii privind componentele tehnice ale sistemului.
*
* *
Pentru a nelege abordarea cerinelor, din perspectiva diferitelor persoane interesate de
implementarea sistemului, vom analiza, n caseta 5.4, cazul sistemului de gestiune a clienilor
de la firma ABC.
Caseta nr. 5.4 Stakeholder-ii sistemului de gestiune a clienilor de la firma ABC
La ABC, utilizatorii operaionali ai noului sistem sunt reprezentai de agenii de vnzri care
preiau telefonic comenzile i de cei care introduc comenzile primite prin pot. Ei au diferite
perspective asupra sistemului i a ceea ce trebuie s fac pentru desfurarea activitilor zilnice.
Agenii de vnzri ce preiau comenzile telefonic sunt interesai de informaiile despre produsele
existente n stoc pentru a confirma disponibilitatea lor i pentru stabilirea datei de livrare. Cei care
preiau comenzile primite prin pot discut despre posibilitatea scanrii lor pentru eliminarea
introducerii acestora de la tastatur. Salariaii de la depozite au nevoie de informaii privind comenzile
care au fost livrate, care urmeaz a fi livrate, ca i posibilitatea accesrii on-line a informaiilor privind
comenzile de livrat, emiterea facturilor pentru ncrcarea produselor n loturile pentru transport.
Patronescu i Patroneasca, n calitatea lor de top-manageri, sunt interesai de obinerea rapoartelor
privind produsele comandate i livrate, determinarea tendinelor pentru fiecare sezon, pentru c n
domeniul lor de activitate este important s se identifice din timp tendina modei, pentru a se adapta
rapid sau pentru a renuna la unele produse, dac acestea nu mai sunt cerute de pia.
Dezvoltarea sistemului este finanat n parte din fonduri interne, dar i prin obinerea unei linii de
credit de la banc. ABC are deschis o linie de creditare pe termen scurt, dar, pentru c proiectul
presupune o investiie de durat, s-a obinut o linie de credit pe termen lung, ceea ce nseamn c banca
(finanatorul) va fi interesat de succesul proiectului. n acest caz, echipa trebuie s identifice care sunt
formatele pentru situaiile financiare pe care banca ar dori s le primeasc n timpul exploatrii i
ntreinerii sistemului, pn 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 dispoziie informaii
privind diferite categorii de cerine pe care noul sistem trebuie s le satisfac.
Revenind la structura organizatoric a firmei ABC (din caseta 5.1, capitolul 5), poziiile
evideniate prin culoarea verde indic top managerii i managerii de mijloc ce vor fi inclui n calitate
de stakeholder-i n dezvoltarea sistemului (Preedinte, director distribuie, director marketing i vnzri,
director economic, director vnzri cu amnuntul, ef birou promovare/publicitate, ef birou cataloage,
ef birou comenzi telefonice, ef linii de producie, ef depozite/livrare, contabil ef, director
departament informatic, ef birou dezvoltare sisteme, ef birou ntreinere sisteme).
n determinarea cerinelor, o importan deosebit o are identificarea persoanelor care pot

s ofere detalii eseniale. Cerinele sunt incomplete dac utilizatorii, beneficiarii, organismele
externe sau personalul tehnic nu sunt consultai n momentul culegerii informaiilor. De cele
mai multe ori, managerul de proiect este cel care ntocmete lista utilizatorilor ce trebuie
implicat n definirea cerinelor, iar pe msura desfurrii activitii, lista poate fi completat i
cu ali salariai ce dein poziii cheie.
Problema cea mai dificil o constituie modul n care echipa proiectului stabilete aceste
persoane. Procesul ncepe cu studierea scopului noului sistem, dup care se analizeaz cu
atenie persoanele care ar putea solicita informaii de la noul sistem. Este momentul n care e
mai bine s se includ mai multe persoane, dect s se omit surse importante pentru
identificarea cerinelor.
Totui, pentru determinarea cerinelor, persoanele implicate nu reprezint singura surs de
identificare. Echipa proiectului poate s se asigure c a folosit toate sursele posibile plecnd de
la alocarea resurselor umane din etapa de planificare a proiectului, construind un tabel cu
metodele de culegere a informaiilor, cine i cnd va realiza activitatea6. Astfel, analiza
cerinelor va avea ca rezultat seturi de documentaii cu informaiile colectate.
ntreaga documentaie din tabel poate fi folosit pentru dezvoltarea matricei
funcii/componente a sistemului informaional. De exemplu, dac sistemul curpinde baze de
date, module de generare a rapoartelor, interfee Web, va fi construit cel puin cte o astfel de
matrice pentru fiecare dintre ele. Unele surse informaionale sunt mai potrivite dect altele
pentru furnizarea anumitor cerine.
5.4.2 Tipuri de cerine
n timpul analizei, cerinele pot fi grupate n trei mari categorii, n funcie de percepia 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 Practioners Approach. European Adaptation, Fifth Edition, McGraw
Hill, London, 2000, pp. 273-274.
cerine normale (obligatorii), prezentate de analist n timpul ntlnirilor cu utilizatorii,

considerate ca fiind obinuite pentru un sistem care se dezvolt. Exemple de astfel de
cerine se refer la tipurile i formatele de ecrane pentru culegerea datelor, prezentarea
funciilor de prelucrare specifice noului sistem, descrierea performanelor pe care le poate
asigura noul sistem;
cerine dorite de utilizatori, considerate implicite pentru un sistem, motiv pentru care
utilizatorii nici nu mai consider necesar prezentarea lor atunci cnd sunt ntrebai. ns,
neonorarea acestora poate determina o puternic nemulumire. Exemple de astfel de cerine
ar putea fi descrierea interfeelor-utilizator, corectitudinea i sigurana prelucrrilor,
instalarea lejer a aplicaiilor etc.;
cerine surpriz, care vin n ntmpinarea ateptrilor utilizatorilor i ofer o mare
satisfacie atunci cnd sunt prezentate de ctre analist. Exemple: posibilitatea de a avea la
dispoziie utilitare incluse n aplicaia nou, care, n mod normal, sunt specifice softului de
sistem, disponibilitatea sistemului pentru configurarea de ctre utilizator a propriilor
rapoarte, pe baza instruciunilor clar definite n cadrul aplicaiei.
Din punct de vedere al cerinelor urmrite n etapele urmtoare de dezvoltare a
sistemului, de ctre membrii echipei de dezvoltare, se pot identifica patru mari categorii de
cerine, i anume:
1. cerine funcionale;
2. cerine nefuncionale sau tehnice;
3. cerine privind managementul proiectului;
4. cerine economice.
5.4.2.1 Cerinele funcionale
Aceast categorie reflect necesitile de modificare a unor funcii existente sau de
dezvoltare a unora noi. Cerinele funcionale sunt oferite, de cele mai multe ori, de ctre
utilizatorii finali.
Cerinele funcionale sunt activitile pe care sistemul trebuie s le desfoare, adic
funciile, procesele, procedurile de prelucrare, ca rspuns la operaiunile economice care au
loc8. De exemplu, dac se dezvolt un sistem de salarizare, el ar putea include funcii cum sunt:
calculul sumei de plat, pregtirea fluturailor, calculul impozitului pe venit, actualizarea
informaiilor despre salariai, obinerea fielor fiscale etc. Cerinele funcionale se determin
plecnd de la principalele componente ale sistemului, i anume9:
1. intrri prezentarea unui exemplar din fiecare intrare (document surs, ieirea altui
sistem), descrierea coninutului, sursei i a persoanei responsabile cu preluarea lor,
momentul culegerii;
2. prelucrri descrierea tuturor proceselor de prelucrare ale noului sistem, respectiv ce va
face sistemul i de ctre cine va fi folosit;
3. ieiri crearea unui exemplar din fiecare ieire a sistemului, descrierea scopului,
frecvenei, destinaiei i stabilirea momentului generrii;
4. date elementare definirea datelor elementare (atributele intrrilor, ieirilor sau locurilor
de stocare) din perspectiva numelui, dimensiunii, formatului, sursei i semnificaiei;
5. structuri de date reprezentarea modului n care datele elementare vor fi organizate din
punct de vedere al nregistrrilor logice;
6. documentaie descrierea modului de exploatare i ntreinere a sistemului;
7. restricii definirea constrngerilor legale de care trebuie s se in cont n funcionarea
sistemului, din perspectiva prelucrrilor, intrrilor i ieirilor;
8. controale definirea procedurilor de control, prin care se vor asigura corectitudinea i
ncrederea n date, prelucrri i informaii.
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, cerinele funcionale sunt bine documentate (regulile i procedurile

existente pentru desfurarea activitilor economice) i sunt mult mai uor de identificat i
descris. Un exemplu ar putea fi Toi salariaii trebuie s completeze un formular n care s fie
nregistrate informaiile necesare sistemului de salarizare, cum ar fi ora intrrii/ieirii n/din
unitate, cantitatea de produse obinut, activitile prestate etc..
n schimb, sunt unele situaii cnd 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 salariailor pentru promoiile speciale adugate la comenzile preluate de la
clieni. Din aceast formulare se ridic o serie de ntrebri: Promoiile speciale sunt cele care
reflect produsele complementare vndute de agenii de vnzri? 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 ctre manageri, fr
ns s existe vreun document care s ateste existena lor, iar includerea n setul de cerine
funcionale depinde de managerii respectivi, dac i aduc aminte s le menioneze.
Descoperirea regulilor de acest gen este esenial pentru proiectarea final a sistemului, pentru
c e posibil ca noul sistem s nu reflecte cele mai importante cerine, cu efecte negative asupra
activitilor economice desfurate n firm.
Plecnd de la aceste consideraii, pot fi amintite cele mai importante cerine pentru noul
sistem:
cerine de modificare a circuitului informaional, n sensul eliminrii sau adugrii de noi
fluxuri informaionale, n funcie de nevoile reale ale utilizatorilor i de cele de prelucrare
ale sistemului, ca rezultat al apariiei unor noi reguli sau activiti economice;
cerine de modificare a structurii datelor, n funcie 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 interfee;
cerine privind datele elementare, prin adugarea, eliminarea sau modificarea celor
existente, plecnd de la nevoile de generare a unor noi ieiri, de preluare i memorare a unor
noi date de intrare;
cerine de schimbare a anumitor proceduri de prelucrare, prin adugarea sau eliminarea
unor procese, pornind de la cerinele de informare ale utilizatorilor sau de integrare cu alte
sisteme.
Cerinele funcionale se regsesc, cel mai adesea, n reprezentarea sistemului cu ajutorul
diferitelor modele construite n timpul analizei.
5.4.2.2 Cerinele nefuncionale
Prin cerinele nefuncionale, numite i tehnice, sunt urmrite mai multe obiective
operaionale legate de mediul hardware i software n care urmeaz s funcioneze noul sistem.
Analistul determin aceste cerine, ntr-o anumit msur, plecnd de la cele funcionale.
Cerinele nefuncionale specific proprietile sistemului, cum ar fi restriciile de
implementare, performana, dependena de o anumit platform de dezvoltare,
mentenabilitatea, extensibilitatea, interoperabilitatea i sigurana exploatrii. Sigurana se
refer la caracteristici cum ar fi: disponibilitatea, acurateea, timpul dintre cderile sistemului,
defectele la 1000 de linii de cod, defectele pe clas de prelucrri. Cerinele de performan fac
trimitere la eficiena cu care se execut procesele de prelucrare, cum ar fi viteza, timpul de
rspuns i memoria folosit.
Dintre cele mai importante cerine formulate de echipa tehnic pot fi amintite:
disponibilitatea datelor, confidenialitatea i integritatea lor;
viteza i timpul de rspuns pentru obinerea unei informaii;
modul de organizare i stocare a datelor;
calitatea informaiilor de ieire, din punct de vedere al momentului obinerii lor, al

formei de prezentare i al modului de transmitere;
introducerea unor noi tehnologii informaionale, cum ar fi nlocuirea sistemului de
prelucrare de tip file/server cu arhitectura client/server, trecerea la prelucrrile de date
bazate pe tehnologia orientat-obiect, implementarea unei soluii de comer electronic
.a.
platformele de lucru privind sistemele de operare, sistemele de gestiune a bazelor de
date, softul de reea, trecerea la cloud computing etc.
De obicei, cerinele nefuncionale sunt prezentate n etapa de analiz sub form narativ,
urmnd a fi detaliate n timpul proiectrii sistemului.
5.4.2.3 Cerine privind managementul proiectului
Cerinele privind managementul proiectului sunt utile n vederea determinrii nevoilor
proiectului pe toat durata lui, respectiv:
resurse necesare pentru desfurarea activitilor n condiii normale i pentru
finalizarea la timp a proiectului, inclusiv momentele n care ele trebuie s fie alocate
sau realocate;
planul comunicrilor ntre membrii echipei de dezvoltare, ntre acetia i beneficiarii
sistemului etc.;
gestiunea modalitilor n care proiectul poate fi coordonat, inclusiv politicile,
procedurile i practicile cele mai bune pentru managementul proiectului.
Cele mai multe dintre aceste cerine sunt furnizate de ctre echipa de specialiti n
dezvoltarea sistemului.
5.4.2.4 Cerine economice
Cerinele economice sunt cele prin care se identific scopul i viziunea general a
proiectului, inclusiv scopul, obiectivele firmei, cerinele privind creterea eficienei
activitilor acoperite prin sistemul dezvoltat, rata de recuperare a investiiei i veniturile pe
care le genereaz.
Tot n aceast categorie se ncadreaz cerinele de reorganizare a firmei, cum ar fi
nfiinarea de noi locuri de munc, restructurarea altora, eliminarea unor funcii sau posturi,
astfel nct cerinele informaionale ale utilizatorilor s poat fi satisfcute. Uneori, se solicit
chiar o modificare esenial a tipului de structur organizatoric, aa cum se ntmpl n cazul
implementrii sistemelor ERP.
Cerinele economice sunt formulate att de ctre utilizatorii finali i conducerea firmei,
ct i de ctre specialitii n dezvoltarea sistemelor.
*
* *
Produsul final al etapei de analiz l reprezint specificaia de analiz sau specificaia
cerinelor, o formalizare a rezultatelor obinute prin activitile desfurate. Scopul l
constituie comunicarea rezultatelor tuturor celor interesai, servind i ca reper pentru etapele
urmtoarele, de proiectare i implementare. Aadar, descrierea precis este preferat de cele
mai multe ori, dar trebuie s se in cont de faptul c specificaia trebuie s fie uor de neles
i de ctre utilizatorii sistemului, ceea ce nseamn apelarea la un limbaj natural i la o serie de
imagini, mult mai uor de perceput. Pentru utilizatori, specificaia are rolul de definire a
funcionalitii sistemului, iar pentru proiectani reprezint punctul de start al etapei de
proiectare.
Utilizatorii sunt mulumii dac li se ofer un document care vorbete pe limba lor,
limbaj care este folosit n domeniul lor de activitate. Proiectanii, pe de alt parte, solicit o
specificaie 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 specificaiilor n
funcie de cei crora li se adreseaz.
Specificaia de analiz trebuie vzut ca un raport la fel de important precum cel care
prezint, de exemplu, performanele nregistrate de firm ntr-un an, pe baza cruia se iau
deciziile privind continuarea activitilor eficiente i luarea msurilor corective pentru cele
care nu au nregistrat rezultatele scontate. n acelai mod, pe baza raportului de analiz se ia
decizia de continuare a proiectului de dezvoltare a sistemului, se iau msuri de mbuntire a
modului de utilizare a resurselor sau de ncadrare n bugetul i timpul alocat. De aceea, din
specificaiile de analiz trebuie s rezulte foarte clar scopul i obiectivele sistemului, metodele
folosite pentru studierea sistemului existent i determinarea cerinelor, rezultatele obinute,
inclusiv modelele construite, variantele de proiectare i recomandrile analitilor, concluziile.
Rezumat
n timpul cercetrii i stabilirii cerinelor se vor obine detaliile privind procesele i activitile
desfurate la nivelul sistemului curent, pe msura intervievrii, observrii utilizatorilor sau analizei
documentelor i procedurilor de lucru existente. n acest mod, se ncearc obinerea unei imagini ct mai
clare i obiective asupra problemelor crora trebuie s le rspund noul sistem. De asemenea, se
urmrete identificarea modalitilor n care pot fi atinse obiectivele economice cu ajutorul tehnologiilor
informaionale, pe care utilizatorii, obinuii 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 desfurarea operaiunilor economice, ceea ce face mult mai facil acceptarea schimbrii
sistemului.
Principalele elemente supuse analizei n timpul studierii sistemului existent sunt: informaiile de
ieire obinute din actualul sistem; datele de intrare n sistem; modul n care sunt stocate, memorate i
pstrate 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 declaneaz 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 tranzacii ce trebuie avute n vedere cnd se analizeaz
un sistem: externe, temporale, de stare. n urma studierii sistemului se pot determina ce funcii se
pstreaz i care sunt eliminate, ce intrri i ieiri mai sunt necesare, care sunt componentele generatoare
de probleme i cum ar putea fi ele rezolvate.
Activitatea de determinare a cerinelor este considerat una din cele mai complexe din faza de
analiz, datorit dificultii de evaluare a necesarului de informaii. n unele situaii, utilizatorii pot fi
subiectivi cnd sunt abordai pe o astfel de tem, iar n alte situaii nu tiu care sunt informaiile 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 acetia, pn la studierea documentelor primare, a rapoartelor, a
procedurilor folosite.
Principala surs de informaii privind cerinele funcionale 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, cerinele pot fi grupate n trei mari categorii, n funcie de percepia pe care o au
utilizatorii asupra celor prezentate de analist, i anume: cerine normale, cerine dorite de utilizatori,
cerine surpriz.
Din punct de vedere al cerinelor urmrite n etapele urmtoare de dezvoltare, de ctre membrii
echipei proiectului, se regsesc urmtoarele tipuri: cerine funcionale, cerine nefuncionale sau tehnice,
cerine privind managementul proiectului, cerine economice.
Produsul final al etapei de analiz l reprezint specificaia de analiz sau specificaia cerinelor, o
formalizare a rezultatelor obinute n aceast faz.
1. Care sunt elementele supuse cercetrii n timpul studierii sistemului existent?
2. Ce obiective se urmresc prin analiza sistemului existent?
3. Enumerai aspectele/obiectivele prezentrii detaliate a ieirilor sistemului curent.
4. Prin ce se verific utilitatea informaiilor coninute de ieirile sistemului curent?
5. Ce situaii trebuie abordate distinct n cazul analizei datelor de intrare?
6. Enumerai elementele ce sunt supuse analizei din punct de vedere al documentelor de intrare sau
documentelor surs.
7. Ce se urmrete la analiza intrrilor provenite din aplicaiile altor sisteme?
8. Ce se evideniaz prin analiza modului de stocare, accesare i pstrare a datelor?
9. Enumerai elementele urmrite prin studierea prelucrrilor din sistemul curent.
10. Care sunt detaliile ce trebuie evideniate n timpul analizei proceselor de prelucrare?
11. Definii evenimentele pe baza crora se identific funciile de prelucrare din sistem.
12. Descriei categoriile de evenimente luate n considerare la analiza sistemului.
13. Descriei cauzele problemelor din timpul determinrii cerinelor informaionale.
14. Care sunt cerinele ce pot fi identificate n timpul etapei de analiz, n funcie de percepia
utilizatorilor?
15. Care sunt principalele tipuri de cerine de identificarea crora depinde derularea urmtoarelor etape
de dezvoltare a sistemului?
16. Enumerai principalele categorii de cerine funcionale ale unui sistem.
17. Care sunt principalele categorii de persoane care stau la baza identificrii cerinelor noului sistem?
18. Care sunt principalele surse de identificare a cerinelor?
Probleme de echip
1. Firma Turism pentru Studeni (TS) face rezervri pentru tabere studeneti la diferite agenii de
turism. n timpul semestrului de var, ageniile trimit firmei informaii despre hotelurile disponibile,
camerele i capacitatea lor, preul pentru petrecerea unei sptmni din vacana de iarn. Fiecare
agenie prezint oferte pentru un numr diferit de sptmni n fiecare sezon, precum i preuri
diferite pentru camere, n funcie de sptmna pentru care se face rezervarea. De obicei, ageniile
ofer o mare varietate de camere, cu capaciti diferite, astfel nct studenii pot s-i rezerve
camera pe care o doresc. Familiile pot rezerva apartamente sau camere de dou persoane.
n septembrie, firma Turism pentru Studeni genereaz o list a ageniilor, sptmnile
disponibile, preul camerelor, list pe care o transmite secretariatelor de la faculti. Cnd un grup
de studeni depune o cerere de rezervare pentru o anumit sptmn i o anumit agenie, TS
atribuie studenilor camere cu suficiente locuri i transmite fiecrui student o not de confirmare. Cu
o sptmn nainte de cea pentru care au fost fcute rezervrile, TS trimite fiecrei agenii lista
studenilor pentru care s-au fcut rezervrile pe fiecare camer. Studenii fac plata la hotelurile unde
i-au fcut rezervrile atunci cnd ajung. Ageniile trimit comisioanele direct sistemului contabil al
firmei TS, sistem separat de cel care ine evidena rezervrilor.
Se cer:
a. identificarea evenimentelor la care sistemul de rezervri de la TS trebuie s asigure declanarea
prelucrrilor;
b. crearea unui tabel complet al evenimentelor, care s conin evenimentul, declanatorul, sursa,
aciunea sistemului, rspunsul, destinaia. Atenie la evenimente, pentru a nu le surprinde pe
cele care sunt declanate pentru a fi prelucrate de sistemul contabil al TS sau al ageniilor.
2. Casa este o societate imobiliar cu mai multe birouri. Sistemul de eviden a imobilelor ofer
informaii pe care agenii imobiliari le folosesc pentru a-i ajuta n vnzarea de locuine. n timpul
lunii, agenii listeaz casele disponibile pentru vnzare, prin contractarea lor cu proprietarii. Agenii
sunt arondai la un birou imobiliar, care transmite informaiile colectate ctre sistemul centralizat al
societii. De aceea, orice agent dintr-o anumit zon poate obine informaiile de care are nevoie.
Informaiile incluse n liste cuprind adresa, anul construirii, suprafaa, numrul de dormitoare,
numrul de bi, numele proprietarului, numrul de telefon, preul cerut, starea imobilului (vndut sau
disponibil). n orice moment al lunii, un agent poate contacta serviciul centralizat pentru a obine
listele cu imobilele ce corespund cerinelor unui cumprtor. Astfel, sunt oferite informaii
suplimentare sau ar putea fi contactat direct proprietarul pentru a stabili o ntlnire ca s fie vzut
imobilul. De dou ori pe lun (pe 15 i pe 30 ale lunii), serviciul centralizat genereaz un registru ce
conine informaiile despre toate imobilele nregistrate i incluse n listele cu descrierea fiecrui
imobil, registru transmis agenilor imobiliari. Muli ageni doresc acest registru pentru c este mult
mai uor de utilizat, avnd la dispoziie informaii despre toate imobilele i nu numai cele care
rspund cerinelor unui anumit cumprtor. Uneori, agenii i proprietarii decid modificarea
informaiilor pe o anumit list, cum ar fi reducerea preului, corectarea unor informaii privind
imobilul sau pentru a indica vnzarea imobilului. Birourile imobiliare transmit aceste modificri
ctre serviciul centralizat atunci cnd agenii vor acest lucru.
Se cer:
a. Care sunt evenimentele crora trebuie s le rspund sistemul de eviden a imobilelor?
b. Realizarea unui tabel complet al evenimentelor.
c. Identificarea cerinelor funcionale i tehnice ale sistemului.
CAPITOLUL VI
Metode de culegere a cerinelor sistemului

Obiective:
Iniierea analitilor n arta intervievrii pentru a putea stabili ct mai exact ce date
sunt cerute de sistemul propus
Cunoaterea modalitilor de lucru cu chestionare pentru a se stabili cerinele sistemului
nelegerea avantajelor i dezavantajelor observrii activitilor prestate de ctre
angajai, a analizei documentelor firmei pentru a se afla care sunt cerinele sistemului
Aa cum s-a vzut din capitolele anterioare, obiectivul de baz al etapei de analiz const
n nelegerea funciilor economice i determinarea cerinelor 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. Cnd a fost lansat metodologia structurat, ca i alte metodologii,
analitii mai nti studiau i documentau sistemul existent, dup care ncercau s identifice
cerinele pentru cel nou pe baza caracteristicilor celui vechi. Pentru acea perioad, n vederea
determinrii cerinelor, se desfurau patru mari patru mari activiti:
identificarea proceselor i activitilor fizice ale sistemului existent;
extragerea, din punct de vedere logic, a funciilor corespunztoare proceselor fizice;
stabilirea, din punct de vedere logic, a funciilor ce urmeaz a fi incluse n noul sistem;
definirea cerinelor fizice de prelucrare pentru noul sistem.
Dup unii autori, unul din marile dezavantaje ale unei astfel de abordri l constituie
timpul mare alocat activitii de analiz, o adevrat problem pentru c, adesea, dezvoltarea
sistemului const doar n automatizarea celui existent i, ca atare, nu conta ct de ineficient era
cel vechi, pentru c oricum vechile proceduri erau nlocuite.
n prezent, ntr-o lume a competitivitii, multe firme urmresc implementarea noilor
tehnologii, n vederea creterii avantajelor lor strategice, reproiectnd n totalitate procedurile
interne pentru a beneficia de avantajele aduse de acestea. Rmne la fel de important
stabilirea setului corect i complet al cerinelor 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 analitii fac apel la o abordare mai rapid,
prin echilibrarea procesului de revizuire a funciilor curente i a celui de identificare a
cerinelor noului sistem. De aceea, atenia n timpul etapei de analiz se concentreaz pe
dezvoltarea setului de cerine logice ale sistemului.
Analitii studiaz sistemul curent numai atunci cnd trebuie s neleag cerinele
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. Aadar, analistul va trebui s
demonstreze o deplin stpnire de sine.
Dezvoltarea modelului logic al noului sistem are loc pe msur ce se culeg informaiile
despre cerinele sistemului, modelarea fizic a acestuia (cum va fi construit sistemul) rmnnd
o sarcin a etapei urmtoare, proiectarea. De baz sunt informaiile care permit construirea
modelului logic al noului sistem, existnd trei ntrebri majore asupra crora ar trebui s se
orienteze desfurarea activitii de studiere a sistemului i de determinare a cerinelor:
1. Care sunt procesele i funciile economice?
Se urmrete obinerea unei liste atotcuprinztoare a proceselor economice. n majoritatea
cazurilor, utilizatorii sunt cei care ofer informaiile, plecnd de la ce se ntmpl n vechiul
sistem, astfel c analitii trebuie s discearn cu atenie care sunt funciile fundamentale ce se
vor pstra i ce trebuie s se elimine sau s se adauge pentru mbuntirea sistemului.
METODE DE CULEGERE A CERINELOR SISTEMULUI 111
De exemplu, personalul de vnzri poate s indice c primul lucru pe care l realizeaz

cnd primesc o comand este s verifice istoricul tranzaciilor 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 cumprturilor, dac este un client fidel etc. n noul
sistem, e posibil ca aceast funcie s nu mai fie realizat de personalul de vnzri, pentru c
poate fi efectuat automat, cu ajutorul diferitelor proceduri de prelucrare incluse n aplicaia
sistemului. Funcia rmne o cerin a sistemului, dar realizarea ei nu mai este o
responsabilitate a personalului de vnzri, ci a aplicaiei care se va dezvolta.
2. Cum sunt realizate procesele economice?
Se face trecerea de la studierea sistemului existent la analiza cerinelor pentru cel nou.
Atenia se concentreaz acum asupra modului n care sistemul ar trebui s sprijine procesele
economice, astfel c primele dou ntrebri sunt legate ntre ele pentru a descoperi cerinele
informaionale. Utilizatorii vorbesc, n majoritatea cazurilor, despre vechiul sistem, dar este
deosebit de important pentru analiti s mearg mai departe, astfel c trebuie s fie capabili s-i
ajute pe utilizatori s prevad i neleag abordri noi i eficiente ale modului n care vor fi
realizate procesele economice n noul sistem, cu ajutorul unor noi tehnologii.
3. Care sunt informaiile necesare desfurrii proceselor economice?
Se pornete de la a doua ntrebare, prin definirea informaiilor specifice pe care noul
sistem trebuie s le ofere. Ultimele dou ntrebri formeaz punctul de plecare n definirea i
descrierea cerinelor, cuvntul magic fiind detaliul, n sensul c trebuie s se neleag n
detaliu fiecare aspect, pentru a se identifica i dezvolta soluia corect.
Valoarea unui analist, n aceste condiii, nu este dat de cunotinele pe care le deine
asupra modului de dezvoltare a unui anumit model sau despre un anumit limbaj de programare,
ci de abilitatea de a analiza i rezolva problemele informaionale. Cu alte cuvinte, se are n
vedere culegerea informaiilor pentru determinarea unor cerine reale, complete i corecte, cu
resurse minime i cu alocarea unui timp ct mai redus de ctre utilizatori. S-au dezvoltat mai
multe metode de culegere a informaiilor privind cerinele sistemului, ele fiind folosite, de
multe ori, n combinaie, pentru creterea eficienei i productivitii etapei de analiz.
Timpul necesar culegerii informaiilor este imens, iar cheltuielile pe msur. Sloganul
care circul printre analiti analysis paralysis (analizele paralizeaz) are un smbure de
adevr, referindu-se la excesele de zel din aceast faz.
Ca efect al tendinelor de mrire 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 puine
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.
Totui, nu trebuie s se ajung la concluzia c analiza, chiar i a sistemului existent, nu mai
este necesar. Ea rmne piesa de baz n ciclul de dezvoltare, doar c tehnicile i
instrumentele cu care se realizeaz permit reducerea timpului alocat acestei etape.
Metodele tradiionale de colectare a cerinelor sistemului sunt:
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 informaiile pentru exercitarea sarcinilor de serviciu;
studierea documentaiei firmei pentru a se cunoate coninutul rapoartelor, al
politicilor, al regulamentelor, precum i direciile spre care se ndreapt prelucrarea
datelor.
6.1 Intervievarea
Intervievarea este de departe una din cele mai bune metode de a nelege funciile i
regulile economice, dar i activitatea cea mai consumatoare de timp i alte resurse. Este o cale
relativ uoar prin care utilizatorii pot s-i exprime inteniile n legtur cu sistemul dorit, cu
ajutorul propriului limbaj, i pot controla perioada de timp pe care o aloc interviului.
Interviul, potrivit definiiei date de Charles J. Stewart i William B. Cash Jr. 1, este
procesul comunicrii diadice, de stabilire a unei relaii cu o finalitate precis, predeterminat,
proces conceput pe alternana rolurilor i care implic formulri de ntrebri i obinerea de
rspunsuri.
Formularea de ntrebri i obinerea rspunsurilor constituie procesele eseniale ale
interviului. Puine sunt interviurile care s nu necesite o structurare prealabil a ntrebrilor.
6.1.1 Tipuri i utilizri 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 urmeaz2:
1. Oferirea de informaii se refer la interviurile folosite pentru orientarea angajailor sau
membrilor organizaiilor sau pentru formarea, instruirea sau antrenarea lor ntr-o anumit
activitate. Se ncadreaz aici:
orientarea;
formarea, instruirea, antrenarea;
prezentarea de manuale;
prezentarea concluziilor unor aciuni.
2. Colectarea de informaii include interviurile destinate obinerii datelor despre fapte,
opinii, sentimente, atitudini, motivarea unor aciuni sau tendine comportamentale, n
urmtoarele situaii:
studii (anchete) i exprimarea prin vot;
la prsirea locului de munc;
cu scop de cercetare;
investigaii de asigurare, ale poliiei .a.;
medicale, psihologice, cazuri .a.;
jurnalistic.
3. Selecia este utilizat pentru filtrarea, recrutarea i angajarea unor persoane sau
primirea de noi membri ntr-o organizaie sau echip.
4. Problemele referitoare la comportamentul intervievatului se refer la interviurile de
apreciere pentru evaluarea comportamentului, performanelor sau progreselor nregistrate,
pentru izolarea unor persoane din anumite colective, disciplinarea persoanelor, precum i
pentru consilierea n vederea rezolvrii unei probleme.
5. Problemele referitoare la comportamentul celui ce ia interviul se refer la interviurile
prin care o persoan primete o reclamaie de la un beneficiar, o plngere de la un angajat sau o
sugestie pentru rezolvarea unei situaii.
6. Rezolvarea problemelor conine interviurile care se ocup nu de probleme personale ale
celor dou pri ale interviului, ci de una care le preocup pe amndou, cum ar fi cderi ale
sistemelor, pierderea clienilor, lipsa ncrederii n sistem .a., ncadrndu-se aici:
discutarea unor probleme de interes comun;
primirea de soluii 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 gndire, de a

percepe i/sau aciona al celui intervievat, avnd ca exemple:
vnzarea produselor sau prestarea serviciilor;
recrutarea de noi membri;
gsirea de fonduri i soluii de dezvoltare;
schimbarea modului n care simte, gndete sau acioneaz o parte.
De regul, interviul urmeaz chestionarului, cererilor de angajare sau unor rspunsuri n
scris. Rezultatele obinute depind de instruirea celui ce l iniiaz, dar i de credibilitatea
prilor.
6.1.2 Paii intervievrii

Pentru ca un interviu s dea rezultate bune, se cuvine s fie realizat n concordan cu
unele orientri-cadru, cum sunt:
1. Planificarea interviului, constnd n:
Pregtirea intervievailor: stabilirea momentului interviului, a subiectului de discuie .a.
Pregtirea unei liste de control a agendei de lucru, precum i a ntrebrilor.
2. Ascultarea cu atenie i consemnarea lucrurilor importante (dac este permis, se poate
efectua i nregistrarea interviului).
3. Revizuirea consemnrilor fcute n cel mult 48 de ore de la interviu.
4. Meninerea strii de neutralitate.
5. Cutarea mai multor puncte de vedere.
De aceea, se consider c etapele de baz ale unui interviu sunt: planificarea (pregtirea)
interviului, desfurarea propriu-zis, ultima fiind finalizarea i stabilirea activitilor
postinterviu.
n desfurarea 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 creia se pot evita unele omisiuni n ceea ce privete obiectivele i
ntrebrile stabilite iniial.
SCHEMA DERULRII INTERVIULUI
INTERVIEVAT: OPERATOR INTERVIU:
Numele persoanei intervievate, funcia/ Numele realizatorului interviului: Intervievescu i
poziia pe care o deine: Vnztorescu, ntrebrescu
director departament marketing-vnzri
LOC/MODALITATE: DATA STABILIT: 7 octombrie 2005
Localizare, nr. telefon: Sala de protocol, Ora de ncepere: 9.00
221133 Ora terminrii: 9.45
ntlnire, convorbire telefonic: ntlnire
OBIECTIVE: DE AFLAT:
Determinarea regulilor de prelucrare a Cine poate primi comisioane pentru vnzri
comisioanelor pentru vnzri Care este baza de calcul a comisioanelor, respectiv
procentele care se acord
Cum se calculeaza comisioanele n cazul refuzului
parial de produse
Care sunt limitele de acordare a comisioanelor
Care sunt excepiile
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: ntrebri 5 minute

Tema 2: ntrebri 7 minute

Sinteza problemelor majore 2 minute
ntrebri ale intervievailor 5 minute
nchiderea operaiunii 1 minut
OBSERVAII GENERALE:
Intervievatul pare extrem de ocupat probabil c este necesar un telefon n zilele urmtoare pentru a
continua ntrebrile care au rspunsuri laconice.
Calculatorul este nchis fie c nu este un utilizator permanent al PC-ului, fie c prelucreaz date cu
regim special i nu dorete s le expun pe ecran.
PROBLEME NEREZOLVATE, DOMENII NEACOPERITE:
Are nevoie de urmrirea vnzrilor din ultimii patru ani. A pus problema bunurilor refuzate de
clieni, dar n-a fost timp suficient pentru lmuriri suplimentare. Mai este necesar s citeasc politicile
firmei privind acordarea comisioanelor.
Aspectele nerezolvate: returnrile de produse i comisioanele, respectiv comisioanele acordate pentru
promoiile speciale.
Data i ora urmtoarei ntlniri: 24 octombrie 2005, la 9.00
Fig. 6.1 Ghid de derulare a interviului
Tipurile de ntrebri3 posibil de utilizat n structura unui interviu sunt redate n tabelul 6.3.
Sfaturi finale pentru operatorii interviului
Indiferent de tipul ntrebrilor, nu le formulai astfel nct s poat conduce la
rspunsuri convenabile sau condamnabile.
Ascultai cu atenie tot ce se afirm n timpul interviului.
Dup terminarea interviului, n cel mult 48 de ore, sintetizai rezultatele la care ai
ajuns.
n timpul interviului, nu v pronunai asupra a ceea ce va fi cu siguran n viitor.
Scade rolul interviului.
Abordai sistemul analizat din mai multe perspective (a potenialilor utilizatori, a
utilizatorilor unor sisteme similare, a celor afectai de schimbarea sistemului, a
managerilor, a controlorilor, a informaticienilor).
Indiferent de stilul folosit la intervievare, nu uitai c politeea joac rolul cel mai
important.
Chiar dac ai efectuat multe interviuri, de fiecare dat alctuii un plan de derulare a
urmtorului interviu.
Nu abuzai de drglenia (se poate citi i politeea) celui intervievat, prelungind cu
mult timpul planificat pentru derularea acestuia.
Nu ezitai s revenii cu un telefon scurt, nsoit de scuzele de rigoare, pentru a lmuri
ceva ce nu v este prea clar; nu improvizai rspunsuri n contul intervievailor.
3. Prelucrare dup colectiv FIMAN, Centrul de consiliere n cariera profesional Manual de nfiinare i operare,
Ed. Expert, Bucureti, 1997, pp. 94-97.
Tabel nr. 6.3 Tipuri de ntrebri 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
Servete strategia ntrzierea concluzionare
noastr rspunsurilor Acord asupra unei
propuneri
Rspuns Scurt Lung, dens Induce rspunsul Precizri asupra Alegere ntre dou
Interlocutorul subiectului posibiliti. Se
aprob sau nu omite o a treia sau
refuzul.
Suport ntrebri care Ce credei? tiai c? Dvs. ce prere Preferai sau
ncep cu Ce, Cine, Care este Ce gndii avei despre? ?
Unde, Cnd? opinia? despre?
De ce? Sperai s?
Avantaje Rapiditate, precizie Multe informaii Progreseaz dialogul Informaii suplimentare Orientare spre
Climat de Se introduc argumente, naintea rspunsului alegere, nu spre
ncredere avantaje noi Dirijarea dialogului obiectul ntrebrii
Ocolirea obieciunilor Refuzul propunerii
Dezavantaje Ascunde informaii Stimuleaz Rspunsul poate Poate prea o Totul se reduce la
tie interogatoriul vorbreii fi NU eschiv doar dou variante
6.2 Chestionarele
Spre deosebire de interviuri, chestionarele sunt mai puin costisitoare i, ntr-un timp
relativ scurt, pot oferi un volum mare de informaii necesare analizei sistemului. Cu ajutorul
chestionarelor, analitii 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 trasturile utilizatorilor.
Prin utilizarea chestionarelor se urmrete obinerea de detalii preliminare privind
cerinele informaionale ale diferitelor persoane interesate de sistem, ajutnd la identificarea
domeniilor ce necesit cercetri suplimentare cu ajutorul interviurilor, analizei documentelor i
al observrii. Chestionarele permit obinerea unor informaii de natur cantitativ, plecnd de
la ntrebri de genul: Ce formulare folosii pentru introducerea datelor despre clienii noi?,
n medie, ct 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 ntrebri de forma: Pe o scar de la 1 la 7, specificai ct de important este
disponibilitatea sistemului privind accesul la istoricul tranzaciilor cu clienii?. Astfel de
ntrebri direcioneaz persoanele chestionate s rspund numai la ntrebarea pus, fr s
lase loc de interpretri sau discuii.
Chestionarul este folosit cnd este necesar s se culeag informaii de la un numr mai
mare de persoane din cadrul organizaiei. El poate fi folosit cnd4:
persoanele importante pentru sistem sunt dispersate teritorial;
volumul informaiilor ce trebuie culese este relativ mic, dar exist foarte multe
persoane implicate n proiect;
este necesar o aciune de cercetare, nainte ca interviurile s aib loc, de exemplu
atunci cnd 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 cerinele sub form scris pentru o
4. Flynn, D. Information Systems Requirements: Determination & Analysis, 2nd Edition, McGraw Hill Companies,
London, 1998, p. 138.
serie de ntrebri deschise, pentru c procesul poate s le ia mai mult timp dect dac ar fi
rspuns acelor ntrebri prin intermediul unui interviu. De asemenea, chestionarul s-ar putea s
nu conin exact ntrebrile la care se ateptau s rspund pentru a-i specifica cerinele.
La prima vedere, chestionarele par a fi cea mai rapid modalitate de culegere a unui
volum relativ mare de informaii despre modul n care utilizatorii vd sistemul curent, despre
problemele cu care se confrunt n activitatea lor i despre ce se ateapt de la noul sistem.
Chiar dac este ntr-o anumit msur adevrat c se pot culege mai multe informaii ntr-un
timp mai scurt fa de interviu, elaborarea unor chestionare eficiente solicit un timp destul de
mare pentru pegtirea i conceperea lor. n primul rnd, este necesar s se stabileasc cu
claritate ce se dorete s se obin prin utilizarea sondajului pe baz de chestionar. De
exemplu, dac se ncearc s se identifice care este procentul de utilizatori ce prefer existena
unei pagini cu ntrebri frecvente (FAQs) ca mijloc de nvare a noilor aplicaii, un chestionar
ar fi cea mai adecvat tehnic. Dac ns se dorete s se analizeze detaliat procesul pe care l
parcurge un manager pentru luarea unei decizii, interviul ar fi o opiune mai bun.
Deoarece conceperea chestionarului este mai mult o art dect o tiin, specialitii s-au
strduit s-i prezinte experiena sub forma unor reguli, recomandate ndeosebi nceptorilor;
cei cu state vechi le pot utiliza drept elemente de comparaie pentru a-i evalua paii ntregii
proceduri. Din aceste motive, considerm de bun augur descrierea pailor parcuri pentru
conceperea unui chestionar n viziunea lui Gilbert Churchill, Jr.5, conform figurii nr. 6.3.
Pas 1 Identificarea informaiilor ce vor fi cutate
Pas 2 Stabilirea tipului de chestionar

i a metodei de administrare
Pas 3 Determinarea coninutului

fiecrei ntrebri
Pas 4 Stabilirea formei de redactare a

rspunsului pentru fiecare ntrebare
Pas 5 Formularea ntrebrilor
Pas 6 Stabilirea secvenei derulrii ntrebrilor
Pas 7 Stabilirea caracteristicilor

tehnice ale chestionarului
Pas 8 Reevaluarea pailor 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 informaii Mare (deoarece se pot folosi mai Medie spre joas (se folosesc
obinute multe canale) doar rspunsurile)
Personal angajat n Redus (n comparaie cu
Relativ numeros
operaiune interviurile)
Numr de persoane implicate Mic, dar posibilitatea de a avea Mare, dar numrul rspunsurilor
n operaiune (testate) toate rspunsurile este foarte mare primite poate fi foarte mic
Valoare cheltuieli Mare Moderat
Timp de pregtire Redus Mare
Timp de operare Mare Sczut-mediu
Timp de prelucrare final Mic Mediu-mare
Posibilitatea evitrii
Mare-foarte mare (dinamic) Mic (limitat)
nenelegerilor
Confidenialitate Respondentul poate s fie
Se cunoate intervievatul
necunoscut
Grad de reuit a operaiunii,
Mare Modest
prin implicarea prii testate
Procent de reuit a testului Mare-foarte mare Redus
6.3 Intervievarea grupurilor

Un inconvenient al aplicrii interviurilor i chestionarelor pentru colectarea cerinelor
sistemelor l constituie apariia unor contradicii aparente ntre datele colectate; reconcilierea
lor presupune intervenia analistului.
Multe neclariti pot fi lmurite prin alte interviuri sau convorbiri telefonice, ceea ce
constituie o activitate anevoioas i nu prea agreat de interlocutori, transformnd activitatea
de colectare a cerinelor sistemului ntr-una ineficient. Operaiunea salvatoare este cea a
intervievrii grupurilor. Printr-un interviu al grupului are loc intervievarea concomitent a unui
grup de persoane-cheie. Operaiunea se efectueaz de unul sau mai muli analiti, situaie n
care se realizeaz o mprire a sarcinilor: o persoan va avea rolul de operator al interviului,
alta va consemna rspunsurile obinute, n timp ce alte persoane pot avea rolul de urmrire a
unor probleme bine definite, mai specializate (una urmrete cererea de date, alta oportunitatea
i declanatorii evenimentului .a.m.d.).
Paii de parcurs pentru planificarea i desfurarea interviurilor de grup sunt:
determinarea obiectivelor proiectului pentru care se intervieveaz grupul i definirea
problemei;
specificarea obiectivelor aciunii care se va ntreprinde (ale interviului);
stabilirea obiectivelor/ntrebrilor la care vor rspunde participanii;
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 Explicaii
crt.
1 Mrimea Se consider c numrul optim al unui grup este de la 8 la 12 persoane. Mai
grupului puin de opt persoane nu asigur dinamica grupului, iar mai mult de 12
persoane pot s determine o serie de discuii neconcludente pentru problemele
puse n discuie.
2 Structura Grupul trebuie s fie omogen din punct de vedere al participanilor, pentru c
grupului n acest fel sunt evitate conflictele asupra unor probleme ce pot s aib
semnificaii diferite. Participanii grupului trebuie s fie analizai i selectai
pe baza anumitor criterii, care s asigure nivelul de coeziune. Participanii
trebuie s aib o anumit experien n ceea ce privete problemele puse n
discuie. 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 buturile rcoritoare trebuie s aib loc nainte de a ncepe interviul de grup,
dar poate fi realizat i n timpul lui.
4 Durata Dei interviurile de grup pot s dureze de la o or la trei ore, de cele mai
interviului multe ori ele se desfoar ntr-o or sau o or i jumtate. Aceast durat este
necesar pentru a stabili raportul cu participanii i de a explora credinele,
sentimentele lor, ideile, atitudinile cu privire la problemele puse n discuie.
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 legtura cu participanii, s asigure continuarea discuiilor i
posibilitatea de exprimare a fiecrui participant. n plus, moderatorul poate s
aib un rol esenial n analiza i interpretarea datelor, ceea ce implic anumite
competene din partea acestuia, respectiv: puterea de observare, relaii
interpersonale, comunicare.
n faa unui grup, tracul este normal, cu att mai mult n cazul n care membrii lui sunt
persoane necunoscute. Atitudinea grupului va fi diferit, dup cum prezena lor la o aciune
este perceput ca o constrngere sau ca o alegere liber. n primul caz, trebuie s ne ateptm
la reacii de respingere i s nvm s le stpnim.
Caracteristicile unui grup sunt urmtoarele:
grupul are un mod simplu de a gndi: el este mai lent dect cel al fiecrui individ.
Nivelul su este inferior nivelului fiecrui 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;
atenia 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 dect fiecare individ n parte: dup ce grupul s-a constituit,
toi participanii care se altur ulterior grupului vor ntmpina dificulti n a se
integra.
n concluzie, este dificil de lucrat cu un grup.
Paralel cu caracteristicile proprii, pentru toate grupurile trebuie inut cont de
personalitile individuale ale participanilor care compun acest grup.
Comportamentele individuale tip apar spontan n formarea grupului. Fiecare ndeplinete
un anumit rol, adoptnd o anumit atitudine (mediator, lider, perturbator, pol al ateniei
celorlali etc.). Este important pentru mediator s tie s recunoasc aceste diferene
individuale, s le foloseasc sau s le neutralizeze, astfel nct grupul s poat progresa.
Un interviu n grup are cteva avantaje:
folosirea mai eficient a timpului alocat interviului dect n varianta unei serii de
intervievarea concomitent a mai multor persoane le permite acestora s-i asculte
reciproc declaraiile, fie pentru a le susine, fie pentru a le combate, fie pentru a se
formula noi preri;
prin interviuri colective se pot efectua delimitri clare ntre punctele de vedere
acceptate de toi intervievaii i cele ce strnesc mari divergene.
Ca dezavantaj principal: dificultatea planificrii calendaristice a desfurrii interviului,
datorit implicrii mai multor persoane care trebuie s participe concomitent la acest proces.
Tehnologiile moderne, ndeosebi diferitele forme ale videoconferinelor, pot simplifica
procesul intervievrii colective, minimiznd influena nefast a dispersiei geografice care face
dificil ntlnirea membrilor grupului.
6.4 Observarea direct a utilizatorilor

Nu ntotdeauna consultarea persoanelor conduce la obinerea celor mai bune rezultate,
chiar i atunci cnd acestea afirm c ofer cele mai sigure informaii sau au impresia c dein
adevrul absolut asupra sistemului analizat. Prerile sunt subiective. Explicaia const n
apariia ocazional a unor evenimente, n punerea amprentei timpului asupra unor sentimente
sau chiar n apariia elementului pasional. Anularea efectelor subiectivismului se poate realiza
prin urmrirea a ceea ce personalul execut sau prin evaluri obiective ale efectului activitii.
Observarea este util pentru a determina modul n care lucreaz actualul sistem i mai
puin pentru a stabili cum ar trebui s funcioneze cel nou, ajutnd la nelegerea funciilor
economice. Totui, exist i posibilitatea de a se crea o imagine despre noul sistem, asociind
procesele economice identificate, n sensul c atunci cnd se observ procesele economice
curente, nu trebuie s se uite c pot i trebuie s fie modificate pentru a fi mai eficiente 7. De
asemenea, prin observare, analitii ncearc s stabileasc care sunt relaiile dintre o anumit
persoan implicat n luarea unor decizii sau desfurarea unei activiti i alte persoane din
firm sau din afara ei8. n plus, prin observarea mediului n care se desfoar diferitele
activiti, se pot identifica factorii care pot influena procesul decizional (echipamente folosite,
ambiana biroului, ergonomia locului de munc).
Observarea presupune nregistrarea comportamentului de baz al persoanelor, obiectelor
sau evenimentelor, ntr-o manier sistematic, pentru obinerea informaiilor 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 cteva moduri, de la a merge prin birouri sau secii i pn la
desfurarea de ctre analiti a activitilor utilizatorilor. Prin deplasarea prin diferite locuri din
firm, se formeaz o perspectiv asupra activitilor desfurate acolo, eventualele nevoi
privind utilizarea unor echipamente i fluxul general de lucru. Prin petrecerea ctorva ore
alturi de utilizatori, pentru a observa cum i desfoar activitile, se obin detalii privind
modul n care sunt folosite anumite echipamente i cum sunt realizate funciile economice. Prin
transpunerea n ipostaza de utilizator i realiznd o parte din activitile specifice, se descoper
dificultile ntmpinate n nelegerea i nvarea procedurilor noului sistem, importana
uurinei 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 observrii la acelai 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 neles, ar putea s fie nevoie de o perioad mai mare

de timp. Ca i n cazul interviurilor, este mult mai benefic dac la observare ar participa doi
analiti, 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 observrii 10:
structurat, cnd analitii specific n detaliu ce va fi supus observrii i cum vor fi
nregistrate rezultatele observrii. Acest lucru reduce tendina ca analistul s afecteze
credibilitatea datelor. Observarea structurat este recomandat atunci cnd problema
analizat a fost foarte clar definit i s-au stabilit cu exactitate informaiile necesare
rezolvrii ei. n aceste circumstane, se desprind cu lejeritate detaliile despre
activitile supuse observrii.
nestructurat, cnd analistul monitorizeaz toate aspectele despre activitile de interes
care par a fi relevante pentru problema identificat. Aceast form de observare se
aplic atunci cnd problema urmeaz s fie formulat n mod explicit i cnd, pentru
identificarea componentelor cheie ale problemei i pentru dezvoltarea ipotezelor de
lucru, este cerut un anumit grad de flexibilitate. n observarea nestructurat, tendina
analistului de a fi influenat de aspectele observate este foarte mare. Din aceast cauz,
elementele supuse observrii trebuie s fie tratate ca ipoteze de verificat i nu ca
aspecte concludente ale problemei analizate.
2. dup modul n care se stabilete momentul desfurrii11:
observarea pe baz de intervale de timp, prin alegerea aleatoare a unor perioade din zi,
ceea ce nseamn c pot fi observate activitile pe care le desfoar n mod curent
utilizatorii. ns, printr-o astfel de modalitate, se culeg date fragmentate ce nu asigur
analiza complet a unui eveniment, de la iniierea i pn 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 iniierea evenimentului i pn la studierea efectelor acestuia.
ns, nici aceast form de observare nu este lipsit de dezavantaje, datorit duratei
relativ mari de ateptare pn la apariia unui eveniment sau a perioadei mari de timp
pe care o presupune realizarea lui; apare i riscul de a omite activitile curente care au
loc n cadrul sistemului. Ca atare, analitii apeleaz, de multe ori, la o combinaie a
celor dou tipuri de observri, pentru a analiza att activitile curente, ct i pe cele
care au loc doar n anumite condiii.
3. n funcie de ntiinarea sau nu a utilizatorilor:
camuflat, ceea ce presupune c persoanele observate nu sunt ntiinate c vor fi
supuse observrii. Aceast form d posibilitatea utilizatorilor de a avea un
comportament natural, pentru c oamenii au ntotdeauna tendina de a se comporta
diferit cnd tiu c sunt supui observrii.
necamuflat, care presupune ntiinarea utilizatorilor c vor fi supui unei observri.
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 prezenei analistului printre ele.
4. dup cadrul n care se va desfura observarea:
natural, const n observarea comportamentului n mediul de lucru al utilizatorilor.
De exemplu, observarea celor care lucreaz cu o anumit aplicaie n cadrul biroului n
care ei i desfoar activitatea zi de zi. Avantajul observrii naturale l constituie
faptul c activitile observate vor reflecta adevrata lor valoare. Dezavantajul const

10. Malhotra, N.K. op. cit., pp. 213-214.
n costul ateptrii desfurrii activitilor i dificultatea evalurii 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 aplicaii.
Observarea activitilor utilizatorilor presupune parcurgerea pailor 12:
stabilirea a ceea ce va fi supus observrii (activitile, procesele, mediul de lucru);
determinarea gradului de detaliere a observrii, care va influena modul de interaciune
cu utilizatorii, precum i timpul necesar analizei i interpretrii activitilor observate;
pregtirea listelor de verificare i a altor materiale necesare desfurrii observrii
propriu-zise;
stabilirea momentului observrii;
desfurarea observrii;
interpretarea i analiza informaiilor nregistrate pe parcursul aciunilor specifice.
Ca tehnici de realizare a observrii pot fi enumerate13:
observarea personal, cnd o persoan urmrete comportamentul utilizatorilor.
Observatorul nu ncearc s controleze sau s manipuleze activitile supuse
observrii, ci numai nregistreaz ceea ce are loc. De exemplu, analistul poate s
nregistreze circuitul fluxurilor de informaii din cadrul unui compartiment.
observarea mecanic, ceea ce implic utilizarea mai mult a dispozitivelor mecanice
dect a observatorilor umani, prin care se nregistreaz activitile 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
nregistrrilor fizice sau executarea unei analize asupra activitilor derulate de-a
lungul timpului.
analiza de coninut este cea mai adecvat metod atunci cnd activitile supuse
observrii apeleaz foarte mult la comunicare i mai puin la comportament. Unitatea
de analiz ar putea fi cuvintele, caracterele persoanelor, msurile de timp i spaiu.
analiza nregistrrilor, prin care colectarea datelor se realizeaz pe baza evidenelor
fizice sau a unui comportament studiat anterior.
Desfurarea operaiunii de observare direct depinde i de acceptul sau bunele intenii
ale organizaiei supuse analizei. Uneori, chiar dac exist un astfel de accept, prezena
analitilor printre angajai i determin pe acetia din urm s manifeste un comportament
anormal, cu scopul de a crea o anumit impresie. Astfel, pot fi emoionai, stresai, se pot fora
s efectueze lucrrile 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 observrii pe termen lung a sistemului.
Discutabile sunt i momentele surprinse, i persoanele ce ar putea fi urmrite ca numr.
Aadar, observarea presupune pentru analiti luarea n considerare a unei palete foarte
largi de factori ce ar putea influena rezultatul aciunii.
6.5 Analiza procedurilor de lucru i a altor documente

Metodele amintite anterior pot fi completate cu cea din paragraful curent, pentru obinerea
celor mai relevante date despre sistemul analizat, prin examinarea documentaiei sistemului i
a organizaiei.
Pentru procedurile i formularele existente apar dou principale surse de informaii:
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 organizaiile profesionale din domeniul n care
activeaz firma sau de la alte firme din aceeai ramur de activitate. Uneori, revistele de
specialitate prezint studii privind cele mai bune practici i rezultatele obinute de diferite
firme n dezvoltarea i implementarea unor sisteme, cum ar fi relatarea cazurilor de succes n
implementarea sistemelor ERP. De asemenea, prin extinderea granielor organizaionale,
sursele externe devin din ce n ce mai importante pentru identificarea cerinelor informaionale,
presupunnd investigarea practicilor i procedurilor partenerilor de afaceri implicai n lanul
valoric al firmei.
Sursele interne servesc pentru atingerea a dou obiective. Primul este de a nelege, n
special de ctre membrii echipei ce nu cunosc ndeajuns de bine firma, procesele economice
ale acesteia, dar i pentru stabilirea ntrebrilor din interviuri i chestionare. Al doilea scop l
constituie utilizarea documentelor existente n timpul interviurilor pentru a asigura o mai bun
comunicare i nelegere a ntrebrilor i rspunsurilor de ctre ambele pri. Formularele i
rapoartele pot servi la vizualizarea unor aspecte ce sunt subiectul interviurilor, dar i ca
documente de lucru pentru discuiile dintre membrii echipei proiectului, care se concentreaz
pe utilizarea fiecrui formular, obiectivele utilizrii lui, distribuia, coninutul, precum i
evenimentele ce declaneaz folosirea acestuia. Este posibil ca evenimente economice diferite
s solicite acelai formular, iar identificarea informaiilor despre evenimentele i procesele
economice devine esenial. n aceast activitate, este util ca echipa s apeleze la formulare ce
sunt completate cu date reale pentru a se asigura c s-a obinut o imagine clar i s-a neles
rolul fiecrui element din formular i coninutul su n ansamblu.
Analiza documentaiei privind procedurile existente ajut la identificarea regulilor
economice care e posibil s nu poat fi desprinse n timpul interviurilor, precum i la
descoperirea unor redundane ce apar la nivelul proceselor economice. Totui, se ntmpl ca
unele manuale ce descriu procedurile de lucru s nu fie actualizate i s conin anumite erori
care nu au fost eliminate. De aceea, pentru a se asigura c ipotezele de lucru i regulile
economice identificate n documentaia 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 organizaiei, obiectivele acesteia, planurile de afaceri, studiile de
fezabilitate, structura organizatoric (organigrama), planul sistemului informaional anterior
sau curent, regulamentele de organizare i funcionare, a celor de ordine interioar, normele
interne de fabricaie, standardele folosite, fiele posturilor, corespondena intern i extern,
rapoartele de analiz obinute din studii anterioare .a. Astfel, documentele analizate pot fi
grupate n mai multe categorii15:
rapoartele generate de sistemul actual;
procedurile de lucru pentru activiti individuale sau ale grupurilor. Prin ele se descrie
modul n care se exercit o anumit activitate, prezentndu-se i datele i/sau informaiile
pe care le solicit sau le genereaz. Analiza procedurilor poate evidenia:
repetarea activitilor n dou sau mai multe locuri de munc declarate cu sarcini
diferite;
absena procedurilor de lucru pentru unele activiti;
depirea valabilitii 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 tranzaciile interne i externe;
documentaia 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 obin informaii despre:

problemele existente n sistemul curent, cum ar fi prezena unor informaii
redundante, a unor puncte de trangulare sau absena unor informaii;
posibilitile de obinere condiionat a unor informaii, cum ar fi lansarea n execuie
a unor programe speciale;
preocupri pe linia schimbrii politicii privind tratarea unor categorii de informaii.
De exemplu, trecerea la sistemele de afaceri electronice pentru mbuntirea relaiilor
cu partenerii de afaceri;
numele i funciile persoanelor direct interesate de soarta sistemului;
obiectivele-cheie ale organizaiei sau/i ale persoanelor sau grupurilor de persoane,
att pe termen scurt, ct i pe termen lung;
procedurile speciale de prelucrare a unor informaii din sistem;
motivele proiectrii sistemului curent, aa cum este el n faza analizei;
datele, regulile de prelucrare a lor, principiile pe baza crora funcioneaz sistemul
informaional.
Analiza documentelor i procedurilor de lucru ajut la descrierea modului n care se
intenioneaz s lucreze sistemul, echipa avnd posibilitatea s identifice diferenele dintre
funciile sistemului actual i cele propuse pentru noul sistem.
Metoda este folosit pentru a documenta rezultatele obinute n timpul intervievrii i
observrii utilizatorilor, permind descrierea fluxurilor de date, documentelor i procedurilor,
cunoscute sub denumirea de fluxuri informaionale.
O comparaie a observrii directe cu analiza documentelor este prezentat n tabelul 6.6.
Tabel nr. 6.6 Analiza comparativ a observrii directe i analizei documentelor
Caracteristici Observarea Analiza documentelor
Cantitatea de informaii obinute Mare (deoarece se pot folosi
Sczut (pasiv) i veche
multe canale)
Personal angajat n operaiune Rezonabil ca numr Ridicat ca numr
Numr persoane implicate n
Mediu Sczut
operaiune (testate)
Valoare cheltuieli Poate fi ridicat Sczut spre moderat
Timp de pregtire Ridicat Sczut spre moderat
Timp de operare Mediu Lung
Timp de prelucrare final Ridicat Mediu
Posibilitatea evitrii
Mare Mediu
nenelegerilor
Confidenialitate Persoana este remarcat i cei
Depinde de natura
observai i pot schimba
documentelor observate
comportamentul
Grad de reuit a operaiunii, Depinde dac cei observai tiu c
Nu implic partea testat
prin implicarea prii testate sunt supui observrii
Procent de reuit a testului Mare Redus-mediu
Rezumat
Timpul necesar culegerii informaiilor este imens, iar cheltuielile sunt pe msur. Este necesar
cunoaterea sloganului care circul printre analiti analysis paralysis (analizele paralizeaz), referindu-
se la excesele de zel din faza de analiz.
Ca efect al tendinelor de mrire 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 puine 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 tradiionale de colectare a cerinelor sistemului sunt: interviuri individuale; anchete
realizate prin chestionare; intervievarea grupurilor de oameni cu interese comune; observarea
personalului; studierea documentaiei firmei.
Intervievarea este de departe una din cele mai bune metode de a nelege funciile i regulile
economice, dar i activitatea consumatoare de timp i alte resurse, fiind calea relativ uoar 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 (pregtirea) interviului, desfurarea propriu-
zis i finalizarea i stabilirea activitilor postinterviu.
Indiferent de tipul interviului, unele principii i tehnici au o aplicabilitate general. Acestea sunt
mprite n trei pri majore: deschiderea, partea principal, nchiderea.
Spre deosebire de interviuri, chestionarele sunt mai puin costisitoare i, ntr-un timp relativ scurt,
pot oferi un volum mare de informaii necesare analizei sistemului. Prin utilizarea chestionarelor se
urmrete obinerea de detalii preliminare privind nevoile informaionale ale diferitelor persoane
interesate de sistem, ajutnd la identificarea domeniilor ce necesit cercetri suplimentare cu ajutorul
interviurilor, analizei documentelor i al observrii.
Paii pentru conceperea unui chestionar sunt: identificarea informaiilor ce vor fi cutate, stabilirea
tipului de chestionar i a metodei de administrare, determinarea coninutului fiecrei ntrebri,
stabilirea formei de redactare a rspunsului la fiecare ntrebare, formularea ntrebrilor, stabilirea
secvenei derulrii ntrebrilor, stabilirea caracteristicilor tehnice ale chestionarului, reevaluarea
pailor anteriori i revizuirea lor, efectuarea pretestului i revizuirea final.
Un inconvenient al aplicrii interviurilor i chestionarelor pentru colectarea cerinelor sistemelor l
constituie apariia unor contradicii aparente ntre datele colectate; reconcilierea lor presupune intervenia
analistului. Operaiunea salvatoare este cea a intervievrii grupurilor. Printr-un interviu al grupului are
loc intervievarea concomitent a unui grup de persoane-cheie.
Paii care se parcurg pentru planificarea i desfurarea interviurilor de grup sunt: determinarea
obiectivelor proiectului pentru care se intervieveaz grupul i definirea problemei; specificarea
obiectivelor aciunii care se va ntreprinde (ale interviului); stabilirea obiectivelor/ntrebrilor la care
vor rspunde participanii 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 obinerea informaiilor 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 documentaiei sistemului i a
organizaiei, pentru obinerea celor mai relevante date despre sistemul analizat. Analiza documentaiei
privind procedurile existente ajut la identificarea regulilor economice care e posibil s nu poat fi
desprinse n timpul interviurilor, precum i la descoperirea unor redundane ce apar la nivelul proceselor
economice.
Metodelor tradiionale, prezentate anterior, li se adaug aa-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 informaiilor prin
diminuarea substanial a timpului dedicat analizei de sistem.
1. Enumerai paii specifici derulrii unui interviu.
2. Care sunt paii care se parcurg pentru conceperea unui chestionar?
3. Prezentai comparativ caracteristicile interviului i chestionarului.
4. n ce situaii se impune utilizarea interviului de grup?
5. Enumerai i descriei principalele caracteristici ale unui grup de care trebuie s se in cont n
intervievarea lui.
6. Ce pai se parcurg pentru planificarea i desfurarea interviurilor de grup?

7. Care sunt avantajele i dezavantajele interviului de grup fa de cel individual?
8. Enumerai motivele pentru care observarea este util n determinarea cerinelor sistemului.
9. Specificai tipurile de observri posibil de efectuat n timpul etapei de analiz.
10. Enumerai avantajele observrii bazat pe evenimente.
11. Prezentai avantajele i dezavantajele observrii.
12. Care este utilitatea analizei procedurilor de lucru i a altor documente?
13. Ce tipuri de informaii se pot obine din analiza procedurilor i documentelor?
14. Descriei principalele surse de informaii folosite n analiza procedurilor i documentelor.
15. Care sunt principalele aspecte urmrite n timpul analizei procedurilor?
Probleme de echip
1. A fost planificat un interviu cu managerul de vnzri al unei firme de papetrie, care dorete s
prezinte o serie de informaii despre produse i vnzri pe Intranet, astfel nct toi angajaii s aib
acces la ele pentru mbuntirea prognozelor privind vnzrile. Reformulai urmtoarele ntrebri,
tiind c, aa cum sunt prezentate, nu au fost formulate corespunztor:
a) Personalul de vnzri din subordine a specificat faptul c avei reineri n privina utilizrii
calculatorului. Este adevrat?
b) Ce surse de informaii folosii cel mai mult pentru analiza vnzrilor i ct de frecvent?
c) Suntei de acord cu plasarea lunar a informaiilor privind vnzrile pe Intranet pentru realizarea
analizelor de vnzri i mbuntirea esenial a sistemului de vnzri?
d) Nu credei c este o cale mult mai bun dect cea folosit pn acum?
2. Ca echip de analiz pentru un proiect de mbuntire a funciilor sistemului contabil al unei firme
de ceasuri, urmeaz s-l intervievai pe contabilul-ef. Formulai 4-6 obiective ale interviului care s
acopere sursele de informaii pe care le folosete, formatul rapoartelor, frecvena lurii deciziilor,
calitatea informaiilor dorite.
a) ntr-un paragraf, precizai cum l vei aborda pe contabilul-ef pentru planificarea interviului.
b) Stabilii structura interviului pe care o vei alege i motivai propunerea.
c) Contabilul-ef are n subordine 3 salariai care folosesc sistemul. i vei intervieva i pe ei?
Motivai dac este necesar sau nu.
d) Formulai 3 ntrebri deschise pe care le vei transmite prin e-mail contabilului-ef nainte de a
se desfura interviul. Explicai de ce este de preferat s se realizeze interviul fa-n-fa i nu
prin intermediul e-mailului.
e) Formulai cel puin 5 ntrebri nchise prin care s obinei informaiile privind formatul
rapoartelor i calitatea informaiilor solicitate.
CAPITOLUL VII
Modelarea logic, grafic,

a proceselor de prelucrare
Obiective:
nelegerea 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 ctre dou
din cele mai utilizate tehnici de modelare: Gane & Sarson i Yourdon & DeMarco
Prezentarea pailor care se parcurg i a recomandrilor pentru construirea DFD
Definirea regulilor care stau la baza construirii DFD
Cunoaterea aspectelor privind descrierea modelului logic al sistemului cu ajutorul
depozitelor de metadate
Toate informaiile culese despre cerinele sistemului trebuie s fie nregistrate sub o form
sau alta, fie c este vorba despre cele funcionale (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 pstrarea lor ntr-un format structurat. Modelele care se construiesc au i rolul de a
asigura comunicarea mai uoar ntre cei care particip la dezvoltarea sistemului sau sunt
afectai de el (beneficiari, utilizatori, finanatori, echipa de dezvoltare).
Procesul de modelare poate fi considerat ca un proces de nvare, pentru c pe msura
crerii modelului, echipa de analiz nva tot mai mult despre sistem, continund pe msura
culegerii cerinelor, 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 obine o imagine mult mai clar asupra principalelor componente ale
acestuia. Modelarea conceptual (logic) a sistemului reprezint nceputul activitilor cu
caracter tehnic din dezvoltarea acestuia, cu scopul de a completa documentaia de analiz i de
a reda cuprinztor elementele ce vor fi supuse proiectrii.
7.1 Introducere n modelarea sistemelor

Documentaia descriptiv a sistemului este un mijloc de comunicare ntre toi cei implicai
n dezvoltarea acestuia, dar nu este, de multe ori, cea mai bun cale pentru a-i descrie cerinele.
Modelarea folosete o combinaie ntre formele descriptive i grafice pentru redarea funciilor
(proceselor), datelor i comportamentului sistemului de o manier relativ uor de neles. Dar
poate cel mai important aspect al modelrii l constituie flexibilitatea pentru corectarea,
completarea i asigurarea concordanei reprezentrii sistemului.
n plus, pentru validarea cerinelor este necesar ca acestea s fie analizate din perspectiva
celor implicai n dezvoltarea sistemului (utilizatori, beneficiari, finanatori, proiectani), iar
modelarea poate fi mijlocul prin care cele patru puncte de vedere sunt reunite, conducnd la
creterea probabilitii de detectare a erorilor nc din faza de analiz, de eliminare a
inconsistenelor, precum i de depistare a eventualelor omisiuni.
Abordarea sistemului prin intermediul diferitelor modele permite obinerea unor avantaje,
n comparaie cu descrierea narativ, i anume:
MODELAREA LOGIC, GRAFIC, A PROCESELOR DE PRELUCRARE 127
nelegerea mult mai uoar a relaiilor care exist ntre sistem i mediul extern,
deosebit de important pentru identificarea frontierelor acestuia i a funciilor pe care
trebuie s le ndeplineasc;
comunicarea eficient i lejer cu utilizatorii, analitii putnd s solicite efectuarea
unor observaii suplimentare, pentru completarea i corectarea modului de
conceptualizare a sistemului, ncorpornd modificrile solicitate de utilizatori, astfel
nct sistemul s redea ct mai bine punctul lor de vedere. Chiar dac majoritatea
autorilor consider c prin intermediul diagramelor (modelelor) este mult mai uor s
se comunice cu utilizatorii, ceea ce este adevrat, acest avantaj nu se obine automat,
pentru c ei trebuie s fie pregtii, n prealabil, pentru a nelege 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 nct analiza s fie o etap prin care s se asigure c toate ieirile
solicitate pot fi obinute din datele de intrare preluate de sistem i c logica
prelucrrilor este reflectat prin intermediul diagramelor. Spre deosebire de analiza
fluxului activitilor, 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 msura trecerii lor prin diferite procese, fr a se face nici o
difereniere ntre cele manuale sau automate i fr a se reda secvena lor cronologic,
urmrindu-se doar o eventual grupare a lor, din punct de vedere al logicii
prelucrrilor;
neincluderea aspectelor tehnice de implementare n etapa de analiz, n sensul c nici
un simbol, cel puin n modelul logic, nu abordeaz elementele tehnice de
implementare, care ar putea ngreuna nivelul de nelegere a utilizatorilor. De
asemenea, acest avantaj elimin riscul stabilirii, nc din etapa de analiz, a unor
tehnologii care se pot dovedi inadecvate n momentul proiectrii i implementrii. 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, evitnd
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, concentrndu-se asupra
operaiilor economice i a modului n care funcioneaz firma sau o anumit component
economic a sa, fr 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 ieire a sistemului ca pe o list de date
elementare, fr a face trimitere dac va fi pe hrtie sau afiat pe ecran. Modelul logic are ca
scop reprezentarea informaiilor 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 deine mai multe
detalii despre formatul ieirilor, al ecranelor de preluare a datelor, a modului de interconectare
a reelelor 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 urmrite prin cele dou modele. De reinut c
modelul logic reflect componenta economic pe care sistemul trebuie s o redea, n timp ce
modelul fizic descrie componentele fizice necesare realizrii funciilor acestuia. Diferena
dintre cele dou scoate n eviden diferena 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
funcioneaz organizaia sau o va funciona el.
component economic a sa.
Componentele Activitile/evenimentele Programele, modulele i procedurile
reprezentate economice. manuale sau automate ce vor fi executate.
Locurile de stocare Coleciile de date cu privire la Fiiere i baze de date sau dosare, registre
redate operaiile economice, fr a n situaia sistemelor manuale.
surprinde modul n care datele sunt
memorate i gestionate.
Tipul datelor La definirea datelor se utilizeaz n funcie 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, obinerea nregistrrilor, pentru
asigurarea finalizrii unui proces, pentru
asigurarea securitii.
Indiferent de tipul sistemului analizat, manual sau informatizat, o problem este comun: el
va fi nlocuit de un nou sistem. Orict 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 conin una sau mai
multe DFD, un model de date i logica proceselor de prelucrare. Problema comun ar consta n
identificarea unei ci 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 neaprat schimbat din sistemul curent i ceea ce trebuie s se
realizeze n cel nou. De regul, se cer mai multe date de cules i pstrat, precum i noi
caracteristici ale prelucrrilor: mai complexe, mai rapide, mai sigure. Aadar, modelul logic
propus poate fi conceput pe baza modelului logic curent. Paii urmtori pot fi efectuai
parcurgnd ci 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 utilizrii diagramelor fizice i logice ale sistemului curent const n faptul c
cele pentru noul sistem sunt mult mai uor de construit, pentru c este neles deja modul lui de
funcionare, analitii trebuind s identifice care sunt procesele ce nu mai sunt necesare, pentru
a fi eliminate, i s adauge noi procese, intrri, ieiri sau locuri de stocare 2. Aceast manier de
lucru ofer o modalitate prin care se asigur pstrarea principalelor funcii i caracteristici ale
vechiului sistem, efectundu-se o trecere gradual ctre proiectarea noului sistem. Dup ce este
construit modelul logic al sistemului nou, acesta poate fi folosit pentru a-l dezvolta pe cel fizic,
aa cum rezult din figura 7.1.

Realizarea diagramelor fizice ale sistemului

Diagramele fizice ale curent, pentru inventarierea interfeelor,
sistemului curent echipamentelor, fiierelor 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 activitilor economice unice
Diagramele logice ale Crearea diagramelor logice pentru sistemul

sistemului nou nou, prin adugarea de noi intrri, ieiri i
procese solicitate de acesta
Construirea diagramelor fizice, prin analiza

Diagramele fizice ale proceselor din noile diagrame logice, pentru
sistemului nou determinarea interfeelorutilizator, a naturii
proceselor (manuale sau automate) i a fiierelor
sau bazelor de date necesare implementrii
noului sistem
Fig. 7.1 Trecerea de la modelele sistemului curent la cele ale noului sistem
Modelarea sistemului curent se impune atunci cnd se efectueaz analiza sistemului
existent i nu exist documentaie pentru acesta. Dup modelarea sistemului existent,
diagramele obinute se vor modifica pentru a fi adaptate la cerinele noului sistem.
Modelele construite n faza de analiz depind de metodologia utilizat, astfel:
abordarea structurat apeleaz la diagramele fluxurilor de date, diagramele entitate-relaie;
ingineria programrii folosete diagrama dependenelor i diagrama entitate-relaie;
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 diferenele dintre abordarea structurat i cea orientat-
obiect, n privina modelrii sistemului n timpul analizei.
Tabel nr. 7.2 Diferene ntre metodologia structurat i orientat-obiect n faza de analiz
Caracteristici Metodologia structurat Metodologia orientat-obiect
Cum este vzut sistemul O colecie de procese i date O colecie de obiecte
Interaciunile sistemului Procesele interacioneaz cu locurile Obiectele interacioneaz cu
de stocare i entitile externe, prin utilizatorii i alte obiecte
intermediul fluxurilor de date
Modalitile de Procesele solicit introducerea Obiectele transmit i rspund la
interaciune datelor i generarea ieirilor 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 relaie Diagrame ale claselor de obiecte
Engleza structurat
Arbori i tabele decizionale
Revenind la modelarea din timpul analizei, putem spune c cerinele sistemului privind
funciile (procesele), datele i comportamentul sistemului sunt modelate apelnd la diferite
forme de reprezentare grafic. Astfel, pentru obinerea viziunii de ansamblu asupra sistemului
se creeaz modelul descompunerii funcionale3, dup care, pentru detaliere, se construiesc
diagramele fluxurilor de date (DFD), indicnd transformarea datelor care intr sau sunt stocate
n sistem pentru obinerea ieirilor. Pentru reprezentarea lucrurilor/obiectelor, atributelor i
3. Nu se va confunda cu metodologia descompunerii funcionale, ca metodologie incipient utilizat n dezvoltarea

sistemelor, cu descompunerea funcional sau descompunerea pe funcii a sistemelor, care reprezint o tehnic
folosit pentru simplificarea reprezentrii grafice a sistemului.
relaiilor dintre ele, se folosesc diagramele entitate-relaie (DER), iar modelarea

comportamentului, a impactului diferitelor evenimente asupra proceselor (ce i cnd
declaneaz procesele de prelucrare) se face cu ajutorul diagramelor strilor de tranziie,
arborilor/tabelelor decizionale etc.
7.2 Descompunerea sistemului pe funcii de prelucrare

Unul dintre principalele obiective ale analistului de sistem const n extragerea cerinelor
din studierea activitilor curente ale utilizatorilor i transpunerea lor sub forma procedurilor
din cadrul aplicaiilor. De exemplu, dac un utilizator specific faptul c primete facturile de
la furnizori i le pltete 30 de zile mai trziu, el explic activitile curente specifice primirii i
plii facturilor. Atunci cnd analistul creeaz specificaiile tehnice pentru cerinele
utilizatorilor, el le formuleaz astfel nct s poat fi transpuse ntr-un mediu informatizat. n
aceste condiii, sistemul trebuie s surprind, din punct de vedere logic, activitile fizice
desfurate de utilizatori. Soluiile logice nu permit ntotdeauna redarea acestora n acelai
mod n care ele se realizeaz n lumea real. De aceea, sistemele informaionale sunt
considerate ca reprezentri logice ale lumii reale. Procesul prin care analitii modeleaz
funciile unui sistem reprezint o abstractizare a activitilor fizice, cunoscut i sub numele de
echivalen logic.
Un pas important n procesul de abstractizare l constituie descompunerea funcional,
prin care se identific principalele componente ale unui sistem (funcii, procese, proceduri de
prelucrare .a.), n urma creia se obine o diagram a descompunerii funcionale.
Aa cum am vzut n capitolul 5, la analiza proceselor de prelucrare a datelor, n cadrul
unui sistem se regsesc tranzaciile i transformrile, ce vor fi coninute de diagrama
descompunerii funcionale.
n cadrul diagramei, sistemul este vzut ca o funcie pe nivelul cel mai nalt, apelnd o
singur dat la simbolul dreptunghi pentru redarea acestuia, dup care, pe celelalte niveluri de
descompunere, se folosete un alt simbol (dreptunghi cu colurile rotunjite) de reprezentare a
proceselor, diferit de cel al funciei, aa cum se va vedea n continuare. O alt regul, care se
va menine i n modelul proceselor, o constituie denumirea unic a fiecrui proces.
Descompunerea funcional este util atunci cnd se dorete nelegerea modului n care
este structurat sistemul, permind realizarea i controlul mult mai uor al modificrilor sau
completrilor la nivelul acestuia.
Diagrama descompunerii funcionale este similar cu organigrama unei firme, n care
poziia de pe cel mai nalt nivel o constituie sistemul, vzut ca funcie de baz, iar nivelurile
inferioare de descompunere sunt procesele din care este alctuit, aa cum rezult i din fig. 7.2.
n figur s-a reprezentat un sistem pentru care s-au identificat mai multe tranzacii i
transformri (funciile principale ale sistemului), din care doar dou se descompun pe
urmtorul nivel n procese de prelucrare, iar dintre acestea doar unul se descompune n
proceduri. Nu este o situaie standard, pentru c toate funciile, procesele i procedurile se pot
descompune pe niveluri inferioare, n funcie de complexitatea lor. n terminologia construirii
modelului sistemului pentru redarea conceptului de prelucrare, indiferent de nivelul pe care se
situeaz, se folosete noiunea de proces, cu referire inclusiv la tranzacii/transformri,
proceduri, module, grupuri de instruciuni, pentru c toate urmresc prelucrarea datelor, aa
cum s-a vzut n capitolul 5.
Procesele de prelucrare care sunt logic legate sau au loc n acelai timp pot fi grupate ntr-
o funcie distinct a sistemului, urmnd a fi reflectate separat pe urmtoarele niveluri de
descompunere. ns, niciodat nu se vor include ntr-o singur funcie sau un singur proces
elemente ntre care nu exist nici o relaie. Dac datele nu sunt prelucrate n acelai timp sau
au regimuri diferite de prelucrare, este indicat ca procesele s fie separate, chiar dac
prelucreaz date coninute de un singur flux sau provin de la aceeai surs (loc de stocare sau
entitate extern).
descompunere
Nivel 0 de
Tranzactie 44
Tranzactie
Contextul sistemului
descompunere
Nivel 1 de
3.2
Proces 3.2
Proces
Tranzactie 33
Tranzactie
3.1
Proces 3.1
Proces
Sistem
Sistem
1.2.3
Procedura1.2.3
Nivelul 2 de
descompunere
Tranformare2 2
Tranformare
Procedura
1.3
Proces 1.3
Proces
1.2.2
Procedura1.2.2
Procedura
1.2
Proces 1.2
Proces
1.2.1
Tranzactie 11
Procedura 1.2.1
Tranzactie
Procedura
1.1
Proces 1.1
Proces
Fig. 7.2 Diagram generalizat a descompunerii funcionale a unui sistem
Cteva observaii asupra modelului prezentat n figura 7.2:

elipsele care delimiteaz nivelurile de descompunere sunt doar didactice, de
evideniere 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 conine principalele funcii de
prelucrare ale sistemului. Urmtorul nivel, 1, este folosit pentru descompunerea n
procese de prelucrare a unei funcii 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 secvena operaiunilor de descompunere, conform notaiei militare.
Aceste comentarii ar trebui reinute, pentru c nivelurile obinute prin descompunere vor
fi folosite mai trziu n construirea modelului proceselor cu ajutorul diagramelor fluxurilor de
date, pentru c scheletul acestor diagrame se construiete plecnd de la diagrama

descompunerii funcionale.
Diagrama descompunerii funcionale poate fi construit apelnd la dou metode: bottom-
up sau top-down, uneori mixt. ns, de cele mai multe ori, se folosete 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 funcie de anumite caracteristici comune, n procese, pn se
ajunge la clase de tranzacii/transformri, i se consider c sistemul este complet. n acest caz,
diagrama descompunerii funcionale poate fi obinut dup ce au fost construite DFD-urile.
n cazul top-down, se parcurge sensul invers al aciunilor, cu alte cuvinte sistemul se
descompune pn la cel mai de jos nivel. n acest caz, diagrama descompunerii funcionale st
la baza construirii DFD-urilor, adic se va obine cte 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 mixrii celor dou metode apare atunci cnd exist deja modelul funcional al
sistemului i sunt necesare diverse ajustri, prin adugarea de noi procese sau eliminarea
altora, n funcie de cerinele noului sistem.
n identificarea principalelor tranzacii/transformri, procese, proceduri ale sistemului,
pentru construirea diagramei descompunerii funcionale, se pleac de la tabelul evenimentelor,
realizat n timpul studierii sistemului existent i determinarea cerinelor.
n caseta 7.1 sunt prezentate tranzaciile i procesele sistemului de gestiune a clienilor,
grupate pe baza asemnrilor existente ntre diferite evenimente, a interaciunilor proceselor de
prelucrare cu actorii i locurile de stocare.
Caseta nr. 7.1 Tranzaciile i procesele sistemului de gestiune a clienilor la firma ABC
Principalele tranzacii i procese de prelucrare identificate pe baza listei evenimentelor n cadrul
sistemului de gestiune a clienilor:
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 cerine client, returnri totale etc.)
Generare rapoarte privind onorarea comenzilor
Actualizare date clieni
nregistrare comand catalog
nregistrare clieni poteniali
nregistrare materiale promoionale
nregistrare ajustri (corectare erori, modificare limite creditare, perioad de plat)
Generare rapoarte
ntreinere date cataloage
Actualizare catalog (modificare date produse, tergere, introducere produse noi)
nregistrare promoii noi
nregistrare cataloage noi
Generare rapoarte privind cataloagele
Pe baza acestor grupri a evenimentelor n procese de prelucrare se poate construi
diagrama descompunerii funcionale a sistemului analizat, aa cum este prezentat n figura
C7.1.
Sistem asisten
clieni
Introducere Onorare comenzi Actualizare ntreinere

comenzi date clieni date cataloage
Verificare nregistrare Generare Inregistrare nregistrare nregistrare nregistrare Generare

existen comand Actualizare rapoarte comanda clieni materiale rapoarte
produs nou comenzi comenzi catalog poteniali promoii ajustri clieni
fluxurilor de date, fiind unul dintre cele mai utilizate.

Verificare nregistrare nregistrare Generare nregistrare nregistrare Generare
stare produse rapoarte Actualizare pr omoii cataloage rapoarte
comand livrare returnate livrri cataloage cataloage
noi noi
nregistrare nregistrare Prelucrare Confirmare

date date
clieni comand comand comand
MODELAREA LOGIC, GRAFIC, A PROCESELOR DE PRELUCRARE
7.3 Diagramele fluxurilor de date (DFD)

Fig. C7.1 Diagrama descompunerii funcionale pentru sistemul de gestiune clieni
dovedit a fi deosebit de valoros pentru modelarea proceselor, l reprezint diagramele

Metodologia structurat a dezvoltrii sistemelor informaionale descrie activitile ca
133
procese care sunt realizate manual sau cu ajutorul calculatorului. Un model grafic, ce s-a
ntr-o definiie restrns, DFD-urile sunt o metod de prezentare grafic a traseului logic
pe care l parcurg datele prin diverse procese pn sunt transformate n ieiri, rednd toate
componentele logice ale unui sistem ntr-o singur reprezentare grafic, respectiv intrrile,
ieirile, prelucrrile i locurile de stocare, precum i graniele sistemului 4.
Indiferent de metodologiile folosite n realizarea unui sistem/aplicaie, toate apeleaz la
operaiunea de modelare logic a prelucrrilor sub form de diagrame, diferenele constnd
doar n folosirea mai pronunat a diagramelor pentru descrierea sistemului, ncadrndu-le n
diagrame de context, diagrame ale fluxurilor de date fizice i diagrame ale fluxurilor de date
logice. Altele apeleaz la combinaii de diagrame, tabele i forme descriptive.
Diagrama de context scoate n relief aria de ntindere a sistemului analizat, prin
specificarea elementelor din interiorul organizaiei i a celor externe, sub denumirea de
entiti externe, nsemnnd entiti 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, acceptndu-se
unele intrri i descriindu-se ieirile din procesele menionate.
Diagrama fluxurilor de date ale sistemului logic curent, independent de tehnologie,
reliefeaz funciile de prelucrare a datelor executate de ctre sistemul informaional curent.
Diagrama fluxurilor de date ale sistemului logic nou va prezenta circuitul datelor,
structura lor i cerinele funcionale ale noului sistem.
Descrieri ale obiectelor DFD se regsesc n aa-zisele dicionare 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 regsesc sub denumirea generic de diagrame ale
fluxurilor de date i, ca atare, sub aceast semnificaie, le tratm i noi n continuare.
Se cuvine o remarc: ntruct diagramele fluxurilor de date (DFD) au ca obiectiv
urmrirea modului de transfer al datelor ntre procesele de prelucrare, astfel de diagrame se
mai numesc i modele ale proceselor de prelucrare, iar operaiunea se numete modelarea
proceselor.
Tehnica de redare a proceselor de prelucrare prin intermediul diagramelor fluxurilor de
date a cptat noi accepiuni prin ncorporarea ei n instrumentele de analiz i proiectare cu
ajutorul calculatorului, adic n produsele CASE, dei n acelai timp putem vorbi i de o
anumit complicare a problemei.
Cu ajutorul diagramelor fluxurilor de date se pot stabili graniele unui sistem apelnd doar
la patru simboluri:
locul n care se vor duce informaiile sau de unde vin ele, vzut ca alt sistem sau alt
persoan care interacioneaz cu sistemul;
locul n care sunt pstrate/memorate datele care circul n sistem;
fluxul de date;
procesul care asigur transformarea datelor.
Aa cum se va vedea mai trziu, primele dou simboluri sugereaz sursa, respectiv
destinaia datelor la un moment dat. DFD-urile pot fi folosite n locul unei descrieri narative a
sistemului, ce vine n sprijinul analitilor n timpul dialogului cu utilizatorii. Acest lucru se
datoreaz faptului c analitii sunt confruntai de multe ori, n timpul ntlnirilor cu utilizatorii,
cu problema explicrii modului de funcionare a sistemului, cnd utilizatorii sunt pui n
situaia de a accepta sau refuza soluiile propuse pentru dezvoltarea unui sistem i nu pot da un
rspuns pentru c nu reuesc s neleag specificaiile 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 consecinele
informatizrii contabilitii, Ed. Graphix, Iai, 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 reuesc s-i aminteasc 100% din imaginile vzute, dar
numai 50% dintr-un text. De aceea, reprezentarea grafic a unui sistem poate oferi utilizatorilor
o modalitate mai simpl de a-l nelege, 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 cretere
a detalierii fluxurilor de date i a prelucrrilor. De aceea, DFD-urile ofer un mecanism pentru
modelarea att a fluxurilor de date, ct i a proceselor, aa cum rezult din figura 7.3.
Enitate externa 1
Date-de-intrare-1
Entitate externa 2
Date-
Tranzactie 1 intermediare-1
3 Date-de-ieire-1
Tranzactie 3
Date- Date-
intermediare -2 intermediare -3
-
2 3
Date- 4
Date-
Transformare 2 memorare
pentru-
memorare
Tranzactie 4
Date-de-
intrare-2 Loc de stocare date
Date-de-ieire-2
Entitate externa 3
Enitate externa 1
Fig. 7.3 Model al fluxului informaional i al prelucrrilor
n figura anterioar, ptratul folosit red o entitate extern, adic o persoan, o aplicaie
sau alt sistem care produce informaii pentru a fi supuse transformrilor sau primete
informaii generate de sistem. Cercul reprezint un proces sau o transformare aplicat()
datelor, prin care datele sunt modificate. Linia cu sgeat reprezint una sau mai multe
structuri de date, indicnd modul n care circul datele n sistem. Cele dou linii paralele
nseamn un loc de stocare a datelor, prin care informaiile sunt pstrate pentru a fi folosite de
ctre 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 indicaii explicite asupra secvenei prelucrrilor sau a condiiilor logice de execuie a
acestora. Procedura sau secvena procedurilor este considerat implicit n cadrul DFD-urilor,
iar explicaiile detaliate sunt lsate pentru etapa de proiectare. De aceea, se consider c DFD
prezint, sub form grafic, activitile sistemului, ca rspuns la apariia unui eveniment.
De exemplu, n cazul sistemului de gestiune a clienilor, evenimentul este Clientul dorete

verificarea disponibilitii unui produs, declanatorul const n Cerere informaii despre
produse, sursa datelor o reprezint Clientul, rspunsul sistemului la eveniment const n
Informaii detaliate privind produsul, iar destinaia este reprezentat tot de Client.
De asemenea, DFD-urile reprezint primul pas ctre realizarea schiei de proiectare a
sistemului, semnificnd transpunerea sub form grafic a cerinelor utilizatorilor.
Aa cum am prezentat anterior, tehnica diagramelor fluxurilor de date apeleaz la patru
simboluri de baz pentru a reprezenta sistemele informaionale logice, nlocuind clasicele
scheme logice. Se consider, totui, c schemele logice de sistem, prin care se red configuraia
fizic a sistemului informatic, sunt mai sugestive dect o diagram; ns, pentru toate celelalte
cazuri, diagramele sunt net superioare, ndeosebi pentru reprezentarea logicii sistemelor
informaionale. Dar i schemele de sistem atrag anumite critici ntruct, prin apelarea n faza
proiectrii logice la unele simboluri speciale pentru discuri, CD-uri .a., se preiau unele
caracteristici specifice proiectrii 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 operaiunile care se efectueaz asupra datelor, fr s se acorde
atenie detaliilor fizice specifice proiectrii.
De aici trebuie reinut 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 fiier indexat pstrat 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 funcional a sistemului, n care a fost identificat structura din care este
alctuit, respectiv funciile, procesele, procedurile de prelucrare.
Nu exist o modalitate ideal de construire a DFD, datorit diferitelor probleme care apar
la nivelul sistemului i a particularitilor de abordare a acestora. Totui, exist o serie de
recomandri, redate n tabelul 7.3.
Tabel nr. 7.3 Recomandri privind construirea DFD
Nr. Recomandare Explicaii
crt.
1. nelegerea sistemului Se pleac de la tabelul evenimentelor, pentru a nelege ce urmeaz s
prelucreze sistemul, declanatorii, sursa i destinaia datelor i
informaiilor. Evenimentele i modul lor de grupare n procese ale
sistemului ar trebui s fie deja identificate, prin diagrama descompunerii
funcionale.
2. Ignorarea anumitor Scopul DFD este de a reprezenta grafic sursa datelor, fluxurile de
aspecte ale sistemului intrare, prelucrrile, locurile de stocare, fluxurile de ieire i destinaia
informaiilor. De aceea, toate procesele de control al securitii i
aciunile 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 granielor 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
incidena prelucrrilor sistemului, astfel nct s fie incluse n DFD
numai acele elemente strict necesare pentru a fi luate n considerare n
timpul proiectrii. Cnd exist dubii asupra unor elemente care par a fi
importante pentru sistem, este bine s fie ncorporate n DFD, pn se ia

crt.
decizia eliminrii sau pstrrii lor, eventual dup discuii suplimentare
cu utilizatorii.
4. Crearea diagramei de Sunt reprezentate entitile externe i fluxurile de date care intr/ies
context n/din sistem, fr a prezenta funciile, procesele i locurile de stocare.
Se pleac de la principalele elemente stabilite a fi incluse n sistem, prin
identificarea entitilor externe, a principalelor fluxuri de date prin
intermediul crora sistemul interacioneaz cu mediul su extern.
5. Identificarea fluxurilor Dup construirea diagramei de context, alturi de fluxurile ce fac
de date interne legtura 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
prelucrrilor. Se vor identifica elementele care iniiaz procesul: ce intr
n proces? E de preferat ca tot ce intr n proces s fie plasat la stnga
lui, pentru c, mai trziu, n timpul mbuntirii modelului, este foarte
uor s se concentreze atenia spre intrri numai prin simpla lor
localizare. De asemenea, se determin ieirile fiecrui proces sau a ceea
ce ar trebui s se obin 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 pn 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 Plecnd de la diagrama descompunerii funcionale, se identific pe
proceselor de nivelul 0 funciile prin care unul sau mai multe fluxuri de date intr
prelucrare n/din care pentru a fi supuse prelucrrilor n vederea obinerii ieirilor. Toate
intr/ies fluxurile de funciile trebuie s aib unul sau mai multe fluxuri de intrare i ieire. n
date plus, este momentul n care se stabilesc cu exactitate fluxurile ce fac
legtura ntre procese sau locuri de stocare sau aa-numitele fluxuri
interne sau intermediare ale sistemului.
8. Stabilirea locurilor de Fiecare flux care circul n sistem are ca surs sau destinaie locurile de
stocare a datelor stocare unde ar trebui s fie nregistrate sau de unde pot fi extrase. Este
momentul cnd se stabilesc exact fiierele, formularele sau alte
componente de care procesul are nevoie pentru realizarea complet a
transformrilor pe care le presupune. Aceste componente sunt, de
obicei, locuri de stocare a datelor apelate n timpul prelucrrilor, fiind
plasate deasupra sau sub proces.
9. Denumirea tuturor Cu excepia 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 ct mai bine structurile pe care le reprezint, fcnd
mult mai uoar citirea i nelegerea DFD. Prin stabilirea numelor
pentru fluxurile de date, analitii sunt forai s-i concentreze atenia
asupra tuturor fluxurilor de date importante pentru sistem i mai puin
asupra proceselor i locurilor de stocare. Din momentul n care fluxurile
au fost etichetate, denumirea proceselor i locurilor de stocare se
realizeaz relativ uor, pentru c, de multe ori, preiau cuvintele cheie ale
fluxurilor de intrare i ieire. De asemenea, numele locurilor de stocare
este dat pentru a sugera datele memorate. n privina proceselor, se
recomand ataarea unui nume i numr plecnd de la rezultatele pe
care le ofer. De exemplu, dac un proces conduce la obinerea
facturilor, el poate fi etichetat cu denumirea Crearea facturilor. Dac
procesul presupune mai mult de un singur eveniment, el poate fi
denumit folosind conjuncia 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 ct mai apropiat de ceea ce utilizatorul
face n activitatea sa curent. Numrul ataat procesului permite
analistului s-l identifice n cadrul sistemului i, ce e mai important, s
stabileasc legtura cu nivelurile superioare sau inferioare identificate n
timpul descompunerii funcionale.
10. Descompunerea DFD O diagram de nivel 0 este dificil de citit i neles. 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, aa cum
sunt redate n diagrama descompunerii funcionale. Astfel, diagrama de
context este descompus n principalele funcii ale sistemului,
obinndu-se diagrama de nivel 0, dup care fiecare funcie este
explodat succesiv n procese de nivel inferior, crendu-se aa-
numitele diagrame-copil.
11. Verificarea Construirea diagramelor presupune respectarea mai multor reguli, ce vor
diagramelor pentru fi descrise mai trziu, ceea ce nseamn c la finalizarea fiecrei
depistarea erorilor diagrame trebuie s se verifice dac au fost respectate, iar, n cazul
apariiei erorilor, trebuie corectate, pentru a nu fi propagate n
urmtoarele diagrame sau n specificaiile de proiectare. De asemenea,
se va urmri dac numele atribuite fluxurilor de date i proceselor sunt
relevante pentru a evidenia ct mai exact ceea ce se ntmpl n sistem.
12. Reluarea procesului de Analitii sunt nevoii s lucreze mai mult timp cu fluxurile de date, pe
construire a DFD msura evalurii 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. Pregtirea formei Se va realiza o copie final a fiecrei DFD astfel nct s poat fi
finale folosit ca parte distinct n documentaia sistemului. Fiecare pagin de
diagram trebuie s aib un nume, plecnd chiar de la numele procesului
de pe nivelul superior din care s-a obinut prin descompunere.
Recomandrile din tabel nu reprezint pai succesivi ce trebuie parcuri pentru construirea
DFD-urilor, pentru c unii dintre ei se pot desfura paralel (de exemplu, identificarea
elementelor din diagram i denumirea lor), altele se reiau n funcie de necesitile de
moment. Detalii privind aceste recomandri 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 combinaii ale numelor realizatorilor acestora. Din prezentrile ulterioare sperm s
atenum teama de diversitate. Tehnicile sunt foarte asemntoare, iar diferenele le vom puncta
la momentul potrivit.
7.3.2.1 Entitile externe (EE)
Entitile externe mai poart numele i de surs/destinaie sau ageni externi, fiind
locurile de unde intr sau ctre care ies documente, liste, situaii, informaii. Entitile 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 reprezentri fizice ale grupurilor de persoane, cum sunt clienii, furnizorii sau ale altor
sisteme, ca de exemplu Gestiunea stocurilor, Salarizare. Uneori, o entitate extern poate fi o
singur persoan (contabil-ef, preedinte etc.).
Legturile care se realizeaz ntre procesele de prelucrare i entitile externe, prin
intermediul fluxurilor de date (interfeele sistemului cu mediul extern), au ca suport circuitul
unor astfel de documente n cadrul organizaiei, purtnd de multe ori i denumirea de fluxuri
externe sau fluxuri finale, pentru c ele vin din afara sistemului (fluxurile de intrare, provenite
de la entiti) sau nu rmn n interiorul sistemului (fluxurile de ieire, care au ca destinaie
entitile externe). O entitate poate fi, la un moment dat, dar nu n acelai timp, att surs, ct i
destinaie.
Enitile sunt considerate externe sistemului pentru c nu intr n aria de modelare a
acestuia, adic a proceselor de prelucrare prin care entitile pun la dispoziia sistemului
fluxurile de intrare sau prin care preiau fluxurile de ieire.
Simbolurile convenionale folosite de cele dou tehnici sunt redate mai jos:
Gane & Sarson Yourdon & DeMarco
Ptrat ngroat Ptrat simplu
Fiecare entitate va avea un nume corespunztor, marcat printr-un substantiv, pentru a reda
ct mai bine ceea ce reprezint pentru sistem. Aceeai entitate poate fi folosit ori de cte ori
este nevoie de ea n cadrul unei DFD, pentru a se evita ncruciarea fluxurilor de date.
7.3.2.2 Fluxuri de date
Fluxurile de date, redate printr-o linie cu o sgeata la unul din capete (reprezentnd
destinaia 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 prelucrrii datelor unui proces poate fi specificat prin descrierea
procesului respectiv n depozitul metadatelor.
De regul, fiecare flux de date primete un nume sugestiv, care descrie numai o structur
de date, reprezentnd un document, un raport, date citite sau scrise dintr-un/ntr-un loc de
stocare, precum i date care sunt transmise ntre procese cu prelucrri on-line. De aceea,
denumirea fluxurilor ncepe cu un substantiv care s redea ct mai bine faptul c se preia sau
se transmite o structur de date necesar:
unui proces, cnd trebuie s fie supus prelucrrilor i este preluat de la o entitate
extern sau este rezultatul citirii unor nregistrri anterioare dintr-un loc de stocare;
unei entiti externe, cnd este rezultatul unui proces de prelucrare i este cerut de o
persoan, un alt sistem, o aplicaie, un birou etc.;
unui loc de stocare, cnd, n urma prelucrrilor, pe baza ei se adaug noi nregistrri, se
modific sau se terg nregistrrile anterioare.
n anumite situaii se impune ns prezentarea ctorva structuri de date pe o singur
sgeat (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 situaie apare atunci cnd 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 asemntor se ntlnete atunci cnd ntr-un proces de prelucrare intr n acelai timp,
de la aceeai surs, fluxuri diferite ca structur (de exemplu, de la depozit vin documentele
privind micrile 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 interpretrilor i analizei, fcnd mai
dificil nelegerea diagramelor.
Structurile multiple de date se pot descompune, la un moment dat, pe nivelurile inferioare
ale DFD, pentru a evidenia c fiecare intr sau iese ntr-o/ dintr-o alt procedur de prelucrare.
Se mai ntlnete o situaie aparte, atunci cnd se dorete redarea unei ramificaii a
aceleiai structuri de date, ceea ce nseamn c un flux se poate descompune, la cerere, avnd o
singur origine i multiple destinaii, aa 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 destinaii
Trebuie reinut 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 ncasai. Fluxurile corect denumite i care ar trebui
reflectate sunt Documente/date privind livrarea produselor, respectiv Documente/date
privind ncasarea.
Aa cum s-a menionat i la descrierea entitilor externe, fluxurile de date se pot ncadra
n dou categorii:
externe, care provin de la entitile externe i sunt supuse proceselor de prelucrare,
respectiv cele care sunt rezultatul unui proces de prelucrare i au ca destinaie entitile
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 prsesc sistemul (merg ntr-un alt proces de prelucrare sau ntr-un loc de
stocare). Atunci cnd un proces are nevoie de informaii 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 prelucrrii unor date rezultatul trebuie s asigure adugarea, modificarea
sau actualizarea unei nregistrri ntr-un loc de stocare, nseamn c din proces se
obine un flux intern de ieire.
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 prelucrrii.
n privina simbolisticii folosite de cele dou tehnici, nu exist diferene.
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 pstreaz n sistem pentru
utilizri viitoare. Ca i n cazul fluxurilor de date, locurile de stocare nu urmresc redarea unui
format fizic de pstrare a datelor, ci reprezint locaii sau metode prin care datele sunt pstrate
n sistem. Un loc de pstrare poate fi un fiier, un director, o tabel a unei baze de date, o baz
de date, un dosar, un registru, o nregistrare din agenda unei persoane, csua de e-mailuri a
unei persoane. Locurile de stocare pot conine date despre clieni, stocuri, comenzi, facturi
primite, facturi emise, state de salarii, pli, ncasri etc. Direcia fluxurilor de date ctre 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 nregistrri dintr-o baz de date este reprezentat tot
ca un flux de date, n sensul c o astfel de operaiune cere ca datele s fie citite nainte de a fi
terse sau modificate. Ca urmare, stocarea datelor se refer att la fiierele sistemelor de
prelucrare manual, ct 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 nenchis la dreapta Linii paralele
n varianta Gane & Sarson, locurile de stocare au cte un identificator unic, prezentat sub
form general Dnn, cum ar fi D1, D7. Cnd se intenioneaz redarea cu claritate a operaiunii
de stocare, simbolul ce poart acelai identificator (Dnn) poate fi multiplicat. n acest sens, la
stnga dreptunghiului alungit se plaseaz un triunghi care va purta acelai numr. El reprezint
numrul de apariii ale aceluiai simbol.
Exemplu:
D1 CLIENTI D1 CLIENTI
3 3
D1 CLIENTI
3
Prezena ntr-o diagram a fluxului de date a unui loc de stocare, care are o singur intrare
i o singur ieire, 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 prezena lui s sugereze un
fiier 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, operaiunea nu este logic necesar, ct timp datele
pot fi transferate i telefonic. Deci, scopul crerii fiierului este acela de a ajuta la operaiunea
de transfer date. Pe de alt parte, dac pe acelai suport s-ar pstra datele despre clienii ru
platnici pentru a fi prezentai responsabilului cu vnzrile, peste cteva zile, operaiunea este
logic necesar, chiar dac ea are doar o intrare i o ieire (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 funcie exercitat cu scopul transformrii datelor, utilizarea
lor pentru crearea unor noi date sau pentru reunirea mai multor date n vederea obinerii unor
informaii, sub forma rapoartelor, documentelor, situaiilor etc. De aceea, se recomand ca
fluxurile de date care prsesc procesul s fie ntotdeauna etichetate diferit fa de cele care
intr n proces, chiar dac ele redau, ntr-o anumit msur, aceeai structur de date, ele
nefiind, totui, identice, pentru c au suferit modificri.
Atunci cnd se modeleaz un proces, din punct de vedere logic, nu are importan dac el
este executat de un calculator, un alt echipament sau de ctre o persoan. Procesele sunt
organizate n cadrul diagramelor fluxurilor de date ntr-o secven corespunztoare ordinii lor
de execuie. Aa cum s-a discutat la descompunerea funcional, un proces poate fi descompus
n componente pentru a se scoate n eviden ct mai multe detalii privind prelucrarea datelor.
Procesele de prelucrare care se rsfrng 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 ieire a procesului i intrare n alt proces, nregistrare ntr-un loc de stocare
sau ieire ctre o entitate extern. Un exemplu al unui astfel de tip de proces l constituie
intrarea informaiilor privind salariile angajailor (tarif/or, sporuri etc.) ntr-un proces prin
care se creeaz statul de plat a salariilor;
2. citirea unor informaii din fluxul de intrare, fr modificarea lui, informaii ce vor fi
folosite pentru obinerea unei ieiri. O situaie des ntlnit o constituie verificarea codului
unui client din nregistrrile anterioare, pentru a determina dac este un client vechi sau nu.
Aceasta nseamn o prelucrare la nivelul nregistrrilor 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, obinerea unei liste a salariailor n ordine alfabetic pe baza datelor
preluate dintr-un fiier al salariailor, n care ordonarea a fost fcut dup marc;
4. preluarea datelor i transferarea unora dintre ele ctre alt proces de prelucrare. Un
exemplu de astfel de proces const n preluarea preului 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 funciei (rolului) procesului, fr ns a oferi prea multe detalii. De exemplu, este
improprie urmtoare denumire de proces: Verificarea contului pentru determinarea limitei de
creditare i stabilirea situaiei contului clientului. Un nume corect de proces ar putea fi:
Verificarea clientului. Astfel, se pot utiliza urmtoarele formate de atribuire a numelor de
procese:
denumirea procesului cu numele sistemului, atunci cnd 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 clienilor, sistemul de aprovizionare etc.
specificarea subsistemelor din care este format sistemul, apelnd 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 funcii de prelucrare, aflate pe nivelul 0 de
descompunere;
utilizarea formei generale verb+descrierea funciei pentru reprezentarea proceselor aflate pe
nivelurile detaliate de descompunere a sistemului. Verbul descrie tipul prelucrrii pe care l
execut, de genul Calculare, Verificare, Pregtire, Tiprire, Adugare etc. Descrierea
funciei ilustreaz ieirea specific procesului, cum ar fi: stoc, comand, raport, nregistrare.
Cteva exemple complete de nume ale proceselor aflate pe niveluri inferioare ale
sistemului: Calculare TVA vnzri, Verificare client, Pregtire factur livrare, Tiprire
raport comenzi aprovizionare, Transmitere confirmare de acceptare a comenzii, Verificare
sold client, Adugare nregistrare stoc etc.
Un proces trebuie s aib, aa cum am vzut deja, un numr unic de identificare, prin care
se indic poziia sa n cadrul nivelurilor de descompunere.
Simbolurile folosite pentru redarea proceselor de prelucrare sunt:
Dreptunghi cu coluri rotunjite Cerc
Ca regul general, se recomand ca erorile sau excepiile 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 excepiile pot fi descrise ulterior.
7.3.2.5 Descrierea legturii dintre procesele de prelucrare i locurile de stocare
Un loc deosebit de important n cadrul sistemului l reprezint datele ce sunt pstrate
pentru a asigura prelucrri ulterioare i pentru generarea ieirilor, elemente ce vor avea o
pondere semnificativ n activitile etapei de proiectare i implementare. n timpul analizei se
folosete 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 iniialele folosite pentru redarea acestor operaiuni.
Modelul va fi folosit n timpul modelrii conceptuale a datelor, fiind punctul de plecare n

identificarea principalelor entiti de date din diagramele entitate-relaie, dar i n timpul
proiectrii fizice, cnd se structureaz modulele programelor, plecnd de la operaiunile care
trebuie s fie executate asupra datelor pstrate n sistem.
O astfel de matrice, pentru sistemul de gestiune a clienilor de la firma ABC, este
prezentat n caseta 7.2.
Caseta nr. 7.2 Matricea legturilor dintre locurile de stocare
i procesele de prelucrare din sistemul de gestiune a clienilor
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
Generare rapoarte cataloage R
Inregistrare produse returnate
Inregistrare clienti potentiali

Generare rapoarte comenzi
Verificare existenta produs
Inregistrare comanda noua
Generare rapoarte livrari
Generare rapoarte clienti

Verificare stare comanda
Inregistrare promotii noi

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

procesul Verificare existen produs efectueaz o Citire (Read) de date din fiierul
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 fiierul
Client, dac noua comand este primit de la un client cu care nu s-a mai nregistrat
nici o tranzacie, sau Citete (Read) datele pentru identificarea clientului, eventual
Actualizeaz (Update) datele despre el. De asemenea, se Creeaz (Create) cte o nou
nregistrare n fiierele Comanda (pentru inerea evidenei comenzilor primite),
Produse comandate (pentru a ti ce produse au fost comandate), Tranzacii comand
(pentru pstrarea unui istoric al tranzaciilor cu clienii, pn la ncheierea lunii sau a
anului) i Livrri (pentru a nregistra data la care urmeaz s se fac livrrile). Apoi,
Citete (Read) nregistrri din fiierele Pachet promoii (pentru a se ti dac noua
comand se ncadreaz ntr-un pachet promoional) i Nomenclator produse (pentru a
afla preul produselor comandate).
7.3.3 Descompunerea diagramelor fluxurilor de date

n paragraful 7.1 se specifica faptul c diagrama descompunerii funcionale 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 funcii n care se
descompune sistemul pe primul nivel;
cte o DFD de nivel 1, numrul acestor diagrame fiind egal cu numrul funciilor de pe
nivelul superior care se descompun. n exemplul dat, se vor obine dou diagrame de
nivel 1, una pentru procesele obinute din descompunerea Tranzacie 1 i o diagram
pentru procesele rezultate din descompunerea Tranzacie 3. Dac ar fi fost descompuse
i Transformare 2, respectiv Tranzacie 4, s-ar fi obinut 4 diagrame de nivel 1;
cte o DFD de nivel 2, numrul diagramelor fiind dat de numrul proceselor de pe
nivelul 1 care s-ar fi descompus n proceduri. Pentru cazul luat, se obine doar o
diagram de nivel 2, pentru redarea procedurilor n care s-a descompus Proces 1.2;
cte o DFD de nivel 3, dac sistemul este descompus n continuare, pe acelai
principiu, ca n cazul diagramelor de nivel 1 i 2.
Plecnd de la aceste consideraii generale, vom descrie specificul fiecrei diagrame.
7.3.3.1 Diagrama de context
Diagrama de context este prima diagram de fluxuri de date care se construiete din setul
obinut n urma descompunerii funcionale. Prezint cele mai puine detalii, urmrind s scoat
n eviden graniele sistemului, prin identificarea legturilor cu entitile externe, prin
intermediul fluxurilor externe de date (de intrare i de ieire). Ca urmare, diagrama de context
conine 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 prelucrrile specifice scrierii sau citirii din aceste locuri. Dac apar situaii
cnd sunt prezentate locuri de stocare, nseamn c ele ies de sub sfera de influen a
sistemului modelat i trebuie reprezentate sub forma entitilor externe. Diagrama de context,
fr a fi particularizat, plecnd de la descompunerea funcional, este redat n fig. 7.8.
Pentru sistemul de gestiune a clienilor 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 clienilor
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
Comenzi-retururi Cataloage
0
Confirmari-cataloage
SGC
Rapoarte-comenzi-
livrari-ajustari
Decizii-politici-
creditare-clienti
Detalii-tranzactii-clienti
Conducere
Raport-
privind- Detalii- Comenzi-
tranzactiile livrari de-onorat
Conturi-
analitice
Banca
Contabilitate Depozit-livrari
Fluxurile de date i entitile externe din diagrama de context sunt preluate din tabelul
evenimentelor, dar, aa cum se tie, sistemul trebuie s rspund celor 20 de evenimente identificate,
ceea ce nseamn c figura prezint o combinaie 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 funcii ale
sistemului pe urmtorul nivel, respectiv diagrama de nivel 0. Procesul de trecere de la
diagrama de context la urmtoarele niveluri de detaliere este numit generic explodare. Prin
diagrama de nivel 0 sunt prezentate secvena funciilor de prelucrare, locurile de stocare
accesate, precum i enitile externe cu care sistemul interacioneaz. Fiecare funcie are un
identificator numeric care corespunde secvenei n care se execut.
Decizia privind funciile incluse de sistem este una deosebit de important, dar plasarea
lor n diagrama de nivel 0 este o decizie care se bazeaz pe subiectivitate. Dei nu exist reguli
stricte din acest punct de vedere, pot fi urmate cteva recomandri, n sensul c procesele care
se includ n diagrama de nivel 0 sunt cele care redau una sau mai multe dintre urmtoarele
aciuni:
un proces care asigur scrierea i/sau citirea dintr-unul sau mai multe locuri de
stocare a datelor;
un proces direct responsabil de obinerea i/sau transmiterea de date ctre una sau mai
multe entiti externe;
un proces care preia datele de la una sau mai multe entiti externe;
un proces care servete ca un descriptor de pe cel mai nalt nivel al pailor prin care
trec datele n timpul transformrii lor.
O alt modalitate de abordare a funciilor ce pot fi incluse ntr-o astfel de diagram se
aplic n cazul sistemelor care se bazeaz pe aplicaii informatice, caz n care opiunile din
meniul principal al aplicaiilor pot sta la baza reprezentrii funciilor 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 excepia proceselor, care sunt
unice, trebuie s se regseasc i pe nivelurile inferioare. Cu alte cuvinte, toate entitile
externe, fluxurile de date din diagrama de context trebuie s fie reprezentate i n diagrama de
nivel 0 i pe urmtoarele niveluri. Odat ce un loc de stocare sau entitate a fost identificat(),
este necesar s se regseasc pe toate nivelurile inferioare, obinute din descompunerea
proceselor cu care locul de stocare are o legtur.
Diagrama de context este explodat pentru a reda de la 3 pn la maxim 9 procese,
obinndu-se un prim nivel de detaliere a sistemului, astfel nct s ncap pe o singur pagin.
Prin explodarea proceselor n subprocese, analitii ncep s reprezinte detaliile despre trecerea
datelor prin diferite prelucrri. Excepiile sunt, n continuare, ignorate, cel puin pentru primele
2-3 niveluri de descompunere ale sistemului. Se consider c includerea a mai mult de 9
procese pe o pagin ngreuneaz nelegerea ei, devenind prea ncrcat cu fluxuri de date i
locuri de stocare. Exemplul general al unei diagrame de nivel 0 a fost prezentat n fig. 7.3.
Atunci cnd sistemul este descompus pentru obinerea diagramei de nivel 0, cu
principalele funcii/procese de prelucrare, construirea ei se va baza pe identificarea logic a
fluxurilor externe (de intrare i ieire) i conectarea lor la procesele corespunztoare pentru a
face legtura cu entitile externe, aa cum au fost reprezentate n diagrama de context. Sunt
situaii cnd, 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.
ncepnd cu DFD-0, i fac apariia fluxurile de date interne, adic cele care fac legtura
dintre procesele de prelucrare i locurile de stocare sau dintre procese. Aceste fluxuri se vor
regsi, n mod obligatoriu, pe urmtoarele niveluri ale DFD, n funcie 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, urmrind s se rspund
la ntrebri de genul: Ce se ntmpl la intrarea datelor n sistem?, Trebuie s fie
memorate?, Reprezint o intrare pentru mai multe procese?;
de la un flux de ieire, analizndu-se cmpurile lui, iar pentru fiecare cmp ce trebuie
generat de sistem se pun ntrebrile: De unde poate fi obinut?, Este un cmp
calculat sau este memorat ntr-un fiier?. De exemplu, cnd ieirea este Flutura,
atunci Nume salariat, Marc, Funcie ar trebui s se regseasc n fiierul Salariai,
Numrul de ore lucrate n fiierul Pontaje, iar Salariul brut, Impozitul, Reinerile
legale s fie cmpuri calculate etc. Fiecare fiier va putea fi conectat la procesul care
genereaz fluturaul;
cu analiza fluxurilor care intr sau ies dintr-un loc de stocare. Se ridic ntrebrile:
Prin ce procese sunt nregistrate/actualizate datele?, Ce procese apeleaz la datele
din locul de stocare respectiv?;
cu analiza proceselor definite n timpul descompunerii funcionale. Se vor umri datele
de intrare de care are nevoie fiecare proces i datele de ieire pe care ar trebui s le
genereze, dup care se vor conecta intrrile i ieirile la locurile de stocare i entitile
corespunztoare, prin intermediul fluxurilor de date care reflect acele intrri/ieiri;
prin notarea tuturor aspectelor asupra crora exist anumite incertitudini, urmrindu-se
formularea unor ntrebri 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
fragmentrii sau partiionrii sistemului, plecnd de la evenimente9. Astfel, se creeaz cte
un fragment de DFD pentru fiecare eveniment din tabelul evenimentelor sau proces identificat
la descompunerea funcional, prin care se reliefeaz modul n care sistemul rspunde acestuia,
redndu-se n detaliu interaciunile procesului cu locurile de stocare i entitile externe. Apoi,
fiecare fragment de DFD poate fi combinat pentru obinerea DFD de nivel 0.
Totui, de multe ori, se evit construirea diagramei de nivel 0 n varianta care se bazeaz
pe fragmentare, din cel puin dou motive:
1. sunt dublate informaiile pe care le conin att fragmentele de DFD, ct i DFD de
nivel 0, precum i eforturile de construire a mai multor diagrame care conduc, n final,
la acelai rezultat;
2. adesea o astfel de manier de construire pentru sistemele de dimensiuni mari este
complex, surprinznd evenimente multiple i diversificate.
n caseta 7.4 este redat diagrama de nivel 0 pentru sistemul de gestiune a clienilor ABC.
Diagrama de nivel 0 este folosit i n timpul proiectrii diagramelor entitate-relaie
(DER), pentru c prezint fluxurile de date i locurile de stocare pe baza crora se pot
identifica entitile de date i relaiile dintre ele. Conceperea celor dou diagrame se poate
realiza n paralel.
7.3.3.3 DFD de nivel 1 pn la n
Dup ce diagrama de nivel 0 a fost finalizat i verificat, pentru eliminarea erorilor i
asigurarea reprezentrii 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., pn cnd 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-printe (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-
Informatii-limita- vanzari Client derulate existente promotionale
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
clienti-
Comenzi Date- 3
Detalii- noi
client
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
asemntor situaiei subfluxurilor din DFD de nivel 0.

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

livrarile vanzari
Conducere
loc, dar i altele ce nu sunt reprezentate n diagrama de nivel 0. De exemplu, poate fi inclus un
descompus n subfluxuri, pentru a se stabili legturi distincte pentru fiecare subproces,
Dac procesul-printe este conectat la un loc de stocare, i diagrama-copil va conine acel

149
Caseta nr. 7.4 Diagrama fluxurilor de date de nivel 0 pentru sistemul de gestiune a clienilor
genereaz. Excepie face situaia n care fluxul primit/generat de procesul-printe este

poate primi sau nu poate genera un flux pe care procesul-printe nu-l primete sau nu-l
Prima regul de construire a diagramelor de nivel 1 const n faptul c un proces-copil nu
rezultatul explodrii lor, respectiv subprocesele, sunt denumite procese-copil/proces-fiu (child
fiier care s fac legtura ntre dou procese ale diagramei-copil. n plus, pot s-i fac
apariia i alte fluxuri de date, de importan mai mic sau de excepie, cum ar fi un flux cu
erori, dar, aa cum am specificat, nu este obligatoriu s se regseasc 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-printe, din care a fost obinut, printr-un sistem
de numerotare secvenial, plecnd de la cifrele alocate n DFD de nivel 0, conform
descompunerii din figura 7.3. De exemplu, procesul Tranzacie 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
aceleai fluxuri de date externe, care intr sau ies din procesul-printe, 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 clienilor 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 clienilor de la firma ABC.
Cteva comentarii privind diagrama din caseta 7.6:
aa cum se observ, procesul 1.2 se descompune n 4 subprocese: Inregistrare date
clienti, Inregistrare date comanda, Prelucrare comanda, Confirmare comanda, fiind
vzute ca patru pai principali necesari finalizrii activitii de primire a unei comenzi.
Aceast descompunere este doar o modalitate de divizare a prelucrrii, ali analiti
putnd s vin cu soluii diferite;
primul pas ncepe cnd 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 nregistrri, iar n cazul clienilor existeni, prin actualizarea
datelor, n funcie de situaie. Apoi, procesul 1.2.1 transmite informaiile despre
comand prin fluxul Date clienti comanda ctre 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 funcia Introducere comand,

din diagrama de nivel 0 a sistemului de gestiune a clienilor
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 crora creeaz o nou nregistrare n locul de
stocare Comenzi. Informaii 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 prelucrrilor din acest proces, se adaug o nregistrare n fiierul Tranzacii
comenzi, cu ajutorul fluxului Comanda posibil de onorat, obinut 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 informaii i pe baza celor

existente n fiier (fluxul Date comenzi nregistrate), are loc actualizarea comenzilor
nregistrate n fiierul Tranzactii comenzi (cu ajutorul fluxului Comanda confirmata,
cel de-al doilea subflux din Tip comanda). Tot din acest proces rezult informaiile
necesare pentru pregtirea livrrilor (Comenzi de onorat), care sunt transmise entitii
Depozit-livrari.
Caseta nr. 7.6 Diagrama de nivel 2 pentru funcia Inregistrare comanda noua,
din diagrama de nivel 1 a sistemului de gestiune a clienilor
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 Recomandri privind oprirea procesului de descompunere a sistemului

Se ridic o problem n privina momentului n care ar trebui s se opreasc
descompunerea. Este o decizie la fel de subiectiv, ca i cea privind stabilirea principalelor
funcii ale sistemului, dar o recomandare general sugereaz c ultimul nivel de descompunere
n-ar trebui s depeasc nivelul 7. Procesul de descompunere ar trebui s continue pn cnd
toate funciile i procesele au fost explodate pentru a evidenia un nivel de detaliere suficient
de relevant analizei. Cnd un proces a fost descompus la nivelul solicitat de detaliere, el este
referit ca o primitiv funcional, n sensul c primete un singur flux de intrare i genereaz
un singur flux de ieire.
O alt recomandare privind descompunerea face referire la faptul c funciile (aplicaiile)
trebuie s fie explodate, pe aceast cale, pn ce detaliile logicii procesului sau primitivele
pot fi scrise pe cel mult o pagin de pseudocod. n cazul sistemelor complexe, apar totui ca
necesare nivelurile 3 i chiar 4.
Chiar dac la prima vedere ar prea c nu exist reguli pentru a stabili momentul ncetrii
procesului de descompunere, pot fi luate n considerare urmtoarele recomandri:
cnd ntregul proces s-a redus la o singur decizie sau o singur operaiune specific
bazelor de date (restaurare, actualizare, creare, tergere sau citire);
cnd utilizatorii sistemului apreciaz c nu au nevoie de detalii mai multe sau cnd
analitii consider c, prin documentaie, au oferit suficiente amnunte, astfel nct
activitile urmtoare din sistem s se deruleze fr probleme;
cnd un flux de date nu mai trebuie s fie descompus pentru a arta c unor date li se
aplic un tratament, iar altora, unul diferit;
cnd se consider c analistul a scos n relief fiecare formular, tranzacie, 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;
cnd analistul apreciaz c s-a atins cel mai de jos nivel al procesului de
descompunere a opiunilor meniurilor sistemului i pentru fiecare dintre ele exist
cte un proces distinct.
Din prezentrile fcute rezult ca procesul de descompunere este destul de subiectiv. El
poate nceta n orice moment, cu intenia 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, indicnd principalele subsisteme ale sistemului;
3. pn la 7 diagrame de nivel 1, indicnd principalele funcii (aplicaii) ale fiecrui
subsistem;
4. pn la 49 de diagrame de nivel 2, indicnd detaliile fiecrei funcii sau ale fiecrei
aplicaii .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 concepia 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 schiarea unuia n curs de proiectare.
Sub form narativ, sistemele sunt descrise prin text, din care, n urma analizei i
selectrii 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 entiti i activiti (n varianta Gane&Sarson),
prezentat n figura 7.11 ca Lista intrrilor/ieirilor din/spre entitile externe.
Entiti externe (EE) Intrri de la EE Ieiri spre EE

Entitate extern 1 Date-de-intrare-1 Date-de-ieire-2
Entitate extern 2 Date-de-ieire-1
Entitate extern 3 Date-de-intrare-2
Fig. 7.11 Lista intrrilor i ieirilor 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 ieiri. Aceasta ar nsemna obinerea datelor din nimic.
Dac un obiect are numai ieiri, el este o surs.
2. Nici un proces nu poate avea doar intrri. Dac un obiect are numai intrri, el poate fi o
destinaie.
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 vnzri (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 primete datele de la o surs i le transmite unui loc de
stocare.
6. Datele nu pot fi transferate spre o destinaie 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/destinaie)
8. Datele nu pot fi transferate direct de la o surs la o destinaie. Trebuie folosit un proces de
trecere.
9. O surs/destinaie este etichetat printr-un substantiv.
Fluxuri de date
10. Un flux al datelor are doar o singur direcie de flux ntre simboluri. Chiar dac el poate fi i
bidirecional, 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 sgei de sensuri contrare, i nu una singur cu
vrfuri la ambele capete, deoarece procesul se realizeaz n momente diferite.
11. Ramificaia ntr-un flux de date nseamn c aceleai date se transfer dintr-un loc comun n
dou sau mai multe procese, locuri de stocare sau surse/destinaii (de regul, nseamn copii
diferite ale acelorai date).
12. Asocierea (unirea) dintr-un flux de date nseamn c exact aceleai date vin dintr-unul sau mai
multe procese sau locuri de stocare, sau surs/destinaie spre un loc de stocare comun.
13. Un flux de date nu poate reveni direct la procesul pe care l-a prsit. Trebuie s existe cel puin
un alt proces prin care s treac, s se efectueze trecerea prin alte procese i de aici s revin
fluxul iniial de date la procesul iniial.
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 sgeat de flux pot aprea mai multe
substantive nsemnnd un transfer gen pachet.
Simbol Incorect Corect
Proces
1.
2.
Stocare
3.
4.
5.
Simbol Incorect Corect
Surs/Destinaie
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 Exemplificri 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 direcionarea greit a sensului, astfel c poate rezulta un
proces care s aib numai fluxuri de intrare sau numai fluxuri de ieire. Fiecare proces
transform date i de aceea trebuie s primeasc cel puin un flux de intrare i s
genereze cel puin un flux de ieire. Aceast eroare poate afecta i alte procese, n sensul
c, atunci cnd un flux de ieire este reprezentat ca intrare, iar al doilea proces, care e
dependent de acea ieire, e posibil s nu aib intrri. i invers, dac un flux de intrare este
redat ca ieire, un alt proces e posibil s nu genereze ieiri, aa cum rezult din figura
7.13.
Procesul 1.2.1 nu are

Comanda Client
nici o ieire, ci
noua
numai intrri
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 dect

ieiri. Fluxul Detalii comanda
este greit direcionat, fiind
de fapt o ieire 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 ieire
2. conectarea locurilor de stocare i a entitilor externe ntre ele. Legturile ntre dou
locuri de stocare se pot stabili numai prin intermediul unui proces de prelucrare. Datele
nu pot s treac dintr-un fiier n altul sau de la o entitate la alta fr ajutorul unei
secvene de program sau al unei persoane, care execut manual un proces. n mod
similar, apare eroarea atunci cnd se stabilete o legtur direct ntre o entitate extern
i un loc de stocare, n sensul c entitatea nu poate interveni direct asupra nregistrrilor
dintr-un fiier fr s fie lansat n execuie un proces care s asigure acea aciune. De
exemplu, nu este posibil ca un client s intervin direct n fiierul de stocuri s vad dac
un produs este disponibil dect prin intermediul unei interfee (secven de prelucrare).
La fel, dou entiti externe nu se pot afla n relaie 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
dispoziie dect informaiile privind livrrile efectuate i nu despre toate comenzile
primite de firm la un moment dat, iar, n al doilea rnd, pentru obinerea raportului sunt
necesare procese de culegere a datelor de pe toate comenzile primite, sortarea i filtrarea
lor n funcie de anumite criterii, citirea unor informaii 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 funciei. Fiecare flux ar trebui s fie denumit printr-un
substantiv. ns nu trebuie exagerat, avnd n vedere semnificaiile i formele multiple pe
care le pot lua cuvintele din limba romn. De exemplu, nregistrare poate semnifica
att procesul de nregistrare a datelor ntr-un fiier, ct i setul de atribute ce formeaz o
nregistrare n fiier. La fel, cerere poate nsemna aciunea de interogare a unui fiier
sau de solicitare a unor informaii, 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
ctre 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 entitilor externe i locurilor de stocare
4. utilizarea unui numr 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 ieirile
indicate numai pe baza fluxurilor pe care le primete. n figura 7.15 este redat o astfel de
situaie;
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 informaii
1.2.3
privind preul
Prelucrare produselor
comenzi
Fig. 7.15 Exemplu de fluxuri insuficiente pentru obinerea unei ieiri

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

diagram-copil trebuie s aib aceleai fluxuri externe de date ca i cele conectate la
procesul-printe, din explodarea cruia a fost obinut. Pot s apar excepii de la aceast
regul, atunci cnd un flux este descompus n dou subfluxuri sau cnd apar fluxuri noi
interne la nivelul diagramei-copil. Cnd 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 cteva
DFD balansate, din care se observ c nivelul 0 al DFD (punctul b) are aceeai intrare (A)
i aceeai ieire (B) ca i diagrama de context (punctul a). La punctul c) este prezentat
explozia cercului numerotat cu 1.0. Se observ c exist aceeai intrare (A) i aceleai
ieiri (C i D) ca la punctul b). Aceast relaie trebuie s existe, pentru c diagrama 1.0,
respectiv punctul c), este o explozie a cercului 1.0, din punctul b). Acelai 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 Destinaie
a) Diagram de context
Sursa A C
2.0 A E
1.2
1.0
1.1 G
Fiier
D F 1.3
3.0
B 1.4 C
Destinaie D
b) DFD de nivel 0 c) Diagrama 1.0
D
3.1 I Fiier
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, ct timp procesul 2.0 este unul elementar
Se poate observa c apar i casetele entitilor 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 cnd sunt construite cu ajutorul instrumentelor
CASE, fiind deja memorate n sistem.
7.4 Depozitul metadatelor

n afara prezenei elementelor necesare ntr-o DFD, se va urmri ca acestea s fie descrise
detaliat n dicionarul proiectului, numit depozit de metadate (repository). El mai este ntlnit
i sub numele de baz de date a proiectului, enciclopedia proiectului, dicionar 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 dicionarul datelor, aa cum este
regsit n lumea bazelor de date, vom folosi cu precdere 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 poziie n depozit, poziie ce urmeaz
s fie completat de analist.
Depozitul metadatelor colecteaz i descrie termeni specifici, asigurnd nelegerea, de
ctre diferite persoane din firm, a semnificaiei noiunilor folosite n modelele sistemului,
fiind folosit pentru:
oferirea documentaiei sistemului i eliminarea redundanei n privina 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
conin;
oferirea punctului de plecare pentru proiectarea ecranelor i rapoartelor;
determinarea structurii locurilor de stocare i utilizarea lor n realizarea diagramelor
entitate-relaie i n proiectarea logic a datelor;
identificarea relaiilor dintre date sau cum o structur de date se afl n legtur cu o alt
structur;
descrierea logicii proceselor de prelucrare, ce vine n sprijinul generrii modulelor
programelor sistemului;
pstrarea informaiilor privind managementul proiectului, respectiv cerinele proiectului i
rezultatele ateptate, planificarea resurselor, a perioadelor calendaristice pentru fiecare
etap i activitate, echipa de dezvoltare a sistemului etc.
Depozitul metadatelor este creat prin analiza i descrierea coninutului fluxurilor de date,
a locurilor de stocare, a proceselor, entitilor externe i a datelor elementare. Fiecare loc de
stocare i flux de date ar trebui descrise prin prisma structurii corespunztoare, dup care
analiza trebuie extins pentru a include detalii despre datele elementare pe care le conin.
Logica fiecrui proces de prelucrare poate fi descris cu ajutorul englezei structurate, plecnd
de la datele care intr sau ies din el, precum i de la matricea CRUD, pentru reflectarea
operaiunilor 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 ntlnite aceste
componente, cu excepia proceselor, ale cror denumiri sunt unice;
2. tipul componentei: proces, flux de date, loc de stocare, entitate extern, dat elementar;
3. structura: diferit n funcie de tipul componentei, i anume:
n cazul fluxurilor de date i al locurilor de stocare, descrierea se realizeaz prin
prezentarea datelor elementare (cmpuri, atribute) din care sunt alctuite;
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 operaiunilor
care se execut prin intermediul acelui proces;
pentru entitile externe se apeleaz la descrierea rolului pe care l au, ce reprezint pentru
sistem, cnd i cum interacioneaz cu sistemul etc.
4. caracteristici: este prezentat lista proceselor care interacioneaz 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 frecvena apariiei unui flux de date, execuiei 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
aceleai. 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 proiectanii n stabilirea caracteristicilor fizice ale noului sistem.
(mrimea, culoarea), unitatea de msur, cantitatea, precum i metoda de plat ce va fi folosit.

numele, adresa, numrul de telefon al clienilor care au lansat o comand, dup care urmeaz
Pentru a ilustra cum este completat depozitul metadatelor se va apela la continuarea
proces, apelrii unui loc de stocare, aspecte privind volumul datelor i securitatea, n
unor formulare speciale. Indiferent de tipul comenzii, datele care trebuie preluate n sistem sunt
n primul rnd, din formularul de comand, rezult c trebuie preluate i memorate
elementele specifice produselor comandate: denumirea produselor i caracteristicile lor

comenzile primite de la clieni pot fi preluate prin pot, fax, telefon sau Internet, cu ajutorul
161
exemplului privind sistemul de gestiune a clienilor de la firma ABC. Aa cum s-a prezentat,
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 intervievrii, observrii utilizatorilor sau analizei procedurilor i altor
documente ale sistemului. Informaiile despre fiecare flux de date ar trebui s surprind:
1. un numr de identificare a fluxului sau un cod (opional);
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. destinaia fluxului de date (entitate extern, loc de stocare sau proces);
6. specificarea dac fluxul este o nregistrare ce intr sau iese dintr-un fiier sau o
nregistrare dintr-un raport, formular sau ecran. Dac fluxul conine date utilizate ntre
dou procese sau ntre un proces i loc de stocare, vor fi indicate ca fluxuri interne;
7. structura sau coninutul fluxului, care poate s aib la baz una sau mai multe date
elementare;
8. perioada de timp la care se nregistreaz datele (zilnic, sptmnal, imediat), dac este
vorba de un flux ce intr ntr-un loc de stocare;
9. alte comentarii i observaii privind fluxul.
n caseta 7.8 este prezentat un exemplu de descriere a fluxului de date ce reprezint
documentul folosit pentru adugarea 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 destinaia, aa cum rezult din
diagrama de nivel 0 din caseta 7.4.
La un moment dat, un flux poate fi descris doar printr-un singur cmp (dat elementar),
cum ar fi codul clientului folosit de o procedur de interogare pentru gsirea nregistrrilor
despre un anumit client.
Caseta nr. 7.8 Exemplu de descriere a unui flux de date
pentru sistemul de gestiune a clienilor la firma ABC
ID _________________________________________________________________
Denumire Comand nou
Descriere Conine informaii despre comanda clientului i este folosit pentru
actualizarea fiierului Client, crearea unei nregistrri n Comenzi, Nomenclator
produse
Sursa Destinaia
Client (entitate externa) Procesul 1.2 Introducere comanda
Tipul fluxului
Document Ecran Formular Raport nregistrare fiier
Structura datelor Perioada de prelucrare
Informaiile specifice formularului de comand La sfritul zilei
Observaii: Se va crea cte o nregistrare cu informaiile despre comand pentru
fiecare comand a fiecruia dintre clienii firmei. Comanda poate fi primit prin pot,
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 notaii
matematice11:
1. semnul egal (=) nseamn c fluxul de date este compus din;
2. semnul plus (+) semnific i
3. acoladele {} (n alte notaii asteriscul *) indic grupurile repetitive, care pot include i
anumite condiii, cum ar fi un numr fix de repetiii sau limite minime i maxime
pentru numrul repetiiilor;
4. parantezele rotunde () sau n alte notaii cele drepte [] redau posibilitatea de
apariie a unui element sau a altuia, toate incluse ntre paranteze, dar excluzndu-se
unul pe altul;
5. parantezele drepte [], n alte notaii cele rotunde ( ), nseamn prezena unui element
opional, ce poate fi omis n cazul ecranelor de introducere a datelor sau poate conine
spaii sau zero pentru cmpurile numerice din structura fiierelor.
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 regsesc 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 alctuit din Nume, Prenume, n cazul clienilor persoane fizice, sau Denumire societate,
Tip societate, n cazul clienilor persoane juridice. Fiecare grup de elemente trebuie s fie
descris pn cnd ntregul set este descompus n date elementare.
Cteva explicaii la figura 7.19:
Yourdon i DeMarco apeleaz la parantezele rotunde, (...), pentru a sugera construciile
opionale, i acoladele, {...}, pentru repetiii.
11. Kendall, K.E., Kendall, J.E. op. cit., p. 310; Oprea, D., Dumitriu, F., Meni, G. CASE proiectarea
asistat de calculator a sistemelor informatice, Ed. Universitii Al. I. Cuza Iai, 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 repetiia este redat prin semnul * (asterisc), apelndu-se, uneori, i la
descrierea indentat a cmpurilor elementare. n plus, Gane&Sarson recomand ca
structurile datelor s fie reduse la a treia form normalizat, iar coninutul locurilor de
stocare a datelor s fie prezentat prin reduceri la unul sau mai multe tabele relaionale
n forma a treia normalizat.
Atunci cnd 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 aplicaii nu vor fi vizibile, pentru c ele
sunt deja cunoscute, dar nu trebuie omise la descrierea structurilor. n aceast situaie 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 acelai
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 fiier, cum ar fi codul
produsului, care nu este solicitat de o anumit activitate economic, dar este necesar
pentru identificarea mult mai uoar a datelor despre produsul respectiv, fr riscul de
nclcare a unor restricii privind bazele de date;
cmpuri de stare, prin care se identific dac o anumit nregistrare este activ sau nu,
cmpuri ce sunt pstrate ntr-un fiier distinct, n funcie de valoarea crora se fac sau
nu anumite prelucrri asupra nregistrrilor respective;
coduri pentru identificarea tranzaciilor, folosite pentru a stabili tipul nregistrrilor,

atunci cnd un fiier conine mai multe tipuri. De exemplu, un fiier ce conine soldul
clienilor poate conine i valoarea produselor returnate, valoarea plilor efectuate;
controlul grupurilor repetitive cu ajutorul unui contor al numrului de cmpuri 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 pstrate n
fiiere 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 cte 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, opional, ce permite analistului s gseasc mult mai uor data elementar,
n situaia completrii automate a depozitului i nu numai;
2. numele datei elementare, care trebuie s fie ct mai sugestiv i s se bazeze pe denumirile
comune utilizate de majoritatea programatorilor i utilizatorilor;
3. alias-urile (pseudonime), reprezentnd numele sub care mai pot fi ntlnite n sistem. Alias-
urile sunt nume folosite de diferii utilizatori din diferite sisteme pentru aceleai lucruri. De
exemplu, Cod_cl poate fi regsit i sub forma Ct_client sau Nr_client, avnd aceeai
semnificaie.
4. o scurt descriere a datei elementare, n sensul prezentrii semnificaiei ei pentru sistem;
5. specificarea dac este o dat elementar de baz sau derivat. Este de baz atunci cnd
este introdus ca atare n sistem, cum ar fi Nume, Adresa, Oras, fiind memorat n fiiere
sau baze de date. Elementele derivate sunt cele create prin intermediul unui proces de
prelucrare, adic al unor operaii matematice sau logice, cum ar fi Valoarea total a
comenzii, care este rezultatul aplicrii funciei de nsumare asupra Valorii produselor dintr-
o comand. Analiza datelor elementare de baz sau derivate difer, oferind un mijloc de
identificare a cmpurilor sistemului ce necesit analize suplimentare.
6. lungimea, respectiv dimensiunea fiecrei date, care trebuie asigurat la memorare.
Lungimea datelor din ecranele de introducere a datelor sau cele tiprite pot s difere de cea
memorat, ns procedurile responsabile cu afiarea lor vor insera spaiile sau vor elimina
zerourile nesemnificative. Problema esenial o constituie stabilirea lungimii fiecrei date
elementare, pentru c unele dintre ele au o lungime standard, cum ar fi abrevierea judeelor,
codurile potale, numerele de telefoane. Pentru altele, lungimea trebuie stabilit de comun
acord ntre analiti i utilizatori, avnd n vedere urmtoarele consideraii:
lungimea datelor numerice trebuie s fie determinat prin identificarea celui mai mare
numr 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;
cmpurile pentru nume i adrese se stabilesc n funcie de cele mai frecvente apariii 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 ntlnite;
pentru alte cmpuri este util s se analizeze datele istorice din cadrul firmei pentru a
determina lungimea corespunztoare. De exemplu, examinnd o list cu prezentarea
produselor, se poate identifica denumirea care conine cele mai multe caractere,
urmrindu-se i determinarea unei valori medii;
Importana 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 informaiilor de ieire. De exemplu, dac numele unui client
este trunchiat, o notificare transmis prin pot poate s ajung totui 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 gseasc 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 ieire, folosind simboluri speciale, pentru a indica modul n care
vor fi prezentate datele, i anume:
X introducerea sau afiarea/tiprirea datelor alfanumerice
9 introducerea sau afiarea datelor numerice
Z afiarea zerourilor de la nceputul atributului ca spaii (suprimarea zerourilor
nesemnificative)
V indic poziia zecimalelor (cnd nu este inclus punctul zecimal), virgula virtual;
, inserarea unei virgule la afiarea unui numr
. inserarea unei punct la afiarea unui numr
/ inserarea unui slash la afiarea unui numr
- inserarea unei cratime la afiarea unui numr
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 afiat pe ecranele de introducere i folosit pentru a reduce volumul datelor de preluat i
al erorilor de introducere. Cnd se apeleaz la liste de tip drill-down, valorea predefinit este
cea selectat curent sau afiat cu alt culoare. Cnd se folosesc butoane radio, este selectat
opiunea pentru valoarea predefinit, iar n cazul apelrii la check box-uri, valoarea
predefinit este indicat prin bifare sau nu.
11. alte observaii folosite pentru a indica formatul datei calendaristice, validrile
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 puin o tranzacie n ultimii 5 ani
Caracteristici
Lungime ___6___ Nr. poziii zecimale ____ Alfabetic
Format intrare ___9(6)__ Alfanumeric
Format ieire ___9(6)__ Dat calendaristic
Valori predefinite _______ Numeric
Continous sau Discrete Baz Derivat
Criterii de validare
Continous Discrete
Limita superioar: <999999 Valoare Semnificaie
_______ _______________
Limita inferioar: >0 _______ _______________
Observaii: Cod client trebuie s treac printr-o funcie de verificare pe baz de
cheie de control modulo 11. Este derivat pentru c este generat automat, secvenial la adugarea
clientului n fiierul Clienti, fiind adugat 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. Cnd
aceast dat elementar va fi implementat n baza de date, i utilizatorii vor fi instruii pentru
exploatarea sistemului, va fi necesar s se listeze un tabel cu valorile pe care ar putea s le ia i
cu semnificaia abrevierilor folosite.
ID _________________________________________________________________
Denumire Culoare
Alias
Descriere Culoarea pentru fiecare tip de articol de mbrcminte
Caracteristici
Lungime ___2___ Nr. poziii zecimale ____ Alfabetic
Format intrare ___X(2)__ Alfanumeric
Format ieire ___X(2)__ Dat calendaristic
Valori predefinite _______ Numeric
Continous sau Discrete Baz Derivat
Criterii de validare
Continous Discrete
Limita superioar: ______ Valoare Semnificaie
Limita inferioar: ___AB____ _Albastru______
___AL____ _Alb__________
___VR____ _Verde________
Observaii:___________________________________________________________
Fig. 7.22 Formular descriere dat elementar de tip alfabetic, discret
7.4.4 Descrierea locurilor de stocare

Aa 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 cnd datele elementare ale fluxurilor de date
sunt grupate, pentru a forma un grup de nregistrri, este creat un loc de stocare. Pentru c un
flux de date poate s conin doar o parte din datele care formeaz structura unei nregistrri,
este necesar s se analizeze mai multe structuri de fluxuri pentru a avea o descriere complet a
locurilor de stocare. De exemplu, cnd se adaug o nregistrate pentru un client nou, se pot
include iniial numai informaiile cunoscute. Soldul contului, data tranzaciei i alte informaii
pot fi adugate n locul de stocare Clienti, dup ce au avut loc anumite operaii economice,
regsindu-se n diferitele fluxuri de date, pe baza crora se fac prelucrrile 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 regsit;
4. o scurt descriere;
5. tipul de fiier, respectiv dac este informatic sau specific sistemelor manuale (pe
suport de hrtie). Dac este automat, trebuie specificat formatul, fie c este vorba de o
baz de date relaional, o tabel a acesteia sau un fiier clasic. Dac este manual,
atunci se va specifica modul i criteriile n care se vor aduga informaiile prelucrate
de pe documente;
6. numrul maxim i minim de nregistrri, informaie care ajut la estimarea spaiului 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 aplicaii, dac este
cunoscut sau dac este cazul;
8. structura datelor, care ar trebui s aib denumirea deja n depozitul datelor, astfel nct
s se realizeze legtura 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. observaiile folosite pentru adugarea de informaii care nu se ncadreaz n nici una
din categoriile anterioare, cum ar fi momentul actualizrii datelor, al realizrii 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 Conine cte o nregistrare pentru fiecare client al firmei
Caracteristicile locului de stocare
Tipul Informatic Manual
Format Baz de date Fiier indexat Fiier secvenial
Mrimea nregistrrii (caractere) _200_ Mrimea blocului 4000
Numr de nregistrri: Maxim 45000 Mediu 4200
Procent cretere a nregistrrilor pe an: 6%
Nume structur de date: Client.dbf
Structura datelor: nregistrare client
Cheie principal: Cod client
Cheie secundar: Nume client
Cod potal
Observaii: nregistrrile din Nomenclatorul Clienti sunt copiate ntr-un fiier
istoric i eliminate dac un anumit client nu a mai cumprat nimic n ultimii 5 ani.
Un client poate fi pstrat chiar dac nu a cumprat 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 minispecificaie, datorit faptului
c este o mic parte din specificaia ntregului proiect este realizat pentru primitivele din
DFD-uri, explicnd logica i formulele prin care sunt transformate intrrile n ieiri (asupra
acestor aspecte vom reveni n capitolul privind modelarea logicii proceselor). Fiecare dat
elementar derivat trebuie s aib la baz o operaie logic sau matematic, pentru a reda
modul n care este obinut din datele elementare de baz sau altele derivate, create anterior, ce
sunt intrri n procesul curent.
ntocmirea specificaiilor proceselor urmrete trei obiective 12:
reducerea ambiguitii proceselor, fornd analistul s depisteze ct mai multe detalii
asupra modului de realizare a fiecrui proces, prin identificarea componentelor vagi,
neclare i reluarea interviurilor cu utilizatorii;
obinerea unei descrieri ct mai exacte a ceea ce se execut n sistem, urmnd a fi
inclus n specificaiile necesare programatorilor;
validarea proiectrii sistemului, asigurndu-se c un proces are toate intrrile necesare
obinerii ieirilor i c ele au fost reprezentate n DFD.
Se pot ntlni multe situaii n care specificaiile 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
ateniona echipa de proiectare c acele procese au deja codul surs. Categoriile de procese,
care, n general, nu solicit descriere sunt:
reprezentarea fizic a intrrilor i ieirilor, cum ar fi scrierea i citirea, fiind doar
operaii logice simple;
redarea unei validri a datelor, fiind relativ uor de executat. Criteriile de validare
sunt deja incluse n dicionar, la descrierea formularelor de introducere a datelor.
Totui, specificaiile sunt necesare pentru procesele de editare complexe;

cele care folosesc un cod surs deja existent, adic cele incluse ntr-un alt sistem sau
n sistemul curent ca subprograme sau funcii. Subprogramele sunt scrise, testate i
memorate, executnd o funcie 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 cte ori este necesar.
Fiecare specificaie de proces trebuie s includ un formular de descriere, cu urmtoarele
elemente:
1. numrul 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, apelnd la numele regsite n DFD. Numele datelor
elementare folosite n relaiile de calcul sau operaiile logice trebuie s fie identice cu
cele din depozitul metadatelor, pentru a asigura consistena lor i o bun comunicare;
5. lista fluxurilor de ieire, apelnd 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 nct salariaii s-i poat desfura activitile specifice;
7. numele subprogramului sau funciei corespunztoare 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 condiii i
formule ce permit firmei s-i desfoare activitile specifice. Formatul comun al
unei reguli include:
definiiile termenilor economici folosii;
condiiile i aciunile economice;
restriciile privind integritatea datelor;
formulele matematice;
operaiile logice;
secvena prelucrrilor;
relaiile dintre diferite evenimente;
9. dac nu exist suficient spaiu 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 ataa specificaiilor
procesului;
10. se vor comunica aspectele nerezolvate, prile 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 vnzare
Fluxurile de intrare
Comanda noua
Date modificare comanda
Date client
Date produs
Cantitate existenta
Fluxurile de ieire
Date comenzi noi si modificate

Tipul procesului Numele programului/funciei
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
rezultnd Cantitate posibil de onorat
transfer Cantitate posibil de onorat n Cantitate produs comand
transfer Cod produs comand n Cod produs posibil de onorat
Sfrit dac
Referire la: Nume descriere
Englez structurat Tabel decizional Arbore decizional
Observaii: 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 dorete livrarea produselor din comand. n aceste condiii, 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 specificaiile unui proces
Dei construirea depozitului de metadate, cu toate detaliile i descrierile fiecrei

componente a sistemului, pn la nivel de dat elementar, solicit un efort imens, rezultatele
i beneficiile obinute se vor vedea n timpul proiectrii, implementrii i ntreinerii, n special
n prezena instrumentelor CASE. n aceste etape, orice modificare efectuat asupra
elementelor din diagrame se propag la nivel de ntreg depozit, fr s mai fie necesar ca
analistul s rein toat schimbrile intervenite. Mai mult, depozitul metadatelor constituie
suportul esenial pentru generarea specificaiilor de analiz.
Rezumat
Crearea unor modele grafice ale sistemului este util pentru a obine o imagine mult mai clar
asupra principalelor componente ale acestuia, cu ajutorul diferitelor diagrame. Modelarea conceptual
(logic) a sistemului reprezint nceputul activitilor cu caracter tehnic din dezvoltarea unui sistem, cu
scopul de a completa specificaiile de analiz i pentru o redare cuprinztoare a elementelor ce vor fi
supuse proiectrii.
Procesul prin care analitii modeleaz funciile unui sistem reprezint o abstractizare a activitilor
fizice, cunoscut i sub numele de echivalen logic. Un pas important n procesul de abstractizare l
constituie descompunerea pe funcii de prelucrare a sistemului sau descompunerea funcional, prin care
se identific principalele componente ale unui sistem (funcii, procese, proceduri de prelucrare .a.),
obinndu-se o diagram a descompunerii funcionale.
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 definiie restrns, DFD-urile sunt o
metod de prezentare grafic a traseului logic pe care l parcurg datele prin diverse procese pn sunt
transformate n ieiri, rednd toate componentele logice ale unui sistem ntr-o singur reprezentare
grafic, respectiv intrrile, ieirile, prelucrrile i locurile de stocare, precum i graniele sistemului.
Indiferent de metodologiile folosite n realizarea unui sistem/aplicaie, toate apeleaz la operaiunea
de modelare logic a datelor i prelucrrilor sub form de diagrame, diferenele constnd doar n folosirea
mai pronunat a diagramelor pentru descrierea sistemului, ncadrndu-le n diagrame de context,
diagrame ale fluxurilor de date fizice i diagrame ale fluxurilor de date logice. Altele apeleaz la
combinaii de diagrame, tabele i forme descriptive.
Diagrama descompunerii funcionale 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; cte o DFD de nivel 1 pentru fiecare proces care se descompune
din diagrama de nivel 0; cte o DFD de nivel 2 pentru fiecare proces care se descompune din diagrama
de nivel 1; cte o DFD de nivel 3 pentru fiecare proces care se descompune din diagrama de nivel 2 etc.
Atunci cnd se construiesc DFD, pot s apar mai multe erori, dintre care cele mai comune sunt:
omiterea unui flux de date sau direcionarea greit a sensului; conectarea locurilor de stocare i
entitilor externe ntre ele; denumirea incorect a proceselor sau fluxurilor de date; utilizarea unui
numr prea mare sau prea mic de fluxuri; descompunerea nebalansat a diagramelor superioare n
diagramele-copil.
n afara prezenei elementelor necesare ntr-o DFD, se va urmri ca acestea s fie descrise detaliat n
dicionarul 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
poziie n depozit, poziie ce urmeaz s fie completat de analist.
1. Ce rol are diagrama descompunerii funcionale n modelarea sistemului?
2. Definii tipurile de diagrame ale fluxurilor de date ce pot fi construite n timpul analizei?
3. Enumerai cel puin patru avantaje ce pot fi obinute din modelarea sistemului cu ajutorul
diagramelor fluxurilor de date comparativ cu descrierea narativ a acestuia. Motivai avantajele.
4. Care sunt cele patru simboluri utilizate n modelarea sistemului cu ajutorul DFD?
5. Care este semnificaia conceptului de explodare a DFD?
6. Enumerai regulile privind procesele ce trebuie respectate la construirea DFD.
7. Enumerai regulile privind locurile de stocare ce trebuie respectate la construirea DFD.
8. Enumerai regulile privind entitile externe ce trebuie respectate la construirea DFD.
9. Care este rolul depozitului de metadate?
10. Care este coninutul formularului de descriere a unui flux de date?
11. Care este coninutul formularului de descriere a unei date elementare?
Probleme de echip
1. Plecnd de la experiena avut din momentul nscrierii la ultimul concurs de admitere i pn la un
eveniment ce a avut loc dup doi ani, ncercai s:
a) construii un tabel al evenimentelor;

b) dezvoltai o diagram a descompunerii funcionale, cu 2 niveluri;
c) construii diagrama de context i diagrama de nivel 0;
d) scoatei n eviden fluxurile care presupunei c ar fi interne sistemului i care sunt vizibile
din exterior.
2. Descriei, pe scurt, tranzaciile specifice pentru prelucrarea comenzilor de ctre Red Pizza, plecnd
de la urmtoarea prezentare:
Red Pizza dorete s implementeze un sistem pentru nregistrarea comenzilor primite prin
telefon. Cnd un client obinuit al firmei telefoneaz, i se solicit s specifice numrul su de telefon,
care, odat introdus, determin apariia pe ecran a numelui, adresei i data ultimei comenzi. Odat
preluat comanda, se calculeaz valoarea ei i TVA-ul, dup care este transmis la buctrie. Pe baza
comenzii, este emis i bonul de cas (chitana sau factura, dup caz). Cu diverse ocazii, sunt tiprite
diferite oferte speciale (cupoane) pe baza crora clienii pot obine 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). Sptmnal se obin rapoarte privind livrrile efectuate pentru a face
comparaie cu performanele din perioadele anterioare.
3. Construii diagrama de context i diagrama de nivel 0 pentru sistemul descris la punctul anterior.
4. Construii o diagram-copil pentru procesul prin care se adaug un nou client, din diagrama de nivel
0 anterioar.
5. Creai diagramele fluxurilor de date pentru urmtoarea situaie:
Job Part Time este o firm specializat n plasarea personalului la diferite firme, pe perioade
scurte de timp. Firma urmrete plasarea personalului cu un grad ridicat de pregtire n utilizarea de
aplicaii, cum ar fi procesare texte, baze de date, programare etc. Angajaii trebuie s treac de un
test de demonstrare a performanelor i abilitilor profesionale, pe baza cruia obin un certificat de
recunoatere a competenei profesionale. Sistemul descris n continuare este responsabil cu
pregtirea angajailor solicitai 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 angajri temporare. Dac
firma care a formulat cererea nu este nregistrat n fiierul Angajatori, se va crea o nou
nregistrare;
salariaii sunt selectai n funcie de calificrile i disponibilitatea lor. Locurile de stocare
Salariai part-time i cel al Cererilor de angajri temporare sunt folosite pentru a lista toi
candidaii calificai pentru locurile de munc oferite de angajatori;
se transmit contracte salariailor selectai. Informaiile se obin din Salariai part-time,
Angajatori i cereri de angajri temporare;
contractele semnate sunt folosite pentru actualizarea locurilor de stocare anterioare cu informaii
privind personalul angajat i perioada de angajare;
lunar, se tiprete un program de lucru pentru fiecare salariat. Informaiile sunt obinute din cele
3 locuri de stocare, fiind ordonate dup data angajrii fiecrei persoane;
sunt transmise notificri ctre firmele care au solicitat personal temporar, pentru a confirma data
de la care pot s se prezinte personalul ce deine calificrile necesare.
6. Creai o matrice CRUD pentru diagrama de nivel 0 de la problema anterioar.
CAPITOLUL VIII
Modelarea conceptual a datelor

(diagramele entitate-relaie, DER)
Obiective:
Discutarea necesitii i coninutului modelrii conceptuale a datelor
Prezentarea conceptelor utilizate n construirea diagramelor entitate-relaie
nelegerea modului de transpunere a regulilor economice n modelul conceptual al datelor
Prezentarea unui model general al DER pentru sistemele informaionale economice
Dup o abordare multipl a sistemelor informaionale, a importanei lor ntr-un organism

economic, am continuat cu prezentarea elementelor-cheie ale dezvoltrii sistemelor
informaionale, i chiar am redat modalitile determinrii cerinelor unui sistem. n momentul
de fa discutm despre structurarea lor, aflndu-ne la unul dintre cele mai importante
momente i obiecte din viaa sistemului. Importana rezid, ndeosebi, n statutul obiectului
supus discuiei: datele.
n capitolul anterior ne-am referit doar la structurarea logic a proceselor de prelucrare din
organizaie (enumerarea i legarea lor), regsit i cu denumirea de modelarea logic a
prelucrrilor.
Elementele eseniale erau diagramele ca instrument de lucru i datele ca obiect de
prelucrare. Insistm asupra acestui aspect, deoarece se produce un salt esenial n abordarea
sistemelor: abandonarea proceselor ce au loc n sisteme (ca importan n activitile de
analiz i proiectare) i trecerea datelor pe primul plan. De fapt, era chiar un paradox: se
ncerca realizarea unor sisteme ct mai stabile pe baza celor mai instabile componente ale lor,
procesele.
Ideea de structurare a sistemului oricum va rmne. Din aceast cauz considerm c se
cuvine s evideniem poziia datelor n abordarea sistemelor.
8.1 Aplicarea principiului abstractizrii n modelarea datelor

n acest paragraf vom ncerca s evideniem necesitatea i coninutul modelrii
conceptuale a datelor. n acest sens, va trebui s explicm n ce const aplicarea principiului
abstractizrii 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 abstractizrii permite stpnirea complexitii sistemului,
prin luarea n considerare, n mod ealonat, a diferitelor aspecte ale acestuia. La un moment
dat, analitii se vor concentra doar asupra anumitor aspecte, ignorndu-le pe celelalte, dar care
vor fi luate n considerare ulterior.
Concret, aplicarea principiului abstractizrii n modelarea datelor presupune operarea pe
trei niveluri, prezentate n figura 8.1: conceptual, logic i fizic. Corespunztor celor trei
niveluri, pot fi identificate trei activiti eseniale n proiectarea bazelor de date:
analiza cerinelor 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
Cerinele de date ale

sistemului
Modelul conceptual al datelor

(modelul entitate - relaie)
Regulile i conceptele Cerinele de calitate
modelului relaional (flexibilitate, stabilitate etc.)
Modelul logic al datelor

(modelul relaional pur)
Cerinele nefuncionale i Facilitile 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 urmrete construirea unui model al datelor care
s asigure transpunerea exact a realitii din domeniul analizat, fr a lua n considerare
cerinele specifice unui model de organizare a datelor (cum este modelul relaional), criteriile
de calitate privind organizarea datelor, cerinele nefuncionale ale sistemului i criteriile de
performan privind stocarea i accesarea datelor. Modelul conceptual al datelor nseamn o
form de reprezentare a datelor organizaiei astfel nct el s reflecte regulile de derulare a
afacerilor n firma respectiv. Rolul su este de a scoate n relief toate regulile privind
identitatea i legturile existente ntre date.
Cea mai cunoscut form utilizat pentru modelarea conceptual a datelor este diagrama
entitate-relaie (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 legturile dintre entitile de date nu
intereseaz n acest moment, atenia 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 restricii de integritate, reprezentnd modelul logic al datelor.
Modelarea logic presupune organizarea datelor n tabele i coloane, conform regulilor
modelului relaional (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
relaional i a criteriilor de calitate ale modelului logic al datelor, aspecte ignorate n etapa
modelrii conceptuale. De exemplu, modelul relaional nu permite implementarea relaiilor
multe-la-multe dintre dou entiti de date, motiv pentru care acestea trebuie transformate n
dou relaii unu-la-multe.
Scopul urmrit const n obinerea unui model relaional pur, nealterat de cerinele
nefuncionale i cele de performan n stocarea i accesarea datelor, nici de facilitile 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 proiectrii fizice, este invizibil utilizatorilor i
programatorilor. El specific modul de stocare i accesare fizic a datelor, utiliznd facilitile
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 operaiune.
Aadar, obiectivul principal urmrit n cadrul acestei activiti const n optimizarea

performanelor bazei de date, n ceea ce privete stocarea fizic i accesul la date.
Luarea n considerare a acestor aspecte poate implica alterarea modelului logic (adic a
modelului relaional pur), presupunnd uneori prejudicierea aspectelor calitative ale acestuia.
n unele situaii, timpii de acces cerui pot fi obinui prin intermediul indecilor, ns, de multe
ori, este necesar modificarea structurii logice a datelor, prin procesul denormalizrii. Dac, la
proiectarea schemei logice, s-a urmrit prezervarea integritii datelor, prin procesul de
normalizare, acum poate deveni necesar introducerea unui anumit nivel de redundan a
datelor sau a cmpurilor calculate n schema bazei de date. Principala provocare const n
gsirea compromisului ntre uurina pstrrii integritii datelor i performanele bazei de date,
prin prisma stocrii i accesrii datelor. Soluia ideal ar presupune obinerea performanelor
cerute n condiiile pstrrii aspectelor calitative ale modelului logic, ceea ce este posibil
numai n condiiile separrii 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 facilitile oferite de
SGBD-ul ales. Diferenele dintre diferite SGBD-uri se refer adesea la tipurile de date
suportate, reprezentarea sau nu a relaiilor dintre clase i subclase, implementarea relaiilor
recursive. De exemplu, n mediul Oracle nu se poate lucra cu date de tip boolean (logic).
Aadar, construirea modelului conceptual al datelor constituie doar o prim activitate n
proiectarea bazei de date. n continuare, ne vom concentra asupra analizei cerinelor sistemului
i construirea modelului conceptual al datelor, respectiv a diagramei entitate-relaie. Mai nti
vom vedea care sunt informaiile care trebuie colectate, n scopul modelrii conceptuale a
datelor, iar apoi care sunt conceptele, regulile i demersul pentru transpunerea lor n diagrama
entitate-relaie.
8.2 Culegerea informaiilor pentru modelarea

conceptual a datelor
Culegerea cerinelor informaionale se realizeaz n faza de analiz a sistemului, prin
intervievarea utilizatorilor sau pe alte ci. Metodele de determinare a cerinelor trebuie s fie
orientate, prin ntrebrile puse, prin anchetele efectuate, i asupra datelor, nu numai asupra
proceselor i logicii lor. La nceput, chiar fr utilizarea unei terminologii de specialitate,
analistul va fi preocupat de modul n care va afla ct mai multe informaii despre datele
necesare viitorului sistem pentru a funciona la parametrii proiectai. ntrebrile vor fi astfel
formulate nct s se realizeze o bun nelegere 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: cnd i
cum sunt prelucrate sau folosite datele, pentru a se realiza modelarea datelor.
Obiectivele majore ale analizei cerinelor privind datele vizeaz 1:
descrierea cerinelor de date ale sistemului n termenii entitilor de date;
colectarea informaiilor care descriu entitile de date i relaiile dintre ele;
determinarea tranzaciilor ce vor fi efectuate asupra bazei de date i descrierea
interaciunii dintre tranzacii i entitile de date;
definirea cerinelor nefuncionale ale bazei de date, cum ar fi cele legate de
performane, integritate, securitate, administrarea datelor;
specificarea platformei hardware i software pe care va fi implementat baza de date.
Modelarea datelor se realizeaz printr-o combinaie a punctelor de vedere.
Un prim punct de vedere, formulat n literatur sub numele de metoda top-down, va scoate
n eviden regulile derulrii activitii firmei, printr-o nelegere 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 organizaie ecranele,
rapoartele sau documentele.
Literatura2 recomand mai multe modaliti de formulare a ntrebrilor astfel nct s se
obin informaiile 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 interacioneaz ntr-o unitate economic i este necesar
culegerea datelor despre ele pentru a fi pstrate o anumit perioad de timp? Cte
cazuri (instane) pot exista pentru fiecare obiect? entiti de date i descrierea lor.
2. Ce caracteristic (caracteristici) unic (unice) ajut la diferenierea obiectelor de
acelai tip? Elementul care ajut la diferenierea obiectelor de acelai tip are caracter
permanent sau este unul temporar? Elementul caracteristic al unui obiect poate lipsi
atunci cnd noi tim cu certitudine c obiectul exist? cheia primar.
3. Ce caracteristici se folosesc pentru descrierea fiecrui obiect? n ce mod se vor
efectua referirile, seleciile, calificrile, sortrile i clasificrile obiectelor? Ce trebuie
s se tie despre fiecare obiect astfel nct s se asigure buna funcionare a unitii?
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 cunoaterea
celor care au controlul semnificaiei datelor.
5. Care ar fi perioada de apartenen a datelor ce ne intereseaz? Este necesar
cunoaterea trendului datelor sau numai valoarea lor la un moment dat i/sau valorile
estimate/proiectate ale lor? Cnd o caracteristic a unui obiect se schimb n timp,
trebuie cunoscut ulterior valoarea anterioar? cardinalitatea i dimensiunea
temporal a datelor.
6. Toate cazurile (instanierile) sub care poate s existe un obiect sunt identice?
Exist obiecte cu un comportament special n organizaie? Exist unele obiecte care
sintetizeaz sau reflect forma combinat a altor obiecte mult mai detaliate?
supertipuri, subtipuri i agregri.
7. Ce evenimente contribuie la asocierea obiectelor ntre ele? Ce activiti fireti sau
care tranzacii economice presupun folosirea datelor despre cteva obiecte de acelai
tip sau de tipuri diferite? relaiile, precum i cardinalitatea i gradul lor.
8. Fiecare activitate sau eveniment are aceeai form de manifestare sau exist i forme
ce caracterizeaz anumite circumstane? 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, informaiile necesare construirii modelului datelor
se pot obine i prin urmrirea documentaiei 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 regsete un model de descriere narativ pentru sistemul de gestiune a
clienilor, prezentat n capitolele anterioare, ns el este uor orientat spre cerinele privind
datele. Pe baza lui, vom ncerca s punem n eviden, pe parcursul paragrafelor urmtoare,
activitile desfurate pentru construirea DER i modul n care poate fi citit aceast
documentaie.
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 utilizrii produselor CASE, construirea DER pornete de la analiza diagramelor

fluxurilor de date i a detaliilor cuprinse n depozitul de metadate.
Caseta nr. 8.1 Descrierea cerinelor sistemului de gestiune a clienilor
A. Descrierea tranzaciilor i prelucrrilor din sistem
Principalele clase de tranzacii nregistrate n sistemul de gestiune a clienilor sunt:
1. Primirea comenzilor de la clieni. Livrarea produselor se face numai n baza unei comenzi, emis
de un client, iar o comand poate conine unul sau mai multe produse. La primirea comenzii,
sistemul va verifica situaia contului pentru clientul respectiv i existena unor stocuri suficiente
pentru produsele de livrat. n funcie de rezultatele celor dou operaiuni de verificare, se va stabili
starea comenzii, respectiv de onorat, amnat sau respins. Din momentul acceptrii comenzii, se
nregistreaz obligaia 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 cantitilor prevzute, operaiune nregistrat pe baza
facturii emise la depozit. Conform politicii firmei, nu se accept dect onorarea printr-o singur
livrare a ntregii comenzi, ns pot exista situaii n care printr-o singur livrare s fie onorate mai
multe comenzi, dar ale aceluiai 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
livrrii, se vor efectua urmtoarele operaiuni de actualizare:
modificarea strii 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 diminurii lui cu cantitile livrate;
modificarea soldului clientului, n sensul incrementrii lui cu valoarea livrrii.
modificarea tipului clientului, dac este prima livrare, iar clientul respectiv a fost nregistrat
anterior drept client potenial.
3. Returnarea produselor de ctre clieni. n cazul n care clientul constat unele defeciuni la
produsele primite sau c ele nu corespund cu cele comandate, el va avea posibilitatea returnrii lor,
nsoite de nota de refuz. Sunt posibile att situaia returnrii pariale, ct 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 creia s-a fcut livrarea. n acest fel, sistemul
va fi n msur s ofere informaii despre livrrile crora le corespunde o returnare, n vederea
stabilirii persoanelor vinovate. n baza notei de refuz, pentru fiecare returnare se va ntocmi o
factur de stornare, parial sau integral, de ctre depozitul care a emis factura, ce corespunde
unei singure livrri. Odat cu nregistrarea facturii de stornare, se va actualiza soldul clientului i
stocul de produse.
Legend: rou = entitate; verde = relaie; albastru = cardinalitate
B. Descrierea documentelor primare din sistem
n cadrul sistemului, se utilizeaz urmtoarele documente:
1. Comanda este emis de client i conine urmtoarele categorii de date: datele de identificare a
comenzii (numrul i data), datele de identificare a clientului (numele i adresa), datele privind
produsele comandate (codul, denumirea, unitatea de msur, cantitatea comandat) i condiiile de
livrare (termenul de livrare).
2. Factura reprezint documentul de nsoire a produselor livrate i conine: datele de identificare a
facturii (numr i data), datele de identificare a clientului (nume, adresa, cod fiscal, numr registru
comer), datele privind produsele livrate (cod, denumire, unitate de msur, 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 returnrii pariale sau integrale a produselor livrate.
Acest document conine urmtoarele categorii de date: date de identificare a documentului (numr
i data), datele de identificare a clientului (numele i adresa), datele de identificare a produselor
returnate (cod, denumire, unitate de msur, cantitate returnat) i alte date (motivele returnrii,
numrul facturii cu care au fost livrate anterior produsele).
C. Descrierea principalelor rapoarte generate de sistem
n urma solicitrii utilizatorilor, sistemul va furniza urmtoarele rapoarte:
1. Raportul privind comenzile de onorat este elaborat la nceputul fiecrei sptmni i conine
informaii despre comenzile ce urmeaz a fi onorate n sptmna respectiv. Aceste informaii se
refer la: codul, numele i adresa clientului; codul, denumirea i unitatea de msur a produselor;
cantitile de livrat; data livrrii.
2. Raport privind potenialii clieni, ntocmit lunar sau la cererea conducerii, conine informaii
despre clienii care au solicitat cataloage de produse, dar care nu au iniiat nc nici o comanda de
cumprare. n acest raport se includ numele i adresa .
3. Raport privind vnzrile, ntocmit la cererea utilizatorilor, conine informaii despre livrrile
efectuate ntr-o perioad dat, pe depozite sau la nivelul firmei. n raport se includ codul i numele
depozitului; numrul i data facturii; codul, denumirea, unitatea de msur i preul produselor;
cantitile livrate; valoarea vnzrii; totalul vnzrilor pe depozite i totalul general al vnzrilor.
8.3 Introducere n cadrul conceptual al

diagramelor entitate-relaie (DER)
Dei diagramele entitate-relaie (DER) se cunosc de ctre muli specialiti din lumea
bazelor de date, ele constituie unul din conceptele eseniale ale analizei i proiectrii
structurate i, ca atare, provin din acest domeniu. De fapt, una din lucrrile de referin ale lui
P.P. Chen, autorul modelului, este destul de relevant: Entity-Relationship Approach to
Systems Analysis and Design (Metoda entitate-relaie n analiza i proiectarea sistemelor),
aprut n anul 1980, dei modelul a fost conceput n anii 1976-1977.
Dup cum reiese i din citirea numelui diagramei, scopul ei este de a evidenia entitile
de date (obiectele despre care se solicit pstrarea datelor) i relaiile ce exist ntre ele.
De remarcat diferena dintre diagrama fluxului de date i diagrama entitate-relaie. n timp
ce diagrama fluxurilor de date indic att procesele de prelucrare, ct i entitile de date
(redate sub forma locurilor de stocare), DER trateaz doar entitile de date. Din aceast cauz,
DER poate fi considerat i ca diagrama modelului datelor sau diagrama conceptual a datelor.
n plus, DER evideniaz i descrie relaiile dintre entitile de date, aspecte ignorate n DFD.
ntotdeauna, crearea unei DER presupune gsirea rspunsului la ntrebarea: Care sunt
entitile despre care sunt necesare datele de stocat?. Rspunsul 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 entitii s fie redat printr-un substantiv la singular
(CLIENT, PRODUS, SALARIAT etc.).
Dup ce se identific entitile, se continu cu mperecherea lor, fiecare cu fiecare, pentru
a descrie ce relaii exist ntre ele. Relaiile dintre entiti pot fi reprezentate printr-un romb.
De exemplu, pentru a arta c o anumit vnzare se refer doar la un client, dei exist
mult mai multe acte de vnzare, implicit mai muli clieni, relaia poate fi redat schematic ca
n fig. 8.2. Acest aspect face referire la cardinalitate, concept care va fi detaliat n unul din
paragrafele urmtoare i care este pus n eviden prin cele dou perechi de valori cuprinse
ntre paranteze.
(1,1) (0,M)
CLIENT Particip VNZARE
Fig. 8.2 DER pentru relaia Particip ntre entitile CLIENT i VNZARE
O vnzare, la rndul ei, const din unul sau mai multe produse, dar i produsele pot
constitui subiecte ale mai multor vnzri, deci ntre entitile VNZARE i PRODUS ambele
perechi de valori ce reprezint cardinalitatea vor conine valoarea M (adic multe). Continum
cu descrierea legturilor/relaiilor posibile: un PRODUS este n legtur direct doar cu o
singur nregistrare STOC, i invers. Antrennd n sfera discuiilor i comanda de

aprovizionare, COMAND_APROVIZIONARE, i furnizorul, FURNIZOR, s-ar putea
construi diagrama entitate-relaie din fig. 8.3.
Entitile conin 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, relaiile pot avea atribute? Dac da, prin ce difer ele de cele ale entitilor?
Sublinierile sunt binevenite, ntruct problema pus n discuie este de o importan deosebit.
O serie de analiti fac distincie net ntre cele dou tipuri de atribute, ale entitilor i ale
relaiilor, n timp ce alii nici nu le sesizeaz prezena. Elementele de derut provin i din
existena unor entiti despre care se poate spune c descriu relaii. n exemplul de mai sus,
despre entitatea COMAND_APROVIZIONARE se poate spune c deine informaii despre
relaia cumprat de la dintre PRODUS i FURNIZOR. Concluzia la care se poate ajunge:
exist entiti purttoare de relaii dintre alte entiti; deci, cu alte cuvinte, printr-o entitate se
poate prezenta o relaie.
(1,1) (0,M)
CLIENT Particip VNZARE
(0,M)
Conine
(1,M)
(0,1) (1,1)
STOC Are PRODUS
(1,M)
Conine
(0,M)
(1,1) (0,M) COMAND_

FURNIZOR Implic
APROVIZIONARE
Fig. 8.3 Diagrama entitate-relaie pentru operaiunea

de vnzare-cumprare
Analiza entitate-relaie este o operaiune deosebit de important pentru scoaterea n relief

a datelor, de fapt a structurii lor. n unele metodologii, cum ar fi ingineria informaiei,
aceasta constituie principalul instrument analitic, n timp ce n altele analizele entitate-relaie
se folosesc n combinaie cu analizele fluxurilor de date.
8.4 Coninutul i etapele activitii de modelare

conceptual a datelor
Dup cum s-a putut observa anterior, DER este construit pe baza a trei tipuri de obiecte:
entiti de date, relaii ntre entiti i atribute care descriu entitile i relaiile. Prin urmare,
modelarea conceptual a datelor presupune parcurgerea urmtoarelor etape:
identificarea entitilor de date,
descrierea entitilor de date prin intermediul atributelor,
definirea relaiilor dintre entiti i
descrierea relaiilor, apelnd la conceptele grad, cardinalitate, rol, atribut.
n continuare, vom descrie pe larg fiecare din aceste etape, ocazie cu care vom introduce
att conceptele, ct i regulile pentru construirea DER.
8.4.1 Identificarea entitilor de date

Dup exemplele date, considerm c semnificaia entitii 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 organizaia dorete s pstreze anumite date.
Se cuvine precizat diferena dintre tipurile entitilor (entity types) i cazurile/instanele
entitii (entity instances).
Tipul entitii, cunoscut i sub numele de clasa entitii, este o colecie de entiti care au
proprieti sau caracteristici comune. Fiecrui tip de entitate i se atribuie un nume, conform
descrierilor i exemplelor anterioare. Ct timp numele reprezint o clas sau un set de cazuri, el
este singular. i nc o convenie. Cum referirea general la elementele ce pot fi catalogate ca
entiti se face prin noiunea de obiect (dei sensul lui poate fi altul n contextul analizei i
proiectrii orientate- obiect), referirea la acesta se va realiza printr-un substantiv la singular. Se
vor folosi litere majuscule, plasate n interiorul dreptunghiului corespunztor entitii.
O instaniere a entitii sau o instan, numit de noi, n continuare, caz al entitii 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/instane stocate n baza de date. Noi vom
utiliza termenii de entitate i instan a entitii.
n sistemele informaionale economice, majoritatea entitilor de date pot fi clasificate n
trei categorii distincte3: resursele utilizate n cadrul firmei, evenimentele (activitile
economice) n care este angajat firma i agenii participani la aceste evenimente.
Resursele sunt acele obiecte care au valoare economic i care sunt necesare pentru
desfurarea activitii din firm. Stocurile de materii prime i produse, mijloacele fixe,
disponibilitile bneti sunt exemple comune de entiti-resurs.
Evenimentele se refer la activitile economice care afecteaz resursele i n legtur cu
care conducerea dorete s se colecteze informaii, n vederea exercitrii funciilor de
planificare i control. Majoritatea evenimentelor reinute n DER se ncadreaz n una din
urmtoarele dou categorii: tranzacii economice (economic exchanges) i obligaii-
angajamente (commitments). Tranzaciile economice sunt acele activiti care afecteaz n mod
direct resursele reinute n sistem. De exemplu, tranzacia de vnzare implic scderea
stocurilor, iar cea de ncasare va genera o sporire a disponibilitilor bneti. n schimb,
angajamentele nu afecteaz imediat nici o resurs, ele reprezentnd o promisiune din partea
firmei de participare la tranzacii viitoare. De exemplu, comanda primit de la un client va
genera ulterior una sau mai multe tranzacii de vnzare. n afara faptului c aceste entiti
stocheaz date despre obligaiile firmei derivate din relaiile de afaceri, ele sunt importante i
n activitile de control i planificare. De regul, astfel de evenimente preced tranzaciile
economice, iar modelul conceptual poate ngloba cerinele de implementare a unor proceduri
de control. De exemplu, nu se va admite derularea unei tranzacii de vnzare fr existena n
prealabil a unei comenzi. De asemenea, astfel de entiti ofer informaiile necesare activitii
de planificare. Pe baza informaiilor despre comenzi se va realiza planificarea vnzrilor.
Agenii reprezint persoane sau organizaii care particip n evenimentele reinute n
sistem i n legtur cu care se dorete memorarea de date, din considerente de planificare,
control sau evaluare. Angajaii, clienii sau furnizorii, bncile sunt exemple de entiti-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 entiti, respectiv locul n care se realizeaz un
eveniment, n timp ce alii consider c nu mai este necesar introducerea acestei categorii,
deoarece astfel de entiti se refer adesea la resursele angajate n evenimentul respectiv4 sau la
agenii angajai ntr-un eveniment (completarea noastr). Exemple de astfel de entiti sunt
depozite, secie de producie etc. Depozitul reprezint locul n care este nregistrat o tranzacie
de intrare sau ieire a bunurilor materiale din stoc.
n afara acestor entiti, s le spunem concrete, exist i alte entiti care nu se ncadreaz
n nici una din cele trei categorii i pe care noi le numim entiti-abstracte. Entitatea
CONSUM-SPECIFIC, care memoreaz date despre consumurile specifice de materiale pentru
obinerea fiecrei uniti de produs finit, reprezint un astfel de exemplu.
Identificarea entitilor reprezint o activitate dificil, mai puin formalizat. Realizarea ei
presupune citirea cu atenie a documentaiei sistemului, n special a prii n care sunt descrise
tranzaciile i prelucrrile din sistem. Se vor urmri evenimentele (tranzaciile economice) n
legtur cu care se dorete memorarea de informaii sau documentele care le consemneaz,
resursele i agenii implicai n derularea fiecrui eveniment reinut n sistem. De exemplu, din
analiza documentaiei prezentat n caseta 8.1, pentru evenimentul primirea comenzii se vor
reine n sistem, pe lng entitatea-eveniment Comanda, entitatea-agent Client i entitatea-
resurs Produs.
Entitile de date poteniale sunt evideniate n caseta 8.1 prin utilizarea caracterelor de
culoare roie. Ele vor fi trecute ntr-o list separat, din care vor fi eliminate cele care se
repet, fiind pstrat o singur dat, sau cele care apar sub nume diferite, cum este cazul pentru
livrare i factur.
Rezultatul acestei activiti este prezentat n caseta 8.2.
Caseta nr. 8.2 Lista entitilor de date pentru sistemul de gestiune a clienilor
Entiti-eveniment:
1. Comanda,
2. Livrare
3. Returnare
Entiti-resurs:
4. Produs
Entiti-agent:
5. Client
6. Depozit.
8.4.2 Descrierea entitilor de date prin intermediul atributelor

Fiecare entitate are un set de atribute asociate lui.
Un atribut este o proprietate sau o caracteristic a unei entiti care prezint interes pentru
organizaie.
Iat cteva nume de entiti i unele dintre atributele lor posibile:
ANGAJAT: MARCA, NUME, CNP, ADRESA, MESERIA
CONT: SIMBOL, TIP, DENUMIRE
Ca i numele entitilor, numele atributelor sunt substantive scrise cu majuscule, plasate
n interiorul elipselor, legate de entitatea creia i se asociaz. De multe ori, ns, chiar i n
cazul folosirii produselor CASE, pentru a nu se ncrca o diagram entitate-relaie, se evit
prezentarea atributelor. Operaiunea 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 entitii, urmat de atributele care o descriu, primul reprezentnd cheia primar,
scris cu caractere ngroate.
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 entitilor 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 combinaie de atribute
prin care se poate identifica n mod unic un caz (o instan) a entitii respective. Fiecare
entitate trebuie s aib un identificator prin care s se efectueze diferenierea instanelor de
acelai tip. n schimb, descriptorii specific proprieti ne-unice ale instanelor unei entiti.
Redm mai jos, ca exemplu, entitatea ANGAJAT cu dou instane. Ele au valori diferite
pentru caracteristica MARCA, aceasta fiind identificatorul entitii (cheia primar), chiar dac
este vorba despre doi angajai care au acelai nume.
MARCA NUME CNP ADRESA MESERIA
1001 Ion I Ion 1700806040021 Florilor, 54 Strungar
1002 Ion I Ion 1670904372271 Nationala,194 Sudor
Sunt entiti care pot avea dou sau mai multe chei-candidat. n exemplul nostru, pot fi
chei-candidat MARCA i CNP. Atunci cnd 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 instanelor n cadrul unei entiti.
Selecia cheii-primare trebuie efectuat dup anumite proceduri5, grupate n caseta 8.3.
Caseta nr. 8.3 Proceduri de selecie a cheii-primare
SELECIA CHEII-PRIMARE
1. Alegei o cheie-candidat care s nu-i schimbe propria valoare n timpul vieii cazului/instanei entitii
respective.
2. Alegei acea cheie-candidat care, pentru fiecare caz/instan al/a entitii, 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 aa-zisele chei-secrete, care preiau n structura lor pri ale unor atribute care semnific
clasificri, locuri, coduri .a., ntruct ele se pot schimba frecvent, i nici nu sunt publice.
4. Preferai formele scurte n locul celor complexe, formate din mai multe atribute, dac este posibil.
n reprezentrile 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 ngroate, dup numele entitii respective, iar n al treilea, ea
este subliniat.
Depistarea entitilor unui sistem nu reprezint o activitate tocmai uoar. n multe situaii
analistul trebuie s decid dac un obiect reprezint o entitate sau un atribut al unei entiti. S
lum, drept exemplu, obiectul LOCALITATE; el reprezint o entitate sau un atribut? n
sistemul de aprovizionare, el ar putea reprezenta o entitate sau doar atributul entitii furnizor.
La clasificarea entitilor i atributelor, trebuie respectate urmtoarele dou reguli:
entitile trebuie s conin informaii descriptive. Conform acestei reguli, dac pentru
un obiect exist informaii descriptive (adic mai multe atribute care s o
caracterizeze), atunci el constituie o entitate, altfel acel obiect va reprezenta un atribut
al unei entiti. Dac pentru obiectul LOCALITATE sunt necesare mai multe
informaii descriptive (cum ar fi judeul, comuna, codul potal etc.), atunci el trebuie
clasificat ca entitate. Dac se solicit doar numele localitii, atunci el va fi doar un
atribut al unei entiti (cum ar fi FURNIZOR, ANGAJAT etc.).
un atribut trebuie ataat acelei entiti pe care o descrie n modul cel mai direct. De
regul, o proprietate se refer la o singur entitate, deci un atribut va fi regsit doar la o
singur entitate. n sistemul de aprovizionare, de exemplu, entitatea COMANDA nu va
conine nici numele furnizorului (sau codul acestuia), nici denumirea materialului (sau
codul acestuia); aceste atribute caracterizeaz mai direct entitile FURNIZOR,
respectiv Material. Nu intr sub incidena acestei reguli sinonimele. Un exemplu, n
acest sens, poate fi atributul adresa: el poate caracteriza att entitatea ANGAJAT, ct
i entitatea FURNIZOR.
Aadar, clasificarea unui obiect ca entitate sau atribut presupune analiza cu mult atenie a
documentaiei sistemului n care sunt formulate i detaliate cerinele informaionale.
Identificarea atributelor descriptive ale entitilor presupune, n primul rnd, analiza
documentaiei privind intrrile i ieirile din sistem, respectiv a documentelor primare i a
rapoartelor. Mai concret, n acest activitate ne intereseaz cerinele privind structura acestora.
Aadar, n caseta 8.1, vor fi analizate prile B i C din documentaie.
O atenie deosebit trebuie acordat alegerii entitii creia i va fi ataat fiecare atribut.
Nu trebuie uitat c unele atribute nu reprezint caracteristica nici unei entiti, ci a unei relaii
dintre entiti, aa cum este cazul atributelor cantitate comandat sau cantitate livrat. Mai
trebuie reinut c fiecare atribut trebuie asociat unei singure entiti i c atributele calculate,
precum valoarea vnzrii, nu vor fi pstrate n DER. Problema includerii cmpurilor calculate
se pune abia n faza proiectrii fizice a bazei de date, ea urmnd a fi discutat n capitolul
dedicat acestei teme n volumul urmtor.
Identificarea atributelor necesare sistemului este mult uurat n cazul utilizrii CASE,
deoarece se poate analiza direct structura fluxurilor care acceseaz locurile de stocare, puse n
eviden n diagramele fluxurilor de date.
Dup identificarea atributelor fiecrei entiti, 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 situaie gsim n exemplul nostru la entitatea Comanda.
Rezultatul acestei activiti, pentru sistemul analizat, este prezentat n figura 8.5. Cheile
primare sunt evideniate prin caractere ngroate.
O problem important legat de descrierea entitilor 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 utilizrii produselor CASE,
majoritatea lor oferind faciliti pentru a verifica dac diagramele fluxurilor de date, pe de o
parte, i DER, pe de alt parte, sunt balansate. n urma acestei verificri, 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 entitilor sistemului de gestiune a clienilor
8.4.2.1 Atribute cu valori multiple

Un atribut cu valori multiple poate s aib mai mult dect o valoare pentru fiecare
caz/instan al/a tipului entitii. De exemplu, atributul MESERIA poate lua valorile
ZUGRAV, MOZAICAR, FAIANAR, ZIDAR pentru o singur persoan (adic pentru o
singur instan a entitii ANGAJAT). Din aceast cauz, n timpul proiectrii conceptuale se
folosete un simbol sau o notaie special pentru a reflecta prezena atributelor cu valori
multiple sau multivaloare. Sunt utilizabile dou modaliti:
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 legtur de asociere de entitatea
iniial.
Metoda este folosit i n cazul ctorva atribute care se repet laolalt, formnd un grup
repetat. Dac aceleiai entiti i-am asocia i atributul NTREINUT, care se refer la
persoanele aflate n ntreinere, fiecare dintre acestea fiind reperate prin
NUME_NTREINUT, VRSTA_NTREINUT, noua form ar putea fi redat prin
modalitile din figura 8.7, a) i b).
CNP ADRESA
NUME MESERIA
NUME_NTREINUT,
MARCA ANGAJAT VRSTA_NTREINUT
a) Reprezentarea unui grup repetat, cu valori multiple, prin elips dublat

CNP ADRESA
NUME_NTREINUT VRSTA_NTREINUT
NUME MESERIA
MARCA ANGAJAT Are NTREINUT

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

Fig. 8.7 Modaliti de redare n DER a grupurilor repetate cu valori multiple
Observai c separarea grupului repetat conduce la obinerea unei relaii a crei

cardinalitate de partea entitii atributive este zero sau multe, reflectnd faptul c unui
angajat i pot corespunde zero sau mai multe persoane aflate n ntreinere.
8.4.3 Identificarea i descrierea relaiilor dintre entiti

O relaie reprezint legtura care exist n lumea real ntre una, dou sau mai multe
entiti. Relaiile nu au o existen fizic sau conceptual, ci depind de entitile asociate.
Altfel spus, existena relaiilor depinde de existena entitilor asociate (n schimb, existena
unei entiti nu depinde de existena unei relaii cu o alt entitate). Un caz particular al unei
relaii se mai numete instana relaiei sau ocurena relaiei. Instana relaiei se refer la
legtura dintre instanele entitilor asociate. De regul, relaiile sunt redate prin verbe i sunt
simbolizate printr-un romb. Pentru simplificarea realizrii DER, ndeosebi n produsele CASE,
nu se mai folosete un simbol anume pentru redarea relaiei (cum este rombul), ci se scriu
verbele direct pe liniile care surprind existena relaiilor dintre entiti. Alteori, nici acestea nu
se mai scriu, relaia fiind evident sau lsat la interpretarea celui ce citete diagrama.
Exemple de relaii sunt: EMITE, ntre entitile FACTURA i FURNIZOR; CONINE,
ntre entitile FACTURA i PRODUS; CONDUCE, ntre entitile ANGAJAT i
DEPARTAMENT sau orice verb care descrie conexiunea dintre entiti. O instan a relaiei
EMITE face referire la legtura dintre o anumit factur i furnizorul care a emis-o.
Descrierea unei relaii presupune specificarea urmtoarelor elemente: gradul (ordinul),
cardinalitatea, rolul i eventualele atribute care o caracterizeaz. n continuare, ne vom opri pe
rnd asupra fiecrui element descriptiv.
8.4.3.1 Gradul relaiilor
Gradul unei relaii (degree of a relationship) este dat de numrul de entiti care particip
la relaie. Cele mai ntlnite relaii n modelele entitate-relaie sunt:
unare (grad unu), numite i recursive sau relaii ale entitii cu ea nsi; acest tip de
relaie leag dou instane ale aceleiai entiti.
binare (grad doi); acest tip de relaii sunt de departe cele mai ntlnite n lumea real.
Mai mult, unele metode utilizeaz doar relaii binare la construirea DER.
ternare (grad trei); relaiile ternare sunt mai rar ntlnite n lumea real, ele fiind
utilizate atunci cnd nu este suficient utilizarea relaiilor binare pentru descrierea cu
acuratee a semanticii relaiei respective.
Pot exista relaii cu grade i mai mari, dar n practic acestea sunt foarte greu de ntlnit.
Cele trei tipuri de relaii sunt prezentate n exemplul din figura 8.8 (cardinalitatea relaiilor nu
a fost reprezentat). Asupra relaiilor ternare vom reveni spre sfritul acestui capitol.
Este
PERSOANA cstorit ANGAJAT Conduce
cu
Unu-la-unu Unu-la-multe
a) Relaie unar
FURNIZOR Emite FACTURA
b) Relaie binar
Fig. 8.8 Exemple de relaii unare, binare, ternare
PIESA
FURNIZOR Transportat DEPOZIT
CANTITATE
c) Relaie ternar
Fig. 8.8 Exemple de relaii unare, binare, ternare
Referirea la gradul unei relaii se mai face i n alte moduri, cum ar fi ordin sau rang al
relaiilor.
8.4.3.2 Cardinalitatea relaiilor

Urmtorul concept utilizat pentru descrierea relaiilor l reprezint cardinalitatea.
Presupunem c exist dou entiti, A i B, ntre care exist o linie de legtur pentru a marca
relaia. Cardinalitatea unei relaii este dat de un numr al cazurilor/instanelor entitii B care
pot sau care ar putea s fie asociate cu fiecare caz al entitii A. Pentru o relaie dat, trebuie
specificat cardinalitatea pentru fiecare entitate asociat. Cardinalitatea relaiei pentru o
entitate este sugerat printr-o pereche de valori, n cazul relaiilor 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 funcie de notaia
folosit. Recomandm citirea cu atenie a diagramelor i descifrarea elementelor strict necesare
nelegerii, ndeosebi pentru reflectarea cardinalitii. De exemplu, ea poate fi notat cu semne
(0, 1, M, N) sau prin simboluri (linie cu vrf simplu de sgeat pentru 1, linie cu vrf dublu de
sgeat pentru M. Alteori, 1 se reprezint prin linie simpl i M prin vrf de sgeat). n multe
materiale, inclusiv produse CASE, se folosete notaia model-date, cunoscut mai mult sub
numele laba-gtei, conform creia cardinalitatea se reprezint prin urmtoarele simboluri:
obligatoriu 1
opional 0 sau 1
n obligatoriu multe (n; unde n ia valori de la 1 la M)

n opional 0 sau multe (n poate lua valori de la 0 la M).
n continuare, vom utiliza semnele 0, 1, M i N pentru reprezentarea cardinalitii care,
considerm noi, face o DER mai uor de citit.
S lum drept exemplu relaia emitere dintre entitile FURNIZOR i FACTURA,
prezentat n figura 8.9. Cardinalitatea minim a relaiei pentru entitatea FACTURA este 1,
iar cea maxim este tot 1; cardinalitatea relaiei pentru entitatea FURNIZOR este 0,
respectiv M. Prin urmare, n relaia emitere, unui furnizor (care este o instan a entitii
FURNIZOR) i poate corespunde minim 0 i maxim multe facturi (adic instane ale
entitii FACTURA), n timp ce unei facturi i corespunde un furnizor i numai unul.
Factura (0,M) (1,1) Furnizor

Emitere
Figura 8.9 Cardinalitatea relaiilor

Observai reprezentarea grafic invers a cardinalitii. Cardinalitatea entitii FACTURA
este plasat lng entitatea FURNIZOR i invers. Aplicarea acestei reguli faciliteaz citirea
unei DER.
Clasificarea relaiilor n funcie de cardinalitatea maxim
O importan deosebit n proiectarea bazelor de date o prezint clasificarea relaiilor n
funcie de cardinalitate, att cea maxim, ct i minim. Astfel, n cazul relaiilor unare
(recursive) i al celor binare, vom avea trei tipuri de relaii, n funcie de cardinalitatea
maxim:
relaii de tipul 1:1 (unu-la-unu), adic o instan a entitii X este asociat unei singure
instane a entitii Y i reciproc. Un exemplu se regsete n figura 8.10.
relaii de tipul 1:M (unu-la-multe), nsemnnd c o instan a entitii X poate fi
asociat la n instane ale entitii Y, n timp ce o instan a entitii Y va fi asociat
doar unei singure instane a entitii X. Acest tip de relaii este cel mai des ntlnit n
lumea real, un exemplu fiind deja prezentat n figura 8.9.
relaii de tipul M:N (multe-la-multe), care presupun c orice instan a entitii X poate
fi asociat mai multor instane ale entitii Y, iar o instan a entitii Y poate, de
asemenea, s aib asociate mai multe instane ale entitii X (vezi figura 8.11).
(1,1) (0,1)
FACTURA Are RECEPIE
Figura 8.10 Relaie de tipul 1:1(unu-la-unu)
(0,M) (1,M)
FACTURA Conine PRODUS
Figura 8.11 Relaie de tipul M:N (multe-la-multe)
Relaii opionale i obligatorii

Uneori, relaiile dintre entiti nu-i fac simit prezena n toate situaiile. Astfel, relaiile
dintre entiti pot fi clasificate dup cardinalitatea minim n dou tipuri: relaii opionale i
relaii obligatorii. Altfel spus, participarea unei entiti ntr-o relaie poate s existe sau nu;
participarea opional este pus n eviden prin cardinalitatea minim 0, iar cardinalitatea
minim 1 semnific faptul c acea entitate este obligatoriu s participe ntr-o relaie.
Cardinalitatea minim are o semnificaie important n proiectarea bazelor de date, ea
fiind legat de conceptul de restricie de dependen6. Dac existena instanei x din entitatea
X depinde de existena instanei y din entitatea Y, se spune c x este dependent de y. Ea
indic dac o instan dintr-o entitate trebuie legat de cel puin o instan a entitii aflate la
cellalt capt al relaiei. Cardinalitatea minim 0 ne arat c pentru entitatea respectiv poate
exista o instan fr ca ea s fie legat de vreo instan a celeilalte entiti. Dimpotriv, n
cazul cardinalitii minime 1 fiecare instan a entitii respective trebuie s fie legat de cel
puin o instan a celeilalte entiti. Rezult c tergerea entitii 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 relaionale. Organizare i interogare, Ed. Junimea, Iai, 1996, p. 69.
entitii x din baza de date. Se spune c existena instanei x depinde de existena instanei 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 relaia Emitere, entitatea
FACTURA are cardinalitatea minim 1, deci este obligatorie participarea oricrei instane
(facturi) ntr-o relaie, n timp ce cardinalitatea minim pentru entitatea FURNIZOR este 0,
ceea ce nseamn c nu este obligatorie participarea fiecrui furnizor n relaia 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 rmn facturi primite de la furnizorul
respectiv. n schimb, tergerea unui furnizor atrage dup sine tergerea tuturor facturilor
aferente acestuia. De asemenea, adugarea unei facturi noi poate fi fcut numai dac ea este
legat de un furnizor.
Cardinalitatea minim poate fi redat i grafic. Cercul suprapus pe latura entitii indic,
de fapt, poziia zero (valoarea minim poate fi i zero), conferind relaiei caracterul opional.
Simbolul folosit pentru a marca relaiile obligatorii este acelai cerc, cu deosebirea c este
haurat.
8.4.3.3 Rolul relaiilor
Rolul definete funcia care atrage dou sau mai multe entiti ntr-o relaie. Pentru o
relaie se poate specifica rolul fiecrei entiti asociate, iar prin combinarea rolurilor jucate de
entitile asociate se obine numele relaiei. De exemplu, revenind la relaia dintre FACTURA
i FURNIZOR, numele acestei relaii poate fi descris sub forma emite/este emis, dup cum se
poate observa i n figura 8.12. Rolul entitii FURNIZOR este Emite, iar cel al entitii
FACTURA este este emis.
Factura (0,M) Emite/este (1,1) Furnizor
emisa
Figura 8.12 Rolul relaiilor

Specificarea rolurilor jucate de entiti n DER nu prezint o importan deosebit n
proiectarea bazelor de date, ns ajut la clarificarea aspectelor semantice ale modelrii datelor,
precum i la citirea relaiilor. Relaia 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 relaiile dintre entiti pot fi exprimate sintetic prin dou fraze scurte, fiecare fiind
inversa celeilalte, dar fiecare ncadrndu-se n forma general:
Fiecare nume-entitate
descrierea-relaiei-lng-entitate
marcaj-legtur-cellalt-capt
cellalt-nume-entitate.
n exemplul nostru, am utilizat dou nume pentru a pune n eviden rolul fiecrei entiti
n cadrul relaiei. Unele metode recomand utilizarea unui singur nume pentru o relaie, stabilit
prin alegerea unui verb care s reflecte logica legturii dintre entitile respective. De exemplu,
pentru aceeai relaie, n figura 8.8 am utilizat numele Emitere. n aceast variant, rolul
fiecrei entiti nu mai este specificat n mod explicit, ns el rezult implicit din numele
atribuit relaiei. n lipsa unui verb semnificativ pentru logica relaiei, se poate alege un nume
format din iniialele entitilor asociate. n cazul n care se utilizeaz doar o linie simpl pentru
reprezentarea relaiilor (fr simbolul romb), rolurile sunt plasate pe linie, de o parte i/sau de
cealalt a ei.
Necesitatea specificrii rolului relaiilor este evident atunci cnd ntre dou entiti exist
mai multe relaii. De exemplu, s-ar putea spune c FURNIZOR ofer PRODUS, dar i
PRODUS este cumprat 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
cumprat
de la
Fig. 8.13 Descrierea relaiilor multiple ntre dou entiti
8.4.3.4 Relaii purttoare de atribute (entiti asociative)

n sfrit, descrierea relaiilor impune i specificarea atributelor asociate, dac ele exist.
Considerm concludente urmtoarele exemple:
1) Cazul prezentat la relaia ternar, n figura 8.8(c). Se observ c relaia ternar nu
nseamn acelai lucru cu trei relaii binare. De exemplu, atributul CANTITATE este asociat
relaiei Transport. Atributul nu poate fi asociat nici uneia dintre cele trei posibile relaii
binare dintre cele trei tipuri de entiti (FURNIZOR, PIESA, DEPOZIT), ntruct
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 relaiei unare multe-la-multe, redat n
figura 8.14.
(0,M)
Are
ARTICOL componente CANTITATE
(0,M)
a) Relaie 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/instane ale relaiei a)

Fig. 8.14 Relaia unar de tip Are componente
Not: Valorile din parantezele ataate componentelor reprezint cantitile nglobate n componenta
superioar.
S punem n discuie un alt exemplu, cel al relaiei Emite dintre entitile FACTURA i
PRODUS. Un produs poate fi coninut n mai multe facturi, dup cum i o factur poate
conine mai multe produse. Prezentm, mai jos, cteva dintre datele concrete:
NUMR_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 conine dou produse, A i B, cu cantiti
diferite (25, respectiv 15), deci CANTITATE nu este o proprietate a entitii FACTURA. Dar
nu este nici o proprietate a entitii PRODUS, ct timp acelai produs poate fi coninut n dou
sau mai multe facturi cu cantiti diferite (produsul A se regsete pe ambele facturi, cu
cantitile 25 i 70). n schimb, CANTITATE este o proprietate a relaiei dintre FACTURA i
PRODUS. Atributul se asociaz relaiei i se prezint sub form de diagram, ca n figura 8.15.
CANTITATE
(0,M) (1,M)
FACTURA Conine PRODUS
Fig. 8.15 Asocierea unui atribut la o relaie
De aici rezult un caz aparte de entitate, numit gerundiv sau compus sau asociativ
care, de fapt, este o relaie folosit de analist n model ca un tip de entitate. n astfel de cazuri,
se folosete un simbol special: dreptunghi cu romb n interior, n care se scrie numele entitii
(fig. 8.16).
CANTITATE
(0,M) (1,M)
FACTURA Con ine PRODUS
Fig. 8.16 Redarea unei entiti gerundive (asociative)
Relaii purttoare de atribute pot fi ntlnite doar n cazul relaiilor de tipul multe-la-
multe sau al relaiilor ternare. Relaiile binare de tipul unu-la-unu sau unu-la-multe nu pot
avea atribute.
8.4.4 Modelul general al DER pentru sistemele informaionale

n figura 8.17, este prezentat un model general al DER pentru sistemele informaionale
economice, care evideniaz relaiile existente ntre cele trei tipuri de entiti, precum i
cardinalitatea tipic a acestor relaii. Prin acest model 7 dorim s oferim un punct de plecare n
modelarea conceptual a datelor din sistemele informaionale economice i construirea DER.
Desigur, trebuie luate n considerare i analizate cu atenie particularitile 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)
Obinere
Resursa A Intrare
resurs A
(?,?) (1,1)
(0,M) Particip
Dualitate Agent intern
(0,M)
Particip (1,1)
(?,?)
Furnizare
Resursa B Ieire
(1, ?) (0,M) resurs B
(0,M)
Particip Agent extern

(1,1)
Fig. 8.17 Modelul general al DER pentru sistemele informaionale economice
n figura 8.17 se regsesc toate cele trei tipuri de entiti specifice sistemelor
informaionale economice: evenimente, resurse i ageni. La identificarea entitilor trebuie
acordat o atenie deosebit obiectelor (evenimente, resurse sau ageni) diferite dar omogene
(adic descrise de aceleai atribute), care pot fi reunite n aceeai entitate. De exemplu,
entitile-resurs MATERIAL, OBIECT_INVENTAR_DEPOZIT i PRODUS_FINIT pot fi reunite
n aceeai entitate, numit eventual BUN_MATERIAL, deoarece toate aceste resurse sunt
descrise de regul prin aceleai atribute (Cod, Denumire, UM, Pre, Stoc). Asemntor, pot fi
reunite entitile-agent FURNIZORI i CLIENI.
n modelul propus, se regsesc trei tipuri de relaii din punctul de vedere al entitilor
implicate. n primul rnd, fiecare entitate-eveniment este legat de o entitate-resurs. De
exemplu, entitatea-eveniment VNZARE 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 rnd, fiecare entitate-eveniment este legat de dou entiti-agent. Agentul
intern este reprezentat de angajatul care are responsabilitatea gestionrii resursei afectate sau a
autorizrii evenimentului respectiv i care, implicit, va avea dreptul s introduc sau s
modifice datele n baza de date. De regul, ea este regsit sub forma entitii UTILIZATOR,
care va avea ca instane angajaii firmei, inclusiv datele privind responsabilitile acestora. Tot
ca ageni interni se vor regsi i diferitele subuniti organizatorice implicate n efectuarea
tranzaciilor interne. De exemplu, n evenimentul consum de materiale sunt implicate
depozitul, care elibereaz materialele, i departamentul care le solicit. Agentul extern se
refer la terul din afara firmei care este implicat n derularea evenimentului respectiv.
Entitatea-eveniment VNZARE va fi legat de entitatea-agent CLIENT.
Al treilea tip de relaie se refer la legturile dintre entitile-eveniment, care reflect
natura economic dual a majoritii evenimentelor din cadrul sistemelor informaionale
economice de tipul intrare-ieire. De exemplu, evenimentul VANZARE, care implic
decrementarea resursei PRODUS, este legat de evenimentul NCASARE, care presupune
incrementarea resursei FOND_BNESC. Se reflect astfel principiile de desfurare a
afacerilor care implic adesea consumarea unor resurse n vederea obinerii altora. De
asemenea, pot s apar relaii ntre entitile-eveniment care reflect un angajament pe viitor i
cele care privesc tranzaciile economice realizate n baza angajamentului. O astfel de relaie
este cea dintre entitile COMANDA i VNZARE. Prin introducerea unor asemenea relaii n
modelul conceptual al datelor i specificarea cardinalitii, se poate arta faptul c nu se
accept nregistrarea unei tranzacii (vnzri) fr existena unui angajament anterior

(comanda).
Alte aspecte relevante privind modul de desfurare a afacerilor de ctre organizaii sunt
reflectate prin cardinalitatea relaiilor. n continuare, vom pune n discuie cardinalitatea pentru
fiecare dintre cele trei tipuri de relaii amintite anterior.
Cardinalitatea relaiilor dintre entitile agent i eveniment
n figura 8.17 se poate observa c att minimul, ct i maximul cardinalitii asociate
entitilor-eveniment n fiecare relaie eveniment-agent este 1 (dup cum tii deja,
cardinalitatea este reprezentat invers n diagram). Aceast situaie este ntlnit aproape
ntotdeauna, reflectnd faptul c trebuie s existe un agent, i numai unul, care s fie implicat
n orice eveniment pentru ca organizaia s evidenieze responsabilitatea derulrii
evenimentului respectiv. O instan VNZARE trebuie s aib n coresponden un CLIENT i
numai unul, astfel nct s se poat identifica n mod cert creana creat. Aceeai cardinalitate
va fi i n relaia cu agentul intern, pentru a se putea ti cu exactitate angajatul responsabil de
operaia respectiv de vnzare.
Perechea (0,M) reprezint cardinalitatea tipic asociat entitii agent n relaiile agent-
eveniment. Cardinalitatea maxim M asociat unui agent intern este pe deplin justificat,
deoarece este de ateptat ca un angajat s autorizeze mai multe evenimente de un anumit tip
(de exemplu vnzri). De asemenea, un agent extern va avea cardinalitatea maxim M pentru
c organizaia se angajeaz n relaii de afaceri repetate cu acelai furnizor sau client.
Cardinalitatea minim 0 este explicat prin dou raionamente. Mai nti, organizaia dorete s
poat aduga 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 entitile-eveniment reprezint de fapt
fiiere de tranzacii (sau temporare), n timp ce entitile-agent sunt fiiere nomenclatoare (sau
permanente). La anumite intervale regulate de timp (de exemplu, la sfritul anului), coninutul
fiierelor de tranzacii este ters dup ce s-a efectuat arhivarea, n timp ce informaiile despre
ageni 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 relaiilor dintre entitile resurs i eveniment
Dup cum rezult din figura 8.17, perechea (0,M) este cardinalitatea tipic asociat
entitilor-resurs n relaiile resurs-eveniment, din aceleai motive prezentate anterior pentru
entitile-agent. Un anumit produs poate face obiectul mai multor operaii de vnzare, la fel
cum poate s nu se regseasc pe nici una.
Cardinalitatea minim asociat entitilor-eveniment este de regul 1, ceea ce nseamn c
fiecare eveniment trebuie s implice cel puin o instan a entitii-resurs cu care este n
legtur, adic el va afecta cel puin o resurs. O vnzare va conine cel puin un produs, iar o
ncasare va afecta cel puin un cont de disponibiliti. Excepii de la aceast regul general
apar n cazul relaiilor alternative dintre entiti, ns aceste tipuri de relaii le vom prezenta n
paragraful urmtor. n schimb, nu exist o regul general n ce privete cardinalitatea maxim
asociat entitilor-eveniment, motiv pentru care am apelat la simbolul ?. Ea depinde de
natura resursei implicate sau de regulile de desfurare a afacerilor din organizaie. De
exemplu, o ncasare va avea n coresponden un singur cont de disponibiliti bneti
(cardinalitatea maxim va fi 1), n timp ce o vnzare poate conine mai multe produse
(cardinalitatea maxim va fi M).
Cardinalitatea relaiilor dintre entitile eveniment
Pentru relaiile dintre dou entiti-eveniment orice cardinalitate este posibil, neexistnd
reguli generale, tipice. Totui, o regul ce poate fi reinut pentru relaiile 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 cellalt eveniment nu

a avut loc; cel mai adesea, dar nu ntotdeauna, cardinalitatea minim corespunztoare celui de-
al doilea eveniment ca desfurare n timp va fi 1, reflectnd faptul c desfurarea celui de-al
doilea eveniment poate avea loc numai dac primul eveniment s-a realizat anterior. Pentru
exemplificare, s lum relaia dintre evenimentele COMANDA i VNZARE: ca ordine de
desfurare, operaiunea de vnzare are loc dup primirea comenzii, deci entitatea COMANDA
va avea cardinalitatea minim 0, dat fiind c operaiunea de vnzare are loc ulterior i, pn
atunci, comanda respectiv nu va avea n coresponden nici o vnzare, iar entitatea
VNZARE va avea cardinalitatea minim 1. Totui, dac regulile afacerii din organizaie
accept derularea de vnzri fr primirea unei comenzi ferme n prealabil, atunci i
cardinalitatea minim asociat entitii VNZARE va fi 0.
Acum, dup ce ne-am familiarizat cu conceptele utilizate pentru descrierea relaiilor dintre
entiti, precum i cu modelul general al DER pentru sistemele informaionale economice,
suntem n msur s finalizm DER-ul pentru sistemul nostru. Rezultatul este prezentat n
figura 8.18.
Cteva comentarii mai sunt necesare n legtur cu modul de construire a diagramei.
Mai nti, identificarea relaiilor dintre entiti reprezint o activitate extrem de
anevoioas, solicitnd mult experien din partea analistului. Dificultatea este cu att mai
mare, cu ct n diagramele fluxurilor de date i n depozitul de date nu se face nici o referire la
relaiile dintre entiti. Singurul model care le evideniaz este diagrama entitate-relaie. Pe de
alt parte, orice relaie specificat n plus sau n minus va avea consecine, uneori grave, asupra
proiectrii bazei de date. Un demers mai formal nu exist, aa c nu ne rmne dect s citim
cu mult atenie documentaia sistemului.
n caseta 8.1, partea de text care sugereaz relaii ntre entiti este scris cu caractere de
culoare verde. Acelai text va sugera i rolul (numele) fiecrei relaii.
n al doilea rnd, dup identificarea unei relaii, se va mai citi o dat textul pentru a
desprinde informaiile necesare pentru stabilirea cardinalitii relaiei. n cazul n care nu
gsete astfel de informaii, analistul va trebui s le afle i s completeze documentaia.
n al treilea rnd, se poate observa c, odat cu introducerea relaiilor, s-au specificat i
atributele asociate relaiilor.
n caseta 8.1, informaiile relevante pentru stabilirea cardinalitii relaiilor sunt scrise cu
caractere de culoare albastr.
Odat ce am obinut forma final a DER pentru sistemul nostru, se cuvine s mai zbovim
un pic asupra legturii 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 asemnri,
dar i unele diferene. ntre cele dou modele exist o legtur direct, n sensul c entitile de
date se vor regsi n diagrama fluxurilor de date sub forma locurilor de stocare. n general, se
poate urmri obinerea unei relaii biunivoce ntre mulimea entitilor de date i cea a locurilor
de stocare, dar nu este obligatorie.
Dac DER conine prea multe entiti, prevederea a cte unui loc de stocare pentru fiecare
din ele ar spori complexitatea i ncrcarea diagramelor fluxurilor de date, nu doar prin
numrul mare de locuri de stocare, ci i printr-un numr mult mai mare de fluxuri de accesare a
lor. Aadar, se poate opta pentru gruparea logic a dou sau mai multe entiti, crora s le
corespund un singur loc de stocare. n exemplul nostru, entitile 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 Conine
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 Conine PretUnitar
(1,M)
Sold
LimitaCredit
TipClient Cantitate
comandata
Figura 8.18 Diagrama entitate-relaie pentru sistemul

de gestiune a clienilor
Pe de alt parte, se poate observa c exist locuri de stocare care nu-i gsesc
corespondentul n DER, cum ar fi Promoii i Catalog. Explicaia este urmtoarea: funciile
(procesele de prelucrare) care acceseaz acele locuri de stocare nu sunt vizate pentru
informatizare, deci nu prezint interes imediat din perspectiva dezvoltrii sistemului
informatic. Prin urmare, s-a considerat c nu este nevoie de memorarea datelor n legtur cu
cele dou entiti. Aceste date se vor regsi doar pe hrtie.
Legtura strns dintre cele dou tipuri de diagrame, i ntr-un sens, i n cellalt, reclam
construirea lor n paralel. Se va ncepe mai nti cu diagrama fluxurilor de date pentru a pune
n eviden principalele funcii i procese din sistem, ns, cnd se ajunge la un nivel suficient
de detaliere, se poate trece la construirea DER. Apoi se revine cu modificri i completri
asupra diagramei fluxurilor de date. Astfel de treceri, de la un model la altul, vor fi realizate ori
de cte ori este nevoie.
8.4.5 Alte situaii ntlnite n modelarea conceptual a datelor

Scopul diagramelor entitate-relaie este de a surprinde cele mai complete sensuri posibile
ale datelor necesare sistemului informaional din organizaie. Aplicarea tuturor conceptelor
prezentate anterior permite descrierea suficient de clar a entitilor i relaiilor identificate n
domeniul analizat, ns, problematica poate fi mult mai ampl dect a fost redat n capitolul
de fa. n acest paragraf, vom reda alte cteva situaii ce pot fi ntlnite n lumea modelat i
maniera n care ele pot fi reprezentate n DER.
8.4.5.1 Cardinalitatea relaiilor ternare
Dac, n cazul unei relaii de ordinul 2, avem trei tipuri de relaii din punctul de vedere al
cardinalitii maxime, pentru relaiile ternare vom avea patru tipuri de relaii: 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). Generaliznd, se poate afirma c o relaie de ordinul n va nregistra n+1 tipuri
de relaii din punctul de vedere al cardinalitii maxime, cu excepia relaiilor unare.
Disciplina
Profesor Examineaza Student

1 N
Fig. 8.19 Exemplu de relaie ternar de tipul 1:M:N

n figura 8.19 este prezentat un exemplu de relaie ternar de tipul 1:M:N. Aceast relaie
poate fi citit astfel:
un profesor poate examina un student la mai multe discipline (de aici M-ul din partea
entitii DISCIPLINA),
un profesor examineaz la o disciplin mai muli studeni,
un student este examinat la o disciplin de un singur profesor.
Se observ c, la determinarea cardinalitii, se ia n considerare numrul maxim (unu sau
multe) de instane ale unei entiti care corespund unei perechi formate din cte o instan a
celorlalte dou entiti. De exemplu, ntrebarea poate fi formulat astfel: Cte discipline pot
corespunde unui anumit profesor i unui anumit student?
8.4.5.2 Relaii redundante
Dou sau mai multe relaii sunt considerate redundante atunci cnd ele sunt utilizate
pentru a reprezenta acelai concept. Un exemplu de relaie redundant este cea dintre
FURNIZOR i DOCUMENT_PLAT din figura 8.20. Aceast relaie este mai curnd una
indirect, dac plile sunt urmrite pe fiecare factur n parte. n momentul n care unei pli i
se asociaz o anumit factur, implicit i se va asocia i furnizorul care a emis factura
respectiv, prin intermediul legturii dintre entitile FURNIZOR i FACTURA. Dac s-ar ine
o eviden global a datoriilor ctre furnizori, neinteresnd factura ce este pltit, ci doar
furnizorul, atunci ar trebui eliminat relaia dintre FACTURA i DOCUMENT_PLAT.
Oricum, indiferent de tipul de eviden utilizat n firm, una din cele dou relaii trebuie
eliminat. Existena unei relaii redundante poate fi sesizat i din urmrirea rolurilor celor trei
relaii, observndu-se c ambele relaii au acelai nume, respectiv Se pltete.
(1,1) Se (0,M) DOCUMENT_
FURNIZOR pltete PLAT
(1,1) (0,M)
(0,M) (1,M) Se
Emite FACTURA pltete
Fig. 8.20 Exemplu de relaie redundant

n schimb, n figura 8.21 nici una dintre cele trei relaii nu este redundant att timp ct
membrii unei asociaii pot locui n alt localitate dect cea n care i are sediul asociaia. Dac
ar exista restricia ca toi membrii unei asociaii s locuiasc n localitatea de reedin a
asociaiei, atunci relaia dintre MEMBRU i LOCALITATE ar fi redundant.
(0,M) (1,1)
MEMBRU Locuiete LOCALITATE
(1,M) (1,1)
(0,M) (0,M) Are

Aparine ASOCIAIE Sediul
n
Fig. 8.21 Exemplu de relaii neredundante

Pentru o mai bun clarificare, revenim la sistemul de gestiune a relaiilor cu clienii i la
DER prezentat n figura 8.18. La o prim vedere, s-ar putea considera c unele relaii au fost
omise. Este vorba, ndeosebi, despre relaia dintre entitile Livrare i Client, considerndu-se
c, prin lipsa ei, nu se va putea ti care este clientul ctre care s-a efectuat o anumit livrare.
O astfel de observaie nu ar fi tocmai corect, att timp ct ntre entitile Livrare i Comand,
pe de o parte, Comanda i Client, pe de alt parte, exist relaii. Vom putea face legtura ntre
o livrare i un client, dar indirect, prin intermediul entitii Comanda.
Observaia ar fi fost ntemeiat dac firma ar fi acceptat livrri i fr primirea prealabil
a unei comenzi. ntr-o asemenea situaie, legtura indirect ntre client i livrare nu mai poate fi
stabilit, att timp ct comanda poate s lipseasc. Atunci, cardinalitatea relaiei dintre Livrare
i Comanda ar trebui modificat, n sensul nlocuirii cardinalitii minime 1, aflat n partea
entitii Comanda, cu 0, i adugrii relaiei dintre entitile Livrare i Client.
S mai spunem c relaii redundante pot apare numai n modelul fizic al datelor, n scopul
creterii vitezei de acces la baza de date. ns, acum ne aflm abia n faza elaborrii modelului
conceptual al datelor.
Rezumat
Aplicarea principiului abstractizrii presupune modelarea datelor pe trei niveluri: conceptual, logic
i fizic. Modelarea pe aceste trei niveluri de abstractizare este justificat de necesitatea stpnirii
complexitii sistemului, analistul avnd posibilitatea de a se concentra, la un moment dat, doar asupra
anumitor aspecte, ignorndu-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 realitii din domeniul analizat,
fr a lua n considerare cerinele 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 entitilor de date i a legturilor dintre ele.
Pentru reprezentarea modelului conceptual se apeleaz la diagrama entitate relaie (DER),
construit prin utilizarea a trei tipuri de obiecte: entiti de date, relaii ntre entiti i atribute.
Realizarea DER implic parcurgerea a patru etape: identificarea entitilor de date, descrierea lor prin
intermediul atributelor, definirea relaiilor dintre entiti 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 organizaia dorete s pstreze anumite date. Entitile pot fi ncadrate n una
din urmtoarele patru categorii: resurse, evenimente, ageni i entiti-abstracte.
O relaie reprezint legtura care exist n lumea real ntre una, dou sau mai multe entiti, ea
neavnd o existen fizic sau conceptual de sine stttoare, ci depinde de entitile asociate. Din acest
motiv, identificarea relaiilor reprezint o activitate dificil, care solicit mult experien i atenie.
Odat identificate, relaiile sunt descrise prin intermediul gradului, cardinalitii, atributelor i rolului.
1. Explicai de ce este important modelarea conceptual a datelor ca activitate de dezvoltare a
sistemelor informaionale.
2. Realizai o comparaie ntre diagrama fluxurilor de date i diagrama entitate-relaie.
3. Enumerai i definii principalele concepte utilizate n modelarea conceptual a datelor.
4. Care sunt tipurile de relaii ternare din punctul de vedere al cardinalitii?
5. Explicai cum poate fi pus n eviden caracterul temporal al legturii dintre dou entiti-eveniment.
6. Explicai de ce relaia ntre entitile Livrare i Produs ar fi redundant, dac ar fi introdus n DER
pentru sistemul de gestiune a clienilor, prezentat n figura 8.18. Specificai ce modificare trebuie
realizat n politica de afaceri a firmei, inclusiv n DER din figura 8.18, pentru ca relaia dintre cele
dou entiti s nu mai fie redundant.
Probleme de echip
1. Redactai o scurt documentaie asupra unei componente, la liber alegere, a sistemului
informaional dintr-o firm care s conin informaiile necesare modelrii conceptuale a datelor.
2. Dai cte dou exemple de entiti-resurs, entiti-eveniment i entiti-agent din urmtoarele
subsisteme informaionale: Urmrirea vnzrilor, Urmrirea achiziiilor, Gestiunea produciei.
3. Punei n eviden, printr-un exemplu, importana rolului relaiilor dintre entiti. Comentai exemplul
ales.
4. Dai un exemplu de relaie ternar i interpretai cardinalitatea ei.
5. Punei n eviden, printr-un exemplu, importana cardinalitii minime a relaiilor.
6. Construii DER pe baza documentaiei redactate la punctul 1.
7. Dai dou exemple de relaii ntre dou entiti-eveniment i explicai n ce const dualitatea celor
dou relaii.
CAPITOLUL IX
Selectarea variantei strategice de proiectare

Obiective:
Discutarea necesitii formulrii mai multor variante de proiectare
Prezentarea procedurilor de selecie a celei mai bune variante strategice de proiectare
Cunoaterea i stpnirea problemelor n legtur cu care se pot genera variante de
strategii de proiectare pentru un sistem informaional
Descrierea posibilelor surse de obinere a softului
Prezentarea metodelor de evaluarea a propunerilor de proiect
Cunoaterea coninutului planului de baz al unui proiect de sistem informaional
ntregul efort depus pn n momentul de fa s-a concretizat ntr-o bogat acumulare de

informaii despre cerinele sistemului, structurate sub diverse forme, precum i despre modul n
care am dori s fie conceput noul sistem sau ce corecii s i se aduc celui vechi.
Obiectivul principal urmrit n faza de analiz l-a reprezentat definirea a ceea ce este i
a ceea ce ar trebui s fie sistemul informaional. n acest sens, au fost realizate dou activiti
importante: determinarea cerinelor sistemului i structurarea (formalizarea) acestora. Prin
determinarea cerinelor sistemului s-a urmrit, mai nti, descrierea a ceea ce face sistemul
existent, prin prezentarea proceselor de prelucrare, a fluxurilor informaionale, a procedurilor
de lucru, a documentelor i rapoartelor din sistem. Apoi, s-a urmrit identificarea a ceea ce
doresc utilizatorii de la noul sistem. Structurarea cerinelor sistemului a vizat dezvoltarea
modelului logic al sistemului. Fluxurile informaionale dintre procesele de prelucrare au fost
reprezentate prin diagrama fluxurilor de date, logica prelucrrii datelor a fost descris prin
intermediul tabelelor de decizie sau a englezei structurate, modelul conceptual al datelor a fost
transpus prin intermediul diagramei entitate-relaie.
9.1 Aspecte generale privind raportul cerinelor sistemului

i selectarea variantei strategice de proiectare
Odat finalizat faza de analiz, trebuie aleas calea de urmat pentru obinerea noului
sistem. Obiectivul principal al proiectrii 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
cerinele identificate anterior. Proiectarea trebuie s ofere soluia optim de nglobare a tuturor
cerinelor n noul sistem. Trecerea de la analiz la proiectare presupune trecerea de la ce la
cum se va obine noul sistem. Toate informaiile colectate pn acum trebuie transformate n
idei i soluii de proiectare pentru noul sistem.
Aadar, ne aflm n aa-zisa faz a definirii strategiei proiectului.
Direcia 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
contradiciile care pot exista ntre utilizatori privind cerinele funcionale, variantele privind
platformele hardware i software, cerinele funcionale care s fie incluse n noul sistem, n
funcie de restriciile de costuri i timp, sursele de obinere a softului etc.
Un cuvnt greu l au utilizatorii i finanatorii proiectului. Pentru a-i ajuta s ajung la o
concluzie final comun, echipa de realizare trebuie s identifice i s defineasc clar cteva
strategii concurente de proiectare, dintre care doar una va fi continuat n pasul urmtor al
ciclului de via al sistemului, faza de proiectare, n funcie de performanele 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 activitile care trebuie parcurse, consideraiile care stau la
baza generrii variantelor strategice de proiectare, criteriile utilizate la evaluarea lor, modul de
selectare a celei mai bune variante de sistem, coninutul planului de baz al proiectului.
Rezultatul final al studiului de identificare a cerinelor de informaii se concretizeaz ntr-
un raport detaliat al cerinelor sistemului, n care vor fi prezentate informaiile necesare noului
sistem. Raportul cuprinde tot ceea ce trebuie s fie produs de ctre sistem. El va lsa fazei de
proiectare o imagine clar a modului n care se vor obine cerinele sistemului.
Raportul va conine urmtoarele elemente:
descrierea funciilor principale executate n noul sistem, inclusiv ce trebuie fcut i de
ctre cine, cum se realizeaz interfaa funciilor cu ntregul sistem i cum funciile noi
vor afecta utilizatorii;
descrierea tuturor datelor necesare sistemului, inclusiv nume, mrime, 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 arta cum datele vor fi organizate n
nregistrri logice i care este legtura dintre date;
o descriere i un model de exemplar pentru fiecare ieire din sistem (rapoarte,
documente). Descrierea trebuie s prezinte numele ieirii, scopul ei, frecvena i
distribuia, precum i toate datele ce le va conine;
descrierea i prezentarea unui exemplar al tuturor intrrilor n sistem, inclusiv numele
fiecrei intrri, sursa, cine l completeaz, ce date va conine i cum vor fi culese datele
din el;
volumul minim, mediu i maxim de date i determinarea numrului de operaiuni de
intrare, al documentelor de ieire i al nregistrrilor stocate. Estimrile trebuie s fie
fcute pe baza frecvenei apariiei de noi nregistrri, a schimbrilor, tergerilor .a.;
descrierea modului de funcionare a noului sistem i a subsistemelor componente,
precum i a modului n care vor fi atinse obiectivele de ctre ntregul organism;
descrierea unor norme interne de conduit privind raportrile, programarea
activitilor, securitatea i protecia, personalul implicat i zona de acces pe categorii
ale acestuia;
prezentarea restriciilor existente n sistem, cum ar fi statutele i regulamentele de
organizare;
o list a problemelor de politic curent a organizaiei i conflictele existente cu
utilizatorii, ca i modul lor de soluionare;
punctele de control al datelor, pentru a se asigura sigurana i controlul realizrii
operaiunilor (pentru intrri, ieiri i prelucrarea tranzaciilor). Se vor meniona tipul
controlului i utilitatea lui (dac are rolul de a preveni, a detecta sau corecta);
necesitile de reorganizare a unitii pentru a rspunde cerinelor utilizatorilor.
Reorganizarea se poate referi la problemele personalului, incluznd adugarea de noi
funcii, reconfigurarea locurilor de munc sau desfiinarea altora. Se va schia o nou
structur organizatoric.
n afara raportului detaliat, se va nainta o sintez pentru conducere, fr s se apeleze la
limbajul tehnic, pentru a se prezenta cerinele utilizatorilor i efortul de elaborare a noului
sistem. Dac este posibil, raportul poate fi nsoit de exemple de structuri ale nregistrrilor,
exemple de ieiri sau grafice, pe variante strategice ale proiectelor propuse.
Odat ce au fost determinate cerinele utilizatorilor, echipa de proiectare va avea misiunea
s continue munca de obinere a acordului i aprobrii utilizatorilor i conducerii. Se vor
organiza ntlniri pentru a se explica noul sistem, pe baza prezentrilor orale, a sintezei
SELECTAREA VARIANTEI STRATEGICE DE PROIECTARE A SISTEMELOR 201
conducerii privind cerinele utilizatorilor i a unor documente dintre cele ntocmite anterior.
Dup acceptul utilizatorilor, conducerile departamentelor implicate vor semna documentele
necesare aprobrii rezultatelor fazei desfurate.
Analiza de sistem se finalizeaz cu raportul analizei de sistem, prin care se sintetizeaz i
se documenteaz constatrile etapei de analiz. Un raport sintetic i un exemplar din
documentaie servesc drept elemente de baz pentru proiectanii de sistem.
Raportul analizei conine:
scopul, domeniul, obiectivele i restriciile proiectului;
legtura proiectului cu planul strategic al ntregului sistem informaional;
criticile aduse sistemului de ctre analiti;
o sintez a problemelor existente n sistemul curent i restriciile lui;
recomandri pentru mbuntirea sistemului existent i proiectarea celui nou;
descrierea informaiilor necesare lurii 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 investigrii iniiale pentru a se stabili dac se va trece mai departe la
studierea sistemului; la sfritul studiului de fezabilitate, pentru a se stabili dac se va trece la
etapa de determinare a necesarului de informaii; dup terminarea fazei de analiz, pentru a se
hotr dac se va continua cu faza de proiectare.
9.2 Procedura de selecie a celei mai bune variante

strategice de proiectare
Pn acum, n faza de analiz, au fost determinate i structurate cerinele sistemului, iar
acum ne ocupm de ultima subfaz, care premerge trecerea la faza de proiectare. Dar de ce este
nevoie s definim mai multe variante de proiectare?
n primul rnd, decizia asupra variantei optime aparine utilizatorilor i conducerii firmei,
datorit importanei ei deosebite. Pentru a fi n msur 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 rsfrnge
asupra unuia din celelalte dou sau chiar asupra ambelor aspecte. De exemplu, accentul pus pe
calitatea sistemului (cum ar fi includerea tuturor cerinelor funcionale i nefuncionale n
sistem) ar presupune costuri i timp de realizare mai mari. Dac se dorete minimizarea
costurilor i reducerea timpului de realizare, atunci calitatea sistemului va fi mult afectat.
Obinerea unui sistem de calitate i ntr-o perioad scurt de timp duce la sporirea
considerabil a costurilor (vor fi angajai numeroi specialiti din afara firmei). Prin urmare, se
poate interveni doar asupra a dou din cele trei aspecte importante care privesc dezvoltarea
sistemelor informaionale.
Un alt motiv, care justific necesitatea elaborrii mai multor variante de proiectare, este
legat de pericolul familiarizrii excesive a membrilor echipei cu anumite tipuri de probleme1.
Dac ei sunt specializai cu precdere n tehnologia bazelor de date, atunci soluia 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 soluie anume la un gen
similar de problem, varianta propus de ei va fi ultima lor realizare la dezvoltarea unui alt
1. Oprea, D. Analiza i proiectarea sistemelor informaionale economice, Ed. Polirom, Iai, 1999, p. 277.
sistem. Dac ea ar fi i cea mai bun soluie nu ar fi nimic grav, ns, de multe ori, propunerea
este subiectiv.
Date fiind aceste tendine, s-a ajuns la concluzia c o echip de analiz trebuie s propun
cel puin dou soluii la problema supus analizei. n teorie se spune c, dac exist trei seturi
de formulri ale cerinelor, trei medii de implementare i patru surse ale softului de aplicaii,
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 ateniei cuvenite doar
pentru trei variante. Numrul este agreat de cei mai muli specialiti, ntruct prin el s-ar
surprinde punctele eseniale ale unui spectru posibil de soluii: cele dou extremiti ale lui i
mijlocul. n cele ce urmeaz, vom face o scurt descriere a fiecreia dintre cele trei variante.
Varianta 1 reprezint partea de jos a spectrului i poate fi caracterizat astfel:
este cea mai conservatoare n ceea ce privete costurile, efortul depus i tehnologiile
implicate;
de cele mai multe ori, soluionarea problemei nu nseamn numai folosirea
calculatorului;
este puternic orientat spre realizarea, pe hrtie, a fluxurilor informaionale mai
eficiente sau spre eliminarea redundanelor din procesele curente;
ofer tot ceea ce a solicitat utilizatorul, printr-un sistem care difer foarte puin de cel
existent.
Varianta 2, de la cellalt capt al spectrului, superior, merge mult mai departe dect
simpla rezolvare a problemei i conine performane pe care probabil c utilizatorul i le-ar
dori. Caracteristicile eseniale sunt:
orientarea spre funcionalitate;
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 copleit 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 trsturile celorlalte dou variante, renunnd la obsesia ncadrrii n anumite
costuri i prelund ca obiectiv central funcionalitatea de nalt nivel;
este varianta de compromis.
ncadrarea n cele trei soluii se realizeaz printr-o minuioas analiz a cerinelor
sistemului.
Selectarea celei mai bune dintre ele se efectueaz cu ajutorul procedurilor cantitative.
Analitii pot sugera varianta perceput de ei ca fiind cea mai bun, dar echipa managerial va
avea ultimul cuvnt. Un proiect poate fi, de asemenea, oprit n aceast etap.
Oricum, n aceast subfaz trebuie s se realizeze urmtoarele activiti:
1. Generarea strategiilor posibile de proiectare.
2. Selectarea celei mai bune strategii.
3. Prezentarea planului de baz al proiectului pentru regsirea strategiei selectate n
sistemul informaional n curs de realizare.
n continuare, vom aborda, pe rnd, aceste trei activiti.
9.3 Generarea variantelor strategice ale proiectului

Pentru generarea variantelor strategice ale proiectului trebuie luate n considerare
urmtoarele probleme:
aria de ntindere i nivelul de informatizare;
sursele softului
selecia softului i a hardului;

implementarea;
limitele organizaiei.
Variantele proiectului trebuie s respecte dou categorii de condiii, prezentate sub forma:
funciilor obligatorii ale noului sistem;
restriciilor impuse.
1. Stabilirea minimului necesar de informaii solicitate de noul sistem
Trsturile pe care le poate dobndi sistemul sunt mprite, uneori, n trei categorii:
obligatorii, importante i dorite.
Trsturile sau caracteristicile sistemului se concretizeaz n:
datele reinute n sistem;
ieirile sistemului (rapoarte, ecrane, documente, rspunsuri la ntrebri);
analizele pe baza crora se obin noi informaii;
accesibilitatea, timpul de rspuns, modul de exploatare (n timp real, partajat .a.).
2. Determinarea restriciilor din noul sistem
Restriciile pot fi generate de factori ca:
un termen anume cnd sistemul trebuie schimbat;
resursele financiare i umane disponibile;
elementele din sistemul curent ce nu pot fi schimbate;
restricii impuse de cadrul legislativ sau de contracte;
importana 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 importana lor,
explicndu-se clar care sunt motivele ordonrii lor ntr-o anumit form.
n continuare, vom pune n discuie principalele probleme care stau la baza generrii
variantelor strategice de proiectare. n acest sens, vom demonstra modul n care pot fi
formulate diferite strategii n legtur cu o anumit problem, dar vom oferi i o scurt
descriere a celor mai importante variante ntlnite n practic, ce o considerm util n
activitatea de evaluare i selecie a celei mai bune strategii.
9.3.1 Variantele de proiectare privind aria de ntindere i nivelul de

informatizare
Aa cum am vzut, una dintre activitile realizate n faza de analiz const n definirea
ariei de ntindere a sistemului. Obiectivul urmrit atunci era definirea granielor sistemului
prin identificarea funciilor ce vor fi incluse i a legturilor cu mediul su extern. Toate aceste
informaii au fost structurate cu ajutorul diagramelor fluxurilor de date.
Acum, nainte de a se trece la proiectarea sistemului, trebuie luat decizia cu privire la
funciile care vor fi incluse n sistem. De regul, utilizatorii solicit mai multe cerine
funcionale, a cror satisfacere ar duce la depirea bugetului alocat i/sau a timpului de
realizare planificat. Mai mult, se ntmpl ca utilizatorii s cear adugarea unor noi funcii
dup ce s-a trecut la faza de proiectare.
Astfel de situaii pot fi evitate prin formalizarea procesului de identificare, grupare i
stabilire a prioritii cerinelor informaionale. 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 cerinele acestora.
Pentru a decide asupra funciilor (cerinelor funcionale) ce vor fi incluse n sistem este
necesar formularea unor variante de proiectare. Fiecare variant va ngloba mai puine sau
mai multe din cerinele utilizatorilor. Aceast sarcin poate fi uurat prin gruparea cerinelor
sistemului n trei categorii: obligatorii, importante i dorite. Stabilirea prioritii fiecrei
cerine este efectuat mpreun cu utilizatorii i poate fi realizat chiar n faza de analiz, pe
msur ce acestea sunt identificate.
Determinarea prioritii fiecrei funcii se face, de regul, n strns legtur cu descrierea
nivelului de informatizare a sistemului. Nivelul de informatizare privete suportul pe care
sistemul informatic l va oferi pentru fiecare funcie n parte. Pentru cele mai multe funcii ale
unui sistem, pot fi definite cel puin trei niveluri de informatizare: mic, mediu i mare.
n cazul unui nivel mic de informatizare, sistemul se va limita la gestiunea nregistrrilor
care privesc acea funcie. Aplicaia va conine formulare pentru introducerea, modificarea,
validarea i salvarea datelor; va furniza unele informaii sub forma rapoartelor programate. Un
nivel mare de informatizare presupune ca sistemul s realizeze ct mai multe din prelucrrile
specifice funciei respective. Definirea acestui nivel este foarte dificil. Dac n cazul unui
nivel mic de informatizare se urmrete, de regul, doar automatizarea procedurilor manuale
existente, acum trebuie sesizate noi moduri de lucru, trebuie regndit complet modul de
realizare a acelei funcii, cu scopul mbuntirii radicale a performanelor. Acest cadru mai
este ntlnit sub numele de reproiectarea proceselor economice (Business Process
Reengineering BPR).
Varianta nivelului mediu de informatizare reprezint, de obicei, o combinaie 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, innd cont de restriciile privind bugetul i timpul de realizare.
Dup definirea variantelor de proiectare, pe baza prioritii i nivelurilor de informatizare
pentru fiecare funcie, se trece la evaluarea acestora. Drept criterii de evaluare vor fi utilizate,
n primul rnd, restriciile rezultate din studiile de fezabilitate a proiectului. Este evident c
extinderea funcional a sistemului i un nivel ridicat de informatizare vor implica costuri mari
i timp ndelungat.
n aceast faz, informaiile despre cerinele sistemului i dificultatea dezvoltrii unor
capaciti ale acestuia sunt mai detaliate, echipa de dezvoltare fiind n msur s evalueze mai
exact dect n fazele anterioare costurile pentru fiecare variant strategic de proiectare,
urmrindu-se ncadrarea n bugetul aprobat. Datorit i restriciilor de timp, noul sistem nu va
putea satisface toate cerinele utilizatorilor. ns, pe msur ce utilizatorii capt experien n
lucrul cu noul sistem, acesta poate fi extins pn ce se acoper toate cerinele i se obine
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 clienilor, dar propunem o
alt viziune a utilizatorilor, care s ofere o baz mai larg de discuie privind posibilitile 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 urmtoarele funcii:
Evidena comenzilor. Dup primirea comenzii se verific situaia clientului i a stocului
pentru produsele solicitate, iar n cazul avizrii se calculeaz valoarea comenzii, se emite i
transmite o ntiinare ctre client i se nregistreaz comanda.
Prelucrare stocuri. Pe baza solicitrii clientului se confirm existena stocului necesar, se
emite avizul de expediie, un exemplar fiind transmis la depozit, i se actualizeaz stocul.
Onorare comenzi. Avizul de expediie st la baza ntocmirii facturii, dup care are loc
nregistrarea i transmiterea ei ctre client. Datele privind facturile sunt prelucrate zilnic n
vederea ntocmirii notei contabile, ce va fi transmis, mpreun cu documentele justificative,
ctre sistemul de contabilitate general.

Eviden analitic clieni. Acest proces este necesar pentru ntocmirea situaiei clienilor de
ncasat i determinarea clienilor n litigiu. n acest sens, se deschide cte o fi analitic
pentru fiecare client important.
Analiza vnzrilor. Acest proces presupune agregarea datelor privind vnzrile 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
funciile (procesele de prelucrare) se regsesc n interiorul liniei punctate, ceea ce nseamn c
s-a optat pentru informatizarea ntregului sistem.
Informatizarea poate ncepe din momentul n care se primete comanda de la client
(eventual prin pot), ns poate merge pn la dezvoltarea unei aplicaii Web care s permit
clienilor, care au acces la Internet, s introduc comanda direct n sistem. Astfel, clienii 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 clienii s gseasc informaii cu privire la produse sau la
starea comenzilor lansate de ei. Eventual, sistemul ar putea s recomande clienilor i alte cri,
n funcie de cele comandate (de exemplu, cri de aceeai autori, cu subiecte asemntoare 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 urmrire a vnzrilor
n continuare, avizarea comenzilor se poate face tot automat, prin implementarea n

aplicaie a unor reguli i politici de creditare, stabilite de conducere, precum i calculul valorii
comenzii i emiterea ntiinrii. Nivelul de informatizare poate fi sporit prin transmiterea
electronic a ntiinrii.
Pe baza comenzii primite, i dup avizarea acesteia, se emite automat avizul de expediie
i factura, dup care urmeaz nregistrarea lor i generarea automat a notei contabile la
sfritul fiecrei zile. O facilitate suplimentar legat de prelucrarea stocurilor ar consta n
comandarea automat, ctre edituri, a crilor pentru care exist cerere i stocul este sub limit.
Informatizarea complet a evidenei analitice a clienilor ar putea presupune i

determinarea profilului clienilor pe baza datelor privind istoricul vnzrilor, ceea ce ar permite
generarea unor oferte personalizate pentru fiecare client.
Informatizarea analizei vnzrilor poate viza doar simpla generare a unor rapoarte pentru
conducere, ns se poate opta pentru dezvoltarea unei aplicaii OLAP care s acceseze un
depozit de date (data warehouse), oferind astfel posibilitatea efecturii unor analize
multidimensionale asupra datelor.
n figura 9.2 este pus n eviden o variant de informatizare parial a sistemului. Se
poate observa c prelucrarea stocurilor nu mai este informatizat, ceea ce nseamn c avizul
de expediie se ntocmete manual la depozit, la fel ca i operarea stocurilor. De asemenea, s-a
renunat la generarea automat a notelor contabile, aceast funcie fiind preluat de sistemul de
contabilitate, cruia i va fi transmis factura. i analiza vnzrilor este plasat n afara ariei de
informatizare, optndu-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 parial a sistemului de urmrire a vnzrilor
Atunci cnd se pune n discuie definirea ariei de informatizare, se poate lucra la un nivel
de descompunere mai fin. Altfel spus, aceast discuie nu se limiteaz la stabilirea proceselor
din diagrama de nivel 0 care s fie sau nu informatizate, ci trebuie luate n considerare i
subprocesele fiecrei funcii din diagrama de nivel 0. Prin urmare, vor fi luate n considerare
i diagramele de pe nivelurile inferioare.
n general, pentru fiecare funcie pot fi definite cel puin trei niveluri de informatizare:
inferior, mediu i l superior. n tabelul 9.1 sunt prezentate att aria de cuprindere, prin
ncadrarea funciilor sistemului n una din cele trei categorii de proriti, ct i nivelul de
informatizare pentru fiecare funcie n parte, prin prezentarea variantelor de informatizare.
Stabilirea prioritii se efectueaz n funcie de cerinele utilizatorilor i obiectivele sistemului.
De exemplu, dac unul din obiectivele sistemului vizeaz mbuntirea relaiilor cu clienii,
atunci funciile care permit firmei s rspund mai rapid i mai bine la cerinele clienilor vor fi
obligatorii i se va lua n considerare un nivel de informatizare ct mai bun.
Tabel nr. 9.1 Prioritile i nivelul de informatizare al principalelor funcii

Funciile 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 ctre un angajat la real comenzii direct de ctre
intervale regulate de timp client
Controlul Dorit Oferirea rspunsului Oferirea rspunsului Notificarea automat
strii dup un anumit timp n timp real de ctre
comenzii un angajat sau
verificarea direct de
ctre client prin Web
Verificare Important Generarea periodic a Verificarea n timp Verificarea n timp real de
situaie client listelor real la preluarea ctre clieni prin Web
comenzii
Verificare Dorit Generarea periodic a Verificarea n timp Verificarea n timp real de
stoc listelor cu stocuri real la preluarea ctre clieni prin Web
comenzii
ntiinare Important Tiprire i transmitere Generare i transmitere Generare i transmiterea
client prin pot 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
promoionale chestionarelor vnzrilor
Determinare Dorit Chestionare i Analiza istoricului Combinarea ambelor
profil clieni prelucrarea lor vnzrilor variante
Actualizare Dorit Actualizarea periodic a Actualizarea n timp Rezervarea stocului de
stoc stocurilor real odat cu avizarea ctre client odat cu
comenzii transmiterea comenzii prin
Web
Generare Obligatorie Tiprire la cerere Afiare on-line n timp
situaie clieni real
de ncasat
Generare Obligatorie Tiprire la cerere Afiare on-line n timp
situaaie real
clieni n
litigiu
Generare fi Important Tiprire la cerere Afiare on-line n timp
client real
Generare not Dorit Generare recapitulaie Generare lunar a Generare not contabil
contabil tranzacii notei contabile pentru fiecare tranzacie
Analiz Dorit Tiprire rapoarte Instrumente OLAP pentru
vnzri diverse analiza datelor
Fiecare celul din ultimele trei coloane trebuie detaliat ntr-o documentaie separat.
Dup cum se poate sesiza cu uurin, informatizarea anumitor funcii depinde de nivelul
de informatizare a altor funcii. De exemplu, transmiterea de materiale promoionale
personalizate nu ar fi posibil fr definirea profilului clienilor pe baza analizei istoricului
vnzrilor. De aceea, diagramele fluxurilor de date trebuie urmrite cu mult atenie, altfel se
poate ajunge la obinerea unui sistem ineficient. De regul, se renun la informatizarea

activitilor situate la extremitatea fluxului logic al activitilor din sistem.
n concluzie, diagrama fluxurilor de date joac un rol important nu doar n reprezentarea
logic a prelucrrilor din sistem, ele stnd i la baza definirii variantelor strategice de
proiectare a sistemului, permind 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,
urmrindu-se n primul rnd ncadrarea n bugetul aprobat i perioada de timp stabilit. Echipa
de realizare poate cere suplimentarea bugetului i prelungirea timpului necesar pentru
dezvoltare, justificnd conducerii necesitatea nglobrii anumitor funcii n sistem.
Funciile care vor fi informatizate, precum i nivelul de informatizare ales sunt evideniate
n tabelul 9.1.
9.3.2 Formularea variantelor de implementare

Implementarea unei soluii poate fi realizat n mai multe moduri. De exemplu, aplicaiile
standard (cum sunt aplicaiile de gestiune a stocurilor, evidena clienilor, contabilitate
general, resurse umane-salarizare etc.) pot fi achiziionate de pe pia de la o firm
productoare de software. Dac aceast soluie nu este agreat de firm, se poate opta pentru
dezvoltarea noului sistem n cadrul firmei, fie cu specialitii proprii, fie prin contractarea unor
specialiti din afara firmei pentru realizarea unor activiti, care presupun un nivel de expertiz
tehnic deosebit (cum ar fi proiectarea i programarea aplicaiilor Web, dezvoltarea
sistemelor distribuite, dezvoltarea aplicaiilor 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 condiiilor din firm i caracteristicilor sistemului informaional.
Diferitele variante de implementare a sistemului se regsesc n spaiul definit de dou
dimensiuni: opiunea achiziionare/dezvoltare i opiunea n cadrul firmei/n afara firmei.
Cadrul astfel format i poziionarea celor mai importante variante de implementare sunt puse n
eviden n figura 9.3.
Externalizarea
serviciilor
informaionale
Achiziionare
Soluii Soluii
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 conine un spectru de valori, nu doar valorile extreme
evideniate n figura 9.3. Se poate opta pentru achiziionarea ntregului sistem sau pentru
dezvoltarea n totalitate a acestuia, ns, ntre aceste dou extreme, pot fi identificate i alte
soluii, n care o parte a sistemului s fie cumprat, iar cealalt parte s fie dezvoltat. De
exemplu, se poate opta pentru achiziionarea unei soluii de pe pia, dar care s necesite
modificarea unor componente sau adugarea altora n vederea adaptrii la anumite cerine
specifice firmei sau pentru crearea interfeelor cu sistemele existente n firm.
n mod similar, exist mai multe opiuni n ce privete 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 informaionale
Externalizarea a devenit una din metodele cele mai eficiente de reducere a costurilor i de
mbuntire a performanelor unui grup de activiti din cadrul firmei. Externalizarea
sistemelor informaionale (sau a serviciilor informaionale) presupune transferul ctre un
furnizor a managementului sistemului, respectiv a dezvoltrii i exploatrii lui. Externalizarea
sistemelor informaionale cuprinde o palet mai larg de posibiliti, de la externalizarea n
totalitate a sistemelor informaionale i pn la externalizarea dezvoltrii pariale a noului
sistem.
La o extrem se afl situaia contractrii unui agent pentru dezvoltarea i exploatarea
aplicaiilor pe calculatoarele acestuia, firma preocupndu-se numai de furnizarea datelor de
intrare i preluarea ieirilor sistemului. n acest caz, agentul contractat se va ocupa de toate
serviciile informaionale, inclusiv prelucrarea datelor, calculatoarele, programele, reeaua i
personalul aparinnd acestuia. n fapt, agentul va reprezenta departamentul informatic al
firmei pentru care presteaz serviciile. O variant apropiat presupune angajarea unei companii
care s furnizeze aplicaiile necesare i s le execute n cadrul firmei contractante pe
calculatoarele acesteia.
Se poate opta pentru externalizarea doar a activitilor de dezvoltare a sistemelor
informaionale, cu scopul dezvoltrii complete sau pariale a sistemului, cumprrii de pachete-
program i, eventual, adaptarea acestora la cerinele specifice ale clientului, sau obinerea de
asisten pe parcursul tuturor fazelor de dezvoltare a sistemului. Un exemplu tradiional const
n contractarea unui agent pentru testarea aplicaiilor la nivel de sistem.
Dup cum rezult din figura 9.3, n acest paragraf, prin externalizare facem referire la
ntregul sistem, inclusiv punerea n funciune i exploatarea sa de zi cu zi. Situaia contractrii
unei firme doar pentru dezvoltarea noului sistem sau a unei pri din acesta nu se ncadreaz
aici. Ea este evideniat n acea parte a formei Soluia dezvoltrii care corespunde opiunii
n afara firmei.
Externalizarea sistemelor informaionale 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 organizaiei. De aceea, ea nu reprezint propriu-zis o variant de implementare,
decizia fiind luat la nivelul conducerii superioare.
Externalizarea serviciilor informaionale este posibil prin apelarea la Application Service
Providers (ASP). Un ASP este o companie care dezvolt i furnizeaz servicii folosite n
comun de mai muli utilizatori, care pltesc un abonament sau taxe de folosire, serviciile fiind
furnizate dintr-o locaie central prin Internet sau printr-o reea privat. ASP presupune acces
partajat, sub control, la anumite servicii.
9.3.2.2 Surse ale softului
Dac soluia externalizrii serviciilor informaionale ar putea prea una prea radical,
firmele au la dispoziie i alte variante de implementare a sistemului. Ne referim la diferitele
surse ale softului.
n general, programele informatice pot fi obinute pe dou ci principale: achiziia unui

pachet de aplicaii de pe pia de la diferii furnizori, numit i soft la cheie, sau dezvoltarea
acestuia prin parcurgerea tuturor fazelor specifice ciclului de via al sistemelor
informaionale, soluie numit i soft la comand. Acestea dou nu reprezint dect valorile
extreme ale unui spectru, ntre ele putnd fi identificate alte soluii.
Softul necesar sistemului poate fi obinut pe urmtoarele ci:
cu fore proprii;
la comand;
la cheie;
la cheie modificat.
Softul realizat cu fore proprii
Din faza incipient a utilizrii calculatoarelor, aproape toate organizaiile i-au proiectat i
au scris propriile lor aplicaii. n multe cazuri, operaiunea este impus, unitatea neavnd de
ales alt modalitate. De cele mai multe ori, nu existau dect cteva tipuri de programe
disponibile pe pia, care nu satisfceau ntotdeauna necesitile organizaiilor. Dei acum la
dispoziia utilizatorului se afl o larg varietate de soft la cheie, mai exist nc uniti care
consider c problemele lor specifice nu se pot rezolva achiziionnd un soft de pe pia. Alte
organizaii sunt att de mari i de complexe nct singura modalitate de a-i satisface cerinele
o constituie elaborarea propriului soft de aplicaii.
Soft realizat la comand
O alt variant de procurare a softului poate fi angajarea din afara unitii a
programatorilor/analitilor sau a unei companii de software pentru a elabora pentru client un
pachet-program de aplicaii. O astfel de modalitate poate s utilizeze i componente din
programele existente deja la client, bineneles, prin adaptarea, completarea i combinarea lor,
astfel nct s rspund noilor cerine.
Elaborarea programelor de ctre clieni 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 cerine, i analist, care trebuie s le interpreteze i s le adapteze n
structuri de programe, fiiere de date, intrri i ieiri. Analistul trebuie s lucreze cu utilizatorii
pentru a determina cu exactitate toate formatele de rapoarte i ecrane. mpreun vor identifica
intrrile sistemului, datele necesare fiecrei intrri, precum i datele din structura fiierelor.
Analistul trebuie, de asemenea, s elaboreze descrieri detaliate ale tuturor prelucrrilor interne,
logic necesare obinerii formei dorite a ieirilor. Aceste specificaii 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. Unitile trebuie s-i exercite controlul cu mare
atenie, mai ales atunci cnd se lucreaz cu personal din exteriorul ei. Realizatorul softului
trebuie s neleag n profunzime modul cum lucreaz unitatea.
Pentru activitatea prestat se va ncheia un contract care va consemna responsabilitatea
contractantului de a rezolva cerinele utilizatorului i care s-i permit unitii s-l interpun
atunci cnd, n anumite condiii, 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. Relaia dintre colaborator i unitate trebuie s fie definit cu
rigurozitate i de aceea trebuie s existe o legtur permanent ntre pri. Costurile trebuie s
fie ndeaproape controlate, iar cheltuielile bneti minimizate, pn cnd proiectul a fost
completat i acceptat.
Softul la cheie
Softul la cheie, realizat de ctre productorii de calculatoare sau de ctre companii
specializate n realizarea de software, este vndut pe pia pentru o mare diversitate de
utilizatori cu cerine similare. Unii productori de software combin softul cu hardul i le vnd
ca pachete. Aceast combinaie este numit sistem la cheie, deoarece furnizorul instaleaz
ntregul sistem, iar utilizatorul trebuie doar s rsuceasc cheia pentru a beneficia de
funciile acestuia.
De remarcat faptul c, la nivelul anilor 1990, n topul primelor 10 firme, cu veniturile cele
mai mari din software, cinci sunt firme productoare 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 puin 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, estimrile arat c peste 70% din costul instalrii
calculatoarelor de astzi provin fie din utilizarea, fie din procurarea pachetelor-program la
cheie. Odat cu trecerea timpului, apar pachete-program tot mai performante, rspunznd
cerinelor unitilor, ca i cnd ele ar fi elaborate cu propriile fore sau atingnd cele mai
diverse pretenii ale organizaiilor mari i complexe.
Modificarea softului la cheie
Numeroase persoane consider c este mai bun calea de a satisface cerinele utilizatorilor
prin procurarea sistemului la cheie i modificarea lui conform unor cerine anume.
Modificrile pot fi fcute de ctre cel care a livrat softul, de ctre personalul unitii
cumprtoare sau de ctre o alt companie furnizoare de software sau de ctre un alt utilizator
al pachetului. n aceast categorie sunt incluse soluiile ERP (Entreprise Resource Planning).
Din relatrile anterioare se pune ntrebarea: Care metod este mai bun? Datorit
situaiilor i condiiilor diferite, nu exist o cale anume, catalogat ca fiind cea mai bun.
Fiecare situaie trebuie luat n calcul separat. De regul, softul la cheie tinde s fie cea mai
bun soluie, cnd rspunde exigenelor unitii sau cnd el poate fi uor modificat, ceea ce
corespunde sistemelor mici i cazului n care cerinele nu sunt complexe. Odat cu creterea
mrimii i complexitii sistemului sau a cerinelor lui, exist slabe sperane ca soluia softului
cumprat s fie cea mai bun. Muli specialiti consider c, dac softul nu poate fi realizat cu
fore proprii, varianta apelrii la persoane din afar pentru a-l scrie este mai scump dect
softul la cheie. Soluia trebuie s vin, totui, de la fiecare unitate, dup ce-i evalueaz
propriile cerine, prin analiz, i dup ce cunoate softul existent pe pia.
Soft realizat cu fore proprii
Avantaje Dezavantaje
1. Programele pot fi concepute astfel nct s 1. Este foarte scump, munca de elaborare este foarte
rspund cu exactitate cerinelor unitii. mare, chiar i cele mai simple aplicaii pot costa
2. Unitatea poate funciona conform cii dorite i nu mii de dolari.
cum este prezentat prin pachetele la cheie. 2. De regul, dureaz mult, nsemnnd luni sau ani de
3. Pachetele proprii sunt mult mai compatibile cu alt zile.
software din organizaie, deci integrarea poate fi 3. Posibilitatea de a eua, la primele ncercri de
uor realizat. utilizare, este mai mare.
4. Demarajul i iniierea n tehnica de utilizare a 4. Solicit costuri deosebite, timp i control exigent.
pachetelor sunt mult mai uor realizabile. Trebuie s se apeleze la o programare standard,
5. Moralul angajailor 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 fore umane.
5. Procesul de elaborare solicit prea mult utilizatorii
i conducerea, deoarece acetia trebuie s analizeze
cerinele, s sprijine proiectarea, s revizuiasc, s
testeze sistemul, s identifice defeciunile .a.
6. Soluia cu specialiti din afar este foarte riscant.
Soft la cheie
1. Costul este mult mai redus fa de celelalte 1. Cerinele firmei nu pot s se regseasc perfect n
variante, deoarece costul elaborrii i ntreinerii ceea ce ofer pachetul-program, fiind necesare
se mparte la numeroi utilizatori. schimbri n modul de lucru, modificri ale unor
2. Practic nu exist timp de ateptare pn la forme folosite anterior, chiar revizuirea stilului de
utilizarea lui. afaceri al firmei, ceea ce nu aduce efecte benefice.

3. Cumprtorul 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 preul
utilizatori ai aceluiai pachet. pachetului procurat.
4. Utilizatorul poate s aleag pachetul care s 3. Programele ultrageneralizate nu sunt la fel de
rspund cel mai bine propriilor cerine. eficiente ca pachetele clientului sau cele
5. Programele sunt mult mai puin productoare de modificate.
erori, ele fiind testate anterior, conform cerinelor 4. Nu ofer posibilitatea specialitilor unitii s
utilizatorilor. intervin n caz de eec.
6. Furnizorul poate s-i actualizeze pachetul cu 5. Exist riscul ca realizatorul softului s dea faliment
cheltuieli mult mai reduse dect ale oricrui sau s nu poat efectua actualizarea.
client, dac ar face acelai lucru.
7. ntruct astfel de produse sunt realizate de ctre
experi, imitarea lor implic cheltuieli imense.
8. Documentaia lor este mai bun.
9. Utilizatorul nu are nevoie de prea muli analiti i
programatori, uneori chiar nu este nevoie de ei
pentru a proiecta i ntreine softul.
Soft la cheie modificat
1. Rspunde mai bine cerinelor unitii dect softul 1. Deseori, programatorii competeni sunt dificil de
la cheie. gsit, ntruct, nu de puine ori, modificarea
2. Compania poate lucra conform modalitii pe care programelor este mai dificil dect scrierea lor
i-o dorete i nu cum se impune prin programul iniial.
la cheie. 2. Muli furnizori nu accept modificarea
3. Pot fi mai ieftine i solicit mai puin timp dect programelor lor.
softul realizat cu fore proprii. 3. Documentaia despre schimbri poate fi incomplet
4. Modificrile pot fi fcute de ctre cel ce l-a sau inexistent.
realizat, apropiindu-se astfel de exigenele 4. Modificrile substaniale pot fi la fel de scumpe ca
oricrui utilizator cu un standard de elaborare i programele scrise de client.
ridicat. 5. Modificrile pot genera erori logice de control,
precum i alte efecte neateptate.
9.3.3 Selectarea furnizorilor

Orice organizaie poate selecta de pe pia furnizorul dorit, prin consultarea crilor de
telefon, prin pliante de prezentare, urmrind reviste comerciale sau de calculatoare, participnd
la conferine, apelnd la organizaii specializate pe consultan .a.
Exist o multitudine de tipuri de furnizori, alturi de productorii de calculatoare.
Segmente majore de activiti se ocup cu producerea mini- i microcalculatoarelor, furnizarea
sistemelor la cheie. Exist birouri de servicii, furnizori specializai pe aplicaii n timp partajat,
companii de nchiriere calculatoare, productori de periferice, furnizori de tehnici moderne de
conducere, precum i furnizori de software. Cnd 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 funcie de tipul lor, ofer servicii sau bunuri
diferite, dup cum urmeaz:
Productorii de calculatoare mari realizeaz i vnd o mare varietate de sisteme de calcul
cu destinaie general. Calculatoarele mari sunt solicitate numai de uniti mari i de organisme
guvernamentale sau locale. Multe dintre companiile productoare ofer, de asemenea, i
servicii. Este cazul firmelor IBM, DEC i Unisys.
Productorii de minicalculatoare urmresc obinerea de echipamente cu dimensiuni mai
mici fa de categoria precedent. Minicalculatoarele solicit limbaje mai puin puternice dect
cele mari. Cei mai muli productori de calculatoare mari ofer i minicalculatoare.
Productorii de microcalculatoare sau calculatoare personale sau desktop-uri sunt cei mai
numeroi, dar dintre ei se desprind firmele IBM, APPLE, Compaq, Dell, Hewlett-Packard,
inclusiv firmele japoneze.
Productorii de echipamente periferice produc o mare varietate de echipamente de

intrare, de ieire i de stocare.
Companiile pentru nchirierea calculatoarelor sau oferirea lor n sistem leasing pun la
dispoziia utilizatorilor sisteme de calcul pe termen scurt sau lung.
Furnizorii sistemelor la cheie procur echipamente de la productori i le revnd n
combinaie cu softul de aplicaie adecvat, precum i n conformitate cu necesitile clienilor.
Furnizorii de software elaboreaz i vnd aplicaii, programe de uz general, utilitare,
sisteme de gestionare a bazelor de date i alte tipuri de programe pentru toate mrimile 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 doleanele utilizatorilor.
Birourile de servicii asigur servicii de prelucrare a datelor cu propriile echipamente
contra unor tarife. Serviciile sunt mai ieftine dect atunci cnd s-ar apela la propriile lor
calculatoare, ntruct cheltuielile se mpart la mai muli utilizatori. Totui, securitatea datelor
nu mai este la fel de bine asigurat.
Furnizorii de aplicaii n timp real asigur calculatoarele pentru prelucrri, echipamente
de stocare on-line i acces la bnci de date contra unor tarife. Utilizatorii acceseaz
calculatoarele n mod interactiv, prin intermediul terminalelor plasate la distan i al liniilor
de telecomunicaii. Tarifele percepute depind de durata utilizrii i de resursele cerute pentru
facilitarea accesului.
O atenie deosebit trebuie acordat evalurii furnizorului, situaie n care se vor avea n
vedere urmtoarele criterii:
Este un furnizor cu mult experien i este bine consolidat? Mai are instalate sisteme
asemntoare?
Furnizorul poate s ofere o list a clienilor vechi, de la care s poat fi obinute
informaiile dorite?
Are o reputaie deosebit pentru sigurana sistemelor oferite? Sunt satisfcui clienii
de serviciile prestate?
Poate asigura furnizorul hardul, softul i ntreinerea?
Poate asigura furnizorul sprijinul necesar pentru implementare i instalare?
Furnizorul este de acord s consemneze promisiunile fcute printr-un contract ferm?
Va fi semnat un contract care s protejeze interesele unitii beneficiare?
Care este situaia financiar a furnizorului?
Asigur o garanie adecvat ofertei?
Ofer ncredere calitatea personalului furnizorului, prin experiena lui?
Asigur instruirea necesar?
Ct de puternic va fi sprijinul ulterior i ct de eficient?
9.3.4 Selectarea hardului

Cei mai muli primi-utilizatori de microcalculatoare nu tiu s rspund la ntrebarea Ce
fel de calculator ar trebui s-mi cumpr?. Desigur, rspunsul la o asemenea ntrebare depinde
de cerinele utilizatorului, precum i de alte circumstane; dar, cu certitudine, exist mai multe
tipuri de calculatoare care s le satisfac necesitile. Rspunsul cel mai corect ar fi
Cumprai un micro-calculator care s v satisfac toate cerinele i care s ofere, cu un cost
redus, siguran n funcionare, precum i servicii ct mai bune i diversificate. Cu alte
cuvinte, nti trebuie selectat softul i furnizorul i apoi se va lua n discuie problema
echipamentului.
i pentru o corporaie se pun aceleai probleme. Numai c ele vor cumpra

microcalculatoare i calculatoare mari. Mai mult, progresul tehnologic deosebit de rapid face
ca un sistem cumprat astzi s devin depit peste doi sau cinci ani. Unitile economice i
populaia interesate s cumpere calculatoare difer att n esen, ct i ca necesiti i
obiective nct este, practic, imposibil s se ofere o list exact de criterii pentru o selecie
bun. Totui, unele dintre cele mai comune criterii pot fi:
cost;
capacitatea de a lucra cu softul dorit;
viteza de prelucrare a unitii centrale de prelucrare i capacitatea ei;
posibilitile memoriei auxiliare;
echipamentele de intrare/ieire;
capacitatea de a lucra n regim de comunicaii;
capacitatea sistemului i posibilitatea de extensie;
vrsta tehnologic (model nou sau vechi);
compatibilitatea cu alte componente ale sistemului i cu alte sisteme;
evaluarea performanelor;
ntreinere uoar;
garania lui;
probleme de natur financiar (reduceri, scutiri .a.).
9.3.5 Formularea cererilor de ofert

Odat definite cerinele sistemului, organizaia este pregtit s invite furnizorii sau
consultanii pentru a propune echipamentele i programele ce rspund cerinelor ei. Furnizorii
poteniali sunt selectai pentru a se alege cei cu produsele cele mai convenabile pentru unitate.
Celor selectai 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
reinerea celei mai bune variante de sistem sau a primelor dou. Aceste sisteme se analizeaz n
profunzime pentru a testa modul cum rspund exigenelor organizaiei.
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, situaie n care furnizorii emit propuneri nsoite 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. Totui,
exist dezavantajul c furnizorul nu poate propune tehnologii pe care clientul nu le tie,
responsabilitatea seleciei rmnnd numai la latitudinea beneficiarului.
A doua modalitate de formulare a cererilor de ofert const n prezentarea unei forme
generalizate de definire a problemei i cerinelor sistemului. Varianta ofer furnizorilor
posibilitatea s propun diverse soluii. Dezavantajul: o mai mare dificultate n selectarea cu
exactitate a ofertelor fcute.
Coninutul cererii de ofert const n:
informaii generale introductive;
descrierea actualului sistem de prelucrare automat a datelor, inclusiv a principalelor
echipamente i aplicaii existente n firm;
specificaii pentru hardul i softul strict necesare i pentru cele ce ar fi dorite;
cerinele de securitate, protecie .a.;
o list a elementelor pe care furnizorul s le ofere n propunerea lui;
criterii de evaluare a propunerilor ce vor fi fcute;
programul de realizare a implementrii;
restricii de costuri;
creterea economic proiectat i eventualele schimbri;
solicitarea unor informaii 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 condiiile diversificrii continue a ofertei de produse i servicii informaionale de pe
pia, a oportunitilor de informatizare existente astzi.
De exemplu, n cazul variantelor de implementare, o soluie poate fi ieftin, dar nu
acoper toate funciunile cerute. Alt soluie poate satisface toate cerinele funcionale, dar
ruleaz pe platforme hardware i software nedorite sau implic o perioad prea mare de
implementare. Dificultatea acestei activiti este sporit de numrul mic de puncte comune
ntre diferitele variante, cum ar fi ntre cele de externalizare i dezvoltarea sistemului n cadrul
firmei sau ntre soluiile diferiilor furnizori.
Cu toate acestea, analistul va trebui s identifice un set de criterii comune care s permit
compararea ct 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: cerinele generale, cerinele funcionale i cerinele tehnice.
Cerinele generale privesc unele consideraii care nu au legtur direct cu sistemele
informatice, dar care sunt importante. n primul rnd, este vorba despre analizele de
fezabilitate, puse n discuie n faza de analiz. Fiecare variant luat n considerare trebuie s
fie fezabil din punct de vedere economic, tehnic, juridic i al programrii n timp. De
asemenea, se vor lua n considerare criteriile de evaluare a furnizorilor, a stabilitii i
performanelor lor. n cazul dezvoltrii n cadrul firmei, se va ine seama de riscurile asociate
proiectelor de dezvoltare a sistemelor informaionale, precum timpul solicitat sau personalul de
specialitate disponibil. Cteva dintre criteriile care pot fi considerate aici sunt prezentate n
tabelul 9.2.
Cerinele funcionale se refer la funciile pe care trebuie s le ndeplineasc sistemul. Ele
sunt evideniate n diagramele fluxurilor de date i au fost puse n discuie la generarea
variantelor de proiectare pe baza ariei i nivelului de informatizare.
n categoria cerinelor tehnice se includ toate celelalte cerine ale sistemului, care privesc
modul de operare, performanele sale etc. O list a criteriilor care pot fi ncadrate n aceast
categorie se gsete n tabelul 9.2.
Tabel nr. 9.2 Criterii de evaluare a variantelor de implementare
Cerine generale Cerine tehnice
Performanele nregistrare de furnizor Robusteea (sigurana n funcionare)
Garaniile i facilitile de service acordate Frecvena erorilor
de furnizor Calitatea programelor (uurina ntreinerii)
Angajaii cu experien disponibili Calitatea documentaiei
Costul dezvoltrii Uurina instalrii
Valoarea beneficiilor ateptate Flexibilitatea (uurina adugrii unor noi
Timpul necesar pn la punerea n funciune funcionaliti)
Costurile estimate pentru conversia datelor Uurina n exploatare (interfee prietenoase)
Impactul asupra firmei (instruirea Performane (timpul de rspuns)
utilizatorilor, schimbarea procedurilor Compatibilitatea cu platforma hardware i software
interne etc)
O list detaliat de criterii pentru evaluarea sistemului poate conine urmtoarele aspecte:
Pachetul selectat rspunde specificaiilor obligatorii din cerere? Ct 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 rspunde pachetul exigenelor sistemului pe toat durata lui de utilizare? Va avea

nevoie de modificri?
Softul conine elemente adecvate de control?
Caracteristicile tehnice sunt adecvate (vitez, precizie, siguran)?
Ali utilizatori sunt mulumii de pachet? Ce probleme au avut? Ce limite au observat
la el?
Documentaia pachetului este bun? Va asigura furnizorul o alt documentaie
concomitent cu modificrile ce vor fi fcute asupra pachetului?
Softul este compatibil cu ceea ce mai exist n unitate?
Pachetul este prietenos utilizatorului?
Softul este disponibil oricnd? Poate fi vzut i testat?
Pachetul are asigurat o garanie?
Softul este modularizat, flexibil i uor de ntreinut?
Este posibil exploatarea fiierelor prin sistemul interactiv (on-line)?
Poate furnizorul s asigure actualizarea continu a pachetului?
Ct de eficient este softul? Ct timp ia n execuie? De ct 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 operaiunilor
similare de intrare, prelucrare i ieire pe calculatoare diferite, selectndu-se cele cu timpul de
prelucrare cel mai redus; a doua variant utilizarea modelelor matematice de simulare a
realizrilor fiecrui sistem propus; a treia a punctajelor, n care sunt listate criteriile luate n
studiu, fiecare cu o greutate specific n totalul criteriilor, acordndu-se, pentru diferii
furnizori sau sisteme anume, note, n funcie de modul n care este atins criteriul respectiv.
Selecia se face dup ce se pondereaz greutatea specific i nota acordat, alegndu-se suma
cea mai mare.
A patra variant de evaluare se bazeaz pe aa-zisele costuri necesare. Se ntocmete o
list a tuturor performanelor ce ar trebui s fie ndeplinite de noul sistem. Dac unele
performane nu exist n anumite sisteme, se va calcula costul asigurrii acestora. Costul total
va nsuma costul de achiziie a sistemului, precum i costurile pentru atingerea performanelor
care lipsesc. Sumele obinute sunt elemente de comparabilitate, ct de ct 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 nti, identificarea criteriilor de evaluare i
stabilirea importanei relative a fiecruia. Unele criterii sunt mai importante pentru organizaie
dect altele. De exemplu, firma poate dori s cumpere doar de la un furnizor cu reputaie, cu
mult experien. n alt situaie, este posibil s existe suficient timp la dispoziie pn la
punerea n funciune a noului sistem, aa c restriciile de timp nu reprezint o cerin critic.
Trebuie determinate nu doar importana relativ a criteriilor n cadrul categoriei din care
fac parte, ci i importana relativ a categoriilor de cerine. O firm poate considera mai
importante cerinele generale dect cele funcionale.
Dup identificarea criteriilor de evaluare i determinarea importanei lor relative, se trece
la evaluarea fiecrei variante, prin acordarea unei note pentru fiecare criteriu, apoi se
pondereaz nota corespunztoare fiecrui criteriu cu factorul ce reprezint importana sa
relativ i se nsumeaz rezultatele obinute n vederea obinerii 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,
importana lor specific, notele acordate i punctajul obinut. Att pentru importana relativ,
ct 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 clienilor
Importana Varianta 1 Varianta 2 Varianta 3
Criterii de evaluare specific (soft la comand (soft la cheie) (soft la comand
n firm) specialiti din
afara firmei)
Criterii generale
Existena personalului 4 3 12 4 16 5 20
specializat
Costul dezvoltrii 5 4 20 2 10 5 25
Valoarea ateptat a 5 5 25 3 15 4 20
beneficiilor
Timpul de dezvoltare 4 3 12 5 20 2 8
Garanii i service 3 5 15 3 9 3 9
Total criterii generale 84 70 82
Criterii funcionale
nregistrarea comenzii 5 5 25 3 15 5 25
Crearea materialelor 4 5 20 0 0 5 20
promoionale
Determinarea profilului 3 5 15 0 0 5 15
clienilor
Urmrire clieni n litigiu 3 5 15 5 15 5 15
Analiz vnzri 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 funcionale 155 75 155
Cerine tehnice
Robusteea 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
Documentaia 3 3 9 5 15 3 9
Uurina instalrii 2 5 10 4 8 4 8
Calitatea interfeei 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
specialitii proprii. Varianta achiziionrii softului la cheie este cea mai slab, datorit faptului
c multe din cerinele funcionale ale sistemului nu sunt satisfcute 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 achiziionat de pe
pia.
9.5 Coninutul planului de baz al proiectului

Dup parcurgerea activitilor menionate anterior, finalizate prin cea mai important
dintre ele, selecia variantei ce urmeaz a fi implementat, planul proiectului capt 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 restriciilor ce pot afecta proiectul.
B. Recomandri. Se prezint un sumar al principalelor aspecte ale procesului planificrii i se
formuleaz recomandri pentru activitile urmtoare.
2. Descrierea sistemului
A. Variantele. O sumar descriere a variantelor de configuraie a sistemului.
B. Descrierea sistemului. Descrierea configuraiei selectate i prezentarea detaliat a datelor de
intrare, a activitilor executate, a informaiilor 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 operaional. Se ofer o analiz a modului n care vor fi rezolvate problemele
unitii, fie interne, fie n relaie cu competitorii, efectundu-se o evaluare a activitilor zilnice n
noile condiii.
D. Analiza legalitii i a contractelor. Sunt prezentate aspecte ale cadrului legal sau ale
riscurilor contractelor referitoare la proiect.
E. Analiza politicilor. Sunt oferite descrieri ale celor interesai de soarta proiectului i ale
percepiilor acestora fa de ceea ce se propune.
F. Analiza desfurrii calendaristice. Sunt puse la dispoziie diferite variante ale planificrii
calendaristice n strns concordan cu modul de alocare a resurselor.
4. Probleme ale managementului
A. Configuraia i managementul echipei. Sunt artate rolurile membrilor echipei i relaiile
dintre ei n ceea ce privete raportarea.
B. Planul comunicrii. Sunt oferite detalii despre procedurile de comunicare ce trebuie s fie
urmate de echipa managerial, de membrii echipei, precum i de ctre beneficiari.
C. Standardele i procedurile proiectului. Se descrie modul n care vor fi evaluate i acceptate
rezultatele proiectului de ctre beneficiari.
D. Alte aspecte specifice proiectului. Sunt abordate orice alte probleme referitoare la proiect
care nu au fost descrise n punctele anterioare.
Rezumat
Pn acum, n faza de analiz, ne-am ocupat de determinarea i structurarea cerinelor sistemului.
Altfel spus, s-a urmrit descrierea a ceea ce este i a ceea ce ar trebui s fie sistemul informaional.
Acum, ne aflm naintea fazei de proiectare, n care trebuie gsit rspunsul 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 privete definirea strategiei de proiectare.
Strategia de proiectare specific direcia care va fi urmat, n continuare, n dezvoltarea noului
sistem. Definirea ei presupune parcurgerea a dou activiti principale: generarea variantelor strategiei
de proiectare i selecia celei mai bune strategii. Decizia final, privind varianta de proiectare care va fi
urmat, aparine utilizatorilor i finanatorului, acest aspect constituind motivul principal pentru care
trebuie ca echipa de realizare s formuleze mai multe variante de sistem. Cei mai muli specialiti
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, selecia furnizorilor.
Oricare ar fi ele, variantele proiectului trebuie s respecte dou categorii eseniale de condiii, prezentate
sub forma funciilor obligatorii ale noului sistem i a restriciilor impuse.
Din punctul de vedere al soluiilor de implementare, variantele posibile se regsesc n cadranul
rezultat prin combinarea a dou dimensiuni corespunztoare opiunilor achiziionare/dezvoltare i n
cadrul firmei/n afara firmei.
Dup formularea clar a variantelor de proiectare, se trece la evaluarea lor n vederea selectrii celei
mai bune. Analitii vor trebui s gseasc criteriile de evaluare cele mai potrivite. n general, aceste
criterii pot fi grupate n trei categorii: cerine generale, funcionale i tehnice.
Pentru evaluare, poate fi aplicat metoda cotelor de nivel, modelele matematice de simulare,
metoda punctajelor sau cea bazat pe aa-zisele costuri necesare.
Rezultatele activitii de definire a strategiei de proiectare se concretizeaz n ceea ce, n practic,
poart numele de planul de baz al proiectului. El conine descrierea variantelor de sistem, recomandri,
studiile de fezabilitate efectuate i alte probleme legate de managementul proiectului
1. Definii strategia de proiectare a sistemelor informaionale.
2. Explicai necesitatea subfazei de definire a strategiei de proiectare.
3. Prezentai elementele componente al raportului detaliat ale cerinelor sistemului.
4. De ce este recomandat formularea a trei variante de proiectare?
5. Descriei succint activitile subfazei de definire a strategiei de proiectare.
6. Facei o scurt prezentare a problemelor n legtur cu care se pot genera variante de proiectare.
7. Explicai rolul diagramelor fluxurilor de date n definirea strategiei de proiectare.
8. Care sunt opiunile posibile de externalizare a serviciilor informaionale?
9. Realizai o comparaie ntre sursele de obinere a softului.
10. Enumerai 7 criterii utilizate la evaluarea furnizorilor i realizai o ierarhie a lor, din punctul de
vedere al importanei.
11. Cum pot fi grupate criteriile de evaluare a variantelor de implementare? Dai exemple din fiecare
categorie.
12. Care sunt metodele de evaluare a variantelor strategiei de proiectare?
13. Prezentai coninutul planului de baz al proiectului.
Probleme de echip
1. Definii trei variante de proiectare n legtur 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. Formulai o cerere de ofert pentru achiziia de echipamente i programe necesare sistemului
analizat n propriul studiu de caz.
3. Formulai trei variante de implementare pentru sistemul analizat n propriul studiu de caz, lund n
considerare sursele softului.
4. Evaluai cele trei variante prezentate la punctul anterior, utiliznd metoda punctajelor. Se va utiliza
modelul prezentat n tabelul 9.3. Specificai varianta cea mai bun i argumentai rezultatul obinut.
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, Iai, 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. Brjovanu, R.A. Cybermarket, cyberpli, bani digitali, frauda i splarea 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 nfiinare i operare,
Ed. Expert, Bucureti, 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. Drghici, M. Noile tehnologii de vrf i societatea, Ed. Politic, Bucureti, 1980.
27. Farca, D. Cui i-e fric de calculatorul electronic?, Ed. Albatros, Bucureti, 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. Soluii informatice integrate pentru gestiunea afacerilor ERP, Ed.
Economic, Bucureti, 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, Bucureti, 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. tiinific, Bucureti, 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 Managers 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. Meni, G. Introducere n afaceri electronice, Ed. Junimea, Iai, 2002.
69. Meni, G., Dumitriu, F. Outsourcing of Information System Development, n volumul
Innovative Applications of Information Technologies in Business and Management, Ed.
Tehnopress, Iai, 2002.
70. Meyer, B. Object-Oriented Software Construction, Prentice Hall, New York, 1988.
71. Modell, M. A Professionals 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. Perfecionarea programrii calculatoarelor utiliznd tabelele de decizie, n
Analele Universitii Al. I. Cuza, Iai, 1980.
75. OLeary, 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 informaionale economice, Ed. Polirom, Iai, 1999
79. Oprea, D. Managementul proiectelor. Teorie i cazuri practice, Ed. Sedcom Libris, Iai, 2002.
80. Oprea, D. Premisele i consecinele informatizrii contabilitii, Ed. Graphix, Iai, 1995.
81. Oprea, D. Globalizarea i securizarea informaional, n Prelegeri Academice, Academia
Romn, Filiala Iai, aprilie 2004.
82. Oprea, D. Protecia i securitatea informaiilor, Ed. Polirom, Iai, 2003.
83. Oprea, D., Dumitriu, F., Meni, G. CASE proiectarea asistat de calculator a sistemelor
informatice, Ed. Universitii Al. I. Cuza Iai, 1995.
84. Oprea, D., Meni, G. Sisteme informaionale pentru manageri, Ed. Polirom, Iai, 2002.
85. Patriciu, V.V. Sisteme electronice de pli, 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 Practioners 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. tiinific i Enciclopedic, Bucureti, 1981.
93. Restian, A. Unitatea lumii i integrarea tiinelor sau INTEGRONICA, Ed. tiinific i
Enciclopedic, Bucureti, 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 informaiei, n Inteligena artificial i robotic, Ed. Academiei R.S.R.,
Bucureti, 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 Mthode 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. *** Buyers Guide to Electronic Commerce. Glossary of Terms, www.wentworth.com.
126. *** Electronic Commerce. An Introduction, Student Manual, ZD University, 1999.
CAPITOLUL I ...................................................................................................................... 1
Sisteme informaionale economice ....................................................................................... 1
1.1 Evoluia sistemelor informaionale economice .......................................................... 2
1.2 Tipologia sistemelor informaionale ........................................................................... 4
1.3 Ciclul prelucrrii datelor ............................................................................................. 7
1.3.1 Faza de culegere a datelor .................................................................................... 9
1.3.2 Pregtirea datelor ............................................................................................... 11
1.3.3 Prelucrarea propriu-zis a datelor ...................................................................... 12
1.3.4 Faza de stocare a datelor i ntreinere a fiierelor ............................................ 15
1.3.5 Obinerea ieirilor .............................................................................................. 16
Rezumat ...................................................................................................................... 16
CAPITOLUL II ................................................................................................................... 18
Sisteme informaionale pentru conducere .......................................................................... 18
2.1 Sistemele de prelucrare a tranzaciilor...................................................................... 18
2.1.1 Caracteristicile sistemelor de prelucrare a tranzaciilor .................................... 19
2.1.2 Obiectivele sistemelor de prelucrare a tranzaciilor .......................................... 19
2.1.3 Funciile sistemelor de prelucrare a tranzaciilor .............................................. 21
2.1.4 Componentele sistemelor de prelucrare a tranzaciilor ..................................... 22
2.2 Sistemele de informare a conducerii......................................................................... 23
2.2.1 Caracteristicile sistemelor de informare a conducerii ....................................... 24
2.2.2 Obiectivele sistemelor de informare a conducerii ............................................. 25
2.2.3 Funciile sistemelor de informare a conducerii ................................................. 26
2.2.4 Componentele sistemelor de informare a conducerii ........................................ 28
Rezumat ...................................................................................................................... 29
CAPITOLUL III.................................................................................................................. 31
Introducere n dezvoltarea sistemelor informaionale ........................................................ 31
3.1 Ciclul de via al dezvoltrii sistemelor informaionale ........................................... 32
3.1.1 Modelul cascad ................................................................................................ 33
3.1.2 Modelul V .......................................................................................................... 34
3.1.3 Modelul incremental .......................................................................................... 35
3.2 Definirea metodologiilor, modelelor, tehnicilor i instrumentelor ........................... 37
3.3 Prezentarea general a etapelor ciclului de via al sistemelor informaionale ........ 39
3.4 Participanii la dezvoltarea sistemelor informaionale ............................................. 43
Rezumat ...................................................................................................................... 46
CAPITOLUL IV ................................................................................................................. 48
Microanaliza sistemelor informaionale ............................................................................. 48
4.1 Identificarea i selecia proiectelor de dezvoltare a sistemelor informaionale ........ 48
4.1.1 Potenialele proiecte de dezvoltare .................................................................... 49
4.1.2 Clasificarea, ierarhizarea i selecia proiectelor de dezvoltare .......................... 51
4.1.2 Planificarea sistemului informaional ................................................................ 53
4.3 Iniierea i planificarea proiectelor de dezvoltare a sistemelor ................................ 62
4.4 Analizele de fezabilitate ........................................................................................... 69
Rezumat ...................................................................................................................... 70
CAPITOLUL V .................................................................................................................. 73
Studierea sistemului existent i determinarea cerinelor noului sistem .............................. 73
5.1 Tipuri de proiecte de dezvoltare a sistemelor informaionale .................................. 75
5.2 Studierea sistemului existent .................................................................................... 75
5.2.1 Analiza informaiilor de ieire ........................................................................... 77
5.2.2 Analiza datelor de intrare................................................................................... 80
5.2.3 Analiza modului n care sunt stocate, accesate i pstrate datele ...................... 83
5.2.4 Analiza proceselor de prelucrare a datelor ........................................................ 84
5.3 Identificarea proceselor de prelucrare ale sistemului ............................................... 87
5.3.1 Tipuri de evenimente ......................................................................................... 87
5.3.2 Identificarea evenimentelor ............................................................................... 89
5.4 Determinarea cerinelor pentru noul sistem.............................................................. 93
5.4.1 Surse de identificare a cerinelor ....................................................................... 95
5.4.1.1 Utilizatorii sistemului ................................................................................. 95
5.4.1.2 Beneficiarii sistemului ................................................................................ 96
5.4.1.3 Personalul tehnic ......................................................................................... 96
5.4.2 Tipuri de cerine ................................................................................................. 97
5.4.2.1 Cerinele funcionale ................................................................................... 98
5.4.2.2 Cerinele nefuncionale ............................................................................... 99
5.4.2.3 Cerine privind managementul proiectului ............................................... 100
5.4.2.4 Cerine economice .................................................................................... 100
Rezumat .................................................................................................................... 101
CAPITOLUL VI ............................................................................................................... 104
Metode de culegere a cerinelor sistemului ...................................................................... 104
6.1 Intervievarea ........................................................................................................... 106
6.1.1 Tipuri i utilizri ale interviurilor .................................................................... 106
6.1.2 Paii intervievrii ............................................................................................. 107
Sfaturi finale pentru operatorii interviului ............................................................ 108
6.2 Chestionarele .......................................................................................................... 109
6.3 Intervievarea grupurilor .......................................................................................... 111
6.4 Observarea direct a utilizatorilor .......................................................................... 113
6.5 Analiza procedurilor de lucru i a altor documente ................................................ 115
Rezumat .................................................................................................................... 117
CAPITOLUL VII .............................................................................................................. 120
Modelarea logic, grafic, a proceselor de prelucrare ...................................................... 120
7.1 Introducere n modelarea sistemelor ....................................................................... 120
7.2 Descompunerea sistemului pe funcii de prelucrare ............................................... 124
7.3 Diagramele fluxurilor de date (DFD) ..................................................................... 127
7.3.1 Construirea diagramelor fluxurilor de date ..................................................... 130
7.3.2 Simboluri utilizate n construirea DFD............................................................ 132
7.3.2.1 Entitile externe (EE) .............................................................................. 132
7.3.2.2 Fluxuri de date .......................................................................................... 133
7.3.2.3 Locuri de stocare a datelor ........................................................................ 135
7.3.2.4 Procese de prelucrare ................................................................................ 136
7.3.2.5 Descrierea legturii dintre procesele de prelucrare i locurile de stocare 137
7.3.3 Descompunerea diagramelor fluxurilor de date .............................................. 139
7.3.3.1 Diagrama de context ................................................................................. 139
7.3.3.2 Diagrama fluxurilor de date de nivel 0 ..................................................... 141

7.3.3.3 DFD de nivel 1 pn la n .......................................................................... 142
7.3.3.4 Recomandri privind oprirea procesului de descompunere a sistemului . 146
7.3.4 Reguli de construire a diagramelor fluxurilor de date ..................................... 148
7.4 Depozitul metadatelor ............................................................................................. 153
7.4.1 Descrierea fluxurilor de date ........................................................................... 156
7.4.2 Descrierea structurii de date ............................................................................ 157
7.4.3 Descrierea datelor elementare.......................................................................... 159
7.4.4 Descrierea locurilor de stocare ........................................................................ 161
7.4.5 Descrierea proceselor....................................................................................... 163
Rezumat .................................................................................................................... 166
CAPITOLUL VIII............................................................................................................. 168
Modelarea conceptual a datelor (diagramele entitate-relaie, DER) .............................. 168
8.1 Aplicarea principiului abstractizrii n modelarea datelor ..................................... 168
8.2 Culegerea informaiilor pentru modelarea conceptual a datelor........................... 170
8.3 Introducere n cadrul conceptual al diagramelor entitate-relaie (DER) ................ 173
8.4 Coninutul i etapele activitii de modelare conceptual a datelor ....................... 174
8.4.1 Identificarea entitilor de date ........................................................................ 175
8.4.2 Descrierea entitilor de date prin intermediul atributelor .............................. 176
8.4.2.1 Atribute cu valori multiple........................................................................ 179
8.4.3 Identificarea i descrierea relaiilor dintre entiti ........................................... 180
8.4.3.1 Gradul relaiilor ........................................................................................ 180
8.4.3.2 Cardinalitatea relaiilor ............................................................................. 181
8.4.3.3 Rolul relaiilor........................................................................................... 183
8.4.3.4 Relaii purttoare de atribute (entiti asociative) .................................... 184
8.4.4 Modelul general al DER pentru sistemele informaionale .............................. 185
8.4.5 Alte situaii ntlnite n modelarea conceptual a datelor ............................... 189
8.4.5.1 Cardinalitatea relaiilor ternare ................................................................. 189
8.4.5.2 Relaii redundante ..................................................................................... 190
Rezumat .................................................................................................................... 191
Probleme ................................................................................................................... 192
CAPITOLUL IX ............................................................................................................... 193
Selectarea variantei strategice de proiectare a sistemelor informaionale ........................ 193
9.1 Aspecte generale privind raportul cerinelor sistemului i selectarea variantei
strategice de proiectare ......................................................................................................... 193
9.2 Procedura de selecie a celei mai bune variante strategice de proiectare ............... 195
9.3 Generarea variantelor strategice ale proiectului ..................................................... 196
1. Stabilirea minimului necesar de informaii solicitate de noul sistem ........... 197
2. Determinarea restriciilor din noul sistem .................................................... 197
9.3.1 Variantele de proiectare privind aria de ntindere i nivelul de informatizare 197
9.3.2 Formularea variantelor de implementare ......................................................... 202
9.3.2.1 Externalizarea serviciilor informaionale ................................................. 203
9.3.2.2 Surse ale softului....................................................................................... 203
Softul realizat cu fore proprii .......................................................................... 204
Soft realizat la comand .................................................................................... 204
Softul la cheie ................................................................................................... 204
Modificarea softului la cheie ............................................................................ 205
9.3.3 Selectarea furnizorilor ..................................................................................... 206
9.3.4 Selectarea hardului........................................................................................... 207

9.3.5 Formularea cererilor de ofert ......................................................................... 208
9.4 Selectarea strategiei de proiectare .......................................................................... 209
9.5 Coninutul planului de baz al proiectului .............................................................. 211
Rezumat .................................................................................................................... 212
Probleme ................................................................................................................... 213
Bibliografie general .................................................................................................... 214

Suport Curs ASI 2016 - Online

Încărcat de

Drepturi de autor:

Formate disponibile

Suport Curs ASI 2016 - Online

Î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

Suport Curs ASI 2016 - Online

Încărcat de

Drepturi de autor:

Formate disponibile

Dumitru Oprea

Gabriela Meni Florin Dumitriu

Contabilitate i informatic de gestiune, anul 3, ZI

Editura Universitii "Alexandru Ioan Cuza" din Iai

Probleme de echip ..................................................................................................... 78

8.4 Coninutul i etapele activitii de modelare conceptual a datelor ....................... 180

Sisteme informaionale economice

Altfel spus, datele stocate n sistemele informaionale descriu elementele patrimoniale

1.1 Evoluia sistemelor informaionale economice

Poate c n-am fi convingtori, dac n-am ncerca s lmurim lucrurile n continuare. n

apariia sistemelor de sprijinire a proceselor decizionale de grup (Group Decision Support

Sisteme de sprijinire a conducerii strategice

Sisteme de prelucrare a tranzaciilor

Fig. 1.1 Componentele mediului de lucru al sistemelor informaionale

1.2 Tipologia sistemelor informaionale

1) Dup scopul urmrit prin sistemul informaional:

sisteme informatice coordonate de componente informatice proprii (centre, staii, oficii

sisteme informaionale bazate pe instrumente diverse de automatizare a analizei i

1.3 Ciclul prelucrrii datelor

identificarea fiecrui eveniment sau activitate care a avut loc;

Reprezentarea tranzaciei de vnzare

Reprezentarea tranzaciei de plat a unui furnizor

Fig. 1.2 Informaiile despre activitile firmei pstrate de sistemul informaional

De exemplu, n cazul vnzrii de produse (eveniment) ar fi util s se culeag urmtoarele

att tranzaciile (evenimentele) interne, respectiv cele care au ca entiti/ actori

OBINEREA INFORMAIILOR DE IEIRE

Fig. 1.3 Ciclul prelucrrii datelor

1.3.1 Faza de culegere a datelor

Metodele de colectare a datelor pot fi grupate n directe (culegerea la surs) i indirecte

1.3.2 Pregtirea datelor

1.3.3 Prelucrarea propriu-zis a datelor

processing). Aceste dou metode privesc nu numai prelucrarea propriu-zis a datelor, ci i

Fig. 1.4 Prelucrarea datelor pe loturi

Fig. 1.4 Componentele necesare unui sistem pentru analize OLAP

2. Stair, R.M., Reynolds, G.W. op. cit., p. 211.

1.3.4 Faza de stocare a datelor i ntreinere a fiierelor

5. Oprea, D. op. cit., 1995, p. 55.

tranzacii vor fi prelucrate n vederea actualizrii fiierelor permanente. Un fiier este

1.3.5 Obinerea ieirilor

Sisteme informaionale pentru conducere

n cele ce urmeaz, vom descrie principalele sisteme informaionale, n deplin

2.1 Sistemele de prelucrare a tranzaciilor

2.1.1 Caracteristicile sistemelor de prelucrare a tranzaciilor

2.1.2 Obiectivele sistemelor de prelucrare a tranzaciilor

n condiiile prelucrrilor automate, o aplicaie privind calculul salariilor ar trebui s aib

2.1.3 Funciile sistemelor de prelucrare a tranzaciilor

2.1.4 Componentele sistemelor de prelucrare a tranzaciilor

2.2 Sistemele de informare a conducerii

Extranet Internet Intranetul

sprijinire a procesului decizional.

Date Sisteme de Date Sistemele de Rapoarte Informaii/

conducerii sunt caracterizate de urmtoarele trsturi:

Financiar Resurse Cercetare- Informatic

2.2.1 Caracteristicile sistemelor de informare a conducerii

activitile desfurate, urmnd ca decidenii s identifice cauzele care au generat problema i

Din punct de vedere al datelor utilizate i al informaiilor oferite, sistemele de informare a

repetitivitate informaiile se obin n mod periodic, cunoscndu-se aproape cu exactitate

2.2.2 Obiectivele sistemelor de informare a conducerii

oferind posibilitatea managerilor s acioneze pentru corectarea situaiilor i aducerea la starea