Kursusgang 2. - Dekomponering af opgaver: Hierarchical Task Analysis (HTA) - Entity-relationship-baseret analyse - Dataindsamling

Transkript

1 Kursusgang 2 Oversigt: Sidste kursusgang Opgaveanalyse - Dekomponering af opgaver: Hierarchical Task Analysis (HTA) - Entity-relationship-baseret analyse - Dataindsamling Fra objektorienteret analyse til HCI-design - Ni metoder - WISDOM og OOA&D - Eksempel (case 2) DIEB 2.1

2 Sidste kursusgang Metoder til HCI-design - Vandfaldsmodellen - Prototyping - Grundlag for valg af metode - Kombineret metode - Fokus: hvordan skal vi udvikle? Modellering af brugere i design - Bedre forståelse af brugernes arbejde og deres krav til systemet - Teknikker til modellering af brugere og deres krav/behov på forskellige niveauer - Problemet med at beskrive krav/behov - Overførsel af information: eksplicit og tavs viden - Fokus: hvem er brugerne? Requirements specification Architectural design Complexity Detailed design Coding and unit testing High Low Integration and testing Operation and maintenance System Life Cycle Prototyping Low Uncertainty Mixed Methodology Prototyping High DIEB 2.2

3 Kursusgang 2 Oversigt: Sidste kursusgang Opgaveanalyse - Dekomponering af opgaver: Hierarchical Task Analysis (HTA) - Entity-relationship-baseret analyse - Dataindsamling Fra objektorienteret analyse til HCI-design - Ni metoder - WISDOM og OOA&D - Eksempel (case 2) DIEB 2.3

4 Opgaveanalyse Nu har vi fået identificeret (modelleret) brugerne (hvem) Nyt fokus: hvordan arbejder brugerne Beskrives gennem analyse af brugerens arbejdsopgaver og de måder han/hun løser dem på Hvorfor skal vi lave denne analyse? To typiske problemer i brugergrænsefladen: - Forkert forståelse af hvad brugerne arbejder med (objekter) - Forkert forståelse af hvordan brugerne arbejder (arbejdsgang) Ide med opgaveanalyse: beskrive brugerens arbejde for at skabe et bedre grundlag for design af brugergrænsefladen DIEB 2.4

5 Dekomponering af opgaver: Hierarkisk opgaveanalyse Fokus på handling gennem begrebet opgave (task) En opgave deles op i mindre (del)opgaver i en hierarkisk struktur Kaldes Hierarchical Task Analysis (HTA) Delopgaverne på et niveau udføres i sekvens En plan beskriver strukturen i udførelsen på et givet niveau Planen kan benytte forskellige kontrolstrukturer A B C D E F G DIEB 2.5

6 Eksempel: Telavning (figur 15.4 i bogen) Kontrolstrukturer: sekvens: plan 3 selektion (optional): plan 0 "if " venter: plan 0 og plan 1 repetition (cycles): plan 5 parallelitet: task 1 og task 2 valgfrihed (discretionary): rum kan støvsuges i valgfri rækkefølge kombinering af flere kontrolstrukturer DIEB 2.6

7 Eksempel: Kontanthævning Plan 0: Udfør 1-2 Hvis koden godkendes udfør 3 Plan 3: Gentag indtil transaktion godkendes Hvilke af handlingerne kan vi iagttage for en konkret bruger? Blade kontra indre knuder i træet 1. Indsæt kort i automaten 0. Hæv kontanter 2. Indtast kode 3.1 Vælg beløbsstørrelse 3. Udfør hævning 3.2 Godkend transaktion DIEB 2.7

8 Øvelse: Indlæggelse af patient (case 1) Lav HTA for placering af en patient Videoklip: Testperson L (2003-4) 1:09:56-1:15:44 DIEB 2.8

9 Brugsmønstre Er et brugsmønster det samme som en hierarkisk opgaveanalyse? Et brugsmønster beskriver noget fremtidigt Et brugsmønster beskriver, hvordan edb-systemet anvendes til at løse en opgave Der er fokus både på brugerens handlinger og på interaktionen med systemet Udtrykkes som tekst eller tilstandsdiagram Kontanthævning Mønster: Kontanthævning igangsættes af kontohaveren, når vedkommende ønsker at anvende sit kreditkort til at hæve kontanter fra en kontantautomat. Kontohaveren indsætter sit kreditkort i automaten. Kontohaveren anmodes via skærmen om at indtaste sin kode. Enten viser skærmen et høfligt afslag, kreditkortet skubbes ud af automaten, og forløbet er afsluttet. Eller også viser skærmen en menu, som anmoder kontohaveren om at vælge beløbsstørrelse gennem indtastning på kontantautomatens tastatur. Et nyt skærmbillede anmoder kontohaveren om at godkende transaktionen. Hvis den ikke godkendes, anmodes kontohaveren igen om at indtaste en beløbsstørrelse. Ellers afsluttes mønsteret med kreditkortet skubbes ud, og det ønskede beløb udbetales. Objekter: (tilføjes senere) Funktioner: (Tilføjes senere) indsæt kort godkend ikke beløb indtast kode kode godkendt Kort indsat Identi¼ceret Kontrolleret vælg beløb fortryd afslag Beløb valgt udbetaling Beløb godkendt godkend beløb DIEB 2.9

10 Entity-relationship-baseret analyse Bruges normalt til design af databaser En database indeholder en samling af entiteter og relationer mellem dem Dix anvender denne beskrivelsesform til at beskrive objekter og de handlinger, som objekterne udfører Svarer (nogenlunde) til objekter og hændelser i OOA&D Kunde navn adresse saldo Åben konto åbnet (dato) konto lukket (dato) konto åbnet (dato) Lukket Lærling A X B Kunde 1 Ansat Assistent Arbejde Reser vation Salon dagsplan 1.. Da gsplan Tidsperiode Ledig 1 12 Ansat 2- ug eplan 1 Andet beløb indsat beløb hævet DIEB 2.10

11 Opsummering To tilgange: - Dekomponering af opgaver hierarkisk opgaveanalyse - Entity-relationship-baseret analyse Begge beskriver det nuværende arbejde uden at tænke på et edb-system Indsamling af data i forbindelse med opgaveanalyse: Dokumentation og beskrivelser af arbejdet Observation af arbejdet Interview med dem, der udfører arbejdet Bearbejdning og strukturering af de indsamlede data (kernen i en analysemetode) DIEB 2.11

12 Relation til OOA&D OOA&D introducerer to sideordnede analyseaktiviteter: - Analyse af problemområdet - Analyse af anvendelsesområdet Dix foreslår, at vi altid starter med analyse af anvendelsesområdet Hvordan svarer det til OOA&D's anbefalinger? Med OOA&D vælger vi strategi efter kompleksitet og usikkerhed i henholdsvis problemområde (objekter og hændelser) og anvendelsesområde (brug og funktioner) Dix antager altså, at anvendelsesområdet altid er det mest komplekse/usikre Det er ikke altid tilfældet Eksempel: hvad er de centrale objekter i patientadministration på et sygehus? Patient, undersøgelse, notater (behandling og pleje) Diskussion: skal man tage udgangspunkt i det eksisterende det gør man ikke med brugsmønstre (OOA&D)? DIEB 2.12

13 Anvendelser af opgaveanalyse Tidlig anvendelse af hierarkisk dekomponering af opgaver: manualer og materiale til optræning Overordnet design af et system - Hvilke objekter og handlinger skal håndteres af systemet - Hvad skal være anderledes - Begreber afspejles i systemets model Detaljeret design af grænsefladen - Vinduers rækkefølge: dekomponering af opgaver - Menuer: struktur og indhold fra vidensbaseret analyse - Objektorientering: beskriver hvordan handlinger knytter sig til objekter, og det kan kopieres for systemets objekter DIEB 2.13

14 Kursusgang 2 Oversigt: Sidste kursusgang Opgaveanalyse - Dekomponering af opgaver: Hierarchical Task Analysis (HTA) - Entity-relationship-baseret analyse - Dataindsamling Fra objektorienteret analyse til HCI-design - Ni metoder - WISDOM og OOA&D - Eksempel (case 2) DIEB 2.14

15 Fra objektorienteret analyse til HCI-design Analyseresultater: Objekter og hændelser (problemområde) - Klassediagram og tilstandsdiagrammer eller - Entity-relationship-baseret analyse Brug og funktioner (anvendelsesområde) - Aktørtabel, brugsmønstre og funktionsliste eller - Hierarkisk opgaveanalyse + detaljering og design Udgør tilsammen en objektorienteret beskrivelse Hvordan kommer vi herfra til et HCI-design? DIEB 2.15

16 Ni metoder van Harmelen (2001): Samling med ni metoder Alle spænder fra OO til HCI-design De fleste har meget fokus på anvendelsen af systemet Kun fire går detaljeret ned i brugergrænsefladen Kun to af dem har konkrete eksempler på design af brugergrænsefladen WISDOM har begge dele DIEB 2.16

17 WISDOM og OOA&D Vi kombinerer OOA&D med WISDOM Vi anvender tre workflows fra WISDOM: - krav - analyse - design WISDOM supplerer OOA&D, hvor den er svag (HCI-design) Resultater fra OOA&D er direkte anvendelige DIEB 2.17

18 Eksempel: Communicator (case 2) Vendsysselværket Brændselsafdelingen Kommunikation: VHF, DECTtelefon, samtaleanlæg DIEB 2.18

19 1. Interiorize project Functionality: Functionality: communication communication device. device. machine state indication, support for Brugere og udviklere laver sammen en højniveaubeskrivelse af problemet: hvad skal systemet gøre, og hvad er systemets nytteværdi og potentielle risici Svarer til systemdefinitionen (BATOFF/FACTOR) og analysen af projektets situation (kontingensfaktorer) machine state indication, support for communication communication Application Application Domain: Domain: transport transport of of coal coal around around the the power power plant, plant, preparation preparation and and mixing mixing of of coal, coal, monitoring monitoring conveyer conveyer belts, belts, problem problem solving/prevention solving/prevention in in production production line line Conditions: Conditions: safety safety critical, critical, noisy noisy environment, environment, dusty dusty conditions, conditions, aboveaboveand and underground, underground, employees employees have have basic basic IT IT training/knowledge training/knowledge Technology: Technology: pocket pocket PC, PC, Microsoft Microsoft visual visual studio studio Net,.Net, WLAN WLAN Objects: Objects: employees, employees, mobile mobile unit, unit, conveyer conveyer belts, belts, magnet, magnet, screener, screener, grinder, grinder, control control room room computers computers Responsibility: Responsibility: context-aware context-aware mobile mobile communication communication support support system system (CAMCoSS), (CAMCoSS), monitoring monitoring production production line line state, state, facilitate facilitate cooperation cooperation and and communication, communication, communication communication in in noisy noisy environments environments DIEB 2.19

20 2. Understand System Context Formål: at forstå systemets omgivelser (kontekst) ting og/eller brugere og deres arbejdsprocesser Resultat: en domænemodel Domænemodellen beskriver de mest centrale objekter i systemets omgivelser ting eller hændelser, som forekommer i omgivelserne Repræsenteres i et klassediagram Svarer til klassediagrammet (første version) DIEB 2.20

21 3. User Profiling Formål: at beskrive de brugere, hvis opgaver systemet skal understøtte Hvem er brugerne, hvordan er de grupperede og hvad er deres mest fremtrædende karakteristika Resultat: en enkel tekstlig beskrivelse eller en kompleks model af brugerne og deres roller Svarer til stakeholder analysis og aktørerne i OOA&D Controller Field worker DIEB 2.21

22 4. Essential Task Modelling Essential use case med fokus på samspil mellem brugere samt systemets ansvar Formål: at beskrive krav 9 essential use cases Et essential task flow diagram for hvert essential use case DIEB 2.22

23 5. Non-Functional Prototype Formål: at evaluere (validere) resultatet af krav-workflowet 4 skærmbilleder Fokus på navigeringsmæssigt og strukturelt design: - elementer i brugergrænsefladen - muligheder for navigering - tilgang til relevant information Udføres på en tavle Overføres til en papirprototype (mock-up), hvor udviklerne simulerer systemets funktion Evalueres igennem usabilitytest Testen danner grundlag for revidering af krav og task flow diagrammer DIEB 2.23

24 Opsummering Gennemført systemvalg i OOA&D Foreløbig analyse af problem- og anvendelsesområde Modellering af opgaver En afprøvet første papirprototype DIEB 2.24