Arena Kundereskontro

Prosessrapport

Prosessrapport

S i d e 2 | 30

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 2015. 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 fag-

terminologi, 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.

Prosessrapport

S i d e 3 | 30

INNHOLD

Forord .......................................................................................................................... 2

1 Planlegging og metode ........................................................................................... 5

1.1 Forløp til prosjektstart ....................................................................................... 5

1.2 Omfang ............................................................................................................ 6

1.3 Arbeidsteknikker og utviklingsmetoder ............................................................. 7

1.3.1 Planlegging av sprinter............................................................................... 8

1.3.2 Arbeidsfordeling ......................................................................................... 9

1.3.3 Scrum ........................................................................................................ 9

1.3.4 Prosjektstyringsverktøy ............................................................................ 11

1.4 Prosjektstyringsdokumenter ........................................................................... 12

1.4.1 Prosjektdagbok ........................................................................................ 12

1.4.2 Møtereferat .............................................................................................. 13

1.4.3 Fremdrift .................................................................................................. 14

1.4.4 Fremdriftsplan .......................................................................................... 14

1.4.5 Arbeidslogg .............................................................................................. 15

1.5 Arbeidsforhold ................................................................................................ 15

1.6 Verktøy .......................................................................................................... 16

1.6.1 Visual Studio 2013 ................................................................................... 16

1.6.2 Versjonskontroll ....................................................................................... 16

1.6.3 C#/.NET ................................................................................................... 17

1.6.4 AngularJS og Bootstrap 3 ........................................................................ 17

1.6.5 Dropbox ................................................................................................... 18

1.6.6 Facebook Messenger .............................................................................. 18

1.6.7 yEd Graph Editor ..................................................................................... 18

Prosessrapport

S i d e 4 | 30

1.6.8 Google Docs ............................................................................................ 18

1.7 IT-faglig forankring av prosjektet .................................................................... 18

2 Utviklingsprosessen ............................................................................................. 19

2.1 Benyttet metodikk ........................................................................................... 19

2.2 Design og Arkitektur ....................................................................................... 20

2.3 Uavhengiget ................................................................................................... 23

2.4 Paralellitet ...................................................................................................... 24

2.4.1 GUID ........................................................................................................ 24

2.4.2 Sync vs Async ......................................................................................... 24

2.5 Demonstrasjon for Kredinor............................................................................ 25

2.6 Samarbeid ...................................................................................................... 26

3 Kravspesifikasjonen og dens rolle ........................................................................ 26

3.1 Bakgrunn for kravspesifikasjonen ................................................................... 26

3.1.1 Utarbeidelse ............................................................................................. 26

3.2 Vår erfaring med kravspesifikasjonen ............................................................. 27

3.2.1 Endringer av kravspesifikasjonen ............................................................. 27

3.3 Konklusjon ..................................................................................................... 28

4 Konklusjon ............................................................................................................ 29

4.1 Resultat .......................................................................................................... 29

4.2 Læringsutbytte ............................................................................................... 29

4.3 Videreutvikling ................................................................................................ 30

4.4 Hva ville bli gjort annerledes?......................................................................... 30

Prosessrapport

S i d e 5 | 30

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

Prosessrapport

S i d e 6 | 30

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 K901. 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 2015.

1 K90 – Kjernesystem i Kredinor som bokfører transaksjoner

Prosessrapport

S i d e 7 | 30

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 til2!

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 http://blog.kjempekjekt.com/2012/02/24/hva-er-smidig-utvikling/

Prosessrapport

S i d e 8 | 30

En anen grunn til at valget falt på denne utviklingsmetodikken var at den var godt

dokumentert3, slik at det var enklere for gruppen, som uerfarne Scrum-utviklere, å

sette seg inn i og følge metodikken.

1.3.1 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 backloggen4 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 Trello5 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.

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: http://scrumreferencecard.com/scrum-reference-card/ 4 Backlog - En prioritert liste med kravspesifikasjonen av produktet presentert som brukerhistorier 5 Trello – Beskrevet i kapittel [2.1.4 Utviklingsverktøy]

Figur 1 - [Skjermbilde av et kort]

Prosessrapport

S i d e 9 | 30

Bruken av de planlagte sprintene beskrives i utviklingsprosessen.

1.3.2 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.

1.3.3 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 10 – 60 minutter, og der presenterte vi hva hver av oss hadde gjort dagen før, hva

Prosessrapport

S i d e 10 | 30

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.

1.3.3.1 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.

1.3.3.2 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.

Prosessrapport

S i d e 11 | 30

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 Trello6 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-backlog7 (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».

6 http://www.trello.com 7 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.

Prosessrapport

S i d e 12 | 30

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.

1.4.1 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.

Prosessrapport

S i d e 13 | 30

Figur 3 - [Referat Mal]

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.

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.

Prosessrapport

S i d e 14 | 30

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.

1.4.4 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.

Prosessrapport

S i d e 15 | 30

Figur 6 - [Kredinors lokaler i Rådhusgata 27]

En mer beskrivende fremdriftsplan er lagt til som vedlegg.

1.4.5 ARBEIDSLOGG

Vår arbeidslogg har i hovedsak vært historien over Changesets8 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.

8 https://msdn.microsoft.com/en-us/library/ms181408.aspx

Prosessrapport

S i d e 16 | 30

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.

1.6.1 VISUAL STUDIO 2013

Visual Studio9 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.

1.6.2 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.

1.6.2.1 TEAM FOUNDATION VERSION CONTROL

Team Foundation Version Control10(TFVC) er et sentralisert versjonskontroll

system. Gruppemedlemmene har typisk en versjon av en spesifikk fil på

arbeidsmaskinen, og prosjekthistorien er opprettholdt på serveren.

9 https://www.visualstudio.com 10 https://www.visualstudio.com/en-us/products/what-is-visual-studio-online-vs.aspx

Prosessrapport

S i d e 17 | 30

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.

1.6.3 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.

1.6.4 ANGULARJS OG BOOTSTRAP 3

AngularJS11 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.

Bootstrap12 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.

11 https://angularjs.org 12 http://www.getbootstrap.com

Prosessrapport

S i d e 18 | 30

1.6.5 DROPBOX

Dropbox13 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.

1.6.6 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.

1.6.7 YED GRAPH EDITOR

yEd Graph Editor14 er et diagram verktøy, som gruppen brukte flittig til å lage ulike

diagrammer, som sekvensdiagram og klassediagram, samt skisser av modulen.

1.6.8 GOOGLE DOCS

Google Docs15 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

13 https://www.dropbox.com 14 http://www.yworks.com/en/products/yfiles/yed/ 15 https://www.google.no/intl/no/docs/about/

Prosessrapport

S i d e 19 | 30

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 10-17. 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.

Prosessrapport

S i d e 20 | 30

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]

Prosessrapport

S i d e 21 | 30

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):

Prosessrapport

S i d e 22 | 30

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.

Prosessrapport

S i d e 23 | 30

Namespace Innhold

API Klasser som kommuniserer med klienten

Core Alle klasser tilknyttet kjernefunksjonalitet

IO Konverterings-klasser for input/output filer

Models 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.

Prosessrapport

S i d e 24 | 30

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

2.4.1 GUID

For å kunne oppnå parallellitet måtte vi ta i bruk globalt unike identifikatorer, også kalt

GUID16. 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].

2.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 Async17 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.

16 https://msdn.microsoft.com/en-us/library/dd354925.aspx 17 https://msdn.microsoft.com/en-us/library/hh191443.aspx

Prosessrapport

S i d e 25 | 30

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.

Prosessrapport

S i d e 26 | 30

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 2015. 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.

3.1.1 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.

Prosessrapport

S i d e 27 | 30

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.

3.2.1 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.

Prosessrapport

S i d e 28 | 30

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.

Prosessrapport

S i d e 29 | 30

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.

Prosessrapport

S i d e 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.