Myslide - Es - Sisteme Informatice de Gestiune 561e72c9a5c9c PDF

S-ar putea să vă placă și

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; noţiuni generale
1.2.-Conceptul de analiză sistemică
2.Sisteme informaţionale
2.1.-Comunicarea în sistemele informaţionale
2.2.-Fluxuri de informaţii
2.3.-Locul şi rolul sistemului informaţional
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
întreţinerea
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 comunicaţiilor
4.3.5. –Modelul conceptual al prelucrărilor
4.3.6. –Modelul organizaţional al prelucrărilor
4.3.7. –Modelul operaţional al prelucrărilor
4.4. –Ciclul de decizie
5.Abordări orientate spre date şi spre prelucrări
Bibliografie
pagina 5
Sisteme informatice de gestiune

1. ABORDAREA SISTEMICĂ

1.1. Sistem; noţiuni generale

Conceptul de sistem apare în forme embrionare


în filosofia antică greacă. Afirmând că "întregul este mai
mult decât suma păţilor", Aristotel dă o primă definiţie
noţiunii 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 lucrări ce
postulează că "universul este organizat în sisteme şi
ansambluri de elemente aflate în interacţiune" ş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 mulţi cercetători.
Un sistem poate fi definit ca o secţiune a realităţii
în care se identifică un ansamblu de fenomene, obiecte,
procese, fiinţe sau grupuri, interconectate printr-o
mulţime de relaţii reciproce, precum şi cu mediul
înconjurător şi care acţionează în comun în vederea
realizării unor obiective bine definite.
Caracteristic pentru noţiunea 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 funcţie de scopul urmărit.

pagina 6
Sisteme informatice de gestiune

Mulţimea relaţiilor dintre componentele unui


sistem precum şi relaţiile între componente şi ansamblu
formează structura sistemului, iar mulţimea
caracteristicilor unui sistem, la un moment dat,
determină starea sa.
Relaţiile dintre elemente se analizează observând
şi studiind logic funcţiile şi mecanismele lor individuale.
După precizarea acestor funcţii şi mecanisme, orice
soluţie avută în vedere poate fi evaluată pentru întregul
sistem, tinând seama de diverse criterii de eficienţă şi de
restricţiile practice asociate elementelor funcţionale.
Elementele unui sistem pot avea relaţii între ele
(relaţii endogene) cât şi relaţii cu mediul înconjurător
(relaţii exogene).
Ca urmare, pentru a caracteriza noţiunea de
sistem este necesar să punem în evidenţă următoarele 5
laturi:
• mulţimea elementelor
• relaţiile între elemente -relaţii endogene
• intrările şi ieşirile în şi din sistem-relaţii exogene
• caracterul variabil în timp al elementelor sistemului
• scopul, finalitatea sistemului
Pentru descrierea unui sistem şi a evoluţiei sale se
asociază "starea sistemului" care este un şir de variabile,
un vector ale cărui componente variabile în timp permit
cunoaşterea sistemului în orice moment.
Folosind vectorul de stare al sistemului, şi vectorii
de intrare, ieşire, comandă etc. se poate asocia
sistemului un sistem de ecuaţii 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, făcând abstracţie de
procesele sale interne.

pagina 7
Sisteme informatice de gestiune

Cutia neagră primeşte impulsuri din mediul


înconjurător (intrările) şi le transformă în acţiuni asupra
mediului (ieşirile).
Mecanismul transformării intrărilor în ieşiri poate
fi descris cu ajutorul unor funcţii care au diverse forme
particulare, în funcţie de natura sistemului.
Sistemul devine "cibernetic" atunci când apare
reglarea (conexiunea inversă sau feedback-ul).
În 1948 matematicianul american Norbert Wiener
prin publicarea lucrării sale fundamentale "Cybernetics",
pune bazele acestei ştiinte a controlului şi comunicării.

Figura 1.1. Sistem cibernetic

Fie sistemul S definit prin vectorul intrărilor X şi


prin vectorul ieşirilor Y; transformarea intrărilor în ieşiri
se poate descrie în mod simplificat prin aplicarea
operatorului liniar F.

Y=FX

Mărimile Y ale ieşirilor se compară cu vectorul


obiectivelor propuse Z şi întrucât de cele mai multe ori
apar abateri (Y#Z) este necesară intervenţia unui
pagina 8
Sisteme informatice de gestiune

"regulator" R care va genera mărimea de reglare Δx, cu


rolul de a aduce ieşirile 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 conducător". Traducând în termenii
prezentaţi anterior, subsistemul condus este sistemul S
iar subsistemul conducător este regulatorul R. Dată fiind
proprietatea sistemelor de a putea fi împărţite în
subsisteme care la rândul lor se pot diviza în alte
subsisteme s.a.m.d., în continuare se va folosi noţiunea
de subsistem numai în cazurile când este necesară
punerea în evidenţă a relaţiei de incluziune într-un alt
sistem.
Din punct de vedere al modului cum se
analizează ieşirile (reacţiile) sistemului condus şi al
modului cum se generează mărimile 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 conducător emite o


decizie D fară a cunoaşte reacţia sistemului condus la
această decizie.
Sistem închis controlat.

Figura 1.3. Sistem închis controlat

În acest caz în urma deciziei D a sistemului


conducător, sistemul condus furnizează informaţia I ca o
reacţie la decizia D.

Sistem controlat autoreglabil univariant.

Figura 1.4. Sistem controlat autoreglabil univariant.


pagina 10
Sisteme informatice de gestiune

Sistemul controlat apare atunci când între forma


primară a deciziei D preconizată de sistemul conducător
şi forma realizată de sistemul condus nu este o
concordanţă perfectă.
În acest caz conducătorul luând în considerare
diferenţele între ce s-a preconizat şi ce s-a realizat
intervine cu noi decizii pentru a determina sistemului
condus să se conformeze deciziei iniţiale D.

Sistem controlat autoreglabil bivariant.

Figura 1.5. Sistem controlat autoreglabil bivariant

Dacă în urma unor perturbaţii conducătorul


reevaluează decizia sa primară poate să preconizeze o
formă modificată a obiectivului iniţial. Sistemul este
bivariant pentru că pe parcursul realizării deciziei atât
forma iniţială cât şi cea finală s-au modificat.

pagina 11
Sisteme informatice de gestiune

1.2. Conceptul de analiza sistemică

Ţinându-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
uşor de stăpânit, toate componentele sunt considerate
în ansamblul lor ("aspect spaţial") atât pe parcursul
analizei, proiectării cât şi al procesului de conducere
("aspect temporal").
De fapt, numai în acest fel este posibil să se
înţeleagă şi să se anticipeze corect comportarea posibilă
a sistemului.
O caracteristică esenţială a abordării sistemice
este accentul pe care îl pune, în cazul analizei, pe
interdependenţele dintre elementele sistemului şi pe
observarea critică a calităţii acestora.
Abordarea sistemică, s-a dovedit de mare utilitate
în rezolvarea problemelor mari şi complexe, referitoare
la oameni şi maşini. Abordarea sistemica este o noţiune
care reuneşte trei activităţi importante:
• analiza sistemelor
• proiectarea (ingineria) sistemelor
• conducerea sistemelor.
Analiza de sistem poate fi considerată un mijloc
de abordare a cercetării, 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 următoarelor


etape:
1.Prima etapă constă în formularea problemei. Pentru
toate lucrările ulterioare este important ca
analistul să examineze critic formularea problemei
de către 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 incompatibilităţi de limbaj. Orice
eroare minoră în formularea problemei sau orice
înţelegere eronată poate genera mari inconveniente
prin amplificarea ei cu fiecare etapă parcursă.

2.De asemenea este deosebit de important să se


examineze minuţios formularea obiectivelor pentru
că în acest domeniu sunt posibile inconsecvente:
"să se maximizeze eficienţa concomitent cu
încadrarea în cheltuielile minime".

3.Adeseori în optimizarea sistemelor apar dificultăţi


cauzate de faptul că este greu sau chiar imposibil
să se analizeze întreaga problemă. Se poate
recurge în astfel de situaţii la optimizarea fiecărui
subsistem analizat, dar sistemul în întregul său nu
poate fi decât suboptimal fiind necesară deci
precizarea clară a limitelor problemei.

4.Analiza cerinţelor utilizatorului constă în


identificarea şi evaluarea necesităţilor lui reale.

5.Precizarea criteriilor de măsurare a eficienţei


sistemului trebuie făcută înainte de evaluarea
soluţiilor propuse prin stabilirea unui grup de
mărimi reprezentative.

pagina 13
Sisteme informatice de gestiune

6.Analiza funcţională se concretizează într-o listă


amănunţită a funcţiunilor şi aprecierilor care
trebuie îndeplinite. La analizele funcţionale o
deosebită importanţă o are reprezentarea grafică în
scheme bloc.

7.Pe masură ce se completează lista restricţiilor care


acţionează asupra sistemului devine posibilă
cercetarea efectelor interacţiuni lor asupra
întregului sistem. Identificarea restricţiilor şi
evaluarea efectului lor asupra eficienţei sistemului
reprezintă un alt aspect important.

8.Pe măsura avansării în analiza sistemului se


conturează diferitele soluţii posibile care satisfac
restricţiile impuse. Obiectivul acestei faze este de
a identifica diversele variante fără a adâncii
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ă posibilităţi
de dezvoltare ulterioară.
9.După precizarea variantelor posibile se trece la
compararea şi evaluarea acestora. Este de dorit ca
atât cheltuielile cât şi eficienţa să fie exprimate
baneşte.

Proiectarea sistemelor este un proces de


concepţie tehnică, asociat de obicei cu dezvoltarea sau
cu modificarea importantă a unui sistem.
Acest proces se împarte în:
• proiectarea propriuzisă a sistemelor şi
• proiectarea operării sistemelor

pagina 14
Sisteme informatice de gestiune

Proiectarea propriuzisă a sistemelor se împarte la rândul


ei în:
• proiectarea preliminară
• proiectarea de detaliu

La proiectarea preliminară se evaluează soluţiile


de proiectare a transpunerii specificaţiilor funcţionale
precizate în faza de analiză a sistemului şi apoi se
selectează soluţia de proiectare.
Proiectarea de detaliu cuprinde transpunerea
concepţiei de proiectare, conturată în faza de proiectare
preliminară în specificaţii de detaliu. Este necesară în
această fază împărţirea lucrărilor pe echipe dar totodată
trebuie să existe un grup de integrare a sistemului care
să se ocupe exclusiv de problema asigurării
funcţionalităţii corespunzătoare a fiecărui subsitem nu
numai în parte ci şi în cadrul sistemului în ansamblu.

Un aspect oarecum neglijat în tehnica sistemelor


este proiectarea operării 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 eşecul unui sistem tot atât de
mult ca şi proiectarea lui defectuoasă. Operarea
sistemelor este uneori neglijată din cauză că proiectanţii
sunt în mod firesc mai interesaţi să soluţioneze
problemele tehnice ale proiectării şi în mai mică masură
problemele legate de limitele fizice şi psihice ale
personalului operaţional şi de întreţinere. În plus
concepţia de a adapta omul la maşină a creat obiceiul
de a angaja pentru operare şi întreţinere acei oameni
ale căror însusiri fizice şi psihice pot fi considerate
compatibile cu caracteristicile echipamentului. Pe
măsura sporirii complexităţii sistemelor, trebuie

pagina 15
Sisteme informatice de gestiune

acordată o atenţie deosebită noţiunilor de fiabilitate şi


mentenabilitate.

Conducerea sistemelor cuprinde stabilirea metodologiei


şi a structurilor organizatorice pentru planificarea,
directivarea şi controlul activităţilor de proiectare a
sistemelor ca şi pentru funcţionarea lor. Conducerea
funcţionarii sistemelor se numeşte "conducere
operaţională".
Pe de altă parte există conducerea însăşi a proiectării
sau dezvoltării sistemului.
Conducerea sistemelor nu reprezintă o fază a
proiectării sistemelor ci este funcţiunea de comandă şi
control care se desfăşoară de-a lungul ciclului de viaţă
al sistemului. Cea mai mare contribuţie la eficienţa
conducerii unui sistem o are identificarea momentelor şi
criteriilor de efectuare a controlului, astfel încât să se
poată stăpânii desfăşurarea activităţilor. Pe lângă
controlul corespunzător principalelor etape conducerea
trebuie să efectueze o permanentă urmărire şi
coordonare. Acest sistem de control poate fi mai eficient
dacă:
• se realizează previziuni asupra evoluţiilor viitoare;
• se planifică reexaminări periodice ale proiectelor.
Integrarea sistemului şi controlul configuraţiei sunt
două activităţi de conducere care trebuie să-şi
dovedească prezenţa pe parcursul fiecărei faze a
proiectării sistemelor. Pentru integrarea sistemului
conducerea trebuie să asigure compatibilitatea
mecanică, electrică, etc. dar şi compatibilitatea
informaţională.
Controlul configuraţiei constă din metodele
folosite pentru a orienta şi urmării modificările î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ă
cunoaşterea sistemului, cunoaştere care se traduce
printr-o reprezentare la nivel cerebral a sistemului în
ansamblul său. De fapt prin analiza s-a transpus
realitatea mai întâi î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
realităţii nu este deloc uşoara şi presupune în mod
obligatoriu participarea activă a beneficiarului
sistemului.

pagina 17
Sisteme informatice de gestiune

2. SISTEME INFORMAŢIONALE

2.1. Comunicarea în sistemele informaţionale

Noţiunea de informaţie este complexă şi de mare


generailitate. La momentul apariţiei sale, conceptul de
informaţie a suscitat dispute filosofice pe tema
caracterului material al acesteia. Norbert Winer spunea:
" Informaţia este informaţie, nu este materie sau
energie."
Informaţia este un tip deosebit de raport între
procesele materiale, raport ce nu există în afara acestor
procese. Se poate afirma că informaţia reprezintă un
atribut fundamental al materiei alături de masă, câmp şi
substanţă. Informaţia ca atribut fundamental al materiei
este prezentă atât în materia vie (informaţia genetică)
cât şi în cea nevie .
Pentru determinarea riguroasă a cantităţii de
informaţie se foloseşte un aparat matematic bazat pe
elemente din teoria probabilităţilor.
Fie un experiment X rezultatele sale pun în
evidenţă un număr finit de evenimente elementare
independente x1,x2,..,xn, având asociate probabilităţile
de realizare p1,p2,...,pn. Presupunem că experimentul X
reprezintă un sistem complet de evenimente, adică prin
efectuarea sa se va obţine cu siguranţă unul din
evenimentele xk Є X , deci Σpk = 1 ; k=1,..,n. Realizarea
unui eveniment înlătură o cantitate de nedeterminare,
deci întrucât informaţia reprezintă o nedeterminare
înlăturată sensul variaţiei nedeterminării este inversul

pagina 18
Sisteme informatice de gestiune

sensului variaţiei informaţiei, unitatea de măsură fiind


aceiaşi.
Notând cu H(X) măsura gradului de nedeterminare,
care este egală cu cantitatea medie de informaţie
furnizată de realizarea unui eveniment se poate scrie:

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

În anul 1948 Claude Shannon în lucrarea "Teoria


matematica a comunicaţiei" a dat expresia cantităţii de
nedeterminare (şi deci a informaţiei):

Shannon a preluat cercetările unui precursor al


său în domeniul teoriei informaţiei R.V.Hartley care încă
din anul 1928 a introdus noţiunea de cantitate de
informaţie, definind-o astfel:"Informaţia obţinută 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. Relaţia stabilită de Hartley se obţine ca un caz
particular din formula lui Shannon atunci când
evenimentele sunt echiprobabile;

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

Măsura informaţiei calculată cu formula lui Shannon se

pagina 19
Sisteme informatice de gestiune

numeşte şi ENTROPIE INFORMAŢIONALĂ prin analogie cu


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

Transferul informaţiilor, deciziilor, datelor şi


cerinţelor între diferite procese şi/sau între diferite
sisteme sau subsisteme creează o problematică
complementară cantităţii de informaţie: problema
COMUNICARII.

Fie:

Figura 2.1. Modelul comunicării

unde:
E - este emiţătorul de informaţie
R - este receptorul de informaţie
C - este canalul de comunicaţie
Caracterul esenţial 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 spaţiu şi timp ale suportului său, sau ale
canalului de transfer (lungimea cuvântului, suprafaţa
unui disc, a unui tablou, numărul de semne imprimate),
dar mai ales de improbabilitatea ocurenţei (apariţiei)
sale, adică de combinaţia pe care o realizează. Această
cantitate de noutate sau originalitate transportată de la
E la R se adaugă la sistemul de cunoştinţe şi de

pagina 20
Sisteme informatice de gestiune

experienţă pe care îl au atât E cât ş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 funcţie de
frecvenţa de întrebuinţare; în pasul următor vom
deduce probabilitatea lor de apariţie (de ocurenţă) şi, în
consecinţă, informaţia pe care ele o transportă.
Informaţia depinde deci de repertoriul comun atât
al transmiţătorului cât şi al receptorului. Această masură
presupune faptul că mesajul este decompozabil în mod
obiectiv într-o serie de semne identificabile şi
enunţabile.
Procesul fundamental al comunicării între
emiţător şi receptor prin intermediul unui canal fizic
înseamnă:

• a găsi semne care pot fi recunoscute într-un


repertoriu prin intermediul unui canal fizic;
• a găsi semne care pot fi recunoscute într-un
repertoriu deţinut de emiţător;
• a le aduce şi ale transmite prin ceea ce numim un
canal de comunicaţie;
• identificarea de către receptor a fiecărui semn pe
care îl primeşte cu cele pe care le are deja în propriul
său repertoriu.

Comunicarea ideilor nu are loc decât în măsură în care


cele două repertorii au o parte comună. Pe măsură ce
acest proces continuă în procesele dotate cu memorie şi
cu estimare statistică, cum este cazul inteligenţei
umane, percepţia semnelor mereu identice vine să
modifice din ce în ce mai mult în repertoriul
receptorului, căruia îi este subordonat. Este vorba de
sistemul de învăţare.

pagina 21
Sisteme informatice de gestiune

În comunicare emiţătorul creează o formă, o


imagine, o idee, pe care o codifică apoi în momentul
emisiei. La rândul său, receptorul, plecând de la mesaj
construieşte o altă formă. Calitatea comunicării se
măsoară prin indentitatea dintre forma percepută şi
forma creată.
Leibnitz a arătat că orice mesaj poate fi
considerat o alegere între o mulţime de cazuri posibile,
alegere care se poate transforma într-un număr suficient
de mare de dileme succesive. Fiecare dintre aceste
alternative, fiecare din aceste alegeri între două
posibiliăţti care se exclud (da-nu; 0-1), dacă ele sunt
egal probabile pentru receptor, reprezintă o unitate de
informaţie sau BIT (binary digit: cifră binară sau
problemă binară). Avem astfel o unitate de măsură a
informaţiei începând cu numărul de dileme susceptibile
a defini mesajul fară ambiguitate.
Receptorul uman nu este capabil să sesizeze
decât o cantitate limitată de originalitate pe unitatea de
timp, adică un anume debit de informaţie, funcţie de
canalul de percepţie (văz auz, pipăit, telepatie, etc.)
Caracterul optim al mesajelor nu este dat de
maximul de informţie ci de maximul de impact adică de
probabilitatea de a înţelege, deci de a proiecta forme
asupra mesajului primit.
E necesar aici un exces, o risipă de semne, şi
apare o altă mărime numerică, legată de mesaj, care
joacă un rol important în comunicaţie: REDUNDANŢA.
Ea înseamna excesul relativ al numărului de
semne faţă de cel care ar fi fost strict necesar pentru a
transmite aceiaşi cantitate de originalitate.

pagina 22
Sisteme informatice de gestiune

Figura 2.2. Alegerea optimului de redundanţă

Orice mesaj poate fi caracterizat prin conţinutul


său de informaţie şi poate să se situeze într-un punct
definit al unei scări care merge de la banalitatea totală
până la originalitatea totală.
Redundanţa variază deci în raport invers
proporţional cu informaţia. Inteligibilitatea unui mesaj
este legată de redundanţa 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 funcţie de caracteristicile receptorului.

Fie:
pagina 23
Sisteme informatice de gestiune

Figura 2.3. Comunicarea în prezenţa perturbaţiei

unde:
E - este emiţătorul de informaţie
R - este receptorul de informaţie
C - este canalul de comunicaţie
P - este perturbaţia

Modelul matematic al unui sistem de transmitere


a informaţiei este format din două mulţimi finite X, Y şi
o probabilitate condiţionată p(y|x), definită pe Y pentru
orice x Є X. X este mulţimea simbolurilor care se emit iar
Y mulţimea simbolurilor ce se recepţionează.
Probabilitatea p(y|x) se numeşte probabilitatea de
recepţie condiţionată de ceea ce se emite şi
caracterizeză perturbaţia existentă pe canalul
sistemnului respectiv. A cunoaşte canalul de
comunicaţie înseamnă a cunoaşte probabilităţile p(y|x)
pentru toate simbolurile x Є X şi y Є Y.
Mărimea H(X|Y) reprezintă cantitatea medie de
informaţie necesară pentru a se recepţiona mulţimea Y
şi depinde de probabilitatea condiţionată p(x|y), care la
rândul ei, este determinată de probabilitatea p(y|x) ce
caracterizează perturbaţia pe canal.
Nedeterminarea H(X|Y) apare datorită
perturbaţiei; ea este preţul pe care trebuie să-l plătim
pagina 24
Sisteme informatice de gestiune

perturbaţiei pentru ca să putem recepţiona semnalele y


Є Y.
Dacă H(X|Y) reprezintă cantitatea medie de
informaţie care se pierde pe canal şi dacă de la sursa se
transmite o cantitate de informatie H(X), la recepţie va
ajunge numai cantitatea de informatie

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

Mărimea denumită CAPACITATEA CANALULUI este


dată de relaţia:

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

si ea pune în evidenţă cantitatea de informaţie care


poate să circule în mod util prin canalul dat.
Diferenţa H(X) - H(X|Y) raportată la uinitatea de timp se
mai numeşte viteză de transmitere a informaţiei.
Capacitatea canalului este deci viteza maximă de
transmitere a informaţie pe canalul respectiv.

pagina 25
Sisteme informatice de gestiune

2.2. Fluxuri de informaţii

Fie graful G0(X,L) unde:


X este mulţimea elementelor şi
L este legea de corespondenţă (mulţimea 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.
• Mulţimea punctelor { x1,x2,...,xl } din mulţimea X
desemnează un DRUM de lungime L dacă perechile
{ xi,xi+1 } sunt laturi;
• Distanţa între două puncte ale unui graf este egală cu
lungimea căii celei mai scurte dintre ele.
Pe acest graf G0(X,L) se defineşte un alt graf numit GRAF
INFORMAŢIONAL G1(X,C).
Între cele două grafuri există o deosebire: legea de
corespondenţă. În timp ce G0 reglementează relaţiile
organizatorice G1 reglementeză relaţiile informaţionale.
Laturile grafului G1 se numesc CANALE
INFORMAŢIONALE. În mulţimea {C} a canalelor
informaţionale se pot defini două submulţimi:

C1={c Є C|c=canal pur informaţional}


C2={c Є C|c=canal decizional}

Pe mulţimea {C} putem defini mulţimea {F} a fluxurilor.


Fluxul este acea cantitate de informaţie care circulă pe
un canal. El poate fi:
• informaţional
• decizional
DRUM INFORMAŢIONAL este succesiunea de arce
adiacente ce permit trecerea fluxului informaţional de la
un nod la altul.

pagina 26
Sisteme informatice de gestiune

LUNGIMEA UNUI DRUM INFORMAŢIONAL este dată de


numărul de arce din care este format. Drumul poat fi:

• deschis (numai informaţional)


• închis (informaţional - decizional)

Tipuri de fluxuri informaţionale. Fie un flux F(A,B) unde


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

• când informaţia circulă de la un nivel organizatoric A


inferior la un nivel superior B, fluxul se numeşte
ascendent.
• când informaţia circulă de la A la B şi ele sunt pe
acelaşi nivel organizatoric, fluxul se numeşte
orizontal.
• când informaţia circulă de la A situat la un nivel
organizatoric superior la B aflat pe un nivel
organizatoric inferior, fluxul se numeşte descendent.
• când A şi B aparţin aceluiaşi sistem S, fluxul F(A,B)
se numeşte intern.
• când A sau B nu aparţin sistemului S fluxul se
numeşte extern.
• când conţinutul, direcţia şi periodicitatea fluxului
sunt prestabilite, fluxul se numeşte periodic.
• când nici conţinutul nici periodicitatea nu sunt
reglementate, fluxul se numeşte de moment sau
întâmplător.

pagina 27
Sisteme informatice de gestiune

2.3. Locul şi rolul sistemului informaţional

Circulaţia informaţiei din momentul producerii


unui eveniment în procesul condus şi până când pe baza
cunoaşterii lui, se declanşează un nou eveniment
precum şi precizarea conţinutului informaţiei,
destinaţiei, locului stocării, etc. alcătuiesc sistemul
informaţional.
Totalitatea metodelor, tehnicilor, mijloacelor,
privite ca ansamblu integrat care asigură înregistrarea,
culegerea, transmiterea, prelucrarea şi valorificarea
informaţiilor de orice natură definesc sistemul
informaţional.
Un sistem informaţional se crează şi se dezvoltă
odată cu organismul sau activitatea pe care o reflectă.
Într-un sistem economic sistemul informaţional
asigură legătura în ambele sensuri între sistemul condus
sau de execuţie şi sistemul conducător sau decizional
(Figura 2.4.).
Orice sistem economic presupune existenţa unei
componente operaţionale care poate fi orice sistem de
producţie de bunuri sau servicii.
Sistemul condus asigură desfăşurarea activităţilor
specifice sistemului în vederea realizării obiectivului
global pentru care a fost creat.
Sistemul condus se compune din ansamblul
actorilor operaţionali din întreprindere şi care:

• utilizează informaţiile prezente în sistemul


informaţional;
• utilizează regulile de comportament din sistemul
informaţional.

pagina 28
Sisteme informatice de gestiune

Figura 2.4. Locul sistemului infirmaţional

Spre exemplu un vânzător dintr-o societate care


se ocupă cu vânzări prin corespondenţă, primeşte o
comandă telefonică de la un client nou. Sistemul
informaţional este acela care:
• îi furnizează informaţia că este vorba de un client
nou;
• îi furnizează regula de acţiune care se traduce prin
aplicarea unui comision de 10% asupra vânzărilor.
Astfel sistemul operaţional adaugă o nouă
informaţie în sistemul informaţional (numele clientului,
adresa clientului, etc).
Sistemul conducător asigură previziunea
comanda, organizarea, coordonarea şi controlul
desfăşurării activităţilor î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 utilizând informaţiile prezente în sistemul
informaţional. Sistemul conducător intervine asupra
sistemul informaţional în sensul adaptării la obiectivele
şi la strategia întreprinderii, modificând natura
informaţiilor şi regulile de comportament.
Spre exemplu conducerea unei bănci decide ca
clienţii săi să nu mai fie consideraţi ca persoane ci ca
gospodării (familii) ceea ce duce la schimbarea naturii
informaţiei.
O societate decide să schimbe modul de facturare
prin editarea facturii pe calculator în momentul
prezentării clientului. Rezultă de aici o acţiune asupra
regulilor de comportament, facturarea actualizând stocul
fără a mai fi nevoie de o procedură ulterioară.
Prin situarea sa între sistemul conducător şi
sistemul operaţional sistemului informaţional asigură
următoarele funcţiuni:
• culegerea datelor care consemnează realitatea
economică din cadrul proceselor operaţionale.
• preluarea informaţiilor de la alte sisteme şi împreună
cu cele din sistemul operaţional să asigure
prelucrarea, valorificarea şi arhivarea lor.
• obţinerea şi transmiterea către conducerea proprie şi
către organele supraordonate a informaţiilor
necesare fundamentării deciziilor sau a urmăririi
efectelor acestora.
• transmiterea de informaţii de rutina altor procese
informaţionale.
• preluarea şi transmiterea fără modificări a deciziilor
care provin de la organele supraordonate către
procesul decizional propriu.

pagina 30
Sisteme informatice de gestiune

Figura 2.5. Sistemul informaţional

Având în vedere caracterul dinamic al sistemului


economic, în mod obiectiv şi sistemul informaţional
trebuie să fie într-o continuă adaptare şi perfecţionare.
Elemente ale sistemului economic pot reprezenta
perturbaţii pentru sistemul informaţional dar acesta fiind
un sistem cibernetic există posibilitatea adaptării şi
funcţionării celor două sisteme în concordanţă.
În sistemul informaţional privit ca sistem
cibernetic conexiunea inversă o constituie :
• deciziile pentru menţinerea echilibrului sistemului
economic în ansamblu;
• deciziile luate de conducerea subsistemului
informaţional pentru buna funcţionare şi
perfecţionare a acestuia.
Reacţia inversă se concretizează prin informaţia
economică necesară conducerii sistemului economic atât
pentru fundamentarea deciziilor cât şi pentru urmărirea
efectelor acestora.
pagina 31
Sisteme informatice de gestiune

Sistemul informaţional are caracter cibernetic şi


datorită faptului că are capacitatea de autoreglare astfel
încât el este întotdeauna în concordanţă cu sistemul
economic pe care îl reflecta.

Figura 2.6. Sistemul informaţional; sistem cibernetic

Funcţiile de previziune, organizare, coordonare şi


control, atribute ale sistemului conducător, 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ă stăpânirea


fluxurilor informaţionale din şi spre sistemul condus, şi
care să permită conducerii sesizarea problemelor ce pot
să apară în viitor.
Întreprinderea este pusă în situaţia de a prelucra
toate aceste fluxuri informaţionale şi de a-şi alege
propria cale din mult mai multe variante pe care le are la
dispoziţie.
Aceste posibilităţi complexe de acţiune se traduc
printr-un nivel mai mare al fluxurilor informaţionale
care intră şi ies din întreprindere, fluxuri care trebuie
analizate şi controlate de conducerea întreprinderii.
Deciziile elaborate trebuie să stea la baza conturării mai
multor variante de evoluţie care să cuprindă simultan
criterii de timp, băneşti şi de performanţă.
Apare în acest caz o situaţie potenţială 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 definiţia sistemului informaţional reiese că


obiectivul global urmărit este tratarea şi valorificarea
informaţiei 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ă.
Deşi la început calculatorele electronice erau
folosite în exclusivitate pentru calcule tehnico-ştiintifice,
începând 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 apărut odată cu
utilizarea calculatoarelor electronice în realizarea
proceselor informaţionale.
Pentru definirea sistemului informatic prezentăm
un set de trei definiţii unanim acceptate, dar care pun
accentul pe una sau alta dintre trăsături, completându-
se reciproc.

• Atunci când în sistemul informaţional 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
prelucrării informaţiilor destinate desfăşurării
procesului de conducere, în scopul asigurării unei
eficienţe cât mai mari a activităţii economico-sociale
respective.

• Partea componentă a sistemului informaţional prin


care se asigură, pe baza folosirii tehnicii de calcul şi
în primul rând a calculatoarelor electronice, tratarea
raţională a datelor şi a informaţiei, cu eficienţă
sporită, constituie un sistem informatic.

În timp ce prima definiţie pune accentul pe


aspectul tehnic, adică pe utilizarea calculatoarelor, cea
de-a doua vizează aspectul de organizare şi
raţionalizare a circuitului informaţiilor destinate
conducerii.
Ultima definiţie este cea care reuneşte cele două
aspecte subliniate de primele definiţii adăugând şi
relaţia de incluziune a sistemului informatic în sistemul
informaţional.
Sistemul informatic se asociază obligatoriu unui
sistem informaţional şi este subordonat unui proces
decizional. Prin tratarea datelor cu tehnica de calcul
sunt eliminate erorile de informare care se
repercutează negativ asupra calităţii desfăşurării
activităţilor.
Sistemul informatic, ca parte a sistemului
informaţional, trebuie structurat ca sistem cibernetic cu
două bucle de reglaj. Bucla principală de reglaj reflectă
principalele influenţe cu mediul înconjurător: legăturile
cu băncile, cu beneficiarii, etc. Bucla secundară este ca
o buclă de autoreglaj care face faţă în principal

pagina 35
Sisteme informatice de gestiune

perturbaţiilor 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 condiţiile unei orientări a activităţii spre piaţă,
strategia întreprinderii poate suferi modificări
substanţiale, în funcţie de situaţiile conjuncturale
apărute. Dacă, în urma unor perturbaţii de acest fel,
conducătorul reevaluează decizia sa primară (planul
iniţial), poate să preconizeze o formă modificată a
obiectivului iniţial. În acest caz, când pe parcursul
realizării deciziei, atât forma iniţială cât şi cea finală s-
au modificat, putem vorbi despre sistemul informatic ca
despre un sistem bivariant.
Sistemul informatic este format, în esenţă, din
următoarele categorii de elemente:

1. calculatoare electronice şi alte echipamente


2. metode şi tehnici de tratare a datelor şi a informaţiei
3. colecţii 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, atât la nivelul elaborării
programelor de activitate, cât şi pe parcursul executării
lor.
Un sistem informatic este conceput prin
colaborarea dintre specialişti din domenii conexe iar
realizarea unui sistem informatic este un proces
complex, de durată şi care necesită activităţi specifice
de analiză, proiectare, programare şi implementare.

pagina 36
Sisteme informatice de gestiune

Sistemul informaţional trebuie să devină, prin


introducerea sistemului informatic, instrument de
reglare şi autoreglare a sistemului economic. Obiectivul
global urmărit este creşterea fiabilităţii sistemului
economic studiat.
Din activitatea practică de realizare a sistemelor
informatice se desprind următoarele 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 documentaţiilor orientate către
beneficiar într-un limbaj accesibil acestuia;
• aprobarea de către beneficiar a tuturor
propunerilor făcute în proiect;
• responsabilitatea viitorului utilizator pentru
implementarea sistemului, pentru corectitudinea
datelor folosite şi pentru pregătirea personalului
necesar exploatării sistemului;

2. Problema cheie este cea a oamenilor nu a


echipamentelor, şi în special a analiştilor-proiectanţi
de sisteme, specialişti care au o influenţă hotărâtoare
asupra modului de realizare a sistemelor.
3. Sistemele informatice trebuiesc justificate din punct
de vedere cantitativ şi calitativ, deoarece reprezintă
investiţii importante.
4. Realizarea sistemului informatic este un proces
iterativ, ceea ce înseamnă că întâi trebuie stabilit
numai cadrul general, detalierea făcându-se apoi
treptat, în mai multe iteraţii.
5. Când nu putem să planificăm 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 urmărite şi reactualizate planificările


iniţiale pe măsura realizării sistemului. De asemenea,
trebuie acordată o deosebită atenţie modului de
etapizare a lucrărilor şi mărimii etapelor pe care vrem
să le realizăm.
6. Procedurile manuale sunt la fel de importante ca şi
programele, de corecta lor proiectare depinzând
durata de implementare şi modul de funcţionare a
sistemului.
7. Trecerea de la vechiul sistem la noul sistem este ea
însăşi un sistem şi de aceea trebuie tratată cu mare
atenţie. 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ă documentaţie î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 informaţional este un proces
complex. Analistul de sistem trebuie să parcurgă o serie
de etape şi să rezolve o mulţime de probleme.
Analiza de sistem înseamnă cunoaşterea
sistemului, cunoaştere care se traduce printr-o
reprezentare la nivel cerebral a sistemului în ansamblul
său. De fapt prin analiză s-a transpus realitatea mai întâi
î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
realităţii nu este de loc uşoară şi presupune participarea
activă a tuturor membrilor echipei de proiectare dar şi a
beneficiarului sistemului într-un context uman, material
şi organizatoric, propice realizării 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
aplicării metodelor.
Când vorbim despre procesul de reorganizare a
unui sistem informaţional, trebuie să descriem un model
care să prevadă ceea ce va apărea în procesul de
dezvoltare. Această etapizare va arăta ce trebuie făcut,
cum va fi realizat, când va fi terminat şi cine va folosi
ceea ce s-a realizat.
Un bun model al procesului de prelucrare trebuie
să respecte trei cerinţe principale.
• Trebuie să aibă o mare putere descriptivă, putând să
descrie esenţialul în mod realist.

pagina 39
Sisteme informatice de gestiune

• Trebuie să permită descrierea însuşi a procesului de


dezvoltare şi a modului de conducere a dezvoltării
procesului.
• Trebuie de asemenea să acopere cazurile
neprevăzute şi schimbările 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 număr 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ă constând în parcurgerea unor etape numite
"faze". (Figura 4.1.)

1. Analiza cerinţelor. Definirea şi analiza necesităţilor


utilizatorului.
2. Specificaţia. Translaţia cerinţelor într-o descriere
generală a sistemului.
3. Proiectarea. Crearea unei abstractizări a sistemului în
concordanţă cu specificaţiile anterioare.
4. Implementarea. Crearea sistemului care
implementează ceea ce s-a proiectat.
5. Testarea. Determină dacă implementarea satisface
cerinţele.
6. Mentenanţa. Modificarea sistemului necesară pentru
a fixa problemele apărute. 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 (puţine detalii) la un
nivel mai scăzut de abstractizare (mai multe detalii). Cu
toate că există o bogată experienţă şi tradiţie în
aplicarea cu succes a modelului, există unele probleme.
În primul rând modelul nu este suficient de descriptiv
în ceea ce priveşte activităţile care interferă prin toate
fazele ciclului de viaţă cum ar fi: conducerea proiectului,
asigurarea calităţii, verificarea şi validarea. Spre exemplu
o eroare de specificare poate să nu fie descoperită decât

pagina 41
Sisteme informatice de gestiune

foarte târziu, şi este extrem de greu de revenit la faza la


care s-a produs eroarea.
În al doilea rând modelul a fost dezvoltat într-o
perioadă când sistemele de mici dimensiuni şi cu
arhitectură compactă erau dominante.
În ultimul rând modelul nu se pretează la
transpunerea sa pe calculator. El a fost dezvoltat într-o
perioadă când proiectarea asistată de calculator nu era
deloc înţeleasă.

Modelul INCREMENTAL (RAPID-PROTOTYPING).

Acest model (al prototipizării rapide) a fost creat


pentru a acoperi deficienţele modelului WATERFALL cu
care se aseamănă din mai multe puncte de vedere.
Diferenţa 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 conţine un plus de funcţiuni. Produsul final
nu este văzut ca un sistem monolit livrabil integral la o
singură dată, ci este realizat şi livrat dintr-o serie de
etape succesive corespunzătoare fiecărei iteraţii. Numai
la sfârşit sistemul este disponibil integral, dar până
atunci fiecare increment poate lucra ca un sistem de sine
stătător. (Figura 4.2.)
Modelul incremental elimină necesitatea furnizării
cerinţelor, specificaţiilor generale şi a celor detaliate
înaintea începerii etapei de proiectare. Aceste specificaţii
numite "builds" (baselined intermediate software
products) sunt în mod formal specificate la începutul
fiecărui increment. Acest lucru permite posibilitatea
schimbării cerinţelor prin adăugarea lor în pasul
următor.

pagina 42
Sisteme informatice de gestiune

Figura 3.2. Modelul incremental

Şi în acest model există posibilitatea erorilor în


formularea cerinţelor dar spre deosebire de modelul
Waterfall acestea pot fi corectate de la un pas la altul pe
parcursul realizării sistemului. În plus se poate simula
funcţionalitatea sistemului, scopul său fiind furnizarea
unor feed-back-uri rapide proiectanţilor şi
conducătorilor fără o pierdere inutilă de timp,
eliminându-se posibilitatea construirii unui sistem
greşit.
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 regăsească sau nu în sistemul final dar regula
generală care trebuie urmărită constă în planificarea
eliminării acestor prototipuri.
Acest model reuşeşte să integreze corect
activităţile 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 incrementări ale versiunii
anterioare şi nu nişte modificări arbitrare şi
neautorizate. Numai acele modificări care vor
determina schimbări favorabile în dezvoltarea
sistemului vor fi aprobate.
• Verificarea constă în stabilirea în continuu a
corespondenţei între ce s-a solicitat şi ce s-a
realizat.
• Validarea, trebuie să aibă în vedere că sistemul
construit să nu prezinte goluri şi incoerenţe.
Dezvoltarea incrementală este ca o sabie cu două tăişuri,
pentru că permiţând etapizarea sistemului în versiuni
succesive, orice problemă apărută şi nerezolvată la un
moment dat implică suspendarea etapelor următoare.
Dezavantajul implicat de această situaţie este totuşi
mult mai mic, decât necazul produs de descoperirea
erorii numai la finalizarea sistemului.
Un alt avantaj constă în posibilitatea dezvoltării
simultane a mai multor sisteme, fiecare în diferite stadii
ale ciclului de viaţă. Aceasta măreşte capacitatea
conducerii de a acoperii un domeniu mai vast putându-
se aloca mai bine resursele, dar trebuie ţinut cont că pot
apărea situaţii în care este greu de estimat necesarul de
resurse mai ales în situaţiile neprevăzute apărute în
diferiţii paşi de dezvoltare ai sistemelor coordonate.

pagina 44
Sisteme informatice de gestiune

Modelul ciclului de concepţie în “V”.

Dezvoltarea unui sistem urmărind abordarile


anterioare poate fi descompusă într-o succesiune de
faze: specificaţii, concepţie, programare şi mentenanţă
după unii autori sau analiză preliminară, proiectare
logică, proiectare tehnică, programare, implementare,
exploatare şi întreţinere, după altii. (variante ale
modelului Waterfall).

Figura 3.4. Ciclul de concepţie în V

pagina 45
Sisteme informatice de gestiune

Pentru evidenţierea faptului că anumite faze ale ciclului


de viaţă sunt condiţionate de faze anterioare s-a propus
reprezentarea ciclului de viaţă al unui sistem informatic
ca un ciclu de concepţie în “V” (Figura 3.4.). Se observă
că etapele din braţul descendent sunt validate de cele
situate pe braţul ascendent. Asfel concepţia arhitecturii
aplicaţiei va trebui să răspundă testelor de funcţionare a
componentelor luate fiecare în parte dar şi în ansamblu.
Această schemă pune clar în evidenţă principalul
inconvenient al abordărilor clasice. Nu se poate valida
analiza făcută la începutul proiectului decât atunci când
toate activităţile de programare, testare şi integrare sunt
terminate.

Modelul OPERAŢIONAL.

Acest model porneşte de la o altă abordare decât


modelele anterioare şi anume prin concentrarea efortului
de definire asupra aspectului operaţional. Mecanismul
implementării nu este ascuns ci stă la baza specificaţiilor
de definire. Cu alte cuvinte, modelul operaţional creează
specificaţii executabile (numite şi specificaţii
operaţionale) care sunt ulterior transformate într-o
eficientă implementare. Astfel comportamentul extern al
sistemului există implicit în cadrul specificaţiilor în timp
ce structura internă nu.
În acest tip de model proiectarea se referă direct
la condiţiile de mediu în timp ce celelalte modele pun
accentul pe separarea cerinţelor (comportamentul
extern) de structura internă a sistemului.
Prin realizarea legăturii între specificaţiile
operaţionale şi structura internă a sistemului, se

pagina 46
Sisteme informatice de gestiune

constată că modelul operaţional este "orientat pe


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

Figura 3.3. Modelul operaţional

Unul dintre avantajele modelului operaţional este


marea sa putere descriptivă orientată direct spre
rezolvarea problemei. Spre deosebire de modelul
incremental care porneşte de la o descriere liberă a
specificaţiilor de definire, modelul operaţional are
descrieri formale, riguroase şi care pot fi uşor analizate.
Acest fapt îi permite să poată foarte uşor să fie transpus
pe calculator.
Ca dezavantaje se constată contradicţia dintre
necesitatea transformării cerinţelor externe într-o
structură internă înainte ca aceasta să fi fost definită.
Deoarece modelul nu este prea răspândit evaluarea
posibilităţilor sale este dificil de făcut 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 experimentări în situaţii
dintre cele mai diferite.
Modelul Incrememtal include în ciclul de viaţă
activităţi de conducere şi dezvoltare prin paşi succesivi,
realizând un feed-back rapid între proiectanţi şi
utilizatori.
Modelul de concepţie în “V” pune în evidenţă
faptul că o fază o validează pe precedenta (similar
modelului Waterfall) dar şi faptul că numai fazele
terminale realizează adevărata validare a etapelor de
început.
Modelul Operaţional realizează specificaţii
"executabile", măreşte rolul automatizării şi stabileşte o
strânsă legatură între specificaţii ş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 condiţii subiective.
Adesea un proiect trebuie început de la dorinţele
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 hotărăşte că nu este de fapt
ceea ce a dorit. Este extrem de greu de modelat această
situaţie: "Nu ştiu ceea ce vreau dar ştiu ceea ce nu
doresc". Practica ne-a demonstrat că folosirea unui
model imperfert şi incomplet este totuşi mult mai utilă
decât renunţarea la orice fel de model.
Dar modelul nu este totul. Avem nevoie de un set
de prescripţii pentru desfăşurarea activităţilor cerute de
etapele unui model bazat pe ciclul de viaţă, prescripţii
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 găsi 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 atât reguli implicite cât şi
explicite. Regulile explicite sunt prezentate de obicei în
documentaţia de realizare dar cele implicite nu sunt
prezentate nicăieri.
Când 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 paşii care trebuie parcurşi
ci precizează şi ce decizii trebuiesc luate în paşii
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ă
operaţie. Automatizare înseamnă un suport pentru o
metoda şi este o parte integrată în procesul de
dezvoltare a sistemului informatic. Dar soluţionarea cu
succes a problematicii constă în integrarea coerentă a
metodelor folosite într-o metodologie, şi nu în
automatizarea lor.
Automatizarea are o mulţime 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 păstrarea unei
cantitaţi mari de informaţii care este imposibil de
gestionat manual pentru sisteme de o anumită mărime.

pagina 49
Sisteme informatice de gestiune

Automatizarea implică o scădere a costurilor de


dezvoltare şi planificare rezultând o creştere calitativă a
activităţii creative deoarece proiectanţii şi conducătorii
proiectului sunt degrevaţi de aspectele de rutină. De cele
mai multe ori automatizarea facilitează învăţarea şi
comunicarea între membrii proiectului.

pagina 50
Sisteme informatice de gestiune

IV. METODA MERISE

4.1. Prezentare

Apariţia metodei MERISE marchează o dată


importantă în istoria prelucrării informaţiilor. Această
apariţie rezultă pe de o parte din contextul generalizării
prelucrărilor conversaţionale, consecinţă a salturilor
tehnologice din anii '70, şi pe de altă parte, rezultă în
urma numeroaselor lucrări asupra bazelor de date şi
asupra "abordării sistemice".
MERISE s-a născut în Franţa în jurul anilor
1978-1979 ca urmare a unei vaste consultări lansate de
către 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
adevărat devenind un standard cu un număr de
utilizatori în continuă creştere atât în domeniul public
cât şi în cel privat. Statisticile publicate în Franţa în
1990 au confirmat această evoluţie deoarece dintre
întreprinderile mari şi mijlocii care foloseau o metoda de
analiză-proiectare, 60% aleseseră deja MERISE.
MERISE acumulează continuu şi completează
cămpul său de aplicabilitate integrând noi extensii. Patru
sunt direcţiile principale de evoluţie:
• integrarea arhitecturilor client/server;
• o mai buna poziţionare în raport cu metodele anglo-
saxone;
• o abordare orientată pe obiecte;

pagina 51
Sisteme informatice de gestiune

• dezvoltarea unui mediu metodologic european


concretizat astăzi prin proiectul EUROMETHODE.
Consfătuirea cu tema "MERISE et les autres"
desfăşurată 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 poziţiei acestei
metode în raport cu alte abordări metodologice.
MERISE are numeroşi adepţi care o utilizează cu
pasiune, dar şi opozanţi care o consideră o metodă
greoaie. Dacă anumite proiecte sunt uneori nereuşite
aceasta este din cauza unei folosiri inadecvate a
metodei. Folosirea metodei MERISE implică o investiţie
personală care presupune o mare rigoare şi folosirea
unor tehnici complexe. Această investiţie personală nu
a fost facută, uneori, în cele mai bune condiţii şi în
această situaţie, pentru anumiţi conducători de proiecte,
metoda pare greoaie.
Pentru a reuşi, un proiect MERISE trebuie să aibă
obligatoriu adeziunea şi participarea utilizatorilor.
Metoda presupune construirea de modele la nivel
conceptual, organizaţional şi operaţional furnizând
astfel legăturile existente în sistemele informaţionale.
(Figura 4.1.)

pagina 52
Sisteme informatice de gestiune

Figura 4.1. Nivelele metodei Merise

NIVELUL CONCEPTUAL constă în analiza


sistemului informaţional în termenii obiectivelor, fără a
ţine cont de nici un concept legat de organizare ("ce
trebuie făcut şi cu ce date?").
Trebuie studiate separat în plan conceptual, pe
de o parte datele şi organizarea lor şi pe de altă parte
prelucrările.

pagina 53
Sisteme informatice de gestiune

În termeni de organizare a datelor se face apel la


formalismul entitate-relaţie şi aceasta se traduce prin
entităţi de baza şi relaţii între aceste entităţi. La acest
nivel, cu ajutorul unei grafici adecvate se constituie
modelul conceptual al datelor (MCD), care permite o
descriere statică a sistemului informaţional cu ajutorul
conceptelor de entitate şi asociaţie.
MCD permite reprezentarea datelor din realitatea
înconjurătoare independent de opţiunile tehnice, pentru
a uşura gândirea în timpul activităţii de concepţie.
În termeni de organizare a prelucrărilor aceste
entităţi vor fi descrise prin prelucrările pentru care ele
sunt cauze şi consecinţe. Această etapă are ca scop
definirea operaţiilor principale care trebuie efectuate în
domeniul studiat. Se va stabili o diagramă de flux
(modelul conceptual al comunicaţiilor MCC) care permite
descrierea informaţiilor schimbate global în sistem prin
intermediul actorilor şi fluxurilor.
Pornind de la această diagramă, se va trece spre
modelul conceptual al prelucrărilor (MCP). Rezultatul său
final se va concretiza sub formă schematică într-un
model "eveniment-operaţie-rezultat" care va trebui să
răspundă la întrebările: ce trebuie făcut în interiorul
sistemului informaţional, sub impulsul căror evenimente
şi ce rezultate se obţin?
NIVELUL ORGANIZAŢIONAL constă în integrarea în
analiză a criteriilor legate de organizare. După ce nivelul
conceptual a exprimat realitatea percepută în ansamblul
său, nivelul organizaţional exprimă această realitate aşa
cum este ea trăită de actorii participanţi, indiferent care
ar fi aceştia. La acest nivel nu se face nici o distincţie
între oameni şi maşini. La nivelul datelor este necesară
orientarea către o clasă de soluţii, şi apare modelul logic
al datelor (MLD) care este o transcriere a modelului
conceptual al datelor. Are loc, în privinţa datelor, o

pagina 54
Sisteme informatice de gestiune

transformare a lor dar nu o îmbogăţire a lor. Nivelul


conceptual al datelor este o descriere completă a
sistemului. Date noi pot fi create la nivele inferioare
(crearea unei redundanţe în vederea minimizării
numărului de accesări la una din entităţi) dar în nici un
caz nu se pot crea informaţii noi.
Situaţia este diferită la nivelul prelucrărilor.
Trecerea de la nivelul conceptual (MCP) la nivelul
organizaţional (MOP) se concretizeaza prin ataşarea
evenimentelor definite anterior, actorilor. În aceste
proceduri globale vor apare întotdeauna actori care au
în plus noţiunea de restricţie temporală şi
organizatorică. La nivelul prelucrărilor evenimentele
descrise au mai ales o dominantă spaţială decât una
temporală şi se completează nivelul conceptual
răspunzând la întrebările cine? şi unde?.
NIVELUL OPERAŢIONAL este o reprezentare a
mijloacelor care vor fi efectiv folosite pentru a gestiona
datele şi prelucrările şi constă în furnizarea soluţiilor
tehnice răspunzând la întrebarea cum?.
La nivelul datelor se va trece de la o clasă de
soluţii la una singură. Aceasta se concretizeaza prin
utilizarea unui anumit SGBD. Se face o alegere privind
metodele de stocare şi de acces la informaţii. Se
construieşte la acest nivel modelul fizic al datelor (MFD)
care este transformarea modelului logic al datelor (MLD)
prin echivalarea noţiunilor de tablou şi coloane cu
noţiunile de relaţie şi atribute din modelul logic al
datelor.
La nivelul prelucrărilor se procedează la
împărţirea proiectului în programe. Modelul operaţional
va descrie arhitectura programelor care vor executa
anumite funcţii, 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 număr de documente care să
permită sinteza procesului de gândire. Aceste
documente, indispensabile elaborării, sunt leagate de
cele rezultate din analiza datelor.
Punerea în aplicare a modelelor de prelucrare la
orice nivel, conceptual, organizaţional sau operaţional
are nu numai scopul de a defini prelucrările de efectuat
dar şi opţiunile 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 realizării sistemului. Aceste
trei cicluri se desfăşoară simultan.
1.Ciclul de abstractizare este realizat prin
formalismul celor trei nivele conceptual, organizaţional
şi operaţional şi se va aplica asupra prelucrărilor şi
datelor.
2.Ciclul de viaţă presupune trei mari etape:
• concepţia sau perioada studiului sistemului existent
şi apoi a noului sistem;
• realizarea care acoperă proiectarea şi exploatarea
sistemului;
• întreţinerea care va permite sistemului să evolueze şi
să se adapteze modificărilor de mediu şi noilor
obiective până î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 desfăşurării 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 noţiuni sumar prezentate se adresează


atât utilizatorilor (cei care solicită serviciile) cât şi
informaticienilor (furnizorii de prestaţii). Eficacitatea şi
validitatea unei analize constă în calitatea comunicaţiei
dintre beneficiar şi proiectant iar calitatea comunicaţiei
este obţinută, în parte, graţie utilizării 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 având caracter de directivă aparţine
Institutului Central de Infornatică şi datează din
decembrie 1977. Conform acestei metodologii realizarea
sistemelor informatice se desfăşoară în şase etape:
elaborarea temei de realizare, elaborarea concepţiei
sistemului informatic (proiectarea logică), proiectarea
tehnică, elaborarea programelor, implementarea,
exploatarea şi întreţinerea.

4.2.1. Elaborarea temei de realizare a sistemului


informatic.

În această etapă iniţială se examinează


posibilitatea realizării unui nou sistem informatic, sau
modificării sistemului existent. Stimulul declanşator al
acestei etape trebuie să fie de regulă viitorul beneficiar.
Principala activitate în acest stadiu este
cunoaşterea 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 următoare.
Elaborarea temei de realizare este etapa prin care
se cunoaşte situaţia actuală, se furnizează un diagnostic
şi se caută soluţiile posibile. În aceastaă etapă trebuie
elaborată o soluţie independentă de mijloacele de
realizare.
Rezultatele acestei etape constau în "caietul de
sarcini" şi "specificaţiile funcţionale 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
specialişti cu experienţă şi care au mai întocmit lucrări
similare.
Obiectivul principal al acestei etape este formularea
cerinţelor informaţionale ale sistemului de conducere.
Activităţile din cadrul acestei etape sunt :
• studiul sistemului existent,
• evaluarea sistemului existent,
• evaluarea gradului de pregătire a întreprinderii,
• formularea cerinţelor şi a restricţiilor pentru
realizarea sistemului informatic.
În cadrul acestei ultime activităţi, cea mai importantă din
prima etapă intră:
• definirea obiectivelor şi performanţelor noului
sistem;
• stabilirea domeniului şi funcţiunilor noului sistem
informatic;
• definirea cerinţelor şi restricţiilor informaţionale pe
probleme şi funcţiuni;
• estimarea resurselor disponibile pentru proiectarea,
implementarea şi exploatarea noului sistem.

În realizarea etapizată a sistemului informatic


tebuie, în primul rând, 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 urmăreşte definirea
caracteristicilor generale şi analiza activităţilor
desfăşurate.
De asemenea studiul sistemului presupune şi
analiza modului în care sistemul informaţional asigură
legăturile între sistemul conducător şi sistemul condus.

pagina 59
Sisteme informatice de gestiune

Pe baza concluziilor rezultate din studiul


sistemului, se evaluează critic sistemul informaţional şi
se formulează cerinţele şi restrictiile pentru realizarea
sistemului informatic.
Printre tehnicile şi metodele de analiza a
sistemului existent se numară:

1. Tehnica documentării
2. Metoda analizei-diagnostic
3. Metoda diagramelor de flux informaţional
4. Metoda evidenţei economice
5. Metoda anchetelor
6. Metoda scenariilor

1. Tehnica documentării.

Prin tehnica documentării se urmăreşte culegerea


şi prelucrarea informaţiilor cu caracter teoretic şi practic
privind sistemul studiat.
Pentru atingerea acestui obiectiv, documentarea
trebuie să se desfaşoare într-o ordine logică folosind ca
instrument principal de lucru documentele care
reglementează existenţa şi funcţionarea sistemului
respectiv. Astfel de documente sunt: organigrama,
regulamentul de organizare şi funcţionare, alte acte
nomative. Prin organigramă sunt reprezentate grafic
gruparea compartimentelor de muncă după criterii
funcţionale, subordonarea acestora, repartizarea lor şi
legăturile dintre compartimente. În acest mod
organigrama vizualizează natura şi poziţia fiecărui
compartiment. Ea reflectă obiectivele sistemului
economic, responsabilităţile, delegările de autoritate şi
legăturile funcţionale. Informaţiile cu caracter general
obţinute prin analiza organigramei pot fi completate

pagina 60
Sisteme informatice de gestiune

prin studiul regulamentului de organizare şi funcţionare


a sistemului. Aspecte de detaliu asupra modului de
desfaşurare a activităţilor sunt completate prin
parcurgerea actelor normative care reglementează
prestarea lor.
Analiza situaţiei existente este completată prin
documentarea asupra unor studii şi proiecte informatice
elaborate în alte întreprinderi cu profil apropiat.
Rezultatele documentării 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


informaţii 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 funcţionarea sistemului şi
în stabilirea remediilor corespunzatoare. Prin cercetarea
activităţilor desfăşurate se stabilesc direcţiile de
dezvoltare pentru sistemul existent. Obiectivele
analizei-diagnostic sunt:
• Realizarea unui sistem de organizare şi conducere
perfecţionat flexibil la modificările care apar. Prin
analiza-diagnostic urmează să se stabilească în ce
măsură structura organizatorică satisface necesităţile
conducerii şi posibilităţile de creştere a fiabilităţii
sistemului prin tratarea automată a datelor.
• Prevenirea factorilor perturbatorii care generează
efecte negative asupra sistemului economic sub
aspect structural, funcţional şi al nivelului de
performanţă.

pagina 61
Sisteme informatice de gestiune

• Identificarea căilor 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
realizării sistemului informatic.
Realizarea presupune luarea în considerare a
următoarelor aspecte:
• strategia de dezvoltare a întreprinderii;
• condiţiile de materializare pe baza resurselor
disponibile;
• priorităţi care se impun în funcţie de condiţii;
În aplicarea metodei se recomandă parcurgerea
următoarelor etape de lucru:
• culegerea informaţiilor privind organizarea şi
funcţionarea sistemului existent;
• formularea obiectivelor, care se realizează prin
conturarea ţelurilor urmărite şi a modalităţilor de
realizare;
• enunţarea instrucţiunilor privind desfăşurarea
acţiunilor;
• realizarea practică a instrucţiunilor;
• analiza informaţiilor culese şi evaluarea rezultatelor;
Dacă soluţiile rezultate nu sunt edificatoare asupra
obiectivelor urmărite atunci analiza diagnostic se reia.
Concluziile analizei-diagnostic, corelate cu rezultatele
documentării, constituie baza cunoaşterii sistemului şi a
posibilităţilor de perfecţionare.

3. Metoda diagramelor de flux informaţional.

Identificarea caracteristicilor sistemului de


conducere necesită detalierea analizei sistemului

pagina 62
Sisteme informatice de gestiune

informaţional. În acest scop se apelează la metoda


diagramelor de flux a documentelor şi a momentelor lor
de completare urmărind raţionalizarea sistemului
informaţional şi ameliorarea funcţionării acestuia.
Diagramele de flux informaţional dau o descriere
sistemica a unui proces sau a unui ciclu de muncă cu
suficiente detalii, care odată analizate pot duce la o
îmbunătăţire a activităţii respective.
Fiecare element component al diagramei este
astfel reprezentat încât 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 evidenţei economice.

Evidenţa economică reprezintă un ansamblu de


procedee şi tehnici de urmărire a fenomenelor şi
proceselor care au avu loc în domeniul vieţii economice.
Prin conţinut evidenţa economică este componenta
majoră a sistemului informaţional economic. Orice
operaţie de flux real al valorilor materiale şi băneşti
trebuie să se găsească consemnată în documentele de
evidenţă economică.
După procedeele şi tehnicile folosite în
investigarea realităţii economice evidenţa economică se
constituie în trei forme distincte:
a)- evidenţa tehnico-operativă
b)- evidenţa contabilă
c)- evidenţa statistică

pagina 63
Sisteme informatice de gestiune

a) Evidenţa tehnico-operativă constă în consemnarea


şi centralizarea datelor privind procesele şi
fenomenele economice la locul şi în momentul
producerii lor. Evidenţa tehnico - operativă
furnizează informaţii necesare conducerii operative.

b) Evidenţa contabilă sau contabilitatea urmăreşte


formarea existenţa şi folosirea mijloacelor
economice şi a surselor lor de formare. Prin
conţinut contabilitatea este cea mai importantă
componentă a evidenţei economice. Ea asigură
continuitatea circuitului informaţional între evidenţa
tehnico-operativă şi cea statistică şi este principala
sursă de informaţii a conducerii tactice şi strategice.
c) Evidenţa statistică sau statistica oglindeşte şi
caracterizează procesele în ansamblul lor prin
studierea unor fenomene social-economice de
masă. Cu ajutorul statisticii se poate studia
evoluţia unor fenomene în perioadele anterioare
pentru a determina evoluţia lor viitoare.

5.Metoda anchetelor.

Prin această metodă se culeg informaţii 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 următoarele principii:
• selectarea persoanelor de interogat având în vedere
poziţia lor în sistem şi competenţa lor profesională;
• antrenarea subiecţilor aleşi la emiterea de idei noi
privind modul de desfăşurare a activităţilor;
• acceptare ideilor emise fară o judecată imediată a
valorii lor;

pagina 64
Sisteme informatice de gestiune

• stimularea gândirii participanţilor prin formularea de


întrebări adecvate;
• verificarea rezultatelor prin îmbinarea modului de
aplicare al tehnicilor;
Respectarea acestor principii asigură luarea în
considerare a comportamentului subiectilor investigaţi,
şi în consecinţă, culegerea de informaţii critice asupra
stării şi funcţionării sistemului.
Metoda anchetelor se constituie dintr-un complex
de tehnici cu caracter interogativ cum sunt:

A) tehnica chestionarului
B) tehnica interviului
C) tehnica observării directe

A. Tehnica chestionarului presupune utilizarea


chestionarului ca instrument de culegere a informaţiilor
referitoare la obiectivele analizei.
Întocmirea chestionarului cuprinde trei faze distincte:

1. Faza pregatitoare, în care se delimitează cu


exactitate obiectivele chestionării.
Astfel de obiective pot fi:

a) analiza activităţilor de bază;


b) principali indicatori economici folosiţi;
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 informaţiilor şi modul de prelucrare
ulterioară.

2. Faza de întocmire a chestionarului.

pagina 65
Sisteme informatice de gestiune

În funcţie de obiective şi subiecţii ce urmează a fi


supuşi chestionării, se stabilesc numărul şi tipul de
întrebări. Numărul mediu de întrebări într-un chestionar
trebuie să fie cuprins între 15 şi 20. Un număr prea mic
de întrebări nu poate furniza informaţiile dorite şi nu
justifică efortul făcut pentru organizarea chestionarului,
iar un număr prea mare de întrebări oboseşte subiectul
chestionat ceea ce duce la emiterea de răspunsuri
pripite, neconcludente pentru analiza de sistem.
Activarea subiecţilor se poate asigura prin folosirea mai
multor tipuri de întrebări, cum sunt:
• întrebări închise, cu un număr redus de răspunsuri
precodificate prin care subiecţii se pronunţă asupra
unor informaţii culese prin alte metode şi tehnici;
• întrebări factuale asupra unor fapte obiective, de
verificare a aptitudinilor, de identificare a unei stări
de fapt, de clarificare a unor aspecte ale analizei;
• întrebări deschise la care numărul răspunsurilor
poate varia de la un subiect la altul.

După locul ocupat în chestionar, întrebările se grupează


astfel:
• introductive, în problema analizată;
• "de filtru" prin care se precizează condiţionarea între
întrebări;
• de bifurcare prin care se identifică numărul
întrebărilor la care se va răspunde în continuare dacă
s-a răspuns afirmativ la întrebarea anterioară şi
numărul întrebărilor înlănţuite în cazul în care
răspunsul anterior a fost negativ;
• de motivare a unor răspunsuri;
• de control a exactităţii răspunsurilor şi de identificare
a subiectului chestionat.
Pentru ca formularea întrebărilor să fie corectă şi
corespunzatoare realizării obiectivelor, la această

pagina 66
Sisteme informatice de gestiune

acţiune trebuie să participe, pe lângă informaticieni


sociologi, psihologi, statisticieni.

3. Faza de verificare a chestionarului.


Prin testări se urmăreşte modul în care rezultatele
chestionării concordă cu obiectivele investigaţiei. În
funcţie de constatările faptice, se corectează formularea
întrebărilor şi ordinea lor în chestionar. În întocmirea şi
completarea chestionarului este recomandată
respectarea următoarelor reguli:
• formularea simplă, clară, concisă şi explicită a
întrbărilor;
• asigurarea libertăţii subiecţilor de a completa sau
nu chestionarul printr-o întrebare introductivă;
• evitarea formulării de întrebări tendenţioase,
ipotetice, prezumptive, insuficient de clare;
• asigurarea unei succesiuni logice a întrebărilor;
• schimbarea ordinii răspunsurilor precodificate în
formulare pentru a se elimina tendinţa de alegere
a primului răspuns;
• includerea în chestionar a unor întrebări de
control prin care să se asigure veridicitatea
răspunsurilor.
Completarea chestionarului de un număr reprezentativ
de subiecţi, asigură obţinerea de informaţii relevante
pentru analiza sistemului.

B. Tehnica interviului

Prin această tehnică se urmăreşte obţinerea într-


un interval de timp redus, de informaţii privind
orientările practice, metodele şi strategiile existente sau
preconizate în rezolvarea problemelor analizate.

pagina 67
Sisteme informatice de gestiune

Interviul asigură obţinerea de informaţii recente şi


verificarea informaţiilor obţinute prin alte metode sau
tehnici.
Alegerea subiectilor de intervievat se face având
în vedere următoarele constatări practice:
• persoanele care ocupă poziţii medii în ierarhia
structurii organizatorice furnizează informaţiile cele
mai apropiate de realitate;
• colectarea de informaţii corecte presupune
intervievarea nu numai a personalului de conducere
ci şi a celui de execuţie;
• competenţa subiecţilor trebuie verificată în
prealabil;
• lipsa unei atitudini critice poate să semnifice reţineri
în exprimarea ideilor.

Procedura de aplicare a interviului cuprinde trei etepe:


1. Etapa pregătitoare constă în următoarele:
• însuşirea terminologiei utilizate în domeniul
studiat;
• formularea şi coordonarea întrebărilor;
• cunoaşterea prealabilă a subiecţilor;
• alegerea momentelor propice pentru luarea
interviului (de obicei, partea medie a perioadei de
activitate).

2. Etapa de desfăşurare a interviului. În această etapă se


cer a fi respectate următoarele reguli:
• menţinerea discuţiei în limitele problemei
analizate,
• acordarea unor momente de gândire,
• formularea de întrebări ajutătoare,
• evitarea consemnării de răspunsuri fără
argumentaţie
• insistarea asupra aspectelor neclare

pagina 68
Sisteme informatice de gestiune

• sesizarea stărilor de reţinere în a critica aspectele


negative ale activităţii analizate;
• evitarea discuţiilor în contradictoriu;
• solicitarea de recomandări şi din partea altor
persoane competente din domeniul analizat.

3. Etapa de culegere şi prelucrare a informaţiilor se


realizează prin consemnarea în raportul de interviu a
răspunsurilor cu precizarea aspectelor neclarificate şi a
posibilităţilor de completare a rezultatelor. Concluziile
interviului reflectă starea elementelor sau a proceselor
analizate şi posibilităţile de remediere a deficienţelor
existente.

C. Tehnica observării directe.

Observarea directă a activităţilor, asigură


cunoaşterea nemijlocită a sistemului existent. Prin
tehnica observării directe se studiază sarcinile care
formează conţinutul unei activităţi. În analiza actvităţii
de producţie, spre exemplu, prin consemnarea
operaţiilor efectuate asupra produsului şi a timpilor de
execuţie se conturează structura ciclului de fabricaţie şi
alte aspecte ale producţiei 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 obţinute prin alte metode.
Tehnica observării directe foloseşte instrumente
specifice de lucru:

pagina 69
Sisteme informatice de gestiune

• sondaje
• cronometrări
• analiza posturilor ( locurilor de muncă)
Prin aplicarea acestora se relevă stări de fapt şi
posibilităţi pentru ameliorarea funcţionarii sistemului.

În cadrul anchetelor combinarea tehnicilor


menţionate asigură clarificarea problemelor de rezolvat
prin cunoaşterea detaliată a sistemului şi obţinerea de
informaţii privind posibilităţile de raţionalizare a
activităţilor. Rezultatele relevă deficienţele existente şi
impiicaţiile tratării automate a datelor.

6.Metoda scenariilor.

Metoda scenariilor se bazează pe un ansamblu de


procedee şi instrumente prin care se stabileşte
succesiunea logică a evenimentelor, în scopul de a
arăta cum se poate evolua pas cu pas spre o situaţie
viitoare plecând de la situaţia actuală. Pentru fiecare
alternativă se urmăreşte evoluţia sistemului reperându-
se noi puncte nodale.
Prin abordarea globală a sistemului sunt elaborate
scenarii calitative care stau la baza elaborării scenariilor
cantitative.
Situaţia cercetărilor previzionare la nivel global se
justifică prin aceea că evenimentele care depind de
fenomene generale sunt, pe termen lung, mai uşor de
prevăzut decât acelea care depind de circumstanţe
particulare.
Obiectivele principale urmărite prin aplicarea
metodei scenariilor sunt:
• predicţia dezvoltării, a evoluţiei unor fenomene şi
procese;

pagina 70
Sisteme informatice de gestiune

• stimularea gândirii în studiul unei probleme


decizionale;
• analiza detaliată a aspectelor dinamice.
În realizarea acestor obiective se urmăreşte parcurgerea
următoarelor 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 elaborării modelelor vor sta seriile
dinamice ale indicatorilor ce reflectă acţiunea
factorilor.
3. Scrierea scenariilor prin abordare globală şi
descrierea evoluţiei sistemului în dinamică, ţinând
cont de modificările care apar în structura sistemului.
4. Stabilirea tendinţelor în funcţie de care va evolua
sistemul, dacă asupra lui nu se exercită acţiuni
voluntare externe.
5. Extragerea rezultatelor prin reţinerea acelor tendinţe
manifestate care corespund obiectivelor propuse.

4.2.2. Proiectarea logică (elaborarea concepţiei


sistemului informatic).

Obiectivul acestei etape îl constituie elaborarea


proiectului de ansamblu al sistemului informatic, pe
baza cerinţelor şi restricţiilor formulate în tema de
realizare. Scopul acestei etape constă în determinarea
obiectivelor detaliate şi cerinţelor noului sistem.
Determinarea cerinţelor se face prin studiul organizaţiei

pagina 71
Sisteme informatice de gestiune

pe care o va servi sistemul, accentul punându-se pe


beneficiile pe care le va aduce sistemul propus.
Principalele activităţi care se desfăşoară în cadrul etapei
de concepţie a sistemului informatic sunt următoarele:

• definirea sistemului informatic, cuprinzând


delimitarea ariei şi a legăturilor sale externe;
estimarea dimensiunilor sistemului; definirea
structurii logice a datelor şi definirea proceselor de
prelucrare a datelor;
• adoptarea soluţiei de principiu pentru codificarea
datelor şi conversia fişierelor;
• proiectarea de principiu a noului flux informaţional;
• stbilirea necesarului de echipamente, configuraţiile
necesare, precum şi modul de procurare a
echipamentelor;
• stabilirea condiţiilor de montaj, funcţionare ş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 intrărilor, ieşirilor, şi prelucrărilor necesare;
• elaborarea graficului de eşalonare pentru proiectarea
şi implementarea componentelor sistemului;
• evaluarea efectelor pe care le va produce noul sistem
informatic;
• estimarea eficienţei economice.
• măsuri pregătitoare pentru realizarea sistemului;

Activtatea cea mai importantă în cadrul elaborării


concepţiei sistemului informatic este analiza circuitului
informaţional. Aceasta înseamnă că fluxurile parţiale
urmează a primi coerenţă prin studiul legăturilor şi
prelucrărilor înlănţuite. În acest fel este posibil să se

pagina 72
Sisteme informatice de gestiune

delimiteze cu claritate graniţele sistemului informatic şi


legăturile sale externe.
Aplicarea metodelor de analiză a circuitului
informaţional se bazează pe următoarele constatări
practice:
• fiecare activitate are un circuit informaţional propriu;
delimitarea sistemului informatic presupune analiza
distinctă a fiecărei activităţi;
• analiza fiecărei activităţi este condiţionată de
cunoaşterea obiectivelor sistemului economic şi de
reglementările care definesc sistemul informaţional;
• în activitatea de gestiune economică operaţiile de
prelucrare a datelor nu sunt diversificate şi au
caracter ciclic (operatiile aritmetice şi logice simple
reprezintă circa 80% din totalul operaţiilor de
prelucrare);
• pentru fiecare activitate, intrările condiţioneaza şi
sunt condiţionate de ieşirile informaţionale;
• prelucrarea datelor de intrare specifice unei activităţi
în scopul obţinerii ieşirilor dorite defineşte
transformările informaţionale şi determină circuitul
informaţional al activităţii;

Stabilirea ieşirilor şi intrărilor informaţionale sunt


determinante în organizarea datelor, în timp ce
transformările informaţionale determină organizarea
prelucrărilor. Bazate pe aceste constatări, metodele de
analiză a sistemului informaţional şi de delimitare a
ariei şi a legăturilor externe ale sistemului informatic
mai des utilizate sunt:
1 - metoda analizei ieşirilor;
2 - metoda orientată pe activităţi;
3 - metoda răspunsului la stimuli;
4 - metoda compartimentală;
5 - metode analizei celulare.

pagina 73
Sisteme informatice de gestiune

1. Metoda analizei ieşirilor.

Metoda analizei ieşirilor constă în parcurgerea


fluxurilor informaţionale invers, de la informaţia finală
(de ieşire) spre informaţia iniţială (de intrare).
Aceasta analiză se face pe baza diagramelor de
flux informaţional. Prin parcurgerea întregului circuit
informaţional, se determină:
• volumul datelor de ieşire;
• volumul datelor de intrare;
• prelucrările efectuate pe parcursul circuitului;
• purtătorii de informaţie;
• caracteristicile datelor.
Metoda analizei ieşirilor permite obţinerea unei imagini
complete asupra circuitului informaţional. Totodată, pot
fi remarcate deficienţe de circuit şi posibilităţi de
raţionalizare a sistemului informaţional.

2. Metoda orientată pe activităţi.

Prin aplicarea acestei metode se urmăreşte


definirea completă a aspectelor informaţionale care
caracterizează fiecare activitate. Parcurgerea fluxurilor
informaţionale pe fiecare activitate asigură cunoaşterea
detaliată a sarcinilor şi a operaţiilor care definesc
activităţile. Analiza unei activităţi se face independent
de celelalte, redând caracteristicile şi intercondiţionările
interne ale activităţii.
Metoda orientată pe activităţi este eficientă în
sisteme în care se manifestă autonomia activităţilor prin
relaţii de interdependenţă reduse.

pagina 74
Sisteme informatice de gestiune

3. Metoda răspunsului la stimuli.

Metoda răspunsului la stimuli are ca punct de


plecare un stimul oarecare, cum ar fi: o comandă, un
produs, o fază de fabricaţie etc. Analizând amănunţit
stimulul, se stabilesc legăturile dintre activităţi ş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 urmăreşte fluxul
principal al informaţiilor cu stabilirea punctelor în care
apar ramificaţii şi identificarea punctelor de control.
Analiza se completează cu studiul fluxurilor secundare.
Pentru activităţi complexe, metoda răspunsului la
stimuli asigură observarea conexiunilor şi demarcarea
operaţiilor principale de cele secundare.

4. Metoda compartimentală.

În aplicarea metodei compartimentale se stabilesc


acţiunile care se realizează într-un compartiment şi
legăturile compartimentului studiat cu celelalte
compartimente.
Pentru activităţi sau părţi din activităţile
desfăşurate în compartiment se determină intrările,
prelucrările şi ieşirile informaţionale necesare realizării
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 informaţional

pagina 75
Sisteme informatice de gestiune

după gradul lor de complexitate. Fiecărei componente


de tip subsistem i se asociază un rang. Subsistemul de
rang zero este componenta elementară şi se numeşte
celulă.
Pentru o celulă C intrările X={x1,x2,....,xn}, ieşirile
Y={y1,y2,..,ym} şi transformările T ale intrărilor în ieşiri
definesc celula respectivă:

C={X,Y,T}

Dacă ieşirea 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

Mărimile Yi şi Xj (ieşirile din celula i şi intrările în


celula j) desemnează acelaşi element. Această dublă
semnificaţie constituie o redundanţă informaţională.
Reducerea unor asfel de redundanţe se face prin
introducerea conceptului de generaţie. Elementul Xj
este un operand de generaţia j. Ca urmare a
transformării efectuate în celula j, apare generaţia j+1
de operanzi ceea ce se exprimă prin relaţia:

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

în care r semnifică numărul de ordine al operandului în


cadrul generaţiei.

Figura 4.4. Generaţii de operanzi

Două sau mai multe lanţuri de celule care au cel puţin


un punct comun, formează un arbore de celule:

A = { Lk , Lm }

Doi sau mai mulţi arbori legaţi în serie, paralel sau mixt
formează o structură complexă. (Figura 4.5.)
Convenţii:
• operanzii primari (datele primare) constituie operanzi
de generaţia zero. ( X01, X02, X03, X04);
• transformările operanzilor de generaţia zero
formează familia de operatori de generaţia 1 (T11,
T12, T13);
• celulele sunt reprezentate de operatorii lor prevăzuţi
cu doi indici; primul indică generaţia, iar al doilea
numărul de ordine al operatorului în cadrul familiei;
• ieşirile unui operator sunt de aceiaşi generaţie cu
operatorul, indiferent de generaţia intrărilor;
• operatorii în lant sunt de generaţii monoton
crescătoare;

pagina 77
Sisteme informatice de gestiune

• un operand poartă o singură pereche de indici chiar


şi când constituie intrări pentru mai mulţi operatori
de aceiaşi generaţie sau de generaţii diferite.

Figura 4.5. Arbore de celule

La nivelul întreprinderii un operator se constituie din


reguli de lucru al căror suport fizic poate fi material sau
imaterial. Celula în care acţionează un operator se
delimitează în funcţie de necesităţile analizei celulare.
Eficienţa metodei creşte prin combinarea aplicării ei cu
alte metode.

Codificarea datelor. Premiza principală a realizării 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 măsură la realizarea eficienţei scontate pentru
întregul sistem informatic. Aceasta asigură eliminarea
pagina 78
Sisteme informatice de gestiune

volumului mare de redundanţă informaţională şi


raţionalizarea procesului de tratare a datelor.
Operaţia de codificare a datelor constă în
stabilirea unei corespondente biunivoce între elementele
sistemului informaţional (documente, operaţii, 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 ieşire.
Desfăşurarea operaţiei de codificare presupuue
respectarea următoarelor principii:

• adoptarea aceloraşi norme în determinarea


vocabularului de intrare;
• folosirea unui limbaj de codificare accesibil, astfel
încât interpretarea alfabetului de ieşire să se facă
fără dificultăţi;
• respectarea biunivocităţii între vocabularul de intrare
şi limbajul de codificare. În finalul codificării, la
fiecare element al vocabularului trebuie să
corespundă un cod unic determinat;
• previziunea evoluţiei codurilor care să asigure
posibilitatea actualizării sistemelor de coduri fără
perturbaţii;
• sistemele de coduri adoptate să fie sugestive în
redarea legăturilor dintre fenomene, procese şi
documente;
• adaptarea codificarii în vederea prelucrării
electronice a datetor.
Între codurile interne sistemului economic şi codurile
folosite în economia naţionala, urmează a se stabili
modalităţi de conversie care să asigure obţinerea
ieşirilor informaţionale necesare în exterior.

pagina 79
Sisteme informatice de gestiune

Într-o abordare metodologica, codificarea constă în


următoarele activităţi:

A. Stabilirea caracteristicilor generale ale codurilor.


• Determinarea vocabularului de intrare şi a
caracteristicilor acestuia.
• Analiza structurii informaţiilor din vocabularul de
intrare pentru fixarea structurii generale a codului pe
grupe de elemente ale sistemului informaţional.
Necesităţile de prelucrare impun utilizarea de coduri
prin care să se indice locul de stocare sau de utilizare
conturile în care se consemnează natura şi
apartenenţa elementelor codificate.
• Determinarea alfabetului de ieşire în funcţie de
mărimea vocabularului de intrare şi de structura
generală a codurilor. Codurile care definesc alfabetul
de ieşire, trebuie să conţină un minimum de
simboluri de reprezentare.
• Fixarea sistemelor de coduri astfel încât acestea să
asigure maximum de uniformitate a codificării.

Principalele sisteme de coduri utilizate sunt:

1. Sistemul în ordine numerică (naturală) este utilizat


pentru elemente temporare ale sistemului, fără
periodicitate. Orice element nou apărut afectează
întregul sistem de coduri.
2. Sistemul în serie este o dezvoltare a sistemului în
ordine naturală prin rezervarea de numere pentru
eventuale apariţii de noi elemente în vocabularul de
intrare.
3. Sistemul pe grupe constă în atribuirea unui anumit
număr de coduri fiecărei 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
rămân 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 puţin 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 mulţimilor. 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 importanţa codurilor în efectuarea prelucrării
datelor, o atenţie deosebită trebuie acordată
corectitudini fiecărui 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 tratării


informaţiei reprezentate. Cifra de control se stabileşte
după algoritmi diferiţi.

B. Clasificarea elementelor vocabularului de


intrare de la general la particular până la nivel elementar
cu respectarea normelor legale. Operaţiile şi
documentele se grupează după locul şi rolul lor în
sistem, materialele după natură, proprietăţi, 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
corespondenţei între vocabularul de intrare şi alfabetul
de ieşire.
E. Unificarea terminologiei şi atribuirea codurilor.
În toate documentele de uz intern urmează a se atribui
coduri elementelor sistemului informaţional.
F. Actualizarea codurilor constă în adăugări de
coduri pentru elementele nou intrate în sistem şi în
eliminări de coduri perimate pentru elemente care nu se
mai utilizează.

Estimarea eficienţei economice a sistemelor informatice.


Asimilarea lucrărilor de realizare a unui sistem
informatic cu lucrările de investiţii, face ca determinarea
şi urmărirea eficienţei să fie un aspect major al realizării
sistemului informatic. Obiectivul global urmărit este
creşterea efectului util al fiecărui leu cheltuit.
Eficienţa, ca raport între efectul util şi efortul
făcut pentru obţinerea efectului scontat, se urmăreşte
sub aspecte multiple. (productivitatea muncii, indici de
utilizare ai resurselor, norme de consum, etc.)

pagina 82
Sisteme informatice de gestiune

Din punct de vedere informaţional, satisfacerea


nevoilor de informare ale conducerii, entropia
informaţională, costul informaţiei, redau eficienţa
sistemului informaţional. În consecinţă, aspectele de
eficienţă se referă nu numai la resursele şi efectele
imediate ale realizării unei investiţii; prin studiul
cheltuielilor necesare şi al efectelor directe şi indirecte
pe o perioadă mai mare de timp. Ele includ şi urmărirea
fiabilităţii obiectivului investiţiei după darea lui în
exploatare.
Evaluarea cheltuielilor. Cheltuielile de realizare a
sistemului informatic se constituie din cheltuielile de
investiţii necesare elaborării şi introducerii sistemului
informatic. În cheltuielile de exploatare se includ şi cele
necesare întreţinerii sistemului în scopul creşterii
performanţelor acestuia. În etapa de analiză şi proiectare
a sistemului informatic, sunt angajate cheltuieli curente
cu salariile echipei de proiectare (în situaţia când
proiectarea se face cu forţe proprii).
Declanşarea activităţilor de conconceptie, implică
efectuarea de cheltuieli pentru pregătirea cadrelor
proprii de informatică ce vor asigura exploatarea
sistemului.
De asemenea, încă din această etapă de lucru,
apare necesară pregătirea psiho-socială a personalului
întreprinderii asupra utilităţii sistemului informatic. În
acest scop sunt necesare cheltuieli cu desfăşurarea de
prezentări demonstrative privind avantajele prelucrării
automate a datelor şi implicaţiile scontate. Scopul unor
astfel de acţiuni este de a se asigura din timp
participarea activă a personalului la realizarea
schimbărilor pe care le va genera introducerea
sistemului informatic, evitându-se opoziţia surdă a celor
vizaţi să fie atinşi 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 aplicaţii tip şi a unor produse-program
generalizabile (software). Aceasta asigură încă de la
început, scurtarea perioadei de analiză-proiectare,
reducerea efortului de programare şi creşterea
performanţelor de exploatare a sistemului informatic.
Cheltuielile pentru realizarea sistemului
informatic se împart în:
1. cheltuieli iniţiale ( Ci ):
• cheltuieli pentru promovarea noii soluţii;
• cheltuieli pentru analiză şi proiectare;
• cheltuieli pentru procurarea şi adaptarea
produselor software tipizate;
• cheltuieli pentru procurarea configuraţiei
hardware;
• cheltuieli pentru amenajarea spaţiilor necesare
instalării echipamentelor.
2. cheltuieli de exploatare ( Ce ):
• cheltuieli cu salariile personalului de informatică;
• cheltuieli pentru perfecţionarea pregătirii
personalului;
• cheltuieli cu materialele consumabile şi cu
amortizarea tehnicii de calcul;
• cheltuieli cu întreţinerea curentă şi reparaţii;
• cheltuieli pentru întreţinerea software a
sistemului informatic (adaptarea sistemului
informatic).

pagina 84
Sisteme informatice de gestiune

Din categoria cheltuielilor iniţiale cea mai mare pondere


o reprezintă cheltuielile cu proiectarea sau cu procurarea
aplicaţiilor tipizate grupate în cheltuieli cu software-ul şi
cheltuieli cu achiziţia echipamentelor care constituie
cheltuielile cu hardware-ul. Analiza evoluţiei 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 eşalonării 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 rândul lor reprezintă doar 20% din totalul
costului sistemului pe parcursul întregului ciclu de viaţă.
Cheltuielile pentru exploatare şi întreţinere sunt în mare
măsură 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 mărimii cheltuielilor de producţie pe
elemente primare sau pe articole de calculaţie ale
costului de producţie ca urmare a prelucrării 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 urmărirea
normelor şi a consumurilor specifice cu ajutorul tehnicii
de calcul. Pentru materialele auxiliare, economiile
rezultă printr-o mai bună dimensionare a stocurilor şi
prin urmărirea exactă a consumurilor.
Estimarea cheltuielilor de transport-aprovizionare se
face în raport cu implicaţiile 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

Relaţia de calcul este următoarea:

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 numărul de lucrători pentru exploatarea şi
întreţinerea sistemului informatic;
• N este numărul lunilor de funcţionare 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 lucrărilor din evidenţa economică în
condiţiile prelucrării 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 contribuţiei
privind asigurările sociale şi fondului de şomaj.
La suma economiilor enunţate mai sus se adaugă cele
obţinute ca urmre a gestiunii raţionale a tuturor
resurselor financiare.
În categoria efectelor economice cantitative se
adaugă profitul suplimentar. În calcule, punctul de
plecare îl constituie stabilirea sporului de producţie ca
urmare a funcţionării sistemului informatic. Relaţiile de
calcul sunt următoarele:

pagina 87
Sisteme informatice de gestiune

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

unde:
• Sp este sporul de producţie ca urmare a funcţionării
sistemului informatic;
• Q0,Q1 reprezintă valoarea producţiei înainte şi
respectiv după introducerea sistemului informatic;
• N este numărul de ani estimat pentru funcţionarea
sistemului informatic;
• Kf este coeficientul modificării valorii mijloacelor de
producţie în primul an de funcţionare a sistemului
informatic faţă de anul precedent;
• Spe este sporul efectiv a valorii producţiei pe durata
exploatării sistemului informatic.

Calculul profitului suplimentar (Ps) datorat introducerii


sistemului informatic se face având în vedere profitul
scontat ce se obţine în primul an de aplicare a sistemului
informatic (P1) profitul normat (Pn) exprimat în mărimi
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 preţul normat şi
preţul efectiv înainte şi după introducerea sistemului
informatic.
La cheltuielile variabile, după determinarea mărimii
influenţei factorilor cantitativi şi calitativi, abaterea

pagina 88
Sisteme informatice de gestiune

suplimentară semnifică influenţa introducerii sistemului


informatic asupra costului productiei.
Pentru cheltuielile fixe, creşterea gradului de
automatizare a producţiei duce la obţinerea de economii
prin accentuarea tendinţei de scădere a cheltuielilor fixe
pe unitatea de produs.
Pe lângă efectele economice cantitative
menţionate, funcţionarea sistemului informatic
generează efecte indirecte (calitative) cum sunt:
• îmbunătăţirea formei şi a conţinutului documentelor
tehnice şi economice;
• raţionalizarea sistemului de evidenţă economică;
• orientarea personalului din compartimentele
funcţionale de la activităţi de rutină spre activităţi de
concepţie;
• îmbunătăţirea controlului asupra activităţii de
gestiune economică;
• transformarea informaţiei privind costul producţiei în
instrument de reglare operativă;
• creşterea posibilităţilor de analiză economico-
financiară.

Dată fiind amploarea şi complexitatea lucrărilor din


domeniul informaticii, se impune elaborarea unui buget
pentru această activitate constituit din:
• bugetul investitiilor;
• buget de exploatare;
• buget de încasări şi cheltuieli.
Bugetul informatic asigură estimarea detaliată a efortului
şi efectelor elaborarii, introducerii şi exploatării
sistemului informatic. De asemenea prin buget se
realizeaza eşalonarea resurselor şi a modului lor de
utilizare pe etape, perioade şi responsabilităţi.

pagina 89
Sisteme informatice de gestiune

Estimarea eficienţei globale. Eficienţa 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 funcţionarea
sistemului informatic;
• Ci sunt cheltuielile iniţiale;
• Ce sunt cheltuielile de exploatare;
• Ps este profitul suplimentar.

Reducerea cheltuililor cu caracter informatic constituie


calea principală de creştere a eficienţei sistemului
informatic. Cu cât durata de recuperare a cheltuielilor cu
caracter informatic este mai mică, cu atât profitul
suplimentar este mai mare ca urmare a faptului că în
perioada dintre momentul recuperării cheltuielilor şi
abandonarea folosirii sistemului informatic, economiile
se transformă în profit. Eficienţa globală creşte şi ca
urmare a prelungirii duratei de viaţă a sistemului
informatic.
Din punct de vedere organizatoric, eficienţa
sistemului informatic se poate determina cu ajutorul
indicatorul "entropia informaţională" (H) prin care se
măsoară gradul de nedeterminare pe care îl înlătură
informaţiile din sistem. Diferenţa dintre entropia
informaţională calculată înainte şi după introducerea

pagina 90
Sisteme informatice de gestiune

sistemului informatic, semnifică, în cifre absolute,


creşterea gradului de organizare a întrepriderii.
Eficienţa globală a unui sistem informatic trebuie
apreciată şi prin prisma implicaţiilor introducerii
prelucrării electronice a datelor asupra conducerii:
• previziunea stărilor şi a funcţionării sistemului
economic capătă determinări realiste ca urmare a
elaborării şi a folosii unor modele adecvate;
• organizarea sistemului economic comportă
îmbunătăţiri substanţiale prin raţionalizarea structurii
organizatorice şi prin posibilitatea integrării
metodelor de conducere previzionară;
• deciziile primesc noi determinări calitative prin
sporirea gradului de obiectivitate;
• coordonarea activităţilor se bazează pe informaţii
necesare reglării funcţionării sistemului economic la
diverse nivele;
• se asigură controlul prin informarea operativă şi
oportună asupra dereglărilor care apar în
funcţionarea organismului economic.
Eficienţa sistemului informatic se exprimă şi prin prisma
timpului mediu de răspuns. Timpul mediu de răspuns
este diferenţa, în unităţi de timp, dintre momentul
punerii la dispoziţia utilizatorului a unei informaţii şi
momentul cererii informaţiei respective.
Aprecierea eficienţei economice cu ajutorul timpului
mediu de răspuns se realizează cu ajutorul
coeficienţilor:

Kt = tm0 /tm1

şi

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.

Eficienţa globală a sistemului informatic se estimează


prin raportul

Eg=Kc / Kt

care exprimă corelaţia 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 concepţie în
domeniul informaticii este, în primul rând, o lucrare de
creaţie în domeniul conducerii, incluzând problematica
perfecţionării mecanismului economico-financiar şi a
interacţiunilor micro şi macro economice. Activităţile de
informatică sunt menite să asigure condiţii de creştere a
producţiei prin reflectarea în sistemul informatic, a
factorilor de influenţă asupra rezultatelor financiare ale
întreprinderii.
Estimarea eficienţei economice a sistemului informatic,
având în vedere implicaţiile complexe ale realizării şi
exploatării componentelor informatice, atestă faptul că
sistemul informatic concură la promovarea eficienţei
economice în toate sectoarele de activitate prin creşterea
efectelor utile şi concentrarea efortului asupra acţiunilor
de concepţie ş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 informaţional 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 găsite incomplete, astfel că vor fi necesare iteraţii
şi corecţii care pot afecta soluţia propusă din puct de
vedere tehnologic, economic sau operaţional.
În această etapă obiectivul principal îl reprezintă
elaborarea componentelor funcţionale detaliate ale
sistemului şi a specificaţiilor de definire a programelor.
Sarcina activităţilor din această etapă ce se desfaşoară la
nivelul subsistemelor sau chiar al aplicaţiilor revine
integral analiştilor de sistem. Activităţile desfăşurate în
această etapă sunt:
• proiectarea funcţională detaliată pe componente şi a
legăturilor dintre acestea;
• stabilirea cerinţelor şi a condiţiilor tehnice de
realizare a programelor;
• elaborarea programelor de lucru pentru etapa
următoare şi stabilirea resurselor necesare.

Activităţile de proiectare tehnică au ca obiectiv


materializarea concepţiei sistemului informnatic prin
proiectarea funcţională amanunţită a componentelor
sistemului şi a legăturilor dintre componente. Pe baza
definirii complete şi precise a sistemului informatic din
etapele precedente, în etapa de proiectare tehnică sunt
concepute specificaţiile de realizare pe compnnente

pagina 93
Sisteme informatice de gestiune

(subsistem, aplicaţie). Proiectul tehnic rezultat din


desfăşurarea activităţilor etapei, pentru o componentă,
constituie baza programării şi a implementării
componentei respective.
Plecând de la ieşirile informaţionale dorite de
utilizator, sunt elaborate modelele de obţinere a ieşirilor
din intrările disponibile prin definirea colecţiilor de date
şi a procedurilor de tratare a datelor din colecţii. Aceste
activităţi urmăresc definirea detaliată a tehnologiei de
prelucrare a datelor. În elaborarea tehnologiei de
prelucrare a datelor, o deosebită atenţie trebuie acordată
proiectării fluxului tratării datelor urmărind ca, prin
colecţile de date şi fluxul prelucrărilor să se reflecte
fidel realitatea. De asemenea, prezintă interes major
verificarea funcţionalităţii componentelor proiectate sub
aspectul completitudinii şi al corectitudinii operaţiilor de
tratare a datelor. Perfornanţele sistemului informatic
sunt determinate, în mare măsură, de metodele de
organizeare a datelor.
Modalităţile de constituire a colecţiilor de date
sunt determinante asupra prelucrărilor, în timp ce
organizarea colecţiilor de date este condiţionată la
rândul ei de definirea fluxului tehnologic al datelor.
În organizarea datelor sunt determinante: studiile
pentru delimitarea ariei şi a legăturilor externe ale
sistemului informatic, modelele de obţinere a ieşirilor
din intrări, volumul datelor de prelucrat, cerinţele de
informare ale conducerii.
Metodelele utilizate în organizarea datelor sunt :
• metoda fişierelor independente,
• metoda bazei de date.

Metoda fişierelor independente constă în crearea de


fişiere pe suport accesibil prelucrării automate a
datelor, pentru înmagazinarea datelor prelucrate în

pagina 94
Sisteme informatice de gestiune

cadrul fiecărei componente a sistemului informatic. Un


fişier este constituit dintr-o submulţime de date
omogene relative la o clasă de elemente a sistemului
informaţional. (ex. fişierul de stocuri din aplicaţia de
gestiunea materialelor).
În general pentru fiecare entitate distinctă a
sistemului informaţional (materiale, produse, personal,
etc.) se constiuie fişiere cu caracter permanent care
reflectă starea elementelor la un moment dat. Operaţiile
curente din sistemul economic constituie tranzacţii şi
sunt reflectate în fişiere temporare. (ex:intrări şi ieşiri de
materiale). Prin aplicarea datelor operaţionale conţinute
în fişierele temporare asupra datelor de structură din
fişierele permanente rezultă ieşirile informaţionale
scontate şi se asigură actualizarea fişierelor permanente.
În urma actualizărilor fişierele permanente vor cuprinde
starea entităţilor "la zi".
Fişiere permanente (cartoteci, registre cataloage
etc.) şi fişiere temporare (centralizatoare, jurnale ...)
sunt utilizate şi în condiţiile prelucrării manuale a
datelor.
Metoda fişierelor independente asigură rapiditate
în organizarea datelor şi a prelucrărilor. În acelaşi timp
efortul de definire completă şi corectă a sistemului
informatic este mai redus prin proiectarea tehnică
detaliată a fiecărei componente şi integrarea ulterioară a
componentelor proiectate în sistemul informatic.
Această metodă este frecvent utilizată în practică pentru
probleme de mici dimensiuni.
Creşterea complexităţii sistemului duce la
creşterea numărului de fişiere necesare ceea ce
generează dificultăţi sporite de întreţinere. Utilizarea de
fişiere independente conduce la o flexibilitate redusă a
sistemului informatic, modificarea structurii fişierelor
implicând refacerea programelor care le utilizează. Prin

pagina 95
Sisteme informatice de gestiune

duplicarea datelor în mai multe fişiere se generează


redundanţe informaţionale, utilizarea neraţională a
suporţilor de informaţie şi dificultăţi în actualizarea şi
controlul datelor.
Pornind de la aceste neajunsuri constatate la
organizarea datelor în fişierelor independente se poate
folosi ca alternativa metoda bazelor de date. Datele din
sistemul informatic sunt organizate în colecţii care se
numesc baze de date şi care au o serie de proprietăţi şi
caracteristici ce vor fi arătate ulterior. Trecerea de la
fişierele independente către bazele de date s-a făcut în
timp prin mai multe etape:
• fiecare program de calcul utiliza date şi fişiere
specifice, proprii pentru obţinerea rezultatelor dorite.
(metoda fişierelor independente).
• mai multe programe folosite în rezolvarea unor
probleme similare, utilizau date şi fişiere comune,
grupate în colecţii mai mari specifice domeniului
respectiv.
• toate programele utilizate folosesc o colecţie unică
de date, o aşa zisă "bază de date" în care sunt
incluse toate datele necesare .
Necesitatea unor mari baze de date comune a fost
simţită nu numai de fabricanţii de calculatoare şi de
proiectanţii de sisteme informatice, ci şi de utilizatorii
sistemelor elaborate. Toţi au constatat că în sistemele de
o anumită mărime, în care se lucrează cu volume mari
de date, este nevoie să se găsească o serie de
modalităţi, 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 obţine informaţii uniforme, atât temporal cât


şi fizic. Se evită actualizarile parţiale a aceloraşi date
în fişiere diferite.
• Utilizarea aceloraşi date în mai multe activităţi.
Având un sistem unitar pentru definirea şi regăsirea
datelor, implementarea unor noi programe se face
relativ uşor. Procedurile folosite pe măsura
construirii şi dezvoltării sistemului fiind cât 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 mâna unui
singur grup coordonator (denumit în general
administrator al bazei de date).
• Independenţa datelor faţa de programe şi suporţii
fizici de memorare generează creşterea calităţii şi
fiabilităţii sistemului informatic.

Deoarece nu există o definiţie general acceptată, vom


denumi o bază de date "un absamblu unitar organizat şi
structurat de date a cărui gestionare se face printr-un
sistem specializat denumit sistem pentru gestionarea
bazelor de date (SGBD)". Prin gestionarea bazelor de
date se întelege îndeplinirea unor funcţii 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 prelucrările
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 concepţia modernă de realizare a sistemelor
informatice "banca de date" devine subsitemul central,
prin el realizându-se principalele legături dintre
majoritatea celorlalte subsisteme şi aplicaţii în primul
rând 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 primeşte răspuns la cererile de informaţii pe


care le face direct pentru el sau pentru alte persoane.
Sunt mai multe categorii de utilizatori:
• utilizatorul profesionist care pentru a primi
răspunsurile solicitate scrie programe, deci are
cunoştinţe de programare;
• utilizatorul nespecialist, care pentru formularea unor
întrebări, scrie o serie de comenzi sau instrucţiuni
relativ simple, dar pentru a căror utilizare are nevoie
de un anumit instructaj (câteva zile);
• utilizatorul nespecialist, de cele mai multe ori un
conducător, care nu trebuie să facă decât nişte
operaţii elementare pentru a obţine informaţiile
dorite (utilizatori "press-button").

Administratorul bazei de date este o funcţie absolut


necesară pentru buna funcţionare a SGBD-ului. Se
constată că administratorul bazei de date este necesar
totdeauna în cadrul sistemelor informatice chiar când 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,


modificările ce li se aduc şi accesul la ele.
Administratorul trebuie să acorde o deosebită atenţie
factorilor care afectează memorarea şi regăsirea datelor
şi de aceea are nevoie de cunoştinţe aprofundate privind
datele necesare în cadrul organizaţiei ş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
combinaţie de echipamente de calcul şi de programe
care asigură accesul la date conform instrucţiunilor
primite de la utilizatori şi de la administrator. În acest
scop gestionarul trebuie să aibă o interfaţă cu toate
limbajele de programare convenţionale admise de
SGBD-ul respectiv. Gestionarul îndeplineşte unele funcţii
care în sistemele anterioare erau îndeplinite de
compilatoare, asambloare, editoare de legături,
programe utilitare, etc.. Gestionarul formează un fel de
graniţă între programele de aplicaţie şi mecanismele de
acces la date. Gestionarul interpretează cererile de date
"logice" ale diverşilor utilizatori şi cu ajutorul
mecanismelor sale de acces extrage şi transferă datele
solicitate de aceştia. Utilizatorul nu ştie cum şi unde
sunt memorate datele. Se spune că tot acest proces este
"transparent" utilizatorului, în sensul că este parcurs fără
a fi cunoscut de el în mod intim, ci numai în principiu.
Prin metoda bazei de date se urmăreşte
organizarea datelor din sistem astfel încât datele
memorate pe suport magnetic de mare capacitate să
răspundă necesităţilor de prelucrare şi utilizare ale
tuturor componentelor sistemului informatic şi ale
tuturor utilizatorilor. Respectarea principiilor privind
unicitatea datelor, independenţa datelor, consultarea
concurentă a datelor necesită efectuarea analizei şi

pagina 99
Sisteme informatice de gestiune

proiectării sistemului informaţional prin abordare


globală şi structurarea lui detaliată.
Activităţile ce ar trebui realizate pentru
determinarea specificaţiei logice de definire a bazei de
date sunt:
1. Trecerea în revistă a tuturor cerinţelor de informare
necesare pentru rezolvarea diverselor probleme. Cu
acest prilej se va stabili o ordine de prioritate în
înlocuirea subsistemelor şi lucrărilor 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 cerinţelor de informare cu stabilirea
legăturilor informaţionale 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 întocmeşte pe baza rezultatelor obţinute în
activităţile anterioare, specificaţia pentru baza de
date, care este o documentaţie ce cuprinde:
• datele şi structurile de date propuse a fi incluse în
baza de date;
• o schemă care să reprezinte legăturile
informaţionale dintre subsisteme şi aplicaţii;
• schema cu structurile logice de date şi legăturile
dintre ele;
• restricţiile hardware şi software avute în vedere;
• cerinţele suplimentare pentru SGBD-ul care
urmează să fie utilizat cum ar fi: volumul
intrărilor, al ieşirilor, timpii de răspuns solicitaţi,
principalele prelucrări, etc.
În funcţie de datele de memorat şi de relaţiile dintre ele
într-o bază de date pot să apară următoarele tipuri de
structuri:

pagina 100
Sisteme informatice de gestiune

• structura punctuală pentru entităţi independente;


• structura ierarhică liniară pentru entităţi cu relaţii
liniare între ele;
• structura ierarhică arborescentă pentru descrierea
relaţiilor dintre entităţi de tipul “un tată are mai mulţi
fii”;
• structura de tip reţea pentru entităţi cu relaţii
complexe între ele, rezultată prin generalizarea
structurilor ierarhice liniare şi arborescente;
• structura relaţională când datele nu mai sunt privite
ca înregistrări ci ca relaţii.
Buna funcţionare a unui sistem informatic lucrând cu
conceptul de baza de date depinde în mare măsură de
modul cum se proiectează această bază de date.
Alegerea variantei de proiectare a circuitului
informaţional este condiţionată de modul în care aceasta
asigură funcţionalitatea componentei respective.
Verificarea funcţionalităţii necesită stabilirea
posibilităţilor de obţinere a datelor de ieşire din datele
de intrare ale componentei proiectate. Descrierea
condiţiilor logice şi a regulilor de obţinere a datelor de
ieşire 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 uşor de citit. Plecând de la ideea că orice
operaţie sau ansamblu de operaţii poate fi condiţionată
sau necondiţionată, tehnica tabelelor de decizii dă o
formă tabelara procesului de prelucrare a datelor.
O tabelă de decizii este constituită din patru părţi
(cadrane):
1. condiţii (criterii) pentru luarea deciziilor (C1;
C2;...Cm);

pagina 101
Sisteme informatice de gestiune

2. intrări ale condiţiilor (IC); combinaţii ale intrărilor


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

CADRANUL I CADRANUL II
(condiţii) (intrări ale
condiţiilor)

CADRANUL III CADRANUL IV


(decizii) (intrări ale
deciziilor)

Figura 4.7. Cadranele unei tabele de decizii

Tabela de decizii descrie toate variantele posibile ale


valorilor condiţiilor şi deciziile corespunzătoare fiecărei
combinaţii a acestor valori în soluţionarea unei
probleme. Citirea tabelei de decizii se face de sus în jos
astfel: "dacă se realizează condiţia C1 şi dacă se
realizează condiţia 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
calităţii
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 funcţie de valorile întâlnite pentru intrările condiţiilor


tabelele de decizii pot fi:

a) cu intrări limitate; când intrările condiţiilor sunt


explicitate numai prin valori DA sau NU (0 sau 1);
b) cu intrări extinse; când intrările fiecărei condiţii ale
unei tabele de decizii sunt explicitate prin mai multe
valori (0, 1, 2,...);

pagina 103
Sisteme informatice de gestiune

c) cu intrări mixte; când din necesităţile analizei


problemei rezultă condiţii cu intrări 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 specificaţiile de realizare au fost


întocmite şi aprobate, ele vor fi repartizate diverselor
grupe de specialişti care au responsabilitatea să le
execute şi ulterior să le asambleze. Etapa este
consacrată elaborării programelor şi procedurilor
manuale, aferente componentelor sistemului informatic,
precum şi testării componentelor. În funcţie de
necesităţile problemei dar şi de cunoştinţele
proiectanţilor, în această etapă se pot folosi tehnici de
programare ca:
• programarea modulară;
• programarea structurată;
• programarea orientată pe obiecte;
sau , eventual soluţii hibride conform nivelului de
stăpânire a tehnicilor respective.

Programarea modulară. Operaţia de împărţire a unei


probleme complexe, concepută din punct de vedere
logic ca un tot unitar, nu este uşoară pentru că
întotdeauna trebuie avut în vedere ca părţile în care a
fost descompus întregul să nu-i schimbe scopul iniţial şi
totodată să permită, relativ usor, reconstituirea
întregului atunci când este necesar. În acest sens trebuie
respectate două reguli:
• fiecare componentă trebuie să îndeplinească o
anumită funcţie bine precizată în cadrul întregului;
• între componente este necesar să se stabilească
foarte exact legăturile, astfel ca fiecare parte să-şi
poată realiza relativ independent funcţia specificată
şi în acelaşi timp să poată contribui la funcţiile
generale ale întregului.

pagina 105
Sisteme informatice de gestiune

Prin modularitate înţelegem proprietatea sau


posibilitatea ca un proces să poată fi descompus în
parţi componente, cu legături bine stabilite între ele,
astfel ca obiectivul general al procesului să poată fi cât
mai eficient realizat. Una din definiţiile date noţiunii
generale de modularitate aparţine lui Russel Armstong,
care considera că un sistem este modular atunci când
este realizat dintr-o mulţime de elemente căreia îi este
asociată o lege de structură. A găsi legea de structură
înseamnă a prospecta interfaţa dintre module. După
acelaşi autor, proiectarea interfeţei dintre module este
simplificată dacă modulele au fost concepute astfel încât
să aibă o funcţionalitate 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 număr
mare de utilizatori, răspândiţi uneori pe zone întinse;
• cerinţele utilizatorilor sunt mereu schimbate şi
completate.

Ţinând 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 - aplicaţie.

a) Sistemul informatic trebuie să urmărească şi să


contribuie la realizarea obiectivelor generale ale
întreprinderii, fixate pe o perioadă lungă de timp.
Deoarece obiectivele şi restricţiile generale se pot

pagina 106
Sisteme informatice de gestiune

schimba în timpul realizării 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ă decât cea prevazută pentru realizarea şi
implementarea sistemului informatic, pot aparea
neconcordanţe imprevizibile, care pot conduce la
efecte negative.
b) Subsistemul corespunde, de regulă, unor obiective
derivate din cele generale, rezultate prin detalierea
acestora. Există unele tendinţe de împărţire a
sistemelor informatice în subsisteme după structura
ierarhică şi organizatorică astfel:
• strategic
• tactic
• operativ,
sau după precizarea funcţiilor sale:
• producţie
• comercial
• financiar-contabil
• personal
• cercetare- dezvoltare.
Între aceste componente (subsisteme) trebuie să
existe legături (interfeţe) clare, cât mai puţine şi cât
mai rigide, în sensul că odată stabilite să nu mai fie
practic modificate.
c) Aplicaţia, ca unitate componentă a subsistemului,
contribuie în general la satisfacerea unor obiective
specifice şi se dezvoltă de obicei la nivelul unor
compartimente sau activităţi din cadrul întreprinderii.
În structura sistemului pe trei nivele aplicaţia se
găseşte pe ultimul nivel, şi construirea sistemului
informatic se face treptat prin realizarea de aplicaţii
asamblate în cadrul nivelurilor superioare.

pagina 107
Sisteme informatice de gestiune

Adâncind nivelul de detaliere al sistemului informatic


putem adăuga încă două nivele:
d) program;
e) modul de program.

d) Aplicaţia la rândul ei este constituită dintr-o serie de


programe şi proceduri manuale legate între ele şi
care îndeplinesc funcţiile cerute.
e) La rândul lor programele sunt de cele mai multe ori
divizate în mai multe părţi, numite "module
program" independente din punct de vedere logic.
Modulele sunt compuse din instrucţiuni scrise într-
un limbaj de programare.

La nivelul programelor modularitatea se mai numeşte şi


micro modularitate. Corelarea modulelor sau cuplarea
modulelor este o măsura a independenţei modulelor, şi
poate avea mai multe forme:
• corelarea externă, când modulele utilizează aceleaşi
date globale ale sistemului;
• corelarea prin control, când unul din module
controlează execuţia celorlalte în mod explicit, prin
chei de control sau variabile de control a căror
valoare indică modul de continuare a execuţiei;
• corelarea internă sau prin conţinut, când un modul
referă direct alt modul;
• corelarea prin date, când la apelarea unui modul de
către altul toate datele de intrare sau de ieşire ale
modulului apelat sunt comunicate sub formă de
parametrii.

Un alt element caracteristic este ponderea sau tăria


modulelor care reflectă modul de formare şi conţinutul
modulului. Există mai multe posibilităţi de divizare a
programelor în module şi anume:

pagina 108
Sisteme informatice de gestiune

• divizarea întâmplătoare, care dă tăria cea mai slabă


modulelor căci programul este împărţit arbitrar în
module;
• divizarea logică, are ca rezultat module ce efectuează
o funcţie la fiecare apelare;
• divizarea clasică, prin care modulul efectuează mai
multe funcţii necorelate între ele prin date;
• divizarea prin comunicare, când modulele efectuează
mai multe funcţii corelate prin date;
• divizarea funcţională, când modulele efectuează o
singură funcţie care le este specifică.

Modularizarea este una din sarcinile principale ale


proiectanţilor de sisteme informatice şi este în cele mai
multe cazuri, o operaţie complicată de care depinde în
mare măsură modul cum va funcţiona în final sistemul.
În acest scop, în cadrul proiectelor mari, pe baza unor
experienţe anterioare, adaptate la specificul respectiv, se
elaborează reguli şi chiar norme care trebuie avute în
vedere la împărţirea î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 funcţie unică, lucru extrem de


avantajos atunci când se fac modificări;
• să fie complet;
• să aibă cât mai puţine interfeţe cu ale module;
• să permită o înţelegere uşoară a problemelor pe care
le rezolvă;
• să se poată încadra în diversele tipuri de
modularitate ale sistemului.

Avantaje ale modularizării:

pagina 109
Sisteme informatice de gestiune

1) Posibilitatea divizării întregului în părţi mai simple şi


mai uşor de realizat.
2) Independenţa modulelor permite elaborarea şi
testarea separată a acestora.
3) Fiecare modul poate fi realizat prin tehnicile
(limbajele) cele mai adecvate funcţiei pe care o
îndeplineşte.
4) Posibilitatea construiri a unei biblioteci de module
testate (module standard) disponibile tuturor
proiectanţilor.
5) Simplificarea întreţinerii sistemului (programului).
6) Permite abordarea de la simplu la complex şi permite
o încărcare echilibrată a fiecarui membru din echipa
de proiectare.

Dezavantajele modularizarii:
1) Mulţi proiectanţi nu înţeleg modularizarea sau nu se
pot acomoda cu ea.
2) Modularitatea cere eforturi suplimentare în faza de
proiectare.
3) Proiectanţii nu cunosc problema în ansamblu ci
numai parţi ale ei.
4) Concepţia modulară duce la realizarea de programe
care încarcă suplimentar unitatea centrală a
calculatorului cu funcţiile de dispecerizare şi
comunicare între module.

Noţiunea de modularitate este însoţită 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
cunoaştere se începe cu aspectul general, "în mare" al
fenomenului, după care, treptat, acesta se detaliază, se
cunoaşte în profunzime, până la un anumit nivel,
considerat suficient pentru scopul urmărit. Dacă

pagina 110
Sisteme informatice de gestiune

modularizarea înseamnă procesul de descompunere a


unui întreg în părţi componente, metoda cea mai
obişnuită, pentru ca împărţirea să fie corect făcută, este
tocmai cea "top-dovn".
Trăgând o concluzie mai generală, se poate spune că
în orice fel de proces de cunoaştere 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 preocupări pentru scăderea
raportului cost/ performanţă, prin aplicarea unor
principii de structurare atât în fazele de proiectatre cât ş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 rând la:
• Identificarea funcţiilor necesare pentru realizarea
produsului, analog cu determinarea părţilor
componente ale unui produs industrial.
• Descompunerea consecvent descendentă (top-down)
în procesul de identificare a funcţiilor componente
ale proiectului. Introducând noţiunea de "nivel al
functiilor" (Nf) şi punând convenţional nivelul
rădăcinii structurii Nf=0, putem defini nivelul unei
funcţii oarecare ca fiind egal cu nivelul funcţiei din
care descinde plus unu. Funcţiile cu nivelul cel mai
ridicat se mai numesc şi "primitive" ale structurii iar
cea cu nivelul zero se numeşte rădăcina structurii.
• Realizarea modulară a produsului, presupune
izolarea funcţiilor găsite în faza de identificare, apoi
determinarea interfeţelor dintre module.

pagina 111
Sisteme informatice de gestiune

• Normalizarea primitivelor structurilor funcţionale


(primitivele structurii).

La un anumit nivel de descompunere în ierarhia


funcţiilor unei structuri se găsesc algoritmii de rezolvare
ai subproblemelor. Pentru realizarea oricărui algoritm
este suficientă utilizarea unui set restrâns de structuri
funcţionale 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 programării structurate prezentăm o serie de
definiţii posibile apărute pe o perioadă mai lungă de
timp, cu menţiunea că cele din anii de început ai
conceptului prezintă mai mult constatări de
circumstanţă şi au o notă uşor ironică:
1. Este o întoarcere la bun-simt.
2. Este metodă generală după care programează cei mai
buni programatori.
3. Este programarea fără GO TO.
4. Este procesul prin care se controlează numărul de
interacţiuni dintre un proces şi contextul său, astfel
încât numărul de interacţiuni să fie o funcţie liniară
depinzând de câţiva 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 încât să poată fi reprezentate
prin iterarea şi compunerea unui număr mic de
structuri logice de control standard.
7. Este o manieră de a organiza şi codifica programe
astfel încât să fie cât mai uşor de înţeles şi de
modificat.

pagina 112
Sisteme informatice de gestiune

8. Scopul programării structurate este de a controla


complexitatea prin teorie şi disciplină.
9. Programarea structurată poate fi caracterizată nu
prin absenţa instrucţiunii GO TO ci prin prezenţa
structurii.
10. O funcţie majoră a structurii programelor este de a
face posibilă demonstrarea corectitudinii lor.
11. Programarea structurată nu este o soluţie totală, ea
constă, de fapt, în folosirea unor notaţii formale
pentru a gândi ordonat.
12. Procesul de organizare a gândirii care duce la o
expresie inteligibilă a procesului de calcul într-un
timp rezonabil.
13. Arta simplităţii.

Sintetizând se poate ajunge la următoarea definiţie:


"Programarea structurată constă dintr-o mulţime de
restricţii şi reguli de programare care forţează
programul să urmeze o formă strânsă, în acest fel
eliminându-se mulţi din factorii care conduc la erori şi
care complică activitatea de testare şi întreţinere."
Examinarea structurii interne a unui program,
evidenţiază existenta unei structuri ierarhice între
componentele unui program, fiecare componentă fiind
coordonată de componenta de nivel superior şi
coordonând 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 încât
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

• SECVENŢA care marchează grupul de enunţuri care


se execută în ordinea în care au fost scrise.
• SELECŢIA care marchează separarea enunţurilor în
două grupe şi executarea unei sau alteia din aceste
grupe în funcţie de o anumită condiţie.
• ITERAŢIA care marchează un grup de enunţuri cu
execuţie repetată de un număr de ori (inclusiv
repetarea de zero ori ceea ce echivalează cu
eliminarea grupului de enunţuri).

Regulile de structurare ale blocurilor sunt:


• punctul de intrare într-un bloc este unic;
• punctul de ieşire dintr-un bloc este unic;
• blocul iterativ începe prelucrarea prin testarea
condiţiei de ieşire din ciclu;
• un bloc poate conţine orice combinaţie de blocuri
care satisfac condiţiile 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
următoarelor reguli:
• nivelele de detaliere se parcurg de sus în jos;
• fiecare nivel reprezintă o detaliere a nivelului
precedent;
• blocurile situate pe un acelaşi nivel ierarhic se
parcurg de la stânga la dreapta;
• terminarea parcurgerii unui nivel presupune
parcurgerea următorului bloc din nivelul anterior.

Regulile de citire a diagramei de structură sunt:

pagina 114
Sisteme informatice de gestiune

• Citirea operaţiei de trecere de la un nivel superior


către un nivel inferior se face utilizând expresia
"constă din".
• Citirea operaţiei de trecere de la un bloc la alt bloc de
pe acelaşi nivel se face utilizând expresia "urmat de".
• Citirea operaţiei de trecere de la un nivel inferior
către un nivel superior se face prin trecerea la
următorul bloc al nivelului superior utilizând
expresia "urmat de".
• Un cerculeţ marcat în colţul din drapta sus al unui
bloc identifică un bloc opţional şi se citeşte utilizând
expresia "sau".
• Un asterisc marcat în colţul din dreapta sus al unui
bloc identifică un bloc cu execuţie repetată şi se
citeşte utilizând expresia "mai multe".

Reprezentarea blocurilor “nested-logic” utilizate în


diagrama de structura şi corespondenţa lor cu
reprezentarea din schemele logice clasice este
prezentată in figura 4.9.

TEOREMA DE STRUCTURĂ: Oricare ar fi schema logică S


aparţinând mulţimii schemelor logice clasice şi care
reprezintă structura logică a unui proces de prelucrare,
există cel puţin o transformare T pentru care S'= T(S)
astfel încât:
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 atenţiei era acordată descrieirii
structurilor de date deoarece, practic, prelucrările
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 creşterea complexităţii programelor, a
apărut necesitatea unei organizări riguroase a muncii.
Ca o etapă superioară capabilă să rezolve în bună
măsură problemele ivite, s-a impus programarea
structurată. De-a lungul anilor, în special datorită
pagina 116
Sisteme informatice de gestiune

creşterii dimensiunii produselor software, şi acest


instrument a devenit la rându-i depăşit. Sporirea
complexităţii programelor aducea după sine dificultăţi
reale legate de întreţinerea unor programe mamut. Cu
alte cuvinte, deşi preţul produselor era în creştere,
calitatea lor tindea să scadă.
În căutarea unei soluţii care să scoată informatica din
situaţia 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 căutărilor, au
apărut limbaje având la bază noţiunea de "cadru"
("frame") şi cele care pornesc de la ideea de "acţiune",
ambele noţiunii folosite în inteligenţa artificială. Prima
categorie implementează "operaţii" asupra unor "modele
de entităţi" iar cea de a doua susţine faptul că "obiectele
nu sunt simple elemente pasive asupra cărora se fac
prelucrări, ci, dimpotrivă, menirea obiectelor rezidă în a
activa prelucrările ce le vor suporta ele însele.
Deşi teoria programării orientate pe obiecte era
bine fundamentată de peste 20 de ani, ideea nu a prins
cu adevărat decât în ultimii ani. Programarea pe obiecte
în loc să separe iremediabil datele de cod nu face altceva
decât să contopească cele două elemente.
Primele limbaje cu adevărat 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 penetrării pe piaţă, a fost însuşi faptul că au apărut ca
limbaje de sine stătătoare, având o răspândire relativ
redusă. Din acest motiv puţini programatori erau dispuşi
să abandoneze limbajele consacrate în acele momente,
doar de dragul de a lucra obiectual. O bună perioadă de
timp metoda programării obiectuale a fost uitată.

pagina 117
Sisteme informatice de gestiune

În anii '80 în urma acceptării 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 naştere prima versiune a noului limbaj C++.
Aproape imediat apar şi partizanii fanatici ai OOP-ului
aflat acum la a doua tinereţe. Termenul de OOP provine
din "Object Oriented Programming" care desemnează
disciplina programării obiectuale sau orientată-obiect.
Profitând deci de marea popularitate în rândul
soft-iştilor şi de multitudinea domeniilor de aplicaţie (de
la grafica interactivă la exploatarea reţelelor de
calculatoare şi chiar până la proiectarea compilatoarelor)
moftul devine modă şi moda certitudine. Acest succes
extraordinar s-a datorat faptului că limbajul C++ nu
face nimic altceva decât să-i dea un nou avânt unuia
dintre cele mai la moda limbaje ale momentului "C".
OOP introduce conceptul de INCAPSULARE prin
care se ating următoarele obiective:
• facilitatea deosebită de localizare a erorilor
• modularizarea problemei de rezolvat.

Notiunea de “clasă” conţine declaraţii de variabile


şi declaraţii de funcţii care operează asupra variabilelor.
Funcţiile se numesc funcţii membru sau metode iar
variabilele variabile membru. Cu ajutorul claselor, un
programator îsi poate defini orice tip de dată dorit,
împreună cu setul de operaţii. Toate aceste informatii
sunt încapsulate într-o “clasă”. Astfel prin “clasă” vom
înţelege 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 instanţiere (o
realizare) a unei clase. Prin intermediul claselor se pot
separa informaţiile de implementare (mecanism intern)
de cele de utilizare (mecanism extern).

pagina 118
Sisteme informatice de gestiune

Un alt termen introdus de OOP, este


“moştenirea”. În urma definirii unei clase, cu un minim
de efort şi timp se pot preciza seturi de clase
asemănatoare, având totuşi o trăsătură distinctivă.
Având o clasă B putem defini o altă clasă D care să
moştenească sau să preia toate caracteristicile clasei B la
care să se poată adăuga altele noi, proprii doar acesteia
din urmă. Prima clasă se va numi "clasă de bază" iar cea
de-a doua "clasă derivată". Moşetenirea stă la baza altor
concepte novatoare cum ar fi “polimorfismul” dar
elementul esenţial al programarii obiectuale rămâne
"încapsularea".
“Polimorfismul” constă în faptul că într-o ierarhie
de clase obţinute prin moştenire, o metodă poate avea
forme diferite de la un nivel la altul, specifice
respectivului nivel din ierarhie. Aşa cum în lumea vie
hrănirea este universal valabilă ea deosebindu-se de la o
clasă la alta de vietăţi, tot aşa şi în cazul OOP metoda
poate avea forme diferite de la o clasă la alta.
În momentul de faţă piaţa informatică este
invadată de biblioteci şi colecţii de clase. Menirea lor
este de a permite un coeficient cât mai ridicat de
reutilizare a codului scris. Pe de altă parte, pornind de la
aceste clase, utilizatorul poate crea prin moştenire alte
clase, care să-l ajute să-şi rezolve problema în mod
optim. În plus, programatorul are garanţia folosirii unor
proceduri scurte, inteligibile şi nu în ultimul rând
corecte.
Un alt domeniu de utilizare a bibliotecilor de clase
este cel al realizării prototipurilor unor produse
software. Prin prototip se înţelege un program
funcţional, 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
producătorului, clientul poate avea o imagine destul de

pagina 119
Sisteme informatice de gestiune

clară asupra produsului final. Pentru o aplicaţie oarecare


prototipul nu trebuie să conţină algoritmul optim,
clientul urmând 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 întreţinerea.

Implementarea este etapa în care sistemul se


testează în condiţii reale. Etapa începe când
componentele individuale, care au fost testate şi
acceptate, pot fi asamblate pentru testarea şi includerea
în sistem pe baza specificaţiilor şi manualelor elaborate
în etapa anterioară.
Circuitul informaţional existent este înlocuit cu
noul circuit prin lansarea în execuţie a programelor şi
verificarea practică a modului de obţinere a rezultatelor,
acestea constituind activităţile de implementare a
sistemului informatic.
Etapa se consideră terminată când sistemul este
acceptat de beneficiar. Unele activităţi pregătitoare ale
implementării pot începe încă din etapa precedentă.
Activităţile aferente implementării sunt următoarele:

• pregătirea implementării;
• executarea procedurilor de conversie;
• testarea în condiţii reale;
• evaluarea rezultatelor obţinute şi verificarea
performanţelor sistemului;
• definitivarea documentaţiei.

Etapa de exploatare începe când informaţiile din


sistem sunt furnizate în mod curent beneficiarului. În
paralel cu exploatarea sistemului se desfăşoară
întreţinerea sistemului. Exploatarea este legată de
problemele curente zilnice ale menţinerii sistemului în
stare de funcţionare, în timp ce întreţinerea constă în
activităţi de evaluare periodică legate de modificările ce
trebuiesc făcute pentru a menţine 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 reprezentări sub
forma de text a realităţii aşa cum a fost ea înteleasă de
analist. Ea se rezumă la descrierea literară ca urmare a
analizei, putându-se deduce din aceasta entităţile,
asociaţiile etc. care vor constitui mai departe modelul
conceptual al datelor.

Concepte utilizate în MCD

a) entitate - este reprezentarea în sistemele


informaţionale a unui obiect material sau imaterial
având o existenţă proprie şi conformă cu necesităţile
gestiunii întreprinderii.
În general se utilizează un substantiv comun ca
nume de entitate, nume ales astfel încât să sublinieze
cât mai bine relaţia cu componenta din sistem pe care o
reprezintă.

b) realizarea unei entităţi - este un element


individualizat apartinând entităţii. Spre exemplu
informaţiile relative la salariatul Popescu sunt o realizare
a entităţii SALARIAT.

c) asociaţia - reprezintă o relaţie între entităţi. Numărul


entităţilor care intervin în relaţie caracterizează
dimensiunea asociaţiei:
• asociaţii binare între două entităţi;

pagina 122
Sisteme informatice de gestiune

• asociaţii ternare între trei entităţi;


• asociaţii n-are între n entităţi.
În general se utilizează ca nume de asociaţie un verb
care să sublinieze cât mai bine relaţia dintre entităţi.
Spre exemplu asociaţia LUCREAZA permite să se
înţeleagă faptul că un SALARIAT lucrează într-o SECTIE.

Figura 4.10. Asociaţie

d) realizarea unei asociaţii - este o asociaţie


individualizată adică o pereche, triplet, etc. constituit
dintr-o singură apariţie a fiecărei entităţi participante la
relaţie.
Spre exemplu în afirmaţia "salariatul Popescu
lucrază în departamentul Personal" cuplul
Popescu/Personal este o realizare a asociaţiei
LUCREAZA.

e) asociaţie reflexivă - este o relaţie care există între


realizarea unei entităţi şi o altă realizare a aceleiaşi
entităţi. Spre exemplu asociaţia INCADRAT este o
asociaţie reflexivă care traduce faptul că un anumit
SALARIAT are posibilitatea de a încadra (angaja) alţi
salariaţi.

pagina 123
Sisteme informatice de gestiune

Figura 4.11. Asociaţie reflexivă

f) legătura - reprezintă o relaţie între o entitate şi o


asociaţie. Ea este caracterizată prin cardinalitatea sa. Se
poate distinge printr-un nume, ceea ce este foarte
practic în cazul asociaţiilor reflexive.

g) cardinalitate - permite să se exprime funcţionalitatea


şi totalitatea sau parţialitatea unei relaţii:
• cardinalitatea minimală - este numărul minim de
participări ale realizări unei entităţi la realizările unei
asociaţii;
• cardinalitatea maximală - este numărul maxim de
participări ale realizării unei entităţi la realizările
unei asociaţii.

pagina 124
Sisteme informatice de gestiune

Figura 4.12. Cardinalitate

Spre exemplu dacă se examinează MCD-ul următor:

Figura 4.13. Exemplu cu entităţi, asociaţie şi


cardinalităţi

se poate spune că aceste cardinalităţi indicate între


entităţile SALARIAT şi asociaţia LUCREAZA se traduc
astfel:
• orice salariat lucrează în cel puţin o secţie,
• orice salariat lucrează în cel mult o secţie,
• adică orice salariat lucrează într-o singură secţie. În
acelaşi fel cardinalităţile dintre SECTIE şi asociaţia
LUCREAZA se traduc prin: într-o secţie lucrează cel
pagina 125
Sisteme informatice de gestiune

puţin un salariat şi într-o secţie lucrează cel mult n


salariaţi, adică mai mulţi salariaţi.

Se constată că toate cardinalităţile 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.
Cardinalităţile principale sunt constituite din
următoarele combinaţii:
0,1 - niciunul sau unul singur
1,1 - unul şi unul singur
0,n - niciunul sau mai mulţi
1,n - cel puţin unul sau mai mulţi
Este posibil să se genereze şi alte cardinalităţi decât
acestea, spre exemplu 0,2 dar în modelul fizic al datelor
cardinalităţile superioare lui 1 sunt transformate în
cardinalităţi n.

h) informaţia - este componenta elementară a


sistemelor informaţionale. (ex. nume, prenume, cod
postal, etc.)

i) domeniul - permite să se formalizeze ansamblul


valorilor care stau la baza informaţiilor. Toate valorile
luate de informaţii şi care sunt transferate entităţilor
constituie ansamblul valorilor din sistemele
informaţionale.
Exemple: domeniul dobânzilor - numere pozitive cu 7
întregi şi 2 zecimale; domeniul numelor - alfabetic cu
majuscule.

j) proprietate - este informaţia care se ataşază unei


entităţi sau unei asociaţii. Ea poate referi un domeniu

pagina 126
Sisteme informatice de gestiune

deci ea îi poate moştenii caracteristicile (tip, lungime,


listă de valori).
Numele fiecărei proprietăţi poate fi înscris în
simbolul entităţii sau asociaţiei atunci când acestea sunt
purtătoare de atribute.
Exemplu: entitatea SALARIAT are proprietăţile
marca, nume, prenume, iar asociaţia INCADRAT are
proprietăţile data de început şi data de sfirsit.

Figura 4.14. Proprietăţi

k) identificatorul unei entităţi - este constituit din una


sau mai multe proprietăţi particulare ale unei entităţi
astfel încât la fiecare valoare a identificatorului
corespunde o singura realizare a entităţii.
Toate entităţile trebuie să posede un identificator
care poate fi compus din una sau mai multe proprietăţi.
Prin convenţie proprietăţile cu rol de identificator sunt
subliniate.
De exemplu proprietatea MARCA este
identificatorul entităţii SALARIAT adică poate defini fără
ambiguitate fiecare salariat.

pagina 127
Sisteme informatice de gestiune

Figura 4.15. Identificator

l) identificatorul unei asociaţii - este intotdeauna


obţinut prin concatenarea indentificatorilor entităţilor
participante la asociaţie. Acest identificator nu figurează
în MCD.

m) legatură-identificator. S-a văzut necesitatea ca


fiecare entitate să aibă un identificator, dar în anumite
cazuri acesta nu este suficient.
Dacă se urmăreste MCD-ul următor:

Figura 4.16. Legatură identificator

pagina 128
Sisteme informatice de gestiune

se constată că cele două entităţi sunt legate printr-o


relaţie de compoziţie.
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ă lucrări să aibă
acelaşi cod dacă ele aparţin unor proiecte diferite, se va
putea identifica fară ambiguitate o lucrare prin codul său
şi prin codul proiectului căruia îi aparţine.
În acest caz legătura care porneşte de la entitatea
elementară este numită LEGATURĂ-IDENTIFICATOR, şi
are obligatoriu cardinalitatea 1,1.
Pe grafic această cardinalitate apare între
paranteze, diferenţiindu-se în acest fel de o legatură
1,1 normală.

n) legatura de moştenire. Moştenirea poate fi exprimată


ca o legătură particulară între entităţi în acelaşi timp
foarte apropiate dar totuşi diferite. Datorită acestui
concept de entitate generală sau mamă, se exprimă
caracteristicile comune mai multor entităţi formând o
aceiaşi familie.
Conceptul complementar de entităţi specializate,
particulare sau fiice ale unei entităţi generale exprimă
caracteristicile proprii fiecărui membru al familiei. Se
vorbeşte de asemenea de legături generice între entităţi
tip şi sub-tip. Toate proprietăţile definite pentru
entitatea generală sunt moştenite de către entităţile
specializate. În acelaşi timp toate asociaţiile unei
entităţi generale sunt valabile pentru entităţile
specializate.
Această noţiune permite îmbogăţirea
considerabilă a MCD punând în evidenţă noţiunile de tip
şi sub-tip în sînul unei aceleiaşi entităţi.

pagina 129
Sisteme informatice de gestiune

În plus ea permite utilizatorului să genereze un


MFD care ţine cont într-adevar de specificaţiile arătate.
Se evită astfel, fie redundanţa informaţională fie
înlocuirea coloanelor care au valori nule.
Fie de exemplu entitatea ANGAJAT, care cuprinde
angajaţii de gen masculin şi pe cei de gen feminin. Se
poate reprezenta această particularitate prin noţiunea de
moştenire considerând entităţile ANGAJAT MASCULIN şi
ANGAJAT FEMININ ca entităţi specializate ale entităţii
generale ANGAJAT.
Reprezentarea constă într-o legătură cu sageată
care pleacă din entitatea fiică şi puncteză entitatea
mamă. Un simbol în forma de semicerc este desenat în
mijlocul legăturii şi serveşte ca punct de întâlnire pentru
alte legături venind de la alte entităţi fiică.

Figura 4.17. Moştenire

Reguli de normalizare a MCD

Elaborarea unui MCD se realizează în mai multe


etape, şi este adesea supusă modificărilor pe parcursul
realizării proiectului informatic. Una din etapele
pagina 130
Sisteme informatice de gestiune

esenţiale ale realizarii unui MCD este verificarea


modelului aplicând un numar de reguli numite reguli de
normalizare. Se obţine în acest fel un modelul cu
redundanţă minima în stocarea datelor.

REGULA 1.
Toate entităţile trebuie să posede un
identificator.

REGULA 2.
Toate proprietăţile unei entităţi sau unei asociaţii
trebuie să fie elementare, adică nedecompozabile.

REGULA 3.
Pentru fiecare realizare a unei entităţi sau
asociaţii, două proprietăţi nu pot reprezenta aceiaşi
informaţie reală, adică nu pot să aibă valori repetate
pentru o aceiaşi realizare a entităţii sau asociaţiei.

REGULA 4.
Toate proprietăţile, altele decât 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
proprietăţi.

Dacă modelul îndeplineşte regulie 1,2 şi 3 este în


PRIMA FORMĂ NORMALĂ.
Dacă îndeplineşte şi regula 4 modelul este în A DOUA
FORMĂ NORMALĂ.
Dacă îndeplineşte şi regula 5 modelul este în A TREIA
FORMĂ NORMALĂ.

pagina 131
Sisteme informatice de gestiune

Exemplu: "Un salariat al unei întreprinderi, împărţită în


secţii, lucrează într-o singură secţie şi participă la minim
două proiecte. Fiecare secţie are un cod şi o denumire."
Această prezentare se traduce în urmatorul MCD.

Figura 4.18. Model nenormalizat

Regulile normalizării nu sunt respectate, şi nu se


poate spune nici măcar 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 secţie dată nu există
doi salariaţi având acelaşi nume, se va putea alege ca
identificator cuplul COD_SECTIE, NUME.
Proprietatea ADRESA se descompune de exemplu
în două proprietăţi elementare STRADA şi ORAS.
Repetarea numelui de proiect se va traduce cu
ajutorul unei entităţi PROIECT şi a unei asociaţii
PARTICIPA.
Se obţine astfel următorul 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ă fără ambiguitate
fiecare salariat, dar proprietatea DEN_SECTIE nu depinde
decât de o parte a identificatorului, proprietatea
COD_SECTIE. Pentru a respecta a doua formă normală,
se adaugă entităţii SALARIAT o nouă proprietate
denumită MARCA care identifică fără ambiguitate fiecare
salariat din întreprindere, iar DEN_SECTIE depinde direct
de MARCA. Se obţine următorul 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 curând de proprietatea COD_SECTIE.
Dependenţa de identificator nu este directă ci mai
degrabă tranzitivă prin intermediul proprietăţii
COD_SECTIE.
Pentru a elimina acest inconvenient este suficient
să se introducă o nouă entitate SECTIE şi o asociaţie
LUCREAZA care arată faptul că un salariat lucrează într-o
secţie. Se obţine următorul 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 urmărită atingerea celei de-a treia forme
normale pentru a minimiza redundanţa informaţională şi
în consecinţă riscurile discordanţelor dintre date.
Normalizarea este deci un proces prin excelenţă
intelectual, căci bazat pe analiza semantică a
proprietăţilor şi plecând de la un ansamblu amorf de
date se obţine 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 fişierelor utilizat,
la nivel organizaţional trebuiesc integrate soluţiile de
organizare a datelor astfel încât formalismul
entitate/relaţie să poată fi transcris cât mai exact, la
nivelul fizic, în termenii limbajului de gestiune a datelor
ales.
Alegerea depinde de tipul software-ului avut la
dispoziţie, şi noul model rezultat (modelul logic al
datelor - MLD) trebuie să ţină cont de posibilităţile
acestui software fără însă să intre în detaliile tehnice ale
metodelor de stocare şi de acces specifice următorului
nivel, nivelul fizic. Alegerea sistemului de gestiune a
datelor se poate face între fişiere şi baze de date.
Utilizarea fişierelor constă în înmagazinarea pe
suport accesibil prelucrării automate, a datelor
prelucrate în cadrul fiecărei componente a sistemului
informatic. Un fişier se constituie dintr-o submulţime de
date relativ omogene relative la o clasă de elemente a
sistemului informaţional. Identificatorul unui fişier este o
proprietate aleasă astfel încât la fiecare valoare a acestei
proprietăţi să corespundă o singură realizare a unui
articol din fişier. Articolul dintr-un fişier este o colecţie
de proprietăţi care se referă la acelaşi element. O
realizare a articolului reprezintă ansamblul proprietăţilor
pentru un articol individualizat.
Se pot distinge două feluri de fişiere:

• fişiere clasice de tip BASIC, FORTRAN, COBOL etc.


• fişiere secvenţial-indexate multicriteriale tip DBASE.

pagina 135
Sisteme informatice de gestiune

Cu fişierele clasice accesul după criterii multiple


este dificil şi sisteme de gestiune a fişierelor ca de
exemplu cel din COBOL nu permit decât funcţii de
adăugare, căutare, modificare şi ştergere. Orice altă
operaţie rămâne în sarcina programatorului.
La fişierele secvenţial-indexate multicrteriale
accesul se face după mai multe chei, este mult mai uşor
şi sunt oferite mai multe posibilităţi de prelucrare.
Metoda fişierelor prezintă inconveniente majore,
idiferent de tipul de fişiere folosit:
• existenţa renundanţelor;
• apariţia unor probleme de coerenţă;
• procedurile de securitate trebuiesc programate;
• programatorul trebuie să gestioneze el însuşi relaţiile
între fişiere
• programatorul trebuie să cunoască metodele de
stocare şi de acces;
• creşterea complexităţii sistemului duce la dificultăţi
sporite de întreţinere.
Ca urmare a persistenţei 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 cărui
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ă;
• coerenţa datelor;
• acces după criterii multiple;

pagina 136
Sisteme informatice de gestiune

• date legate între ele conform cu MCD;


• independenţa programelor şi datelor;
• securitatea datelor;
• actualizare şi interogarea concurentă.

În funcţie de datele de memorat şi de relaţiile dintre ele


într-o bază de date pot să apară următoarele tipuri de
structuri:
• structura arborescentă; când există o singură
legătură între două entităţi ale bazei de date, de la
"tată" la "fiu", exploatarea facându-se fie pe traseul
"tată-fii" fie invers "fiu-tată".
• structura reţea; când o înregistrare "fiu" poate avea
mai multe înregistrări "tată", care permite căutarea
în toate direcţiile pornind de la orice entitate. Trebuie
menţionat aici modelul CODASYL (Conferance on
Data Systems Languages) elaborat la începutul anilor
'70, şi ale cărui norme sunt respectate de numeroase
sisteme de baze de date.
• structura relaţională; când entitatea este privită ca o
relaţie între proprietăţi şi nu ca o înregistrare,
asigurându-se o independenţă totală a programelor
faţă de date.

Trecerea de la MCD la MLD se poate face către


toate tipurile de organizare a datelor, inclusiv către
organizarea în fişiere clasice, dar mai utilizate sunt
MLD CODASYL şi MLD relaţional. În cele ce urmează
vom dezvolta trecerea către MLD relaţional.
Modelul logic al datelor utilizează concepte ale
modelului relaţional şi presupune dispunerea datelor
sub formă de tablouri cu două dimensiuni numite tabele
sau relaţii.
Pentru a facilita înţelegerea regulilor de trecere de
la MCD la MLD trebuiesc definite următoarele concepte:

pagina 137
Sisteme informatice de gestiune

a) tabel. Un tabel corespunde unei entităţi sau unei


asociaţii din MCD şi este alcătuit din linii şi coloane.
b) linie. O linie corespunde noţiunii de realizare a
entităţii sau asociaţiei.
c) coloana. Noţiunea de coloană corespunde noţiunii de
proprietate.
d) cheie primară. Noţiunea de cheie primară corespunde
noţiunii 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ţă evitând repetiţiile.

Reguli de trecere de la MCD la MLD

REGULA 1. Entităţile devin tabele. Proprietăţile devin


coloane de tabele. Identificatorii entităţilor devin chei
primare ale tabelelor.
REGULA 2. Când o asociaţie binară are o legătură 0,1
sau 1,1 şi o alta de cardinalitate 0,n sau 1,n apare o
migraţie a cheilor entităţii 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 proprietăţile "cod
fiscal" (identificator) şi "nume beneficiar" primeşte una
sau mai multe facturi caracterizate printr-un "număr
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

Asociaţia nu se transformă într-un tabel la nivelul


MLD, dar este explicitată plasând în tabelul "factura"
cheia primară a tabelului "beneficiar" care devine o cheie
straină. Se obţine astfel următorul MLD:

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


exemplu

Dacă ASOCIAŢIA din MCD prezentată anterior are


proprietatea "data" (data primirii facturii) atunci MCD şi
MLD corespunzător 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 următor care arată că o
factură este constituită din una sau mai multe poziţii
(rânduri în factură), iar o poziţie aparţine unei singure
facturi,

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


exemplu

identificatorul entităţii "poziţii" va fi format din


concatenarea identificatorilor entităţilor participante la
asociaţie, 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 asociaţie binară este purtătoarea a două
legături de cardinalitate 0,n sau 1,n asociaţia devine un
tabel în MLD, în care migrează cheile entităţilor.
Asociaţia devine un tabel, în care cheia primară
este obţinută prin concatenarea identificatorilor
entităţilor participante la asociaţie.
Dacă asociaţia are proprietăţi, acestea devin
coloane în tabelul care rezultă din asociaţie.
Considerând următoarea situaţie: "un client poate
să nu cumpere sau să cumpere n produse, iar un produs
poate să nu fie cumpărat sau să fie cumpărat de n
clienti" , modelele conceptual şi fizic vor arăta ca în
figura 4.28.

pagina 141
Sisteme informatice de gestiune

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


exemplu

Noţiunea de asociaţie din MCD poate fi deci


tradusă în funcţie de cardinalităţile asociate , în două
feluri:
• prin utilizarea conceptului de cheie straină (regula 2);
• prin utilizarea unui nou tabel (regula 3).
Cardinalităţile alese la nivel conceptual determină deci
în mare parte structura fizică, fiind necesară o mare
atenţie în alegerea lor.

REGULA 4.
Atunci când o asociaţie binară are două legături
de cardinalitate 0,1 sau 1,1 apare o dublă migraţie a
identificatorilor entităţilor.
Fie următorul MCD şi corespunzător acestuia
următorul MLD.

pagina 142
Sisteme informatice de gestiune

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


exemplu

În MLD se păstrează cele două entităţi


provocându-se în fiecare din ele migrarea reciprocă a
identificatorilor. Când asociaţia binară are două legături
0,1 sau 1,1 şi o proprietate, atunci asociaţia se
transformă într-un tabel prin trecerea de la MCD la MLD.

REGULA 5.
Această regulă priveşte în special entităţile
generatoare şi entităţile specifice. Fie MCD următor:

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


exemplu

pagina 143
Sisteme informatice de gestiune

Există mai multe posibilităţi de a obţine MLD din care o


prezentăm pe cea mai simplă, adică crearea unui tabel
pentru fiecare entitate, ceea ce se traduce prin migrarea
identificatorului şi a proprietăţilor de la entitatea
generatoare (mamă) în fiecare entitate fiică:

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


exemplu

Atunci când entitatea generatoare este în


asociaţie cu o altă entitate, apare o combinaţie între
REGULA 2 şi regulile menţionate mai înainte, rezultatele
obţinute fiind în funcţie de cardinalităţile asociaţiei.

pagina 144
Sisteme informatice de gestiune

4.3.3. Modelul fizic al datelor

Descrierea unui model fizic este strâns legată de


sistemul de gestiune a datelor ales. În practică se
întâlnesc frecvent trei tipuri de soluţii tehnice:

1. Utilizarea unui sistem de gestiune a fişierelor clasic


având ca metodă principală accesul secvenţial-
indexat.
Fişierele indexat secvenţiale sau “cu index rar”
presupun memorarea înregistrărilor într-un fişier
numit fişier principal, în ordinea crescătoare a
cheilor şi grupate pe pagini. Se adaugă un fişier de
index, ce conţine pentru fiecare pagină din fişierul
principal câte o înregistrare cu valoarea celei mai
mari chei din pagină şi adresa de început a paginii.
Fişierul de index este ordonat crescător în raport cu
valoarea cheii. De cele mai multe ori pagina
corespunde unui bloc, înlănţuirea blocurilor în
ordine crescătoare a cheilor permite parcurgerea
secvenţială ordonată a fişierului. Atunci când în
fişierul de index se găseşte acelaşi număr de
înregistrări cu cele din fişierul principal fişierul se
numeşte “cu index dens”. Pentru fişierele de
dimensiuni foarte mari, se poate considera fişierul de
index din organizarea secvenţial indexată ca fişier
principal căruia i se ataşează un fişier cu index rar.
Procedând recursiv până se obţine un fişier index ce
conţine un singur bloc, se obţine 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 reţea. Acesta se poate
implementa uşor prin asocierea a câte unui fişier la
fiecare entitate. Înregistrările fişierului corespund
realizărilor entităţii şi câmpurile înregistrării
corespund atributelor entităţii. Modelul reţea este
apropiat de forma de reprezentare a bazelor de date
sub forma diagramelor entitate-asociaţie. Deosebirea
constă doar în faptul că toate relaţiile ce apar pot fi
numai binare de tipul unu-la-unu şi mai-mulţi-la-
unu. Această restricţie permite reprezentarea grafică
a unei baze de date de tip reţea sub forma unui graf
direcţionat numit reţea. Într-o reţea nodurile
corespund entităţilor şi relaţiile sunt reprezentate
prin săgeţi între noduri de la tată la fiu. Structura de
reprezentare reţea este dezvoltarea structurii
arborescente permiţănd ca orice colecţie de date să
aibă mai multe colecţii de date superioare. O relaţie R
de forma mai-mulţi-la-unu de la entitatea E1 la
entitatea E2 se implementează ca o mulţime de liste
circulare numite inele având capetele în fişierul
asociat lui E2. Un inel de capăt e2 aparţinând lui E2
conţine toate elementele e1 aparţinând lui E1 care
sunt în relaţie cu e2.
Modelul reţea este folosit din ce în ce mai puţin,
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
relaţional.
Modelul relaţional se bazează pe noţiunea
matematică de relaţie, aşa cum este ea definită de
teoria mulţimilor, şi anume ca o submulţime a
produsului cartezian al unei liste finite de mulţimi
numite domenii. Elementele unei relaţii se numesc

pagina 146
Sisteme informatice de gestiune

tupluri, iar numărul de domenii (nu toate distincte)


din produsul cartezian se numeşte aritatea relaţiei.
De obicei relaţiile sunt reprezentate sub forma unor
tabele în care fiecare rând reprezintă un tuplu şi
fiecare coloană reprezintă valorile tuplurilor dintr-un
domeniu dat al produsului cartezian. În
reprezentarea sub formă de tabel a unei relaţii,
coloanelor şi respectiv domeniilor corespunzătoare
lor li se asociază nume intitulate atribute. Mulţimea
atributelor unei relaţii se numeşte schemă
relaţională. Un alt mod de a defini relaţiile este
următorul: prin relaţie înţelegem o mulţime de funcţii
definite pe o mulţime de atribute cu valori în
reuniunea unor domenii, cu restricţia ca valoarea
corespunzătoare fiecărui atribut să se afle în
domeniul asociat acelui atribut. Mulţimea tuturor
schemelor relaţionale corespunzatoare unei aplicaţii
se numeşte schema bazei de date relaţionale, iar
conţinutul curent al relaţiilor la un moment dat se
numeşte bază de date relaţională. În modelul
relaţional entităţile sunt reprezentate sub formă de
relaţii în care schema relaţională conţine toate
atributele entităţii şi fiecare tuplu al relaţiei
corespunde unui element al entităţii. La atributele
entităţii se pot adăuga în relaţie şi alte atribute
suplimentare utilizate pentru exprimarea relaţiilor
între entităţi.
Descrierea modelului fizic al datelor (MFD) va fi facută
în limbajul sistemului de gestiune corespunzător soluţiei
alese. În plus, mediul de dezvoltare va influenţa şi el
foarte mult MFD.

pagina 147
Sisteme informatice de gestiune

4.3.4. Modelul conceptual al comunicaţiilor

Acest model, numit şi graf actori-flux, permite


descrierea informaţiilor schimbate la nivel global în
sistem. Conceptele utilizate sunt:
a) actor.
Se întelege prin actor tot ceea ce joacă un rol în
transmiterea unei informaţii şi care produce un flux
informaţional (pesoană fizică, juridică, clădire, servicii)
Actorii se împart în două categorii:
• actori interni, care fac parte din organizaţie;
• actori externi organizaţiei sau domeniului studiat.

b) flux.
Un flux este un schimb de bunuri, bani sau
informaţii între un actor emiţător şi unul receptor. Se
disting în particular următoarele fluxuri:
• fluxuri fizice
• fluxuri monetare
• fluxuri de informaţii
Printre fluxurile de informaţii, în funcţie de natura
suportului se va vorbi de flux informaţional oral,
documentar sau informatic. O altă clasificare a
fluxurilor este în funcţie de locul emiţătorului în raport
cu domeniul studiat:
• flux intern, atunci când este emis de un actor intern
domeniului;
• flux extern, atunci când este emis de un actor extern
domeniului.

c) ordonarea fluxurilor.
Această operaţie permite observarea înlănţuirii
fluxurilor, putându-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
scăzut nivel organizatoric într-un domeniu de gestiune.
Într-un domeniu contabil, un flux primar va fi de
exemplu un borderou de mişcări, document situat în
amonte de fluxuri ca jurnalele, cartea mare, balanţa,
bilanţul etc..

e) flux secundar.
Un flux secundar este un flux a cărui emisie este
subordonată preexistentei unuia sau mai multor fluxuri
primare sau secundare. De exemplu, emiterea unei
facturi este subordonată recepţiei unei comenzi.

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

Figura 4.32. Modelul conceptual al comunicaţiilor


pagina 149
Sisteme informatice de gestiune

4.3.5. Modelul conceptual al prelucrărilor

Prelucrările constituie partea dinamică a


sistemului informaţional. Ele descriu acţiunile ce trebuie
executate asupra datelor pentru obţinerea rezultatelor
scontate. Prelucrările nu sunt de fapt decât traducerea
regulilor de gestiune care compun activitatea sistemului
economic. Reprezentarea schematică face apel la
următoarele concepte:

1)domeniu.
Noţiunea de domeniu în sensul de "domeniu de
gestiune" corespunde unei părţi a sistemului care
conţine subansamble coerente.
Exemplu: domeniul comercial, domeniul financiar,
domeniul personal.

2)procese.
Procesele reprezintă subansamble ale unui
domeniu. Se recurge la această împărţire atunci când
sistemul de studiat este foarte vast.
Exemplu: Domeniul comercial al unei întreprinderi poate
cuprinde trei procese: urmărire reprezentanţi, primire
comenzi şi urmărire comenzi.

3) operaţie.
O operaţie este o activitate prin care se produc
fluxuri informaţionale. O operaţie este definită imaterial,
fără restricţii organizatorice. Ea descrie la fel de bine
gestiunea manuală cât şi pe cea automată.
O operaţie poate utiliza una sau mai multe
entităţi şi/sau asociaţii pentru acţiuni de creare,
modificare, ştergere sau consultare.
O operaţie se descompune în acţiuni.

pagina 150
Sisteme informatice de gestiune

Exemplu: O operaţie în domeniul "Evidenţa


personalului" ar putea fi "Obţinerea adeverinţei de
salariu". Simbolul pentru operaţie este:

Figura 4.33. Operaţie

4) acţiune.
O acţiune este o funcţie elementară. Între acţiunile unei
operaţii nu există aşteptare, şi derularea lor este
secvenţială.
O acţiune poate referi una sau mai multe REGULI DE
GESTIUNE
O operaţie poate utiliza una sau mai multe entităţi
şi/sau asociaţii
pentru acţiuni de creare, modificare, ştergere sau
consultare. Simbolul este:

Figura 4.34. Acţiune

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 acţiuni. O aceeaşi regulă de
gestiune se poate aplica uneia sau mai multor acţiuni.

Exemple:
1. Trebuie aplicat 2% reducere clienţilor ale căror
comenzii din anul precedent au depăşit 4.000.000
lei;
2. Comenzile către furnizor trebuie să fie vizate de
către şeful serviciului aprovizionare.

6) eveniment.
În timpul analizei unei operaţii trebuie
întotdeauna să se pună întrebarea "care sunt
evenimentele care concură la declanşarea unei operaţii?".
Un eveniment se defineşte ca un flux de orice natură,
sau un fapt care permite lansarea unei operaţii. 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ă" decât "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 declanşatoare, care declanşează o
operaţie sub controlul unei condiţii de sincronizare;
• evenimente rezultate, produse de către o operaţie ca
urmare a unei reguli de emisie.
Declanşarea unei operaţii este în general condiţionată de
prezenţa mai multor evenimente declanşatoare. Aceste
evenimente nu apar în acelaşi moment, deci apare
necesitatea condiţionării declanşării operaţiei cu o
condiţie de sincronizare a evenimentelor declanşatoare.
În acelaşi fel, operaţiile, nu generează întotdeauna
aceleaşi evenimente rezultante. Producerea
evenimentelor rezultante va fi deci supusă regulilor de
emisie.

pagina 153
Sisteme informatice de gestiune

Figura 4.36. Evenimente declanşatoare şi rezultante

Evenimentele 1 şi 2 declanşează o operaţie alcătuită din


două acţiuni 1 şi 2, iar evenimentele 3 şi 4 sunt
rezultatul operaţiei.

7) condiţia de sincronizare.
Condiţia de sincronizare este exprimată printr-o
condiţie booleană care leagă evenimentele declanşatoare
prin operaţii logice ŞI, SAU, NU. Operaţia nu este
declanşată decât atunci când condiţia este îndeplinită.
Este recomandată folosirea alias-ului pentru descrierea
condiţiei de sincronizare.
În exemplul din figura 4.37., operaţia nu va fi
declanşată decât dacă evenimentul A se produce în
acelaşi timp cu evenimentul B sau C.
Dacă un singur eveniment este necesar pentru
declanşarea operaţiei, condiţia de sincronizare dispare
din reprezentarea grafică.

8) regula de emisie.
O regulă de emisie defineşte condiţia sub care
evenimentele rezultate vor fi produse de către o
operaţie. O operaţie poate avea una sau mai multe reguli
pagina 154
Sisteme informatice de gestiune

de emisie, o regulă gestionând emisia unuia sau a mai


multor evenimente rezultate.

Figura 4.37. Condiţia de sincronizare

Figura 4.38. Regula de emisie


pagina 155
Sisteme informatice de gestiune

O operaţie poate să nu aibă regulă de emisie. În acest


caz emisia evenimentelor este necondiţionată şi se
traduce cu ajutorul cuvântului "totdeauna". O regulă de
emisie poate avea un alias pentru uşurarea afişării
simbolului operaţiei în cazul în care textul care
defineşte regula este prea lung.

Figura 4.39. Modelul conceptual al comunicaţiilor;


Exemplu
pagina 156
Sisteme informatice de gestiune

Evenimentele 1, 2 şi 3 declanşează operaţia 1 punându-


se condiţia de sincronizare “a ŞI (b SAU c)”. Operaţia 1
este constituită din acţiunile 1 şi 2 care conduc la regula
2 de emisie. Evenimentele 4 şi 5 sunt rezultate
produse de operaţia 1.
Operaţia 2 compusă din acţiunea 3 este declanşată de
evenimentul 5. Evenimentul 6 este întotdeauna emis de
operaţia 2.

9) reguli de creare a unui MCP.

Crearea unui MCP poate părea uşoară la prima


vedere, dar se poate constata că există tendinţa 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


dificultăţilor pe care le întâlnim în timpul analizei unui
proces în separarea părţii conceptuale de partea
organizaţională.
Trebuie să ne amintim tot timpul că MCP trebuie
să exprime ce trebuie făcut, dar nu arată când trebuie
făcut şi nici unde trebuie făcut (concepte
organizaţionale) şi încă şi mai puţin cum trebuie făcut
(concept operaţional).
Cu titlu de exemplu să încercăm modelarea
procesului de selecţie a unui candidat la ocuparea unui

pagina 157
Sisteme informatice de gestiune

post. Această modelare se sprijină pe următoarea


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 când
aceste controale sunt favorabile, se trimite o convocare
pe adresa candidatului"

Figura 4.40. MCP; Erori de modelare

pagina 158
Sisteme informatice de gestiune

Fără a putea spune că acest model este fals se pot


formula totuşi următoarele observaţii:
1. nici un eveniment extern, după venirea dosarului, nu
justifică împarţirea prelucrărilor aşa de detaliat
(scrisoarea de respingere reprezintă de fapt numai
un singur eveniment);
2. s-a ţinut cont în acest model de o restricţie
organizaţională, asimilând o operaţie desfăşurată
într-un anumit loc de muncă unei operaţii
conceptuale;
În general, atunci când o serie de operaţiuni se
înlănţuie fără evenimente externe sau interne justificate
cu adevărat, nu trebuie să aibă loc o detaliere a
operaţiunilor.
Se poate propune următorul 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 câteva reguli de validare. Aceste reguli,
elementare, fac apel mai ales la bunul simţ.

a) Reguli legate de operaţiuni.


Când s-a plasat o operaţie în model trebuie
verificate următoarele:
• o operaţie este un ansamblu de acţiuni
neîntreruptibile, adică nu sunt supuse aşteptării unor
evenimente. Dacă acest lucru nu este posibil, trebuie
folosite mai multe operaţii;
• o operaţie trebuie să fie omogenă, adică fără
prelucrări alternative dezechilibrate în interior. O
operaţie neomogenă poate să ascundă producerea
unor evenimente interne neprevăzute care ar antrena
împărţirea operaţiei în mai multe operaţii omogene;
• trebuie să se obţină un rezultat în toate situaţiile;
• o operaţie este întotdeauna precedată de cel puţin un
eveniment;
• o regulă de emisie trebuie să coexiste întotdeauna cu
contrariul său (afară de cazul "totdeauna");

b)Reguli legate de condiţiile de sincronizare.


Când se introduce în model o condiţie 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 operaţiei care
depinde de mai mult decât de un singur eveniment şi
când operaţia este declanşată de fapt de sosirea unui
singur eveniment.

pagina 160
Sisteme informatice de gestiune

Figura 4.42. MCP; Sincronizare nerecomandată

Acest tip de operaţie nu este recomandat pentru


că prin condiţia de sincronizare A SAU B producerea
evenimentului 1 sau a evenimentului 2 va declanşa
operaţia fără nici o aşteptare, fapt care contrazice
definiţia sincronizării. În acest sens modelul di
figura 4.43. prezintă o anume incoerenţă pentru că
producerea evenimentului "b" declanşează imediat şi
necondiţionat operaţia 2, ceea ce înseamnă că operaţiile
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 incoerenţe

Figura 4.44. MCP corectat


pagina 162
Sisteme informatice de gestiune

12) reguli legate de funcţionarea unui MCP.

MCP nu este numai un model static de


reprezentare a prelucrărilor, dar este în acelaşi timp un
model dinamic a cărui funcţionare este supusă anumitor
reguli care depind în cea mai mare parte de context. Se
vor aborda numai cazurile în care funcţionarea
modelului este imposibilă sau nedeterminată, adică vor
fi abordate noţiunile de conflict şi de ciclu.

a) Noţiunea de conflict.
Se spune că există un conflict relativ la un
eveniment dacă acest eveniment contribuie la mai multe
sincronizări. Astfel următorul MCP prezintă o situaţie
conflictuală:

Figura 4.45. MCP cu conflict

pagina 163
Sisteme informatice de gestiune

Apariţia evenimentului 2 va putea într-un mod


nedeterminat să contribuie la activarea operaţiilor 1 şi 2.
Acest conflict poate fi rezolvat în două feluri:
• cardinalitatea producerii evenimentului 2 este 2 şi în
acest caz cele două apariţii ale evenimentului 2 sunt
folosite în cele două sincronizări;
• condiţiile de participare ale evenimentului 2 la cele
două operaţii sunt exclusive.

b) Noţiunea de ciclu.
Când o operaţie are ca eveniment declanşator un
eveniment pe care ea îl produce nemijlocit sau prin
intermediul mai multor operaţii, ne găsim în prezenţa
unui ciclu.
Folosirea ciclurilor, cu condiţia să fie valide, este
o tehnică ce permite să se reducă sensibil mărimea
MCP-ului. Un astfel de ciclu (figura 4.46.) este controlat
şi condiţiile 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 restricţii temporale de tipul:
"întâi ale lunii, începutul perioadei, 15 ale lunii ..."

Validarea modelelor.

Validarea modelelor are ca obiectiv sinteza între


analiza datelor şi analiza prelucrărilor. Ea permite
verificarea între MCD şi MCP.
Verificarea acestei coerenţe are ca regulă
esenţială verificarea ca toate entităţile şi asociaţiile
MCD-ului să fie utilizate de cel puţin o operaţie a MCP.

pagina 164
Sisteme informatice de gestiune

Figura 4.46. MCP cu ciclu

Entitatea sau asociaţia trebuie atunci să fie


asociată unui eveniment declanşator sau rezultant, sau
să intervină într-o regulă de gestiune sau un calcul.
Când lipsa coerenţei este constatată se poate
interveni asupra MCD. Aceasta se poate traduce prin:

pagina 165
Sisteme informatice de gestiune

• adăugarea de proprietăţi care reprezintă informaţii a


căror necesitate nu a fost banuită;
• adăugarea de noi asociaţii care stabilesc dependenţe
între entităţi care nu erau corect precizate.

Asocierea modelului datelor cu modelul prelucrărilor


este unica operaţie care permite validarea MCD. Operaţia
de validare permite trecerea de la un MCD brut la un
MCD validat.

pagina 166
Sisteme informatice de gestiune

4.3.6. Modelul organizaţional al prelucrărilor

Anumite concepte au fost definite la modelul


conceptual al prelucrărilor, deci se vor prezenta numai
conceptele noi specifice MOP.

1) procedura.
O procedură este o succesiune de faze aparţinând
aceluiaşi proces şi executat de actori. Este un
subansamblu al unui proces din MCP decalaşat de unul
sau mai multe evenimente.
MOP trebuie să fie stabilit cu grija căci el
constituie prima viziune globală şi coerentă a sarcinilor
efectuate de către actori, schimburile dintre actori,
datele la care fac apel actorii şi restricţiile
organizaţionale.

2) actorii.
Un actor este o entitate organizaţională
însărcinată să efectueze un anumit număr de faze. Un
actor aparţinând 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ţă contribuţia actorului în cadrul unui
proces dat. Procedura actor cuprinde ansamblul
sarcinilor efectuate de către un actor, MOP permiţând
astfel stabilirea lucrărilor executate de fiecare actor.

3) faza.

pagina 167
Sisteme informatice de gestiune

O fază este o înlănţuire ninteruptibilă de task-uri


cu aceiaşi 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 prelucrărilor sau task-urilor care compun
faza;
• condiţiile de sincronizare ale evenimentelor
declanşatoare;
• regulile de emisie ale evenimentelor rezultante.

În plus, o fază relevă caracteristicile următoare:


• natura sau tipul prelucrării;
• derularea prelucrării;
• locul unde se desfăşoară.

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 său 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 desfăşurare a activităţii.


Locul de desfăşurare a activităţii înglobează
conceptul de actor căruia i se atribuie caracteristici
organizaţionale. Aceste caracteristici sunt tipul locului
de desfăşurare, responsabilul şi resursele.
Tipul locului reprezintă ansamblul locurilor unde
acţiunile unei operaţii conceptuale se pot efectua.
Resursele sunt ansamblul mijloacelor care permit
realizarea anumitor acţiuni ale unei operaţii. Resursele
pot fi consumabile sau reutilizabile.
Caracteristicile legate de desfăşurarea unei faze
sunt indicate în coloana "perioadă" a MOP iar tipul este
indicat în coloana "tip". Actorul sau locul de desfăşurare
a activităţii relativ la o faza este indicat prin coloana
unde figurează faza. La fiecare operaţie conceptuală din
MCP îi corespunde una sau mai multe faze.

7) task.

O fază este descompusă în task-uri. Un task


reprezintă o funcţiune elementară. Un task poate folosi
una sau mai multe reguli de organizare.
Conceptul de task este foarte important pentru că
el stă la baza dezvoltărilor ulterioare.

8) eveniment.

pagina 169
Sisteme informatice de gestiune

Conceptul de eveniment este acelaşi care a fost


definit în MCP, cu deosebirea că noţiunea cuprinde şi
alte tipuri de evenimente care îmbracă mai ales aspectul
organizaţional (introducerea unei comenzi, decizia
superiorului, etc.)
Aceste evenimente, iniţiate prin regulile de
organizare, vor avea un efect deloc neglijabil asupra
împărţirii operaţiilor 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 căreia i se dă o dimensiune
organizatorică.
Exemplu: O regulă de gestiune spune că "orice client
trebuie să fie solvabil". La nivel organizaţional, se
îmbogăţesşte această regulă precizând modul de calcul
prin care să se permită verificarea solvabilităţii clientului.
Astfel, orice regulă de calcul poate fi o regulă
organizaţională.

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 prezentăm un model ipotetic
privind prelucrarea unor cereri de aprovizionare.

Figura 4.48. Modelul organizaţional al prelucrărilor

Reguli de concepere a unui MOP.

MOP poate fi dedus din MCP. Analiza restricţiilor


organzaţionale condiţionează în întregime trecerea de
la MCP la MOP. El se caracterizează prin luarea în
pagina 171
Sisteme informatice de gestiune

considerare a restricţiilor organizaţionale. Se trece într-


adevar de la un ansamblu de lucrări finalizate (operaţiile
conceptuale), la un ansamblu de lucrări organizate
(task-urile), având numeroase restricţii organizaţionale.
Metoda va consta în analiza restricţiilor
organizaţionale şi în împarţirea fiecărei operaţiuni
conceptuale.

1) Analiza restricţiilor organizaţionale.


Analiza restricţiilor organizaţionale va permite
punerea în evidenţă a noilor actori şi a noilor
evenimente.
Evenimentele unui MOP pot fi conceptuale sau numai
organizaţionale. Un eveniment este conceptual dacă el
decurge direct dintr-un MCP şi este organizaţional în
caz contrar.
Evenimentele organizaţionale pot fi purtătoare
sau nu de date. În cazul în care ele sunt purtătoare de
informaţii, ele fac obiectul unei descrieri, care va servi la
validarea modelelor de date. În cazul când ele nu sunt
purtătoare de date, acestea sunt evenimente de tipul
"resursă disponibilă" şi nu este necesar să se reprezinte
în MOP. În acest caz, se vor regăsi în coloana
"perioadă" sau "tip".

2) Împarţirea fiecărei operaţiuni conceptuale.


Punerea în evidenţă a unor noi actori şi/sau a
unor noi evenimente va permite împărţirea fiecărei
operaţii conceptuale în faze. Fiecărei operaţiuni
conceptuale din MCP îi va corespunde:
• o fază unică în MOP; este cazul unei operaţii
conceptuale care poate fi complet executată de un
actor într-o aceiaşi unitate de timp.
• mai multe faze în MOP; este cazul unei operaţii
conceptuale care trebuie să fie împarţită în mai

pagina 172
Sisteme informatice de gestiune

multe subansamble de periodicităţi diferite pentru


unele acţiuni sau o împărţire rezultând dintr-o
restricţie organizatorică.

Pentru mai buna descompunere a unei operaţii


conceptuale, este necesar să se procedeze la o analiză
ascendentă plecând de la rezultate spre evenimente.
Astfel, o operaţie conceptuală dă întotdeuna cel
puţin 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 atâtea faze de achiziţie de date câte fluxuri
informaţionale necesită o introducere de date.
Ansamblul fazelor astfel obţinute, prin
descompunerea procedurii funcţionale, pot fi eventual
din nou combinate dacă:
• la ele nu participă decât un singur actor;
• nu necesită decât resurse identice;
• nu au loc decât în acelaşi moment;
• nu sunt supuse unei aşteptări de natura
organizaţională.

În cursul descompunerii unei operaţii conceptuale, este


frecventă obţinerea unei faze care a fost deja
determinată anterior. În acest caz nu se va reţine decât o
singură fază.
Se constată că metoda nu constă în analiza
restricţiilor organizaţionale şi apoi împărţirea fiecărei
operaţii conceptuale, ci mai curând împărţirea operaţiilor
în acelaşi timp cu analiza restricţiilor organizaţionale.
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 prelucrărilor. Ea permite

pagina 173
Sisteme informatice de gestiune

verificarea coerenţei între MLD şi MOP. Verificarea


acestei coerenţe se efectuează la două niveluri:
• toate tabelele din MLD sunt necesare;
• orice coloană din MLD este utilizată de cel puţin o
operaţie din MOP.
Coloana trebuie să figureze la un eveniment declanşant
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ă.
Când se constată o lipsă de coerenţă poate fi
necesară intervenţia în modelele de date şi chiar
modificarea la nivelul MCD. Aceasta se poate traduce
prin:
• adăugarea de proprietăţi care reprezintă informaţii a
căror necesitate nu a fost bănuită; aceasta poate
conduce la o anumită denormalizare a modelului de
date;
• adăugarea de noi asociaţii care stabilesc dependenţe
între entităţi care nu erau corect precizate;
• adăugarea la nivelul MLD a unor noi indecşi care
asigură timpi de răspuns mai bun.

pagina 174
Sisteme informatice de gestiune

4.3.7. Modelul operaţional al prelucrărilor

Scopul modelului operaţional al prelucrărilor


(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 tranzacţiilor (pentru faze în "timp real").
Se recomandă respectarea câtorva reguli în funcţie de
tipul programelor. Astfel pentru programele "batch":
• împărţirea acestora după periodicitatea de
prelucrare;
• împarţirea după tipul de prelucrare (validare,
calcul,actualizare, editare)

Pentru prelucrarea tranzacţiilor se recomandă


următoarele reguli:
• fiecărui ecran îi va corespunde o tranzacţie;
• fiecare tranzacţie va fi structurată în afişare ecran,
introducere date, prelucrare ecran (normalizare
I.S.O.);
• stabilirea normelor ergonomice pentru afişarea
ecranului şi introducerea datelor;
• împărţirea prelucrărilor în validări, calcule,
actualizări şi editări;

Descrierea nivelului operaţional al prelucrărilor va


evolua foarte mult în următorii ani prin utilizarea
limbajelor de baze de date ca SQL şi prin generalizarea
programării orientate pe obiecte.

pagina 175
Sisteme informatice de gestiune

4.4. Ciclul de decizie

Ciclul de decizie cuprinde toate deciziile luate pe


parcursul desfăşurării 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 următoarea:
• împărţirea sistemului informaţional în domenii;
• orientările generale în ceea ce priveşte gestiunea,
organizarea şi soluţiile tehnice;
• planificarea dezvoltării;
• 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


iniţierea proiectului şi ulterior terminării acestuia
evaluarea reuşitei proiectului. Această observaţie ne
duce spre ideea că o corectă abordare a ciclului de
decizie trebuie începută de la nivelul sistemului
informaţional, prin împărţirea sistemului în zone de
interes şi prin stabilirea orientărilor generale.
Totodată trebuie făcută o diferenţa între
atitudinea decizională pasivă, care lasă lucrurile să
evolueze în mod “natural” şi o politică managerială
consecventă în direcţia informatizării.

Din constantările practice se observă o etapizare


"naturală" în introducerea prelucrării automate a datelor.

pagina 176
Sisteme informatice de gestiune

Această etapizare depinde de condiţiile obiective


existente în economie:
• starea tehnologiei hardware;
• starea tehnicilor de rezolvare a problemelor
fundamentale;
• riscul pe care-l implică deficienţele de organizare.
Deşi tehnologia hardware este uniformă în cea
mai mare parte a lumii, tehnica rezolvării problemelor
fundamentale, variază de la industrie la industrie şi de
la întreprindere la întreprindere.
Valoarea riscului pe care-l implică, deficienţele de
organizare variază de la caz la caz. Pragul de la care o
anumită activitate devine riscantă este o problemă
subiectivă şi se stabileşte în funcţie de nivelul acceptat al
probabilităţii de producere a evenimentelor nefavorabile.
Dar miza depăşirii eventualelor dificultăţi este
mare deoarece un succes mai însemnat realizat de o
întreprindere va stârni un ecou rapid în rândul celorlalte.
Etapizarea pătrunderii calculatoarelor într-o
întreprindere, sintetizată pe baza mai multor constatări
practice este următoarea:
1. aplicaţii de bază ale calculatoarelor;
2. aplicaţii intradivizionare ale calculatoarelor;
3. aplicaţii interdivizionare ale calculatoarelor;
4. aplicaţii avansate ale calculatoarelor.

Această etapizare nu presupune o intervenţie


coordonată în direcţia informatizării. Bineânţeles că în
cazul unei opţiuni ferme de realizare a unui sistem
informatic se va putea aborda direct etapa finală în
utilizare a calculatoarelor.
1. Prima arie de aplicaţii î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, aplicaţiile iniţiale sunt limitate la


proiecte de proporţii şi complexităţi reduse. în plus
hard-ul se alege dintre cele mai ieftine alternative, din
cauza tendinţei normale de limitare a riscului financiar
în introducerea unei tehnologii noi şi nu prea cunoscute.
Accentul în primele aplicaţii se pune pe înlocuirea
muncii umane în activităţi de sortare, raportari scrise şi
rezolvări de ecuaţii.
2. O altă etapă este aceea când se utilizează
personalul dintr-un singur compartiment şi este
caracterizată prin întreţinerea şi punerea la zi a fişierelor
şi printr-un nivel mai ridicat al complexitatii.
Aplicaţiile includ state de plată, stocuri, registre
contabile generale, balanţe, calculul dividentelor,
evidenţa mijloacelor fixe, etc..
3. Cea de-a treia etapă se caracterizează prin
încercarea de rezolvare a unor probleme economice care
cer un număr limitat de cooperari între sectoare.
Există un interes crescând pentru optimizarea
sistemelor complexe şi de regulă, majoritatea
întreprinderilor urmăresc să câştige maximum prin
optimizarea planificării şi utilizării echipamentelor
electronice.
După cum sarcinile de lucru cresc pentru
echipamentele de calcul ale intreprinderii, există
tendinţa de a favoriza aplicaţiile mai urgente, astfel
încât apar cozi de aşteptare în vederea punerii la punct
a celorlalte aplicaţii. O rezolvare a acestei probleme este
descentralizarea responsabilităţilor de calcul.
În această etapă se încearcă şi câteva din
aplicaţiile cele mai simple de comandă a proceselor de
producţie. Comanda proceselor şi-a câştigat 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

condiţiilor de funcţionare, determină îmbunătăţirea


produselor şi reducerea cheltuielilor de producţie.
4. La sfârşitul etapei a treia devine clar pentru
multe întreprinderi că apropierea treptată de rezolvarea
problemei şi de păstrarea înregistrărilor nu ţine pasul cu
cerinţa întreprinderii pentru informare şi răspuns. Un
răspuns la această problemă este implementarea unui
sistem informatic integrat. În industriile care au o
producţie de masă, cu utilizarea unei tehnologii
omogene, aceste sisteme pot fi introduse fără prea mari
dificultăţi. Totuşi, majoritatea întreprinderilor productive
au o tehnologie extrem de diversificată în ceea ce
priveşte primirea comenzilor, achiziţionarea de materii
prime, distribuirea, depozitarea şi mecanismul de
desfacere. Un element simplu ce exemplifică
eterogenitatea schimburilor de informaţii este numărul
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 opoziţie cu atitudinea pasivă se află acţiunea


conştientă prin care strategia întreprinderii trebuie să
beneficieze de o serie de orientări generale care să-i
permită câştigarea unor avantaje competitive. În acest
sens modelul următor permite corelarea scopurilor
întreprinderii cu avantajele potenţiale dar şi cu efortul
necesar.
Conducătorul este pus aşadar în faţa unei
probleme foarte importante şi deloc uşoară. Este evident
că are nevoie de o tehnologie informatică, dar care
aplicaţii informatice din cele existente sau dintre cele
oferite pe piaţă au o importanţă strategică şi pot
influenţa în mod decisiv potenţialul firmei? El trebuie să
ştie când tehnologia informatică este un element critic

pagina 179
Sisteme informatice de gestiune

pentru întreprinderea sa. O cale posibilă pentru o


investigaţie de acest fel o constituie Modelul strategic tip
grilă (The Strategic Gril Model; Figura 4.49.) care permite
determinarea importanţei şi impactului strategic prin
situarea firmei într-un cadran cu două dimensiuni:
• impactul strategic al sistemelor existente;
• impactul strategic al dezvoltării sistemelor (sistemele
viitoare)
În cadranul 1 “suport” (de sprijin) sistemele
informatice sunt văzute ca având un impact redus
asupra activităţii firmei şi tind să rămană aşa şi în viitor.
Dependenţa activităţii firmei de sistemele informatice
este considerabil scăzută. Tehnologia informatică este
percepută ca un sprijin funcţional fără să implice
investiţii semnificative şi sunt coordonate de la un nivel
ierarhic mijlociu şi scăzut.
În cadranul 2 “factory” (de fabricaţie) deşi
sistemele informatice sunt importante în afacerile firmei
ele nu sunt în centrul dezvoltării strategice. Un posibil
exemplu l-ar putea constitui o întreprindere în care
producţia este condusă prin sisteme de control în timp
real dar viitoarele dezvoltări ale sistemului informatic nu
vor influenţa 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
creşteri a activităţii ci mai ales pentru menţinerea pe
piaţă într-un mediu economic perturbat. Se poate
exemplifica acestă situaţie 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


căror activitate depinde în mod critic de existenţa
sistemelor informatice. O performanţă scăzută ori
căderea acestor sisteme poate fi cauza unor
disfuncţionalităţi 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 investiţii din
acest domeniu. Exemple de firme din acest cadran sunt
băncile, companiile de asigurări, firme de brokeraj,
ziare, institute de cercetări de marketing, etc. Situarea
întreprinderii în acest cadran trebuie să vizeze lanţul

pagina 181
Sisteme informatice de gestiune

producţie-desfacere, existând posibilitatea ca diferite


alte activităţi să se găseasca în celelalte cadrane.
Acest model permite o privire statică asupra
prezentului şi viitoarei dependenţe de sistemele
informatice. De altfel este important de urmărit mişcarea
în timp în interiorul grilei. Trecerea din cadranul “suport”
în “strategic” se poate face sub presiunea progresului
tehnologic, a competiţiei de pe piaţa sau a unor noi
obiective în dezvoltarea firmei.

La fel de importantă este acţiunea conducătorului


şi la nivelul dezvoltării componentelor sistemului
informatic, cu observaţia că în acest caz este vorba de o
conducere de nivel inferior. O proastă conducere poate
afecta succesul proiectului mai mult decât alţi factori,
dar acest fapt, în mod surprinzător, este mai puţin
înţeles î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
următoarele diagrame care evidenţiează implicarea
factorului de conducere în realizarea proiectului. (Figura
4.50.)
La acest nivel de prezentare condiţia iniţială este
“iniţierea proiectului” şi rezultatul este “proiect realizat”.
Resursele reprezintă tot ceea ce s-a consumat pentru
realizarea proiectului. Pentru furnizarea mai multor
amănunte această diagramă poate fi detaliată pentru
şase etape ale ciclului de viaţă al proiectului: analiza
preliminară, proiectarea logică, proiectarea tehnică,
construcţia, 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ă stările în
care se poate afla sistemul şi este folosit pentru
descrierea dependenţelor, pentru alocarea resurselor şi
pentru finanţare.
Dreptunghiurile reprezintă stări sau grupuri de
stări legate între ele în diferite moduri, iar intrările şi
ieşirile sunt evenimente care permit tranziţia de la o
stare la alta. Stările, permit conducătorului de proiect
comunicarea şi măsurarea activităţiil asociate proiectului
în dezvoltare. Se observă că evenimentele sau condiţiile
de ieşire asociate stărilor sunt stabilite pentru ca
managerul să ştie când o anumită fază este completă
astfel încât să poată începe următoarea.

pagina 183
Sisteme informatice de gestiune

Figura 4.51. Conducerea proiectului pe etape ale


ciclului de viaţă

AC (Asigurarea Calităţii) reprezintă semnalul prin


care care să se garanteze că produsul se conformează
unor standarde IEEE Standard for Sofware Quality.
Calitatea produsului constă în totalitatea trăsăturilor sau
caracteristicilor sale care îi permit să se conformeze
necesităţilor utilizatorului. Controlul calităţii constă în
acţiunile necesare pentru măsurarea caracteristicilor
produsului şi compararea lor cu specificaţiile. 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 până la
şfârşitul ciclului de viaţă, pentru că fiecare etapă
constituie o nouă ocazie pentru alte tipuri de erori.
CM (Componenţa Managementului) este aspectul
care permite identificarea în timp a acelor puncte pentru

pagina 184
Sisteme informatice de gestiune

efectuarea contrulului modificărilor, pentru


monitorizarea integrităţii şi trasabilităţii produsului pe
parcursul ciclului de viaţă. Aceasta permite
conducătorului să cunoască ce s-a făcut, ce se
realizează acum şi cu ce se va continua mai departe.
V+V (Verificarea şi Validarea) se referă la cât de
bine produsul corespunde din punct de vedere
funcţional, al cerinţelor de performanţă şi al interpretării
corecte a cerinţelor. Punctul principal al verificării şi
validării este clientul adică dacă ceea ce i s-a furnizat
corespunde cerinţelor sale.

Aşa cum s-a văzut din cele prezentate


conducerea proiectului este activitatea care traversează
întregul ciclu de viaţă. Conducătorul trebuie să fie atent
în deciziile luate, trebuie să posede informaţiile corecte
pentru luarea deciziilor şi să nu ia decizii compensatorii
atunci când s-a greşit. 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 motivaţiile personale şi
interpersonale. Complexul de atitudini, motivaţii,
intentii, stări afective etc. constituie împreună
"comportamentul uman" care trebuie avut în vedere de
conducător în cele două accepţiuni 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. Abordări orientate spre date şi prelucrări

Ralizarea unui sistem informaţional-decizional


performant este rezultatul unui cumul de factori. Este
cert că nu factorii individuali sunt cei cu influenţă
hotărâtoare ci ansamblul interacţiunii lor. Acest
ansamblu de factori trebuie analizat şi modelat în aşa fel
încât să se obţină performanţa maximă. Dacă prin
extensie spunem că modelarea efectuată pentru
realizarea sistemului este ea însăşi un factor, putem
afirma că într-adevăr acesta este unul important.
Modelarea situaţiei existente sau a celei dorite trebuie să
fie capabilă să reprezinte realitatea la un moment dat
dar şi să se poată adapta la modificările pe care ea însăşi
le preconizează.
Analizând modelele de reprezentare a realităţii
propuse de metoda Merise, se observă două tipuri de
reprezentare.
• Prima este bazată pe postulatul că un sistem trebuie
să realizeze anumite funcţii (existenţa unui material
în stoc, înlănţuirea etapelor pentru construcţia unei
case, etc. ). Această abordare este cea a
descompunerii funcţionale.
• A doua se preocupă de faptul că un sistem informatic
este un sistem de relaţii între entităţi. Spre exemplu
se descrie un individ ca un ansamblu compus dintr-
un nume, unul sau mai multe prenume, un cod
numeric personal şi având unul sau mai mulţi copii.
În acelaşi sens o casă este un ansamblu de fundaţii,
pereţi, uşi ş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 funcţională îşi propune să abordeze


sistemul ca un prestator de servicii care să răspundă la
anumite întrebări. De exemplu “Câţi clienţi au fost
vizitaţi de la începutul lunii?”. Furnizarea răspunsului
presupune desfăşurarea unei serii de acţiuni:
determinarea primei zi lucrătoare din lună, găsirea
clienţilor vizitaţi de la acea dată şi până la zi şi afişarea
rezultatului. Funcţia “găsirea clienţilor vizitaţi de la
începutul lunii şi până la zi” se descompune ea însăşi în
acces la fişierul de clienţi, selecţionarea numărului de
clienţi vizitaţi începând de la acea dată, eliminarea
clienţilor vizitaţi de două ori, etc.. Acest demers ar părea
natural în măsura în care ar reproduce ceea ce face un
salariat căruia i se pune această întrebare. Se poate
distinge o dublă acţiune.
• O împărţire temporală prin care sarcinile trebuiesc
îndeplinite unele după altele. În exemplul dat nu pot
fi selectionaţi clienţii înainte de stabilirea primei zi
lucrătoare din lună. Această dimensiune temporală
pune în relief secvenţialitatea sarcinilor şi
sincronizarea lor.
• Împărţirea procedurilor în subproceduri prin care
sarcinile globale sunt împărţite în activităţi care pot
fi din nou împărţite la rândul lor. Procesul se repetă
până când sarcinile elementare sunt suficient de
simple.

Descompunerea funcţională va fi exemplificată cu


ajutorul modelului conceptual al prelucrărilor din
metoda Merise.
Indiferent de modaliatea practică de realizare a
diagramei funcţionale particularitatea acestei abordări
constă în urmărirea unei aplicaţii prin toate trasformările
pe care le exercită asupra datelor. Este vorba de o
structurare a prelucrărilor. Analiza prin descompunerea

pagina 188
Sisteme informatice de gestiune

funcţională permite să se găsesască sub-proceduri


comune, putându-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 modificări se vor face într-
un singur loc aplicându-se tuturor funcţiilor la care
procedura comună participă.
Ca o alternativă la structurarea prelucrărilor s-a
lansat spre sfârşitul anilor ’80 analiza structurilor de
date. O problemă este reprezentată printr-un sistem de
relaţii dintre elementele care-l compun. Abordarea se
canalizează spre definirea elementelor de model şi spre
stabilirea reţelei de relaţii care le leagă.
Prezentarea acestui sistem de relaţii se face cu ajutorul
diagramei entitate-relaţie. Entităţile reprezintă fiinţe sau
obiecte purtătoare a anumitor proprietăţi iar relaţiile
reprezintă interacţiunile dintre entităţi. O relaţie se
poate exprima printr-o frază al cărui complement sunt
entităţile iar verbul este relaţia dintre ele. Pentru
exemplificare s-a folosit modelul conceptual al
prelucrărilor din metoda Merise pentru aceiaşi problemă
a construcţiei unei case.
Figura 5.2. introduce noţiunea de cardinalitate
(un şofer face parte dintr-o echipă şi numai una iar într-
o echipă pot fi zero sau mai mulţi şoferi) dar spre
deosebire de structurarea prelucrărilor situaţia
prezentată de diagrama entitate-relaţie este statică (se
prezintă datele dar nu se precizează dacă ele sunt în
mişcare sau în repaus). Diagrama entitate-relaţie
explică ce sunt fundaţiile şi ce este necesar pentru a le
construi dar nu explică maniera prin care se poate face.
Tot pe lista minusurilor se poate adăuga, că unui singur
model îi corespunde un număr infinit de realizări
posibile exprimându-se un ansamblu de relaţii posibile
fără 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


prelucrărilor

Pe de altă parte modelul este recunoscut ca durabil în


măsura în care reprezintă realitatea fundamentală a
domeniului de activitate modelat şi este extrem de
adaptabil. Înlocuirea unui şef de echipă sau introducerea
unei noi maşini ( entităţi) cu ajutorul căreia se vor săpa
gropile nu schimbă major sistemul.

pagina 190
Sisteme informatice de gestiune

Abordările orientate spre date şi spre prelucrări


îşi au rădăcina în două sisteme de gândire diferite:

• Analiza prin prelucrări îşi găseşte sursa în noţiunea


de metodă în sensul în care aceasta îşi propune să
rezolve o problemă printr-un cadru procedural.
Acest cadru fixează etapele şi înlănţuirea lor astfel
încât intrările şi ieşirile corespund fiecărei etape.
Această gândire este esenţialmente carteziană şi
analiza prin structura prelucrărilor este legată de
acest curent de gândire.
• Analiza structurilor de date studiază problema
modelării punându-se accentul pe relaţiile 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 totuşi că însăşi 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 prelucrări o dublă abordare a
sistemului, persistă totuşi unele inconveniente.

• Fazele de studii sunt prea lungi şi neproductive.


Împărţirea lucrului ce decurge din abordarea prin
sarcini specializate şi din ciclul de concepţie în V fac
dificilă obţinerea de rezultate notabile. Această
abordare impune o înţelegere globală a concepţiei

pagina 191
Sisteme informatice de gestiune

anterioare programarii. Adesea până când grupul de


studii să termine caietul de sarcini necesităţile s-au
schimbat iar în proiectele de o anumită dimensiune
lungimea fazelor face foarte posibilă frecventa
schimbare a analiştilor. Presiunea este foarte mare la
începutul proiectului, atunci când deciziile cele mai
importante trebuiesc luate plecându-se de la un
minim de elemente. Deci, abordările tradiţionale sunt
caracterizate printr-o dificultate ridicată o primelor
etape când orice eroare poate avea consecinţe grave.
• Comunicarea este dificilă mai ales cu
neinformaticienii. Implicarea utilizatorilor în proiect
este adesea dificilă, principala dificultate constând în
formularea cerinţelor într-un format propriu
modelării. Comunicarea în sens invers nu este nici
ea mai uşoară, pe de o parte din cauza necunoaşterii
de către client a limbajului informatic dar mai ales
datorită necunoaşterii suportului de comunicaţie. De
la un anumit nivel de complexitate verificarea
diagramelor entitate-relaţie şi de structurare a
prelucrărilor de către un neinformatician devine
imposibilă.
• Abordările orientate spre date şi funcţiuni sunt
ireconciliabile. Analiza structurii datelor permite
obţinerea de programe mai evoluate dar ea nu
permite reprezentarea scopului aplicaţiei a ceea ce
utilizatorul aştepta de la ea. Trebuie deci ca mai
târziu să se descrie aceasta prin modelarea
prelucrărilor. 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 prelucrărilor. Problememle cu
adevărat dificile apar la integrarea datelor cu
prelucrările în procesul de realizare dar mai ales în

pagina 192
Sisteme informatice de gestiune

faza de mentenanţă când apare frecvent fenomenul


de regresie. Acesta constă în faptul că modificarea
prelucrărilor într-o zonă a aplicaţiei afectează datele
utilizate de întreg sistemul. Se poate demonstra că
această problemă decurge tocmai din contradicţia
dintre date şi prelucrări.

• Abordarea prin prelucrări impune ca o funcţie


utilizată în mai multe locuri să nu existe decât
într-un singur exemplar. În arborescenţa
programului ea va fi ridicată către vârful
arborescenţei pentru a putea fi utilizată de
toate celelate funcţii care o apelează.
• Securitatea datelor impune ca accesul la ele să
fie făcut de un număr minim de funcţii. Deci
atunci când o dată este modificabilă de mai
multe proceduri este imposibil de a găsi
originea modificărilor. Există deci tendinţa de
coborâre a funcţiei de acces pentru a evita
modificările intempestive.
Aceste considerente au stat la baza naşteri unei noi
abordări, numită orientatată obiect, care are la origine
rezolvarea problemelor de simulare. Într-o astfel de
abordarea nu mai este vorba de analiza funcţiilor sau de
studierea relaţiilor dintre elemente ci mai curând de
situarea în interiorul lor reproducând comportamentul la
anumite evenimente. Din această abordare se naşte
conceptul de obiect ca entitate ce reacţionează singură
şi este independentă. Deşi metoda MERISE preia unele
aspecte ale abordării obiectuale rămâne în sarcina
viitoarelor cercetări integrarea reală a conceptului
obiectual.

Bibliografie.

pagina 193
Sisteme informatice de gestiune

(1) Gh. Boldur Lăţescu, Gh. Ciobanu, I. Băncilă -


"Analiza sistemelor complexe"; Editura ştiintifică şi
enciclopedică Bucureşti 1982
(2) I.Roşca, E.Macovei, N.Davidescu, V.Răileanu
“Proiectarea sistemelor informatice financiar-contabile”
Editura didactică şi pedagogică Bucureşti 1993
(3) Dumitru Oprean "Metode şi tehnici utilizate în
realizarea sistemelor informatice" Editura Dacia 1980
(4) Mihai Păun, 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

S-ar putea să vă placă și