DIEB2.1 Kursusgang 2 Oversigt: Sidste kursusgang Opgaveanalyse ­ Dekomponering af opgaver: Hierarchical Task Analysis (HTA) ­ Entity-relationship-baseret.

Præsentationer af emnet: "DIEB2.1 Kursusgang 2 Oversigt: Sidste kursusgang Opgaveanalyse ­ Dekomponering af opgaver: Hierarchical Task Analysis (HTA) ­ Entity-relationship-baseret."— Præsentationens transcript:

1 DIEB2.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)

2 DIEB2.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 Operation and maintenance Architectural design Detailed design Coding and unit testing Integration and testing

3 DIEB2.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)

4 DIEB2.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

5 DIEB2.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 BCD EFG

6 DIEB2.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

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

8 DIEB2.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

9 DIEB2.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)

10 DIEB2.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 A X B Kunde AnsatDagsplan Tidsperiode AndetLedigArbejde LærlingAssistent 1 1..  0..  1 1 1..  1 0..  Reservation 1 1 Salon dagsplan 1 1..  Ansat 2- ugeplan 1 12

11 DIEB2.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)

12 DIEB2.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)?

13 DIEB2.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

14 DIEB2.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)

15 DIEB2.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?

16 DIEB2.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ænse- fladen Kun to af dem har konkrete eksempler på design af bruger- grænsefladen WISDOM har begge dele

17 DIEB2.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

18 DIEB2.18 Eksempel: Communicator (case 2) Vendsysselværket Brændselsafdelingen Kommunikation: VHF, DECT- telefon, samtaleanlæg

19 DIEB2.19 1. Interiorize project Brugere og udviklere laver sammen en højniveau- beskrivelse 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) Functionality: communication device. machine state indication, support for communication Application Domain: transport of coal around the power plant, preparation and mixing of coal, monitoring conveyer belts, problem solving/prevention in production line Conditions: safety critical, noisy environment, dusty conditions, above- and underground, employees have basic IT training/knowledge Technology: pocket PC, Microsoft visual studio 2003.Net, WLAN Objects: employees, mobile unit, conveyer belts, magnet, screener, grinder, control room computers Responsibility: context-aware mobile communication support system (CAMCoSS), monitoring production line state, facilitate cooperation and communication, communication in noisy environments Functionality: communication device. machine state indication, support for communication Application Domain: transport of coal around the power plant, preparation and mixing of coal, monitoring conveyer belts, problem solving/prevention in production line Conditions: safety critical, noisy environment, dusty conditions, above- and underground, employees have basic IT training/knowledge Technology: pocket PC, Microsoft visual studio 2003.Net, WLAN Objects: employees, mobile unit, conveyer belts, magnet, screener, grinder, control room computers Responsibility: context-aware mobile communication support system (CAMCoSS), monitoring production line state, facilitate cooperation and communication, communication in noisy environments

20 DIEB2.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)

21 DIEB2.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

22 DIEB2.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

23 DIEB2.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

24 DIEB2.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