Department of computer science

Transkript

1 Department of computer science Titel: Wap.studenternet.auc.dk Tema: Design og vurdering af et edb-system i samarbejde med brugere Projektperiode: 3/2 30/ Semester: Informatik 2. Semester Projektgruppe: E1-113 Deltagere: Christian Veigaard Kim Fritze Sillasen Lars Kragh Nielsen Mikkel Lønvig Jensen Frederik Normann Hansen Rasmus Brink Troels Fibæk Bertel Karsten Andersen Vejleder: Lone Leth Thomsen Oplagstal: 10 Sideantal: 114 Bilagsantal og art: 3 bilag 1 appendiks Afleveringsdato: 30/5/2003 Synopsis Dette projektet er underlagt temaet Design og vurdering af et edb-system i samarbejde med brugere, og omhandler udviklingen af et system baseret på WAP protokollen. Dette system har til formål at gøre funktionaliteter på hjemmesiden mobile for studerende på Aalborg Universitet. Vi har valgt at udvikle systemet efter Extreme Programming metoden, og har haft et udbytterigt brugersamarbejde. Resultatet er et WAP-system programmeret i PHP og WML, der i samspil med Studenternets database kan vise informationer gemt i brugernes kalendere samt informationer om de kurser, som brugerne følger. Der er desuden implementeret en busplan som supplement til funktionaliteterne på Studenternet. Konklusionen på dette er, at vi har udviklet et system som brugerne er tilfredse med, og vi har derfor med succes inddraget brugerne i udviklingsforløbet. Endvidere konkluderes det at Extreme Programming har været en god metode at anvende til dette projekt.

2

3 Indholdsfortegnelse Forord...5 Indledning...1 Problemformulering...1 Problemafgrænsning...1 Målgruppen...2 Del I Metode...3 Traditional Software Engineering...3 Extreme Programming...5 Metodediskussion...7 XP som udviklingsmodel...9 Del II Foranalyse...17 Beskrivelse af WAP...17 Studenternet...18 Indledende brugermøder...19 User stories...20 Strukturering af releases...21 Del III Release- forberedelse...23 Design...28 Del IV Release Design...33 Del V Release Design...41 Test af Release 1 & Del VI Release Design...51 Test af Release 2 & Fremtidige releases...57 Del VII Refleksion...61 Projektforløb...61 Metoden...62 Udviklingsfilosofi...65 Samarbejde med Studenternet...67 Brugersamarbejde og test...68

4 Konklusion Bilag A - Tests Test af release 1 & Test af release 2 & Bilag B - Tidsplan...89 Tidsplan Bilag C - Brugermøder Kondensering af første møde med brugere Ordforklaring Litteraturliste Bøger Artikler Internet adresser Appendiks A Kode eksempler Busplan - Nytorv.php Kalender Maaned.php Studenternet Loginwml.php

5 Forord Denne rapport er skrevet af gruppe E1-113 på Informatik studiets 4. semester ved Aalborg Universitet. Projektet er udarbejdet med henblik på at designe, vurdere og realisere et edbsystem i samarbejde med dets kommende brugere samt at vise forståelse for kurserne Systemudviklings Filosofi og Software Engineering. I dette projekt er der blevet samarbejdet med gruppe D321 fra Informatik Basis, 2. semester, og vi vil derfor rette en tak for et inspirerende samarbejde. Derudover sendes der tak til Ulrik Kold, Rolf Njor Jensen og Joakim Recht fra Studenternet for hjælpen med at sætte os ind i Studenternets kildekode. Kim Baasch og Søren Kriegbaun, der begge arbejder for Computopic skal have tak for at stille en SMS-gateway til vores rådighed. Ord i teksten, som kræver yderligere forklaring uddybes i ordforklaringen sidst i rapporten. Referencer til bøger i teksten er opbygget således [forfatters efternavn, udgivelsesåret, sidetal]. Til rapporten er der vedlagt en CD med den udviklede kode. Christian Veigaard Kim Fritze Sillasen Lars Kragh Nielsen Rasmus Schjer Brink Troels Fibæk Bertel Mikkel Lønvig Jensen Karsten Stig Andersen Frederik NormannHansen

6

7 Indledning Studenternet ( startede i august 1998 som en online version af Aalborg Universitets Studieguide. Antallet af besøgende på siden var dog meget lavt i forhold til studerende på universitetet, så strategien blev ændret til at åbne muligheden for adgang til nye funktionaliteter, og man gik helt væk fra Studieguiden. Målgruppen for det reviderede Studenternet var studerende ved fremmedsprog på universitetet, men de var af ukendte årsager ikke interesserede i at bruge siden. For at få flere brugere på siden overtalte man i stedet sekretærerne på basisuddannelsen til at bruge Studenternet til skemaer og anden studierelevant information. Dette gjorde, at Studenternet blev benyttet mere af studerende på basis, og udbredelsen af Studenternet er siden steget støt, og udgør i skrivende stund godt 640 brugere. Dette tal stiger stadig. Studenternet indeholder i dag en bred vifte af funktionaliteter og informationer, som kommer de studerende til gode. Blandt andet vises der udsnit fra nyhedstjenesten Politiken.dk, hvor den studerende kan læse de seneste nyheder. Som en central del indeholder Studenternet en kalenderfunktion, hvor den studerende kan se sin semesterkalender, og der tilbydes en personlig kalender, hvor aftaler og opgaver kan gemmes. Det er endvidere muligt at tilmelde en projektgruppe, der kan oprette gruppeaftaler, og flette disse sammen med de øvrige aftaler gruppen har, i en og samme kalender. Herudover tilbyder Studenternet et fildelingssystem, hvor dokumenter kan gemmes, så andre medlemmer af den samme gruppe kan læse og redigere i disse. Der er til denne funktion udviklet et versionsstyringssystem, så alle tidligere udgaver af dokumenter er tilgængelige. En sidste og meget central del af Studenternet er en indbygget mailklient, hvorfra den studerende kan læse og sende s. Studenternet er på nuværende tidspunkt kun tilgængeligt gennem stationære eller bærbare computere med netadgang. En måde at forandre dette kunne være at gøre siden, eller dele af den, mobilt tilgængelig. Her kommer Wireless Application Protocol (WAP) teknologien ind i billedet. For nogle år siden forventede mange, at det mobile Internet i form af WAP snart ville blive en realitet [Grouleff, 1999]. Siden er forventningerne blevet væsentligt mindre, og mange forventer ikke længere, at udviklingen vil ske med den samme hastighed, som man troede dengang. Problemet var dengang, hvem der skulle skabe dette mobile Internet og hvordan. Der findes talrige eksempler på, hvordan udviklingen af nye markeder har forvandlet sig til rene standardkampe firmaer imellem. Et kendt eksempel er historien om Macintosh, som for 1

8 10 år siden havde en meget stor markedsandel. Denne markedsandel var så stor, at der var en chance for, at Macintosh ville udkonkurrere DOS baserede computere. Som vi alle ved, var det imidlertid PCen, der vandt kampen gennem lanceringen af det meget Apple inspirerede Windows-system. [Skovgaard, 2000] WAP-standarden blev skabt som et sæt grundregler for det mobile Internet, netop for at undgå lignende standardkampe samt for at skabe en fælles standard, der kunne læses af mobile enheder. Der bestod et problem i, at de mobile enheder, som skulle håndtere informationer var meget små. Her menes ikke kun størrelsesmæssigt, men også kapacitetsmæssigt. Processor, hukommelse, båndbredde, strømforsyning, skærm og tastatur er langt mindre end på stationære PCer. Dette er et problem, da hjemmesider på Internettet laves til relativt store skærme og kraftfulde computere. Derfor satte tre af verdens største mobiltelefonproducenter, Motorola, Ericsson, Nokia, og softwarefirmaet Phone.com sig ned for at udvikle en standard til at simplificere informationer på Internettet sådan, at de også kunne læses på mobile platforme. Denne standard kaldte de WAP. Desuden dannede de organisationen WAP Forum, der havde til formål at udvikle og promovere WAP. Hermed var Motorola, Ericsson og Nokia klar til at producere og lancere telefoner med den nye teknologi. De første telefoner, der var i stand til at vise WAP-sider, kom på markedet herhjemme i slutningen af Teknologien var ny og forhåbningerne til den store [Svendsen, 1999]. WAP blev markedsført som Internettet på mobiltelefonen, men svarede nok mere til mobilt tekst TV, som en dengang fremtræden dansk WAP-portal foretrak at kalde det [Bredsdorff, 1999]. Wapportal.dk var en af de første danske WAP-sider og rummede, da siden var størst, links til 4000 europæiske WAP-sider. Heraf var de 500 danske. Allerede et år efter den danske lancering af WAP stod det klart, at teknologien kun havde tiltrukket en meget lille del af det antal brugere, som mange havde håbet. Wapportal.dk valgte som en følge heraf, at fokusere på udviklingen af WAP-sider til andre selskaber [Lauridsen, 2000]. WAP teknologiens flop hos den brede forbrugerskare skabte store ændringer, ikke kun hos wapportal.dk, men også for mange af de virksomheder, der udviklede mobile løsninger. Udviklingsvirksomhederne blev tvunget til at skabe tjenester med reel værdi frem for at leve på den tiltrækning, som en ny teknologi ofte har i sin første levetid. Det har under disse ændringer vist sig, at det ofte er internt i virksomheder og organisationer at WAP teknologiens fordele udnyttes bedst [Nokia, 2003], [Nielsen, 2000] og [Dun, 2000]. Det er derved med til at højne berettigelsen af vores undersøgelse, at Studenternet må betragtes som en service for en organisation. Det vil derfor blive interessant at se, om vi er i 2

9 stand til, sammen med brugerne, at udvikle en WAP-side med brugbar information og dermed reel værdi. 3

10

11 Problemformulering Temaet for dette projekt er Design og vurdering af et edb-system i samarbejde med brugere. Vi har valgt at designe og vurdere et mobilt system baseret på WAP-protokollen. Dette system er tiltænkt at støtte de studerendes daglige arbejde på Aalborg Universitet. Det være sig både i faglige og praktiske henseender. Systemet vil derfor tage udgangspunkt i de muligheder, der findes på web-portalen Studenternet. Denne portal er udformet med det formål at samle alle de oplysninger og værktøjer, som de studerende på Aalborg Universitet har brug for til både faglige og sociale formål. Følgende initierende problem udgør essensen i vores problemformulering: Hvordan kan vi, i samarbejde med udvalgte brugere, udvikle et system, der gør dele af Studenternet mobilt tilgængeligt? Heraf fremspringer følgende problemstillinger: Hvordan kan vi inddrage brugerne i systemudviklingen og sikre et brugbart system? Hvilken systemudviklingsmetode egner sig godt til dette projekt? Problemafgrænsning Som det fremgår af problemformuleringen, er der én overordnet problemstilling, som vi vil koncentrere os om i dette projekt. Det giver anledning til at nævne de aspekter af systemudviklingen, vi ikke vil undersøge nærmere. I et projekt, hvor systemet ikke er bestillingsarbejde og derved bygges på en idé, ville der i mange tilfælde ligge en markedsanalyse til grund for projektet. Dette er dog ikke tilfældet for dette projekt, og det kan diskuteres, om en markedsanalyse er nødvendig for at udvikle et stykke software af den størrelse, som er aktuel i forbindelse med et universitetsprojekt. Mange produktudviklinger i dag bygger på idéer og områder, hvor der er et behov, som udviklerne prøver at dække. Om behovet fastslås vha. markedsanalyser, forespørgsler eller bare er åbenlyst for systemudviklerne, er ikke afgørende. Dette projekt bygger på en idé til et system, som vi mener, kan lette de studerendes dagligdag. Det afgørende for os er læringsprocessen, der sker ved at udvikle et stykke software i samarbejde med brugerne. Et andet aspekt af systemudviklingen, vi ikke vil gå i dybden med, er den økonomiske side. Med dette menes de omkostninger, som de studerende eller universitetet vil få i forbindelse 1

12 med at bruge systemet. Vi vil ikke se nærmere på, hvor denne økonomiske belastning skal ligge, eller hvor stor den vil blive. Det sidste aspekt er vedligeholdelse af systemet. Systemet kommer til at hente informationer fra den samme database som Studenternet, og vil på den måde vedligeholde sig selv med hensyn til opdaterede informationer. Af samme årsag vil koden til vores system være afhængig af den kode, som ligger til grund for Studenternet. Derfor vil det kræve tilpasning af vores kode, hvis Studenternets kode blev ændret. Målgruppen Målgruppen, for det system vi designer, er Studenternets brugergruppe. Som repræsentanter for brugerne har vi valgt en gruppe bestående af syv studerende på Informatik Basis 2. semester. Da Studenternet anvendes som semesterkalender på basisuddannelsen, har brugerne allerede et godt kendskab til websiden og dermed et godt udgangspunkt til at hjælpe os med udviklingen. Vi kan ikke forudsætte, at vores målgruppe har et tidligere kendskab til WAP, da udbredelsen og anvendelsen af WAP i Danmark lader en del tilbage at ønske. Dermed er vores målgruppe, og de repræsentanter for samme vi vil anvende som testpersoner, ingenlunde eksperter i, hvilke krav, der kan stilles til en WAP-service. Af denne grund vil det være risikabelt at opstille en definitiv kravspecifikation tidligt i udviklingsforløbet baseret på brugernes krav. I stedet ønsker vi en indledende, midlertidig kravspecifikation kombineret med et tæt, løbende brugersamarbejde, hvor nye eller ændrede krav kan indfries. 2

13 Del I Metode I dette afsnit vil vi begrunde vores valg af udviklingsmetode. Indledningsvis vil vi introducere forskellige udviklingsmodeller og fremhæve deres styrker og svagheder. Baseret på disse overvejelser vil vi vælge en metode, som passer til vores projekt. I løbet af dette semester har vi modtaget undervisning i forskellige tilgange til systemudvikling. Konkret har dette været gjort ved at holde flere forskellige traditionelle softwareudviklingstilgange op mod den nyere metode Extreme Programming (XP). Dermed har vi haft mulighed for at vælge mellem en del metoder til udviklingen af dette projekt, hver med sine styrker og svagheder. Efter grundigt at have vurderet en række metoder har vi indsnævret udvalget til to tilgange, der på en række områder ligner hinanden, men som samtidig adskiller sig afgørende. Metoderne er Incremental Development og XP. Årsagen til at vi har kunnet indsnævre vores fokus til netop disse to metoder er, at begge metoder anvender et tæt og løbende samarbejde med brugere. Dette er et af de krav, som er sat af vores studieordning. I det efterfølgende kommer en kort gennemgang af de to metoder, hvorefter vores valg vil falde på den ene. Gennemgangen af Incremental Development starter med en kort introduktion af Traditional Software Engineering (TSE) for at forklare baggrunden for metoden. Traditional Software Engineering TSE er den traditionelle måde at udvikle software på. TSE er ikke en metode eller model i sig selv, men beskriver en række udviklingsmodeller til brug under softwareudvikling. Disse 3

14 modeller tæller bl.a. The Waterfall model, The Spiral model, Prototyping og Incremental Development [Sommerville, 2001, s ], som har hver deres styrker og svagheder alt efter hvilken situation og hvilket problemområde, udviklerne har med at gøre. Gode udviklere bør derfor vælge udviklingsmodel med omhu, inden de kaster sig ud i et udviklingsprojekt. Dette vil vi forsøge at gøre i det efterfølgende. Som nævnt ovenfor har vi valgt at koncentrere os om to udviklingsmodeller; Incremental Development og Extreme Programming, som begge er karakteriseret ved stor brugerkontakt. Vi vil nu gennemgå modellen Incremental Development. Incremental Development Incremental Development er en hybrid-model, der tager sine karakteristika fra flere forskellige modeller i TSE. Argumentet for dette er, ifølge Ian Sommerville [Sommerville, 2001, s.51], at det er nødvendigt at bruge forskellige indgangsvinkler til forskellige problemer. For eksempel kunne det være en fordel at bruge The Waterfall model under udviklingen af et delsystem, hvor kravspecifikationen er meget veldefineret og Prototyping på et andet, hvor kravspecifikationen er knap så veldefineret. Sommerville siger ydermere, at det er nødvendigt at have en iterativ model, så man kan ændre designet og implementeringen i takt med, at brugerne ændrer deres krav. Det vil sige, at det er tilladt at springe frit mellem udviklingsfaserne, hvis man får brug for det. Figur 1 : Incremental Development [Sommerville, 2001, s. 52] Incremental Development deler et system op i såkaldte increments, som er afgrænsede funktionaliteter eller delsystemer af det færdige produkt. Funktionaliteterne i et increment designes og implementeres serielt. Som det fremgår af Figur 1 ovenfor, starter modellen med at identificere og fastlægge de overordnede funktioner, som systemet skal kunne udføre. Herefter skal kunden prioritere funktionaliteterne efter, hvilke der er de vigtigste. Så laves prioriteterne til increments og det 4

15 aftales hvornår de enkelte increments skal afleveres til kunden. Det increment, som har højeste prioritet, afleveres først osv. Efter alle increments er på plads, er den første kundekontakt slut. Nu designes den overordnede systemarkitektur. Når den overordnede systemarkitektur er på plads startes der på det første increment, hvor funktionaliteter defineres og designes i detaljer. Derefter udvikles med den rette model som beskrevet ovenfor. Hvert increment testes og integreres i systemet, hvorefter hele systemet testes. Så snart et increment er færdigudviklet og integreret afleveres det til kunden. Dette sikrer, at kunden hurtigt opnår erfaring med systemet og mest erfaring med de tidligst leverede funktionaliteter, hvilke kunden prioriterede som de vigtigste. Det sikrer hurtig og god feedback fra kunden angående ændringer, forbedringer osv. Resultatet burde være, at omfangsrige og talrige ændringer i koden undgås og et mere solidt produkt produceres [Sommerville, 2001, s. 51]. Extreme Programming XP er en relativt ny metode, som bygger på forskellige egenskaber fra andre systemudviklingsmetoder. Forskellen mellem XP og de modeller, fra hvilke den henter inspiration, er ekstremiteten. Hvor der under tidligere metoder blev skrevet en række testcases til udvalgte områder af et systems funktionalitet, bliver der i XP skrevet testcases til alt. Hertil kommer at disse testcases køres, hver gang koden ændres. Tanken bag dette er formuleret af Kent Beck, metodens skaber, If testing is good, everybody will test all the time (unit testing) even the customers (functional testing) [Beck, 2000, preface]. Dette citat reflekterer idéen bag XP, XP takes common sense principles and practices to extreme levels [Beck, 2000, preface]. On-site customer er et af hovedbegreberne i XP. Denne er en repræsentant for brugerne, der er til stede under udviklingsforløbet. Hans formål er at teste systemet løbende og give hurtig og relevant feedback. Ved at være en del af udviklingsforløbet får han hurtigt stor indsigt i systemet, og giver dermed også bedre feedback. Release er et andet af XPs hovedbegreber. Disse tilsvarer Incremental Delevelopments increments, dog med nogle få forskelle. Graden af planlægning er mindre end for increments. 5

16 Man starter således hurtigere i udviklingen af releaset med at implementere funktionaliteterne, som i XP defineres ud fra customer stories. Customer stories er funktionaliteter sat i relation til virkeligheden; hvordan kunne det tænkes at funktionaliteten blev brugt, i hvilken situation osv. TSE kalder dette for brugsmønstre. Således er XP i høj grad en praktisk orienteret metode. The Planning Game er XPs værktøj til planlægning af udviklingsforløbet. Dette gøres ved at udviklerne, i samspil med kunden, fastlægger indholdet af det system, der skal udvikles. Det er kundens opgave at skrive et antal af de førnævnte customer stories. Disse gives til udviklerne, som derefter estimerer, hvor lang tid de enkelte stories vil tage at implementere. Disse estimeringer formidles tilbage til kunden, som skal udvælge de customer stories, der skal implementeres i et release og fastsætte en deadline for releaset. Den planlægningsmæssige horisont er også forholdsvis kort i XP; i stedet for at søge at planlægge det fremtidige udviklingsforløb i detaljer vælges det under XP at have en midlertidig kravspecifikation og designe og implementere det, der er nødvendigt i nuet. Den pågældende on-site customer tester således systemet efterhånden som det udvikles, og tilbagemelder fejl eller nye krav til systemet. Herved udvikles kravspecifikationen og systemet forfines løbende. Som det fremgår af Figur 2 startes udviklingen med at definere customer stories. Dette gøres i samarbejde med on-site customeren. Herefter prioriteres de pågældende customer stories og rækkefølgen, hvorpå de skal implementeres, fastlægges. Et passende antal customer stories tildeles hvert release og der sættes deadlines for, hvornår releasene skal ligge færdige. Der startes nu på det første release med at konstruere tasks ud fra de pågældende customer stories. Herefter konstrueres en passende designmetafor og en overordnet arkitektur. Med designmetafor menes en metafor, der kan lette forståelsen af det lidt abstrakte programmel, både programmører imellem og mellem programmørerne og on-site customeren. Et glimrende og nok det mest kendte eksempel herpå, er metaforen for Microsoft Windows grænseflade, som de kalder skrivebordet. Hver gang der implementeres selv en lille del testes hele systemet enten af on-site customer eller af udviklerne. 6

17 Figur 2: Modellen viser faserne i et XP-projekt. Metodediskussion Nu har vi gennemgået de to udviklingsmodeller, som vi vurderer er interessante for vores projekt. Den valgte udviklingsmetode bliver essentiel for vores projektforløb og som tidligere nævnt, bør gode udviklere vælge en udviklingsmetode med omhu. Derfor vil vi nu diskutere de to metoder og en udvalgt række af deres respektive styrker og svagheder med det formål at vælge en udviklingsmetode for projektet. Begge udviklingsmetoder har elementer, som virker interessante set i lyset af vores projekt: De primære fælles forcer for Incremental Development og XP ligger i brugerkontakten og opdelingen af udviklingen i etaper. Den løbende implementering og test sikrer, at kunden er med i udviklingen, og at der bliver skredet ind overfor kritiske fejl på et tidligt tidspunkt i forløbet. Dette sikrer mere stabil og brugervenlig software, samt at fejl er relativt billige at rette. Endvidere spildes der ikke unødvendigt lang tid på grundig indledende analyse af problemområder, hvor brugerne ikke kan forventes at vide, hvilke krav de har, fordi der anvendes en mindre udbredt teknologi. 7

18 Til trods for at de to modeller bl.a. har brugerkontakten til fælles, adskiller de sig dog betragteligt i anvendelighed ved relativt små projekter. Som Sommerville [Sommerville, 2001, s. 51] skriver, blev Incremental Development oprindeligt konstrueret som en udviklingsmodel til store projekter. Her menes projekter, som omhandler omfangsrige programmer, der ikke umiddelbart kan overskues af hverken kunden eller udviklerne. Incremental Development opdeler derfor systemudviklingen i mindre stykker, hvorefter disse brudstykker udvikles én efter én, hvilket giver både kunden og udviklerne et meget bedre overblik over programmet. Hvert brudstykke skal udvikles ved brug af den TSE-model, som egner sig bedst til det aktuelle problem alt efter, hvor god kravspecifikationen er for det givne increment. Dette er en relativt omstændelig proces, hvilket betyder at projekterne, der anvender denne tilgang, skal have en vis størrelse for at metoden kan forsvares ressourcemæssigt. I modsætning hertil egner XP sig bedst til mindre udviklingsprojekter, der kan varetages af 2-10 udviklere. Udviklingsmetoden foreskriver, at alle udviklerne sidder i samme lokale, og at koden bliver parprogrammeret. Parprogrammering indebærer at al kode skrives af teams på to udviklere. På den måde sikrer man kommunikationen i projektgruppen, og sikrer konsistens og kvalitet af koden. Miljøet er således meget vigtigt for udviklingsprojektets succes. Godt miljø medfører tilfredse medarbejdere og et bedre produkt. Det er svært at forestille sig, hvordan XPs principper kan håndhæves i større udviklingsforløb, med f.eks. 30 programmører, der alle skal sidde i samme lokale. Vi vurderer yderligere, at der vil være følgende positive egenskab ved at vælge XP: Vi ønsker under dette projekt at anvende parprogrammering. XP forudsætter parprogrammering som en bærende aktivitet for et udviklingsprojekt, og beskriver hvorledes denne aktivitet bedst faciliteres. I Incremental Development anvendes parprogrammering som udgangspunkt ikke. Af Sommerville fremgår det direkte: Providing individual offices for software engineering staff can make a significant difference to productivity [Sommerville, 2001]. Hvis vi skulle anvende parprogrammering i samspil med Incremental Development, ville vi dermed skulle modificere metoden og gå imod et af TSEs, og dermed også Incremental Developments principper. Med hovedargument i projektets størrelse og de ressourcer vi har til rådighed, har vi valgt XP som udviklingsmodel, og vil derfor gennemgå modellen i større detalje. 8

19 XP som udviklingsmodel XP sigter som metode mod at imødegå et grundlæggende problem i forbindelse med systemudvikling: omgivelsernes omskiftelighed. I løbet af en længerevarende systemudvikling vil mange af de krav, som brugere stiller til systemet, ændre sig. Krav, der tidligere virkede fornuftige og vigtige, kan vise sig irrelevante og falde bort, mens nye opstår. Historisk har systemudvikling fulgt et mønster, hvor udviklerne først grundigt analyserer den kontekst systemet skal indgå i for herefter i samspil med brugerne at opstille en kravspecifikation til systemet. Siden designes, implementeres og testes på basis af analysen. Det formodentlig mest yderliggående eksempel på en af disse TSE-tilgange til systemudvikling er The Waterfall model, som er nævnt tidligere. Problemet med modeller som The Waterfall model består i, at der, grundet de foranderlige krav, er forbundet stor økonomisk risiko med denne tilgang. Kunden risikerer således, at systemet er udviklet til at imødekomme en række krav, der helt eller delvist er forsvundet. Følgelig vil systemet være helt eller delvist ubrugeligt. Derfor er der ifølge Kent Beck brug for en langt mere fleksibel tilgang til systemudvikling, end man hidtil har anvendt [Beck, 2000, s. 27]. Beck laver en analogi mellem systemudvikling og det at køre bil; Det er ikke nok at lægge en fast rute og så bare køre lige ud med den forudsætning, at vejen fortsætter med at være jævn og lige (TSE). Hvis denne tilgang følges vil bilen forulykke i det øjeblik vejen ikke længere er jævn og lige. I stedet skal chaufføren konstant være opmærksom på vejens beskaffenhed og justere sin kørsel derefter. Herved minimeres risikoen for ulykker og det er denne tilgang, der afspejler tanken bag XP. Roller i et XP projekt Der er principielt intet lederskab i udviklingsgruppen i et XP projekt. Dog findes der i gruppen af udviklere forskellige kompetencer, hvilket udnyttes til at sikre at projektet har en styring. Der er således tre administrative roller, der fordeles blandt udviklerne. Disse roller fordeles efter menneskelige såvel som faglige kompetencer. Tracker: En rolle for den person, der helt konkret med tal vurderer i hvilken grad planlægningen overholdes og om de stillede mål opnås. Et eksempel kunne være at holde styr på hvor stor en procentdel af de opstillede deadlines, der bliver overholdt. Manager: En rolle for den person, der fordeler ressourcer. Coach: En rolle for den person, som skal sikre projektets gunstige udvikling. 9

20 Coach rollen er det tætteste, vi kommer på den traditionelle projektlederrolle. Imidlertid skal en coach modsat den traditionelle projektleder i videst muligt omfang ikke træffe beslutninger; i stedet skal han fungere som en katalysator, som får udviklerne til at træffe de rigtige beslutninger. Formelt ligger magten dog hos coachen, og denne har vetoret. Endvidere skal en coach sikre, at de fysiske omgivelser såvel som det psykiske arbejdsklima er i orden; at disse er af en sådan beskaffenhed, at udviklerne kan trives med arbejdet. Fire værdier i XP Bærende for XP står fire værdier: Communication, Simplicity, Feedback og Courage [Beck, 2000, s. 29]. Communication Velfungerende kommunikation internt i gruppen såvel som eksternt med kunden er en vigtig faktor for systemudvikling. God kommunikation søges sikret gennem en række arbejdsvaner, der kun er mulige i kraft af god kommunikation. Hermed menes at der i et XP projekt samarbejdes på en måde, der tvinger folk til at kommunikere med hinanden. Eksempler på måder at fremme kommunikationen er parprogrammering, automatiserede tests og opgaveestimering. [Beck, 2000, s. 30] Endvidere er det coachens opgave at bemærke, når forskellige personer ikke kommunikerer ordentligt med hinanden og sørge for at den velfungerende kommunikation genoprettes. Simplicity I et XP projekt designes systemer på den enklest mulige måde. Endvidere skal udviklerne udforme deres kode på en sådan måde, at den udelukkende lever op til de krav, der er kendte på det givne tidspunkt under udviklingen. Der bruges således ikke kræfter på at gøre systemet modtageligt overfor udvidelser, som måske vil blive ønskelige i fremtiden. Hvis et krav senere skulle opstå, behandles problemet på dette tidspunkt. [Beck, 2000, s. 30] Feedback Centralt i XP metoden står idéen om feedback. Feedback er vigtigt, fordi det fortæller udviklerne, om de er på rette kurs. Der skrives automatiserede tests, som giver hurtig feedback på om ændringer i koden har haft negative konsekvenser for programsegmentet som helhed. Endvidere forekommer hyppige releases, hvilket betyder, at kunden hurtigt får praktisk erfaring med systemet, og kan melde eventuelle nye krav tilbage til udviklerne. De omtalte releases bliver desuden frigivet i en rækkefølge prioriteret efter vigtighed, hvilket betyder, at kunden har mest tid til at lære de vigtige funktioner at kende og teste disse gennem brug. Alt dette sikrer hurtig og relevant feedback. [Beck, 2000, s. 31] 10

21 Courage Med udgangspunkt i de tre foregående værdier skal udviklerne arbejde så optimalt som muligt. I en ekstremt kompetitiv branche er det nødvendigt at arbejdsindsatsen optimeres. Samtidig skal udviklerne dog være modige nok til at træffe valg, der på kort sigt går mod denne optimering: Hvis det giver et bedre system at kaste allerede udført arbejde bort, skal udviklerne udvise mod ved at gøre dette. På kort sigt kan det virke som spildt arbejde, men på lang sigt vil det give bedre kode og bedre systemer med mindre vedligeholdelse. [Beck, 2000, s. 33] Principper i XP For at operationalisere disse fire overordnede værdier opstiller Kent Beck [Beck, 2000, kap 8] en række grundlæggende principper, som hjælper med at sikre kvaliteten af udviklingsarbejdet. Centrale principper Rapid feedback; hurtig feedback sikrer en hurtigere læringsproces for udviklerne Assume simplicity; implementer alt på den simpleste måde, hvorved programmet kan virke. Incremental change; alle ændringer foretages i overskuelige etaper. Embrace change; løs problemer på en sådan måde, at flest mulige muligheder holdes åbne. Quality work; hvis der ikke leveres kvalitetsarbejde bliver projektet ikke en succes. Mindre centrale principper Her har vi udvalgt de vigtigste. Teach learning; fokuser på egne erfaringer mht. hvor meget der skal testes etc. Small initial investment; et stramt budget tvinger udviklere til at optimere arbejdsindsatsen. Concrete experiments; når der designes skal der anvendes mockups i stedet for færdigt design til at teste designforslag. Accept responsibility; alle vælger selv, hvilke arbejdsopgaver de vil beskæftige sig med. Ingen beordres. Local adaptation; metoden skal tilpasses lokale forhold. Honest measurements; bedre at estimere en opgaves tidsforbrug i realistiske ca. tider end urealistisk præcise tider. Systemudvikling som fire aktiviteter XP ses som bestående af fire centrale aktiviteter, Coding, Testing, Listening og Design; 11