HØGSKOLEN I OSLO OG AKERSHUS FôrIt CDS Stian Strøm Anderssen, Mikkel Sannes Nylend og Shahariar Kabir Bhuiyan Gruppe 10 27.05.2014
Forord Formålet med denne rapporten skal være å gi leseren en innsikt i arbeidet under prosjektperioden. I rapporten skriver vi om prosess-verktøy som ble brukt under prosessen. Rapporten inneholder også en lengre beskrivelse av prosessen hvor vi går inn på hver sprint og drøfter hva som ble gjort. En drøfting om arbeidsmetoden er også med i rapporten, her skriver vi litt om KISS prinsippet og hva dette innebærer. Vi drøfter også kravspesifikasjonens rolle i prosessen. Denne rapporten kan leses av alle. En trenger ingen spesiell forkompetanse. 1
Innholdsfortegnelse Forord...1 Innholdsfortegnelse...2 1 Arbeidsforhold og samarbeid...4 1.1 Gruppen...4 1.2 Kunnskapsnivå og egen læring...5 1.3 Dialog med Goodtech...5 1.4 Dialog med EWOS...6 2 Verktøy...6 2.1 Trello...6 2.2 SVN...6 2.3 Google Hangout...7 2.4 Tavle...7 2.5 SCRUM...7 3 Prosessen...7 3.1 Planleggingsfasen...8 3.2 Forprosjektfasen...8 3.3 Sprint 1-10.02.2014 til 20.02-2014...9 3.4 Sprint 2-24.02.2014 til 7.03.2014... 10 3.5 Sprint 3-10.03.2014 til 21.03.2014... 11 3.6 Sprint 4-24.03.2014 til 05.04.2014... 12 3.7 Sprint 5-07.04.2014 til 18.04.2014... 13 3.8 Arbeidet etter siste sprinten... 14 4 Arbeidsmetode...14 4.1 KISS prinsippet... 14 5 Kravspesifikasjonens rolle i utviklingsprosessen...15 2
3
1 Arbeidsforhold og samarbeid I dette kapittelet beskrives arbeidsforhold og samarbeid i gruppen under prosjektperioden. 1.1 Gruppen Gruppen har siden starten av prosjektet hatt et tett samarbeid. Vi har gjennom mange prosjekter på Høgskolen valgt å jobbe sammen. Derfor var det naturlig for oss å jobbe sammen på hovedprosjektet. Grunnet utviklingsmiljøet applikasjonen skulle utvikles i, har vi holdt til i Goodtech sine lokaler på Karihaugen siden starten av januar frem til mai. Gruppen har jobbet 3-4 ganger i uken med prosjektet med en gjennomsnittlig arbeidstid på 7 timer per dag. Samarbeidet i gruppen har gått svært bra! Vi har hatt dialoger og vært ærlige med hverandre. Hvis det har vært vi er uenig i, har ingen hatt noe problemer med å ta det opp med resten av gruppen. Dette har skapt et veldig godt samhold og god dialog medlemmene imellom. I tillegg til dette har vi også sørget for å gjøre litt sosiale ting sammen etter arbeidstid for å ivareta gruppedynamikken på et personlig plan. Under følger en tabell som viser ansvarsfordelingen i prosjektet. Ansvarsområde Gruppeleder Brukergrensesnitt Kartløsning Språk Risikoanalyase Testing Webservice Kodemiljø (Maven moduler, xml- config filer) Produktdokumentasjon Brukerdokumentasjon Hvem Stian Mikkel Shahariar Stian Alle Mikkel/Shahariar Mikkel/Stian Shahariar Stian Mikkel Shahariar 4
Testdokumentasjon Utviklingsprosessdokumentasjon Kvalitetsikring Shahariar Stian Alle 1.2 Kunnskapsnivå og egen læring I et gruppearbeid hender det ofte at kunnskapsnivået gruppemedlemmene vil variere. Både Shahariar og Mikkel har vist fra et svært tidlig stadium at programmering er en veldig sterk side hvor de kan mye. Det har derfor vært naturlig at de har tatt et visst ansvar i prosjektutviklingen. Alle på gruppen har hjulpet hverandre med å få til bra kode hvis det har oppstått noen problemer noen steder. Vi fordelte forskjellige ansvarsområder til ulike gruppemedlemmer. Shahariar var ansvarlig for å drifte hjemmesiden og oppdatere prosjektdagboken jevnlig. Mikkel har hatt ansvar for at koden vi skriver er av god kvalitet. Stian har hatt ansvar for at dokumentasjonen blir skrevet, og dette på en god måte. Ved hjelp av denne fordelingen har vi alle fått lov til å ha ansvar for felter vi er sterkest i. Vi har alle jobbet med forskjellige områder under hele prosjektet, men denne fordelingen har vært en forsikring på at det som blir levert skal være av kvalitet. 1.3 Dialog med Goodtech Harald Pedersen og Øystein Myhre har vært ansvarlige for oss under prosjektperioden. De har begge hjulpet til med å få oss til å forstå prosjektets omfang, og hva som skal utvikles. Harald Pedersen har vært ansvarlig for oss under prosjektperioden, og Øystein Myhre har fremgått som en kodeveileder, det var han som hadde ansvar for å få utviklet webservicen etter våre ønsker og krav. Øystein har også hjulpet oss med å få satt opp miljøet til utvikling. Siden Goodtech hadde litt forskjellige standarder til kodemiljø enn det gruppen var vant til fra før, var dette en veldig sterk fordel. Dialogen med Goodtech har i hele prosjektfasen vært særdeles bra. Vi har fått all den hjelpen vi har trengt og mer til. Både Harald og Øystein har hjulpet gruppen med å få renskrevet dokumenter etter en viss standard. Kravspesifikasjonen ble i tidlig revidert av Øystein hele fem ganger før den ble satt som endelig. 5
Vi anser arbeidet med Goodtech som et svært vellykket samarbeid. Vi ble tatt imot på en svært positiv og åpen måte som ble gjenspeilt i hjelpen vi fikk under prosjektarbeidet. 1.4 Dialog med EWOS Gruppen har siden starten av prosjektfasen forholdt seg til Goodtech, og deres ønsker og krav. Harald Pedersen har vært den som har stått for videre dialog med EWOS. På slutten av prosjektet sendte vi en lengre mail til EWOS hvor vi viste litt hva vi hadde gjort og skrevet om de. EWOS har samtykket til å bli omtalt som kunden i prosjektet. 2 Verktøy Nedenfor følger en liste med verktøy som ble brukt under prosjektarbeidet. 2.1 Trello Trello er en webapplikasjon som lar brukere lage «post it» notater med korte kommentarer om en oppgave som skal utføres. Trello tillater muligheten for å lage en status på notatet som blir laget. Status kan være «To do». «Doing», «Testing» eller «Done». Gruppen brukte Trello i startfasen på prosjektet for å fordele oppgaver, men gikk i sluttfasen over til å bruke tavle. 2.2 SVN SVN er et versjonskontrollverktøy for kode, også kalt Subversion. SVN er et online versjonskontrollverktøy som gjør det mulig å laste opp forskjellig versjoner av en fil. Ved bruk av versjonskontroll ivaretar en at prosjektet hele tiden er oppdatert med en kjørende versjon. Hver gang en fil blir endret må den sjekkes inn på SVN. Hvis de andre gruppemedlemmene skal ha tilgang til filen, kan de trykke på filen, og oppdatere den mot riktig versjon som har blitt lastet opp på SVN. 6
2.3 Google Hangout Google sin chatfunksjon som fungerer på stasjonære og mobile enheter. Gruppen har brukt Hangout flittig i hele utviklingsprosessen for å avtale møtetider, og gi nyttig informasjon. Hangout tillater også videokonferanser, noe gruppen har benyttet seg av. 2.4 Tavle I slutten av prosjektarbeidet begynte gruppen og bruke mer tavle. Det var hele tiden ting som måtte gjøres, og beskjeder ble oppdatert jevnlig. Istedenfor å bruke Trello, valgte gruppen da og gå over til bruk av tavle til å skrive ned viktige gjøremål og beskjeder. 2.5 SCRUM SCRUM er en smidig utviklingsmetode som blir brukt under prosjektutvikling. Ved bruk av SCRUM får utviklere mer å si under prosjektutviklingen. I SCRUM deler en opp prosjektet i flere iterasjoner som er små prosjektfaser. Disse iterasjonene blir kalt sprinter, hver sprint har en fast lengde. I vårt prosjektarbeid har dette vært ti dager. Etter hver sprint setter en seg ned og evaluerer sprinten som en helhet. En ser på hva som har blitt utført, hva som skal utføres i neste sprint og hva som har vært utfordrende. For mer informasjon om våre sprinter, vennligst les kapittelet om prosessen, eller se på vårt vedlagte Gant-Diagram. 3 Prosessen I dette kapittelet skal vi skrive om prosessen og belyse ulike prosjektfaser med hva vi gjorde i detalj. På hjemmesiden vår har vi laget en prosjektdagbok hvor leser kan følge utviklingen fra dag til dag gjennom hele prosjektet. Kapittelet består av flere underkapitler som beskriver de ulike sprintene i kronologisk rekkefølge. Vedlagt i sluttrapporten finnes et Gant diagram som viser fremdriftsplanen for prosjektet oppdelt i iterasjoner. 7
3.1 Planleggingsfasen Dette var den første starten på prosjektarbeidet. I denne perioden var hovedmålet og finne det mest relevante prosjektet som kunne gi oss mest utbytte. I vårt tilfelle ble dette FôrIt CDS applikasjonen hos Goodtech ASA. Etter noen møter med veilederne i Goodtech ble det laget en prosjektskisse og en statusrapport om prosjektets fremgang. 3.2 Forprosjektfasen Dette var oppstartfasen for det virkelige prosjektarbeidet. Arbeidet startet en tidlig morgen fredag 6 januar. I begynnelsen av prosjektet handlet det om å bli kjent med ulike utviklingsmiljøer og rammeverket som skulle benyttes i produktutviklingen. Denne perioden handlet mye om å gjøre seg komfortabel med miljøet vi skulle tilbringe de neste 5 månedene i. En betingelse oppdragsgiver satt, var at prosjektet skulle legges ut på bedriftens intranett. Dette ble gjort for å ivareta sikkerheten under utvikling, samt det var enklere for veilederne og følge utviklingen, og se til at oppsett ble utført i henhold til gitte standarder. For gruppen medførte dette at vi var avhengig av å sitte hos Goodtech når vi skulle utvikle produktet. Grunnet sikkerhetsbegrensninger ble det vanskelig å kunne sitte på skolen å jobbe med prosjektet. Det ble derfor laget en intern avtale i gruppen at vi skulle jobbe med prosjektet hver mandag, tirsdag og fredag fra klokken 08:30 til 16:00 hos Goodtech. Parallelt med planleggingen begynte vi å se på mulighetene som fantes i rammeverket vi skulle bruke til utvikling. Siden produktet er utviklet ved hjelp av rammeverket Vaadin måtte vi sette oss inn i dette for å lære oss hvilke muligheter og begrensninger som fantes. I en tidlig oppstartfase ble det utviklet en svært enkel demo som siden ble vist frem på forprosjektpresentasjonen på Høyskolen i Oslo og Akershus. Gruppen satte opp en plan for de fremtidige sprintene. Ved hjelp av estimeringsteknikken Planning Poker satte gruppen opp et estimat på hvor lang tid det skulle ta å utvikle de ulike modulene. Dette ble grunnlaget for de senere sprintene som er nevnt i senere avsnitt. Det ble også bestemt av hver sprint skulle være på 10 dager (mandag- fredag uken etter) 8
3.3 Sprint 1-10.02.2014 til 20.02-2014 Den første sprinten handlet mye om å bli kjent med prosjektet og skrive kravspesifikasjon. Vi hadde nå en god oversikt over prosjektets omfang, men det gjensto svært mye når det kom til prosjektets utforming, og hvilke standarder som prosjektoppsettet skulle følge. I en tidlig fase i prosjektet ble det bestemt at gruppen skulle kun lage klientsiden av applikasjonen. FôrIt CDS skulle være lagdelt hvor gruppens ansvar var applikasjonlaget. Applikasjonen skulle kommunisere med en webservice som igjen kommuniserte med selve FôrIt databasen. Det var veilederen vår Øystein Myhre som skulle være ansvarlig for å utvikle webservicen basert på våre analyser og tilbakemeldinger. Vår oppgave ble derfor å finne ut hva slags data som webservicen skulle hente ut. Siden vår applikasjon er en forenklet utgave av et større eksisterende system, var det en omfattende oppgave å finne ut hvilken data som var relevant for oss. Vi fikk tilgang på en databasemodell av det eksisterende systemet for å skjønne litt mer om logikken bak kulissene. Denne modellen var svært komplisert og det medførte i mange spørsmål som vi måtte finne ut av. Vi brukte over en uke på å lage en liste med hvilke data som webservicen skulle hente ut. Ved å lage listen over data vi trengte innså vi også en annen utfordring i prosjektfasen. Siden Goodtech skulle utvikle en modul til prosjektet vårt, ble gruppen avhengig at de leverte innen tid. Siden vi er studenter som skriver en oppgave på vegne av en oppdragsgiver er det naturlig å tro at dette prosjektet ikke er høyeste prioritet internt i bedriften. Forutsetningen for å få et ferdig virkende produkt var da at Goodtech leverte sin modul innen avtalt tid. Mye av tiden i sprint 1 gikk ut på å sette opp et prosjekt som var i henhold til Goodtech sine retningslinjer når det kom til kode, filhierarki, kommentarer m.m. Det ble i en tidlig fase bestemt at vi skulle bruke SVN til versjonskontroll av prosjektet. Gruppen skulle bruke Goodtech sitt interne savn oppsett for kode underveis i prosjektet. Siden det var mange regler vi måtte følge brukte vi ganske lang tid på å sette opp et prosjekt som var i henhold. 9
Den 17.02.2014 fikk vi satt opp vårt første testprosjekt som stemte overens med standarden til Goodtech. Når prosjektet var satt opp i henhold var det mulig for oss å begynne på implementasjonsfasen. 17.02.2014 satte vi opp klassehierarkiet til prosjektet som skulle være produktet vårt. Dette var første skritt på veien til et ferdig produkt. I starten av sprint 1 ble gruppen enige om en del funksjoner som skulle implementeres i løpet av sprinten. Ved hjelp av en gjøremålsliste som ble oppdatert fra dag til dag gikk dette arbeidet veldig i henhold til det vi planla. Siden Goodtech skulle lage webservicen var det opp til oss og lage testdata vi kunne bruke under utvikling av prosjektet. I sluttfasen av sprinten satte vi opp første utkast til det som skulle være vår dummydata. De viktigste funksjonene som ble implementert i sprint 1 Førsteutkast til modellen i prosjektet Noen views ble definert med et potensielt design Dummydata ble implementert for senere utvikling 3.4 Sprint 2-24.02.2014 til 7.03.2014 Vi var nå inne i kodefasen av prosjektet. Nå var det viktig at de største endringene skulle implementeres. For at ting skulle gå etter planen var det viktig at vi fulgte gjøremålslisten og jobbet systematisk. I starten av sprinten satte vi derfor opp den ønskede funksjonaliteten vi skulle implementere i løpet av denne sprinten. Ved hjelp av nettsiden Trello.com tildelte gruppen ulike oppgaver til medlemmene og satte opp frister for når de ulike modulene skulle være ferdig. Hovedfokuset for sprint 2 var å få implementert en kartløsning i prosjektet vårt. Siden sluttbrukerne av appen er avhengig av å kunne spore fiskefôret sitt, var det viktig at vi fant en kartløsning som funket godt til mobile enheter. 10
Shahariar ble oppnevnt til kartansvarlig i begynnelsen av prosjektet. Han implementerte to kart fra Google og Leaflet i hvert sitt prosjekt og testet ut dette. Etter noe testing ble det bestemt at vi skulle bruke V-Leaflet til videre utvikling da dette var mer mobilvennlig. Vi jobbet også mye med å implementere de ulike sidene som skulle dukke opp i applikasjonen. Her lagde vi flere potensielle løsninger hvor alle hadde et felles mål, om å være enklest mulig å bruke for en sluttbruker. I slutten av sprinten satt vi igjen med utkast til en del layouts som applikasjonen kunne ha. De viktigste funksjonene implementert i sprint 2: Kartløsning fra V-Leaflet integrert i applikasjonen Layout og design ble implementert i flere sider Dummydataklassen ble oppdatert med flere data og logikk for å hente ut dataen. Innloggingsfunksjon til applikasjonen. 3.5 Sprint 3-10.03.2014 til 21.03.2014 I denne sprinten handlet det mye om å få implementert løsninger og fikse problemer som hadde oppstått så langt i prosjektet. Vi hadde også en demo med veilederne våre i Goodtech og fikk tilbakemeldinger på det vi hadde gjort så langt. Vi fikk mye innsikt i hva som kunne gjøres bedre og fikk en prioritert liste på prioritert funksjonalitet. For at prosjektet vårt også skulle bli relevant som en bacheloroppgave valgte vi å endre prioriteringen på kravene vi satte i kravspesifikasjonen. Tidligere hadde vi satt muligheten for å endre språk som en tilleggsfunksjonalitet. For at applikasjonen i fremtiden skal være enklere å distribuere i utlandet, valgte vi å sette språk som en prioritert funksjonalitet. Dette skulle vise seg å være en liten utfordring, men etter sprinten var over hadde vi klart å implementere et førsteutkast til en språkløsning. I denne perioden ble det mest fokus på koding, da det var viktig å få ting ferdig til avtalt tid og med en god kvalitet. Gjøremålslister ble laget hver dag og ble brukt som en pekepinn på hvordan vi lå an i prosjektet som en helhet. 11
Språkfunksjon - bruker kan nå velge å få applikasjonen på norsk eller engelsk Endring i innloggingsfunksjon - Endret innloggingsfunksjonen til å bruke en innloggingsform som var sikrere enn det vi hadde fra før Design og layout på tekst, målet var å prøve å få en enklest mulig layout Dagmodus og nattmodus for kart lagt til, dette skal være en fin ekstrafunksjonalitet som tar liten plass, og som gjør at sluttbruker kan endre kontrast på kartet hvis vedkommende finner dette bedre 3.6 Sprint 4-24.03.2014 til 05.04.2014 Sprint 4 var en av de mest omfattende sprintene vi hadde. Nå hadde gruppen fått god oversikt over hva som måtte gjøres, og hvilke problemer vi sto ovenfor. Med to måneder til innlevering må en begynne å ta en del valg på hva som skal utvikles, og hva som må legges på is. I denne sprinten handlet det mye å om fullføre moduler som vi tidligere har begynt på, og samtidig begynne på de siste inkrementene av prosjektet som vi hadde planlagt å lage. Vår veileder Øystein Myhre kom flere ganger med forslag til hva vi kunne lage for å sørge for at vi ikke hadde noe dødtid. Parallelt med utvikling av applikasjonen, ble det i denne perioden utviklet en webservice som FôrIt CDS skulle kommunisere med for å hente data. For å få applikasjonen ut i produksjon er viktigheten av denne webservicen svært stor, da det er den som henter ut dataen som skal vises fra FôrIt sine databaser. Gruppen ble også klar over noen feil i moduler som var utvikle og vi måtte ta noen skritt tilbake for å få forbedret disse feilene da disse var kritiske for at applikasjonen skulle fungere på riktig måte. Moduler som ble laget i denne sprinten Bedret språkfunksjon ved å bruke Set og get-metoder på globale språkvariable. Prosjektet ble lagdelt i et Businesslayer som inneholder metoder for logikken. Goodtech har en del rutiner og regler når det kommer til å lage prosjekter som skal slippes ut til produksjon. Denne perioden har gått mye med til å sørge for at vårt prosjekt er delt opp i moduler som kreves for at applikasjonen lett kan legges ut på nett, og samtidig enkelt kommunisere med en webservice. 12
På slutten av sprinten hadde vi en evaluering av kodingen med veilederen vår. Øystein tok stikkprøver av koden og fikk oss til å fortelle om hvorfor vi hadde kodet den slik vi gjorde. Dette gjorde at vi ble mer obs på feil vi hadde gjort og muligheten for å utvikle det vi hadde gjort til noe bedre. Han virket veldig fornøyd med det vi hadde gjort så langt i prosessen, men hadde noen kommentarer til noe av logikken vår. Til sprint 5 ble det bestemt av vi skulle fokusere mer på feilhåndtering problemer som måtte oppstå når koden kjører, viktigheten av å logge feil som måtte oppstå er svært stor da applikasjonen skal driftes i fremtiden, og da er det svært mye enklere om en vet hva som er feil. 3.7 Sprint 5-07.04.2014 til 18.04.2014 Dette var den siste sprinten vi satte opp i planen vår. Denne sprinten gikk ut på å gjøre ferdig de siste funksjonene og ferdigstille applikasjonen mot levering. I denne sprinten ble det fokusert mye på å få fullført enhetstestingen av applikasjonen, da webservicen vi skulle bruke snart var ferdig, var det viktig at vi fikk implementert denne inn i vår applikasjon. Siden det skulle være en liten forskjell på applikasjonen vi skulle levere inn til Høyskolen og applikasjonen som skal settes i produksjon på Goodtech, var det viktig at vi la opp til at endringene skulle bli minimale for at funksjonaliteten ville fungere for begge. Enhetstestingen var et viktig mål for oss og få fullført. Vi har hele tiden hatt fokus på at det vi leverer skal være så komplett som mulig. Applikasjonen skal kunne settes direkte ut i produksjon når vi leverer, samt at den skal være enkel å videreutvikle. I slutten av sprinten hadde vi et møte hvor vi planla ukene mot innlevering. På planen hadde vi satt oss som mål og bli ferdig med et leverbart utkast av applikasjonen. Siden webservicen ble litt forsinket i utviklingen, måtte vi bruke noen av de siste ukene med å få implementert denne inn i vår applikasjon. Det ble også bestemt av fokus mer og mer skulle gå mot å ferdigstille sluttdokumentasjonen. 13
3.8 Arbeidet etter siste sprinten I starten av prosjektfasen ble det bestemt hvor lange sprinter gruppen skulle ha, og hvor lenge hver enkelt skulle vare. For gruppen betydde det nå at alle sprinter var over. Hovedarbeidet med funksjonaliteten var over. Det som nå gjensto var å få renskrevet dokumentasjon og ryddet i kode. De neste ukene gikk mye til avslutningsarbeider. Ved hjelp av Øystein Myhre fikk vi hjelp til å få sluttført et produkt som tilfredsstilte Goodtech sine ønsker og krav på en god måte. Samtidig som applikasjonen vår ble ferdig ble det også implementert en løsning i FôrIt databasen som knyttet alle lokasjonsid er med et passord. Nå kunne en logge inn med hvilken som helt lokasjonsid, så lenge det var lagt til i databasen. Gruppen hadde som mål og få vår applikasjon opp og gå mot denne nye databasen før prosjektet ble avsluttet. Tirsdag 14 mai ble arbeidet med klienten ferdig. Nå lå det en ferdig FôrIt CDS klient som kommuniserte via webservicen ute på Goodtech sine testservere. Vår arbeid med produkt var nå ferdig. 4 Arbeidsmetode Kravspesifikasjonen ligger vedlagt bakerst i sluttrapporten og kan brukes som et supplement til dette kapittelet. 4.1 KISS prinsippet I kravspesifikasjonen vår skrev vi at vi kom til å dele opp prosjektfasen i sprinter på 2 uker. Vi skulle arbeide etter KISS prinsippet. (Keep it simple stupid). Dette har vi gjort gjennom prosjektarbeidet. Målet med applikasjonen var at den skulle være så enkel å bruke at alle kunne bruke den med minimal opplæring. En av de vanligste fellene utviklere kan gå i er å utvikle et program som er så komplisert at utvikler knapt skjønner hva som er kodet. Ved å ha jevnlig revidering av kode og utfyllende 14
kommentarer i klassene har det vært enkelt og gå tilbake og se hva vi tenkte når koden ble utviklet. Struktur og formatering har vært den viktigste regelen vi har satt under prosjektperioden. Ved hjelp av vår kodeveileder på Goodtech, Øystein Myhre har vi jevnlig hatt demonstrasjoner av koden og på funksjonaliteten. Vi har valgt å bruke en smidig utviklingsmetode til prosjektet. Prosjektet er delt inn i ulike moduler hvor vi har fokusert på spesielle deler av produktet. Parallelt med modulutviklingen har vi gått tilbake til tidligere moduler for å fikse feil og bugs som har blitt funnet i senere i utviklingen. Kvalitetssikring ved revidering av tidligere arbeid har vært en visjon vi har jobbet etter. Revidering av tidligere kode ved å hele tiden prøve og forbedre det vi har laget. Vi følger en metodikk som handler å finne feilen tidligst mulig og forbedre den fortløpende. 5 Kravspesifikasjonens rolle i utviklingsprosessen Ved oppstart av prosjektfasen bestemte vi oss for å følge en smidig utviklingsmetode. Vi bestemte oss for å bruke SCRUM metodikken og delte opp prosjektene våre i iterasjoner og faser. Ved bruk av denne metodikken kan en gjøre endringer i prosjektplaner underveis. Det er ikke avtalt et fullstendig fast oppsett på forhånd. Dette har gjort at vi underveis har endret litt på prioriteringene på hva som skal gjøres først. Vi satte blant annet opp at språkfunksjon i applikasjonen skulle være ønsket prioritet, men dette ble implementert allerede i sprint 3. Gruppen har hatt et ønske om å levere et fullstendig produkt med utfyllende funksjonalitet som skiller seg ut fra andre tilsvarende produkter på markedet. Når vi startet å utvikle FôrIt CDS var vi klar over at det fantes tilsvarende produkter levert av konkurrenter, så vår oppgave var å lage et produkt som på mange måter ville anses å være unikt med et bredt spekter av funksjonalitet. Vi bygde derfor opp en kravspesifikasjon i samråd med Goodtech og EWOS som inneholdt svært realiserbare krav. Kravspesifikasjonen har vært vår guide mens vi har jobbet med prosjektet vårt. Vi har under hele prosjektprosessen evaluert modulene vi har laget opp mot kravspesifikasjonen. 15
Derfor kan vi med trygghet si at kravspesifikasjonen har en god relevans med det ferdige produkt som er utviklet. I starten av prosjektarbeidet fikk vi en mail fra Goodtech som EWOS hadde fått tilsendt, hvor det var kommet noen ønsker til krav for systemet. Vi fikk beskjed om å forholde oss til Goodtech og deres ønsker om funksjonalitet. De var de som kom til å ta dialogen med EWOS om hva som skulle utvikles. Fordelen med dette er at kravene da blir enklere å implementere. En person som ikke har kompetanse i IT utvikling har liten innsikt i hva som er mulig å utvikle. Personer uten kompetanse kan lett sette krav som vil være svært vanskelig å implementere. Ved å la Goodtech stå for kommunikasjon med kunde, så har de redusert arbeidet vårt med å komme frem til en løsning som alle vil være fornøyd med. 16