ANALYSEVERKTØY MED MASKINLÆRING

Transkript

1 ANALYSEVERKTØY MED MASKINLÆRING Bachelorprosjekt for Fiskeridirektoratet våren 2017 Høgskolen i Oslo og Akershus ADSE3900/ITPE3900

2 PROSJEKT NR. 26 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Offentlig Telefon: Telefaks: BACHELORPROSJEKT HOVEDPROSJEKTETS TITTEL Analyseverktøy med Maskinlæring Fiskeridirektoratet PROSJEKTDELTAKERE DATO ANTALL SIDER / BILAG 120 INTERN VEILEDER Terje Leirvik Jan André Eikrem Slettebakk Crystal Kim-Phuong Tran s236732@stud.hioa.no s165903@stud.hioa.no s178511@stud.hioa.no Henrik Qvigstad og Heidi Mork OPPDRAGSGIVER Kantega AS KONTAKTPERSON Aiko Yamashita Aiko.yamashita@hioa.no SAMMENDRAG Webapplikasjon som bruker maskinlæring til å produsere en risikovurdering som kan brukes av Fiskeridirektoratets inspektører til å velge ut fartøy for inspeksjoner. 3 STIKKORD Webapplikasjon Maskinlæring Kontinuerlig integrering 1

3 1 Innhold BACHELORPROSJEKT Innledning Forord Presentasjon av gruppen Presentasjon av arbeidsgiver og samarbeidspartner Problemstilling Kravspesifikasjon Kravspesifikasjon Prosessdokumentasjon Forarbeid Teknologivalg Back-end Front end Scrum som metode Kodegjennomgang Testing Fremdriftsplan og milepælsplan Verktøy Utfordringer Produktdokumentasjon Systemarkitektur Back-end Front-end Design og brukeropplevelse Avslutning Erfaringer Hva kunne vært gjort annerledes? Måloppnåelse Videreutvikling Modularitet Konklusjon Vedlegg

4 7.1 Testdokumentasjon Sprintdagbok Prosjektdagbok Brukermanual Publiseringsmanual Dokumentasjon av API Bibliografi

5 2 Innledning 2.1 Forord Denne rapporten dokumenterer gjennomføringen av bachelorprosjekt for gruppe 26 ved Høgskolen i Oslo og Akershus (HiOA), institutt for informasjonsteknologi. Rapporten består av flere individuelle deler skrevet av prosjektgruppen og er satt sammen til en sluttrapport i fellesskap. Vi håper rapporten danner et helhetlig bilde av utviklingsprosessen og gir et detaljert, oversiktlig og sannferdig bilde av prosessen og veien mot det ferdige produktet. Sluttrapporten er åpen og tilgjengelig for alle å lese og vil bli publisert på HiOAs nettsted etter innleveringsfrist. Kildekoden til dette prosjektet er privat og opphavsretten tilhører Kantega A/S. Vi ønsker å rette en stor takk til Kantega A/S ved Hans Ove Ringstad for å ha gitt oss muligheten til å delta på et svært lærerikt og spennende bachelorprosjekt og til Fiskeridirektoratet som var positive og samarbeidsvillige. 2.2 Presentasjon av gruppen Gruppen består av tre studenter Jan André Eikrem Slettebakk, Terje Leirvik og Crystal Kim-Phuong Tran. Vi har gjennom studiene våre samarbeidet på flere prosjekter og oppnådd gode resultater. Derfor var det naturlig at vi inngikk samarbeid om det avsluttende bachelorprosjektet. Vi er alle studenter ved HiOA, institutt for informasjonsteknologi. Jan André og Terje går på anvendt datateknologi, mens Crystal går på informasjonsteknologi. Underveis i studiene har vi valgt å fordype oss i programmering ved å ta valgemner innen fagområder som programmering, operativsystemer, matematikk og algoritmer og datastrukturer. 4

6 2.3 Presentasjon av arbeidsgiver og samarbeidspartner Vår arbeidsgiver, Kantega, er en ansatteid IT-bedrift som har i overkant av 100 medarbeidere, og leverer ifølge seg selv innovative IT-løsninger som innfrir høye krav til brukervennlighet, funksjonalitet, sikkerhet og ytelse til kunder med høye krav til kvalitet og gjennomføringsevne. Figur 1 Utsnitt fra kantega.no med oversikt over noen av Kantegas kunder(trenger ref) Vi kontaktet Kantega i fjor høst og forhørte oss om muligheten for å innlede et samarbeid om et bachelorprosjekt. Kantega responderte umiddelbart positivt og var generøs nok til å lage en spennende oppgave for oss i samarbeid med en av deres kunder Fiskeridirektoratet. 5

7 Kantega hadde i lengre tid ønsket å utforske maskinlæring for å gjøre seg litt erfaringer og se på mulig forretningsmuligheter innen fagområdet. Timingen for vår forespørsel var i så måte perfekt. Fiskeridirektoratet er en norsk, statlig etat som har ansvar for fiskeri- og havbruksforvaltning og har som oppgave å fremme lønnsom og verdiskapende næringsaktivitet gjennom bærekraftig og brukerrettet forvaltning av marine ressurser og marint miljø og de fører blant annet derfor tilsyn og kontroll med fiskefartøy for å se at regelverket etterleves. Datavitenskap generelt og maskinlæring spesielt er krevende fagområder som krever særlig kompetanse som ligger utenfor vårt studieområde. Derfor har vi fått god hjelp av våre veiledere i prosjektet vårt som har vært uvurderlig betydning. Veiledere Vår interne veileder er Aiko Yamashita, førsteamanuensis ved Høgskolen i Oslo og Akershus. Produkteier/Sponsor hos Kantega er Hans Ove Ringstad. Våre interne veiledere er Henrik Qvigstad og Heidi Mork, begge ansatte hos Kantega. Vi hadde fast avtalte møter med vår interne veileder, Aiko Yamashita. Det ble totalt gjennomført fire møter og vi hadde hyppig kontakt per e-post. Arbeidssted Vi har hatt faste kontorplasser hos Kantega i Kirkegata 5, Oslo. Det å ha en fast arbeidsplass med nærhet til veiledere og andre høyt kompetente Kantega ansatte har vært av uvurderlig betydning for sluttresultatet til dette prosjektet. 6

8 2.4 Problemstilling Den innledningsvise problemstillingen for prosjektet ble presentert for oss per e-post fra Ringstad i Kantega på tampen av fjoråret. Kan vi ved hjelp av maskinlæring lage et analyseverktøy som inspektører i Fiskeridirektoratet kan bruke for å planlegge mer effektivt hvor de bør gå på tilsyn? o Datainnsamling og utforsking; Innhente domenekunnskap og finne tilgjengelige data som vi tror vi kan nyttiggjøre oss av. o Implementere og teste ut datamodeller og algoritmer. o Utarbeide hypoteser og mål for analyse og maskinlæring. Et krav vil være at man bruker minst én maskinlæringsalgoritme. Som det fremgår av denne rapporten skal den opprinnelige problemstillingen endre seg underveis i rapporten. Rammebetingelser og kontekst I denne delen presenterer vi konteksten og kravene knyttet til prosjektet for å kunne gi et klart overblikk over hvilke utfordringer som er knyttet til prosjektet og dets problemstilling. Det overordnede målet har vært å lage et maskinlæringsverktøy som inspektørene hos Fiskeridirektoratet kan bruke til å si noe om hvor de bør utføre tilsyn. Tre delmål ble definert som nødvendige for å nå hovedmålet: gjennomgang og bearbeiding av tilgjengelig data, utvikling av en maskinlæringsalgoritme, og utviklingen av en webapplikasjon der brukere kan kommunisere med maskinlæringsalgoritmen. Maskinlæringsalgoritmen er en risikovurderingsalgoritme der risiko defineres innenfor det aktuelle domenet som «Sannsynlighet for og konsekvens av at det skjer brudd på regelverket.» og risikovurdering defineres som «Systematisk fremgangsmåte for å beskrive, beregne, prioritere og håndtere 7

9 risiko» (Kantega, 2017). De nøyaktige spesifikasjonene har vært noe flytende gjennom store deler av prosjektperioden. Omfanget på oppgaven har gått gjennom revisjoner og endringer som ble vurdert som nødvendige for å kunne ha en realistisk plan med tanke på de tilgjengelige ressursene i form av tid og data som kunne lede mot målet; et sluttprodukt som var tilfredsstillende for alle parter. Dette har vi hatt en åpen dialog med Fiskeridirektoratet og Kantega om gjennom hele prosjektperioden og alle parter har vært innforstått med det sannsynligheten var stor for at det måtte bli endringer for å kompensere for manglende data eller tid. Per i dag har inspektørene stor frihet til å selv velge ut fartøy til inspeksjon. Dette gjør faktorer som den individuelle inspektørens erfaring og kjennskap til fangstmiljøene innenfor han eller hennes distrikt veldige fremtredende. En internt utviklet risikovurdering eksisterer også og er i begrenset bruk. Denne vurdering gjøres manuelt på en enkelt saksbasis. På grunn av mangel på data som den eksisterende risikovurderingen trenger for å generaliseres og automatiseres valgte vi å ikke bygge videre på denne men heller utvikle en egen vurdering. Denne delen, bearbeiding av dataen og utviklingen av maskinlæringsmodellen som gjør risikovurderingen, bestemte vi oss, etter råd fra veileder, om å ikke inkludere i selve omfanget på oppgaven. Vi har arbeidet med data, skriving av noen enkle Python script for automatisk datavasking, og vært med i utviklingen av maskinlæringsmodellen, men hovedansvaret for dette har våre to veiledere fra Kantega hatt. Fokusert vårt var på å utvikle webapplikasjonen som skal huse maskinlæringsmodellen og integreringen av denne. Den skal i hovedsak brukes av Fiskeridirektoratets inspektører i feltet og funksjonaliteten måtte designes deretter. Det betyr at brukergrensesnittet må være så forståelig som mulig selv for personer uten dyp kjennskap til domenet og med varierende grad av tekniske kunnskaper. Veien til målet, en risikovurdering av og informasjon om utvalgte fartøy, må være kort, og illustreres tydelig. I tillegg må det være skalerbart med mulighet for å legge til nye fartøy og annen type data siden behovet for dette vil oppstå. 8

10 Mål Akkurat som man har spesifikke funksjonelle og ikke funksjonelle krav til et produkt som man senere kan bruke til å forme prosessen og senere evaluere resultatet ønsket vi å sette oss noen mål i starten av prosjektet. Spesifikt innen to kategorier: resultat (i form av produktet) og læring (hva vi har lært av prosessen). Formålet med disse målene var å ha lage noe vi kunne bruke som en kjerne for refleksjon mot slutten av prosjektet. Disse målene satte vi oss før vi startet å arbeide på prosjektet og er følgelig formulert i ganske generiske termer. Resultatmål Overordnet er målet vårt å lage et produkt som alle interessentene (vi som gruppe, Kantega som arbeidsgiver, Fiskeridirektoratet som kunde og inspektører fra Fiskeridirektoratet som brukere) vil være fornøyde med. Våre resultatmål er som følger: Vi ønsker å lage en maskinlæringsalgoritme som kan brukes av Fiskeridirektoratets inspektører til å velge ut objekter som de burde inspisere. Vi ønsker å lage en god webapplikasjon som oppfyller så mange av brukskravene til Fiskeridirektoratet som mulig. Vi ønsker å gjøre applikasjonen lett å arbeide videre på, og integrerer, der det måtte være behov for det. Vi ønsker å produsere god dokumentasjon og testing av applikasjonen. Vi ønsker å produsere en god rapport av prosjektperioden vår. Læringsmål Vi arbeider på Kantegas kontorer, vegg i vegg med et team som arbeider på et annet prosjekt for Fiskeridirektoratet og har tilgang til to veiledere med lang erfaring. Med andre ord har vi tilgang til en stor mengde kompetanse, og vi arbeider i en setting som er 9

11 forholdsvis den vi vil møte i arbeidslivet. Et bachelorprosjekt som dette er en ypperlig anledning for oss som studenter å lære mer om hvordan det er å jobbe på et prosjekt for en kunde i en profesjonell setting. For de fleste studenter, oss inkludert, vil dette være første gang vi arbeider på et prosjekt som ikke er for skolen eller en hobby. Våre læringsmål er som følger: Vi ønsker å lære mer om teknologi spektrumet som eksisterer rett og slett få en bedre oversikt over hvilke mulige teknologier som finnes. Slik at vi har et større verktøysskrin å velge fra når vi leter etter den riktige teknologien for en spesifikk oppgave. Vi ønsker å få mer erfaring med godt ansette teknologier som vi kan komme til å bruke i arbeidslivet. Vi ønsket å lære hvordan man jobber med tidsrelevante konsepter som Big Data og maskinlæring. Vi ønsker å lære mer om hvordan det er å planlegge og gjennomføre et prosjekt av denne størrelsen. Spesielt tidsestimering i denne typen prosjekt er noe vi tror vil være verdifull informasjon å ta med seg videre. Vi ønsker å lære hvordan det er å arbeide med et prosjekt i en mer profesjonell setting innenfor paradigmer som er mye brukt i It-konsulentbransjen som DevOps og smidigutvikling. Vi ønsker å lære mer om hvordan man på en best mulig måte dokumenterer prosesser og produkter. Use Case / Scope Her presenteres de viktigste brukstilfellene med et use case diagram og et sekvensdiagram. For detaljert informasjon henvises det til kravspesifikasjon (Punkt 3.2). 10

12 Figur 2 Use Case Tekstlig beskrivelse for sekvensdiagram Navn: Velg objekter for risikovurdering Aktør: Inspektør Prebetingelse: Ingen Postbetingelse: Risikoverdi blir vist for det valgte fartøyet. Hovedflyt: 1: Inspektør velger fartøy eller mottak i webapplikasjonens. 2: Klientsiden sender en forespørsel til back-end med de valgte objektene. 3: Java Spring Boot kaller på kalkulert risikoverdi som ligger i Scala for det valgte fartøyet. 3: De valgte objektene blir sendt til maskinlæringsmodulen for risikokalkulering i Scala 4: Scala returnerer så den kalkulerte risikoverdien (rådata) tilbake til Java Spring Boot. 5: Java Spring Boot sender risikoverdien videre til grensesnittet. 6: Applikasjonen presenterer de valgte objektene med en kalkulert risiko og objektets detaljer. 11

13 Unntak: 1a: Inspektør finner ikke fartøy eller mottak i webapplikasjonen. 2a: Får ikke kontakt med back-end. 2b: Ukjent objekt og risiko kan ikke kalkuleres. Figur 3 Sekvensdiagram 12

14 3 Kravspesifikasjon 3.1 Kravspesifikasjon Kravspesifikasjonen til et system beskriver hva det spesifikke systemet skal kunne gjøre, tjenestene det tilbyr og begrensningene det har (Sommerville, 2014, s. 91). Her vil vi spesifisere disse kravene, både de funksjonelle kravene - definert som tjenester systemet skal tilby - og ikke-funksjonelle kravene - definert som begrensninger satt på systemet i form av for eksempel hvor lang tid oppgaver skal ta, hvor pålitelig det skal være og lagringskapasitet (Sommerville, 2014, ss ). Funksjonelle krav I tråd med vår bruk av en smidig utviklingsprosess har vi dokumentert spesifikasjonene gjennom brukerhistorier som vi har tildelt en prioritering (Sommerville, 2014, s. 99). Til organiseringen av brukerhistoriene har vi brukt Jira (se kapitel X). De funksjonelle kravene ble utformet i samarbeid med representanter fra Kantega og Fiskeridirektoratet. Videre ble de delt inn i to grupper: minimumskrav og ønsket funksjonalitet. Det var et krav at brukerhistoriene i gruppen minimumskrav ble ferdigstilte og de ble derfor tildelt kritisk prioritet. Brukerhistoriene i ønsket funksjonalitet gruppen var det derimot ikke et krav at vi ble ferdige med. Disse ble tildelt prioritet som viktig, lite viktig og triviell, og tok presedens basert på denne rangeringen gitt at det var tid til overs etter at den kritiske funksjonaliteten var implementert. Under følger en liste over de kritiske funksjonelle kravene, en fullstendig liste over de mindre viktige kravene er tilgjengelige i seksjon X av rapporten. Nr. Brukerhistorie Prioritet 1 Som inspektør har jeg behov for å kunne søke etter fartøy basert på forskjellige kriterier, som for eksempel call sign, godkjenningsnummer, navn og region, og lage en liste av skipene jeg vil se nærmere på. Kritisk 13

15 Som inspektør ønsker jeg å kunne trykke på en knapp som 2 tar meg videre til en side der risikovurderingen for fartøyene jeg har valgt vises. Som inspektør ønsker jeg at risikovurderingen oppdater 3 seg og gir meg den nyeste vurderingen tilgjengelig når jeg trykker på knappen som tar meg til siden med risikovurderingen. Som inspektør ønsker jeg at størrelsen på skipene (hvor 4 mange tonn det rommer) skal illustreres på en tydelig måte slik at jeg kan ta dette med i vurderingen av risiko. 5 Som inspektør ønsker jeg å kunne filtrere ut fartøy som ikke legger til kai i min region Som inspektør ønsker jeg å kunne trykke på et fartøy jeg 6 har valgt og få opp et view som viser tidligere brudd begått det aktuelle fartøyet. Som inspektør har jeg behov for å kunne søke etter 7 fiskemottak basert på forskjellige kriterier, som for eksempel godkjenningsnummer, bedriftsnavn og region, og lage en liste av mottakene jeg vil se nærmere på. 8 Som inspektør ønsker jeg et visuelt hjelpemiddel som illustrer om søkeresultatet mitt er et fartøy eller et mottak. Som inspektør ønsker jeg å kunne trykke på en knapp som 9 viser meg tidligere risikovurderinger for fartøyene jeg har valgt. Som inspektør ønsker jeg å se et kart der posisjonen til 10 fartøyene jeg har valgt vises. Kritisk Kritisk Kritisk Viktig Viktig Lite viktig Trivielt Lite viktig Trivielt 14

16 Brukerhistorier som ikke ble implementert Fra starten av viste de involverte partene at dette var et stort og komplisert prosjekt så muligheten for at ikke alle brukerhistoriene kunne implementeres var alltid til stedet. Dette problemet manifesterte seg og vi måtte kutte noen av brukerhistoriene. Spesifikt kuttet vi nummer 5, 9 og 10. Nummer 5 var problematisk siden denne brukerhistorien var prioritert som viktig og følgelig var det et sterkt ønske fra Fiskeridirektoratet om å få denne funksjonaliteten implementert. De to andre var «lite viktig» og «trivielt» og derfor mindre problematiske å kutte. Følgende lå til grunne for at vi ikke fikk implementert disse brukerhistoriene: Nummer 5: Dette var et spørsmål om tilgjengelige data. Vi hadde rett og slett ikke tilgang på den nødvendige dataen for å implementere denne funksjonaliteten. I utgangspunktet var det en god mulighet for at vi ville få den nødvendige dataen, men etter hvert viste det seg å ikke være mulig. Nummer 9: Dette var en brukerhistorie vi etter hvert innså ville gi liten verdi til Fiskeridirektoratet siden vurderingen i et vakuum ikke sier stort. Faktorene, og forholdet dem imellom, som spiller inn på vurderingen måtte i tilfellet være synlige for brukeren og det er en ganske krevende oppgave som vi ikke ville bruke ressurser på når den hadde prioritet som «lite viktig». Nummer 10: Dette var en brukerhistorie som i utgangspunktet hadde lav prioritet og på grunn av tidsmangel ble den kuttet. En klar prioritering av funksjonalitet gjorde det lettere å gjøre vurdering på når noe burde kuttes og hva som i tilfellet skulle kuttes. Ikke-funksjonelle krav De ikke-funksjonelle kravene ble utformet i samarbeid med Kantega og Fiskeridirektoratet. Spesielt ble det lagt vekk på fart, skalerbarhet og mulighet for fremtidig integrering med andre prosjekter. Under følger en liste av de ikke-funksjonelle kravene. 15

17 Nr. Krav Beskrivelse Maskinlæringsmodellen må gjøre ferdig sine 1 Fart utregninger innen en rimelig tid (dette er en tung prosess som krever litt tid men ikke mer enn 30 sekunder ved valg av under 20 fartøy). 2 Skalering Det skal være mulig å bygge videre på webapplikasjonen uten å måtte gjøre drastiske endringer i koden. 3 Integrering Webapplikasjonen skal utvikles på en slik måte at det er mulig å integrere den i Kantegas andre prosjekter. 4 Robusthet Webapplikasjonen skal være i stand til å håndtere feil. 5 Tilgjengelighet Webapplikasjonen skal være tilgjengelig for brukere gitt at de har en internettilkobling. 16

18 4 Prosessdokumentasjon 4.1 Forarbeid Risikomatrise Hva kan gå galt? Sannsynlighet Konsekvens Forebygging/løsning Sykdom Høy Middels Bedrift nedprioriterer oss Lav Høy eller trekker seg Gruppekonflikter Høy Middels Den sykemeldte må gi beskjed tidlig og bør så langt som det lar seg gjøre ta inn igjen tapt arbeid, eller så må noen overta arbeidet hvis sykdommen vedvarer en lang periode. Hvis bedriften nedprioriterer oss må vi prøve å ha møte med dem og snakke ting ut sammen. Hvis bedriften velger å trekke seg under prosessen må vi ta hensyn til kontrakten og de kravene som er satt opp der. Hvis en av oss har et problem med måten noe blir gjort vil vi ta det opp med en gang. Medlemmer skal opprettholde en god tone og løse problemet sammen. 17

19 Manglende engasjement Høy Middels Tekniske Lav Middels problemer Tap av data Lav Høy Kort tidsramme Lav Høy For komplisert prosjekt Middels Middels Mangel på engasjement kan skyldes lite interesse for den tildelte oppgaven. Bør kanskje fordele oppgavene på nytt etter områder medlemmene yter best. Ta jevnlig backup i tilfelle datamaskinen kortslutter, eventuelt finne en annen teknisk løsning. Ta jevnlig backup på dataene. Alle medlemmer i gruppa har en versjon hver. Tidsplanen bør vurderes i forhold til arbeidsmengden og ressurser som er tilgjengelige. Kjøre sprintplanlegging. Hvis arbeidsmengden blir for stor eller at man ikke rekker en frist må man si fra tidlig. Det er vanskelig å estimere hvor komplisert prosjektet blir, og da må det eventuelt gjøres justeringer underveis i prosessen. Noen teknologier er nytt for medlemmene, trenger derfor tid til å innlære anvendelsen og kunnskapen om disse. 18

20 4.2 Teknologivalg I innledningen til dette prosjektet ønsket vi å være så teknologinøytrale som mulige, men siden HiOA underviser programmering hovedsakelig i Java var det naturlig at vi ønsket å ta i bruk Java med Spring rammeverket på back-end. Vi ønsket så langt det lot seg gjøre å bruke åpen-kildekode verktøy i prosjektet. Valg av programmeringsspråk og teknologier til prosjektet kan sies å være av avgjørende betydning for utfallet av prosjektet (Hughes & Cotterell, 2009). I vårt tilfelle, hvor vi skulle lage en responsiv webapplikasjon, var det naturligvis et begrenset utvalg som var aktuelle. Kantega hadde på forhånd valgt ut en teknologi-stack som de ønsket at vi skulle bruke i vårt prosjekt. Alle programmeringsspråk har en rekke regler og egenskaper som gjør det mer eller mindre passende for en gitt oppgave. Derfor er det viktig å gjøre grundige undersøkelser før man velger et programmeringsspråk for et prosjekt. 4.3 Back-end Her vil vi snakke litt om teknologiene vi valgte å bruke i utviklingen av back end hvorfor de ble valgt og hvordan de virker. Der det er naturlig vil vi også gå litt nærmere innpå hvilke teknologier vi vurderte men til slutt valgte bort og hvorfor dette ble gjort. Teknologiene vi endte opp med å bruke forklares i detalj under egne overskrifter. For back-end ble rammeverket Spring Boot anbefalt på bakgrunn av følgende argumenter: Kantega arbeider på et annet prosjekt for Fiskeridirektoratet som er laget i Spring Boot og de ønsket å gjøre det så lettvint som mulig å integrere vårt prosjekt i deres hvis dette skulle vise seg å være fordelaktig. Kantega som organisasjon er godt kjent med Spring Boot og har følgelig erfarne programmerere som kan dette rammeverket som kan konsulteres. 19

21 Kantega ønsket å gi oss en teknologistabel som var utfordrende, spennende og ikke minst relevant i forhold til hva som er i bruk i konsulentbransjen om dagen. Etter å ha undersøkt alternativer som Apache Struts 2, Spring MVC og Play Framework kom vi frem til at Spring Boot er en sterk kandidat på egne meritter og når vi også tar Kantegas argumenter i betraktning mener vi at dette er riktig verktøy for jobben. Når det kommer til auksiliære teknologier som IDE, verktøy for bygging og integrering av maskinlæringsmodellen stod vi mer fritt til å utforske alternativene. Valg av IDE brukte vi minst tid på siden, selv om programmeringsmiljøet er viktig, vi allerede hadde mange nye teknologier å lære oss og dette valget var det som hadde minst påvirkning på sluttproduktet. Vi var alle godt kjente, og fornøyde, med IntelliJ IDEA. Når det kommer til byggeverktøy snevret vi feltet ned til Gradle og Maven. Gradle er skriptbasert og derfor veldig lett å skreddersy, men dette betyr også at det er vanskeligere å forstå. I tillegg må prosjektet kjøres for å kunne få informasjon om det. Maven på sin side kommer med egne utfordringer (som diskuteres under egen overskrift), men alt i alt vurderte vi det som det beste alternativet. Apache Spark hadde få reelle konkurrenter når det kommer til integreringen av maskinlæringen, og sammen med veilederne våre fra Kantega, som har en langt mer kunnskap om maskinlæring og teknologiene rundt det enn vi har, bestemte vi oss for å gå for Spark. Apache Spark Apache Spark er et rammeverk for prosesseringen av store mengder data (Zaharia, et al., 2016). Prosesseringen skjer i minnet og er flere ganger raskere enn det tradisjonelle dataprosesseringsverktøyet Hadoop. Spark har unike egenskaper innen områder som maskinlærings, prosessering av en datastrøm, grafisk utregning og interaktiv analysering. For å kunne ta disse funksjonalitetene i bruk er det ikke nødvendig å lage nye kalkuleringsklynger hvis man har en eksisterende Hadoop løsning, Spark kan legges til på toppen av den eksisterende løsningen (Zaharia, et al., 2016). 20

22 Spark kan brukes sammen med SQL, noe som betyr at eksisterende datakilder kan brukes i kalkulering. Rammeverket er basert på Scala men støtter også Java og Python og, ifølge Wilder-James, er det noe utviklere synes er lett å bruke (Zaharia, et al., 2016). Hurtig, lett å bruke, godt egnet til maskinlæring med gode bibliotek til dette formålet, og støtte for flere språk - Apache Spark fremstår som et godt valg for et maskinlæringsprosjekt (Zaharia, et al., 2016) (Apache Spark, Udatert). Spring Boot Spring rammeverket beskrives på deres nettsider som en omfattende programmerings og konfigureringsmodell for moderne Java baserte applikasjoner (Spring, 2017). Noen av egenskapene som gjør Spring til et populært rammeverk er: «Dependency Injection» som motiverer utviklere til å skrive testbar kode. Enkle og kraftige database transaksjons styring. Forenkling av integreringen med andre Java rammeverk som JPA/Hibernate ORM, Struts/JSF web rammeverk. Et oppdatert Web MVC rammeverk til bygging av webapplikasjoner Videre tilbyr Spring rammeverket fleksible konfigureringsmuligheter av såkalte «beans» ved for eksempel XML, annoteringer, og JavaConfig. Et potensielt problem med Spring rammeverket er at konfigureringen av alle de forskjellige egenskapene er noe komplisert (Reddy Katamreddy, 2016). Spring Boot er en enkel måte å utvikle produksjonsklare Spring applikasjoner som kan kjøres rett ut fra boksen (Spring, 2017). Spring Boot automatiserer store deler av konfigureringen men gir utviklerne mulighet til å overstyre disse standardene hvis det skulle være ønskelig. En ferdig konfigurert Tomcat server følger blant annet med Spring Boot. Dette betyr at alt som trengs for å kunne kjøre applikasjonen på en Tomcat server er annotasjon over klassen med hoved metoden. Alternativt kan denne 21

23 innstillingen overstyres hvis man foretrekker for eksempel Jetty i stedet (Katamreddy, Java Zone, 2016). Målene til Spring-boot er å være: Radikalt raskere og tilgjengelig startopplevelse for Spring utvikling. «Påståelig» angående konfigurasjoner ut av boksen samtidig som det hurtig trer til side når kravene begynner å vike fra standard verdiene. En leverandør av ikke-funksjonelle egenskaper som er vanlige i større prosjekt (for eksempel innebygget servere, sikkerhet med mer). (Humphrey, 2013) Apache Maven Apache Maven er et bygge verktøy for Java prosjekter. Verktøyet ble laget av utviklere som ville definere en standard for hvordan man bygger prosjekter, en klar definisjon av hvilke avhengigheter som er inkludert i et prosjekt, en enkel måte å publisere prosjektinformasjon på og en måte å dele JAR-filer over flere prosjekter. Alle Maven prosjekter bruker en Project Object Model (POM), til å bygge. Det vil si at når en utvikler har gjort seg kjent med POM og byggeprosessen vet han automatisk hvordan alle Maven prosjekt bygges. Denne POM-filen er en beleilig kilde til prosjekt informasjon som for eksempel hvilke avhengigheter som er inkludert (Apache Maven Project, Udatert). Konfigureringsfilen POM er kjernen i Maven og det er her prosjektets avhengigheter deklareres. Maven tar automatisk alle de nødvendige stegene for å inkludere disse avhengighetene i prosjektet. Det vet hvor tredjeparts biblioteker og deres avhengigheter kan lastes ned fra. Omfanget til en avhengighet kan også deklareres i POM filen. For eksempel kan avhengigheter som bare brukes til testing deklareres som en del av dette spesifikke omfanget. Maven vet at testingen må gjøres etter at koden er kompilert og tar 22

24 ikke med kode og avhengigheter som brukes i dette omfanget i pakkingen av applikasjonen (Attard, 2014). Figur 4 Maven POM-fil med Spring-boot og sparkml avhengighet. Figur 5 Maven POM-fil der slf4j-log4j12 avhengigheten som følger med spark-core JUnit JUnit er et rammeverk som brukes av utviklere til å implementere enhetstester i Java. Rammeverket tilbyr funksjonalitet forskjellig funksjonalitet som fixtures og testsuite. Fixtures er å gi objekter en sett tilstand som kan brukes som grunnlag for testing. Slik sikrer man at testmiljøet er det samme hver gang testen kjøres resultatet kan gjenskapes. Testsuite pakker flere enhetstester sammen og kjører dem sammen. JUnit har klasser som Assert og TestResult. Assert inneholder metoder som bekrefter eller avkrefter at et resultat 23

25 er det man forventer, mens RestResult inneholder metoder som samler resultatet fra kjøringen av testene (JUnit, 2017) (Wick, Stevenson, & Wagner, 2005). Jackson Jackson er et API som tilbyr dataprosesseringsverktøy for språk på JVM-plattformen. Den støtter en rekke datastrukturer, men er mest kjent for en god JSON tolker og generator. Jackson tilbyr en mengde funksjonalitet for å lese og manipulere JSON-datastrukturer og konvertere disse til en rekke andre datastrukturer. En annen viktig egenskap ved Jackson er gode databindingsevner som gjør at man kan serialisere et Java objekt til JSON-format og deserialisere JSON-strenger til et Java objekt. (Jackson Project, 2017) (Shah, 2016) Jenkins og kontinuerlig integrering Kontinuerlig integrering er en design praksis der utviklere kontinuerlig integrerer kode inn i et felles oppbevaringssted. Etter hvert som koden integreres verifiseres og bygges den automatisk slik at problemer kan oppdages underveis. Kontinuerlig integrasjon bygger på dette prinsippet; jo lenger det går før kode integreres, testes og bygges jo lenger går det før feil identifiseres og jo vanskeligere blir det å rette feilene (Vasilescu, Yu, Wang, Devanbu, & Filkov, 2015). Jenkins er et verktøy som hjelper med å styrede utvikler siden av DevOps. Det kan brukes til alt fra kildekode styring til levering av kode til produksjon. Jenkins er en kontinuerlig levering og kontinuerlig integreringsløsning som lar utviklere automatisere disse prosessene (Vasilescu, Yu, Wang, Devanbu, & Filkov, 2015) (Knorr, 2016). Jenkins kan konfigureres til å se etter kodeendringer på steder som SVN og Git, automatisk bygge prosjektet ved hjelp av verktøy som Ant eller Maven, teste den ferdigbygde koden og gjennomføre forhåndsbestemte handlinger basert på utfallet av testene (Vasilescu, Yu, Wang, Devanbu, & Filkov, 2015). Ansible og kontinuerlig leveranse 24

26 Kontinuerlig leveranse er tett knyttet opp mot kontinuerlig integrasjon og referer til å automatisk sette ferdigbygget kode som passerer testene som er laget for den ut i produksjon (Thoughtworks, udatert). Ansible er en enkel automatiseringsmotor som automatiserer blant annet leveranse av ferdigbygget kode til produksjon. Til å beskrive hvordan leveringen skal foregå brukes en enkel YAML-fil kalt Ansible Playbook. Database Vi startet prosjektet med å designe og implementere en permanent MySQL database. En permanent database som overlever etter systemet som opprettet den har stoppet å kjøre var dessverre ikke godt egnet for våre formål (Pfeil, 2010). Nye data ble tilgjengelig fortløpende, hvilke data som var relevante var i endring og nye metadatamerkelapper ble laget gjennom store deler av prosjektperioden. I tillegg tok de tid å merke de forskjellige dataene siden de krevde en god forståelse av domenet noe som var vanskelig på grunn av dårlige metadata. Det ble for krevende å måtte manuelt slette den eksisterende databasen og erstatte den med en ny som reflekterte de siste endringene. Dette økte også sannsynligheten for en feil kunne oppstå. Løsningen vår var å gå over til en H2 in-memory database. En in-memory database der databasen ikke er permanent, den slettes når systemet som opprettet den stopper å kjøre, passet bedre (Pfeil, 2010). Automatisk sletting av databasen når systemet ble tatt ned for å gjøre endringer var en stor forbedring. Databasen populeres fra JSON og CSV filer ved oppstart gjennom parsere. En H2 database går også godt sammen med Spring Boot som, hvis det finner en in-memory database som H2 i klassekatalogen(class path), automatisk vil lage en in-memory datakilde og registrere markerte entiteter som tabeller (Katamreddy, Java Zone, 2016). 25

27 H2 H2 er en SQL relasjonsdatabase skrevet i Java som kan kjøres i tre forskjellige tilstander: embedded der den bare er tilgjengelig på den aktuelle maskinen, på en server eller som en kombinasjon av de to. I alle de forskjellige tilstandene kan man velge om man vil at dataene bare skal lagres i minnet, og dermed forsvinne når databasen slås av, eller om man ønsker å lagre de slik at de ikke forsvinner selv om databasen slåes av. Databasen er laget for å ha et lite digitalt fotspor med en jar fil størrelse på rundt 1,5 MB, og for høy ytelse (H2, Udatert). Maskinlæring og Big Data Selve maskinlæringsdelen var ikke inkludert i det endelig definerte omfanget på oppgaven vår, men det ble ikke bestemt før vi allerede var kommet et godt stykke med prosjektet. En god del av tiden vår gikk dermed med til å sette oss inn i de relevante teknologiene. I tillegg var det nødvendig med en forståelse for dataene og selve domenet for å utvikle webapplikasjonen, og en viss forståelse av selve maskinlæringsmodell for å kunne integrere den i prosjektet. Vi har derfor valgt å snakke litt om teknologiene vi satte oss inn i forbindelse med maskinlæring. Når det kommer til selve valget av hvilke teknologier som skulle brukes i maskinlæring veide veiledernes meninger tungt her siden dette var et felt som var helt ukjente for oss. Python ble foreslått og valgt til å behandle dataene, mens Scala ble valgt som språket selve maskinlæringsmodellen skulle skrives i. Apache Tomcat Apache Tomcat er en Java servlet kontainer som styrer og kaller på forskjellige «servlets» for brukere (Shachor, 2017). Tomcat kommer med Spring Boot som standard. Hvis man ønsker å bruke en annen servlet kontainer må dette manuelt overstyres i prosjektets konfigurasjoner (Apache Tomcat, 2017). 26

28 Scala Scala er et programmeringsspråk som integrer både objekt orienterte og funksjonelle programmerings konsepter. Scala er et objekt orientert språk i den forstand at, konseptuelt, hver verdi er et objekt og hver operasjon er et metodekall. Språket støtter avanserte komponenter og arkitektur gjennom klasser og trekk. Funksjonelt tilbyr Scala bibliotek med blant annet effektive immutable datastrukturer (Odersky, WHAT IS SCALA?, Udatert). Scala har en relativt liten markedsandel sammenlignet med andre maskinlæringsspråk som Python, R, Java og C++, men er i sterk vekst (Puget, 2017). Scala kan fritt blandes med Java siden Scala begge kjører på JVM en abstrakt maskin som gir et miljø ved Java bytekode kan kjøres (JavaTPoint, Udatert). Selv om de tilhører separate prosjekt er det mulig å kalle på Scala metoder i en Java klasse (Odersky, WHAT IS SCALA?, Udatert). Dette er en åpenbar fordel for prosjekter med en Java basert back end. Java selv kan brukes i maskinlæring og kunne vært et alternativ, men det kommer med noen ulemper. Spesifikt bruker Java ofte flere kodelinjer enn Scala på å si det samme. Java har heller ikke støtte for les evaluer print løkken noe som gjør det ikke går an å aksessere eller utforske datasettet som brukes uten å gå gjennom en fullstendig utviklingssyklus (Jiang, 2015) Figur 6 Scala-kode for å lage en Person klasse Python Pyton er et tolket høynivås programmeringsspråk (Python, udatert). Språket er laget for å være lett å lese med en syntaks som ligger tett opp mot det engelske språket med bruk av ord som «not» og «in». Lesbarheten er også grunnen til at de tradisjonelle krøllparentesene ikke brukes i Python. Et sett med formateringsregler, kjent som PEP 8, sørger for at et script skrevet av en amatør har mer eller mindre det samme formatet som et skrevet av en erfaren Python programmerere (Love, 2014). Dette gjør at språket er relativt lett å plukke opp for en nybegynner. 27

29 Python har gjennom sin lange fartstid, 20 år, som et åpen-kildekode prosjekt opparbeidet seg en stor samling med biblioteker som er tilgjengelige for offentligheten. Biblioteker for alt fra bilde manipulering til vitenskapelige kalkuleringer eksisterer og gjør at språket har et vidt bruksområde (Love, 2014). Disse faktorene, lesbarhet og versatilitet, er viktige faktor når man skal velge et språk til bearbeiding av data. Databearbeidingen er en flaskehals i maskinlæringsprosjekter dataene må være ferdig behandlet før utviklere kan begynne å designe maskinlæringsmodellen. Man trenger forståelse for domenet, hvilke data som er tilgjengelige og hva de kan brukes til før man kan gå videre med utviklingen av alt fra databasen til maskinlæringsmodellen. Python er et språk som hjelper deg gjennom denne flaskehalsen raskt. Figur 7 Python kode med kodeblokk markert av hvit rom. 4.4 Front end Kantega hadde på forhånd antydet at React kunne vært et godt bibliotek for dette prosjektet og vi ble raskt enige om at det var en god løsning. Vi evaluerte en rekke andre rammeverk 28

30 og biblioteker ved hjelp av TodoMVC (se punkt 5.4 for mer informasjon). Bakgrunnen for valget av React som front-end bibliotek var til dels et ønske å bruke en av utfordrerne i markedet og til dels for å gi oss en ordentlig utfordring. React introduserte det som for oss var helt nye paradigmer og designmønstre og vi opplevde at React med tilhørende programvare hadde en svært bratt læringskurve. Det gikk med mye tid i starten av prosjektet til å få innsikt i en helt ny og komplisert verden. Det som utvilsomt var vanskeligst var å bli fortrolig med funksjonell programmering. Her blir vi introdusert for mange helt ukjente konsepter som det tok tid å lære seg og som vi heller ikke har hatt undervisning i. Valget om å programmere funksjonelt medførte at vi hadde lite tilgang til informasjon. I den aller meste informasjonen om React som er tilgjengelig brukes det et objektorientert paradigme og vi kan derfor i liten grad nyttiggjøre oss av den tilgengelige informasjonen. Foruten god hjelp fra vår veileder har vi vært prisgitt mer generell teori om funksjonell programmering. HTML HyperText Markup Language (HTML) er et markeringsspråk som bruker hypertekst for formatering og strukturering av nettsider (W3C, 1995). HTML5 er nyeste versjon av HTML i dag og er fortsatt under utvikling. HTML5 muliggjør strukturering og oppbygging av ulike typer innhold på nettsiden slik som bilder, tekst, video og animasjoner (Ducket, 2011). CSS Cascading Style Sheets (CSS) er et stilark som brukes til å style HTML-elementer for å gjøre nettsiden mer attraktiv og brukervennlig. Dette språket ble først introdusert i 1994 av Håkon Wium Lie. En CSS-fil innebærer definerte regler som lar oss kontrollere styling og layout på nettsidene via CSS-attributter (Ducket, 2011). De aller fleste nettlesere i dag har støtte for både HTML og CSS. 29

31 Javascript Javascript er et høynivå, dynamisk, ikke-typet og tolket run-time språk. Språket er definert i ECMAScript-spesifikasjonen og utviklingen av språket håndteres av Mozilla Foundation. Selv om det er tydelige likhetstrekk mellom Java og Javascript som navnet, syntaks og standardbibliotek, er det to helt distinkte språk som er svært forskjellige. Javascript er kjent for å ha hentet sin inspirasjon fra språkene Self og Scheme (Mozilla Foundation, 2017). Javascript er et prototype-basert språk med førsteklasse funksjoner, noe som tillater flere paradigmer; imperativ, objektorientert og funksjonell programmering. I dette prosjektet har vi programmert funksjonelt og brukt ECMAScript 6(ES6) standarden (Engelschall, 2016). Vi har brukt Babel til å oversette fra ES6 til en versjon av Javascript som nettleseren støtter (Babel.js, 2017). Figur 8 Eksempel på Javascript ES6 kode fra prosjektet som kaller et eksternt API Rendering Vi vil i dette dokumentet benytte oss av verbet å rendre. Dette kommer av det engelske ordet to render. I denne konteksten betyr det at vi referer til React sin render-metode. Denne metoden er det primære API-et for å manipulere DOM-treet (Facebook, 2015). 30

32 React React er et åpen-kildekode Javascript bibliotek opprinnelig utviklet av Jordan Walke hos Facebook, men har nå bidragsytere fra hele verden og en rekke kjent selskaper som AirBnB, Netflix og Paypal både bruker og videreutvikler React (React, 2017). React er et bibliotek for å lage effektive brukergrensesnitt og har som formål om å være rask, enkel og skalerbar (React, 2017). React er ikke et rammeverk på samme måte som Angular eller Vue.js siden React kun er et bibliotek for presentasjonslaget og blir ofte referert til som V-en i MVC-modellen (React, 2017). Man må derfor komplementere React med andre bibliotek eller rammeverk for å være funksjonelt. Det er vanlig å kombinere React med Redux.js, som er en implementasjon av Flux designmønsteret utviklet av Facebook (Facebook, 2015). React ser på grensesnittet (User Interface) som en funksjon av applikasjonens tilstand og denne måten å jobbe med grensesnitt er vanlig innen funksjonell programmering. Man har en deklarativ tilnærming i React, som er et paradigme kjent for de aller fleste fra blant annet HTML, regulære uttrykk og databasespørringsspråk som SQL og GraphQL. Det vil si at vi uttrykker hvordan vi ønsker at webapplikasjonen skal se ut, heller enn hvilke DOMoperasjoner som trengs for å oppnå ønsket resultat (Bekk, 2016). Andre viktige egenskaper ved React React opererer på en virtuell Document Object Model(DOM) og lager en datastruktur i minnet som representerer DOM. Forskjellen mellom den virtuelle DOM og DOM blir så skrevet til DOM. Dette er med på å gjøre React svært raskt fordi React oppdaterer bare den delen av grensesnittet som har endret seg. JSX er en syntaxutvidelse av Javascript og er anbefalt av Facebook for bruk i React. Strengt tatt ikke en del av React, men av økosystemet rundt React. Med JSX lager man React elementer og JSX er i utgangspunktet bare syntaktisk hjelp for React.createElement(component, props,...children). Se eksempel på hvordan JSX blir oversatt til Javascript i figur 9. 31

33 En-veis dataflyt er en annen viktig egenskap ved React. Data flyter bare en vei i applikasjonen; fra forelder til barn. Når man oppdaterer tilstanden vil React bare oppdatere de berørte komponentene og sørger for at grensesnittet alltid er oppdatert. I React applikasjoner kan man feilsøke med såkalt Time travel debugging. Det tillater oss å gå frem og tilbake i tid fra applikasjonens alle tilstander. Dette er et svært nyttig verktøy. Når man kombinerer dette med Hot reloading, hvor man kan gjøre endringer i koden live. Alle komponenter som endrer seg blir rekompilert og automatisk installert i utviklingsmiljøet som er funksjonalitet kjent fra funksjonell programmering. Disse to egenskapene gir oss et kraftig verktøy for utvikling og feilsøking. (React, 2017) (Barr, Marron, Maurer, Moseley, & Seth, 2016). (React, 2017) (Bekk, 2016) (Hudson, 2016) Figur 9 Oversettelse av JSX (venstre side) til Javascript (høyre side) ved bruk av Babel Redux.js Redux er ett lite bibliotek for tilstandshåndtering og dataflyt for JavaScript-applikasjoner skrevet av Dan Abramov. Abramov har hentet inspirasjon fra det Facebook-utviklede designmønsteret Flux, som er en ny måte å strukturere klientsiden av applikasjoner. Abramov har også hentet inspirasjon fra det funksjonelle språket Elm. (Redux, 2017) (React, 2017) 32

34 Historisk sett har MVC-modellen, som ble introdusert i Smalltalk-76 av Trygve Reenskaug, blitt brukt til webutvikling, men den har blitt kritisert for å skalere dårlig i store kodebaser (Parunashvili, 2016). Hovedproblemet med MVC-modellen har vært den bidireksjonale dataflyten som kan forårsake en kaskadeeffekt, hvor en liten oppdatering trigger andre oppdateringer i kodebasen. Dette er med på å gjøre store MVC-prosjekter lite oversiktlige og vanskelig å feilsøke (Parunashvili, 2016). Redux forsøker å løse dette ved å introdusere en ny modell for dataflyt som er strengt håndhevet i motsetning til i MVC-modellen hvor man står fritt til å strukturere dataflyten slik man selv vil (Parunashvili, 2016). Siden vi har uforanderlig data, både inn og ut, har vi kode som er enkel å forutsi og dermed også enkel å teste. Redux introduserer ytterligere kompleksitet til prosjektet og en helt ny måte å tenke på i forhold til tilstandshåndtering. Redux er i utgangspunktet et enkelt konsept og kan beskrives med tre prinsipper: Single source of truth. Hele tilstanden til applikasjonen er lagret i et objekttre i én enkel instans av store og det er kun én måte å endre tilstanden til applikasjonen. Dette gjør applikasjonen transparent og det er enkelt å forutsi tilstanden til applikasjonen. Tilstanden til applikasjonen er uforanderlig. For å endre applikasjonens tilstand må man sende en action, som beskriver endringene i applikasjonen, til en reducer. En reducer har som oppgave å kalkulere neste tilstand, på bakgrunn av nåværende tilstand og en action. I figur 10 ser vi et eksempel på noen actions fra applikasjonen vår. Endringer i applikasjonen endres med rene funksjoner. 33

35 Figur 10 Eksempel på "actions" i applikasjonen Figur 11 Oversikt over Redux' dataflyt (Geary, 2016) I figur 11 ser vi oversikt over dataflyten til Redux. Bruker manipulerer et av DOM-elementene, som for eksempel klikker på en knapp. Reactkomponenten lager en action som sendes til en dispatcher. Denne vil sende denne videre til en reducer. Denne vil på bakgrunn av nåværende tilstand og action kalkulere neste tilstand 34

36 og returnere denne til store. Til slutt vil store sende endringene videre til komponenten. Disse dataene vil så flyte nedover i applikasjonen; fra forelder til barn. Figur 12 Oversikt over applikasjonens tilstand En reducer har som oppgave å kalkulere neste tilstand, på bakgrunn av nåværende tilstand og en action. Reducere må være deterministiske, såkalte pure functions. En reducer med observerbare sideeffekter, som for eksempel asynkrone kall til eksterne API-er, diskaksess eller andre input-/output-operasjoner, vil forårsake problemer i applikasjonen siden den muterer tilstanden. Redux støtter ikke asynkrone actions, men trenger såkalt middleware som redux-thunk (Redux Thunk, 2017) (Redux, 2017). Funksjonell programmering Funksjonell programmering er et deklarativt programmeringsparadigme som beskriver hvordan man bygger strukturen og elementene i et dataprogram. I deklarative paradigmer beskriver man hva som skal gjøres i motsetning til imperative paradigmer, som beskriver hvordan man utfører gitte funksjoner. 35

37 I funksjonell programmering blir kode utrykt som matematiske funksjoner og man unngår tilstandsendringer og foranderlige data. Funksjonell programmering har sine røtter i Lamda-kalkulus, som er et formelt system innen matematisk logikk for å uttrykke computability (Cooper, 2004). I funksjonell programmering avhenger verdien av et uttrykk bare av inn-argumentene til uttrykket, og på den måten vil en funksjon x som blir kalt flere ganger med samme argument gi det samme resultatet, såkalt idempotens. Førsteklasse- og høyere ordens funksjoner En høyere ordens funksjon er en funksjon som enten kan ta en annen funksjon som argument eller returverdi og den er tett koplet mot førsteklassefunksjoner. Førsteklassesfunksjoner er et svært sentralt konsepts innen funksjonell programmering og tillater funksjonalitet som partial application (Begrenser antall argumenter til en funksjon og deler opp funksjoner) og currying (Oversetter evalueringen av en funksjon som tar flere argumenter til en sekvens av funksjoner med ett argument). Rene funksjoner Rene funksjoner eller såkalte pure functions er funksjoner eller uttrykk som ikke har noen observerbare sideeffekter og gitt samme innverdier, vil den alltid gi samme resultat. Med sideeffekter mener vi at funksjonen eller utrykket ikke endrer på verdier utenfor scope eller den har en observerbar kopling til den kallende funksjonen eller utsiden av funksjonen (Ofte er dette i form input/output-operasjoner). Det finnes en rekke fordeler ved å programmere funksjonelt som Hvis det ikke er avhengigheter mellom to pure functions så kan vi endre på kjørerekkefølgen på funksjonene og de kan kjøres i parallell fordi de ikke har mulighet til å endre hverandre fordi pure funtions er thread-safe(en applikasjon som er thread-safe opererer på delte datastrukturer på en måte som garanterer at race conditions ikke oppstår. En race condition er en låsetilstand som oppstår når to eller flere prosesser/tråder ønsker tilgang/å endre delte datastrukturer) 36

38 En pure function som blir kalt med samme argumenter vil alltid gi samme resultat. Dette muliggjør optimalisering som for eksempel memoization. Hvis resultatet av en pure function ikke brukes kan den fjernes uten komplikasjoner. Disse egenskapene gjør rene funksjoner enkle å teste fordi funksjonene ikke har noen avhengigheter til utsiden av funksjonen og fraværet av en intern tilstand gjør at vi kun trenger å teste grenseverdiene til argumentene og verifisere resultatene. Et annet viktig kjennetegn ved rene funksjoner er at de kan erstattes. Vi kan erstatte en metode eller funksjon med dets returnerte verdi uten å endre programmet. For eksempel vil concat( Hei, på deg ) kunne erstattes av strengen Hei på deg uten å endre programmet. Førsteklasse og høyere ordens funksjoner En høyere ordens funksjon er en funksjon som enten kan ta en annen funksjon som argument eller returverdi og den er tett koplet mot førsteklassefunksjoner. Førsteklassesfunksjoner er et svært sentralt konsepts innen funksjonell programmering og tillater funksjonalitet som partial application og currying. React/Redux økosystem Økosystemet rundt React og Redux er komplisert og består av en rekke komponenter. Programvaren og komponentene som vi benytter oss av er ikke unike for React/Redux. Det er mange andre JavaScript-baserte rammeverk og biblioteker som kjører samme utviklingsmiljø. Fellesnevneren for mye av programvaren er at de er basert på åpne og frie lisenser, altså åpen-kildekode, og utvikles av hundrevis av utviklere og mange av rammeverkene hadde sin spede start hos store firmaer som Google, Facebook og Twitter. Vi går her igjennom de viktigste verktøyene vi har brukt i vårt utviklingsmiljø. Babel 37

39 Som de fleste kanskje har erfart finnes det en rekke nettlesere som hver har sin egen implementasjon av JavaScript-tolker. Det finnes også en rekke JavaScript-standarder, både offisielle og kommende standarder, som Babel kan transpilere til standard JavaScript. Vi har brukt Babel til å oversette fra ES6 og JSX til en versjon av Javascript som nettleseren støtter (Babel.js, 2017). Dette muliggjør også at koden vår kan kjøres på eldre nettlesere. Babel er godt dokumentert, har et rikt utvalg av tilleggsprogramvare og er svært konfigurerbart og utvidbart (Babel.js, 2017). Node.js/NPM Node.js er et åpen-kildekode JavaScript run-time environment. Node muliggjør bruk av JavaScript på server og man kan dermed skape dynamiske nettsider ved å rendre websider før den blir sent til brukeren, såkalt isomorphic JavaScript. Node.js har også et svært godt bibliotek av de fundamentale internettjenestene som DNS, HTTP og TCP/IP. Dette gjør at Node egner seg svært godt til å lage internett-tjenester som RESTfulle API-er eller andre socket-baserte tjenester og den håndterer trafikk svært godt grunnet den hendelsesdrevne arkitekturen. Node baserer seg på en hendelsesdreven arkitektur og Node bruker bare en tråd og ikkeblokkerende I/O-kall og baserer seg på callbacks for å signalisere om en oppgave er ferdig. Dermed kan den håndtere titusenvis av koplinger uten å måtte foreta kostbare kontekstbytter og egner seg derfor svært godt til dataintensive applikasjoner (Kontekstbytte; Når prosessoren skifter fra en oppgave til en annen går det tapt forholdsvis mye tid) (Li, Ding, & Shen, 2007) (Node.js Foundation, 2017). Bakdelen med denne arkitekturmodellen er at den takler prosessorintensive applikasjoner dårlig siden en oppgave som krever mye kjøretid vil blokkere alle andre oppgaver under kjøring og man bør velge en trådbasert arkitektur hvis man har prosessorintensive bruksområder (Node.js Foundation, 2017). Node Package Manager (NPM) er et pakkehåndteringssystem for JavaScript som tilbyr omlag en halv million pakker og det er det anbefalte verktøyet for pakkehåndtering og 38

40 konfigurasjonsstyring for React og vi har brukt NPM i stor utstrekning i prosjektet (Node.js Foundation, 2017) (React, 2017) (Node.js Foundation, 2017). Vi brukte Nodes rammeverk for web, Express, for å webtjener i prosjektet. Det er en svært minimalistisk webtjener som egner seg svært godt til utvikling siden den bruker lite ressurser og er enkel å konfigurere og tilpasse til egne scenarier. Hvis denne applikasjonen skal i produksjon må den migreres over til en mer skalerbar og driftssikker løsning. Enzyme/Mocha Enzyme er et verktøy for testing av React JavaScript kode, som vi brukte sammen med Mocha. Mocha er et testrammeverk for JavaScript kode som kjører på Node.js og er en såkalt test runner (Airbnb, 2016) (Airbnb, 2017) (Mocha, 2017). En test runner er et konfigurerbart program eller bibliotek som har som oppgave å utføre enhetstestene og presentere oss for resultatene. Enzyme er utviklet av AirBnb som er en stor markedsplass for overnatting og er en av de store aktørene innen delingsøkonomi. AirBnb har satset stort på React og har utgitt en rekke verktøy under en åpen-kildekode lisens. Enzyme tilbyr oss flere metoder for å rendre React komponenter slik at vi får isolert komponenten under test. Slik sørger vi for at vi ikke indirekte tester på eller blir forstyrret av komponenter som ikke er under test (Airbnb, 2017) (Airbnb, 2016). Webpack Webpack er en JavaScript modulbygger, basert på åpen-kildekode. Webpack analyserer hvilke avhengigheter du har i koden ved å lage en avhengighetsgraf som inkluderer alle modulene applikasjonen trenger. Den vil så å lage statiske kopier av avhengig kode i en fil. På denne måten reduserer vi hvor mye kode som må lastes inn. Det kan også være nyttig i store prosjektet for å splitte prosjekter i mindre, håndterbare biter for å redusere innlastingstid og få et mer oversiktlig prosjekt. 39

41 Vi slipper også å lenke til en mengde JavaScript-filer i prosjektet vårt og reduserer innlastingstiden. Vi benyttet også oss av webpack-dev-server (Node.js Express-basert) som vår webserver siden den støtter hot loading, som betyr at Webpack har kildekoden i minnet og enhver endring av kode trigger automatisk oppdatering av server. Figur 13 Oversikt over noen av modulene Webpack har bygget i prosjektet Bootstrap Bootstrap er et populært front-end rammeverk laget av Twitter i midten av 2010 og er utgitt som et åpent kildekodeprosjekt på GiHub. Vi brukte React-Bootstrap hovedsakelig for layout og plassering av elementer. React-Bootstrap er en komplett re-implementasjon av Bootstrap-komponenter for React. Det har ingen avhengighet til hverken bootstrap.js eller jquery (Twitter, 2017) (React-Bootstrap, 2017). Ajax Asynchronous JavaScript and XML (Ajax) er et JavaScript med et asynkront kall til server (Holzner, 2008, s. 5). Det finnes hovedsakelig to typer kall til server, synkront og asynkront kall. Et synkront kall er når nettleseren må vente til det for svar fra server før brukeren kan 40

42 gjøre noe som helst på nettsiden (Cisco, Inc, 2014). Mens et asynkront kall er når brukeren kan jobbe på nettsiden parallelt mens de venter på svar fra server uten at hele nettsiden må lastes inn på nytt igjen (Holzner, 2008, s. 73). Vi brukte Ajax for å gjøre nettsiden dynamisk og brukervennlig. 4.5 Scrum som metode Det kan være vanskelig å levere programvare som møter kundens forventninger fordi krav og kundens forventninger kan stadig endre seg og det er ikke alltid kunden vet hva de vil ha før man begynner å utvikle deler av systemet. Vi ønsket å bruke smidig arbeidsmetodikk for å kunne håndtere endringer som kan oppstå under (Beck, et al., Principles behind the Agile Manifesto, 2001). Smidige utviklingsmetodikker er svært mye brukt i bransjen og Kantega bruker hovedsakelig smidige utviklingsmetodikker i deres prosjekter (Scrum Alliance, 2017) (Kantega A/S, 2015). Scrum er en av de mest populære rammeverkene som brukes i smidige utviklingsprosjekter og baserer seg på elementer fra inkrementell og iterativ utvikling (Scrum Alliance, 2017). Smidig planlegging skjer inkrementelt, det betyr at for hver runde med planlegging skal det legges til en ny funksjonalitet, et inkrement, som gjør det enklere å endre under prosessen ved kundebehov. Funksjonaliteten til inkrementene er ikke planlagt på forhånd, de avgjøres under utviklingen. Hva som tas med i hver iterasjon avhenger av utviklingen i prosjektet og kundens prioriteringer. Kundens prioriteringer og krav endrer seg stadig, derfor kan det være fornuftig å ha en fleksibel plan som kan ta høyde for disse endringene, slik som det er gjort i Scrum. Fordeler med inkrementell utvikling er lavere kostnader ved kravendring, enklere å få tilbakemeldinger fra kunden på det som har blitt utviklet, lettere oversikt over utviklingsprosessen, raskere levering av deler av systemet, og lavere risiko for at noe kan gå galt. 41

43 Inkrementell og iterativ utvikling går ut på å gjenbruke eksisterende komponenter, hvor man legger til ett inkrement, dette kalles en sprint. Hver iterasjon varer omtrent to til fire uker. Sprinter brukes for å forbedre koden eller gjøre koden mer robust. En iterasjon består av daglige oppmøter i teamet og er en syklus i utviklingen av et prosjekt. Et nytt inkrement utvikles gjennom en ny iterasjon som betyr en forbedring av det forrige systemet (Cohn, 2014). Inkrementell og iterativ utvikling henger ofte sammen i smidig utvikling, men kan også være plandrevet og en blanding av andre typer utviklingsmetodikker. Vi tok høyde for tidlige og kontinuerlige leveranser for kunden av verdifull programvare og var åpen for kravendringer, selv sent i utviklingsprosessen. Retroperspektiv. Teamet reflekterte over hvordan man kan bli mer effektiv og muligens utføre noen justeringer ved behov (Cohn, 2014). 4.6 Kodegjennomgang Selv om vi i prosjektet hadde tatt i bruk automatisk kodegjennomgang hadde vi også kodegjennomganger i form av uformelle gjennomganger av kode som har blitt commit et. En kodegjennomgang er en strukturert undersøkelse av kildekode, også kjent som code review.. En slik gjennomgang har vært en viktig del av kvalitetsarbeidet i prosjektet. I tillegg til å avsløre uoppdagede feil, så er formålet med en slik gjennomgang å øke kvaliteten på koden. Vi har hatt et strengt regime for kodegjennomgang i prosjektet. Vi har ikke hatt rettigheter til å installere kode i hovedtreet i vårt pakkebrønnsystem Gitlab og vi har vært avhengig av en streng kodegjennomgang før vi har fått den nødvendige godkjennelsen. Selv om dette til tider kan føles pedantisk så har det vært svært nyttig å måtte oppfylle slike strenge krav til kodekvalitet. Vi måtte som regel gjennom mange iterasjoner før koden vår ble godkjent og 42

44 den minste ting førte til at koden ble avvist og man måtte starte hele prosessen på nytt. Dette gjorde oss rutinerte i bruk av pakkehåndteringsverktøyet git, ga oss mye erfaring i prosessen involvert i systemutvikling og gjorde oss fokuserte og skjerpet ved å tvinge oss til å strekke oss lengre. Vi tok i bruk AirBnBs kodestandard for JavaScript og JSX (style guide) (AirBnB, 2017). 4.7 Testing Formålet med testing er å sikre god kvalitet i IT-systemer. Det finnes mange grunner til at man bør teste. Menneskelig feil skjer hele tiden. Sikre at kunden blir fornøyd. Sikre kvaliteten i systemet. Sikre god ytelse. Langsiktig sikre minimalt med nødvendig vedlikehold. Det koster mye mer å vedlikeholde systemet og rette opp feil når systemet er satt i produksjon enn man gjør tidlig i fasen. Ved å identifisere feil så tidlig som mulig så vil man spare tid og penger. (Kaulgud & Sharma, 2011) Man får aldri ett feilfritt system derfor har vi nødt til å legge oss på ett nivå hvor vi kan si at kvaliteten er god nok med å ta hensyn til kunden og det kan by på noen utfordringer (Mitchell & Black, 2015). Enhetstesting Enhetstesting, også kalt komponenttesting, tester funksjonaliteten til hver individuelle programenhet for seg selv (Mitchell & Black, 2015). Enhetstesting bør automatiseres slik at tester kan kjøres uten manuell innblanding. Det betyr at vi slipper å gjøre de samme type testene hver gang fra bunnen av og vi sparer tid. Automatisering av testene har en viktig 43

45 betydning i forhold til regresjonstesting. Enhetstester kjennetegnes ved at de er korte, selvstendige og uavhengige, idempotente funksjoner. Programmereren er selv ansvarlig med å skrive tester til sine egne enheter og metoder i koden. Vi utførte automatisering av testene både i enhetstesting- og integrasjonstestingsfasen. Det finnes en del verktøy for gjennomføring av enhetstesting. JUnit er et test- og automatiseringsrammeverk for Java som vi brukte for testing i back-end. I prosjektet vårt har vi tatt i bruk en del sentrale prinsipper fra DevOps. I vår prosjektinfrastruktur har vi en instans av Jenkins, som er programvare for kontinuerlig integrasjon. Hver gang vi leverte kode til vårt repository trigget det kjøring av alle enhetstestene, altså såkalt regresjonstesting som vil si at vi tester for å avsløre om vi har introdusert nye feil i eldre kode. Det er et krav all kode passerer testene før den blir akseptert inn i hovedtreet (master branch). Testene ble kjørt hurtig og veldig ofte. For hver gang det skjedde en endring av koden måtte testene kjøres om igjen for å avdekke mulige feil som kan ha oppstått under endringen. Denne type kvalitetssikring er spesielt aktuelt i smidig utvikling. Det ble gjennomført to typer enhetstester på normal bruk og unormal bruk. Ved testing av normal bruk så skal man sjekke om komponenten oppfører seg som forventet. Mens ved testing av unormal bruk så blir enheten testet på om det ikke krasjer ved unormal input, for da må man håndtere feilene som blir generert. Formålet med enhetstesting er å avsløre feil tidlig i prosessen. Derfor er det viktig at enhetstester er korte, selvstendige og uavhengige, idempotente funksjoner. Enhetstest ble gjennomført i front-end med Mocha og Enzyme, mens i back-end ble det brukt JUnit. 44

46 Figur 14 Eksempel på enhetstest av reducer Figur 15 Eksempel på enhetstest av metode i JUnit Integrasjonstesting Integrasjonstesting er neste testfase hvor vi testet sammensatte komponenter og samspillet mellom disse (Mitchell & Black, 2015). Integrasjonstest ble gjennomført med SoapUI. Her testet vi endepunktene i Java Spring Boot for hvordan det oppfører seg i forhold til standardene. 45

47 Figur 16 Eksempel på integrasjonstest utført i SoapUI Systemtesting Systemtesting er når systemet blir testet som en helhet, samhandlingen mellom alle sammensatt komponenter (Mitchell & Black, 2015). Det er normalt at man mot slutten av testfasen utfører systemtest etter enhetstest og integrasjonstest. Vi valgte å ikke utføre systemtest i prosjektprosessen vår fordi mottagerorganisasjonen hadde lite disponert tid til å integrere løsningen vår inn i deres store system. Akseptansetesting Akseptansetesting er den siste testfasen hvor systemet skal leveres og er når potensielle brukere tester systemet i egne omgivelser (Mitchell & Black, 2015). Akseptansetest foregikk med kunden mot slutten av bachelorprosjektet. Her ble det fokusert på validering og verifisering av produktet opp mot kravspesifikasjon. Vi ville sjekke om produktet stemmer med det kunden ønsket seg ved å ta hensyn til brukerhistorier som ble laget i 46

48 kravspesifikasjonen. Formålet med akseptansetest er å få bekreftelse om systemet imøtekommer kundens krav og overlevere det til kunden. Fortrolighetsavtale På grunn av prosjektets natur har vi arbeidet med mye sensitiv data. For å beskytte disse dataene har hvert individ i gruppen signert en fortrolighetsavtale med Fiskeridirektoratet og arbeidet på PC er med krypterte harddisker. Disse dataene danner grunnlaget for applikasjonen vår men, på grunn av den nevnte fortrolighetsavtalen har vi ikke mulighet til å inkludere disse i den endelige innlevering. Vi har i stedet skrevet egne filer med «mock data» for at applikasjonene skal kunne returnere data hvis det skulle være ønskelig for noen fra HiOA å kjøre den. Disse dataene inneholder flere av de samme kategoriene som de originale men vi har valgt å ikke inkludere kategorier som i original dataene konsekvent hadde nullmerker. Disse kategoriene ble heller ikke sett på som relevante for prosjektet av samme årsak og følgelig ikke brukt. I tillegg har de vedlagte filene langt mer begrenset innehold enn de vi faktisk har arbeidet på. 47

49 4.8 Fremdriftsplan og milepælsplan Figur 17 Fremdriftsplan med milepæler for prosjektet 4.9 Verktøy Integrert utviklingsverktøy Et integrert utviklingsverktøy, en såkalt IDE, er en applikasjon for programvareutvikling som har som formål om å øke produktiviteten til utvikler ved å tilby funksjonalitet og egenskaper som skal understøtte utviklingsprosessen som: Statisk kodeanalyse for å avsløre feil i kode, død kode, sikkerhetsproblemer, duplikat kode og andre type feil som kan oppdages uten å kjøre koden Håndtering av avhengigheter Intuitiv og kontekstsensitiv fullføring av kode Automatisk fullføring av kode ved å tilby Automatisering av kompilering og kjøring av kode 48

50 Integrasjon mot versjonshåndteringssystemer (JetBrains, 2017) En IDE består normalt av en teksteditor, kompilator, en debugger, og et grafisk brukergrensesnitt. Til Java-utviklingen evaluerte vi ikke noen andre IDE-er enn IntelliJ IDEA fordi vi hadde god erfaring med denne fra tidligere prosjekter. Dessuten hadde den god støtte for Java EE spesifikasjonene. Det finnes en rekke gode IDE-er for Java utvikling og for det meste handler det om smak og behag og vaner når det gjelder valg av utviklingsverktøy. Åpen-kildekode utgaven av IntelliJ IDEA har ikke støtte for Java EE/Spring, men vi har som studenter tilgang til fullversjonen igjennom skolen (JetBrains, 2017). Til utvikling av JavaScript/JS-kode ønsket vi en IDE eller editor som hadde god støtte for node.js verktøy, git og lint verktøy (statisk analyse av koden opp mot forhåndsdefinerte regler). Vi vurderte flere verktøy og IDE-er som Sublime Text, NotePadd++, JetBrains WebStorm, men valget falt til slutt ned på Atom grunnet svært gode muligheter for konfigurering og gode tilleggspakker som tilbyr funksjonalitet og språkstøtte vi trengte. Atom Atom er åpen kildekode og modulært oppbygd tekstbehandlingsverktøy utviklet av GitHub. Atom tilbyr et rikt utvalg av tilleggspakker og det er god språkstøtte med syntaksmarkering for JSX/ES6 (Atom, 2017). Vi brukte Atom for utvikling av JavaScript/JSX i prosjektet. GitLab GitLab er en versjonskontroll og et verktøy for deling av programkode. Denne tjenesten er mye brukt til utviklingsprosjekter innen IT-bransjen. GitLab er en moderne utgave av GitHub som tilbyr flere funksjonaliteter. Versjonskontroll betyr at man kan gjenopprette tidligere versjoner av prosjektkoden dersom en feil skulle oppstå. I GitLab kan en opprette offisielle og private prosjekter, arbeide individuelt på hver sine gren før man velger å 49

51 synkronisere dem mot en felles hovedgrein. Tanken er å forebygge eventuelle konflikter eller uønsket påvirkning av hverandres arbeid under kodingen. GitLab gir en enkel oversikt over utførte endringer, og farge-markerer koden sammen med kommentarer i forbindelse med commits som gjør at man til enhver tid vet hva som foregår i koden. GitLab sier også ifra dersom konflikter oppstår, et klassisk eksempel er at noen har endret på samme sted i koden (GitLab, 2017). Figur 18 Skjermbilde fra GitLab(Bilde tatt ) Jira JIRA er et digitalt verktøy for prosjektstyring. Navnet stammer fra det japanske ordet Gojira eller Godzilla. Denne tjenesten tilbyr teamarbeid med Scrum-board, sprintplanlegging, bugtracking, integrasjon med GitLab, og flere andre funksjonaliteter for prosjektstyring. Jira gir en god oversikt over prosjektstatus og er et godt verktøy for smidig metodikk (Atlassian, 2017). 50

52 Figur 19 Skjermbilde fra prosjektstyringsverktøyet Jira(Bilde tatt ) Slack Searchable Log of All Conversation and Knowledge (Slack) er et digitalt kommunikasjonsverktøy der teammedlemmer kan enkelt kontakte hverandre på tvers av panelet. Slack tilbyr deling av filer, meldinger og videosamtaler, integrasjon til andre verktøyprogrammer som Dropbox, Twitter, GitLab, etc. Innhold i filer og alt som blir publisert i Slack er søkbart ved kun bruk av ett søkefelt. Teamsamtaler kan distribueres i ulike typer aktivitetskanaler og gir god kontekst og strukturflyt (Slack, 2017). 51

53 Figur 20 Skjermbilde fra Slack (Bilde tatt ) Mattermost Mattermost er et utvidet Slack-alternativ for digitalt kommunikasjonsverktøy. I tillegg til Slack-funksjoner tilbyr Mattermost mer funksjonalitet i sikkerhet, intern kommunikasjon, integrasjon med GitLab, lokal- og språksetting, og full aksessering til alle typer API-servere. Mattermost er bygget på moderne teknologier som Golang, React.js og Node.js (Mattermost, 2017). 52

54 Figur 21 Skjermbilde fra Mattermost (Bilde tatt ) Confluence Confluence er et digitalt kommunikasjonsverktøy for deling av informasjon innad prosjektgrupper. Confluence kan brukes til dokumentasjon, prosjektplanlegging, oversikt over arbeidsoppgaver, oppretting og deling av dokumentfiler, og tilbakemeldinger i strukturert kontekst. For dokumentasjon kan man opprette hjemmeområder til hvert enkelt prosjekt. Hvert hjemmeområdene inneholder et sett med undersider organisert i en trestruktur. På sidene kan medlemmer gi kommentarer, sette inn ekstra funksjonaliteter, og gi brukerrettigheter. Sidene er alltid lagret i versjoner og kan enkelt redigeres (Atlassian, 2017). Eslint ESLint er et åpen-kildekode verktøy før statisk kodeanalyse laget av Nicholas C. Zakas i Vi brukt ESLint som en plug-in i Atom for å finne problematiske kodemønstre og brudd på kodestandarden i prosjektet vårt. Siden JavaScript er et dynamisk og løst typet språk er det sårbart for at utviklere introduserer feil i koden. 53

55 4.10 Utfordringer Hovedutfordringen i prosjektet har vært å sette seg inn i alle de nye teknologiene vi, sammen med Katenga, bestemte oss for å bruke. Spark (Apache Spark, Udatert), Springboot (Katamreddy, Java Zone, 2016), Maven (Apache Maven Project, Udatert), React (React, 2017), Redux (Redux, 2017), Python (Python Software Foundation, 2017), Scala (Odersky, Scala, Udatert), Jenkins (Knorr, 2016) og Ansible (Ansible, 2017) ingen av oss hadde jobbet med noen av disse teknologiene før vi startet prosjektet. I tillegg jobbet vi innenfor paradigmer som var forholdsvis ukjente for oss gjennom studiene har vi hovedsakelig jobbet med objekt orientert programmering, mens en stor del av prosjektet baserte seg på funksjonell programmering. En god porsjon av prosjektperioden har derfor naturlig nok gått med til å bli kjent med alle disse ulike teknologiene. Resonnementet bak hvert individuelle teknologivalg mener vi var godt (en kombinasjon av et ønske om å finne det beste verktøyet for hver individuelle jobb og hensyn til Kantegas ønsker med tanke på å gjøre en mulig integrering inn i et av deres prosjekt lettere), men vi tok nok ikke godt nok hensyn til helheten og hvor stor summen av alt det nye vi måtte lære oss ble. Dette problemet ble forsterket av at vi bare er tre på gruppen. Vi fordelte hovedansvaret for forskjellige språk mellom oss, men med så få personer å fordele de på (samt et ønske om at vi alle skulle få innsikt i alle de forskjellige teknologiene) ble det til at vi alle måtte kunne litt om alle språkene. I tillegg til teknologiene var det også mange prosjektstyringsverktøy (Jira, Slack, Mattermost og Gitlab) å forholde seg til. Det må nevnes at vi hadde god hjelp av to veiledere fra Kantega som tok på seg hovedansvaret for Scala og Python delen av prosjektet. Alt i alt og ed fordel av etterpåklokskap, og med tanke på det finnes fag på HiOA som gir 10 studiepoeng for å sette seg inn i et programmeringsspråk, kan det nok sies at vi var litt vel ambisiøse i antallet nye teknologier vi valgte å bruke. Ambisiøse var vi også når det kommer til omfanget av selve oppgaven der vi utgangspunktet hadde en oppgave som gikk på å analysere og bearbeide data fra Fiskeridirektoratet, lage en maskinlæringsalgoritme basert på disse dataene og lage en webapplikasjon der brukere kan aksessere og arbeide med algoritmen. Vi hadde et ønske om å ta på oss en utfordrende oppgave og en formening om at vi ville være i stand til å 54

56 gjennomføre den. Det viste seg imidlertid at appetitten var større enn evnen og etter tilbakemelding fra veileder om at prosjektet var for stort valgte vi å holde samtaler med Kantega om å skalere ned oppgaven. Resultatet ble at vi tok hovedansvaret for utviklingen av webapplikasjonen, mens våre to veiledere tok hovedansvaret for å bearbeide dataene og utvikle maskinlæringsalgoritmen. Vi har gjennom hele prosjektet hatt god kontakt med Kantega noe som har gjort oss godt rustet til å møte problemer, for eksempel behovet for å gjøre omfanget mindre, og gjøre de nødvendige endringene samtidig som tar hensyn til begge parters behov. Datakvalitet er en typisk utfordring for maskinlæringsprosjekt og vårt var intet unntak. Vi hadde en god dialog med Fiskeridirektoratet og de var veldig hjelpsomme når det kom til å hente inn og sende over dataene vi har spurt etter, men kvaliteten på disse dataene varierte. Mye av de tilgjengelige dataene hadde mangler og var dårlig egnet for vårt formål. Den totale mengden med data som kunne brukes til å trene og teste algoritmen viste seg å være liten. Dataene kom heller ikke med spesielt gode merkelapper så det var nødvendig å sette seg litt inn i domenet og konteksten til data der tall ofte bare var merket med uforklarte akronym før arbeidet med å bearbeide de kunne begynne. Databearbeiding ble en flaskehals for hele prosjektet. Alt i alt møtte vi på flere utordringer underveis der de fleste kan spores tilbake til at dette er førstegang vi jobber på et prosjekt av dette omfanget. Selv om vi har jobbet på flere mindre prosjekt tidligere kom det veldig tydelig frem at vi ikke hadde den nødvendige kunnskapen til å lage et realistisk estimat over hvor lang tid de forskjellige oppgavene tar. Dette skapte også en kjedereaksjon der fristen for å ferdigstille en oppgave ikke ble holdt noe som spiste inn i tiden som var satt av til neste oppgave og så videre. Vi har prøvd å kompensere for dette ved å ha en åpen og aktiv dialog med arbeidsgiver, kunde og veiledere (både fra HiOA og Kantega) underveis. Dette har gitt oss mye verdifull tilbakemelding underveis som vi har tatt hensyn til. Vi måtte ta noen vanskelige valg underveis der noen featurs måtte kuttes og oppgavens omfang måtte redefineres, men vi kom, sammen med Kantega, frem til at det var bedre å ha et begrenset men ferdig produkt enn et større uferdig produkt. 55

57 5 Produktdokumentasjon 5.1 Systemarkitektur Maskinlæringsmodellen, skrevet i Scala, integreres i back-end delen av prosjektet som en JAR-fil. Denne filen blir koblet til prosjektet gjennom Maven og blir referert til i POM-filen. Scala metodene kan nå kalles fra Java koden. Dataen sendes og prosesseres mellom de to lagene av en Apache Spark ML pipeline. Dataen som prosesseres av denne pipelinen er av typen DataFrame. Back-end henter dataene ved oppstart av applikasjonen fra filer i CSV og JSON format. Parsere for begge formatene mapper innholdet i filene til Java objekter som legges inn i en H2 in memory database. Front-end kommuniserer med back-end gjennom kall til API end point. Dataene som kommer som svar er i JSON format. 56

58 Figur 22. Illustrasjon av arkitekturen og kommunikasjonen mellom de forskjellige lagene. DevOps DevOps er en term som stammer fra sammenslåingen av to store relaterte trender innen ITindustrien: Agile system administrering bruken av smidig tilnærming til operasjons eller administrerings arbeid. Samarbeid mellom utviklere og operasjonsarbeidere gjennom alle stadiene av utviklingssyklusen. I praksis vil det si at DevOps er samarbeid mellom utviklere og operasjonsarbeidere gjennom hele livssyklusen til tjenesten som utvikles fra design, gjennom utviklingen til postproduksjonssupport. Dette er bygget på konsepter fra smidigutvikling der et nært 57

59 samarbeid mellom kunde, produkt eier, utviklere og QA avdelingen gjennom flere iterasjoner er essensielt. DevOps tar disse konseptene videre fra å gjelde bare selve koden til å gjelde hele den aktuelle tjenesten. To sentrale praksiser innen DevOps er kontinuerlig integrering og kontinuerlig levering som vi vil gå nærmere innpå under egne overskrifter (Mueller, 2016). Smidigutvikling har vært sentralt gjennom hele utviklingsprosessen vår og DevOps ble derfor tidlig en sentral del av utviklingsmiljøet vårt. Vi satte av tid tidlig i prosjektperioden til å sette opp en Anisble playbook og et Jenkins miljø som kunne brukes til kontinuerlig integrering og kontinuerlig levering. Dette gjorde kvalitetssikring, der koden må passere alle testene før den kan merges inn i master grenen i GitLab, bedre og tillot oss å publisere den nyeste versjonen av webapplikasjonen (den versjonen som ligger i master grenen). I et smidigmiljø der kontinuerlig tilbakemelding fra produkteier (Fiskeridirektoratet i dette tilfellet) er viktig gjør denne tilnærmingen det langt lettere å vise den nåværende versjonen av produktet og holde diskusjoner rundt denne. Kantega har en eksisterende Jenkins server som de lot oss bruke. Dette sparte oss en del tid som ellers ville gått med til å få en ny Jenkins server opp og kjøre. Vi koblet serveren til GitLab prosjektet vårt ved hjelp av såkalte webhooks som gjør det mulig for eksterne tjenester som Jenkins å abonnere på hendelser på GitLab (Github Developer, 2017) og konfigurerte den til å kjøre enhetstester ved push til alle grenene og publisering ved merging til master. Kontinuerlig integrering og kontinuerlig levering Kontinuerlig integrering går essensielt ut på å integrere hele systemet eller applikasjonen så ofte og så tidlig som mulig. Hvert teammedlem pusher versjonen av systemet eller applikasjonen de har arbeidet på til en felles pakkebrønn. Dette gjøres hyppig, for eksempel på slutten av arbeidsdagen. Hver gang en ny versjon pushes til denne pakkebrønnen trigges kompileringsprosessen, kjører enhetstester og andre kvalitetsrelaterte verktøy som er i bruk. Denne prosessen automatiseres som oftest så langt som det lar seg gjøre (Hering, 58

60 2015). Fordeler med denne måten å arbeide på er at man oppdager feil og integreringsproblemer tidlig når det fortsatt er relativt enkelt å løse de. Problem og mangler ved designet oppdages underveis. Alternativet der slike problem oppdages sent i prosessen da de ofte har vokst seg større og er vanskeligere å løse (Sharma, 2012). Kontinuerlig levering er et konsept som er til forveksling lik kontinuerlig publisering. Der den eneste forskjellen er - som figur 23 viser hvilken del av prosessen som automatiseres. I kontinuerlig levering, som er det vi har benyttet oss av automatiseres alt opp til punktet der systemet eller applikasjonen settes ut i produksjon (Hering, 2015). I vårt prosjekt må versjonen gjennom en kodegjennomgang fra de andre gruppemedlemmene før den kunne merges inn i master grenen og dermed settes ut i produksjon. Figur 23. Forskjellen mellom kontinuerlig levering og kontinuerlig publisering (Hering, 2015). 5.2 Back-end Her vil vi snakke litt om teknologiene vi valgte å bruke i utviklingen av back end hvorfor de ble valgt, hvordan de virker. Der det er naturlig vil vi også gå litt nærmere innpå hvilke teknologier vi vurderte men til slutt valgte bort og hvorfor dette ble gjort. Teknologiene vi endte opp med å bruke forklares i detalj under egne overskrifter. For back end ble rammeverket Spring Boot anbefalt på bakgrunn av følgende argumenter: 59

61 Kantega arbeider på et annet prosjekt for Fiskeridirektoratet som er laget i Spring Boot og de ønsket å gjøre det så lettvint som mulig å integrere vårt prosjekt i deres hvis dette skulle vise seg å være fordelaktig. Kantega som en organisasjon er godt kjent med Spring Boot og har følgelig erfarne programmerere som kan dette rammeverket som kan konsulteres. Kantega ønsket å gi oss en teknologistabel som var utfordrende, spennende og ikke minst relevant i forhold til hva som er i bruk i konsulentbransjen om dagen. Etter å ha undersøkt alternativer som Apache Struts 2, Spring MVC og Play Framework kom vi frem til at Spring Boot er en sterk kandidat på egne meritter og når vi også tar Kantegas argumenter i betraktning mener vi at dette er riktig verktøy for jobben. Når det kommer til auksiliære teknologier som IDE, verktøy for bygging og integrering av maskinlæringsmodellen stod vi mer fritt til å utforske alternativene. Valg av IDE brukte vi minst tid på siden, selv om programmeringsmiljøet er viktig, vi allerede hadde mange nye teknologier å lære oss og dette valget var det som hadde minst påvirkning på sluttproduktet. Vi var alle godt kjente, og fornøyde, med IntelliJ. Når det kommer til bygge verktøy snevret vi feltet ned til Gradle og Maven. Gradle er skript basert og derfor veldig lett å skreddersy, men dette betyr også at det er vanskeligere å forstå. I tillegg må prosjektet kjøres for å kunne få informasjon om det. Maven på sin side kommer med egne utfordringer (som diskuteres under egen overskrift), men alt i alt vurderte vi det som det beste alternativet. Apache Spark hadde få reelle konkurrenter når det kommer til integreringen av maskinlæringen, og sammen med veilederne våre fra Kantega, som har en langt mer kunnskap om maskinlæring og teknologiene rundt det enn vi har, bestemte vi oss for å gå for Spark. 5.3 Front-end Økosystemet for programmering av grensesnitt er i rivende utvikling og det finnes nå utallige rammeverk og bibliotek basert på Javascript eller som transpilerer (kildekode til 60

62 kildekode kompilering) til Javascript. I forprosjektet ble vi enige om at vi ønsket å utforske et moderne rammeverk/bibliotek basert på Javascript for såkalte Single Page Applications (SPA) og hadde sett på muligheten til å enten bruke Angular 2/4 eller React. Vi vurderte også Knockout.js Ember.js, Vue.js og jquery i den innledende fasen. Funksjonell programmering sammen med uforanderlige datastrukturer og React har utvilsomt endret måten vi programmerer grensesnitt på. React abstraherer i praksis bort DOM-en. Da vi skulle evaluere hvilket rammeverk eller bibliotek vi skulle ta i bruk på front-end så brukte vi TodoMVC. Det er en huskelapp webapplikasjon som er implementert i over 50 forskjellige språk og rammeverk som Vue.js, Angular 1.x/2.x, Backbone.js, React, Knockout.js og mange fler. Slik kan vi sammenligne de forskjellige språkene og rammeverkene opp mot hverandre. TodoMVC gir en begrenset innsikt i hvordan en applikasjon skrevet i det aktuelle språket er strukturert og har vært nyttig når vi evaluerte rammeverk og bibliotek for front-end (TodoMVC, 2017). 5.4 Design og brukeropplevelse Designet til webapplikasjonen ble tatt opp i et møte med oppdragsgiver i startfasen. Selv om funksjonalitetene til webapplikasjonen lå høyst i prioriteringslista så var det ønskelig for oss å utvikle parallelt et innbydende og moderne design. Det ble brukt Helvetica, en kategorisert skrifttype under sans-serif, for økt lesbarhet og nøytralt for øynene. Vi tok hensyn til gruppering ved å beholde tomrom mellom de forskjellige elementene og en lik struktur mellom de forskjellige sidene. Siden løsningen vår skal integreres i et større system så valgte vi å tilpasse designet vårt til det eksisterende med tanke på fargebruk. (Shinn, Udatert) 61

63 Figur 24 Utsnitt av førstesiden til applikasjonen Figur 25 Utsnitt av objekter med kalkulert risiko 62

64 6 Avslutning 6.1 Erfaringer Teknologier Spring Boot Erfaring Spring Boot gjorde det veldig enkelt å få applikasjonen opp å kjøre. Alle konfigurasjonene og bibliotekene som kommer ut av boksen kuttet ned på kodemengden noe som gjorde back-end mer oversiktlig. Det finnes en mengde guider og en dedikert youtube kanal som tar for seg forskjellige aspekter av Spring Boot noe som var veldig nyttig. Apache Spark Alt i alt er vi veldig fornøyde med valget av Spring Boot som back-end rammeverket. Det eneste problemet vi støtte på var at, siden Spring Boot gjør mye for deg automatisk, kunne det tidvis være vanskelig å finne ut den nøyaktige prosessen bak noe som ble automatisert. Spark var forholdsvis greit å sette seg inn i, spesielt i forhold til alternativene, men var fortsatt den klart vanskeligste teknologien vi jobbet med i forbindelse med backend. Apache Maven Etter å ha arbeidet med det i en periode, og blitt litt mer kjent med mulighetene som tilbys, ble vi forholdsvis komfortable med flyten i Spark, og dro nytte av bibliotekene som var tilgjengelige gjennom Spark. Utregningene ble også ferdige innen en akseptabel tid. Av alternativene som eksisterer per i dag ville vi nok valgt Spark igjen hvis vi skulle arbeidet på et nytt maskinlæringsprosjekt. Maven var intuitivt og det tok forholdsvis liten tid før vi følte oss komfortable med dette verktøyet. Maven gjorde avhengighetsstyringen utrolig lettvint. Muligheten til å legge til en avhengighet bare ved å skrive inn gruppe IDen og artefakt Iden i POMfilen sparte oss mye tid. Det ble også mer oversiktlig når navnet og versjonsnummeret til de forskjellige avhengighetene var samlet i en fil. 63

65 Vi dro også godt nytte av mer avansert funksjonalitet som muligheten til å se hvilke underavhengigheter de forskjellige avhengighetene vi la inn kom med, og muligheten til å legge inn JAR-filer av egne prosjekter. Det første hjalp oss med å rette opp i feil laget av konflikter mellom forskjellige avhengigheter, og det siste med å integrere maskinlæringsprosjektet i back-end. Ansible Maven er absolutt et verktøy vi vil bruke i fremtidige prosjekter. Anisble var ikke en teknologi vi var spesielt fornøyde med. Dette var et verktøy som det var vanskelig å sette seg inn. Guider og dokumentasjon fant vi lite av. Selv med hjelp fra ansatte fra Kantega som hadde brukt det tidligere tok det oss en god stund å få det opp å kjøre. Jenkins Vi har ikke dyp nok kjennskap til andre verktøy som fyller en lignende rolle til å definitivt si at Anisble er vanskeligere å bruke enn de andre, men erfaringene fra dette prosjektet har gjort at vi nok kommer til å prøve et annet verktøy neste gang vi vil automatisere publiseringen av en tjeneste. Jenkins var intuitivt og godt dokumentert. Dette gjorde det let å sette seg inn i og bruke. Siden vi arbeidet med en kunde som for det meste ikke kunne være fysisk tilstedte var det viktig at den nye versjonen av koden vår alltid var tilgjengelig på server slik at den kunne revideres. Jenkens hadde den nødvendige funksjonaliteten for å gjøre dette. En mengde annen funksjonalitet var tilgjengelig for å skreddersy automatiseringen av publiseringsprosessen. Vi valgte blant annet at webapplikasjonen kun skulle publiseres hvis den passerte noen tester vi hadde skrevet. Dette gjør det mulig å sikre en viss kvalitetskontroll. JIRA Neste gang vi jobber på et prosjekt med kontinuerlig integrering kan vi godt tenke oss å bruke Jenkins igjen. Det var en forholdsvis stor investering, i form av tid og energi, for å venne seg til JIRA. I utgangspunktet virket det langt lettere å bare kommunisere over en eller annen form for chat, men etter hvert som det ble mer naturlig å bruke gikk det fort å 64

66 Slack Tomcat H2 Jackson OpenCSV Scala sette opp og fordele nye oppgaver. Oversikten over hvem som gjorde hva, statusen på oppgaven og hva som gjensto å gjøre var absolutt verdt investeringen. Slack gjorde jobben som et kommunikasjonsmiddel for oss i gruppen og mellom gruppen og mentorene. Siden vi brukte Spring Boot kom Tomcat serveren ferdig konfigurert. Vi hadde fryktelig lite direkte interaksjoner med den og har derfor ikke arbeidet oss opp en sterk mening om den. H2 databasen er noe som i Spring Boot i stor grad håndteres automatisk eller gjennom annotasjoner. Vi hadde lite direkte interaksjoner med den og derfor ingen sterke meninger om den. Jackson var godt dokumentert, intuitivt og lett å bruke. Vi testet mange forskjellige CSV parsere og av de vi testet var OpenCSV den eneste som tilbød all funksjonaliteten vi trengte. Dette inkluderte en god måte å håndtere tomme felter, intuitivere navnene til de forskjellige feltene i filene og mappe de til riktig navn. En enkel, hurtig, godt dokumentert CSV parser med god funksjonalitet. Absolutt noe vi kan tenke oss å bruke ved fremtidige prosjekter. Det tok en god del tid å sette seg ordentlig inn i Scala og de tilgjengelige bibliotekene, men vi var veldig fornøyde med utbyttet. Siden vi ikke laget maskinlæringsmodellen skrev vi veldig lite Scala kode, men det lille vi gjorde var en liten åpenbaring. Det vi brukte mange linjer på å gjøre med Java kode kunne i Scala gjøres med en. RESTful API IntelliJ React/Redux Vi fikk ikke utnyttet dette så mye i dette prosjektet men Scala er noe vi godt kan se for oss å bruke i fremtidige prosjekter. RESTful APIer var lette å sette opp i en Spring Boot webapplikasjon og var også godt forklart i flere guider. Dette var en editor vi var godt kjente med fra før og som derfor var intuitiv og lett å bruke. Den tilbød all funksjonaliteten vi trengte. React og Redux er utvilsomt imponerende teknologi som gjør muliggjør dynamiske nettsteder Blandingen av nye programmeringsparadigmer og funksjonell JavaScript og JSX 65

67 Atom IDE HTML/CSS JavaScript Funksjonell programmering Node.js/NPM Læringskurven på dette har vært bratt Intuitiv editor som har et rikt utvalg av nyttige plug-ins. Egner seg svært godt til JavaScript/JSX Dette er teknologier som var godt kjent for oss fra før og som vi mestrer godt. Det var veldig nyttig å lære seg den nye ES6 standarden for JavaScript som introduserer en rekke nye funksjoner og funksjonelt JavaScript Et helt nytt og spennende paradigme for oss som hadde en høy læringskurve. Vi brukte Node Package Manager (NPM) for å håndtere avhengigheter og for testing og kjøring av prosjektet. NPM tilbyr et enormt utvalg av pakker 6.2 Hva kunne vært gjort annerledes? Selv om vi følte oss godt forberedte til dette prosjektet, og aktiv hadde lett etter et prosjekt som lot oss arbeide på noe utfordrende (maskinlæring i dette tilfellet,) dukket det allerede tidlig i prosessen opp ting vi skulle ønske vi hadde gjort annerledes. For store ambisjoner: Som en gruppe på tre personer burde vi nok hatt et langt mer realistisk forhold til hvor vanskelig og omfattende oppgaven vi tok på oss var. Data bearbeiding og domene forståelse er noe som tar lang tid å gjøre på en god måte. Spesielt med data av kvaliteten vi hadde tilgjengelig (i forskjellige formater, mye nullmerker, mye fritekst og dårlig merket felter). Kvaliteten ble vi først klar over når vi fikk overlevert dataene, noe vi ikke fikk før et godt stykke ut i prosjektet, men det hadde allerede gått opp for oss at dette var noe vi ikke kom til å ha tid til. Det samme gjaldt maskinlæring som vi brukte lang tid på å sette oss inn og vi tok kurs online mens vi ventet på de nødvendige dataene. Jo mer vi så på det jo klarere ble det at vi ikke kom til å rekke å lage maskinlæringsmodellen og webapplikasjonen som skulle huse den. På toppen av alt hadde vi valgt å bruke mer eller mindre utelukkende teknologier vi ikke hadde tidligere erfaring med. Etter en samtale med veilederen vår fra HiOA ble det klart at vi måtte kutte ned på omfanget av oppgaven. Vi holdt samtaler med Kantega og Fiskeridirektoratet. Heldigvis var 66

68 veilederne våre villige til å ta på seg databearbeidingen og utviklingen maskinlæringsmodellen. På dette stadiet hadde vi allerede dedikert mye tid til disse tingene, tid som gav oss mye når det kommer til læring, men ingenting når det kommer til resultat. Løsning: Vi burde absolutt ha vært mer realistiske når det kom til egne evner og vært langt mer forsikte med hvor mye vi tok på oss. Spesielt med tanke på at vi ikke hadde jobbet med det før og derfor ikke hadde et grunnlag for å estimere hvor lang tid disse oppgavene ville ta. Dette er en lekse vi har lært for fremtiden vær raus med tidsestimering og gi deg selv lenger tid på å løse enn oppgave enn det du tror du vil trenge, med mindre du har lang erfaring med den typen oppgaver. Klarere spesifikasjoner: Arkitekturen og teknologiene ble bestemt tidlig i prosjektet, og vi hadde en generell ide om hva vi skulle lage. Vi visste hva noe av kjernefunksjonaliteten skulle være og noen av kravene til webapplikasjonen, men vi hadde ikke en liste med spesifikasjoner eller brukerhistorier som var klart definerte og alle partene var enige i. Dette var et problem når vi skulle lage et helhetlig design og førte til at vi arbeidet veldig modulært med funksjonalitet som ble lagt til etter hvert som det ble behov. Det vil nok ikke alltid være at man har en klart definert spesifikasjon å arbeide ut fra i et prosjekt. I så måte var dette en god erfaring med å jobbe på et prosjekt der man ikke har en overordnet spesifikasjon å arbeide ut fra. Vi vil allikevel si at det var en stor mangel i prosjektet å ikke ha en spesifikasjon. Ikke bare var vi usikre i starten av prosjektet på nøyaktig hva Fiskeridirektoratet ville vi skulle lage, men de var også usikker på akkurat hva det var de ville få. Det var ikke før et møte med Fiskeridirektoratet en stund ut i prosjektet vi klarte å bli enige med alle parter om et klart sett med spesifikasjoner. Disse danner grunnlaget for brukerhistoriene listet i denne rapporten og kravene i akseptansetesten. 67

69 Løsning: Vi burde gått hardere inn for å få alt definert skriftlig tidligere slik at vi alle hadde en spesifikasjon vi kunne arbeide ut fra. Denne burde vært klar før arbeidet startet slik at helheten kunne planlegges bedre. 6.3 Måloppnåelse I begynnelsen av dette prosjektet satte vi oss noen mål rundt hva vi ønsket å lære og produsere i løpet av bachelorperioden. Her ønsker vi å se tilbake på disse målene og hvorvidt det endelige resultatet svarer til målene. Resultat I startfasen av prosjekt satte vi oss noen generelle mål for resultatet av prosjektet. Det overordnede målet var å utvikle et produkt alle de involverte partene var fornøyde med. Som målestokk på hvor nært vi kom dette målet bruker vi andel implementerte brukerhistorier samt en liste med krav vi gikk gjennom under en sprint demo med Fiskeridirektoratet. Der viste vi webapplikasjonen og funksjonaliteten som var implementert, og gikk gjennom listen med krav for å sikre oss at de var oppfylt. Tilbakemelding vi fikk etter gjennomgangen av kravene med Fiskeridirektoratet var at vi hadde oppfylt de kritiske kravene. Alle brukerhistoriene som ble vurdert som kritiske ble implementert samt flere av de ikke-kritiske. Vi er veldig fornøyde med å ha klart å gjennomføre alle disse. Måten vi har klart å integrere maskinlæringsmodellen gjennom Spark er vi også veldig fornøyde med. Dette er en funksjonalitet som lett kan bygges videre på og gjenbrukes i andre maskinlæringsprosjekter. Det samme kan gjøres med JSON og CSV leserne vi utviklet. Akkurat dette har vært viktig fra starten av siden vi hele tiden har vist at det er mulig at bare deler av prosjektet vil bli videreutviklet. Dette målet samt målet om å produsere enn webapplikasjon som oppfyller de viktigste kravene og brukerhistoriene mener vi at vi har klart å oppfylle. 68

70 Kvaliteten på maskinlæringsmodellen var også noe vi satte på listen over mål i starten av prosjektet men dette falt til slutt utenfor ansvarsområdet vårt. Det viktigste ble i stedet å sørge for at integreringen av modellen var god. Vi hadde også som mål å lage god dokumentasjon til webapplikasjonen og dette mener vi vi har klart med API dokumentasjon, videreutviklingsguide og en brukerguide. Alt i alt, og basert på kravene, vil vi si oss fornøyde med produktet. Læring Målt i hvor mye vi har lært har prosjektet vært en stor suksess. Vi føler oss rimelig trygge på påstanden; dette er det mest lærerike enkeltstående prosjektet vi har hatt i løpet av studiene. Mye av dette er takket være hvor godt vi ble tatt imot av Kantega. Flere av de ansatte der tok seg tid til å svare på spørsmål, dele informasjon og diskutere problemer vi støtte på underveis. Det tette samarbeidet med to seniorutviklere fra Kantega som fungerte som veiledere på prosjektet var også en konstant kilde til ny kunnskap. I den innledende delen av prosjektet brukte vi tid på å undersøke forskjellige mulige løsningene og teknologiene som var best egnet til å implementere disse løsningene. Vi satte oss inn fordelene og ulempene med de forskjellige alternativene og tok et valg. De teknologiene vi valgte var mer eller mindre alle nye for oss. Dette økte vanskelighetsgraden på prosjektet. Samtidig oppfylte det målene våre om å få en bedre oversikt over eksisterende teknologier og ga oss en dypere forståelse for de vi valgte å gå videre med. Etter refleksjon vil vi påstå at teknologiene vi valgte var godt egnet til å løse oppgavene de satt til. For oss som skal ut i arbeidslivet har erfaringen av å sitte hos Kantega vært uvurderlig. Vi har brukt flere av de samme prosjektstyringsverktøyene og prosessene som de brukere. Slik har vi fått erfart hvordan det er å jobbe på et prosjekt i konsulentbransjen. 69

71 Tidsestimering var noe vi var spesielt interessert i å lære mer om og det gjorde vi virkelig. Her var vi alt for optimistiske i starten og tok på oss større oppgaver enn vi var i stand til å gjennomføre innen den gitte tiden. I fremtiden vil vi nok være mer bevist på at man gjerne bør estimere litt mer tid enn hva man tror man trenger til å løse en gitt oppgave. Vi var også veldig interessert i å arbeide med DevOps og dette gjorde vi gjennom kontinuerlig integrering med testing og publisering av webapplikasjonen. I tillegg til å lære mer om hvordan dette gjøres lærte vi også hvorfor det bør gjøres. I tidligere prosjekter har gruppemedlemmer jobbet for lenge på sine versjoner av løsningen, og når det var tid for å sette den sammen oppstod det ofte konflikter som var vanskelige å løse. DevOps eliminer ikke dette problemet på egenhånd men det var en klar forbedring fra tidligere prosjekt. Målene vi gjerne skulle fått jobbet litt bedre med er Big Data, maskinlæring og prosess dokumenteringen. Big Data og maskinlæring ble et offer for tidspress og selv om vi fikk jobbet en del med det skulle vi gjerne sett at vi hadde kunne tatt ansvaret for implementeringen av maskinlæringsmodellen. Vi kommer på tross av dette fra prosjektet med en betydelig bedre forståelse for hvordan slike modeller lages. Prosess dokumenteringen følte vi var god underveis men den led også under tidsmangel og ble tidvis nedprioritert til fordel for koding. Dette kommer tilbake til tidsestimering og er noe vi vil ta med oss videre. Det fleste læringsmålene vi satte oss ble oppnådd, men ikke alle. Spå tross av det vil vi si oss fornøyde med denne delen. Vi la opp prosjektet slik at prosessen skulle være så lik den man møter på hos et it-konsulentfirma. Dette mener vi vi lyktes med, og vi føler at vi har et langt mer realistisk bilde av hvordan de vil bli å jobbe på et prosjekt som dette i arbeidslivet. 6.4 Videreutvikling Videreutvikling var noe vi tenkte på gjennom hele utviklingsprosessen. Fra starten viste vi at det var mulig hele eller deler av prosjektet vårt ville bli brukt av Kantega i et annet prosjekt de har med Fiskeridirektoratet. Spesielt måten data leveres til applikasjonen kan komme til å endre seg etter hvert som det andre prosjektet blir mer ferdig. Per i dag 70

72 kommer dataene vi bruker fra flere forskjellige databaser som ikke er koblet sammen på en god måte, men etter hvert kan denne dataen bli samlet i en stor database. Hvis det skjer vil den bli kilden maskinlæringsmodellen henter dataene sine fra. Denne databasen er planlagt å benytte seg av et standardisert skjema for melding av avvik ved inspeksjoner. Disse standardene er mer i tråd med behovet til maskinlæringsmodellen enn de eksisterende avviksskjemaene. Det vil også bety at modellen har tilgang til data som oppdateres hyppig. Sammen vil disse endringene bety store endringer i måten dataene brukes av webapplikasjonen og treffsikkerheten til modellen. Hadde ikke tid vært en begrensing og prosjektet applikasjonen vår potensielt skal integreres i vært ferdig ville vi arbeidet videre med følgende funksjonalitet: Økt treffsikkerheten til modellen betraktelig gjennom tilgang til mer og bedre data. Designet en persistent database som hentet dataene direkte fra prosjektet Kantega arbeider med. Lagt til funksjonalitet for å sortere søkeresultater etter hvor høyt de scorer på risikovurdering (altså hvor sannsynlig det er at det gitte fartøyet vil begå lovbrudd). Laget en maskinlæringsmodell for risikovurdering for fiskemottak, og integrert den vurderingen som en faktor i risikovurderingen for fartøy. Dette er for det meste overordnede oppgaver som må deles inn i mindre deler og vil kreve en god del ekstra funksjonalitet. 6.5 Modularitet På grunn av sannsynligheten for at prosjektet vårt i en eller annen form kan komme til å integreres med et annet prosjekt har det vært viktig å utvikle det med dette i tankene. Det vil si at: Vi må skrive forståelig og god kode som det er lett å bygge videre på. Koden må være skrevet slik at det er minimale endringer som må gjøres andre steder i programmet hvis en vilkårlig metode endres. Filene må være små og organisert på en intuitiv måte. 71

73 Det er mulig bare er deler av funksjonalitetene vi har utviklet vil bli tatt med videre, og derfor må de forskjellige funksjonalitetene være så modulære og selvstendige som mulig. 6.6 Konklusjon Bacheloroppgaven vi nå har levert fra oss er ett stykke arbeid vi er meget stolte av og det er et resultat av et tidvis strukturert og godt samarbeid gjennom fem måneder. Vi satte oss tidlig et ambisiøst mål om å strekke oss etter best mulig resultat, både faglig og for våre samarbeidspartnere. Problemstillingen vår var som tidligere nevnt: Kan vi ved hjelp av maskinlæring lage et analyseverktøy som inspektører i Fiskeridirektoratet kan bruke for å planlegge mer effektivt hvor de bør gå på tilsyn?. Som det fremgår av denne rapporten så har vi svart på denne problemstillingen på en tilfredsstillende måte. Vi har laget et verktøy som vil kunne komme Fiskeridirektoratet til nytte. Sett i ettertid burde vi vært mer realistiske når det kommer til arbeidsmengde og vanskelighetsgrad siden det opprinnelige scope trolig lå nærmere en masteroppgave enn en bacheloroppgave. Men dette prosjektet var så interessant at vi ble litt revet med. Det er ikke hver dag man får muligheten til å jobbe med et slikt prosjekt og med de ressursene som Kantega tilgjengeliggjorde for oss. Selv om vi sett i ettertid gapte over for mye har vi hentet mye lærdom i løpet av prosessen som vil være nyttig for oss i fremtidige arbeidsforhold. Vi er stolte av å ha gått inn i dette prosjektet som inneholdt mange nye teknologier og paradigmer som var ukjente for oss og som vi heller ikke har vært innom i studiene. Vi er svært takknemlige ovenfor Kantega, som har tatt oss i mot med åpne armer og vi har følt som ansatte. Vi har fått jobbet med cutting-edge teknologi, både på front-end og backend. I tillegg har vi hatt to svært kunnskapsrike veiledere som har vært av uvurderlig betydning for utfallet. 72

74 7 Vedlegg 7.1 Testdokumentasjon Akseptansekrav Krav Forventet resultat Godkjent Feilet Kritisk Verifiser at alle fartøy radiokallesignal eller navn som stemmer overens, eller starter, med en gitt søkestreng vises i søkeresultatene. Verifiser at ingen fartøy vises i søkeresultater hvis en gitt søkestreng ikke stemmer overens med navn eller radiokallesignal feltene til noen av fartøy i databasen. Verifiser at fartøy med radiokallesignal eller navn som starter med de samme tegnene som de i en gitt søkestreng vises i søkeresultatene. Verifiser at alle fiskemottak med region, godkjenningsnummer eller navn som stemmer overens med som stemmer overens med en gitt søkestreng vises i søkeresultatene. Verifisere at man kan lage en liste over fartøy og mottak man ønsker å se nøyere på. Verifisere at man kan slette fartøy og mottak fra listen med de vi har valgt. Godkjent Alle fartøy med radiokallesignal eller navn som stemmer overens eller starter med søkestrengen vises. X Ja Godkjent X Ja En et tomt søkeresultat vises. Godkjent X Ja Alle fartøy med radiokallesignal eller navn som starter med tegnene i søkestrengen vises i søkeresultatet. Godkjent X Ja Alle mottak med region, godkjenningsnummer og navn som stemmer overens med eller starter med søkestrengen vises. Godkjent Alle fartøy og mottak som velges fra søkeresultatene blir lagt til en liste. X Ja Godkjent X Nei Alle fartøy og mottak som ble forsøkt slettet ble fjernet fra listen. 73

75 Verifisere at man kan videre til en ny Godkjent X Ja side med fartøyene og mottakene som er Alle fartøy og mottak som ble valgt ble lagt til i listen over de man ønsker å se med til neste side. nærmere på. Verifisere at man kan se Godkjent X Ja risikovurderingen til fartøyene man har Alle fartøy som ligger i listen vises lagt til i listen over de man vil se med en risikovurdering. nærmere på. Verifiser at risikovurderinger over 0.7 Godkjent X Nei farges røde for å markere at risikoen er Alle risikovurderinger over 0.7 farges høy. røde. Verifiser at risikovurderinger mellom Godkjent X Nei 0.4 og 0.7 farges gule for å markere at Alle risikovurderinger mellom 0.4 og risikoen er til stedet men ikke høy. 0.7 farges gule. Verifiser at risikovurderinger under 0.4 Godkjent X Nei farges grønne for å markere at risikoen Alle risikovurderinger under 0.4 farges er lav. grønne. Verifiser at riktig navn og Godkjent X Ja radiokallesignal vises for hvert av Navn og radiokallesignal vises i listen fartøyene i listen på risikovurderings slik de forekommer i databasen. siden. Verifiser at en illustrasjon som viser hva Godkjent X Nei fargekodene rød, gul og grønn betyr når En illustrasjon som forklarer at rød risikovurderingen farges i den fargen betyr høy risiko, gul betyr middels vises øverst på risikovurderings siden. risiko, og grønn betyr lav vises øverst til høyre på siden. Verifisere at hvert av fartøyene i listen Godkjent X Ja på risikovurderingssiden siden som har En illustrasjon i rødt med teksten begått tidligere regelbrudd har en «Fartøyet har merknader» vises ved merknad for å illustrere dette for siden av navnet og radiokallesignalet brukeren til fartøyene som har merknader. 74

76 Verifiser at man kan trykke på fartøy Godkjent X Ja elementet i listen og få Hvis fartøy elementet trykkes på åpner tilleggsinformasjon om fartøyet i en en drop down meny seg med tilleggs drop down meny. informasjon som: navn, radiokallesignal, registreringsmerke, lengde, bredde, hvor mange tonn skipet er, eier og risiko. Verifiser at et norsk flagg vises i drop Godkjent X Nei down menyen med mer informasjon om Fartøy som er registrert i databasen et gitt fartøy hvis skipet er norskeid. som norskeide har et norsk flagg øverst i høyre hjørne. Verifiser at en knapp med teksten «Vis Godkjent X Ja merknader» vises i drop down menyen Fartøy som er registrert i databasen hvis fartøyet har tidligere registrerte med tidligere regelbrudd har en knapp regelbrudd. nederst til høyre i drop down menyen med teksten «Vis merknader» Verifiser at et fartøy uten tidligere Godkjent X Nei regelbrudd har teksten «Ingen Fartøy som er registrert i databasen merknader registrert» i stedet for «Vis uten tidligere regelbrudd har teksten merknader» knappen. teksten «Ingen merknader registrert» i stedet for «Vis merknader» knappen. Verifiser at man kan trykke på «Vis Godkjent X Ja merknader» knappen og få opp Hvis «Vis merknader» knappen trykkes tilleggsinformasjon om regelbrudd på åpner en drop down meny seg med begått av det gitte fartøyet i en drop følgende informasjon om fartøyets down meny. tidligere regelbrudd: inspeksjonsnummer, bruddkode, bruddbegrep og avgjørelse. 75

77 Gjennom to møter med representanter fra Fiskeridirektoratet og Kantega utarbeidet vi en liste med kriterier som måtte være klare for at webapplikasjonen skulle aksepteres. 7.2 Sprintdagbok Dette segmentet beskriver de ulike fasene vi gikk igjennom under utvikling av prosjektet. Prosjektet ble delt opp i fem faser 1. Oppstartsfase 2-4. Utviklingsfaser(Sprinter) 5. Dokumentasjonsfase Vi går igjennom fasene i kronologisk rekkefølge og vi reflekterer rundt de utfordringene og de strategiske valgene vi tok underveis i prosjektet. Oppstartsfase Oppstartsfasen startet 5.januar og varte til 25.januar. Det var mange aktiviteter knyttet til denne fasen. Vi hadde på forhånd gjort oss opp noen tanker og hadde en del ideer siden vi vi før oppstartsfasen hadde en kort beskrivelse av prosjektet. Vi fikk prosjektbeskrivelsen i starten av desember 2016 og vi hadde en del kontakt med Ringstad i Kantega. Oppsett av infrastruktur og utviklingsmiljø Vi satte opp to separate utviklingsmiljøer, for front-end og back-end. For å bli ordentlig kjent med økosystemet rundt React og JavaScript valgte vi å sette opp utviklingsmiljøet manuelt, for å bli fortrolig med pakkehåndteringssystemet til Node(Node Package Manager). Dette skulle vise seg å være lurt siden React er tett knyttet mot Node.js moduler (Node.js Foundation, 2017) (React, 2017). Vi var også heldige og fikk tilgang til Kantegas tekniske infrastruktur og fikk dermed mulighet til å ta i bruk en rekke verktøy, teknikker og systemer som av mange ses på som 76

78 bransjestandard. Kantega lagde tre repositories på sin interne GitLab-tjener; for front-end, back-end og maskinlæringsprosjektet (Se punkt 1.2.3). Vi fikk også tilgang til deres interne Slack (Se punkt 1.2.3, Mattermost (Se punkt 1.2.3), Confluence (Se punkt 1.2.3) og Jira (Se punkt 1.2.3). Bruk av kilder og ressurser I den første fasen gikk det med masse tid til å bli kjent med og lære seg en rekke nye teknologier og nye paradigmer. Vi gikk til innkjøp av en rekke bøker som omhandlet teknologiene vi skulle ta i bruk. Men den viktigste lærdommen i denne fasen var trolig det å følge tutorials og utforske rammeverkene ved å lage simple programmer. Det tok lang tid før vi følte vi mestret det å skrive funksjonell JavaScript/JSX og den første tiden føltes ganske frustrerende. Vi baserte oss på informasjon fra følgende kilder Offisiell dokumentasjon. Både Facebooks offisielle React/Redux sider og Java Spring sine inneholder rikelig med god dokumentasjon og eksempler. Diskusjoner, artikler og annen dokumentasjon: Vi benyttet oss av medium.com, som kan anbefales for gode, tekniske artikler av høy kvalitet for spesielt front-end utvikling. Siden vi valgte å utvikle med funksjonell JavaScript var det noe begrenset utvalg av kilder tilgjengelig, trolig fordi det er såpass nytt og til nå lite brukt. Stack Overflow(SO) har vært av uvurderlig betydning, spesielt når det kommer til problemstillinger knyttet til Java Spring og Java Spring Boot (medium.com, 2017) (Stack Overflow, 2017) (Pivotal Software, 2017). Opplæringsvideoer: Vi brukte i stor utstrekning opplæringsvideoer i startfasen. Det finnes tusenvis av timer med video tilgjengelig på en rekke interessante emner som funksjonell JavaScript(ES6), React/Redux, Spring Boot for å nevne noen. Mye av dette er gratis tilgjengelig på YouTube og egghead.io (YouTube, 2017) (egghead.io, 2017) (Pivotal Software, 2017) 77

79 Bøker: Vi gikk til innkjøp av en rekke bøker som omhandlet Java Spring og React. Det var et begrenset utvalg av bøker tilgjengelig til React siden det er relativt nytt, mens det til Redux ikke finnes tilgjengelig litteratur. Sprint 1 Den første utviklingsfasen(sprint 1) varte fra 25.januar til 7.mars og besto av følgende aktiviteter Prosjektinfrastruktur Som tidligere nevnt har vi hatt tilgang til Kantegas infrastruktur, på lik linje med Kantegas tilsvarende prosjekter. Vi hadde noen kriterier vi ønsket for vår prosjektinfrastruktur Separate git repositories for front-end, back-end og maskinlæringsprosjektet. Automatisk testing ved levering av kode til våre git repositories. Automatisk installering av kompilert kode på server for både back-end og front-end. Tilgang til prosjektmiljø utenfor Kantegas kontorlokaler Siden vi har tatt i bruk en del av produktporteføljen til Atlassian var det naturlig å undersøke Atlassians produkter for kontinuerlig integrasjon og leveranse. Vi var også innom Travis, men den ble raskt forkastet fordi det er en sky-tjeneste driftet fra USA og det bryter en rekke punkter i vår kontrakt med arbeidsgiver og kunde (Travis CI, 2017). Til slutt endte vi opp med å bruke Jenkins, hovedsakelig fordi det allerede var et godt driftet Jenkins-miljø på Kantega og at vi dermed hadde god kompetanse på området innenfor rekkevidde. Det gikk med mye tid til å sette opp en såkalt build pipeline for prosjektet vårt, men når det først var gjort fikk vi et svært smidig utviklingsmiljø hvor veien fra commit, test og til leveranse kun tok noen sekunder. En kan jo argumentere at DevOps er alt for komplisert og avansert og dermed helt unødvendig for et prosjekt av vår størrelse, men vi føler likevel det har vært godt anvendt tid da dette har gitt oss kompetanse på et spennende fagfelt som er i rivende utvikling. 78

80 Det har vært spennende å ta i bruk DevOps og det har gitt oss nyttig kompetanse og innsikt i omkringliggende systemer som Jenkins, Linux, git, applikasjons- og webservere. Dette har hjulpet oss å løfte blikket litt og se ting i større sammenheng når man tenker på applikasjonsutvikling. Selv om implementasjonen av DevOps tok mye tid så har det utvilsomt gitt oss et større perspektiv og forståelse for systemutvikling. React Det var utvilsomt denne delen vi gruet oss mest til siden dette var upløyd mark for oss. Vi hadde noe erfaring med Angular 2.x fra tidligere prosjekt og vet hvor vanskelighetsnivået ligger. Vi startet med å lage en designskisse på pair over hvordan vi ønsket av webapplikasjon skal se ut. Ut ifra det tentative designforslaget lagde vi et minimumsforslag for å komme i gang med utviklingen. Vi lagde også hardkodede data for å ha ett datasett å jobbe på. Det gikk også med mye tid til å undersøke og teste react-router, Redux og andre biblioteker/rammeverk for håndtering tilstand og routing. Vi endte til slutt opp med å ta i bruk Redux for tilstandshåndtering. Siden applikasjonen er såpass liten så endte vi opp med å håndtere routing manuelt uten bruk av støtte biblioteker for å unngå unødig kompleksitet. Kombinasjonen av funksjonell programmering, Det å bare lage en enkel, klikkbar komponent skulle vise seg å ta mange uker. Det ble forholdsvis mange nye paradigmer å skulle ta inn over seg på en gang og det tok lang tid før vi kom ordentlig i gang. 79

81 Redux Det er i all hovedsak kombinasjonen av den funksjonelle programmeringen og tilstandshåndteringen som gjør React/Redux komplisert. Den første prosjektperioden gikk med til lære seg teorien bak designmønsteret Flux, som Redux er basert på. Autentisering Det ble bestemt at vi ikke skulle utvikle løsning for autentisering siden denne løsningen kjører bak en brannvegg og således er sikret. Vi hadde i utgangspunkt ønsket å implementere brukerhåndtering med autentisering ved hjelp av JSON Web Tokens (Internet Engineering Task Force (IETF), 2015) Java Spring Etter å ha gått nøye gjennom guidene og dokumentasjonen ble valget om å bruke Spring Boot tatt. Dette virket å være det rammeverket som stemte best overens med våre behov. Vi var godt kjent med Java fra tidligere prosjekter og det er det språket vi anser at vi mestrer best. Utover oppsett av prosjektmiljøet gikk det med en del tid til å lære seg Maven og håndtere prosjektavhengigheter. For å bli mer kjent med rammeverket brukte vi mye tid på dokumentasjonen til Spring, som er svært god og omfattende (Pivotal Software, 2017). Store deler av back-end designet var avhengig av hvilke data, hvor mye data og hvor godt merket de var (metadataene). Siden det gikk en stund før vi fikk tilgang til alle dataene vi hadde bruk for gikk det også en stund før vi kunne lage et komplett design. I mellomtiden ble det bestemt at et enkelt back-end prosjekt der data kunne aksesseres i en database gjennom et endpoint. Etter hvert som dataene ble tilgjengelige, noe som skjedde i stadier, ble Java objekter designet basert på hvilke data som var relevante for oss. Endpoint ble laget for å servere dataene videre i første omgang var det data om fartøy som ble sendt. Det ble også bestemt at et testrammeverket skulle settes opp for back-end og noen enhetstester skulle skrives i denne fasen av prosjektet. 80

82 Figur 26 Eksempel på Jira-task 81

83 Figur 27 Eksempel på Jira-task Database Designet av databasen var, i likhet med back-enden, en prosess som tok tid og krevde flere endringer underveis på grunn av den gradvise tilgangen til de relevante dataene. Det ble bestemt at en persistent MySQL database skulle lages og tabeller opprettes etter hvert som behovet oppstod. Maskinlæring Maskinlæringsdelen av prosjektet ble ledet av Qvigstad hos Kantega. Den første tiden gikk med til å innhente domenekunnskap og opprette forbindelse med brukeren; Fiskeridirektoratet. Vi fikk tidlig tilsendt et datasett, men dette var av svært dårlig kvalitet og nesten helt uten metadata. Qvigstad i Kantega jobbet opp mot Fiskeridirektoratet for å opprette kontakt og sikre oss de nødvendige dataene. 82

84 Scope På dette tidspunktet hadde vi fortsatt et scope som innebar utvikling av front-end, back-end og maskinlæring/big-data. Det svært vide og store scopet i starten gjorde at vi brukte mye tid på tematikk som senere ble fjernet fra scope. Det endelige scopet ble definert etter workshop med alle involverte i starten av mars (Se punkt 1.2.3). Sprint 2 Det var en del oppgaver som ble forskjøvet inn i Spring 1, men i denne fasen hadde vi omsider kommet ordentlig i gang. React/Redux Nå hadde vi tilegnet oss tilstrekkelig kunnskap til å lage enkle komponenter og kople disse sammen. Dermed gikk vi i gang med å skissere grovt hvordan vi ønsket at applikasjonen skulle se ut og hvilke komponenter vi ville trenge. Komponentene utgjorde: Søkeside. Side hvor brukeren søker etter objekter (fartøy eller fiskemottak). Denne siden fungerer også som en startside. Resultatsiden. Side med oversikt over søkeresultatene. På denne siden får man oversikt over risikoen som er beregnet for hvert objekt. Det er også mulig å få ut informasjon om objektene. Detaljsider. Flere sider som tilbyr detaljer om objektene. Søkefelt Det å kunne søke etter et objekt i databasen og kunne se resultatet var en milepæl i prosjektet. Det fordret en fungerende back-end som kunne levere data via et REST endpoint og et søkefelt som kunne sende et asynkront kall og behandle dataene som kommer i retur (Schreier, 2011). 83

85 Figur 28 Søkefeltet i applikasjonen Vi implementerte en dynamisk dropdown liste i søkefeltet. Når søkefeltkomponenten blir renderet henter den en liste fra vår Spring back-end med alle objekter som har rapporteringsplikt til Fiskeridirektoratet. Brukeren får da mulighet til å velge en eller flere objekter i listen og snevre inn søket ved å taste inn i søkefeltet. Det er også mulig å fjerne valgte objekter og oppdatering av grensesnittet skjer dynamisk og håndteres automatisk av React ved endring av tilstand (Se punkt for produktgjennomgang for mer informasjon) (Facebook, 2015). Figur 29 Eksempel på JavaScript-kode for API-kall til back-end (Ved bruk av Promises) Denne funksjonaliteten var svært tidkrevende å få til og det føltes som et stort gjennombrudd når den var på plass i slutten av Sprint 2. 84

86 Refaktorering Siden vi var uerfarne med utvikling i React/Redux gikk det med mye tid til refaktorering av koden. Og vi gjennomførte flere totale refaktoreringer av hele kodebasen. Etterhvert som vi lærte nye kodestandarder og beste praksiser som dekorering av komponenter ved hjelp av første ordens funksjoner og skille mellom presentasjons- og kontainerkomponenter ble disse implementert. I tillegg var veileder veldig hands-on og utførte kodegjennomgang. Den strenge policyen vedrørende kodekvaliteten vi var pålagt var svært nyttig, sett i ettertid. Selv om den til tider føltes unødvendig streng og til hinder for progresjon Selv om den strenge policyen vedrørende kodekvalitet til tider føltes unødvendig streng og til hinder for progresjon, var den svært nyttig, sett i ettertid. Den tvang oss til å etterstrebe en høy standard på koden og at koden vår ble sendt i retur med merknader, var mer regelen enn unntaket. Figur 30 Skjermbilde fra versjonshåndteringssystemet Gitlab. Denne viser kommentar på kode etter kodegjennomgang av veileder Fiskeridirektoratet Vi hadde en veldig nyttig workshop med Fiskeridirektoratet sammen Kantega. Det ble en verdifull informasjonsutveksling og vi fikk mye større forståelse for de dataene vi allerede 85

87 hadde fått. Vi fikk også spesifisert hvilke data vi ønsket tilgang til og dette tok Fiskeridirektoratet med seg til sin IT-avdeling for uttrekk. Spring Boot På grunn av behovet for å lese data inn ved oppstart gikk mye tid med til å designe gode parsere for dataformatene vi forventet å jobbe med CSV og JSON. I tandem med en databaselaster som kjørte ved oppstart ble det lettvint å legge nye data til prosjektet. Det å finne et bibliotek for CSV formatet som passet våre behov viste seg å være vanskelig, spesielt utfordrende var det at CSV filene vi hadde brukte forskjellige skilletegn noe som ingen av de tilgjengelige bibliotekene i Java hadde en god løsning på. Etter å ha testet flere biblioteker fant vi et som gjorde jobben vi ønsket, men vi måtte fortsatt lage noen Python script som gikk gjennom filene og produserte nye med en uniform skilletegnstandard. Vi mottok data om fiskemottak og laget funksjonalitet samt endpoint for denne dataen. I tillegg ble det bestemt at det, siden utviklingen av maskinlæringsmodellen for risikovurdering tok tid, skulle lages en mock av risikovurdering (et tilfeldig generert siffer mellom 0.1 og 1.0) og et endpoint dere denne vurderingen kunne aksesseres. Database Siden vi i denne perioden fortsatt mottak nye data og metadataen av eksisterende data fortsatt ikke var helt klar ble vi enige om at det var for tungvint å gjøre designendringer i database kontinuerlig. I tillegg måtte dataene laste inn på nytt hver gang endringer ble gjort for å reflektere disse endringene. Det ble bestemt at den eksisterende persistent MySQL databasen skulle erstattes med en in-memory database som lastet inn dataene fra filer ved oppstart og slettet de når den ble slått av. Dataene ble mappet til Java objekter som også fungerte som grunnlag for databasetabellene. 86

88 Sprint Demo 1 I slutten av hver sprint har vi i utgangspunktet tenkt til å ha en sprint demo. Her viser vi ny funksjonalitet til kunden og får tilbakemelding på dette arbeidet. I samarbeid med kunden velger vi også ut hvilken funksjonalitet vi skal prioritere i neste sprint. I denne demoen hadde vi Fiskeridirektoratet med på videokonferanse og vi demonstrerte i hovedsak søkefeltet. Vi viste også noen skisser og delte noen tanker om hvordan vi skal presentere risikoen knyttet til hvert objekt. Domenemodell Etter den første sprintdemoen utvidet vi applikasjonen ved å inkludere fiskemottak på land etter forespørsel fra Fiskeridirektoratet. Det første datauttrekket vi fikk fra Fiskeridirektoratet inneholdt kun fartøy. Vi lagde derfor en ny og mer generisk domenemodell som støtter både fartøy og mottak. Dette medførte en større refaktorering av kodebasen i front-end. Sprint 3 Redusert produktivitet Etter påskeferien sank produktiviteten noe. Det var mange faktorer som spilte inn her. To av gruppens medlemmer var i en jobbsøkerprosess. En prosess som var langt mer krevende både tidsmessig og mentalt enn tidligere antatt. Når gruppens medlemmer hadde skrevet kontrakter med arbeidsgivere gikk det også med noe tid til. Når arbeidskontrakter var inngått gikk det også med en del tid til forberedelser for oppstart. Dette sammen med noe uklare mål gikk kraftig ut over prosjektet mot slutten. Det ble totalt tre sprinter i dette prosjektet. 87

89 React/Redux Den siste utviklingsperioden ble brukt hovedsakelig på en stor refaktorering og implementasjon av mindre funksjonalitet som navigasjonshjelp, visualisering av skipsstørrelse og feilretting. Vi brukte også mye til på å implementere selectors. Det er såkalte memoization selekteringsfunksjoner som er funksjoner som har som oppgave å sortere data hentet fra Redux store. Disse funksjonene mellomlagrer resultater og er svært effektive. Dessverre rakk vi ikke å merge inn selectors i hoved-treet i git (Facebook, 2017). Figur 31 Deler av kode for en memoized selector som sorterer data fra Redux store Back-end Fokuset i denne sprintperioden var integreringen av den ferdige maskinlæringsmodellen. Det ble bestemt at modellen skulle integreres inn i selve prosjektet ved hjelp av Maven. Det å introdusere et av våre prosjekt som et en avhengighet inn i et annet viste seg å være en mer utfordrende oppgave enn først antatt. Mye på grunn av konflikter mellom avhengigheter i de to forskjellige prosjektene. De neste stegene var å bruke Spark til å prosessere dataen, kalle de nødvendige metodene fra maskinlæringsprosjektet, og prosessere dataene vi fikk i retur. Dette var som forventet en komplisert prosess og det tok oss mye tid å gjøre på en god måte. 88

90 Figur 32. Et bilde av Jira oppgaven om å lage en tjeneste i back-end som laster brudd_classification (risikoanalysen) fra maskinlæringsmodellen med de nødvendige dataene. Maskinlæring Maskinlæringsmodellen ble ferdigstilt av våre Kantegaveildere i denne sprintperioden. Gruppen har gjennom hele prosjektet prøvd å holde oss relativt oppdaterte på hvordan modellen var bygget opp, men mye hadde skjedd på kort tid og vi måtte bruke en del tid på å gå gjennom koden slik at vi ville være i stand til å bruke den. Det var nødvendig med en inngående kjennskap til de forskjellige metodene og gangen i modellen slik at vi hadde oversikt over hvilke metoder vi måtte kalle og hvilke parametere og retur data vi måtte forholde oss til. Sprint Demo 2 I den siste sprintdemoen fremviste vi et nokså ferdig produkt for kunden og vi gikk igjennom funksjonaliteten. Vi brukte også en del tid på å forklare og diskutere maskinlæringsalgoritmens prediktive kvaliteter og hvilke data som hadde vært nyttig som input i en slik algoritme. 89

91 Siden tidsskjemaet til samtlige involverte parter har vært under press har det ikke vært mulig å finne et tidspunkt for å gjennomføre en formel akseptansetest. Derfor utførte vi denne sprintdemoen som en uformell akseptansetest hvor vi gikk igjennom all funksjonalitet i applikasjonen. Tilbakemeldingene fra kunde var god og det var i all hovedsak detaljer på utseendet og plassering av elementer vi fikk kommentarer på. Kunden utrykte et ønske om visualisering av skips størrelse og dette implementerte vi i etterkant av møtet. Totalt sett var de fornøyd og de aksepterte vårt produkt. Dokumentasjonsfasen Den siste fasen i prosjektet var dokumentasjonsfasen og den varte fra midten av mai til innleveringsfrist 24.mai. Vi tok utgangspunkt i kompendiet for dokumentasjonsstandard (HiOA) når vi skrev dokumentasjonen for prosjektet, dog med noen tilpasninger som vi følte var nødvendige å dokumentere. Vi fordelte oppgaver innen dokumentasjon ut i fra hvilke områder av prosjektet man var mest fortrolig med. Det har vært utfordrende å skulle dokumentere et så stort prosjekt som dette da vi ikke har erfaring med et såpass stort og komplekst prosjekt som dette er og vi har etter beste evne prøvd å få dekket alle relevante momenter i prosjektet. 7.3 Prosjektdagbok Møte med Alfred Bratterud Vi ble først presentert en mulig bacheloroppgave i samarbeid med Pillbox eller IncludeOS Søknad 90

92 Vi kjente at det fortsatt var tidlig å fastslå en oppdragsgiver for bacheloroppgaven så vi tok sjansen og sendte ut søknader til flere private og offentlige bedriftssektorer. Vi ville søke et bredere spekter av potensielle oppdragsgivere for å ikke utelukke gode alternativer så tidlig i søknadsfasen Intervju med Accenture Vi ble innkalt til intervju med Accenture og det ble ikke spesielt vellykket. Men vi ble en erfaring rikere Intervju med Iterate/Torve Indahl og Kim Ophus Leskovsky Det var et svært positivt møte hvor vi ble presentert for prosjektet WoolIt og en mulig bacheloroppgave. Her ble det avtalt nytt møte neste fredag kl. 13 ved formiddagen hvor vi skal presentere våre innledende resultater. Figur 33 Brainstorming fra møtet med Iterate 91

93 Diskusjon om potensielle oppdragsgivere Herfra fikk vi svar fra søknadene vi sendte tidligere og de fleste var positive, men vi fikk også noen avslag. På dette møtet ble det diskutert rundt prosessen med å finne den potensielle oppdragsgiver til vårt bachelorprosjekt og hvilke temaprosjekt og bedrift som virket mest spennende og aktuelt for oss Møte med Bekk Consulting AS Møte med Bekk/personalansvarlig Anders Hefre på Espresso House Aker Brygge. Det var et hyggelig møte med god stemning. Anders Hefre så ut til å like ideen vår veldig godt som vi foreslo i søknaden vår. Men det var et temaprosjekt hvor han måtte senere ta kontakt med ledelsen i selskapet for å kunne gi oss ett godt nok svar på et samarbeid med oss Innlevering av statusrapport Produserte en kortfattet statusrapport for HiOA Forberedelse til møte med Iterate Til forberedelse for neste møte med Iterate valgte vi å engasjere oss i å lage et mock-up av en foreslått ide av WoolIt-prosjektet som vi fikk tilbudt av Iterate og utførte noen brukertester på en lo-fi prototype. 92

94 Figur 34 En lo-fi prototype av en webapplikasjon for Iterate Forberedelse for presentasjon Iterate Det ble oppmøte dagen før for å lage et utkast til presentasjonen for Iterate Møte med Iterate Kl Møte med Iterate/Torve Indahl og Kim Ophus Leskovsky. Her holdt vi presentasjon for Iterate som handlet om undersøkelsen vi gjorde av brukertestingen og pratet om hvilke muligheter som ligger bak en bacheloroppgave i samarbeid med Iterate. Iterate likte vår framgangsmåte og var positivt overrasket på hva vi fikk ut av undersøkelsen. Det ble avtalt nytt møte med deres utviklere om to uker for å diskutere videre angående «virtual dressing room». Kl Bekk avslo vår søknad grunnet ressursmangel og dermed står vi igjen med Iterate som oppdragsgiver Intervjuinnkallelse fra Kantega AS 93

95 Svar på søknad i mail viste seg at Kantega AS var interessert i et møte med oss mandag 7.november. Vi hadde ikke skrevet under kontrakt med Iterate ennå, dermed bestemte vi oss for å ta denne unike sjansen for å se hvilke spennende prosjektoppgaver Kantega kunne tilby oss Første møte med Kantega AS Vårt første møte med Kantega AS var med deres avdelingsledere Hans Ove Ringstad og Abid Ali Teepo. I løpet av søkeprosessen på en bacheloroppgave med bedrifter tidligere har det ført med seg erfaringer og dyktighet på intervjutiltredelser. Vi stilte positivt på intervju og fikk vite alternative områder som vi kunne tenkt å fordype i en bacheloroppgave hos Kantega Avslagsbrev til Iterate AS Oppgavene som ble tilbudt av Kantega virket svært spennende og interessante og vi visste at dette var noe vi brente for. Dermed bestemte vi oss for å skrive et avslagsbrev til Iterate AS Avtalt oppstartstid av prosjekt med Kantega Vi fikk en prosjektbeskrivelse over mail og en samarbeidspartner å se frem til Oppstart av prosjektet med Kantega AS og Idémyldring Henrik Qvigstad og Heidi Mork ble presentert som våre to veiledere for bachelorprosjektet. Kompetansebakgrunn og fagfelt blant ulike medlemmer ble introdusert. Prosjektbeskrivelsen ble diskutert med idemyldring og eventuelle spørsmål ble tatt opp i møtet Kontrakt med Kantega AS 94

96 Da fikk vi endelig signert en skriftlig avtale med Kantega om å være samarbeidspartnere for bacheloroppgaven vår Første planleggingsmøte En felles prosjektplanlegging ble gjennomført sammen i teamet hvor vi diskuterte om tilgjengelige ressurser, antall personer til rådighet, teknologier som skal brukes, mulige risikofaktorer som kan oppstå underveis, håndtering av sikkerhet, og type arbeidsmetodikk som skal gjennomføres Forberedelse på møte med kunde Vi trengte et felles oppmøte for å finne ut av hva vi kunne få til i første møtet med Fiskeridirektoratet på mandag 23. januar Første møte med Aiko Vårt første møte med veileder Aiko Yamashita fra HiOA fantes sted ved Mesh Work Lounge café. Vi formidlet nåværende prosjektsstatus til Aiko og hvordan vi tenkte å løse oppgaven med Kantega som samarbeidspartner. Vi fikk sterk kritikk om å gjøre oppgaven enda smalere med tanke på at vi hadde tenkt å implementere maskinlæring sammen med en webapplikasjon innenfor den korte tidsrammen vi hadde til rådighet. Møtet med Aiko var svært oppsiktsvekkende og vi måtte snarest ta kontakt med vår oppdragsgiver om å gjennomføre kun en av delene Første møte med Fiskeridirektoratet Møtet med kundens representanter foregikk hos Kantegas møterom. Det ble holdt en god tone under hele møtet og de så ut til å være fornøyde med forberedelsen som vi hadde å tilby dem om våre ideer rundt prosjektet. En 95

97 kravspesifikasjon ble diskutert og det ble tatt hensyn til å spisse oppgaven mer til et smalere område med tanke på tidsramme og realistiske mål. Etterpå ble det middag med kunden som var meget koselig Sprint 1: Dagligmøte Vi begynte å designe kravspesifikasjonen i vår første sprintplanlegging. De funksjonelle kravene i front-end og back-end. Vi fikk i tillegg tatt en prat med en av senior utviklerne, Torstein Strøm, som ga oss informasjon om Fiskeridirektoratets API er og på grunn av sikkerhet måtte vi høre med kunden om de tilgjengelige dataene. Arbeidsoppgaver ble tildelt medlemmer og lagt inn i Jira. Figur 35 Skisse 96

98 Figur 36 Skisse Dagligmøte med veileder Det ble enighet i teamet at vi skulle ha dagligmøter ofte. Alle dagligmøter måtte gå gjennom samme rutinespørsmål for alle medlemmer: «Hva gjorde du i går?», «Hva sto du fast på?», «I så fall, hva skal du jobbe med nå?». Hensikten med en slik rutine var å produsere noe programmeringskode hver dag. Det ble arbeidet med søkefunksjonalitet i React og søking på best practice for dette. En Lint kodestandard ble lagd for prosjektet. Satte opp en database og end-point der filtrerte data fra en JSON-fil med fiskebåter kunne aksesseres, og ferdigstilte mapping av data fra filen til et Vessel objekt. Veileder Henrik Qvigstad gjorde søk på Scala og andre teknologier rundt maskinlæring Dagligmøte med veileder Ferdigstilte arbeidet med en Jenkins on pipeline for backend. Arbeidet med front-end og raffinering av søkeprosessen. Startet arbeid av backend entrypoints og tilhørende funksjonalitet. 97

99 Dagligmøte med veileder Arbeidet med Select view og tilhørende funksjonalitet og debuggings funksjonalitet. Arbeidet med en mock risk assesment ble startet. Startet testing for backend. Et foreløpig utkast til layout ble forslått i grensesnittet for front-end Dagligmøte med veileder Ferdigstilte arbeidet med testingen og arbeider med exception handling. Satt oss inn i Swagger. Muligheten for å bruke Swagger til å generere back-end endpoints og dokumentasjon ble diskutert, og det ble bestemt at vi skulle ta en diskusjon sammen med personell fra det tilhørende Saga prosjektet for å ta en avgjørelse rundt dette Dagligmøte med veileder Ferdigstilte arbeidet rundt testing i back-end. Pipelines ble satt for automatisk testing i GitLab (Continuous Integration). Kantegas Jenkins server brukes til continuous integration (CI) Dagligmøte med veileder Ferdig med automatisk testing i GitLab (Continuous Integration). Satt opp inmemory database Dagligmøte med veileder 98

100 Arbeidet med å legge ekstra funksjonalitet til Vessel-object på backend og opprettet kobling med front-end viewene. Viktigheten av å holde seg innenfor oppgavebeskrivelsen gitt i Jira ble diskutert og presisert Dagligmøte med veileder Det ble nå enda mer fokus på å programmere kode i front-end. Forberedelse på midterm presentasjon Møte med Heidi Heidi Mork er vår andre veileder og kommer innom kontoret av og til når hun har mulighet. I møtet med Heidi Mork ble det diskutert om maskinlæring og data. Det har vært en stor utfordring å få tak i de riktige dataene fra Fiskeridirektoratet. Det ble avtalt et nytt møte 6.mars med Fiskeridirektoratet Dagligmøte med veileder Få orden på strukturene presentational og container components. En prioriteringsliste: 1. Å legge RiskAssesment i VesselKomponent. 2. Expand vesselkomponent View. Bruddtabell i FDIRML-data ble opprettet Dagligmøte med veileder Visualisering av en risikoverdi prioriteres og korrigeringer ble tatt opp. Møte med Fiskeridirektoratet og avslutning 99

101 Vår veileder holdt en presentasjon om forslag på en maskinlæringsmodell for kunden. Det ble da ikke valgt en modell enda fordi det er mange faktorer og aspekter å ta hensyn etter. Håpet på å ha klart en modell om etter et par uker. Denne modellen bør da være klar for plugin med backend. Når det gjaldt front-end så fikk vi en del søkekriterier fra kunden: Fartøygruppe Mottaker Beredskap Kobling mellom fartøy og landingssted (ingen datasett for dette) Kvantum Art Håndtering og prioriteringer mellom to høye risikoer. Tidspunkt for det siste bruddet? Avslutning av sprint 1 Vi avsluttet første sprint med demo, code review og retroperspektiv Midtveispresentasjon Det ble gjennomført midtveispresentasjoner av bachelorgrupper med Aiko på skolen. Presentasjonene skulle gi et klart bilde på hva de ulike bachelorgruppene hadde valgt som prosjektoppgave Tilbakemeldinger om midtveispresentasjonen Dagen etter midtveispresentasjonen hadde vi et møte med Aiko. På dette møtet fikk vi tilbakemelding om vår presentasjon og om selve 100

102 bacheloroppgaven. Det var et positivt møte hvor vi fikk tips og råd til elementer vi burde fokusere videre i utviklingen og i rapportskrivingen Sprint 2: Dagligmøter Da var vi kommet til andre sprint som gikk ut på søk og valg av fartøysliste. I vår andre sprintplanlegging så hadde vi også lyst til å søke etter mottak i front-end Dagligmøte med veileder Det ble laget en mock-up som illustrerer et søkefelt som kan håndtere søk på både fartøy og mottak Dagligmøte med veileder Arbeidet med å hente data fra 2 endpoints: Mottak og vessel. Det ble laget visualisering av fartøyenes tonnasje. Planlegging av flere funksjonaliteter i front-end Møte med Fiskeridirektoratet Det var ønskelig av kunden å ha flere nye funksjonaliteter i webapplikasjonen: Sortering etter lav, normal, og høy risiko. 101

103 Knytte havn med region. Sortering etter navn, prediksjon top 10 kandidater. Hvilke faktorer som kan gi høy risiko. Sprint 2 avsluttes med code review, demo og retroperspektiv Start på sprint 3: Dagligmøter Ny runde med sprintplanlegging med ny funksjonalitet til det gamle Møte med Aiko Vår siste fysiske møte med Aiko foregikk på et av skolens møterom. På møtet fikk vi tilbakemeldinger på rapportskrivingen, blant annet på hva vi skulle endre og hva som kunne gjort bedre Siste dag med Kantegas veileder Siste daglig møte med veileder Henrik Qvigstad, grunnet utplassering til et nytt jobbprosjekt. Her ble det laget en realistisk plan for den resterende måneden med utvikling uten veileder tilstede. Selv om veilederne våre var opptatte den siste tiden så var de tilgjengelige på Slack og Mattermost Sprint 3 avsluttes 102

104 Det ble gjennomført en demo, testing, og retroperspektiv Akseptansetest Det ble utført en akseptansetest med Fiskeridirektoratet Rapportskriving I denne perioden ble det bare fokus på rapportskriving. Alt som vi produserte og gjennomførte i prosjektet med Kantega og Fiskeridirektoratet ble dokumentert ned i rapporten Rapport 1. Utkast Vi leverte første utkast av rapporten over mail til Aiko. Mens vi ventet på svar fortsatte vi likevel med rapportskrivingen, spesielt på rapportstrukturen som vi visste trengte mer omstrukturering Tilbakemelding fra Aiko Vi fikk tilbakemelding av rapportens første utkast over mail. Det var en god del som måtte fikses opp i rapporten og vi satte stor pris på tilbakemeldingen fra Aiko Siste arbeid På den siste tiden som var igjen ble det dedikert arbeid for å ferdigstille rapporten. Det ble gjort små finpuss på språket og vi måtte gå gjennom hele rapporten i fellesskap noen ganger før vi sa oss fornøyde. Rapporten var dermed klar til innlevering. 103

105 7.4 Brukermanual Forord Denne brukerveiledning er tiltenkt alle som har tenkt til å ta i bruk FDir-ML. En grunnleggende forståelse for bruk av pc og internett forutsettes, samt kunnskap om fiskeri- og havbruksforvaltning. Figur 37 Førstesiden på applikasjonen På applikasjonens førsteside blir vi presentert for et søkefelt. Søkefeltet er dynamisk og begynner søket så fort man skriver i feltet, som vist i figur

106 Figur 38 Søk i applikasjonen Applikasjon søker blant alle registrerte fartøy og fiskemottak. Man velger objekt ved å klikke på navnet. Figur 39 Oversikt over valgte objekter Man kan fjerne valgte objekter ved å trykke på x-merket. Grensesnittet vil da oppdateres automatisk. For å beregne risiko på det valgte objektet trykker man på den blå knappen. 105

107 Når man har trykket Select Items så vil de valgte objektene bli risikoberegnet i back-end. Resultatet oppdateres dynamisk i grensesnittet. I dette bildet vil risikoen for hvert objekt bli presentert i en egen knapp helt til høyre i bildet. Figur 40 Detaljert oversikt over objekt med risiko I dette skjermbildet kan man velge å se flere detaljer på hvert valgt objekt, som vist i figuren over. Her ser man informasjon som objektets navn og spesifikasjoner som lengde, bredde og vekt. Hvis et objekt er registrert med tidligere lovovertredelser som har ført til anmeldelse eller andre reaksjoner vil dette bli kommunisert til bruker ved en knapp. 106

108 Figur 41 Visuelt hjelpemiddel Vi har laget et visuelt hjelpemiddel slik at det skal være enkelt å oppfatte risikoen på hvert objekt umiddelbart. Figur 42 Figuren over viser et objekt som har en tidligere lovovertredelse og derfor blir markert med en stor rød knapp med beskjeden; Fartøyet har merknader. Da kan brukeren vise detaljene til objektet og trykke på Vis merknader, som vist i figuren under. 107

109 Figur 43 Objekt med tidligere brudd på regelverk Her ser vi et skjermbilde med et objekt og dets overtredelser som inspektørene kan få frem kun ved få trykk, noe som er en radikal forbedring målt opp mot dagens situasjon. 108

110 7.5 Publiseringsmanual 109

111 7.6 Dokumentasjon av API 110

112 111

113 112