DEN NATURSKÅNSOMME FISK. Datamatikeruddanelsen på Erhvervsakademiet. 5. semester opgave (hovedopgaven) Foreningen af Naturskånsomme Fiskere

Transkript

1 FORSIDE DEN NATURSKÅNSOMME Uddannelsessted Niveau Titel Forfattere Vejleder Opgavestiller Periode Omfang Synopsis Datamatikeruddanelsen på Erhvervsakademiet semester opgave (hovedopgaven) Den naturskånsomme fisk Rasmus Stenholm Henriksen Jens Bo Rasmussen Arne Møller Jensen Foreningen af Naturskånsomme Fiskere 12. august - 4. november 2002 Rapport: 74 sider Bilag: 9 sider Denne rapport beskriver udviklingen af et web-baseret e-handelsystem til afsætning af naturskånsomt fangede fisk. Det udvikles for foreningen Naturskånsomme Fiskere. Udviklingsmetoden er extreme Programming og projektet indeholder såvel en teoretisk beskrivelse som en praktisk anvendelse af denne. Systemet er programmeret udelukkende i Java og den anvendte teknologi er Enterprise Java Beans og en objektorienteret database fra Matisse. Afleveringsdato: Underskrevet: Side 1

2 INDHOLDSFORTEGNELSE DEN NATURSKÅNSOMME Indholdsfortegnelse Projektetablering Opgavebeskrivelse Titel Organisation Kontaktperson Projektgruppenavn Deltagere Målgruppe Baggrund og formål Rapportens form Forventet resultat Projektgrundlag Konfigurationsstyring Ressourcer Organisering Konflikthåndtering Projektbeskrivelse Virksomheden Kunderne Ydelserne og produkterne Markedsføring og salg Systemdefinition Projektplan Vilkår Strategi Risikoanalyse Interessentanalyse Metodebeskrivelse extreme Programming (XP) Introduktion Planlægning Fundamentet Releaseplanlægning Iterationsplanlægning Accepttest Design Unittest Parprogrammering Side 2

3 INDHOLDSFORTEGNELSE DEN NATURSKÅNSOMME Standardiseret kodning Refaktorering Fælles ejerskab Løbende systemintegration Dokumentation Strukturen Releaseplanlægning Realiseringsmodel Unittest Kodning Kravmodel Accepttest Systemarkitektur og udviklingsmiljø Proces Idé Database og model Applikationsserver og n-tier arkitektur JSP og servlets Tomcat EJB Produkt Arkitektur Databaseserver Applikationsserver Webserver Klient Matisse - OODB Typer og constraints Sikkerhed Oprydning og versionering Indexering Backup og recovery Projektet Den første release Releaseplanlægning Releaseperioden Undersøgelsesfasen Forpligtelsesfasen Resultat Non-funktionelle krav Evaluering af releaseplanlægningen Side 3

4 INDHOLDSFORTEGNELSE DEN NATURSKÅNSOMME Den første iteration Iterationsplanlægning Acceptest Unittest Evaluering af metoden Den anden iteration Styringsfasen Iterationsplanlægning Accepttest Kravmodellen Realiseringsmodellen Unittest Cookie kontra HttpSession Accepttestforløb Sikkerhed Baggrund Termer EJB og J2EE Konklusion Den anden release Releaseplanlægning Release- og iterationsperiode Forpligtelsesfasen Den tredie iteration Iterationsplanlægning Accepttest Kravmodellen Realiseringsmodellen Accepttestforløb Afslutning Opfølgning Refaktorering Brugervenlighed Navigations-diagram Kravspecifikation i XP Baggrund Løbende kravudformning Udfordringen Side 4

5 INDHOLDSFORTEGNELSE DEN NATURSKÅNSOMME Konklusion Installationsvejledning Installér IDE Installér OODB Konfigurer OODB Konfigurer OODB med ny database Startapplikationssserver Afprøv fra en browser Litteraturliste Bilag Bilag Bilag Bilag Bilag Bilag Bilag i plastlommen bagerst Bilag i plastlommen bagerst Side 5

6 PROJEKTETABLERING DEN NATURSKÅNSOMME Projektetablering Side 6

7 PROJEKTETABLERING DEN NATURSKÅNSOMME Opgavebeskrivelse Titel Organisation Kontaktperson "Den naturskånsomme fisk" "Foreningen af Naturskånsomme fiskere" Knud Andersen Hemmedvej Glesborg Tlf Der vil være behov for daglig kontakt: primært via og telefon, men også møder. Dette er essentielt for extreme Programming (herefter: XP) som metodevalg. Projektgruppenavn Deltagere Målgruppe Bomus Jens Bo Rasmussen Rasmus Stenholm Henriksen Rapporten henvender sig primært til lærere og elever ved datamatikerstudiet. Baggrund og formål På Datamatikeruddannelsens 4. semester holdt vi et kort foredrag om udviklingsmetoden XP med det formål at skabe overblik over metoden. Vi fik kun lejlighed til at skrabe overfladen. Derfor vælger vi at fordybe os i XP i hovedopgaven på datamatikeruddannelsens semester. Det er vores intention at afprøve XP på et konkret udviklingsprojekt. Inden vi kan give os i kast med det konkrete projekt, er det nødvendigt at se nærmere på teorien og de idéer, som er grundlaget for XP. Hovedopgaven vil derfor bestå både af en teoretisk del og en praktisk del. Den teoretiske del er en detaljeret gennemgang af de elementer i udviklingsmetoden, som vi vurderer vi med fordel kan drage nytte af i det konkrete udviklingsprojekt, og ikke en tilbundsgående undersøgelse af samtlige elementer i XP. Vi er interesseret i at afprøve teorien i praksis, men har ingen ambitioner om at afprøve samtlige elementer i XP. Dertil har vi for kort tid. Tværtimod skærer vi helt ind til benet og beskæftiger os kun indgående med de elementer, som er relevante i forhold til det konkrete projekt. Hovedopgaven er et eksempel på XP i praksis og ikke et teoretisk værk. Det er udelukkende vores subjektive vurdering i forhold til det konkrete projekt, der er bestemmende for hvilke elementer af XP vi vil beskæftige os med. Den praktiske del er dokumentationen af processen og produktet. Gentagende evalueringer i Side 7

8 PROJEKTETABLERING DEN NATURSKÅNSOMME forløbet sikrer at vore erfaringer med XP dokumenteres. Rapportens form Forventet resultat Rapporten indeholder som sagt en teoretisk og en praktisk del. Inden vi giver os i kast med den praktiske del har vi én ting i tankerne; hvordan kan vi selv tænke os at få rapporten serveret? Og efter en kort diskussion er vi begge enige om formen; en form der måske ved første øjekast virker utraditionel, men er mere interessant for læseren fordi vedkommende lever sig ind i forløbet. Dokumentationen skal ses som en sammenhængende beskrivelse af et XP-forløb. Vi er ærlige overfor metoden. Dette gælder både proces og produkt. Vi dokumenterer begivenhederne i den rækkefølge de opstår. Det betyder at rapporten kun delvist kan bruges som vedligeholdelsesdokument men, mener vi, er ideelt som læringsredskab. Både hvis man vil se hvordan metoden virker, hvilke faldgruber der er, hvordan teknologien er brugt og hvordan man også kan dokumentere et projekt. Der ønskes et system der kan sikre succesfuld afsætning af friske naturskånsomme fisk til miljøbevidste forbrugere uden fordyrende mellemled. I forhold til produktet forventer vi at nå de dele af systemet der berører kunderegistrering og provisionsberegning. Det er netop disse dele Knud vægter højest. Hvad angår processen forventer vi en succesoplevelse med XP som metode; en oplevelse af at tilfredsstille brugerens behov, at bevare overblikket gennem hele forløbet, at opnå indgående kendskab til XP gennem egne erfaringer og ikke mindst ha' det skægt. Side 8

9 PROJEKTETABLERING DEN NATURSKÅNSOMME Projektgrundlag Konfigurationsstyring Ressourcer Organisering Microsoft Word benyttes til tekstbehandling og programmets default-typografier anvendes: overskrift 1, 2, 3 og normal. Ved indskrivning gælder det om at formulere sig så præcist og kortfattet som muligt. Tegnsætning skal være korrekt, og stavefejl er generelt uacceptable. Filerne må kun forekomme i én version og kun ét sted, og opbevares derfor i passende directories centralt på en ftp-server. Vi er nødt til at skrive vores tekster i bidder, og derefter sætte dem ind i det relevante dokument efter vi har varskoet den anden part. Dette skyldes at Word ikke understøtter exclusive locks når netværket ikke er Microsoft's. Backup udføres automatisk med sikkerhedskopi-funktionen i Windows XP hver nat kl Udviklerne er begge familiefædre med nogenlunde de samme behov og begrænsninger. Mødetiden er derfor dagligt fra 09:30 til 14:30 i Nørregade Der må dog forventes hjemmearbejde og øget arbejdspres i hele perioden. Beslutninger træffes i fællesskab. Som udgangspunkt udarbejder og programmerer vi hovedopgaven sammen i Nørregade 5, men det er ikke udelukket at opgaverne uddelegeres hvor det forekommer naturligt - f.eks. ved specialiserede opgaver som kræver research. Samarbejdet bygger på gensidig tillid og respekt. Kendetegnende for samarbejdet er venskab, trivsel, åbenhed, ærlighed, omsorg og humor. Der er højt til loftet med plads til "dumme spørgsmål" og kritik. Kritik skal være saglig, konstruktiv og oprigtig. Både positiv og negativ kritik er velkommen og modtages positivt med oprejst pande. Negativ kritik må aldrig opfattes som et angreb på ens person eller evner. Der er etableret kontakt til to andre projektgrupper med hvem der løbende kan gennemføres reviews; gruppe nr. 20 og nr. 42. Konflikthåndtering Uenighed løses i fællesskab. I tilfælde af utilfredshed og mistrivsel skal der meldes klart ud med det samme, så dage med dårlig stemning undgås. Der gælder følgende lille talemåde: "lad ikke solen gå ned over din vrede". Inden dagen er omme SKAL der findes en løsning som begge parter kan acceptere. Indrømmelser/undskyldninger skal imødekommes og tilgives uden at bære nag. Hvis en af parterne opfatter en negativ kritik som et angreb på ens person, skal der meldes ud pronto. Det samme gør sig gældende hvis man føler, at ens grænser overskrides. Side 9

10 PROJEKTETABLERING DEN NATURSKÅNSOMME Projektbeskrivelse Virksomheden Kunderne Ydelserne og produkterne Markedsføring og salg Systemdefinition Virksomheden er en salgsorganisation for naturskånsomt fangede fisk i overensstemmelse med reglerne og det tilknyttede mærke. Den står for koordineringen mellem producenter, forarbejdningsvirksomheder, transportører samt forhandlere og forbrugere. Kunderne er almindelige forbrugere; enlige, familier eller storfamilier. Herudover storkøkkener (kantiner, restauranter, plejehjem, detailfiskehandlere m.fl.). Produkterne består primært af fersk uforarbejdet, klargjort (f.eks. flået) eller fileteret fisk af fiskearter fanget af fiskefartøjer, som er godkendte af foreningen "Naturskånsomme Fiskere". Der vil også blive tale om røgede produkter, marinerede eller krydrede sild, m.v. Markedsføring foregår primært ved, at kunderne tilbydes en vis provision for at anbefale (skaffe) nye kunder. Der foregår derudover ingen markedsføring bortset fra adgang til information via en hjemmeside, samt salgsmateriale, som kunden/sælgeren kan bringe med sig. Der foregår derudover en generisk informationsvirksomhed, som principielt er anbefalelsesmarkedsføringssystemet uvedkommet. Salgsorganisationen tager såvel ansvaret for afregning og distribution. Systemet vi skal udvikle kan beskrives mere specifikt som følger: - der ønskes et system der kan sikre succesfuld afsætning af friske økologiske fisk til miljøbevidste forbrugere uden fordyrende mellemled. Dette skal realiseres via internettet, så interesserede kunder kan købe direkte fra producent/grossist. Det er tanken at disse kunder også skal fungere som sælgere i systemet. Såkaldt Multi Level Marketing - hvor købere også er sælgere, og får provision af antal købte varer af kunder under dem. Det skal være muligt at justere provisionsgraden - for at sikre en retfærdig håndtering af de penge der er afsat til marketing. Kunderne skal, efter de har registreret sig, til hver en tid kunne få deres saldo, samt hvilke kunder de har og deres status oplyst. Det skal være muligt at administrere kunderne fra en administrativ del. Man ønsker at arbejde med WindowsNT som platform. Fiskene skal ydermere sælges til fiskehandlere fra en internetauktion efter de er meldt fanget online fra kutterne, og returemballagen skal administreres. Disse to systemer er ikke en del af dette system, men de skal alle tre kunne kobles sammen til ét system på et ikke givet tidspunkt. Side 10

11 PROJEKTETABLERING DEN NATURSKÅNSOMME Projektplan Vilkår Strategi Risikoanalyse Vi arbejder på serversiden med en windows-platform. Denne er velgennemprøvet, og burde ikke give os de store problemer. I udviklergruppen har vi tidligere arbejdet med web-arkitektur og vi glæder os til at arbejde med en ny metode. Men vores manglende kendskab til JSP, HTML, JavaServlets, objektorienteret database generelt og Matisse specifikt, EJB og applikationsservere gør at vi må sikre delresultater hurtigt og lave små researchseminarer. Det vil være en fordel at have hurtig adgang til konsulentbistand, men vi må nok se i øjnene at dette ikke er praktisk muligt. Det er et forholdsvist lille system vi skal lave, men der foreligger et ønske om høj kvalitet. Derfor må vi sikre korte iterationer med højt testniveau, så vi hele tiden kan styre efter højest mulig kvalitet i produktet. Brugergruppen er entusiastisk, til gengæld er der kun én. Det kan derfor blive nødvendigt at finde nogle tilfældige brugere. Vi vil forsøge at samarbejde med andre grupper for at sikre fremgang i starten og høj kvalitet i det lange løb. Projektet skal have et inkrementelt forløb med korte iterationer, og højt testniveau. Dels for at justere ambitionsniveauet løbende, men også for at sikre entusiasme hos bruger og udviklere. Det skal ydermere være muligt at afsætte tid til research. Der er risiko for at vores system bygger på en ulovlig marketingstrategi (Multi Level Marketing). Derfor må vi sørge for at holde projektet åbent, og spille med åbne kort under udviklingen. Viser det sig at vi er på kant med loven ignorerer vi det; vi har ikke tid til andet. Sandsynligheden for at Knud Andersen afbryder samarbejdet er meget lille - men dog katastrofal. Grundet tidsmangel, ser vi os nødsaget til at ignorere dette. Tab af data forebygges ved at tage daglig back-up. Der er risiko for at vores forventede resultats omfang er fejlestimeret i forhold til de 5 mandemåneder vi har til rådighed. Det er meget svært at estimere udfra en systemdefinition. Forholdsregel nummer et: korte iterationer så vi kan realisere de vigtigste systemdele først. Multi Level Marketing Som det fremgår af ovenstående risikoanalyse er vi i tvivl om lovligheden af vores systems tilblivelse. Så dette ønsker vi kort belyst. I forbrugerombudsmandens "tjekliste til brug for vurdering af lovligheden af pyramidisk opbyggede arrangementer" fra juli 1999 lyder det om MLM: "Nogle arrangementer involverer omsætning af produkter med reel værdi. Der oppebæres en reel indtjening på baggrund af produktomsætningen. Forhandlernettet er ofte opbygget således, at de enkelte forhandlerled, udover indtjening ved eget salg, opnår provision af de nedre forhandlerleds omsætning." Side 11

12 PROJEKTETABLERING DEN NATURSKÅNSOMME Denne form ses der med milde øjne på, hvis forhandleren ellers overholder forbrugeraftaleloven 1. Her tænkes der primært på 10 der omhandler en uges fortrydelsesret for køberen. Denne blanket skal fremsendes sammen med varen og underskrives for at være gældende. Ellers er aftalen ikke bindende for køberen. Konklusion Der er ikke på nuværende tidspunkt noget i vejen for at gå videre med udviklingen af systemet. Vi skal blot holde os for øje at der er visse spilleregler der skal overholdes, og at lovgivningen kan ændre sig senere. Interessentanalyse Knud Andersen er meget ivrig for at få udviklet et brugbart system og forventer et kørende system ved projektets afslutning. Det kan resultere i at Knud bakker ud af projektet hvis ikke hans forventninger opfyldes. Derfor skal vi sikre et gennemskueligt projektforløb og skabe tillid ved at sikre hurtige delresultater. 1 Side 12

13 METODEBESKRIVELSE DEN NATURSKÅNSOMME Metodebeskrivelse Side 13

14 METODEBESKRIVELSE DEN NATURSKÅNSOMME extreme Programming (XP) Introduktion XP er en metode der trækker sund fornuft ud i ekstremerne. Flere af teknikkerne i XP er ikke nyopfindelser. Men det der er specielt er at de er samlet under samme tag, de understøtter hinanden og praksiserne sikrer at de bliver udført så omhyggeligt som muligt. Der findes idag en del agile metoder, men XP var den første af sin art. XP bygger på fællesskab, som understøttes af nogle simple praksiser. De fire grundværdier er: simpelt design, kommunikation, feed-back og mod. Fællesskabet er koncentreret omkring en central person: kunden eller brugeren om man vil. Der ventes meget af denne person og det er bydende nødvendigt at vedkommende er godt inde i problemområdet. Knud, vores rekvirent er en ildhu person der i mange år har beskæftiget sig med miljø og fiskeri. Han skal besvare spørgsmål når der er nogen, deltage i udvikling af kravspecifikation, udforme accepttests, godkende testresultater og generelt deltage aktivt på stedet. Dette stiller også store krav til udviklernes evne til at formidle deres resultater og tanker. Planlægning Fundamentet Uanset hvilken metode man vælger som grundlag for udviklingsprojektet handler det om hvordan man udfører de grundlæggende aktiviteter; kravspecificering, planlægning, test, programmering, design og implementering. Systemudvikling er forbundet med risici, som de metoder vi tidligere har arbejdet med giver mulighed for at styre mere eller mindre indirekte. Typiske eksempler er overskredne deadlines med yderligere risiko for lukning af projektet, systemet løser ikke opgaven pga. misforståelser og dårlig kommunikation, virksomheden bruger ikke systemet pga. ændrede behov, systemet indeholder unødvendig funktionalitet eller er fyldt med fejl, systemet er vanskeligt at vedligeholde, udviklerne hader systemet og finder andet arbejde. XP er en metode som direkte retter sig mod ovennævnte risici, ikke mindst i planlægningen. Dette er en af de vigtigste årsager til vores valg af denne metode, fordi vi i tidligere projekter har oplevet det og fordi dette projekt's vilkår lægger op til det. Planlægningen af et XP-projekt bygger på fire faktorer som man skal have styr på: omkostninger, tid, kvalitet og omfang. Mange kunder mener fejlagtigt at de kan bestemme værdien af alle fire faktorer, men i XP får udviklerne altid lov at bestemme én af faktorerne. Omkostninger er oftest den mest bundne faktor, da man ikke kan betale sig til hyppige afleveringer, kvalitet og omfang. Tidsfaktoren er ofte bestemt af kunden, som ønsker systemet klart til en bestemt begivenhed. Mere tid kan øge både kvalitet og omfang, men for meget tid mod- Side 14

15 METODEBESKRIVELSE DEN NATURSKÅNSOMME arbejder ønsket om hurtig feedback fra kunden. Vi har i vores projekt et ønske om hurtig feedback, fordi det stimulerer motivation og fremdrift. Kvaliteten er en vanskelig faktor at have med at gøre og kan anskues på to måder: ekstern kvalitet er den kunden oplever og intern kvalitet er den udviklerne oplever. Det kan være fristende at lave noget rod for at blive hurtigere færdig, vel at mærke uden at det på kort sigt går ud over den eksterne kvalitet. Sikkert er det dog at dårlig intern kvalitet på lang sigt vil fordyre eksempelvis videreudvikling og vedligeholdelse. Desuden er det demoraliserende for udviklerne at sidde og lave noget skrammel. Vi har et ønske om at opnå såvel høj intern som ekstern kvalitet. Det tager tid, derfor må vi se i øjnene at omfanget af vores resultat bliver ringe. Omfanget er den faktor som er lettest at skrue op og ned for. I mange tilfælde kan kunden ikke fortælle præcist hvad de gerne vil have, men finder først ud af det når de ser den første version af systemet. Når kravspecifikationen på den måde ændrer sig undervejs bliver det muligt at forme omfanget. I XP fastsættes tid (deadline), kvalitet og omkostning og efterhånden som projektet skrider frem, vil vi se hvilket omfang der er muligt inden for rammerne af de første tre faktorer. I starten af projektet er det vanskeligt at estimere og udviklerne må måske udelade vigtig funktionalitet. Vi har også problemer med at overskue omfanget af vores systemdefinition. Derfor programmeres kundens højeste ønsker først, så hvis funktionalitet udelades er den funktionalitet som er vigtigere under alle omstændigheder lavet. Af samme årsag er det forventede resultat udarbejdet i samarbejde med Knud. Estimeringerne bliver selvfølgelig bedre og bedre efterhånden som vi får høstet erfaring. Hvordan foregår dette i praksis? Releaseplanlægning Et XP-projekt opdeles i releases hvor en release er en fuld funktionsdygtig frigivet version af det færdige system. Kunden fastlægger længden af perioden mellem de enkelte releases (herefter: releaseperioden) som forbliver konstant gennem hele forløbet. Releaseperioden er typisk på maksimum 2-3 måneder, men afhænger af omfanget af anvendelsen, distributionen og dokumentationen. Omfanget af anvendelsen klarlægges hen ad vejen, distributionen er ikke videre krævende da det er et webbaseret system mens dokumentationen i vores projekt er omfattende fordi der også skal afleveres en rapport der dokumenterer proces såvel som produkt. Resultatet af ovenstående releaseplanlægning er en releaseplan som er en prioriteret liste af krav (historier) som kodes indenfor estimeret tid. I et XP-projekt kaldes planlægningsarbejdet for "The Planning Game" og betragtes som et spil med kunden og udviklerne som deltagere. Målet er at maksimere værdien af den software som skal programmeres. Strategien går ud på at udvikle den mest vigtige del af funktionaliteten for kunden så hurtigt som muligt, så der hurtigt udvikles et kørende system som har værdi for kunden. Når først systemet Side 15

16 METODEBESKRIVELSE DEN NATURSKÅNSOMME er kørende er det som nævnt lettere for kunden at identificere kravene. A5 papkort er brikkerne i spillet. Spillet har tre faser: undersøgelse, forpligtelse og styring. I hver fase gælder bestemte spilleregler hvor det kun er muligt at foretage ganske bestemte træk. Undersøgelsesfasen skal give begge spillere en idé om hvad systemet skal ende med at kunne og der er tre mulige træk: - kunden skriver en historie på et af papkortene som beskriver en nødvendig funktionalitet som systemet skal kunne og giver den en titel - udviklerne estimerer historien og skriver estimatet på papkortet. Hvis ikke det er muligt beder de kunden om at præcisere historien eller dele den op i mindre historier - kunden deler historien op i mindre historier I forpligtelsesfasen er formålet for kunden at vælge omfang og afleveringsdato for den næste release og at give udviklerne tryghed for at kunne levere det. Der er fire mulige træk: - kunden sorterer historierne i tre bunker i prioriteret orden; de som skal udvikles nu, de som kan vente lidt og de som kan vente lidt længere - udviklerne sorterer de tre bunker i prioriteret orden: dem som kan estimeres præcist, dem som kan estimeres med rimelig sikkerhed og dem som ikke kan estimeres - udviklerne fastsætter projekthastigheden i idealudviklingsdage per kalender uge - kunden vælger de historier som skal med i den første release enten ud fra ønsket om en fast afleveringsdato eller et bestemt omfang. I styringsfasen opdateres planen ud fra det som spillerne erfarer undervejs og der er fire mulige træk: - en release opdeles i et antal iterationer og kunden udvælger de historier som skal realiseres i starten af hver iteration - udviklerne har fejlestimeret historierne og beder kunden om at genvurdere hvilke historier som skal med på baggrund af den nye projekthastighed - kunden skriver en ny historie som skal tilføjes og må derfor fjerne en anden historie med et tilsvarende estimat - hvis udviklerne føler at planen er urealistisk kan de beregne den nye hastighed og genestimere resten af historierne I planlægningsfasen kan det blive nødvendigt at indhente relevant information omkring et emne. Det sker gerne fordi udviklerstaben ikke er godt nok inde i et teknologisk område til at kunne foretage en egentlig estimering, eller fordi problemområdet er ukendt. Her kan man bruge en spike (:spydspids) der er et hurtigt til bunds gående smid-væk eksperiment. Det eneste man bruger fra forsøget Side 16

17 METODEBESKRIVELSE DEN NATURSKÅNSOMME er erfaringen. Man kan ikke både bære tung bagage og samtidigt bevæge sig agilt. Vi har f.eks. intentioner om at bruge en objektorienteret database (OODB), men har aldrig rørt ved en. Derfor har vi her i starten igangsat en spike, for at finde ud af hvordan bruger man OODB i praksis; er det realistisk at vi kan nå at lære det og er det relevant? 2 Iterationsplanlægning Formålet med iterationsplanlægning er at detailplanlægge de aktiviteter udviklerne skal udføre i releaseperioden. Releaseperioden opdeles i x antal iterationer af 1-3 ugers varighed, men længden af iterationerne skal være konstant gennem hele projektet. Korte iterationer understøtter vores ønske om hurtig feedback. Kunden vælger de historier fra releaseplanen som er vigtigst at få udviklet i den første iteration. Denne strategi sikrer at det hele tiden er det vigtigste, som bliver lavet først. Derefter overtager udviklerne planlægningen og nedbryder historierne til opgaver som nedskrives på papkort og som er projektets konkrete programmeringsaktiviteter. Hver udvikler plukker et antal opgaver og for hver opgave estimerer han hvor mange idealudviklingstimer det tager at løse den. Hvis en opgave tager mere end to dage at løse deles den op i flere opgaver. Udvikleren fastsætter sin belastningsgrad, som er antal kalenderdage delt med antal idealudviklingsdage. I den første iteration er der selvsagt ingen tal at måle på og han må gætte. Opgaveestimaterne summeres og ganges med belastningsgraden. Hvis ikke udvikleren kan løse opgaverne indenfor længden af iterationen skal de lægges tilbage. Kan udviklerne samlet set ikke nå alle opgaverne beder de kunden om at fravælge historier eller dele heraf som udskydes til næste iteration. Projektet XP-planlægning stemmer godt overens med vores strategi, og det er vores intention at afprøve metoden. Vi er af den opfattelse at de enkelte dele af XP-planlægningen er så vigtige at alle elementer har relevans for vores projekt. Det kan være at iterationsplanlægningen som tager sig af den interne koordinering af projektaktiviteter er overflødig da vi kun er to udviklere, man lad os nu se! Som udgangspunkt holder vi os til metoden. Accepttest Umiddelbart efter iterationsplanlægningen skrives der i samarbejde med kunden accepttestcases til valgte user-stories. Dette gøres for at sikre at kunden får det han vil have. En accepttest er i almindelig forstand en test som fortæller om kravspecifikationen er acceptabel. Det er det også i XP, men her er kravspecifikationen som nævnt specificeret ved en mængde user-stories. Det er kundens opgave at specificere accepttesten. De fleste brugerhistorier vil omhandle funktionaliteter. Derfor går accepttest i XP også under navnet funktionstest, og er at sidestille med blackbox test af systemet. Men brugerhistorier kan sagtens indeholde krav 2 Se bilag 1 - Matisse op imod Java Side 17

18 METODEBESKRIVELSE DEN NATURSKÅNSOMME der er non-funktionelle. F. eks. krav til brugervenlighed, forudsætninger der skal ligge til grund for designkriterier osv. Disse krav skal også testes. Når accepttesten er godkendt er historien færdigudviklet. Projektet Vores strategi lægger op til et højt testniveau og sikring af entusiasme hos brugere/kunden. Derfor er det vigtigt at vægte denne praksis højt. Vi bliver nødt til løbende at integrere kunden i udviklingsarbejdet. Dette gør vi ved at få Knud til at udpege de dele af systemet han finder centrale at få testet. Det er en praksis der som forudsætning har kunden på stedet, så vi kan få afklaret problematikker med det samme. Det er en praksis vi får svært ved at imødekomme, så vi må prøve at få det bedste ud af det! Design Den centrale designparole er i XP: keep it simple. Dette kommer udfra en betragtning af at økonomien i systemudvikling lige såvel er en funktion af de samlede risici som af tiden. Designet skal være så komplekst at man kan gennemføre alle testcases, men så heller ikke mere. Konceptet er meget tæt knyttet til de fire grundværdier: det er nemmere at formidle et enkelt design, man finder hurtigere ud af om det design man sidder med er det rigtige fordi man får feedback hurtigt og det kræver mod, fordi et stop efter lidt design er på kant med udviklernes instinkter om at foregribe problemer. For i praksis at kunne gennemføre dette må vi udvikle en designstrategi der giver enkelt design, sikre hurtig test af designets kvalitet, gøre brug af vores erfaringer med det samme og mindske procestiden mest muligt. Designstrategi Designstrategien skal fungere ved trinvise ændringer. Design lidt ad gangen medfører at designet aldrig bliver færdigt men er under konstant udvikling. Intet overflødigt design. Designet skal opfylde de funktionelle og non-funktionelle krav som vi sidder med nu og her. Lad være med at foregribe begivenhedernes gang. Disse strategielementer er en konsekvens af at vi ikke helt præcist ved hvad der sker imorgen eller i overmorgen. Altså en situationsbestemt strategi. 1. lav et design der gør at du lige præcis har nok til at skrive en testcase 2. design og programmer indtil testen kører 3. start forfra Får man en god idé til ændring af designet skal den føres ud i livet pronto. Unittest Når man har planlagt, snakket design og skrevet accepttestcases udarbejder hvert udviklerpar unittests til de tasks som de hver især har plukket. Unittests er white- Side 18

19 METODEBESKRIVELSE DEN NATURSKÅNSOMME box tests. Unittests er en af hjørnestenene i XP. Den automatiske test skrives inden programmeringen går igang. Når testen kører er man klar til at gå videre. Det centrale koncept er at man skal spare tid ved at lave disse tests; færre tests sænker produktiviteten. Når produktiviteten falder stiger presset, hvilket medfører flere fejl som så igen sænker produktiviteten...osv. En ond cirkel man kan forsøge at forebygge. Derfor parolen: "test lidt, kod lidt, test lidt, kod lidt...!" For at kunne gennemføre automatiske tests må man lave et antal klasser hvori alle de gængse tests er skrevet. Dette er der nogle der har gjort på for os. I java kan man finde det på JUnit er ved at udvikle sig til at blive standarden inden for automatiseret unittest. Projektet Som sagt vægter vi test og kvalitetssikring højt. Har man sagt A må man også sige B, og unittesting er og bliver en central disciplin i dette projekt. JUnit Vi skal i det følgende behandle tests som objekter. JUnit definerer hvordan man strukturerer sine testcases, og tilbyder samtidig værktøjet til at køre testene. Man implementerer testen som en subklasse af TestCase: public class VoresTest extends TestCase{ //... Her skal vi realisere vores testmetoder der tester det relevante; f.eks. input, forventet output og reelt output. TestSuite Man samler et vilkårligt antal tests i et suite. JUnit er forsynet med såkaldte testrunners der kan køre samtlige tests den finder i et testsuite. Man skal blot overholde standarden og kalde metoden, der samler de tests man vil køre; suite(): public static Test suite() { suite.addtest(new VoresTest("nummer_1"); suite.addtest(new VoresTest("nummer_2"); return suite; } Husk at navngive metoder der skal testes efter standarden: start altid med test som eksempelvis testopen(), testclosed() osv. 3 Hvordan kører vi så en test? JUnit stiller to muligheder til rådighed: en statisk og en dynamisk. Ved statisk brug overrider man metoden runtest() i klassen TestCase. Denne er realiseret vha. et template-pattern. Testen gives et navn, så man kan genkende 3 Se Bilag 1 - Matisse op imod Java Side 19

20 METODEBESKRIVELSE DEN NATURSKÅNSOMME den hvis den giver anledning til en fejl. Her er den realiseret med en anonym indre klasse: TestCase test = new VoresTest("nummer_1") { public void runtest(){ //testmetode(); } }; test.run(); Ved dynamisk brug kan man nøjes med at tage klassen til den TestSuite man bruger med som parameter. Så henter den automatisk de metoder der skal køres (testmetode()...osv): TestCase test = new VoresTest("nummer_1"); public static Test suite(){ return new TestSuite(VoresTest.class); } Den sidste er mere kompakt men man er ikke sikret typetjek ved compiletime; en fejl i testnavnet vil gå ubemærket hen, indtil man får en NoSuchMethodException. Nu er vi klar til at køre vores test. JUnit stiller en GUI til rådighed hvorfra man kan køre sine tests: her indtaster man den test man vil køre og trykker "Run". Der genereres en rapport med fejl, som specificerer hvad der er gået galt. Man kan også vælge at køre sine tests i tekstmode fra en kommandoprompt. Parprogrammering Standardiseret kodning I XP sidder to udviklere sammen ved én skærm og programmerer. Den ene taster koden ind mens den anden tænker over om koden er fornuftig, om der findes en smartere løsning og om der mulighed for refaktorering. Programmeringen foregår ved at man sammen analyserer, designer, udarbejder tests og koder. Fordelen er at man udveksler tanker og idéer og på den måde lærer af hinanden og bliver bedre til at programmere. Man supplerer hinanden med sine styrker og svagheder som alt andet lige resulterer i større produktivitet, bedre kvalitet og større arbejdsglæde. Parprogrammering understøtter i høj grad kommunikation som er en af XP s grundlæggende værdier. Programmerer man alene er der en tendens til at man "hopper over hvor gærdet er lavest"; man dropper at skrive testcases og venter med at refaktorere og integrere. Men sammen holder man hinanden oppe på at overholde aftalerne og de fælles arbejdsmåder. For at kunne gennemføre fælles eje, parprogrammering, refaktorering hvor og når som helst er det essentielt at have en kodestandard. Det er klart at alle har deres særheder at arbejde med, men man aftaler en standard og arbejder på den. Efter kort tid kan man ikke se forskel på to forskellige programmøreres arbejde. Side 20