Universitatea “Petru Maior” Târgu Mureş

Centrul pentru Învăţământ cu Frecvenţă Redusă

Conf. Univ. Dr. IOAN RUS

PROIECTAREA SISTEMULUI
INFORMATIC DE GESTIUNE

CURS

Pentru uzul studenţilor

2016 - 2017

1
 CUPRINS

MODULUL I.
ANALIZA SISTEMELOR INFORMAȚIONALE 3
Tema 1. Noțiuni de bază: sistem, sistem economic, sistem informational, sistem
informatic 3
Tema 2. Sisteme informatice 5
Tema 3. Determinarea cerințelor sistemelui informatic 10
Tema 4. Strategii de proiectare 15
Întrebări de verificare 36

MODULUL II.
ORGANIZAREA DATELOR 37
Tema 1. Concepte și principii generale de organizare a datelor, conglomerate
de date 37
Tema 2. Metode de reprezentare a structurilor logice complexe 40
Tema 3. Rolul sistemelor de operare în manipularea datelor 49
Tema 4. Organizarea datelor 51
Întrebări de verificare 53

MODULUL III.
PROIECTAREA SISTEMELOR INFORMATICE 54
Tema 1. Proiectarea logică a sistemelor informatice 54
Tema 2. Proiectarea fizică a sistemelor informatice 57
Întrebări de verificare 73

MODULUL IV.
SISTEME INFORMATICE INTEGRATE 74
Tema 1. Sisteme informatice integrate pentru domeniul economic –
Sisteme informatice ERP, CRM 74
Tema 2. Tendințe în dezvoltarea produselor informatice pentru economie 80
Întrebări de verificare 83

BIBLIOGRAFIE 84

2
MODULUL I

ANALIZA SISTEMELOR INFORMAȚIONALE

Obiectivele modulului

Obiectivele prezentării primului modul presupun cunoaşterea modului de organizare a

sistemelor, noțiuni despre informație, entropie și metode și strategii de proiectare ale
sistemelor informatice.

Structura modulului

Subiectul abordat Pagina

Tema 1. Noțiuni de bază: sistem, sistem, economic, 3
sistem informational, sistem informatic
Tema 2. Sisteme informatice 5
Tema 3. Determinarea cerințelor sistemului 10
informatic
Tema 4. Strategii de proiectare 15
Întrebări de verificare 36

TEMA 1
Noțiuni de bază: sistem, sistem economic, sistem
informațional, sistem informatic

Timp mediu necesar pentru asimilarea acestei Teme: 30 minute

Competenţe

În urma parcurgerii temei, cursanți vor putea să identifice diferitele tipuri de

sisteme dintr-o firmă.

Definirea şi clasificarea sistemelor informatice.

Un sistem este un ansamblu de mai multe elemente care sunt corelate între ele pentru a
realiza un anumit scop.

Ludwig von Bartulanffy - părintele definiţiei sistemului: “sistemul este un ansamblu de

elemente aflate în interacţiune.”

3
 Sistemul este un ansamblu de elemente legate organic între ele prin relaţii logice care
urmăresc îndeplinirea unui scop bine definit.

Despre organizarea sistemelor:

Organizarea sau dezorganizarea sistemelor este în strânsă legătură cu gradul de
cunoaştere sau necunoaştere a sistemelor.

Regulă generală de organizare:

Cu cât un sistem este mai puţin organizat cu atât părţile componente influenţează mai
puţin întregul. Cu cât un sistem este mai organizat cu atât sistemul influenţează şi controlează
părţile mai mult.

De regulă orice sistem se compune din subsisteme: diviziunea în subsisteme se face pe

baza unei caracteristici comune subsistemului. Orice subsistem funcţionează după reguli
proprii şi la rândul lui se poate diviza în alte subsisteme. Din această divizare ierarhică se obţin
nivelurile:

Sistem
întrprinder
e

Subsistem
Subsistem Subsistem desfacere
Subsistem Subsistem
financiar aprovizio-
resusrse producţie
nare şi
umane
desfacere

Subsistem Subsistem
aprovizio- desfacere
nare

Subsistem
furnizor Subsistem
Subsistem Subsistem
personal
personal
clienţi

4
 TEMA 2
Sisteme informatice

Timp mediu necesar pentru asimilarea acestei Teme: 2 ore

Competenţe

În urma parcurgerii temei, cursanți vor putea:

• Să cunoască componentele diferitelor tipuri de sisteme și să
aprofundeze structura acestora.

Sistem. Sistem cibernetic. Sistem economic. Sistem informaţional.

Sistem informatic. Sistem informatic integrat.

Un sistem se compune din:

1) Elementele sistemului sunt obiecte sau fenomene care au o caracteristică comună şi
interacţionează între ele în vederea realizării scopului sistemului.
2) Starea sistemului este mulţimea caracteristicilor sistemului la un moment dat. Avem:
starea iniţială – mulţimea caracteristicilor sistemului la momentul t0.
starea finală – mulţimea caracteristicilor sistemului la momentul tn.
3) Traiectoria sistemului reprezintă stările prin care trece sistemul de la starea iniţială
la starea finală.
4) Factorii sistemului pot fi interni şi externi.
Factorii interni – asupra cărora se poate acţiona din interiorul sistemului.
Factorii exteni – în afara sistemului şi sunt independenţi de acesta.
Exemplul sistemului firmă:
- Elemente: utilaje, maşini, materiale, clădiri, oameni, echipamente
- Conexiuni: fluxuri interne de materiale, finanţe, de oameni
- Starea sistemului: situaţia sistemului la un moment dat
iniţială t0 – începutul anului
finală tn – sfârşitul anului
- Factorii - interni: managementul, fiabilitatea firmei
- externi: cererea de piaţă, comcurenţă, furnizori, clienţi
Conceptul de cutie neagră (Black box):

y
x Orice sistem reprezintă o
S
transformare a intrărilor
în ieşiri.

Funcţia de transformare a sistemului:

y = S(x)

5
 Noţiunea de buclă de reglare:
x y
S Δx – o abatere pe care o introduce bucla de
reglare Δx
asupra intrărilor pentru a reduce diferenţa dintre
R
rezultat şi scop.

Bucla de reglare se mai numeşte conexiune inversă. Un sistem cu buclă de reglare se

numeşte sistem cibernetic.
Stefana Odobleja (1938) a adus contribuţii importante în ceea ce priveşte sistemul
cibernetic.
Orice sistem cibernetic are următoarele elemente:
- sistem de conducere
- sistem condus
- legătură directă
- legătură inversă

intrări ieşiri

Sistem condus
legătură legătură
directă inversă
Sistem conducere

Cibernetica economică analizează economia, structura şi părţile ei componente

Entropia H(x) = - Σ (i=1,n) pi log 2 pi
Energia informaţională E = Σ (i=1,n) pi2 (A)
Organizarea unei companii creşte şi energia informaţională creşte atunci H(x) scade.
Organizarea unei companii scade şi energia informaţională scade atunci H(x) creşte.
Cu cât avem mai multe informaţii despre companie cu atât este mai organizată.

Legi ale sistemelor cibernetice:

Legi generale:
Sistemul cibernetic este un sistem dinamic, deschis, de dimensiuni mari şi complex.
Legi specifice:
1) Legea varietăţii generale: varietatea ieşirilor sau diferenţa între rezultat şi scop
poate fi influenţată de varietatea intrărilor.
2) Legea conexiunii inverse: orice sistem cibernetic conţine cel puţin o buclă de
autoreglare.

6
 3) Legea sinergiei: efectul componentelor la nivel de sistem este diferit de suma
efectelor componentelor subsistemelor.
4) Principiul complementarităţii: orice sistem cibernetic constituie cel puţin o buclă
de reglaj pentru un sistem de nivel superior.
5) Legea entropiei negative: dacă entropia creşte şi gradul de organizare scade atunci
cantitatea de informaţii este mai mică.
Exemple de sisteme cibernetice în economie:
- sistemul cibernetic al producătorului are ca buclă de reglaj cererea consumatorului
- sistemul cibernetic al relaţiilor externe: economia naţională se reglează în funcţie de
relaţiile externe.
- sistemul guvernamental se autoreglează după dimensiunea bugetului
Sistemul economic este un sistem cibernetic format din totalitatea resurselor unei
economii naţionale, a subsistemelor din economie şi a relaţiilor dintre ele.
Sistemul informaţional este un subsistem al sistemului economic format din toate
fluxurile informaţionale care circulă între sistemele de conducere şi sistemul condus,
Sistemul informatic este acea parte a sistemului informaţional care asigură culegerea,
prelucrarea, transmiterea şi stocarea informaţiilor cu ajutorul calculatoarelor electronice pentru
a fi utilizate în conducere.
Sistemul informatic este un ansamblu coerent de echipamente, procese, programe şi
oameni care împreună utilizează calculatoarele electronice pentru prelucrarea datelor. Sistemul
informatic nu e un scop în sine, ci are rolul de a prelucra datele.
Elementele unui sistem informatic:
1. resursa fizică (hardware)
2. resursa logică (software)
3. informaţiile sau datele
4. resursa umană formată din utilizatori şi informaticieni.
O caracteristică a sistemului informatic este de a furniza informaţii prelucrate pentru
conducere.

Particularităţi ale sistemelor informatice:

1) ciclu de viaţă lung
2) gestionează cantităţi foarte mari de informaţii
3) utilizează intens sistemul matematic
4) au un număr mare de utilizatori
5) dispun de proceduri clare, automate şi manuale
6) sunt costisitoare dar eficiente

Clasificarea sistemelor informatice:

Parţiale – se ocupă cu informatizarea unui sector sau al unui subsistem într-o companie.
Totale – se ocupă de informatizarea tuturor sectoarelor subsistemelor companiei.
Integrate – abordează prelucrarea automată a datelor în mod global şi asigură
prelucrarea informaţiilor în toate modurile necesare.
Sistemele informatice asigură informaţia necesară procesului de decizie.

7
 Importanţa deciziilor într-o companie:

Strategice – decizii pe termen lung luate de managerul

companiei pentru o persoană de mai mulţi ani

Tactice – asigură adaptarea sistemului la mediu

Operaţionale – se iau de persoana operativă şi sunt zilnice

Structura sitemului informatic:

În funcţie de natura activităţilor susţinute, sistemele informatice se compun din:
- sisteme destinate conducerii (Manager Suport System (MSS))
- sisteme operaţionale.

Sistemele destinate conducerii - MSS se compun din subsistemele

- suport al executivului (Executive Suport System (ESS))
- suport pentru decizie (Decision Suport System (DSS))
- destinate conducerii curente (Management Information System (MIS))
Sistemele operaţionale sunt:
- sistem pentru procesarea tranzacţiilor (TPS)
- sistem pentru activitate şi birotică (Office Automatization Sistem
(OAS))
- sistem pentru controlul proceselor (PCS)
Un sistem informatic integrat se compune din mai multe subsisteme informatice care
au, aşa cum am văzut, diferite intrări, ieşiri, scopuri şi utilizatori. Prezentăm mai jos aceste
elemente pentru cele mai reprezentative componente ale unui sistem informatic integrat.

Elementele componente ale unui sistem informatic

Sistem Intrări Prelucrări Ieşiri Utilizatori

informatic

TPS date primare, de actualizări, situaţii sintetice şef departament

tip tranzacţii sortări, rapoarte şi analitice

OAS date primare, procesare documente funcţionar,

documente, documente, corespondenţă, manager
secvenţe audio şi comunicări, prezentări
video prezentări

8
 MIS volum de date pe bază de situaţii sintetice şef departament
de intrare din modele şi şi rapoarte
zona TPS analiză

DSS volum mic de complexe cu situaţii şi analize manager,

date din MIS, modele analitice decizionale consilier
TPS destinate administrativ
managerului şi
consiliului
administrativ

ESS date de intrare, simulări grafice analize şi manager,

agregate interne şi simulări cu prognoze consilier
şi externe date concrete administrativ
companiei

Sistemele integrate
Principiul integrării derivă din principiul ordinii şi organizării. Sistemele în evoluţia lor
dezvoltă tot mai multă cunoaştere şi tind să se organizeze în sistem complex.
Sistemele integrate măresc performanţa sistemelor şi elimină redundanţele (lucruri care
se respectă)
Tipuri de integrarări:
- integrare genetică
- integrare prin constrângere (necesară, determinată, legală)
- integrare prin dependenţă
- integrare la alegere
- integrare întâmplătoare

9
 TEMA 3
Determinarea cerințelor unui sistem informatic

Timp mediu necesar pentru asimilarea acestei Teme: 2 ore

Competenţe

În urma parcurgerii temei, cursanți vor putea:

• Să cunoască componentele sistemului cibernetic al întreprinderii.

Sistemul informaţional al firmei

Principalele subsisteme, legături interne şi externe
ale subsistemului financiar contabil

Întreprinderea este un sistem cibernetic care se compune din 5 subsisteme.

1) Subsistemul logistică şi de producţie
2) Subsistemul financiar contabil
3) Subsistemul de marketing
4) Subsistemul de resurse umane
5) Subsistemul de control şi gestiune strategică
Sistemul oricărei organizaţii include sistemul decizional, operaţional şi informaţional.

Sistem Sistem Sistem

decizional informaţional operaţional

Sistemul decizional primeşte prin intermediul sistemului informaţional de la sistemul

operaţional date privind rezultatele proceselor operaţionale. Sistemul decizional analizează
aceste date şi transmite decizii şi dispoziţii către sistemul operaţional tot prin intermediul
sistemului informaţional.

Legăturile organizaţiei cu exteriorul: ca orice sistem şi sistemul „FIRMĂ” are

conexiuni cu exteriorul , de unde preia cerinţe (comenzi) şi livrează satisfaceri (produse şi
servicii). În schema de mai jos sunt redate aceste conexiuni.

10
Sistemele firmei

Sistem
decizional
dec

Sistem
Mediul
Informaţional
înconjurător

Fluxuri de bunuri şi servicii

Sistem
operaţional Produse şi servicii

Sistemul funcţional al unei organizaţii.

Orice organizaţie sau firmă văzută ca un sistem are un anumit scop, se compune din
mai multe subsisteme şi are unul sau mai multe sisteme de autoreglare. Scopul sistemului este
obiectivul sau rezultatul prestabilit pe care o firmă urmăreşte să-l obţină. Realizarea acestui
obiectiv se obţine prin contribuţia mai multor subsisteme la asigurarea funcţionării sistemului
„FIRMĂ”. Nici o firmă nu poate funcţiona de exemplu fără subsistem financiar-contabil
deoarece acesta asigură şi gestionează resursele băneşti necesare funcţionării firmei.
Tot la fel o firmă nu poate funcţiona fără a-şi analiza periodic (zilnic, săptămânal, lunar,
anual, etc) nivelul realizărilor faţă de obiectivul stabilit şi de a lua măsuri în consecinţă. Acest
aspect face parte din bucla de reglare a sistemului firmă.
Nici un subsistem şi nici firma în ansamblul ei nu poate funcţiona independent de alte
firme numite clienţi, furnizori, bănci, etc. Toate acestea arată complexitatea sistemelor de
natură economică şi legăturile necesare care se stabilesc între diferite sisteme sau intre
subsistemele aceluiaşi sistem. În schema următoarele sunt evidenţiate principalele cmponente
şi conxiuni ale sistemului unei firme şi a subsistemelor sale.
Sistemul oricărei firme este un SISTEM CIBERNETIC.

11
 Sistemul funcţional al unei organizaţii.

Piaţa financiară

Subsistem financiar contabil

F plăţi facturi
U CL
R Subsistem Subsistem control Producţi încasări I
facturi logistică interior şi gestiune e E
NI
Z strategică comenzi N
O ŢI
RI livrări Subsistem livrări
Subsistem
resurse
marketing
umane
studi
i

plecări angajări

Piaţa forţei de muncă

Proprietăţile sistemului cibernetic

A) generale
B) specifice

Proprietăţi generale:
a) deschis
b) dinamic
c) de dimensiuni mari
d) complex

Proprietăţi specifice:
a) Legea varietăţii necesare: Varietatea la ieşirea unui sistem poate fi modificată doar
printr-o varietate suficientă la intrarea acestuia.
b) Legea conexunii inverse: orice sistem cibernetic conţine cel puţin o buclă de reglaj.
c) Principiul sinergiei: efectul total al interacţiunilor şi interdependenţelor dintr-un
sistem de este diferit de suma efectelor locale.
d) Principiul complementarităţii externe: orice sistem cibernetic conţine un element a
cel puţin a unei bucle de reglaj dintr-un sistem cibernetic de ordin superior.
e) Legea entropiei negative: în sistemele cibernetice există tendinţa ca sintropia
informaţională să crească şi entropia informaţională să scadă.
Sintropia informaţională reprezintă cantitatea de informaţii pe care o poate dezvolta un
sistem până când ajunge în starea de total cunoaştere. Altfel spus sintropia este cantitatea de

12
informaţie pe care o înmagazinează un sistem la un moment dat şi care se poate obţine numai
prin transformarea sistemului din starea actuală în starea de totală cunoaştere.

Conceptul de cutie neagră y

x
S

J=S (x)

Orice sistem este o transformare care se aplică intrărilor pentru a produce ieşiri.
Sistem cibernetic: orice sistem care are buclă de reglaj se numeşte sistem cibernetic.

x S y

Δx J = S (x+Δx)
R

Sistem cibernetic cu legătură inversă legătură directă

program de
conducere
Sistem de intrări Sistem condus ieşiri
conducere

legătură inversă

Sistem cibernetic al producătorului

Piaţa bunurilor şi serviciilor

Venituri Oferta produse

Sistemul cibernetic al
producătorului ieşiri
Cerere de factor
Servicii de de producţie
producţie Piaţa factorilor de
producţie

13
 Sistem cibernetic guvernamental

Piaţa bunurilor şi
Cerere bunuri
Achiziţii bunuri şi serviciilor
şi servicii
servicii

Sistem cibernetic
Impozite şi taxe Plăţi tranferabile
guvernant

Cerere de bani pentru

Împrumuturi Piaţa financiară acoperirea deficitului
guvern

Sistem informatic integrat (caracterizare, funcţii, avantaje)

Informaţia este o noţiune abstractă care aduce cunoaştere. Manifestarea concretă a
informaţiei o reprezintă datele.
Datele prelucrate generează la rândul lor informaţii de alt nivel, calitate şi agregare.
Sistemul informatic reprezintă un ansamblu de echipamente, programe şi oameni care
împreună rezolvă prelucrarea datelor cu ajutorul calculatorului electronic.
Elementele unui sistem informatic
1) resursa fizică HARDWARE
2) resursa logică SOFTWARE
3) baza de date
4) resursele umane
Principalele module ale unui sitem informatic integrat
1) Planificarea şi controlul producţiei
2) Managementul, aprovizionarea, vânzarea şi producţia
3) Contabilitate financiară şi de gestiune
4) Managementul resurselor umane
5) Managementul calităţii
6) Managementul proiectelor
7) Managementul echipamentelor
8) Managementul serviciilor
9) Controlul companiei

Caracteristicile sistemelor informatice integrate

1) Ciclu de viaţă lung
2) Cost ridicat .
Indici de calitate ai informaţiei
a) oportunitatea (actualitatea)
b) precizie şi acurateţe
c) completitudinea
d) relevanţa – este calitatea informaţiei de a produce stimuli în sistem
e) conciziunea – este calitatea informaţiei de a fi scurtă şi clară

14
 Societatea secolului trecut a fost societatea industrială ce avea ca scop producţia
industrială şi având ca resurse capitalul. Societatea secolului nostru este societatea
informaţională.
Societatea informaţională:
scop: producţia intelectuală
resursele: informaţia
Datele în urma prelucrării şi transformării informaţiei:
- de utilizare
- de tip raţionamente şi experimente
Relaţia tezaur ↔ informaţie
a) informaţia este lângă tezaur

T i

b) informaţiile curente sunt în interiorul tezaurului dar sunt evidenţiate

T i

c) se întrepătrund

T i

TEMA 4
Strategii de proiectare

Timp mediu necesar pentru asimilarea acestei Teme: 4 ore

Competenţe
În urma parcurgerii temei, cursanți vor putea:
• Să se familiarizeze cu termenii specifici
• Să cunoască principalale tehnologii de proiectare utilizate în realizarea
sistemelor informatice.

Consideraţii de ordin general

În funcţie de modalitatea de abordare a realizării sistemului informatic, s-au cristalizat în

timp trei strategii:
• strategia descendentă (top-down);
• strategia ascendentă;
• strategia mixtă.

15
 Strategia top-down (este cea mai răspândită modalitate de descriere a situaţiei curente a
organizaţiei prin care se urmăreşte determinarea cerinţelor informaţionale ale unităţii. Se
începe cu o analiză mai profundă a misiunii organizaţiei, a obiectivelor ei şi a strategiei, pentru
a stabili cu exactitate informaţiile necesare atingerii obiectivelor. Strategia presupune o puternică
implicare a top-managerilor.
Strategia descendentă (top-down) are la bază principiul modularităţii, după cum este
exemplificat în figura următoare şi constă în descompunerea succesivă a unui sistem complex de
sus în jos până la un nivel de module elementare. Descompunerea urmăreşte structura
funcţională a sistemului şi se finalizează în identificarea arborelui structurii sistemului cu
definirea modulelor funcţionale pe fiecare nivel ierarhic şi a legăturilor dintre acestea oferind
o descriere a fiecărei componente a sistemului.

Prin această abordare, sistemul informatic dobândeşte o structură ierarhic modulară

în care fiecare componentă îndeplineşte o anumită funcţionalitate şi va fi coordonată în
funcţionarea sa de componentele plasate la nivelul ierarhic imediat superior.

Strategia descendentă

Rezultă că această strategie se aplică în cazul sistemelor informatice complexe, vizând

o arie largă de cuprindere (de exemplu: sistemul informatic al CCR, sistemul informatic al
unei bănci, sistemul informatic al Ministerului Finanţelor etc.).
Se asigură astfel realizarea unei soluţii globale, unitare la nivel conceptual pentru
întregul sistem, componentele acestuia urmând să fie proiectate şi realizate independent (pe
baza unei planificări), priorităţile fiind fixate în funcţie de opţiunea beneficiarului sau
importanţei respectivelor componente şi conexiunilor necesare în cadrul sistemului global.
Pe măsura realizării componentelor din arhitectura generală a sistemului informatic
acestea se vor testa şi apoi integra în produsul final a cărui funcţionalitate va fi de
asemenea verificată. Se poate realiza trecerea în exploatare a componentelor finalizate
urmând ca integrarea acestora în sistemul informatic global să se realizeze în timp. Aplicarea
unei astfel de strategii impune un efort deosebit atât în perioada de analiză (fiind necesară
o analiză complexă şi foarte amănunţită având în vedere complexitatea proceselor

16
informaţionale supuse informatizării) cât şi de proiectare şi realizare, ceea ce impune eforturi
financiare deosebite.
În procesul integrării componentelor în cadrul sistemului informatic global nu vor apărea
probleme deosebite ca urmare a strategiei unitare de proiectare şi realizare definită la demararea
proiectului. Integrarea se va realiza din treaptă în treaptă pornindu-se de la componentele
elementare (cu gradul cel mai mare de detaliere).
Avantajele metodei top-down:
• Perspectivă mai largă - Dacă n-ar fi văzută în primul rând de sus, organizaţia ar fi
considerată ca un sistem informatic lipsit de imagine de ansamblu.
• Integrare mai bună - Dacă nu ar fi văzut pe ansamblu (de sus), sistemul informatic ar
fi unul nou, şi nu unul integrat în cel existent.
• Sprijin managerial - Dacă n-ar fi implicaţi factorii de decizie de pe nivelul superior,
planificarea sistemului informatic ar avea mai puţine şanse de reuşită.
• Înţelegere mai bună - Dacă nu s-ar vedea unitatea de sus, ar creşte tendinţele de
abordare a unor componente izolate ale acesteia.
Strategia ascendentă (botton-up) este opusă metodei top-down având la bază
principiul agregării şi constă în identificarea de jos în sus a componentelor unui sistem şi
asamblarea succesivă a modulelor definite pe diferite nivele ierarhice şi a relaţiilor dintre acestea
astfel încât se ajunge la un singur modul corespunzător sistemului. Combinată cu metoda
ascendentă a condus la „strategia mixtă” care îmbină elemente de la ambele promovează iniţiativa
la nivelul fiecărui domeniu de gestiune. Această strategie presupune identificarea problemelor
organizaţiei şi a posibilităţilor oferite pentru definirea proiectelor. Se dezvoltă soluţii informatice
la nivelul fiecărui domeniu de gestiune (contabilitate, comercial, producţie etc.) fără a exista
o soluţie cadru şi o arhitectură definită pentru sistemul informatic global la nivel de
organizaţie.
Sistemele de gestiune se realizează şi exploatează independent pe măsura finalizării lor,
răspunzând cerinţelor de gestiune ale domeniilor pentru care au fost realizate, urmând ca ulterior
să se treacă la integrarea acestora în cadrul sistemului informatic global al organizaţiei. Metoda
cere un timp mai scurt şi este mai ieftină, având avantajul de a se şti cu exactitate problemele cu
care se confruntă unitatea. Datorită lipsei unei strategii unitare în plan hardware şi software, a
unei soluţii unitare de proiectare şi realizare există riscul unui grad redus de integrare a
subsistemelor de gestiune cuprinse în cadrul sistemului informatic al organizaţiei. Ca dezavantaj
se consideră lipsa unui punct de vedere de ansamblu, la nivel de unitate.
Strategia mixtă reprezintă o combinare a strategiei descendente cu strategia ascendentă
reţinându-se punctele lor forte. În această abordare se optează pentru o definire a componentelor
sistemului informatic în conformitate cu cerinţele strategiei descendente, urmând ca
proiectarea, realizarea şi integrarea acestor componente să se realizeze urmând cerinţele
strategiei ascendente.
În funcţie de elementul care stă la baza structurii sistemului informatic şi implicit, a
abordării structurale, pot fi identificate mai multe strategii de dezvoltare a sistemelor
informatice – de la cele orientate pe funcţii sau procese şi până la cele orientate obiect.
Strategia descompunerii funcţionale a sistemelor informatice, care este orientată pe
funcţii, nu poate să conducă la conceperea unor sisteme suficient de stabile. Totuşi, pe lângă
problema complexităţii, stabilitatea arhitecturii programelor este una din principalele mize
ale acestei abordări. În acest sens, trebuie amintit conceptul de independenţă funcţională care
stă la baza proiectării arhitecturale a programelor.
Conceptul de independenţă funcţională derivă din principiul „divide et impera” şi
principiul abstractizării. El presupune că fiecare modul de program să fie proiectat astfel încât
el să realizeze o singură funcţie sau subfuncţie a programului, iar interfaţa cu celelalte module să
fie cât mai simplă. Independenţa funcţională este măsurată prin intermediul a doua criterii

17
calitative: coeziunea şi cuplarea. Coeziunea este o măsură a afinităţii mutuale dintre
componentele unui modul, respectiv a modului în care instrucţiunile dintr-un modul sunt
folosite pentru realizarea unei singure funcţii. Cuplarea este o măsură a interdependenţei
relative dintre module, ea depinzând de complexitatea interfeţei dintre module. Cu toate
acestea, eforturile de obţinere a unui anumit nivel de stabilitate în proiectarea sistemului
informatic are puţine şanse de reuşită atât timp cât se porneşte de la premisa că arhitectura
programului este determinată de cerinţele funcţionale ale sistemului. Aceasta presupune
construirea diagramei de structură pe baza diagramelor fluxurilor de date ale sistemului ce
sunt întocmite conform descompunerii funcţionale a sistemului. Ori, se ştie că cerinţele
funcţionale ale unui sistem informatic sunt cele mai susceptibile de a se modifica.
Descompunerea funcţională este cea care anunţă apariţia proiectării structurate şi
analizei structurate. Fiecare funcţie este descompusă în subfuncţii etc., până când se obţin forme
uşor de transpus în instrucţiunile limbajelor de programare.
Şi în cazul descompunerii funcţionale conceptele specifice au fost introduse mai întâi
în programarea structurată (Dahl) şi apoi în proiectare, urmată de analiză. Descompunerea
funcţională (DF) este văzută ca o sumă de funcţii, subfuncţii şi interfeţe funcţionale, sub forma
unei ecuaţii:

Metoda are ca puncte tari simplitatea, obţinerea destul de uşoară a cerinţelor utilizatorului
şi generarea de soluţii pe diferite niveluri de abstractizare (sistem, subsistem, funcţie, subfuncţie).
Ca puncte slabe putem considera concentrarea eforturilor spre funcţii (ceea ce
conduce la culegerea multor date redundante), inexistenţa unor reguli precise de
descompunere şi evidenţierea anevoioasă a interacţiunilor non-ierarhice din sistemele complexe.
Disfuncţionalităţile metodei au fost ameliorate prin soluţii ingenioase de tipul coeziunii şi
cuplării, introduse spre sfârşitul anilor 1990 de Page&Jones şi Zourdon/Constantine.
O altă metodă şi în acelaşi timp o altă modalitate de reprezentare a domeniului problemei
şi responsabilităţilor sistemului printr-o specificaţie tehnică este metoda orientată spre
procese, deseori descrisă ca „analiza structurată”.

Ecuaţia metodei este:

Prin această metodă, analiştii efectuează reprezentarea lumii reale prin linii ale
fluxurilor de date şi cerculeţe pentru procese. În timp, s-au conturat două strategii în analiza
structurată. Se vorbeşte despre o metodă „veche” şi despre o metodă „modernă” de analiză
structurată, lansată în dezbateri la nivelul anului 1982 şi prin materialele editate în 1984 -
reprezentative fiind lucrările autorilor McMenamin&Palmer, din 1984, şi a lui Yourdon
(„Analiza modernă structurată”) din 1989. În ultima variantă sunt definite cu claritate
evenimentele din lumea reală la care sistemul trebuie să răspundă, o formă embrionară a
actualelor interacţiuni dintre utilizator şi sistem, bazate pe mesaje. Sunt incluse de asemenea,
fluxurile datelor şi transformările la nivel inferior prin intermediul dicţionarului de date,

18
respectiv al specificaţiilor proceselor.
Cum metoda orientată pe procese are încă un mare grad de asemănare cu
descompunerea funcţională, criticile metodei descrise anterior se reportează şi în cazul de faţă.
Oricum, după cum se va vedea ulterior, multe elemente ale acestei metode sunt preluate
de către metodele orientate-obiect.
Majoritatea specialiştilor consideră că se poate obţine un plus de stabilitate dacă
structura propriu-zisă a sistemului informatic se limitează la descrierea datelor şi a bazei de
date, presupunându-se că tipurile de date utilizate în cadrul organizaţiei sunt supuse mai puţin
schimbării decât prelucrările din sistem.
Această orientare a dus la apariţia strategiei orientate pe date. Chiar dacă valoarea
datelor se schimbă în mod constant, structura datelor nu presupune modificări esenţiale, dacă
ea a fost bine proiectată de la început. De regulă, clasele de entităţi în legătură cu care se
vor memora datele în sistem nu se schimbă, rareori fiind necesară introducerea unei noi clase
de entităţi, caz în care structura nu suferă transformări esenţiale, ci presupune doar adăugarea
noii clase la structura existentă.
Pe de altă parte, atributele specifice claselor de entităţi identificate în sistem suferă
modificări în mod cu totul excepţional. Descrierea datelor pe cele trei niveluri de abstractizare
– conceptual, logic şi fizic – permite o mai bună evidenţiere a aspectelor invariante specifice
datelor. În acest sens, modelarea conceptuala a datelor, folosind modelul entitate-relaţie, descrie
datele aşa cum sunt ele în realitate, independent de cerinţele organizării şi de cerinţele tehnice
ale suporturilor de stocare şi ale programelor de aplicaţii care le accesează.
Dacă datele sunt relativ stabile, procesele de prelucrare care utilizează datele sunt
considerate a fi supuse schimbărilor în mod frecvent, ca urmare a necesităţii adaptării lor la
cerinţele funcţionale ale utilizatorilor şi la progresele tehnologice.
Este de dorit ca analiştii de sisteme şi utilizatorii finali să fie capabili să schimbe
frecvent procedurile administrative din cadrul sistemului, a căror modelare trebuie realizată cu
maximum de flexibilitate. Modificarea procedurilor de prelucrare determină reproiectarea
prelucrărilor şi fluxurilor din sistem, modificarea programelor de aplicaţii, schimbarea
echipamentelor şi a programelor de sistem. În schimb, structura datelor rămâne relativ stabilă.
Două realizări remarcabile în domeniu au dat tonul acestei noi orientări în abordarea
sistemelor: modelarea datelor cu ajutorul diagramelor entitate-relaţie, de către Peter P. Chen şi
ingineria informaţiei, în viziunea lui James Martin.
Termenul „obiect”, folosit în modelarea informaţiilor sau modelarea semantică a
datelor, este un simbol prin care se reprezintă una sau mai multe „ocurenţe” (cazuri) ale
„entităţilor” lumii reale.
Metoda este identificată prin următoarea ecuaţie:

Coad şi Yourdon spun că şi în acest caz se poate vorbi despre existenţa a două
strategii. Strategia veche se bazează pe conceperea listei atributelor, gruparea lor în obiecte,
stabilirea de relaţii între „ocurenţe” (cazuri), folosirea supertipurilor/subtipurilor pentru
extragerea atributelor comune şi definirea obiectelor asociative pentru reliefarea relaţiilor
sigure.

19
 Noua strategie este destul de apropiată de precedenta, cu excepţia primului pas, care îşi
propune mai întâi să identifice obiectele lumii reale şi apoi urmează descrierea lor cu ajutorul
atributelor. Specialiştii apreciază salturile înregistrate însă, în acelaşi timp, fac inventarul
conceptelor inexistente, cum ar fi: servicii, mesaje, moştenire, structură.
Strategia orientată-obiect pune în centrul atenţiei noţiunea de obiect, considerată drept
o entitate care se poate distinge dintre alte entităţi şi care are o semnificaţie în contextul
aplicaţiei modelate. Obiectul asociază datele şi prelucrările în cadrul aceleiaşi entităţi,
rămânând vizibilă doar interfaţa obiectului.
Un obiect comportă un aspect static, reprezentat prin intermediul unor variabile de stare
numite atribute şi un aspect dinamic, reprezentat de comportamentul obiectului. Aspectul
static este ascuns de aspectul dinamic. În acest fel, abordarea obiectuală se distinge de
abordarea structurată. În locul unei structurări separate a variabilelor de stare, reprezentate de
date şi a funcţiilor, reprezentate de prelucrări, se modelează entităţi active formate din structuri
de date ascunse de funcţii. Un program este privit într-o manieră globală, ca un ansamblu de
obiecte care interacţionează prin intermediul mesajelor, care declanşează operaţiuni ce
determină evoluţia stărilor interne ale obiectelor. În acest fel se obţine un plus de stabilitate în
conceperea sistemelor informatice.
Sintagma „orientat-obiect” este destul de greu de definit din cauza accepţiunilor
diferite care i s-au atribuit de diverse discipline. Numai în domeniul informaticii există trei
variante: una folosită în modelarea informaţiilor, alta în programare şi a treia este cea de faţă,
utilizată în analiza şi proiectarea sistemelor. Fiind un domeniu relativ nou, este normal să existe
o mare diversitate de opinii până şi asupra termenului „obiect”. Ecuaţia ce caracterizează
metoda, o redăm în cele ce urmează:

Conceptele de obiect şi clasă sunt interdependente: un obiect aparţine unei clase (este
o instanţă a clasei), iar o clasă este o grupare logică a obiectelor care au aceeaşi structură şi un
comportament similar. Un obiect este o abstractizare a datelor elementare şi poate fi descris
astfel:

Identitatea obiectului se realizează printr-un identificator al obiectului, care este un

atribut invariabil ce permite ca obiectul să fie referit independent de celelalte obiecte.
Identificatorul este generat de sistem la crearea obiectului.
Starea obiectului este o valoare care poate fi simplă (de exemplu, un literal) sau
structurată (de exemplu, o listă). În ultimul caz, ea poate fi compusă din valori simple,
referinţe la alte obiecte sau valori care ele însele sunt structurate.
Comportamentul unui obiect este definit printr-un set de operaţiuni ce-i pot fi aplicate şi
este descris în clasa căreia îi aparţine obiectul.
Concluzionând, putem afirma că obiectul este o abstractizare a datelor elementare,

20
caracterizat printr-un identificator unic, invariabil, o clasă căreia îi aparţine şi o stare reprezentată
printr-o valoare simplă sau structurată. Abordarea structurală specifică metodelor orientate-obiect
capătă un caracter conceptual mai accentuat, diminuând distanţa semantică ce există între modelul
sistemului şi realitate. Se realizează astfel o mai bună aplicare a abstractizării. De asemenea,
cuplarea redusă dintre obiecte şi coeziunea mare obţinută prin încapsulare şi polimorfism permit
o mai bună localizare a modificărilor, ceea ce determină un nivel redus al riscului efectelor
neaşteptate.

Aspecte privind abordarea activităţilor de proiectare a sistemelor ERP; modele ale

ciclului de viaţă

Pornind de la ciclul de viaţă al sistemelor spre cel al obiectelor, ne-am propus să

surprindem o sintagmă esenţială în activitatea de analiză şi proiectare a sistemelor, respectiv ciclul
de viaţă al dezvoltării sistemelor (CVDS) sau ciclul dezvoltării sistemelor (CDS).
Menţionăm încă de la început că, indiferent de etapa istorică sau metodologică,
sistemele sunt abordate prin prisma ciclului lor de viaţă. Ele apar, se dezvoltă, descresc şi dispar
sau se perfecţionează printr-un nou ciclu, dând naştere unei alte versiuni sau chiar unui nou
sistem. Mutaţiile din domeniul tehnologiilor informaţionale şi al metodelor de abordare a
sistemelor s-au reflectat şi în ciclul de viaţă al dezvoltării sistemelor, fie prin schimbarea
etapelor acestuia, fie prin modificarea opticii de parcurgere a lor.
Ciclul de viaţă al dezvoltării sistemelor este „o metodologie comună de dezvoltare a
sistemelor din multe organizaţii, caracterizată prin câteva faze care marchează evoluţia
eforturilor de analiză şi proiectare a sistemelor”. Fazele sau etapele ciclului de viaţă sunt greu de
prezentat, nu numai ca nume, ci şi ca număr.
Prin parcurgerea materialelor de specialitate, am putut constata că numărul
fazelor/etapelor variază de la trei (de exemplu: analiză, proiectare, implementare) la peste
douăzeci. Firesc, în cel de-al doilea caz, nici simpla enumerare a lor nu este edificatoare.
Totuşi, s-ar putea formula o concluzie: în fazele incipiente de abordare a sistemelor, numărul
etapelor se situa la aproximativ şase. Ele erau descompuse pe activităţi, subactivităţi, operaţiune
firească, apreciem noi, datorită influenţei gândirii bazate pe descompunerea funcţională,
care era la modă. Prin trecerea la orientarea-procese şi orientarea-date, considerăm că s-au
înregistrat două fenomene:
• diversificarea etapelor;
• revizuirea modelului sub care se manifestă ciclicitatea.
Se înregistrează aşadar apariţia uneori, a peste douăzeci de etape.
Odată cu tehnicile de dezvoltare rapidă a aplicaţiilor, prin sistemul prototipizării sau
RAD (Rapid Application Development), cu varianta europeană PD (Participatory Design),
numărul fazelor/etapelor s-a redus din nou, operându-se chiar schimbări ale numelor acestora.
James Martin enumera următoarele faze ale ciclului de viaţă RAD: planificarea cerinţelor,
proiectul utilizatorului, construcţia, finisarea/fasonarea. Dacă facem trimitere la cele şase etape
regăsite în majoritatea opiniilor (analiza sistemelor, achiziţia sistemelor, proiectarea
conceptuală, proiectarea fizică, implementarea şi conversia, exploatarea şi întreţinerea) se
observă cu uşurinţă diferenţele dintre ele.
Referitor la numărul şi numele etapelor ciclului de viaţă al dezvoltării sistemelor, se

21
observă o tendinţă de preluare a unor etape specifice managementului proiectelor. De
exemplu, identificarea şi selecţia proiectului, planificarea şi iniţierea proiectului (numite de
unii specialişti etapele microanalizei) precedă analiza, proiectarea logică, proiectarea fizică,
implementarea, întreţinerea. Apar şi alte puncte de vedere. Ele pot fi asociate curentului creat
de Yourdon în 1989, prin lucrarea privind analiza modernă structurată.
Indiferent de numărul şi numele etapelor ciclului de viaţă al dezvoltării sistemelor,
o problemă mult mai importantă, o reprezintă ordinea şi felul în care se parcurg etapele
respective, ceea ce în literatura de specialitate se tratează sub numele de modele ale ciclului
de viaţă al dezvoltării sistemelor.
Datorită simplei enumerări a etapelor, se poate trage concluzia, la prima vedere, că
ordinea lor este secvenţială, ceea ce nu este confirmat de realitate. Revenirile la etapele
anterioare sunt foarte dese, ceea ce sfidează secvenţialitatea. Uneori, etapele se pot derula
iterativ, dar cu posibilitatea revenirii la etapele anterioare, conform variantei sugerate de
modelul cascadă, sau unele etape se pot derula în paralel.
Unii specialişti văd ciclul viaţă ca pe o spirală, alţii ca pe un proces circular. În literatura
ultimilor ani sunt lansate şi alte modele, cum ar fi: în V, în X, tridimensional,minge de baseball
(sau de oină), fântână arteziană, piramidă, pinball (bila magică) etc. Putem afirma cu certitudine
că, odată cu abordarea orientată-obiect a sistemelor, s-au lansat şi noi modele ale ciclului de viaţă.
Unii autori vorbesc chiar despre cicluri de viaţă orientate-obiect, în care există o puternică
convergenţă între diferitele stadii ale ciclului de viaţă şi un grad ridicat al iteraţiei. Astfel că, în
locul modelului cascadă, s-au propus: modelul spirală (Boehm), modelul fântână arteziană
(Henderson-Sellers şi Edwards), modelul pinball (Ambler) etc.
Considerăm totuşi că este cam forţată legarea unor modele numai de orientarea obiect,
indiferent de momentul lansării lor. E adevărat că unele modele îşi justifică prezenţa în
domeniu, îndeosebi datorită abordării obiect, sau că altele capătă adaptări specifice noului
mediu de lucru.
De exemplu, firma Digital enumera modelele în ordinea lor evolutivă, astfel: cascadă,
incremental, spirală, evolutiv, însă autorii UML – Unified Modeling Language (Booch,
Jacobson şi Rumbaugh) - propun un ciclu iterativ-incremental, bazat pe cazuri de utilizare, ceea
ce denotă o diferenţă a punctelor de vedere, deşi chiar şi ultimii apelează la cascadă în cadrul
iteraţiilor. Datorită marii diversităţi a opiniilor, considerăm binevenită o descriere sumară a mai
multor modele, cu atât mai mult cu cât în literatura noastră subiectului de faţă nu i se
acordă importanţa cuvenită.
Modelul cascadă este unul de referinţă, asigurând trecerea de la o etapă la alta, ce-i drept
mai mult teoretică, în ordine secvenţială. Realitatea a demonstrat că parcurgerea
etapelor/fazelor într-o astfel de ordine nu este o regulă, întrucât, de cele mai multe ori, se
înregistrează reveniri la etapele anterioare sau parcurgerea în paralel a unora dintre ele.
Modelul este lansat la începutul anilor 1970 de către W.W. Royce şi constă în
descompunerea ciclului de viaţă în faze secvenţiale. La rândul lor, fazele sunt structurate pe
activităţi şi subactivităţi. Trecerea de la o etapă la alta se realizează după ce precedenta a fost
parcursă în întregime. Modelul se aplică la nivel de sistem, ceea ce constituie un dezavantaj
întrucât sistemele complexe, cu un număr mare de aplicaţii ce interacţionează între ele, sunt
greu de controlat. Deşi nu este descurajată abordarea iterativă a unor faze sau componente ale
lor, restricţiile de timp impuse de programarea, calendaristică a etapelor limitează efectele

22
benefice ale acesteia, ca şi posibilităţile de revenire la etape anterioare.

Modelul cascadă

Modelului i se recunosc unele avantaje, cum ar fi: un control total asupra fazelor, în
sensul că ele sunt ordonate şi, firesc, previzibile, prin evidenţierea clară a ariei de întindere a
fiecărei etape sau subcomponente a ei; este uşor de însuşit de către membrii echipelor de analiză
şi proiectare, inclusiv de cei noi, cu o experienţă mai puţin vastă; fiecare etapă este însoţită de o
documentaţie perfect structurată (controlată).
Ca dezavantaje, amintim:
• sistemul se predă doar după parcurgerea etapelor anterioare, ceea ce înseamnă o lungă
perioadă de timp, suficient ca utilizatorii să-şi schimbe pretenţiile;
• nu corespunde intenţiilor de abordare dinamică a sistemelor;
• nu este deschis schimbărilor ce pot interveni pe parcurs.
Într-un anumit fel, modelul este folosit de către Booch, în 1991, în proiectarea sa
orientată-obiect la fazele de proiectare şi implementare, precum şi de către Ivar Jacobson, în
modelul OOSE (Object Oriented Software Engineering), în 1992, acoperind toate etapele. Am
putea spune că şi aliatul ulterior al celor doi, Rumbaugh, foloseşte într-o formă oarece
valenţele modelului cascadă, doar că ele se regăsesc într-un mod aparte în modelul V, utilizat
parţial. Ideea de bază a modelului este regăsită şi în altele, cum ar fi modelul X, fântână
arteziană sau cel incremental.

Modelul V este o variantă a modelului cascadă, prin care se introduc conceptele de sistem
şi componente (subsisteme), aplicându-se teste explicite la un sistem ierarhic pentru creşterea
controlului asupra modului în care se desfăşoară etapele.
Tocmai această înlesnire constituie o latură a literei V. Prima este latura din stânga,
parcursă descendent, şi conţine treptele propriu-zise, iar cea de-a doua latură, din dreapta, se
parcurge ascendent, pe ea realizându-se verificările şi validările elementelor create anterior.
Acest model punctează cu mai multă claritate separările dintre ceea ce implică participarea

23
utilizatorului, modelul arhitectural şi cel al implementării. Utilizatorul este implicat doar în
fazele din partea superioară a V-ului.

Modelul în V

Arhitectura sistemului este surprinsă în partea de mijloc a literei, iar partea inferioară a
ei se referă la faze de implementare, care ar putea consta fie din asamblarea componentelor
soft, fie din codificarea unor componente. Modelul se pretează şi în mediul orientat-obiect,
deoarece încurajează prototipizarea, reutilizarea unor structuri superioare. El oferă un control
puternic asupra sistemului în curs de realizare, prin structurile ierarhice şi modulare pe care le
promovează, ceea ce îl face utilizabil şi în cazul sistemelor complexe. Modelul devine şi mai
puternic dacă promovează iteraţia, adică reluarea unor faze, activităţi sau subactivităţi. De fapt,
acesta este stilul adoptat de cei trei autori ai UML – (Booth, Jacobson şi Rumbaugh), modelul
iterativ-incremental, anunţat de anumite performanţe ale modelului V.
În cadrul acestui model se face, de asemenea, distincţie evidentă între verificare şi
validare. Prima se referă la testarea sistemului, în diverse stadii ale lui, dacă s-a construit corect
din punct de vedere logic, în timp ce validarea va scoate în evidenţă faptul că sistemul, în
forma lui finală, răspunde sau nu cerinţelor iniţiale . Tocmai din această cauză, i se reproşează
că lasă validarea prea târziu, după ce sistemul s-a construit, ceea ce îl face ineficient. În forma lui
consacrată, modelul îi aparţine lui Ould, care îl lansează în 1990, anumite forme fiind folosite

24
şi de Rumbaugh, încă din 1991. El utilizează doar latura din stânga V-ului, fazele
descendente, în care un loc esenţial revine tratării sistemului pe componente. Cea mai vădită
preluare a filosofiei modelului V este regăsită în modelul X (Hodgson), din fig.18.
Modelul incremental este o altă variantă a modelului cascadă care promovează ideea
proiectării şi realizării independente a componentelor după definirea arhitecturii globale a SI.

Modelul incremental

Proiectarea şi realizarea SI se face astfel în conformitate cu principiile metodelor top-

down. Sistemul va putea fi livrat beneficiarului şi etapizat pe măsura realizării componentelor
(în funcţie de priorităţile formulate de beneficiar) dar, într-o astfel de abordare pot apărea
dificultăţi legate de integrarea componentelor în sistemul final.

Din figură se observă faptul că primele două etape – definirea cerinţelor şi analiza –
sunt identice cu cele două etape de început ale modelului cascadă, însă din momentul
definirii arhitecturii SI fiecare componentă îşi urmează propriul ciclu de viaţă. Spre deosebire
de modelul în V care presupune integrarea componentelor, testarea şi validarea acestuia, de
această dată se oferă şi posibilitatea livrării independente a componentelor SI către beneficiar
fără a se exclude şi posibilitatea livrării SI final având toate componentele integrate.
Din descrierea de până acum rezultă câteva dintre avantajele modelului:
- se încadrează în principiul arhicunoscut „divide et impera”, prin posibilitatea
abordării unor părţi ale întregului;

25
 - sistemul poate fi livrat şi pe componente realizate la perioade scurte de timp;
- proiectul sau sistemul final poate fi realizat de mai multe echipe sau persoane datorită
modularizării lui.
Dintre dezavantaje pot fi enumerate:
- imposibilitatea aplicării lui în toate cazurile, uneori neexistând elementele necesare
descompunerii întregului;
- componentele pot fi realizate numai după ce întregului sistem i se defineşte
arhitectura, totul derulându-se după principiile metodelor top-down, ceea ce înseamnă încă o
condiţie dură: cunoaşterea şi formularea cerinţelor din faza incipientă de abordare a sistemului;
- fiind posibil de realizat pe părţi, eforturile de integrare a acestora în întreg sunt destul
de mari, vorbindu-se chiar despre o aşa-zisă testare multiplă de sisteme, cu trimitere la faptul că
de fiecare dată când se adaugă o nouă componentă sistemul poate fi considerat unul nou.

Modelul spirală este lansat de unul dintre specialiştii cu preocupări mai vechi legate de
ciclul de viaţă, B.W. Boehm. Acesta s-a ocupat de aşa-zisele modele tradiţionale încă din anul
1981, iar în 1986 anunţă modelul spirală şi publică rezultatele cercetării sale în 1988.

Modelul spirală

El se bazează pe două convingeri:

- natura iterativă a dezvoltării şi nevoia de planificare şi evaluarea riscurilor fiecărei
iteraţii;
- deficienţa înregistrată la modelul V, în care validarea se efectuează prea târziu, îl face
să propună, dimpotrivă, realizarea acesteia cât mai devreme posibil, de cât mai multe ori, prin
construirea prototipurilor.

26
 Modelul este îmbunătăţit de R.G. Williams, R.F. Wirfs-Brock iar Ivar Jacobson îl
ameliorează, în 1990, prin modelul spirală ierarhic şi Rumbaugh, în 1992, prin modelul vârtej
de apă (whirlpool-like). În varianta Boehm, echipa de dezvoltare şi utilizatorii se angajează
treptat în proiect, diminuând riscurile la nivel de prototip. De asemenea, de bun augur este
valorificarea experienţei anterioare în planificarea activităţilor din prototipul următor. Facem
menţiunea că modelul cascadă se va regăsi în fiecare iteraţie. Deci după
cunoaşterea cerinţelor şi efectuarea studiilor de fezabilitate, se realizează sistemul, se
integrează şi instalează printr-o singură livrare, în varianta modelului cascadă.
Dintre avantajele modelului, în afară de posibilitatea evaluării riscurilor în diferite
momente, ar mai fi de amintit şi simplificarea operaţiunilor de evaluare a ceea ce este
necesar în etapa (prototipul) următoare, inclusiv prin prisma costurilor.
Nu ca dezavantaje, ci mai degrabă ca elemente ce condiţionează folosirea modelului,
amintim profesionalismul echipei de dezvoltare şi flexibilitatea în acţiune, inclusiv în
alocarea de fonduri, şi definirea activităţilor ce urmează a fi întreprinse.
Referitor la modelul evolutiv, Carmichael afirma că „metoda orientată-obiect în
abordarea sistemelor permite realizarea a ceva grefat pe ceea ce există şi ameliorarea
incrementală a sistemelor. Aspectul evolutiv al ciclului de viaţă, şi nu cel monolitic se
regăseşte în toate metodologiile orientate-obiect”.
În principiu, modelul evolutiv constă în efectuarea unei investigaţii iniţiale,elaborarea
unei strategii pentru descompunerea proiectului în părţi/segmente, fiecare cu o valoare deosebită
pentru client. Ele sunt realizate şi livrate în mod iterativ şi contribuie la sporirea treptată a
performanţelor sistemului. Formele obţinute pentru părţile componente nu sunt foarte puternic
detaliate, lăsându-se loc pentru adaptări şi modificări ulterioare. Oricare dintre
segmentele/părţile luate în studiu trece prin toate fazele de dezvoltare a sistemelor: definirea
cerinţelor, analiză, proiectare, implementare, testare, utilizare. Clientul intră în posesia unei
forme cvasi-finite la terminarea fiecărui segment. Soluţia întregului sistem înseamnă, de fapt,
segmentarea ei conform modelului evolutiv, care este identică modului în care orientarea-
obiect încapsulează atributele şi funcţionalitatea în obiecte bine definite. Schema generală a
modelului evolutiv este prezentată în figura de mai jos.

Modelul evolutiv

27
 Modelul evolutiv a avut un puternic impact în lumea utilizatorilor, deoarece este
orientat către aceştia. De asemenea, procesul de dezvoltare a sistemelor se efectuează sub un
control permanent, inclusiv din partea clienţilor.
Reuşita utilizării sale constă în crearea unei arhitecturi deschise, flexibile,elaborată prin
participarea tuturor părţilor interesate, inclusiv a utilizatorilor, dar şi a unor specialişti,
profesionişti. Modelul evolutiv preia caracteristica esenţială a modelului circular, o formă
existentă printre modelele tradiţionale. Concepţia modelului circular se baza pe ciclul complet al
unui sistem realizat prin cercuri complete (de 360°). La închiderea cercului (ciclului), se trece la
o nouă versiune a sistemului sau la unul nou.
Modelul tridimensional a fost lansat în Franţa şi susţinut de adepţii acestei şcoli. El a
fost introdus odată cu metoda Merise. Se consideră că este singurul model care ţine cont de
aspectele impuse de bazele de date, prin încorporarea clară a nivelurilor ANSI/SPARC.
Modelul surprinde dezvoltarea sistemelor printr-o redare grafică bazată pe trei axe, descriind
ciclul de viaţă al sistemului, ciclul de viaţă al proiectului şi ciclul de viaţă al abstractizării .
Ciclul de viaţă al sistemului informaţional surprinde timpul vieţii sistemului şi
perioadele principale după care se efectuează schimbări majore, cum ar fi creşteri ale sarcinii
de prelucrare (ca volum al datelor sau al tranzacţiilor înregistrate), schimbări tehnologice
(hard şi/sau soft) sau schimbări structurale (de la sisteme centralizate la arhitecturi distribuite).
Toate acestea determină acţiunile de întreprins în timpul realizării sau întreţinerii sistemului,
după cum sunt prezentate în figura următoare.

Modelul tridimensional

28
 Ciclul abstractizării tratează nivelurile succesive ale specificaţiilor, pornind de la cea
mai pură formă conceptuală, independentă de tehnologie, până la una care depinde vizibil de
mediul tehnologic, nivelul fizic.
Ciclul de viaţă al proiectului, numit de autori şi ciclul deciziei, este echivalent cu
modelul cascadă. El defineşte secvenţa fazelor prin care trece proiectul pentru a fi realizat. În
concluzie, proiectarea unui sistem înseamnă orientarea continuă şi simultană pe cele trei axe.
Se consideră că originalitatea modelului constă în axele ciclului de viaţă al sistemului
şi ciclului abstractizării. Primul ciclu permite o planificare a evoluţiei sistemului şi a
schimbărilor de efectuat, în timp ce al doilea ciclu permite oferirea soluţiei conceptuale pentru
problemă, dată independent de tehnica implementată, ceea ce va oferi posibilitatea extinderii
sistemului în viitor.

Modelul X îşi propune să extindă aria performanţelor obţinute prin modelele cascadă şi
V, ambele fiind considerate ca exemple de modele ale procesului de dezvoltare care, la rândul
lui, ar fi parte integrantă a unui proces mai larg, al livrării sistemelor, pentru care Hodgson,
în 1991, propune un model special.
Specificul modelelor iterative este accentul pus pe minimizarea resurselor de utilizat
pentru asigurarea următorului increment de produs, cu menţinerea legăturii cu obiectivele
proiectului global. Fiecare produs livrat succesiv are o funcţionalitate parţială. Modelele livrării
sunt independente tehnologic, iar impactul orientării-obiect asupra procesului dezvoltării l-a
condus pe Hodgson la formularea noului model al ciclului de viaţă pentru ingineria softului
orientat-obiect. Numit modelul X, el surprinde, în partea superioară a X-ului,
responsabilităţile softului curent şi, în partea inferioară, componentele fizice ale softului.
Partea superioară a X-ului este o variantă modificată a modelului V, exprimând modul
în care specificaţiile tehnice devin sisteme livrate. Ca şi la dezvoltările tradiţionale, există
specificaţii ale sistemului, proiectul arhitectural, proiectarea de detaliu, codificarea, testarea pe
componente, integrarea şi testarea sistemului. Partea inferioară a X-ului este un V întors, pentru
a sugera noţiunea de gestiune patrimonială a depozitelor reutilizabile, fie la nivel de
componentă, de structură, domeniu sau chiar la nivel de aplicaţie.
Modelul X exprimă două mari categorii de cicluri de activităţi: una derulată înainte
(forward activity), care sintetizează sistemul nou (sau modificat) şi o activitate derulată înapoi
(reverse activity) pentru dobândirea sistemelor şi a componentelor lor,pentru catalogarea
diverselor modele, arhitecturi şi componente ale activităţii finalizate pentru o posibilă
reutilizare. Ingineria preventivă (forward engineering) de la nivelul fiecărui stadiu al
procesului încearcă să reutilizeze – prin selecţie, adaptare, rafinare –acumulările anterioare
care se regăsesc în bibliotecile sistemelor. Schematic, modelul X este prezentat în figura
următoare.

29
 Modelul în X

Din punct de vedere economic, dezvoltarea softului în ciclul derulat înainte reprezintă
responsabilităţile curente pe linie de soft, iar ciclul derulat înapoi componentele fizice soft. În
cazul orientării-obiect, modelul X este utilizat corespunzător domeniului nou de studiu.
Atunci când intră în discuţie o nouă aplicaţie, echipa de realizare a ei va dedica un timp
anume pentru aflarea modelelor existente în acel domeniu în vederea determinării gradului
în care ele pot servi noua aplicaţie. Preocuparea esenţială va fi axată pe „ce poate fi luat” în
procesul de analiză. Modelul X de dezvoltare a softului ia în considerare existenţa diferitelor
cicluri de viaţă concurente (paralele) pentru componente, aplicaţii şi proiecte abstracte.
Conţinutul bibliotecilor componentelor fizice se află într-un continuu proces de rafinare.
Partea superioară a X-ului este o reluare modelului V, în care lucrurile erau clare: după
parcurgerea descendentă a etapelor din stânga V-ului urmau verificările rezultatelor şi se
finaliza cu validarea produsului pe latura din dreapta V-ului.

30
 Modelul fântână arteziană îşi are originea în modelul spirală şi în altele care au
reprezentat îmbunătăţiri ale acestuia. Ne referim la modelul spirală ierarhic şi vârtej de apă.

Modelul fântână arteziană

Modelul fântână arteziană este anunţat de Brian Henderson-Sellers şi J.M. Edwards

Edwards, J.M. - The Fountain Model for Object-Oriented Systems Development, in Object
Magasine, 1993, pag. 71-79. Cum modelul spirală îşi are originea în modelul cascadă, iar
modelul fântână arteziană preia forme îmbunătăţite ale modelului spirală, concluzia este că
modelul de faţă este unul căruia trebuie să i se acorde atenţia cuvenită.

Modelul pinball, propus de S.W. Ambler, l-am putea numi „bila magică”. Principiul
modelului este cel al deplasării aleatoare a unei bile împinse printr-un sistem mecanic cu arc
sau electronic, prin simularea mişcărilor mecanice, în vederea atingerii unor ţinte punctate
diferit. În anumite momente, deplasarea bilei depinde şi de acţiunile întreprinse de jucător.

31
 Modelul pinball

În figura de mai sus, tampoanele şi obstacolele de pe panou, precum i cele două braţe
din partea inferioară a acestuia reprezintă activităţi diverse necesare într-un ciclu de viaţă
orientat-obiect: aflarea clasei de apartenenţă, a atributelor, metodelor, relaţiilor dintre obiecte,
definirea colaborărilor, moştenirea, agregarea şi subsistemele, precum şi convertirea
proiectului în instrucţiuni, testarea şi implementarea. Analogia constă în faptul că deplasarea bilei
în interiorul panoului într-un mod repetat aleator seamănă cu ceea ce se întâmplă în ciclul de viaţă
al obiectelor. Ordinea diferă de la o tragere la alta, ceea ce ar putea să însemne şi de la un
proiect la altul.
Modelul minge de baseball (dezvoltare concurentă). Metoda lansată de Coad, Yourdon şi
Nicola se caracterizează prin mai multe aspecte specifice, cum ar fi:
- renunţarea la paşi în favoarea activităţilor;
- modelul minge de baseball (dezvoltare concurentă);
- echipe interdisciplinare;
- rezultate controlate frecvent, măsurabile.
Autorii pornesc de la premisa că dezvoltarea de soft sau de sisteme necesită creativitate şi
inovaţie. Din această cauză, ei renunţă la stereotipia paşilor ce trebuie parcurşi, înlocuindu-i cu
activităţi, în concepţia lor, analiza orientată-obiect şi proiectarea orientată-obiect sunt activităţi,
nu paşi, şi pot fi realizate în paralel. De fapt, această filosofie a lor se regăseşte în modelul minge
de baseball.
Se porneşte de la considerentul că multe organizaţii încep aplicarea unei metode prin
folosirea modelului cascadă sau spirală, însă cu timpul echipele apelează la modelul dezvoltării
concurente, cu scopul îmbunătăţirii comunicării între membrii echipei, dar şi pentru reducerea

32
timpului scurs de la concept la produs finit.

Modelul minge de baseball

Autorii consideră că în modelul dezvoltării concurente, o echipă efectuează în sistem

concurenţial, activităţile de analiză orientate-obiect (AOO), proiectare orientată obiect (DOO)
şi programare orientată-obiect (POO). Printr-o astfel de procedură, analiza orientată-obiect
beneficiază de rezultatele proiectării şi programării orientate-obiect. Proiectarea orientată-obiect
va beneficia de ceea ce-i oferă analiza şi programarea orientată-obiect, iar programarea
orientată-obiect va folosi ceea ce-i pun la dispoziţie analiza şi proiectarea orientate-obiect.
Pentru ca modelul să dea rezultate, autorii propun o structură interdisciplinară a
membrilor echipei ce vor lucra împreună la analiza orientată-obiect, proiectarea orientată-obiect,
programarea orientată-obiect. La o analiză mai atentă a modelului propus, rezultă că el ar fi o
structură circulară bidirecţională care încurajează iteraţia pe arcele de cerc componente, ele
fiind activităţi (etape/faze) sau sarcini ale lor, ceea ce ar fi, de fapt,activităţile şi
subactivităţile promovate de cele mai multe metodologii.

Modelul piramidă. J. Martin şi J. Odell, autorii metodei OOIE (Object-

OrientedInformation Engineering), intenţionează să marcheze evident trecerea de la tehnicile
structurate utilizate în ingineria software aplicabile unui proiect, la tehnici structurate orientate-
obiect aplicabile la nivel de întreprindere în ansamblul ei sau de sector mare al acesteia, în cadrul
ingineriei informaţiei orientate-obiect. Modelul lor se pretează în exclusivitate mediilor de abordare
orientate-obiect. Autorii intenţionează să scoată în relief faptul că succesiunea etapelor unui ciclu
de viaţă înseamnă şi o trecere treptată spre mai multe detalii, pornindu-se de la nivelul superior,
al planificării întreprinderii, spre analiza domeniilor mari ale întreprinderii, proiectarea sistemului
şi apoi construirea lui, conform de mai jos.

33
 Modelul piramidă al ingineriei informaţiei orientate-obiect

Zonele evidenţiate în figura de mai sus cuprind următoarele activităţi:

o Planificarea întreprinderii:
▪ Preocupări în legătură cu obiectivele întreprinderii şi factori de succes
▪ Crearea unei imagini globale asupra întreprinderii
▪ Identificarea obiectivelor de nivel superior ale întreprinderii
o Analiza domenii întreprinderii:
▪ Construirea unui model OO (orientat obiect) al domeniului întreprinderii
▪ Identificarea obiectivelor domeniului economic
▪ Exprimarea regulilor politicilor economice
o Proiectare sistem:
▪ Crearea unui model OO al sistemului
▪ Conceperea proiectului detaliat al claselor
▪ Crearea prototipurilor pentru a fi validate de utilizatori
o Construcţie:
▪ Implementarea metodelor cu generarea codurilor-program
La nivelul superior se construieşte un model global. O parte a lui se dezvoltă în mai
multe detalii la nivelul analizelor întreprinse în domeniile de interes ale întreprinderii, în
continuare, o parte a acestui model se dezvoltă în mai multe detalii la nivelul proiectului de
sistem. Sistemul este apoi construit cu clase şi metode orientate-obiect. Acelaşi depozit
(repository) este folosit la toate nivelurile şi se completează cu cât mai multe detalii posibile.
Modelul apelează la un sistem de diagrame pentru exprimarea detaliilor fiecărui nivel.
În plus, se mai folosesc tehnicile specifice dezvoltării rapide a aplicaţiilor, îndeosebi în faza

34
de construcţie. Pentru cei ce agreează modelul, el este bine acoperit printr-un cadru
conceptual profesionist, dar şi prin tehnici performante. Probabil că excesul de detalii
îndepărtează pe unii dintre potenţialii utilizatori.
După ce am descris principalele modele ale ciclului de viaţă al dezvoltării sistemelor, putem
trage unele concluzii, după cum urmează:
- modelele sunt diferite, în funcţie de tehnologiile folosite în procesul de realizare
sistemelor, saltul considerabil înregistrându-se în mediile orientate-obiect;
- modelele depind şi de mărimea proiectelor, dar şi de domeniile cărora le aparţin
sistemele iar diferenţele dintre modele constau, îndeosebi, în modul de parcurgere a etapelor,
ca ordine, dar şi în ceea ce priveşte modalitatea de abordare a SI;
- în selectarea modelului un rol important îl are echipa ce efectuează această operaţiune,
referindu-ne la experienţa ei de a lucra cu diverse modele;
- cerinţele funcţionale îşi pun, de asemenea, amprenta pe tipul de model; sistemul poate
fi abordat în întregime sau pe componente funcţionale, complexitatea sa reflectându-se, în mare
măsură, în tipul modelului selectat;
- nivelul de implicare a utilizatorilor în realizarea sistemului va impune opţiunea pentru
modelele cu performanţe diferite pe acest plan.
Pentru asigurarea comparabilităţii unor modele, propun o abordare pe cele două axe de
coordonate: una, pe verticală, care să surprindă etapele ciclului de viaţă şi alta, pe orizontală, care
să reliefeze partea de sistem avută în vedere, prin prisma a patru modele prezentate evolutiv,
astfel: cascade, incremental, spirală, evolutiv.

Studiu comparativ al modelelor ciclului de viaţă al dezvoltării SI

35
 Figura de mai sus reprezintă o analiză comparativă a metodologiilor expuse ce studiază
comportamentul indus de modele de ciclu de viaţă asupra fazelor procesului de realizare.
Observăm că la modelul „cascadă”, etapele ciclului de viaţă al dezvoltării sistemelor se parcurg
în totalitate la nivelul întregului sistem (reprezentat prin dreptunghiuri mari), însă la modelul
incremental doar definirea cerinţelor, analiza şi o parte a proiectării se referă la întregul sistem,
celelalte etape fiind parcurse pe părţi/componente ale sistemului (mai multe dreptunghiuri
mici desprinse din cel mare), în final realizându-se integrarea componentelor.
Situaţia este inversă în cazul modelului spirală, sistemul fiind abordat pe componente
în primele etape şi în ansamblul lui în etapele de implementare, instalare şi întreţinere. Cea mai
puternică abordare pe părţi/componente se regăseşte în modelul evolutiv.
Trecerea spre metodele orientate-obiect trebuie să fie explicată în contextul cunoaşterii
analitice a metodelor care le-au precedat. De fiecare dată când se lansează ceva nou, este din
cauză că la vechea formă a fost posibil să se aducă îmbunătăţiri fie de ordinul structurii interne,
fie al funcţionării întregului.

Întrebări de verificare
1. Enumerați minim 5 strategii de proiectare a unui sistem informatic.
2. Enumarați cele cinci subsisteme al sistemului cibernetic al unei întreprinderi.

36
MODULUL II

ORGANIZAREA DATELOR

Obiectivele modulului

Obiectivele prezentării primului modul presupun cunoaşterea modului de organizare a

datelor, recapitularea metodelor de reprezentare a structurilor logice.

Structura modulului

Subiectul abordat Pagina

Tema 1. Concepte și principii generale de organizare 37
a datelor, conglomerate de date
Tema 2. Metode de reprezentare a structurilor logice 40
complexe
Tema 3. Rolul sistemelor de operare în manipularea 49
datelor
Tema 4. Organizarea datelor 51
Întrebări de verificare 53

TEMA 1
Concepte și principia generale de organizare a datelor,
conglomerate de date
Timp mediu necesar pentru asimilarea acestei Teme: 1 oră

Competenţe

În urma parcurgerii temei, cursanți vor putea:

• Să se familiarizeze cu terminologia specifică.
• Să acumuleze cunoștințe legate de organizarea datelor.

Informaţia reprezintă gradul de cunoștere sau de necunoaștere pe care-l avem despre o

sursă de informatiei.
Calculatoarele prin analogie cu viaţa reală prelucrează informaţii. Informaţia reprezintă
cunoaştere.
Sursa de informaţie

e1 e2 ……. en
S:

p1 p2….pn

37
 - se compune din mai multe evenimente şi probabilităţile ca ele să se realizeze.
- cu cât probabilităţile sunt mai certe cu atât avem mai multe informaţii şi evenimente
despre sursa respectivă.
- cu cât probabilităţile se aproprie mai mult de starea “echiprobabilă” cu atât sursa este
mai puţin
cunoscută.
Cantitatea de informaţii pe care o poate DEZVOLTA o sursa se numeşte entropie
informaţională H(x). Arată cantitatea MAXIMĂ de informație a unei surse de informație.
Entropie provine din lb. greacă en = în
tropo = conversie,transformare
n

p
H(x)= - i 1 i * log2 pi
unde:
pi = probabilitatea de apariţie a elementelor
e = numărul evenimentelor

Unități de măsură a informațiilor

BIT –ul = cea mai mică unitate de măsură a informaţiei

OCTET-ul = cea mai mică unitate de măsură a informaţiei care este adresabilă în
computer
1 OCTET = 8 BIŢI = 1 BYTE
Bitul este cantitatea de informaţie pe care o poate aduce o sursă de informaţie cu 2 stări
când trece de la starea de totală necunoaştere (echiprobabilă) la starea de totală cunoaştere
(eveniment cert).
Multiplii octetului:
1 KILOOCTET = 1 KILOBYTE = 1024 octeţi = 210 octeţi
1 KO = 1 KB
1 MEGAOCTET = 1 MEGABYTE = 210 KO= 220 octeţi
1 MO = 1 MB
1 GIGAOCTET = 1 GIGABYTE = 210 Mo = 220 KO= 230 octeţi
1 GO = 1 GB
1 TERAOCTET = 1 TERABYTE =210 Go = 220 Mo = 230 KO = 240 octeţi
1 TO = 1 TB
.... PetaOctetul
.... ExaOctetul
.... ZettaOctetul
.... YottaOctetul
Ce sunt DATELE ?
Forma concretă de manifestare a informaţiei o reprezintă datele.
Datele sunt valori concrete ale mărimii informaţiei.
Există şi păreri care spun că datele sunt elemente primare şi că datele se transformă în
informaţii după prelucrare.

38
 Memoria internă
-ROM (read only memory) memorie internă nedestructibilă
-RAM (random acces memory) adresabilă direct de programator
-ROM - PROM – memorie ROM programabilă
- EPROM – (ERASABLE…) memorie PROM care poate fi modificată
256 sau 512 MB RAM - memoria puțină
1 sau 2 GB - memoria obişnuită

În prelucrarea automată a datelor, datele sunt organizate sub formă de fişiere sau tabele.Această
organizare este regăsită pe suporţi magnetici.
Fişierul este o colecţie de informații omogene din punct de vedere al semnificaţiei şi a
cerinţelor de prelucrare. Fișierul reprezintă o colecție omogenă de informații care au o
caracteristică COMUNĂ.

Fişierul are următoarele elemente:

- articolul (înregistrarea)- reprezintă toate informaţiile despre un obiect, subiect sau fenomen
al fişierului.
- câmpul (atributul)- reprezintă o caracteristică a unei înregistrări.Se defineşte prin următoarele
elemete:
- nume câmp
- tip câmp- arată natura sau felul datelor, poate fi numeric, caracter, alfanumeric.
- lungimea- câmpului este dimensiunea maximă în octeţi alocată pentru câmpul
respectiv.
- număr de zecimale- opţional, de regulă numărul de zecimale şi marca zecimală sunt
incluse în lungimea câmpului.
- domeniul valorilor -
Înregistrările unui fişier sunt de două feluri:
- fizice- sunt aşa cum ele apar pe suportul de înregistrare sub formă de şiruri de octeţi. Mai
multe înregistrări fizice formează un bloc fizic. Transferul de date de pe suportul extern al
fişierului în calculator (şi invers) se face la nivel de bloc. Comandarea operaţiilor fizice de
transfer de date din calculator (şi invers) se face cu ajutorul sistemului de gestiune al fişierelor.
Sistemul de gestiune al fişierelor este o componentă a sistemului de operare.
- logice- sunt structuri de date aşa cum sunt văzute de programatori.
Accesul în fişiere stabileşte modalitatea în care programatorii au acces la o înregistrare din
fişier.
- acces secvenţial este acea modalitate în care pentru a putea prelucra înregistrarea “n” trebuie
să citim toate înregistrările dinaintea ei.
- acces direct prin care o înregistrare poate fi prelucrată fără a citi toate înregistrărirle dinaintea
ei. Accesul direct se poate face dupa o cheie de găsire a înregistrării sau după numărul relativ
a înregistrării în fişier. Accesul direct se face după un calcul matematic al locului unde se află
înregistrarea respectivă în fişier. Calculul se face cu ajutorul unei funcţii:
y= f(x), care se numeşte algoritm de randomizare
Accesul direct pe bază de cheie.
Regăsirea directă pe bază de cheie este acea formă de acces în care identificarea unei
înregistrări se face folosind un câmp al fişierului, câmp numit “câmp cheie” şi un fişier ajutător
numit “index” care ajută la localizarea fizică a înregistrări dorite. Fişierul index are două
elemente:
- referitor la cheile articolelor (interval, poate să nu fie interval)

39
- referitoare la indicaţia de adresă
Căutarea cu ajutorul fişierului index se realizeză astfel:
- se citeşte fişierul de index pentru identificarea locului unde se află cheia dorită;
- se ia din fişier informaţia de adresă şi pe baza acesteia se caută în fişierul principal;
Accesul direct pe bază de adresă relativă de articol
Adresa relativă a unui articol se calculează cu ajutorul unei funcţii:
y = f(x) numită funcţie de randomizare, unde x este elementul care identifică articolul
şi y este adresa relativă a articolului respectiv faţă de începutul fişierului.

TEMA 2
Metode de reprezentare a structurilor logice complexe
Timp mediu necesar pentru asimilarea acestei Teme: 1 oră

Competenţe

În urma parcurgerii temei, cursanți vor putea:

• Să se familiarizeze cu terminologia specifică
• Să acumuleze cunoștințe legate de algoritmi

ALGORITMII :
 Sunt o succesiune de operaţii cunoscute, care rezolvate într-o anumită ordine stabilită,
duc la rezolvarea unei probleme.
 Pentru rezolvarea aceleaşi probleme, există mai mulţi algoritmi.
 Fiecare algoritm defineşte o funcţie matematică.
 Pentru fiecare problemă P există date presupuse cunoscute (date iniţiale pentru
algoritmul corespunzător, A) şi rezultate care se cer a fi găsite (date finale). Evident,
problema s-ar putea să nu aibă sens pentru orice date iniţiale. Vom spune că datele
pentru care problema P are sens fac parte din domeniul D al algoritmului A. Rezultatele
obţinute fac parte dintr-un domeniu R, astfel că executând algoritmul A cu datele de
intrare xD vom obţine rezultatele rR. Vom spune că A(x)=r şi astfel algoritmul A
defineşte o funcţie
A : D ---> R .

Definirea algoritmului: reprezintă cea mai importantă etapă în elaborarea unui proiect
informatic sau a unui program pe calculatoare.
CONCEPTUL de ALGORITM: o transformare aplicată unor date determină obținerea unui
rezultat de prelucrare.
R=T(x)

40
Caracteristici
1. generalitatea – este calitatea algoritmului de a putea fi aplicat la toate problemele din
clasa respectivă sau de acelaşi tip şi totdeauna să dea soluţii
2. finitudinea – este calitatea algoritmului de a avea sfârşit

Algoritmii care nu au sfârşit determină buclarea programului fără să

ajungă la soluţii!
3. claritatea – ordinea de executare a aplicaţilor trebuie exact stabilită
4. completitudinea – este calitatea algoritmului de a trata complet fenomenul modelat

Forme de reprezentare a algoritmilor

Algoritmii se reprezintă cu ajutorul a patru tehnici:
- scheme logice
- limbajul conveţional
- limbajul algoritmic sau pseudocod
- tabele de decizie.
1. SCHEMA LIGICĂ: o reprezentare grafică intuitiva a algoritmului. Definește
operațiile de executat și ordinea lor

Simboluri:

bloc terminal

bloc de calcul ( prelucrare )

bloc de introducere sau extregere

introducere date

extragere date

bloc de condiţie sau control

înlănţuire de blocuri

bloc de procedură (arată instrucţiuni care vor fi descrise în altă parte în

program)

bloc de procedură

 Blocurile delimitatoare Start şi Stop vor marca începutul respectiv sfârşitul unui
algoritm dat printr-o schemă logică.
Descrierea unui algoritm prin schemă logică va începe cu un singur bloc Start şi se va
termina cu cel puţin un bloc Stop.

 Blocurile de intrare/ieşire Citeşte şi Tipăreşte (Afişează) indică introducerea unor

Date de intrare respectiv extragerea unor Rezultate finale.

41
 Blocul Citeşte iniţializează variabilele din lista de intrare cu valori corespunzătoare, iar
blocul Tipăreşte va preciza rezultatele obţinute (la execuţia cu ajutorul calculatorului
cere afişarea pe ecran a valorilor expresiilor din lista de ieşire).

 Blocurile de atribuire (calcul) se utilizează în descrierea operaţiilor de atribuire (:=).

Printr-o astfel de operaţie, unei variabile var i se atribuie valoarea calculată a unei
expresii expr.

 Blocurile de decizie marchează punctele de ramificaţie ale algoritmului în etapa de

decizie. Ramificarea poate fi dublă sau triplă (blocul aritmetic).

 Blocul de decizie aritmetic va hotărî ramura de continuare a algoritmului în funcţie de

semnul valorii expresiei aritmetice înscrise în acest bloc, care poate fi negativă, nulă
sau pozitivă.

 Blocul de decizie logic indică ramura pe care se va continua execuţia algoritmului în

funcţie de îndeplinirea (ramura Da) sau neîndeplinirea (ramura Nu) unei condiţii.
Condiţia care se va înscrie în blocul de decizie logic va fi o expresie logică a cărei
valoare poate fi una dintre valorile "adevărat" sau "fals".

 Blocurile de conectare marchează întreruperile săgeţilor de legătură dintre blocuri,

dacă din diverse motive s-au efectuat astfel de întreruperi .

Exemplu de schemă logică care

reprezintă algoritmul de calcul al unei
sume.

42
 Exemplu de utilizarea a schemei logice pentru ilustrarea unui algoritm de luare a unei
decizii.

43
2. LIMBAJUL CONVENȚIONAL
Limbajul convenţional şi algoritmic
Limbajul convenţional permite exprimarea neambiguă a ordinii de
executare a paşilor unui algoritm cu ajutorul unor reguli sintactice simple. Prin
limbaj înţelegem o mulţime de cuvinte sau de propoziţii împreună cu o mulţime
de regului numite gramatică şi care împreună pot defini comunicarea.

Elementele limbajului convenţional

Notaţii:
Α = condiţie - simplă, compusă
β = bloc de prelucrare
v = variabilă
vo = valoarea iniţială
e = o expresie care se va calcula
Propoziţii
Dacă α atunci β1 altfel β2.
Dacă v ← vo
Dacă v ← e – valoarea expresiei e se atribuie variabilei v
STOP
citeşte intrare= introducere de date
scrie ieşire= extragere de date din calculator

MATERIALEPas 1. CITEŞTE MATERIALE ( i ) i =1,n

COD – MAT Pas 2. i ← 1 , MAX ← PREŢ ( 1 )
DEN - MAT Pas 3. Execută Pas 4. Dacă i < N
PREŢ Dacă i < N execută Pas 4. Altfel Pas 5.

Pas4. Dacă PREŢ ( i ) > MAX atunci MAX ← PREŢ ( i )

Altfel mergi mai departe.
i = i + 1. mergi la pas 4.
Pas 5. Scrie “Preţul maxim este:”
Pas 6. STOP

Limbajul algoritmic (pseudocod) constituie o formă intermediară între limbajul

matematic şi limbajul de programare. Nu este conceput ca un limbaj de programare, are
mai puţine reguli şi o mai mare libertate de exprimare a acţiunilor. Elementele
principale ale limbajului algoritmic sunt cuvintele cheie. Cuvintele cheie sunt acele
cuvinte din vocabularul pseudolimbajului care au o semnificaţie exactă şi care se traduc
uşor într-o instrucţiune de program. De exemplu cuvântul „IF” – dacă.

Limbajul algoritmic este mai exact decât limbajul convenţional.În limbajul

algoritmic avem următoarele instrucţiuni de bază:

44
 1.instrucţiuni de citire- scriere
read listă, variabilă
write listă, variabilă
2. instucţiune de atribuire variabilă: = expresie
Se evaluează expresia şi rezultatul se atribuie variabilei „variabilă”.
3. STOP
4. instrucţiune de ramificare

if condiţie
then secvenţă 1
else secvenţă 2

5.instrucţiune repetitivă condiţionată anterior (ciclu cu test iniţial)

while condiţie
do secvenţă de instrucțiuni.
Se evaluează condiția.

Până când condiția este adevărată se execută secvența de instrucțiuni de după do și se

revine la evaluarea condiției.
Dacă condiția nu este îndeplinită se termină instrucțiunea while și se merge la
instrucțiunea următoare.

6. instrucţiune repetitivă condiţionată posterior (ciclu cu test final)

repeat secvenţă
until condiţie

7.instrucţiune repetitivă cu un număr finit de paşi

for contor= valoare iniţială, valoarea finală, pas

do secvenţa
- se execută secvenţa de un anumit număr de ori (valoare finală –
valoare iniţială) controlată de variabila contorului care se incrementează cu valoarea pas la
fiecare ciclu de executare a secvenţei.

contor= valoarea iniţială

while= (contor – valoarea finală)+ PAS< 0
do secvenţă
contor= contor+ PAS

8. instrucţiune de ramificare multiplă

case expresie of
c1: secvenţa 1

45
 c2: secvenţa 2
…………….
cn:secvenţa n
else secvenţa n+1

Dacă expresia îndeplineşte condiţia c1 se execută secvenţa 1.Dacă este îndeplinită

condiţia c2 se execută secvenţa 2…, dacă nu este îndeplinită nici o condiţie se exercită secvenţa
n+1.

9. instrucţiunea de ramificare redusă

if condiţie then secvenţă

Dacă este indeplinită condiţia se execută secvenţa.

10. instrucţiunea de ieşire forţată din program EXIT

11. Comentariu / * text* / (se explică detalii)

Tabele de decizie

Un nou mod de reprezentare al algoritmilor sunt tabele de decizie.

Tabela de decizie este o modalitate de comunicare între persoanele care participă la
realizarea unui proiect informatic.
Cu ajutorul tabelelor de decizie se pot analiza procese complexe într-o formă foarte
succintă. Conţinutul tabelei de decizie se bazează pe propoziţia „if condiţie then acţiune”.
Orice tabel de decizie are următoarrea formă:

R1 R2 Rm

Condiţii C1 C11 C12 Intrări condiţii C1m

C2 C21 C22 C2m

... ... ... ...

Cn Cn1 Cn2 Cnm

Acţiuni A1 * Intrări acţiuni

A2 *

... * *

An

Orice tabel de decizie prezintă pe linii condiţiile şi acţiunile procesului. Pe coloane sunt
descrise regulile care determină acţiunea. Regulile sunt formate din combinări ale diverselor

46
condiţii legate între ele cu AND sau OR (operatori). Pe liniile acţiunilor sunt marcate (*)
acţiunile care trebuie îndeplinite dacă se respectă o anumită regulă.

Există două feluri de reguli:

- regula lui AND, când toate condiţiile unei reguli sunt legate între ele prin operatorul
„AND”
- regula lui OR, când toate condiţiile unei reguli sunt legate între ele prin operatorul
„OR”
Pe baza unui astfel de model se pot scrie programe. Numărul de regului a unei tabele de
decizie este 2n dacă n este numărul de condiţii al tabelei.

Exemplu: După regulamentul studenţesc promovările din anul I → II se fac astfel:

a) înscrierea în anul II este condiţionată de obţinerea unui mimnim de credite de 40

puncte
b) promovarea anului I este condiţionată de obţinerea unui minim de 60 puncte
c) punctele de credit ale anului I şi II trebuie obţinute în maxim 3 ani în caz contrar
studentul este exmatriculat
d) în caz de concediu medical prevederea de la punctul 1 se reduce la 30 puncte urmând
ca în anul II studentul să obţină minim 50 puncte

Să se elaboreze un model cu tabele de decizie care să rezolve problema.

I Condiţii
c1 numărul de puncte credit dat în anul I
< 30, > 30, > 40, > 60
c2 dacă are sau nu concediu medical
D, M
c3 dacă a fost 2 ani în anul I
2 ani, I (D, N)
II Acţiunile
A1- studentul este declarat promovat şi înscris în anul II
A2- studentul este înscris în anul II
A3- studentul rămâne în anul I cu prelungire de şcolarizare
A4- studentul este exmatriculat

R1 R2 R3 R4 R5 R6 R7 R8

Condiţii C1 >=60 >=40 >=30 >=30 >=30 <30 <30 <30

C2 - - D N N - - D

C3 - - - D N D N D

Acţiuni A1 *

A2 *

47
 A3 * * *

A4 * * *

O tabelă de decizie poate fi redusă dacă mai multe reguli duc la aceeaşi acţiune prin
definirea unei reguli compuse.

ALGORITMI DECIZIONALI IMBRICAȚI

48
 TEMA 3
Rolul sistemelor de operare în manipularea
datelor
Timp mediu necesar pentru asimilarea acestei Teme: 1 oră
Competenţe

În urma parcurgerii temei, cursanți vor putea:

• Să se familiarizeze cu terminologia specifică
• Să acumuleze cunoștințe legate evoluția sistemelor de operare

Sisteme de operare – caracteristici generale 1

Obiectivele generale ale unui sistem de operare sunt:
• automatizarea operaţiilor standard în toate etapele de exploatare a sistemului
de calcul;
• minimizarea efortului uman pentru utilizarea sistemului de calcul;
• optimizarea utilizării resurselor sistemului de calcul;
• creşterea eficienţei globale în utilizarea sistemului de calcul
Funcţiile sistemelor de operare
Sistemele de operare trebuie să îndeplinească patru funcţii esenţiale:
• gestiunea prelucrărilor;
• gestiunea intrărilor şi ieşirilor;
• gestiunea fişierelor;
• dialogul cu utilizatorul.
Gestiunea prelucrărilor
Prelucrările reprezintă un ansamblu de activităţi codificate prin comenzi ale
limbajului specific sistemului de operare. O activitate contine una sau mai icomenzi,
elementare sau complexe, care pot fi executate executa secvenţial sau concurent. Gestiunea
prelucrărilor este asigurată de un program monitor care coordoneaza executia
taskurilor/programelor si realizeaza gestiunea resurselor sistemului de calcul in timpul rularii
programelor.
Gestiunea intrărilor şi ieşirilor
Prin intrari si iesiri se face referire la schimburile de informatii dintre unitatea centrală
şi echipamentele periferice. Acestea sunt gestionate de sistemul de operare prin componenta
BIOS, care contine comenzi de citire/scriere a datelor şi informaţiilor de pe/pe unităţile
periferice. Gestiunea fişierelor
Datele sunt organizate pe suporturile de memorare a informatiei in fisiere. Sistemul de
gestiune a fişierelor este o componentă a sistemului de operare care asigura gestiunea
fişierelor şi potecţia datelor. Protectia datelor se asigura la acest nivel prin drepturile de
citire/scriere/modificare/stergere a fisierelor, drepturi ce sunt acordate de administratorul
sistemului de calcul fiecarui tip de utilizator.
Dialogul cu utilizatorul

1
http://formare.contatic.ase.ro/pluginfile.php/34/mod_resource/content/1/1C%20sisteme%20de%
20operare.pdf

49
 Se refera la o interfata care permite comunicarea intre sistemul de operare si
utilizatorul uman. Aceasta interfata poate avea o forma simpla, sub forma unor comenzi sau
pot avea o grafica complexa, facilitand comunicarea
Sisteme de operare
Cele mai moderne sisteme de operare şi aplicaţii au interfeţe grafice cu utilizatorul
(GUI - Graphical User Interface) care folosesc ferestre ce conţin pictograme, meniuri,
indicatori şi care pot fi utilizate cu ajutorul mouse-ului sau al tastaturii. Un exemplu
concludent în acest sens, îl constituie Microsoft Windows. În fiecare fereastră a sistemului de
operare Microsoft Windows, se poate executa un program sau se pot afişa date diferite, astfel
că o fereastră reprezintă vizualizarea logică a unui fişier (de exemplu, conţinutul unui
director, un fişier text, o imagine, etc.). Prin activarea mai multor ferestre, se poate lucra
simultan cu mai multe aplicaţii, dar şi ieşi, din toate programele accesate, în acelaşi timp (ex.
închiderea simultană a tuturor ferestrelor de Internet Explorer).
Ferestrele pot fi aranjate astfel încât acestea să nu se suprapună (mozaic windows) sau
să se suprapună (ferestre acoperite). O fereastră se poate muta, redimensiona pe ecran.
Sistemul de operare Windows reprezintă un sistem de programe şi comenzi conceput şi
dezvoltat pe un mediu de interfaţă grafică care se instalează, execută şi selectează pe
calculatoare personale, în funcţie de configuraţiile hardware disponibile şi de cerinţele
utilizatorilor.
De-a lungul timpului au existat mai multe generaţii de sisteme de operare Windows,
aliniind cerinţele software cu cele hardware. Astfel, în anul 1981, IBM a lansat Personal
Computer (PC), un standard hardware care urma să fie copiat de toţi producătorii de
calculatoare, dar care necesita un sistem de operare local instalat şi configurat. Astfel a luat
naştere sistemul de operare MS-DOS (Microsoft Disk Operating System), realizat de
Microsoft, un succesor al sistemului de operare UNIX. Sistemul MS-DOS era foarte puternic,
însă avea un neajuns: folosea comenzi date de utilizatori de la tastatură care trebuiau reţinute.
Un alt dezavantaj era faptul că pentru a porni un program, utilizatorul trebuia să intre mai
întâi în directorul programului şi apoi să tasteze denumirea fişierului executabil. Pentru a
suplini aceste dezavantaje, Microsoft a lansat pe piaţă un alt sistem de operare cu denumirea
“Interface Manager”.
Evoluţia mediului Windows
În lanțul evolutiv al produsului Microsoft Windows, amintim etapele inițiale: Win
3.1.,Win98, Win2000, Win Me.
Începând cu produsul Wi8ndows XP, firma Microsoft a livrat un produs stabil, care a
cucerit piața utilizatorilor de PC-uri.

Windows XP
Windows XP integrează punctele forte ale versiunii Windows 2000 - securitatea
crescută, administrabilitatea şi fiabilitatea cu cele mai bune caracteristici de business ale
Windows 98 şi Windows Me – Plug and Play, interfaţa cu utilizatorul uşor de folosit şi
serviciile inovative de suport.
Avantajele sistemului de operare Windows XP sunt date de:
• Implementare şi integrare rapidă - Windows XP asigura o administrare
avansată, implementare şi instrumente pentru suport tehnic care făceau sarcina
50
 administratorilor de sistem mai uşoară Windows XP se integra fără probleme
în mediile existente ale Windows 2000 Active Directory, oferind şi politici noi
de sistem;
• Mobilitate –Windows XP aducea facilităţile inovative în mobilitate cum ar fi
Remote Desktop care permiteau lucrul la distanţă şi accesarea calculatorului
de la distanţă, prin intermediul conexiunii la reţea;
• Securitate la nivel de business – Caracteristicile de securitate de prim nivel
vizau apărarea fişierelor importante, informaţiilor, activităţilor pe Internet şi
confidenţialitatea, cum ar fi Internet Connection Firewall.
• Fiabilitate sporită – Comunicaţiile cu clienţii şi partenerii –Windows.
Windows XP a apărut în mai multe variante: Windows XP Professional,
Windows XP Home Edition, acestea fiind ediţii pe 32 biţi, ulterior apărând
sistemul de operare Windows XP pe 64 biţi (unul din principalele avantaje
constând în recunoaşterea capacităţii RAM mai mare de 3,5 GB).
Windows Vista
Windows Vista a fost lansat în luna ianuarie 2007. Noul sistem de operare în variante
pe 32 biţi sau 64 biţi are în plus faţă de Windows XP o serie de caracteristici multimedia
superioare, precum Windows Media Center, care permite gestionarea de înregistrări video,
audio şi programe TV, toate din PC-ul cu un tuner TV. Opţiuni noi de securitate, precum
controalele parentale şi Anti-Spyware integrat, permit protecţia datelor. În ediţiile Home
Premium, Business si Ultimate ale S.O. Windows Vista, se văd mai clar activităţile la care se
lucrează cu ajutorul noii interfeţe Windows Aero, care include Windows Flip 3D, ce permite
comutarea rapidă între ferestre şi activităţi. Windows Vista poate permite organizarea şi
găsirea cu uşurinţă a fotografiilor, înregistrărilor video, muzică şi documente, utilizează
instrumente noi, cum ar fi căutarea integrată, opţiunea „căutare instantanee” (Instant Search)
a îmbunătăţit procesul de căutare a fişierelor. Prin introducerea numelui unui element căutat,
de exemplu data unei fotografii, titlul unei melodii sau un cuvânt dintr-un document sau un
mesaj, funcţia Căutare instantanee va lista toate rezultatele relevante.
Windows 7
Sistemul de operare Windows 7 (WIN 7) disponibil în varianta 32 biţi şi 64 biţi
(recunoaşte memoria RAM mai mare de 2 GB) , lansat pe piaţă la noi în ţară în 2010, prezintă
noi caracteristici în interfaţa cu utilizatorul. Pentru un utilizator care are cunoştinţe de
Windows XP sau Vista, aceste noutăţi pot fi identificate cu uşurinţă, datorită familiarizării cu
mai vechile sisteme de operare. Lucrul cu WIN 7 este nou şi diferit prin rapiditatea în
răspunsul cererilor făcute de utilizator. Instalarea acestui sistem de operare nu necesită o
pregătire în prealabil, realizându-se prin apăsarea succesivă a butoanelor next, atunci când
acesta o cere, după o anumită configurare (ex. Tastatura, ceasul, numele logic al
calculatorului, reţea, etc). Odată cu sistemul de operare, producătorul furnizează gratuit şi
aplicaţiile: Intenet Explorer 9 (variantă de navigator la care încă se mai lucrează), Windows
Live Essentials 2011 şi Microsoft Security Essentials.
Windows 8, 10 și Windows Phone
Prin Windows 10 Microsoft face trecerea catre echipamentele mobile, asigurând
același gen de interfață atât pentru lucru pe stații cât și pe tabletă sau telefonul mobil.

51
 TEMA 4
Organizarea datelor
Timp mediu necesar pentru asimilarea acestei Teme: 1 oră

Competenţe

În urma parcurgerii temei, cursanți vor putea:

• Să se familiarizeze cu terminologia specifică.
• Să acumuleze cunoștințe legate de organizarea datelor.

Organizarea datelor
Organizarea fişierelor se poate face în trei feluri: secvenţial, secvenţial indexat şi direct.
Fişiere secvenţiale sunt acele fişiere în care accesul la înregistrare se face numai sec
venţial parcurgând toate înregistrările de la începutul fişierului la înregistrarea dorită.
Fişiere secvenţial indexate sunt acele fişiere în care pe lângă înregistrarea fişierului mai
există un fişier anexă numit “fişier index”, care are rolul de a asigura accesul la înregistrările
efective de date cu ajutorul unei tabele logice.
O altă modalitate este folosind intervale de început şi sfârşit a cheilor de regăsire şi
adrese fizice pentru cheia de început de interval. Căutarea se face se face citind secvenţial
tabela de index şi localizând intervalul în care aceasta se găseşte. În intervalul localizat folosind
zona de adresă fizică se realizează o poziţionare pe suport la înregistrarea ce reprezintă
începutul intervalului. De aici începe citirea secvenţială până se găseşte înregistrarea dorită.
Citirea înregistrărilor din fişierele secvenţial indexate cu ajutorul tabelelor de index se numeşte
căutare directă.
Fişiere de organizare directă- în acest caz înregistrările se regăsesc direct pe suportul
magnetic folosind o funcţie pentru calculul poziţiei înregistrării respective, funcţie care asigură
o corespondenţă biunivocă între un câmp al fişierului şi localizarea înregistrării pe suport.
Această funcţie se numeşte funcţie de randomizare.
Algoritmul de randomizare asigură identificarea fizică a înregistrării dorite prin calculul
y= f(x). Este important ca funcţia de randomizare să fie absolut aceeaşi la scrierea fişierului şi
la citirea lui.

Operaţii cu fişiere
Operaţiile cu fişiere se referă la două aspecte: la nivel de fişier şi la nivel de articol.

Operaţii la nivel de articol

- adăugarea de noi articole
- modificarea de articole existente- înseamnă modificarea unor câmpuri sau informaţii care
presupun citirea articolului, modificarea şi rescrierea.
- ştergere articol- poate fi fizică, adică ştergere efectiv sau logică, care se face cu ajutorul
unui câmp pentru ştergere care se marchează pentru cele şterse într-un anumit fel
Operaţii la nivel de fişier
1. Copierea fişierului dintr-un loc în altul;
2. Ştergerea fişierului;
3. Asigurarea securităţii fişierului;
4. Schimbarea numelui;

52
Sortarea şi interclasarea fişierelor
Spre deosebire de algoritmii de sortare obişnuiţi, când vorbim de sortarea fişierelor
avem un volum foarte mare de date. Aceste date din fişiere nu pot fi încărcate deodată în
memoria calculatorului. Din această cauză sunt necesare alte tehnici de sortare.

Interclasarea fişierelor
Datorită volumului mare de date, fişierele se interclasează ţinând cont de 3 lucruri:
1) prelucrări de interclasare pentru primele două articole
2) prelucrări de interclasare pentru situaţia când nici unul din fişiere nu s-a terminat
3) prelucrări de interclasare pentru situaţia în care unul din fişiere s-a terminat. În acest caz
se folosesc variabile logice pentru controlul terminaării unui fişier.

Rezolvare simplă de interclasări

Dacă nu se fac precizări cu privire la articolele multiple (care au aceeaşi cheie) atunci
interclasarea va scrie în fişierul rezultat toate articolele cu chei multiple aşa cum existau ele în
fiţierele componente. Dacă se fac precizări asupra unor prelucrări sau moduri de tratare a
articolelor multiple (care au aceeaşi cheie) atunci prelucrarea se rezolvă în două etape, astfel:
1. se interclasează fişierele scriind în ieşire toate articolele din cele 2 fişiere de intrare
2. se prelucrează fişierul rezultat printr-un algoritm separat efectuând pentru cheile duble
prelucrările cerute în probleme

Întrebări de verificare

1. Construiți o schema logică pentru un algoritm care să rezolve problema inventarierii

produselor alimentare care au expirat, într-un magazin.
2. Transcrieți algoritmul de la pct.1 în limbaj natural și ulterior în limbaj conventional.
3. Precizați platformele pe care poate opera Win10.

53
MODULUL III

PROIECTAREA SISTEMELOR INFORMATICE

Obiectivele modulului

Obiectivele prezentului modul sunt prezentarea principalelor metode și tehnici

utilizate în proiectarea produselor software.

Structura modulului

Subiectul abordat Pagina

Tema 1. Proiectarea logică a sistemelor informatice 54
Tema 2. Proiectarea fizică a sistemelor informatice 57
Întrebări de verificare 73

TEMA 1
Proiectarea logică a sistemelor informatice
Timp mediu necesar pentru asimilarea acestei Teme: 1 oră

Competenţe

În urma parcurgerii temei, cursanți vor putea:

• Să se familiarizeze cu terminologia specifică.
• Să acumuleze cunoștințe legate de tehnicile de proiectare ale
sistemelor informatice.

Proiectarea sistemelor informatice este un proces complex care trebuie să identifice

toate aspectele relevante ale sistemului actual, posibilităţi de îmbunătăţire a acestuia şi
modalităţile de informatizare a componentelor sistemului analizat. Pentru realizarea sistemelor
informatice se parcurg mai multe etape cu obiective şi activităţi specifice.
Etapele de realizare a unui sistem informatic sunt:
1) Strategia
2) Analiza sistemului informatic
3) Concepţia (proiectarea) sistemului informatic (se elaborează documentaţia
proiectului)
4) Realizarea sistemului sau programarea
5) Tranziţia
6) Exploatarea

54
 STRATEGIA
STRATEGIA

ANALIZA
ANALIZA

CONCEPTIE
CONCEPTIE
PROIECTARE
PROIECTARE

DOCUMENTATIA
DOCUMENTATIA
REALIZAREA
REALIZAREA UTILIZATOR
UTILIZATOR

TRANZITIA
TRANZITIA

EXPLOATAREA
EXPLOATAREA

Etapele realizării unui sistem informatic

Analiza sistemelor informatice

Determinarea cerinţelor sistemelor informatice se realizează cu ajutorul
metodelor de analiză tradiţionale sau moderne.

Metode - tradiţionale: interviu, chestionare, analiza documentelor, observare directă

- moderne - rapide: JAD (Join Apllications Design), prototip, RAD
- pe procese

JAD este o metodă de analiză proiectată de IBM. Ea constă în identificarea cerinţei

proiectului prin realizarea unor sesiuni de lucru JAD. La aceste sesiuni participă utilizatorii şi
proiectanţi. Se organizează una sau mai multe sesiuni JAD care durează de la 4ore până la o
săptămână.
Participă la şedinţă:
- conducătorul sesiunii care trebuie să fie specialist în management.
- utilizatorii (specialişti din domeniul respectiv care lucrează ca executanţi)
- manageri de nivelul mediu pentru care se proiectează sistemul
- sponsorul sau susţinătorul proiectului care este o persoană din conducerea companiei
care este în măsură să ia decizii şi să finanţeze proiectul.
- analiştii de sistem care sunt informaticieni specialişti pe analiză (pot fi de la
compartimentul IT sau de la companii specializate)
- scribul (secretar)
- informaticienii (proiectanţi, programatori)

55
 Şedinţa JAD are următoarele obiective: prezentarea de către analişti a sistemului
existent (discutarea cu utilizatorii a acestei prezentări) şi prezentarea concepţiei noului sistem
informatic. De obicei se prezintă scheme de context, scheme bloc. Informaticienii explică
noului sistem şi se comentează de către utilizatori pe marginea acestui subiect.
Obligatoriu această şedinţă se desfăşoară în afara localităţii sediului beneficiarului
pentru ca toţi participanţii să fie deconectaţi de la activitatea curentă de la serviciu.
Prototipizarea constă în faptul că se identifică un produs informatic existent dintre
sistemele informatice existente din domeniu în care facem analiza. Acel sistem se pune în
funcţiune. Se mai numeşte punerea în funcţiune a unui sistem rudimentar. După punerea în
funcţiune a sistemelor informatice toţi utilizatorii, pentru o perioadă definită de timp au dreptul
de a-şi exprima nemulţumirile. După această perioadă se analizează oportunitatea efectuării
unor modificări asupra sistemului. Dacă ele există, se efectuează şi apoi avem un nou sistem
funcţional.

RAD (Rapid Applications Development): se formează un colectiv din cei mai buni
utilizatori şi informaticieni care studiază produse existente şi presupun implementarea unui
produs existent sau a unui produs cu modificări. Se execută modificarea şi se pune în funcţiune
produsul astfel obţinut în forma finală.

Metode moderne de proiectare orientate pe procese

Aceste modalităţi de proiectare sunt efectuate cu unelte automate din categoria CASE
(Computer Aided Systems Engineering).
Cele mai dezvoltate produse din această clasă sunt ale firmei ORACLE.
Metodele moderne se caracterizează prin reducerea perioadei de analiză şi proiectare,
reducerea costului şi probabilistic obţinem aceleaşi performanţe ca şi prin metodele
tradiţionale.
Metodele tradiţionale sunt mai costisitoare, mai consumatoare de timp şi resurse umane,
duc la rezultat sigur şi conform cerinţelor beneficiarului. Se utilizează atunci când se doresc
proiecte pe măsură sau la cerere.
Analiza documentelor este metoda prin care se identifică informaţiile relevante din
document.
Observarea directă constă în participarea informaticienilor la derularea proiectului
analizat sau studiat.

56
 TEMA 2
Proiectarea fizică a sistemelor informatice
Timp mediu necesar pentru asimilarea acestei Teme: 4 ore

Competenţe

În urma parcurgerii temei, cursanți vor putea:

• Să se familiarizeze cu terminologia specifică.
• Să acumuleze cunoștințe legate de tehnicile de proiectare ale
sistemelor informatice.

MODELAREA
Modelarea parcurge trei etape:
1. Modelarea proceselor
2. Modelarea datelor
3. Modelarea prelucrărilor.

1. Modelarea PROCESELOR
Modelarea proceselor – procesele reprezintă subsisteme formate din resusrse
materiale şi umane împreună cu regulile de prelucrare şi stocare a datelor. Prin modelarea
proceselor înţelegem descrierea prelucrării de date. Prelucrarea de date şi descrierea proceselor
se realizează cu ajutorul diagramelor.

Diagramele folosite în modelarea proceselor sunt de 3 feluri:

1) diagrama de context (scheme bloc). Cu ajutorul lor se descriu procesele în
ansamblu şi se clarifică aria şi întinderea sistemului proiectat.
2) diagrama fluxurilor de date fizice – specifică persoanele şi tehnologiile folosite în
prelucrarea datelor.
3) diagrama fluxurilor de date logice – descrie prelucrările care se efectuează
indiferent de tehnologia folosită.

Diagrama de context – pentru procesul de vânzare / cumpărare marfă

Client

Prelucrare
Bancă stocuri Furnizori
vânzare
cumpărare

informaţii
Date şi rapoarte
despre vânzări Conducere

57
 Descompunerea diagramei de context se face pe nivele astfel:
1) diagrama de nivel 0 cuprinde subsistemele sistemului.
2) diagrama de nivel 1 – diagrama funcţiilor unde fiecare fiecare subsistem se poate
descompune în maxim 7 funcţii.
3) diagrama de nivel 2 este diagrama prelucrărilor pentru fiecare aplicaţie din nivelul
1; se pot detalia maxim 49 de prelucrări.
Detalierea prelucrării se face pe două criterii:
- prelucrările definite să fie relativ independente şi clare
- prelucrările să definească un algoritm de prelucrare.
Detalierea prelucrărilor se face atât de mult încât o prelucrare să se scrie pe maxim o
pagină. Dacă este necesar o prelucrare din diagrama de nivel 2 se poate detalia în nivelul 3 tot
în aceeaşi diagramă.

Fluxuri de date

Fluxurile de date se reprezintă pe schemele sistemelor informatice cu ajutorul săgeţilor.

Reguli pentru verificarea unui model:

1. nici un proces nu poate avea numai ieşiri
2. nici un proces nu poate avea numai intrări
3. datele nu pot fi transferate dintr-un loc în altul numai prin intermediul unui proces
4. simbolizarea unui flux de date spre un loc de stocare înseamnă actualizare (datele din
depozit se modifică)

Modelarea datelor
Datele sunt elementele principale asupra cărora acţionează programele. Fizic datele se
găsesc în fişiere sau baze de date → structură fizică (tabelă = fişier)
În fişiere şi tabele se găsesc înregistrări, articole sau entităţi.
Entitatea este un ansamblu de informaţii şi legături referitoare la obiecte şi evenimente
care au o caracteristică comună.
Modelarea datelor se face cu ajutorul modelului entitate, asociere sau legătură, numit
modelul E-A.
Prin modelul entitate-asociere înţelegem toate entităţile şi relaţiile între ele pentru a
reda realitatea datelor în procesul studiat. Fie de exemplu entitatea COMANDĂ şi entitatea
CONT. Acestea au mai multe atribute fiecare, astfel:

Comanda Cont
Număr comandă Simbol
Dată Denumire
Denumirea RD
Unitatea de măsură RC
Cantitate Sold

Atributul reprezintă o caracteristică a entităţii care prezintă interes din punct de vedere
al proiectului. Reprezintă un anumit fel de informaţie despre entitate.

58
Clasificarea atributelor

după complexitate: - simple – nu se pot descompune în alte atribute (nr. matricol, preţ)
- complexe – se pot descompune la rândul lor în alte atribute.
ex: DATA 25 / 10 / 2004 – ziua, luna, anul.
PERIOADA: – luni, trimestre, ani
după felul realizărilor:
• obligatorii - trebuie să aibă cel puţin o realizare (simbol cont, denumire cont). Sunt
echivalente cu expresia NOT NULL.
• opţionale – pot să nu prezinte nici o valoare (număr telefon, e-mail, RD, RC).
• monovaloare – sunt atribute care au o singură valoare (exemplu, simbol cont, număr
matricol).
Iată de exemplu o înregistrare concretă pentru entitatea COMANDĂ:
1110 25 / 10 / 2004 costum bărbaţi buc 200 → aceasta este o realizare
Obiectele modelului entitate atribut pot fi de două feluri:
- simple: cărora le corespunde o entitate (cantitate → obiect simplu)
- compuse: descompune în obiecte simple

Carte Carte Autor

Cotă Cotă Nume

Naţionalitate
Titlu Titlu

Editură Editură

An apariţie An

Autor (mai mulţi)

Naţionalitate este un atribut sau grup de atribute care identifică în mod unic o
Identificatorul
înregistrare (realizare)
autor a entităţii → cheia înregistrării.
Relaţiile sau asocierea – reprezintă legăturile care se stabilesc între entităţi.

Avion Cursă de avion

Cod identificare Număr cursă

Data ultimei reparaţii Ora plecării
Kilometri parcurşi Ora sosirii
ID, PERS, REPAR Destinaţie

face este
făcută

Realizează
data cursei

- avionul x face în data y cursa z.

- cursa z este făcută în data y de avionul x.

59
 Cardinalitatea este un cuplu de două numere (x,y), arată câte entităţi (x,y) participă la
realizarea unei legături. Cardinalitatea minimă arată numărul minim de entităţi care participă
la realizarea unei legături. Cardinalitatea maximă arată numărul maxim de entităţi care
participă la realizarea unei legături.

Tipuri de entităţi după participarea la realizarea legăturilor

1. unare (unu la unu) (soţ, soţie) (şef birou, birou)

2. binare (unu la mai multe)

Familie Copii
Cod familie Cod familie
Nume Nume
Adresă Vârstă

3. ternale (mai multe la mai multe) (furnizori, marfă, magazine), mai muţi furnizori
livrează mărfuri la mai multe magazine.

Atributele după valorile pe care le conţin pot fi de mai multe feluri:

• numerice
• caracter
• data
• logic
• etc.

60
 Entităţile au o importanţă deosebită în realizarea proiectelor informatice. Entităţile se
descriu cu următoarele elemente: nume entitate, nume atribut, tip atribut, lungume, domeniu de
valori şi opţional număr de zecimale. Iată un exemplu pentru o astfel de descriere:

NUME ENTITATE: MATERIALE

Nr crt Nume atribut Tip Lungime Domeniu de valori

1 Cod material Numeric 14 NOT NULL
2 Denumire material Caracter 20 NOT NULL
3 Unitate de măsură Caracter 3 BUC / T, KG
4 Cantitate Numeric 10
5 Gestiune Numeric 4 110

Restricţii impuse atributelor:

Pentru a asigura o acurateţe ridicată a datelor, asupra valorilor pe care le iau atributele
se pun anumite restricţii. Operaţia prin care se verifică această restricţie se numeşte validarea
datelor.
Restricţii - 1) de integritate
- 2) domeniu
1) condiţiile pe care trebuie să le îndeplinească datele pentru a fi corecte şi coerente faţă
de realitate.
- verificări logice -
Ex: data curentă a unei înregistrări trebuie să fie mai mare sau egală cu data zilei .
DATA ÎNREG >= DATA ZILEI
- cota de TVA {0, 9, 19}
- statice – se referă la valori care nu se modifică
ex: kilograme.
- dinamice – valorile se pot modifica în timp
ex: procentul de TVA
2) Ne asigură că atributele aparţin unui domeniu permis. Se pot prezenta în mai multe
feluri.
a) lista de valori (*) mulţime → cota de TVA {0, 9, 19} * {bucăţi, tone, kilograme}
b) valorile să respecte anumite corelaţii
GESTIUNE = 1 atunci COD MATERIAL > 1000 şi COD MATERIAL < 5000
c) sub formă de corelaţii
ex: cantitate comandată <= stoc
data fabricaţiei > data omologării
d) valori care rezultă din calcule:
valoarea medie a preţului <= 100.000

61
Dependenţa funcţională
Dacă există două atribute, unul determinant şi unul determinat, dacă cunosc valoarea
determinantului sigur îl cunoaştem pe determinat.

DETERMINANT DETERMINAT

ex.: cod poştal (localitate) → denumire (localitate)

CNP → nume persoană

Matricea dependenţelor funcţionale

Folosind noţiunea dependenţelor funcţionale, se poate întocmi o matrice care arată care
sunt atributele între care există legături ale valorilor de date. Această matrice conţine pe coloană
atributele determinante iar pe linie mulţimea tuturor atributelor din proiect sau din modelare.
Atribute determinante
Nr. Atribute 1 2 6 9
crt.
1. Cod postal 1
2. Denumire localitate 1 1
3. Număr locuitori
4. Denumire stradă
5. Judeţul 1
1 – înseamnă relaţia de determinare şi dacă el pe el se determină, se subliniază
6. Cod material 1
7. Unitate de măsură 1
8. Denumire material 1
9. Cod produs 1
10. Cod reper 1
11. Denumire produs 1
12. Denumire reper 1
Rolul matricei dependenţelor funcţionale este de a pune în evidenţă legături
determinante între atributele modelului pe care îl proiectăm. Acest lucru ne ajută la definirea
legăturilor dintre date şi la simplificarea lor. Reprezintă un document de sinteză al proiectului
informatic.

Reguli de verificare a Modelului Conceptual al Datelor (MCD)

1. unicitatea numelui = un nume (de entitate, tabel, fişier, atribut) trebuie să fie peste tot
acelaşi şi să se refere la acelaşi lucru. Trebuie eliminate omonimele sau sinonimele.
2. unicitatea atributelor = numele de atribute trebuie să fie unice şi dacă se poate
neconfundabile cu altele apropiate
3. atributele care sunt identificatori nu pot lua valoarea NULL, adică necompletată

62
Reguli pentru normalizarea MCD
Normalizarea MCD- relizarea unui model fiabil, corect. Fiecare entitate trebuie să
prezinte un identificator cu valori unice (cheia primară). Când vorbim de asocieri sau legături,
atributele unei legături trebuie să depindă de identificatorul legăturii respective.

Exemplu:

CURS SĂLI

Denumire OCUPĂ Număr săli

curs Număr locuri
Dată început Dată, nr.
zile
Dată sfârşit
Atributele DATA şi NR. ZILE din relaţia OCUPĂ trebuie să fie unice pentru cursul X
şi sala Y. Număr cursanţi

Tipuri de legături între entităţi

După numărul de entităţi la care se referă o legătură, acestea pot fi de trei feluri:
- unare- legătură de tip unu_la_unu
Exemplu: soţ  soţie
şef birou  birou

- binare- legătură de tip unu_la_mai_multe

Exemplu: familie  copii
companie angajaţi

- ternare- legătură de tip multe_la_mai_multe

Exemplu: furnizori  mărfuri
În proiecte se întocmeşte o fişă a entităţii, care cuprinde următoarele elemente:

NUME ENTITATE(care fizic înseamnă TABELĂ, FIŞIER)= NOMENCLATOR

Nume atribut Tip atribut Lungime Domeniu Index

Cod material Numeric 14 Not null Da, unic

Denumire material Caracter 30 Not null

Unitate de măsură Caracter 3 Kg, tona, buc

Cantitate Numeric 10

Data creerii data 10 >= 24 / 10

/2004

Coloana INDEX se referă la atributele de tip identificator şi se specifică dacă are chei
unice sau multiple.

63
 Crearea acestei tabele în Sistemul de Gestiune a Bazei de Date:
CREATE TABLE NOMENCLATOR
(COD_MAT NUMBER (14) NOT NULL,
DEN_MAT CHAR (30) NOT NULL,
UM CHAR (3), CANTITATE NUMBER (10),
DATA_CREERII DATE (10), PRIMARY KEY (COD_MAT));

Modelarea prelucrărilor
Prelucrările descriu acţiuni şi operaţii exercitate asupra datelor. Ele reprezintă
formalizarea sub formă de acţiuni a regulilor şi legăturilor după care se gestionează un proces,
un sistem, o firmă.
Exemplu: Fie următoarea regulă: salar brut cuvenit pentru timpul lucrat= tarif orar, număr
efectiv prestate.

În calculator această regulă duce la următoarele prelucrări şi acţiuni:

1. Citeşte SALARUL DE ÎNCADRARE (din nomenclatorul de personal).

2. SALAR_ORAR= SALAR_ÎNCADRARE/ORE_MEDII (160 de ore pe lună)
3. Citeşte NR_ORE_EFECTIV
4. SALAR_BRUT= SALAR_ORAR x NR_ORE_EFECTIV
Pentru a defini prelucrările trebuie răspuns la următoarele cinci întrebări:
1. Ce reguli sunt? } Model conceptual al prel.
2. Cine face prelucrările? Model logic al
3. Unde se efectuează prelucrările?
prelucrării
4. Când se efectuează prelucrările? (zilnic, săptămânal, lunar)
5. Cum se efectuează prelucrările? } Modelul fizic al prelucrării

Modelul conceptual şi logic al prelucrărilor

Procesul- reprezintă ansamblul de activităţi în care punctele de intrare şi ieşire
sunt stabile.
Exemplu: la gestiunea comenzilor- gestiunea facturilor

PRIMIRE DISPOZIŢII DE LIVRARE

comandă sau comandă ACCEPTATĂ

GESTIUNEA ÎNTOCMIRE
COMANDĂ FACTURI

Comandă ACCEPTATĂ FACTURI

REFUZATĂ

Operaţia=prelucrarea un bloc de prelucrare care cuprinde prelucrări elementare, generatoare

de evenimente. Toate operaţiile aritmetice, operaţiile de atribuire, operaţiile de comparare,
operaţiile de calcul de orice fel sunt admise sub noţiunea de operaţie.
Regula de emisie este o propoziţie logică, care dacă este adevărată va determina
producerea unui eveniment.

64
 Analiza comenzii

Compararea cantităţii comandate cu stocul

Regulă Stoc ≤ Cantitatea Stoc ≥ Cantitatea Regulă

de livrare comandată comandată de livrare

Dispoziţie Dispoziţie
Eveniment de de livrare
provocat fabricaţie

Evenimentul este un semnal sau un stimul adus la cunoştinţa sistemului informaţional la care
acesta trebuie să reacţioneze. Pentru a fi considerat un evenimet semnalul trebuie să
îndeplinească trei condiţii:
1. Să producă o informaţie sau un stimul asupra sistemului.
2. Sistemul să perceapă acest stimul.
3. Sistemul să reacţioneze la semnal prin desfăşurarea unor operaţii.

Operaţiile şi evenimentele trebuie văzute în succesiunea lor în sensul că operaţiile pot

determina evenimente şi invers.Aceasta se numeşte caracterul ciclic OPERAŢII –
EVENIMENTE.

Clasificarea evenimentelor:

- evenimete externe procesului- generează operaţii în afara procesului;

- evenimente interne procesului- cele care generează operaţii în cadrul sistemului;
- evenimente de rezultat- ieşiri din prelucrare sub formă de documente;

Reprezentarea grafică a modelării prelucrărilor MP

Pentru modelarea prelucrărilor se parcurg următorii paşi:

- delimitarea domeniului de modelat;

- definirea fluxurilor informaţionale şi reprezentarea lor;
- identificarea evenimentelor;
- identificarea acţiunilor care rezultă din evenimete;
- definirea prelucrărilor;
- înlănţuirea prelucrărilor;
- validarea modelului conceptual al prelucrărilor;

65
Modelarea prelucrărilor pentru procesul de VÂNZARE- FACTURARE
- delimitarea prelucrării

COMANDĂ Iese din ciclu

NC + Factură →
Contabilitate
Dispoziţie
fabricaţie
Elaborar
Proces e
vânzare factură
facturare
Dispoziţie Factură de încasat
livrare

Definirea fluxurilor:

F1 F2 F4

F5
F3

Identificarea evenimentelor

Elaborarea dispoziţiilor de fabricaţie

Notă
E4 contabilă
E1 E2 E3

Ulterior poate Dispoziţie Elaborare

E5 Urmărire încasări
duce la dispoziţie livrare factură
de livrare

66
Identificarea acţiunilor: întocmirea tabloului evenimente-acţiuni:

Nr. Eveniment Acţiune Rezultat

crt.

E1 Dispoziţie de Se fabică produsul Se livrează produsul

fabricaţie

E2 Dispoziţie livrare Livrare marfă Se întocmeşte DL

E3 Întocmire factură Calculare, întocmire factură Factura expediată cu

marfa

E4 Întocmire notă Factura trimisă la Înregistrare în

contabilă contabilitate şi NC contabilitate

E5 Urmărire încasare Factura trimisă la financiar, Factură încasată

factură verificare disp, încasare, OP

Definirea şi înlănţuirea prelucrărilor:

START 1

Analiza comenzii

NU Cerinţă DA
îndeplinită

Întocmire
NU 2
Se mai dispoziţie plată
DA
poate
fabrica

Întocmire factură
Refuz Întocmire disp. 4
3
comanda fabricaţiei

STOP

67
 Validarea modelului – reguli de realizare:

- orice operaţie de prelucrare trebuie să fie declanşată de cel puţin un eveniment.

- orice prelucrare trebuie să genereze cel puţin un eveniment.
- orice operaţie generează un eveniment.
- prelucrările sunt înlănţuite logic

Studiu de caz
Se cere să se modeleze procesele, datele, prelucrările pentru următoarea situaţie:
O societate de turism doreşte să realizeze un produs informatic pentru gestiunea
hotelieră. Să se elaboreze:
- schema de context şi descompunerea ei
- structura datelor
- schema bloc a prelucrărilor, ştiind că:
- se doreşte evidenţa spaţiului de cazare (camere de trei tipuri: simplă, dublă, apartament).
- tariful diferă de la o cameră la alta chiar dacă sunt de aceleaşi tip.
- se vrea evidenţa serviciilor suplimentare din unele camere (TV, fax, frigider), acestea se vor
factura în poziţii separate sau la cerere în facturi separate.
- nota de plată se întocmeşte în funcţie de cameră, număr de zile, servicii suplimentare.
- rezervările se fac pe cameră şi nu pe locuri.

Diagrama de context
CLIENŢI

CAMERE solicitare camere Încasări, facturi

Evidenţă FINANCIAR -
hotelieră CONTABIL
(Recepţia)
alocare camere

rapoarte, statistici

CONDUCERE

Descompunerea diagramei de context

1 Diagrama de nivelul „0” unde se

evidenţiază subsistemele:
3
1. Recepţia
4
2
2. Camere

3. Financiar contabil
68 4. Conducerea
Modelarea datelor

69
 CLIENT
CNP
Se poate face o
NUME codificare separată
RECLAMAŢII
pentru facilităţi:
PRENUME
CNP CLIENT
ADRESĂ T – televizor
DATA
ZIUA DE ÎNCEPUT I – internet
RECLAMAŢIE.......
ZIUA DE SFÂRŞIT F – frigider
FACILITĂŢI
FACILITĂŢI: X – fax

A – aer condiţioant
RECEPŢIONER CAMERE FACILITĂŢI PREŢ FACILITĂŢI

COD_RECEP NUMĂR CAMERĂ NUMĂR CAMERĂ TELEVIZOR

DATA TIP CAMERĂ TELEVIZOR INTERNET
SCHIMBUL TARIF / ZI INERNET AER CONDIŢIONAT
NUME, PRENUME DISPONIBILITATE FAX FRIGIDER
DE LA DATA: FRIGIDER FAX
PÂNĂ LA DATA AER CONDIŢIONAT

Descrierea entităţilor – model fizic

Entitate: CLIENT

Nr. crt. Atribut Tip Lungime octet Domeniu Index

1 CNP N 13 NOT NULL DA, UNIC

2 NUME_PRENUME A 50 NOT NULL

3 ADRESĂ AN 50 NOT NULL

4 ACT IDENTITATE AN 14 DA, UNIC

5 NR. CAMERE CERUTE AN 12 nnnS,nnnD, nnnA

6 DATA ÎNCEPUT D 8 zz / ll / aa

7 DATA SFÂRŞIT D 8 zz / ll / aa

8 NUMĂR PERSOANE N 4

9 FACILITĂŢI entitate facilităţi

70
 S – single, D – double, A – apartament

Entitate facilităţi

Nr. crt. Atribut Tip Lungime Domeniu Index

1 Număr cameră N 3 001 – 800 Da, Unic

2 TV AN 1 *

3 Internet AN 1

4 Aer condiţionat AN 1

5 Frigider AN 1

6 fax AN 1

* are semnificaţia că facilitatea este disponibilă.

Modelarea prelucrărilor:

evenimente: E1 = primire comandă

E2 E4 E6

E3
E5

E1 – primire comandă
E2 – comandă acceptată
E3 – comandă refuzată
E4 – sfârşit perioadă sejur
E5 – reclamaţii (pot apărea în timpul sau la sfârşitul sejurului)
E6 – întocmire rapoarte financiar şi contabil

Diagrama acţiunilor:

Analiza comandă

Marcare camere

Verificare facilităţi

Elaborare factură

Tratare reclamaţii
71
Elaborare rapoarte
 Tabela evenimente – acţiuni:

Nr. crt. Eveniment Acţiune Rezultat

1 E1 – primire comandă Analiza comandă: Comandă analizată cu cele
-se verifică dacă există camere două variante de rezultat
-se verifică dacă există facilităţi (acceptat / neacceptat)
2 E2 – comandă acceptată Reţinere cameră Servirea clientului
-marcare facilităţi acordate
3 E3 – comandă refuzată Client refuzat
4 E4 – sfârşit perioadă -verificare facilităţi Realizat venit
sejur - elaborare factură
- încasare numerar / eliberare
chitanţă
-încasare virament
-verificare încasare virament
-eliberare camere
-eliberare facilităţi
5 E5 – reclamaţii Clientul reclamă: Date pentru conducere
-facilităţi
-servicii
-curăţenie
6 E6 – elaborare rapoarte 1)Elaborare raport financiar- Rapoarte financiar-contabile
contabil
-întocmit registru casă
2) Elaborare rapoarte statistice
-încasări pe zile
-reclamaţii
-gradul de ocupare a camerelor
-statistică de clienţi

72
Întrebări de verificare

Elaborați un studiu de caz pentru implementarea unui sistem informatic într-o firmă.
Elaborați:
- schema de context şi descompunerea ei;
- structura datelor;
- schema bloc a prelucrărilor.

73
MODULUL IV

SISTEME INFORMATICE INTEGRATE

Obiectivele modulului

Obiectivele prezentului modul sunt prezentarea sistemelor informatice integrate

pentru domeniul economic, cu accent pe sistemele ERP și CRM.

Structura modulului

Subiectul abordat Pagina

Tema 1. Sisteme informatice integrate pentru 74
domeniul economic - Sisteme informatice ERP,
CRM
Tema 2. Tendințe în dezvoltarea produselor 80
informatice pentru economie
Întrebări de verificare 83

TEMA 1
Sisteme informatice integrate pentru domeniul economic
- Sisteme informatice ERP, CRM

Timp mediu necesar pentru asimilarea acestei Teme: 2 oră

Competenţe

În urma parcurgerii temei, cursanți vor putea:

• Să se familiarizeze cu terminologia specifică.
• Să acumuleze cunoștințe legate de evoluția sistemelor ERP.
• Să-și formeze o imagine asupra perspectivelor sistemelor ERP și
CRM.

Evoluţia şi utilizarea sistemelor ERP; aspecte teoretice

În zilele noastre pare evident că o trebuie să dispună de software integrat pentru a

gestiona toate arealele sale funcţionale. Un sistem integrat ERP este un complex de hardware
şi software care nu era realizabil înainte de 1990. Sistemele ERP curente au evoluat ca rezultat
al dezvoltării tehnologiilor hardware şi software necesare pentru a sprijini sistemul, şi, de
asemenea, ca urmare a dezvoltării unei noi viziuni asupra sistemelor informaţionale integrate.
Sistemele ERP integrează arealele funcţionale ale afacerii. Înainte de apariţia sistemelor
ERP, fiecare areal funcţional opera independent, folosind propriul sistem informaţional şi
propriile metode de înregistrare a tranzacţiilor. Softurile ERP îmbunătăţesc raportarea către

74
management şi adoptarea de decizii în cadrul organizaţiei. În completare, ERP promovează
gândirea la scopurile corporaţiei, şi nu doar luarea în considerare a scopurilor departamentale.
Punctul de plecare pentru ERP poate fi considerat sistemele de contabilitate timpurii
care manevrau procesarea comenzilor, funcţiile de bază ale achiziţiei şi inventarul, şi, de
asemenea, logica de procesare a facturilor de materiale. Pachetele software ERP au evoluat de-
a lungul timpului, suportând o varietate de medii de producţie şi practici de afaceri. De
asemenea, ele au evoluat şi în ceea ce priveşte uşurinţa în folosire şi în implementare. Un pachet
soft ERP creşte în timp prin adăugarea de noi module şi funcţii de către furnizor.
În cele ce urmează, vom prezenta pe scurt evoluţia în timp a sistemelor integrate,
precum şi principalele etape în dezvoltarea acestora.
Din punct de vedere istoric, noţiunea de ERP a apărut la începutul anilor 1990 şi a fost
utilizată pentru a califica generatoarele de software care acopereau gestiunea completă a unei
întreprinderi: SAP, ORACLE Applications, BAAN, SSA, JD EDWARDS. Pe baza experienţei
în sisteme de gestiune pentru întreprinderi, aceşti producători s-au angajat să transforme
aplicaţiile lor în sisteme integrate de gestiune a întreprinderii.
Fenomenul de industrializare a determinat producţia în serii mari de softuri perfect
identice, cu dezvoltare masivă, contrar altor tipuri de aplicaţii. Primele pachete de sisteme
integrate conţineau module pentru: contabilitate, plăţi, gestiunea imobilizărilor. Producătorii
anterior menţionaţi au creat o serie cuprinzătoare de sisteme de gestiune integrate, astfel încât,
la sfârşitul anilor 1990 deţineau o poziţie de invidiat pe piaţa ERP.
Însă, pentru a înţelege evoluţia în timp a sistemelor integrate de tip ERP, este necesară
o scurtă incursiune în dezvoltarea tehnologiilor informaţionale care au stat la baza apariţiei şi
progresului sistemelor integrate.
Astfel, se consideră că sfârşitul celui de-al doilea război mondial, reprezintă momentul
de debut al tehnologiilor informaţionale. Primele computere utilizate în practicile de afaceri au
fost computerele mainframe în anii 1960. Aceste computere erau depozitate în propriile lor
camere cu climat controlat în scopuri operaţionale şi de securitate. Programele erau introduse
utilizând cartele perforate sau benzi magnetice, putând dura ore până când informaţiile să fie
procesate de către computer.
Computerele mainframe erau adecvate doar pentru sarcini secvenţiale, repetitive,
precum contabilitate, gestiunea inventarului şi plăţi. Nu se poate vorbi despre sisteme integrate
pentru adoptarea deciziilor în afaceri, din cauza limitelor tehnologiei, chiar dacă valoarea
integrării era înţeleasă. Companiile achiziţionau computere mainframe pentru a efectua sarcini
izolate, repetitive pentru care anterior era necesitat un număr mare de funcţionari.
Între anii 1960-1970 computerele devin mai mici, mai ieftine şi mai rapide.
Tehnologiile de depozitare şi recuperare s-au îmbunătăţit putând permite accesul direct sau
secvenţial la date. Toate programele care accesau date au devenit imediat mai rapide ca urmare
a acestei schimbări.
Bazele de date relaţionale au fost introduse în anii 1970 şi au beneficiat de schimbările
în tehnologiile de depozitare. Bazele de date relaţionale erau mai eficiente pentru obţinerea de
răspunsuri la interogări complexe, decât cele ierarhice, însă necesitau computere mai rapide şi
accesul la disk.
Hardware-ul pentru computere a devenit chiar şi mai mic în anii 1980. Microprocesorul
a devenit prezent în anii 1970, dar s-a maturizat într-un instrument serios de afaceri când IBM
a introdus primul calculator personal în 1981. Capacităţile crescânde şi costurile în scădere ale
calculatoarelor personale le-au ajutat să devină instrumente standard pentru afaceri.
Au apărut astfel primele încercări de partajare a datelor. Calculatoarele personale au
câştigat popularitate în afaceri, managerii devenind conştienţi că informaţii importante erau
depozitate pe acestea, dar neexistând nici o manieră uşoară de a le partaja electronic.

75
 Era uşor de configurat ca un calculator să funcţioneze ca un „terminal mut” pentru un
computer mainframe, dar ceea ce era necesar era un mod de a partaja echipamentele periferice
scumpe (imprimante şi hard-disk, care la începutul anilor 1980 erau foarte scumpe) şi, cel mai
important, datele.
Progresul telecomunicaţiilor a permis ca datele şi perifericele să fie partajate prin reţele
locale. Aceasta însemna că datele puteau să fie descărcate de la un calculator central (deseori
numit „server”) pe calculatoare locale (numite „clienţi” ai serverului). Arhitectura client-server
a luat locul arhitecturii bazată pe mainframe. Serverele au devenit mai puternice, mai ieftine,
furnizând scalabilitate.
Până la sfârşitul anilor 1980, mare parte din hardware-ul necesitat pentru a sprijini
dezvoltarea sistemelor ERP exista deja: calculatoare rapide, acces în reţea şi tehnologia bazelor
de date avansate. Adiţional, existau şi bazele de date şi instrumentele software necesitate pentru
managementul dezvoltării softurilor ERP. Ceea ce trebuia, era posibilitatea de a vedea
beneficiile sistemelor integrate şi bunăvoinţa de a pune la dispoziţie resursele pentru crearea
de soft ERP.

Principalele etape în dezvoltarea sistemelor integrate

Reorganizările companiilor spre sfârşitul anilor 1980, începutul anilor 1990, cauzate de
dificultăţile economice au reprezentat un stimul în dezvoltarea ERP.
Predecesoarele sistemelor integrate de tip ERP caracteristice anilor 1990, sunt sistemele
MRP1 (Materials Requirements Planning) din anii 1960 şi MRP2 (Manufacturing Resource
Planning) din anii 1970. Astfel, sistemele ERP sunt considerate o extindere a acestora din urmă
şi fac parte din sistemele moderne informaţionale pentru eficientizarea proceselor din cadrul
organizaţiilor.
Viziunea de a deţine un sistem informaţional integrat a apărut la nivel de fabrică.
Softurile de producţie s-au dezvoltat de-a lungul anilor 1960 şi 1970, evoluând de la sisteme
simple de inventar până la softuri de planificare a materialelor MRP (Materials Requirements
Planning), concretizându-se astfel prima etapă majoră în dezvoltarea sistemelor integrate.
A doua etapă importantă a reprezentat-o apariţia MRP II. Conceptul de bază al
sistemelor ERP era inerent în dezvoltarea MRP II – Manufacturing Resource Planning
(Planificarea Mijloacelor de Producţie). Termenul MRP II a fost elaborat de către Oliver Wight,
o figură cheie în dezvoltarea sistemelor MRP în timpul anilor 1980. Astfel, este posibil ca
sistemele ERP să fie văzute ca o extensie a sistemelor MRP II.
Potrivit literaturii de specialitate, termenul de Enterprise Resources Planning aparţine
Gartner Group. Sistemele ERP au intrat în uzul comun abia pe la jumătatea anilor 1990. Pe
măsură ce această tehnologie tânără continuă să se maturizeze, furnizorii de ERP lucrează din
greu să rezolve problemele care creează dificultăţi pentru clienţi.
Până în 1998 marea majoritate a companiilor mari şi foarte mari şi-au instalat deja
sisteme ERP, astfel încât furnizorii acestora şi-au redirecţionat eforturile de marketing către
companii mijlocii(cu mai puţin de 1000 de angajaţi). Acestea alcătuiau o piaţă matură şi
profitabilă. Schematic, evoluţia sistemelor ERP se prezintă în figura următoare.

76
 Evoluţia sistemelor ERP

Precum indică şi schema anterioară, anii 2000 sunt caracterizaţi, din punctul de vedere al
aplicaţiilor integrate, de o extindere a sistemelor ERP, denumite ERP II sau Extended ERP. În fapt,
aceste aplicaţii au ca nucleu sistemele ERP la care se adaugă alte module integrate, precum sunt:
SCM – Supply Chain Management, CRM – Customer Relationship Management, BI- Business
Intelligence, ş.a. .
Argumentând în favoarea punctului de vedere anterior menţionat, se poate considera
evoluţia sistemelor ERP ca fiind una continuă, în plină desfăşurare. Se cunoaşte, cu aproximaţie,
momentul apariţiei termenului ERP şi a sistemelor ca atare, iniţial direcţionate către companiile
mari, care dădeau semne de necesitatea unui astfel de sistem. În zilele noastre, producătorii acestui
tip de software tind să-şi diversifice utilizatorii ţintă, adresându-se şi întreprinderilor de talie
mijlocie.

ERP – fundament al actului decizional

Indiferent de mărimea sau natura lor, întreprinderile, prin managementul lor, au ajuns
la concluzia că un sistem integrat de tip ERP reprezintă un avantaj concurenţial, asigurându-le
desfăşurarea activităţii la un nivel de eficienţă maximă. În lupta pentru supravieţuirea pe piaţa

77
dinamică sunt necesare sisteme informatice strategice şi globale, sistemele integrate definind
cu succes această categorie.
Sistemul ERP se referă la infrastructura software care asigură coeziunea internă a
companiei şi, totodată, acesta susţine procesele externe de afaceri în care este implicată
compania. Iată, câteva dintre caracteristicile acestor sisteme:
- aplicaţiile ERP sunt destinate proceselor de afaceri;
- aplicaţiile ERP sunt modulare;
- aplicaţiile ERP sunt integrate;
- acestea permit extinderea companiei dincolo de limitele sale fizice: spre furnizori,
clienţi şi parteneri;
- pachetul ERP complet va fi destinat tuturor (sau majorităţii) elementelor din funcţiile
de business ale companiei.
Avantajul unei aplicaţii ERP îl constituie faptul că e un pachet de aplicaţii care
funcţionează împreună, iar fără această funcţionalitate, nu se poate beneficia de procese
eficiente de afaceri.

Arhitectura sistemelor ERP în contextul actual

Caracterul modular este important atunci când se doreşte achiziţionarea şi

implementarea unui ERP. Uneori nu sunt necesare toate aplicaţiile în acelaşi timp sau se poate
dori implementarea unei singure aplicaţii la un moment dat. Aceste aplicaţii se deosebesc de
aplicaţiile separate, în sensul că, dacă se implementează cel puţin două, acestea se potrivesc ca
piesele de Lego şi funcţionează automat.
Un sistem integrat este o structură modulară, care are un nucleu ( SETUP), în care se
definesc setările proprii companiei şi un număr variabil de module în funcţie de cerinţele de
implementare.
S-a demonstrat în timp că utilizatorii de aplicaţii neintegrate petrec foarte mult timp
repetând la nesfârşit aceeaşi sarcină, şi anume introducerea aceloraşi date în programe diferite.
În acest caz, pot fi identificate câteva probleme:
• Introducerea repetată a aceloraşi date înseamnă pierdere de timp.
• Este foarte posibil ca acestea să fie introduse incorect.
• Pot să arate diferit în funcţie de program (de exemplu aceeaşi companie cu doua
denumiri).
• Datele care rezultă din aplicaţiile individuale neconectare sunt inconsecvente, iar
încercările de a le analiza nu duc decât la un haos decizional sau la o risipă de resurse
pentru validarea rezultatelor.
• Cu ajutorul unei suite ERP integrate, nu există decât „un singur adevăr” care trebuie
preluat o singură dată, pentru a fi propagat în toate sectoarele necesare ale afacerii.
Procesele de afaceri, angajaţii care utilizează aplicaţia şi directorii care iau decizii
pentru companie au parte de aceeaşi versiune a realităţii, în timp real, în orice moment.

Pentru că afacerea înseamnă mai mult decât operaţii interne: pentru a avea succes,
trebuie să fie administrată eficient modalitatea de achiziţionare a bunurilor, serviciilor şi
materiilor prime; să fie supravegheată şi controlată relaţia cu furnizorii şi cu partenerii de
afaceri; şi să fie creată, administrată şi păstrată baza de clienţi. Toate aceste relaţii pot fi
administrate mai eficient şi mai eficace cu ajutorul aplicaţiilor ERP.

78
 Avantaje nete ale utilizării ERP în administrarea afacerilor:
• Scalabilitate - soluţiile ERP sunt destinate dezvoltării
în paralel cu compania . Spre deosebire de aplicaţiile
de sine stătătoare, acestea oferă şi căi de trecere către
alte soluţii, permiţând să pornim de la zero cu o nouă
aplicaţie.
• Administrarea furnizorilor - Nu e uşor să
administrezi o mulţime de furnizori, fiecare cu mai
multe numere gratuite de servicii pentru clienţi. ERP
oferă un furnizor de soluţii cu care se uşurează acest
efort.
• Funcţionalitate - La prima vedere, s-ar putea să nu
pară cea mai rentabilă alegere, dar se va dovedi cea mai
economică soluţie pe termen lung, pe măsură ce se
dezvoltă şi modifică afacerea.
• Service şi asistenţă de încredere - Posibilitatea de
acces la service şi asistenţă este un lucru esenţial. Este
mai uşor să întreţii un mediu ERP integrat decât un
amalgam de aplicaţii diferite.

Firmele mici care au adoptat sistemul ERP la jumătatea anilor '90 nu au fost copleşite
de structurile de cost sau de riscurile pe care au trebuit să şi le asume companiile mai mari. În
prezent, aceste firme utilizează aplicaţii depăşite şi supraîncărcate şi trebuie să investească într-
o tehnologie nouă, pentru a obţine sau a-şi păstra competitivitatea pe piaţă, să implementeze
aplicaţiile software
într-un timp scurt şi să obţină amortizarea rapidă a investiţiilor în aplicaţii.
Astăzi, întreprinderile mici şi mijlocii sunt orientate în principal pe costuri, considerate
ca fiind cea mai mare provocare, şi afirmă că cel mai mare impediment în aplicarea strategiilor
îl reprezintă alocarea insuficientă a fondurilor. Sunt preocupate, de asemenea şi de creşterea
numărului de clienţi şi de reţinerea acestora – de obţinerea şi menţinerea unei baze de clienţi
fideli. Mai mult, aceste companii au în vedere potenţialul de răspândire al produselor şi
serviciilor proprii.
Dintre problemele firmelor care pot fi rezolvate cu ajutorul soluţiilor ERP, menţionăm:
• Alocarea insuficientă de fonduri pentru strategiile şi iniţiativele companiei.
• Lipsa de viziune şi obiective clar definite.
• Comunicarea ineficienta a strategiilor şi a iniţiativelor companiei.
• Indicatori care nu stimulează suficient angajaţii în susţinerea/realizarea obiectivelor.
• Incapacitatea de a stabili şi de a planifica cu exactitate cererea clientului.
Pe lângă alocarea de fonduri, soluţiile de definire a obiectivelor şi de comunicare a
acestora în cadrul organizaţiei permit îmbunătăţirea administrării relaţiilor cu angajaţii (ERM),
beneficiind şi de alte soluţii tehnologice, cum ar fi portalurile şi soluţiile
self-service pentru angajaţi.
Mai mult, soluţiile de stimulare bazate pe obiective pot fi implementate prin
administrarea susţinută a angajaţilor (EIM), prin „achiziţia” angajaţilor talentaţi prin recrutare
electronică şi prin gestionarea cererii cu ajutorul soluţiilor de prognozare IT. Piaţa de mijloc a
evoluat mai lent decât întreprinderile mari în ceea ce priveşte adoptarea unor astfel de soluţii;
şi totuşi, îşi manifestă nevoia de implementare a acestora, în toate segmentele de aplicare a
sistemului ERP.

79
 TEMA 2
Tendințe în dezvoltarea sistemelor informatice pentru
economie
Timp mediu necesar pentru asimilarea acestei Teme: 1 oră

Competenţe

În urma parcurgerii temei, cursanți vor putea:

• Să se familiarizeze cu terminologia specifică.
• Să acumuleze cunoștințe legate de tendințele actuale în dezvoltarea
sistemelor informatice.

Deşi se vorbeşte la ora actuală de sisteme integrate destul de complexe, acestea nu sunt
considerate a fi finalizate. Cercetătorii în domeniu, precum şi producătorii acestui tip de
software, nu pot vizualiza un punct de oprire a evoluţiei sistemelor integrate, deşi, după unele
păreri, această evoluţie ar putea lua sfârşit prin încorporarea sistemelor ERP în ERM –
Enterprise Resource Management. Astfel, acestea din urmă sunt văzute ca „viitor” al
sistemelor ERP, adăugând avantajul integrării perfecte dintre ERP şi BPI – Business Process
Integration.
Suitele de management de business, cunoscute sub numele de ERP (Enterprise
Resources Planning) au devenit un instrument indispensabil întreprinderilor mijlocii, fiind
utilizate pentru gestionarea finanţelor, automatizarea plăţilor şi creanţelor şi generarea
rapoartelor.
Astăzi, ERP încă se dezvoltă, adaptându-se dezvoltării cerinţelor pieţii.
Patru tendinţe principale modelează evoluţia ERP:
• dezvoltarea integrării şi a flexibilităţii;
• extinderea la aplicaţii e-business,
• o mai largă cooperare cu noi utilizatori,
• adoptarea tehnologiei Internetului.
Figura de mai jos ilustrează 4 mari tendinţe ce se dezvoltă în aplicaţiile ERP. Mai întâi,
pachetele software ERP implementate în 1990 şi criticate pentru inflexibilitatea lor, au fost cu
timpul modificate şi făcute mai flexibile. Companiile care au instalat sisteme ERP, i-au presat
pe ofertanţi să adopte arhitecturi software mai flexibile. Aceasta face software-ul mai uşor de
integrat cu alte aplicaţii pe care le folosesc companiile, şi mai uşor de adaptat la nevoile
companiei. Un exemplu este SAP R/3, lansat in 2002 de SAP AG ca succesor al versiunilor
SAP R3. Şi alţi lideri ofertanţi ai ERP, ca Oracle, PeopleSoft, şi J.D.Edwards, au dezvoltat de
asemenea produse ERP mai flexibile.

E-Business
ERP-ul intre Companii
ERP prin Web
ERP flexibil

Tendinţe în dezvoltarea aplicaţiilor ERP

80
 Software-ul ERP pentru Web este a doua dezvoltare în evoluţia ERP. Dezvoltarea
Internetului şi a Intra şi Extra-netului, au obligat companiile să folosească tehnologii de pe
Internet ca să creeze interfeţe Web şi reţele în sistemele ERP. Aceste caracteristici fac
sistemele ERP uşor de folosit şi de conectat la alte aplicaţii interne şi la sistemele companiilor
partener. Această conectare la Internet a condus la dezvoltarea relaţiilor ERP între companii
şi a legăturilor de afaceri Web ( ca inventar şi producţie) a unei companii cu clienţii,
ofertanţii, distribuitorii etc., săi. Aceste legături externe semnalează o mişcare înspre
integrarea interfeţelor ERP cu aplicaţiile externe de ofertă a lanţului managerial (OLM) şi a
partenerilor ofertanţi.
Toate aceste dezvoltări s-au dovedit a fi tehnologia de afaceri a momentului pentru
integrarea funcţiilor ERP în programele e-business. Companiile ce dezvoltă softuri ERP pentru
managementul relaţiilor cu clienţii, pentru lanţul de distribuţie, de ofertă, şi alte aplicaţii sunt
majoritare. De exemplu, Oracle e-business şi SAP’s my SAP. Unele programe e-business
descompun componentele ERP şi le integrează în alte module din software. Desigur, scopul
acestor programe este de a ajuta companiile să-şi deruleze procesul afacerilor folosind un
sistem prin Web şi prin baze de date, în locul unei varietăţi de programe business separate. Un
exemplu din viaţa reală îl reprezintă implementarea la Visa International a programelor E-
Business.
În ciuda inovaţiilor aduse comerţului global de către sistemele de plată, Visa
International avea sisteme surprinzător de demodate ce organizau unele dintre secţiunile interne
cele mai importante. „KPMG a făcut o analiză a afacerii noastre şi a descoperit că sistemele
noastre deveniseră un risc pentru organizaţia noastră” a spus Gretchen McCoy, senior vice
preşedinte al Visa International, „Eram cam la limită”.
McCoy şi-a dat seama că sistemele interne erau subdezvoltate şi nu aduceau avantaje
companiei. Infrastructura managementului financiar era fragmentată, complexă şi costisitor de
menţinut. Informaţiile nu erau standardizate, şi prea multe baze de date interpretau în mod
separat informaţiile afacerii. Achiziţionarea, plăţile contabilităţii şi managementul bunurilor se
făceau manual, rezultând astfel doar timp irosit şi discrepanţe. Sistemele interne fragmentate
nu sunt neobişnuite într-o companie ce experimentează o dezvoltare rapidă. Visa a crescut la o
cifra de afaceri cu două zerouri în ultimii 11 ani. Visa a ales Oracle E-Business pentru a remedia
problema unei bănci de date complexe şi ineficiente.
Implementarea programului a condus Visa la soluţii business bazate pe Web, în toate
rolurile şi procesele ei. De exemplu, programul Oracle Financiar a schimbat organizarea veche
a Visa şi a creat un sistem mai agil şi mai capabil de a face faţă activităţilor financiare ale
companiei la scară mondială. Plăţile contabilităţi s-au transformat dintr-un proces manual într-
un sistem bine legat şi fluent care verifica automat facturile şi plăţile exterioare şi cere
corectarea oricăror discrepanţe prin e-mail. Iar Oracle iProcurement a ajutat Visa să-şi modifice
sistemul de aprovizionare, fluidizându-l şi implementând un model automat pentru a-i creşte
eficienţa, a spus McCoy.
Într-o anumită măsură, viitorul sistemelor ERP este strâns legat de curentele actuale ale
informaticii şi tehnologiei, şi mai cu seamă ale sistemelor de computerizare şi de creare ale
bazelor de date.
Următoarea generaţie a sistemelor ERP va fi determinată poate într-o mai mare măsură,
de cererea de noi programe, de la utilizatorii deja existenţi ai sistemelor ERP care vor dori să
le extindă capacitatea de lucru.
Totuşi este important să observăm, că aceste doua forţe
– schimbările din tehnologia informaţiei şi cererea de noi programe – nu sunt întrutotul
compatibile. Coexistenţa lor creează o tensiune anume, pe care ofertanţii sistemelor ERP
trebuie să încerce să o diminueze; în caz contrar, dominaţia lor pe piaţă va fi subminată de
noutatea şi de agilitatea concurenţei.

81
 In ultimele 2 decade, principala forţă ce a modelat tehnologia informaţiei, a fost şi
continuă să fie, factorul ce conduce către descentralizare. Sistemele ERP s-au împotrivit modei
actuale, cel puţin temporar, prin implementarea sistemelor integrate în jurul unei baze de date
comune. În implementările actuale ale sistemelor ERP, serverul bazei de date şi cel al
aplicaţiilor sunt de cele mai multe ori grupate laolaltă într-o reţea comună, care este
administrată de o organizaţie IT centrală. Astfel, dacă 2 sau mai multe unităţi ale organizaţiei
adoptă un sistem ERP, ele ajung să implementeze bucăţele independente din sistem. Dacă
viitorul sistemelor informatice rezidă în sisteme descentralizate, atunci sistemele de sine
stătătoare ar putea fi date la o parte. Aceasta însemnă că vânzătorul (ofertantul) ar putea fi
nevoit să-şi descompună sistemul ce ar include un număr de aplicaţii compacte, în componente
ce pot fi distribuite uşor.
Mulţi ofertanţi ai ERP procedează aşa, dar ei trebuie să se confrunte cu menţinerea
echilibrului între dreptul propriilor aplicaţii şi deschiderea cerută de către client. Aceasta ar
însemna un dezastru pentru ofertanţii ERP, căci criteriul principal pentru a intra pe piaţa de
lucru ERP îl constituie chiar mărimea şi complexitatea sistemelor ERP. Moda sistemelor bazate
pe componente ar putea declanşa o avalanşă de sute de fabricanţi (producători) de componente
mici, individuale ca şi competitori din afara pieţii, cum ar fi giganţi ai software-ului, companii
ale serviciilor informatice şi firme de consultanţă.
Majoritatea sistemelor ERP vor interacţiona cu serviciul Web pentru a capta
informaţia tranzacţiei. Un curent important în computerizarea serverului-client îl constituie
dezvoltarea celui de-al „patrulea set”. În trecut, sistemele server-client erau descrise ca fiind
compuse din 3 părţi: baza de date, aplicaţie şi prezentare, şi numai de curând ca având n părţi
şi indicând posibilitatea unei structuri multiple. Dar un strat din această structură, în mod
special – al patrulea strat – este deosebit de important: serviciile Web. Această parte mediază
între prezentare şi aplicaţie şi este în mod obişnuit implementat ca un server Web, ca
ascultător(auditor) sau ca agent întrebări-răspuns.

Browser

Prezentare
Servicii Web

Aplicaţie Aplicaţie

Baza de date Baza de date

Al treilea server-client Al patrulea server-client
Arhitectura server-client

Pentru ofertanţii ERP semnificaţia acestui curent este de a reduce importanţa acelor
porţiuni ale sistemului ce operează la nivelul stratului prezentării. Interfeţele utilizatorilor au
fost rareori considerate un atu comercial al sistemelor ERP, şi astfel se înţelege că unii ofertanţi
vor înlocui părţi din prezentarea sistemului cu interfeţe generale bazate pe browsere. E posibil
ca unii ofertanţi ERP să ofere plug-uri speciale pentru a extinde capacitatea softului client.
A doua forţă majoră ce va determina viitorul ERP este cererea de aplicaţii. Această
cerere se structurează pe două dimensiuni: (1) verticală, ca îmbunătăţire a funcţionării

82
sistemelor ERP şi (2) orizontală, ca extindere majoră a sistemelor ERP în noi regiuni ale
companiei.
Îmbunătăţirile de tip vertical sunt cele ce se clădesc deasupra sistemelor ERP cu
integrarea activităţilor back-office şi supply-chain sau suportă implementarea şi menţinerea
acestor sisteme.
Informaţia, analiza produselor şi instrumentele de decizie sunt doar câteva dintre
zonele îmbunătăţite la majoritatea ofertanţilor sistemelor ERP, de-a lungul anilor.
Extinderile de tip orizontal suportă integrări în diferite regiuni ale companiei,
incluzând activităţile office ca şi cele ce se concentrează pe lanţul de cereri. Până de curând,
ofertanţii ERP nu au considerat acest tip de extindere ca fiind o prioritate. Sistemele de
procurare Intranet, cele de distribuţie Extranet, aplicaţiile comerciale Internet, sistemele de
îmbunătăţire a vânzării, sistemele de management orientat pe client, cum ar fi call-center-urile
şi aplicaţiile help-desk sunt exemple de zone explorate de către ofertanţii ce vor extinde
sistemele ERP către noi direcţii.
În sfârşit, implementarea sistemelor ERP este foarte complexă datorită imenselor
eforturi de adaptare dar şi a nevoii de a conduce organizarea acestei schimbări. Până de curând,
metodologiile implementărilor au tins să trateze toate companiile adoptatoare în acelaşi fel,
cerându-le acelaşi program complex de adoptare. Ca răspuns, ofertanţii ERP investesc resurse
semnificative pentru a îmbunătăţi procesul de implementare, simplificând instalarea şi
adaptarea sistemelor.
În concluzie, provocarea cu care se confruntă ofertanţii ERP, este de a organiza
cererea noilor aplicaţii, menţinând, în acelaşi timp, standardele operării acestor aplicaţii. Pentru
a rămâne concurenţi veritabili, ei trebuie să-şi descompună aplicaţiile compacte, construind, în
acelaşi timp, noi aplicaţii. Pe de altă parte există riscul ca piaţa sistemelor ERP să devină prea
divizată. Pe de altă parte, există o excelentă oportunitate pentru aceste sisteme, să împlinească
visul multor practicanţi şi academicieni de a folosi tehnologia informaţiei pentru a ajunge la un
nou nivel al integrării-client către vânzător, lanţ de cerere-ofertă în companii largi.

Întrebări de verificare
1. Enumerați minim 4 sisteme ERP.
2. Enumerați cele 4 tendințe în modelarea viitoare a sistemelor ERP.
3. Care sunt avantajele nete ale utilizării ERP în administrarea afacerilor?

83
BIBLIOGRAFIE
1. Lixăndroiu D., Bazele informaticii economice, Ed.Infomarket, Braşov, 2000
2. Niţchi Ş., ş.a., Bazele prelucrării informaţiilor şi tehnologie informaţională, Ed.
Intelcredo, Deva, 1996
3. Dumitru Oprea – Analiza şi proiectarea sistemelor informaţionale economice, Ed.
POLIROM, IAŞI, 1999
4. Popovici Dorin Mircea, ş.a. – Proiectare şi implementare software, ed. Teora,
Bucureşti, 1999
5. Reș Moreno-Doru – Sisteme informatice integrate E.R.P. – proiectare, implementare,
auditare, Ed. RISOPRINT, Cluj-Napoca, 2011
6. Rus Ioan – Informatică de Gestiune, Editura Dacia, Cluj-Napoca, 2007
7. Stanciu Victoria – Proiectarea sistemelor informatice de gestiune, Ed. CISON,
Bucureşti, 2000
8. Văduva I.,ş.a., - Programare structurată, Ed. Tehnică, Bucureşti, 1978,

84