Proiectarea interfet¸elor utilizator bazatˇa pe analiza ...adriana/Referat2.pdf · Analiza sarcinii poate sˇa utilizeze una sau mai multe din metodele disponibile de colectare

UNIVERSITATEA BABES-BOLYAI

FACULTATEA DE MATEMATICA SI INFORMATICA

Proiectarea interfetelor utilizator bazata pe analiza

activitatii de munca

-referat la doctorat-

Autor: Adriana Mihaela TartaIndrumator stiintific: Militon Frentiu

martie 2005

Cuprins

1 Analiza activitatii de munca 31.1 Ce este analiza activitatii de munca? . . . . . . . . . . . . . . . . . . . . . 41.2 Scurt istoric al analizei activitatii . . . . . . . . . . . . . . . . . . . . . . . 51.3 Analiza activitatii de munca ın proiectarea sistemelor interactive . . . . . . 71.4 Produsele analizei activitatii si sistemele interactive . . . . . . . . . . . . . 111.5 Probleme relevate de analiza activitatii . . . . . . . . . . . . . . . . . . . . 11

2 Metode de analiza a activitatii de munca 132.1 Hierarchical Task Analysis (HTA) . . . . . . . . . . . . . . . . . . . . . . . 132.2 Groupware Task Analysis (GTA) . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.1 Analiza sistuatiei curente - Modelul 1 al activitatii (sarcinilor) . . . 152.2.2 Specificarea situatiei viitoare a activitatii - Modelul 2 al activitatii

(sarcinilor) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.3 Specificarea tehnologiei - Modelul 3 al activitatii . . . . . . . . . . . 152.2.4 Agentii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.5 Munca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.6 Situatia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.7 Ontologie pentru universul activitatii . . . . . . . . . . . . . . . . . 172.2.8 Verificarea modelelor . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.9 Reprezentari pentru conceptele GTA . . . . . . . . . . . . . . . . . 20

2.3 ConcurTaskTrees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.4 Proiectarea interfetei utilizator pe baza modelelor sarcinilor . . . . . . . . . 28

3 Instrumente pentru analiza activitatii de munca 303.1 CTTE - ConcurTaskTrees Environment . . . . . . . . . . . . . . . . . . . . 303.2 EUTERPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3 Cerinte pentru instrumentele de analiza a activitatii . . . . . . . . . . . . . 31

4 DUTCH - metoda de proiectare bazata pe analiza activitatii 334.1 Studiu de caz: aplicarea metodei DUTCH

ın proiectarea unui sistem interactiv pentruevaluarea posturilor de munca . . . . . . . . . . . . . . . . . . . . . . . . . 35

5 Activitati ın derulare si directii de cercetare 40

Anexe 42

A System Usability Scale (SUS) 42

B DTD pentru memorarea arborilor de sarcini 44

1

Introducere

Interesul pentru proiectarea si dezvoltarea de sisteme informatice utilizabile a crescutsemnificativ ın ultima perioada, datorita dorintei de a permite accesul la aplicatiile softpentru cat mai multi utilizatori. Cresterea utilizabilitatii sistemelor interactive presupuneluarea ın considerare a mai multor factori: activitatile care trebuie sprijinite, contextulde utilizare, preferintele utilizatorilor, tehnicile de interactiune disponibile pentru o anu-mita categorie de dispozitive. Cu toate ca ın ultima perioada s-au dezvoltat numeroaseinstrumente de dezvoltare a interfetelor utilizator folosind manipularea directa, rezultatulfolosirii acestora nu este cel scontat. Problemele de utilizare sunt cauzate de faptul cautilizatorii nu ınteleg ce actiuni sunt facilitate de sistemul informatic si nu stiu cum sa aso-cieze actiunile logice care trebuie efectuate cu actiunile fizice de la nivelul interfetei. Acestgen de probleme pot fi evitate printr-o abordare sistematica si prin dezvoltarea de instru-mente care sa sprijine dezvoltarea de modele ale activitatii si care sa furnizeze indicatiidespre cele mai eficiente tehnici de interactiune si prezentarile cele mai potrivite pentrusprijinirea utilizatorilor. Modelele activitatii descriu modul de efectuare a sarcinilor pen-tru atingerea scopurilor atunci cand se foloseste un sistem interactiv. Modelele activitatiise construiesc pe baza analizei activitatii, tehnica ce ısi are originea ın psihologia muncii.

Scopul prezentului referat este de a prezenta modul ın care analiza si modelarea ac-tivitatii poate fi integrata ın procesul de proiectare a sistemelor interactive. Clarificariale notiunilor de baza relative la analiza activitatii sunt prezentate ın primul capitol alreferatului.

Activitatea de analiza si modelare a activitatii a fost abordata ın maniere diverse de-a lungul timpului, fiecare metoda aducand propriile ımbunatatiri procesului de analiza.Capitolul 2 al referatului prezinta cateva metode de analiza a activitatii care au fostpreluate ın activitatea de proiectare a interfetelor utilizator ımpreuna cu metode recentdezvoltate tocmai ın contextul proiectarii sistemelor interactive.

Analiza activitatii este o activitate complexa, care foloseste un volum mare de informatiecare trebuie manipulata si a carei consistenta trebuie atent verificata. Pentru usurareaprocesului de analiza si modelare a activitatii s-au dezvoltat instrumente de analiza simodelare, cateva din ele constituind subiectul celui de-al treilea capitol al referatului.

In proiectarea sistemelor interactive analiza activitatii a fost folosita doar facultativsi deseori cu titlu experimental, dovedindu-si ın numeroase cazuri aportul pozitiv. Rezul-tatele experientelor de integrare a analizei activitatii ın proiectarea sistemelor interactives-au conturat ın dezvoltarea metodei DUTCH. Metoda DUTCH este descrisa ın capi-tolul patru al referatului, ımpreuna cu un studiu de caz asupra proiectarii unui sisteminformatic conform metodei.

Instrumentele descrise ın capitolul 3 al referatului au avantajele si lipsurile lor. Capi-tolul cinci se doreste a fi o contributie la ımbunatatirea performantelor acestor instru-mente. Obiectivul este proiectarea si dezvoltarea unui instrument de analiza si modelarea activitatii bazat pe metoda GTA, care sa ımbine aspectele pozitive ale instrumentelorcare fac obiectul de studiu al capitolului 3 si sa elimine lipsurile acestora.

2

Capitolul 1

Analiza activitatii de munca

In viata de zi cu zi, la serviciu sau acasa, oamenii efectueaza activitati pentru a ındepliniscopuri impuse de ei ınsisi sau de mediu. Activitatile pot fi privite ca niste mecanismemai mult sau mai putin bine definite pe care oamenii le aplica pentru a schimba stareaobiectelor care ıi ınconjoara. Pentru activitate doar o mica parte a lumii ınconjuratoareeste importanta si e compusa din obiecte fizice (note, usi, masini, oameni) sau obiecteabstracte (adrese, facturi, organizatii). Tipul si numarul obiectelor relevante pentru ac-tivitate e limitat de mediul fizic si social ın care se desfasoara activitatea. Multimeaobiectelor relevante pentru activitate poarta numele de domeniu al muncii.

In realizarea scopurilor oamenii sunt ajutati de instrumente concepute a fi un mij-loc de usurare a modalitatii de ındeplinire a sarcinilor. In randul acestor instrumenteintra si calculatoarele, ınzestrate cu soft dedicat ındeplinirii unor activitati specifice prininteractiune cu utilizatorul. Deseori ınsa, instrumentele proiectate pentru a fi un sprijinın efectuarea activitatii sunt evitate de oameni sau produc frustrare atunci cand suntfolosite, iar alteori acestea produc modificari inacceptabile la nivelul organizatiilor pentrucare au fost dezvoltate. Motivul atitudinii de neacceptare a sistemelor informatice esteacela ca acestea nu sprijina ın mod efectiv si eficient activitatea utilizatorilor (cu altecuvinte nu realizeaza acele activitati care ar trebui realizate sau nu fac acest lucru cuun consum minim de resurse, astfel ıncat sa optimizeze procesul muncii). In proiectareasistemelor chiar si ın prezent este exclusa variabila umana, mai precis existenta unordiferente individuale ın interactiunea cu sistemul si anume elementele de procesare cog-nitiva care favorizeaza o abordare optima a sistemului proiectat. Instrumentele sporescvarietatea mijloacelor de realizare a sarcinilor, fiind proiectate pentru a permite oame-nilor sa realizeze scopurile propuse ın mod eficient sau sa ındeplineasca sarcini imposibileın prealabil. Pentru a fi utile, aceste instrumente trebuie sa se potriveasca domeniu-lui muncii pentru activitatea respectiva. Proiectantii instrumentelor trebuie sa acordeatentie atat caracteristicilor relevante ale obiectelor din universul activitatii, cat si con-strangerilor, competentelor si preferintelor oamenilor si mediului ın care se desfasoaraactivitatea. Aceste aspecte determina utilizabilitatea instrumentului pentru o combinatiespecifica de utilizatori si sarcini. Pentru a dezvolta sisteme utile si utilizabile este nevoie caın proiectarea lor sa se porneasca de la activitatile pe care oamenii trebuie sa le efectueze.Achizitia informatiilor necesare despre activitati si structura lor poarta numele de analizaa activitatii de munca. Datele achizitionate ın analiza activitatii sunt deseori numeroasesi uneori chiar contradictorii. Pentru a obtine o imagine cat mai clara a activitatii uti-lizatorilor este nevoie de o structurare a informatiilor relevante despre sarcinile de muncasi a relatiilor dintre sarcini, iar acest obiectiv se realizeaza prin construirea de modele.Acest proces poarta denumirea de modelarea activitatii. Modelele construite ne ajuta saıntelegem realitatea si ne ghideaza interactiunea cu lumea ınconjuratoare.

3

CAPITOLUL 1. ANALIZA ACTIVITATII DE MUNCA

1.1 Ce este analiza activitatii de munca?

Pentru a putea ıntelege care este rolul si scopul analizei activitatii de munca este necesarsa clarificam mai ıntai semnificatiile termenilor de sarcina si de activitate. Leontiev [16]sustine ca sarcina se refera la un obiectiv care trebuie atins ın conditii date. Conditiile potfi de natura tehnica, organizationala, sociala. Alaturi de acestea trebuie incluse ın studiuconditiile legate de utilizator: daca dispune de cunostintele necesare realizarii sarcinii,este competent sau nu, este ıntr-o stare emotionala buna sau nu, este obosit sau nu, etc[16].

In mod similar, Leplat [17] defineste activitatea ca fiind un obiectiv de atins ın conditiideterminate. Conditiile pot fi de diferite tipuri: fizice, tehnice, organizationale, socio-economice. Raspunsul individului la ansamblul acestor conditii este sarcina, adica ceeace face omul pentru a realiza obiectivul.

Activitatea se refera la o structura complexa a comportamentului uman care urmaresterealizarea unui scop. Acest scop este realizabil prin descompunerea activitatii ın unitatimai mici, numite sarcini. Sarcinile au asociate de asemenea scopuri (care se constituieın subscopuri ale scopului activitatii). Indeplinirea sarcinilor se realizeaza prin efectuareaunui set de actiuni (fizice sau mentale).

Analiza activitatii este un proces de colectare sistematica de date care descriu sarcinileaferente unui post de munca, precum si cunostintele, deprinderile, aptitudinile si alteparticularitati ale muncii care ofera unei persoane posibilitatea de a ındeplini conditiileimpuse de acesta [22].

Analiza sarcinilor este procesul de culegere de date despre actiunile pe care oamenii leefectueaza [27], iar modelarea sarcinilor este crearea de reprezentari ale sarcinilor pe careoamenii le efectueaza [8]. Prin urmare, analiza activitatii se realizeaza prin ansamblulrezultatelor analizei sarcinilor.

Analiza activitatii nu apare doar ın HCI, ci ın orice activitate al carei scop este creareaunui mediu ın care sarcinile sa fie efectuate. Diferenta este ca ın cazul sistemelor in-teractive sarcinile sunt reprezentate prin simboluri, iar executia sarcinilor se face prinmanipularea simbolurilor.

Exista cateva metode specifice de culegere a datelor precum: interviuri, observatie,protocoale verbale sau studii etnografice la locul de munca.

Metode si tehnici de culegere a datelor

Analiza sarcinii poate sa utilizeze una sau mai multe din metodele disponibile de colectarea informatiilor despre sarcina, ın functie de tipul activitatii analizate, scopul analizei,conditiile de realizare a analizei sau experienta analistului. Tehnicile de colectare a datelorse pot grupa ın trei categorii:

1. Tehnici de interogare - sunt tehnici verbale unde subiectului, care se afla ınafara situatiei reale a sarcinii i se cere sa-si reaminteasca, sa explice, sa reflectezeasupra comportamentului sau de realizare a sarcinii. Din aceasta categorie fac parteurmatoarele tehnici: interviul structurat, interviul focalizat, introspectia.

2. Tehnici observationale - subiectul se afla ıntr-o situatie reala sau simulata derealizare a sarcinii. Tehnicile pot sa presupuna sau nu realizarea unui protocolverbal. Din aceasta categorie fac parte tehnici precum: protocoalele verbale sitehnica “gandirii cu voce tare”, tehnica ”teach-back”.

4


3. Tehnici multidimensionale - ofera ın general date non-verbale; rolul lor este de aforta subiectul sa gandeasca despre domeniul sarcinii ıntr-un mod nou, care uneoripoate sa para fara legatura cu sarcinile pe care le realizeaza. Din aceasta categoriefac parte tehnici precum: grila-inventar, sortarea si clasificarea [13].

O data culese datele, acestea trebuie structurate si ıntelese, acest proces purtandnumele de modelarea activitatii. Modelele activitatii sunt rezultatele (produsele) ıntregiiactivitati de analiza a sarcinilor. Nici analiza sarcinilor si nici modelarea sarcinilor nusunt subiecte de discutie noi, dar si-au recastigat atentia o data cu cresterea interesuluipentru proiectarea centrata pe utilizator.

Analiza sarcinilor constituie punctul de pornire ın dezvoltarea oricarui sistem/interfeteutilizabile. In proiectarea, validarea si exploatarea sistemelor informatice, analiza sarcinilorpoate contribui la realizarea a doua obiective principale:

1. ameliorarea caracteristicilor activitatii umane ın sistemele existente;

2. proiectarea si dezvoltarea unor sisteme noi.

Cele doua obiective influenteaza modalitatea de realizare a analizei. Astfel, dacascopul este proiectarea si dezvoltarea unui nou sistem, este esential sa se analizeze detaliatscopurile si functiile sistemului, dar sunt luate ın considerare si cerintele formale aleperformantei umane, deoarece acestea permit stabilirea unui cadru conceptual adecvatın proiectarea activitatii si a conditiilor de realizare a sarcinilor. In cazul sistemelor dejadezvoltate, interesul se ındreapta spre analiza performantelor reale si ameliorarea acestora[13].

Scopul analizei sarcinilor este de a culege suficienta informatie despre mediul sarciniipentru a face posibila proiectarea interfetei utilizator.

In proiectarea interfetelor bazata pe sarcina, modelele activitatii sunt sursa primaraın determinarea functionalitatii aplicatiei si a modului de structurare a interactiunii. Mo-delele sarcinilor sunt folosite pentru restructurarea muncii si pentru a oferi detalii despreutilizatori si despre alte persoane afectate de folosirea sistemului. Aceste informatii suntextrem de importante atunci cand se proiecteaza avand ca obiectiv utilizabilitatea.

1.2 Scurt istoric al analizei activitatii

Prima publicatie referitoare la analiza sarcinilor dateaza din 1967 si poarta titlul: Hie-rarchical Task Analysis. O perioada ındelungata acest subiect a fost ignorat, pana ın aniioptezci cand metode precum GOMS si TAG au recastigat interesul proiectantilor.

Goals, Operators, Methods and Selection Rules (GOMS)

GOMS reprezinta o familie de metode de analiza a sarcinilor si este cu siguranta ceamai influenta metoda de analiza a sarcinilor, desi este mai degraba o tehnica de descrierea dialogului bazata pe sarcini, descriind pasii care trebuie urmati pentru a realiza oactivitate folosind o anumita interfata. Descrierile GOMS se centreaza ın jurul a patruconcepte:

• Goal (scop) - reprezinta starea pe care utilizatorul vrea sa o atinga;

• Operators (operatori) - actiuni de baza pe care utilizatorul trebuie sa le efectuezepentru a folosi sistemul; afecteaza sistemul (apasa tasta F1) sau starea mentala autilizatorului (citirea unei cutii de dialog);

5


• Methods (metode, proceduri) - o modalitate posibila de a ındeplini scopul propus;este formata dintr-o secventa de pasi;

• Selection rules (reguli de selectare) - exista posibilitatea atingerii unui scop folosindmai multe metode; regulile de selectare exprima optiunile de realizare a sarcinilor[7].

Descrierea GOMS ia forma unui arbore de descompunere a activitatii pornind de la scop,pana la mentionarea detaliata a actiunilor necesare ındeplinirii sarcinilor. Descrierea estetextuala, ceea ce face metoda greu de folosit daca descompunerea devine mare si nupermite decat exprimarea de actiuni secventiale, ceea ce limiteaza extrem de mult clasasarcinilor care pot fi descrise.

Un exemplu de analiza GOMS pentru selectarea unui text este prezentat ın cele ceurmeaza:

Selection rule set for goal: select text

if text-is word thenaccomplish goal: select word

end ifif text-is arbitrary then

accomplish goal: select arbitrary textend ifreturn with goal accomplished.

Method for goal: select wordStep 1. Locate middle of word. (M)Step 2. Move cursor to middle of word. (P)Step 3. Verify that the correct word is located. (M)Step 4. Double click mouse button. (BB)Step 5. Verify that the correct text is selected. (M)Step 6. Return with goal accomplished.

Method for goal: select arbitrary textStep 1. Locate beginning of text. (M)Step 2. Move cursor to beginning of text. (P)Step 3. Verify that the correct beginning is located. (M)Step 4. Press mouse button down. (B)Step 5. Locate end of text. (M)Step 6. Move cursor to end of text. (P)Step 7. Verify that correct text is marked. (M)Step 8. Release mouse button. (B)Step 9. Verify that the correct text is selected. (M)Step 10. Return with goal accomplished.

Task-Action Grammar (TAG)

TAG este un formalism care porneste de la conceptia ca interactiunea om-calculator esteun proces de comunicare prin intermediul unui limbaj, prin urmare poate fi descris folosindgramatici [21]. Scopul modelelor TAG este ıntelegerea comportamentului utilizatoru-lui si analiza complexitatii cognitive a interfetei. Modul de realizare a sarcinilor cu o

6


interfata este descris prin intermediul regulilor de productie, ımbunatatirea pe care o aducemetoda TAG ın clasa metodelor care folosesc gramatici pentru descrierea interactiunii om-calculator fiind aceea ca se realizeaza o reprezentare compacta a intractiunii, tinand contde cunostintele pe care le are utilizatorul despre lume si despre inferentele pe care acestale poate dezvolta pe baza acestor cunostinte.

Un exemplu de analiza TAG pentru descrierea operatiilor de copiere si mutare a unorfisiere ıntr-un sistem de operare Linux este prezentat ın cele ce urmeaza:

file op[Op] := command[Op]+filename+filename|command[Op]+filenames+directorycommand[Op=copy] := cpcommand[Op=move] := mvSuccesul metodei a fost limitat de reprezentarea textuala folosita, dar a fost folosita

cu succes pentru compararea complexitatii interfetelor pe baza numarului de reguli deproductie necesare descrierii interactiunii.

Methode Analytique de Description des taches(MAD)

Metoda MAD face parte dintr-o metoda mai larga de descriere a sistemelor interac-tive. Modelele sarcinilor create folosind MAD sunt foarte similare modelelor generatede HTA, cu exceptia faptului ca planurile au fost ınlocuite prin “constructori” care spe-cifica dependentele temporale dintre sarcini (ex. de constructori: PREV, SEQ, PAR,ALT, SIM) [23]. Detaliile despre sarcini (pre- si postconditii, stari initiale si finale, pri-oritati, etc.) sunt descrise ın sabloane. Criticile aduse acestei metode sunt legate de faptulca nu modeleaza conceptele relative sarcinilor precum roluri, obiecte, agenti [27].

Groupware Task Analysis (GTA)

GTA este o metoda recent dezvoltata care se ınscrie ın tendintele CSCW (ComputerSupported Collaborative Work) si care pleaca de la premisa ca nu e optim a analizamunca din punctul de vedere al unui utilizator izolat, ci e mai bine sa se analizeze ıntreagaorganizatie (de aici si “groupware”). GTA este parte integranta a metodei de proiectarea sistemelor interactive prezentata ın capitolul 4 al prezentului referat.

Deoarece scopul prezentului referat este clarificarea notiunii de analiza a activitatii(sarcinilor) si a rolului acestei metode ın proiectarea sistemelor interactive, o atentie de-osebita se va acorda ın capitolele care urmeaza metodei HTA, ca metoda fundamentalafolosita pentru analiza sarcinilor si metodei GTA, care este metoda cel mai solid funda-mentata teoretic ın ceea ce priveste stabilirea conceptelor de interes si a relatiilor dintreele ın sfera de interes a proiectarii de sisteme utile si utilizabile.

1.3 Analiza activitatii de munca ın proiectarea sis-

temelor interactive

Orice tehnica de analiza a activitatii implica stabilirea domeniului problemei pe care uti-lizatorul ıncearca sa o rezolve cu sistemul si formularea sa ın termenii scopurilor, intentiilorsi operatiilor. In functie de obiectivele analizei, aceasta poate sa fie efectuata ın moduridiferite:

• Descompunerea activitatii - interesul este orientat spre identificarea sarcinilor careduc la atingerea obiectivului propus si a ordinii ın care acestea trebuie efectuate;

7


• Analiza bazata pe cunostinte - urmareste identificarea cunostintelor pe care utiliza-torul trebuie sa le detina cu privire la obiectele si actiunile implicate ın ındeplinireaunei sarcini;

• Analiza relatiilor dintre componente - identificarea actorilor, obiectelor si a relatiilorcare se stabilesc ıntre acestia si actiunile pe care ei le realizeaza.

In HCI analiza activitatii se foloseste ın trei feluri diferite:

• descrierea activitatii utilizatorului si mediului activitatii (modelul descriptiv al ac-tivitatii);

• analiza consecintelor deciziilor de reproiectare a activitatii (proiectare a sarcinilor -modelul prescriptiv al activitatii);

• analiza activitatii relativ la modul ın care este sau ar trebui sa fie efectuata cu ointerfata utilizator particulara (analiza interfetei utilizator sau evaluarea interfeteiutilizator).

Rezultatul analizei activitatii este constituit de modelele activitatii care trebuie sa steala baza procesului de proiectare a sistemelor interactive. Proiectarea bazata pe mode-le nu este o practica noua, modelele fiind folosite datorita sprijinului pe care ıl oferaın ıntelegerea aspectelor esentiale ale lumii ınconjuratoare. Scopul proiectarii bazate pemodele este sa identifice modele de nivel ınalt care le permit proiectantilor sa specificesi sa analizeze aplicatiile soft interactive de la un nivel orientat spre semantica mai de-graba decat sa ınceapa prin referirea la nivelul de implementare. Acest fapt le permitesa se concentreze asupra aspectelor esentiale fara a fi confuzi ın legatura cu detaliile deimplementare, iar mai apoi sa dispuna de instrumente care actualizeaza implementareaın concordanta cu deciziile de nivel ınalt. Prin folosirea modelelor care capteaza aspectelesemantice de interes proiectantii pot gestiona mai usor complexitatea crescanda a sis-temelor interactive si sa le analizeze atat ın faza de dezvoltare a lor, cat si atunci candtrebuie modificate sau evaluate.

Exista diferite tipuri de modele care sunt folosite ın proiectarea sistemelor interac-tive. Putem mentiona tehnicile de modelare orientate pe obiecte, cea mai de succesfiind UML [15], similara cu tehnicile orientate pe activitate din perspectiva faptului cafolosesc descrieri ale obiectelor si activitatii, dar care difera prin notatiile orientate peobiecte folosite si prin punctele de interes. Abordarile orientate pe activitate identificamai ıntai sarcinile si apoi obiectele care trebuie manipulate. Metodele orientate pe obiecteurmeaza un drum invers, deoarece urmaresc modelarea obiectelor care alcatuiesc sistemul.In consecinta, abordarile orientate pe activitate sunt mai potrivite pentru proiectareaaplicatiilor centrate pe utilizator pentru ca atentia este ındreptata spre a sprijini efectivsi eficient sarcinile utilizatorului (sa nu uitam ca unul din cele mai importante principiide utilizabilitate spune:“concentreaza-te asupra utilizatorului si sarcinilor sale”), pe candtehnicile orientate pe obiecte au succes la ingineria nivelului de implementare.

In proiectarea sistemelor interactive trebuie efectuate urmatoarele activitati relativesarcinilor:

1. identificarea domeniului activitatii, constrangerilor, competentelor si preferinteloroamenilor si mediului ın care se desfasoara activitatea;

2. identificarea acelor sarcini care pot fi efectuate ın modul cel mai eficient de catrecalculator;

8


3. proiectarea de modele ale domeniului activitatii (structuri de date) care permitefectuarea computerizata a unui numar maxim de subsarcini;

4. identificarea si dezvoltarea proceselor care permit calculatorului efectuarea acestorsarcini;

5. dezvoltarea interfetei utilizator care acopera golul dintre nevoile utilizatorului, con-ceptia acestuia asupra activitatii si modelul sarcinilor. Interfetele bine proiectaterealizeaza o cartare naturala ıntre domeniul conceptual al proiectantilor si domeniulutilizatorului prin:

• crearea unei conceptii asupra domeniului activitatii care sa corespunda catmai bine domeniului conceptual al utilizatorului prin prezentarea obiectelordomeniului ıntr-o forma potrivita, astfel ıncat utilizatorii sa le ınteleaga usorsemnificatia si caracteristicile si sa stabileasca natural legatura ıntre actiunilecalculatorului (functionalitatea) si actiunile sarcinilor;

• proiectarea de dialoguri care ıi ofera utilizatorului libertate ın cadrul dome-niului activitatii, oferindu-i toate oportunitatile necesare de a realiza sarcinilefara a pierde controlul asupra sistemului.

Activitatile doi, trei si patru sunt ın mod traditional subiect de studiu pentru ingineriasoft. Activitatea cinci este obiect de studiu pentru HCI. Activitatea unu este condusa deanalisti, experti ın interactiunea om-calculator, experti din organizatie. Atat HCI cat siingineria softului au dezvoltat metode proprii de culegere de informatii relevante pentrusarcina. Ingineria soft foloseste metode de Analiza sistemului, iar HCI foloseste metodede Analiza activitatii. Anumite metode din analiza sistemului sunt confundate uneoricu analiza activitatii pentru ca ambele analizeaza si modeleaza componente ale sarcinii.Analiza sarcinilor difera de analiza sistemului prin scopuri, rezultate si subiecte de interes.Distinctia dintre analiza sarcinilor si ingineria cerintelor ın ingineria softului este aceeaca ingineria cerintelor e preocupata de caracteristicile sistemului informatic. Atunci candinterfata utilizator e privita ca o bucata de soft, sau ca parte a sistemului interactiv,analiza sarcinilor este o parte a ingineriei cerintelor. Daca interfata utilizator e privita caun instrument de efectuare a muncii, iar sistemul informatic este privit ca o implementarefunctionala a instrumentului, atunci analiza sarcinilor este o activitate independenta [8].

Aplicarea metodelor de analiza a sarcinilor ıi ofera analistului o imagine a implicariiumane ın sistem, ajutand la dezvoltarea unei imagini detaliate asupra sistemului dinperspectiva utilizatorului asupra activitatii. Unele parti ale sistemului sunt modelateformal, altele mai putin formal. Atat modelul sarcinilor cat si procesul de modelare ınsine ıi ofera analistului o ıntelegere profunda a performantei umane. Modelul activitatiipoate fi dezvoltat ınaintea, simultan cu sau dupa proiectarea sistemului interactiv, ınfiecare caz e folosit diferit, dupa cum urmeaza:

• analiza sarcinilor poate fi folosita ca intrare pentru toate etapele proiectarii, modelulfiind construit pe baza unei activitati existente; ın acest caz analiza sarcinilor efolosita ca sursa de informare;

• modelele sarcinilor pot fi folosite ın proiectare, permitand proiectantilor sa dezvoltescenariile de interactiune ın paralel cu dezvoltarea restului sistemului. Aceasta posi-bilitate e utila ın dezvoltarea prototipurilor. Modelul trebuie modificat la fiecareversiune noua a prototipului. In acest caz analiza sarcinii poate fi privita ca un mij-loc de a discuta impactul deciziilor de proiectare asupra activitatii umane.

9


Analiza de sistem Analiza activitatii

Scop Intrari pentru proiectarea Intrare pentrustructurilor de date proiectarea interfetelorsi proceselor soft utilizator

Rezultat Specificare functionala Specificari alesi specificarea arhitecturii interfetei utilizatorsistemului

Subiecte Informatii tehnice, Limitari ale procesarii informatieide interes caracteristici ale datelor, ale fiintelor umane,

limitari de procesare, caracteristici ale utilizatorilor,consideratii referitoare la consideratii asupra sarcinilorarhitectura sistemelor

Principalele obiecte Structuri de date Concepte despre sarcinide analiza (domeniul sarcinii si activitate

computerizate) sifunctionalitate

Tabela 1.1: Comparatie ıntre analiza sistemului si analiza activitatii

• analiza sarcinilor poate fi folosita pentru a verifica potrivirea dintre sistem si sarcinileutilizatorului. In acest caz analiza este realizata dupa proiectarea sistemului, con-stituind un mijloc de evaluare a eficientei si operativitatii interfetei utilizator si camijloc de efectuare a analizei erorilor.

Din interviurile cu proiectantii de soft ın privinta utilitatii analizei sarcinilor ın pro-cesul de proiectare a softului, a reiesit ca analiza sarcinilor ıi ajuta sa identifice:

• ce asteapta utilizatorii de la sistem;

• structura si frecventa de folosire a facilitatilor sistemului;

• numele si forma de reprezentare a obiectelor prezente pe ecran si a evenimentelorcare apar;

• infomatia care ar trebui sa fie disponibila ıntr-un context anumit (ex: ecran);

• structura de navigare ıntre contexte (mutarea ıntre ecrane).

Proiectantii si-au exprimat dorinta ca analiza sarcinilor sa sprijine operatiile de cartaresi verificare ıntre sarcinile utilizator si proiectarea propusa. Un alt aspect mentionat deproiectanti a fost cel al produselor analizei sarcinilor care ar trebui sa poata fi cartate ınaspecte ale proiectarii precum functionalitatea si dialogul [14].

Dintre toate metodele dezvoltate de-a lungul timpului, doar cateva si-au demonstrataplicabilitatea ın practica. HTA a stat la baza mai multor metode de analiza a activitatii,iar GOMS este cea mai utilizata metoda de analiza a sarcinilor. Motivul inaplicabilitatiiacestor metode este generat de aspectele de reprezentare. Majoritatea metodelor suntformale, fapt care le face puternice, dar greu de utilizat, astfel devenind stringenta nevoiafolosirii unor intrumente care sa-i ajute pe practicieni (ın general este vorba despre des-crieri textuale de dimensiuni mari, greu de urmarit).

10


1.4 Produsele analizei activitatii si sistemele interac-

tive

Whitefield si Hill [30] subliniaza noua componente ale sistemelor interactive care trebuiesa fie descrise ın produsele analizei activitatii:

1. comportamentele sistemului interactiv - analiza sarcinilor trebuie sa identifice com-portamentele pe care sistemul interactiv trebuie sa le detina pentru a realiza osarcina sau a ındeplini un scop;

2. secventele comportamentale ale sistemului interactiv - comportamentele sistemelorinteractive apar ıntr-o anumita ordine. Adesea aceasta secventa este determinatade echipamentele folosite, ınsa unele sarcini impun o secventiere independenta deechipamentul folosit (ex.: un mesaj nu poate fi trimis ınainte de a fi creat oricepachet de emailuri s-ar folosi);

3. scopurile sarcinilor - analiza sarcinilor trebuie sa identifice scopurile pe care sistemulinteractiv trebuie sa le ındeplineasca. Scopul unei sarcini poate fi un scop al muncii(ex.: sa se trimita un raspuns la toate emailurile care necesitau raspuns) sau osarcina de activare (ex.: sa existe un editor de emailuri care sa functioneze);

4. obiectele din domeniul muncii si atributele lor - descrierea scopurilor muncii im-pune identificarea obiectelor din domeniul muncii si atributele acestora care vor fimodificate (ex.: mesaj cu atributele “status” cu valori citit/necitit, data, continut);

5. structuri abstracte ale sistemelor interactive - comportamentele sistemelor interac-tive sunt sprijinite de structuri abstracte precum: abilitati de tastare, protocoale decomunicare, programe de editare, etc.;

6. structuri fizice ale sistemelor interactive - produsele analizei sarcinilor vor identificacomponentele fizice ale unui sistem interactiv;

7. descompuneri ale scopurilor sau comportamentului - daca sarcinile sistemului in-teractiv sunt complexe, atunci se impune o descompunere a acestora fie la nivel alcomportamentului, fie la nivel al scopurilor;

8. o descriere a performantei sistemului interactiv - aceasta va include o descriere com-pleta a calitatilor sistemului si a resurselor si costurilor necesare atingerii performantei.Nivelul de detaliere la care costurile si calitatile vor fi descrise este constrans de des-compunerea scopurilor muncii si comportamentele sistemului interactiv;

9. referinte ıntre componente - produsele bune ale analizei sarcinilor indica modul ıncare componenetele sunt legate ıntre ele (ex.: ar trebui sa se indice care compor-tamente actioneaza asupra caror obiecte, care comportamente determina atingereaunor scopuri, etc.) [30].

1.5 Probleme relevate de analiza activitatii

Unul din reprosurile care au fost adresate analizei sarcinilor a fost acela ca ramane neclarce se poate face cu datele culese. Raspunsul este acela ca datele trebuie supuse unuiproces de analiza care poate evidentia prezenta urmatoarelor tipuri de probleme:

11


• Probleme ın structura activitatii - structura activitatii nu este optima pentru canecesita executia prea multor sarcini sau anumite sarcini sunt mari consumatoarede timp sau au o frecventa de aparitie prea mare;

• Diferente ıntre efectuarea formala si cea curenta a activitatii - desi exista documentatiicare specifica modul de realizare a sarcinilor, ın realitate sarcinile nu se efectueazaconform documentelor, ci se efectueaza ın diverse modalitati. Problemele pot saapara atunci cand ıntr-un mediu cooperativ persoanele au pareri diferite despreceea ce trebuie sa se faca;

• Interactiune ineficienta ın organizatie - sarcinile complexe necesita implicarea maimultor persoane care trebuie sa interactioneze si sa comunice pentru a ımpartasicunostinte despre activitate sau datorita responsabilitatii pentru sarcini. Acesteasunt cauzele pentru care unele activitati sunt mari consumatoare de timp sau potdeveni iritante pentru unele persoane implicate;

• Inconsistente ın sarcini - actiunile sarcinilor sunt definite, dar nu sunt executate denici un agent sau sunt executate ın secvente contradictorii;

• Oamenii fac lucruri interzise - ın mediile complexe adeseori oamenii efectueaza ac-tivitati pentru care nu au primit aprobarea oficiala sau folosesc/modifica obiecte pecare nu au voie sa le manipuleze.

Unele din aceste probleme pot fi detectate automat sau semi-automat atunci cand sefoloseste un instrument pentru analiza sarcinilor.

12

Capitolul 2

Metode de analiza a activitatii demunca

2.1 Hierarchical Task Analysis (HTA)

HTA este o metoda de analiza a sarcinilor care porneste de la descompunerea activitatiiın sarcini. Rezultatele HTA constau ın ierarhii de scopuri, sarcini si actiuni si planuricare descriu ın ce ordine si ın ce conditii se executa sarcinile.

Reprezentarea ierarhiilor de sarcini poate lua forma textuala, caz ın care indentareaeste folosita pentru a sugera nivelurile ın cadrul ierarhiei de sarcini, iar sarcinile suntnumerotate pentru a evidentia aceasta ierarhie. Planurile sunt numerotate corespunzatorsarcinilor (ex.: planul 0 exprima modul ın care se desfasoara sarcinile 1-5 ale activitatii0). In cadrul planurilor observam ca nu toate actiunile trebuie sa se execute sau nu ınordinea prezentata. Gasirea ierarhiei potrivite, restructurarea acesteia, fac parte din pro-cesul HTA. Procesul de construire a ierarhiei de sarcini si a planurilor este unul iterativ.Se porneste de la o activitate si prima ıntrebare pe care o adresam este una referitoarela sarcinile care trebuie ındeplinite pentru a realiza activitatea, iar raspunsul la aceastaıntrebare ıl gasim din surse precum: observarea directa, opinia expertilor, documentatie,etc. La urmatorul pas se analizeaza fiecare sarcina si se ıncearca descompunerea ei ın modsimilar. Un aspect problematic al acestei abordari este legat de determinarea punctuluide oprire ın descompunerea ierarhica. Un criteriu de oprire este cand sarcina contineraspunsuri motorii complexe (ex: miscarea mouseului) sau cand se ajunge la luarea unordecizii interne (unde activitatea e pur cognitiva)[9]. Pentru descrierea planurilor analistulpoate alege folosirea unei metode formale, o diagrama sau o descriere textuala. Un ex-emplu de descompunere a activitatii folosind HTA este cel al curateniei unui apartament.Descompunerea textuala este prezentata ın cele ce urmeaza:0. pentru a face curatenie:

1. ia aspiratorul de praf

2. ataseaza-i componentele

3. curata ıncaperea

(a) curata holul

(b) curata camerele de zi

(c) curata dormitoarele

4. goleste sacul de praf

13

CAPITOLUL 2. METODE DE ANALIZA A ACTIVITATII DE MUNCA

5. pune aspiratorul si componentele atasate la locul lor.

Planul 0: executa 1,2,3,5 ın aceasta ordine; cand sacul este plin executa 4.Planul 3: executa oricare din 3.1, 3.2, 3.3 ın orice ordine ın functie de ıncaperea care

necesita curatarea.Deoarece fiintele umane ınteleg mai usor reprezentarile grafice, o metoda alternativa

de descriere a ierarhiilor rezultate din analiza HTA este cea folosind arbori de sarcini.Descrierea grafica a exemplului prezentat anterior este ilustrata ın Figura 2.1:

Figura 2.1: Diagrama HTA

2.2 Groupware Task Analysis (GTA)

GTA este o metoda de analiza a activitatii recent dezvoltata la Universitatea Libera dinAmsterdam care combina aspecte preluate si prelucrate de la alte cateva metode de analizaa sarcinilor. GTA se doreste a fi o abordare noua pentru fazele initiale din proiectareasistemelor complexe, ın care diferiti utilizatori cu competente si roluri diferite si persoanea caror activitate este afectata de introducerea tehnologiei folosesc solutii informaticepentru a efectua sarcini complexe. Termenul “groupware” subliniaza faptul ca sistemeleinteractive complexe si procesele de munca nu pot fi analizate cu folos din punctul devedere al unui singur post de munca sau al unei interactiuni unice utilizator-calculator[26]. GTA ofera un cadru conceptual care specifica aspectele relevante din universulactivitatii care trebuie luate ın considerare la proiectarea de sisteme pentru grupuri deutilizatori.

GTA este parte a metodei de proiectare DUTCH [29], ın cadrul careia corespundeprimei faze din procesul de proiectare a sistemelor interactive complexe.

Rezultatul analizei GTA este un model formal al activitatii care specifica cadrulintentionat pentru sarcini, iar aceasta specificare se doreste a fi intrarea pentru speci-ficarea detaliilor tehnologice (proiectarea propriu-zisa a sistemului) [24].

Analiza activitatii include activitati diverse:

• analiza situatiei curente de munca si modelarea ei, rezultatul fiind Modelul 1 alactivitatii (sarcinilor) - MA1 ;

• imaginarea unei noi situatii pentru activitatea de munca pentru care se proiecteazasistemul, rezultatul fiind Modelul 2 al activitatii - MA2 ;

14


• specificarea semanticii tehnologiei informatiei care este proiectata, regasit si subdenumirea de Modelul 3 al activitatii - MA3 [26].

2.2.1 Analiza sistuatiei curente - Modelul 1 al activitatii (sarcinilor)

In majoritatea cazurilor proiectarea sistemelor este declansata de o situatie existentaa activitatii. Aceasta situatie fie nu este optima, fie se asteapta ca introducerea noiitehnologii sa ımbunatateasca aceasta situatie. Analiza starii curente a activitatii da posi-bilitatea proiectantului sa formuleze cerintele de proiectare si permite evaluarea ulte-rioara a proiectarii. Modelarea structurata a activitatii ajuta proiectantul sa realizezecare sunt lacunele sale ın ceea ce priveste cunoasterea si ıntelegerea activitatii. Modelul1 al sarcinilor serveste ca si baza pentru modelul 2 al sarcinilor.

2.2.2 Specificarea situatiei viitoare a activitatii - Modelul 2 alactivitatii (sarcinilor)

Cel de-al doilea model al sarcinilor este reproiectat pe baza modelului 1 al sarcinilorastfel ıncat sa fie posibila includerea de solutii tehnice si de raspunsuri tehnice la cerinteleutilizatorilor. Deciziile de proiectare care conduc de la modelul 1 al sarcinilor la modelul2 al sarcinilor sunt bazate pe trei surse:

• Problemele identificate ın modelul 1 al sarcinilor - prima analiza a activitatii vaevidentia parti ale structurii activitatii si caracteristici ale obiectelor asociate sarcinilorcare trebuie modificate pentru a optimiza ındeplinirea obiectivului;

• Cerintele clientului - clientii sunt persoanele care platesc pentru ımbunatatireasituatiei curente a sarcinii, iar cerintele lor includ aspecte economice, constrangeride timp, norme calitative referitoare la munca efectuata;

• Constrangeri si optiuni tehnice - pe baza cunostintelor tehnologice proiectantii iden-tifica posibilele solutii pentru problema, ınsa solutiile tehnologice pot sa nu fie fe-zabile.

2.2.3 Specificarea tehnologiei - Modelul 3 al activitatii

Cel de-al treilea model specifica oferta sistemului ın privinta delegarii sarcinilor. DacaMA 2 prezinta noua structura a activitatii global, modelul 3 specifica solutia detaliata ıntermeni ai tehnologiei. Pentru ıntelegerea acestui model se introduce notiunea de masinavirtuala a utilizatorului (User’s Virtual Machine - UVM) care indica acele cunostinte pecare trebuie sa le posede utilizatorul sistemului pentru a-i ıntelege competenta ın domeniulmuncii. UVM cuprinde trei aspecte:

• functionalitatea - sarcinile de baza pe care utilizatorul le poate delega sistemului;

• limbajul interfetei - limbajul ın care utilizatorul trebuie sa se exprime ın interactiuneacu sistemul;

• prezentarea - reprezentarea informatiilor relevante pentru utilizator. Intre MA 2 siMA 3 trebuie sa se pastreze o corespondenta. O data ce UVM este implementataıntr-un prototip este necesara o revizuire a ambelor modele ın scopul evaluarii.

15


Proiectarea prin rafinare a interfetei utilizator aduce avantaje ın raport cu proiectareadirecta a acesteia prin ımbunatatirea comunicarii ıntre echipele de proiectare, deoareceproblemele si solutiile propuse sunt modelate explicit, iar modelarea permite revenirea sievaluarea deciziilor de proiectarea ın raport cu cerintele. Nucleul GTA este un cadru con-ceptual care serveste doua scopuri: de a oferi recomandari pentru colectarea de informatiidespre starea curenta a activitatii si de a oferi o baza pentru modelarea vechii si noiistructuri a activitatii. Analiza GTA are la baza trei aspecte diferite: agentii, munca sisituatia [26, 24], fiecare din acestea descrie universul sarcinilor dintr-un punct de vederediferit, dar se afla ıntr-o stransa relatie cu celelalte. Aceasta abordare din unghiuri variatepermite luarea de decizii de proiectare mai potrivite sarcinilor si permite instrumentelorde proiectare sa verifice si sa pastreze consistenta si completitudinea modelelor.

2.2.4 Agentii

Agentii se refera la oameni (individual sau grupuri), dar si la sisteme. Oamenii sunt des-crisi prin carateristicile lor relevante pentru activitate: limba pe care o vorbesc, abilitatilede tastare sau operarea pe diverse sisteme de operare. Agentii sunt grupati ın functie desubmultimile de sarcini alocate ın roluri. Un rol poate fi detinut de mai multi agenti, la felcum un agent poate sa detina mai multe roluri. Organizatia este definita de relatiile dintreagenti si roluri ın raport cu alocarea sarcinilor. Analiza si reprezentarea unei organizatiitrebuie sa includa informatii despre responsabilitatea sarcinilor, delegarea sarcinilor siatribuirea rolurilor, precum si despre competente si accesul la obiecte.

2.2.5 Munca

In studiul muncii conceptul de baza este sarcina, care poate fi identificata la diverseniveluri de complexitate. Munca poate fi structurata ın una sau mai multe structuride sarcini, unde structura sarcinilor trebuie sa fie descrisa folosind constructori pentrurelatiile temporale (secventierea, declansarea subsarcinilor, cicluri, alegeri). La nivelul su-perior al unei structuri a activitatii se gaseste scopul activitatii (business goal) si sarcinilelegate de acesta. O activitate nu este delegata unei singure persoane sau unui singurrol, iar pentru scopurile de nivel ınalt exista cateva sarcini care sa duca la ındeplinireascopului. La nivelul inferior al structurii de sarcini se gasesc actiunile.

Exista doua tipuri de sarcini care merita o atentie deosebita: sarcinile unitate - adicaacele sarcini pe care le descriu oamenii cand vorbesc de cel mai jos nivel al muncii lor sisarcinile de baza care reprezinta nivelul atomic de delegare a sarcinilor definit de instru-mentul folosit ın realizarea sarcinii (ex: comanda). Sarcinile complexe pot fi ımpartiteıntre actori sau roluri. Sarcinile unitate si sarcinile de baza pot fi descompuse mai departeın actiuni sistem si actiuni utilizator.

Structura activitatii

Structura activitatii este ın cele mai multe cazuri ierarhica, iar pentru indicarea ordiniitemporale si a relatiilor de dependenta dintre sarcini este de nevoie de folosirea unor“constructori”. Structura activitatii nu este cunoscuta adeseori de actorii individuali,mai ales cand diferite roluri sunt implicate ın realizarea unor sarcini.

Actiunile

Actiunile sunt componente identificabile ale sarcinilor de baza sau ale sarcinilor unitatecare au un rol ın ındeplinirea unei unitati de munca, dar care ısi deriva sensul din sarcina

16


a caror parte sunt (ex.: apasarea tastei ENTER are o semnificatie diferita cand urmeazaunei comenzi sau cand confirma o valoare numerica). In descrierea actiunilor scopul estede a le identifica semnificatia, nu caracteristicile fizice.

Protocoalele si strategiile

O multime de sarcini care apartin unui singur rol au un mod de efectuare bine definit.Daca acest procedeu este considerat a fi o practica comuna buna, ıl denumim protocol.Daca procedura este specifica expertilor ın domeniu, o numim strategie.

2.2.6 Situatia

Analiza universului activitatii din punctul de vedere al situatiei ınseamna gasirea si des-crierea mediului ınconjurator (fizic, conceptual si social) si a obiectelor din mediu.

Obiectele

Orice lucru care este relevant pentru munca ıntr-o anumita situatie este un obiect ın cadrulanalizei sarcinilor. Obiectele pot fi fizice sau conceptuale (mesaje, gesturi). Referirea laobiecte se face prin reprezentari externe cu caractere diferite: etichete, desene, metafore.Actorii care joaca un anumit rol pot fi obiecte ıntr-o situatie a sarcinii diferita si vor fietichetati ca “obiecte active”. Obiectele sunt folosite pentru a transfera informatii ıntreagenti.

Structura obiectelor

Pentru a descrie semnificatia obiectelor trebuie identificate doua tipuri de relatii ıntreobiecte:

• relatii de specializare de tipul subtip/supertip. Subtipurile mostenesc caracteristicilesupratipurilor ın absenta altor specificari. Pe baza acestor relatii obiectele vor ficuprinse ıntr-o ierarhie de obiecte.

• relatii de agregare - cand un obiect poate fi “ın” alt obiect sau “contine” alt obiectsau obiectele pot sa se “mute” dintr-o locatie ın alta.

Pe langa aceste relatii, obiectele sunt legate de sarcini sau agenti.Obiectele sunt descrise prin structura si atributele lor, dar nu e vorba de sensul oferit

termenului ın paradigma orientata pe obiecte.

Mediul

Mediul sarcinilor este contextul curent pentru ındeplinirea obiectivului si include actori,roluri, conditii pentru ındeplinire sarcinilor, pentru strategii si protocoluri, obiecte rele-vante, artefacturi precum sisteme carora le sunt delegate sarcini. De asemenea, structuratemporala a evenimentelor este parte a mediului. Mediul influenteaza structura activitatii.

2.2.7 Ontologie pentru universul activitatii

Van Welie [27] propune o ontolgie a universului sarcinilor care evidentiaza aspecteleesentiale ın analiza sarcinilor si relatiile dintre ele. Ontologia defineste conceptele si

17


relatiile dintre ele care sunt considerate relevante pentru scopul analizei sarcinilor. On-tologia constituie baza conceptuala pentru informatiile care trebuie retinute si modul destructurare si reprezentare a acesteia.

Figura 2.2: Ontologia universului activitatii [27]

In continuare vom detalia conceptele din ontologie si relatiile care pot sa existe ıntreele:

• Sarcina - pasi efectuati de agenti pentru a atinge un anumit scop. Sarcinile suntexecutate ıntr-o anumita ordine si finalizarea unei sarcini poate declansa executiauneia sau mai multor sarcini. O sarcina poate sa fie declansata si de aparitia unuieveniment.

• Scop - este o stare care se doreste a fi atinsa si care poate fi atinsa prin executiauneia sau mai multor sarcini.

• Rol - colectie de sarcini efectuate de unul sau mai multi agenti. Rolul are sensatunci cand are un scop clar si stabileste o distinctie ıntre grupuri de agenti. Rolule responsabil de sarcinile pe care le cuprinde. Rolurile pot fi descompuse ierarhic.

• Obiect - entitate fizica sau conceptuala, poate fi inclus ıntr-o ierarhie de tipuri sipoate fi inclus ın alte obiecte.

• Agent - entitate activa (oameni, grupuri de oameni sau sisteme). Agentii nu suntindivizi specifici, ci indica clase de indivizi cu anumite caracteristici.

• Eveniment - schimbare ın universul activitatii la un moment dat ın timp asupracareia actorul nu are ıntotdeauna controlul direct (ex.: caderea electricitatii, ımbolna-virea unui coleg, etc.). Evenimentele influenteaza ordinea executiei sarcinilor prindeclansarea de sarcini.

Relatiile care pot aparea ıntre componentele ontologiei sunt:

• foloseste - specifica obiectele folosite ın executia sarcinii si modul ın care suntfolosite.

• declanseaza - este relatia de baza ın specificarea fluxului sarcinilor, specificanddaca o sarcina e declansata de un eveniment sau o alta sarcina.

18


• joaca - fiecare agent trebuie sa joace un rol. Aceasta relatie indica rolurile asociateagentilor.

• realizata de - specifica faptul ca o sarcina este efectuata de un agent, lucru care nuınseamna ca agentul este responsabil pentru sarcina, responsabilitatea depinzand derolul din care face parte agentul. Cand nu este important care agent efectueaza osarcina se poate mentiona rolul care e responsabil pentru sarcina.

• are - relatie care conecteaza sarcinile la scopuri; fiecare sarcina are un scop caredefineste motivul executiei sale.

• subsarcina/subscop - descrie descompunerea sarcinilor/scopurilor.

• subrol - determina o ierarhie a rolurilor.

• influenteaza - un rol poate influenta un alt rol (este o parte a culturii organizationale).

• responsabil - specifica sarcinile pentru care un rol este responsabil.

• folosit de - specifica cine poate folosi un obiect si modul ın care un rol sau un agentpoate folosi obiectul.

Aceste relatii formeza o baza, iar alte relatii pot fi derivate pe baza acestor relatii (ex:cine este implicat ıntr-o sarcina = responsabil + realizeaza + joaca + subrol).

2.2.8 Verificarea modelelor

Definirea obiectelor si relatiilor dintre ele permite verificarea modelelor construite. Pro-prietatile care pot fi verificate sunt general valabile si se refera la constrangeri pe care amdori ca modelele sa le satisfaca. Aceste constrangeri se pot referi la cardinalitate, tip siatribute ale obiectelor.

Constrangeri de cardinalitate - se refera la cardinalitatea relatiilor dintre concepte.Acestea sunt:

• Fiecare eveniment trebuie sa declanseze cel putin o sarcina:

∀e∃t{e ∈ Events, t ∈ Tasks|triggers(e, t)}

• Fiecare agent trebuie sa aiba cel putin un rol:

∀a∃r{a ∈ Agents, r ∈ Roles|hasrole(a, r)}

• Fiecare rol trebuie sa fie responsabil pentru cel putin o sarcina:

∀r∃t{r ∈ Roles, t ∈ Tasks|responsible(r, t)}

• Fiecare obiect trebuie sa fie folosit ın cel putin o sarcina:

∀o∃t{o ∈ Objects, t ∈ Tasks|uses(t, o)}

• Fiecare sarcina trebuie sa fie ındeplinita de cel putin un rol:

∀t∃r{t ∈ Tasks, r ∈ Roles|performs(t, r)}

• Pentru fiecare sarcina trebuie sa existe cel putin un rol responsabil:

∀t∃r{t ∈ Tasks, r ∈ Roles|responsible(r, t)}

19


• Fiecare obiect trebuie sa aiba un proprietar:

∀o∃r{o ∈ Objects, r ∈ Roles|uses(o, r, Rights) ∨ owner ∈ Rights}

Constrangeri de tip - se refera la entitati de acelasi tip:

• O instanta a unui obiect nu poate sa se contina pe sine:

¬∃o{o ∈ Objects|contains(o, o)}

• O sarcina nu poate sa se aiba pe sine ca subsarcina:

¬∃t{t ∈ Tasks|subtask(t, t)}

• O sarcina nu poate sa se declanseze pe sine:

¬∃t{t ∈ Tasks|trigers(t, t)}

• Un rol nu poate sa se aiba pe sine ca subrol:

¬∃r{r ∈ Tasks|subrole(r, r)}

2.2.9 Reprezentari pentru conceptele GTA

GTA este un cadru conceptual doar si nu impune folosirea unor reprezentari, dar dinexperienta aplicarii metodei urmatoarele tipuri de reprezentari corespund cerintelor anali-zei sarcinilor.

Reprezentarea structurii muncii

Scopul modelarii structurii muncii este de a reprezenta modul ın care oamenii ısi ımpartactivitatea ın parti mai mici pentru a atinge scopuri. Cunoasterea structurii munciipermite proiectantilor sa ınteleaga modul ın care oamenii gandesc asupra muncii lor simodul ın care sarcinile sunt legate de scopuri. Relatia dintre sarcini si scopuri permitemai departe alegerea sarcinilor care trebuie sa fie sprijinite de sistemul informatic si caresunt scopurile independente de tehnologia folosita. Structura muncii este modelata ınmod uzual prin arbori de sarcini care descriu o descompunere ierarhica a muncii. Inconstructia arborilor este esentiala relatia de subsarcina dintre sarcini. Alaturi de sarcini,ın ierarhii sunt incluse si scopurile. La cel mai ınalt nivel un arbore poate sa ınceapa cuun scop si subscopurile sale si sa continue cu sarcini, subsarcini si actiuni. In astfel decazuri sunt folosite relatiile are si subscop. O descompunere a activitatii este modelatadin punctul de vedere al unui rol sau al unui scop, prin urmare se vor descrie cativa arboripentru a surprinde munca din punctul de vedere al tuturor rolurilor. Deseori sunt necesaresi informatii temporale, ın acest caz folosindu-se constructori precum: SEQ, LOOP, PARsau OR [25]. Exista situatii ın care anumite sarcini apar uneori sau aproape niciodata.Daca se impune precizie ın specificarea unor astfel de situatii, alegerea cea mai potrivitaeste de folosire a workflow-urilor [28]. Detaliile despre sarcina sunt completate ın sabloanecare includ informatii despre schimbarea starii, frecventa si durata.

Structura rolurilor si relatia cu sarcinile sunt alte aspecte importante ale structuriimuncii. Structura rolurilor poate fi decsrisa folosind de asemenea arbori de roluri.

20


Figura 2.3: Reprezentarea GTA pentru structura muncii

Reprezentarea dinamicii muncii

Dinamica muncii se refera la ordinea ın care sunt efectuate sarcinile relativ la rolurilecare le efectueaza. Pentru descrierea acestor aspecte sunt folosite diagramele de flux aactivitatilor (workflow) si modelele de sarcini. Un aspect important al dinamicii munciise refera la colaborare si comunicare, mai ales cand sunt implicate mai multe roluri ınrealizarea unei activitati. Un model al fluxului muncii poate descrie munca ın raport curolurile si timpul. Acest model ıi ofera proiectantului informatii despre ordinea ın caresunt efectuate sarcinile si modul de implicare al oamenilor ın efectuarea acestora, precumsi informatii despre modul ın care oamenii colaboreaza si comunica prin schimbul deobiecte si mesaje. Pentru modelarea acestor aspecte se foloseste o variatie a diagramelorde activitate UML, ın care au fost incluse evenimente si scopuri pentru a o face maipotrivita pentru analiza sarcinilor. Fiecare flux descrie un scenariu care este declansat deun eveniment, reprezentat de un oval conectat la prima sarcina. Succesiunea sarciniloreste descrisa prin folosirea operatorilor Concurrent si Choice. Sarcinile pot fi grupateın culoare, cate un culoar pentru fiecare rol. Obiectele transmise ıntre sarcini aparatinanddiferitelor roluri sunt desenate pe linia despartitoare a culoarelor (vezi Figura 2.4). Sco-purile pot fi reprezentate ın prima coloana a fluxului muncii si sunt ınsotite de linii verticalecare indica durata activarii scopului.

Modelul de flux nu da informaatii despre ierarhia sarcinilor, ci foloseste doar sarcinicare se afla pe acelasi nivel al ierarhiei. Pentru subsarcini se construiesc noi modele deflux.

In termeni ai ontologiei, modelul de flux e bazat pe conceptele eveniment, sarcina,obiect si rol. Relatiile folosite sunt declanseaza, responsabil si foloseste. Operatorii folositisunt Concurrent, Choice, Successive, care sunt parametri ai relatiei declanseaza. Incazul obiectelor transmise ıntre roluri, acestea trebuie sa fie asociate ambelor sarcini prinrelatia foloseste.

Reprezentarea artefacturilor

Mediul muncii contine numeroase obiecte, unele din ele fiind folosite direct ın realizareasarcinilor. Modelul artefacturilor surprinde doua relatii ıntre obiecte: contine si tip.Pentru acestea e relevant sa se descrie structura, tipul, si atribute specifice. Pentru adescrie aceste aspecte se folosesc diagrame de clase, dar fara sectiunea de metode.

Obiectele pot sa fie legate de utilizatori (roluri sau agenti), ın loc sa fie legate desarcinile ın care sunt folosite. Pentru astfel de cazuri se folosesc diagrame ın care utiliza-

21


Figura 2.4: Reprezentarea GTA pentru fluxul activitatii

torii sunt reprezentati ca si ovaluri, iar obiectele sunt reprezentate prin puncte etichetatepozitionate ın interiorul ovalurilor. Ovalurile se pot suprapune daca mai multi utilizatorifolosesc un obiect (vezi Figura 2.5).

Relatiile cu sarcinile si utilizatorii sunt descrise ın sabloane specifice.

Reprezentarea mediului muncii

Un aspect al mediului muncii este dispunerea fizica a obiectelor si dimensiunile acestora.In descrierea acestor aspecte se folosesc harti, fotografii, fragmente video la care se adaugacomentarii relative la impactul lor asupra muncii (ex.: usurinta de a ajunge la un obiect).

Un alt aspect al mediului muncii este cultura organizationala. In acest model rolurilesunt reprezentate ca si ovaluri, iar acestea sunt conectate prin sageti daca exista o influentaıntre roluri. Intensitatea influentei dintre roluri este ilustrata prin grosimea sagetilor.Influentele sunt etichetate cu comportamentul determinat de relatia de influenta (veziFigura 2.6).

Reprezentari folosite ın proiectarea detaliata

In etapa de proiectare detaliata se are ın vedere specificarea functionalitatii, dialogului siprezentarii.

Pentru proiectarea dialogului se foloseste notatia UAN (User Action Notation). Dia-gramele UAN descriu dialogul dintre utilizator si sistem. Deoarece folosirea singulara adiagramelor UAN nu a dat rezultate ıncurajatoare, ın paralel sunt descrise si schite aleecranelor. In descrierea UAN a interactiunii sarcinile de baza ale modelului de sarcinadevin interactiunile de nivel ınalt din UAN [25].

22


Figura 2.5: Reprezentarea GTA pentru artefacturi si roluri

Figura 2.6: Reprezentarea GTA pentru cultura organizationala

UAN - User Action Notation

UAN este o notatie orientata pe utilizator si sarcina pentru reprezentarea comportamen-tului interfetelor concepute pentru manipularea directa a obiectelor si s-a dorit a fi unmecanism de comunicare ıntre proiectantii de interfete si implementatorii acestora. Speci-ficarea este atat de detaliata ıncat nici un amanunt nu este lasat la alegerea sau intuitiaimplementatorilor [11]. UAN descrie comportamentul utilizatorului si al interfetei ıntimp ce duc la ındeplinire o sarcina ın mod cooperativ. Actiunile utilizatorului, raspunsulinterfetei si starea sistemului sunt descrise simultan, iar relatiile temporale indica ordineaefectuarii actiunilor.

Notatiile UAN sunt prezentate ın tabelele 2.1 si 2.2:

23


Feedback Semnificatie! lumineaza obiectul (marcheaza selectia)-! deselecteaza obiectul!-! clipire (blink)(!-!)n clipire de n ori@x, y la punctul (x,y)@ X la obiectul Xdisplay (X) afiseaza obiectul Xerase (X) sterge obiectul XX>˜ obiectul X urmareste cursorulX>>˜ obiectul X este redimensionat corespunzator pozitiei cursoruluioutline(X) evidentiaza obiectul X

Tabela 2.1: Notatiile UAN pentru raspunsul interfetei

Actiune Semnificatie

˜ muta cursorul[X] “contextul” obiectului X˜[X] muta cursorul ın contextul obiectului X˜[x,y] muta cursorul la punctul de coordonate (x,y) ın afara oricarui obiect˜[x,y in A] muta cursorul la punctul (x,y) ın interiorul lui A˜[X in Y] muta cursorul la obiectul X din cadrul obiectului Y[X]˜ muta cursorul ın afara contextului lui Xv apasaˆ elibereazaXv apasa butonul sau tasta numita XX elibereaza butonul sau tasta numita XXv click pe buton sau tasta numita XX“abc” introdu stringul “abc” folosind echipamentul XX(xyz) introdu valoare pentru variabila xyz folosind echipamentul X∗ ınchidere reflexiva - sarcina se executa de zero sau mai multe ori+ sarcina se executa cel putin o data| | sarcina optionalaA B secventiere - executa sarcina A, apoi sarcina BOR disjunctie& ordine independenta ın efectuarea sarcinilor⇔ intermitenta - efectuarea sarcinilor se poate ımpleti|| concurenta; ıntreruperea efectuarii sarcinii∀ oricare: separator ıntre conditie si actiune sau feedback

Tabela 2.2: Notatiile UAN pentru actiunile utilizatorului

Actiunea utilizatorului Raspunsul interfetei Starea interfetei[pictograma-fisier]Mv pictograma-fisier-!:pictograma-fisier! selected=fisier

∀ pictograma-fisier’ !:pictograma-fisier’-![x,y]* [x’,y’] outline(pictograma-fisier) >˜

Mˆ @[x’,y’] display(pictograma-fisier)

Tabela 2.3: Exemplu UAN pentru mutarea pictogramei unui fisier

24


Figura 2.7: Relatia dintre ontologia sarcinilor si UAN [25]

2.3 ConcurTaskTrees - notatie diagramatica pentru

specificarea modelelor sarcinilor

ConcurTaskTrees este o notatie diagramatica pentru specificarea modelelor sarcinilor dez-voltata din dorinta de a oferi o reprezentare grafica a structurii ierarhice rezultate dinanaliza activitatii de munca [20]. Neajunsul major al metodelor de analiza a sarcinilordezvoltate anterior era acela ca nu ofereau posibilitatea exprimarii relatiilor temporaledintre sarcini. Mai mult decat atat, metode de analiza a sarcinilor precum GOMS sauTAG nu ofereau posibilitatea descrierii de sarcini care se desfasoara paralel sau concurent,ci doar descrierea de sarcini care se desfasoara secvential. ConcurTaskTrees introduce ınnotatia propusa operatorii temporali LOTOS [12], care dispun de o semantica definitaformal si care este o notatie internationala standardizata.

LOTOS (Language of Temporal Ordering Specifications)

LOTOS este un limbaj de specificare bazat pe algebra proceselor, mai exact CSP (Commu-nicating Sequential Processes). Specificarea unui sistem ın LOTOS descrie toate “urmele”(secvente de evenimente) pe care un observator extern le poate surprinde. Modelul LO-TOS al unui sistem este o “cutie neagra” care dispune de canale de comunicare cu mediulınconjurator. Sistemul poate sa-si activeze canalele prin acceptarea unei valori de pe uncanal de intrare sau oferind o valoare pe un canal de iesire.

Un proces LOTOS este expresia unui comportament care are un nume. Definirea unuiproces se face prin constructia:

<proc-name> [ <formal-gates> ] ( <params> ) : <funct> := <behavior>where<local definitions> endprocInstantierea unu proces se face astfel:<proc-name> [ <actual-gates> ] ( <parameter-values> ),iar <func> este functionalitatea: fie exit, fie noexit.

25


Operatorii LOTOS:

• alegerea - []- A [] B exprima doua alternative, alegerea uneia dintre ele depinde deprimul eveniment care apare;

• activarea - >> - A >> B se citeste A activeaza B, adica dupa terminarea cu succesa procesului A, ıncepe B;

• sincronizare totala - ‖ - X ‖ Y semnifica faptul ca toate evenimentele din X si Ysunt sincronizate.

• interschimbare - ||| - este o compunere concurenta fara interactiune.

• dezactivarea - [< - modeleaza ıntreruperea unui proces de catre alt proces. X [< Ysemnifica faptul ca ın orice moment al desfasurarii lui X se poate face o alegere ıntreexecutia actiunii urmatoare din X sau executia uneia din primele actiuni ale lui Y.Dupa alegerea unei actiuni din Y, Y continua sa se execute, iar restul actiunilor dinX devin imposibile. Daca X se ıncheie fara succes, atunci se executa prima actiunedin Y, altfel Y nu va ıncepe.

• ascunderea - hide - se foloseste pentru definirea unor actiuni locale, care nu suntvizibile ın afara procesului.

In ConcurTaskTrees o sarcina este descrisa de urmatoarele atribute:

• nume - folosit pentru identificarea sarcinii;

• tip - exista patru tipuri de sarcini:

1. utilizator - efectuate ın ıntregime de utilizator care implica activitati cognitivesau fizice care nu implica interactiunea cu sistemul (ex.: utilizatorul citesteo lista a curselor aeriene si alege una care satisface nevoile sale). Sarcinileutilizator sunt asociate cu o activitate de procesare a informatiei primite de lamediu.

2. aplicatie - sarcini efectuate complet de catre sistem, care primesc informatiede la sistem si o ofera utilizatorului. Aceste sarcini sunt initiate de aplicatie(ex.: compilarea unui program si transmiterea de mesaje de eroare, primireaunor mesaje din retea si afisarea lor).

3. interactiune - executate de utilizator ın interactiune cu sistemul, interactiuneactivata de utilizator (ex.: editarea unei diagrame, formularea unei interogaripentru o baza de date).

4. abstracte - sarcini care presupun actiuni complexe a caror efectuare completanu intra doar ın una din categoriile de tipuri de activitati prezentate anterior.

• subsarcina a - nume al sarcinii parinte;

• obiecte - vector de obiecte, fiecare obiect definit prin: nume, tip, lista actiunilorasupra obiectului. Tipul obiectelor poate fi:

– intern - se refera la o entitate care apartine aplicatiei si care trebuie mapatapentru a fi perceputa de utilizator (ex: starea unei interogari a unei baze dedate, ınregistrarile bazei de date);

26


– perceptibil - utilizatorul poate interactiona cu obiectul prin intermediul simturilor(ex.: meniuri, ferestre, pictograme, etc.);

• iterativ - valoare booleana care specifica daca sarcina e iterativa;

• prima actiune - multimea actiunilor initiale posibile;

• ultima actiune - multimea actiunilor finale posibile;

Obiectele - sunt entitati manipulate pentru ındeplinirea sarcinilor prin actiunile aso-ciate. Intre obiectele care apar pe niveluri diferite ale ierarhiei de sarcini pot aparea douatipuri de relatii:

• descompunere - un obiect de la un nivel al sarcinii poate fi descompus ın mai multeobiecte la nivelul urmator;

• rafinare - numarul actiunilor asociate unui obiect creste odata cu trecerea la un nounivel de detaliere a sarcinilor.

Actiunile - sunt asociate cu obiectele si se clasifica ın trei categorii: cognitive, logice,fizice. Pentru sarcinile care nu sunt iterative este importanta specificarea ultimei actiuni.Este la fel de important sa mentionam care sunt actiunile initiale deoarece este nevoie decunoasterea acestora la evaluarea unor expresii temporale (ex.: ın prezenta unui operatorde alegere [] sau a operatorului de deactivare (inhibare) [<).

Operatorii temporali folositi ın notatia ConcurTaskTrees sunt:

1. T1 ||| T2 - ıntretaierea - actiunile celor doua sarcini se pot desfasura ın orice ordine;

2. T1 [] T2 - alegerea - se poate alege una din cele doua sarcini dupa care ıncepeexecutia ei, cealalta devenind indisponibila pana la terminare sarcinii care a ınceputsa se execute;

3. T1 |[]| T2 - concureta cu schimb de informatie - sarcinile se executa concurent, dartrebuie sa se sincronizeze pentru schimb de informatie;

4. T1 | = | T2 - independenta - ambele sarcini trebuie sa se execute, dar odata ceexecutia unei sarcini a ınceput, cealalta se poate executa doar la terminarea primei;

5. T1 >> T2 - activarea - la terminarea sarcinii T1 este activata sarcina T2;

6. T1 [] >>T2 - activarea cu schimbare de informatie - la terminarea sarcinii T1 esteactivata T2 si ın plus ıi sunt transmise anumite valori lui T2;

7. T1 [> T2 - dezactivarea - la efectuarea unei actiuni din T2, T1 este dezactivatadefinitiv;

8. T1 | > T2 - suspendare/reluare - T2 poate sa ıntrerupa executia lui T1, iar laterminarea lui T1, T2 poate sa fie reactivata din starea ın care se afla ınainte deıntrerupere;

9. T1* - iteratia - activitatea este iterativa.

10. T1(n) - iteratie finita - T1 se executa de n ori;

11. [T1] - activitate optionala - executia lui T1 nu e obligatorie;

12. T - recursivitatea - posibilitatea includerii ın specificarea activitatii pe ea ınsasi [19].

Un exemplu de model al sarcinii CTT este prezentat ın cele ce urmeaza:

27


Figura 2.8: Modelul sarcinii pentru interactiunea cu un bancomat folosind CTT

2.4 Proiectarea interfetei utilizator pe baza modelelor

sarcinilor

Analiza si modelarea sarcinilor participa la achizitia de informatii relevante despre utiliza-tori si sarcini, informatii folosite ın proiectarea interfetei utilizator. Informatiile despreutilizatori, sarcini, contextul muncii sunt esentiale ın proiectarea de sisteme utile si uti-lizabile, ajutandu-i pe proiectanti sa ınteleaga cum pot fi sprijiniti utilizatorii ın muncalor.

Proiectarea interfetei utilizator cuprinde proiectarea functionalitatii, structurii dia-logului si prezentarii. Rezultatele analizei sarcinilor se constituie dintr-o descriere deta-liata a domeniului problemei si o determinare a aspectelor care pot fi ımbunatatite, celedin urma constituind scopurile proiectarii sistemului (cerintele). Trecerea de la analiza laproiectare este dificila, deoarece presupune pe langa o serie de pasi bine definiti (inginerie)si creativitate. In aceasta faza se ıncearca gasirea raspunsului la ıntrebari precum:

• care sunt principalele ecrane?

• care sunt datele care trebuie reprezentate si care sunt cele care se constituie maidegraba ın atribute?

• ce stil de interactiune este mai potrivit?

• cum ar trebui sa navigheze utilizatorul ıntre ecrane?

• cum se va face accesibila functionalitatea sistemului?

In practica se porneste cu o proiectare initiala creata pe baza analizei sarcinilor careeste supusa unui proces iterativ de evaluare/modificare. Pasii care trebuie urmati ıntrecerea de la analiza la proiectare sunt urmatorii:

1. dezvoltarea unui model conceptual al universului activitatii (fara referiri la instru-mente sau sisteme folosite);

2. identificarea sarcinilor majore si obiectelor care trebuie sa faca parte din sistem;acestea vor forma structura de nivel ınalt a interfetei;

28


3. structurarea aplicatiei;

4. crearea cailor de navigare ın structura interfetei utilizator ın functie de structuraactivitatii;

5. proiectarea prezentarii ın functie de stilul platformei[27].

Deoarece notiunea de interfata utilizator are un sens restrictiv, pentru majoritatea avandsemnificatia de ecrane, s-a ales folosirea termenului de masina virtuala a utilizatorului(UVM - User’s Virtual Machine) care cuprinde toate aspectele sistemului relevante pentruutilizator. Astfel, proiectarea masinii virtuale a utilizatorului ınseamna, conform mo-delului lui Seeheim, proiectarea functionalitatii, dialogului si prezentarii. UVM e specificaunui rol si sarcinilor asociate, iar pentru ca sistemele sunt proiectate pentru mai multeroluri e necesara proiectarea mai multor UVM-uri care sunt mai apoi integrate, prinurmare orice proiectare este un compromis.

Proiectarea functionalitatii este diferita de proiectarea arhitecturii aplicatiei, refe-rindu-se la functionalitatea aplicatiei ın masura ın care este relevanta pentru utilizator sicare ıi va fi prezentata prin intermediul interfetei utilizator. Pentru a realiza activitatiutilizatorii efectueaza actiuni asupra obiectelor, astfel ca la proiectarea functionalitatiiproiectantii trebuie sa aleaga obiectele care vor face parte din sistem, structura si relatiiledintre ele si trebuie sa descrie actiunile care pot fi efectuate asupra lor. Sarcinile sprijinitede sistem vor oferi baza pentru fixarea cailor de navigare la un nivel ınalt si care vor fitranspuse ın structura interfetei utilizator. Functionalitatea sistemului trebuie sa fie binealeasa astfel ıncat sa sprijine realizarea sarcinilor din modelul activitatii. Functionalitateava influenta arhitectura softului deoarece functionalitati specifice vor impune constrangeriasupra implementarii (ex: nivele multiple de Undo/Redo impun folosirea unei cozi decomenzi).

Proiectarea dialogului - dialogul se refera la structura si comportamentul dinamical interfetei utilizator, fara a lua ın considerare prezentarea. La nivelul dialogului nu esteimportant modul ın care arata o componenta a interfetei utilizator, ci daca e modala saunu, ce continut are si cum e structurat. La acest nivel trebuie definite componentele ma-jore din structura interfetei si dinamica interfetei utilizator (ex: deschiderea unei ferestrepoate determina ınchiderea altei ferestre). In dialogul om-calculator un rol importantıl are comportamentul utilizatorului care cuprinde actiuni fizice si actiuni mentale careocupa un timp considerabil ın executia sarcinilor. Pentru a ımbunatati performanteleutilizatorului trebuie sa se ofere o structura navigationala buna ınsotita de prezentareaelementelor relevante pentru executia sarcinilor.

Proiectarea prezentarii - se refera la aspectele vizibile ale interfetei utilizator, darsi la feedbackul auditiv si cel tactil (ın cazul utilizarii force-feedback-ului). Folosireaculorilor poate duce la prevenirea erorilor si la memorarea semanticii obiectelor interfetei.Gruparea logica a elementelor are un efect pozitiv ın gasirea rapida a informatiei.

29

Capitolul 3

Instrumente pentru analizaactivitatii de munca

Numarul instrumentelor comerciale folosite ın fazele timpurii ale proiectarii interfetelorbazata pe analiza sarcinilor este scazut, dar numarul de instrumente dezvoltate ın ac-tivitati de cercetare este superior. In functie de fazele de proiectare pe care le acoperaaceste instrumente se clasifica ın:

• instrumente pentru extragerea cerintelor: EL-TaskModels, U-TEL;

• instrumente pentru modelare: CTTE, QGOMS, GOMSED, ALACIE, EUTERPE;

• instrumente pentru analiza si simulare: CTTE, QGOMS, GOMSED, TAMOSA,EUTERPE;

Nu vom oferi o prezentare a tuturor instrumentelor mentionate anterior datoritaurmatoarelor aspecte: instrumente precum QGOMS si GOMSED se bazeaza pe analizaGOMS ale carei carente au fost prezentate ın capitolul 1 al acestei lucrari; alte instrumentenu sunt disponibile gratuit pe Internet. In plus, dintre instrumentele disponibile, nu toateofera functionalitati complete necesare analizei sarcinilor, astfel ıncat atentia noastra s-aoprit asupra instrumentelor EUTERPE (instrument asociat metodei de analiza GTA),respectiv ConcurTaskTreesEnvironment (asociat notatiei ConcurTaskTrees). O motivatieın plus pentru prezentarea celor doua instrumente este data de faptul ca sunt comple-mentare, ın urmatorul sens: metoda GTA ofera un cadru conceptual bine conturat pentruanaliza activitatii, cu fundamente solide ın analiza muncii. Instrumentul asociat metodei,EUTERPE, ofera facilitati deosebite pentru achizitia datelor, construirea si analiza Mode-lului 1 (descriptiv) al sarcinilor, cu mentiunea unor lacune ın ceea ce priveste exprimarearelatiilor temporale. Pe de alta parte, CTTE nu dispune de un cadru teoretic la fel desolid pe baza caruia sa se faca analiza sarcinilor, dar exceleaza ın construirea Modelului 2al sarcinilor si ın specificarea precisa a relatiilor temporale prin folosirea operatorilor LO-TOS. Mai mult decat atat, procesul de analiza si modelare a sarcinilor continua pana lascopul final, si anume generarea unei specificari abstracte a interfetei utilizator. Folosireaambelor instrumente sprijina procesul complet de dezvoltare a interfetelor utilizator pebaza analizei sarcinilor, pornind de la achizitia datelor pana la generarea interfetei pebaza informatiilor culese si deciziilor de proiectare luate.

3.1 CTTE - ConcurTaskTrees Environment

CTTE este un instrument dezvoltat la Universitatea din Pisa care poate fi utilizat ınanaliza si modelarea sarcinilor. Instrumentul ofera un editor grafic pentru ierarhiile de

30

CAPITOLUL 3. INSTRUMENTE PENTRU ANALIZA ACTIVITATII DE MUNCA

sarcini. Sarcinile pot avea diverse tipuri: abstracte, utilizator, aplicatie sau interactiune,fiecare tip de sarcina avand o pictograma asociata (astfel este exprimata sugestiv alocareasarcinilor ın cadrul organizatiei). Ierarhiile de sarcini includ operatori LOTOS pentru aexprima constrangerile temporale care apar ıntre sarcini. Instrumentul permite verifi-carea structurii modelului, transformarea din specificatie informala ın specificatie formalaa sarcinilor pe baza unor scenarii, transformarea modelului ın specificatie LOTOS, conver-sia fisierelor de descriere ın diferite formate (HTML, XML, JPG), editarea de diagrame deutilizare UML, analiza tangibilitatii unor stari, simularea executiei modelului sarcinilor.Mai mult decat atat, instrumentul genereaza pe baza descrierilor ierarhiilor de sarcinimultimi de prezentari (Presentation Task Sets), care se constituie ın intrari pentru proce-sul de constructie a specificarii abstracte a interfetei pe baza informatiilor despre sarcini(frecventa, obiecte manipulate, tipul interactiunii - selectare, control sau editare) si a con-strangerilor temporale dintre ele. Instrumentul permite descrierea modelului sarcinilorpentru cazul ın care activitatea e realizata de un singur utilizator, respectiv pentru cazulın care activitatea e realizata ıntr-un mod cooperativ (situatie ın care apare si conceptulde rol).

Alaturi de acest instrument este disponibil de asemenea gratuit un alt instrumentdenumit EL-TaskModels care pe baza descrierii unui scenariu ıncarcat ın instrument ajutaanalistul ın identificarea rolurilor, obiectelor si sarcinilor, rezultand un ConcurTaskTree.

3.2 EUTERPE

EUTERPE este un instrument pentru analiza sarcinilor dezvoltat la Universitatea Liberadin Amsterdam si care are la baza ontologia definita de metoda GTA. Premisa de la cares-a plecat ın definirea ontologiei a fost ca sunt prea putine sarcinile efectuate de un singurutilizator si ca tendinta actuala este ca activitatile sa se desfasoare ın mod cooperativ.

Instrumentul permite crearea de ierarhii de sarcini, specificarea rolurilor responsabilepentru sarcini, specificarea obiectelor manipulate ın realizarea fiecari sarcini, specificareaevenimentelor care declanseaza o anumita sarcina sau specificarea sarcinilor declansatede efectuarea unei sarcini. Pentru fiecare sarcina e posibila specificarea starii initiale,ınainte de executia sarcinii, a conditiilor de efectuare a unei sarcinii, precum si a stariifinale, dupa executia sarcinii si a postconditiilor. In EUTERPE nu exista un formalismspecific pentru exprimarea constrangerilor temporale, acestea fiind deduse din specificareaproprietatilor de declansare ale sarcinilor sau prin specificarea unor constructori (similariMAD). Instrumentul permite crearea unui flux al sarcinilor (workflow), ın care acesterelatii temporale primesc o reprezentare grafica expresiva. Alaturi de functionalitatea deeditare a arborilor de sarcini instrumentul dispune de o optiune pentru analiza modeluluicare se face pe baza constrangerilor enuntate ın Capitolul 2, dar analiza se poate facesi pe baza unor euristici (ex.: sarcini efectuate de un anumit rol, roluri responsabilepentru mai mult de o sarcina, etc.). Modelele pot fi facute publice datorita facilitatii degenerare a unor documente HTML care prezinta modelele sarcinilor si permit navigareaıntre conceptele ontologiei prin intermediul unor hiperlegaturi.

3.3 Cerinte pentru instrumentele de analiza a ac-

tivitatii

Instrumentele de analiza de sarcina se afla doar la un timid ınceput, dar au reusit chiarsi ın stadiul la care se afla sa-si dovedeasca utilitatea si aplicabilitatea [26, 24, 25, 19, 10].

31

CAPITOLUL 3. INSTRUMENTE PENTRU ANALIZA ACTIVITATII DE MUNCA

Analiza sarcinilor ınseamna mai mult decat editarea de ierarhii de sarcini. Analizasarcinilor se bazeaza pe concepte si relatii ıntre concepte, iar pe baza acestor relatii sepot verifica propietati ale modelelor sarcinilor. In analiza sarcinilor este important sa seofere mai multe reprezentari ale modelelor, iar ın acest caz consistenta ıntre reprezentarie o cerinta esentiala.

La fel ca si alte activitati de proiectare, modelarea si analiza sarcinilor este preferabilsa se realizeze ın echipe. Este o cerinta esentiala ca dezvoltarea de modele sa poata firealizata ın mod cooperativ. Instrumentele dezvoltate pana ın prezent nu sprijina astfelde activitati cooperative. Gestiunea versiunilor si a schimbarilor este un aspect delicat sicomplex, dar care este imperios necesar atata timp cat ne dorim ca proiectarea sistemelorinformatice sa fie ıntr-adevar o activitate interdisciplinara.

In analiza sarcinilor o etapa esentiala o reprezinta culegerea de informatii. Un instru-ment de analiza a sarcinilor ar trebui sa poata prezenta utilizatorilor baza pe care aufost luate anumite decizii ın ierarhizarea sarcinilor, asocierea rolurilor, obiectelor, respon-sabilitatilor, etc. Deoarece multe din informatiile culese iau forma unor fragmente audio,iamgini ale obiectelor sau fragmente video, un instrument trebuie sa aiba capacitatea dea le manipula si de a le pune la dispozitia tuturor celor interesati.

In situatiile unor proiecte mari, este importanta stocarea evolutiei specificatiilor si amotivelor care determina anumite decizii. Simpla asociere a unor notite nu este ıntotdeaunacea mai buna cale de a pastra astfel de informatii de aceea includerea unor tehnici precumQOC (Questions Options Criteria) ar trebui sa fie disponibile.

Din toate aceste cerinte rezulta directiile de dezvoltare care trebuie urmate ın dez-voltarea de instrumente de analiza si modelare a sarcinilor.

32

Capitolul 4

DUTCH - metoda de proiectarebazata pe analiza activitatii

DUTCH (Designing for Users and Tasks from Con-

cepts to Handles)

DUTCH este o metoda pentru proiectarea sistemelor complexe si necesita participareaunor echipe multidisciplinare (programatori, psihologi, etnografi, proiectanti industriali),fiecare responsabila pentru un anumit aspect al proiectarii. Datorita caracterului mul-tidisciplinar al persoanelor implicate ın proiectare apar constrangeri ın ceea ce privestefolosirea documentatiei, alegerea reprezentarilor care variaza de la metode formale panala schite informale sau scenarii. Aplicarea metodei presupune alocarea activitatilor com-plementare unor grupuri specializate care cuprind 3-5 persoane. Comunicarea ıntre acestegrupuri trebuie gestionata cu atentie, ın sensul ca e indicata folosirea unei combinatii demetode formale si informale.

O metoda practica de proiectare impune respectarea urmatoarelor cerinte:

1. definirea clara a unui proces;

2. definirea modelelor si reprezentarilor ımpreuna cu semantica lor;

3. dezvoltarea de instrumente care sprijina crearea modelelor si folosirea metodei [29].

Metoda de proiectare DUTCH este bazata pe sarcina de munca, ceea ce ınseamna cafoloseste sarcinile utilizatorilor ca forta de conducere ın procesul de proiectare. Se con-sidera ca pentru a dezvolta sisteme utile si utilizabile este nevoie ca proiectarea sistemelorsa aiba la baza munca pe care oamenii trebuie sa o desfasoare.

Procesul de proiectare consta din patru activitati principale:

1. analiza situatiei curente de munca;

2. imaginarea unei situatii viitoare de munca pentru care se proiecteaza solutia infor-matica;

3. specificarea tehnologiei informatice care se proiecteaza;

4. evaluarea activitatilor anterior specificate, care va face procesul de proiectare ciclic.

Procesul de proiectare ıncepe printr-o analiza extensiva a sarcinilor, folosind metodaGTA. Analiza se va finaliza cu descrierea muncii, situatiilor de munca, a utilizatorilor si

33

CAPITOLUL 4. DUTCH - METODA DE PROIECTARE BAZATA PE ANALIZAACTIVITATII

Figura 4.1: Procesul de proiectare a sistemelor interactive complexe folosind metodaDUTCH [29]

a altor persoane afectate de introducerea unui nou sistem. GTA presupune construireaa doua modele ale sarcinilor: modelul 1 al sarcinilor care este folosit ın analiza situatieicurente a activitatii, este deci un model descriptiv, iar pe baza acestui model se con-struieste modelul 2 al sarcinilor, care este un model descriptiv. MA1 este construit decatre psihologi si etnografi, iar la construirea MA2 participa reprezentantii tuturor disci-plinelor anterior mentionate.

Trecerea de la modelul 1 al sarcinilor la modelul 2 al sarcinilor este cel mai importantpas ın procesul de proiectare DUTCH. Pe baza cerintelor clientilor si a problemelor de-tectate ın modelul 1 al sarcinilor si a dorintelor si ideilor utilizatorilor si altor persoaneimplicate se formuleaza cerintele de (re)proiectare. Toate disciplinele contribuie la pro-punerea de ımbunatatiri sau schimbari, iar aceste propuneri sunt evaluate ın raport curesursele disponibile, utilizabilitate, fezabilitate. Modelul 2 al sarcinilor va fi structuratsimilar modelului 1, dar nu va mai fi un model descriptiv al cunostintelor utilizatorului, ciun model prescriptiv al cunostintelor pe care un utilizator expert al noii tehnologii trebuiesa le posede.

Etapa de proiectare detaliata consta din specificare tehnologiei proiectate. Punctulde pornire pentru proiectarea detaliata este modelul 2 al sarcinilor, la care se adaugadecizii legate de prezentare (look and feel), proiectarea dialogului, proiectarea si ergonomiahardului. Specificarile sarcinilor din MA2 sunt folosite ca baza ın deciziile legate defunctionalitatea sistemului, ın masura ın care aceasta este relevanta pentru utilizator.Pornind de la structura sarcinilor se determina o grupare initiala a functiilor si se descriestructura de navigare principala. Pe baza specificatiilor rezultate si a recomandarilor siprincipiilor de proiectare se construieste un prototip care este supus unor teste de utili-zabilitate cu utilizatori directi. Rezultate evaluarii vor determina modificari ale proiectariiUVM, pana cand rezultatele obtinute la testele de utilizabilitate sunt cele asteptate. La

34


final, pe baza specificarilor UVM se trece la implementarea sistemului interactiv.Metoda de reprezentare a rezultatelor analizei sarcinilor a luat forma arborilor de

sarcini. Metodele consacrate de analiza a sarcinilor precum GOMS sau TAG foloseaumodalitati formale de descriere a structurilor sarcinilor care luau forme textuale, dar carenecesitau experienta ın folosirea metodei pentru a putea fi ıntelese. Reprezentarea graficaeste usor de urmarit si ınteles de catre diverse persoane, mai ales cand arborele continepana la 20 sarcini. Sarcinile din arborii de sarcini au atasate imagini, interviuri saufragmente video, pentru a argumenta structurarea sarcinilor ıntr-o anumita maniera.

Reprezentarile folosite ın etapa de proiectare detaliata iau forma schitelor, capturilorde ecran (screenshots), prototipuri si descrieri UAN (User Action Notation). Acestereprezentari sunt atat de detaliate astfel ıncat pe baza lor se construieste un prototip,iar apoi se implementeaza ıntregul sistem. In faza de evaluare se folosesc scenariile, carereprezinta o descriere informala a sarcinilor care e posibil sa apara simultan ıntr-o anu-mita situatie si care includ o descriere detaliata a implicarii utilizatorului. Scenariile ısidovedesc utilitatea atunci cand sunt puse ın practica (jucate). Este recomandat ca “ac-torii” unor astfel de scenarii sa fie utilizatori care sunt sceptici sau se tem de introducereanoii tehnologii, pentru ca ei pot releva situatii de esec ale sistemului.

Metoda DUTCH a fost adoptata ın 4 universitati din Olanda, 2 universitati dinRomania si este folosita ın practica de o companie din Austria preocupata de proiectarede sisteme critice [29].

4.1 Studiu de caz: aplicarea metodei DUTCH

ın proiectarea unui sistem interactiv pentru

evaluarea posturilor de munca

Activitatea de evaluare a posturilor de munca este esentiala ın cadrul departamentuluide resurse umane al oricarei institutii, deoarece rezultatele evaluarii determina nivelulde salarizare pentru fiecare din posturile organizatiei [22]. Evaluarea posturilor este oactivitate care impune colaborarea dintre psihologul care demareaza procesul de evalu-are si expertii din cadrul organizatiei care vor efectua ın mod real evaluarea. Psihologuleste cel care stabileste o serie de factori relevanti ın evaluare defalcati ıntr-o serie de di-mensiuni care au atasate niste niveluri valorice (valorile numerice sunt cunoscute doar depsiholog). Expertii primesc lista posturilor de evaluat si lista dimensiunilor si factorilorasociati ımpreuna cu instructiunile de evaluare (ın care sunt definite dimensiunile, fac-torii si semnificatia fiecaruia din niveluri). Folosind lista de instructiuni, fiecare expertrealizeaza individual evaluarea posturilor. La ıncheierea evaluarii psihologul centralizeazarezultatele, acorda puncte corespunzator nivelurilor, calculeaza media punctajelor pen-tru fiecare post si stabileste o ierarhie a posturilor. Urmeaza o analiza comparativaıntre nivelul actual de salarizare al fiecarui post si punctajul obtinut prin intermediultrasarii dreptei de regresie. Din reprezentarea grafica se vor contura neconcordantele din-tre salarizare si importanta postului pentru organizatie. Acesta este scenariul activitatiide evaluare asa cum se petrece el ın mod curent.

Am abordat problema proiectarii sistemului dintr-un punct de vedere procesual, cu in-fuzie cognitivista. Punctul de plecare ın proiectarea sistemului este activitatea (evaluareamuncii). Orice activitate se compune din ındeplinirea unei multimi de sarcini interconec-tate (crearea listei de evaluatori, realizarea secventei de evaluare, etc.). La baza realizariiunei sarcini vom gasi o suita de actiuni (introducerea posturilor, introducerea expertilorevaluatori, etc). Aceasta viziune asupra analizei activitatii este un pas ınainte fata de

35


abordarea behaviorista care nu pune accent tocmai pe abordarea procesului operational,eludand implicatiile psihologice pe care acesta le are ın functionarea optima a sistemuluiinteractiv. Metoda DUTCH se dovedeste a fi cea mai potrivita pentru o astfel de abor-dare a proiectarii sistemului interactiv. Aplicand metoda DUTCH, primul pas este acelade a descrie primul model al activitatii. Rolurile identificate din descrierea activitatiisunt: psiholog si expert. Obiectele manipulate de acestia ın procesul de evaluare sunt:lista posturilor din organizatie (organigrama), lista instructiunilor, lista dimensiunilor sifactorilor, ierarhia de posturi, respectiv dreapta de regresie. Agentii sunt persoane carac-terizate prin folosirea limbii romane si cunostinte medii de operare cu sisteme informatice.Scopul principal al acestei activitati este obtinerea unei ierarhii a posturilor, iar sarcinilede care sunt responsabile cele doua roluri rezulta din descrierea anterioara. Arborele pen-tru sarcina cooperativa si aroborii de sarcini pentru cele doua roluri sunt prezentati ınfigurile 4.2, 4.3, 4.4:

Figura 4.2: Modelul 1 al sarcinilor cooperativ

Figura 4.3: Modelul 1 al sarcinilor pentru rolul Psiholog

De partea psihologului sarcinile solicitante sunt cele legate de centralizare a evaluarilorexpertilor, conversia nivelurilor factorilor ın punctaje, calculul punctajelor medii, deter-minarea ierarhiei posturilor precum si desenarea dreptei de regresie, sarcini ındeplinite ınmod manual sau semiautomatizat folosind diverse instrumente (calculatoare, MSExcel).Aceste sarcini pot fi delegate unui sistem interactiv care sa preia rezultatele evaluarilor sisa efectueze actiunile complexe de centralizare si ierarhizare a datelor. Pentru a se puteapastra o evidenta a evolutiei posturilor ın timp, este util ca psihologul sa poata identifica sigestiona rezultatele ın timp ale evaluarilor, motiv pentru care viitorul sistem informatic ıiva oferi psihologului posibilitatea de creare a unor sesiuni noi de evaluare cu configurareaacesteia (stabilirea dimensiunilor si factorilor evaluati precum si a expertilor participanti

36


Figura 4.4: Modelul 1 al sarcinilor pentru rolul Expert

la evaluare). Deoarece subiectul principal al evaluarii ıl reprezinta posturile din cadrulorganizatiei, a caror evolutie ın timp variaza se considera utila oferirea functionalitatii degestiune a posturilor (adaugarea, stergerea acestora). De asemenea, la evaluare participaexperti din cadrul organizatiei, care ınsa pot sa ramana sau sa paraseasca organizatia,prin urmare psihologul trebuie sa poata actualiza lista expertilor din organizatie. Procesulde evaluare pe puncte are la baza criteriile de evaluare stabilite prin factorii dimensiunilorde evaluat, acestia putand varia de la o evaluare la alta. Pe baza acestei constatari, s-adecis utilitatea introducerii functionaltatii de adaugare/modificare a unor noi dimensi-uni/factori. In final, rezultatele evaluarilor trebuie sa-i fie aduse ıntr-o forma cat maiconcisa si relevanta psihologului. Sistemul proiectat va trebui sa furnizeze functionalitatede vizualizare a ierarhiei posturilor. Deoarece ın contexte diferite e nevoie de reprezentaridiferite, sistemul va oferi posibilitatea vizualizarii rezultatelor ın format de raport (im-primabil), respectiv sub forma de grafic (vezi figura 4.9, respectiv 4.10). Pentru a de-termina existenta unor neconcordante ın ceea ce priveste nivelul salarizarii, sistemul vafurniza functionalitate de trasare a dreptei de regresie. Modelul 2 al sarcinii pentru rolulpsiholog, prezentat ın figura 4.5 va sugera delegarea unui numar mare din sarcini sistemu-lui interactiv, fapt ce justifica fezabilitatea automatizarii procesului de evaluare.

Figura 4.5: Modelul 2 al sarcinilor pentru rolul Psiholog

Meniul prezentat psihologului la ınceperea unei sesiuni de lucru este ın consecintacel din figura 4.6 (partea stanga), ımpreuna cu prezentarea dreptei de regresie (parteadreapta).

Activitatea de evaluare implica o colaborare ıntre doua roluri: cel de psiholog si celde expert. Expertii sunt acele persoane cu un nivel ridicat al cunostintelor din domeniu.Acestia sunt solicitati a eticheta fiecare factor din lista de evaluare pentru fiecare post cunivelul corespunzator (pentru alegerea nivelelor expertii au la dispozitie definitiile fiecaruinivel pentru fiecare factor). Evaluarea posturilor implica parcurgerea listei posturilor,parcurgerea listei factorilor si stabilirea nivelului corespunzator. Sistemul interactiv vatrebui sa ıi prezinte expertului lista posturilor, lista dimensiunilor si factorilor si acces

37


Figura 4.6: Meniul pentru rolul Expert si Dreapta de regresie

la definitiile acestor factori si posibilitatea alegerii unui nivel. Arborele de sarcini dupaintroducerea solutiei informatice pentru rolul Expert este cel din figura 4.7.

Figura 4.7: Modelul 2 al sarcinilor pentru rolul Expert

Obiectele manipulate de psiholog ın procesul de evaluare sunt dispuse ıntr-un singurecran, care contine o lista a sesiunilor de evaluare la care psihologul este participant simai exista posturi neevaluate, lista posturilor (care mai trebui evaluate ın cadrul sesiu-nii selectate) si un tabel care permite selectarea nivelului corespunzator sau consultareainstructiunilor de evaluare (definitii ale dimensiunilor si nivelurilor factorilor) (vezi figura4.8).

Dezvoltarea sistemului a respectat procesul DUTCH prin ınceperea procesului deproiectare cu analiza extensiva activitatii pentru rolurile identificate, stabilirea secventeide sarcini care duc la ındeplinirea activitatii si identificarea obiectelor relevante pentruactivitate din domeniul muncii, urmate de dezvoltarea iterativa de prototipuri ale sistemu-lui si prezentarea acestora viitorilor utilizatori. In final, sistemul a fost supus testului deutilizabilitate SUS (System USability Scale) [6] cu 20 subiecti reali, rezultatul de 76%constituind o ıncurajare ın demersul adoptarii metodei DUTCH ın proiectarea de sistemeinteractive. Testul SUS este disponibil ın Anexa A din prezentul referat.

38


Figura 4.8: Fereastra de evaluare

Figura 4.9: Prezentarea ierarhiei posturilor sub forma de grafic

Figura 4.10: Prezentarea ierarhiei posturilor sub forma de raport

39

Capitolul 5

Activitati ın derulare si directii decercetare

Experienta aplicarii metodelor de analiza activitatii ın proiectarea sistemelor interactivea necesitat folosirea instrumentelor disponibile pentru editarea arborilor de sarcini, me-morarea obiectelor din ontologia GTA si verificarea corectitudinii modelului conform cri-teriilor enumerate ın capitolul 2. EUTERPE s-a dovedit a fi un sprijin real pentru creareaunui “depozit” cu informatiile relative crearii modelului 1 al sarcinilor, cu exceptia faptu-lui ca desi metoda impune descrierea structurii sarcinilor pentru fiecare rol, instrumentulnu ofera posibilitatea construirii acestor arbori de sarcini ın cadrul aceleiasi sesiuni delucru si sublinierea partilor interactive, functionalitate sprijinita ınsa de CTTE.

Pentru etapa de construire a modelului 2 al sarcinilor CTTE si-a dovedit superioritateaprin oferta de tipuri diverse de sarcini, reprezentate prin pictograme sugestive si prinposibilitatea specificarii relatiilor temporale dintre sarcini. Posibilitatea specificarii tipuluiobiectelor asociate fiecarei sarcini (perceptibil sau aplicatie), a tipului interactiunii (moni-torizare, control, editare, generare de eveniment) constituie initiative apreciabile pentruspecificarea prezentarii interfetei utilizator. Trebuie remarcat ınsa ca CTTE sprijina doaretapa de construire a modelului 2 al sarcinilor, deoarece toate proprietatile editabile alesarcinilor sunt legate de interfata utilizator, ori ın construirea modelului 1 al sarcinilor enevoie de descrierea obiectelor din lumea reala.

Deoarece metoda DUTCH si-a dovedit ın repetate randuri utilitatea [26, 24, 25], con-sideram necesara dezvoltarea unui instrument care sa sprijine procesul de analiza integral,ımbinand aspectele pozitive ale instrumentelor deja dezvoltate. Initiativa noastra estecea de dezvoltare a unui instrument care sa suplineasca lipsurile instrumentelor studiate.Obiectivul este acela ca instrumentul sa ofere posibilitatea dezvoltarii celor doua modeleale sarcinilor specifice GTA, si mai mult decat atat sa genereze o specificare a interfeteiutilizator ın limbajul UIML [18, 4]. Alegerea unui astfel de tip de iesiri ın urma procesu-lui de proiectare se justifica prin faptul ca exista actualmente instrumente precum Liquid[1] care transforma specificarile UIML ın interfete utilizator descrise ın limbaje variate(pana ın prezent este vorba de Java, WML, HTML si exista proiecte ın derulare pentruplatforma .NET).

Pana ın prezent instrumentul are implementata optiunea de editare a modelelor desarcina, cu posibilitatea editarii proprietatilor sarcinilor conform metodei GTA si salvareamodelelor ın format XML, conform unui DTD (prezentat ın Anexa B). Modelele sarcinilorpot fi salvate de asemenea ın format persistent prin serializare. Functionalitatea propusaspre realizare pentru prima versiune a prototipului este expusa prin intermediul meniuluiprezentat ın figura 5.1.

Editarea modelelor de sarcini se realizeaza folosind ca stil de interactune manipularea

40

CAPITOLUL 5. ACTIVITATI IN DERULARE SI DIRECTII DE CERCETARE

Figura 5.1: Optiunile oferite de prototipul GTATool

directa, utilizatorul avand la dispozitie o bara de instrumente ce contine reprezentari aletipurilor de sarcini din clasificarea CTT. La editarea arborelui de sarcini se fac si primeleverificari ale corectitudinii arborelui pe baza urmatoarelor criterii: radacina unui arboretrebuie sa fie o sarcina abstracta, o sarcina abstracta nu poate fi fiu decat al altei sarciniabstracte, o sarcina abstracta trebuie sa aiba cel putin doua subsarcini si o sarcina utiliza-tor nu poate avea ca subsarcina decat o alta sarcina utilizator. In dezvoltarea interfeteiutilizator s-au folosit framework-urile jhotdraw [3] care permite crearea de interfete graficesi desenarea de obiecte grafice si JGoodies [2], care permite aranjarea si implementareade forme folosind Swing ıntr-o maniera elegenta si eficienta.

Figura 5.2: Fereastra principala a instrumentului GTATool

Aspectele de interes imediat ın dezvoltarea acestui instrument sunt cele legate deintroducerea unor operatori temporali ın arborii de sarcini, simularea executiei sarcinilorconform operatorilor temporali, stabilirea obiectelor de interactiune necesare ferestreloraplicatiilor pentru interactiune si ın final generarea fisierelor UIML. O prioritate este siverificarea corectitudinii modelelor conform constrangerilor prezentate ın capitolul 2 alreferatului.

O alta directie de studiu se refera la posibilele conexiuni care exista ıntre proiectareasistemelor de workflow si analiza activitatii, dat fiind ca ın proiectare sistemelor de work-flow conceptele de baza [5] sunt aceleasi pe care se sprijina si metodele de proiectare asistemelor interactive bazate pe analiza activitatii.

41

Anexa A

System Usability Scale (SUS)

@Digital Equipment Corporation, 1986 [6]

1. Consider ca mi-ar placea sa folosesc ın mod frecvent acest sistem.

Dezacord Acordputernic puternic

1 2 3 4 5

2. Consider ca sistemul este mai complicat decat ar fi necesar.


1 2 3 4 5

3. Cred ca sistemul este usor de folosit.


1 2 3 4 5

4. Cred ca am nevoie de suport tehnic din partea unui specialist pentru a folosi acestsistem.


1 2 3 4 5

42

ANEXA A. SYSTEM USABILITY SCALE (SUS)

5. Cred ca functiuni diferite ale acestui sistem sunt bine integrate.


1 2 3 4 5

6. Mi se pare ca este prea multa incosistenta ın acest sistem.


1 2 3 4 5

7. Consider ca multi oameni ar ınvata repede sa foloseasca acest sistem.


1 2 3 4 5

8. Sistemul acesta mi s-a parut foarte dificil de folosit.Dezacord Acordputernic puternic

1 2 3 4 5

9. M-am simtit ıncrezator ın performantele sistemului cand l-am folosit.


1 2 3 4 5

10. A trebuit sa ınvat foarte multe lucruri ınainte sa pot initia folosirea sistemului.


1 2 3 4 5

43

Anexa B

DTD pentru memorarea arborilor desarcini

<?xml version = ”1.0”encoding = ”UTF − 8”? >

<!ELEMENT tasktree (task+) >

<!ELEMENT task (name, role∗, object∗, event∗, agent∗) >

<!ATTLIST task

id ID #REQUIRED

ref IDREF #REQUIRED

type (abstraction | user | interaction | application) #REQUIRED

goal CDATA #IMPLIED

start CDATA #IMPLIED

stop CDATA #IMPLIED

initial state CDATA#IMPLIED

final state CDATA#IMPLIED

duration CDATA#IMPLIED

frequency CDATA#IMPLIED

user actions CDATA#IMPLIED

system operations CDATA#IMPLIED

>

<!ELEMENT name (#PCDATA) >

<!ELEMENT role (#PCDATA) >

<!ATTLIST role

name CDATA #IMPLIED

goal CDATA #IMPLIED

>

<!ELEMENT object (#PCDATA) >

<!ATTLIST object

44

ANEXA B. DTD PENTRU MEMORAREA ARBORILOR DE SARCINI

name CDATA #IMPLIED

description CDATA #IMPLIED

>

<!ELEMENT event (#PCDATA) >

<!ATTLIST event

name CDATA #IMPLIED

description CDATA #IMPLIED

>

<!ELEMENT agent (#PCDATA) >

<!ATTLIST agent

name CDATA #IMPLIED

skills CDATA #IMPLIED

attitude CDATA #IMPLIED

>

45

Bibliografie

[1] ***. http://www.harmonia.com/resurces, Harmonia, inc.

[2] ***. www.jgoodies.com.

[3] ***. www.jhotdraw.org.

[4] M. Abrams and C. Phanouriou. UIML: An XML language for building device-independent user interfaces, 1999.

[5] P. Barthelmess and J. Wainer. Workflow systems: a few definitions and a few sugges-tions. In COCS ’95: Proceedings of conference on Organizational computing systems,pages 138–147. ACM Press, 1995.

[6] J. Brooke. SUS - A “quick and dirty” usability scale.http://www.cee.hw.ac.uk/ ph/sus.html. User information Architecture A/DGroup, Digital Equipment Co. Ltd.

[7] S. Card, T. Moran, and A. Newell. The Psychology of Human-Computer Interaction.Cariere. Lawrence Erlbaum Associates, 1983.

[8] G. de Haan. ETAG A Formal Model of Competence Knowledge for User InterfaceDesign. PhD thesis, Vrije Universiteit Amsterdam, 2000.

[9] A. Dix and al. Human-Computer Interaction. Prentice Hall, 1993.

[10] Paterno F. Model-based tools for pervasive usability. Interacting with Computers,2004.

[11] H. Hartson, A. Siochi, and D. Hix. The UAN: A user-oriented representation fordirect manipulation interface designs. ACM Transactions on Information Systems,8(3):181–203, 1990.

[12] ISO/IEC. Information Processing Systems Open Systems Interconnection:. LOTOS,a Formal Description Technique Based on the Temporal Ordering of ObservationalBehaviour. IS 8807, 1989.

[13] G. Iosif and A. Marhan. Introducere ın interactiunea om-calculator, chapter Analizasarcinii, pages 97–116. Matrix Rom, Bucuresti, 2003.

[14] H. Johnson and P. Johnson. Integrating task analysis into system design. Ergonomics,32(11):1451–1467, 1990.

[15] C. Larman. Applying UML and Patterns: An Introduction to Object-Oriented Analy-sis and Design. Prentice Hall, 1997.

[16] A. Leontiev. Le development du physicisme. Paris: Editions Sociales, 1972.

46

BIBLIOGRAFIE

[17] J. Leplat. Ergonomie cognitiva: teorii, modele, aplicatii, chapter Analiza psihologicaa activitatii ın situatie de munca, pages 16–43. Matrix Rom, Bucuresti, 2004.

[18] F. Mir, M. Prez-Quiones, and Abrams M. A multi-step process for generating multi-platform user interfaces using UIML, 2001.

[19] G. Mori, F. Paterno, and C. Santoro. CTTE: Support for developing and analyzingtask models for interactive system design. IEEE Transactions on Software Engineer-ing, 28(9):1–17, 2002.

[20] F. Paterno, C. Mancini, and S. Meniconi. ConcurTaskTrees: A diagrammatic nota-tion for specifying task models. In INTERACT ’97: Proceedings of the IFIP TC13Interantional Conference on Human-Computer Interaction, pages 362–369. Chapman& Hall, Ltd., 1997.

[21] S.J. Payne. Task Action Grammar. In Bullinger H. J. and Shackel B., editors,Proceedings INTERACT’84, pages 139–144, North-Holland, 1984.

[22] H. Pitariu. Proiectarea fiselor de post, evaluarea posturilor de munca si a personalului.Cariere. Casa de editura IRECSON, 2003.

[23] D. Scapin and C. Pierret-Golbreich. Towards a method for task description: MAD.Work with Display Units, 89:371–380, 1989.

[24] G. van der Veer, M. Hoeve, and B. Lenting. Modeling complex work systems -method meets reality. In Cognition and the work system, 1996.

[25] G. van der Veer and M. van Welie. Task based groupware design: putting theory intopractice. In DIS ’00: Proceedings of the conference on Designing interactive systems,pages 326–337. ACM Press, 2000.

[26] R. van Loo, G. van der Veer, and M. van Welie. Groupware Task Analysis in prac-tice: a scientific approach meets security problems. In 7th European Conference onCognitive Science Approaches to Process Control, 1999.

[27] M. van Welie. Task-based User Interface Design. PhD thesis, Vrije UniversiteitAmsterdam, 2001.

[28] M. van Welie, G. van der Veer, and A. Koster. Integrated representations for taskmodeling. In Tenth European Conference on Cognitive Ergonomics, pages 129–138,21-23 August 2000.

[29] M. van Welie and G.C. van der Veer. Structured methods and creativity: a happyDutch marriage. In Co-Designing 2000, 2000.

[30] A. Whitefield and B. Hill. Comparative analysis of task analysis products. Interactingwith computers. 1994.

47

Proiectarea interfet¸elor utilizator bazatˇa pe analiza ...adriana/Referat2.pdf · Analiza sarcinii poate sˇa utilizeze una sau mai multe din metodele disponibile de colectare

Documents