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

Transkript

1 15pt0pt

2

3 Department of Computer Science Informatik Fredrik Bajers Vej 7E DK-9220 Aalborg Øst Titel: Workout & Fitnesss Tema: Design og vurdering af et edbsystem i samarbejde med brugere Projektperiode: INF2, Forårssemester 2006 Projektgruppe: i202a Deltagere: Mikkel Bundgaard Lars Holm Christiansen Brit Susan Jensen Kasper Wittrup Højris Jensen Mads Kristian Wallin Pedersen Alex Ranch Vejleder: Janne Jul Jensen Oplagstal: 8 Sidetal: 92 Afsluttet den 30. Maj 2006 Synopsis: Denne rapport behandler udvikling af software i samarbejde med brugere. Der anvendes extreme Programming(XP) som udviklingsmodel for processen. Samarbejdspartneren i dette projekt er en mindre virksomhed, der sælger samt udlejer diverse tness produkter til private samt rmaer. Virksomheden har ønske om at optimere deres arbejdsrutiner, ved hjælp af implementering af ny software løsninger, da de eksisterende systemer ikke længere opfylder virksomhedens krav. Gennem denne proces vil XP bliver evalueret som udviklingsmetode, hvorved vi vil specicere kritikpunkter og styrker. Programmet er udviklet i et Java udviklingsmiljø og efterfølgende er der udført en brugbarhedstest på programmet for at afdække og klassicere eventuelle brugbarhedsproblemer.

4

5 Forord. Vi ønsker at takke Thomas Storm fra Workout & Fitness, uden hans hjælp ville det ikke have været muligt at gennemføre dette projekt. Thomas formåede at tage tid ud af hans travle kalender gentagende dage, for at kunne arbejde sammen med os. Møderne har været yderst produktive og vi er sikre på, at vi alle har lært meget af disse. Læsevejledning Til rapporten er tilknyttet en CD indeholdende udarbejdet materiale i form af kildekode og færdigt prototype-program. Kildehenvisninger er angivet som (forfatter, årstal) og en kildeliste ndes i kildeliste - se indholdsfortegnelse. I rapporten igennem anvendes udtrykket vi, og er udtryk for gruppen som har udarbejdet denne rapport. Forkortelser vil forekomme, angives som følgende eksempel: ExtremeProgramming(herefter XP). Appendiks indeholder udarbejdet materiale fra gruppen og er materiale som er udarbejdet af gruppen, men som ikke er relevant i rapporten. Mikkel Bundgaard Lars H. Christiansen Mads Wallin Brit Susan Jensen Kasper Wittrup Alex Ranch

6

7 Indhold. 1 Indledning Problembeskrivelse Problemformulering Indledende virksomhedsbesøg Mål Overvejelser Resultat af mødet Virksomhedsbeskrivelse Lageret Bogføring Ønsker til et nyt system XP Metoder Introduktion til XP Case værktøjer til XP X-planner Test Driven Development og J-unit Fælles udvikling Design Udviklingsmetode Planning game Hyppige udgivelser Metaforer Enkelt design Test Refaktorering Fælles ejerskab timers arbejdsuge Kundetilstedeværelse

8 3.4 Programmering Kunden er tæt på Kode standarder Test Driven Development Par programmering Integrer ofte Alle skal være med til at kode Opsummering Iterationer Første iteration Brug af brugerhistorier Kravliste Release Kommunikation Brugermøde Feedback Forbedringer til kommunikation Konklusion Anden iteration Kravliste Release Kommunikation Feedback Konklusion Opsummering af processen Metode kritik af XP Krav ændres løbende Brugsmønster vs. Brugerhistorier Anvendelse af XP Refaktoring Test driven development Mangel på ansvarsdeling Jo simplere, jo bedre Koden er designet Koden er selv-dokumenterende Caseværktøjer Positive erfaringer med XP Universitetsprojekter Opsummering

9 6 Estimering og usikkerheder Estimering Opsummering Tanker vedrørende software udvikling Gidseltagning i Extreme Programming Orden i kaos Konsekvenser Acceptance test 55 9 Test Testformål Teori Opstilling af test Fremgangsmåde Resultater Test overvejelser Konklusion Diskussion Samme projekt, to fremgangsmåder Samme fremgangsmåde andet projekt Konklusion Fremtidig arbejde Fremtiden for vores program A Mødeprogram 75 B Brugerhistorier 77 B.1 Interview guide C Introduktion til test 81 C.1 Testspørgsmål C.2 Samtykkeerklæring C.3 Demogrask data af testpersoner D Essays fra Software loso 85 D.1 Gidseltagning i Extreme Programming? D.2 Orden i kaos

10 D.3 Konsekvenser

11 Figurer. 3.1 Screenshoot af X-planner Forskrifterne supplerer hinanden Forløb i udvikling af software gennem TDD Et system til at udføre løbende test Screenshoot fra første iteration Screenshoot fra anden iteration Godkendelseskriterier for test Skema til katagorisering af fundne problemer Opstilling i Usabilitylab Fundne og klassicerede problemer fra brugbarhedstesten C.1 Samtykkeerklæring C.2 Demogrask data

12 FIGURER FIGURER 10

13 . KAPITEL 1 Indledning Dette projekt er udarbejdet i forbindelse med semestret INF2 ved Aalborg Universitet med det overordnede tema: Design og vurdering af et edb-system i samarbejde med brugere Formålet med dette projekt er at opnå erfaring i metoder og teknikker til samarbejde med brugere i udviklingsarbejde baseret på design, realisering og evaluering af prototyper. Vi vil i denne rapport dokumentere processen og erfaringerne fra udviklingen af et stykke software til rmaet Workout & Fitness. Projektet vil forløbe efter udviklingsmetoden Extreme Programming (XP). Det er vores mål at softwaren til Workout & Fitness kan anvendes i almindelige arbejdsrutiner, hvorved virksomhedens arbejdsopgaver eektiviseres. 1.1 Problembeskrivelse I det daglige arbejde hos Workout & Fitness bruges forskellige applikationer til både administration, håndtering af salg samt lagerstatus. Således er den nuværende forretningsgang, at et salg registreres ved at rmaets webløsning sender en til salgsafdelingen, der efterfølgende ringer op til køberen, for at aftale betalingsform samt levering med mere. Sælgeren skriver derefter kundens personlige oplysninger ind i et dokument, der benyttes som faktura. Dernæst skrives oplysninger vedrørende handlen, manuelt ind i virksomhedens økonomisystem. Til sidst sendes der besked til lageret om, at den bestilte vare skal afsendes. Ligeledes når der opgøres status på lageret, foregår dette ved at optællingen foretages, hvorefter resultatet sendes via , for derefter at blive indført i et regneark. Systemerne der bruges til at udføre dette arbejde har altså ingen, eller ringe indbyrdes sammenhæng, hvilket betyder at de ansatte ofte skal skifte mellem ere applikationer, for at løse deres arbejdsopgave. Dette medfører at tidsforbruget ved gennem-

14 1.2 Problemformulering 1 Indledning førelse af en bestilling synes at være for stort samt at muligheden for fejl indtastninger øges, hvilket vi vil søge at eektivisere. 1.2 Problemformulering Vi ønsker vha. XP at udvikle en applikation der muliggør en forbindelse mellem disse forskellige applikationer i den centrale styring, med særlig fokus på optimering af arbejdsgangen omkring lagerarbejdet i Flensborg. I udviklingen af denne applikation ønskes brugerinddragelse jf. XP forskrifterne, for derigennem at sikre succesfuld kravbeskrivelse samt implementering. Ovenstående leder os frem til følgende problemformulering: Hvorledes udvikles der med brug af XP, en applikation der kan sammenkoble de forskellige systemer virksomheden benytter nu, og hvilke erfaringer kan vi danne ud fra denne proces? 12

15 . KAPITEL 2 Indledende virksomhedsbesøg Inden selve udviklingen begyndte havde vi et initierende møde med virksomheden Workout & Fitness for at danne os et indtryk virksomheden, som vi ønskede at skrive projekt med, og for at vi kunne mødes med den repræsentative gruppe fra virksomheden. Vores mål var her at beskrive vores projekt og hvorledes det skulle forløbe. Det er dette vi beskriver i dette kapitel. 2.1 Mål Som første led i vores samarbejde med virksomheden Workout & Fitness, besluttede vi at hele gruppen skulle deltage i det første møde med virksomheden. Formålet med vores indledende besøg var til dels ment som en introduktion til virksomheden, og vore fremtidige samarbejdspartner. En del af mødet skulle samtidig foregå som et kvalitativt interview, i form af det Kvale (Kvale, 1994) kalder et delvist struktureret, kvalitativt eksplorerende interview (Se bilag B.1 på side 80). På mødet præsenterede vi vore mål med projektet, samt undersøgte hvad virksomheden kunne opnå gennem dette samarbejde. Herefter gav vi en generel kort introduktion til software-udviklingsmodeller, dernæst specikt om brugen af XP, samt hvad udvikling efter XP betyder for virksomheden. Herunder et tæt samarbejde og gentagende møder med repræsentanter for virksomheden. 2.2 Overvejelser En del af vore overvejelser inden mødet omhandlede hvorledes vi kunne sikre et højt udbytte af mødet. Dette søgte vi at opnå gennem det delvist struktureret eksplorerende interview. Spørgeformen var åben og fulgte et naturligt ow. Interviewet og de indledende spørgsmål var stillet med henblik på, at få

16 2.3 Resultat af mødet 2 Indledende virksomhedsbesøg et overblik over organisationen som helhed, samt at få et detaljeret indblik i de daglige arbejdsopgaver. 2.3 Resultat af mødet Igennem mødet k vi klarlagt forretningsgangen i virksomheden, samt et detaljeret indblik i arbejdsgangen i form af daglige opgaver. Samtidig gav mødet også virksomheden en introduktion til vores forventninger og hvilke fremgangsmetoder de kunne forvente vi ville anvende. Dette har været med til at danne videre grundlag for samarbejdet med Workout & Fitness. 2.4 Virksomhedsbeskrivelse Samarbejdspartneren Workout & Fitness er et lille rma med under ti medarbejdere, oprettet i 1997, fordelt på 2 geograske lokationer henholdsvis; Århus, virksomhedens hovedsæde, samt Flensborg. Flensborg afdelingen fungerer som lager samt butik, og er placeret i Tyskland af konkurrencemæssige årsager. Produkterne består af diverse typer af tness udstyr, alt fra mindre vægtsæt til større motionsmaskiner, så som motionscykler, træningsbænke etc. Virksomheden sælger primært produkter til private personer, dog køber rmaer også større tness løsninger hos Workout & Fitness. Virksomhedens nuværende hjemmeside kan ndes på Kundesegmentet er typisk personer i alderen år hvilket virksomhedens web løsning afspejler, idet betalingen foregår ved almindelig bankoverførsel således kunden har en fast kontaktperson på kontoret i Århus. Ved modtaget betaling sendes varen direkte fra lageret i Flensborg til kunden. Det er endnu ikke muligt at betale via hjemmesiden, hvilket der dog arbejdes på Lageret Lageret har ikke nogen elektronisk lagerstyringsfunktion, hvilket medfører at resultater af vareoptællinger manuelt skal indføres i et regneark. Vareforsendelsen sker ved salgskontoret kontakter lageret og beder dem sende de bestilte varer. Elektronisk lagerstyring er derfor også et ønske, således salgsafdelingen er i stand til at se lagerstatus samt at sammenholde denne, med hjemmesiden. Levering af varer sker så vidt muligt, som dag til dag levering. Dog afhænger dette af valgte fragtmand. 14

17 2 Indledende virksomhedsbesøg 2.4 Virksomhedsbeskrivelse Bogføring Bogføring i virksomheden foretages i C5 Light, som er en ældre version med DOS brugerade. Der er et udpræget ønske om bogføring stadig skal foretages i et C5 miljø, men at bogføringssystemet bliver opdateret til C5, samt at det integreres med lagerstyring, bestilling og faktureringen fra hjemmesiden Ønsker til et nyt system De nuværende systemer er ikke i tilstrækkelig grad integreret med hinanden, hvorfor der foretages en del manuel gentagende arbejde. Eksempelvis indføres bestillinger fra hjemmesiden manuelt i bogføringssystemet, ligesom der manuelt skal sendes besked til lageret om at afsende produkter. Det er bl.a. disse arbejdsgange der ønskes optimeret og integreret i et samlet system, således en del af det administrative merarbejde minimeres betydeligt, jf. nedenstående punkter. Integration mellem web og bogførings systemer Elektronisk lagerstyring Betalingsgateway på hjemmeside Mindsket gentagende administrations overhead, som følge af gentaget arbejde 15

18 2.4 Virksomhedsbeskrivelse 2 Indledende virksomhedsbesøg 16

19 . KAPITEL 3 XP Metoder I dette afsnit vil vi beskrive grundelementerne i XP samt hvordan udviklingen bør foregå efter XP. Ydermere vil vi behandle de caseværktøjer der anbefales til udviklingen, samt hvordan udviklingsprocessen bør forløbe ifølge XP. 3.1 Introduktion til XP Extreme Programming (XP) is actually a deliberate and disciplined approach to software development (Wells, 1999). XP adskiller sig fra det traditionelle udvikling paradigme, som f.eks. vandfaldsmodellen, ved i langt større grad, at sætte kunden i fokus i sammenlignet med det traditionelle paradigme. Dette fokus på kunden gennem hele udviklingsprocessen er vigtigt i XP idet kunden derved får et bedre indblik idet software der er under udvikling. Dette sætter kunden bedre i stand til at træe rationelle beslutninger om mulige ændringer i softwaren, selv sent i udviklingsprocessen. I XP lægges der stor vægt på de re kerneværdier som er; kommunikation, enkelthed, feedback og mod. Samlet set er dette med til at sikre en agil udviklingsproces. Eksempelvis igennem praksisen omkring parprogramming, sætter XP stor fokus på kommunikation. Yderligere er XP opbygget efter en ad struktur hvor alle har et fælles ansvar, idet der ofte skiftes rundt blandt udviklerne. Således står en enkelt udvikler ikke til ansvar for en komplet del af systemet, men mange delelementer. Ved at lade udviklerne rotere inden for projektet, muliggøres det også at give feedback på program-stumper, hvilket er medvirkende til at skabe ensartet kode. Igennem hele processen holdes en tæt kundekontakt og udgivelser til kunden sker hurtigt i projekt forløbet.

20 3.2 Case værktøjer til XP 3 XP Metoder 3.2 Case værktøjer til XP Der ndes en række udviklingsværktøjer til brug i XP der understøtter projekteringen og udviklingen af softwaren. Nogle af disse værktøjer vi vil beskrive i de følgende afsnit X-planner X-planner er et tidsestimeringsværktøj til at understøtte udviklingen, ved at holde rede på brugerhistorier i udviklingsiterationerne. Efter nogen tids brug, kan udviklerne bruge X-planner til at hjælpe med at estimere tidskrævende iterationer, baseret på data indsamlet under tidligere iterationer. Yderligere hjælper værktøjet med at holde styr på hvilke udviklere der er tilknyttet hvilke brugerhistorier, samt hvor langt udviklingen af opgaverne er kommet. For illustration af X-planner se gur 3.1 Figur 3.1: Screenshoot af X-planner Test Driven Development og J-unit Teorien bag brugen af Test Driven Development(TDD) foreskriver at der på forhånd skrives unit tests til den kode der skal skrives. Dette gøres for at sikre at den kode der skrives, ikke indeholder unødvendige funktioner idet der kun skal skrives nok kode til at unit testen kan gennemføres uden fejl. 18

21 3 XP Metoder 3.3 Design Således fungerer unit testene som succeskriterier for udviklingen, og disse er med til at validere at softwaren er færdig udviklet. Til at skrive unit test, bliver frameworket J-unit anvendt, som kan integreres direkte med de este Java udviklingsmiljøer, hvilket i vores tilfælde er Borland JBuilder Fælles udvikling Til at styre kildekode lerne anvendes Subversion, hvilket er en forbedring af det ældre CVS, som versionsstyringsprogram. Til dette anvendes TortoiseSVN for at holde rede på opdateringer og nye tilføjelser fra gruppen. TortoiseSVN er en grask overbygning til SVN således det undgås at anvende en konsol. 3.3 Design Udviklingsmetode XP består af en række regler, hvor enten alle, eller ingen af disse regler skal anvendes. Disse regler understøtter ifølge XP hinanden i en symbiotisk eekt, som vist på gur 3.2. Pilene mellem reglerne (punkterne) indikerer hvordan de balancerer og forstærker hinanden. Figur 3.2: Forskrifterne supplerer hinanden Planning game For at få det meste ud af udviklingsperioden forskriver XP, at udviklerne fra starten planlægger forløbet i samarbejde med kunden. Dette sker både 19

22 3.3 Design 3 XP Metoder for lade kunden føle at teamet har tingene under kontrol, men samtidig også en mulighed for at se hvad teamet gennemgår på forskellige tidspunkter i forløbet. Da kunden er i stand til se hvornår teamet udvikler på bestemte arbejdsområder, vil det være nemmere at komme med spørgsmål og ideer på det rigtige tidspunkt. Det er således kunden der er i den bedste position til at vurdere hvilke dele af systemet der har den højeste prioritet. Derimod er det udviklerne der kan vurdere hvilke opgaver der har den største kompleksitet og hvilke opgaver der således bør påbegyndes først. Ved hjælp af gruppens erfaringer fra tidligere projekter skulle udviklerne således være i stand til at fastsætte et reelt udviklingsforløb for at sikre projektets succes Hyppige udgivelser Efter en nøje planlægning ligger XP op til der udgives udgivelser med mindre tidsintervaller, så kunden vha. Planning game samt de forskellige udgivelser vil være i stand til at komme med indskydninger i form af ideer, for på den måde få de mest nyttige funktioner udviklet på mindst tid. Således vil udviklerne selv fra starten af forløbet være i stand til at starte på selve udviklingen af softwaren, og vha. af hyppige aeveringer være i stand til at minimere omkostningerne ved ændringer. Minimeringen af omkostningerne sker i kraft af at kunden gennem de hyppige udgivelser kan nde fejl, og derved kan der korrigeres for disse, således der ikke videreudvikles på fejl. De hyppige udgivelser hjælper således kunden med at ændre retningen af udviklingen for derigennem at sikre enighed mellem kundens ønsker og det som udvikles Metaforer Metaforer benyttes til at hjælpe kunden for at give forståelse for udviklingen vha. noget genkendeligt for kunden, eksempelvis at omtale et databasesystem som et adressekatalog eller telefonbog. Metaforer kan ligeledes benyttes internt i udviklingsteamet, således at hvis en delgruppe ikke mestrer et delemne, kan en anden delgruppe forklare sammenhængen vha. en metafor Enkelt design XP foreskriver, at softwaren ikke må indeholde redundant kode og skal således kun være i stand til at fuldføre alle testcases. Dette kan minde om en øvelse (Tufte, 1992) beskriver for graske designere: Design en gur, fuldstændig som man vil. Fjern derefter elementer uden at fjerne noget information. Når der ikke er mere der kan slettes, står man tilbage med det rigtige design. 20

23 3 XP Metoder 3.3 Design Altså bør det undgås at implementere unødige og overkomplicerede metoder i bestræbelserne på at opnå et enkelt design Test I XP skrives testcasene først og efterfølgende skrives koden. Årsagen til dette er, at man derved anskueliggør de krav og formål, den efterfølgende kode skal kunne opfylde. Udviklerne opnår derved simplere kode og det overordnede mål fastholdes. Dette giver samtidig en mere stabil og funktionel kode, se: (Beck, 2002), da hver enkelt del bliver gennemtestet før den bliver tilføjet til den eksisterende kode. Består den nye kode ikke testen fejlfrit, refaktoreres denne indtil dette er tilfældet. Dette skaber mere tillid til koden, både for udviklerne og kunden. Se også afsnit på side Refaktorering Når et udviklingspar tilføjer ny kode til den samlede systemkode, er det vigtigt at de overvejer om der kan laves ændringer til den eksisterende kode, der kunne gøre deres implementering lettere. Hvis implementeringen lykkes og den gennemløber samtlige tests fejlfrit, kan udviklerne overveje om de kan se nye måder at forbedre koden på. Det er denne gennemgang og søgen efter forbedring af systemkoden der kaldes refaktorering. Måden udviklerne nder frem til, at det er nødvendigt med refaktorering, kan f.eks. være hvis der er redundant kode. Eksempelvis hvis metoder har næsten samme funktion, kan disse laves til en enkelt metode der opfylder begge krav, hvilket resulterer i en simplere og mere overskuelig kode Fælles ejerskab For at opnå det bedst mulige udbytte af de forskellige udvikleres erfaringer, opfordres disse til løbende at tilføje ændringer og opdatere kode igennem hele systemet. Udviklingen foregår ved at der programmeres i par og at der hyppigt roteres rundt, så alle programmører har haft del i alt kode i større eller mindre grad. Derved undgås at enkelte udviklere får ejerskab over en bestemt del af koden. Hvis et udviklingspar nder muligheder for at opdatere systemkoden, eller det er nødvendigt at ændre koden for, at implementere nye dele, så bør de foretage disse ændringer. Udviklernes kendskab til det samlede system afhjælper også de mulige fejl og problemer disse løbende opdateringer ville kunne skabe. 21

24 3.3 Design 3 XP Metoder timers arbejdsuge I XP udviklingsmetoden er kreative og oplagte udviklere et vigtigt element. Arbejdsopgaver i udviklingen bør være fastsat således udvikleren ikke overbelastes med arbejde, således de ikke kan møde udhvilet og oplagte op næste arbejdsdag. Et eksempel på dette kan være en 40 timers arbejdsuge. Dette betyder dog ikke, at der ikke er plads til overarbejde hvis uventede problemer opstår, dog vil der ikke komme noget godt ud af gentaget overarbejde. I sådanne tilfælde står projektgruppen overfor et dybereliggende problem, der ikke kan løses ved overarbejde Kundetilstedeværelse Kundetilstedeværelse er et vigtigt element i XP udviklingsmetoden, fordi den hjælper med at sikre udviklingens og systemets succes. Kunden er en repræsentant for virksomheden der udvikles til, der har forståelse for hvad der kræves af systemet, samt hvordan det skal anvendes. XP foreskriver at der gøres nytte af en onsite costumer, hvilket betyder at kunden ikke bare skal være et element man forhandler med og udvikler til. Men derimod ønskes det at kunden er en aktiv del af udviklingsholdet, så det derved er muligt at diskutere eventuelle tvivlsspørgsmål i selve udviklingsprocesen. Formålet med kundetilstedeværelsen er, at søge at sikre et bedre slutprodukt, ved at lade kunden besvare udviklernes spørgsmål samt træe beslutninger vedrørende udviklingen. Brugerhistorier Brugerhistorier minder lidt om brugsmønstre, dog er brugsmønstre mere proces orienterede samt skrevet af udvikleren. Brugerhistorier er små historier skrevet af brugerne af systemet. Disse historier skal kort fortælle hvad delelementer af systemet skal kunne. Eksempelvis kunne en brugerhistorie beskrive, hvorledes et salg forgår fra start til slut, hvorimod et brugsmønster for samme scenario ville beskrive den specikke proces. Brugerhistorier erstatter samtidig kravspecikationen. Idet en kravspecikation er et endegyldigt dokument, bruges en sådan specikation ikke ifølge XP idet et af kerne elementerne i XP er at kunden skal kunne ændre kravene til systemet løbende gennem projektet. Brugerhistorier er dog ikke endegyldige krav til delelementet, men lige så meget en indikator af sværhedsgraden af det ønskede element. Udvikleren kan således bruge disse brugerhistorier i planlægningsfasen, til estimering af hvor lang tid det vil tage at udvikle den specikke del af systemet. Under udfærdigelsen af brugerhistorierne er kundens opgave at forklare udvikleren 22

25 3 XP Metoder 3.4 Programmering problemstillingen, med henblik på at udvikleren skal få indsigt i problemstillingen samt have mulighed for at stille uddybende spørgsmål. Udgivelser Når brugerhistorierne er lavet, afholdes et udgivelsesmøde, hvori det bestemmes hvornår de forskellige udgivelser skal nde sted. Rækkefølgen af udgivelserne bestemmes i samarbejde med kunden. Møder XP foreskriver standup meetings som en måde at komme hurtigt i gang med dagens opgaver, samtidig med at hele holdet bliver sat ind i ændringer. Grunden til at møderne afholdes stående er for at sikre at de ikke trækker ud. Dette er ligeledes med til at holde diskussionerne små, samtidigt med at hele holdet bidrager til mødet. 3.4 Programmering Kunden er tæt på Et af kerne-elementerne i XP er, at have kunden tæt på under hele processen hvilket også gælder i programmeringsfasen. Hvis muligt tilrådes det ydermere, at kunden aktivt hjælper med til selve udviklingen af programmet. Kundens primære funktion er, at fungere som et værktøj til at sikre produktet lever op til egne forventninger og krav. Dette sikres ved at kunden, med hjælp fra udviklerne, skriver brugerhistorier og er med til at fastsætte deadlines for udgivelser, samt prioritering af de forskellige udgivelser. Kunden tilrådes også at være med til at teste de forskellige udgivelser, da disse test ligger til grund for vericering af udgivelsens modenhed Kode standarder Udviklerne skal indbyrdes aftale, hvordan koden opstilles og hvilken navngivningsstandard der benyttes. Dette gøres for at opnå ensartet kodelayout, hvorved alle udviklere bedre er i stand til at læse og forstå hinandens kode. Ifølge XP er ens kodelayout noget man stræber efter, dog er det opnå svært at opnå fuldstændig ensartethed. 23

26 3.4 Programmering 3 XP Metoder Test Driven Development Inden selve programmeringen påbegyndes, overvejes det hvilke test der skal udføres for koden er tilstrækkelig udviklet. Sideløbende med udviklingen skrives yderligere test. Først når koden består testcasene, er udviklingen færdig. Det er derfor vigtigt at tilføje alle tænkelige testcases. Test Driven Dvelopment,TDD, er også en fordel ved refaktorering af kode, da det bliver lettere at refaktorere kode, idet det hurtigt kan afgøres om den refaktorerende kode, lever op til kravene fastsat i testcasene. Inden en testcase skrives, overvejes det først hvad der er nødvendigt at teste. Derefter skrives testen, og testen udføres for at sikre at den fejler. Herefter skrives den kode som denne testcase har til formål at validere. Dette er illustreret i gur 3.3. Eksempler på testkode kan ses på den medfølgende CD. Figur 3.3: Forløb i udvikling af software gennem TDD Alle testcases bør så vidt muligt automatiseres, således det ikke kræver menneskelig fortolkning af testresultaterne. Hvis testene tager længere tid, kan der i stedet anvendes smoking tests (Larman, 2005), som betyder at de længerevarende test cases kun afvikles 4 gange om dagen. For at kunne udføre løbende test, kræves det at store dele af udviklingen automatiseres. Denne automatisering er illustreret på gur 3.4 på næste side. En server henter løbende opdateringer til kildekoden fra versionstyringsprogrammet(subversion/cvs). Herefter afvikles alle testcases, og når testcasene 24

27 3 XP Metoder 3.4 Programmering validerer korrekt, overføres de til webserveren. Figuren illustrere hvordan det kunne foregå ved et webudviklingsprogram. Figur 3.4: Et system til at udføre løbende test Par programmering Parprogrammeing er en programmeringsform hvor to programmører deles om en computer. Ideen med parprogrammeing er at trods tiden det tager at producere et stykke kode øges, bliver kvaliteten af koden samtidig højere, ifølge (Cockburn and Williams, 2001). Derved ender man med at spare tid og omkostninger senere i processen, da der ikke er nær så mange fejl og der skal rettes i programmet. Parprogramming besidder samtidig den fordel, at det er med til at uddanne udviklerne og give ensartet kode. XP foreskriver at der til et par af programmører hører ét tastatur, en mus, samt at de to udviklere bytter plads med jævne intervaller for at sikre kvaliteten. 25

28 3.5 Opsummering 3 XP Metoder Integrer ofte Udviklerne skal stræbe efter at udgive kode så ofte som muligt. Det er især vigtigt at et udviklingsteam ikke holder på et stykke kode i mere end en dag af gangen. Løbende udgivelse af kode medvirker til at undgå en afvigende og fragmenteret udvikling, idet alle har adgang til den sidste nye kode. Dermed kan udviklerne til stadighed holde sig opdaterede med både funktionalitet af kode, samt have overblik over processen som helhed. Ydermere er det vigtigt at integrationerne fra de forskellige programmerings grupper koordineres så der ikke forekommer konikter eller programmeres videre i forældet kode Alle skal være med til at kode XP tilråder at alle medvirker til at kode og dermed er med til at nde nye ideer i alle aspekter af projektet. Dette medfører at der ikke er enkelte udviklinghold der ejer et stykke kode, hvorved alle udviklere vil kunne ændre og optimere alle dele af systemet. Denne tankegang medfører også at der ikke er en chef arkitekt på hele systemet. Alle i projektgruppen vil derfor være lige ansvarlige for det samlede system. 3.5 Opsummering Vi har i dette kapitel gennemgået og beskrevet hvorledes XP-metoden er opbygget af en række forskrifter der, ifølge (Beck, 2002), understøtter og forstærker hinanden. Disse forskrifter bygger på XP-metodens ånd om teamwork, kommunikation, enkelthed og feedback. Teamwork gennemføres vha. parprogramming, omrokering af udviklerne, møder samt fælles ejerskab. Alt dette er med til at sikre at alle udviklere har kendskab til alle aspekter af udviklingen, samt friheden til at gennemføre ændringer i hele kildekoden. Kommunikation gennemføres via den tætte kundekontakt, understøttet af brugerhistorier samt metaforer. Enkeltheden bliver understøttet af de fælles kodestandarder, hyppige aeveringer og refaktorering. Feedback kommer i udviklingen igennem de hyppige iterationer, kundekontakten, test og integrationerne. Alle forskrifterne understøtter hinanden indbyrdes og er med til at sikre en produktiv udvikling, der ikke er underlagt de traditionelle udviklingsparadigmers stringente opdeling af analyse og design. Dermed giver det udviklerne og kunden mulighed for, at indgå et tæt samarbejde hvor der hurtigt kan implementeres nye ændringer og stadig sikre et resultat af høj kvalitet. 26

29 . KAPITEL 4 Iterationer I kraft af at udviklingen gennemgår ere iterationer, bliver udviklerne i samarbejde med kunden, mere og mere opmærksomme på dennes ønsker. Således opnås der med tiden et system, der er lever op til kundens ønsker. 4.1 Første iteration Efter udarbejdelse af brugerhistorier i samarbejde med kunden gik vi igang med at designe GUI'en. Efter første iteration resulterede det i følgende; se gur 4.1 på den følgende side. Vores udgangspunkt var at designe en brugerade med store knapper med ikoner som medarbejderne intuitivt kunne associere til deres dagligdag. Årsagen til at udvikle GUI'en allerede i første iteration var, at give kunden et bedre indtryk af et fungerende program tidligt i processen. På denne måde ønskede vi at gøre kunden mere tryg ved programmet, for således at minimere eventuelle problemer forbundet med ibrugtagningen af systemet. Samtidig fungerede GUI'en som en overordnet arkitektur for funktionaliteter der skulle laves i kommende iterationer. Endvidere valgte vi i slutningen af iterationen at begynde udviklingen af enkelte funktionaliteter i metodelaget af programmet. Dette betød at vi skabte kontakt imellem vores program og den SQL-database server der indeholder lagerstatus, varenumre, priser osv. Dette var for at opnå bedre indblik i hvordan programmet i fremtiden skulle håndtere dette data Brug af brugerhistorier Ud fra de brugerhistorier vi k fra kunden, se appendiks B på side 77, kunne vi fastlægge nogle specikke krav til systemet. F.eks. kunne historien om lageroptælling omsættes til kravet om mere automatisering. Dette er i overensstemmelse med kundens ønske om at systemet selv skal løse gentagende og trivielle opgaver. Ud fra disse informationer besluttede vi at designe systemet således, at når lagerstatusen på et givent produkt ændres, skrives dette

30 4.1 Første iteration 4 Iterationer Figur 4.1: Screenshoot fra første iteration automatisk til den database som hjemmesiden bruger til at vise lagerstatus for kunderne. Denne funktion gør hele den nuværende procedure fuldautomatisk, hvilket derfor sparer tid hos både lagermedarbejderne, ledelsen og kunden Kravliste Der er fra kundens side stillet forskellige krav til systemet; bl.a. skal det automatisere en del af det gentage arbejde, der på nuværende tidspunkt forekommer i virksomheden. Ydermere skal der automatisk sendes en ordrebekræftelse, når en kunde har foretaget et køb via hjemmesiden. Når der bliver lavet optælling, indkøb, salg etc. skal systemet og hjemmesiden automatisk opdateres, således lagerstatus altid stemmer overens. Systemet skal desuden have funktioner der kan lave produktbestillinger, således brug af ere forskellige applikationer overødiggøres. Ydermere skal systemet kunne holde rede på hvem der har lejet et givent produkt, samt hvor lang tid det har været udlejet. Nedskrivningen af dette produkt skal ligeledes beregnes af systemet. Disse krav er at nde i de brugerhistorier der er blev udarbejdet i samarbejde med kunden. Brugerhistorierne 28

31 4 Iterationer 4.1 Første iteration kan ndes i appendiks B på side Release Efter ca. 14 dages udvikling sendte vi første iteration til kunden som i løbet af et par dage skulle gennemgå første iteration og komme med kommentarer ved brugermødet. Formålet med dette var at få respons på hvordan udviklingen af programmet forløb i forhold til de krav og brugerhistorier som blev udarbejdet fra starten. Således ville der allerede kunne tages hånd om uforudsete problemer og krav, således disse føres videre til næste iteration Kommunikation Gennem første iteration har vi benyttet forskellige kommunikationsformer, i vores kontakt med kunden.vi har primært, grundet den fysiske afstand, benyttet os af telefonisk kommunikation, samt korrespondance. Ved større beslutninger og designvalg valgte vi at tage til Århus for at holde personlige møder med kunden. Ved det første møde med kunden, var formålet at igangsætte projektet, derfor var hele gruppe med til mødet i Aarhus. Dette gentog vi da der skulle udarbejdes brugerhistorier. Som substitut for kunden der, i kraft af virksomhedens begrænsede størrelse, til tider havde de nødvendige ressourcer at afsætte til projektet, rettede vi i stedet denne kommunikation mod et gruppemedlem. Dette gjorde vi da vedkommende har indsigt i virksomhedens arbejdsmåder i kraft af sit fritidsarbejde i virksomheden. Dette gruppemedlem kom derfor ofte til at fungere som både en del af udviklingsholdet samt som kunde, hvilket var en stor fordel da gruppemedlemmet havde stort kendskab til de tekniske sider af det eksisterende system. Dette havde en vital rolle i udviklingen, idet mange af de tekniske spørgsmål kunne besvares omgående af vedkommende, i kraft af dennes overblik over det eksisterende system Brugermøde Slutningen på første iteration skulle have været et brugermøde med kunden for at igangsætte anden iteration. Dog blev vores kontakt med kunden begrænset i forhold til hvad vi havde håbet på. Det var i denne del af første iteration, vi valgte at benytte os af gruppemedlemmet der havde tilknytning til kunden. Gruppemedlemmets erfaring inden for virksomheden, samt kontakt med kunden via MSN Messenger og , gjorde at vi k den nødvendige respons og kritik til at kunne afslutte første iteration og fortsætte til anden iteration. 29

32 4.1 Første iteration 4 Iterationer Feedback Da det primært var GUI'en der var udviklet, gav kunden ikke så meget feedback, da kundens fokus mere lå på funktionaliteten af programmet. Dog blev der noteret, at kunden ønskede bedre navigation i programmet, gerne ved hjælp af en tilbageknap, således det altid vil være muligt at komme tilbage til hovedmenuen. GUI'en gjorde det således muligt for kunden at se hvordan de forskellige funktioner var planlagt til at se ud i programmet, hvilket denne fandt tilfredsstillende Forbedringer til kommunikation Grundet de, til tider, lange svar tider på s valgte vi, som tidligere nævnt, i slutningen af første iteration at benytte MSN Messenger. Idet kommunikation i Messenger automatisk bliver gemt på computeren blev det således muligt for hele gruppen på et senere tidspunkt at gennemse denne kommunikationen med kunden, for vericering af vores implementeringsforslag. Ved denne opdatering af vores kommunikationsform håbede vi, at få en mere eektiv arbejdsgang samt forøge hastigheden i fremtidige iterationer. Det var ydermere et forsøg på i større grad at følge XP forskrifterne i forhold til hvad vi havde gjort i den første iteration. Grundet, vore samt kundens, begrænsede ressourcer kunne vi ikke leve op til det element i XP der foreskriver kunden skal være tæt på udviklerne. Vi håbede dog på MSN Messenger løsningen ville simulere en tættere kontakt med kunden igennem de næste iterationer Konklusion Gennem første iteration, har vi lært at projektplanlægningen skal fastholdes, idet det er nødvendigt følge op på opgavernes varighed og længde, for derigennem at søge at undgå spildtid og samtidig tracke retningen af udviklingen. Samtidig har vi gjort nogle erfaringer med brugerhistorier, samt opgaven med at udlede arbejdsopgaver fra brugerhistorier. Denne erfaring vil vi naturligvis bruge i anden iteration, samtidig vil vi forsøge at gøre mere ud af at anvende de roller som XP opstiller, samt og synliggøre disse. Disse tiltag skal være med til at forbedre udviklingen i anden iteration. Vores kommunikation i sidste del af første iteration har primært været MSN Messenger, kombineret med s. Mindre spørgsmål kunne stilles pr telefon hvis det ikke var muligt, at komme i kontakt med kunden via MSN Messenger. Vi vil i anden iteration forsætte med at anvende MSN Messenger 30

33 4 Iterationer 4.2 Anden iteration som et supplement til den eksisterende kommunikationen med kunden. 4.2 Anden iteration Efter gennemarbejdning af første iteration, samt dertilhørende feedback fra kunden, påbegyndte vi implementeringen af yderligere funktionalitet i programmet. Anden iteration indebar samtidig nogle udfordringer, idet virksomheden besluttede at omstrukturere deres database, hvilket resulterede i omfattende refaktorering, af alt der kommunikerede med databasen. Dette forsinkede vores udviklingsproces en del, idet dette viste sig at være mere kompliceret end først antaget. Årsagen til dette problem var til dels, at XP foreskriver at man altid skal kode til nu'et, og det derfor ikke er nødvendigt at fremtidssikre sit program, da man i tilfælde af ændringer bør refaktorerer. Derfor var store dele af koden opbygget omkring de antagelser vi i starten af første iteration havde gjort os. Da disse antagelser ikke længere var gyldige, resulterede dette som sagt i omfattende ændringer i koden, lignedende det (Rosenberg and Scott, 2000) kalder et kode Rip op Kravliste De generelle krav til programmet er stadig relevante for denne iteration, dog blev der fra kundes side fremsagt et ønske om en tilbage-funktion på brugeraden, der skulle muliggøre, at det altid var muligt for brugeren at komme tilbage til forsiden af programmet, vha. et museklik Release Efter cirka en uges udvikling på metodelaget, færdiggjorde vi anden iteration. Dette indebar en omfattende refaktorering af al koden der kommunikerer med SQL-databases, hvilket var nødvendigt for at kompensere for de ændringer der skete i opbygningen af det eksisterende system. Idet databasekontakten var etableret og vareoplysninger kunne hentes fra databasen samt behandles i programmet, forventede vi i dette release, respons fra kunden om hvordan disse levede op til dennes krav. Samtidig forventede vi også respons på implementeringen af præference-menuen i programmet, som indebar nye funktionaliteter kunden skulle tage stilling til. Dette var dog ikke muligt, så kommunikationen igennem denne iteration blev støttet op af antagelser om hvad kunden ønskede, baseret på inputs fra gruppemedlemmet der er ansat i virksomheden. Anden iteration resulterede således bl.a. i gur 4.2 på næste side der viser panelet Complete Order, hvilket 31

34 4.2 Anden iteration 4 Iterationer er et af de paneler der k tilføjet funktionalitet i anden iteration. Figur 4.2: Screenshoot fra anden iteration Kommunikation Vi har gennem anden iteration benyttet kommunikation via MSN Messenger, og telefon. De este af samtalerne er foregået over MSN messenger, da det umiddelbart var den nemmeste måde, hvorpå kunden kunne nde nogle tomme huller i sin tidsplan. Denne kommunikationsform er ikke ideel til brugermøder, men omstændighederne taget i betragtning, var det den mest eektive måde, hvorpå vi kunne få og opretholde kontakt med kunden. 32