Forprosjektrapport Hovedprosjekt for gruppe 26, våren 2017 Terje Leirvik, Crystal Kim-Phuong Tran og Jan Andre Slettebakk Høgskolen i Oslo og Akershus
Innholdsfortegnelse Forprosjekt FDir-ML... 3 Prosjektgruppe... 3 Oppdragsgiver... 3 Om oppdragsgiver... 3 Om Fiskeridirektoratet... 3 Kontaktperson... 3 Intern veileder... 3 Ekstern veileder... 3 Prosjektbeskrivelse... 4 Prosjektets hovedbestanddeler... 4 Teknologi og rammeverk... 5 Prosjektkrav... 5 Teknologier og avhengigheter... 5 Arkitektur... 5 Front-end... 6 Back-end... 6 Maskinlæring... 6 Versjonshåndtering... 6 DevOps og Continuous Delivery/Integration... 7 Arbeidstider... 7 Prosjektmetodikk... 7 Prosjektstyringsverktøy... 7 Taushetsplikt... 8 Risikomatrise... 8 Fremdriftsplan... 9 Oppsummering... 12 Bibliografi... 13 2
Forprosjekt FDir-ML Prosjektgruppe Terje Leirvik, s23672@stud.hioa.no Crystal Kim-Phuong Tran, s178511@stud.hioa.no Jan Andre Eikrem Slettebakk, s166903@stud.hioa.no Oppdragsgiver Kantega A/S Kirkegata 5 0153 Oslo Om oppdragsgiver Kantega er et ansatteid IT-selskap med i overkant av 100 medarbeidere som leverer innovative IT-løsninger som innfrir høye krav til brukervennlighet, funksjonalitet, sikkerhet og ytelse til blant annet Norges største bank, forsikring, industri, handel og offentlig sektor. Kantega er blant Norges fremste eksperter på systemutvikling på Java-plattform og er en aktiv bidragsyter i det norske Java-miljøet og er aktive på konferanser som JavaZone(partner). Om Fiskeridirektoratet 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. Kontaktperson Hans-Ove Ringstad, hans.ove.ringstad@kantega.no Intern veileder Aiko Yamashita, Førsteamanuensis HiOA, aiko.yamashita@hioa.no Yamashita jobber innen empirisk software engineering, med spesielt fokus på kodekvalitet og software evolution (Yamashita, 2016). Ekstern veileder Heidi Mork / Henrik Qvigstad 3
Prosjektbeskrivelse Analyseverktøy med maskinlæring for Fiskeridirektoratet Målet for dette prosjektet er å lage et analyseverktøy i samarbeid med Kantega som inspektører i Fiskeridirektoratet kan nyttiggjøre seg av for å planlegge hvor de bør utføre tilsyn. Den overordnede problemstillingen vi arbeider med er som følger: Hvordan kan vi, ved hjelp av maskinlæring, gjøre risikovurderingen av forskjellige typer objekter som fiskebåter, oppdrettsanlegg og mottak lettere for fiskeridirektoratet slik at de kan rette ressursene sine dit sannsynligheten for brud på sentrale regler er størst? Risikovurdering i dette tilfellet referer til sannsynligheten for å finne avvik fra regelverket ved de nevnte objektene. Fordelene ved en slik løsning er primært evnen til å identifisere objekter som burde inspiseres basert på risikovurderingen. Sekundært kan den avsløre hvilke faktorer som øker sannsynligheten for at et objekt avviker fra reglementet. Dette kan igjen brukes til å fortelle inspektører hvilke spesifikke faktorer de bør undersøke nærmere. Den foreslåtte løsningen er todelt: Vi utvikler en maskinlæringsalgoritme som, ved hjelp av lærings- og testdata, vil kunne utføre en risikoanalyse og tillegg de forskjellige objektene en vurdering. Vi utvikler en webapplikasjon der brukerne (inspektører og administratorer hos Fiskeridirektoratet) gjennom et brukergrensesnitt får tilgang på og kan arbeide med algoritmen. Prosjektets hovedbestanddeler Datainnsamling og utforskning: I denne perioden vil vi jobbe med å identifisere hvilke data som er tilgjengelig og ut fra det filtrere ut data som er av relevans for oss. Bearbeide data og oppdatere eller sette mål, delmål, hypoteser og tidslinjer basert på dette: I denne perioden vil vi samarbeide med domeneeksperter hos Fiskeridirektoratet og Kantega for å utarbeide delmål, brukerhistorier og sprinter. Et av de viktigste spørsmålene som må besvares i denne perioden er omfanget hvor altomfattende skal algoritmen være. Hvis tiden ikke hadde vært en faktor hadde det nok vært ønskelig at den skulle kunne brukes på flere forskjellige typer objekter og at den i tillegg til risikoen for et avvik fra forskriftene også tok hensyn til konsekvensen av det gitte avviket. Siden tid i dette tilfellet er en faktor ser vi på det som ønskelig å begrense så mye som mulig. Det vil si at vi i første omgang lager en algoritme basert på en type objekter og ser bort fra konsekvensen av avviket. Det blir da viktig å legge til rette for at algoritmen senere kan utvides slik at kan legge til den hvis vi får tid eller at andre kan gjøre det senere hvis de ønsker å fortsette prosjektet. 4
Hvilken type objekter og egenskaper som skal prioriteres vil vi utarbeide i samarbeid med Fiskeridirektoratet og Kantega. Implementere og teste ut datamodeller og algoritmer. Teknologi og rammeverk Prosjektkrav Vi er fortsatt i innsiktsfasen av prosjektet så alle krav er ikke kartlagte enda. Nedenstående liste er derfor å anse som tentativ og ufullstendig. Løsningen vi leverer skal være brukervennlig. Vi skal levere god dokumentasjon slik at Kantega/Fiskeridirektoratet skal kunne videreutvikle løsningen. Vi skal benytte oss av enhetstesting og annen relevant testmetodologi. Applikasjonen skal kodes og kommenteres på engelsk Applikasjonen skal kunne kommunisere med Saga, som er et fagsystem hos Fiskeridirektoratet for kontroll og tilsyn. Teknologier og avhengigheter Arkitektur Kantega ønsker at vår løsning skal lages med en teknologistack tilsvarende den som i dag brukes på Saga prosjektet og vi skal produsere en responsiv Single Page Application. Vår løsning tar i bruk Model-View-Controller mønsteret, som er et designmønster innen programvareutvikling. MVC-modellen er en et anerkjent og mye brukt designmønster i moderne applikasjonsutvikling som deler løsningen i modell og view(grensesnitt) med en kontroller som styrer kommunikasjonen mellom disse. Figur 1 Illustrasjon av MVC-modellen 5
Front-end Vi skal levere en moderne webapplikasjon som bruker fremtidsrettede teknologier og rammeverk. React.js og Redux.js med middleware-rammeverket redux-saga er våre hovedrammeverk og vi bruker disse for å skape en dynamisk Single-Page Application(SPA). HTML5 blir brukt som markeringsspråk CSS, såkalte stilark, blir brukt for å definere utseendet på vår webapplikasjon. jquery blir brukt for DOM manipulering Back-end Vår backend-løsning består av en relasjonsdatabase som tilgjengeliggjør data via et RESTfult API som blir skrevet i Java EE med Spring rammeverket. Denne modulære oppbyggingen gjør at vedlikehold og eventuelt videreutvikling blir mye lettere. Dette gir også muligheten til å integrere vår løsning i andre systemer eller bruke andre klienter så lenge man har en klient som kan konsumere API-er kan man ta i bruk vår løsning. Siden kommunikasjonen mellom front-end og back-end foregår asynkront vil dette gjøre at eldre nettlesere ikke støttes, men dette har vi valgt ikke å ta hensyn til. Vi anser sannsynligheten for at noen skulle ønske å bruke eldre versjoner av nettlesere som marginal. Maskinlæring Det er et krav i prosjektet at vi skal minst ta i bruk en maskinlæringsalgoritme. Selv om det ikke er helt avklart så kommer vi trolig til å benytte oss av Apache Spark/MLib som rammeverk for maskinlæring. Versjonshåndtering Vi bruker en privat git lagringstjeneste internt hos Kantega for å håndtere kildekoden til prosjektet (Wikipedia, 2017). 6
DevOps og Continuous Delivery/Integration DevOps kan ses på å være et slags rammeverk, metodikk og kultur for utviklingsprosessen med fokus på hyppige leveranser med sterkt fokus på programvaretesting og er mye brukt i smidige programvareutviklingsprosjekter (Jabbari, Ali, Petersen, & Tanveer, 2016). Figur 2 Livssyklusen til DevOps Vi planlegger å ta i bruk en Jenkins build pipeline for automatisk testing og leveranse av kode til utviklings- og testmiljø (Jabbari, Ali, Petersen, & Tanveer, 2016) Arbeidstider Vi har fast kontorplass hos Kantega og jobber med prosjektet fra 09-15 hver dag. Prosjektmetodikk Prosjektteamet vil jobbe smidig i sprinter etter Scrum-metodikken og vil ha tidsavgrensede sprinter, daglige standups og periodiske sprintdemoer. De første ukene går med til å skaffe oss innsikt i prosjektet, bestemme arkitektur og teknologi og vi oppretter en innledende backlog av utestående oppgaver til den første sprinten som forventes startet i uke tre (Wikipedia, 2017). Prosjektstyringsverktøy Vi bruker også Atlassian Jira for prosjektstyring og Atlassian Confluence for prosjektdokumentasjon (Atlassian, 2017) (Atlassian, 2017). 7
Taushetsplikt Vi har signert en avtale om konfidensialitet og vi plikter å bevare taushet om og hindre at andre utenforstående får kjennskap til informasjon som ikke er allment tilgjengelig om selskapets produkter, tjenester, teknologi og forretningsmessige forhold. Risikomatrise Hva kan gå galt Sannsynlighet Konsekvens Forebygging/løsning Den sykemeldte må gi beskjed tidlig og bør så langt som det lar seg gjøre ta Sykdom Høy Middels 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 Bedrift nedprioriterer ting ut sammen. Hvis bedriften velger oss eller trekker seg Lav Høy å trekke seg under prosessen må vi ta hensyn til kontrakten og de kravene som er satt opp der. Gruppekonflikter Høy Middels Manglende engasjement Høy Middels Tekniske problemer Lav Middels Tap av data Lav Høy Kort tidsramme Lav Høy For komplisert prosjekt Middels Middels 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. 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. 8
Fremdriftsplan Vi har valgt å definere sprinter med varighet på to uker etter innspill fra Kantega og vi får veiledning i hvordan man skal gjennomføre et agilt programvareutviklingsprosjekt. Det endelige omfanget og målsetninger for prosjektet blir fastsatt i en workshop med Kantega og Fiskeridirektoratet mandag 23.1.2017. Milepælene i vårt prosjekt er definert som sprintene(sp1-sp6). Nedenstående fremdriftsplan er ufullstendig og tentativ og forventes ferdigstilt i etterkant av workshop med kunden. Figur 3 Fremdriftsplan for januar 9
Figur 4 Fremdriftsplan for februar Figur 5 Fremdriftsplan for mars 10
Figur 6 Fremdriftsplan for april Figur 7 Fremdriftsplan for mai 11
Figur 8 Fremdriftsplan for juni Oppsummering Det er utvilsomt et ambisiøst prosjekt vi har forpliktet oss til, men vi har blitt svært godt mottatt hos Kantega og har tilgang på gode ressurser i prosjektet vårt. Og det er et prosjekt vi er veldig takknemlige for å bli med på siden potensialet for læring er svært høyt. Men det må likevel bemerkes at prosjektet er beheftet med til dels stor risiko siden maskinlæring er et helt nytt område for oss og det er svært krevende. Derfor blir det helt avgjørende for prosjektet suksess at vi greier å avgrense nok slik at det blir håndterbart innenfor den tiden vi har til rådighet. 12
Bibliografi Atlassian. (2017). Atlassian. (Atlassian, Producent, & Atlassian) Hämtat från Atlassian Jira: https://www.atlassian.com/software/jira den 13 Januar 2017 Atlassian. (2017). Atlassian. (Atlassian, Producent, & Atlassian) Hämtat från Atlassian Confluence: https://www.atlassian.com/software/confluence den 13 Januar 2017 Jabbari, R., Ali, N. b., Petersen, K., & Tanveer, B. (2016). What is DevOps?: A Systematic Mapping Study on Definitions and Practices. XP '16 Workshops: Proceedings of the Scientific Workshop Proceedings of XP2016. ACM. Wikipedia. (2017). Wikipedia. Hämtat från Wikipedia: Git: https://en.wikipedia.org/wiki/git den 17 Januar 2017 Wikipedia. (2017). Wikipedia. Hämtat från Wikipedia: Scrum (Software development): https://en.wikipedia.org/wiki/scrum_(software_development) den 17 Januar 2017 Yamashita, A. (2016). Aiko Yamashita - HiOA. Hämtat från Aiko Yamashita - HiOA: https://www.hioa.no/tilsatt/aikyam den 13 Januar 2017 13