III.5.

Componenta de interfaţă şi dialog cu utilizatorii

Componenta de interfaţă şi dialog cu utilizatorii reprezintă componenta ce asigură

interfaţa cu utilizatorul, acoperind toate aspectele legate de comunicarea dintre
utilizator şi sistem. Deoarece utilizatorii SSD sunt, de multe ori managerii fără cunoştinţe
avansate de utilizare a calculatoarelor, interfaţa cu utilizatorul a SSD trebuie să fie
intuitivă şi uşor de utilizat, cu posibilităţi de personalizare, în funcţie de preferinţele
utilizatorului. Interfaţa ajută în construirea modelelor şi în interacţiunea cu modelele.
Rolul principal al componentei este de a îmbunătăţi capacitatea utilizatorului de a
utiliza şi de a beneficia de SSD (Druzdzel, Flynn, 2002).
O interfață cu utilizatorul este ceea ce managerii văd și utilizează atunci când
interacționează cu un DSS. Mai precis, o interfață cu utilizatorul este setul de meniuri,
pictograme, comenzi, formate grafice de afișare și / sau alte reprezentări furnizate de un
program software pentru a permite utilizatorului să comunice și să utilizeze programul.
De asemenea, o interfață cu utilizatorul se referă la hardware și software care
creează comunicarea și interacțiunea dintre un utilizator DSS și computer. Interfața cu
utilizatorul include răspunsuri și implică un schimb de semne grafice, acustice, tactile sau
de altă natură. Cercetarea interfeței utilizatorului este un subset al unui câmp numit
interacțiune computer-umană (HCI). HCI se concentrează pe studiul oamenilor,
computerului tehnologie și modul în care fiecare îl influențează pe celălalt.
O interfață de utilizator eficientă este importantă, deoarece datele și graficele afișate
pe ecranul stației de lucru ale unui computer oferă un context pentru interacțiunea umană
și indicii pentru acțiunile dorite de către un utilizator. Utilizatorul formulează un răspuns
la contextul furnizat de interfața utilizatorului și ia o acțiune. Datele trec apoi înapoi la
computer prin interfață.
O interfață de utilizator bine concepută poate crește viteza de procesare umană,
reduce erorile, crește productivitatea și creează un sentiment de control al utilizatorului.
Calitatea unei interfețe DSS, din perspectiva utilizatorului, depinde de ceea ce vede sau
simte utilizatorul, de ceea ce trebuie să știe utilizatorul pentru a înțelege ceea ce este văzut
sau simțit și ce acțiuni poate face utilizatorul și, în unele cazuri, să întreprindă pentru a
obține rezultatele dorite.
Pentru a crea o interfață de utilizator bine concepută, profesioniștii din SIG trebuie să
lucreze îndeaproape cu potențialii utilizatori, să încerce diverse soluții de proiectare și să
ofere utilizatorilor un control adecvat asupra funcțiilor sistemului. Această abordare este
adesea numită User Centered Design (cf., Gulliksen, Lantz și Boivie, 1999). Ambele
grupuri de participanți la proiectare trebuie să fie familiarizați cu următoarele probleme
importante și subiecte legate de construirea și evaluarea unei interfețe cu utilizatorul:

1. Stilul interfeței cu utilizatorul - Este adecvat stilul sau combinația de stiluri? Ce stiluri
sunt utilizate în interfața cu utilizatorul?
2. Proiectarea și aspectul ecranului - Ce abordare de proiectare ar trebui utilizată? Este
designul ușor de înțeles și atractiv? Designul este simetric și echilibrat?
3. Utilizarea culorilor, a liniilor și a graficelor - Sunt culorile utilizate în mod
corespunzător? Grafica îmbunătățește designul sau distrage atenția utilizatorului?
4. Densitatea informațiilor - Sunt prezentate prea multe informații pe ecran? Utilizatorii
pot controla densitatea informațiilor?
5. Utilizarea pictogramelor și simbolurilor - Sunt de înțeles icoanele?
6. Alegerea dispozitivelor de intrare și ieșire - Dispozitivele se potrivesc sarcinii?
7. Secvența de interacțiune Human-Software - Interacțiunea dezvoltată de software este
logică și intuitivă? Oamenii răspund previzibil la secvența de interacțiune?

Pornind de la cele trei componente de bază ale unui sistem suport pentru decizii şi
de la relaţiile dintre ele, se pot enumera următoarele arhitecturi ale componentei de
interfaţă şi dialog cu utilizatorii (Airinei, 2006):
- arhitectura în reţea – fiecare model dispune de baza sa de date, de modulul său de
dialog ca şi de module de integrare;
- arhitectura centralizată – fiecare model depinde de modul de dialog unic şi
comunică cu o singură bază de date.;
- arhitectura ierarhizată – se apropie de sistemul centralizat, doar că modulul de dialog
este divizat, în timp ce modulul bază de date este prevăzut cu un nivel suplimentar.
Tabelul. 6. Avantajele şi dezavantajele diferitelor arhitecturi (Airinei, 2006)
 Arhitectura Avantaje Dezavantaje
Reţea - Arhitectură deschisă - Integrare slabă
- Modularitate sporită - Lipsa unităţii de dialog
- Dificultăţi în schimburile de date
Centralizată - Integrare sporită -- Dificultăţi în mari
Dificultăţi în controlului
proiectarea realizarea
- Unitate de dialog modificărilor, mai ales la
- Facilităţi de schimb de date introducerea de noi modele
- Relativă uşurinţă de realizare - Lipsa confidenţialităţii pentru
Ierarhică - Integrare sporită - Dificultăţi în realizarea
accesul la date
- Unitate de dialog supervizorului şi a modulului de
- Facilităţi de creare a bazelor extragere suficient de universale
de date Uşurinţă în pentru a suporta modificări
realizarea modificărilor ulterioare
Componenta Uşurinţă
de de interfaţă şi dialog cu utilizatorii (figura 8) este o componentă a
în utilizare
sistemului suport de decizie care permite comunicarea bidirecţională între sistem şi
utilizator.

Acţiunile transmise sistemului, respectiv răspunsurile primite de către utilizator se pot

realiza prin intermediul unei interfeţe grafice care este construită de către sistem prin
componentele sale specializate (procesorul de limbaj natural, sistemul de management al
interfeţei cu utilizatorul, perifericele de intrare ieşire împreună cu programele driver
aferente).

În 2001, Eom prezenta funcţiile interfeţei cu utilizatorul:

 să permită utilizatorului să creeze, să actualizeze şi să şteargă
înregistrări ale bazelor de date şi modele de decizie prin intermediul
sistemului de gestiune a datelor şi sistemul de gestiune a modelelor;
 să furnizeze o varietate de formate de intrare şi de ieşire –
elemente grafice multi-dimensionale, tabele şi ferestre;
 să furnizeze diferite stiluri de dialog (interfeţe grafice (GUI),
meniuri, comenzi directe, interacţiune în limbaj natural, interacţiune
de tip întrebări şi răspunsuri).
Proiectarea unei interfeţe de utilizator presupune obţinerea unei înţelegeri complete a
nevoilor utilizatorilor şi a modului în care acestea iau deciziile.

Interfaţa de utilizator poate include:

 Comenzi
 Set de meniuri
 Grafică
 Icoane
 Ghiduri
 Acustică
 Tactile
 Hardware
 Orice altă prezentare
Cele mai importante caracteristici ale interfeţei de utilizator sunt următoarele:

 Influenţează modul în care utilizatorii interacţionează cu sistemul de asistenţă

decizională
 Echilibrează tehnicitatea (funcţionalitatea sistemului) şi mentalitatea (starea de
spirit a utilizatorului)
 Oferă utilizatorilor o modalitate (vizuală) de a interacţiona cu sistemul
 Creează comunicare şi interacţiune impecabilă între utilizator şi sistemul de
asistenţă la decizii
 Reduce erorile, creşte viteza, sprijină „luarea de decizii bune”
 Logic şi intuitiv în acelaşi timp

Stiluri de interfaţă utilizator

După cum ştim, interfaţa utilizator este spaţiul în care au loc interacţiuni om-maşină.
Aceasta decide modul în care utilizatorul introduce informaţiile şi modul în care
sistemul prezintă rezultatul. Există diferite modalităţi de interacţiune cu sistemele
computerizate de luare a deciziilor.

Cu toate acestea, ce stil de interfaţă de utilizator trebuie utilizat trebuie să fie decis
înainte de începerea procesului de dezvoltare. Nu există reguli dure şi rapide despre
care este cel mai bun stil de interfaţă de utilizator. Un sistem de asistenţă decizională
poate utiliza un stil de interfaţă sau o combinaţie de două sau mai multe stiluri.
Un proiectant DSS poate oferi mai multe secvenţe de control pentru a gestiona sau
rula un program software, în funcţie de nevoile utilizatorilor. Există şase stiluri de
interfaţă de utilizator dominante care pot fi utilizate:

1. Interfaţă linie de comandă: După cum sugerează numele, interfaţa de linie de

comandă a folosit dominant comenzile pentru a seta interacţiunea utilizatorului cu
sistemul software. Un utilizator ar introduce comanda, cum ar fi „rula” şi sistemul o
va executa. Sistemele de operare utilizate au fost MS-DOS, UNIX şi LINUX. Această
interfaţă ar necesita un utilizator să introducă comanda, pentru a spune maşinii ce
trebuie să facă. Deşi astfel de interfeţe au fost puternice, utilizatorul ar trebui să înveţe
de fapt comenzile pentru ca un sistem să funcţioneze pentru acestea, ceea ce era cu
siguranţă restricţionarea.
2. Interfaţa de meniu: Interfaţa de meniu oferă utilizatorilor o listă de funcţii sub formă
de alegeri. Meniul derulant facilitează selectarea unei funcţii care trebuie îndeplinite.
Partea cea mai bună este că utilizatorii nu trebuie să înveţe comenzile pentru a utiliza
sistemul software.

Cu toate acestea, meniurile sunt potrivite pentru sisteme simple. Pe măsură ce

complexitatea creşte, utilizatorii necesită mai multe seturi de meniuri pentru a alege.
Chiar şi elementele din meniu pot avea submeniuri. Un bun exemplu de astfel de sistem
de operare este Windows. Dar când vine vorba de construirea DSS folosind interfaţa
meniului, este nevoie de timp şi resurse imense pentru proiectarea şi dezvoltarea
interfeţei şi a software-ului în sine pe termen lung.
3. Interfaţă grafică: este un sistem de interfaţă care permite utilizatorilor să dea comenzi
prin obiecte vizibile. Puneţi sau atingeţi imaginile, pictogramele sau simbolurile pentru a
efectua o acţiune. Interfaţa grafică a utilizatorului se concentrează mai mult pe
multimedia, decât pe text.
4. Interfaţa întrebare-răspuns: acest tip de interfaţă permite maşinii să pună întrebări şi
utilizatorului să introducă răspunsuri la întrebări. Se transformă într-un dialog atunci când
utilizatorul continuă să răspundă la întrebările adresate de sistem. Acest tip de interfaţă
este un efort de a induce interacţiunea om-om printr-un sistem. Cu toate acestea,
provocarea majoră apare atunci când răspunsurile furnizate de utilizator sunt
nestructurate, deoarece un computer nu înţelege răspunsurile nestructurate.
5. Interfaţă utilizator vocal: după cum sugerează şi numele, face posibilă interacţiunea
om-maşină prin vorbire. O voce umană este necesară pentru a controla maşina sau pentru
a o face să efectueze o acţiune. Interfeţele utilizatorilor de voce au devenit acum ceva
obişnuit. Acestea sunt interfeţe fără ochi şi mâini libere care efectuează acţiuni prin
recunoaşterea vorbirii.

6. User Interface Touch: Acesta este cel mai popular şi cel mai recent tip de interfaţă cu
utilizatorul. Se bazează pe simţul atingerii şi direcţionează sistemul pentru a efectua
acţiunea aleasă atunci când un utilizator atinge un anumit vizual. În mediul digital, este
utilizat alături de interfaţa utilizatorului de voce şi grafică.
Abordare de proiectare RFMC - Reprezentare - Funcţionare - Ajutor de memorie -
Ajutor de control

RFMC este o abordare organizată pentru proiectarea sistemelor specializate de asistenţă

decizională, mai precis a interfeţelor lor de utilizator. Este o mişcare sistematică către
proiectarea mecanismelor de reprezentare, funcţionare, memorie şi control ale unui mare
sistem de asistenţă la decizii.

Sugerată de Ralph Sprague şi Eric Carlson în 1982, se concentrează pe analiza celor patru
elemente importante menţionate mai sus ale unei interfeţe de utilizator. Abordarea ajută
la identificarea competenţelor esenţiale ale unui sistem computerizat. Nu numai că
această abordare este potrivită pentru dezvoltarea de proiecte de interfaţă de utilizator,
dar aceasta poate fi folosită şi pentru crearea proiectelor de ecran.

 Reprezentarea - Reprezentarea se referă la prezentarea de informaţii sau rezultate

pentru chestiunea respectivă, într-un mod structurat. Toate activităţile de luare a
deciziilor într-o organizaţie au loc într-un anumit mediu sau context. Reprezentarea,
în tandem cu acest context, oferă o conceptualizare tangibilă pentru a comunica
informaţii către factorul de decizie sau utilizatorul sistemului despre situaţie.

Reprezentarea oferă o bază pentru factorii de decizie susţinuţi de informaţii concrete,

ajutându-i să interpreteze rezultatele DSS. Reprezentarea poate fi sub forma unui
tabel, grafic, hartă, grafic sau un document text şi fiecare valoare de pe o hartă sau un
tabel comunică contextul decizional.

 Funcţionare - Această etapă a proiectării interfeţei utilizatorului se concentrează pe

sarcini specifice efectuate de / cu un sistem de asistenţă decizională. Operaţiunea
poate implica o activitate sau multe, în funcţie de nevoile specifice ale factorului de
decizie. Un DSS poate fi utilizat pentru procesarea datelor, urmărirea tendinţelor
pieţei, realizarea de analize sau sugerarea alternativelor sau îndeplinirea tuturor
funcţiilor.

 Ajutor de memorie - Cum va funcţiona un DSS? Pe ce bază va produce rezultate?

Ce va reprezenta? Trebuie să aibă acces la date pentru a sintetiza şi analiza. Un
depozit de date este ajutorul său de memorie şi deci pentru factorii de decizie. Aşadar,
 trebuie să ofere utilizatorilor un link către datele de la depozitul de date care să le
ajute memoria. În plus, le poate oferi legături şi comenzi rapide sau secvenţe de
comandă pentru a ajuta utilizatorii să controleze un sistem de asistenţă la decizii.

 Ajutor de control - Ajutorul de control este oferit utilizatorilor, astfel încât aceştia să
poată utiliza în mod eficient reprezentări, operaţii şi auxiliare de memorie. Le permite
să editeze, să refacă, să anuleze, să salveze, să vadă, să şteargă orice informaţie sau
reprezentare sau sarcina îndeplinită de / cu un DSS. Acestea facilitează utilizatorul să
interacţioneze cu şi să controleze un sistem de asistenţă la decizii. Comenzile depind
totuşi de tipul de interfaţă de utilizator.

Un design al interfeţei utilizator este format din toate aceste elemente şi o mulţime de
brainstorming şi planificare intră în ea. Proiectarea unui proiect de utilizator nu este un
proces tehnic; mai degrabă este un efort colectiv al experţilor tehnici şi decizionali. Ei
trebuie să lucreze îndeaproape, pentru a proiecta o interfaţă de utilizator excelentă. Acest
lucru creşte probabilitatea ca un sistem să fie utilizat după dezvoltare şi implementare

Iată 10 reguli de proiectare a interfeţei utilizator pe care trebuie să le urmaţi la proiectarea

uneia:

1. Coerenţă: un software pentru sistemul de asistenţă decizională trebuie să arate, să

simtă şi să acţioneze similar în tot. Combinaţia de culori, tema, afişarea meniului
şi alte elemente vizuale trebuie să fie consistente. Face un aspect DSS organizat şi
bine gândit.

2. Reducerea supraîncărcării informaţiilor: Obiectivul principal al unui sistem de

asistenţă decizional este reducerea supraîncărcării informaţionale şi simplificarea
lucrurilor în măsura posibilului. Probabil, acesta este motivul pentru care
majoritatea organizaţiilor folosesc sisteme computerizate pentru a ajuta la luarea
deciziilor. Memoria umană este supusă unei limitări atunci când vine vorba de
comenzi de procesare a informaţiilor şi de învăţare. Dacă este cazul, proiectarea ar
trebui să fie minimizată şi trebuie afişate comenzile şi succesiunea acţiunilor ar
trebui să fie scurtată.
3. Design minimalist al interfeţei: interfaţa ar trebui să fie atrăgătoare; cu toate
acestea, nu trebuie să-ţi arăţi latura artistică. Trebuie să fie echilibrat, liniştitor,
interactiv şi receptiv.

4. Feedback informativ: Utilizatorii aşteaptă cu nerăbdare să dea feedback

informativ despre comanda pe care au dat-o sau despre acţiunile pe care le-au
efectuat. Comenzile minore pot oferi feedback modest, în timp ce feedback-ul
concret trebuie oferit pentru acţiuni rare.

5. Interacţiuni de proiectare: fiecare interacţiune ar trebui să aibă o secvenţă sau o

ordine - început, mijloc şi sfârşit. Acest lucru păstrează o pistă a fluxului de
dialog.

6. Anticipează erorile: trebuie să anticipezi erorile posibile pe care le poate face un

utilizator atunci când foloseşte sistemul de asistenţă decizional. Gândiţi-vă la
modalităţi simple şi inteligibile de a detecta erorile şi de a ghida utilizatorii cu
privire la ce trebuie să facă acum. În unele locuri, sistemul trebuie să îi aducă la
cunoştinţă utilizatorilor ce erori vor face apăsând o comandă.

7. Permite inversarea acţiunii: includeţi „anulaţi”. Uneori, utilizatorii fac greşeli

fără intenţie. Dar incapacitatea de a inversa acţiunea poate crea anxietate în
utilizatori. Oferă-le flexibilitatea de a anula ceea ce au făcut, fie că sunt în
cunoştinţă de cauză sau fără să ştie. Le oferă încrederea de a încerca lucruri noi.

8. Oferiţi utilizatorilor Controlul sistemului: Oamenii care folosesc un sistem de

asistenţă decizională vor să controleze fiecare aspect al sistemului. Incapacitatea
de a-i controla îi face anxioşi şi neconfidenţi. Dă-le controlul asupra sistemului şi
lasă-i să-l exploreze atât cât vor.

9. Furnizaţi acceleratoare: Deoarece factorii de decizie utilizează un DSS mai des,

ei nu vor să ofere aceleaşi informaţii de fiecare dată când se conectează la sistem.
Oferiţi-le acceleratoare pentru a scurta interacţiunile şi a creşte ritmul. Oferiţi
abrevieri şi comenzi de automatizare care accelerează întregul proces de luare a
deciziilor.
 10. Oferiţi funcţii de documentare şi ajutor: un DSS deşi nu este incomplet dacă nu
oferă funcţii de documentare, dar utilizatorilor poate părea incomplet. Astfel de
capacităţi sunt de dorit, deoarece majoritatea utilizatorilor vor să documenteze
puncte majore sau ceva care le atrage atenţia.

Iată, aşadar, factorii care influenţează succesul designului UI. Uită-te:

 Timpul de execuţie: De ce utilizatorul decide să folosească un sistem

computerizat pentru a ajuta la luarea deciziilor? Evident, pentru a reduce timpul
de execuţie! Ca proiectant DSS, trebuie să încercaţi să reduceţi timpul de execuţie
pentru o comandă dată şi o acţiune efectuată. Maximizaţi ritmul de execuţie
pentru a minimiza risipa de timp.

 Versatilitate: Un sistem de asistenţă decizională trebuie să fie suficient de plin de

resurse pentru a îndeplini întreaga gamă de sarcini pe care un factor de decizie
trebuie să le îndeplinească atunci când ia o decizie folosind DSS. În plus, ar trebui
să fie suficient de flexibil pentru a integra sarcini noi ori de câte ori apar nevoi.

 Adaptabilitate: Un sistem de asistenţă la decizii ar trebui să fie suficient de

inteligent pentru a se adapta în funcţie de obiceiurile cele mai proeminente ale
utilizatorului său. Acest lucru înseamnă că trebuie să fie personalizat sau
personalizat în sine. Poate părea practic, dar în realitate nu este. Este mai degrabă
ceea ce se aşteaptă de la un sistem inteligent de luare a deciziilor.

 Timpul de învăţare: O interfaţă de utilizator DSS ar trebui să fie suficient de

simplă pentru a reduce timpul de învăţare al utilizatorilor săi, astfel încât să poată
utiliza aceasta la capacitatea maximă cât mai curând posibil.

 Uniformitatea comenzii: Aşa cum s-a spus mai devreme, o interfaţă de utilizator
DSS trebuie să aibă o temă uniformă în tot. Ar trebui să ofere acelaşi aspect şi
aceeaşi simţire şi comandă pe tot parcursul.

 Calitate help: Atunci când un factor de decizie este utilizator un DSS construit de
dvs., acesta sau ea se aşteaptă de la dvs. un sprijin complet şi off line. Succesul
unui DSS depinde de calitatea suportului oferit. Recunoaşteţi ce poate face
utilizatorul pe / cu DSS şi oferă manuale de auto-ajutor atât online, cât şi offline.
  Încărcarea memoriei: o persoană are limitări atunci când vine vorba de
amintirea numerelor. Ideea este să nu bombardezi utilizatorul cu prea multe
interpretări statistice sau numerice simultan. Un design bun al interfaţei de
utilizator scoate sarcina de memorie din mintea utilizatorului.

 Uşor de reamintit: Dacă un utilizator revine la DSS după mult timp, acesta
trebuie să-l ajute să-şi amintească ce a fost făcut anterior. Îi ajută să atingă acelaşi
ritm într-un timp scurt.

 Oboseală: oboseala mentală apare din cauza complexităţii designului. Menţineţi

lucrurile simple şi păstraţi vizual comenzile astfel încât utilizatorul să nu fie
nevoie să-şi amintească nimic.

 Erori: anticipează erorile pe care un utilizator le poate efectua atunci când

foloseşte un sistem de asistenţă decizional. Oferaţi-le controlul pentru a inversa
acţiunea şi ajutaţi-i să-i îndrumaţi ce trebuie să faceţi în continuare

Keen și Gambino (în Bennett, 1983, p. 168) oferă următoarele sugestii pentru construirea
unei interfețe cu utilizatorul DSS. Ei cred că prototiparea rapidă și designul adaptiv sunt
esențiale pentru construirea interfeței cu utilizatorul; ei susțin că un analist, programator
sau consultant DSS care construiește un DSS trebuie să facă următoarele:

a. Inceperea. O aplicație DSS nu vine de obicei ambalată cu specificații îngrijite.

Începeți cu un design inițial al interfeței cu utilizatorul. Oferă un mijloc de învățare de
la utilizator și de răspuns la acesta.

b. Răspundeți rapid. O interfață de utilizator DSS trebuie să evolueze rapid, iar

proiectanții trebuie să învețe rapid. Structura de proiectare și tehnicile de programare
trebuie să faciliteze evoluția și învățarea.

c. Acordați o atenție deosebită interfețelor și ieșirilor utilizator-sistem. Un DSS este

„un set de componente relativ simple care trebuie să se potrivească pentru a permite
rezolvarea problemelor complexe, variate și idiosincrazice”. Un analist DSS trebuie
să obțină o înțelegere foarte detaliată a sarcinii care trebuie sprijinită și a persoanelor
care o îndeplinesc.
Potrivit lui Keen și Gambino, „secvența și ordinea naturală a prioritatii” în dezvoltarea
oricărui tip de DSS sunt următorii patru pași:

1. Proiectați interfața și dialogul cu utilizatorul.

2. Proiectați comenzi și operațiuni în ceea ce privește procesele și conceptele

utilizatorilor.

3. Definiți ce face și vede utilizatorul când este invocată o comandă.

4. Lucrați înapoi pentru a crea logica programului și gestionarea datelor.

Profesorul Mark Silver (1991) a propus o abordare de proiectare alternativă. El sugerează

următorii pași, după caz, pentru dezvoltarea unei interfețe de utilizator DSS:
1. Stabiliți cine este utilizatorul dvs.
2. Stabiliți ce va face utilizatorul cu sistemul. Care sunt sarcinile specifice?
3. Determinați ce secvență de pași trebuie să urmeze utilizatorul pentru a îndeplini o
sarcină.
4. Schematizați pașii de la punctul 3 și arborele de decizie implicat. Examinați-le
împreună cu utilizatorul.
5. Determinați care dintre acești pași necesită interacțiune cu sistemul.
6. Determinați informațiile și cerințele de decizie pentru fiecare interacțiune (atât de
sistem, cât și de utilizator).
7. Selectați categoriile de dialog (meniuri, solicitări, formulare etc.).
8. Schemați fluxul dialogului, arătând toate deciziile și cerințele lor de informații.
Examinați-le împreună cu utilizatorul.
9. Ecrane de proiectare.
10. Încercați-l, analizați-l, simplificați-l, schimbați-l, încercați-l. . .
11. Actualizați diagramele de decizie.
12. Protejează dialogul întrebând ce se întâmplă dacă utilizatorul face ceva neașteptat?

Etapele 4-11 sunt un proces de proiectare iterativ.

Chiar dacă un analist DSS intenționează să dezvolte o interfață de utilizator DSS

utilizând prototipuri rapide, este important să înțelegem cine este utilizatorul DSS, pentru
ce va fi utilizat sistemul și ce secvență de pași va urma un utilizator. Un proiectant poate
fi capabil să treacă peste unele dintre etapele formale de diagramare, cum ar fi pașii 4, 8
și 11, în favoarea creării unui prototip, dar o anumită înțelegere a sarcinii ar trebui să fie
formalizată și documentată.

În general, un analist DSS ar trebui să finalizeze proiectarea interfeței cu utilizatorul

înainte de a construi o bază de date și de a implementa proiectarea. În timpul construcției
unui DSS se vor face modificări, dar proiectarea interfeței obligă un analist să se ocupe
de multe probleme practice. Un analist DSS poate utiliza o serie de instrumente pentru a
ajuta la proiectarea interfeței, inclusiv machete de ecran, diagrame de tranziție și arbori
de meniu.

Când este posibil, software-ul care implementează interfața cu utilizatorul ar trebui să fie
decuplat de datele, modelul și componentele de comunicare DSS.

III.6. Componenta de comunicaţie pentru SSD-uri

Filip, 2007 prezintă importanţa şi implicaţiile pe care această componentă le

are asupra utilizării eficiente a SSD-urilor, asupra desfăşurării procesului decizional
asistat de SSD şi arată faptul că un acces şi o legătură de tip în orice moment şi în orice
loc (any-time, any-place) între participanţii la adoptarea şi implemetarea deciziilor
multiparticipant est absolut necesară şi de dorit în cazul celorlalte tipuri de decizii.

Comunicarea se poate realiza prin intermediul tehnologiilor moderne de

comunicaţii (cu sau fără fir – fixe sau mobile) şi al echipamentelor de tip pager, telefoane
celulare, PDA, reţele de calculatoare.

Comunicarea între SSD-uri prin intermediul reţelelor de calculatoare se poate

realiza prin intermediul soluţiilor de tip client/server sau prin transmiterea de pachete
de date prin reţele ce funcţionează pe principiul reţelei Internet, organizate pe baza
modelului TCP-IP.

Reţelele de tip Wireless asigură mobiltate componentelor SSD, în special

utilizatorilor acestuia. Reţelele Wireless funcţionează pe baza standardelor IEEE
802.11 (cele de tip WiFi – Wireless Fidelity), 802.16 (cele de tip WiMax (Worldwide
Interoperability for Microwave Access), 802.15.1 (WPAN sau Bluetooth – Wireless
Personal Area Network).

Arhitectura client/server

Utilizarea arhitecturii de tip client – server are avantajul că este simplă, uşor de
implemetat, are costuri mici şi aduce beneficii datorită partajării resurselor (hardware şi
software) şi a facilităţilor de comunicare.

Caracteristic acestei arhitecturi este faptul că există o singură entitate numită server
şi mai multe entităţi numite client care intră în comunicaţie cu entitatea server prin
intermediul reţelei. Pentru a se putea realiza comunicarea trebuie ca atât clientul cât şi
serverul să utilizeze acelaşi protocol (set de reguli stabilite pentru comunicare).

Caracteristicile serverului:
 este în permanenţă în aşteptarea cererilor din partea clienţilor;
 ascultă reţeaua şi este gata să răspundă cererilor trimise de clienţi;
 dacă primeşte o cerere, o prelucrează şi trimite răspuns clientului care a
trimis cererea.

Caracteristicile clientului:
 este cel care iniţiază comunicarea;
 trimite cereri serverului;
 aşteaptă să primească răspuns de la server.

În contextul SSD arhitectura client-server constituie o soluţie pentru SSD complexe

ce funcţionează în organizaţii de mărime mică, medie care nu sunt localizate geografic pe
arii foarte mari.

Serverul poate fi constituit din nucleul SSD (baza de date, baza de cunoştinţe, baza
de modele, etc.), iar clientii pot constitui diferite componente ale SSD cu
funcţiuni specifice activităţilor de introducere date, interogare, afişare rapoarte, etc.
Clienţii ar putea fi personalizaţi pentru fiecare categorie de utilizatori participantă în
procesul decizional.

În cazul organizaţiilor care se întind pe arii geografice mari, al SSD-urilor

avansate care utilizează tehnologii WEB şi integrează diferite tehnologii specifice
business intelligence consider că este mai potrivită o arhitectură pentru componenta de
comunicare bazată pe modelul TCP-IP.

Modelul TCP-IP de transmitere a datelor în reţea (Internet)

În cazul reţelelor de tip Intranet/Extranet-Internet organizarea acestora se face pe baza

modelului TCP-IP (le voi numi în continuare reţele TCP-IP). Aria de acoperire poate fi mică
în cazul reţelelor LAN (reţele locale) sau poate acoperi întreaga suprafaţă terestră (Internet).

Reţele TCP-IP oferă numeroase servicii utilizatorilor, servicii de care beneficiază

şi sistemele pentru suport al deciziei (SSD-urile hibride, de tip avansat în mod special).

În cadrul reţelelor TCP-IP sunt utilizate protocoale specifice diferitelor sarcini ce

trebuiesc îndeplinite în reţea, din mulţimea acestora două stau la baza acestei
arhitecturi: protocolul TCP (Transmision Control Protocol) şi protocolul IP (Internet
Protocol).

În contextul SSD modelul TCP-IP asigură protocoalele şi serviciile de care

SSD are nevoie pentru a-şi îndeplini cu succes misiunea pentru care a fost creat şi
implementat. În actualul context al exploziei serviciilor bazate pe WEB tehnologia
SSD nu putea rămâne izolată. Astfel au apărut SSD inteligente care integrează la un
nivel ridicat tehnologiile de comunicare orientate către WEB şi tehnologiile
inteligenţei artificiale (figura 9, figura 10).
 Figura 9. Arhitectura SSD orientat către servicii WEB
(preluare din O'Brien, J.A.; Marakas, G., 2007 şi Ref1. Istudor)

Figura 10. Portal cunoştinţe de întreprindere bazat pe servicii WEB

(preluare din O'Brien, J.A.; Marakas, G., 2007 şi Ref1. Istudor)

III.7. Componenta hardware pentru SSD

Componenta hardware a SSD afectează funcţionalitatea şi utilizarea sistemului.

Alegerea hardware-ului poate fi făcută înainte, în timpul, sau după proiectarea

software a SSD.

Ca şi elemente hardware practica a arătat că hardware-ul pentru SSD cuprinde o

paletă largă de opţiuni:
 servere de organizaţie ;
 staţii de lucru;
  calculatoare personale;
 sisteme client / server;
 periferice dedicate;
 soluţii pentru restaurarea şi salvarea datelor de capacităţi mari.

Puterea şi capacităţile reţelei World Wide Web au un impact dramatic asupra

SSD şi aupra hardware-ului dedicat SSD. Acest lucru se reflectă prin:
 hardware dedicat proceselor de comunicare şi colaborare;
 hardware dedicat pentru securitatea reţelei;
 hardware specializat pentru stocarea datelor şi partajarea acestora în reţea;
 surse de alimentare inteligente cu monitorizare prin reţea

IV. Dezvoltarea sistemelor suport pentru decizie

Natura sistemelor SSD necesită o tehnică de construire diferită de cea clasică
folosită pentru sistemele de procesare a tranzacţiilor. Abordările tradiţionale de
proiectare şi construire s-au dovedit nepotrivite deoarece nu există o teorie completă şi
cuprinzătoare a luării deciziilor şi datorită modificărilor rapide în condiţiile mediului
decidenţilor.

Utilizatorii SSD nu pot defini anticipat funcţiile pe care ar trebui să le

îndeplinească sistemul, astfel încât constructorul să le poată implementa în sistem
(Sprague, 1980).

IV.1. Principii de proiectare a SSD

Au fost formulate zece principii pentru proiectarea Sistemelor Suport pentru

Decizii, după cum urmează:
1. Parteneriatului om-calculator. Un SSD asistă şi nu înlocuieşte decidentul
uman. Decidentului uman are ca atribute puterea de conceptualizare, intuiţie şi
creativitate, în timp ce calculatorul oferă viteza de calcul, paralelism, acurateţea şi
stocarea permanentă de informaţii detaliate. Automatizarea ar trebui
restricţionată la:
  monitorizarea activităţilor de rezolvare a problemelor,
 detectarea conflictelor,
 evaluărilor
 executarea secvenţelor de căutare şi planificare.

2. Cooperativ şi distribuit - Sistemul suport pentru decizii poate avea avantajul

unei arhitecturi distribuite, prin care creşte viteza de calcul se pot modifica unele
componente ale sistemului în timp ce sistemul ca un tot unitar continuă să
opereze cu celelalte componente rămase iar funcţionarea parţială sau
nefuncţionarea a unei componente nu afectează întregul sistem.

3. Arhitectură deschisă - Componentele sistemului se pot schimba în timp prin

modificări, înlocuiri, ştergeri sau extinderi. Poate fi posibil să implementăm
aceste schimbări într-o manieră optimă prin programarea interfeţelor folosind
aplicaţii comune şi baze de date partajate.

4. Instrumente şi nu soluţii - Sistemul suport pentru decizii ar trebui proiectat ca

un set de instrumente şi nu ca un set de soluţii la un set de probleme
predeterminat.

5. Reprezentare internă la un nivel îna lt - În acest sens, un instrument este definit

mult mai generic în comparaţie cu o secvenţă de algoritmi sau proceduri care
sunt aplicate în mare măsură în direcţia unui utilizator. Instrumentele se pot auto-
activa, pot avea cel puţin un comportament semi-autonom şi pot coopera cu
alte instrumente şi utilizator în cererea şi furnizarea serviciilor. Abilitatea
unui SSD de a avea un oarecare nivel de înţelegere a semnificaţiei informaţiei pe
care o procesează este cea mai importantă condiţie pentru un mediu de rezolvare
a problemelor de cooperare şi colaborare.

6. Cunoaştere încapsulată - Sistemul suport pentru decizii ar trebui să fie un

sistem bazat pe cunoaştere. În acest context, cunoaşterea poate fi descrisă ca o
experienţă derivată din observare şi interpretarea evenimentelor sau fenomenelor
trecute şi aplicarea metodelor în situaţiile din trecut. Bazele cunoaşterii captează
această experienţă în forma regulilor, studiilor de caz, practicilor standard,
descrierea tipică a obiectelor şi a obiectelor sistem care pot servi ca prototip.
 Aplicaţiile de rezolvare a problemelor tipic, manipulează aceste prototipuri prin
adaptare, rafinare, mutaţie, analogie şi combinare, pe care apoi le aplică soluţiei
problemei curente.

7. Descentralizarea luării deciziei - Sistemul suport pentru decizii nu are nevoie şi

nu ar trebui să exercite un control centralizat în mediul.

8. Accentuarea identificării conflictului - Sistemul suport pentru decizii ar trebui

să se concentreze asupra identificării decât o hotărâre automată a conflictului.

9. Interfaţa calculator-utilizator - Importanţa gradului înalt de interacţiune între

utilizatori şi diverse componente SSD este integrată în majoritatea principiilor
descrise mai sus. Interacţiunea este facilitată de două caracteristici ale
sistemului: o reprezentare a obiectelor la nivel înalt şi o interfaţă utilizator
intuitivă.

10. Integrarea funcţională - În trecut a fost considerat de ajutor, ca planificarea şi

execuţia sa fie văzute ca activităţi distincte. În această concepţie scopul
planificării este să definească clar şi să analizeze problema şi apoi să dezvolte o
soluţie. Pe măsură ce complexitatea şi ritmul situaţiilor de rezolvare a
problemei cresc, aceste aparente arii funcţionale distincte nu mai pot fi
catalogate ca fiind sfere discrete de activităţi operaţionale. Acestea au tendinţa de
a fi comasate într-un singur pol de capabilităţi integrat funcţional din care
decidentul uman poate obţine asistenţă în funcţie de necesităţi. În aceste situaţii
de rezolvare de probleme schimbarea continuă a informaţiilor necesită
replanificare constantă.

IV.2. Strategi de abordare

Strategia descendentă (top-down) are la bază principiul modularităţii şi constă în

descompunerea succesivă a unui sistem complex de sus în jos până la un nivel de
module elementare. Descompunerea urmăreşte structura funcţională a sistemului şi se
finalizează prin identificarea arborelui structurii sistemului cu definirea modulelor
funcţionale pe fiecare nivel ierarhic şi a legăturilor dintre acestea, oferind totodată o
descriere a fiecărei componente a sistemului.

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

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

Se asigură astfel realizarea unei soluţii globale, unitare la nivel conceptual pentru
întregul sistem, componentele acestuia urmând să fie proiectate şi realizate independent,
priorităţile fiind fixate în funcţie de opţiunea beneficiarului sau importanţei respectivelor
componente şi conexiunilor necesare în cadrul sistemului global.

Pe măsura realizării componentelor din arhitectura generală a sistemului informatic

acestea se vor testa şi apoi integra în produsul final a cărui funcţionalitate va fi de
asemenea verificată. Se poate realiza trecerea în exploatare a componentelor finalizate
urmând ca integrarea acestora în sistemul informatic global să se realizeze în timp.
Aplicarea unei astfel de strategii impune un efort deosebit atât în perioada de analiză
(fiind necesară o analiză complexă şi foarte amănunţită având în vedere complexitatea
proceselor informaţionale supuse informatizării) cât şi de proiectare şi realizare, ceea ce
impune eforturi financiare deosebite.

În procesul integrării componentelor în cadrul sistemului informatic global nu vor

apărea probleme deosebite ca urmare a strategiei unitare de proiectare şi realizare
definită la demararea proiectului. Integrarea se va realiza din treaptă în treaptă pornindu-
se de la componentele elementare (cu gradul cel mai mare de detaliere).
Strategia ascendentă (botton-up) are la bază principiul agregării şi constă în
identificarea de jos în sus a componentelor unui sistem şi asamblarea succesivă a
modulelor definite pe diferite nivele ierarhice şi a relaţiilor dintre acestea astfel încât se
ajunge la un singur modul corespunzător sistemului.
Abordarea mixtă reprezintă o combinaţie a celor două strategii prezentate
mai sus (ascendentă şi descendentă) cu scopul de a folosi avantajele celor două
abordări. În această strategie se optează pentru o definire a componentelor sistemului
informatic în conformitate cu cerinţele strategiei descendente, urmând ca proiectarea,
realizarea şi integrarea acestor componente să se realizeze urmând cerinţele strategiei
 ascendente.

IV.3. Ciclul de viaţă şi strategi de realizare

Ciclul de viaţă al unui produs software reprezintă intervalul de timp de la momentul

deciziei de realizare şi până la retragerea sau înlocuirea totală a acestuia cu un nou produs
software.

Ciclul de realizare este o noţiune derivată din cea de ciclu de viaţă acoperind
intervalul dintre momentul deciziei iniţiale de realizare şi până la punerea în funcţiune a
produsului software. Acest interval, împărţit în general în faze, presupune analiza
problemei, proiectarea produsului software, implementarea de cod, testarea şi
experimentarea acestuia, deci reprezintă o parte a ciclului de viaţă şi anume cea care are
ca scop dezvoltarea produsului.

Activităţile componente ale acestuia sunt grupate în mai multe moduri, în etape sau
faze. O astfel de grupare a activităţilor componente ale ciclului de viaţă este prezentată în
tabelul 6 [BRU 95]:

Tabelul 6. Fazele ciclului de viaţă

FAZE OBIECTIVE PRODUSE FINALE

Cerinţe utilizator Definirea problemei Specificaţii cerinţe utilizator
Cerinţe software Analiza problemei Cerinţe şi specificaţii software
Proiectarea arhitecturii Soluţii de ansamblu Proiect de ansamblu
Producţie Implementare Proiect de detaliu,
Software testat
Transfer Instalare Software instalat, training clienţi
Mentenanţă Evoluţie produs software Software întreţinut şi dezvoltat
Modul de grupare al activităţilor percum şi sucesiunea fazelor conduc la diferite
modele de implementare ale ciclului de viaţă.

Un model al ciclului de viaţă pentru produse software descrie activitatea de realizare a

produsului software şi fluxul procesului de dezvoltare. În decursul timpului au fost elaborate
diferite strategii de implementare a conceptului de ciclu de viaţă concretizate în diferite
modele:
 Modelul în cascadă
  Modelul incremental
 Modelul evolutiv
 Modelul în spirală
 Inginerie software bazată pe model

. Modelul în cascadă

DEFINIRE CERINŢE

ANALIZA

PROIECTARE

IMPLEMENTARE COD

TESTARE

UTILIZARE&MENTENANŢĂ

Figura 11. Modelul în cascadă

Un model tipic în cascadă presupune că dezvoltarea începe cu definirea cerinţelor şi

a specificaţiilor, care se pot realiza în secvenţă dar şi alternându-le. Urmează proiectarea
care odată terminată se pot implementa module mici care pot fi testate individual, iar apoi
împreună; când ultimul test de integrare este complet, întregul produs software poate fi
testat şi livrat şi începe faza de mentenanţă (figura 11).

Iniţial a existat ideea că o fază trebuie să fie complet terminată pentru a o începe pe
următoarea. Acest principiu a fost abandonat relativ repede şi s-a convenit ca o fază să
poată începe înainte ca precedenta să fie complet terminată.

În acest model intrările fiecărei faze sunt ieşirile alteia. Feedback-ul e format din
erori care se răsfrâng asupra fazei următoare. Erorile se propagă indirect, în plus intervin
costurile modificărilor fapt ce implică necesitatea testării foarte riguroase a fiecărei faze.

Modelul în cascadă a avut un impact uriaş asupra metodelor ingineriei software şi a fost
repede adoptat, chiar înainte de a fi bine descris. Dacă este utilizat în domenii puţin cunoscute
se poate lucra mult pentru a acoperi cerinţele, uneori găsite prea târziu, situaţie în care, la
nivel conceptual este necesară utilizarea de prototipuri în fazele iniţiale sau de strategii
euristice, după caz. Fazele modelului în cascadă necesită un personal cu pregătire diversă
(analişti, programatori etc.) şi se poate spune că este deci o strategie de implementare aproape
istorică.

. Modelul incremental

Specific acestui model este faptul că etapele finale sunt realizate în mai mulţi paşi
succesivi ceea ce permite obţinerea de versiuni preliminare ale produsului software
(figura12).

Cerinţe utilizator
Cerinţe software
Proiectare arhitecturală

Proiectare de detaliu şi producţie

Transfer
Utilizare şi mentenanţă
timp

Figura 12. Modelul incremental

Modelul incremental are următoarele caracteristici: analiza şi proiectul de ansamblu

(arhitectural) se realizează într-o singură componentă; proiectarea de detaliu, producţia,
transferul şi mentenanţa sunt făcute în mai mulţi paşi succesivi; elaborarea produsului
software în paşi dă posibilitatea verificării dacă producţia va da rezultatele dorite. Modelul
incremental este mai bun decât modelul în cascadă, necesită mai multă organizare, dar
permite versiuni preliminare ale produsului software pe care se pot verifica calităţile
acestuia.

. Modelul evolutiv sau prptotipizare

Comparativ cu modelele precedente, acest model, necesită un management mai

mare, o organizare mai bună. Este foarte util când specificaţiile iniţiale nu sunt foarte
clare sau când se realizează un sistem nou şi nu se pot da specificaţii precise şi complete
sau când acestea sunt instabile. Prin parcurgerea paşilor modelului evolutiv se realizeză
un prototip iniţial care în final prin reluarea etapelor (paşilor) ajunge să satisfacă cerinţele
clienţilor (figura13).
Cerinţe utilizator

Cerinţe software

Proiectare arhitecturală

Proiectare de detaliu şi producţie

Transfer

Utilizare şi mentenanţă

timp

Figura 13. Modelul evolutiv

Modelul evolutiv poate fi aplicat printr-o strategie agresivă (sau revoluţionară) care
ţine cont de cerinţele pieţei în sensul dezvoltării continue de noi produse sau de noi
funcţii, racordate la cerinţele pieţei de produse software.

Bazat pe prototipizare, prin repetarea tuturor fazelor, modelul evolutiv naşte în timp
mai îndelungat un produs, dar permite întotdeauna rezolvarea unor noi probleme sau
includerea de noi funcţii cerute de piaţa utilizatorilor de produse software.

Adaptat la cerinţele pieţei, modelul evolutiv poate produce o soluţie evolutivă sau,
prin strategia agresivă, o soluţie revoluţionară. Prin combinarea acestora şi în funcţie de
studiile de piaţă se poate obţine o soluţie intermediară.

Deoarece modelele precedente folosesc noţiuni ca prototipizare şi prototip, vom

preciza în continuare sensul acestora.

Prototipizarea este o tehnică de construire şi implementare parţială a unui sistem

sau produs software astfel încât cumpărătorul, utilizatorul sau realizatorul să poată învăţa,
cunoaşte mai mult despre problemă şi despre soluţionarea acesteia.
 Prototipul este util pentru utilizatorul final care va înţelege mai bine ce vrea sau ce
se aşteaptă de la produs şi este util pentru realizator pentru a testa unele tehnici, algoritmi
aplicaţi, interfeţe realizate etc.

Referitor la prototip există două abordări :

 prototip de încercare care trebuie să fie rapid, chiar dacă nu perfect şi care
poate fi utilizat pentru validarea interfeţei, pentru particularizarea
arhitecturii pentru a cuprinde cerinţele cât mai bine, sau pentru a valida
algoritmi particulari;
 prototip evolutiv care, dimpotrivă, dezvoltă produsul final astfel încât să se
poată aprecia toate caracteristicile de calitate ale produsului software final;
în general acest prototip nu poate fi rapid, dar permite îmbunătăţirea
modelului prin asigurarea unei calităţi ridicate a produsului software.

. Modelul în spirală

Problemele majore în dezvoltarea produselor software apar, în cele mai multe

cazuri, în faza de mentenanţă care în realitate conţine definirea de noi cerinţe de
specificare, de analiză, de proiectare. Au fost dezvoltate în timp o serie de alte modele
decât cele descrise anterior, cel mai utilizat actualmente fiind modelul în spirală al lui
Boehm care încearcă să soluţioneze problema amintită anterior [JAC 96]. Modelul în
spirală (figura14) poate descrie cum un produs se dezvoltă pentru a forma o nouă
versiune şi cum o nouă versiune se dezvoltă incremental de la un prototip la un produs
complet.
ANALIZĂ

SPECIFICAŢII DE
PROIECTARE
CERINŢE
V1 V2 V3 V4
VERSIUNE
IMPLEMENTARE &
TESTARE FINALĂ
INDIVIDUALĂ

INTEGRARE
 Figura 14. Modelul în spirală

Modelul propune aceleaşi etape de realizare, dar fiecare ciclu de dezvoltare începe
prin studiul de fezabilitate, apoi continuă cu specificarea cerinţelor şi analiza,
proiectarea şi implementarea. Pe de altă parte fiecare din etapele amintite anterior se
realizează printr-o succesiune de activităţi:
 determinarea obiectivelor etapei, a alternativelor şi restricţiilor;
 evaluarea alternativelor, identificarea riscurilor şi rezolvarea lor;
 dezvoltarea şi verificarea următorului nivel al produsului;
 întocmirea planului următoarei etape, ales pe baza riscurilor.

Atât etapele cât şi activităţile lor componente sunt evaluate având drept criteriu de
bază costurile implicate.

Modelul în spirală are următoarele caracteristici:

 conţine aproape toate caracteristicile celorlalte modele;
 celelalte modele pot fi considerate sau sunt cazuri particulare ale acestuia;
 evaluează riscurile oricărei abordări în toate fazele de dezvoltare a
produselor software, iar pe baza acestora alege abordarea corectă.

Dezvoltarea produselor software conţine în mod uzual toate fazele şi activităţile

prezentate anterior, chiar dacă ele poartă diferite nume în diferite metodologii şi
dezvoltarea decurge incremental pe parcursul acestor faze, scenariu de dezvoltare care se
poate aplica indiferent de metoda de realizare utilizată. Putem caracteriza dezvoltarea
produsului ca pornind iniţial dintr-o fază nebuloasă, dar care se stabilizează în următorii
paşi în subsecvenţe. Metodele de dezvoltare trebuie să ajute ca procesul de dezvoltare să fie
stabil pe cât posibil. Se presupune că trebuie lucrat în faza de analiză până când se va
înţelege sistemul în totalitate, dar nu atât de mult încât să considerăm detaliile care vor fi
modificate pe parcursul proiectării.

Iniţial un grup redus de persoane efectuează analiza şi proiectarea. Aceste activităţi

se realizează iterativ. Cu cât structura sistemului se stabilizează, un număr mai mare de
oameni sunt antrenaţi în implementare şi testare. De obicei activităţile de analiză şi
proiectare sunt clarificate atunci când începe testarea, deoarece în acest stadiu nu sunt
posibile decât puţine modificări în ceea ce s-a realizat în faza de analiză şi proiectare.

IV.4. Metodologi de realizare a sistemelor in formatice

Metodologiile de realizare reprezintă un ansamblu de concepte, tehnici de

reprezentare a acestora şi de etape, faze şi activităţi care coordonează realizatorul pe
parcursul ciclului de realizare al sistemului informatic.

De-a lungul timpului s-au conturat două mari clase de metodologi şi anume
matodologi tradiţionale şi metodologi orientate obiect.

IV.1. Metodologi tradiţionale

Majoritatea metodologiilor tradiţionale admit, ca principiu general pentru controlarea

complexităţii, modularizarea. Modularizarea se poate realiza având ca bază:
 descompunerea funcţională;
 structura datelor;
 fluxul datelor;
 abstracţii.

Metodele de descompunere funcţională sunt bazate pe împărţirea sistemului în

subsisteme cu coeziune internă puternică şi interfeţe minime; împărţirea se face pe baza
structurii de funcţiuni a sistemului. Dintre aceste metodologi pot fi amintite metodologia
HIPO (Hierarhycal - Input Proccessing - Output) sau metodologia SADT (Structured
Analysis and Design Technique.

Metodele bazate pe structura datelor consideră că structura programelor este direct

derivabilă din structura datelor. Dintre acestea pot fi amintite metodele LCS (Logique de la
Construction des Systemes) şi LCP (Logique de la Construction des Programes) dezvoltate
de J. D. Warnier în Franţa şi introduse în S.U.A. sub numele de metoda Warnier – Orr sau
metoda Jackson dezvoltată de M. A. Jackson în Anglia.
 Metodele bazate pe fluxul datelor consideră că la baza determinării structurii
programelor se pune fluxul datelor în cadrul problemei. Din această clasă de metode fac
parte metoda de analiza structurata (De Marco), metoda de analiză şi proiectare
structurată, dezvoltată de Yourdon şi Constantine sau metoda de proiectare compozită,
dezvoltată de G. Myers pornind de la proiectarea structurată prin modificarea
terminologiei şi a modului de reprezentare a proiectului.

Metodele bazate pe abstractizare - în cazul în care la baza modularizării stă

abstracţia (ca instrument puternic în vederea reducerii complexităţii), se evidenţiază metoda
lui Parnas - bazată pe principiul ascunderii informaţiei, metoda maşinilor abstracte, iniţiată
de Dijkstra sau metoda maşinilor cu stări, folosită de Compania IBM.

Toate metodele enumerate au câteva caracteristici comune:

 oferă criterii de evaluare a analizei şi proiectării;
 propun tehnici de reprezentare a sistemului în diferite etape de realizare,
care permit comunicarea uşoară şi neambiguă între participanţi;
 impun structurarea şi modularizarea sistemului;
 utilizează modele de sistem (logice şi fizice).

IV.2. Metodologi orientate obiect

Spre deosebire de metodele tradiţionale, metodele orientate obiect propun modelarea

concomitentă a celor două tipuri de structuri, de date şi de prelucrări, în vederea obţinerii unei
ierarhii de clase de obiecte care înglobează atât date cât şi comportament.

Modelarea orientată obiect reprezintă un alt mod de gândire şi de abordare a

problemelor, utilizând modele pentru a căror construire se folosesc concepte din lumea
reală. Modelele orientate obiect sunt importante pentru: înţelegerea problemei, descrierea
corectă şi completă a sistemului, comunicarea cu utilizatorul final, proiectarea
programelor şi bazelor de date, precum şi pentru pregătirea şi elaborarea documentaţiei.
Cu alte cuvinte orientarea obiect, ca metodă, îşi propune rezolvarea dificultăţilor ce apar
în dezvoltarea aplicaţiilor software în cel puţin două momente ale acestui demers, şi
anume la trecerea descrierii problemei din limbajul specific domeniului aplicaţiei într-un
limbaj formalizat, specific domeniului informatic şi la trecerea din descrierea problemei
utilizând limbajul formalizat (grafic, textual sau mixt) într-un limbaj de programare.

Premizele apariţiei orientării obiect, ca filozofie, derivă din următoarele aspecte:

- necesitatea unor schimbări în metodele şi tehnicile de elaborare a produselor
software cerute de costul ridicat şi calitatea acestora, precum şi de timpul
necesar pentru dezvoltare, de uşurinţa în înţelegere, modificare şi întreţinere;
- dezvoltarea şi răspândirea analizei, proiectării şi programării structurate a
pregătit trecerea către modelarea orientată obiect, care a preluat iniţial unele
din conceptele metodelor tradiţionale;
- s-a produs o schimbare în privinţa orientării aplicaţiilor dinspre date spre
proceduri în scopul prelucrării eficiente a datelor prin intermediul unor
algoritmi performanţi (calcul paralel, reţele neuronale etc.);
- pe lângă evoluţia din domeniul metodelor şi tehnicilor de dezvoltare, filozofia
orientării obiect a apărut şi datorită progreselor înregistrate în domeniul
hardware-ului şi în cel al limbajelor de programare;
- necesitatea de a avea interfeţe cu utilizatorul simple, prietenoase, lucrul cu
ferestre şi utilizarea mouse-ului au avut ca urmare faptul că un procent
semnificativ dintr-un cod sursă (aproximativ 70%) îl reprezintă elemente de
interfaţă. Spre deosebire de metodele tradiţionale, cele orientate obiect oferă
suport pentru modelarea interfeţelor cu utilizatorul.

Orientarea obiect reprezintă un mod de gândire abstractă asupra problemelor reale.

Un principiu de bază în modelarea orientată obiect este independenţa de orice limbaj de
programare, scopul modelelor orientate obiect fiind înţelegerea mai bună a cerinţelor
beneficiarilor şi comunicarea cu aceştia.

Această abordare este potrivită pentru proiectarea şi construirea sistemelor suport

pentru decizii (Filip, 2004).

IV.5. Etapele procesului de dezvoltare a unui SSD

Conform lui Filip (2004, procesul de dezvoltare a unui SSD se realizează în mai multe
etape:
 - iniţierea şi pregătirea proiectului;
- analiza de sistem;
- proiectarea tehnică;
- implementarea;
- exploatarea şi evoluţia

A. Iniţierea şi pregătirea proiectului - începe cu apariţia ideii de introducere a SSD în

organizaţie şi se finalizează cu decizia de realizare a unui proiect şi alocarea resurselor şi
responsabilităţilor în acest sens. Paşii parcurşi în această etapă sunt următorii:

 generarea ideii introducerii unui SSD în organizaţie (de unul sau mai mulţi
decidenţi)
 diagnosticarea situaţiei actuale:
- identificarea imperfecţiunilor modului de desfăşurare a activităţilor decizionale
- prezentarea oportunităţilor şi modalităţilor de schimbare şi îmbunătăţire.
 definira caracteristicilor sistemului:
- utilizatorul,
- funcţiile,
- tipul de suport,
- orientarea tehnologică a sistemului,
- sursele şi fluxurile de date,
- performanţele tehnice principale
- beneficiile aşteptate.

După realizarea unui studiu de fezabilitate se trece la realizarea planului proiectului (pe
faze, indicându-se pentru fiecare fază: timpul, rezultate aşteptate, persoanele implicate
şi resursele alocate).

B. Analiza de sistem - urmăreşte elaborarea specificaţiilor funcţionale de detaliu pentru

sistem şi identificarea setului de instrumente informatice care ar putea fi folosite în
construirea SSD. Paşii sunt următorii:
 culegerea, analiza şi prelucrarea datelor implicate
 definirea specificaţiilor funcţionale de detaliu care conţin:
- funcţiunile care urmează a fi realizate,
 - modul de desfăşurare a dialogului
- forma în care se va realiza controlul asupra sistemului pentru a răspunde
caracteristicilor sarcinilor şi particularităţilor decidentului.
 identificarea şi inventarierea instrumentelor informatice care ar putea fi folosite
în construirea SSD.

C. Proiectarea tehnică - se proiectează efectiv sistemul în ansamblu şi componentele

sale, din punct de vedere al tehnologiei informatice, conţinutul specificaţiei de definire
fiind transpus într-un proiect de execuţie.

Modul de realizare a SSD depinde foarte mult de instrumentul informatic ales

pentru a fi folosit şi de momentul alegerii acestuia: la începutul sau la sfârşitul
etapei de proiectare. Acest instrument ar putea uşura sau îngreuna procesul de realizare,
în funcţie de facilităţile şi limitările acestuia, dacă este ales la începutul etapei.

În general, alegerea instrumentului se face la început-ul etapei de proiectare,

când se utilizează suite software modulare sau generatoare de SSD. Folosirea lor ar
putea duce la scurtarea timpului de realizare dar şi la o pierdere din flexibilitate.

Când alegerea se face la sfârşitul etapei de proiectare şi proiectarea este

independentă de un instrument anume, soluţia poate fi consistentă şi să poată permite
adaptări ulterioare. Timpul de execuţie, în acest caz, este mai mare şi uneori ar
putea apărea dificultăţi în etapa de construire propriu-zisă. În acest caz, de obicei,
se optează pentru instrumente de uz general ca limbaje de programare, sisteme de
gestiune a bazelor de date etc.

D. Implementarea –

 realizare propriu-zisă a SSD-ului - depinde foarte mult de instrumentul

informatic ales. În cazul folosirii unor suite software modulare sau a unor
generatoare de SSD, activitatea constă în personalizarea pe aplicaţie a
instrumentului informatic ales. Timpul de realizare, în acest caz, poate fi destul
de scurt şi fără foarte mare efort. În cazul folosirii unor instrumente primare de
uz general, eforul şi timpul de realizare de realizare sunt mult mai mari.

 integrarea SSD-ului în sistemul informatic global al organizaţiei,

  testarea şi validarea SSD-ului – testarea are ca scop aprecierea corectitudinii
transpunerii informatice a conţinutului proiectului tehnic. Validarea urmăreşte să
determine modul în care sistemul implementat satisface scopul propus şi
aşteptările utilizatorului. În cazul constatării unor probleme, se revine la unele
activităţi anterioare pentru rezolvarea acestora. În această etapă are loc şi o
testare de către utilizator (test de acceptare), pentru a obţine validarea de către
acesta.

 elaborarea documentaţiei (manualul de utilizare şi manualul de întreţinere)

 instruirea utilizatorilor.

E. Exploatarea şi evoluţia - După finalizarea produsului şi elaborarea documentaţiei, se

poate trece la exploatarea sistemului. Dacă sistemul va fi folosit şi de alţi utilizatori
decât cei care l-au testat deja în etapa anterioară, se realizează o instruire a acestora.

V. Sisteme suport pentru decizii de grup

Sistemele suport de grup sau sistemele suport pentru decizii de grup reprezintă
un tip de sisteme care susţin activităţile desfăşurate de decidenţi în grup.

Termenul de grup se referă la două sau mai multe persoane a căror misiune este
aceea de a îndeplini nişte obiective şi care se comportă ca o echipă. Grupul poate avea
caracter permanent sau temporar. Grupul se poate afla într-o singură locaţie sau poate fi
distribuit, membri grupului se pot întâlni simultan sau la diferite momente de timp.

Chiar dacă cele mai multe companii sunt de tip ierarhic, luarea deciziei este un
proces colectiv. Grupul poate fi implicat în luarea unei decizii cum ar fi crearea unei
scurte liste de alternative sau alegerea criteriilor pentru acceptarea unei alternative.
Aceste întâlniri sunt caracterizate de următoarele activităţi şi procese:
 Întâlnirile sunt o activitate comună, agreată de un grup de persoane, de
obicei având un statut egal sau aproape egal.
 Rezultatele întâlnirii depind într-o oarecare măsură de cunoaşterea,
opiniile şi judecata participanţilor.
  Rezultatele întâlnirii de asemenea depind de componenţa grupurilor şi de
procesul de luare a deciziilor folosit de grup.
 Diferenţele de opinii sunt rezolvate, de obicei, prin negociere.

Conform lui Turban şi Aronson (Decision Support Systems and Intelligent

Systems, 1998), grupul decidenţilor este asistat de un lider care planifică întâlnirile,
coordonează activităţile echipei de asemenea ca facilitator ale cărui responsabilităţi
sunt să accepte promovarea utilizării tehnicilor de rezolvare a problemelor şi
încurajează atingerea consensului.

Beneficiile tipice a unei astfel de colaborări au fost sintetizate de Turban (2001):

 Grupurile sunt mai bune ca decidenţii individuali în înţelegerea problemei
 Decidenţii sunt responsabili pentru deciziile la care au participat
 Grupurile sunt mai bune ca decidenţii individuali în identificarea erorilor
 Un grup deţine mai multe informaţii, cunoştinţe, decât oricare decident. Grupurile
pot combina acea cunoaştere ca să creeze o cunoaştere nouă. Ca şi rezultat, sunt
mai multe alternative pentru rezolvarea problemei, astfel pot fi obţinute soluţii
mai bune.
 În procesul de rezolvare a problemei poate apărea sinergia
 Lucrul colaborativ poate stimula participanţii
 Decidenţii se implică în luarea decizie, ceea ce conduce la un grad mai ridicat
al satisfacţie cu procesul decizional.
 Tentaţia spre riscuri este echilibrată. Grupurile îi temperează pe cei care de
obicei îşi asumă riscuri mari sau pe de altă parte îi încurajează pe conservatori.

Cu toate că există multe beneficii ale interacţiunii în grup rezultatele nu sunt

întotdeauna încununate de succes. Motivul este acela că procesul decizional colaborativ
este supus unor numeroase disfuncţii:
 Presiune socială pentru conformare poate determina ca decidenţii să susţină
ideile comune iar cele noi să nu fie acceptate.
 Procesul este unul lent şi consumator de timp.
 Lipsa de coordonare a muncii făcute de grup şi planificarea deficitară a
întâlnirilor
  Influenţe neadecvate cum ar fi: dominarea timpului, subiectului, opiniilor de
către una sau mai multe persoane; frica de exprimare.
 Tendinţa membrilor grupului de a se baza pe alţii pentru a îndeplini toate
sarcinile
 Inclinaţia spre soluţii de compromis, de proastă calitate
 Analiza obiectivelor incompletă
 Timp neproductiv: socializare, pregătirile preliminare, aşteptarea participanţilor
 Tendinţa de a se repeta ceea ce s-a mai spus.
 Costuri mari pentru luarea deciziilor, datorate duratei întâlnirii şi cheltuielilor de
deplasare.
 Tendinţa grupurilor de a lua decizii cu un grad de risc mai mare decât ar trebui.
 Utilizarea neadecvată sau incompleta a informaţiei.
 Reprezentarea neadecvată în cadrul grupului

În afara cazului în care grupul se întâlneşte în acelaşi loc şi în acelaşi timp, pot
exista situaţii în care membrii grupului se află în locaţii diferite sau participă la întâlnire
în momente de timp diferite. Aceste probleme pot fi depăşite cu ajutorul Internetului.

Succesul limitat al metodelor prezentate a determinat la încercări de a folosi

tehnologia informaţiei pentru a asista întâlnirile de grup. Cea mai importantă tehnologie
se numeşte Sisteme Suport pentru Decizii de Grup.

SSDG a evoluat pe parcurs ce cercetătorii din tehnologia informaţiei au identificat

că tehnologia poate fi dezvoltată pentru a sprijini o mulţime de activităţi ce în mod
normal se petrec în cadrul întâlnirilor, cum ar fi: generarea de idei, ajungerea la un
consens, votare şi evaluare anonimă.

Iniţial au fost două abordări:

- cea influenţată de ştiinţelor sociale şi construită pe teorii sociologice şi cognitive
pentru a identifica eficacitatea tipurilor de instrumente eficiente;
- cea inginerească care prin analiza modului de interacţione dintre participanţi au
condus la implementarea unor programe pentru a îmbunătăţi eficcacitatea
grupului.
În timp ambele abordări s-au contopit în cercetarea SSDG de azi .
 SSDG, după DeSanctis şi Gallupe, este un sistem informatic interactiv care
facilitează abordarea problemelor nestructurate de către un grup de persoane.

Ca şi componente, SSDG include

 echipament hardware,
 instrumente software,
 oameni
 proceduri.

Ca şi caractestici generale:
 SSDG trebuie să îmbunătăţească procesul de luare a deciziei sau rezultatele
obţinute de grup.
 SSDG trebuie să fie uşor de învăţat şi de utilizat
 SSDG poate fi proiectat pentru un anumit tip de problemă sau pentru o
varietate de decizii organizaţionale la nivel de grup.
 SSDG este proiectat pentru a încuraja activităţile colaborative precum
generarea ideilor, rezolvarea conflictelor, libertate de exprimare.
 SSDG trebuie să ofere mecanisme ce descurajează dezvoltarea unor
comportamente de grup negative cum ar fi conflicte, lipsa de comunicare
sau alinierea la o idee comună.

Scopul SSDG este de a îmbunătăţi productivitatea şi eficienţa întâlnirilor decizionale,

fie prin micşorarea duratei procesului de luare a deciziei, fie prin îmbunătăţirea calităţii
rezultatelor deciziei. SSDG caută să crească beneficiile lucrului în grupuri şi să micşoreze
disfuncţiile.

Ca şi avantaje ale SSDG avem:

 Suportă procesarea paralelă a informaţiei şi generarea ideilor de către
participanţi (procesarea paralelă umană)
 Oferă posibilitatea grupurilor numeroase să participe în cadrul aceleaşi
întâlniri
 Permite grupului să folosească tehnici şi metode structurate sau
nestructurate pentru a îndeplini obiectivul propus
 Rezultatele pot fi consultate imediat.
  Înregistrează toată informaţiile relevante care au condus la o anumită
decizie, pentru a putea fi analizate ulterior (memoria grupului)
DeSanctis şi Gallupe descriu suportul oferit de tehnologia SSDG pe 3 nivele în funcţie de
modul în care ajută grupul la luarea deciziilor.

 Nivelul 1: Sprijin oferit procesului: Obiectivul acestui nivel este de a reduce sau a desfiinţa
barierele din comunicare. Ca şi exemple de funcţionalităţi oferite la acest nivel ar fi:

- Mesageria electronică.
- Reţeaua care să facă legătura între membrii grupului, facilitator, ecranul public,
serverul care deţine baza de date.
- Un ecran public care să fie la îndemâna fiecărui membru sau să fie plasat într-o
poziţie centrală pentru a fi vizibil pentru toţi participanţii.
- Introducerea de idei şi evaluări într-un mod anonim pentru a spori gradul de
participare a membrilor grupului ce preferă anonimitatea.
- Solicitarea ideilor şi voturilor din partea fiecărui membru pentru a încuraja
participarea şi a stimula creativitatea.
- Rezumarea şi afişarea ideilor şi opiniilor, incluzând analize statistice şi eventual
afişarea pe ecranul public.
- Un format pentru agenda întânirii care să fie agreată de grup
- Afişarea continuă a agendei şi a altor informaţii, pentru a se putea respecta
planificarea întâlnirii.
 Nivelul 2: Sprijin oferit luării deciziei: La acest nivel sistemul software adaugă posibilităţi
pentru modelare şi analiza deciziei. SSDG încearcă să reducă nesiguranţa procesului de luare
a deciziilor prin furnizarea unor metode de structurare pentru sprijinirea sarcinilor specifice.
Ca exemple de funcţionalităţi oferite la acest nivel ar fi:
- Modele de planificare

- Arbori de decizie

- Modele pentru evaluarea probabilităţilor

- Modele pentru alocarea resurselor

Astfel de modele pot exista în pachetele SSDG obişnuite şi pot fi adăugate la software-ul
destinat nivelului 1.
 Nivelul 3: Reguli de funcţionare: În cadrul acestui nivel se doreşte controlarea
timpului alocat, a conţinutului, a interacţiunii dintre decidenţi. Spre exemplu anumite
reguli pot determina secvenţa intervenţiilor, modul de votare.

Tehnologii folosite pentru SSDG

În continuare vor fi prezentate componentele unui SSDG.

Hardware: Pot fi folosite câteva tipuri de configuraţii hardware:
 Un singur calculator: Participanţii utilizează un singur calculator care va
înregistra opiniile şi evaluările dedidenţilor iar SSDG va ajuta la
consolidarea răspunsurilor. Un astfel de sistem aduce însă beneficii
minime.
 Reţea de calculatoare sau calculatoare portabile. Cele din urmă sunt mai
uşor de manevrat dar reduc productivitatea decidenţilor mai puţin
familiarizaţi cu utilizarea unui astfel de sistem.
 Camera pentru decizii, o sală special proiectată pentru întâlniri.
 SSDG distribuite: Participanţii se află în locaţii diferite dar care accesează
prin internetului SSDG, această configuraţie devenind cea mai frecventă.
Software: Software-ul destinat SSDG include module care sprijină decidentul,
grupul, procesul şi obiectivele deciziei de grup. Spre exemplu, software-ul poate include
rutine speciale care să îmbunătăţească procesul de luare a deciziei împreună cu interfeţe
uşor de utilizat. Software-ul permite participanţilor să lucreze individual.
Facilităţi pentru grup sunt:
 Rezumate numerice şi grafice a ideilor şi voturilor.
 Programe pentru: calcularea valorilor atribuite ca importanţă
alternativelor, înregistrarea anonimă a ideilor, alegerea formală a
conducătorului de grup, runde progresive de votare pentru atingerea
consensului, eliminarea informaţiei redundante în cadrul sesiunii de
brainstorming.
  Transmiterea de date şi text între membri grupului, între facilitator şi
membrii grupului şi între membri grupului şi o unitate centrală de
stocare a informaţiilor.
Persoane: La această componentă intră membri grupului şi facilitatorul.
Facilitatorul are rolul de a ghida grupul folosind componentele hardware şi software ale
SSDG.
Proceduri: Procedurile permit utilizarea eficientă a tehnologiei de către membri
grupului. Aceste proceduri pot fi aplicate doar la folosirea componentelor hardware şi
software sau pot fi extinse pentru a cuprinde reguli cu privire la discuţiile verbale între
decidenţi şi modul în care
evenimentele se petrec în cadrul întâlnirilor.

Camera pentru decizii

O astfel de sală are de obicei între 12 şi 30 de calculatoare. La server este ataşat un

ecran public care este conectat la reţea şi pe care pot fi afişate informaţii de la fiecare
calculator.
Utilizarea unor astfel de săli de obicei necesită implicarea unui facilitator. Succesul
oricărui SSDG depinde în mare măsura de activităţi şi de sprijinul oferit de facilitator.
Camera pentru decizii, deşi extrem de folositoare, este folosită de foarte puţine
organizaţii deoarece:
 Este necesară o investiţie majoră.
 Trebuie implicat un facilitator bine pregătit.
 Software-ul este proiectat pentru a ajuta la depăşirea conflictelor, cum ar fi
alocarea resurselor. Astfel este foarte important să fie oferite facilităţi
precum votarea, negocierea, anonimatul contribuţiilor, rezolvarea
conflictelor. Totuşi o mare măsură din efortul grupului implică mai mult
cooperare decât managementul conflictului. Altfel, sistemul poate conduce
la neutilizarea lui.
 Din ce în ce mai multe activităţi decizionale colective se realizează când
membrii grupului se află în locaţii diferite şi în momente de timp diferite.
Pentru a utiliza o camera pentru decizii, toţi participanţii trebuie să fie în
 acelaşi loc şi în acelaşi moment de timp. Acest lucru poate fi costisitor,
consumator de timp şi nefezabil.
 În unele organizaţii este posibil ca în acelaşi timp să se desfăşoare mai multe
întâlniri, astfel ar fi necesară utilizarea mai multor camere pentru decizii.
 Ultimele dezvoltări ale programelor pentru SSDG permit ca membri grupului
să lucreze împreună prin intermediul internetului, astfel se elimină nevoia unei
săli special amenjate pentru luarea deciziilor de grup.

Generarea ideilor

Prin definiţie generarea de idei in SSDG este un efort colaborativ. O idee a unei
persoane declanşează o alta idee a unei alte persoane care la rândul ei declanşează alte
idei, practic se generează un lanţ de idei. Cu ajutorul instrumentelor electronice persoana
este cea care gândeşte şi instrumentul software care sprijină acest proces. Asta deoarece li
se permite participanţilor să-şi exprime opiniile într-un mod în care li se păstrează
anonimatul, păreri care în cadrul unei întâlniri s-ar evita exprimarea lor.
Datorită ideilor generate de fiecare participant, se facilitează astfel efectul de
sinergie în cadrul grupului şi apariţia unor idei creative. Rezultatele sesiunilor de
generare a ideilor pot fi înregistrate electronic, astfel pot fi folosite în cadrul unor întâlniri
viitoare pentru a spori creativitatea altor persoane.
Cercetările cu privire la cum ar trebui un grup să se organizeze pentru a genera idei
arată că un grup care e asistat de un SSDG generează mai multe idei de o calitate mai
bună ca acelaşi număr de participanţi lucrând individual sau în grupuri mai mici.

Desfăşurarea unei întâlniri asistate de SSDG

În continuare sunt prezentate etapele unei întâlniri asistate de SSDG:

a. Pentru început liderul grupului se întâlneşte cu facilitatorul pentru planificarea

întâlnirii, alegerea instrumentelor software şi stabilirea agendei întâlnirii.
b. Participanţii sunt adunaţi în camera pentru decizii şi liderul pune o întrebare
grupului.
c. Participanţii îşi introduc ideile şi comentariile, rezultatele fiind făcute public.
Deoarece participanţii pot observa ideile şi comentariile celorlalţi participanţi,
pot să comenteze în mod pozitiv sau negativ ce s-a scris înainte.
 d. Facilitatorul utilizând instrumentul pentru organizarea ideilor, caută subiectele şi
ideile comune pe care le organizează în categorii cu comentariile aferente.
e. Liderul începe o discuţie verbală sau electronică. În acest moment participanţii
evaluează ideile.
f. Primele 5 până la 10 subiecte sunt introduse în instrumentul pentru generarea
ideilor, după ce au fost mai întâi discutate.
g. La final procesul descris poate fi repetat (generarea, organizarea şi evaluarea
ideilor) sau poate fi dat un vot final.
Întâlnirile care se produc în locaţii diferite şi la momente de timp diferite au devenit o
abordare standard datorită creşterii gradului de acces la internet. Se cunoaşte însă destul de puţin
despre cea mai eficace modalitate de desfăşurare a întâlnirilor distribuite.

Metode

Dacă se elimină sau se micşorează unele disfuncţii, beneficiile deciziilor de grup

sunt sporite. Experţi din cadrul mai multor domenii (sociologie, psihologie etc.) au
dezvoltat câteva metode pentru a rezolva aceste probleme. Unele metode sunt numite
„dinamici de grup”. În continuare sunt prezentate câteva metode.
Metoda nominală: Este una dintre metodele manageriale cele mai răspândite care
include o secvenţă de activităţi în procesul de luare a deciziei:
 generarea ideilor în scris
 punerea ideilor pe o foaie
 discutarea ideilor în serie
 scrierea priorităţilor şi evaluarea lor în scris
 discutarea priorităţilor
 reevaluarea priorităţilor în scris
Procesul este bazat pe cercetări socio-psihologice, care indică că această procedură
este superioară discuţiilor de grup convenţionale cu privire la obţinerea unor avantaje,
cum ar fi calitate superioară, cantitate mai mare de idei exprimate, îmbunătăţirea
distribuirii informaţiei pentru stabilirea obiectivelor.
Succesul acestei metode şi a metodelor similare depind în mare măsură de
capacitatea facilitatorului şi de calitatea instruirii oferite participanţilor. De asemenea
această metodă nu
rezolvă câteva din disfuncţiile procesului de luare a deciziei în grup, cum ar fi: teama de a
vorbi, organizarea şi planificarea slabă a întâlnirilor, compromisurile, lipsa unei analize
adecvate.
Metoda Delphi: A fost dezvoltată de RAND Corporation, destinată procesului de
luare a deciziilor de către grupuri de experţi. Scopul acestei metode este de a elimina
efectul nedorit dat de interacţiunea dintre membri grupului. Experţii nu se cunosc între ei.
Metoda începe prin scrierea unor opinii, de câtre fiecare expert, cu privire la problema
discutată, împreună cu argumente sau presupuneri care să le susţină. Aceste opinii sunt
date câtre coordonator care editează, clarifică şi face un rezumat al datelor primite.
Aceste opinii sunt furnizate ca şi feedback la toţi experţii împreună cu a doua rundă de
întrebări. Întrebările şi feedback-ul continuă în scris pentru câteva runde, devenind din ce
în ce mai specifice, până când se ajunge la un consens sau până când experţii nu-şi mai
modifică poziţia.
Metoda Delphi beneficiază de anonimitate, diversitatea opiniilor şi comunicarea
între membrii grupului. În acelaşi timp se evită câteva efecte negative (comportament
dominant, gândirea asemănătoare între membri grupului, încăpăţânare etc.) care de obicei
apar în cadrul unei întâlniri.
Metoda are câteva limitări: este lentă, costisitoare şi de obicei limitată la o singură
problemă în acelaşi timp.

Decizii multicriteriale apar atunci când alegerea unei alternative sau a unui plan de
acţiune se realizează în condiţiile în care decidentul trebuie să considere, în acelaşi timp,
mai multe obiective. Acestea sunt, de multe ori, de naturi diferite şi pot fi în contradicţie
unul cu altul. În situaţiile decizionale care implică existenţa unor decizii multicriteriale se
pot distinge 2 tipuri de probleme (:Filip, F.G., Asistarea deciziilor cu calculatorul, Ed
Tehnica, Bucuresti, 2002)
Probleme cu număr limitat de alternative discrete (existente şi identificate sau
proiectate), ca de exemplu, alegerea locului de petrecere a concediului, selectarea unui
programator nou.
Probleme cu spectru continuu de alternative (generate de un mecanism
algoritmic de căutare-evaluare), ca de exemplu, determinarea nivelului stocurilor, a
ritmurilor de producţie dintr-o rafinărie. În toate aceste situaţii, variabilele de decizie iau
valori în cadrul unui domeniu limitat de restricţii.
Metodele de rezolvare ale problemelor decizionale cu spectru discret de
alternative formează analiza deciziilor multi-atribut. În cazul rezolvării problemelor cu
spectru continuu de alternative, se vorbeşte despre metode de decizie multi-obiectiv.

Votarea

Ca metodă de luare a deciziei de grup exprimând voinţa majorităţii, votarea este un

proces decizional multicriterial în care un decident îşi exprimă opţiunea prin selectarea
unui candidat sau a unei alternative decizionale.
Există două sisteme fundamentale de votare: voturile neprioritizate în care fiecare
decident îşi exprimă un vot unic şi votarea preferenţială în care votantul indică ordinea în
care ar dori să plaseze candidaturile.
Primul sistem de votare este indicat atunci când numărul votanţilor este egal cu doi,
iar al doilea sistem în caz contrar, fiind necesară protejarea minorităţii şi extinderea
reprezentativităţii peste un spectru rezonabil de interese.
Bui (1993) enumără trei motive pentru a incorpora mai mult de o singură tehnică de
decizie în cadrul SSDG (Bui, T.X., Co-oP: A Group Decision Support System for
Cooperative Multiple Criteria, Group Decision Making, Lecture Notes in Computer
Science, No. 290. Springer Verlag: Berlin, 1993):
 există de obicei două formate de ieşire ale programelor pentru decizii multi-
criteriale folosite de un decident:
- matricea relaţiei de ordonare (ex.: Electre).
- sub forma unui vector al preferinţelor ordonat sau cardinal (ex.: AHP), este cel
mai comun
Nici una din metodele de agregare a preferinţelor cunoscute în literatură nu pot să
satisfacă toate cele cinci condiţii impuse de teorema imposibilităţii a lui Arrow (1963).
Combinaţia diferitelor metode ar putea cel puţin să fie utilizată ca o încercare de a
reduce impactul neajunsurilor unei anumite metode.
 Combinaţia diferitelor tehnici pot să crească şansa de consens, sau cel puţin
constituie o bază mai puţin fragilă pentru negociere.
În afara votului majoritar, zece algoritmi pentru agregarea preferinţelor individuale
sunt evidenţiate în management. Aceste metode pleacă de la următoarele premize: toţi
participanţii partajează acelaşi set de alternative, însă nu în mod necesar şi acelaşi set de
criterii de evaluare şi înainte de a începe procesul decizional de grup, fiecare participant
trebuie să facă propria evaluare a preferinţelor.

Funcţionalităţile oferite de sistemele comerciale

Facilitate.com
Acest pachet software include următoarele instrumente:
A. Brainstorming
Oferă o modalitate electronică pentru generarea ideilor. Se pot adăuga oricât de multe idei de la
un număr nelimitat de participanţi. De asemenea se pot adăuga comentarii la ideile generate.
Ideile pot conţine text, fişiere cu date sau imagini sau adrese de email. Ideile pot fi trimise în mod
anonim sau nu.
B. Categorizing & Organizing
Pentru a rezolva o problemă nu este suficient să colectăm idei bune. Cu ajutorul acestui
instrument putem organiza ideile pe diferite categorii.
C. Voting & Prioritization
Luarea deciziilor implică evaluarea ideilor şi ajungerea la un consens. Acest instrument ne oferă
posibilitatea de a vota o listă de idei. Se pot alege unul sau mai multe criterii şi diferite moduri de
votare. Rezultatele sunt accesibile instantaneu şi pot fi uşor exportate într-o altă aplicaţie.
D. Action Planing
Un rezultat important al unei întâlniri constă în transformarea lor în acţiuni. Acest instrument
oferă posibilitatea de a materializa concluziile unei întâlniri în planuri de acţiune cu roluri,
responsabilităţi şi termene limită. Odată ce a fost dezvoltat planul de acţiune acesta poate fi
modificat de către participanţi până când acesta se finalizează.
E. Survey
Cu acest instrument se pot construi foarte uşor şi rapid chestionare. Acestea pot fi compuse din
mai multe întrebări şi oferă posibilitatea ca răspunsurile să fie anonime. Chestionarele sunt
distribuite pe internet. Rezultatele sunt accesibile în orice moment.
F. Document
De obicei se aşteaptă foarte mult timp până când se elaborează documentele ce cuprind
informaţiile din cadrul întâlnirii Acest instrument elimină acest neajuns prin crearea de rapoarte
în format electronic care pot fi accesate de către oricine, într-un timp foarte scurt de la terminarea
întâlnirii.
G. Chat
Cu ajutorul acestui instrument se poate interacţiona foarte rapid trimiţându-se mesaje instantaneu,
fie pentru a discuta o problemă sau doar pentru a comunica.

Meetingworks.com
Acest pachet software include mai multe instrumente:
A. Generate:
Acest instrument ajută participanţii la întâlnire să genereze idei, este instrumentul folosit pentru
brainstorming. Participanţii introduc ideile accesând propriul calculator, ideile fiind afişate pe un
ecran public. Modul de utilizare a acestui instrument poate fi controlat: în funcţie de timp, limitat
la un anumit număr de idei după dorinţa facilitatorului, sau poate să nu fie impusă nici o limită.
Această decizie de limitare este luată în timpul planificării întâlnirii iar agenda va reflecta acest
lucru. Ideile pot fi generate pentru diferite subiecte. Subiectul pentru care se generează idei la un
anumit moment poate fi controlat de facilitator sau de participant. Facilitatorul are în grijă
supravegherea sistemului software, respectarea agendei întâlnirii, salvarea rezultatelor,
interacţionea din cadul grupului. Când facilitatorul controlează subiectul pentru care se generează
idei, toţi participanţii sunt focalizaţi pe acelaşi subiect iar toate ideile vor apărea pe ecranul public
în momentul în care acestea sunt trimise de participanţi. Când participanţii controlează subiectul
pentru care se generează idei, acestora le este prezentată lista întreagă de subiecte iar aceştia
trimit idei cu referinţă la subiectul dorit. Ideile trimise pentru diferite subiecte apar în ferestre
separate pe ecranul public.
B. Organize:
Cea mai mare provocare a participanţilor este aceea de a transforma o listă de elemente într-un set
de rezultate coerente, acest lucru se realizează prin discuţii, modificări şi organizarea listei cu

idei. Spre deosebire de instrumentele generate şi evaluate, participanţii nu-şi utilizează propriile

calculatoare în schimb ei lucrează ca o echipă pentru a ajunge la un consens. Facilitatorul

ghidează grupul pe toată perioada procesului de organizare a ideilor, iar facilitatorul utilizează
instrumental organize pentru a afişa deciziile grupului. Instrumentul organize procesează listele

în doua moduri: „Discussion” şi “Outliner”.

În modul „Discussion” fiecare element apare în fereastra de discuţii şi este analizat pentru
claritate, unicitate şi potrivire. Elementul poate fi editat sau reformulat.
In modul „Outliner” relaţiile între elementele clarificate sunt identificate iar elementele sunt
grupate împreună. Mai multe metode sunt puse la dispoziţie pentru a realiza aceste lucruri,
permiţând grupului o mare flexibilitate.
Facilitatorul poate utiliza ambele metode şi poate comuta între ele. Rezultatele obţinute sunt clare
şi structurate.
C. Evaluate:
Acest instrument furnizează diferite metode prin care participanţii pot evalua elementele dintro
listă. De asemenea participanţii îşi pot argumenta evaluarea făcută pentru un anumit element.
Participanţii trimit evaluările şi argumentele, acestea vor fi afişate pe ecranul public. Toate
argumentele trimise de participanţi sunt afişate în timpul discuţiei rezultatelor, păstrând
anonimitatea respondentului. Rezultatele evaluării sunt prezentate sub formă de grafice şi tabele.
D. Cross Impact:
Instrumentul este folosit pentru a compara două liste. Una din cele două liste poate conţine idei
iar cealaltă poate fi o listă cu criterii. Rezultatul este tot o lista. Rezultate pot fi vizualizate sub
formă de grafice.
E. Multiple Criteria Analysis:
O listă de elemente cum ar fi soluţii, proiecte, angajaţi sunt evaluate potrivit unei liste de criterii.
Uneori anumite criterii sunt mai importante ca altele, astfel este indicată stabilirea unei valori
pentru fiecare criteriu pentru a indica gradul de importanţă.
F. Timer:
Acest instrument a fost proiectat pentru un bun management al timpului în cadrul întâlnirii. În
mod frecvent acest instrument este utilizat împreună cu un alt instrument dar poate fi utilizat şi
singur. În timpul planificării întâlnirii facilitatorul decide cât de mult timp se alocă pentru fiecare
activitate din cadrul întâlnirii şi dacă se impune folosirea instrumentului Timer. Instrumentul
Organize are inclus propriul timer astfel că utilizarea instrumentului Timer în combinaţie cu
Organize este inutilă.
G. File Editor:
Acest instrument este utilizat de şofer, în general pentru a pregăti o listă de elemente pentru pasul
următor sau pentru a o adăuga la documentul final. De asemenea poate fi folosit pentru a verifica
scrierea corectă a elementelor unei liste.
H. Manual:
În agenda întâlnirii se vor găsi programate diferite activităţi care nu necesită utilizarea
calculatoarelor, cum ar fi discursurile, pauzele de masă. Aceste activităţi pot fi incluse în agenda
cu ajutorul acestui instrument.
I. External Program Tool:
Agenda întâlnirii poate conţine activităţi care necesită utilizarea de programe software adiţionale,
cum ar fi Microsoft Excel, Microsoft Word, MS Project. Aceste activităţi pot fi incluse în agendă
cu ajutorul acestui instrument.

GroupSystemes.com:
GroupSystems este o platformă software pentru managementul proceselor de afaceri, deciziilor
asistate electronic şi colaborare. GroupSystems este o colecţie de instrumente ce suportă procese
de grup cum ar fi brainstorming-ul, colectare de informaţii, votarea, organizarea, evaluarea şi
realizarea unui consens.
A. Categorizer:
Acest instrument ajută grupurile să îndeplinească 3 obiective:
• Generarea de liste cu idei
• Generarea de comentarii care sunt destinate ideilor
• Organizarea ideilor în categorii
În modul de lucru cel mai simplu al instrumentului, fiecare participant introduce idei care au
legătură cu subiectul supus discuţiei. Aceste idei sunt adăugate într-o listă. Grupul poate edita
lista pentru a contopi ideile similare. Participanţii pot adăuga comentarii oricărei idei din listă.
După aceea participanţii pot copia sau muta ideile în categoria de care aparţin. Ca şi alternativă,
grupul poate începe prin a crea categorii şi după aceea să adauge idei şi comentarii pentru fiecare
categorie creată.
B. Vote:
Acesta este un instrument de evaluare care furnizează baza pentru a ajunge la o decizie de grup.
Este folosit frecvent pentru a determina gradul de consens al grupului. De asemenea mai poate fi
folosit pentru a strânge informaţii. Pentru a utiliza acest instrument mai întâi se introduce o lista
de elemente care urmează a fi evaluate. După aceea se selectează o metodă de evaluare din cele
existente.
• Ordonarea listei
• Scală de 10 puncte
• Adevărat/Fals
• Da/Nu
• Aprob/Dezaprob (5 puncte)
• Aprob/Dezaprob (4 puncte)
• Selecţie multiplă
• Metode definite de utilizator
Rezultatele pot fi vizualizate fie sub forma unei tabele fie sub formă de grafice.
C. Topic Commenter:
Acesta este utilizat pentru a genera o listă de subiecte şi a aduna comentarii. Comparat cu
instrumentul pentru brainstorming Topic Commenter este mai structurat, este similar cu
instrumentul Group Outliner dar fără posibilitatea de a subordona un subiect la altul. Subiectele
pot fi introduse sau pot fi importate înainte de a începe întâlnirea sau pot fi introduse în timpul
întâlnirii. Participanţii pot introduce comentarii pentru subiecte în ce ordine doresc. Spre exemplu
o listă ordonată din instrumentul Vote poate fi introdusă în acest instrument pentru ca participanţii
să comenteze mai detaliat cele mai bine cotate elemente din listă.
D. Electronic brainstorming:
Este un instrument proiectat pentru a colecta idei şi comentarii într-o manieră
nestructurată.Participanţii răspund la o întrebare sau la un comentariu al altor participanţi, într-un
process divergent care ajută grupul să genereze rapid idei. Participanţii contribuie simultan şi
anonim la discuţie. Acest instrument oferă o abordare mai puţin structurată decât instrumentele
Topic Commenter şi Group Outliner. Acest instrument este ideal pentru a ajuta grupurile în a
gândi creativ.
E. Alternative Analysis:
Permite grupurilor să evalueze şi să analizeze o serie întreagă de probleme utilizând diferite
metode.
Se pot evalua o listă de alternative în funcţie de o listă de criterii. Adiţional participanţii îşi pot
testa presupunerile prin modificarea valorii pe care o atribuie criteriilor. Se poate şi vota o listă de
categorii având fiecare sub-elemente. Rezultatele evaluării pot fi sub forma de tabele sau grafice
care permit focalizarea pe informaţia dorită. Alternativelor şi criteriilor li se pot atribui valori
pentru a putea avea o analiză mai sofisticată.
F. Group Outliner:
Acest instrument ajută participanţii să genereze şi să organizeze ideile. Poate fi utilizat cu succes
atunci când se doreşte completarea detaliilor unui plan de afaceri sau a unui plan de acţiune. Ca şi
instrument pentru generarea ideilor funcţionează în mare parte la fel cu Topic Commenter, în care
participanţii adaugă comentarii la subiectele dintr-o listă. Ca deosebire între cele două ar fi aceea
ca Group Outliner are pentru fiecare subiect ca sub-elemente alte subiecte, aranjate într-o
structură ierarhică. Astfel procesul de generare de idei este mai structurat decât la Electronic
Brainstorming sau la Topic Commenter. Group Outliner de asemenea poate fi folosit pentru a
organiza idei. Începând de la un subiect aflat în discuţie sau de la un rezultat provenit dintr-un
proces anterior, participanţii pot introduce subiecte cu sub-elemente. Participanţii pot introduce
comentarii pentru fiecare subiect. Spre exemplu, o echipă căreia i s-a atribuit sarcina de a face o
prezentare poate folosi instrumental pentru a planifica conţinutul prezentării, iar mai apoi să
identifice resursele, obiectivele şi termenele limită asignate fiecărei activităţi.
G. Survey:
Permite crearea, administrarea şi analizarea unui chestionar, în mod electronic, fie într-o cameră
în cadrul unei întâlniri, fie în reţea sau prin intermediul internetului. Instrumentul suportă 11
tipuri diferite de întrebări. Participanţii pot fi direcţionaţi pentru a răspunde la anumite întrebări şi
vor fi atenţionaţi dacă nu au răspuns s-au dacă au răspuns incorrect la o întrebare. Răspunsurile
individuale sunt actualizare foarte frecvent pentru a putea fi vizualizate. Rezultatele pot fi filtrate
în funcţie de anumite răspunsuri, spre exemplu pe categorii de vârstă. Întrebările pot fi analizate
fie individual fie împreună pentru a se putea face comparaţii.