Tema: Design og vurdering af et edbsystem i samarbejde med brugere. Synopsis:

Transkript

1 Datalogisk institut Informatik Fredrik Bajers Vej 7, bygning E Telephone: (45) Telefax: (45) Titel: Café Chic Tema: Design og vurdering af et edbsystem i samarbejde med brugere Projekt periode: INF2, 2006 Projekt gruppe: I201a Gruppe Medlemmer: Jesper Vinther Rødkjær Martin Jensen Michael Henning Juul Petersen Nikolaj Yde Frederiksen Nissanthen Thiruravichandran Thomas Knudsen Kristensen Vejleder: Michael Bach Pedersen Oplagstal: 8 Synopsis: Formålet med projektet var at undersøge hvordan vi kunne bruge udviklingsmetoden Extreme Programming til at udvikle et lagerstyringssystem, i samarbejde med Café Chic. Kravene til systemet blev formaliseret igennem kundens historier, som beskrev hvordan dele af systemet skulle interagere. Disse historier blev herefter fortolket til opgaver, som kunne implementeres i systemet. Efter implementeringen gennemførte vi en brugbarhedsevaluering, hvor vi blandt andet inddrog kunden og de fremtidige slutbrugere. Denne rapport beskriver de metoder som er blevet brugt til udarbejdelsen af projektet. Herunder beskrives fremgangsmåden og resultaterne. Vi laver en opsamling af de erfaringer vi har dannet os gennem forløbet, hvor vi beskriver de problemer vi stødte på og hvordan vi løste dem. Til sidst konkluderer vi, udfra de opstillede spørgsmål i problemformuleringen, at metoden Extreme Programming er et godt valg til at udvikle it-systemer i et tæt kundesamarbejde. Metoden er samtidig også et godt valg til vores udviklingsforløb, da ere at metodeværktøjerne er med til at understøtte et læringsprojekt. Sidetal: 117 Afsluttet den 30. maj 2006

2 2

3 Forord Vi vil først og fremmest gerne takke Jens Krohn for hans store engagement, samt Cafe Chic personalet for at have afsat tid til at deltage i udviklingsforløbet. Vi vil takke vores projektvejleder, Michael Bach Pedersen, for et konstruktivt samarbejde. Dette projekt er blevet udarbejdet under fjerde semester på informatikstudiet. Rapporten henvender sig til personer med indblik i udviklingsmetoden extreme Programming (Herefter XP) eller personer der gerne vil lære om denne metode. Det forventes at rapporten læses i kronologisk rækkefølge. Rapporten er opdelt i to dele. Første del er en metode- og procesbeskrivelse, hvor vi beskriver XP metoden, udviklingen og evalueringen. Den anden del er studiedelen, hvor vi beskriver hvilke erfaringer vi har gjort os gennem projektforløbet. Kildehenvisninger er angivet ved (forfatter(e), udgivelsesår). Litteraturlisten ndes bagerst i rapporten. 3

4 4

5 Indhold 1 Indledning Indledning Problemformulering Afgrænsning Case beskrivelse Metode Systemudvikling med XP De re værdier De re aktiviteter De re faktorer Fremgangsmåde Aeveringer Forberedelse til aeveringer Historier Udviklingsmiljø Aevering Aevering Teknisk beskrivelse af det færdige system Overordnet arkitektur Beskrivelse af brugergrænseadelaget Beskrivelse af persistenslaget Evaluering Mål Metode Denition af brugbarhed Kognitiv gennemgang Mål Metode Resultat Pilottest Mål Metode Resultat Brugbarhedstest Mål

6 4.5.2 Metode Resultat Interview Mål Metode Resultat Opsummering Erfaringsopsamling Indledning Foranalyse Fremgangsmåde Problemer og løsninger aevering Fremgangsmåde Problemer og løsninger aevering Fremgangsmåde Problemer og løsninger Samarbejde Fremgangsmåde Problemer og løsninger Evaluering Fremgangsmåde Problemer og løsninger Opsamling i forhold til XPs værdier Kommunikation Enkelthed Feedback Mod Opsamling i forhold til XPs aktiviteter Programmering Test Lydhørhed Design Diskussion Metodekritik Samarbejde med brugeren Udvikling af programmel Skiftende krav Evaluering på slutbrugere og kunde Valg af kunderepræsentant Sammenfatning Konklusion 85 8 Perspektivering 89 6

7 9 Bilag Indhold af CD-ROM Historier Historie Historie Historie Historie Historie Historie Historie Historie Historie Historie Historie Historie Historie Historie Dagbog Interview spørgsmål Introduktion til brugbarhedstest Opgaver til brugbarhedstests Demogrask spørgeskema Essays Kunden i XP ikke altid kompetent Nedprioritering af teamroller i XP Kunden og slutbrugeren Informatik Cafe Chic Lager

8 Informatik Cafe Chic Lager

9

10 1.1. INDLEDNING 1.1 Indledning I foregående semestre har vi arbejdet med traditionelle udviklingsmetoder som bland andet Struktureret Program-Udvikling, der er en delvis modiceret udgave af den klassiske vandfaldsmodel (Biering-Sørensen et al., 2002). Udviklingsfaserne i vandfaldsmodellen er oprindeligt tilsigtet til at skulle følges sekventielt. Således kan udviklerne og kunden forholdsvist tidligt producere en plan over projektforløbet, og derudfra lave aftaler, skrive kontrakter, fastsætte pris og leveringsdato, osv. Denne ikke-iterative udviklingsproces har vist sig at være en problematisk aære i softwareudvikling, da estimerede tidsplaner og budgetter ofte overskrides (Marqvadsen, 2004). Der er varianter af metoden, som tillader iterationer, således at omskrivning af eksempelvis kravsspecikationen tillades. Dette nødvendiggøres idet at det ikke er realistisk at denere alle krav til et stykke software i så tidligt et stadie, da nye krav tilføjes og andre ændres, og fordi nye eektiviserende muligheder kan opstå (Marqvadsen, 2004). Da verden omkring projektet og projektgruppen ikke er statisk, vil man med disse metoder have mulighed for at anvende nye teknologier og imødegå nye krav. Som et alternativ til vandfaldsmodellen er der blevet udviklet andre metoder til udvikling af software. En gren af disse er kendt som agile metoder. Det principielle grundlag for agil udvikling, beskrevet i det agile manifest, er det tætte samarbejde mellem udvikler og kunde, der bl.a. betyder at man foreskriver at kunden skal præsenteres for fungerende software tidligt og hyppigt i udviklingsforløbet (Beck et al., 2001). Desuden opfordrer metoden til et dagligt samarbejde mellem udvikler og kunde, hvilket bl.a. medfører at ændringer af krav og tilføjelser af nye krav lettere kan håndteres, og ligefrem opfordres, også sent i forløbet. I de agile metoder ser man ikke software udvikling som en rationel proces, hvor alt kan modelleres og dokumenteres fra starten. Det er især på dette punkt at de agile metoder adskiller sig fra de traditionelle. En af de mest anvendte agile metoder er Extreme Programming (XP), der adskiller sig fra de udviklingsmetoder vi tidligere har stiftet bekendtskab med. Metoden forskriver at kunden inddrages gennem hele processen, og der skal fokuseres på at opfylde de krav kunden løbende stiller til projektet, fremfor at fokusere på dokumentation (f.eks. gennemarbejdede analyser af problem og anvendelsesområde som ses i metoder såsom Objektorienteret Analyse & Design (Mathiassen et al., 2001)). XP er en meget løs metode, uden faste rammer og aktiviteter, men fokuserer på kundetilfredshed i form af hyppige præsentationer af fungerende software. Den ligger desuden langt fra de traditionelle metoder, idet den fokuserer på programmet som det vigtigste produkt og ikke dokumentationen. På dette semester er temaet Design og evaluering af et edb-system i samarbejde med brugere. På baggrund af dette tema, semestrets undervisning i agile udviklingsmetoder og vores erfaringer fra tidligere projekter har vi besluttet os for at se nærmere på udvikling med XP, hvilket leder os frem til problemformuleringen. Informatik Cafe Chic Lager

11 KAPITEL 1. INDLEDNING 1.2 Problemformulering Med udgangspunkt i metoden Extreme Programming vil vi, i samarbejde med en café, udvikle et lagerstyringssystem til at understøtte de ansattes arbejde i dagligdagen. Dette leder os frem til følgende spørgsmål. Hvordan kan vi benytte Extreme Programming (XP) i vores udviklingsforløb? Herunder behandles: Hvordan kan XP støtte samarbejdet mellem udvikler og bruger? Vi vil afprøve XP metodens værktøjer og vurdere hvordan de kan benyttes i vores projekt, samt holde dem op mod tidligere erfaringer med andre metoder. Vi vil afslutningsvis interviewe kunden for at vurdere vores samarbejde. Hvordan kan vi tilstræbe at det endelige produkt lever op til brugerens forventninger? Vi vil undersøge hvordan XPs inddragelse af brugeren kan forme projektets, og systemets, udvikling. Vi vil endvidere vurdere det færdige system ved hjælp af en brugbarhedsevaluering, hvor vi inddrager faktiske slutbrugere. 1.3 Afgrænsning Under udviklingen af det nye system er det vores plan at gennemløbe det antal iterationer som omfanget af vores projektforløb tillader. Vores fokus ligger på projektet som en læringsproces og selve programmet er derfor ikke den primære del. Der er ydermere på dette semester hovedsageligt fokus på metodedelen, dvs. samarbejdet mellem kunde og udvikler, og det er også her vi lægger hovedvægten. Vi vil derfor ikke udvikle et fuldt funktionelt program, men tilstræber i stedet et dybdegående samarbejde med brugeren gennem de antal iterationer, der udføres. Efter sidste aevering vil vi foretage en grundig brugbarhedsevaluering af systemet, hvor vi vil inddrage de potentielle slutbrugere. Ydermere vil vi evaluere brugersamarbejdet med et afsluttende interview med vores kunde. Med hensyn til vores samarbejde med kunden er der i metoden XP fokus på at kunden altid er fysisk til stede hos udviklingsholdet (Se afsnit 2.1). Men fordi at dette er et universitetsprojekt, er det ikke praktisk muligt at udforske denne del fuldt ud. Vi vil derfor basere samarbejdet på hyppige møder samt kommunikation via telefonsamtaler og . Informatik Cafe Chic Lager

12 1.4. CASE BESKRIVELSE 1.4 Case beskrivelse I forbindelse med dette semesters projekt lægger temaet vægt på samarbejde med brugere, hvorfor et valg af case skal repræsentere dette. Valget faldt på en nyopstartet café i Aalborg, Café Chic. Valget begrundes i, at ejerne var bekendte af et gruppemedlem. Ydermere er caféen i færd med at få udviklet et nyt kasseapparatssystem og er derfor open minded i forhold til en udviklingsproces, hvorfor det er oplagt at anvende XP som udviklingsmetode. Idet at kunden er positiv og engageret i projektet betyder det at vi forhåbentlig kan opnå et godt samarbejde, der i sidste ende vil kunne udmunde i et godt produkt. Fokus indenfor XP er netop det tætte samarbejde med kunden, men som universitetsstuderende kan det være besværligt at sikre et tæt samarbejde med en kunde gennem hele semestret, da vi samtidig studerer og ikke udvikler et færdigt produkt. Men netop det at kunden er en bekendt af et gruppemedlem giver os en relativ sikkerhed for et udbytterigt samarbejde. Igennem et initialiserende interview blev vi opmærksomme på mange af deres krav og k samtidig et større indblik i denne tydeligvis konkurrenceprægede verden. Café Chic i Aalborg er den anden café for ejerne, som består af de to brødre Jens og Rasmus Krohn, samt Jens Jensen. Det er Jens Krohn der under projektforløbet vil være den primære kontakt mellem projektgruppen og Café Chic. De to brødre, som står for den daglige drift, har igennem de sidste 6 år indenfor branchen erhvervet sig et bredt kendskab samt ekspertise indenfor branchen. Deres hovedfokus ligger på tre ting, nemlig øl, kae og mad. De har professionelle kokke ansat for at hæve standarden i køkkenet. De lægger meget stor vægt på friske og gode råvarer, således at kunderne opnår en god standard i forhold til café-miljøet, der normalt ikke tilbyder nere spise. Med hensyn til øl og kae, ligger vægten på et stort udvalg af forskellige typer. De har i den forbindelse forskellige arrangementer som øl- og kaesmagning og giver på den måde øl- og kaeentusiaster mulighed for at prøvesmage mange forskellige typer. De mener at det er vigtigt at dierentiere sig fra andre på markedet, for netop at kunne opretholde en stabil og konkurrencedygtig virksomhed. Netop derfor vil de nu sætte fokus på deres it-systemer, da det på nuværende tidspunkt udmunder sig i at hvert system kører på en separat computer. Det være sig f.eks. overvågning, musik, kasseapparat og lagersystem. Dette gør at der mange gange kan opstå forvirring i anvendelsen, samt muligheder for fejlbetjening. Der er imidlertid mange produkter på markedet, men der ndes intet der udbyder en samlet løsning på én maskine, hvilket i øvrigt er deres primære præference. Opgaven bliver derfor for os at udvikle et lagerstyringssystem til at holde styr på deres store udvalg af produkter. Herunder skal hovedvægten ligge på at administrere lageret af øl, vand og spiritus, sammen med bar-lageret. Informatik Cafe Chic Lager

13

14 2.1. SYSTEMUDVIKLING MED XP 2.1 Systemudvikling med XP I dette kapitel beskrives udviklingsmetoden Extreme Programming (XP), samt de værdier og akiviteter som metoden foreskriver. Ydermere beskriver vi hvilke tilpasninger det har været påkrævet at tilføre metoden til netop dette udviklingsforløb. Hvorfor hedder det Extreme Programming? Fordi metoden tager nogle af de vigtigste, mest afprøvede og bedste ting fra de traditionelle udviklingsmetoder og bruger dem i det ekstreme. Hvis f.eks. det at teste er godt, så siger XP: Så lad os teste ekstremt. Det gør vi ved at nde de steder hvor vi mener en testcase kan betale sig og så lade både udviklerne udføre unittests og kunden skrive testcases dertil. Hvis kode reviews er gode, så lad os reviewe hele tiden. Dette ligger implicit i XP ved at man sidder og koder i par, da den som sidder ved tastaturet ofte har øje for koden i hånden og den som kigger over skulderen ofte vil have en anden vinkel til tingene og derfor større overskud til at opdage fejl mens man koder. To hjerner er bedre end en og i XP er al kode gennemset og testet af mindst to personer. Hvis design er godt, så lad os gøre det til et dagligt gøremål for udviklerne ved at lave refaktorering hele tiden. Her skal vi gøre brug af de re værdier i XP. (Se kapitel 2.2 på modstående side) Hvis enkelhed er godt, så lad os alle bære et ansvar for altid at sikre at systemet, i forhold til dets nuværende funktionalitet, altid har et enkelt design. Hvis arkitektur er vigtigt, så lad os alle arbejde på at forbedre den hele tiden. Her benytter XP sig af en metafor til at skabe en fælles forståelse af systemets opbygning og interne sammenhæng. Metaforen gør det muligt for udviklerne og kunden at diskutere systemet i de samme termer, uden kunden behøver at kende noget til programmering. Et eksempel på en metafor, der kunne have været anvendt i XP, er at Microsoft Windows er opbygget som et skrivebord. Hvis korte iterationer er gode, så lad os lave dem ekstremt korte. Planlægning i XP foregår som en dialog mellem udviklerne og kunden. Beslutninger, der omhandler et bestemt arbejdsområde, skal tages af de personer der k- ender til området. Således er det kunden, der producerer og prioriterer historier, mens det er udviklerne der ud fra kundens kriterier bedømmer hvor meget der kan implementeres til en given deadline. Hvis integrationstests er vigtige, så lad os integrere og teste ere gange om dagen. XP gør i sin grundform op med de traditionelle paradigmer ved at afskære stort set hele analysedelen og dokumentationen. XP fokuserer i stedet på selve systemet og ser kodning som et håndværk. Koden ses dermed som direkte erstatning for dokumentationen. Informatik Cafe Chic Lager

15 KAPITEL 2. METODE XP ser dog ikke sig selv som løsningen på alt. En vigtig del er troen fra såvel udviklerne som kunden for at projektet skal lykkes. Dette opnås med gensidig tillid mellem kunde og udvikler samt tillid til værktøjer og processer. XP er derfor meget åben i forhold til indførelse af værktøjer og processer som er med til at underbygge denne tillid. 2.2 De re værdier XP er opbygget om de re værdier kommunikation, enkelthed, feedback og mod. Med disse re værdier bliver det muligt at mindske problemer og pris, sørge for at kunden får det som kunden gerne vil have og at kunden samtidig får det bedst mulige resultat. For at forklare dette beskrives de re værdier lidt nærmere: Kommunikation De problemer der kan opstå gennem et udviklingsforløb, vil ifølge Kent Beck ofte kunne føres tilbage til ingen eller dårlig kommunikation (Beck, 2002). Dette kan være indbyrdes i udviklingsgruppen, men ofte mellem udviklere og kunde. For at undgå ingen eller dårlig kommunikation har XP indført en række arbejdsvaner og værktøjer, som ikke vil være mulige uden kommunikation. Enkelthed For at holde koden så enkel som muligt, skal der fokuseres på at lave det kode der skal bruges, og ikke tænke på hvad der måske skal bruges senere. "Det er bedre at gøre noget enkelt i dag og så betale lidt mere i morgen for at ændre det, hvis det bliver nødvendigt, end at gøre noget mere indviklet i dag, som der måske alligevel aldrig bliver brug for."(beck, 2002) Feedback Inden en programdel kodes, skal der skrives en testcase, som fortæller udvikleren hvornår koden kan lige præcist det som der ønskes af koden. Derudover er det også vigtigt at kunden får feedback fra udviklingsgruppen, så kunden kan fortælle om udviklingen går i den rigtige retning. Mod Nogle gange kan udviklere sidde fast i noget kode, hvor det ikke rigtigt er muligt at komme videre. Her skal udvikleren have modet til at smide koden ud og starte forfra. Derudover skal udvikleren have modet til at ændre i systemets struktur, for at gøre det mindre komplekst. Informatik Cafe Chic Lager

16 2.3. DE FIRE AKTIVITETER 2.3 De re aktiviteter Udover de re værdier, er der ifølge XP også brug for re aktiviteter. Disse skal bruges for at det er muligt at udvikle et system. De re aktiviteter er: Kodning Koden er den vigtigste del i udviklingen af et system og er hvor XP virkelig skiller sig ud fra de traditionelle paradigmer. Kode gør som det er programmeret til, og kan derfor ikke misforstås, i modsætning til forklaringer. Hvis du har en idé og forklarer den til mig, kan jeg nemt risikere at misforstå, hvad du mener. Men hvis vi koder det sammen, kan jeg ud fra logikken i din kode se, præcist hvad du mener. (Beck, 2002). Dette er også en af grundene til at udviklingen foregår i par. Test Ifølge de engelske losoer Locke, Berkeley og Hume, vil alt der ikke kan måles, ikke eksistere. (Beck, 2002). Dette gælder ifølge XP også for kode. Derfor opstiller XP også et krav om at alt skal kunne testes. XP foreskriver at man skriver test cases inden man koder, dette gøres både af kunden og udviklerne. Kunden skriver test cases ud fra historierne og udviklerne skriver unit tests. Test cases i XP skal være velafgrænsede og automatiske. Lydhørhed For at kunne teste om systemet kan hvad der er brug for, skal udviklerne kende disse krav. Dette sker ved at være lydhøre overfor kunden. På samme måde skal kunden også lytte til udviklerne, som kan beskrive sværhedsgraden i de forskellige dele. Design Ved design menes der at skabe en struktur, som kan organisere systemets logik. Ved et godt design vil en ændring et sted i systemet, ikke kræve ændringer andre steder og gør det samtidig muligt at udvide enkelte dele af systemet. Det bliver sikret at hver del af systemet kun hører til et sted, og anbringer metoder i nærheden af det data der arbejdes på. "Man koder altså, for hvis man ikke koder, har man ikke lavet noget. Man tester, for hvis man ikke tester, ved man ikke, hvornår man er færdig med at kode. Man lytter, for hvis man ikke lytter, ved man ikke hvad man skal kode, eller hvad man skal teste. Og man designer for at kunne vedblive med at kode, teste og lytte i det uendelige"(beck, 2002) Informatik Cafe Chic Lager

17 KAPITEL 2. METODE 2.4 De re faktorer XP indeholder yderligere et sæt faktorer der skal overvejes for at får styr på et projekt. Omkostninger Hvis der er for mange penge på spil, kan det skabe problemer. Omvendt er det heller ikke hensigtsmæssigt med for få, da det vil kunne resultere at udviklerne ikke kan leve op til kundens problemstilling (Beck, 2002). Tid Med hensyn til tid, kan det være positivt med mere tid inden aevering da det kan være med til at højne kvaliteten. Dog opnås bedre resultater med feedback på et kørende system, så for meget tid kan også være skadeligt. For lidt tid kan resultere i ringere kvalitet, mindre omfang og i sidste ende høje omkostninger (Beck, 2002). Kvalitet Ved at slække på kvaliteten, kan der opnås kortsigtede fordele for udviklerne, hvilket vil kunne resultere i store omkostninger på ere sider - menneskelige, foretningsmæssige og tekniske (Beck, 2002). Omfang Når der skæres ned på omfanget, giver det mulighed for at hæve kvaliteten, forudsat at kundens problemstilling stadig bliver overholdt. En anden mulighed er at der bliver mulighed for at levere systemet før tid eller til en billigere pris end først antaget (Beck, 2002). Kunden får muligheden for at justere tre af de re faktorer. Problemet kan dog i mange tilfælde være at forklare kunden hvorfor denne ikke kan justere på alle re. Et eksempel derpå kan være, at kunden beder udvikleren om at være færdig med en række krav indenfor en hvis tid, med de folk der er til rådighed og dertil må der heller ikke gåes på kompromis med kvaliteten. Det der netop vil ske i dette tilfælde er, at kvaliteten bliver derefter. Ifølge XP arbejder udviklere ikke godt under stress og samtidig betyder det også at tidsestimaterne skrider (Beck, 2002). Historier Igennem udviklingsforløbet skal en række procedurer gennemføres. Det er b- landt andet historier og aeveringer. Historier skrives af kunden og er en kort beskrivelse af hvilke problemer systemet skal kunne løse. En historie er dermed XPs kravspecikation, da de bruges til at fastsætte systemets funktionalitet. historier kan blive store opgaver og derfor opdeles de i mindre opgaver. Dette gøres for at forenkle implementeringen. Rækkefølgen hvorved de forskellige opgaver skal implementeres bestemmes af kunden. Et eksempel på en historie til Microsoft Windows kunne være: Når jeg skal slette en l trækker jeg den hen på skraldespanden, hvor den bliver liggende, indtil jeg tømmer skraldespanden. Informatik Cafe Chic Lager

18 2.5. FREMGANGSMÅDE Aeveringer En aevering er implementering af en eller ere historier til en funktionel del af et system. Det er dog et krav at der skal være en sammenhæng imellem de historier som implementeres, så det bliver et helt system. Det er op til kunden at bestemme hvilke historier der skal med i hver aevering, hvilket der sammen med mange aeveringer, sikrer at kunden får det ønskede resultat. Det er vigtigt at aeveringerne ikke indeholder mere eller mindre end det kunden har bedt om. Planlægning og belastningsfaktor Når man som udvikler tager et ansvar for en opgave skal den enkelte lave et estimat af det antal udviklingstimer det vil tage at løse opgaven. Denne proces skal foretages af alle udviklere, og der tages ikke hensyn til parprogrammering. Det er her ikke kun programmeringstiden der indregnes, men ligeledes den tid der tales med kunden, møder og så videre. Det er samtidig vigtigt at der ikke er nogle udviklere der påtager sig for store opgaver, så der ikke er tid til at hjælpe de andre. Skulle det ske alligevel, er det nødvendigt at lave en udbalancering. Det foregår på den måde, at hver udvikler regner sine opgaverestimater sammen og ganger dem med belastningsfaktoren. De udviklere der har taget for mange opgaver, må således uddelegere nogle af opgaverne til andre. Det samlede antal timer der beregnes kan således udnyttes til at fastlægge tidsbelastningen til de efterfølgende iterationer. 2.5 Fremgangsmåde I forbindelse med en udviklingsmetode som f.eks. XP, er der visse forholdsregler vi som studerende er nødt til at tage os. Vi bliver i visse tilfælde nødt til at tilpasse metoden til et universitetsforløb da metoden oprindeligt er tiltænkt brug i industrien. Dette kræver at metoden skræddersyes til vores projektforløb. XP er på sin vis en sammensmeltning af diverse metodeværktøjer, der alle er afprøvet i erhvervsmæssige sammenhænge. Princippet kundetilstedeværelse kan berige et projekt, ved bl.a. at foretage afklaringer for udviklerne. Beklageligvis er det som studerende ikke muligt at udføre denne del direkte, da vi som oftest er optaget af forelæsninger og andre aktiviteter. Samtidig er det svært i studiesammenhæng at nde en kunde som er ligeså engageret i et læringsprojekt som hvis det havde været et reelt projekt. Vi er som følge deraf nødt til at opbygge et tæt samarbejde med kunden, inden for nogle rammer der passer os såvel som dem. Det er vigtigt for metodens virkning at vi bibeholder en stabil kontakt, der sikrer en konsistens i udviklingen og vericerer princippet brugerinddragelse. I vores tilfælde løser vi problemet ved at benytte historier, som en af de grundlæggende kommunikationsmetoder. Kunden får ved starten af hver iteration udleveret papirer som skal udfyldes og leveres tilbage til udviklerne. Skulle der forelægge tvivl af enhver art, tager vi kontakt til kunden og får udbedret tvivlen. Dog er det ligeledes en nødvendighed at kunden er i stand til at udfylde papirerne med korrekt fokus, dvs. at det vi får tilbage, rent praktisk kan omformes til krav til systemet og herefter imple- Informatik Cafe Chic Lager

19 KAPITEL 2. METODE menteres. Derfor har vi som et af de første skridt afholdt et møde med kunden og diskuteret hvordan han beskriver historierne på en hensigtsmæssig måde. At det skal være på et meget lavt niveau, der skridt for skridt beskriver den måde hvorpå vedkommende rent faktisk vil kunne forestille sig at skulle interagere med systemet. Vi er hele tiden opmærksomme på det faktum at det er kunden der skal stille kravene og at disse ikke må påvirkes af os som udviklere, da vi ellers kan risikere at produktet afviger fra kundens egentlige krav. Vi har som udviklere den tekniske og faglige indsigt til at kunne rådgive kunden i de krav kunden fremstiller. XP lægger op til at eksperimentere med forskellige fremgangsmåder. Hvis noget virker tiltalende, så brug det (Beck, 2002). Derfor har vi som udviklere store muligheder for at tænke innovativt og udforme metoden så den lige netop passer til os som studerende. Blandt andet siger metoden at man bør programmere i par og i samme rum, dette punkt har vi til tider valgt at modicere lidt. Vi har stadig siddet i samme rum, men har brugt en projektor for at involvere alle gruppemedlemmer i processen. På den måde mener vi at kunne skabe en berigende dialog i gruppen samtidig med den egentlige programmering tager sted. Samtidig sikrer vi at alle får en forståelse af selve udviklingsværktøjet. Ydermere bliver systemet ikke delt op i mindre partitioner, således opnås en jævnbyrdig forståelse af koden. Denne fremgangsmåde, en mere ekstrem grad af parprogrammering om man vil, er dog mere tidskrævende end hvis vi praktiserede parprogrammering, men vi vurderer at det er acceptabelt da vi samtidig lægger stor fokus på projektet som værende et læringsredskab. Dette grunder i tidligere erfaringer hvor problemet ofte består i at når implementeringsopgaver uddelegeres, ender det som regel med at kun enkelte fra gruppen kommer til at fordybe sig i koden. Informatik Cafe Chic Lager

20 2.5. FREMGANGSMÅDE Informatik Cafe Chic Lager

21

22 3.1. FORBEREDELSE TIL AFLEVERINGER I dette kapitel vil vi uddybe hvordan vi kommer frem til de forskellige programaeveringer, hvorledes vi fortolker brugerhistorierne, samt en beskrivelse af de endelige aeveringer. Ydermere vil vi fremstille en teknisk beskrivelse af det færdige system. 3.1 Forberedelse til aeveringer Under forberedelsen af aeveringer kigger vi på de krav vi har opstillet ud fra kundens brugerhistorier og herudfra udarbejder vi de enkelte underopgaver. Inden første iteration er der også overvejelser omkring udviklingssprog og -miljø. Dette skal være på plads inden vi begynder på første aevering Historier Igennem historier, som tidligere beskrevet, kommer vi frem til nogle krav som derefter skal implementeres i systemet. Ud fra en historie fortolker vi i fællesskab de nye krav og stiller dem op i nogle underopgaver. På den måde får vi stillet kravene op i nogle punkter der gør det lettere for os som udviklere at overskue og dermed gå videre til implementeringen Udviklingsmiljø Vi udvikler programmet i C# da det har meget til fælles med Java, som vi allerede har erfaringer med. Da vi desuden mener at det er vigtigt at opnå erfaringer i C#, vælger vi dette frem for Java. Vi bruger udviklingsværktøjet Microsoft Visual Studio 2005, da det virker nemt at gå til, især i forbindelse med udvikling af graske brugergrænseader. Visual Studio implementerer i høj grad drag-and-drop udvikling, især i brugergrænseadedesign, hvilket bevirker at man hurtigt har et program kunden kan interagere med og give feedback på. Dette gør det til et ideelt valg sammen med XP hvor man hurtigt vil have kørende programmel. 3.2 Aevering 1 Da det er første gang gruppen udvikler efter denne metode, er der nogle ting som kan være svære for os at estimere. For det første har vi nogle problemer med at give et estimat af tidskrav. Vi har ikke nogle forudsætninger for at vide hvor lang tid de forskellige iterationer vil tage os. Da vi ingen tidligere erfaring har med XPs værktøjer, som for eksempel udførelse af historier, gør det estimeringen af tid besværlig. Udviklingsmiljøet og programmeringssproget er også nyt for os og programmeringserfaringen er derfor på dette stadie minimal. Vi vil udvikle et system som skal understøtte lagerstyringen af Café Chic, det værende sig i både de ansattes dagligdagsrutiner samt ejerens styring af lagerbeholdningen. Det er derfor vigtigt at vi har øje for de rutiner og arbejdsgange Café Chic har med at styre lageret. Informatik Cafe Chic Lager

23 KAPITEL 3. AFLEVERINGER I samarbejde med kunden udarbejder vi derfor et skema over hvordan funktionerne i systemet kan se ud (Se eksempel på brugerhistorie 3.1). Hovedfokus er herefter at vi i fællesskab med kunden skal udvikle et program som understøtter eller forbedrer lagerstyringen, og at de ansatte har let ved at benytte systemet uden at skulle omstille sig betydeligt. Figur 3.1: Her ses kundens beskrivelse af hoved- og undergrupper Den første aevering beskriver hvorledes kunden ønsker at registrere de forskellige varer i hovedgrupper og undergrupper. Derudover en mere detaljeret beskrivelse af hvordan de forskellige varer ønskes registreret i selve systemet, i forhold til et varelager i baren, samt et fast varelager. Herunder lister vi nogle af punkterne fra kundens historier, efterfølgende nedbrudt til de krav vi benytter i implementeringen. Til den første implementeringen benytter vi os af de re første historier kunden har udarbejdet (Se 9.2 på side 97). Historie 1: Kunden ønsker at det er muligt at man kan se hvilke varer der er oprettet i systemet. Herunder skal der kunne registreres følgende oplysninger omkring en vare. Navn Antal på lager Antal i kolli Leverandør Minimum for lavsæson Informatik Cafe Chic Lager

24 3.2. AFLEVERING 1 Minimum for højsæson Hovedgruppe Undergruppe Varerne skal være inddelt i hovedgrupper og undergrupper, for eksempel skal varen Heineken være under hovedgruppen Øl og undergruppen Udenlandsk aske. Historie 2: Kunden ønsker at de oprettede varer skal kunne redigeres. Det vil sige at det skal være muligt, foruden at oprette, at redigere oprettede varer samt slette oprettede varer. Disse funktioner skal være tilgængelige sammen med en liste over eksisterende varer i systemet. Historie 3: Kunden ønsker at det skal være muligt at se en liste over de oprettede leverandører i systemet. Følgende informationer skal være registreret om en leverandør. Navn Adresse Telefonnummer Noter Historie 4: Kunden ønsker at det skal være muligt, foruden at se en liste over de oprettede leverandører, at tilføje, redigere og slette leverandører. Disse funktioner skal være tilgængelige sammen med en liste over eksisterende leverandører i systemet. Vi formulerer således i fællesskab kravene til vores system ud fra den første historie og kommer frem til følgende underopgaver der skal hjælpe os i gang med implementeringen. Vis en liste over hovedgrupper. Der skal kunne oprettes, redigeres og slettes. Herunder skal der tages højde for et persistenslag. Vil vi gemme vores data i en l, eller database? Vi vælger et bruge en database der bender sig online, da der er gode backup muligheder og fordi vi kan tilgå den uanset anvendelsessted. Vi vurderer at dette, især de gode backupmuligheder, er hensigtsmæssigt i forhold til et lagerstyringssystem. Vis en liste over undergrupper. Der skal ligeledes kunne oprettes, redigeres og slettes. Derudover skal undergruppen tilknyttes hovedgruppen, således at når man vælger en hovedgruppe, vises den korresponderende undergruppe. Vis en liste over varer. Der skal kunne oprettes, redigeres og slettes varer. Varer skal ligeledes knyttes til den korresponderende undergruppe, der så er tilknyttet den korresponderende hovedgruppe. Vis en liste over leverandører. Disse skal kunne oprettes, redigeres og slettes. Informatik Cafe Chic Lager

25 KAPITEL 3. AFLEVERINGER Fastlægge en brugergrænseadestruktur som gør sig gældende igennem hele systemet. Kravene er nu på plads og vi kan fortsætte med udviklingen af selve systemet. Til at starte med har vi som nævnt svært ved at vurdere tidshorisonten for implementeringen af første aevering. Ifølge XP skal vi notere den tid vi bruger på de forskellige dele af systemet, men dette punkt vælger vi at udsætte indtil vi er fortrolige med udviklingsplatformen og især dennes samarbejde med en database. På denne måde indgår vi i et forløb hvor udviklingen er præget af forsøg og leg med koden. Vi har allerede deneret kravene, så efterhånden som vi forsøger os frem og vænner os til Visual Studio, begynder vi at tage fat på nogle af de funktioner der skal repræsenteres i det fremtidige system. Formålet på dette stadie er ikke at lave den første aevering, men netop at blive mere fortrolige med udviklingsmiljøet. Da vi har brugt et par uger sideløbende med forelæsninger og andet, føler vi os klar til at gå i gang med første aevering. Vi smider derfor hele koden væk og starter forfra, selvom store dele kunne være brugbar. Vi bliver enige om at det er vigtigt at vi nu fokuserer direkte på systemet til kunden. Nu har vi også mulighed for at begynde at holde styr på hvor meget tid der bliver brugt på udviklingen af første aevering. Informatik Cafe Chic Lager

26 3.2. AFLEVERING 1 Vi starter derfor på at designe brugergrænseaden i systemet. Her kommer vores nye udviklingsplatform os til gode, fordi at det er hurtigt og simpelt at redigere brugergrænseaden. De første krav indebærer registreringen af varer, hvilket er den centrale del af systemet. Disse bliver udgangspunktet for udviklingen af brugergrænseaden. Kunden har udtrykt at hovedgrupper og undergrupper skal kunne ses på samme skærm og der skal så være en knap der kan vise de varer som tilhører de respektive grupper (Se gur 3.2). Figur 3.2: Screenshot af Vare funktionen Som det er illustreret på billedet, er de to gruppetyper placeret ved siden af hinanden, således at der er et overblik over de valgte grupper. Det er næsten en direkte grask fortolkning af kundens forklaring (Se gur 3.1) Først når undergruppen er valgt har man muligheden for at trykke på knappen vis varer for så at blive ført videre til en skærm der repræsenterer varerne til den valgte undergruppe. Under denne er det så muligt at oprette, redigere og slette varer. I den fjerde historie i første aevering ønsker kunden at det skal være muligt at se en liste over de registrerede leverandører. Vi begynder derfor at tænke lidt over hvordan vi ønsker at opbygge mulighederne for at navigere rundt til de forskellige funktioner i systemet. Vi diskuterer mulighederne for at lave en slags web lignende menu med links der kan sende brugeren rundt i systemet. Vi bliver dog enige om at det ville være ideelt at kunne navigere i systemet ved hjælp af faneblade (Se gur 3.3). På den måde har brugeren hele tiden mulighed for at se hvilke muligheder han har og hurtigt navigere rundt mellem de større dele af programmet. Denne funktion underbygger også den mulighed at skifte mellem fanerne, selvom brugeren ikke er færdig med en aktivitet, og så vende tilbage Informatik Cafe Chic Lager

27 KAPITEL 3. AFLEVERINGER for at færdiggøre den. Figur 3.3: Screenshot af faneblade Da vi nu har muligheden for at navigere rundt mellem forskellige funktioner i systemet, kan vi fortsætte med at implementere leverandørlisten under fanebladet Leverandører. Vi opretter derfor en ny tabel under databasen, der hedder leverandører. Det er derefter muligt under fanebladet "Leverandører"at oprette, slette og redigere leverandører (Se gur 3.4). Figur 3.4: Screenshot af Leverandører Ved hjælp af historierne fra kunden, en refaktorering og de udvundne krav er vi nu kommet frem til den første del af systemet. Samlet resulterer det i vores første aevering. Vi har således opnået en del erfaringer i forhold til den første aevering. I forhold til samarbejde med kunden, har vi fået et større indblik i hvor meget tid vi rent faktisk kan forvente os af kunden. Til at begynde med, kan det være svært at afmåle kundens engagement indtil vi rent faktisk kommer i gang. Det viser sig at kunden er meget samarbejdsvillig og gerne vil sætte tid af til os. Vi er i løbende kommunikationen med kunden omkring udviklingen. Informatik Cafe Chic Lager

28 3.2. AFLEVERING 1 Vi har ligeledes opnået større indblik i hvor meget tid vi skal bruge på udviklingen af de forskellige historier, hvilket gør os i stand til at give et mere realistisk bud på en deadline til anden aevering. Vi har under den første aevering registreret hvor mange timer vi har brugt på de forskellige historier og dem har vi nu mulighed for at omsætte til en belastningsfaktor, for derved lettere at få mulighed for at estimere hvor meget vi kan implementere inden for tidsrammerne til anden aevering. For at lave en eektiv beregning på belastningsfaktoren, som vi implementerer i næste iteration, inddeler vi derfor vores opgaver ud fra kravene i belastningsfaktoren. Grunden til at vi ikke laver en vurdering ud fra hele historier er at vi mener at det giver større usikkerhed i at fastlægge et præcist estimat, end hvis vi gør det i underopgaverne. Oprettelse af nye hovedgrupper, undergrupper og varer: Belastningsfaktor 30 Liste af leverandører: Belastningsfaktor 3 Den graske brugergrænseade: Belastningsfaktor 20 Funktionalitet i brugergrænseaden: Belastningsfaktor 12 Vurderingen af de forskellige opgaver er udført ud fra det funktionelle program. For eksempel er opsætningen af databasen og tabeller lagt ind under o- prettelsen af hovedgrupper. Grunden til dette er at selve persistenslaget udgøres af en database der er nødt til at virke for at systemet kan køre. Derfor det høje tal til det første punkt. Det andet punkt på listen går på visning af leverandører. I og med at vi allerede har oprettet databasen tager det ikke lang tid at oprette en ny tabel. De forskellige databasekald tager heller ikke lang til at implementere da de er af simpel karakter. Da vi allerede har erfaringer med databasekald fra forrige opgaver, er dette punkt kun vurderet til belastningsfaktor 3. Den graske brugergrænseade er ligeledes en stor del af systemet. Det er allerede her vi denerer standarden for resten af systemet, så det er vigtigt at vi bruger den fornødne tid til denne del. Kunden har allerede ytret mange ønsker, så derfor vurderer vi det som en vigtig del, dog alligevel ikke så stor som den første. Selve funktionaliteten af brugergrænseaden er ligeledes meget vigtig. Igen har vi her allerede gjort os mange tanker omkring denne del. Da kunden samtidig har et ønske om at brugergrænseaden skal være så simpel som mulig er tidsforbruget for denne begrænset. Estimeringen af belastningsfaktorer er udført på den måde at vi i fællesskab har kigget på hver underopgave og tildelt dem belastningsfaktorer i forhold til hinanden, altså i forhold til opgavernes omfang. Informatik Cafe Chic Lager

29 KAPITEL 3. AFLEVERINGER Vi kan nu udføre en beregning af belastningsfaktoren i forhold til det timeantal vi har brugt til første aevering. ( ) 23 60min = 21min/Belastningsf aktor Belastningsf aktor 65 Det vil sige at det tager et par 21 minutter at programmere hvad der svarer til belastningsfaktor 1. Vi er dog nødt til at tage hensyn til at vi ikke har medregnet den tid hvor vi har eksperimenteret med nogle af funktionerne, for at lære programmet at kende. Dette giver en usikkerhedsfaktor i forhold til disse tal. Til næste aevering får vi mange nye historier som vi ikke vil have kendskab til på forhånd, hvilket betyder at vi må iberegne noget ekstra tid i forhold til denne inddeling. Med det i baghovedet har vi nu mulighed for at lave et estimat på vores anden aevering. Inden vi går videre til næste iteration, holder vi et møde hvor vi viser kunden systemet. Her har vi muligheden for at få afklaret eventuelle afvigelser i forhold til kundens forventninger og om det er lykkedes at opstille de rigtige krav ud fra historierne. Det viser sig at kunden er meget begejstret for systemet og at det lever op til forventningerne. Kun et par småting som navngivning af nogle enkelte funktioner kommer på tale. Kunden havde dog et ønske om at det skulle være muligt at benytte systemet via touch screen, da ere af de systemer de allerede bruger benytter denne teknologi. Det ville heller ikke være optimalt at opstille et keyboard og en mus i baren på grund af pladsmangel og stor risiko for at udstyret ikke kan holde til arbejdsmiljøet i en bar. 3.3 Aevering 2 I processen omkring anden aevering mærker vi en stor forandring. Kunden har på dette tidspunkt nu mere erfaring med samarbejdet og måden hvorpå historierne skal udformes. Dette resulterer derfor i en lang række mere konkrete historier om ønsker til systemet (se 9.2 på side 97). Som vist i første aevering listes nogle af punkterne fra historierne efterfulgt af krav og opgaver. Vi har valgt ikke at liste alle sammen, da der er mange ere historier til denne iteration end den første. Historie 5: Kunden ønsker at visse dele af systemet kun kan bruges af en administrator. Historie 6: Kunden ønsker at der skal være en form for lagerstatus, hvor det er muligt at rette antallet af varer på en hurtigt og eektiv måde. Historie 7: Kunden ønsker at det skal være muligt at overføre varer fra lageret til baren. Informatik Cafe Chic Lager

30 3.3. AFLEVERING 2 Historie 9: Kunden ønsker at der skal være en form for markering af de varer, der er i undertal på lageret. Det vil sige at ud fra lavsæson og højsæson skal systemet kunne markere hvis der ikke er nok på lager. Historie 13: Kunden ønsker at det er muligt at opdatere varelageret når der kommer en ny levering. Ud fra de nye historier opstiller vi således følgende krav og opgaver til anden del af systemet. Efterfølgende laver vi en estimering af tidshorisonten i forhold til belastningsfaktorer, således at næste deadline overholdes. En login funktion der gør det muligt at vise faner i forhold til bruger. Det vil sige at visse brugere har adgang til alle funktioner, mens andre er nægtet adgang til bestemte funktioner. En status-funktion der gør det muligt at liste varer på lager og opdatere antal på en hurtig og eektiv måde. En funktion der gør det muligt at overføre varer fra lager til bar. En funktion der gør det muligt at markere om der er et lavt antal varer på lager i forhold til lav og højsæson. En funktion der gør det muligt at opdatere lageret i tilfælde af levering af ere varer. De nye krav til systemet er udarbejdet i forhold til de historier, vi i samråd med kunden mener er nødvendige for at systemet kan blive implementeret til en tilstand hvor det er muligt at evaluere det. Det vil sige at en historie som nr. 11, der går ud på at lave en screensaver, efter vores fælles mening ikke er relevant at implementere på nuværende tidspunkt. Funktionen er dog meget relevant, i og med at der på den måde er mulighed for at udnytte screensaveren til reklamer da systemet er tiltænkt en placering hvor det er synligt for caféens gæster. Vi vurderer dog at det er vigtigere at implementere større funktioner, der i en helhed resulterer i et mere bredt og samlet system. Når vi træer den beslutning, er det på den baggrund at vi mener at det er hensigtsmæssigt at udvikle systemet så tilstrækkeligt at det kan repræsentere de daglige funktioner, der indgår i arbejdet på Café Chic. Inden vi fortsætter med selve implementeringen inddeler vi de forskellige underopgaver i forhold til belastningsfaktoren. På den måde har vi mulighed for at se om vi har opstillet en realistisk deadline i forhold til anden aevering. Som nævnt tidligere er vi nødt til at tage højde for den usikkerhedsfaktor der følger af de eksperimenter vi foretager med koden inden den egentlige implementering. Derfor vurderer vi at det er hensigtsmæssigt at påregne en belastningsfaktor på ca. 5 units ekstra pr. underopgave. Login-funktion: Belastningsfaktor Vise og redigere alle vare til status-funktionen: Belastningsfaktor Informatik Cafe Chic Lager

31 KAPITEL 3. AFLEVERINGER Overføre varer fra lager til bar: Belastningsfaktor Markering af antal i forhold til høj og lavsæson: Belastningsfaktor Registrering af ny levering: Belastningsfaktor Vi vurderer login-funktionen til at være en større opgave, da vi på forhånd ikke har særlig kendskab til at lave den slags funktioner. Status-funktionen til at liste og redigere i lageret hurtigt og eektivt, vurderer vi til en lavere belastningsfaktor. Det er et spørgsmål om at oprette en liste, der viser alle varerne i databasen. Det skal så være muligt at redigere antal under hver vare. En funktion der gør det muligt at overføre varer fra lageret til baren, vurderes også forholdsvis højt, af den grund at vi ikke allerede har en lignende algoritme i programmet og at vi derfor skal starte fra bar bund. Markering af lavt vareantal vurderer vi ligeledes højt, idet vi skal have lavet nye algoritmer der kan traversere igennem vores varelister og derefter markere hver vare der er i undertal på lageret. Registrering af nye leverancer har vi ikke vurderet særlig højt, da algoritmen der overfører varer fra lager til bar ligner meget. Den samlede vurdering af belastningsfaktorer ser derfor således ud: ( ) Belastningsfaktor 87 21min = 30.45timer 60 Ud fra vores tidsplan har vi ca. en uge inden anden aeverings deadline. Man kan derfor påstå at ovenstående vurdering på ca. 30 timer passer nogenlunde med vores tidsplan. På baggrund af de nye opgaver og vores tidsestimat går vi i gang med implementeringen af anden aevering. Login-funktionen, der er det første nye aspekt af systemet, bliver vi enige om at lave som en administrator login. Det vil sige at hvis en bruger er administrator, har denne adgang til ere faneblade og dermed ere funktioner i systemet. Der bliver imidlertid ikke taget højde for muligheden for at have ere forskellige brugerkonti (Se gur 3.5). Informatik Cafe Chic Lager

32 3.3. AFLEVERING 2 Figur 3.5: Screenshot af login funktionen Lagerstatus-funktionen, hvor det skal være muligt at liste alle varer i systemet og rette i disses antal på en hurtig og eektiv måde, bliver implementeret som en liste over alle varer i systemet. I den liste er der kun mulighed for at redigere et enkelt sted, nemlig under antal. Der bliver ikke implementeret en gem knap eller lignende, da den automatisk gemmer når der enten trykkes enter eller der bliver skiftet linje. På den måde mener vi at opfylde kravet om at det skal være hurtigt at ændre antallet af de forskellige varer (Se gur 3.6). Informatik Cafe Chic Lager

33 KAPITEL 3. AFLEVERINGER Figur 3.6: Screenshot af Lagerstatus Informatik Cafe Chic Lager

34 3.3. AFLEVERING 2 Overførsel fra lager til bar er en vigtig del af systemet. Da lagerstyringen er delt over to lokationer, skal det være muligt at ytte varer mellem dem. Vi bibeholder designet fra Varer-funktionen i første aevering, hvor der bliver vist to rammer med hoved- og undergrupper, men tilføjer så en liste der her viser hvilke varer den valgte undergruppe indeholder. Disse varer kan så vælges en ad gangen til at blive overført til en midlertidig liste, der giver brugeren et overblik over de valgte varer, denne ønsker at overføre. Når der ikke skal vælges ere varer trykkes der på knappen "Overfør"og varerne bliver overført og trukket fra lageret (Se gur 3.7). Figur 3.7: Screenshot af Lager til Bar funktionen Funktionen der gør det muligt at illustrere hvornår en vare er i undertal i forhold til højsæson og lavsæson, vælger vi at implementere sammen med Lagerstatus-funktionen. Det gør vi af den grund at alle varer i forvejen er listet her og vi mener ikke at der grund til at lave et nyt punkt der viser akkurat det samme. Vi modicerer dog fanebladet med en funktion der gør det muligt at vælge mellem lavsæson og højsæson (Se gur 3.6). Alt efter hvad der bliver valgt, løber systemet igennem varelisten og kontrollerer om det aktuelle vareantal er under minimumsgrænsen i forhold til det minimum for højsæson og lavsæson der er speciceret for hver vare. Er antallet lavt, markeres varen med en rød farve på listen. Informatik Cafe Chic Lager

35 KAPITEL 3. AFLEVERINGER Kunden ønsker ligeledes en funktion, der gør det muligt at registrere vareleverancer i systemet. Til denne funktion gør vi igen brug af samme menustruktur som i den funktion der overfører fra lager til bar. Så i princippet fungerer den på samme måde, men i stedet for at overføre til baren bliver den nye leverance tilføjet til lageret. Her er der også mulighed for samtidigt at tilføje en eller ere varer via listen (Se gur 3.8). Figur 3.8: Screenshot af Leverings funktionen Informatik Cafe Chic Lager

36 3.3. AFLEVERING 2 Vi vil nu illustrere hvorledes forskellen på design kommer til udtryk fra første til anden aevering (Se gur 3.9). Ved anden aevering nævner kunden at knapper og faner muligvis er for små til en touch screen, hvorefter vi så vælger at lave dem større. Det bevirker også at vi samtidig må tænke over interaktionen med programmet, det vil for eksempel sige at man skal designe efter at interaktionspunkter helst skal ligge mindst en ngerbredde fra hinanden for at undgå interaktionsfejl. Et eksempel kan her være hvis to knapper er placeret for tæt på hinanden. Figur 3.9: Screenshot af menu før og efter Vi har desuden også valgt at designe vores liste af varer baseret på et dokument vi har fået udleveret af kunden. Dette dokument viser opstillingen af varer og bliver brugt af personalet til optælling af varelageret (Se gur 3.10). Hvis vi designer vores lister ud fra dette dokument vil de ansatte derved nemmere kunne genkende sammenhængen fra gængse arbejdsvaner og systemet (Se gur 3.11). Informatik Cafe Chic Lager

37 KAPITEL 3. AFLEVERINGER Figur 3.10: Scan af produktliste Figur 3.11: Skærmbillede af vareliste Informatik Cafe Chic Lager

38 3.4. TEKNISK BESKRIVELSE AF DET FÆRDIGE SYSTEM 3.4 Teknisk beskrivelse af det færdige system Dette afsnit giver mere teknisk indsigt i hvordan den færdige version af systemet er implementeret, det vil sige den version der blev brugt i forbindelse med brugbarhedsevalueringen Overordnet arkitektur Programmets arkitektur er forholdsvis simpel idet brugergrænseade-laget kommunikerer direkte med persistenslaget og omvendt (se gur 3.12). Dette følger af programmets simple formål, da det hovedsageligt fungerer som et værktøj til at redigere indholdet af en database. Der er for eksempel derfor ikke behov for et funktionslag eller modellag. Figur 3.12: Den lagdelte arkitektur for det færdige system Beskrivelse af brugergrænseadelaget Hele brugergrænseaden er bygget op omkring et centralt vindue, eller Windows Form som det hedder i C#, som vi kalder MainForm. Denne indeholder de faneblade eller tabs hvor al interaktion foregår. Indholdet af disse tabs kan skifte afhængigt af brugerens interaktion med programmet og de er derfor deklarerede som statiske objekter i MainForm-klassen. Dette gør os i stand til at lave statiske metoder i MainForm-klassen der, når de bliver kaldt fra andre klasser, ændrer indholdet af fanebladene. For at gøre det nemmere for os at designe indholdet af fanebladene, har vi brugt UserControl klasser som man i Visual Studio hurtigt kan designe ved hjælp af dennes graske brugergrænseade. Det vil sige at MainForm-klassen indeholder nogle statiske objekter af Tab-klassen som igen indeholder UserControl-objekter, der kan udskiftes dynamisk. Navigation indenfor tab'en foregår derfor ved at den respektive event kalder den respektive statiske metode i MainForm, der så Informatik Cafe Chic Lager

39 KAPITEL 3. AFLEVERINGER udskifter UserControl'en. Opbygningen af brugergrænseaden er illustreret på gur Figur 3.13: Visuel opbygning af brugergrænseaden (MainForm-klassen) Beskrivelse af persistenslaget Til et lagerstyringssystem som dette er det oplagt at benytte en database, da det skal administrere en stor mængde data. Samtidig tilbyder nogle databaseløsninger gode sikkerhedsmuligheder som for eksempel automatisk backup. Derfor valgte vi at bygge persistenslaget op omkring en database. Vi valgte en Microsoft SQL Server baseret database, da Visual Studio understøtter denne type database fuldt ud og fordi vi k tilbudt plads på et SQL server hotel. I databasen er der oprettet separate tabeller for varer, varegrupper og leverandører. For hver tabel er der oprettet én eller ere TableAdapter klasser, der virker som interface til de faktiske tabeller i databasen. Al interaktion med databasen foregår derfor gennem TableAdapter metoder, såsom Fill, Insert, Delete. Disse repræsenterer faktiske SQL sætninger. Objekter af TableAdapter klasserne er derfor bindeled mellem de to lag. Informatik Cafe Chic Lager

40 3.4. TEKNISK BESKRIVELSE AF DET FÆRDIGE SYSTEM Informatik Cafe Chic Lager

41

42 4.1. MÅL I dette kapitel beskrives fremgangsmåde til vores brugbarhedsevaluering, og hvilke metoder vi har valgt til at underbygge denne fremgangsmåde. Vi fremstiller resultaterne fra vores tests, hvor identicerede problemer analyseres. Kapitlet er inddelt på følgende måde, Mål Her speciceres hvad vi vil afdække med en brugbarhedsevalueringen. Metode Her beskrives de metoder og faciliteter vi har valgt at anvende til indsamling af data, Kognitiv gennemgang. Her beskrives målet med at udføre gennemgangen, fremgangsmåden og resultatet heraf (se 4.3). Pilottest. Her beskrives målet med testen, fremgangsmåden og resultatet heraf (se 4.4). Brugbarhedstest. Her beskrives målet med testen, den foreskrevne fremgangsmåde og resultatet heraf (se 4.5). Interview. Her beskrives målet med interviewet, fremgangsmåden og teorien som underbygger fremgangsmåden og resultatet af interviewet (se 4.6). Opsummering Her samles resultaterne fra de ovennævnte metoder som udgør brugbarhedsevalueringen (se 4.7). 4.1 Mål Målet for brugbarhedsevalueringen er at fastslå i hvor høj grad produktet lever op til kundernes og brugernes krav og forventninger. Vores primære mål med at teste er at undersøge hvor godt vores designvalg og implementation af systemet lever op til kundens og brugernes forventninger og krav, samt at afdække eventuelle brugbarhedsproblemer der måtte være. Herunder gælder det at (se mere herom i 4.2.1), Systemet skal være let at lære og at bruge (Molich, 2000). Systemet skal opfylde kravene stillet af kunden på en tilfredsstillende måde (Beck, 2002). Endvidere vil vi fastslå om det, ved hjælp af udviklingsmetoden XP, er lykkedes for os at fremstille et brugbart system. 4.2 Metode Der ndes ere forskellige måder at evaluere et systems brugbarhed på. De to hovedtyper er brugertest og gennemgang eller inspektion. Ved en brugertest Informatik Cafe Chic Lager

43 KAPITEL 4. EVALUERING gennemgår man systemet sammen med en faktisk bruger, for hvem systemet er designet. Det vil sige at brugeren deltager aktivt i testen af systemet, og derfor er med til at påvirke designet af det system, som de i sidste ende selv skal benytte. Ifølge Jerey Rubin kan man ved hjælp af en brugertest afdække op mod 80 procent af et systems brugbarhedsproblemer med bare 4-5 testpersoner (Rubin, 1994). Under en gennemgang gennemgår en ekspert i brugbarhed systemet, og nder frem til eventuelle brugbarhedsproblemer, ud fra et sæt regler eller heuristikker. Denne metode er som udgangspunkt mindre ressourcekrævende end en brugertest, og kan derfor anvendes hvis økonomi er en afgørende faktor, eller som supplement til en brugertest. Men for at sikre præcise resultater, kræver denne metode at man har en del erfaring med lignende systemer eller brugbarhedsevaluering generelt (Molich, 2000). Vi har fra tidligere projekter haft gode erfaringer med at anvende en metode til brugerbarhedstest der kaldes tænke-højt test, til at undersøge i hvor høj grad et system opfylder brugerens krav og lever op til brugerens forventninger (se 4.5 på side 47). Som forberedelse til tænke-højt testen udføres en pilottest, med det formål at rette eventuelle fejl i udformningen af de testopgaver, som tænke-højt testen er baseret på (se 4.4 på side 46). Vi vil endvidere anvende en form for gennemgang kaldet Kognitiv gennemgang". Denne form for gennemgang foregår ved at vi som eksperter i systemet sætter os ned og gennemgår det, ved hjælp af realistiske opgaver som brugerne kunne nde på at udsætte systemet for (se 4.3 på næste side). For at afdække kundens synsvinkel på samarbejdet med udviklerne og udviklingsprocessen, vil vi foretage et kvalitativt interview. Ydermere kan et interview afdække mange aspekter af anvendelsen af systemet (Molich, 2005) (se 4.6 på side 60) Denition af brugbarhed Viden om brugbarhed opnås, ifølge Rolf Molich, ved at lytte til brugerens behov og ved at have indsigt i brugerens domæne. Molich denerer brugbarhed med udgangspunkt i følgende re egenskaber (Molich, 2000). Let at lære Den tid, som det tager brugeren at lære at løse bestemte opgaver ved hjælp af systemet. Let at huske Den tid, som det tager brugere som har været væk fra systemet i et stykke tid eller anvender det sjældent, at løse bestemte opgaver ved hjælp af systemet. Eektivt at bruge Informatik Cafe Chic Lager

44 4.3. KOGNITIV GENNEMGANG Den hastighed, hvormed brugeren løser bestemte opgaver i forening med systemet. Eektiviteten afhænger af responstiden, hvor hyppigt fejl opstår og hvor konstruktive fejlmeddelelserne er. Tilfredsstillende at bruge Den tilfredshed med systemet, som brugeren udtrykker i spørgeskemaer eller ved interviews. Prioritering af de ovennævnte egenskaber kan balanceres afhængig af, hvorledes anvendelsen af systemet er tilsigtet i brugerens domæne. Eksempelvis ville eektivitet prioriteres, hvis systemet bruges ere gange dagligt, hvorimod indlæring og genindlæring ville blive prioriteret, hvis systemet blev anvendt sjældent (Molich, 2000). 4.3 Kognitiv gennemgang Vi vil anvende en form for gennemgang kaldet kognitiv gennemgang. Denne gennemgang udføres inden selve brugbarhedsevalueringen Mål Denne gennemgang udføres for, at vi skal have mulighed for selv at opdage og rette så mange fejl og uhensigtsmæssigheder i systemet som muligt, før det præsenteres for testpersonerne i en brugertest. Her fokuseres på funktionelle problemer, stavefejl, manglende instruktioner og feedback. Metoden er baseret på en tanke om at brugere foretrækker at lære at bruge system ved at udføre opgaver, i modsætning til f.eks. at læse en manual Metode Denne form for gennengang foregår ved at vi som eksperter gennemgår systemet, med udgangspunkt i realistiske opgaver som brugerne kunne nde på at udsætte systemet for. Opgaverne bliver gennemgået med henblik på at nde eventuelle brugbarheds problemer, så disse kan blive rettet inden tænkehøjt testen. Til dete formål fremstilles en checkliste, en liste over opgaver, og et skema til at dokumentere eventuelle problemer i. Gennemgangen afvikles således at re eksperter udfører de opstillede opgaver. Fire computere med systemet installeret bliver sat til rådighed. Ydermere skal de re eksperter notere de opdagede problemer i skemaet. Efterfølgende samles resultaterne fra de re eksperter og sammenskrives i et skema, så det efterfølgende er muligt at diskutere og vurdere alvorligheden af de enkelte problemer. De problemer der blev fundet af mere end én ekspert blev vurderet som alvorlig, og blev efterfølgende rettet eller ændret. Informatik Cafe Chic Lager

45 KAPITEL 4. EVALUERING Resultat Under den kognitive gennemgang opdager vi hurtigt nogle små fejl i systemet (se gur 4.1). Blandt andet nder vi ud af at når man skal skifte faneblad i systemet, opdaterer den ikke fra databasen, dette er uheldigt da det nemt kan resultere i nogle problemer som ikke direkte er brugbarhedsfejl, men nærmere system fejl, der kan medføre brugbarhedsproblemer i større eller mindre omfang. Et andet problem, der blev opdaget under gennemgangen var, at når man overfører varer fra lager til bar, giver systemet ikke nogen bekræftelse. Dette kan forvirre brugeren, der ikke kan være sikker på at systemet har gjort det han har bedt det om. Dette problem blev rettet ved at tilføje en system meddelelse, der gør brugeren opmærksom på at overførslen er udført. Figur 4.1: Problemer fundet under kognitiv gennemgang og efterfølgende rettet. Informatik Cafe Chic Lager

46 4.4. PILOTTEST De problemer der ikke er blevet rettet efter endt gennemgang er problemer som kun blev opdaget af en enkelt ekspert, eller som efter diskussion blev vurderet til ikke umiddelbart at ville forårsage brugbarhedsproblemer. De blev dog noteret så det er muligt at undersøge i hvor høj grad de er reelle brugbarhedsproblemer i forbindelse med en tænke-højt test (se gur 4.2). Figur 4.2: Problemer fundet under kognitiv gennemgang, dog ikke rettet. 4.4 Pilottest Mål Pilottesten benytter vi for at eliminere eventuelle fejl i udformningen af spørgsmål, men ligeledes for at blive kendt med det tidsmæssige forløb. for at kunne planlægge den endelige tænke-højt test mere detaljeret. Da vores hensigt er at teste systemet på 5 personer, er det vigtigt at vi kan tilrettelægge test dagen så hensigtsmæssigt som muligt. Her fokuseres på det administrative omkring testen Metode Til at udføre denne test, har vi valgt en uvildig person der ikke har nogen tilknytning til universitet såvel som Café Chic. Dette af den grund, at vi vil sikre os at personen ikke har nogen baggrundsviden inden for området. Dette gør vi fordi at det giver os et bredere publikum og derved opnår vi at personen kan Informatik Cafe Chic Lager

47 KAPITEL 4. EVALUERING forholde sig mere kritisk til systemet og kommentere på spørgsmålene så vi kan opnå mere velformulerede spørgsmål, der ikke giver anledning til misforståelser. Det er systemet der skal testes, derfor er det vigtigt at test personerne forstår spørgsmålene. Til at udføre testen benytter vi os af en båndoptager til at optage testen, en bærbar computer samt en notesblok til notater. Testen ledes af en testleder og i baggrunden sidder en observatør og tager notater. Testen udføres hjemme hos testpersonen Resultat Under pilottesten, kommer det hurtigt til udtryk at der er nogle problemer med forståelsen af spørgsmålene (se 9.6). I ere opgaver går personen forkert i gang med at udføre opgaven da denne ikke er forstået fuldt ud. Efter et stykke tid skrider testlederen ind og beder personen om at læse spørgsmålet igen og der hersker nu forståelse omkring opgaven. På bagrund af disse oplysninger er vi i stand til at gennemgå spørgsmålene igen, og skrive dem om så de umiddelbart er lettere at forstå. Til vores overraskelse kommer testpersonen ikke ind i de store problemer under testen. Der er dog et enkelt tilfælde hvor personen går i stå i længere tid, men kommer på rette spor efter lidt hjælp fra testlederen. Et andet problem i testen er at testpersonen har problemer med at forstå nogle menupunkter. Det være sig grupper af varer som ikke umiddelbart er kendte af en person der ikke arbejder i en bar. Et eksempel er da testpersonen skal tilføje 48 stk. Fosters øl til lageret. Vedkommende er ikke klar over hvilken kategori denne øl ligger i. Dette betyder, at man bør have noget baggrundsviden for at kunne benytte systemet. Derudover lokaliserer vi ere mindre tegn på brugbarhedsproblemer, men disse venter vi med at vurdere indtil den endelige test. 4.5 Brugbarhedstest Mål En tænke-højt test anvendes med den hensigt at identicere systemets brugbarhedsproblemer. Molichs klassikationskriterier anvendes for at klassicere alvorligheden af disse brugbarhedsproblemer (Molich, 2005). Vi fremsætter nogle forslag til fremtidige optimeringer af systemet, baseret på de brugbarhedsproblemer brugerne identicerede under evalueringen Metode Vi har fra tidligere projekter haft gode erfaringer med at anvende en metode til brugbarhedstest der kaldes tænke-højt tests, til at undersøge i hvor høj grad et system opfylder brugerens krav og lever op til brugerens forventninger. Evalueringsformen kaldes tænke-højt test da testpersonen opfordres til at tænke højt under testen (Molich, 2000). Informatik Cafe Chic Lager

48 4.5. BRUGBARHEDSTEST Testpersonen opfordres således til at beskrive og begrunde sine tanker og handlinger i forbindelse med testen af systemet. Denne form for test giver mulighed for at læse testpersonens tanker omkring systemet, og giver rig mulighed for at indsamle kvalitativ data (Rubin, 1994). Denne tankestrøm giver et indblik i hvorfor testpersonen handler som han gør, og ikke kun hvad han gør. Dette giver en bedre forståelse for hvor eventuelle problemer ligger, og dermed et bedre grundlag for at løse dem (Rubin, 1994). Der er dog også faldgruber ved denne form for brugertest, som man skal være opmærksom på. Det kan føles unaturligt for en testperson at skulle tænke højt, da det for de estes vedkommende ikke er en vanlig adfærd (Rubin, 1994). Derfor er det vigtigt at testpersonen gøres opmærksom på at de skal tænke højt. Endvidere gør tænke-højt-metoden at brugeren bliver sænket i sin tankeproces, hvilket kan bevirke at de er mere opmærksomme på deres handlinger end de normalt ville være (Rubin, 1994). Dette kan betyde at nogle af de problemer der kunne opstå i en virkelig situation ikke bliver belyst. Desuden egner denne metode sig ikke til tests hvor præstationstiden er afgørende. Et sidste problem i forbindelse med denne form for test er, at det under alle omstændigheder er udmattende for både testperson og testleder at deltage i en tænke højt test (Rubin, 1994). Det er vigtigt at overveje under hvilke forhold vi ønsker at foretage tænkehøjt testen, om vi ønsker at observere brugeren i sit naturlige miljø, eller om det er mere hensigtsmæssigt at foretage testen i et opstillet miljø, som f.eks. et brugbarhedslaboratorium (Rubin, 1994). Foretager man observationen i brugerens "naturlige"miljø, også kaldet en feltobservation, vil brugeren givetvis føle sig bedre tilpas og mere sikker, end hvis man foretog testen i et laboratorium. Under en feltobservation er det dog svært at kontrollere ydre påvirkninger af personen fra miljøet omkring vedkommende (Rubin, 1994). I et opstillet miljø, f.eks. et professionelt brugbarhedslaboratorium, er det nemmere for testforetagerne at kontrollere de forskellige variabler der måtte forekomme, og dermed minimere uønskede påvirkninger (Rubin, 1994)). Da man altid anvender det samme lokale og bestræber sig på at sikre et identisk testmiljø for alle testpersonerne, har vi valgt at benytte et laboratorium til brugbarhedstesten af systemet. På trods af de nævnte faldgruber i metoden, har vi valgt at bruge den i forbindelse med en laboratorietest af systemet, da vi mener det er den mest hensigtsmæssige i forhold til vores system og arbejdsforhold. Behandling af data Efter endt test skal de fundne brugbarhedsproblemer klassiceres. Til dette formål anvendes Molichs klassikationskriterier. Positive kommentarer og forslag til fremtidige forbedringer indgår også i denne klassikationsproces (Molich, 2000). Informatik Cafe Chic Lager

49 KAPITEL 4. EVALUERING Positive kommentarer Funktioner eller andre træk ved systemet, som brugeren syntes godt om. Disse kommentarer kan tjene som forbillede for videre udvikling af systemet. Forbedringsforslag Et forslag fra en bruger, som kan medføre en væsentlig forbedring af brugeroplevelsen. Kosmetisk problem Problemet forsinker brugeren et kort øjeblik. Bør rettes ved lejlighed. Alvorligt problem Brugeren bliver væsentlig forsinket, men nder selv videre efter unødig mange anstrengelser. Problemet kan lejlighedsvis give anledning til katastrofer. Kritisk problem (katastrofe) Et kritisk problem opstår når der er en kritisk forskel mellem det brugeren forventer systemet gør og det systemet rent faktisk gør. Ydermere kan et brugbarhedsproblem klassiceres som kritisk, hvis brugeren ikke er i stand til at fortsætte sit arbejde med systemet, uden assistance fra en anden person. En katastrofe opstår hvis samme kritiske problem opleves af to brugere uafhængigt af hinanden. Fejlen bør rettes med det samme. Endvidere anvender vi følgende skema til at lette klassiceringen af brugbarhedsproblemerne. Klassicering af problemer er ikke en eksakt videnskab, man skal bl.a. være påpasselig med at bedømme problemerne ud fra tiden som den afgørende faktor (se gur 4.3). Specielt i forbindelse med tænke-højt test sænkes brugere tidsmæssigt da de skal sætte ord på de tanker de gør sig. Figur 4.3: Kategorisering af problemer Positive kommentarer, funktionsfejl og forbedringsforslag, er kategorier som er baseret på brugernes udtalelser under evalueringen. Roller Følgende rollefordeling optræder under vores brugbarhedstest, Testlederen Rollen som testleder indebærer evnen til, at formidle de opstillede opgaver Informatik Cafe Chic Lager

50 4.5. BRUGBARHEDSTEST samt debriefe og interviewe testpersonerne efter endt test. Ydermere er testlederen den ansvarlige hvad angår afvikling af testen og registrering af data. Observatører Observatøren skal notere de brugbarheds problemer, som brugeren nder, samt årsagen til disse problemer. Ydermere skal observatøren notere brugerens positive kommentarer og forslag til systemet, da disse kan optræde som pointere til fremtidige forbedringer. Testpersoner Systemet skal testes af personer som vil kunne komme til at benytte systemet når det er færdigudviklet. For at ramme den rigtige målgruppe har vi valgt at bruge personalet fra Café Chic, som helt naturligt vil skulle bruge systemet. Usability lab Brugbarhedstesten udføres i usability laboratoriet på Aalborg Universitet. Laboratoriet er opdelt i et kontrolrum, et observationsrum og et testrum (se gur 4.4). Testpersonen placeres sammen med testlederen i observationsrummet, hvor de vil blive lmet gennem testen. I kontrolrummet styres optagelsen af lyd og billede, mens testen kan følges på monitorer. I observationsrummet følges testen gennem envejsspejlet. Testen vil blive logget af tre personer som bender sig i henholdsvis observationsrummet og kontrolrummet. Informatik Cafe Chic Lager

51 KAPITEL 4. EVALUERING Figur 4.4: Figuren viser Usability Lab på Aalborg Universitet. Udstyr Til testen benyttes tre computere til at skrive logl på, og en computer til at udføre testen på. Denne computer er tilkoblet optageudstyret, så skærmbilledet kan komme med på optagelsen sammen med optagelser fra de re kameraer der er tilstede i testrummet. En touch screen er desuden sluttet til computeren, i stedet for den normale skærm. Efter testen gennemses optagelserne for at sikre at det vigtige er med i loglerne. Procedure Det er vigtigt at have fastlagt en testprocedure forud for testen. På den måde sikrer vi at forholdene for alle testpersoner er så ens, som muligt. I det følgende beskrives proceduren for vores tests. 1. Testforløbet starter med at testlederen personligt byder testpersonen velkommen. Testpersonen bliver derefter bedt om at underskrive en samtykkeerklæring, der giver os tilladelse til at bruge de data vi indsamler under testen. Informatik Cafe Chic Lager

52 4.5. BRUGBARHEDSTEST 2. Herefter orienterer testlederen testpersonen om den forestående test (se 9.5). Han forklarer hvordan testen forløber, og hvordan testpersonen skal tænke højt imens opgaverne løses. Denne orientering læses højt for alle testpersoner for at sikre at de alle får den samme introduktion og at testlederen ikke glemmer vigtige oplysninger. 3. Dernæst kan selve testen begynde. Opgaverne præsenteres for testpersonen én ad gangen, og disse bliver læst op af testpersonen for at sikre at han har forstået dem rigtigt. Hver opgave akkompagneres af en kort scenariobeskrivelse, der skal gøre det nemmere for testpersonen at leve sig ind i situationen (Molich, 2000). Testlederens rolle under testen er at opfordre testpersonen til at tænke højt, og kan i yderste tilfælde hjælpe testpersonen videre i en opgave. Når testpersonen mener at opgaven er løst, skal han meddele dette til testlederen, hvorpå han modtager næste opgave. Det er desuden testlederens ansvar at tidsplanen overholdes. Hvis tiden er ved at løbe ud og testen endnu ikke er færdig, er det op til testlederen at vurdere hvorvidt det er lønsomt at fortsætte testen, eller om enkelte opgaver skal udelades. 4. Efter testen indleder testlederen et debrieng interview med testpersonen. Her kan testlederen bede testpersonen om at uddybe og forklare de problemer, der opstod under testen. Desuden opfordres testpersonen til at kommentere systemet. Til slut bliver testpersonen bedt om at udfylde et spørgeskema om demograske data, såsom navn og alder (se 9.7). Når disse re trin er gennemført, forlader testpersonen testlokalet og der gøres klar til næste test Resultat Inden testen udfylder de fem testpersoner alle et spørgeskema, der fortæller os noget om deres baggrund og erfaring inden for IT. Svarene fra spørgeskemaerne er samlet og illustreret i tabel 4.5. Figur 4.5: Demograskedata Testperson 1, 2, 3 og 4 arbejder alle på Cafe Chic. Testperson 5 har ingen tidligere erfaring med løsning af de daglige opgaver og den daglige arbejdsrutine på en cafe. Testpersonerne er aldersmæssigt fordelt fra 19 til 26 år. To af testpersonerne er kvinder og tre af dem mænd. Der er desuden stor spredning Informatik Cafe Chic Lager

53 KAPITEL 4. EVALUERING på testpersonernes ugentlige computerbrug, fra 0-5 timer op til timer om ugen. Dette betyder samlet set at vi anvender et bredt udvalg af personalet på Cafe Chic, og derfor har mulighed for at få så bred en vurdering af systemet som muligt. Efter brugbarhedstesten gennemgik vi vores noter for at lokalisere brugbarhedsproblemer, i forbindelse med løsningen af opgaverne (se 9.6). Dette resulterede i 15 problemer fordelt på otte kosmetiske, fem alvorlige, et kritisk og et teknisk problem. (Se gur 4.6) Vi vil her beskrive de tekniske, kritiske og alvorlige problemer. Tekniske problemer Problem 15 (Putty går ned, og adgangen til databasen afbrydes). Den port som skal bruges for at skabe forbindelse til vores database, er ikke åben på universitetet, og derfor benytter vi os af Putty til at lave en tunnel. Men ere gange under testene forsvandt denne tunnel, og systemet gik ned, da der ikke kunne skabes forbindelse til databasen (se 9.1). Kritiske problemer Problem 10 (Testpersonen er i tvivl om ændringen af antal er gennemført). I opgave 8 skal testpersonerne ændre lager antallet af Svaneke Classic fra tre til to. Alle personerne løser opgaven korrekt, men re af dem er mere eller mindre i tvivl om opgaven faktisk er løst. Den sidste har løst en tidligere opgave på den måde som denne var tiltænkt, og derfor løses opgaven her uden problemer. Opgaven løses ved at klikke ind under lagerstatus, og klikke i antal. Her kan der ændres hvor meget der er på lager, og det gemmes ved at trykke Enter. Grunden til at der opstår forvirring er manglen på konsistens, da alle andre opgaver før denne skal løses ved at klikke på en knap på skærmen i stedet for Enter, hvorefter der kommer en dialogboks der bekræfter at opgaven er løst. Grunden til at problemet kategoriseres som kritisk er, at der er re ud af fem personer som forventede en bekræftelse i form af en dialogboks, der ikke kom. Derudover er testpersonerne ikke sikre på at opgaven er løst, eller hvad de har lavet. Testperson 5 tjekker om databasen er opdateret, og konstaterer at det var held at opgaven blev løst. Problemet opstår da systemet er lavet til hurtigt at kunne ændre mange varer ved status eller lignende. Det var tiltænkt at, efter alle varer var optalt, skulle listen hurtigt kunne gennemgås, uden forstyrrelse af dialogbokse. For at løse problemet, kunne der indsættes en gem knap, og en dialogboks. Dermed ville brugeraden også få mere konsistens, og systemet ville gøre som brugerne forventer. Informatik Cafe Chic Lager

54 4.5. BRUGBARHEDSTEST Figur 4.6: Figuren viser de problemer som blev lokaliseret under tænke-højt testen, og hvilke testpersoner der oplevede dem. Informatik Cafe Chic Lager

55 KAPITEL 4. EVALUERING Alvorlige problemer Problem 4 (Det er ikke tydeligt, at man skal ind under levering for at tilføje ere varer til lageret). I opgave 4 skal der tilføjes nogle varer til lageret og her kan ingen af testpersonerne se, at de skal klikke på levering for at komme til at løse opgaven. Først efter noget tid lykkedes det for personerne at nde frem til den rigtige menu. Problemet kategoriseres som alvorligt da alle testpersoner forsinkes i længere tid, men da ingen går helt i stå, vil den ikke kunne kategoriseres som kritisk. Løsningen på problemet er, ifølge testperson 2, at ændre teksten på tab'en fra Levering til Tilgang da dette er den brugte term i branchen. Problem 5 (Overfør til liste under Levering/Lager->Bar er ikke logisk tekst). I de opgaver hvor der skal yttes varer fra lageret til baren og indtastes nyankomne leveringer, opstår der problemer med forståelsen af brugergrænseadens tekst. Det fjerde skridt i de to aktioner er at klikke på en knap hvor teksten Overfør til liste står over (Se gur 4.7). Informatik Cafe Chic Lager

56 4.5. BRUGBARHEDSTEST Figur 4.7: Her ses skærmbilledet der beskrives i problem 5 Denne tekst over knappen forvirrer tre af testpersonerne, som går i stå da de ser teksten (se 9.1). Testperson 5 kommenterer i opgave 4 at han ikke forstår teksten. Grunden til at problemet kategoriseres som alvorlig er at tre personer går i stå en eller ere gange, men får løst opgaven alligevel. Der er her igen tale om sprogbrug. Der er brugt pile i teksten Lager -> Bar. Problemet ville kunne løses ved f.eks. at ændre teksten til Overfør til bar. Teksten Overfør til liste kunne ændres til Indtast tilgang. Det skal dog her påpeges at ere af testpersonerne efter gennemgang af opgaven opdager, hvorledes logikken bag fremgangsmåden hænger sammen og desuden påpeger at "..det skulle man lige nde ud af, så er det jo logisk nok." Problem 7 (Systemet husker hvilke skærmbilleder der sidst er anvendt under hver fane, hvilket forvirrer testpersonen). Hvis testpersonen eksempelvis har været inde på fanen Varer (se gur 4.8), og her er gået videre til Vis varer (Se gur 4.9). Herefter går testpersonen så til fanen Leverandører (se gur 4.10), for så at gå tilbage til Varer. Her forventer testpersonen at skærmbilledet viser gur 4.9, men i stedet vises gur 4.8. Informatik Cafe Chic Lager

57 KAPITEL 4. EVALUERING Figur 4.8: Her ses skærmbilledet Varer fra problem 7 Informatik Cafe Chic Lager

58 4.5. BRUGBARHEDSTEST Figur 4.9: Her ses skærmbilledet Vis varer fra problem 7 Informatik Cafe Chic Lager

59 KAPITEL 4. EVALUERING Figur 4.10: Her ses skærmbilledet Leverandør fra problem 7 Der er altså her en konikt med det som tespersonerne forventer og med det som egentlig sker. Problemet kategoriseres derfor som alvorlig. Problemet ville kunne løses ved at nulstille hvert faneblad hver gang det blev forladt. På den måde ville systemet vise samme skærmbillede hver gang. Dette havde vi dog forinden i designfasen besluttet at programmet ikke skulle gøre, af den begrundelse at det så ville være nemmere at skifte imellem igangværende jobs på forskellige faner. Hvis fanen nulstiller hver gang, skal man enten indtaste oplysninger eller følge stien frem til der hvor man var sidst. Problem 8 (Den røde farve under lagerstatus tydes af testpersonerne som en fejl, i stedet for den rigtige betydning: Antallet af den givne vare er under minimumsvarerlageret). Når en vare er under minimumsvarerlageret, bliver baggrundsfarven ændret på den givne vare under lagerstatus. Testperson 2 kommenterer at det må betyde at der er sket en fejl da han ser den røde farve. Grunden til at problemet kategoriseres som alvorligt er at farven misfortolkes. Det er vigtigt at farverne fortolkes som de skal. Problemet ville kunne løses ved at lave en forklaring af farven på samme skærmbillede. Eller bruge en anden farve end rød da denne farve ofte fortolkes som farlig/fejl eller forbudt. Informatik Cafe Chic Lager

60 4.6. INTERVIEW Problem 9 (Det er ikke tydeligt at der kan ændres i antal under lagerstatus). I opgave 8 skal antallet af varer på lageret ændres. Dette gøres ved at klikke i feltet antal under lagerstatus. Tre af testpersonerne har problemer med at nde frem til at der kan klikkes i feltet og prøver en masse forskellige muligheder, inden de rammer feltet og dermed får rettet antallet. Grunden til at problemet kategoriseres som alvorligt, er at tre testpersoner bliver forsinket i længere tid af problemet. De opfatter også samtidig ikke feltet som et felt man kan ændre i. Problemet ville kunne løses ved at lave en ret knap, som der er implementeret andre steder i systemet. Dette ville også kunne bringe noget mere konsistens til systemet. Da en af testpersonerne løser opgave 4 på den måde som opgave 8 var tiltænkt og herefter løser opgave 8 uden problemer, tyder dette på at programmet er let at huske, hvilket er et af Molichs kriterier for brugbarhed. Ud over de listede problemer, fandt testpersonerne også frem til et par relevante tips til forbedringer til systemet (se 9.1). Tip 1 Tilføj ekstra tekstfelt under leverandør, så det er muligt at have et separat tlf-nummer på repræsentanten fra rmaet. Sådan har de det stående i deres papirer nu. Tip 2 Det skal være muligt at se hvilke varer der er i baren, blandt andet som et ekstra check i forhold til overførsler fra lager til bar. Flere problemer end dem der er listet blev fundet af testperson 5. Disse problemer skyldes dog testpersonens manglende erfaring med café branchen og manglende forståelse af branchens termer som bruges i forbindelse med de daglige rutiner i Café Chic (se 9.1). 4.6 Interview Mål Til evaluering af vores samarbejde med kunden foretages et kvalitativt interview. Vi vil her forsøge at afdække kundens oplevelser af samarbejdet og udviklingsprocessen. Ydermere skal fokus sættes på kundens forventninger til forløbet og om disse blev indfriet. Målet med interviewet er at få kundens synsvinkel på samarbejdet med udviklerne. Informatik Cafe Chic Lager

61 KAPITEL 4. EVALUERING Metode For at opnå et berigende interview, skal ere metodiske succeskriterier opfyldes. Intervieweren skal bl.a. løbende analysere, fortolke og danne mening af det sagte. Denne fremgangsmåde vil hjælpe intervieweren med at opretholde et fokuseret interview. Til at assistere os igennem interviewet har vi på forhånd udformet en række spørgsmål med fokus på samarbejdet (se 9.4 på side 104). Vi vil lave et semi-struktureret og eksplorativt interview (Kvale, 2001). Udførelsen af interviewet foregår hos kunden selv i vante omgivelser. Vi er i alt re personer til stede inklusiv kunden Resultat Kunden har udtrykt stor tilfredshed omkring samarbejdet. Kunden mener at der er mange virksomheder som er forbeholdende overfor denne type samarbejde, men at det i dette tilfælde har været en succesfuld og berigende proces. De første tanker omkring samarbejdet, var at det lød spændende, specielt i forhold til at de på forhånd er i færd med at undersøge mulighederne for nye systemer til at administrere kasseapparatet og lagerstyringen. Forventninger var ikke store fra starten af, i og med at kunden ikke havde så meget indblik i de krav, som samarbejdet ville stille i forhold til et universitetsprojekt. Samtidig synes kunden, at der var en del ting vi skulle blive enige om før vi kunne komme rigtigt i gang. Her tænkes hovedsageligt på tekniske termer og lignende, som for eksempel begreber som implementering og aeveringer. Det kan som udgangspunkt ikke forventes at kunden på forhånd har kendskab til disse termer, hvorfor det må forventes at kunden i starten vil stille mange spørgsmål og at vi som udviklere må forklare løbende. Efter at systemet og dets muligheder blev præsenteret til den første aevering, ledte dette til velovervejede krav, da kunden havde et større indblik i hvorledes kundeaktiviteterne praktiseres. En af de ting der var mest spændende i forløbet, var ifølge kunden, at følge med i hvordan systemet udviklede sig fra aevering til aevering i forhold til de historier som blev udarbejdet. Med hensyn til forberedelsestid var der i nogle enkelte tilfælde, hvor kunden kunne have ønsket sig lidt mere tid. Her menes specielt, da kunden for første gang skulle have udformet historierne til den første aevering. Som tidligere nævnt havde vi problemer med at tolke kravene ud fra historierne (se på side 22), så derfor tog vi kontakt til kunden igen og bad om tid til et møde, hvor vi sammen kunne gennemgå hvordan vi gerne ville have at de skulle udformes. Da vi samtidig var ivrige for at komme i gang med implementeringen og at det kun var historierne vi manglede, pressede vi her på for at få dem udfærdiget. I et sådant tilfælde ville kunden måske ønske at der var lidt mere forberedelsestid, da det kan være svært at få det til at passe ind i kalenderen. Kunden ville ligeledes gerne have en mere struktureret plan over vores deadlines således, kunne kunden tilpasse sin tidsplan i forhold til vores deadlines. Informatik Cafe Chic Lager

62 4.7. OPSUMMERING Med hensyn til møderne sammen med kunden blev der nævnt at til første møde, hvor hele gruppe på seks mand mødte op, virkede det overvældende og at denne var bange for, at det blev svært at holde et struktureret møde. Men ifølge kunden virkede det struktureret og velforberedt, idet at der var en leder der styrede dagsordenen, men at de andre deltagere samtidig bød ind når det passede sig. Med hensyn til kundens indydelse på systemets endelige form, var denne meget tilfreds. Vi havde været gode til at fange kundens ønsker inden for de relative få evner kunden har i forhold til IT. Det har ifølge kunden været utroligt at se hvordan vi har kunnet, ud fra relative små informationer, opbygge et system der stemmer overens med forventningerne. Kunden mener, at det rent faktisk har udmundet sig i et system der i princippet kunne tages i brug, som det ser ud efter sidste aevering. Vi spurgte desuden om der var nogle ting som kunden kunne tænke sig noget, som havde udformet sig anderledes i forhold til systemet. Det syntes kunden ikke, men udtrykker at efterhånden som aeveringerne bliver færdige, begynder mulighederne at vise sig. Kunden har indtil videre kun blevet præsenteret overfor pakkeløsninger, som skulle fungere som en universelløsning til caféer. Her blev kunden fascineret over, hvorledes systemudviklingen havde taget caféens specikke behov i betragtning. Specielt når brugergrænseaden tages i betragtning mener kunden, at de kan se hvor meget deres egen indydelse reekteres igennem systemets brugergrænseade. Hvis de køber en pakkeløsning, vil der være en stor del funktioner som de aldrig vil komme til at tage i bruge. Ifølge kunden er de systemer præget kommercielt, forstået på den måde at målgruppen er bred og det derfor er nødvendigt at systemet i sig selv er bredt (mere herom på side 75). Vi afslutter interviewet ved at spørge kunden om der er andre ting der skal nævnes som vi ikke allerede har været inde på. Her nævnes, igen brugbarhedstesten. Personalet har være meget positivt stemt overfor den. De var meget overraskede over den grad af professionalisme, der prægede denne del. De havde ikke forventet at vi havde gjort så meget ud af det og det var meget spændende. De havde ikke prøvet den form for test før, men kan se mulighederne i de informationer der indsamles. At det yderligere kan give feedback således, at et endnu bedre og mere brugervenligt system udvikles. 4.7 Opsummering Den kognitive gennemgang blev udført med det formål at nde en række brugbarhedsproblemer i systemet, så vi kunne rette dem inden den egentlige tænkehøjt test. De este af problemerne blev klassiceret som alvorlige, da mere end en ekspert stødte på dem. Disse blev rettet umiddelbart efter testen. De resterende problemer, der kun blev fundet af en enkelt ekspert, blev ikke rettet, men der blev holdt øje med dem under tænke-højt testen. Pilottesten ledte os til nogle problemer med udformningen af testspørgsmålene. Disse problemer forårsagede at testpersonens forståelse af opgaverne blev svækket og testpersonens tilgang til disse var dermed ikke som vi havde tiltænkt. Informatik Cafe Chic Lager

63 KAPITEL 4. EVALUERING Nogle af opgaverne krævede indblik i de forskellige varegrupper, hvilket ikke taget med i betragtning, da udformningen af testspørgsmålene blev rettet til. Under tænke-højt testen identicerede de fem testpersoner otte kosmetiske, fem alvorlige, et kritisk og et teknisk problem. Efter testen indledtes et debrieng interview, med det formål at testpersonerne kan uddybe og forklare de problemer der opstod under evalueringen. Ydermere blev testpersonen bedt om at kommentere systemet. Brugbarhedsproblemer blev klassiceret ved hjælp af Molichs klassikationskriterier. På baggrund af det udførte interview, kan vi opsummere en generel tilfredshed over samarbejdet fra begge parter. Ifølge kunden er det ikke sidste gang, at de vil lade sig indvillige i den form for projekter. De synes selv at de har lært utroligt meget omkring hvad der forventes af dem som kunder, de har lært utrolig meget omkring nogle tekniske aspekter og ikke mindst at arbejde sammen i nogle store grupper. Overordnet synes vi samtidig at vi har fået afsluttet samarbejdet på en fornuftig måde, hvor både vi som udviklere k sagt tak for indsatsen, men hvor kunden også havde mulighed for at komme med sine erfaringer og holdninger i forhold til samarbejdet og projektet i det hele taget. Informatik Cafe Chic Lager

64 4.7. OPSUMMERING Informatik Cafe Chic Lager

65

66 5.1. INDLEDNING 5.1 Indledning Vi vil i dette kapitel samle op på de processer vi har gennemgået i projektforløbet. Vi vil beskrive vores fremgangsmåde, analysere de problemer der opstod og beskrive hvordan vi løste dem. I denne forbindelse vil vi drage paralleller til XPs værdier og principper, hvor det er relevant, samt samle op på vores projektforløb i forhold XPs værdier og aktiviteter. Mange af de vigtige beslutninger, der er beskrevet i kapitlet, er endvidere dokumenteret i vores dagbog (se 9.3). Kapitlet er opdelt i syv dele: Foranalyse Omhandler projektforløbet fra projektets start til vi modtager de første historier fra kunden. 1. aevering Omhandler projektforløbet fra vi modtager vores første historier fra kunden til vi fuldfører første aevering. 2. aevering Omhandler projektforløbet fra vores første aevering til vi fuldfører vores anden aevering. Evaluering Omhandler brugbarhedsevalueringen af systemet. Samarbejde Omhandler gruppens interne samarbejde og gruppens samarbejde med vejlederen. Opsamling i forhold til XPs værdier Her samler vi op på vores proces i forhold XPs re værdier som er beskrevet i 2.2 på side 15. Opsamling i forhold til XPs aktivieter Her samler vi op på vores proces i forhold XPs re aktiviteter som er beskrevet i 2.3 på side 16. Figur 5.1: Tidslinie for projektforløbet Informatik Cafe Chic Lager

67 KAPITEL 5. ERFARINGSOPSAMLING De første re dele af kapitlet er illustreret i forhold til projektets forløb på gur 5.1. Femte del, Samarbejde, dækker hele forløbet. 5.2 Foranalyse Fremgangsmåde Som udgangspunkt havde vi valgt at ville samarbejde med Hjørring Politi i håb om at kunne få lov til at udvikle et program til gadebetjente. Vi tog telefonisk samt skriftlig kontakt til dem. Selvom vi blev lovet i første omgang at det sikkert var muligt, k vi dog afslag fra øverste instans. Derefter tog vi kontakt til en nyåbnet cafe i Aalborg; Café Chic. Et gruppemedlem fra vores gruppe kendte en af de tre ejere personligt og arrangerede et møde hvor hele udviklingsgruppen kunne møde ejerne og omvendt. Vi havde til dette møde forberedt os grundigt ved at udforme både spørgsmål som kunne hjælpe os selv til at afklare generelle spørgsmål omkring Caféen, ejerne, personalet, arbejdsgange samt hvilke problemer og udviklingsvilkår vi kunne forvente omkring projektet. Desuden havde vi også forberedt en lille præsentation hvor vi fortalte lidt om os selv, hvordan vores forventninger var og hvordan vi havde forestillet os dette projekt skulle løbe af dagen. Under mødet optog vi alt på bånd, det var vores forventning at dette ved senere analyse skulle hjælpe os til at få en dybdegående føling for de større problemer som kunden stod med Problemer og løsninger Det første problem vi stødte på var at vores primære kunde ikke var interesseret i et samarbejde da de selv var i gang med en større reform indenfor deres IT-område. Problemet knytter sig ikke til metoden, men er et studierelateret problem. Løsningen til dette problem afhjalp sig selv hurtigt, da vi k kontakt med en ny kunde samme dag som den første faldt fra. Det er dog med til at illustrere at vi i fremtidige projekter skal have en aftale helt på plads inden vi går videre i et projekt. Normalt vil kunden ikke trække sig tilbage igen, da det er dem der tager den første kontakt. Så problemet vil kun opstå i et studieprojekt. Under mødet k vi fastlagt hvilke problemer Cafe Chic for øjeblikket stod med: Det var tydeligt at de havde et stort ønske om et samlet system der kunne erstatte alle de nuværende separate systemer, hvilket for vores universitetsprojekt forekom alt for omfattende. De havde samtidig en meget besværlig, langsommelig og skriftlig tung metode til at styre deres varelager. Vi besluttede derfor, i samråd med kunden, at koncentrere os om afhjælpning af deres problemer omhandlende lagerstyring. Under det første møde kom der mange specikke og designmæssige gode forslag frem fra kunden om hvordan de ønskede et muligt lagerstyringssystem skulle se ud og fungere. Men for at omsætte dette til implementerbare problemer valgte vi at bruge nogle værktøjer fra XP (Se 5.3 på den følgende side). Det er vigtigt at pointere at kunden ønskede et IT-system til at kunne registrere og holde styr Informatik Cafe Chic Lager

68 AFLEVERING på varelageret a evering Fremgangsmåde For at præcisere kundens krav til systemet yderligere og udnytte XPs historiekoncept, afholdte vi et nyt møde med kunden (se 9.3). Her forklarede vi mere om metoden og hvad vi forventede af ham i forhold til XPs kunderolle. Vi medbragte historiekort og instruerede ham i hvordan han skulle udfylde dem. De historier vi efterfølgende modtog var dog ikke umiddelbart brugbare for os, da de Et lagerstyringsprogram der kan indeholde minimums varelager delt i højsæson og lavsæson. var meget overordnede og generelle. F.eks. lød én af historierne Vi afholdte derfor endnu et møde med ham hvor vi sammen kunne gennemgå hans behov (se 9.3). Dette resulterede i en række skitser og noter som vi efterfølgende fortolkede og omdannede til formelle historier (se 9.2 og gur 5.2). Figur 5.2: Udviklings historie Da vi havde skabt os et overblik over historierne, udvalgte vi de historier der var centrale for at systemet havde en solid bund at arbejde videre på (se ). Dernæst begyndte vi at eksperimentere med implementeringen i Visual Studio, hvilket foregik forholdsvis ustruktureret og på forsøgsbasis. Da vi mente vi vidste tilstrækkeligt om hvordan vi kunne implementere historierne, inddelte vi dem i opgaver, smed den eksisterende forsøgskode væk og startede forfra. Denne refaktorering udførte vi for at gøre koden så enkel som mulig, hvilket Kent Beck også anbefaler (Beck, 2002). Informatik Cafe Chic Lager

69 KAPITEL 5. ERFARINGSOPSAMLING XP foreskriver ikke noget specikt om hvordan man skal designe brugergrænse- ader. For at påbegynde denne proces valgte vi derfor enkeltvis at lave skitser ud fra de tegninger vi modtog fra kunden. Vores skitser blev derefter diskuteret i gruppen (se gur 5.3 og gur 5.4). Vi implementerede derefter et første udkast til brugergrænseaden. Vi benyttede under denne implementering en projektor for at sikre at alle medlemmer kunne komme med feedback til designet. Efterfølgende blev brugergrænseadens design ændret løbende, efterhånden som nye ideer opstod. For eksempel var vores brug af faneblade ikke en del af det o- prindelige design. Andre beslutninger, såsom at benytte en SQL database, blev taget efterhånden som det blev relevant, hvilket er i overensstemmelse med principperne i XPs designstrategi, hvor blandt andet trinvis design fremhæves (Beck, 2002). I forbindelse med selve programmeringen valgte vi i udpræget grad at følge XPs princip om parprogrammering. Dette bevirkede blandt andet at vi kunne korrigere hinandens fejl mens vi skrev og i parret diskutere forskellige fremgangsmåder til at implementere en opgave. Ifølge XP er det vigtigt at man tester meget og at man i den sammenhæng skriver test cases til hver opgave før man skriver sin kode. Det var først på dette punkt i projektforløbet at vi blev helt klar over hvordan programmet skulle struktureres, og hvor langt vi egentlig kunne komme med en meget begrænset mængde kode. Vi lagde derfor ikke stor vægt på automatisk test af koden, da vi hellere ville koncentrere os om andre dele af projektet (se 9.3). Samtidig havde vi dog nedskrevne krav, som vi arbejdede ud fra og en opgave var derfor ikke færdig før kravene var opfyldt. Endvidere var der ikke noget kode der blev integreret med resten af systemet, førend vi var sikre på at det opfyldte kravene. Fravalget af test cases gjorde os desuden i stand til at overføre ere ressourcer til andre dele af vores projekt, og betød at de enkelte iterationer var kortere. Vi ville hellere lægge ere kræfter i at producere noget konkret som vi kunne præsentere for vores kunde, da det som tidligere nævnt var samarbejdet med kunden vi ville koncentrere os om Problemer og løsninger Et generelt problem for projektet, som især blev synligt i denne del af projektforløbet, var at vi fra starten manglede erfaring med metoden og kundesamarbejde generelt. Det var også tydeligt at vores kunde også var helt uden erfaring i denne fremgangsmåde, hvor man involverer kunden så dybt i udviklingsprocessen. Vi havde svært ved at få kundens ønsker speciceret og programfunktionerne formidlet. Problemer opstod for eksempel da historierne skulle udfærdiges til noget konkret, så kodningen kunne påbegyndes. Kunden havde svært ved at levere konkrete historier og var usikker på hvad vi præcist ønskede af ham, hvilket resulterede i et tilbageslag for den samlede proces. Dette grundede sansynligvis i både vores egne, samt kundens manglende erfaringer indenfor samarbejde omkring et softwareudviklingsprojekt. Det udmøntede sig i at første iteration blev en længere og mere problemfyldt proces end først antaget. I sådan et tilfælde er det vigtigt at udviklerne uddanner kunden. XP foreskriver at en kunde i et XP-projekt skal være villig til at lære, villig til at tage beslutninger og villig til at engagere sig i projektet (Beck, 2002). Vi løste derfor problemet ved at indgå i en tættere dialog med kunden. I stedet for at lade kunden sidde med historierne og ansvaret alene, valgte vi at afsætte nogle timer til at uddanne Informatik Cafe Chic Lager

70 AFLEVERING Figur 5.3: Vi benyttede skitser som denne til at diskutere designet af brugergrænseaden Figur 5.4: Det færdige design af brugergrænseaden har i visse tilfælde ikke ændret sig meget fra den oprindelige skitse Informatik Cafe Chic Lager

71 KAPITEL 5. ERFARINGSOPSAMLING kunden. Ifølge XP er dette udviklernes ansvar. Vi udformede derfor historierne i fælleskab og vi k på den måde som udviklere også et bedre indblik i domænet. Det var ikke alle medlemmer af gruppen, der programmerede. Dette skyldtes blandt andet at vi har forskellig programmeringserfaring. Samtidig fandt vi det vanskeligt at arbejde på samme Visual Studio projekt samtidig, da det ikke altid var tydeligt hvilke ler man ændrede og om de forskellige versioner kunne integreres uden at overskrive hinanden, på trods af at vi brugte et versionsstyringsværktøj. Skulle man for eksempel denere et nyt databasekald til brug i én klasse i projektet, blev disse altid oprettet i én samlet l, der indeholdt alle denitioner for databasekald i hele projektet. Dette problem blev kun til dels løst da der i det meste af perioden kun var to personer der stod for programmeringen. Fordi disse programmerede sammen blev den del af problemet der berørte Visual Studio dog automatisk elimineret, idet der kun eksisterede en enkelt version af koden aevering Fremgangsmåde Da vi havde færdiggjort første aevering af vores system, kontaktede vi vores kunde for at præsentere aeveringen (se 9.3). Han var meget tilfreds med systemet indtil videre. Der var selvfølgelig nogle aspekter ved aeveringen han gerne ville have ændret, men de var få og ikke af omfattende karakter. Som vi havde forventet, eftersom vi havde brugt tid på at uddanne kunden, var det nu meget nemmere for ham at forestille sig nye historier til systemet. Dette skyldes også at kunden nu kunne se hvad historierne konkret udformede sig i. Dette betød at vi nu k betydeligt mere konkrete krav og historier fra kunden (se 9.3). Det var derfor ikke nødvendigt med den samme grad af fortolkning fra vores side, som det var tilfældet i første aevering. Historierne skulle dog stadig formaliseres for at give os et bedre overblik over hvad kunden ønskede, hvilket resulterede i historie 5-14 (se 9.2 på side 97). I forbindelse med førnævnte møde med vores kunde, k vi også en fornemmelse af hvilke af de nye historier han forventede var implementeret i næste aevering. Vi startede dog med at implementere de rettelser og mangler, som kunden havde påpeget da han blev præsenteret for første aevering af systemet. En af disse ændringer bestod i at systemet nu skulle designes til touch screen, hvilket betød at vi skulle ændre i dele af brugergrænseaden. Knapperne og teksten skulle gøres større, så det blev muligt at ramme ved brug af ngrene. Det er især ændringer som disse, som vi modtog da aeveringen skulle præsenteres for kunden, da han her havde mulighed for at interagere med det foreløbige system. Da vi havde udvalgt de historier, vi mente vi kunne nå at implementere til næste aevering, startede vi igen med at eksperimentere med koden i et separat projekt. Dernæst kasserede vi det projekt og startede forfra med at implementere de nye historier som en overbygning af den første aevering. Idet parprogrammeringen havde fungeret godt i forbindelse med forrige aever- Informatik Cafe Chic Lager

72 5.5. SAMARBEJDE ing, valgte vi at fortsætte med dette. Denne gang var der dog ere af gruppens medlemmer involveret i programmeringen, og det var derfor ikke kun to personer der havde ansvaret for hele implementeringen. Igen var der dog kun et par ad gangen der programmerede, på grund af de restriktioner vi følte Visual Studio pålagde os (se 5.3.2). Generelt var der dog ere personer involveret i programmeringen af anden aevering end der var i første aevering, idet der opstod situationer hvor hele gruppen fulgte med på skærmen, og rettede og kommenterede den igangværende implementering. Dette bevirkede at ere af gruppens medlemmer k dybere indsigt i implementeringsprocessen, og at vi alle følte et større ansvar for det system, der var lavet Problemer og løsninger Vi nåede ikke at færdiggøre anden aevering inden vores egen, internt fastsatte deadline. Dette betød at vi måtte arbejde ekstra for at færdiggøre aeveringen inden den kognitive gennemgang. Dermed blev denne også rykket et par dage, men det havde ingen indydelse på resten af tidsplanen, og vi var dermed klar til at udføre brugerevalueringen på det planlagte tidspunkt. Årsagen til dette skred i tidsplanen er muligvis at det ikke var muligt at præsentere kunden for første aevering, og dermed få nye historier, førend to dage efter vi egentlig var færdige med aeveringen. Vi påbegyndte derfor implementeringen af anden aevering senere end oprindeligt planlagt. En anden mulig årsag til at vi overskred deadlinen, kan være at vi havde problemer med at anslå hvor mange ressourcer vi skulle allokere de historier, vi ville implementere i anden aevering. Dog vil der næsten altid opstå uforudsete forhindringer i et projektforløb, som er besværlige at tage højde for i planlægningen af projektet. 5.5 Samarbejde Fremgangsmåde Vi valgte at anvende en række metoder som vi anså som succeskriterier til at opfylde ønsket om et konstruktivt, såvel som berigende projektforløb. Vi blev bland andet enige om at en gruppelederrolle måtte indføres, og at denne rolle skulle besættes af et nyt gruppemedlem hver uge. Gruppelederen er blandt andet pålagt ansvaret for at uddelegere arbejdsopgaver og træe projektrelaterede beslutninger. Vi arrangerede ugentlige evalueringsmøder, med det formål at hver gruppemedlem kunne modtage feedback på færdiggjorte afsnit. Endvidere kunne gruppelederen fremsætte forventninger til fremtidige bedrifter og dermed organisere k- ommende projektrelaterede opgaver. Når større beslutninger blev truet, blev dette noteret i dagbogen, såsom hvilket udviklingsmiljø vi ville udvikle i og hvilke metoder vi ville anvende til brugbarhedsevalueringen (se 9.3). Opgaverne blev oftest uddelegeret således at vi arbejdede i par. Denne fremgangsmåde blev praktiseret til fordel for kvaliteten og dybden af det skrevne. Informatik Cafe Chic Lager

73 KAPITEL 5. ERFARINGSOPSAMLING Færdigskrevne dokumenter blev udvekslet iblandt medlemmerne for at sikre enighed i det skrevne og at nødvendige ændringer i teksten blev foretaget. Vi anvendte versionstyringssystemet, Subversion; dennes intelligente dokumentstyringsfaciliteter tillader at ere brugere kan redigere i det samme dokument samtidigt. Samarbejdet med vejlederen foregik via møder mellem gruppen og vejlederen. Der blev aftalt at der skulle være møde hver onsdag morgen, med mindre at andet blev aftalt. Inden hver møde skulle materiale til gennemlæsning sendes senest to dage før. Dette var af hensyn til vejlederen, så han kunne få det til at passe med eventuelt overarbejde. Det betød at weekendens arbejde skulle samles og rettes igennem inden at det mandag eftermiddag blev sendt til vejleder. En af grundene til at vi valgte C# som programmeringssprog var at vi gerne ville have kendskab til et nyt programmeringssprog. C# læner sig op ad Java, som vi tidligere har arbejdet med, og derfor regnede vi ikke med at få store problemer med at prøve C#. De første forsøg med programmeringen blev foretaget således at der skulle optræde en jævnbyrdig forståelse af implementeringsprocessen. Vi anvendte en projektor, således at alle kunne følge med i implementeringen og dermed komme med input Problemer og løsninger Den ekstreme grad af parprogrammering vi praktiserede, var for tidskrævende, hvilket vi indså tidligt i udviklingsforløbet. Da aeveringsdatoerne nærmede sig manglede vi stadig at implementere de funktioner, som var fremsat som krav. Vi anså det som en nødvendighed at praktisere parprogrammering, som foreskrevet af XP, for at få implementeret de påkrævede funktioner. Den oprindelige tidsplan blev ikke overholdt, da vi i starten ikke havde klargjort projektets omfang. Vi brugte meget mere tid end først antaget på at fortolke de historier vores kunde fremsatte. Dette resulterede i at vi overskred den første aeveringsdato. Et møde med vores vejleder blev arrangeret, hvor vi diskuterede realistiske deadlines for aeveringer, dokumenter og evaluering. Herefter udarbejdede vi en tidsplan for resten af forløbet (se 9.3). De beskrevne projektstyringsmetoder bør tilegnes det specikke projektforløb. En regulær anvendelse af metoderne kan fremme at projektet bliver og forbliver kohærent. En ugentlig leder er f.eks. med til at sikre en gensidig involvering i projektet samt et overblik over projektets omfang. Informatik Cafe Chic Lager

74 5.6. EVALUERING 5.6 Evaluering Fremgangsmåde For at identicere uhensigtsmæssigheder og uklarheder i systemet, anvendte vi metoden kognitiv gennemgang (se 9.3). Gennemgangen tog udgangspunkt i realistiske opgaver, som den fremtidige bruger kunne tænkes at udføre. Opgaverne blev designet med den hensigt at alle aspekter i systemet skulle dækkes. Vi påtog rollen som brugbarhedseksperter og identicerede fejl som blev noteret i et skema, således at en berigende og konstruktiv diskussion kunne foretages efter gennemgangen. Vi diskuterede hvilke fejl der var hensigtsmæssige at rette, og disse blev efterfølgende rettet i systemet (se 9.3). Dermed håbede vi at kunne eliminere nogle af de problemer som brugerne eventuelt ville støde på under den senere brugerevaluering. Som forberedelse til vores brugbarhedsevaluering udførtes en pilottest, således at fejl i testopgavernes udformning kunne identiceres og rettes (se 9.3). Denne form for test blev anvendt som en tilrettelæggelse af den egentlige brugbarhedsevaluering, således at vi kunne danne et billede af, hvor meget tid der skal afsættes til evalueringen. Det er systemets funktionalitet og brugbarhed der skal testes, derfor er det en væsentlig faktor, at der ikke optræder nogle uklarheder i testopgaverne. En brugbarhedsevaluering blev udført med det formål at identicere eventuelle brugbarhedsproblemer. Som forberedelse til denne evaluering udførte vi som sagt en kognitiv gennemgang og en pilottest, således at testopgaverne blev tilrettelagt så hensigtsmæssigt som muligt. Evalueringen blev udført med fem testpersoner, hvoraf en af dem var vores kunde, tre af dem var ansatte ved kunden og den sidste var en informatikstuderende. Vi gjorde på et tidligt tidspunkt kunden opmærksom på at vi havde brug for nogle ansatte til at evaluere systemet, da det ville være optimalt hvis det var slutbrugeren der påtog denne opgave. Vi foreslog at komme med til et personalemøde for at se om vi kunne rekruttere nogle testpersoner. Men da dette ikke var muligt, k vi besked på at udarbejde et opslag, som kunden så kunne præsentere for medarbejderne til personalemødet. Dermed påtog kunden sig ansvaret for at rekruttere testpersoner blandt medarbejderne (se 9.3). Opslaget specicerede evalueringens omfang og mål, således at de interesserede medarbejdere kunne danne sig et billede over evalueringens forløb. Vi anvendte datalogiinstituttets usability lab til at udføre evalueringen, da vi mente at dets faciliteter ville gavne forløbet (se 9.3). Vi gjorde brug af muligheden for at optage processen, da vi kunne anvende optagelserne til analyse og fremtidig reference Problemer og løsninger Der opstod tekniske problemer under gennemgangen, når eksperterne redigerede i det samme data i databasen, da systemet er ikke designet til at håndtere inter- Informatik Cafe Chic Lager

75 KAPITEL 5. ERFARINGSOPSAMLING aktion fra ere brugere samtidig. Opgaverne blev derfor omstruktureret således at eksperterne redigerede i forskellige dele af systemet. Pilottesten ledte os til mangler, struktur- og formuleringsmæssige fejl i testopgaverne, ydermere opstod nogle uklarheder. Disse var forårsaget af testpersonens manglende indblik i de brugsdomænet, men dette var dog også forventet. Der var uklarhed om, hvor mange af kundens personale der ville stå til rådighed som testpersoner. Da det viste sig, at det kun var re personer, som var ledige, inklusiv kunden selv, supplerede vi derfor med en informatikstuderende. Selvom at 80% af systemets brugbarhedsproblemer kan afdækkes af 4-5 testpersoner (Rubin, 1994), følte vi alligevel at det ville gavne vores evaluering at indsamle empiri fra en femte testperson. 5.7 Opsamling i forhold til XPs værdier Kommunikation Kommunikationen mellem gruppen og kunden har været lidt svingende. Vi har altid været velkomne til at kontakte kunden, men det har ikke altid været muligt at få kontakt. De gange hvor vi har fået fat i kunden, har det ikke været noget problem at få mange oplysninger om de problemer som vi stødte på. Så generelt har kunden været meget hjælpsom. Der har dog været episoder hvor kommunikationen har svigtet, og aftaler ikke er blevet overholdt. Dette skete på grund af dårlig kommunikation. Da kunden skulle lave de første historier, var han ikke blevet informeret godt nok om hvorledes disse skulle skrives, og derfor var de ikke klar til tiden, og vi blev nødt til at forsøge at forklare hvordan det skulle gøres endnu en gang. Gennem parprogrammering har ere personer kunnet komme med input til koden, og dermed ville ere også automatisk få større indblik i det kode der er blevet skrevet, end hvis koden blev skrevet enkeltvis. Ved at kode parvis, har vi haft lettere ved at holde gang i kodningen, da vi ikke har oplevet at gå helt i stå så ofte som i tidligere projekter. Så kommunikationen mellem programmørerne har været med til at hjælpe os til at få skabt den rigtige kode hurtigere. Efter første aevering k vi en god diskussion med kunden om systemets udseende og funktionalitet, hvor vi k valideret det, der var blevet lavet. Kunden fremstillede også nye historier som skulle implementeres. Mange af disse var i høj grad mere konkrete end de tidligere historier, hvilket vi mener skyldes at kunden undervejs blev uddanet i metoden, hvorved han bedre kunne forholde sig til et konkret system, som han kunne gå ud fra og bygge videre på. Dette hjalp os en hel del, da de mere konkrete historier lettede den senere implementering. Samtidig har den tætte kundekontakt som XP foreskriver, haft stor indydelse på et system der skærer direkte ind til grundfunktionaliteterne. Kunden udtrykker, som tidligere sagt, at mange nuværende løsninger består i pakkeløsninger der indeholder en meget bred funktionalitet, med en række funktioner der ikke vil blive benyttet. Her mener vi at XP har hjulpet os til netop at undgå dette. Informatik Cafe Chic Lager

76 5.7. OPSAMLING I FORHOLD TIL XPS VÆRDIER Enkelthed Vi har prøvet på at holde systemet enkelt, ved kun at kode lige præcist det som historierne lagde op til. Nogle gange har vi ment at systemet ville være bedre med en ekstra funktion. Andre gange har vi haft diskussioner om hvordan systemet skal håndtere nogle givne situationer, som slet ikke havde relevans for systemet på det stadie som vi var nået til. Dette er sket i situationer hvor vi ikke har haft tankerne på XP, men så snart vores tanker er kommet over på XP er diskussionerne stoppet, da vi ikke skal kode mere end højst nødvendigt. Så der er ikke mere med i vores aevering end hvad kunden har skrevet i historien. Dette kan have været en af grundene til at kundens reaktion på første aevering var at det virkede meget simpelt, og at det ikke var fyldt med alle mulige ekstrafunktioner Feedback Vi har ikke brugt feedback helt så meget som vi burde ifølge XP. Men når vi har fået nogle historier fra kunden, har vi prøvet at estimere hvor lang tid det ville tage at programmere den del af systemet, så kunden kunne vide hvornår der ville komme en aevering. Vi har fået feedback fra forskellige tidsplaner, som har kunnet fortælle om vi har været foran eller bagefter planen, og om vi dermed ville kunne nå det som vi regnede med. Kunden har dog ikke været med inde over denne tidsplan. Vi har udviklet systemet så det kunne blive klar til brug så hurtigt som muligt, forstået på den måde at vi har sørget for at den første aevering af systemet skulle kunne registrere oplysninger som varegrupper, leverandører og så videre. Dette er vitale dele for at systemet kommer til at køre, da der ikke vil kunne holdes styr på et lager uden at kunne vælge hvad der er på lageret. På denne måde vil vi hurtigere kunne få feedback fra kunden om hvad der er godt og skidt ved systemet, og dermed få optimeret systemet så kunden får det system der passer til hans ønsker og behov Mod Første gang vi stødte på store problemer med koden valgte vi at smide hele koden ud, og starte forfra. Dette viste sig som en så god løsning, så vi fortsatte med at bruge den hver gang vi fremover kom til noget nyt. Var vi ikke helt sikre på hvordan noget nyt kode skulle se ud, prøvede vi os frem, og når vi fandt frem til en løsning der fungerede efter hensigten, blev koden droppet, og det nye kode blev skrevet ind i systemet. På den måde endte vi op med et system, som ikke er fuld af slamkode, men i stedet er meget overskueligt, og består af så lidt kode som muligt. Informatik Cafe Chic Lager

77 KAPITEL 5. ERFARINGSOPSAMLING 5.8 Opsamling i forhold til XPs aktiviteter Programmering Nøjagtig som XP-metoden foreskriver, har vi brugt koden til at lære og kommunikere med. Vi har i løbet af dette projekt i forhold til programmering prøvet os meget frem, bakket lidt tilbage når det gik galt og derefter prøvet igen. Dette har været en utrolig god måde til selv at lære at kode på. Da vi valgte at programmere i et, for os ukendt, udviklingsmiljø og samtidig også valgte et ukendt programmeringssprog, er der gået utrolig mange tidsressourcer af til at lære begge disse ting at kende. Det er gået ud over bl.a. testværktøjer, som vi o- prindeligt havde planlagt at sætte os ind i, men hvor vi vurderede at vi hellere ville allokere de ressourcer til andre dele af projektet (se 9.3). Vi har brugt parprogrammering, som har været en kæmpe succes, da vi her har oplevet at vi kunne hjælpe og støtte os meget til hinanden. Hvad den ene ikke lige kunne overskue, havde den anden en god ide til. Dette forhindrede bl.a. at man sjældent sad fast i en programmeringsopgave, men samtidig også at vi kunne kommunikere med hinanden igennem koden og lære af hinandens evner Test XP ligger stærkt op til at man tester meget. Både gennem automatiserede test cases og funktionalitetstests. Her har vi ikke fulgt XP metoden fuldt ud. Vi har gennem historierne og samtaler med kunden formaliseret funktionelle krav, som vi efterfølgende har implementeret (se 9.3). Denne fremgangsmåde fandt vi gentagende gange succesfuld i forhold til vores kundes forventninger. Vores kunde var god til, gennem diskussion og historier, at forklare hvad han forventede retur af systemet ved bestemte interaktioner. Dette formaliserede vi til konkrete krav, som i bund og grund svarer til funktionalitetstests, og det var ved hjælp af dette vi implementerede systemets funktioner. Automatiserede tests, såsom unit tests, har vi ikke benyttet, da vi hellere ville koncentrere os om hurtigt at få et funktionelt system ud til kunden. XP er primært beregnet til brug i erhvervslivet, hvor blandt andet kvaliteten af den udviklede software er særdeles vigtig. Det er derfor Kent Beck lægger så meget vægt på test af koden. Han siger dog samtidig at man skal tilpasse metoden til sin situation (Beck, 2002). Da dette er et læringsprojekt om brugersamarbejde, har vi derfor prioriteret nogle aspekter af XP højere end andre. Her er test et af de aspekter der er blevet nedprioritetert i forhold til for eksempel samarbejde med kunden Lydhørhed Under dette projekt har vi bestræbt os på at være meget lydhør overfor kunden igennem hele samarbejdet. Nedenfor har vi listet to eksempler (se også 9.3). Indledende problem: Her gjorde kunden udtryk for generelle erhvervsmæssige problemer. Det værende sig dagligdagsproblemer samt ønsker og krav til et fremtidigt it-system. Løsning: Her hjalp vi kunden med at afgrænse krav til systemet så det lå Informatik Cafe Chic Lager

78 5.8. OPSAMLING I FORHOLD TIL XPS AKTIVITETER indenfor et realistisk mål. Problem under udviklingen: Kunden havde problemer med at udfærdige historier korrekt. Løsning: Her skolede vi kunden og hjalp ham bl.a. ved at vi udfærdigede historierne sammen Design I vores programkode har vi gennem refaktorering hele tiden forsøgt at strukturere vores kode så den blev bedst mulig. Med dette forstås kode som er enkel, let at forstå, at programdele ikke er gentaget og at hver enkelt programdel ikke laver ændringer i andre programdele. Det har været en god ting at have for øje, da vi i forhold til tidligere projekter kan se en simplere og mere overskuelig programstruktur. Dette behøver dog ikke kun at være grunden. Det kan skyldes det udviklingsmiljø vi har brugt, eller at vi simpelthen har fået mere erfaring i at kode og dermed tænker over strukturen mens vi koder. XP har ingen metoder til at sikre at brugergrænseaden af systemet bliver brugervenlig. Her har vi måtte trække på tidligere erfaringer fra design af brugergrænseader. Informatik Cafe Chic Lager

79

80 6.1. METODEKRITIK Vi vil i dette afsnit diskutere XP metoden, vores anvendelse af den og sammenligne den med andre metoder. Vi vil opsummere vores oplevelser fra dette projektforløb og trække på tidligere erfaringer med andre metoder. 6.1 Metodekritik Hvis vi skal se på hvordan XP som metode forholder sig til vores indledende spørgsmål (Se kapitel 1.2), så er det som første skridt en forudsætning at sætte sig grundigt ind i XP og dernæst udføre den i praksis. Vi har i dette projekt været nødt til at tilpasse visse værktøjer og arbejdsgange i forhold til XPs grundform. Dette skyldes, som nævnt tidligere, at XP er designet til industrien og ikke et universitetsprojekt. Det kan derfor altid diskuteres om vores bøjning af XP har indvirket på det samlede resultat. Vi har i så vid udstrækning som mulig anvendt XP hvor vi mente det var hensigtsmæssigt i forhold til projektet omfang og fokusområde. Kent Beck beskriver selv i sit værk at man skal tilpasse XP lokalt (Beck, 2002, s.39). Han skriver også at man kun skal indføre én XP-regel af gangen (Beck, 2002, s.115), men at man ikke får fuldt udbytte af XP før alle reglerne er taget i brug (Beck, 2002, s.137). Vi har under dette projekt gjort os nogle erfaringer med XP som vi vil gennemgå her. Vi vil diskutere fordele og ulemper som vi har oplevet med XP under dette projekt. Disse oplevelser vil vi holde op mod tidligere metoder som vi har erfaringer med, som Objekt-Orienteret Analyse & Design (Mathiassen et al., 2001) i projekt LIVIN'FO (Petersen et al., 2005) og Struktureret Program-Udvikling (vandfaldsmodellen) fra (Biering-Sørensen et al., 2002) i projekt Partybox (Petersen et al., 2004) Samarbejde med brugeren Fordele I XP er hovedfokus lagt på samarbejdet med brugeren. Dette gør at alle værktøjer i metoden er baseret på et tæt samarbejde. Kunden er en del af udviklingsteamet. Det giver store fordele med hensyn til pludseligt opståede implementeringsproblemer; som f.eks. Ville kunden nu have en rund eller en rkantet knap?, for kunden er altid omkring udviklerne med et hurtigt svar. Det er med til at sikre at kunden får et tæt samarbejde med udviklerne og dermed mest mulig indydelse på det færdige produkt. OOAD og vandfaldsmodellen er baseret på et grundigt forarbejde, hvor det er meningen at alle problemer og krav skal afdækkes på forhånd. Dette har vi i tidligere projekter oplevet som besværligt, da der næsten altid opstår uforudsete problemer eller uklarheder. Dette betyder i andre metoder at der skal ændres i henholdsvis designdokumentet (OOAD) eller kravsspecikationen (SPU). I XP tager man bare udfordringerne som de kommer. Informatik Cafe Chic Lager

81 KAPITEL 6. DISKUSSION Ulemper I et så tæt samarbejde som XP forskriver, kræver det imidlertid en engageret og kompetent kunde. Det kræver utrolig meget tid og mange ressourcer fra kunden side. Kent Beck forsvarer det med at de afsatte ressourcer tjener sig selv ind på længere sigt, da det færdige produkt vil have en højere kvalitet, være bedre tilpasset til kundens krav og kræve mindre vedligeholdelse. Dette har vi dog også selv oplevet da vi havde en meget engageret kunde (se på side 61). Men et scenario med et ringe kundeengagement kan nemt ende i et dårligt produkt, da ere XP-værktøjer forudsætter kommunikation med kunden Udvikling af programmel Fordele XP har ingen tilhørende dokumenter til programmet. Dette betyder at man fra starten kan gå direkte i gang med at kode. Det kræver så at man er villig til tit at smide en mængde kode væk og begynde forfra hvis f.eks. kravene ændrer sig undervejs i udviklingen. Men det betyder netop også at man kan ændre noget helt op til sidste aevering. OOAD og vandfaldsmodellen tillader ikke sådanne ændringer, de har ikke som XP direkte værktøjer eller aktiviteter til at håndtere sådanne tilfælde. Vi har gennem projektforløbet også erfaret at parprogrammering, som er et af hjørnestenene i XP, er et godt værktøj for vores gruppe. Vi har forskellige kodeerfaringer og er på forskellige niveauer indenfor programmering. Parprogrammering er med til at hæve den samlede standard hvis man parer rigtigt, dvs. de mindre øvede sammen med de erfarne. Ulemper I XP er det kunden som har det sidste ord. Han sætter dermed et stort præg på det færdige produkt. I XP er det også en regel at man ikke implementerer mere end det kunden forlanger. Begge disse ting er med til at holde kreativiteten og innovationen på et minimum, hvis ikke udviklerne eller kunden selv er klar på at prøve nye tiltag. Kreativitet kommer tit af vilde ideer eller nye måder at se ting på. Hvis ikke udviklerne får lov til at komme med disse vilde ideer vil udviklingen stå stille Skiftende krav Fordele XP metoden er som før nævnt god til at håndtere skiftende krav. I løbet af tidligere projekter med bl.a. SPU, har vi erfaret at det brugerne i starten af et projekt siger de vil have, ikke altid er det samme som det de egentlig vil have. Dette bevirker at man kan være uheldig at stå med et slutprodukt som er fuldstændig ubrugeligt. I XP er der iterationer som ville afhjælpe dette problem, da brugerne allerede tidligt i et udviklingsforløb bliver præsenteret for færdige elementer af det samlede system. Vi oplevede selv i løbet af dette projekt at små ting fra kunden var Informatik Cafe Chic Lager

82 6.2. EVALUERING PÅ SLUTBRUGERE OG KUNDE misfortolket i historierne, men at de let kunne rettes fra aevering til aevering. Derved oplevede vi at vi denne gang kom frem til et slutprodukt som faktisk lå over det kunden havde forventet (Se kapitel 4.6). Ulemper Et XP projekt kan trække i langdrag hvis kunden hele tiden ændrer krav. Hvis ikke kunden fra starten af kan formidle til udviklerne præcist hvad han mener, vil man som udvikler opleve at man hele tiden sidder og ændrer eller omskriver kode. Hvis man følger XP, herunder faktorerne (Se kapitel 2.4 på side 17), vil kunden dog løbende blive gjort opmærksom på dette problem. 6.2 Evaluering på slutbrugere og kunde I dette projekt har vi testet det færdige produkt på de tiltænkte slutbrugere; ejer og ansatte ved Café Chic. Vi udførte dog en enkelt brugbarhedstest samt en pilottest på brugere som ikke havde kontakt til café-miljøet og derfor ikke var egentlige slutbrugere. Vi gjorde den opdagelse at disse to personer ere gange stødte ind i samme problemer (dog af mindre alvorlig karakter) og at netop disse problemer ikke blev oplevet af slutbrugerne. Problemerne som de to personer oplevede relaterede til forståelsen af branche-termer og har derfor ikke nogen betydning for den tiltænkte brug af vores system. Vi kan herfra udlede at det er en vigtig faktor at teste på tiltænkte slutbrugere når det handler om programmets anvendelighed i den rette kontekst. Som en afsluttende del af evalueringen valgte vi at lave et interview med kunden dagen efter brugbarhedsevalueringen. Her k vi opsamling på vores samarbejde og fandt frem til ere ting som ikke blev belyst under testen. Bl.a. havde kunden og de andre testpersoner efterfølgende diskuteret programmet og en eventuel ibrugtagning i caféen. Vi k også belyst kundens side af vores samarbejde og hans oplevelser igennem projektforløbet. Dette interview er utrolig vigtigt og tungtvejende med henblik på den samlede evaluering af samarbejdet, men især også af programmet. Man kan lave et nok så brugervenligt program, men hvis det ikke er det som kunden forventer, vil det aldrig blive sat i brug. 6.3 Valg af kunderepræsentant I XP er det tætte samarbejde med brugeren i højsædet. Vi vil her diskutere dette punkt i forhold til et af vores essays (Se kapitel 9.8 på side 109). I dette essay diskuteres hvorledes det er muligt at have en tilstedeværende kunde, der er ekspert i domænet og samtidig skal træe beslutninger der repræsenterer kundeorganisationens ønsker. Essayet konkluderer at uanset hvilken person fra rmaet, der bliver valgt, vil det blive meget svært at repræsentere begge sider. Det vil vi her tage op i forhold til samarbejdet med vores kunde. Ifølge Kent Beck er en af de vigtigste aspekter af XP at kunden er i stand til at træe beslutninger med meget kort varsel, hvilket vil sige at det skal være en medarbejder med store beføjelser og derfor sandsynligvis også højt rangeret i rmaet. Men samtidig skal det være en medarbejder, der har stor indsigt i Informatik Cafe Chic Lager

83 KAPITEL 6. DISKUSSION domænet, helst en fremtidig slutbruger. Her er problemet ofte, at de højere rangerende medarbejdere i en virksomhed ikke har en dyb indsigt i det domæne, der skal repræsenteres. Dette er selvfølgelig ikke en gylden regel, og i vores tilfælde repræsenterer kunden faktisk begge sider. For det første er han chefen og ejeren af rmaet, og for det andet repræsenterer han samtidig slutbrugeren, hvilket medfører en stor indsigt i domænet. Som udgangspunkt lyder det som den optimale situation, men der er imidlertid nogle andre faktorer der spiller ind. Idet at det er et mindre rma, er ledelsen repræsenteret af få eller som i vores tilfælde én person. Dette rejser et nyt problem. Kan rmaet undvære denne medarbejder i længere perioder? Som der ligeledes ræsonneres i essayet er det ofte ikke tilfældet, at denne person rent faktisk kan undværes og at rmaerne ofte ikke er klar over, hvor vigtigt det er at de sender den mest kompetente medarbejder. Disse problemer oplever vi derfor også igennem projektforløbet, da det til tider var svært at lave aftaler på kort sigt, da kunderepræsentanten ikke altid kunne undværes i rmaet. 6.4 Sammenfatning Samarbejdet med kunden har gjort at vi ofte hurtigt har kunnet ændre i systemet, hvis kunden ikke har været helt tilfreds. Dette har dog krævet at kunden har skullet afsætte meget tid til projektet, hvilket ikke altid har været en mulighed. Det betyder også at kode ofte skal smides ud, da kunden kan ændre mening hvis kunde og udviklere ikke helt har forstået hinanden. I projekter som vores, hvor samarbejdet foregår med den øverste i virksomheden, og samtidig slutbrugeren af systemet, vil der blive udviklet et system hvor brugernes rutiner er implementeret, og dermed får kunden et system som kan bruges uden megen vedligeholdelse. Ved at slutbrugeren har været med hele vejen igennem projektet, har det også været naturligt at evaluere produktet gennem ham via en tænke-højt test. Informatik Cafe Chic Lager

84 6.4. SAMMENFATNING Informatik Cafe Chic Lager

85

86 Vores mål med dette projekt har været at udvikle et lagerstyringssystem i samarbejde med Café Chic i henhold til semestrets tema, Design og vurdering af et edb-system i samarbejde med brugere. Vi valgte XP som udviklingsmetode, da denne netop lægger stor vægt på samarbejdet mellem kunde og udviklere. XP foreskriver ikke præcist hvordan man starter et projekt og vi indledte derfor forløbet med en foranalyseperiode, hvor vi skabte en præliminær kontakt til kunden. Her k vi fastsat rammerne for samarbejdet og forsøgte at skabe os et overblik over den kommende udviklingsopgave. Dernæst begyndte det egentlige XP-udviklingsprojekt. I samarbejde med kunden udviklede vi de første historier, som vi efterfølgende omdannede til opgaver og implementerede. Vi benyttede os af XP principper som bl.a. parprogrammering og refaktorering under implementeringen af denne første aevering af systemet. Kunden blev derefter præsenteret for aeveringen. Dette resulterede i rettelser af implementerede historier, samt udvikling af nye historier. Igennem samme fremgangsmåde som under første aevering, blev anden og sidste aevering udviklet. Det færdige system skulle efterfølgende evalueres. Vi valgte først at udføre en kognitiv gennemgang, hvor vi som brugbarhedseksperter løste opgaver ved hjælp af systemet. De fundne problemer dannede derefter grundlag for rettelser i systemet. Inden de endelige brugbarhedstests gennemgik vi ligeledes en pilottest, der skulle eliminere eventuelle problemer i forhold til de udformede spørgsmål. Den rettede version blev derefter evalueret af fem brugere til en tænke-højt test. Fire af brugerne var faktiske slutbrugere, ansat ved Café Chic. Til slut interviewede vi vores kunde for at evaluere vores samarbejde i forbindelse med det nu afsluttede projekt. Her udtrykte kunden stor tilfredshed med samarbejdet, hvor specielt kvaliteten af de afholdte møder blev fremhævet. Forventningerne til systemet var ikke store, men også her er kunden meget tilfreds med slutresultatet. Kunden blev mere og mere engageret i projektet, jo længere vi kom med det, da han kunne se at systemet udviklede sig i retning af det han gerne ville have. Det eneste der var problematisk ifølge kunden, var at der ikke altid var forberedelsestid nok. Baseret på vores erfaringer i forbindelse med udviklingsprojektet kan vi nu svare på de spørgsmål, vi opstillede i problemformuleringen. Vi starter med at svare på underspørgsmålene og samler dernæst op under hovedspørgsmålet. Hvordan kan XP støtte samarbejdet mellem udvikler og bruger? Et tæt samarbejde mellem udvikler og bruger er en af grundpillerne i XP, og metoden indeholder derfor en betydelig støtte i forhold til dette samarbejde. Her er en tilstedeværende kunde helt central. Vi havde dog ikke mulighed for at arbejde så tæt med kunden som XP foreskriver, hvilket betød at der til tider opstod tvivlsspørgsmål. Desuden bevirkede den store afstand til kunden at kommunikationen nogle gange fejlede, og kunden ikke altid var indforstået med hans rolle i projektet. Efterhånden som samarbejdet skred frem, blev vores kunde dog mere fortrolig med sin rolle og vores samarbejde blev tilsvarende Informatik Cafe Chic Lager

87 KAPITEL 7. KONKLUSION mere udbytterigt. Da det samtidig er kunden der fra aevering til aevering denerer systemets funktionalitet, er man som udvikler sikker på at man kun implementerer det som kunden har forlangt. De hyppige aeveringer som er en del af XP, har desuden bevirket at kunden har haft nemmere ved at give feedback og fremsætte nye funktionaliteter til fremtidige aeveringer. Dette betyder dog at kravene til systemet hyppigt ændres. Hvilket der, til forskel fra traditionelle metoder såsom vandfaldsmodellen, tages højde for i XP. Hvordan kan vi tilstræbe at det endelige produkt lever op til brugerens forventninger? Ifølge XP skal kunderollen besættes af en fremtidig slutbruger, hvilket også var tilfældet med vores kunde. Hans dybe indsigt i domænet må betyde at de historier han fremlagde var relevante for udviklingsprojektet. Kundens feedback i forbindelse med aeveringerne be- eller afkræftede at historierne var implementeret i forhold til hans forventninger. Traditionelle udviklingsmetoder inddrager sjældent brugeren i samme omfang, og det endelige produkt afhænger derfor af udviklernes evne til at analysere domænet. Vores inddragelse af faktiske slutbrugere i brugbarhedsevalueringen af systemet og det afsluttende interview med kunden, bekræftede desuden til dels at produktet levede op til brugernes og kundens forventninger. Hvordan kan vi benytte Extreme Programming (XP) i vores udviklingsforløb? Det tætte kundesamarbejde, som er centralt for XP, nder vi yderst brugbart i forhold til vores udviklingsprojekt, og vi kan anbefale et endnu tættere samarbejde. Vi har, på trods af den manglende erfaring i begyndelsen, opnået en stor indsigt og erfaring med inddragelse af brugere. Værktøjer som kundens historier har blandt andet været en af de store hjælpemidler i den sammenhæng. For det første har kunden opnået en større indydelse i den faktiske udformning, men samtidig har vi som udviklere lært meget omkring dialog med kunden. Det er dog vigtigt at vi tager os god tid til at uddanne kunden i forhold til hans rolle i udviklingsforløbet. En af de ting som har gjort det muligt for os at bekræfte, at vores dialog med kunden har fungeret, har været de hyppige aeveringer. Det er her at vi har kunnet bekræfte hvorvidt produktet lever op til kundens forventninger, og om at dialogen har fungeret. Det tætte samarbejde som foreskrives i XP er helt klart faldet ud til vores fordel. Selve programmeringsdelen har ligeledes været meget lærerig, idet at vi ikke før har forsøgt os med parprogrammering. Det er vores erfaring at to hoveder tænker bedre end ét, hvorfor vi således erfarer at det fra starten har udmundet i kode, der underbygger kundens problemstilling. De hyppige refaktoreringer har ligeledes hjulpet os med at holde koden enkel og overskuelig. Evalueringen af det endelige system har blandt andet vist at det levede op til brugernes og kundens forventninger. Informatik Cafe Chic Lager

88 Dette projekt har været karakteriseret ved et fokus på brugersamarbejde. I den forbindelse har vi fundet Extreme Programmings værktøjer og principper utroligt hjælpsomme da de, baseret på vores erfaringer, fremmer og støtter dette samarbejde. Vi kan kun anbefale et tættere samarbejde i fremtidige udviklingsprojekter. Informatik Cafe Chic Lager

89

90 I perspektiveringen vil vi beskrive de muligheder der er for systemets videreudvikling. Med kundens efterhånden større indblik i de aktiviteter og værdier som udgør udviklingsprocessen, er der nu grundlag for mange ere historier. Kunden har lært at formulere historierne, således at vi som udviklere lettere kan fortolke historiernes krav og implementere disse. På den baggrund er der potentiale for, at der indenfor en overskuelig tidsramme, kan færdigudvikles et komplet system. Kunden er indforstået med at det ikke er muligt at implementere alle de funktionaliteter som der ønskes, men at der derimod fokuseres på lagerstyrringen. Figur 8.1: Kunden ville placere det færdige system i baren, hvor personalet nemt ville have adgang til det. På nuværende tidspunkt har kunden allerede forslået en del fremtidige forbedringer af systemet. Her kan der blandt andet nævnes muligheden for synkronisering mellem systemet og en PDA. Ideen er her at der er mulighed for at opdatere lageret i baren via en PDA, hvilket vil gøre det lettere og samtidig eliminere behovet for papir. I det tilfælde hvor der skal overyttes varer fra lageret til baren, medtages PDA'en blot til baren, hvor der registreres hvilke varer der mangler på hylderne. Herefter vil der komme en udskrift på lageret, og varerne vil kunne yttes op i baren. På samme måde vil den være en god supplering i forhold til nye leverancer, hvor brugeren kan registrere de nye varer så snart de bliver indleveret af fragtmanden. Kunden har erfaring med at hardware i en bar tit går i stykker, her omtales især keyboards. Det ville derfor være en god ide at indføre et elektronisk keyboard som kan aktiveres via touch screen'en. Det ville også samtidig spare plads omkring systemet. Informatik Cafe Chic Lager