Documente Academic
Documente Profesional
Documente Cultură
ANALIZA SISTEMELOR
INFORMAŢIONALE*
– Suport de curs –
2018
Cuprins
CAPITOLUL I ...................................................................................................................... 7
Sisteme informaţionale economice ....................................................................................... 7
1.1 Evoluţia sistemelor informaţionale economice .......................................................... 8
1.2 Tipologia sistemelor informaţionale ......................................................................... 10
1.3 Ciclul prelucrării datelor........................................................................................... 13
1.3.1 Faza de culegere a datelor.................................................................................. 15
1.3.2 Pregătirea datelor ............................................................................................... 17
1.3.3 Prelucrarea propriu-zisă a datelor ...................................................................... 18
1.3.4 Faza de stocare a datelor şi întreţinere a fişierelor ............................................ 21
1.3.5 Obţinerea ieşirilor .............................................................................................. 22
Rezumat ...................................................................................................................... 22
Întrebări recapitulative ................................................................................................ 23
Probleme de echipă ..................................................................................................... 23
CAPITOLUL II ................................................................................................................... 24
Sisteme informaţionale pentru conducere .......................................................................... 24
2.1 Sistemele de prelucrare a tranzacţiilor...................................................................... 24
2.1.1 Caracteristicile sistemelor de prelucrare a tranzacţiilor .................................... 25
2.1.2 Obiectivele sistemelor de prelucrare a tranzacţiilor .......................................... 25
2.1.3 Funcţiile sistemelor de prelucrare a tranzacţiilor .............................................. 27
2.1.4 Componentele sistemelor de prelucrare a tranzacţiilor ..................................... 28
2.2 Sistemele de informare a conducerii......................................................................... 29
2.2.1 Caracteristicile sistemelor de informare a conducerii ....................................... 30
2.2.2 Obiectivele sistemelor de informare a conducerii ............................................. 31
2.2.3 Funcţiile sistemelor de informare a conducerii ................................................. 32
2.2.4 Componentele sistemelor de informare a conducerii ........................................ 34
Rezumat ...................................................................................................................... 35
Întrebări recapitulative ................................................................................................ 35
Probleme de echipă ..................................................................................................... 36
CAPITOLUL III.................................................................................................................. 37
Introducere în dezvoltarea sistemelor informaţionale ........................................................ 37
3.1 Ciclul de viaţă al dezvoltării sistemelor informaţionale ........................................... 38
3.1.1 Modelul cascadă ................................................................................................ 39
3.1.2 Modelul V .......................................................................................................... 40
3.1.3 Modelul incremental .......................................................................................... 41
3.2 Definirea metodologiilor, modelelor, tehnicilor şi instrumentelor ........................... 43
3.3 Prezentarea generală a etapelor ciclului de viaţă al sistemelor informaţionale ........ 45
3.4 Participanţii la dezvoltarea sistemelor informaţionale ............................................. 49
Rezumat ...................................................................................................................... 52
Întrebări recapitulative ................................................................................................ 52
Probleme de echipă ..................................................................................................... 52
CAPITOLUL IV ................................................................................................................. 54
Microanaliza sistemelor informaţionale ............................................................................. 54
4.1 Identificarea şi selecţia proiectelor de dezvoltare a sistemelor informaţionale........ 54
4.1.1 Potenţialele proiecte de dezvoltare .................................................................... 55
4.1.2 Clasificarea, ierarhizarea şi selecţia proiectelor de dezvoltare.......................... 57
4.1.2 Planificarea sistemului informaţional ................................................................ 59
4.3 Iniţierea şi planificarea proiectelor de dezvoltare a sistemelor ................................ 68
4.4 Analizele de fezabilitate ........................................................................................... 75
Rezumat ...................................................................................................................... 76
Întrebări recapitulative ................................................................................................ 77
4 ANALIZA SISTEMELOR INFORMAŢIONALE
CAPITOLUL I
Obiective:
Prezentarea sistemelor economice şi a componentelor generale ale acestora
Definirea sistemelor informaţionale şi prezentarea evoluţiei lor
Clasificarea sistemelor informaţionale
Descrierea ciclului prelucrării datelor
Conceptul de sistem informaţional economic a fost definit în moduri diferite. De cele mai
multe ori, el este sinonim cu sistem informaţional pentru conducere, iar cele mai dese referiri
se fac la această ultimă variantă, aşa cum vom proceda şi noi în continuare. Din toate
definiţiile, rezultă că el este un ansamblu de resurse umane şi de capital, investite într-o
unitate economică, în vederea colectării şi prelucrării datelor necesare producerii
informaţiilor, care vor fi folosite la toate nivelurile decizionale ale conducerii şi controlului
activităţilor organizaţiei.
Sistemul informaţional pentru conducere nu trebuie tratat numai prin prisma
calculatorului electronic, deoarece şi unităţile care nu dispun de el beneficiază de serviciile
unui astfel de sistem.
Termenul de sistem este deosebit de popular în domeniul informaticii, sub forma
diferitelor componente specifice: echipamente, persoane, software, date, funcţii. Cu alte
cuvinte, el este alcătuit din multiple elemente care interacţionează pentru atingerea unui scop
comun.
Există o strânsă legătură între sistemele fizice, existente la nivelul unei firme, şi sistemul
informaţional, considerat sistem logic, din următoarele considerente1:
sistemul fizic (real) este alcătuit din bunurile corporale prin intermediul cărora se
desfăşoară activităţile oriecărei organizaţii (firmă, instituţie guvernamentală, bancă,
instituţie de învăţământ etc). Componentele sistemului fizic sunt clădirile, angajaţii,
echipamentele, resursele materiale, banii, toate folosite pentru atingerea unor
obiective, cum ar fi obţinerea profitului, recuperarea investiţiilor, câştigarea unui
segment de piaţă, creşterea cotaţiei acţiunilor pe piaţa bursieră etc.;
sistemul logic (reglat) reprezintă mijloacele prin care se pot reda, din punct de vedere
logic, componentele sistemului fizic. Un astfel de sistem este, de exemplu, sistemul
de gestiune a stocurilor, în sensul că datele şi informaţiile păstrate de către acesta
reprezintă articolele fizice de stoc, existente în diferite depozite ale firmei. Sistemul
stocurilor oferă rapoarte (pe hârtie sau în format electronic) ce conţin informaţii
despre existenţa diferitelor articole în stoc, despre operaţiunile care s-au efectuat
asupra stocurilor. Diferiţi utilizatori autorizaţi vizualizează rapoartele pentru a urmări
evoluţia stocurilor, ceea ce înseamnă că nu este necesar să se deplaseze la fiecare
depozit pentru a vedea dacă un anumit articol există sau nu în stoc. Presupunând că
raportul privind stocurile conţine informaţii corecte, managerii nu trebuie decât să-l
citească pentru a lua deciziile cuvenite.
1. McLeod Jr., R., Jordan, E. – System Development. A Project Management Approach, John Wiley & Sons, Inc.,
New York, 2002, pp. 29-30.
8 ANALIZA SISTEMELOR INFORMAŢIONALE
Date aţii
Resurse umane
Software Comunic
Echipamente
speciale
MEDIUL INTERN
Informaţ
ii Structură
Sisteme pe funcţii Resurse umane, ă
materiale, financiare
Conducere organizatoric
MEDIUL EXTERN
Furnizori Organisme stituţii
Clienţi Investitori Diverse in
Concurenţi Bănci/Creditori
(Acţionari) guvernamentale
Furnizor
CULEGEREA
DATELOR
PREGĂTIREA DATELOR
PRELUCRAREA
DATELOR
ÎNTREŢINEREA
FIŞIERELOR
Fiecare ciclu prelucrează un număr mai mare sau mai mic de activități, multe dintre ele
fiind, totuşi, divizate în categorii mai mici, datorită numărului prea mare, a particularităţilor pe
care le prezintă sau a complexităţii procesului de prelucrare. De exemplu, majoritatea
activităților/operațiilor prelucrate în ciclul privind vânzările şi încasările sunt legate fie de
vânzarea produselor, fie de încasarea contravalorii bunurilor vândute.
datelor fie prin scrierea lor în documentele sursă, fie prin captarea şi stocarea lor cu ajutorul
diferitelor echipamente.
Metodele de colectare a datelor pot fi grupate în directe (culegerea la sursă) şi indirecte
(culegerea tradiţională a datelor).
Metoda tradiţională de colectare a datelor presupune realizarea unui număr mare de
activităţi, cele mai multe fiind manuale, cum ar fi culegerea de pe comenzile primite de la
clienţi sau de pe listele de inventar, atunci când intervin modificări în structura stocurilor.
Introducerea datelor se realizează prin intermediul unor ecrane (formulare de preluare a
datelor) care sunt similare ca formă, conţinut şi denumire cu documentul sursă pe care îl
reflectă. Prin intermediul ecranelor de introducere a datelor se îmbunătăţesc atât controlul, cât
şi corectitudinea datelor despre activităţile economice. Controlul este mai eficient prin faptul
că se poate apela la:
1. achiziţia de documente prenumerotate (facturi, chitanţe), urmărindu-se să nu fie omis
nici un document prin verificarea secvenţei de numerotare;
2. secvenţierea automată, prin atribuirea de numere pentru fiecare activitate/operație
nouă.
Corectitudinea datelor este asigurată prin instrucţiunile sau mesajele privind datele ce
trebuie introduse, gruparea logică a categoriilor de informaţii care se culeg, utilizarea check-
box-urilor pentru bifarea unui câmp sau a meniurilor de tip pull-down, pentru selecţia de valori,
apelarea la diferite stiluri, culori, linii pentru separarea clară a câmpurilor care trebuie
completate.
Datorită numărului mare de activităţi şi a suporturilor pentru înregistrare utilizate, a
caracterului preponderent manual al acestor activităţi şi a numărului mare de persoane
implicate, metoda este costisitoare şi produce numeroase erori.
Aceste deficienţe reprezintă motivul principal pentru care dezvoltarea sistemelor
informatice s-a orientat către metode directe de colectare a datelor, numite şi metode de
culegere a datelor la sursă. Aceste metode îşi propun automatizarea activităţii de colectare a
datelor prin reducerea sau eliminarea majorităţii activităţilor, personalului şi a suporturilor
pentru înregistrarea datelor necesare în metodele tradiţionale.
O importanţă deosebită prezintă echipamentele pentru introducerea directă a datelor,
respectiv scannerele de imagini şi scannerele pentru recunoaşterea optică a caracterelor – OCR
(Optical Character Recognition – Recunoaşterea optică a caracterelor), schimbul electronic
de date (EDI – Electronic Date Interchange), utilizarea codurilor bară pentru punctele de
vânzare (POS – Point of Sale), tehnologia RFID (Radio-Frequency Identification),
echipamente de numărare sau cântărire a produselor obţinute, echipamente de citire a
legitimaţiilor salariaţilor pentru înregistrarea timpului la care au intrat/ieşit din unitate etc.
De exemplu, citirea codului bară al unui produs cu ajutorul dispozitivelor de scanare este
mult mai rapidă, asigurând un grad de corectitudine mult mai mare decât dacă s-ar introduce
manual. Scannerul citeşte codul bară al fiecărui articol şi caută preţul în tabela de produse. În
acelaşi timp, prin intermediul POS-urilor se interoghează baza de date pentru determinarea
preţului de vânzare al produselor cumpărate şi calcularea valorii pe care trebuie să o plătească
un client, determinarea automată a cotei de TVA sau a taxei pe vânzări – în ţările unde nu se
foloseşte TVA, precum şi posibilitatea de încasare pe bază de card şi nu cu numerar. Tipul
produselor şi cantitatea din fiecare produs, data, momentul din zi şi valoarea achiziţiilor sunt
informaţii folosite mai departe pentru actualizarea datelor privind stocurilor de produse,
identificarea profilului clientului etc. În continuare, pe baza tabelei de stocuri actualizată, se
poate genera un raport de atenţionare a gestionarului că este necesar să se aprovizioneze cu noi
cantităţi, atunci când stocul scade sub un anumit nivel. De asemenea, informaţiile culese
privind vânzările efectuate către un anumit client sau ale unui produs pot fi folosite pentru
realizarea de analize detaliate a vânzărilor, de genul cel mai bine vândut produs, momentele
din zi, săptămână când un produs a fost cumpărat cel mai bine etc.
SISTEM, SISTEM ECONOMIC, SISTEM INFORMAŢIONAL 17
O situaţie similară apare în cazul utilizării cardurilor pentru evidenţa timpului lucrat de
salariaţi. Pe lângă informaţiile privind timpul lucrat pentru calculul salariilor, un astfel de
sistem poate ajuta firma să determine câte ore s-a lucrat pentru fiecare activitate sau proiect,
astfel că pot fi făcute ajustări şi planificări mai bune ale timpului pentru viitoarele proiecte.
Metoda culegerii directe a datelor nu este lipsită însă de dezavantaje, în sensul că, la
apariţia erorilor, e destul de dificil de identificat cauza sau locul de provenienţă a lor, costurile
dezvoltării unui astfel de sistem nu sunt mici, dar comparabile cu cele pe care le presupune
metoda tradiţională.
O altă cale, mai practică (pentru întreprinderile noastre), de colectare directă a datelor
constă în instalarea unei reţele de calculatoare şi dispunerea de terminale în diferite puncte din
întreprindere (secţii de producţie, magazie, birouri) care să permită culegerea datelor la locul
producerii lor şi transmiterea lor în vederea unei prelucrări centralizate, metodă considerată
mixtă şi care combină avantajele celorlalte două.
firmă sau produsele al căror stoc este mai mic decât o anumită cantitate. Sortarea datelor poate
fi făcută la cererea utilizatorilor sau poate fi realizată automat, prin aplicații, în funcție de
modul în care au fost gândite prelucrările de date și nevoile de informații.
Cuplarea (fuziunea) a două sau mai multor loturi de înregistrări într-unul singur. Această
operațiune, în situația prelucrărilor automate, nu apare ca fiin necesară, însă în cazul
prelucrărilor manuale sunt strict necesare. De exemplu, se cuplează toate loturile ce conțin
înregistrările privind facturile primite de la furnizori și plățile către aceștia. În felul acesta, se
asigură o creștere a eficienței prelucărilor propriu-zise de date, nemafiind necesară căutarea
datelor de un anumit tip.
Transmiterea datelor de la un punct la altul şi transcrierea lor dintr-o formă în alta, astfel
încât să se efectueze trecerea de la scrierea de mână la cea tipizată sau de la documentele scrise
la mediile specifice calculatoarelor. Sunt situații când firmele nu au sisteme informatice
performante, nu sunt integrate, nu există suficiente echipamente de prelucrare, motiv pentru
care de la un punct de lucru la sediul central datele se transmit pe un suport electronic, urmând
a fi încărcate în baza de date și prelucrate la nivelul întregii firme. Altfel, dacă sistemul este
integrat, iar infrastructura fizică permite comunicarea în timp real, datele generate de operațiile
economice de la un punct de lucru al firmei se vor reflecta automat în situațiile generale ale
acesteia, fără a mai fi necesară transcrierea și/sau transmiterea datelor dintr-un format în altul.
Poate cea mai importantă activitate o reprezintă verificarea datelor pentru validarea şi
asigurarea corectitudinii lor, pentru a detecta orice problemă ce ar fi putut interveni la
culegerea lor. De exemplu, datele privind cantitatea şi preţul produselor vândute trebuie să fie
numerice, iar denumirea produselor alfabetice sau alfanumerice, altfel datele neputând fi
validate.
Adesea, codurile asociate unei anumite operații trebuie să fie verificate în baza de date
pentru a controla existenţa datelor de identificare ale acelei categorii de operații. Dacă se
introduce un cod care nu se regăseşte în baza de date, activitatea este refuzată pentru
prelucrările ulterioare. Refuzarea la prelucrare a unei operații nu este suficientă, pentru că
sistemul trebuie să transmită mesaje prin care să specifice ce problemă a apărut, ce corecţii
trebuie făcute, dacă este necesar să se reintroducă datele depistate a fi eronate în timpul
verificării etc. De exemplu, un cod bară scanat trebuie să existe în tabela de produse. Dacă el
nu poate fi citit sau nu există în tabelă, persoana care realizează operaţiunea de scanare
primeşte instrucţiuni fie pentru rescanarea produsului, fie pentru introducerea manuală a
codului.
line processing). Aceste două metode privesc nu numai prelucrarea propriu-zisă a datelor, ci şi
celelalte faze ale ciclului de prelucrare (colectarea datelor, actualizarea bazei de date).
Prelucrarea pe loturi presupune, mai întâi, acumularea datelor privind operațiile
economice pe o anumită perioadă, după care urmează prelucrarea lor periodică, chiar şi în ceea
ce priveşte actualizarea bazei de date. În acest mod, se realizează utilizarea mai eficientă a
resurselor informatice decât în cazul prelucrării în timp real, mai ales în situația în care
operațiile economice nu au o frecvență mare, şi se asigură un mai bun control asupra datelor.
Schematic, prelucrarea pe loturi a datelor este redată în figura 1.4.
Informaţii (nu
Date privind Intoducere date reflectă starea
tranzacţiile, (pe loturi) curentă, doar
cumulate perioade
pe loturi anterioare)
Prelucrare pe loturi
Dezavantajele acestui tip de prelucrare derivă din faptul că datele din tabelele principale
ale bazei de date şi informaţiile din rapoarte sunt perimate în momentele prelucrării lor, deci nu
se pot obţine informaţii la zi despre activitatea firmei. De aceea, prelucrarea pe loturi este
recomandată doar pentru acele aplicaţii care nu necesită actualizarea bazei de date pe măsură
ce au loc activitățile/operațiile şi atunci când sunt solicitate rapoarte doar la anumite intervale
de timp bine definite.
Este motivul pentru care se încearcă renunţarea la prelucrările pe loturi în favoarea
prelucrărilor în timp real (OLTP – On-Line Transaction Processing). Acest tip de prelucrare
presupune colectarea şi prelucrarea datelor în timp ce are loc o activitate/operație economică,
fără acumularea datelor şi tratarea lor periodică. În acest fel, se elimină activităţile de grupare,
sortare şi transcriere specifice prelucrării pe loturi. Imediat ce are loc o operație economică,
datele sunt colectate cu ajutorul diferitelor echipamente şi stocate în fişiere cu acces direct,
apoi sunt prelucrate în vederea actualizării tabelelor permanente ale bazei de date sau obţinerii
diverselor rapoarte. Numai că introducerea prelucrării în timp real necesită instalarea unei
reţele locale sau extinse care să lege între ele terminalele şi calculatoarele aflate la diferite
posturi de lucru din organizaţie.
Cele mai întâlnite sisteme informaţionale bazate pe prelucrări în timp real se regăsesc în
băncile care au instalate ATM-uri (bancomate) şi în sistemele de rezervare ale companiilor
aeriene.
Sistemele informaţionale bazate pe prelucrarea în timp real oferă marele avantaj al
furnizării imediate de informaţii actuale. În schimb, ele presupun şi o serie de dezavantaje
legate de integrarea numeroaselor proceduri de control privind protejarea conţinutului bazei de
date împotriva accesului neautorizat sau a distrugerii accidentale a datelor (multe organizaţii
ţin un jurnal de control în care sunt înregistrate toate activitățile/operațiile care au avut loc).
În realitate, puţine sisteme informaţionale se bazează doar pe prelucrări în timp real. Cele
două metode de prelucrare a datelor pot fi combinate, în funcţie de obiectivele urmărite şi de
particularităţile organizaţiei.
O comparaţie între cele două tipuri de prelucrări este realizată în tabelul 1.1.
Odată cu dezvoltarea tehnologiilor data warehouse şi a data marts-urilor, prelucrarea on-
line nu mai era suficientă, pentru că nu permitea căutarea şi interogarea bazelor de date
multidimensionale. Ca rezultat, şi-a făcut apariţia o nouă modalitate de prelucrare a datelor,
cea analitică on-line (OLAP – On-Line Analytical Processing), pentru a memora, prelucra şi
transmite informaţii specifice depozitelor de date. OLAP permite utilizatorilor să exploreze
datele firmei din mai multe perspective/dimensiuni.
20 ANALIZA SISTEMELOR INFORMAŢIONALE
Tabel nr. 1.1 – Comparaţie între prelucrarea pe loturi şi prelucrarea în timp real
Caracteristică Prelucrarea pe loturi Prelucrarea în timp real
Prelucrarea Datele operațiilor sunt colectate, Datele operațiilor sunt prelucrate
datelor grupate, sortate, transcrise şi apoi imediat ce ele au fost produse.
prelucrate periodic.
Actualizarea După prelucrarea lotului. După prelucrarea datelor privind
fişierelor activitatea/operației.
Timpul de răspuns Mai multe ore sau zile, după ce lotul Câteva secunde după producerea
de date a fost prelucrat. evenimentului (activitate/operație)
Instrumentele şi serverele OLAP sprijină analiza datelor incluse în relaţii complexe, cum
ar fi combinaţii între produsele firmei, regiuni geografice unde au fost vândute, canale de
distribuţie, perioade de vânzări etc. Dacă la început OLAP era folosit în special pentru
planificările financiare, ulterior a devenit din ce în ce mai utilizat în domeniile ce solicită
analize rapide, aşa cum este cazul investiţiilor pe piaţa acţiunilor, marketingului, lansării pe
piaţă a unui nou produs, determinării profitabilităţii unui client etc.
Caracteristicile OLAP sunt2:
oferă posibilitatea analizei datelor de tip drill-down (descompunere pe niveluri din ce
în ce mai detaliate), bazate pe interogări în baze de date multidimensionale, pe mai
multe dimensiuni ale problemei ce urmează a fi studiată;
presupun o mare ingeniozitate umană şi o puternică interacţiune cu bazele de date
pentru găsirea informaţiilor necesare;
solicită testarea repetitivă a ipotezelor emise de utilizatori pentru identificarea
faptelor.
În figura 1.4 sunt ilustrate componentele necesare pentru efectuarea analizelor cu
instrumentele OLAP.3
OLAP Server
Client PC
Baza de date a
corporaţiei
Baza de date
operaţională
Baza de date Minidepozite de date
multidimensională Depozite de date
Foi de calcul
Pachete statistice
Software OLAP ce poate
rula cu browsere Web
Datele sunt extrase din baza de date a firmei şi depozitate într-o bază de date
multidimensională, de unde vor fi interogate de aplicaţiile instalate la utilizatori. Interogările
OLAP presupun efectuarea unor analize asupra datelor, cum ar fi4:
Consolidarea implică agregarea datelor, care poate însemna o simplă adunare sau poate fi
o grupare după criterii complexe ce ţin de relaţiile dintre date. Ca exemplu, vânzările locale pot
fi cumulate la nivel de zonă şi ulterior la nivel de regiune.
Analiza drill-down (pe niveluri de detaliere) reprezintă operaţia inversă consolidării, prin
care datele consolidate sunt analizate în detaliu, ajungându-se la datele care le-au compus. Ca
exemplu, analiza vânzărilor unui produs sau ale unui agent de vânzări din totalul vânzărilor
înregistrate într-o regiune;
Analiza de tip „slicing and dicing” (feliere la întâmplare/aleatoare) se referă la
posibilitatea de a efectua analize din diferite puncte de vedere, ţinând cont de diferite criterii.
De exemplu, se pot analiza toate vânzările unui anumit tip de produs într-o anumită regiune (o
„felie” din total), în timp ce o altă interogare poate arăta totalul vânzărilor produsului respectiv
printr-un anumit canal de ditribuţie. Aceste analize sunt efectuate, de regulă, în funcţie de
anumite axe (cum ar fi axa timpului) pentru a determina anumite tendinţe sau tipare.
Dintre cei mai cunoscuţi furnizori de software OLAP se numeră Cognos, Hyperion
Solutions, Oracle, MineShare, WhiteLight, Microsoft.
În ultima perioadă, tot în scopul prelucrării cantităților mari de date, au apărut noi
tehnologii, între care mai importante sunt Cloud Computing și Data Analytics, care vin în
sprijinul Big Data.
Cloud Computing-ul este o combinaţie de conexiuni rapide Internet, cu puteri de calcul,
multe și ieftine, bazate pe Web, prin folosirea de soft complex pentru monitorizarea şi
gestiunea activităților de prelucrare, indiferent de locația geografică. Cloud Computing
reprezintă un set distribuit de servicii de prelucrare, aplicații, acces la informații și stocarea
datelor, fără ca utilizatorii să cunoască amplasarea și configurația fizică a sistemelor care
asigură aceste servicii. Mai este văzut și ca un sistem de resurse de tip “low cost”.
Data Analytics reprezintă modalitatea de a analiza date brute cu scopul de a extrage o
serie de concluzii pe baza acestor informații. Data Analytics se utilizează în multe domenii,
pentru a permite organizațiilor să ia cele mai bune decizii în domeniul lor de activitatea, iar în
cazul diferitelor științe să se verifice și valideze modele și teorii. Data Analytics diferă de data
mining prin domeniul de aplicare, scopul și orientarea analizelor efectuate. Analiștii sortează
seturi uriașe de date folosind software specializat pentru a identifica modele noi și pentru a
descoperi conexiuni imposibil altfel de determinat. Data Analytics se bazează pe deducție și
inferențele logice cunoscute de cei care sunt implicați în procesul de analiză.
Rezumat
O categorie aparte a sistemelor o constituie sistemul informaţional, întâlnit deseori în viaţa de zi cu
zi, fiind caracterizat de cele trei aspecte comune regăsite la orice sistem: sunt constituite din mai multe
componente, ce interacţionează între ele, în vederea realizării unui scop comun. Sistemul informaţional al
unei organizaţii este cel care redă, din punct de vedere logic, componentele fizice ale organizaţiei şi
acţiunile care au loc în interiorul sau cu exteriorul ei.
Sistemul informaţional este un ansamblu de resurse umane şi de capital, investite într-o
organizaţie, în vederea colectării şi prelucrării datelor necesare producerii informaţiilor, care vor fi
folosite la toate nivelurile decizionale ale conducerii şi controlului activităţilor organizaţiei.
Evoluţia sistemului informaţional – de la primele forme, în care prelucrarea se făcea primordial
manual, până la noile forme, bazate pe Web – reflectă progresul tehnologiilor informaţionale şi de
comunicaţii, schimbările intervenite în strategiile şi cerinţele organizaţionale, creşterea luptei pentru
câştigarea avantajelor competitive etc.
Din definiţie se poate observa că sistemul informaţional îndeplineşte patru funcţii esenţiale pentru
activitatea unei firme: (1) colectarea datelor despre activităţile desfăşurate într-o organizaţie, (2)
SISTEM, SISTEM ECONOMIC, SISTEM INFORMAŢIONAL 23
prelucrarea datelor, transformarea lor în informaţii şi stocarea, (3) asigurarea elementelor necesare
efectuării controlului, (4) sprijinirea procesului decizional.
Pentru realizarea funcţiilor specifice, datele generate de activitățile/operațiile economice sunt
supuse unui set de operaţiuni, din momentul apariţiei lor, pentru a permite obţinerea de informaţii
semnificative, cuprinse la un loc prin noţiunea de ciclu al prelucrării datelor. Ciclul cuprinde cinci faze:
culegerea datelor, pregătirea datelor, prelucrarea datelor, întreţinerea fişierelor şi obţinerea informaţiilor
de ieşire.
Întrebări recapitulative
1. Care sunt principalele elemente componente ale unui sistem informaţional?
2. Exemplificaţi cel puţin 3 criterii de clasificare a sistemelor informaţionale.
3. Explicaţi de ce un tabel şi un grafic privind evoluţia vânzărilor unui produs reprezintă componentele
logice ale unui sistem.
4. Care sunt principalele categorii de sisteme informaţionale, plecând de la criteriul managerial?
5. Enumeraţi sistemele informaţionale care nu se încadrează pe nici un nivel decizional, dar le sprijină
activitatea.
6. Care sunt elementele unei activități/operații economice pe care un sistem informaţional trebuie să le
reflecte?
7. Exemplificaţi fiecare activitate din ciclul prelucrării datelor.
8. Prezentaţi diferenţele dintre prelucrarea datelor pe loturi şi prelucrarea în timp real.
Probleme de echipă
1. Descrieţi principalele caracteristici ale sistemelor informaţionale ce pot fi identificate îmtr-o
organizaţie şi încadraţi-le în cel puţin trei criterii de clasificare cunoscute. Motivaţi alegerile făcute.
2. Prezentaţi principalele activități/operații economice pe care ar trebui să le suprindă sistemele
informaţionale identificate într-o organizaţie. Se cer:
analiza modului în care datele despre aceste activități sunt prelucrate şi explicarea a ceea ce se
întâmplă în fiecare etapă a ciclului de prelucrare a datelor;
identificarea principalelor documente pe care firma le foloseşte pentru a culege date relevante
despre activitățile identificate la punctul anterior;
enumerarea principalelor rapoarte obţinute. Ce decizii pot fi influenţate de aceste rapoarte?
CAPITOLUL II
Obiective:
Descrierea principalelor categorii de sisteme informaţionale
Cunoaşterea principalelor tipuri de sisteme de prelucrare a tranzacţiilor
Identificarea elementelor ce caracterizează sistemele de informare a conducerii
economice ale acestora. Este adevărat că finalizarea multor activități economice presupune
implicarea mai multor componente organizatorice, dar prelucrarea datelor privind acele
operații nu este obligatoriu să se realizeze acolo unde au avut loc. De exemplu, sistemul
privind gestiunea clienţilor presupune culegerea datelor de la biroul desfacere, depozite, biroul
financiar, ceea ce înseamnă că acest sistem nu poate fi localizat într-un singur birou,
prelucrarea datelor putându-se realiza în oricare dintre cele trei birouri sau în toate, în funcţie
de responsabilităţile de prelucrare alocate fiecăruia. Un alt exemplu este cel în care prelucrarea
datelor se face centralizat, într-un departament specializat, gen centru de procesări. Ca urmare,
nu putem identifica sau pune semnul egal între sistemul de evidenţă a clienţilor şi biroul
desfacere sau departamentul informatic.
Sistemele de prelucrare a tranzacţiilor rămân, cu toate evoluţiile tehnologice, cea mai
importantă categorie de sisteme informaţionale dintr-o organizaţie, pentru că reprezintă
principalul instrument prin care firma poate să interacţioneze direct cu mediul extern şi asigură
informaţii despre ceea ce se întâmplă în firmă. Pentru că managerii sunt tentaţi să solicite tot
mai mult informaţii de ultimă oră şi nu informaţii despre evenimentele trecute, este esenţial ca
aceste sisteme să funcţioneze fără întreruperi şi fără erori. Este cazul sistemelor de comerţ
electronic, pentru că, în esenţă, sistemele de prelucrare a tranzacţiilor sunt cele pe care trebuie
să se bazeze funcţionarea comerţului electronic.
Plecând de la aceste consideraţii generale, încercăm să prezentăm principalele
caracteristici, obiective, funcţii şi aplicaţii ale sistemelor de prelucrare a tranzacţiilor.
1. Marc, L., Songini, M. – „Procter&Gamble Unit Aims IT as Contract Monitoring”, in Computerworld, January 28,
2002, www.computerworld.com.
SISTEME INFORMAŢIONALE PENTRU CONDUCERE 27
2. Stair, R.M., Reynolds, G.W. – Principles of Information Systems, 6th Edition, Course Technology, Thomson
Learning, Boston, 2003, p. 21.
28 ANALIZA SISTEMELOR INFORMAŢIONALE
3. Structura în care angajaţii cu activităţi similare – cum sunt marketing, producţie, contabilitate – sunt grupaţi într-o
subunitate (departament, serviciu sau birou) a organizaţiei.
SISTEME INFORMAŢIONALE PENTRU CONDUCERE 29
4. McLeod Jr., R., Schell, G. – Management Information Systems, 8th Edition, Prentice Hall, Upper Saddle River,
New Jersey, 2001, pp. 239-240.
5. Stair, R.M., Reynolds, G.W. – op. cit., p. 415.
30
Alte surse
externe de date Date
Date Date
Informaţii
Informaţii
Baze de date Baze de date
cu informaţii cu informaţii
Date Date
Informaţii
Sisteme de sprijinire
Rapoarte Management Interogări a top-managerilor
strategic
Informaţii Rapoarte
Informaţii Management Informaţii/
operational scenarii
Interogări
ANALIZA SISTEMELOR INFORMAŢIONALE
să găsească soluţiile. Dar, pentru eliminarea acestui neajuns, şi-au făcut apariţia sistemele de
SISTEME INFORMAŢIONALE PENTRU CONDUCERE 31
să obţină un raport privind cantitatea de produse existentă în stoc pentru produsele solicitate,
un raport privind limita de creditare acordată clientului şi în ce sumă se mai poate încadra cu
noua comandă, astfel încât să fie în măsură să accepte sau nu comanda respectivă.
Prin folosirea tehnologiilor avansate de extragere şi interpretare a datelor (OLAP – On-
line Analitycal Processing, data warehouse, data mining ş.a.), sistemele de informare a
conducerii au la dispoziţie instrumente ce permit prelucrări interactive ale utilizatorilor, multe
dintre rapoarte putând fi generate în varianta rapoartelor de tip drill-down6, adică a rapoartelor
cu grade diferite de detaliere, în funcţie de necesităţile utilizatorilor. Astfel, managerii pot să
analizeze, iniţial, date sintetice, după care pot obţine informaţii din ce în ce mai analitice, prin
navigare în cadrul unei ierarhii a descompunerii raportului. Un exemplu de raport de acest tip
este prezentat în fig. 2.2.
3. Controlul
Ca şi în cazul sistemelor operaţionale, prin control se urmăreşte asigurarea corectitudinii
şi calităţii informaţiilor generate de sistem, prin detectarea şi eliminarea erorilor apărute în
timpul culegerii şi prelucrării datelor.
Rezumat
Pentru redarea operaţiunilor curente desfăşurate la nivelul unei firme şi pentru asigurarea unui
control riguros al resurselor pe care le solicită, sunt implementate sistemele de prelucrare a tranzacţiilor,
fără de care nici o firmă nu poate să-şi desfăşoare în condiţii normale activităţile. Aceste sisteme se află
pe nivelul operaţional al conducerii unei firme, dar reprezintă suportul esenţial pentru generarea
informaţiilor necesare celorlalte niveluri decizionale.
Firmele au realizat că datele stocate la nivelul sistemelor de prelucrare a tranzacţiilor pot fi utilizate
şi pentru a ajuta managerii în luarea celor mai bune decizii în sfera lor de acţiune, nu numai la nivel
operaţional, ci şi la nivelul managementului tactic şi strategic. Satisfacerea cerinţelor informaţionale a
fost şi este un factor determinant pentru dezvoltarea sistemelor de informare a conducerii tactice.
La acest nivel, sistemele informaţionale trebuie să asigure informaţiile necesare stabilirii planurilor
şi bugetelor de desfăşurare a activităţilor, care, în majoritatea cazurilor, sunt decizii ce privesc
gestionarea resurselor întreprinderii, supravegherea şi controlul.
Sistemele de informare a conducerii permit obţinerea mai multor categorii de rapoarte, şi anume:
liste de control, situaţii operative, rapoarte periodice, de excepţie, neplanificate, analize speciale,
prelucrări interactive, cu scopul sprijinirii deciziilor ce se iau la nivelul componentelor funcţionale ale
firmei, având un caracter parţial structurat.
Prin prezentarea principalelor categorii de sisteme informaţionale, s-a încercat evidenţierea
caracteristicilor esenţiale ce trebuie avute în vedere la dezvoltarea lor. Deşi principalele etape şi activităţi
pot fi identice, aspectele de care trebuie să se ţină cont la dezvoltarea lor diferă, în special, din
perspectiva utilizatorilor şi nevoilor lor informaţionale, a tehnologiilor şi arhitecturilor pe care le
presupune implementarea fiecărei categorii de sisteme.
Întrebări recapitulative
1. Prin ce se diferenţiază sistemele de prelucrare a tranzacţiilor de compartimentele/ departamentele
din structura organizatorică a unei firme?
2. Care sunt aspectele ce scot în evidenţă importanţa sistemelor de prelucrare a tranzacţiilor?
3. Prin ce se diferenţiază sistemele de prelucrare a tranzacţiilor de sistemele de informare a
conducerii?
4. Care este rolul şi prin ce se caracterizează sistemele de informare a conducerii?
5. Prezentaţi tipurile de rapoarte ce pot fi obţinute cu ajutorul sistemelor de informare a conducerii.
6. Care sunt trăsăturile sistemelor de sprijinire a procesului decizional?
7. Care sunt principalele funcţii pe care le poate îndeplini un sistem de sprijinire a procesului
decizional?
36 ANALIZA SISTEMELOR INFORMAŢIONALE
Probleme de echipă
1. Plecând de la informaţiile pe care le găsiţi în diferite reviste economice sau de informatică
economică, identificaţi pachete software care pot fi implementate pentru asigurarea funcţionalităţii
sistemelor de sprijinire a procesului decizional, sistemelor de informare a top-managerilor şi
birotică.
2. Presupunând că sunteţi o echipă ce a înfiinţat o firmă nouă, care vinde aparatură electrocasnică,
specificaţi care sunt aplicaţiile sistemelor de prelucrare a tranzacţiilor de care aţi avea nevoie şi
motivaţi.
3. Echipa trebuie să culeagă informaţii despre o aplicaţie (un pachet software) specifică sistemelor de
prelucrare a tranzacţiilor. Realizaţi un raport de două pagini prin care să descrieţi acea aplicaţie.
4. Echipa a fost desemnată să propună un sistem de informare a conducerii pentru o firmă mică, ce
produce 10 tipuri de modele de încălţăminte pentru copii. Aceste produse sunt vândute
distribuitorilor şi magazinelor de încălţăminte specializate din Regiunea Nord-Est. Una din
principalele probleme cu care se confruntă firma o reprezintă faptul că nu are un control eficient
asupra stocurilor de produse. Întotdeauna se confruntă cu faptul că o parte din modele rămân în stoc
o perioadă prea mare de timp, în timp ce stocul pentru alte modele este epuizat foarte repede.
Patronul firmei a sugerat că ar dori să rezolve această problemă. Realizaţi o scurtă prezentare a
principalelor subsisteme şi a rapoartelor corespunzătoare unui sistem de informare a conducerii care
s-ar preta acestei firme. Construiţi o schemă prin care să evidenţiaţi modul în care subsistemele pot
fi integrate. Enumeraţi câteva din beneficiile pe care le-ar putea obţine firma printr-un control mai
riguros al stocurilor de încălţăminte.
5. Imaginaţi-vă că sunteţi o echipă care trebuie să decidă asupra dezvoltării unui sistem de informare a
top-managerilor pentru firma de la problema 4. Care sunt principalele decizii pe care conducerea
strategică ar trebui să le ia? Realizaţi o listă a principalelor caracteristici pe care trebuie să le ofere
un astfel de sistem. Identificaţi cel puţin trei surse externe de date care vor fi utile decidenţilor
strategici.
6. Mergeţi la o firmă şi încercaţi să aflaţi următoarele aspecte:
a. tipurile de sisteme informaţionale existente şi încadrarea lor după criteriul managerial;
b. alegeţi două dintre sisteme şi prezentaţi principalele informaţii care sunt obţinute cu ajutorul lor;
c. enumeraţi deciziile care pot fi luate pe baza informaţiilor oferite de cele două sisteme.
CAPITOLUL III
Introducere în dezvoltarea
sistemelor informaţionale
Obiective:
Caracterizarea celor mai cunoscute modele ale ciclurilor de viaţă ale dezvoltării
sistemelor informaţionale
Crearea unei imagini generale asupra etapelor proiectului de dezvoltare a unui sistem
Datorită existenţei unui context din ce în ce mai competitiv şi a unei lumi aflată în
continuă schimbare, firmele trebuie să facă faţă provocărilor prin căutarea de noi soluţii, bazate
pe obţinerea rapidă de informaţii. Pentru a răspunde acestei nevoi, sistemul informaţional
trebuie supus unor modificări continue, plecând de la mici ajustări sau adaptări până la
schimbări substanţiale sau chiar înlocuirea lui. Schimbările sunt atât de constante şi frecvente,
încât majoritatea firmelor sunt într-un proces continuu de îmbunătăţire sau transformare a
sistemelor. Ele sunt nevoite să efectueze diferite modificări, cel puţin datorită unuia dintre
următoarele motive:
ca parte a unui program mai amplu de modernizare a întregului sistem. Multe firme
întreprind o serie de proiecte pentru modernizarea tehnologiei de prelucrare a datelor
– hardware, sisteme de operare, programe utilitare, aplicaţii informatice. Un astfel de
proiect este iniţiat, de obicei, ca parte a intenţiei de a înlocui aplicaţiile vechi,
centralizate, cu altele noi, bazate pe tehnologia client/server, a sistemelor distribuite
sau a celor bazate pe web;
modificarea unor aspecte funcţionale de bază. Firmele îşi reproiectează procesele de
bază fie ca rezultat al efortului continuu de îmbunătăţire permanentă a activităţilor, fie
mult mai radical, ca efect al reproiectării proceselor economice;
schimbarea obiectivelor strategice ale organizaţiei. De multe ori, firmele sunt nevoite
să-şi regândească nu numai modul în care îşi desfăşoară activităţile, dar şi ceea ce ar
trebui să facă pentru a rezista competiţiei. În unele cazuri, firmele de producţie se
transformă în firme prestatoare de servicii, producătorii primari devin unităţi de
asamblare a componentelor realizate de alţii, se modifică liniile lor de afaceri şi se
reexaminează nevoile clienţilor. Marile firme se lipsesc de propriile divizii şi linii de
producţie, păstrând ceea ce consideră a fi nucleul de bază al afacerii lor;
nevoia creşterii performanţelor aplicaţiilor informatice, funcţionalităţii diferitelor
caracteristici de exploatare sau îmbunătăţirea interfeţelor utilizator. Pe măsură ce
condiţiile economice se schimbă, cerinţele utilizatorilor sunt din ce în ce mai mari, în
ceea ce priveşte extinderea funcţionalităţii sistemelor existente. Creşterea numărului
utilizatorilor de calculatoare şi dezvoltarea aplicaţiilor cu interfeţe grafice schimbă
aşteptările acestora în ceea ce priveşte toleranţa la erori;
necesitatea accesării directe şi într-un timp cât mai scurt a datelor firmei.
Majoritatea utilizatorilor de staţii de lucru sau PC-uri au din ce în ce mai multe date
stocate în fişiere proprii. Datele din aceste fişiere provin din informaţii prelucrate de
utilizator, sunt transferate de pe calculatorul lui pe alt calculator, cu ajutorul
diferiţilor suporţi de stocare, al diferitelor mecanisme de transfer al fişierelor. Aceste
transferuri sunt mari consumatoare de timp şi destul de greoaie. De aceea, utilizatorii
doresc un acces la date mult mai performant;
38 ANALIZA SISTEMELOR INFORMAŢIONALE
1. Hoffer, J.A., George, J.F., Valacich, J.S. – Modern Systems Analysis and Design, The Benjamin/Cummings
Publishing Company, Inc., Menlo Park, 1996, p. 22.
INTRODUCERE ÎN DEZVOLTAREA SISTEMELOR INFORMAŢIONALE 39
2. Martin, J. – Rapid Application Development, Macmillan Publishing Company, New York, 1991.
3. Royce, W.W. – „Managing the Development of Large Software Systems”, in Proceedings of IEEE, WESTCON,
San Francisco, 1970. Reprinted in Proceedings of the 9th International Conference on Software Engineering,
Monterey, 1987, pp. 328-338.
40 ANALIZA SISTEMELOR INFORMAŢIONALE
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
benefice ale acesteia, ca şi posibilităţile de revenire la etape anterioare. Modelul este redat în
fig. 3.1.
Modelului i se recunosc unele avantaje, cum ar fi:
un control total asupra fazelor, în sensul că ele sunt ordonate şi, firesc, previzibile, prin
evidenţierea clară a ariei de întindere a fiecărei etape sau subcomponentă 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ă).
Definirea
cerinţelor
Analiza
Proiectarea
Implementarea
Testarea
Utilizarea şi
întreţinerea
3.1.2 Modelul V
Modelul V este, aşa cum am menţionat anterior, 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 etapele 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.
INTRODUCERE ÎN DEZVOLTAREA SISTEMELOR INFORMAŢIONALE 41
Modelul, redat în figura 3.2, punctează cu mai multă claritate separările dintre ceea ce
implică participarea utilizatorului, modelul arhitectural şi cel al implementării. Utilizatorul este
implicat doar în fazele din partea superioară a V-ului. Arhitectura sistemului este surprinsă în
partea de mijloc a literei, iar partea inferioară a ei se referă la faza de implementare, care ar
putea consta fie din asamblarea componentelor software, fie din codificarea unor componente.
Definirea
Validare
cerinţelor
Proiectare Testare
sistem sistem
Proiectare Testare
subsistem subsistem
(componentă) (componentă)
Codificare/
asamblare
componente
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 lipsind elementele necesare
descompunerii întregului;
componentele pot fi realizate numai după ce întregului sistem i se defineşte arhitectura,
totul derulându-se după principiile metodei top-down, ceea ce înseamnă încă o
condiţie: 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.
Proiectare
Definirea componentă-1 Instalare
cerinţelor componentă-1
Arhitectura
sistemului
Proiectare Instalare
componentă-n componentă-n
Implementare Întreţinere
componentă-n componentă-n
*
* *
În privința modelelor ciclului de viaţă al dezvoltării sistemelor, se pot trage unele
concluzii, după cum urmează:
modelele sunt diferite, în funcţie de tehnologiile folosite în procesul de realizare a
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;
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 sistemului (în întregime sau
pe părţi componente);
î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 sistemului se va reflecta, î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.
INTRODUCERE ÎN DEZVOLTAREA SISTEMELOR INFORMAŢIONALE 43
5. Satzinger, J.W., Jackson, R.B., Burd, S.D. – Systems Analysis and Design in a Changing World, Second Edition,
Course Technology, Thomson Learning, Boston, 2002, pp. 74-75.
44 ANALIZA SISTEMELOR INFORMAŢIONALE
dezvoltarea sistemelor, pentru că ei, de obicei, îşi au propriile reprezentări pe care nu toţi
ceilalţi le înţeleg.
Modelele, ca şi componentele sistemului, pot fi create cu ajutorul instrumentelor, regăsite,
adesea, sub formă de programe. Cele mai simple oferă facilităţi de realizare grafică a
diagramelor, iar aplicaţiile complexe includ depozite de metadate despre etapele parcurse
pentru dezvoltarea sistemelor, cum ar fi descrieri ale fluxurilor de date, proceselor de
prelucrare, scheme ale bazelor de date etc.
Programatorii au şi ei la îndemână suficiente instrumente ce le sprijină activitatea, cele
mai noi asigurând inclusiv generarea codului aplicaţiilor, reverse-engineering-ul, depanarea
programelor etc.
Dar cele mai cuprinzătoare instrumente disponibile pentru specialiştii în dezvoltarea
sistemelor sunt cele de tip CASE (Computer Assisted/Aided Software/Systems Engineering),
care sprijină crearea celor mai importante modele ale unui sistem informaţional, inclusiv
verificarea automată a completitudinii şi corectitudinii lor, precum şi generarea schmei bazei
de date și/sau a codului programelor pentru modelele dezvoltate.
Atât instrumentele automatizate, cât şi cele manuale se bazează pe o serie de tehnici, adică
o colecţie de recomandări ce vin în sprijinul dezvoltatorilor pentru desfăşurarea activităţilor
specifice. O tehnică include instrucţiunile care trebuie să fie urmate pas-cu-pas în crearea unui
model sau sfaturi generale privind, de exemplu, modul de culegere a cerinţelor de la utilizatorii
sistemului. În această categorie se includ tehnicile de intervievare a utilizatorilor, de modelare
a datelor, de testare a softului, de proiectare a bazelor de date relaţionale etc.
Uneori, o tehnică poate face referire la o întreagă etapă a ciclului de viaţă şi include
câteva modele, iar altele fac referire doar la un model sau la documentaţia sistemului.
Se poate spune că o metodologie cuprinde o colecţie de modele, instrumente şi tehnici
utilizabile în fiecare din etapele ciclului de dezvoltare al sistemului. Ca în aproape orice
domeniu, specialiştii sistemelor informaţionale apelează la instrumente software ce îi sprijină
în desfăşurarea multora dintre activităţile care se pretează la automatizare.
Existenţa unei mari varietăţi de modele, instrumente, inclusiv metodologii, poate crea
confuzii, în special, pentru cei care sunt noi în domeniu. Uneori, se pare că fiecare firmă îşi are
propria abordare a dezvoltării sistemelor informaţionale, iar în cadrul aceleiaşi firme se poate
întâmpla ca echipele de specialişti să folosească metodologii diferite. Însă, ei trebuie să fie
familiarizaţi cu cele mai utilizate şi cunoscute metodologii de dezvoltare, motiv pentru care
prezentăm, în continuare, câteva dintre caracteristicile esenţiale ale acestora.
Metodele ar putea fi grupate, prin prisma celor mai mulţi autori, astfel:
metode orientate spre funcţii, numite şi metode ale descompunerii funcţionale;
metode orientate spre fluxuri de date, deci metode orientate spre procese, deoarece
diagramele fluxurilor de date se întrebuinţează pentru descrierea proceselor;
metode orientate spre informaţii sau date, orientate-informaţii, probabil şi datorită
popularizării puternice a ingineriei informaţiei a lui James Martin, dar şi a diagramelor
entitate-relaţie ale lui Chen;
metode orientate-obiect.
Pe de altă parte, considerăm că este destul de motivată şi o grupare de genul:
metode empirice, nefundamentate sistemic;
metode orientate spre sistem, în care ar fi incluse metodele orientate spre funcţii,
procese şi informaţii sau date;
metode orientate-obiect.
Dar, în acelaşi timp, şi metodele orientate-obiect ar putea fi incluse în categoria metodelor
sistemice, ca şi cele orientate spre funcţii, procese sau spre date/informaţii, pentru că sistemul
este văzut prin prisma funcţiilor, proceselor, datelor sau obiectelor componente.
INTRODUCERE ÎN DEZVOLTAREA SISTEMELOR INFORMAŢIONALE 45
A.
IDENTIFICAREA ŞI
SELECŢIA PROIECTULUI
MICROANALIZA
B. INIŢIEREA ŞI
PLANIFICAREA
PROIECTULUI
FA
ZE
LE
C.
CI
CL
ANALIZA
UL
UI
D
EV
IA
ŢĂ
AL
D.
DE
TREI ACTIVITĂŢI PRINCIPALE
PROIECTAREA LOGICĂ
ZV
OL
T
ĂR
II
SIS
E.
T
EM
PROIECTAREA FIZICĂ
E LO
R
F.
IMPLEMENTAREA
G.
ÎNTREŢINEREA
După ce planul iniţial al proiectului a fost finalizat, se merge mai departe cu etapa de
analiză, prin care se urmăreşte identificarea şi documentarea cerinţelor funcţionale şi
nonfuncționale ale noului sistem. Cuvintele cheie ale acestei etape sunt identificare şi
înţelegere6, care presupun studierea sistemului existent, determinarea cerinţelor pentru noul
sistem, ierarhizarea cerinţelor, generarea şi evaluarea variantelor de proiectare, elaborarea
documentaţiei de analiză, evaluarea proiectului şi soluţiilor identificate pentru a obţine
aprobarea necesară continuării cu etapa de proiectare.
Culegerea informaţiilor se desfăşoară pentru a înţelege cât mai bine domeniul problemei,
nevoile informaţionale ale utilizatorilor, cunoaşterea în detaliu a modului în care funcţionează
actualul sistem, în sensul identificării celor 5 C7:
1. Ce persoane sunt afectate de actualul şi noul sistem?
2. Ce activităţi economice realizează fiecare dintre persoanele identificate?
3. Care este mediul în care se desfăşoară activităţile economice?
4. Care sunt momentele în care au loc procesele de prelucrare a datelor generate de
activităţile economice?
5. Ce presupune realizarea procedurilor din sistemul curent?
Din obţinerea răspunsurilor la cele cinci întrebări se poate identifica modul cum
funcţionează actualul sistem, scopul lui, punctele tari care trebuie păstrate în noul sistem şi
cele slabe care ar trebui eliminate sau înlocuite.
Analiza sistemului este o activitate esenţială în aflarea situaţiei existente şi a ceea ce se
doreşte în viitor. Informaţiile privind sistemul curent şi cerinţele pentru noul sistem se pot
obţine prin intermediul mai multor tehnici, cum ar fi observarea a ceea ce fac utilizatorii,
intervievarea lor sau sondarea pe bază de chestionare, analiza documentelor şi a procedurilor
de lucru, a regulilor economice şi a responsabilităţilor fiecărui loc de muncă care este
influenţat sau influenţează funcţionarea sistemului, a documentaţiei sistemul informatic
existent. Pe lângă utilizatorii sistemului, este necesar să se culeagă informaţii şi de la alte
persoane interesate, respectiv reprezentanţii conducerii tactice şi strategice, partenerii de
afaceri, finanţatorii proiectului. De asemenea, se poate apela şi la ceea ce se întâlneşte sub
denumirea de metode moderne de culegere a cerinţelor, respectiv sesiunile JAD (Joint
Application Design), sistemele de sprijinire a grupurilor de lucru, prototipizarea şi RAD (Rapid
Application Development).
Dar nu este suficientă simpla culegere a informaţiilor. Analiştii trebuie să le revizuiască,
analizeze şi structureze astfel încât cerinţele noului sistem să fie uşor înţelese. Această
activitate este cunoscută sub numele de structurarea cerinţelor şi implică construirea unor
modele specifice: modelul proceselor, modelul logicii proceselor şi modelul conceptual al
datelor.
Obiectivul creării modelelor este de a transpune sub formă de diagrame principalele
componente ale sistemului (procese de prelucrare, intrări, ieşiri, locuri de stocare a datelor). Pe
baza lor se construieşte un aşa-zis dicţionar (depozit) al metadatelor, prin care sunt surprinse
toate detaliile privind elementele regăsite în diferitele modele create. De exemplu, se descrie
formatul fluxurilor de date (tipul atributelor pe care le conţin, mărimea lor, momentul în care
se obţin sau sunt supuse proceselor de prelucrare ş.a.m.d.).
Atunci când apar restricţii de fonduri sau resurse, unele cerinţe identificate nu vor putea fi
cuprinse în noul sistem, ceea ce înseamnă că echipa de dezvoltare, împreună cu utilizatorii şi
reprezentanţii conducerii, trebuie să stabilească o ierarhie a lor, iar, mai departe, se identifică
diferite soluţii de proiectare a sistemului: dezvoltarea în interiorul firmei, cumpărarea unui
pachet software existent pe piaţă, externalizare. Soluţiile sunt supuse atenţiei conducerii,
urmând să fie aleasă cea care răspunde cel mai bine analizelor cost/beneficiu.
În finalul etapei de analiză, se pregăteşte o documentaţie necesară proiectării, prin care
sunt surprinse toate aspectele privind modul de funcţionare a sistemului curent, căror nevoi şi
cerinţe trebuie să răspundă noul sistem, ce funcţii trebuie să cuprindă şi ce obiective trebuie să
sprijine.
În etapa de proiectare logică se urmăreşte dezvoltarea arhitecturii sistemului, pregătirea
specificaţiilor de proiectare a ieşirilor, intrărilor, bazelor de date, interfeţelor-utilizator,
controalelor şi procedurilor de realizare a copiilor de siguranţă, programelor etc., independent
de platformele pe care urmează să fie instalat sistemul. Aceste activităţi se bazează pe
utilizarea informaţiilor culese şi a modelelor create în timpul analizei.
Utilizatorii sunt acele persoane care vor interacţiona direct şi în mod curent cu sistemul,
putând fi angajaţii firmei, managerii sau partenerii firmei. Utilizatorii au diferite roluri în
timpul proiectului:
sunt cei care explică modul de funcţionare a sistemului curent şi formulează nevoile şi
cerinţele informaţionale pentru cel nou;
participă la evaluarea rezultatelor fiecărei etape din ciclul de dezvoltare al sistemului,
oferind feedback-ul de care au nevoie specialiştii pentru completarea, modificarea sau
înţelegerea mai bună a ceea ce trebuie să facă sistemul;
controlează şi monitorizează periodic evoluţia proiectului;
participă la testarea sistemului.
Pentru sistemele complexe, în care investiţiile şi valoarea dezvoltării sistemului sunt mari,
este benefic să existe în echipă şi un reprezentant al managementului strategic sau tactic,
pentru că un prim semnal de acceptare a noului sistem vine de aici. Din acest punct de vedere,
cel mai important rol al conducerii este de a sprijini şi încuraja proiectele de dezvoltare a
sistemelor şi de aliniere a lor la strategiile firmei. De asemenea, ei participă la stabilirea
scopului şi obiectivelor sistemului, analiza performanţelor înregistrate de departamentul
informatic, selectarea proiectelor propuse şi a politicilor privind luarea celor mai importante
decizii legate de dezvoltarea sistemelor.
Din punct de vedere al calităţii de utilizatori ai sistemului, managerii participă la definirea
cerinţelor informaţionale pentru proiectele departamentelor pe care le coordonează, asistă
analiştii în estimarea costurilor şi beneficiilor, alocă membrii-cheie în echipele de dezvoltare a
sistemelor, ca şi fondurile necesare dezvoltării şi exploatării lor.
Din categoria specialiştilor în dezvoltarea sistemelor informaţionale, echipa proiectului ar
putea avea în componenţă analişti de sistem, proiectanţi, programatori, administratori de reţea.
Analiştii de sistem, în prima etapă a ciclului de viaţă, participă la identificarea
oportunităţilor şi obiectivelor sistemului, după care determină cerinţele informaţionale ale
utilizatorilor şi asigură modelarea acestora cu ajutorul diferitelor tehnici pe care le au la
dispoziţie. Ei sunt cei care trebuie să asigure cele două concepte de bază ale etapei de analiză:
identificare şi înţelegere. De capacitatea lor de a surprinde toate aspectele relevante ale
sistemului curent şi ale celui nou, de a înţelege modul de funcţionare, depind celelalte etape de
dezvoltare şi, ca urmare, succesul implementării şi exploatării noului sistem. În finalul etapei
de analiză, ei sunt responsabili cu elaborarea specificaţiilor necesare etapei de proiectare.
Pentru că sunt mai apropiaţi de utilizatori, analiştii asigură legătura dintre aceştia şi ceilalţi
specialişti, legătură esenţială pentru reuşita sistemului, pentru că, de cele mai multe ori,
proiectanţii şi programatorii folosesc un limbaj tehnic, ce nu este la îndemâna şi pe înţelesul
utilizatorilor. Acest lucru face mult mai dificilă comunicarea dintre ei şi ar putea să afecteze
reflectarea cerinţelor utilizatorilor în proiectarea şi implementarea a sistemului. Nu în ultimul
rând, analiştii participă la testarea şi conversia sistemului, fiind cei care ştiu cel mai bine
particularităţile domeniului economic căruia sistemul trebuie să-i răspundă, precum şi la
elaborarea documentaţiei finale şi a manualelor de utilizare.
Proiectanţii asigură transpunerea cerinţelor sistemului sub forma procedurilor de
prelucrare, prin apelarea la tehnici şi principii specifice proiectării interfeţelor-utilizator,
bazelor de date, programelor. Tot ei sunt cei care proiectează procedurile de control şi de
asigurare a securităţii sistemului, realizând şi specificaţiile necesare etapei de implementare.
Calitatea de proiectant poate fi deţinută de proiectanţi ai interfeţelor, administratori şi
proiectanţi de baze de date, chiar şi de către analiştii de sistem.
Programatorii modifică sau dezvoltă programele pentru satisfacerea cerinţelor
utilizatorilor, preluând specificaţiile de proiectare pentru a dezvolta arhitectura programelor şi
pentru scrierea efectivă a codului sursă al acestora, apelând la limbaje de programare
convenţionale, la generatoare de coduri sau la limbaje orientate-obiect. De asemenea, ei
participă la activităţile de testare pentru a se asigura că programele rulează fără erori sau că nu
INTRODUCERE ÎN DEZVOLTAREA SISTEMELOR INFORMAŢIONALE 51
au fost omise anumite funcţii sau proceduri. Un rol important le revine în timpul exploatării şi
întreţinerii sistemului, atunci când trebuie să intervină pentru eliminarea anumitor erori
neidentificate până la exploatarea sistemului, îmbunătăţirea unor componente sau adăugarea
unora noi.
Administratorii de reţea sunt implicaţi în dezvoltarea arhitecturii sistemului, în situaţia în
care acesta presupune o extindere la nivelul întregii organizaţii, participând la etapa de
proiectare, prin definirea proiectului de reţea, la etapa de implementare, asigurând configurarea
reţelei necesare rulării programelor şi exploatării bazelor de date în regim distribuit, astfel
încât să se asigure accesul utilizatorilor la informaţiile solicitate şi la care au drept de acces,
indiferent de poziţia lor geografică.
În sinteză, activităţile la care participă membrii echipei de dezvoltare a sistemului sunt
redate în tabelul 4.1.
Tabel nr. 4.1 – Implicarea membrilor echipei în dezvoltarea sistemului
Manager Utilizatori
Manager Administrator
Activităţi strategic (inclusiv Analişti Proiectanţi Programatori
proiect reţea
sau tactic stakeholderi)
Identificarea problemelor şi
obiectivelor firmei √ √ √ √
Realizarea planului strategic de
dezvoltare a sistemelor √ √ √ √
informaţionale
Iniţierea şi selectarea
proiectelor √ √ √ √
Planificarea proiectului √ √ √ √
Studierea sistemului existent √ √
Determinarea cerinţelor noului
sistem √ √
Modelarea sistemului √ √
Ierarhizarea cerinţelor √ √ √ √
Generarea şi evaluarea
variantelor strategice √ √ √ √
Elaborarea specificaţiilor de
analiza √ √ √
Proiectarea logică a datelor √ √
Proiectarea interfeţelor şi
formularelor √ √ √
Proiectarea structurii
programelor √ √
Proiectarea arhitecturii
sistemului √ √ √
Proiectarea procedurilor de
control √ √ √
Elaborarea specificaţiilor de
proiectare √ √ √ √
Scrierea programelor √ √
Testarea programelor şi
sistemelor √ √ √ √ √
Conversia sistemului √ √ √ √ √
Instruirea utilizatorilor √ √
Elaborarea documentaţiei şi
manualelor sistemului √ √ √ √ √
Exploatarea şi întreţinerea
sistemului √ √ √ √ √
Modul de implicare a fiecărui membru al echipei de dezvoltare a sistemului va fi prezentat
şi în capitolele ce urmează, atunci când se vor detalia activităţile specifice fiecărei etape şi se
vor descrie tehnicile posibil de utilizat.
52 ANALIZA SISTEMELOR INFORMAŢIONALE
Rezumat
Firmele sunt nevoite să modifice sau să înlocuiască sistemele datorită următoarelor cauze: ca parte
a unui program mai amplu de modernizare a întregului sistem; schimbarea unor aspecte de bază în
responsabilităţile şi activităţile utilizatorilor; redefinirea obiectivelor strategice ale organizaţiei; nevoia
creşterii performanţelor aplicaţiilor informatice, a funcţionalităţii de exploatare sau îmbunătăţirea
interfeţelor-utilizator; necesitatea accesării directe şi într-un timp cât mai scurt a fişierelor firmei;
îmbunătăţirea sistemului pentru valorificarea avantajelor oferite de tehnologiile de ultimă oră.
Sistemele sunt abordate prin prisma ciclului lor de viaţă. Ele apar, se dezvoltă, descresc şi pier sau,
printr-un nou ciclu, se perfecţionează, dând naştere unei alte versiuni sau chiar unui nou sistem. Problema
cea mai importantă o constituie ordinea şi felul în care se parcurg etapele respective, ceea ce în literatura
de specialitate se abordează sub numele de modele ale ciclului de viaţă al dezvoltării sistemelor. Dintre
acestea, cele care şi-au pus cu adevărat amprenta asupra evoluţiei modului de dezvoltare a sistemelor
sunt: cascadă, modelul V, incremental, spirală, evolutiv, tridimensional, modelul X, fântână arteziană,
pinball, minge de baseball sau dezvoltarea concurentă, piramidă.
Ciclul de viaţă al dezvoltării sistemelor oferă un cadru general pentru procesul de dezvoltare, dar el
presupune cunoaşterea mult mai multor elemente decât etapele din care este alcătuit, elemente care fac
referire la metodologii, modele, instrumente şi tehnici, de a căror înţelegere depinde modul de derulare a
activităţilor specifice ciclului de viaţă.
Plecând de la prezentarea opiniei mai multor autori, considerăm că metodele de abordare a
sistemelor ar putea fi grupate astfel: metode orientate spre funcţii; metode orientate spre fluxuri de date;
metode orientate spre informaţii sau date, orientate-informaţii; metode orientate-obiect.
Dezvoltarea sistemului începe prin identificarea unei probleme, a oportunităţilor care impun un
astfel de proces, precum şi prin stabilirea obiectivelor noului sistem, urmând planificarea fiecărei
activităţi şi a resurselor solicitate, ceea ce se constituie în aşa-numita microanaliză a sistemului, după care
au loc celelalte etape specifice dezvoltării propriu-zise, respectiv analiza, proiectarea, implementarea,
exploatarea şi întreţinerea.
Întrebări recapitulative
1. Definiţi ciclul de viaţă al dezvoltării sistemelor informaţionale.
2. Care este diferenţa dintre un model şi un instrument? Dar între tehnică şi metodologie?
3. Care sunt obiectivele urmărite prin fiecare etapă a ciclului de viaţă al sistemelor?
4. Enumeraţi principalii membri ai unei echipe de dezvoltare a unui sistem informaţional.
5. Descrieţi rolul fiecărui membru al echipei de dezvoltare în cadrul principalelor etape ale ciclului de
viaţă.
Probleme de echipă
1. Plecând de la discuţiile cu diverse persoane din firmă, încercaţi să identificaţi ce metodologie
folosesc pentru dezvoltarea sistemelor. Aţi observat existenţa unei documentaţii a sistemului
existent?
2. Căutaţi site-uri Web pentru cel puţin 3 firme de consultanţă din domeniul dezvoltării sistemelor
informaţionale. Încercaţi să găsiţi informaţii despre metodologia folosită pentru dezvoltarea
sistemelor. Au descris modelul ciclului de viaţă? Este menţionat pe site dacă folosesc instrumente
care să le automatizeze anumite activităţi din ciclul de dezvoltare?
3. Într-o zi, Noulescu şi-a parcat maşina şi mergea spre biroul său din Universitate. Se simţea bine
pentru a-şi începe activitatea de analist de sistem, urmând să se întâlnească cu alţi salariaţi ai
departamentului informatic.
Ajungând în birou, Noulescu este întâmpinat de Analescu, având următorul dialog:
Analescu: „Am fost desemnaţi să lucrăm ca analişti pentru un nou proiect. Am să-ţi spun toate
detaliile şi apoi vom merge prin clădire”.
Noulescu: „Sună bine. De cât timp lucrezi aici?”
INTRODUCERE ÎN DEZVOLTAREA SISTEMELOR INFORMAŢIONALE 53
Analescu: „De aproape 5 ani. Am început ca analist-programator, dar în ultimii ani m-am dedicat
analizei şi proiectării. Sper să găsim câteva soluţii de creştere a productivităţii pentru departamentul
de informatică”.
Noulescu: „Spune-mi ceva despre noul proiect”.
Analescu: „Ca multe alte organizaţii, avem un număr foarte mare de calculatoare, cu diferite
programe instalate. În anii '90 erau doar câteva microcalculatoare şi câteva programe, dar numărul
lor a crescut în ultimii ani. Sistemul curent folosit pentru întreţinerea softului şi hardului e complet
depăşit”.
Noulescu: „Dar despre utilizatori ce poţi spune? Pe cine ar trebui să cunosc? Ce crezi că ar fi
important pentru noul sistem?”
Analescu: „Te vei întâlni cu fiecare, dar sunt câteva persoane-cheie cu care am discutat deja şi am
să-ţi spun ce am constatat, pentru a şti câte ceva despre fiecare atunci când te vei întâlni cu ele.
Informaticescu este directorul departamentului informatic. Pare că se poate lucra foarte bine cu el.
Este foarte competent şi e potrivit pentru îmbunătăţirea comunicării dintre utilizatori şi analişti”.
Noulescu: „Va fi o plăcere să-l cunosc”.
Analescu: „Apoi este Calculatorescu, expert în întreţinerea calculatoarelor. Este un tip drăguţ, dar
foarte ocupat. Va trebui să-l ajutăm să scape de supraîncărcarea cu care se confruntă. Pe partea de
întreţinere a softului este Softulescu, fire libertină şi puţin cam zăpăcit, dar nu mă înţelege greşit, îşi
cunoaşte foarte bine meseria”.
Noulescu: „Pare distractiv să lucrezi cu el”.
Analescu: „Ar putea fi. Te vei întâlni, de asemenea, cu responsabilul financiar, Finanţescu, cu
care încă nu am avut nici o discuţie”.
Noulescu: „Cred că te pot ajuta eu cu ceva în sensul ăsta”.
Analescu: „În final, ar trebui să te întâlneşti cu Prelucrărescu, care coordonează activitatea de
prelucrare a datelor şi care e dispus să lucreze cu noi pe tot parcursul proiectului de dezvoltare a
noului sistem de întreţinere”.
Noulescu: „Sună promiţător”.
Se cere să se identifice, din conversaţia anterioară, rolul pe care ar putea să-l aibă fiecare
persoană descrisă.
CAPITOLUL IV
Dezvoltarea sistemelor este iniţiată, aşa cum am mai specificat, atunci când noul sistem
este parte a planului strategic al firmei, ce vine în sprijinul atingerii obiectivelor generale ale
acesteia, sau ca răspuns la o nevoie imediată legată de o problemă de prelucrare, de obţinerea
unor beneficii din exploatarea oportunităţilor apărute în mediul de afaceri etc.
Iniţiativele de dezvoltare a sistemului pot veni de la orice nivel al firmei şi pot fi
planificate sau nu, în funcţie de politicile şi regulile existente, de complexitatea proiectului, de
urgenţa rezolvării unei probleme. Însă, trebuie avut în vedere faptul că planificarea riguroasă şi
implicarea managerială permit susţinerea planului strategic al firmei. De aceea, este important
ca fiecare firmă, pentru eficientizarea şi îmbunătăţirea condiţiilor de competitivitate, să aibă
planuri strategice atât pentru atingerea obiectivelor generale ale organizaţiei, cât şi pentru
dezvoltarea sistemelor informaţionale. De fapt, planul strategic al sistemelor informaţionale
este parte integrantă din planificarea strategică a firmei.
Odată dezvoltat planul strategic, urmează identificarea potenţialelor proiecte de dezvoltare
a sistemelor, ce vor fi supuse ierarhizării şi selecţiei, moment în care se trece la iniţierea şi
planificarea proiectului ales pentru a fi derulat în perioada următoare.
În etapa de microanaliză a sistemului, ca de altfel pe tot parcursul dezvoltării sistemului,
un proces esenţial în asigurarea succesului implementării îl reprezintă managementul
proiectului.
mult, unele dintre activităţi pot să nu fie necesare (sau ele să fi fost deja realizate), dacă în
cadrul organizaţiei există o planificare strategică din care să rezulte cerinţele informaţionale
ale organizaţiei, care să se concretizeze în definirea unui plan al sistemului informatic.
1. complet manuale;
2. parţial manuale şi parţial informatizate;
3. informatizate complet, cu următoarele patru subtipuri:
a. modificări minore ale sistemului, de genul rescrierii aplicaţiilor cu ajutorul altor
limbaje de programare;
b. îmbunătăţirea şi întreţinerea sistemului;
c. reproiectarea şi redezvoltarea sistemului.
Tabel nr. 4.1 – Identificarea potenţialelor probleme la nivelul firmei şi al sistemului informaţional
Mod de identificare Simptome ale apariţiei problemelor
Compararea rezultatelor cu Prea multe erori
performanţele dorite Activităţi derulate într-un timp mai mare decât ar fi normal
Activităţi generatoare de date eronate, incomplete
Activităţi nefinalizate
Cauzele pot fi identificate prin evaluarea periodică a sistemului, iar problemele pot să fie
ridicate de către utilizatori, conducere sau de către un compartiment specializat în sisteme
informatice.
O astfel de problemă poate fi supusă atenţiei, formal sau informal, celor îndreptăţiţi să ia
decizii în privinţa dezvoltării sistemelor. Calea informală (de obicei, verbală) este urmată de
cele mai multe ori de o cerere formală, adică a unui memoriu sau a unei cereri scrise. Indiferent
de forma luată, ea trebuie să conţină numele celui care solicită, natura solicitării (fie natura
problemei economice care trebuie rezolvată, fie tipul serviciului solicitat), motivul solicitării,
precum şi timpul în care se doreşte rezolvarea problemei. Cererea trebuie, de asemenea, să aibă
semnăturile persoanelor autorizate, informaţii privind sursa de finanţare a proiectului şi oricare
alte elemente ce scot în evidenţă prioritatea solicitării.
Este de preferat ca nici un proiect să nu fie propus fără aceste informaţii. Deşi structura
solicitării poate să varieze, conţinutul unei cereri de dezvoltare a sistemului informaţional
trebuie să dea posibilitatea surprinderii următoarelor aspecte:
identificarea, în mod clar, a cauzelor care impun schimbarea;
nominalizarea obiectivelor urmărite;
specificarea avantajelor şi costurilor preconizate;
identificarea finanţatorului şi a celui ce va prelua sistemul la finalizarea lui.
Cererea va fi analizată de compartimentul care se ocupă cu dezvoltarea/ întreţinerea
sistemelor, dacă există, sau de cei care iau decizii în această privinţă şi se va hotărî dacă poate
fi satisfăcută de sistemul existent, cu eventuale mici modificări, sau sunt necesare modificări
majore care impun trecerea la operaţia de analiză a sistemului.
Problema principală a activităţii de identificare a potenţialelor proiecte de dezvoltare
constă în nominalizarea celor ce pot fi abilitaţi să facă propuneri pertinente. Din experienţa
MICROANALIZA SISTEMELOR INFORMAŢIONALE 57
acumulată în practică, rezultă că aceştia pot fi grupaţi în patru categorii distincte, după cum
urmează:
un reprezentant al top-managerilor, fie directorul general al întreprinderilor mici şi
mijlocii, fie un director al întreprinderilor mari;
un comitet de organizare creat cu un scop special de către managerii unor
compartimente interesate;
compartimentele utilizatorilor, fie printr-un şef al grupului solicitant, fie printr-un
comitet de iniţiativă, care decid ce proiecte să fie propuse (Noi, în calitate de analişti,
vom ajuta utilizatorii să-şi formuleze cerinţele!);
un grup de dezvoltare a sistemului sau reprezentantul compartimentului de
informatică.
Caracteristicile esenţiale ale variantelor de proiecte propuse, în cele patru situaţii, sunt
prezentate în tabelul 4.2.
Tabel nr. 4.2 – Variante de propuneri de proiecte
Propuneri Metoda de selecţie Caracteristicile proiectului
a proiectului
orientare puternică spre strategie;
Top-managerii cele mai mari dimensiuni ale proiectului;
cele mai de durată proiecte.
De sus în jos orientare mixtă (a diferiţilor reprezentanţi);
Comitetul de vizează schimbările organizaţionale cele mai mari;
iniţiativă analiză riguroasă a costurilor şi avantajelor proiectelor;
proiecte mai mari şi mai riscante.
limitat, neorientat strategic;
Departamentul realizare mai rapidă;
utilizatorilor câţiva utilizatori reprezintă niveluri ale conducerii,
De jos în sus precum şi funcţiile întreprinderii.
integrare în sistemul existent;
Grupul de
puţine întârzieri în realizarea proiectului;
dezvoltare
mai puţin interesat de analizele cost/beneficii.
NEVOILE RESURSELE
PERCEPUTE ŞI EXISTENTE ŞI
CELE REALE DISPONIBILE
DECIZIA LUATĂ:
•PROIECT ACCEPTAT
•PROIECT RESPINS
•PROIECT AMÂNAT
LISTA DECIZIA DE
PROIECTELOR SELECŢIE A •PROIECT REORIENTAT
POTENŢIALE PROIECTULUI
ŞI ÎN EXECUŢIE •REALIZAT DE
UTILIZATORUL FINAL
•VERIFICAREA/PROBA
PROIECTULUI
MEDIUL
ORGANIZAŢIONAL CRITERII DE
CURENT EVALUARE
PLANIFICAREA
CALENDARISTICĂ A
•EVALUARE PROIECTELOR
•STABILIRE PRIORITĂŢI 1. ….
•PLANIFICARE CALENDARISTICĂ 2. ….
A PROIECTELOR 3. ….
DE JOS ÎN SUS
• DEPARTAMENT UTILIZATORI
• GRUP DE DEZVOLTARE
Situaţia curentă
•Lista prelucrărilor manuale şi automate
Pas 1 •Lista datelor obţinute manual şi automat
•Inventarul tehnologiilor
•Inventarul resurselor umane
Situaţia viitoare
•Planul prelucrărilor manuale şi automate
Pas 2 •Planul datelor obţinute manual şi automat
•Planul tehnologiilor
•Planul resurselor umane
Pas 3
B
C
...
1 2 3 4 5 ... 15
funcţionari.
Funcţiile se pot regăsi în întreaga unitate şi ele se exercită în cadrul activităţilor zilnice,
cum ar fi: aprovizionare, producţie, desfacere, personal, cercetare-dezvoltare.
Procesele sunt reprezentate printr-o listă a procedurilor manuale sau automate prin care
sunt exercitate funcţiile întreprinderii, ca de exemplu: prelucrare plăţi, prelucrare încasări,
facturare clienţi, expediţie mărfuri/transport produse ş.a.
Entităţile de date reprezintă componentele altei liste din care să rezulte informaţiile
obţinute, actualizate, şterse sau folosite în procesele de prelucrare.
Sistemele informaţionale vor specifica dacă se folosesc sisteme manuale sau automate
pentru transformarea datelor în informaţii.
Exemplu: Sintetic, plecând de la exemplul anterior, se pot descrie câteva funcţii ale
întreprinderii, entităţile de date şi sistemele informaţionale, astfel:
Funcţii Entităţi de date Sisteme informaţionale
planificare economică client prelucrare salarii
dezvoltare produse produs prelucrare plăţi
marketing şi desfacere vânzător prelucrare creanţe
producţie material prelucrare pontaje
finanţe – contabilitate comandă gestiune stocuri
resurse umane facturi ….
… echipament
…
După identificarea informaţiilor de nivel superior, ele se descompun în părţi mai mici
pentru a înlesni o planificare mai detaliată. De exemplu, funcţiile economice pot fi descompuse
în funcţii ajutătoare. Sub formă de schemă, acest lucru este reprezentat ca în figura 4.4.
Funcţii economice Funcţii ajutătoare
Planificare economică
Analize ale pieţelor
Prognoze vânzări
Dezvoltare produse
Cercetări de marketing
Comenzi onorate
Distribuţie
Producţie
Programare producţie
Fabricaţie
Asamblare
Finisare
Financiar-contabilă
Bugetare capital
Conturi de creanţe
Conturi de plăţi
Resurse umane
Recrutare
Instruire (Training)
Antrenare (Coaching)
Fig. 4.4 Descompunerea funcţiilor economice în funcţii ajutătoare
După alcătuirea listelor menţionate anterior, se construiesc seturi de matrice pentru a
evidenţia legăturile existente între diferitele elemente ale organizaţiei. Matricele tipice sunt:
Amplasare – Funcţie. Se identifică funcţiile întreprinderii executate în diferite locuri
de amplasare a afacerii.
Amplasare – Unitate (componentă) organizatorică. Se identifică toate componentele
organizatorice amplasate într-un anumit loc sau care au legătură cu locul respectiv.
62 ANALIZA SISTEMELOR INFORMAŢIONALE
Prelucrare comenzi
telefonice
Prelucrare comenzi
cataloage
Prelucrare vânzări
amănuntul
Prelucrare salarii
Prelucrare stocuri
Prelucrari
contabilitate
generală
….
Vânzări cu amănuntul
Resurse umane
Contabilitate
generală
Pentru a înţelege mai bine tehnicile specifice dezvoltării sistemelor informaţionale, vom
începe, din acest capitol, prezentarea unui proiect de dezvoltare a sistemului de gestiune a
clienţilor pentru o firmă ABC, producător şi distribuitor de articole de îmbrăcăminte1. Toate
referirile la acest proiect se vor face prin intermediul unor casete. Aşadar, începem cu o prima
casetă, Caseta 4.1, în care facem o trecere în revistă a obiectului de activitate şi a modului de
derulare a activităţilor, pentru a înţelege modul de definire a planului strategic al sistemului
informaţional şi pentru stabilirea obiectivelor de bază ale sistemului de gestiune a clienţilor
(SGC), ca parte a planului strategic.
Caseta 4.1 – Descrierea firmei ABC şi planul strategic al sistemului informaţional
1. Prezentarea generală a firmei ABC
ABC şi-a început activitatea în anul 1990, având ca iniţiatori pe Patronescu şi pe Patroneasca, din
Oraşul 1. Ea a fost întotdeauna pasionată de modă şi îmbrăcăminte, lucrând în timpul facultăţii ca
designer şi vânzător de articole de îmbrăcăminte la magazinele din oraş. El a lucrat câţiva ani la un
depozit de produse de îmbrăcăminte după terminarea facultăţii. Împreună, s-au decis să încerce să
extindă afacerea ei atât din punct de vedere al segmentului de clienţi, cât şi al tipurilor de produse
vândute.
Primul pas l-a constituit dezvoltarea sistemului de vânzări prin poştă pe bază de cataloage de
produse, astfel că Patroneasca a fost nevoită să-şi mărească activitatea de producţie, angajând un creator
de modă şi un director de producţie, care să supravegheze activitatea de pe liniile de producţie. Pe
1. Exemplul se bazează pe modelul prezentat în Satzinger, J.W., Jackson, R.B., Burd, S.D. – Systems Analysis and
Design in a Changing World, Second Edition, Course Technology, Thomson Learning, Boston, 2002.
64 ANALIZA SISTEMELOR INFORMAŢIONALE
măsură ce interesul clienţilor pentru vânzarea prin intermediul cataloagelor a crescut, firma şi-a adăugat
noi linii de produse şi accesorii şi a deschis un magazin propriu în Oraşul 1.
La începutul anului 2000, ABC a devenit unul din cei mai importanţi distribuitori de articole de
îmbrăcăminte în Oraşul 1 şi zonele limitrofe, astfel că firma şi-a dezvoltat liniile de producţie pentru a
răspunde solicitărilor pieţei, iar catalogul de vânzări a luat o nouă formă de prezentare, incluzând o gamă
mult mai variată de produse.
ABC are acum 600 de angajaţi şi vânzări de aproape 10 milioane RON anual. Vânzările prin poştă
deţin ponderea cea mai mare din venituri, aproximativ 6 milioane RON, iar vânzările prin magazinul
propriu nu depăşesc 0,25 milioane RON, în Oraşul 1, şi 0,5 milioane RON în magazinul deschis recent în
Oraşul 2. În anul 1995, ABC a deschis şi o linie de vânzări prin intermediul preluărilor de comenzi
telefonice, din care obţine acum aproximativ 3 milioane RON. Clienţii tradiţionali au considerat acest
serviciu ca o extindere naturală a activităţii firmei, însă ABC trebuie să facă o serie de modificări
substanţiale la nivelul sistemului de prelucrare a comenzilor primite în variantă telefonică.
2. Aspecte privind strategia ABC
ABC a fost printre primii distribuitori de articole de îmbrăcăminte pe Web. Iniţial, site-ul a fost
conceput doar pentru îmbunătăţirea imaginii firmei şi pentru a permite potenţialilor clienţi să solicite
catalogul de produse şi pe această cale. De asemenea, a servit ca un portal pentru a asigura legătura cu
principalele evenimente şi festivaluri de modă. Prima îmbunătăţire a site-ului a constat în adăugarea de
informaţii suplimentare pentru fiecare produs, inclusiv oferte speciale ce puteau fi comandate prin
telefon. Apoi a fost făcut disponibil on-line catalogul de produse, însă clienţii, în continuare, pot să-şi
formuleze comenzile numai prin poştă sau telefon.
Proprietarii firmei au fost de acord să încerce dezvoltarea comerţului electronic B2C, dar
Patroneasca era îngrijorată în privinţa riscului de creştere neaşteptată a cererilor de produse, ştiind că
mulţi producători şi distribuitori mici nu au făcut faţă prelucrărilor on-line şi onorării la timp a
comenzilor. O proastă gestionare a stocurilor, servicii necorespunzătoare, neacceptarea returnării
produselor, emiterea de facturi duble către acelaşi client au fost câteva dintre aspectele care au fost
identificate ca potenţiale riscuri.
Cei doi au recunoscut potenţialul pe care îl poate oferi comerţul electronic, dar voiau să facă cu
prudenţă ceea ce trebuia făcut şi să nu treacă la acţiune peste noapte, fără nici un plan sau o strategie. Ei
au apelat întotdeauna la planuri şi cunosc foarte bine care este impactul tehnologiilor asupra firmei, astfel
încât au dorit să acorde atenţia cuvenită noii iniţiative, abordând-o la nivel strategic. De aceea, s-au decis
să analizeze atent întreaga infrastructură tehnologică a firmei şi să creeze un plan strategic de dezvoltare
a sistemului informaţional, apelând, pentru planificarea sistemului, la o firmă de consultanţă. Firma le-a
sugerat să-şi concentreze atenţia asupra a două ţinte strategice:
gestiunea lanţului de aprovizionare, prin care să se asigure procesele necesare integrării
activităţilor de proiectare a produselor, de aprovizionare, producţie şi gestiunea stocurilor.
gestiunea relaţiilor cu clienţii, prin care să se dezvolte procesele de sprijinire a activităţilor de
marketing, vânzări şi servicii oferite clienţilor, implicând interacţiunea directă sau indirectă cu
aceştia.
Ambele strategii sprijină firmele, în special comercianţii cu amănuntul, prin eficientizarea
activităţilor de vânzare şi asistenţă a clienţilor.
În planul strategic al sistemului informaţional au fost incluse două componente:
1. planul arhitecturii aplicaţiilor, detaliindu-se proiectele de dezvoltare a sistemului pe care
firma trebuie să le pună în practică;
2. planul arhitecturii tehnologice, descriind infrastructura fizică necesară funcţionării sistemului.
Ambele componente au la bază obiectivele privind gestiunea lanţului de aprovizionare şi a relaţiilor
cu clienţii, definite pentru următorii 5 ani.
3. Structura organizatorică a firmei
ABC se bazează foarte mult pe acţiunile şi controlul proprietarilor ei. Patronescu este preşedintele
consiliului de administraţie, iar Patroneasca directorul cu distribuţia. Ceilalţi top-manageri sunt:
Vânzărescu, director de vânzări şi marketing, Economescu, director economic. Departamentul informatic
este subordonat şi raportează directorului economic. Structura organizatorică este redata în figura C4.1.
Sunt 113 salariaţi care lucrează la departamentele merchandising/distribuţie, resurse umane,
financiar-contabil, vânzări şi marketing, informatică la sediul central al firmei din Oraşul 1. Există două
magazine de desfacere, în Oraşul 1 şi Oraşul 2. Secţiile de producţie sunt localizate în Oraşul 1 şi, mai
MICROANALIZA SISTEMELOR INFORMAŢIONALE 65
recent, în Oraşul 2. De asemenea, firma dispune de 3 depozite: Oraşul 1, Oraşul 2, Oraşul 3. Prelucrarea
comenzilor primite prin poştă este asigurată de 58 de salariaţi, aflaţi într-un alt corp de clădire din Oraşul
1. Centrul de preluare a comenzilor telefonice are 20 de angajaţi, fiind situat lângă clădirile în care sunt
liniile de producţie din Oraşul 1.
Preşedinte
Patronescu
Director departament
Şef achiziţii interne Şef birou cataloage
informatică
Achiziţescu Catalogescu
Informaticescu
Şef centru
Şef birou proiectare Şef birou
comenzi telefonice
Conceptescu dezvoltare sisteme
Telefonescu
Dezvoltărescu
planificarea trecerii la o soluţie Intranet, pentru desfăşurarea unor funcţii economice, cum ar fi
resursele umane, financiar-contabilă, sistemul de raportare către conducere;
2. din punct de vedere al aplicaţiilor:
managementul lanţului de aprovizionare: implementarea unui sistem care să integreze
proiectarea produselor, achiziţiile, producţia şi gestiunea stocurilor, pentru a veni în sprijinul
creşterii rapide a vânzărilor. Dezvoltare internă.
sistemul de gestiune a clienţilor: implementarea unui sistem de prelucrare şi onorare a
comenzilor care să fie integrat cu cel de gestiune a lanţului de aprovizionare, astfel încât să se
asigure prelucrarea rapidă a comenzilor primite prin cele trei modalităţi (poştă, telefon, Web),
dar cu reflectare imediată în nivelul stocurilor şi planificarea producţiei. Dezvoltare internă.
sistemul de sprijinire a conducerii strategice: implementarea unui sistem informaţional care să
permită extragerea şi analiza informaţiilor privind lanţul de aprovizionare şi gestiunea
relaţiilor cu clienţii în vederea eficientizării procesului decizional operaţional şi strategic, dar
şi pentru efectuarea unui control mai riguros. Soluţie de pe piaţă.
sistemul de gestiune a vânzărilor cu amănuntul: înlocuirea vechiului sistem cu unul care să
permită integrarea cu cel de gestiune a clienţilor. Soluţie de pe piaţă.
sistemul de contabilitate generală: achiziţia unei soluţii de pe piaţă, posibil o aplicaţie Intranet
cu arhitectură client/server.
sistemul de resurse umane: achiziţia unei soluţii, cu arhitectură client/server de tip Intranet,
pentru a asigura un acces eficient la formularele, procedurile şi informaţiile specifice
domeniului funcţional.
Perioadele de timp în care urmează să se implementeze planul privind aplicaţiile sunt prezentate în
tabelul C4.1.
Tabel nr. C4.1 – Perioadele de implementare a aplicaţiilor din planul strategic
Sistemul Perioada Descriere
Gestiunea lanţului de 2004-2005 În curs de finalizare, urmărindu-se integrarea proiectării,
aprovizionare aprovizionării, producţiei şi gestiunii stocurilor.
Sistemul de gestiune a 2004-2005 Urmăreşte implementarea unui nou sistem de prelucrare şi
clienţilor onorare a comenzilor care să poată fi integrat cu cel de
gestiune a lanţului de aprovizionare şi care să sprijine toate
cele 3 modalităţi de preluare a comenzilor: poştă, telefon,
Web.
Sistemul de sprijinre a 2005 Soluţie la cheie, pentru extragerea şi analiza informaţiilor
conducerii strategice din celelalte sisteme, în vederea sprijinirii procesului
decizional atât la nivel strategic, cât şi la nivel operaţional,
pentru efectuarea activităţilor de control.
Sistemul de gestiune a 2005 Soluţie la cheie, care să poată fi integrată cu sistemul de
vânzărilor cu amănuntul gestiune a clienţilor
Sistemul de contabilitate 2005 Soluţie la cheie
generală
Sistemul resurselor 2006 Soluţie la cheie
umane
Celelalte sisteme din plan se vor baza pe alegerea de soluţii la cheie, dar care să corespundă
cerinţelor de integrare ale întregului sistem informaţional al ABC.
În final, se urmăreşte ca întregul sistem să folosească o nouă bază de date distribuită, care să
integreze toate datele firmei.
7. Sistemul de gestiune a clienţilor
Proiectul de dezvoltare a sistemului este cel de gestiune a clienţilor. ABC şi-a concentrat atenţia
asupra clienţilor, orientându-şi activităţile în funcţie de cerinţele acestora. Una din competenţele
strategice ale ABC a fost abilitatea de a dezvolta şi păstra relaţiile de loialitate cu clienţii. Preşedintele
Consiliului de Administraţie a fost la zi, totdeauna, cu cele mai importante aspecte ale activităţilor
desfăşurate de firmă, fiind pe deplin convins că, pentru dezvoltarea eficientă şi competitivă a activităţilor
firmei, atenţia trebuie acordată clienţilor. Chiar dacă în sistemul de gestiune a clienţilor au fost incluse
68 ANALIZA SISTEMELOR INFORMAŢIONALE
creşterea vânzărilor, prin extinderea capacităţilor de vânzare şi marketing, cu ajutorul noului sistem.
Sistemul de gestiune a lanţului de aprovizionare s-a derulat până acum conform planificărilor,
proiectul solicitând câteva activităţi suplimentare, în sensul participării la activităţile de adaptare a
sistemelor specifice a partenerilor ABC, furnizorii tradiţionali, astfel încât să se asigure
compatibilitatea lor. Prima fază a fost realizată conform planului: cerinţele sistemului au fost
definitivate, proiectarea conceptuală finalizată, urmând ca la începutul anului viitor să se treacă la
implementarea noului sistem. Patronescu a stabilit o întâlnire specială cu comitetul executiv al firmei,
pentru a analiza evoluţia proiectelor curente şi pentru a evalua posibilitatea trecerii la cel nou. Înainte de
întâlnire, i-a cerut directorului economic să-i prezinte o analiză financiară detaliată privind bugetul
sistemului la care se lucrează şi previziunile impactului financiar pe care l-ar avea începerea noului
proiect. De asemenea, l-a invitat pe directorul departamentului de informatică pentru evaluarea gradului
de încărcare a personalului din biroul Dezvoltare sisteme şi disponibilitatea de a începe un alt proiect.
După o lungă discuţie, comitetul executiv a decis să se înceapă proiectul acum, chiar dacă nu sunt
suficiente resurse, fiind însă vital pentru ABC să aibă o prezenţă puternică pe Internet. Ca urmare, s-a
hotărât ca directorul departamentului de informatică să înceapă proiectul. Astfel, el s-a întâlnit cu şeful
biroului Dezvoltare sisteme, căruia i-a cerut să stabilească un manager de proiect şi un analist de sistem
cu experienţă pentru demararea proiectului. De asemenea, a solicitat, din partea preşedintelui,
formularea unei cereri prin care să se confirme decizia luată de conducere. Patronescu a început prin
contactarea membrilor comitetului executiv pentru a obţine acceptul lor de participare, în calitate de
membri ai comitetului de supraveghere a proiectului. De asemenea, ştiind cât de importante sunt
obţinerea acceptului şi implicarea utilizatorilor, a căutat să includă utilizatorii cei mai afectaţi de noul
sistem. Directorului departamentului marketing şi vânzări i s-a solicitat să fie finanţatorul proiectului,
din moment ce domeniul lui funcţional este directat vizat, fiind numit preşedintele comitetului de
supraveghere. Ceilalţi membri desemnaţi au fost: şeful biroului cataloage, şeful liniilor de producţie,
preşedintele consiliului de administraţie şi directorul departamentului informatic.
Proiectul a fost demarat prin numirea ca manager de proiect a unei persoane din Biroul Dezvoltare
sisteme, Proiecteasca, angajată de câţiva ani în firmă.
Înainte, ea a lucrat, în calitate de consultant pe sisteme informaţionale, la o firmă de contabilitate.
Conducerea ABC are deplină încredere în calităţile şi abilităţile ei de a conduce proiectul de dezvoltare
a sistemului de gestiune a clienţilor.
Alături de Proiecteasca, a fost inclus în proiect şi Analizescu, un analist de sistem experimentat, ei
lucrând şi la alte proiecte, având stiluri de lucru compatibile. Datorită importanţei proiectului, în echipa
de iniţiere a proiectului au mai fost implicaţi încă 2 analişti de sistem. Figura C4.3 redă o scurtă
prezentare a proiectului, prin care se justifică activităţile preliminare efectuate de echipa de iniţiere a
proiectului.
Nume proiect: Sistem de gestiune a clienţilor
Scop proiect: Creşterea performanţei gestiunii relaţiilor cu clienţii, fiind necesar să includă
toate funcţiile privind activităţile desfăşurate cu aceştia, de la primirea comenzilor, până
la livrare, incluzând aici solicitarea cataloagelor de produse, preluarea comenzilor,
urmărirea lor, livrarea, acceptarea returnărilor, analiza vânzărilor.
Durata: 18 luni de la data iniţierii
Buget aprobat: până la 0,15 milioane RON
Participanţi cheie:
Proiecteasca – manager de proiect, din cadrul Biroului Dezvoltare sisteme, va conduce
întregul proiect.
Dezvoltărescu – şef Birou Dezvoltare sisteme, va superviza activitatea managerului de
proiect, va analiza săptămânal evoluţia proiectului, va participa la şedinţele comitetului
de supraveghere.
Informaticescu – director Departament de informatică, va participa la întâlnirile comitetului
de supraveghere.
Vânzărescu – director Departament Marketing-vânzări, beneficiarul principal al sistemului,
aprobă bugetul şi planurile proiectului, preşedinte al comitetului de supraveghere.
Catalogescu – şef Birou Cataloage, membru al comitetului de supraveghere, va oferi resurse
şi sprijin utilizatorilor sistemului.
Liniescu – şef linii producţie – membru al comitetului de supraveghere.
70 ANALIZA SISTEMELOR INFORMAŢIONALE
stabilesc legăturile cu celelalte sisteme ale firmei sau compartimente, pentru a determina
gradul de complexitate, dar şi nivelul de integrare cu sistemele existente sau cele care urmează
a se dezvolta. Definirea ariei de întindere are ca punct de plecare matricele realizate în timpul
descrierii situaţiei curente, apelându-se, de cele mai multe ori, la realizarea unei diagrame,
numită diagrama de context, cu ajutorul căreia sunt evidenţiaţi principalii utilizatori ai
sistemului şi informaţiile care sunt schimbate între ei şi sistem. Pentru că este momentul în
care echipa defineşte doar scopul sistemului, diagrama va evidenţia numai principalele legături
şi nevoi informaţionale ale altor sisteme sau utilizatori, fără a intra în detalii, concentrându-se
mai mult asupra informaţiilor de ieşire pe care trebuie să le ofere. Despre modelarea sistemului
cu ajutorul unor astfel de diagrame ale fluxurilor de date se va discuta detaliat într-un capitol
viitor, acum fiind prezentată doar o diagramă de context simplificată pentru sistemul de
gestiune a clienţilor (fig. 4.9).
Departament
Departament Vanzari
Marketing
Informatii-clienti-
potentiali
Rapoarte- Rapoarte-de-
privind- performanta
vanzarile
Rapoarte-privind-
onorarea-comenzilor
Comanda-noua
Notificare-produse- Rapoarte-privind- Conducere
returnate 0 vanzarile
Notificare-modificare-
Client date-identificare Sistem de
asistenta a
clientilor Raport-de-activitate
Notificare-
acceptare-comanda
Factura
Comenzi-de-
livrat
Informatii-
privind-
incasarile
Serviciu
Banca transport
După definirea problemei, un membru al echipei a făcut câteva investigaţii preliminare asupra
soluţiilor posibile, prin căutarea de informaţii în reviste de specialitate, pe Internet şi alte surse, pentru
a determina dacă sistemul ar putea fi cumpărat şi instalat cât mai repede posibil. Deşi au fost găsite
câteva soluţii, se pare că nici una nu asigură, în totalitate, caracteristicile sistemului. Ca umare, după
mai multe discuţii la nivelul echipei, s-a decis că cea mai bună variantă este de a desfăşura etapa de
analiză înainte de a lua o hotărâre finală în privinţa soluţiei de adoptat, urmând să se revadă, mult mai
detaliat, posibilităţile existente după finalizarea analizei.
modificările termenelor, activităţilor ş.a. pot fi uşor efectuate şi corelate imediat cu celelalte, în
condiţiile folosirii softului specializat (de exemplu, Microsoft Project).
5. Definitivarea planului de bază al proiectului
Planul de bază reflectă cel mai bine activităţile prestate în cadrul proiectului, precum şi
resursele solicitate. El va fi folosit ca piesă de bază în etapa următoare a proiectului, execuţia,
în timpul căreia proiectul poate fi schimbat, în sensul actualizării lui. Planul de bază conţine
toate documentele obţinute în urma derulării activităţilor specifice etapei de planificare a
proiectului.
Se conturează câteva dimensiuni ale fezabilităţii, care trebuie evaluate prin studiul de
fezabilitate întreprins, incluzând fezabilitatea tehnică, economică, de exploatare (operaţională),
a legalităţii şi a programării în timp.
Fezabilitatea tehnică. Problema fundamentală este: poate fi elaborat şi implementat
sistemul planificat în organizaţia respectivă folosind tehnologia existentă? Aceasta deoarece
progresele tehnologice sunt mai rapide decât posibilităţile unităţilor de a le implementa. Şi încă
o întrebare: oferă unitatea condiţii persoanelor care vor proiecta, implementa şi exploata
sistemul propus?
Fezabilitatea economică. Două probleme de bază apar în acest caz. Prima: justifică
sistemul propus timpul, banii, alte resurse şi costurile necesare pentru a fi implementat? A
doua: are unitatea fondurile necesare pentru elaborarea şi implementarea sistemului, date fiind
cerinţele de capital şi pentru alte proiecte existente? Pentru a răspunde acestor întrebări,
trebuie să fie estimate şi analizate diverse costuri şi beneficii asociate fiecărei variante.
Fezabilitatea economică necesită un tratament, ulterior, complet.
Fezabilitatea organizaţională sau a exploatării porneşte de la o primă întrebare, şi
anume: este posibil ca noul sistem să fie utilizat de către persoanele cărora le este adresat?
Răspunsul poate fi dat numai în condiţiile din întreprindere, de ceea ce se întâmplă cu
persoanele din sistem înainte de implementarea celui nou, în sensul participării efective,
motivate, la realizarea lui, precum şi dorinţa lor de transformare. Se are în vedere reacţia
angajaţilor firmei sau anumite modificări de natură organizatorică posibile sau propuse. Dacă
proiectul are susţinerea conducerii şi a utilizatorilor, noul sistem are toate condiţiile să fie
implementat şi exploatat cu succes. Oricum, schimbarea implică şi o doză de risc. Dintre cele
mai frecvente riscuri care trebuie avute în vedere, enumerăm:
competenţe scăzute în utilizarea calculatoarelor;
fobie generală în privinţa exploatării calculatoarelor;
percepţia pierderii controlului de către salariaţi sau conducere asupra activităţilor
desfăşurate;
potenţiala schimbare a puterii politice şi organizaţionale datorită noului sistem;
teama de modificare a responsabilităţilor ce revin fiecărui loc de muncă;
teama de pierdere a locului de muncă datorită automatizării;
obişnuinţa cu anumite proceduri de lucru.
Este destul de dificil de identificat toate riscurile organizaţionale care ar putea să apară la
nivelul firmei, dar echipa de gestiune a proiectului trebuie să fie foarte atentă pentru a le
identifica din timp şi a le elimina sau atenua efectele dacă ele şi-au făcut deja apariţia.
Fezabilitatea legalităţii urmăreşte să determine dacă se pot înregistra conflicte între
sistemul propus şi anumite obligaţii legale. De asemenea, sistemul trebuie să respecte toate
statutele, deciziile, regulamentele, legile şi alte acte normative şi juridice, atât la nivel local, cât
şi naţional şi internaţional. Pentru aceasta, se analizează scopul sistemului şi se identifică
principalele reglementări ale domeniului economic abordat prin sistem.
Fezabilitatea programării răspunde, în primul rând, la următoarea întrebare: poate fi
proiectat şi implementat sistemul în timpul alocat? Dacă răspunsul este nu, sistemul trebuie să
fie modificat sau va fi luată în studiu o altă variantă, sau data implementării va fi schimbată.
Din nefericire, nici tehnologiile moderne nu aduc o reducere substanţială a timpului de
proiectare şi implementare, motivul fiind posibilităţile de adaptare a personalului la nou.
Rezumat
Dezvoltarea sistemelor este iniţiată atunci când noul sistem este parte a planului strategic al firmei,
ce vine în sprijinul atingerii obiectivelor generale ale firmei, sau ca răspuns la o nevoie imediată, legată
de o problemă de prelucrare, de obţinerea unor beneficii din exploatarea unor oportunităţi apărute în
mediul firmei etc.
MICROANALIZA SISTEMELOR INFORMAŢIONALE 77
Întrebări recapitulative
1. Care sunt modalităţile de identificare a unor noi proiecte de dezvoltare a sistemului?
2. Identificaţi, într-o organizaţie cunoscută, potenţialele persoane care sunt abilitate să propună proiecte
de dezvoltare a sistemelor informaţionale, încadrându-le în una din categoriile descrise anterior.
3. Ce se urmăreşte prin realizarea matricelor din etapa planificării strategice a sistemului?
4. Ce criterii pot fi avute în vedere la ierarhizarea şi selecţia proiectelor de dezvoltare?
5. Enumeraţi cel puţin 3 propuneri de proiecte de dezvoltare a sistemelor informaţionale, ce s-ar putea
regăsi într-o organizaţie cunoscută, şi specificaţi criteriile pe care le-aţi utiliza pentru evaluarea lor.
Motivaţi.
6. Enumeraţi şi descrieţi principalele activităţi desfăşurate în timpul iniţierii proiectului.
7. Care este scopul diagramei de context în etapa de planificare a sistemului?
8. Specificaţi tipurile analizelor de fezabilitate ce trebuie efectuate în timpul planificării proiectului.
9. În ce etape ale ciclului de dezvoltare al unui sistem este necesar să se reia o parte din analizele de
fezabilitate? De ce?
78 ANALIZA SISTEMELOR INFORMAŢIONALE
Probleme de echipă
1. Noul sistem de gestiune a clienţilor şi încasărilor de la Beta constituie un factor esenţial pentru
sprijinirea dezvoltării şi câştigării unui segment cât mai mare pe piaţă.
Componenta de vânzări cu amănuntul a sistemului trebuie să urmărească fiecare vânzare şi să
ofere posibilitatea stabilirii unei legături directe cu sistemul de stocuri, pentru obţinerea de informaţii
privind existenţa produselor în stoc, costurile lor de producţie, astfel încât să se poată genera zilnic
un raport privind beneficiile sau pierderile înregistrate din vânzarea diferitelor produse.
Baza de date a clienţilor trebuie să permită obţinerea istoricului vânzărilor pentru a ajuta
conducerea în formularea unor scrisori speciale şi stabilirea unor acţiuni promoţionale personalizate
pentru fiecare client.
Pentru rezolvarea problemei privind soldul foarte mare al contului de clienţi, sistemul trebuie să
permită obţinerea unor fişe de cont analitice, pe baza lor putând să se transmită conducerii rapoarte
detaliate privind istoricul creditului fiecărui client.
Se cere identificarea principalelor funcţii care ar trebui să fie incluse în noul sistem de gestiune a
clienţilor şi încasărilor.
2. Concepeţi un document pentru descrierea propunerii noului sistem informaţional de gestiune a
clienţilor, plecând de la aspectele identificate la problema 1.
3. Plecând de la studierea misiunii, obiectivelor şi strategiilor, a sistemelor informaţionale şi structurii
organizatorice a unei firme, construiţi principalele matrice din care ar putea fi identificate eventualele
proiecte de dezvoltare a sistemelor şi stabiliţi un plan strategic al sistemelor informaţionale.
CAPITOLUL V
Obiective:
Cunoaşterea caracteristicilor proiectelor de dezvoltare a sistemelor informaţionale
Descrierea componentelor sistemului existent (ieşiri, intrări, stocarea datelor, procese de
prelucrare), pentru identificarea punctelor tari şi slabe din sistem
Înţelegerea evenimentelor la care sistemul trebuie să reacţioneze prin funcţiile de prelucrare,
precum şi a modalităţii de identificare a lor
Prezentarea principalelor activităţi ce se realizează în timpul determinării cerinţelor
Cunoaşterea principalelor surse de identificare a cerinţelor sistemului,
a persoanelor afectate, direct sau indirect, de implementarea noului sistem
Identificarea principalelor categorii de cerinţe ale noului sistem
Dobândirea de cunoştinţe privind modul de întocmire a specificaţiei de analiză,
a criteriilor calitative pe care trebuie să le îndeplinească
1. Satzinger, J.W., Jackson, R.B., Burd, S.D. – Systems Analysis and Design in a Changing World, Second Edition,
Course Technology, Thomson Learning, Boston, 2002, p. 108.
80 ANALIZA SISTEMELOR INFORMAŢIONALE
respecta structura sau sintaxa unui anumit limbaj (aceasta se va realiza într-o etapă
ulterioară, proiectarea);
modelul datelor, realizat prin intermediul diagramelor entitate-relaţie, reliefează
obiectele sau lucrurile din lumea reală, sub forma entităţilor de date, despre care
trebuie păstrate date în cadrul sistemului, o lungă perioadă de timp. Entităţile de date
sunt componentele unui sistem care au cea mai lungă perioadă de viaţă şi sunt cele
mai persistente.
4. Întocmirea raportului analizei de sistem reprezintă sinteza activităţilor anterioare şi va
conţine: lista problemelor şi restricţiile existente în sistemul curent; cerinţele noului
sistem; rezultatele modelării conceptuale; recomandări privind proiectarea noului sistem.
5. Analiza recomandărilor împreună cu reprezentanţii conducerii, care trebuie informaţi
cu privire la evoluţia proiectului, urmărindu-se luarea deciziei de continuare sau nu a
acestuia, alegerea celei mai bune variante de proiectare a sistemului, precum şi aprobarea
bugetului şi planurilor calendaristice revizuite pentru finalizarea proiectului.
2. Modell, M. – A Professional’s Guide to Systems Analysis, Second Edition, McGraw-Hill Company, New York,
1996, pp. 20-36.
82
Tabel nr. 6.1 – Caracteristicile proiectelor de dezvoltare a sistemelor din perspectiva analizei
Tipul Diferenţe privind analiza
proiectului Elementele supuse analizei Responsabilităţi Rezultatele analizei Factori declanşatori
Modificare - Prelucrările manuale - Simplificarea fluxului - Standarde/proceduri noi - Întârzieri în prelucrări
sistem manual - Fluxurile şi etapele prelucrărilor informaţional - Reguli de performanţă - Noi forme de raportare
- Rezultatele prelucrărilor - Reducerea redundanţelor - Noi formulare, proceduri de - Flux greoi al documentelor
- Reordonarea prelucrărilor control, rapoarte - O nouă formă
- Conţinutul formularelor - Noi prelucrări sau fluxuri organizaţională
Informatizare - Modalităţile de înlocuire a - Impactul componentelor - Noi formulare de introducere a - Costurile mari ale prelucrării
sistem/ prelucrărilor manuale manuale asupra celor datelor manuale
componente - Procesele şi procedurile manuale automate - Stabilirea conţinutului - Erori în prelucrarea datelor
- Interacţiunea dintre fişierelor - Creşterea duratei de obţinere
Îmbunătăţire/ - Domeniile de lucru ale - Adăugări de noi funcţionalităţi - Reproiectarea logicii - Modificări în mediul
Întreţinere utilizatorilor - Identificare interdependenţe cu aplicaţiilor economic
- Legăturile cu alte sisteme alte aplicaţii ce folosesc - Modificarea structurii bazei de - Solicitări ale utilizatorilor
- Structura programelor aceeaşi bază de date date; pentru noi funcţionalităţi
ANALIZA SISTEMELOR INFORMAŢIONALE
Reproiectare/ - O nouă analiză a întregului - Analiza nevoilor utilizatorilor - Reproiectarea procedurilor; - Migrarea de la o tehnologie
Redezvoltare sistem - Identificarea şi eliminarea - Conversia bazelor de date; la alta
problemelor ce apar odată - Reintegrarea sistemului - Trecerea de la prelucrarea pe
noile tehnologii reproiectat în sistemul firmei. loturi la cea online
- Convingerea conducerii de - Restructurarea
necesitatea redezvoltării organizaţională
Deşi este o activitate distinctă în cadrul analizei, studierea sistemului existent este foarte
asemănătoare, ca tehnică de lucru, cu determinarea cerinţelor noului sistem, însă specialiştii îşi
condiţiile în care sistemul curent este înlocuit în totalitate, analiştii au nevoie de informaţii
rapoarte şi ecrane, diagrame ale fluxurilor de date, diagrame entitate-relaţie etc. Aşadar, şi în
fiind nevoiţi să apeleze atât la discuţii cu utilizatorii şi la observarea modului în care aceştia îşi
Mai mult, sunt destul de rare cazurile când specialiştii în dezvoltarea sistemelor pot crea
desfăşoară activitatea, cât şi la analiza documentaţiei sistemului existent, care poate include
imaginea noului sistem doar pe baza cunoştinţelor sau experienţelor pe care le deţin, de obicei,
STUDIEREA SISTEMULUI EXISTENT ŞI DETERMINAREA CERINŢELOR 83
dar pentru alt sistem, de exemplu sistemul de încasări și plăți, pe baza căruia se vor actualiza și
urmări încasările de la clienți.
Dintre obiectivele prezentării detaliate a ieşirilor sistemului existent pot fi enumerate:
1. Determinarea formatului şi conţinutului ieşirilor
În funcţie de aceste elemente, se va constata, din discuţiile purtate cu utilizatorii, dacă
sunt mulţumiţi de ieşirile generate de sistem sau ele trebuie modificate, fie din punct de vedere
al conţinutului, fie al formei.
De exemplu, dacă un raport privind comenzile primite de la clienţi, într-o perioadă de
timp, este generat în mai multe exemplare şi conţine informaţii pe care o parte din utilizatori nu
le folosesc, este necesară regândirea conţinutului raportului, fie prin eliminarea acelor
informaţii, fie prin proiectarea a două tipuri de rapoarte, unul detaliat şi unul sintetic.
O altă situaţie poate fi cea în care raportul se obţine pe suport de hârtie, deşi el este
utilizat o singură dată, după care este arhivat, fără a se mai apela la conţinutul lui. O soluţie ar
fi generarea lui în format electronic, fără a mai fi tipărit.
Ca urmare, analiştii trebuie să urmărească dacă toate câmpurile din conţinutul raportului
sunt utile tuturor utilizatorilor, dacă suportul de prezentare este cel mai eficient mod de a pune
la dispoziţie informaţiile solicitate sau dacă ar trebui modificat din punct de vedere al formei
(de exemplu, din raport de tip tabel în raport de tip grafic, din raport detaliat într-unul de tip
drill-down etc.)
2. Modul de structurare a ieşirilor
Se va analiza dacă fiecare ieşire are în structură următoarele componente (asupra acestui
aspect se va reveni în capitolul de proiectare a rapoartelor):
introducerea sugestivă (partea de titlu a raportului), care trebuie să fie clară, să scoată în
evidenţă numărul raportului şi data întocmirii lui, locurile în care trebuie să fie distribuite
exemplarele;
informaţiile privind instrucţiunile de completare, destinaţiile fiecărui exemplar, evitarea
comentariilor lungi, prin rubrici sugestive;
partea principală a raportului, care trebuie să fie echilibrată, cu folosirea corectă a
spaţierilor şi marginilor, etichetarea corectă a rubricilor şi gruparea lor logică, marcarea
fiecărei rubrici, accentuarea zonelor cheie prin linii sau culori;
concluziile (finalul) ieşirii, care trebuie să fie plasate la sfârşitul raportului, să aibă spaţiu
suficient pentru semnături, să prezinte regimul de lucru cu documentul respectiv, să fie
accentuate totalurile.
3. Identificarea momentului elaborării rapoartelor
Obiectivul se referă la identificarea frecvenţei cu care se obţin ieşirile, criteriu în funcţie
de care se pot obţine următoarele categorii de rapoarte, prezentate şi în capitolul 2:
rapoarte programate (la termen);
rapoarte neprogramate, cu rol special (rapoarte ad-hoc);
rapoarte declanşate de excepţi;
rapoarte la cerere.
Prin acest obiectiv se doreşte evaluarea eficienţei generării rapoartelor în funcţie de modul
de sprijinire a procesului decizional şi de control. De obicei, rapoartele generate la termen sunt
solicitate mai mult pentru respectarea obligaţiilor legale, în timp ce altele sunt răspunsuri la
cererile managerilor. În aceste condiţii, se poate determina cât de flexibil este sistemul la
nevoile de informare ale utilizatorilor interni şi externi, indiferent de tipul raportului solicitat.
Astfel, este necesar să se identifice toţi utilizatorii informaţiilor şi să fie încadrate în una din
categoriile menţionate pentru a vedea dacă sunt satisfăcute cerinţele lor, dacă sunt necesare şi
alte tipuri de rapoarte.
4. Determinarea duratei necesare pentru generarea unei ieşiri
STUDIEREA SISTEMULUI EXISTENT ŞI DETERMINAREA CERINŢELOR 85
Unul dintre elementele în funcţie de care se stabileşte dacă procedura de prelucrare este
eficientă îl constituie durata necesară obţinerii informaţiilor, influenţată de mai mulţi factori,
dintre care mai importanţi sunt:
prelucrarea se face pe loturi, ceea ce înseamnă că unele rapoarte, privind activităţile
desfăşurate într-o perioadă mai scurtă de timp decât cea în care are loc prelucrarea, nu pot
fi obţinute decât după perioada stabilită pentru culegerea şi prelucrarea datelor generate de
un set de operaţiuni. Acest lucru poate afecta procesul decizional prin lipsa informaţiilor
actualizate. De exemplu, personalul de vânzări nu poate accepta comanda unui client în
ziua primirii ei, ci numai după o săptămână, dacă actualizarea stocului de produse se face,
pe baza facturilor emise şi a bonurilor de predare a produselor finite de la secţiile de
producţie, doar la sfârşitul săptămânii;
prelucrările se bazează pe un sistem de gestiune a bazelor de date ce nu mai face faţă
numărului de înregistrări. Dacă se solicită răspunsul la o întrebare de genul: „Care este
stocul produsului X”, iar utilizatorul trebuie să aştepte mai mult de 5 minute pentru
obţinerea răspunsului dorit, înseamnă că interogarea bazei de date se realizează greoi,
datorită lipsei de performanţă a sistemului de gestiune a bazelor de date sau a neoptimizării
acesteia;
procedurile existente nu se desfăşoară în regim distribuit, astfel că la solicitarea unor
informaţii aflate în mai multe locuri ale firmei este necesar să se aştepte până se
centralizează şi sintetizează datele în forma dorită de utilizatori;
performanţa echipamentelor nu este cea mai bună pentru a sprijini obţinerea rapoartelor în
formatul şi la momentul dorit de utilizatori. De exemplu, unităţile de prelucrare nu permit
generarea unor rapoarte de tip grafic, imprimantele nu au posibilitatea tipăririi în formatul
cerut (A3, A5 etc.) sau solicită mult timp pentru imprimare (cazul imprimantelor
matriceale încă folosite de unele firme pentru tipărirea statelor de salarii sau a balanţelor
de verificare, operaţiune care poate dura şi câteva ore).
5. Identificarea circuitului informaţiilor de ieşire la nivelul organizaţiei
Obiectivul se poate realiza răspunzând la următoarele întrebări:
cine este beneficiarul listei/situaţiei, ecranului sau răspunsului la întrebare? Se identifică
locul/locurile din firmă unde sunt necesare informaţiile. De exemplu, situaţia comenzilor
primite de la clienţi poate fi solicitată de cei de la depozite, în vederea pregătirii produselor
pentru livrare, de cei de la producţie, pentru a planifica producţia, de marketing, pentru a
analiza tendinţele pieţei, de salarizare, pentru a calcula salariile agenţilor de vânzări etc. În
această situaţie, este important să se determine dacă este eficientă obţinerea unui singur
raport, în mai multe exemplare, care să fie transmis tuturor celor interesaţi, sau e mai bine
să fie generate rapoarte cu conţinut diferit, în funcţie de nevoile fiecărui beneficiar.
câte persoane folosesc sau văd listele/situaţiile, ecranele sau răspunsurile la întrebări? Se
determină numărul exact al exemplarelor în care trebuie obţinut raportul, pentru că un tip
de beneficiar ar putea fi format din mai multe persoane. De exemplu, marketingul e posibil
să fie reprezentat de mai mulţi analişti ce urmăresc aspecte diferite în cadrul aceluiaşi
raport: o persoană este interesată de evoluţia generală a comenzilor pentru un anumit
produs, o alta de tendinţa unui client de a se axa pe anumite produse sau anumite perioade
de cumpărare etc.
unde sunt transmise listele/situaţiile, ecranele sau răspunsurile la întrebări? Unele
rapoarte, potrivit regulamentelor interne sau legislaţiei în vigoare, trebuie să aibă
semnătura uneia sau mai multor persoane pentru asigurarea corectitudinii şi validităţii
informaţiilor pe care le conţin. De exemplu, bilanţul contabil trebuie să poarte semnătura
directorului economic, a unui expert contabil şi a directorului firmei pentru a certifica
exactitatea datelor. Acest lucru înseamnă că, până a ajunge la destinaţie (preşedintele
consiliului de administraţie, adunarea generală a acţionarilor sau asociaţilor, direcţia
finanţelor publice), bilanţul trebuie analizat şi verificat de mai multe persoane. Astfel de
86 ANALIZA SISTEMELOR INFORMAŢIONALE
2. pentru informaţiile provenite, în format electronic, din alte sisteme/ aplicaţii, care
presupun retratarea sub aspectul compatibilităţii cu formatul datelor existente în
aplicaţiile sistemului analizat.
1. Analiza documentelor de intrare
Din punct de vedere al documentelor, analiza trebuie să reliefeze o serie de aspecte cu
privire la gradul de optimizare a circuitului lor, momentul în care documentul este emis şi cel
al prelucrării efective a datelor, precum şi cu privire la necesitatea culegerii datelor de pe
documente pentru a fi supuse prelucrărilor. Astfel, se va pune accent pe următoarele elemente:
a) locul de provenienţă a documentelor (emitentul), indicându-se atât locurile din interiorul
organizaţiei, cât şi cele externe;
b) data emiterii documentului şi data preluării datelor în sistem, pentru a se şti care este
intervalul de timp dintre momentul apariţiei datelor de intrare şi cel al prelucrării efective;
c) numărul de exemplare în care se întocmeşte fiecare document şi circuitul fiecărui
exemplar al documentului, pentru a se depista eventualele locuri în care documentul ar
putea fi supus aceloraşi tipuri de prelucrări;
d) frecvenţa de apariţie a documentelor, în funcţie de care se va determina timpul necesar
pentru prelucrarea datelor, precum şi stabilirea tipului prelucrării (pe loturi sau on-line);
e) locul de arhivare a documentelor şi momentul în care intră în acest proces, pentru a se
stabili dacă arhivarea este un proces al sistemului sau aparţine altui sistem (cu alte cuvinte,
dacă documentul rămâne sau nu în sistemul analizat);
f) datele preluate din documente pentru a fi supuse prelucrării, astfel încât să se determine
dacă sunt suficiente sau prea detaliate în raport cu nevoile de informare;
g) criteriile de clasificare şi grupare a documentelor, mai ales în condiţiile în care
prelucrarea datelor se face pe loturi, pentru a şti care este ordinea de prelucrare şi care este
criteriul după care se face prelucrarea. Astfel, pot exista situaţii când prelucrarea se face
după data emiterii documentelor, după emitent sau operaţia economică pe care o reflectă.
De exemplu, facturile primite de la furnizori pot fi grupate după data primirii lor, după
furnizor sau după conţinutul facturilor (facturi pentru materii prime şi materiale, facturi
pentru prestări servicii, facturi pentru achiziţia de mijloace fixe);
h) codificările utilizate pentru înregistrarea datelor în documente, urmărind să existe
concordanţă între codurile utilizate în documente şi cele existente în sistem, pentru a uşura
procesul de prelucrare. De exemplu, existenţa corespondenţei între codificarea
personalului folosită de sistemul de personal-salarizare şi codificarea folosită de secţiile de
producţie, în cadrul fişelor normelor de muncă pentru fiecare salariat;
i) verificările sau controlul la care sunt supuse documentele, din punct de vedere al
legalităţii, completitudinii şi corectitudinii lor, vizează:
semnarea documentelor de către persoanele responsabile;
identificarea eventualelor neconcordanţe între valorile înregistrate şi cele stabilite prin
lege;
completarea tuturor câmpurilor sau explicarea situaţiilor în care nu se solicită această
operaţiune;
verificarea câmpurilor calculate, pentru a se elimina orice sursă de eroare;
j) durata medie a timpului de aşteptare al unui document pentru a fi supus prelucrării,
precum şi durata medie a prelucrării;
k) dependenţele existente între documente pentru a fi supuse proceselor de prelucrare. Cu
alte cuvinte, de stabilit dacă un document poate fi supus prelucrării numai atunci când un
alt document este deja introdus în sistem. De exemplu, factura primită de la furnizor nu
poate fi prelucrată până nu au fost preluate datele de pe notele de intrare-recepţie.
2. Analiza intrărilor din alte sisteme, în format electronic
Referitor la intrările care provin din aplicaţiile altor sisteme, este necesar să se
urmărească:
88 ANALIZA SISTEMELOR INFORMAŢIONALE
a) identificarea datelor care intră din aplicaţiile altor sisteme, pentru a determina formatul
de intrare, de exemplu sub forma unor fişiere temporare;
b) compatibilitatea structurii datelor, în sensul stabilirii tipului atributelor, a mărimii acestora
şi a formatului, astfel încât datele transmise să nu fie supuse unor retratări, ci direct
procesului de prelucrare;
c) momentele în care sistemul analizat solicită date de la aplicaţiile altor sisteme şi cele în
care sunt oferite efectiv, pentru a se identifica potenţialele întârzieri datorate unor
deficienţe ale aplicaţiilor din alte sisteme sau din sistemul analizat. În situaţia prelucrărilor
automate, trebuie urmărite tipurile de prelucrări (pe loturi sau on-line), platformele pe care
rulează aplicaţiile, pentru a fi rezolvată problema compatibilităţii procedurilor de
prelucrare;
d) identificarea datelor care trebuie supuse unor procese de pregătire (regrupări, reordonări
sau sortări, în funcţie de necesităţile sistemului care este supus analizei) şi a celor ce pot fi
prelucrate direct.
Cod client şi Nume client, respectiv Cod produs şi Denumire produs, dar ele sunt folosite ca
elemente de control pentru eliminarea erorilor de introducere a datelor.
De asemenea, printr-o astfel de matrice se pot identifica şi eventualele date nepreluate
încă în sistem, dar necesare pentru generarea ieşirilor, aşa cum este cazul Limita creditare, care
este o dată ce nu se regăseşte în sistem, ceea ce înseamnă că la determinarea cerinţelor ar trebui
inclusă, fie pe baza eventualelor contracte/convenţii care se încheie cu clienţii, fie a unor reguli
economice interne.
Astfel de matrice şi verificări se pot realiza automat cu ajutorul instrumentelor CASE.
ce utilizatori au acces la e-mail şi cât de des folosesc e-mailul (dacă sistemul apelează
la e-mail pentru preluarea sau transmiterea datelor);
dacă există posibilitatea accesării Internetului, trebuie specificat cine are acces, pentru
ce îl accesează, ce servicii ale Internetului sunt folosite;
13. protecţia şi securitatea datelor, prin prezentarea drepturilor de acces ale utilizatorilor la
fişiere şi baze de date (cine, ce drepturi are), procedurile de asigurare a integrităţii datelor,
de realizare a copiilor de siguranţă.
2. transformările presupun obţinerea informaţiilor din datele existente, fără a avea ca rezultat
modificări la nivelul înregistrărilor din baza de date. Sistemul de calcul al drepturilor
salariale reprezintă un exemplu tipic pentru acest tip de prelucrări: pe baza numărului de
ore lucrate (intrarea în sistem) se calculează drepturile salariale, prin efectuarea diferitelor
calcule privind tariful orar, sporurile şi reţinerile prevăzute, în final obţinându-se statul de
plată şi centralizatorul statelor de salarii. Un alt exemplu îl reprezintă sistemul de
contabilitate generală, a cărui funcţie principală o constituie înregistrarea cronologică şi
sistematică a mişcărilor de valori ce au loc în firmă. Notele contabile, preluate de la
sistemele de evidenţă analitică, sunt transcrise, mai întâi, în registrul jurnal, apoi ele sunt
prelucrate şi sistematizate în cartea mare, pe baza căreia se va întocmi balanţa de
verificare, prin aplicarea regulilor de transformare cunoscute. În final, se va obţine bilanţul,
ce reprezintă principala ieşire a sistemului de contabilitate generală.
La nivelul unui sistem se regăsesc ambele categorii de procese (tranzacţii şi transformări),
numai că unele sunt orientate cu preponderenţă spre tranzacţii, iar altele spre transformări, aşa
cum se va vedea şi în capitolul care tratează proiectarea programelor.
În cazul sistemelor automatizate, identificarea proceselor de prelucrare se realizează,
relativ uşor, prin citirea documentaţiei aplicaţiilor (dacă există) sau prin analiza aplicaţiei.
Astfel, pentru studierea modului de descompunere a sistemului, se urmăresc opţiunile
meniurilor şi submeniurilor din care sunt constituite aplicaţiile. Fiecare opţiune va fi analizată
din perspectiva acţiunilor pe care le realizează, pe baza citirii codului sursă sau a
documentaţiei utilizatorului. De multe ori, opţiunile unui meniu sunt grupate în două moduri:
1. în funcţie de operaţiile economice care au generat datele ce urmează a fi supuse prelucrării,
caz în care submeniurile reflectă operaţiile respective şi vor conţine proceduri pentru
introducerea datelor, proceduri de actualizare a bazelor de date, de verificare şi validare, de
pregătire şi generare a ieşirilor;
2. în funcţie de tipul prelucrărilor care se execută, când submeniurile sunt organizate plecând
de la principalele prelucrări care se vor executa (introducere date, actualizare baze de date,
generare rapoarte), în cadrul lor regăsindu-se operaţiile economice care urmează a fi
prelucrate.
În cazul sistemelor manuale, procesele de prelucrare trebuie identificate plecând de la
persoanele implicate, în sensul analizei acţiunilor pe care le realizează asupra documentelor,
ţinând cont de etapele ciclului prelucrărilor datelor, descris într-un capitolul anterior. Astfel, se
va urmări modul în care are loc transcrierea unor câmpuri de pe anumite documente în alte
documente, sub forma centralizatoarelor, însumarea câmpurilor ce solicită o astfel de
operaţiune, aplicarea unor formule de calcul pentru obţinerea şi completarea unor câmpuri de
pe documentul pe care îl folosesc ş.a.m.d.
De exemplu, în cazul prelucrării manuale a comenzilor primite de la clienţi, se pot
desfăşura următoarele procese:
preluare, prin telefon sau poştă, a comenzilor de către o persoană de la vânzări;
scrierea datelor pe un formular specific de comandă sau completarea celui primit cu
alte date necesare prelucrărilor ulterioare, cum ar fi codul clientului, codul produselor,
preţul de vânzare;
căutarea şi citirea informaţiilor (de pe documente centralizatoare sau de altă natură)
privind stocul de produse existent (din fişa de magazie) şi limita de creditare acordată
clientului (din fişa de cont analitic);
generarea notei de confirmare a comenzii;
gruparea comenzilor în funcţie de codul clientului, data comenzii, codul produselor
etc.;
centralizarea datelor privind produsele solicitate şi transmiterea lor la producţie şi/sau
depozite;
arhivarea comenzilor în funcţie de codul clientului sau de dată;
92 ANALIZA SISTEMELOR INFORMAŢIONALE
3. Satzinger, J.W., Jackson, R.B., Burd, S.D. – Systems Analysis and Design in a Changing World, Second Edition,
Course Technology, Thomson Learning, Boston, 2002, pp. 153-157.
94 ANALIZA SISTEMELOR INFORMAŢIONALE
Un eveniment extern reflectă o operaţiune ce are loc în afara sistemului, fiind iniţiat de un
agent, actor sau entitate externă (o persoană, un departament din interiorul firmei sau altă
firmă), care furnizează date sistemului sau primeşte informaţii de la el. Aici nu trebuie să se
facă confuzia între entităţile externe sistemului şi cele externe firmei, pentru că atenţia se
orientează spre ceea ce poate să declanşeze prelucrarea datelor în cadrul sistemului.
De exemplu, entitate externă sistemului de gestiune a aprovizionărilor este furnizorul, care
livrează materiile prime şi materiale, pentru că declanşează prelucrarea datelor privind facturile
primite. Însă, şi comisia de recepţie este entitate externă sistemului de aprovizionare, pentru că
oferă informaţii privind eventualele diferenţe ce apar între datele înscrise în facturile
furnizorilor şi cele identificate la verificarea faptică a cantităţilor primite, reflectate într-un
document specific (nota de intrare-recepţie) ce va fi prelucrat de sistem.
Un alt exemplu de entitate externă îl reprezintă clientul, care poate transmite o comandă,
prin care solicită unul sau mai multe produse. Un astfel de eveniment este esenţial pentru un
sistem de gestiune a clienţilor, dar lui îi sunt asociate şi alte evenimente, în sensul că un client
poate să returneze un produs, să plătească factura pentru comanda onorată ş.a.
Ca urmare, pentru analiza sistemului se vor identifica acele entităţi externe care ar putea
solicita informaţii de la sistem sau care pun date la dispoziţia lui.
Evenimentele externe stau la baza stabilirii principalelor funcţii de prelucrare ale
sistemului. La descrierea lor este indicat să fie folosite denumiri cât mai sugestive, astfel încât
entitatea externă să fie mai uşor de identificat, precum şi acţiunile realizate de aceasta şi care
pot afecta sistemul. De exemplu, operaţiunea Transmiterea comenzii de către client descrie
entitatea externă (Clientul) şi acţiunea pe care o realizează (Transmiterea comenzii), ce va
determina preluarea şi prelucrarea comenzilor, reprezentând una din funcţiile de bază ale
sistemului de gestiune a clienţilor.
Evenimentele externe pot fi declanşate şi de nevoile informaţionale ale unor persoane sau
componente organizaţionale din interiorul firmei, cum ar fi solicitarea unor informaţii privind
încasarea facturilor emise clienţilor, pentru actualizarea conturilor. Majoritatea evenimentelor
externe pot fi încadrate în una din următoarele categorii generale:
entităţile externe transmit date, ca rezultat al unei operaţii economice;
entităţile externe solicită anumite informaţii pentru derularea unor operaţii economice,
fără a se cunoaşte momentul solicitării;
datele memorate, în urma unor evenimente anterioare, trebuie actualizate.
Evenimentele temporale sunt cele care au loc ca rezultat al atingerii unui moment dintr-o
perioadă de timp bine determinată. Multe sisteme generează informaţiile de ieşire la intervale
bine definite, cum ar fi statele de plată emise de sistemul de salarizare, chenzinal sau lunar,
lista achiziţiilor pe luna x, generată de sistemul de aprovizionare ş.a.m.d. Uneori, ieşirile sunt
rapoarte pe care conducerea doreşte să le primească periodic, cum ar fi rapoartele privind
eficienţa unei activităţi sau rapoarte cu titlu de excepţie.
Evenimentele temporale sunt diferite de cele externe, prin faptul că sistemul poate să
genereze automat informaţiile solicitate fără să i se specifice ce are de făcut. Cu alte cuvinte,
nici un agent extern sau entitate externă nu declanşează funcţiile de prelucrare ale sistemului,
ci factorul timp, entităţile externe urmând doar să primească informaţia. Identificarea acestui
tip de eveniment se poate face plecând de la găsirea răspunsurilor la o serie de întrebări de
genul: Ce informaţii trebuie obţinute la anumite perioade de timp? Ce prelucrări ar putea fi
solicitate în acele momente?
De exemplu, în cazul sistemului de salarizare, procesul prin care se obţin statele de salarii
ar putea fi denumit astfel: Generarea chenzinală/lunară a statelor de plată, ceea ce evidenţiază
informaţiile pe care ar trebui să le prelucreze sistemul şi perioada de timp la care ar trebui să
realizeze funcţia respectivă.
Aceste tipuri de evenimente nu este obligatoriu să fie declanşate la date calendaristice
fixe, ci pot fi declanşate şi la îndeplinirea anumitor condiţii, dependente de perioade
STUDIEREA SISTEMULUI EXISTENT ŞI DETERMINAREA CERINŢELOR 95
calendaristice. O situaţie de acest fel se întâlneşte atunci când un client nu-şi plăteşte factura la
data prevăzută, iar sistemul poate genera o înştiinţare privind întârzierea plăţii, după 15 zile de
la expirarea termenului de plată.
A treia categorie de evenimente este cea de stare. Ele apar când se întâmplă ceva în sistem
sau este îndeplinită o condiţie ce declanşează o prelucrare. De exemplu, dacă vânzarea unui
produs are ca rezultat scăderea stocului sub un anumit nivel, atunci este necesar să se emită o
comandă de reaprovizionare, iar evenimentul ar putea fi denumit Emitere comandă de
reaprovizionare. Adesea, evenimentele de stare sunt similare celor temporale, cu excepţia
faptului că nu sunt cunoscute momentele de timp când trebuie declanşate procedurile de
prelucrare şi depind de evenimentele externe, fiind executate şi ca rezultat al altor prelucrări.
Trebuie remarcat faptul că evenimentele temporale şi de stare presupun, în principal,
transpunerea datelor memorate în sistem într-o formă solicitată de diferiţii utilizatorii ai
informaţiei, spre deosebire de cele externe care implică adăugări, modificări sau ştergeri de
date.
sistemul prelucrează operaţiunea de cumpărare, după care, până la sfârşitul lunii, când va avea
loc încasarea, prelucrează alte date. Nu se poate opri sistemul din prelucrarea datelor, generate
de alte tipuri de evenimente, până când are loc încasarea. În acest caz, avem două evenimente
externe: Cumpărarea, care declanşează procesul de prelucrare Emitere factură, respectiv
Efectuarea plăţii de către client, prin care se declanşează procesul Încasarea facturii, şi un
eveniment temporal care conduce la Generarea situaţiei lunare a contului clientului.
Pentru identificarea evenimentelor este util să se analizeze secvenţa lor, plecând de la
entitatea externă care le declanşează sau este afectată de către acestea. În cazul sistemului de
gestiune a clienţilor de la firma ABC, analistul ar trebui să se gândească la toate evenimentele
posibile care ar putea să aibă loc în legătură cu un client. În primul rând, clientul poate solicita
un catalog de produse sau anumite informaţii despre disponibilitatea unui produs, determinând
adăugarea unei noi înregistrări în baza de date cu numele şi adresa clientului, dacă el este un
client nou. Apoi, clientul ar putea să transmită o comandă, să modifice comanda (de exemplu,
să solicite o altă mărime a produselor sau un nou articol), după care doreşte să urmărească
starea comenzii şi momentul livrării. Este posibil ca acel client să-şi schimbe adresa, ceea ce
înseamnă înregistrarea noii adrese la care urmează a fi livrate produsele sau cataloagele firmei.
În final, clientul ar putea să returneze anumite produse care i-au fost livrate. O astfel de
abordare a secvenţei de derulare a evenimentelor poate ajuta la identificarea celor ce trebuie
luate în considerare la prelucrarea datelor.
În caseta 5.2 sunt prezentate cele mai importante evenimente în firma ABC şi pe care
sistemul de gestiune a clienţilor trebuie să le surprindă.
Caseta nr. 5.2 – Evenimentele specifice sistemului de gestiune a clienţilor la firma ABC
Sistemul de gestiune a clienţilor implică o mare varietate de evenimente, multe dintre ele similare
deja celor prezentate. Ca evenimente externe au fost identificate:
verificarea de către client a disponiblităţii unui produs;
transmiterea unei comenzi de către client;
modificarea sau anularea de către client a unei comenzi;
solicitarea de către client sau conducere a informaţiilor necesare verificării stării unei comenzi;
livrarea/onorarea comenzii;
returnarea produselor de către client (defecte, shimbarea părerii despre produs, returnare totală
sau parţială);
solicitarea cataloagelor de produse de către potenţialii clienţi;
solicitarea din partea departamentului de marketing de a transmite materiale promoţionale
clienţilor;
schimbarea politicii de creditare a clienţilor (creşterea limitei de creditare, acordarea de
discounturi, reducerea penalităţilor etc.);
obţinerea unor noi produse, modificarea caracteristicilor produselor existente sau a preţurilor;
lansarea de acţiuni promoţionale pentru anumite produse sau anumiţi clienţi.
Se poate observa că multe dintre evenimente au ca entitate externă declanşatoare clientul, în timp
ce altele implică apariţia chiar a departamentelor sau conducerii firmei. Analistul trebuie să dezvolte o
listă a evenimentelor externe, urmărind toate persoanele sau componentele organizaţionale care pot
declanşa o anumită operaţiune de prelucrare sau care solicită anumite răspunsuri din partea sistemului.
Sistemul de gestiune a clienţilor include câteva procese temporale, declanşate de factorul timp,
respectiv:
generarea rapoartelor privind comenzile primite;
generarea rapoartelor privind activitățile desfăşurate într-o perioadă de timp;
generarea rapoartelor privind comenzile onorate;
obţinerea de rapoarte privind potenţialii clienţi;
obţinerea de rapoarte privind modificările efectuate asupra contului clienţilor;
generarea rapoartelor privind producerea şi distribuirea de cataloage.
Multe dintre aceste rapoarte sunt periodice, fiind destinate diferitelor compartimente, ceea ce
înseamnă că analistul trebuie să studieze toate rapoartele şi situaţiile pe care sistemul trebuie să le
genereze la anumite perioade de timp.
Pe măsura dezvoltării listei evenimentelor, analistul trebuie să observe şi noteze orice informaţie
STUDIEREA SISTEMULUI EXISTENT ŞI DETERMINAREA CERINŢELOR 97
suplimentară care poate prezenta interes, prin construirea unui tabel al evenimentelor, în care pe linii
sunt reprezentate evenimentele, iar pe coloane detaliile fiecăruia. Un exemplu de astfel de tabel pentru
evenimentul Solicitare informaţii disponibilitate produs este redat în figura C5.1.
Ce agent/actor extern
generată de sistem?
primeşte ieşirea
Destinaţia:
cazul) ar trebui să fie
generată de sistem?
Ce ieşire (dacă este
Destina?ia
Destinaţia
Client
Răspunsul:
Detalii privind
R?spunsul
sistemului
Răspunsul
sistemului
produsul
stoc
sursa pentru introducerea
existenţeiînînstoc
produs
agentul extern reprezintă
sistemului
Căutareprodus
sistemului
verificarea
Ac?iunea
Acţiunea
?işiverificarea
Pentru un eveniment
extern, actorul sau
existen?ei
datelor în sistem.
Cautare
când un eveniment
Ce face sistemul
Sursa:
Sursa
Acţiunea:
Client
areloc?
Declanşator
Declan?ator
declanşatorul constă în datele
pentru un
Cum ştie sistemul că a avut
Cererea
introduse în sistem. Pentru
produs
momentul ce declanşează
loc un eveniment? Pentru
evenimentele externe,
prelucrarea în sistem.
disponibilitate produs
produs
informa?ii
Declanşatorul:
Solicitareinformaţii
Eveniment
disponibilitate
Solicitare
Ce determină
Evenimentul:
efectueze o
sistemul să
acţiune?
să-l constituie şi un alt proces de prelucrare, care transmite o serie de date pentru a fi supuse
altor prelucrări. De exemplu, în urma introducerii datelor de pe comenzile primite de la clienţi,
se transmite un flux de date în procesul de verificare a situaţiei contului clienţilor, pentru a
vedea dacă noile comenzi se mai încadrează în limita de creditare acordată.
Pentru un eveniment temporal, declanşatorul este dat de momentul dintr-o perioadă de
timp bine delimitată când sistemul trebuie să obţină sau să prelucreze ceva. De exemplu, la
sfârşitul fiecărei zile, sistemul trebuie să genereze rapoartele privind operaţiile economice
desfăşurate în acea zi cu clienţii firmei.
În legătură cu întrebarea „Ce trebuie să facă sistemul când un eveniment are loc sau care
este reacţia sistemului la eveniment?”, se va identifica acţiunea pe care trebuie să o execute.
Acţiunea reprezintă prelucrările pe care sistemul le desfăşoară când a avut loc un eveniment şi
se concretizează într-o ieşire sau rezultat bine delimitat. De exemplu, când un client transmite o
comandă, sistemul execută procesul de prelucrare Înregistrare comandă nouă, prin care sunt
preluate detaliile din comanda primită şi se adaugă o nouă înregistrare în tabela de comenzi.
Atunci când trebuie să se genereze un raport privind activitățile/operațiile, sistemul execută o
procedură numită Generare raport activități/operații zilnice.
În final, trebuie să se identifice rezultatul/răspunsul obţinut de sistem în urma acţiunilor
desfăşurate, acesta fiind o ieşire a sistemului. Când sistemul generează rapoartele privind
activitățile/operațiile zilnice, înseamnă că se obţin ieşirile sistemului, dar printr-o acţiune se
pot genera mai multe rapoarte. De exemplu, când sistemul creează o înregistrare nouă în
fişierul de comenzi, sistemul poate transmite clientului o confirmare a comenzii, iar detaliile
privind comanda sunt trimise depozitelor pentru pregătirea livrării. Destinaţia este locul unde
răspunsul sistemului (ieşirea) este transmis, reprezentată de un agent sau actor extern. Tot ca
destinaţie sunt considerate şi locurile de stocare în care sunt înregistrate datele rezultate în
urma prelucrărilor.
Uneori, o acţiune a unui sistem este posibil să nu genereze imediat un răspuns. De
exemplu, dacă un client doreşte să-şi actualizeze informaţiile privind adresa, ele vor fi
modificate în baza de date, dar nu este necesar ca sistemul să dea un răspuns clientului la
această acţiune. Înregistrarea informaţiilor în baza de date reprezintă însă o parte a acţiunii
sistemului la evenimentul de transmitere de către client a noilor date, ce vor fi folosite la
apariţia altor evenimente.
Se poate spune că tabelul evenimentelor este un mijloc eficient de a culege o parte din
infomaţiile necesare stabilirii cerinţelor informaţionale ale sistemului.
În cazul sistemului de gestiune a clienţilor de la ABC, tabelul evenimentelor este redat în
caseta 5.3:
Caseta 5.3 – Tabelul evenimentelor pentru sistemul de gestiune a clienţilor la firma ABC
4. Christel, M., Kang, K.C. – Issues in Requirements Elicitation, Technical Report, CMU/SEI-92-TR-012, ESC-TR-
-92-012, 1992, p. 2.
100 ANALIZA SISTEMELOR INFORMAŢIONALE
Cerinţele nu constau doar din funcţii ale unui sistem sau ale unei componente, ci trebuie
urmărite mai multe caracteristici ale acestora, astfel încât să fie exploatat pentru a răspunde
eficient unei probleme sau unui domeniu de activitate.
Am văzut că pe parcursul etapei de planificare a sistemului se identifică scopul sistemului,
adică principalele funcţii şi caracteristici pe care trebuie să le deţină, detaliate în timpul
analizei.
Dintr-o perspectivă generală, la nivelul unui proiect de dezvoltare se identifică două
categorii majore de cerinţe ale unui sistem: funcţionale şi nefuncţionale sau tehnice. Însă, se
întâlnesc şi alte tipuri, văzute din perspectiva utilizatorilor sau a managementului de proiect,
aşa cum se va vedea într-un paragraf următor.
Activitatea de determinare a cerinţelor este considerată una din cele mai complexe din
faza de analiză, datorită dificultăţii de evaluare a necesarului de informaţii. În unele situaţii,
utilizatorii pot fi subiectivi când sunt chestionaţi pe o astfel de temă, iar în alte situaţii nu îşi
dau seama care sunt informaţiile de care au nevoie sau le identifică în mod eronat.
La această problemă se adaugă şi diversitatea surselor de informare: de la utilizatorii
sistemului curent, prin observarea a ceea ce fac aceştia, până la studierea documentelor
primare, a rapoartelor, a procedurilor folosite.
Cauzele care determină apariţia problemelor în procesul de culegere a cerinţelor sunt
grupate astfel:
cauze legate de scop – graniţele sistemului sunt greşit stabilite sau utilizatorii/beneficiarii
sistemului specifică detalii tehnice inutile, care mai mult derutează decât să clarifice
obiectivele sistemului;
cauze privind dificultatea înţelegerii dorinţelor utilizatorilor, de unde necesitatea bunei
cunoaşteri de către echipa de analiză a domeniului sistemului, pentru că utilizatorii:
– nu sunt foarte siguri asupra elementelor de care au nevoie;
– nu cunosc îndeajuns de bine performanţele şi limitele mediului lor de lucru;
– nu înţeleg în totalitate domeniul problemei;
– au probleme în comunicarea nevoilor;
– omit informaţii pe care le consideră „implicite”, „normale”;
– cerinţele specificate pot intra în conflict cu nevoile altor utilizatori;
– percep greu limbajul echipei de analiză, mai ales dacă se foloseşte un limbaj pur tehnic;
– formulează cerinţe ambigue sau netestabile.
cauze legate de volatilitatea informaţiilor. Cerinţele, de multe ori, se modifică în timp.
Descrierile anterioare au evidenţiat faptul că multe dintre greutăţile care apar se datorează
comunicării dificile între utilizatori şi echipa de dezvoltare a sistemului. Neînţelegerile dintre
ei pot duce la grave probleme în dezvoltarea sistemului, fie prin eforturi umane şi financiare
ineficiente, fie prin nerezolvarea cerinţelor reale ale sistemului propus pentru dezvoltare.
Prin determinarea şi analiza cerinţelor se urmăreşte gruparea şi organizarea lor în seturi
interdependente, identificarea relaţiilor dintre o cerinţă cu altele şi asigurarea corespondenţei
dintre ele, depistarea eventualelor omisiuni sau ambiguităţi, precum şi ierarhizarea cerinţelor în
funcţie de nevoile utilizatorilor.
Din momentul în care începe analiza cerinţelor, este necesară examinarea următoarelor
aspecte:
dacă au fost specificate toate cerinţele la un nivel corespunzător de abstractizare sau se
indică un nivel de detaliere tehnică necorespunzătoare acestei etape;
cerinţele sunt cu adevărat necesare sau reprezintă caracteristici sau elemente
suplimentare ce nu sunt esenţiale atingerii scopului sistemului;
fiecare cerinţă este bine delimitată şi nu este ambiguu formulată;
cerinţele au identificate sursele (în general, o anumită persoană);
o cerinţă să nu intre în conflict cu altele;
STUDIEREA SISTEMULUI EXISTENT ŞI DETERMINAREA CERINŢELOR 101
să fie posibilă satisfacerea cerinţelor prin aplicaţia informatică care urmează să fie
dezvoltată;
fiecare cerinţă să poată fi testată în momentul în care urmează să fie implementat
sistemul.
Fără a avea pretenția de a fi o listă exhaustivă, poate asigura o anumită certitudine asupra
cerințelor ce se vor regăsi la viitorul sistem.
La ABC, utilizatorii operaţionali ai noului sistem sunt reprezentaţi de agenţii de vânzări care
preiau telefonic comenzile şi de cei care introduc comenzile primite prin poştă. Ei au diferite
perspective asupra sistemului şi a ceea ce trebuie să facă pentru desfăşurarea activităţilor zilnice.
Agenţii de vânzări ce preiau comenzile telefonic sunt interesaţi de informaţiile despre produsele
existente în stoc pentru a confirma disponibilitatea lor şi pentru stabilirea datei de livrare. Cei care
preiau comenzile primite prin poştă discută despre posibilitatea scanării lor pentru eliminarea
introducerii acestora de la tastatură. Salariaţii de la depozite au nevoie de informaţii privind comenzile
care au fost livrate, care urmează a fi livrate, ca şi posibilitatea accesării on-line a informaţiilor privind
STUDIEREA SISTEMULUI EXISTENT ŞI DETERMINAREA CERINŢELOR 103
comenzile de livrat, emiterea facturilor pentru încărcarea produselor în loturile pentru transport.
Patronescu şi Patroneasca, în calitatea lor de top-manageri, sunt interesaţi de obţinerea rapoartelor
privind produsele comandate şi livrate, determinarea tendinţelor pentru fiecare sezon, pentru că în
domeniul lor de activitate este important să se identifice din timp tendinţa modei, pentru a se adapta
rapid sau pentru a renunţa la unele produse, dacă acestea nu mai sunt cerute de piaţă.
Dezvoltarea sistemului este finanţată în parte din fonduri interne, dar şi prin obţinerea unei linii de
credit de la bancă. ABC are deschisă o linie de creditare pe termen scurt, dar, pentru că proiectul
presupune o investiţie de durată, s-a obţinut o linie de credit pe termen lung, ceea ce înseamnă că banca
(finanţatorul) va fi interesată de succesul proiectului. În acest caz, echipa trebuie să identifice care sunt
formatele pentru situaţiile financiare pe care banca ar dori să le primească în timpul exploatării şi
întreţinerii sistemului, până la rambursarea integrală a creditului.
În final, din moment ce noul sistem implică apelarea la noi tehnologii (Internet şi sisteme
distribuite), este importantă participarea personalului tehnic.
Se poate observa că sunt destul de multe persoane care ar trebui să pună la dispoziţie informaţii
privind diferite categorii de cerinţe pe care noul sistem trebuie să le satisfacă.
Revenind la structura organizatorică a firmei ABC (din caseta 5.1, capitolul 5), poziţiile
evidenţiate prin culoarea verde indică top managerii şi managerii de mijloc ce vor fi incluşi în calitate
de stakeholder-i în dezvoltarea sistemului (Preşedinte, director distribuţie, director marketing şi vânzări,
director economic, director vânzări cu amănuntul, şef birou promovare/publicitate, şef birou cataloage,
şef birou comenzi telefonice, şef linii de producţie, şef depozite/livrare, contabil şef, director
departament informatic, şef birou dezvoltare sisteme, şef birou întreţinere sisteme).
6. McLeod Jr., R., Jordan, L. – Systems Development. A Project Management Approach, John Wiley & Sons, Inc.,
New York, 2002, p. 320.
7. Pressman, R.S. – Software Engineering. A Practioner’s Approach. European Adaptation, Fifth Edition, McGraw
Hill, London, 2000, pp. 273-274.
104 ANALIZA SISTEMELOR INFORMAŢIONALE
8. Satzinger, J.W., Jackson, R.B., Burd, S.D. – op. cit., pp. 112-113.
9. Romney, M.B., Steinbart, P.J. – op. cit., p. 591.
STUDIEREA SISTEMULUI EXISTENT ŞI DETERMINAREA CERINŢELOR 105
*
* *
Produsul final al etapei de analiză îl reprezintă specificaţia de analiză sau specificaţia
cerinţelor, o formalizare a rezultatelor obţinute prin activităţile desfăşurate. Scopul îl
constituie comunicarea rezultatelor tuturor celor interesaţi, servind şi ca reper pentru etapele
următoarele, de proiectare şi implementare. Aşadar, descrierea precisă este preferată de cele
mai multe ori, dar trebuie să se ţină cont de faptul că specificaţia trebuie să fie uşor de înţeles
şi de către utilizatorii sistemului, ceea ce înseamnă apelarea la un limbaj natural şi la o serie de
imagini, mult mai uşor de perceput. Pentru utilizatori, specificaţia are rolul de definire a
funcţionalităţii sistemului, iar pentru proiectanţi reprezintă punctul de start al etapei de
proiectare.
Utilizatorii sunt mulţumiţi dacă li se oferă un document care „vorbeşte pe limba lor”,
limbaj care este folosit în domeniul lor de activitate. Proiectanţii, pe de altă parte, solicită o
specificaţie care să apeleze la concepte utilizate în domeniul lor de specialitate. În practică, se
STUDIEREA SISTEMULUI EXISTENT ŞI DETERMINAREA CERINŢELOR 107
ajunge de multe ori la un compromis sau pot fi prezentate forme diferite ale specificaţiilor în
funcţie de cei cărora li se adresează.
Specificaţia de analiză trebuie văzută ca un raport la fel de important precum cel care
prezintă, de exemplu, performanţele înregistrate de firmă într-un an, pe baza căruia se iau
deciziile privind continuarea activităţilor eficiente şi luarea măsurilor corective pentru cele
care nu au înregistrat rezultatele scontate. În acelaşi mod, pe baza raportului de analiză se ia
decizia de continuare a proiectului de dezvoltare a sistemului, se iau măsuri de îmbunătăţire a
modului de utilizare a resurselor sau de încadrare în bugetul şi timpul alocat. De aceea, din
specificaţiile de analiză trebuie să rezulte foarte clar scopul şi obiectivele sistemului, metodele
folosite pentru studierea sistemului existent şi determinarea cerinţelor, rezultatele obţinute,
inclusiv modelele construite, variantele de proiectare şi recomandările analiştilor, concluziile.
Rezumat
În timpul cercetării şi stabilirii cerinţelor se vor obţine detaliile privind procesele şi activităţile
desfăşurate la nivelul sistemului curent, pe măsura intervievării, observării utilizatorilor sau analizei
documentelor şi procedurilor de lucru existente. În acest mod, se încearcă obţinerea unei imagini cât mai
clare şi obiective asupra problemelor cărora trebuie să le răspundă noul sistem. De asemenea, se
urmăreşte identificarea modalităţilor în care pot fi atinse obiectivele economice cu ajutorul tehnologiilor
informaţionale, pe care utilizatorii, obişnuiţi cu modul de lucru al sistemului, aproape nu le mai sesizează.
Şi asta pentru că, în timpul analizei, „se merge unde trebuie şi se discută ce trebuie” cu utilizatorii care
participă la desfăşurarea operaţiunilor economice, ceea ce face mult mai facilă acceptarea schimbării
sistemului.
Principalele elemente supuse analizei în timpul studierii sistemului existent sunt: informaţiile de
ieşire obţinute din actualul sistem; datele de intrare în sistem; modul în care sunt stocate, memorate şi
păstrate datele în sistem; procesele de prelucrare la care sunt supuse datele.
Un rol important în analiza sistemului îl are analiza proceselor de prelucrare, care se bazează pe
studierea evenimentelor ce au loc într-o anumită perioadă de timp şi într-un anumit loc, ce pot fi descrise
şi ar trebui memorate de sistem. Evenimentele sunt cele care determină sau declanşează procesele de
prelucrare pe care le execută un sistem, ceea ce înseamnă că este necesară inventarierea şi analiza lor.
Există trei mari categorii de evenimente sau activități ce trebuie avute în vedere când se analizează
un sistem: externe, temporale, de stare. În urma studierii sistemului se pot determina ce funcţii se
păstrează şi care sunt eliminate, ce intrări şi ieşiri mai sunt necesare, care sunt componentele generatoare
de probleme şi cum ar putea fi ele rezolvate.
Activitatea de determinare a cerinţelor este considerată una din cele mai complexe din faza de
analiză, datorită dificultăţii de evaluare a necesarului de informaţii. În unele situaţii, utilizatorii pot fi
subiectivi când sunt abordaţi pe o astfel de temă, iar în alte situaţii nu ştiu care sunt informaţiile de care
au nevoie sau le identifică în mod eronat.
La această problemă se adaugă şi diversitatea surselor de informare: de la utilizatorii sistemului
curent, prin observarea a ceea ce fac aceştia, până la studierea documentelor primare, a rapoartelor, a
procedurilor folosite.
Principala sursă de informaţii privind cerinţele funcţionale ale sistemului o reprezintă diferitele
persoane interesate de implementarea cu succes a sistemului (stakeholder-ii), grupate în patru mari
categorii: utilizatorii, beneficiarii, personalul tehnic, organismele externe firmei.
În timpul analizei, cerinţele pot fi grupate în trei mari categorii, în funcţie de percepţia pe care o au
utilizatorii asupra celor prezentate de analist, şi anume: cerinţe normale, cerinţe dorite de utilizatori,
cerinţe „surpriză”.
Din punct de vedere al cerinţelor urmărite în etapele următoare de dezvoltare, de către membrii
echipei proiectului, se regăsesc următoarele tipuri: cerinţe funcţionale, cerinţe nefuncţionale sau tehnice,
cerinţe privind managementul proiectului, cerinţe economice.
Produsul final al etapei de analiză îl reprezintă specificaţia de analiză sau specificaţia cerinţelor, o
formalizare a rezultatelor obţinute în această fază.
108 ANALIZA SISTEMELOR INFORMAŢIONALE
Întrebări recapitulative
1. Care sunt elementele supuse cercetării în timpul studierii sistemului existent?
2. Ce obiective se urmăresc prin analiza sistemului existent?
3. Enumeraţi aspectele/obiectivele prezentării detaliate a ieşirilor sistemului curent.
4. Prin ce se verifică utilitatea informaţiilor conţinute de ieşirile sistemului curent?
5. Ce situaţii trebuie abordate distinct în cazul analizei datelor de intrare?
6. Enumeraţi elementele ce sunt supuse analizei din punct de vedere al documentelor de intrare sau
documentelor sursă.
7. Ce se urmăreşte la analiza intrărilor provenite din aplicaţiile altor sisteme?
8. Ce se evidenţiază prin analiza modului de stocare, accesare şi păstrare a datelor?
9. Enumeraţi elementele urmărite prin studierea prelucrărilor din sistemul curent.
10. Care sunt detaliile ce trebuie evidenţiate în timpul analizei proceselor de prelucrare?
11. Definiţi evenimentele pe baza cărora se identifică funcţiile de prelucrare din sistem.
12. Descrieţi categoriile de evenimente luate în considerare la analiza sistemului.
13. Descrieţi cauzele problemelor din timpul determinării cerinţelor informaţionale.
14. Care sunt cerinţele ce pot fi identificate în timpul etapei de analiză, în funcţie de percepţia
utilizatorilor?
15. Care sunt principalele tipuri de cerinţe de identificarea cărora depinde derularea următoarelor etape
de dezvoltare a sistemului?
16. Enumeraţi principalele categorii de cerinţe funcţionale ale unui sistem.
17. Care sunt principalele categorii de persoane care stau la baza identificării cerinţelor noului sistem?
18. Care sunt principalele surse de identificare a cerinţelor?
Probleme de echipă
1. Firma Turism pentru Studenţi (TS) face rezervări pentru tabere studenţeşti la diferite agenţii de
turism. În timpul semestrului de vară, agenţiile trimit firmei informaţii despre hotelurile disponibile,
camerele şi capacitatea lor, preţul pentru petrecerea unei săptămâni din vacanţa de iarnă. Fiecare
agenţie prezintă oferte pentru un număr diferit de săptămâni în fiecare sezon, precum şi preţuri
diferite pentru camere, în funcţie de săptămâna pentru care se face rezervarea. De obicei, agenţiile
oferă o mare varietate de camere, cu capacităţi diferite, astfel încât studenţii pot să-şi rezerve
camera pe care o doresc. Familiile pot rezerva apartamente sau camere de două persoane.
În septembrie, firma Turism pentru Studenţi generează o listă a agenţiilor, săptămânile
disponibile, preţul camerelor, listă pe care o transmite secretariatelor de la facultăţi. Când un grup
de studenţi depune o cerere de rezervare pentru o anumită săptămână şi o anumită agenţie, TS
atribuie studenţilor camere cu suficiente locuri şi transmite fiecărui student o notă de confirmare. Cu
o săptămână înainte de cea pentru care au fost făcute rezervările, TS trimite fiecărei agenţii lista
studenţilor pentru care s-au făcut rezervările pe fiecare cameră. Studenţii fac plata la hotelurile unde
şi-au făcut rezervările atunci când ajung. Agenţiile trimit comisioanele direct sistemului contabil al
firmei TS, sistem separat de cel care ţine evidenţa rezervărilor.
Se cer:
a. identificarea evenimentelor la care sistemul de rezervări de la TS trebuie să asigure declanşarea
prelucrărilor;
b. crearea unui tabel complet al evenimentelor, care să conţină evenimentul, declanşatorul, sursa,
acţiunea sistemului, răspunsul, destinaţia. Atenţie la evenimente, pentru a nu le surprinde pe
cele care sunt declanşate pentru a fi prelucrate de sistemul contabil al TS sau al agenţiilor.
2. „Casa” este o societate imobiliară cu mai multe birouri. Sistemul de evidenţă a imobilelor oferă
informaţii pe care agenţii imobiliari le folosesc pentru a-i ajuta în vânzarea de locuinţe. În timpul
lunii, agenţii listează casele disponibile pentru vânzare, prin contractarea lor cu proprietarii. Agenţii
STUDIEREA SISTEMULUI EXISTENT ŞI DETERMINAREA CERINŢELOR 109
sunt arondaţi la un birou imobiliar, care transmite informaţiile colectate către sistemul centralizat al
societăţii. De aceea, orice agent dintr-o anumită zonă poate obţine informaţiile de care are nevoie.
Informaţiile incluse în liste cuprind adresa, anul construirii, suprafaţa, numărul de dormitoare,
numărul de băi, numele proprietarului, numărul de telefon, preţul cerut, starea imobilului (vândut sau
disponibil). În orice moment al lunii, un agent poate contacta serviciul centralizat pentru a obţine
listele cu imobilele ce corespund cerinţelor unui cumpărător. Astfel, sunt oferite informaţii
suplimentare sau ar putea fi contactat direct proprietarul pentru a stabili o întâlnire ca să fie văzut
imobilul. De două ori pe lună (pe 15 şi pe 30 ale lunii), serviciul centralizat generează un registru ce
conţine informaţiile despre toate imobilele înregistrate şi incluse în listele cu descrierea fiecărui
imobil, registru transmis agenţilor imobiliari. Mulţi agenţi doresc acest registru pentru că este mult
mai uşor de utilizat, având la dispoziţie informaţii despre toate imobilele şi nu numai cele care
răspund cerinţelor unui anumit cumpărător. Uneori, agenţii şi proprietarii decid modificarea
informaţiilor pe o anumită listă, cum ar fi reducerea preţului, corectarea unor informaţii privind
imobilul sau pentru a indica vânzarea imobilului. Birourile imobiliare transmit aceste modificări
către serviciul centralizat atunci când agenţii vor acest lucru.
Se cer:
a. Care sunt evenimentele cărora trebuie să le răspundă sistemul de evidenţă a imobilelor?
b. Realizarea unui tabel complet al evenimentelor.
c. Identificarea cerinţelor funcţionale şi tehnice ale sistemului.
CAPITOLUL VI
Aşa cum s-a văzut din capitolele anterioare, obiectivul de bază al etapei de analiză constă
în înţelegerea funcţiilor economice şi determinarea cerinţelor sistemului. Problema care se
ridică, de cele mai multe ori, este dacă să se studieze şi modeleze/documenteze şi sistemul
curent sau numai cel nou. Când a fost lansată metodologia structurată, ca şi alte metodologii,
analiştii mai întâi studiau şi documentau sistemul existent, după care încercau să identifice
cerinţele pentru cel nou pe baza caracteristicilor celui vechi. Pentru acea perioadă, în vederea
determinării cerinţelor, se desfăşurau patru mari patru mari activităţi:
identificarea proceselor şi activităţilor fizice ale sistemului existent;
extragerea, din punct de vedere logic, a funcţiilor corespunzătoare proceselor fizice;
stabilirea, din punct de vedere logic, a funcţiilor ce urmează a fi incluse în noul sistem;
definirea cerinţelor fizice de prelucrare pentru noul sistem.
După unii autori, unul din marile dezavantaje ale unei astfel de abordări îl constituie
timpul mare alocat activităţii de analiză, o adevărată problemă pentru că, adesea, dezvoltarea
sistemului constă doar în automatizarea celui existent şi, ca atare, nu conta cât de ineficient era
cel vechi, pentru că oricum vechile proceduri erau înlocuite.
În prezent, într-o lume a competitivităţii, multe firme urmăresc implementarea noilor
tehnologii, în vederea creşterii avantajelor lor strategice, reproiectând în totalitate procedurile
interne pentru a beneficia de avantajele aduse de acestea. Rămâne la fel de importantă
stabilirea setului corect şi complet al cerinţelor sistemului, dar, într-o lume a vitezei, se
consideră că nu este timp şi nu sunt nici resurse suficiente pentru a revedea şi documenta toate
procedurile ineficiente ale vechiului sistem, astfel că analiştii fac apel la o abordare mai rapidă,
prin echilibrarea procesului de revizuire a funcţiilor curente şi a celui de identificare a
cerinţelor noului sistem. De aceea, atenţia în timpul etapei de analiză se concentrează pe
dezvoltarea setului de cerinţe logice ale sistemului.
Analiştii studiază sistemul curent numai atunci când trebuie să înţeleagă cerinţele
economice şi nu pentru a defini procesele specifice vechiului sistem, deoarece trebuie să
cunoască în detaliu nevoile firmei (pe principiul „walk the walk and talk the talk”), dar nu
trebuie să cadă în capcana metodelor vechi, ineficiente. Aşadar, analistul va trebui să
demonstreze o deplină stăpânire de sine.
Dezvoltarea modelului logic al noului sistem are loc pe măsură ce se culeg informaţiile
despre cerinţele sistemului, modelarea fizică a acestuia (cum va fi construit sistemul) rămânând
o sarcină a etapei următoare, proiectarea. De bază sunt informaţiile care permit construirea
modelului logic al noului sistem, existând trei întrebări majore asupra cărora ar trebui să se
orienteze desfăşurarea activităţii de studiere a sistemului şi de determinare a cerinţelor:
1. Care sunt procesele şi funcţiile economice?
Se urmăreşte obţinerea unei liste atotcuprinzătoare a proceselor economice. În majoritatea
cazurilor, utilizatorii sunt cei care oferă informaţiile, plecând de la ce se întâmplă în vechiul
sistem, astfel că analiştii trebuie să discearnă cu atenţie care sunt funcţiile fundamentale ce se
vor păstra şi ce trebuie să se elimine sau să se adauge pentru îmbunătăţirea sistemului.
METODE DE CULEGERE A CERINŢELOR SISTEMULUI 111
6.1 Intervievarea
Intervievarea este de departe una din cele mai bune metode de a înţelege funcţiile şi
regulile economice, dar şi activitatea cea mai consumatoare de timp şi alte resurse. Este o cale
relativ uşoară prin care utilizatorii pot să-şi exprime intenţiile în legătură cu sistemul dorit, cu
ajutorul propriului limbaj, şi pot controla perioada de timp pe care o alocă interviului.
Interviul, potrivit definiţiei date de Charles J. Stewart şi William B. Cash Jr.1, este
procesul comunicării diadice, de stabilire a unei relaţii cu o finalitate precisă, predeterminată,
proces conceput pe alternanţa rolurilor şi care implică formulări de întrebări şi obţinerea de
răspunsuri.
Formularea de întrebări şi obţinerea răspunsurilor constituie procesele esenţiale ale
interviului. Puţine sunt interviurile care să nu necesite o structurare prealabilă a întrebărilor.
1. Stewart, J.C., Cash, Jr., W.B. – Interviewing, Principles and Practices, Wm.C. Brown Publishers, Dubuque,
1991, p. 3.
2. Stewart, J.C., Cash, Jr., W.B. – op. cit., pp. 5-7.
METODE DE CULEGERE A CERINŢELOR SISTEMULUI 113
Tipurile de întrebări3 posibil de utilizat în structura unui interviu sunt redate în tabelul 6.3.
Sfaturi finale pentru operatorii interviului
Indiferent de tipul întrebărilor, nu le formulaţi astfel încât să poată conduce la
răspunsuri convenabile sau condamnabile.
Ascultaţi cu atenţie tot ce se afirmă în timpul interviului.
După terminarea interviului, în cel mult 48 de ore, sintetizaţi rezultatele la care aţi
ajuns.
În timpul interviului, nu vă pronunţaţi asupra a ceea ce va fi cu siguranţă în viitor.
Scade rolul interviului.
Abordaţi sistemul analizat din mai multe perspective (a potenţialilor utilizatori, a
utilizatorilor unor sisteme similare, a celor afectaţi de schimbarea sistemului, a
managerilor, a controlorilor, a informaticienilor).
Indiferent de stilul folosit la intervievare, nu uitaţi că politeţea joacă rolul cel mai
important.
Chiar dacă aţi efectuat multe interviuri, de fiecare dată alcătuiţi un plan de derulare a
următorului interviu.
Nu abuzaţi de drăgălăşenia (se poate citi şi politeţea) celui intervievat, prelungind cu
mult timpul planificat pentru derularea acestuia.
Nu ezitaţi să reveniţi cu un telefon scurt, însoţit de scuzele de rigoare, pentru a lămuri
ceva ce nu vă este prea clar; nu improvizaţi răspunsuri în contul intervievaţilor.
3. Prelucrare după colectiv FIMAN, Centrul de consiliere în cariera profesională – Manual de înfiinţare şi operare,
Ed. Expert, Bucureşti, 1997, pp. 94-97.
METODE DE CULEGERE A CERINŢELOR SISTEMULUI 115
Dezavantaje Ascunde informaţii Stimulează Răspunsul poate Poate părea o Totul se reduce la
Ştie interogatoriul vorbăreţii fi NU eschivă doar două variante
6.2 Chestionarele
Spre deosebire de interviuri, chestionarele sunt mai puţin costisitoare şi, într-un timp
relativ scurt, pot oferi un volum mare de informaţii necesare analizei sistemului. Cu ajutorul
chestionarelor, analiştii pot studia atitudinea, comportamentul şi caracteristicile persoanelor-
cheie din firmă afectate de sistemul curent sau de cel nou. Atitudinea înseamnă identificarea a
ceea ce spun utilizatorii că şi-ar dori de la sistem, comportamentul – ce fac utilizatorii, iar
caracteristicile – trasăturile utilizatorilor.
Prin utilizarea chestionarelor se urmăreşte obţinerea de detalii preliminare privind
cerinţele informaţionale ale diferitelor persoane interesate de sistem, ajutând la identificarea
domeniilor ce necesită cercetări suplimentare cu ajutorul interviurilor, analizei documentelor şi
al observării. Chestionarele permit obţinerea unor informaţii de natură cantitativă, plecând de
la întrebări de genul: „Ce formulare folosiţi pentru introducerea datelor despre clienţii noi?”,
„În medie, cât durează introducerea datelor de pe o comandă?”. De asemenea, sunt folosite
pentru a identifica opinia utilizatorilor faţă de anumite aspecte privind sistemul, cu ajutorul
unor întrebări de forma: „Pe o scară de la 1 la 7, specificaţi cât de importantă este
disponibilitatea sistemului privind accesul la istoricul operațiilor cu clienţii?”. Astfel de
întrebări direcţionează persoanele chestionate să răspundă numai la întrebarea pusă, fără să
lase loc de interpretări sau discuţii.
Chestionarul este folosit când este necesar să se culeagă informaţii de la un număr mai
mare de persoane din cadrul organizaţiei. El poate fi folosit când4:
persoanele importante pentru sistem sunt dispersate teritorial;
volumul informaţiilor ce trebuie culese este relativ mic, dar există foarte multe
persoane implicate în proiect;
este necesară o acţiune de cercetare, înainte ca interviurile să aibă loc, de exemplu
atunci când trebuie identificate problemele sistemului;
se verifică datele culese cu ajutorul altor metode.
Una din problemele pe care le ridică utilizarea chestionarului constă în faptul că
utilizatorilor s-ar putea să li se pară dificil să-şi specifice cerinţele sub formă scrisă pentru o
4. Flynn, D. – Information Systems Requirements: Determination & Analysis, 2nd Edition, McGraw Hill Companies,
London, 1998, p. 138.
116 ANALIZA SISTEMELOR INFORMAŢIONALE
serie de întrebări deschise, pentru că procesul poate să le ia mai mult timp decât dacă ar fi
răspuns acelor întrebări prin intermediul unui interviu. De asemenea, chestionarul s-ar putea să
nu conţină exact întrebările la care se aşteptau să răspundă pentru a-şi specifica cerinţele.
La prima vedere, chestionarele par a fi cea mai rapidă modalitate de culegere a unui
volum relativ mare de informaţii despre modul în care utilizatorii văd sistemul curent, despre
problemele cu care se confruntă în activitatea lor şi despre ce se aşteaptă de la noul sistem.
Chiar dacă este într-o anumită măsură adevărat că se pot culege mai multe informaţii într-un
timp mai scurt faţă de interviu, elaborarea unor chestionare eficiente solicită un timp destul de
mare pentru pegătirea şi conceperea lor. În primul rând, este necesar să se stabilească cu
claritate ce se doreşte să se obţină prin utilizarea sondajului pe bază de chestionar. De
exemplu, dacă se încearcă să se identifice care este procentul de utilizatori ce preferă existenţa
unei pagini cu întrebări frecvente (FAQs) ca mijloc de învăţare a noilor aplicaţii, un chestionar
ar fi cea mai adecvată tehnică. Dacă însă se doreşte să se analizeze detaliat procesul pe care îl
parcurge un manager pentru luarea unei decizii, interviul ar fi o opţiune mai bună.
Deoarece conceperea chestionarului este mai mult o artă decât o ştiinţă, specialiştii s-au
străduit să-şi prezinte experienţa sub forma unor reguli, recomandate îndeosebi începătorilor;
cei cu state vechi le pot utiliza drept elemente de comparaţie pentru a-şi evalua paşii întregii
proceduri. Din aceste motive, considerăm de bun augur descrierea paşilor parcurşi pentru
conceperea unui chestionar în viziunea lui Gilbert Churchill, Jr.5, conform figurii nr. 6.3.
5. Churchill, Jr., G.A. – Basic Marketing Research, The Dryden Press, Chicago, 1988, pp. 269-297.
METODE DE CULEGERE A CERINŢELOR SISTEMULUI 117
6. Malhotra, N.K. – Marketing Research – An Applied Orientation, Prentice Hall, Upper Saddle River, New Jersey,
1996, pp. 166-167.
118 ANALIZA SISTEMELOR INFORMAŢIONALE
folosirea mai eficientă a timpului alocat interviului decât în varianta unei serii de
interviuri individuale;
intervievarea concomitentă a mai multor persoane le permite acestora să-şi asculte
reciproc declaraţiile, fie pentru a le susţine, fie pentru a le combate, fie pentru a se
formula noi păreri;
prin interviuri colective se pot efectua delimitări clare între punctele de vedere
acceptate de toţi intervievaţii şi cele ce stârnesc mari divergenţe.
Ca dezavantaj principal: dificultatea planificării calendaristice a desfăşurării interviului,
datorită implicării mai multor persoane care trebuie să participe concomitent la acest proces.
Tehnologiile moderne, îndeosebi diferitele forme ale videoconferinţelor, pot simplifica
procesul intervievării colective, minimizând influenţa nefastă a dispersiei geografice care face
dificilă întâlnirea membrilor grupului.
de timp. Ca şi în cazul interviurilor, este mult mai benefic dacă la observare ar participa doi
analişti, pentru a combina eforturile şi rezultatele procedurilor de observare9.
Observarea utilizatorilor poate fi clasificată după mai multe criterii, şi anume:
1. după modul în care sunt stabilite elementele ce vor fi supuse observării10:
structurată, când analiştii specifică în detaliu ce va fi supus observării şi cum vor fi
înregistrate rezultatele observării. Acest lucru reduce tendinţa ca analistul să afecteze
credibilitatea datelor. Observarea structurată este recomandată atunci când problema
analizată a fost foarte clar definită şi s-au stabilit cu exactitate informaţiile necesare
rezolvării ei. În aceste circumstanţe, se desprind cu lejeritate detaliile despre
activităţile supuse observării.
nestructurată, când analistul monitorizează toate aspectele despre activităţile de interes
care par a fi relevante pentru problema identificată. Această formă de observare se
aplică atunci când problema urmează să fie formulată în mod explicit şi când, pentru
identificarea componentelor cheie ale problemei şi pentru dezvoltarea ipotezelor de
lucru, este cerut un anumit grad de flexibilitate. În observarea nestructurată, tendinţa
analistului de a fi influenţat de aspectele observate este foarte mare. Din această cauză,
elementele supuse observării trebuie să fie tratate ca ipoteze de verificat şi nu ca
aspecte concludente ale problemei analizate.
2. după modul în care se stabileşte momentul desfăşurării11:
observarea pe bază de intervale de timp, prin alegerea aleatoare a unor perioade din zi,
ceea ce înseamnă că pot fi observate activităţile pe care le desfăşoară în mod curent
utilizatorii. Însă, printr-o astfel de modalitate, se culeg date fragmentate ce nu asigură
analiza completă a unui eveniment, de la iniţierea şi până la finalizarea lui. De
asemenea, în cazul unor evenimente ce au loc la intervale mai mari de timp, e posibil
ca acestea să nu poată fi surprinse prin momentul stabilit;
observarea pe bază de evenimente, ce permite analiza completă a comportamentului în
contextul natural, de la iniţierea evenimentului şi până la studierea efectelor acestuia.
Însă, nici această formă de observare nu este lipsită de dezavantaje, datorită duratei
relativ mari de aşteptare până la apariţia unui eveniment sau a perioadei mari de timp
pe care o presupune realizarea lui; apare şi riscul de a omite activităţile curente care au
loc în cadrul sistemului. Ca atare, analiştii apelează, de multe ori, la o combinaţie a
celor două tipuri de observări, pentru a analiza atât activităţile curente, cât şi pe cele
care au loc doar în anumite condiţii.
3. în funcţie de înştiinţarea sau nu a utilizatorilor:
camuflată, ceea ce presupune că persoanele observate nu sunt înştiinţate că vor fi
supuse observării. Această formă dă posibilitatea utilizatorilor de a avea un
comportament natural, pentru că oamenii au întotdeauna tendinţa de a se comporta
diferit când ştiu că sunt supuşi observării.
necamuflată, care presupune înştiinţarea utilizatorilor că vor fi supuşi unei observări.
De exemplu, li se poate spune că analistul va sta o perioadă de timp printre ei. Acest
tip de observare nu este foarte des practicat. Se consideră că persoanele observate îşi
vor modifica comportamentul pe perioada prezenţei analistului printre ele.
4. după cadrul în care se va desfăşura observarea:
naturală, constă în observarea comportamentului în mediul de lucru al utilizatorilor.
De exemplu, observarea celor care lucrează cu o anumită aplicaţie în cadrul biroului în
care ei îşi desfăşoară activitatea zi de zi. Avantajul observării naturale îl constituie
faptul că activităţile observate vor reflecta adevărata lor valoare. Dezavantajul constă
Sursele externe sunt cele provenite de la organizaţiile profesionale din domeniul în care
activează firma sau de la alte firme din aceeaşi ramură de activitate. Uneori, revistele de
specialitate prezintă studii privind „cele mai bune practici” şi rezultatele obţinute de diferite
firme în dezvoltarea şi implementarea unor sisteme, cum ar fi relatarea cazurilor de succes în
implementarea sistemelor ERP. De asemenea, prin extinderea graniţelor organizaţionale,
sursele externe devin din ce în ce mai importante pentru identificarea cerinţelor informaţionale,
presupunând investigarea practicilor şi procedurilor partenerilor de afaceri implicaţi în lanţul
valoric al firmei.
Sursele interne servesc pentru atingerea a două obiective. Primul este de a înţelege, în
special de către membrii echipei ce nu cunosc îndeajuns de bine firma, procesele economice
ale acesteia, dar şi pentru stabilirea întrebărilor din interviuri şi chestionare. Al doilea scop îl
constituie utilizarea documentelor existente în timpul interviurilor pentru a asigura o mai bună
comunicare şi înţelegere a întrebărilor şi răspunsurilor de către ambele părţi. Formularele şi
rapoartele pot servi la vizualizarea unor aspecte ce sunt subiectul interviurilor, dar şi ca
documente de lucru pentru discuţiile dintre membrii echipei proiectului, care se concentrează
pe utilizarea fiecărui formular, obiectivele utilizării lui, distribuţia, conţinutul, precum şi
evenimentele ce declanşează folosirea acestuia. Este posibil ca evenimente economice diferite
să solicite acelaşi formular, iar identificarea informaţiilor despre evenimentele şi procesele
economice devine esenţială. În această activitate, este util ca echipa să apeleze la formulare ce
sunt completate cu date reale pentru a se asigura că s-a obţinut o imagine clară şi s-a înţeles
rolul fiecărui element din formular şi conţinutul său în ansamblu.
Analiza documentaţiei privind procedurile existente ajută la identificarea regulilor
economice care e posibil să nu poată fi desprinse în timpul interviurilor, precum şi la
descoperirea unor redundanţe ce apar la nivelul proceselor economice. Totuşi, se întâmplă ca
unele manuale ce descriu procedurile de lucru să nu fie actualizate şi să conţină anumite erori
care nu au fost eliminate. De aceea, pentru a se asigura că ipotezele de lucru şi regulile
economice identificate în documentaţia existentă sunt corecte, este necesar ca analiza lor să se
efectueze împreună cu utilizatorii.
Documentele ce pot fi studiate sunt de o mare diversitate. Tratamentul lor în materialul de
faţă nu poate fi exhaustiv. Dintre documentele mai des solicitate fac parte: declararea viziunii,
misiunii şi strategiei organizaţiei, obiectivele acesteia, planurile de afaceri, studiile de
fezabilitate, structura organizatorică (organigrama), planul sistemului informaţional anterior
sau curent, regulamentele de organizare şi funcţionare, a celor de ordine interioară, normele
interne de fabricaţie, standardele folosite, fişele posturilor, corespondenţa internă şi externă,
rapoartele de analiză obţinute din studii anterioare ş.a. Astfel, documentele analizate pot fi
grupate în mai multe categorii15:
rapoartele generate de sistemul actual;
procedurile de lucru pentru activităţi individuale sau ale grupurilor. Prin ele se descrie
modul în care se exercită o anumită activitate, prezentându-se şi datele şi/sau informaţiile
pe care le solicită sau le generează. Analiza procedurilor poate evidenţia:
repetarea activităţilor în două sau mai multe locuri de muncă declarate cu sarcini
diferite;
absenţa procedurilor de lucru pentru unele activităţi;
depăşirea valabilităţii în timp a procedurii;
procedurile formale contrazise de realitatea constatată prin interviuri, chestionare şi
alte metode folosite la studierea sistemului;
formularele utilizate de unitate pentru toate operațiile interne şi externe;
documentaţia folosită în sistemul informatic (numai în cazul sistemelor de prelucrare
automată a datelor).
15. Hoffer, J.A., George, J.F., Valacich, J.S. – Modern Systems Analysis and Design, The Benjamin/Cummings
Publishing Company, Inc., Sand Hill Road, Menlo Park, 1998.
METODE DE CULEGERE A CERINŢELOR SISTEMULUI 123
Rezumat
Timpul necesar culegerii informaţiilor este imens, iar cheltuielile sunt pe măsură. Este necesară
cunoaşterea sloganului care circulă printre analişti „analysis paralysis” (analizele paralizează), referindu-
se la excesele de zel din faza de analiză.
Ca efect al tendinţelor de mărire a timpului de analiză a sistemelor existente, în ultimii ani, s-a
efectuat trecerea spre analiza cu ajutorul unor tehnici mai rapide. Astfel, tehnicile moderne, JAD şi
prototipizarea, preiau tot mai puţine elemente din sistemele existente, ca urmare a analizelor efectuate.
Altele, mai radicale, renunţă aproape total la analiza sistemului existent. Este cazul proceselor controlate
124 ANALIZA SISTEMELOR INFORMAŢIONALE
prin RAD (Rapid Application Development), care apelează la JAD, prototipizare şi alte instrumente
integrate de tip CASE.
Metodele tradiţionale de colectare a cerinţelor sistemului sunt: interviuri individuale; anchete
realizate prin chestionare; intervievarea grupurilor de oameni cu interese comune; observarea
personalului; studierea documentaţiei firmei.
Intervievarea este de departe una din cele mai bune metode de a înţelege funcţiile şi regulile
economice, dar şi activitatea consumatoare de timp şi alte resurse, fiind calea relativ uşoară prin care
utilizatorii pot să-şi exprime planurile lor pentru sistemul dorit, cu ajutorul propriului limbaj, şi pot
controla perioada de timp pe care o alocă interviului.
Etapele de bază ale unui interviu sunt: planificarea (pregătirea) interviului, desfăşurarea propriu-
zisă şi finalizarea şi stabilirea activităţilor postinterviu.
Indiferent de tipul interviului, unele principii şi tehnici au o aplicabilitate generală. Acestea sunt
împărţite în trei părţi majore: deschiderea, partea principală, închiderea.
Spre deosebire de interviuri, chestionarele sunt mai puţin costisitoare şi, într-un timp relativ scurt,
pot oferi un volum mare de informaţii necesare analizei sistemului. Prin utilizarea chestionarelor se
urmăreşte obţinerea de detalii preliminare privind nevoile informaţionale ale diferitelor persoane
interesate de sistem, ajutând la identificarea domeniilor ce necesită cercetări suplimentare cu ajutorul
interviurilor, analizei documentelor şi al observării.
Paşii pentru conceperea unui chestionar sunt: identificarea informaţiilor ce vor fi căutate, stabilirea
tipului de chestionar şi a metodei de administrare, determinarea conţinutului fiecărei întrebări,
stabilirea formei de redactare a răspunsului la fiecare întrebare, formularea întrebărilor, stabilirea
secvenţei derulării întrebărilor, stabilirea caracteristicilor tehnice ale chestionarului, reevaluarea
paşilor anteriori şi revizuirea lor, efectuarea pretestului şi revizuirea finală.
Un inconvenient al aplicării interviurilor şi chestionarelor pentru colectarea cerinţelor sistemelor îl
constituie apariţia unor contradicţii aparente între datele colectate; reconcilierea lor presupune intervenţia
analistului. Operaţiunea salvatoare este cea a intervievării grupurilor. Printr-un interviu al grupului are
loc intervievarea concomitentă a unui grup de persoane-cheie.
Paşii care se parcurg pentru planificarea şi desfăşurarea interviurilor de grup sunt: determinarea
obiectivelor proiectului pentru care se intervievează grupul şi definirea problemei; specificarea
obiectivelor acţiunii care se va întreprinde (ale interviului); stabilirea obiectivelor/întrebărilor la care
vor răspunde participanţii grupului; redactarea unui plan de interviu; dezvoltarea rolului
moderatorului; conducerea interviului de grup; revederea casetelor şi analiza datelor; sintetizarea
elementelor identificate în urma interviului de grup.
Observarea uilizatorilor presupune înregistrarea comportamentului de bază al persoanelor,
obiectelor sau evenimentelor într-o manieră sistematică pentru obţinerea informaţiilor despre un anumit
element (fenomen) de interes din cadrul sistemului. Observatorul nu întreabă şi nici nu comunică cu
persoanele observate.
Metodele amintite anterior pot fi completate cu examinarea documentaţiei sistemului şi a
organizaţiei, pentru obţinerea celor mai relevante date despre sistemul analizat. Analiza documentaţiei
privind procedurile existente ajută la identificarea regulilor economice care e posibil să nu poată fi
desprinse în timpul interviurilor, precum şi la descoperirea unor redundanţe ce apar la nivelul proceselor
economice.
Metodelor tradiţionale, prezentate anterior, li se adaugă aşa-zisele metode moderne, dintre care
amintim: Joint Application Design (JAD), sistemele de sprijinire a grupurilor, instrumentele CASE şi
prototipizarea. Toate aceste metode sprijină procesul de culegere şi structurare a informaţiilor prin
diminuarea substanţială a timpului dedicat analizei de sistem.
Întrebări recapitulative
1. Enumeraţi paşii specifici derulării unui interviu.
2. Care sunt paşii care se parcurg pentru conceperea unui chestionar?
3. Prezentaţi comparativ caracteristicile interviului şi chestionarului.
4. În ce situaţii se impune utilizarea interviului de grup?
5. Enumeraţi şi descrieţi principalele caracteristici ale unui grup de care trebuie să se ţină cont în
intervievarea lui.
METODE DE CULEGERE A CERINŢELOR SISTEMULUI 125
Probleme de echipă
1. A fost planificat un interviu cu managerul de vânzări al unei firme de papetărie, care doreşte să
prezinte o serie de informaţii despre produse şi vânzări pe Intranet, astfel încât toţi angajaţii să aibă
acces la ele pentru îmbunătăţirea prognozelor privind vânzările. Reformulaţi următoarele întrebări,
ştiind că, aşa cum sunt prezentate, nu au fost formulate corespunzător:
a) Personalul de vânzări din subordine a specificat faptul că aveţi reţineri în privinţa utilizării
calculatorului. Este adevărat?
b) Ce surse de informaţii folosiţi cel mai mult pentru analiza vânzărilor şi cât de frecvent?
c) Sunteţi de acord cu plasarea lunară a informaţiilor privind vânzările pe Intranet pentru realizarea
analizelor de vânzări şi îmbunătăţirea esenţială a sistemului de vânzări?
d) Nu credeţi că este o cale mult mai bună decât cea folosită până acum?
2. Ca echipă de analiză pentru un proiect de îmbunătăţire a funcţiilor sistemului contabil al unei firme
de ceasuri, urmează să-l intervievaţi pe contabilul-şef. Formulaţi 4-6 obiective ale interviului care să
acopere sursele de informaţii pe care le foloseşte, formatul rapoartelor, frecvenţa luării deciziilor,
calitatea informaţiilor dorite.
a) Într-un paragraf, precizaţi cum îl veţi aborda pe contabilul-şef pentru planificarea interviului.
b) Stabiliţi structura interviului pe care o veţi alege şi motivaţi propunerea.
c) Contabilul-şef are în subordine 3 salariaţi care folosesc sistemul. Îi veţi intervieva şi pe ei?
Motivaţi dacă este necesar sau nu.
d) Formulaţi 3 întrebări deschise pe care le veţi transmite prin e-mail contabilului-şef înainte de a
se desfăşura interviul. Explicaţi de ce este de preferat să se realizeze interviul faţă-în-faţă şi nu
prin intermediul e-mailului.
e) Formulaţi cel puţin 5 întrebări închise prin care să obţineţi informaţiile privind formatul
rapoartelor şi calitatea informaţiilor solicitate.
CAPITOLUL VII
Obiective:
Înţelegerea conceptului de modelare a proceselor de prelucrare a datelor, redat
prin intermediul diagramelor fluxurilor de date (DFD)
Descrierea principalelor simboluri utilizate în construirea DFD de către două
din cele mai utilizate tehnici de modelare: Gane & Sarson şi Yourdon & DeMarco
Prezentarea paşilor care se parcurg şi a recomandărilor pentru construirea DFD
Definirea regulilor care stau la baza construirii DFD
Cunoaşterea aspectelor privind descrierea modelului logic al sistemului cu ajutorul
depozitelor de metadate
Toate informaţiile culese despre cerinţele sistemului trebuie să fie înregistrate sub o formă
sau alta, fie că este vorba despre cele funcţionale (CE trebuie să facă sistemul), fie despre cele
tehnice (CUM trebuie să facă sistemul), iar pentru acest lucru se apelează la diferite modele, ce
permit păstrarea lor într-un format structurat. Modelele care se construiesc au şi rolul de a
asigura comunicarea mai uşoară între cei care participă la dezvoltarea sistemului sau sunt
afectaţi de el (beneficiari, utilizatori, finanţatori, echipa de dezvoltare).
Procesul de modelare poate fi considerat ca un proces de învăţare, pentru că pe măsura
creării modelului, echipa de analiză învaţă tot mai mult despre sistem, continuând pe măsura
culegerii cerinţelor, modelele fiind revizuite împreună cu utilizatorii pentru a le verifica,
corecta şi completa.
De asemenea, crearea unor modele grafice ale sistemului, cu ajutorul diferitelor diagrame,
este utilă pentru a obţine o imagine mult mai clară asupra principalelor componente ale
acestuia. Modelarea conceptuală (logică) a sistemului reprezintă începutul activităţilor cu
caracter tehnic din dezvoltarea acestuia, cu scopul de a completa documentaţia de analiză şi de
a reda cuprinzător elementele ce vor fi supuse proiectării.
înţelegerea mult mai uşoară a relaţiilor care există între sistem şi mediul extern,
deosebit de importantă pentru identificarea frontierelor acestuia şi a funcţiilor pe care
trebuie să le îndeplinească;
comunicarea eficientă şi lejeră cu utilizatorii, analiştii putând să solicite efectuarea
unor observaţii suplimentare, pentru completarea şi corectarea modului de
conceptualizare a sistemului, încorporând modificările solicitate de utilizatori, astfel
încât sistemul să redea cât mai bine punctul lor de vedere. Chiar dacă majoritatea
autorilor consideră că prin intermediul diagramelor (modelelor) este mult mai uşor să
se comunice cu utilizatorii, ceea ce este adevărat, acest avantaj nu se obţine automat,
pentru că ei trebuie să fie pregătiţi, în prealabil, pentru a înţelege scopul şi rolul
diagramelor, nicidecum de a crea o şi mai mare confuzie;
analiza sistemului propus pentru identificarea corectă a datelor şi proceselor
necesare, astfel încât analiza să fie o etapă prin care să se asigure că toate ieşirile
solicitate pot fi obţinute din datele de intrare preluate de sistem şi că logica
prelucrărilor este reflectată prin intermediul diagramelor. Spre deosebire de analiza
fluxului activităţilor, care prezintă modul de derulare a acestora în formă manuală sau
automată, în ordine cronologică, diagramele pun accentul pe prelucrarea datelor şi
transformarea acestora, pe măsura trecerii lor prin diferite procese, fără a se face nici o
diferenţiere între cele manuale sau automate şi fără a se reda secvenţa lor cronologică,
urmărindu-se doar o eventuală grupare a lor, din punct de vedere al logicii
prelucrărilor;
neincluderea aspectelor tehnice de implementare în etapa de analiză, în sensul că nici
un simbol, cel puţin în modelul logic, nu abordează elementele tehnice de
implementare, care ar putea îngreuna nivelul de înţelegere a utilizatorilor. De
asemenea, acest avantaj elimină riscul stabilirii, încă din etapa de analiză, a unor
tehnologii care se pot dovedi inadecvate în momentul proiectării şi implementării. De
exemplu, chiar dacă prin diagrame se semnalează faptul că datele sunt memorate într-
un loc de stocare, nu se redă sistemul de gestiune a datelor și/sau suportul fizic de
stocare a lor. Astfel, analistul poate conceptualiza fluxurile de date necesare, evitând
redarea aspectelor ce ţin de realizarea lor tehnică.
Există două mari categorii de modele ale sistemului1:
Modelul logic prin care se reprezintă Ce trebuie să facă sistemul, concentrându-se asupra
operaţiilor economice şi a modului în care funcţionează firma sau o anumită componentă
economică a sa, fără a se face trimitere la nici o tehnologie. Echipa de analiză îşi va orienta
eforturile spre ceea ce este necesar şi nu asupra modului în care urmează să se contureze
sistemul. De exemplu, un model poate specifica o ieşire a sistemului ca pe o listă de date
elementare, fără a face trimitere dacă va fi pe hârtie sau afişată pe ecran. Modelul logic are ca
scop reprezentarea informaţiilor de care au nevoie utilizatorii, descriind evenimentele care au
loc şi datele cerute sau generate de fiecare eveniment.
Modelul fizic redă modul în care sistemul va fi implementat, astfel că va deţine mai multe
detalii despre formatul ieşirilor, al ecranelor de preluare a datelor, a modului de interconectare
a reţelelor etc. De aceea, el va surprinde aspectele legate de echipamente, software, baze de
date şi sisteme de gestiune a lor, resurse umane pe care le presupun implementarea şi
exploatarea sistemului.
În tabelul 7.1 sunt prezentate caracteristicile urmărite prin cele două modele. De reţinut că
modelul logic reflectă componenta economică pe care sistemul trebuie să o redea, în timp ce
modelul fizic descrie componentele fizice necesare realizării funcţiilor acestuia. Diferenţa
dintre cele două scoate în evidenţă diferenţa dintre analiza sistemului şi proiectarea lui. În
1. Kendall, K.E., Kendall, J.E. – Systems Analysis and Design, 5th Edition, Prentice Hall, Upper Saddle River, New
Jersey, 2002, p. 251; Satzinger, J.W., Jackson, R.B., Burd, S.D. – Systems Analysis and Design in a Changing
World, Second Edition, Course Technology, Thomson Learning, Boston, 2002, p. 110.
128 ANALIZA SISTEMELOR INFORMAŢIONALE
general, analiza presupune crearea de modele logice detaliate, în timp ce proiectarea se bazează
pe cele fizice. Variantele de proiectare create în timpul analizei sunt modele fizice, dar nu
surprind detaliile specifice etapei de proiectare.
Tabel nr. 7.1 – Caracteristicile modelului logic şi fizic al sistemului
Caracteristici Model logic Model fizic
Scopul modelului Ce trebuie să facă sistemul şi cum Cum va fi implementat sistemul sau cum
funcţionează organizaţia sau o va funcţiona el.
componentă economică a sa.
Componentele Activităţile/evenimentele Programele, modulele şi procedurile
reprezentate economice. manuale sau automate ce vor fi executate.
Locurile de stocare Colecţiile de date cu privire la Fişiere şi baze de date sau dosare, registre
redate operaţiile economice, fără a în situaţia sistemelor manuale.
surprinde modul în care datele sunt
memorate şi gestionate.
Tipul datelor La definirea datelor se utilizează În funcţie de sistemul de gestiune a
memorate tipuri comune de date (numeric, bazelor de date, se aleg cele mai potrivite
caracter, tip dată calendaristică). tipuri de date
Controlul sistemului Redă politicile de control economic. Redă controlul pentru validarea datelor de
intrare, obţinerea înregistrărilor, pentru
asigurarea finalizării unui proces, pentru
asigurarea securităţii.
Indiferent de tipul sistemului analizat, manual sau informatizat, o problemă este comună: el
va fi înlocuit de un nou sistem. Oricât de ineficient ar fi, vechiul sistem trebuie să transfere celui
nou o serie de elemente, cum sunt datele folosite, procedurile existente. Deci, sistemul fizic actual
efectuează, în parte sau în întregime, ceea ce-şi propune să facă noul sistem fizic, dar la alt nivel
de performanţă. Tocmai necesitatea trecerii de la vechiul la noul sistem ne obligă să decidem
asupra celor două elemente specificate anterior, date şi proceduri, ceea ce conduce la
obligativitatea constituirii unui model logic al sistemului propus, care să conţină una sau mai
multe DFD, un model de date şi logica proceselor de prelucrare. Problema comună ar consta în
identificarea unei căi de realizare a modelului logic al sistemului propus.
O modalitate ar consta în prezentarea detaliată a sistemului fizic curent, după care să se
încerce conturarea noului model logic, prin abstractizarea celui fizic existent. Se va continua cu
scoaterea în relief a ceea ce trebuie neapărat schimbat din sistemul curent şi ceea ce trebuie să se
realizeze în cel nou. De regulă, se cer mai multe date de cules şi păstrat, precum şi noi
caracteristici ale prelucrărilor: mai complexe, mai rapide, mai sigure. Aşadar, modelul logic
propus poate fi conceput pe baza modelului logic curent. Paşii următori pot fi efectuaţi
parcurgând căi diverse. Ţelul lor este implementarea modelului logic propus pentru a se ajunge la
proiectul noului sistem fizic.
Chiar dacă este o activitate ce solicită timp şi eforturi suplimentare în analiza sistemului,
un argument al utilizării diagramelor fizice şi logice ale sistemului curent constă în faptul că
cele pentru noul sistem sunt mult mai uşor de construit, pentru că este înţeles deja modul lui de
funcţionare, analiştii trebuind să identifice care sunt procesele ce nu mai sunt necesare, pentru
a fi eliminate, şi să adauge noi procese, intrări, ieşiri sau locuri de stocare2. Această manieră de
lucru oferă o modalitate prin care se asigură păstrarea principalelor funcţii şi caracteristici ale
vechiului sistem, efectuându-se o trecere graduală către proiectarea noului sistem. După ce este
construit modelul logic al sistemului nou, acesta poate fi folosit pentru a-l dezvolta pe cel fizic,
aşa cum rezultă din figura 7.1.
Revenind la modelarea din timpul analizei, putem spune că cerinţele sistemului privind
funcţiile (procesele), datele şi comportamentul sistemului sunt modelate apelând la diferite
forme de reprezentare grafică. Astfel, pentru obţinerea viziunii de ansamblu asupra sistemului
se creează modelul descompunerii funcţionale3, după care, pentru detaliere, se construiesc
diagramele fluxurilor de date (DFD), indicând transformarea datelor care intră sau sunt stocate
în sistem pentru obţinerea ieşirilor. Pentru reprezentarea lucrurilor/obiectelor, atributelor şi
prelucrează date conţinute de un singur flux sau provin de la aceeaşi sursă (loc de stocare sau
entitate externă).
descompunere
Nivel „0” de
prelcurare 4
Tranzactie 4
Tranzactie
Contextul sistemului
descompunere
Nivel „1” de
3.2
Proces 3.2
Proces
prelucrare 3
Tranzactie 3
Tranzactie
3.1
Proces 3.1
Proces
Sistem
Sistem
1.2.3
Procedura 1.2.3
Nivelul „2” de
descompunere
Tranformare 2 2
Tranformare
Procedura
1.3
Proces 1.3
Proces
1.2.2
Procedura 1.2.2
Procedura
1.2
Proces 1.2
Proces
1.2.1
prelucrare 1
Tranzactie 1
Procedura 1.2.1
Tranzactie
Procedura
1.1
Proces 1.1
Proces
Într-o definiţie restrânsă, DFD-urile sunt o metodă de prezentare grafică a traseului logic
pe care îl parcurg datele prin diverse procese până sunt transformate în ieşiri, redând toate
componentele logice ale unui sistem într-o singură reprezentare grafică, respectiv intrările,
ieşirile, prelucrările şi locurile de stocare, precum şi graniţele sistemului4.
Indiferent de metodologiile folosite în realizarea unui sistem/aplicaţie, toate apelează la
operaţiunea de modelare logică a prelucrărilor sub formă de diagrame, diferenţele constând
doar în folosirea mai pronunţată a diagramelor pentru descrierea sistemului, încadrându-le în
diagrame de context, diagrame ale fluxurilor de date fizice şi diagrame ale fluxurilor de date
logice. Altele apelează la combinaţii de diagrame, tabele şi forme descriptive.
Diagrama de context scoate în relief aria de întindere a sistemului analizat, prin
specificarea elementelor din interiorul organizaţiei şi a celor externe, sub denumirea de
entităţi externe, însemnând entităţi externe sistemului analizat.
Diagrama fluxurilor de date ale sistemului fizic curent specifică persoanele şi
tehnologiile folosite pentru fiecare proces de transfer şi transformare a datelor, acceptându-se
unele intrări şi descriindu-se ieşirile din procesele menţionate.
Diagrama fluxurilor de date ale sistemului logic curent, independentă de tehnologie,
reliefează funcţiile de prelucrare a datelor executate de către sistemul informaţional curent.
Diagrama fluxurilor de date ale sistemului logic nou va prezenta circuitul datelor,
structura lor şi cerinţele funcţionale ale noului sistem.
Descrieri ale obiectelor DFD se regăsesc în aşa-zisele dicţionare ale proiectelor sau
depozite CASE (repository), ce reprezintă depozitul de date despre ... datele, obiectele şi
procesele diagramelor, pe scurt depozitul de metadate.
În literatura de specialitate, toate se regăsesc sub denumirea generică de diagrame ale
fluxurilor de date şi, ca atare, sub această semnificaţie, le tratăm şi noi în continuare.
Se cuvine o remarcă: întrucât diagramele fluxurilor de date (DFD) au ca obiectiv
urmărirea modului de transfer al datelor între procesele de prelucrare, astfel de diagrame se
mai numesc şi modele ale proceselor de prelucrare, iar operaţiunea se numeşte modelarea
proceselor.
Tehnica de redare a proceselor de prelucrare prin intermediul diagramelor fluxurilor de
date a căpătat noi accepţiuni prin încorporarea ei în instrumentele de analiză şi proiectare cu
ajutorul calculatorului, adică în produsele CASE, deşi în acelaşi timp putem vorbi şi de o
anumită complicare a problemei.
Cu ajutorul diagramelor fluxurilor de date se pot stabili graniţele unui sistem apelând doar
la patru simboluri:
locul în care se vor duce informaţiile sau de unde vin ele, văzut ca alt sistem sau altă
persoană care interacţionează cu sistemul;
locul în care sunt păstrate/memorate datele care circulă în sistem;
fluxul de date;
procesul care asigură transformarea datelor.
Aşa cum se va vedea mai târziu, primele două simboluri sugerează sursa, respectiv
destinaţia datelor la un moment dat. DFD-urile pot fi folosite în locul unei descrieri narative a
sistemului, ce vine în sprijinul analiştilor în timpul dialogului cu utilizatorii. Acest lucru se
datorează faptului că analiştii sunt confruntaţi de multe ori, în timpul întâlnirilor cu utilizatorii,
cu problema explicării modului de funcţionare a sistemului, când utilizatorii sunt puşi în
situaţia de a accepta sau refuza soluţiile propuse pentru dezvoltarea unui sistem şi nu pot da un
răspuns pentru că nu reuşesc să înţeleagă specificaţiile prea ample şi complex formulate. Din
4. Kendall, K.E., Kendall, J.E. – op. cit., p. 241; McLeod Jr., R., Jordan, L. – Systems Development. A Project
Management Approach, John Wiley & Sons, Inc., New York, 2002, p. 94; Oprea, D. – Premisele şi consecinţele
informatizării contabilităţii, Ed. Graphix, Iaşi, 1995, p. 179; Romney, M.B., Steinbart, P.J. – Accounting
Information Systems, 9th Edition, Prentice Hall, Upper Saddle River, New Jersey, 2003, p. 156; Satzinger, J.W.,
Jackson, R.B., Burd, S.D. – op. cit., p. 195.
MODELAREA LOGICĂ, GRAFICĂ, A PROCESELOR DE PRELUCRARE 135
experienţă, s-a constat că oamenii reuşesc să-şi amintească 100% din imaginile văzute, dar
numai 50% dintr-un text. De aceea, reprezentarea grafică a unui sistem poate oferi utilizatorilor
o modalitate mai simplă de a-l înţelege, precum şi modul în care el le va rezolva problemele.
DFD-urile pot fi utilizate pentru reprezentarea unui sistem sau a unui software la orice
nivel de abstractizare. Propriu-zis, DFD-urile pot fi descompuse pe niveluri ce indică o creştere
a detalierii fluxurilor de date şi a prelucrărilor. De aceea, DFD-urile oferă un mecanism pentru
modelarea atât a fluxurilor de date, cât şi a proceselor, aşa cum rezultă din figura 7.3.
Enitate externa 1
Date-de-intrare-1
Entitate externa 2
Date-
Tranzactie 1 intermediare -1
prelucrare 1
3 Date-de-ieşire-1
Tranzactie 3
prelucrare 3
Date- Date-
intermediare -2 intermediare -3
-
2 3
Date- 4
Date-
Transformare 2 memorare
pentru-
memorare
Tranzactie 4
prelucrare 4
Date-de-
intrare-2 Loc de stocare date
Date-de-ieşire-2
Entitate externa 3
Enitate externa 1
În figura anterioară, pătratul folosit redă o entitate externă, adică o persoană, o aplicaţie
sau alt sistem care produce informaţii pentru a fi supuse transformărilor sau primeşte
informaţii generate de sistem. Cercul reprezintă un proces sau o transformare aplicat(ă)
datelor, prin care datele sunt modificate. Linia cu săgeată reprezintă una sau mai multe
structuri de date, indicând modul în care circulă datele în sistem. Cele două linii paralele
înseamnă un loc de stocare a datelor, prin care informaţiile sunt păstrate pentru a fi folosite de
către procesele sistemului.
Simplitatea simbolurilor folosite pentru construirea DFD-urilor reprezintă un alt motiv
pentru care sunt folosite în modelarea şi descrierea sistemului. Însă, trebuie remarcat faptul că
nu există indicaţii explicite asupra secvenţei prelucrărilor sau a condiţiilor logice de execuţie a
acestora. Procedura sau secvenţa procedurilor este considerată implicită în cadrul DFD-urilor,
iar explicaţiile detaliate sunt lăsate pentru etapa de proiectare. De aceea, se consideră că DFD
prezintă, sub formă grafică, activităţile sistemului, ca răspuns la apariţia unui eveniment.
136 ANALIZA SISTEMELOR INFORMAŢIONALE
Recomandările din tabel nu reprezintă paşi succesivi ce trebuie parcurşi pentru construirea
DFD-urilor, pentru că unii dintre ei se pot desfăşura paralel (de exemplu, identificarea
elementelor din diagramă şi denumirea lor), altele se reiau în funcţie de necesităţile de
moment. Detalii privind aceste recomandări şi modul efectiv de construire a diagramelor vor fi
prezentate în paragrafele ce urmează.
7.3.2 Simboluri utilizate în construirea DFD
În practică, cele mai multe produse CASE apelează la două tehnici de redare a
diagramelor fluxurilor de date: Gane & Sarson5 şi Yourdon6 & DeMarco7. Firesc, numele lor
sunt combinaţii ale numelor realizatorilor acestora. Din prezentările ulterioare sperăm să
atenuăm teama de diversitate. Tehnicile sunt foarte asemănătoare, iar diferenţele le vom puncta
la momentul potrivit.
7.3.2.1 Entităţile externe (EE)
Entităţile externe mai poartă numele şi de sursă/destinaţie sau agenţi externi, fiind
locurile de unde intră sau către care ies documente, liste, situaţii, informaţii. Entităţile externe
5. Gane, C., Sarson, T. – Structured Systems Analysis: Tools and Techniques, Prentice Hall, Englewood Cliffs, New
Jersey, 1979.
6. Yourdon, E., Constantine, L.L. – Structured Design, Prentice Hall, Englewood Cliffs, New Jersey, 1979.
7. DeMarco, T. – Structured Analysis and Design Specification, Prentice Hall, Englewood Cliffs, New Jersey, 1979.
MODELAREA LOGICĂ, GRAFICĂ, A PROCESELOR DE PRELUCRARE 139
sunt reprezentări fizice ale grupurilor de persoane, cum sunt clienţii, furnizorii sau ale altor
sisteme, ca de exemplu Gestiunea stocurilor, Salarizare. Uneori, o entitate externă poate fi o
singură persoană (contabil-şef, preşedinte etc.).
Legăturile care se realizează între procesele de prelucrare şi entităţile externe, prin
intermediul fluxurilor de date (interfeţele sistemului cu mediul extern), au ca suport circuitul
unor astfel de documente în cadrul organizaţiei, purtând de multe ori şi denumirea de fluxuri
externe sau fluxuri finale, pentru că ele vin din afara sistemului (fluxurile de intrare, provenite
de la entităţi) sau nu rămân în interiorul sistemului (fluxurile de ieşire, care au ca destinaţie
entităţile externe). O entitate poate fi, la un moment dat, dar nu în același timp, atât sursă, cât şi
destinaţie.
Enităţile sunt considerate externe sistemului pentru că nu intră în aria de modelare a
acestuia, adică a proceselor de prelucrare prin care entităţile pun la dispoziţia sistemului
fluxurile de intrare sau prin care preiau fluxurile de ieşire.
Simbolurile convenţionale folosite de cele două tehnici sunt redate mai jos:
Gane & Sarson Yourdon & DeMarco
Pătrat îngroşat Pătrat simplu
Fiecare entitate va avea un nume corespunzător, marcat printr-un substantiv, pentru a reda
cât mai bine ceea ce reprezintă pentru sistem. Aceeaşi entitate poate fi folosită ori de câte ori
este nevoie de ea în cadrul unei DFD, pentru a se evita încrucişarea fluxurilor de date.
7.3.2.2 Fluxuri de date
Fluxurile de date, redate printr-o linie cu o săgeata la unul din capete (reprezentând
destinaţia datelor), sunt utilizate cu scopul de a sugera o cale pe care se pot suprapune una sau
mai multe structuri de date, în momente nespecificate, care intră în procesele de prelucrare sau
sunt rezultatul lor. Momentul prelucrării datelor unui proces poate fi specificat prin descrierea
procesului respectiv în depozitul metadatelor.
De regulă, fiecare flux de date primeşte un nume sugestiv, care descrie numai o structură
de date, reprezentând un document, un raport, date citite sau scrise dintr-un/într-un loc de
stocare, precum şi date care sunt transmise între procese cu prelucrări on-line. De aceea,
denumirea fluxurilor începe cu un substantiv care să redea cât mai bine faptul că se preia sau
se transmite o structură de date necesară:
unui proces, când trebuie să fie supusă prelucrărilor şi este preluată de la o entitate
externă sau este rezultatul citirii unor înregistrări anterioare dintr-un loc de stocare;
unei entităţi externe, când este rezultatul unui proces de prelucrare şi este cerută de o
persoană, un alt sistem, o aplicaţie, un birou etc.;
unui loc de stocare, când, în urma prelucrărilor, pe baza ei se adaugă noi înregistrări, se
modifică sau se şterg înregistrările anterioare.
În anumite situaţii se impune însă prezentarea câtorva structuri de date pe o singură
săgeată (flux), după cum rezultă din figura 7.4 (fluxul Istoric-incasari-si-Facturi-emise).
140 ANALIZA SISTEMELOR INFORMAŢIONALE
Incasare
Date-
incasare-
client
Limita- 1
Istoric-inacasari-si-
creditare Facturi-emise
Clienti Inregistrare
Verificare limita comanda noua
creditare
Date-facturi-
client Date-comanda
O astfel de situaţie apare atunci când dintr-un proces de prelucrare rezultă două structuri
de date care trebuie să ajungă simultan într-un alt proces de prelucrare sau la o entitate externă.
Un caz asemănător se întâlneşte atunci când într-un proces de prelucrare intră în acelaşi timp,
de la aceeaşi sursă, fluxuri diferite ca structură (de exemplu, de la depozit vin documentele
privind mişcările de materiale dintr-o perioadă de timp, care au structuri de date diferite, dar
sunt necesare toate pentru actualizarea stocului de materiale). Însă, trebuie să se determine
dacă acestea circulă întotdeauna împreună, altfel fiind necesară reprezentarea lor diferită,
pentru că e posibil ca documente distincte să fie ascunse interpretărilor şi analizei, făcând mai
dificilă înţelegerea diagramelor.
Structurile multiple de date se pot descompune, la un moment dat, pe nivelurile inferioare
ale DFD, pentru a evidenţia că fiecare intră sau iese într-o/ dintr-o altă procedură de prelucrare.
Se mai întâlneşte o situaţie aparte, atunci când se doreşte redarea unei ramificaţii a
aceleiaşi structuri de date, ceea ce înseamnă că un flux se poate descompune, la cerere, având o
singură origine şi multiple destinaţii, aşa cum ilustrează şi exemplul din fig. 7.5.
1
Client
Factura-vanzare
Emitere factura
Facturi emise
Trebuie reţinut că prin fluxurile de date nu se redau circuitele bunurilor fizice, ci numai
datele care reflectă aceste circuite. De exemplu, este incorect să se includă într-o diagramă
fluxul „Produse livrate” sau „Bani încasaţi”. Fluxurile corect denumite şi care ar trebui
reflectate sunt „Documente/date privind livrarea produselor”, respectiv „Documente/date
privind încasarea”.
Aşa cum s-a menţionat şi la descrierea entităţilor externe, fluxurile de date se pot încadra
în două categorii:
externe, care provin de la entităţile externe şi sunt supuse proceselor de prelucrare,
respectiv cele care sunt rezultatul unui proces de prelucrare şi au ca destinaţie entităţile
externe;
interne sau intermediare, cu referire la fluxurile care circulă între două procese de
prelucrare sau între un proces şi un loc de stocare. Sunt considerate interne pentru că
MODELAREA LOGICĂ, GRAFICĂ, A PROCESELOR DE PRELUCRARE 141
ele provin din interiorul sistemului (un proces de prelucrare sau un loc de stocare),
respectiv nu părăsesc sistemul (merg într-un alt proces de prelucrare sau într-un loc de
stocare). Atunci când un proces are nevoie de informații dintr-un loc de stocare pentru
a face o prelucrare (de exemplu, pentru stabilirea limitei de creditare a unui client
presupune citirea datelor din tabela clienti) înseamnă că în proces intră un flux intern.
Dacă în urma prelucrării unor date rezultatul trebuie să asigure adăugarea, modificarea
sau actualizarea unei înregistrări într-un loc de stocare, înseamnă că din proces se
obține un flux intern de ieșire.
Cei care modelează sistemul, prin intermediul diagramelor fluxurilor de date, trebuie să
ţină cont de faptul că orice flux trebuie să treacă printr-un proces de prelucrare, fie că intră în
el pentru a fi prelucrat, fie că este rezultatul prelucrării.
În privinţa simbolisticii folosite de cele două tehnici, nu există diferenţe.
7.3.2.3 Locuri de stocare a datelor
Locul de stocare a datelor reprezintă o „magazie” pentru datele care sunt înregistrate
temporar sau permanent în cadrul sistemului, adică cele care se păstrează în sistem pentru
utilizări viitoare. Ca şi în cazul fluxurilor de date, locurile de stocare nu urmăresc redarea unui
format fizic de păstrare a datelor, ci reprezintă locaţii sau metode prin care datele sunt păstrate
în sistem. Un loc de păstrare poate fi un fişier, un director, o tabelă a unei baze de date, o bază
de date, un dosar, un registru, o înregistrare din agenda unei persoane, căsuţa de e-mailuri a
unei persoane. Locurile de stocare pot conţine date despre clienţi, stocuri, comenzi, facturi
primite, facturi emise, state de salarii, plăţi, încasări etc. Direcţia fluxurilor de date către sau de
la locul de stocare indică faptul că datele sunt scrise sau citite în/din acel loc de stocare. În
plus, orice ştergere sau modificare a unei înregistrări dintr-o bază de date este reprezentată tot
ca un flux de date, în sensul că o astfel de operaţiune cere ca datele să fie citite înainte de a fi
şterse sau modificate. Ca urmare, stocarea datelor se referă atât la fişierele sistemelor de
prelucrare manuală, cât şi la cele create în medii informatizate, inclusiv una sau mai multe
tabele ale bazelor de date.
Simbolurile utilizate de cele două tehnici sunt:
Gane & Sarson Yourdon & DeMarco
Dreptunghi neînchis la dreapta Linii paralele
În varianta Gane & Sarson, locurile de stocare au câte un identificator unic, prezentat sub
formă generală Dnn, cum ar fi D1, D7. Când se intenţionează redarea cu claritate a operaţiunii
de stocare, simbolul ce poartă acelaşi identificator (Dnn) poate fi multiplicat. În acest sens, la
stânga dreptunghiului alungit se plasează un triunghi care va purta acelaşi număr. El reprezintă
numărul de apariţii ale aceluiaşi simbol.
Exemplu:
D1 CLIENTI D1 CLIENTI
3 3
D1 CLIENTI
3
Prezenţa într-o diagramă a fluxului de date a unui loc de stocare, care are o singură intrare
şi o singură ieşire, conduce la o examinare mai atentă, pentru a se trage concluzia dacă acel
loc, din punct de vedere economic, este logic necesar. S-ar putea ca prezenţa lui să sugereze un
fişier fizic temporar, utilizat ca mediu de comunicare a datelor.
De exemplu, dacă anumite date se salvează pe un anumit suport doar pentru a fi
transportate de la o filială la sediul firmei, operaţiunea nu este logic necesară, cât timp datele
142 ANALIZA SISTEMELOR INFORMAŢIONALE
pot fi transferate şi telefonic. Deci, scopul creării fişierului este acela de a ajuta la operaţiunea
de transfer date. Pe de altă parte, dacă pe acelaşi suport s-ar păstra datele despre clienţii rău
platnici pentru a fi prezentaţi responsabilului cu vânzările, peste câteva zile, operaţiunea este
logic necesară, chiar dacă ea are doar o intrare şi o ieşire (fig. 7.6 şi 7.7).
1 2
Comanda-noua
Cont de client valid
Verificare client Validare client
Date-
client
Date-
client
Clienti incerti
Clienti
Date-
sold
1 2
Cont-de-client-
Comanda-noua Date-client valid
Verificare client Validare client
CRUD
CRU
RU
C
R
R
R
returnate
Tranzactii Pachet Nomenclator Produse
C
R
comandate comanda promotii produse
R
R
R
R
R
R
R
CRU
RU
R
R
R
Locuri de stocare
CRUD
RUD
C
R
Produse
RUD
RU
RU
C
R
R
Catalog Client Stoc Comanda
RU RUD
RU
CRU RU C
R
R
R
R
R
R
R
R
CRUD
CRU
RU
RU
R
R
R
RU
Inregistrare comanda catalog R
R
C
R
Inregistrare produse returnate
Inregistrare ajustari
Actualizare comenzi
Inregistrare livrare
Procese
Actualizare catalog
Actualizează (Update) datele despre el. De asemenea, se Creează (Create) câte o nouă
înregistrare în fişierele Comanda (pentru ţinerea evidenţei comenzilor primite),
Produse comandate (pentru a şti ce produse au fost comandate), Tranzacţii comandă
(pentru păstrarea unui istoric al operațiilor cu clienţii, până la încheierea lunii sau a
anului) şi Livrări (pentru a înregistra data la care urmează să se facă livrările). Apoi,
Citeşte (Read) înregistrări din fişierele Pachet promoţii (pentru a se şti dacă noua
comandă se încadrează într-un pachet promoţional) şi Nomenclator produse (pentru a
afla preţul produselor comandate).
Entitate externa
1
Entitate externa
2
Date-de-
intrare-1
Date-de-
iesire-1
Date-de-iesire-2
0
Sistem
Date-de-intrare-2
Entitate externa
3
Departament
marketing
Sistem vanzari
Raport-
privind- Informatii- Rapoarte-privind-
potentialii- limita- vanzarile
clienti Informatii-
creditare-
clienti-noi-
clienti
Detalii- pentru-limita-
campanii- creditare
promotionale
Birou distributie
Date-de-identificare
Client Rapoarte-privind-
cataloagele
Cataloage
Comenzi-retururi
0
Confirmari-cataloage
SGC
Rapoarte-comenzi-
livrari-ajustari
Decizii-politici-
creditare-clienti
Detalii-tranzactii-clienti
Conducere
Raport-
privind- Detalii- Comenzi-
operațiile livrari de-onorat
Conturi-
analitice
Banca
Contabilitate Depozit-livrari
Fluxurile de date şi entităţile externe din diagrama de context sunt preluate din tabelul
evenimentelor, dar, aşa cum se ştie, sistemul trebuie să răspundă celor 20 de evenimente identificate,
ceea ce înseamnă că figura prezintă o combinaţie a fluxurilor de date pentru principalele evenimente,
tocmai pentru a asigura viziunea de ansamblu asupra sistemului.
MODELAREA LOGICĂ, GRAFICĂ, A PROCESELOR DE PRELUCRARE 147
entitate externă, un proces sau un loc de stocare şi apoi să se înceapă construirea diagramei de
la unul din aceste elemente. Se poate începe8:
de la un flux de date ce intră în sistem de la o entitate externă, urmărind să se răspundă
la întrebări de genul: „Ce se întâmplă la intrarea datelor în sistem?”, „Trebuie să fie
memorate?”, „Reprezintă o intrare pentru mai multe procese?”;
de la un flux de ieşire, analizându-se câmpurile lui, iar pentru fiecare câmp ce trebuie
generat de sistem se pun întrebările: „De unde poate fi obţinut?”, „Este un câmp
calculat sau este memorat într-un fişier?”. De exemplu, când ieşirea este Fluturaş,
atunci Nume salariat, Marcă, Funcţie ar trebui să se regăsească în fişierul Salariaţi,
Numărul de ore lucrate în fişierul Pontaje, iar Salariul brut, Impozitul, Reţinerile
legale să fie câmpuri calculate etc. Fiecare fişier va putea fi conectat la procesul care
generează fluturaşul;
cu analiza fluxurilor care intră sau ies dintr-un loc de stocare. Se ridică întrebările:
„Prin ce procese sunt înregistrate/actualizate datele?”, „Ce procese apelează la datele
din locul de stocare respectiv?”;
cu analiza proceselor definite în timpul descompunerii funcţionale. Se vor umări datele
de intrare de care are nevoie fiecare proces şi datele de ieşire pe care ar trebui să le
genereze, după care se vor conecta intrările şi ieşirile la locurile de stocare şi entităţile
corespunzătoare, prin intermediul fluxurilor de date care reflectă acele intrări/ieşiri;
prin notarea tuturor aspectelor asupra cărora există anumite incertitudini, urmărindu-se
formularea unor întrebări pentru o nouă serie de interviuri cu utilizatorii-cheie ai
sistemului.
O altă manieră de abordare a descompunerii diagramei de context în DFD-0 este cea a
„fragmentării” sau „partiţionării” sistemului, plecând de la evenimente9. Astfel, se creează câte
un fragment de DFD pentru fiecare eveniment din tabelul evenimentelor sau proces identificat
la descompunerea funcţională, prin care se reliefează modul în care sistemul răspunde acestuia,
redându-se în detaliu interacţiunile procesului cu locurile de stocare şi entităţile externe. Apoi,
fiecare fragment de DFD poate fi combinat pentru obţinerea DFD de nivel 0.
Totuşi, de multe ori, se evită construirea diagramei de nivel 0 în varianta care se bazează
pe fragmentare, din cel puţin două motive:
1. sunt dublate informaţiile pe care le conţin atât fragmentele de DFD, cât şi DFD de
nivel 0, precum şi eforturile de construire a mai multor diagrame care conduc, în final,
la acelaşi rezultat;
2. adesea o astfel de manieră de construire pentru sistemele de dimensiuni mari este
complexă, surprinzând evenimente multiple şi diversificate.
În caseta 7.4 este redată diagrama de nivel 0 pentru sistemul de gestiune a clienţilor ABC.
Diagrama de nivel 0 este folosită şi în timpul proiectării diagramelor entitate-relaţie
(DER), pentru că prezintă fluxurile de date şi locurile de stocare pe baza cărora se pot
identifica entităţile de date şi relaţiile dintre ele. Conceperea celor două diagrame se poate
realiza în paralel.
7.3.3.3 DFD de nivel 1 până la n
După ce diagrama de nivel 0 a fost finalizată şi verificată, pentru eliminarea erorilor şi
asigurarea reprezentării corecte a fluxurilor sistemului, procesul de descompunere continuă cu
nivelurile de la 1 la n. Acest lucru înseamnă că nivelul 0 este descompus pe nivelul 1 şi, dacă e
necesar, nivelul 1 pe nivelul 2 ş.a.m.d., până când se atinge cel mai mare nivel de detaliere
pentru toate procesele şi subprocesele asociate. La procesele din DFD de nivel 0 se face
referire, de cele mai multe ori, sub denumirea de procese-părinte (parent processes), iar
Catalog Catalog
Date-de-identificare
Client Conducere
Date- Nomenclator
Comanda-noua produs produse Decizii-politici-creditare-clienti
Cantitate- Date- Departament
Nota-confirmare- existenta Cantitate- Promotii noi- marketing
modificare-comanda Rapoarte-privind-comenzile
Nota-confirmare- comandata catalog
Date-modificare-comanda comanda Visible Systems Corporation Demonstration Version
Date- Date- Detalii-
1 promotii-
Sistem cataloage- campanii-
Client derulate existente promotionale
Informatii-limita- vanzari
Introducere creditare-clienti
comanda
Comenzi-de-
onorat
4
Date-comenzi- Date-promotii-noi
Informatii- Comanda-
Date- Tip- inregistrate
clienti-noi- catalog
Depozit- comanda- comanda
pentru-limita- Catalog
livrari noua Date- Tranzactii Intretinere date
creditare
comenzi-existente comenzi cataloage
Informatii- Detalii-comenzi-
si-clienti
Date- clienti-
Detalii- Comenzi 3
client noi
livrari Date- Date-
Detalii- Data-cataloage-
produs tranzactii- Cataloage
comenzi- Catalog Actualizare date trimise
Date- cataloage
de-
Clienti
comenzi-onorate clienti Rapoarte-
onorat privind-
Informatii-clienti-noi
Date- cataloagele
fişier care să facă legătura între două procese ale diagramei-copil. În plus, pot să-şi facă
generează. Excepţie face situaţia în care fluxul primit/generat de procesul-părinte este
descompus în subfluxuri, pentru a se stabili legături distincte pentru fiecare subproces,
loc, dar şi altele ce nu sunt reprezentate în diagrama de nivel 0. De exemplu, poate fi inclus un
Prima regulă de construire a diagramelor de nivel 1 constă în faptul că un proces-copil nu
rezultatul explodării lor, respectiv subprocesele, sunt denumite procese-copil/proces-fiu (child
Caseta nr. 7.4 – Diagrama fluxurilor de date de nivel 0 pentru sistemul de gestiune a clienţilor
150 ANALIZA SISTEMELOR INFORMAŢIONALE
apariţia şi alte fluxuri de date, de importanţă mai mică sau de excepţie, cum ar fi un flux cu
erori, dar, aşa cum am specificat, nu este obligatoriu să se regăsească în diagrama de context şi
cea de nivel 0, dar obligatoriu trebuie să fie fluxuri interne şi nu externe.
De asemenea, pentru asigurarea principiului de balansare a diagramelor, fiecare proces-
copil din DFD de nivel 1 este legat de procesul-părinte, din care a fost obţinut, printr-un sistem
de numerotare secvenţial, plecând de la cifrele alocate în DFD de nivel 0, conform
descompunerii din figura 7.3. De exemplu, procesul Tranzacţie 1, de pe nivelul 0, este
reprezentat pe nivelul 1 cu trei procese-copil 1.1, 1.2, şi 1.3. Din figura 7.9, se poate observa că
aceleaşi fluxuri de date externe, care intră sau ies din procesul-părinte, sunt reprezentate în
diagrama de nivel 1.
Entitate externa 1
Date-de-intrare-1b
1.1
1.3
Proces 1.1
Date-
prelucrate-1 Proces 1.3
Date-prelucrate-2
1.2
Date-
intermediare-1
Proces 1.2
Date-de-
intrare-1a
Entitate externa 1
Tranzactii comenzi
Conducere
Nomenclator
produse
Date-comenzi-
Rapoarte-privind-
inregistrate
Date-comezi-
modificate
comenzile
modificata
comanda-
Cantitate-
rapoarte comenzi
Actualizare
comenzi
Generare
1.3
1.4
Date-comenzi-modificate
comenzi-
existente
Date-
Nomenclator
produse
Date-produs
Sistem vanzari
Nomenclator
Date-client
produse
Comenzi
Catalog
Informatii-clienti-noi
Informatii-limita-
creditare-clienti
Cantitate-comanda-noua
Catalog
Cantitate-
existenta
Clienti
comanda-noua
produs
Date-
Date-comenzi-noi
Date-
Date-
client
si-modificate
existenta produs
inregistrate
Verificare
comenzi-
comanda noua
1.1
Date-
Inregistrare
Tranzactii comenzi
1.2
Comanda-noua
comanda
Tip-
modificare-
comanda
Date-client
Date-
Date-de-identificare
creditare-clienti
Decizii-politici-
modificare-comanda
Nota-confirmare-
Nota-confirmare-
Comenzi-de-onorat
comanda
Conducere
Client
Clienti
Depozit-livrari
Client
procesul 1.2.2 preia fluxurile Date clienti comanda, de la procesul 1.2.1, şi Date
comenzi noi si modificate, de la procesul 1.1, Verificare existenta produs, de pe nivelul
anterior de descompunere, pe baza cărora creează o nouă înregistrare în locul de
stocare Comenzi. Informaţii detaliate despre comenzi sunt transmise şi procesului
1.2.3, Prelucrare comanda, pentru a se înregistra cantitatea solicitată prin comanda
nouă şi pentru a trimite datele necesare procesului 1.3, Actualizare comenzi. Tot pe
baza prelucrărilor din acest proces, se adaugă o înregistrare în fişierul Tranzacţii
comenzi, cu ajutorul fluxului Comanda posibil de onorat, obţinut prin descompunerea
fluxului Tip comanda. Un ultim flux (Date comenzi de onorat) este trimis în procesul
1.2.4, Confirmare comanda. În cadrul acestui proces se calculează valoarea comenzii,
care este transmisă prin fluxul Date comenzi de onorat;
în final, procesul 1.2.4 trebuie să verifice limita de creditare acordată clientului şi, dacă
noua comandă sau cea modificată se încadrează în această limită, se vor emite
documentele de acceptare a comenzii (fluxurile Nota confirmare comanda, Nota
152 ANALIZA SISTEMELOR INFORMAŢIONALE
Client Date-de-
identificare Clienti
Date-
client
Informatii-
1.2.1
clienti-noi
Client
Sistem vanzari
Inregistrare date
clienti
Date-
Tranzactii comenzi
comanda-
noua Date-comenzi-
1.2.3 modificate
Comenzi
Prelucrare Cantitate-
comanda comanda-
noua
Comanda-
posibil-de-
Nomenclator
onorat Date- produse
comenzi-
inregistrate
Tranzactii comenzi
când utilizatorii sistemului apreciază că nu au nevoie de detalii mai multe sau când
analiştii consideră că, prin documentaţie, au oferit suficiente amănunte, astfel încât
activităţile următoare din sistem să se deruleze fără probleme;
când un flux de date nu mai trebuie să fie descompus pentru a arăta că unor date li se
aplică un tratament, iar altora, unul diferit;
când se consideră că analistul a scos în relief fiecare formular, tranzacţie, ecran de
calculator, raport printr-un flux de date, ceea ce ar putea să însemne că un nume de
ecran sau de raport ş.a.m.d. este atribuit şi ca nume al unui flux;
când analistul apreciază că s-a atins cel mai de jos nivel al procesului de
descompunere a opţiunilor meniurilor sistemului şi pentru fiecare dintre ele există
câte un proces distinct.
Din prezentările făcute rezultă ca procesul de descompunere este destul de subiectiv. El
poate înceta în orice moment, cu intenţia de oprire definitivă, dar poate fi şi reluat ulterior,
dacă se consideră utilă descompunerea.
În sinteză, un sistem trebuie să fie reprezentat printr-un set de diagrame, de genul celui
prezentat în fig. 7.10, şi anume:
1. o diagramă de context;
2. o diagramă de nivel 0, indicând principalele subsisteme ale sistemului;
3. până la 7 diagrame de nivel 1, indicând principalele funcţii (aplicaţii) ale fiecărui
subsistem;
4. până la 49 de diagrame de nivel 2, indicând detaliile fiecărei funcţii sau ale fiecărei
aplicaţii ş.a.m.d.
Diagrama de
context
4 Diagrama de
1
nivel 0
2 3
3.1
Diagrama de
3.3.1
nivel 2
3.3.2 etc.
3.3.3
3.3.4
10. Celko, J. – „Data Flow Diagrams”, in Computer Language, 4, January 1987, pp. 41-43.
MODELAREA LOGICĂ, GRAFICĂ, A PROCESELOR DE PRELUCRARE 155
actualizare, este indicată folosirea a două săgeţi de sensuri contrare, şi nu una singură cu
vârfuri la ambele capete, deoarece procesul se realizează în momente diferite.
11. Ramificaţia într-un flux de date înseamnă că aceleaşi date se transferă dintr-un loc comun în
două sau mai multe procese, locuri de stocare sau surse/destinaţii (de regulă, înseamnă copii
diferite ale aceloraşi date).
12. Asocierea (unirea) dintr-un flux de date înseamnă că exact aceleaşi date vin dintr-unul sau mai
multe procese sau locuri de stocare, sau sursă/destinaţie spre un loc de stocare comun.
13. Un flux de date nu poate reveni direct la procesul pe care l-a părăsit. Trebuie să existe cel puţin
un alt proces prin care să treacă, să se efectueze trecerea prin alte procese şi de aici să revină
fluxul iniţial de date la procesul iniţial.
14. Un flux de date spre un loc de stocare înseamnă actualizare (ştergere sau schimbare).
15. Un flux de date dinspre un loc de stocare înseamnă restaurare sau folosire date.
16. Un flux de date este etichetat printr-un substantiv. Pe o săgeată de flux pot apărea mai multe
substantive însemnând un transfer gen pachet.
Proces
1.
2.
Stocare
3.
4.
5.
156 ANALIZA SISTEMELOR INFORMAŢIONALE
Sursă/Destinaţie
6.
Transfer produse
7. Magazie
Flux de date
8.
A A
9. B A
A A
10. B A
A B
11.
A A
Fig. 7.12 Exemplificări incorecte şi corecte ale unor reguli din tabelul 7.5
În continuare, sunt redate, prin exemple, cele mai frecvente erori în construirea DFD:
1. omiterea unui flux de date sau direcţionarea greşită a sensului, astfel că poate rezulta un
proces care să aibă numai fluxuri de intrare sau numai fluxuri de ieşire. Fiecare proces
transformă date şi de aceea trebuie să primească cel puţin un flux de intrare şi să
genereze cel puţin un flux de ieşire. Această eroare poate afecta şi alte procese, în sensul
că, atunci când un flux de ieşire este reprezentat ca intrare, iar al doilea proces, care e
dependent de acea ieşire, e posibil să nu aibă intrări. Şi invers, dacă un flux de intrare este
redat ca ieşire, un alt proces e posibil să nu genereze ieşiri, aşa cum rezultă din figura
7.13.
MODELAREA LOGICĂ, GRAFICĂ, A PROCESELOR DE PRELUCRARE 157
1.2.1
Inregistrare Date clienti Clienti
date existenti
client
Cantitate Stoc
Detalii acceptata
comanda
1.2.2 1.2.3
Inregistrare Detalii Prelucrare
date comanda comanda
comanda
Fig. 7.13 Exemplu de eroare cu procese care au numai fluxuri de intrare şi numai de ieşire
2. conectarea locurilor de stocare şi a entităţilor externe între ele. Legăturile între două
locuri de stocare se pot stabili numai prin intermediul unui proces de prelucrare. Datele
nu pot să treacă dintr-un fişier în altul sau de la o entitate la alta fără ajutorul unei
secvenţe de program sau al unei persoane, care execută manual un proces. În mod
similar, apare eroarea atunci când se stabileşte o legătură directă între o entitate externă
şi un loc de stocare, în sensul că entitatea nu poate interveni direct asupra înregistrărilor
dintr-un fişier fără să fie lansat în execuţie un proces care să asigure acea acţiune. De
exemplu, nu este posibil ca un client să intervină direct în fişierul de stocuri să vadă dacă
un produs este disponibil decât prin intermediul unei interfeţe (secvenţă de prelucrare).
La fel, două entităţi externe nu se pot afla în relaţie directă, chiar dacă ele trebuie să
comunice. În acest caz, fie comunicarea nu intră în aria de interes a sistemului modelat,
fie dacă sistemul trebuie să asigure acest lucru este necesar să intervină un proces. De
exemplu, transmiterea unui raport privind comenzile nu poate fi realizată direct de la
entitatea Departament livrari la Conducere din două motive: Departamentul nu are la
dispoziţie decât informaţiile privind livrările efectuate şi nu despre toate comenzile
primite de firmă la un moment dat, iar, în al doilea rând, pentru obţinerea raportului sunt
necesare procese de culegere a datelor de pe toate comenzile primite, sortarea şi filtrarea
lor în funcţie de anumite criterii, citirea unor informaţii din locurile de stocare şi abia
după aceea generarea raportului. Exemple de astfel de erori sunt redate în figura 7.14.
3. denumirea incorectă a proceselor sau fluxurilor de date. Un proces ar trebui să indice
numele sistemului, subsistemului sau să se folosească forma deja prezentată verb
(substantiv verbal) + descrierea funcţiei. Fiecare flux ar trebui să fie denumit printr-un
substantiv. Însă nu trebuie exagerat, având în vedere semnificaţiile şi formele multiple pe
care le pot lua cuvintele din limba română. De exemplu, „înregistrare” poate semnifica
atât procesul de înregistrare a datelor într-un fişier, cât şi setul de atribute ce formează o
înregistrare în fişier. La fel, „cerere” poate însemna acţiunea de interogare a unui fişier
158 ANALIZA SISTEMELOR INFORMAŢIONALE
sau de solicitare a unor informaţii, dar poate reprezenta şi un document de genul „Cerere
de aprovizionare”;
Clientul nu poate să-şi
modifice singur datele
Comanda Client
Date clienti în locul de stocare, ci
noua
modificate trebuie să intervină
un proces
1.2.1
Date clienti Clienti
Inregistrare
date existenti
client Un loc de stocare nu
poate fi actualizat
Cantitate Comanda direct pe baza datelor
Detalii acceptata dintr-un alt loc de
comanda Date produse stocare, ci printr-un
comandate proces.
1.2.2
Produse
Inregistrare comandate
date
comanda Detalii
comenzi
1.2.3
Date comanda
Prelucrare
de confirmat
comenzi
1.2.4
Generare
confirmare
comanda
Comanda
Comenzi
Contabilitate Client confirmata
transmise
4. utilizarea unui număr prea mare sau prea mic de fluxuri, în sensul că o serie de fluxuri nu
sunt necesare pentru a fi preluate de un proces sau procesul nu poate genera ieşirile
indicate numai pe baza fluxurilor pe care le primeşte. În figura 7.15 este redată o astfel de
situaţie;
Cantitate Comanda
Detalii acceptata
comanda
Date produse
1.2.2 comandate Produse
Inregistrare comandate Procesul 1.2.2 nu
date poate genera toate
comanda detaliile despre
comenzile primite
Detalii
pentru că nu dispune
comenzi
de informaţii
1.2.3
privind preţul
Prelucrare produselor
comenzi
a) Diagramă de context
Sursa A C
2.0 A E
1.2
1.0
1.1 G
Fişier
D F 1.3
3.0
B 1.4 C
Destinaţie D
D
3.1 I Fişier
D
I
3.1.1
H
3.2
J
B 3.1.2
H
d) Diagrama 3.0 e) Diagrama 3.1
Fig. 7.16 Un set de DFD balansate
Notă: Nu există diagrama 2.0, cât timp procesul 2.0 este unul elementar
Se poate observa că apar şi casetele entităţilor din diagrama de context, precum şi din
diagrama de nivel 0, dar care, de regulă, nu mai apar în diagramele de nivel 0 sau cele de
pe nivelurile inferioare acestuia, mai ales când sunt construite cu ajutorul instrumentelor
CASE, fiind deja memorate în sistem.
Pentru a se evita confuzia legată de termenul depozite de date (data warehouse), ca tehnologie
de interogare şi extragere date pentru analize, sau legată de dicţionarul datelor, aşa cum este
regăsit în lumea bazelor de date, vom folosi cu precădere depozit de metadate.
În cele mai multe produse CASE, acest depozit este legat de diagramă, ceea ce înseamnă
că pentru orice simbol al diagramei se va crea automat o poziţie în depozit, poziţie ce urmează
să fie completată de analist.
Depozitul metadatelor colectează şi descrie termeni specifici, asigurând înţelegerea, de
către diferite persoane din firmă, a semnificaţiei noţiunilor folosite în modelele sistemului,
fiind folosit pentru:
oferirea documentaţiei sistemului şi eliminarea redundanţei în privinţa descrierii
elementelor acestuia, care ar putea proveni din diferite surse;
validarea diagramelor fluxurilor de date din punct de vedere al completitudinii şi
corectitudinii lor;
descrierea fluxurilor de date din perspectiva structurii lor şi a datelor elementare pe care le
conţin;
oferirea punctului de plecare pentru proiectarea ecranelor şi rapoartelor;
determinarea structurii locurilor de stocare şi utilizarea lor în realizarea diagramelor
entitate-relaţie şi în proiectarea logică a datelor;
identificarea relaţiilor dintre date sau cum o structură de date se află în legătură cu o altă
structură;
descrierea logicii proceselor de prelucrare, ce vine în sprijinul generării modulelor
programelor sistemului;
păstrarea informaţiilor privind managementul proiectului, respectiv cerinţele proiectului şi
rezultatele aşteptate, planificarea resurselor, a perioadelor calendaristice pentru fiecare
etapă şi activitate, echipa de dezvoltare a sistemului etc.
Depozitul metadatelor este creat prin analiza şi descrierea conţinutului fluxurilor de date,
a locurilor de stocare, a proceselor, entităţilor externe şi a datelor elementare. Fiecare loc de
stocare şi flux de date ar trebui descrise prin prisma structurii corespunzătoare, după care
analiza trebuie extinsă pentru a include detalii despre datele elementare pe care le conţin.
Logica fiecărui proces de prelucrare poate fi descrisă cu ajutorul englezei structurate, plecând
de la datele care intră sau ies din el, precum şi de la matricea CRUD, pentru reflectarea
operaţiunilor care se execută asupra locurilor de stocare. Prin depozit se pot identifica
eventualele omisiuni sau erori care ar putea afecta proiectarea.
În general, descrierile în depozit cu privire la componentele diagramelor sunt:
1. numele componentei: sunt incluse toate numele prin care se identifică fiecare element din
diagrame, inclusiv alias-urile (pseudonime) sub care mai pot fi întâlnite aceste
componente, cu excepţia proceselor, ale căror denumiri sunt unice;
2. tipul componentei: proces, flux de date, loc de stocare, entitate externă, dată elementară;
3. structura: diferită în funcţie de tipul componentei, şi anume:
în cazul fluxurilor de date şi al locurilor de stocare, descrierea se realizează prin
prezentarea datelor elementare (câmpuri, atribute) din care sunt alcătuite;
dacă tipul este o dată elementară, atunci descrierea se realizează prin prezentarea
dimensiunii şi tipului de caractere folosite pentru redarea datei elementare, precum şi
intervalul de valori în care trebuie să se încadreze (de exemplu, AA9999).;
un proces se descrie prin engleză structurată sau pseudocod, pentru redarea operaţiunilor
care se execută prin intermediul acelui proces;
pentru entităţile externe se apelează la descrierea rolului pe care îl au, ce reprezintă pentru
sistem, când şi cum interacţionează cu sistemul etc.
4. caracteristici: este prezentată lista proceselor care interacţionează cu un flux de date. În
cazul datelor elementare, este prezentat fluxul sau locul de stocare din care provin. De
asemenea, pot fi oferite detalii privind frecvenţa apariţiei unui flux de date, execuţiei unui
Societatea:______________________________________________________
Localitate:________________ Judet: __________________Cod postal______
Strada:__________________________ Nr.________ Telefon/fax____________
Cod fiscal: ___________________________
Cont bancar:__________________________
Banca:_______________________________
COMANDA
Adresa de expeditie:
Plata se va face prin: CEC _____________, Ordin de plata ____________, Numerar _________, Compensare__________
Va rugam sa transmiteti confirmarea comenzii
comenzile primite de la clienţi pot fi preluate prin poştă, fax, telefon sau Internet, cu ajutorul
exemplului privind sistemul de gestiune a clienţilor de la firma ABC. Aşa cum s-a prezentat,
proces, apelării unui loc de stocare, aspecte privind volumul datelor şi securitatea, în
Sursa Destinaţia
Client (entitate externa) Procesul 1.2 Introducere comanda
Tipul fluxului
Document Ecran Formular Raport Înregistrare fişier
Structura datelor Perioada de prelucrare
Informaţiile specifice formularului de comandă La sfârşitul zilei
Observaţii: Se va crea câte o înregistrare cu informaţiile despre comandă pentru
fiecare comandă a fiecăruia dintre clienţii firmei. Comanda poate fi primită prin poştă,
fax, telefon sau Web
11. Kendall, K.E., Kendall, J.E. – op. cit., p. 310; Oprea, D., Dumitriu, F., Meşniţă, G. – CASE – proiectarea
asistată de calculator a sistemelor informatice, Ed. Universităţii „Al. I. Cuza” Iaşi, 1995, pp. 55-56; Satzinger,
J.W., Jackson, R.B., Burd, S.D. – op. cit., p. 217.
164 ANALIZA SISTEMELOR INFORMAŢIONALE
Gane&Sarson Yourdon&DeMarco
Comanda client = Cod client + Nume client + Comanda client = Cod client + Nume client +
Adresa + Telefon + Nr. comanda + Data Adresa + Telefon + Nr. comanda + Data
comanda+ Produse comandate* + Total valoare comanda+ {Produse comandate} + Total valoare
produs + Valoare livrare + Total valoare produs + Valoare livrare + Total valoare
comanda + [TVA] + Metoda de plata + [Tip comanda + (TVA) + Metoda de plata + (Tip
credit card] + [Nr. credit card] + [Data expirare credit card) + (Nr. credit card) + (Data expirare
card] card)
Nume client = Nume + [Initiala] + Prenume Nume client = Nume + (Initiala) + Prenume
Adresa = Stradă + [Apartament] + Oras + Judet + Adresa = Stradă + (Apartament) + Oras + Judet +
Cod Cod
Produse comandate = Cod produs + Denumire Produse comandate = Cod produs + Denumire
produs + Marime + Culoare + Unitate masura + produs + Marime + Culoare + Unitate masura +
Cantitate + Pret + Total valoare produs Cantitate + Pret + Total valoare produs
Metoda de plata = (Cec ¦ Credit card ¦ Cash) Metoda de plata = [Cec ¦ Credit card ¦ Cash]
Tip credit card = (MasterCard ¦ VisaCard) Tip credit card = [MasterCard ¦ VisaCard]
Fig. 7.19 Exemplu de descriere a structurii datelor în tehnicile Gane & Sarson
şi Yourdon & DeMarco
este trunchiat, o notificare transmisă prin poştă poate să ajungă totuşi la acel client,
datorită adresei. În schimb, dacă se trunchează adresa de e-mail, atunci mesajul va fi
returnat sistemului pentru că nu poate să găsească o adresă de e-mail validă.
7. tipul datelor: numeric, dată calendaristică, alfabetic, caracter (alfanumeric sau de tip text),
şi, în ultimul timp, imagine, sunet.
8. formatul pentru intrare şi ieşire, folosind simboluri speciale, pentru a indica modul în care
vor fi prezentate datele, şi anume:
X – introducerea sau afişarea/tipărirea datelor alfanumerice
9 – introducerea sau afişarea datelor numerice
Z – afişarea zerourilor de la începutul atributului ca spaţii (suprimarea zerourilor
nesemnificative)
V – indică poziţia zecimalelor (când nu este inclus punctul zecimal), virgula virtuală;
, – inserarea unei virgule la afişarea unui număr
. – inserarea unei punct la afişarea unui număr
/– inserarea unui slash la afişarea unui număr
- – inserarea unei cratime la afişarea unui număr
9. criteriile de validare pentru a se asigura corectitudinea datelor preluate în sistem. Datele
elementare sunt fie „discrete”, adică cu valori fixe, fie „continous”, încadrate într-un
interval de valori;
10. orice valoare predefinită pe care o poate lua o data elementară. Valoarea predefinită
este afişată pe ecranele de introducere şi folosită pentru a reduce volumul datelor de preluat şi
al erorilor de introducere. Când se apelează la liste de tip drill-down, valorea predefinită este
cea selectată curent sau afişată cu altă culoare. Când se folosesc butoane radio, este selectată
opţiunea pentru valoarea predefinită, iar în cazul apelării la check box-uri, valoarea
predefinită este indicată prin bifare sau nu.
11. alte observaţii folosite pentru a indica formatul datei calendaristice, validările
specifice solicitate, metoda cifrei de control ş.a.
Un model de descriere a datelor elementare este redat în figura 7.20.
ID _________________________________________________________________
Denumire Cod client
Alias Ct_client, Nr. client
Descriere Identifică unic un client care a realizat cel puţin o operație/activitate în ultimii 5 ani
Caracteristici
Lungime ___6___ Nr. poziţii zecimale ____ Alfabetic
Format intrare ___9(6)__ Alfanumeric
Format ieşire ___9(6)__ Dată calendaristică
Valori predefinite _______ Numeric
Continous sau Discrete Bază Derivat
Criterii de validare
Continous Discrete
Limita superioară: <999999 Valoare Semnificaţie
_______ _______________
Limita inferioară: >0 _______ _______________
Observaţii: Cod client trebuie să treacă printr-o funcţie de verificare pe bază de
cheie de control modulo 11. Este derivat pentru că este generat automat, secvenţial la adăugarea
clientului în fişierul Clienti, fiind adăugată şi cifra de control
Pentru descrierea unei date elementare de tip alfabetic este prezentat exemplul din figura
7.22, care este o dată discretă, cu o listă de coduri de selectat pentru atribuirea valorilor. Când
această dată elementară va fi implementată în baza de date, şi utilizatorii vor fi instruiţi pentru
exploatarea sistemului, va fi necesar să se listeze un tabel cu valorile pe care ar putea să le ia şi
cu semnificaţia abrevierilor folosite.
ID _________________________________________________________________
Denumire Culoare
Alias
Descriere Culoarea pentru fiecare tip de articol de îmbrăcăminte
Caracteristici
Lungime ___2___ Nr. poziţii zecimale ____ Alfabetic
Format intrare ___X(2)__ Alfanumeric
Format ieşire ___X(2)__ Dată calendaristică
Valori predefinite _______ Numeric
Continous sau Discrete Bază Derivat
Criterii de validare
Continous Discrete
Limita superioară: ______ Valoare Semnificaţie
Limita inferioară: ___AB____ _Albastru______
___AL____ _Alb__________
___VR____ _Verde________
Observaţii:___________________________________________________________
este necesar să se analizeze mai multe structuri de fluxuri pentru a avea o descriere completă a
locurilor de stocare. De exemplu, când se adaugă o înregistrate pentru un client nou, se pot
include iniţial numai informaţiile cunoscute. Soldul contului, data tranzacţiei şi alte informaţii
pot fi adăugate în locul de stocare Clienti, după ce au avut loc anumite operaţii economice,
regăsindu-se în diferitele fluxuri de date, pe baza cărora se fac prelucrările specifice.
Descrierea locurilor de stocare se realizează prin intermediul elementelor:
1. identificatorul locului de stocare, obligatoriu în tehnica Gane&Sarson, pentru a
preveni înregistrarea datelor redundante;
2. denumirea semnificativă;
3. alias-urile sub care mai poate fi regăsit;
4. o scurtă descriere;
5. tipul de fişier, respectiv dacă este informatic sau specific sistemelor manuale (pe
suport de hârtie). Dacă este automat, trebuie specificat formatul, fie că este vorba de o
bază de date relaţională, o tabelă a acesteia sau un fişier clasic. Dacă este manual,
atunci se va specifica modul şi criteriile în care se vor adăuga informaţiile prelucrate
de pe documente;
6. numărul maxim şi minim de înregistrări, informaţie care ajută la estimarea spaţiului de
memorie solicitat şi determinarea sistemului de gestiune a datelor şi a echipamentelor
de folosit;
7. numele sub care mai poate fi identificat în cadrul actualelor aplicaţii, dacă este
cunoscut sau dacă este cazul;
8. structura datelor, care ar trebui să aibă denumirea deja în depozitul datelor, astfel încât
să se realizeze legătura cu datele elementare din structura fluxurilor de date sau a
celorlalte locuri de stocare. De asemenea, este necesar să se stabilească cheile primare
sau secundare.
9. observaţiile folosite pentru adăugarea de informaţii care nu se încadrează în nici una
din categoriile anterioare, cum ar fi momentul actualizării datelor, al realizării copiilor
de siguranţă, drepturile de acces etc.
În figurile 7.23 şi 7.24 se prezintă formularul de descriere a locurilor de stocare, respectiv
ecranul specific Visible Analyst.
ID _________________________________________________________________
Denumire Clienti
Alias Nom_Clienti, Fisier principal Clienti
Descriere Conţine câte o înregistrare pentru fiecare client al firmei
Caracteristicile locului de stocare
Tipul Informatic Manual
Format Bază de date Fişier indexat Fişier secvenţial
Mărimea înregistrării (caractere) _200_ Mărimea blocului 4000
Număr de înregistrări: Maxim 45000 Mediu 4200
Procent creştere a înregistrărilor pe an: 6%
Nume structură de date: Client.dbf
Structura datelor: Înregistrare client
Cheie principală: Cod client
Cheie secundară: Nume client
Cod poştal
Observaţii: Înregistrările din Nomenclatorul Clienti sunt copiate într-un fişier
istoric şi eliminate dacă un anumit client nu a mai cumpărat nimic în ultimii 5 ani.
Un client poate fi păstrat chiar dacă nu a cumpărat pe bază de catalog.
Fig. 7.24 Ecranul Visible Analyst pentru descrierea locului de stocare Clienti
cele care folosesc un cod sursă deja existent, adică cele incluse într-un alt sistem sau
în sistemul curent ca subprograme sau funcţii. Subprogramele sunt scrise, testate şi
memorate, executând o funcţie generală a sistemului, cum ar fi validarea unei date
calendaristice sau a unei cifre de control, astfel că ele sunt descrise numai o dată şi
utilizate ori de câte ori este necesar.
Fiecare specificaţie de proces trebuie să includă un formular de descriere, cu următoarele
elemente:
1. numărul procesului, care trebuie să fie identic cu cel din DFD;
2. denumirea procesului, care trebuie să coincidă cu cel din DFD;
3. scurtă descriere a ceea ce realizează procesul;
4. lista fluxurilor de intrare, apelând la numele regăsite în DFD. Numele datelor
elementare folosite în relaţiile de calcul sau operaţiile logice trebuie să fie identice cu
cele din depozitul metadatelor, pentru a asigura consistenţa lor şi o bună comunicare;
5. lista fluxurilor de ieşire, apelând la denumirea din depozit;
6. indicarea tipului de proces: pe loturi, on-line, manual. Toate procesele on-line solicită
proiectarea de ecrane, iar cele manuale trebuie să aibă proceduri foarte bine definite,
astfel încât salariaţii să-şi poată desfăşura activităţile specifice;
7. numele subprogramului sau funcţiei corespunzătoare pentru procesul care are deja
codul sursă existent;
8. logica procesului, care statuează regulile economice într-un limbaj natural şi nu într-
un limbaj de programare. Regulile economice sunt proceduri sau un set de condiţii şi
formule ce permit firmei să-şi desfăşoare activităţile specifice. Formatul comun al
unei reguli include:
definiţiile termenilor economici folosiţi;
condiţiile şi acţiunile economice;
restricţiile privind integritatea datelor;
formulele matematice;
operaţiile logice;
secvenţa prelucrărilor;
relaţiile dintre diferite evenimente;
9. dacă nu există suficient spaţiu pentru descrierea completă a procesului cu ajutorul
englezei structurate sau dacă logica procesului se realizează cu ajutorul arborilor sau
al tabelelor de decizie, se va face trimitere la numele lor şi se vor ataşa specificaţiilor
procesului;
10. se vor comunica aspectele nerezolvate, părţile incomplete ale descrierii proceselor,
pentru a fi clarificate în timpul unor noi interviuri.
În figura 7.25, este redat un formular de descriere a unui proces de prelucrare, iar, în 7.26,
ecranul din Visible Analyst.
ID _1.1_____________________________________________________________
Denumire Verificare existenţă produs
Descriere Se determină dacă un produs este disponibil sau nu pentru vânzare
Fluxurile de intrare
Comanda noua
Date modificare comanda
Date client
Date produs
Cantitate existenta
Fluxurile de ieşire
MODELAREA LOGICĂ, GRAFICĂ, A PROCESELOR DE PRELUCRARE 171
Rezumat
Crearea unor modele grafice ale sistemului este utilă pentru a obţine o imagine mult mai clară
asupra principalelor componente ale acestuia, cu ajutorul diferitelor diagrame. Modelarea conceptuală
(logică) a sistemului reprezintă începutul activităţilor cu caracter tehnic din dezvoltarea unui sistem, cu
scopul de a completa specificaţiile de analiză şi pentru o redare cuprinzătoare a elementelor ce vor fi
supuse proiectării.
Procesul prin care analiştii modelează funcţiile unui sistem reprezintă o abstractizare a activităţilor
fizice, cunoscută şi sub numele de echivalenţă logică. Un pas important în procesul de abstractizare îl
constituie descompunerea pe funcţii de prelucrare a sistemului sau descompunerea funcţională, prin care
se identifică principalele componente ale unui sistem (funcţii, procese, proceduri de prelucrare ş.a.),
obţinându-se o diagramă a descompunerii funcţionale.
Un model grafic ce s-a dovedit a fi deosebit de valoros pentru modelarea proceselor îl reprezintă
diagramele fluxurilor de date, fiind unul din cel mai utilizate. Într-o definiţie restrânsă, DFD-urile sunt o
metodă de prezentare grafică a traseului logic pe care îl parcurg datele prin diverse procese până sunt
transformate în ieşiri, redând toate componentele logice ale unui sistem într-o singură reprezentare
grafică, respectiv intrările, ieşirile, prelucrările şi locurile de stocare, precum şi graniţele sistemului.
Indiferent de metodologiile folosite în realizarea unui sistem/aplicaţie, toate apelează la operaţiunea
de modelare logică a datelor şi prelucrărilor sub formă de diagrame, diferenţele constând doar în folosirea
mai pronunţată a diagramelor pentru descrierea sistemului, încadrându-le în diagrame de context,
diagrame ale fluxurilor de date fizice şi diagrame ale fluxurilor de date logice. Altele apelează la
combinaţii de diagrame, tabele şi forme descriptive.
Diagrama descompunerii funcţionale stă la baza construirii „scheletului” diagramelor fluxurilor
date, pentru că pot fi generate automat, mai ales cu ajutorul instrumentelor CASE, şi anume: o diagramă
de context; o singură DFD de nivel 0; câte o DFD de nivel 1 pentru fiecare proces care se descompune
din diagrama de nivel 0; câte o DFD de nivel 2 pentru fiecare proces care se descompune din diagrama
de nivel 1; câte o DFD de nivel 3 pentru fiecare proces care se descompune din diagrama de nivel 2 etc.
Atunci când se construiesc DFD, pot să apară mai multe erori, dintre care cele mai comune sunt:
omiterea unui flux de date sau direcţionarea greşită a sensului; conectarea locurilor de stocare şi
entităţilor externe între ele; denumirea incorectă a proceselor sau fluxurilor de date; utilizarea unui
număr prea mare sau prea mic de fluxuri; descompunerea nebalansată a diagramelor superioare în
diagramele-copil.
În afara prezenţei elementelor necesare într-o DFD, se va urmări ca acestea să fie descrise detaliat în
dicţionarul proiectului, numit depozit de metadate (repository). În cele mai multe produse CASE, acest
depozit este legat de diagramă, ceea ce înseamnă că pentru orice simbol al diagramei se va crea automat o
poziţie în depozit, poziţie ce urmează să fie completată de analist.
Întrebări recapitulative
1. Ce rol are diagrama descompunerii funcţionale în modelarea sistemului?
2. Definiţi tipurile de diagrame ale fluxurilor de date ce pot fi construite în timpul analizei?
3. Enumeraţi cel puţin patru avantaje ce pot fi obţinute din modelarea sistemului cu ajutorul
diagramelor fluxurilor de date comparativ cu descrierea narativă a acestuia. Motivaţi avantajele.
4. Care sunt cele patru simboluri utilizate în modelarea sistemului cu ajutorul DFD?
5. Care este semnificaţia conceptului de „explodare” a DFD?
6. Enumeraţi regulile privind procesele ce trebuie respectate la construirea DFD.
7. Enumeraţi regulile privind locurile de stocare ce trebuie respectate la construirea DFD.
8. Enumeraţi regulile privind entităţile externe ce trebuie respectate la construirea DFD.
9. Care este rolul depozitului de metadate?
10. Care este conţinutul formularului de descriere a unui flux de date?
11. Care este conţinutul formularului de descriere a unei date elementare?
Probleme de echipă
1. Plecând de la experienţa avută din momentul înscrierii la ultimul concurs de admitere şi până la un
eveniment ce a avut loc după doi ani, încercaţi să:
MODELAREA LOGICĂ, GRAFICĂ, A PROCESELOR DE PRELUCRARE 173
Obiective:
Discutarea necesităţii şi conţinutului modelării conceptuale a datelor
Prezentarea conceptelor utilizate în construirea diagramelor entitate-relaţie
Înţelegerea modului de transpunere a regulilor economice în modelul conceptual al datelor
Prezentarea unui model general al DER pentru sistemele informaţionale economice
Prin modelarea conceptuală a datelor se urmăreşte construirea unui model al datelor care
să asigure transpunerea exactă a realităţii din domeniul analizat, fără a lua în considerare
cerinţele specifice unui model de organizare a datelor (cum este modelul relaţional), criteriile
de calitate privind organizarea datelor, cerinţele nefuncţionale ale sistemului şi criteriile de
performanţă privind stocarea şi accesarea datelor. Modelul conceptual al datelor înseamnă o
formă de reprezentare a datelor organizaţiei astfel încât el să reflecte regulile de derulare a
afacerilor în firma respectivă. Rolul său este de a scoate în relief toate regulile privind
identitatea şi legăturile existente între date.
Cea mai cunoscută formă utilizată pentru modelarea conceptuală a datelor este diagrama
entitate-relaţie (DER). O modalitate aproape identică este folosită şi în analiza şi proiectarea
orientate-obiect.
Modelul conceptual este unul abstract, care nu poate fi implementat direct pe calculator.
De exemplu, modul în care vor fi implementate legăturile dintre entităţile de date nu
interesează în acest moment, atenţia fiind îndreptată doar spre identificarea şi descrierea lor.
Ulterior, acest model trebuie transformat într-o schemă a bazei de date sub formă de tabele,
coloane şi restricţii de integritate, reprezentând modelul logic al datelor.
Modelarea logică presupune organizarea datelor în tabele şi coloane, conform regulilor
modelului relaţional (acesta fiind cel mai popular model de organizare a datelor). După cum se
poate observa din figura 8.1, proiectarea logică a bazei de date presupune transformarea
modelului conceptual al datelor, prin aplicarea regulilor şi conceptelor specifice modelului
relaţional şi a criteriilor de calitate ale modelului logic al datelor, aspecte ignorate în etapa
modelării conceptuale. De exemplu, modelul relaţional nu permite implementarea relaţiilor
multe-la-multe dintre două entităţi de date, motiv pentru care acestea trebuie transformate în
două relaţii unu-la-multe.
Scopul urmărit constă în obţinerea unui model relaţional pur, nealterat de cerinţele
nefuncţionale şi cele de performanţă în stocarea şi accesarea datelor, nici de facilităţile oferite
de diferite SGBDR-uri existente pe piaţă. Toate aceste aspecte vor fi considerate abia la
construirea modelului fizic al datelor. Principalele criterii de calitate utilizate la evaluarea
modelului logic al datelor se referă la completitudine, non-redundanţă, reutilizare, flexibilitate
şi simplitate.
Modelul fizic al datelor, rezultat în urma proiectării fizice, este invizibil utilizatorilor şi
programatorilor. El specifică modul de stocare şi accesare fizică a datelor, utilizând facilităţile
oferite de un anumit SGBD. De exemplu, date din tabele diferite pot fi stocate pe disc
împreună pentru a putea fi transferate în memoria calculatorului printr-o singură operaţiune.
176 ANALIZA SISTEMELOR INFORMAŢIONALE
1. Teorey, T.J. – Database Modeling & Design, Morgan Kaufmann Publishers, Inc, San Francisco, 1999, p. 46-47.
MODELAREA CONCEPTUALĂ A DATELOR 177
şi nu se va opri asupra detaliilor privind modul în care sunt folosite în organizaţie ecranele,
rapoartele sau documentele.
Literatura2 recomandă mai multe modalităţi de formulare a întrebărilor astfel încât să se
obţină informaţiile necesare. În sinteză, ele pot fi redate astfel:
1. Ce obiecte/subiecte sunt într-o întreprindere? Ce tipuri de persoane, locuri, lucruri,
materiale ş.a. se folosesc sau interacţionează într-o unitate economică şi este necesară
culegerea datelor despre ele pentru a fi păstrate o anumită perioadă de timp? Câte
cazuri (instanţe) pot exista pentru fiecare obiect? – entităţi de date şi descrierea lor.
2. Ce caracteristică (caracteristici) unică (unice) ajută la diferenţierea obiectelor de
acelaşi tip? Elementul care ajută la diferenţierea obiectelor de acelaşi tip are caracter
permanent sau este unul temporar? Elementul caracteristic al unui obiect poate lipsi
atunci când noi ştim cu certitudine că obiectul există? – cheia primară.
3. Ce caracteristici se folosesc pentru descrierea fiecărui obiect? În ce mod se vor
efectua referirile, selecţiile, calificările, sortările şi clasificările obiectelor? Ce trebuie
să se ştie despre fiecare obiect astfel încât să se asigure buna funcţionare a unităţii? –
chei secundare.
4. Cum vor fi folosite datele nominalizate? Care este sursa datelor? Cine va face referire
la ele? Cine le poate modifica sau distruge? Cine nu are drept de folosire a lor? Cine
este responsabil cu corectitudinea datelor? – controale de securitate şi cunoaşterea
celor care au controlul semnificaţiei datelor.
5. Care ar fi perioada de apartenenţă a datelor ce ne interesează? Este necesară
cunoaşterea trendului datelor sau numai valoarea lor la un moment dat şi/sau valorile
estimate/proiectate ale lor? Când o caracteristică a unui obiect se schimbă în timp,
trebuie cunoscută ulterior valoarea anterioară? – cardinalitatea şi dimensiunea
temporală a datelor.
6. Toate cazurile („instanţierile”) sub care poate să existe un obiect sunt identice?
Există obiecte cu un comportament special în organizaţie? Există unele obiecte care
sintetizează sau reflectă forma combinată a altor obiecte mult mai detaliate? –
supertipuri, subtipuri şi agregări.
7. Ce evenimente contribuie la asocierea obiectelor între ele? Ce activităţi fireşti sau
care activități economice presupun folosirea datelor despre câteva obiecte de acelaşi
tip sau de tipuri diferite? – relaţiile, precum şi cardinalitatea şi gradul lor.
8. Fiecare activitate sau eveniment are aceeaşi formă de manifestare sau există şi forme
ce caracterizează anumite circumstanţe? Un eveniment presupune implicarea doar a
unor obiecte asociate sau acestea trebuie să existe în totalitate? Asocierile dintre
obiecte se schimbă de-a lungul timpului? Valorile ce scot în relief caracteristicile unor
date sunt exprimabile în cadrul unor limite? – reguli de integritate, cardinalitate
minimă şi maximă, dimensiunea temporală a datelor.
În afara tehnicilor enumerate anterior, informaţiile necesare construirii modelului datelor
se pot obţine şi prin urmărirea documentaţiei firmei, ecrane, rapoarte, formulare, din interiorul
sistemului. Acest proces este cunoscut în literatura de specialitate sub numele de metoda
bottom-up.
În caseta 8.1 se regăseşte un model de descriere narativă pentru sistemul de gestiune a
clienţilor, prezentat în capitolele anterioare, însă el este uşor orientat spre cerinţele privind
datele. Pe baza lui, vom încerca să punem în evidenţă, pe parcursul paragrafelor următoare,
activităţile desfăşurate pentru construirea DER şi modul în care poate fi citită această
documentaţie.
2. Aranow, E.B. – „Developing Good Data Definitions”, in Database Programming & Design, 2, August 1988, pp.
36-39; Sandifer, A., Von Halle, B. – „A Rule by Any Other Name”, in Database Programming & Design, 4,
March 1991, pp. 11-13; Sandifer, A., Von Halle, B. – „Linking Rules to Models”, in Data and Knowledge
Engineering, 7, 1991, pp. 47-83.
178 ANALIZA SISTEMELOR INFORMAŢIONALE
referă la: codul, numele şi adresa clientului; codul, denumirea şi unitatea de măsură a produselor;
cantităţile de livrat; data livrării.
2. Raport privind potenţialii clienţi, întocmit lunar sau la cererea conducerii, conţine informaţii
despre clienţii care au solicitat cataloage de produse, dar care nu au iniţiat încă nici o comanda de
cumpărare. În acest raport se includ numele şi adresa .
3. Raport privind vânzările, întocmit la cererea utilizatorilor, conţine informaţii despre livrările
efectuate într-o perioadă dată, pe depozite sau la nivelul firmei. În raport se includ codul şi numele
depozitului; numărul şi data facturii; codul, denumirea, unitatea de măsură şi preţul produselor;
cantităţile livrate; valoarea vânzării; totalul vânzărilor pe depozite şi totalul general al vânzărilor.
(1,1) (0,M)
CLIENT Participă VÂNZARE
Fig. 8.2 DER pentru relaţia Participă între entităţile CLIENT şi VÂNZARE
O vânzare, la rândul ei, constă din unul sau mai multe produse, dar şi produsele pot
constitui subiecte ale mai multor vânzări, deci între entităţile VÂNZARE şi PRODUS ambele
perechi de valori ce reprezintă cardinalitatea vor conţine valoarea M (adică multe). Continuăm
cu descrierea legăturilor/relaţiilor posibile: un PRODUS este în legătură directă doar cu o
180 ANALIZA SISTEMELOR INFORMAŢIONALE
(0,M)
Conţine
(1,M)
(0,1) (1,1)
STOC Are PRODUS
(1,M)
Conţine
(0,M)
În continuare, vom descrie pe larg fiecare din aceste etape, ocazie cu care vom introduce
atât conceptele, cât şi regulile pentru construirea DER.
3. Romney, M.B., Steinbart, P.J. – Accounting Information Systems, 9th Edition, Prentice Hall, Upper Saddle River,
New Jersey, 2003, p. 116.
182 ANALIZA SISTEMELOR INFORMAŢIONALE
Unii autori propun o a patra categorie de entităţi, respectiv locul în care se realizează un
eveniment, în timp ce alţii consideră că nu mai este necesară introducerea acestei categorii,
deoarece astfel de entităţi se referă adesea la resursele angajate în evenimentul respectiv4 sau la
agenţii angajaţi într-un eveniment (completarea noastră). Exemple de astfel de entităţi sunt
depozite, secţie de producţie etc. Depozitul reprezintă locul în care este înregistrată o operație
de intrare sau ieşire a bunurilor materiale din stoc.
În afara acestor entităţi, să le spunem concrete, există şi alte entităţi care nu se încadrează
în nici una din cele trei categorii şi pe care noi le numim entităţi-abstracte. Entitatea
CONSUM-SPECIFIC, care memorează date despre consumurile specifice de materiale pentru
obţinerea fiecărei unităţi de produs finit, reprezintă un astfel de exemplu.
Identificarea entităţilor reprezintă o activitate dificilă, mai puţin formalizată. Realizarea ei
presupune citirea cu atenţie a documentaţiei sistemului, în special a părţii în care sunt descrise
activitățile şi prelucrările din sistem. Se vor urmări activitățile (evenimentele economice) în
legătură cu care se doreşte memorarea de informaţii sau documentele care le consemnează,
resursele şi agenţii implicaţi în derularea fiecărui eveniment reţinut în sistem. De exemplu, din
analiza documentaţiei prezentată în caseta 8.1, pentru evenimentul primirea comenzii se vor
reţine în sistem, pe lângă entitatea-eveniment Comanda, entitatea-agent Client şi entitatea-
resursă Produs.
Entităţile de date potenţiale sunt evidenţiate în caseta 8.1 prin utilizarea caracterelor de
culoare roşie. Ele vor fi trecute într-o listă separată, din care vor fi eliminate cele care se
repetă, fiind păstrată o singură dată, sau cele care apar sub nume diferite, cum este cazul pentru
livrare şi factură.
Rezultatul acestei activităţi este prezentat în caseta 8.2.
Caseta nr. 8.2 – Lista entităţilor de date pentru sistemul de gestiune a clienţilor
Entităţi-eveniment:
1. Comanda,
2. Livrare
3. Returnare
Entităţi-resursă:
4. Produs
Entităţi-agent:
5. Client
6. Depozit.
află numele entităţii, urmată de atributele care o descriu, primul reprezentând cheia primară,
scrisă cu caractere îngroşate.
CNP
NUME ADRESA
MARCA
NUME
CNP
ADRESA
MESERIA
Sunt entităţi care pot avea două sau mai multe chei-candidat. În exemplul nostru, pot fi
chei-candidat MARCA şi CNP. Atunci când sunt mai multe chei-candidat, analistul trebuie să
decidă care dintre ele va fi folosită drept cheie-primară. O cheie-primară este o cheie-candidat
care a fost selectată pentru a servi ca identificator al instanţelor în cadrul unei entităţi.
Selecţia cheii-primare trebuie efectuată după anumite proceduri5, grupate în caseta 8.3.
SELECŢIA CHEII-PRIMARE
1. Alegeţi o cheie-candidat care să nu-şi schimbe propria valoare în timpul vieţii cazului/instanţei entităţii
respective.
2. Alegeţi acea cheie-candidat care, pentru fiecare caz/instanţă al/a entităţii, garantează faptul că atributul
sau grupul de atribute are o valoare corectă şi nu este nulă.
5. Bruce, T.A. – Designing Quality Databases with IDEF1X Information Models, Dorset House Publications, New
York, 1992.
184 ANALIZA SISTEMELOR INFORMAŢIONALE
3. De evitat aşa-zisele chei-secrete, care preiau în structura lor părţi ale unor atribute care semnifică
clasificări, locuri, coduri ş.a., întrucât ele se pot schimba frecvent, şi nici nu sunt publice.
4. Preferaţi formele scurte în locul celor complexe, formate din mai multe atribute, dacă este posibil.
În reprezentările din DER, în elipsa sau elipsele aferente atributului sau atributelor ce
formează cheia primară, numele respective se subliniază (vezi MARCA din entitatea
ANGAJAT). În cel de-al doilea model, prezentat în figura 8.4, cheia primară este plasată pe a
doua linie şi scrisă cu caractere îngroşate, după numele entităţii respective, iar în al treilea, ea
este subliniată.
Depistarea entităţilor unui sistem nu reprezintă o activitate tocmai uşoară. În multe situaţii
analistul trebuie să decidă dacă un obiect reprezintă o entitate sau un atribut al unei entităţi. Să
luăm, drept exemplu, obiectul LOCALITATE; el reprezintă o entitate sau un atribut? În
sistemul de aprovizionare, el ar putea reprezenta o entitate sau doar atributul entităţii furnizor.
La clasificarea entităţilor şi atributelor, trebuie respectate următoarele două reguli:
entităţile trebuie să conţină informaţii descriptive. Conform acestei reguli, dacă pentru
un obiect există informaţii descriptive (adică mai multe atribute care să o
caracterizeze), atunci el constituie o entitate, altfel acel obiect va reprezenta un atribut
al unei entităţi. Dacă pentru obiectul LOCALITATE sunt necesare mai multe
informaţii descriptive (cum ar fi judeţul, comuna, codul poştal etc.), atunci el trebuie
clasificat ca entitate. Dacă se solicită doar numele localităţii, atunci el va fi doar un
atribut al unei entităţi (cum ar fi FURNIZOR, ANGAJAT etc.).
un atribut trebuie ataşat acelei entităţi pe care o descrie în modul cel mai direct. De
regulă, o proprietate se referă la o singură entitate, deci un atribut va fi regăsit doar la o
singură entitate. În sistemul de aprovizionare, de exemplu, entitatea COMANDA nu va
conţine nici numele furnizorului (sau codul acestuia), nici denumirea materialului (sau
codul acestuia); aceste atribute caracterizează mai direct entităţile FURNIZOR,
respectiv Material. Nu intră sub incidenţa acestei reguli sinonimele. Un exemplu, în
acest sens, poate fi atributul adresa: el poate caracteriza atât entitatea ANGAJAT, cât
şi entitatea FURNIZOR.
Aşadar, clasificarea unui obiect ca entitate sau atribut presupune analiza cu multă atenţie a
documentaţiei sistemului în care sunt formulate şi detaliate cerinţele informaţionale.
Identificarea atributelor descriptive ale entităţilor presupune, în primul rând, analiza
documentaţiei privind intrările şi ieşirile din sistem, respectiv a documentelor primare şi a
rapoartelor. Mai concret, în acestă activitate ne interesează cerinţele privind structura acestora.
Aşadar, în caseta 8.1, vor fi analizate părţile B şi C din documentaţie.
O atenţie deosebită trebuie acordată alegerii entităţii căreia îi va fi ataşat fiecare atribut.
Nu trebuie uitat că unele atribute nu reprezintă caracteristica nici unei entităţi, ci a unei relaţii
dintre entităţi, aşa cum este cazul atributelor cantitate comandată sau cantitate livrată. Mai
trebuie reţinut că fiecare atribut trebuie asociat unei singure entităţi şi că atributele calculate,
precum valoarea vânzării, nu vor fi păstrate în DER. Problema includerii câmpurilor calculate
se pune abia în faza proiectării fizice a bazei de date, ea urmând a fi discutată în capitolul
dedicat acestei teme în volumul următor.
Identificarea atributelor necesare sistemului este mult uşurată în cazul utilizării CASE,
deoarece se poate analiza direct structura fluxurilor care accesează locurile de stocare, puse în
evidenţă în diagramele fluxurilor de date.
După identificarea atributelor fiecărei entităţi, trebuie ales unul sau mai multe dintre
acestea care vor juca rolul de cheie primară (simplă sau compusă). Dacă nici unul dintre
atribute nu poate fi cheie, atunci se introduce un atribut special care să joace acest rol. O astfel
de situaţie găsim în exemplul nostru la entitatea Comanda.
Rezultatul acestei activităţi, pentru sistemul analizat, este prezentat în figura 8.5. Cheile
primare sunt evidenţiate prin caractere îngroşate.
MODELAREA CONCEPTUALĂ A DATELOR 185
NrFactura
Livrare Depozit
DataFactura
NrNotaRefuz NrFactura
DataRefuz CodDepozit
DataFactura
Motivatie NumeDepozit
NUME MESERIA
NUME_ÎNTREÞINUT,
MARCA ANGAJAT VÂRSTA_ÎNTREŢINUT
CNP ADRESA
NUME_ÎNTREŢINUT VÂRSTA_ÎNTREŢINUT
NUME MESERIA
Este
PERSOANA căsătorit ANGAJAT Conduce
cu
Unu-la-unu Unu-la-multe
a) Relaţie unară
MODELAREA CONCEPTUALĂ A DATELOR 187
b) Relaţie binară
PIESA
CANTITATE
c) Relaţie ternară
Fig. 8.8 Exemple de relaţii unare, binare, ternare
Referirea la gradul unei relaţii se mai face şi în alte moduri, cum ar fi ordin sau rang al
relaţiilor.
(1,1) (0,1)
FACTURA Are RECEPŢIE
(0,M) (1,M)
FACTURA Conţine PRODUS
6. Korth, H.F., Silberschatz, A. – Sistemes de gestion de bases de donees, McGraw-Hill, Paris, 1988, citat în
Fotache, M. – Baze de date relaţionale. Organizare şi interogare, Ed. Junimea, Iaşi, 1996, p. 69.
MODELAREA CONCEPTUALĂ A DATELOR 189
entităţii x din baza de date. Se spune că existenţa instanţei x depinde de existenţa instanţei y.
Entitatea Y este denumită entitate dominantă, iar entitatea X este numită entitate dependentă.
Revenind la exemplul din figura 8.9, se observă că, în relaţia Emitere, entitatea
FACTURA are cardinalitatea minimă „1”, deci este obligatorie participarea oricărei instanţe
(facturi) într-o relaţie, în timp ce cardinalitatea minimă pentru entitatea FURNIZOR este „0”,
ceea ce înseamnă că nu este obligatorie participarea fiecărui furnizor în relaţia emitere (va
putea exista un furnizor care să nu aibă în corespondenţă nici o factură). De asemenea, putem
spune că entitatea FACTURA este dependentă de entitatea FURNIZOR, sau că FURNIZOR
este entitatea dominantă. Ştergerea unei facturi nu atrage automat şi ştergerea furnizorului care
a emis-o, deoarece este posibil ca în baza de date să mai rămână facturi primite de la furnizorul
respectiv. În schimb, ştergerea unui furnizor atrage după sine ştergerea tuturor facturilor
aferente acestuia. De asemenea, adăugarea unei facturi noi poate fi făcută numai dacă ea este
legată de un furnizor.
Cardinalitatea minimă poate fi redată şi grafic. Cercul suprapus pe latura entităţii indică,
de fapt, poziţia zero (valoarea minimă poate fi şi zero), conferind relaţiei caracterul opţional.
Simbolul folosit pentru a marca relaţiile obligatorii este acelaşi cerc, cu deosebirea că este
haşurat.
8.4.3.3 Rolul relaţiilor
Rolul defineşte funcţia care atrage două sau mai multe entităţi într-o relaţie. Pentru o
relaţie se poate specifica rolul fiecărei entităţi asociate, iar prin combinarea rolurilor jucate de
entităţile asociate se obţine numele relaţiei. De exemplu, revenind la relaţia dintre FACTURA
şi FURNIZOR, numele acestei relaţii poate fi descris sub forma emite/este emisă, după cum se
poate observa şi în figura 8.12. Rolul entităţii FURNIZOR este Emite, iar cel al entităţii
FACTURA este este emisă.
Factura (0,M) Emite/este (1,1) Furnizor
emisa
Necesitatea specificării rolului relaţiilor este evident atunci când între două entităţi există
mai multe relaţii. De exemplu, s-ar putea spune că „FURNIZOR oferă PRODUS”, dar şi
„PRODUS este cumpărat de la FURNIZOR”, ceea ce s-ar putea reprezenta ca în fig. nr. 8.13.
Oferă
(0,M) (0,M)
PRODUS FURNIZOR
(0,M) (0,M)
Este
cumpărat
de la
(0,M)
Să punem în discuţie un alt exemplu, cel al relaţiei Emite dintre entităţile FACTURA şi
PRODUS. Un produs poate fi conţinut în mai multe facturi, după cum şi o factură poate
conţine mai multe produse. Prezentăm, mai jos, câteva dintre datele concrete:
NUMĂR_FACTURĂ DENUMIRE_PRODUS CANTITATE
1111 Produs A 25
1111 Produs B 15
2222 Produs A 70
2222 Produs C 40
Din analiza cazurilor rezultă că factura 1111 conţine două produse, A şi B, cu cantităţi
diferite (25, respectiv 15), deci CANTITATE nu este o proprietate a entităţii FACTURA. Dar
nu este nici o proprietate a entităţii PRODUS, cât timp acelaşi produs poate fi conţinut în două
MODELAREA CONCEPTUALĂ A DATELOR 191
sau mai multe facturi cu cantităţi diferite (produsul A se regăseşte pe ambele facturi, cu
cantităţile 25 şi 70). În schimb, CANTITATE este o proprietate a relaţiei dintre FACTURA şi
PRODUS. Atributul se asociază relaţiei şi se prezintă sub formă de diagramă, ca în figura 8.15.
CANTITATE
(0,M) (1,M)
FACTURA Conţine PRODUS
De aici rezultă un caz aparte de entitate, numită gerundivă sau compusă sau asociativă
care, de fapt, este o relaţie folosită de analist în model ca un tip de entitate. În astfel de cazuri,
se foloseşte un simbol special: dreptunghi cu romb în interior, în care se scrie numele entităţii
(fig. 8.16).
CANTITATE
(0,M) (1,M)
FACTURA Con ţine PRODUS
Relaţii purtătoare de atribute pot fi întâlnite doar în cazul relaţiilor de tipul „multe-la-
multe” sau al relaţiilor ternare. Relaţiile binare de tipul „unu-la-unu” sau „unu-la-multe” nu pot
avea atribute.
7. Modelul prezentat este adaptat şi completat după Romney, M.B., Steinbart, P.J. – op.cit.
192 ANALIZA SISTEMELOR INFORMAŢIONALE
(1,1)
Particip ă Agent extern
(0,M)
(1, ?) (0,M)
Obţinere
Resursa A Intrare
resursã A
(?,?) (1,1)
(0,M) Particip ă
(0,M)
Particip ă (1,1)
(?,?)
Furnizare
Resursa B Ieşire
(1, ?) (0,M) resursă B
(0,M)
În figura 8.17 se regăsesc toate cele trei tipuri de entităţi specifice sistemelor
informaţionale economice: evenimente, resurse şi agenţi. La identificarea entităţilor trebuie
acordată o atenţie deosebită obiectelor (evenimente, resurse sau agenţi) diferite dar omogene
(adică descrise de aceleaşi atribute), care pot fi reunite în aceeaşi entitate. De exemplu,
entităţile-resursă MATERIAL, OBIECT_INVENTAR_DEPOZIT şi PRODUS_FINIT pot fi reunite
în aceeaşi entitate, numită eventual BUN_MATERIAL, deoarece toate aceste resurse sunt
descrise de regulă prin aceleaşi atribute (Cod, Denumire, UM, Preţ, Stoc). Asemănător, pot fi
reunite entităţile-agent FURNIZORI şi CLIENŢI.
În modelul propus, se regăsesc trei tipuri de relaţii din punctul de vedere al entităţilor
implicate. În primul rând, fiecare entitate-eveniment este legată de o entitate-resursă. De
exemplu, entitatea-eveniment VÂNZARE este legată de entitatea-resursă PRODUS, pentru a
reflecta diminuarea stocului de produse finite. Un alt eveniment, COMANDA, care reflectă un
angajament pe viitor al firmei, va fi legat tot de resursa PRODUS, ce va fi afectată la o dată
ulterioară prin respectarea angajamentului.
În al doilea rând, fiecare entitate-eveniment este legată de două entităţi-agent. Agentul
intern este reprezentat de angajatul care are responsabilitatea gestionării resursei afectate sau a
autorizării evenimentului respectiv şi care, implicit, va avea dreptul să introducă sau să
modifice datele în baza de date. De regulă, ea este regăsită sub forma entităţii UTILIZATOR,
care va avea ca instanţe angajaţii firmei, inclusiv datele privind responsabilităţile acestora. Tot
ca agenţi interni se vor regăsi şi diferitele subunităţi organizatorice implicate în efectuarea
operațiilor interne. De exemplu, în evenimentul consum de materiale sunt implicate depozitul,
care eliberează materialele, şi departamentul care le solicită. Agentul extern se referă la terţul
din afara firmei care este implicat în derularea evenimentului respectiv. Entitatea-eveniment
VÂNZARE va fi legată de entitatea-agent CLIENT.
Al treilea tip de relaţie se referă la legăturile dintre entităţile-eveniment, care reflectă
natura economică duală a majorităţii evenimentelor din cadrul sistemelor informaţionale
economice de tipul intrare-ieşire. De exemplu, evenimentul VANZARE, care implică
decrementarea resursei PRODUS, este legat de evenimentul ÎNCASARE, care presupune
incrementarea resursei FOND_BĂNESC. Se reflectă astfel principiile de desfăşurare a
afacerilor care implică adesea consumarea unor resurse în vederea obţinerii altora. De
asemenea, pot să apară relaţii între entităţile-eveniment care reflectă un angajament pe viitor şi
cele care privesc activitățile economice realizate în baza angajamentului. O astfel de relaţie
este cea dintre entităţile COMANDA şi VÂNZARE. Prin introducerea unor asemenea relaţii în
modelul conceptual al datelor şi specificarea cardinalităţii, se poate arăta faptul că nu se
acceptă înregistrarea unei operații (vânzări) fără existenţa unui angajament anterior (comanda).
MODELAREA CONCEPTUALĂ A DATELOR 193
Alte aspecte relevante privind modul de desfăşurare a afacerilor de către organizaţii sunt
reflectate prin cardinalitatea relaţiilor. În continuare, vom pune în discuţie cardinalitatea pentru
fiecare dintre cele trei tipuri de relaţii amintite anterior.
Cardinalitatea relaţiilor dintre entităţile agent şi eveniment
În figura 8.17 se poate observa că atât minimul, cât şi maximul cardinalităţii asociate
entităţilor-eveniment în fiecare relaţie eveniment-agent este 1 (după cum ştiţi deja,
cardinalitatea este reprezentată invers în diagramă). Această situaţie este întâlnită aproape
întotdeauna, reflectând faptul că trebuie să existe un agent, şi numai unul, care să fie implicat
în orice eveniment pentru ca organizaţia să evidenţieze responsabilitatea derulării
evenimentului respectiv. O instanţă VÂNZARE trebuie să aibă în corespondenţă un CLIENT şi
numai unul, astfel încât să se poată identifica în mod cert creanţa creată. Aceeaşi cardinalitate
va fi şi în relaţia cu agentul intern, pentru a se putea şti cu exactitate angajatul responsabil de
operaţia respectivă de vânzare.
Perechea (0,M) reprezintă cardinalitatea tipică asociată entităţii agent în relaţiile agent-
eveniment. Cardinalitatea maximă M asociată unui agent intern este pe deplin justificată,
deoarece este de aşteptat ca un angajat să autorizeze mai multe evenimente de un anumit tip
(de exemplu vânzări). De asemenea, un agent extern va avea cardinalitatea maximă M pentru
că organizaţia se angajează în relaţii de afaceri repetate cu acelaşi furnizor sau client.
Cardinalitatea minimă 0 este explicată prin două raţionamente. Mai întâi, organizaţia doreşte să
poată adăuga date despre un client sau furnizor chiar dacă el nu a fost implicat încă în nici un
eveniment. Cel de-al doilea motiv este legat de faptul că entităţile-eveniment reprezintă de fapt
fişiere de tranzacţii (sau temporare), în timp ce entităţile-agent sunt fişiere nomenclatoare (sau
permanente). La anumite intervale regulate de timp (de exemplu, la sfârşitul anului), conţinutul
fişierelor de tranzacţii este şters după ce s-a efectuat arhivarea, în timp ce informaţiile despre
agenţi sunt permanente. Prin urmare, la începutul unei perioade de timp (de exemplu, la
începutul anului) nici un agent nu va avea în corespondenţă vreun eveniment.
Cardinalitatea relaţiilor dintre entităţile resursă şi eveniment
După cum rezultă din figura 8.17, perechea (0,M) este cardinalitatea tipică asociată
entităţilor-resursă în relaţiile resursă-eveniment, din aceleaşi motive prezentate anterior pentru
entităţile-agent. Un anumit produs poate face obiectul mai multor operaţii de vânzare, la fel
cum poate să nu se regăsească pe nici una.
Cardinalitatea minimă asociată entităţilor-eveniment este de regulă 1, ceea ce înseamnă că
fiecare eveniment trebuie să implice cel puţin o instanţă a entităţii-resursă cu care este în
legătură, adică el va afecta cel puţin o resursă. O vânzare va conţine cel puţin un produs, iar o
încasare va afecta cel puţin un cont de disponibilităţi. Excepţii de la această regulă generală
apar în cazul relaţiilor alternative dintre entităţi, însă aceste tipuri de relaţii le vom prezenta în
paragraful următor. În schimb, nu există o regulă generală în ce priveşte cardinalitatea maximă
asociată entităţilor-eveniment, motiv pentru care am apelat la simbolul „?”. Ea depinde de
natura resursei implicate sau de regulile de desfăşurare a afacerilor din organizaţie. De
exemplu, o încasare va avea în corespondenţă un singur cont de disponibilităţi băneşti
(cardinalitatea maximă va fi 1), în timp ce o vânzare poate conţine mai multe produse
(cardinalitatea maximă va fi M).
Cardinalitatea relaţiilor dintre entităţile eveniment
Pentru relaţiile dintre două entităţi-eveniment orice cardinalitate este posibilă, neexistând
reguli generale, tipice. Totuşi, o regulă ce poate fi reţinută pentru relaţiile dintre două
evenimente este cea care relevă caracterul temporal: cardinalitatea minimă a evenimentului
care se realizează primul în timp va fi 0, deoarece la momentul respectiv celălalt eveniment nu
a avut loc; cel mai adesea, dar nu întotdeauna, cardinalitatea minimă corespunzătoare celui de-
194 ANALIZA SISTEMELOR INFORMAŢIONALE
Comanda
Returnare
CodComanda Livrare NrFactura
NrComanda (1,M) (0,1) (1,1) (0,1) DataFactura
DataComanda Onorare NrFactura Corespunde
DataFactura NrNotaRefuz
TermenLivrare DataRefuz
StareComanda (0,M) (0,M) Motivatie
(0,M) (0,M)
Cantitate
Emite returnata
Emite Conţine
Stoc
(1,1) curent
(1,1) Depozit (1,M)
(1,M)
Client CodDepozit Produs
NumeDepozit Este în
CodClient stoc CodProdus
NumeClient (0,M) DenProdus
Adresa UM
CodFiscal Conţine PretUnitar
(1,M)
Sold
LimitaCredit
TipClient Cantitate
comandata
Pe de altă parte, se poate observa că există locuri de stocare care nu-şi găsesc
corespondentul în DER, cum ar fi Promoţii şi Catalog. Explicaţia este următoarea: funcţiile
(procesele de prelucrare) care accesează acele locuri de stocare nu sunt vizate pentru
informatizare, deci nu prezintă interes imediat din perspectiva dezvoltării sistemului
informatic. Prin urmare, s-a considerat că nu este nevoie de memorarea datelor în legătură cu
cele două entităţi. Aceste date se vor regăsi doar pe hârtie.
Legătura strânsă dintre cele două tipuri de diagrame, şi într-un sens, şi în celălalt, reclamă
construirea lor în paralel. Se va începe mai întâi cu diagrama fluxurilor de date pentru a pune
în evidenţă principalele funcţii şi procese din sistem, însă, când se ajunge la un nivel suficient
de detaliere, se poate trece la construirea DER. Apoi se revine cu modificări şi completări
asupra diagramei fluxurilor de date. Astfel de treceri, de la un model la altul, vor fi realizate ori
de câte ori este nevoie.
Disciplina
(0,M) (1,M) Se
Emite FACTURA plăteşte
(1,M) (1,1)
Rezumat
Aplicarea principiului abstractizării presupune modelarea datelor pe trei niveluri: conceptual, logic
şi fizic. Modelarea pe aceste trei niveluri de abstractizare este justificată de necesitatea stăpânirii
complexităţii sistemului, analistul având posibilitatea de a se concentra, la un moment dat, doar asupra
anumitor aspecte, ignorându-le momentan pe celelalte. În faza de analiză se efectuează doar modelarea
conceptuală a datelor, celelalte două modele fiind realizate pe parcursul fazei de proiectare.
Modelarea conceptuală a datelor presupune transpunerea exactă a realităţii din domeniul analizat,
fără a lua în considerare cerinţele specifice unui model de organizare a datelor sau criteriile de
performanţă privind stocarea şi accesarea datelor. Modelul rezultat trebuie să reflecte regulile de derulare
a afacerilor în firma respectivă sub forma entităţilor de date şi a legăturilor dintre ele.
Pentru reprezentarea modelului conceptual se apelează la diagrama entitate relaţie (DER),
construită prin utilizarea a trei tipuri de obiecte: entităţi de date, relaţii între entităţi şi atribute.
Realizarea DER implică parcurgerea a patru etape: identificarea entităţilor de date, descrierea lor prin
intermediul atributelor, definirea relaţiilor dintre entităţi şi descrierea lor prin specificarea eventualelor
atribute, dar şi prin apelarea la conceptele grad, cardinalitate şi rol.
O entitate este o persoană, un loc, un obiect, eveniment sau concept din domeniul de activitate a
utilizatorului despre care organizaţia doreşte să păstreze anumite date. Entităţile pot fi încadrate în una
din următoarele patru categorii: resurse, evenimente, agenţi şi entităţi-abstracte.
O relaţie reprezintă legătura care există în lumea reală între una, două sau mai multe entităţi, ea
neavând o existenţă fizică sau conceptuală de sine stătătoare, ci depinde de entităţile asociate. Din acest
motiv, identificarea relaţiilor reprezintă o activitate dificilă, care solicită multă experienţă şi atenţie.
Odată identificate, relaţiile sunt descrise prin intermediul gradului, cardinalităţii, atributelor şi rolului.
Întrebări recapitulative
1. Explicaţi de ce este importantă modelarea conceptuală a datelor ca activitate de dezvoltare a
sistemelor informaţionale.
2. Realizaţi o comparaţie între diagrama fluxurilor de date şi diagrama entitate-relaţie.
3. Enumeraţi şi definiţi principalele concepte utilizate în modelarea conceptuală a datelor.
4. Care sunt tipurile de relaţii ternare din punctul de vedere al cardinalităţii?
5. Explicaţi cum poate fi pus în evidenţă caracterul temporal al legăturii dintre două entităţi-eveniment.
6. Explicaţi de ce relaţia între entităţile Livrare şi Produs ar fi redundantă, dacă ar fi introdusă în DER
pentru sistemul de gestiune a clienţilor, prezentată în figura 8.18. Specificaţi ce modificare trebuie
realizată în politica de afaceri a firmei, inclusiv în DER din figura 8.18, pentru ca relaţia dintre cele
două entităţi să nu mai fie redundantă.
198 ANALIZA SISTEMELOR INFORMAŢIONALE
Probleme de echipă
1. Redactaţi o scurtă documentaţie asupra unei componente, la liberă alegere, a sistemului
informaţional dintr-o firmă care să conţină informaţiile necesare modelării conceptuale a datelor.
2. Daţi câte două exemple de entităţi-resursă, entităţi-eveniment şi entităţi-agent din următoarele
subsisteme informaţionale: Urmărirea vânzărilor, Urmărirea achiziţiilor, Gestiunea producţiei.
3. Puneţi în evidenţă, printr-un exemplu, importanţa rolului relaţiilor dintre entităţi. Comentaţi exemplul
ales.
4. Daţi un exemplu de relaţie ternară şi interpretaţi cardinalitatea ei.
5. Puneţi în evidenţă, printr-un exemplu, importanţa cardinalităţii minime a relaţiilor.
6. Construiţi DER pe baza documentaţiei redactate la punctul 1.
7. Daţi două exemple de relaţii între două entităţi-eveniment şi explicaţi în ce constă dualitatea celor
două relaţii.
CAPITOLUL IX
Întregul efort depus până în momentul de faţă s-a concretizat într-o bogată acumulare de
informaţii despre cerinţele sistemului, structurate sub diverse forme, precum şi despre modul în
care am dori să fie conceput noul sistem sau ce corecţii să i se aducă celui vechi.
Obiectivul principal urmărit în faza de analiză l-a reprezentat definirea a „ceea ce este” şi
a „ceea ce ar trebui să fie” sistemul informaţional. În acest sens, au fost realizate două activităţi
importante: determinarea cerinţelor sistemului şi structurarea (formalizarea) acestora. Prin
determinarea cerinţelor sistemului s-a urmărit, mai întâi, descrierea a ceea ce face sistemul
existent, prin prezentarea proceselor de prelucrare, a fluxurilor informaţionale, a procedurilor
de lucru, a documentelor şi rapoartelor din sistem. Apoi, s-a urmărit identificarea a ceea ce
doresc utilizatorii de la noul sistem. Structurarea cerinţelor sistemului a vizat dezvoltarea
modelului logic al sistemului. Fluxurile informaţionale dintre procesele de prelucrare au fost
reprezentate prin diagrama fluxurilor de date, logica prelucrării datelor a fost descrisă prin
intermediul tabelelor de decizie sau a englezei structurate, modelul conceptual al datelor a fost
transpus prin intermediul diagramei entitate-relaţie.
organiza întâlniri pentru a se explica noul sistem, pe baza prezentărilor orale, a sintezei
conducerii privind cerinţele utilizatorilor şi a unor documente dintre cele întocmite anterior.
După acceptul utilizatorilor, conducerile departamentelor implicate vor semna documentele
necesare aprobării rezultatelor fazei desfăşurate.
Analiza de sistem se finalizează cu raportul analizei de sistem, prin care se sintetizează şi
se documentează constatările etapei de analiză. Un raport sintetic şi un exemplar din
documentaţie servesc drept elemente de bază pentru proiectanţii de sistem.
Raportul analizei conţine:
scopul, domeniul, obiectivele şi restricţiile proiectului;
legătura proiectului cu planul strategic al întregului sistem informaţional;
criticile aduse sistemului de către analişti;
o sinteză a problemelor existente în sistemul curent şi restricţiile lui;
recomandări pentru îmbunătăţirea sistemului existent şi proiectarea celui nou;
descrierea informaţiilor necesare luării deciziilor;
o sinteză a tuturor studiilor de fezabilitate (tehnică, economică ş.a.), cu recomandarea
ca sistemul să fie continuat sau nu;
estimarea timpului, a costurilor şi a resurselor necesare noului sistem;
planurile preliminare ale fazei de proiectare a sistemului.
Decizia de a merge sau nu mai departe se ia, în principiu, de trei ori în timpul analizei
sistemului: în timpul investigării iniţiale pentru a se stabili dacă se va trece mai departe la
studierea sistemului; la sfârşitul studiului de fezabilitate, pentru a se stabili dacă se va trece la
etapa de determinare a necesarului de informaţii; după terminarea fazei de analiză, pentru a se
hotărî dacă se va continua cu faza de proiectare.
1. Oprea, D. – Analiza şi proiectarea sistemelor informaţionale economice, Ed. Polirom, Iaşi, 1999, p. 277.
202 ANALIZA SISTEMELOR INFORMAŢIONALE
similar de problemă, varianta propusă de ei va fi ultima lor realizare la dezvoltarea unui alt
sistem. Dacă ea ar fi şi cea mai bună soluţie nu ar fi nimic grav, însă, de multe ori, propunerea
este subiectivă.
Date fiind aceste tendinţe, s-a ajuns la concluzia că o echipă de analiză trebuie să propună
cel puţin două soluţii la problema supusă analizei. În teorie se spune că, dacă există trei seturi
de formulări ale cerinţelor, trei medii de implementare şi patru surse ale softului de aplicaţii,
rezultă în total 36 de strategii posibile de proiectare. În practică însă, multe dintre acestea pot fi
nefezabile sau lipsite de interes, ceea ce se rezumă, în final, la acordarea atenţiei cuvenite doar
pentru trei variante. Numărul este agreat de cei mai mulţi specialişti, întrucât prin el s-ar
surprinde punctele esenţiale ale unui spectru posibil de soluţii: cele două extremităţi ale lui şi
mijlocul. În cele ce urmează, vom face o scurtă descriere a fiecăreia dintre cele trei variante.
Varianta 1 reprezintă partea de jos a spectrului şi poate fi caracterizată astfel:
este cea mai conservatoare în ceea ce priveşte costurile, efortul depus şi tehnologiile
implicate;
de cele mai multe ori, soluţionarea problemei nu înseamnă numai folosirea
calculatorului;
este puternic orientată spre realizarea, pe hârtie, a fluxurilor informaţionale mai
eficiente sau spre eliminarea redundanţelor din procesele curente;
oferă tot ceea ce a solicitat utilizatorul, printr-un sistem care diferă foarte puţin de cel
existent.
Varianta 2, de la celălalt capăt al spectrului, superior, merge mult mai departe decât
simpla rezolvare a problemei şi conţine performanţe pe care probabil că utilizatorul şi le-ar
dori. Caracteristicile esenţiale sunt:
orientarea spre funcţionalitate;
costurile nu constituie problema cea mai importantă;
se oferă cele mai performante sisteme bazate pe cele mai avansate tehnologii;
sistemul este deschis unor posibile extensii viitoare;
utilizatorul este copleşit de varianta propusă, dar nu întotdeauna poate să identifice o
astfel de variantă din cauza resurselor limitate.
Varianta 3, situată între cele două prezentate, se află la mijlocul spectrului.
Caracteristicile ei sunt:
combină trăsăturile celorlalte două variante, renunţând la obsesia încadrării în anumite
costuri şi preluând ca obiectiv central funcţionalitatea de înalt nivel;
este varianta de compromis.
Încadrarea în cele trei soluţii se realizează printr-o minuţioasă analiză a cerinţelor
sistemului.
Selectarea celei mai bune dintre ele se efectuează cu ajutorul procedurilor cantitative.
Analiştii pot sugera varianta percepută de ei ca fiind cea mai bună, dar echipa managerială va
avea ultimul cuvânt. Un proiect poate fi, de asemenea, oprit în această etapă.
Oricum, în această subfază trebuie să se realizeze următoarele activităţi:
1. Generarea strategiilor posibile de proiectare.
2. Selectarea celei mai bune strategii.
3. Prezentarea planului de bază al proiectului pentru regăsirea strategiei selectate în
sistemul informaţional în curs de realizare.
În continuare, vom aborda, pe rând, aceste trei activităţi.
sursele softului
selecţia softului şi a hardului;
implementarea;
limitele organizaţiei.
Variantele proiectului trebuie să respecte două categorii de condiţii, prezentate sub forma:
funcţiilor obligatorii ale noului sistem;
restricţiilor impuse.
1. Stabilirea minimului necesar de informaţii solicitate de noul sistem
Trăsăturile pe care le poate dobândi sistemul sunt împărţite, uneori, în trei categorii:
obligatorii, importante şi dorite.
Trăsăturile sau caracteristicile sistemului se concretizează în:
datele reţinute în sistem;
ieşirile sistemului (rapoarte, ecrane, documente, răspunsuri la întrebări);
analizele pe baza cărora se obţin noi informaţii;
accesibilitatea, timpul de răspuns, modul de exploatare (în timp real, partajat ş.a.).
2. Determinarea restricţiilor din noul sistem
Restricţiile pot fi generate de factori ca:
un termen anume când sistemul trebuie schimbat;
resursele financiare şi umane disponibile;
elementele din sistemul curent ce nu pot fi schimbate;
restricţii impuse de cadrul legislativ sau de contracte;
importanţa datelor şi dinamica problemei supuse analizei impun limite referitoare la
modul de realizare a sistemului (de exemplu, dacă se gestionează date strict secrete,
sistemul nu poate fi realizat de alte firme).
Ambele considerente trebuie să fie identificate şi ierarhizate după importanţa lor,
explicându-se clar care sunt motivele ordonării lor într-o anumită formă.
În continuare, vom pune în discuţie principalele probleme care stau la baza generării
variantelor strategice de proiectare. În acest sens, vom demonstra modul în care pot fi
formulate diferite strategii în legătură cu o anumită problemă, dar vom oferi şi o scurtă
descriere a celor mai importante variante întâlnite în practică, ce o considerăm utilă în
activitatea de evaluare şi selecţie a celei mai bune strategii.
Pentru a decide asupra funcţiilor (cerinţelor funcţionale) ce vor fi incluse în sistem este
necesară formularea unor variante de proiectare. Fiecare variantă va îngloba mai puţine sau
mai multe din cerinţele utilizatorilor. Această sarcină poate fi uşurată prin gruparea cerinţelor
sistemului în trei categorii: obligatorii, importante şi dorite. Stabilirea priorităţii fiecărei
cerinţe este efectuată împreună cu utilizatorii şi poate fi realizată chiar în faza de analiză, pe
măsură ce acestea sunt identificate.
Determinarea priorităţii fiecărei funcţii se face, de regulă, în strânsă legătură cu descrierea
nivelului de informatizare a sistemului. Nivelul de informatizare priveşte suportul pe care
sistemul informatic îl va oferi pentru fiecare funcţie în parte. Pentru cele mai multe funcţii ale
unui sistem, pot fi definite cel puţin trei niveluri de informatizare: mic, mediu şi mare.
În cazul unui nivel mic de informatizare, sistemul se va limita la gestiunea înregistrărilor
care privesc acea funcţie. Aplicaţia va conţine formulare pentru introducerea, modificarea,
validarea şi salvarea datelor; va furniza unele informaţii sub forma rapoartelor programate. Un
nivel mare de informatizare presupune ca sistemul să realizeze cât mai multe din prelucrările
specifice funcţiei respective. Definirea acestui nivel este foarte dificilă. Dacă în cazul unui
nivel mic de informatizare se urmăreşte, de regulă, doar automatizarea procedurilor manuale
existente, acum trebuie sesizate noi moduri de lucru, trebuie regândit complet modul de
realizare a acelei funcţii, cu scopul îmbunătăţirii radicale a performanţelor. Acest cadru mai
este întâlnit sub numele de reproiectarea proceselor economice (Business Process
Reengineering – BPR).
Varianta nivelului mediu de informatizare reprezintă, de obicei, o combinaţie a
caracteristicilor celorlalte două. Prin această variantă, care este cel mai probabil să fie
selectată, analistul încearcă să facă cea mai bună alegere între ceea ce este necesar şi ceea ce
este posibil, ţinând cont de restricţiile privind bugetul şi timpul de realizare.
După definirea variantelor de proiectare, pe baza priorităţii şi nivelurilor de informatizare
pentru fiecare funcţie, se trece la evaluarea acestora. Drept criterii de evaluare vor fi utilizate,
în primul rând, restricţiile rezultate din studiile de fezabilitate a proiectului. Este evident că
extinderea funcţională a sistemului şi un nivel ridicat de informatizare vor implica costuri mari
şi timp îndelungat.
În această fază, informaţiile despre cerinţele sistemului şi dificultatea dezvoltării unor
capacităţi ale acestuia sunt mai detaliate, echipa de dezvoltare fiind în măsură să evalueze mai
exact decât în fazele anterioare costurile pentru fiecare variantă strategică de proiectare,
urmărindu-se încadrarea în bugetul aprobat. Datorită şi restricţiilor de timp, noul sistem nu va
putea satisface toate cerinţele utilizatorilor. Însă, pe măsură ce utilizatorii capătă experienţă în
lucrul cu noul sistem, acesta poate fi extins până ce se acoperă toate cerinţele şi se obţine
nivelul de informatizare dorit.
În continuare, vom prezenta un exemplu (Caseta 9.1) prin care să punem în evidenţă
modul în care pot fi identificate şi definite variantele de proiectare legate de aria şi nivelul de
informatizare. În acest sens, vom apela tot la sistemul de gestiune a clienţilor, dar propunem o
altă viziune a utilizatorilor, care să ofere o bază mai largă de discuţie privind posibilităţile de
informatizare. De asemenea, acum vom considera cazul unei firme distribuitoare de carte.
Caseta nr. 9.1 – Definirea ariei de întindere a sistemului
În urma definirii ariei de întindere, s-a considerat că sistemul realizează următoarele funcţii:
Evidenţa comenzilor. După primirea comenzii se verifică situaţia clientului şi a stocului
pentru produsele solicitate, iar în cazul avizării se calculează valoarea comenzii, se emite şi
transmite o înştiinţare către client şi se înregistrează comanda.
Prelucrare stocuri. Pe baza solicitării clientului se confirmă existenţa stocului necesar, se
emite avizul de expediţie, un exemplar fiind transmis la depozit, şi se actualizează stocul.
Onorare comenzi. Avizul de expediţie stă la baza întocmirii facturii, după care are loc
înregistrarea şi transmiterea ei către client. Datele privind facturile sunt prelucrate zilnic în
vederea întocmirii notei contabile, ce va fi transmisă, împreună cu documentele justificative,
SELECTAREA VARIANTEI STRATEGICE DE PROIECTARE A SISTEMELOR 205
Instiintare-
client Limita-de-credit-
Client Date-clienti Factura
si-sold-client
Clienti 5
Date-
Analiza vanzari
1 Client-nou vanzari
Comanda- Comenzi-
client clienti
Evidenta
comenzi Date-comanda-noua
Date- Conducere
analiza-vanzari
Comanda
Date-
Solicitare- preturi
stoc
Clienti-
Stoc Comanda- in-
neonorata Clienti 4 litigiu
Stoc-
actualizat Evidenta
Stoc-
existent Date- analitica
3 clienti Sold- clienti
nou
Prelucrare 2
stocuri Date-
Aviz-de-expeditie Onorare factura- Date-
Aviz- comenzi noua vanzari
de- Clienti-
expeditie de-
Factura incasat
Factura
Depozit Nota-
Client contabila
Sistem
contabilitate
Instiintare-
Client client Limita-de-credit-
si-sold-client Date-clienti Factura
Clienti 5
Date-
Analiza vanzari
1 vanzari
Comanda- Client -nou
client Comenzi-
Evidenta clienti
comenzi Date-comanda-noua
Date-
Conducere
Comanda analiza-vanzari
Date-
Solicitare- preturi
stoc
Clienti-
Stoc Comanda- in-
neonorata Clienti 4 litigiu
Stoc-
Solicitare- actualizat
stoc Stoc- Evidenta
existent Date- analitica
3 clienti Sold- clienti
nou
2
Prelucrare Aviz-de-expeditie
stocuri Date-
Onorare factura- Date-
comenzi noua vanzari
Aviz- Clienti-
de- Factura de-
expeditie incasat
Factura
Aviz-de-expeditie Factura
Depozit
Client
Sistem
contabilitate
Atunci când se pune în discuţie definirea ariei de informatizare, se poate lucra la un nivel
de descompunere mai fin. Altfel spus, această discuţie nu se limitează la stabilirea proceselor
din diagrama de „nivel 0” care să fie sau nu informatizate, ci trebuie luate în considerare şi
subprocesele fiecărei funcţii din diagrama de „nivel 0”. Prin urmare, vor fi luate în considerare
şi diagramele de pe nivelurile inferioare.
În general, pentru fiecare funcţie pot fi definite cel puţin trei niveluri de informatizare:
inferior, mediu şi l superior. În tabelul 9.1 sunt prezentate atât aria de cuprindere, prin
încadrarea funcţiilor sistemului în una din cele trei categorii de prorităţi, cât şi nivelul de
informatizare pentru fiecare funcţie în parte, prin prezentarea variantelor de informatizare.
Stabilirea priorităţii se efectuează în funcţie de cerinţele utilizatorilor şi obiectivele sistemului.
De exemplu, dacă unul din obiectivele sistemului vizează îmbunătăţirea relaţiilor cu clienţii,
atunci funcţiile care permit firmei să răspundă mai rapid şi mai bine la cerinţele clienţilor vor fi
obligatorii şi se va lua în considerare un nivel de informatizare cât mai bun.
SELECTAREA VARIANTEI STRATEGICE DE PROIECTARE A SISTEMELOR 207
Fiecare celulă din ultimele trei coloane trebuie detaliată într-o documentaţie separată.
După cum se poate sesiza cu uşurinţă, informatizarea anumitor funcţii depinde de nivelul
de informatizare a altor funcţii. De exemplu, transmiterea de materiale promoţionale
personalizate nu ar fi posibilă fără definirea profilului clienţilor pe baza analizei istoricului
vânzărilor. De aceea, diagramele fluxurilor de date trebuie urmărite cu multă atenţie, altfel se
208 ANALIZA SISTEMELOR INFORMAŢIONALE
Soluţii Soluţii
ERP la cheie
Dezvoltare
Software la comandă
Fiecare din cele două axe conţine un spectru de valori, nu doar valorile extreme
evidenţiate în figura 9.3. Se poate opta pentru achiziţionarea întregului sistem sau pentru
dezvoltarea în totalitate a acestuia, însă, între aceste două extreme, pot fi identificate şi alte
soluţii, în care o parte a sistemului să fie cumpărată, iar cealaltă parte să fie dezvoltată. De
exemplu, se poate opta pentru achiziţionarea unei soluţii de pe piaţă, dar care să necesite
modificarea unor componente sau adăugarea altora în vederea adaptării la anumite cerinţe
specifice firmei sau pentru crearea interfeţelor cu sistemele existente în firmă.
În mod similar, există mai multe opţiuni în ce priveşte cealaltă dimensiune, situate între
cele două extreme: dezvoltarea integrală a sistemului în cadrul firmei şi dezvoltarea sa
integrală în afara firmei.
9.3.2.1 Externalizarea serviciilor informaţionale
Externalizarea a devenit una din metodele cele mai eficiente de reducere a costurilor şi de
îmbunătăţire a performanţelor unui grup de activităţi din cadrul firmei. Externalizarea
sistemelor informaţionale (sau a serviciilor informaţionale) presupune transferul către un
furnizor a managementului sistemului, respectiv a dezvoltării şi exploatării lui. Externalizarea
sistemelor informaţionale cuprinde o paletă mai largă de posibilităţi, de la externalizarea în
totalitate a sistemelor informaţionale şi până la externalizarea dezvoltării parţiale a noului
sistem.
La o extremă se află situaţia contractării unui agent pentru dezvoltarea şi exploatarea
aplicaţiilor pe calculatoarele acestuia, firma preocupându-se numai de furnizarea datelor de
intrare şi preluarea ieşirilor sistemului. În acest caz, agentul contractat se va ocupa de toate
serviciile informaţionale, inclusiv prelucrarea datelor, calculatoarele, programele, reţeaua şi
personalul aparţinând acestuia. În fapt, agentul va reprezenta departamentul informatic al
firmei pentru care prestează serviciile. O variantă apropiată presupune angajarea unei companii
care să furnizeze aplicaţiile necesare şi să le execute în cadrul firmei contractante pe
calculatoarele acesteia.
Se poate opta pentru externalizarea doar a activităţilor de dezvoltare a sistemelor
informaţionale, cu scopul dezvoltării complete sau parţiale a sistemului, cumpărării de pachete-
program şi, eventual, adaptarea acestora la cerinţele specifice ale clientului, sau obţinerea de
asistenţă pe parcursul tuturor fazelor de dezvoltare a sistemului. Un exemplu tradiţional constă
în contractarea unui agent pentru testarea aplicaţiilor la nivel de sistem.
După cum rezultă din figura 9.3, în acest paragraf, prin externalizare facem referire la
întregul sistem, inclusiv punerea în funcţiune şi exploatarea sa de zi cu zi. Situaţia contractării
unei firme doar pentru dezvoltarea noului sistem sau a unei părţi din acesta nu se încadrează
aici. Ea este evidenţiată în acea parte a formei „Soluţia dezvoltării” care corespunde opţiunii
„În afara firmei”.
Externalizarea sistemelor informaţionale reprezintă, în general, o decizie strategică, pe
termen lung (de regulă 8-10 ani), şi nu se aplică doar asupra unui proiect de dezvoltare, ci la
nivelul întregii organizaţiei. De aceea, ea nu reprezintă propriu-zis o variantă de implementare,
decizia fiind luată la nivelul conducerii superioare.
Externalizarea serviciilor informaţionale este posibilă prin apelarea la Application Service
Providers (ASP). Un ASP este o companie care dezvoltă şi furnizează servicii folosite în
comun de mai mulţi utilizatori, care plătesc un abonament sau taxe de folosire, serviciile fiind
furnizate dintr-o locaţie centrală prin Internet sau printr-o reţea privată. ASP presupune acces
partajat, sub control, la anumite servicii.
9.3.2.2 Surse ale softului
Dacă soluţia externalizării serviciilor informaţionale ar putea părea una prea radicală,
firmele au la dispoziţie şi alte variante de implementare a sistemului. Ne referim la diferitele
surse ale softului.
210 ANALIZA SISTEMELOR INFORMAŢIONALE
În general, programele informatice pot fi obţinute pe două căi principale: achiziţia unui
pachet de aplicaţii de pe piaţă de la diferiţi furnizori, numit şi soft la cheie, sau dezvoltarea
acestuia prin parcurgerea tuturor fazelor specifice ciclului de viaţă al sistemelor
informaţionale, soluţie numită şi soft la comandă. Acestea două nu reprezintă decât valorile
extreme ale unui spectru, între ele putând fi identificate alte soluţii.
Softul necesar sistemului poate fi obţinut pe următoarele căi:
cu forţe proprii;
la comandă;
la cheie;
la cheie modificat.
Softul realizat cu forţe proprii
Din faza incipientă a utilizării calculatoarelor, aproape toate organizaţiile şi-au proiectat şi
au scris propriile lor aplicaţii. În multe cazuri, operaţiunea este impusă, unitatea neavând de
ales altă modalitate. De cele mai multe ori, nu existau decât câteva tipuri de programe
disponibile pe piaţă, care nu satisfăceau întotdeauna necesităţile organizaţiilor. Deşi acum la
dispoziţia utilizatorului se află o largă varietate de soft la cheie, mai există încă unităţi care
consideră că problemele lor specifice nu se pot rezolva achiziţionând un soft de pe piaţă. Alte
organizaţii sunt atât de mari şi de complexe încât singura modalitate de a-şi satisface cerinţele
o constituie elaborarea propriului soft de aplicaţii.
Soft realizat la comandă
O altă variantă de procurare a softului poate fi angajarea din afara unităţii a
programatorilor/analiştilor sau a unei companii de software pentru a elabora pentru client un
pachet-program de aplicaţii. O astfel de modalitate poate să utilizeze şi componente din
programele existente deja la client, bineînţeles, prin adaptarea, completarea şi combinarea lor,
astfel încât să răspundă noilor cerinţe.
Elaborarea programelor de către clienţi este, deseori, un proces dificil şi poate să se
concretizeze în risipă de timp şi de resurse. O problemă deosebită apare între utilizatorii finali,
care îşi definesc propriile cerinţe, şi analist, care trebuie să le interpreteze şi să le adapteze în
structuri de programe, fişiere de date, intrări şi ieşiri. Analistul trebuie să lucreze cu utilizatorii
pentru a determina cu exactitate toate formatele de rapoarte şi ecrane. Împreună vor identifica
intrările sistemului, datele necesare fiecărei intrări, precum şi datele din structura fişierelor.
Analistul trebuie, de asemenea, să elaboreze descrieri detaliate ale tuturor prelucrărilor interne,
logic necesare obţinerii formei dorite a ieşirilor. Aceste specificaţii de program trebuie să fie
apoi interpretate şi codificate prin programe.
Datorită numeroaselor şi variatelor obiective de realizat, întregul proces presupune o
disciplină deosebită şi un control permanent. Unităţile trebuie să-şi exercite controlul cu mare
atenţie, mai ales atunci când se lucrează cu personal din exteriorul ei. Realizatorul softului
trebuie să înţeleagă în profunzime modul cum lucrează unitatea.
Pentru activitatea prestată se va încheia un contract care va consemna responsabilitatea
contractantului de a rezolva cerinţele utilizatorului şi care să-i permită unităţii să-l interpună
atunci când, în anumite condiţii, n-au fost onorate clauzele contractuale. Toate aspectele
proiectului privind softul trebuie să fie prezentate în detaliu şi astfel să se poată verifica pe
parcurs întregul proiect. Relaţia dintre colaborator şi unitate trebuie să fie definită cu
rigurozitate şi de aceea trebuie să existe o legătură permanentă între părţi. Costurile trebuie să
fie îndeaproape controlate, iar cheltuielile băneşti minimizate, până când proiectul a fost
completat şi acceptat.
Softul la cheie
Softul la cheie, realizat de către producătorii de calculatoare sau de către companii
specializate în realizarea de software, este vândut pe piaţă pentru o mare diversitate de
utilizatori cu cerinţe similare. Unii producători de software combină softul cu hardul şi le vând
SELECTAREA VARIANTEI STRATEGICE DE PROIECTARE A SISTEMELOR 211
ca pachete. Această combinaţie este numită sistem la cheie, deoarece furnizorul instalează
întregul sistem, iar utilizatorul trebuie doar să „răsucească” cheia pentru a beneficia de
funcţiile acestuia.
De remarcat faptul că, la nivelul anilor 1990, în topul primelor 10 firme, cu veniturile cele
mai mari din software, cinci sunt firme producătoare şi de echipamente: IBM – locul I (înaintea
firmei Microsoft), Computer Associates – locul III, Digital – locul VI, Unisys – locul VIII,
Hewlett Packard – locul X.
Producerea softului la comandă presupune o muncă anevoioasă şi de aceea scumpă. Ca
urmare, tot mai multă lume se îndreaptă spre pachetele la cheie, mai puţin costisitoare. Deja s-a
ajuns la concluzia că nu este cazul „să se reinventeze roata”, scriind programe care deja se
comercializează pe piaţă. De fapt, estimările arată că peste 70% din costul instalării
calculatoarelor de astăzi provin fie din utilizarea, fie din procurarea pachetelor-program la
cheie. Odată cu trecerea timpului, apar pachete-program tot mai performante, răspunzând
cerinţelor unităţilor, ca şi când ele ar fi elaborate cu propriile forţe sau atingând cele mai
diverse pretenţii ale organizaţiilor mari şi complexe.
Modificarea softului la cheie
Numeroase persoane consideră că este mai bună calea de a satisface cerinţele utilizatorilor
prin procurarea sistemului la cheie şi modificarea lui conform unor cerinţe anume.
Modificările pot fi făcute de către cel care a livrat softul, de către personalul unităţii
cumpărătoare sau de către o altă companie furnizoare de software sau de către un alt utilizator
al pachetului. În această categorie sunt incluse soluţiile ERP (Entreprise Resource Planning).
Din relatările anterioare se pune întrebarea: Care metodă este mai bună? Datorită
situaţiilor şi condiţiilor diferite, nu există o cale anume, catalogată ca fiind cea mai bună.
Fiecare situaţie trebuie luată în calcul separat. De regulă, softul la cheie tinde să fie cea mai
bună soluţie, când răspunde exigenţelor unităţii sau când el poate fi uşor modificat, ceea ce
corespunde sistemelor mici şi cazului în care cerinţele nu sunt complexe. Odată cu creşterea
mărimii şi complexităţii sistemului sau a cerinţelor lui, există slabe speranţe ca soluţia softului
cumpărat să fie cea mai bună. Mulţi specialişti consideră că, dacă softul nu poate fi realizat cu
forţe proprii, varianta apelării la persoane din afară pentru a-l scrie este mai scumpă decât
softul la cheie. Soluţia trebuie să vină, totuşi, de la fiecare unitate, după ce-şi evaluează
propriile cerinţe, prin analiză, şi după ce cunoaşte softul existent pe piaţă.
Soft realizat cu forţe proprii
Avantaje Dezavantaje
1. Programele pot fi concepute astfel încât să 1. Este foarte scump, munca de elaborare este foarte
răspundă cu exactitate cerinţelor unităţii. mare, chiar şi cele mai simple aplicaţii pot costa
2. Unitatea poate funcţiona conform căii dorite şi nu mii de dolari.
cum este prezentată prin pachetele la cheie. 2. De regulă, durează mult, însemnând luni sau ani de
3. Pachetele proprii sunt mult mai compatibile cu alt zile.
software din organizaţie, deci integrarea poate fi 3. Posibilitatea de a eşua, la primele încercări de
uşor realizată. utilizare, este mai mare.
4. Demarajul şi iniţierea în tehnica de utilizare a 4. Solicită costuri deosebite, timp şi control exigent.
pachetelor sunt mult mai uşor realizabile. Trebuie să se apeleze la o programare standard,
5. Moralul angajaţilor în prelucrarea automată a precum şi la elaborarea şi documentarea pachetelor
datelor este mai ridicat, loialitatea lor faţă de conform standardelor existente, ceea ce înseamnă o
propriul sistem este mult sporită. mare concentrare de forţe umane.
5. Procesul de elaborare solicită prea mult utilizatorii
şi conducerea, deoarece aceştia trebuie să analizeze
cerinţele, să sprijine proiectarea, să revizuiască, să
testeze sistemul, să identifice defecţiunile ş.a.
6. Soluţia cu specialişti din afară este foarte riscantă.
Soft la cheie
Avantaje Dezavantaje
1. Costul este mult mai redus faţă de celelalte 1. Cerinţele firmei nu pot să se regăsească perfect în
variante, deoarece costul elaborării şi întreţinerii ceea ce oferă pachetul-program, fiind necesare
se împarte la numeroşi utilizatori. schimbări în modul de lucru, modificări ale unor
2. Practic nu există timp de aşteptare până la forme folosite anterior, chiar revizuirea stilului de
212 ANALIZA SISTEMELOR INFORMAŢIONALE
O listă detaliată de criterii pentru evaluarea sistemului poate conţine următoarele aspecte:
Pachetul selectat răspunde specificaţiilor obligatorii din cerere? Cât de bine?
2. Satzinger, J.W., Jackson, R.B., Burd, S.D. – Systems Analysis and Design in a Changing World, Course
Technology, Thomson Learning, Boston, 2002, p. 317.
216 ANALIZA SISTEMELOR INFORMAŢIONALE
Tabel nr. 9.3 – Evaluarea variantelor de implementare pentru sistemul de gestiune a clienţilor
Importanţa Varianta 1 Varianta 2 Varianta 3
Criterii de evaluare specifică (soft la comandă (soft la cheie) (soft la comandă
– în firmă) – specialişti din
afara firmei)
Criterii generale
Existenţa personalului 4 3 12 4 16 5 20
specializat
Costul dezvoltării 5 4 20 2 10 5 25
Valoarea aşteptată a 5 5 25 3 15 4 20
beneficiilor
Timpul de dezvoltare 4 3 12 5 20 2 8
Garanţii şi service 3 5 15 3 9 3 9
Total criterii generale 84 70 82
Criterii funcţionale
Înregistrarea comenzii 5 5 25 3 15 5 25
Crearea materialelor 4 5 20 0 0 5 20
promoţionale
Determinarea profilului 3 5 15 0 0 5 15
clienţilor
Urmărire clienţi în litigiu 3 5 15 5 15 5 15
Analiză vânzări 3 5 15 0 0 5 15
Controlul stocurilor 5 5 25 5 25 5 25
Generarea notei contabile 4 5 20 5 20 5 20
Avizare comenzi 4 5 20 0 0 5 20
Total criterii funcţionale 155 75 155
Cerinţe tehnice
Robusteţea 5 3 15 5 25 3 15
Erori de programare 4 3 12 4 16 3 12
Calitatea codului 4 4 16 5 20 4 16
Documentaţia 3 3 9 5 15 3 9
Uşurinţa instalării 2 5 10 4 8 4 8
Calitatea interfeţei 4 5 20 4 16 5 20
Total criterii tehnice 82 100 80
Total general 321 245 317
Din tabelul 9.3, rezultă că varianta cea mai bună o constituie dezvoltarea sistemului cu
specialiştii proprii. Varianta achiziţionării softului la cheie este cea mai slabă, datorită faptului
că multe din cerinţele funcţionale ale sistemului nu sunt satisfăcute de programele existente pe
piaţă. Pentru varianta a doua a fost luat în considerare cel mai bun program de pe piaţă. O altă
variantă, care putea fi luată în calcul, o reprezintă modificarea programului achiziţionat de pe
piaţă.
2. Descrierea sistemului
A. Variantele. O sumară descriere a variantelor de configuraţie a sistemului.
B. Descrierea sistemului. Descrierea configuraţiei selectate şi prezentarea detaliată a datelor de
intrare, a activităţilor executate, a informaţiilor care au rezultat.
3. Studiile de fezabilitate
A. Analize economice. Se oferă o justificare economică a sistemului, prin analizele cost-
beneficiu.
B. Analize tehnice. Se prezintă aspectele edificatoare ale factorilor de risc tehnic şi o ierarhizare
a factorilor de risc la nivel de proiect.
C. Analiza operaţională. Se oferă o analiză a modului în care vor fi rezolvate problemele
unităţii, fie interne, fie în relaţie cu competitorii, efectuându-se o evaluare a activităţilor zilnice în
noile condiţii.
D. Analiza legalităţii şi a contractelor. Sunt prezentate aspecte ale cadrului legal sau ale
riscurilor contractelor referitoare la proiect.
E. Analiza politicilor. Sunt oferite descrieri ale celor interesaţi de soarta proiectului şi ale
percepţiilor acestora faţă de ceea ce se propune.
F. Analiza desfăşurării calendaristice. Sunt puse la dispoziţie diferite variante ale planificării
calendaristice în strânsă concordanţă cu modul de alocare a resurselor.
4. Probleme ale managementului
A. Configuraţia şi managementul echipei. Sunt arătate rolurile membrilor echipei şi relaţiile
dintre ei în ceea ce priveşte raportarea.
B. Planul comunicării. Sunt oferite detalii despre procedurile de comunicare ce trebuie să fie
urmate de echipa managerială, de membrii echipei, precum şi de către beneficiari.
C. Standardele şi procedurile proiectului. Se descrie modul în care vor fi evaluate şi acceptate
rezultatele proiectului de către beneficiari.
D. Alte aspecte specifice proiectului. Sunt abordate orice alte probleme referitoare la proiect
care nu au fost descrise în punctele anterioare.
Rezumat
Până acum, în faza de analiză, ne-am ocupat de determinarea şi structurarea cerinţelor sistemului.
Altfel spus, s-a urmărit descrierea a „ceea ce este” şi a „ceea ce ar trebui să fie” sistemul informaţional.
Acum, ne aflăm înaintea fazei de proiectare, în care trebuie găsit răspunsul la întrebarea „cum” se va
parcurge drumul de la „ceea ce este” la „ceea ce ar trebui să fie” sistemul. În acest sens, o ultimă
activitate a fazei de analiză priveşte definirea strategiei de proiectare.
Strategia de proiectare specifică direcţia care va fi urmată, în continuare, în dezvoltarea noului
sistem. Definirea ei presupune parcurgerea a două activităţi principale: generarea variantelor strategiei
de proiectare şi selecţia celei mai bune strategii. Decizia finală, privind varianta de proiectare care va fi
urmată, aparţine utilizatorilor şi finanţatorului, acest aspect constituind motivul principal pentru care
trebuie ca echipa de realizare să formuleze mai multe variante de sistem. Cei mai mulţi specialişti
recomandă definirea a trei variante de proiectare.
Generarea variantelor strategice ale proiectului presupune considerarea unor probleme legate de
sistem, precum: aria de întindere şi nivelul de informatizare, sursele softului, selecţia furnizorilor.
Oricare ar fi ele, variantele proiectului trebuie să respecte două categorii esenţiale de condiţii, prezentate
sub forma funcţiilor obligatorii ale noului sistem şi a restricţiilor impuse.
Din punctul de vedere al soluţiilor de implementare, variantele posibile se regăsesc în cadranul
rezultat prin combinarea a două dimensiuni corespunzătoare opţiunilor achiziţionare/dezvoltare şi în
cadrul firmei/în afara firmei.
După formularea clară a variantelor de proiectare, se trece la evaluarea lor în vederea selectării celei
mai bune. Analiştii vor trebui să găsească criteriile de evaluare cele mai potrivite. În general, aceste
criterii pot fi grupate în trei categorii: cerinţe generale, funcţionale şi tehnice.
Pentru evaluare, poate fi aplicată metoda cotelor de nivel, modelele matematice de simulare,
metoda punctajelor sau cea bazată pe aşa-zisele costuri necesare.
Rezultatele activităţii de definire a strategiei de proiectare se concretizează în ceea ce, în practică,
poartă numele de planul de bază al proiectului. El conţine descrierea variantelor de sistem, recomandări,
studiile de fezabilitate efectuate şi alte probleme legate de managementul proiectului
SELECTAREA VARIANTEI STRATEGICE DE PROIECTARE A SISTEMELOR 219
Întrebări recapitulative
1. Definiţi strategia de proiectare a sistemelor informaţionale.
2. Explicaţi necesitatea subfazei de definire a strategiei de proiectare.
3. Prezentaţi elementele componente al raportului detaliat ale cerinţelor sistemului.
4. De ce este recomandată formularea a trei variante de proiectare?
5. Descrieţi succint activităţile subfazei de definire a strategiei de proiectare.
6. Faceţi o scurtă prezentare a problemelor în legătură cu care se pot genera variante de proiectare.
7. Explicaţi rolul diagramelor fluxurilor de date în definirea strategiei de proiectare.
8. Care sunt opţiunile posibile de externalizare a serviciilor informaţionale?
9. Realizaţi o comparaţie între sursele de obţinere a softului.
10. Enumeraţi 7 criterii utilizate la evaluarea furnizorilor şi realizaţi o ierarhie a lor, din punctul de
vedere al importanţei.
11. Cum pot fi grupate criteriile de evaluare a variantelor de implementare? Daţi exemple din fiecare
categorie.
12. Care sunt metodele de evaluare a variantelor strategiei de proiectare?
13. Prezentaţi conţinutul planului de bază al proiectului.
Probleme de echipă
1. Definiţi trei variante de proiectare în legătură cu aria şi nivelul de informatizare pentru sistemul
analizat în propriul studiu de caz. Se va utiliza modelul prezentat în paragraful 9.3.1.
2. Formulaţi o cerere de ofertă pentru achiziţia de echipamente şi programe necesare sistemului
analizat în propriul studiu de caz.
3. Formulaţi trei variante de implementare pentru sistemul analizat în propriul studiu de caz, luând în
considerare sursele softului.
4. Evaluaţi cele trei variante prezentate la punctul anterior, utilizând metoda punctajelor. Se va utiliza
modelul prezentat în tabelul 9.3. Specificaţi varianta cea mai bună şi argumentaţi rezultatul obţinut.
Bibliografie generală
1. Adamec, F. – Project Management, apud Project and Grant Management, ETP Slovakia
Foundation, Budapest, Hungary, July 19, 1997.
2. Airinei, D. – Depozite de date, Ed. Polirom, Iaşi, 2002.
3. Ambler, S.W. – „In Search of a Generic SDLC for Object Systems”, in Object Magazine, 1994,
4(6).
4. Belanger, T.C. – Successful Project Management, American Management Association, USA, 1995.
5. Bîrjovanu, R.A. – „Cybermarket, cyberplăţi, bani digitali, frauda şi spălarea electronică a benilor în
Cyberspace”, în Computerworld, nr. 16 (86), 1997.
6. Boehm, B.W. – „A Spiral Model of Software Development and Enhancement”, in IEEE Computer,
1988, 21(5).
7. Bourne, K.C. – „Putting Rigour Back in RAD”, in Database Programming & Design, 7(8) (August
1994).
8. Bouzeghoub, M., Gardarin, G., Valduriez, P. – Object Technology – Concepts and Methods,
International Thomson Computer Press, Boston, 1997.
9. Brady, J.A., Monk, E.F., Wagner, B.J. – Concepts in Enterprise Resource Planning, Course
Technology, Thomson Learning, Boston, 2001.
10. Brown, D. – An Introduction to Object-Oriented Analysis: Objects in Plain English, John Wiley &
Sons, Inc., New York, 1997.
11. Carey, J. – Quality Management and Performance Measurement in Information Services, Carey
Project Organization, Ardmore, 1991.
12. Carmichael, A.R. – Object Development Methods, Andy Carmichael (ed.), SIGS Books, New York,
1994.
13. Celko, J. – „Data Flow Diagrams”, in Computer Language, 4, January 1987.
14. Chaffey, D. – E-Business and E-Commerce Management, Prentice Hall, Harlow, 2002.
15. Christel, M., Kang, K.C. – Issues in Requirements Elicitation, Technical Report, CMU/SEI-92-TR-
012, ESC-TR--92-012, 1992.
16. Churchill, Jr., G.A. – Basic Marketing Research, The Dryden Press, Chicago, 1988.
17. Coad, P., Yourdon, E. – Object-Oriented Analysis, Second Edition, Yourdon Press, Prentice Hall
Building, Englewood Cliffs, New Jersey, 1991.
18. Colectiv FIMAN, Centrul de consiliere în cariera profesională – Manual de înfiinţare şi operare,
Ed. Expert, Bucureşti, 1997.
19. Conger, S. – The New Software Engineering, Wadsworth Publishing Company, Belmont, 1994.
20. Curtis, G., Cobham, D. - Business Information Systems. Analysis, Design and Practice, Prentice
Hall, Upper Saddle River, New Jersey, 2002.
21. Cushing. B.E., Romney, M.B. – Accounting Information Systems, 6th Edition, Addison-Wesley
Publishing Company, Reading, Menlo Park, 1994.
22. Dawson, M.L. – The Accountability of an Enterprise Resource Planning System, May 7, 2002,
http://erp.ittoolbox.com (accesat pe 4 august 2004).
23. DeMarco, T. – Structured Analysis and Design Specification, Prentice Hall, Englewood Cliffs, New
Jersey, 1979.
24. Digital – A Guide to USE Digital Program Methodology, 1996.
25. Donaldson, S.E., Siegel, S.G. – Successful Software Development, Prentice Hall, Upper Saddle
River, New Jersey, 2001
26. Drăghici, M. – Noile tehnologii de vârf şi societatea, Ed. Politică, Bucureşti, 1980.
27. Farcaş, D. – Cui i-e frică de calculatorul electronic?, Ed. Albatros, Bucureşti, 1987.
28. Finkelstein, R. – „Understanding the need for on-line analytical servers”, in Ann Arbor,Comshare,
1994.
29. Finkelstein, R. – „When OLAP Does Not Relate”, in Computerworld, December 12, 1994.
30. Fotache, D., Hurbean, L. – Soluţii informatice integrate pentru gestiunea afacerilor – ERP, Ed.
Economică, Bucureşti, 2004
31. Gane, C., Sarson, T. – Structured Systems Analysis: Tools and Techniques, Prentice Hall,
Englewood Cliffs, New Jersey, 1979.
SELECTAREA VARIANTEI STRATEGICE DE PROIECTARE A SISTEMELOR 221
32. Garsombke, H.P., Trussell, L., Oprea, D. – The Accounting Profession and Education in
Romania, Midwest Accounting Society Meeting, Chicago, 1993.
33. Geller, D.P. – The Yin and Yang of Electronic Commerce, http://idm.internet.com.
34. Gibson, M.L., Hughes, C.T. – Systems Analysis and Design: A Comprehesive Methodology with
CASE, Boyd & Fraser Publishing/Company, Danvers, 1994.
35. Harel, D. – „Statecharts. A Visual Formalism for Complex Systems”, in Science of Computer
Programming, 8, 1987.
36. Hayes, E.M. – Project Management, CRISP Publication, Inc., California, 1989.
37. Henderson-Sellers, B. – Object-Oriented Metrics – Measures of Complexity, Prentice Hall PTR,
Upper Saddle River, New Jersey, 1996.
38. Henderson-Sellers, B., Edwards, J.M. – „The Fountain Model for Object-Oriented Systems
Development”, in Object Magazine, 3(2), 1993.
39. Hoffer, J.A., George, J.F., Valacich, J.S. – Modern Systems Analysis and Design, The
Benjamin/Cummings Publishing Company, Inc., Sand Hill Road, Menlo Park, 1998.
40. Hossain, L., Patrick, J.D., Rashid, M.A. – Enterprise Resource Planning. Global Opportunities &
Challenges, IDEA Group Publishing, Hershey PA, 2002.
41. Humphries, M., Hawkis, W.M., Dy, C.M. – Data Warehousing. Architecture and Implementation,
Prentince Hall PTR, New Jersey, 1999.
42. Hutt, A.T.S. – Object Analysis and Design: Foundation of Methods, John Wiley & Sons, Inc., New
York, 1994.
43. Igbaria, M, Anandarajan, M., Chen, C.C-H. – „Global Information Systems”, in Encyclopedia of
Information Systems, vol. 2, Academic Press, San Diego, 2003.
44. Ives, B., Jaravenpaa, S.L. – „Applications of Global Information Technology: Key Issues for
Management”, in MIS Quarterly, 159, 1991.
45. Jaba, E. – Statistica, Ed. Economică, Bucureşti, 1998.
46. Jacobson, I., Christerson, M., Jonsson, P., Övergoard, G. – Object-Oriented Software
Engineering: A Use Case Driven Approach, Addison-Wesley Publishing Company, Wokingham,
1992.
47. Kalakota, R., Whinston, A.B. – Frontiers of Electronic Commerce, Addison Wesley, Reading,
1996.
48. Kendall, K.E., Kendall, J.E. – Systems Analysis and Design, 5th Edition, Prentice Hall, Upper
Saddle River, New Jersey, 2002.
49. Kestenbaum, M.I., Straight, R.L. – „Paperless grants via the Internet”, in Public Administration
Review, 1996 56(1).
50. Kezsbom, D.S., Edward, K.A. – The New Dynamic Project Management, John Wiley & Sons, Inc.,
New York, 2001.
51. Koch, C. – The ABCs of ERP, Enterprise Resource Planning Research Center, March 7, 2002,
www.cio.com (accesat pe 3 august 2004).
52. Koory, J.L., Medley, D.B. – Management Information Systems: Planning and Decision Making,
South Western College Publishing, Cincinnati, 1990.
53. Kornai, J. – Antiequilibrium, Ed. Ştiinţifică, Bucureşti, 1974.
54. Kulik, P., Samuelsen, R. – „e-Project Management for the New Reality”, in PM Network, March
2001.
55. Laudon, K., Laudon, J.P. – Essentials of Management Information Systems: Organization &
Technology in the Networked Entreprise, 4th Edition, Prentice Hall, Upper Saddle River, New
Jersey, 2001.
56. Lewis, J.P. – The Project Manager’s Desk Reference, McGraw-Hill, New York, 2000.
57. Lientz, B.P., Rea, K.P. – Guide to Successful Project Management, Harcourt Brace Professional
Publishing, San Diego, 1999.
58. Luftman, J.N., Papp, R., Brier, T. – „Enablers and Inhibitors of Business-IT Alignment”, in
Communication of the Association for Information Systems, Volume 1, Article 11, 1999.
59. Malhotra, N.K. – Marketing Research – An Applied Orientation, Prentice Hall, Upper Saddle
River, New Jersey, 1996.
60. Marakas, G. M. - Systems Analysis and Design: An Active Approach, Prentice-Hall, New Jersey,
2001.
222 ANALIZA SISTEMELOR INFORMAŢIONALE
95. Royce, W.W. – „Managing the Development of Large Software Systems”, in Proceedings of IEEE,
WESTCON, San Francisco, 1970. Reprinted in Proceedings of the 9th International Conference on
Software Engineering, Monterey, 1987.
96. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorenson, W. – Object-Oriented Modelling
and Design, Prentice Hall International, Inc., New York, 1991.
97. Satzinger, J.W., Jackson, R.B., Burd, S.D. - Systems Analysis and Design in a Changing World,
Course Technology, Thomson Learning, Boston, 2002.
98. Schaaf, J.M. – „Building A Partnership Mosaic”, in The Forrester Report, January 2001,
www.channelwave.com/news_and_events/documents.
99. Shlaer, S., Mellor, S.J. – Object Lifecycles: Modeling the World in States, Prentice Hall,
Englewood Cliffs, New Jersey, 1992.
100. Skidmore, S. – Introduction Systems Analysis, Second Edition, Macmillan, London, 1997.
101. Skidmore, S. – Introduction Systems Design, Ncc Blackwell, Oxford, 1996.
102. Sommerville, I. – Software Engineering, 1st Edition, Addison-Wesley, Reading, 1989.
103. Songini, M.L. – „Global Supply Chains Rife with Challenges”, in Computerworld, March 12, 2001,
accesat la www.computerworld.com.
104. Sowa, J.F., Zachman, J.A. – „Extending and Formalizing the Framework for Information Systems
Architecture”, in IBM Systems Journal, 31(3), 1992.
105. Sperley, E. – The Enterprise Data Warehouse. Planning, Building and Implementation, Hewlett-
Packard Professional Books, Prentince Hall PTR, Upper Saddle River, New Jersey, 1999.
106. Stair, R.M., Reynolds, G.W. – Principles of Information Systems, 6th Edition, Course Technology,
Thomson Learning, Boston, 2003.
107. Stancovici, V. – „Filosofia informaţiei”, în Inteligenţa artificială şi robotică, Ed. Academiei R.S.R.,
Bucureşti, 1983.
108. Standish Group – CHAOS Report (1994), 1999, www.standishgroup.com.
109. Stewart, J.C., Cash, Jr., W.B. – Interviewing, Principles and Practices, Wm. C. Brown Publishers,
Dubuque, 1991.
110. Subramanian, G.H., Nosek, J., Raghuanthan, S.P., Kanitkar, S.S. – „A Comparison of Decision
Table and Tree”, in Communications of the ACM, 35, January 1992.
111. Sudman, S., Blair, E. – Marketing Research. A Problem-Solving Approach, Irwin/McGraw-Hill,
Boston, 1998.
112. Sully, P. – Modelling the World with Objects, Prentice Hall, New York, 1993.
113. Tardieu, H., Rochfeld, A., Colleti, R. – La Méthode Merise: Principes et Outils, 2e Édition,
Éditions & Organisation, Paris, 1991.
114. Turban, E., McLean, E., Wetherbe, J. – Information Technology for Management. Making
Connections for Strategic Advantage, John Wiley & Sons, Inc., New York, 2001.
115. Vanthienen, J. – „Technical Correspondence”, in Communications of the ACM, 37, February 1994.
116. Vessey, I., Weber, R. – „Structured Tools and Conditional Logic”, in Communication of the ACM,
29, January 1986.
117. Weisman, J. – „The Making of E-Commerce: 10 Key Moments”, in E-Commerce Times, August
2000, www.ecommercetimes.com/perl/printer/4085.
118. Whitmire, S.A. – Object Oriented Design Measurement, John Wiley & Sons, Inc., New York, 1997.
119. Wood, J., Silver, D. – Joint Application Design, John Wiley & Sons, New York, 1989.
120. Wysocki, R.K., DeMichiell, R.L. – Managing Information Across the Enterprise., John Wiley &
Sons, Inc., New York, 1997.
121. Yourdon, E., Argila, C. – Case Studies in Object Oriented Analysis & Design, Yourdon Press,
Prentice Hall Building, Upper Saddle River, New Jersey, 1996.
122. Yourdon, E., Constantine, L.L. – Structured Design, Prentice Hall, Englewood Cliffs, New Jersey,
1979.
123. Zwass, V. – Management Information Systems, ECB-Wm, C. Brown Publishers, Dubuque, 1992.
124. Zwass, V. – „Structure and macro-level impacts of electronic commerce: from technological
infrastructure to electronic marketplaces”, in Emerging Information Technologies, ed. K. Kendall,
Sage Publications, Thousand Oaks, 1998.
125. *** – Buyer’s Guide to Electronic Commerce. Glossary of Terms, www.wentworth.com.
126. *** – Electronic Commerce. An Introduction, Student Manual, ZD University, 1999.