1. Prosessrapport. Experior - rich test editor for FitNesse -

Transkript

1 1. Experior - rich test editor for FitNesse -

2

3 1.1. Forord Denne rapporten inneholder dokumentasjon av prosessen og gruppens arbeid, i form av informasjon om blant annet bakgrunn for prosjektet, mål, rammebetingelser, planlegging og gjennomføring. Rapporten er først og fremst beregnet på sensor og intern veileder ved Høgskolen i Oslo, men kan selvfølgelig også leses av andre som måtte finne det interessant. Den er optimalisert for papir. Det forutsettes at leseren har erfaring i bruk av PC som verktøy, og gjerne også noe kjennskap til programmering og utvikling. Teknisk informasjon er for øvrig utelatt fra denne rapporten i så stor grad som mulig, men er tatt med der vi mener det er nødvendig for sammenhengen. For teknisk informasjon om Experior henviser til produktrapporten. Enkelt ord og uttrykk er bevisst ikke oversatt fra engelsk til norsk. Dels fordi det ofte mangler fullgode norske oversettelser, men også fordi det skal være lettere for leseren å søke mer informasjon om enkelte emner dersom dette skulle være ønskelig. For best sammenheng anbefales det at rapporten leses i kronologisk rekkefølge. Informasjon om testingen som er gjennomført vil være sentral informasjon for de som eventuelt skal videreutvikle prosjektet. Derfor er dette en integrert del av produktrapporten. Hensikten med prosjektet har vært å utvikle en ny teksteditor for FitNesse, et eksisterende verktøy som brukes for å teste applikasjoner. Derav undertittelen rich test editor. Gruppen tok selv initiativ ovenfor Bekk Consulting og ytret ønske om å gjennomføre hovedprosjekt hos dem. Vi vil i den forbindelse rette en takk til Bekk for å ha gitt oss denne muligheten. 2

4 1.2. Innhold 1.1. Forord Innhold Innledning Om bedriften Bakgrunn for oppgaven Hva er FitNesse? Situasjonen ved prosjektstart Mål Rammebetingelser Valg av hovedprosjekt Smidige utviklingsmetoder og Scrum Bakgrunn Scrum som metode Scrum i praksis Forberedelser, planlegging og prosjektstyring Oppstart og forberedelser Valg av løsning og teknologi Organisering Prosjektstyring Verktøy og versjonshåndtering Utviklingsprosess og gjennomføring Veiledning og samarbeid Kravspesifikasjonen og dens rolle Scrum i vårt prosjekt Estimering Mønster (pattern) Hovedutfordringer Iterasjonsbeskrivelse Iterasjon 0 (uke 2 3) Iterasjon 1 (uke 4 5) Iterasjon 2 (uke 6 7) Iterasjon 3 (uke 8 9) Iterasjon 4 (uke 10 11) Iterasjon 5 (uke 12 14) Iterasjon 6 (uke 16 17) Iterasjon 7 (uke 18-19) Oppsummering Produktet Prosess Referanser/kilder

5 4

6 1.3. Innledning Om bedriften Bekk Consulting A/S er et norsk konsulentselskap med 210 ansatte. Bekk leverer tjenester innen rådgivning, teknologi og forvaltning til store offentlige og private virksomheter. Et utvalg av Bekks kunder er Telenor, Gjensidige, Norwegian og NAV. Bekk har avdelingskontorer i Oslo og Trondheim Bakgrunn for oppgaven Bekk Consulting har prosjektengasjement hos Bankenes Betalingssentral, BBS. På dette prosjektet benyttes et testverktøy kalt FitNesse, som har vært utgangspunktet for vår oppgave Hva er FitNesse? FitNesse er et verktøy som brukes til testing av applikasjoner. Det kan benyttes for at kunden, i samarbeid med utvikleren, selv skal kunne verifisere at applikasjonen oppfyller kravene som er spesifisert. I prosjektet hos BBS har BBS egne dedikerte testere, som bruker FitNesse til å teste et system som utvikles av blant annet Bekk Consulting. Kommunikasjonen med brukeren skjer gjennom et webgrensesnitt, hvor man kan opprette, redigere og kjøre tester mot en applikasjon. Testene skrives inn i FitNesse som ren tekst i en svært enkel teksteditor, med en wikisyntaks. Ved å følge denne syntaksen bygges testene opp i en type tabell. I disse tabellene skriver testeren input til applikasjonen og hva som forventes som output. Når testen gjennomføres blir det sammenlignet hva som faktisk ble returnert fra applikasjonen opp mot det som var forventet. Hvis det som var forventet stemmer overens med det som ble returnert er testen passert og den funksjonen som ble testet fungerer etter kravet. FitNesse er særlig utbredt ved bruk av testdrevet utvikling og smidige utviklingsmetoder. Her i Norge benyttes det blant annet av, som nevnt, Bekk og BBS, Bring (tidligere Posten), Statens Pensjonskasse, KnowIT og Kantega i tillegg til en rekke andre i Norge og resten av verden. Gjennom FitNesse synliggjøres tester for andre enn utviklere. Testene kan skrives med vanlig språk, det vil si lite til felles med programmeringsspråk som benyttes og forstås av utviklere. Dette gjør at for eksempel kunder og andre interessenter kan bla rundt i tester, lese hva de utfører, og selv kjøre 5

7 dem for å verifisere at systemet faktisk oppfyller kravene de har spesifisert. De som skriver testene er ofte dedikerte testere uten programmeringsbakgrunn. I BBS-prosjektets tilfelle har de imidlertid en enorm kompetanse om hvilke krav systemet må oppfylle. Med FitNesse kan disse kravene spesifiseres i form av tester med et språk som testerne forstår. Dersom testen passerer er kravet oppfylt. I tillegg fungerer dette som en utmerket dokumentasjon, da testen er en helt konkret spesifikasjon av hva systemet gjør. Denne dokumentasjonen er også kontinuerlig oppdatert, i motsetning til det som kan være tilfelle med annen dokumentasjon. Der kan det hevdes at et system møter et spesifikt krav, men man har ikke noe bevis. FitNesse derimot, beviser at systemet faktisk gjør, eller ikke gjør, det som er spesifisert Situasjonen ved prosjektstart For en bruker ser og oppfører FitNesse seg tilnærmet som en vanlig nettside som vises i en nettleser. Testene har hittil blitt skrevet inn som ren tekst i en enkel teksteditor i FitNesse. Den har ingen funksjonalitet ut over muligheten til å lagre og å importere tabeller fra regneark fra Excel og lignende. Teksten vises helt uten støtte til brukeren i form av for eksempel variasjon i tekstfargeog størrelse eller kontroll av om det brukeren skriver inn er korrekt. Teksteditoren er vist i figur 1. Figur 1: Test vist i FitNesses egen editor Tester kan bli store dokumenter, både i lengde og bredde. Som nevnt skrives testene i dag med en wikisyntaks. Dette, kombinert med at editoren ikke gir noen støtte til brukeren, gjør at testene lett blir uoversiktlige og redigeringen av tester blir vanskelig. 6

8 Oppdragsgiver ønsket dermed en forbedret editor for skriving av tester. Dette var utgangspunktet for oppgaven og vårt hovedprosjekt Mål Hovedmålet for oppgaven ble derfor å utvikle en forbedret teksteditor for FitNesse, med navn Experior. Hvilke forbedringer den nye editoren skulle inneholde var ikke fullstendig definert fra oppdragsgiver, men det ble lagt frem følgende ønsker til hovedfunksjonalitet: Forbedret tabellredigering ved at piper, som brukes for å definere kolonner i tabeller i testene, automatisk settes under hverandre. Denne funksjonaliteten er heretter kalt aligning. På denne måten blir tabellene, særlig større tabeller, mer oversiktlige. Autofullføring av metodenavn, basert på programkoden som testen skal kjøres mot. Syntaks highlighting. For konkretisering av disse og andre krav henviser vi til kravspesifikasjonen. I tillegg ble det satt hovedmål som vi som gruppe kunne oppnå i løpet av prosjektet: Få erfaring i å gjennomføre en systemutviklingsprosess langt større enn det vi til nå har gjennomført, både med tanke på dokumentasjon, utvikling, samarbeid og presentasjon. Lære, for oss, nye teknologier, metodikker og språk. Få erfaring i å samarbeide med en reell oppdragsgiver Rammebetingelser For å kunne være i stand til å implementere det som var ønsket var det nødvendig at vi som utviklere skaffet oss god kjennskap til FitNesse. Både om hvordan det brukes rent praktisk, men også om programkode og oppbygging. Vi stod veldig fritt i valg av teknologi og løsninger. Siden det ble bestemt at vi skulle utnytte det eksisterende webgrensesnittet til FitNesse (mer om begrunnelse for dette i punkt 1.5.2) måtte Experior lages i en teknologi som egnet seg for web. I tillegg var det også ønskelig at det ikke skulle være nødvendig med nye rammeverk eller teknologier, verken i selve FitNesse eller hos brukeren, for at løsningen skulle fungere. 7

9 FitNesse er skrevet i Java, og selve integrasjonen av Experior inn i FitNesse måtte derfor gjøres i Java. Oppdragsgiver ønsket at Experior skulle gjøres tilgjengelig med lisens for åpen kildekode. Dersom det skulle brukes elementer fra andre prosjekter med åpen kildekode måtte dette selvfølgelig gjøres på korrekt måte i forhold til lisensen på de aktuelle prosjektene. Som prosessmodell for utviklingen har vi brukt Scrum, som er en agil metode. Vi valgte Scrum fordi Scrum er i utstrakt bruk som prosessmodell for mange store utviklerfirmaer, som for eksempel oppdragsgiveren vår Bekk Consulting. I tillegg var det et ønske fra oppdragsgiver. Mer om denne modellen følger senere i rapporten. Vi stod i utgangspunktet fritt til å velge verktøy som skulle benyttes i utviklingen, men med tanke på eventuell videreutvikling av Experior etter prosjektslutt var det en fordel hvis vi benyttet verktøy som oppdragsgiver benytter og er godt kjent med. Prosjektperioden har gått over 21 uker. Viser her til arbeids- og fremdriftsplan Valg av hovedprosjekt Gruppen ønsket å ha hovedprosjekt hos en bedrift som har utvikling av datasystemer som en del av sin kjernevirksomhet. Derfor rettet vi henvendelser til bedrifter som Bekk Consulting, Capgemini og ErgoGroup i november 2008 med tanke på samarbeid om hovedprosjekt. Bekk Consulting ga raskt uttrykk for at de var positive til dette og presenterte forslaget til oppgaven rundt FitNesse. Vi hadde et ønske om et reelt prosjekt, og ikke noe som var funnet på fra bedriftens side. FitNesse brukes i dag på flere prosjekter, blant annet hos vår oppdragsgiver Bekk, og dermed var det stor sannsynlighet for at Experior ville bli tatt i bruk i praksis. Dette har vært en stor motivasjon for oss. JavaScript (herunder AJAX) og webteknologier generelt var noe gruppen hadde begrensede kunnskaper om på forhånd. Denne oppgaven ga mulighet for å få mer innsikt i dette og dermed muligheten til å lære noe nytt gjennom hovedprosjektet. Samtidig kunne dette kombineres med Java, som gruppen hadde et ønske om å få mer dyptgående kunnskap om. I tillegg ga det oss muligheten til å lære et testverktøy (FitNesse) som er i utstrakt bruk. Alt i alt ga altså dette hovedprosjektet oss mulighet for å lære ikke bare nye 8

10 teknologier, men også, for oss, hittil ukjente verktøy. Dette var grunnen til at vi valgte å jobbe videre med dette prosjektet Smidige utviklingsmetoder og Scrum Siden vi har valgt å bruke Scrum som prosessmodell i vårt hovedprosjekt, så vil vi derfor skrive litt om denne modellen og hvorfor vi mener den ofte egner seg bedre, særlig for enkelte typer prosjekter, enn mer tradisjonelle metodikker Bakgrunn Det har vært en voldsom utvikling fra dataverdenens tidlige spede begynnelse til vår komplekse og sofistikerte verden slik vi kjenner den i dag. I begynnelsen tenkte vel ingen programmerer at programmering og applikasjoner skulle bli så sofistikerte og komplekse som de som utvikles i dag. Kravene til applikasjonene som utvikles blir større og større. Enkelte ser på utvikling av software som å bygge hus, at man starter med planlegging, tegninger, grunnmur, 1. etasje og så videre. Man kan se på disse fasene som et fossefall der en fase kronologisk etterfølges av den neste. Dermed kalles dette fossefallmetoden. I denne modellen er det ikke mulig underveis å gå tilbake for å endre eller utvide kravene som har blitt spesifisert. Dette er ofte ikke hensiktsmessig for utvikling av datasystemer, og det har vært, og er i mange tilfeller, behov for å tenke nytt og endre på modellene som benyttes i utviklingsprosessen. Både med fossefallsmodellen og med mer avanserte modeller som for eksempel RUP (Rational Unified Process) brukes mye tid på modellering og dokumentasjon, særlig før selve programmeringen starter. Dette er ikke alltid hensiktsmessig for alle typer prosjekter: 1. Bedriftene som driver med utvikling får ofte ikke penger for dokumentasjonen. Det er produsert kode og et fullverdig system som kundene er villige til å betale for. 2. Det viser seg ofte at ting må forandres i implementeringsfasen. Dermed har man brukt mye tid og ressurser på å dokumentere et system man trodde ble sånn og slik, men som ikke ble det likevel. I tillegg finnes mange applikasjoner som aldri blir ferdige i tradisjonell betydning, men hvor det stadig dukker opp nye krav og ønsker til funksjonalitet. Det beste 9

11 eksemplet er vel GMAIL som har befunnet seg på betastadiet siden tjenesten ble tilgjengelig for ca fem år siden. Softwareutvikling kan vanskelig sammenlignes med for eksempel bygging av en bro eller et hus. Når et hus først er designet i et prosjekt så vil det ikke endre seg dynamisk etter hvert som byggingen forgår. Dette er som oftest heller ikke teknisk mulig. I softwareutvikling har man imidlertid rent teknisk muligheten til å foreta kontinuerlige endringer og det er derfor hensiktsmessig å bruke utviklingsmetoder som også legger til rette for det Scrum som metode Som et alternativ til mer tradisjonelle metoder som fossefall og RUP har det dukket opp agile (smidige) metoder. Agile metoder har eksistert i mange år, men ikke fått skikkelig fotfeste før i de senere år. Mange har sett på agile metoder som noe bare hobbyprogrammerere kunne bruke. Men nå har agile metoder fått sin rennesanse for fult, de fleste store firmaene har tatt i bruk agile metoder, som for eksempel Scrum. Følgende analogi kan benyttes for å illustrere prinsippet: A pig and a chicken are walking down a road. The chicken looks at the pig and says, "Hey, why don't we open a restaurant?" The pig looks back at the chicken and says, "Good idea, what do you want to call it?" The chicken thinks about it and says, "Why don't we call it 'Ham and Eggs'?" "I don't think so," says the pig, "I'd be committed but you'd only be involved." ( Analogien er at pig og chicken kan henvises til programutviklerne og kundene og ellers alle som er involvert i hele prosjektet. Utvikleren vil være grisen, siden det er den som er mest involvert i prosjektet, og som dermed må ofre skinken. Kundene kan sees på som hønen, som skal kjøpe et produkt som igjen skal utvikles av en utvikler. Poenget er at Scrum involverer prosjektdeltakerne i stor grad. Ordet Scrum kommer fra et begrep i rugby, fordi det handler om å være sammen om å løse et problem. I rugby har man en kaptein (i Scrum en scrummaster) som oppsummerer progresjonen og hva man har oppnådd. Hovedtanken bak Scrum er at komplekse prosesser håndteres best ved en empirisk tilnærming. Med empirisk mener vi en tilnærming som bygger på erfaring og observasjon. Empiriske metoder krever: 10

12 Synlighet Synlighet betyr at de faktorer som styrer utfallet av prosessen må være synlige for dem som styrer selve prosessen. I tillegg til at faktorene må være synlige, må de også være sanne. Hva betyr det for eksempel at funksjonalitet er ferdig? Kodet i henhold til standarder? Testet? Kan utgis? Inspeksjon De forskjellige delene i en empirisk prosess må kontrolleres ofte nok slik at store avvik fanges opp. Dette forutsetter at den som kontrollerer og følger prosessen må ha kunnskap nok til å fange opp avvikene. Tilpasning Avvik som fører til at produktet ikke blir akseptert må føre til endringer. Endringer må gjøres så fort som mulig for å sikre at konsekvensene blir så små som mulig. Dette kan sammenlignes med Albert Einsteins definisjon av galskap: Å gjøre akkurat det samme om igjen og om igjen og forvente forskjellige resultat. Et prosjekt som drives med Scrum går gjennom flere iterasjoner. Iterasjonene er korte (for eksempel 1-4 uker) og hver iterasjon skal i prisnippet resultere i funksjonalitet som kan tas i bruk av kunden. Dette setter store krav til et tett samarbeid mellom kunde og leverandør. Den store styrken med å jobbe på denne måten er at det allerede tidlig i prosjektperioden sikres at alle aktører har innsikt i prosjektet. Innsikten beholdes gjennom hele prosjektet og sørger dermed for at produktet som skal overleveres, er i tråd med kundens krav og forventninger. Scrum kan innkapsle andre modeller og være den overordnede metoden for å styre et prosjekt. Scrum kan igjen også være innkapslet i andre modeller og være den "indre" metodikken som benyttes for å styre prosjektet Scrum i praksis I Scrum deles utviklingen av et system som nevnt opp i flere kortere iterasjoner. Iterasjonene kan variere i lengde, men vil normalt være av 1-4 ukers varighet. Oppsummert er målet for hver iterasjon å implementere den funksjonaliteten som er til enhver tid viktigst for kunden, og levere et fungerende forbedret system til kunden etter hver iterasjon. I starten av prosjektet lages et dokument kalt prosjektbacklog, som inneholder kundens ønsker og krav til produktet i en prioritert liste. Dette formuleres som 11

13 user stories, typisk på formen Som en bruker vil jeg kunne logge inn med brukernavn og passord og lignende. Prosjektbacklogen kan oppdateres kontinuerlig gjennom hele prosjektet. En sprintbacklog (sprint = iterasjon) lages ved å flytte (i samråd med kunden) punkter fra prosjektbacklog til sprintbacklog. Man velger da ut punkter som det er realistisk å kunne levere i løpet av neste iterasjon. Når sprintbacklog er definert, starter man på selve iterasjonen og utvikler funksjonaliteten. Under en iterasjon møtes utviklingsteamet i daglige, men korte, statusmøter for å rapportere fremdrift, synkronisere sine aktiviteter, og for å sette fokus på problemer og hindringer. User storiene, med deloppgaver, plasseres på en fysisk tavle med papirlapper. Hver oppgave kan befinne seg i fasene to do, in progress, verify og done. Etter hvert som utviklingen går fremover flyttes lappene med oppgaver mellom disse fasene. En iterasjon avsluttes med et møte hvor man går igjennom den leverte funksjonaliteten, presenterer løsningen slik den er, og evaluerer den avsluttede iterasjonen. Deretter starter man en ny iterasjon med et møte for å planlegge og å velge ut punkter fra prosjektbacklog og flytte dem til en ny sprintbacklog. Figur 2: Scrum i praksis I Scrum skal en av prosjektdeltakerne fungere som scrum-master. Denne skal blant annet sørge for at utviklingsteamet holder fokus og sørge for at metodikken følges. I tillegg skal scrum-masteren administrere burn down charts. Dette er et diagram i Scrum som sier noe om faktisk progresjon i forhold til estimert tidsbruk. 12

14 Fordeler ved bruk av Scrum som modell: Kontinuerlig og rask leveranse av fungerende programvare. Fungerende programvare leveres hyppig. Fungerende programvare er lett målbar. Tett samarbeid mellom kunde og leverandør øker sjansen for at kundens ønsker og forventninger oppfylles. Mange kjente store firmaer har tatt i bruk Scrum, for eksempel Bekk Consulting, Finn, Microsoft Norge og Capgemini. Dette viser at Scrum ikke bare er en tekno-flopp, men en seriøs utviklingsmetodikk som store firmaer innen IT har tatt i bruk. Informasjon om bruk av Scrum i vårt prosjekt finnes senere i rapporten Forberedelser, planlegging og prosjektstyring Vårt valg av prosessmodell har gjort at vi ikke har hatt en planleggingsfase i like stor grad som ved tradisjonell organisering, hvor kravene gjerne blir helt fastsatt før implementasjonen begynner. Enkelte grunnleggende elementer måtte imidlertid på plass før vi kunne gå i gang, og disse er det gitt en beskrivelse av her Oppstart og forberedelser Slik oppgaven var definert fra oppdragsgiveren var den nokså åpen. Det var i stor grad opp til oss å komme med forslag til hvordan oppdragsgivers ønsker kunne realiseres, i tillegg til å komme med egne forslag til funksjonalitet. Dermed måtte vi selv på forhånd sette oss inn i hvordan FitNesse kan brukes, for selv å kunne identifisere hvilken funksjonalitet som ville være hensiktsmessig. For å kunne begynne raskest mulig på selve prosjektet ved prosjektstart etter jul begynte vi å sette oss inn i bruken av FitNesse i begynnelsen av desember. På grunn av eksamen i andre fag ble tiden noe begrenset, men det gjorde at vi fikk en effektiv og god start i begynnelsen av januar. Vi stod også fritt i å velge teknologi, tilpasset web. Det var imidlertid ikke ønskelig at det skulle være nødvendig å implementere noen nye teknologier/rammeverk inn i FitNesse for å ta Experior i bruk. For å kunne foreta et valg var det nødvendig å sette seg inn i aktuelle teknologier for at vi kunne velge hvilke vi skulle jobbe videre med. 13

15 Valg av løsning og teknologi Ut i fra måten oppgaven var definert på var det i stor grad opp til oss hvordan sluttresultatet skulle se ut. Det som var klart var at oppdragsgiver ønsket en forbedret teksteditor til å skrive tester i. Oppgaveteksten skisserte et par mulige løsninger på dette: 1. Plug-in til Eclipse 2. Plug-in til FitNesses eksisterende webgrensesnitt En plugin til Eclipse ville vært lite fordelaktig for dedikerte testere som i utgangspunktet ikke har noe med selve programmeringen av systemet å gjøre. Å installere, drifte og kjøre en Eclipse-klient på alle testernes lokale maskiner kun for å skrive tester for FitNesse ville vært lite effektivt. I tillegg ville det blitt nødvendig med en del opplæring samt enda et program å forholde seg til for brukeren. Vi kom også frem til at det ville vært en stor utfordring å finne en smidig kobling mellom Eclipse og webgrensesnittet til FitNesse, som vi mener det ville vært vanskelig å få et godt resultat ut av innenfor tidsrammen til prosjektet. Dette forslaget til løsning ble derfor forkastet, og vi bestemte oss raskt for å lage den nye editoren som en plug-in til selve FitNesse. Oppgaveteksten var ikke spesifikk på om Bekk og BBS ønsket at Experior skulle være en utvidet teksteditor eller ha en WYSIWYG-tilnærming. Sistnevnte ville gitt funksjonalitet der en wiki-tabell ville blitt vist i Excel-format med fysiske tabeller fremfor å vise wikisyntaks i selve Experior. Etter samtaler oss i mellom, veileder og en fokusgruppe i BBS kom vi frem til at selv om dette ville sette terskelen lavere for førstegangsbrukere, er en ren teksteditor mer effektivt enn en løsning som legger opp til utstrakt bruk av mus. I tillegg er den eksisterende fremgangsmåten for å opprette, redigere og kjøre tester godt innarbeidet hos brukerne. Dermed var det ønskelig at den nye editoren skulle legge til rette for at selve fremgangsmåten og måten og bygge opp tester på skulle kunne skje tilnærmet som i dag. Forbedringene i den nye editoren skulle i hovedsak konsentreres rundt eksisterende måte å jobbe på ved å tilby støtte og hjelp til brukeren. FitNesse kjøres på en veldig enkel webserver skrevet i ren Java, uten noe annet rammverk. Det understrekes her ren Java, det vil si tilsvarende som 14

16 benyttes ved utvikling av tradisjonelle frittstående applikasjoner, uten tradisjonell server-teknologi i bunnen. Serveren har naturlig nok ikke støtte for PHP, ASP.NET eller lignende, og det var som nevnt heller ikke ønskelig at det skulle være nødvendig å implementere nye teknologier i FitNesse for å ta Experior i bruk. Dermed var det begrenset hva vi kunne benytte av teknologi. Derfor måtte vi begrense oss til kode som enten kjøres hos klienten, eller direkte i FitNesse sin Java-løsning. Teknologiene bestod da av Java, HTML og JavaScript. Det finnes en rekke rammeverk og hjelpemidler som forenkler utviklingen av JavaScript, og optimaliserer automatisk kode tilpasset alle nettlesere. Noen av disse er Google Web Tookit, JQuery og Prototype. Etter prøving og feiling kom vi frem til at vi måtte bruke ren egenutviklet JavaScript for å oppnå den kontrollen vi trengte over nettleserens funksjonalitet. Vi ville heller ikke være avhengige av eksterne bibliotek for å få den funksjonaliteten vi ønsket. På grunn av store forskjeller i hvordan de ulike nettleserne håndterer JavaScript og hvilken informasjon det er mulig å hente ut og gi nettleseren har vi av hensyn til prosjektets tidsbegrensning valgt å fokusere på Mozilla sin motor, Gecko, som brukes i Firefox. Dette er gjort etter avtale med oppdragsgiver. Det er også implementert noe funksjonalitet for Internet Explorer, men for fullstendig funksjonalitet må Mozilla Firefox benyttes. I en mer tradisjonell nettløsning ville vi forsikret oss om at koden fungerte i alle nettlesere for å nå ut til så mange som mulig, men siden Experior har en relativt begrenset potensiell brukergruppe er løsningen som er valgt hensiktsmessig Organisering Ett eller flere av gruppemedlemmene jobbet med hovedprosjektet hver dag, innenfor normal arbeidstid. Vi har hatt fast møtetid på HiO tirsdag, torsdag og fredag. Denne faste møtetiden mener vi har vært svært viktig for å sikre en jevn progresjon, og vi føler mer ansvar når ting er fastsatt enn om det avtales underveis. Vi har valgt ikke å føre detaljerte timelister. Vi mener det er resultatet ved prosjektlutt som teller, og ikke antallet timer som hver og en har brukt. Samtlige gruppemedlemmer har tatt to eller flere fag dette semesteret, i tillegg til hovedprosjektet. Dette har til tider påvirket hvor mye tid som har blitt brukt på hovedprosjektet. Ingen av gruppemedlemmene har imidlertid tatt de samme fagene, slik at hvis et medlem har vært litt opptatt med et annet fag 15

17 en periode har de to andre hatt mer tid. Derfor føler vi at dette ikke har gått nevneverdig ut over progresjonen underveis Prosjektstyring Helt fra oppstarten har vi vært bevisste på å dokumentere hva som til enhver tid har blitt gjort, i en prosjektdagbok. Ikke nødvendigvis så langt og omfattende, men tilstrekkelig til at vi har holdt oversikt over hva som til enhver tid har foregått og hvilke problemer som vi har møtt på. Denne har vært til stor hjelp i forbindelse med denne prosessrapporten, men også for vår veileder fra Bekk som har kunnet følge progresjonen fra dag til dag. Dagboken er, av hensyn til omfanget, ikke med i denne skriftlige dokumentasjonen, men er tilgjengelig via vår hjemmeside. I tidligere prosjekter har vi sendt dokumenter frem og tilbake på e-post. Dette er en lite effektiv løsning hvor det er risiko for at informasjon går tapt. Derfor har alle prosjektstyringsdokumenter for dette prosjektet blitt lagt ut på et begrenset område på Google Docs, hvor vi, vår interne veileder ved HiO og veileder hos Bekk har hatt tilgang. Gjennom Google Docs har alle kunnet jobbe på samme dokument og det har vært enkelt å spore hvilke endringer som har blitt gjort Verktøy og versjonshåndtering Som utviklingsmiljø har vi benyttet Eclipse. Dette mener vi har vært et hensiktsmessig valg. I og med at dette prosjektet har innebåret programmering i både Java og JavaScript var det hensiktsmessig å kunne foreta all programmering i samme utviklingsmiljø. Ikke minst i forhold til versjonshåndtering. Her har vi benyttet Google Code, som igjen benytter subversion (SVN). Det ble installert en plug-in for Eclipse som muliggjør synkronisering med SVN direkte fra Eclipse. Vi hadde på forhånd varierende kunnskaper om bruk av SVN for versjonshåndtering. Dermed har det vært noe tilvenning og enkelte problemer i starten, men etter hvert som vi har blitt mer fortrolige med verktøyet har dette fungert utmerket. I og med at Experior skulle integreres i et allerede eksisterende system ble det flere avhengigheter til eksterne JAR-bibliotek og lignende i prosjektet. Derfor benyttet vi, etter råd fra veilederen ved Bekk, Apache Maven som prosjektbygger. Maven benyttes i tillegg av Bekk i dag og det er dermed også hensiktsmessig dersom det skal drives videreutvikling av Experior senere. Maven inneholder funksjonalitet for kompilering, testing, rapportering, 16

18 samarbeid og dokumentasjon. Det egner seg svært godt for å holde styr på avhengigheter. Vi hadde ingen erfaring med Maven før prosjektstart, og derfor ble det nokså komplisert og tidkrevende og sette det opp. Her bistod veilederen vår Bekk med god hjelp. Når Maven først var i drift har dette fungert svært godt. For mer utfyllende beskrivelse av benyttede teknologier henvises det til produktrapporten Utviklingsprosess og gjennomføring Veiledning og samarbeid Samarbeidet vårt med veilederen og kontaktpersonen ved Bekk, Rune Flobakk, har vært svært godt gjennom hele perioden. Han har alltid vært tilgjengelig for oss og stilt opp med gode svar på våre spørsmål når det måtte være. Han har vært veldig flink og forutsigbar med å definere kravene og hvilke ønsker som Bekk hadde til dette hovedprosjektet. Måten veilederen ved HiO, Geir Skjevling, har lagt opp veiledningen på har passet oss og denne typen prosjekt svært bra. Han har alltid vært tilgjengelig for oss med raske tilbakemeldinger dersom det var noe vi stod fast på eller ønsket mer informasjon om. Vi har ikke hatt faste møter og tidspunkt, men har henvendt oss til han ved behov. Han har for øvrig hatt tilgang til styringsdokumentene og prosjektdagboken og har kunnet følge progresjonen på den måten. Vi er også godt fornøyd med samarbeidet innad i gruppen, og vi føler vi har utfylt hverandres kunnskaper svært bra. Det ble ikke satt opp noen samarbeidsavtale i forkant, da vi tok det som en selvfølge at vi skulle være profesjonelle nok til å håndtere eventuelle uenigheter som måtte oppstå uten en slik avtale. Dette har vist seg å stemme Kravspesifikasjonen og dens rolle Oppdragsgiver ønsket ikke å fastsette fullstendige krav ved prosjektstart, men derimot formulere disse underveis i prosessen. Dermed var det heller ikke definert en fullstendig kravspesifikasjon tidlig i prosjektet. Oppdragsgiver presenterte tidlig ønsker til hva som kunne være aktuell funksjonalitet. Dette var svært overordnet og har blitt konkretisert og lagt til 17

19 kravspesifikasjonen til gjennom hele prosjektet. Dette har blitt gjort av oppdragsgiver og oss i fellesskap. Veilederen vår ved Bekk Consulting bruker ikke selv FitNesse til daglig, men har god kjennskap til begrensningene i FitNesses egen teksteditor. For å lage et produkt som var mest mulig i tråd med hva de som bruker FitNesse til daglig ønsker har vi gjennomført intervju og observasjon av to testere på BBS, som bruker FitNesse til daglig. Dette ble gjort tidlig i prosjektet, og det var svært nyttig å se hvordan FitNesse blir brukt i praksis. Intervjuet var svært åpent og kombinert med vår observasjon av praktisk bruk ga dette oss god innsikt i hvilke funksjonalitet det ville være hensiktsmessig å implementere. Kravspesifikasjonen har fungert som en rettesnor for overordnede krav. Ut i fra dette har det blitt formulert user stories, som dermed har fungert som en konkretisering og presisering av hva de enkelte kravene til funksjonalitet egentlig har innebåret. Det har blitt laget use case modell av de deler vi mener har vært nødvendig for konkretisering av krav. Se vedlegg D. I og med at kravspesifikasjonen har blitt utformet underveis er det godt samsvar mellom denne og det produktet som beskrives i produktdokumentasjonen Scrum i vårt prosjekt Vi bestemte oss tidlig i prosjektperioden for at vi ville benytte utviklingsmetodikken Scrum, siden vi hadde en unik mulighet til å lære Scrum i praksis gjennom vår veileder fra Bekk Consulting. Oppdragsgiver ønsket at vi skulle komme tidlig i gang med programmering, og ønsket ikke at vi brukte tid på tydelig kravdefinering og modellering med for eksempel UML. Verken i starten eller i prosjektet forøvrig. Vi mener denne tankegangen passer vår type prosjekt svært godt. Tidlig i prosjektet hadde vi liten kunnskap om prosjektet generelt og hadde ikke vært i stand til å lage gode modeller på det tidspunktet. Dermed hadde vi måttet gjøre om disse når vi hadde fått mer kunnskap. Vi mener det har vært langt mer hensiktsmessig å bruke tiden på å skaffe seg kunnskap og drive med selve utviklingen. Generelt har det vært lite fokus på tradisjonell modellering med UML eller E/R i dette prosjektet. E/R er naturlig utelatt da det ikke inngår noen database. Det har blitt laget en overordnet use case modell for konkretisering av krav der vi føler dette har vært nødvendig. I tillegg har det blitt laget et klassediagram for 18

20 den delen av prosjektet som har blitt implementert i Java. Oppdragsgiver har ikke hatt noe ønske eller krav om at UML skulle brukes i det hele tatt, men vi har tatt med de elementene vi føler vi har hatt behov for. Vi har utviklet forslag til funksjonalitet, ut fra aktuelle user stories, og kontinuerlig presentert det for oppdragsgiver, i tråd med ett av prinsippene bak Scrum. Ved å se forslaget til funksjonaliteten i praksis føler vi det har vært mye enklere å drøfte forslag til ny funksjonalitet enn om man kun ser funksjonen beskrevet på et papir. Drøftingen av ny funksjonalitet har foregått kontinuerlig, av typen ja, dette er et godt stykke på vei, men ved å gjøre sånn og slik i tillegg ville det blitt enda bedre og når jeg ser dette kom til å tenke på en annen funksjon som hadde vært svært nyttig og så videre. Etter hvert som funksjonalitet har blitt fullført har denne blitt tatt i bruk av oppdragsgiver underveis. Etter hvert som flere og flere user stories har blitt definert har det blitt definert hvilke oppgaver hver story sannsynligvis ville inneholde. Hver oppgave ble plassert på virtuelle Scrum-tavler 1 i form av virtuelle lapper. Figur 3: En versjon av en av våre virtuelle scrum-tavler 1 På 19