Arena Kundereskontro. Prosessrapport

Transkript

1 Arena Kundereskontro Prosessrapport

2 PROSESSRAPPORT FORORD Denne rapporten beskriver prosessen gruppe 25 gjennomgikk i planleggingen og gjennomføringen av vårt hovedprosjekt på Høgskolen i Oslo våren Rapporten vil blant annet ta for seg alle steg i utviklingsprosessen, utfordringer underveis, løsninger på problemer, fremgang underveis og strategi. En refleksjon rundt oppgaven tar til slutt for seg spørsmål rundt hva gruppen gjorde bra, hvilke erfaringer som er verdifulle og andre konklusjoner som er blitt erfart. Ordbruken i rapporten forutsetter at leser er kjent med utviklingsmetodikker og teknologi som er benyttet i oppgaven. Dette innebærer først og fremst bruk av fagterminologi, referanser til eksisterende utviklingsmetodikker og uttrykk. Dersom det skulle oppstå forvirring rundt visse uttrykk kan leser se om ordet finnes i vedlagt referanseliste. Rapporten er strukturert i til sammen seks deler: Oppstart: Kort introduksjon om hvem gruppen er, hvordan oppgaven ble til og litt om oppdragsgiveren Kredinor. Planlegging: Går inn på alle deler av forarbeidet vi som gruppe har gjennomgått. Her dokumenteres utarbeidelse av kravspesifikasjonen, omfang og begrensninger, valg av metodikk og teknologi, arbeidsmiljø og fremdriftsplan. Parallellitet; Beskriver utfordringene vi hadde rundt effektivisering av modulen, og hvordan vi løste dette ved bruk av asynkron programmering. Utviklingsprosessen: Beskriver hvordan hele prosessen har blitt gjennomført og drøfter i hvilken grad vi fulgte valgt metodikk og fastsatt fremdriftsplan. Konklusjon: Er en oppsummering av hele prosessen hvor alle valg, endringer, avgjørelser og steg underveis drøftes. Her beskrives både deler som har fungert godt, og deler som ikke har fungert fullt så godt. S i d e 2 30

3 INNHOLD Forord Planlegging og metode Forløp til prosjektstart Omfang Arbeidsteknikker og utviklingsmetoder Planlegging av sprinter Arbeidsfordeling Scrum Prosjektstyringsverktøy Prosjektstyringsdokumenter Prosjektdagbok Møtereferat Fremdrift Fremdriftsplan Arbeidslogg Arbeidsforhold Verktøy Visual Studio Versjonskontroll C#/.NET AngularJS og Bootstrap Dropbox Facebook Messenger yed Graph Editor S i d e 3 30

4 1.6.8 Google Docs IT-faglig forankring av prosjektet Utviklingsprosessen Benyttet metodikk Design og Arkitektur Uavhengiget Paralellitet GUID Sync vs Async Demonstrasjon for Kredinor Samarbeid Kravspesifikasjonen og dens rolle Bakgrunn for kravspesifikasjonen Utarbeidelse Vår erfaring med kravspesifikasjonen Endringer av kravspesifikasjonen Konklusjon Konklusjon Resultat Læringsutbytte Videreutvikling Hva ville bli gjort annerledes? S i d e 4 30

5 1 PLANLEGGING OG METODE Planleggingen var en viktig del av prosjektet. Her la vi til rette for absolutt alt som skulle gjøres, og forsøkte å forutse alle kommende steg i så tilstrekkelig omfang som mulig. Dette innebar å dele hele prosessen i så konkrete steg som mulig, planlegge hvert individuelle steg og deretter prioritere disse i logisk rekkefølge. Det var naturlig å starte planleggingen med å utrette en kravspesifikasjon, noe som beskrives i kapitel 4 [Kravspesifikasjonen og dens rolle]. Følgendearbeid ble utarbeidet under planleggingen: Kravspesifikasjon Risikoanalyse Sprintoversikt Grovskisse av systemet Oversikt over klasser og namespaces Valg av metodikk Store deler av planleggingsprosessen foregikk ved at gruppen satt samlet i lokalene til HiOA. Vi benyttet verktøy for å lage skisser av klasse-diagram, tenkte så kreativt vi kunne og forsøkte å definere så store deler av prosessen som mulig. Alle stegene under planleggingen ble gjort i fellesskap. Ingen vesentlige uenigheter oppstod under planleggingen, da ettersom vi hadde samme formeninger om de fleste avgjørelser som ble tatt. 1.1 FORLØP TIL PROSJEKTSTART To viktige deler av forløpet til prosjektet var å danne en gruppe og deretter finne en oppgave. Gruppen ble dannet av fire studenter som kjente hverandre fra før, og på grunnlag av flere faktorer som tilsa at samarbeidet ville bli vellykket. Oppgaven ble tildelt igjennom et av gruppemedlemmene som er ansatt i inkassoselskapet Kredinor. Detaljer rundt dannelsen av gruppen, kontakten med Kredinor og bakgrunnen for den endelige oppgaven beskrives i Presentasjon-rapporten [Dannelse av gruppen]. Kredinor presenterte to alternativ vi kunne velge mellom: Utvikle en ny intranettside for selskapets ansatte som inneholder nyheter, informasjon til ansatte, dokumentarkiv, personalhåndbok og andre relevante lenker. Utvikle en.net modul for deres nye saksbehandlingsklient, Arena. På gitt tidspunkt syntes vi begge oppgavene virket interessante. Arbeidet med intranettsiden ville bestått av mye front-end utvikling og linking til andre portaler, slik at S i d e 5 30

6 ulike ansatte ville hatt hver sine innfallsporter til informasjon. Alle i gruppen hadde på dette tidspunktet erfaring med front-end utvikling og webapplikasjoner fra tidligere kurs, og vi så for oss en intranett side spekket med spennende funksjonalitet. På tross av dette fristende alternativet endte avgjørelsen på den andre oppgaven. Vi syntes oppgaveteksten virket innbydende, og så for oss en lærerik prosess med et sluttprodukt som ville være til stor nytte hos oppdragsgiver. Produktet ble presentert som et klassebibliotek, noe som gjorde oss nysgjerrige ettersom det var en oppgave ulik alle oppgaver vi tidligere hadde gjennomført i skolesammenheng. Vi fikk inntrykk av at oppdragsgiver hadde en relativt klar formening om hva som skulle utvikles, men at vi stod fritt til å bestemme omfang og sentrale deler selv. Det faktum at denne oppgaven var mer back-end orientert enn det første alternativet hadde dessuten stor innflytelse på vår beslutning, ettersom samtlige medlemmer hadde størst interesse for back-end utvikling. 1.2 OMFANG Oppgaven ble tildelt med mye ønsket funksjonalitet, men det var oss til oss selv å definere omfanget. Ønsket produkt var et klassebibliotek som på sikt skulle være med på å erstatte mye av funksjonaliteten i systemet K90 1. Modulen skulle støtte alle kravene til oppdragsgiver, men vi bestemte selv hvor stor del av funksjonaliteten vi skulle implementere. Etter å det første møtet med oppdragsgiver hadde vi dannet oss et klarere bilde av hva oppgaven gikk ut på. Vi bestemte så overordnet omfang. Vi vedtok at oppgaven skulle bestå av å implementere et klassebibliotek som ga funksjonalitet for å ta imot innsendte filer med transaksjoner, postere disse med full sporbarhet og overgi bokførte posteringer til eksterne regnskapssystem. I planlegging av omfanget tok vi tid, krav og ønsket funksjonalitet i betraktning Foruten klassebibliotekets kjernefunksjonalitet bestemte vi oss tidlig for at vi ville utvikle et Web API som benyttet klassebibliotekets funksjonalitet. Vi så på dette som en nødvendighet både for å kunne teste og vise frem modulens funksjonalitet, og for å utvide funksjonalitet. Foruten dette så vi det også som en spennende mulighet til å utvide oppgavens omfang. Web API er detaljert i eget vedlegg. Prosjektet innebar også god planlegging, og estimering av tid, for å komme i mål til fristen. Prosjektets offisielle start var januar 2015, og innleveringsfrist var 26. mai K90 Kjernesystem i Kredinor som bokfører transaksjoner S i d e 6 30

7 Vi definerte omfanget til følgende deler: Oppgavens hovedfokus skulle ligge på implementasjonen av klassebiblioteket. Alle krav i kravspesifikasjonen skal oppfylles, og implementasjonen skal foregå i henhold til rangering av viktigst funksjonalitet. Klassebiblioteket skal leveres som en fullstendig løsning, men det skal være enkelt å videreutvikle modulen for oppdragsgiver Et Web-API skal benytte seg av klasse-biblioteket på samme måte som en fremtidig klient. Web-API et skal i første omgang gjøre det mulig å gjennomføre bokføringer av innsendte transaksjoner, men det skal også muliggjøre videre funksjonalitet. 1.3 ARBEIDSTEKNIKKER OG UTVIKLINGSMETODER Ved prosjektstart var valg av metodikk en stor og viktig avgjørelse vi måtte ta. Dette valget preget hele prosjektet ved å bestemme selve måten vi skulle gjennomføre arbeidet på. Vi var alle enige i at vi ville gå fult inn for å følge den metodikken vi valgte på korrekt vis, både for erfaringens- og prosjektets skyld. Vi var alle enige i at vi ville benytte smidig utviklingsmetodikk. Smidig metodikk er svært populært og begreper som Scrum, Kanban og Extreme Programming dukker ofte opp utviklingssammenhenger. Begrepet smidig utvikling kan være vanskelig å forstå, men disse tre påstandene kan være med å synliggjøre behovet: Det vil aldri gå å samle alle krav til en løsning før du begynner! Kravene vil mest sannsynlig endre seg underveis! Det vil alltid være mer å gjøre enn man har tid til 2! Ved smidig utviklingsmetodikk rettes fokuset mot full kontroll på arbeid, god kommunikasjon i gruppen og ferdige biter av produktet levert ved fastsatte datoer. Vi diskuterte bruken av de metodikkene vi visste om (med erfaring fra faget systemutvikling) og kom frem til at Scrum var en metodikk som tilfredsstilte alle våre krav samtidig som det var en metodikk med mange gode anbefalinger. Et av gruppens medlem hadde erfaring med Scrum etter å ha jobbet med utviklingsprosjekt hos Kredinor, og hadde da både erfaring og kunnskap han overførte til resten av gruppen. Vi fikk inntrykk av at Scrum ga god oversikt, basert på uttalelser som at metodikken gjør det blir enklere å håndtere kompleksitet gjennom tverrfaglig samarbeid (teoretisk, men ikke praktisk sett i vårt tilfelle) og at gruppemedlemmene høster lærdom av resultatet etter hver sprint. 2 S i d e 7 30

8 En anen grunn til at valget falt på denne utviklingsmetodikken var at den var godt dokumentert 3, slik at det var enklere for gruppen, som uerfarne Scrum-utviklere, å sette seg inn i og følge metodikken PLANLEGGING AV SPRINTER Med Scrum arbeider man i sprinter (korte perioder), der man ved slutten av hver sprint ønsker å ha et fullstendig produkt å vise frem til oppdragsgiver, for å avdekke eventuelle misforståelser når kravspesifikasjonen ble utarbeidet. De arbeidsoppgavene som blir satt opp til en sprint skal være gjennomført når sprinten er ferdig. Til sammen syv sprinter på to uker hver ble gjennomført i prosjektets løp. Sprintene bestod av utvalgte deler av selve backloggen 4 til prosjektet. Backloggen ble definert som et sett av brukerhistorier ut ifra den ferdige kravspesifikasjonen, og vi rangerte brukerhistoriene etter prioritet og logisk rekkefølge før vi fordelte disse til ulike sprinter. Brukerhistoriene ble rangert etter graden de utgjorde av viktighet og den rekkefølgen vi følte var mest logisk. Vi benyttet verktøyet Trello 5 i denne planleggingen, og la alle brukerhistorier vi hadde definert i en To-Do tabell. Dette var en omfattende prosess som krevde stor innsikt i det kommende arbeidet, og vi benyttet kravspesifikasjonen i stor grad. Den endelige backloggen bestod av over 120 brukerhistorier med hvert sitt Trello-kort, hvorav mange av disse inneholdt detaljerte sjekklister og omfattende beskrivelser. Vi brukte mye tid på å gjøre hvert kort så grundig som mulig, da vi følte at det ville lette utviklingsprosessen senere. Figur 1 - [Skjermbilde av et kort] Sprintene ble definert etter at backloggen var klar. Vi planla en sprint fordele brukerhistoriene på syv bolker som til sammen inneholdt hele backloggen. De brukerhistoriene vi syntes hørte sammen ble lagt i samme sprint. For hver sprint foretok vi en realistisk vurdering rundt sannsynligheten for gjennomføring av sprinten. Her tok vi både høyde for estimert arbeidsmengde, varighet av implementasjon og vanskelighetsgrad. Vi tok også høyde for at nye oppgaver ville dukke opp underveis. 3 Mye benyttet kilde: 4 Backlog - En prioritert liste med kravspesifikasjonen av produktet presentert som brukerhistorier 5 Trello Beskrevet i kapittel [2.1.4 Utviklingsverktøy] S i d e 8 30

9 Bruken av de planlagte sprintene beskrives i utviklingsprosessen ARBEIDSFORDELING I planleggingsperioden brukte vi mye tid på å organisere oppgaven i henhold til Scrums prinsipper. Gruppemedlemmet som var ansatt hos oppdragsgiver hadde oftere kontakt med kontaktpersonen der enn resten av gruppen, og det ble derfor naturlig å utnevne han til Scrum-master. Dette innebar at han fikk et overordnet ansvar for å tilse at prosessen gikk som den skulle, sørge for at alle hadde nødvendige verktøy og i det hele tatt legge alt til rette for at prosessen skulle gå så smidig som mulig. Det faktum at han hadde benyttet Scrum i tidligere jobb-sammenheng gjorde han dessuten mer erfaren enn resten av gruppen. Arbeidsfordelingen har vært preget av selvgående arbeid, frihet til å ta tak i de oppgavene vi selv har villet og jevn ansvarsfordeling. Dette foregikk ved at vi i starten av hver sprint gikk igjennom alle kort i back-loggen, før hver og en av gruppen ga kall på de oppgavene han ville arbeide med. Selvstendigheten denne arbeidsfordelingen medførte ga hvert medlem ansvar for å bidra til felles utbytte. Denne fordelingen viste seg å fungere svært bra. Etter hvert som prosessen utviklet seg begynte vi å finne våre egne interessefelt, samtidig som vi la merke til hverandres interessefelt. En potensiell svakhet ved denne type arbeidsfordeling er at noen gruppemedlem kan sluntre unna arbeid og gjør mindre enn andre. Dette unngikk vi ved å benytte Trello til å sette hvert medlem til sitt sett med oppgaver og ved å ha standup-møter de dagene vi jobbet sammen. De dagene vi ikke jobbet sammen kommuniserte vi ofte på web, og oppdaterte sprint-backloggen. På denne måten hadde vi alltid oversikt over hvem som gjorde hva. Oppdatering av prosjekt-dokumenter, utarbeidelse av møte-agendaer og diskusjon av alle steg underveis ble gjennomført med hele gruppen til stede. På denne måten fikk alle bidra til utviklingen av produktet, og alle fikk bidra med sine meninger og ideer SCRUM Arbeid med Scrum var nytt for flere i gruppen. Vi hadde enkelte startvansker og tok oss selv i å unnvike bruk av sentrale prinsipper i metodikken under oppstart. Metodikken vi fulgte var ikke utelukkende tradisjonell Scrum. Det viktigste for oss var å fokusere på smidige prinsipper og ha fokus på fremgang i utviklingen. Dette var noe vi fikk til. I løpet av prosjektets gang avholdt vi mange Stand-up møter. Disse møtene ble som oftest gjennomført i lokalene til Kredinor alt fra 3 til 5 dager i uken. Møtene varte i alt fra minutter, og der presenterte vi hva hver av oss hadde gjort dagen før, hva S i d e 9 30

10 vi skulle jobbe med den dagen og eventuelle hindringer som stoppet oss fra å utføre arbeidet. Fra tid til annen ble disse møtene holdt etter endt arbeidsdag, og det var som oftest da de kunne vare lengre enn planlagt. Dette skyltes ofte det siste punktet, hvor diskusjoner rundt funksjonaliteten og implementasjonen til modulen tok lang tid. Noen ganger kunne disse diskusjonene fortsette på Facebook helt frem til vi møttes neste dag. Selv om vi ikke holdt oss helt tro til «oppskriften» på stand-up møter fulgte vi prinsippet om uformell og daglig kommunikasjon. Det faktum at alle i gruppen kjente hverandre fra før bidro til å senke formaliteten. Vi snakket fritt hele veien og hadde alltid oversikt over hverandres oppgaver BRUK AV TRELLO Bruken av Trello var svært sentralt under hele planleggingsprosessen. Vi benyttet dette verktøyet til å planlegge hele produkt-backloggen, til å dele denne opp i sprinter, og etter hvert til å fordele alle arbeidsoppgavene imellom gruppen. En svakhet ved bruk av Trello som prosjektstyringsverktøy, er at Trello ikke loggførte antall timer hver gruppemedlem brukte på de forskjellige brukerhistoriene. Det kunne ha vært interessant å få ut statistikk på tidsbruk tilknyttet de forskjellige brukerhistoriene, for bruk ved fremtidig tidsestimering. En fordel ved bruk av Trello er at det er mulig å tildele flere gruppemedlemmer den samme oppgaven. Det er også mulig å implementere sjekklister til hver brukerhistorie. På den måten kunne man se hva som var fullført, og hva som ikke var det FORBEDRINGSPOTENSIAL I retrospekt er gruppen enige om at vi burde vært flinkere til å følge den fastsatte Scrum rutinen. Vi kunne vært strengere mot oss selv og fokusert mer på å holde faste standup-møter for å opprettholde god rutine. I enkelte perioder hadde vi ikke formelle standup-møter. Dette førte ikke til store problemer, men vi erfarte at når man først begynner å gå vekk fra enkelte rutiner, er det fort gjort å gå vekk fra andre rutiner. I de periodene vi ikke hadde like mange arbeidsmøter, merket vi at produksjonshastigheten sank. Ved å ha et fast sted (Kredinor/HiOA) å jobbe på, ble det enklere å holde fokus på arbeidsoppgavene, og ikke bli forstyrret av eksterne faktorer. S i d e 10 30

11 1.3.4 PROSJEKTSTYRINGSVERKTØY Etter å ha bestemt oss for å utvikle i Scrum fikk vi noen råd fra veileder om hvilke verktøy som var tilgjengelige. Vi bestemte oss for å benytte Trello 6 som prosjektstyringsverktøy. Dette verktøyet gjorde det enkelt å organisere prosjektet. Med Trello kan man flytte brukerhistorier mellom selvdefinerte kolonner. Vi endte opp med å bruke fem forskjellige kolonner som fungerte som vår Sprint-backlog 7 (se også figur 2): Backlog: Alle brukerhistoriene/kravene en sprint består av. To Do: Konkrete oppgaver som følge av kravene/brukerhistoriene. In Progress: Arbeidsoppgaver som er under arbeid. Testing: Arbeidsoppgaver som testes. Finished: Fullførte oppgaver. En tendens vi fort la merke til var at "Testing" tabellen økte hyppig i innehold sammenlignet med resten av tabellene. Dette var fordi det var vanskelig å si seg 100% ferdig med en arbeidsoppgave etter at den var implementert, og dessuten var det fristende å starte på nye oppgaver så fort et kort ble flyttet vekk fra «In-progress» Sprint backlog - En liste med alt arbeid som skal fullføres i løpet av en gitt sprint. Opprettes under planleggingen av en sprint ved å velge et antall brukerhistorier og dele disse opp til konkrete oppgaver. S i d e 11 30

12 Figur 2 - [Skjermbilde av Trello] Trello var både nyttig i planleggingsfasen og i utviklingsfasen. Det forble vårt mest nyttige utviklingsverktøy i både planlegging og utviklingsprosess. 1.4 PROSJEKTSTYRINGSDOKUMENTER I løpet av prosjektet opprettet vi mange dokumenter relatert til fremgangen. Noen av disse ble utviklet under planleggingen, andre ble utviklet kontinuerlig igjennom hele prosjektet. Disse dokumentene var: prosjektdagbok, møtereferater, fremdriftsplan PROSJEKTDAGBOK Vi hadde på forhånd planlagt å skrive detaljerte dags-referat underveis. Dette ble gjort fra dag til dag og alle i gruppen bidro. Dagbøkene ble skrevet i MS Word og vi fikk tilgang via en delt mappe på Dropbox. Der skrev vi hvem som jobbet med hva og problemer og løsninger vi støtte på underveis. Bruken viste seg å være nyttig av flere årsaker. Vi fikk bedre kontroll på hva som ble gjort, hvem som hadde gjort hva, og hvilke problem vi hadde støtt på fra dag til dag. Senere i prosessen, når vi begynte å skrive rapporten, benyttet vi dagboken for dokumentere det arbeidet vi hadde gjort flere måneder i forveien. S i d e 12 30

13 1.4.2 MØTEREFERAT I løpet av prosjektet hadde vi flere møter med både Kredinor og veileder på HiOA med jevne mellomrom. I forkant av hvert møte utarbeidet vi en møteagenda som ble sendt til veileder eller oppdragsgiver på epost. Under møtet ble dette dokumentet fylt ut med referat og en kort oppsummering, slik at vi skulle få så mye ut av møtene som mulig. Vi hadde stor nytte av møtene og møtereferatene. Problem vi støtte på og spørsmål relatert til programmeringen ble først og fremst avklart med veileder fra HiOA. Vi stilte spørsmål, fremviste arkitektur og kode og mottok tilbakemeldinger, eksempler og kommentarer på det arbeidet vi hadde gjort. Figur 3 - [Referat Mal] Spørsmål vi hadde som mer rettet mot løsningens funksjonalitet, krav og innhold, avklarte vi i møte med veiledere fra Kredinor. Vi avtalte møter som ble gjennomført i Kredinors lokaler. Vi hadde stor nytte at dette, særlig under planleggingsfasen. Vi avholdt et møte helt i starten, hvor vi stilte alle grunnleggende spørsmål, og utarbeidet så en kravspesifikasjon og klassearkitektur ut ifra det vi lærte dette møtet. Vi fikk så tilbakemeldinger på det vi hadde gjort, og laget nye utgaver av både kravspesifikasjon og arkitektur med de mottatte innspillene tatt i betraktning. Vi fikk også innføring i sentrale økonomiske prinsipper og begreper i disse møtene. Noen av gruppemedlemmene hadde aldri før hørt begreper som «posteringer» og «reskontromeldinger», og disse møtene var derfor svært lærerike. S i d e 13 30

14 1.4.3 FREMDRIFT Figur 4 - [Gant Diagram] Bildet over viser vår faktiske fremgang i prosjektet, de forskjellige fasene og hvor mye tid som ble brukt på hver aktivitet. Sprint én endte opp på 2 uker og 2 dager. Vi ville ha sprintperioder som endte på onsdager, fordi det den dagen passet best for alle gruppemedlemmene å møtes FREMDRIFTSPLAN Etter beslutning av valgt metodikk, teknologi og verktøy var tatt, satte vi i gang med oppsett av en fremdriftsplan. Vi ble enige om at utviklingen av produktet skulle pågå frem til 10. mai, og at produktet skulle være ferdigstilt til dette tidspunktet. På grunn av uforutsette hendelser ble denne fristen flyttet til den 13. mai. Dokumentasjonen skulle utarbeides når sprint 7 avsluttes og frem til den 25.mai. Figur 5 - [Fremdriftsplan] Vi startet selve utviklingen 02 februar. Vi opprettet databasemodeller og leverte det til godkjenning ved utløp av sprint 1. De neste sprintene frem til siste sprint skulle bygge på brukerhistorier hentet fra backlog. S i d e 14 30

15 En mer beskrivende fremdriftsplan er lagt til som vedlegg ARBEIDSLOGG Vår arbeidslogg har i hovedsak vært historien over Changesets 8 på Visual Studio Online. Vi har fra starten av vært nøye på at Changesets skulle ha gode beskrivelser. På denne måten er det lett å se hva som er gjort til hvilken tid, og av hvem. 1.5 ARBEIDSFORHOLD Som den sammensveisede gjengen vi etter hvert ble var det lett å arbeide sammen. Vi viste godt på forhånd hva hver enkelt likte å jobbe med best. Selv om alle jobbet med forskjellige deler av modulen nølte vi ikke med å spørre hverandre om hjelp, og vi lærte av hverandre. Arbeidsforholdet var preget av en uformell tone, noe som gjorde prosessen behagelig og til tider morsom. Når vi arbeidet sammen møttes vi i Kredinors lokaler. Dette var en fin måte å arbeide på, da vi fikk en følelse av å gå på jobb når vi skulle arbeide med oppgaven. Lokalene er lyse og fine, og den nære avstanden til kontaktpersonene var dessuten en fordel. I flere tilfeller hvor vi støtte på problemer fikk vi rask hjelp og løsninger. Figur 6 - [Kredinors lokaler i Rådhusgata 27] 8 S i d e 15 30

16 1.6 VERKTØY Da kravspesifikasjonen var ferdigstilt og godkjent av oppdragsgiver, måtte vi bestemme oss for hvilken teknologi som skulle benyttes i utviklingen. Siden Kredinors Arena system blir utviklet med C#/.NET, var det en forutsetning for prosjektoppgaven at Arena Kundereskontro også skulle utvikles med C#/.NET, for det skulle bli lettere å implementere modulen i deres system. Web API, som er laget for teste modulen, brukes av et brukergrensesnitt laget i AngularJS og Bootstrap CSS VISUAL STUDIO 2013 Visual Studio 9 er et utviklingsverktøy når man skal lage programvare i Microsofts rammeverk ASP.NET, og brukes av de ansatte hos Kredinor hver dag. Det ble derfor et naturlig valg for gruppen å bruke Visual Studio under utvikling av produktet. Visual Studio er et veldig utbredt verktøy for programmering i.net og det gav verdifull erfaring å benytte dette i prosjektet VERSJONSKONTROLL Et versjonskontrollsystem er programvare laget for å dele filer i prosjekter, og sørger for at endringene blir «sammensmeltet». Versjonskontrollsystemer er essensielle for prosjekter med flere utviklere. Etter hvert som vi programmerte, ble vi flinkere på bruken av versjonskontroll. I begynnelsen følte det var vrient å samkjøre våre lokale versjoner. Vi rotet med samkjøringen fordi vi glemte å laste ned seneste versjonen før vi lastet vår lokale opp på serveren. Det ble gradvis enklere, ettersom vi ble vant med nedlasting før opplasting TEAM FOUNDATION VERSION CONTROL Team Foundation Version Control 10 (TFVC) er et sentralisert versjonskontroll system. Gruppemedlemmene har typisk en versjon av en spesifikk fil på arbeidsmaskinen, og prosjekthistorien er opprettholdt på serveren S i d e 16 30

17 TFVC er et gratis sky basert verktøy som er bygd inn i Visual Studio Online og som gjør det mulig for brukerne å jobbe på det samme prosjektet på hver sin maskin. Ved hjelp av TFVC har vi oversikt over hvem som har tilgang til hvem som jobber med prosjektet og hvilke endringer som har blitt gjort. Ved commit av endringer (Changesets) skrives en beskrivelse av endringen inn, som igjen kan sees av alle medlemmene under «history» i Visual Studio. Fra «history» vinduet er det mulig å sammenligne endringer, sjekke om det er konflikter og laste ned en eldre versjon av prosjektet C#/.NET C# er et objekt orientert programmeringsspråk som bygger på Java og C++. Vi ble nødt til å benytte dette språket da det var en forutsetning for oppgaven. Vi hadde god erfaring med språket fra faget Webapplikasjoner med C#/.NET fra HiOA og dessuten god erfaring med Java ANGULARJS OG BOOTSTRAP 3 AngularJS 11 er et open source JavaScript-rammeverk, som blir vedlikeholdt av Google og deler av brukermassen i fellesskap. Målet med AngularJS er å endre statiske HTML-sider til å støtte dynamisk endring. Vi ønsket å benytte AngularJS til å lage brukergrensesnittet til WEB-API et, da vi både har tidligere erfaring med bruk av dette rammeverket gjennom kurs på skolen, og vi mener det gir gode muligheter til å lage interaktive websider. Nettsiden til rammeverket lover blant annet god støtte for testing av logikken, enkel data-binding og en fornuftig modell. Vi mener at det kan være svært aktuelt å lære seg AngularJS godt for fremtidige muligheter i arbeidslivet. Bootstrap 12 er et rammeverk for å gjøre det enkelt å tilpasse nettsider til mobil og nettbrett. Det inneholder både JavaScript-, HTML- og CSS-funksjonalitet for å modellere et passende utseende. Selv om tilpasning av Web-API til mobil ikke er nødvendig, brukte vi Bootstrap da dette gjorde designet til nettsiden mer brukervennlig S i d e 17 30

18 1.6.5 DROPBOX Dropbox 13 er en sky basert lagringsenhet, der du kan lagre filer på web. Disse filene kan deles mellom andre. Gruppen opprettet en delt mappe i Dropbox slik at vi kunne legge ut arbeid som alle hadde tilgang til å se FACEBOOK MESSENGER Facebook Messenger er et Instant Message program utviklet av Facebook som gjør at personer kan kommunisere via private meldinger. Dette ble brukt av gruppen for å kommunisere når vi ikke var på samme sted. Det ble også brukt til å dele nyttige lenker til nyttige sider YED GRAPH EDITOR yed Graph Editor 14 er et diagram verktøy, som gruppen brukte flittig til å lage ulike diagrammer, som sekvensdiagram og klassediagram, samt skisser av modulen GOOGLE DOCS Google Docs 15 er et web basert tekst-redigeringsprogram som ble brukt til å skrive rapporter. Programmet gjorde det mulig for gruppemedlemmene å jobbe samtidig på de samme dokumentene. 1.7 IT-FAGLIG FORANKRING AV PROSJEKTET Da planleggingen nærmet seg slutt hadde vi klare retningslinjer å følge, og visste godt hva vi måtte sette oss inn i. Oppgaven innebar bruk av både prinsipper, teknologier og utviklingsmetodikker som var nye for oss, både relatert til utvikling og økonomi. Allerede i første møte med oppdragsgiver ble bokføringsloven nevnt som en viktig del av prosjektet. Vi ble bedt om å sette oss inn de prinsipper denne loven innebærer, og S i d e 18 30

19 vi ble gjort oppmerksomme på at oppgaven skulle løses på en måte som stod i samsvar med loven. Det var også et krav at vi behersket.net programmering, da dette er det rammeverket Kredinor benytter hos seg. Ryddig og selvforklarende kode, bruk av objekt orientert programmering, fornuftig klassedesign og generell programmeringsforståelse var også et krav. Sist, men ikke minst, var utviklingsmetodikken en viktig del av oppgaven. Som beskrevet i kapittel 2. Planlegging og metode, valgte vi å benytte metodikken Scrum. Ettersom vi ikke hadde tidligere erfaring med denne metodikken måtte vi lære oss Scrums viktigste prinsipper, og hvordan de følges. Dette gjorde vi ved å benytte oss av veiledninger på nettet, lese oss frem og ved å avklare prinsipper med veileder fra HiOA. 2 UTVIKLINGSPROSESSEN I dette kapittelet går vi igjennom utviklingsprosessen, der vi tar for oss arbeidsformen, gruppens samarbeidsevne og avgjørelser som ble tatt underveis. Utfordringer og løsninger vil også nevnes. 2.1 BENYTTET METODIKK Gjennom nesten hele prosjektet, sett bort i fra enkelte dager der vi jobbet ekstra for å nå en tidsfrist, la gruppen opp arbeidsdagene etter en semi-tradisjonell modell, med arbeidsdag fra Gruppen møtte enten opp hos Kredinor eller HiOA for å jobbe sammen. I startfasen av prosjektet møttes vi ikke veldig ofte. De første to månedene av prosjektet jobbet vi for det meste hjemmefra. Etter hvert som prosjektet utviklet seg møttes vi ca. 3 dager i uken for å jobbe sammen. De ukene vi hadde en tidsfrist møttes vi 4 dager i uken. På grunn av andre fag, jobb og andre uforutsette hendelser var vi ikke fulltallig hver gang. Vi kommuniserte med gruppemedlemmene som ikke var til stede over Facebook Messenger for å fortelle hva som var gjort, og hva som måtte gjøres. S i d e 19 30

20 2.2 DESIGN OG ARKITEKTUR Etter å ha fullført kravspesifikasjonen til modulen og omfanget til Web-API et analyserte vi all info vi hadde om modulen til da og satte i gang med å planlegge klassebibliotekets arkitektur. Vi måtte beskrive hendelsesforløp og planlegge alle modeller forløpet ville ta i bruk, sette disse i kontekst, og bestemme hvilke klasser som utføre hvilke deler av funksjonaliteten. Dette var en stor, tidskrevende og vanskelig prosess, da den innebar at vi måtte dele opp systemet i så små bolker at vi fikk full oversikt over hva som foregikk hvor. Vi begynte med å lage en grovskisse av systemet hvor vi delte de viktigste stegene i hendelsesforløpet opp til de klassene og metodene vi anså som mest vesentlige. Vi benyttet graf-editoren yed til å lage grovskissen. Skissen er fremvist i figur 1. Skissen var hjelpsom da den ga oss et litt klarere helhetlig inntrykk av hvordan systemet måtte konstrueres. Figur 7 - [Skisse av modulen] S i d e 20 30

21 Vi forsøkte å lage en ryddig arkitektur som stod i samsvar med prinsipper rundt bruk av polymorfi der det var hensiktsmessig, logisk navngivning av klasser og muligheter for videreutvikling/integrasjon. Skissen var nyttig og hjalp oss med neste steg: definisjon av modeller. Vi brukte skissen til å se for oss et standard hendelsesforløp, og skrev ned de ulike objektene klassene ville arbeide med underveis. Vi brukte så hendelsesforløpet, klassene vi hadde til da og de modellene vi så som vesentlige, til å utarbeide et klassediagram som beskrev arkitekturen til kjernefunksjonaliteten (Se figur 8). Figur 8 - [Det første klassediagrammet] Vi bestemte oss for å ta utgangspunkt i dette klassediagrammet først, og heller lage nye diagram for funksjonalitet utover kjernefunksjonaliteten etter at kjernefunksjonaliteten var implementert. Vi så derfor ikke bort ifra at klassediagrammet ville endre seg i takt med utviklingsprosessen. Etter klassediagrammet delte vi all funksjonalitet opp i ulike deler og definerte så disse til individuelle prosjekter. Dette var hensiktsmessig av rent praktiske grunner, ettersom vi kunne bruke resultatet av denne estimeringen direkte ved implementasjonen senere. Vi bestemte at løsningen skulle bestå av fire prosjekter (illustrert ved figur 9): S i d e 21 30

22 ArenaKundereskontro: Selve klassebiblioteket. Prosjektet er selvstendig og har ingen avhengigheter. Web-API: Web-API et. Benytter koden til klassebiblioteket, altså er den avhengig av tilgang til ArenaKundereskontro. ArenaKundereskontro.Tests: Alle enhetstestene. Vi var enige i at enhetstester skulle implementeres, og at disse testene ikke skulle være en del av selve produktet. Testene er avhengige av tilgang funksjonaliteten til ArenaKundereskontro, men befinner seg i sitt eget prosjekt. Test: Test-prosjekt benyttet under utviklingen av produktet. Vi viste at produktet måtte testet kontinuerlig, og i denne klassen ville vi ha en main-metode for å simulere en klient. Prosjektet var derfor avhengig av tilgang til ArenaKundereskontro. Figur 9 - [Lagdeling av prosjektet] Etter at både klassediagram og overordnet lagdeling var fullført gikk vi videre på å planlegge oppbyggingen til klassebiblioteket. Neste steg var derfor å dele klasser inn i ulike lag. Vi så på lagdeling som en helt vesentlig del av planleggingen og klassebiblioteket, da utelatelse av dette ville resultert i kaotisk oppbygging og fullstendig mangel på struktur. Vi la klasser med relatert funksjonalitet i samme kategori. Deretter bestemte vi navnene til namespacene basert på funksjonaliteten og innholdet til kategoriene. Igjennom prosjektets løp hadde vi mange diskusjoner om navngivningen av namespacene, og ved prosessens slutt var utfallet helt ulikt det vi opprinnelig startet med. Det var mange grunner til dette, blant annet klassebibliotekets eksplosive vekst fra start til slutt og vår klarere oppfatning av all funksjonalitet. S i d e 22 30

23 Namespace API Core IO Models Innhold Klasser som kommuniserer med klienten Alle klasser tilknyttet kjernefunksjonalitet Konverterings-klasser for input/output filer Alle objektene I løpet av utviklingsprosessen gjennomgikk både arkitektur, klasse/namespace/metode-navn og kravspesifikasjon flere endringer. Sprintene ble gjennomført i planlagt rekkefølge, men vi innså etter noen uker at klassediagrammet vi hadde måtte utvides for å få inkludere ny funksjonalitet. Vi var innforstått med dette da vi startet utviklingen av klassediagrammet, noe som gjorde det til en kontinuerlig prosess. Funksjonaliteten til klassebiblioteket ble tydeligere etter hvert som implementasjonen av backloggen startet. Vi var klare over hva som skulle gjøres, men det var ikke før vi startet implementasjonen at vi brukte tid på å finne ut av hvordan det skulle gjøres. Disse valgene omhandlet både valg av filformat, oppbygning av klasser og avgjørelser i forbindelse med hendelsesforløpet til enkelte prosesser. Klasser gjennomgikk forandringer både i form av innhold, funksjon og navn. Et stykke inn i prosessen tok vi oss selv i å ha programmert noen klasser med for mye ansvar og funksjonalitet. Disse stykket vi ned til mindre klasser med mer konkrete oppgaver. Namespacene gjennomgikk også store forandringer. Vi så etter hvert at de namespacene vi hadde planlagt ikke på langt nær var tilstrekkelig for å holde løsningen ryddig. Vi brukte derfor mye tid på å bestemme nye, beskrivende namespaces. Denne prosessen skapte den største uenigheten under hele prosessen, da vi var uenige om navngivningen og nytten disse namespacene skulle ha. Etter å ha diskutert i flere dager kom vi frem til en løsning alle var enige i. 2.3 UAVHENGIGET Modulen skulle ha et design som gjorde den uavhengig, som beskrevet i kravspesifikasjonen. Dette innebar at vi måtte ta hensyn til at løsningen skulle være selvstendig, men samtidig lett å ta i bruk av andre system. Dette betyr at det ikke stilles noe annet krav til systemet som skal ta i bruk modulen enn at oppsettet må gjennomgås. S i d e 23 30

24 Konkrete valg vedtatt som følge av dette kravet var blant annet: Klassebiblioteket skal ikke har noen eksterne avhengigheter Klassebiblioteket skal ha et design som gjør det enkelt for et hvilket som helst system å ta det i bruk 2.4 PARALELLITET GUID For å kunne oppnå parallellitet måtte vi ta i bruk globalt unike identifikatorer, også kalt GUID 16. Datatype GUID er en 16byte binær datatype som er generert av en algoritme utviklet av Microsoft. GUID blir benyttet som primærnøkkel i Transaksjonstabellen istedenfor en inkrementell integer. To tråder kunne tildele den samme primærnøkkelen til to forskjellige databaserader ved bruk av inkrementell integer. Dette unngikk vi ved å bruke GUID som primærnøkkel. Når primærnøkkelen i tabellen er globalt unik, spiller det liten rolle hvilken tråd som først skriver til databasen. Ved bruk av GUID som primærnøkkel åpnet det opp muligheten for Async databaseskriving [Kapittel 3.4.2] SYNC VS ASYNC For å møte kravet om effektivitet måtte vi finne en måte å kunne lagre store mengder data på kort tid, uten at det går ut over integriteten til dataene som skal bli lagret. Ved å søke på nettet fant vi ut av at Async 17 metoder var riktig vei å gå. En synkron Tråd vil låse en prosess frem til prosesseringen har fullført, noe som ikke er ideelt for modulen. Ved prosessering av store mengder data, vil vi unngå å låse tråden, slik at data kan bli prosessert samtidig. Asynkron håndtering innebærer (ved korrekt bruk) at hver transaksjon tildeles sin egen tråd i operativsystemet og på denne måten håndteres når CPU en har mulighet til det. Antall tråder som blir kjørt samtidig avhenger av kapasiteten til CPU en. I vår modul vil det bli opprettet et likt antall tråder som det er transaksjoner som skal bli gjennomført S i d e 24 30

25 Asynkron programmering er enkelt å håndtere i.net som følge av at Microsoft så den store etterspørselen som fantes etter enklere håndtering av multithreading. Vi har implementert både asynkron og synkron av to like metoder i vår løsning. Dette for å kunne tilby kunden den løsningen som passer best. Ved å ha to fungerende alternativ står kunden selv fritt til å benytte seg av den funksjonaliteten som er mest hensiktsmessig i gitt kontekst. For at løsningen skal være asynkron/synkron hele veien (hele hendelsesforløpet, og ikke bare et sted) er det implementert asynkrone og synkrone metoder med samme funksjonalitet flere steder i modulen. Sammenlignet med synkron håndtering kan asynkron håndtering vise seg å være svært hensiktsmessig i forhold til effektivitet. Tester i forbindelse med sammenligning av de to metodene kan studeres i Testrapporten. Disse testene viser også at modulen oppnår kravet om effektivitet. Etter hvert som vi kodet fant vi ut at håndtering av feil (Exceptions) ikke ble fanget opp av modulen. Hovedtråden ville ikke fange opp feilene, og kvitteringene ville ikke nå frem til brukeren av systemet. Det viste seg at feilhåndteringen måtte skje inne i tråden som ble opprettet og ikke av hovedtråden. Asynkrone metoder vil kunne prosessere data raskere, men det økte også faren for at feilsituasjoner kunne oppstå. Det var en tidkrevende prosess å få asynkron håndtering av transaksjoner å fungere riktig. 2.5 DEMONSTRASJON FOR KREDINOR En demonstrasjon av produktet utføres for å avgjøre om et produkt oppfyller kundens behov, og stemmer overens med kravspesifikasjonen og annen dokumentasjon. Demonstrasjonen er siste mulighet for en kunde å avvise et utilstrekkelig produkt, før det settes i drift. Demonstrasjonen ble utført uformelt med et møte mellom gruppemedlemmene og Kredinor, der gruppen presenterte modulen for Kredinor. Gruppemedlemmene forklarte hvordan backend fungerte og viste hvordan XML ble mottatt ved å bruke WEB-API et til å laste opp en XML-fil. Kredinor mente at produktet var tilstrekkelig og utfylte de kravene som ble satt i begynnelsen av prosjektet. Kunde mente også at produktet var greit som en betaversjon. Det har i senere tid kommet andre forutsetninger for denne modulen, som har gjort at modulen blir vanskelig å implementere med en gang. Modulen må videreutvikles før den kan driftsettes. S i d e 25 30

26 2.6 SAMARBEID Etterhvert som prosjektet vedvarte, ble vi bedre kjent. Vi lærte hverandres arbeidsvaner, som første til at det ble et enklere og mer effektivt samarbeid utover i prosjektperioden. De største utfordringene vi hadde var å skille arbeidstid og sosial tid. Dette var spesielt vanskelig de dagene deler av gruppen måtte jobbe med et annet fag, men vi likevel valgte å sitte sammen. 3 KRAVSPESIFIKASJONEN OG DENS ROLLE 3.1 BAKGRUNN FOR KRAVSPESIFIKASJONEN Utarbeidelse av kravspesifikasjonen stod som noe av det viktigste som måtte være på plass før programmeringen kunne starte. Vi tok utgangspunkt i oppgaveteksten gitt av Kredinor, og laget et førsteutkast i januar Vi fremla her sentrale deler av funksjonaliteten til det eksisterende systemet, pluss ny ønsket funksjonalitet. Kravene ble presentert som brukerhistorier, hvor vi i tillegg til selve kravet beskrev viktigheten og detaljer om det aktuelle kravet UTARBEIDELSE Utkastet ble utarbeidet og levert i januar 2015 som en del av forprosjektet. Deler av denne kravspesifikasjonen er gjengitt (kun som krav) under: Løsningen skal være uavhengig. Alle transaksjoner skal være sporbare. Alle transaksjoner skal til enhver tid være i balanse. Det skal ikke være lov å slette transaksjoner. Gjeldende lover/forskrifter om bokføringsloven skal følges. Klassebiblioteket skal ha god ytelse. Klassebiblioteket skal utvikles i.net. Etter utarbeidelse av utkastet arrangerte vi et møte med Kredinor hvor vi presenterte kravspesifikasjonen. Sammen gikk vi trinnvis gjennom dokumentet. Oppdragsgiver var enige i de punktene vi hadde definert, men ga også utrykk for at det var mye vi ikke hadde tatt høyde for. Utkastet definerte de viktigste kravene rundt kjernefunksjonaliteten, men ikke om selve utførelsen eller videre funksjonalitet. S i d e 26 30

27 Vi diskuterte så ønsket funksjonalitet og relasjonen slutt-produkt og Kredinor ideelt sett villa ha. Ved møtets slutt hadde vi forlenget kravspesifikasjonen med nye punkter. I tillegg til kravene i førsteutkastet hadde vi nå definert konkrete krav til modulens input/output håndtering og viktig tilleggs funksjonalitet: Modulen skal ta imot transaksjoner tilsendt som fil. Modulen skal kunne håndtere individuelle transaksjoner. Modulen skal dokumentere prosesserte transaksjoners status. Modulen skal gi alle transaksjoner unike Guid-verdier. Alle transaksjoner skal være søkbare i ettertid. Bokførte betalinger skal kunne overlates til et eksternt regnskapssystem. Oppdragsgiver gikk god for denne versjonen, og det var den vi tok utgangspunkt i under resten av prosjektet. Kravspesifikasjon ligger i sin helhet i vedlegget. 3.2 VÅR ERFARING MED KRAVSPESIFIKASJONEN Kravspesifikasjonen har gitt oss generelle retningslinjer for hva som skulle lages, hvordan oppgaven skulle struktureres og hvilke funksjonaliteter som skulle implementeres. Denne informasjonen forenklet planleggingen av prosjektet. Det har også vært betryggende å ha gitte retningslinjer man kunne forholde seg til ENDRINGER AV KRAVSPESIFIKASJONEN Ettersom vi har jobbet smidig under utviklingsprosessen har noen krav forandret seg under prosessen. Noen krav har utgått fordi implementasjonen av kravene var overflødige. Vi kan ta for oss kravet «Ta imot melding om innbetaling mottatt direkte hos arbeidsgiver». Vi så for oss først at vår modul skulle ta imot informasjonen direkte, for så å videresende det til inkassosystemet, men vi snudde heller om på problemstillingen. Inkassosystemet tar imot informasjonen, for så å sende de kontoene det skal posteres mot til vår modul. Selv om dette kravet har utgått, så støtter vår modul funksjonaliteten. Vi trenger for eksempel å ikke motta en hel del informasjon for så å lagre en bit av informasjonen. Vi tar heller imot transaksjoner og posteringer fra systemene rundt, deriblant inkassosystemet. S i d e 27 30

28 3.3 KONKLUSJON Kravspesifikasjonen har spilt en stor rolle for utviklingen av modulen, spesielt for hva som gjaldt omfang av oppgaven. Mesteparten av funksjonaliteten det ble stilt krav til ble innfridd, mens noen av elementene utgikk. S i d e 28 30

29 4 KONKLUSJON I denne delen av dokumentet vil vi komme med egne meninger om forskjellige deler av hovedprosjektet og vår opplevelse av prosjektet, samt hvilke muligheter Kredinor har for videreutvikling av modulen. 4.1 RESULTAT Gruppen er godt fornøyd med resultatet av produktet. Vi satt for det meste i lokalene til Kredinor, der arbeidsmiljøet var veldig aktivt. Selv om vi gjerne skulle ha hatt mer tid til denne utviklingen, så føler vi at vi har utviklet et produkt vi kan være fornøyde med. Det er mange timers arbeid som ligger bak utviklingen av systemet, og vi mener det er skrevet på en slik måte at det er lett å vedlikeholde, utvide eller gjenbruke deler av koden i andre prosjekter. 4.2 LÆRINGSUTBYTTE Vi har blitt utfordret til å sette oss dypere inn i.net rammeverket, noe som har vært interessant og lærerikt både for hobby-basis og for videre karriere. Vi er alle enige i at vi har forbedret vår kompetanse rundt språket betydelig i løpet av prosessen. Vi har også lært hvordan vi skal bruke teknologi i et større prosjekt, og ikke bare simulere problemstillinger, slik studenter vanligvis gjør på HiOA. Vi har også fått erfaring i å jobbe selvstendig, men samtidig evne til å samarbeide i gruppe. For vår personlige utvikling har det vært lærerikt å kunne jobbe med et større prosjekt, der vi har fått en god smakebit på hva som venter oss ute i arbeidslivet. I og med at prosjektet har blitt utviklet for en oppdragsgiver har vi fått følelsen av å jobbe for et firma. Vi ser på dette som en positiv erfaring, og takker igjen både Kredinor og våre veiledere der for muligheten de ga oss. Benyttet metodikk har også gitt stort læringsutbytte. Vi har nå erfaring med hvordan Scrum benyttes i et prosjekt, og vi er godt innforstått med alle prinsipper og retningslinjer metodikken tar i bruk. I og med at denne metodikken daglig tas i bruk i stort omfang i den «virkelige verden» ser vi på det som en stor fordel å kunne bekrefte at vi nå har gjennomført et prosjekt hvor vi har tatt denne metodikken i bruk. Sist, men ikke minst har vi fått erfare hvordan et prosjekt gjennomføres, hele veien fra første møte med oppdragsgiver frem til endelig overlevering av produkt. Denne prosessen er verdifull på veldig mange måter, og vi føler alle at vi har vokst i løpet av de fem månedene prosjektet har pågått. S i d e 29 30

30 4.3 VIDEREUTVIKLING Ved prosjektets slutt brukte vi tid på reflektere rundt videreutvikling av det endelige sluttproduktet. Ved prosjektets start ble klassebiblioteket beskrevet som en selvstendig del av et større system som i fremtiden vil erstatte K90. Som beskrevet i kapitel 2.2 Omfang var det vi som selv bestemte omfanget til prosjektet. Ettersom modulen senere skal implementeres i en større kontekst, måtte vi ta høyde for at implementasjon og videreutvikling av biblioteket skulle være enkelt. Oppdragsgiver kan derfor videreutvikle klassebiblioteket med all ønsket funksjonalitet. Vi satte oss det målet at vi skulle levere et fungerende klassebibliotek med hovedfokus på håndtering av transaksjoner. Sluttproduktet lever opp til de kravene vi satte oss selv. Da vi var ferdige diskuterte vi potensielle ideer til videreutvikling og kom frem til noen punkter: Generering av statistikk. Utvide filtrering og mulighetene for uthenting av data. Utvidelse av datamodellene, det er trolig ønskelig å lagre mer informasjon i modulen enn det som gjøres i dag. 4.4 HVA VILLE BLI GJORT ANNERLEDES? Selv om vi er godt fornøyde med resultatet er det noen ting vi ville gjort annerledes dersom vi fikk sjansen til å starte prosjektet på nytt. Vi ville lagt mer tid i å utforme et detaljert og fullstendig klassediagram. Å lage diagrammer og planlegge hvilken funksjonalitet som passet inn hvor var en utfordring. Vi laget flere diagrammer som tok for seg mindre deler av funksjonaliteten, men som etterhvert viste seg å være feil, f.eks. fordi bokføringsprinsipper ikke var blitt overholdt. Dette førte igjen til at vi måtte omstrukturere deler av prosjektet for å ta høyde for alle krav. Vi er enige i at testdreven utvikling hadde passet prosjektet godt. Ved å jobbe testdrevet kan utviklere endre kode uten at det oppstår problemer. Testene ville gjort oss oppmerksomme på endringer som førte til rar eller annerledes oppførsel. S i d e 30 30