SIFC2 Sisteme Informationale Financiar Contabile II - Suport Curs PDF

Sisteme informaţionale financiar-contabile II

- suport de curs -

Contabilitate şi informatică de gestiune, anul 3, ID

Semestrul 2, an universitar 2018-2019

Prof. Univ. Dr. Dumitru OPREA
Prof. Univ. Dr. Florin DUMITRIU
Prof. Univ. Dr. Gabriela Meşniţă
CUPRINS

Introducere ......................................................................................................................................... 5
Unitatea de studiu 1 ........................................................................................................................... 8
Elemente generale privind formularele/formatele şi rapoartele......................................................... 8
1.1 Aspecte generale ale proiectării formularelor/formatelor şi a rapoartelor ..................... 9
1.2 Caracteristicile generale şi clasificarea ieşirilor ............................................................... 10
1.2.1 Scopul ieşirilor ................................................................................................................ 11
1.2.2 Destinatarii ieşirilor ........................................................................................................ 12
1.2.3 Frecvenţa ieşirilor ........................................................................................................... 13
1.2.4 Formatul ieşirilor............................................................................................................. 15
1.2.5 Conţinutul........................................................................................................................ 15
1.2.6 Sursa datelor.................................................................................................................... 18
1.2.7 Mediul de generare şi transmitere a ieşirilor .................................................................. 19
1.2.8 Controlul confidenţialităţii, integrităţii şi accesibilităţii ieşirilor ................................... 21
1.2.9 Caracteristicile informaţiilor şi nivelurile decizionale ................................................... 22
1.3 Răspunsuri la testele de autoevaluare ................................................................................ 22
1.4 Lucrare de verificare ........................................................................................................... 23
1.5 Bibliografie ........................................................................................................................... 23
Unitatea de studiu 2 ......................................................................................................................... 24
Proiectarea formularelor/formatelor şi a rapoartelor ....................................................................... 24
2.1 Reguli de proiectare a formularelor/formatelor şi a rapoartelor ................................... 24
2.1.1 Recomandări generale de formatare................................................................................ 25
2.1.2 Scoaterea în evidenţă a informaţiilor .............................................................................. 26
2.1.3 Reguli specifice de proiectare a rapoartelor în formă tabelară ....................................... 29
2.1.4 Reguli specifice de proiectare a graficelor...................................................................... 33
2.1.5 Reguli pentru controlul confidenţialităţii, integrităţii şi accesibilităţii ieşirilor ............. 34
2.2 Demersul proiectării ieşirilor.............................................................................................. 36
2.3 Formularea specificaţiilor de proiectare a ieşirilor .......................................................... 38
2.6 Bibliografie ........................................................................................................................... 40
Concepte generale privind interfeţelor utilizator ............................................................................. 41
3.1 Rolul interfeţelor utilizator în dezvoltarea sistemelor informaţionale ........................... 42
3.1.1 Definirea conceptului de interfaţă................................................................................... 42
3.1.2 Identificarea interfeţelor utilizator .................................................................................. 44
3.2 Metode şi echipamente folosite în dialogul om-calculator ............................................... 46
3.2.1 Metode de interacţiune om-calculator............................................................................. 47
3.2.2 Selectarea echipamentelor necesare interacţiunii cu sistemul ........................................ 55
3.5 Bibliografie ........................................................................................................................... 57
Principii de lucru în proiectarea interfeţelor utilizator .................................................................... 58
4.1 Controlul aplicaţiei de către utilizator ............................................................................... 60
4.1.1 Principiul utilizării judicioase a modurilor de lucru ....................................................... 61
4.1.2 Principiul retroacţiunii (feed-back) imediate .................................................................. 63
4.1.3 Principiul pǎstrării stilului de lucru al utilizatorilor ....................................................... 63
4.1.4 Principiul alegerii între utilizarea tastaturii şi/sau a mouse-ului .................................... 63
4.1.5 Principiul asigurării transparenţei detaliilor de proiectare a programelor şi a bazei de
date ........................................................................................................................................... 64
4.2 Reducerea volumului de informaţii pe care trebuie sǎ le memoreze utilizatorul .......... 65
3

4.2.1 Principiul degrevării utilizatorului de memorarea, pe termen scurt, a unor informaţii .. 65
4.2.2 Principiul interfeţei orientate pe recunoaştere, nu pe amintire ....................................... 66
4.2.3 Principiul prevederii formelor scurte de lucru ................................................................ 66
4.2.4 Principiul relevanţei vizuale............................................................................................ 66
4.3 Uniformitatea interfeţelor utilizator .................................................................................. 67
4.3.1 Principiul uniformitǎţii modului de prezentare a interfeţei ............................................ 68
4.3.2 Principiul uniformitǎţii în comportamentul interfeţei ..................................................... 68
4.3.3 Principiul uniformităţii interacţiunii cu interfaţa utilizator ............................................ 69
4.6 Bibliografie ........................................................................................................................... 70
Demersul proiectării interfeţelor utilizator. Controlul datelor în interfeţele utilizator .................... 71
5.1 Demersul proiectării interfeţelor utilizator ....................................................................... 71
5.1.1 Culegerea şi analiza informaţiilor de la utilizatori.......................................................... 74
5.1.2 Proiectarea interfeţei utilizator........................................................................................ 76
5.1.3 Construirea interfeţei utilizator ....................................................................................... 80
5.1.4 Evaluarea şi validarea interfeţei utilizator ...................................................................... 82
5.2 Reguli de proiectare a meniurilor ...................................................................................... 83
5.3 Aspecte privind proiectarea interfeţelor web.................................................................... 84
5.4 Controlul datelor în interfeţele utilizator .......................................................................... 85
5.5 Formularea specificaţiilor de proiectare a interfeţelor .................................................... 88
5.8 Bibliografie ........................................................................................................................... 89
Concepte de bază privind modelarea logică a datelor...................................................................... 90
6.1 Locul modelării logice a datelor în ciclul de viaţă al sistemelor ...................................... 91
6.2 Concepte de bază utilizate în modelul relaţional .............................................................. 92
6.3 Demersul proiectării logice a bazelor de date ................................................................... 96
6.6 Bibliografie ........................................................................................................................... 98
Transformarea diagramelor entitate-relaţie în relaţii ale bazei de date ........................................... 99
7.1 Reprezentarea entităţilor .................................................................................................. 100
7.2 Reprezentarea legăturilor ................................................................................................. 101
7.2.1 Reprezentarea legăturilor binare 1:N şi 1:1 .................................................................. 101
7.2.2 Reprezentarea legăturile binare de tip M:N şi a celor ternare ...................................... 103
7.2.3 Reprezentarea legăturilor unare .................................................................................... 106
7.3 Răspunsuri la testele de autoevaluare .............................................................................. 110
7.4 Lucrare de verificare ......................................................................................................... 110
7.5 Bibliografie ......................................................................................................................... 110
Unitatea de studiu 8 ....................................................................................................................... 111
Proiectarea programelor şi a procedurilor...................................................................................... 111
8.1 Aspecte generale ale proiectării programelor şi procedurilor....................................... 111
8.1.1 Definirea arhitecturii programelor ................................................................................ 112
8.1.2 Structurile de control ale programelor .......................................................................... 113
8.4 Bibliografie ......................................................................................................................... 118
4 SISTEME INFORMAŢIONALE FINANCIAR-CONTABILE II
Unitatea de studiu 9 ....................................................................................................................... 119
Implementarea sistemului. Testarea sistemelor informaţionale..................................................... 119
9.1 Planificarea implementării................................................................................................ 120
9.2 Testarea sistemelor informaţionale .................................................................................. 121
9.2.1 Aspecte generale privind organizarea testării sistemelor.............................................. 121
9.2.2 Tehnici de testare .......................................................................................................... 124
9.2.3 Strategia testării sistemelor informatice........................................................................ 128
9.5 Bibliografie ......................................................................................................................... 133
Unitatea de studiu 10 ..................................................................................................................... 134
Implementarea sistemului. Documentarea şi conversia sistemului................................................ 134
10.1 Documentarea sistemului ................................................................................................ 134
10.1.1 Consideraţii generale privind documentarea sistemului ............................................. 135
10.1.2 Documentaţia utilizatorului......................................................................................... 137
10.2 Selectarea şi instruirea personalului .............................................................................. 140
10.2.1 Participanţii la instruire............................................................................................... 140
10.2.2 Organizarea activităţilor de instruire .......................................................................... 141
10.3 Conversia sistemului ........................................................................................................ 144
10.4 Răspunsuri la testele de autoevaluare ............................................................................ 145
10.5 Lucrare de verificare ....................................................................................................... 146
10.6 Bibliografie ....................................................................................................................... 146
Bibliografie ............................................................................................................................... 147
5
Introducere

Disciplina Sisteme informaţionale financiar-contabile II este o continuare a disciplinei
Sisteme informaţionale financiar-contabile I pe linia ciclului de viaţă al dezvoltării
sistemelor informaţionale financiar-contabile. Ea îşi propune să integreze cunoştinţele şi
abilităţile dobândite de către studenţi la disciplinele din domeniul financiar-contabil cu cele
din domeniul informaticii, studiate anterior, şi să le ofere cadrul de transpunere a cerinţelor
informaţionale în componente ale sistemului informaţional contabil, precum : rapoarte,
ecrane pentru introducerea datelor, schema logică a bazei de date, arhitectura sistemului,
documentaţia sistemului. Conţinutul cursului tratează doar acele faze şi activităţi ale ciclului
de viaţă în care economiştii joacă un rol important.

Obiectivele principale ale disciplinei sunt:

Inţelegerea rolului şi locului economistului contabil în proiectarea şi implementarea

sistemelor informaţionale contabile ;
Desluşirea aspectelor de calitate ale sistemelor informaţionale şi a modalităţii de obţinere a
lor ;
Descrierea principiilor de lucru, a regulilor şi a recomandărilor pentru proiectarea
unor sisteme informaţionale contabile de calitate;
Definirea demersului de proiectare a componentelor unui sistem informaţional cu
orientare pe implicarea directă a utilizatorului final;
Dobândirea aptitudinilor necesare în proiectarea componentelor percepute de
utilizatori la un sistem informaţional, respectiv rapoarte şi formulare, ecrane pentru
culegerea datelor, sistemul de meniuri şi schema logică a bazei de date;
Familiarizarea cu activităţile principale din faza de implementare a sistemelor
informaţionale;
Dobândirea aptitudinilor privind elaborarea documentaţiei sistemului;
Dobândirea aptitudinilor necesare testării sistemelor informaţionale, mai ales din
perspectiva utilizatorului final.

Pentru atingerea obiectivelor propuse, suportul de curs a fost structurat în 10 unităţi de

studiu, fiecare conţinând obiective proprii, teste de autoevaluare şi lucrări de verificare. Cele 10
unităţi de studiu sunt:

1. Elemente generale privind formularele/formatele şi rapoartele
2. Proiectarea formularelor/formatelor şi a rapoartelor
3. Concepte generale privind interfeţelor utilizator
4. Principii de lucru în proiectarea interfeţelor utilizator
5. Demersul proiectării interfeţelor utilizator. Controlul datelor în interfeţele utilizator
6. Concepte de bază privind modelarea logică a datelor
7. Transformarea diagramelor entitate-relaţie în relaţii ale bazei de date
8. Proiectarea programelor şi a procedurilor
9. Implementarea sistemului. Testarea sistemelor informaţionale
10. Implementarea sistemului. Documentarea şi conversia sistemului

Evaluarea studenţilor va avea două componente: evaluarea pe parcurs şi evaluarea la examen.
Evaluarea pe parcurs constă în elaborarea şi susţinerea unui proiect în echipă, iar nota obţinută va
avea o pondere de 40% din nota finală, şi o lucrare de verificare, care va avea o pondere de 10%
din nota finală. Evaluarea la examen, realizată în sesiune, constă într-o probă

scrisă ce va conţine subiecte tip grilă şi subiecte clasice şi va avea o pondere de 50% din nota
finală. Prin subiectele grilă se vor evalua preponderent cunoştinţele teoretice, iar prin subiectele
clasice abilităţile şi cunoştinţele practice. În calculul notei la proba scrisă subiectele grilă vor avea
o pondere de 75%, iar subiectele clasice 25%. Promovarea a examenului presupune obţinerea
notei minime 5 atât la susţinerea proiectului, cât şi la examen.

Modul de calcul al notei finale este redat în tabelul de mai jos.

Criteriul Ponderi (%) Nota criteriu Punctaj
Evaluare proiect 40% 9,00 3,60
Lucrare de verificare 10% 10,00 1,00
Examen - subiecte grilă 37,5% 8,00 3,00
Examen - subiecte clasice 12,5% 10,00 1,25
Total punctaj 100% --- 8,85
Nota finală 9,00

Lucrarea de verificare pe parcurs va fi susţinută la a 2-a întâlnire din timpul semestrului,
conform programării activităţilor tutoriale, iar proiectul va fi susţinut în cadrul ultimei întâlniri din
timpul semestrului. Studenţii care nu se vor prezenta la acea dată, sau vor fi respinşi, vor putea
susţine proiectul numai în sesiunea de restanţă.

Elaborarea proiectului
Proiectul este o continuare a celui elaborat la disciplina „Sisteme informaţionale financiar-
contabile I”. Prin acest proiect se urmăreşte realizarea unor activităţi specifice fazelor de proiectare
şi implementare a sistemelor informaţionale contabile.
Structura proiectului cuprinde următoarele părţi:

1. Proiectarea logică a sistemului informaţional
1.1 Proiectarea logică a bazei de date. Construirea schemei logice a bazei de date prin
transformarea diagramei entitate-relaţie şi înglobarea cerinţelor de calitate specifice modelului
logic al datelor. Schema logică a bazei de date va fi tiparită din ACCESS (prin captură de ecran).
1.2 Proiectarea rapoartelor. Se va utiliza modelul de formulare a specificaţiilor de proiectare
prezentat la sfârşitul unităţii de studiu 2 din suportul de curs. Vor fi proiectate câte două rapoarte
pentru fiecare membru al echipei de realizare a proiectului, din care cel puţin un raport va include
grupuri de date. De asemenea, pentru fiecare raport se vor prezenta specificaţiile de proiectare
pentru secvenţele de dialog necesare în generarea rapoartelor (conform modelului din caseta 2.7,
pag. 82).
1.3 Proiectarea ecranelor(formularelor) pentru culegerea datelor. Documentul va conţine,
pentru fiecare formular: scenariile de lucru, „poza” formularului, descrierea funcţionalităţii şi
comportamentului obiectelor din formular. Se vor proiecta minim 2 formulare pentru fiecare
membru al echipei, din care cel puţin un formular să trateze o clasă de tranzacţii din sistemul dat.
1.4 Proiectarea sistemului de meniuri al aplicaţiei. Studenţii se pot inspira din aplicaţiile
similare existente pe piaţă sau în firma în care realizează proiectul.
2. Implementarea sistemului (mediul de implementare va fi Access)
2.1 Construirea bazei de date. Se vor realiza următoarele activităţi: crearea tabelelor şi
legăturilor dintre tabele, definirea cheilor primare şi străine, declararea restricţiilor de integritate
referenţială, unicitate, nulitate şi a celor specifice domeniului temei.
2.2 Construirea formularelor.
2.3 Popularea bazei de date. Se vor adăuga minim 5 înregistrări în tabelele nomenclatoare
(produse, clienţi), 10 înregistrări în tabelele cu date despre documente (facturi, consumuri) şi 15
înregistrări în tabelele cu date despre detaliile din documente (articole facturi, articole consum).
2.4 Construirea rapoartelor (inclusiv interogările necesare obţinerii rapoartelor). Se vor
construi toate rapoartele proiectate la punctul 1.2, iar jumatate dintre ele vor fi construite în modul
Design View.
7

2.5 Construirea interogi"irilor aplicafiei. Se vor crea minim 7 interogiiri pentru fiecare membru
a!echpei, din care eel putin 2 vor include facilitii(i de agregare.
Studen(ii vor prezenta Ia sus(inere documentatia de proiectare (capitolul 1), redactatii in
WORD i listatii Ia irnprimantii, i aplica(ia ACCESS in format electronic (se poate utiliza i un alt
mediu de dezvoltare a aplicatiilor economice, precum EXCEL).

Unitatea de studiu 1

Elemente generale privind formularele /formatele
şi rapoartele

Obiective:
Explicarea conceptelor formular/format şi raport
Identificarea şi descrierea ieşirilor din sistem
Clasificarea ieşirilor din sistem
Înţelegerea importanţei controlului integrităţii ieşirilor din sistem
Competenţe dobândite:
Proiectarea de formulare/formate şi raporte de calitate pe baza înţelegerii caracteristicilor
acestora
Formularea elementelor descriptive a rapoartelor specifice sistemelor informaţionale
contabile
Încadrarea rapoartelor în funcţie de diferite criterii de clasificare
Definirea caracteristicilor informaţionale ale rapoartelor în funcţie de nivelul decizional
vizat
Timpul mediu necesar asimilării: 4 ore

Structura unităţii de studiu
1.1 Aspecte generale ale proiectării formularelor/formatelor şi a rapoartelor............................... 9
1.2 Caracteristicile generale şi clasificarea ieşirilor .................................................................... 10
1.2.1 Scopul ieşirilor ................................................................................................................ 11
1.2.2 Destinatarii ieşirilor ........................................................................................................ 12
1.2.3 Frecvenţa ieşirilor ........................................................................................................... 13
1.2.4 Formatul ieşirilor............................................................................................................. 15
1.2.5 Conţinutul........................................................................................................................ 15
1.2.6 Sursa datelor.................................................................................................................... 18
1.2.7 Mediul de generare şi transmitere a ieşirilor .................................................................. 19
1.2.8 Controlul confidenţialităţii, integrităţii şi accesibilităţii ieşirilor ................................... 21
1.2.9 Caracteristicile informaţiilor şi nivelurile decizionale ................................................... 22
1.3 Răspunsuri la testele de autoevaluare .................................................................................... 22
1.4 Lucrare de verificare .............................................................................................................. 23
1.5 Bibliografie ............................................................................................................................ 23

Aşa cum a fost finalizată etapa de analiză, rezultă că intrările şi ieşirile au fost
identificate şi prezentate în subfaza de structurare a cerinţelor. Oricum, în acel moment, nu
s-au prezentat toate detaliile privind formularele/formatele, rapoartele şi răspunsurile la
întrebări. S-a insistat mai mult asupra identificării acestora şi descrierii lor. De exemplu,
fiecare formular/format va fi asociat unui flux al datelor ce intră într-un proces al
diagramelor fluxurilor de date (DFD), iar fiecare formular/format de ieşire sau raport se
poate regăsi într-un flux al datelor generate de un proces al DFD.
Se poate concluziona că datele elementare conţinute de fluxurile de date asociate
înseamnă, în acelaşi timp, şi conţinuturile formularelor/formatelor de intrare sau ale
rapoartelor şi răspunsurilor la întrebări. De asemenea, datele formularelor/ formatelor sau
9

rapoartelor pot fi date elementare ale locurilor de stocare sau pot fi calculate pe baza
acestora şi a altor elemente generate de sistem.
În acest capitol ne vom concentra asupra proiectării intrărilor şi ieşirilor din sistem, fie
ele formulare/formate sau rapoarte, fără a ne preocupa de interacţiunile dintre utilizator şi
calculator, inerente în preluarea datelor de intrare sau în generarea ieşirilor. Această din
urmă categorie de aspecte vor fi dezbătute pe larg în capitolul următor.

1.1 Aspecte generale ale proiectării formularelor/formatelor şi a
rapoartelor

Un formular/format poate fi un document primar care conţine unele date predefinite,
cărora li se adaugă altele ce urmează a fi completate în rubrici special rezervate. Din punct
de vedere structural, un formular/format este un element tipărit/afişat, cu antet şi alte
componente pretipărite, precum şi cu spaţii (rubrici) pentru completarea cu date.
Într-un sistem de prelucrare automată a datelor, formatul este asociat imaginii afişate
pe ecran, identică formularului tipărit. Datele afişate din formate sunt cunoscute sub
numele de date constante, în timp ce elementele ce vor fi completate sunt numite date
variabile.
Majoritatea formularelor au în structură patru elemente determinante: introducerea,
instrucţiunile, partea principală (corpul) şi concluziile.
Introducerea, în general, trebuie să apară la începutul formularului şi să conţină titlul
formularului, numărul formularului şi, dacă formularul trebuie distribuit altcuiva, numele
şi adresa destinatarului.
Instrucţiunile sunt, de regulă, de două tipuri. Ele precizează fie modul de completare a
formularului, fie destinaţia lui după completare. Uneori numele elementelor de completat
sunt atât de clare încât nu mai necesită informaţii speciale pentru completare. Formularele
cu un pronunţat caracter tehnic necesită mai multe informaţii în partea principală sau pe
verso. Instrucţiunile în legătură cu ceea ce trebuie făcut cu formularul trebuie să fie foarte
clare, specificându-se pentru fiecare exemplar unde trebuie să ajungă. În proiectarea acestor
formulare trebuie să se urmărească o formă cât mai simplă de realizare.
Partea principală este cea care concură la utilizarea unor formulare cât mai simple.
Relaţiile logice dintre căsuţe trebuie să fie grupate; căsuţele şi coloanele trebuie să fie
foarte clar conturate şi, evident, locul unde trebuie completate, mai ales când datele din ele
vor fi supuse prelucrării automate.
Concluziile apar la sfârşit şi se referă la înregistrarea informaţiilor cu privire la
dispoziţiile finale şi/sau la aprobările necesare în legătură cu operaţiile consemnate,
incluzând semnăturile şi data. Dacă este un formular cu operaţiuni financiare, acesta trebuie
să conţină şi rubrici pentru totaluri.
Un raport este un document economic în care sunt incluse, de regulă, date predefinite,
ceea ce înseamnă că poate fi numit şi document pasiv, fiind folosit exclusiv pentru a fi citit
sau vizualizat.
Obiectivul prezentării detaliate a ieşirilor este şi acela de a determina formatul şi
conţinutul tuturor rapoartelor imprimate/afişate şi ale documentelor furnizate de sistem,
deşi, după cum se va observa ulterior, sistemele flexibile trebuie să ofere şi tipuri de
rapoarte cu structuri definite ulterior implementării.
Formularele/formatele şi rapoartele pot fi regăsite în sistemele informaţionale
economice atât ca intrări, cât şi ca ieşiri, deşi, de regulă, documentele apar ca intrări, iar

rapoartele ca ieşiri. Intrările în sistem sunt mai puţin sub controlul echipei de proiectare, ele
fiind primite în forma transmisă de sistemul sursă. În schimb, echipa de proiectare trebuie
să se preocupe, în mod deosebit, de proiectarea ieşirilor, fie ele formate/formulare sau
rapoarte. Sunt exceptate acele ieşiri care au format şi conţinut reglementat, cum ar fi
„Factura” sau „Jurnalul de vânzări”. Din acest motiv, pe parcursul acestui capitol,
formularele/formatele şi rapoartele vor fi referite, adesea, ca ieşiri ale sistemului.
Dacă tratarea intrărilor şi obţinerea ieşirilor necesită interacţiunea om-calculator, atunci
echipa de proiectare trebuie să se preocupe şi de proiectarea dialogurilor. Acest subiect va
fi abordat separat, în capitolul următor.

1.2 Caracteristicile generale şi clasificarea ieşirilor

Proiectarea ieşirilor constituie poate cea mai importantă activitate în dezvoltarea
sistemelor informaţionale, deoarece obţinerea lor reprezintă scopul general al oricărui
sistem informaţional. Utilizatorii vor aprecia noul sistem mai ales prin prisma calităţii
ieşirilor. Obiectivul principal al proiectării ieşirilor este de a prezenta informaţia solicitată
într-o formă inteligibilă, unde trebuie, când trebuie şi cui trebuie.
Realizarea acestui obiectiv impune acordarea unei atenţii deosebite caracteristicilor
generale ale ieşirilor din sistem, prezentate sintetic în tabelul 1.1, majoritatea lor
reprezentând în acelaşi timp criterii de clasificare. În fapt, aceste caracteristici stau la baza
formulării specificaţiilor de proiectare a ieşirilor, după cum vom vedea ulterior.

Tabel nr. 1.1 – Caracteristicile generale şi clasificarea
ieşirilor din sistemele informaţionale

Caracteristica Descriere Clasificarea ieşirilor

Scopul Descrierea motivului realizării – monitorizarea proceselor sau a activităţilor
fiecărei ieşiri. – controlul activităţilor
– luarea deciziilor
– transferul informaţiilor în afara firmei
– întocmirea altor documente sau rapoarte
Destinatarii Identificarea şi descrierea – interne
persoanelor care vor utiliza ieşirile. – externe
– hibride (documente în circuit)
Frecvenţa Specificarea momentelor la care – rapoarte programate
trebuie generate ieşirile. – rapoarte generate de excepţii
– rapoarte la cerere
– analize ad-hoc
Formatul Descrierea modalităţii de – text
organizare şi prezentare a – tabelară
informaţiilor. – grafică
– zone predefinite
Conţinutul Descrierea informaţiilor care vor fi – rapoarte detaliate
furnizate în fiecare ieşire. – rapoarte de sinteză
– rapoarte dinamice (prin combinarea celorlalte
două)
Sursa datelor Identificarea căilor de obţinere a – baze de date
datelor necesare pentru generarea – ieşirile din alte procese de prelucrare
ieşirilor. – surse externe
Mediul de Alegerea modalităţii de generare şi – tipărite
transmitere transmitere a ieşirilor. – afişate pe ecran
– transmise prin mesaje electronice
– sistemele COM
11

Caracteristica Descriere Clasificarea ieşirilor
– audio
– video
– hypertext
Controlul Definirea procedurilor şi – cu restricţii de întrebuinţare
mecanismelor necesare pentru – publice
asigurarea confidenţialităţii,
integrităţii accesibilităţii controlate
a ieşirilor.

1.2.1 Scopul ieşirilor

Definirea scopului presupune cunoaşterea exactă a motivului pentru care a fost

solicitată şi pentru care va fi utilizată ieşirea respectivă. Dacă documentele primare sunt
concepute pentru consemnarea diferitelor tranzacţii, interne sau externe, rapoartele pot avea
utilizări diverse, în cadrul sistemului sau în afara acestuia:
monitorizarea proceselor sau a activităţilor din cadrul firmei. „Situaţia vânzărilor
pe categorii de produse” poate fi utilizată în urmărirea şi evaluarea creşterii
vânzărilor în urma unei campanii de marketing.
controlul activităţilor economice desfăşurate în cadrul firmei. „Balanţa analitică a
stocurilor” poate fi utilizată pentru verificarea corectitudinii şi completitudinii
înregistrării tranzacţiilor privind stocurile, atât în contabilitate, cât şi în evidenţa
organizată la nivelul depozitelor.
luarea deciziilor pe diferite niveluri ierarhice. De exemplu, „Situaţia vânzărilor
pe zone geografice” este utilă în definirea strategiei de distribuţie.
transferul unor informaţii în afara organizaţiei. În afara raportărilor statistice,
aici pot fi incluse şi ofertele de produse sau „Situaţia facturilor neachitate”
transmise clienţilor.
prelucrarea informaţiilor conţinute în ieşiri, în vederea întocmirii unor documente
sau a altor rapoarte. Aici poate fi inclus „Centralizatorul statelor de salarii”, pe
baza căruia se întocmeşte „Ordinul de plată” pentru achitarea obligaţiilor legale
către bugetul statului, cel al asigurărilor sociale şi alte bugete. Un alt exemplu îl
reprezintă „Jurnalul vânzărilor”, utilizat împreună cu „Jurnalul cumpărărilor”
pentru întocmirea „Decontului TVA”.
În funcţie de scopul ieşirilor se vor defini unele aspecte de proiectare a lor, cum ar fi
ordinea de prezentare a coloanelor, sortarea informaţiilor, totalurile ce trebuie incluse,
suportul pe care va fi transmisă ieşirea şi frecvenţa lor.

Teste de autoevaluare
TA 1.1
1. Enumeraţi aspectele de proiectare a rapoartelor a căror formulare (definire) este
influenţată de scopul raportului.
2. Daţi trei exemple de rapoarte din domeniul contabilităţii şi precizaţi scopul fiecăruia.
Răspuns:

1.2.2 Destinatarii ieşirilor

Cunoaşterea destinatarilor serveşte la o bună proiectare a ieşirilor din sistem.

Identificarea şi descrierea destinatarilor, precum şi a sarcinilor de lucru ale acestora, vor
permite o mai bună înţelegere a scopului în care va fi utilizată fiecare ieşire. În general,
sistemele informaţionale servesc o mare varietate de utilizatori, care realizează sarcini şi
operaţiuni diverse în cadrul firmei, ceea ce face dificilă personalizarea rapoartelor pentru
fiecare utilizator în parte. Analistul va trebui să ia în considerare eficienţa fiecărei ieşiri,
respectiv raportul beneficii-costuri, şi să combine cerinţele informaţionale ale utilizatorilor
cu costurile în vederea proiectării unor ieşiri cât mai apropiate de cerinţele acestora.
De asemenea, informaţiile despre destinatarii ieşirilor vor ghida proiectarea
mecanismelor pentru controlul generării şi distribuirii lor, precum şi alegerea mediilor de
transmitere.
Destinatarii ieşirilor se regăsesc în diagramele fluxurilor de date sub forma entităţilor
externe către care se îndreaptă fluxurile de date, iar descrierea lor se regăseşte în depozitul
metadatelor din produsele CASE.
Din punctul de vedere al destinatarilor, pot fi identificate două tipuri principale de
ieşiri: interne şi externe. Ieşirile interne sunt rezultatul unui proces de prelucrare şi rămân
în cadrul sistemului, fiind folosite de utilizatori pentru luarea unor decizii sau controlul
unor activităţi. În Sistemul de evidenţă a relaţiilor cu furnizorii, „Situaţia datoriilor scadente
faţă de furnizori” poate servi în luarea deciziei privind plăţile ce se vor efectua, iar
„Balanţa analitică a furnizorilor” va permite controlul corectitudinii înregistrării
operaţiunilor economice privind furnizorii.
Ieşirile externe se referă la documentele primare şi acele rapoarte care depăşesc
graniţele sistemului şi, în unele cazuri, pe cele ale firmei. De cele mai multe ori, ele au
rolul de confirmare a realizării unei acţiuni sau de declanşare a unui proces în cadrul
sistemului destinatar. De exemplu, Sistemul de urmărire a producţiei întocmeşte „Raportul
de producţie” pentru a confirma Sistemului informaţional contabil producţia realizată în
fiecare lună. „Avizul de însoţire a mărfurilor” şi „Situaţia cheltuielilor materiale pe comenzi
de producţie”, generate de Sistemul de gestiune a stocurilor vor reprezenta intrări pentru
Sistemul de desfacere, respectiv Sistemul de calculaţie a costurilor, unde vor fi declanşate
procesele de întocmire a facturii, respectiv actualizarea fişelor de postcalcul.
O atenţie deosebită trebuie acordată proiectării ieşirilor destinate utilizatorilor din afara
firmei, deoarece ele reprezintă documente oficiale. În această categorie se cuprind ofertele
transmise clienţilor, rapoartele financiare destinate acţionarilor firmei sau documentele
legale, precum facturile şi poliţele de asigurare. Astfel de ieşiri trebuie obţinute în condiţii
grafice şi color de calitate înaltă.
O a treia formă ar putea fi una hibridă, cunoscută şi sub numele de documente în
circuit, ceea ce ar însemna producerea lor într-un sistem, părăsirea lui şi revenirea în sistem
sub o formă îmbunătăţită, ca intrări. Aici pot fi incluse cupoanele firmelor care combină
13

oferta lor cu potenţiala comandă a clientului (de regulă, detaşabilă sau returnabilă la
emitent) sau carnetele cu file CEC. În cele mai moderne forme se apelează la documente ce
pot fi citite automat de sistemele de prelucrare automată a datelor, care folosesc cititoare de
coduri bară, de caractere scrise cu cerneală magnetică sau recunoscute pe cale optică.
Un alt aspect de proiectare, strâns legat de destinatarii ieşirilor, îl reprezintă numărul
de exemplare. Atunci când pentru o aceeaşi ieşire există mai mulţi destinatari, ea trebuie
generată în mai multe exemplare. Dacă majoritatea documentelor sunt întocmite în mai
multe exemplare, de exemplu trei pentru „Factură” şi două pentru „Bonul de consum”,
rapoartele sunt generate, de regulă, într-un singur exemplar. Există şi excepţii: „Lista de
inventar” şi „Statul de salarii” sunt întomite în două exemplare.

1.2.3 Frecvenţa ieşirilor

Eficacitatea rapoartelor depinde de oportunitatea lor. Dacă ele nu sunt furnizate la

timp, atunci ele nu vor mai contribui la atingerea scopului pentru care au fost proiectate.
Frecvenţa rapoartelor poate varia de la cele solicitate la cerere, până la cele zilnice,
săptămânale, lunare, trimestriale sau anuale.
În funcţie de momentul elaborării lor, rapoartele pot fi clasificate în patru categorii:
rapoarte programate, analize neprogramate, rapoarte la cerere şi rapoarte declanşate de
excepţii. O prezentare sintetică a acestor tipuri de rapoarte este redată în figura 1.1.
Rapoartele programate (la termen) sunt elaborate la anumite intervale regulate, au un
conţinut predeterminat şi formatul lor este dinainte stabilit. Aici se încadrează rapoartele
realizate zilnic, săptămânal, lunar, trimestrial sau annual. De exemplu, „Registrul de casă”
se întocmeşte zilnic, „Statul de plată al salariilor” şi „Centralizatorul statelor de plată al
salariilor” se întocmesc lunar, iar diferitele anexe la bilanţ se întocmesc anual. Alte
exemple de rapoarte programate sunt: analizele săptămânale ale vânzărilor, raportul lunar
de producţie, balanţa sintetică de verificare, situaţia amortizării lunare a mijloacelor fixe,
dările de seamă financiar-contabile.
Analizele neprogramate, cu rol special, deseori numite şi rapoarte ad-hoc, nu au
conţinutul şi forma dinainte stabilite şi nu sunt realizate conform unor programări
anterioare. De fapt, ele sunt elaborate ca răspuns la întrebările managerilor privind anumite
probleme sau cerinţe ce nu au putut fi identificate pe timpul dezvoltării sistemului, motiv
pentru care ele nu au fost proiectate anterior. Pentru a permite obţinerea unor astfel de
rapoarte, sistemul trebuie să ofere facilităţi grafice prin care utilizatorii să poată lansa
interogări SQL şi construi rapoarte.
Rapoartele declanşate de excepţii conţin informaţii filtrate în legătură cu anumite
evenimente sau tranzacţii care implică depăşirea unor valori prestabilite, şi care solicită o
atenţie specială. Ele au un conţinut predeterminat şi un format anume şi sunt generate în
momentul în care se realizează excepţia prevăzută. Un exemplu îl reprezintă „Situaţia
depăşirii costurilor”, în care sunt incluse poziţiile bugetare la care s-a înregistrat depăşirea
cheltuielilor planificate, şi pe baza căreia managerul va putea lua deciziile şi măsurile
corective. Acest raport va fi generat atunci când se înregistrează depăşirea cheltuielilor
bugetate, însă, dacă astfel de situaţii se petrec cu regularitate, atunci el va deveni un raport
programat, ce va fi solicitat periodic, eventual lunar. Aşadar, unele rapoarte generate de
excepţii pot fi elaborate periodic.

Rapoarte ad-hoc (Analize neprogramate)
• Sprijină managerii în aflarea răspunsurilor
la întrebările What-If
• Realizate pe baza programelor statistice
de modelare
• Utile în planificarea decizională

Rapoarte de excepţii
• Semnalează doar cazurile ie şite de sub
control
• Pot fi liste de erori sau rapoarte obişnuite

Rapoarte la cerere
• Generate la cererea unei persoane
• Uşor de realizat prin limbaje de interogare
• Acoperă cererea spontană de informa ţii

Rapoarte programate
• Realizate la termene prestabilite
• Pot fi zilnice, săptămânale, decadale,
chenzinale ş.a.
• Mult solicitate de utilizatori

Fig. 1.1 Caracterizarea tipurilor de rapoarte necesare procesului managerial

Alte exemple de rapoarte declanşate de excepţii sunt: „Lista stocurilor fără mişcare sau
cu mişcare lentă”, „Situaţia rebuturilor înregistrate în procesul de producţie”, „Lista
clienţilor cu creanţe scadente neachitate”, „Lista imputaţiilor pentru lipsă din gestiune”.
Rapoartele la cerere au, de asemenea, conţinut şi formă predeterminate, dar sunt
elaborate numai ca răspuns la cererea managerilor.
Rapoartele declanşate de excepţii şi cele la cerere dau puterea sistemelor informaţionale
de a fi eficiente în sprijinirea conducerii.

TA 1.2
1. Prezentaţi caracteriticile rapoartelor declanşate de excepţii.
2. Realizaţi o comparaţie între rapoartele programate şi cele neprogramate.
3. Daţi câte un exemplu de rapoarte programate şi declanşate de excepţii din domeniul
contabilităţii.
Răspuns:
15

1.2.4 Formatul ieşirilor

Formatul ieşirilor defineşte modalitatea de organizare şi prezentare a informaţiilor,

astfel încât ele să fie atrăgătoare, uşor de înţeles şi utilizat. De multe ori, informaţii
oportune, corecte şi pertinente nu pot fi valorificate deplin, datorită unei prezentări
inadecvate. Informaţiile trebuie să fie clare, precise, ordonate, prezentate într-o modalitate
adecvată şi pe un suport accesibil. Cele mai utilizate forme de prezentare sunt:
tabelară; este cea mai frecvent întâlnită şi presupune organizarea informaţiilor în
linii şi coloane; de cele mai multe ori această formă înlesneşte pe cea grafică;
zone predefinite, caz în care informaţiile sunt organizate în mai multe zone
predefinite pe hârtie sau pe ecran, similar paginilor Web sau ziarelor obişnuite;
grafică, în care datele numerice sunt prezentate prin unul din numeroasele tipuri de
grafice.
În unele situaţii, cea mai bună modalitate de prezentare a informaţiilor poate rezulta
din combinarea celor trei forme. Asupra regulilor de prezentare a informaţiilor în formă
tabelară sau grafică vom reveni în paragrafele următoare.
Un alt element de proiectare, legat de definirea formatului ieşirilor, priveşte
dimensiunea paginii, în cazul tipării lor, sau rezoluţia de afişare, atunci când ele vor fi
vizualizate pe ecran. Formatele de pagină standard utilizate frecvent sunt A3, A4 şi A5. În
ceea ce priveşte rezoluţia de afişare, deşi aceasta evoluează extrem de rapid, este
recomandată utilizarea standardului 640x480 pixeli, pentru a fi siguri că toţi utilizatorii vor
putea vizualiza ieşirile din sistem.

1.2.5 Conţinutul

Această caracteristică este considerată adesea drept cea mai importantă. Ea defineşte
informaţiile ce vor fi incluse într-un document sau raport, în funcţie de scopul utilizării lor.
Se spune că managerii au nevoie de şase categorii mari de informaţii1: curente, de
atenţionare, indicatori de bază, situaţionale, clevetiri (bârfe), externe.
Principalele atribute calitative ale ieşirilor, din punctul de vedere al conţinutului, sunt
exactitatea şi exhaustivitatea informaţiilor. Utilizatorilor trebuie să li se furnizeze doar
acele informaţii de care are nevoie, fără a-i sufoca cu un şuvoi informaţional din care să fie
incapabili să deceleze informaţia necesară sau să le solicite eforturi inutile şi păguboase. De
asemenea, dacă se furnizează prea puţine informaţii, atunci raportul nu va mai fi de folos
utilizatorilor.
Prin prisma gradului de detaliere a informaţiilor conţinute, rapoartele pot fi detaliate,
de sinteză sau dinamice.
Rapoartele detaliate conţin informaţii cu un nivel minim de agregare şi filtrare, fiind
utilizate în activitatea de zi cu zi de către angajaţii din firmă. De regulă, în astfel de
rapoarte se include câte o linie pentru fiecare înregistrare prelucrată din baza de date. Unele
rapoarte detaliate pot conţine informaţii referitoare la o singură tranzacţie sau obiect; în
„Fişa analitică” a unui client se reţine câte o linie pentru fiecare înregistrare din baza de
date care priveşte o livrare sau o încasare pentru acel client. Alte rapoarte prezintă un grup
de tranzacţii. De exemplu, „Situaţia lunară a vânzărilor” poate conţine câte o line pentru
fiecare document de livrare emis în luna respectivă, şi pentru fiecare produs cuprins în
document.

1. Alter, S. – Op. cit., pp. 147-148; Mintzberg, H. – „The Manager’s Job: Folklore and Fact”, in Harvard Business
Review 53, nr. 4, July-August 1975, pp. 49-61.

O bună proiectare a rapoartelor detaliate implică, de cele mai multe ori, prevederea
unuia sau mai multor niveluri de total. În „Situaţia lunară a vânzărilor”, datele pot fi
grupate pe clienţi şi pe documente, fiind prevăzute, în afara totalului general, totalul
vânzărilor pe clienţi şi totalul valoric pentru fiecare document, în literatura de specialitate
fiind cunoscute ca sume de control major, intermediar şi minor.
Rapoartele de sinteză sunt generate pentru a oferi utilizatorilor informaţii agregate şi
filtrate, fără a mai fi prezentate unele detalii, care nu le sunt necesare. Înformaţiile conţinute
în aceste rapoarte sunt obţinute prin prelucrarea şi însumarea înregistrărilor din baza de
date, iar fraza SELECT, prin care se extrag şi se prelucrează datele necesare, va include
clauza GROUP BY.
Rapoartele de sinteză sunt utilizate, de regulă, de către managerii de pe nivelurile
superioare de conducere. Directorul de vânzări poate fi interesat de „Situaţia lunară a
vânzărilor”, numai că informaţiile vor fi prezentate la un nivel de agregare superior celui
discutat anterior. Dacă este solicitată „Situaţia vânzărilor pe clienţi”, atunci raportul va
conţine câte o linie pentru fiecare client, în care sunt însumate toate documentele de livrare
pentru un client. „Raportul vânzărilor lunare” presupune un nivel de agregare şi mai mare,
reţinându-se câte o linie pentru fiecare lună calendaristică, care va conţine totalul vânzărilor
din luna respectivă.
Rapoartele dinamice presupun combinarea rapoartelor de sinteză cu cele detaliate, însă
ele pot fi afişate doar pe ecran. Aceste rapoarte oferă utilizatorului posibilitatea schimbării
interactive a nivelului de detaliere a informaţiilor, dacă ele sunt proiectate în acest sens.
Rapoartele dinamice pot fi create pe baza a două tehnici: „drill up-drill down” şi cea
bazată pe legare.
Prin tehnica drill up-drill down, informaţiile, organizate după o anumită ierarhie, pot fi
afişate pe diferite niveluri de detaliere, aranjate în cascadă. Aceste tipuri de rapoarte sunt
frecvent întâlnite în aplicaţiile OLAP (On-Line Analytical Processing), care extrag datele
stocate în depozite de date (data warehouse) sau baze de date multidimensionale, şi care
sunt utilizate în analize multidimensionale.
„Raportul privind situaţia profitului” din figura 1.2 este prezentat la nivelul maxim de
detaliere pentru primele trei trimestre, însă el poate fi reconfigurat de către utilizator, astfel
încât să fie afişate numai informaţiile la nivel de trimestre sau ani. Selectarea cu mouse-ul a
„minusului” din partea stânga va determina ascunderea detaliilor de pe nivelurile inferioare,
similar cu parcurgerea structurii de directoare în Windows Explorer, operaţiune numită
drill-up. În locul semnului „minus” va apărea semnul „plus” , prin selectarea căruia se va
reveni la afisarea detaliilor de pe nivelul imediat inferior, operaţiune numită drill- down.
Afişarea datelor detaliate pe lunile trimestrului IV se poate face prin selectarea cu mouse-ul
a „plusului” din dreapta. De exemplu, pentru afişarea doar a informaţiilor relative la cele
patru trimestre ale anului 1999 vor trebui selectate cele patru „minusuri”, situate în partea
stângă a liniilor aferente.
17

Fig. 1.2 Exemplu de raport ce utilizează tehnica „drill up-drill down”

Cea de-a doua tehnică presupune legarea rapoartelor, în mod asemănător cu
documentele accesate pe Internet cu ajutorul browser-elor. Această tehnică permite
utilizatorilor să coreleze informaţiile dintr-un raport cu un altul mai detaliat. În figura 1.3
este prezentată „Balanţa analitică a stocurilor de materiale”, iar prin apăsarea tastei
<ENTER> sau efectuarea „dublu clic” pe linia curentă se poate declanşa afişarea „Fişei
analitice” pentru materialul corespunzător. În fişă pot fi vizualizate toate intrările şi ieşirile
din stoc pentru acel material, în perioada curentă. Aceeaşi tehnică poate fi utilizată pentru
legarea unui raport sintetic, privind vânzările lunare pe categorii de produse, de un altul,
detaliat, în care să fie prezentate vânzările lunare pentru o anumită categorie, însă pe
fiecare produs în parte.
Biroul Contabilitate
Balanţa analitică a stocurilor pe luna aprilie 2005
Gestiunea: Materii prime şi materiale

Nr. Cod Denumire UM Pret Stoc Sold Intrari Ieşiri Stoc Sold
crt. material material iniţial iniţial Cantitativ Valoric Cantitativ Valoric final final
1 220006 Balama tip banda buc 188.500 122 22.997.000 75 14.137.500 112 21.112.000 85 16.022.500
2 220014 Ornament Bis buc 74.320 35 2.601.200 40 2.972.800 25 1.858.000 50 3.716.000
3 220022 Broasca simpla buc 98.100 50 4.905.000 88 8.632.800 98 9.613.800 40 3.924.000
4 220037 Furnir stejar mp 212.000
212.000 115 24.380.000 220 46.640.000 235 49.820.000 100 21.200.000
5 220045 Furnir cires mp 179.500 25 4.487.500 33 5.923.500 30 5.385.000 28 5.026.000
6 220053 Lac kg 23.500 360 8.460.000 864 20.304.000 982 23.077.000 242 5.687.000
7 220061 Bait luciu kg 31.200 88 2.745.600 110 3.432.000 120 3.744.000 78 2.433.600

Fig. 1.3 Exemplu de utilizare a tehnicii legării rapoartelor

Un alt aspect dinamic al rapoartelor afişate pe ecran constă în posibilitatea vizualizării
datelor din perspective diferite. De exemplu, situaţia vânzărilor poate fi afişată pe regiuni şi
categorii de produse sau pe regiuni şi pe perioade de timp.

Rapoartele tipărite pot fi şi ele organizate într-o manieră asemănătoare celor dinamice,
însă costurile vor fi mult mai mari, ceea ce poate afecta eficienţa informaţiilor furnizate.
O altă specificaţie de proiectare, strâns legată de conţinutul rapoartelor, este secvenţa
sau ordinea de prezentare informaţiilor. Alegerea ordinii de prezentare depinde de scopul
ieşirilor. Optarea pentru criterii de ordonare neadecvate poate determina eşecuri în atingerea
scopului urmărit. De exemplu, ordonarea alfabetică a „Situaţiei costurilor” după denumirea
elementelor de cost nu va evidenţia elementele care înregistrează un nivel mare al
costurilor, iar utilizatorul poate fi indus în eroare dacă el trebuie să ia unele decizii
privind reducerea costurilor. În plus, oamenii au tendinţa de a acorda o atenţie mai mare
acelor elemente care sunt prezentate în prima parte a rapoartelor.
De multe ori, satisfacerea unor cerinţe diverse impune ca în acelaşi raport datele să fie
ordonate după unele criterii sau altele. De exemplu, „Balanţa analitică a stocurilor” poate
să aibă datele ordonate pe gestiuni, dacă ea va fi utilizată pentru verificarea fişelor de
magazie, sau pe conturi de evidenţă, dacă se verifică corectitudinea înregistrărilor în
contabilitate, prin compararea ei cu „Balanţa de verificare sintetică”. Diferitele cerinţe de
ordonare pentru acelaşi raport necesită proiectarea unei secvenţe de dialoguri, prin care
utilizatorul să poată alege criteriile de ordonare. Problematica proiectării dialogurilor va fi
tratată în capitolul următor.

TA 1.3
1. Descrieţi, pe scurt, tehnica drill-up/drill-down de creare a rapoartelor dinamice.
2. Enumeraţi specificaţiile de proiectare privind conţinutul rapoartelor.
3. Daţi un exemplu de raport în care să puneţi în evidenţă legătura dintre ordinea de
prezentare a informaţiilor şi scopul raportului.
Răspuns:

1.2.6 Sursa datelor

În majoritatea cazurilor, sursa pentru obţinerea ieşirilor o constituie tabelele bazei de

date, reprezentate în diagrama fluxurilor de date prin locurile de stocare. Astfel, procesele
de prelucrare ce au drept scop obţinerea de rapoarte vor include una sau mai multe
operaţiuni de citire, puse în evidenţă prin fluxuri de date dinspre locurile de stocare către
19

procesele respective. Pentru fiecare flux de citire, în depozitul metadatelor, se vor specifica
detaliile privind câmpurile accesate şi înregistrările care vor fi extrase pentru prelucrare.
În alte situaţii, pentru generarea unei ieşiri, mai ales a documentelor, se folosesc drept
sursă ieşirile din alte procese de prelucrare. Întocmirea „Decontului TVA” se face pe baza
„Jurnalului de cumpărări” şi a „Jurnalului de vânzări”, obţinute prin alte două procese de
prelucrare.
Atunci când pentru obţinerea ieşirilor sunt necesare date din surse externe, analistul va
trebui să aleagă cea mai bună metodă de accesare şi prelucrare. Un asemenea caz va fi pus
în evidenţă, în diagrama fluxurilor de date, printr-un flux extern ce intră în procesul reţinut
pentru prelucrarea acestor date. Sursele externe pot face referire la locurile de stocare
gestionate de alte sisteme informaţionale din firmă sau de baze de date publice.
Din punctul de vedere al echipei manageriale, informaţiile pot fi văzute după sursele
acestora. Sintetic, ele sunt redate în tabelul 1.2.

Tabel nr. 1.2 – Surse comune ale informaţiilor

Surse de informaţii
Tip informaţie
Interne Externe
Formală (oficială), bazată Indicatorii principali obţinuţi din Baze de date publice
pe s.p.a.d. diverse sisteme de evidenţă ale firmei
Formală (oficială), bazată Planuri, rapoarte, procese-verbale ş.a. Rapoarte pe ramuri, cărţi, reviste
pe documente
Formală (oficială), verbal şedinţe programate Forumuri pe domenii
Informală Conversaţiile la masă, culese pe timpul Expoziţii, târguri, contacte
deplasărilor ş.a. personale ş.a.

1.2.7 Mediul de generare şi transmitere a ieşirilor

Una dintre activităţile specifice proiectării ieşirilor priveşte alegerea modului de

prezentare a informaţiilor. Deşi majoritatea ieşirilor sunt tipărite pe hârtie sau sunt afişate
pe ecran, există şi alte medii de transmitere a informaţiilor, precum cele audio şi video,
care au un impact imens asupra modului în care utilizatorii comunică. Este posibil ca
ieşirile să fie solicitate în mai multe forme, caz în care analistul va trebui să aibă în vedere
aspecte suplimentare la proiectare, precum cele specifice fiecărui mediu de transmitere şi
tehnologiilor utilizate.
În continuare, vom face o succintă descriere a principalelor tipuri de ieşiri, în funcţie
de mediul utilizat pentru prezentarea lor.

Ieşirile tipărite

Deşi, de mai mulţi ani, se vorbeşte despre biroul „fără hârtie” sau biroul digital, având
drept argumente progresele înregistrate în domeniul tranzacţiilor şi al documentelor
electronice, forma tipărită rămâne cea mai frecvent utilizată. Ieşirile tipărite au avantajul de
a fi „portabile”, mai comode, motive pentru care cei mai mulţi utilizatori vizualizează mai
întâi un raport pe ecran, după care îl tipăresc. În unele cazuri tipărirea constituie încă
singura formă viabilă de generare a ieşirilor, cum este cazul facturilor sau cel al
documentelor în circuit.
Desigur că utilizarea hârtiei pentru generarea ieşirilor creează unele probleme
organizaţiilor, dar şi mediului înconjurător. Cheltuielile privind obţinerea, arhivarea şi
regăsirea informaţiilor stocate pe hârtie sunt mult superioare celorlalte forme. De aceea,
multe firme îşi pun problema transpunerii documentelor din formatul pe hârtie în cel

electronic, de exemplu prin utilizarea scanner-elor, urmărind reducerea cheltuielilor şi
regăsirea mai rapidă a informaţiilor.
Datorită progreselor înregistrate în ultimii ani de tehnologia iprimării, astăzi există o
varietate mare de imprimante, în funcţie de preţ, rezoluţie, viteza de imprimare şi
capacitatea de memorie. Chiar dacă tehnologia imprimantelor cu jet de cerneală şi a celor
bazate pe laser s-a impus în ultimii ani, imprimantele matriciale rămân încă o soluţie
viabilă, mai ales pentru rapoartele mari sau solicitate des.

Ieşirile afişate pe ecran

Odată cu îmbunătăţirea performanţelor şi reducerea preţului monitoarelor, ecranul a

devenit, şi va rămâne, mediul preferat al utilizatorilor pentru generarea rapoartelor. Afişarea
pe ecran a ieşirilor prezintă numeroase avantaje, în comparaţie cu utilizarea hârtiei:
posibilitatea vizualizării rapoartelor dinamice, costuri de obţinere mult inferioare şi accesul
mai rapid la informaţii.

Mesajele electronice

Odată cu integrarea sistemelor informaţionale la nivel de organizaţie, dar şi inter-

organizaţii, generarea şi transmiterea ieşirilor în format electronic sunt din ce în ce mai
frecvent utilizate. Principalele tehnologii care facilitează schimbul electronic de informaţii
sunt Web-ul, poşta electronică şi sistemele EDI.
Extinderea utilizării Internetului, Intranet-ului, Extranet-ului şi a tehnologiei Web în
lumea afacerilor a creat condiţiile integrării sistemelor informaţionale. De exemplu, o firmă
poate permite accesul principalilor furnizori la sistemul său de gestiune a stocurilor,
transmiţînd acestora responsabilităţile privind activitatea de aprovizionare. Prin intermediul
tehnologiei Web, furnizorii vor putea oricând să acceseze baza de date şi să obţină anumite
rapoarte privind stocurile. De asemenea, prin intermediul unui site Web, clienţii vor putea
obţine on-line un catalog al produselor sau o ofertă.
Poşta electronică a devenit instrumentul esenţial de comunicare internă şi externă în
lumea afacerilor. Informaţiile despre produse noi, plăţi scadente, diverse notificări sau
confirmări, chiar documente, pot fi generate şi transmise în exteriorul firmei sub forma
mesajelor e-mail. Poşta electronică este utilizată din ce în ce mai mult şi în interiorul
firmei, înlocuind corespondenţa tradiţională bazată pe hârtie. Noile sisteme informaţionale
pot genera şi transmite automat, prin poşta electronică, diferite solicitări, înştiinţări sau
confirmări către angajaţii firmei sau decidenţi.

Sistemele cu ieşiri bazate pe microfilme, COM

(Computer Output Microfilm)

Ieşirile din sistem pot fi redate şi sub forma microfilmelor, care, prin instrumente
oferite de softul specializat, pot fi stocate, modificate şi transmise pe mai multe căi.
Sistemele COM permit utilizarea imaginilor în scopul arhivării şi consultării rapide a
documentelor şi rapoartelor generate iniţial pe hârtie, obţinându-se importante economii de
spaţiu. Ele sunt utile mai ales atunci când este necesară stocarea documentelor semnate,
ştampilate sau cu alte caracteristici vizuale. Totuşi, popularitatea acestor sisteme a scăzut în
ultimul timp în favoarea scanner-elor digitale.
Imaginea documentelor este captată şi stocată sub formă de microfilme sau microfişe.
Microfilmele stochează imaginile pe role de film, iar microfişele le transpun pe o singură
peliculă, sub forma diapozitivelor. Microfişele sunt preferate microfilmelor, datorită
21

utilizării mai eficiente a suportului de stocare şi pentru că ele permit indexarea şi regăsirea
mai uşoară a informaţiei.
Un sistem COM este conectat la un calculator şi poate transpune imaginile pe
microfilme sau microfişe în mod direct, pe măsură ce sunt generate. În afara acestui sistem,
utilizarea microfişelor şi a microfilmelor implică utilizarea unor echipamente auxiliare de
developare, copiere şi proiecţie.

Sistemele audio şi video

Tehnologiile audio şi video au înregistrat cele mai mari progrese în ultimii ani. Ieşirile
audio şi video oferă un potenţial de îmbunătăţire a comunicării pe care nici un alt mediu
nu-l poate realiza.
Audio înseamnă redarea sonoră a datelor. Mesajele vocale, fie şi cele gen Voice-Mail
(V-Mail), sunt destul de folosite în afaceri, îndeosebi în comerţul electronic. Aplicaţiile
practice ale ieşirilor audio sunt din ce în ce mai variate. Ele facilitează citirea ecranelor de
către utilizatorii cu probleme de vedere. De asemenea, ieşirile de tip audio pot fi generate
automat de către sistemul informatic pentru a înlocui personalul care preia telefonic
comenzile clienţilor, oferind astfel clienţilor un serviciu disponibil permanent, de tip
24/7/365 - 24 de ore din 24 ale zilei, 7 zile din 7 ale săptămânii, 365 de zile din an, cu
cheltuieli minime.
Video înseamnă combinarea imaginii şi a sunetului pentru a reda un anumit eveniment
în mişcare sub formă de film sau animaţie. Este forma specifică video-conferinţelor. O altă
utilizare a acestui tip de ieşire presupune crearea de simulări animate pentru a permite
utilizatorilor să vizualizeze o serie complexă de evenimente într-un timp scurt.

1.2.8 Controlul confidenţialităţii, integrităţii

şi accesibilităţii ieşirilor

În paragrafele anterioare, am consemnat o mare varietate de ieşiri, în funcţie de scop,

destinatari, format, mediu de transmitere, frecvenţă, conţinut şi sursa datelor. Pentru fiecare
tip de ieşire există proceduri şi mecanisme de control specifice, care vor trebui luate în
considerare la proiectarea lor. Însă, indiferent de tipul ieşirilor, prin control se vor urmări
confidenţialitatea, integritatea şi accesibilitatea ieşirilor, ceea ce înseamnă asigurarea
furnizării lor către destinatarii autorizaţi să le acceseze, precum şi a corectitudinii,
oportunităţii şi completitudinii informaţiilor conţinute. Oricum, nu trebuie să se omită
problemele referitoare la exercitarea controlului asupra sistemului, ele oferind motive de
revizuire a drepturilor de acces ale potenţialilor utilizatori, îndeosebi odată cu trecerea la
sistemul on-line.
Problema controlului ieşirilor nu o vom detalia în acest paragraf, deoarece această
caracteristică nu constituie un criteriu de clasificare, iar obiectivul urmărit de noi în acest
paragraf vizează prezentarea principalelor tipuri de ieşiri, pornind de la caracteristicile lor
generale. Asigurarea controlul integrităţii ieşirilor solicită aplicarea unor reguli specifice de
proiectare, motiv pentru care ele vor fi prezentate într-un paragraf următor, special destinat
acestui subiect. Problema securităţii ieşirilor este una mult prea vastă pentru a putea fi
epuizată în lucrarea de faţă. Celor interesaţi de acest subiect le recomandăm lucrarea
profesorului Dumitru Oprea, Protecţia şi securitatea informaţiilor2.

2. Oprea, D. – Protecţia şi securitatea informaţiilor, Editura Polirom, Iaşi, 2002.

1.2.9 Caracteristicile informaţiilor şi nivelurile decizionale

Cel mai adesea, ieşirile sunt generate în scopul luării deciziilor pe diferite niveluri
ierarhice. Pentru a-şi dovedi utilitatea, informaţiile trebuie să îndeplinească anumite
caracteristici relative la format, conţinut, sursa datelor, mediul de transmitere etc., aspecte
descrise în paragrafele anterioare. Caracteristicile pot fi văzute în mod diferit pe cele trei
niveluri decizionale, după cum este prezentat tabelul 1.3, care consemnează un punct de
vedere3 din literatura de specialitate.

Tabel nr. 1.3 – Caracteristicile informaţiilor pe niveluri decizionale

Caracteristicile
Caracteristicile
Niveluri decizionale
informaţiilor/rapoartelor
Operativ
Operativ Tactic
Tactic Strategic
Strategic

Dependen a de sistemele de
Dependenţa
pre uc a e automată
prelucrare au oma ă a datelor
da e or R d ca ă
Ridicată Mode aă
Moderată Redusă sp spree mode aă
moderată
Dependen a de informaţiile
Dependenţa informa iile interne Foar e d ca
Foarte ă
ridicată R d ca ă
Ridicată Mode aă
Moderată
Dependen a de informaţiile
Dependenţa informa iile externe Redusă
Redusă Mode aă
Moderată Foar
Foartee dridicată
ca ă
Gradul de sintetizare a informaţiilor
informa iilor Foarte redus Moderat
Moderat Ridicat
Nevoia de informaţii
informa ii on-line Foar
Foartee dridicată
ca ă R d ca ă
Ridicată Mode aă
Moderată
Nevoia de ggrafică
a că pepeca cu ator
calculator Redusă Mode aă
Moderată R d ca ă
Ridicată
informa iilor în timp real Foar
Folosirea informaţiilor e d ca
Foarte ă
ridicată R d ca ă
Ridicată Mode aă
Moderată
informa iilor predictive* Redusă
Folosirea informaţiilor R d ca ă
Ridicată Foar
Foartee dridicată
ca ă
informa iilor din trecut
Folosirea informaţiilor R d ca ă
Ridicată Mode aă
Moderată Redusă
informa iilor tip What-If Redusă
Folosirea informaţiilor Redusă R d ca ă
Ridicată Foar
Foartee dridicată
ca ă
informa iilor în etalon
Folosirea informaţiilor
bănesc Redusă Mode aă
Moderată R d ca ă Frecven
Ridicată Deseori a
Frecvenţa cererii de
cererii de informa ii informaţii Regulat, repetitiv Aproape regulat Deseori ad-hoc
ad-hoc Rezultate
informa iei la
Efectul primirii informaţiei Rezultat aşteptat Pot apă
Pot apărea unele
ea une surprize
e surpr pline depline
ze Rezultate surprize
de
utilizator (predictibil) surprize
Pentru perioade viitoare
Intervalul de timp acoperit Trecut Comparativ
Comparativ pe pe perioade
perioade Pentru perioade viitoare
(predicţii)
sau fa
faţăă de anum
anumitee (predic
ii)
standarde Sintetice
N velu de
Nivelul dede a e e a ap prezentărilor
detaliere ezen ă o FoarteFoarte
detaliate
detaliate Sintetice Sintetice
Sursa datelor Interne Interne
Interne şi
şi externe
externe Majoritatea externe
Natura datelor utilizate Puternic structurate Unele
Unele date nestructurate Puternic nestructurate
date nestructurate
Corectitudinea/Precizia datelor Foarte precise Unele date sunt subiective Foarte subiective
subiective
Utilizatorii tipici Supervizorii din prima Managerii
Managerii de de mijloc
mijloc Top managerii
linie
linie
Obiectul deciziei luate Act v ă i prestabilite
Activităţi prestabilite Orientate spre
Orientate spre controlul
controlul Orientate spre obiective
şi alocarea resurselor strategice

* În accepţiunea autorului înseamnă informaţii obţinute prin tehnici de modelare statistică, cum ar fi regresia, analiza
seriilor de timp şi simularea. Ajută managerul în planificarea managerială, oferind răspunsuri la întrebările What-If.

1.3 Răspunsuri la testele de autoevaluare

TA 1.1 1) ordinea de prezentare a coloanelor, sortarea informaţiilor, totalurile ce
trebuie incluse, suportul pe care va fi transmisă ieşirea şi frecvenţa. 2) Vezi p. 10.

TA 1.2 1) Formatul şi conţinutul predeterminate, generate în momentul realizării excepţiei
prevăzute. 2) Au/nu au forma şi conţinutul dinainte stabilite, sunt/nu sunt realizate la momente
prestabilite. 3) Vezi p. 12.
TA 1.3 1) Vezi p. 15. 2) exactitate, exhaustivitate, nivelul de detaliere, ordonarea
informaţiilor, totaluri şi subtotaluri incluse. 3) Vezi p. 17.

3. Hicks Jr., J.O. – Management Information Systems: A User Perspective, Second Edition, West Publishing Company,
St. Paul, 1987, p. 25; Schulteis, R., Sumner, M., Bock, D. – Management Information Systems: The Manager’s View,
Second Edition, IRWIN, Homewood, Boston, 1992, pp. 312-329.
23

1.4 Lucrare de verificare

A. Alegeţi varianta/variantele corectă/e de răspuns:
1) Rapoartele dinamice se caracterizeaza prin faptul ca:
a) ele combina rapoartele de sinteza cu cele detaliate
b) ele redau dinamica unui anumit proces sau fenomen economic
c) ele combina datele in format tabelar cu reprezentarile grafice
2) Care dintre urmatoarele tipuri de rapoarte (clasificate dupa frecventa lor) au un
continut predeterminat si format dinainte stabilit?
a) analizele neprogramate
b) declansate de exceptii
c) programate
d) la cerere
e) ad-hoc
f) dinamice
3) Scopul rapoartelor determina urmatoarele aspecte de proiectare:
a) totalurile ce trebuie incluse
b) ordinea de prezentare a coloanelor
c) sortarea (ordonarea) informatiilor continute
d) frecventa elaborarii lor

B. Răspundeţi la următoarele întrebări şi probleme:
1. Daţi un exemplu de raport din domeniul contabilităţii şi descrieţi-l prin intermediul
caracteristicilor generale ale ieşirilor.
2. Care sunt formele de generare şi transmitere a rapoartelor (ieşirilor)?

1.5 Bibliografie

1. Marakas, G. – Systems Analysis and Design. An Active Approach, Prentice Hall, New
Jersey, 2001, pp. 307-321
2. Oprea, D., Dumitriu, F., Meşniţă, G., Proiectarea sistemelor informaţionale, Ed.
Universităţii “Al. I. Cuza” Iaşi, 2006, pp. 12-33
3. Romney, M.B., Steinbart, P.J., Accounting Information Systems, Pearson Education Inc.,
New Jersey, 2003, pp. 662-664


Proiectarea formularelor/formatelor
şi a rapoartelor

Obiective:
Descrierea regulilor şi recomandărilor de proiectare a ieşirilor
Prezentarea unor criterii de apreciere a calităţii informaţiilor incluse în formulare/formate
şi rapoarte
Descrierea procesului de proiectare a formularelor şi rapoartelor
Prezentarea unui model de întocmire a specificaţiilor de proiectare a formularelor şi
rapoartelorExplicarea conceptelor formular/format şi raport
Determinarea regulilor de proiectare a ieşirilor din sistemele informaţionale care trebuie
aplicate în diverse situaţii şi pe diferite tipuri de ieşiri
Aplicarea regulilor de proiectare în scopul obţinerii de rapoarte de calitate
Definirea procedurilor de control al ieşirilor informaţionale
Definirea unui demers de lucru care să permita implicarea directă a utilizatorilor în procesul
de proiectare a ieşirilor informaţionale
Elaborarea specificaţiilor detaliate de proiectare a rapoartelor

2.1 Reguli de proiectare a formularelor/formatelor şi a rapoartelor ............................................ 24
2.1.1 Recomandări generale de formatare................................................................................ 25
2.1.2 Scoaterea în evidenţă a informaţiilor .............................................................................. 26
2.1.3 Reguli specifice de proiectare a rapoartelor în formă tabelară ....................................... 29
2.1.4 Reguli specifice de proiectare a graficelor...................................................................... 33
2.1.5 Reguli pentru controlul confidenţialităţii, integrităţii şi accesibilităţii ieşirilor ............. 34
2.2 Demersul proiectării ieşirilor ................................................................................................. 36
2.3 Formularea specificaţiilor de proiectare a ieşirilor ................................................................ 38
2.6 Bibliografie ............................................................................................................................ 40

2.1 Reguli de proiectare a formularelor/formatelor
şi a rapoartelor

Odată cu succesele înregistrate de tehnologiile informaţionale, pretenţiile utilizatorilor
de informaţii au crescut şi ele, datorită unei influenţe fireşti a educaţiei acestora în domeniul
calculatoarelor. Efectul se face simţit şi în privinţa calităţii rezultatelor prelucrării obţinute la
calculator. Paradoxal, chiar specialiştii în informatică trebuie să le cultive utilizatorilor
gustul pentru nou, pentru calitatea ieşirilor informatice. Într-un astfel de context, vom
prezenta câteva aspecte ce ţin de cultura bunului gust în privinţa proiectelor de
formulare/formate şi rapoarte.
25

2.1.1 Recomandări generale de formatare

Descrierea detaliată a modului în care se reflectă calitatea ieşirilor în performanţele

celor ce le utilizează constituie un amplu subiect de discuţie în literatura de specialitate4.
Din multitudinea de păreri s-ar putea desprinde ca fiind cele mai elocvente sintezele
realizate de J.S. Dumas5 şi Cushing & Romney6.

Introducere sugestivă (partea de titlu)

Prezentarea foarte clară a titlului ieşirii în partea superioară a paginii, central. Ea trebuie
să descrie cu fidelitate conţinutul.
Evidenţierea numărului şi/sau datei.
Dacă trebuie distribuit în alte locuri, care sunt acestea?
Specificarea datei de emitere a ieşirii, care poate să nu coincidă cu data sau perioada de
apartenenţă a informaţiilor oferite.
Dacă este cazul, va fi consemnată şi ora editării.
Informaţiile din instrucţiuni
Regulile de completare să fie foarte clare.
Să se specifice etapa ce urmează după editare.
De evitat comentariile lungi, prin rubrici cu nume sugestive.
De consemnat destinaţiile fiecărui exemplar al documentului/raportului tipărit.
Informaţiile să fie oferite fără modificări manuale.
Partea principală (corpul ieşirii)
Să se facă o prezentare echilibrată, evitându-se aglomerările.
Folosirea corectă a spaţierilor, marginilor.
Numirea corectă a rubricilor.
Gruparea logică a rubricilor.
Scoaterea în relief a zonelor ce marchează rubrici diferite.
Accentuarea prin linii sau culori a zonelor-cheie.
Concluziile (finalul ieşirii)
De plasat la sfârşitul paginii.
De alocat spaţiu suficient semnăturilor.
De prezentat ultimele indicaţii privind regimul de lucru cu documentul/ raportul.
Totalurile vor fi bine evidenţiate.
Deplasarea lejeră prin document (navigarea)
De indicat, în faza de editare, cum se pot efectua deplasările înainte şi înapoi.
De arătat întotdeauna locul în care se află utilizatorul (de exemplu, pagina 5 din 15).
De specificat modul cum se poate efectua ieşirea din regimul de editare.
Semnalarea clară a ultimei pagini dintr-o secvenţă de mai multe pagini.
Tratarea ecranului după acelaşi regim cu documentul original (clasificarea informaţiilor şi
a accesului la ele).
Protejarea împotriva pierderii, modificării sau sustragerii ilegale sau din greşeală a
informaţiilor.

4. Shneiderman, B. – Designing the User Interface: Strategies for Effective Human-Computer Interaction, Addison-
Wesley, Reading, Massachusetts, 1992; Caroll, J.M. – Designing Interaction, Cambridge University Press, Cambridge,
1991; Norman, K.L. – The Psychology of Menu Selection, Ablex, Norwood, New Jersey, 1991; Benbasat. I., Dexter,
A.S., Todd, P. – „The Influence of Color and Graphical Information Presentation in a Managerial Decision
Simulation”, in Human-Computer Interaction 2, 1986, pp. 65-92.
5. Dumas, J.S. – Designing User Interface for Software, Prentice Hall, Englewood Cliffs, 1988; Vezi şi Beizer, B. –
Personal Computer Quality, Van Nostrand Reinhold Company, New York, 1986.
6. Cushing, B.E., Romney, M.B. – Accounting Information Systems, Addison-Wesley Publishing Company, New York,
1994.

O regulă generală de proiectare a ieşirilor priveşte uniformitatea. La proiectarea tuturor
ieşirilor trebuie aplicate aceleaşi principii şi reguli, uşurând astfel procesul de învăţare. De
exemplu, data generării şi numărul de pagină trebuie să fie plasate în acelaşi loc pentru
toate ieşirile, abrevierile utilizate să fie menţinute de la o ieşire la alta etc.
Majoritatea regulilor prezentate anterior se aplică şi în cazul formularelor/formatelor
pretipărite: titlurile rubricilor trebuie să fie explicite şi să conţină doar abrevieri standard;
rubricile trebuie să fie grupate şi ordonate din punct de vedere logic; totalurile să fie bine
evidenţiate etc. Ca particularitate, apare necesitatea contactării furnizorului în vederea
punerii de acord asupra dimensiunii paginii, tipului şi dimensiunii fonturilor, culoarea
cernelii, a altor detalii. Formularul/formatul trebuie şă fie atractiv, uşor de citit şi la un preţ
rezonabil.

2.1.2 Scoaterea în evidenţă a informaţiilor

Datorită progreselor semnificative înregistrate în domeniul tehnologiilor

informaţionale, punerea în evidenţă a informaţiilor din formulare/formate sau rapoarte se
poate realiza sub forme din ce în ce mai performante. Literatura recomandă mai multe
forme de marcare a anumitor informaţii, a grupurilor de informaţii aflate în interdependenţă,
a totalurilor ş.a.m.d. Dintre ele amintim:
marcaj clipitor/intermitent;
marcaj sonor;
intensităţi diferite de culoare;
culori diferite;
diferenţieri prin mărimi variate ale caracterelor;
diferenţieri prin fonturi;
video invers;
casete cu date grupate;
subliniere;
caractere majuscule;
tipărirea informaţiilor nestandard cu caractere diferite de celelalte.
Evidenţierea unor informaţii dintr-o mulţime dată este recomandată îndeosebi în
următoarele situaţii:
Atenţionarea utilizatorului, atunci când se introduc date eronate sau când, din
prelucrare, unele valori sunt eronate.
Punerea în gardă a utilizatorului că datele introduse trebuie să aparţină unor intervale
de valori sau că anumite echipamente nu sunt în stare funcţională.
Semnalarea, prin comenzi, cuvinte-cheie sau mesaje, că operarea a intrat într-un
regim anormal.
Scoaterea în evidenţă a unor rubrici unde se înregistrează subtotaluri sau totaluri
sau unde se va afişa în curând o nouă valoare.
Marcarea zonelor comune din pagină ş.a.
În figura 1.4 prezentăm o formă neinspirată pentru ecranul „Situaţie a personalului”,
iar în figura 1.5 este redată o altă formă, dar cu scoaterea în evidenţă a informaţiilor
conţinute.
În ultima variantă, s-au folosit mai multe dintre modalităţile recomandate anterior
pentru scoaterea în evidenţă a unor informaţii importante: mărimi diferite ale caracterelor,
fonturi diverse, intensităţi variate, subliniere, caractere îngroşate (bold), folosirea doar
27

pentru anumite informaţii a majusculelor, apelarea la casete diferite, intensităţi diferite de
scriere, comenzi clare de navigare, prin butoane.
Citire dificilă: informaţii
Titlu vag prea înghesuite, nealiniate

Utilizarea exclusivă Lipsesc
Lipsa unor
a majusculelor este facilităţile de
totaluri
obositoare navigare

Fig. 1.4 Exemplu incorect de scoatere în evidenţă a informaţiilor

Titlu clar,
bine scos în evidenţă

Combinarea plăcută a Includerea unor Facilităţi pentru
majusculelor şi minusculelor. totaluri relevante navigare
Gruparea datelor. Evidenţierea Citire lejeră: aliniere,
prin caractere îngroşate. evidenţierea elementelor
variabile de cele constante
Fig. 1.5 Exemplu corect de scoatere în evidenţă a informaţiilor

În privinţa marcării prin culori, părerile sunt împărţite. Deseori, culorile scot în
evidenţă în mod plăcut anumite elemente, alteori ele se folosesc doar pentru a fi altceva
decât clasicele imprimări alb-negru.
Literatura este destul de reprezentativă în legătură cu folosirea sau nu a culorilor7. În
pofida disputelor aprige, concluzia a fost aceea că, totuşi, apelarea la culori ar putea oferi
avantaje, dar şi crea anumite probleme, astfel:
Avantaje:
„Sar” în ochi, scot în evidenţă ceva anume.
Accentuează ceea ce printr-o afişare normală ar fi irelevant.
Prin nuanţări de culori se pot evidenţia situaţii specifice din afişări complexe.
Subliniază organizarea logică a informaţiilor.
Orientează atenţia spre zonele cărora trebuie să li se acorde o importanţă deosebită.
Produc reacţii emoţionale mai mari.
Ajută la citirea mai uşoară a liniilor din tabele.
Probleme ce apar la folosirea culorilor:
Anumite suprapuneri de culori conduc la aşa-zisa „spălăcire” a elementelor tipărite
sau la apariţia unor culori-fantomă.
Rezoluţia este diferită de la un mediu de lucru la altul.
Fidelitatea culorii diferă de la un mediu la altul.
Tipărirea sau conversia pe un alt echipament ar putea fi sortită eşecului.
Imposibilitatea perceperii anumitor nuanţe de culori de către toţi utilizatorii – de
exemplu, culoarea roşie şi derivatele, pentru daltonişti.
Manipularea mai lejeră a cititorilor prin colorarea stridentă a informaţiilor
nerelevante economic, cu scopul ascunderii altora importante.
Nu trebuie să se tragă concluzia că întotdeauna varianta color este mai bună decât cea
alb-negru. De exemplu, un stat de salarii, o calculaţie de cost, o situaţie a furnizorilor ar fi
eronat realizate în varianta color. În schimb, reprezentarea grafică a indicatorilor economici
se pretează la utilizarea marcării prin culori.
Cel puţin în privinţa monitoarelor, s-a constatat că 8% din bărbaţii Europei şi Americii
de Nord au probleme cu vederea din cauza folosirii culorilor. Varianta alb-negru este mult
mai odihnitoare pentru privire, dar nu şi mai plăcută întotdeauna. De aceea se sugerează
proiectarea în varianta alb-negru, rămânând la latitudinea utilizatorului ce culori foloseşte.
Se recomandă, de asemenea, apelarea la un număr cât mai redus de culori, doar pentru a
evidenţia anumite elemente şi pentru formatarea informaţiilor.
În ceea ce priveşte textele, care în orice condiţii de lucru au o pondere substanţială în

ieşirile sistemelor, se recomandă câteva reguli:
Caracterele: Se recomandă folosirea literelor mari şi mici, inclusiv respectarea regulilor de
punctuaţie.
Spaţierea: Dacă este posibil, este de dorit folosirea dublei spaţieri. Dacă nu, se recomandă
plasarea unei linii cu spaţii între paragrafe.
Alinierea: Se recomandă alinierea textului la stânga şi, dacă nu se poate rezolva altfel,
partea dreaptă poate fi neregulată.
Liniuţa de În textele ecranelor, ale rapoartelor nu se recomandă despărţirea cuvintelor în
unire: silabe de pe un rând pe altul.
Abrevierile: Nu se recomandă folosirea abrevierilor pentru cuvinte care nu au o recunoaştere
generală.

7. Benbasat, I., Dexter, A.S., Todd, P. – op. cit.; Shneiderman, B. – op. cit.; Dumas, J. S. – op. cit.
29

TA 2.1
1. Care sunt recomandările de proiectare a părţii de titlu a unei ieşiri?
2. Prezenaţi 3 situaţii în care este recomandată evidenţierea unor informaţii dintr-o
mulţime dată. Argumentaţi necesitatea evidenţierii.
3. Daţi un exemplu de formular în care să fie aplicate cel puţin trei forme de evidenţiere
(marcare) a unor informaţii.
Răspuns:

2.1.3 Reguli specifice de proiectare a rapoartelor în formă tabelară

Majoritatea ieşirilor din sistemele informaţionale economice au formă tabelară.

Tabelele au şi ele un tratament riguros, formatul de editare fiind foarte important. Ca şi
informaţiile prezentate prin text, şi cele din tabele trebuie să respecte anumite reguli,
devenite în timp standarde, prezentate în tabelul 1.4.

Tabel nr. 1.4 – Reguli generale de afişare a tabelelor

Folosirea unor nume semnificative:
Toate coloanele şi rândurile să aibă nume (etichete) cât mai relevante.
Numele respective vor fi scoase în evidenţă faţă de celelalte prin tehnicile corespunzătoare,
descrise anterior.
Reafişarea numelor coloanelor sau rândurilor când datele depăşesc limitele paginii.
Evitarea numelor lungi, a ambiguităţilor generate de sensul cuvintelor folosite.
Pe cât posibil, de renunţat la despărţirea în silabe, recomandare întâlnită şi la texte.
Centrarea, în cele mai multe cazuri, a numelor coloanelor şi alinierea la stânga a numelor
rândurilor.
Formatarea coloanelor, a rândurilor şi a textului:
Sortarea într-o ordine logică a datelor prezentate, după una sau două chei, ascendent sau
descendent.
Folosirea unei linii cu spaţii după fiecare cinci rânduri atunci când există prea multe
coloane.
Informaţiile similare afişate în mai multe coloane trebuie să fie sortate pe verticală, întrucât
ordinea lor se urmăreşte pe coloană, deci de sus în jos, şi nu de la stânga la dreapta, pe
linie.
Între coloane trebuie să existe cel puţin două spaţii.
De lăsat loc suficient pe rapoartele tipărite care să-i permită utilizatorului să introducă
diverse adnotări.
De folosit acelaşi gen de caractere, cu excepţia cazurilor care trebuie să fie scoase în

evidenţă.
De evitat excesele de fonturi fanteziste, greu de citit.
Formatarea datelor de tip numeric, alfabetic sau alfanumeric:
Datele numerice trebuie să fie aliniate la dreapta şi/sau pe marca zecimală, coloanele fiind
astfel uşor de citit.
Datele de tip text vor fi aliniate la stânga.
Se recomandă folosirea liniilor scurte de text, de regulă de 30-40 de caractere, pentru o
parcurgere uşoară prin citire. Aceasta este şi dimensiunea standard a coloanelor de ziar.
De evitat blocurile mari cu date alfanumerice. În astfel de cazuri trebuie găsite criterii de
descompunere a lor în grupuri mai mici, mai uşor de citit, deci şi mai inteligibile, care să nu
aibă mai mult de 3-4 caractere, gen numere auto sau de telefon (0232-212-131).

La proiectarea rapoartelor în format tabelar se vor lua în considerare zonele specifice,
regăsite în toate generatoarele de rapoarte, întâlnite în multe sisteme de gestiune a bazelor
de date. Aceste zone, prezentate şi în raportul din figura 1.6, sunt (redăm şi denumirea lor
în limba engleză, pentru o mai bună recunoaştere a lor în generatoarele de rapoarte):
Antetul şi sfârşitul raportului (Report Header şi Report Footer). Fiecare raport
trebuie să aibă un antet şi un sfârşit. Antetul raportului va conţine elementele care
apar o singură dată, la începutul raportului. Aici se includ, de obicei, titlul
raportului, data obţinerii şi numele destinatarului. În zona de sfârşit a raportului
sunt prevăzute totalurile generale pentru câmpurile numerice şi, eventual, numele
persoanelor responsabile de generarea lui, precum şi ale celor care îl certifică.
Antetul şi sfârşitul paginii (Page Header şi Page Footer). În aceste zone vor fi
incluse elementele raportului care apar pe fiecare pagină, la începutul sau la
sfârşitul ei. Pentru fiecare raport, numele coloanelor trebuie prevăzute în antetul de
pagină, astfel încât ele să fie afişate la începutul fiecărei pagini. Numărul paginii şi
numele raportului pot să apară în zona de antet sau cea de sfârşit al paginii. Tot
aici sunt incluse totalurile la nivel de pagină.
Antetul şi sfârşitul grupului (Group Header şi Group Footer). Aceste două zone
vor fi prevăzute numai în rapoartele în care se doreşte gruparea liniilor cu date
după unul sau mai multe câmpuri de control. În exemplul din figura 1.6, vânzările
sunt grupate pe clienţi, iar codul clientului reprezintă câmpul de control.
Elementele incluse în aceste zone apar o singură dată pentru fiecare grup de date,
deasupra primei linii cu date din grup, respectiv sub ultima linie din grup. În antet
se includ, de regulă, datele de identificare ale grupului adică, în exemplul nostru,
codul şi numele clientului. În zona de sfârşit se pot afişa totalurile sau rezultatele
altor operaţiuni de agregare la nivelul grupului, precum numărul elementelor,
valoarea medie, minimă şi maximă pentru câmpurile numerice.
Linia de detaliu (Detail) . Este zona principală a oricărui raport şi conţine
câmpurile care vor forma o linie cu informaţii. În această zonă sunt afişate date
extrase din bază sau informaţii calculate pe baza acestora. Pentru fiecare
înregistrare prelucrată din baza de date se va crea câte o linie.
La construirea tabelelor se pot lua în considerare şi următoarele recomandări, adaptate
după Publication Manual of the American Psychological Association, ediţia a 3-a, care pot
fi urmărite şi cu ajutorul figurilor 1.7 şi 1.8. Există şi alte metode de prezentare a tabelelor,
dar cea a Asociaţiei Americane de Psihologie constituie referinţa.
31

Date identificare grup

Departamentul Desfacere
Antet
Situaţia vânzărilor pe clienţi în perioada 01/01/2006 - 28/02/2006 raport

Data: 15/03/2006

N
Nr.
r.r. Fa
Factura
Fac
ctura
ura Comanda Coman
omanda
da Valoare
Antet pagina
crt. Valoa
Număr
Valoare
re crtrt.Data
. N
Număr
umărumăr Data Data
CodNclient:
umărumăr Datclient:
1234, Nume a ALFA srl Antet grup
1 Cod clien
lientt: 1234,13-ian-2006
458992 Nume clien
lientt: ALF
LFA srlrl
A1212 5-ian-2006 72.000.000
1
2 458992
459025 13
13--ia
ian
n-2006
13-feb-2006 1212
1875 5-ia
ian
n-2006
6-feb-2006 72.000.000
57.000.000
2
3 459025
459220 13
13--feb-2006
22-feb-2006 1875
1899 6-feb-2006
11-feb-2006 57.000.000
112.000.000 Linie detaliu
3
4 459220
459758 22
22--feb-2006
23-feb-2006 1899
2543 11
11--feb-2006
13-feb-2006 112.000.000
43.000.000
4 Total client
459758 23
23--feb-2006 2543 13
13--feb-2006 284.000.000
43.000.000 Sfârsit grup

Totota
Cod al client
client: nt Nume client: BETA sa
1235, 284.000.000

5 Cod clien
lientt: 1235,13-ian-2006
458891 Nume clien
lientt: BETA
ETA sa
1211 4-ian-2006 14.500.000
5
6 458891
458999 13
13--ia
ian
n-2006
18-ian-2006 1211
1256 4-ia
ian
n-2006
10-ian-2006 14.500.000
29.850.000
6
7 458999
459112 18
18--ia
ian
n-2006
20-feb-2006 1256
1301 10
10--ia
ian
n-2006
10-feb-2006 29.850.000
44.000.000
7 459112
Total client 20
20--feb-2006 1301 10
10--feb-2006 44.000.000
88.350.000
Totota
Totalalgeneral
clientnt 88.350.000
372.350.000 Sfârsit raport

Pagina 1 din 1 Sfârsit pagina

Fig. 1.6 Zonele întâlnite în rapoartele în format tabelar

În figura 1.7 sunt prezentate elementele componente ale unui tabel şi modul lor de
organizare, iar în figura 1.8 oferim un exemplu pentru a reliefa aspectele teoretice care stau
la baza construirii tabelelor.

(1) Numărul tabelului

(2) Titlul tabelului
(3) Linie desenată
(6) Titlul coloanelor multiple
(4) Titlul cotorului (5) Titlul coloanei Titlul coloanei
(7) Titlul liniei
(8) Subtitlu Date Date
Subtitlu Date Date
Titlul liniei Date Date
(3) Linie desenată
(9) Sursa:
(10) Note explicative

Fig. 1.7 Elementele de bază ale unui tabel

Pentru realizarea unui tabel, aşa cum se observă şi din figurile 1.7 şi 1.8, trebuie luate
în considerare zece elemente esenţiale, şi anume:
(1) Numărul tabelului: se va atribui consecutiv, în ordinea apariţiei, pe parcursul
întregului raport, sub forma numerelor arabe. Numărul se va scrie la marginea din stânga,
apelând la metoda numerelor duble (de exemplu, 2.3) numai în rapoartele lungi, care
conţin mai multe capitole, fără a se pune punct după ultimul grup de numere. Numărul şi
titlul se vor plasa deasupra tabelului, iar elementele suplimentare în zona imediat următoare
sub tabel.

(1) Tabel 1
(2) Costul de producţie pe produs

(3)
(6) Tipul produsului
(5) AC DC
(4) Costuri iniţiale
(7) Componenta de bază1 $ 76,000 $ 110,000
(8) Dispozitiv auxiliar-1 1,500 -
Dispozitiv auxiliar-2 2,000 -
Instalare 23,000 12,000
Total $ 102,500 $ 122,000
(3)
(9) Sursa: Smith, J.K., Speed Drives, Production Journal, iulie, 1977, 52.
(10) 1 în ambele variante se oferă un an garanţie

Fig. 1.8 Exemplu de tabel cu prezentarea elementelor componente

(2) Titlul tabelului trebuie să identifice, cât mai concis, datele înregistrate în tabel. Ca
şi numărul tabelului, titlul va fi scris la marginea din stânga, la două rânduri sub număr.
Formatul în care se va scrie titlul este următorul: prima literă a titlului şi pentru
substantivele proprii se vor scrie cu literă mare, iar celelalte cuvinte cu litere mici. Dacă
titlul necesită şi o a doua linie, se va începe tot din marginea din stânga, la două rânduri sub
prima linie de titlu. Nu se va pune punct după titlu.
(3) Liniile tabelului. În general, tabelele au trei linii orizontale şi nici o linie verticală.
Dacă raportul este mai mult informal, se va apela la cât mai puţine linii sau chiar la nici
una. Ultima linie din tabel va delimita conţinutul acestuia de elementele suplimentare
ataşate, cum ar fi sursa tabelului şi notele explicative.
(4) Titlul cotorului (capetele de linii) este folosit pentru a denumi coloana în care vor fi
înregistrate numele variabilelor comparate în cadrul tabelului.
(5) Titlul coloanelor defineşte datele înscrise în coloanele respective.
(6) Titlul coloanelor multiple este folosit ca nume comun pentru coloanele situate sub
el, pentru a se reduce repetiţiile ce ar putea apărea în titlul fiecărei coloane.
(7) Titlul liniei identifică conţinutul rândului de date din dreapta primei coloane în care
se găseşte. Dacă este necesar, titlul liniei poate fi descompus în două sau mai multe
subtitluri, caz în care nu se vor înregistra date în dreptul liniei de titlu.
(8) Subtitlul defineşte conţinutul elementelor plasate pe rândurile imediat următoare
variabilei pe care o formează, fiind plasat sub titlul liniei şi evidenţiat prin indentare
(scriere adâncită, mai spre dreapta).
(9) Sursa este folosită pentru a indica originea datelor preluate. În cazul în care datele
au fost citate dintr-un material, se vor preciza cu exactitate autorul, titlul materialului, locul
şi anul apariţiei, eventual numărul paginii. Dacă datele provin dintr-o altă sursă decât
materiale publicate, se va specifica locul de unde au fost preluate (de exemplu, Sursa: Date
preluate de la Departamentul Producţie). Dacă sunt necesare comentarii asupra tabelului,
acestea se vor realiza între ultima linie trasată şi sursă, folosind cuvântul Notă, urmat de
comentariile respective.
(10) Notele explicative sunt destinate explicaţiilor privind anumite zone ale tabelului.
Se va face trimitere la aceste note prin litere mari sau mici atât în cadrul tabelului, cât şi la
începutul notei explicative.
33

TA 2.2
1. Enumeraţi şapte reguli de afişare a tabelelor.
2. Ce elemente ale unui raport pot fi incluse în antet (Page header)?
3. Daţi un exemplu de raport care să conţină un grup de date şi evidenţiaţi zonele
specifice rapoartelor în format tabelar.
Răspuns:

2.1.4 Reguli specifice de proiectare a graficelor

Deseori, există dispute între specialişti privind superioritatea graficelor în comparaţie

cu tabelele. Din mai multe privinţe, graficele sunt mai edificatoare. Dintre acestea amintim:
O imagine este mai sugestivă decât 1 000 de cuvinte, afirmă specialiştii.
Se prezintă o sinteză riguroasă a datelor.
Marcarea celor mai importante elemente.
Excepţiile sunt uşor de sesizat.
Evidenţiază eventualele corelaţii dintre elemente.
Se poate aprecia tendinţa în timp.
Se pot efectua comparaţii multiple rapide.
Se oferă şansa efectuării de prognoze.
Cu ajutorul unui grafic pot fi vizualizate mult mai simplu cantităţi imense de date
valorice.

Tipuri de grafice corelate cu datele reprezentate

Atunci când se apelează la forma grafică de reprezentare a informaţiilor este necesar să

se selecteze mai întâi tipul cel mai potrivit de grafic (histogramă, histogramă cumulată,
linie, diagramă de structură), care depinde de tipul informaţiilor pe care le va conţine.
Datele pot să aparţină fie unei serii discrete, fie unei serii continue. Diferenţa dintre cele
două categorii constă în faptul că seriile continue conţin date care se schimbă în timp (de
exemplu, populaţia unui oraş în momente diferite), iar seriile discrete – date similare de la
entităţi diferite (de exemplu, populaţia a trei oraşe la un anumit moment).
Graficele linie sunt cele mai potrivite pentru redarea seriilor continue. Graficele stivă
de bare (histogramă cumulată) şi tip pie sunt reprezentative pentru seriile discrete. Graficul
tip pie (diagramă de structură) este folosit pentru a scoate în evidenţă ponderea părţilor în
întreg.

Recomandări generale pentru construirea graficelor

În rapoarte, graficelor li se atribuie un număr şi un titlu, indiferent de tip.
Referirea la grafice se va face, în general, ca şi la figuri, numerotându-le secvenţial
de-a lungul raportului, cu numere arabe.
Se va plasa cuvântul Figura şi numărul corespunzător la marginea din stânga
paginii, numărul fiind urmat de punct şi alt număr, dacă se prezintă figurile pe
capitole, de genul x.y.
Titlul graficului va începe imediat după număr, fără a fi subliniat şi fără a se pune
punct după el. Dacă sunt necesare două linii pentru redarea titlului, cea de-a doua
linie va începe tot din marginea din stânga, la două rânduri distanţă sub prima linie.
Se va indica sursa datelor prin plasarea cuvântului Sursă sub numărul şi numele
graficului, urmat de citarea sursei.
În rapoartele informale, realizatorii lor, deseori, plasează titlul dedesubt sau deasupra
figurii, după cum poate fi obţinută o imagine mai clară şi în funcţie de formatul
paginii.
De multe ori, graficele sunt folosite pentru a prezenta aceleaşi date statistice conţinute
de un tabel. Multe produse-program oferă posibilitatea generării automate a graficelor pe
baza datelor ce au fost introduse în diferite tabele. Graficele prezintă informaţiile într-un
mod mult mai concludent decât tabelele. Totuşi, sunt cazuri când graficele nu redau situaţia
la fel de exact aşa cum se întâmplă când se apelează la tabele. Altfel spus, uneori, graficele
sunt mai puţin elocvente decât tabelele, ceea ce impune alegerea celei mai bune variante,
tabel sau grafic, care să uşureze înţelegerea datelor de către utilizator.
Aşadar, tabelele nu pot lipsi din majoritatea aplicaţiilor economice, unde nu
semnificaţia unui fenomen sau a unui proces este relevantă, ci valoarea concretă a datelor.
În acest caz, când trebuie să fie descrise valori individuale, tabelele sunt de neînlocuit. În
astfel de situaţii, recomandăm apelarea la tabele landscape (pe lungimea foii A4). Numărul
coloanelor poate fi mai mare, iar regulile amintite anterior pot fi respectate mult mai uşor.

2.1.5 Reguli pentru controlul confidenţialităţii, integrităţii şi accesibilităţii
ieşirilor

Aşa cum am văzut anterior, una dintre caracteristicile ieşirilor, care trebuie luată în
considerare la formularea specificaţiilor de proiectare, se referă la controlul ieşirilor.
Obiectivul urmărit la proiectarea ieşirilor constă în asigurarea completitudinii, oportunităţii
şi exactităţii informaţiilor conţinute, precum şi restricţionarea accesului pentru persoanele
35

neautorizate. Odată ce au fost generate, ieşirile sunt dificil de controlat, deoarece numărul
mecanismelor de control este redus, fiind aplicabile doar procedurile de control fizic. De
aceea, este recomandată aplicarea procedurilor de control înainte de generarea şi distribuirea
ieşirilor.
Poate cea mai eficace procedură pentru controlul ieşirilor constă în limitarea accesului
la sistemul informaţional, prin definirea utilizatorilor autorizaţi şi a drepturilor de acces ale
fiecăruia. În acest fel, se asigură un anumit nivel de control în ceea ce priveşte ieşirile, ele
putând fi accesate doar de persoanele cu drepturi de acces în sistem.
Cu toate acestea, sunt necesare unele controale care să-i vizeze pe utilizatorii
sistemului. În acest sens, pot fi aplicate două proceduri: controlul distribuirii ieşirilor şi
separarea atribuţiilor.
Controlul distribuirii ieşirilor vizează permiterea accesului la rapoarte doar
utilizatorilor cărora le sunt destinate. În trecut, majoritatea ieşirilor erau tipărite pe hârtie,
prin folosirea unei singure imprimante la nivelul întregii firme. Controlul distribuirii
ieşirilor era centralizat la nivelul unui birou special, unde utilizatorii autorizaţi puteau
solicita pe cele care le erau destinate.
Progresele tehnologice înregistrate, dezvoltarea pe scară largă a sistemelor
client/server, au determinat unele mutaţii, precum integrarea sistemelor informatice,
preferinţa pentru afişarea rapoartelor pe ecran în detrimentul tipăririi lor, dotarea fiecărui
departament cu imprimante. În noile condiţii, controlul ieşirilor se bazează mai mult pe
procedurile logice decât pe cele fizice. Foarte utilă este întocmirea unei liste pentru
controlul distribuirii, în care se vor specifica utilizatorii autorizaţi pentru fiecare ieşire în
parte, eventual şi staţia de lucru de pe care poate fi generată şi accesată. Implementarea
acestei liste impune gestionarea, în cadrul aplicaţiei, a drepturilor de acces pentru fiecare
ieşire, dar şi o bună coordonare între aplicaţie şi sistemul de securitate din reţeaua de
calculatoare a firmei.
Separarea responsabilităţilor presupune crearea unor activităţi separate care să fie
realizate de angajaţi diferiţi, identificându-se activităţile care, dacă ar fi realizate de acelaşi
angajat, ar crea condiţii pentru realizarea de fraude. Separarea atribuţiilor se realizează la
nivelul diferitelor funcţii ale sistemului, vizate fiind, în mod deosebit, cele care privesc
crearea şi generarea ieşirilor. De exemplu, preluarea comenzilor de la clienţi şi înregistrarea
lor în sistem ar trebui separată de generarea documentelor privind livrările, cele două
activităţi trebuind realizate de două persoane diferite. Altfel, va fi posibilă efectuarea unor
livrări frauduloase. De asemenea, înregistrarea anumitor tipuri de tranzacţii şi obţinerea
rapoartelor, pe baza cărora se va verifica corectitudinea şi completitudinea înregistrărilor
care privesc acele tranzacţii, trebuie realizate de persoane diferite. Un alt exemplu se referă
la separarea funcţiei de scriere a programului pentru generarea unei ieşiri, de cea care
priveşte utilizarea programului respectiv.
Corectitudinea, completitudinea şi oportunitatea informaţiilor furnizate de sistem
depind, în cea mai mare măsură, de procesele interne de prelucrare, şi mai puţin de
aplicarea unor proceduri de control. Totuşi, analistul are la dispoziţie câteva astfel de
proceduri, pe care trebuie să le ia în considerare la proiectarea fiecărei ieşiri, după cum
urmează:
includerea, în antetul rapoartelor, a datei la care au fost generate;
formularea clară a titlului raportului, în care să fie precizată perioada de timp
acoperită de informaţiile conţinute;
includerea numelui destinatarului în antetul rapoartelor;

numărul de pagină să fie în formatul „pagina din ”;
prevederea unor totaluri de control, ori de câte ori este posibil;
afişarea numărului de înregistrări prelucrate.

2.2 Demersul proiectării ieşirilor

Atât formularele/formatele proiectate a fi realizate cu ajutorul calculatorului, cât şi
rapoartele constituie cele mai interesante piese ale sistemului pentru utilizatorii acestuia.
Demersul proiectării ieşirilor trebuie astfel conceput încât să permită implicarea directă şi
eficientă a utilizatorilor. De aceea, proiectarea ieşirilor trebuie să se realizeze după un
anumit procedeu-cadru, specific prototipizării8, conform figurii 1.10.

Identificarea Cerinţele iniţiale Realizarea

problemei prototipului

Conversia în Prototip în lucru
operaţional
sistem opera ional
Alte cerinţe
Dacă prototipul
este eficient
Problema
Implementare Prototip revizuit
şişi folosirea
folosirea Altă versiune şi îmbunătăţit
îmbună ă it
prototipului
Fig. 1.10 Metodologia prototipizării

În proiectarea ieşirilor, analistul trebuie să elaboreze un model demonstrativ al

raportului sau ecranului şi să întrebe utilizatorul dacă informaţiile din raport şi formatul
acestuia sunt acceptabile. Utilizatorului trebuie să i se acorde suficient timp pentru a studia
ieşirile, astfel încât să fie sigur că i se oferă ceea ce a cerut, că nu sunt adăugate informaţii
de prisos şi că ieşirile sunt redate în cea mai plăcută formă. Dacă ieşirile sunt inacceptabile,
analistul trebuie să le modifice şi să i le dea din nou utilizatorului pentru a le revedea.
Acest pas este atât de important încât multe organizaţii cer utilizatorilor să semneze un
document prin care să se consemneze că forma şi conţinutul rapoartelor propuse sunt
acceptate de către ei. Procedura asigură astfel evitarea cheltuielilor şi a timpului suplimentar
impuse de eventualele schimbări ulterioare.
În timpul procesului de proiectare a formularelor şi rapoartelor trebuie să se găsească
răspunsuri la întrebările: cine, ce, când, unde, cum, conform următorului model:
Cine este beneficiarul formularului/formatului, raportului sau răspunsului la
întrebări?
Ce trebuie să conţină formularul/formatul, raportul sau răspunsul la întrebări?
Când se solicită obţinerea ieşirilor?
Unde să fie transmis formularul/formatul, raportul sau răspunsul la întrebări şi unde
să fie folosit?
Cum se vor utiliza ieşirile respective? Câte persoane le vor folosi sau le vor vedea?
După culegerea tuturor informaţiilor în legătură cu ieşirea de proiectat, se va da forma
unui prototip al acesteia. Într-o astfel de fază, dialogul cu utilizatorul nu mai este atât de

8. Naumann, J.D., Jenkins, A.M. – „Prototyping: The New Paradigm for Systems Development”, in MIS Quarterly, 6 (3),
1993, pp. 29-44.
37

intens, deşi unele păreri ale sale sunt luate în considerare. Totuşi, după obţinerea
prototipului, utilizatorul este cel ce se va pronunţa asupra calităţii acestuia, cerând fie
acceptarea în forma primită, fie efectuarea unor corecţii. În cazul corecţiilor, se parcurg
paşii specifici prototipizării: construcţie-evaluare-rafinare în ciclu, până când sunt rezolvate
toate cerinţele utilizatorului. De regulă, acest ciclu este reluat de câteva ori. De fiecare dată,
utilizatorul este cel ce va declanşa procesul.
Construcţia prototipului iniţial poate fi realizată în diverse medii. În faza în care ne
aflăm, se poate vorbi de o „ciornă” a formularelor/ formatelor, rapoartelor sau ecranelor,
ele fiind privite doar ca structură şi machetă. Ne aflăm doar în faza de proiectare logică,
detaliile privind modul de obţinere a ieşirilor respective vor fi oferite mai târziu. Ceea ce ne
propunem acum poate fi realizat cu un procesor de texte, un produs-program orientat spre
grafică sau cu un program de calcul tabelar. Opţiunea la modă se îndreaptă spre
instrumentele CASE sau cele standard pentru un astfel de obiectiv.
Atunci când utilizatorul evaluează performanţele formularelor/formatelor sau
rapoartelor, operaţiunea se referă la câteva aspecte esenţiale, şi anume: viteza cu care se
efectuează o activitate, precizia rezultatelor obţinute, satisfacţia folosirii ieşirilor respective.
În afara performanţei, utilizatorul priveşte ieşirile şi din alte puncte de vedere, care pot
fi prezentate astfel:
Stabilitate – Stabilitatea sau consistenţa presupune folosirea aceloraşi termeni,
abrevieri, formate, titluri şi metode de navigare în toate ieşirile sistemului.
Eficienţa – Atunci când se efectuează formatarea ea trebuie să se deruleze în strânsă
concordanţă cu sarcinile de executat. Textele trebuie să fie aliniate, coloanele
sortate, deplasarea să fie uşor de realizat. Pe cât este posibil, ar trebui să fie evitate
introducerile de date necesare obţinerii ieşirilor.
Comoditate – Să nu se facă trimiteri la afişări anterioare, să se folosească etichete
clare, precum şi factori de scală corespunzători.
Format – Formatul informaţiilor trebuie să se menţină pentru aceleaşi tipuri de date
şi să scoată în evidenţă ceea ce este important. Se recomandă folosirea, printre
caracterele tipărite, a semnelor monetare, a mărcilor zecimale, a separatorilor
ordinelor de mărime şi a semnelor +, –, % în mod corespunzător.
Flexibilitate – Trebuie să i se ofere utilizatorului posibilitatea de a lista în modurile
dorite de el, de a opri procesul şi de a naviga în locurile dorite.
În concluzie, specialiştii spun că satisfacţia în utilizare s-ar putea rezuma la: timpul de
învăţare (acomodare), viteza în execuţie, rata erorilor, persistenţa în timp (stabilitatea),
satisfacţii subiective. Culegerea informaţiilor despre toate aceste considerente o efectuează
echipa de proiectare şi realizare, prin tehnicile descrise anterior în etapa de analiză a
sistemelor.

TA 2.3
1. Explicaţi, pe baza unui exemplu, în ce constă aplicarea separării responsabilităţilor
pentru controlul confidenţialităţii şi integrităţii ieşirilor în sistemele informaţionale.
2. Cum poate fi implicat utilizatorul în proiectarea ieşirilor informaţionale?
3. În ce constă stabilitatea rapoartelor din punctul de vedere al utilizatorului?
Răspuns:

2.3 Formularea specificaţiilor de proiectare a ieşirilor

Ca şi în cazul altor etape sau subetape, trebuie să luăm în discuţie şi produsele etapei
de faţă. Ele sunt sintetizate în specificaţii de proiectare a formularelor şi rapoartelor,
structurate astfel:
prezentarea descriptivă a ieşirii;
un model al proiectului;
testarea şi evaluarea comportamentului în utilizare.
În secţiunea rezervată prezentării descriptive a ieşirii, trebuie specificate toate
elementele relevante de proiectare, care privesc caracteristicile discutate anterior, în acest
capitol: scopul şi destinatarii, frecvenţa, formatul şi conţinutul, sursa datelor, mediul de
generare şi controlul. În cea de-a doua secţiune este prezentat prototipul, din care reiese
forma ieşirii respective. În ultima secţiune, sunt prezentate rezultatele evaluării prototipului
de către utilizatori. În acest sens, va fi cuantificată percepţia utilizatorilor în legătură cu
aspectele esenţiale ale ieşirii, aspecte prezentate în finalul paragrafului anterior.
Un model de specificaţie pentru raportul „Situaţia vânzărilor …” este prezentat în
figura 1.11.
Pentru sursa datelor, specificaţiile de proiectare pot fi completate prin descrierea
câmpurilor ce vor fi accesate din fiecare tabelă a bazei de date. Asupra acestui aspect vom
reveni în capitolul destinat proiectării fizice a bazei de date. De asemenea, specificaţiile de
proiectare a secvenţei de dialoguri, prin care utilizatorul va interacţiona cu sistemul pentru
obţinerea raportului, vor fi prezentate în capitolul următor.
39

Specificaţiile de proiectare pentru raportul
“Situaţia vânzărilor de produse finite pe gestiuni şi factur i”
a) Prezentare descripti vă
Scop: - Întocmirea şi verificarea notei contabile privind vânzările .
- Controlul ieşirilor de produse finite din depozite .
Utilizatori: Economistul r esponsabil cu evidenţa produselor f inite .
Conţinut: 1. Gruparea datelor - pe gestiuni şi facturi
- pe gestiuni şi produse .
2. Ordonarea datelor - pe gestiuni si facturi sau pe gestiuni şi produse, în
funcţie de modul de grupare dorit, şi apoi după denumirea
produsului sau numărul facturii.
3. Totaluri solicitate – la nivel de gestiuni, facturi/produse şi raport.
4. Alte menţiuni – raportul va conţine date privitoare la o singură
gestiune, aleasă de utilizator, sau pentru toate gestiunile;
perioada de timp va fi tot la alegerea utilizato rului.
- denumirea gestiunii va fi afişată o singură dată, în
prima linie a grupului, precum şi în prima linie de detaliu a fiecărei
pagini.
Mediul de generare: Raport ul va fi tipărit sau afişat pe ecran.
Frecvenţa: Raportul va fi generat lunar, în primele 5 zile ale lunii, sau la cerere.
Sursa datelor: Se vor accesa tabelele GESTIUNE, PRODUS, VANZARE şi
ARTICOLV ANZARE din baza de date.

b) Modelul proiectului
Departamentul Contabilitate

Situaţia vânzărilor pe gestiuni şi facturi
în perioada 01/01/2006 - 31/01/2006

Emis de Ionescu Ionela Data: 02.02.2006
Factura
Factura Produs Preţ
Preţ Cantitate
Cantitate Valoare
Valoare
Număr Data Cod Denumire UM unitar
Depozitul nr. 1
18795
18795 05.ian.06
05.ian.06 110220
110220 Sacou
Sacou tip
tip A
A buc
buc 124,00
124,00 10,00
10,00 1.240,00
1.240,00
110228 Costum Bărb. buc 322,00 8,00 2.576,00
110236 Pantaloni EST per 45,00 12,00 540,00
110250 Camaşă SV buc 81,00 12,00 972,00
Total factură 5.328,00
18801
18801 09.ian.06
09.ian.06 110220
110220 Sacou
Sacou tip
tip A
A buc
buc 124,00
124,00 5,00
5,00 620,00
620,00
110244 Sacou tip E buc 76,00 5,00 380,00
Total depozit 6.328,00
Depozitul nr. 2
21544
21544 13.ian.06 110267
13.ian.06 110267 Pijama
Pijama cod
cod 21
21 set
set 67
67 25,00
25,00 1.675,00
1.675,00
110275 Rochie MD 11 buc 85 10,00 850,00
21545
21545 20.ian.06
20.ian.06 110283
110283 Maieu
Maieu barb.
barb. buc
buc 15
15 100,00
100,00 1.500,00
1.500,00
110267 Pijama cod 21 set 67 20,00 1.340,00
110275 Rochie MD 11 buc 85 25,00 2.125,00
Total depozit 7.490,00
Total general 13.818,00

Pagina 1 din 1

c) Testarea şi evaluarea comportamentului la utilizare
Nivelul de percepţie al utilizatorilor (cca. 8 utilizatori):
Consistenţa (de la 1 – consistent la 5 – inconsistent): 1,60
Flexibilitate (de la 1 – flexibil la 5 – inflexibil): 1,85
Precizia (de la 1 – precis la 5 - imprecis): 1,53
...

Fig. 1.11 Model de specificaţie de proiectarea ieşirilor


TA 2.1 1) Prezentarea foarte clară a titlului ieşirii în partea superioară a paginii, central;
evidenţierea numărului şi/sau datei; locul în care este distribuit; specificarea datei de emitere
a ieşirii; consemnarea orei editării. 2) Vezi p. 25. 3) Casete cu date grupate, diferenţieri
prin fonturi, subliniere – vezi fig. 1.5.
TA 2.2 1) Vezi tabelul 1.4. 2) Numele coloanelor, numărul paginii, totaluri de pagină preluate
de pe pagina anterioară, titlul raportului. 3) vezi fig. 1.6.

TA 2.3 1) Vezi p. 34. 2) Se aplică procedeul prototipizării în proiectaraea rapoartelor. 3) Să se
utilizeze aceeaşi termeni, abrevieri, formate, titluri şi metode de navigare în toate ieşirile
sistemului.


1) In zona de sfarsit a unui raport in format tabelar se includ urmatoarele elemente:
a) totalurile generale pentru campurile numerice
b) numarul total de pagini
c) numarul paginii
d) numele persoanelor responsabile de generarea sau certificarea lui

2) Care dintre urmatoarele tipuri de grafice sunt potrivite pentru reprezentarea seriilor discrete
de date?
a) stiva de bare
b) diagrama de structura (pie)
c) piramidale
d) nor de puncte
e) linie

3) La proiectarea rapoartelor in forma tabelara se recomanda includerea unei linii cu spatii
dupa fiecare cinci randuri in urmatoarele situatii:
a) exista blocuri mari cu date alfanumerice
b) exista prea multe pagini in raport
c) exista prea multe linii cu date pe o pagina
d) exista prea multe coloane

1. Enumeraţi şi descrieţi succint 10 reguli de proiectare a rapoartelor tipărite.
2. Prezentaţi un exemplu de grafic prin care să se reprezinte o serie de valori discrete.
Precizaţi regulile de proiectare folosite.
3. Întocmiţi specificaţiile de proiectare pentru un raport programat, care să conţină un grup de
date.

2.6 Bibliografie

Jersey, 2001, pp. 307-321
3. Romney, M.B., Steinbart, P.J., Accounting Information Systems, Pearson Education Inc.,
New Jersey, 2003, pp. 662-664


Concepte generale privind interfeţelor utilizator

Obiective:
Evidenţierea importanţei interfeţei utilizator în dezvoltarea sistemelor informaţionale
economice
Definirea conceptului de interfaţă utilizator
Prezentarea metodelor de interacţiune şi a echipamentelor folosite în dialogul om-
calculator
Explicarea manierei în care pot fi identificate interfeţele utilizator
Alegerea metodelor de interacţiune om-calculator în funcţie de cerinţele sistemului
Selectarea echipamentelor folosite în dialogul om-calculator în sistemele informaţionale
Formularea cerinţelor privind dialogul om-calculator în sistemele informaţionale contabile

3.1 Rolul interfeţelor utilizator în dezvoltarea sistemelor informaţionale................................... 42
3.1.1 Definirea conceptului de interfaţă................................................................................... 42
3.1.2 Identificarea interfeţelor utilizator .................................................................................. 44
3.2 Metode şi echipamente folosite în dialogul om-calculator .................................................... 46
3.2.1 Metode de interacţiune om-calculator............................................................................. 47
3.2.2 Selectarea echipamentelor necesare interacţiunii cu sistemul ........................................ 55
3.5 Bibliografie ............................................................................................................................ 57

Intrările şi ieşirile în/din sistemele informaţionale au fost identificate şi descrise în faza
de analiză, iar elementele de proiectare a lor au fost discutate în unităţile anterioare. Au fost
prezentate conţinutul specificaţiilor de proiectare a formularelor/formatelor şi a rapoartelor,
regulile şi demersul de proiectare a lor.
Preluarea intrărilor în sistem şi obţinerea ieşirilor se pot efectua în mod automat, însă,
în majoritatea situaţiilor, ele implică intervenţia omului, ceea ce determină existenţa
interacţiunilor dintre utilizator şi calculator. Pentru fiecare intrare se va proiecta un ecran
care să permită utilizatorilor să introducă datele de intrare. Fiecărei ieşiri îi va corespunde o
succesiune de dialoguri prin care utilizatorii vor putea să le genereze. De asemenea,
utilizatorii vor interacţiona cu calculatorul în vederea iniţierii operaţiunilor de prelucrare,
scop în care se va proiecta un sistem de meniuri. Toate aceste aspecte nu au fost luate în
considerare anterior, ele fiind tratate în continuare, în această unitate de studiu şi
următoarele două.

3.1 Rolul interfeţelor utilizator în dezvoltarea
sistemelor informaţionale

Proiectarea interfeţelor reprezintă o activitate foarte importantă în dezvoltarea
sistemelor informatice, chiar critică, din perspectiva acceptării sistemului de către
utilizatori. Acest lucru este explicabil, dacă ţinem cont de faptul că interfaţa utilizator
reprezintă acea parte a sistemului pe care acesta o percepe în mod direct, cu care el
interacţionează pentru a-şi realiza sarcinile de lucru. Pe de altă parte, interactivitatea este
una dintre caracteristicile esenţiale ale sistemelor informaţionale economice, interfaţa
utilizator constituind componenta cea mai însemnată.
Proiectarea necorespunzătoare a bazei de date va afecta, în primul rând, proiectanţii de
programe şi programatorii, iar slaba proiectare a arhitecturii programelor şi a modulelor de
program va face mai dificilă munca celor însărcinaţi cu testarea şi întreţinerea programelor.
Utilizatorii sistemului vor percepe mai puţin aceste carenţe în proiectarea sistemului, ei
putând fi nemulţumiţi de timpii de răspuns ai calculatorului la unele operaţii iniţiate de ei
în timpul exploatării. În schimb, proiectarea defectuoasă a interfeţelor utilizator va
determina, de cele mai multe ori, respingerea sistemului, chiar dacă acesta oferă mai multe
funcţionalităţi decât cele solicitate de utilizatori. Dimpotrivă, un sistem, care nu oferă toate
cerinţele funcţionale solicitate, ar putea fi acceptat de către utilizatori dacă dispune de
interfeţe utilizator simple şi prietenoase, care să ofere satisfacţie.
Boris Beizer, un pătimaş al umanizării relaţiilor cu calculatorul, precizează la un
moment dat că „toate relaţiile puternice sunt exprimate prin comunicare. Chiar mai mult,
formele comunicării dau expresie şi relaţiilor. Între dragoste şi ură nu e decât un pas: câteva
cuvinte neinspirate pot schimba prezentul cu trecutul – câteva comenzi necorespunzătoare
pot transforma dragostea faţă de un produs-program în ură. Mijloacele prin care trebuie să
comunicăm cu calculatorul şi cele prin care el comunică cu noi vor afecta în mod
determinant relaţia noastră cu acesta”9.
În acest capitol ne vom ocupa îndeosebi de proiectarea interfeţelor utilizator, nu înainte
de lămuri unele aspecte definitorii ale noţiunii de interfaţă, dată fiind complexitatea ei.

3.1.1 Definirea conceptului de interfaţă

Noţiunea de interfaţă este destul de des întâlnită în literatura informatică, deşi ea are şi
o accepţiune generală în limbajul curent, în sensul de element de legătură între două unităţi.
Dicţionarul explicativ al limbii române defineşte interfaţa foarte îngust, ca fiind
„suprafaţa de separare a porţiunilor care reprezintă faze diferite într-un sistem fizico-
chimic”. Din definiţie rezultă funcţia de separare, şi nu cea de legătură. Ulterior, în
Dicţionarul explicativ al limbii române – Supliment, apar termenii de interfaţare şi
interfaţă.
Interfaţa, cu trimitere la domeniul electronicii, este „un dispozitiv care converteşte
semnalele electronice în aşa fel încât două aparate sau sisteme să poată comunica între ele”.
Se observă o schimbare radicală a poziţiei faţă de prima variantă, interfaţa fiind ceva care
asigură comunicarea între două sisteme. Aproape similar, interfaţarea este definită ca o
„interconectare a părţilor unui sistem sau a unor aparate astfel încât ele să îşi poată îndeplini
funcţia în mod corect, coordonat”.

9. Beizer, B. – Personal Computer Quality: A Guide for Victims and Vendors, Van Nostrand Reinhold Company, New
York, 1986, p. 87.
43

Webster’s Encyclopedia Unbridged Dictionary of the English Language, Grammary
Books, New York/Avenal, New Jersey, ediţia din 1994, defineşte interfaţa astfel:
1. „O suprafaţă referitoare la o frontieră comună (sublinierea noastră) dintre două corpuri
sau spaţii.
2. Fapte, probleme, considerente, teorii, practici etc. avute în comun de două sau mai multe
discipline, proceduri sau domenii de studiu: interfaţa dintre fizică şi chimie.
3. O frontieră comună sau o interconexiune între sisteme, echipamente, concepte sau fiinţe
umane.
4. Computer Technology. a) echipament sau program conceput pentru a comunica
informaţii de la un sistem de echipamente electronice sau programe la altul.
b) orice reglementare privind astfel de comunicaţii…”.
Aşadar, pe scurt, interfaţa asigură comunicarea între două sau mai multe sisteme. În
informatică, o astfel de semnificaţie este des întâlnită, căpătând mai multe conotaţii.
Referindu-se la software-ul de sistem, Schulteis, Sumner şi Bock10 afirmă că „prin
intermediul echipamentelor electronice de calcul şi al unui timp anume destinat, software-
ul sistemelor acţionează ca o legătură sau interfaţă între sistemul de calcul şi programele de
aplicaţii pe care utilizatorul doreşte să le execute”. Aceiaşi autori, la pagina 33, definesc
interfaţa ca „o conexiune la frontierele unui sistem sau subsistem. O interfaţă serveşte drept
mediu de conversie a ieşirilor unui sistem în intrări ale altuia”. De cele mai multe ori,
funcţia de legare între ele a două componente este realizată de un subsistem special
proiectat în acest scop.
Pentru domeniul dezvoltării sistemelor informatice economice, prezintă interes următoarele
sensuri ale noţiunii de interfaţă:
interfaţa dintre sistemul informaţional şi mediul său extern relevant, prin care se
face referire la intrările/ieşirile în/din sistem şi care pot să apară sub forma
documentelor, rapoartelor, a răspunsurilor la întrebări sau a unor simple structuri de
date schimbate cu alte sisteme informatice;
interfaţa dintre componentele software ale sistemului informatic. Această
accepţiune face referire la legăturile dintre modulele unui program, care reflectă
invocarea unui modul de către un altul, şi parametrii transmişi între ele, sub formă
de date elementare, structuri de date sau informaţii de control;
interfaţa dintre om şi calculator, în sensul unui mediu eficient de comunicare dintre
om şi calculator, pe baza căruia utilizatorii pot interacţiona cu calculatorul, pentru a
transmite comenzile şi datele, precum şi pentru a obţine informaţiile necesare. În
această accepţiune, interfaţa face referire la partea vizibilă a sistemului
informaţional, din punctul de vedere al utilizatorului.
Nu toate accepţiunile prezentate anterior vor fi tratate în acest capitol. Prima accepţiune
este utilizată în faza de analiză, la definirea ariei de întindere a sistemului, atunci când
se specifică funcţiile sistemului, intrările, ieşirile şi entităţile externe cu care
interacţionează sistemul. Acest sens a fost deja discutat, în volumul anterior, în capitolul
destinat modelării logice a prelucrărilor.
Cel de-al doilea sens este utilizat la proiectarea programelor şi procedurilor, iar cu el
ne vom întâlni în capitolul cinci. Atunci vom trata interfaţa ca unul dintre atributele de bază
ale modulelor de program.

10. Schulteis, R., Sumner, M., Bock, D. – Management Information Systems: The Manager’s View, Second Edition,
IRWIN, Homewood, Boston, 1992, p. 123.

Ultima accepţiune mai este referită şi sub denumirea de interfaţă a utilizatorului,
definită de Zwass11 ca „o combinaţie a mijloacelor prin care un utilizator interacţionează cu
un sistem electronic de calcul”. Ea constă din componente hardware şi software, care
permit utilizatorului să preia în sistem datale de intrare, în vederea stocării şi prelucrării lor,
şi să obţină informaţiile necesare în rezolvarea propriilor sarcini de lucru. Componentele
hardware se referă la echipamentele cu care interacţionează utilizatorii precum tastatura,
mouse, trackball, ecran, imprimantă etc. Componentele software ale interfeţei utilizator
cuprind acele elemente pe care utilizatorii le percep dintr-o aplicaţie, respectiv ecranele
(formularele) pentru culegerea şi introducerea datelor în calculator, meniurile şi dialogurile
prin intermediul cărora utilizatorii pot iniţia diferite operaţiuni, inclusiv afişarea şi tipărirea
unor informaţii sub formă de rapoarte.
Noţiunea de interfaţă utilizator ar putea fi definită într-un sens mai larg, prin includerea
altor componente care permit utilizatorilor să interacţioneze cu sistemul, precum
documentaţia utilizatorului, manualul de instruire, facilităţile de ajutor şi alte documentaţii,
care sunt livrate împreună cu echipamentele şi programele. Aceste elemente vor fi
prezentate în capitolul 7 din acest volum.
La o analiză mai atentă, şi subiectul capitolului următor (proiectarea logică a fişierelor
sistemului şi bazelor de date – pe scurt, modelarea logică a datelor) ar ţine tot de o astfel de
problematică: interfeţe om – calculator pentru culegerea datelor.
Ordinea în care sunt tratate cele trei capitole (proiectarea formularelor/ formate şi a
rapoartelor, proiectarea interfeţelor şi a dialogurilor, modelarea logică a datelor) poate fi
îndelung discutată. Secvenţa folosită în tratarea lor, de cele mai multe ori, este doar una
logică: precedentul capitol creează bazele celui ce urmează. În realitate, în practica de zi cu
zi, ordinea lor nu este secvenţială, ci, mai curând, paralelă sau iterativă.
O altă noţiune care prezintă importanţă în acest context este dialogul. În informatică,
el are aceeaşi semnificaţie ca şi în accepţiunea cotidiană: conversaţie între doi parteneri.
Am putea chiar afirma că proiectarea dialogurilor şi a interfeţelor reprezintă procesele de
definire a modalităţilor prin care oamenii şi calculatoarele schimbă informaţii.
În capitolul de faţă, ne vom ocupa de componentele software ale interfeţei utilizator,
care au rolul de a asigura dialogul între utilizator şi sistem. În capitolul anterior am descris
aspectele privind proiectarea formularelor/documentelor, care consemnează datele de
intrare în sistem, şi a rapoartelor, care conţin informaţiile solicitate de utilizator, obţinute
în urma prelucrărilor. Acum, vom urmări proiectarea ecranelor (formularelor), necesare
pentru preluarea datelor de pe formulare/documente şi salvarea lor în baza de date, a
dialogurilor, care vor permite utilizatorilor obţinerea rapoartelor, şi a meniurilor, prin
intermediul cărora utilizatorii vor lansa diferite operaţiuni, inclusiv cele pentru culegerea
datelor şi obţinerea rapoartelor.
Pentru ecrane, în acest capitol, vom folosi şi noţiunea de formular, dar cu alt sens.
Dacă în capitolul anterior, prin formular se făcea referire la un document în care sunt
consemnate datele cu privire la diferite tranzacţii economice, în acest capitol el este sinonim
cu cel de ecran pentru culegerea datelor. Am optat pentru utilizarea ambelor noţiuni,
deoarece unii sunt familiarizaţi cu noţiunea de formular, de la englezescul „form”.

3.1.2 Identificarea interfeţelor utilizator

Identificarea interfeţelor utilizator este realizată în strânsă legătură cu prima accepţiune

a conceptului de interfaţă, cea care face referire la interacţiunile sistemului cu mediul său

11. Zwass, V. – Management Information Systems, WCB-Wm, C. Brown Publishers, Dubuque, 1992, p. 338.
45

extern. Această activitate presupune analiza atentă a intrărilor şi ieşirilor din sistemul
informaţional, pe baza diagramelor fluxurilor de date, elaborate în faza de analiză, şi a
graniţelor informatizării, stabilite la definirea strategiei de proiectare. Intrările şi ieşirile
care depăşesc graniţele pot prezenta interes din perspectiva proiectării interfeţelor utilizator.
De exemplu, fluxul de intrare FACTURA, primit de la entitatea externă FURNIZOR,
sugerează necesitatea proiectării unui ecran (formular) prin intermediul căruia utilizatorul să
poată interacţiona cu sistemul în vederea preluării şi stocării în baza de date a datelor din
factură. De asemenea, fluxul de ieşire JURNALUL DE CUMPĂRĂRI, transmis către
entitatea externă CONTABILITATE GENERALĂ, impune proiectarea unui set de dialoguri
care să permită utilizatorului generarea acestui raport.
Însă, nu toate intrările/ieşirile în/din sistem implică o interfaţă utilizator. Dacă unele
intrări şi ieşiri solicită utilizatorul, în mod direct şi hotărâtor, ele fiind referite ca interfeţe
utilizator, altele nu presupun intervenţia acestuia sau ea este minimală. De exemplu, unele
date sunt preluate automat în sistem cu ajutorul unor echipamente speciale, cum ar fi
scanerele optice sau cititoarele de coduri bară. Revenind la ciclul prelucrării datelor,
discutat în volumul anterior, este vorba despre metode de culegere automată a datelor.
De asemenea, unele rapoarte sau documente pot fi generate automat sau ca urmare a
unei intervenţii umane minime. De exemplu, generarea balanţei de verificare sintetică
poate fi realizată prin simpla selectare a unei opţiuni din meniul aplicaţiei. Aceste intrări şi
ieşiri sunt referite ca interfeţe sistem.
Principalele tipuri de interfeţe sistem sunt:
Culegerea automată a datelor de intrare. Echipamente speciale, precum scanerele,
permit introducerea automată a datelor în sistem. Cititoarele de coduri bară, plasate
în punctele de vânzare – POS (point of sale), asigură preluarea automată în sistem a
datelor privind vânzările. Tot cu ajutorul cititoarelor de coduri bară, se poate
automatiza activitatea de inventariere a depozitelor de bunuri materiale.
Intrări provenite de la alte sisteme informaţionale. Preocupările din ultimii ani,
privind integrarea sistemelor informaţionale, au determinat reducerea considerabilă
a redundanţei în culegerea datelor şi, ca o consecinţă, creşterea volumului de date
transferate între diferite sisteme. Integrarea poate fi realizată fie prin schimbul de
mesaje între sisteme, fie prin partajarea unei baze de date comune. În primul caz, o
intrare poate reprezenta un mesaj primit de la alt sistem prin intermediul schimbului
electronic de date – EDI (Electronic Data Interchange). Mesajul primit declanşează
o serie de prelucrări, exact ca şi cum utilizatorul le-ar fi iniţiat, dar fără ca acesta să
intervină. De exemplu, înregistrarea unei comenzi primite direct de la sistemul
informaţional al unui client poate declanşa procesul de livrare în vederea onorării
comenzii respective, fără ca utilizatorul să mai preia datele din comandă. În cel de-
al doilea caz, integrarea prin date a sistemelor informaţionale presupune accesarea
unei baze de date comune. Datele preluate şi stocate de un sistem vor putea fi
accesate şi de alte sisteme. De exemplu, informaţiile despre livrările efectuate,
colectate şi stocate de sistemul de gestiune a vânzărilor, pot fi accesate de către
sistemul de încasări şi plăţi în vederea verificării şi înregistrării operaţiunilor de
încasare a clienţilor. O astfel de intrare nu implică proiectarea unui ecran pentru
introducerea datelor respective, ci semnifică o operaţie de acces la un fişier întreţinut
de un alt sistem. Ea poate sugera doar includerea în program a unei fraze SELECT
SQL.

Ieşiri către alte sisteme informaţionale. Acest tip de interfeţe sistem reprezintă
imaginea în oglindă a tipului de interfeţe discutat la punctele anterioare.
Înregistrarea intrării în stoc a produselor finite poate determina generarea şi
transmiterea automată a unui mesaj către sistemul de gestiune a vânzărilor.
Ieşiri care presupun intervenţie umană minimă. Există situaţii în care generarea şi
transmiterea rapoartelor se face automat, la anumite intervale de timp sau la date
fixe, sau în care interacţiunea cu sistemul este minimă, neimplicând proiectarea
unor dialoguri. De exemplu, situaţia detaliată a soldului pentru clienţii importanţi
poate fi generată şi transmisă periodic acestora, în mod automat.
În dezvoltarea sistemelor informaţionale este foarte importantă separarea clară a
interfeţelor utilizator de interfeţele sistem, deoarece proiectarea celor două tipuri de interfeţe
solicită expertiză şi tehnologii diferite. Dacă de proiectarea interfeţelor utilizator ne vom
ocupa în acest capitol, la proiectarea interfeţelor sistem ne vom referi în capitolul destinat
proiectării programelor, deoarece lor le corespund, adesea, module de programe speciale,
pentru preluarea automată a datelor sau generarea automată a informaţiilor.

TA 3.1
1. În ce constă diferenţa dintre interfaţa utilizator şi interfaţa sistem?
2. Enumeraţi componentele software ale interfeţei utilizator.
Răspuns:

3.2 Metode şi echipamente folosite
în dialogul om-calculator

Dacă interfaţa dintre utilizator şi calculator a fost, pe vremuri, practic imposibilă,
făcând referire la calculatoarele generaţiei inventatorilor, prin progresele din domeniu, în
prezent se vorbeşte despre o generaţie a utilizatorilor sau conducătorilor. Progresul
înregistrat a fost atât de rapid, încât a apărut nevoia atribuirii unui calificator pentru noua
variantă, vorbindu-se despre Graphical User Interface (GUI) – interfaţa grafică a
utilizatorului.
Ar fi de ajuns doar să enumerăm câteva astfel de medii. Revoluţia s-a produs odată cu
lansarea pe piaţă a interfeţei grafice a utilizatorului de către Macintosh, bazată în mare
parte pe rezultatele înregistrate de Xerox Palo Alto Research Center. Noul mediu se
bazează pe aşa-zisele icons reprezentând obiecte sau acţiuni prin meniuri care să ajute la
selectarea unei acţiuni. Mouse-ul ajută la navigarea într-un astfel de mediu. Ulterior, au fost
promovate alte produse care încorporează elemente de interfaţă grafică a utilizatorului,
47

dintre care le enumerăm pe cele mai reprezentative: Windows (Microsoft), Presentation
Manager din OS/2 (IBM şi Microsoft), Open Look (AT&T), GEM (Digital Research),
NewWave (Hewlett-Packard), NeXTStep (NeXT), Motif (Open Software Foundation).
Sunt progrese demne de semnalat în mediul grafic faţă de cel tradiţional, spunându-se
că munca utilizatorului se reduce cu 35%, datorită vitezei mai mari cu care se operează, iar
erorile scad cu 17%.
O altă soluţie a constituit-o noua interfaţă pentru calculatoarele dotate cu creioane
optice. Sistemul de operare PenPoint al firmei Go Corporation a însemnat o nouă modă în
interfeţele oferite utilizatorilor.
Interfeţele pentru preluarea/redarea vocii constituie încă un salt, deşi ca răspândire nu
au regimul celorlalte interfeţe. Mai nou, există interfeţele multimedia oferite utilizatorului
pentru acces la text, sunet, imagine.

3.2.1 Metode de interacţiune om-calculator

Dacă interfaţa dintre utilizator şi calculator a fost, pe vremuri, practic imposibilă,

făcând referire la calculatoarele generaţiei inventatorilor, prin progresele din domeniu, în
prezent se vorbeşte despre o generaţie a utilizatorilor sau conducătorilor. Progresul
înregistrat a fost atât de rapid, încât a apărut nevoia atribuirii unui calificator pentru noua
variantă, vorbindu-se despre Graphical User Interface (GUI) – interfaţa grafică a
utilizatorului.
Ar fi de ajuns doar să enumerăm câteva astfel de medii. Revoluţia s-a produs odată cu
lansarea pe piaţă a interfeţei grafice a utilizatorului de către Macintosh, bazată în mare
parte pe rezultatele înregistrate de Xerox Palo Alto Research Center. Noul mediu se
bazează pe aşa-zisele icons reprezentând obiecte sau acţiuni prin meniuri care să ajute la
selectarea unei acţiuni. Mouse-ul ajută la navigarea într-un astfel de mediu. Ulterior, au fost
promovate alte produse care încorporează elemente de interfaţă grafică a utilizatorului,
dintre care le enumerăm pe cele mai reprezentative: Windows (Microsoft), Presentation
Manager din OS/2 (IBM şi Microsoft), Open Look (AT&T), GEM (Digital Research),
NewWave (Hewlett-Packard), NeXTStep (NeXT), Motif (Open Software Foundation).
Sunt progrese demne de semnalat în mediul grafic faţă de cel tradiţional, spunându-se
că munca utilizatorului se reduce cu 35%, datorită vitezei mai mari cu care se operează, iar
erorile scad cu 17%.
O altă soluţie a constituit-o noua interfaţă pentru calculatoarele dotate cu creioane
optice. Sistemul de operare PenPoint al firmei Go Corporation a însemnat o nouă modă în
interfeţele oferite utilizatorilor.
Interfeţele pentru preluarea/redarea vocii constituie încă un salt, deşi ca răspândire nu
au regimul celorlalte interfeţe. Mai nou, există interfeţele multimedia oferite utilizatorului
pentru acces la text, sunet, imagine.
Literatura de specialitate oferă veritabile tratate ce descriu metodele de interacţiune
dintre om şi calculator, cu renumiţi autori, cum sunt: Steven Alter, Robert Buzzell, Robert
Mann, John Rockart, De Long David, Ralph Sprague, Eric Carlson, Edward Tufte, Efraim
Turban, M. Blattner, E. Schultz, J.S. Dumas, E.B. Fernandez, R.C. Summers, C. Wood,
J.C. May, F.R. McFadden, J.A. Hoffer, K.L. Norman, A. Porter, B. Shneiderman, V.
Zwass, A. Varsegi, B. Buzman, R. Schulteis, M. Sumner ş.a. Am prezentat această listă
cuprinzătoare pentru a veni în sprijinul acelora care, în noile variante de navigare prin
bibliotecile Internet, să poată apela direct numele susmenţionate. În aceeaşi idee, există şi

zeci de reviste care, număr de număr, oferă suficient material bibliografic pe tema interfeţei
om – calculator.
Având în vedere varietatea metodelor de interacţiune, în continuare le vom descrie pe
cele mai utilizate dintre ele. Ulterior, vom analiza şi echipamentele cu o astfel de destinaţie.

3.2.1.1 Interacţiunea prin limbaj-comandă

Toate calculatoarele încep să funcţioneze prin comenzi, omul transmiţând

calculatorului ceea ce ar dori să execute. Se spune că un software bun este caracterizat prin
multe opţiuni de lucru, printr-o logică riguroasă, ceea ce ar însemna gramatica unui limbaj-
comandă, precum şi prin uşurinţa cu care intuim forma a ceea ce va genera comanda
lansată în execuţie. Comenzile trebuie să fie concepute astfel încât să răspundă cerinţelor
tuturor categoriilor de utilizatori, de la începători la avansaţi.
Există o mare varietate de tipuri de comenzi, enumerând aici pe cele mai cunoscute:
comenzi sintactice, comenzi mnemonice, comenzi-taste şi comenzi în limbajul natural.
Cea mai simplă comandă sintactică este cea prin care utilizatorul trebuie să tasteze
mai întâi toate informaţiile necesare, după o sintaxă foarte riguroasă, după care va lansa în
execuţie comanda respectivă, de regulă prin apăsarea tastei ENTER. Pentru exemplificare,
să considerăm comanda următoare:
DIR C:\SUBDIR\*.exe /p /w <ENTER>

Această comandă este familiară celor care au lucrat cu sistemul de operare MS-DOS şi
are ca efect afişarea condensată, ecran cu ecran, a informaţiilor despre fişierele cu extensia
EXE din subdirectorul SUBDIR de pe discul C.
Cele mai inteligibile şi mai simple comenzi sunt cele mnemonice, adică ele au un sens
prin cuvintele sau abrevierile utilizate. Este vorba despre formele folosite pentru comenzile
sistemelor de operare care pot fi utilizate fie prin numele lor în întregime, ca de exemplu
RENAME, fie prin primele trei litere, ceea ce înseamnă REN. Similar sunt utilizabile şi
comenzile VISUAL FOXPRO, cu diferenţa că, în aceste cazuri, formele abreviate înseamnă
utilizarea primelor patru caractere din comenzi.
Comenzile-taste constau în acţionarea unei taste anume, a unei taste funcţionale (F1,
F2, F3 etc.) sau a unei combinaţii de taste (se folosesc tastele CTRL, SHIFT, ALT) atunci
când programul este pregătit să accepte o nouă comandă. Diverse programe lansate în
execuţie pot redefini funcţiile tastelor funcţionale speciale, dându-le o semnificaţie
dinamică. Sunt produse-program care, pentru a uşura munca utilizatorului, oferă şabloane
de carton ce pot fi ataşate zonei tastelor funcţionale. Alteori, se lipesc mici etichete adezive
pe taste, indicând noua lor funcţiune.
Nu putem să nu consemnăm interacţiunea cu calculatorul prin limbaj natural, deşi ea
se află în stadiu incipient. Progresele se datorează cercetărilor din domeniul inteligenţei
artificiale, şi anume acelora referitoare la limbajul natural. Oricum, au fost concepute
sisteme care folosesc atât interfaţa prin voce, cât şi aceea care utilizează clasica tastatură a
sistemelor de calcul.
Spre deosebire de softul care comunică prin meniuri, în care opţiunile sunt afişate pe
ecran, comunicarea prin limbaj-comandă presupune ca opţiunile de lucru să se afle în
mintea utilizatorului. Acesta este motivul determinant pentru care softul orientat pe comenzi
este mai dificil de învăţat, pentru că trebuie însuşite comenzile ce pot fi utilizate. Dacă ele
nu au o logică, o oarecare apropiere de limbajul uman, misiunea de a le învăţa devine şi mai
anevoioasă. Totuşi, ele rămân încă bine apreciate în rândul multor informaticieni.
49

3.2.1.2 Interacţiunea prin meniuri

Interacţiunea prin meniuri este familiară majorităţii celor care utilizează astăzi
calculatorul. Aproape toate produsele-program dispun astăzi de meniuri.
Un meniu pune la dispoziţie o listă de opţiuni, relevante din punctul de vedere al
activităţii ce trebuie realizată, din care utilizatorul va selecta una, iar comanada
corespunzătoare va fi executată. Există mai multe modalităţi de selectare a unei opţiuni din
meniu, dintre care cel mai utilizat este cursorul, deşi operaţiunea poate fi realizată şi prin
atingerea cu degetul a unei zone anume, cu ajutorul mouse-ului, al unui creion special
(light pen) ş.a.
Opţiunile de selectat pot fi afişate în diverse moduri: prin coduri, cuvinte scurte (dar
foarte sugestive), fraze, imagini – icons, butoane sau combinaţii ale acestora, astfel că pot
exista multe tipuri de meniu. Vom prezenta în continuare cele mai utilizate dintre acestea.
Liste simple cu opţiuni
Unele produse-program folosesc meniurile într-o modalitate deosebit de simplă, cu
opţiuni multiple, de genul:

Creare fişier nomenclator
Salvare într-un fişier nou
Listare fişier nomenclator
…
Părăsire aplicaţie
Tastaţi opţiunea dumneavoastră şi apoi RETURN.

În acest tip de meniu, utilizatorul selectează opţiunea dorită, comanda este executată
după care se revine la meniu. În exemplul nostru, utilizatorul selectează o opţiune prin
tastarea literei evidenţiată cu caracter îngroşat. Un astfel de meniu prezintă avantajul
simplităţii navigării şi a memorării uşoare, însă ocupă porţiuni importante de ecran. De
aceea, astăzi ele nu mai sunt folosite.

Zone cu comenzi şi linii-meniu

Există produse-program care, imediat ce sunt lansate în execuţie, afişează comenzile

într-o anumită zonă sau, de cele mai multe ori, pe prima sau pe ultima linie a ecranului.
Selecţia uneia dintre comenzi se poate efectua prin câteva metode, cum ar fi: prima literă a
cuvântului-cheie, marcarea sau punctarea comenzii, apăsarea unei taste funcţionale. Astfel
de meniuri se regăseau în special în programele ce rulau sub sistemul de operare MS-DOS,
mai cunoscute fiind LOTUS 1-2-3 şi WORD PERFECT.
Cum cele mai multe calculatoare au tastele funcţionale pe linia de sus a tastaturii, în
multe produse-program comenzile se afişează pe ultima linie a ecranului, realizându-se
astfel o apropiere a lor. Se recomandă ca ordinea comenzilor să respecte şi ordinea tastelor
funcţionale de pe tastatură.
Liniile cu comenzi oferă câteva avantaje: nu ocupă mult loc pe ecran, pot fi păstrate în
permanenţă pe ecran, sunt uşor de folosit. Un dezavantaj constă în restricţia de a le
condensa într-un singur cuvânt care trebuie să fie sugestiv şi care, de cele mai multe ori,
trebuie să înceapă cu altă literă decât celelalte comenzi.
Meniuri de tip bară
Cele mai multe dintre produsele-program de astăzi dispun de meniuri-bară (menu bar).
Acest tip de meniu este plasat în prima linie a ecranului sau a unei ferestre a programului şi
oferă acces permanent la opţiunile sale, chiar şi atunci când utilizatorul lucrează în cadrul
unui ecran sau ferestre. Un meniu-bară constă dintr-o listă dinamică de categorii de acţiuni

care conduc utilizatorul la o listă de acţiuni specifice categoriei selectate, prezentată sub
formă de meniu drop-down. Figura 2.1(a) prezintă meniul de tip bară din procesorul de
texte WORD şi meniul drop-down aferent opţiunii FILE. Meniurile pot fi organizate pe
niveluri, după cum se poate observa în figura 2.1(b).
O caracteristică importantă a meniurilor se referă la definirea dinamică a opţiunilor
disponibile. Utilizatorul va avea acces numai la opţiunile potrivite acţiunii pe care o
realizează la un moment dat. Opţiunile care nu sunt disponibile la un moment dat sunt
evidenţiate distinct, de regulă prin utilizarea caracterelor de culoare gri. De exemplu, în
meniul EDIT din WORD, opţiunile CUT şi COPY nu vor fi active dacă nu este selectat un
obiect sau o porţiune de text din fereastra de lucru. Astfel, utilizatorul va şti ce acţiuni şi
opţiuni sunt permise într-un anumit context de lucru, determinând reducerea încărcării
memoriei acestuia.

a) Exemplu de meniu drop-down

b) Exemplu de meniu în cascadă

Fig. 2.1 Exemple de meniuri pop-up şi drop-down

Meniuri context

Cel mai nou tip de meniu, utilizat în interfeţele utilizator, este meniul context, numele
său provenind de la faptul că opţiunile afişate depind de contextul de lucru în care se află
utilizatorul. El mai este numit şi meniu pop-up, deoarece apare pe ecran, lângă obiectul
selectat, imediat după apăsarea butonului dreapta al mouse-ului sau a unei taste anume.
51

Figura 2.2 prezintă meniul context asociat unui obiect de tip căsuţă de text, din Power
Point.
Un meniu context conţine doar opţiunile de lucru specifice obiectului selectat. De
obicei, se includ doar opţiunile utilizate mai frecvent, care sunt accesibile şi din meniul
bară al produsului-program. Astfel de meniuri pot fi proiectate pentru fiecare element din
fereastra de lucru care poate fi selectat de utilizator: imagine (icon), căsuţă de text etc.

Meniu prin imagini

Fig. 2.2 Exemple de meniu context şi icons

Meniuri prin imagini/pictograme (icons)

Meniurile prin imagini constituie, de fapt, meniuri cu linii de comenzi în care acţiunile
de întreprins sunt exprimate prin imagini (icons), şi nu prin cuvinte. Imaginile sunt cât se
poate de sugestive, facilitând utilizarea, memorarea şi recunoaşterea lor. Totuşi,
simbolistica desenelor rămâne deocamdată un element de studiu pentru specialişti, deoarece
generalizarea lor necesită mult timp, cu atât mai mult cu cât mulţimea simbolurilor se
extinde continuu.
Prin imagini pot fi redate uşor substantivele, destul de mulţumitor verbele, dar foarte
dificil adjectivele şi aproape fără speranţă adverbele. Iată de ce meniurile prin imagini nu
pot lua forme prea performante. Până şi sensurile simbolurilor diferă de la o cultură la alta.
Dacă un chinez ar dori să creeze o imagine prin care să sugereze salvarea tuturor
elementelor-problemă (a se citi un necaz) lui i-ar veni foarte uşor, întrucât în simbolistica
chineză necazul se poate reprezenta prin imaginea a două femei sub acelaşi acoperiş. Câţi
americani sau europeni ar atribui sensul acesta imaginii respective?
Meniurile bazate pe imagini (icons) fac parte din categoria cunoscută în literatură ca
interacţiune bazată pe obiecte. Imaginile folosite funcţionează ca butoanele. La „apăsarea”
lor (a se citi selecţia lor) se activează o anumită funcţie sau comandă (salvare, imprimare,
căutare ş.a.). În figura 2.2 este prezentat meniul bazat pe imagini din Power Point.

3.2.1.3 Interacţiunea prin ecrane pentru introducerea datelor (formulare)

Cea mai utilizată metodă de interacţiune om-calculator este, probabil, cea bazată pe
ecrane pentru introducerea datelor, numite şi formulare (forms). Prin această metodă,
utilizatorii vor completa diferitele câmpuri din ecrane, cu date preluate adesea din
documentele primare (formate/formulare), a căror proiectare a fost discutată în capitolul
anterior. Datele introduse sunt, de obicei, salvate în baza de date. Ecranele sunt, de
asemenea, utilizate pentru vizualizarea într-o formă logică, structurată, a datelor din bază.
La construirea formularelor se apelează la o serie de obiecte de control, utilizabile
pentru introducerea datelor, referite adesea, pe scurt, prin controale. Forma celor mai
utilizate obiecte de control este prezentată în figura 2.3, iar descrierea lor se regăseşte în
tabelul 2.1. În prima coloană a tabelului am inclus, între paranteze, denumirea lor în limba
engleză, întâlnită în mediile de programare vizuale.

Fig. 2.3 Principalele tipuri de obiecte de control utilizate la construirea formularelor

Tabel nr. 2.1 – Principalele tipuri de controale regăsite în formulare

Obiect de control Descriere şi caracteristici principale

Căsuţă de text Este tipul de obiect cel mai utilizat în construirea formularelor. El
(Text box) este folosit pentru preluarea datelor introduse de la tastatură, pe o
singură linie. Căsuţele de text pot fi proiectate astfel încât datele
introduse să fie limitate la o anumită lungime sau un anumit format.
Atunci când logica aplicaţiei o permite, se recomandă scrierea unei
valori implicite, pe care utilizatorul o poate păstra sau modifica.
Etichetă Cu ajutorul etichetei se pot afişa texte în poziţii bine precizate din
(Label) formulare. Aceste texte însoţesc căsuţele de text sau alte tipuri de
controale şi se referă la titluri, explicaţii sau indicaţii referitoare la
ceea ce trebuie să introducă utilizatorul.
Căsuţă cu listă Ea este derivată din căsuţe de text, fiind utilizată pentru selectarea
(List box) unui element dintr-o listă de valori predefinite. Prin acest tip de
obiect se evită introducerea unei valori de la tastatură, oferindu-se
utilizatorului o listă de valori din care poate alege una. Se reduce
astfel riscul introducerii de date eronate deoarece utilizatorul
specifică o valoare corectă de vreme ce ea este afişată.
53

Obiect de control Descriere şi caracteristici principale
Căsuţă combinată Ea reprezintă o combinaţie între căsuţele de text şi cele de tip listă. O
(Combo box) căsuţă combinată conţine de asemenea o listă predefinită de valori
din care poate fi aleasă una, ca în cazul căsuţei cu listă, dar permite
în acelaşi timp adăugarea de valori noi, precum în căsuţele de text.
Grilă (grid) Acest tip de obiect este adesea utilizat în formularele concepute
pentru culegerea datelor din documentele primare. O grilă este
formată din mai multe coloane în care se introduc datele privind
detaliile din documente, cum ar fi denumirea, cantitatea, preţul şi
valoarea mărfurilor dintr-o factură. Coloanele apar sub formă de
căsuţe de text, dar şi căsuţe combinate.
Butoane de opţiune sau Acest tip de obiect asociază mai multe opţiuni din care utilizatorul
butoane radio poate alege una singură. Atunci când se dă clic pe una dintre
(Option buttons sau opţiuni, cea care era anterior selectată va fi automat dezactivată,
Radio buttons) astfel că la un moment dat o singură opţiune va fi activă. Deoarece
toate opţiunile posibile sunt afişate în formular, acest tip de obiect
este utilizat atunci când numărul alternativelor este mic şi ele nu se
modifică în timp.
Căsuţă de validare O căsuţă de validare este asemănătoare cu butoanele de opţiuni, în
(Check box) sensul că ea conţine mai multe opţiuni, dar din care utilizatorul poate
activa oricâte şi nu doar una. Activarea/dezactivarea unei opţiuni din
listă se efectuează prin simpla selectare a ei de la tastatură sau
mouse.
Cadru de pagină El permite crearea de pagini suprapuse într-un formular. Fiecare
(Page frame) pagină va avea nume, conţinut şi funcţionalitate proprii. Cadrele de
pagini se utilizează atunci când funcţionalitatea unui formular poate
fi separată în mai multe părţi strâns legate, pentru fiecare
construindu-se câte o pagină. O pagină va conţine obiecte de
celelalte tipuri.
Buton de comandă El oferă utilizatorului posibilitatea declanşării unei acţiuni sau
(Command button) operaţiuni, cum ar fi tipărirea la imprimantă, salvarea datelor
introduse, închiderea formularului.

În figura 2.4 este prezentat un exemplu de formular pentru introducerea şi vizualizarea

datelor referitoare la achiziţia de mărfuri. Aceste date privesc documentele primite de la
furnizori, facturi şi/sau avize de expediţie, şi cele de recepţionare a mărfurilor. Formularul
prezentat conţine, în partea sa superioară, o secţiune pentru filtrarea datelor afişate şi
căutarea documentelor. Primele două căsuţe de text, din partea stângă, permit utilizatorului
să specifice intervalul de timp pentru care se vor afişa date în formular, iar butoanele radio
şi căsuţa de text din partea dreaptă vor fi utilizate pentru a specifica tipul şi numărul
documentului pe care utilizatorul doreşte să-l caute şi să-l afişeze. De asemenea, formularul
conţine două pagini, respectiv FACTURI/AVIZE şi RECEPTII, în figura 2.4 fiind afişată
prima pagină. Această pagină conţine două grile: prima afişează date despre documentele
(facturi şi avize) primite de la furnizori şi înregistrate în perioada specificată anterior; cea
de-a doua grilă prezintă detaliile documentului selectat din prima grilă. După cum se poate
observa, unele coloane din cele două grile sunt de tip căsuţe combinate. Cele două grile pot
fi utilizate şi pentru adăugarea datelor. În partea de jos a paginii, se regăsesc butoanele, prin
intermediul cărora se pot iniţia diferite acţiuni, precum adăugarea sau salvarea unui
document.
O problemă foarte importantă în construirea formularelor/ecranelor o constituie
proiectarea navigării între câmpuri şi în interiorul lor. Navigarea trebuie să fie de la stânga
la dreapta şi de sus în jos, însă cu posibilităţi de revenire, la cerere. Formularele pentru

introducerea datelor trebuie să încorporeze şi alte categorii de funcţiuni comune. O parte
dintre acestea sunt enumerate în tabelul 2.2.

Fig. 2.4 Exemplu de formular pentru culegerea datelor privind cumpărările de la furnizor

Tabel nr. 2.2 – Funcţiuni ce trebuie incluse în interfeţele
din programele de introducere a datelor

Categorie de Exemple
funcţiune
Deplasarea în Deplasarea de la un câmp la următorul/precedentul/primul/ultimul.
formular

Ştergerea unei linii dintr-o grilă (grid), a tuturor datelor din formular.
Posibilităţi de editare
Inserarea unor caractere printre cele existente
Salvarea conţinutului formularului în baza de date.

Confirmarea salvării formei editate sau trecerea la un alt ecran.
Facilităţi de ieşire
Ieşirea temporară într-un mediu de lucru ajutător (vizualizare ceas,
folosire calculator de buzunar etc.).
Oferirea informaţiilor Furnizarea de informaţii despre orice câmp sau despre întregul formular.
ajutătoare
Restricţionarea accesului utilizatorilor.
Posibilităţi de control Identificarea şi autentificarea utilizatorilor.
al accesului Interzicerea modificărilor/ştergerilor înregistrărilor anterioare care au un
regim special.
Dacă este posibil, să se folosească valorile implicite (data curentă, preţul

de catalog al produselor).
Trecerea automată în câmpul următor, atunci când s-a introdus un
Facilităţi oferite la anumit număr de caractere.
introducerea datelor Nominalizarea prin titluri a conţinutului casuţelor de text şi a altor
obiecte ce afişează date.
Indicarea unităţilor de măsură, atunci când este cazul.
Oferirea exemplelor de formate folosite, cum ar fi cele pentru numere de
55

telefon, sau date calendaristice.
Alinierea automată a datelor introduse.

Verificarea dacă datele sunt cele aşteptate (exemplu: sumele încasate
sunt egale cu cele de încasat?).
Tehnici de validare a Testarea lipsei datelor în unele câmpuri.
datelor introduse Verificarea încadrării valorilor în anumite intervale (exemplu: notele să
fie în intervalul 0-10).
Apelarea la tehnica cifrei de control.

TA 3.2
1. Enumeraţi tipurile de meniu utilizate în aplicaţiile informatice.
2. Prezentaţi 8 funcţiuni pe care trebuie să le ofere un formular pentru introducerea datelor.
3. Ce tip de obiect trebuie utilizat în formular atunci când utilizatorul trebuie să aleagă una
din cinci opţiuni care nu se schimbă în timp? Dar dacă sunt 10 opţiuni posibile? De ce?
Răspuns:

3.2.2 Selectarea echipamentelor necesare interacţiunii
cu sistemul

Întrucât în paragrafele anterioare am făcut referire şi la echipamentele care asigură

interactivitatea cu sistemul, în cele ce urmează vom realiza doar succinte prezentări ale
celor mai folosite echipamente, păstrând numele lor din limba engleză pentru a nu le
denatura sensul. În zona de descriere a tabelului 2.3 vom încerca să le oferim şi un sens
românesc.
la dreapta şi de sus în jos, însă cu posibilităţi de revenire, la cerere. Formularele pentru

introducerea datelor trebuie să încorporeze şi alte categorii de funcţiuni comune. O parte
Echipament Descriere şi caracteristici principale în utilizare
Keyboard Tastatura este formată dintr-un set de butoane (taste) plasate după reguli
standard. Prin intermediul ei se introduc date, comenzi. Are o largă flexibilitate
în utilizare.
Mouse Traducerea este de prisos. Şoricelul s-a încetăţenit în limba română în varianta
engleză, mouse. El este o cutiuţă mică de plastic în care se află o bilă şi
mecanisme speciale care transformă deplasarea cutiuţei pe o suprafaţă plată în
mişcări ale cursorului de pe ecran. Mouse-ul poate fi cu două sau trei butoane.
Cele mai noi sunt sub formă de stilou.
Joystick I s-ar putea spune „beţişorul fermecat”, deşi traducerea tehnică este manşă de
comandă, asemănătoare manetei de viteze de la autoturisme. Are aceeaşi
funcţionalitate ca şi mouse-ul.
Trackball Poate fi numită bilă indicatoare de cale, căci ea oferă o sferă plasată în diferite
poziţii ale tastaturii, cu un rol similar mouse-ului. Prezintă avantajul
nesolicitării unui spaţiu special pentru deplasare, aşa cum solicită mouse-ul.
Touch Screen Atingerea ecranului constituie modalitatea prin care are loc selecţia. Este o
variantă recomandată în mediile nu prea curate sau pentru utilizatorii fără
dexteritate sau experienţă în lucrul cu alte echipamente.
Light Pen Stiloul optic efectuează selecţia prin apăsare pe ecran. Este recomandat în
sistemele care interacţionează direct cu conţinutul ecranului.
Graphics Planşeta grafică constă dintr-o suprafaţă plană pe care se plasează un
Tablet instrument de genul stiloului optic, care ghidează deplasarea cursorului pe
afişajul calculatorului. Selecţia se efectuează prin apăsarea unui buton sau a
unui stilou pe planşetă. Este utilizat pentru aplicaţiile care presupun apelarea la
multe desene sau grafice.
Voice Vocea constituie modalitatea de transmitere a textelor şi comenzilor către
calculator. Este utilă pentru persoanele cu deficienţe la mâini sau pentru cei ce
efectuează simultan operaţiuni diferite cu ajutorul ambelor mâini.

În funcţie de scopul aplicaţiilor, echipamentele anterioare pot fi descrise cu punctele
lor forte sau cu cele slabe. Oricum, selecţia este necesară.


TA 3.1 1) Interfaţa utilizator presupune interactiune om–calculator intensă, iar în
interfeţele sistem intervenţia omului este minimă sau lipseşte 2) Ecranele
(formularele), sistemul de meniuri, dialogurile.
TA 3.2 1) Liste simple cu opţiuni, zone cu comenzi şi linii-meniu, meniuri de tip bară,
meniuri context, meniuri prin imagini/pictograme.
2) Vezi tabelul 2.2. 3) Butoane de opţiune (radio buton); căsuţă combinată (combo box).

12. Tabelele 2.3, 2.4, şi 2.5 sunt adaptări după Blattner, M., Schultz, E. – „User Interface Tutorial”, Proceedings of the
International Conference on System Sciences, Kona, Hawaii, January 1988.
57


1) Diferenta dintre interfata utilizator si interfata sistem consta in:
a) interfata sistem presupune proiectarea unui modul de program, in timp ce interfata
utilizator presupune proiectarea unui meniu sau formular
b) distingerea intre interfata utilizator si interfata sistem nu este importanta in dezvoltarea
sistemelor informationale economice
c) interfata sistem este proiectata atunci cand datele de intrare sunt culese automat, iar
interfata utilizator presupune interventia omului la culegerea datelor

2) Care dintre urmatoarele tipuri de obiecte se foloseşte întrun formular atunci când
utilizatorul poate alege oricâte opţiuni dintro listă?
a) căsuţă combinată (combo box)
b) căsuţă de validare (check box)
c) butoane de opţiuni (radio buton)

3) Interacţiunea prin limbaj-comandă presupune ca utilizatorul:
a) să folosească o comandă intr-un limbaj de programare
b) să folosească tastele funcţionale
c) să folosească combinaţii de taste (CTRL-A, de exemplu)

1. Care este diferenţa dintre butoanele radio şi căsuţele de validare? Dar între căsuţa de tip
listă şi căsuţa combinată?
2. Explicaţi importanţa proiectării interfeţelor utilizator în dezvoltarea sistemelor
informaţionale contabile.
3. Precizaţi ce tipuri de obiecte veţi utiliza la proiectarea unui formular pentru preluarea
consumurilor de materiale, ştiind că trebuie introduse următoarele date: tipul (bon de consum sau
fişă limită de consum), numărul şi data documentului, locul de consum (există 15 departamente,
secţii şi ateliere), codul, denumirea şi preţul materialelor (maxim 7 materiale pe un document),
cantitatea solicitată, cantitatea aprobată şi valoarea consumată, valoarea totală a documentului.

3.5 Bibliografie

Jersey, 2001, pp. 332-343


Principii de lucru în proiectarea
interfeţelor utilizator

Obiective:
Descrierea principiilor de proiectarea şi a modului de aplicare a lor în scopul obţinerii unor
interfeţe utilizator de calitate
Familiarizarea cu aspectele de calitate a interfeţelor utilizator
Proiectarea unor interfeţe utilizator de calitate
Evaluarea aspectelor privind calitatea interfeţelor utilizator

4.1 Controlul aplicaţiei de către utilizator ................................................................................... 60
4.1.1 Principiul utilizării judicioase a modurilor de lucru ....................................................... 61
4.1.2 Principiul retroacţiunii (feed-back) imediate .................................................................. 63
4.1.3 Principiul pǎstrării stilului de lucru al utilizatorilor ....................................................... 63
4.1.4 Principiul alegerii între utilizarea tastaturii şi/sau a mouse-ului .................................... 63
4.1.5 Principiul asigurării transparenţei detaliilor de proiectare a programelor şi a bazei de
date ........................................................................................................................................... 64
4.2 Reducerea volumului de informaţii pe care trebuie sǎ le memoreze utilizatorul .................. 65
4.2.1 Principiul degrevării utilizatorului de memorarea, pe termen scurt, a unor informaţii .. 65
4.2.2 Principiul interfeţei orientate pe recunoaştere, nu pe amintire ....................................... 66
4.2.3 Principiul prevederii formelor scurte de lucru ................................................................ 66
4.2.4 Principiul relevanţei vizuale............................................................................................ 66
4.3 Uniformitatea interfeţelor utilizator ....................................................................................... 67
4.3.1 Principiul uniformitǎţii modului de prezentare a interfeţei ............................................ 68
4.3.2 Principiul uniformitǎţii în comportamentul interfeţei ..................................................... 68
4.3.3 Principiul uniformităţii interacţiunii cu interfaţa utilizator ............................................ 69
4.6 Bibliografie ............................................................................................................................ 70

Importanţa calităţii interfeţelor utilizator, în succesul unui sistem informatic, a
determinat specialiştii să se preocupe de formularea unor principii de proiectare, care să
ghideze proiectanţii în obţinerea unor interfeţe de calitate.
În acest cadru se înscriu şi preocupările producătorilor de software, de a defini un set
de principii şi reguli pe care să le aplice în dezvoltarea produselor lor. Cei mai importanţi
dintre aceştia (mai ales furnizorii de sisteme de operare) au publicat propriile reguli
încorporate în produsele lor. Dintre acestea, amintim pe cele ale firmelor Apple Computer
Inc (1992), IBM Corporation (1992), UNIX OSF/Motif (Open Software Foundation, 1993),
Microsoft Corporation (1995).
În literatura de specialitate pot fi găsite numeroase opinii în legătură cu principiile şi
regulile de proiectare a interfeţelor utilizator. În privinţa interfeţelor grafice, există aspecte
59

comune tuturor mediilor de acest gen (Microsoft Windows13, Macintosh14 ş.a.), dar şi
elemente specifice fiecăruia dintre ele. Unii specialişti se limitează la prezentarea
principiilor cu aplicabilitate generală, alţii formulează reguli specifice, în funcţie de
platformele hardware şi sistemele de operare utilizate, cerinţele sistemului sau obiectivele
definite pentru proiectarea interfeţelor. De exemplu, Rubenstein şi Hersch au identificat şi
prezentat în cartea lor, „The Human Factor” (1984), nu mai puţin de 93 de principii de
lucru15. Ben Shneiderman propune 8 reguli de bază aplicabile în majoritatea sistemelor
interactive16, prezentate în tabelul 2.6. Noi vom insista asupra principiilor general valabile,
întrucât particularul este surprins în materialele citate anterior.

Tabel nr. 2.6 –Regulile de bază ale proiectări

interfeţelor utilizator formulate de Shneiderman
Regula Descriere
1. Asigurarea Utilizarea aceleiaşi secvenţe de dialoguri în situaţii similare; a unei
uniformităţii terminologii unitare în meniuri, ecrane, mesaje etc.
2. Prevederea de Utilizarea tastelor funcţionale, a combinaţiilor de taste în locul accesării
comenzi scurte meniurilor sau a selectării unor butoane de comandă cu mouse-ul,
determină reducerea numărului de interacţiuni, cu efecte imediate
asupra productivităţii, mai ales în cazul operaţiunilor repetitive.
3. Furnizarea În cazul acţiunilor cu frecvenţă mică şi/sau de importanţă mare este

retroacţiunii foarte importantă informarea utilizatorului în legătură cu rezultatele
acţiunilor iniţiate. Pentru acţiunile cu frecvenţă mare sau a celor de
importanţă redusă, mesajele de răspuns din partea sistemului pot fi
simplificate sau chiar eliminate.
4. Marcarea sfârşitului Orice dialog trebuie să fie organizat ca o secvenţă de acţiuni în care să
dialogurilor existe un început, un mijloc şi un sfârşit.
5. Gestiunea simplă a Sistemul trebuie proiectat astfel încât să limiteze posibilitatea ca
erorilor utilizatorul să comită erori grave. Totuşi, dacă se întâmplă, sistemul va
oferi mecanisme simple şi inteligibile de detectare şi gestionare a
erorilor.
6. Prevederea Interfaţa trebuie să-i permită utilizatorului să folosească acţiunea
operaţiunilor inversă celei anterioare, cum ar fi readucerea unui element şters.
reversibile Unităţile de reversibilitate pot fi o acţiune simplă, o introducere de
date sau un grup complet de acţiuni.
7. Controlul aplicaţiei Utilizatorii experimentaţi doresc ca ei să fie cei care controlează
de către utilizator aplicaţia. Aplicaţia trebuie astfel proiectată încât utilizatorii să joace
rolul de iniţiatori ai acţiunilor şi nu pe cel de respondenţi.

13. Porter, A. – C++ Programming for Windows, McGraw-Hill, Berkeley, 1993; Bachenski, B. – „GUI Builders Pay
Price for User Productivity”, in Software Magazine, April 1992; Greenbaum, J. – „The Evolution Revolution”, in
Information Week, March 14, 1994; Haarind, R. – „Software’s New Object Lesson”, in Technology Review, February-
March, 1992; Jalics, P.J. – „COBOL on a PC: A New Perspective on a Language and Its Performance”, in
Communications of ACM 30, nr. 2, February 1987; Mandelkern, D. – „Graphical User Interfaces: The Next
Generation”, in Communication of ACM 36, nr. 4, April 1993; Morse, A., Reynolds, G. – „Overcoming Current
Growth Limits in UI Development”, in Communications of ACM 36, nr. 4, April 1993; Wiederhold, G., Wegner, P.,
Ceri, S. – „Toward Megaprogramming”, in Communications of ACM 35, nr. 11, November 1992.
14. May, J.C. – Extended the Macintosh Toolbox: Programming Menus, Windows, Dialogues and More, Addison-
Wesley, Reading, Massachusetts, 1991.
15. Autorii sunt referiţi în Mandel, T. – The Elements of User Interface Design, John Wiley & Sons, 1997, New York,
p.49.
16. Shneiderman, B. – Designing the User Interface, Addison Wesley, 1998, Third Edition,
http://www.cs.utexas.edu/users/almstrum/cs370/elvisino/rules.html

Regula Descriere
8. Reducerea La proiectarea interfeţelor trebuie luate în considerare limitele
volumului de memoriei umane pe termen scurt. Formularele vor fi simple, se vor
informaţii pe care evita trecerile de la un formular la altul etc.
utilizatorul trebuie
să-l memoreze pe
termen scurt

O tratare mai completă a principiilor generale de proiectare a interfeţelor utilizator a
fost realizată de Mandel. El le grupează în trei reguli de bază (golden rules)17:
1. Controlul aplicaţiei de către utilizator,
2. Limitarea volumului de informaţii pe care trebuie să-l memoreze utilizatorul şi
3. Uniformitatea interfeţelor utilizator.
În continuare, ne vom folosi de această clasificare pentru a descrie principalele principii
de proiectare a interfeţelor, enumerate în tabelul 2.7.

Tabel nr. 2.7 –Principalele principii de proiectare a interfeţelor utilizator
Reguli de bază Principii de proiectare
Controlul aplicaţiei 1. Utilizarea judicioasă a modurilor de lucru
de către utilizator 2. Retroacţiunea (feed-back) imediată
3. Pǎstrarea stilului de lucru al utilizatorilor
4. Alegerea între utilizarea tastaturii şi/sau a mouse-ului
5. Asigurarea transparenţei detaliilor de proiectare a
programelor şi a bazei de date
Limitarea volumului 1. Degrevarea utilizatorului de memorarea pe termen scurt
de informaţii pe care a unor informaţii
trebuie să-l 2. Proiectarea de interfeţe orientate pe recunoaştere, nu pe
memoreze amintire
utilizatorul 3. Prevederea formelor scurte de lucru
4. Relevanţa vizuală a interfeţelor
Uniformitatea 1. Uniformitatea modului de prezentare a interfeţei
interfeţelor utilizator 2. Uniformitatea în comportamentul interfeţei
3. Uniformitatea interacţiunii cu interfaţa utilizator

4.1 Controlul aplicaţiei de către utilizator

Conform acestei reguli, o interfaţă trebuie concepută astfel încât utilizatorul să simtă
că el este cel care controlează aplicaţia şi nu invers. Utilizatorul este cel care iniţiază
diferitele operaţiuni, controlând astfel derularea proceselor realizate cu calculatorul. El va
juca un rol activ şi nu unul reactiv.
Pentru a înţelege mai bine esenţa acestei reguli de bază, vom apela la o analogie. Să
considerăm că o persoană doreşte să asculte albumul „Innuendo” al formaţiei rock Queen şi
are la dispoziţie două variante: să utilizeze un magnetofon sau o combină audio
performantă, cu unitate CD. În cazul utilizării magnetofonului, „melomanul” va trebui să
potrivească banda respectivă, să-l pornească, după care să se aşeze confortabil într-un
fotoliu şi să asculte. Numai că, el va fi obligat să asculte piesele de pe album în ordinea

17. Mandel, T. – The Elements of User Interface Design, John Wiley & Sons, New York, 1997, p. 48.
61

înregistrării lor, fără a-şi putea alege o ordine preferată. Aşadar, el este sub controlul
magnetofonului.
În cazul utilizării combinei audio, ascultătorul va putea să personalizeze audiţia
albumului, în sensul alegerii ordinii pieselor sau chiar a reluării unora dintre ele. De data
aceasta, audiţia albumului este sub controlul ascultătorului. Însă, pentru o astfel de audiţie,
persoana respectivă trebuie să îndeplinească două condiţii: 1) să cunoască comenzile
combinei audio, ceva mai complexe decât în cazul magnetofonului şi 2) să cunoască
piesele de pe albumul „Innuendo”, pentru a fi în măsură să stabilească ordinea preferată de
ascultare a lor.
În mod asemănător se pune problema şi în cazul aplicaţiilor informatice. Ordinea de
execuţie a anumitor operaţii poate să fie sub controlul utilizatorului sau al aplicaţiei.
Aplicaţiile interactive, dezvoltate până în anii ’80, dispuneau de interfeţe „la modul
caracter”, în care utilizatorul era complet sub controlul acestora, el având un rol reactiv. O
astfel de interfaţă este prezentată în figura 2.5.

Doriţi să adăugaţi un nou material (d/n)? d

Introduceţi codul materialului: 108250

Introduceti denumirea materialului: Cherestea fag
Introduceti unitatea de măsură: mc
Introduceti preţul: 56,20

Doriţi sa salvaţi (d/n)? d

Fig. 2.5 Exemplu de interfaţă în care utilizatorul este sub controlul aplicaţiei

Când se aplică această regulă, se va lua în considerare categoria de utilizatori pentru
care este proiectată interfaţa, adică experienţa lor în lucrul cu calculatorul şi cea din
domeniul de activitate pentru care este dezvoltat sistemul. Revenind la analogia cu audiţia
albumului „Innuendo”, pentru ca „melomanul” să poată beneficia de avantajele oferite de
combina audio, el trebuie să cunoască comenzile acesteia şi conţinutul albumului.
Transpunând aceste două cerinţe în sfera proiectării interfeţelor, utilizatorul se va putea
bucura de deţinerea controlului asupra aplicaţiei numai dacă este familiarizat cu interfeţele
grafice şi cu sarcinile de lucru din sistemul informaţional.
În continuare, vom prezenta cele mai importante dintre principiile a căror aplicare
conduce la punerea în practică a acestei reguli.

4.1.1 Principiul utilizării judicioase a modurilor de lucru

Printr-un mod de lucru se înţelege un context în care se află aplicaţia la un moment

dat, în care utilizatorul poate efectua doar anumite operaţiuni sau de care depinde funcţia
pe care o realizează un obiect al interfeţei. De regulă, atunci când utilizatorul se află într-un
mod de lucru, nu i se permite să lucreze în altă parte a aplicaţiei.
Utilizatorii calculatoarelor sunt obişnuiţi cu modurile de lucru, deoarece ele pot fi
observate uşor în majoritatea programelor. Un exemplu comun este dat de modurile de
lucru insert/overwrite dintr-un procesor de texte, trecerea dintr-un mod de lucru în celălalt
realizându-se prin apăsarea tastei Insert.
În cele mai multe aplicaţii, formularele concepute pentru actualizarea bazei de date
conţin modul de lucru vizualizare, în care utilizatorii pot afişa informaţiile, dar nu le pot
modifica. Ecranul din figura 2.4 permite, la încărcarea acestuia, afişarea facturilor/avizelor

primite de la furnizori, dar nu şi adăugarea sau modificarea lor. Pentru a modifica datele
referitoare la un document, utilizatorul trebuie să-l selecteze şi să intre în modul de lucru
modificare, prin apăsarea butonului MODIFICA DOC. Intrarea în modul de lucru adăugare
se face prin apăsarea butonului DOC. NOU. Imediat după salvarea datelor
modificate/adăugate, se revine la modul de lucru vizualizare.
Modurile de lucru limitează controlul utilizatorului asupra aplicaţiei, deoarece acesta
nu poate realiza decât operaţiunile permise în contextul de lucru respectiv. În plus,
utilizatorul va fi nevoit să efectueze un număr suplimentar de operaţiuni, pentru a trece de
la un mod de lucru la altul. Din acest motiv, apelarea la modurile de lucru trebuie temeinic
justificată.
Chiar dacă utilizarea modurilor de lucru limitează controlul utilizatorului asupra
aplicaţiei, ele se regăsesc în majoritatea aplicaţiilor. Ele trebuie utilizate numai atunci când
sunt necesare, evitându-se plasarea utilizatorului în moduri de lucru inutile. Întrebarea
„Când este justificată şi când nu utilizarea modurilor de lucru?” nu are un răspuns general
valabil. Câteva dintre cazurile care justifică utilizarea modurilor de lucru sunt:
Utilizatorii sunt neexperimentaţi în lucrul cu interfeţele grafice sau în activităţile
derulate în cadrul sistemului, fiind de dorit un control mai bun al operaţiunilor
realizate de ei cu ajutorul calculatorului. Astfel, se evită apariţia erorilor datorate
iniţierii greşite a unor operaţiuni.
Restricţionarea accesului, atunci când există categorii de utilizatori cu drepturi de
acces diferite. Unii utilizatori pot avea drepturi de modificare sau anulare a
facturilor, iar alţii doar pe cele de vizualizare a acestora.
Simplificarea formularului, prin schimbarea funcţiilor unor butoane de la un mod
de lucru la altul, pentru a se evita includerea unui număr prea mare de butoane. De
exemplu, prin transformarea butoanelor de comandă ADAUGARE şi
MODIFICARE, din modul de lucru vizualizare, în SALVARE şi ABANDON, în
modurile de lucru adăugare şi modificare, formularul va conţine doar două butoane
în loc de patru.
Un alt aspect, demn de luat în considerare, la analiza justeţei includerii modurilor de
lucru, se referă la numărul de operaţiuni suplimentare necesare pentru trecerea de la un
mod de lucru la altul. Dacă, la introducerea facturilor/avizelor, utilizatorul va fi nevoit să
comute între modurile de lucru adăugare şi vizualizare pentru fiecare document în parte,
atunci el ar putea fi nemulţumit de productivitatea muncii sale, mai ales dacă numărul de
documente ce trebuie operate este mare. Ar fi mai simplu ca ei să poată adăuga date fără a
mai fi necesară selectarea butonului ADAUGARE, pentru fiecare document în parte. Prin
urmare, utilizarea modurilor de lucru este neproductivă în cazul operaţiunilor de
actualizare cu frecvenţă mare.
Atunci când sunt utilizate, este obligatorie semnalarea, în orice moment, a modului de
lucru în care se află utilizatorul. În acest sens, există mai multe posibilităţi. De exemplu, în
Microsoft Word, intrarea în modul de lucru „Draw” este semnalat prin schimbarea
pointerului de mouse în semnul „+”. Pentru diferenţierea între modurile vizualizare şi
modificare, se pot utiliza culori diferite pentru fundalul câmpurilor din formular, de regulă
gri pentru vizualizare şi alb pentru modificare. O altă modalitate priveşte introducerea unui
mesaj în linia de stare, care să arate în orice moment utilizatorului modul de lucru în care
se află (vezi mesajul cu roşu din formularul prezentat în figura 2.4).
Aşadar, aplicarea acestui principiu este strâns legată de cel care va fi discutat în
continuare, respectiv principiul retroacţiunii imediate.
63

4.1.2 Principiul retroacţiunii (feed-back) imediate

Acest principiu ar putea fi reformulat prin imperativul „Nu lǎsaţi utilizatorul în ceaţǎ!”.
Interfaţa trebuie sǎ indice utilizatorului, dupǎ caz, dacǎ acţiunea iniţiatǎ de el a fost
realizatǎ, fie sǎ afişeze rezultatul acţiunii sale. Dacă execuţia operaţiunii dureazǎ mai mult
timp, atunci utilizatorul trebuie să aibǎ confirmarea cǎ operaţiunea este în curs de execuţie
şi sǎ fie informat despre starea ei. Starea execuţiei unei operaţiuni poate fi afişată sub
forma timpului rǎmas pânǎ la finalizare sau sub forma procentelor din operaţiune care au
fost executate. De asemenea, este necesară precizarea modului în care operaţiunea poate fi
suspendatǎ sau anulatǎ. De exemplu, la descǎrcarea unui fişier de pe un site web, pe ecran
va fi afişat în permanenţǎ, în procente, partea din fişier care a fost transferată.
În general, informarea utilizatorului despre acţiunea iniţiatǎ de el poate fi fǎcutǎ în mai
multe moduri: prin actualizarea liniei de stare a ferestrei de lucru, prin afişarea unui mesaj
sau prin iniţierea unei casete de dialog.
Lipsa retroacţiunii creeazǎ utilizatorului o stare de nesiguranţǎ şi discomfort, şi-l
obligǎ la eforturi suplimentare, pentru a se asigura cǎ operaţiunea iniţiatǎ de el a fost
realizatǎ. Dacă, în formularul din figura 2.4, utilizatorul nu ar primi un mesaj de confirmare
a operaţiunii de anulare a unei facturi, el ar fi nevoit să verifice dacǎ operaţiunea respectivǎ
a fost înregistratǎ în baza de date, afectând astfel productivitatea muncii sale.

4.1.3 Principiul pǎstrării stilului de lucru al utilizatorilor

În general, la proiectarea unui nou sistem informatic trebuie menţinut stilul de lucru al
utilizatorilor, iar eventualele modificǎri să fie explicate acestora. Experienţa anterioarǎ,
aşteptǎrile, pǎrerile, convingerile şi dorinţele utilizatorilor trebuie să se regǎsească în
interfaţă.
Experienţa anterioarǎ a utilizatorilor cu sistemele informatice determinǎ, în bunǎ
mǎsurǎ, aşteptǎrile lor privind modul de funcţionare a noului sistem. De cele mai multe ori,
puşi în situaţii noi sau complexe, oamenii încearcǎ sǎ simplifice lumea din jurul lor şi sǎ
gǎseascǎ similitudini cu lucruri pe care ei le înţeleg şi vor acţiona în maniera în care ei cred
cǎ ar trebui sǎ se desfǎşoare acele lucruri. Prin urmare, ei vor reacţiona în funcţie de
aşteptǎrile lor. Edificator în acest sens, este întâmplarea din urmă cu câţiva ani cu angajatul
unei firme americane, care utiliza unitatea de CD-ROM ca suport pentru ceaşca de cafea,
plecând, probabil, de la experienţa anterioară şi asemănarea relativă cu dispozitivul destinat
acestui scop din autoturismul propriu.
De aceea, membrii echipei de proiectare va trebui sǎ ştie cât mai multe despre
utilizatorii sistemului, despre sarcinile de lucru pe care ei trebuie sǎ le realizeze, despre
cunoştinţele lor în domeniul informaticii, despre experienţa pe care o au în lucrul cu
sistemele informatice, cu interfeţele grafice etc. Dupǎ cum vom vedea ulterior, una din
primele etape ale procesului de proiectare a interfeţelor vizeazǎ identificarea şi descrierea
categoriilor de utilizatori din sistem.

4.1.4 Principiul alegerii între utilizarea tastaturii şi/sau a mouse-ului

Nu toţi utilizatorii sunt bucuroşi sǎ utilizeze mouse-ul, din motive subiective sau
obiective. Pe de o parte, unii utilizatori nu sunt familiarizaţi cu interfeţele grafice, ei
formându-şi unele deprinderi de lucru în utilizarea tastaturii, iar a-i forţǎ sǎ utilizeze
mouse-ul le-ar putea provoca disconfort şi, în final, insatisfacţii. Pe de altǎ parte, utilizarea

tastaturii este uneori justificatǎ de o mai mare productivitate a muncii, mai ales în cazul
operaţiunilor de rutinǎ, cu un grad mare de repetabilitate.
Sǎ ne imaginǎm că un utilizator trebuie să introducă câteva sute de documente pe zi. El
va relua operaţiunile specifice introducerii datelor pentru un document, de exemplu o
facturǎ, de câteva sute de ori. Prin utilizarea tastaturii, el îşi va forma deprinderile necesare
astfel încât sǎ piardǎ cât mai puţin timp cu privitul pe ecran şi sǎ se poatǎ concentra asupra
citirii datelor de pe document şi tastării lor. Altfel, dacǎ dupǎ fiecare facturǎ introdusǎ va
trebui sǎ priveascǎ ecranul şi sǎ utilizeze mouse-ul pentru deplasarea de la un câmp la altul
sau pentru selectarea butonului „Salvare”, randamentul sǎu se va diminua şi va creşte
oboseala acumulatǎ. El va fi nevoit sǎ schimbe mereu tastatura cu mouse-ul şi invers.
Proiectanţii trebuie sǎ conceapǎ interfeţele astfel încât utilizatorii sǎ poatǎ lucra cu
ambele echipamente. Însă, interfaţa trebuie să fie optimizată pentru utilizarea unuia dintre
cele două echipamente. Dacă sarcinile de lucru au frecvenţă mare, atunci interfaţa trebuie
optimizată pentru lucrul cu tastatura, ceea ce impune acordarea unei atenţii deosebite
facilităţilor de deplasare în formular, mai ales în ce priveşte ordinea de parcurgere a
câmpurilor. Chiar dacǎ interfaţa va fi optimizatǎ pentru utilizarea mouse-ului, vor fi create
şi facilitǎţi de lucru cu tastatura, fie şi numai de dragul utilizatorilor.

4.1.5 Principiul asigurării transparenţei detaliilor de proiectare
a programelor şi a bazei de date

Conform acestui principiu, interfaţa trebuie sǎ ascundǎ detaliile privind structura bazei
de date sau logica prelucrǎrii datelor din modulele de program. De exemplu, nu trebuie
afişate în formulare anumite coduri interne, cum ar fi codul tranzacţiilor, pe care
proiectantul bazei de date le-a inclus din anumite considerente de proiectare a bazei de
date, şi al cǎror sens nu este cunoscut şi nu intereseazǎ utilizatorii. De asemenea, aplicaţia
trebuie sǎ controleze riguros toate erorile care pot să apară în execuţia programelor, fie ele
erori ale sitemului de operare, şi sǎ furnizeze utilizatorului mesaje de eroare pe care acesta
le înţelege sau, oricum, sǎ nu-l sperie.
Un exemplu comun de încǎlcare a acestui principiu îl reprezintǎ utilitarul „Task
manager”, din sistemul de operare Windows 2000. Atunci când un program s-a blocat în
memorie, utilizatorul are posibilitatea închiderii acestuia prin intermediul utilitarului
menţionat (apǎsând tastele CTRL-ALT-DEL). Numai cǎ, acest utilitar afişeazǎ, pe lângǎ
programele lansate de utilizator, şi alte programe ale sitemului de operare, cu nume ciudate,
despre care utilizatorul nu ştie nimic. În plus, utilizatorul poate selecta şi închide oricare
din programe, ulterior el constatând funcţionarea necorespunzătoare a calculatorului.

TA 4.1
1. Care sunt avantajele proiectării unor interfeţe în care utilizatorul să deţină controlul asupra
aplicaţiei?
2. Ce presupune optimizarea interfeţei pentru lucrul cu tastatura?
3. Prezentaţi modurile de lucru în interfaţa unui soft cu care sunteti familiarizat şi explicaţi
avantajele şi dezavantajele experimentate.
Răspuns:
65

4.2 Reducerea volumului de informaţii pe care trebuie sǎ le
memoreze utilizatorul

Cercetǎrile psihologice demonstreazǎ cǎ cele douǎ componente ale sistemului de
memorare uman sunt limitate: prima componentǎ, memoria pe termen scurt, asigurǎ
regǎsirea uşoarǎ a informaţiilor reţinute, însǎ este limitatǎ în ce priveşte perioada şi
capacitatea de memorare; cea de-a doua, memoria pe termen lung, este nelimitatǎ în ce
priveşte capacitatea şi perioada de memorare, însǎ este limitatǎ în ceea ce priveşte regǎsirea
informaţiei
Aplicarea aceastei reguli presupune utilizarea calculatorului pentru acoperirea limitelor
memoriei umane. În acest sens, trebuie aplicate câteva principii de proiectare a interfeţelor,
prezentate în continuare.

4.2.1 Principiul degrevării utilizatorului de memorarea,
pe termen scurt, a unor informaţii

Memorarea pe termen scurt este utilǎ în reţinerea informaţiilor care pot fi regǎsite
rapid, dar care pot fi pǎstrate o perioadǎ scurtǎ de timp şi în volum redus (circa 5 – 9
elemente pentru aproximativ 30 de secunde). De aceea, utilizatorii nu trebuie forţati sǎ
memoreze unele informaţii pe termen scurt, atunci când ei trec de la o operaţiune la alta, ci
aplicaţia sǎ facǎ acest lucru pentru ei.
Deşi atât de simplu, acest principiu este încǎlcat în practicǎ deseori. De multe ori,
utilizatorii deschid un formular pentru cautǎ o informaţie, iar dupǎ ce o gǎsesc o noteazǎ pe
hârtie, în vederea folosirii ei în alt formular.
Aşa se întâmplǎ la unele bǎnci, atunci când un client solicitǎ informaţii despre contul
sǎu. El este întrebat, mai întâi, de numǎrul contului, iar dacǎ nu-l cunoaşte i se solicitǎ
numele. Funcţionarul bǎncii deschide formularul pentru cǎutarea şi afişarea informaţiilor
despre clienţii bǎncii, unde va gǎsi numǎrul contului, pe care-l va nota pe hârtie. Apoi, el
va închide formularul respectiv şi va deschide un altul, pentru cǎutarea şi afişarea
informaţiilor despre conturile clienţilor bǎncii iar, pe baza numǎrului de cont notat anterior,
va putea regǎsi şi afişa informaţiile solicitate de client. Să reţinem sugestia funcţionarului
de la ghişeu: „Vă rugăm ca data viitoare sǎ aveţi notat numǎrul contului pentru mai multǎ
operativitate!”.

4.2.2 Principiul interfeţei orientate pe recunoaştere, nu pe amintire

Problema majorǎ, în cazul memorării pe termen lung, este legatǎ de regǎsirea

informaţiei, iar aplicaţia trebuie sǎ sprijine utilizatorul în acest sens.
Existǎ douǎ metode principale de regǎsire a informaţiei din memorie: recunoaşterea şi
amintirea. Recunoaşterea presupune regǎsirea informaţiei pe baza unei sugestii, în timp ce
amintirea implicǎ regǎsirea informaţiei fǎrǎ existenţa vreunei sugestii. Evident, este mult
mai comod pentru utilizator sǎ recunoascǎ o informaţie, decât sǎ încerce sǎ şi-o aminteascǎ.
De exemplu, atunci când este posibil, este preferabilǎ furnizarea unei liste, din care
utilizatorul sǎ recunoascǎ şi sǎ selecteze elementul dorit, decât sǎ fie obligat sǎ şi-l
aminteascǎ şi sǎ-l introducǎ într-o cǎsuţǎ de text. De asemenea, este mai bine sǎ selecteze o
comandǎ din meniu decât sǎ o introducǎ de la tastaturǎ.
Un alt aspect important priveşte apelarea la metafore. Ele faciliteazǎ învǎţarea şi
exploatarea aplicaţiei, deoarece utilizatorii pot lucra mai uşor cu un obiect nou dacǎ îl
asociazǎ cu un alt obiect, din lumea realǎ, care îi este familiar, permiţându-i astfel
transferarea cunoştinţelor şi experienţei trecute. Apelarea la metafore dǎ încredere
utilizatorilor, iar ei pot învǎţa prin explorarea interfeţei. De exemplu, în sistemul de operare
Windows, transferarea unor fişiere în „Recycled” îl va determina pe utilizator sǎ înţeleagǎ
aceastǎ operaţiune exact ca aruncarea unui dosar la coş, de unde, pentru o perioadǎ de timp,
îl mai poate recupera.

4.2.3 Principiul prevederii formelor scurte de lucru

Aplicarea acestui principiu presupune definirea unor cǎi mai directe de realizare a
diferitelor operaţiuni de cǎtre utilizator, prin reducerea numǎrului de apǎsǎri de taste sau de
acţiuni cu mouse-ul. Astfel, se reduce volumul de informaţii pe care utilizatorul trebuie sǎ-l
memoreze, pentru a lucra cu sistemul, şi va creşte productivitatea muncii sale.
Existǎ douǎ modalitǎţi de definirea a unor scurtǎturi:
Utilizarea comenzilor mnemonice. Aceste comenzi pot fi întâlnite în majoritatea
programelor. Ele apar, de regulă, sub forma un singur caracter alfanumeric, şi
înlesnesc memorarea unor informaţii. Comenzile mnemonice pot fi utilizate pentru
selectarea unei opţiuni din meniul aplicaţiei sau a unui element dintr-o căsuţă de tip
listǎ. De exemplu, meniul tip bară din Microsoft Word conţine comenzile
mnemonice F pentru File, E pentru Edit, V pentru View sau H pentru Help.
Utilizarea tastelor speciale sau a combinaţiilor de taste pentru iniţierea mai directă
operaţiunilor. Spre exemplu, tasta ALT, în mediul Windows, activeazǎ meniul; în
Visual FoxPro, combinaţia CTRL+W determinǎ salvarea ultimelor modificǎri
efectuate în tabela curentǎ şi închiderea ferestrei Browse.

4.2.4 Principiul relevanţei vizuale

Relevanţa vizualǎ este asiguratǎ de obiectele care compun interfaţa, şi se referǎ la:
sugestivitatea lor, modul de organizare şi simplitatea interfeţei.
Sugestivitatea obiectelor presupune ca ele sǎ fie uşor de înţeles şi sǎ reprezinte o
transpunere simplificatǎ a obiectelor reale. În acest sens, se va urmǎri nominalizarea
conţinutului obiectelor care conţin date (cǎsuţe de text, cǎsuţe combinate, căsuţe de tip listă
etc.), prin titluri explicite şi inteligibile, sau atribuirea unor nume sugestive butoanelor şi
grupurilor de obiecte din formulare.
67

Organizarea obiectelor interfeţei vizeazǎ gruparea şi aranjarea lor. Opţiunile,
comenzile şi obiectele de date legate între ele, din punct de vedere logic, trebuie grupate şi
delimitate de celelalte prin linii sau chenare. Aranjarea obiectelor trebuie sǎ fie în
concordanţǎ cu cerinţele funcţionale ale utilizatorilor, astfel încât sǎ le permitǎ acestora o
navigare uşoarǎ de la un obiect la altul, precum şi în interiorul lor. De asemenea,
formularele pentru culegerea datelor trebuie să reflecte structura documentului de pe care
se preiau datele. Utilizatorul va învǎţa mai uşor semnificaţia şi rolul câmpurilor din
formular, va sesiza mai repede informaţiile afişate şi, în consecinţă, va avea o productivitate
sporită.
Prin simplitatea interfeţei se urmăreşte evitarea creării de ecrane încǎrcate, greu de
urmǎrit şi utilizat. Dacǎ un ecran conţine prea multe informaţii, atunci utilizatorul va fi
derutat şi nu va şti unde sǎ se uite, pentru a gǎsi informaţia dorită. Cu cât o interfaţǎ este
mai simplǎ, cu atât ea este mai uşor de învǎţat şi utilizat. Însǎ, nu trebuie sacrificatǎ
funcţionalitatea aplicaţiei de dragul simplitǎţii. Gǎsirea unui echilibru între cele douǎ
caracteristici constituie o provocare pentru proiectant şi impune participarea activǎ a
utilizatorilor în activitatea de proiectare.

TA 4.2
1. Enumeraţi modalităţile de aplicare a principiului interfeţei orientate spre recunoaştere.
2. Care sunt avantajele prevederii formelor scurte de lucru?
Răspuns:

4.3 Uniformitatea interfeţelor utilizator

Uniformitatea interfeţelor poate fi obţinută prin aplicarea aceloraşi convenţii de
proiectare a acestora, atât în cadrul unei aplicaţii, cât şi în aplicaţii diferite. Multe
organizaţii au adoptat standardizarea interfeţelor utilizator la nivelul tuturor aplicaţiilor,
conştientizând beneficiile ce pot fi obţinute18.
Uniformitatea interfeţelor permite utilizatorilor transferarea experienţei lor anterioare
şi a cunoştinţelor acumulate, ei fiind în mǎsurǎ sǎ înveţe mai uşor aplicaţiile noi. Interfaţa
noii aplicaţii va fi familiarǎ şi predictibilǎ, oferind utilizatorului sentimentul de stabilitate.
Altfel, procesul de învǎţare poate fi inhibat, iar utilizatorul nu va mai avea încredere nici în

18. Marakas, G. – Systems Analysis and Design. An Active Approach, Prentice Hall, New Jersey, 2001, p. 347.

noua aplicaţie, nici în ceea ce a învǎţat anterior. Un alt efect benefic al uniformităţii
interfeţelor priveşte reducerea erorilor în culegerea datelor.
Uniformitatea interfeţelor presupune luarea în considerare a următoarelor aspecte:
Uniformitatea în cadrul aplicaţiei.
Uniformitatea în cadrul sistemului, între diferitele aplicaţii existente. Funcţiunile
similare, din aplicaţii diferite, trebuie sǎ ofere interfeţe similare.
Uniformitatea cu sistemul de operare. Respectarea standardelor de proiectare a
interfeţelor specifice sistemului de operare utilizat, cu care utilizatorul este deja
familiarizat, va asigura învǎţarea şi exploatarea mai facilǎ a aplicaţiei.
Uniformitatea interfeţelor utilizator este urmărită sub trei aspecte: al modului de
prezentare, al comportamentului şi al interacţiunii, fiecare fiind tratat, în continuare, ca
principiu dinstinct.

4.3.1 Principiul uniformitǎţii modului de prezentare a interfeţei

Aplicarea acestui principiu presupune ca utilizatorul sǎ vadǎ informaţiile şi obiectele

interfeţei în acelaşi mod, din punct de vedere logic, fizic şi vizual, în cadrul întregii
aplicaţii/sistem. Dacǎ într-un formular conţinutul unei cǎsuţe de text pe fond de culoare gri
nu poate fi modificat, această operaţiune fiind permisă numai în cazul în care culoarea de
fond este albǎ, atunci aceastǎ regulǎ trebuie respectatǎ în toate formularele aplicaţiei.
Modificarea acestei reguli, într-un formular, poate provoca o stare de nelinişte utilizatorului.
De asemenea, dacǎ pentru introducerea unui anumit tip de date se utilizeazǎ un anumit tip
de obiect, atunci el trebuie utilizat în toate ecranele care solicitǎ introducerea acelui tip de
datǎ. Numele comenzilor similare din formulare diferite trebuie sǎ fie aceleaşi pentru a
încuraja învǎţarea exploratorie.
Conform acestui principiu, trebuie respectatǎ şi uniformitatea esteticii interfeţei.
Utilizarea aceleiaşi scheme de culori, a aceloraşi fonturi şi a aceleiaşi strategii de plasare a
obiectelor va duce la obţinerea unei interfeţe mai plǎcute.

4.3.2 Principiul uniformitǎţii în comportamentul interfeţei

Acelaşi obiect trebuie sǎ aibă un comportament similar, în situaţii şi ecrane diferite.

Schimbarea comportamentului obiectelor interfeţei în cadrul aplicaţiei sau de la o aplicaţie
la alta, cum ar fi butoanele sau opţiunile din meniu, poate determina un comportament
superstiţios, mistic din partea utilizatorilor. Ei vor vedea cǎ, în urma realizǎrii aceleiaşi
acţiuni, obţin rezultate diferite. De exemplu, selectarea oricǎrei opţiuni dintr-un meniu-bară
trebuie, întotdeauna, sǎ afişeze un meniu „drop-down” , din care utilizatorul sǎ poatǎ iniţia
operaţiunea doritǎ, şi nu sǎ execute o acţiune în mod direct. Dacǎ utilizatorul este obişnuit
sǎ se întâmple o anumită acţiune la dublu clic pe un anumit tip de obiect, cum ar fi o cǎsuţǎ
de text, atunci aceeaşi acţiune trebuie sǎ se realizeze când face dublu clic pe un alt obiect
de acelaşi tip.
Uniformitatea în comportament nu priveşte doar obiectele interfeţei, ci şi secvenţa
dialogurilor. Aceeaşi operaţiune, realizatǎ la momente diferite, trebuie sǎ implice aceeaşi
succesiune de paşi, cu aceleaşi opţiuni de lucru pentru fiecare pas în parte. Dacǎ totuşi
acest lucru nu este posibil, atunci utilizatorul trebuie informat.
O atenţie deosebitǎ trebuie acordatǎ mesajelor de informare sau de eroare. De câte ori
este posibil, se va încerca afişarea aceluiaşi mesaj, dacǎ utilizatorul se aflǎ în aceeaşi
situaţie, dar în locuri diferite ale aplicaţiei. În acest sens, este recomandată crearea unei
69

biblioteci de mesaje, în care sǎ se atribuie fiecǎrui mesaj un identificator. Un mesaj va
putea fi apelat în orice parte a aplicaţiei prin intermediul identificatorului său.

4.3.3 Principiul uniformităţii interacţiunii cu interfaţa utilizator

Utilizatorul nu trebuie forţat inutil ca într-o parte a aplicaţiei sǎ lucreze cu tastatura, iar
în altǎ parte sǎ utilizeze mouse-ul. De asemenea, comenzile mnemonice, tastele speciale şi
combinaţiile de taste trebuie sǎ aibǎ aceleaşi funcţiuni de la un program la altul. De
exemplu, astăzi în toate mediile de lucru, F1 este utilizată pentru activarea facilităţilor de
ajutor (Help).
*
* *
Toate principiile prezentate anterior trebuie vǎzute ca un sistem, între multe dintre ele
existând relaţii de interdependenţǎ, dar şi antagonice. Proiectantul îşi va defini propriul
sistem, prin alegerea principiilor care se potrivesc cel mai bine platformelor hardware,
sistemului de operare şi altor categorii de software utilizate, cerinţelor funcţionale ale
sistemului şi nevoilor utilizatorilor. Respectarea acestor principii poate însemna eforturi
suplimentare de proiectare, programare şi testare a aplicaţiei, însǎ ele vor fi contrabalansate
de satisfacţiile pe care le vor avea utilizatorii şi, implicit, de reducerea riscului de
neacceptare a sistemului.


TA 4.1 1) Posibilitatea alegerii ordinii de realizare a anumitor operaţiuni;
productivitatea muncii sporită în cazul operaţiunilor de culegere a datelor cu frecvenţă
mare; uşurinţa invăţării interfeţei utilizator; 2) Includerea facilităţilor de deplasare în
formular, stabilirea atentă a ordinii de parcurgere a câmpurilor formularului. 3) Vezi
exemplul cu procesorul de text de la p.62.
TA 4.2 1) Furnizarea unei liste din care utilizatorul să aleagă elementul dorit; furnizarea unui
meniu din care utilizatorul să aleagă comanda dorită; utilizarea metaforelor. 2) Reducerea volumului
de informaţii de memorat şi creşterea productivităţii activităţilor de culegere a datelor.


1) Uniformitatea interfetelor utilizator asigura:
a) reducerea numarului de erori in culegerea datelor
b) reducerea numarului de operatiuni pe care utilizatorul trebuie sa le efectueze
c) productivitate sporita in cazul operatiunilor repetitive
d) invatarea mai usoara a aplicatiei de catre utilizatorii noi

2) Includerea modurilor de lucru in proiectarea interfetelor utilizator este recomandata in
urmatoarele situatii:
a) operatiunile de actualizare a datelor sunt caracterizate de frecventa si grad de
repetitivitate mare
b) se doreste restrictionarea accesului pentru diferite categorii de utilizatori
c) se urmareste simplificarea formularului (ecranului)
d) utilizatorii au o bogata experienta in lucrul cu interfetele grafice

1. În ce constă uniformitatea interfeţei utilizator? Enumeraţi principiile de lucru pentru
obţinerea ei.
2. Enumeraţi şi descrieţi trei principii de proiectare a interfeţelor care asigură uşurinţa învăţării
acestora.
3. Enumeraţi şi descrieţi trei principii de proiectare a interfeţelor care asigură uşurinţa utilizării
acestora.

4.6 Bibliografie

1. Mandel, T. – The Elements of User Interface Design, John Wiley & Sons, New York, 1997,
p. 47-79
Jersey, 2001, pp. 343-354
71


Demersul proiectării interfeţelor utilizator. Controlul
datelor în interfeţele utilizator

Obiective:
Descrierea etapelor de lucru în proiectarea interfeţelor utilizator
Definirea rolului utilizatorilor în proiectarea interfeţelor utilizator
Prezentarea regulilor de proiectare a paginilor Web
Descrierea mecanismelor pentru controlul corectitudinii şi validităţii datelor de intrare
Formularea specificaţiilor de proiectare a interfeţelor utilizator
Evaluarea prototipurilor pentru interfaţa utilizator din calitatea de utilizator al sistemului
informaţional
Proiectarea interfeţelor utilizator conform unui demers adaptat la obiectivele definite şi
care să permită implicarea directă a utilizatorilor
Identificarea cerinţelor privind corectitudinea şi validitatea datelor de intrare
Definirea mecanismelor pentru controlul corectitudinii şi validităţii datelor de intrare
Elaborarea specificaţiilor detaliate de proiectare a interfeţelor utilizator

5.1 Demersul proiectării interfeţelor utilizator ............................................................................ 71
5.1.1 Culegerea şi analiza informaţiilor de la utilizatori.......................................................... 74
5.1.2 Proiectarea interfeţei utilizator........................................................................................ 76
5.1.3 Construirea interfeţei utilizator ....................................................................................... 80
5.1.4 Evaluarea şi validarea interfeţei utilizator ...................................................................... 82
5.2 Reguli de proiectare a meniurilor .......................................................................................... 83
5.3 Aspecte privind proiectarea interfeţelor web ......................................................................... 84
5.4 Controlul datelor în interfeţele utilizator ............................................................................... 85
5.5 Formularea specificaţiilor de proiectare a interfeţelor........................................................... 88
5.8 Bibliografie ............................................................................................................................ 89

5.1 Demersul proiectării interfeţelor utilizator

Proiectarea interfeţelor utilizator pune accentul pe definirea elementelor componente
ale interfeţei, cu care vor interacţiona utilizatorii, pentru a-şi realiza sarcinile de lucru.
Conştientizând importanţa interfeţelor în succesul noului sistem informaţional, specialiştii
s-au preocupat de găsirea unor tehnici de proiectare, care să plaseze în centrul atenţiei şi să
implice în mod direct utilizatorii în dezvoltarea sistemului informaţional. Aceste tehnici
sunt referite sub titulatura de proiectare orientată spre utilizatori.
Această abordare are la bază trei principii importante19:
Orientarea spre utilizator şi atribuţiile sale de serviciu, încă de la începutul
dezvoltării sistemului informaţional. Dacă în abordarea tradiţională accentul era

19. Satzinger J.W., Jackson, R.B., Burd, S.D. – Systems Analysis and Design in a Changing World, Course Technology,
Thomson Learning, 2002, Boston, p. 441.

pus pe cerinţele funcţionale ale sistemului, acum analiştii trebuie să axeze pe
identificarea categoriilor de utilizatori şi să înţeleagă cerinţele lor specifice. Ei
trebuie să găsească răspunsuri la întrebări precum: Ce cunoştinţe şi experienţă au
ei? Cum învaţă ei? Cum ar dori ei să lucreze? Ce-i motivează?
Evaluarea specificaţiilor de proiectare în vederea asigurării uşurinţei învăţării şi
utilizării noului sistem. Obţinerea acestei caracteristici reprezintă o sarcină dificilă,
datorită existenţei unor categorii diferite de utilizatori, cu preferinţe şi abilităţi
diversificate, dificil de armonizat. Dacă interfaţa este flexibilă, utilizatorii mai
puţin experimentaţi se pot simţi neliniştiţi, iar o interfaţă prea rigidă creează
frustrări utilizatorilor experimentaţi. De asemenea, uşurinţa în învăţare este adesea
în conflict cu uşurinţa în utilizare. O aplicaţie bazată pe un meniu, cu multe ecrane,
mesaje de dialog şi informaţii explicative detaliate este uşor de învăţat, însă greu
de utilizat, deoarece implică numeroase interacţiuni între utilizator şi calculator. O
astfel de interfaţă este indicată atunci când ea este utilizată rar. Utilizatorii care
folosesc sistemul zilnic, în mod intensiv, preferă o interfaţă mai flexibilă, cu
comenzi apelabile direct, prin combinaţii de taste, cu formulare mai încărcate.
Interfaţa va fi mai greu de învăţat, însă ea le va permite utilizatorilor să obţină un
plus de eficacitate.
Angajarea unui proces iterativ de dezvoltare. Implicarea utilizatorilor în procesul
de dezvoltare a sistemului poate fi obţinută, cel mai bine, prin organizarea
activităţilor într-un proces iterativ, utilizând tehnica prototipizării. Activităţile vor
fi reluate de mai multe ori, prototipul fiind supus modificării şi evaluării din partea
utilizatorilor, în cadrul fiecărei iteraţii. Procesul iterativ se va încheia după ce
utilizatorii îşi vor da acordul asupra interfeţei rezultate.
În continuare vom descrie un proces iterativ de proiectare a interfeţelor, care să pună în
aplicare cele trei principii discutate anterior. El se prezintă sub forma unei spirale (vezi
figura 2.6), formată din patru faze20:
1. Colectarea şi analiza informaţiilor de la utilizatori,
2. Proiectarea interfeţelor,
3. Construirea interfeţelor şi

4. Validarea.

2) Proiectarea
Proiectarea 1) Analiza

3) Construirea
Construirea 4) Validarea
Fig. 2.6 Procesul iterativ de proiectare a interfeţelor utilizator

Modelul în spirală relevă faptul că, fiecare dintre fazele enumerate mai sus va fi reluată
de mai multe ori, astfel încât fiecare iteraţie va introduce noi cerinţe şi specificaţii de
proiectare, care vor fi implementate şi testate de fiecare dată. Procesul iterativ va continua

20. Mandel, T. – The Elements of User Interface Design, John Wiley & Sons, New York, 1997, p. 251.
73

până când toate cerinţele identificate au fost înglobate în specificaţiile de proiectare ale
interfeţei, iar utilizatorul îşi va da acordul asupra rezultatului proiectării.
În paragrafele următoare, vom descrie activităţile specifice fiecăreia dintre cele patru
faze. De asemenea, vom relua modelul de studiu de caz privind sistemul de gestiune a
clienţilor şi ne vom ocupa de proiectarea ecranului pentru preluarea în sistem a comenzilor
primite de la clienţi şi a secvenţei de dialoguri necesare pentru obţinerea raportului
„Situaţia vânzărilor pe gestiuni şi facturi”, proiectat în capitolul anterior.
Necesitatea proiectării unui ecran (formular) pentru actualizarea comenzilor poate fi
stabilită în urma studierii diagramelor fluxurilor de date. În diagrama de nivel 0 a sistemului
de gestiune a clienţilor pot fi observate trei fluxuri de intrare care provin de la entitatea
externă Client: Comandă nouă, Date de identificare şi Date modificare comandă. Ele se
regăsesc şi în diagrama de nivel 1 pentru procesul „Introducere comandă”, aşa cum este
redată în caseta 2.1.
Cele trei fluxuri sugerează necesitatea preluării în sistem şi a actualizării datelor privind
comenzile clienţilor. Proiectantul îşi va continua munca prin studierea cu atenţie a
cerinţelor informaţionale culese şi structurate în faza de analiză, în partea din diagramele
fluxurilor de date care detaliază procesul corespunzător (în modelul nostru, diagrama de
nivel 1 pentru procesul „Introducere comandă”), precum şi în dicţionarul metadatelor.

Caseta nr. 2.1 – Diagrama de nivel 1 pentru funcţia „Introducere comandă”

Catalog
Comanda-noua

Client

Tranzactii comenzi
Date-
produs

Date-
modificare-
Nomenclator
produse
comanda
Date-comezi-
modificate
1.1
Cantitate-
Date-comenzi-
inregistrate
Verificare existenta

Clienti
Clienti
Date-client
existenta produs Sistem vanzari
1.3

Date-comenzi-noi
Informatii-limita-
creditare-clienti
Actualizare
comenzi
Date-de-identificare si-modificate

Client Date-comenzi-modificate

Nota-confirmare-

Cantitate-
1.2

comanda
Nomenclator
produse
comanda-
modificata
Cantitate-comanda-noua
Nota-confirmare-
modificare-comanda
Inregistrare

comanda noua Date-
comanda-noua
Comenzi-de-onorat Nomenclator
Comenzi
Comenzi Date-
produse
comenzi-
existente
Date-
client Informatii-clienti-noi
Depozit-livrari

Date-
comenzi-

1.4
inregistrate

Tip-
comanda
Clienti
Date-client
Decizii-politici- Generare
creditare-clienti rapoarte comenzi

Tranzactii comenzi
Date-produs

Conducere
Conducere
Rapoarte-privind-
comenzile

Catalog

Conducere
Conducere

5.1.1 Culegerea şi analiza informaţiilor de la utilizatori

Dezvoltarea unui sistem informaţional trebuie să înceapă cu definirea clară a

problemelor pe care utilizatorul doreşte să le rezolve cu ajutorul noului sistem, înţelegerea
şi descrierea atribuţiilor de serviciu şi a modului în care utilizatorul le realizează. Prin
urmare, proiectarea interfeţelor utilizator va începe cu identificarea categoriilor de
utilizatori şi formularea cerinţelor acestora. Chiar dacă această fază este derulată în cadrul
analizei sistemului, acum vom prezenta câteva repere, care trebuie atinse în analiza
sistemului, pentru a se asigura premisele unei bune proiectări a interfeţelor utilizator.
În această fază sunt derulate cinci activităţi: determinarea profilului utilizatorilor,
analiza atribuţiilor de serviciu ale acestora, culegerea cerinţelor utilizatorilor, analiza
mediului de lucru şi armonizarea cerinţelor utilizatorilor cu atribuţiile lor de serviciu.

Determinarea profilului utilizatorilor

În cadrul acestei activităţi, analistul trebuie să identifice categoriile de utilizatori, să

înţeleagă percepţia fiecărei categorii asupra sistemului şi să formuleze cerinţele lor
specifice.
Categoriile de utilizatori pot fi identificate pe baza unei matrice, rezultată prin
combinarea a două dimensiuni: cunoştinţele în domeniul de activitate, pentru care se
dezvoltă sistemul informaţional, şi experienţa în lucrul cu sistemele informatice. Rezultă
patru categorii de utilizatori:
utilizatori care nu au cunoştinţe în domeniul lor de activitate şi nici experienţă în
utilizarea calculatorului;
utilizatori fără cunoştinţe în domeniul lor de activitate, dar familiarizaţi cu
sistemele informatice;
utilizatori care au o experienţă bogată în domeniul lor de activitate, dar mai puţină
experienţă în utilizarea calculatorului;
utilizatori experimentaţi atât în domeniul lor de activitate, cât şi în utilizarea
sistemelor informatice.

Analiza atribuţiilor de serviciu ale utilizatorilor

Acum se urmăreşte identificarea şi descrierea atribuţiilor de serviciu ale utilizatorilor,

a modului în care ei realizează aceste sarcini. După descrierea situaţiei existente, se va
încerca reorganizarea sarcinilor de serviciu, astfel încât să se beneficieze din plin de
avantajele oferite de noile tehnologii angajate în dezvoltarea sistemului. Această problemă
se pune, mai ales, în situaţia trecerii de la interfeţe clasice la interfeţe grafice, de la un
sistem manual la unul informatizat, sau de la unul neintegrat la unul integrat.
Schimbările privind modul de realizare a sarcinilor de serviciu trebuie să fie bine
justificate din punctul de vedere al optimizării lor, iar efectele lor pozitive şi/sau negative
să fie aduse la cunoştinţa utilizatorilor. Mai mult, utilizatorii trebuie implicaţi activ în
regândirea sarcinilor lor de muncă. Altfel, modificările radicale şi nejustificate pot crea
frustrări în rândul utilizatorilor şi, implicit, sporirea riscului de neacceptare a noului sistem.
Această etapă de lucru trebuie să ofere răspunsuri la unele întrebări, precum:
Care sunt sarcinile realizate de utilizatori?
Ce atribuţii sunt cele mai importante pentru activitatea desfăşurată de utilizator?
Care sunt operaţiunile necesare pentru realizarea unei atribuţii de serviciu?
Cu ce scopuri realizează utlizatorul aceste atribuţii?
75

Care sunt informaţiile de care are nevoie utilizatorul pentru a-şi îndeplini atribuţiile?
Care sunt rezultatele obţinute pentru fiecare atribuţie de serviciu?
Cum lucrează utilizatorii pentru îndeplinirea atribuţiilor lor (manual, pe calculator
etc.)?
Care este frecvenţa de realizare a fiecărei sarcini de serviciu?
Cum ar putea sistemul să-l ajute pe utilizator în realizarea atribuţiilor sale?

Identificarea cerinţelor de lucru

În acest moment, se vor culege informaţiile privind doleanţele utilizatorilor, cu privire

la ce trebuie să ofere şi cum trebuie să arate interfeţele. Cerinţele utilizatorilor vor putea fi
culese cu ajutorul tehnicilor specifice, cum ar fi interviul şi chestionarul. În cazul în care
utilizatorii nu sunt în măsură să-şi specifice cerinţele, proiectantul va construi un prototip al
fiecărei interfeţe, pe baza rezultatelor din primii doi paşi, pe care-l va supune apoi atenţiei
acestora. Având în faţă un astfel de prototip, utilizatorii vor putea să facă observaţii şi să-şi
exprime cerinţele.
În general, cerinţele utilizatorilor se pot referi la reducerea numărului de erori în
culegerea datelor, automatizarea unor activităţi manuale, sporirea vitezei de culegere a
datelor, efectuarea anumitor verificări asupra datelor introduse, semnalarea unor situaţii de
excepţie etc.

Analiza mediului de lucru al utilizatorilor

Prin analiza mediului de lucru se urmăreşte determinarea caracteristicilor de mediu

care pot influenţa activitatea utilizatorilor. Vor fi culese informaţii cu privire la
caracteristicile fizice ale mediului de lucru (luminozitate, zgomote, spaţiu, temperatură
etc.), aspectele de ergonomie a muncii, nevoile speciale ale utilizatorilor cu diverse
infirmităţi etc.

Armonizarea cerinţelor utilizatorilor cu sarcinile lor de serviciu

În finalul acestei faze, se va verifica dacă cerinţele exprimate de utilizatori corespund

cu caracteristicile sarcinilor de serviciu pe care ei trebuie să le realizeze. Analistul va
încerca să ofere utilizatorilor mai mult decât ceea ce au cerut ei, dar şi să explice acestora
situaţiile în care anumite cerinţe nu pot fi rezolvate. De exemplu, dacă utilizatorul are
nevoie numai de informaţii de tip text, atunci nu se justifică proiectarea unei interfeţe care
să ofere facilităţi de lucru multimedia.
În caseta 2.2 sunt prezentate rezultatele acestei faze pentru proiectarea ecranului de
actualizare a comenzilor.

Caseta nr. 2.2 – Rezultatele fazei de colectare şi analiză a informaţiilor necesare

proiectării ecranului pentru actualizarea comenzilor
Profil utilizatori

- abilităţi minime în utilizarea calculatorului;

- o bună cunoaştere a produselor firmei;

- nivel mediu de experienţă în preluarea şi prelucrarea comenzilor.

Activităţile utilizatorilor

- înregistrarea unei comenzi noi;

- modificarea unei comenzi;

- anularea unei comenzi;

- vizualizarea datelor privind comenzile unui client.

Cerinţele utilizatorilor

- timpi mici de răspuns, mai ales în cazul primirii comenzilor prin telefon;

- interfeţe asemănătoare cu cele din mediul Windows;

- posibilitatea de tipărire a comenzilor;

- posibilitatea de transmitere de notificări către client, cu privire la înregistrarea
comenzii sale, mai ales în cazul primirii ei prin telefon;

- oferirea de informaţii privind stocul disponibil;

- servirea simultană a mai multor utilizatori;

- flexibilitatea derulării dialogurilor pentru situaţia primirii comenzii prin telefon;

- întreruperea şi abandonarea unei activităţi.

Mediul de lucru al utilizatorului

- cerinţele standard pentru utilizarea desktop-urilor conectate la reţeaua firmei pentru
accesarea bazei de date, în condiţiile utilizării telefonului;

- utilizarea de laptop-uri conectate la Internet pentru accesarea bazei de date a firmei
de la sediul clienţilor;

- servirea simultană a mai multor utilizatori.

Armonizarea cerinţelor cu sarcinile utilizatorilor

- stocurile trebuie actualizate la timp pentru a oferi clienţilor informaţii corecte;

- reţeaua de calculatoare a firmei trebuie să fie capabilă să gestioneze simultan cererile
mai multor utilizatori, în timp cât mai scurt.

5.1.2 Proiectarea interfeţei utilizator

Mulţi sunt tentaţi ca, dupǎ parcurgerea activitǎţilor din faza anterioarǎ, sǎ ignore
această etapă de lucru şi să treacǎ direct la construirea interfeţelor şi scrierea programelor.
Chiar dacǎ aceastǎ fazǎ solicitǎ timp şi eforturi semnificative, parcurgerea ei va asigura
obţinerea unor interfeţe de calitate. În altă ordine de idei, ignorarea acestei faze ar face
imposibilă punerea în practică a procesului iterativ şi, implicit, angajarea directă a
utilizatorilor în proiectarea interfeţelor.
Paşii ce trebuie parcurşi în această fază sunt: definirea
obiectivelor de calitate a interfeţelor, formularea
scenariilor pentru fiecare sarcină de serviciu, definirea
obiectelor şi acţiunilor interfeţei utilizator,
stabilirea modului de reprezentare vizuală a obiectelor interfeţei.

Definirea obiectivelor

Obiectivele privind calitatea interfeţelor utilizator pot fi definite, de o manierǎ mai

generalǎ, sub forma sintagmelor uşor de învǎţat şi uşor de utilizat. Însǎ, ele trebuie definite
77

într-o manierǎ mai detaliatǎ şi mai concretǎ, în măsură sǎ permitǎ cuantificarea lor. Ele vor
servi mai bine nu doar la proiectarea interfeţelor, ci şi la testarea acestora.
Booth defineşte patru factori relativi la calitatea interfeţelor (usability) 21:
utilitatea (usefulness) reprezintă măsura în care produsul (interfaţa) permite
utilizatorului să-şi atingă scopurile sale. Prin intermediul acestui factor, se evaluează
motivaţia utilizatorilor de a folosi produsul respectiv.
eficacitatea se referă la uşurinţa şi rapiditatea cu care utilizatorii îşi pot realiza
sarcinile de lucru.
uşurinţa învăţării este evaluată prin prisma timpului de instruire necesar pentru ca
utilizatorii să obţină un anumit nivel de competenţă în utilizarea sistemului.
atitudinea priveşte percepţia şi opiniile utilizatorilor asupra celorlalţi trei factori,
enumeraţi anterior. În fapt, se ia în considerare ceea ce gândesc utilizatorii cu
privire la calitatea interfeţei.
Obiectivele privind calitatea interfeţei trebuie definite pentru fiecare din cei patru
factori, amintiţi anterior. În caseta 2.3 sunt prezentate obiectivele de calitate definite pentru
ecranul de culegere a datelor privind comenzile primite de la clienţi.

Caseta nr. 2.3 – Obiectivele de calitate urmărite la proiectarea
ecranului pentru actualizarea comenzilor

Factorii calităţii Obiectivele de calitate

Utilitatea După 5 scenarii de lucru, 90% dintre utilizatori vor fi capabili să
realizeze cu succes o operaţiune.
Eficacitatea După 5 scenarii de lucru, 75% dintre utilizatori vor fi capabili să
realizeze cu succes o operaţiune, în mai puţin de 2 minute
Uşurinţa invăţării După o oră de instruire, toţi utilizatorii vor fi capabili să realizeze cele
mai importante sarcini de lucru.
Atitudinea După efectuarea a 5 scenarii de lucru, 85% dintre utilizatori vor aprecia
satisfacţia obţinută prin nivelul 5.5, pe o scară de la 1 la 7.

Definirea scenariilor de lucru

Un scenariu reprezintă o descriere generală unei atribuţii de serviciu, sub forma unei
succesiuni de operaţiuni pe care le realizează utilizatorul. Scenariile de lucru sunt utile nu
doar la proiectarea interfeţelor, ci şi la testarea lor. Neidentificarea tuturor scenariilor de
lucru poate determina creşterea probabilităţii de omitere a unui obiect sau a unei acţiuni şi,
implicit, obţinerea unei aplicaţii cu funcţionalitate incompletă. Se vor urmări identificarea
şi definirea de scenarii de lucru distincte, pentru fiecare categorie de utilizatori, ţinând cont
de caracteristicile lor.
Este foarte important de reţinut că scenariile definite trebuie să ghideze proiectarea
interfeţelor şi nu invers, adică proiectarea mai întâi a interfeţelor şi definirea ulterioară a
scenariilor. Altfel, faza de testare va porni de la premise greşite, fiind testate scenariile care
oricum pot fi realizate prin intermediul interfeţei şi nu scenariile de lucru reale.
În caseta 2.4 sunt prezentate scenariile de lucru ale utilizatorilor pentru actualizarea şi
vizualizarea datelor privind comenzile primite de la clienţi.

21. Booth, P. – An Introduction to Human-Computer Interaction, Lawrence Erlbaum Associates, Londra, 1989, citat în
Mandel, T. – op. cit., p. 103.

Caseta nr. 2.4 – Scenariile de lucru pentru actualizarea şi vizualizarea comenzilor

Scenariul 1. Introducerea unei comenzi noi

Operaţiile de lucru sunt următoarele:

Alegerea clientului. Utilizatorul introduce codul clientului după care va verifica dacă
numele şi adresa acestuia corespund cu datele înscrise pe document. În cazul în care
utilizatorul nu ştie codul clientului, şi nici nu este trecut în document, atunci el va selecta
numele acestuia din lista clienţilor;

Adăugarea unui client nou (dacă clientul dorit nu există în baza de date);

Completarea datelor de individualizare a comenzii (numărul dat de client, numărul intern,

atribuit în mod automat de sistem, şi data înregistrării, preluată din sistem, dar care poate fi
modificată de utilizator);

Completarea modalităţii de plată şi a termenului de livrare;

Adăugarea articolelor comandate. Această operaţie va fi reluată pentru fiecare articol

comandat, şi presupune:

– Selectarea produsului. Utilizatorul introduce codul produsului după care va verifica dacă
denumirea acestuia corespunde cu cea înscrisă pe document. În cazul în care codul
produsului nu apare în document şi utilizatorul nu-l ştie sau acesta este incorect, atunci el
va selecta produsul respectiv dintr-o listă cu toate produsele;

– Verificarea unităţii de măsură, a stocului disponibil şi a preţului unitar;

– Completarea cantităţii comandate pentru articolul respectiv;

– Verificarea valorii calculate pentru articolul respectiv;

Verificarea totalului valoric al comenzii, prin compararea totalului rezultat în urma

adăugării datelor cu totalul înscris în comandă;

Salvarea comenzii;

Transmiterea unei notificări către client. În cazul primirii comenzii prin telefon, clientul
poate solicita confirmarea înregistrării comenzii sale prin transmiterea unui email cu toate
detaliile;

Tipărirea comenzii, dacă utilizatorul doreşte acest lucru (în special în cazul comenzilor
primite prin telefon.

Scenariul 2. Modificarea datelor de pe o comandă


Căutarea şi afişarea comenzii. Căutarea poate fi efectută în funcţie de numărul dat de client
sau numărul (codul) intern al comenzii, perioada în care a fost înregistrată, codul sau
numele clientului;

Verificarea stării comenzii. Comenzile deja onorate nu mai pot fi modificate;

Modificarea datelor de pe comandă. Se pot ivi următoarele situaţii: modificarea modalităţii

de plată, a perioadei de livrare, adăugarea sau ştergerea unui articol, modificarea
cantităţii comandate;

Salvarea sau abandonarea modificărilor. Utilizatorul va confirma acţiunea aleasă;

Transmiterea unei notificări către client privind modificările efectuate. În cazul în care
79

clientul solictă prin telefon efectuarea unor modificări asupra comenzii, acesta poate cere
confirmarea înregistrării modificărilor prin transmiterea unui mesaj email cu toate detaliile
comenzii;

Tipărirea comenzii, dacă utilizatorul doreşte acest lucru (mai ales în cazul comenzilor
primite anterior prin telefon).

Scenariul 3. Anularea unei comenzi


Căutarea comenzii (vezi prima sarcină de lucru de la scenariul 2);

Verificarea stării comenzii. Comenzile deja onorate nu mai pot fi anulate;

Anularea comenzii. Utilizatorul va confirma anularea comenzii;

Transmiterea unei notificări către client cu privire la anularea comenzii sale.

Scenariul 4. Vizualizarea comenzilor unui client


Introducerea datelor de identificare a clientului. Se poate introduce codul clientului sau se

alege numele acestuia dintr-o listă;

Verificarea corectitudinii identităţii clientului. Se va compara adresa clientului afişată cu

cea înscrisă pe comandă sau cea specificată de client prin telefon;

Căutarea unei comenzi a clientului selectat. Căutarea poate fi realizată după numărul
comenzii dat de client sau data de înregistrare;

Vizualizarea comenzii. Utilizatorul poate fi interesat de felul plăţii, data livrării, articolele
şi cantităţile comandate, valoarea totală a comenzii, starea acesteia etc;

Tipărirea comenzii, dacă utilizatorul doreşte acest lucru.

Definirea obiectelor şi acţiunilor interfeţei

Pe baza scenariilor definite anterior, se vor defini obiectele şi acţiunile necesare în

interfaţă, pentru a putea fi realizate sarcinile de serviciu respective, în conformitate cu
cerinţele şi obiectivele de calitate definite. În acest sens, se va citi cu atenţie descrierea
tuturor scenariilor şi operaţiilor de lucru şi se vor sublinia toate substantivele şi verbele,
urmând a fi trecute într-o listă specială. Fiecare substantiv este susceptibil de a reprezenta
un obiect, iar fiecare verb poate corespunde unei acţiuni. Obiectele sunt reprezentate, de
regulă, prin câmpuri de date, precum numărul şi data facturii, numele furnizorului,
denumirea marfii, iar acţiunile prin operaţiunile iniţiate în interfaţă, cum ar fi adăugare
factură, salvare date, căutare document, încărcarea datelor.
În caseta 2.4, substantivele (obiectele) au fost evidenţiate cu caractere îngroşate (bold),
iar verbele (acţiunile) cu caractere înclinate (italice).
Lista obţinută va fi revizuită pentru a se elimina obiectele şi acţiunile duplicate,
precum şi pentru a adăuga eventualele obiecte şi acţiuni care nu au rezultat în mod explicit
din descrieriea scenariilor de lucru. Lista finală pentru exemplul nostru este prezentată în
caseta 2.5.

Caseta nr. 2.5 – Lista obiectelor şi acţiunilor din ecranul
pentru actualizarea şi vizualizarea comenzilor

Obiectele ecranului Acţiunile ecranului
Client Adăugare client nou
Cod client Salvare comandă
Nume client (listă) Transmitere notificare
Adresă client Tipărire comandă
Comandă Căutare comandă
Numărul comenzii dat de client Modificare date
Cod intern al comenzii Adăugare articol
Data înregistrării comenzii Ştergere articol
Modalitatea de plată Abandonare
Termen de livrare Anulare comandă
Articol comandă
Cod produs
Denumire produs (listă)
Unitate de măsură
Stoc existent
Preţ unitar
Valoare articol
Total valoric comandă
Perioada de căutare/afişare comenzi

Stabilirea modului de reprezentare vizuală a obiectelor interfeţei

După identificarea şi definirea obiectelor interfeţei, se va trece la stabilirea modului de

reprezentare vizuală pentru fiecare obiect în parte. În acest sens, se va ţine cont de tipurile
de obiecte specifice interfeţelor grafice (căsuţe de text, butoane radio, casuţe combinate
etc.). Apoi, se va determina modul în care utilizatorii vor interacţiona cu obiectele interfeţei,
luându-se în considerare evenimentele asociate fiecărui obiect în parte. Dacă este necesar,
vor fi prevăzute meniuri de tip pop-up, asociate obiectelor, sau meniuri de tip bară, asociate
ecranelor. De exemplu, IBM recomandă utilizarea unui meniu de tip bară, atunci când un
ecran oferă mai mult de şase opţiuni de lucru.

5.1.3 Construirea interfeţei utilizator

Odată ce au fost formulate specificaţiile de proiectare, se trece la construirea

interfeţelor utilizator. Această fază este axată pe construirea prototipului interfeţei. Este
indicată construirea de prototipuri pentru mai multe variante de proiectare.
Construirea prototipurilor este o operaţiune foarte simplă, dacă se apelează la ajutorul
oferit de produsele CASE sau de mediile speciale de dezvoltare grafică. Se pot folosi
programe utilitare de proiectare a intrărilor şi ieşirilor (documente şi rapoarte), însă există
instrumente specializate, cunoscute sub numele de Prototypers (prototipizoare) sau Demo
Builders (constructori demo), care permit construirea rapidă a ecranelor şi vor demonstra
cum va fi folosită interfaţa în viitorul sistem. Prin ele se realizează şi evaluarea
comportamentului în utilizare. Avantajul principal al acestor medii constă în construirea
uşoară şi rapidă a prototipurilor şi a versiunilor demonstrative ale sistemului informatic,
chiar de către neprogramatori. Dezavantajele sunt legate de funcţionalitatea limitată şi
utilizarea platformelor proprietare pentru scrierea codului, ceea ce face dificilă încorporarea
sa în produsul final.
81

Ca alternativă, se poate utiliza mediul de dezvoltare în care va fi implementată
interfaţa, de exemplu Visual Basic sau Java. Proiectantul va avea la dispoziţie toate
facilităţile disponibile la implementarea sistemului, în plus, fiind posibilă reutilizarea
codului scris cu ocazia construirii prototipului. Dezavantajul acestei alternative este legat
de dificultatea utilizării acestor medii de către cei care nu le stăpânesc.
Modelul final al prototipului pentru ecranul (formularul) de culegere, actualizare şi
vizualizare a datelor privind comenzile primite de la clienţi este prezentat în caseta 2.6.

Caseta nr. 2.6 – Prototipul ecranului pentru actualizarea

şi vizualizarea datelor privind comenzile

În caseta 2.7 este prezentată fereastra de dialog cu care va interacţiona utilizatorul
pentru generarea şi tipărirea raportului „Situaţia vânzărilor pe gestiuni şi facturi”, ale cărui
specificaţii de proiectare au fost prezentate în capitolul anterior.

Caseta nr. 2.7 – Fereastra de dialog pentru obţinerea raportului
„Situaţia vânzărilor pe gestiuni şi facturi

Datorită simplităţii secvenţei de dialoguri, nu a mai fost necesară parcurgerea, fază cu
fază, a demersului de proiectare a interfeţelor utilizator. Oricum, construirea prototipului
pentru fereastra de dialog are la bază specificaţiile de proiectare ale raportului, cum ar fi
perioada de timp pentru care se generează raportul, modul de grupare şi ordonare, gestiunile
pentru care se vor lista datele etc. Scenariile de lucru sunt uşor de intuit şi de transpus în
prototip, fără a mai fi necesară definirea lor explicită.

5.1.4 Evaluarea şi validarea interfeţei utilizator

După construirea prototipului, se trece la evaluarea acestuia, pentru a se stabili dacă el

satisface cerinţele utilizatorilor. În fapt, activitatea de evaluare este cea care determină
caracterul iterativ al procesului de proiectare al interfeţelor utilizator, prezentat în figura
2.7.
Utilizatorii vor evalua prototipul şi vor formula propriile observaţii cu privire la
calitatea interfeţei. Pe baza constatărilor şi a noilor cerinţe formulate de aceştia, proiectantul
va modifica specificaţiile de proiectare şi va construi un nou prototip. Noul prototip va fi
supus din nou operaţiunii de evaluare, acest ciclu continuând până când utilizatorii vor
valida interfaţa respectivă.

Proiectarea
Proiectarea
ppreliminară
e mina ă

Construire
prototip nr. 1
Construire
prototip nr. N

Modificarea
Evaluarea
specifica iilor
specificaţiilor
interfeţei
interfe ei
de proiectare

Analiza
rezultatelor
Interfaţă proiectată
complet
Fig. 2.7 Locul evaluării în procesul de proiectare a interfeţei utilizator

83

Obiectivele activităţii de evaluare vizează aprecierea comportamentului, performanţelor
şi satisfacţiei utilizatorilor în lucrul cu interfeţele. Testarea şi evaluarea interfeţei de către
utilizatori trebuie realizate cât mai devreme şi cât mai des cu putinţă. Dacă această
activitate ar fi realizată la sfârşitul procesului de proiectare, în cazul identificării unor
probleme, s-ar putea să fie prea târziu pentru a se mai putea efectua modificări asupra
interfeţei, deoarece unele modificări ar putea afecta programele şi baza de date. Chiar
dacă aceste modificări pot fi efectuate, nimeni nu va putea garanta că interfaţa astfel
obţinută va corespunde cerinţelor utilizatorilor.
TA 5.1
1. Descrieţi succinct principiile proiectării orientate spre utilizator a interfeţei.
2. Enumeraţi paşii fazei de proiectare a interfeţei utilizator din cadrul demersului prezentat.
3. În ce faze ale demersului proiectării interfeţelor utilizator sunt implicaţi în mod direct
utilizatorii? Explicaţi rolul jucat de aceştia.
Răspuns:

5.2 Reguli de proiectare a meniurilor

Meniurile unei aplicaţii reflectă structura generală a sistemului informaţional, din
punctul de vedere al utilizatorului. Meniul conţine o ierarhie de opţiuni, grupate după
diferite criterii. Cel mai adesea, meniurile sunt structurate pe subsisteme (funcţii) sau
acţiuni efectuate asupra obiectelor. De exemplu, opţiunile principale din meniul unei
aplicaţi privind gestiunea relaţiilor cu clienţii pot fi: înregistrare tranzacţii, actualizare
clienţi şi generare rapoarte diverse. Meniurile pot fi aranjate şi pe baza obiectelor din
sistem: comenzi, livrări, încasări, clienţi, produse. În acest caz, unele funcţii vor fi
redundante, întrucât fiecare dintre opţiunile amintite va avea asociat un submeniu cu opţiuni
precum actualizare sau rapoarte.
La proiectarea meniurilor trebuie analizate cu atenţie diagramele fluxurilor de date, în
special diagramele de nivel 0 şi 1. Structurarea meniurilor poate reflecta, în bună măsură,
structura funcţională a sistemului, rezultată prin procesul de descompunere a diagramelor
fluxurilor de edate. De regulă, proiectarea meniurilor se realizează în paralel cu proiectarea
arhitecturii programelor. Se va lua în considerare caracteristica generală a sistemului, adică

dacă el este orientat pe tranzacţii sau pe transformări. În acest sens, diagrama de structură,
instrumentul utilizat pentru descrierea arhitecturii programelor, va reflecta în partea sa
superioară structura meniului. De aceea, asupra proiectării meniurilor vom reveni în cadrul
capitolului destinat proiectării programelor.
În legătură cu proiectarea meniurilor, s-au conturat câteva convenţii standard, dintre
care le enumerăm pe cele mai importante:
în cele mai multe aplicaţii se foloseşte poziţia File. În astfel de cazuri ea trebuie să
fie prima poziţie din linia meniului;
poziţia Edit este întotdeauna a doua, dacă există;
poziţia Window este întotdeauna penultima, dacă există;
poziţia Help este întotdeauna ultima din linie, dacă există;
o săgeată () plasată în dreapta ultimului element înseamnă descompunerea
acestuia în submeniuri (vezi şi figura 2.2 a);
elementele selectate sau activate vor fi marcate într-un anumit mod (de exemplu,
bifare în stânga numelui);
prezentarea elementelor care, dacă sunt selectate, vor conduce la apariţia meniurilor
pop-up, marcate, de obicei, cu (…);
afişarea pe prima linie a unui text-comentariu referitor la poziţia pe care se află
prompterul;
ştergerea sau evidenţierea poziţiilor ce pot fi activate faţă de celelalte care nu pot fi
folosite (de exemplu, folosirea culorilor accentuate pe butoanele care pot fi activate,
şi aproape şterse pe celelalte);
structura meniului trebuie să reflecte cât mai fidel succesiunea paşilor pe care
utilizatorul o foloseşte cel mai frecvent;
oferirea a două sisteme de meniuri, unul pentru utilizatorii neexperimentaţi, care va
conţine un set minim de acţiuni, organizate în cascadă, şi unul pentru utilizatorii
experimentaţi, care va conţine toate opţiunile de lucru;
gruparea opţiunilor astfel încât să se maximizeze similitudinea lor în cadrul
categoriei şi să se minimizeze similitudinea opţiunilor din categorii diferite;
oferirea accesului direct la opţiunile critice sau utilizate frecvent;
separarea opţiunilor care iniţiază acţiuni destructive de cele utilizate frecvent;
includerea în meniu a unor opţiuni de lucru care nu se regăsesc în cerinţele
funcţionale (transpuse în diagrama fluxurilor de date). Astfel de opţiuni pot privi
restaurarea sau arhivarea bazei de date, întreţinerea conturilor de utilizatori, facilităţi
de ajutor (help) etc.

5.3 Aspecte privind proiectarea interfeţelor web

Internetul şi Web-ul oferă noi oportunităţi de desfăşurare a afacerilor şi de concepere a
sistemelor informaţionale. Tehnologia Web este, astăzi, larg utilizată în asigurarea
comunicării în cadrul firmei, pentru oferirea serviciilor informaţionale clienţilor firmei etc.
Regulile şi principiile generale de proiectare a interfeţelor, discutate anterior, sunt
aplicabile şi în proiectarea interfeţelor Web. Însă, tehnologia Web presupune unele
particularităţi faţă de interfeţele clasice. De exemplu, interfeţele Web oferă avantajul
utilizării hyper-link-urilor, ce uşurează navigarea de la o pagină la alta. Prin urmare, la
85

proiectarea interfeţelor şi site-urilor Web trebuie respectate unele principii de lucru
specifice.
Jacob Nielsen a formulat 10 reguli care trebuie respectate la proiectarea interfeţelor
Web. Acestea sunt:
1. Includerea numelui şi a logo-ului firmei în fiecare pagină, iar logo-ul să fie o
legătură către pagina de început (home page).
2. Punerea la dispoziţie a funcţiei de căutare, dacă site-ul are mai mult de 100 de
pagini.
3. Scrierea unor antete şi titluri de pagină directe şi simple, care să explice clar despre
ce este vorba în pagina respectivă, şi să fie relevante atunci când sunt citite în lista
obţinută prin intermediul unui motor de căutare.
4. Structurarea paginii astfel încât să faciliteze explorarea ei rapidă. De exemplu, se
pot utiliza gruparea şi subantetele, pentru a împărţi o listă lungă în câteva unităţi
mai mici.
5. Utilizarea hypertext-ului pentru a structura spaţiul de afişare într-o pagină de
început, în care să fie prezentată o descriere succintă, şi mai multe pagini secundare,
fiecare orientată pe un anumit subiect (temă). Se evită astfel înghesuirea tuturor
informaţiilor într-o singură pagină uriaşă.
6. Evitarea construirii unor pagini cu multe fotografii, care să prezinte familii de
produse. Prima pagină de prezentare trebuie să fie încărcată şi deschisă în timp
scurt.
7. Utilizarea de imagini miniaturale relevante, în locul imaginilor sau a fotografiilor
prea mari, minimizându-se astfel timpul de descărcare a paginilor. Pentru obţinerea
imaginilor miniaturale se vor utiliza, în combinaţie, ambele metode de reducere a
unei imagini, respectiv redimensionarea şi decuparea. Utilizarea uneia dintre cele
două metode poate reduce drastic calitatea imaginii obţinute. Aducerea la o scară
redusă, prin redimensionare, duce la pierderea unor detalii şi a clarităţii imaginii
obţinute. Prin decupare se păstrează detaliile, însă se pierde contextul întregii
imagini, ceea ce poate face nerelevantă imaginea miniaturală obţinută.
8. Utilizarea de titluri sugestive pentru legături, care să ofere utilizatorilor o imagine
corectă asupra conţinutului paginii ce va fi deschisă, înainte ca acesta să o acceseze.
9. Toate paginile importante trebuie să ofere facilităţi speciale de accesare pentru
utilizatorii cu diferite infirmităţi, îndeosebi pentru cei cu vederea slăbită.
10. Conceperea interfeţei în aceeaşi manieră în care o fac ceilalţi. Dacă cele mai
multe site-uri Web fac un anumit lucru într-o anumită manieră, atunci utilizatorii
se vor aştepta ca şi celelalte site-uri să funcţioneze similar.

5.4 Controlul datelor în interfeţele utilizator

În domeniul sistemelor informaţionale este arhicunoscut principiul GIGO (Garbage In,
Garbage Out – Gunoi Intră, Gunoi Iese), care evidenţiază importanţa corectitudinii,
consistenţei şi completitudinii datelor de intrare în obţinerea de informaţii relevante şi de
înaltă calitate. Respectarea acestui principiu constituie o miză extrem de importantă în
proiectarea interfeţelor utilizator, motiv pentru care este necesară definirea unor mecanisme
de control, care să realizeze verificarea datelor de intrare, înainte de salvarea lor în bază.
Erorile la introducerea datelor apar, de cele mai multe ori, ca urmare a adăugării de
caractere în plus sau a trunchierii datelor de intrare, a schimbării succesiunii a două sau mai

multor caractere. Deşi eliminarea completă a datelor eronate nu este posibilă, există totuşi o
serie de mecanisme de control care pot reduce considerabil apariţia erorilor. Aceste
mecanisme de control vor ajuta utilizatorii în identificarea anumitor tipuri de erori la
culegerea datelor. În tabelul 2.8 sunt enumerate şi descrise, succint, câteva mecanisme de
control al datelor de intrare, ce pot fi implementate la nivelul interfeţei utilizator.

Tabel nr. 2.8 – Mecanisme de control al datelor introduse în ecrane
Mecanisme de Explicaţii
control

Se verifică dacă datele dacă sunt de un anumit tip (numerice, alfanumerice,
Tipul datelor
date calendaristice etc.)
Verosimilitatea datelor depinde de la caz la caz. De exemplu, cantitatea

vândută nu poate fi prea mare dacă preţul de vânzare este foarte mare. Nivelul
Verosimilitate
salariului sau al unei retrageri din cont bancar nu pot depăşi anumite limite.

Atunci când este posibil, aplicaţia va permite utilizatorului să aleagă o valoare
Selectarea unei
dintr-o listă, prin utilizarea căsuţelor combinate sau a celor de tip listă. De
valori, în locul
exemplu, pentru introducerea tipului de document se va prevedea în formular
introducerii ei
o căsuţă combinată sau butoane de opţiune.

Câmpurile din formulare, care sunt obligatoriu de completat, trebuie
Depistarea datelor
semnalate utilizatorilor, iar în momentul salvării datelor se va verifica dacă
lipsă
au fost completate toate câmpurile.

Această tehnică este utilizată pentru verificarea corectitudinii codurilor
Tehnica cifrei de
utilizate în aplicaţie, cum ar fi codul mărfii, al furnizorului etc. Un exemplu
control
este prezentat mai jos.
Pentru unele date pot fi definite şabloane, urmând a se verifica dacă datele

introduse corespund acestora. Astfel de şabloane pot fi definite pentru datele
Formatul datelor
calendaristice, numere de telefon, numere de înmatriculare a autoturismelor
etc.
Se verifică dacă datele introduse de utilizator se încadrează în intervalele de
Intervale de valori valori admise. De exemplu, notele obţinute la examen să fie în intervalul 0 –
10, stocul să fie mai mare decât 0 etc.

Numărul de caractere care trebuie introduse într-un câmp trebuie verificat
Numărul de
atunci când este cunoscut. De exemplu, CNP-ul unei persoane este format din
caractere
13 cifre.
Validitatea datelor introduse în formulare poate fi determinată prin
Compararea compararea lor cu datele stocate deja în baza de date. De exemplu, la
datelor introduse introducerea codului sau a numelui clientului se va verifica dacă el există în
cu cele stocate baza de date. Acest mecanism permite utilizatorilor să verifice corectitudinea
datelor introduse, înainte de salvarea lor.

Dintre mecanismele de control enumerate în tabelul 2.8, tehnica cifrei de control este
ceva mai complex. Conform acesteia, codurile numerice utilizate pentru reprezentarea
diferitelor entităţi vor avea ultima cifră determinată pe baza unui algoritm. Acelaşi algoritm
va fi utilizat şi la introducerea codurilor respective în formulare, pentru a stabili validitatea
lor. Această tehnică este utilizată la stabilirea codului numeric personal (CNP) al unei
persoane.
În caseta 2.8 sunt prezentate un exemplu de cod cu cifră de control şi algoritmul de
determinare a ei. Mai întâi, fiecărei cifre din cod i se atribuie câte un număr prim, în ordine
crescătoare, începând de la stânga spre dreapta. În cazul unui cod format din cinci cifre,
numerele prime utilizate vor fi 1, 2, 3, 5 şi 7. Primei cifre din stânga i se va atribui numărul
87

1, celei de-a doua numărul prim 2 ş.a.m.d. Apoi, se va calcula suma ponderată a cifrelor
din cod cu numerele prime atribuite. Cifra de control se va determina prin aplicarea
operaţiei „modulo 9” din suma ponderată rezultată. În final, se adaugă cifra de control la
codul iniţial şi se va obţine codul final.

Caseta nr. 2.8 – Exemplu de algoritm pentru calculul cifrei de control

codulnumer
Să considerăm codu numeric 12012.
c 12012.
Numerele cu ca
caree va fi ponderată ieca e cicifră
fiecare ă dindin
cod sun
cod : 12012
sunt: 12012
12357
12357
Suma ponderată va fi 1x1+2x2+0x3+1x5+2x7=24
împărţirii
Restul împăr irii sumei la 9 (modulo 9 din sumă): 24 : 9 = 2, iar restul este 6.
Cifra de control este 6, iar codul rezultat va fi 120126.

În tabelul 2.8 sunt prezentate doar mecanismele de control care realizează verificarea
automată a datelor introduse prin intermediul ecranelor. În afara acestora, pot fi prevăzute
mecanisme care să permită utilizatorilor să verifice ei înşişi corectitudinea datelor, în
momentul introducerii lor. Un astfel de mecanism îl reprezintă afişarea informaţiilor de
identificare a entităţilor în legătură cu care se introduc date, mai ales atunci când se
folosesc coduri. De exemplu, după introducerea codului pentru furnizorul care a emis
factura, se vor afişa, în câmpuri alăturate, datele sale de identificare, preluate automat din
baza de date, respectiv numele, adresa etc. Utilizatorul va avea posibilitatea să compare
aceste informaţii cu cele înscrise în factură şi să depisteze eventualele neconcordanţe.
Aceeaşi procedură poate fi utilizată şi pentru introducerea datelor privind mărfurile din
factură.
O altă procedură constă în afişarea unor totaluri sau a altor câmpuri calculate. De
exemplu, în formularul pentru introducerea facturilor primite de la furnizori se va afişa
valoarea TVA şi totalul facturii. Dacă aceste valori diferă de cele înscrise în factură, atunci
este foarte probabil ca utilizatorul să fi introdus greşit cantitatea sau preţul pentru una sau
mai multe mărfuri.

TA 5.2
1. Enumeraţi 6 reguli de proiectare a meniurilor.
2. Enumeraţi 5 reguli de proiectare a interfeţelor Web.
3. Explicaţi, printr-un exemplu, în ce constă aplicarea tehnicii cifrei de control?
Răspuns:

5.5 Formularea specificaţiilor de proiectare a interfeţelor

Specificaţiile de proiectare a interfeţelor şi dialogurilor se pot concretiza într-o formă
similară celei prezentate în continuare.
1. Prezentare generală descriptivă
1.1. Numele interfeţei/dialogului
1.2. Caracteristicile utilizatorului
1.3. Caracteristicile activităţii
1.4. Caracteristicile sistemului
1.5. Caracteristicile mediului de lucru
2. Proiectele interfeţelor/dialogurilor
2.1. Proiectele formularelor/formatelor/rapoartelor
2.2. Diagramele secvenţelor de derulare a dialogurilor şi prezentarea descriptivă a
acestora
3. Testarea şi evaluarea interfeţelor/dialogurilor în utilizare
3.1. Obiectivele testării
3.2. Procedurile testării
3.3. Rezultatele testării
3.3.1. Timpul de învăţare
3.3.2. Viteza de execuţie
3.3.3. Rata erorilor
3.3.4. Rezistenţa în timp
3.3.5. Satisfacţia şi alte percepţii ale utilizatorului


TA 5.1 1) Vezi p. 71-72. 2) Definirea obiectivelor de calitate a interfeţelor, formularea
scenariilor pentru fiecare sarcină de serviciu, definirea obiectelor şi acţiunilor interfeţei
utilizator, stabilirea modului de reprezentare vizuală a obiectelor interfeţei. 3) Culegerea şi
analiza informaţiilor - analiza atribuţiilor de serviciu, identificarea cerinţelor de lucru;
Proiectarea interfeţelor – definirea scenariilor de lucru; Evaluarea şi validarea interfeţelor
utilizator – evaluarea prototipurilor.
TA 5.2 1) Vezi subunitatea 5.2 2) Vezi subunitatea 5.3. 3) vezi caseta 2.8.
89



1) Care dintre urmatoarele mecanisme pentru controlul datelor in interfetele utilizator trebuie
aplicat in vederea evitarii introducerii eronate a valorii Novatim in loc de Navotim pentru numele
clientului?
a) verosimilitate
b) selectarea unei valori in locul introducerii ei
c) tipul datelor
d) tehnica cifrei de control

2) La proiectarea meniurilor trebuie aplicate urmatoarele conventii:
a) oferirea accesului direct la toate optiunile din meniu
b) includerea in meniu doar a optiunilor de lucru care se regasesc in cerintele functionale
c) pozitia Help este intotdeauna prima din linia meniului
d) separarea optiunilor care initiaza actiuni distructive de cele apelate in mod curent


1. Descrieţi, pe scurt, etapele şi activităţile procesului de proiectare a interfeţelor utilizator.
2. Enumeraţi elementele specificaţiei de proiectare a interfeţelor utilizator.
3. Alegeţi mecanismul cel mai potrivit pentru controlul datelor în vederea depistării
următoarelor erori de introducere a datelor:
introducerea într-o căsuţă de text a valoarii 220459 în loc de 220549;
specificarea datei 30 februarie;
specificarea a 320 ore lucrate pentru un angajat, la preluarea datelor din centralizatorul
lunar al pontajelor;
introducerea valorii Iasirad în loc de Iasiard, pentru numele clientului;
nespecificarea cantităţii pentru un produs, la preluarea datelor de pe o factură;
introducerea greşită cantităţii, pentru o marfă achiziţionată prin factură;
introducerea valorii IS-289-GDF, pentru numărul de înmatriculare al unui camion;
introducerea sumei de 2500 lei pentru plata unei facturi, deşi valoarea facturii este de
numai 2000 lei.

5.8 Bibliografie

1. Mandel, T. – The Elements of User Interface Design, John Wiley & Sons, New York, 1997,
p. 245-290
Jersey, 2001, pp. 354-362


Concepte de bază privind modelarea logică a datelor

Obiective:
Definirea locului modelării logice a datelor în ciclul de viaţă al sistemelor
Descrierea aspectelor calitative ale modelului logic al datelor
Prezentarea sintetică a conceptelor specifice modelului relaţional
Descrierea demersului de proiectare logică a bazei de date
Evaluarea aspectelor calitative ale unei scheme logice a bazei de date
Modelarea logică a datelor prin înţelegerea corectă a necesităţii şi conţinutului aplicării
principiului abstractizării
Elaborarea unui demers de proiectare a bazei de date adaptat la caracteristicile sistemului

6.1 Locul modelării logice a datelor în ciclul de viaţă al sistemelor ........................................... 91
6.2 Concepte de bază utilizate în modelul relaţional ................................................................... 92
6.3 Demersul proiectării logice a bazelor de date ........................................................................ 96
6.6 Bibliografie ............................................................................................................................ 98

În timpul analizei sistemelor, s-a discutat despre dezvoltarea sistemului informaţional
din trei puncte de vedere:
determinarea cerinţelor sistemului;
structurarea cerinţelor;
generarea şi selecţia variantelor noului sistem.
Componenta referitoare la structurarea cerinţelor a fost tratată astfel:
modelarea logică a proceselor de prelucrare;
modelarea logicii proceselor;
modelarea conceptuală a datelor (diagrama entitate-relaţie).
Unitatea de studiu de faţă, împreună cu următoarea, se află în strânsă legătură cu
modelarea conceptuală a datelor. Pentru o şi mai bună clarificare, revenim la aplicarea
principiului abstractizării, discutat şi în cadrul etapei de analiză, conform căruia datele sunt
modelate pe trei niveluri: conceptual, logic şi fizic. Acum ne concentrăm asupra celui de-al
doilea nivel de abstractizare, respectiv modelarea logică a datelor. În timpul modelării
conceptuale s-a urmărit reprezentarea modului de organizare a datelor, independent de
tehnologiile specifice de stocare şi prelucrare a bazelor de date, fără să se înregistreze o
preocupare anume referitoare la calitatea modelelor. Ultimului aspect i se va acorda atenţia
cuvenită abia acum, odată cu modelarea logică a datelor, descriindu-se structurile datelor
din bază.
91

6.1 Locul modelării logice a datelor
în ciclul de viaţă al sistemelor

Modelarea logică a datelor descrie datele cu ajutorul unei notaţii speciale, care
corespunde unui mod de organizare a acestora de către un sistem de gestiune a bazelor de
date relaţionale, numit şi model relaţional.
Diferenţa majoră dintre modelarea conceptuală şi cea logică a datelor este aceea că,
după modelarea logică a datelor, cerinţele structurate de date se concretizează în relaţii
(tabele), şi nu în entităţi. Din cauza unor criterii de calitate şi reguli de organizare diferite,
cum ar fi normalizarea, nu este necesară o corespondenţă biunivocă între mulţimea
entităţilor şi cea a relaţiilor.
Principalele criterii de calitate utilizate în evaluarea modelului logic al datelor sunt22:
Completitudine. Modelul logic trebuie să conţină toate datele necesare prelucrărilor
în vederea obţinerii ieşirilor din sistem.
Neredundanţă. Redundanţa datelor generează probleme privind integritatea lor (vezi
anomaliile la actualizare descrise în acest capitol) şi solicită procese suplimentare
pentru întreţinerea datelor. De aceea, modelul logic trebuie să fie format dintr-un set
de tabele normalizate.
Reutilizare. Schema logică a bazei de date trebuie concepută astfel încât ea să
satisfacă nu doar cerinţele anticipate ale sistemului, ci şi pe cele ale altor potenţiali
utilizatori sau eventualele cerinţe viitoare care apar inevitabil. Dacă datele sunt
organizate având în minte doar cerinţele actuale, atunci reorganizarea datelor,
determinată de apariţia unor noi cerinţe funcţionale, poate fi foarte costisitoare.
Stabilitate şi flexibilitate. Aceste criterii vizează uşurinţa adaptării bazei de date la
modificările ulterioare ale cerinţelor sistemului. Un model al datelor este considerat
stabil dacă eventualele modificări ale cerinţelor funcţionale nu determină schimbarea
structurii sale. Schema bazei de date va fi considerată mai stabilă sau mai puţin
stabilă în funcţie de amploarea modificărilor generate de schimbarea cerinţelor.
Flexibilitatea unui model al datelor este dată de uşurinţa extinderii sale pentru
înglobarea noilor cerinţe cu impact minim asupra structurii existente.
Simplitate şi eleganţă. Modelul logic al datelor trebuie să ofere o clasificare naturală
şi elegantă a datelor. De exemplu, este inadecvată existenţa tabelelor FURNIZOR şi
CLIENT, atât timp cât unii parteneri de afaceri pot fi atât furnizori, cât şi clienţi.
Aceeaşi situaţie poate apărea în cazul facturilor, fiind neelegantă conceperea a două
tabele, una pentru facturi emise şi alta pentru facturi primite, atât
timp cât ele au structuri similare.
Tot acum facem menţiunea că relaţiile (tabelele) nu corespund fişierelor fizice realizate
cu calculatorul, operaţiune efectuată în timpul proiectării fizice, descrisă într-un capitol
următor. După cum vom vedea, obiectivele şi criteriile de calitate sunt diferite de cele
vizate la proiectarea logică a datelor.
Procesul de modelare logică a datelor se derulează în paralel cu celelalte activităţi ale
proiectării logice: proiectarea formularelor şi a rapoartelor, proiectarea dialogurilor şi
interfeţelor. Modelarea logică a datelor se realizează nu numai pe baza diagramei entitate-

22. Simsion, G.C. – Data Modeling Essentials. Analysis, Design, and Innovation, Second Edition, The Coriolis Group,
2001, Scottsdale, Arizona, pp. 11-15.

relaţie, ci şi pe baza machetelor formularelor şi a rapoartelor. Se efectuează analiza datelor
elementare din intrările şi ieşirile sistemului, pentru a se desprinde legăturile dintre ele.
Procesul de modelare a datelor este complex. În fiecare etapă a ciclului de viaţă al
sistemelor se regăseşte câte o activitate specifică datelor, conform tabelului 3.1.
Întrucât modelul relaţional reprezintă subiectul central al discuţiei noastre despre
modelarea logică a datelor, în paragraful următor, vom descrie conceptele sale de bază.

Tabel nr. 3.1 – Relaţia dintre etapele ciclului de viaţă al sistemelor şi modelarea datelor
Etapa din ciclul de Elemente de modelare a datelor
viaţă al sistemului
Identificarea şi Modelul general al datelor la nivel de întreprindere (DER doar cu
selecţia proiectelor entităţi).
Iniţierea şi Modelul conceptual al datelor. Prezentarea DER cu entităţile specifice
planificarea unor proiecte.
proiectului
Analiza Modelele conceptuale ale datelor. Se prezintă DER în care se includ şi
atributele.
Proiectarea logică Modelul logic al datelor (relaţional).
Proiectarea fizică Proiectarea fişierelor şi bazelor de date fizice (organizarea fişierelor).
Implementarea Descrierea fişierelor şi bazelor de date (codificarea unor SGBD).
Întreţinerea Evoluţia modelului datelor.

6.2 Concepte de bază utilizate în modelul relaţional

O bază de date relaţională poate fi definită ca un ansamblu de relaţii (tabele) aflate în
legătură. Fiecare tabel este identificat printr-un nume propriu, având linii şi coloane, la
intersecţia cărora se introduc valori atomice. În figura 3.1 este prezentat un exemplu
simplificat de bază de date pentru evidenţa vânzărilor.
În modelul relaţional, datele sunt stocate sub forma tabelelor, numite şi relaţii (de aici
provine şi numele de model relaţional). Conceptul de relaţie permite reprezentarea unei
entităţi din universul modelat sau a unei legături semantice dintre două entităţi. În exemplul
nostru se regăsesc patru relaţii: PRODUS, ARTICOLFACTURA, FACTURA şi CLIENT.
În tabelul 3.2 sunt prezentate principalele noţiuni utilizate în descrierea modelului
relaţional, precum şi termenii corespondenţi din teoria mulţimilor şi din domeniul
prelucrării datelor.

Tabel nr. 3.2 – Terminologia diferitelor domenii de lucru
Teoria Baze de date relaţionale Convenţii din prelucrarea datelor
mulţimilor
Relaţie Tabel Fişier
Domeniu Toate valorile posibile pe care le Toate valorile posibile pe care le poate
poate avea o coloană avea un câmp
Tuplu Linie Înregistrare
Termenul relaţie provine din studiile efectuate asupra datelor de E.F. Codd şi alţii, în
timp ce lucrau pentru IBM, în tentativa lor de a găsi unele criterii, cât de cât ştiinţifice, de
descriere a datelor şi care să conducă la o proiectare flexibilă, cu structuri uşor de modificat.
Concentrându-se asupra datelor, Codd a găsit de cuviinţă că ar fi utilă aplicarea în acest
domeniu a matematicilor mulţimilor de elemente. O mulţime matematică este
93
concepută ca un grup de obiecte, cu o regulă de asociere între elemente bine definite, sau
prin folosirea unei liste de consultat, pentru a se vedea dacă un element îi aparţine sau nu.
Se poate spune, astfel, că mulţimea numerelor pare este o submulţime a mulţimii numerelor
naturale, cu condiţia ca fiecare număr să se împartă exact la 2.
PRODUS
CodProdus DenProdus UM Stoc PretVanzare
100001 Canapea Mircea buc 7,00 250,00
100018 Comoda Mia buc 12,00 140,00
100026 Pal furniruit mp 112,00 12,50
100034 Biblioteca Livia buc 4,00 980,00

ARTICOLFACTURA
ARTICOLFACTURA
NrFactura CodProdus Cantitate
81001 100026 40,00
81002 100001 4,00
81002 100018 8,00
81003 100018 1,00
81004 100026 28,00
81004 100018 45,00
81005 100034 1,00

FACTURA
NrFactura DataFactura CodClient
81001 25.mai.04 1001
81002 25.mai.04 1001
81003 26.mai.04 1002
81004 26.mai.04 1002
81005 27.mai.04 1003

CLIENT
CodClient NumeClient Adres
Adresaa Sold
1001 Mota SRL Florilor, 21, Ias i 0
1002 Mobins SA Copou, 11, Vas lui 15000000
1003 Lux SRL Viilor, 45, Hus i 29000000

Fig. 3.1 Exemplu de bază de date relaţională

Fiecare linie dintr-o tabelă (relaţie), numită tuplu, conţine date despre un caz sau o
instanţă a entităţii reprezentate prin tabela respectivă. De exemplu, fiecare linie din tabela
PRODUS conţine datele necesare despre un anumit produs. Fiecare coloană (atribut)
conţine informaţii despre o anumită caracteristică a entităţii reprezentate, ele fiind cunoscute
şi sub numele de valori ale caracteristicii. Astfel, fiecare instanţă a entităţii PRODUS este
descrisă prin următoarele caracteristici: cod, denumire, unitate de măsură, stoc şi preţul de
vânzare.
La intersecţia fiecărei linii şi coloane se va introduce o valoare atomică, adică o
valoare care nu mai poate fi descompusă. De exemplu, la intersecţia coloanei NrFactura cu
prima linie din tabela FACTURA se regăseşte o singură valoare, 81001, care nu mai poate
fi descompusă. Acesta este şi motivul pentru care a fost creată tabela ARTICOLFACTURA.
Dacă nu ar fi existat această tabelă, iar câmpul Cantitate ar fi fost inclus în tabela
FACTURA, atunci linia corespunzătoare unei facturi ar fi conţinut mai multe valori pentru
această coloană, câte una pentru fiecare produs vândut prin intermediul acelei facturi. De
exemplu, linia corespunzătoare facturii 81004 ar fi conţinut două valori în coloana
Cantitate, 28.00 şi 45.00, pentru cele două produse de pe factură.

Totuşi, în exemplul nostru se poate considera că unele coloane nu conţin valori
atomice. Coloana Adresa din tabela CLIENT ar putea fi descompusă cel puţin în oraş,
strada şi număr. Este adevărat însă, după cum vom vedea ulterior, atomicitatea valorilor
stocate într-o tabelă este o noţiune relativă.
Mulţimea tuturor valorilor pe care le poate lua o dată elementară se numeşte domeniu,
definit, de cele mai multe ori, prin limite superioare şi inferioare
Ansamblul minimal de atribute prin care se poate identifica în mod unic orice tuplu
dintr-o relaţie reprezintă cheia relaţiei. Orice relaţie posedă cel puţin o cheie. Când cheia
este constituită dintr-un singur atribut, poartă numele de cheie simplă, iar atunci când este
formată din mai multe atribute ea se numeşte cheie compusă. Tabelele PRODUS,
FACTURA şi CLIENT au cheie simplă, respectiv CodProdus, NrFactura şi CodClient, în
timp ce tabela ARTICOLFACTURA are o cheie compusă, formată din coloanele NrFactura
şi CodProdus (în figura 3.1, datele din coloanele respective sunt cu caractere îngroşate).
O relaţie poate avea două sau mai multe atribute sau combinaţii de atribute care să joace
rolul de cheie. În acest caz ele se vor numi chei candidat, urmând ca proiectantul să aleagă
una dintre ele drept cheie primară, iar celelalte se vor numi chei secundare. În relaţia
CLIENT, atributul NumeClient reprezintă o cheie secundară deoarece valorile sale pot
identifica în mod unic fiecare linie.
La alegerea unei chei primare analistul trebuie să aibă în vedere trei restricţii:
unicitatea – o cheie identifică un singur tuplu (linie) a relaţiei;
compoziţia minimală – atunci când cheia primară este compusă, nici un atribut din
cheie nu poate fi eliminat fără distrugerea unicităţii tuplului în cadrul relaţiei;
valori ne-nule – valorile atributului sau ale ansamblului de atribute ce desemnează
cheia primară sunt întotdeauna specificate, deci ne-nule; nici un atribut din
compoziţia cheii primare nu poate avea valori nule.
În mulţimile matematice nu este permis ca un obiect să apară de mai multe ori. Cât
timp o relaţie este o mulţime de tupluri, teoretic nici o linie a unei relaţii nu poate fi
duplicatul altei linii (SQL admite existenţa unor linii duplicat într-un tabel, considerându-se
că există modalităţi de eliminare a lor, dacă se doreşte). Dacă o coloană sau o combinaţie
de coloane nu poate să identifice în mod unic o linie, atunci trebuie inventată o coloană-
cheie specială. Oricum, fiecare relaţie trebuie să dispună de o cheie primară.
Legătura între tupluri din relaţii diferite se realizează prin intermediul unei coloane
comune, utilizându-se noţiunea de cheie străină, întâlnită uneori în literatură şi sub numele
de cheie externă. O cheie străină este un atribut care apare într-o tabelă şi care este cheie
primară în altă tabelă. În exemplul nostru, legătura dintre tabelele CLIENT şi FACTURA
este realizată prin intermediul atributului comun CodClient. Acest atribut joacă rolul de
cheie primară în tabela-părinte CLIENT şi rolul de cheie străină în tabela-copil
FACTURA23. În figura 3.1, cheile primare sunt evidenţiate prin caractere îngroşate (bold),
iar cheile străine prin caractere înclinate (italic).
În legătură cu cheia străină, apare conceptul de restricţie de integritate referenţială.
Această restricţie presupune că, pentru o cheie străină se admite orice valoare nenulă care
se regăseşte între valorile cheii primare din tabela-părinte. În tabela FACTURA toate
valorile coloanei CodClient, care este cheie străină, au corespondenţă în valorile aceleiaşi
coloane din tabela CLIENT, unde ea este definită cheie primară.

23. În teoria grafurilor, structurile arborescente sunt redate prin relaţii descendente, în care apar conceptele de bunic,
părinte, copil (fiu).
95
concepută ca un grup de obiecte, cu o regulă de asociere între elemente bine definite, sau
bazei de date, motiv pentru care trebuie definite aspectele de comportament al datelor în
cazul celor trei operaţiuni de actualizare: adăugarea, modificarea şi ştergerea de linii.
În cazul operaţiunii de adăugare, nu este permisă introducerea unei noi linii în tabela-
copil care să nu aibă corespondent în tabela-părinte. De exemplu, nu este corectă adăugarea
unei facturi în tabela FACTURA pentru clientul cu codul 2222 (adică o linie pentru care
valoarea atributului CodClient să fie 2222), atât timp cât acest client nu există în tabela
CLIENT.
Celelalte două operaţiuni privesc comportamentul datelor din tabela-părinte. Astfel, nu
se admite modificarea valorii cheii primare pentru o linie din tabela-părinte dacă aceasta
are asociată cel puţin o linie în tabela-copil. De exemplu, nu se admite modificarea valorii
cheii primare pentru linia corespunzătoare clientului „Lux SRL” (valoarea 1003 pentru
coloana CodClient) în tabela CLIENT deoarece în tabela FACTURA ultima linie face
referire la această valoare. În mod asemănător, nu este permisă ştergerea unei linii din
tabela-părinte dacă există cel puţin o linie în tabela-copil care face referire la ea. Cu atât
mai mult, linia corespunzătoare clientului „Lux SRL” din tabela CLIENT nu poate fi
eliminată. Dacă nu ar fi existat ultima linie din tabela FACTURA, atunci operaţia de
ştergere ar fi putut avea loc.
Asigurarea consistenţei datelor impune conceperea unei baze de date bine structurate,
care să garanteze respectarea restricţiilor privind cheia şi a restricţiei referenţiale. În
paragraful următor vom pune în evidenţă, printr-un exemplu, avantajele unei baze de date
structurate.

TA 6.1
1. Explicaţi deosebirea dintre modelul conceptual şi modelul logic al datelor.
2. Enumeraţi criteriile de calitate ale modelului logic al datelor.
3. Explicaţi următoarele noţiuni din modelul relaţional: relaţie, cheie primară, cheie străină,
restricţie de integritate referenţială.
Răspuns:

6.3 Demersul proiectării logice a bazelor de date

Proiectarea schemei logice a bazei de date poate fi realizată în mai multe moduri.
Abordarea tradiţională, aplicată, în special, în cazul bazelor de date relaţionale, presupune
constituirea relaţiei generale prin reunirea tuturor datelor elementare (atribute), identificate
în faza de analiză, şi repartizarea lor în tabele, pe baza analizei dependenţelor dintre
atribute (dependenţe funcţionale, dependenţe multivaloare şi de joncţiune) şi aplicarea
procesului de normalizare. Această abordare a înregistrat unele succese în proiectarea
bazelor de date de dimensiuni mici şi medii, însă ea devine foarte greoaie în cazul bazelor
de date de dimensiuni mari şi foarte mari.
Introducerea modelului entitate-relaţie a determinat reorientarea specialiştilor către o
nouă abordare în proiectarea bazelor de date. Aceasta presupune, mai întâi, modelarea
conceptuală a datelor, prin construirea diagramei entitate-relaţie, care evidenţiază entitaţile
de date ale sistemului, atributele acestora şi legăturile dintre entităţi. Ulterior, prin aplicarea
unor reguli simple, are loc transformarea DER în schema logică a bazei de date. Tabelele
astfel rezultate sunt, în final, analizate din perspectiva normalizării, cu posibilitatea obţinerii
unor tabele noi.
Corespunzător celor două abordări, există două strategii de proiectare a schemei logice
a bazei de date:
strategia bottom-up reprezintă abordarea tradiţională şi presupune constituirea
relaţiei generale care urmează a fi supusă normalizării pentru a se obţine tabelele
bazei de date;
strategia top-down presupune construirea DER şi apoi transformarea ei într-un set
de tabele, prin aplicarea unor reguli. Tabelele rezultate vor fi analizate din
perspectiva normalizării.
Utilizarea strategiei top-down oferă o serie de avantaje, faţă de abordarea tradiţională24:
diagrama entitate-relaţie reprezintă un instrument util de comunicare între analişti
şi utilizatori pe parcursul fazelor de analiză şi proiectare logică;
modelul entitate-relaţie este uşor de înţeles şi conceput. În general, prezentarea
grafică permite exprimarea unui volum mare de informaţii sub o formă compactă,
uşor de urmărit şi înţeles;
utilizează conceptul de abstractizare, ceea ce reduce considerabil numărul obiectelor
luate în considerare la analiza şi proiectarea bazei de date. Prin utilizarea noţiunii de
entitate (sau clasă de entităţi), ca abstractizare pentru datele elementare (atribute), se
vor analiza mai puţine obiecte (numărul entitaţilor de date este mult mai mic
decât numărul datelor elementare din sistem) şi mai puţine relaţii între obiecte
(numărul relaţiilor dintre entităţi este mult mai mic decât numărul relaţiilor de
dependenţă existente între atribute). Deşi datele elementare sunt reprezentate şi în
modelul entitate-relaţie, ca proprietăţi ale entităţilor, totuşi numărul
dependenţelor ce trebuie analizate este mult redus, fiind luate în considerare doar
dependenţele dintre atributele unei entităţi şi nu dependenţele dintre toate atributele
bazei de date.
Existenţa unui set complet de reguli de transformare a DER în tabele ale bazei de
date. Aceste reguli permit transformarea simplă şi rapidă a cerinţelor informaţionale
ale sistemului, structurate în DER, în baza de date. În acest sens, majoritatea

24. Adaptare după Teorey, T.J. – Database Modeling & Design, Morgan Kaufmann Publishers, Inc, 1999, San Francisco,
p. 46.
97

instrumentelor CASE oferă suport pentru generarea automată a bazei de date, în
funcţie de SGBD-ul dorit.
Pornind de la cele două strategii, pot fi identificate demersuri diferite de proiectare a
bazei de date, mai mult sau mai puţin riguroase. Două dintre ele corespund celor două
strategii, ele fiind descrise pe scurt anterior. Un demers mai riguros presupune combinarea
celor două strategii: se aplică ambele strategii, pentru obţinerea a două modele logice ale
datelor, iar, din compararea lor, va rezulta schema logică finală a bazei de date. În acest fel
se combină avantajele strategiei top-down, enumerate anterior, cu abordarea mai analitică,
specifică strategiei bottom-up. Chiar dacă este mai îndelungat şi mai costisitor, un astfel de
demers oferă garanţii suplimentare privind calitatea schemei logice a bazei de date, mai
ales în ce priveşte completitudinea.
Un asemenea demers presupune parcurgerea următorilor patru paşi:
1. Construirea câte unui model logic al datelor din perspectiva utilizatorului
(formulare şi rapoarte) privind aplicaţia, respectându-se principiile normalizării.
2. Integrarea tuturor perspectivelor normalizate ale utilizatorilor, obţinute prin
parcurgerea pasului anterior, într-un model logic consolidat al datelor.
3. Transformarea modelului conceptual al datelor (entitate-relaţie), realizat fără să se
ţină cont de perspectiva utilizatorului, într-un set de relaţii normalizate.
4. Compararea modelului logic consolidat al datelor, rezultat prin integrarea
perspectivelor utilizatorilor (pasul 2), cu cel obţinut prin transformarea DER (pasul
3), în vederea definirii modelului logic final al datelor.
În practică, poate fi angajat un alt demers, mai simplu (uneori simplist!), de proiectare
a bazei de date, constând în transpunerea directă a cerinţelor sistemului în modelul logic al
datelor, fără parcurgerea unor paşi intermediari. Cu alte cuvinte, analistul va exprima
cerinţele funcţionale nestructurate ale sistemului direct în termenii tabelelor, coloanelor şi
restricţiilor. Un asemenea demers poate fi aplicat în cazul bazelor de date de dimensiuni
foarte mici sau dacă analistul are o mare experienţă în domeniul problemei. Oricum,
alegerea unui demers sau a altuia depinde de complexitatea bazei de date, de experienţa
echipei de proiectare, de timpul şi resursele financiare disponibile sau de cerinţele de
calitate dorite.
În continuare, vom dezbate, pe rând, cele două strategii de proiectare, după care vom
prezenta căteva consideraţii legate de conţinutul celui de-al patrulea pas al demersului
propus, respectiv contopirea rezultatelor obţinute în paşii 2 şi 3.


TA 6.1 1) În modelul conceptual datele sunt reprezentate ca entităţi abstracte, iar în modelul
logic cerinţele structurate de date se concretizează în relaţii (tabele) 2) Completitudine,
neredundanţă, reutilizare, stabilitate şi flexibilitate, simplitate şi eleganţă. 3) Vezi p. XXX.



1) Implicarea utilizatorilor in proiectarea logica a bazei de date poate fi realizata prin:
a) includerea in echipa de proiectare a unui reprezentant al utilizatorilor
b) utilizarea instrumentelor CASE

c) angajarea unui demers iterativ

2) Spre deosebire de abordarea traditionala, strategia top-down de proiectare a bazei de date
prezinta urmatoarele avantaje:
a) exista un set complet de reguli de transformare a DER in tabele si legaturi ce permite
generarea automata a bazei de date
b) relatiile de dependenta functionala dintre atribute sunt mai putin numeroase decat
legaturile dintre entitatile de date
c) este mai analitica, prin aplicarea ei evitandu-se omiterea unor cerinte functionale


1. Realizaţi o comparaţie între cele două strategii de proiectare logică a bazei de date, bottom-
up şi top-down.
2. Daţi un exemplu de bază de date formată din două tabele, din domeniul contabilităţii, şi
puneţi în evidenţă conceptele principale ale modelului relaţional.

6.6 Bibliografie

1. Airinei, D., ş.a., Instrumente software pentru afaceri, Ed. Sedcom Libris, Iaşi, 2007, p. 131-
160
2. Teorey, T.J. – Database Modeling & Design, Morgan Kaufmann Publishers, Inc, 1999, San
Francisco, p. 40-52
99


Transformarea diagramelor entitate-relaţie în relaţii
ale bazei de date

Obiective:
Prezentarea modului de reprezentare a entităţilor de date într-o bază de date relaţională
Descrierea şi exemplificarea regulilor de transformare a legăturilor între entităţi în relaţii
(tabele) ale unei baze de date relaţionale
Proiectarea schemei logice a bazei de date prin aplicarea strategiei top-down

7.1 Reprezentarea entităţilor ...................................................................................................... 100
7.2 Reprezentarea legăturilor ..................................................................................................... 101
7.2.1 Reprezentarea legăturilor binare 1:N şi 1:1 .................................................................. 101
7.2.2 Reprezentarea legăturile binare de tip M:N şi a celor ternare ...................................... 103
7.2.3 Reprezentarea legăturilor unare .................................................................................... 106
7.3 Răspunsuri la testele de autoevaluare .................................................................................. 110
7.4 Lucrare de verificare ............................................................................................................ 110
7.5 Bibliografie .......................................................................................................................... 110

Din descrierile anterioare rezultă că normalizarea este un proces ascendent (bottom-
up), prin care se obţine un set de relaţii bine structurate, care să conţină toate datele
solicitate din exteriorul sistemului şi pe cele consemnate în ieşirile lui. Acum, vom
prezenta principalele reguli care se aplică în cadrul strategiei top-down, pentru
transformarea DER într-un set de relaţii normalizate, reunite într-un proces. El reprezintă
conţinutul celui de-al treilea pas al demersului propus pentru proiectarea logică a bazei de
date.
Prin transformarea DER, pot rezulta patru tipuri de tabele:
1. Tabele care vor avea acelaşi conţinut ca entităţile originale. Acest tip de tabele
rezultă din transformarea (1) entităţilor implicate în relaţii binare de tipul „multe-la-
multe”, (2) a celor situate în partea „unu” a unei relaţii binare „unu-la-multe” sau
(3) a uneia dintre cele două entităţi aflate într-o relaţie „unu-la-unu”; acelaşi tip de
tabele poate rezulta şi din transformarea (4) entităţilor cu relaţii recursive de tipul
„multe-la-multe” sau (5) a entităţilor implicate în relaţii ternare. Cheia primară a
acestor tabele va fi reprezentată de cheia entităţii originale, iar celelalte proprietăţi
ale entităţii vor deveni atribute non-cheie în tabela rezultată. Tabelele de acest tip
vor juca, întotdeauna, rolul de părinte în legăturile cu tabele încadrate în celelalte
tipuri.
2. Tabele care vor conţine cheia primară a entităţii părinte. Acest tip de transformări
apar în cazul (1) entităţilor aflate de partea „multe” a unei relaţii binare de tipul
„unu-la multe”, (2) a uneia dintre entităţile legate printr-o relaţie „unu-la unu”,
precum şi (3) a entităţilor cu legături recursive de tipul „unu-la-unu” sau „unu-la-
multe”. Tabelele rezultate în urma acestor transformări vor juca rolul de tabelă
copil. Ele vor avea ca atribute proprietăţile entităţii originale, la care se adaugă

cheia principală a entităţii cu care este legată şi care va juca rolul de cheie
străină/externă.
3. Tabele care vor conţine cheile tuturor entităţilor asociate într-o relaţie. Aceste
tabele derivă din transformarea (1) legăturilor binare sau recursive de tipul „multe-
la-multe”, precum şi (2) a legăturilor ternare sau de un ordin mai mare de trei. Ele
mai sunt numite şi entităţi asociative, iar o tabelă de acest tip va conţine cheile
primare ale tuturor entităţilor asociate, fiecare jucând rolul de cheie străină, precum
şi eventualele proprietăţi ale relaţiei. Cheia principală a tabelei este formată, de
regulă, prin combinarea cheilor străine.
4. Tabele care vor conţine atributele multivaloare ale unei entităţi. În cazul în care o
entitate conţine unul sau mai multe atribute multivaloare, atunci se va constitui o
tabelă distinctă care va conţine atributele multivaloare, preluând şi cheia entităţii
originale. De regulă, cheia primară va fi formată din cheia entităţii originale la care
se adaugă unul sau mai multe din celelalte atribute. Acest caz a fost discutat în
capitolul 10 din volumul 1, atunci când am prezentat entităţile atributive.
Regulile anterioare de transformare iau în considerare numai maximul cardinalităţii
relaţiilor dintre entităţi. Minimul cardinalităţii, care descrie caracterul obligatoriu/facultativ
al relaţiei dintre entităţi, indică dacă pentru cheile străine sunt permise valorile nule sau nu.
În acest sens, se va lua în considerare minimul cardinalităţii unei legături de partea entităţii
părinte (adică entitatea din partea în care maximul cardinalităţii este”unu”); dacă legătura
este opţională, atunci se vor permite valorile nule pentru cheia străină în tabela-copil; în
cazul legăturilor obligatorii, nu se vor permite valori nule pentru cheile străine.
Transformarea DER într-un set de tabele normalizate presupune parcurgerea a patru
paşi:
1. Reprezentarea entităţilor, în care se obţin tabele din prima categorie;
2. Reprezentarea relaţiilor dintre entităţi, activitate în urma căreia vor rezulta tabele
din a doua şi a treia categorie.
3. Reprezentarea atributelor multivaloare, caz în care se vor obţine tabele din ultima
categorie.
4. Normalizarea relaţiilor. Tabelele create în paşii 1 şi 2 pot conţine redundanţe
nedorite şi vor constitui surse ale anomaliilor la actualizare.
Deoarece subiectul de la pasul 4 a fost tratat disciplinei Baze de date, în cele ce
urmează vom discuta doar primii trei paşi.

7.1 Reprezentarea entităţilor

Fiecare entitate din diagrama entitate-relaţie este reprezentată ca o relaţie (tabelă) în
modelul logic al datelor. Identificatorul entităţii devine cheie primară a relaţiei, iar celelalte
proprietăţi ale entităţii devin atribute non-cheie. Ulterior, ca rezultat al transformării
legăturilor dintre entităţi, unele entităţi vor avea ca atribute cheile primare ale altor entităţi.
Ele se mai numesc şi entităţi slabe.
Reprezentarea unei entităţi ca relaţie se face în mod direct, după cum rezultă din figura
3.2, prin alegerea uneia dintre formele (b), (c) şi (d).
101

NUME

(a) MARCA ADRESA
ANGAJAT

(b) ANGAJAT (MARCA, NUME, ADRESA)
(c) ANGAJAT :MARCA, NUME, ADRESA
ANGAJAT

Marca Nume Adres a
(d)
1111 Ion Ion Arini, 28, Iasi
1112 Ion Ionel Anini, 120, Blaj

Fig. 3.2 Entitatea ANGAJAT şi formele de reprezentare ca relaţie

7.2 Reprezentarea legăturilor

Am recurs la noţiunea de legătură în locul celei de relaţie (cu sensul de înrudire)
pentru a nu se confunda cu termenul relaţie (sub accepţiunea de tabelă), care preia
conţinutul entităţilor din DER.
Procedura de reprezentare a legăturilor depinde atât de gradul legăturii (unară, binară,
ternară), cât şi de cardinalitatea ei (1:1, 1:M, M:N).

7.2.1 Reprezentarea legăturilor binare 1:N şi 1:1

O legătură binară unu-la-multe dintr-o diagramă entitate-relaţie este reprezentată prin

adăugarea atributului/atributelor-cheie-primară al/ale entităţii aflate în partea „unu” a
legăturii ca cheie-străină în tabela corespunzătoare entităţii aflată în partea „multe” (vezi
figurile 3.3 şi 3.4). Pentru cheia străină se acceptă valori nule numai dacă participarea
entităţii de partea „unu” a legăturii este facultativă.
În figura 3.3 este prezentată legătura „Onorare” dintre entităţile FACTURA şi
COMANDA, legătură de tip 1:N. Se vor constitui două relaţii, FACTURA şi COMANDA,
aferente celor două entităţi. Reprezentarea legăturii 1:N dintre cele două entităţi presupune
ca Fact_nr, care este cheie primară în tabela FACTURA (situată la capătul „unu” al
legăturii), să fie adăugată drept cheie-străină în tabela COMANDA (aflată la capătul
„multe” al legăturii). Am evidenţiat cheia străină nu doar prin scrierea cu caractere înclinate,
ci şi prin specificarea „[FK]” (de la „foreign key”) în dreptul ei, întrucât această modalitate
este frecvent întâlnită în produsele CASE.
Observaţi că pentru cheia străină (atributul Fact_nr din tabela COMANDA) se admite
valoarea nulă, dat fiind cardinalitatea minimă 0 din dreptul entităţii FACTURĂ, care este
părinte (participarea entităţii părinte este facultativă). Deşi în realitate pot exista situaţii de
tipul prezentat anterior, trebuie să spunem că ele trebuie evitate, deoarece admiterea valorii
nule pentru cheia străină poate crea dificultăţi în menţinerea integrităţii datelor din bază.
Relaţiile (tabelele) rezultate sunt prezentate în partea dreaptă a figurii 3.20. O altă
formă de prezentare o redăm mai jos (cheia primară este subliniată cu o linie continuă, iar
cheia străină cu o linie întreruptă):
FACTURA(Fact _nr, Fact_data)
COM ANDA(Cmd_nr, Cmd_data, Fact_nr)

Factura Fiecare comandă este onorata de
Fact_nr către furnizor prin intermediul a
Fact_data maxim o livrare (factură) sau nici Factura
una, în timp ce printr-o factură el Fact_nr
(0,1)
poate onora mai multe comenzi. Fact_data

Onorare

Comanda

Cmd_nr
(1,M) Cmd_data

Fact_nr
Fact_nr[FK]
[FK] NULL
NULL
Comanda
Cmd_nr
Cmd_data

Fig. 3.3 Transformarea relaţiilor 1:N în care
participarea entităţii din partea „unu” este facultativă

În figura 3.4 avem tot o relaţie 1:N, dar în care participarea entităţii de partea „unu” a
legăturii este obligatorie (cardinalitatea minimă este 1). Transformarea este asemănătoare
cu cea din exemplul anterior, singura diferenţă constând în faptul că nu se admit valori nule
pentru cheia străină. Observaţi, de asemenea, că participarea facultativă a entităţii aflate de
partea „multe” nu are efecte asupra transformării. Cele două relaţii rezultate sunt:

FURNIZOR (FURN_ID, FURN_NUME)

FACTURA(FACT_NR, FACT_DATA, FACT_ID)
O legătură binară de tip 1:1, dintre două entităţi A şi B, poate fi reprezentată în una
din următoarele modalităţi:
1. Adăugarea cheii-primare a entităţii A la entitatea B sub formă de cheie-străină.
2. Adăugarea cheii-primare a entităţii B la entitatea A, sub formă de cheie-străină.
3. Ambele cazuri (1 şi 2), dacă cerinţele de acces la date o cer.
4. Unirea celor două entităţi într-o singură tabelă, care va conţine atributele ambelor
entităţi şi a cărei cheie principală va fi aleasă dintre cheile celor două entităţi.

Furnizor
Furn_id
Furn_nume
Furnizor
O factură este emisă obligatoriu Furn_id
(1,1) de un furnizor, în timp ce un Furn_nume
furnizor ne poate emite mai
multe facturi sau nici una.

Emite

Factura

Fact_nr

(0,M) Fact_data
Furn_id [FK] NOT NULL
Factura
Fact_nr
Fact_data

Fig. 3.4 Transformarea relaţiilor 1:N în care
participarea entităţii din partea unu este obligatorie
103

Dacă participarea unei entităţi într-o legătură 1:1 este opţională, atunci ea va reprezenta
tabela părinte, iar cheia sa principală va fi adăugată în tabela corespunzătoare celeilalte
entităţi, jucând rolul de cheie străină. În figura 3.5, participarea entităţii ANGAJAT în
relaţia "conduce" cu entitatea DEPARTAMENT este opţională (cardinalitatea minimă este
0), deci tabela corespunzătoare ei va fi tabela-părinte, iar cheia sa, Ang_id va fi cheie
străină în tabela corespunzătoare entităţii DEPARTAMENT. Altfel formulată această
regulă, cheia primară a entităţii aflate în partea cu cardinalitatea minimă
1 va fi inclusă în tabela aferentă celeilalte entităţi şi va reprezenta cheia străină. De
asemenea, observaţi că pentru cheia străină nu se admite valoarea nulă. Relaţiile rezultate
sunt :
ANGAJAT (Ang_id, Ang_nume, Ang_saltf)

DEPARTAM ENT(Dep _id, Dep _nume, Ang_id)

Departament Fiecare departament trebuie să aibă
Dep_id un manager, iar un angajat poate fi
Dep_nume managerul unui singur departament Departament
dar nu este obligatoriu ca fiecare Dep_id
(0,1) angajat să conducă un depa rtament Dep_nume
Ang_id [FK] NOT

NULL
Conduce

(1,1) Angajat
Ang_id
Angajat Ang_nume
Ang_id Ang_saltf
Ang_nume
Ang_saltf

Fig. 3.5 Transformarea relaţiilor 1:1 în care
participarea uneia dintre entităţi este facultativă

7.2.2 Reprezentarea legăturile binare de tip M:N şi a celor ternare

Legăturile binare de tipul M:N şi legăturile ternare, indiferent de tipul cardinalităţii,

primesc acelaşi „tratament” la transformarea lor: pe lângă tabelele din prima categorie (vezi
începutul unităţii de studiu), create pentru fiecare entitate implicată în legătura respectivă,
se mai introduce o tabelă, corespunzătoare legăturii dintre entităţi, numită şi asociativă,
care va avea drept atribute cheile primare ale entităţilor asociate (şi care vor juca rolul de
chei străine) şi eventualele proprietăţi ale legăturii.
Regulile de definire a cheii primare diferă, în funcţie de ordinul şi cardinalitatea
legăturii. Vom exemplifica şi vom discuta în continuare câteva situaţii.
În figura 3.6 este prezentată legătura binară "Conţine", dintre entităţile PRODUS şi
FACTURA, cu cardinalitatea M:N. În urma transformării rezultă tabelele PRODUS şi
FACTURA, corespunzătoare celor două entităţi, şi LINIE_FACTURA, derivată din legătura
dintre cele două entităţi. Cea din urmă va conţine cheile primare ale celor două entităţi
asociate, precum şi atributele Cantitate şi Pret, care erau iniţial proprietăţi ale

legăturii "Conţine". De regulă, cheia acestei tabele se formează prin combinarea cheilor
celor două entităţi.
Cele trei tabele rezultate sunt:
PRODUS (PROD_ID, PROD_DEN)
FACTURA(FACT_NR, FACT_DATA)
LINIE_FACTURA(FACT_NR, PROD_ID, CANTITATE, PRET)

Fiecare factură conţine unul sau mai P rodus
Produs
Produs
Produs
multe produse , iar un produs se P
Prod_id
ro
rroro
od
od
dd
__id
iid
d
iidididd
Prod_id
Pro rroroo
od
rod
dd
__id
id
poate regăsi pe mai multe facturi P rod_den
Prod_den eenenn
Prod_den
id
id
iididd
sau niciuna.
P d d (1,M)

Articol_factura
Ar ArAA rrtico
rtico
tico ttico
icol
tico
l_
Cantitate
ticol
_f factu
l_cftu
Prod_id acctu
turcrtu
[FK]actu
cturra

Conţine Fact_nr
Prod_id iiddi[FK]
d[[FFKK]]
Cantitate
Factcct ctt_
_t__nr nr
nnn rr rn[F
rn r K]
Pret
Pret
[CFan
Kan
a]ntittittitateateate

(0,M)

Factu
Fac
Factura Factu Fac
Factura
tu
Factu
Factu
Fact_nractur
Fraa tu
Factu
actur
Fractur
Fact_nr a ra
a ra
ctur
Fact_data Factcct tct_
Fact_data _t_
_nr
nr
nnn
rrnrrnr
F ttttt
Fig. 3.6 Transformarea relaţiilor M:N

În figura 3.6 nu s-a mai specificat restricţia „NOT NULL” pentru cele două chei
străine din tabela ARTICOL_FACTURA, fiind inutilă de vreme ce ambele chei străine fac
parte din cheia primară.
Pot exista situaţii când relaţia constituită pe baza legăturii M:N dintre două entităţi nu
este suficient definită printr-o cheie-primară care conţine doar cheile-primare ale entităţilor
aflate în legătură, fiind necesară utilizarea suplimentară a unuia sau mai multor atribute.
Să pornim de la exemplul prezentat în figura 3.7.

Data Nota

StuStuStud
Student tuSdtud
en n
deen Profesoesoeso
Profesor sor
er
en
ent
eent ntt
Examinare r r
sor
Nr_matricol Cod_profesor
(0,M) (0,M
NrNN rN rr__r_
Nume_student m
_m atarico
tr CoCCo ood_
Cod_
Nume_prof d_dd_pro
_dd
__
ii ii i l i l f f
Fig. 3.7 Exemplu de relaţie definită prin chei primare şi atribute proprii

Pentru diagrama de mai sus, atributul DATA trebuie să fie o parte a cheii relaţiei
EXAMINARE, astfel:
EXAMINARE (NR_MATRICOL, COD_PROFESOR, DATA, NOTA)
Dacă fiecare examinare ar avea un cod propriu de identificare, data ar fi de prisos, iar
NR_MATRICOL şi COD_PROFESOR ar deveni chei-referinţă-încrucişată, după cum
urmează:
EXAMINARE (COD_EXAMINARE, NR_MATRICOL, COD_PROFESOR, DATA, NOTA)
105

Transformarea legăturilor ternare este asemănătoare cu cea aplicată legăturilor binare
de tip M:N. Deosebiri se înregistrează doar la definirea cheii primare a tabelei asociate
legăturii. În acest sens, se aplică următoarele reguli:
1. Dacă toate entităţile prezintă cardinalitatea maximă „unu”, atunci există trei
posibilităţi de formare a cheii primare (trei chei candidat), rezultate prin combinarea
oricăror două dintre cele trei chei ale entităţilor originale;
2. Dacă două dintre entităţi prezintă cardinalitatea maximă „unu”, atunci vor exista
două posibilităţi de formare a cheii: prin combinarea cheii primare a entităţii din
partea „multe” cu una dintre cheile entităţilor situate de partea „unu”;
3. Dacă o singură entitate prezintă cardinalitatea maximă „unu”, atunci cheia va fi
formată prin combinarea cheilor principale ale celor două entităţi situate de partea
„multe” a relaţiei;
4. Dacă toate cele trei entităţi prezintă cardinalitatea maximă „multe”, atunci cheia
primară va fi formată prin combinarea cheilor tuturor celor trei entităţi asociate.În
figura 3.8 este prezentat un exemplu de transformare a unei legături ternare cu cardinalitatea
1:M:N. Tabela EXAMEN, corespunzătoare legăturii dintre cele trei entităţi, va avea ca
atribute cheile primare ale celor trei entităţi, STUD_ID, PROF_ID şi DISC_ID, care vor
juca rolul de chei străine, precum şi atributele asociate legăturii, EXAM_DATA şi
EXAM_NOTA. Conform regulilor prezentate anterior (regula nr. 3), cheia primară a acestei
tabele ar trebui să fie formată din atributele STUD_ID şi DISC_ID. Însă, această
combinaţie nu este suficientă pentru a juca rolul de cheie primară, deoarece un student
poate susţine acelaşi examen de mai multe ori, situaţie în care vor exista mai multe linii
(tupluri) în relaţia EXAMEN care vor prezenta aceleaşi valori pentru cele două atribute.
Din acest motiv, în compoziţia cheii a fost inclus şi atributul EXAM_DATA.
Profesor
Profeso sosoor
sorrr
Prof_id
PrPrPrro
Poro
fo_fi_did
Prof_nume
P
drof_nume
1

D iscisciscip
Disciplina cispcl Examinare Student
Student
M N
li
ip
i
p n
la
i n
Disc_id a Stud_id
Stud
StudStud
tud_
S_
D iscscscc_
Disc_den sc_
__idid Stud_nume
_i
tud_
id_id

Fiecare student susţine un anumit examen cu un singur profesor ; un student
poate fi examinat de acelaşi profesor la mai multe discipline; un profesor
examinează la o anumită disciplină mai mulţi studenţi.

Profesor
Profeso sosoor
sorrr
Prof_id
PrPrPrro
Poro
fo_fi_did
Prof_nume
P
drof_nume

Disciplina
Discisciscip cispcl Ex
Examen
Ex Ex xa
Eaxame
amemm emeen
n Student
Student
liipnlaina
ip
Disc_id me
n mten
S
Stud_idund_id[FK] Stud
Stud_id
StudStud
tud_
S_
Disc_den
Discscscc_sc_
__idid [Disc_id
S FtuKd]_id [FK]
[FK] Stud_nume
_i
tud_
id_id
DExam_data
iscscscc_
sc_
__idid
[Prof_id
FK] [FK]
EExam_nota
xam_data
P P P Pf ifd id
Fig. 3.8 Transformarea legăturilor ternare de tipul 1:M:N

Relaţiile rezultate din transformarea legăturii "Examinare" sunt:
PROFESOR (PROF_ID, PROF_NUME)
STUDENT(MATRICOL, STUD_NUME)
DISCIPLINA(DISC_ID, DISC_DEN)
EXAMEN(MATRICOL, DISC_ID, EXAM_DATA, PROF_ID, NOTA)

TA 7.1
1. Ce este o entitate slabă?
2. Daţi un exemplu de legătură 1:M din domeniul contabilităţii şi realizaţi transformarea ei
într-un set de relaţii. Explicaţi regulile aplicate.
3. Ce reguli se aplică în cazul transformării unei legături M:N între două entităţi de date?
Răspuns:

7.2.3 Reprezentarea legăturilor unare

O legătură unară reprezintă o legătură între instanţele unei singure entităţi, numită şi
legătură sau asociere recursivă. În literatură sunt cele mai citate exemplele prin care
entitatea ANGAJAT are o legătură recursivă cu ea însăşi (un ANGAJAT „conduce” zero,
unul sau mai mulţi ANGAJAT(i)) sau structura unei reţete de fabricaţie în care ARTICOL
„conţine” zero, unul sau mai multe ARTICOL(e). Cele două exemple sunt prezentate în
figurile 3.9 şi 3.10. În primul exemplu avem o legătură recursivă de tipul 1:N, iar în cel de-
al doilea o legătură de tipul M:N.
Pentru o legătură unară de tip 1:N, în care intră cazul entităţii ANGAJAT, diagrama
este prezentată în fig. 3.9.
107

Un angajat poate conduce mai
ANGAJAT
ANGAJAT ANGAJAT
mulţi angajaţi sau nici unul, Marca_angajat
Marca_angajat
Marca_angajat (0,M)
Numemm
Nume ee iar fiecare angajat are un Nume
Alte_date
Alte_date manager şi numai unul Alte_date
Marca_manager [FK]
(1,1)

Conduce

Fig. 3.9 Diagrama legăturilor unare de tip 1:N şi transformarea lor

Pentru legătura unară de tip M:N, în care intră entitatea ARTICOL, diagrama este
redată în figura 3.10.

ARTICOL

ARTICOL
A RTICOL
Un articol poate conţine mai Cod_articol
multe articole, iar un articol
Co
Cod_articol
Co Co od
Cdod _ar
d_ar _ar
__ar (0,M ) Denumire
Denumire
art
_art_ic
art
icicol
ticiocio
lcicol
l olol
poate intra în fabricaţia mai Cost
De
Cost
olDeDenu nu numi
multor alte articole.

DDDD
i i
(0,M )

Contine
ARTICOL_COMPONENT
Cod_articol
Cod_componenta [FK]
Cantitate Cantitate

Fig. 3.10 Diagrama legăturilor unare de tip M:N

Pentru legătura unară 1:N, entitatea este modelată ca o relaţie, în care cheia primară
este cheia primară a entităţii. Relaţiei i se adaugă o cheie străină prin care se va face
referire la valoarea cheii-primare din aceeaşi relaţie.
O cheie-străină recursivă este o cheie-străină dintr-o relaţie care face referire la valorile
cheii-primare din aceeaşi relaţie. Reprezentarea legăturii unare 1:N din exemplul dat este:
ANGAJAT (MARCA_ANGAJAT, NUME, ALTE_DATE, MARCA_MANAGER)
în relaţia de mai sus, MARCA_MANAGER este o cheie-străină recursivă care îşi ia
valoarea din acelaşi domeniu cu MARCA_ANGAJAT.
Pentru legătura unară M:N, entitatea ARTICOL se va modela ca o relaţie, după care se
va crea o altă relaţie pentru scoaterea în relief a legăturii M:N. Cheia primară a acestei noi
relaţii este una compusă care va prelua cele două atribute, dar care nu trebuie să aibă
acelaşi nume, în schimb vor lua valori din acelaşi domeniu al cheii-primare. Orice alt
atribut ce trebuie adăugat noii legături (cum este CANTITATE) este inclus ca un atribut
non-cheie.
Rezultatul poate fi prezentat astfel:
ARTICOL (COD_ARTICOL, DENUMIRE, COST)
ARTICOL_COMPONENT (COD_ARTICOL, COD_COMPONENTA, CANTITATE)
Prin tot ceea ce s-a tratat în paragraful de faţă, s-a demonstrat modul în care se pot
transforma diagramele entitate-relaţie în relaţii. În tabelul 3.3 sunt descrise regulile de
transformare a DER în relaţii.

Tabel nr. 3.3 – Transformarea relaţională a structurilor entitate-relaţie

Structura entitate-
Reprezentarea relaţională
relaţie
Entităţi normale Se creează o relaţie care are o cheie primară şi atribute non-cheie.
Entitate slabă Crearea unei relaţii cu o cheie primară compusă (în care este inclusă
cheia primară a fiecărei entităţi de care depinde această entitate) şi cu
atributele non-cheie.
Legătura binară sau Plasarea cheii-primare a oricărei entităţi în relaţia creată din cealaltă
unară 1:1 entitate sau efectuarea acestui lucru pentru ambele entităţi.
Legătura binară 1:M Se plasează cheia-primară a entităţii aflate lângă partea „unu” a legăturii
ca o componentă specială (cheie străină) a relaţiei care se află lângă
partea „multe” a legăturii.
Legăturile sau Crearea unei relaţii cu o cheie-primară compusă, folosind cheile primare
gerundivele binare ale entităţilor înrudite, plus orice atribute non-cheie ale legăturii sau
sau unare M:N gerundivei.
Legăturile sau Crearea unei relaţii cu o cheie primară compusă, folosind cheile primare
gerundivele binare ale entităţilor înrudite şi atribute suplimentare folosite drept cheie
sau unare M:N cu primară asociate legăturii sau gerundivei, plus orice alte atribute non-
chei suplimentare cheie ale legăturii sau gerundivei.
Legăturile sau Creare unei relaţii cu cheia primară asociată legăturii sau gerundivei,
gerundivele binare plus orice alte atribute non-cheie ale legăturii sau gerundivei, iar cheile
sau unare M:N cu primare ale entităţilor înrudite sunt folosite tot ca atribute non-cheie.
chei proprii
Legătura IS-A (clasă Crearea unei relaţii pentru clasa superioară care să conţină propria cheie
– subclasă) primară şi atributele comune tuturor subclaselor, plus crearea a câte unei
relaţii separate pentru fiecare subclasă cu aceeaşi cheie primară (cu
nume identic sau propriu) dar care să conţină numai atributele specifice
subclasei respective.

În Caseta 3.1 se pleacă de la exemplul sistemului de gestiune a clienţilor şi se reia
procesul de proiectare a bazei de date de la modelul conceptual al datelor (diagrama
entitate-relaţie), construit în timpul analizei sistemului. În casetă se regăseşte modul de
aplicare a unora dintre regulile descrise anterior.
Transformarea diagramei entitate-relaţie (DER) începe cu reprezentarea entităţilor.
Comparând figurile C3.1 şi C3.2, se poate constata că pentru fiecare entitate de date a fost
creată câte o tabelă în baza de date. Astfel, în fig. C3.2 se regăsesc tabelele CLIENT,
COMANDA, LIVRARE, RETURNARE, DEPOZIT şi PRODUS. Cele şase tabele au
preluat cheile primare şi atributele non-cheie ale entităţilor corespondente.
În continuare, se trece la analiza legăturilor dintre entităţi, urmărindu-se ordinul şi
cardinalitatea acestora. Din punctul de vedere al ordinului, toate legăturile din DER sunt
binare, iar din cel al cardinalităţii maxime avem trei tipuri: 1:1, 1:N şi M:N.
Singura legătură de tipul 1:1 este Corespunde, dintre LIVRARE şi RETURNARE.
Întrucât participarea entităţii LIVRARE în acestă legătură este facultativă (cardinalitatea
minimă este 0), tabela corespondentă va fi părinte, iar cheia primară a acesteia, NrFactura,
va fi inclusă în tabela RETURNARE şi va juca rolul de cheie străină. Deoarece în tabela
RETURNARE exista deja un atribut cu acelaşi nume, atributul inclus se numeşte
NrFacturaL.
109

Caseta nr. 3.1 – Proiectarea bazei de date plecând de la modelul conceptual

Comanda Returnare
CodComanda
(0,1) Livrare (1,1) NrFactura
NrComanda (1,M) (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)

(1,M)
Depozit
(1,M)
Client CodDepozit
Produs
NumeDepozit Este în
CodClient CodProdus
NumeClient stoc DenProdus
(0,M)
Adresa UM
CodFiscal Conţine PretUnitar
Sold (1,M)
LimitaCredit
TipClient
Cantitate
comandata

Fig. C3.1 Modelul conceptual al datelor pentru sistemul de gestiune a clienţilor

Rezultatul transformării modelului conceptual este prezentat în figura c3.2.
Client
CodClient Livrare
NumeClient NrFactura
Adresa DataFactura
CodFiscal CodDepozit[FK] Not null
Sold
LimitaCredit
TipClient

Returnare
NrFactura
Depozit DataFactura
CodDepozit NrNotaRefuz
NumeDepozit DataRefuz
Comanda Motivatie
CodComanda NrFacturaL[FK] Not null
NrComanda

DataComanda
Stocuri
TermenLivrare
StareComanda CodDepozit [FK]

CodClient[FK] Not null
NrFactura[FK] Null
CodProdus [FK]
StocCurent

ProduseReturnate
NrFactura [FK]
CodProdus [FK]
CantitateReturnata
Produs
ProduseComandate
CodProdus
CodComanda [FK]
DenProdus
CodProdus [FK]
UM
CantitateComandata
PretUnitar
Fig. C3.2 Schema logică a bazei de date pentru sistemul de gestiune a clienţilor

Legăturile de tip 1:N sunt trei: emite, dintre CLIENT şi COMANDA; onorare, dintre
COMANDA şi LIVRARE; emite, dintre LIVRARE şi DEPOZIT. În cazul tuturor celor trei
legături, entitatea aflată de partea „multe” a preluat cheia primară a entităţii aflată de partea
„unu”. Astfel, tabela COMANDA are două chei străine, CodClient şi NrFactura, prin
intermediul cărora se stabilesc legăturile cu tabelele CLIENT, respectiv LIVRARE, iar
tabela LIVRARE conţine o cheie străină, CodDepozit, care asigură legătura cu tabela
DEPOZIT. O particularitate apare în cazul legăturii Onorare, deoarece participarea entităţii
părinte, LIVRARE, este facultativă. Prin urmare, se vor admite valori nule pentru atributul

NrFactura din tabela COMANDA, care este cheia străină rezultată din transformarea
acestei legături. Pentru celelalte chei străine nu se admite valoarea nulă, fapt specificat în
fig. C3.1 prin adăugarea „Not null” în dreptul lor.
Legăturile Conţine, dintre COMANDA şi PRODUS, Este în stoc, dintre DEPOZIT şi
PRODUS, şi Conţine, dintre RETURNARE şi PRODUS, sunt de tipul M:N. Pentru toate
cele trei legături s-a creat câte o tabelă nouă, rezultând tabelele PRODUSECOMANDATE,
STOCURI şi PRODUSERETURNATE. Fiecare tabelă conţine cheile primare ale entităţilor
legate, ele jucând rolul de cheie străină, precum şi atributele descriptive ale legăturii
corespondente. Cheia primară este formată, pentru toate cele trei tabele, din combinaţia
cheilor străine.
În final să remarcăm că fiecare cheie străină apare ca urmare a unei legături dintre
tabele, iar fiecărei legături îi corespunde o cheie străină.
În practică, transformarea DER poate să nu fie chiar atât de simplă, uneori fiind
necesară modificarea bazei de date obţinute de către echipa de proiectare, pe baza
experienţei şi a regulilor euristice de care dispune.


TA 7.1 1) Entităţile care vor avea ca atribute cheile primare ale altor entităţi . 2) Vezi
exemplul din fig. 3.4 3) Se creează câte o tabelă pentru fiecare entitate; se adaugă a treia
tabelă corespunzătoare legăturii M:N; a treia tabelă conţine cheile primare ale celorlalte
două tabele, ce vor juca rolul de chei străine, şi eventualele atribute ale legăturii M:N; cheia
primară a celei de-a treia tabele se formează, de regulă, prin combinarea celor două chei
străine.



1) Doua entitati din DER sunt reprezentate prin trei relatii (tabele) in modelul relational atunci
cand legatura dintre cele doua entitati este de tip:
a) 1:1
b) M:N
c) 1:N

2) O legatura binara de tipul 1:1 intre doua entitati de date, A si B, poate fi reprezentata in
modelul logic al datelor astfel:
a) reunirea celor doua entitati intr-o singura tabela
b) crearea a trei tabele, cate una pentru cele doua entitati si una pentru legatura
c) adaugarea cheii-primare a entitatii A la entitatea B sub forma de cheie-straina


1. Ce este o entitate asociativă? Daţi un exemplu.
2. Daţi un exemplu din domeniul contabilităţii prin care să puneţi în evidenţă transformarea
unei legături ternare, indiferent de cardinalitatea acesteia.

7.5 Bibliografie

1. Date, C.J., Baze de date, Editura Plus, Bucureşti, 2005, p.148-167
2. Fotache, M., Proiectarea bazelor de date. Normalizare şi postnormalizare, Ed. Polirom, Iaşi,
2005, p. 60-95
111


Proiectarea programelor şi a procedurilor

Obiective:
Prezentarea principalelor concepte utilizate în proiectarea programelor
Definirea arhitecturii programelor
Descrierea principalelor structuri de control utilizate la realizarea programelor
Participarea la deciziile de proiectare arhitecturală a programelor din perspectiva analistului
(a specialistului în domeniul de activitate a sistemului dezvoltat)
Redarea logicii prelucrărilor din domeniul contabilităţii cu ajutorul structurilor logice de
control

8.1 Aspecte generale ale proiectării programelor şi procedurilor .............................................. 111
8.1.1 Definirea arhitecturii programelor ................................................................................ 112
8.1.2 Structurile de control ale programelor .......................................................................... 113
8.4 Bibliografie .......................................................................................................................... 118

Până în această fază ne-am ocupat, mai întâi, de proiectarea interfeţelor sistemului,
care apar sub forma formularelor/formatelor sau rapoartelor, a ecranelor sau secvenţelor de
dialog. Apoi, ne-am ocupat de proiectarea bazei de date, urmărind transpunerea cerinţelor
din modelul conceptual al datelor în schema logică (modelul relaţional). Proiectarea
intrărilor, ieşirilor şi a stocării datelor fiind rezolvată, nu ne rămâne decât să ne aplecăm
asupra cerinţelor privind prelucrările din sistem, în scopul transpunerii lor în programe.
Prin problematica prezentată în unitatea de studiu de faţă intrăm în domeniul de
activitate al proiectanţilor de soft şi al programatorilor. Proiectantul de soft are ca principală
misiune definirea şi structurarea componentelor care vor forma un tot unitar, astfel încât
prin acestea să se obţină un proiect soft operaţional. După proiectanţii de soft vor
interveni programatorii, pentru transpunerea în realitate a proiectului. Ei vor controla
intrările, prelucrările, stocările şi ieşirile din sistem prin intermediul programelor.

8.1 Aspecte generale ale proiectării programelor
şi procedurilor

Programul, în concepţia diverşilor autori, are semnificaţii diferite. El este definit ca:
o entitate ce poate fi executată pe calculator;
un mijloc de comunicare cu calculatorul pentru rezolvarea unei probleme;
o descriere a unui algoritm şi a datelor asociate în vederea execuţiei pe calculator,
deci o reprezentare a acestora (algoritmi şi date) ţinând cont de restricţiile impuse
de calculator;
o realizare a unei funcţii f care, dată fiind o mulţime de date x, specifică o valoare y
= f(x); multitudinea datelor permise ca date de intrare formează domeniul

programului, iar mulţimea ieşirilor care pot fi obţinute prin intermediul programului
constituie codomeniul acestuia.
În continuarea acestui paragraf, vom urmări să definim noţiunea de arhitectură a
programelor, să descriem succint principiile de lucru aplicabile în proiectarea programelor
şi să trecem în revistă structurile fundamentale de control utilizate nu doar în descrierea
logicii modulelor, ci şi în descrierea arhitecturii programelor.

8.1.1 Definirea arhitecturii programelor

Arhitectura unui sistem informatic face referire la structura sa. Conform teoriei
generale a sistemelor, prin structură se descriu elementele componente ale sistemului,
interconexiunile între acestea, pe de o parte, între acestea şi sistem, pe de altă parte.
Noţiunea de structură poate fi definită din perspectiva transformărilor prin care trece
sistemul în interacţiunea cu mediul său, considerându-se că ea face referire la aspectul
invariant al sistemului, dând identitatea acestuia. Ea defineşte o ordine relativ stabilă,
referindu-se la anumite caracteristici invariabile în condiţiile variabilităţii intrărilor, ieşirilor
şi stărilor sistemului.
Într-o manieră generică, arhitectura unui program defineşte componentele acestuia,
proprietăţile lor vizibile din exterior, precum şi relaţiile dintre componente. Concretizarea
definiţiei anterioare presupune specificarea semnificaţiei atribuite noţiunii componentă,
după care vor putea fi identificate proprietăţile lor şi natura relaţiilor dintre ele.
În cazul programelor, putem vorbi despre două categorii de componente: instrucţiunile
(în alte materiale fiind regăsite sub numele de enunţuri, în altele – declarative, de la
cuvântul englezesc statements) şi modulele. Ele constituie „materia primă” din care se
realizează programele aplicaţiilor.
Instrucţiunile sunt operaţiuni elementare executate de calculator prin gruparea şi
selecţia controlată a acestora pentru atingerea obiectivelor funcţiilor de prelucrare orientate
pe probleme. Instrucţiunile constituie cel mai de jos nivel al operaţiunilor ce pot fi executate
de către un limbaj de programare. Blocurile de instrucţiuni sunt astfel grupate încât să
constituie anumite structuri executabile de calculator. De modul în care sunt grupate
instrucţiunile pentru a da naştere unor structuri standard ale programelor, de relaţiile dintre
instrucţiuni, de aranjamentul acestora depinde calitatea softului proiectat.
Modulul este o unitate structurală de sine stătătoare, fie program, fie subprogram, ce
apare ca o colecţie sau o formă grupată de instrucţiuni program. El reprezintă o unitate de
program ce poate fi compilată separat. Modulele se pot grupa pentru a forma programele,
deci, la nivelul softului proiectat, modulul reprezintă componenta de bază.
Odată ce am clarificat semnificaţia noţiunii de componentă în arhitectura programelor,
acum va trebui să identificăm proprietăţile modulelor de program. Astfel, un modul prezintă
trei atribute (proprietăţi) de bază, prin intermediul cărora el poate fi descris: funcţia,
logica şi interfaţa.
Funcţia unui modul face referire la transformările realizate asupra datelor în urma
execuţiei acestuia. Funcţia este tratată în regimul cutiei negre, adică ea este văzută prin
ceea ce se percepe din exteriorul modulului, respectiv intrările, ieşirile şi rolul modulului,
fără a privi componentele interne ale modulului (instrucţiunile şi logica modulului).
Logica modulului descrie prelucrările care au loc în interiorul acestuia, ceea ce, spre
deosebire de funcţie – referită ca o cutie neagră, ar însemna tratamentul cutiei albe. La
nivelul programării, preocuparea este, în esenţă, legată de logica modulului. Algoritmii de
prelucrare, redaţi sub diverse forme – scheme logice, pseudocod, tabele de decizie, arbori
113
de decizie sau combinaţii ale acestora – sunt concepuţi pentru prezentarea modului de
transformare a intrărilor în ieşiri. Paşii algoritmilor se vor transforma în instrucţiuni ale
limbajelor de programare. Fiecare modul va avea un singur punct de intrare şi un singur
punct de ieşire.
Interfeţele fac referire la structurile de date transferate între module. De cele mai multe
ori, pentru a-şi îndeplini funcţia, modulele trebuie să primească anumite date şi, la rândul
lor, să transmită rezultatele prelucrării altor module.
Aşa cum spuneam anterior, arhitectura unui program face referire numai la proprietăţile
componentelor vizibile din exterior, adică funcţia şi interfeţele modulelor. Proprietăţile
interne ale componentelor, reprezentate de detaliile logicii algoritmilor din module, nu
sunt luate în considerare la definirea arhitecturii programelor, ele nefiind vizibile din
exterior.
Din acest punct de vedere, putem distinge două mari activităţi în proiectarea
programelor: proiectarea arhitecturală şi proiectarea logicii modulelor. Proiectarea
arhitecturală presupune găsirea soluţiilor privind descompunerea sistemului în părţi
componente astfel încât fiecare parte să fie mai puţin complexă decât sistemul ca întreg, iar
prin integrarea acestor componente sistemul să fie cât mai flexibil, să îndeplinească
cerinţele funcţionale şi criteriile de calitate specifice programelor. În condiţiile în care
complexitatea modulelor este rezonabilă, este foarte important ca interfeţele dintre acestea
să nu fie prea complicate. Logica modulelor vizează algoritmii de prelucrare ce vor fi
implementaţi în vederea obţinerii funcţionalităţii prevăzută pentru fiecare modul în parte.
Ultimul aspect relevant, din perspectiva arhitecturii programelor, se referă la natura
relaţiilor dintre componente. Relaţiile dintre modulele unui program se înregistrează pe
două planuri:
al transferării controlului execuţiei de la un modul la altul;
al transmiterii datelor de la un modul la altul.
Arhitectura programelor prezintă o mare importanţă în activitatea de proiectare din cel
puţin patru motive25:
conceperea arhitecturii programului permite o mai bună comunicare între membrii
echipei de dezvoltare a sistemului informatic, pe baza ei putându-se discuta şi
analiza inclusiv aspectele calitative relevante ale programelor;
arhitectura evidenţiază principalele decizii de proiectare care au un impact profund
asupra activităţilor ulterioare privind dezvoltarea programului şi în succesul
acestuia;
arhitectura oferă un model relativ simplu al modului în care este structurat sistemul
şi modul în care componentele sale interacţionează, facilitând repartizarea sarcinilor
de lucru privind proiectarea şi scrierea programelor pe fiecare membru al echipei;
arhitectura reprezintă o unitate transferabilă a sistemului informatic, deoarece ea
facilitează reutilizarea componentelor atât în cazul unor sisteme similare, cât şi al
reproiectării sistemului.

8.1.2 Structurile de control ale programelor

După o perioadă de artizanat în activităţile de programare, analiză şi proiectare, s-a

trecut la abordarea structurată a acestora, ceea ce a însemnat impunerea unor restricţii de
utilizare, cu scopul creşterii strandardizării şi a eficienţei activităţilor susmenţionate.

25. Presmann, R.S. – Software Engineering. A practitioner’s Approach, McGraw Hill Publishing Company, London,
2000, p. 359.

Controlul se referă la relaţiile posibile dintre componentele programului. Structurile de
control al logicii, cunoscute şi sub numele de structuri de control fundamentale, reprezintă
un set minim, dar necesar, de reguli prin care să se controleze procesul de activare a
componentelor de prelucrare dintr-un program sau dintre modulele acestuia. Structurile
sunt: secvenţa, selecţia şi iteraţia sau repetiţia. Ele mai sunt cunoscute şi sub numele de
structură secvenţială, alternativă (simplă şi generalizată), repetitivă (condiţionată anterior
sau la început şi condiţionată posterior sau la sfârşit).
Secvenţa asigură parcurgerea instrucţiunilor în ordinea în care apar. Selecţia defineşte
alegerea unui grup de instrucţiuni din două sau mai multe posibile. Iteraţia oferă
posibilitatea execuţiei repetate a unui grup de instrucţiuni.
În elaborarea programelor structurate este necesar să se respecte o serie de restricţii, şi
anume:
fiecare element (secvenţa, selecţia, iteraţia) are un punct unic de intrare;
fiecare element are un punct unic de ieşire;
elementul de iteraţie permite şi o execuţie cu factor de repetiţie zero, adică
excluderea elementului respectiv din execuţie.
Fiecare element din cele enunţate (secvenţa, selecţia, iteraţia) care respectă restricţiile
de mai sus defineşte un bloc standard. De asemenea, orice combinaţie de blocuri standard
care respectă restricţiile precizate defineşte un bloc standard.
Structura secvenţială (liniară) se prezintă astfel (fig. 4.1):

S1

S2

Sn

Fig. 4.1 Structura secvenţială

Selecţia (structura de tip IF-THEN-ELSE) sau structura alternativă are următoarea
formă de reprezentare (fig. 4.2):

Nu Da
C

Bloc-2
Bloc-2 Bloc-1

Fig. 4.2 Structura alternativă
115
de decizie sau combinaţii ale acestora – sunt concepuţi pentru prezentarea modului de
operaţiile din Bloc-2; după execuţia blocului, se continuă cu instrucţiunea următoare.
Când Bloc-2 nu conţine nici o operaţiune, rezultă o structură alternativă cu o ramură
vidă, de tip IF-THEN, redată în figura 4.3.

Nu Da
C

Bloc-1

Fig. 4.3 Structura alternativă cu o ramură vidă

Structura alternativă generalizată (de tip CASE-OF) este o generalizare a selecţiei. Ea
permite alegerea unei variante din mai multe posibile (fig. 4.4).

C

Bloc-11
Bloc- Bloc-2 Bloc-n

Fig. 4.4 Structura alternativă generalizată

Iteraţia sau structura repetitivă defineşte execuţia repetată a unei operaţii sau grup de
operaţii, funcţie de rezultatul evaluării unei condiţii. Evaluarea condiţiei se face fie înainte,
fie după executarea operaţiilor.
Structura repetitivă condiţionată anterior (de tip WHILE-DO) se reprezintă ca în
figura 4.5.
Structura repetitivă condiţionată posterior (de tip DO UNTIL) are forma redată în
figura 4.6.

Bloc-1

C
Da

Nu

Fig. 4.5 Structura repetitivă condiţionată anterior

Bloc-1

C
Da

Nu

Fig. 4.6 Structura repetitivă condiţionată posterior

O formă particulară de structură repetitivă condiţionată posterior este structura
repetitivă cu număr definit de paşi (de tip DO FOR). Numărul de repetiţii este controlat de
o variabilă, numită variabilă de control. În reprezentarea grafică următoare, V este variabila
de control, Vi este valoarea iniţială a variabilei de control, Vf este valoarea finală a
variabilei de control, iar R este raţia (incrementul). O astfel de structură este redată în
figura 4.7.
În literatura de specialitate, se consideră că structura secvenţială, structura alternativă
de tip IF-THEN-ELSE şi structura repetitivă condiţionată anterior sunt suficiente pentru a
defini structura de control a oricărui program Din acest motiv, cele trei structuri de control,
enumerate mai sus, sunt numite structuri fundamentale sau structuri de bază.
117

V:=Vi

Bloc-1

V:=Vi+R

V>Vf Nu

Da

Fig. 4.7 Structura repetitivă cu număr definit de paşi

TA 8.1
1. Ce semnifică interfaţa modulelor de program?
2. Prezentaţi succint atributele de bază ale unui modul de program.
3. Redaţi în formă grafică structura de control alternativă generalizată.
Răspuns:


TA 8.1 1) Structurile de date transferate între două module de program. 2) Fucţia, logica
modulului şi interfaţa 3) Vezi fig. 4.4.



1) Care dintre următoarele restricţii, în legătură cu structurile de control (secvenţa, selecţia,
iteraţia), trebuie respectate la elaborarea programelor?
a) fiecare structură de control trebuie să aibă cel puţin o intrare şi cel puţin o ieşire
b) fiecare structură de control trebuie să aibă un punct unic de intrare şi unul de ieşire
c) fiecare structură de control trebuie să conţină cel puţin 2 căi de execuţie
d) elementul de iteraţie să permită şi o execuţie cu factor de repetiţie 0

2) Structura alternativă generalizată permite:
a) alegerea mai multor variante posibile
b) includerea unei ramuri vide
c) alegerea unei variante din mai multe posibile

3) Prin arhitectura unui program se face referire la:
a) logica prelucrărilor din fiecare modul de program
b) funcţia fiecărui modul de program
c) interfeţele utilizator
d) interfeţele dintre modulele de program

1. Definiţi următoarele concepte: program, modul de program, arhitectura programelor, logica
modulului de program.
2. Daţi un exemplu de prelucrare din domeniul contabilităţii prin care să puneţi în evidenţă o
structură de control alternativă simplă.

8.4 Bibliografie

Universităţii “Al. I. Cuza” Iaşi, 2006, pp. 215-225, 241-251
2. Presmann, R.S. – Software Engineering. A practitioner’s Approach, McGraw Hill
Publishing Company, London, 2000, p. 356-364
119


Implementarea sistemului. Testarea sistemelor
informaţionale

Obiective:
Înţelegerea importanţei planificării implementării
Înţelegerea obiectivelor şi a principiilor testării sistemelor informaţionale
Descrierea activităţilor din cadrul procesului de testare
Clasificarea tehnicilor de testare
Definirea strategiei de testare
Definirea obiectivelor testării sistemelor informaţionale
Aplicarea unor tehnici de testare

9.1 Planificarea implementării ................................................................................................... 120
9.2 Testarea sistemelor informaţionale ...................................................................................... 121
9.2.1 Aspecte generale privind organizarea testării sistemelor.............................................. 121
9.2.2 Tehnici de testare .......................................................................................................... 124
9.2.3 Strategia testării sistemelor informatice........................................................................ 128
9.5 Bibliografie .......................................................................................................................... 133

Dintre toate etapele dezvoltării sistemului, implementarea are gradul de risc cel mai
mare. Acest lucru se datorează faptului că, în timpul etapelor anterioare (microanaliză,
analiză, proiectare), proiectul de dezvoltare este desfăşurat într-un mediu ce nu afectează
activităţile zilnice ale firmei. În schimb, implementarea presupune influenţarea
operaţiunilor economice reflectate de către sistemul dezvoltat, prin faptul că ea constă în
înlocuirea efectivă a sistemului vechi, ceea ce înseamnă că orice eroare nedepistată nici
acum poate declanşa grave probleme. De aceea, este necesar ca activităţile etapei de
implementare să fie planificate şi gestionate cu atenţie pentru a minimiza cât mai mult
potenţialele efecte negative şi să se conceapă un plan de acţiune pentru evenimentele
neprevăzute.
Implementarea este procesul de transformare a componentelor proiectate într-un sistem
funcţional. Într-o formă destul de concentrată, în caseta 5.1, prezentăm conţinutul unui
raport al proiectării pentru firma ABC.

Caseta nr. 5.1 – Conţinutul raportului proiectării
S.C. ABC
Raportul proiectării sistemelor
I. Sinteza proiectării fizice a sistemelor
II. Prezentarea generală a scopului proiectului şi sinteza la zi a constatărilor de pe teren
III. Recomandările principale ale proiectării fizice
1. Proiectarea ieşirilor
2. Proiectarea intrărilor

3. Proiectarea bazelor de date
4. Proiectarea prelucrărilor (softului)
5. Proiectarea echipamentelor
6. Proiectarea controalelor
7. Proiectarea procedurilor de lucru
IV. Ipoteze de lucru şi probleme nerezolvate
V. Concluzii
VI. Anexe şi glosar de termeni
Implementarea sistemelor este procesul de instalare a echipamentelor şi softului, în
vederea finalizării sistemului şi dării lui în funcţiune. Operaţiunea se derulează printr-un
set bine definit de activităţi, redate în fig. 5.1.

Planificarea
Plan carea mpimplementării
emen ări

Pregătirea locurilor
Pregătirea locurilo

Realizarea şi Selectarea şi
de muncă; instalarea
testarea şi testarea instruirea
programelor echipamentelor personalului

Finalizarea Testarea
documentaţiei
documenta iei sistemului

Conversia de la
vechiul la noul
sistem

Fig.5.1 Principalele activităţi ale etapei de implementare

9.1 Planificarea implementării

În timpul implementării, vor fi executate simultan mai multe activităţi. De aceea, ele
trebuie să fie planificate şi programate de către o echipă de implementare formată din
utilizatori, manageri şi specialişti în proiectarea sistemelor.
Planificarea implementării, firesc, începe anterior demarării unei astfel de acţiuni. De
fapt, problemele implementării sunt abordate chiar la începutul proiectului, iar aspectele
conceptuale şi strategiile implementării şi conversiei sistemelor trebuie să fie luate în
discuţie în fiecare stadiu al ciclului de viaţă al sistemelor. Totuşi, planurile detaliate de
implementare nu pot fi finalizate până când conducerea nu aprobă proiectul noului sistem.
Planul de implementare este revizuit şi modificat la intervenţiile comitetului de
informatizare, ale utilizatorilor, ale conducătorilor sistemului, înainte de a începe
operaţiunea de implementare.
Un plan de implementare evidenţiază toate activităţile necesare, ajutând pe cei ce-l
întocmesc să fie siguri că totul a fost prezentat corect. Prin el se vor consemna toate
activităţile de efectuat, precum şi timpul alocat. Responsabilităţile de execuţie trebuie să fie
121

foarte clare. De asemenea, trebuie estimate costurile fiecărei activităţi astfel încât să poată
fi elaborat un buget special. În acelaşi timp, trebuie determinate reperele de executat în
timp, pentru a putea fi controlate. Mai dificil este de estimat momentul când se va finaliza
implementarea. De fiecare dată utilizatorii sunt cei care îşi dau acceptul final, iar procesul,
teoretic, poate fi considerat ca desfăşurându-se pe o perioadă nedefinită.
Planificarea, coordonarea şi controlarea activităţii de implementare sunt cel mai des
realizate prin două tehnici cunoscute: diagramele Gantt şi PERT.
Dintre cele mai relevante aspecte ale planificării implementării, pot fi enumerate:
începe odată cu luarea startului conceperii unui nou proiect;
se încheie odată cu aprobarea dată pentru implementare;
aprobarea planului de implementare, firesc, se obţine înainte de a începe această
etapă;
identificarea activităţilor principale, a desfăşurării lor calendaristice, a
responsabilităţilor, precum şi a rezultatelor finale ale acestora;
urmărirea riguroasă a modului în care se respectă planul de implementare;
identificarea factorilor de risc şi a modalităţilor strategice de eliminare sau de
diminuare a riscurilor;
apelarea la diagramele Gantt pentru urmărirea modului de desfăşurare a etapei de
implementare;
folosirea tehnicii PERT pentru identificarea activităţilor critice.
Planul de implementare are un rol esenţial în derularea activităţilor specifice şi de el
depind calitatea sistemului şi momentul în care poate dat în exploatare. Fără a face neapărat
o ierarhie, se consideră că planificarea implementării ocupă unul din primele locuri între
factorii de succes sau eşec al unui proiect, pentru că prin implementare se asigură, până la
urmă, funcţionarea sistemului.

9.2 Testarea sistemelor informaţionale

Dezvoltarea rapidă a tehnologiilor informaţionale a determinat extinderea rapidă a
ariei de informatizare, condiţii în care calitatea existenţei noastre depinde din ce în ce mai
mult de calitatea sistemelor informatice cu care lucrăm. De aceea, trebuie acordată o atenţie
deosebită activităţilor de testare. Testarea este ultima ocazie pentru revizuirea cerinţelor
sistemului, a specificaţiilor de proiectare şi a programelor sursă. Obiectivul general al
testării îl reprezintă identificarea numărului maxim de erori cu efort minim.
În general, cheltuielile asociate activităţii de testare pot ajunge până la o pondere de
30-40% din totalul cheltuielilor necesare dezvoltării unui sistem informatic. În domeniile
cu activităţi critice (controlul traficului aerian, monitorizarea reactoarelor nucleare etc)
aceste cheltuieli pot fi de 3-5 ori mai mari decât toate celelalte cheltuieli cu dezvoltarea
sistemului informatic26.

9.2.1 Aspecte generale privind organizarea testării sistemelor

Testarea este un termen mai general care face referire la alte două noţiuni: verificarea
şi validarea. Verificarea reprezintă procesul de evaluare a sistemului sau a unei

26. Pressman, R.S. – Software Engineering. A Practitioner’s Approach, Fifth Edition, McGraw-Hill Publishing
Company, London, 2000, p.426.

componente a lui, pentru a se determina dacă o anumită funcţie a fost implementată corect,
oferind răspunsul la întrebarea: A fost construit bine sistemul? Validarea poate fi definită
ca procesul de evaluare a sistemului sau a unei componente a lui, pentru a se determina
dacă sunt respectate cerinţele funcţionale identificate în faza de analiză, răspunzând la
întrebarea: A fost construit sistemul care trebuie? Aşadar, verificarea vizează modul cum a
fost construit sistemul, iar validarea se referă la ce a fost construit. Atât verificarea, cât şi
validarea trebuie desfăşurate pe parcursul întregului proces de dezvoltare a sistemului, nu
doar la sfârşitul acestuia.
Practic, testarea întregului sistem nu este posibilă, deoarece ea nu ar fi fezabilă
economic şi tehnic. Un exemplu simplu este edificator: dacă un program conţine două
structuri de control repetitive imbricate, fiecare din cele două structuri presupunând un
număr de iteraţii cuprins între 1 şi 20, iar structura de control interioară conţine patru
structuri de control alternative simple, atunci numărul ramurilor logice din program care
trebuie testate va fi de 1014! Din acest motiv, activitatea de testare trebuie organizată în
mod riguros şi eficient.
În general, testarea implică elaborarea planurilor testelor, stabilirea standardelor testării,
precum şi încadrarea întregii activităţi de testare în ciclul de viaţă al sistemelor, în vederea
asigurării completitudinii planurilor de testare a programelor şi sistemului căruia aparţin.
Într-o formă schematică, principalele activităţi care formează procesul de testare sunt
evidenţiate în figura 5.2. P reprezintă obiectul supus testării, respectiv un modul de
program, specificaţiile procedurale sau întregul sistem.

subset al
datelor de Stabilirea rezultatele
intrare rezultatelor asteptate

P Strategia Compararea Rezultatele Documentatia
testarii rezultatelor testarii testarii

subset al P rezultatele
datelor de obtinute
intrare
Fig. 5.2 Schema generală a procesului de testare
(adaptare după van Vliet, H. – Software Engineering. Principles and Practicies,
John Wiley & Sons, LTD, Chichester, 2000, p. 401)

Prima activitate se referă la definirea strategiei, care are drept scop definirea setului
minim al datelor de test care să satisfacă cerinţele testării, cuantificate prin intermediul
criteriilor de acceptabilitate. De exemplu, criteriile de acceptabilitate pot fi exprimate
astfel: la testare se va urmări execuţia cel puţin o dată a tuturor instrucţiunilor din program;
prin testare se va urmări execuţia tuturor ramurilor logice din program etc. Evident că cele
două exemple nu sunt echivalente, întru-cât primul criteriu nu permite testarea ramurilor
vide.
După stabilirea criteriilor de acceptabilitate, se va trece la generarea setului de teste
care să răspundă acestor criterii, adică a unui subset al datelor de intrare în P. Această
activitate nu se desfăşoară la întâmplare, ci de-o manieră sistematică, apelând la diferitele
tehnici de testare pe care le avem la dispoziţie. În funcţie de tehnicile de testare alese se va
genera şi subsetul datelor de test.
Odată definit setul de teste, se va trece la determinarea rezultatelor aşteptate pentru
fiecare test în parte şi apoi la execuţia componentei P. În final, se realizează compararea
123

rezultatelor obţinute în urma execuţiei cu cele aşteptate, eventualele diferenţe semnalând
existenţa unor erori, ce vor fi transmise spre rezolvare proiectanţilor sau programatorilor
responsabili de componenta testată. Rezultatele testării vor fi consemnate într-o
documentaţie specială.
Există câteva principii generale care ghidează activitatea de testare a programelor:
1. Testele trebuie concepute astfel încât să urmărească respectarea cerinţelor
utilizatorilor. Cele mai numeroase erori sunt legate de nesatisfacerea cerinţelor
sistemului, identificate şi formulate în faza de analiză.
2. Testele trebuie planificate cu mult timp înainte de începerea activităţii de testare.
Toate testele trebuie planificate şi proiectate înainte de scrierea/ generarea
programelor sursă, chiar din timpul analizei sistemului odată ce modelul cerinţelor
sistemului este complet. Definirea detaliată a cazurilor de test poate începe încă din
timpul fazei de proiectare, odată cu întocmirea specificaţiilor de proiectare.
3. Testarea trebuie să înceapă cu detaliile, desfăşurată la nivelul modulelor
componente, iar, pe măsură ce ea progresează, atenţia va fi îndreptată spre
identificarea erorilor de integrare a acestor componente şi, în final, asupra
întregului sistem.
4. Testarea exhaustivă nu este posibilă. Numărul cazurilor de test, derivate din
combinarea tuturor situaţiilor posibile, este foarte mare chiar şi pentru programele
de dimensiuni mai mici. De aceea, este necesară utilizarea unor tehnici speciale de
definire a cazurilor de test care să corespundă criteriilor de acceptabilitate.
5. Pentru a fi eficientă, testarea trebuie să fie realizată de persoane care nu au fost
implicate în fazele anterioare de dezvoltare a sistemului. Chiar dacă acest principiu
nu trebuie interpretat în mod absolut, totuşi, de cele mai multe ori, persoanele
implicate în crearea sistemului nu sunt cele mai indicate în realizarea testării
programelor, cu excepţia aplicaţiilor de dimensiuni mai mici.
6. Testarea nu vizează numai produsul final, ci şi rezultatele fazelor intermediare ale
dezvoltării sistemului. Nu doar programele sunt supuse testării, ci şi cerinţele
informaţionale şi funcţionale ale sistemului (structurate în faza de analiză), soluţiile
generale de proiectare, specificaţiile detaliate de proiectare (întocmite în fazele
proiectării logice şi fizice), documentaţia sistemului etc. Cele mai grave erori sunt
cele derivate din identificarea incompletă sau formularea greşită a cerinţelor.
Insistăm asupra ultimului principiu prezentat, tocmai pentru că el este, adesea, ignorat
în practică, consecinţele fiind apariţia de costuri suplimentare. De aceea, una dintre
activităţile care trebuie realizată înainte de proiectarea şi implementarea sistemului priveşte
verificarea cerinţelor sistemului. Prin această activitate nu se urmăreşte a stabili dacă
cerinţele sunt corecte sau greşite, ci a determina dacă ele sunt complete. Altfel spus, se
stabileşte dacă27: cerinţele sunt detaliate suficient, astfel încât să permită proiectarea şi
implementarea lor; cerinţele nu intră în contradicţie unele cu altele.
Atingerea obiectivelor urmărite prin verificarea cerinţelor presupune utilizarea a două
metode de lucru: mai întâi se efectuează inspecţia cerinţelor, urmată de schiţarea planului
de testare. Inspecţia cerinţelor presupune efectuarea unor verificări simple asupra
documentului cerinţelor, întocmit la sfârşitul fazei de analiză, pentru a fi siguri că el
conţine suficiente detalii şi că nu există două cerinţe contradictorii. Acestă operaţiune
trebuie realizată de autorul documentului, împreună cu reprezentanţi ai echipelor de
proiectare, implementare şi testare.

27. Richard, L.K. – Testing Requirements, www.gantthead.com (accesat 18.01.2006).

După finalizarea inspecţiei cerinţelor, echipa de testare va întocmi o schiţă a planului
de testare, prin care se stabileşte cât de detaliat sunt formulate cerinţele. Dacă se constată
dificultăţi în elaborarea testelor pe baza documentaţiei, atunci este de aşteptat că nici
proiectanţii sau programatorii să nu poată implementa aceste cerinţe. În cel mai bun caz, ei
vor încerca să citescă printre rânduri şi să deducă propriile soluţii, care ar putea fi în
contradicţie cu aşteptările utilizatorilor.

9.2.2 Tehnici de testare

Tehnicile de testare au un caracter preponderent euristic şi empiric, mai puţin

fundamentate teoretic, ceea ce explică multitudinea tehnicilor prezentate în literatura de
specialitate. Importantă este alegerea unei strategii prin care să se selecteze tehnicile cele
mai adecvate pentru atingerea obiectivelor definite în faza de planificare a testării. Pentru a
fi în măsură de a alege cele mai potrivite tehnici de testare, este necesară cunoaşterea
modalităţilor de clasificare a lor.

9.2.2.1 Clasificarea tehnicilor de testare

În literatura de specialitate, tehnicile de testare sunt grupate după diverse criterii.

Mosley diferenţiază testele în funcţie de modul în care acestea angajează tehnici dinamice
sau statice, precum şi în funcţie de modul de efectuare, automat sau manual28.
Testarea statică înseamnă verificarea programelor sursă fără ca acestea să fie lansate
în execuţie. Multe din aceste tehnici sunt aplicate la testarea rezultatelor fazelor de analiză
şi proiectare sau a documentaţiei sistemului. Testarea dinamică implică execuţia
programelor. Pornind de la un set de date de intrare se va lansa în execuţie programul şi se
vor compara rezultatele execuţiei programului cu rezultatele scontate.
Testarea automată este efectuată sub controlul calculatorului, în timp ce testarea
manuală se desfăşoară sub controlul omului.
Cele două moduri de clasificare sunt relativ redundante, în sensul că majoritatea
tehnicilor de testare manuală se regăsesc şi în categoria tehnicilor de testare statică, atât
timp cât, în general, tehnicile manuale nu implică execuţia programelor29, iar tehnicile de
testare automată presupun de cele mai multe ori execuţia programelor, deci ele sunt
considerate tehnici de testare dinamică.
În mod tradiţional, există două abordări complementare în testarea programelor, în
funcţie de sursele de informaţii utilizate pentru generarea cazurilor de test. Celor două
abordări le corespund două categorii de tehnici de testare: tehnici tip „cutia neagră” sau
tehnici tip „cutia albă”.
Testarea tip „cutia neagră”, numită şi funcţională, nu ia în considerare detaliile
procedurale interne ale componentei testate, ci urmăreşte funcţiile acesteia. Se vor alege
date de test pentru fiecare funcţie în parte. În cazul unui modul de program, responsabilii
testării nu vor examina instrucţiunile acestuia, ei fiind interesaţi doar de datele de intrare şi
rezultatele aşteptate pentru fiecare funcţie a modulului.
Testarea tip „cutia albă”, numită şi structurală, presupune concentrarea atenţiei asupra
detaliilor procedurale ale componentei testate, pentru a putea determina cazurile de test şi
datele de intrare necesare. Ea implică identificarea cazurilor de test care permit execuţia
tuturor ramurilor programului, derivate din structurile de control alternative şi/sau

28. Mosley, D.J. – The Handbook of MIS Application Software Testing, Yourdon Press, Englewood Cliffs, New Jersey,
1993.
29. van Vliet, H. – Software Engineering. Princples and Practice, Second Edition, John Wiley & Sons, LTD, Chichester,
2002, p. 399.
125

repetitive. Prin urmare, se va defini câte un caz de test pentru fiecare ramură logică a
programului. Tehnica testării căilor de bază, ce va fi prezentată în paragraful următor, se
încadrează în această categorie.
Deoarece porneşte de la analiza structurilor de control din specificaţiile procedurale de
proiectare sau codul program, s-ar putea crea impresia că aplicarea aceste testări, tip „cutia
albă”, ar conduce inevitabil către obţinerea de programe 100% corecte şi că testarea de tip
„cutia neagră” ar fi inutilă. Ar putea fi adevărat dacă ar fi posibilă testarea exhaustivă a
programelor (reamintiţi-vă unul din principiile testării enunţate anterior).
Problema poate fi formulată şi din cealaltă perspectivă: de ce trebuie să cheltuim atâta
timp şi energie cu testarea la nivelul detaliilor programelor, în loc să ne concentrăm atenţia
asupra testelor care să vizeze fiecare funcţie a programelor? Aşadar, de ce să ne complicăm
cu testarea tip „cutia albă”, în loc să consumăm toate resursele cu testarea tip „cutia
neagră”?
Răspunsul la întrebarea anterioară derivă din natura erorilor întâlnite în programe.
Multe erori apar atunci când se proiectează şi implementează condiţii sau structuri de
control care privesc cazurile speciale ale funcţiei tratate şi care nu fac parte din fluxul logic
principal al programului. Se estimează că numărul erorilor logice este invers proporţional
cu probabilitatea de execuţie a unei ramuri logice a programului30. Erorile de scriere a
programelor sursă pot apărea oriunde în programe, atât în ramurile logice principale, cât şi
în cele care tratează cazurile speciale, ceea ce justifică necesitatea tehnicilor de testare de
tip „cutia albă”.
Pe de altă parte, aplicarea tehnicilor de testare de tip „cutia albă” permite identificarea
şi localizarea mai uşoară a erorilor, tocmai datorită faptului că acest tip de testare se
desfăşoară la nivelul detaliilor procedurale. Să ne imaginăm ce dificilă ar fi localizarea unei
erori identificate la testarea unei funcţii a sistemului ce presupune execuţia mai multor
module de program. În plus, noi ştim că rezultatele obţinute nu sunt corecte, dar ar putea fi
vorba de mai multe erori şi nu doar de una singură. Acesta este unul din motivele pentru
care strategia de testare trebuie definită astfel încât să se aplice mai întâi tehnicile de testare
tip „cutia albă” şi apoi cele tip „cutia neagră”.
De regulă, testarea tip „cutia albă” urmăreşte generarea cazurilor de test astfel încât:
execuţia fiecărei structuri de control alternative pe ambele ramuri;
execuţia fiecărei structuri de control repetitive, atât la numărul minim, cât şi cel
maxim al iteraţiilor, dar şi a unuia intermediar;
verificarea validităţii structurilor de date interne ale programelor.
Testarea de tip „cutia neagră” urmăreşte să răspundă la următoarele întrebări: Cum
poate fi testată validitatea funcţională a aplicaţiei? Cum pot fi testate performanţele
aplicaţiei? Ce volum de date şi ce rată a intrărilor poate accepta sistemul? Ce efect va avea
asupra modului de funcţionare a sistemului o anumită combinaţie a datelor de intrare?
În realizarea acestui tip de testare, un rol important îl au diagramele fluxurilor de date,
pe baza cărora se pot defini clasele de intrări care să permită testarea eficace a fiecărei
tranzacţii/transformări (în funcţie de orientarea sistemului) şi a fiecărui proces în realizarea
ei. Pornind de la diagramele fluxurilor de date, se poate realiza testarea pe baza unor
grafuri, în care nodurile reprezintă procesele necesare unei tranzacţii, iar legăturile
reprezintă conexiunile logice dintre acestea. În cazul sistemelor orientate pe transformări,

30. Jones, T.C. – Programming productivity: Issues for the 80s, IEEE Computer Society Press, 1981, citat în Presmann,
R.S. – op. cit., p. 433.

nodurile reprezintă datele, iar legăturile dintre noduri reprezintă transformările la care
acestea sunt supuse.
În concluzie, testarea tip „cutia neagră” şi cea tip „cutia albă” sunt complementare,
ambele trebuind să fie utilizate pentru o bună testare. De asemenea, de reţinut că nu există
o tehnică de testare sau o categorie de tehnici catalogată drept cea mai bună. Fiecare
tehnică este orientată spre detectarea anumitor tipuri de erori sau atingerii anumitor
obiective. Din acest motiv, se va apela la utilizarea mai multor tehnici, în funcţie de
obiectivele propuse, strategia de testare, complexitatea sistemului informatic, resursele
alocate etc.

9.2.2.2 Testarea structurilor de control repetitive.

Structurile repetitive stau la baza majorităţii algoritmilor implementaţi în programe.

Din punctul de vedere al testării, ele pot fi împărţite în trei categorii, prezentate în figura
5.3: simple, imbricate şi concatenate. Regulile de testare a structurilor repetitive se
încadrează în tehnicile tip „cutia albă”.

structuri structuri structuri
repetitive repetitive repetitive
simple imbricate concatenate
Fig. 5.3 Tipuri de structuri de control repetitive

În cazul structurilor repetitive simple, considerând n – numărul maxim de iteraţii,

trebuie realizate următoarele teste: nici o iteraţie (adică nici o trecere prin bucla respectivă),
o singură trecere, două treceri, m treceri (unde m<n), n-1, n, n+1 treceri.
Pentru structurile repetitive imbricate, numărul testelor posibile creşte în progresie
geometrică cu nivelul de imbricare. Reducerea numărului de teste se poate realiza astfel:
1. Se porneşte cu structura repetitivă de pe nivelul cel mai mare de imbricare (prima
din interior), configurându-se celelalte structuri la numărul minim de iteraţii. Pentru
această structură de control se realizează testele specifice structurii repetitive simple,
amintită anterior.
2. Se continuă testele specifice structurii repetitive simple, pentru testarea structurii de
control situate pe nivelul următor de imbricare, păstrându-se structurile de control
situate deasupra sa la numărul minim de iteraţii şi valorile tipice pentru cele situate
dedesubt.
3. Se continuă în aceeaşi manieră până când se testează toate structurile de control.
Structurile repetitive concatenate pot fi testate în maniera descrisă în cazul structurilor
simple, dacă fiecare structură de control este independentă de celelalte, sau asemănător
127

celor imbricate, dacă structurile de control nu sunt independente. Două structuri de control
concatenate nu sunt independente atunci când condiţiile conţinute de cele două structuri
sunt legate între ele. Aşa este cazul a două structuri de tip FOR, în care contorul primei
structuri de control este utilizat ca valoare iniţială pentru cea de-a doua structură.

9.2.2.3 Examinările şi execuţiile de probă

Ambele tehnici de testare sunt manuale, iar aplicarea lor presupune constituirea unor
echipe speciale care vor evalua programele şi specificaţiile procedurale în cadrul unor
sesiuni formale de lucru, urmându-se anumite proceduri clar definite.
Examinările presupun evaluarea programelor linie cu linie în vederea depistării
manuale a unor erori frecvent întâlnite, fără a se urmări efectul fiecărei instrucţiuni. De
aceea, este necesară întocmirea unei liste de control cu erorile tipice întâlnite în activităţile
de proiectare şi programare. Exemple de erori sunt:
Utilizarea greşită a structurilor de date: referirea unor variabile neiniţializate sau
chiar nedeclarate, depăşirea dimensiunii unui tablou de date etc;
Erori în expresiile de calcul: împărţirea la 0, utilizarea unor variabile de tipuri
diferite în aceeaşi expresie fără a se apela la funcţiile de conversie, nerespectarea
ordinii de prioritate a operatorilor, plasarea eronată a parantezelor, rotunjirea
zecimalelor şi nu truncherea şirului de cifre pentru partea fracţionară (în calcule
foarte exacte, cum sunt cele ştiinţifice sau pentru stabilirea mediilor în sistemele
educaţionale) etc;
Erori legate de fluxul logic de control: structuri de control repetitive infinite,
blocuri de instrucţiuni ce nu vor putea fi executate niciodată etc;
Erori la nivelul interfeţelor: utilizarea unui număr incorect de parametri sau a unor
parametri al căror tip nu este corespunzător etc.
În general, o echipă de examinare este formată din patru membri, fiecare cu roluri bine
definite. Moderatorul este responsabil pentru organizarea şedinţelor de lucru, le conduce,
asigură ca fiecare participant să urmeze procedurile stabilite astfel încât aceştia să lucreze
ca o echipă. Echipa mai conţine doi inspectori (examinatori) care vor interpreta programul
sursă. Din echipă va face parte şi programatorul, respectiv cel ce a scris codul (programul
sursă), deoarece acesta cunoaşte cel mai bine programul şi poate fi solicitat de inspectori să
explice ce a intenţionat să facă atunci când aceştia consideră că ceva este greşit, neclar sau
nu funcţionează corect.
Membrii echipei de examinare vor primi programele sursă, specificaţiile de proiectare
şi documentaţia asociată cu câteva zile înainte de desfăşurarea sesiunii de lucru. În timpul
şedinţelor de lucru, examinatorii vor interpreta liniile de program, mai multe linii deodată,
iar pe baza comentariilor şi întrebărilor formulate se vor descoperi eventualele greşeli. De
asemenea, programele vor fi analizate pe baza listei de control a erorilor tipice. Rezultatele
sesiunii de examinare vor fi consemnate într-o listă a problemelor identificate. Aceste
probleme nu vor fi rezolvate în cadrul şedinţelor de examinare pentru a nu distrage atenţia
membrilor echipei de la obiectivul principal, respectiv identificarea erorilor. Lista cu
problemele identificate va fi înmânată pentru rezolvare programatorilor care au scris codul.
Execuţia de probă, spre deosebire de examinări, presupune analiza programelor prin
urmărirea efectului fiecărei instrucţiuni pe baza unor date de test. Datele de test alese sunt
de cele mai multe ori simple, astfel încât să nu facă dificilă urmărirea programului. De fapt,
datele de test vor servi mai mult drept punct de pornire a discuţiilor decât unei testări
riguroase. Pe parcursul sesiunii de lucru, proiectantul poate fi solicitat să argumenteze şi să
explice deciziile sale.
Ambele tehnici de testare pot fi aplicate în cadrul tuturor fazelor de dezvoltare a

sistemului informatic, şi nu doar în faza de implementare, cu condiţia existenţei unei
documentaţii clare.
În afară de numărul mare de erori descoperite prin urmărirea atentă a programelor
(după unele estimări între 60% şi 90%)31, ambele tehnici prezintă şi alte avantaje:
promovarea spiritului de echipă; membrii unei echipe pot învăţa unii de la alţii şi pot
acumula cunoştinţe noi privind tehnicile şi stilurile de programare, erorile tipice care pot să
apară la scrierea programelor etc.

TA 9.1
1. Care sunt principalele activităţi ale etapei de implementare?
2. Redaţi schematic activităţile procesului de testare.
3. Descrieţi succint caracteristicile testării de tip „cutia neagră”.
Răspuns:

9.2.3 Strategia testării sistemelor informatice

Testarea presupune un grup de activităţi care trebuie planificate din timp şi realizate în
mod sistematic. În acest sens, este necesară definirea unui cadru de desfăşurare a fazei de
testare, ca parte a demersului dezvoltării sistemelor informatice. Acest cadru se
concretizează în strategia testării. Strategia testării sistemelor informatice integrează
diferitele metode de concepere a cazurilor de test, într-o succesiune de paşi bine planificaţi,
astfel încât să fie asigurată dezvoltarea unui sistem informatic de calitate.
Orice strategie de testare trebuie să aibă următoarele caracteristici generale:
1. Testarea începe de jos, de la nivelul modulelor, şi se încheie prin validarea sistemului
informatic ca un tot. În faza de proiectare, sistemul este descompus în mai multe
module organizate ierarhic, obţinându-se arhitectura sistemului, pe baza căreia se va
realiza şi faza de testare. Se va începe cu testarea modulelor, după care se va viza
maniera de integrare a acestora, conform arhitecturii definite în faza de proiectare,
numită testarea integrării. După testarea integrării, urmează testarea sistemului,

31. Oprea, D. – Analiza şi proiectarea sistemelor informaţionale economice, Editura Polirom, Iaşi 1999, p. 481.
129

moment în care programele şi alte elemente componente ale sistemului sunt testate ca
un tot, în funcţie de cerinţele funcţionale şi restricţiile definite în faza de analiză. Se
încheie cu testarea de acceptare, prin implicarea directă a utilizatorilor. Cele patru
etape vor fi prezentate succint în paragrafele următoare.
2. Diferitele tehnici de testare trebuie aplicate în anumite momente ale testării. Dacă la
testarea modulelor se utilizează cu precădere tehnicile tip „cutia albă”, în timpul
testării integrării vor fi utilizate mai mult tehnicile tip „cutia neagră”. Testarea
sistemului şi testarea de acceptare implică aproape în exclusivitate apelarea la testarea
tip „cutia neagră”, urmărindu-se verificarea funcţionalităţii, comportamentului şi
performanţelor sistemului, precum şi dacă sistemul corespunde exigenţelor
utilizatorilor.
3. Testarea este realizată de către o echipă independentă, în cazul proiectelor mari sau
de membrii echipei de dezvoltare a sistemului, în cazul proiectelor de mai mică
amploare. Pentru orice proiect de dezvoltare a sistemelor informatice, faza de testare
implică anumite conflicte de interese inerente. Pe de o parte, pare evident că cei mai
potriviţi, pentru a realiza testarea, sunt proiectanţii şi programatorii, adică cei care
cunosc cel mai bine sistemul. Pe de altă parte, aceştia vor încerca să demonstreze că
programele nu conţin erori, iar prin testele proiectate vor demonstra că sistemul
funcţionează conform cu cerinţele formulate.
În general, proiectanţii şi programatorii sunt responsabili atât pentru testarea modulelor,
cât şi pentru testarea integrării modulelor, iar ultimele două etape vor fi realizate de o echipă
independentă.

9.2.3.1 Testarea modulelor

Scopul principal urmărit prin testarea la nivelul modulelor constă în identificarea şi

corectarea unui număr cât mai mare de erori, înainte de integrarea modulelor în unităţi de
program mai complexe, în care erorile sunt mult mai greu de localizat şi corectat.
În acest moment al testării sunt implicate mai multe tehnici de testare, în funcţie de
aspectele urmărite. De regulă, se începe cu testarea la nivelul interfeţelor modulului,
pentru a se asigura că intrările şi ieşirile în/din modul sunt corecte, înainte de a se efectua
alte teste asupra modulului. Urmează testarea structurilor de date locale, prin care se
verifică integritatea datelor memorate temporar de-a lungul ramurilor de execuţie din
modulul respectiv.
Cele mai importante teste, dintre cele efectuate la nivelul modulelor, sunt cele care
vizează căile de execuţie a programului. Prin testarea căilor de execuţie se urmăreşte
depistarea erorilor legate de calcule greşite, comparaţii greşite în expresiile logice, controlul
logic necorespunzător al execuţiei etc. Foarte utile, în acest scop, sunt tehnica testării căilor
de bază şi testarea structurilor de control repetitive. Testarea modulelor se încheie cu
analiza valorilor limită. Deşi sunt puţine explicaţii, majoritatea erorilor apar la
extremităţile domeniului de valori pentru datele de intrare şi nu în mijlocul acestui domeniu.
De exemplu, apar erori la execuţie, atunci când se invocă ultima iteraţie dintr-o structură
repetitivă, se prelucrează ultimului element dintr-un tablou de date etc. Din acest motiv, se
impune reluarea testelor privind structurile de date şi fluxul logic de control, însă vor fi
utilizate alte cazuri de test, prin care se va urmări exersarea valorilor limită ale domeniului.
Testarea modulelor mai are o particularitate. După cum se ştie, un modul nu este de
sine-stătător, el fiind plasat undeva în structura ierarhică a programului, de unde este apelat
de modulele de pe nivelul ierarhic superior, după cum, la rândul său, poate apela unele
module situate pe nivelul ierarhic inferior, pentru a-şi putea realiza funcţia. În aceste
condiţii, aplicarea tehnicilor de testare dinamică este de cele mai multe ori imposibilă.
Pentru a se evita acest neajuns, pentru fiecare modul testat, se vor concepe două tipuri
speciale de module: module subordonate (stub module) şi module director (drive module).
Un modul director este văzut ca un program principal al cărui rol constă în a simula
condiţiile normale de exploatare a programului în care va fi executat modulul testat.
Funcţiile lui privesc acceptarea datelor de test, transmiterea lor către modulul ce trebuie
testat şi afişarea rezultatelor relevante ale testării. Un modul subordonat are rolul de a
înlocui un modul invocat de modulul testat, el fiind un subprogram care va avea aceeaşi
interfaţă ca şi modulul pe care-l înlocuieşte, va realiza un minim de prelucrări, va semnala
faptul că el a fost apelat, după care va reda controlul modulului testat.
Testarea modulelor este simplificată, cu atât mai mult, cu cât coeziunea lor este mai
mare. Dacă un modul este caracterizat de o coeziune funcţională, deci el a fost proiectat să
realizeze o singură funcţie, atunci numărul testelor necesare este mai redus, iar erorile pot fi
mai uşor descoperite.

9.2.3.2 Testarea integrării

Ajunşi în această etapă, unii s-ar putea întreba: De ce mai este necesară testarea
integrării modulelor, atât timp cât fiecare modul a fost testat individual şi se presupune că
ele funcţionează ireproşabil? Răspunsul este cât se poate de simplu: pentru că pot apărea
alte erori, care nu pot fi depistate prin testarea la nivelul modulelor. Anumite date se pot
pierde, prin transmiterea lor de la un modul la altul, sau execuţia unui modul poate avea
efecte negative asupra altui modul. De asemenea, integrarea subfuncţiilor realizate de
diferite module poate să nu ducă la obţinerea funcţiei dorite sau se pot ivi unele probleme
la utilizarea structurilor de date globale. Lista ar putea continua.
Integrarea modulelor se poate face treptat, modul cu modul, sau deodată. Strategia
integrării treptate presupune construirea şi testarea programului în paşi mici, astfel încât
erorile să fie uşor de localizat şi corectat, interfeţele să fie cât mai complet testate, iar
întreaga activitate de testare a integrării modulelor să fie desfăşurată de o manieră
sistematică. În opoziţie cu această strategie, integrarea deodată a modulelor presupune
construirea programului prin integrarea modulelor componente urmată de testarea
programului ca un tot. Această strategie nu este recomandată deoarece face dificilă
localizarea şi corectarea erorilor.
Testarea integrării se poate face atât de sus în jos (top-down) , cât şi de jos în sus
(bottom-up). Integrarea şi testarea modulelor de sus în jos (top-down) începe cu modulul
principal, după care se continuă, prin parcurgerea în jos a structurii ierarhice a programului,
în două modalităţi posibile: integrarea orientată pe verticală sau integrarea orientată pe
orizontală.
Integrarea orientată pe verticală presupune integrarea tuturor modulelor componente
pe câte o ramură a structurii ierarhice. Integrarea orientată pe orizontală presupune
reunirea mai întâi a modulelor situate pe nivelul ierarhic imediat inferior modulului
principal şi se continuă cu fiecare nivel ierarhic.
Aplicarea integrării top-down impune utilizarea modulelor subordonate. Se începe prin
testarea modulului principal, considerat ca modul director, iar modulele de pe nivelul
ierarhic inferior vor fi înlocuite cu module subordonate. Acestea din urmă vor fi eliminate
şi înlocuite cu modulele reale, pe măsură ce se înaintează cu testarea
După cum sugerează şi numele, testarea integrării de-jos-în-sus presupune construirea
şi testarea treptată a programului, începând cu modulele de pe ultimele niveluri ierarhice.
131

În acest caz, se va apela la înlocuirea modulelor de program cu module director. Această
abordare se desfăşoară după următorul scenariu: modulele situate pe ultimele niveluri
ierarhice sunt grupate astfel încât fiecare grup de module să realizeze o subfuncţie a
programului; apoi se creează câte un modul director pentru fiecare grup de module şi pe
baza căruia se va testa fiecare grup în parte; după ce testarea fiecărui grup de module s-a
încheiat, se elimină modulele director şi se regrupează modulele prin înglobarea celor
situate pe nivelul imediat superior. Acest proces va fi reluat până la construirea şi testarea
întregului program.
În practică, cele două abordări sunt utilizate împreună, fiecare prezentând avantaje şi
dezavantaje specifice. Principalul beneficiu obţinut poate consta în reducerea numărului de
module director şi subordonate care trebuie create.

9.2.3.3 Testarea la nivelul sistemului

Deşi testarea la nivelul sistemului poate părea similară cu testarea integrării, ea diferă
prin orientarea testelor spre acele caracteristici nespecifice componentelor programului,
cum ar fi: performanţele sistemului, securitatea, refacerea în cazul apariţiei unor căderi ale
sistemului etc. De asemenea, testarea sistemului diferă de testele anterioare prin luarea în
considerare şi a celorlalte componente ale sistemului, în afară de programe. Aceste teste
vor verifica dacă elementele componente ale sistemului – hardware, software, oameni şi
date - sunt integrate corespunzător şi realizează funcţiile prevăzute.
Testele concepute în această fază pot fi împărţite în patru categorii, în funcţie de
scopul urmărit32:
Testarea refacerii urmăreşte să forţeze căderea sistemului din diferite cauze şi să
verifice dacă refacerea este realizată corespunzător. Dacă refacerea este realizată
automat de către sistemul însuşi, vor fi verificate reiniţializarea sistemului,
refacerea datelor şi alte aspecte. Dacă refacerea implică intervenţia beneficiarului,
va fi evaluată perioada de timp necesară pentru repunerea sistemului în funcţiune.
Testarea securităţii urmăreşte să verifice dacă mecanismele de protecţie ale
sistemului funcţionează corespunzător împotriva încercărilor de atac asupra
sistemului sau a accesării neautorizate.
Testarea solicitării sistemului presupune confruntarea sistemului cu situaţii
anormale, testele anterioare vizând modul de funcţionare a programelor în condiţii
normale de lucru. Prin testele concepute, execuţia programelor va solicita resurse în
cantităţi, volume sau frecvenţe anormale. De exemplu, pot fi concepute teste pentru
situaţiile în care volumul şi rata datelor de intrare creşte de un anumit număr de ori
faţă de situaţiile normale, teste în care timpul de căutare şi citire a datelor de pe disc
este foarte mare etc.
Testarea performanţelor sistemului este adesea combinată cu testarea solicitării
sistemului şi ia în considerare performanţele tehnice ale hardware-ului şi software-
ului.
În principiu, testarea sistemului va include toate activităţile specifice testării de
acceptare, însă va fi realizată fără implicarea utilizatorilor. Astfel, se oferă ocazia ultimelor
verificări şi modificări înainte de prezentarea sistemului în faţa beneficiarului.

32. Presmann, R.S. – op. cit., pp. 483-485.

9.2.3.4 Testarea de acceptare

Testarea de acceptare reprezintă ultima ocazie de verificare a sistemului, înainte de a fi

dat în exploatare. Spre deosebire de testele anterioare, testarea de acceptare trebuie să se
desfăşoare într-un mediu similar celui în care va fi pus în funcţiune şi de către persoanele
care îl vor utiliza. Ea este realizată din perspectiva utilizatorului, ceea ce înseamnă că, prin
testele concepute, vor fi exersate funcţiile aplicaţiei orientate spre utilizator.
Testarea de acceptare trebuie planificată încă din primele faze ale dezvoltării
sistemului, începând cu analiza. Dacă planificarea testării de acceptare începe din faza de
analiză, atunci, în paralel cu definirea cerinţelor sistemului, se va stabili şi modul în care
fiecare cerinţă poate fi testată cât mai bine. Mai mult, dacă o anumită cerinţă este dificil de
testat şi de întreţinut, atunci utilizatorului i se pot oferi unele explicaţii care să-l determine
să renunţe la acea cerinţă.
Testarea de acceptare presupune, de regulă, două etape: testarea alfa şi testarea beta.
Testarea alfa este realizată de client la sediul producătorului, sub supravegherea
specialiştilor din echipa de dezvoltare a sistemului, şi sunt utilizate date nereale, dar
reprezentative. În schimb, testarea beta se desfăşoară la sediul clientului, fără ca utilizatorii
să mai fie supravegheaţi de membrii echipei de dezvoltare a sistemului, utilizându-se date
reale. De fapt, testarea beta reprezintă un fel de repetiţie generală înaintea exploatării
propriu-zise a sistemului.

TA 9.2
1. Prezentaţi succint caracteristicile generale ale unei strategii de testare.
2. Prin ce se diferenţiază testarea alfa de testarea beta?
Răspuns:


TA 9.1 1) Planificarea implementării, realizarea şi testarea programelor, pregătirea
locurilor de muncă, instruirea personalului, finalizarea documentaţiei, testarea sistemului,
conversia sistemului. 2) Vezi fig. 5.2 3) Ia în considerare funcţiile componentei testate, nu
detaliile procedurale interne; sunt examinate datele de intrare şi rezultatele aşteptate pentru
133

fiecare funcţie a modulului testat; urmăreşte validitatea funcţională şi performanţele
aplicaţiei; pot fi utilizate diagramele fluxurilor de date.
TA 9.2 1) Vezi p. XXX. 2) Realizată la sediul producătorului / clientului; sub
supravegherea specialiştilor / fără ca utilizatorii să fie supravegheaţi; sunt utilizate date
nereale, dar reprezentative / date reale.



1) Care dintre următoarele principii generale trebuie să ghideze activitatea de testare:
a) testarea trebuie să înceapă la nivelul întregului sistem şi se finalizează la nivelul
modulelor de program
b) testarea vizează şi rezultatele fazelor intermediare ale dezvoltării sistemului, nu doar
produsul final
c) testarea trebuie realizată de către prsoanele implicate în fazele anterioare de dezvoltare a
sistemului, deoarece ele cunosc cel mai bine sistemul
d) testele trebuie planificate cu mult timp timp înainte de începerea activităţii de testare

2) Care tip de testare se aplică mai întâi:
a) "cutia neagră"
b) nu are importanţă, de vreme ce cele două tipuri de testare sunt considerate
complementare
c) "cutia albă"

3) În cazul structurilor de control repetitive simple, în care "n" este numărul maxim de iteraţii,
trebuie realizate următoarele teste:
a) două iteraţii
b) trei iteraţii
c) nicio interaţie
d) n iteraţii
e) n+1 iteraţii
f) o iteraţie

1. Comentaţi următoarea afirmaţie: Tehnicile de testare tip „cutia albă” şi cele tip „cutia
neagră” sunt complementare.
2. Prezentaţi patru categorii de erori care pot fi urmărite în cadrul examinărilor.
3. Care este scopul testării integrării modulelor?

9.5 Bibliografie

Universităţii “Al. I. Cuza” Iaşi, 2006, pp. 215-225, 298-321
2. Presmann, R.S. – Software Engineering. A practitioner’s Approach, McGraw Hill
Publishing Company, London, 2000, p. 416-444


Implementarea sistemului. Documentarea şi conversia
sistemului

Obiective:
Înţelegerea conţinutului şi a modului de elaborare a documentaţiei utilizatorului
Cunoaşterea modalităţilor de organizare a instruirii în funcţie de participanţi, persoanele
care asigură instruirea, locul de desfăşurare şi forma de derulare
Descrierea metodelor de conversie a vechiului sistem la noul sistem
Elaborarea documentaţiei utilizatorului
Organizarea activităţilor de instruire a utilizatorilor
Alegerea tipului de conversie a sistemului în funcţie de caracteristicile acestuia

10.1 Documentarea sistemului ................................................................................................... 134
10.1.1 Consideraţii generale privind documentarea sistemului ............................................. 135
10.1.2 Documentaţia utilizatorului......................................................................................... 137
10.2 Selectarea şi instruirea personalului .................................................................................. 140
10.2.1 Participanţii la instruire............................................................................................... 140
10.2.2 Organizarea activităţilor de instruire .......................................................................... 141
10.3 Conversia sistemului .......................................................................................................... 144
10.5 Lucrare de verificare .......................................................................................................... 146
10.6 Bibliografie ........................................................................................................................ 146
Bibliografie ................................................................................................................................ 147

10.1 Documentarea sistemului

Documentaţia sistemului informaţional reprezintă un element de comunicare, control
şi monitorizare a proiectului de dezvoltare, exploatare şi întreţinere. În acelaşi timp,
documentaţia trebui privită şi ca unul dintre rezultatele etapelor ciclului de viaţă al
sistemului, regăsind în structura sa: documentaţia microanalizei, specificaţiile de analiză,
documentaţia proiectării şi implementării, manualul de utilizare şi operare. Ca urmare,
documentaţia sistemului este importantă, atât din punct de vedere al managementului
proiectelor, cât şi al dezvoltării şi utilizării lui. Cel mai adesea, din nefericire, în practică,
documentaţia fie este incompletă, fie lipseşte în totalitate.
Nu de puţine ori auzim în rândul specialiştilor sistemelor informaţionale afirmaţii de
genul: „nu putem modifica programul, pentru că nu ştim cum a fost gândit”, „nu putem
interveni pe schema bazei de date, pentru că nu este clar modul în care a fost proiectată”,
„nu putem include un nou modul în aplicaţie, pentru că nu există nimic legat de structurarea
aplicaţiei” etc. Astfel de situaţii apar când sistemul aflat în exploatare necesită modificări
sau îmbunătăţiri, dificil de efectuat, luându-se, în majoritatea cazurilor, decizia de a se
iniţia un nou proiect de dezvoltare, ştiindu-se că e mult mai uşor să faci ceva de la început
decât să modifici ceva existent. Dar, care este motivul pentru care se trece, în contextul
prezentat, la dezvoltarea unui nou sistem? Unul din răspunsuri îl constituie documentaţia,
în sensul că fie nu există, fie este incompletă sau neactualizată, şi, ca atare,
135

nu poate fi folosită în procesul de întreţinere a sistemului. Mai mult, documentaţia
sistemului se poate transforma într-un factor de eşec al proiectelor, având în vedere că
trecerea de la o etapă la alta, în cadrul ciclului de dezvoltare, are loc pe baza informaţiilor
colectate în cadrul specificaţiilor elaborate la sfârşitul fiecărei etape, ca un rezultat parţial al
proiectului.
Documentaţia este privită, deseori, numai din perspectiva existenţei unui volum
suplimentar de informaţii la dispoziţia organizaţiei şi a echipei proiectului, care, după
părerea unora, îngreunează şi prelungeşte derularea unui proiect. Această opinie ar putea fi
acceptată dacă se are în vedere viteza şi stringenţa cu care se solicită modificarea sau
înlocuirea sistemelor. Însă, o astfel de poziţie poate să aibă, pe termen lung, un efect destul
de costisitor.

10.1.1 Consideraţii generale privind documentarea sistemului

Documentaţia unui proiect reprezintă atât un instrument de înregistrare a diferitelor

decizii şi acţiuni pe care le implică ciclul de viaţă al unui proiect, cât şi mijlocul prin care
se documentează şi justifică deciziile şi acţiunile. Crearea documentelor poate să ajute
echipa proiectului în desfăşurarea activităţilor şi atingerea obiectivelor stabilite,
reprezentând suportul pentru obţinerea aprobărilor necesare desfăşurării etapelor, alocării
resurselor, efectuării controlului din partea managerului de proiect sau a finanţatorului.
Aşadar, orice proiect, deci şi cel de dezvoltare a unui sistem informaţional, are la bază
o documentaţie, constituită dintr-o serie de documente, elaborată pe parcursul ciclului de
viaţă al proiectului. Fiecare etapă a proiectului, în mod normal, ar trebui să se finalizeze cu
un set de documente, folosit ca punct de plecare în luarea deciziilor de continuare a
proiectului, a modului în care se vor desfăşura activităţile specifice fazelor următoare,
precum şi a măsurilor necesare pentru încadrarea în timp şi buget, dacă se constată o
depăşire a acestora, sau de modificare a specificaţiilor iniţiale ale proiectului. Cu alte
cuvinte, documentaţia fiecărei etape permite, pe de o parte, realizarea monitorizării şi
controlului proiectului, iar, pe de altă parte, derularea etapelor prevăzute în planul iniţial.
Documentaţia proiectului poate fi structurată, în funcţie de etapa din proiect la care se
face referire, şi anume33:
Pentru etapa de concepere a planului proiectului specific este, după cum arată şi
numele, planul proiectului – document oficial, aprobat şi folosit pentru gestiunea şi
controlul execuţiei proiectului, fiind o colecţie de documente ce pot fi schimbate în timp,
pe măsură ce se obţin mai multe informaţii. Planul proiectului are o structură destul de
elaborată, fiind elementul esenţial în conducerea proiectului. Alături de planul proiectului,
în urma conceperii lui, se mai obţin şi alte detalii ajutătoare, care cuprind: documentaţia
obţinută pe parcursul conceperii proiectului (de exemplu, ipoteze ce nu au fost prevăzute
anterior); specificaţii şi proiecte tehnice, dacă sunt necesare; documentaţia pentru
standardele folosite în aprecierea calităţii proiectului.
În cadrul etapei de execuţie a proiectului se vor genera numeroase rapoarte, care scot
în evidenţă modul în care au fost parcurse activităţile, cum au fost respectate standardele de
calitate impuse, încadrarea în buget şi timp, cererile de efectuare a schimbărilor la nivel de
proiect, autorizările necesare pentru efectuarea lucrărilor etc. La acestea se adaugă toate
formularele şi documentele utilizate pentru evidenţa alocării şi utilizării resurselor, a
rezultatelor obţinute, pentru urmărirea contractelor etc.

33. Oprea, D. – Managementul proiectelor. Teorie şi cazuri practice, Editura Sedcom Libris, Iaşi, 2001, pp. 105-109.

Pentru etapa de control al schimbărilor, ca documente, sunt specifice planul
proiectului actualizat şi prognozele privind viitorul proiectului.
În cadrul închiderii proiectului apar ultimele reglări contractuale, inclusiv decizii
pentru unele probleme care au rămas nerezolvate, precum şi raportul de finalizare a
proiectului, ce conţine o prezentare sintetică a modului de desfăşurare a proiectului, a
modificărilor ce au apărut pe parcurs, a rezultatelor obţinute.
Conţinutul documentaţiei proiectului diferă şi în funcţie de categoriile de persoane
implicate, după cum urmează34:
la nivelul comitetului de aprobare sau a finanţatorului proiectului ar trebui să se
regăsească propunerea de proiect, cu justificarea necesităţii lui, studiul de
fezabilitate, planul proiectului, rapoartele privind evoluţia proiectului;
pentru beneficiarul rezultatelor proiectului apar ca necesare analiza cost/beneficiu,
schiţa şi planul proiectului, documentaţia privind modul de utilizare a rezultatelor;
pentru echipa proiectului sunt necesare următoarele piese din documentaţie: planul
proiectului, documentele de justificare a resurselor folosite, rapoartele privind
evoluţia proiectului, documentaţia obţinerii rezultatelor prevăzute prin proiect,
contractele cu furnizorii sau firmele de consultanţă, cererile aprobate de modificare
a anumitor aspecte din planul de bază etc.
Documentaţia sistemului este un produs/rezultat al derulării unui proiect, al cărui scop
este de a comunica informaţiile despre proiect şi sistem tuturor celor interesaţi, de la
finanţatori, utilizatori, specialişti şi până la conducerea organizaţiei unde se va implementa
noul sistem.
Cu toate că există similitudini între documentaţia proiectului şi documentaţia
sistemului informaţional, este necesar să se facă distincţie între ele, chiar dacă cea din urmă
face parte integrantă din prima.
Şi în cazul documentaţiei sistemului informaţional, se poate apela la cele două criterii
de clasificare, respectiv etapele care se desfăşoară pentru construirea lui şi categoriile de
persoane care solicită sau cărora trebuie să li se transmită diferite informaţii despre stadiul
de dezvoltare.
După etapele ciclului de viaţă al sistemului, putem identifica35:
1. documentaţia microanalizei de sistem, care conţine un set de documente, obţinute
în timpul iniţierii proiectului sau existente deja, dintre care mai importante sunt:
planul strategic de dezvoltare a sistemului la nivelul organizaţiei, cererea de
dezvoltare a sistemului, rapoartele de prefezabilitate şi fezabilitate, planul detaliat al
proiectului iniţiat, planificarea calendaristică a proiectului, planul şi procedurile
manageriale şi de comunicare, planul resurselor, bugetul preliminar al proiectului;
2. specificaţiile sau documentaţia de analiză, reprezentând o formalizare a rezultatelor
obţinute în această fază. Scopul său îl constituie comunicarea rezultatelor celor
interesaţi, servind şi ca reper pentru etapele următoare, în primul rând pentru cea de
proiectare. Ca urmare, o descriere foarte precisă, chiar matematică, 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 şi înţeles;

34. *** – Project Management – Guidelines, www.projectmanagement.tas.gov.au (accesat 06.07.2004).
35. Oprea, D., Meşniţă, G. – „Documentaţia sistemelor informaţionale – problemă a managementului proiectelor?”, în
vol. Societatea informaţională: Educaţie, Cercetare, Sisteme informaţionale, Tehnologii Informaţionale, Editura
ETP Tehnopress, Iaşi, 2004, pp. 110-111.
137

3. documentaţia de proiectare, prin care se detaliază modul de dezvoltare a sistemului
pentru a răspunde cerinţelor din specificaţiile de analiză. În setul de documente ale
acestei etape, ar trebui să se regăsească descrierea sau modelul tuturor intrărilor şi
ieşirilor sistemului, proceselor de prelucrare, interfeţelor-utilizator. Este indicat să
fie incluse, ori de câte ori este posibil, exemple de ecrane/formulare pentru preluarea
datelor, proceduri de control sau de interacţiune a utilizatorului cu sistemul. De
asemenea, sunt prezentate elementele privind modul de organizare a modulelor
programelor şi aplicaţiilor, a procedurilor de control şi asigurare a securităţii
aplicaţiilor şi datelor, structurarea bazei de date, procedurile de prelucrare distribuită
etc. Multe dintre componentele documentaţiei de proiectare sunt necesare
specialiştilor ce vor participa la desfăşurarea următoarei etape, având un pronunţat
caracter tehnic, dar ele se adresează şi utilizatorilor, pentru că pot ajuta la
demonstrarea facilităţilor oferite de sistem şi a modului în care se poate interacţiona
cu el;
4. documentaţia implementării, în care sunt cuprinse elementele specifice planificării
implementării, comentariile privind generarea codului programelor, tipurile de
testări şi rezultatele testelor, procedurile de conversie a sistemului etc. Tot acum se
dezvoltă şi documentaţia utilizatorului şi documentaţia tehnică a sistemului.
Din perspectiva participanţilor la proiectul de dezvoltare a sistemului, identificăm
două mari categorii de specificaţii :
1. documentaţia utilizatorului, care cuprinde documentele necesare stabilirii cerinţelor
sistemului şi pentru aprobarea diferitelor prototipuri sau specificaţii de proiectare,
precum şi manualul de utilizare. Prin manualul de utilizare sunt descrise principalele
elemente privind funcţionarea sistemului, modul în care se poate interacţiona cu el,
particularităţile fiecărui modul al aplicaţiei, apelarea la sistemul de ajutor, modul
de corectare a eventualelor erori, nivelurile de acces acordate diferitelor categorii de
utilizatori etc;
2. documentaţia tehnică a sistemului, în care sunt incluse manualul de prezentare
adresat conducerii, din care trebuie să rezulte imaginea generală a sistemului,
însoţită de o descriere succintă a fiecărei componente funcţionale, precum şi
manualul de operare. În manualul de operare sunt prezentate condiţiile de exploatare
a sistemului, pe baza cărora se poate intervine pentru eliminarea eventualelor erori
nedepistate în timpul testării sistemului, adăugarea unor componente noi sau
îmbunătăţirea celor existente.

10.1.2 Documentaţia utilizatorului

Prin documentaţia utilizatorului se asigură suportul permanent al celor care vor

exploata sistemul, având drept scop să prezinte, într-o formă structurată şi detaliată,
descrieri ale modului în care vor interacţiona cu sistemul. Ea trebuie să conţină, în primul
rând, procedurile de introducere a datelor, crearea şi generarea ieşirilor, modul de rezolvare
a problemelor elementare care ar putea să apară în utilizarea sistemului.
Pentru a fi uşor de folosit, documentaţia utilizatorului trebuie să includă un cuprins, o
decriere generală a scopului şi funcţiilor sistemului, descrierea procedurilor, un glosar de
termeni şi un index, după cum urmează:

1. Prezentarea generală a sistemului:
scopul sistemului;
prezentarea sumară, sub formă narativă şi grafică, a intrărilor, prelucrărilor şi
ieşirilor.
2. Procedurile generale
accesarea sistemului şi părăsirea lui;
instrucţiuni de operare (tastele funcţionale, combinaţiile de taste, utilizarea
mouse-ului, secvenţa comenzilor pentru executarea anumitei funcţii);
proceduri pentru încărcarea şi execuţia programelor;
lista controalelor şi descrierea lor;
explicaţii privind mesajele de eroare comune şi modul lor de corectare;
persoana de contact pentru eventualele probleme apărute în sistem.
3. Documentaţia procedurilor:
a. Prezentarea generală a fiecărei proceduri:
descrierea sumară;
diagrama fluxurilor de date.
b. Descrierea detaliată a fiecărei proceduri:
descrierea narativă şi grafică a procedurii (de exemplu, paşii care ar trebui
urmaţi pentru introducerea datelor de pe o comandă primită de la un client
nou);
descrierea fluxului de activităţi;
modele de ecrane şi explicarea opţiunilor ce apar pe fiecare ecran (de exemplu,
adăugarea, ştergerea, modificarea unui document);
descrierea sursei documentelor şi instrucţiunile de introducere a datelor de
intrare;
descrierea ieşirilor şi prezentarea unui model al fiecărei ieşiri, cu explicaţii şi
instrucţiuni privind modul de obţinere şi distribuire a fiecărei ieşiri.
c. Definirea datelor:
descrierea datelor utilizate de fiecare procedură;
proprietatea şi responsabilitatea asupra datelor;
explicaţii privind securitatea accesului la date.
d. Interfeţele cu proceduri sau sisteme
datele primite de alte proceduri sau grupuri de utilizatori
informaţiile ce trebuie oferite altor proceduri sau grupuri de utilizatori.
4. Glosarul de termeni
5. Indexul
Deşi, cei mai mulţi dintre utilizatori încă lucrează într-o lume bazată pe hârtie,
dezvoltarea şi oferirea unei documentaţii on-line prezintă câteva avantaje importante.
Caracteristica cea mai importantă a unei astfel de documentaţii o constituie abilitatea de a
apela la ajutorul contextual. Acest concept oferă utilizatorilor informaţii de ajutor pe
subiecte legate de acţiunea pe care o execută în momentul în care activează funcţia Help.
De exemplu, atunci când utilizatorul execută o funcţie mai complexă, este mult mai eficient
pentru el să i se ofere informaţii ajutătoare exact pentru acea funcţie, decât să caute în toată
documentaţia sistemului. Un exemplu de ajutor contextual este redat în figura 5.4, pe baza
funcţiei Help din Excel.
139

ajutor
contextual

Fig. 5.4 Exemplu de ajutor contextual pentru funcţia SUM din Excel

Pregătirea documentaţiei finale a utilizatorului presupune descompunerea problemelor

şi funcţiilor de ajutor în trei mari categorii: manualul de utilizare, ghidul general şi
tutorialele.
Manualul de utilizare se concentrează spre oferirea de asistenţă în cazul realizării unei
anumite funcţii sau instrucţiuni, cum ar fi generarea unui anumit raport. Informaţiile sunt
organizate pe funcţii şi instrucţiuni (de exemplu, meniul principal şi opţiunile lui), indicând
secvenţa paşilor pe care trebuie să-i parcurgă utilizatorul pentru realizarea activităţii. În
funcţie de complexitatea sistemului, această secţiune poate fi destul de detaliată şi
voluminoasă.
Ghidul general este mai puţin complex şi de o dimensiune mai mică, urmărind să ofere
utilizatorilor un ajutor rapid pentru anumite sintaxe sau funcţii, fiind mai mult un dicţionar
în care se pot găsi formele corecte de utilizare a unor instrucţiuni necesare pentru
desfăşurarea acţiunilor.
Tutorialele au ca scop învăţarea utilizatorului în ceea ce priveşte exploatarea
principalelor funcţii ale sistemului, prin ghidarea lui pe baza unor scenarii sau a unor
acţiuni specifice.
Indiferent de forma pe care o va lua documentaţia utilizatorului, realizarea ei reprezintă
o activitate care trebuie să fie desfăşurată cu mare atenţie, pentru a surprinde toate
elementele necesare exploatării cu eficienţă şi fără probleme a sistemului.
Momentul finalizării codificării şi cel al realizării versiunii finale a sistemului depind
de cât de repede şi cât de bine este realizată documentaţia utilizatorului. Conţinutul
documentaţiei şi persoanele responsabile pentru realizarea ei trebuie să fie cunoscute încă
de la începutul proiectului. Neglijarea acesteia până la finalizarea tuturor programelor poate
să conducă la următoarele situaţii: documentaţia poate să fie gata la momentul planificat,
dar, sub presiunea timpului, să nu fie adecvată cerinţelor sau e posibil să fie realizată
corect, însă se va întârzia etapa de implementare a sistemului. În orice caz, documentaţia
utilizatorului trebuie să fie disponibilă în momentul în care se trece la activitatea de
instruire.

TA 10.1
1. Care sunt componentele documentaţiei tehnice?
2. Descrieţi componentele documentaţiei utilizatorului.
Răspuns:

10.2 Selectarea şi instruirea personalului

Potenţial, proiectele de dezvoltare a noilor sisteme pot să conducă la modificări în
structura organizatorică a firmei, prin crearea de noi compartimente, apariţia de noi posturi
sau eliminarea unora dintre cele existente. În aceste condiţii este necesar să se stabilească
necesarul de personal, în special pentru posturile sau compartimentele noi, după care să se
demareze acţiunea de asigurare a personalului. În primul rând, vor fi testate persoanele ale
căror posturi au fost eliminate, oferindu-le şansa de a fi angajaţi în noul sistem. Angajări
din afara firmei se vor face numai în condiţiile în care sunt necesare persoane strict
specializate şi nu pot fi instruite cele din firmă36.
Înainte de a se trece la conversia sistemului, persoanelor implicate în exploatarea şi
întreţinerea noului sistemului trebuie să li se asigure instruirea necesară pentru cunoaşterea
modului de funcţionare a acestuia. De modul în care se va înţelege rolul fiecărei persoane şi
după cum se vor asuma responsabilităţile privind utilizarea sistemului depinde succesul
întregului proiect.
Problema instruirii utilizatorilor aplicaţiilor informatice este deosebit de importantă în
ţările cu economii avansate. De exemplu, în SUA se investesc aproape 100 miliarde de
dolari anual numai în acest scop, întrucât s-a ajuns la concluzia că investirea unui dolar în
pregătirea profesională a utilizatorilor de calculatoare este mai eficientă decât investirea
aceleiaşi sume în îmbunătăţirea (upgrade-ul) componentelor hard sau soft.

10.2.1 Participanţii la instruire

În stabilirea activităţilor de instruire trebuie să se aibă în vedere, mai întâi, participanţii,

deoarece conţinutul instruirii diferă, plecând de la cele trei mari categorii ce vor fi
implicate în exploatarea şi întreţinerea sistemului, respectiv: utilizatorii, personalul IT şi
managerii. Fiecare dintre aceştia are niveluri de pregătire şi nevoi diferite. Astfel,

36. Oprea, D. – Premisele şi consecinţele informatizării contabilităţii, Editura Graphix, Iaşi, 1994, p. 194.
141

utilizatorii sunt interesaţi de maniera în care trebuie să folosească sistemul pentru a
desfăşura activităţile zilnice. Personalul IT are nevoie de informaţii despre modul în care
sistemul funcţionează, în ce condiţii se poate interveni pentru realizarea arhivelor şi copiilor
de siguranţă, care sunt operaţiunile de întreţinere şi funcţiile de administrare. Managerilor
trebuie să li se ofere o imagine generală asupra sistemului pentru a se asigura că utilizatorii
vor fi instruiţi corespunzător şi că vor folosi sistemul în concordanţă cu specificaţiile şi
procedurile stabilite.
Utilizatorilor, pentru că de ei depinde în cea mai mare măsură performanţa sistemului
în exploatare, în funcţie de tipul aplicaţiei, trebuie să li se ofere cele mai utile forme de
instruire privind:
modul de utilizare a sistemului (domeniile funcţionale acoperite, modul de accesare
a meniurilor, modul de completare a formularelor/machetelor de ecran, maniera de
corectare a erorilor, nivelurile de acces disponibile, modalităţile de obţinere a
ieşirilor etc.);
conceptele de bază ale prelucrării automate a datelor;
conceptele de bază ale teleprelucrării;
conceptele de bază ale sistemelor informatice;
cunoştinţele despre SGBD şi/sau produse-program de calcul tabelar;
conceptele de bază din domeniile vizate de prelucrarea automată a datelor
(contabilitate, marketing, personal, secretariat ş.a.);
managementul proiectelor;
managementul sistemelor;
instalarea sistemelor (probleme ale conversiei lor) .
Pentru personalul IT, de multe ori, sunt suficiente doar informaţiile care se regăsesc în
documentaţia sistemului, în special în manualul de operare, fără a fi necesar să se
organizeze sesiuni formale de instruire. Adesea, chiar personalul nu agreează participarea
la cursuri, mai ales dacă este experimentat, considerând că este mai important să asigure
funcţionarea sistemelor, decât să ia parte la discuţii despre lucruri deja cunoscute sau pe
care le poate aborda în varianta autoinstruirii.
Managerii sunt cei care pot lua parte la toate sesiunile de instruire organizate pentru
utilizatori, dar de cele mai multe ori ei participă doar la sesiunea introductivă, în care se
prezintă sistemul de o manieră generală, şi, eventual, la cea finală în care se încearcă
rezolvarea potenţialelor probleme de utilizare.

10.2.2 Organizarea activităţilor de instruire

Maniera de organizare şi desfăşurare a instruirii depinde de o serie de factori, dintre

care amintim:
numărul participanţilor;
nivelul lor de pregătire;
complexitatea sistemului;
sursa componentelor sistemului, în special a aplicaţiilor;
existenţa unor persoane abilitate să desfăşoare astfel de activităţi;
disponibilitatea participanţilor de a renunţa pentru o perioadă de timp la activităţile
curente.
Organizarea instruirii presupune stabilirea a patru elemente esenţiale.

Un prim element avut în vedere îl constituie decizia asupra metodei de instruire care să
acopere cât mai bine nevoile participanţilor. Dintre principalele modalităţi de instruire, pot
fi enumerate37:
1. lucrări practice, seminarii coordonate de o singură persoană la un moment dat;
2. cursuri – prin care mai multe persoane predau unei serii de cursanţi;
3. instruirea asistată de calculator;
4. manuale interactive de instruire – o combinaţie a lucrărilor practice şi seminariilor
cu instruirile asistate de calculator;
5. componente help ale softului şi documentaţia sistemului.
Fiecare dintre aceste metode are avantajele şi dezavantajele proprii, dar, de cele mai
multe ori, se apelează la un mixaj al acestora.
Un al doilea element îl constituie stabilirea personalului care va asigura instruirea, în
situaţia în care se apelează la lucrările practice sau cursuri, ca modalităţi de instruire.
Astfel, pregătirea personalului se poate realiza cu personalul firmei sau cu specialişti din
afara ei, cum ar fi reprezentanţii de la firmele furnizoare.
În primul caz, când se apelează la personalul firmei, apar mai multe posibilităţi, şi
anume38:
utilizatorii sunt cei care asigură instruirea. Avantajul constă în faptul că ei vorbesc
aceeaşi limbă cu cei care sunt instruiţi şi pot răspunde mult mai uşor la întrebările
legate de domeniile funcţionale ale sistemului. În schimb, apare dezavantajul
limitării cunoştinţelor din punct de vedere tehnic. De asemenea, sunt puţine firme
care au utilizatori experimentaţi în derularea cursurilor, cu abilităţi de comunicare.
membrii echipei de specialişti se vor constitui în echipă de instruire. Ei sunt cei
care deţin cele mai multe cunoştinţe despre aspectele tehnice ale sistemului şi, ca
atare, pentru personalul de întreţinere a sistemului este varianta cea mai adecvată. În
schimb, pentru utilizatori apar o serie de inconveniente, cum ar fi: personalul de
specialitate, de cele mai multe ori, este prins cu alte activităţi din ciclul de
dezvoltare, foloseşte, cel mai adesea, un limbaj mai greu de perceput de către
utilizatori şi manageri, nu au cea mai bună abilitate de comunicare orală sau în
scris. Mai mult, cei mai mulţi dintre specialiştii IT consideră instruirea mai puţin
importantă decât celelalte activităţi în care sunt implicaţi;
cursurile vor fi ţinute de instructori specializaţi. Prin pregătirea pe care o au,
acoperă lipsa abilităţilor de comunicare, asigurând o viziune de ansamblu asupra
sistemului, fără a intra în detalii, care oricum nu pot fi reţinute până când cei care
exploatează sau întreţin sistemul nu se întâlnesc concret cu situaţii particulare.
Dezavantajele unei astfel de instruiri constau în faptul că instructorii nu cunosc
îndeajuns de bine domeniile funcţionale ale sistemului, sunt destul de puţine firmele
care îşi permit să aibă angajaţi astfel de specialişti.
În cel de-al doilea caz, contractarea de specialişti din afara firmei, se vor înregistra
costuri suplimentare, în situaţia în care aceştia nu fac parte din cadrul companiei care a
furnizat eventualele aplicaţii. Pe piaţă sunt şi furnizori specializaţi în organizarea de astfel
de cursuri, însă ele urmăresc o pregătire generală a personalului, pe componentele hardware
sau software de sistem pentru personalul IT, respectiv pentru dobândirea de către utilizatori
a abilităţilor de lucru cu anumite aplicaţii. Dacă se apelează la acest gen de

37. Nelson, R.R., Cheney, P.H. – „Training End Users: An Exploratory Study”, in MIS Quarterly 11, december 1987, pp.
547-559.
38. Kendall, K.E., Kendall, J.E. – op. cit., p. 644.
143

furnizori, este necesară, totuşi, şi asigurarea instruirii cu personalul propriu pentru oferirea
cunoştinţelor specifice domeniilor funcţionale.
În practica unităţilor beneficiare ale serviciilor de informatică, pe primul loc pentru
instruirea utilizatorilor figurează experţii proprii (peste 50% din cazuri), urmaţi de instruirea
asistată de calculator (peste 12% din cazuri), componente Help ale softului (10% din
cazuri), lucrări practice (7%), seminarii (7%), iar celelalte variante figurează cu câte 5
procente.
În pofida acestor statistici, deseori, se constată că utilizatorii finali spun că s-au instruit
singuri, fără să apeleze la modalităţile de instruire amintite. E drept că operaţiunea este
posibilă atunci când ei sunt deprinşi cu softul pentru dezvoltarea de aplicaţii (cum ar fi
Developer al firmei Oracle) sau cu pachetele de aplicaţii (de exemplu, Ciel sau Application
for Finance Oracle), cu comunicaţiile de date, cu modul de operare la calculatoare, cu
sistemele de operare ale acestora, cu tehnicile de lucru în mod grafic ş.a. Se subînţelege că
anterior ei au fost „şcoliţi” pe unele dintre aceste domenii.
Tuturor modalităţilor de instruire amintite, în ultima perioadă li s-au adăugat şi alte
căi: casete video, sisteme interactive de televiziune, telecablu, instruiri multimedia, lucrări
practice on-line şi multe altele, îndeosebi specifice învăţământului la distanţă.
Stabilirea locului de desfăşurare a instruirii constituie cel de-al treilea element al
organizării cursurilor. Ele se pot desfăşura la locul de activitate al personalului de
exploatare şi întreţinere, în spaţii special amenajate sau în afara firmei.
De obicei, instruirea utilizatorilor se realizează la locul de muncă al acestora pentru
asigurarea cadrului de lucru cu sistemul. Dar există riscul distragerii atenţiei prin faptul că
sunt presaţi de activităţile curente. Apelarea la spaţii special amenajate poate constitui un
avantaj din acest punct de vedere, dar apare limitarea numărului de participanţi, pentru că
în spaţiile respective nu există suficiente resurse sau nu pot fi blocate o lungă perioadă de
timp.
Instruirea în afara organizaţiei este folosită mai mult pentru cei din conducere, pentru
eliminarea perturbării activităţilor de către intervenţiile personalului propriu pentru
operaţiuni curente.
Pentru personalul IT, varianta cea mai bună o constituie desfăşurarea instruirilor în
mediul operaţional al sistemului, deşi există şi aici dezavantajul că ar putea fi afectată
funcţionarea normală a acestuia.
Al patrulea element îl constituie perioada în care se vor efectua cursurile. Decizia este
destul de dificilă, pentru că, pe de o parte, dacă se stabileşte ca instruirea să fie făcută la
începutul etapei de implementare, există suficient timp pentru învăţarea modului de lucru
cu noul sistem. Pe de altă parte, e posibil ca o astfel de instruire să fie frustrantă pentru că
sistemul nu este pe deplin testat, pot să apară multe erori sau blocări, ceea ce devine
obositor atât pentru cei instruiţi, cât şi pentru cei care asigură instruirea. Cu toate acestea,
stabilirea momentului în care se va desfăşura instruirea se face din primele etape ale
ciclului de viaţă al sistemului (o estimare iniţială a perioadei are loc în etapa de
microanaliză, respectiv planificarea proiectului, iar planificarea exactă după finalizarea
analizei şi proiectării sistemului).
În multe cazuri, decizia care se ia, în privinţa perioadei, depinde de strategia de
conversie a sistemului care s-a ales. Dacă se merge pe varianta conversiei directe sau
paralele, atunci instruirea trebuie să fie planificată pentru a se finaliza înainte de începerea
conversiei, dar cât mai aproape de ea, astfel încât utilizatorii să poată reţine şi aplica
imediat cunoştinţele asimilate. În cazul în care s-a ales să se meargă pe celelalte tipuri de
conversii (pe faze sau modulară), atunci planificarea instruirii trebuie să coincidă cu

planificarea fazelor/modulelor de conversie, iar instruirea trebuie desfăşurată pentru a se
evita întreruperea activităţilor curente desfăşurate simultan cu procesul de conversie.

10.3 Conversia sistemului

Procesul de trecere de la vechiul la noul sistem se numeşte conversie. Ea se finalizează
când noul sistem devine perfect funcţional în unitate. Pentru a minimiza problemele,
planificarea conversiei trebuie să demareze de îndată ce se cunoaşte natura noului sistem,
înaintea fazei de implementare. Acţiunile fazei de conversie sunt similare celor din etapa
de implementare, ceea ce înseamnă că se vor stabili şi în acest caz responsabilităţi de
execuţie a fiecărei activităţi.
Există mai multe tipuri de conversii. Înlocuirea unor echipamente uzate cu altele noi
presupune conversia acestora. Dacă noul sistem va schimba atât tipurile de activităţi, cât şi
secvenţa lor de execuţie, se impune o procedură de conversie. Similar, programele pot fi
supuse operaţiunii de conversie. Dar ,cea mai dificilă problemă privind conversia este
trecerea datelor dintr-un sistem în altul.
Se utilizează patru metode de conversie: directă, paralelă, pe faze, pe module.
Conversia directă poartă şi denumirea de „arderea podului”. Ea constă în renunţarea,
la un moment dat, la vechiul sistem şi trecerea la cel nou. Există un mare risc: dacă noul
sistem nu funcţionează corect, vechiul sistem nu mai există. Un alt factor de risc constă în
faptul că nu există posibilitatea de a verifica funcţionalitatea noului sistem, în sensul că nu
poate fi realizată o comparaţie între ieşirile noului sistem cu ale celui vechi.
Firmele apelează la această metodă pentru implementarea produselor-program
achiziţionate, pentru că ele implică un risc de eşec mai mic. Pentru sistemele dezvoltate în
interior, majoritatea firmelor folosesc metoda, dacă instalarea sistemului nu ridică mari
probleme. De asemenea, este necesară atunci când mediile de exploatare ale celor două
sisteme (vechi şi nou) nu sunt compatibile. O altă situaţie care favorizează apelarea la
metoda directă este cea a sistemelor implementate în mijlocul unui exerciţiu de gestiune şi,
pentru că trebuie obţinute diferite rapoarte la perioade exacte de timp, sistemul trebuie să
fie pregătit pentru generarea lor.
Conversia paralelă constă în funcţionarea paralelă a celor două sisteme o perioadă de
timp. Ieşirile din cele două sisteme sunt supuse comparaţiilor. Prelucrările paralele se
întrerup când noul sistem funcţionează perfect (de regulă, după săptămâni sau luni de
lucru). Avantajele metodei sunt date de faptul că se elimină riscul în caz de eşec al noului
sistem şi faptul că utilizatorii au mai mare încredere în noul sistem, oferindu-li-se
posibilitatea de a-l verifica înainte de fi dat în exploatare definitiv. Dezavantajul principal îl
constituie volumul dublu de muncă şi o cantitate mai mare de resurse. Totuşi, în practică,
este cea mai agreată metodă.
Conversia paralelă nu funcţionează în situaţia în care cele două sisteme nu sunt
compatibile tehnic sau când mediul de exploatare nu poate să suporte sarcina funcţionării
lor în paralel. De asemenea, nu se recomandă atunci când sistemele au funcţionalităţi
diferite sau noul sistem presupune o nouă metodă de derularea a operaţiilor economice.
Conversia pe faze sau graduală constă în înlocuirea treptată a elementelor sistemului,
evitându-se schimbările drastice, instalându-se câte un subsistem pe rând. În acest fel, noul
sistem poate să funcţioneze on-line cu o serie de componente funcţionale, logic ordonate,
astfel încât să elimine cât mai mult posibil perioadele de întrerupere a activităţii
145

utilizatorilor şi a fluxurilor economice. Principalul dezavantaj este creşterea costului prin
crearea interfeţelor temporare între vechiul şi noul sistem, precum şi timpul suplimentar
impus de înlocuirea treptată. Conversia pe faze nu poate fi folosită atunci când noul sistem
nu permite separarea modulelor sau subsistemelor.
Conversia modulară (pilot) presupune implementarea sistemului în unele componente
din unitate, cum ar fi un anumit număr de secţii, compartimente ş.a. Întâi se ia o staţie pilot
în care implementarea să se facă după una dintre cele trei metode prezentate, iar după
testare va fi extins fie în întregul sistem, fie în anumite locuri. Dezavantajul provine din
intervalul de timp mărit pentru conversie, precum şi din costul interfeţelor necesare între
vechiul şi noul sistem care coexistă până ce conversia se realizează în ultimul loc din
unitate.
O sinteză a metodelor de conversie este redată în fig. 5.5.

Sistem vechi
Sistem vechi Sistem nou
Sistem nou

a) Conversia directă b) Conversia paralelă

Sistem vechi Sistem nou Sistem vechi Sistem nou

c) Conversia pe faze d) Conversia modulară (pilot)

Fig. 5.5 Metode de conversie a sistemelor

O altă problemă a conversiei se referă la datele stocate. Fişierele existente şi bazele de
date sunt convertite pe trei căi diferite:
a) datele trebuie să fie transferate de pe un suport pe altul;
b) conţinutul datelor trebuie modificat (câmpuri şterse sau adăugate);
c) formatul fişierului trebuie modificat.
O conversie anume poate fi concretizată sub toate cele trei forme.
Conversia fişierelor sau a bazelor de date constă în patru activităţi principale:
1) pregătirea datelor pentru conversie;
2) conversia datelor;
3) verificarea corectitudinii noilor date;
4) documentaţia şi efectuarea copiilor de siguranţă.
Din cele prezentate rezultă că trecerea de la un sistem la altul este un proces complex,
iar descrierile de mai sus nu reprezintă decât elemente ce marchează importanţa problemei.


TA 10.1 1) Manualul de prezentare şi manualul de operare. 2) Vezi pag. XXX.



1) Dezavantajele conversiei directe constau în:
a) cantitatea mare de resurse consumată
b) nu există posibilitatea de a verifica funcţionalitatea noului sistem prin comparare cu
vechiul sistem
c) creşterea costului prin crearea interfeţelor temporare între vechiu şi noul sistem

2) În manualul de utilizare, care este parte a documentaţiei utilizatorului, sunt descrise:
a) cerinţele funcţionale ale sistemului care au fost solicitate de către utilizatori
b) modalitatea de eliminare a erorilor nedepistate în timpul testării
c) modul de corectare a eventualelor erori
d) specificaţiile de proiectare privind interfeţele utilizator

3) Utilizatorilor trebuie să li se ofere instruire privind:
a) normalizarea bazelor de date
b) conceptele de bază din domeniile vizate de prelucrarea automată a datelor
c) programarea în limbajul utilizat la implementarea sistemului
d) modul de utilizare a sistemului

1. Cum se clasifică documentaţia, din punct de vedere al etapelor ciclului de viaţă?
2. Care sunt principalele modalităţi de instruire?
3. Realizaţi o comparaţie a celor patru metode de conversie a sistemului.

10.6 Bibliografie


Bibliografie selectivă

1. Airinei, D., ş.a. – Medii de programare, Ediţia a IV-a, Editura Sedcom Libris, Iaşi, 2004
2. Bachenski, B. – „GUI Builders Pay Price for User Productivity”, in Software Magazine, April 1992;
3. Beizer, B. – Personal Computer Quality: A Guide for Victims and Vendors, Van Nostrand Reinhold
Company, New York, 1986.
4. Benbasat. I., Dexter, A.S., Todd, P. – „The Influence of Color and Graphical Information Presentation
in a Managerial Decision Simulation”, in Human-Computer Interaction 2, 1986.
5. Bidgoli, H. (editor) – Encyclopedia of Information Systems, vol. 4, Academic Press, Amsterdam, 2003.
6. Blattner, M., Schultz, E. – „User Interface Tutorial”, Proceedings of the International Conference on
System Sciences, Kona, Hawaii, January 1988.
7. Booth, P. – An Introduction to Human-Computer Interaction, Lawrence Erlbaum Associates, Londra,
1989.
8. Budd, T. – An Introduction to Object-Oriented Programming, Second Edition, Addison Wesley,
Reading, Massachusetts, 1998.
9. Carliner, S. – Industry Report: Overview of the Technical Communication Industry, 2002, www.stc.org
(accesat 2.01.2006).
10. Caroll, J.M. – Designing Interaction, Cambridge University Press, Cambridge, 1991.
11. Connoly, T.M., Begg, C.E. – Database Systems. A Practical Approach to Design, Implementation, and
Management, Third Edition, Addison Wesley, Harlow, 2002.
12. Craig, J.S., Beck, B.E. – „A New Look at Documentation and Training: Technical Communicator as
Problem Solver”, in Information Systems Management, 10 (Summer), 1993.
13. Crowley, A. – „The Help Desk Gains Respect”, in PC Week, no. 10, November 15, 1993.
14. Cushing, B.E., Romney, M.B. – Accounting Information Systems, Addison Wesley Publishing
Company, New York, 1994.
15. Date, C.J. – An Introduction to Database Systems, Seventh Edition, Addison Wesley, Reading,
Massachusetts, 2000.
16. Date, C.J. – Baze de date, Editura Plus, Bucureşti, 2005, traducere a lucrării Date, C.J. – An
Introduction to Database Systems, Eighth Edition, Pearson Education, Inc., Boston, 2004.
17. Davenport, T.H. – Process Innovation: Reengineering Work through Information Technology, Harvard
Business School Press, Boston, 1993.
18. Dollinger, R. – Baze de date şi gestiunea tranzacţiilor, Editura Albastră, Cluj-Napoca, 1999.
19. Dumas, J.S. – Designing User Interface for Software, Prentice Hall, Englewood Cliffs, 1988.
20. Elmasri, R., Navathe, S.B. – Fundamentals of Database Systems, Third Edition, Addison Wesley,
Reading, Massachusetts, 2000.
21. Fînaru, L., Brava, I.M. – Visual Basic. Primii paşi… şi următorii, Editura Polirom, Iaşi, 2001.
22. Forward, A. – Software Documentation – Building and Maintaining Artefacts of Communication,
University of Ottawa, Ontario, Canada, 2002.
23. Fotache, M. – Proiectarea bazelor de date. Normalizare şi postnormalizare. Implementări SQL şi
Oracle, Editura Polirom, Iaşi, 2005.
24. Gliedman, C. – Thirty-one Best Practices for the Service Desk, June 28, 2005, http://i.i.com/cnwk.ld/itp
(accesat 25.10.2005).
25. Greenbaum, J. – „The Evolution Revolution”, in Information Week, March 14, 1994.
26. Haarind, R. – „Software’s New Object Lesson”, in Technology Review, February-March, 1992.
27. Hall, G., Rosenthal, J., Wade, J. – „How to make reengineering really work”, in Harvard Business
Review, November-December 1993.
28. Halpin, T. – Information Modeling and Relational Databases, Kaufmann Publishers, Inc, San Francisco,
2001.
29. Hammer, M. – „Re-engineering work: don’t automative, obliterate”, in Harvard Business Review, July-
August 1990.
30. Hayley, K., Plewa, J., Watts, M. – „Reengineering Tops CIO Menu”, in Datamation, vol. 38., nr. 6,
April 15, 1993.
31. Hicks Jr., J.O. – Management Information Systems: A User Perspective, Second Edition, West
Publishing Company, St. Paul, 1987.


32. Hoffer, J.A., Prescott, M.B., McFadden, F.R. – Modern Database Management, Sixth Edition,
Pearson Education, Inc., Prentice Hall, Upper Saddle River, New Jersey, 2002.
33. Hoffer, J.A., George, J.F., Valacich, J.S. – Modern Systems Analysis and Design, Benjamin/Cummings
Publishing Company, Inc., Sand Hill Road, Menlo Park, 1996.
34. Hughes, B. – Practical software measurement, McGraw-Hill, London, 2000.
35. Jones, T.C. – Programming productivity: Issues for the 80s, IEEE Computer Society Press, 1981.
36. Kendall, K.E., Kendall, J.E. – Systems Analysis and Design, Fifth Edition, Prentice Hall, Upper Saddle
River, New Jersey, 2002.
37. Koval, J. A. – Analyzing Systems, Prentice Hall, Upper Saddle River, New Jersey, 1988.
38. Langer, A.M. – Analysis and Design of Information Systems, Second Edition, Springer – Verlag, New
York, 2001.
39. Madison, J. – Five “T’s” of Database Availability, www.standishgroup.com (accesat 20.10.2004).
40. Mandel, T. – The Elements of User Interface Design, John Wiley & Sons, New York, 1997.
41. Mandelkern, D. – „Graphical User Interfaces: The Next Generation”, in Communication of ACM 36, nr.
4, April 1993.
42. Marakas, G. – Systems Analysis and Design. An Active Approach, Prentice Hall, New Jersey, 2001.
43. Martin, J. – Information Engineering: Book II – Planning & Analysis, Prentice Hall, Englewood Cliffs,
New Jersey, 1990.
44. Martinsons, M.G., Revenaugh, D.L. – „Re-engineering is Dead; Long Live Re-engineering”, in
International Journal of Information Management, vol. 17, nr. 2, 1997.
45. May, J.C. – Extended the Macintosh Toolbox: Programming Menus, Windows, Dialogues and More,
Addison Wesley, Reading, Massachussetts, 1991.
46. McFadden, F.R., Hoffer, J.A. – Data Base Management, Second Edition, The Benjamin/Cummings
Publishing Company, Inc., Menlo Park, 1988.
47. McFadden, F.R., Hoffer, J.A. – Modern Database Management, Benjamin/Cummings Publishing
Company, Inc., Redwood City, 1994.
48. McLeod, Jr., R., Jordan, E. – Systems Development. A Project Management Approach, John Wiley &
Sons, Inc., New York, 2002.
49. Meşniţă, G. – „Reproiectarea proceselor economice (BPR)”, în Analele Ştiinţifice ale Universităţii „Al.
I. Cuza” Iaşi – Seria Ştiinţe Economice, Tomul XLVI, Editura Universităţii „Al. I. Cuza”, Iaşi, 2000.
50. Morris, D., Brandon, J. – Re-engineering Your Business, McGraw-Hill, New York, 1993.
51. Morse, A., Reynolds, G. – „Overcoming Current Growth Limits in UI Development”, in
Communications of ACM 36, nr. 4, April 1993.
52. Mosley, D.J. – The Handbook of MIS Application Software Testing, Yourdon Press, Englewood Cliffs,
New Jersey, 1993.
53. Naumann, J.D., Jenkins, A.M. – „Prototyping: The New Paradigm for Systems Development”, in MIS
Quarterly, 6 (3), 1993.
54. Nelson, R.R., Cheney, P.H. – „Training End Users: An Exploratory Study”, in MIS Quarterly 11,
December 1987.
55. Norman, K.L. – The Psychology of Menu Selection, Ablex, Norwood, New Jersey, 1991.
56. Oprea, D. – Analiza şi proiectarea sistemelor informaţionale economice, Editura Polirom, Iaşi 1999.
57. Oprea, D. – Premisele şi consecinţele informatizării contabilităţii, Editura Graphix, Iaşi, 1994.
58. Oprea, D. – Protecţia şi securitatea informaţiilor, Editura Polirom, Iaşi, 2002.
59. Oprea, D. – Protecţia şi securitatea sistemelor informaţionale, Editura Polirom, Iaşi, 2002.
60. Oprea, D. – Managementul proiectelor. Teorie şi cazuri practice, Editura Sedcom Libris, Iaşi, 2001.
61. Oprea, D., Meşniţă, G. – „Documentaţia sistemelor informaţionale – problemă a managementului
proiectelor?”, în vol. Societatea informaţională: Educaţie, Cercetare, Sisteme informaţionale, Tehnologii
Informaţionale, Editura ETP Tehnopress, Iaşi, 2004.
62. Page, J., Hooper, P. – Accounting and Information Systems, Fourth Edition, Prentice Hall, Englewood
Cliffs, New Jersey, 1992.
63. Porter, A. – C++ Programming for Windows, McGraw-Hill, Berkeley, 1993.
64. Post, G.V. – Database Management Systems. Designing and Building Business Applications, McGraw-
Hill, Boston, 1999.
65. Powers, M.J., Cheney, P.H., Crow, G. – Structured Systems Development: Analysis, Design,
Implementation, Boyd & Fraser Publishing Company, Boston, 1990.
66. Pressman, R.S. – Software Engineering. A Practitioner’s Approach, Fifth Edition, McGraw-Hill
Publishing Company, London, 2000.

BIBLIOGRAFIE 149

67. Richard, L.K. – Testing Requirements, www.gantthead.com (accesat 18.01.2006).
68. Riordan, R.M. – Designing Relational Database Systems, Microsoft Press, Redmond, Washington,
1999.
69. Satzinger J.W., Jackson, R.B., Burd, S.D. – Systems Analysis and Design in a Changing World,
Course Technology, Thomson Learning, Boston, 2002.
70. Schiesser, R. – IT Systems Management. Designing, Implementing, and Managing World-Class
Infrastructures, Prentice Hall PTR, Upper Saddle River, New Jersey, 2002.
71. Schulteis, R., Sumner, M., Bock, D. – Management Information Systems: The Manager’s View, Second
Edition, IRWIN, Homewood, Boston, 1992.
72. Shelly, G.B., Cashman, T.J., Rosenblatt, H.J. – Systems Analysis and Design, Fourth Edition, Course
Technology, Thomson Learning, Boston, 2001.
73. Shneiderman, B. – Designing the User Interface, Addison Wesley, 1998, Third Edition,
http://www.cs.utexas.edu/users/almstrum/cs370/elvisino/rules.html
74. Shneiderman, B. – Designing the User Interface: Strategies for Effective Human-Computer Interaction,
Addison Wesley, Reading, Massachusetts, 1992.
75. Simon, J.C., Chaney, L.H. – Systems and Procedures for the Modern Office –A Simulation Approach,
Second Edition, Regents/Prentice Hall, Englewood Cliffs, New Jersey, 1993.
76. Simsion, G.C. – Data Modeling Essentials. Analysis, Design, and Innovation, Second Edition, The
Coriolis Group, Scottsdale, Arizona, 2001.
77. Teorey, T.J. – Database Modeling & Design, Morgan Kaufmann Publishers, Inc, San Francisco, 1999.
78. van Vliet, H. – Software Engineering. Princples and Practice, Second Edition, John Wiley & Sons,
LTD, Chichester, 2002.
79. Văduva, I. ş.a. – Ingineria programării, Editura Academiei, Bucureşti, 1985 (vol. I), 1986 (vol. II).
80. Wiederhold, G., Wegner, P., Ceri, S. – „Toward Megaprogramming”, in Communications of ACM 35,
nr. 11, November 1992.
81. Yourdon, E. – Decline & Fall of the American Programmer, Englewood Cliffs, New Jersey, Yourdon
Press, 1993.
82. Zwass, V. – Management Information Systems, WCB-Wm, C. Brown Publishers, Dubuque, 1992.
83. *** – Foundation of Business Systems, Second Edition, Andersen Consulting – Arthur A. Andersen &
Co. S.C., Dryden, 1989.
84. *** – Software Process Engineering Metamodel, version 1.1, OMG, 2005.
85. *** – Unified Modeling Language (UML) Specification: Infrastructure, version 2.0, OMG, 2004, p. 10.
86. *** – Project Management – Guidelines, www.projectmanagement.tas.gov.au (accesat 06.07.2004).
87. *** – Oracle® Database Performance Tuning Guide 10g Release 2 (10.2), www.oracle.com.
88. *** – Incident Description Report, www.gantthead.com (accesat 12.01.2006).

SIFC2 Sisteme Informationale Financiar Contabile II - Suport Curs PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SIFC2 Sisteme Informationale Financiar Contabile II - Suport Curs PDF

Titlu original:

Încărcat de

Drepturi de autor:

Formate disponibile

Inţelegerea rolului şi locului economistului contabil în proiectarea şi implementarea

Pentru atingerea obiectivelor propuse, suportul de curs a fost structurat în 10 unităţi de

Modul de calcul al notei finale este redat în tabelul de mai jos.

Structura proiectului cuprinde următoarele părţi:

Caracteristica Descriere Clasificarea ieşirilor

Definirea scopului presupune cunoaşterea exactă a motivului pentru care a fost

Cunoaşterea destinatarilor serveşte la o bună proiectare a ieşirilor din sistem.

Eficacitatea rapoartelor depinde de oportunitatea lor. Dacă ele nu sunt furnizate la

Formatul ieşirilor defineşte modalitatea de organizare şi prezentare a informaţiilor,

În majoritatea cazurilor, sursa pentru obţinerea ieşirilor o constituie tabelele bazei de

Una dintre activităţile specifice proiectării ieşirilor priveşte alegerea modului de

Ieşirile afişate pe ecran

Odată cu îmbunătăţirea performanţelor şi reducerea preţului monitoarelor, ecranul a

Odată cu integrarea sistemelor informaţionale la nivel de organizaţie, dar şi inter-

Sistemele cu ieşiri bazate pe microfilme, COM

Sistemele audio şi video

1.2.8 Controlul confidenţialităţii, integrităţii

În paragrafele anterioare, am consemnat o mare varietate de ieşiri, în funcţie de scop,

Tabel nr. 1.3 – Caracteristicile informaţiilor pe niveluri decizionale

Descrierea detaliată a modului în care se reflectă calitatea ieşirilor în performanţele

Introducere sugestivă (partea de titlu)

Datorită progreselor semnificative înregistrate în domeniul tehnologiilor

Majoritatea ieşirilor din sistemele informaţionale economice au formă tabelară.

Tabel nr. 1.4 – Reguli generale de afişare a tabelelor

(1) Numărul tabelului

Deseori, există dispute între specialişti privind superioritatea graficelor în comparaţie

Atunci când se apelează la forma grafică de reprezentare a informaţiilor este necesar să

Recomandări generale pentru construirea graficelor

Identificarea Cerinţele iniţiale Realizarea

În proiectarea ieşirilor, analistul trebuie să elaboreze un model demonstrativ al

Identificarea interfeţelor utilizator este realizată în strânsă legătură cu prima accepţiune

Dacă interfaţa dintre utilizator şi calculator a fost, pe vremuri, practic imposibilă,

3.2.1.1 Interacţiunea prin limbaj-comandă

Toate calculatoarele încep să funcţioneze prin comenzi, omul transmiţând

Zone cu comenzi şi linii-meniu

Există produse-program care, imediat ce sunt lansate în execuţie, afişează comenzile

b) Exemplu de meniu în cascadă

Obiect de control Descriere şi caracteristici principale

În figura 2.4 este prezentat un exemplu de formular pentru introducerea şi vizualizarea

la dreapta şi de sus în jos, însă cu posibilităţi de revenire, la cerere. Formularele pentru

Întrucât în paragrafele anterioare am făcut referire şi la echipamentele care asigură

la dreapta şi de sus în jos, însă cu posibilităţi de revenire, la cerere. Formularele pentru

3. Furnizarea În cazul acţiunilor cu frecvenţă mică şi/sau de importanţă mare este

Introduceti unitatea de măsură: mc

Introduceti preţul: 56,20

Printr-un mod de lucru se înţelege un context în care se află aplicaţia la un moment

Problema majorǎ, în cazul memorării pe termen lung, este legatǎ de regǎsirea

Aplicarea acestui principiu presupune ca utilizatorul sǎ vadǎ informaţiile şi obiectele

Acelaşi obiect trebuie sǎ aibă un comportament similar, în situaţii şi ecrane diferite.

Fig. 2.6 Procesul iterativ de proiectare a interfeţelor utilizator

Dezvoltarea unui sistem informaţional trebuie să înceapă cu definirea clară a

Determinarea profilului utilizatorilor

În cadrul acestei activităţi, analistul trebuie să identifice categoriile de utilizatori, să

Acum se urmăreşte identificarea şi descrierea atribuţiilor de serviciu ale utilizatorilor,

În acest moment, se vor culege informaţiile privind doleanţele utilizatorilor, cu privire

Analiza mediului de lucru al utilizatorilor

Prin analiza mediului de lucru se urmăreşte determinarea caracteristicilor de mediu

Armonizarea cerinţelor utilizatorilor cu sarcinile lor de serviciu

În finalul acestei faze, se va verifica dacă cerinţele exprimate de utilizatori corespund

Caseta nr. 2.2 – Rezultatele fazei de colectare şi analiză a informaţiilor necesare

Obiectivele privind calitatea interfeţelor utilizator pot fi definite, de o manierǎ mai

Factorii calităţii Obiectivele de calitate