UDVIKLING AF SUPPORTSYSTEM

Transkript

1 UDVIKLING AF SUPPORTSYSTEM Aalborg Universitet E2-214 INF2 2002

2 Gruppe E2-214 Side 2

3 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere Department of Computer Science Aalborg Universitet Titel: Tema: Design og vurdering af et edb-system i samarbejde med brugere Projektperiode: Fra: 4. februar 2002 Til: 30. maj 2002 Gruppe: E2-214 INF2 Synopsis: Gruppemedlemmer: Casper Lykke Hansen Morten Sieker Andreasen René Møller Lauridsen Simon Ormholt Schrøder Rasmus Flyger Berg Andersen Henrik Villemann Nielsen Allan Sandal Hagelskjær Vejleder: Marianne Bangsø Oplag: 10 Sider: 115 Dette projekt omhandler udviklingen af et IT-system. Dette system skal effektivisere arbejdsgangene i supportafdelingen hos IT-virksomheden SAXoTECH. Samarbejdet med SAXoTECH har været omdrejningspunktet under udviklingen. Under udviklingen har vi gjort brug af en blanding af metoder. Vi har inddraget dele af Prototyping, OOA&D og Extreme Programming. Vi har anvendt de forskellige metoder i det omfang, vi har ment det var nødvendigt. Udfra metoderne har vi analyseret det eksisterende system og derudfra har vi lavet en prototype af det nye system efter udarbejdelsen af et design. Prototypen er testet for brugervenlighed hos brugerne ved SAXoTECH. Ud fra vores test kunne vi se, at brugerne helt klart mente, at det nye system var bedre end det eksisterende. Testen viste dog også at der var mange ting der skulle forbedres. Samarbejdet med SAXoTECH har været essentielt for udviklingen af prototypen. Vi har lavet en Prototype, som løser de grundlæggende problemer fremsat af SAXoTECH. Der mangler dog meget funktionalitet inden man kan sige, at programmet er klar til introduktion i firmaet. Vi har gennem samarbejdet med SAXoTECH fået erfaringer i, hvordan det er at arbejde for en kunde, hvilke vi kan drage stor nytte af i fremtiden. Alt i alt har dette semester været en meget positiv oplevelse. Side 3 af 115

4 Gruppe E2-214 Side 4

5 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere 1 Forord Dette projekt er lavet over temaet Design og vurdering af et edb-system i samarbejde med brugere. Vi har valgt at lave et supportsystem som skal bruges i forbindelse med support hos firmaet SAXoTECH. Igennem projektet har vi haft forbindelse til supportafdelingen hos SAXoTECH. Vi vil i denne forbindelse gerne takke Torben Hoelgaard, Kim Skovgaard og resten af SAXoTECH s supportteam, for deres hjælp i at få dette projekt lavet. Hovedgruppen for denne rapport er primært den eksterne eksaminator, vores vejleder og supporterne hos SAXoTECH. Læsevejledning for denne rapport: Referencerne i denne rapport er skrevet i følgende format: [forfatter, sidetal, linie]. Mere specifikke oplysninger om referencen findes i litteraturlisten. Hvis andet ikke er angivet, betyder en kunde SAXoTECHs kunder, mens bruger betyder den endelige bruger af systemet, oftest supporterne. Der er vedlagt skærmbilleder af programmet (bilag 7), samt et implementationsafsnit (bilag 6). En CD er inkluderet med denne rapport og indeholder rapporten i følgende formater [*.pdf, *.doc, *.rtf]. Samtidig vil der være lydspor med vores test og selve programkoden (bilag 5). Aalborg Universitet, 30. maj Casper Lykke Hansen Morten Sieker Andreasen René Møller Lauridsen Simon Ormholt Schrøder Rasmus Flyger Berg Andersen Henrik Villemann Nielsen Allan Sandal Hagelskjær Side 5 af 115

6 Gruppe E2-214 Side 6

7 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere Indholdsfortegnelse 1 FORORD INDLEDNING TEORI & METODE (GENERELT) PROTOTYPING OOA&D Analyse Design EXTREME PROGRAMMING Hvad er XP? Kunden i centrum Ledelse og planlægning Analyse Design Kodning Test Opsummering BRUGERVENLIGHED Den klassiske definition Katastrofer De fem gyldne regler Gestaltlove SYSTEMUDVIKLINGSFILOSOFI Hard Systems Thinking (HST) Soft Systems Thinking (SST) Dialectic System Thinking (DST) Sammenligning af HST og SST TEST Metodevalg Andre testformer Konstruktiv interaktion Observation TEORI & METODE (PRAKSIS) UDVIKLINGSMODEL Overordnet model Design Programmering Opsummering TEST Introduktion Formål Problemspecifikation Brugerprofil Metode Opgaveliste Testmiljø og udstyr Testlederens rolle Testkriterier BRUGERVENLIGHED I PRAKSIS Mål Udvikling Eksempel 1: Optimering af brugerfladen Eksempel 2: Brug af forbillede Eksempel 3: Brug af gestaltlove Side 7 af 115

8 Gruppe E Opsummering SYSTEMFILOSOFI PREANALYSE PROJEKTVALG VORES SAMARBEJDSPARTNER VORES FØRSTE MØDE MED SAXOTECH PROBLEMDEFINITION KRAVSPECIFIKATION SYSTEMDEFINITION ANALYSE BESKRIVELSE AF SUPPORT ARBEJDSRUTINER USE CASES FOR MODTAGELSE AF FEJLMEDDELELSE Telefonisk henvendelse Henvendelse via mail/osc DEN EKSISTERENDE BRUGERFLADE KLASSEDIAGRAM DELKONKLUSION DESIGN HÅNDTERINGEN AF OPKALD HÅNDTERINGEN AF MAILS HÅNDTERINGEN AF KUNDEOPLYSNINGER BRUGSSCENARIER Brugsscenarier for det nye system Vurdering KLASSEDIAGRAM FUNKTIONSLISTE SKITSE AF BRUGERFLADEN REVIDERET PROBLEMDEFINITION Revideret kravspecifikation Revideret systemdefinition EKSEMPLER PÅ NY BRUGERFLADE DET NYE DESIGN TESTRESULTATER VURDERING OG FORBEDRINGSFORSLAG UDFRA TESTRESULTATERNE Forbedringsforslag Vurdering udfra spørgeskemaerne DELKONKLUSION SAMARBEJDSDOKUMENT FILOSOFISK ANSKUELSE DELKONKLUSION VURDERING UDVIKLINGSMODEL TEST SAMARBEJDE KONKLUSION METODER PROGRAMMET ER KRAVENE OPFYLDT? TEST & RESULTATER Side 8

9 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere 14.5 AFRUNDING LITTERATURLISTE BILAG & APPENDIKSOVERSIGT Side 9 af 115

10 Gruppe E2-214 Side 10

11 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere 2 Indledning Vi har i dette projekt, udfra forskellige teorier og metoder om udvikling af software, beskrevet udviklingen af et stykke software til IT-virksomheden SAXoTECH. Det udviklede software har til formål at lette kommunikationen mellem supportere, interne udviklere og firmaets kunder. Dette er gjort gennem en proces, hvor Prototyping har været omdrejningspunktet. En ting der er kendetegnende for stort set alle former for software er, at der er mennesker der gennem deres arbejde eller på anden vis er afhængige af softwaren for at kunne udføre forskellige opgaver et program kan ikke kaldes en succes, om end det er programmeret efter den bedste praksis, hvis ikke brugerne er interesserede i at anvende det. Dette betyder, at man må inddrage fremtidige brugere i udviklingen af software, for at kunne målrette produktet mod de krav og ideer brugerne har. Men betyder dette, at man skal have alle de fremtidige brugere med under udviklingen for at kunne sikre at disse vil finde systemet tilfredsstillende? Dette ville hurtigt blive en uoverskuelig opgave, og det er her udviklingsmetoder kommer til deres ret. Disse forskellige metoder gør, at man i samarbejde med en gruppe af brugere, kan udvikle et stykke software, som i høj grad kan rettes mod samtlige brugere. Dette er en god grund til, at være interesseret i netop dette semesters temaramme som er: Projektenheden på INF2 har temaet Design og vurdering af et edbsystem i samarbejde med brugere. Semestrets formål er at udbygge og afrunde den studerendes grundlæggende kendskab til centrale datalogiske emnekredse med særlig fokus på interaktion med brugere i udviklingsarbejdet.[ 25/ Vi har gennem analyse og design af det eksisterende system kunnet lave, et system der i høj grad løser de kerneproblemer som blev fremsat af SAXoTECH. Dette er gjort i tæt samarbejde med ledelsen og brugerne i firmaet, hvilket har resulteret i en kørende prototype der med en samlet arbejdsproces kunne udvikles til et færdigt kørende system som kunne lette hverdagen for de ansatte hos SAXoTECH. Side 11 af 115

12 Gruppe E2-214 Side 12

13 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere 3 Teori & metode (generelt) 3.1 Prototyping I det følgende afsnit vil vi gennemgå ideerne bag Prototyping. Bag langt de fleste af de kommercielle applikationer, der i dag findes på vore computere, ligger mange timers planlægning, afprøvning og diskussion. Helt præcist hvordan man har nået det færdige resultat, varierer i sagens natur i det uendelige. Dog har de næsten alle det til fælles, at de på et eller andet tidspunkt, har eksisteret som prototyper. Disse prototyper har repræsenteret forskellige elementer der, måske, måske ikke, er blevet implementeret i den færdige applikation. Softwarebranchen er benhård. Her kan man med rette bruge det darwinistiske udtryk "survival of the fittest." Det samme må ligeledes gøre sig gældende med udviklingen af prototyper. Vi kan vælge at betragte udviklingen fra prototype til applikation som et evolutionsforløb, hvor udviklerne, i skaberens rolle, afprøver forskellige løsninger. Her lever en prototype således i kraft af sine styrker indtil den må vige pladsen for en stærkere og mere succesfuld udgave. En, der er bedre egnet til overlevelse. Det er den stærkeste der overlever, når brugerne vender tommelen op eller ned. En prototype er et til dels udviklet produkt, som gør kunder og udviklere i stand til, at undersøge forskellige dele af et foreslået system og derigennem fastslå om det er egnet til det færdige produkt. [Pfleeger 2001] s. 51, l. 2. En prototype vil typisk starte på et planlægningsstadie, hvor den eksisterer udelukkende som tegninger på et papir, hvor hver tegning repræsenterer et skærmbillede. Herefter kan det være man arbejder hen imod en kombinationsløsning, der er baseret både på papir og computergrafik, inden man tager skridtet fuldt ud og sigter mod den elektroniske prototype, der i sidste ende gerne skulle resultere i en færdig applikation. Når man snakker om prototyper er der to måder, hvor på disse bliver udviklet og behandlet. Disse er; evolutionary og throw-away. En throw-away prototype er software der skal hjælpe udviklere til, at forstå forskellige problemer. Ligeledes bruges denne til, at få af- eller bekræftet om de forskellige løsningsforslag er berettigede i softwaren. En throw-away prototype er ikke udviklet eller beregnet til, at blive en del det endelige system. Dette vil med andre ord sige, at når prototypen har været brugt smides den væk og udviklerne tage de nye erfaringer og fører disse med over i et nyt system. Dette er dog ikke tilfældet ved den evolutionary prototype. Denne er ligeledes skabt til, at skabe forståelse for systemet, dog er forskellen at denne prototype skaber basis for det endelige system. [Pfleeger 2001] s. 169, l. 6. Det vil sige, at prototypen benyttes til at udvikle applikationen under hele udviklingsforløbet hen mod en færdig og fuldt funktionel applikation. Endvidere tillader den, at udvikleren løbende kan foretage ændringer på baggrund af tests og analyser. Alene det at diskutere begrebet "en færdig applikation" er vanskeligt, da det er de færreste applikationer, hvis udvikling nogensinde stopper. Selvfølgelig har de fleste applikationer en vis forventet levetid, som afhænger af flere faktorer, men gennem denne levetid foretages der næsten konstant mindre ændringer i applikationen, fra udviklernes side. Ideen i at konstruere en prototype er muligheden for at teste denne for fejl, og lære af dem. Man er så i stand til at implementere forbedringer i forhold til testen, i en ny forbedret prototype. Sådan fortsætter man indtil prototypen, af udviklerne, bliver bedømt som værende klar til at tage springet fra prototype til færdig applikation. Herefter vil den være underlagt et vedvarende vedligeholdelsesarbejde fra udviklernes side, i takt med at fejl og forslag til forbedringer tages til Side 13 af 115

14 Gruppe E2-214 efterretning. Man kan lave interne tests, hvor det er udviklerne selv, der tester applikationen. Endvidere kan man lade personer fra målgruppen deltage i forsøgene for at se om applikationen taler det "rigtige sprog." Der er både fordele og ulemper ved at bruge personer fra disse to grupper. De fleste vil jo nok mene, at udviklerne ikke har mulighed for at se objektivt på applikationen selv. Derimod kan udviklernes viden i forhold til applikationen også udnyttes til at gå dybere ned i analysen af applikationen. Når man gør brug af personer fra målgruppen er der åbenlyse fordele, idet man her har et antal personer, som er i den gruppe applikationen er henvendt til. Endvidere har personerne ikke umiddelbart nogen viden om applikationen på forhånd og ingen tilhørsforhold, hvilket betyder, at de har mulighed for at være helt objektive. En ulempe kunne være, at det kan være svært at få personer uden for projektet til at leve sig helt ind i brugssituationen. Desuden kan man forestille sig, at disse personers engagement i testen eller forståelse af denne, ikke lever op til udviklernes ønske. Alt i alt kan man sige, at en prototype er fornuftig måde til, at teste en applikation gennem hele udviklingsforløbet. Prototypen er under hele processen i konstant udvikling gennem en iterativ proces hvor der foretages tests og revurderinger af design og funktionalitet. 3.2 OOA&D Dette afsnit er skrevet ud fra bogen Objekt Orienteret Analyse & Design [Mathiassen et. al]. Objekt Orienteret Analyse & Design (OOA&D) er en meget anvendt metode indenfor systemudvikling. Den mest basale byggesten i metoden er objekter. Disse bruges som beskrivende elementer, hvorved man får en større forståelse af problemområdet. Endvidere bruges begrebet hændelser til, at beskrive interaktionen mellem de forskellige objekter. Da objekterne og hændelserne kan være meget omfattende samles de i klasser, hvorved man ikke længere kigger på det enkelte objekt, men i stedet abstraheres disse. Herved får man en beskrivelse af en samling objekter med samme struktur, adfærdsmønster og attributter. Fordelen med dette er, at man herefter kan lave en klassestruktur der giver et godt og fornuftigt overblik over problemområdet. Der er samtidig en tæt sammenhæng mellem objektorienteret analyse, design og programmering. OOA&D analysen er en kombination af følgende: Problemområdet: Den del af omgivelserne, der administreres, overvåges eller styres ved hjælp af et system. [Mathiassen et.al. 2001] s. 6 l. 27 Anvendelsesområde: En organisation, der administrerer, overvåger eller styrer et problemområde. [Mathiassen et.al.2001] s. 6 l. 29 Side 14

15 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere Analyse I bogen, Objekt Orienteret Analyse og Design, beskrives disse tre punkter som værende formålet med et analyse og design dokument [Mathiassen et.al.2001] s.3, i tabel.. At aftale krav til et edb-system. At designe et edb-system uden væsentlige usikkerheder. At forstå et edb-system, dets omgivelser og vilkårene for dets realisering. Det er grundlæggende punkt 1 og 3 vi beskæftiger os med her i analysen. Nemlig det at lave en kravspecifikation i samarbejde med brugeren og analysere deres nuværende anvendelses og problem område, så vi får en bedre indsigt i, hvilke rammer vi skal bygge vores nye system op om. Systemdefinition Det første der gøres i OOA&D er at lave en systemdefinition, hvilket er en kortfattet og præcis beskrivelse af et system udtrykt i naturligt sprog. I systemdefinitionen vil der stå, hvad systemet skal indeholde informationer om, hvad det skal kunne og hvor det skal bruges, samt hvilke betingelser der gælder for udviklingen. Den systemdefinition der udarbejdes skal være med til bevare overblikket igennem resten af analyse- og designarbejdet. I forbindelse med systemdefinitionen i OOA&D, bliver der indført kriterium for dennes indhold. Disse bliver beskrevet i et såkaldt BATOFF-kriteriet, som står for Betingelserne, Anvendelsesområde, Teknologi, Objekter, Funktioner og Filosofi. Problemområde En af de første ting der skal analyseres i analysedelen er selve problemområdet, det vil sige den del af omgivelserne der administreres, overvåges eller styres ved hjælp af et edb-system. Opgaven er at se på problemområdet og brugernes forståelse af dette. Derfor nøjes man med, at observere det der sker. Målet med en analyse af problemområdet er, at kunne opstille en model for det der sker. Ud fra denne er det så være muligt, at designe og implementere et system der kan behandle, kommunikere og præsentere information fra problemområdet på en effektiv måde. Det er vigtigt, at analysen af problemområdet danner et overblik, i stedet for en masse beskrivende detaljer der kan være med til, at forvirre og ødelægge overblikket. Noget af det første man beskæftiger sig med i analysen af problemområdet er, at udvælge, hvilke objekter og hændelser der skal med i modellen. Som nævnt i den indledende del af dette afsnit bliver objekterne og hændelserne klassificeret i klasser, og de klasser systemet skal bevare informationer om bliver udvalgt. Endvidere skal disse klasser være med til, at definere og afgrænse problemområdet. En anden del i analysen af problemområdet er struktur aktiviteten, hvor der sættes fokus på sammenhænge mellem klasser og objekter. Dette gøres for at forstå de abstrakte, generelle sammenhængen mellem klasser og de konkrete sammenhænge mellem objekter. Opgaven i klasse aktiviteten er at udvælge klasser til modellen og karakterisere deres hændelser. I strukturaktiviteten skal denne beskrivelse udvides ved at tilføje strukturelle relationer mellem klasser og objekter. Side 15 af 115

16 Gruppe E2-214 Den sidste aktivitet under analysen af problemområdet er, at kigge på adfærdsaktiviteten. Her bliver beskrivelsen af klasserne i klassediagrammet udvidet ved, at der bliver tilføjet en beskrivelse af adfærdsmønstret og attributter for hver klasse. Desuden resulterer dette i et tilstandsdiagram for hver klasse. Anvendelsesområde Efter at have analyseret problemområdet, skal anvendelsesområdet analyseres, dette hænger tæt sammen med analysen af problemområdet. Formålet med analysen af anvendelsesområdet er at definere de krav, der er til systemets model og at formulere krav til funktioner og grænseflade. Det er i analysen af anvendelsesområdet at brugsmønstrene bliver lavet. Disse er med til at opnå et relevant fokus og abstraktionsniveau. I brugsmønstrene beskrives aktørerne, hvilke er personerne og andre IT-systemer, der anvender systemet. At opstille brugsmønstre er en svær aktivitet, da det kræver samarbejde mellem brugere og udviklere. Det er kunden der formulerer deres behov og bidrager derigennem med deres indsigt i anvendelsesområdet, mens det er udvikleren der formulerer brugsmønstre og bidrager med teknisk indsigt. I anvendelsesområdet bliver funktionerne som systemet skal indeholde også beskrevet. Der bliver i denne del af analysen opstillet en komplet liste af funktioner samt detaljerede specifikationer af de komplekse dele. Udfordringen ved funktionsaktiviteten er at vælge hvilke funktioner der skal være med i systemet. Det er også i anvendelsesområdet at grænsefladen bliver beskrevet, da det er denne der bruges af aktørerne (brugerne) til at interagere med systemet. Grænsefladen er delt op i to dele; brugergrænsefladen, hvilket er den del brugerne bruger, og systemgrænsefladen, hvilket er grænsefladen til andre systemer. Analysen af disse grænseflader skal føre til en komplet beskrivelse af både brugergrænseflade- og systemgrænsefladeelementer. Det er i denne del af analysen ikke nødvendigt at gå for meget i detalje omkring de forskellige grænsefladeelementer. Men i stedet skal dialogformen og præsentationsformen beskrives sammen med en liste af alle brugergrænsefladeelementer. Analysen af brugergrænsefladen hænger meget sammen med de andre dele af analysen fra både problemområdet og anvendelsesområdet. Side 16

17 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere Design I OOA&D s designdel skal man designe den arkitektur som systemet skal bygges op efter. Ideen med denne arkitektur er, at systemet deles op i mindre dele som skal opfylde bestemte designkriterier. Designdelen i OOA&D lægger meget op til, at designet skal leve op til de krav, der formuleres i analysedelen. Noget af det første man derfor gør i designet, er at opstille en liste over de designkriterier for kvalitet, som systemet skal overholde for, at man kan kalde det for et godt design. Ved OOA&D sker denne prioritering af designkriterier ved at opstille en checkliste med dem, hvor man kan vælge hvilken prioritet et designkriterium har. Det er også i designdelen at den tekniske platform bliver defineret, da det har betydning for hvor mange resurser et program må bruge. Det er ligeledes her udvikleren tager stilling til, hvilket programmeringssprog systemet skal designes i. En af hovedopgaverne i designdelen er at opstille en komponentarkitektur, da denne gør det lettere at forstå systemet og organisere designarbejdet. Komponentarkitekturen reducerer samtidig det samlede design til en række mindre komplekse opgaver. Når komponentarkitekturen skal opstilles, beskrives dette i et klassediagram, hvor komponenterne beskrives som pakker, og forbindelsen mellem dem som afhængigheder. Det diagram, der kommer ud af denne komponentarkitektur, kan mange gange se meget enkelt og trivielt ud, men til gengæld tvinger designet af komponentarkitekturen udviklerne til at tænke over de enkelte komponenters ansvar. Ideen med at lave en komponentarkitektur er, at lave en sammenhæng mellem de krav der er fundet frem til i analysedelen og de tekniske muligheder. To af de væsentlige komponenter der bliver designet er model- og funktionskomponenterne. Modelkomponenten skal indeholde hvordan klasserne i systemet repræsenteres, mens der i funktionskomponenten står beskrevet hvordan funktionerne i systemet skal implementeres. Side 17 af 115

18 Gruppe E Extreme Programming En utraditionel, kontroversiel og forholdsvis ny metode til udvikling af software er Extreme Programming (XP). XP vender op og ned på de traditionelle udviklingsmetoder, og den har både modstandere og tilhængere. En af pionererne inden for XP er Kent Beck, og det er [Beck 2000] der er grundlag for dette kapitel. Metoden er specielt velegnet til små eller mellemstore udviklingsgrupper, der arbejder med skiftende systemkrav. XP er opstået i en erkendelse af traditionelle udviklingsmetoders begrænsninger. Selvom man i årevis har anvendt mere og mere udviklede varianter af dem, støder man igen og igen på de samme problemer:?? Tidsplanen holder ikke og afleveringsfrister udskydes?? Projekter aflyses inden de når produktionen?? Systemet bliver i tiltagende grad kaotisk?? Systemet indeholder for mange fejl?? Systemet svarer ikke til kundens behov?? Systemet indeholder mange irrelevante eller ubrugelige funktioner, der måske var sjove at programmere men ikke understøtter kundens forretningsbehov.?? Kravene ændres undervejs og det er ikke muligt at implementere dem Endvidere er de almindelige udviklingsmetoder ikke særlig motiverende for udviklerne. Beck hævder, at den traditionelle opbygning af et udviklingsforløb strider imod programmørens natur. Derfor forsøger man i XP at vende udviklingen på en måde, der er naturlig, spændende og produktiv for udviklerne, samtidig med at kundens behov er i centrum Hvad er XP? Ifølge [Beck 2000] s. xvii er XP en effektiv, letvægts, lav-risiko, fleksibel, forudsigelig, videnskabelig og sjov måde at udvikle software på. Dens væsentligste karaktertræk er:?? Hurtig, konkret løbende feedback fra små udviklings cyklusser?? En trinvis planlægningsprocess, hvor der hurtigt udvikles en plan for hele projektets levetid?? Evnen til fleksibelt at planlægge implementationen efter skiftende forretningsbehov?? Løbende tests skrevet af både udviklere og kunder er med til at fange fejl tidligt?? Vægt på mundtlig kommunikation og test, samt program kode der er selvforklarende med hensynt til funktion og program struktur?? En evolutionær design proces der varer lige så længe som systemet?? Vægt på tæt samarbejde mellem programmører?? Vægt på arbejdsprocedurer der både stemmer i overens med programmørernes instinkter og projektets langtidsinteresser. Side 18

19 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere Kunden i centrum Som med alle andre udviklingsmodeller er det ultimative mål med XP, at kunden er tilfreds med den software, der bliver udviklet. Forskellen i forhold til traditionel software udvikling er, at kunden inddrages intensivt. Projektgruppen består således ikke blot af udviklere og en projektleder, men også af en repræsentant fra kunden, der har indblik i det pågældende system bliver et permanent medlem af holdet. Kundens opgave i projektgruppen er, at fremlægge de behov og krav, som systemet skal efterleve. Kontaktpersonen skal løbende besvare de spørgsmål, som udviklerne støder på. Det medfører, at man sjældent vil løbe ind i en blindgyde i systemudviklingen. Det er fuldt legalt for kunden, at ændre systemkravene midt i udviklingen, faktisk opfordres denne til det. Opgaverne i udviklingen fordeles ved hjælp af såkaldte CRC-kort. CRC står for class, responsibility and colalaborators, hvilket på dansk kan oversættes til: Klasse, ansvarlighed og samarbejde. Hvert kort indeholder en historie, der beskriver en konkret opgave, som systemet skal løse. Den kan både være formuleret af en udvikler eller en bruger af systemet. Ved gruppemøder, hvor både udviklere, kunden og brugere er tilstede, gennemgår man historierne og udvælger dem, der umiddelbart vil tilføre systemet den største merværdi. Merværdi er her defineret som de funktioner, der forretningsmæssigt vil betyde mest for det endelige produkt. Det er også ved denne brainstorm, at systemet deles op i klasser, objekter, og sammenhængen mellem dem bestemmes. Når man har prioriteret opgaverne fordeles de, og hver enkelt udvikler vurderer, hvor lang tid opgaven vil kræve. Dette er essentielt, da det i høj grad er med til at fremme realistiske tidsplaner, når den enkelte udvikler selv kommer med overslaget. I mere traditionelle softwareudviklings metoder anvender man kun CRC-kort, i den indledende fase af projektet. I XP anvendes de gennem hele projektet. Det medfører et fleksibelt forhold til nye systemkrav, og derudover er det også en god måde at dokumentere de beslutninger, der blev vedtaget ved mødet. Det er vigtigt at holde en vis disciplin ved møderne, så man anvender tiden effektivt. Jo flere personer der deltager i møderne, jo flere bliver inddraget i udviklingsprocessen Ledelse og planlægning Projektlederens rolle er at sørge for, at de langsigtede mål overholdes. Han skal ikke fordele opgaverne men påpege, hvad der skal laves. Endvidere skal han på alle måder hjælpe udviklerne med at levere et stykke kvalitetsarbejde. Den overordnede tidsplan er yderst begrænset. I stedet følger den detaljerede planlægning de forskellige releases af systemet, hvilket kunne være intervaller på 1-4 uger. Kunden vælger den release der har den største anvendelighed set i et forretningsperspektiv. Hvilket betyder, at kunden altid ved hvad han får. En vigtig del af organisationen er, at ingen personer ejer et stykke kode. Alle har ret til at ændre i al kode. Side 19 af 115

20 Gruppe E Analyse Analyse fasen er meget vigtig i XP, det er her kunden (som regel den fremtidig bruger af systemet) der beskriver, hvad systemet skal indeholde og kunne. En af de første ting der sker er, at kunden nedskriver et sæt af user stories. En user story kan sammenlignes med en use case i andre udviklingsmetoder. I user stories står der de refleksioner kunden har haft over, hvordan det fremtidige system skal fungere. Når user stories er udarbejdet kan der laves en projektplan. Dette starter med, at udviklerne laver en fælles vurdering over, hvor lang tid det vil tage, at implementere systemet. Denne tidsplanlægning bliver inddelt i mindre dele, alt efter behov. De planlagte tidsintervaller vil altid kunne ændres, hvis det er nødvendigt Design Design delen i XP er stærkt nedprioriteret i forhold til andre udviklingsmodeller. I hvert fald, hvis man opfatter design på den traditionelle måde. Der lægges ikke meget vægt på design, da man ønsker, at udvikle et brugbart system så hurtigt som muligt. Derfor udvikles og ændres designet løbende gennem projektet. Det er naturligvis fortsat nødvendigt at skabe et overblik over et endeligt system, men dette overblik skabes ikke ved hjælp af et stort design dokument. Det er i orden, at man på forhånd har en ide omkring, hvordan man vil implementere en bestemt del af systemet. Denne form for små-design opmuntres man rent faktisk til i XP. Målet er, at gøre hele projektet og systemet mere fleksibelt, så ændringer er mulige. Det centrale begreb når man arbejder med design i XP er simpelhed. Alle strukturer og koder tilstræbes at være så simple som overhovedet mulig, og det udvikles i en iterativ proces. Refactoring er en meget vigtig og stor del af XP metoden. Kort fortalt er det en måde, hvor man rydder op i kode ved at fjerne uoverflødige dele såsom ubrugte funktioner. Refactoring gør det muligt, at arbejde med voksende kode, uden en tilbundsgående beskrivelse af designet, som XP forsøger at undgå. Refactoring sørger ligeledes for, at programmører ikke holder sig til de forkerte ideer, da de bliver tvunget til at bruge simpel, ren og forståelig kode Kodning Kodeprocedurerne i XP adskiller sig fra de fleste andre udviklingsmetoder. Et af de mest kendte elementer i XP er parprogrammering. Mange sætter fejlagtigt lighedstegn mellem parprogrammering og XP. Dette er en grov forenkling. XP er som et korthus, hvor kortene er elementer som hyppig testning, brugerinddragelse og endda det fysiske arbejdsmiljø. Parprogrammering går ud på, at to udviklere arbejder sammen om udviklingen af et stykke kode. Den ene person skriver koden, mens den anden bevarer det kølige, overordnede overblik og fanger fejl i programmeringen. Dermed bliver kodens kvalitet angiveligt høj, og metoden styrker også udbredelse af kompetence udviklerne imellem. Hvis man anvender et rotationsprincip, er det også muligt, at alle medarbejdere bliver fortrolige med en meget stor andel af programmet. Tilhængere af XP påstår, at resultatet af par programmering er mindst det samme, som det to enkelte programmører kan nå at lave hvis ikke mere. Side 20

21 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere Test Test er et af de vigtigste elementer i XP. Det er en forudsætning for det, onde tunger ville kalde kaotisk organisation. Det er testningen der muliggør programkode på et højt kvalitetsniveau. Man skelner inden for XP mellem to typer af tests, der dog er tæt relateret; unittest og acceptancetests. Almindelig unittestning udføres løbende og ofte. Dem der arbejder med et stykke programkode, tester det sideløbende med udviklingen. Ofte skrives testen faktisk før en eneste linie programkode er skrevet. Acceptance tests er derimod skrevet af kunden for at sikre, at deres behov dækkes. For at undgå at systemet bliver kaotisk og fyldt med fejl bliver der skabt og vedligeholdt en omfattende test suite, som køres efter alle ændringer i systemet. Hvis der opstår fejl, rettes de med det samme. Unit tests er en måde til at teste adfærden hos den enkelte klasse. Ved god XP praksis sætter en udvikler sig ned og overvejer, hvad formålet med den klasse, han er i færd med at skrive, er. Det er muligt at skrive unittests for enhver enkelt klasse i et system. Unit tests gør det meget nemt, at bygge god, funktionel og højkvalitets kode. Når en klasse ikke passer til en unit test ændres den. Et stykke kode vil aldrig blive integreret med det kørende system, før det er testet og virker fuldstændigt. I praksis skal kode dog integreres med systemet, så snart som det er muligt. Den anden form for tests i XP s udviklingsproces er acceptance tests. De er baseret på bruger fortællinger, der oversættes så de kan testes. Dette svarer på mange måder til black box tests. Det er irrelevant, hvordan systemet udfører opgaverne så længe resultatet er korrekt. Acceptancetests er et af målene med programmeringsindsatsen hos udviklerne. Den medfører ren og simpel kode, da unødvendige egenskaber viser sig i testen. Man ser fremad og kun ting der er nødvendige for den pågældende iteration bliver implementeret. Ved denne form for tests får kunden lige nøjagtigt, det de ønsker - hverken mere eller mindre. Når Refactoring er sket køres testene igen, og hvis det ikke fungerer et hundrede procent er der noget galt. En anden stor fordel er, at det kollektive ejerskab af kode gøres simplere. Med mange udviklere på det samme stykke kode er det rart, at have en nem måde til, at verificere den opdaterede kode. Ligeledes gøres den hyppige kode integration lettere af netop samme grund Opsummering Målet med XP er at opnå højere kvalitet og hastighed gennem en bedre forståelse af kundens behov. Det kræver en ny måde at tænke på. En del af procedurerne er dristige og vil kræve en del mod af både udviklere og ledelse at implementere. Andre vil blot kræve en mindre ændring. De central principper er tæt kundekontakt, hyppig test og simpelhed i implementeringen. Kontakten med kunden danner et startpunkt og et mål. Kunden er ikke bare den der skal betale for programmet og brugerne er ikke bare dem, der skal bruge det. Begge indgår aktivt og hyppigt i udviklingsprocessen. Et andet væsentligt princip er hyppig integration af kode. Integrationen skal ske sekventielt og ikke parallelt. På denne måde har systemet altid en problemfri og kørende version. Problemfri, fordi der ikke er nogle dele af softwaren der er integreret med andre. Således er det muligt at frigive en ny udgivelse, hver gang der er sket en integration med systemet. Side 21 af 115

22 Gruppe E2-214 Kollektivt ejet kode er et andet vigtigt princip. Herved forstås, at der ikke er nogen, der ejer en linie kode, men alle har mulighed for at ændre eller opdatere al kode. På denne måde opnår man på udviklingsholdet en kollektiv forståelse af arkitekturen, systemet og den underliggende teknologi. Idealistisk set burde programmørerne cirkulere rundt i teamet, således alle kommer til, at kode på alle dele af systemet. XP kræver dog også en vis disciplin. Eksempelvis kræver kodepraksis, at koden er selvdokumenterende. Dermed er yderligere dokumentation end selve koden principielt overflødig. Kodestandarder bør overholdes af alle involverede udviklere for, at opnå forståelig og ensformig kode. Side 22

23 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere 3.4 Brugervenlighed Begrebet brugervenlighed anvendes ofte I forbindelse med udviklingen af IT-løsninger, men ofte defineres begrebet kun meget vagt. I dette afsnit ønsker vi at definere, hvad vi forstår ved begrebet brugervenlighed, når vi refererer til det i resten af projektet. Afsnittet er skrevet udfra [ 23/05/02 samt [Molich 2000]. Hvorfor overhovedet beskæftige sig med brugervenlighed? Vi ønsker at udvikle et mere effektivt system end det, der anvendes i dag. Da brugervenlighed i høj grad er med til at forbedre samspillet mellem menneske og maskine, mener vi at det er en faktor, der ikke må undervurderes. Af yderligere fordele ved intuitivt opbyggede brugergrænseflader kan nævnes, at der kan spares tid på uddannelse, og flere brugere har umiddelbar mulighed for at benytte systemet. Der kan også afsættes færre ressourcer til support på systemet. Et brugervenligt design er med til at øge kundernes moral og motivation til at arbejde Den klassiske definition Rolf Molich definerer brugervenlighed på [ 25/05/02 til at være: Let at lære At noget er let at lære kan måles på indlæringstiden. Indlæringstiden: Den tid det tager brugere at lære at løse bestemte opgaver ved hjælp af systemet. Let at huske At noget er let at huske kan måles på genindlæringstiden. Genindlæringstid: Den tid det tager brugere, som har været væk fra systemet eller, som kun anvender det engang imellem, at løse bestemte opgaver. Effektivt at bruge Effektivitet: Den hastighed hvormed brugeren løser bestemte opgaver i forening med systemet. Effektiviteten afhænger bl.a. af svartid og fejlhyppighed og ikke mindst kvaliteten af fejlmeddelelser. Rart at bruge Subjektiv tilfredshed: Den tilfredshed som brugeren udtrykker i spørgeskemaer eller ved interviews. Ved udvikling af et brugervenligt IT-system må man afveje, hvilke af disse faktorer der er vigtigst i forhold til det pågældende projekt. Indlæring og genindlæring er eksempelvis meget vigtig i et system, som brugere kun anvender sjældent. Det kunne eksempelvis være et selvbetjeningssystem som en dankortautomat. Effektiviteten er derimod vigtigst i et system, som brugere anvender mange gange dagligt. Det kunne eksempelvis være et bogføringssystem. Side 23 af 115

24 Gruppe E Katastrofer Et andet mål for brugervenlighed i et system kan være antallet af "kritiske problemer" og "katastrofer". Der er tale om et kritisk problem i et system, hvis et eller flere af følgende kriterier er opfyldt: 1. Brugeren er ude af stand til at fortsætte sit arbejde uden at få hjælp fra en anden person 2. Brugeren føler, at systemets opførsel er stærkt irriterende eller irrationel. 3. Der er en kritisk forskel mellem det, som brugeren tror, at systemet gør, og det som systemet rent faktisk gør. Disse tre typer fejl kan findes under brugertests eller ved efterfølgende evaluering. En katastrofe optræder, når to brugere uafhængigt af hinanden støder på et kritisk problem. For at designe brugervenlige systemer, kan de fem "gyldne regler" også være en hjælp De fem gyldne regler 1. Kend brugerne Det er meget vigtigt at lære brugerne af systemet at kende. Nogle systemer har mange forskellige brugere, men her er det vigtigt at identificere de primære brugere af systemet. Ofte vil man som systemudvikler have en del kontakt med chefer og ledelsen, dem der skal betale for systemet, men det er ved kontakt med systemets brugere, at man får den nødvendige information og feedback. Af teknikker til dette kan nævnes interview, diskussion, eller man kan besøge brugerne på deres arbejdsplads og observere dem mens de arbejder. 2. Inddrag brugerne Tag typiske brugere med på råd lige fra projektets start. Typiske brugere har stor erfaring med hvad systemet skal kunne. Man skal ikke blot få brugere til at godkende et færdigt system, man skal få dem til at øse af deres erfaring under udviklingen af systemet. Hvis man arbejder sammen med de samme brugere gennem længere tid, risikerer man dog at de bliver eksperter, og ikke længere fungerer som realistiske brugere. En af de bedste metoder til inddragelse af brugerne er udvikling af prototyper med eksempler på realistiske skærmbilleder. Det er i høj grad med til at engagere brugerne, og det er lettere for dem at visualisere, hvordan systemet kommer til at fungere. Hvis brugerne kommer med kritik af en prototype, må man ikke være bange for at ændre på den eller helt kassere den 3. Afprøv og ret systemet Selv erfarne systemudviklere kan ikke forudsige hvor brugervenligt et system vil være. Afprøvning er derfor den eneste vej frem. Resultaterne af afprøvningen styrer det videre design. 4. Lær af andre Lad dig inspirere. Brugergrænseflader i fremmede systemer kan give en masse nyttig inspiration - om ikke andet så til at fastslå, hvordan man ikke vil gøre. Det vil ofte være en fordel at finde "forbilleder" - programmer der i funktion eller opbygning minder om ens eget. På denne måde kan man finde inspiration til mulige brugergrænseflader. Side 24

25 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere 5. Koordiner systemets dele Koordinering sikrer at du kan lave ændringer i de enkelte dele af brugergrænsefladen. Hvis afprøvningen af systemet medfører, at et ord i menuen må laves om, så sikrer koordineringen, at ordet også ændres i alle andre dele af systemet, f.eks. hjælp, dokumentation og fejlmeddelelser Gestaltlove Perceptionspsykologien beskæftiger sig med, hvordan vi opfatter helheder. Inden for denne gren af psykologien er man nået frem til en række såkaldte "gestaltlove 1, der beskriver hvordan man kan få oplysninger til at hænge sammen visuelt. Der er tre primære love. De betyder kort fortalt følgende:?? Loven om nærhed: Symboler anbragt nær hinanden opfattes som sammenhængende?? Loven om lukkethed: Symboler i samme "ramme" opfattes som sammenhængende?? Loven om lighed: Symboler der minder om hinanden opfattes som sammenhængende. Disse love kan anvendes til at designe brugergrænseflader, når man skal placere de forskellige elementer. Eksempelvis kan de anvendes ved placeringen af knapper, tekst og grafiske elementer. 3.5 Systemudviklingsfilosofi Dette afsnit omhandler en lille del af den filosofiske teori bag systemudvikling, som vi kan integrere med vores projekt. Systemudviklingsfilosofi er teoretisk meget omfattende, så vi har valgt at fremhæve de 3 grundlæggende tænkemåder; Hard, Soft og Dialectic systems thinking. Det er tre differentierede tænkemåder, som vi i et senere afsnit vil inddrage i forbindelse med beskrivelsen af projektudviklingen. Selvom disse tre tænkemåder er skrevet i metodeafsnittet, er de ikke deciderede metoder. De er nærmere ubevidste ideologiske regelsæt, der benyttes af udviklerne Hard Systems Thinking (HST) HST er en meget regelfast tænkemåde. At bruge HST betyder, at man ser alt som systemer, at alle systemer eksisterer, og at de kan analyseres og implementeres som et computerprogram. Det medfører, at man skal tænke meget abstrakt og se alle faktiske ting som systemer. Disse kan nedbrydes til mindre systemer, helt ned til de enkelte funktioner og elementer. Tesen er, at man først skal se hele det samlede system og retorisk spørge; hvad skal dette system kunne, når det er færdigt?. Svaret til dette skaber nye spørgsmål, som igen skal besvares og igen kan der opstå nye spørgsmål. Det kan fortsætte indtil man er på et niveau, hvor man kan besvare eller løse spørgsmålene med kendte programmérbare funktioner. Dette kaldes funktionel analyse og er effektivt, når der overvejes meget komplekse systemer. Efter analysen kan funktionerne sættes sammen til elementer eller mindre systemer og igen sættes sammen til et stort veldefineret, eksplicit og hierarkisk system. Denne metode gør det også nemt at vise data-flow mellem de enkelt elementer i systemet. 1 Gestalt = helhed Side 25 af 115

26 Gruppe E2-214 I bogen Computers in Context [Dahlbom et.al. 1993] sammenlignes dette med de matematiske og fysiske love og teorier, der gør det muligt at beskrive Jorden som et stort system, nedbrudt til og genopbygget fra de atomare partikler. Dette kan dog kun lade sig gøre, da HST ikke tager forbehold for eksempelvis æstetik, politik og kultur. Det vil sige mennesket, eller systemets bruger bliver meget passive med denne filosofi Soft Systems Thinking (SST) Med SST opstår der en ny systemopfattelse. Modsat HST er alle systemer ikke i forvejen fastlagte og eksplicitte. Systemet vil kun være et system inde i hovedet på den individuelle udvikler, og det er hans baggrund, oplevelser, interesser og uddannelse m.m. der spiller ind på vedkommendes opfattelse af systemet. Det vil sige, at hvis udviklerens opfattelse af verdenen omkring ham ændres, vil systemet også ændres. Systemets brugere spiller derfor en væsentlig rolle med SST. Det er vigtigt med SST, at alle individer i systemet har den samme opfattelse og fortolkning af et system. Når det er opfyldt, kan man begynde at lave en rationel analyse og efterfølgende udvikle et program. Programmet vil have brugerne i centrum, frem for HST der har programmet i centrum Dialectic System Thinking (DST) DST er baseret på ide om, at verden er i konstant forandring, og at man kun kan opfatte det ved at vide, hvad der forandres og hvorfor. På den måde kan man se modsætningerne og forskellene fra før og efter forandringen, samt forklare og forstå, hvorfor der er sket denne forandring. Det er netop her den nye viden og forståelse opstår. DST er let at bruge i et humanistisk, social og psykologisk system-sammenhæng, men bogen stiller selv spørgsmål til, om metoden overhovedet kan overføres til computersystemer: Since there are no actors or conflicts within a computer system, its only fair to question whether it makes sense to speak of contradictions within such a system [Dahlbom et.al. 1993] s Sammenligning af HST og SST Soft Systems Thinking Subjektivt System & sociologisk teori Fleksibel metode Fokus på organisatorisk problemløsning Analysen skal gøre systemet nemmere for brugeren. Organisatorisk produkt Systemet bliver kreativt og intuitivt Systemet kan komme med forskellige løsninger. Hard Systems Thinking Objektivt System og computervidenskabelig teori Fastlagt metode Fokus på teknisk problemløsning Analysen er videnskabelig og teknisk og systemet er domineret af analysen. Teknisk produkt. Systemet kommer med én korrekt løsning. Side 26

27 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere Med HST bliver organisationer og programmer opfattet som systemer med en overordnet funktion eller ide. Den meget tekniske analyse og problemløsning vil udmunde i et system, der er designet til optimal effektivitet og er præcis defineret på en måde, så systemet opfylder dets funktionalitet. Ulempen ved HST er, at brugerne ikke inddrages i analyse og udviklingsprocessen. SST vil derimod prøve at overføre fokus fra en generel, firkantet verdensopfattelse til en, der er mere individuel. SST henvender sig også til det humanistiske og sociologiske perspektiv i systemerne og prøver at inddrage disse. Hvilket vil resultere i et system, hvor brugerne har stor indflydelse på udviklingen og resultatet. Ulempen ved SST er, at produktet bliver et mindre effektivt system, samt at komplekse systemer og problemer bliver sværere at udvikle og designe. 3.6 Test Metodevalg Når man skal teste et system, er der mange forskellige faktorer, man skal overveje. Først og fremmest skal man overveje præcis, hvad det er man ønsker at teste. Man kan lave forskellige former for tests, der for eksempel er beregnet til at teste selve koden eller brugervenligheden. Man kunne også lave deciderede programtests for at teste selve koden. Vi har dog valgt ikke at gøre dette udfra den anskuelse, at dette semester i højere grad lægger vægt på interaktionen os og firmaet imellem. Hvis semestret i højere grad omhandlede kodning kunne man have lavet direkte kodetests. Derfor har vi valgt at koncentrere os om tests for brugervenlighed. Et tænke højt forsøg går ud på, at testpersonen udfører en række fastlagte opgaver alt imens han fortæller, hvilke overvejelser han gør sig. Det er meget vigtigt at registrere de ting, som testpersonen udtaler. Fordelen ved tænke højt forsøg i forhold til en række andre testmetoder er, at man får en række meget spontane overvejelser omkring det testede system. Når en testperson direkte fortæller sine tanker under testen, mener vi også, at der er mindre sandsynlighed for, at væsentlige informationer bliver glemt. For at lave en tænke højt undersøgelse, skal man udarbejde realistiske opgaver, som brugeren skal løse i det pågældende program. Man skal endvidere sørge for, at spørgsmålene dækker et så bredt aspekt af programmets funktioner som muligt. Det gælder altså om ikke kun at lave opgaver i funktioner, som man ved er programmets stærke sider. For at forhindre dette kunne man inspireret af XP skrive sine tests før man påbegynder programmeringen. Dette kunne gøres udfra usecases, som skal kunne udføres i det nye system. Man skal også opstille retningslinier for testens udførelse. Dette er især af betydning, når testen som i vores tilfælde udføres af de samme personer, som har udviklet det testede program. Eksempelvis kunne man forestille sig at en testleder, der selv har været med til at udvikle et system, vil have en tendens til at forsvare systemet. Derfor må man opstille nogle regler, som testlederen skal følge. Endvidere er faste retningslinier med til at give sammenlignelige resultater, og eventuelle resultatmæssige afvigelser må antages at skyldes programmet og ikke testen. Side 27 af 115

28 Gruppe E2-214 Når man kommer til udvælgelsen af deltagere i forsøget må man forsøge at få et repræsentativt udvalg af brugere. Her kan eksempelvis stilling og erfaring indgå i udvælgelsen. Man skal altså ikke udelukkende bruge erfarne eller uerfarne brugere men en blanding og gerne nogen på et mellemstadie. Det er vigtigt at testen ikke stilles op som en eksamenssituation, hvor testpersonerne føler, at det er dem der testes. Derfor bør man forsøge at etablere et afslappet testmiljø, der samtidig er så tæt som muligt på programmets realistiske anvendelsesområde. Testlederens opgave under selve forsøget er at sikre, at testpersonen ikke sidder fast i en bestemt opgave. Der kan kun gives hjælp, hvis det er yderst nødvendigt, og denne hjælp gives i form af ledetråde. Testlederen må altså ikke direkte hjælpe brugeren med at besvare spørgsmålet. Hvis brugeren stadig ikke kan løse opgaven, må testlederen vurdere, om det er nødvendigt at gå videre til næste spørgsmål. Vi har valgt at bruge disse retningslinier af flere grunde. På den ene side får vi mest ud af testen, når brugeren selv forsøger at løse opgaverne. Omvendt kan vi måske motivere testpersonen til at forsøge sig på en opgave lidt længere, hvis han får lidt hjælp. Dermed får vi sandsynligvis også en række interessante observationer omhandlende de problematiske dele af programmet. Man skal være opmærksom på, at lederen ikke ubevidst giver hjælp i situationer, hvor det ikke er nødvendigt, og at lederen ikke manipulerer testpersonen til at svare i en bestemt retning på nogle af spørgsmålene. Efter endt afprøvning er det vigtigt, at man bruger tid på at snakke med testpersonen for at få uddybet dennes opfattelse af systemet Andre testformer I det nedenstående afsnit vil vi gennemgå andre former for testmetoder. Vi vil lave en kort gennemgang af hver testform, hvor vi definerer formålet med testen samt fordele og ulemper ved testformen. Vi har udvalgt et par testformer, som vi mener kunne bruges i vores situation Konstruktiv interaktion Formålet med denne testform er, såvel som ved tænke højt test, at teste systemet for funktionalitet og hvorvidt det er intuitivt forståeligt. I sin grundform minder den konstruktive interaktion stort set om en normal tænke højt test. Der er det til forskel, at man ved konstruktiv interaktion i stedet for en testperson bruger to. Det er så meningen at de to testpersoner skal løse opgaverne i fællesskab. En af fordelene ved at benytte denne form for test er, at det i høj grad falder testpersonerne naturligt at tænke højt. Det betyder at hele testformen kan virke mere afslappet for testpersonerne da mange testpersoner tit vil føle, at det virker unaturligt at sidde og ytre deres tanker højt. En ulempe ved denne testform kan være, at de to brugere simpelthen ikke arbejder godt sammen og der opstår konflikter, som intet har med det system der testes at gøre. Man vil også kunne opleve, at testpersonerne ikke bryder sig om eventuelt at skulle vise over for kolleger at der er huller i deres viden. Endvidere er denne testform ikke nødvendigvis fordelagtig, hvis systemet ved almindelig brug skal bruges af enkeltpersoner. Side 28