Fun Center

3SPKFLU"VEMFWFSFU""Es""""ds"" TFQUFNCFS" emmj3SPKFLU"BGMFWFSFU" Es""eds""EFDFNCFS"" emmj

,OTUJUVU"GPS"'BUBMPHJ"£"6FMNB"/BHFSM÷GT"9FK"fmm"£"leem"$BMCPSH"@TU"£"UMGs"lifhkkhf"£"GBYs"lkfhljlk

Institut for datalogiAalborg Universitet

DAT1/INF1

TITEL:FunCenter Reservationssystem- udvikling af programmel.

PROJEKTPERIODE:DAT1/INF1,1. september - 21. december, 2007

PROJEKT GRUPPE:d101a

GRUPPEMEDLEMMER:Jonas Urth Olsen

Michael Bønnerup

Nikolaj Johannesson

Rahuvaran Pathmanathan

Søren Hugger Møller

Thulasika Rasenthiran

VEJLEDER:Gitte Tjørnehøj

ANTAL KOPIER: 8

RAPPORT SIDEANTAL: 125

APPENDIKS SIDEANTAL: 10

TOTAL SIDEANTAL: 135

SYNOPSIS:

Denne projektrapport dokumenterer analyse-,

design-, udviklings- og evalueringsfasen i ud-

viklingen af et touchscreen-baseret reserva-

tionssystem til et funcenter, hvor der er lagt

vægt på en brugervenlig og intuitiv gra�sk

brugergrænse�ade.

Formålet med systemet er at det understøt-

ter og letter et funcenters administrative op-

gaver, idet der til et funcenter hører sig en del

administrationsarbejde, hvor der skal holdes

styr på kunder, tider, aftaler, ressourcer, re-

serveringer, rabatordninger mm. De anvendte

metoder er præsenteret i Objektorienteret

Analyse & Design (OOA&D)[23]

Til analysen er der taget udgangspunkt i

en systemde�nition og BATOFF-kriterier.

Herefter er problem- og anvendelsesområdet

blevet analyseret og beskrevet i analysedoku-

mentet. Dette danner grundlag for designde-

len, som ligger grund for implementeringen.

Programmeringssproget er C# med et objek-

torienteret perspektiv og udvalgte dele af sys-

temet er udviklet i Mircosoft Visual Studio

2005. Efter implementeringen er der foretaget

en brugbarhedstest af det udviklede system og

derudover er der udført en programtest på de

vigtigste funktioner i systemet.

Forord

Denne projektrapport samt det tilhørende software er udfærdiget af DAT1/INF1-gruppe, d101a på Aalborg Universitet fra d. 1. september til d. 21. december2007. Semestertemaet er "Udvikling af programmel"og projektet tager udgangspunkti forslaget "Fun-center-booking", som er fremlagt af vejleder og underviser GitteTjørnehøj.

Som baggrund for semestrets tema er der inddraget viden fra undervisning ifølgende kurser: Algoritmik og Datastrukturer, Design og implementering afBrugergrænse�ader, Systemanalyse og Design samt Objektorienteret Program-mering. Rapporten består af en studierapport, et analysedokument, et design-dokument, et implementeringsdokument og et test- og evalueringsdokument.

Vi vil gerne takke Seaport Funcenter, som vi i forbindelse med projektet, harhaft kontakt til. De har bistået med information om hvordan deres nuværendereservationsprocedure foregår, og ladet os få et kig på hvordan systemets bruger-grænse�ade er opbygget. Endvidere vil vi takke vores vejleder og OOA&D un-derviser Gitte Tjørnehøj for gode råd og vejledning igennem dette semester påDAT1/INF1, efteråret 2007.

Aalborg Universitet, 21 december 2007

IV

Indhold

1 Læsevejledning 1

I Studierapport 3

2 Indledning 4

3 Problemformulering 53.1 Problemafgrænsning . . . . . . . . . . . . . . . . . . . . . . . . . 5

4 Proces 64.1 Procesbeskrivelse . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

5 Fokusområde 105.1 Kriterier for brugergrænse�aden . . . . . . . . . . . . . . . . . . 105.2 Opsummering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6 Re�eksion 146.1 OOA&D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146.2 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146.3 OOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156.4 Forudsætninger ved projektstart . . . . . . . . . . . . . . . . . . 156.5 Erfaringer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

7 Perspektivering 16

8 Konklusion 188.1 Udviklingsmetode . . . . . . . . . . . . . . . . . . . . . . . . . . . 188.2 Touchscreen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198.3 Brugbarhedstest . . . . . . . . . . . . . . . . . . . . . . . . . . . 198.4 Afrundning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

II Analysedokument 20

9 Opgaven 219.1 Formål . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219.2 Systemde�nition . . . . . . . . . . . . . . . . . . . . . . . . . . . 219.3 BATOFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

VI

9.4 Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239.5 Omgivelser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239.6 Problemområde . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259.7 Anvendelsesområde . . . . . . . . . . . . . . . . . . . . . . . . . . 259.8 Forbillede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279.9 Metaforer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

10 Problemområdet 3110.1 Klynger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3110.2 Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3210.3 Klassebeskrivelser . . . . . . . . . . . . . . . . . . . . . . . . . . . 3410.4 Hændelser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

11 Anvendelsesområdet 4011.1 Brug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4011.2 Funktioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5611.3 Brugergrænse�aden . . . . . . . . . . . . . . . . . . . . . . . . . . 5811.4 Den tekniske platform . . . . . . . . . . . . . . . . . . . . . . . . 6011.5 Anbefalinger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6011.6 Strategi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6011.7 Udviklingsøkonomi . . . . . . . . . . . . . . . . . . . . . . . . . . 60

III Designdokument 61

12 Opgaven 6212.1 Kvalitetsmål . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

13 Teknisk platform 6513.1 Udstyr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6513.2 Basisprogrammel . . . . . . . . . . . . . . . . . . . . . . . . . . . 6513.3 Systemgrænse�ade . . . . . . . . . . . . . . . . . . . . . . . . . . 6513.4 Designsprog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

14 Arkitektur 6714.1 Designkriterier og arkitektoniske krav . . . . . . . . . . . . . . . 6714.2 Generiske designbeslutninger . . . . . . . . . . . . . . . . . . . . 6714.3 Komponentarkitektur . . . . . . . . . . . . . . . . . . . . . . . . 7014.4 Eksemplariske design . . . . . . . . . . . . . . . . . . . . . . . . . 71

15 Komponenter 7415.1 Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7415.2 Klasser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7615.3 Bruger�adekomponenten . . . . . . . . . . . . . . . . . . . . . . . 77

IV Implementeringsdokument 83

16 Implementering 8416.1 Windows Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8416.2 Custom controllers . . . . . . . . . . . . . . . . . . . . . . . . . . 85

VII

16.3 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8516.4 DayView klasserne . . . . . . . . . . . . . . . . . . . . . . . . . . 8616.5 Persitens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8616.6 Singleton-klasser . . . . . . . . . . . . . . . . . . . . . . . . . . . 8616.7 Kodeorganisering . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

V Test- og evalueringsdokument 88

17 Heuristisk inspektion 9117.1 Teorien bag brugbarhed . . . . . . . . . . . . . . . . . . . . . . . 9117.2 Metode - opstilling af heuristika . . . . . . . . . . . . . . . . . . . 9317.3 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9317.4 Deltagere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9517.5 Undersøgelsesdesign . . . . . . . . . . . . . . . . . . . . . . . . . 9617.6 Resultater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9717.7 Analyse og Vurdering . . . . . . . . . . . . . . . . . . . . . . . . 9717.8 Konklusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

18 Programtest 10418.1 Udarbejdelse testcases . . . . . . . . . . . . . . . . . . . . . . . . 10418.2 Testværktøjer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10418.3 Blackbox- og Whitebox-testing . . . . . . . . . . . . . . . . . . . 10418.4 Ansvar mellem klasserne . . . . . . . . . . . . . . . . . . . . . . . 10518.5 Anvendelse af Unit-test . . . . . . . . . . . . . . . . . . . . . . . 105

19 Brugbarhedstest 10619.1 Formål og hovedspørgsmål . . . . . . . . . . . . . . . . . . . . . . 10619.2 Metode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10619.3 Brugerpro�l og roller . . . . . . . . . . . . . . . . . . . . . . . . . 10719.4 Test afvikling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10819.5 Evaluering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10819.6 Lokalitet og udstyr . . . . . . . . . . . . . . . . . . . . . . . . . . 10919.7 Dataopsamling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10919.8 Resultater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11019.9 Konklusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

VIII

Kapitel 1

Læsevejledning

Vi har i vores opbygning af rapporten, så vidt muligt forsøgt at lade denneafspejle det forløb som projektet har gennemgået. Rapporten er delt op i 5dokumenter.

• Studierapport

• Analysedokument

• Designdokument

• Implementeringsdokument

• Test- og evalueringsdokument

Studierapport

Første del af rapporten beskriver projektets fokusområde og forløb, hvor deerfaringer og læringsmæssige begreber beskrives og evalueres.

Analysedokument

Analysedokumentet beskriver projektets analysefase, hvor der ses på problem-og anvendelsesområdet samt systemkriterierne.

Designdokument

Designdokumentet beskriver projektets designfase, hvor systemet blandt andetdesignes ved hjælp af usecases, sekvensdiagrammer mv.

Implementeringsdokument

Implementeringsdokumentet beskriver udviklingen af systemet samt forklaringpå dokumentation genereret i Doxygen.

Test- og evalueringsdokument

Dokumentet beskriver de forskellige tests vi har udført i projektet, samt resul-tater og evaluering af resultaterne.

1

Kapitel 1 Funcenter

Generelt

Rapporten er skrevet, så der forekommer både kildehenvisninger og fodnoter.Kildehenvisningen vil i teksten være noteret som [kildetal][sidetal], f.eks. en�gurhenvisning vil være [�gur 3.2]. Fodnoterne vil indeholde uddybende ellerforklarende information om emnet og vil være tilgængelig i bunden af denpågældende side og betegnes med numre. I forhold til projektets forløb arbejdesmed begreber som analyse, design, udvikling, test og evaluering, hvor der refer-eres til de faser projektet har forløbet efter.

En stor del af dette projekt beskæftiger sig med mange forskellige begreber, somikke ofte er eksplicit de�neret, og vi har derfor vurderet det som væsentligt atfastlægge hvad vi i det følgende forstår ved centrale begreber.

Usecase/brugsmønster beskrives i rapporten med samme betydning og de-�nerer et mønster for interaktion mellem et system og en aktør ianvendelsesområdet[23][s. 118].

Opret aftale de�nerer hændelsen, hvor en kunde kommer ind i et center ogbestiller en bane on demand.

Opret reservation de�nerer hændelsen, hvor en kunde ringer eller møder opi centret og bestiller en reservation som ligger efter, og ikke på bestillingstid-spunktet.

En aktivitet er de forskellige forlystelser/muligheder kunderne kan prøve i cen-teret. Eksempelvis bowling, pool, lasergame eller spisning.

En ressource er et element som bruges i en aktivitet. Eksempelvis bowlingbanesom bruges i aktiviteten bowling.

2

Del I

Studierapport

3

Kapitel 2

Indledning

Temarammen for vores projekt er "Design, realisering og optimering af et reser-vationssystem via touchscreen". Dette overordnede tema er yderligere konkre-tiseret til en problemstilling, der lyder "Analyse, design og realisering af etIT-system".

Kort kan den generelle opfattelse således konkretiseres i tre trin: analyse, de-sign samt realisering. I modsætning til basis-semestrene, er vi denne gang mereløsningsorienterede med henblik på at udvikle et konkret IT-system, hvor vitidligere fokuserede meget på analyser af eksisterende systemer. Et IT-systemer et relativt bredt begreb, som kan dække over mange ting. Det er typisk enkombination af hardware og software, som er designet og realiseret med henblikpå at løse en eller �ere givne opgaver. Det består således typisk af en rækkefunktioner og en brugergrænse�ade til at iværksætte dem.

Ideologien bag et reservationssystem er at e�ektivisere administrationen af res-sourcereservationer for �ere forskellige aktiviteter på samme tid - det vil sigebåde en økonomisk og tidsbesparende optimering af tilgængelige ressourcer.Økonomisk og tidsbesparende i den forstand, at det bliver hurtigere at fore-tage en reservation og dermed udnytte ressourcerne bedre. Systemet skal desu-den fremme overblikket over kunder, ressourcer og reservationer, således at enmedarbejder til alle tider, kan danne sig et overblik over centerets problemom-råde. Dette medfører at det letter reservationsprocessen, sådan medarbejderenikke behøver at afvise mulige kunder af den grund, at det ikke er til at se,hvorvidt en ressource er blevet reserveret eller ej.

En af fordelene ved IT-systemer er den interaktivitet som der tilbydes, og hvorman som bruger kan interagere med systemet selv og få feedback på eventuelleforespørgsler. I det miljø hvor vores målgruppe ligger er der �ere ting vi skaltage højde for, travlhed, støj og manglende overblik for at nævne nogen afdem. Derfor har vi lagt vægt på brugen af touchscreen, netop fordi vi ønskerat beskæftige os med en løsning, som kan være med til at afhjælpe nogle af deførnævnte problemstillinger, men også af interesse, for at se hvilke mulighedereller begrænsninger der ligger bag dette interface.

4

Kapitel 3

Problemformulering

Ud fra de indledende overvejelser søges følgende problemformulering besvaret

• Hvordan kan man designe et reservationssystem med vægt på brugen aftouchscreen, og hvordan implementerer man dette?

3.1 Problemafgrænsning

Udviklingen af et system er som regel en kompliceret proces, derfor er det vigtigtpå forhånd at have en fremgangsmåde for selve udviklingsprocessen. Under an-dre omstændigheder ville man før udviklingsarbejdet have set på hvilken ud-viklingsstrategi, man ville benytte i forbindelse med processen. Tilrettelæggelsenaf en udviklingsproces kaldes en udviklingsmodel. En udviklingsmodel kan ifølgeMarie Christensen og Louise H. Fischer de�neres på følgende måde:

"En udviklingsmetode indeholder en række retningslinjer og anbefalinger for ar-bejdet med udførelsen af et digitalt produkt[16][s. 31]".

Projektrammerne er fastelagt i dette semester og dermed også udviklingsmeto-den. Af denne grund vil det ikke blive undersøgt yderligere, om denne metode erden mest hensigtsmæssige og ligeledes om faseinddelingen har været optimale.

Dertil kan der til tider forekomme inkonsistens mellem de forskellige faser, grun-det den tidsmæssige kompleksitet af studieprojektet, det betyder at efter etoverstået review, er denne fase afsluttet og ikke taget op igen til trods for tilk-ommende ændringer i senere faser.

5

Kapitel 4

Proces

4.1 Procesbeskrivelse

Valget udviklingsmetode har i dette semester ikke været valgfrit, begrundelsenfor dette er, at semesterstrukturen har lagt op til en meget sekvensrettet ud-viklingsproces.

Vi har derfor benyttet vandfaldsmodellen fremgangs og udviklingsmetode. Deru-dover har vi sideløbende arbejdet med V-model. V-modellen er udbredt anvendti sammenhæng med softwareudvikling med fokus på testbarhed. V'ets venstreside indeholder speci�kationsarbejdet og inkluderer en detaljeret plan for testsder indeholdes i højre side.

V-modellen støtter sig umiddelbart op af vandfaldsmodellen og udviklet medhenblik på, at føre løbende test ved afslutningen af de forskellige fase i denne,det betyder at for hvert et trin man tager i vandfaldsmodellen, følger en eller�ere tests.

En illustration af V-modellen ses på [�gur 4.1], som viser relationerne imellemhver fase i udviklingsprocessen og hvordan de er associeret med en følgende test.På �guren ses en �rkant omkring den del af V-modellen, som illustrerer Vand-faldsmodellen.

Fordelen ved brug af V-modellen er at den skaber en velstruktureret metode,som i hver fase bliver implementeret med en detaljeret dokumentation for hvertidligere fase.

Metoden vi har valgt, har derudover været en tidsmæssig økonomisk metode,idet vi har haft små testforberedelser og udførelser af test i de forskellige faser,fremfor en langt større test i slutningen af udviklingen.

6

Funcenter Kapitel 4

Figur 4.1: Illustration af V-model

Vi vil herunder nærmere beskrive hvad der sker i hver af de faser som �ndes iV-modellen samt beskrive hvad vi har gjort i forhold til det projektforløb vi harværet igennem.

4.1.1 Kravsanalyse

I denne fase samles de forskellige krav til systemet ind, og bliver analyseret iforhold til de krav som brugeren af systemet har. Fasen er rettet mod hvadet ideelt system bør indeholde. Hvordan systemet skal designes eller opbyggeser ikke i fokus. I denne fase, interviewes brugerne af systemet, og et analyse-og kravspeci�kationsdokument udarbejdes ud fra de krav brugerne har til sys-temet. Dokumentet vil typisk beskrive systemets funktionalitet, fysik, bruger-interface, præsentation, data og sikkerhed. Dette er ofte et dokument som sys-temudviklerne bruger til kommunikation med køberne af systemet, for at sikreforståelsen af det system de ønsker at få. Dette gøres via en bruger-accepttest,som bliver udført i slutningen af denne fase. Efter denne kravspeci�kationstester accepteret af kunden, kan man gå til næste fase i V-modellen.

4.1.2 Kravsanalysetest

Denne test tjekker om systemet lever op til de krav som brugeren har stil-let. Den bruger den såkaldte Blackbox-testmetode, hvor den bruger reelle data,reelle mennesker og reelle dokumenter til at sikre en god brugbarhed og funk-tionalitet af systemet. Brugere som forstår forretningsbetingelserne i systemetudfører denne test, og der testes ud fra installations- og hjælpefunktioner i sys-temet. Derudover gennemgås kravspeci�kationsdokumentet for brugbarhed ognøjagtighed. Testerne opretter et dokument over hver deres test og beskriverfejl og inkonsistens i forhold til dokumentet, samt mulige løsninger af problemermv.

7

Kapitel 4 Funcenter

4.1.3 1.review

I vores projekt var kravsanalyse-testen en test, som foregik i forbindelse medvores 1.review, hvor reviewer og hovedvejleder deltog. Af reviewet �k vi kom-mentarer til rettelser i forhold til analysedokumentet, som netop indeholdt kravtil systemet. Det hele udmundede i et analysedokument, som kan læses i Del II.

4.1.4 Systemdesign

I denne fase skal systemudviklerne sætte sig ind i kundens situation og se på deforretningsmuligheder der er i systemet, og dette gøres ved at analysere på dekrav, som der blev oprettet i kravspeci�kationsanalysefasen. Dernæst påbegyn-der de at designe teknikker og ser løsninger i forhold til de krav brugeren haropstillet til systemet, og hvis nogle af de krav ikke er mulige at implementere,kontaktes kunden og der �ndes en løsning til problemet. Såfremt kravene æn-dres, bliver de ændret i kravspeci�kationsdokumentet fra forrige fase.Der oprettes et designdokument som beskriver systemets generelle tekniskeopbygning, organisation, komponentarkitektur, menu og datastrukturer. Deru-dover vil dette dokument indeholde eksempler på bruger-scenarier og eksemplerpå forskellige brugergrænse�ader for at opnå en større forståelse af det systemder ønskes udviklet. Andre tekniske dokumentationer, såsom sekvensdiagram-mer og præsentationsmodeller, bliver produceret i denne fase, og samles i etdesigndokument, som afsluttes med en test. Testen her er at forklare kundenomkring de tekniske speci�kationer, og kun med kundens accept, er systemud-viklerne i stand til at gå videre i processen.

4.1.5 Arkitekturdesign

Denne fase bliver ofte beskrevet som high-leveldesign, hvor systemudviklerneskal beskrive systemets opbygning i forhold til dets lag. De forskellige lag sombrugergrænse�aden, funktions- og modellaget bliver her beskrevet med deres k-lasser og arkitekturen fremstår derfor i en mere speci�k tilgang. I deres beskriv-else og illustrationer beskrives relationerne imellem lagene så kunden er i standtil at forstå systemet fra en mere teknisk vinkel end hidtil i processen. Outputtetaf denne fase er en rapport

4.1.6 System- og arkitekturdesigntest

Denne test vil sammenligne systemets speci�kationer med det aktuelle systemde-sign. Der bliver testet ud fra det a�everede systemdesigndokument og i forholdtil brugen af det i denne fase. Nogle gange bliver der brugt automatiske test-værktøjer som tester systemet igennem, ellers sidder kundens valgte testmandog tester designet.

4.1.7 2. review

I forhold til vores projekt, foregik denne test i forbindelse med vores 2.review,hvor reviewer og vejleder deltog. Her blev der diskuteret omkring strukturenaf vores system, samt de eventuelle problematikker og fejl, der var i forhold tilvores designklassediagram og sekvensdiagrammer. Ud fra det andet review ogdesignfasen blev der oprettet et designdokument som ses i Del III.

8

Funcenter Kapitel 4

4.1.8 Moduldesign

Denne fase bliver beskrevet som low-leveldesignfase. Her er systemet splitteti små moduler, hvor hver model er beskrevet så programmøren er i stand tilat programmere direkte. Her vil dokumentationen være i form af funktionelbeskrivelse af hvert modul samt evt. pseudokode, med brug af alle elementersamt deres type og størrelse. Alle input og output beskrives for hvert modul, ogunit-testen forberedes i slutningen af denne fase.

4.1.9 Integrationstest

I integrationstesten som bliver udført efter at moduldesignfasen er afsluttet,testes de separate moduler sammen med hinanden, for at sikre at de fungerersammen. Dette sker for at se om der er fejl i mellem interfaces og i interaktionenmellem de integrerede komponenter. For at dokumentere denne udviklingsprocesaf systemet, udarbejdedes et implementeringdokument, som ses i Del IV, sombeskriver opbygningen af vores system med en teknisk tilgang, samt der gøresbrug af dokumentation af koden dertil med Doxygen[24]. Denne form for tester igen en Black-boxtest, idet koden ikke er testet direkte for fejl, men om dearbejder sammen i en helhed. Denne test udføres igen af systemudviklere.

4.1.10 Heuristisk inspektion

Vi foretog en heuristisk inspektion af vores system for at udføre denne test. Vibrugte os selv som eksperter til systemet, og havde en checkliste som vi tjekkedesystemets funktionalitet og brugbarhed ud fra. Her blev ikke testet i koden, menblot på brugen samt navigationen af systemet. Beskrivelse, analyse og resultateraf vores heuristiske inspektion kan læses i kapitel 17.

4.1.11 Unittest

I denne fase testes de forskellige enheder (units), hvilket udføres af systemud-viklerne. Systemets units testes for om de gør det, som de skal i forhold til denfunktionalitet, som er blevet beskrevet i tidligere faser. Den går ind og veri�-cerer om koden er korrekt og opfylder kriterierne for klasserne. Testen udføresaf software-udviklere eller ved brug af unittest-programmer som for eksempelNunit[1]. Vi udførte en Unittest på enkelte komponenter og controllers i sys-temet, som kan læses i kapitel 18.

4.1.12 Brugbarhedstest

Efter vi havde færdigudarbejdet systemet, afholdte vi en endelig brugbarhed-stest. Vi havde to testpersoner inde og teste hele systemet. Beskrivelsen ogresultaterne fra denne test kan læses i kapitel 19.

9

Kapitel 5

Fokusområde

Gennem de forskellige faser af dette projekt, har vores fokusområde omhandletbrug af touchscreen og de designteorier der ligger bag brugergrænse�aden. Dethar specielt været vigtigt for os, at sætte os ind i hvorledes vi har kunnet opti-mere brugen med henblik på det miljø, hvor systemet skal implementeres. Derforhar mange af de beslutninger, der er blevet taget gennem de forskellige faser afprojektet, haft deres grundlag i de forskellige teorier vi har arbejdet med.

Specielt gennem designfasen er der blevet lagt vægt på teorien bag et funktioneltog brugervenlig design. Men også senere gennem implementering af dette, hardet hovedsagelig været i grænse�aden, hvor vi har lagt vores kræfter. Det ud-mønter sig selvfølgelig også i, at denne del fylder mest gennem de forskelligefaser i projektet.

Derfor har det fra starten været vigtig for os at få en nødvendig viden om, hvor-dan sådan et design kan udarbejdes, vi har været omkring forskellige teorierder omhandler brugergrænse�aden til touchscreen, men det har i overvejendegrad været i en eksperimentel dokumentering fra SAP[22], hvor vi har fundetinspiration. Følgende vil vi trække væsentlige punkter frem for at danne bundfor en bedre forståelse af de valg, vi har tru�et gennem de forskellige faser afdette projekt.

5.1 Kriterier for brugergrænse�aden

I dette kapitel tages der udgangspunkt i et dokument udarbejdet af SAP[22] ogsom bygger på deres egne erfaringer og ideer. Dokumentet har de selv valgt atkalde eksperimental.

De har opstillet og udarbejdet retningslinjer for skærmdialog og regler for op-bygning af design af brugergrænse�aden for touchscreen-applikationer samt beskrevethvilke elementer, det vil være bedst at anvende på applikationen.

10

Funcenter Kapitel 5

5.1.1 Skærm og baggrund.

En applikation bør afvikles i fuldskærm for at få et overordnet helhedsindtryk.Til baggrunden bør der anvendes en lys farve og ikke sort. En lys baggrundsfarveskjuler fedtede �ngeraftryk på skærmen og reducerer genskinnet fra skærmen.En dithering eller mønstret baggrund kan også anvendes. Dette hjælper øjetmed at fastholde fokuseringen på selve skærmbilledet i stedet for på muligere�eksioner, dette gælder også for områder på skærmbilledet hvor der ikke erikoner eller menuer

5.1.2 Skærmplads og -layout.

Programmer til touchscreen afvikles ofte i en opløsning på 640*480 eller 800*600pixels. Den lave opløsning skyldes at knapper, scrollbarer m.m. skal have entilpas stor størrelse der gør at de kan anvendes ved �ngertryk. Skærmpladsener derfor nødt til at blive håndteret på en anderledes måde end ved normalskærmdialog.

Faneblade Faneblade kan bruges til virtuelt at forstørre skærmbilledet ved atbrugeren kan skifte mellem forskellige områder ved hjælp af faner.

Skiftende områder. Skiftende områder kan ligeledes med faneblade bruges til atforstørre skærmbilledet. Her ændrer skærmbilledet sig ikke voldsomt, men deter områder som data display, function key area, keypad area m.m der ændres.For at forblive i et område eller skifte mellem to områder, kan pushbuttonsanvendes. Pushbuttons er knapper, der er aktive indtil der igen trykkes på demfor at skifte til et andet område.

5.1.3 Ændringer mellem skærmbilleder.

For at give adgang til forskellige funktioner, har brugeren som oftest brug for atnavigere mellem �ere type skærmbilleder. Derfor bør skærmbillederne have etkonsistens layout og udseende, således brugere vil opfatte dem som en helhed.Det er også af betydning at gøre navigationsvalgene klare, således brugeren vedhvordan man fortsætter eller går tilbage. Endvidere bør antallet af skift mellemskærmbilleder holdes til et minimum, og multiple vinduer skal undgås.

5.1.4 Placering af skærmelementer.

For at undgå at skærmbilledet bliver for detaljeret og uoverskueligt at se på, skalman holde sig til en simpel og overskuelig struktur. Med det sagt, er det vigtigtat have gestaltlovene[20] i baghovedet, når elementer som knapper skal placeres.Hvorvidt elementer opfattes som sammenhørende eller ej bør kunne ses ud fraden måde de er grupperet på. Man kan anbringe elementer nær hinanden forat skabe sammenhænge mellem dem (nærhedsloven), benytte sig af rammer tilat adskille dem fra andre elementer (lukkethedsloven) eller anvende elementermed ens geometriske former til at fremhæve sammenhøringen (lighedsloven).Elementer kan også sammenfattes ved hjælp af andre attributter såsom tekst,fonte, forgrunds- og baggrundsfarve. Dog må det ikke udelukkende ske ud frafarveforskelle.

11

Kapitel 5 Funcenter

5.1.5 Knapper

Idet touchscreen-applikationer hovedsagelig benytter sig af point-and-click for-men, spiller knapper en vigtig rolle i designet. Størrelsen på en knap bør somminimum være 2*2 cm og afstanden mellem to knapper må mindst være 3 mm.For at vise at en knap er aktiveret er det en god ide at anvende ikoner på knap-per. Når en knap bliver trykket, kan man ændre knappens ikon hvorudfra deter til at se at der er blevet trykket. En anden måde at sørge for at vise at dertrykkes på knappen, er at oplyse knappen i den tid der trykkes. Eller også kanman ændre størrelsen på knappen i få sekunder eller få knappen til at blinkenår den er blevet aktiveret eller har ændret tilstand.

5.1.6 Menuer

Menuer er ofte placeret i grupper af knapper. Disse kan ligne knapper ellerkan simpelthen bare være gra�ske elementer, ofte suppleret med tekstlabels. Engruppe af knapper skal være adskilt tydeligt og med plads rundt omkring, så manikke fejlagtigt aktiverer knappen ved siden af den tiltænkte ved en fejltagelse. Forat fremstå en menu eller en gruppe af knapper som en enhed, kan der anvendesde samme retningslinjer som nævnt under Placering af skærmelementer.

5.1.7 Selektion

Der er forskellige muligheder for at foretage valg af menupunkter eller elementerpå skærmen. Groft delt op kan man vælge mellem multiple selektion og singleselektion. Hvis man ønsker at foretage en multiple selektion, kan man anvendecheckbokse, hvorved �ere punkter kan markeres. Til enkelt selektioner er der�ere muligheder at vælge imellem. Der kan anvendes knapper, popup-menuer,radioknapper og tekstliste. Udover de nævnte muligheder kan man gøre brug afsliders og scrollbarer[22].

5.1.8 Farver

Der skal tages hensyn til �ere forhold, når farver på grænse�aden skal sammen-sættes. Det er en god ide at bruge stærke kontraster som rød, gul og grøn til atpåkalde opmærksomhed og som støtte for formidlingen, men samtidig skal manvære varsom med ikke at overdrive brugen af farver. Man bør vælge en farve-holdning og bruge den konsekvent gennem hele systemet. Ved at bruge farvernekan der skabes en sti eller en rytme, som kan lede brugeren til et vigtigt stedpå skærmen[4].

Det er endvidere almindelig kendt at farver og farveindtryk kan påvirke men-neskets sanser, selvom mennesket har forskellige opfattelser af farver og deresbetydning. Dog �ndes der kulturelt bestemte farvekoder, dvs. farver, der kul-turelt er blevet tildelt nogle værdier. De nok mest kendte i Danmark er rød,gul/orange og grøn. Disse farver kendes bl.a. fra tra�klyset[3]. Rolf Molich hargivet nogle korte retningslinjer for brug af de tre farver. Den røde farve signalererfare og fejl, og bør reserveres til fejlmeddelelser. Den grønne farve symbolisererdet sikre eller oplagte valg, mens den gule farve giver udtryk for forsigtighed ogat man skal passe på.

12

Funcenter Kapitel 5

Anvendelsen af farvekoder kan være nyttige i stressede situationer eller underrutineprægede opgaver, hvor mange vil vælge knap efter farve og ikke efter hvadder står på knappen, dette er netop fordi farvede elementer tiltrækker øjet mereend sort/hvide[11][s. 70+75].

Undersøgelser har vist at den blå farve virker afslappende og dæmper �ere au-tomatiske kropsfunktioner såsom blodtryk og puls[12]. I modsætning til farversom rød og gul, kan farven blå sagtens optræde i store mængder da den erafdæmpet, fordi dens lysstyrke er lav. Komplementærfarven til blå er orange,og er derfor i modsætning til blå varm og glødende[7].

5.2 Opsummering

Denne teori har lagt grundlaget for designet af brugergrænse�aden, med henblikpå brugen af touchscreen, som det fremgår af teorien har disse design idealeren del tilfælles med, at design mod et almindeligt bruger interface med tastaturog mus, dog bør man være bevist om de hindringer, eller i vores tilfælde udfor-dringer, som touchscreen har tilbudt.

Specielt i designfasen har vi gjort brug af denne teori, men også andet fremsatteori har været med til at præge vores beslutninger for at give os et bedre fun-dament til at designe brugergrænse�aden på en touchscreen, i et travlt og tiltider støjende miljø som et funcenter.

På baggrund af dette har vi også udarbejdet en prototype, som vi efterfølgendehar testet, først og fremmest for at undersøge designet af vores brugergrænse-�ade, men også for at kunne observere deltagernes interaktion via interfacet,for at få en fornemmelse af hvilke områder, som det har været nødvendigt atarbejde videre med i det senere forløb.

13

Kapitel 6

Re�eksion

I det følgende afsnit vil vi redegøre for metoderne og processen benyttet i ud-viklingen af reservationssystemet. Som semestret lægger op til er udviklingensket ud fra 3 hoveddisipliner: OOA&D (objektorienteret analyse og design),UML (uni�ed modelling language) og OOP (objekt orienteret programmering).OOA&D er den overordnede metode der er brugt til at analysere problemom-rådet, og UML er den diagrammeringsteknik brugt til at modellere analyse ogdesign. Endelig er systemet implementeret ved OOP, nærmere bestemt C# 2.0.I de følgende underafsnit vil vi uddybe disse 3 punkter, gennemgå gruppensforudsætninger ved projektstart samt lessons learned.

6.1 OOA&D

Vi har benyttet OOA&D til at analysere problemområdet og anvendelsesom-rådet samt kravene og kriterierne for projektet. Dette er blandt andet gjort vedat opstille personas og brugsmønstre og ved at kigge på metaforer og forbilled-er for systemet. Der udarbejdedes ligeledes aktør- og funktionstabeller for atdanne et overblik over systemet. Vi har løbende arbejdet på analyse- og design-klassediagrammer som begge ændrede sig meget efterhånden som processen løbfremad.

6.2 UML

UML er det sprog vi har brugt til langt de �este modeller vi har lavet i OOA&Dfasen. Sproget indeholder notationer og diagrammer til langt det meste vi harhaft brug for, dog er prototypen som er lavet i løbet af analysen og designetikke UML.Vi har benyttet Dia1 til at tegne de �este diagrammer og modeller da det kanbenyttes på de 3 platforme vi har arbejdet på, og det indeholder en næstenkomplet samling af UML notationer og �gurer, med mulighed for at tilføje �ere.Dog er enkelte diagrammer lavet i Powerpoint.

1Se: http://www.gnome.org/projects/dia/

14

http://www.gnome.org/projects/dia/

Funcenter Kapitel 6

6.3 OOP

Vi har benyttet objektorienteret programmering til udviklingen af systemet, C#2.0. Af udviklingsværktøjer er benyttet Microsoft Visual Studio og MicrosoftVisual Studio C# Express.

6.4 Forudsætninger ved projektstart

Ved projektstart var der ingen af os der havde kendskab til de metoder vi harbenyttet i processen. I de sideløbende fag SAD (System Analyse og Design) ogDIEB (Design Implementation og Evaluering af Brugergrænse�ader) af har vilært om OOA&D og UML, og i OOP (Objekt Orienteret Programmering) harvi lært C#, så det er egentlig ikke fordi vi har skullet vælge metode, blot læreat bruge de nævnte.SAD kurset har sat os i stand til at analysere og designe et system fra bunden udfra behovet og mulighederne for udviklingen, ved hjælp af kontakt med kunden,potentielle brugere, samt gennem forskellige former for modellering af systemet.DIEB kurset har givet os teorier om hvordan en god brugergrænse�ade designes,samt eksempler på både gode og dårlige implementationer af dette. OOP kursethar sat os i stand til den faktiske implementation af systemet, altså udviklingenaf reservations systemet i C#.

6.5 Erfaringer

For at sikre at reservationssystemet er e�ektivt, blev en brugbarhedstest fore-taget, hvor vi benyttede os af en tænke-højt-metoden i et usability-laboratorie.Testen blev foretaget med to personer. Forløbet blev ikke optaget som følge afden valgte testmetode, men vi tog noter undervejs og noterede testpersonernesreaktioner. Vi antog at det stillede antal opgaver var rimelig inden for den afsat-te tid på en halv time per person. Det viste sig dog at opgaverne gennemsnitligthurtigt blev løst på halvdelen af den afsatte tid. Vi kunne have forebygget detteved på forhånd at have testet opgaverne på en 3.person og derved fået et skønover den tid, testen ville vare.

6.5.1 Brugbarhedsteori

Anvendelsen af en touchscreen bevirker, at vi ikke helt kan anvende de ret-ninglinjer for design, der normalt knyttes til applikationer, der kører på en almin-delig skærm. Dette skyldes at der er forskel på at interagere med en almindeligskærm og med en touchscreen. Vi har derfor måttet �nde teori, der gælder fordette. Vi har villet �nde touchscreenteori skrevet af kendte brugbarhedsekspert-er som Jakob Nielsen. Selvom der �ndes �ere brugbarhedsteorier, der ligger tilgrund for design af brugergrænse�aden, har det ikke været ligetil at �nde teoriomkring hvorvidt brugergrænse�aden bør være på en touchscreen, men efter endel research faldt vi over et eksperimenterende dokument fra SAP. På mangelaf bedre læste vi deres dokument igennem og kom frem til at der faktisk stodmeget af det, vi havde brug for.

15

Kapitel 7

Perspektivering

Vores vision for programmet er en kombination af ideer, dannet på baggrund afteori, forbilleder og metaforer og desuden et syn på hvordan programmet skalfungere som helhed, hertil vil vi nævne nye ideer til funktioner, der kunne im-plementeres med tiden for at forbedre systemet.

Vores vision med programmet er et program med vægt på memorability, i dennesituation vil det sige et program, som betjenes via touchscreen på baggrund aflet forståelige og omsættelige signaler, i form af farver og ikoner. Men overord-net er det et værktøj som styrer informationer om centerets problemområde ogafhjælper a�æsningen og manipulationen af dem.

Under den tidlige planlægning og udvikling af systemet gjorde vi os tanker om,hvilke funktioner der var vitale og hvilke der kunne undværes af hensyn tilprojektets omfang. Som følge af det, er der en del funktioner, som vi gerne såimplementeret ved en eventuel videreudvikling af reservationssystemet, ligeledeshar vi senere fundet mangler som vi gerne så afhjulpet.

Som noget af det første, ville de brugbarhedsfejl, der blev opdaget under brug-barhedstesten og den heuristiske inspektion blive forsøgt udbedret i systemet ogdernæst ville endnu en tænke-højt burgbarhedstest komme på tale. Her kunnevi godt tænke os at anvende testpersoner, der til daglig har kontakt til et travltbar-miljø og bruger et reservationssystem på arbejdspladsen. Herved kan vi fået bedre indtryk af hvorvidt det er lykkedes os at designe systemet til at værenyttigt i det tiltænkte miljø, da brug af disse testpersoner højst sandsynligtbedre kan afsløre uhensigtsmæssigheder og fejl ved systemet.

Således vil vi også bringe vores udviklingsmetode op til revision, da vi under an-dre omstændigheder ville have valgt en anden metode. I dette forløb har vi væretmere eller mindre bundet til at bruge vandfaldsmetoden. I et udviklingsprojektsom dette havde en metode som prototyping været mere hensigtsmæssig, da viville havde haft muligheden for at lave �ere iterationer og derved både bevægeos frem og tilbage i de forskellige faser og derved have haft bedre mulighed forat få forbedret de uhensigtsmæssige eller manglende funktionaliteter.

Med hensyn til den fuldkomne funktionalitet af systemet, skal systemet videreud-

16

Funcenter Kapitel 7

vikles med en administrator login. Administratoren kan i modsætning til brugerenoprette og nedlægge ressourcer mm. Herefter skal der implementeres en form fornetværk mellem administratorens maskine og den i baren. Således er der ikkelængere tale om et stand-alone system, det vil medføre at et punkt som sikker-hed bliver mere væsentligt. Dette vil yderligere medføre en revidering af vorespersistenslag, da det ikke længere er hensigtsmæssigt at gemme oplysninger omkunder, ressourcer og reservationer i �ler. Det betyder at interfacet på systemetskal udvikles, så det kan håndtere kommunikation med en database.

Desuden vil en internetforbindelse give �ere muligheder. Med sider som dgs.dkbliver det lettere at oprette kunder. Brugeren kan nøjes med at få oplyst kun-dens telefonnummer og taste det ind i systemet. Herefter skal systemet selv gåpå internettet og hente de oplysninger ned, medmindre han allerede er opretteti systemet, brugeren slipper herved for at taste oplysningerne ind manuelt ogsparer derved yderligere tid. Senere kunne man også forestille sig en form forportal som snakkede sammen med interfacet i vores system, hvor kunderne selvkunne danne sig et overblik over centerets aktiviteter og reservere pladser pådem.

Slutteligt kan et betalingssystem komme på tale, så kunden enten kan betaleførst og anvende aktiviteterne og spise i funcenteret eller betale til slut, her villedet igen være nødvendigt at arbejde videre med interfacet på systemet, for atmuliggøre en kommunikation med et eventuelt kasse- og betalingssystem.

17

Kapitel 8

Konklusion

I vores problemformulering spurgte vi til, 'Hvordan kan man designe et reserva-

tionssystem med vægt på brugen af touchscreen, og hvordan implementerer man

dette? ' I de følgende punkter vil vi konkludere på vores initielle problem ud fra�ere hovedepunkter.

8.1 Udviklingsmetode

Først og fremmest har det været nødvendigt at lave en fyldestgørende analyseaf vores problemområde, desuden har vi gennemgået teori om designprincipperog -regler for en brugergrænse�ade på touchscreeen. Dertil har vi foretaget for-billedeanalyser og set på metaforer, alt sammen for at danne en grundlæggendeforståelse af opgaven. Vi erfarede dog hurtigt som projektet udfoldede sig gen-nem de efterfølgende faser, at projektet og dermed opgaven til stadighed blevmere og mere kompleks, derfor er der fra analyse- og op gennem designfasen,blevet sorteret �ere og �ere ting fra, som ikke længere var nødvendige for atnå vores resultat rent studiemæssigt. Det er også en af grundene til at klasse-diagrammet har ændret sig radikalt fra analyse- til designdokument, klasser erkommet til og andre er faldet fra. En anden grund til ændringerne er, at vigennem implementeringen erfarede at det første klassediagram ikke længere varhensigtsmæssigt og derfor var det nødvendigt med et redesign, grundprincippetbag dem er dog det samme.

Ligeledes er sekvensdiagrammerne revideret en del gange, grundet vi gik forgrundig til værks i designfasen, hvor vi forsøgte at klargøre �ere diagrammertil implementeringen. Vi erfarede dog hurtigt at den proces ikke var holdbar ogat det var langt bedre at veksle mellem at designe og afprøve designet i småbidder kode og dette til trods for, at vi manglede et mere indgående kendskabtil objektorienteret programmering og C#.

Overordnet er hele projektet skredet frem på baggrund af en udviklingsmetode,som ligger tæt op af vandfaldsmodellen, dog har vi vekslet en del frem og tilbagei design- og implementeringsfasen, så denne del lgger op af prototyping.

18

Funcenter Kapitel 8

8.2 Touchscreen

Det står klart for os at det er mere tidskrævende at udvikle et brugerinterfacetil et touchscreenbaseret system. Windows Form gør det meget nemt at designeen brugegrænse�ade hurtigt, da der stilles en masse kontroller til rådighed. Ud-fordringen for os har dog været at alle disse kontroller ikke er optimale til ettouchscreen interface. Dialogbokse, f.eks. den normale MessageBox, er for småog benytter ikke de knapper vi selv har udviklet. Så vi har måtte udvikle voresegne dialogbokse. I �ere tilfælde kunne vi benytte standard kontroller som virettede lidt på via deres metoder og attributter. Som regel var det størrelsender blev rettet.

Touch interfacet gav også begrænsninger i forhold til de muligheder, man harmed en normal WIMP-applikation. Men kan ikke benytte højreklik, og marker-ing af f.eks. tekst er ikke så enkelt som med en mus. Alt i alt har dette betydet, atvi har brugt mere tid til udviklingen for at nå det vi har nået, end hvis vi havdeen normal applikation. Dog er det sansynligt at vi kunne have skåret i denne ud-viklingstid hvis vi havde benyttet nogle eksisterende 3. parts kontroller udviklettil touchscreen. Vi valgte dog ikke at gøre det, da vi så det uddannelsesmæssigespændende i selv at udvikle dem.

8.3 Brugbarhedstest

I brugbarhedstestene forsøgte vi at lave et setup der kom tæt på den normalearbejdssituation i et sådan center. Men om vi kom tæt nok på kan diskuteres.Et af vores kriterier for programmet var, at det skulle minimere fejl i et travltbarmiljø. Til netop at afteste dette ville det have været oplagt at benytte en"on lokation"test, hvor man testet programmet der, hvor det skal benyttes. Ensådan test vil muligvis have fanget �ere fejl, men trods dette formåede vorestest at fange mange fejl.

8.4 Afrundning

Generelt har vi opnået en god forståelse af, hvordan man designer en bruger-grænse�ade på touchscreen mod en speci�k målgruppe i et udfordrende miljø.Desuden har vi erfaret, at implementeringsfasen kan og i vores tilfælde var megetkompliceret, her er det især vigtig at analyse- og designprocessen er i orden, dakon�ikter hurtig kan opstå. Hertil er det specielt vigtig at gruppen som helhedopnår en god forståelse af systemets design inden implementeringen, da dennelægger fundamentet for en fornuftig struktureret arbejdsproces.

19

Del II

Analysedokument

20

Kapitel 9

Opgaven

I dette analysedokument vil vi ved at se på problem- og anvendelsesområdet,dokumentere analysen af reservationssystemet samt opstille kriterier for sys-temet. Dernæst vil vi se på forskellige personas, som kan indtræde i det miljøreservationssystemet skal implementeres i.

9.1 Formål

Formålet med reservationssystemet er at e�ektivisere administrationen af banereser-vationer for �ere forskellige aktiviteter på samme tid - både økonomisk og tids-besparende optimering af ressourcerne. Økonomisk og tidsbesparende i den for-stand, at det bliver hurtigere at foretage en reservation og at aktiviteterne bliverudnyttet bedst muligt. Systemet skal gøre det muligt for en medarbejder til alletider at kunne få et overblik over reservationer og ressourcernes brug. Medarbe-jderen skal kunne få et overblik over de aftaler, der er til de enkelte ressourcer;hvilke ressourcer der er optaget og hvilke der kan reserveres til kunder. Ved dennuværende fremgangsmåde bliver en reservation registreret parallelt med entelefonsamtale. Systemet skal derved hjælpe med at lette reservationsprocessen,således medarbejderen ikke behøver at afvise mulige kunder af den grund, atdet ikke er til at se hvorvidt en ressource er blevet reserveret eller ej. Systemetskal desuden virke som et skemaplanlægningssystem, der kommer med forslagtil reservationsmuligheder. Reservationssystemet skal i det hele støtte og lettepresset på medarbejderen i arbejdsprocessen. Desuden forligger muligheden for,at systemet skal arbejde sammen med et betalingssystemet, men i dette tilfældeskal systemet ikke bruges til at administrere betalinger af arrangementer ellermedarbejdernes lønninger.

9.2 Systemde�nition

Et IT-system, udviklet til administration af reservationer til bowlingbaner, pool-borde, lasergame samt restaurantborde i et travlt barmiljø i et større funcenter.Formålet med systemet er på bedst mulig måde at få udnyttelse af centeretsressourcer i forhold til økonomisk optimering. Desuden skal det være nemt, hur-tigt og lettilgængeligt at betjene. Systemet skal ikke bruges til at administrere

21

Kapitel 9 Funcenter

betalinger eller lønninger. Systemet skal bruges af lønnede medarbejdere i cen-teret med kendskab til brug af IT-værktøjer, og de skal bruge systemet som etreservationssystem til de forskellige aktiviteter i centeret. Systemet skal brugespå en stand-alone PC-platform, fungerende med en touchscreen, som skal værelet tilgængeligt i et travlt barmiljø. Brugen af touchscreen skal på samme mådeminimere risiko for fejl.

9.3 BATOFF

For at sikre at vores systemde�nition indeholder alle aspekter af systemet og forat evaluere om systemde�nitionen er god, har vi taget udgangspunkt i BATOFF-kriteriet[23][s. 37].

9.3.1 Betingelser

Systemet skal være nemt, hurtigt og lettilgængeligt at betjene i et travlt barmiljø,og skal bruges af medarbejdere med et grundlæggende kendskab til brug af IT.Systemet skal lette reservationsarbejdet for medarbejderne og kunne give demet overblik over centerets ressourcer, og på en praktisk måde adskille de ledigeog de reserverede ressourcer fra hinanden på sådan en måde, at medarbejderennemt kan se forskellen.

9.3.2 Anvendelsesområde

Hovedsagligt skal systemet bruges af medarbejderne i funcenteret, som foretagerreservationer af diverse aktiviteter ved bardisken. Derudover vil systemet kunnehenvende sig til de øverste chefer i centeret, for at give overblik over centeretsaktiviteter og deres brug i åbningstiden.

9.3.3 Teknik

Teknikken, som skal bruges til systemet, skal være en stand-alone PC-platform,eventuelt med brug af touchscreen. Valget af sidstnævnte arkitektur skyldtes,at systemet skal minimere risiko for fejl i forhold til forkerte indtastninger mv.

9.3.4 Objekter

Kunder, bowlingbaner, poolborde, lasergame, og bordreservationer.

9.3.5 Funktioner

Systemets funktioner skal håndtere reservationer af centerets aktiviteter samtgive overblik over hvilke ressourcer som er i brug og hvilke som ikke er.

9.3.6 Filoso�

Administrativt reservationsværktøj med henblik på bedst mulig udnyttelse afcenterets ressourcer, både økonomisk som tidsmæssigt.

22

Funcenter Kapitel 9

9.4 Stakeholders

9.4.1 Primære stakeholders

Medarbejdere i funcenteret (ved baren/telefonen). Disse er de eneste brugere afsystemet der bruger det i deres arbejde næsten hele tiden hver dag. Systemetssucces vil i første omgang overvejende afhænge af om medarbejderne bliver gladefor at bruge systemet.

9.4.2 Sekundære stakeholders

Kunder og funcenterets ledelse/administration. Kunder er sekundære stakehold-ers, da de er interesserede i at systemet virker optimalt, så man kan være sikkerpå at få det man har reserveret, og at selve reservationen foregår hurtigt ognemt. Funcenterets ledelse er sekundære stakeholders af �ere grunde. For detførste har de mulighed for at benytte systemet til at se statistikker over fun-centerets aktiviteter. For det andet er de interesserede i et e�ektivt system, såcenterets ressourser udnyttes optimalt og så kunderne har en god oplevelse ogvender tilbage en anden gang.

9.4.3 Tertiære stakeholders

Konkurrerende systemer som fx "Flexibook"[5] vil være påvirket af, hvor godtsystemet klarer sig. Hvis det klarer sig godt kan de konkurrerende systemer mistemarkedsandele, og omvendt kan de eventuelt få en ny kunde hvis systemet bliveren �asko. Funcenterets aktionærer er også berørt af succesen af systemet, da deti sidste ende vil have ind�ydelse på hvor godt centeret klarer sig, og dermed påaktiekursen.

9.4.4 Faciliterende stakeholders

Admin af reservationssytemet er naturligvis påvirket af hvordan systemet erudviklet i forhold til vedligeholdelse og eventuel videreudvikling af systemet.

9.5 Omgivelser

For at skabe et overblik udviklede vi i fællesskab et overbliksbillede af systemetsomgivelser, som er gengivet på [�gur 9.1].

9.5.1 Arbejdsgang

Efter vi havde set på systemets omgivelser for at skabe os et overblik, begyn-dte vi at kortligge den arbejdsgang vi mente ville være i et funcenter. På [�gur9.2]. får vi et indblik i funcenteret. På �guren vises to former for reservation-er af baner, hvor den ene reservation sker pr. telefon, hvor en kunde ringerind til medarbejderen i centeret og reserverer en aktivitet. Den anden reserva-tion sker ved direkte henvendelse nede i funcenteret, igen med medarbejderenved baren/disken. Dette kaldes derimod en aftale fremfor en reservation, hviskunden ønsker at benytte en af aktiviteterne på bestillingstidspunktet. Her s-es medarbejderen så med �re forskellige planer/kalendere for aktiviteter, som

23

Kapitel 9 Funcenter

Figur 9.1: Problemområde og anvendelsesområde

Figur 9.2: Arbejdsgang

24

Funcenter Kapitel 9

han/hun skal reservere kundernes tider ind i. Vi ser her, at medarbejderen harbehov for overblik på fysisk plan med �re forskellige kalendere for reservationersamt at skulle tage imod betaling af kunder ved disken, hvilket til tider kan givetravlhed.

9.5.2 Forandring

Hvis vi forestiller os at det forhenværende reservationssystem har været via �reforskellige kalendersystemer, illustration på [�gur 9.3], så betyder det, at detfor medarbejderen er et stort kriterium ikke at komme til at blande kalendernesammen, og skabe sig et større overblik, i travle periode, specielt op til fx jul ogpåske. Med det nye system, vil der skabes større overblik, mulighed for øvrigemedarbejdere og ledere at hjælpe til med reservation af aktiviteterne samt fjernealt papirarbejdet.

Figur 9.3: Forandring

9.6 Problemområde

Administration af reservationer i et funcenter, hvor de mest relevante dele iproblemområdet er de forskellige ressourcer, det vil sige bowlingbanerne, pool-borderne, cafeborderne og lasegame. Derudover er kunder som besøger centeretogså relevant i forhold til problemområdet.

9.7 Anvendelsesområde

I anvendelsesområdet er den brugerorganisation som anvender IT-systemet,brugere som håndterer de forskellige reservationer. Den applikation vi vælgerat udvikle, skal kunne oprette, redigere og slette aktivitets-reservationer. Forat hjælpe medarbejderne med at holde styr på kunderne skal systemet også

25

Kapitel 9 Funcenter

kunne gemme kundeoplysninger. Systemet skal køre på en stand-alone Windows-baseret PC.

26

Funcenter Kapitel 9

9.8 Forbillede

Vi har valgt at kigge på et reservationssystem hos Seaport Bowling Center iAalborg. Systemet, som de bruger har mange af de funktioner, vi ønsker i voressystem. Systemet er ret avanceret og interfacer med andre system, som f.eks.deres system til at styre bowlingbanerne, og De Gule Sider (www.dgs.dk) forkontaktinformation. Udover at bruges til at holde styr på bord- (i restauran-ten) og banereservation, kan systemet også holde styr på regningen. Vi kiggedeprimært på reservationsdelen.

Systemet er client/server baseret, og kører på en Windows platform. Der er femklienter placeret forskellige steder i centeret, disse henter og gemmer data påen central server. Interface-enhederne til klienterne er standard mus/tastaturog en touchscreen. Programmet benytter typiske Windows interface mulighed-er som f.eks. højreklik for en kontekst menu. Det meste af programmet kanbenyttes med både mus/tastatur eller touchscreen. En medarbejder fortæller athan benytter touchscreen når det er simple opgaver der skal klares, som f.eks. atsende en reservation til betaling, og mus/tastatur til mere input tunge opgaver,som f.eks. at registrere en ny kunde. Han siger desuden, at de mange input mu-ligheder kan forvirre knap så rutinerede it-brugere. De kan have problemer medat �nde ud af, hvornår man skal bruge den ene eller anden input-enhed. Systemet

Figur 9.4: Seaport Bowling

er opbygget som en slags kalender, der viser en oversigt over alle bowlingbanernei den horisontale retning og tiden i den vertikale retning. Desuden er der indsatmarkeringer i oversigten, der matcher de fysiske rammer i centeret, der er alt-så en forbindelse mellem hvordan bowlingcenteret er indrettet og programmetsbrugerinterface. Dette gælder også reservationssystemet til restaurantbordene.Alle reservationer bliver vist som "kasser"der kan tilføjes eller redigeres ved atklikke på dem. De kan �yttes via 'drag and drop'. Reservationerne er farvekodeti forhold til blandt andet hvilket tilbud de er prissat efter, desuden er der krydsover dem der er betalt. Centeret har selv bestemt disse farvekoder. Systemet kandesuden håndtere multireservationer, altså reservationer der gentager sig. Sys-temet er generelt opbygget omkring reservationerne, man kan stort set kommetil alle funktionerne ved at klikke på dem via højre- eller venstreklik. Funktion-erne kan være at slette, oprette eller ændre en reservation, men også at se ogrette i regninger og kunder tilknyttet reservationen.

27

Kapitel 9 Funcenter

Når kunderne ankommer bliver det registeret i system, dette vises ved atregningen bliver åbnet. De kan betale med det samme (så får deres reservation etkryds), eller vente til de forlader centeret. Ved reservationen i "venteposition"harden en bestemt farve.

Reservationer foretages af medarbejdere i Seaport som kontaktes af kunder icenteret eller over telefonen. Systemet tilgås altså kun af medarbejdere i centeret.For at bruge systemet skal medarbejderne logge på, det er altså muligt at sehvilken medarbejder der har foretaget de forskellige reservationer.

Opsamling på forbillede

Systemet i Seaport og det system vi ønsker at udvikle, minder meget om hinan-den, da begge er reservationssystemer i samme genre og derfor kan vi også sepå hvilke egenskaber, vi kan overdrage til vores system.

• Platformen vil være bedst virkende på en Windows platform, hvor funk-tioner som 'højre-klik' og andre tab-funktioner gør det mere brugervenligtfor brugeren, i forhold til genkendelighed fra andre systemer.

• Touchscreen er brugbart i et travlt arbejdsmiljø, hvor det kan lette op-gaverne og e�ektivisere servicen i funcenteret. Dog er det bedst at havemus/tastatur til udførelse af mere komplicerede reservationer og indtast-ning af nye kunder mv.

• Menuer og knapper skal tilpasse de inputs på skærmen samt være over-skuelig, så brugeren ikke forvirres i forhold til udførelsen af opgaverne isystemet.

• Kalenderfunktionsopbygningen er med tll at give brugeren overblik overde forskellige aktiviteter/baner, og gøre det nemmere for brugeren at �ndetid i forhold til ny reservation af aktivitet.

• Farvekoder hjælper til at holde styr over de forskellige aktiviteter, medhver sin farve til hver sin aktivitet, som gør brugen af kalenderfunktionenmere brugervenlig.

De ovenstående punkter, er hvad vi �nder relevant i forhold til det system viønsker at udvikle.

28

Funcenter Kapitel 9

9.9 Metaforer

Vi har set funcenteret som et bibliotek, og her så vi nærmere på NordjyllandsLandbibliotek, hvor der var tale om et system, som lader brugerne af biblioteketreservere plads ved computere med internetadgang.Systemet lader som sagt bibliotekets kunder/lånere reservere tid ved en com-puter, det er altså ikke en ansat ved biblioteket, der står for reservationerne.Når en låner vil reservere tid ved en computer, kan vedkommende anvende en af�ere computere som er opstillet på biblioteket, som kun har denne ene funktion.Selve reservationen foregår ved at en låner vælger hvornår vedkommende vilbruge en computer, det gøres ved at vælge et interval på en halv time. Lånerenidenti�ceres vha. CPR-nr. og en adgangskode, som skal oprettes i systemet hosen bibliotekar. Systemet tillader ikke at man sletter en tid.

Figur 9.5: Nordjyllands Landsbibliotek

Vi har desuden valgt at se på udlåns- og reservationssystemet på Jelling Bib-liotek. Vi valgte at se på det system, som bibliotekarerne bruger, frem for detsystem som er tilgængeligt for lånerne via internettet.Udlån af bøger foregår vha. CPR-nr. Når en låner første gang vil låne en bog, o-prettes vedkommende i systemet, således at biblioteket kan holde styr på, hvilkelånere der har lånt hvilke bøger. Bibliotekarerne har mulighed for at hjælpelånere med at �nde det, de leder efter. Systemet tillader at bibliotekarerne kansøge efter en bestemt bog ud fra alle tænkelige parametre, fx forfatter, titel ogISBN. Søgeresultaterne viser hvorvidt en bog er hjemme på det aktuelle bib-liotek, og på de biblioteker som der samarbejdes med (Jelling Bibliotek er endel af Vejle Bibliotekerne, som bl.a. også inkluderer Vejle Bibliotek og GiveBibliotek). Det er muligt at få resultater fra andre biblioteker, men den kræveropslag i en anden database. Hvis en bog ikke er hjemme, kan den reserveres aflåneren. Hvis der allerede er reservationer på bogen viser systemet, hvornår detforventes at bogen er tilgængelig, det viser ikke hvor mange reservationer derer på bogen. Hvis låneren ønsker at reservere bogen tilføjes vedkommende sidsti reservationskøen. Når materialet er tilgængeligt for låneren, vil vedkommendefå besked via SMS, e-mail eller brevpost, afhængigt af hvad vedkommende fore-trækker. Hvis materialet ikke afhentes inden 10 dage annulleres reservationen.Særligt specielt populære titler kan ikke reserveres, og kan kun lånes i 14 dage,frem for en måned.Systemet holder også styr på om lånerne skylder penge for for sent a�everedebøger. Hvis en låner skylder mere end kr. 200,- i gebyrer kan vedkommende ikkefå lov til at låne igen før regningen er betalt.

29

Kapitel 9 Funcenter

Opsamling på metaforer

Selvom der umiddelbart kan synes at være stor forskel på bibliotekssystemerneog vores funcentersystem, kan biblioteket dog bruges som en metafor for voresfuncenter. Hvis vi ser vores funcenter som et bibliotek er der en række forholdsom vi kan bruge i udviklingen af vores system.

• Kalendermodellen fra computerreservationssystemet, er meget lig det kalen-dersystem vi skal have implementeret i vores system.

• Den måde håndteringen af lånere foregår på, kan overføres direkte til voressystem, med få justeringer. Vores system vil fx ikke kræve at kunderne skalopgive deres CPR-nr, dog måske mere deres telefonnummer, som bliverregistreret den første gang de besøger centeret.

• Parallelt med bibliotekssystemet, skal funcentersystemet holde styr påhvilke kunder, der har reserveret hvilke materialer - i vores tilfælde bowl-ingbaner o.l.

30

Kapitel 10

Problemområdet

10.1 Klynger

I klassediagrammet har vi som udgangspunkt kun 1 klynge, som begrundes medat der i virkeligheden er en naturlig inddeling af objekterne i vores problemom-råde. Den klynge vi har i vores system er klyngen "Ressourcer", som indeholderde ressourcer som de forskellige aktiviteter og centeret har til rådighed. Deru-dover knytter der sig til enhver ressource en kalender, som holder rede på hvornården aktuelle ressource er reserveret til. Klyngen vil med tiden blive udspeci�cereteftersom projektet skrider længere frem, og vi når til designfasen af systemet. I[�gur 10.1], er klyngen illustreret i følge standarden for illustration af klynger.

Figur 10.1: Systemets klynge: Ressourcer

31

Kapitel 10 Funcenter

10.2 Struktur

Beskrivelse af klassediagram

Klassen Kunde indeholder som navnet antyder de kundeobjekter, som kan fore-tage reservationer og lave aftaler med funcenteret, dvs. de indeholder data omhvem kunden er mm. Klassen Aftale indeholder speci�kke aftaler, som en kundehar lavet, den indeholder informationer om bl.a. antallet af personer, kundener ledsaget af og hvornår aftalen er oprettet. Denne klasse associerer sig medklassen aktivitet som indeholder informationer om de enkelte aktiviteter, desu-den aggregerer den sig med klassen Tidslot, som indeholder informationer omhvornår en speci�k ressource er reserveret. Aktivitetspakken indeholder infor-mationer og sammensætninger af �ere aktiviteter, derved har en kunde mulighedfor at reservere en samlet løsning af aktiviteter. Ressource Klassen indeholderinformationer om den speci�kke ressource, så som hvilken type aktivitet det erog max antallet af deltagere, som kan benytte den af gangen, desuden fortællerklassen os hvilken tilstand den speci�kke ressource er i, såsom om den er aktiveller deaktiv mm. Klassen Kalender indeholder informationer om hvilken typetidslot vi har med at gøre, eksempelvis kan vi regne i både halve og hele timer.

Den grundliggende ide

Den grundliggende ide i dette reservationssystem er således at en kunde indgåri en eller �ere reservationer, det vil sige aftale(r) med udbyderen, om brugen afen eller �ere ressourcer som tilhører forskellige aktiviteter.

Opsamling af idéen

Alt i alt betyder denne opbygning, at vi har en række forskellige aktiviteter sombestår af en række ressourcer. Til hver ressource har vi en kalender med et antaltidslots, disse tidslots som kan knyttes til en reservation, som så igen knyttes tilen kunde. Således skulle det være muligt at navigere rundt mellem ressourcer,der er reserveret, ledige og optaget.

32

Funcenter Kapitel 10

Figur 10.2: Klassediagram

33


10.3 Klassebeskrivelser

Klassen kunde

Denne klasse indeholder de generelle informationer om kunder.

Klassen Kunde har kun en tilstand: "aktiv", og en instans af klassen er en kundei centeret. I det øjeblik en kunde vil reservere en bane eller aktivitet i centeretbliver han eller hun kunde i centeret. I dette øjeblik sker hændelsen "modtagpersonoplysninger". Kunder har del i mange hændelser som f.eks. "reserver"og"igangsætning af aktivitet". [Figur 10.3], viser tilstandsdiagrammet.

Figur 10.3: Tilstandsdiagram for kunde

Klassen aftale

En aftale indgås når en kunde ønsker at reservere en bane eller bord på etbestemt tidspunkt, eller når en kunde ønsker at bruge et bord eller en baneuden en i forvejen indgået aftale. Klassen har tre tilstande. "planlagt", somer den tilstand en aftale får når den er indgået. Tilstanden: "under afvikling",og "afsluttet"som eksisterer da der er en interesse i at gemme oplysninger omaftaler efter de er afsluttet. Tilstandsdiagrammet ses på [�gur 10.4].

Klassen aktivitet

Denne klasse indeholder informationer om de forskellige aktivitetstyper. Objek-tet bliver oprettet ved beskrivelse af en aktivitet som f.eks. pool eller lasergame,og lever til centeret vælger ikke at udbyde en aktivitet. Objekter har kun entilstand. Se tilstandsdiagrammet på[�gur 10.5].

Klassen ressource

Klasserne har tre tilstande. "fri"når en ressource er tilgængelig for kunder, "ibrug"når den bliver brugt, og "defekt"når ressourcen er fejlmeldt. Objektet

34


Figur 10.4: Tilstandsdiagram for aftale

Figur 10.5: Tilstandsdiagram for aktivitet

35


for ressourcen forsvinder når ressourcen nedlægges. Atributten "type"beskriverom det er et poolbord, lasergamebane, cafébord eller bowlingbane. Attribut-ten "maxDeltagere"beskriver hvor mange deltagere, der kan bruge ressourcensamtidig. Tilstandsdiagrammet ses på [�gur 10.6].

Figur 10.6: Tilstandsdiagram for ressource

Klassen kalender

Denne klasse er associeret med klassen Ressource. Klassen har kun en tilstand,og "lever"så længe den ressource, den er tilknyttet "lever". Kalender er en slagsbeholder for Tidsslot-objekter. Tilstandsdiagrammet kan ses på [�gur 10.7].

Klassen tidsslot

Denne klasse beskriver de enkelte tidsslot i kalenderen, og bliver oprettet når ettidsslot bliver optaget, og lever indtil slottet frigøres ved en aftaleændring ellera�ysning. Tilstandsdiagrammet kan ses på [�gur 10.8].

36


Figur 10.7: Tilstandsdiagram for kalender

Figur 10.8: Tilstandsdiagram for tidsslot

37


Klassen aktivitetspakke

Denne klasse gør det muligt at sammensætte �ere aktiviteter til specielle samledepakkeløsninger.

38


10.4 Hændelser

I [tabel 10.1] viser vores tabel over hændelser, som kan indtræ�e i systemet.Hændelserne i tabellen kommer fra klassediagrammet.En "*"viser, at hændelsen kan ske nul eller �ere gange i objektets levetid, menset "+"viser, at hændelsen kan ske nul eller én gang.

Tabel 10.1: HændelsestabelHændelser/Klasser Kunde Aftale Aktivitet Ressource Kalender Tidsslot

Oprettelse af reservation * * * * *Sletning af reservation * * * * *Redigering af reservation * * * * *Igangsætning af reservation * + * *Afslutning af reservation * + * *Oprettelse af kunde +Redigering af kunde *Klarmeld ressource * * *Fejlmeld ressource * * *Betaling * +Oprettelse af ressource *Redigering af ressource *Sletning af ressource *

39

Kapitel 11

Anvendelsesområdet

11.1 Brug

Oversigt

Ved dannelsen af et brugsmønster over vores system, skal vi de�nere aktør-erne for vores system. En aktør kan beskrives som en abstraktion over brugereeller andre systemer, der interagerer med systemet, her et reservationssystem. Iforbindelse med det projekt vi udarbejder, er medarbejderen og administatoren(admin) aktører for vores system, som kommer til at interagere med reservation-ssystemet i anvendelsesområdet. Medarbejderen håndterer de basale funktionerog administratoren har derudover adgang til de mere avancerede funktionersåsom oprettelse af nye medarbejdere og tilføjelse, redigering og sletning afressourcer. Aktører beskrives i aktørspeci�kationer, som består af følgende tredele.

• formål; hvor aktørens rolle i forhold til systemet beskrives kortfattet ogpræcist

• karakteristik; hvor de væsentlige forhold for aktørens brug af systemetbeskrives samt eksempler.

Funktioner i anvendelsesområdet

I skiftet fra problemområdet til anvendelsesområdet, opstår der krav om nyefunktioner. Dette er funktioner der ikke ses i problemområdet. Oprettelse ogsletning af medarbejdere og login er funktioner som viste sig nødvendige somfølge af arbejdet med brugsmønstrene. Opdeling af aktører i medarbejder ogadmin, sker på baggrund af ønsket om at de mere avancerede funktioner somadministration af medarbejdere og ressourcer, ikke skal kunne tilgås af alle ak-tører.

40


11.1.1 Aktør

Medarbejder

Formål

En person, der er hovedbruger af systemet. Medarbejderen er ansvarlig for atreservere, redigere og slette reserveringsdata gennem reservationssystemet.

Karakteristik

Medarbejderne er ikke nødvendigvis eksperter inden for IT, men de har alle engrundlæggende viden/erfaring inden for håndtering af et IT-system, som gør atde kan håndtere forskellige basic programmer.

Eksempler

En medarbejder interagerer dagligt med systemet. Det er via systemet, at medar-bejderen bl.a. kan reservere, foretage ændringer, a�yse og få et overblik over deforskellige reservationer samt evt. oprette, redigere og slette personlige kundeo-plysninger. Systemet er derfor uundværligt og et vigtigt værktøj for medarbe-jderen til håndtering af reservationer af funcenterets aktiviteter.

Admin

Formål

En person, der har adgang til de mere avancerede funktioner i systemet. Admin-istratoren står for at håndtere ressourcerne og medarbejderne i systemet. Detteindebærer bl.a. at tilføje, redigere & fjerne resssourcer, der er tilgængelige isystemet.

Karakteristik

Adminen behøver ikke at have større IT-erfaring end den almindelige medarbe-jder, da forskellen på de to blot er, at de har adgang til forskellige funktioner isystemet.

Eksempler

En admin anvender ikke systemet så ofte som en almindelig medarbejder. Hviscenteret på et tidspunkt får en ny bowlingbane er det administratoren, der skalsørge for at denne bliver oprettet i systemet, således at den kan reserveres. Deter også administratoren, der står for at tilføje en medarbejder i systemet ved ennyansættelse.

41


Aktørtabel

Tabel 11.1: AktørtabelBrugsmønster/Aktør Reservationsmedarbejder AdminOpret reservation xRediger reservation xSlet reservation xOpret ressource xRediger ressource xSlet ressource xFejlmeld ressource xKlarmeld ressource xTilføj medarbejder xRediger medarbejder xFjern medarbejder x

42


11.1.2 Personas

For en mere uddybende beskrivelse af vores medarbejder-aktør, vil vi se på etpar personas af den aktør, som vi har med at gøre i vores reservationssystem[21].

Figur 11.1: Personas

Persona nr. 1

Susanne Jørgensen, som ses på [�gur 11.1], er 22 år og studerer HumanistiskInformatik på Aalborg Universitet. Hun er på sit fjerde semester og hun haret deltidsjob på 10-12 timer, fordelt på 2 gange om ugen i et funcenter. Måletmed deltidsjobbet er som første prioritet at supplere SU'en samt have det sjovtpå arbejde i et travlt bar-miljø. Hendes opgaver i funcenteret er at tage imodaftaler og reservationer af de forskellige aktiviteter i funcenteret, som både skerved baren, såvel som ved telefonen. Derudover er hun også med til at servicerekunderne i baren. Hun har et basalt kendskab til IT, hvilket vil sige at huner i stand til at bruge forskellige skriveværktøjer såsom Word, Excel, Outlookmv. Derudover bruger hun af og til internettet i forbindelse med hendes studie,hvilket giver hende en større viden indenfor IT. Susanne kendte ingen lignendesystemer før hun påbegyndte arbejdet i funcenteret, dog er hun en meget læren-em medarbejder.

Persona nr. 2

Miguel Inzaghi, som ses på [�gur 11.1], er 19 år og går i 3.g på Hasseris Gym-nasium i udkanten af Aalborg. Han har et deltidsjob på 8-10 timer om ugen,fordelt i weekenderne i et funcenter. Målet med hans deltidsjob er at lære adskil-lige færdigheder indenfor restaurant-branchen, idet hans far ejer �ere forskelligestørre restauranter i andre storbyer, og det ligger til familien, at Miguel skalovertage dem alle på et senere tidspunkt. Hans opgaver i funcenteret, er at tageimod aftaler og reservationer i baren såvel som telefonen, og dertil afrydde deforskellige caféborde i café-afdelingen i funcenteret. Miguel har fra lille haft k-endskab til IT, idet hans far lærte ham brugen af forskellige IT-systemer i entidlig alder, hvilket gør ham til ekspert i brugen af IT. Han har også kendskabtil andre reservationssystemer, såsom dem som hans far har i hans restauranterog barer.

43


Persona nr. 3

Inge Poulsen er 35 år, som ses på [�gur 11.1], og enlig mor til to børn på hen-holdsvis otte og 10 år. Hun bor i en lille lejlighed i Vejgaard i Aalborg. Hunhar et fuldtidsjob som servitrice i et funcenter, hvor hun tager sig af aftaler ogreservationer og servicerer kunderne i centeret. Målet med hendes job er at t-jene penge til lejligheden i Vejgaard samt til børnene. Derudover har hun en storinteresse i bar- og restaurantmiljøet og har været i branchen i 15 år, hvilket gørhende professionel på det område. Hun har været med siden dengang man skrevaftalerne op i en fysisk kalender og da det første IT-system blev implementereti funcenteret. Inges IT-kendskab har aldrig været hendes førsteprioritet, dog erhun meget ivrig efter at lære nye ting, og ser kun nye IT-værktøjer som en udfor-dring. Hun har i løbet af sine 15 år haft med forskellige reservationsværktøjer atgøre, og har derfor ekspertise i at fortælle hvilke systemer som virker og hvilkesom ikke gør.

44


11.1.3 Scenarier

Scenarie 1

Med udgangspunkt i personaerne Inge og Miquel - medarbejderePå en ganske almindelig hverdag modtager medarbejderen Inge som så ofte etopkald fra en kunde, der ønsker at bestille en aktivitet. Denne kunde ønskerat reservere en bowlingbane. Inge indtaster den ønskede dato og tidspunkt isystemet og vælger bowling som aktivitetstype. Systemet tjekker om kundensønsker kan blive opfyldt, ved at søge efter ledige tider i kalenderen og præsenter-er Inge for de mulige valg omkring det ønskede dato og tidspunkt. Inge vælgeren ledig bane på det ønskede tidspunkt og spørger derefter kunden om telefon-nummer og indtaster dette. Det viser sig at kunden ikke allerede eksisterer isystemet, så Inge beder kunden om yderligere oplysninger og indtaster dette isystemet. Systemet beder om bekræftelse på de indtastede informationer. Ingevælger 'ok' og reservationen gemmes i systemet. Inden røret bliver lagt på, fore-spørger Inge kunden om han/hun kunne have interesse i at spise efter bowling,hvilket betyder at Inge skal oprette en aktivitetspakke. Tilføjelsen af en ek-stra aktivitet på samme reservation sker på samme måde som tilføjelse af enaktivitet. Dog takker kunden nej tak til tilbuddet om spisning og reservation-sprocessen afsluttes.Senere samme dag ringer kunden igen og vil gerne have en ekstra bane samttidspunktet rykket en time frem hvis muligt. Miguel, der har taget telefonen,spørger om kundens telefonnummer og indtaster dette. Systemet tjekker efterom nummeret er registeret på forhånd og Miguel præsenteres for oplysninger omkunden og den dertilhørende reservation. Desuden kan han se at Inge har ståetfor reservationen tidligere på dagen. Miquel går ind i kalenderen og ser at derkun er to ledige baner, der står side om side, to timer senere og spørger kundenom dette tidspunkt er �nt, før han foretager sig noget videre. Idet kunden giv-er sin godkendelse, redigerer Miguel tidspunktet og den opdaterede reservationgemmes i systemet, hvorefter han bekræfter overfor kunden, at reservationen erblevet ændret.

Scenarie 2

Med udgangspunkt i adminSusanne opdager en lørdag formiddag, kort før funcenteret åbner, at et af pool-bordene er gået i stykker. Via systemet fejlmelder hun det defekte bord og giverbesked til sin overordnede. Susanne fortæller ham samtidig at dette bord harværet i stykker mange gange på det sidste. Den overordnede logger ind somadmin i systemet. Han vælger at slette ressourcen helt da det er nedslidt ogder i virkeligheden er mere brug for pladsen til �ere caféborde. Desuden huskerden overordnede sig selv på at der starter en ny medarbejder i centeret denkommende uge, og derfor opretter han på samme tid den nye medarbejder ireservationssystemet.Da den overordnede er en travl herre, beder han Susanne om at se kalenderenfor poolbordet igennem og tjekke listen med de reserveringer, der skulle værepå det pågældende bord, da dette også er muligt via en medarbejderlogin. Altefter om det er muligt, �ytter Susanne reservationerne hen til et ledigt bord.Hvis ikke, kontakter hun kunderne og meddeler dem situationen.

45


Brugsmønstre fra scenarierne

I ovenstående scenarier forekommer �ere forskellige brugsmønstre. Vi har valgtde brugsmønstre ud, som vi mener er relevante at beskrive yderligere.

• Oprettelse reservation

• Redigering af reservation

• Oprettelse af kunde

• Oprettelse af medarbejder

• Oprettelse af aktivitetspakke

• Oprettelse af ressource

• Fejlmelding af ressource

• Sletning af ressource

• Tjek kalender

46


11.1.4 Brugsmønstre

Oprettelse af reservation

Figur 11.2: Sekventielt tilstandsdiagram - Oprettelse af reservation

47


Interaktionsrum - Oprettelse af reservation

Figur 11.3: Interaktionsrum - Oprettelse af reservation

Brugsmønsterbeskrivelse - Oprettelse af reservation

BeskrivelseOprettelse af reservation.Først åbnes et skærmvindue, hvorpå det er muligt at indtaste hvilken aktivitetman ønsker at reservere samt dato og tidsrum, hvorefter systemet søger efteren mulighed for reservation. Det næste skærmbillede viser en kalenderoversigtover den valgte aktivitet på den valgte dato, samt et par timer frem og tilbage,så der er mulighed for at browse for andre tidsrum før det endelige valg afreservation. Når man har fundet en tid, markerer man tiden og klikker på vælg,som dernæst bliver vist i et nyt skærmvindue. Hvis tidsrummet allerede er re-serveret, har man mulighed for at søge efter en ny tid, ved at blive gå tilbagetil første skærmbillede, og derefter indtaste nye reservationsoplysninger. For atvære sikker på, at den valgte tid er den korrekte, bekræfter man valget i etnyt bekræftelsesvindue, hvor man bliver sendt videre til personoplysningsvin-due. Før indtastningen af personlysninger er der mulighed for at tilføje ekstraaktiviteter. Efter valget af de forskellige aktiviteter er indtastet, forespørgerbrugeren kunden om dennes telefonnummer. Hvis telefonnummeret allerede ek-sisterer i systemet, �ndes kundes personoplysninger automatisk. Hvis kundenikke er oprettet i systemet, indtaster man kundens oplysninger i samme vindue.Efter personoplysningerne er modtaget, vises disse i et nyt vindue, som skalbekræftes, før der foretages en udførelse af reservationen. Dette er det sidsteskærmvindue for en reservation af en ressource.

ObjekterPerson, Reservation, Aktivitet, Spisning, Pool, Lasergame, Bowling, Kalender

48


Redigering af reservation

Figur 11.4: Sekventielt tilstandsdiagram - Redigering af reservation

49


Interaktionsrum - Redigering af reservation

Figur 11.5: Interaktionsrum -Redigering af reservation

Brugsmønsterbeskrivelse - Redigering af reservation

BeskrivelseRedigering af reservation.En allerede eksisterende reservation kan redigeres af en medarbejder efter ønskefra kunden. Medarbejderen skal dog være logget ind i systemet, før der kanforetages ændringer (så der kan holdes øje med, hvem der redigerer i hvilke o-plysninger, så der ikke eventuelt opstår misforståelser senere hen). Til at kunneforetage en redigering i en reservation skal kunden oplyse sit telefonnummer.Medarbejderen taster oplysningen ind i et søgefelt på hovedskærmen for atsøge efter kunden og den dertilhørende reservation. Systemet henter herefteroplysninger om kunden og den pågældende reservation frem på et nyt skærm-billede. Medarbejderen kan på selvsamme skærmbillede (personoplysningsvin-duet) ændre det kunden ønsker, det være sig dato eller tidspunkt. Herefterbekræftes den nye reservation, hvorved den bliver opdateret. Hvis kundens ønskeikke kan imødekommes pga. allerede eksisterende reservationer, stiller systemetselv nogle forslag i et nyt skræmvindue, som prøver så vidt muligt at nærme sigkundens ønsker. Valgene foretages og bekræftes, hvorefter reservationen bliverregistreret i systemet.


50


Sletning af reservation

Figur 11.6: Sekventielt tilstandsdiagram - Sletning af reservation

51


Interaktionsrum - Sletning af reservation

Figur 11.7: Interaktionsrum - Sletning af reservation

Brugsmønster-beskrivelse -Sletning af reservation

BeskrivelseSletning af reservationsdata.Sletning af en reservation igangsættes, når en kunde ønsker at få slettet enreservation i vedkommendes navn. Medarbejderen indtaster personinformationfor at få oplysninger om reservationer tilhørende denne person. Medarbejderenser nu en liste over de reservationer tilknyttet kunden. Herefter vælges denreservation der skal slettes, og sletningen bekræftes, det er muligt at gå tilbageog slette �ere reservationer. Medarbejderen kan også annullere sletningen hviskunden fortryder, og brugsmønsteret slutter.


Brugsmønsterbeskrivelser

Opret ny reservation

Når en kunde ønsker at reservere tid til en aktivitet i funcenteret, kan ved-kommende enten ringe til centeret eller møde op personligt. En medarbejdervil betjene kunden og tage imod bestillingen. Medarbejderen vælger den ak-tivitet (fx bowling) og dato, som kunder forespørger, i systemet. Derudovervælges i kalenderen det tidspunkt, hvorpå kunden ønsker at placere en reserva-tion. Systemet melder tilbage om der er ledige ressourcer (fx bowlingbaner) pådet givne tidspunkt. Hvis det er muligt at oprette en reservation på det ønskedetidspunkt, skal medarbejderen indtaste kundens telefonnummer i systemet. Sys-temet tjekker så, ved hjælp af telefonnummeret, om kunden i forvejen eksistereri systemet. Hvis det er kundens første besøg, eksisterer vedkommende ikke i sys-temet og medarbejderen skal bruge yderligere oplysninger, så kunden kan blive

52


oprettet. Når systemet har modtaget de nødvendige oplysninger om kunden, vilreservationen blive gemt i systemet.


Hvis en kunde, af den ene eller anden årsag, ønsker ændringer foretaget i en ek-sisterende reservation, kan vedkommende enten ringe til centeret eller møde oppersonligt. En medarbejder vil betjene kunden. For at kunne foretage ændringeri en eksisterende reservation skal medarbejderen bruge kundens telefonnummer,som også fungerer som kundenummer. Ved hjælp af kundenummeret kan sys-temet �nde frem til hvilke reservationer der er foretaget til denne kunde. Medar-bejderen har nu mulighed for at �ytte reservationen til et andet tidspunkt, hvoren tilsvarende ressource er ledig. Dette sker ved hjælp af kalenderen i systemet.Kalenderen viser reservationens nuværende placering, og lader medarbejderen�ytte den til et andet tidspunkt.

Sletning af reservation

Hvis en kunde, af den ene eller anden årsag, ønsker at slette en eksisterendereservation, kan vedkommende enten ringe til centeret eller møde op person-ligt. En medarbejder vil betjene kunden. For at kunne slette i en eksisterendereservation skal medarbejderen bruge kundens telefonnummer, som også funger-er som kundenummer. Ved hjælp af kundenummeret kan systemet �nde fremtil hvilke reservationer der er foretaget til denne kunde. Medarbejderen har numulighed for at slette reservationen, og reservationen er derefter ikke længereat �nde i systemet.

53


Samlet interaktionsrum

Figur 11.8: Diagram over det samlede interaktionsrum

54


11.1.5 Brugsmønsterdiagrammer

Brugsmønsterdiagrammer

Vi vælger herunder at lave et brugsmønsterdiagram, som har til formål at gøredet nemmere at �nde frem til funktioner i systemet. Alle bobler i diagrammetmed undtagelse af dem i den kolonne tættest på aktøren, er funktioner.

Samlet brugsmønsterdiagram for systemet

Figur 11.9: Samlet brugsmønsterdiagram for systemet

55


11.2 Funktioner

11.2.1 Komplet funktionsliste

I [tabel 11.2], kan man se den komplette funktionsliste. Ved hjælp af denne listekan man se hvilke funktioner der skal understøtte systemet, samt hvem der skalanvende disse funktioner.

Tabel 11.2: FunktionstabelNavn Kompleksitet TypeForespørgsel på ledig ressource Middel A�æsningVælg ressource Simpel OpdateringOprettelse af reservation Kompleks OpdateringRedigering af reservation Kompleks OpdateringSletning af reservation Simpel OpdateringVælg reservation Simpel A�æsningOprettelse af aktivitetsaftale Middel OpdateringOprettelse af ressource Middel OpdateringNedlæg ressource Simpel OpdateringValg af ressource Simpel OpdateringRedigering af ressource Simpel OpdateringFejlmeld ressource Simpel OpdateringKlarmeld ressource Simpel OpdateringSe kunde Simpel A�æsningSøg kunde Simpel A�æsningVælg eksisterende kunde Simpel A�æsningOpret kunde Middel OpdateringSe ressource Simpel A�æsningSe medarbejder Simpel A�æsningLogin Simpel OpdateringLogout Simpel OpdateringList reservationer Simpel A�æsning

11.2.2 Speci�kation af funktioner

Her følger en speci�kation af de komplekse funktioner.

Oprettelse af reservation

Oprettelse af en ny reservation er en kompleks funktion, da den kræver at sys-temet skal foretage en række tjek på ledige ressourcer. Systemet skal tjekke,om det kan lade sig gøre at oprette en reservation af den givne aktivitet pådet givne tidspunkt. Systemet melder altså tilbage til medarbejderen, om denvalgte dato og det valgte tidspunkt er tilgængeligt for den valgte aktivitet. Deter komplekst at implementere en funktion som denne, da den skal søge igennemstore mængder af information.

56



Denne funktion minder på mange måder om funktionen Oprettelse af reserva-tion, og derfor er den ligeledes kompleks. Når en reservation skal �yttes fra ettidspunkt til et andet, skal systemet foretage de samme tjek, som når en medar-bejder vil oprette en helt ny reservation. Dette indebærer altså at systemetskal �nde ud af, om det kan lade sig gøre at �ytte reservationen af de aktuelleressourcer, til det nye tidspunkt. Forskellen er blot at der nu også skal slettesen eksisterende reservation fra det gamle tidspunkt.

57


11.3 Brugergrænse�aden

11.3.1 Mål for brug

Brugeren af systemet vil som angivet i systemde�nitionen be�nde sig i et bar-miljø, hvor der ofte kan forekomme perioder med travlhed, og hvor brugeren kankomme ud for at skulle interagere med �ere på en gang. Det er derfor et kravaf afgørende betydning at systemet er nemt at huske (memorability), såledesbrugeren kan huske de forskellige funktionaliteter - selv midt i travlheden. De-raf er det dermed også vigtigt at brugeren hurtigt lærer at benytte systemet(learnbility) og så snart brugeren har lært at anvende systemet, skal det væree�ektivt (e�ectiveness). Systemet skal betjenes af brugere med mindst en basalkendskab til brug af IT-værktøj, det er derfor irrelevant at have forskellige til-gange til en funktion (utility) og derved muligvis komplicere brugen af systemetmere end nødvendigt. At systemet er ligetil er derfor vigtigt (Og som følge afdette kriterium er sikkerheden ikke højt prioriteret, idet sandsynligheden forat begå en fejl er minimal). Vi har ikke lagt vægt på brugeroplevelsen, idetvi ikke mener de er relevante i et system, der er udviklet til administration afreservationer. Med udgangspunkt i disse betragtninger er et prioriteringsskemaudformet, se [tabel 11.3]. Skemaet viser hvordan vi har prioriteret de forskelligemål i forhold til brugbarhed (usability) og brugeroplevelse (experience).

Prioriteringsskema

Tabel 11.3: PrioriteringsskemaMeget vigtigt Vigtigt Mindre vigtigt Irrelevant

Usability E�ectiveness xE�ciency xSafety x*Utility xLearnability xMemorability x

Experience Satisfying xEnjoyable xFun xEntertaining xHelpful xMotivating xAesthetically pleasing xSupportive of creativity xRewarding xEmotionally ful�lling x

*Safety: Ifølge de�nitionen for DIEB: Sikkerhed mod at brugeren udfører en fork-ert handling er safety mindre vigtigt. Hvis de�ntionen personsikkerhed bruges,er safety irrelevant.

58


11.3.2 Begrebsmæssig model

Da vi ikke har valgt at stille nogle særlige krav til brugernes IT-erfaring, er detvigtigt at vores system er let at gå til. Det skal helst være logisk hvordan engiven funktion udføres. Det skal være let at gennemskue hvad en given knapgør, og hvornår systemet f.eks. skal modtage bruger-input.

Vi har valgt at bruge interaktionsformen WIMP1. Denne form for interface ermeget udbredt indenfor programudvikling på stort set alle platforme, og det erderfor realistisk at forvente, at den gennemsnitlige bruger vil have en vis gradaf erfaring indenfor brug af et sådant system. Vores system vil også indeholdeskemaudfyldelse til f.eks. indtastning af kundeoplysninger.

Systemet anvender følgende interaktionstyper: Instruktion, Konversation samtUdforskning og Browsing. Instruktion �nder for eksempel sted, når en medar-bejder vælger at forespørge på en ledig ressource. Her vender systemet tilbagemed en oversigt over ledige ressourcer.

Processen med at foretage en reservation foregår ved hjælp af Konversation.Her giver medarbejderen systemet nogle input (for eksempel ressourcetype),som systemet behandler, hvorefter det beder om yderligere oplysninger (f.eks.kundeoplysninger). Udforskning og Browsing er f.eks. i brug når medarbejderenskal vælge en ressource til et givent tidspunkt, i kalenderen.

Vi har valgt at bruge C# til programmeringen af systemet, fordi det er det vier blevet opfordret til, og det er det programmeringssprog vi har mest erfaringmed.

1Windows, Icons, Menus, Pointers - Præsenteret i DIEB

59


11.4 Den tekniske platform

Systemet udvikles til brug på en Windows-baseret stand-alone PC-platform,og er programmeret i programmeringssproget C#. Valget af C# sker på bag-grund af det programmeringskursus, vi har haft i forbindelse med dette semester.Til PC'en er tilsluttet en touchscreen, som skal lette processen med at foretagereservationer. Brug af tastatur/mus er muligt i forhold til mere komplekse reser-vationer, nye kunder og lignende.

11.5 Anbefalinger

Ud fra den foretagede analyse, mener vi at systemet på nuværende tidspunktvirker realiserbart. Ambitionsniveauet, som er beskrevet i formålet til det beskrevnesystem, stemmer overens med målsætningen, og systemet vil derfor blive ud-viklet efter de udstukne retningslinjer fra analysedokumentet.

11.6 Strategi

Eftersom første review er overstået, vil vi se på eventuelle rettelser til analyse-dokumentet, før vi vil gå videre til designdokumentet af vores system. Dernæstvil vi skabe en fælles forståelse for opbygningen og strukturen af systemet ogdertil gennemgå systemet fra start til slut, samtidig med at et navigationsdi-agram bliver udviklet. Når navigationsdiagrammet er på plads, kan vi se påkvalitetsmålet for vores system. Dernæst ser vi på arkitekturen af komponenterog processer samt modelkomponenter til systemet. Til sidst afsluttes designfasenmed anden review, som dertil kommenteres af reviewer og nye tilføjelser tilføjes.

11.7 Udviklingsøkonomi

Udviklingen af dette projekt sker over en �re måneders projektarbejde på AAU.Projektet har til formål at indlære nye metoder og modeller for systemudvikling.Arbejdet er ulønnet og AAU forbeholder sig rettigheden til projektets endeligeprodukt, da alle ressourcer til udvikling af projektet/produktet dækkes af AAU.

Udviklingen af projektet sker under opgaveregning i de forskellige kurser somhar relevans for projektet, samt den tid som ligger uden for kurserne, som typiskvil være i hverdage imellem kl. 8.00-16.00. I analysedokumentet blev der brugt�re ugers projekttid og for det videre udviklingsarbejde i designfasen er lagt �reugers projektarbejde til side, som afsluttes mandag den 12. november.

60

Del III

Designdokument

61

Kapitel 12

Opgaven

12.1 Kvalitetsmål

Vi har i analysefasens systemde�nition redegjort for, hvad vi ønsker systemetskal kunne, hvor de væsentlige krav er at systemet skal være nem at bruge ogudførelsen af opgaverne skal være e�ektiv og ske på en brugervenlig. Derudoverskal brugeren formå at danne sig et overblik over systemets funktioner, og haveen forståelse for funktionernes sammenhænge, og han/hun skal kunne stole påsystemet og opnå en tillid til brugen af systemet. Systemet skal være nemt forbrugeren at kunne redigere i diverse aftaler/oplysninger samt tilføjelse af nyekunder, og skal styres af en stand-alone PC-platform.

Herunder har vi listet de kvalitetsmål for vores system. hvor vi har afkrydsetdem, efter hvor vigtigt de netop er for det system vi udvikler.

12.1.1 Kvalitetsmålsskema

Tabel 12.1: KvalitetsmålsskemaKriterier Meget vigtigt Vigtigt Mindre vigtigt Irrelevant Trivielt opfyldt

Brugbart xSikkert xKorrekt xPålideligt xVedligeholdbart xTestbart xFleksibelt xForståeligt xGenbrugbart xFlytbart xE�ektivt xIntegrerbart x

62


12.1.2 Beskrivelse og begrundede kriterier

Herunder vil vi gå igennem hvert kriterie samt begrunde for dets prioriterings-grundlag.

Brugbart

Systemet, som vi har valgt at udvikle, har en stor vigtighed hvad angår omsystemet er brugbart for brugeren. Hvis systemet �ndes besværligt at anvende,opstår problemer om udførelse af opgaver, samt systemets formål forsvinder.

Sikkert

Når vi snakker om sikkerhed, snakker vi om sikkerhed i forbindelse med atbrugeren har brug for brugersensitive oplysninger i forbindelse med indtastningaf kunder mv. Derfor er det et vigtigt krav, at sikkerheden hvad angår kundernesoplysninger ikke er tilgængelige for enhver, og kun brugere med login og kodeordhar adgang til systemet. Et andet krav i forhold til kriteriet, er at systemet skalkunne køre på den PC-platform som centeret har opstillet, samt vigtigheden iat der bliver taget hensyn til hardwarespeci�kationer til platformen.

Pålideligt og Korrekt

Kriterierne 'Pålideligt' og 'Korrekt' er i sin vis meget vigtige kriterier i voressystem, da det skal foretage korrekte registreringer af alt data og gemme demde relevante steder i systemet. Eksempel på disse kan være data/oplysninger omreservationer, kunder samt valg af aktiviteter.

Vedligeholdbart

At systemet er muligt at vedligeholde er ikke så vigtig et kriterie, da systemetikke kræver opdateringer med tiden, for at det skal kunne fungere. Systemetbliver muligt at bruge den dag det sættes i brug for første gang og videre vedlige-holdelse er ikke så vigtigt.

Testbart

At systemet er testbart, er et vigtigt kriterie, da der selv under udviklingen skalvære mulighed for at teste systemet af, og eventuel �nde fejl som kan rettes til,før det endelige system er færdig. Kriteriet er også en vigtighed, da der skalvære mulighed for at evaluere systemet eftersom udviklingen er endt, og manstår tilbage med et system som virker funktionelt.

Fleksibelt

Fleksibiliteten af systemet er ikke så højtprioriteret idet at den ikke kræver, atder bruges andre eksterne systemer for brugen af selve systemet.

63


Forståeligt

Kriteriet 'forståeligt' er meget vigtig i systemet, da brugeren skal opnå en visforståelig i brugen af funktionerne i systemet for at kunne anvende og udførede opgaver, som han/hun ønsker. Derfor skal tekst, billeder, ikoner, menuer ogknapper være lette at læse og forstå psykisk og bringe konsistens i forhold tildens brug.

Genbrugbart

Om enkelte komponenter i vores system kan genbruges, er ikke essentielt forsystemet, dog kan det hjælpe til med at lette udviklingen af systemet og derforer kriteriet prioriteret som vigtigt i forhold til udviklingen af vores system.

Flytbart

Kriteriet er i vores tilfælde irrelevant, da vores system kun bruges på en stand-alone PC-platform, og derfor opstår der ikke et behov for brug af systemet fra�ere forskellige steder. Derudover er systemet ikke på noget netværk, som givermulighed for ekstern tilgang til systemet.

E�ektivt

At systemet er brugbart, er just et kriterie som er vigtigt for systemet. Dog ere�ektiviteten i systemet et ligeså højtprioriteret kriterie, idet brugeren i voressystem arbejder i et travlt bar-miljø, hvor det går stærkt i betjeningen af kunder,samt brugeren skal have en mulighed for at kunne multitaske samtidig medbrugen af systemet. Det vil sige, at en bruger skal kunne have mulighed for atskænke øl op, imens han bruger en anden hånd til håndtering af systemet.

Integrerbart

At systemet er integrerbart er heller ikke så vigtigt et kriterie, idet systemet skalkunne integreres den ene gang det installeres, og derefter ikke kræver nogen formfor opdatering eller integration af nye tiltag til systemet.

64

Kapitel 13

Teknisk platform

13.1 Udstyr

Systemet skal fungere på en Windows-baseret stand alone-PC. Vores systemkommer altså rent hardwaremæssigt kun til at bestå af en enkelt enhed. Al datasom systemet anvender, vil blive gemt lokalt på maskinen i �ler frem for i endatabase. Dette sker da det er et krav fra Universitetet at vi ikke skal arbejdemed databaser på dette semester. Da vi har valgt at udvikle vores system til entouchscreen, er det krævet at PC'en har en touchscreen tilkoblet. Der vil dogogså være mus og tastatur tilknyttet PC'en til brug i nødsituationer og til mereavancerede opgaver.

13.2 Basisprogrammel

PC'en, som systemet skal køre på, skal være af nyere dato. Dette indebærerat den skal være i stand til at køre en nyere version af et Microsoft Windows-operativsystem (Windows XP eller Windows Vista). Selve udviklingen af sys-temet foregår i programmeringssproget C# 2.0[9] og brugergrænse�aden vilblive udviklet med Windows Forms. Brugen af C# 2.0 og Windows Forms gørydermere, at maskinen som skal køre programmet, skal have Microsoft .NETFramework 2.0[10] eller nyere installeret for at kunne eksekvere vores program.C# er et objektorienteret programmeringsprog udviklet af Microsoft. Det erbaseret på C++ og Java, og minder således om disse sprog på nogle punkter.

13.3 Systemgrænse�ade

Da vores system skal fungere på en stand alone-PC, skal det ikke interagere medeksterne systemer eller apparater. Vores system gør brug af en touchscreen, menda denne blot fungerer som en mus, har vi ikke vurderet, at det er nødvendigtat beskrive den interaktion der �nder sted.

65


13.4 Designsprog

UML[6] er det designsprog, som vi vælger at beskrive vores reservationssystemmed. UML står for Uni�ed Modeling Language, og er en standard for diagram-mer til beskrivelse af strukturer og forløb i netop objekt-orienterede softwaresys-temer. UML er udviklet af Object Managament Group (OMG).UML har gra�ske notationer for de �este begreber og mulige sammenhængemellem begreber indenfor objekt-orienteret softwareudvikling, og til det formåler UML i dag blevet en "de facto"standard.

66

Kapitel 14

Arkitektur

14.1 Designkriterier og arkitektoniske krav

14.1.1 Faktor-tabel

Ved at lave en faktortabel kan vi få et indblik i hvilke faktorer, der kommertil at spille ind i udviklingen og brugen af systemet og derved modvirke evt.kommende problemer og ulejligheder. Tabellen som ses i [tabel 14.1 udtrykkerdesuden vigtigheden af at den enkelte faktors mål og krav bliver opfyldt. Vihar derfor udvalgt seks faktorer, som vi anser for at være vigtige i udviklingenog implementeringen af systemet. Første kolonne i tabellen angiver de valgtefaktorer, mens anden kolonne tegner et billede af de kvalitetskriterier, der måttevære og som skal overholdes. Den tredje kolonne viser hvorvidt kriterierne er�eksible, mens den næste kolonne viser hvilken konsekvens, det vil have forbrugeren, hvis målet ikke er opnået. De to sidste kolonner angiver hvor storrisikoen eller sværhedsgraden er i sammenhæng med implementeringen. Her erden enkelte faktor angivet med enten et H (høj), et M (middel/medium) elleret L (lav).

14.2 Generiske designbeslutninger

I dette afsnit vil vi beskrive de generiske designbeslutninger. Generiske de-signbeslutninger er en form for generelle beslutninger omkring design i allekategorier. Et eksempel på en kategori kan fx være tekstinput. Her kunne manopstille nogle retningslinjer for, hvordan sådan en skal designes. De valgte gener-iske beslutninger anvendes over hele systemet. I udviklingen af et hvilket somhelst IT-system, er det derfor godt på forhånd at opstille generiske beslutningerom designet for det system man ønsker at udvikle. Vi har herunder listet degeneriske designbeslutninger, vi har valgt at bruge under vores udvikling afreservationssystemet.

Brugergrænse�ade

Det er nødvendigt at tage højde for, at vores system skal fungere på en touch-screen, når vi skal designe systemets brugergrænse�ade. Derfor er elementer i

67


Figur 14.1: Faktortabel

68


bruger�aden såsom knapper, inputfelter osv. større end de traditionelt vil være,for at de derved vil være lettere at ramme med �ngre.

Knapper

Knapper i systemet skal overholde en række krav, som skal være med til at sikreat systemet er logisk at bruge. En knap med en given funktion skal have densamme placering i alle forms. Knapperne i systemet holdes i samme gra�skestil, således at der ikke er tvivl hos brugerne om hvad der er en knap. Særligeknapper som dem der bruges til at vælge hvilke ressourcer der skal søges i,skiller sig ud fra det generelle knapdesign, da disse er en anden slags knapper. Inederste højre hjørne vil der altid være to eller �ere knapper. Disse vil ændre sigalt efter om systemet be�nder sig i en kæde af forms. Hvis brugeren skal tilbage,vil der være en Annuller-knap og hvis det er muligt for brugeren at bevæge siget skridt videre, vil der være en Godkend-knap. Denne Godkend-knap vil væreændret til en Gem-knap, hvis brugeren er kommet til den sidste form i kæde ogskal gemme data.

Tekstinput

Et reservationssystem vil helt naturligt kræve input fra brugerne, da der i sys-temet er situationer, som kræver at brugeren skal udfylde tekstfelter, bl.a. for atoprette eller opdatere noget. Når brugeren ønsker noget oprettet, skal der i sys-temet indtastes dato, tid og kundenr. I en situation som denne, hvor brugerenskal indtaste data vil der altid blive anvendt tekstfelter. Disse tekstfelter benyt-ter altid samme layout. Dette sker for at sikre at der, for brugeren, aldrig ertvivl om at der er tale om at systemet skal bruge input.

Bekræftelse ved hjælp af dialogboks

Hver gang brugeren skal gemme, ændre eller slette data i systemet, skal systemethave en bekræftelse. Dette sker ved hjælp af en dialogboks. Da der er et stortarbejde forbundet med genoprettelse og at brugeren lettes i sin arbejdsgang hvisfejltastninger undgås, skal brugeren derfor alt efter hvilken type manipulationder er i gang, give sin bekræftelse til systemet før operationen foretages.

Browsing

Måden at �nde frem til den ønskede ressource, er ved at browse sig igennem deoprettede ressourcer under den enkelte aktivitet. Herefter er der mulighed forat lave en aftale for kunden eller hvis ressourcen er optaget, er det muligt atbrowse videre til en anden ressource og reservere den i stedet.

Persistens

For at håndtere persistens bruger vores system Serialization, som er et interfacei C#. Serialization er en måde at gemme objekter i for eksempel �ler. Ved hjælpaf Deserialization kan objekter hentes ind i systemet igen. At vigtigt data kangemmes på disken, sikrer at systemet kan fungere, selvom det eventuelt skalgenstartes eller uventet går ned.

69


14.3 Komponentarkitektur

Da vores system er forholdsvis simpelt med hensyn til komponenter har vi val-gt at lave vores komponentarkitektur på baggrund af �gur 10.5 i OOA&D. På[�gur 14.2], ses vores komponentarkitektur.

Figur 14.2: Komponentarkitektur

Vi har valgt at have en Brugergrænse�adekomponent frem for en Grænse-�adekomponent. Dette valg er foretaget fordi vores system ikke indeholder nogensystemgrænse�ader. Til gengæld indeholder vores system to forskellige bruger-grænse�ader - en til reservationsmedarbejderne og en til administratoren.

Modelkomponenten indeholder modellen af problemområdet, altså de dele affuncenteret som systemet skal administrere. Data i modelkomponenten gemmesved hjælp af en lagringskomponent. Da vi ikke anvender en database, har vivalgt navnet Lagringssystem frem for Databasesystem. Indholdet i modelkom-ponenten påvirkes gennem Funktionerkomponenten, og adgang til denne opnåsgennem Brugergrænse�adekomponenten. Der �ndes to forskellige slags bruger-

70


grænse�ader, en Reservationsgrænse�ade og en Admingrænse�ade. Reservation-sgrænse�aden er den del af systemet som reservationsmedarbejderne har adgangtil. Det lader dem håndtere aftaler af de forskellige ressourcer. Admingrænse-�aden giver en administrator mere avancerede muligheder, blandt andet mu-lighed for at tilføje og fjerne ressourcer fra systemet. De to typer brugergrænse-�ader giver adgang til forskellige funktioner. Derfor indeholder Funktionerkom-ponenten to subfunktionskomponenter. Admingrænse�aden er en udvidelse afreservationsgrænse�aden, en administrator har altså også mulighed for at brugede funktioner, som en reservationsmedarbejder har, plus de mere avanceredefunktioner, og derfor er admingrænse�aden også forbundet med reservations-funktionerne.

Vores komponentarkitektur er designet som værende Lukket-Streng. At arkitek-turen er lukket betyder at de enkelte lag kun kan bruge operationer fra et lagsom ligger umiddelbart over eller under det aktuelle lag. At arkitekturen erstreng, medfører at de enkelte lag kun kan bruge operationer fra underliggendelag.En lukket arkitektur har den fordel at der er få afhængigheder mellem lagene ogat det dermed er let at ændre i et et lag, uden atskabe for meget uro i systemet.

Vi har vurderet det var relevant at dekomponere Funktionerkomponenten, dader er en væsentlig forskel på de funktioner, der er tilgængelige på de forskel-lige brugergrænse�ader. Vi har ligeledes valgt at dekomponere Brugergrænse-�adekomponenten, da de to grænse�ader giver vidt forskellige muligheder. Tilgengæld har vi ikke vurderet at det var nødvendigt at dekomponere Modelkom-ponenten. Det har vi valgt fordi vores problemområde ikke er særligt komplekst,og det således er de samme dele af Modelkomponenten der påvirkes uanset hvilkefunktioner der anvendes.

14.4 Eksemplariske design

Grundet den tidsmæssige kompleksitet i dette projekt, har vi udvalgt tre af deudarbejdede brugsmønstrede til det videre forløb, det drejer sig om Ny reserva-tion(appendiks 6), som også indeholder de mindre brugsmønstre Ny kunde(appendiks3) og Ny ressource(appendiks 4). Alle de udarbejdede sekvensdiagrammer kandog ses i appendiks.

14.4.1 Opret ny Ressource

Detaljeret use case beskrivelse: Opret ny ressource

Pre-betingelser: Ressourcen er ikke oprettet i systemet.Post-betingelser: Ressourcen er oprettet.

Ved valg af Ressource-liste og derefter Opret ressource, har man mulighed for atoprette en ressource. GF spørger først efter en række parametre, ved indtastningog godkendelse heraf, kalder GF ResourceCtrl med Create, som kalder Resourcehvor der oprettes et nyt objekt af typen resource som gemmes i ResourceList.

71


Resource giver ResourceCtrl en bekræftelse, som sender den videre til GF.

14.4.2 Opret ny Kunde

Detaljeret use case beskrivelse: Opret ny kunde

Pre-betingelser: Kunden er ikke oprettet i systemet.Post-betingelser: Kunden er oprettet.

Ved indtastning af reservation i GF, spørger GF efter kundenummer, ved ind-tastning af kundenummer kalder GF PersonCtrl på id, som kalder personList påid. Hvis objektet fore�ndes, sender Person objektet parametre tilbage til Per-sonCtrl som sender dem tilbage til GF, som viser informationerne.

Hvis kunden ikke �ndes, har man mulighed for at oprette kunden i systemet. Iforbindelse med oprettelse af en ny Kunde, spørger GF efter en række parame-tre, der skal udfyldes. Ved indtastning og godkendelse heraf, kalder GF Createpå PersonCtrl, denne kalder herpå Person, hvor der oprettes et nyt objekt aftypen Person som gemmes i PersonList. Person giver PersonCtrl en bekræftelse,som den sender videre til GF.

14.4.3 Opret ny Reservation

Detaljeret use case beskrivelse: Opret ny reservation

Pre-betingelser: Den ønskede forespørgsel på et reservations på tidpunkt ermulig, desuden �ndes kunden i systemet.Post-betingelser: Reservationen er gemt og der bliver udskrevet eller printet enbekræftelse.

Ved valg af Opret reservation i GF, spørger GF til valg af aktivitet, dato ogtidspunkt. GF kalder Getbusy på AgreementCtrl, AgreementCtrl kalder herpåGetAll på Calender, som sender en Liste tilbage til AgreementCtrl, der indehold-er alle objekter på den pågældende dato som også har referancer til både kunder,resourcer og timeslots. AgreementCtrl sender derpå en TsDataListe tilbage tilGF, derpå viser kalenderen hvilke timeslots som er optaget på hvilke ressourcerog af hvem. Således er derpå muligt, at vælge ikke bookede timeslots på afressourcerne.

Efter en bekræftelse af aftaleforslaget i GF og en efterfølgende godkendelse aftidspunktet, beder GF om Kundenummer. Ved indtastning af kundenummeretkalder GF PersonCtrl, som kalder PersonList på id. Hvis objektet eksisterer,sender PersonList objektet tilbage til PersonCtrl som sender det til GF, derviser informationerne. Hvis objektet ikke fore�ndes i systemet, er det muligtat oprette et objekt af persontypen (se sekvensdiagram for ny kunde). Herefterer det nu muligt at godkende aftalen via GF, som sender en TsDataListe tilAgreementCtrl, her kalder AgreementCtrl Timeslot, hvor der bliver oprettet etobjekt svarende til den valgte aftale i container klassen dato som igen liggeri kalenderen, Timeslot giver herefter en melding på, om det lykkedes. Dennehandling bliver gentaget, indtil der er oprettet objekter svarende til aftalen af

72


de forskellige tidsslots på forskellige ressourcer. Herefter kalder AgreementCtrlAgreement for at oprettet et nyt objekt af typen Agreement, som indeholder idfra de forskellige oprettede timeslots objekter samt Resource id og Person id.Agreement giver en melding tilbage på om det lykkedes til AgreementCtrl sommelder tilbage til GF.

Til sidst er det mulig via GF at vælge om man vil printe eller maile en bekræf-telse til kunden, her kalder GF AgreementCtrl som igen kalder Agreement.

Alternativt forløb 1: Alle tidsslots på den valgte dato og tidsrum er oprettet.I dette tilfælde kan medarbejderen søge på en anden dato og tid eller afbrydeforløbet.

Alternativt forløb 2: Kundenummeret er ikke kendt i systemet. I dette tilfældekan medarbejderen oprette kunden med diverse oplysninger.

73

Kapitel 15

Komponenter

15.1 Struktur

15.1.1 Lag

Systemet er inddelt i �re lag. Generelt gælder det, at de forskellige lag kun tilgårlaget nedeunder eller andre klasser i laget. Dog er der datatyper der bevæger sighelt fra modellaget til brugergrænse�aden. F.eks. et objekt som "Customer",som brugergrænse�aden kan håndtere direkte.

Brugergrænse�aden

Klasserne som bruges til opbygning af brugergrænse�aden.

Funktioner

Som styrer adgangen fra brugergrænse�aden til modellen, Alle klasser i funk-tionslaget programmeres efter singleton-mønsteret for at undgå, at der oprettesmere end et objekt af dem. Desuden giver de mulighed for at tilgå dem fra �ereforskellinge klasser. Klasser i funktionslaget står for instantiering af container-klasserne (List-klasser).

Model

Laget indeholder de klasser, der skal administeres af systemet. Klasserne er entenen abstrakt datatype eller en container (List-klasser) til disse typer. Containernestår for instantiering af de abstrakte datatyper.

Persistens

Laget hvor datalagringen foregår, i dette tilfælde lagring i �ler.

15.1.2 Klassediagram

Klassediagrammet se [�gur 15.1].

74


Figur 15.1: Klassediagram

75


15.2 Klasser

15.2.1 Brugergrænselaget

Login

Formål: Klassen Login har til formål at lade medarbejderen logge sig ind på af-talen via et brugernavn og et kodeord. Hvis man er logget ind som administratoraf systemet, kan man blive navigeret videre til evt. "ny tilføjelse af medarbe-jder"i systemet.

Operationer: afslut program, godkend.

Menu

Formål: Klassen Menu har til formål at vise brugeren de funktioner, som er tilrådighed i systemet, og medarbejderen opfordres til at udvælge den funktion,vedkommende ønsker at foretage.

Operationer: log-out, ressource-liste, opret reservation, kalenderoversigt, søg.

Kalender

Formål: Klassen Kalender har til formål at vise medarbejderen kalenderen forden valgte aktivitet/ressource samt oplysninger om den kunde, som har re-serveret aftalen. Derudover �ndes en oversigt over de forskellige funktioner, somogså �ndes under klassen Menu.

Operationer: dato frem, dato tilbage, indtast yderligere oplysninger, annuller,tilbage, godkend, ret reservation, ny aftale, slet reservation, igangsæt.

Reservation

Formål: I klassen Reservation opfordres medarbejderen til at udvælge den ak-tivitet, eller de aktiviteter han/hun ønsker at lave en reservation til. Udover atindtaste hvilke aktiviteter, skal man indtaste i hvilket tidsrum og på hvilkendato, man ønsker at oprette en aktivitetsreservation på.

Operationer: godkend, annuller

Ressource

Formål: I klassen Ressource opfordres medarbejderen til at udvælge hvilkenaktivitet, eller hvilke aktiviteter han/hun ønsker at lave en aftale til. Udoverat indtaste hvilke aktiviteter, skal man indtaste i hvilket tidsrum og på hvilkendato, man ønsker at oprette en reservation på.

Operationer: godkend, annuller.

76


15.2.2 Klasser i model, funktion, og persistens-laget

Konventionelle attributter og metoder er beskrevet og kan udlæses på klassedi-agrammet. Alle controller (*Ctrl) er implementeret med singleton-mønster.

15.3 Bruger�adekomponenten

Vi har udarbejdet en præsentationsmodel for vores IT-system, hvor vi i hverinteraktionselement, som vises som klasser, har beskrevet de forskellige in- ogoutput attributter samt de actions som fore�ndes.

De forskellige klasser har en kobling til hinanden, og denne kobling er entenbeskrevet som 'navigates' og 'contains'. Navigates viser hvilke tilgange der er tilde forskellige klasser, og contains viser hvilke klasser som nedarver eller inde-holder de andre klasser.

På samme tid med at vi har lavet en præsentationsmodel med indblik på in-og outputs, har vi udarbejdet et navigationsdiagram som vores prototype påsystemet.

Begge de udarbejdede diagrammer kan ses i appendiks 9 og 10.

Diagrammet er udarbejdet således, at man kan få en ide om hvordan navigatio-nen er struktureret i systemet. Ideen med dette diagram er baseret på farver,således at de bestemte knapper/funktioner har speci�kke farver. De pile der vis-er navigationen i systemet, er udarbejdet i samme farver som de funktioner deer knyttet til, på den måde kan man komme frem og tilbage i skærmbillederneved at følge farverne. Farverne er udvalgt så de tildels giver en indikation forhvilken funktion knappen har, men dette er ikke det primære med farvevalget.Farver er valgt for at kunne følge navigationen gennem diagrammet. Dette giveros rigtig god mulighed for at præsentere systemet for en potentiel kunde, da dener mere præsentabel i forhold til præsentationsmodellen. Præsentationsmodellenog navigationsdiagrammet er konsistente med hinanden, og de klasser som visesi præsentationsmodellen ses i de forskellige brugergrænse�ader i navigationsdi-agrammet, og hjælper til at få et større overblik over reservationssystemet.

15.3.1 Interaktionselementer

I dette afsnit identi�ceres �re overordnede interaktionselementer, som ikke er'contained' i et andet interaktionselement; typisk et vindue. Disse præsenteres iform af beskrivelse af den anvendte aktionsform og den fysiske design (en tegn-ing). Der henvises endvidere til de brugsmønstre, hvor det enkelte interaktion-selement anvendes. De �re interaktionselementer vi har valgt er som følgende:

• Reservationsforespørgsel

• Kalender

• Indtast personoplysning

• Klarmeld/fejlmeld ressource

77


Reservations- og aktivitetsforespørgselInteraktionselementet Reservationsforespørgsel er simpelt opbygget med en b-landing af interaktionsformerne menu og skemaudfyldelse. Fordelen ved men-uformen er, at det kræver færre indtastninger og tiden for indlærning er kort.Menupunkterne bruges her til at organisere de forskellige aktiviteter. Skemaud-fyldelsen bruges ofte til indlæsning af data struktureret som formular eller ske-ma. Denne interaktionsform kommer her til udtryk ved at der i interaktionsele-mentet kan indtastes/vælges dato. Skema-udfyldelsen giver et forenklet indtast-ning, men kræver at brugeren får forståelse for feltnavne og indtastningsforme.Det fysiske design af interaktionselementet Reservationsforespørgsel er angivetpå [�gur 15.2]. Med et begrænset valg af muligheder på selve skærmbilledet, er

Figur 15.2: Reservations- og aktivitetsforespørgsel

det simpelt opbygget, da det kun er de mest nødvendige menupunkter, der ermedtaget. Menuknapperne er store (mindst 2cm x 2cm) for bedre at give pladstil �ngertryk, dette går igen i alle de andre interaktionselementers fysiske design.Jvf. gestaltlovene er knapperne for de forskellige aktiviteter sammenfattet i engruppering, så det opfattes som sammenhørende og nedenunder er datafeltetplaceret.

Dette interaktionselement vil være en af de hyppigst anvendte i systemet. Detbliver anvendt under brugsmønstret Opret reservation, hvor en kunde ønsker atforetage en reservation, eller når der søges efter om der er en ledig ressource påen aktivitet på en bestemt dato og tid. Interaktionselementet refererer også tilaktivitetsreservationen, hvor en kunde kommer ind i centeret og ønsker at spilleher og nu.

Kalender

Skærmbilledet for kalender se [�gur 15.3]. har ligeledes med det forrige interak-tionselement interaktionsformene menu og skemaudfyldelse. Layoutet er konsis-tent hele vejen gennem systemet, så dette interaktionselement har som de andreden samme baggrundsfarve og de forskellige menuknapper har ens farve alt efterhvilken funktionalitet de repræsenterer. Mulighederne for at vælge mellem hvor-dan man kan indtaste værdier på en touchscreen er begrænset, da det i forvejenkan være svært at lave det således at brugere har let ved at overskue det. Nogle

78


af de optimale interaktionsformer er at lade brugeren benytte sig af forudde-�nerede værdier ved gentagne tryk på knapper (dato frem, dato tilbage). Vihar valgt at kombinere dette i forbindelse med datovalg, således brugeren bådeselv kan taste dato-værdier ind eller trykke på en knap og �ytte en dato fremeller tilbage. Dette interaktionselement er det primære fokusområde i systemet

Figur 15.3: Reservations oversigt

og bliver anvendt via mange brugsmønstre, nogle af disse er reservationsre-lateret hvor reservationer oprettes, redigeres eller slettes, mens andre kan værekunderelateret i den forstand, at der oprettes en ny eller indtastes yderligereinformationer omkring en kunde. Igen kan man via kalenderen igangsætte elleroprette en ny reservation.

Indtast personoplysninger

Til Indtast personoplysninger se [�gur 15.4]. er der benyttet interaktionsformenskemaudfyldelse. På skærmen vil der være otte kundeoplysningsrelateret punk-ter, der skal udfyldes. Såfremt der i forevejen er blevet indtastet informationerom kunden, vil dette også fremgå af skærmbilledet. Dette interaktionselement

Figur 15.4: Indtast personoplysninger

anvendes i forbindelse med oprettelse af en ny kunde eller til at redigere o-plysninger om en kunde.

79


Figur 15.5: Klarmeld og fejlmeld

Resourcebrowcer

I dette interaktionselement se [�gur 15.5]. bruges menu-formen. Skærmbilledet erstort set dækket af en tabel, der angiver en ressources tilstand, nummer, antalpladser og under hvilken aktivitet ressourcen hører under. Under tabellen ermenuknapperne placeret. Jf. gestaltlovene er knapperne delt op for at signalereat funktionerne mellem disse grupper adskiller sig markant fra hinanden. Detteinteraktionselement anvendes kun under brugsmønstre relateret til ressourcernesfysiske tilstande. Dette er for eksempel at slette en defekt ressource og opretteen ny i stedet.

15.3.2 Anvendelse af SAP-teori

Der er �ere brugbarhedsteorier der ligger til grund for design af brugergrænse-�aden. Brugergrænse�aden skal være brugbar med en touchscreeen, og i et travltbarmiljø. Anvendelsen af en touchscreen bevirker at vi ikke helt kan anvendede retningslinjer for design, der normalt knyttes til applikationer der køres påen almindelig skærm. Derfor tager vi udgangspunkt i SAPs guidelines, når videsigner reservationssystemets grænse�ade. I det følgende er angivet nogle afde dele af SAP's retningslinjer og regler, som vi har valgt at medtage i voresovervejelser under opbygningen af design på brugergrænse�aden. Nogle af ret-ningslinjerne har vi dog tilpasset, så de bedre passer til vores reservationssystem.

Som noget af det første vælger vi at anvende en højere opløsning til skærmen.Vi har valgt en opløsning på 1024*768, som vi mener, vil egne sig bedre til enstor touchscreen på 19 tommer. Skærmens baggrundsfarve bliver ren hvid og u-den mønstre. Selvom et let mønstret baggrund er god til at fastholde brugerensfokus på skærmet, er der risiko for at det kan blive for meget, idet vi anvenderfarvede knapper (mere herom senere), derfor vælger vi at undlade det.

De runde knapper er større end 2*2cm og på en knap, der skal trykkes på for atkomme videre i systemet, vil det kunne ses at den er blevet trykket ind, mensman trykker på den.

80


Til multiple selektion har vi valgt at gøre brug af både checkbokse og knap-per der kan markeres. Selve markeringen vises ved at knappens over�adefarvebliver ændret til dens komplementære farve (blå/orange), så snart den er blevetmarkeret. Der vil ikke være multiple vinduer og der vil ikke kunne scrolles iselve skærmbilledet, men i funktioner som kalenderoversigten, er det direktenødvendigt, at der er mulighed for scrolling.

Farvevalg

Brugergrænsen�aden skal være brugbar med en touchscreen og i et travlt barmiljø,dette betyder at brugeren skal kunne genkende de forskellige interaktionsele-menter klart og tydeligt, og det skal stå klar hvilken funktion de udfører.

Et af midlerne til at opnå denne klarhed er ved at benytte farver. Vi gør merepræcis brug af kulturelt bestemte farvekoder og udnytter derved farvegenkende-ligheden. Det er dog vigtigt at sikre at brugen af kulturelt bestemte farvekoderharmonerer med de kulturelt bestemte værdier. Vi vil prøve at opnå en bestemtreaktion fra brugeren, ved at lade den enkelte knaps farve associere til knappenstiltænkte funktionalitet. Til det går �re farver igen i hele den gra�ske bruger-grænse�ade. Det er rød, grøn, orange og blå. De tre første farver er bl.a. valgtfor deres symbolik fra tra�klys.

Jf. farveteorien se [�gur 15.6], har vi tildelt den røde farve til funktionerne Slet,Nej og Log af. De har fået den røde farve, fordi det kulturelt har fået givetadvarselsværdien. Hvis Slet-knappen i stedet var grøn, ville det forvirre mereend det ville hjælpe brugeren, fordi grøn kulturelt har en modsat værdi af det,den røde farve, repræsenterer. Opret, Godkend og Ja-knapperne får den grønnefarve, mens tilbage-knappen bliver repræsenteret af orange1. Som følge af de tre

Figur 15.6: Forkert og rigtig brug af kulturelle farveværdiger

farvers betydning vil rød, orange og grøn kun optræde på de valgte knapper.De andre knapper vil få andre farver for ikke at overføre lyssignalets farvekoderover på dem, samtidig skal vi passe på med at vi ikke skaber et cirkus-agtigtindtryk med for mange stærke farver. Derfor vil de andre knapper være farvetblå.

Farven blå er valgt, fordi den kan blive anvendt på en stor plads uden at virke formeget og fordi undersøgelser har vist at den blå farve har nogle gode virkningersom at virke afslappende og dæmpe blodtrykket jf. farveteorien. Selvom virknin-gen af den blå farve i dette tilfælde måske ikke vil være tydeligt, kan det alligevelvære nyttig at anvende den til vores system, der, jf. systemde�nitionen, skal an-vendes i et travlt bar-miljø. Derfor bruger vi også den blå farve til skriftenudover knapperne. Endvidere er blå kombineret med den hvide baggrund en

1På den vedlagte CD ligger en PDF hvor billderne kan ses i farver

81


god kontrast. Til fejlmeddelelser har vi brugt den røde farve, der signalerer atder er noget forkert og at brugeren skal være opmærksom på det. som farvernesbetydning bliver indøvet, bliver det også en ubevidst handling hver gang mantrykker på knapperne og brugeren vil efterhånden ubevidst vide at det er denrøde knap, der skal trykkes på for at slette og den orange knap går et trin tilbagei programmet.

Ikoner

Ikoner er et andet middel til at opnå en brugergrænse�ade der giver et hur-tigt overblik. I �ere tilfælde er farver ikke det bedste til at di�erentiere mellemforskellige knappers funktioner. Et eksempel er når knapper har funktioner, derligner hinanden, som f.eks. valg af forskellige aktiviteter i vores system. Her erdet oplagt at benytte ikoner til at symbolisere disse aktiviteter. Hjerne opfatterjo billeder hurtigere end en tekst, derfor vil ikoner give god mulighed for atbrugerne kan a�æse valgmulighederne hurtigt. Der er dog nogle krav til disseikoner, de skal være så enkle som muligt, så hjernen ikke bruger unødvendig tidtil at analysere dem, men komplicerede nok til at man ikke misforstår betyd-ningen af dem.På [�gur 15.7] ses et eksempel på ikoner.

Figur 15.7: Oversigtsbillede med ikoner for ressourcerne

15.3.3 Gestaltlovene og konsistens

I udvikling af brugergrænse�aden har gestaltlovene også haft en betydning.Nogle af de mest brugte er nærhedsloven og lukkethedsloven, hvor betydendekomponenter, der har en eller anden sammenhæng, hhv. placeres tæt og grup-peres inde i rammer. Se eksempel på [�gur 15.8]. Skærmbillederne får et enkeltog konsistens layout med udgangspunkt i gestaltlovene, her benyttes som nævntbåde placeringen af elementerne og deres farver til at fremhæve om elementerneer sammenhørende eller ej. Konsistens er vigtig både for de enkelte skærmbilled-er og igennem hele brugergrænse�aden. Det burde være med til at lette arbejdetfor brugere af systemet og gøre det mindre vanskeligt for dem at �nde rundt isystemet og derved undgå problemer med at få udført deres arbejdsopgave, forsystemet er også henvendt til brugere, der er novicer indenfor brug af IT, jf.systemde�nitionen.

Figur 15.8: Eksempel på knapplacering efter gestaltlovene

82

Del IV

Implementeringsdokument

83

Kapitel 16

Implementering

Som tidligere nævnt er vores system udviklet i programmeringssproget C#. Idette dokument, vil vi nærmere dokumentere de vigtigste, ikke-trivielle dele afkoden.

16.1 Windows Forms

Vores program består af i alt 12 Windows Forms, som der ses en illustration af på[�gur16.1]. Den første form, som brugeren bliver introduceret for er loginformen,hvor brugeren skal logge sig ind i systemet. Dernæst bliver han/hun introducerettil en menuform, med mulighed for at komme til de andre funktioner/mulighederi systemet. Ud over de 12 deciderede forms, har vi yderligere lavet en rækkeMessageBox'e, som også er opbygget ved hjælp af Windows Forms, og lavetsom custom controllers hvilket bliver beskrevet senere i dette kapitel.

Figur 16.1: Forms i systemet.

84


16.2 Custom controllers

Da vi har valgt at udvikle et stykke software, som skal bruges i forbindelse meden touchscreen, er det, jævnfør fokusområdeafsnittet, nødvendigt at tage højdefor en række ting, når det kommer til designet af den gra�ske brugergrænse-�ade. For at kunne anvende teorien for design til touchscreen, har vi valgt atlave en række UserControllers til brug i vores program. Disse controllere er bl.a.brugt til at lave knapper og messageboxe, som er bedre egnet til touchscreenend standard Windows-elementer.

Vi har valgt at lave en UserControl, som lader os lave store knapper, som ernemme at få øje på og ramme, præcis om teorien foreskriver. På den måde sikresdet, at knapperne har samme størrelse uanset hvor i programmet de bruges. Tra-ditionelle knapper kunne godt have været brugt i vores system, da deres størrelsekan ændres. Det er dog sværere at ændre deres udseende, og derfor valgte vi atlave vores egen knap, som passede bedre ind i vores gra�ske design.

Ud over en traditionel knap valgt vi også at lave en knap som fungerer som encheckbox. Det vil sige en knap som forbliver markeret efter et tryk. Dette sketeligeledes for at sikre at disse knapper var lette at bruge på en touchscreen. Forat gøre det tydeligt om knappen er valgt eller ej, er der valgt farver med storkontrast til at markere om en knap er aktiv.

Vi har desuden valgt at lave en række UserControllers som lader os lave message-boxe, som er bedre egnet til brug på touchscreen end de traditionelle Windows-messageboxe. Vores egne messageboxe indeholder større knapper og større tekstend de traditionelle Windows-boxe. Dette skal være med til at gavne vores sys-tems brugbarhed på en touchscreen, da disse messageboxe er væsentligt lettereat interagere med end dem man normalt �nder i Windows-applikationer.

16.3 Dokumentation

Dokumentationen af koden er fremstillet ved hjælp af programmet Doxygen,som genererer dokumentation ud fra XML-kommentarer i koden. Doxygen-dokumentationen indeholder beskrivelser af ikke-trivielle klasser og dertilhørenderelevante metoder. Ved hjælp af denne dokumentation, er det muligt at få etoverblik over hvad de enkelte klasser og metoder præcist gør.

Dokumentationen vil være præsenteret i form af et HTML-dokument, som givermulighed for let at navigere rundt mellem de enkelte dele af dokumentationen.Dokumentationen indeholder krydsreferencer til programmets kildekode, såledesat det er muligt let at �nde den aktuelle klasse/metode i kildekoden. Koden erdokumenteret på dansk, men der vil i Doxygen-dokumentet være engelske kom-mentarer, det skyldes at Visual Studio genererer kommentarer i udvalgte deleaf koden, og disse kommentarer er på engelsk. Doxygen-dokumentationen kan�ndes sammen med programmet på den vedlagte CD-ROM.

85


16.4 DayView klasserne

DayView-klasserne er en række klasser, som bruges til at tegne selve kalenderen.Vi har ikke selv kodet disse klasser fra bunden, men derimod fundet et åbentkalenderprojekt på codeproject.com, som vi har modi�ceret betydeligt til atfungere i reservationssystemet. Der er lavet om i så godt som samtlige metoder,dog er mange af tegnemetoderne genbrugt.

Udover at tegne en kalender, giver disse klasser også mulighed for at markeretidsintervaller bestående af halve timer (timeslots) og det markerede tidsintervalkan så sendes videre, så der kan oprettes en egentlig aftale.

Når en aftale er blevet gemt bliver den tegnet ind i kalenderen, og aftaleboksenkan gøres større og mindre, samt man kan ved at klikke på aftalen, ændre iaftaleteksten.

16.5 Persitens

Alle objekter i model laget skal gemmes også når programmet ikke kører. Dettekræver persistensfunktionalitet i programmet. I dette projekt er dette løst ved atgemme data direkte i �l-systemet. Objekter skal gøres klar til at blive gemt, enmåde at gøre det på er vha. serialization. Dette er en teknik som gør det muligtat sende et objekt som en stream, altså en streng af bits. C# har understøttelsefor dette. Den grundliggende måde at klargøre en klasse til serialization er attilføje attributten [Serializable()] til de klasser som skal serialiseres. Objektetkan derefter sendes som en stream, f.eks. over en netværksforbindelse eller tilen �l. De klasser der serialiseres er dem, der ikke er kontainer klasser, dette ergjort for at undgå tvivlstilfælde om data er gemt eller om det er det nyeste datader er i �lsystemet. Dette forklares bedst med et eksempel. Customer objektergemmes i CustomerList, persitensfunktionaliteten er programmeret i Customerklassen og ikke CustomerList. Dette betyder at man bekymringsløst kan �ytteCustomerObjekter rundt i alle lag af programmet. Brugergrænse�aden sætterog henter attributter direkte på en Costumer objekt. Ulempen ved dette er, atnår CustomerList ikke gemmes, skal klassen have funktionalitet til at hente alleCustomer objekter fra persitenslaget og lægge dem ind i sin interne liste. Dettegælder alle container klasser.

16.6 Singleton-klasser

Mange klasser i programmet er implementeret i efter singleton-mønster, for atsikre at der kun bliver oprettet en instans af klassen. Et eksempel på dette erklasserne PersonId og ResourceId, som bruges til at generere unikke id'er til Cus-tomer, Sta� og Ressource objekter. Id'erne bruges til at identi�cere de forskelligeobjekter, derfor er det vigtig at to objekter får samme id. Id klasserne har dogen lille afvigelse i forholde til det normale singleton-mønster. For id klasserne erdet vigtigt at der heller ikke oprettes nye instanser, selv hvis programmet harværet slukket. Det er løst ved at instance() metoden ud over at kontrollere, omder allerede �ndes en instans af den (via uniqueInstance variable), også kon-trollerer om der allerede er gemt en instans i �lsystemet, som bruges hvis det er

86


tilfældet.

Ud over id klasserne er alle klasser i funktionslaget (FunCenter.Ctrl namspace),som f.eks. PersonCtrl og ResourceCtrl, og kontainer klasserne også implementeretsom singleton.

16.7 Kodeorganisering

Koden er organiseret således i disse namespaces under FunCenter, og tilsvarendefoldere i MS Visual Studie solution. Desuden er stortset alle klasser organisereti en �l for hver klasse.

FunCenter.Controllers

Custom kontroller som f.eks. CusttomMessageBox.

FunCenter.Ctrl

Klasser der tilhøre funktions laget, som PersonCtrl

FunCenter.Model

Klasser tilhørende model-laget, f.eks. Customer og Sta�List.

FunCenter.Test

Nunit tests navgivet som "klassen de tester"+Test f.eks. ResourceTest.

FunCenter

Klasser der ikke passer ind i den eksisterende strukturer, f.eks. klassen med mainmetoden og Id klasserne.

87

Del V

Test- og evalueringsdokument

88


Dette test- og evalueringsdokument, dokumenterer de forskellige tests som erforetaget i projektperioden. Vi har foretaget os 5 tests, hvor de 2 første tests blevforetaget i forhold til vores første og andet review i samarbejde med vejlederog reviewer. De resterende 3 test var foretaget senere i projektet. Der blevforetaget en heuristisk inspektion, unit - program test og til sidst afslutningsvisen brugbarhedstest af systemet.

1.review

Første review blev foretaget den torsdag den 11.oktober 2007, hvor vejleder ogreviewer så på analysedokumentet og gav feedback på indholdet af dokumentet,samt eventuelle rettelser og ændringer som skulle laves før vi kunne gå videre iprojektet. Af de ændringer som der blev påpeget under reviewet, var de primæreændringer i dokumentet herefter:

• Ændring af beskrivelsen af problem- og anvendelsesområdet.

• Forbedret hændelsestabel med markeringer af (+/*).

• Ændring af klassediagram.

• Nyt brugsmønster som beskriver hele systemet.

• Bedre sammenhæng imellem aktørtabel og brugsmønstre.

• Navigationsdiagrammet beskrives som eksempel på prototype.

• Ændring i aktørtabel.

2.review

Andet review blev foretaget den torsdag den 15. november 2007, hvor vejleder ogreviewer så på designdokumentet og gav feedback på indholdet af dokumentet,samt eventuelle rettelser og ændringer. Af de ændringer som blev påpeget underreviewet, var de primære ændringer i dokumentet herefter:

• Ændring af klassediagram.

• Sletning og rettelse af forskellige brugmønstre.

• Konsistens-rettelse i forhold til analysedokumentet

• Rettelse af sekvensdiagrammer i forhold til brugsmønstrene.

Heuristisk inspektion

Den heuristiske inspektion blev foretaget midt i udviklingen af systemet, af5 eksperter. Testen tog udgangspunkt i Jakob Nielsen- og Alistair Sutcli�escheckliste i forhold til brugbarhed, både funktionelt som æstetisk design. Teoriensom lå til grund for inspektionen beskrives i dokumentet, samt de resultater ogden evaluering der blev tager dernæst er alt beskrevet i et senere kapitel.

89


Programtest

Vi har foretaget en programtest af de vigtigste controllere i vores reservation-ssystem, som er AgreementControlleren og ResourceControlleren, dertil deressubklasser. Grunden til valget af disse controllers er på grund af at det er vigtigtat sikre sig at en aftale oprettes på det rigtige tidspunkt, end at få fat i de rigtigekundeoplysninger mv. Testen blev foretaget lige før vi endte vores udviklingsfaseog gjorde klar til brugbarhedstesten.

Brugbarhedstest

Eftersom vi havde færdigudviklet reservationssystemet, foretog vi den tirsdagd.11. december, en brugbarhedstest, hvor vi brugte to testpersoner til at testesystemet både fra an administrativ som en brugermæssig tilgang. Vi brugte ialt to testpersoner og de 2 tests i alt 2 timer. Testplan, resultater og evaluering�ndes alt sammen i dette dokument.

90

Kapitel 17

Heuristisk inspektion

Heuristisk inspektion er en evaluering brugt til at foretage brugbarhedsinspek-tion udviklet af forskellige forskere indenfor brugbarhed som Jakob Nielsen, RolfMölich, Alistair Sutcli� og mange andre.Fremgangsmetoden er at en række eksperter vurderer et IT-system på baggrundaf et sæt brugbarhedskriterier. Metoden er en særlig tids- og ressourceøkonomiskmetode til at afsløre brugbarhedsproblemer i et brugerinterface, og bygger oppå de værende teorier om brugbarhed samt empiribaserede principper for brug-barhed. Med andre ord er heuristisk inspektion designet ud fra en analyse aftypiske brugbarhedsproblemer, tendenser og funderet i de gængse teorier ombrugbarhed i IT-systemer.

17.1 Teorien bag brugbarhed

For at danne et grundlag for i det hele taget at evaluere brugbarhed og lokalis-ere et brugbarhedsproblem, behandles det teoretiske aspekt for hvad brugbarheder.ISO-organisationen har udviklet over 15.000 internationale standarder på dettekniske område og er paraply-organisation for 157 nationale standardiseringsin-stitutter i medlemslandene[17]. I én af deres standarder (9241-11) de�neres brug-barhed på denne måde:

'Den e�ekt, e�ektivitet og tilfredsstillelse med hvilken speci�cerede brugere kanopnå mål i et givent miljø'[18].

E�ekten karakteriseres som brugerens evne til at løse en opgave i det givnemiljø. E�ektiviteten svarer til den tid, det tager for brugeren at opnå sit mål.Tilfredsstillelse er et subjektivt begreb, som afslører hvor godt systemet opfylderbrugerens behov og forventninger.Rolf Mölich er civilingeniør og har arbejdet med brugervenlighed siden 1984.Han har de�neret brugbarhed på følgende måde:

'Umiddelbart at kunne bruge et system og løse sin opgave tilfredsstillende udenundervisning eller brug af dokumentation'1. Ud fra denne de�nition af brug-

1VIT forelæsning af Janne Jul Jensen, 2006

91


barhed kan man omvendt de�nere et brugbarhedsproblem, som en situationhvor: Brugeren forhindres eller sinkes i at realisere hensigten/målet med at an-vende systemet. Forhindringen er oplevet af en konkret bruger. Rolf Mölich ogJakob Nielsen, har begge opstillet nogle kriterier for hvad brugbarhed er. Dogligner de meget hinanden og dette ses herunder.

Rolf Molich

• Let at lære.

• Let at huske.

• E�ektivt at bruge.

• Forståeligt.

• Tilfredsstillende at bruge.

Jakob Nielsen

• Easy to learn.

• Easy to remember.

• E�cient to use.

• Few errors.

• Subjectively pleasing.

Begge de�nitioner / grundbegrebspakker er de grundlæggende retningslinier forhvilke egenskaber et brugervenligt system skal besidde, ifølge Mölich og Nielsen.

92


17.2 Metode - opstilling af heuristika

Brugbarhedskriterierne også kaldet heuristika kan varieres fra system til systemalt efter hvilke dele af systemet man vil lægge særlig vægt på. F.eks. ville en testaf en online-community sandsynligvis kræve helt andre set af heuristikaer enden test af en mobiltelefons brugergrænse�ade, hvor f.eks. let tilgængelighed ofteer det betydningsbærende. De oprindelige heuristika bygger på Jakob Nielsenscheckliste2, og knyttede sig ikke til en bestemt platform eller medie. Der ersiden blevet udviklet en række forskellige andre sæt heuristika, som enten tagersit afsæt i Jakob Nielsens heuristika, eller knytter sig til viden/research fraarbejdet med den aktuelle teknologi. På grund af heuristikkens meget praktiskeorientering er der imidlertid intet problem i at blande heuristikaer fra forskelligeliste. Vi har valgt at benytte os af dette og ud fra Jakob Nielsens og AlistairSutcli�es checklister udarbejdet vores egen checkliste i forhold til inspektionenaf vores reservationssystem.

17.3 Checkliste

Jakob Nielsens checkliste

Grunden til at vi inddrager Jakob Nielsens checkliste, er at vores medie er en IT-reservationssystem, vis vigtige opgave er at udføre reservationer og håndteringaf et funcenters ressourcer mv. Systemet servicerer personalet i centeret til atudføre lette, hurtige reservationer i et ellers travlt barmiljø, hvor multi-taskinger en vigtig kompetence. Der vil være en række informationer i systemet sommedarbejderne skal kunne håndtere, hvorfor det er vigtigt at informationerneog tilgangen til informationerne er indlysende, hvilket er et af Jakob Nielsenschecklistes hovedfokuseringer.Som nævnt tidligere, har vi i udviklingen af reservationssystemet, fokuseret påbrugbarheden, og dermed forventer vi at der bliver set bort fra teknisk-relateredefejl i systemet, og derfor har vi sammensmeltet, de to heuristika der omhandlerfejl på systemet.

Dette giver os følgende 9 heuristika som udgangspunkt.

• Feedback og respons på brugerens handlinger.

Systemet bør altid sørge for feedback til brugeren, om hvad det foretagereller har foretaget sig.

• Sammenhæng mellem systemet og den virkelige verden.

Systemet bør tale brugerens sprog, med ord, fraser og koncepter sombrugeren er fortrolig med, frem for system-relaterede faglige termer. Somi den virkelige verden skal information fremstilles i en naturlig og logiskorden.

• Brugerkontrol og frihed. Brugere vælger ofte ved en fejltagelse en funk-tion, og har derfor brug for en tydelig 'nødudgang', så han kan forlade den

2Ten Usability Heuristics: http://www.useit.com/papers/heuristic/heuristic_list.html

93


uønskede tilstand, uden at skulle igennem en længere dialog. Dette kanf.eks. understøttes ved 'fortryd' og 'gentag' funktioner.

• Konsistens og standarder.

En bestemt systemhandling, bør altid kunne opnås af den samme bestem-te brugerhandling. Der bør ikke være anledning til tvivl om forskellige ord,situationer eller handlinger betyder det samme. Følg platformens konven-tioner.

• Genkendelse frem for genkaldelse.

A�ast brugerens hukommelse ved at gøre objekter, handlinger og mu-ligheder synlige. Brugeren skal ikke være nødt til at huske information fraen side til en anden. Instruktioner til systemet skal være synlige eller lettilgængelige når der er brug for det.

• Fleksibilitet og e�ektivitet.

Det skal være nemt at komme til den ønskede information, og opgaver skalkunne løses intuitivt, hurtigt af både erfarne og uerfarne brugere

• Æstetisk og minimalistisk design.

Systemet skal ikke indeholde irrelevant eller sjældent brugbart informa-tion. Al unødvendig information må betragtes som en konkurrent til denrelevante information, og mindsker dermed dennes relative synlighed.

• Giv gode fejlmeddelelser og forebyg fejl.

Gode fejlmeddelelser er forsvarende, præcise og konstruktive. Forsvarendefejlmeddelelser placerer ansvaret på systemet, ikke brugeren. Præcise ogkonstruktive fejlmeddelelser er eksakte i forhold til angivelse af fejlår-sagen, og kommer med meningsfulde forslag til udbedring af fejlen. Fe-jlmeddelelser skal ske i et normalt sprog og i ikke koder.

• Hjælp og dokumentation.

Gør hjælp og dokumentation tilgængelig. Denne information skal være letat søge i, fokuseret på brugerens opgaver, kort, konkret og 'step-by-step'-orienteret.

Alistair Sutcli�es checkliste.

Det er indlysende at andre medier går ind og påvirker os, såsom internetmedi-et som er en konkurrencepræget kommunikationskanal, hvor man antager, ellerbør antage at brugeren er kritisk, utålmodig og umiddelbart i stand til at af-bryde, skifte eller fravælge en kommunikationsstrøm fra en given afsender, og detsamme sker derfor i selv systemer som IT-systemer uden internetopkobling ogforbindelse til andre computere i et mindre netværk. Der spiller mange forskel-lige parametre ind i evalueringen af et reservationssystem til et funcenter, endblot de kriterier for god brugbarhed af Jakob Nielsen.

94


'If you cannot attract a user to stay on a website, it doesn't matter how welldesigned operational usability may be[13][s. 183-190].

Ovenstående citat understreger vigtigheden af at fange brugerens opmærksomhedog interesse. Citatet stammer fra en artikel fra 2001 af Alistair Sutcli�e, der op-stiller 11 heuristika for et IT-systems attraktivitet. Fælles for disse heuristika er,at de opfordrer til, gennem dels lingvistiske og primært gra�ske virkemidler, atmotivere brugeren til at fastholde fokus på den enkelte side eller det pågældendesystem. Det vil ikke være hensigtsmæssigt at benytte alle 11 heuristika i kom-bination med Jakob Nielsens 10. Selvom de �este er relevante i relation til detreservationssystem, ønsker vi stadig at holde fokus på Jakob Nielsens heuristika,der tjener til vurdering af brugbarhed relateret til opgaveløsning. Et tillæg på11 heuristika ville imidlertid skabe uoverskuelighed og uligevægt i forhold tilevalueringssituationen. Derfor har vi valgt at fokusere på tre heuristika, hvorden tredje er et sammenkog af to nært beslægtede heuristika.Herunder ses de frit oversat til dansk.

• Identitet og brand.

Gør den bagvedliggende organisations identitet synlig på en konsistentmåde ved hjælp af ord og billeder/logoer.

• Velovervejet brug af farver.

Farvebrugen bør være afbalanceret der bør ikke bruges mere end 2-3 mæt-tede/klare farver. Baggrunden bør være farveløs eller bestå af nedtonedefarver/pastelfarver.

• Symmetri, stil og konsistens.

Det visuelle layout bør være symmetrisk forstået sådan at man kan foldedesignet på midten og se højre og venstre sides tilnærmelsesvise match.Bløde former bidrager til en tiltrækkende visuel stil, når disse er i kontrastmed rektangulære former. Designet skal være overordnet konsistent på helesiden.

Vi får altså en checkliste med 9 punkter omhandlende generel brugbarhed og 3punkter angående design og layout i forhold til attraktivitet, i alt 12 punktersom i det følgende vil danne rammen om vores heuristiske evaluering.

17.4 Deltagere

Til at afgøre hvor mange deltagere vi vil bruge til evalueringen, kan vi ligeledeshente hjælp fra Jakob Nielsen. I [�gur 17.1] ses en graf, som afspejler mængdenaf fundne fejl/problemer i forhold til antallet af evaluatorer.Som det måske kommer bag på nogen, stiger antallet af fundne fejl i takt medat antallet af evaluatorer stiger. Imidlertid kan det ses, at kurven �ader udved omkring 10 deltagere. Ved brug af én evaluator, afsløres ca. 33 procent affejl/problemer ved systemet. Ved to evaluatorer, �ndes 50 procent af de fundnefejl/problem. Fem evaluatorer �nder som regel 60 procent af fejlene, hvor 10personer magter at �nde 80 procent.

95


Figur 17.1: Fejlprocent i forhold til antal evaluatorer.

Selvom man selvfølgelig altid er interesseret i at opdage alle fejlene, har vi tilvores inspektion af vores reservationssystem, valgt at bruge 5 personer til testen,som et kompromis mellem �est muligt fundne fejl og et fornuftigt ressourcefor-brug. Vi har valgt selv at være evaluatorer, da vi gennem kurserne 'VIT' og'DIEB' på Aalborg Universitet[21] og læsning af dertil hørende materiale, harmodtaget relevant undervisning samt gennemført øvelse i heuristisk inspektion.

17.5 Undersøgelsesdesign

Fremgangsmåden til at �nde brugbarhedsproblemerne, har været relativt sim-pel. Ved at anvende den prototype af vores reservationssystem udviklet i C#,hvilket er det programmeringssprog vi benytter i projektet, har vi haft mulighedfor at sætte os i brugerens sted.Samtlige sider i systemet og funktionaliteten i reservationssystemet er herefterblevet studeret og evalueret. Når evaluatoren oplever et brugbarhedsproblem,altså et brud på de listede brugbarhedskriterier, nedskrives problemet i et skemainddelt med de 12 heuristika og nummereres med et fortløbende problemnum-mer. Fejlens placering angives i forhold til de hovedområder og sider, der er givethovedmenuen i reservationssystemet.

Efter evalueringens udfærdigelse er alle brugbarhedsproblemerne blevet sam-menskrevet, hvorefter en ny person har inddelt problemerne i forhold til alvorlighe-den bag hvert enkelt brugbarhedsproblem.Denne proces kaldes kritikalitetsvurdering (på engelsk: serverity rating), og kanifølge Jakob Nielsen ske gennem vægtningen af tre faktorer[14]:

• Frekvensen af de fundne problemer/fejl, altså hvor ofte de fundne proble-mer/fejl.

96


• Ind�ydelsen af de fundne problemer/fejl, altså hvor nemt eller svært af defundne fejl/problemer at løse dem, hvis det er muligt.

• Vedholdenheden af de fundne problemer/fejl, altså om man nemt kankomme forbi de fundne fejl/problemer, eller om de bliver ved med at ir-riterer brugeren.

Til denne vurdering bruges tal, det vil sige man giver en fejl/problem en karakterefter hvor slemt problemet er:

• 'Jeg ser ikke dette problem som noget problem overhovedet!'

• Kosmetisk problem, intet behov for rettelse med mindre der er tid til det.

• Mindre brugbarhedsproblem, dette problem bør have lille prioritet angåenderettelse.

• Større brugbarhedsproblem, dette problem bør have stor prioritet angåenderettelse.

• Brugbarhedskatastrofe, dette problem bør i alle tilfælde rettes.

En sådan inddeling kan hjælpe med til at undersøge, hvor alvorlige de fundnefejl/problemer er, og hvor producenten skal lægge sit fokus, når fejlene skalrettes. Vi har i vores færdige skema valgt at se bort fra karakteren nul. I stedeter disse emner blevet slettet fra skemaet med brugbarhedsproblemer.Som det sidste vil vi for hvert brugbarhedsproblem se på, hvad der rent tekniskskal til for at løse eller mindske brugbarhedsproblemet. Derfor skrives et løs-ningsforslag under de emner vi ser en umiddelbar løsning på.

17.6 Resultater

Den heuristiske inspektion efterlader os med en mængde brugbarhedsproblemer,der som nævnt bliver kategoriseret på to måder, som er i forhold til evaluerin-gens heuristikker og i forhold til vores vurdering af det enkelte problems alvor,altså hvor vigtigt det er,at en given fejl bliver rettet til. I [tabel 17.2], vil netopdisse to faktorer være omdrejningspunktet. Som det kan ses i skemaet oven-for, har den heuristiske evaluering afsløret 25 brugbarhedsproblemer, hvoraf 2problemer er fundet af to eller �ere evaluatorer. Fordelt på de forskellige kri-tikaliseringsniveuaer, ses at i altSom nævnt i metodeafsnittet er rapporterede problemer, der viste sig ikke atvære et problem blevet fjernet fra den samlede liste. Det drejer sig om ca. 10tilfælde. Fordelt på de forskellige kritikalitetsniveauer, ses at i alt 10 problemerer kosmetiske, 10 problemer er små, 5 er vurderet som værende store problemer,og ingen er nævnt som en katastrofalt problem i vores reservationssystem. Vivil dernæst tage hvert problem op og se på de løsningsmuligheder problemernekan løses / forbedres på.

17.7 Analyse og Vurdering

For at analysere og vurdere problemerne mere nøje, har vi taget hvert problemfor sig, set på problemet og givet et løsningsforslag dertil. Dog har vi pga. tids-

97


Figur 17.2: Resultatskema af heuristisk inspektion

mangel i projektforløbet ikke udført ændringer fra den heuristiske inspektion,dog redegjort for hvordan problemerne kunne ændres.

H1 - Feedback og respons på brugerens handlinger.

Beskrivelse: Rediger-knappen på søgesiden i systemet, er synlig før en påbeg-yndt søgning efter en kunde. Det vil sige, at man kan klikke på knappen, selvomman ej har fundet den bruger man ønsker at �nde oplysninger dertil.

Kategorisering: Kosmetisk problem.

Løsningsforslag: Problemet kan løses ved at lade knappen være usynlig førsøgningen er påtaget. En anden løsning kunne være af gråtone knappen, og fåden til at skifte farve idet, der er fundet en kunde i systemet.


Beskrivelse: På søgesiden, vises der stadig en fejlmeddelse eftersom kunden eroprettet i systemet.

Kategorisering: Mindre problem.

Løsningsforslag: Problemet kan løses ved at gøre fejlmeddelelsen usynlig efter-som den har oprettet en ny kunde.


Beskrivelse: Når man i systemet vælger at få sendt en mail omkring opret-telsen af en ny reservation, bliver man ikke bekræftet om at mailen er blevetsendt afsted, samt man bliver sendt tilbage til systemets kalender.

98



Løsningsforslag: Problemet kan løses ved at der laves et bekræftelsesvindue,som popper up idet systemet har sendt mailen afsted, samt at brugeren bliverautomatisk sendt tilbage til hovedmenuen.


Beskrivelse: Der er ingen som helst feedback på oprettelsen af en ressource isystemet.


Løsningsforslag: Problemet kan løses ved at der popper et vindue op, efter-som der er oprettet en ressource, som bekræfter oprettelsen af en ny ressourcei systemet.


Beskrivelse: Idet der skulle søges efter en kunde, under oprettelsen af en reser-vation, er det et problem at søgeknappen ligger lige over Opret kunde-knappen.

Kategorisering: Større problem.

Løsningsforslag: Problemet kan løses ved at �ytte knapperne længere væk,men samtidig med brug af gestalt-lovene.

H2- Sammenhæng mellem systemet og den virkelige verden

Beskrivelse: Forståelsesproblem over "ordet ressource", i forhold til bord, ellerbane.


Løsningsforslag: Problemet kan løses ved at �nde et mere fælles ord forbane/bord, eller kræves det mere eller mindre bedre forståelse af ordet "ressource".

H3 - Brugerkontrol og frihed.

Beskrivelse: Problem i kalenderen, med at man skal holde �ngeren på skærmenhele tiden for at vælge �ere timeslots.


Løsningsforslag: Problemet kunne løses hvis det ikke var muligt at klikkepå et timeslot af gangen og på den måde de så blev markeret.


Beskrivelse: Problem i valget om man vil printe eller man vil sende en mail tilkunden omkring oprettelsen af ny reservation. Der er ingen andre muligheder

99


for at komme videre i systemet. En låst pop-up.

Kategorisering: Mindre problem

Løsningsforslag: Problemet kan løses ved at tilføje en ekstra knap, som gørdet muligt at afslutte nyoprettelsen af reservationen uden at printe eller e-mailereservationsoplysningerne.


Beskrivelse: Mange vinduer i systemet skader overblikket.


Løsningsforslag: Løsningen kunne være at der skulle være mindre vinduermed mere information, eller at brugeren ikke ser skiftende imellem vinduerne.

H5 - Genkendelse fremfor genkaldelse.

Beskrivelse: Forvirring omkring hvad de forskellige vinduer bruges til.


Løsningsforslag: En løsning kunne være små beskriver, som fortæller om vin-duets funktion, eller en hjælp-knap, som der kan klikkes på for mere informa-tion. Dog kan sidstnævnte løsning betyde der bruges mere tid, og �ere "tryk"påskærmen.


Beskrivelse: Det er ikke altid helt klart hvor man er henne i systemet.


Løsningsforslag: Løsning på dette problem, at der opstilles indikatorer somviser hvor langt brugeren er henne i processen for at udføre en opgave. Det vilsige, der kunne være streger som lyse mere op end andre, eller tal som visteskridt for skridt. Eksempelvis ('2 ud af 3 trin').


Beskrivelse: Brug af samme farver på knappernes fællesfunktioner.


Løsningsforslag: Løsningen kunne være at der var lavet helt klare regler forde forskellige knappers farve i forhold til hvilken funktion de havde i systemet.

100


H6 - Fleksibilitet og e�ektivitet.

Beskrivelse: Det er et problem med alt for små scroll-bars til touch-screen.


Løsningsforslag: Der kan laves andre touch-screen scroll-bars, som scrolleraf sig selv, ved at glide �ngeren et lille stykke, og på samme måde stoppe detigen, ved at sætte �ngeren på igen[2].

H7 - Æstetik og minimalistisk design.

Beskrivelse: Problem med at sætte ressourcer aktive og deaktive. Checkboksener alt for lille.


Løsningsforslag: Det kan som løsning males to bokse, henholdsvis rød og grøn,som indikerer om ressourcen er aktiveret eller deaktiveret. Ved et enkelt klikskal brugeren dernæst bekræfte om valget af en eventuel de- eller aktivering afressourcen.

H7 - Fleksibilitet og e�ektivitet.

Beskrivelse: Eftersom der bliver klikket på opret reservation, forekommer deret vindue, hvor det brugeren muligt at afslutte reservationen, hvilket skaber m-isforståelse af en eventuel oprettelse af en ny reservation.


Løsningsforslag: Løsningsforslaget kunne være at der skulle vælges et andetordvalg i stedet for ordet Afslut, eftersom man netop af klikket på opret reser-vation.

H9 - Hjælp og dokumentation.

Beskrivelse: Det er ikke altid lige klart, hvad knapperne direkte betyder dateksten på dem er minimal.


Løsningsforslag: Løsningen kunne være større knapper, eller bedre grupperingaf knapperne. Tooltip, kan desværre ikke bruges i systemet, da vi har med entouch-screen at gøre.

H11 - Velovervejet brug af farver.

Beskrivelse: I tre af hovedmenuens punkter optræder knapfarverne grøn ogorange, dog ikke i søgevinduet, hvilket kan forvirre brugeren. Dog er der i søge-feltet mange blå knapper.

101



Løsningsforslag: Løsningen kunne være bedre brug af enkelte farver, samtbedre farvekombinatorik, såsom tra�klysfarverne og en grå, sort, end en blåfarve.


Beskrivelse: Knappen Slet i kalenderen er blå og knappen i ressourcelisten errød.


Løsningsforslag: Løsningen kan være at begge slet knapper skulle være rød,dog uden der skabes gruppering imellem en afslut/luk knap i systemet.


Beskrivelse: I tre af hovedmenuens punkter optræder knapfarverne grøn ogorange, dog ikke i søgevinduet, hvilket kan forvirre brugeren. Dog er der i søge-feltet mange blå knapper.


Løsningsforslag: Løsningen kunne være bedre brug af enkelte farver, samtbedre farvekombinatorik, såsom tra�klysfarverne og en grå, sort, end en blåfarve.

H12 - Symmetri, stil og konsistens.

Beskrivelse: Ressourcelisten og kalenderen har hver to forskellige stile i forholdtil designet, hvilket skaber problemer i forhold til symmetri og konsistens.


Løsningsforslag: Løsningen kan ske ved at lave begge vinduer efter en bestemtstil, og ikke to forskellige. Nok bedst med en moderne stil, da vi mest har medunge at gøre som slutbrugere af systemet.


Beskrivelse: Under afslutningen af reservationen er der 3 overskrifter mednæsten ens størrelse lige under hinanden.


Løsningsforslag: Løsningen kan være at der bør grupperes tekster alt efterhvilke som tilhører hvor på skærmen, samt at størrelserne bør justeres eftersomhvilken der er vigtigst.

102



Beskrivelse: Ressourcelisten og kalenderen har hver to forskellige stile i forholdtil designet, hvilket skaber problemer i forhold til symmetri og konsistens.


Løsningsforslag: Løsningen kan ske ved at lave begge vinduer efter en bestemtstil, og ikke to forskellige. Nok bedst med en moderne stil, da vi mest har medunge at gøre som slutbrugere af systemet.

17.8 Konklusion

Selvom de tre heuristika 1,5,11 og 12 står bag mange af den samlede prob-lemmængde, ses det ud fra analysen at også de andre heuristika rejser vigtigecentrale problemstillinger. Hvis vi skal se på en konklusion ud fra de forskelligeproblemer og deres vurdering kan man sige at de fejl som er fundet ikke på nogettidspunkt har været så kritiske at programmet ikke har været mulig at udføreopgaver derpå.

Når fejl ikke er fejlAt bringe personer, med så tæt tilknytning til projektet, som vi har gjort medos selv ind som evaluatorer indebærer selvfølgelig en potentiel fejlkilde. Da vigennemførte inspektionen, havde vi i forvejen stiftet bekendtskab med det sys-tem vi var igang med at opbygge og dermed kunne vi have en forudindtagetmening om systemet. Det er derfor vigtigt at vi forholder os professionelt tilvurderingen.

En anden usikkerhed, kan være hvordan man ser på evt. fejl og problemer. No-gen gange kan det være, man �nder en fejl, der viser sig at være en falsk alarm.Man drager for hurtige konklusioner. Bogen[19][s. 411] nævner, at det er sket,at eksperter har evalueret et system, som ifølge dem, har et vist et antal fejl. Daman senere undersøgte de fejl, viser det sig, at næsten halvdelen af de fundnefejl fra eksperternes side, rent faktisk ikke kunne betegnes som deciderede fejl.Denne e�ekt kan måske forklares ved tendensen at når du kigger efter fejl så�nder du også fejl. Eksperten bliver påvirket af den kontekst han sidder i, ogbegynder at se fejl i selv den mindste uregelmæssighed. I så fald vil denne fe-jlkilde sandsynligvis være temmelig udbredt i vores resultater, da alle deltagereop til inspektionen havde arbejdet kritisk med systemet i løbet af hele projekt-perioden.

103

Kapitel 18

Programtest

Programtest i dette projekt er foretaget løbende igennem udviklingsprocessen,som en del af selve udviklingen. Der fokuseres på de klasser og data typer somer de mest betydende. Der er især blevet fokuseret på de klasser og datatyper,der har betydning for at gemme aftaler, da disse har en særlig betydning forreservationssystemets pålidelighed i henhold til at udnytte centerets ressourcebedst muligt. Klasserne som testes, er fra model-laget: Customer, Sta�, Sta�Listog Ressource. I funktionslaget testes: PersonCtrl. Ikke alle klasser vil blive testetog det er der to grunde til, enten anser vi det for trivielt at udvikle tests til enklasse, og bruger i stedet energien andre steder, eller også er en klasse ikkefærdigudviklet til en test. Testene ligger på �ere lag i programmet, det betyderat når funktionslaget testes, bliver modellaget også testet.

18.1 Udarbejdelse testcases

Det er muligt at udarbejde testcases, før der er blevet programmeret væsentligtdele af systemet. Dette kan ske ved hjælp af klassediagrammer og deslige. Vihar dog vurderet at det vil være mest praktisk for os at vente til vi har fåetprogrammeret de klasser, som skal testes, før vi begynder at udarbejde testcases.Ved at vente til efter programmeringen er vi sikre på, at vi får mest muligt udaf vores testcases, da vi med større sikkerhed ved hvad det er, der skal testes.Dette sikrer, at der kan tages højde for eventuelle ændringer, der foretages iforbindelse med udviklingen.

18.2 Testværktøjer

Vi vil foretage tests af programmet med Nunit[1], da det er dette program vi harfået undervisning i, i OOP-forelæsningerne[15]. NUnit er er et såkaldt unit-testprogram, hvor enkelte dele af programmet testes seperat.

18.3 Blackbox- og Whitebox-testing

Vi har vurderet, at det i vores projekt vil være mest relevant at fokusere påBlackbox-testing. På grund af den begrænsede tid har vi vurderet, at det vil

104


være vigtigere at vores klasser fungerer korrekt, som er hvad Blackbox-testinggår ud på, fremfor at tjekke om der er risiko for, at en bestemt vej gennemprogrammet kan resultere i fejl (Whitebox). Naturligvis er det også vigtigt atsikre os, at der ikke er risiko for at en bestemt vej til en given funktion kanresultere i et fejlende program. Whitebox testing er meget omfattende, så vivalgte at lægge vores fokus andre steder i projektet.

18.4 Ansvar mellem klasserne

Ansvar mellem de forskellige klasser har betydning for udformning af de forskel-lige tests. Det er nemmest at vise med et eksempel. For oprettelse af kunder(Customer objekter), skal der sikres at der ikke oprettes kunder uden adresse,telefonnummer mv. Ansvaret for at dette ikke sker ligger i brugergrænse�adeni dette tilfælde, da brugergrænse�aden kan give direkte feedback til brugeren,som f.eks. at bede om at alle felter med kundeinformation skal udfyldes. Gen-nemgående programmerer vi ikke unødige checks ind i de forskellige klasser.Dette betyder, at PersonCtrl som står for at oprette Customer objekter ikketjekker, om det data den får ind, er rigtig. En unittest hvor et Customer objektbliver oprettet med tom data, vil altså ikke blive opfattet som en fejl i testen.Hvis der var fejl, vil de blive opfanget i testet af de forskellige forms i bruger-grænse�aden. Vi har dog valgt ikke at lave test i brugergrænse�adelaget medNunit af tids hensyn. Nunit kan ikke direkte bruges til dette, men der �ndesdog en udgivelse[8], der giver muligheden.

18.5 Anvendelse af Unit-test

Vi bruger unittest til at teste, hvorvidt det system vi har programmeret gør det,som vi har planlagt at det skulle. Udover unit-testing vil vi foretage brugbarhed-stest med brugere, for at teste om systemet er brugervenligt, som beskrivessenere i dette dokument.Vi har ligeledes foretaget en heuristisk inspektion af systemet, for at se om vi kan�nde og løse nogle af de brugbarhedsproblemer, som muligvis ville have væretfundet i en brugbarhedstest. Hvis det er muligt af afhjælpe problemer uden atinvolvere brugere er det selvfølgelig positivt. Samtidig er det uundværligt atforetage brugbarhedstest med brugere, da det giver potentiale for at �nde fejl,som ikke �ndes af et ekspertpanel.

Kildekoden til Nunit-testen �ndes i testfolderen på CD'en.

105

Kapitel 19

Brugbarhedstest

19.1 Formål og hovedspørgsmål

Formålet med evalueringen er at validationsteste reservationssystemet baseretpå en summativ og formativ fremgangsmåde. Hovedspørgsmålet til brugbarhed-stesten er derfor:

• Vi ønsker at teste og evaluere reservationssystemets e�ektivitet og påsamme tid se, om det er let at bruge i et travlt arbejdsmiljø. VI ønsker at�nde ud af om systemet er tidsmæssig økonomisk.

19.2 Metode

Testen er en såkaldt Instant Data Analyses (IDA) test, som er udviklet af JesperKjeldskov, Mikael B. Skov og Jan Stage. Gennem sidste års kursusgang i Vur-dering af IT-systemer (VIT) og gennemgåelse af brugbarhedseksperten JakobNielsens teori, fandt vi ud af, at tre er det optimale antal testpersoner for atopnå en kvalitativ brugbarhedstest af et givent system, men som følge af man-gel på ressourcetid, benytter vi os af to testdeltagere. Vi har valgt at skrive etmanuskript til de to deltagere for at sikre, at testen udføres på samme måde foralle. De materialer som testdeltageren får uddelt, er en samtykkeerklæring samtet brev til testpersonen som �ndes i appendiks 1 og 2. Vi har til testen valgtpersoner i samme aldersgruppe, idet systemet bliver brugt af en brugergruppei alderen 18-40 år. Før testen har vi foretaget et interview med hver af testper-sonerne, for at danne os et overblik over den pro�l vi skal teste. På testdagenankommer testpersonerne til testrummet. Her modtages de af testlederen, somforklarer vores ønske om at sikre et ens udgangspunkt for alle deltagere, ogat det som følge heraf vil foregå ret mekanisk. Herefter udleverer testlederenet brev til hver testperson, som de skal læse og forstå før testen igangsættes.Testen er en tænke-højt test, hvilket betyder at testpersonen skal fortælle, hvadhan/hun tænker imens han/hun udfører opgaverne. Analysedelen styres af enIDA-facilitator, der ikke er til stede under selve testen. En IDA-test muliggørat testet kan afvikles på en dag, og man skærer hele videoanalysen væk, oganalyserer lige efter afviklingen af testen.

106


19.3 Brugerpro�l og roller

I forhold til brugerpro�len er vores brugere af reservationssystemet medarbe-jdere med kendskab til IT i forhold til styresystemet Windows samt diversebasale Windows-programmer, såsom internetbrowser og tekstbehandlingssoft-ware.

Udover de testpersoner, som er med til at teste reservationssystemet vil der tiltesten af reservationssystemet være følgende fem rolletyper:

• Testleder

• Videooperatør

• Logger

• 2 x Observator

• IDA facilitator

Disse vil vi herunder give en dybere beskrivelse af:

Testleder

Det er testlederens ansvar at tage imod testpersonen og informere om hvad derskal ske, ligesom det til sidst er testlederen der laver en debrie�ng. Testlederenskal under hele testforløbet være til stede i testrummet til at guide testpersonen,og han har ansvaret for at brugbare data indsamles. Går testpersonen i stå i enopgave, er det testlederens opgave at få testpersonen på sporet igen.Ligeledes er det op til testlederen at vurdere, om testdeltageren er gået helt istå og derfor skal have udleveret den næste opgave. For at skabe det sammeudgangspunkt for alle testdeltagere, er der udarbejdet retningslinjer for hvor-dan testlederen skal henvende sig til testpersonen. Undervejs i testforløbet, kantestlederen spørge om følgende:

• Hvad tænker du?

• Hvad er din hensigt?

• Har du andre muligheder?

• Hvordan har du det lige nu?

• Har du brug for en pause?

Testelederen skriver noter under testen, som efterfølgende skal bruges i analysesessionen.

Videooperatør

Videooperatøren sørger for at videoovervågningen af testen kører. Dette inde-bærer bl.a. at skifte mellem de forskellige kameraer, således at den bedste kam-eravinkel opnås. Testlederen er den eneste der be�nder sig i samme rum somtest personen, så de resterende personer ser på de direkte video optagelser.

107


Logger

Loggeren skriver noter under testforløbet. Det noteres bl.a. hvilke fejl testper-sonen løber ind i. Det er dog ikke en detajleret oversigt over fejl. En overordnetlog over testen kommer senere, hvor der opstilles et skema over fejlene og deresprioriteter for hvor kritiske de er. Ofte kan der være mere end én logger for atvære sikker på at få så meget som overhovedet muligt med.

IDA facilitator

Faclitatoeren er ikke er tilstede under testen, Han opgave starter når testen skalevalueres, dette foregår lige efter testen. Det er hans opgave at styre evalueringsprocessen, og få en konstruktiv dialog til at køre mellem testlederen og loggeren.

Observator

De 2 observatorer har ingen opgaver i forbindelse med testen, men er med forat opnå en forståelse for en IDA test, som vi som studeren ikke har prøvet atafvikle før.

19.4 Test afvikling

Der fastligges opgaver som test-personen skal igennem, disse opgaver er fastlagtud fra brugsmønstere, ligger til grund for udviklingsprocessen af programmet.Det drejer sig om:

• Oprettelse af aftale.

• Ændring af aftale.

• Sletning af aftale.

Det at vi kun anvender to testdeltagere gør det muligt for os at koncentrere osfuldt ud om hver enkelt testdeltager, således at vi får mest muligt ud af testen.Flere deltagere havde givet mere feedback, men mange testpersoner vil også givefare for at de enkelte testpersoner får mindre fokus.

19.5 Evaluering

IDA facilitatoren, testlederen og loggeren starter evalueringen med en brain-stormingsproces på en time. Loggeren og testlederen nævner alle de usabitityproblemer de har logget, under denne proces benyttes udprint af screen shots,for at underbygge brainstormen. Facilitatorens opgave er at skrive alle proble-mer på en tavle og kategorisere dem i rangorden efter kosmetisk, alvorlig, kritiskog katastrofe. Når dette er gjort skrives en mindre rapport hvor hvert problembeskrive med en kort tekst, og et eventuelt løsningsforslag. De beskrivelser ogløsningsforslag til de fejl vi har fundet i vores test, er beskrevet i et senere afsnit.

108


19.6 Lokalitet og udstyr

Til testen, bruger vi en stand-alone PC-platform med tilhørende touch-screen.Testen bliver udført på AAU's usabilitylaboratorie. På [�gur 19.1] ses et billedefra laboratoriet. Til testen kommer testpersonen til at stå op, og teste systemet,for at opnå en mest realistisk billeder af hvordan det ville foregå i et funcenter.Derudover bliver der afspille musik i baggrunden, som der ville have være ifuncentret.

Figur 19.1: Billede fra usabilitylaboratoriet på Selma Lagerlöfs vej

19.7 Dataopsamling

Dataopsamling i en IDA-test består af logs fra testleder, logger, og hvad deefterfølgende kan huske. Testsessionen optages ikke på bånd, da videoen ikkeskal benyttes efterfølgende, men vi noterer hvad testpersonen oplever på com-puterskærmen. Derudover har vi valgt at teste om systemet er e�ektivt at brugeog på samme tid er brugervenligt.Til testen tager vi tid på, hvor lang tid det tager at udføre usecase-opgaverne.Det er vigtigt at huske på, at det ikke er testpersonen, men systemet der testes.Derfor kan vi komme ud for at det bliver nødvendigt at korrigere tidsresultatet,hvis en person generelt bare arbejder langsommere end en anden (f.eks. vedskrivning på computer). Hvis der opstår en situation, hvor testpersonen ikkekan komme videre, må vi vurdere om det er systemet der fejler, eller om derer andre forhold, der spiller ind. Efter at årsagen til brugerens frustration ellerforhindring er blevet fastslået, vil kategorisering blive relevant. Kategoriseringforetages gennem en vurdering af, hvor alvorligt problemet er for brugeren, forsenere hen at kunne lave en prioriteret liste af brugbarhedsproblemer. Man talerom �re kategorier, der svarer til alvorlighedsgraden: Kosmetisk, alvorlig, kritiskog katastrofe. En katastrofe vil sige, at det samme kritiske brugbarhedsproblemer oplevet af to eller �ere personer uafhængigt af hinanden. Tre faktorer spillerpå en særlig måde ind ved fastlæggelse af de tre andre kategorier. Tid, irrita-tion/irrationalitet og forventning.Vi vil altså se på hvilken indvirkning et brugbarhedsproblem har på tidsfor-bruget og e�ektiviteten af udførelsen af de forskellige use-cases.

109


19.8 Resultater

De problemer som vi er kommet frem til gennem IDA, fremgår herunder. Prob-lemerne er kategoriseret ud fra �re niveauer, nemlig:

• Kosmetisk: Et lille problem som ikke har betydning for udførelsen af enopgave, men alligevel generer en smule.

• Alvorligt: Et problem som sinker testpersonen i udførelsen af en opgave.Forsinkelsen er dog ikke voldsomt generende. Et alvorligt problem måmaksimalt forsinke en bruger 2 min. Afhængigt af opgavens karakter.

• Kritisk: Et kritisk problem er et problem som forsinker testpersonen ien sådan grad at det er generende. Det betyder typisk at testpersonenforsinkes mere end 2 minutter.

• Katastrofe: Et katastrofalt problem er et problem som forhindrer en test-person i at udføre en opgave.

På grund af tidspres har vi valgt ikke at foretage ændringer i systemet efterbrugbarhedstesten. Vi har i stedet angivet et eller �ere løsningsforslag til hvertproblem. Disse løsningsforslag er noget som ville kunne implementeres hvis tidentillod det.

19.8.1 Datovalgsproblem

Beskrivelse: Begge testpersoner oplevede problemer med at vælge et tidspunkti kalendervinduet. Det er for den ene testperson ikke umiddelbart klart at derskal trækkes en markering med �ngeren, og den anden indser ikke at der skalvælges et tidspunkt i kalenderen. Det skaber en del forvirring og forårsager enforsinkelse i processen.

Kategorisering: Alvorlig

Løsningsforslag: En løsning på dette problem ville være at gør det tydeligereat kalenderen skal bruges til at vælge et tidspunkt. Dette kunne for eksempelklares med forklarende overskrift. Derudover kunne det være en mulighed at gøredet muligt at indtaste klokkeslæt, da det eventuelt ville være mere intuitivt daman jo i forvejen kan indtaste en dato.

19.8.2 For lille scrollbar

Beskrivelse: Begge testpersoner har problemer med at bruge scrollbaren ikalenderen. Den er simpelthen for smal, og derfor svær at "få fat i"med �n-geren. Det kræver en smule tilvænning og forvirre og forsinker.


Løsningsforslag: Dette problem skal simpelthen løses ved at gøre scrollbarenbredere, således at den er bedre egnet til brug med en touch-screen.

110


19.8.3 Adresseforvirring

Beskrivelse: Begge testpersoner indtaster hele kundens adresse, inkl. Husnum-mer, i Gade-feltet. De opdager hurtigt at der �ndes et gadenr.-felt, og retterfejlen. Dette skaber ikke særlig forsinkelse.

Kategorisering: Kosmetisk

Løsningsforslag: Dette er et kosmetisk problem og kræver derfor ikke at derforetages væsentligt. Der er i høj grad tale om et tilvænningsspørgsmål.

19.8.4 Rabataftaleforvirring

Beskrivelse: Der opstår forvirring hos begge testpersoner da de kommer tilRabataftale, mens de er ved at oprette en kunde. Opgaven beskriver kundensrabataftale som "Ingen". Dette resulterer i at en testperson undlader at skrivenoget i feltet, mens den anden skriver "Ingen". Dette viser at konceptet meden rabataftale er uklart. Det forsinker ikke testpersonerne i nævneværdig grad,men det viser at det ikke umiddelbart er gennemskueligt hvad der kan skrives itekstfeltet.


Løsningsforslag: Dette problem kan løses ved, i stedet for at bruge en tekstbox,at have en drop-down-menu der indeholder et antal præde�nerede muligheder,således at der ikke er tvivl om hvad der kan og skal vælges.

19.8.5 Rettelse af tidspunkt

Beskrivelse: Hos begge testpersoner opstår der problemer da der er blevetangivet et forkert tidsinterval, under oprettelse af en reservation. Begge test-personer er i tvivl om hvordan det valgte tidsinterval kan ændres. De savner enredigerknap og er i tvivl om hvorvidt Tilbage-knappen vil slette de eksisterendeoplysninger. Dette skaber en del forvirring og forsinkelse for begge testpersoner.

Kategorisering: Kritisk

Læsningsforslag: Dette problem kan løses ved at indsætte en rediger-knap iforbindelse med tids- og datooplysningerne.

19.8.6 Knapforviring

Beskrivelse: Der opstår forvirring, hos begge testpersoner, da oprettelsen af enreservation skal gennemføres. Knapperne "Opret"og "Godkend"forvirre beggetestpersoner. Da Opret-knappen lige er blevet brugt i forbindelse med at opretteen bruger formår begge dog at gennemskue at det er Godkend-knappen den skalbruges.


Løsningsforslag: Problemet er svært at løse da det ikke rigtig er muligt at

111


placere knapperne anderledes på en fornuftig måde. Men da problemet er kos-metisk er det ikke så vigtigt at det bliver ordnet, da det sikkert er noget der vilblive løst med erfaring.

19.8.7 Problem med at vælge radiobuttons + textboxes

Beskrivelse: En testperson oplevede problemer med at vælge radiobuttons ogtekstfelter ved hjælp af touch-screen'en. Der var simpelthen så lidt plads at detvar svært at ramme med en �nger.


Løsningsforslag: Det aktive område omkring en radiobutton kan gøres størreså den bliver nemmere at ramme med en �nger. Ligeledes kan tekstbokse gørestørre så de er nemmere at ramme.

19.8.8 Aktiv/inaktiv

Beskrivelse: Begge testpersoner havde svært ved at bedømme hvorvidt enressource var aktiv eller inaktiv. I ressourcelisten er en ressources status mark-eret med en checkbox, som er let at overse når man arbejder ved en touchscreen.Dette problem sinkede især den ene af vores testpersoner, som forsøgte at ændrestatus �ere gange, da vedkommende ikke opdagede at systemet reagerede.


Løsningsforslag: En ressources status bør vises med tekst. Frem for en check-box som er markeret eller ikke markeret, kunne der for eksempel anvendes ordene"Aktiv"og "Inaktiv".

19.9 Konklusion

Vores brugbarhedstest afslørede ingen problemer som forhindrede testperson-erne i, at udføre de opgaver som de skulle. Det er selvfølgelig glædeligt. Men forat kunne give en fair vurdering af resultaterne bør det nævnes at vores systemikke var færdigudviklet, og at funktionaliteten således var begrænset, hvilketselvfølgelig indvirker på hvor stor sandsynlighed der er for at der opstår fejl.Den begrænsede funktionalitet indebærer bl.a. en række dummyknapper, somi systemets nuværende form ikke er aktive, det betyder at der er en mindsketrisiko for at en testperson kommer på afveje i systemet.

Ved vurderingen af de fundne problemer bør der ligeledes tages højde for atvores system er designet med fokus på memorability frem for learnability. Detbetyder at systemet er målrettet mod brugere som kender til systemet, og somhar haft en form for introduktion til systemet. Vores testpersoner kendte ikketil systemet. De �k en kort introduktion for testen, således at de kendte il demest basale funktioner.At testpersonerne ikke havde særlig erfaring i brug af systemet kan have haftindvirkning på testen. Det kan betyde at vores testpersoner muligvis oplevede

112


nogle problemer som en rutineret medarbejder ikke ville opleve.

På trods af de nævnte forbehold er testen dog stadig brugbar. At testperson-erne ikke havde særlig erfaring i brug af systemet har muligvis betydet at derblev fundet problemer som ikke ville være relevante for rutinerede brugere, mendisse problemer kan alligevel være relevante. På trods af at vores systemet byg-ger mere på memorability end på learnability er det alligevel vigtigt at voressystem er til at gå til for en ny medarbejder. Det er vigtigt at det ikke tageruforholdsmæssigt langt tid at �nde ud af hvordan systemet fungerer.

At systemet ikke var færdigudviklet kan som nævnt også have haft indvirkningpå testresultaterne, men testen har alligevel givet et fornuftigt billede af de brug-barhedsproblemer der var med de dele af systemet som rent faktisk fungerede,og ingen af testpersonerne forsøgte i væsentlig grad at anvende dummyknap-perne.

På trods af enkelte forbehold vil vi betegne testen som brugbar, og hvis vi havdemere tid ville systemet uden tvivl kunne forbedres ud fra de problemer som blevfundet i testen.

113

Litteratur

[1] Carsten Juel Andersen. http://www.captator.dk/captator.aspx?

article=66, 2007.

[2] Apple. http://www.apple.com/iphone/, 2007.

[3] Gra�sk BAR. http://www.synsergonomi.dk/page.php?page=14, 2007.

[4] Extra Dimensions. http://www.extradimensions.dk/, 2007.

[5] Magio Flexibook. http://www.flexibook.com, 2005.

[6] Object Management Group. http://www.omg.org/gettingstarted/

what_is_uml.htm, 2005.

[7] Ida Marie. http://www.idamarie.dk/idamarie/Farvelaere/

kompendium.htm, 2007.

[8] Luke T. Maxon. http://nunitforms.sourceforge.net/, 2007.

[9] Microsoft. http://msdn2.microsoft.com/en-us/vcsharp/aa336809.

aspx, 2006.

[10] Microsoft. http://msdn2.microsoft.com/en-us/netframework/

default.aspx, 2006.

[11] Rolf Molich. Brugervenlige EDB-systemer. Nyt Teknisk Forlag, 1994.

[12] Bibliotekernes Netguide. http://info.bibliotekernesnetguide.dk/

referater/Thorlacius.ppt, 2007.

[13] Jakob Nielsen. Evaluation of Website Attractiveness and Usability. SpringerVerlag, 1999.

[14] Jakob Nielsen. http://www.useit.com/papers/heuristic/

severityrating.html, 2004.

[15] Kurt Nøremark. http://www.cs.aau.dk/~normark/oop-07/html/

notes/test.html, 2007.

[16] Marie Christensen og Louise Harder Fischer. Udvikling af multimedier -

En helhedsorienteret metode. Nyt Teknisk Forlag, 2006.

[17] ISO organisation. http://www.iso.org/iso/en/aboutiso/

introduction/index.html, 2003.

114

http://www.captator.dk/captator.aspx?article=66

http://www.captator.dk/captator.aspx?article=66

http://www.apple.com/iphone/

http://www.synsergonomi.dk/page.php?page=14

http://www.extradimensions.dk/

http://www.flexibook.com

http://www.omg.org/gettingstarted/what_is_uml.htm

http://www.omg.org/gettingstarted/what_is_uml.htm

http://www.idamarie.dk/idamarie/Farvelaere/kompendium.htm

http://www.idamarie.dk/idamarie/Farvelaere/kompendium.htm

http://nunitforms.sourceforge.net/

http://msdn2.microsoft.com/en-us/vcsharp/aa336809.aspx

http://msdn2.microsoft.com/en-us/vcsharp/aa336809.aspx

http://msdn2.microsoft.com/en-us/netframework/default.aspx

http://msdn2.microsoft.com/en-us/netframework/default.aspx

http://info.bibliotekernesnetguide.dk/referater/Thorlacius.ppt

http://info.bibliotekernesnetguide.dk/referater/Thorlacius.ppt

http://www.useit.com/papers/heuristic/severityrating.html

http://www.useit.com/papers/heuristic/severityrating.html

http://www.cs.aau.dk/~normark/oop-07/html/notes/test.html

http://www.cs.aau.dk/~normark/oop-07/html/notes/test.html

http://www.iso.org/iso/en/aboutiso/introduction/index.html

http://www.iso.org/iso/en/aboutiso/introduction/index.html


[18] ISO organisation. http://www.iso.org/iso/iso_catalogue/

catalogue_tc/catalogue_detail.htm?csnumber=21922, 2006.

[19] Jenny Preece. Interaction Design. John Wiley and Sons, 2003.

[20] Jan Stage. http://www.cs.aau.dk/~jans/courses/hci-courses/

dieb-2007/slides-pdf/Lektion05.pdf, 2007.

[21] Jan Stage. http://www.cs.aau.dk/~jans/courses/hci-courses/

dieb-2007/slides-pdf/Lektion03.pdf, 2007.

[22] SAP Design Guild Team. http://www.sapdesignguild.org/resources/TSDesignGL/Index.htm, 2007.

[23] Aalborg Universitet. Objekt Orienteret Analyse og Design. Forlag Marko,2001.

[24] Dimitri van Heesch. http://www.stack.nl/~dimitri/doxygen/, 2007.

115

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=21922

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=21922

http://www.cs.aau.dk/~jans/courses/hci-courses/dieb-2007/slides-pdf/Lektion05.pdf




http://www.sapdesignguild.org/resources/TSDesignGL/Index.htm

http://www.sapdesignguild.org/resources/TSDesignGL/Index.htm

http://www.stack.nl/~dimitri/doxygen/

Funcenter Appendiks

Appendiks 1: Samtykkeerklæring

Fortrolighed overfor testpersonen

Testpersonens navn, adresse og andre personlige oplysninger vil hverken optræde

i fremlæggelse af testresultater, i skreven rapport eller i øvrig forbindelse med

vores projekt. Ved underskrivelse af denne samtykkeerklæring indvilliger test-

personen dog i, at den optagne video kan blive brugt til fremlæggelse af testre-

sultaterne ved eksamen i januar 2008. Dvs. testpersonens ansigt vil muligvis

blive set af et begrænset publikum, som censor, lærer og evt. de personer, der

kunne have interesse i at overvære vores projekteksamen. Anden form for of-

fentliggørelse vil ikke �nde sted.

Testpersonen kan i øvrigt stoppe testen, hvis testpersonen af en eller anden år-

sag ikke �nder det muligt eller ønskeligt at gennemføre testen.

Underskrift fra testperson

Testlederens underskrift

116

Funcenter Appendiks

Appendiks 2: Brev til test-person

Kære testdeltager Først vil vi gerne starte med at takke dig for, at du vil hjælpe

os med at gennemføre denne test. Vi vil nu informere dig om testens forløb.

Det system du skal hjælpe os med at teste, er et reservationssystem til et fun-

center. Det vil sige, at du skal sætte dig i en medarbejders position, og kunne

agere som om du bruger systemet til reservationer af funcenterets ressourcer.

Testen foreløber således, at du får stillet et antal opgaver, som du skal forsøge

at løse ved hjælp af systemet.

De opgaver som du får stillet, afspejler en medarbejders typiske brug af systemet

i forhold til reservationsrelaterede opgaver. Det skal bemærkes at alle opgaver

kan løses ved hjælp af systemet, hvilket betyder at du på intet tidspunkt skal

væk fra systemet til andre systemer.

Opgaverne vil du få udleveret, én efter én og du bedes besvare opgaverne på

følgende måde: Først skal du læse hele tektsten til opgaven højt op. Dernæst

skal du fortælle mig, hvordan du forstår opgaven, og hvad du vil gøre for at løse

den. Du skal forsøge at løse opgaven og mens du løser den, bedes du tænke højt

og fortælle hvad du gør, step by step.

Det betyder, at du skal sige:

• Hvad du har tænkt dig at gøre.

• Hvad der frustrerer dig.

• Hvad der overrasker dig.

• Hvad du ellers tænker på under brugen.

Vi ved godt, at det ikke er naturligt at sidde og tænke højt, så hvis du glem-

mer det, vil jeg minde dig om det. Hvis du får problemer under løsningen af

opgaven, kan du godt spørge mig. Jeg vil nok ikke hjælpe dig direkte. I stedet

vil jeg forsøge at få dig til selv at komme videre ved egen hjælp. Hvis du stadig

sidder fast og jeg vurderer, at opgaveløsningen ikke længere tjener et formål, vil

du få stillet en ny opgave.

Husk at det er et udtryk for at systemet er uhensigtsmæssigt, der er ingen grund

til at give dig selv skylden. Når du mener, at du er færdig med at løse en opgave,

vil jeg bede dig sige det, så vi ikke er i tvivl bagefter. Under testen vil du og

dine bevægelser på skærmen blive video�lmet. Disse optagelser vil udelukkende

blive brugt til senere analyse og vil aldrig blive o�entlig tilgængelige uden dit

samtykke.

Testforløbet vil blive observeret af tre andre personer udover mig. Disse person-

ers tilstedeværelse er udelukkende nødvendig for at styre det tekniske udstyr,

samt registrere de problemer du eventuelt skulle støde ind i. Det er vigtigt at

du forstår at det naturligvis er systemet, vi ønsker at teste og ikke dig. Det er

derfor vigtigt at du løser de opgaver som vi stiller i et tempo som du �nder

naturligt og afslappende.

At gennemføre en sådan test kan være meget krævende, rent mentalt. Føler du

under testen at du får brug for en pause skal du derfor endelig sige til.

Før testen starter, vil jeg bede dig om at underskrive denne samtykkeerklæring

for at sikre, at du er indforstået med rammerne for testen. Har du spørgsmål til

denne eller forsøgets forløb må du endelig spørge mig nu.

117

Funcenter Appendiks

Appendiks 3: Sekvensdiagram for ny kunde

118

Funcenter Appendiks

Appendiks 4: Sekvensdiagram for ny ressource

119

Funcenter Appendiks

Appendiks 5: Sekvensdiagram for aktiv/deaktiv

120

Funcenter Appendiks

Appendiks 6: Sekvensdiagram for ny reservation

121

Funcenter Appendiks

Appendiks 7: Sekvensdiagram for ret reservation

122

Funcenter Appendiks

Appendiks 8: Sekvensdiagram for slet reservation

123

Funcenter Appendiks

Appendiks 9: Præsentationsmodel

124

Funcenter Appendiks

Appendiks 10: Navigationsdiagram

Kalender

Reserveret/Optaget

Eksisterende reservation

Forslag til reservation

Symbol forklaring

GodkendTilbage

Login /

Logout

Søg

Kunde /

Ressource

Ressource

Hovedmenu

Laser

gameSpisningPoolBowling

Søg ledig/ret ressource

Indtast dato

Indtast klokkeslæt

Annuller Godkend

PoolBowling

Bekræftelse

Tilbage GodkendAnnuller

Indtast personoplysninger

Indtast telefonnummer

Annuller GodkendTilbage

Indtast

yderlige

oplysninger

Navn: xxxx xxxxx

Adresse: xxxxxxx xx

Post nr: xxxx

By: xxxxx

Mail: xxxxxxxxx

GodkendTilbage

Indtast telefonnummer

Yderlige (Ret) personoplysninger

Indtast information Indtast information

Indtast information

Indtast information Indtast information

Tilbage

Annuller

OK

Print

bekræftel

se

Ok

Send

mail

Aftale

godkendt

Gem

kunde

Afslut

Aftale

godkendt

Klarmeld

Fejlmeld

Ressource xx

Søg kunde/ressource

Annuller Godkend

Søg kunde

Søg Ressource

Søg

yderlige

oplysninger

Ressource browcer

Tilbage

Ikke aktiv

Opret / Ret / Slet ressource

Vælge type

Indtast Information

Opret /

Godkend

Indtast Information

Indtast Information

Indtast Information

Indtast Information

Ny

Aftale

Afslut

programGodkend

Login

Indtast Brugernavn

Indtast Password

Påvirket

Reservationer

xxxxxxxxxx

xxxxxxxxxx

xxxxxxxxxx

xxxxxxxxxx

Indtast kunde nr. Indtast

yderlige

oplysning

er

Navn: xxxx xxxxx

Adresse: xxxxxxx xx

Post nr: xxxx

By: xxxxx

Mail: xxxxxxxxx

Aftale oplysninger

Xxxxxxxxxx xxxxxxxxxx















Godkend

Xxxx: xxxx xxxxx

Xxxxxx: xxxxxxx xx

Xxxxx: xxxx

Xxxx: xxxxx

Xxxxx: xxxxxxxxx

Opret ny

Ressourc

e

Slet Aftale

Slet

reservati

on

Ret

reservati

on

Reservation

Aftale

Navigations diagram

Slet

ressourc

e

Tilbage

OK

Slet ressource

Dato

tilbage

Dato

frem

Tilbage

Ret/Slet

Ressourc

e

Indtast reservations nr.

Igangsæt

Ny

Aftale

Annuller

Oplysnings view
















Godkend

Ret

Oplysnin

ger

Godkend

Godkend

sletning

Annuller

Godkend



Tilføj

aktivitet

125

Fun Center

Documents

Transcript of Fun Center