Sunteți pe pagina 1din 192

Cristian Georgescu

SISTEME INFORMATICE DE GESTIUNE


Sisteme informatice de gestiune

pagina 4
Sisteme informatice de gestiune

CUPRINS

1.Abordarea sistemica
1.1.-Sistem; noiuni generale
1.2.-Conceptul de analiz sistemic
2.Sisteme informaionale
2.1.-Comunicarea n sistemele informaionale
2.2.-Fluxuri de informaii
2.3.-Locul i rolul sistemului informaional
3.Sisteme informatice
3.1. -Definire
3.2. -Ciclul de via al unui sistem informatic
4.Metoda MERISE
4.1. Prezentare
4.2. Ciclul de via
4.2.1. Elaborarea temei de realizare a
sistemului informatic
4.2.2. Proiectarea logic
4.2.3. Proiectarea tehnic
4.2.4. Elaborarea programelor
4.2.5. Implementarea, exploatarea i
ntreinerea
4.3. Ciclul de abstractizare
4.3.1. -Modelul conceptual al datelor
4.3.2. Modelul logic al datelor
4.3.3. Modelul fizic al datelor
4.3.4. Modelul conceptual al comunicaiilor
4.3.5. Modelul conceptual al prelucrrilor
4.3.6. Modelul organizaional al prelucrrilor
4.3.7. Modelul operaional al prelucrrilor
4.4. Ciclul de decizie
5.Abordri orientate spre date i spre prelucrri
Bibliografie
pagina 5
Sisteme informatice de gestiune

1. ABORDAREA SISTEMIC

1.1. Sistem; noiuni generale

Conceptul de sistem apare n forme embrionare


n filosofia antic greac. Afirmnd c "ntregul este mai
mult dect suma pilor", Aristotel d o prim definiie
noiunii de sistem care se va dezvolta i va evolua timp
de peste 2000 de ani pentru a ajunge la forma actual
abia la nceputul secolului XX.
Cel care ncepe nchegarea unei teorii privind
sistemele este biologul german L. von Bertalanffy care
ntre 1928 i 1950 public o serie de lucrri ce
postuleaz c "universul este organizat n sisteme i
ansambluri de elemente aflate n interaciune" i care
reprezint nceputurile teoriei generale a sistemelor.
Economistul american E. Boulding pune bazele
teoriei sistemelor n 1956, teorie reluat i dezvoltat de
atunci de foarte muli cercettori.
Un sistem poate fi definit ca o seciune a realitii
n care se identific un ansamblu de fenomene, obiecte,
procese, fiine sau grupuri, interconectate printr-o
mulime de relaii reciproce, precum i cu mediul
nconjurtor i care acioneaz n comun n vederea
realizrii unor obiective bine definite.
Caracteristic pentru noiunea de sistem este
posibilitatea ca ansamblul de elemente componente ale
sistemului s poata fi divizat n subsisteme.
Structurarea sistemului n subsisteme se face
dup reguli stabilite n funcie de scopul urmrit.

pagina 6
Sisteme informatice de gestiune

Mulimea relaiilor dintre componentele unui


sistem precum i relaiile ntre componente i ansamblu
formeaz structura sistemului, iar mulimea
caracteristicilor unui sistem, la un moment dat,
determin starea sa.
Relaiile dintre elemente se analizeaz observnd
i studiind logic funciile i mecanismele lor individuale.
Dup precizarea acestor funcii i mecanisme, orice
soluie avut n vedere poate fi evaluat pentru ntregul
sistem, tinnd seama de diverse criterii de eficien i de
restriciile practice asociate elementelor funcionale.
Elementele unui sistem pot avea relaii ntre ele
(relaii endogene) ct i relaii cu mediul nconjurtor
(relaii exogene).
Ca urmare, pentru a caracteriza noiunea de
sistem este necesar s punem n eviden urmtoarele 5
laturi:
mulimea elementelor
relaiile ntre elemente -relaii endogene
intrrile i ieirile n i din sistem-relaii exogene
caracterul variabil n timp al elementelor sistemului
scopul, finalitatea sistemului
Pentru descrierea unui sistem i a evoluiei sale se
asociaz "starea sistemului" care este un ir de variabile,
un vector ale crui componente variabile n timp permit
cunoaterea sistemului n orice moment.
Folosind vectorul de stare al sistemului, i vectorii
de intrare, ieire, comand etc. se poate asocia
sistemului un sistem de ecuaii de stare care permit
studiul i sinteza unor clase de sisteme.
Pentru analiza comportamentului sistemelor, n
ansamblul lor, s-a propus conceptul de "cutie neagr"
care reprezint sistemul ca un tot, fcnd abstracie de
procesele sale interne.

pagina 7
Sisteme informatice de gestiune

Cutia neagr primete impulsuri din mediul


nconjurtor (intrrile) i le transform n aciuni asupra
mediului (ieirile).
Mecanismul transformrii intrrilor n ieiri poate
fi descris cu ajutorul unor funcii care au diverse forme
particulare, n funcie de natura sistemului.
Sistemul devine "cibernetic" atunci cnd apare
reglarea (conexiunea invers sau feedback-ul).
n 1948 matematicianul american Norbert Wiener
prin publicarea lucrrii sale fundamentale "Cybernetics",
pune bazele acestei tiinte a controlului i comunicrii.

Figura 1.1. Sistem cibernetic

Fie sistemul S definit prin vectorul intrrilor X i


prin vectorul ieirilor Y; transformarea intrrilor n ieiri
se poate descrie n mod simplificat prin aplicarea
operatorului liniar F.

Y=FX

Mrimile Y ale ieirilor se compar cu vectorul


obiectivelor propuse Z i ntruct de cele mai multe ori
apar abateri (Y#Z) este necesar intervenia unui
pagina 8
Sisteme informatice de gestiune

"regulator" R care va genera mrimea de reglare x, cu


rolul de a aduce ieirile la nivelul obiectivelor stabilite
ceea ce se poate scrie:

Z = F ( X + x)

Sistemele cibernetice constituie o clas important de


sisteme. Sistemele economice sunt structurate, de
obicei, ca dou subsisteme "subsistemul condus" i
"subsistemul conductor". Traducnd n termenii
prezentai anterior, subsistemul condus este sistemul S
iar subsistemul conductor este regulatorul R. Dat fiind
proprietatea sistemelor de a putea fi mprite n
subsisteme care la rndul lor se pot diviza n alte
subsisteme s.a.m.d., n continuare se va folosi noiunea
de subsistem numai n cazurile cnd este necesar
punerea n eviden a relaiei de incluziune ntr-un alt
sistem.
Din punct de vedere al modului cum se
analizeaz ieirile (reaciile) sistemului condus i al
modului cum se genereaz mrimile de reglare
(deciziile) sistemele pot fi:

Sistem deschis necontrolat.

Figura 1.2. Sistem deschis necontrolat.


pagina 9
Sisteme informatice de gestiune

n acest tip de sistem sistemul conductor emite o


decizie D far a cunoate reacia sistemului condus la
aceast decizie.
Sistem nchis controlat.

Figura 1.3. Sistem nchis controlat

n acest caz n urma deciziei D a sistemului


conductor, sistemul condus furnizeaz informaia I ca o
reacie la decizia D.

Sistem controlat autoreglabil univariant.

Figura 1.4. Sistem controlat autoreglabil univariant.


pagina 10
Sisteme informatice de gestiune

Sistemul controlat apare atunci cnd ntre forma


primar a deciziei D preconizat de sistemul conductor
i forma realizat de sistemul condus nu este o
concordan perfect.
n acest caz conductorul lund n considerare
diferenele ntre ce s-a preconizat i ce s-a realizat
intervine cu noi decizii pentru a determina sistemului
condus s se conformeze deciziei iniiale D.

Sistem controlat autoreglabil bivariant.

Figura 1.5. Sistem controlat autoreglabil bivariant

Dac n urma unor perturbaii conductorul


reevalueaz decizia sa primar poate s preconizeze o
form modificat a obiectivului iniial. Sistemul este
bivariant pentru c pe parcursul realizrii deciziei att
forma iniial ct i cea final s-au modificat.

pagina 11
Sisteme informatice de gestiune

1.2. Conceptul de analiza sistemic

inndu-se cont de complexitatea deosebit a


celor mai multe sisteme existente n natur, economie,
etc., studierea sistemelor se face ntr-o manier aparte
numit abordare sistemic.
Abordarea cartezian const n a repera i a izola
fiecare subproblem pentru o prelucrare ulterioar. Prin
aceasta nu se va putea rezolva ns ansamblul
problemei. Abordarea sistemic propune o viziune unic
i global a problemei de rezolvat.
n loc de a se ncepe analiza prin divizarea
sistemului n componente din ce n ce mai mici i mai
uor de stpnit, toate componentele sunt considerate
n ansamblul lor ("aspect spaial") att pe parcursul
analizei, proiectrii ct i al procesului de conducere
("aspect temporal").
De fapt, numai n acest fel este posibil s se
neleag i s se anticipeze corect comportarea posibil
a sistemului.
O caracteristic esenial a abordrii sistemice
este accentul pe care l pune, n cazul analizei, pe
interdependenele dintre elementele sistemului i pe
observarea critic a calitii acestora.
Abordarea sistemic, s-a dovedit de mare utilitate
n rezolvarea problemelor mari i complexe, referitoare
la oameni i maini. Abordarea sistemica este o noiune
care reunete trei activiti importante:
analiza sistemelor
proiectarea (ingineria) sistemelor
conducerea sistemelor.
Analiza de sistem poate fi considerat un mijloc
de abordare a cercetrii, sau chiar disciplin n sine,
deoarece acest concept a nceput s fie folosit pe scar
larg n mai toate domeniile.

pagina 12
Sisteme informatice de gestiune

Analiza sistemelor presupune parcurgerea urmtoarelor


etape:
1.Prima etap const n formularea problemei. Pentru
toate lucrrile ulterioare este important ca
analistul s examineze critic formularea problemei
de ctre utilizator. Este bine s se aib n vedere
c la acest prim contact ntre analist i utilizator
pot apare probleme de comunicare ntre cei doi,
datorate unor incompatibiliti de limbaj. Orice
eroare minor n formularea problemei sau orice
nelegere eronat poate genera mari inconveniente
prin amplificarea ei cu fiecare etap parcurs.

2.De asemenea este deosebit de important s se


examineze minuios formularea obiectivelor pentru
c n acest domeniu sunt posibile inconsecvente:
"s se maximizeze eficiena concomitent cu
ncadrarea n cheltuielile minime".

3.Adeseori n optimizarea sistemelor apar dificulti


cauzate de faptul c este greu sau chiar imposibil
s se analizeze ntreaga problem. Se poate
recurge n astfel de situaii la optimizarea fiecrui
subsistem analizat, dar sistemul n ntregul su nu
poate fi dect suboptimal fiind necesar deci
precizarea clar a limitelor problemei.

4.Analiza cerinelor utilizatorului const n


identificarea i evaluarea necesitilor lui reale.

5.Precizarea criteriilor de msurare a eficienei


sistemului trebuie fcut nainte de evaluarea
soluiilor propuse prin stabilirea unui grup de
mrimi reprezentative.

pagina 13
Sisteme informatice de gestiune

6.Analiza funcional se concretizeaz ntr-o list


amnunit a funciunilor i aprecierilor care
trebuie ndeplinite. La analizele funcionale o
deosebit importan o are reprezentarea grafic n
scheme bloc.

7.Pe masur ce se completeaz lista restriciilor care


acioneaz asupra sistemului devine posibil
cercetarea efectelor interaciuni lor asupra
ntregului sistem. Identificarea restriciilor i
evaluarea efectului lor asupra eficienei sistemului
reprezint un alt aspect important.

8.Pe msura avansrii n analiza sistemului se


contureaz diferitele soluii posibile care satisfac
restriciile impuse. Obiectivul acestei faze este de
a identifica diversele variante fr a adncii
analizele privind cheltuielile pe care le implic.
ntr-un sistem informatic, de exemplu, este
necesar s se determine gradul n care hardware-
ul i software-ul avute n vedere ofer posibiliti
de dezvoltare ulterioar.
9.Dup precizarea variantelor posibile se trece la
compararea i evaluarea acestora. Este de dorit ca
att cheltuielile ct i eficiena s fie exprimate
banete.

Proiectarea sistemelor este un proces de


concepie tehnic, asociat de obicei cu dezvoltarea sau
cu modificarea important a unui sistem.
Acest proces se mparte n:
proiectarea propriuzis a sistemelor i
proiectarea operrii sistemelor

pagina 14
Sisteme informatice de gestiune

Proiectarea propriuzis a sistemelor se mparte la rndul


ei n:
proiectarea preliminar
proiectarea de detaliu

La proiectarea preliminar se evalueaz soluiile


de proiectare a transpunerii specificaiilor funcionale
precizate n faza de analiz a sistemului i apoi se
selecteaz soluia de proiectare.
Proiectarea de detaliu cuprinde transpunerea
concepiei de proiectare, conturat n faza de proiectare
preliminar n specificaii de detaliu. Este necesar n
aceast faz mprirea lucrrilor pe echipe dar totodat
trebuie s existe un grup de integrare a sistemului care
s se ocupe exclusiv de problema asigurrii
funcionalitii corespunztoare a fiecrui subsitem nu
numai n parte ci i n cadrul sistemului n ansamblu.

Un aspect oarecum neglijat n tehnica sistemelor


este proiectarea operrii lor. Adeseori se consider c
proiectarea s-a terminat odat cu momentul n care
sistemul este livrat beneficiarului. Un astfel de punct de
vedere poate contribui la eecul unui sistem tot att de
mult ca i proiectarea lui defectuoas. Operarea
sistemelor este uneori neglijat din cauz c proiectanii
sunt n mod firesc mai interesai s soluioneze
problemele tehnice ale proiectrii i n mai mic masur
problemele legate de limitele fizice i psihice ale
personalului operaional i de ntreinere. n plus
concepia de a adapta omul la main a creat obiceiul
de a angaja pentru operare i ntreinere acei oameni
ale cror nsusiri fizice i psihice pot fi considerate
compatibile cu caracteristicile echipamentului. Pe
msura sporirii complexitii sistemelor, trebuie

pagina 15
Sisteme informatice de gestiune

acordat o atenie deosebit noiunilor de fiabilitate i


mentenabilitate.

Conducerea sistemelor cuprinde stabilirea metodologiei


i a structurilor organizatorice pentru planificarea,
directivarea i controlul activitilor de proiectare a
sistemelor ca i pentru funcionarea lor. Conducerea
funcionarii sistemelor se numete "conducere
operaional".
Pe de alt parte exist conducerea nsi a proiectrii
sau dezvoltrii sistemului.
Conducerea sistemelor nu reprezint o faz a
proiectrii sistemelor ci este funciunea de comand i
control care se desfoar de-a lungul ciclului de via
al sistemului. Cea mai mare contribuie la eficiena
conducerii unui sistem o are identificarea momentelor i
criteriilor de efectuare a controlului, astfel nct s se
poat stpnii desfurarea activitilor. Pe lng
controlul corespunztor principalelor etape conducerea
trebuie s efectueze o permanent urmrire i
coordonare. Acest sistem de control poate fi mai eficient
dac:
se realizeaz previziuni asupra evoluiilor viitoare;
se planific reexaminri periodice ale proiectelor.
Integrarea sistemului i controlul configuraiei sunt
dou activiti de conducere care trebuie s-i
dovedeasc prezena pe parcursul fiecrei faze a
proiectrii sistemelor. Pentru integrarea sistemului
conducerea trebuie s asigure compatibilitatea
mecanic, electric, etc. dar i compatibilitatea
informaional.
Controlul configuraiei const din metodele
folosite pentru a orienta i urmrii modificrile n
diversele etape ale ciclului de via al sistemului.

pagina 16
Sisteme informatice de gestiune

Am enumerat mai sus o serie de etape i de


probleme pe care trebuie s le urmeze i s le rezolve
analistul de sistem. Analiza de sistem nseamn
cunoaterea sistemului, cunoatere care se traduce
printr-o reprezentare la nivel cerebral a sistemului n
ansamblul su. De fapt prin analiza s-a transpus
realitatea mai nti ntr-un model cerebral pe care
analistul l va transforma i l va prezenta sub forma
unui model matematic, grafic, etc..
Aceast activitate de percepere i reprezentare a
realitii nu este deloc uoara i presupune n mod
obligatoriu participarea activ a beneficiarului
sistemului.

pagina 17
Sisteme informatice de gestiune

2. SISTEME INFORMAIONALE

2.1. Comunicarea n sistemele informaionale

Noiunea de informaie este complex i de mare


generailitate. La momentul apariiei sale, conceptul de
informaie a suscitat dispute filosofice pe tema
caracterului material al acesteia. Norbert Winer spunea:
" Informaia este informaie, nu este materie sau
energie."
Informaia este un tip deosebit de raport ntre
procesele materiale, raport ce nu exist n afara acestor
procese. Se poate afirma c informaia reprezint un
atribut fundamental al materiei alturi de mas, cmp i
substan. Informaia ca atribut fundamental al materiei
este prezent att n materia vie (informaia genetic)
ct i n cea nevie .
Pentru determinarea riguroas a cantitii de
informaie se folosete un aparat matematic bazat pe
elemente din teoria probabilitilor.
Fie un experiment X rezultatele sale pun n
eviden un numr finit de evenimente elementare
independente x1,x2,..,xn, avnd asociate probabilitile
de realizare p1,p2,...,pn. Presupunem c experimentul X
reprezint un sistem complet de evenimente, adic prin
efectuarea sa se va obine cu siguran unul din
evenimentele xk X , deci pk = 1 ; k=1,..,n. Realizarea
unui eveniment nltur o cantitate de nedeterminare,
deci ntruct informaia reprezint o nedeterminare
nlturat sensul variaiei nedeterminrii este inversul

pagina 18
Sisteme informatice de gestiune

sensului variaiei informaiei, unitatea de msur fiind


aceiai.
Notnd cu H(X) msura gradului de nedeterminare,
care este egal cu cantitatea medie de informaie
furnizat de realizarea unui eveniment se poate scrie:

H(X) = H(p1,p2,...,pn)

n anul 1948 Claude Shannon n lucrarea "Teoria


matematica a comunicaiei" a dat expresia cantitii de
nedeterminare (i deci a informaiei):

Shannon a preluat cercetrile unui precursor al


su n domeniul teoriei informaiei R.V.Hartley care nc
din anul 1928 a introdus noiunea de cantitate de
informaie, definind-o astfel:"Informaia obinut prin
precizarea unei variante din cele n echiprobabile este
egal cu logaritmul lui n n baza 2".

I = log2 n = -log2 p

unde p=1/n reprezint probabilitatea de realizare a unei


variante. Relaia stabilit de Hartley se obine ca un caz
particular din formula lui Shannon atunci cnd
evenimentele sunt echiprobabile;

p1 = p2 =....= pn = p= 1/n

Msura informaiei calculat cu formula lui Shannon se

pagina 19
Sisteme informatice de gestiune

numete i ENTROPIE INFORMAIONAL prin analogie cu


entropia termodinamic, care masoar de asemenea
gradul de nedeterminare al unui fenomen.

Transferul informaiilor, deciziilor, datelor i


cerinelor ntre diferite procese i/sau ntre diferite
sisteme sau subsisteme creeaz o problematic
complementar cantitii de informaie: problema
COMUNICARII.

Fie:

Figura 2.1. Modelul comunicrii

unde:
E - este emitorul de informaie
R - este receptorul de informaie
C - este canalul de comunicaie
Caracterul esenial al procesului de comunicare este
reprezentat de mesaj i aceast cantitate care
caracterizeaz mesajul - definit ca o secven de semne
elementare - este legat de lungimea sa, de
dimensiunile n spaiu i timp ale suportului su, sau ale
canalului de transfer (lungimea cuvntului, suprafaa
unui disc, a unui tablou, numrul de semne imprimate),
dar mai ales de improbabilitatea ocurenei (apariiei)
sale, adic de combinaia pe care o realizeaz. Aceast
cantitate de noutate sau originalitate transportat de la
E la R se adaug la sistemul de cunotine i de

pagina 20
Sisteme informatice de gestiune

experien pe care l au att E ct i R i se nscrie n


memoria lor.
Semnele exist nainte de crearea mesajului sau a actului
de comunicare. Este vorba aici de a constitui un
repertoriu, de a le clasa ntr-o ordine n funcie de
frecvena de ntrebuinare; n pasul urmtor vom
deduce probabilitatea lor de apariie (de ocuren) i, n
consecin, informaia pe care ele o transport.
Informaia depinde deci de repertoriul comun att
al transmitorului ct i al receptorului. Aceast masur
presupune faptul c mesajul este decompozabil n mod
obiectiv ntr-o serie de semne identificabile i
enunabile.
Procesul fundamental al comunicrii ntre
emitor i receptor prin intermediul unui canal fizic
nseamn:

a gsi semne care pot fi recunoscute ntr-un


repertoriu prin intermediul unui canal fizic;
a gsi semne care pot fi recunoscute ntr-un
repertoriu deinut de emitor;
a le aduce i ale transmite prin ceea ce numim un
canal de comunicaie;
identificarea de ctre receptor a fiecrui semn pe
care l primete cu cele pe care le are deja n propriul
su repertoriu.

Comunicarea ideilor nu are loc dect n msur n care


cele dou repertorii au o parte comun. Pe msur ce
acest proces continu n procesele dotate cu memorie i
cu estimare statistic, cum este cazul inteligenei
umane, percepia semnelor mereu identice vine s
modifice din ce n ce mai mult n repertoriul
receptorului, cruia i este subordonat. Este vorba de
sistemul de nvare.

pagina 21
Sisteme informatice de gestiune

n comunicare emitorul creeaz o form, o


imagine, o idee, pe care o codific apoi n momentul
emisiei. La rndul su, receptorul, plecnd de la mesaj
construiete o alt form. Calitatea comunicrii se
msoar prin indentitatea dintre forma perceput i
forma creat.
Leibnitz a artat c orice mesaj poate fi
considerat o alegere ntre o mulime de cazuri posibile,
alegere care se poate transforma ntr-un numr suficient
de mare de dileme succesive. Fiecare dintre aceste
alternative, fiecare din aceste alegeri ntre dou
posibiliti care se exclud (da-nu; 0-1), dac ele sunt
egal probabile pentru receptor, reprezint o unitate de
informaie sau BIT (binary digit: cifr binar sau
problem binar). Avem astfel o unitate de msur a
informaiei ncepnd cu numrul de dileme susceptibile
a defini mesajul far ambiguitate.
Receptorul uman nu este capabil s sesizeze
dect o cantitate limitat de originalitate pe unitatea de
timp, adic un anume debit de informaie, funcie de
canalul de percepie (vz auz, pipit, telepatie, etc.)
Caracterul optim al mesajelor nu este dat de
maximul de informie ci de maximul de impact adic de
probabilitatea de a nelege, deci de a proiecta forme
asupra mesajului primit.
E necesar aici un exces, o risip de semne, i
apare o alt mrime numeric, legat de mesaj, care
joac un rol important n comunicaie: REDUNDANA.
Ea nseamna excesul relativ al numrului de
semne fa de cel care ar fi fost strict necesar pentru a
transmite aceiai cantitate de originalitate.

pagina 22
Sisteme informatice de gestiune

Figura 2.2. Alegerea optimului de redundan

Orice mesaj poate fi caracterizat prin coninutul


su de informaie i poate s se situeze ntr-un punct
definit al unei scri care merge de la banalitatea total
pn la originalitatea total.
Redundana variaz deci n raport invers
proporional cu informaia. Inteligibilitatea unui mesaj
este legat de redundana sa. Ea reprezint maximul
pentru un mesaj total banal i este nul pentru un mesaj
perfect original.
Valoarea mesajului se traduce atunci prin diferite
rate de redundan, (Figura 2.2.) care prezint un maxim
n funcie de caracteristicile receptorului.

Fie:
pagina 23
Sisteme informatice de gestiune

Figura 2.3. Comunicarea n prezena perturbaiei

unde:
E - este emitorul de informaie
R - este receptorul de informaie
C - este canalul de comunicaie
P - este perturbaia

Modelul matematic al unui sistem de transmitere


a informaiei este format din dou mulimi finite X, Y i
o probabilitate condiionat p(y|x), definit pe Y pentru
orice x X. X este mulimea simbolurilor care se emit iar
Y mulimea simbolurilor ce se recepioneaz.
Probabilitatea p(y|x) se numete probabilitatea de
recepie condiionat de ceea ce se emite i
caracterizez perturbaia existent pe canalul
sistemnului respectiv. A cunoate canalul de
comunicaie nseamn a cunoate probabilitile p(y|x)
pentru toate simbolurile x X i y Y.
Mrimea H(X|Y) reprezint cantitatea medie de
informaie necesar pentru a se recepiona mulimea Y
i depinde de probabilitatea condiionat p(x|y), care la
rndul ei, este determinat de probabilitatea p(y|x) ce
caracterizeaz perturbaia pe canal.
Nedeterminarea H(X|Y) apare datorit
perturbaiei; ea este preul pe care trebuie s-l pltim
pagina 24
Sisteme informatice de gestiune

perturbaiei pentru ca s putem recepiona semnalele y


Y.
Dac H(X|Y) reprezint cantitatea medie de
informaie care se pierde pe canal i dac de la sursa se
transmite o cantitate de informatie H(X), la recepie va
ajunge numai cantitatea de informatie

Q=H(X) - H(X|Y)

Mrimea denumit CAPACITATEA CANALULUI este


dat de relaia:

C = MAX (H(X) - H(X|Y))

si ea pune n eviden cantitatea de informaie care


poate s circule n mod util prin canalul dat.
Diferena H(X) - H(X|Y) raportat la uinitatea de timp se
mai numete vitez de transmitere a informaiei.
Capacitatea canalului este deci viteza maxim de
transmitere a informaie pe canalul respectiv.

pagina 25
Sisteme informatice de gestiune

2.2. Fluxuri de informaii

Fie graful G0(X,L) unde:


X este mulimea elementelor i
L este legea de coresponden (mulimea de perechi de
puncte distincte din X);
Un punct xi din X este numit NOD.
O pereche de puncte xi,xj este numit LATURA sau
ARC.
Mulimea punctelor { x1,x2,...,xl } din mulimea X
desemneaz un DRUM de lungime L dac perechile
{ xi,xi+1 } sunt laturi;
Distana ntre dou puncte ale unui graf este egal cu
lungimea cii celei mai scurte dintre ele.
Pe acest graf G0(X,L) se definete un alt graf numit GRAF
INFORMAIONAL G1(X,C).
ntre cele dou grafuri exist o deosebire: legea de
coresponden. n timp ce G0 reglementeaz relaiile
organizatorice G1 reglementez relaiile informaionale.
Laturile grafului G1 se numesc CANALE
INFORMAIONALE. n mulimea {C} a canalelor
informaionale se pot defini dou submulimi:

C1={c C|c=canal pur informaional}


C2={c C|c=canal decizional}

Pe mulimea {C} putem defini mulimea {F} a fluxurilor.


Fluxul este acea cantitate de informaie care circul pe
un canal. El poate fi:
informaional
decizional
DRUM INFORMAIONAL este succesiunea de arce
adiacente ce permit trecerea fluxului informaional de la
un nod la altul.

pagina 26
Sisteme informatice de gestiune

LUNGIMEA UNUI DRUM INFORMAIONAL este dat de


numrul de arce din care este format. Drumul poat fi:

deschis (numai informaional)


nchis (informaional - decizional)

Tipuri de fluxuri informaionale. Fie un flux F(A,B) unde


A i B sunt noduri iar fluxul F circul pe canalul AB:

cnd informaia circul de la un nivel organizatoric A


inferior la un nivel superior B, fluxul se numete
ascendent.
cnd informaia circul de la A la B i ele sunt pe
acelai nivel organizatoric, fluxul se numete
orizontal.
cnd informaia circul de la A situat la un nivel
organizatoric superior la B aflat pe un nivel
organizatoric inferior, fluxul se numete descendent.
cnd A i B aparin aceluiai sistem S, fluxul F(A,B)
se numete intern.
cnd A sau B nu aparin sistemului S fluxul se
numete extern.
cnd coninutul, direcia i periodicitatea fluxului
sunt prestabilite, fluxul se numete periodic.
cnd nici coninutul nici periodicitatea nu sunt
reglementate, fluxul se numete de moment sau
ntmpltor.

pagina 27
Sisteme informatice de gestiune

2.3. Locul i rolul sistemului informaional

Circulaia informaiei din momentul producerii


unui eveniment n procesul condus i pn cnd pe baza
cunoaterii lui, se declaneaz un nou eveniment
precum i precizarea coninutului informaiei,
destinaiei, locului stocrii, etc. alctuiesc sistemul
informaional.
Totalitatea metodelor, tehnicilor, mijloacelor,
privite ca ansamblu integrat care asigur nregistrarea,
culegerea, transmiterea, prelucrarea i valorificarea
informaiilor de orice natur definesc sistemul
informaional.
Un sistem informaional se creaz i se dezvolt
odat cu organismul sau activitatea pe care o reflect.
ntr-un sistem economic sistemul informaional
asigur legtura n ambele sensuri ntre sistemul condus
sau de execuie i sistemul conductor sau decizional
(Figura 2.4.).
Orice sistem economic presupune existena unei
componente operaionale care poate fi orice sistem de
producie de bunuri sau servicii.
Sistemul condus asigur desfurarea activitilor
specifice sistemului n vederea realizrii obiectivului
global pentru care a fost creat.
Sistemul condus se compune din ansamblul
actorilor operaionali din ntreprindere i care:

utilizeaz informaiile prezente n sistemul


informaional;
utilizeaz regulile de comportament din sistemul
informaional.

pagina 28
Sisteme informatice de gestiune

Figura 2.4. Locul sistemului infirmaional

Spre exemplu un vnztor dintr-o societate care


se ocup cu vnzri prin coresponden, primete o
comand telefonic de la un client nou. Sistemul
informaional este acela care:
i furnizeaz informaia c este vorba de un client
nou;
i furnizeaz regula de aciune care se traduce prin
aplicarea unui comision de 10% asupra vnzrilor.
Astfel sistemul operaional adaug o nou
informaie n sistemul informaional (numele clientului,
adresa clientului, etc).
Sistemul conductor asigur previziunea
comanda, organizarea, coordonarea i controlul
desfurrii activitilor n vederea ndeplinirii
obiectivelor sistemului.

pagina 29
Sisteme informatice de gestiune

El este compus din ansamblul actorilor care


fixeaz i adapteaz obiectivele i strategia
ntreprinderii utiliznd informaiile prezente n sistemul
informaional. Sistemul conductor intervine asupra
sistemul informaional n sensul adaptrii la obiectivele
i la strategia ntreprinderii, modificnd natura
informaiilor i regulile de comportament.
Spre exemplu conducerea unei bnci decide ca
clienii si s nu mai fie considerai ca persoane ci ca
gospodrii (familii) ceea ce duce la schimbarea naturii
informaiei.
O societate decide s schimbe modul de facturare
prin editarea facturii pe calculator n momentul
prezentrii clientului. Rezult de aici o aciune asupra
regulilor de comportament, facturarea actualiznd stocul
fr a mai fi nevoie de o procedur ulterioar.
Prin situarea sa ntre sistemul conductor i
sistemul operaional sistemului informaional asigur
urmtoarele funciuni:
culegerea datelor care consemneaz realitatea
economic din cadrul proceselor operaionale.
preluarea informaiilor de la alte sisteme i mpreun
cu cele din sistemul operaional s asigure
prelucrarea, valorificarea i arhivarea lor.
obinerea i transmiterea ctre conducerea proprie i
ctre organele supraordonate a informaiilor
necesare fundamentrii deciziilor sau a urmririi
efectelor acestora.
transmiterea de informaii de rutina altor procese
informaionale.
preluarea i transmiterea fr modificri a deciziilor
care provin de la organele supraordonate ctre
procesul decizional propriu.

pagina 30
Sisteme informatice de gestiune

Figura 2.5. Sistemul informaional

Avnd n vedere caracterul dinamic al sistemului


economic, n mod obiectiv i sistemul informaional
trebuie s fie ntr-o continu adaptare i perfecionare.
Elemente ale sistemului economic pot reprezenta
perturbaii pentru sistemul informaional dar acesta fiind
un sistem cibernetic exist posibilitatea adaptrii i
funcionrii celor dou sisteme n concordan.
n sistemul informaional privit ca sistem
cibernetic conexiunea invers o constituie :
deciziile pentru meninerea echilibrului sistemului
economic n ansamblu;
deciziile luate de conducerea subsistemului
informaional pentru buna funcionare i
perfecionare a acestuia.
Reacia invers se concretizeaz prin informaia
economic necesar conducerii sistemului economic att
pentru fundamentarea deciziilor ct i pentru urmrirea
efectelor acestora.
pagina 31
Sisteme informatice de gestiune

Sistemul informaional are caracter cibernetic i


datorit faptului c are capacitatea de autoreglare astfel
nct el este ntotdeauna n concordan cu sistemul
economic pe care l reflecta.

Figura 2.6. Sistemul informaional; sistem cibernetic

Funciile de previziune, organizare, coordonare i


control, atribute ale sistemului conductor, devin n
societatea modern din ce n ce mai complicate. Din
aceast cauz n procesul de conducere apare
pagina 32
Sisteme informatice de gestiune

necesitatea unor metode care s permit stpnirea


fluxurilor informaionale din i spre sistemul condus, i
care s permit conducerii sesizarea problemelor ce pot
s apar n viitor.
ntreprinderea este pus n situaia de a prelucra
toate aceste fluxuri informaionale i de a-i alege
propria cale din mult mai multe variante pe care le are la
dispoziie.
Aceste posibiliti complexe de aciune se traduc
printr-un nivel mai mare al fluxurilor informaionale
care intr i ies din ntreprindere, fluxuri care trebuie
analizate i controlate de conducerea ntreprinderii.
Deciziile elaborate trebuie s stea la baza conturrii mai
multor variante de evoluie care s cuprind simultan
criterii de timp, bneti i de performan.
Apare n acest caz o situaie potenial de risc,
generat mai ales de imposibilitatea de a controla noul
val de complexitate.

pagina 33
Sisteme informatice de gestiune

3. SISTEME INFORMATICE

3.1. Definire

Din definiia sistemului informaional reiese c


obiectivul global urmrit este tratarea i valorificarea
informaiei la toate nivelele sistemului n care se creaz
i se dezvolt.
Metodele, mijloacele i tehnicile utilizate n
realizarea obiectivului caracterizeaz modul de
prelucrare a datelor. Putem avea o prelucrare manual,
automat sau interactiv.
Dei la nceput calculatorele electronice erau
folosite n exclusivitate pentru calcule tehnico-tiintifice,
ncepnd cu cel de-al aptelea deceniu al secolului
nostru, acestea sunt utilizate pe o scar tot mai larg
pentru prelucrarea automat a datelor referitoare la
procesele i fenomenele economice, la rezolvarea pe
cale automat a unor probleme generate n procesul
decizional.
Prelucrarea automat a datelor a aprut odat cu
utilizarea calculatoarelor electronice n realizarea
proceselor informaionale.
Pentru definirea sistemului informatic prezentm
un set de trei definiii unanim acceptate, dar care pun
accentul pe una sau alta dintre trsturi, completndu-
se reciproc.

Atunci cnd n sistemul informaional predomin


utilizarea calculatoarelor electronice, se spune c el
este un sistem informatic.

pagina 34
Sisteme informatice de gestiune

Un sistem informatic poate fi definit ca un ansamblu


tehnico-organizatoric de automatizare a culegerii i
prelucrrii informaiilor destinate desfurrii
procesului de conducere, n scopul asigurrii unei
eficiene ct mai mari a activitii economico-sociale
respective.

Partea component a sistemului informaional prin


care se asigur, pe baza folosirii tehnicii de calcul i
n primul rnd a calculatoarelor electronice, tratarea
raional a datelor i a informaiei, cu eficien
sporit, constituie un sistem informatic.

n timp ce prima definiie pune accentul pe


aspectul tehnic, adic pe utilizarea calculatoarelor, cea
de-a doua vizeaz aspectul de organizare i
raionalizare a circuitului informaiilor destinate
conducerii.
Ultima definiie este cea care reunete cele dou
aspecte subliniate de primele definiii adugnd i
relaia de incluziune a sistemului informatic n sistemul
informaional.
Sistemul informatic se asociaz obligatoriu unui
sistem informaional i este subordonat unui proces
decizional. Prin tratarea datelor cu tehnica de calcul
sunt eliminate erorile de informare care se
repercuteaz negativ asupra calitii desfurrii
activitilor.
Sistemul informatic, ca parte a sistemului
informaional, trebuie structurat ca sistem cibernetic cu
dou bucle de reglaj. Bucla principal de reglaj reflect
principalele influene cu mediul nconjurtor: legturile
cu bncile, cu beneficiarii, etc. Bucla secundar este ca
o bucl de autoreglaj care face fa n principal

pagina 35
Sisteme informatice de gestiune

perturbaiilor interne din sistem. Structura cibernetic cu


dou bucle de reglaj a sistemului informatic este
necesar i suficient pentru ca sistemul s poat fi
folosit ca instrument al conducerii.
n condiiile unei orientri a activitii spre pia,
strategia ntreprinderii poate suferi modificri
substaniale, n funcie de situaiile conjuncturale
aprute. Dac, n urma unor perturbaii de acest fel,
conductorul reevalueaz decizia sa primar (planul
iniial), poate s preconizeze o form modificat a
obiectivului iniial. n acest caz, cnd pe parcursul
realizrii deciziei, att forma iniial ct i cea final s-
au modificat, putem vorbi despre sistemul informatic ca
despre un sistem bivariant.
Sistemul informatic este format, n esen, din
urmtoarele categorii de elemente:

1. calculatoare electronice i alte echipamente


2. metode i tehnici de tratare a datelor i a informaiei
3. colecii organizate de date
4. proceduri i programe de tratare a datelor
5. cadre de specialitate

n cadrul sistemelor informatice, calculatorul


electronic devine un factor de sprijinire a analizei i
deciziei de maxim importan, prin rezolvarea
problemelor de optimizare, att la nivelul elaborrii
programelor de activitate, ct i pe parcursul executrii
lor.
Un sistem informatic este conceput prin
colaborarea dintre specialiti din domenii conexe iar
realizarea unui sistem informatic este un proces
complex, de durat i care necesit activiti specifice
de analiz, proiectare, programare i implementare.

pagina 36
Sisteme informatice de gestiune

Sistemul informaional trebuie s devin, prin


introducerea sistemului informatic, instrument de
reglare i autoreglare a sistemului economic. Obiectivul
global urmrit este creterea fiabilitii sistemului
economic studiat.
Din activitatea practic de realizare a sistemelor
informatice se desprind urmtoarele principii pentru
realizarea sistemelor informatice.

1. Sistemul este pentru beneficiar, ceea ce implic:


participarea permanent a beneficiarului n toate
etapele de realizare a sistemului;
ntocmirea documentaiilor orientate ctre
beneficiar ntr-un limbaj accesibil acestuia;
aprobarea de ctre beneficiar a tuturor
propunerilor fcute n proiect;
responsabilitatea viitorului utilizator pentru
implementarea sistemului, pentru corectitudinea
datelor folosite i pentru pregtirea personalului
necesar exploatrii sistemului;

2. Problema cheie este cea a oamenilor nu a


echipamentelor, i n special a analitilor-proiectani
de sisteme, specialiti care au o influen hotrtoare
asupra modului de realizare a sistemelor.
3. Sistemele informatice trebuiesc justificate din punct
de vedere cantitativ i calitativ, deoarece reprezint
investiii importante.
4. Realizarea sistemului informatic este un proces
iterativ, ceea ce nseamn c nti trebuie stabilit
numai cadrul general, detalierea fcndu-se apoi
treptat, n mai multe iteraii.
5. Cnd nu putem s planificm ceva nu putem s
facem corect acel lucru, principiu valabil nu numai n
informatic. n virtutea acestui principiu trebuie

pagina 37
Sisteme informatice de gestiune

permanent urmrite i reactualizate planificrile


iniiale pe msura realizrii sistemului. De asemenea,
trebuie acordat o deosebit atenie modului de
etapizare a lucrrilor i mrimii etapelor pe care vrem
s le realizm.
6. Procedurile manuale sunt la fel de importante ca i
programele, de corecta lor proiectare depinznd
durata de implementare i modul de funcionare a
sistemului.
7. Trecerea de la vechiul sistem la noul sistem este ea
nsi un sistem i de aceea trebuie tratat cu mare
atenie. Proiectantul de sistem are de fapt n fa trei
sisteme: cel vechi, cel nou i cel care face trecerea de
la vechiul mod de lucru la cel nou.
8. Sistemul trebuie s aib o bun documentaie n
toate etapele de realizare.

pagina 38
Sisteme informatice de gestiune

3.2. Ciclul de via al unui sistem infomatic

Din cele prezentate anterior se constat c


restructurarea unui sistem informaional este un proces
complex. Analistul de sistem trebuie s parcurg o serie
de etape i s rezolve o mulime de probleme.
Analiza de sistem nseamn cunoaterea
sistemului, cunoatere care se traduce printr-o
reprezentare la nivel cerebral a sistemului n ansamblul
su. De fapt prin analiz s-a transpus realitatea mai nti
ntr-un model cerebral pe care analistul l va transforma
i l va prezenta sub forma unui model matematic,
grafic, etc..
Aceast activitate de percepere i reprezentare a
realitii nu este de loc uoar i presupune participarea
activ a tuturor membrilor echipei de proiectare dar i a
beneficiarului sistemului ntr-un context uman, material
i organizatoric, propice realizrii sistemului.
Mediul de proiectare al unui sistem informatic
const n unitatea proceselor de dezvoltare, a metodelor
de definire, descriere, abstractizare, modificare, rafinare
i documentare precum i modalitatea de automatizare a
aplicrii metodelor.
Cnd vorbim despre procesul de reorganizare a
unui sistem informaional, trebuie s descriem un model
care s prevad ceea ce va aprea n procesul de
dezvoltare. Aceast etapizare va arta ce trebuie fcut,
cum va fi realizat, cnd va fi terminat i cine va folosi
ceea ce s-a realizat.
Un bun model al procesului de prelucrare trebuie
s respecte trei cerine principale.
Trebuie s aib o mare putere descriptiv, putnd s
descrie esenialul n mod realist.

pagina 39
Sisteme informatice de gestiune

Trebuie s permit descrierea nsui a procesului de


dezvoltare i a modului de conducere a dezvoltrii
procesului.
Trebuie de asemenea s acopere cazurile
neprevzute i schimbrile continue care intervin
ntr-un astfel de proces.

n general, modelul trebuie s aib capacitatea de


a putea descrie o mare varietate de sisteme i de
subsisteme ale acestora. Exist un mare numr de
modele care descriu procesul de realizare a unui sistem
informatic denumite generic "modele ale ciclului de
viat".

Modelul WATERFALL (n cascad).

Este cel mai vechi i cel mai cunoscut model. A


fost dezvoltat n perioada anilor '60, caracteristica
principal constnd n parcurgerea unor etape numite
"faze". (Figura 4.1.)

1. Analiza cerinelor. Definirea i analiza necesitilor


utilizatorului.
2. Specificaia. Translaia cerinelor ntr-o descriere
general a sistemului.
3. Proiectarea. Crearea unei abstractizri a sistemului n
concordan cu specificaiile anterioare.
4. Implementarea. Crearea sistemului care
implementeaz ceea ce s-a proiectat.
5. Testarea. Determin dac implementarea satisface
cerinele.
6. Mentenana. Modificarea sistemului necesar pentru
a fixa problemele aprute. Ciclul de via se repet n
cadrul acestei faze.

pagina 40
Sisteme informatice de gestiune

Figura 3.1. Modelul Waterfall

Se constat c fiecare faz constituie o trecere de la


un nivel de abstractizare ridicat (puine detalii) la un
nivel mai sczut de abstractizare (mai multe detalii). Cu
toate c exist o bogat experien i tradiie n
aplicarea cu succes a modelului, exist unele probleme.
n primul rnd modelul nu este suficient de descriptiv
n ceea ce privete activitile care interfer prin toate
fazele ciclului de via cum ar fi: conducerea proiectului,
asigurarea calitii, verificarea i validarea. Spre exemplu
o eroare de specificare poate s nu fie descoperit dect

pagina 41
Sisteme informatice de gestiune

foarte trziu, i este extrem de greu de revenit la faza la


care s-a produs eroarea.
n al doilea rnd modelul a fost dezvoltat ntr-o
perioad cnd sistemele de mici dimensiuni i cu
arhitectur compact erau dominante.
n ultimul rnd modelul nu se preteaz la
transpunerea sa pe calculator. El a fost dezvoltat ntr-o
perioad cnd proiectarea asistat de calculator nu era
deloc neleas.

Modelul INCREMENTAL (RAPID-PROTOTYPING).

Acest model (al prototipizrii rapide) a fost creat


pentru a acoperi deficienele modelului WATERFALL cu
care se aseamn din mai multe puncte de vedere.
Diferena principal const n introducerea conceptului
de dezvoltare incremental.
Dezvoltarea incremental const n crearea unor
mici salturi de la vechea variant de sistem la noua
variant care conine un plus de funciuni. Produsul final
nu este vzut ca un sistem monolit livrabil integral la o
singur dat, ci este realizat i livrat dintr-o serie de
etape succesive corespunztoare fiecrei iteraii. Numai
la sfrit sistemul este disponibil integral, dar pn
atunci fiecare increment poate lucra ca un sistem de sine
stttor. (Figura 4.2.)
Modelul incremental elimin necesitatea furnizrii
cerinelor, specificaiilor generale i a celor detaliate
naintea nceperii etapei de proiectare. Aceste specificaii
numite "builds" (baselined intermediate software
products) sunt n mod formal specificate la nceputul
fiecrui increment. Acest lucru permite posibilitatea
schimbrii cerinelor prin adugarea lor n pasul
urmtor.

pagina 42
Sisteme informatice de gestiune

Figura 3.2. Modelul incremental

i n acest model exist posibilitatea erorilor n


formularea cerinelor dar spre deosebire de modelul
Waterfall acestea pot fi corectate de la un pas la altul pe
parcursul realizrii sistemului. n plus se poate simula
funcionalitatea sistemului, scopul su fiind furnizarea
unor feed-back-uri rapide proiectanilor i
conductorilor fr o pierdere inutil de timp,
eliminndu-se posibilitatea construirii unui sistem
greit.
Fiecare increment realizat n fiecare pas de
dezvoltare al sistemului se poate constitui ntr-un

pagina 43
Sisteme informatice de gestiune

prototip al viitorului sistem. Fiecare acest prototip poate


s se regseasc sau nu n sistemul final dar regula
general care trebuie urmrit const n planificarea
eliminrii acestor prototipuri.
Acest model reuete s integreze corect
activitile care acoper tot ciclul de via al sistemului,
cum ar fi:
Coordonarea proiectului const n capacitatea de a
controla versiunile sistemului de elaborat, pentru ca
acestea s fie n realitate incrementri ale versiunii
anterioare i nu nite modificri arbitrare i
neautorizate. Numai acele modificri care vor
determina schimbri favorabile n dezvoltarea
sistemului vor fi aprobate.
Verificarea const n stabilirea n continuu a
corespondenei ntre ce s-a solicitat i ce s-a
realizat.
Validarea, trebuie s aib n vedere c sistemul
construit s nu prezinte goluri i incoerene.
Dezvoltarea incremental este ca o sabie cu dou tiuri,
pentru c permind etapizarea sistemului n versiuni
succesive, orice problem aprut i nerezolvat la un
moment dat implic suspendarea etapelor urmtoare.
Dezavantajul implicat de aceast situaie este totui
mult mai mic, dect necazul produs de descoperirea
erorii numai la finalizarea sistemului.
Un alt avantaj const n posibilitatea dezvoltrii
simultane a mai multor sisteme, fiecare n diferite stadii
ale ciclului de via. Aceasta mrete capacitatea
conducerii de a acoperii un domeniu mai vast putndu-
se aloca mai bine resursele, dar trebuie inut cont c pot
aprea situaii n care este greu de estimat necesarul de
resurse mai ales n situaiile neprevzute aprute n
diferiii pai de dezvoltare ai sistemelor coordonate.

pagina 44
Sisteme informatice de gestiune

Modelul ciclului de concepie n V.

Dezvoltarea unui sistem urmrind abordarile


anterioare poate fi descompus ntr-o succesiune de
faze: specificaii, concepie, programare i mentenan
dup unii autori sau analiz preliminar, proiectare
logic, proiectare tehnic, programare, implementare,
exploatare i ntreinere, dup altii. (variante ale
modelului Waterfall).

Figura 3.4. Ciclul de concepie n V

pagina 45
Sisteme informatice de gestiune

Pentru evidenierea faptului c anumite faze ale ciclului


de via sunt condiionate de faze anterioare s-a propus
reprezentarea ciclului de via al unui sistem informatic
ca un ciclu de concepie n V (Figura 3.4.). Se observ
c etapele din braul descendent sunt validate de cele
situate pe braul ascendent. Asfel concepia arhitecturii
aplicaiei va trebui s rspund testelor de funcionare a
componentelor luate fiecare n parte dar i n ansamblu.
Aceast schem pune clar n eviden principalul
inconvenient al abordrilor clasice. Nu se poate valida
analiza fcut la nceputul proiectului dect atunci cnd
toate activitile de programare, testare i integrare sunt
terminate.

Modelul OPERAIONAL.

Acest model pornete de la o alt abordare dect


modelele anterioare i anume prin concentrarea efortului
de definire asupra aspectului operaional. Mecanismul
implementrii nu este ascuns ci st la baza specificaiilor
de definire. Cu alte cuvinte, modelul operaional creeaz
specificaii executabile (numite i specificaii
operaionale) care sunt ulterior transformate ntr-o
eficient implementare. Astfel comportamentul extern al
sistemului exist implicit n cadrul specificaiilor n timp
ce structura intern nu.
n acest tip de model proiectarea se refer direct
la condiiile de mediu n timp ce celelalte modele pun
accentul pe separarea cerinelor (comportamentul
extern) de structura intern a sistemului.
Prin realizarea legturii ntre specificaiile
operaionale i structura intern a sistemului, se

pagina 46
Sisteme informatice de gestiune

constat c modelul operaional este "orientat pe


problem" spre deosebire de celelate modele care sunt
"orientate pe implementare".

Figura 3.3. Modelul operaional

Unul dintre avantajele modelului operaional este


marea sa putere descriptiv orientat direct spre
rezolvarea problemei. Spre deosebire de modelul
incremental care pornete de la o descriere liber a
specificaiilor de definire, modelul operaional are
descrieri formale, riguroase i care pot fi uor analizate.
Acest fapt i permite s poat foarte uor s fie transpus
pe calculator.
Ca dezavantaje se constat contradicia dintre
necesitatea transformrii cerinelor externe ntr-o
structur intern nainte ca aceasta s fi fost definit.
Deoarece modelul nu este prea rspndit evaluarea
posibilitilor sale este dificil de fcut mai ales pentru
sisteme de mari dimensiuni. El este n schimb mai folosit
pentru realizarea sistemelor mici.

pagina 47
Sisteme informatice de gestiune

Din parcurgerea sumar a acestor modele se


observ c modelul Waterfall este un model atractiv care
se bazeaz pe o lung perioad de aplicare, fapt care i
confer avatajul numeroaselor experimentri n situaii
dintre cele mai diferite.
Modelul Incrememtal include n ciclul de via
activiti de conducere i dezvoltare prin pai succesivi,
realiznd un feed-back rapid ntre proiectani i
utilizatori.
Modelul de concepie n V pune n eviden
faptul c o faz o valideaz pe precedenta (similar
modelului Waterfall) dar i faptul c numai fazele
terminale realizeaz adevrata validare a etapelor de
nceput.
Modelul Operaional realizeaz specificaii
"executabile", mrete rolul automatizrii i stabilete o
strns legatur ntre specificaii i implementare.
Cu toate acestea se constat c un model perfect bazat
pe ciclul de via al sistemului informatic nu se poate
realiza, mai ales datorita unor condiii subiective.
Adesea un proiect trebuie nceput de la dorinele
unui viitor utilizator care are o vag idee despre ceea ce
va trebui s se realizeze, i numai dup ce sistemul s-a
realizat aproape integral se hotrte c nu este de fapt
ceea ce a dorit. Este extrem de greu de modelat aceast
situaie: "Nu tiu ceea ce vreau dar tiu ceea ce nu
doresc". Practica ne-a demonstrat c folosirea unui
model imperfert i incomplet este totui mult mai util
dect renunarea la orice fel de model.
Dar modelul nu este totul. Avem nevoie de un set
de prescripii pentru desfurarea activitilor cerute de
etapele unui model bazat pe ciclul de via, prescripii
utilizate pentru proiectarea sistemului. Am definit prin
aceasta metoda de proiectare. Metoda de proiectare are
o dubl responsabilitate:

pagina 48
Sisteme informatice de gestiune

de a creea produsul
de a implementa o parte din modelul ciclului de
via.
ncercarea de a gsi cea mai bun metod de realizare a
sistemelor informatice este un subiect de cercetare
deosebit de important. Problema cu cele mai multe
metode este c ele au att reguli implicite ct i
explicite. Regulile explicite sunt prezentate de obicei n
documentaia de realizare dar cele implicite nu sunt
prezentate nicieri.
Cnd se realizeaz un sistem informatic apar o
multitudine de probleme i este aproape imposibil s se
repete procesul original pentru crearea unui alt sistem.
Metoda nu furnizeaz numai paii care trebuie parcuri
ci precizeaz i ce decizii trebuiesc luate n paii
respectivi. Este foarte important, n acest caz, ca la
livrarea proiectului s se furnizeze i metoda dup care
a fost realizat.
Ultimul aspect care trebuie abordat este
"automatizarea" metodei de proiectare. Acest termen
este preferat termenului de "instrumente de dezvoltare"
(software tools), care vizeaz punctual o anumit
operaie. Automatizare nseamn un suport pentru o
metoda i este o parte integrat n procesul de
dezvoltare a sistemului informatic. Dar soluionarea cu
succes a problematicii const n integrarea coerent a
metodelor folosite ntr-o metodologie, i nu n
automatizarea lor.
Automatizarea are o mulime de avantaje. Cel mai
important const n reducerea muncii n aplicarea
metodelor, i ntr-un anume fel este cea mai realist
manier de aplicare a metodelor. Apectul birocraic al
celor mai multe metode presupune pstrarea unei
cantitai mari de informaii care este imposibil de
gestionat manual pentru sisteme de o anumit mrime.

pagina 49
Sisteme informatice de gestiune

Automatizarea implic o scdere a costurilor de


dezvoltare i planificare rezultnd o cretere calitativ a
activitii creative deoarece proiectanii i conductorii
proiectului sunt degrevai de aspectele de rutin. De cele
mai multe ori automatizarea faciliteaz nvarea i
comunicarea ntre membrii proiectului.

pagina 50
Sisteme informatice de gestiune

IV. METODA MERISE

4.1. Prezentare

Apariia metodei MERISE marcheaz o dat


important n istoria prelucrrii informaiilor. Aceast
apariie rezult pe de o parte din contextul generalizrii
prelucrrilor conversaionale, consecin a salturilor
tehnologice din anii '70, i pe de alt parte, rezult n
urma numeroaselor lucrri asupra bazelor de date i
asupra "abordrii sistemice".
MERISE s-a nscut n Frana n jurul anilor
1978-1979 ca urmare a unei vaste consultri lansate de
ctre Ministerul Industriilor cu scopul de a realiza o
metod modern de concepere i realizare a sistemelor
informatice.
ntre 1986 i 1989 metoda MERISE s-a impus cu
adevrat devenind un standard cu un numr de
utilizatori n continu cretere att n domeniul public
ct i n cel privat. Statisticile publicate n Frana n
1990 au confirmat aceast evoluie deoarece dintre
ntreprinderile mari i mijlocii care foloseau o metoda de
analiz-proiectare, 60% aleseser deja MERISE.
MERISE acumuleaz continuu i completeaz
cmpul su de aplicabilitate integrnd noi extensii. Patru
sunt direciile principale de evoluie:
integrarea arhitecturilor client/server;
o mai buna poziionare n raport cu metodele anglo-
saxone;
o abordare orientat pe obiecte;

pagina 51
Sisteme informatice de gestiune

dezvoltarea unui mediu metodologic european


concretizat astzi prin proiectul EUROMETHODE.
Consftuirea cu tema "MERISE et les autres"
desfurat la Versailles ntre 5 i 7 octombrie 1994 a
avut ca subtitlu "Ce sisteme informatice pentru o lume
n schimbare?" i i-a propus dezbaterea poziiei acestei
metode n raport cu alte abordri metodologice.
MERISE are numeroi adepi care o utilizeaz cu
pasiune, dar i opozani care o consider o metod
greoaie. Dac anumite proiecte sunt uneori nereuite
aceasta este din cauza unei folosiri inadecvate a
metodei. Folosirea metodei MERISE implic o investiie
personal care presupune o mare rigoare i folosirea
unor tehnici complexe. Aceast investiie personal nu
a fost facut, uneori, n cele mai bune condiii i n
aceast situaie, pentru anumii conductori de proiecte,
metoda pare greoaie.
Pentru a reui, un proiect MERISE trebuie s aib
obligatoriu adeziunea i participarea utilizatorilor.
Metoda presupune construirea de modele la nivel
conceptual, organizaional i operaional furniznd
astfel legturile existente n sistemele informaionale.
(Figura 4.1.)

pagina 52
Sisteme informatice de gestiune

Figura 4.1. Nivelele metodei Merise

NIVELUL CONCEPTUAL const n analiza


sistemului informaional n termenii obiectivelor, fr a
ine cont de nici un concept legat de organizare ("ce
trebuie fcut i cu ce date?").
Trebuie studiate separat n plan conceptual, pe
de o parte datele i organizarea lor i pe de alt parte
prelucrrile.

pagina 53
Sisteme informatice de gestiune

n termeni de organizare a datelor se face apel la


formalismul entitate-relaie i aceasta se traduce prin
entiti de baza i relaii ntre aceste entiti. La acest
nivel, cu ajutorul unei grafici adecvate se constituie
modelul conceptual al datelor (MCD), care permite o
descriere static a sistemului informaional cu ajutorul
conceptelor de entitate i asociaie.
MCD permite reprezentarea datelor din realitatea
nconjurtoare independent de opiunile tehnice, pentru
a uura gndirea n timpul activitii de concepie.
n termeni de organizare a prelucrrilor aceste
entiti vor fi descrise prin prelucrrile pentru care ele
sunt cauze i consecine. Aceast etap are ca scop
definirea operaiilor principale care trebuie efectuate n
domeniul studiat. Se va stabili o diagram de flux
(modelul conceptual al comunicaiilor MCC) care permite
descrierea informaiilor schimbate global n sistem prin
intermediul actorilor i fluxurilor.
Pornind de la aceast diagram, se va trece spre
modelul conceptual al prelucrrilor (MCP). Rezultatul su
final se va concretiza sub form schematic ntr-un
model "eveniment-operaie-rezultat" care va trebui s
rspund la ntrebrile: ce trebuie fcut n interiorul
sistemului informaional, sub impulsul cror evenimente
i ce rezultate se obin?
NIVELUL ORGANIZAIONAL const n integrarea n
analiz a criteriilor legate de organizare. Dup ce nivelul
conceptual a exprimat realitatea perceput n ansamblul
su, nivelul organizaional exprim aceast realitate aa
cum este ea trit de actorii participani, indiferent care
ar fi acetia. La acest nivel nu se face nici o distincie
ntre oameni i maini. La nivelul datelor este necesar
orientarea ctre o clas de soluii, i apare modelul logic
al datelor (MLD) care este o transcriere a modelului
conceptual al datelor. Are loc, n privina datelor, o

pagina 54
Sisteme informatice de gestiune

transformare a lor dar nu o mbogire a lor. Nivelul


conceptual al datelor este o descriere complet a
sistemului. Date noi pot fi create la nivele inferioare
(crearea unei redundane n vederea minimizrii
numrului de accesri la una din entiti) dar n nici un
caz nu se pot crea informaii noi.
Situaia este diferit la nivelul prelucrrilor.
Trecerea de la nivelul conceptual (MCP) la nivelul
organizaional (MOP) se concretizeaza prin ataarea
evenimentelor definite anterior, actorilor. n aceste
proceduri globale vor apare ntotdeauna actori care au
n plus noiunea de restricie temporal i
organizatoric. La nivelul prelucrrilor evenimentele
descrise au mai ales o dominant spaial dect una
temporal i se completeaz nivelul conceptual
rspunznd la ntrebrile cine? i unde?.
NIVELUL OPERAIONAL este o reprezentare a
mijloacelor care vor fi efectiv folosite pentru a gestiona
datele i prelucrrile i const n furnizarea soluiilor
tehnice rspunznd la ntrebarea cum?.
La nivelul datelor se va trece de la o clas de
soluii la una singur. Aceasta se concretizeaza prin
utilizarea unui anumit SGBD. Se face o alegere privind
metodele de stocare i de acces la informaii. Se
construiete la acest nivel modelul fizic al datelor (MFD)
care este transformarea modelului logic al datelor (MLD)
prin echivalarea noiunilor de tablou i coloane cu
noiunile de relaie i atribute din modelul logic al
datelor.
La nivelul prelucrrilor se procedeaz la
mprirea proiectului n programe. Modelul operaional
va descrie arhitectura programelor care vor executa
anumite funcii, dar n nici un caz la acest nivel nu va
exista o activitate de programare efectiv.

pagina 55
Sisteme informatice de gestiune

Fiecare din aceste nivele are ca obiectiv principal


furnizarea unui anumit numr de documente care s
permit sinteza procesului de gndire. Aceste
documente, indispensabile elaborrii, sunt leagate de
cele rezultate din analiza datelor.
Punerea n aplicare a modelelor de prelucrare la
orice nivel, conceptual, organizaional sau operaional
are nu numai scopul de a defini prelucrrile de efectuat
dar i opiunile alese n elaborarea modelelor datelor.
Abordarea analizei cu ajutorul metodei MERISE se
face dup trei axe constituind ceea ce numim "cele trei
cicluri". (Figura 4.2.) Analistul trebuie s parcurg toate
cele trei cicluri pe parcursul realizrii sistemului. Aceste
trei cicluri se desfoar simultan.
1.Ciclul de abstractizare este realizat prin
formalismul celor trei nivele conceptual, organizaional
i operaional i se va aplica asupra prelucrrilor i
datelor.
2.Ciclul de via presupune trei mari etape:
concepia sau perioada studiului sistemului existent
i apoi a noului sistem;
realizarea care acoper proiectarea i exploatarea
sistemului;
ntreinerea care va permite sistemului s evolueze i
s se adapteze modificrilor de mediu i noilor
obiective pn n momentul n care nu va mai fi
capabil de adaptare i va fi inlocuit cu un nou sistem.
3.Ciclul de decizie care cuprinde toate deciziile
luate pe parcursul desfurrii proiectului, mai generale
la nceput i apoi din ce n ce mai precise.

pagina 56
Sisteme informatice de gestiune

Figura 4.2. Cele trei cicluri ale metodei Merise

Aceste noiuni sumar prezentate se adreseaz


att utilizatorilor (cei care solicit serviciile) ct i
informaticienilor (furnizorii de prestaii). Eficacitatea i
validitatea unei analize const n calitatea comunicaiei
dintre beneficiar i proiectant iar calitatea comunicaiei
este obinut, n parte, graie utilizrii corecte a unei
metode de analiz.

pagina 57
Sisteme informatice de gestiune

4.2. Ciclul de via

n ara noastr ultima reglementare metodologic


n domeniul ciclului de via cu aplicabilitate n
economie i avnd caracter de directiv aparine
Institutului Central de Infornatic i dateaz din
decembrie 1977. Conform acestei metodologii realizarea
sistemelor informatice se desfoar n ase etape:
elaborarea temei de realizare, elaborarea concepiei
sistemului informatic (proiectarea logic), proiectarea
tehnic, elaborarea programelor, implementarea,
exploatarea i ntreinerea.

4.2.1. Elaborarea temei de realizare a sistemului


informatic.

n aceast etap iniial se examineaz


posibilitatea realizrii unui nou sistem informatic, sau
modificrii sistemului existent. Stimulul declanator al
acestei etape trebuie s fie de regul viitorul beneficiar.
Principala activitate n acest stadiu este
cunoaterea general a problemei i a obiectivelor care
trebuie realizate, la un nivel care s permit s se
stabilesc dac este sau nu necesar s se treac la
etapa urmtoare.
Elaborarea temei de realizare este etapa prin care
se cunoate situaia actual, se furnizeaz un diagnostic
i se caut soluiile posibile. n aceasta etap trebuie
elaborat o soluie independent de mijloacele de
realizare.
Rezultatele acestei etape constau n "caietul de
sarcini" i "specificaiile funcionale generale".

pagina 58
Sisteme informatice de gestiune

De obicei aceast etap, frecvent denumit i


studiu de oportunitate sau analiz preliminar implic
timp i efort relativ redus, doar din partea unor
specialiti cu experien i care au mai ntocmit lucrri
similare.
Obiectivul principal al acestei etape este formularea
cerinelor informaionale ale sistemului de conducere.
Activitile din cadrul acestei etape sunt :
studiul sistemului existent,
evaluarea sistemului existent,
evaluarea gradului de pregtire a ntreprinderii,
formularea cerinelor i a restriciilor pentru
realizarea sistemului informatic.
n cadrul acestei ultime activiti, cea mai important din
prima etap intr:
definirea obiectivelor i performanelor noului
sistem;
stabilirea domeniului i funciunilor noului sistem
informatic;
definirea cerinelor i restriciilor informaionale pe
probleme i funciuni;
estimarea resurselor disponibile pentru proiectarea,
implementarea i exploatarea noului sistem.

n realizarea etapizat a sistemului informatic


tebuie, n primul rnd, cunoscut sistemul existent.
Echipa de proiectare trebiuie s aib ca punct de plecare
un tablou de probleme elaborat mpreun cu
conducerea ntreprinderii. Pe baza acestuia se trece la
studiul sistemului prin care se urmrete definirea
caracteristicilor generale i analiza activitilor
desfurate.
De asemenea studiul sistemului presupune i
analiza modului n care sistemul informaional asigur
legturile ntre sistemul conductor i sistemul condus.

pagina 59
Sisteme informatice de gestiune

Pe baza concluziilor rezultate din studiul


sistemului, se evalueaz critic sistemul informaional i
se formuleaz cerinele i restrictiile pentru realizarea
sistemului informatic.
Printre tehnicile i metodele de analiza a
sistemului existent se numar:

1. Tehnica documentrii
2. Metoda analizei-diagnostic
3. Metoda diagramelor de flux informaional
4. Metoda evidenei economice
5. Metoda anchetelor
6. Metoda scenariilor

1. Tehnica documentrii.

Prin tehnica documentrii se urmrete culegerea


i prelucrarea informaiilor cu caracter teoretic i practic
privind sistemul studiat.
Pentru atingerea acestui obiectiv, documentarea
trebuie s se desfaoare ntr-o ordine logic folosind ca
instrument principal de lucru documentele care
reglementeaz existena i funcionarea sistemului
respectiv. Astfel de documente sunt: organigrama,
regulamentul de organizare i funcionare, alte acte
nomative. Prin organigram sunt reprezentate grafic
gruparea compartimentelor de munc dup criterii
funcionale, subordonarea acestora, repartizarea lor i
legturile dintre compartimente. n acest mod
organigrama vizualizeaz natura i poziia fiecrui
compartiment. Ea reflect obiectivele sistemului
economic, responsabilitile, delegrile de autoritate i
legturile funcionale. Informaiile cu caracter general
obinute prin analiza organigramei pot fi completate

pagina 60
Sisteme informatice de gestiune

prin studiul regulamentului de organizare i funcionare


a sistemului. Aspecte de detaliu asupra modului de
desfaurare a activitilor sunt completate prin
parcurgerea actelor normative care reglementeaz
prestarea lor.
Analiza situaiei existente este completat prin
documentarea asupra unor studii i proiecte informatice
elaborate n alte ntreprinderi cu profil apropiat.
Rezultatele documentrii urmeaz a fi
sistematizate i sintetizate pe domenii de probleme care
apar n tabloul ntocmit pe baza comenzii beneficiarului.

2.Metoda analizei-diagnostic.

Aceast metod i propune s furnizeze


informaii asupra sistemului existent. Analiza-diagnostic
este o metod colectiv de lucru aplicat de echipa de
proiectare. Diagnosticul const n relevarea anomaliilor
manifestate n organizarea i funcionarea sistemului i
n stabilirea remediilor corespunzatoare. Prin cercetarea
activitilor desfurate se stabilesc direciile de
dezvoltare pentru sistemul existent. Obiectivele
analizei-diagnostic sunt:
Realizarea unui sistem de organizare i conducere
perfecionat flexibil la modificrile care apar. Prin
analiza-diagnostic urmeaz s se stabileasc n ce
msur structura organizatoric satisface necesitile
conducerii i posibilitile de cretere a fiabilitii
sistemului prin tratarea automat a datelor.
Prevenirea factorilor perturbatorii care genereaz
efecte negative asupra sistemului economic sub
aspect structural, funcional i al nivelului de
performan.

pagina 61
Sisteme informatice de gestiune

Identificarea cilor de restabilire a echilibrului, de


compensare sau eliminare a factorilor perturbatorii.
Acest obiectiv, cumulat cu cel precedent, poate fi
ndeplinit prin abordarea global a ntreprinderii
privit ca sistem dinamic, nchis i adaptabil.
Concluziile analizei-diagnostic stau la baza analizei
critice a sistemului existent i sunt ghidul necesar
realizrii sistemului informatic.
Realizarea presupune luarea n considerare a
urmtoarelor aspecte:
strategia de dezvoltare a ntreprinderii;
condiiile de materializare pe baza resurselor
disponibile;
prioriti care se impun n funcie de condiii;
n aplicarea metodei se recomand parcurgerea
urmtoarelor etape de lucru:
culegerea informaiilor privind organizarea i
funcionarea sistemului existent;
formularea obiectivelor, care se realizeaz prin
conturarea elurilor urmrite i a modalitilor de
realizare;
enunarea instruciunilor privind desfurarea
aciunilor;
realizarea practic a instruciunilor;
analiza informaiilor culese i evaluarea rezultatelor;
Dac soluiile rezultate nu sunt edificatoare asupra
obiectivelor urmrite atunci analiza diagnostic se reia.
Concluziile analizei-diagnostic, corelate cu rezultatele
documentrii, constituie baza cunoaterii sistemului i a
posibilitilor de perfecionare.

3. Metoda diagramelor de flux informaional.

Identificarea caracteristicilor sistemului de


conducere necesit detalierea analizei sistemului

pagina 62
Sisteme informatice de gestiune

informaional. n acest scop se apeleaz la metoda


diagramelor de flux a documentelor i a momentelor lor
de completare urmrind raionalizarea sistemului
informaional i ameliorarea funcionrii acestuia.
Diagramele de flux informaional dau o descriere
sistemica a unui proces sau a unui ciclu de munc cu
suficiente detalii, care odat analizate pot duce la o
mbuntire a activitii respective.
Fiecare element component al diagramei este
astfel reprezentat nct s ajute pe analist s-i formeze
o imagine clar asupra sistemului studiat.
Majoritatea diagramelor combin reprezentarea
scris cu cea grafic i figurativ pentru a se asigura
participarea deplin a tuturor persoanelor interesate.
Schemele sunt instrumente excelente n
prezentarea propunerilor de ameliorare a metodelor de
munc la toate nivelurile de conducere.

4. Metoda evidenei economice.

Evidena economic reprezint un ansamblu de


procedee i tehnici de urmrire a fenomenelor i
proceselor care au avu loc n domeniul vieii economice.
Prin coninut evidena economic este componenta
major a sistemului informaional economic. Orice
operaie de flux real al valorilor materiale i bneti
trebuie s se gseasc consemnat n documentele de
eviden economic.
Dup procedeele i tehnicile folosite n
investigarea realitii economice evidena economic se
constituie n trei forme distincte:
a)- evidena tehnico-operativ
b)- evidena contabil
c)- evidena statistic

pagina 63
Sisteme informatice de gestiune

a) Evidena tehnico-operativ const n consemnarea


i centralizarea datelor privind procesele i
fenomenele economice la locul i n momentul
producerii lor. Evidena tehnico - operativ
furnizeaz informaii necesare conducerii operative.

b) Evidena contabil sau contabilitatea urmrete


formarea existena i folosirea mijloacelor
economice i a surselor lor de formare. Prin
coninut contabilitatea este cea mai important
component a evidenei economice. Ea asigur
continuitatea circuitului informaional ntre evidena
tehnico-operativ i cea statistic i este principala
surs de informaii a conducerii tactice i strategice.
c) Evidena statistic sau statistica oglindete i
caracterizeaz procesele n ansamblul lor prin
studierea unor fenomene social-economice de
mas. Cu ajutorul statisticii se poate studia
evoluia unor fenomene n perioadele anterioare
pentru a determina evoluia lor viitoare.

5.Metoda anchetelor.

Prin aceast metod se culeg informaii cantitative


i calitative pe domenii i probleme fiind o metod de
investigare analitic. Pentru ca investigarea s
duc la rezultate concludente, n aplicarea tehnicilor
este necesar s se aib n vedere urmtoarele principii:
selectarea persoanelor de interogat avnd n vedere
poziia lor n sistem i competena lor profesional;
antrenarea subiecilor alei la emiterea de idei noi
privind modul de desfurare a activitilor;
acceptare ideilor emise far o judecat imediat a
valorii lor;

pagina 64
Sisteme informatice de gestiune

stimularea gndirii participanilor prin formularea de


ntrebri adecvate;
verificarea rezultatelor prin mbinarea modului de
aplicare al tehnicilor;
Respectarea acestor principii asigur luarea n
considerare a comportamentului subiectilor investigai,
i n consecin, culegerea de informaii critice asupra
strii i funcionrii sistemului.
Metoda anchetelor se constituie dintr-un complex
de tehnici cu caracter interogativ cum sunt:

A) tehnica chestionarului
B) tehnica interviului
C) tehnica observrii directe

A. Tehnica chestionarului presupune utilizarea


chestionarului ca instrument de culegere a informaiilor
referitoare la obiectivele analizei.
ntocmirea chestionarului cuprinde trei faze distincte:

1. Faza pregatitoare, n care se delimiteaz cu


exactitate obiectivele chestionrii.
Astfel de obiective pot fi:

a) analiza activitilor de baz;


b) principali indicatori economici folosii;
c) identificarea caracteristicilor sistemului de
conducere;
d) identificarea metodelor i tehnicilor folosite n
prelucrarea datelor.
n aceast faz este necesar s se indice gradul de
detaliere a informaiilor i modul de prelucrare
ulterioar.

2. Faza de ntocmire a chestionarului.

pagina 65
Sisteme informatice de gestiune

n funcie de obiective i subiecii ce urmeaz a fi


supui chestionrii, se stabilesc numrul i tipul de
ntrebri. Numrul mediu de ntrebri ntr-un chestionar
trebuie s fie cuprins ntre 15 i 20. Un numr prea mic
de ntrebri nu poate furniza informaiile dorite i nu
justific efortul fcut pentru organizarea chestionarului,
iar un numr prea mare de ntrebri obosete subiectul
chestionat ceea ce duce la emiterea de rspunsuri
pripite, neconcludente pentru analiza de sistem.
Activarea subiecilor se poate asigura prin folosirea mai
multor tipuri de ntrebri, cum sunt:
ntrebri nchise, cu un numr redus de rspunsuri
precodificate prin care subiecii se pronun asupra
unor informaii culese prin alte metode i tehnici;
ntrebri factuale asupra unor fapte obiective, de
verificare a aptitudinilor, de identificare a unei stri
de fapt, de clarificare a unor aspecte ale analizei;
ntrebri deschise la care numrul rspunsurilor
poate varia de la un subiect la altul.

Dup locul ocupat n chestionar, ntrebrile se grupeaz


astfel:
introductive, n problema analizat;
"de filtru" prin care se precizeaz condiionarea ntre
ntrebri;
de bifurcare prin care se identific numrul
ntrebrilor la care se va rspunde n continuare dac
s-a rspuns afirmativ la ntrebarea anterioar i
numrul ntrebrilor nlnuite n cazul n care
rspunsul anterior a fost negativ;
de motivare a unor rspunsuri;
de control a exactitii rspunsurilor i de identificare
a subiectului chestionat.
Pentru ca formularea ntrebrilor s fie corect i
corespunzatoare realizrii obiectivelor, la aceast

pagina 66
Sisteme informatice de gestiune

aciune trebuie s participe, pe lng informaticieni


sociologi, psihologi, statisticieni.

3. Faza de verificare a chestionarului.


Prin testri se urmrete modul n care rezultatele
chestionrii concord cu obiectivele investigaiei. n
funcie de constatrile faptice, se corecteaz formularea
ntrebrilor i ordinea lor n chestionar. n ntocmirea i
completarea chestionarului este recomandat
respectarea urmtoarelor reguli:
formularea simpl, clar, concis i explicit a
ntrbrilor;
asigurarea libertii subiecilor de a completa sau
nu chestionarul printr-o ntrebare introductiv;
evitarea formulrii de ntrebri tendenioase,
ipotetice, prezumptive, insuficient de clare;
asigurarea unei succesiuni logice a ntrebrilor;
schimbarea ordinii rspunsurilor precodificate n
formulare pentru a se elimina tendina de alegere
a primului rspuns;
includerea n chestionar a unor ntrebri de
control prin care s se asigure veridicitatea
rspunsurilor.
Completarea chestionarului de un numr reprezentativ
de subieci, asigur obinerea de informaii relevante
pentru analiza sistemului.

B. Tehnica interviului

Prin aceast tehnic se urmrete obinerea ntr-


un interval de timp redus, de informaii privind
orientrile practice, metodele i strategiile existente sau
preconizate n rezolvarea problemelor analizate.

pagina 67
Sisteme informatice de gestiune

Interviul asigur obinerea de informaii recente i


verificarea informaiilor obinute prin alte metode sau
tehnici.
Alegerea subiectilor de intervievat se face avnd
n vedere urmtoarele constatri practice:
persoanele care ocup poziii medii n ierarhia
structurii organizatorice furnizeaz informaiile cele
mai apropiate de realitate;
colectarea de informaii corecte presupune
intervievarea nu numai a personalului de conducere
ci i a celui de execuie;
competena subiecilor trebuie verificat n
prealabil;
lipsa unei atitudini critice poate s semnifice reineri
n exprimarea ideilor.

Procedura de aplicare a interviului cuprinde trei etepe:


1. Etapa pregtitoare const n urmtoarele:
nsuirea terminologiei utilizate n domeniul
studiat;
formularea i coordonarea ntrebrilor;
cunoaterea prealabil a subiecilor;
alegerea momentelor propice pentru luarea
interviului (de obicei, partea medie a perioadei de
activitate).

2. Etapa de desfurare a interviului. n aceast etap se


cer a fi respectate urmtoarele reguli:
meninerea discuiei n limitele problemei
analizate,
acordarea unor momente de gndire,
formularea de ntrebri ajuttoare,
evitarea consemnrii de rspunsuri fr
argumentaie
insistarea asupra aspectelor neclare

pagina 68
Sisteme informatice de gestiune

sesizarea strilor de reinere n a critica aspectele


negative ale activitii analizate;
evitarea discuiilor n contradictoriu;
solicitarea de recomandri i din partea altor
persoane competente din domeniul analizat.

3. Etapa de culegere i prelucrare a informaiilor se


realizeaz prin consemnarea n raportul de interviu a
rspunsurilor cu precizarea aspectelor neclarificate i a
posibilitilor de completare a rezultatelor. Concluziile
interviului reflect starea elementelor sau a proceselor
analizate i posibilitile de remediere a deficienelor
existente.

C. Tehnica observrii directe.

Observarea direct a activitilor, asigur


cunoaterea nemijlocit a sistemului existent. Prin
tehnica observrii directe se studiaz sarcinile care
formeaz coninutul unei activiti. n analiza actvitii
de producie, spre exemplu, prin consemnarea
operaiilor efectuate asupra produsului i a timpilor de
execuie se contureaz structura ciclului de fabricaie i
alte aspecte ale produciei cum sunt:
tipuri de produse fabricate
tehnologii aplicate
locuri de munc
dotarea cu utilaje

Dac obiectivele propuse prin observarea direct sunt


clar precizate, atunci aplicarea acestei tehnici duce la
concluzii reale care nu pot fi obinute prin alte metode.
Tehnica observrii directe folosete instrumente
specifice de lucru:

pagina 69
Sisteme informatice de gestiune

sondaje
cronometrri
analiza posturilor ( locurilor de munc)
Prin aplicarea acestora se relev stri de fapt i
posibiliti pentru ameliorarea funcionarii sistemului.

n cadrul anchetelor combinarea tehnicilor


menionate asigur clarificarea problemelor de rezolvat
prin cunoaterea detaliat a sistemului i obinerea de
informaii privind posibilitile de raionalizare a
activitilor. Rezultatele relev deficienele existente i
impiicaiile tratrii automate a datelor.

6.Metoda scenariilor.

Metoda scenariilor se bazeaz pe un ansamblu de


procedee i instrumente prin care se stabilete
succesiunea logic a evenimentelor, n scopul de a
arta cum se poate evolua pas cu pas spre o situaie
viitoare plecnd de la situaia actual. Pentru fiecare
alternativ se urmrete evoluia sistemului reperndu-
se noi puncte nodale.
Prin abordarea global a sistemului sunt elaborate
scenarii calitative care stau la baza elaborrii scenariilor
cantitative.
Situaia cercetrilor previzionare la nivel global se
justific prin aceea c evenimentele care depind de
fenomene generale sunt, pe termen lung, mai uor de
prevzut dect acelea care depind de circumstane
particulare.
Obiectivele principale urmrite prin aplicarea
metodei scenariilor sunt:
predicia dezvoltrii, a evoluiei unor fenomene i
procese;

pagina 70
Sisteme informatice de gestiune

stimularea gndirii n studiul unei probleme


decizionale;
analiza detaliat a aspectelor dinamice.
n realizarea acestor obiective se urmrete parcurgerea
urmtoarelor etape de lucru:

1. Stabilirea obiectivelor concrete ale cercetarii.


starea spre care se sper c pot fi dirijate
evenimentele;
alegerea variantelor ce se ramific din punctele
nodale.
2. Studiul contextului n care se va dezvolta sistemul.
reprezentarea factorilor de influen i impactul
lor asupra sistemului;
la baza elaborrii modelelor vor sta seriile
dinamice ale indicatorilor ce reflect aciunea
factorilor.
3. Scrierea scenariilor prin abordare global i
descrierea evoluiei sistemului n dinamic, innd
cont de modificrile care apar n structura sistemului.
4. Stabilirea tendinelor n funcie de care va evolua
sistemul, dac asupra lui nu se exercit aciuni
voluntare externe.
5. Extragerea rezultatelor prin reinerea acelor tendine
manifestate care corespund obiectivelor propuse.

4.2.2. Proiectarea logic (elaborarea concepiei


sistemului informatic).

Obiectivul acestei etape l constituie elaborarea


proiectului de ansamblu al sistemului informatic, pe
baza cerinelor i restriciilor formulate n tema de
realizare. Scopul acestei etape const n determinarea
obiectivelor detaliate i cerinelor noului sistem.
Determinarea cerinelor se face prin studiul organizaiei

pagina 71
Sisteme informatice de gestiune

pe care o va servi sistemul, accentul punndu-se pe


beneficiile pe care le va aduce sistemul propus.
Principalele activiti care se desfoar n cadrul etapei
de concepie a sistemului informatic sunt urmtoarele:

definirea sistemului informatic, cuprinznd


delimitarea ariei i a legturilor sale externe;
estimarea dimensiunilor sistemului; definirea
structurii logice a datelor i definirea proceselor de
prelucrare a datelor;
adoptarea soluiei de principiu pentru codificarea
datelor i conversia fiierelor;
proiectarea de principiu a noului flux informaional;
stbilirea necesarului de echipamente, configuraiile
necesare, precum i modul de procurare a
echipamentelor;
stabilirea condiiilor de montaj, funcionare i
exploatare;
centralizarea cheltuielilor de dotare;
stabilirea necesarului de produse program noi;
structurarea sistemului informatic pe componente,
cu luarea n considerare a mai multor variante;
definirea intrrilor, ieirilor, i prelucrrilor necesare;
elaborarea graficului de ealonare pentru proiectarea
i implementarea componentelor sistemului;
evaluarea efectelor pe care le va produce noul sistem
informatic;
estimarea eficienei economice.
msuri pregtitoare pentru realizarea sistemului;

Activtatea cea mai important n cadrul elaborrii


concepiei sistemului informatic este analiza circuitului
informaional. Aceasta nseamn c fluxurile pariale
urmeaz a primi coeren prin studiul legturilor i
prelucrrilor nlnuite. n acest fel este posibil s se

pagina 72
Sisteme informatice de gestiune

delimiteze cu claritate graniele sistemului informatic i


legturile sale externe.
Aplicarea metodelor de analiz a circuitului
informaional se bazeaz pe urmtoarele constatri
practice:
fiecare activitate are un circuit informaional propriu;
delimitarea sistemului informatic presupune analiza
distinct a fiecrei activiti;
analiza fiecrei activiti este condiionat de
cunoaterea obiectivelor sistemului economic i de
reglementrile care definesc sistemul informaional;
n activitatea de gestiune economic operaiile de
prelucrare a datelor nu sunt diversificate i au
caracter ciclic (operatiile aritmetice i logice simple
reprezint circa 80% din totalul operaiilor de
prelucrare);
pentru fiecare activitate, intrrile condiioneaza i
sunt condiionate de ieirile informaionale;
prelucrarea datelor de intrare specifice unei activiti
n scopul obinerii ieirilor dorite definete
transformrile informaionale i determin circuitul
informaional al activitii;

Stabilirea ieirilor i intrrilor informaionale sunt


determinante n organizarea datelor, n timp ce
transformrile informaionale determin organizarea
prelucrrilor. Bazate pe aceste constatri, metodele de
analiz a sistemului informaional i de delimitare a
ariei i a legturilor externe ale sistemului informatic
mai des utilizate sunt:
1 - metoda analizei ieirilor;
2 - metoda orientat pe activiti;
3 - metoda rspunsului la stimuli;
4 - metoda compartimental;
5 - metode analizei celulare.

pagina 73
Sisteme informatice de gestiune

1. Metoda analizei ieirilor.

Metoda analizei ieirilor const n parcurgerea


fluxurilor informaionale invers, de la informaia final
(de ieire) spre informaia iniial (de intrare).
Aceasta analiz se face pe baza diagramelor de
flux informaional. Prin parcurgerea ntregului circuit
informaional, se determin:
volumul datelor de ieire;
volumul datelor de intrare;
prelucrrile efectuate pe parcursul circuitului;
purttorii de informaie;
caracteristicile datelor.
Metoda analizei ieirilor permite obinerea unei imagini
complete asupra circuitului informaional. Totodat, pot
fi remarcate deficiene de circuit i posibiliti de
raionalizare a sistemului informaional.

2. Metoda orientat pe activiti.

Prin aplicarea acestei metode se urmrete


definirea complet a aspectelor informaionale care
caracterizeaz fiecare activitate. Parcurgerea fluxurilor
informaionale pe fiecare activitate asigur cunoaterea
detaliat a sarcinilor i a operaiilor care definesc
activitile. Analiza unei activiti se face independent
de celelalte, rednd caracteristicile i intercondiionrile
interne ale activitii.
Metoda orientat pe activiti este eficient n
sisteme n care se manifest autonomia activitilor prin
relaii de interdependen reduse.

pagina 74
Sisteme informatice de gestiune

3. Metoda rspunsului la stimuli.

Metoda rspunsului la stimuli are ca punct de


plecare un stimul oarecare, cum ar fi: o comand, un
produs, o faz de fabricaie etc. Analiznd amnunit
stimulul, se stabilesc legturile dintre activiti i
compartimentele ntreprinderii. Dup identificarea
stimulilor la care trebuie s se raspund, se determin
compartimentele implicate i documentele la care se
refer stimulul. n continuare se urmrete fluxul
principal al informaiilor cu stabilirea punctelor n care
apar ramificaii i identificarea punctelor de control.
Analiza se completeaz cu studiul fluxurilor secundare.
Pentru activiti complexe, metoda rspunsului la
stimuli asigur observarea conexiunilor i demarcarea
operaiilor principale de cele secundare.

4. Metoda compartimental.

n aplicarea metodei compartimentale se stabilesc


aciunile care se realizeaz ntr-un compartiment i
legturile compartimentului studiat cu celelalte
compartimente.
Pentru activiti sau pri din activitile
desfurate n compartiment se determin intrrile,
prelucrrile i ieirile informaionale necesare realizrii
sarcinilor compartimentului.
Metoda compartimental este aplicabil n
ntreprinderi n care compartimentele prezint o
autonomie mai mare n cadrul structurii organizatorice.

5. Metoda analizei celulare.

La baza metodei analizei celulare st principiul de


ierarhizare a componentelor sistemului informaional

pagina 75
Sisteme informatice de gestiune

dup gradul lor de complexitate. Fiecrei componente


de tip subsistem i se asociaz un rang. Subsistemul de
rang zero este componenta elementar i se numete
celul.
Pentru o celul C intrrile X={x1,x2,....,xn}, ieirile
Y={y1,y2,..,ym} i transformrile T ale intrrilor n ieiri
definesc celula respectiv:

C={X,Y,T}

Dac ieirea celulei i constituie intrare pentru celula j,


atunci Ci i Cj formeaz un lan notat simbolic:

L = { Ci , Cj }

Figura 4.3. Lan de celule

Mrimile Yi i Xj (ieirile din celula i i intrrile n


celula j) desemneaz acelai element. Aceast dubl
semnificaie constituie o redundan informaional.
Reducerea unor asfel de redundane se face prin
introducerea conceptului de generaie. Elementul Xj
este un operand de generaia j. Ca urmare a
transformrii efectuate n celula j, apare generaia j+1
de operanzi ceea ce se exprim prin relaia:

Xj+1,r = T Xj,r
pagina 76
Sisteme informatice de gestiune

n care r semnific numrul de ordine al operandului n


cadrul generaiei.

Figura 4.4. Generaii de operanzi

Dou sau mai multe lanuri de celule care au cel puin


un punct comun, formeaz un arbore de celule:

A = { Lk , Lm }

Doi sau mai muli arbori legai n serie, paralel sau mixt
formeaz o structur complex. (Figura 4.5.)
Convenii:
operanzii primari (datele primare) constituie operanzi
de generaia zero. ( X01, X02, X03, X04);
transformrile operanzilor de generaia zero
formeaz familia de operatori de generaia 1 (T11,
T12, T13);
celulele sunt reprezentate de operatorii lor prevzui
cu doi indici; primul indic generaia, iar al doilea
numrul de ordine al operatorului n cadrul familiei;
ieirile unui operator sunt de aceiai generaie cu
operatorul, indiferent de generaia intrrilor;
operatorii n lant sunt de generaii monoton
cresctoare;

pagina 77
Sisteme informatice de gestiune

un operand poart o singur pereche de indici chiar


i cnd constituie intrri pentru mai muli operatori
de aceiai generaie sau de generaii diferite.

Figura 4.5. Arbore de celule

La nivelul ntreprinderii un operator se constituie din


reguli de lucru al cror suport fizic poate fi material sau
imaterial. Celula n care acioneaz un operator se
delimiteaz n funcie de necesitile analizei celulare.
Eficiena metodei crete prin combinarea aplicrii ei cu
alte metode.

Codificarea datelor. Premiza principal a realizrii de


componente viabile ale sistemului informatic, cu
parametri superiori de exploatare este codificarea
datelor care urmeaz a fi prelucrate cu echipamentele de
calcul. O metodologie adecvat de codificare contribuie
n mare msur la realizarea eficienei scontate pentru
ntregul sistem informatic. Aceasta asigur eliminarea
pagina 78
Sisteme informatice de gestiune

volumului mare de redundan informaional i


raionalizarea procesului de tratare a datelor.
Operaia de codificare a datelor const n
stabilirea unei corespondente biunivoce ntre elementele
sistemului informaional (documente, operaii, produse,
materiale etc.) i o multime de simboluri (cifre, litere
etc.). Datele de codificat constituie vocabularul de
intrare, iar simbolurile de reprezentare formeaza
limbajul de codificare. Rezultatele codificarii se
concretizeaz n sisteme de coduri care semnific
alfabetul de ieire.
Desfurarea operaiei de codificare presupuue
respectarea urmtoarelor principii:

adoptarea acelorai norme n determinarea


vocabularului de intrare;
folosirea unui limbaj de codificare accesibil, astfel
nct interpretarea alfabetului de ieire s se fac
fr dificulti;
respectarea biunivocitii ntre vocabularul de intrare
i limbajul de codificare. n finalul codificrii, la
fiecare element al vocabularului trebuie s
corespund un cod unic determinat;
previziunea evoluiei codurilor care s asigure
posibilitatea actualizrii sistemelor de coduri fr
perturbaii;
sistemele de coduri adoptate s fie sugestive n
redarea legturilor dintre fenomene, procese i
documente;
adaptarea codificarii n vederea prelucrrii
electronice a datetor.
ntre codurile interne sistemului economic i codurile
folosite n economia naionala, urmeaz a se stabili
modaliti de conversie care s asigure obinerea
ieirilor informaionale necesare n exterior.

pagina 79
Sisteme informatice de gestiune

ntr-o abordare metodologica, codificarea const n


urmtoarele activiti:

A. Stabilirea caracteristicilor generale ale codurilor.


Determinarea vocabularului de intrare i a
caracteristicilor acestuia.
Analiza structurii informaiilor din vocabularul de
intrare pentru fixarea structurii generale a codului pe
grupe de elemente ale sistemului informaional.
Necesitile de prelucrare impun utilizarea de coduri
prin care s se indice locul de stocare sau de utilizare
conturile n care se consemneaz natura i
apartenena elementelor codificate.
Determinarea alfabetului de ieire n funcie de
mrimea vocabularului de intrare i de structura
general a codurilor. Codurile care definesc alfabetul
de ieire, trebuie s conin un minimum de
simboluri de reprezentare.
Fixarea sistemelor de coduri astfel nct acestea s
asigure maximum de uniformitate a codificrii.

Principalele sisteme de coduri utilizate sunt:

1. Sistemul n ordine numeric (natural) este utilizat


pentru elemente temporare ale sistemului, fr
periodicitate. Orice element nou aprut afecteaz
ntregul sistem de coduri.
2. Sistemul n serie este o dezvoltare a sistemului n
ordine natural prin rezervarea de numere pentru
eventuale apariii de noi elemente n vocabularul de
intrare.
3. Sistemul pe grupe const n atribuirea unui anumit
numr de coduri fiecrei clase de elemente de
reprezentat. n general codul ijk (i = 1, m ; j = 1, n ;

pagina 80
Sisteme informatice de gestiune

k = 1, p) indic grupa i subgrupa j i sortimentul k al


elementului reprezentat.
4. Sistemul zecimal presupune divizarea vocabularului
de intrare n zece grupe iar fiecare grup n zece
subgrupe s.a.m.d. n practica economic acest sistem
este adoptat pentru codificarea conturilor de
eviden.
5. Sistemul n ah se bazeaz pe construirea de tabele
n care fiecare dimensiune specific o caracteristic a
elementelor de reprezentat, iar elementele tabelului
sunt numere n ordine natural. Aplicarea sistemului
este recomandabil pentru clase de elemente care
rmn neschimbate, ca spre exemplu, pentru
codificarea pieselor i subansamblelor unui utilaj.
6. Sistemul repetitiv const n realizarea codului din
caracteristicile elementelor de codificat. Sfera
sistemului este limitat la un vocabular de intrare
mai puin complex;
7. Sisteme combinate cum ar fi: sistemul n ordine
natural pentru clase ale vocabularului de intrare,
sistemul n serie pentru grupe i sistemul repetitiv
pentru elemente.
8. Sisteme binare prin care se asociaza cifre binare
elementelor vocabularului de intrare. Construirea
codurilor se bazeaz pe algebra booleeana i pe
conceptele teoriei mulimilor. Sistemele binare au o
larg aplicare n codicarea datelor de intrare n
prelucrarea electronic. Spre exemplu, sistemul
EBCDIC de reprezentare a datelor pe 8 biti i
sistemul ASCII de reprezentare a datelor pe 7 biti
sunt cele mai folosite.
Dat fiind importana codurilor n efectuarea prelucrrii
datelor, o atenie deosebit trebuie acordat
corectitudini fiecrui cod utilizat. n acest scop la cod se
adaug o cifr de control care s permit verificarea

pagina 81
Sisteme informatice de gestiune

corectitudinii accstuia n orice moment al tratrii


informaiei reprezentate. Cifra de control se stabilete
dup algoritmi diferii.

B. Clasificarea elementelor vocabularului de


intrare de la general la particular pn la nivel elementar
cu respectarea normelor legale. Operaiile i
documentele se grupeaz dup locul i rolul lor n
sistem, materialele dup natur, proprieti, mod de
gestionare.

C. Precizarea termninologiei standard de


codificare la care se preteaz fiecare clas de elemente a
vocabularului de intrare.
D. Codificarea propriu-zis prin stabilirea
corespondenei ntre vocabularul de intrare i alfabetul
de ieire.
E. Unificarea terminologiei i atribuirea codurilor.
n toate documentele de uz intern urmeaz a se atribui
coduri elementelor sistemului informaional.
F. Actualizarea codurilor const n adugri de
coduri pentru elementele nou intrate n sistem i n
eliminri de coduri perimate pentru elemente care nu se
mai utilizeaz.

Estimarea eficienei economice a sistemelor informatice.


Asimilarea lucrrilor de realizare a unui sistem
informatic cu lucrrile de investiii, face ca determinarea
i urmrirea eficienei s fie un aspect major al realizrii
sistemului informatic. Obiectivul global urmrit este
creterea efectului util al fiecrui leu cheltuit.
Eficiena, ca raport ntre efectul util i efortul
fcut pentru obinerea efectului scontat, se urmrete
sub aspecte multiple. (productivitatea muncii, indici de
utilizare ai resurselor, norme de consum, etc.)

pagina 82
Sisteme informatice de gestiune

Din punct de vedere informaional, satisfacerea


nevoilor de informare ale conducerii, entropia
informaional, costul informaiei, redau eficiena
sistemului informaional. n consecin, aspectele de
eficien se refer nu numai la resursele i efectele
imediate ale realizrii unei investiii; prin studiul
cheltuielilor necesare i al efectelor directe i indirecte
pe o perioad mai mare de timp. Ele includ i urmrirea
fiabilitii obiectivului investiiei dup darea lui n
exploatare.
Evaluarea cheltuielilor. Cheltuielile de realizare a
sistemului informatic se constituie din cheltuielile de
investiii necesare elaborrii i introducerii sistemului
informatic. n cheltuielile de exploatare se includ i cele
necesare ntreinerii sistemului n scopul creterii
performanelor acestuia. n etapa de analiz i proiectare
a sistemului informatic, sunt angajate cheltuieli curente
cu salariile echipei de proiectare (n situaia cnd
proiectarea se face cu fore proprii).
Declanarea activitilor de conconceptie, implic
efectuarea de cheltuieli pentru pregtirea cadrelor
proprii de informatic ce vor asigura exploatarea
sistemului.
De asemenea, nc din aceast etap de lucru,
apare necesar pregtirea psiho-social a personalului
ntreprinderii asupra utilitii sistemului informatic. n
acest scop sunt necesare cheltuieli cu desfurarea de
prezentri demonstrative privind avantajele prelucrrii
automate a datelor i implicaiile scontate. Scopul unor
astfel de aciuni este de a se asigura din timp
participarea activ a personalului la realizarea
schimbrilor pe care le va genera introducerea
sistemului informatic, evitndu-se opoziia surd a celor
vizai s fie atini de noua tehnologie.

pagina 83
Sisteme informatice de gestiune

O categorie important de cheltuieli este cea a


cheltuielilor cu tehnica de calcul, care cuprinde n afar
de cheltuielile pentru achizitionarea i instalarea
echipamentelor (hardware) i cheltuieli cu procurarea i
adaptarea unor aplicaii tip i a unor produse-program
generalizabile (software). Aceasta asigur nc de la
nceput, scurtarea perioadei de analiz-proiectare,
reducerea efortului de programare i creterea
performanelor de exploatare a sistemului informatic.
Cheltuielile pentru realizarea sistemului
informatic se mpart n:
1. cheltuieli iniiale ( Ci ):
cheltuieli pentru promovarea noii soluii;
cheltuieli pentru analiz i proiectare;
cheltuieli pentru procurarea i adaptarea
produselor software tipizate;
cheltuieli pentru procurarea configuraiei
hardware;
cheltuieli pentru amenajarea spaiilor necesare
instalrii echipamentelor.
2. cheltuieli de exploatare ( Ce ):
cheltuieli cu salariile personalului de informatic;
cheltuieli pentru perfecionarea pregtirii
personalului;
cheltuieli cu materialele consumabile i cu
amortizarea tehnicii de calcul;
cheltuieli cu ntreinerea curent i reparaii;
cheltuieli pentru ntreinerea software a
sistemului informatic (adaptarea sistemului
informatic).

pagina 84
Sisteme informatice de gestiune

Din categoria cheltuielilor iniiale cea mai mare pondere


o reprezint cheltuielile cu proiectarea sau cu procurarea
aplicaiilor tipizate grupate n cheltuieli cu software-ul i
cheltuieli cu achiziia echipamentelor care constituie
cheltuielile cu hardware-ul. Analiza evoluiei raportului
acestor cheltuieli pe o perioad lung de timp
este consemnat n figura 4.6.

Figura 4.6. Ponderea cheltuielilor cu hardware-ul i


software-ul ntr-un sistem informatic

Din punctul de vedere al ealonrii pe parcursul


ciclului de via al sistemului cheltuielile cu hardware-ul
sunt grupate preponderent la nceputul perioadei de
realizare a sistemului informatic, iar cheltuielile cu
software-ul au o repartizare diferit pe durata ciclului de
viat. Tema de realizare consum aproximativ 5% din
totalul cheltuielilor cu proiectarea, proiectarea logic i

pagina 85
Sisteme informatice de gestiune

proiectarea tehnic mai consum nc 35% din resurse,


pentru elaborarea programelor i testarea lor se mai
cheltuiesc 40% din fonduri iar pentru implementare 20%.
Aceste procente sunt relative la costurile de proiectare,
care la rndul lor reprezint doar 20% din totalul
costului sistemului pe parcursul ntregului ciclu de via.
Cheltuielile pentru exploatare i ntreinere sunt n mare
msur dependente de stabilitatea mediului economic n
care este implementat dar se estimeaz c aceste
cheltuieli se ridic la aproximativ 80% din costul total al
sistemului.
Evaluarea efectelor. Introducerea i exploatarea
sistmului informatic genereaz efecte directe i
indirecte, care pot fi estimate prin indicatori cantitativi
i calitativi.
Stabilirea efectelor economice cantitative se realizeaz
prin determinarea factorilor care contribuie la
modificarea mrimii cheltuielilor de producie pe
elemente primare sau pe articole de calculaie ale
costului de producie ca urmare a prelucrrii electronice
a datelor pe perioada de via a sistemului informatic.
Aceste efecte se materializeaz n economii de resurse
materiale i umane. La materii prime i materiale de
baz, rezult economii prin calcularea i urmrirea
normelor i a consumurilor specifice cu ajutorul tehnicii
de calcul. Pentru materialele auxiliare, economiile
rezult printr-o mai bun dimensionare a stocurilor i
prin urmrirea exact a consumurilor.
Estimarea cheltuielilor de transport-aprovizionare se
face n raport cu implicaiile sistemului informatic
asupra reducerii timpului pentru aprovizionare.
La salarii, calculul economiilor se bazeaz pe estimarea
economiilor relative de personal tehnic, economic,
administrativ prin evaluarea volumului de munc nainte
i dup introducerea sistemului informatic.

pagina 86
Sisteme informatice de gestiune

Relaia de calcul este urmtoarea:

Ep = Ne * (Mn/Mv - 1) * N/T

n care:
Ep este economia de personal;
Mv este volumul de munc nainte de introducerea
sistemului informatic;
Mn este volumul de munc dup introducerea
sistemului informatic;
Ne este numrul de lucrtori pentru exploatarea i
ntreinerea sistemului informatic;
N este numrul lunilor de funcionare a sistemului
informatic;
T este durata ciclului de prelucrare electronic a
datelor, n luni.

Economia relativ de personal este privit pe durata de


existen a sistemului informatic, este exprimat i cu
ajutorul ponderii lucrrilor din evidena economic n
condiiile prelucrrii electronice a datelor fa de
prelucrarea n sistem manual.
Prin centralizarea economiilor de personal rezult
economii la fondul de salarii. Coeficientul de reducere
relativ a fondului de salarii se aplic i contribuiei
privind asigurrile sociale i fondului de omaj.
La suma economiilor enunate mai sus se adaug cele
obinute ca urmre a gestiunii raionale a tuturor
resurselor financiare.
n categoria efectelor economice cantitative se
adaug profitul suplimentar. n calcule, punctul de
plecare l constituie stabilirea sporului de producie ca
urmare a funcionrii sistemului informatic. Relaiile de
calcul sunt urmtoarele:

pagina 87
Sisteme informatice de gestiune

Sp = Q1 * N * Kf - Q0 * N + Spe

unde:
Sp este sporul de producie ca urmare a funcionrii
sistemului informatic;
Q0,Q1 reprezint valoarea produciei nainte i
respectiv dup introducerea sistemului informatic;
N este numrul de ani estimat pentru funcionarea
sistemului informatic;
Kf este coeficientul modificrii valorii mijloacelor de
producie n primul an de funcionare a sistemului
informatic fa de anul precedent;
Spe este sporul efectiv a valorii produciei pe durata
exploatrii sistemului informatic.

Calculul profitului suplimentar (Ps) datorat introducerii


sistemului informatic se face avnd n vedere profitul
scontat ce se obine n primul an de aplicare a sistemului
informatic (P1) profitul normat (Pn) exprimat n mrimi
relative:

Ps = P1 * Sp / Q1

sau

Ps = Pn * Sp

Aplicarea modelelor de normare a costurilor permite ca


determinarea economiilor i a profitului suplimentar s
se realizeze global prin abaterea dintre preul normat i
preul efectiv nainte i dup introducerea sistemului
informatic.
La cheltuielile variabile, dup determinarea mrimii
influenei factorilor cantitativi i calitativi, abaterea

pagina 88
Sisteme informatice de gestiune

suplimentar semnific influena introducerii sistemului


informatic asupra costului productiei.
Pentru cheltuielile fixe, creterea gradului de
automatizare a produciei duce la obinerea de economii
prin accentuarea tendinei de scdere a cheltuielilor fixe
pe unitatea de produs.
Pe lng efectele economice cantitative
menionate, funcionarea sistemului informatic
genereaz efecte indirecte (calitative) cum sunt:
mbuntirea formei i a coninutului documentelor
tehnice i economice;
raionalizarea sistemului de eviden economic;
orientarea personalului din compartimentele
funcionale de la activiti de rutin spre activiti de
concepie;
mbuntirea controlului asupra activitii de
gestiune economic;
transformarea informaiei privind costul produciei n
instrument de reglare operativ;
creterea posibilitilor de analiz economico-
financiar.

Dat fiind amploarea i complexitatea lucrrilor din


domeniul informaticii, se impune elaborarea unui buget
pentru aceast activitate constituit din:
bugetul investitiilor;
buget de exploatare;
buget de ncasri i cheltuieli.
Bugetul informatic asigur estimarea detaliat a efortului
i efectelor elaborarii, introducerii i exploatrii
sistemului informatic. De asemenea prin buget se
realizeaza ealonarea resurselor i a modului lor de
utilizare pe etape, perioade i responsabiliti.

pagina 89
Sisteme informatice de gestiune

Estimarea eficienei globale. Eficiena global a


sistemului informatic este exprimat prin indicatorii:

coeficientul de eficien global (Ke);

Ke = (Ec + Ps) / (Ci + Ce)

durata de recuperare a cheltuielilor (Dr).

Dr = 1 / Ke

unde:
Ec este suma economiilor rezultate din funcionarea
sistemului informatic;
Ci sunt cheltuielile iniiale;
Ce sunt cheltuielile de exploatare;
Ps este profitul suplimentar.

Reducerea cheltuililor cu caracter informatic constituie


calea principal de cretere a eficienei sistemului
informatic. Cu ct durata de recuperare a cheltuielilor cu
caracter informatic este mai mic, cu att profitul
suplimentar este mai mare ca urmare a faptului c n
perioada dintre momentul recuperrii cheltuielilor i
abandonarea folosirii sistemului informatic, economiile
se transform n profit. Eficiena global crete i ca
urmare a prelungirii duratei de via a sistemului
informatic.
Din punct de vedere organizatoric, eficiena
sistemului informatic se poate determina cu ajutorul
indicatorul "entropia informaional" (H) prin care se
msoar gradul de nedeterminare pe care l nltur
informaiile din sistem. Diferena dintre entropia
informaional calculat nainte i dup introducerea

pagina 90
Sisteme informatice de gestiune

sistemului informatic, semnific, n cifre absolute,


creterea gradului de organizare a ntrepriderii.
Eficiena global a unui sistem informatic trebuie
apreciat i prin prisma implicaiilor introducerii
prelucrrii electronice a datelor asupra conducerii:
previziunea strilor i a funcionrii sistemului
economic capt determinri realiste ca urmare a
elaborrii i a folosii unor modele adecvate;
organizarea sistemului economic comport
mbuntiri substaniale prin raionalizarea structurii
organizatorice i prin posibilitatea integrrii
metodelor de conducere previzionar;
deciziile primesc noi determinri calitative prin
sporirea gradului de obiectivitate;
coordonarea activitilor se bazeaz pe informaii
necesare reglrii funcionrii sistemului economic la
diverse nivele;
se asigur controlul prin informarea operativ i
oportun asupra dereglrilor care apar n
funcionarea organismului economic.
Eficiena sistemului informatic se exprim i prin prisma
timpului mediu de rspuns. Timpul mediu de rspuns
este diferena, n uniti de timp, dintre momentul
punerii la dispoziia utilizatorului a unei informaii i
momentul cererii informaiei respective.
Aprecierea eficienei economice cu ajutorul timpului
mediu de rspuns se realizeaz cu ajutorul
coeficienilor:

Kt = tm0 /tm1

Kc = Ct1 / Ct0

pagina 91
Sisteme informatice de gestiune

n care:
tm0,tm1 reprezint timpii medii de munc necesari
nainte i dup introducerea sistemului informatic;
Ct0,Ct1 reprezint costurile totale nainte i dup
introducerea sistemului informatic.

Eficiena global a sistemului informatic se estimeaz


prin raportul

Eg=Kc / Kt

care exprim corelaia dintre scurtarea timpului mediu i


costul pe care aceasta l genereaz. Sistemul informatic
este performant dac raportul este subunitar i apropiat
de valoarea zero.
Se consider c o lucrare de concepie n
domeniul informaticii este, n primul rnd, o lucrare de
creaie n domeniul conducerii, incluznd problematica
perfecionrii mecanismului economico-financiar i a
interaciunilor micro i macro economice. Activitile de
informatic sunt menite s asigure condiii de cretere a
produciei prin reflectarea n sistemul informatic, a
factorilor de influen asupra rezultatelor financiare ale
ntreprinderii.
Estimarea eficienei economice a sistemului informatic,
avnd n vedere implicaiile complexe ale realizrii i
exploatrii componentelor informatice, atest faptul c
sistemul informatic concur la promovarea eficienei
economice n toate sectoarele de activitate prin creterea
efectelor utile i concentrarea efortului asupra aciunilor
de concepie i de conducere a ntreprinderii.

pagina 92
Sisteme informatice de gestiune

4.2.3. Proiectarea tehnic.

Este etapa n care se definitiveaz mijloacele


tehnice necesare (echipamente, programe, proceduri
manuale....) prin care fluxul informaional stabilit
anterior este transformat ntr-un flux cu prelucrare
automat a datelor. Efortul principal este de proiectare
pur.
Frecvent, datele furnizate din proiectarea logic
pot fi gsite incomplete, astfel c vor fi necesare iteraii
i corecii care pot afecta soluia propus din puct de
vedere tehnologic, economic sau operaional.
n aceast etap obiectivul principal l reprezint
elaborarea componentelor funcionale detaliate ale
sistemului i a specificaiilor de definire a programelor.
Sarcina activitilor din aceast etap ce se desfaoar la
nivelul subsistemelor sau chiar al aplicaiilor revine
integral analitilor de sistem. Activitile desfurate n
aceast etap sunt:
proiectarea funcional detaliat pe componente i a
legturilor dintre acestea;
stabilirea cerinelor i a condiiilor tehnice de
realizare a programelor;
elaborarea programelor de lucru pentru etapa
urmtoare i stabilirea resurselor necesare.

Activitile de proiectare tehnic au ca obiectiv


materializarea concepiei sistemului informnatic prin
proiectarea funcional amanunit a componentelor
sistemului i a legturilor dintre componente. Pe baza
definirii complete i precise a sistemului informatic din
etapele precedente, n etapa de proiectare tehnic sunt
concepute specificaiile de realizare pe compnnente

pagina 93
Sisteme informatice de gestiune

(subsistem, aplicaie). Proiectul tehnic rezultat din


desfurarea activitilor etapei, pentru o component,
constituie baza programrii i a implementrii
componentei respective.
Plecnd de la ieirile informaionale dorite de
utilizator, sunt elaborate modelele de obinere a ieirilor
din intrrile disponibile prin definirea coleciilor de date
i a procedurilor de tratare a datelor din colecii. Aceste
activiti urmresc definirea detaliat a tehnologiei de
prelucrare a datelor. n elaborarea tehnologiei de
prelucrare a datelor, o deosebit atenie trebuie acordat
proiectrii fluxului tratrii datelor urmrind ca, prin
colecile de date i fluxul prelucrrilor s se reflecte
fidel realitatea. De asemenea, prezint interes major
verificarea funcionalitii componentelor proiectate sub
aspectul completitudinii i al corectitudinii operaiilor de
tratare a datelor. Perfornanele sistemului informatic
sunt determinate, n mare msur, de metodele de
organizeare a datelor.
Modalitile de constituire a coleciilor de date
sunt determinante asupra prelucrrilor, n timp ce
organizarea coleciilor de date este condiionat la
rndul ei de definirea fluxului tehnologic al datelor.
n organizarea datelor sunt determinante: studiile
pentru delimitarea ariei i a legturilor externe ale
sistemului informatic, modelele de obinere a ieirilor
din intrri, volumul datelor de prelucrat, cerinele de
informare ale conducerii.
Metodelele utilizate n organizarea datelor sunt :
metoda fiierelor independente,
metoda bazei de date.

Metoda fiierelor independente const n crearea de


fiiere pe suport accesibil prelucrrii automate a
datelor, pentru nmagazinarea datelor prelucrate n

pagina 94
Sisteme informatice de gestiune

cadrul fiecrei componente a sistemului informatic. Un


fiier este constituit dintr-o submulime de date
omogene relative la o clas de elemente a sistemului
informaional. (ex. fiierul de stocuri din aplicaia de
gestiunea materialelor).
n general pentru fiecare entitate distinct a
sistemului informaional (materiale, produse, personal,
etc.) se constiuie fiiere cu caracter permanent care
reflect starea elementelor la un moment dat. Operaiile
curente din sistemul economic constituie tranzacii i
sunt reflectate n fiiere temporare. (ex:intrri i ieiri de
materiale). Prin aplicarea datelor operaionale coninute
n fiierele temporare asupra datelor de structur din
fiierele permanente rezult ieirile informaionale
scontate i se asigur actualizarea fiierelor permanente.
n urma actualizrilor fiierele permanente vor cuprinde
starea entitilor "la zi".
Fiiere permanente (cartoteci, registre cataloage
etc.) i fiiere temporare (centralizatoare, jurnale ...)
sunt utilizate i n condiiile prelucrrii manuale a
datelor.
Metoda fiierelor independente asigur rapiditate
n organizarea datelor i a prelucrrilor. n acelai timp
efortul de definire complet i corect a sistemului
informatic este mai redus prin proiectarea tehnic
detaliat a fiecrei componente i integrarea ulterioar a
componentelor proiectate n sistemul informatic.
Aceast metod este frecvent utilizat n practic pentru
probleme de mici dimensiuni.
Creterea complexitii sistemului duce la
creterea numrului de fiiere necesare ceea ce
genereaz dificulti sporite de ntreinere. Utilizarea de
fiiere independente conduce la o flexibilitate redus a
sistemului informatic, modificarea structurii fiierelor
implicnd refacerea programelor care le utilizeaz. Prin

pagina 95
Sisteme informatice de gestiune

duplicarea datelor n mai multe fiiere se genereaz


redundane informaionale, utilizarea neraional a
suporilor de informaie i dificulti n actualizarea i
controlul datelor.
Pornind de la aceste neajunsuri constatate la
organizarea datelor n fiierelor independente se poate
folosi ca alternativa metoda bazelor de date. Datele din
sistemul informatic sunt organizate n colecii care se
numesc baze de date i care au o serie de proprieti i
caracteristici ce vor fi artate ulterior. Trecerea de la
fiierele independente ctre bazele de date s-a fcut n
timp prin mai multe etape:
fiecare program de calcul utiliza date i fiiere
specifice, proprii pentru obinerea rezultatelor dorite.
(metoda fiierelor independente).
mai multe programe folosite n rezolvarea unor
probleme similare, utilizau date i fiiere comune,
grupate n colecii mai mari specifice domeniului
respectiv.
toate programele utilizate folosesc o colecie unic
de date, o aa zis "baz de date" n care sunt
incluse toate datele necesare .
Necesitatea unor mari baze de date comune a fost
simit nu numai de fabricanii de calculatoare i de
proiectanii de sisteme informatice, ci i de utilizatorii
sistemelor elaborate. Toi au constatat c n sistemele de
o anumit mrime, n care se lucreaz cu volume mari
de date, este nevoie s se gseasc o serie de
modaliti, tehnici i metode eficiente pentru definirea
organizarea, memorarea i actualizarea datelor n forme
din ce n ce mai performante. Sistemele informatice n
care se utilizeaza conceptul de baz de date prezint
unele avantaje:
Reducerea considerabil a nivelului de redundan al
datelor memorate. Folosind bazele de date comune

pagina 96
Sisteme informatice de gestiune

se pot obine informaii uniforme, att temporal ct


i fizic. Se evit actualizarile pariale a acelorai date
n fiiere diferite.
Utilizarea acelorai date n mai multe activiti.
Avnd un sistem unitar pentru definirea i regsirea
datelor, implementarea unor noi programe se face
relativ uor. Procedurile folosite pe msura
construirii i dezvoltrii sistemului fiind ct mai
uniforme, exploatarea se face mult mai sigur i
eficient.
Controlul centralizat, integritatea i securitatea
datelor sunt posibile n astfel de sisteme deoarece
definirea structurilor de date, modul lor de
gestionare i accesul la acestea sunt n mna unui
singur grup coordonator (denumit n general
administrator al bazei de date).
Independena datelor faa de programe i suporii
fizici de memorare genereaz creterea calitii i
fiabilitii sistemului informatic.

Deoarece nu exist o definiie general acceptat, vom


denumi o baz de date "un absamblu unitar organizat i
structurat de date a crui gestionare se face printr-un
sistem specializat denumit sistem pentru gestionarea
bazelor de date (SGBD)". Prin gestionarea bazelor de
date se ntelege ndeplinirea unor funcii specifice de
operare asupra lor: creare/generare, actualizare/inere
la zi, interogare i reorganizare.
Ansamblul format din:
baza de date,
sistemul care o gestioneaz (SGBD),
echipamentele de calcul utilizate pentru
nregistrarea, memorarea i pentru prelucrrile
efectuate asupra datelor din baza de date,

pagina 97
Sisteme informatice de gestiune

procedurile automate i neautomate suplimentare


necesare pentru gestionarea datelor, n afara celor
din SGBD,
reprezint BANCA DE DATE.
n concepia modern de realizare a sistemelor
informatice "banca de date" devine subsitemul central,
prin el realizndu-se principalele legturi dintre
majoritatea celorlalte subsisteme i aplicaii n primul
rnd a celor care lucreaz cu datele din baza de date.
Un SGBD are trei componente principale:
utilizatorul sistemului;
administratorul bazei de date;
gestionarul bazei de date.

Utilizatorul primete rspuns la cererile de informaii pe


care le face direct pentru el sau pentru alte persoane.
Sunt mai multe categorii de utilizatori:
utilizatorul profesionist care pentru a primi
rspunsurile solicitate scrie programe, deci are
cunotine de programare;
utilizatorul nespecialist, care pentru formularea unor
ntrebri, scrie o serie de comenzi sau instruciuni
relativ simple, dar pentru a cror utilizare are nevoie
de un anumit instructaj (cteva zile);
utilizatorul nespecialist, de cele mai multe ori un
conductor, care nu trebuie s fac dect nite
operaii elementare pentru a obine informaiile
dorite (utilizatori "press-button").

Administratorul bazei de date este o funcie absolut


necesar pentru buna funcionare a SGBD-ului. Se
constat c administratorul bazei de date este necesar
totdeauna n cadrul sistemelor informatice chiar cnd nu
folosim conceptul de baz de date. El este reprezentat
de o persoan sau un grup de persoane care controleaz

pagina 98
Sisteme informatice de gestiune

i coordoneaz modul de introducere a datelor,


modificrile ce li se aduc i accesul la ele.
Administratorul trebuie s acorde o deosebit atenie
factorilor care afecteaz memorarea i regsirea datelor
i de aceea are nevoie de cunotine aprofundate privind
datele necesare n cadrul organizaiei i modul cum
acestea sunt folosite.

Gestionarul nu mai este o persoan sau un grup de


persoane ca n cazul primelor dou componente, ci o
combinaie de echipamente de calcul i de programe
care asigur accesul la date conform instruciunilor
primite de la utilizatori i de la administrator. n acest
scop gestionarul trebuie s aib o interfa cu toate
limbajele de programare convenionale admise de
SGBD-ul respectiv. Gestionarul ndeplinete unele funcii
care n sistemele anterioare erau ndeplinite de
compilatoare, asambloare, editoare de legturi,
programe utilitare, etc.. Gestionarul formeaz un fel de
grani ntre programele de aplicaie i mecanismele de
acces la date. Gestionarul interpreteaz cererile de date
"logice" ale diverilor utilizatori i cu ajutorul
mecanismelor sale de acces extrage i transfer datele
solicitate de acetia. Utilizatorul nu tie cum i unde
sunt memorate datele. Se spune c tot acest proces este
"transparent" utilizatorului, n sensul c este parcurs fr
a fi cunoscut de el n mod intim, ci numai n principiu.
Prin metoda bazei de date se urmrete
organizarea datelor din sistem astfel nct datele
memorate pe suport magnetic de mare capacitate s
rspund necesitilor de prelucrare i utilizare ale
tuturor componentelor sistemului informatic i ale
tuturor utilizatorilor. Respectarea principiilor privind
unicitatea datelor, independena datelor, consultarea
concurent a datelor necesit efectuarea analizei i

pagina 99
Sisteme informatice de gestiune

proiectrii sistemului informaional prin abordare


global i structurarea lui detaliat.
Activitile ce ar trebui realizate pentru
determinarea specificaiei logice de definire a bazei de
date sunt:
1. Trecerea n revist a tuturor cerinelor de informare
necesare pentru rezolvarea diverselor probleme. Cu
acest prilej se va stabili o ordine de prioritate n
nlocuirea subsistemelor i lucrrilor manuale cu cele
n care gestiunea datelor i furnizarea rezultatelor se
face prin intermediul tehnicii de calcul.
2. Se examineaz toate datele necesare pentru
satisfacerea cerinelor de informare cu stabilirea
legturilor informaionale care trebuie s existe ntre
acestea.
3. Se realizeaz o serie de analize i studii detaliate
privind datele care se vor utiliza n sistem. Abia acum
se poate vedea dac avem nevoie de un SGBD.
4. Se ntocmete pe baza rezultatelor obinute n
activitile anterioare, specificaia pentru baza de
date, care este o documentaie ce cuprinde:
datele i structurile de date propuse a fi incluse n
baza de date;
o schem care s reprezinte legturile
informaionale dintre subsisteme i aplicaii;
schema cu structurile logice de date i legturile
dintre ele;
restriciile hardware i software avute n vedere;
cerinele suplimentare pentru SGBD-ul care
urmeaz s fie utilizat cum ar fi: volumul
intrrilor, al ieirilor, timpii de rspuns solicitai,
principalele prelucrri, etc.
n funcie de datele de memorat i de relaiile dintre ele
ntr-o baz de date pot s apar urmtoarele tipuri de
structuri:

pagina 100
Sisteme informatice de gestiune

structura punctual pentru entiti independente;


structura ierarhic liniar pentru entiti cu relaii
liniare ntre ele;
structura ierarhic arborescent pentru descrierea
relaiilor dintre entiti de tipul un tat are mai muli
fii;
structura de tip reea pentru entiti cu relaii
complexe ntre ele, rezultat prin generalizarea
structurilor ierarhice liniare i arborescente;
structura relaional cnd datele nu mai sunt privite
ca nregistrri ci ca relaii.
Buna funcionare a unui sistem informatic lucrnd cu
conceptul de baza de date depinde n mare msur de
modul cum se proiecteaz aceast baz de date.
Alegerea variantei de proiectare a circuitului
informaional este condiionat de modul n care aceasta
asigur funcionalitatea componentei respective.
Verificarea funcionalitii necesit stabilirea
posibilitilor de obinere a datelor de ieire din datele
de intrare ale componentei proiectate. Descrierea
condiiilor logice i a regulilor de obinere a datelor de
ieire din datele de intrare este realizat eficient folosind
tehnica tabelelor de decizii.
Aceast tehnic se bazeaz pe constatarea c
vederea este cel mai dezvoltat sim uman. Un tabel de
decizii se bucur de toate avantajele pe care le ofer un
tabel oarecare provenind din faptul c sunt clare,
concise i uor de citit. Plecnd de la ideea c orice
operaie sau ansamblu de operaii poate fi condiionat
sau necondiionat, tehnica tabelelor de decizii d o
form tabelara procesului de prelucrare a datelor.
O tabel de decizii este constituit din patru pri
(cadrane):
1. condiii (criterii) pentru luarea deciziilor (C1;
C2;...Cm);

pagina 101
Sisteme informatice de gestiune

2. intrri ale condiiilor (IC); combinaii ale intrrilor


posibile redau reguli n luarea deciziilor (R);
3. decizii (aciuni) posibile (D1,D2,....Dp); succesiunea
vertical a denumirii deciziilor indic ordinea n care
urmeaz a fi executate deciziile;
4. intrrile deciziilor (ID) prin care se specific ce decizii
urmeaz a fi luate pentru fiecare regul.

CADRANUL I CADRANUL II
(condiii) (intrri ale
condiiilor)

CADRANUL III CADRANUL IV


(decizii) (intrri ale
deciziilor)

Figura 4.7. Cadranele unei tabele de decizii

Tabela de decizii descrie toate variantele posibile ale


valorilor condiiilor i deciziile corespunztoare fiecrei
combinaii a acestor valori n soluionarea unei
probleme. Citirea tabelei de decizii se face de sus n jos
astfel: "dac se realizeaz condiia C1 i dac se
realizeaz condiia C2 i dac ... atunci se ia decizia Dk".

R1 R2 R3 R4 R5 R6 R7 R8
C1 Se solicta mat. Da Da Da Da Nu Nu Nu Nu
X de cal. I
C2 Depozitul Da Nu Nu Nu Da Da Nu
dispune de
pagina 102
Sisteme informatice de gestiune

mat. X de cal I
C3 Depozitul Da Da Nu Da Nu Nu Nu
dispune de
mat. X de calit.
II n cantitate Q
C4 Solicitantul Da Nu Da Nu
accepta
schimbarea
calitii
D1 Elibereaza mat. * *
X de calit. I n
cant. Q
D2 Elibereaz mat. * *
X de calit. II n
cant. Q
D3 Emite comanda * *
de aprov. pt.
mat. X de
calit. I
D4 Emite comanda * *
de aprov. pt.
mat. X de
calit. II

Figura 4.8. Tabel de decizii

n funcie de valorile ntlnite pentru intrrile condiiilor


tabelele de decizii pot fi:

a) cu intrri limitate; cnd intrrile condiiilor sunt


explicitate numai prin valori DA sau NU (0 sau 1);
b) cu intrri extinse; cnd intrrile fiecrei condiii ale
unei tabele de decizii sunt explicitate prin mai multe
valori (0, 1, 2,...);

pagina 103
Sisteme informatice de gestiune

c) cu intrri mixte; cnd din necesitile analizei


problemei rezult condiii cu intrri explicitate, fie
prin valori DA sau NU fie prin mai mult de dou
valori.

pagina 104
Sisteme informatice de gestiune

4.2.4. Elaborarea programelor.

Dup ce specificaiile de realizare au fost


ntocmite i aprobate, ele vor fi repartizate diverselor
grupe de specialiti care au responsabilitatea s le
execute i ulterior s le asambleze. Etapa este
consacrat elaborrii programelor i procedurilor
manuale, aferente componentelor sistemului informatic,
precum i testrii componentelor. n funcie de
necesitile problemei dar i de cunotinele
proiectanilor, n aceast etap se pot folosi tehnici de
programare ca:
programarea modular;
programarea structurat;
programarea orientat pe obiecte;
sau , eventual soluii hibride conform nivelului de
stpnire a tehnicilor respective.

Programarea modular. Operaia de mprire a unei


probleme complexe, conceput din punct de vedere
logic ca un tot unitar, nu este uoar pentru c
ntotdeauna trebuie avut n vedere ca prile n care a
fost descompus ntregul s nu-i schimbe scopul iniial i
totodat s permit, relativ usor, reconstituirea
ntregului atunci cnd este necesar. n acest sens trebuie
respectate dou reguli:
fiecare component trebuie s ndeplineasc o
anumit funcie bine precizat n cadrul ntregului;
ntre componente este necesar s se stabileasc
foarte exact legturile, astfel ca fiecare parte s-i
poat realiza relativ independent funcia specificat
i n acelai timp s poat contribui la funciile
generale ale ntregului.

pagina 105
Sisteme informatice de gestiune

Prin modularitate nelegem proprietatea sau


posibilitatea ca un proces s poat fi descompus n
pari componente, cu legturi bine stabilite ntre ele,
astfel ca obiectivul general al procesului s poat fi ct
mai eficient realizat. Una din definiiile date noiunii
generale de modularitate aparine lui Russel Armstong,
care considera c un sistem este modular atunci cnd
este realizat dintr-o mulime de elemente creia i este
asociat o lege de structur. A gsi legea de structur
nseamn a prospecta interfaa dintre module. Dup
acelai autor, proiectarea interfeei dintre module este
simplificat dac modulele au fost concepute astfel nct
s aib o funcionalitate bine definit.
Modularizarea sistemelor informatice ine seam de
unele caracteristici ale acestora:
sunt realizate i implementate ntr-un timp
ndelungat (de ordinul anilor);
introducerea sistemelor informatice conduce la
cheltuieli importante;
sistemele informatice sunt folosite de un numr
mare de utilizatori, rspndii uneori pe zone ntinse;
cerinele utilizatorilor sunt mereu schimbate i
completate.

innd seama de cele de mai sus se poate face o


modularizare pe trei nivele a sistemelor informatice:
a) nivelul 1 - sistem;
b) nivelul 2 - subsistem;
c) nivelul 3 - aplicaie.

a) Sistemul informatic trebuie s urmreasc i s


contribuie la realizarea obiectivelor generale ale
ntreprinderii, fixate pe o perioad lung de timp.
Deoarece obiectivele i restriciile generale se pot

pagina 106
Sisteme informatice de gestiune

schimba n timpul realizrii sistemului informatic


este necesar o revedere i o redefinire periodic a
acestora. Acolo unde planurile de perspectiv ale
ntreprinderii, sunt cunoscute pentru o perioad mai
scurt dect cea prevazut pentru realizarea i
implementarea sistemului informatic, pot aparea
neconcordane imprevizibile, care pot conduce la
efecte negative.
b) Subsistemul corespunde, de regul, unor obiective
derivate din cele generale, rezultate prin detalierea
acestora. Exist unele tendine de mprire a
sistemelor informatice n subsisteme dup structura
ierarhic i organizatoric astfel:
strategic
tactic
operativ,
sau dup precizarea funciilor sale:
producie
comercial
financiar-contabil
personal
cercetare- dezvoltare.
ntre aceste componente (subsisteme) trebuie s
existe legturi (interfee) clare, ct mai puine i ct
mai rigide, n sensul c odat stabilite s nu mai fie
practic modificate.
c) Aplicaia, ca unitate component a subsistemului,
contribuie n general la satisfacerea unor obiective
specifice i se dezvolt de obicei la nivelul unor
compartimente sau activiti din cadrul ntreprinderii.
n structura sistemului pe trei nivele aplicaia se
gsete pe ultimul nivel, i construirea sistemului
informatic se face treptat prin realizarea de aplicaii
asamblate n cadrul nivelurilor superioare.

pagina 107
Sisteme informatice de gestiune

Adncind nivelul de detaliere al sistemului informatic


putem aduga nc dou nivele:
d) program;
e) modul de program.

d) Aplicaia la rndul ei este constituit dintr-o serie de


programe i proceduri manuale legate ntre ele i
care ndeplinesc funciile cerute.
e) La rndul lor programele sunt de cele mai multe ori
divizate n mai multe pri, numite "module
program" independente din punct de vedere logic.
Modulele sunt compuse din instruciuni scrise ntr-
un limbaj de programare.

La nivelul programelor modularitatea se mai numete i


micro modularitate. Corelarea modulelor sau cuplarea
modulelor este o msura a independenei modulelor, i
poate avea mai multe forme:
corelarea extern, cnd modulele utilizeaz aceleai
date globale ale sistemului;
corelarea prin control, cnd unul din module
controleaz execuia celorlalte n mod explicit, prin
chei de control sau variabile de control a cror
valoare indic modul de continuare a execuiei;
corelarea intern sau prin coninut, cnd un modul
refer direct alt modul;
corelarea prin date, cnd la apelarea unui modul de
ctre altul toate datele de intrare sau de ieire ale
modulului apelat sunt comunicate sub form de
parametrii.

Un alt element caracteristic este ponderea sau tria


modulelor care reflect modul de formare i coninutul
modulului. Exist mai multe posibiliti de divizare a
programelor n module i anume:

pagina 108
Sisteme informatice de gestiune

divizarea ntmpltoare, care d tria cea mai slab


modulelor cci programul este mprit arbitrar n
module;
divizarea logic, are ca rezultat module ce efectueaz
o funcie la fiecare apelare;
divizarea clasic, prin care modulul efectueaz mai
multe funcii necorelate ntre ele prin date;
divizarea prin comunicare, cnd modulele efectueaz
mai multe funcii corelate prin date;
divizarea funcional, cnd modulele efectueaz o
singur funcie care le este specific.

Modularizarea este una din sarcinile principale ale


proiectanilor de sisteme informatice i este n cele mai
multe cazuri, o operaie complicat de care depinde n
mare msur modul cum va funciona n final sistemul.
n acest scop, n cadrul proiectelor mari, pe baza unor
experiene anterioare, adaptate la specificul respectiv, se
elaboreaz reguli i chiar norme care trebuie avute n
vedere la mprirea n componente la toate nivelurile. n
fond, aceste reguli decurg din conceptul general de
modularitate, stabilind n principal c un modul trebuie:

s ndeplineasc o funcie unic, lucru extrem de


avantajos atunci cnd se fac modificri;
s fie complet;
s aib ct mai puine interfee cu ale module;
s permit o nelegere uoar a problemelor pe care
le rezolv;
s se poat ncadra n diversele tipuri de
modularitate ale sistemului.

Avantaje ale modularizrii:

pagina 109
Sisteme informatice de gestiune

1) Posibilitatea divizrii ntregului n pri mai simple i


mai uor de realizat.
2) Independena modulelor permite elaborarea i
testarea separat a acestora.
3) Fiecare modul poate fi realizat prin tehnicile
(limbajele) cele mai adecvate funciei pe care o
ndeplinete.
4) Posibilitatea construiri a unei biblioteci de module
testate (module standard) disponibile tuturor
proiectanilor.
5) Simplificarea ntreinerii sistemului (programului).
6) Permite abordarea de la simplu la complex i permite
o ncrcare echilibrat a fiecarui membru din echipa
de proiectare.

Dezavantajele modularizarii:
1) Muli proiectani nu neleg modularizarea sau nu se
pot acomoda cu ea.
2) Modularitatea cere eforturi suplimentare n faza de
proiectare.
3) Proiectanii nu cunosc problema n ansamblu ci
numai pari ale ei.
4) Concepia modular duce la realizarea de programe
care ncarc suplimentar unitatea central a
calculatorului cu funciile de dispecerizare i
comunicare ntre module.

Noiunea de modularitate este nsoit aproape


ntotdeauna de un alt concept, cel de "top-down". "Top-
down" nseamn "de sus n jos" sau "descendent". n linii
mari el ar putea fi explicat astfel: n procesul general de
cunoatere se ncepe cu aspectul general, "n mare" al
fenomenului, dup care, treptat, acesta se detaliaz, se
cunoate n profunzime, pn la un anumit nivel,
considerat suficient pentru scopul urmrit. Dac

pagina 110
Sisteme informatice de gestiune

modularizarea nseamn procesul de descompunere a


unui ntreg n pri componente, metoda cea mai
obinuit, pentru ca mprirea s fie corect fcut, este
tocmai cea "top-dovn".
Trgnd o concluzie mai general, se poate spune c
n orice fel de proces de cunoatere din lumea real,
metoda universal valabil este cea a analizei
descendente, "top-down".

Programarea structurat. Pentru abordarea unei


probleme complexe n realizarea a unui sistem
informatic se impun preocupri pentru scderea
raportului cost/ performan, prin aplicarea unor
principii de structurare att n fazele de proiectatre ct i
n cele de realizare a sistemelor informatice. Principiile
generale privind realizarea acestor produse informatice
trebuie aplicate n mod consecvent n toate fazele de
realizare. Aceste principii se refer n primul rnd la:
Identificarea funciilor necesare pentru realizarea
produsului, analog cu determinarea prilor
componente ale unui produs industrial.
Descompunerea consecvent descendent (top-down)
n procesul de identificare a funciilor componente
ale proiectului. Introducnd noiunea de "nivel al
functiilor" (Nf) i punnd convenional nivelul
rdcinii structurii Nf=0, putem defini nivelul unei
funcii oarecare ca fiind egal cu nivelul funciei din
care descinde plus unu. Funciile cu nivelul cel mai
ridicat se mai numesc i "primitive" ale structurii iar
cea cu nivelul zero se numete rdcina structurii.
Realizarea modular a produsului, presupune
izolarea funciilor gsite n faza de identificare, apoi
determinarea interfeelor dintre module.

pagina 111
Sisteme informatice de gestiune

Normalizarea primitivelor structurilor funcionale


(primitivele structurii).

La un anumit nivel de descompunere n ierarhia


funciilor unei structuri se gsesc algoritmii de rezolvare
ai subproblemelor. Pentru realizarea oricrui algoritm
este suficient utilizarea unui set restrns de structuri
funcionale primitive. Aceste structuri vor fi considerate
structuri elementare.
Tehnica de programare care i propune s
respecte aceste principii i care va fi tratat n
continuare este numit programarea structurat.
Pentru a crea o imagine general a efortului de
definire a programrii structurate prezentm o serie de
definiii posibile aprute pe o perioad mai lung de
timp, cu meniunea c cele din anii de nceput ai
conceptului prezint mai mult constatri de
circumstan i au o not uor ironic:
1. Este o ntoarcere la bun-simt.
2. Este metod general dup care programeaz cei mai
buni programatori.
3. Este programarea fr GO TO.
4. Este procesul prin care se controleaz numrul de
interaciuni dintre un proces i contextul su, astfel
nct numrul de interaciuni s fie o funcie liniar
depinznd de civa parametrii ai procesului.
5. Este programarea TOP-DOWN.
6. Programarea structurat se ocup de convertirea
unor scheme logice arbitrar de mari i complexe n
forme standard, astfel nct s poat fi reprezentate
prin iterarea i compunerea unui numr mic de
structuri logice de control standard.
7. Este o manier de a organiza i codifica programe
astfel nct s fie ct mai uor de neles i de
modificat.

pagina 112
Sisteme informatice de gestiune

8. Scopul programrii structurate este de a controla


complexitatea prin teorie i disciplin.
9. Programarea structurat poate fi caracterizat nu
prin absena instruciunii GO TO ci prin prezena
structurii.
10. O funcie major a structurii programelor este de a
face posibil demonstrarea corectitudinii lor.
11. Programarea structurat nu este o soluie total, ea
const, de fapt, n folosirea unor notaii formale
pentru a gndi ordonat.
12. Procesul de organizare a gndirii care duce la o
expresie inteligibil a procesului de calcul ntr-un
timp rezonabil.
13. Arta simplitii.

Sintetiznd se poate ajunge la urmtoarea definiie:


"Programarea structurat const dintr-o mulime de
restricii i reguli de programare care foreaz
programul s urmeze o form strns, n acest fel
eliminndu-se muli din factorii care conduc la erori i
care complic activitatea de testare i ntreinere."
Examinarea structurii interne a unui program,
evideniaz existenta unei structuri ierarhice ntre
componentele unui program, fiecare component fiind
coordonat de componenta de nivel superior i
coordonnd componenta de nivel inferior. Ideea
structurilor ncuibate (nested-logic) conduce la o
dispunere a elementelor componente ntr-o form n
care s se poat distinge nivelele ierarhice, astfel nct
fiecare nivel de prelucrare s reprezinte o detaliere a
nivelelor precedente. Pentru definirea structurii nested-
logic a unui program se utilizeaz ca instrument de
lucru diagrama de structur. Blocurile nested-
logic folosite n diagrama de structur sunt:

pagina 113
Sisteme informatice de gestiune

SECVENA care marcheaz grupul de enunuri care


se execut n ordinea n care au fost scrise.
SELECIA care marcheaz separarea enunurilor n
dou grupe i executarea unei sau alteia din aceste
grupe n funcie de o anumit condiie.
ITERAIA care marcheaz un grup de enunuri cu
execuie repetat de un numr de ori (inclusiv
repetarea de zero ori ceea ce echivaleaz cu
eliminarea grupului de enunuri).

Regulile de structurare ale blocurilor sunt:


punctul de intrare ntr-un bloc este unic;
punctul de ieire dintr-un bloc este unic;
blocul iterativ ncepe prelucrarea prin testarea
condiiei de ieire din ciclu;
un bloc poate conine orice combinaie de blocuri
care satisfac condiiile de mai sus.

Blocurile diagramei de structur sunt reprezentate prin


dreptunghiuri identificate printr-un nume nscris n
interior.

Diagrama de structur este reprezentarea grafic a unei


structuri de prelucrare pe nivele de detaliere conform
urmtoarelor reguli:
nivelele de detaliere se parcurg de sus n jos;
fiecare nivel reprezint o detaliere a nivelului
precedent;
blocurile situate pe un acelai nivel ierarhic se
parcurg de la stnga la dreapta;
terminarea parcurgerii unui nivel presupune
parcurgerea urmtorului bloc din nivelul anterior.

Regulile de citire a diagramei de structur sunt:

pagina 114
Sisteme informatice de gestiune

Citirea operaiei de trecere de la un nivel superior


ctre un nivel inferior se face utiliznd expresia
"const din".
Citirea operaiei de trecere de la un bloc la alt bloc de
pe acelai nivel se face utiliznd expresia "urmat de".
Citirea operaiei de trecere de la un nivel inferior
ctre un nivel superior se face prin trecerea la
urmtorul bloc al nivelului superior utiliznd
expresia "urmat de".
Un cercule marcat n colul din drapta sus al unui
bloc identific un bloc opional i se citete utiliznd
expresia "sau".
Un asterisc marcat n colul din dreapta sus al unui
bloc identific un bloc cu execuie repetat i se
citete utiliznd expresia "mai multe".

Reprezentarea blocurilor nested-logic utilizate n


diagrama de structura i corespondena lor cu
reprezentarea din schemele logice clasice este
prezentat in figura 4.9.

TEOREMA DE STRUCTUR: Oricare ar fi schema logic S


aparinnd mulimii schemelor logice clasice i care
reprezint structura logic a unui proces de prelucrare,
exist cel puin o transformare T pentru care S'= T(S)
astfel nct:
1. S' este echivalent cu S;
2. S' este o schem cu structur nested-logic.

pagina 115
Sisteme informatice de gestiune

Figura 4.9. Structuri elementare n programarea


structurat

Programarea orientata pe obiecte. Pentru problemele de


natur economic, n limbajele de programare clasice,
cea mai mare parte a ateniei era acordat descrieirii
structurilor de date deoarece, practic, prelucrrile
etectuate asupra lor sunt destul de simple i nu necesit
un efort de programare deosebit. Spre exemplu n
limbajul COBOL aproximativ 79% din lungimea codului
surs este ocupat de descrierea structurilor de date. n
timp, odat cu creterea complexitii programelor, a
aprut necesitatea unei organizri riguroase a muncii.
Ca o etap superioar capabil s rezolve n bun
msur problemele ivite, s-a impus programarea
structurat. De-a lungul anilor, n special datorit
pagina 116
Sisteme informatice de gestiune

creterii dimensiunii produselor software, i acest


instrument a devenit la rndu-i depit. Sporirea
complexitii programelor aducea dup sine dificulti
reale legate de ntreinerea unor programe mamut. Cu
alte cuvinte, dei preul produselor era n cretere,
calitatea lor tindea s scad.
n cutarea unei soluii care s scoat informatica din
situaia dificil n care se afla, s-a pornit de la ideea c o
bun reprezentare a temei de rezolvat este deseori
cauza transformarii unei probleme complexe ntr-una
deosebit de simpl. n urma diversificarii cutrilor, au
aprut limbaje avnd la baz noiunea de "cadru"
("frame") i cele care pornesc de la ideea de "aciune",
ambele noiunii folosite n inteligena artificial. Prima
categorie implementeaz "operaii" asupra unor "modele
de entiti" iar cea de a doua susine faptul c "obiectele
nu sunt simple elemente pasive asupra crora se fac
prelucrri, ci, dimpotriv, menirea obiectelor rezid n a
activa prelucrrile ce le vor suporta ele nsele.
Dei teoria programrii orientate pe obiecte era
bine fundamentat de peste 20 de ani, ideea nu a prins
cu adevrat dect n ultimii ani. Programarea pe obiecte
n loc s separe iremediabil datele de cod nu face altceva
dect s contopeasc cele dou elemente.
Primele limbaje cu adevrat demne de acest nume
au fost SIMULA (1965) i SIMULA-2 (1967), iar prin anii
'70 SMALLTALK.
Cel mai mare dezavantaj al lor, din punct de vedre
al penetrrii pe pia, a fost nsui faptul c au aprut ca
limbaje de sine stttoare, avnd o rspndire relativ
redus. Din acest motiv puini programatori erau dispui
s abandoneze limbajele consacrate n acele momente,
doar de dragul de a lucra obiectual. O bun perioad de
timp metoda programrii obiectuale a fost uitat.

pagina 117
Sisteme informatice de gestiune

n anii '80 n urma acceptrii definitive a


limbajului C, un colectiv condus de Bjarne Stroustrup
ncearc introducerea conceptului de "clas" ntr-un
dialect numit "C with classes". Ideea prinde contur i n
1983 ia natere prima versiune a noului limbaj C++.
Aproape imediat apar i partizanii fanatici ai OOP-ului
aflat acum la a doua tineree. Termenul de OOP provine
din "Object Oriented Programming" care desemneaz
disciplina programrii obiectuale sau orientat-obiect.
Profitnd deci de marea popularitate n rndul
soft-itilor i de multitudinea domeniilor de aplicaie (de
la grafica interactiv la exploatarea reelelor de
calculatoare i chiar pn la proiectarea compilatoarelor)
moftul devine mod i moda certitudine. Acest succes
extraordinar s-a datorat faptului c limbajul C++ nu
face nimic altceva dect s-i dea un nou avnt unuia
dintre cele mai la moda limbaje ale momentului "C".
OOP introduce conceptul de INCAPSULARE prin
care se ating urmtoarele obiective:
facilitatea deosebit de localizare a erorilor
modularizarea problemei de rezolvat.

Notiunea de clas conine declaraii de variabile


i declaraii de funcii care opereaz asupra variabilelor.
Funciile se numesc funcii membru sau metode iar
variabilele variabile membru. Cu ajutorul claselor, un
programator si poate defini orice tip de dat dorit,
mpreun cu setul de operaii. Toate aceste informatii
sunt ncapsulate ntr-o clas. Astfel prin clas vom
nelege un tip abstract de dat, definit de utilizator.
Un obiect este o variabil declarat ca fiind de
tipul clas. Altfel spus un obiect este o instaniere (o
realizare) a unei clase. Prin intermediul claselor se pot
separa informaiile de implementare (mecanism intern)
de cele de utilizare (mecanism extern).

pagina 118
Sisteme informatice de gestiune

Un alt termen introdus de OOP, este


motenirea. n urma definirii unei clase, cu un minim
de efort i timp se pot preciza seturi de clase
asemnatoare, avnd totui o trstur distinctiv.
Avnd o clas B putem defini o alt clas D care s
moteneasc sau s preia toate caracteristicile clasei B la
care s se poat aduga altele noi, proprii doar acesteia
din urm. Prima clas se va numi "clas de baz" iar cea
de-a doua "clas derivat". Moetenirea st la baza altor
concepte novatoare cum ar fi polimorfismul dar
elementul esenial al programarii obiectuale rmne
"ncapsularea".
Polimorfismul const n faptul c ntr-o ierarhie
de clase obinute prin motenire, o metod poate avea
forme diferite de la un nivel la altul, specifice
respectivului nivel din ierarhie. Aa cum n lumea vie
hrnirea este universal valabil ea deosebindu-se de la o
clas la alta de vieti, tot aa i n cazul OOP metoda
poate avea forme diferite de la o clas la alta.
n momentul de fa piaa informatic este
invadat de biblioteci i colecii de clase. Menirea lor
este de a permite un coeficient ct mai ridicat de
reutilizare a codului scris. Pe de alt parte, pornind de la
aceste clase, utilizatorul poate crea prin motenire alte
clase, care s-l ajute s-i rezolve problema n mod
optim. n plus, programatorul are garania folosirii unor
proceduri scurte, inteligibile i nu n ultimul rnd
corecte.
Un alt domeniu de utilizare a bibliotecilor de clase
este cel al realizrii prototipurilor unor produse
software. Prin prototip se nelege un program
funcional, simplificat i care s dea o imagine clar a
produsului final. Utilitatea lor const n faptul c, ntr-un
timp foarte scurt i cu un efort minim din partea
productorului, clientul poate avea o imagine destul de

pagina 119
Sisteme informatice de gestiune

clar asupra produsului final. Pentru o aplicaie oarecare


prototipul nu trebuie s conin algoritmul optim,
clientul urmnd s poat nlocui doar acele module care
sunt deficitare din anumite puncte de vedere.

pagina 120
Sisteme informatice de gestiune

4.2.5. Implementarea, exploatarea i ntreinerea.

Implementarea este etapa n care sistemul se


testeaz n condiii reale. Etapa ncepe cnd
componentele individuale, care au fost testate i
acceptate, pot fi asamblate pentru testarea i includerea
n sistem pe baza specificaiilor i manualelor elaborate
n etapa anterioar.
Circuitul informaional existent este nlocuit cu
noul circuit prin lansarea n execuie a programelor i
verificarea practic a modului de obinere a rezultatelor,
acestea constituind activitile de implementare a
sistemului informatic.
Etapa se consider terminat cnd sistemul este
acceptat de beneficiar. Unele activiti pregtitoare ale
implementrii pot ncepe nc din etapa precedent.
Activitile aferente implementrii sunt urmtoarele:

pregtirea implementrii;
executarea procedurilor de conversie;
testarea n condiii reale;
evaluarea rezultatelor obinute i verificarea
performanelor sistemului;
definitivarea documentaiei.

Etapa de exploatare ncepe cnd informaiile din


sistem sunt furnizate n mod curent beneficiarului. n
paralel cu exploatarea sistemului se desfoar
ntreinerea sistemului. Exploatarea este legat de
problemele curente zilnice ale meninerii sistemului n
stare de funcionare, n timp ce ntreinerea const n
activiti de evaluare periodic legate de modificrile ce
trebuiesc fcute pentru a menine sistemul viabil.

pagina 121
Sisteme informatice de gestiune

4.3. Ciclul de abstractizare

4.3.1. Modelul conceptual al datelor

Pentru realizarea unui model conceptual al


datelor este necesar folosirea unei reprezentri sub
forma de text a realitii aa cum a fost ea nteleas de
analist. Ea se rezum la descrierea literar ca urmare a
analizei, putndu-se deduce din aceasta entitile,
asociaiile etc. care vor constitui mai departe modelul
conceptual al datelor.

Concepte utilizate n MCD

a) entitate - este reprezentarea n sistemele


informaionale a unui obiect material sau imaterial
avnd o existen proprie i conform cu necesitile
gestiunii ntreprinderii.
n general se utilizeaz un substantiv comun ca
nume de entitate, nume ales astfel nct s sublinieze
ct mai bine relaia cu componenta din sistem pe care o
reprezint.

b) realizarea unei entiti - este un element


individualizat apartinnd entitii. Spre exemplu
informaiile relative la salariatul Popescu sunt o realizare
a entitii SALARIAT.

c) asociaia - reprezint o relaie ntre entiti. Numrul


entitilor care intervin n relaie caracterizeaz
dimensiunea asociaiei:
asociaii binare ntre dou entiti;

pagina 122
Sisteme informatice de gestiune

asociaii ternare ntre trei entiti;


asociaii n-are ntre n entiti.
n general se utilizeaz ca nume de asociaie un verb
care s sublinieze ct mai bine relaia dintre entiti.
Spre exemplu asociaia LUCREAZA permite s se
neleag faptul c un SALARIAT lucreaz ntr-o SECTIE.

Figura 4.10. Asociaie

d) realizarea unei asociaii - este o asociaie


individualizat adic o pereche, triplet, etc. constituit
dintr-o singur apariie a fiecrei entiti participante la
relaie.
Spre exemplu n afirmaia "salariatul Popescu
lucraz n departamentul Personal" cuplul
Popescu/Personal este o realizare a asociaiei
LUCREAZA.

e) asociaie reflexiv - este o relaie care exist ntre


realizarea unei entiti i o alt realizare a aceleiai
entiti. Spre exemplu asociaia INCADRAT este o
asociaie reflexiv care traduce faptul c un anumit
SALARIAT are posibilitatea de a ncadra (angaja) ali
salariai.

pagina 123
Sisteme informatice de gestiune

Figura 4.11. Asociaie reflexiv

f) legtura - reprezint o relaie ntre o entitate i o


asociaie. Ea este caracterizat prin cardinalitatea sa. Se
poate distinge printr-un nume, ceea ce este foarte
practic n cazul asociaiilor reflexive.

g) cardinalitate - permite s se exprime funcionalitatea


i totalitatea sau parialitatea unei relaii:
cardinalitatea minimal - este numrul minim de
participri ale realizri unei entiti la realizrile unei
asociaii;
cardinalitatea maximal - este numrul maxim de
participri ale realizrii unei entiti la realizrile
unei asociaii.

pagina 124
Sisteme informatice de gestiune

Figura 4.12. Cardinalitate

Spre exemplu dac se examineaz MCD-ul urmtor:

Figura 4.13. Exemplu cu entiti, asociaie i


cardinaliti

se poate spune c aceste cardinaliti indicate ntre


entitile SALARIAT i asociaia LUCREAZA se traduc
astfel:
orice salariat lucreaz n cel puin o secie,
orice salariat lucreaz n cel mult o secie,
adic orice salariat lucreaz ntr-o singur secie. n
acelai fel cardinalitile dintre SECTIE i asociaia
LUCREAZA se traduc prin: ntr-o secie lucreaz cel
pagina 125
Sisteme informatice de gestiune

puin un salariat i ntr-o secie lucreaz cel mult n


salariai, adic mai muli salariai.

Se constat c toate cardinalitile permit s


transpun realitatea i n consecin alegerea lor este
primordial. n plus, dup cum se va vedea n
continuare, ele au o influen deloc neglijabil asupra
MFD.
Cardinalitile principale sunt constituite din
urmtoarele combinaii:
0,1 - niciunul sau unul singur
1,1 - unul i unul singur
0,n - niciunul sau mai muli
1,n - cel puin unul sau mai muli
Este posibil s se genereze i alte cardinaliti dect
acestea, spre exemplu 0,2 dar n modelul fizic al datelor
cardinalitile superioare lui 1 sunt transformate n
cardinaliti n.

h) informaia - este componenta elementar a


sistemelor informaionale. (ex. nume, prenume, cod
postal, etc.)

i) domeniul - permite s se formalizeze ansamblul


valorilor care stau la baza informaiilor. Toate valorile
luate de informaii i care sunt transferate entitilor
constituie ansamblul valorilor din sistemele
informaionale.
Exemple: domeniul dobnzilor - numere pozitive cu 7
ntregi i 2 zecimale; domeniul numelor - alfabetic cu
majuscule.

j) proprietate - este informaia care se ataaz unei


entiti sau unei asociaii. Ea poate referi un domeniu

pagina 126
Sisteme informatice de gestiune

deci ea i poate motenii caracteristicile (tip, lungime,


list de valori).
Numele fiecrei proprieti poate fi nscris n
simbolul entitii sau asociaiei atunci cnd acestea sunt
purttoare de atribute.
Exemplu: entitatea SALARIAT are proprietile
marca, nume, prenume, iar asociaia INCADRAT are
proprietile data de nceput i data de sfirsit.

Figura 4.14. Proprieti

k) identificatorul unei entiti - este constituit din una


sau mai multe proprieti particulare ale unei entiti
astfel nct la fiecare valoare a identificatorului
corespunde o singura realizare a entitii.
Toate entitile trebuie s posede un identificator
care poate fi compus din una sau mai multe proprieti.
Prin convenie proprietile cu rol de identificator sunt
subliniate.
De exemplu proprietatea MARCA este
identificatorul entitii SALARIAT adic poate defini fr
ambiguitate fiecare salariat.

pagina 127
Sisteme informatice de gestiune

Figura 4.15. Identificator

l) identificatorul unei asociaii - este intotdeauna


obinut prin concatenarea indentificatorilor entitilor
participante la asociaie. Acest identificator nu figureaz
n MCD.

m) legatur-identificator. S-a vzut necesitatea ca


fiecare entitate s aib un identificator, dar n anumite
cazuri acesta nu este suficient.
Dac se urmreste MCD-ul urmtor:

Figura 4.16. Legatur identificator

pagina 128
Sisteme informatice de gestiune

se constat c cele dou entiti sunt legate printr-o


relaie de compoziie.
S-ar putea dori s se defineasc identificatorul
"cod lucrare" din entitatea elementar LUCRARE, relativ
la identificatorul "cod proiect" din entitatea compus
PROIECT. Dar cum este posibil ca dou lucrri s aib
acelai cod dac ele aparin unor proiecte diferite, se va
putea identifica far ambiguitate o lucrare prin codul su
i prin codul proiectului cruia i aparine.
n acest caz legtura care pornete de la entitatea
elementar este numit LEGATUR-IDENTIFICATOR, i
are obligatoriu cardinalitatea 1,1.
Pe grafic aceast cardinalitate apare ntre
paranteze, difereniindu-se n acest fel de o legatur
1,1 normal.

n) legatura de motenire. Motenirea poate fi exprimat


ca o legtur particular ntre entiti n acelai timp
foarte apropiate dar totui diferite. Datorit acestui
concept de entitate general sau mam, se exprim
caracteristicile comune mai multor entiti formnd o
aceiai familie.
Conceptul complementar de entiti specializate,
particulare sau fiice ale unei entiti generale exprim
caracteristicile proprii fiecrui membru al familiei. Se
vorbete de asemenea de legturi generice ntre entiti
tip i sub-tip. Toate proprietile definite pentru
entitatea general sunt motenite de ctre entitile
specializate. n acelai timp toate asociaiile unei
entiti generale sunt valabile pentru entitile
specializate.
Aceast noiune permite mbogirea
considerabil a MCD punnd n eviden noiunile de tip
i sub-tip n snul unei aceleiai entiti.

pagina 129
Sisteme informatice de gestiune

n plus ea permite utilizatorului s genereze un


MFD care ine cont ntr-adevar de specificaiile artate.
Se evit astfel, fie redundana informaional fie
nlocuirea coloanelor care au valori nule.
Fie de exemplu entitatea ANGAJAT, care cuprinde
angajaii de gen masculin i pe cei de gen feminin. Se
poate reprezenta aceast particularitate prin noiunea de
motenire considernd entitile ANGAJAT MASCULIN i
ANGAJAT FEMININ ca entiti specializate ale entitii
generale ANGAJAT.
Reprezentarea const ntr-o legtur cu sageat
care pleac din entitatea fiic i punctez entitatea
mam. Un simbol n forma de semicerc este desenat n
mijlocul legturii i servete ca punct de ntlnire pentru
alte legturi venind de la alte entiti fiic.

Figura 4.17. Motenire

Reguli de normalizare a MCD

Elaborarea unui MCD se realizeaz n mai multe


etape, i este adesea supus modificrilor pe parcursul
realizrii proiectului informatic. Una din etapele
pagina 130
Sisteme informatice de gestiune

eseniale ale realizarii unui MCD este verificarea


modelului aplicnd un numar de reguli numite reguli de
normalizare. Se obine n acest fel un modelul cu
redundan minima n stocarea datelor.

REGULA 1.
Toate entitile trebuie s posede un
identificator.

REGULA 2.
Toate proprietile unei entiti sau unei asociaii
trebuie s fie elementare, adic nedecompozabile.

REGULA 3.
Pentru fiecare realizare a unei entiti sau
asociaii, dou proprieti nu pot reprezenta aceiai
informaie real, adic nu pot s aib valori repetate
pentru o aceiai realizare a entitii sau asociaiei.

REGULA 4.
Toate proprietile, altele dect indentificatorul,
trebuie s depind n ntregime de identificator i nu
numai de o parte din el.

REGULA 5.
Fiecare proprietate trebuie s depind direct de
identificator i nu prin intermediul uneia sau mai multor
proprieti.

Dac modelul ndeplinete regulie 1,2 i 3 este n


PRIMA FORM NORMAL.
Dac ndeplinete i regula 4 modelul este n A DOUA
FORM NORMAL.
Dac ndeplinete i regula 5 modelul este n A TREIA
FORM NORMAL.

pagina 131
Sisteme informatice de gestiune

Exemplu: "Un salariat al unei ntreprinderi, mprit n


secii, lucreaz ntr-o singur secie i particip la minim
dou proiecte. Fiecare secie are un cod i o denumire."
Aceast prezentare se traduce n urmatorul MCD.

Figura 4.18. Model nenormalizat

Regulile normalizrii nu sunt respectate, i nu se


poate spune nici mcar dac este n prima form
normal. De altfel:
nici o proprietate nu este identificator (R1)
proprietatea ADRESA nu este elementar (R2)
este o repetare a numelor de proiect (R3).
Dac se admite c pentru o secie dat nu exist
doi salariai avnd acelai nume, se va putea alege ca
identificator cuplul COD_SECTIE, NUME.
Proprietatea ADRESA se descompune de exemplu
n dou proprieti elementare STRADA i ORAS.
Repetarea numelui de proiect se va traduce cu
ajutorul unei entiti PROIECT i a unei asociaii
PARTICIPA.
Se obine astfel urmtorul MCD.

pagina 132
Sisteme informatice de gestiune

Figura 4.20. Model n prima form normal

Acest MCD este acum n prima form normal.


Se poate constata c nu este respectat regula 4.
Cuplul COD_SECTIE, NUME identific fr ambiguitate
fiecare salariat, dar proprietatea DEN_SECTIE nu depinde
dect de o parte a identificatorului, proprietatea
COD_SECTIE. Pentru a respecta a doua form normal,
se adaug entitii SALARIAT o nou proprietate
denumit MARCA care identific fr ambiguitate fiecare
salariat din ntreprindere, iar DEN_SECTIE depinde direct
de MARCA. Se obine urmtorul MCD:

Figura 4.21. Model n a doua form normal


pagina 133
Sisteme informatice de gestiune

Acest model este acum n a doua form normal


dar nu este n a treia form normal pentru c nu este
respectat regula 5. Se constat c proprietatea
DEN_SECTIE nu depinde direct de identificator, dar
depinde mai curnd de proprietatea COD_SECTIE.
Dependena de identificator nu este direct ci mai
degrab tranzitiv prin intermediul proprietii
COD_SECTIE.
Pentru a elimina acest inconvenient este suficient
s se introduc o nou entitate SECTIE i o asociaie
LUCREAZA care arat faptul c un salariat lucreaz ntr-o
secie. Se obine urmtorul MCD care este acum n a
treia form normal.

Figura 4.22. Model n a treia form normal

n concluzie prima form normal este suficient


pentru implementarea unui ansamblu de date, dar
trebuie urmrit atingerea celei de-a treia forme
normale pentru a minimiza redundana informaional i
n consecin riscurile discordanelor dintre date.
Normalizarea este deci un proces prin excelen
intelectual, cci bazat pe analiza semantic a
proprietilor i plecnd de la un ansamblu amorf de
date se obine un model conceptual n a treia form
normal.
pagina 134
Sisteme informatice de gestiune

4.3.2. Modelul logic al datelor

n timp ce modelul conceptualal al datelor este


independent de sistemul de gestiune al fiierelor utilizat,
la nivel organizaional trebuiesc integrate soluiile de
organizare a datelor astfel nct formalismul
entitate/relaie s poat fi transcris ct mai exact, la
nivelul fizic, n termenii limbajului de gestiune a datelor
ales.
Alegerea depinde de tipul software-ului avut la
dispoziie, i noul model rezultat (modelul logic al
datelor - MLD) trebuie s in cont de posibilitile
acestui software fr ns s intre n detaliile tehnice ale
metodelor de stocare i de acces specifice urmtorului
nivel, nivelul fizic. Alegerea sistemului de gestiune a
datelor se poate face ntre fiiere i baze de date.
Utilizarea fiierelor const n nmagazinarea pe
suport accesibil prelucrrii automate, a datelor
prelucrate n cadrul fiecrei componente a sistemului
informatic. Un fiier se constituie dintr-o submulime de
date relativ omogene relative la o clas de elemente a
sistemului informaional. Identificatorul unui fiier este o
proprietate aleas astfel nct la fiecare valoare a acestei
proprieti s corespund o singur realizare a unui
articol din fiier. Articolul dintr-un fiier este o colecie
de proprieti care se refer la acelai element. O
realizare a articolului reprezint ansamblul proprietilor
pentru un articol individualizat.
Se pot distinge dou feluri de fiiere:

fiiere clasice de tip BASIC, FORTRAN, COBOL etc.


fiiere secvenial-indexate multicriteriale tip DBASE.

pagina 135
Sisteme informatice de gestiune

Cu fiierele clasice accesul dup criterii multiple


este dificil i sisteme de gestiune a fiierelor ca de
exemplu cel din COBOL nu permit dect funcii de
adugare, cutare, modificare i tergere. Orice alt
operaie rmne n sarcina programatorului.
La fiierele secvenial-indexate multicrteriale
accesul se face dup mai multe chei, este mult mai uor
i sunt oferite mai multe posibiliti de prelucrare.
Metoda fiierelor prezint inconveniente majore,
idiferent de tipul de fiiere folosit:
existena renundanelor;
apariia unor probleme de coeren;
procedurile de securitate trebuiesc programate;
programatorul trebuie s gestioneze el nsui relaiile
ntre fiiere
programatorul trebuie s cunoasc metodele de
stocare i de acces;
creterea complexitii sistemului duce la dificulti
sporite de ntreinere.
Ca urmare a persistenei acestor inconveniente n
informatica mondial s-a impus un nou concept care a
devenit dominant nc din anii '70. Acesta este conceptul
de baz de date. n sistemele de o anumit
complexitate sunt necesare metode performante pentru
definirea, organizarea memorarea i actualizarea
datelor. Astfel o baz de date poate fi definit ca un
ansamblu de date organizat unitar i structurat a crui
gestionare se face printr-un sistem specializat denumit
sistem pentru gestionarea bazelor de date (SGBD).
Notiunea de baz de date este caracterizat de
urmatoarele:
structurarea datelor;
redundan minim;
coerena datelor;
acces dup criterii multiple;

pagina 136
Sisteme informatice de gestiune

date legate ntre ele conform cu MCD;


independena programelor i datelor;
securitatea datelor;
actualizare i interogarea concurent.

n funcie de datele de memorat i de relaiile dintre ele


ntr-o baz de date pot s apar urmtoarele tipuri de
structuri:
structura arborescent; cnd exist o singur
legtur ntre dou entiti ale bazei de date, de la
"tat" la "fiu", exploatarea facndu-se fie pe traseul
"tat-fii" fie invers "fiu-tat".
structura reea; cnd o nregistrare "fiu" poate avea
mai multe nregistrri "tat", care permite cutarea
n toate direciile pornind de la orice entitate. Trebuie
menionat aici modelul CODASYL (Conferance on
Data Systems Languages) elaborat la nceputul anilor
'70, i ale crui norme sunt respectate de numeroase
sisteme de baze de date.
structura relaional; cnd entitatea este privit ca o
relaie ntre proprieti i nu ca o nregistrare,
asigurndu-se o independen total a programelor
fa de date.

Trecerea de la MCD la MLD se poate face ctre


toate tipurile de organizare a datelor, inclusiv ctre
organizarea n fiiere clasice, dar mai utilizate sunt
MLD CODASYL i MLD relaional. n cele ce urmeaz
vom dezvolta trecerea ctre MLD relaional.
Modelul logic al datelor utilizeaz concepte ale
modelului relaional i presupune dispunerea datelor
sub form de tablouri cu dou dimensiuni numite tabele
sau relaii.
Pentru a facilita nelegerea regulilor de trecere de
la MCD la MLD trebuiesc definite urmtoarele concepte:

pagina 137
Sisteme informatice de gestiune

a) tabel. Un tabel corespunde unei entiti sau unei


asociaii din MCD i este alctuit din linii i coloane.
b) linie. O linie corespunde noiunii de realizare a
entitii sau asociaiei.
c) coloana. Noiunea de coloan corespunde noiunii de
proprietate.
d) cheie primar. Noiunea de cheie primar corespunde
noiunii de identificator.
e) cheie strain. O coloan a unui tabel este numit
cheie strain dac ea corespunde unei chei primare
dintr-un alt tabel. Cheia primar permite accesul la
coloanele tabelului de referin evitnd repetiiile.

Reguli de trecere de la MCD la MLD

REGULA 1. Entitile devin tabele. Proprietile devin


coloane de tabele. Identificatorii entitilor devin chei
primare ale tabelelor.
REGULA 2. Cnd o asociaie binar are o legtur 0,1
sau 1,1 i o alta de cardinalitate 0,n sau 1,n apare o
migraie a cheilor entitii legate de legatura de
cardinalitate 0,n sau 1,n spre cealalt entitate.
Fie MCD-ul din figura 4.23, care prezint faptul
c un "beneficiar" caracterizat prin proprietile "cod
fiscal" (identificator) i "nume beneficiar" primete una
sau mai multe facturi caracterizate printr-un "numr
factur" (identificator) i "valoare factur". O factur este
primit de un singur beneficiar .

pagina 138
Sisteme informatice de gestiune

Figura 4.23. Reguli de trecere de la MCD la MLD;


exemplu

Asociaia nu se transform ntr-un tabel la nivelul


MLD, dar este explicitat plasnd n tabelul "factura"
cheia primar a tabelului "beneficiar" care devine o cheie
strain. Se obine astfel urmtorul MLD:

Figura 4.24. Reguli de trecere de la MCD la MLD;


exemplu

Dac ASOCIAIA din MCD prezentat anterior are


proprietatea "data" (data primirii facturii) atunci MCD i
MLD corespunztor arat astfel:

pagina 139
Sisteme informatice de gestiune

Figura 4.25. Reguli de trecere de la MCD la MLD;


exemplu
Dac se utilizeaz conceptul de LEGATUR-
IDENTIFICATOR ca n MCD-ul urmtor care arat c o
factur este constituit din una sau mai multe poziii
(rnduri n factur), iar o poziie aparine unei singure
facturi,

Figura 4.26. Reguli de trecere de la MCD la MLD;


exemplu

identificatorul entitii "poziii" va fi format din


concatenarea identificatorilor entitilor participante la
asociaie, conform MLD de mai jos:
pagina 140
Sisteme informatice de gestiune

Figura 4.27. Reguli de trecere de la MCD la MLD;


exemplu

REGULA 3.
Dac o asociaie binar este purttoarea a dou
legturi de cardinalitate 0,n sau 1,n asociaia devine un
tabel n MLD, n care migreaz cheile entitilor.
Asociaia devine un tabel, n care cheia primar
este obinut prin concatenarea identificatorilor
entitilor participante la asociaie.
Dac asociaia are proprieti, acestea devin
coloane n tabelul care rezult din asociaie.
Considernd urmtoarea situaie: "un client poate
s nu cumpere sau s cumpere n produse, iar un produs
poate s nu fie cumprat sau s fie cumprat de n
clienti" , modelele conceptual i fizic vor arta ca n
figura 4.28.

pagina 141
Sisteme informatice de gestiune

Figura 4.28. Reguli de trecere de la MCD la MLD;


exemplu

Noiunea de asociaie din MCD poate fi deci


tradus n funcie de cardinalitile asociate , n dou
feluri:
prin utilizarea conceptului de cheie strain (regula 2);
prin utilizarea unui nou tabel (regula 3).
Cardinalitile alese la nivel conceptual determin deci
n mare parte structura fizic, fiind necesar o mare
atenie n alegerea lor.

REGULA 4.
Atunci cnd o asociaie binar are dou legturi
de cardinalitate 0,1 sau 1,1 apare o dubl migraie a
identificatorilor entitilor.
Fie urmtorul MCD i corespunztor acestuia
urmtorul MLD.

pagina 142
Sisteme informatice de gestiune

Figura 4.29. Reguli de trecere de la MCD la MLD;


exemplu

n MLD se pstreaz cele dou entiti


provocndu-se n fiecare din ele migrarea reciproc a
identificatorilor. Cnd asociaia binar are dou legturi
0,1 sau 1,1 i o proprietate, atunci asociaia se
transform ntr-un tabel prin trecerea de la MCD la MLD.

REGULA 5.
Aceast regul privete n special entitile
generatoare i entitile specifice. Fie MCD urmtor:

Figura 4.30. Reguli de trecere de la MCD la MLD;


exemplu

pagina 143
Sisteme informatice de gestiune

Exist mai multe posibiliti de a obine MLD din care o


prezentm pe cea mai simpl, adic crearea unui tabel
pentru fiecare entitate, ceea ce se traduce prin migrarea
identificatorului i a proprietilor de la entitatea
generatoare (mam) n fiecare entitate fiic:

Figura 4.31. Reguli de trecere de la MCD la MLD;


exemplu

Atunci cnd entitatea generatoare este n


asociaie cu o alt entitate, apare o combinaie ntre
REGULA 2 i regulile menionate mai nainte, rezultatele
obinute fiind n funcie de cardinalitile asociaiei.

pagina 144
Sisteme informatice de gestiune

4.3.3. Modelul fizic al datelor

Descrierea unui model fizic este strns legat de


sistemul de gestiune a datelor ales. n practic se
ntlnesc frecvent trei tipuri de soluii tehnice:

1. Utilizarea unui sistem de gestiune a fiierelor clasic


avnd ca metod principal accesul secvenial-
indexat.
Fiierele indexat secveniale sau cu index rar
presupun memorarea nregistrrilor ntr-un fiier
numit fiier principal, n ordinea cresctoare a
cheilor i grupate pe pagini. Se adaug un fiier de
index, ce conine pentru fiecare pagin din fiierul
principal cte o nregistrare cu valoarea celei mai
mari chei din pagin i adresa de nceput a paginii.
Fiierul de index este ordonat cresctor n raport cu
valoarea cheii. De cele mai multe ori pagina
corespunde unui bloc, nlnuirea blocurilor n
ordine cresctoare a cheilor permite parcurgerea
secvenial ordonat a fiierului. Atunci cnd n
fiierul de index se gsete acelai numr de
nregistrri cu cele din fiierul principal fiierul se
numete cu index dens. Pentru fiierele de
dimensiuni foarte mari, se poate considera fiierul de
index din organizarea secvenial indexat ca fiier
principal cruia i se ataeaz un fiier cu index rar.
Procednd recursiv pn se obine un fiier index ce
conine un singur bloc, se obine o structur
indexat pe mai multe nivele, foarte flexibil i
eficient, numit structur B-arbore de la denumirea
din limba englez balanced trees.
2. Utilizarea unui sistem de baze de date de tip
CODASYL;

pagina 145
Sisteme informatice de gestiune

Sistemul CODASYL este unul reprezentativ pentru


modelul de organizare tip reea. Acesta se poate
implementa uor prin asocierea a cte unui fiier la
fiecare entitate. nregistrrile fiierului corespund
realizrilor entitii i cmpurile nregistrrii
corespund atributelor entitii. Modelul reea este
apropiat de forma de reprezentare a bazelor de date
sub forma diagramelor entitate-asociaie. Deosebirea
const doar n faptul c toate relaiile ce apar pot fi
numai binare de tipul unu-la-unu i mai-muli-la-
unu. Aceast restricie permite reprezentarea grafic
a unei baze de date de tip reea sub forma unui graf
direcionat numit reea. ntr-o reea nodurile
corespund entitilor i relaiile sunt reprezentate
prin sgei ntre noduri de la tat la fiu. Structura de
reprezentare reea este dezvoltarea structurii
arborescente permind ca orice colecie de date s
aib mai multe colecii de date superioare. O relaie R
de forma mai-muli-la-unu de la entitatea E1 la
entitatea E2 se implementeaz ca o mulime de liste
circulare numite inele avnd capetele n fiierul
asociat lui E2. Un inel de capt e2 aparinnd lui E2
conine toate elementele e1 aparinnd lui E1 care
sunt n relaie cu e2.
Modelul reea este folosit din ce n ce mai puin,
fiind eficient doar n cazul unor baze de date foarte
mari. De aceea acest tip de baze de date nu mai sunt
studiate i dezvoltate.
3. Utilizarea unui sistem de baze de date de tip
relaional.
Modelul relaional se bazeaz pe noiunea
matematic de relaie, aa cum este ea definit de
teoria mulimilor, i anume ca o submulime a
produsului cartezian al unei liste finite de mulimi
numite domenii. Elementele unei relaii se numesc

pagina 146
Sisteme informatice de gestiune

tupluri, iar numrul de domenii (nu toate distincte)


din produsul cartezian se numete aritatea relaiei.
De obicei relaiile sunt reprezentate sub forma unor
tabele n care fiecare rnd reprezint un tuplu i
fiecare coloan reprezint valorile tuplurilor dintr-un
domeniu dat al produsului cartezian. n
reprezentarea sub form de tabel a unei relaii,
coloanelor i respectiv domeniilor corespunztoare
lor li se asociaz nume intitulate atribute. Mulimea
atributelor unei relaii se numete schem
relaional. Un alt mod de a defini relaiile este
urmtorul: prin relaie nelegem o mulime de funcii
definite pe o mulime de atribute cu valori n
reuniunea unor domenii, cu restricia ca valoarea
corespunztoare fiecrui atribut s se afle n
domeniul asociat acelui atribut. Mulimea tuturor
schemelor relaionale corespunzatoare unei aplicaii
se numete schema bazei de date relaionale, iar
coninutul curent al relaiilor la un moment dat se
numete baz de date relaional. n modelul
relaional entitile sunt reprezentate sub form de
relaii n care schema relaional conine toate
atributele entitii i fiecare tuplu al relaiei
corespunde unui element al entitii. La atributele
entitii se pot aduga n relaie i alte atribute
suplimentare utilizate pentru exprimarea relaiilor
ntre entiti.
Descrierea modelului fizic al datelor (MFD) va fi facut
n limbajul sistemului de gestiune corespunztor soluiei
alese. n plus, mediul de dezvoltare va influena i el
foarte mult MFD.

pagina 147
Sisteme informatice de gestiune

4.3.4. Modelul conceptual al comunicaiilor

Acest model, numit i graf actori-flux, permite


descrierea informaiilor schimbate la nivel global n
sistem. Conceptele utilizate sunt:
a) actor.
Se ntelege prin actor tot ceea ce joac un rol n
transmiterea unei informaii i care produce un flux
informaional (pesoan fizic, juridic, cldire, servicii)
Actorii se mpart n dou categorii:
actori interni, care fac parte din organizaie;
actori externi organizaiei sau domeniului studiat.

b) flux.
Un flux este un schimb de bunuri, bani sau
informaii ntre un actor emitor i unul receptor. Se
disting n particular urmtoarele fluxuri:
fluxuri fizice
fluxuri monetare
fluxuri de informaii
Printre fluxurile de informaii, n funcie de natura
suportului se va vorbi de flux informaional oral,
documentar sau informatic. O alt clasificare a
fluxurilor este n funcie de locul emitorului n raport
cu domeniul studiat:
flux intern, atunci cnd este emis de un actor intern
domeniului;
flux extern, atunci cnd este emis de un actor extern
domeniului.

c) ordonarea fluxurilor.
Aceast operaie permite observarea nlnuirii
fluxurilor, putndu-se deosebi fluxurile primare de
fluxurile secundare.

pagina 148
Sisteme informatice de gestiune

d) flux primar.
Un flux primar este un flux care apare la cel mai
sczut nivel organizatoric ntr-un domeniu de gestiune.
ntr-un domeniu contabil, un flux primar va fi de
exemplu un borderou de micri, document situat n
amonte de fluxuri ca jurnalele, cartea mare, balana,
bilanul etc..

e) flux secundar.
Un flux secundar este un flux a crui emisie este
subordonat preexistentei unuia sau mai multor fluxuri
primare sau secundare. De exemplu, emiterea unei
facturi este subordonat recepiei unei comenzi.

f) graful fluxurilor.
Graful fluxurilor este un graf ale crui noduri sunt
actori iar arcele orientate sunt fluxurile schimbate.

Figura 4.32. Modelul conceptual al comunicaiilor


pagina 149
Sisteme informatice de gestiune

4.3.5. Modelul conceptual al prelucrrilor

Prelucrrile constituie partea dinamic a


sistemului informaional. Ele descriu aciunile ce trebuie
executate asupra datelor pentru obinerea rezultatelor
scontate. Prelucrrile nu sunt de fapt dect traducerea
regulilor de gestiune care compun activitatea sistemului
economic. Reprezentarea schematic face apel la
urmtoarele concepte:

1)domeniu.
Noiunea de domeniu n sensul de "domeniu de
gestiune" corespunde unei pri a sistemului care
conine subansamble coerente.
Exemplu: domeniul comercial, domeniul financiar,
domeniul personal.

2)procese.
Procesele reprezint subansamble ale unui
domeniu. Se recurge la aceast mprire atunci cnd
sistemul de studiat este foarte vast.
Exemplu: Domeniul comercial al unei ntreprinderi poate
cuprinde trei procese: urmrire reprezentani, primire
comenzi i urmrire comenzi.

3) operaie.
O operaie este o activitate prin care se produc
fluxuri informaionale. O operaie este definit imaterial,
fr restricii organizatorice. Ea descrie la fel de bine
gestiunea manual ct i pe cea automat.
O operaie poate utiliza una sau mai multe
entiti i/sau asociaii pentru aciuni de creare,
modificare, tergere sau consultare.
O operaie se descompune n aciuni.

pagina 150
Sisteme informatice de gestiune

Exemplu: O operaie n domeniul "Evidena


personalului" ar putea fi "Obinerea adeverinei de
salariu". Simbolul pentru operaie este:

Figura 4.33. Operaie

4) aciune.
O aciune este o funcie elementar. ntre aciunile unei
operaii nu exist ateptare, i derularea lor este
secvenial.
O aciune poate referi una sau mai multe REGULI DE
GESTIUNE
O operaie poate utiliza una sau mai multe entiti
i/sau asociaii
pentru aciuni de creare, modificare, tergere sau
consultare. Simbolul este:

Figura 4.34. Aciune

pagina 151
Sisteme informatice de gestiune

5) reguli de gestiune.
O regul de gestiune este o reglementare care la
nivelul ntreprinderii se va aplica sistematic. Regulile de
gestiune vor servi la definirea ansamblului de reguli care
trebuiesc respectate pentru aciuni. O aceeai regul de
gestiune se poate aplica uneia sau mai multor aciuni.

Exemple:
1. Trebuie aplicat 2% reducere clienilor ale cror
comenzii din anul precedent au depit 4.000.000
lei;
2. Comenzile ctre furnizor trebuie s fie vizate de
ctre eful serviciului aprovizionare.

6) eveniment.
n timpul analizei unei operaii trebuie
ntotdeauna s se pun ntrebarea "care sunt
evenimentele care concur la declanarea unei operaii?".
Un eveniment se definete ca un flux de orice natur,
sau un fapt care permite lansarea unei operaii. Un
eveniment va fi n general desemnat printr-un verb la
participiu document, ci trebuie conservat aspectul
dinamic al descrierii. Se va spune mai bine "comanda
primit" dect "comanda".
Exemple: Cererea unui deviz este un eveniment. Faptul
c suntem n a cincea zi din lun este de asemenea un
eveniment.
Simbolul pentru eveniment este:

pagina 152
Sisteme informatice de gestiune

Figura 4.35. Eveniment

Un eveniment are un nume, un cod, i un alias care


apare ntre paranteze. Se vor distinge:
evenimente declanatoare, care declaneaz o
operaie sub controlul unei condiii de sincronizare;
evenimente rezultate, produse de ctre o operaie ca
urmare a unei reguli de emisie.
Declanarea unei operaii este n general condiionat de
prezena mai multor evenimente declanatoare. Aceste
evenimente nu apar n acelai moment, deci apare
necesitatea condiionrii declanrii operaiei cu o
condiie de sincronizare a evenimentelor declanatoare.
n acelai fel, operaiile, nu genereaz ntotdeauna
aceleai evenimente rezultante. Producerea
evenimentelor rezultante va fi deci supus regulilor de
emisie.

pagina 153
Sisteme informatice de gestiune

Figura 4.36. Evenimente declanatoare i rezultante

Evenimentele 1 i 2 declaneaz o operaie alctuit din


dou aciuni 1 i 2, iar evenimentele 3 i 4 sunt
rezultatul operaiei.

7) condiia de sincronizare.
Condiia de sincronizare este exprimat printr-o
condiie boolean care leag evenimentele declanatoare
prin operaii logice I, SAU, NU. Operaia nu este
declanat dect atunci cnd condiia este ndeplinit.
Este recomandat folosirea alias-ului pentru descrierea
condiiei de sincronizare.
n exemplul din figura 4.37., operaia nu va fi
declanat dect dac evenimentul A se produce n
acelai timp cu evenimentul B sau C.
Dac un singur eveniment este necesar pentru
declanarea operaiei, condiia de sincronizare dispare
din reprezentarea grafic.

8) regula de emisie.
O regul de emisie definete condiia sub care
evenimentele rezultate vor fi produse de ctre o
operaie. O operaie poate avea una sau mai multe reguli
pagina 154
Sisteme informatice de gestiune

de emisie, o regul gestionnd emisia unuia sau a mai


multor evenimente rezultate.

Figura 4.37. Condiia de sincronizare

Figura 4.38. Regula de emisie


pagina 155
Sisteme informatice de gestiune

O operaie poate s nu aib regul de emisie. n acest


caz emisia evenimentelor este necondiionat i se
traduce cu ajutorul cuvntului "totdeauna". O regul de
emisie poate avea un alias pentru uurarea afirii
simbolului operaiei n cazul n care textul care
definete regula este prea lung.

Figura 4.39. Modelul conceptual al comunicaiilor;


Exemplu
pagina 156
Sisteme informatice de gestiune

Evenimentele 1, 2 i 3 declaneaz operaia 1 punndu-


se condiia de sincronizare a I (b SAU c). Operaia 1
este constituit din aciunile 1 i 2 care conduc la regula
2 de emisie. Evenimentele 4 i 5 sunt rezultate
produse de operaia 1.
Operaia 2 compus din aciunea 3 este declanat de
evenimentul 5. Evenimentul 6 este ntotdeauna emis de
operaia 2.

9) reguli de creare a unui MCP.

Crearea unui MCP poate prea uoar la prima


vedere, dar se poate constata c exist tendina de a se
comite dou tipuri de erori:
erori de modelare;
erori de validare a modelului.

10) erori de modelare

Erorile de modelare sunt datorate n general


dificultilor pe care le ntlnim n timpul analizei unui
proces n separarea prii conceptuale de partea
organizaional.
Trebuie s ne amintim tot timpul c MCP trebuie
s exprime ce trebuie fcut, dar nu arat cnd trebuie
fcut i nici unde trebuie fcut (concepte
organizaionale) i nc i mai puin cum trebuie fcut
(concept operaional).
Cu titlu de exemplu s ncercm modelarea
procesului de selecie a unui candidat la ocuparea unui

pagina 157
Sisteme informatice de gestiune

post. Aceast modelare se sprijin pe urmtoarea


prezentare sub form de text.
"La primirea dosarului, un angajat efectueaz
controlul documentelor din dosar. Dup care se studiaz
curriculum vitae-ul redactat de candidat i care face
parte din documentele depuse n dosar. Atunci cnd
aceste controale sunt favorabile, se trimite o convocare
pe adresa candidatului"

Figura 4.40. MCP; Erori de modelare

pagina 158
Sisteme informatice de gestiune

Fr a putea spune c acest model este fals se pot


formula totui urmtoarele observaii:
1. nici un eveniment extern, dup venirea dosarului, nu
justific mparirea prelucrrilor aa de detaliat
(scrisoarea de respingere reprezint de fapt numai
un singur eveniment);
2. s-a inut cont n acest model de o restricie
organizaional, asimilnd o operaie desfurat
ntr-un anumit loc de munc unei operaii
conceptuale;
n general, atunci cnd o serie de operaiuni se
nlnuie fr evenimente externe sau interne justificate
cu adevrat, nu trebuie s aib loc o detaliere a
operaiunilor.
Se poate propune urmtorul MCP:

Figura 4.41. MCP corectat

pagina 159
Sisteme informatice de gestiune

11) erorile legate de validarea modelului.

Dup conceperea unui MCP, este posibil s se


aplice cteva reguli de validare. Aceste reguli,
elementare, fac apel mai ales la bunul sim.

a) Reguli legate de operaiuni.


Cnd s-a plasat o operaie n model trebuie
verificate urmtoarele:
o operaie este un ansamblu de aciuni
nentreruptibile, adic nu sunt supuse ateptrii unor
evenimente. Dac acest lucru nu este posibil, trebuie
folosite mai multe operaii;
o operaie trebuie s fie omogen, adic fr
prelucrri alternative dezechilibrate n interior. O
operaie neomogen poate s ascund producerea
unor evenimente interne neprevzute care ar antrena
mprirea operaiei n mai multe operaii omogene;
trebuie s se obin un rezultat n toate situaiile;
o operaie este ntotdeauna precedat de cel puin un
eveniment;
o regul de emisie trebuie s coexiste ntotdeauna cu
contrariul su (afar de cazul "totdeauna");

b)Reguli legate de condiiile de sincronizare.


Cnd se introduce n model o condiie de
sincronizare, este preferabil s se verifice s nu fie
ntotdeuna fals i s nu existe posibilitatea ca
sincronizarea s fie activat de evenimente care sosesc
la momente diferite, acesta fiind cazul operaiei care
depinde de mai mult dect de un singur eveniment i
cnd operaia este declanat de fapt de sosirea unui
singur eveniment.

pagina 160
Sisteme informatice de gestiune

Figura 4.42. MCP; Sincronizare nerecomandat

Acest tip de operaie nu este recomandat pentru


c prin condiia de sincronizare A SAU B producerea
evenimentului 1 sau a evenimentului 2 va declana
operaia fr nici o ateptare, fapt care contrazice
definiia sincronizrii. n acest sens modelul di
figura 4.43. prezint o anume incoeren pentru c
producerea evenimentului "b" declaneaz imediat i
necondiionat operaia 2, ceea ce nseamn c operaiile
1 i 2 sunt n realitate una singur. Este de preferat n
acest caz modelul din figura 4.44.

pagina 161
Sisteme informatice de gestiune

Figura 4.43. MCP cu incoerene

Figura 4.44. MCP corectat


pagina 162
Sisteme informatice de gestiune

12) reguli legate de funcionarea unui MCP.

MCP nu este numai un model static de


reprezentare a prelucrrilor, dar este n acelai timp un
model dinamic a crui funcionare este supus anumitor
reguli care depind n cea mai mare parte de context. Se
vor aborda numai cazurile n care funcionarea
modelului este imposibil sau nedeterminat, adic vor
fi abordate noiunile de conflict i de ciclu.

a) Noiunea de conflict.
Se spune c exist un conflict relativ la un
eveniment dac acest eveniment contribuie la mai multe
sincronizri. Astfel urmtorul MCP prezint o situaie
conflictual:

Figura 4.45. MCP cu conflict

pagina 163
Sisteme informatice de gestiune

Apariia evenimentului 2 va putea ntr-un mod


nedeterminat s contribuie la activarea operaiilor 1 i 2.
Acest conflict poate fi rezolvat n dou feluri:
cardinalitatea producerii evenimentului 2 este 2 i n
acest caz cele dou apariii ale evenimentului 2 sunt
folosite n cele dou sincronizri;
condiiile de participare ale evenimentului 2 la cele
dou operaii sunt exclusive.

b) Noiunea de ciclu.
Cnd o operaie are ca eveniment declanator un
eveniment pe care ea l produce nemijlocit sau prin
intermediul mai multor operaii, ne gsim n prezena
unui ciclu.
Folosirea ciclurilor, cu condiia s fie valide, este
o tehnic ce permite s se reduc sensibil mrimea
MCP-ului. Un astfel de ciclu (figura 4.46.) este controlat
i condiiile sale de pornire i de terminare trebuie s fie
clare. Astfel pornirea ciclului se face cu ajutorul
evenimentului "start i oprirea se face cu ajutorul
evenimentului "stop". Aceste evenimente nu sunt
fictive, dar corespund n general n practic
evenimentelor care introduc restricii temporale de tipul:
"nti ale lunii, nceputul perioadei, 15 ale lunii ..."

Validarea modelelor.

Validarea modelelor are ca obiectiv sinteza ntre


analiza datelor i analiza prelucrrilor. Ea permite
verificarea ntre MCD i MCP.
Verificarea acestei coerene are ca regul
esenial verificarea ca toate entitile i asociaiile
MCD-ului s fie utilizate de cel puin o operaie a MCP.

pagina 164
Sisteme informatice de gestiune

Figura 4.46. MCP cu ciclu

Entitatea sau asociaia trebuie atunci s fie


asociat unui eveniment declanator sau rezultant, sau
s intervin ntr-o regul de gestiune sau un calcul.
Cnd lipsa coerenei este constatat se poate
interveni asupra MCD. Aceasta se poate traduce prin:

pagina 165
Sisteme informatice de gestiune

adugarea de proprieti care reprezint informaii a


cror necesitate nu a fost banuit;
adugarea de noi asociaii care stabilesc dependene
ntre entiti care nu erau corect precizate.

Asocierea modelului datelor cu modelul prelucrrilor


este unica operaie care permite validarea MCD. Operaia
de validare permite trecerea de la un MCD brut la un
MCD validat.

pagina 166
Sisteme informatice de gestiune

4.3.6. Modelul organizaional al prelucrrilor

Anumite concepte au fost definite la modelul


conceptual al prelucrrilor, deci se vor prezenta numai
conceptele noi specifice MOP.

1) procedura.
O procedur este o succesiune de faze aparinnd
aceluiai proces i executat de actori. Este un
subansamblu al unui proces din MCP decalaat de unul
sau mai multe evenimente.
MOP trebuie s fie stabilit cu grija cci el
constituie prima viziune global i coerent a sarcinilor
efectuate de ctre actori, schimburile dintre actori,
datele la care fac apel actorii i restriciile
organizaionale.

2) actorii.
Un actor este o entitate organizaional
nsrcinat s efectueze un anumit numr de faze. Un
actor aparinnd domeniului studiat este numit actor
intern, iar n caz contrar este numit actor extern. Actorii
sunt coloanele principale n MOP.
O coloan actor dintr-o procedur constituie o
"procedur actor". Astfel fiecare procedur actor trebuie
s pun n eviden contribuia actorului n cadrul unui
proces dat. Procedura actor cuprinde ansamblul
sarcinilor efectuate de ctre un actor, MOP permind
astfel stabilirea lucrrilor executate de fiecare actor.

3) faza.

pagina 167
Sisteme informatice de gestiune

O faz este o nlnuire ninteruptibil de task-uri


cu aceiai periodicitate, executate de un actor intern sau
extern. O faz este reprezentat grafic prin simbolul:

Figura 4.47. Faza

Acest formalism permite s se vizualizeze imediat:


denumirea fazei;
numele prelucrrilor sau task-urilor care compun
faza;
condiiile de sincronizare ale evenimentelor
declanatoare;
regulile de emisie ale evenimentelor rezultante.

n plus, o faz relev caracteristicile urmtoare:


natura sau tipul prelucrrii;
derularea prelucrrii;
locul unde se desfoar.

O faz poate utiliza una sau mai multe tabele ale


unui MLD, pentru consultare, creare, modificare sau
tergere.

4) tipul unei faze.

pagina 168
Sisteme informatice de gestiune

Tipul unei faze este gradul su de automatizare.


O faz este manual sau automat. O faz poate fi n
ntregime automat sau interactiv.

5) derularea unei faze.


Derularea unei faze se caracterizeaz prin
periodicitatea sa i prin durata sa. Pentru durat se va
indica ora de nceput i durata maxim a fazei.

6) locul de desfurare a activitii.


Locul de desfurare a activitii nglobeaz
conceptul de actor cruia i se atribuie caracteristici
organizaionale. Aceste caracteristici sunt tipul locului
de desfurare, responsabilul i resursele.
Tipul locului reprezint ansamblul locurilor unde
aciunile unei operaii conceptuale se pot efectua.
Resursele sunt ansamblul mijloacelor care permit
realizarea anumitor aciuni ale unei operaii. Resursele
pot fi consumabile sau reutilizabile.
Caracteristicile legate de desfurarea unei faze
sunt indicate n coloana "perioad" a MOP iar tipul este
indicat n coloana "tip". Actorul sau locul de desfurare
a activitii relativ la o faza este indicat prin coloana
unde figureaz faza. La fiecare operaie conceptual din
MCP i corespunde una sau mai multe faze.

7) task.

O faz este descompus n task-uri. Un task


reprezint o funciune elementar. Un task poate folosi
una sau mai multe reguli de organizare.
Conceptul de task este foarte important pentru c
el st la baza dezvoltrilor ulterioare.

8) eveniment.

pagina 169
Sisteme informatice de gestiune

Conceptul de eveniment este acelai care a fost


definit n MCP, cu deosebirea c noiunea cuprinde i
alte tipuri de evenimente care mbrac mai ales aspectul
organizaional (introducerea unei comenzi, decizia
superiorului, etc.)
Aceste evenimente, iniiate prin regulile de
organizare, vor avea un efect deloc neglijabil asupra
mpririi operaiilor conceptuale n faze.

9) reguli de organizare.

O regul de organizare decurge dintr-o alegere


organizatoric. O regul de organizare poate fi aplicat
unuia sau mai multor task-uri. Ele corespund adesea
unei reguli de gestiune creia i se d o dimensiune
organizatoric.
Exemplu: O regul de gestiune spune c "orice client
trebuie s fie solvabil". La nivel organizaional, se
mbogeste aceast regul preciznd modul de calcul
prin care s se permit verificarea solvabilitii clientului.
Astfel, orice regul de calcul poate fi o regul
organizaional.

10) modul.

Conceptul de modul permite s se arate cu ce


mijloc (n general informatic) poate s se execute un
task. Un modul const din: un ecran de culegere, un
program de editare, etc..
Un acelasi modul poate fi utilizat de unul sau mai
multe task-uri. Un modul poate utiliza unul sau mai

pagina 170
Sisteme informatice de gestiune

multe tabele ale unui MLD, n consultare, creare,


modificare sau tergere.
Pentru exemplificare prezentm un model ipotetic
privind prelucrarea unor cereri de aprovizionare.

Figura 4.48. Modelul organizaional al prelucrrilor

Reguli de concepere a unui MOP.

MOP poate fi dedus din MCP. Analiza restriciilor


organzaionale condiioneaz n ntregime trecerea de
la MCP la MOP. El se caracterizeaz prin luarea n
pagina 171
Sisteme informatice de gestiune

considerare a restriciilor organizaionale. Se trece ntr-


adevar de la un ansamblu de lucrri finalizate (operaiile
conceptuale), la un ansamblu de lucrri organizate
(task-urile), avnd numeroase restricii organizaionale.
Metoda va consta n analiza restriciilor
organizaionale i n mparirea fiecrei operaiuni
conceptuale.

1) Analiza restriciilor organizaionale.


Analiza restriciilor organizaionale va permite
punerea n eviden a noilor actori i a noilor
evenimente.
Evenimentele unui MOP pot fi conceptuale sau numai
organizaionale. Un eveniment este conceptual dac el
decurge direct dintr-un MCP i este organizaional n
caz contrar.
Evenimentele organizaionale pot fi purttoare
sau nu de date. n cazul n care ele sunt purttoare de
informaii, ele fac obiectul unei descrieri, care va servi la
validarea modelelor de date. n cazul cnd ele nu sunt
purttoare de date, acestea sunt evenimente de tipul
"resurs disponibil" i nu este necesar s se reprezinte
n MOP. n acest caz, se vor regsi n coloana
"perioad" sau "tip".

2) mparirea fiecrei operaiuni conceptuale.


Punerea n eviden a unor noi actori i/sau a
unor noi evenimente va permite mprirea fiecrei
operaii conceptuale n faze. Fiecrei operaiuni
conceptuale din MCP i va corespunde:
o faz unic n MOP; este cazul unei operaii
conceptuale care poate fi complet executat de un
actor ntr-o aceiai unitate de timp.
mai multe faze n MOP; este cazul unei operaii
conceptuale care trebuie s fie mparit n mai

pagina 172
Sisteme informatice de gestiune

multe subansamble de periodiciti diferite pentru


unele aciuni sau o mprire rezultnd dintr-o
restricie organizatoric.

Pentru mai buna descompunere a unei operaii


conceptuale, este necesar s se procedeze la o analiz
ascendent plecnd de la rezultate spre evenimente.
Astfel, o operaie conceptual d ntotdeuna cel
puin o faza de producere a unui rezultat. Eventual, dac
sunt necesare calcule prea lungi pentru producerea
rezultatului se poate defini o faz de calcul specific. Se
vor distinge attea faze de achiziie de date cte fluxuri
informaionale necesit o introducere de date.
Ansamblul fazelor astfel obinute, prin
descompunerea procedurii funcionale, pot fi eventual
din nou combinate dac:
la ele nu particip dect un singur actor;
nu necesit dect resurse identice;
nu au loc dect n acelai moment;
nu sunt supuse unei ateptri de natura
organizaional.

n cursul descompunerii unei operaii conceptuale, este


frecvent obinerea unei faze care a fost deja
determinat anterior. n acest caz nu se va reine dect o
singur faz.
Se constat c metoda nu const n analiza
restriciilor organizaionale i apoi mprirea fiecrei
operaii conceptuale, ci mai curnd mprirea operaiilor
n acelai timp cu analiza restriciilor organizaionale.
Orice faz trebuie s fie caracterizat de o unitate
de loc, o unitate de timp i o unitate de resurse.
Validarea modelelor are ca obiectiv sinteza ntre
analiza datelor i analiza prelucrrilor. Ea permite

pagina 173
Sisteme informatice de gestiune

verificarea coerenei ntre MLD i MOP. Verificarea


acestei coerene se efectueaz la dou niveluri:
toate tabelele din MLD sunt necesare;
orice coloan din MLD este utilizat de cel puin o
operaie din MOP.
Coloana trebuie s figureze la un eveniment declanant
sau rezultant, sau s intervin ntr-o regul
organizatoric.
Un al doilea nivel mult mai detaliat care verific
dac accesul la o tabel este necesar n raport cu
obiectivele task-ului care se efectueaz.
Cnd se constat o lips de coeren poate fi
necesar intervenia n modelele de date i chiar
modificarea la nivelul MCD. Aceasta se poate traduce
prin:
adugarea de proprieti care reprezint informaii a
cror necesitate nu a fost bnuit; aceasta poate
conduce la o anumit denormalizare a modelului de
date;
adugarea de noi asociaii care stabilesc dependene
ntre entiti care nu erau corect precizate;
adugarea la nivelul MLD a unor noi indeci care
asigur timpi de rspuns mai bun.

pagina 174
Sisteme informatice de gestiune

4.3.7. Modelul operaional al prelucrrilor

Scopul modelului operaional al prelucrrilor


(MOpP) este de a descrie arhitectura programelor care
vor fi realizate pornind de la fazele descrise n MOP.
Aceste programe vor fi: programe "batch" sau programe
de prelucrare a tranzaciilor (pentru faze n "timp real").
Se recomand respectarea ctorva reguli n funcie de
tipul programelor. Astfel pentru programele "batch":
mprirea acestora dup periodicitatea de
prelucrare;
mparirea dup tipul de prelucrare (validare,
calcul,actualizare, editare)

Pentru prelucrarea tranzaciilor se recomand


urmtoarele reguli:
fiecrui ecran i va corespunde o tranzacie;
fiecare tranzacie va fi structurat n afiare ecran,
introducere date, prelucrare ecran (normalizare
I.S.O.);
stabilirea normelor ergonomice pentru afiarea
ecranului i introducerea datelor;
mprirea prelucrrilor n validri, calcule,
actualizri i editri;

Descrierea nivelului operaional al prelucrrilor va


evolua foarte mult n urmtorii ani prin utilizarea
limbajelor de baze de date ca SQL i prin generalizarea
programrii orientate pe obiecte.

pagina 175
Sisteme informatice de gestiune

4.4. Ciclul de decizie

Ciclul de decizie cuprinde toate deciziile luate pe


parcursul desfurrii proiectului, mai generale la
nceput i apoi din ce n ce mai precise. Deciziile globale
trebuie luate de directorul general, dar la fiecare nivel
trebuie consultat personalul implicat. Ierarhia deciziilor
care se pot lua este urmtoarea:
mprirea sistemului informaional n domenii;
orientrile generale n ceea ce privete gestiunea,
organizarea i soluiile tehnice;
planificarea dezvoltrii;
alegerea ntre procedurile manuale i automate;
alegerea procedurilor ce se vor executa n timp real;
determinarea locurilor de munc i a sarcinilor
respective;
conceperea ecranelor, listelor, etc.

n responsabilitatea conducerii cade n mod normal


iniierea proiectului i ulterior terminrii acestuia
evaluarea reuitei proiectului. Aceast observaie ne
duce spre ideea c o corect abordare a ciclului de
decizie trebuie nceput de la nivelul sistemului
informaional, prin mprirea sistemului n zone de
interes i prin stabilirea orientrilor generale.
Totodat trebuie fcut o diferena ntre
atitudinea decizional pasiv, care las lucrurile s
evolueze n mod natural i o politic managerial
consecvent n direcia informatizrii.

Din constantrile practice se observ o etapizare


"natural" n introducerea prelucrrii automate a datelor.

pagina 176
Sisteme informatice de gestiune

Aceast etapizare depinde de condiiile obiective


existente n economie:
starea tehnologiei hardware;
starea tehnicilor de rezolvare a problemelor
fundamentale;
riscul pe care-l implic deficienele de organizare.
Dei tehnologia hardware este uniform n cea
mai mare parte a lumii, tehnica rezolvrii problemelor
fundamentale, variaz de la industrie la industrie i de
la ntreprindere la ntreprindere.
Valoarea riscului pe care-l implic, deficienele de
organizare variaz de la caz la caz. Pragul de la care o
anumit activitate devine riscant este o problem
subiectiv i se stabilete n funcie de nivelul acceptat al
probabilitii de producere a evenimentelor nefavorabile.
Dar miza depirii eventualelor dificulti este
mare deoarece un succes mai nsemnat realizat de o
ntreprindere va strni un ecou rapid n rndul celorlalte.
Etapizarea ptrunderii calculatoarelor ntr-o
ntreprindere, sintetizat pe baza mai multor constatri
practice este urmtoarea:
1. aplicaii de baz ale calculatoarelor;
2. aplicaii intradivizionare ale calculatoarelor;
3. aplicaii interdivizionare ale calculatoarelor;
4. aplicaii avansate ale calculatoarelor.

Aceast etapizare nu presupune o intervenie


coordonat n direcia informatizrii. Bineneles c n
cazul unei opiuni ferme de realizare a unui sistem
informatic se va putea aborda direct etapa final n
utilizare a calculatoarelor.
1. Prima arie de aplicaii ntr-o ntreprindere
productiv este aceea n care se cere un efort individual,
sau cel mult, cooperarea ntre grupuri mici.

pagina 177
Sisteme informatice de gestiune

Ca rezultat, aplicaiile iniiale sunt limitate la


proiecte de proporii i complexiti reduse. n plus
hard-ul se alege dintre cele mai ieftine alternative, din
cauza tendinei normale de limitare a riscului financiar
n introducerea unei tehnologii noi i nu prea cunoscute.
Accentul n primele aplicaii se pune pe nlocuirea
muncii umane n activiti de sortare, raportari scrise i
rezolvri de ecuaii.
2. O alt etap este aceea cnd se utilizeaz
personalul dintr-un singur compartiment i este
caracterizat prin ntreinerea i punerea la zi a fiierelor
i printr-un nivel mai ridicat al complexitatii.
Aplicaiile includ state de plat, stocuri, registre
contabile generale, balane, calculul dividentelor,
evidena mijloacelor fixe, etc..
3. Cea de-a treia etap se caracterizeaz prin
ncercarea de rezolvare a unor probleme economice care
cer un numr limitat de cooperari ntre sectoare.
Exist un interes crescnd pentru optimizarea
sistemelor complexe i de regul, majoritatea
ntreprinderilor urmresc s ctige maximum prin
optimizarea planificrii i utilizrii echipamentelor
electronice.
Dup cum sarcinile de lucru cresc pentru
echipamentele de calcul ale intreprinderii, exist
tendina de a favoriza aplicaiile mai urgente, astfel
nct apar cozi de ateptare n vederea punerii la punct
a celorlalte aplicaii. O rezolvare a acestei probleme este
descentralizarea responsabilitilor de calcul.
n aceast etap se ncearc i cteva din
aplicaiile cele mai simple de comand a proceselor de
producie. Comanda proceselor i-a ctigat o larg
apreciere n industriile unde produsele sunt elaborate fie
n flux continuu sau proces intermitent i unde controlul
permanent al materiei prime, mpreun cu controlul

pagina 178
Sisteme informatice de gestiune

condiiilor de funcionare, determin mbuntirea


produselor i reducerea cheltuielilor de producie.
4. La sfritul etapei a treia devine clar pentru
multe ntreprinderi c apropierea treptat de rezolvarea
problemei i de pstrarea nregistrrilor nu ine pasul cu
cerina ntreprinderii pentru informare i rspuns. Un
rspuns la aceast problem este implementarea unui
sistem informatic integrat. n industriile care au o
producie de mas, cu utilizarea unei tehnologii
omogene, aceste sisteme pot fi introduse fr prea mari
dificulti. Totui, majoritatea ntreprinderilor productive
au o tehnologie extrem de diversificat n ceea ce
privete primirea comenzilor, achiziionarea de materii
prime, distribuirea, depozitarea i mecanismul de
desfacere. Un element simplu ce exemplific
eterogenitatea schimburilor de informaii este numrul
de formulare diferite utilizate n interiorul ntreprinderii.
Cu toate c aceste sisteme sunt deseori denumite
sisteme informatice de conducere, elementul lor comun
este necesitatea unei baze de date integrate.

n opoziie cu atitudinea pasiv se afl aciunea


contient prin care strategia ntreprinderii trebuie s
beneficieze de o serie de orientri generale care s-i
permit ctigarea unor avantaje competitive. n acest
sens modelul urmtor permite corelarea scopurilor
ntreprinderii cu avantajele poteniale dar i cu efortul
necesar.
Conductorul este pus aadar n faa unei
probleme foarte importante i deloc uoar. Este evident
c are nevoie de o tehnologie informatic, dar care
aplicaii informatice din cele existente sau dintre cele
oferite pe pia au o importan strategic i pot
influena n mod decisiv potenialul firmei? El trebuie s
tie cnd tehnologia informatic este un element critic

pagina 179
Sisteme informatice de gestiune

pentru ntreprinderea sa. O cale posibil pentru o


investigaie de acest fel o constituie Modelul strategic tip
gril (The Strategic Gril Model; Figura 4.49.) care permite
determinarea importanei i impactului strategic prin
situarea firmei ntr-un cadran cu dou dimensiuni:
impactul strategic al sistemelor existente;
impactul strategic al dezvoltrii sistemelor (sistemele
viitoare)
n cadranul 1 suport (de sprijin) sistemele
informatice sunt vzute ca avnd un impact redus
asupra activitii firmei i tind s rman aa i n viitor.
Dependena activitii firmei de sistemele informatice
este considerabil sczut. Tehnologia informatic este
perceput ca un sprijin funcional fr s implice
investiii semnificative i sunt coordonate de la un nivel
ierarhic mijlociu i sczut.
n cadranul 2 factory (de fabricaie) dei
sistemele informatice sunt importante n afacerile firmei
ele nu sunt n centrul dezvoltrii strategice. Un posibil
exemplu l-ar putea constitui o ntreprindere n care
producia este condus prin sisteme de control n timp
real dar viitoarele dezvoltri ale sistemului informatic nu
vor influena semnificativ activitatea firmei.
n cadranul 3 turnaround (revenire) sistemele
informatice nu au fost foarte importante n trecut dar
realizarea de noi sisteme a nceput s devin critic
pentru activitatea viitoare a firmei. Firma realizeaz
aceast schimbare de optic nu numai datorit unei
creteri a activitii ci mai ales pentru meninerea pe
pia ntr-un mediu economic perturbat. Se poate
exemplifica acest situaie cu o ntreprindere n care
planurile de dezvoltare sunt puternic legate de
tehnologia informatic.

pagina 180
Sisteme informatice de gestiune

Figura 4.49. Modelul strategic grila

n cadranul 4 strategic se reprezint firmele a


cror activitate depinde n mod critic de existena
sistemelor informatice. O performan sczut ori
cderea acestor sisteme poate fi cauza unor
disfuncionaliti majore. Mai mult, dezvoltarea
sistemului informatic este critic pentru activitatea
firmei i trebuie s cad n sarcina conducerii executive
a firmei. Rolul important al tehnologiei informatice este
remarcat i de volumul semnificativ de investiii din
acest domeniu. Exemple de firme din acest cadran sunt
bncile, companiile de asigurri, firme de brokeraj,
ziare, institute de cercetri de marketing, etc. Situarea
ntreprinderii n acest cadran trebuie s vizeze lanul

pagina 181
Sisteme informatice de gestiune

producie-desfacere, existnd posibilitatea ca diferite


alte activiti s se gseasca n celelalte cadrane.
Acest model permite o privire static asupra
prezentului i viitoarei dependene de sistemele
informatice. De altfel este important de urmrit micarea
n timp n interiorul grilei. Trecerea din cadranul suport
n strategic se poate face sub presiunea progresului
tehnologic, a competiiei de pe piaa sau a unor noi
obiective n dezvoltarea firmei.

La fel de important este aciunea conductorului


i la nivelul dezvoltrii componentelor sistemului
informatic, cu observaia c n acest caz este vorba de o
conducere de nivel inferior. O proast conducere poate
afecta succesul proiectului mai mult dect ali factori,
dar acest fapt, n mod surprinztor, este mai puin
neles n procesul de dezvoltare a software-ului. Toate
modelele anterioare ale ciclului de via nu trateaz
conducerea ca un model distinct ci privesc conducerea
proiectului ca o parte inseparabil a procesului de
dezvoltare a software-ului.
Pentru clarificarea acestui aspect s-a recurs la
urmtoarele diagrame care evidenieaz implicarea
factorului de conducere n realizarea proiectului. (Figura
4.50.)
La acest nivel de prezentare condiia iniial este
iniierea proiectului i rezultatul este proiect realizat.
Resursele reprezint tot ceea ce s-a consumat pentru
realizarea proiectului. Pentru furnizarea mai multor
amnunte aceast diagram poate fi detaliat pentru
ase etape ale ciclului de via al proiectului: analiza
preliminar, proiectarea logic, proiectarea tehnic,
construcia, implementarea i testarea.

pagina 182
Sisteme informatice de gestiune

Figura 4.50. Conducerea proiectului

n figura 4.51. este prezentat modelul conducerii


procesului pe parcursul ciclului de via al sistemului.
Modelul este numit model comportamental sau model
de conducere pe baz de evenimente. El arat strile n
care se poate afla sistemul i este folosit pentru
descrierea dependenelor, pentru alocarea resurselor i
pentru finanare.
Dreptunghiurile reprezint stri sau grupuri de
stri legate ntre ele n diferite moduri, iar intrrile i
ieirile sunt evenimente care permit tranziia de la o
stare la alta. Strile, permit conductorului de proiect
comunicarea i msurarea activitiil asociate proiectului
n dezvoltare. Se observ c evenimentele sau condiiile
de ieire asociate strilor sunt stabilite pentru ca
managerul s tie cnd o anumit faz este complet
astfel nct s poat ncepe urmtoarea.

pagina 183
Sisteme informatice de gestiune

Figura 4.51. Conducerea proiectului pe etape ale


ciclului de via

AC (Asigurarea Calitii) reprezint semnalul prin


care care s se garanteze c produsul se conformeaz
unor standarde IEEE Standard for Sofware Quality.
Calitatea produsului const n totalitatea trsturilor sau
caracteristicilor sale care i permit s se conformeze
necesitilor utilizatorului. Controlul calitii const n
aciunile necesare pentru msurarea caracteristicilor
produsului i compararea lor cu specificaiile. Calitatea
nu poate fi testat n produs dar ea trebuie s fie
construit n interiorul produsului. Procesul trebuie s
nceap din primele etape i s continuie pn la
fritul ciclului de via, pentru c fiecare etap
constituie o nou ocazie pentru alte tipuri de erori.
CM (Componena Managementului) este aspectul
care permite identificarea n timp a acelor puncte pentru

pagina 184
Sisteme informatice de gestiune

efectuarea contrulului modificrilor, pentru


monitorizarea integritii i trasabilitii produsului pe
parcursul ciclului de via. Aceasta permite
conductorului s cunoasc ce s-a fcut, ce se
realizeaz acum i cu ce se va continua mai departe.
V+V (Verificarea i Validarea) se refer la ct de
bine produsul corespunde din punct de vedere
funcional, al cerinelor de performan i al interpretrii
corecte a cerinelor. Punctul principal al verificrii i
validrii este clientul adic dac ceea ce i s-a furnizat
corespunde cerinelor sale.

Aa cum s-a vzut din cele prezentate


conducerea proiectului este activitatea care traverseaz
ntregul ciclu de via. Conductorul trebuie s fie atent
n deciziile luate, trebuie s posede informaiile corecte
pentru luarea deciziilor i s nu ia decizii compensatorii
atunci cnd s-a greit. Mai mult chiar, conducerea
proiectului nu implic numai manipularea resurselor
bani i timp ci i a resursei umane.
n procesele de decizie, chiar n stabilirea
obiectivelor intervin puternic motivaiile personale i
interpersonale. Complexul de atitudini, motivaii,
intentii, stri afective etc. constituie mpreun
"comportamentul uman" care trebuie avut n vedere de
conductor n cele dou accepiuni ale sale:
factorul uman din interiorul echipei de proiectare;
comportamentul uman din sistemul studiat ca obiect
de analiza al echipei de proiectare.

pagina 185
Sisteme informatice de gestiune

V. Abordri orientate spre date i prelucrri

Ralizarea unui sistem informaional-decizional


performant este rezultatul unui cumul de factori. Este
cert c nu factorii individuali sunt cei cu influen
hotrtoare ci ansamblul interaciunii lor. Acest
ansamblu de factori trebuie analizat i modelat n aa fel
nct s se obin performana maxim. Dac prin
extensie spunem c modelarea efectuat pentru
realizarea sistemului este ea nsi un factor, putem
afirma c ntr-adevr acesta este unul important.
Modelarea situaiei existente sau a celei dorite trebuie s
fie capabil s reprezinte realitatea la un moment dat
dar i s se poat adapta la modificrile pe care ea nsi
le preconizeaz.
Analiznd modelele de reprezentare a realitii
propuse de metoda Merise, se observ dou tipuri de
reprezentare.
Prima este bazat pe postulatul c un sistem trebuie
s realizeze anumite funcii (existena unui material
n stoc, nlnuirea etapelor pentru construcia unei
case, etc. ). Aceast abordare este cea a
descompunerii funcionale.
A doua se preocup de faptul c un sistem informatic
este un sistem de relaii ntre entiti. Spre exemplu
se descrie un individ ca un ansamblu compus dintr-
un nume, unul sau mai multe prenume, un cod
numeric personal i avnd unul sau mai muli copii.
n acelai sens o cas este un ansamblu de fundaii,
perei, ui i ferestre.

pagina 186
Sisteme informatice de gestiune

Sosirea
Sosirea
buldozerului muncitorilor

Pregatirea buldozerului Pregatirea echipei


verificarea combustibilului verificarea prezentei
verificarea prezentei sofer repartizarea sarcinilor
incalzirea motorului

Inceput Inceputul
activitate lucrului
buldozer echipei

Beton
disponibil
Saparea fundatiilor
sapatura bruta
finisaj sapatura
non OK OK

Sapatura
Anuntare terminata
proiectant

Turnarea betonului
pregatire cofraj
pregatire armatura
turnare beton
asteptare intarire
Terminare turnare fundatii

Figura 5.1. Exemplificare cu modelul conceptual al


datelor

pagina 187
Sisteme informatice de gestiune

Descompunerea funcional i propune s abordeze


sistemul ca un prestator de servicii care s rspund la
anumite ntrebri. De exemplu Ci clieni au fost
vizitai de la nceputul lunii?. Furnizarea rspunsului
presupune desfurarea unei serii de aciuni:
determinarea primei zi lucrtoare din lun, gsirea
clienilor vizitai de la acea dat i pn la zi i afiarea
rezultatului. Funcia gsirea clienilor vizitai de la
nceputul lunii i pn la zi se descompune ea nsi n
acces la fiierul de clieni, selecionarea numrului de
clieni vizitai ncepnd de la acea dat, eliminarea
clienilor vizitai de dou ori, etc.. Acest demers ar prea
natural n msura n care ar reproduce ceea ce face un
salariat cruia i se pune aceast ntrebare. Se poate
distinge o dubl aciune.
O mprire temporal prin care sarcinile trebuiesc
ndeplinite unele dup altele. n exemplul dat nu pot
fi selectionai clienii nainte de stabilirea primei zi
lucrtoare din lun. Aceast dimensiune temporal
pune n relief secvenialitatea sarcinilor i
sincronizarea lor.
mprirea procedurilor n subproceduri prin care
sarcinile globale sunt mprite n activiti care pot
fi din nou mprite la rndul lor. Procesul se repet
pn cnd sarcinile elementare sunt suficient de
simple.

Descompunerea funcional va fi exemplificat cu


ajutorul modelului conceptual al prelucrrilor din
metoda Merise.
Indiferent de modaliatea practic de realizare a
diagramei funcionale particularitatea acestei abordri
const n urmrirea unei aplicaii prin toate trasformrile
pe care le exercit asupra datelor. Este vorba de o
structurare a prelucrrilor. Analiza prin descompunerea

pagina 188
Sisteme informatice de gestiune

funcional permite s se gsesasc sub-proceduri


comune, putndu-se atunci s se construiasc o singur
procedur care va fi utilizat de mai multe ori n mai
multe locuri. Avantajul const n faptul c a fost scris o
singur dat iar eventualele modificri se vor face ntr-
un singur loc aplicndu-se tuturor funciilor la care
procedura comun particip.
Ca o alternativ la structurarea prelucrrilor s-a
lansat spre sfritul anilor 80 analiza structurilor de
date. O problem este reprezentat printr-un sistem de
relaii dintre elementele care-l compun. Abordarea se
canalizeaz spre definirea elementelor de model i spre
stabilirea reelei de relaii care le leag.
Prezentarea acestui sistem de relaii se face cu ajutorul
diagramei entitate-relaie. Entitile reprezint fiine sau
obiecte purttoare a anumitor proprieti iar relaiile
reprezint interaciunile dintre entiti. O relaie se
poate exprima printr-o fraz al crui complement sunt
entitile iar verbul este relaia dintre ele. Pentru
exemplificare s-a folosit modelul conceptual al
prelucrrilor din metoda Merise pentru aceiai problem
a construciei unei case.
Figura 5.2. introduce noiunea de cardinalitate
(un ofer face parte dintr-o echip i numai una iar ntr-
o echip pot fi zero sau mai muli oferi) dar spre
deosebire de structurarea prelucrrilor situaia
prezentat de diagrama entitate-relaie este static (se
prezint datele dar nu se precizeaz dac ele sunt n
micare sau n repaus). Diagrama entitate-relaie
explic ce sunt fundaiile i ce este necesar pentru a le
construi dar nu explic maniera prin care se poate face.
Tot pe lista minusurilor se poate aduga, c unui singur
model i corespunde un numr infinit de realizri
posibile exprimndu-se un ansamblu de relaii posibile
fr a se impune un sens de lectur.

pagina 189
Sisteme informatice de gestiune

Sofer
nume Echipa
1,1 face parte
0,n sef de echipa
numar de membrii
0,1
0,n

conduce
definit de

1,1
0,n
Buldozer
numar sapa Groapa
1,n
1,n locul in teren
adancimea
suprafata
0,1

construita

1,1
Fundatia Cofraj
cod cofrata tip
1,1 material
data terminarii 0,1
suprafata marca beton

Figura 5.2. Exemplificare cu modelul conceptual al


prelucrrilor

Pe de alt parte modelul este recunoscut ca durabil n


msura n care reprezint realitatea fundamental a
domeniului de activitate modelat i este extrem de
adaptabil. nlocuirea unui ef de echip sau introducerea
unei noi maini ( entiti) cu ajutorul creia se vor spa
gropile nu schimb major sistemul.

pagina 190
Sisteme informatice de gestiune

Abordrile orientate spre date i spre prelucrri


i au rdcina n dou sisteme de gndire diferite:

Analiza prin prelucrri i gsete sursa n noiunea


de metod n sensul n care aceasta i propune s
rezolve o problem printr-un cadru procedural.
Acest cadru fixeaz etapele i nlnuirea lor astfel
nct intrrile i ieirile corespund fiecrei etape.
Aceast gndire este esenialmente cartezian i
analiza prin structura prelucrrilor este legat de
acest curent de gndire.
Analiza structurilor de date studiaz problema
modelrii punndu-se accentul pe relaiile dintre
elementele din model. Aceast abordare este cea
inaugurat de coala sistemic. Software-ul este
nainte de toate conceptualizat ca un component al
sistemului de organizare global al ntreprinderii.
Conceperea sa ncepe prin analiza definirii sistemului
i a frontierelor sale.

Trebuie remarcat totui c nsi metoda de dezvoltare,


procesul sau metodologia, pune n eviden o abordare
cartezian chiar dac aceasta se refer preponderent la
o modelare orientat spre structurarea datelor.
Ceea ce trebuie remarcat este faptul c aceste dou
concepte au stat la baza metodelor actuale de
proiectare. Cu toate c metoda MERISE realizeaz prin
modelele de date i prelucrri o dubl abordare a
sistemului, persist totui unele inconveniente.

Fazele de studii sunt prea lungi i neproductive.


mprirea lucrului ce decurge din abordarea prin
sarcini specializate i din ciclul de concepie n V fac
dificil obinerea de rezultate notabile. Aceast
abordare impune o nelegere global a concepiei

pagina 191
Sisteme informatice de gestiune

anterioare programarii. Adesea pn cnd grupul de


studii s termine caietul de sarcini necesitile s-au
schimbat iar n proiectele de o anumit dimensiune
lungimea fazelor face foarte posibil frecventa
schimbare a analitilor. Presiunea este foarte mare la
nceputul proiectului, atunci cnd deciziile cele mai
importante trebuiesc luate plecndu-se de la un
minim de elemente. Deci, abordrile tradiionale sunt
caracterizate printr-o dificultate ridicat o primelor
etape cnd orice eroare poate avea consecine grave.
Comunicarea este dificil mai ales cu
neinformaticienii. Implicarea utilizatorilor n proiect
este adesea dificil, principala dificultate constnd n
formularea cerinelor ntr-un format propriu
modelrii. Comunicarea n sens invers nu este nici
ea mai uoar, pe de o parte din cauza necunoaterii
de ctre client a limbajului informatic dar mai ales
datorit necunoaterii suportului de comunicaie. De
la un anumit nivel de complexitate verificarea
diagramelor entitate-relaie i de structurare a
prelucrrilor de ctre un neinformatician devine
imposibil.
Abordrile orientate spre date i funciuni sunt
ireconciliabile. Analiza structurii datelor permite
obinerea de programe mai evoluate dar ea nu
permite reprezentarea scopului aplicaiei a ceea ce
utilizatorul atepta de la ea. Trebuie deci ca mai
trziu s se descrie aceasta prin modelarea
prelucrrilor. Din aceast cauz n marile proiecte
era necesar o dubl abordare. O echip trebuie s
se ocupe de structurarea datelor i alta de serviciile
pe care sistemul urmeaz s le ofere utilizatorilor,
adic de structurarea prelucrrilor. Problememle cu
adevrat dificile apar la integrarea datelor cu
prelucrrile n procesul de realizare dar mai ales n

pagina 192
Sisteme informatice de gestiune

faza de mentenan cnd apare frecvent fenomenul


de regresie. Acesta const n faptul c modificarea
prelucrrilor ntr-o zon a aplicaiei afecteaz datele
utilizate de ntreg sistemul. Se poate demonstra c
aceast problem decurge tocmai din contradicia
dintre date i prelucrri.

Abordarea prin prelucrri impune ca o funcie


utilizat n mai multe locuri s nu existe dect
ntr-un singur exemplar. n arborescena
programului ea va fi ridicat ctre vrful
arborescenei pentru a putea fi utilizat de
toate celelate funcii care o apeleaz.
Securitatea datelor impune ca accesul la ele s
fie fcut de un numr minim de funcii. Deci
atunci cnd o dat este modificabil de mai
multe proceduri este imposibil de a gsi
originea modificrilor. Exist deci tendina de
coborre a funciei de acces pentru a evita
modificrile intempestive.
Aceste considerente au stat la baza nateri unei noi
abordri, numit orientatat obiect, care are la origine
rezolvarea problemelor de simulare. ntr-o astfel de
abordarea nu mai este vorba de analiza funciilor sau de
studierea relaiilor dintre elemente ci mai curnd de
situarea n interiorul lor reproducnd comportamentul la
anumite evenimente. Din aceast abordare se nate
conceptul de obiect ca entitate ce reacioneaz singur
i este independent. Dei metoda MERISE preia unele
aspecte ale abordrii obiectuale rmne n sarcina
viitoarelor cercetri integrarea real a conceptului
obiectual.

Bibliografie.

pagina 193
Sisteme informatice de gestiune

(1) Gh. Boldur Lescu, Gh. Ciobanu, I. Bncil -


"Analiza sistemelor complexe"; Editura tiintific i
enciclopedic Bucureti 1982
(2) I.Roca, E.Macovei, N.Davidescu, V.Rileanu
Proiectarea sistemelor informatice financiar-contabile
Editura didactic i pedagogic Bucureti 1993
(3) Dumitru Oprean "Metode i tehnici utilizate n
realizarea sistemelor informatice" Editura Dacia 1980
(4) Mihai Pun, 1997, Analiza sistemelor
economice,Ed.All
(5) C. Georgescu - "Suport de curs - Proiectarea
sistemelor informatice"; Facultatea de tiinte economice
i administrative; februarie 1995
(6) A. Benabdelhafid, E.Reppert - " Elements de
conceeption D'un systeme de logistique integree";
Congres "Merise et les autres" 5-7 octobre 1994,
Versailles
(7) Robert N. Carette - "Software Engineering
Environments - Concepts and technology" ; Intertexty
Publications, Inc. McGraw-Hill,Inc. New york 1986
(8) Joseph Gabay "Apprendre et pratiquer
MERISE" Paris, Editions MASSON 1993
(9) Joseph Gabay "MERISE - etudes des cas"
Paris, Editions MASSON 1991
(10) Tawfik Jelassi - "Competing through
information technology - Strategy and implementation";
Prentice Hall Publishing, November 1994.
(11) H. B. Maynard - "Manual de inginerie
industriala"; Editura tehnica 1975
(12) Jean-Patrick Matheron "Comprendre MERISE"
Paris, Editions EYROLLES , 1987, 1990

pagina 194