HOVEDPROSJEKT. Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo

Transkript

1

2 2

3 PROSJEKT NR. 13 TILGJENGELIGHET: OFFENTLIG Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo HOVEDPROSJEKT Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL Avviksrapportering F/NLF DATO 26.mai 2014 PROSJEKTDELTAKERE Morten Kristoffersen (s169440), Dataingeniør, mortenkristoffersen10@gmail.com Eivind Jacobsen (s173466), Anvendt Datateknologi, eivind_ja@hotmail.com Tore Buer (s180346), Anvendt Datateknologi, tore@fallskjerm.no ANTALL SIDER / BILAG 133 INTERN VEILEDER Eva Hadler Vihovde OPPDRAGSGIVER Fallskjermseksjonen/Norges Luftsportforbund VEILEDERBEDRIFT Accenture AS SAMMENDRAG KONTAKTPERSON Jan Wang EKSTERNE VEILEDERE Fredrik Bjørnøy, fredrik.bjornoy@accenture.com Nils Ove Erstad, Erstad, nils.ove.erstad@accenture.com REST web API for håndtering av avviksrapporter for Fallskjermseksjonen/Norges Luftsportforbund 3 STIKKORD RESTful web API Java JavaScript 3

4 Forord Denne rapporten tar for seg all dokumentasjon i forbindelse med hovedprosjekt ved Høyskolen i Oslo og Akershus våren Rapporten har fem hoveddeler: Presentasjon. Involverte aktører, sammendrag av oppgaven, beskrivelse av organiseringen av fallskjermhopping i Norge. Denne delen er skrevet for sensor og våre veiledere. Produktbeskrivelse. Inneholder en beskrivelse av hele applikasjonen, og er skrevet for produkteier samt personer som skal vedlikeholde eller videreutvikle systemet Utvikling. Inneholder bakgrunnen for produktet, valg som ble tatt, begrunnelse for valg. Denne delen er skrevet for sensor, samt personer som skal vedlikeholde og/eller videreutvikle systemet. Grunnleggende kunnskap om systemutvikling og datateknologi kreves for å forstå denne delen i sin helhet. Prosessbeskrivelse. Skrevet for sensor, veiledere og andre som måtte ha interesse av å lese om arbeidet vi har lagt ned i dette prosjektet. Denne delen er ment for personer med grunnleggende kunnskap om systemutvikling og datateknologi. Avslutning. Skrevet for sensor og veiledere. Dette er en oppsummering av prosjektet, med produktets verdi, vårt læringsutbytte og erfaringer Vedlegg ligger bakerst i dokumentet. Oslo, 26. mai 2014 Morten Kristoffersen Eivind Jacobsen Tore Buer 4

5 Innhold Forside Forord Presentasjon Innledning Involverte aktører Gruppemedlemmer Intern veileder HiOA Ekstern veiledning Veiledere Accenture Oppdragsgiver Presentasjon av involverte aktører Studentgruppen HiOA Accenture Fallskjermseksjonen i Norges Luftsportforbund Bakgrunn for oppgaven Mål for oppgaven Produktpresentasjon Innledning Oversikt over systemets hoveddeler Frontend webklient Initialisering av rapport Type rapport Valg av klubb og lokasjon Involverte personer Mellomlagring av data Informasjon om de involverte Hendelsesforløp Bekreftelse før rapport sendes til hovedinstruktør Lese avviksrapporter Administrere data

6 2.4. Logisk arkitektur back-end Implementasjonen Universell utforming Testing Innledning Backend Manuelle tester via Postman Manuell systematisk testing av ressurser Unit testing Eksempler på tester: Frontend Produktdemonstrasjon - Fagseminar Produktdemonstrasjon - SU møte Produktpresentasjon - Accenture Utvikling - Valg og utfordringer Innledning Kravspesifikasjon Kort om valg av programmeringsspråk Webservice API og REST Hva er en web service? Hva er et web API SOAP REST SOAP vs REST Valg av type webservice Dataoverføringsformater XML (Extensible Markup Language) JSON (JavaScript Object Notation) HAL (Hypertext Application Language) Vårt valg av dataoverføringsformat Lagdeling Fordeler med lagdelingen vår

7 Ulemper med lagdelingen Utviklingsmiljø og anvendt programvare Fysisk server Virtuell maskin, nettskyløsninger Utvikling av MelwinClient Systemkrav Backend Frontend Installasjonsveiledning for kjøring på Ubuntu server Prosjektstyring Versjonskontroll Git IDE - (Integrated Development Environment) Eclipse NetBeans versjon Sublime Database Relasjonsdatabase NoSQL-database Vårt valg av databasesystem Byggverktøy Maven Erfaringer og utfordringer med Maven Anvendt rammeverk, biblioteker og programmeringsspråk Java Spring Framework Hvorfor velge Spring? Utvikling med Spring Vår erfaring med Spring Spring Security Innlogging

8 Spring Boot JUnit AngularJS Viktige funksjoner: UI-Select Bootstrap-datetimepicker Twitter Bootstrap Valg om å ikke kommentere kildekoden Prosessbeskrivelse Innledning Planlegging / Forprosjekt Arbeidsmengde Arbeidssted Prosjektside Metodikk Avslutning og resultat Produktet Oppfyllelse av krav til funksjonalitet Oppfyllelse av krav til videreutvikling Veien videre Refleksjon Gjennomføring Samarbeid Læringsutbytte Konklusjon Vedlegg Vedlegg 1 - Norges Luftsportforbund Vedlegg 2 - Kravspesifikasjon Avviksrapportering Fallskjermseksjonen/Norges Luftsportforbund (F/NLF) Vedlegg 3 - Oversikt over ressurser Web API Vedlegg 4 - Klasseoversikt Vedlegg 5 - Filstruktur frontend

9 Vedlegg 6 - Brukertest Vedlegg 7 - Tilbakemelding fra oppdragsgiver Vedlegg 8 Risikoanalyse Vedlegg 9 Fremdriftsplan Vedlegg 10 - Ordliste VEDLEGG 11 - Kilder

10 1. Presentasjon 1.1. Innledning I denne delen presenteres involverte aktører, samt bakgrunnen og målet for oppgaven. Delen er skrevet for sensor og våre veileder. Oppdragsgiveren, Fallskjermseksjonen/Norges Luftsportforbund (F/NLF), presenteres kort i denne delen. For mer utfyllende informasjon rundt organiseringen av fallskjermhopping i Norge, ord og uttrykk henvises det til vedlegg Involverte aktører Gruppemedlemmer Morten Kristoffersen, s Dataingeniør Epost: mortenkristoffersen10@gmail.com Eivind Jacobsen, s Anvendt Datateknologi Epost: eivindjac1@gmail.com Tore Buer, s Anvendt Datateknologi Epost: tore@fallskjerm.no Intern veileder HiOA Eva Hadler Vihovde Epost: EvaHadler.Vihovde@hioa.no Tlf: Ekstern veiledning Accenture AS ved Rune Waage Epost: rune.waage@accenture.com Veiledere Accenture Nils Ove Erstad nils.ove.erstad@accenture.com Tlf: Fredrik Bjørnøy fredrik.bjornoy@accenture.com Tlf:

11 Oppdragsgiver Fallskjermseksjonen / Norges Luftsportforbund (F/NLF) Fagsjef Jan Wang, produkteier Epost: jan.wang@nlf.no Sikkerhet- og utdanningskomitteen (SU) i F/NLF ved leder Knut Asgeir Lien Einar Huseby, prosjektkontakt F/NLF Epost: einar.huseby@gmail.com Figur 1 - Oversikt over involverte aktører 1.3. Presentasjon av involverte aktører Studentgruppen Studentgruppen ble satt sammen i september Tore kjente både Eivind og Morten fra ulike tidligere skoleprosjekter, men vi tre har ikke jobbet sammen tidligere. Morten og Tore kjenner hverandre også fra tidligere gjennom mange år med fallskjermhopping og vedlikehold av fallskjermutstyr. Gruppen ble satt sammen på bakgrunn av god erfaring fra tidligere skoleprosjekter, høye ambisjoner og høy arbeidsvilje HiOA Høgskolen i Oslo og Akershus (HiOA) er landets største statlige høgskole, med ca studenter og over 1850 tilsatte. Fakultet for teknologi, kunst og design (TKD) tilbyr blant annet høyere utdanning innen ingeniør-, Figur 2 - Logo HiOA 11

12 teknologi- og datafag og har ca 2600 studenter. Fakultetet tilbyr tre kurs innen datafag: Dataingeniør, Informasjonsteknologi og Anvendt Datateknologi Accenture Accenture er et globalt konsulentselskap som leverer tjenester innenfor rådgivning, teknologi og outsourcing, med omkring ansatte som arbeider for kunder i mer enn 120 land. Avdelingen på Fornebu utenfor Oslo har et omfattende og solid opplegg for veiledning av bacheloroppgaver. Hvert år velger de ut flere grupper etter en søknadsprosess, og opplegget deres omfatter også kurs i teknologier ved siden av veiledning Fallskjermseksjonen i Norges Luftsportforbund Norges Luftsportforbund (NLF) er et særforbund innen Norges idrettsforbund og Fallskjermseksjonen er en adskilt seksjon innen Norges Luftsportforbund. F/NLF er en av tre aktører i Norge som har tillatelse fra Luftfartstilsynet til å arrangere sivil Fallskjermhopping. NLF har rundt medlemmer og Fallskjermseksjonen er den største seksjonen innen NLF med rundt 4000 medlemmer. Figur 3 - Logo Accenture Figur 4 - Logo NLF 1.4. Bakgrunn for oppgaven F/NLF har i dag et papirbasert og elektronisk system for rapportering av avvik. Den papirbaserte delen gjøres normalt rett etter at avviket har skjedd, og denne rapporten sendes videre til klubbens hovedinstruktør som skal føre inn informasjonen på et webskjema. Registrering av rapporter i felles system via webskjemaet tar ofte vesentlig lenger tid enn de maksimalt 48 timene F/NLF krever det skal ta fra et avvik skjer, til rapporten ligger registrert i systemet. Tungvint og tidkrevende rapportering gjør at mindre avvik ikke registreres, og påbegynte rapporter skrevet på papir forsvinner ofte før de blir registrert. F/NLF har i flere år sett etter en bedre løsning for rapportering av hendelser enn det de har i dag Mål for oppgaven Oppgavens mål er å forenkle avviksrapportering for Fallskjermseksjonen i Norge. Det skal bygges opp en god backend og et REST-API, med funksjonalitet som støtter registrering og uthenting av avvik. I tillegg skulle det lages et frontend som benyttet REST-API et til å utføre CRUD- operasjoner (Create, Read, Update, Delete) på avvik, medlemmer, utstyr, etc. Selve produktet skal resultere i et REST-API og en frontend web-applikasjon. Web-applikasjonen bør lages med responsivt design for å tilgjengeliggjøre tilgang også fra mobile enheter. En responsiv webklient vil skape en opplevelse av dialog med brukeren, der kun aktuelle felter for det gitte avviket som skal registreres blir synlig. 12

13 Applikasjonen skal kunne brukes av Fallskjermseksjonens Hoppledere til å registrere avvik, næruhell og ulykker, samt administrasjon av klubb- og medlemsdata for Fagsjefen og Instruktørene. I applikasjonen vil rapporteringen foregå digitalt. Selv om rapporten ikke fullføres umiddelbart, vil dataene som er lagret være synlige for andre, og tilgjengelig for redigering. De viktigste operasjonene som skal kunne gjennomføres er: Registrere avvik Sikker innlogging Administrasjon av medlemsdata og klubbdata Uthenting av informasjon Synkronisering fra F/NLF s egen database (MeLWin) F/NLF hadde en lang liste over ønsker og funksjonalitet til applikasjonen. For å se komplett liste over dette, se vedlegg 2, Kravspesifikasjon. Applikasjonen bygges med fokus på muligheter for videreutvikling, og utskifting av deler av applikasjonen. Applikasjonen bygges derfor lagdelt. Oppdragsgiver har ikke helt klart for seg alle funksjoner og muligheter systemet skal tilby. Utviklingsmetoden Scrum tar god høyde for dette og vil bli benyttet. Testdreven utvikling (TDD) vil fange opp feil underveis, og verktøy for kontinuerlig integrasjon vil tilgjengeliggjøre systemet for brukertesting. Git tar seg av versjonskontroll, og dataene distribueres for sikring mot tap. 13

14 2. Produktpresentasjon 2.1. Innledning Denne delen beskriver produktet i sin helhet, med de viktigste funksjonene, skjermbilder og systemet som ligger bak. Denne delen av rapporten er skrevet for sensor, våre veiledere, og andre måtte ha interesse av å lese om hvordan systemet er implementert. Vi vil i denne delen belyse prosjektets omfang og datatekniske vanskelighetsgrad, og det forutsettes at leseren har grunnleggende kunnskap innen systemutvikling for å forstå det som er beskrevet. For beskrivelse av valg som ble tatt, positive og negative erfaringer henvises det til del 3, Utvikling - valg og begrunnelser. For beskrivelse av fallskjermtekniske ord, uttrykk og roller henvises det til vedlegg 1, F/NLF. Kjørende versjon finnes på ip-adressen Kildekode er tilgjengelig på det åpne Git-repoet avviksrapportering-fnlf-snapshot og på vedlagt USBstick Oversikt over systemets hoveddeler Systemet vi har laget består av: Frontend. En high fidelity prototype på mulig frontendløsning. Laget i AngularJS/JavaScript og stylet med Twitter Bootstrap. REST-API. Lagdelt system skrevet i Java med Spring rammeverket, består av følgende deler: o RestLayer, tilbyr ressurser til frontend gjennom JSON objekter via URI (Uniform Resource Identifier) o Business Logic Layer, tar seg av all logikk o Data Access Layer (DAL), tar seg av lesing og skriving av data til og fra databasen o Modell, definisjon av datatyper, get-, og set-metoder MongoDB. Dokumentdatabase i bunn der alle data lagres til og hentes fra. MeLWin-klient, henter nye og/eller endrede data fra medlemsdatabasen MeLWin og skriver til MongoDB. Vedleggene 4 og 5 viser oversikt over henholdsvis klassene i backend og filstrukturen i frontend 2.3. Frontend webklient Som beskrevet i kravspesifikasjonen har vi laget en fungerende, high fidelity prototype som frontend for å ha et presentasjonslag som tilbyr funksjonalitet for å logge seg inn, lagre og lese avvik, og legge til, endre eller slette datatyper i databasen. Frontend er en single-page applikasjon laget med JavaScript-rammeverket AngularJS, og stylet med Twitter Bootstrap. I tillegg har vi benyttet biblioteket UI-Select2 for å lage søkbare select-bokser, og Bootstrap-timepicker for valg av dato og tidspunkt. 14

15 Under følger en beskrivelse av frontend fra brukeren er logget inn, vi går igjennom registreringen av et avvik, og ser på hvordan administrasjon av datatyper foregår Initialisering av rapport Figur 5 - Initialisering av rapporten og innskriving av de viktigste dataene kan gjøres via mobil. Type rapport Type rapport beskriver alvorlighetsgraden av avviket. Valget gjøres i dynamisk genererte radioknapper der dataene hentes fra REST-laget, og tooltip vises når musepekeren holdes over et valg. Figur 6 - Tooltip Kodeeksempel 1 - Radioknapper Valg av klubb og lokasjon Valg av klubb og lokasjon gjøres ved hjelp av biblioteket UI-Select2, som gjør det mulig å søke etter verdien man leter etter. Søkestrengen er ikke case-sensitiv, og søket gjøres i alle deler av ordene. 15

16 Figur 7 - UI-Select2 for valg av klubb Listen med klubber hentes fra MeLWin via MeLWin-klienten (SOAP API) og legges over i vår database, MongoDB. Lokasjoner ligger lagret i MongoDB og kan administreres fra frontend via RESTlaget om man er logget inn som administrator. Brukere har tilgang til å legge til nye lokasjoner via et modalt vindu. Figur 8 - Modalt vindu for ny lokasjon Involverte personer Et avvik kan ha en eller flere involverte personer. Norske hoppere med gyldig lisens ligger lagret i MeLWin og hentes inn til MongoDB via SOAP-klienten. Det er i overkant av 2000 personer lagret i MelWin pr i dag. De involverte kan være utenlandske hoppere, elever eller ikke-hoppere som da ikke ligger lagret i MeLWin. Disse kan legges inn i databasen av brukeren via et modalt vindu. 16

17 Figur 9 - UI-Select2 med multiple funksjonalitet For valg av involverte personer bruker vi UI-Select2 biblioteket, og da satt opp med multiple funksjonalitet, slik at flere personer kan velges. Personene er søkbare på navn og medlemsnummer. Mellomlagring av data For hver side av registreringen lagres dataene til databasen, slik at brukeren kan påbegynne en rapport, gjerne på mobil i løpet av den travle hoppdagen, for så å fullføre registreringen på et senere tidspunkt Informasjon om de involverte Figur 10 - Registrering av informasjon om de involverte For hver av de involverte personene må det fylles ut informasjon om lisenser personen hadde da avviket fant sted, type hopp som ble utført, erfaring i antall år og erfaring i antall hopp. I rapportene kreves det et bilde av hopperens situasjon der og da, så selv om informasjon om hvilke lisenser personen har hentes fra MongoDB er man avhengig av å kunne oppdatere dette dersom dataene 17

18 som hentes fra databasen ikke stemmer. Hopptype og erfaring lagres ikke i MeLWin, og må derfor settes inn manuelt for hver registrering. Figur 11 - Utfylling av detaljer Hendelsesforløp Figur 12 - Legg til hendelse Et avvik kan bestå av en eller flere hendelser, og i hver hendelse er en eller flere av de involverte personene i avviket involvert. Det er ønskelig å registrere hele hendelsesforløpet i kronologisk rekkefølge, der de som er involvert i hendelsen velges ved hjelp av checkboxer, og hvilken type hendelse velges fra en søkbar UI-Select2 nedtrekksliste. Hver enkelt hendelse kan utfylles med en kommentar om det er nødvendig. Hver enkelt hendelse som legges til, vises i en egen liste i hendelsesforløpet. 18

19 Figur 13 - Hendelsesforløp Dersom en hendelsestype ikke finnes, kan brukeren legge til en ny via et modalt vindu. Figur 14 - Modalt vindu for å legge til hendelsestype Etter at en hendelse er lagt til i avviket, kan brukeren endre rekkefølge, endre eller slette hendelser i avviket. 19

20 Figur 15 - HL's kommentar Til slutt i registreringen av et avvik har hoppleder (HL) mulighet til å legge inn en sluttkommentar, dersom hendelsesforløpet ikke kommer tydelig nok frem. Kommentaren har en fiktiv maksimumslengde på 255 karakterer. Oppdragsgiver ønsket dette for at brukeren skal oppfordres til å begrense lengden på kommentaren, men likevel ha mulighet til å skrive så mye han har behov for Bekreftelse før rapport sendes til hovedinstruktør Side 4 av rapporteringen lister enkelt ut de inntastede dataene på skjerm, og gir brukeren mulighet til å lese igjennom før rapporten sendes videre til hovedinstruktør. 20

21 Lese avviksrapporter Brukere med rolle hovedinstruktør eller høyere, kan lese avvik. Disse listes ut i stigende rekkefølge. Brukeren kan filtrere hvilke rapporter som skal vises, og systemet vil da søke i alle data i rapporten. Figur 16 - Les rapporter, med filtrering Hver rapport som listes ut kan trykkes på og åpnes, slik at de kan leses i sin helhet Administrere data Gjennom Admin menyen kan administrator av systemet endre de datatypene som ikke hentes fra MeLWin, samt endre på klubber. 21

22 Figur 17 - Adminmenyen Figur 18 - Eksempel på administrasjon Administrasjonen er for prototypen gjort helt enkelt, slik at systemet kan prøves ut av oppdragsgiver. Controllerklassene i Angular tar seg av logikken til det som skal vises i View et. En controller kan gjelde for en hel, eller deler av en side. Dersom en controller benyttes på flere sider, eller flere ganger på en side, for eksempel gjennom ng-repeat, vil en instans av klassen opprettes for hver gang. 22

23 Figur 19 Eksempel på bruk av controllere 2.4. Logisk arkitektur back-end Figur 20 - Logisk arkitektur Oppdragsgiver ønsket at systemet skulle utvikles med tanke på muligheter for videreutvikling og vedlikehold. Vi valgte derfor å dele applikasjonen inn i flere lag som hvert har sitt ansvarsområde.. 23

24 For kommunikasjonen lagene i mellom bruker lagene et felles sett med dataobjekter. For å lese om fordeler og ulemper med lagdelingen, henvises det til kapittel 3.7, lagdeling. Modell: Modell-laget er der domeneobjektene er definert. Klassene beskriver dataobjektene som sendes mellom lagene. Disse klassene inneholder kun datatyper og get, set metoder for å hente og lagre data. DataAccessLayer: Dette laget har ansvaret for CRUD operasjonene mot databasen. Data fra databasen blir konvertert til Dataobjekter definert i modell-laget. Uansett hvilke type database som blir bruk vil dette laget kommunisere med samme type dataobjekter mot LogicLayer. Hvis man senere skulle ønske å bytte ut databasesystem behøver man da kun å jobbe med dette laget. I dette laget er det en pakke med mongo-classes som mapper domene objekter mot collections i databasen. Mappingen blir utført ved hjelp av Spring. MeLWinClient: MeLWinClient er en SOAP klient som har ansvaret for å gjøre spørringer mot MeLWins SOAP web service og oppdatere databasen med medlemsinformasjon fra MeLWins database. MeLWinClient jobber direkte mot databasen. LogicLayer: Dette laget har ansvaret for å hente dataobjekter fra DataAccessLayer til Restlayer. Laget har også ansvaret for logiske operasjoner som for eksempel å finne ut hvilke rettigheter en bruker av systemet har. RestLayer: Dette laget har ansvaret for REST web API et. Det henter og sender dataobjekter til det logiske laget og sender data som ressurser ut til forskjellige frontend klienter. Laget har ansvaret for konverteringa av dataobjekter til JSON og tilbake. Det er laget to versjoner av dette laget. En med linker på ressursene og en uten. Linker til JSON objektene gjør at web API et er på nivå 3 etter Richardsons maturity model. Hvis man skulle ønske å heller lage en SOAP basert web service eller et HTML-genererende frontend så vil det være dette laget man skal endre eller bygge på Implementasjonen Rammeverket Spring er brukt i alle lagene unntatt MeLWinClient. Grunnen til det er at vi startet med arbeidet med kommunkasjonen med MeLWin før vi hadde startet å bruke Spring. Spring gjør det lettere å lage modulær kode med løs kobling mellom modulene. Logikken og dataoverføring er lagt til ulike kontrollere som er singleton-objekter. Et singleton objekt kan ha et satt antall instanser. Det er vanligst med en og den er tilgjengelig for hele applikasjonen. 24

25 For å knytte modulene sammen brukte vi Maven. Maven tar seg også av inkludering av forskjellige tredjepartsbiblioteker Universell utforming Vi har ikke lagt vekt på universell utforming i forhold til synshemninger, kognitive vansker og lignende i frontend prototypen i dette prosjektet, og det er to grunner til det. Systemet er laget for fallskjermhoppere, og dermed ikke allment tilgjengelig. Fallskjermhoppere må før sitt første hopp gjennomgå en legesjekk som blant annet innebærer sjekk av syn og bevegelighet Frontend av systemet er en prototype som skal testes og videreutvikles Derimot har det vært et ønske om at avviksregistreringen skal kunne initieres ute i felten. Derfor har vi gjort førstesiden på avviksregistreringen responsivt, og denne er tilgjengelig på både store skjermer og håndholdte enheter Testing Innledning Denne delen beskriver testingen av avviksrapporteringssystemet. Dette er skrevet for sensor, våre veiledere, og andre personer som måtte ha interesse for å lese om testingen av vårt system. Beskrivelsene av testene inkluderer unit-testing, manuell testing og brukertesting av frontend Backend Testing av Backend har foregått med JUnit og har vært en del av utviklingsmetodikkene våre; Testdriven development. Vi delte opp testingen i unit-tester, og testet på forskjellig funksjonalitet. Testene blir også kjørt i gjennom av Maven (for forklaring av Maven, se kapittel ) for hver gang prosjektet kompileres og bygges, slik at vi også tester at ikke nylig lagt til funksjonalitet ødelegger for eksisterende kode Manuelle tester via Postman Vi testet våre lukkede ressurser som anomalies og parachutist via Postman (en http-klient for Google Chrome). Postman lar en teste http-request kjapt og enkelt. Den tilbyr også å sende med headers og URL parameters. For å teste at alt fungerte kjøre vi manuelle tester i Postman først mot login siden vår. 25

26 Figur 21 - Testing via Postman REST client Her sender man inn brukernavn og passord via x-www-form-urlencoded. Her hadde vi opprettet en testbruker med brukernavn admin og passord admin. Dette var selvfølgelig riktig og vi får en STATUS 200 OK tilbake sammen med en token som dere ser i bildet over. Dette er billetten vi får tildelt og skal bruke til å aksessere mer sensitive data. Noe i REST-API et vårt skal være åpent, men en del sensitiv informasjon skal være beskyttet mot uautoriserte brukere. For prøver vi å aksessere ressursene som inneholder avvik uten videre, får vi en 401 access denied melding. Figur 22 - Uautoriserte brukere får ikke tilgang For å kunne aksessere disse ressursene trenger vi å løse inn billetten vi mottok ved login som bevis på at vi er den vi utgir oss for å være. Den sender vi med som en header tilbake til REST-API et og der vil den bli mottatt av en service som sjekker billetten mot billetten bak. Dette gjøres på følgende måte i Postman (se bildet under): 26

27 Figur 23 - X-auth-token Her sender vi med en X-Auth-Token med samme verdien som vi mottok i sted, og da får vi returnert en STATUS 200 OK med de ressursene brukeren har krav på. I bildet ser vi også litt av JSON-strengen med avviksdata Manuell systematisk testing av ressurser Testing via Postman GET, POST, PUT og DELETE. På POST sendte vi inn JSON-objekter med data. TEST Beskrivelse GET POST PUT DELETE Resultat Ressursen clubs Testet henting, posting, oppdatering og sletting av klubber til databasen via REST-API et OK OK OK OK 200 OK. Alt gikk som forventet. Operasjonen kan også utføres med manglende variabler. Ressursen persons Testet henting, posting, oppdatering og sletting av Parachutists. OK OK OK OK 200 OK. Fungerer fint. Tok litt lenger tid å hente parachutists, da det er mange i databasen. Men nesten ikke merkbart. Ressursen licenses Ressursen locations Test av henting, posting, oppdatering og sletting av lisenser. Henting, posting, oppdatering og sletting av OK OK OK OK 200 OK. Bra. Fungerer raskt og fint. OK OK OK OK 200 OK. Går raskt og fint. 27

28 lokasjoner. Ressursen IncidentType Henting, posting og sletting av hendelser til databasen. OK OK Not teste d OK 200 OK. Fungerer bra. Ressursen MainCanopy Ressursen ReserveCano py Henting, posting, oppdatering og sletting Henting, posting, oppdatering og sletting. OK OK OK OK 200 OK. OK OK OK OK 200 OK Unit testing Navn på test Beskrivelse Resultat ContextTest (ligger i Restlayer) TestingCredentials (Ligger i Restlayer) TestingContext (Ligger i Logiclayer) Testing på innlasting av applikasjonkonteksten. Dette lastes inn og så sjekkes det at en av Service ene ikke er NULL. Testen tester på skriving og sletting til databasen gjennom alle lagene i applikasjonen. Den starter i RestLayer og sender dataene slik: RestLayer Logiclayer Datalayer MongoDB. Resultatet av innsettingen går samme vei tilbake igjen. Tester at brukernavn hashes riktig. Har hentet ut en SHA256 hash med salt for user og sjekker at SaltedSHA256PasswordEncoder hasher det riktig. Testing på innlasting av applikasjonskonteksten. Det lastes inn en bønne fra Datalayer og sjekker at denne ikke er NULL. True. Ingen feil ved siste test True. Ingen feil. True. Bønnen er ikke tom. 28

29 Eksempler på tester: Å lagre data til databasen Sjekke at applikasjonskonteksten og bønnene blir riktig lastet inn Sjekke at data ble lagret Oppdatere data og sjekke at det ble oppdatert Slette data og sjekke at de har opphørt å eksistere Lagre passord med hashing og sjekke at den hashes riktig Sjekke at data med høye autoriseringskrav ikke kan aksesseres av brukere med lavere autorisering Sjekke at metoder ikke returnerer null Kodeeksempel 2 - JUnit testing Over ser vi et utsnitt fra en av JUnit testene på å sjekke at det faktisk legges inn verdier i databasen. Metoden som er er et premiss om at den skal utføres før vi tester. Deretter kommer selve testen som skal sjekke at når man henter ut objektet fra databasen med idnummeret, som vi fikk returnert fra placeobjectindatabase() metoden, så er objektet ikke null. Deretter kjører vi en metode merket annotasjon, som betyr at etter testen er utført, så skal vi slette den verdien som ble lagt inn Frontend Da vi hadde ferdig en prototype på frontend for registrering av avvik gjennomførte vi brukertester med to forskjellige testpersoner. De to testpersonene var Jan Erik Wang som er Fagsjef i F/NLF og Tore Granmo som er fallskjermhopper fra HaGL fallskjermklubb. Begge to har mange års erfaring fra fallskjermhopping og 29

30 har fungert som hoppleder en rekke ganger. Begge hadde da erfaring med det eksisterende hendelsesrapporteringssystemet. Tore Granmo har dysleksi. Figur 24 - Brukertesting Begge to fikk utdelt de samme to case. Begge casene var basert på virkelige hendelser som har funnet sted og var rapportert inn tidligere i Jan Wang brukte en pc med Chrome som nettleser. Tore Granmo brukte en mac med safari som nettleser. En av oss presenterte casen med oppgaver som testpersonene skulle utføre. En annen av oss satt ved siden av og observerte. Fullstendige rapporter fra disse testene er lagt til i vedlegg Produktdemonstrasjon - Fagseminar F/NLF inviterer hvert år ledere, hovedinstruktører og ressurspersonell fra alle landets klubber til Fagseminar. Under årets fagseminar februar holdt studentgruppen en presentasjon av arbeidet så langt. Publikum fikk her anledning til å komme med konstruktiv tilbakemelding som vi tok med oss i det videre arbeidet med applikasjonen Produktdemonstrasjon - SU møte 24. april ble studentgruppen innkalt til møte med Sikkerhet- og Utdanningskommitteen (SU), der applikasjonen ble presentert og diskutert. SU var svært godt fornøyd med produktet vi presenterte, og bestemte seg for å engasjere utviklere for å arbeide videre med applikasjonen. Det ble også bestemt at utvalgte klubber skulle ta i bruk systemet allerede nå i sommer, slik at brukernes behov kan belyses og testes. Videre ble det planlagt at applikasjonen skal tas i bruk av alle landets fallskjermklubber fra og med Produktpresentasjon - Accenture 20. mai holdt studentgruppen en presentasjon av applikasjonen for Accenture. Tilbakemeldingene var svært positive, både på hva vi hadde laget, og hvordan utfordringer har blitt løst. 30

31 3. Utvikling - Valg og utfordringer 3.1. Innledning Denne delen beskriver begrunnelser for valg som er tatt, positive og negative erfaringer, utviklingsmiljø, systemkrav og en kort beskrivelse av kravspesifikasjonen. Det vil også bli skrevet om de forskjellige rammeverkene og hvordan de er brukt i dette prosjektet. Del 2 og del 3 er tett knyttet sammen, der del 2 beskriver selve produktet, og del 3 bakgrunnen for valgene som ble tatt. Del 3 av rapporten er skrevet for sensor, våre veiledere, og andre måtte ha interesse av å lese om hvordan systemet er implementert. Det forutsettes at leseren har grunnleggende kunnskap innen systemutvikling for å forstå det som er beskrevet. Det henvises til vedlegg 2, kravspesifikasjon for detaljer Kravspesifikasjon Kravspesifikasjonen til dette prosjektet ble utarbeidet i samarbeid med oppdragsgiver og veilederne. Vi har benyttet oss av smidig utvikling, og kravspesifikasjonen har derfor hatt en dynamisk rolle. Vårt prosjekt har vært første skritt i en lengre prosess med utvikling av avviksrapporteringssystemet, og det har vært ønskelig fra oppdragsgiver sin side at flest mulig krav beholdes i dokumentasjonen for senere referanse. Endringer i kravspesifikasjonen ble gjort i samarbeid med oppdragsgiver Kort om valg av programmeringsspråk Etter at vi hadde signert kontrakt med F/NLF og Accenture om valg av oppgave, begynte arbeidet med valg av rammene for prosjektet. Oppdragsgiver ga ingen føringer for hva vi skulle bruke av programmeringsspråk, untatt at de ytret et ønske om at systemet skulle være basert på åpen kildekode (open source) og at programmeringspråket skulle ha et stort community. Utover dette hadde vi frie tøyler til å velge det vi mente ville fungere best for denne applikasjonen. Et viktig læringsmål for gruppemedlemmene har vært at prosjektet gjøres så jobbrelatert som mulig, og vi ønsket derfor å bruke teknologier som er ettertraktet å ha erfaring med i jobbsammenheng. Søk i jobbannonser og BEKK s teknologiradar ble viktige momenter i valgene.i tillegg har våre veilederes erfaringer og kunnskap vært viktig i avgjørelsene. Figur 25 - BEKK Teknologiradar Tidlig i prosjektfasen kom Spring inn som en aktuell teknologi. Dette ble sterkt anbefalt fra våre veiledere, og de hadde selv lang erfaring med dette. Spring rammeverket finnes for både.net og Java. Java ble valgt siden dette er open source og kan kjøres på Linux server. 31

32 Valg av database var en omfattende prosess, der valget til slutt sto mellom relasjons- eller dokumentdatabase. Vi hadde erfaring fra relasjonsdatabaser fra skolen, men så utfordringer med at oppdragsgiver ikke visste nøyaktig hvilke data som skulle lagres, og at avviksrapportene kunne inneholde svært ulik mengde og type data. Valget ble dokumentdatabase, og MongoDB ble valgt på grunn av god støtte fra Spring. Som grensesnitt mellom backend og frontend sto valget mellom SOAP og REST. SOAP ble sterkt frarådet av våre veiledere, under en fagkveld med Accenture, og ved søk på nett. REST ble valgt. Oppdragsgiver ønsket at vi leverte et forslag til en high fidelity og så langt som mulig fungerende frontend for å vise funksjonaliteten til backend, og som kunne inspirere til en mer konkret kravspesifikasjon for videreutvikling av frontend. Siden frontend var en mindre viktig del av leveransen, så vi etter frontend rammeverk som kunne manipulere JSON objekter. AngularJS ble raskt pekt ut som en god kandidat, og ble støttet av både veiledere og BEKK s teknologiradar. Oppdragsgiver ønsket at deler av avviksrapporteringen skulle kunne gjøres på mobil, og responsivt design ble derfor et aktuelt tema. For å ikke bruke for mye tid på CSS så vi etter rammeverk som kunne gjøre denne jobben for oss. Twitter Bootstrap ble raskt aktuelt, og dette ble støttet av veilederne. I tillegg til AngularJS og Twitter Bootstrap brukte vi JavaScriptbibliotekene UI-Select2 og Bootstrapdatetimepicker til henholdsvis søkbare nedtrekkslister og valg av dato og tid i frontend. Valgene av disse ble gjort underveis i utviklingen og valget ble tatt etter mye prøving og feiling av tilsvarende biblioteker. Utfordringen her gikk i å finne biblioteker som fungerte godt både i nettleseren og på mobil, noe som viste seg å bli svært utfordrende Webservice API og REST I prosjektet vårt ønsket vi en så løs kobling som mulig mellom backend og frontend. Det finnes mange plattformer som er aktuelle for frontend klienter, Android, IOS, Windows og forskjellige nettlesere. For å gi en best mulig brukeropplevelse vil det ideelle være å lage en klient for hver plattform som best bruker de mulighetene plattformen gir. Dette ble et for omfattende arbeid for prosjektet vårt med vår gruppestørrelse og tidsramme. Derfor gikk vi for å utvikle en web klient som kunne brukes på alle plattformer og gi en relativ god brukeropplevelse. Men vi ønsket at systemet senere skulle kunne brukes av andre frontend klienter. 32

33 Derfor bestemte vi oss for at backend skulle være et RESTful web API. Et RESTful web API er en type web service. Når valget av type web service var tatt måtte det også tas et valg av type dataoverføringsformat. Der valgte vi JSON som format mellom backend og frontend. Her følger en nærmere beskrivelse av de to typene webservice som var aktuelle for prosjektet og ulike typer dataoverføringsformat som var aktuelle, med begrunnelse av valgene som ble gjort. Figur 26 - RESTful web API Hva er en web service? Avviksrapporteringsystemet sin backend-del skal kunne kommunisere med forskjellige typer frontend klienter som kan være basert på forskjellige plattformer. De forskjellige klientene kan f.eks være en Android eller IOS-applikasjon, en desktop-applikasjon eller en webapplikasjon som skal virke i forskjellige nettlesere. Systemet vårt løser dette ved å tilby en en webservice via et RESTful web API. I tillegg kommuniserer avviksrapporteringsapplikasjonen med MeLWin via en webservice basert på SOAP. Begrepene web service og web api blir ofte brukt, men definisjonen på hva begrepene beskriver kan være noe uklart. Begrepene blir ofte brukt om hverandre og selve definisjonene kan det være delte meninger om. En web service er programvare som sørger for kommunikasjon mellom forskjellige applikasjoner/maskiner over et nettverk og da her over web. En webservice bruker en bestemt protokoll for utveksling av bestemte dataformater mellom systemer. For selve overføringen av data er det mest vanlig å bruke http- eller https-protokollen. Forskjellen mellom en webservice og en vanlig nettside er i hovedsak at en nettside har informasjonen formatert for at en person skal kunne lese og forstå informasjonen, mens en webservice har informasjonen formatert slik at andre applikasjoner og systemer kan benytte seg av informasjonen. Et eksempel på forskjellen er yr.no. Skriver man inn URL en i nettleseren får man et værvarsel i et brukervennlig lesbart format. Skriver man inn i stedet vil man få det samme varselet, men nå i et XML-format som gjør det vanskelig å lese for en person, men lettere for andre systemer å benytte. 33

34 W3C har følgende definisjon av en webservice: a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Webrelated standards Hva er et web API Et web API er et begrep som flere bruker synonymt med en web service, men det også en betegnelse på en web service som er bygget opp med en REST- (Represential State Transfer) arkitektur. Fordeler med å utvikle og benytte en webservice for utveksling av data: Interoperabilitet En webservice kan gi et plattform- og implementasjonsuavhengig grensesnitt mellom forskjellige applikasjoner. For eksempel kan man ha en lage en applikasjon ved hjelp av.net rammeverket på en server som bruker Windows som operativsystem. Et annet system, uviklet i Java som kjører på en Linux-plattform kan utveksle data med.net-applikasjonen ved hjelp av en webservice.. Gjenbrukbarhet og brukskvalitet (Usability) Man kan hente data fra forskjellige systemer via webservices og dermed slippe selv å implementere løsninger for å oppnå samme funksjonalitet. Man kan selv velge hvilke ressurser man ønsker å benytte fra et annet system og derme 34

35 Et eksempel kan være en nettside for et skisenter som henter data om vær og snødybder fra yr.no og nve.no i stedet for selv lage systemer for å formidle vær og snødybde. Tilgjengelighet Web services bruker standard internett teknologier for transport av data. Dette gjør at ressurserer fra en web service kan være tilgjengelig for alle systemer og enheter som er koblet til internett. Man vil også få mindre problemer med forskjellige brannmurer som data skal passere gjennom enn om man benytter seg av egne protokoller. Ulemper med web services: Datamengde Web services bruker vanligvis ren tekst for å overføre data. Dette gir enkelthet som er en fordel, men det fører til at man ofte må legge til metadata for at den skal tolkes korrekt mellom avsender og mottaker. Dette kan være et problem for overføringsmedier med begrenset kapasitet. 35

36 Eksempelet ovenfor er en SOAP melding fra MeLWin som angir hvilke kontigentår som er gjeldende. Informasjonen som er av interesse er det tallverdien 2014 representer med 4 tegn. Resten av teksten er SOAP data i XML format. Hele SOAP-meldingen over er på 514 tegn. Ved å bruke en REST-basert web service kan man kutte ned mengden data. Vanlig representasjon med REST er JSON (JavaScript Object Notation) I REST kan man selv velge dataformat (JSON, XML, HAL) og man kan da få mindre omstendelige meldinger. Men ved systemer som skal overføre mindre meldinger i hovedsak kan bruk av web service redusere ytelse i forhold til egendefinert binær dataoverføring. Tilstandsløshet En web service har ingen kontroll på tilstanden til hverken klient eller server. Dette gir utfordringer for autentisering og sesjoner. Det er ingen funksjonalitet for å sikre at klienten serveren kommuniserte med for noen sekunder siden er den samme som sender en ny forespørsel. Og serveren har ingen forutsetninger for å vite om klienten fortsatt er aktiv. Funksjonalitet for å ta seg av dette må implementeres både på klienten og server. De to metodene som er mest brukt for å implementere en webservice er SOAP og REST. Begge metodene er brukt i vårt prosjekt SOAP SOAP er en forkortelse for Service Oriented Architecture Protocol, også kalt Simple Object Access Protocol. Det er en protokoll for å sende data i XML format og gjøre prosedyrekall via internett. Denne protokollen er mye brukt ved utvikling av web services. Det er standarder for SOAP protokollen beskrevet av W3C. En web service basert på SOAP har grensesnittet sitt definert i et XML-dokument kalt WSDL (Web Services Description Language). Ved å lese WSDL-dokumentet kan en klient få vite hva en server tilbyr i sin web service og hvordan ta i bruk tjenestene. 36

37 Figuren over viser hvordan avviksrapporteringssystemet bruker en SOAP webservice for å hente data fra medlemsdatabasen til MeLWin. MeLWin er en Windowsapplikasjon som er basert på en 4D relasjonsdatabase. Siden avviksrapporteringssystemet er en java-applikasjon som kjører på en Linux plattform vil systemene trenge en felles protokoll for å kunne kommunisere med hverandre. Dette gjøres med SOAP-meldinger. Først må klienten finne ut hvilke tjenester serveren tilbyr i en webservice. Dette kan klienten finne i WSDL-dokumentet. Her registrerer serveren tjenestene med metodekall, metodeparametre og returtyper. WSDL dokumentet er i XML format. Avviksrapporteringsystemet skal hente informasjon om alle medlemmer i Fallskjermseksjonen i NLF. For å finne ut hvilke metoder i web servicen som kan hjelpe med dette, ser man i <porttype> taggene i WSDL-dokumentet. Her er metodene listet opp Det er ingen metode for å finne alle medlemmene i seksjonen, men det er en metode for å få ut alle medlemmene i en klubb, ws_getallclubmemberdata. Nå trenger vi å vite hva slags parametre metoden tar. Vi kan se på input meldingen, ws_getallclubmemberdatarequest. Denne finner vi igjen mellom en <message> tag. 37

38 Vi skal her sende med tre parametre som er strenger. En brukerid med tilhørende passord og en ID for klubben vi skal hente medlemmene til. Hvordan svaret vil bli kan vi se på output meldingen ws_getallclubmemberdataresponse Svaret består av en serie med tabeller som inneholder forskjellige datatyper som String, boolean, int, dato og float. Når vi vet metodene vi skal bruke, hvilke parametre som skal sendes med og hva vi vil få tilbake kan vi kontstruere en SOAP melding. En SOAP melding har en fast form: Applikasjonene som skal kommunisere med hverandre må nå parse data til og fra en SOAP melding. På serversiden tar 4D applikasjonen seg av spørringer mot databasen og konstruerer en SOAPrespons. Avvikssystem må kontstruere en SOAP-request og kunne parse tilbake responsen den mottar tilbake. For dette i vårt system brukes rammeverket Apache Axis. SOAP spørringen blir da sånn: 38

39 SOAP responsen hvis man spør bruker clubid til Troms Fallskjermklubb blir da: Her brukes HTTP som transportprotokoll, Dette settes i <binding> taggen. 39

40 SOAP kan også bruke HTTPS og SMTP som transportprotokoll og det er også mulig å overføre via UDP REST Den andre metoden for en webservice kalles REST (Represential State Transfer). I motsetning til SOAP er ikke REST en protokoll, men en arkitektur. Det finnes derfor ikke en standard for en web service basert på REST. REST-arkitekturen ble introdusert av Roy Fielding i en avhandling fra For at en web service skal kunne kalles REST bør den være innenfor disse rammene: 1. Server - Klient. Et uniform grensesnitt er den eneste koblingen mellom klient og server. Klienten skal hente ressurser fra server via grensesnittet og ellers ikke ha noe innvirkning på hva som skjer på serveren. Serveren skal ikke ha noe innvirkning på hva klienten gjør med ressursene etter at de er hentet. Dette for å sørge for et høyt nivå av interoperabilitet. 2. Tilstandsløs. Serveren er tilstandsløs. Ressursene har ingen forskjellige tilstander. Ingen informasjon om klienten skal lagres på serveren mellom forespørsler. Hver forespørsel fra klienten skal inneholde nok informasjon til å gi tilgang til ressursen. Sesjonsdata skal lagres på klienten. Men man kan behandle klientinformasjon som en ressurs på server for å ha funksjonalitet for autentisering. 3. Mellomlagring (Caching). Ressurser fra server kan mellomlagres hos klienten. Server skal kunne merke ressursene om de kan mellomlagres eller ikke. 4. Lagdelt. Ressurser som blir sendt fra server til klient kan passere flere mellom-servere uten at klienten har noe informasjon om dette. Mellom-servere kan være der for sikkerhet i form av brannmurer eller øke skalarbarhet med mellomlagring og trafikkfordeling. 5. Code on Demand. Server kan legge til funksjonalitet hos klienten ved å sende kode som en ressurs. Dette kan være i form av f.eks java-applets eller JavaScript. Code on Demand er ikke et krav til en REST web service. 6. Uniformt grensesnitt. En REST web service tilbyr ressurser og disse ressursene skal være i et format som er innenfor rammene for et uniformt grensesnitt. Identifisering av ressurser. 40

41 Ressurser er identifisert via URI (Uniform Resource Identifier) og ved en web applikasjon, en URL. Klienten mottar ikke selve ressursen men en representasjon av den. F.eks vil i avvikssystemet, kallet på ressursen /clubs/ ikke returnere hele databasefilen som inneholder en collection med klubber, men en representasjon i JSON format. Andre overføringsformater som XML, HTML, HAL kan også brukes. Manipulering av ressurser. Når klienten har mottatt en representasjon av ressursen kan klienten har den nok informasjon til å endre eller slette ressursen. Beskrivende meldinger. En melding eller en representasjon av en ressurs inneholder informasjon om hvordan man skal kunne lese innholdet. F.eks hvis meldingen er i JSON format skal dette oppgis, eller hvis det er en pdf - fil skal dette oppgis. HATEOAS (Hypermedia As The Engine Of Application State) Klienten får vite med linker (hyperlinks i hypertekst, altså hypermedia) som er oppgitt i representasjonen av ressursen om andre funksjonaliteter knyttet til denne ressursen. Med dette kan klienten endre tilstand. Hvis en web service er innenfor alle disse rammene så kan den kalles en RESTful web service og et REST web API. Men mange web services som brukes er ikke innenfor disse rammene, selv om de blir kalt en RESTful web service. Det er en skala kalt Richardsons Maturity Model som graderer en web service etter hvor tro den er mot REST-arkitekturmodellen. Den er delt opp i 4 nivåer: Nivå 0, POX 41

42 POX er en forkortelse for Plain Old XML. På dette nivået bruker man en transport protokoll som HTTP til å sende meldinger. Klient sender en melding (da gjerne i XML-format) til til serveren og får en melding tilbake i samme format. En SOAP basert webservice er på dette nivået. Som beskrevet tidligere for at avviksrapporteringssystemet skal få en liste med informasjon om medlemmer i en fallskjermklubb fra MeLWin, sendes en XML melding med autentiseringsdata og en identifikator på klubben. MeLWin sender da en XML-melding tilbake med informasjonen. Man bruker her kun POST metoden til HTTP. Alle henvendelser mot server skjerm mot et enkelt tilknytningspunkt. I SOAP web services er denne definert i WSDL dokumentet. Nivå 1, Ressurser. I stedet for å rette spørringen mot et enkelt tilknytningspunkt, retter her klienten forespørselen mot forskjellige ressurser på serveren. I avvikssystemet vil url /clubs/ være der man knytter seg til klubb-ressursen, mens /persons/ er ressursen for personer. Vil man da ha en liste over medlemmer i en klubb sender man en melding med en klubb som parameter til person-ressursen og får da en medlemsliste tilbake. Nivå 2, HTTP verb På nivå 0 og 1 har man kun brukt HTTP metoden POST. På nivå 2 bruker man også HTTP metodene GET, PUT og DELETE mot ressursene. Klienten kan da også bruke HTTP koden man får tilbake fra serveren for å finne ut hvordan forespørselen har fungert. Man kan bruke POST for alle mulige spørringer som på nivå 1, men man vil da kun få et begrenset utvalg med responskoder tilbake. Med å bruke GET for å hente en representasjon av en ressurs så er klienten også sikker på at ressursen ikke blir manipulert som man kan oppnå med en POST henvendelse. Nivå 3, Hypermedia Control, HATEOAS. Ved å innføre linker til relaterte ressurser i meldingene fra server til klient vil man kunne sette tilstanden til klienten. Hvis vi bruker avviksrapporteringsystemet som eksempel kan man for eksempel i meldingen man får fra /clubs/ ressursen ha en link til listen over klubbens medlemmer som man henter fra /persons/ ressursen. 42

43 { Andre fordeler med å legge til linker er at web servicen blir mer selvdokumentert. Hvis man ved rotnivået har linker til alle ressursene, og ressursene har linker til andre relaterte ressurser blir det enklere å for utviklere av klienten å gjøre seg kjent med tilgjengelige ressurserser. En annen fordel med å ha en oppgitt relasjonsbeskrivelse til hver link, rel, er at man kan la denne holdes undret ved endringer av selve URL en i linken. Hvis Klienten forholder seg kun til relasjonsbeskrivelsen kan man endre på oppsettet på serveren og linkene uten at klienten blir berørt. rel : link : SOAP vs REST Spørsmålet som ofte kommer opp når man skal velge hvilke type web service man skal implementere er om man skal gå for SOAP eller REST. Hva er best? Her er det satt opp en enkel sammenligning mellom SOAP og REST som forutsetter at HTTP er protokollen som brukes for dataoverføring for begge. REST SOAP Tilbyr ressurser som representerer data. Bruker HTTP verb POST, GET, PUT, DELETE. Støtter forskjellige dataoverføringsformat. Tilstandsløs server. Tilbyr operasjoner som representerer logikk. Bruker HTTP POST. Bruker kun XML som dataoverføringsformat. Streng typing av datatyper. Kan tilby tilstand på server. I REST tilbys det ressurser som man kan hente data fra i et eller flere typer dataformat som representerer informasjonen. I SOAP har man en WSDL som kan sammenlignes med et interface i 43

44 java/c# eller en abstract klasse i c++. I WSDL filen finner man operasjonene som man benytter for å lese eller manipulere data. Når man skal lage en klient til en SOAP webservice så finnes det flere typer rammeverk, som ut i fra WSDL-filen genererer brukergrensesnitt mellom klienten og server. Man får da implementert alle operasjonene på klienten som serveren tilbyr. I vårt system har vi brukt apache axis til dette. Når man skal lage en klient til en RESTful webservice så er man enten avhengig av at alle ressursene er å finne i dokumentasjonen eller at man er på nivå 3 etter Richardsons Maturity Model og kan finne alle ressursene via lenker. SOAP bruker kun HTTP verbet POST, mens REST bruker GET, PUT og DELETE i tillegg. Dette kan gjøre REST tryggere. Ved å bruke GET er man tryggere på at data blir bare lest og ikke manipulert hvis det er ønskelig. Man kan konfigurere brannmurer til å kun tillate de HTTP verbene man ønsker å slippe igjennom. REST er ikke begrenset til ett bestemt dataoverføringsformat som SOAP er. SOAP bruker kun XML, mens REST kan benytte seg av f.eks JSON og HAL i tillegg til XML. XML er mer omstendelig enn f. eks. JSON og gjør da at datameldingen tar mer plass. I SOAP oppgis datatype på variablene som for eksempel heltall og flyttall. Dette er en mulighet i REST, men er da avhengig om dette er støttet i dataoverføringsformatet. Streng typing vil i de fleste tilfeller gi raskere parsing hos server og klient. I REST skal serveren være tilstandsløs, mens tilstander kan settes på serveren i SOAP. Å ha forskjellige tilstander på server kan gjøre implementeringen av sikkerhetsrutiner enklere Valg av type webservice Oppdragsgiver ville først ha på plass en webclient for da å dekke flest mulig plattformer. For å å kunne lage en webclient med et rikt brukergrensesnitt valgte vi å bruke AngularJS som er et MVC rammeverk basert på JavaScript. Vi valgte derfor å lage et RESTful web API. Data til modellen i AngularJS blir hentet fra ressursene i web API et. REST er egnet både til server til server kommunikasjon og server til klient, mens SOAP er best egnet til server-server kommunikasjon og mindre egnet for server - klient Dataoverføringsformater XML (Extensible Markup Language) XML er et markeringsspråk som sin mer kjente slektning HTML. Data er definert mellom tagger som for eksempel kan gi informasjon om datatype, betydning og struktur. Informasjonen i taggene kan utvides ytterligere med attributter. Et eksempel på en XML representasjon om en fallskjermklubb: 44

45 Fordeler Formatet er lesbart både for maskiner og mennesker. Det er egnet til å representere datastrukturer, både lineære som lister og tabeller og i tillegg trestrukturer. Med attributter kan det være strengt typet som gjør det vellegnet til for tolkning av maskiner. Ulemper Syntaksen med både start- og stopp-tagger er plasskrevende og gjør derfor at dataoverføringen krever mer båndbredde JSON (JavaScript Object Notation) JSON har sin opprinnelse fra programmeringspråket JavaScript. Det er en datarepresentasjonsmåte som defineres med objekter som består av en eller flere nøkkel verdi par. Et object er beskrevet mellom { }, nøkkel er separert fra verdi med :. Tabeller og lister er beskrevet mellom [ ]. JSON har et begrenset utvalg av datatyper. Verdier kan være et tall, en streng, en boolsk verdi, en null verdi, et annet objekt eller en tabell med verdier. Et eksempel på JSON representasjon av en fallskjermklubb: Fordeler Det er godt lesbart for både mennesker og maskin. Det er mer lettvekt enn XML. Det trenger færre tegn for å overføre data som tilsvarende data med XML og krever da mindre 45

46 båndbredde. JSON er arvet fra JavaScript og er derfor godt egnet for kommunikasjon med webclienter som er basert på JavaScript. Ulemper Det er et mindre utvalg av datatyper og man har ikke attributter til datatyper. Dette gjør at parsing hos server og klient kan være tregere enn ved bruk av XML HAL (Hypertext Application Language) HAL er et dataoverføringsformat som er basert på XML eller JSON. Den vanligste varianten er basert på JSON. HAL har linker og beskrivelse av linken, relasjonen som standard ved en melding. Dette gjør HAL vellegnet som dataoverføringsformat for et RESTful web API. Man vil da lettere oppnå nivå 3 i Richardsons Maturity Model. Et eksempel på club i HAL format Fordeler HAL er et slags tilleggslag for XML og JSON og arver da de fordeler og ulemper som det dataformatet man arver fra. I HAL er lenker på datameldingene standard, noe som gjør at man enklere kan lage REST web services som er på nivå 3 etter Richardsons Maturity Model. Ulemper Hvis man ønsker å lage en mer lettvekts web service der datameldingene ikke har noe mer informasjon enn det som er strengt nødvendig og man ikke ønsker å ha HATEOAS funksjonalitet vil HAL kreve mer båndbredde enn for eksempel ren JSON Vårt valg av dataoverføringsformat. Siden REST arkitekturen ikke gir noen føringer på dataoverføringsformatet ble dette et valg vi måtte ta. På frontend gikk vi for en JavaScript basert klient og det naturlige valget ble da JSON. Underveis i prosjektet ble vi invitert av Accenture til å bli med på en fagkveld der REST-arkitektur var tema. Der fikk vi presentert arbeidet som ble gjort med det REST-baserte web API til Altinn. Altinn har valgt HAL som dataoverføringsformat. HAL kunne gjøre jobben lettere med å implementere HATEOAS, men vi det kom litt seint i prosjektet og vi valgte å fortsette med JSON. 46

47 Ved å legge til lenker i JSON kunne vi fortsatt oppnå nivå 3 REST-arkitektur. Ved å ha et REST-API på nivå 3 vil være en fordel når man skal lage en klient til REST-API et. Ved å legge til lenker til ressursene blir API et mer selvdokumenterende. Lenkene angir hvilke muligheter man har som klient med hver ressurs. Ved konsekvent navngiving på relasjonene til lenkene vil man som klient kunne velge å knytte ressursforespørsler kun mot relasjonsbeskrivelsene. Endringer til for eksempel på URL til linkene vil da ikke ha noen innvirkning på klienten Lagdeling Lagdelingen er tidligere presentert i Kapittel 2. Her skal vi se litt på fordelene og ulempene ved en slik lagdeling vi har valgt for dette prosjektet. Kort oppsummert har vi valgt en tre lags-arkitektur, med en domenemodell delt av alle lagene. Lagene er restlayer, logiclayer og datalayer. Frontend er helt selvstendig og kan kjøre på en annen server om man ønsker det. I tillegg er det utviklet en egen SOAP-klient mot MeLWin (F/NLF s medlemsdatabase) Fordeler med lagdelingen vår Fordelen med denne lagdelingen er at det gjør det veldig lett å bytte ut moduler ved behov. At løsningen er lagdelt, og at de forskjellige lagene er egne prosjekter gjør at man kan bruke forskjellige teknologier på de ulike lagene om man ønsker det. Hovedtanken er at skal være enkelt å bytte ut moduler uten å affektere resten av koden. Lagdelingen gir prosjektet en litt større struktur, men mye mer oversiktlig og tilgjengelig. Database transaksjonene skjer i datalaget (datalayer) og ressursmappingen skjer i RESTlaget (REST-layer). Målet er at fremtidige utviklere enkelt skal kunne forstå koden ut ifra lagdelingen og dermed gjøre det intuitivt hvor ny funksjonalitet skal legges inn. En annen fordel er at når man skal kompilere og bygge prosjektet med Maven (info om Maven under ), så bygger man hvert enkelt prosjekt for seg. Dermed kan man også isolere eventuelle feil som er knyttet til ett bestemt lag Ulemper med lagdelingen Det kan være en ulempe at applikasjonen er delt opp i flere prosjekter hvis ny funksjonalitet skal legges til. Skal for eksempel nye datatyper sendes fra frontend, må det gjøres endringer i alle lagene, hele veien ned til datalaget. 47

48 3.7. Utviklingsmiljø og anvendt programvare Fysisk server Vi ble først presentert at løsningen skulle kjøre på en fysisk server som brukte Gentoo-Linux som operativsystem. Ved oppstart av prosjektet var denne maskinen lokalisert hos Einar Huseby, men skulle i løpet av kort tid flyttes til en serverpark som NLF var kunde hos. Vi startet dermed å gjøre oss kjent med Gentoo-Linux. Ingen av oss var kjent med denne Linuxdistroen fra før. Hovedforskjellen som skiller Gentoo fra andre Linuxdistribusjoner er at programvaren som installeres med Gentoos pakkesystem Portage, lastes ned som kildekode og kompileres lokalt ved installering. Men man har også muligheten til å installere enkelte applikasjoner med ferdigkompilert binærkode hvis det er ønskelig. Det at programvaren blir kompilert lokalt ved installering gjør at systemet med applikasjonene blir optimalisert for den fysiske maskinen den kjører på. Fart og strømforbruk blir da mer optimalisert i forhold til andre Linux-distribusjoner. For å gjøre oss kjent med Gentoo brukte vi Virtual Box fra Oracle og satte opp en virtuell maskin med Gentoo. Erfaringene vi fikk var at Gentoo krevde mer manuell konfiguering og var mer tidkrevende å bli kjent med enn Debian og rpm baserte Linux-distribusjoner Virtuell maskin, nettskyløsninger Vi fikk tidlig problemer med å jobbe mot den fysiske maskinen som var lokalisert hos Einar Huseby. Det var problemer med linjene og flyttingen til serverparken ble utsatt gjentatte ganger. Vi bestemte oss derfor å sette opp en virtuell maskin som vi kunne bruke som utviklingserver. Vi satte opp en virtuell maskin på Microsoft Azure som er en nettsky leverandør. Vi valgte der å bruke Ubuntu-Linux som operativsystem. Vi var alle i gruppa kjent med denne Linuxvarianten og Ubuntu var et predefinert forvalg hos Microsoft Azure. Den første måneden var denne tjenesten gratis og vi håpet at vi kunne få bedre tilgang til Gentoo maskinen i løpet av denne tiden. Det å bytte mellom forskjellige operativsystemer for løsningen burde ikke by på store utfordringen siden vi utviklet en plattformuavhengig Java-løsning. Vi fikk gode erfaringer med Microsoft Azure. Å sette opp den virtuelle maskinen med operativsystem var gjort på 30 minutter. Konfigurering med å åpne porter gjorde vi via webkonsollet til Azure. Vi fikk også tilgang til overvåkningsverktøy til den virtuelle maskinen. Etter at maskinen var satt opp kunne vi jobbe mot den via SSH-klienter som Putty eller andre Linuxemulatorer for Windows som MinGW og Cygwin. Etter at den ene måneden med gratis virtuell maskin hos Microsoft Azure var over hadde vi fortsatt ikke tilgang til den fysiske maskinen. Vi flyttet derfor over til Amazon Web Services, der vi hadde 48

49 tilgang til gratis virtuell maskin i 12 måneder. Også der brukte vi Ubuntu som operativsystem som også hos Amazon var et predefinert forvalg. Systemovervåkning Amazon Via webconsollet til Amazon kan man enkelt se f.eks. prosessorbelastningen til den virtuelle maskinen. Dette er interessant informasjon om man vurderer at belastningen blir for stor og man vurdererer å oppgradere serveren. Via grafen over kan man se belastningen på prosessoren de siste to ukene. Serverens prosessor ligger godt under 20 % det meste av tiden, men har høyere belastning på nærmest periodiske intervaller. 49

50 Grafen over viser nettverkstrafikken inn på serveren de siste to ukene. Hvis man sammenlikner grafene på inntrafikk og prosessorbelastning så kan man se at de er sammenfallende. Ved å sammenligne med logger på serveren fant vi ut at kommunikasjonen mot MeLWin, der medlemsdata hentes, står for de fleste toppene for beslag av serverressurser. På bakgrunn av dette kan man hvis det er behov legge tidspunktet for synkronisering av databasen mot MeLWin på et tidspunkt på døgnet der det eller skjer lite. De andre ressursbruktoppene sammenfaller med når vi brukte Maven til å bygge og kompilere backend. 50

51 Hvis vi ser på grafen for nettrafikk ut fra serveren så er den mer beskjeden i forhold til inntrafikken. Det kan derfor være mulig at F/NLF vil kunne klare seg med en micro-instans hos Amazon som vil gi svært små driftsutgifter. En stor fordel med nettskyløsninger er at de fleste driftsoppgaver blir tatt seg av leverandøren av nettskyløsningen. Backup av harddisk, bytte ut hardwarekomponenter eller omstart etter strømbrudd slipper man å tenke på. Andre utfordringer med nettskyløsninger er knyttet til personvern og sikkerhet. Man er avhengig av nettskyleverandøren leverer den sikkerheten de har lovet hvis man skal lagre sensitive opplysninger som omhandler skader på personer Utvikling av MelwinClient SOAP API til melwin er definert i wsdl-filen som ligger på Web API hadde ingen dokumentasjon. For å bli kjent med metodene som lå der brukte vi nettstedet soapclient.com og Chrome tilleggsapplikasjonen wizdler. Med disse to verktøyene kunne vi teste alle metodene og finne ut hva de returnerte. Det var 36 forskjellige metoder definert og testingen av disse var ganske tidkrevende, heldigvis var metodenavnene ganske selvforklarende. Vi fant ut at metodene vi trengte var ws_getallclubmemberdata og ws_lisenser. Disse metodene returnert alle den informasjonen om medlemmene i Fallskjermseksjonen fra MeLWin vi trengte. Vi prøvde så å finne et rammerk for å lage en klient i Java som benyttet seg av SOAP-protokollen. Vi fant ut at Apache Axis kunne brukes for å lage en SOAP-klient. MeLWins SOAP API bruker RPCstyle (Remote Procedyre Call) som service-style. Dette er en enkoding for SOAP som ikke alle SOAPjavarammeverk støtter. Den mer vanlig Document-stylen støttes av de fleste. Vi prøvde først rammeverk som Apache CXF og Apache Axis 2 for å lage en Java web-klient men fikk problemer med MelWins RPC-style. I RCP kalles en metode med parametere. 51

52 Figur 27 - Skjermbilde fra Wisdler Her kalles en metode i MelWin med tre parametre. Bruker ID og passord for autentisering og id på klubben det skal hentes medlemmer. Man får så et xml-dokument tilbake. Dokumentet består av 23 kolonner som representerer et datafelt, En ny tag i dokumentet har en referanse til sin kolonne og hver item-tagg representer en rad i sitt datafelt. Axis generer Java datatyper ut i fra dette XML-dokumentet. 52

53 I Javaprosjektet blir det generert et Interface A_WebServicRCP.java med en Java-metode for alle SOAP metodene som er beskrevet i WSDL-filen. Axis genererer også ArrayDataHolder-klasser som brukes som parametre i metodene. Objekter av disse klassene inneholder arrayer med tilhørende datatyper. SOAP-metodene tar referanser til disse objektene og fyller de med data. Koden over viser hvordan vi får hentet inn data med lisensinformasjon til dataholderobjektene. Hver enkelt persons informasjon vil da ha samme indeks i de forskjellige tabellene. Vi laget en klasse MelwinSoapConnection.java som implementerte interfacet A_WebServicRCP.java. De aller fleste metodene som ble generert i interfacet av Axis var ikke relevante for vår applikasjon og vi lot disse stå uimplementert. Utfordringen er at det er vanlig at en fallskjermhopper kan være medlem i flere klubber. Vi måtte derfor legge til en sjekk om hopperen allerede var hentet inn i fra MeLWin, og hvis dette var tilfelle skulle klubben legges til listen over klubber hopperen er medlem i. 53

54 Metoden over tar en liste med klubber og returnerer alle medlemmene som er i disse klubbene. Hvis en klubb er medlem i flere klubber blir klubben lagt til medlemmets klubbliste. Da vi hadde fått inn alle medlemmene skulle det legges til lisenser. Vi måtte bruke SOAP-metoden ws_lisenser for å hente lisensene. Vi måtte da gå igjennom hver klubb igjen for å få lisenser til hvert medlem. På grunn av at det ikke eksisterte en SOAP-metode i MeLWin for å få ut alle fallskjermhoppere i NLF med lisenser, måtte vi bruke metodene for å få samme informasjon fra hver enkelt klubb. Dermed ble hele prosessen ganske så treg, mye på grunn av at autorasjonene på hvert SOAP-kall fort tar et 54

55 par sekunder. Det blir også mange iterasjoner gjennom mange arrayer med sammenligningsoperasjoner for å unngå dobbeltposteringer av personer i databasen Systemkrav Backend For å kunne kjøre applikasjonen må følgende programvare installeres: Oracle-Java 7 64 bit. MongoDB 64 bit, versjon eller nyere Apache webserver (for frontend, andre webservere kan også brukes.) For å kompilere systemet fra kildekoden må Apache Maven, versjon 3, være installert. Java, MongoDB og Apache webserver finnes i versjoner for både Windows, Linux og Mac OS X. Løsningen vår kan derfor kjøre på alle disse plattformene. For systemkrav på forskjellige plattformer henviser vi til sidene for de forskjellige programmene. Vi har kjørt vår løsning under utviklingen på en Ubuntu server versjon plattform. Løsningen er testet på en Amazon EC2 micro instans med følgende spesifikasjoner: Prosessor: Intel(R) Xeon(R) CPU E GHz Minne: GiB Disk: 30 GiB. Denne plattformkonfigurasjonen vil gi nok ytelse for vår løsning. MongoDb bruker en del minne siden den ønsker å cache mest mulig av databasen for økt fart. Hvis databasen blir stor i fremtiden vil ytelsen bli bedre med mye ram på plattformen der løsningen kjører Frontend Frontend kjøres i nettleseren og er plattformuavhengig. AngularJS skal fungere i alle de store nettleserne, men har utfordringer med Internet Explorer 7 og lavere. Bibliotekene UI-Select2 og Bootstrap-datetimepicker opplyses å fungere i de samme nettleserne som AngularJS. Vi har testet applikasjonen i følgende nettlesere med positivt resultat: Firefox Internet Explorer 9 Chrome ios Android 55

56 3.9. Installasjonsveiledning for kjøring på Ubuntu server. Man bør ha en grunnleggende forståelse for Ubuntu-Linux og Debians pakkesystem før man setter i gang. Kildekoden anbefales hentet ned fra github. Anbefalt metode for installering av nødvendig programvare er via Debians pakkeløsning. På utviklingserveren har vi kjørt Apache server på port 80 og Tomcat på port Sjekk at disse portene er åpne. 1. Oracle-Java Oracle-Java er ikke å finne i Ubuntus egne pakke-repositories. I kommandolinja vil følgende installere Oracle-Java: a. sudo add-apt-repository ppa:webupd8team/java b. sudo apt-get update c. sudo apt-get install oracle-java7-installer 2. MongoDB a. sudo apt-get update b. sudo apt-get install mongodb-org 3. Apache Webserver a. sudo apt-get update b. sudo apt-get install apache2 4. Maven a. sudo apt-get update b. sudo apt-get install maven Kjøre løsningen fra kildekode. 1. MongoDB: Først bør databasen settes opp. Dette gjøres ved å kjøre scriptene i mongo-scripts mappen. Det er viktig at fnlfanomaliesdblicenses.js og fnlfanomaliesdbclubs.js kjøres først. Så de resterende scriptene. Scriptene kan kjøre i kommandolinja med: a. mongo /path-til-script/scriptnavn.js b. for å sjekke at alle scriptene er kjørt bør man gå inn i mongo-shellet og sjekke at alle korresponderende collections er opprettet. 2. MelwinSoapclient: Dette er et Mavenprosjekt. Gå til mappen der pom.xml filen ligger og skriv kommandoen: mvn clean install. Må da være online da Maven henter biblioteker fra sentralt Maven repository. melwin.jar er filen som da kan kjøres. Denne klienten er avhengig av at mongoscriptene fnlfanomaliesdblicenses.js og 56

57 fnlfanomaliesdbclubs.js er kjørt og at MongoDB er oppe og går. Sett så opp Cron til å kjøre melwinklienten på ønskede tidspunkter. Disse tidspunktene bør settes når trafikken til serveren har forventet lav belastning. a. Eksempel: 0 2 * * * java -jar /path-til-jar-fil/melwin.jar > /path-til-log-mappe/log.txt Denne setter cron til å kjøre melwin.jar kl hver dag. Utskriften av programmet blir lagt til i filen log.txt 3. Rest-Backend: Backend i tillegg til melwinsoapclient består av enkeltstående Mavenprosjekter som er avhengig av hverandre. a. Start med å gå inn i mappen NLF_Classes og kjør mvn clean install. b. Gjør det samme i mappen NLF_DAL. c. Så det samme i mappen NLF_BLL. d. Til slutt det samme i mappen NLF_RestPortal. e. Filen NLF_RestPortal.jar vil da bli liggende i NLF_RestPortal/target/. Denne filen kan da startes med kommandoen java -jar NLF_RestPortal.jar &. Løsningen har en innbygget Tomcat webserver som vil kjøre på port Frontend: Frontend er statiske dokumenter i mappen frontend/www/. Denne mappestrukturen kan kopieres til default-mappen for Apache web server eller man kan sette opp en symbolsk link til frontend/www/, eller man kan konfiguere web serveren. Se for forskjellige konfigurasjonsmetoder Prosjektstyring F/NLF ville at vi skulle benytte oss av JIRA fra Atlassian som prosjektstyringsverktøy i prosjektet. F/NLF skulle skulle ordne med lisenser for Atlassian, men dette kom aldri i orden. Vi bestemte oss da for å bruke Trello som prosjektstyringsverktøy. Figur 28 - Skjermbilde Trello 57

58 Trello er en web-applikasjon som tilbyr en kanban-tavle. Man setter opp arbeidsoppgaver i en liste og flytter arbeidsoppgavene over i andre lister som hver indikerer status for arbeidsoppgaven. Vi satte opp en tavle for hver sprint og delte opp sprinten i 4 forskjellig tilstander/lister. Den første listen representer backloggen der alle brukerhistoriene for hele prosjektet ble lagt. 58 I den neste listen ble brukerhistoriene og andre oppgaver som var estimert ferdig i løpet av sprinten flyttet fra backlogg-listen. Oppgaven ble tildelt personen(e) som skulle uføre den. Vi brøt de fleste oppgavene i flere deloppgaver og kunne dermed ha oversikt over oppgavens status. I Trello kan man legge til kommentarer til hver oppgave om for eksempel problemer på en oppgave som må løses. For de fleste brukerhistoriene delte vi oppgaven opp i hva som måtte implementeres i de forskjelle lagene i backend, og hva som måtte på plass i frontend før oppgaven kunne få status Done. Trello er et enkelt verktøy som er lett å komme i gang med og ga en god oversikt over arbeidet i hver sprint. Vi hadde bestemt oss for å benytte SCRUM som metodikk og savnet da i Trello muligheter for å legge til verdier for tidsestimering og rangering av brukerverdi. Trello mangler også burndown-chart som brukes i SCRUM for å holde kontroll på framdriften av prosjektet. Vi prøvde en burndown-chart plugin for Trello, men den var ustabil og lite brukervennlig. Vår erfaring med Trello underveis i prosjektet er at det er enkelt og oversiktelig, men er mer egnet for prosjekter som bruker Kanban som metodikk enn SCRUM. Et pluss med Trello er at Klientene for Android og IOS er gode, slik at vi kunne få varsel på telefonen når arbeidsoppgaver endret status eller ble kommentert i prosjektet Versjonskontroll Et versjonskontrollsystem er en programvare som kan holde orden på de forskjellige versjonene av et prosjekt med datafiler. Når en av filene i prosjektet blir oppdatert, fjernet eller flyttet, så vil fortsatt bildet av den tilstanden filen var i før endringstidspunktet være lagret. På den måten kan man gå frem og tilbake i forskjellige versjoner Git På prosjekter med flere deltakere er et versjonsstyringsverktøy nødvendig for å sikre synkronisering mellom deltakerne og god framdrift i prosjektet. Vårt prosjekt som er utviklet i Java og Angular blir antall filer fort veldig høyt. Manuell synkronisering mellom deltakerne ville derfor bli tilnærmet umulig i praksis.

59 Tidligere i studiet har vi brukt subversion og git som versjonsstyringsverktøy. Vi valgte å bruke Git på dette prosjektet og Github som sentralt repository. Hovedforskjellen mellom Git og subversion er at Git er et distribuert versjonskontrollsystem. Hver utvikler kan jobbe mot sin lokale versjon. Versjonene kan sammenflettes med andre versjoner, både fra samme utvikler og versjoner fra andre utviklere. Med subversjon må alle deltakere jobbe mot samme sentrale utviklingstråd. Med Git kan hver utvikler jobbe mot sin egen branch med sin delegerte oppgave. Når oppgaven er utført og testet kan utvikleren flette sin branch inn i hovedgrenen. For synkronisering mellom prosjektdeltakerne brukte vi Github som er et nettsted som tilbyr gratis, sentrale Git-repositorys. Vi brukte et lukket repository under utviklingen da vi hadde passord til innlogging til MeLWin i kildekoden. Via github har også veilederne fra Accenture og Einar Huseby fra F/NLF hatt tilgang til kildekoden. Githubs brukergrensesnitt gjør det enkelt å følge brancher og hvordan de forskjellige versjonene i branchene er commited kronologisk i forhold til hverandre. Bildet over er fra github og viser en tidslinje med forskjellige branches og commitene i hver branch og sammenfletting av brancher. 59

60 3.12. IDE - (Integrated Development Environment) Eclipse Eclipse er en open-source IDE skrevet hovedsaklig i Java. Eclipse støtter for utvikling i bl.a. Java, C, C++, JavaScript, PERL, PHP, Python, Ruby og Fortran m.m. Eclipse ble benyttet for utvikling av backend. Vi brukte utvidet støtte for Spring, Maven og Git. Som nevnt hadde vi jo flere lag i prosjektet, lagt inn med tanke på skalerbarhet, og lagene ble lagt inn som avhengigheter og ressurser til de andre prosjektene. Eclipse fungerer godt med Spring og Spring-Boot og det er lett å testkjøre applikasjonen i og fra Eclipse. IDE en støtter Unit-testing med JUnit og dette har vært særdeles nyttig. I tillegg er det lett å identifisere feil, når de oppstår. Java forklarer godt og tydelig hva som er feil og hvor det evt. feiler. Eclipse inkluderer Eclipse Java Development Tools (JDT) og har en inkrementell Java-kompilerer som tillater avanserte refaktoreringsoperasjoner. Det har også sin egen workspace hvor den oppbevarer oppdaterte metadata til prosjektene. Erfaring Vi hadde vært borte i Eclipse før, men ikke mye. Det gikk greit og raskt å sette seg inn i IDE en og vi fikk oversikt tidlig. Arbeidet i Eclipse har forløpet uten store problemer og produktiviteten har vært jevnt god. Et negativt punkt vi kan nevne ved å bruke Eclipse, i hvertfall i vårt tilfelle, har vært at den har sin egen workspace og har ikke hatt problemer med å importere avhengigheter fra de andre prosjektlagene vi hadde. Dette merket vi imidlertid fort da vi skulle bygge prosjektet med Maven utenfor Eclipse s sitt utviklingsmiljø. Da slet den med å finne ressursene fra de andre prosjektlagene og applikasjonskonteksten ble ikke lastet inn riktig. Dette måtte vi da skrive nye tester på og få prosjektet til å bygge uavhengig av Eclipse sitt utviklingsmiljø. Dette var viktig å få til da vi ikke ville binde fremtidige utviklere til en bestemt IDE. Bortsett fra at vi ikke var helt klar over dette i begynnelsen, så har IDE en vært god å bruke NetBeans versjon 7.4 NetBeans er en open-source IDE (Integrated Development Environment) for utvikling av systemer i blant annet språkene Java, C/C++, PHP, HTML5, CSS og JavaScript. NetBeans ble benyttet for utvikling av frontend, HTML5, CSS og JavaScript. Programmet har syntaksmerking av all kode, og NetBeans leveres med et programtillegg til blant andre nettleseren Chrome som tilbyr Live Preview av all kode. Programtillegget er en svært god hjelp ved feilsøking, og gir utskrift av eventuelle feil, nettverkstrafikk, variabelverdier osv. NetBeans har funksjonalitet for Git-kommandoer, og merker alle filer med tilstander dersom de er up to date, lagt til eller endret. 60

61 Erfaring NetBeans ble valgt som IDE til frontend pga gruppemedlemmenes gode erfaringer fra tidligere prosjekter. Programmet har levd opp til forventningene på alle områder og har vært til god hjelp under utviklingen Sublime Sublime er en teksteditor med syntaksmerking for en mengde programmeringsspråk. Sublime har mange av de vanligst brukte funksjonaliteten til en IDE. Sublime er mindre omfattende enn for eksempel Eclipse og NetBeans og bedre egnet for arbeid mot enkeltfiler og ikke prosjekter. Sublime ble brukt for å skrive scriptene for å sette opp collections i MongoDB. MongoDB bruker JavaScript notasjon på scriptene. Det var raskere å bruke en teksteditor til dette enn med en tyngre IDE Database For prosjektet fikk vi ganske frie tøyler fra F/NLF til valg av verktøy og rammeverk for å løse oppgaven. Det samme gjaldt valg av databasesystemer. Einar Huseby ba oss se på mulighetene for å bruke en NoSQL dokument- eller grafdatabase i stedet for en relasjonsdatabase. Tidligere under studiet har vi kunnet jobbet med relasjonsdatabaser. Dokument- og grafdatabaser var helt nytt for oss. Vi måtte derfor sette oss inn i NoSQL teknologiene for å kunne vurdere om de var bedre egnet enn en relasjonsdatabase for vårt prosjekt. Etter at vi hadde satt oss inn i de forskjellige databasetypene bestemte vi oss for å bruke en dokumentdatabase kalt MongoDB. Her følger en nærmere beskrivelse av de forskjellige typer databaser som var aktuelle med begrunnelse for vårt valg Relasjonsdatabase I en relasjonsdatabase er data organisert i tabeller i form av rader og kolonner. En rad beskriver en entitet, mens en kolonne beskriver en datatype. Alle data blir derfor lagret etter en bestemt struktur etter et predefinert skjema. Relasjonsdatabaser blir også kalt skjemabaserte databaser. For å unngå å lagre redundant informasjon kan man normalisere databasen og dele data opp i flere tabeller. Relasjonene mellom tabellene er angitt med et nøkkel datafelt i minst to tabeller. For å lese og manipulere data i relasjonsdatabase bruker man et standardisert språk SQL. Hvis data er fordelt over flere tabeller kan man lese og manipulere disse dataene ved å konstruere en SQL setning. Fordeler Med en normalisert database slipper man å lagre redundant informasjon og sparer dermed lagringsplass. 61

62 Med relasjoner og en normalisert database er ofte oppdateringer av data raskere. Det holder å oppdatere en tabell og la andre tabeller ha en relasjon til denne tabellen. SQL er et standard språk for å jobbe med databaser og man kan bruke den samme syntaksen på nesten alle typer relasjonsdatabaser med små endringer i syntaksen. I vår applikasjon har vi et datatilgangslag som har ansvaret for kommunikasjonen med databasen. Hvis vi hadde benyttet en relasjonsdatabase og skulle bytte den med en annen database ville spørringene i metodene vært trolig identiske og lite refaktorering ville være nødvendig. For databaser der det skal gjøres mange transaksjoner er det en fordel med tabeller og relasjoner Relasjonsdatabaser følger ACID (Atomicity, Consistency, Isolation, Durability) prinsippene. Ulemper: Skalering, relasjonsdatabaser er lettest vertikalt skalerbare. Det vil si at hvis man trenger mer lagringsplass eller fart er den letteste måten å øke den fysiske lagringplassen på den enheten databasen kjører på. Det kan gjøres ved å bytte ut harddisken med en disk med større lagringskapasitet eller legge til flere disker til samme enhet. For fart må enten prosessor byttes, minne byttes eller legges til. Alt dette løses lettest ved å legge til ressurser på enheten databasesystem kjører på. Å distribuere databasen over flere enheter vil kunne gå ut over ytelsen, da det vil bli mye trafikke som skal passere over nettverket mellom enhetene. Pris, på de fleste nettskyleverandører er tjenester basert på relasjonsdatabaser dyrer enn NoSQL baserte løsninger. Ved endringer i datastrukturen som skal lagres, kan det det bli mye arbeid med å restruktuere data og tabellene i relasjonsdatabasene. Utvikling kan derfor gå tregere ved smidig metodikk, da man oftest ikke har en fastsatt datastruktur under hele utviklingsprosjektet. Datastrukturene i en relasjonsdatabase er ofte forskjellig fra datastrukturen som brukes i en applikasjon som er utviklet i et objektorientert språk. Man blir fort avhengig av ORMrammeverk som Hibernate til Java eller Entity Framework til.net NoSQL-database En samlebetegnelse på databaser som ikke er relasjonsdatabaser blir ofte kalt NoSQL-databaser. Dette er databaser som ikke organiserer data etter tabeller og relasjoner. NoSQL er en forkortelse for Not only SQL. Denne typen databaser må ikke ha SQL som spørrespråk, men kan ha det. Et fellestrekk for NoSQL databaser er at de er såkalt skjemaløse, de behøver ikke å følge en fast mal for datastrukturen. Det er flere grupper NoSQL-databaser. Her er noen av de mest brukte: Dokumentdatabaser 62

63 En nøkkel-verdi datastruktur der verdien kan være en kompleks datastruktur kalt dokument. Eksempler databasesystemer: MongoDB, CoachDB Key-value databaser En nøkkel-verdi datastruktur der verdien er en enklere datatype. Eksempler databasesystemer: Google Cloud Datastore, Redis. Grafdatabaser. Består av noder med nøkkel-verdi par. Noder har relasjoner med andre noder. Hver relasjon kan sine datafelter og har en start- og stoppnode. Grafdatabaser er baser på graf-teori. Eksempler databasesystemer: Neo4J, HyperGraphDB Wide column stores Her lagres data i tabeller, men bare i kolonner ikke rader. Fordeler: Eksempler databasesystemer: Cassandra, HBase Skalering, NoSQL databaser kan skaleres horisontalt. For å øke ytelse og kapasitet kan man enklere enn med relasjonsdatabaser fordele databasen over flere servere og over flere datasentre. Skjemaløs, ustrukturerte datastruktur gjør at endringer i datastrukturen underveis i utviklingen går raskere enn ved relasjonsdatabaser. Pris, for løsninger som kjører i nettskyen er NoSQL databaser som oftest billigere. Bruker ofte et datalagringsformat som er helt eller svært likt et vanlig programmeringsspråk. For eksempel bruker dokumentdatabasen MongoDB BSON som lagringsformat som er en binær form av JSON. Fart, hvis data for det meste skal legges til eller leses vil en NoSQL database ofte være raskere enn en relasjonsdatabase. Ulemper: NoSQL databaser bruker ikke et standard spørrespråk som SQL. Hva slags språk hvert databasesystem bruker kan variere. Hvis man skal bruke et nytt databasespråk må man derfor beregne tid til å lære seg API språket. Valg Kapasitet vs Ytelse, ved bruk av NoSQL må man ofte ta valget om man skal normalisere: Man kan normalisere for å spare plass, men får da dårligere ytelse fordi NoSQL databaser trenger å utføre flere spørringer enn ved en SQL-spørring som bruker JOIN. Ved å droppe normalisering vil man få raskere spørringer, men det blir lagret mer 63

64 redundant informasjon. Fart, fordi NoSQL databaser ofte ikke er normalisert vil ofte spørringer som går på oppdatering være tregere enn ved relasjonsdatabaser. Ikke alle NoSQL databaser følger ACID prinsippene for transaksjoner, man kan derfor som utvikler eller som driftsansvarlig få seg noen overraskelser hvis man tar dette for gitt. Utbredelse, for videre drift og utvikling vil det være lettere å skaffe kompetanse på mer utbredte relasjonsdatabaser enn å finne kompetanse på de mindre utbredte NoSQLdatabasene Vårt valg av databasesystem. Etter å ha satt oss mer inn i NoSQL databaser bestemte vi oss for å bruke en dokumentdatabase MongoDB. Hovedgrunnen var at MongoDB kan lagre ustrukturerte data og det er mindre jobb med endringer i databasestrukturen. Vi hadde på tidligere tatt avgjørelsen at vi ville benytte Java og Spring i backend. API et mellom Java og MongoDB var godt dokumentert og det var relativt greit å komme i gang. Spring hadde et eget rammeverk for koblinger mellom applikasjoner og Mongodatabaser så denne databasetypen ville da være enkelt å komme i gang med. Datastruktruren i MongoDB, BSON er veldig lik JSON som vi brukte som dataoverføringsformat i REST API et. Dataobjektene fra database til frontend kunne da ha lik form. I tillegg er MongoDB open-source og gratis Byggverktøy Byggverktøy er verktøy som skal hjelpe deg som utvikler ved å forenkle byggeprosessen av ditt prosjekt. Vanligvis styrer de avhengigheter, ressurser, kompiler og bygging av prosjektet Maven Maven betyr Accumulator of knowledge og er et byggverktøy for Java. Maven ble brukt til avhengighetsstyring, kompilering, bygging og testing. Vi vurderte også Ant og Gradle, men endte på Maven da dette gav inntrykket av å være mest brukt, pluss at våre veiledere i Accenture var godt kjent med det. Maven er nyttig å bruke da man kan spesifisere de avhengighetene man trenger til prosjektet og å kompilere og bygge det. Siden vi har lagdelt prosjektet vårt i domenemodell (Classes), dataksesslag (datalayer), logikklaget (logiclayer), REST-lag (restlayer) og frontend, så bruker vi Maven til å legge inn datalayer som en avhengighet hos logikklaget, likeledes gjør vi med logikklaget og legger det inn som avhengighet i REST-laget. 64

65 Erfaringer og utfordringer med Maven Vår erfaring med Maven er veldig positiv, og det har vært verdifullt å ta seg tid til å lære seg dette. Å importere avhengigheter og sette opp bygg informasjon har vel vært det viktigste det er blitt brukt til. I tillegg kjører den gjennom junit testene våre og sjekker at alt er på stell ved kompilering og bygging. En av utfordringene med å bruke Maven var integrasjonen med Eclipse. Det som Eclipse gjør er at den bygger og kompilerer prosjektene sine på egen måte ved hjelp av «Maven update project». Problemet her er at Eclipse importerer avhengigheter og løser opp i små konfigurasjoner og importeringer man eventuelt har glemt. Så når vi da skulle bygge og kjøre prosjektet med «mvn clean install» fikk vi feil under kjøring av at jar-fila vår ikke fant bønnedefinisjonen. Bønnene og Servicene er fordelt over flere prosjekter, og vi hadde ikke konfigurert Mavens konfigurasjonsfil «pom.xml» til å laste applikasjonskonteksten vår riktig. Vi satte da opp en junit-test for å laste inn applikasjonskonfigurasjonen og injisere en bønne i denne testen. Deretter fulgte vi feilloggen og fikk til slutt lastet inn konfigurasjonen riktig. Det er veldig viktig at prosjektet kunne bygges uten å måtte være avhengig av Eclipse. Det skal kunne lastes inn i ønsket IDE. En lærdom vi kan trekke ut av dette er å ikke stole for mye på autokonfigurasjoner, i f.eks. Eclipse IDE, og være flinkere til å skrive flere tester i starten av prosjektet Anvendt rammeverk, biblioteker og programmeringsspråk Java Java er et open source klassebasert og objektorientert programmeringsspråk. Java følger WORAprinsippet (Write once, run anywhere). Dette betyr at koden ikke trenger å kompileres på nytt for andre plattformer. Java er et av de mest populære programmeringsspråkene i verden, og da spesielt for klient-server web applikasjoner. Vi valgte Java pga stort community og fordi det er open source, noe som hadde betydning for kunden Spring Framework 3 Spring er et rammeverk for Java håndterer mye av infrastrukturen for deg, som frigjør mer fokus til utvikling. Rammeverket er også modulært, dvs. du kan selv velge de avhengighetene Spring skal ha med og ikke med. Det tilbyr bl.a. et fullverdig MVC-rammeverk, og AOP (Aspect Oriented Programming). Spring tilbyr også Dependency Injection og Inversion of Control. Dependency Injection kan forklares på denne måten; hvis klasse A har en avhengighet til klasse B, og klasse A bruker klasse B som en variabel. Her kan man injisere klasse B inn i klasse A uten å måtte instansiere klassen. I Spring kan annotasjonen til å injisere klassene i hverandre. 65

66 Hvorfor velge Spring? Spring er et av de største og mest brukte rammeverket i industrien. I tillegg til å ha et stort community, som åpenbart er en fordel, så får man også gjort en mer kodeeffektiv jobb. Noen av grunnene til at vi valgte Spring, er: Stort community. Rammeverket bruker ikke mye minne eller CPU-sykluser på å laste bønner, hente services eller transaksjoner. Forenkler database interaksjon. Spring konfigurasjon gjøres i xml eller ved hjelp av annotasjoner (Spring 3 >), som er relativt lett å lese og forstå. Løst koblede applikasjoner ved hjelp av Dependency Injection. Kodeeffektivt. Man kan få gjort mer arbeid for hver linje med kode. Lett å teste, da Spring tilbyr unit testing support klasser Utvikling med Spring I prosjektet har vi domenemodellen og den inneholder rene POJO-klasser (Plain Old Java Objects) med GET- og SET-metoder. POJO-klassene brukes i sammenheng med opprettelse av nye objekter, og lesing og skriving til databasen. Et eksempel på hvordan vi har tatt i bruk Spring kan være databaseinteraksjonen vår hvor vi har tatt i bruk Spring Data. Spring Data for MongoDb gjør det mulig å gjøre spørringer og å lagre objekter til databasen ved å referere til en klassemal. I vårt tilfelle opprettet vi for oppkobling til databasen som så ble brukt for spørringer. Det er mye «magi» som skjer i Spring og vi kan spørre etter et objekt med en spørring og referere til en klasse, og dermed blir det slått opp i riktig databasekolleksjon og spørringen blir utført der. Klassene i Dataaksesslaget bruker da MongoDb bønnene til å lese og skrive til/ fra databasen. Disse klassene er merket annotasjon og blir da en annotasjonsklasse. Dette kan igjen injiseres inn i logikklaget og bruke metodene der, uten å måtte instansiere klassen. I det øverste kontroller-laget i REST, «mappes» dataene ut til ulike URI er (Uniform Resource Identifier). Dette gjøres ved hjelp av Dataene mappes ut til en URI, og kan aksesseres av ulike applikasjoner med de 66

67 rette tilgangene. Aksessen er i vårt tilfelle begrenset til aksess fra server, men i utviklingsperioden har vi hatt behov for å ha Backend på server og så har vi hatt Frontend lokalt med aksess mot server. For å få til dette har vi brukt CORS (Cross Origin Resource Sharing) som spesifiserer hvilke domener som har lov til å aksessere ressursene og eventuelt hvilke headers som er lovlige. Frontend er enkeltstående og skal i utgangspunktet ligge på samme host. I tillegg er det satt inn autentisering og autorisering ved hjelp av Spring Security. Access-Control-Allow-Origin: Eksempel på origin access control Vår erfaring med Spring Noen av våre utfordringer var at vi ikke hadde noen erfaringer med Spring, Maven, MongoDB eller JUnit. Derfor ble det en rimelig bratt læringskurve, med noen småfall på veien. Spring Data og skriving og lesing til MongoDB gikk rimelig smertefritt med Spring, da vi lett fant frem til dokumentasjon på dette og gode eksempler. Utfordringene gikk til dette gikk mest på oppbyggingen av klassene og referanser i MongoDB. Lagdelingen og instansieringen av klasser lagde et problem for oss, da vi helt i begynnelsen ikke opprettet bønner (Spring Beans). Istedenfor å injisere klassen som en service inn i en annen klasse, så opprettet vi en ny instans av klassen. Dette fikk vi ryddet opp i ganske fort og satt oss godt inn i Spring sine annotasjoner og DI (Dependency Injection). Det fungerer slik at man bruker klassen som en dependency, uten å instansiere den. Deretter kan man bruke avhengighetens metoder. De fleste av tjenestene (@Service) og bønnene er laget med Java annotasjoner, mens noen ting følte vi det var tryggere å bruke xml på. Veilederne våre anbefalte også å bruke xml, da man har mer kontroll på bønnene og konfigurasjonene sine. Vi brukte i midlertidig annotasjoner på tjenestene i datalayer og xml konfigurasjon på security-konfigurasjonen. Et eksempel på dette er i Spring Security hvor vi, ikke nødvendigvis fikk mer kontroll enn ved annotasjoner, men fikk det mer oversiktlig for oss selv og forhåpentligvis for fremtidige utviklere Spring Security 3.0 Vi har brukt Spring Security for autorisering og autentisering. Valget om å ta i bruk Spring Security for sikkerhet ble et ganske naturlig valg siden vi allerede hadde valgt Spring rammeverket, og Spring Security er også kodeeffektivt. Sikkerheten er satt opp på den måten at ulike ressurser er bare tilgjengelig etter innlogging og bare hvis man har de rette tilgangene/ rollene. 67

68 Rollene er delt opp i autorisasjonsnivåer user, HL, HI, SU og Fagsjef. For utfyllende informasjon om rollene i rapporteringsprosessen, se vedlegg 1, F/NLF. User-rollen har ingen særskilte rettigheter, annet enn at personen skal ha tilgang til å se hvilke avvik som er registrert på en selv. Man har krav på user-tilgang såfremt man har betalt årskontigent til F/NLF. HL (Hoppleder) tilgangen har skrivetilganger på avvik og kan registerere avvik på andre. Man har HL-tilgang om man har C- eller D-sertifikat. Dette er to av totalt 5 sertifikater man kan ha. Om man har C- eller D-sertifikat har man altså HL-tilgang. Dette sjekkes av SecurityService.java i datalayer. HI (Hovedinstruktør) tilgangen har i tillegg leserettigheter på avvik tilknyttet klubber og medlemmer. SU (Sikkerhet- og utdanningskomiteen) har leserettigheter til alle avvik, medlemmer og klubber. Fagsjef-rollen fungerer som en superadministrator med tilgang til å skrive, lese og slette absolutt alt av data. Brukernavn og passord ligger i databasen hashes med SHA-256, og brukerne kan ha rollene user, HL, HI, SU, Fagsjef. Rollene er listet opp etter tilganger i stigende rekkefølge. Rollen Fagsjef tilsvarer en superadministrator. Passord og brukernavn blir skrevet inn ved innlogging og verifisert eller avslått. Deretter utstedes en billett (token) til klienten som brukes som et bevis på at man har tillatelse til å aksessere dataene. Billetten ødelegges i det man logger ut av webapplikasjonen. XML er brukt til å definere tilgangene på ressursene, og de ulike ressursene er merket med minimumstilganger for aksess. På kodesnutten nedenfor ser vi for eksempel tilgangsstyringen på CRUD operasjoner på ressursen «clubs». Vi ser at å hente (GET) klubbinformasjon skal være tilgjengelig for alle. Å oppdatere klubbinformasjon derimot skal kun gjøres av de med HI-tilgang eller høyere, da de med HI-tilgang er sjef for klubben det gjelder. I dialog med fallskjermseksjonen er det også ønskelig at SU (Sikkerhets- og utdanningskomiteen) har tilgang til dette. Å poste nye klubber og/ eller å slette klubber, er det derimot bare Fagsjef som skal kunne gjøre. 68

69 I tillegg til XML, må det også lages logikk på om brukeren har tilgang på visse ressurser. En bruker med user -tilgang har ikke tilgang til å lese avvik, bortsett fra de eventuelle avvikene han/hun selv er involvert i. Anomalies ressursen er da sikret på måten vi ser i bildet under. Metodene isauthorized() sjekker om brukeren har HL-tilgang eller høyere, og isauthorizedtoviewanomaly(id) sjekker om brukeren er involvert i avviket han/hun prøver å se på. Dette gjøres ved at identifikatoren til avviket sendes med i metoden, og man henter ut de involverte personene der. Hvis en av de involverte sin id er lik brukernavnet til personen som er logget inn (brukernavn og fallskjermhopper ID er de samme), så har han/hun leserettigheter til det avviket. Metoden isauthorizedtoviewanomaly(id) er gjengitt under. 69

70 3.16. Innlogging Sikkerheten og innlogging på frontend håndteres av AngularJS. AngularJS sender inn brukernavn og passord som verifiseres av Backend, deretter sendes en billett/ token tilbake som AngularJS sender med i headeren for videre forespørsler. Når bruker logger ut, så slettes user og authtoken fra angularjs og i fra Cookien. AngularJS bruker både token og cookies. Ved innlogging kan man velge å bli husket og innloggingsinformasjonen ligger lagret til neste gang man kommer inn på siden. Det vil ikke si at man er permanent logget inn, men man kan la brukernavn og passord bli husket i en sesjon. Man kan altså når som helst ødelegge innloggingsinformasjonen fra applikasjonen Spring Boot Spring Boot gjør det enklere å produsere en stand-alone Spring-basert applikasjon som kan kjøres. Spring Boot legger til rette alle de avhengigheter og ressurser man trenger. Man kan bruke Spring Boot til å lage tradisjonelle war-deployments, eller man kan produsere en kjørbar jar fil. Og det er det vi har gjort i dette prosjektet. 70

71 Vi bruker også en innebygd Tomcat server i applikasjonen vår, det vil si når man starter jar fila, starter den på en innebygd Tomcat server. Hele Backend kan altså pakkes, leveres og startes som en jar fil. F/NLF skal selv stå for egen host hvor de skal bruke SSL (Secure Socket Layer) for å kryptere trafikken. I vårt tilfelle har vi ikke fått midler til å kjøpe eget sikkerhetssertifikat enda, men F/NLF har ønsket å kunne ha Backend kjørende på https. Dette la vi til rette for å lagde en versjon av prosjektet hvor Spring-Boot initierer applikasjonen med Tomcat konfigurert til å kjøre på https. En midlertidig løsning har derfor vært å lage vårt eget selvsignerte sertifikat. Det er sikret med en RSA algoritme og keysize Det at applikasjonen kjører over https er laget som en bønne i application.java og kan enkelt fjernes, og heller bruke et offentlig signert sertifikat. Den innebygde Tomcat serveren startes opp på https i dag JUnit JUnit er et open source unit testing rammeverk for Java. Det er designet for å skrive og å kjøre tester. Testing har hovedsaklig gått på testing av skriving og lesing til database. Testene er bygd opp slik at vi returnert en forklarende melding om testen feilet. Hvis den er vellykket, får vi beskjed om at testen er gått i gjennom vellykket. Eksempel på tester som er gjennomført er: Å lagre data til databasen Sjekke at applikasjonskonteksten og bønnene blir riktig lastet inn Sjekke at data ble lagret Oppdatere data og sjekke at det ble oppdatert Slette data og sjekke at de har opphørt å eksistere Lagre passord med hashing og sjekke at den hashes riktig Sjekke at data med høye autoriseringskrav ikke kan aksesseres av brukere med lavere autorisering. 71

72 3.19. AngularJS AngularJS er et open source MVC (Model View Controller) JavaScript rammeverk for utvikling av dynamiske single-page webapplikasjoner. Rammeverket hadde sin første release i 2009, og blir i dag utviklet av Google og frivillige bidragsytere. Innen IT-bransjen har AngularJS blitt omtalt som en hype som fortsatt er i vekst, og at antallet større prosjekter som velger AngularJS vil øke i årene som kommer. Viktige funksjoner: To-veis databinding AngularJS tilbyr en mengde verktøy for å bygge store JavaScript applikasjoner med minst mulig kode. Den kanskje viktigste funksjonen er to-veis databinding, som innebærer at endringer i View et umiddelbart reflekteres i modellen, og vice-versa. ng-model Definerer variabelnavn med to-veis databinding mellom view og scope. 72

73 ng-controller Definerer JavaScript controlleren som skal evaluere HTML-koden. En ng-controller kan defineres for alt fra en hel side eller kun ett objekt, og controllere kan flettes om nødvendig. ng-repeat Instansierer et element for hver verdi i en collection. ng-show og ng-hide Viser eller skjuler elementer basert på et boolsk uttrykk. Hvorfor AngularJS? Vår hovedoppgave har vært å utvikle et solid API for rapportering av avvik. Et fungerende frontend var ønskelig fra kunden, men ikke et must i dette prosjektet, og vi ønsket derfor å benytte rammeverk som passet til vårt system og som ville forenkle utviklingen. Et av kundens ønsker var at initialiseringen av en rapport skulle kunne gjøres via mobil, og valget falt da raskt på Twitter Bootstrap som rammeverk for CSS. AngularJS fungerer i de mest brukte nettlesere, er godt kompatibelt med Bootstrap, og ble anbefalt både fra skolens side og veilederne. Erfaring AngularJS er relativt nytt, stort og komplekst, og i tillegg under kontinuerlig utvikling. Det er ikke så mange store, gode ressurser å finne, noe som har krevd en god del mer innsats enn det vi så for oss fra starten av. Mange av ressursene vi fant viste seg å være utdaterte, selv om de var under ett år gamle. En utfordring med JavaScript er asynkroniteten, som betyr at programmet fortsetter videre selv om en funksjon ikke har gjort seg ferdig. Dette ga oss utfordringer i situasjoner der vi skulle finne objekter det var referert til i et annet objekt. Et eksempel her er når systemet skal finne en involvert persons lisenser, og krysse av de riktige checkboxene. Her måtte vi sørge for at lisenser ble lastet inn i klienten før søket etter lisenser ble påbegynt. Om systemet forsøker å skrive ut en involvert persons lisenser før lisensarrayet er lastet inn i klienten, vil hver lisens bli definert som undefined, og checkboksen vil ikke markere at det i systemet er angitt at denne personen innehar den gjeldende lisensen. Selv om det har vært en del utfordringer med AngularJS, ser vi på dette som en positiv erfaring med høy og nyttig læringsverdi. Frontend av vårt system manipulerer JSON-objekter, og dette egner AngularJS seg svært godt til. Siden AngularJS er et MVC rammeverk, er det mulig å hente data direkte fra databasen. Oppgaven vår var dog å lage et REST- API med en high fidelity prototype, så AngularJS kommuniserer med REST-API et. 73

74 3.20. UI-Select2 Select2 er et jquery bibliotek for å lage søkbare selectbokser. I motsetning til vanlige HTML selectboxer, gjør Select2 innholdet søkbart. UI-Select2 er en såkalt wrapper, en innpakning, for å tilpasse biblioteket til AngularJS. Dette biblioteket ble benyttet på alle selectbokser i frontend, og gjør det enklere for brukeren å finne ønsket valg. UI-Select2 kan settes opp til å la brukeren velge en eller flere elementer. Vi brukte muligheten for flere (multiple) valg på involverte personer, mens valg slik som klubb og lokasjon ble satt til singleselect. Søkbare selectbokser kalles token input, og vi forsøkte flere forskjellige biblioteker for å oppnå denne funksjonaliteten, blant annet tokeninput og Chosen. Felles for dem alle var at de var relativt vanskelige å sette opp, de fungerte dårlig med objekter. Valget falt likevel til slutt på UI-select2, da det var den eneste som også fungerte på mobil. 74

75 Vi hadde ganske store problemer med å implementere søkbare selectbokser. Funksjonaliteten vi ønsket var som følger: Objektene skal hentes fra databasen Objektene skal være søkbare Dersom brukeren har valgt ett eller flere objekter tidligere, så skal disse være valgt i selectboksen når vinduet åpnes Utfordringen var at Angular oppretter en ny instans av objektet ved opprettelse av selectboksen, og sammenlikner dette objektet med det objektet brukeren eventuelt har valgt tidligere. Siden det da er to forskjellige instanser av det samme objektet, matcher ikke Angular disse, og resultatet er at tidligere valg ikke blir vist selv om objektet ligger lagret i avviket. Løsningen ble å benytte objektet sin unike id i selectboksene, og i controllerne søke etter objekt med samme id. Siden objektene kunne være forhåndsvalgt og brukeren skal kunne legge til eller fjerne objektene, måtte det i kontrolleren opprettes en ny midlertidig variabel, og denne må til slutt kopieres over i det virkelige objektet Bootstrap-datetimepicker For valg av dato og tidspunkt har vi valgt å bruke Bootstrap datetimepicker, et JavaScript bibliotek som igjen bygger på biblioteket moment.js. Moment inneholder en mengde forskjellige funksjoner for manipulering av dato og tid. Bootstrap datetimepicker er en enkel widget for valg av dato og tidspunkt, og fungerer godt på mobil. 75

76 3.22. Twitter Bootstrap 3.0 Bootstrap ble laget hos Twitter rundt midten av Bootstrap har blitt et av de mest populære front-end rammeverkene og open source prosjektene i verden. Bootstrap sitt bibliotek inneholder responsiv funksjonalitet og gjør at nettsidens utseende blir justert i forhold til hvilke enheter man bruker. Horisontale visninger på store pc-skjermer blir til vertikale, smarte visninger på en smarttelefon. For å sikre korrekt prosessering og visning, legges det til en meta tag i <head>. Boostrap 3 operer med klasser, og man kan enkel lage responsive bilder ved å referere til.imgresponsiv klassen. Bootstrap bruker et grid system for å holde orden på innholdet. Helt enkelt kan man tenke på det som en tabell med celler eller Java s gridlayout. En rad inneholder 12 kolonner, før man går over på en ny rad. Radene blir definert ved.row. Får å plassere innholdet inn i kolonne, så velger man hvor mange kolonner innholdet skal oppta. For eksempel kan man lage en div tag med class= «col-md-2» 76

77 og innholdet i denne div tagg en opptar nå 2 kolonner av totalt 12 på denne siden. Dvs. at man har 10 kolonner igjen å gå på. Går man over 12 kolonner, vil man begynne på en nye rad. Innholdet i de forskjellige kolonnene vil også stakke seg oppå hverandre jo mindre skjermen blir. På en mobil enhet vil innholdet representeres vertikalt. Figur 1 - illustrasjon hentet fra getboostrap.com Rammeverket forenkler oppgaven med å skrive responsiv kode, og selv om det ikke er noe krav til at siden skal kunne tilpasses mobile enheter, så er det allikevel en liten anstrengelse med stort utbytte. Bootstrap-biblioteket inneholder også templates for tabeller, knapper og skjemaer. Her går det på feltenes stil og utseende. Å bruke dette gjør at man får et moderne og tidsriktig utseende på nettsiden Valg om å ikke kommentere kildekoden Kildekoden vår har vi valgt skal være uten kommentarer, da kommentarer til metoder og klasser har en tendens til ikke å bli oppdatert ved videreutvikling. Et av prinsippene i smidig utvikling er også at man skal sette fungerende kildekode fremfor dokumentasjon. Så ved å ha selvforklarende metode-, variabel- og klassenavn skal man ideelt sett kunne skjønne koden uten kommentarer. For øvrig har vi bedrevet noe kommentering av kode under produksjon, men mest for egne interesser. Både for å hjelpe hverandre til å forklare hva de forskjellige metodene gjør, og for å markere ting for hverandre. I ettertid har vi sett at dette er unødvendig, og at ved ha konsistente og selvforklarende metodenavn oppnår man det samme. 77

78 4. Prosessbeskrivelse 4.1. Innledning Denne delen beskriver prosjektperioden fra starten høsten 2013 og frem til innlevering våren Prosjektbeskrivelsen er skrevet for sensor, våre veiledere og andre som måtte ha interesse av å sette seg inn i arbeidet vi har lagt ned i dette prosjektet. Leseren av prosessdokumentasjonen forventes å ha grunnleggende kunnskap om systemutvikling og datateknologi. For beskrivelse av produktet henvises det til del 2, Produktbeskrivelse Planlegging / Forprosjekt Valg av ekstern veileder Etter deltakelse på forskjellige studentarrangement i regi av Accenture, ble vi oppfordret til å søke om veiledning hos Accenture. Studentgruppen hadde opparbeidet et positivt inntrykk av Accenture gjennom deres studentarrangementer, og deres opplegg for veiledning av bacheloroppgaver virket svært godt. Søknad ble sendt og innvilget i september Valg av oppgave / oppdragsgiver Morten og Tore har gjennom egen fallskjermhopping erfart behovet for et nytt rapporteringssystem for avvik, og ønsket derfor å søke F/NLF om å kunne benytte dette som bacheloroppgave. Oppgaven ble diskutert med Accenture, og de mente dette var en god bacheloroppgave. Søknaden ble sendt til F/NLF og innvilget i august Valg av intern veileder HiOA har som tradisjon å tildele veiledere til de ulike studentgruppene. Da listen over tilgjengelige veiledere ble publisert valgte vi å søke om å få Eva Hadler Vihovde som veileder. Vi har alle hatt Eva som veileder i tidligere fag, og opplegget Eva har for veiledning av bacheloroppgaver virket mer omfattende og gjennomført enn det vi kunne forvente. Søknad ble sendt og innvilget i oktober Kontrakter Siden vi nå hadde oppdragsgiver og ekstern veileder fra forskjellige organisasjoner ble vi nødt til å skrive to kontrakter. En kontrakt basert på skolens standardmal som ble inngått mellom oss og F/NLF, og en tilleggskontrakt som ble inngått mellom oss og Accenture. På denne måten ble F/NLF rettmessige eiere av det ferdige produktet, og Accenture forpliktet seg til å stille med veiledere gjennom hele prosjektperioden. Innhenting av brukerhistorier F/NLF har hatt et ønske om et elektronisk rapporteringssystem siden 2008, men prosjektet har ikke kommet igang før nå, mye på grunn av økonomiske begrensninger. I 2008 ble det skrevet en avhandling som beskrev F/NLF s behov på det tidspunktet, og flere sentrale personer innen fallskjermmiljøet har siden den gang gjort seg opp en egen mening om hvordan et elektronisk avviksrapporteringssystem bør fungere. 78

79 I samarbeid med F/NLF ved Sikkerhet- og Utdanningskomittéen, valgte vi å gå bredt ut for å samle inn brukerhistorier, og dermed involvere så mange potensielle brukere og brukergrupper som mulig. Epost til sentrale personer i klubbene, slik som ledere, Hovedinstruktører og Hoppledere, ble sendt ut, og det ble lagt ut innlegg på F/NLF s Facebookgruppe. Til sammen fikk vi inn i underkant av 100 brukerhistorier fra ca 30 personer fra alle brukergruppene, som etter en ryddeprosess av overlappende historier resulterte i 49 brukerhistorier. Prioritering av brukerhistorier F/NLF ønsket at flest mulig av de potensielle brukerene og brukergruppene også skulle involveres i prioriteringen av brukerhistoriene. Vi løste dette ved å opprette et spørreskjema i Google Disk, og inviterte potensielle brukere av systemet til å prioritere hver enkelt brukerhistorie på en skala fra 1-5, der 1 betød Uviktig, og 5 Må implementeres. I skjemaet måtte også respondentene oppgi hvilken rolle de hovedsakelig vil ha med systemet. Besvarelsene resulterte i en gjennomsnittlig prioritering av de 49 brukerhistoriene på over 4, og ga derfor liten nytte. Sikkerhet- og Utdanningskomitteen samt Fagsjefen tok da en ny gjennomgang av brukerhistoriene, og ut fra denne listen ble kravspesifikasjonen utformet i samarbeid med oppdragsgiver. Kravspesifikasjon Med utgangspunkt i de 49 brukerhistoriene ble kravspesifikasjonen utarbeidet i samarbeid med oppdragsgiver. Vi valgte å beholde alle brukerhistoriene, og også sette disse inn i kravspesifikasjonen, selv om vi på forhånd var inneforstått med at dette ble for mye jobb for dette prosjektet. Begrunnelsen for dette, var et ønske fra oppdragsgiver om at prosjektet skal fortsettes også etter at bacheloroppgaven er ferdig, og dermed at så mye informasjon som mulig ble med i prosessen. Konseptskisse / Prototype Etter å ha gjennomgått de første brukerhistoriene og fått input på en del krav til avviksregistreringen, lagde vi en prototype/ konseptskisse med interaktivitet. Her fikk vi lært oss en del Twitter Bootstrap 3.0, som vi har tenkt til å bruke som front-end rammeverk. Bruken av dette er tidligere diskutert og vurdert som aktuelt, da det gir høy grad av responsiv GUI tilpasset ulike skjermer og mobile enheter. 79

80 Konseptskissen bestod av en typisk innloggingsside, og deretter fulgte man en avviksregistrering på reservetrekk. Skissen skulle demonstrere en skjemaløs tilnærming til avviksregistrering. Gangen i det hele skal i utgangspunktet være basert på de valgene man tar der og da. Om man velger reservetrekk, så skal det komme opp valg om type reserveskjerm, størrelse og hvor mange ganger denne er brukt også videre. I denne konseptskissen brukte vi jquery og Twitter Bootstrap til å legge fram nye svaralternativer og inputbokser. Det vil si, svaralternativene var alltid de samme, da dette var ment for å vise en idé på type skjema til ledelsen i NLF. Feedback på ulike type valg i registreringen var også noe vi ville ha svar på. Ved valg av hoppsted i Norge kan man ha veldig mange steder. For å få minst mulig fritekst, så ligger en del steder lagret i databasen (skal lagres) og når man begynner å skrive så dukker det opp alternativer som passer med det man begynner å skrive inn. Her har vi brukt Facebook Tokenfield, og dette ble godt mottatt. Dette egner seg å bruke istedenfor å få en dropdown-liste med f.eks. 200 forskjellige hoppfelt i Norge. Denne konseptskissen ble utarbeidet for å gi NLF noe å se på og samtidig vurdere konseptet. Konseptskissen er interaktiv og kan sees her: Vi tegnet også for hånd noen skisser hvor man kan registrere avvik og plassere disse i kronologisk rekkefølge på en vertikal tidslinje. Dette tenkte vi kunne gjøre det lettere å 80

81 identifisere årsaker til avvik og i en avviksrapport med flere avvik får man da sett hvilken avvikstype det hele startet med. F. eks. en feilfunksjon på utstyr medførte et reservetrekk som igjen førte til en kollisjon. F/NLF s reaksjon på konsept og prototype Fagsjefen og styret i F/NLF overværte presentasjon av konsept og fikk både se og prøve prototypen på brukergrensesnitt og brukeropplevelse. Tilbakemeldingene var positive, og de likte utseendet og gangen i registreringen. Vi måtte flere ganger minne på at det ikke lå noen funksjonalitet bak og at dataene var hardkodet inn i applikasjonen og at hovedintensjonen var å simulere en brukeropplevelse. Dette er en av ulempene med å starte med en HiFidelity prototype, altså at brukerne tror det er ekte. Men det gikk greit og det var det beste valget vi kunne gjøre for å demonstrere for kunden hvilket nivå dette lå på. Entusiasmen var stor og de gleder seg til den ordentlige utviklingen skulle begynne Arbeidsmengde Et mål for oss med oppgaven har vært at arbeidet skal være så likt en reell arbeidssituasjon som mulig for å forberede oss til arbeidslivet. Alle tre gruppemedlemmene jobber ved siden av studiene, to av oss har også barn, og ett av medlemmene har tatt et valgfag. For å sikre et høyt fokus på prosjektet og at vi jobbet samtidig så mye som mulig av tiden, ble vi enige om faste dager for jobbing med prosjektet. Vi har alle høye ambisjoner for prosjektet, og ønsket å legge flere timer i dette enn det skolen har lagt opp til. Timeplanen ble planlagt som følger: Mandag: Prosjekt 9-17 Tirsdag: Prosjekt 9-17 Onsdag: Jobb og valgfag 9-12, prosjekt Torsdag: Jobb og valgfag Fredag: Prosjekt

82 Dager med henting og levering i barnehage ble litt kortere, men denne tiden ble tatt igjen med jobbing på kveldstid. Totalt sett har vi endt opp med å jobbe mer enn de 29 timene pr uke som vi først planla, men det har vært helt i tråd med både ambisjoner og ønske fra den enkelte Arbeidssted Vi har benyttet tre forskjellige steder for jobbing med prosjektet; HiOA s lokaler på Holbergs plass, Accentures lokaler på Fornebu, og i NLF s lokaler i Møllergata. NLF s lokaler har blitt mest benyttet, da vi var så heldige å få et helt møterom for oss selv. I tillegg til å være et svært godt egnet lokale, satt vi her med oppdragsgiver i umiddelbar nærhet. Dette gjorde at vi kunne spørre med en gang det dukket opp avgjørelser som måtte tas, og oppdragsgiver kunne umiddelbart involveres i testing av ny funksjonalitet Prosjektside Etter krav fra skolen og av eget ønske ble det opprettet en webside for prosjektet, der rapporter ble publisert og informasjon mellom oss, oppdragsgiver og veiledere ble delt. Vi valgte å benytte Wordpress bloggrammeverk til dette, da vi følte at det var bedre å bruke tid på selve prosjektet enn å lage en enkel HTML/CSS nettside. Kort tid inn i prosjektperioden anså vi det å skulle oppdatere prosjektsiden mer som en belastning enn en fordel, og vi valgte å kutte den ut. Vi opprettet i stedet en facebookgruppe der all informasjon mellom de involverte aktørene ble delt, og prosjektsiden ble byttet ut med en enkel Twitter Bootstrap side der rapporter ble publisert Metodikk Smidig utvikling Å jobbe smidig og/eller bruke smidig metodikk er noe som blir mer og mer vanlig. Vi lever i en verden som er under konstant utvikling, og nye teknologier dukker opp så å si hver måned. I den globale sammenhengen er det altså viktig å ta høyde for at endringer i kravspesifikasjonen kan skje raskt. Det sies at det er umulig å fastsette alle kravene på forhånd i et prosjekt og kravene og behovene vil endre seg over relativt liten tid. Ingen av oss har hatt noen erfaring med smidig utvikling før, annet enn en teoretisk tilnærming. Vi fikk i midlertid tilbud om et lettbeint SCRUM kurs fra Accenture i forkant av prosjektet som vi benyttet oss av. Her lærte vi grunnleggende om SCRUM og gikk i gjennom noen enkle øvelser på estimering av tid og gjennomføring. Scrum Scrum er et enkelt og smidig rammeverk som har som mål å oppnå kreativitet, ekstraordinær produktivitet og godt samarbeid ved utvikling av både komplekse og mindre komplekse løsninger. Vi bestemte oss for å bruke Scrum som arbeidsmetodikk, og beslutningen ble også støttet av 82

83 våre veiledere i Accenture. En fremdriftsplan ble nedarbeidet som en foreløpig estimering. Sprintene ble satt til 3 uker om gangen. Scrum i praksis Scrum-metodikken har vært mer en veiledende plan og et sett med aspekter vi har fått nytte av i vår egen utvikling. Vi har stort sett sittet ute hos kunden (F/NLF) og jobbet, og vi har sittet sammen omtrent hele tiden. Fremdriftsplanen var til tider vanskelig å overholde, og vi fikk mye ønsker og spørsmål fra F/NLF underveis i den første perioden. For å prøve å overholde leveringstidspunktene ble vi veldig funksjonelt fokusert, og det ble jobbet hardt med å få funksjonene som F/NLF ønsket. Vi fikk også mer informasjon om systemets og forløpet av å registrere avvik underveis, som førte til refaktoriseringer og utbygginger av databasen. Etter hvert ble fremdriftsplanen sett på som løst veiledende. I tillegg til SCRUM har vi også benyttet noen aspekter fra den smidige utviklingsmetoden Extreme Programming (XP). Dette inkluderer parvis-programmering og gjennomgang av hverandres kode. Testdriven Development Denne metodikken går ut på at en skal skrive tester på det applikasjonen skal kunne gjøre og returnere før en faktisk begynner å kode funksjonalitet. Pga manglende erfaring med rammeverkene, ble det ikke helt slik i startfasen. Det ble viktigst å sette seg inn i de ulike teknologiene, og leke seg litt rundt med de for å forstå hvordan de fungerte. De første testene vi skrev gikk på databasetransaksjoner, og om hvorvidt disse ble utført riktig. Deretter ble det skrevet tekster for å laste inn applikasjonskonteksten riktig, og passe på at service ene ble lastet inn riktig. Vi benyttet oss ikke nok av denne metodikken i dette prosjektet, men om vi skulle ha gjort det om igjen hadde vi hatt nok grunnlag til å bedrive ordentlig testdriven development. De fleste testene ble skrevet rundt midten av prosjektsperioden. 83

84 5. Avslutning og resultat 5.1. Produktet REST-API et er ferdigstilt med de planlagte og nødvendige ressurser tilgjengelige. Synkronisering av F/NLF s medlemsdatabase mot vår egen MongoDb skjer 2 ganger i døgnet, og den vil alltid være oppdatert med medlemmers lisenser og aktive hoppere. Ressursene API et tilbyr er sikret der det trengs, og man må være autorisert for å gjøre endringer. REST-API et kjører på en Amazon server i dag, men skal flyttes til en egen host. Frontend ligger også på samme server og er brukergrensesnittet utad mot API et og tilbyr innlogging, registrering, manipulering og uthenting av avvik, medlemmer og klubber, etc. Vi har lagt til rette for at selve REST-API et starter opp på https med selvsignert SSL sertifikat, men vi anbefaler at de kjøper et offentlig godkjent sikkerhetssertifikat med en gang de deployer applikasjon på egen host. Ledelsen i F/NLF har allerede testet dette flere ganger, og vil så snart de får plassert applikasjonen på egen server kjøre i gang en testperiode med registrering av avvik for en eller flere klubber. Disse vil da fungere som forsøkspersoner for løsningen i et par måneders tid. F/NLF er meget fornøyd med løsningen, og synes løsningen kommer til å forenkle avviksregistrering enormt. Ifølge kravspesifikasjonen fik vi innfridd de største kravene og ønskene til F/NLF. Det er fortsatt en del mindre «nice to have»-funksjoner som kan implementeres. Dette blir opp til fremtidige utviklere å vurdere Oppfyllelse av krav til funksjonalitet F/NLF hadde fra starten av mange krav, men mye av beslutningene lå også hos oss. Både Tore og Morten i studentgruppen har hoppet fallskjerm i en årrekke og hadde mange konstruktive forslag og unik innsikt i fallskjermseksjonens behov. F/NLF s fagsjef ga oss derfor en del frie tøyler til utforming av applikasjonen. Allikevel er det en del krav til utfyllingen av avvikene som vi måtte diskutere ofte. Den smidige utviklingsmetodikken vår har tillatt oss å være nettopp smidige. Kravene og oversikten har blitt noe forandret underveis, og både vi og F/NLF har tilpasset oss. En av utfordringene har vært å kunne fastslå hvem som skal ha tilgang til hva. Dvs. de ulike rollene som hoppleder, hovedinstruktør og Fagsjef. Hvem skal ha skriverettigheter på de ulike, stedene, hvem skal bare kunne lese og hvem skal ikke ha tilgang i det hele tatt. Her har vi også drøftet personvern og hva slags informasjon man skal ha tilgang på. Man skal uansett ha tilgang på informasjon som er lagret om en selv. 84

85 5.3. Oppfyllelse av krav til videreutvikling At applikasjon lett skal kunne videreutvikles har vært et mål og et hensyn vi har hatt i hodet underveis i hele utviklingsprosessen. Det at applikasjonen vår er lagdelt og frikoblet fra frontend, gjør at man kan byttet ut lag etter ønske. REST-API et tilbyr ressurser, og det kan lett utvikles en iphone-, Android- eller Windowsapp basert på ressursene API et tilbyr. Brukergrensesnittet vårt som er utviklet med AngularJS, føler vi tilfredsstiller krav til å kunne benyttes på ulike bærbare og stasjonære enheter. Dette mest pga responsivt design, men også fordi AngularJS er et godt rammeverk som fungerer i de fleste nettlesere. Vi har testet det uten feil i Chrome, IExplore, Firefox, Opera og Safari. Lagdelingen gjør også at det er enkelt å bytte ut database om man ønsker, dataaksesslag, logikk eller domenemodellen. Dette gjør det veldig skalerbart og er veldig nyttig om Luftsportforbundet også vil integrere sine data inn i samme system. Altså få et sentralt system for hele Luftsportforbundet Veien videre Applikasjonen vil i sommer bli tatt i bruk av et utvalg av fallskjermklubber. Disse vil i en periode måtte rapportere dobbelt, både på den papirbaserte metoden og med vår applikasjon. F/NLF har engasjert to fallskjermhoppere til å videreutvikle applikasjonen, og F/NLF sitt mål er at systemet tas ibruk for alle klubber Studentgruppen har blitt kontaktet av Presidenten i Norges Luftsportforbund (NLF), Rolf Liland. Parallelt med videreutviklingen av vår applikasjon, vil de nå ta dette som utgangspunkt for å utvikle et felles avviksrapporteringssystem for alle seksjonene i NLF Refleksjon Gjennomføring Prosjektets gjennomføring har gått fint, til tross for at vi ikke har hatt noen erfaring med slike prosjektstørrelser før. En av de største utfordringene var å bli kjent alle rammeverkene og teknologiene. Vi hadde, som tidligere nevnt, ikke erfaring med noen av rammeverkene tidligere. Det tok tid å sette seg inn i Spring, SOAP, Maven og MongoDB. Selv om det var ganske bratt læringskurve i begynnelsen, gikk det bedre etter hvert. Det holdt å få grunnleggende info om rammeverkene, og deretter lærte vi mens vi gikk veien. Det ble åpenbart en del forandringer underveis, da vi også stadig fant ut bedre måter å gjøre ting på. Noe av det viktigste var ikke bare at det skulle fungere, men at utviklingen ble gjort på en riktig og ryddig måte. 85

86 Tidsplanen vi satte for oss sprakk vi på, selv om denne ikke var skrevet i stein. Det er ikke annet å forvente når man benytter smidig utvikling. Da må man regne med forandringer hele tiden. Vi taklet presset bra, og holdt på jevnt og kontinuerlig med å utvikle og utvide applikasjonen med å imøtekomme nye behov og funksjonalitet Samarbeid Samarbeidet på gruppa har foregått veldig bra. Alle har vist stort engasjement for oppgaven, og ingen har vært redde for å si ifra om det skulle være noe de lurte på, problemer, forslag eller ros og ris. Arbeidet har foregått stort sett ute hos kunden i Møllergata 39, på skolen og noe ute hos Accenture. F/NLF har bistått med utømmelig kilder med kaffe som har holdt gjengen gående. Samarbeidet med kunden og Accenture har også vært bra. Vi har kunnet spørre og grave om ting vi lurer på ute hos kunden, og de har vært veldig behjelpelige med svar og bistand. Accenture sine veiledere har også vært dyktige, og kommet med mye bra konstruktiv kritikk. I tillegg har vi fått kurs og opplæring i ulike teknologier, og fått delta på seminarer Læringsutbytte Før valg av rammeverk og teknologier kunne tas, måtte vi sette oss inn i hva de ulike rammeverkene og teknologiene tilbyr.for å gjøre dette mest mulig effektivt valgte vi å fordele de potensielle rammeverkene og teknologiene mellom oss, og så presentere for resten av gruppen. Denne metoden ga gode resultater, og vi fikk et godt, overfladisk overblikk over de ulike teknologiene. Prosjektet har gitt oss mye, og alle har lært masse. Vi kunne ingen av de rammeverkene vi valgte å ta i bruk fra før av, og det var mye å sette seg inn i. Læringskurven har vært bratt, og mye kunnskap har kommet underveis i utviklingen. Dette har tidvis ført til endringer i kode og oppbygging. Endringene har da vært vurdert til det bedre Konklusjon Vi er godt fornøyd med applikasjonen vi har laget. Prosjektet har hatt stort omfang, og vi har utviklet utrolig mye forskjellig. Det er mange komponenter, teknologier og rammeverk som spiller sammen og læringsutbytte har vært enormt. Prosjektet har vært krevende, men vi har fått mye igjen. Å kunne bidra med å utvikle en applikasjon som skal brukes til noe viktig og nyttig gir oss en god følelse. F/NLF vil ta i bruk applikasjonen på en prøveperiode med en eller flere klubber, og dette gir oss stor glede. 86

87 6. Vedlegg Vedlegg 1 - Norges Luftsportforbund Historie Norges Luftsportforbund (NLF) er et fleridrettsforbund, tilsluttet Norges idrettsforbund (NIF) og olympiske og paralympiske komité of Fédératxion Aéronautique Internationale (FAI). Forbundet består av følgende idretter som hver har sin seksjon i NLF; fallskjermhopping, hang- og paragliding, seilflyging, motorflyging, mikroflyging, modellflyging og flyging med varmluftballong. NLF har sine røtter tilbake til 1909 da Norsk Luftseiladsforening ble stiftet. I 1928 ble Norsk Aero Klubb (NAK) stiftet og i 1930 ble de to organisasjonene slått sammen. NFL ble stiftet i 1971 som en paraplyorganisasjon for fallskjermhopping og seilflyging, som på det tidspunktet var godkjent som idretter og tatt opp i NIF. Hanggliding ble tatt opp i forbundet i 1980 og senere også paragliding. Ved luftsportstinget i 2000 ble det vedtatt at de fire luftsportsgrenen ballongflyging, modellflyging, mikroflyging og motorflyging ble innlemmet i NFL. På NLFs ting NAKs representasjonsmøte i 2003 ble det besluttet å slå sammen de to forbundene under navnet Norges Luftsportforbund / Norsk Aero klubb. Luftsportstinget i 2007 besluttet at navnet på forbundet skal være Norges Luftsportforbund (NLF). Organisert fallskjermhopping sivilt startet i Norge i begynnelsen av 1960-tallet. Organisasjon NLF er et idrettsforbund underlagt Norges Idrettsforbund (NIF). NLF er dermed underlagt de lover og regler som er bestemt av NIF. NLF har et forbundstyret som er til valg hver andre år. NLFs ulike seksjoner har igjen hver sitt styre som også er på valg hvert andre år. Fallskjermseksjonen i Norges Luftsportforbund (F/NLF) består igjen av 19 fallskjermklubber som er spredt ut over landet. Sekretariat. F/NLF har en ansatt person som har stillingen som fagsjef i seksjonen. Komiteer: Styret i F/NLF utnevner forskjellige komiteer som styrer arbeidet for sine ansvarsområder. 87

88 Styret NLF: Velges på Luftsportstinget hvert 2. år Styret F/NLF Velges på Seksjonsmøtet hvert 2. år Administrasjon Fagsjef og Avdelingsleder, ansatt av NLF, egen stillingsbeskrivelse. SU Sikkerhets- og Utdanningskommitéen, utpekes av styret i F/NLF KK Konkurransekommitéen, utpekes av styret if/nlf DK Dommerkommité, utpekes av Styret if/nlf RK Rikssenterkommité, utpekes av styret i F/NLF VK Valgkommite velges av Fallskjermklubbene 88

89 Operativ organisering SU MK MR HI HL HFL HM Flyger Består av Leder, materiellsjef og medlemmer, Utpekes av F/NLF Materiellkontrollør, utdannes og lisensieres av F/NLF Materiellkontrollør, utdannes og lisensieres av F/NLF Hovedinstruktør, overordnet ansvar for all fallskjermoperativ aktivitet i klubb, utpekes av F/NLF (SU) Hoppleder, stedlig ansvarlig ved hopping, utpekes av HI Hoppfeltleder, ansvarlig på bakken ved hopping, utpekes av HL Hoppmester, leder av det hopptekniske om bord i flyet, utpekes av HFL Ansvarlig for luftfartøyets sikkerhet, får retningslinjer fra HM,, og gir klarsignal når utsprang kan starte Sikkerhets- og utdanningskommitéen (SU): Sikkerhets- og utdanningskommitéen (SU) har overordnet kontroll med all utdanning og praktisk hoppvirksomhet innen F/NLF. SU består av leder i tillegg til 3 andre medlemmer. Det ene medlemmet har vervet som Materiellsjef. Materiellsjefen oppnevnes av Styret F/NLF og utøver i samarbeid med SU overordnet kontroll med all materielltjeneste innen F/NLF. All fallskjermaktivitet i Norge er regulert av Lov om luftfart som forvaltes av Samferdselsdepartementet gjennom Luftfartstilsynet (LT). LT har i samarbeid med NLF utarbeidet Bestemmelser for sivil luftfart (BSL) som regulerer fallskjermhopping. Med hjemmel i Bestemmelser for Sivil Luftfart (BSL), utsteder, iverksetter og håndhever SU, gjennom F/NLFs Håndbok Del , , bestemmelser for F/NLFs praktiske hoppvirksomhet og utdanning. SU godkjenner klubbers oppnevnelse av Hovedinstruktør, og utsteder/inndrar fallskjermklubbers og andre organisasjonsenheters Operasjonstillatelser. SU ivaretar NLFs kontakt med luftfartsmyndighetene i fallskjermrelaterte saker. Ved alvorlige ulykker oppnevnes undersøkelseskommisjon av Styret F/NLF. Materiellkontrollør (MK): Materiellkontrollør utfører hovedkontroll på fallskjermer og gjennomfører eksamensprøver for fallskjermpakkere i samsvar med gjeldene bestemmelser. Materiellreperatør (MR): Materiellreparatør kan utføre alle former for materiellreparasjoner på de fallskjermtyper han er sertifisert og autorisert for. 89

90 Hovedinstruktør (HI): Hovedinstruktør er den instruktør som er oppnevnt av styret i klubb eller annen organisasjonsenhet til å lede all utdanning og praktisk hoppvirksomhet. Oppnevnelsen skal godkjennes av SU. Hovedinstruktøren er faglig ansvarlig for sikkerhet og materiell. Han/hun er faglig bindeledd mellom lokalklubb og SU. Han/hun er ansvarlig for at rutinemessige rapporter som vedrører den operative drift blir utarbeidet og innsendt i rett tid, samt at hendelsesrapporter blir utarbeidet, kommentert og rapportert til SU v/ F/NLFs sekretariat uten unødig opphold. Hoppleder (HL): HL er den person som er overlatt ansvaret for gjennomføring av praktisk hoppvirksomhet på et sted i et bestemt tidsrom. HL skal være utpekt før hopping startes av lokal HI. Hoppfeltleder (HFL): HFL utpekes av HL, er underlagt denne, og har til oppgave å administrere, organisere og overvåke hoppfeltet, og påse at hoppingen gjennomføres etter gjeldende bestemmelser. Hoppmester (HM): HM er den person som har ansvaret for, og kommandoen over hoppere under innlasting i flyet og ved utsprang. Flyver: Fartøysjef på ikke kommersielt luftfartøy som anvendes for fallskjermutsprang er en del av den operative hopporganisasjonen Hendelser og rapportering Ved avvik fra reglementet skal hoppleder sende inn en avviksrapport Situasjoner som skal rapporteres er: NÆRUHELL: Utilsiktet skjermåpning, utløsning av reserveskjerm, feilfunksjoner, utilsiktet vannlanding eller andre forhold som nær hadde forårsaket uhell/ulykke. Som næruhell regnes også brudd på F/NLFs bestemmelser. UHELL: Hendelse hvor hopper er påført skade som medfører behandling av lege og/eller av sykehus og/eller påfølgende sykefravær i kortere eller lengre tid. Skaden må ha inntruffet mellom avgang med fly og fullført landing. Som uhell regnes også større skader på materiell. ULYKKE: Hendelse som har medført død for en eller flere personer mellom avgang med fly og landing i fallskjerm. Som ulykke regnes også store skader der situasjonen er uavklart eller at skaden er så alvorlig at det er risiko for varige mén. 90

91 Hendelserapportering Sikkerhet og utdanningskomiteen ser på hendelsesrapportering som en kritisk faktor for arbeidet med sikkerheten for fallskjermhoppingen generelt. Gjennom hendelsesrapportering kan man finne årsaker og komme med korrigerende tiltak. Man kan fange opp mønster og trender og sette i gang preventive tiltak. Rapporteringen sees på som avgjørende for at F/NLF skal bli en lærende organisasjon og en nøkkelkomponent i F/NLF sitt sikkerhetssystem. F/NLF er pålagt å ha et sikkerhetssystem som inneholder system for hendelsesrapportering. Pålegget har hjemmel i forskrift om sivil fallskjermhopping, BSL D4-2. Dagens løsning:. Ved eventuelle hendelser er det hoppleders oppgave å skrive en hendelsesrapport. I dag skrives disse rapportene ved å fylle ut et skjema på papir. Hoppleder overleverer så dette skjemaet til fallskjermklubbens hovedinstruktør som skal legge ved sine kommentarer og sende rapporten inn til F/NLF sentralt. Denne rapporteringen skjer elektronisk via et web skjema. Bildet over viser flyten for prosessen ved innrapportering av en hendelse i dag. 48 timer etter at en hendelse har oppstått skal Fagsjef ha mottatt en hendelsesrapport påført vurderinger og kommentarer fra lokal HI. Før dette, skal HL ha skrevet rapport og overlevert denne til HI. HI rapporterer inn til FNLF via elektronisk skjema på NLF sine nettsider. Den største utfordringen med prosessen er tid. Enten at det tar lang tid før hendelsesrapporter kommer inn, eller så kommer de ikke inn i hele tatt. Dette problemet oppstår i steget Rapport sendes HI. De manuelle papirrapportene har en tendens til å bli liggende i HI hylla, evt i HI sin innboks (epost) for de klubbene som har implementert en lokal elektronisk variant av papirrapporten, de fleste da via et skjema laget i Google docs. Siden det samme skjemaet må skrives to ganger, så øker både risikoen for feil og det er mer arbeid. Sistnevnte vil kunne være en ytterligere forsinkende faktor. Hendelsesrapporteingsprosessen henger sterkt sammen med to andre F/NLF prosesser: SU sin prosess for å gjennomgå innkomne hendelser og rapportering til Fagseminaret. Forarbeidet til disse prosessene er tunge og manuelle som følge av at kvaliteten på informasjonen er varierende. 91

92 Aktører i rapporteringsprosessene Rolle SU Materiellsjefen Fagsjef Statistikkansvarlig Hovedinstruktør Hoppleder Hopper(e) Beskrivelse Vurderer den operative sikkerheten løpende. Får sammenstilte rapporter jevnlig fra Fagsjef og årsrapport fra Statistikkansvarlig. Basert på funn, trender og diskusjoner vurderer SU tiltak der det anses som nødvendig. Er en del av SU og håndterer materiellrapportene. Vurderer løpende materiellsikkerhet og tiltak. Fagsjef tar jevnlig ut hendelsesrapporter og sender disse til medlemmene av SU. Fagsjefen blir også varslet direkte ved alvorlig hendelser og ulykker. Lager spørringer og statistikk basert på innholdet i hendelsesdatabasen. Skal sende inn hendelsesrapport med vurderinger og kommentarer til FNLF innen 48 timer. Dette gjøres via skjema på nlf.no. Skal skrive hendelsesrapport på rapporteringspliktig hendelse og sende denne til Hovedinstruktør. Den/de person(er) som er involvert i en rapporteringspliktig hendelse. Skjemaet som benyttes av HI ved elektronisk innrapportering av hendelser er basert på papirskjemaet som benyttes av HL. Skjemaet har en del faste punkter som alltid skal fylles ut, uansett hvilke type hendelse. Felles for disse punktene er: Basert på fritekst. Noe validering av tekstfeltene på klient, ingen validering på server. Ved feilfunksjon så er rapporten basert på avkrysningsvalg. Flere av valgene er utdaterte. En del feilfunksjoner som er vanlige mangler. Det er ingen logikk i strukturen. Ved personskade er rapporten basert på både fritekst og avkrysningsvalg. Her er det også flere vanlige skadeårsaker som mangler. På alle rapporter skal HL og HI skrive på sine kommentarer for hendelsen. Feltene er basert på fritekst. 92

93 Det er ingen veiledning for kommentarene. Det SU gjerne vil se i disse kommentarene er 3 punkter: Hva som har skjedd HL og HIs formening om hvorfor det har skjedd. Hvilke tiltak HL og HI har iverksatt i etterkant for å sørge for at samme type hendelse kan unngås i fremtiden. 93

94 94

95 Vedlegg 2 - Kravspesifikasjon Avviksrapportering Fallskjermseksjonen/Norges Luftsportforbund (F/NLF). Innledning I dette prosjektet blir Scrum brukt som utviklingsmetodikk. Som med alle smidige utviklingsmetoder stiller også Scrum mindre krav til rigide kravspesifikasjoner før prosjektstart. Metodikken åpner opp for at produkteier skal kunne komme med ønsker om forandringer underveis, og kravspesifikasjonen betegnes derfor som veiledende. Kravene er merket med skal og bør, som betyr henholdsvis must have og nice to have. Kravene som er merket med skal er de kravene vi jobber mest med for å få gjennømført. Krav merket med bør kommer i andre rekke, og startes bare på om vi har tid og fått gjennomført kravene som skal gjennomføres. Prioriteringen kan endres underveis etter resultater fra brukertesting. F/NLF er også inneforstått med at vi ikke kommer til å klare å innfri alle deres ønsker og krav, og at det dermed kan være aktuelt for videreutvikling av applikasjonen ved senere anledning. Det er derfor ønskelig og viktig med god dokumentasjon på systemet og rikelig med kommentarer i kildekoden. Det viktigste er god backend kode og funksjonalitet på å lagre avvik. Brukere Administrator - Fagsjef Skal ha alle rettigheter Sikkerhet- og utdanningskomitteen (SU) Skal kunne lese alle innkommende rapporter Skal motta varsler ved anbefaling om permanent hoppforbud Hovedinstruktør (HI) Skal kunne registrere avviksrapporter og se oversikt over tidligere rapporter Skal kunne administrere HL er Skal kunne redigere rapporter innsendt av HL Hoppleder (HL) Skal kunne registrere avviksrapporter og se oversikt over tidligere rapporter Medlem Fallskjermseksjonen/Norges Luftsportsforbund (F/NLF) - Hopper Skal kunne lese anonymiserte rapporter Innlogging Systemet skal tilby funksjonalitet tilpasset av den brukergruppen personen er medlem av Systemet bør benytte NLF-medlemsnummer som brukernavn Systemet bør kunne tilby selvvalgt passord for senere innlogging Systemet kan tilby innlogging med eksisterende Facebook/Gmail-konto 95

96 Registrering av involverte personer Systemet skal hente medlemsdata fra MelWin. MelWin er medlemregisteret til Norges Luftsportsforbund. MelWin har et web-api som bruker SOAP som grensesnitt. Systemet skal kun hente informasjon fra Melwin, ikke skrive, slette eller oppdatere. Systemet skal tilby å legge til personer som ikke er registrert i MelWin inn i avviksregisteret for å fange opp f.eks. utenlandske hoppere. Systemet skal tillate å registrere flere personer i en hendelse. Registrering av avvik - HL Systemet skal tillate at rapporter kan påbegynnes og lagres, og fullføres senere. Systemet skal tillate at kun vesentlig informasjon må skrives inn, mens utfyllende informasjon kan legges til om relevant Systemet bør kunne vise en hoppers tidligere avvik Systemet bør kunne tillate opplasting av vedlegg, som bilder og video HL bør kunne gi tilgang til andre personer for å kunne gi utfyllende rapporter Systemet må kunne validere viktige felter Registrering av avvik -HI Systemet skal kunne tilby funksjonalitet for å returnere en mangelfull rapport fra HL, med kommentar om hva som mangler Systemet skal kunne varsle HI ved nye hendelser i egen klubb Systemet skal kunne kunne tilby funksjonalitet for å vise nøkkelinformasjon over hendelser i egen klubb Systemet skal kunne tilby funksjonalitet for å vise alle registrerte hendelser på en person Systemet skal kunne tilby funksjonalitet for å vise vise utvalg av hendelser, basert på lisens, erfaring osv Systemet skal kunne tilby funksjonalitet for å registrere om hendelsen kan kreve behov for ytterligere undersøkelser eller gransking Systemet skal kunne tilby funksjonalitet for å legge til eller slette personer registrert i en hendelse Systemet skal tilby funksjonalitet for å anbefale permanent hoppforbud. Systemet bør kunne varsle HI i god tid før 48 timer er gått, slik at HI kan purre på HL Systemet bør kunne tilby funksjonalitet for å avslå og slette irrelevante rapporter fra HL Administrasjon av systemet Systemet skal være brukervennlig og enkelt å vedlikeholde Systemet skal varsle dersom alvorlige hendelser er registrert Systemet skal kunne tilby funksjonalitet for administrasjon av brukere og brukergrupper Systemet skal kunne tilby funksjonalitet for å ta ut utvalg av rapporter Systemet bør kunne tilby funksjonalitet for registrering av kvartalsrapportering 96

97 Systemet skal kunne tilby funksjonalitet for redigering av labels, slik som lokasjoner, avvikstyper osv. Nye labels skrevet inn av av HL/HI skal kunne aksepteres som ny label, eller avslås og knyttes mot eksisterende labels Systemet skal kunne tilby funksjonalitet for å legge til avvik som ikke tidligere er registrert Systemet bør tilby varsling ved innkommende rapporter Systemet bør utheve hendelser som ikke tidligere er lest Videreutvikling av systemet Systemet skal bygges og dokumenteres på en slik måte at det lar seg videreutvikle av andre utviklere All dokumentasjon i forbindelse med utviklingen skal tilgjengeliggjøres ovenfor F/NLF ved prosjektets slutt Ikke-funksjonelle krav Systemet skal utvikles i open-source programvare Systemet skal kunne kjøres på F/NLF s Linux-server Det skal benyttes engelsk som språk i all kode Systemet skal gjøres tilgjengelig via en webapplikasjon Systemet bygges med RESTful-API, slik at komponenter lettere kan byttes ut Frontend webapplikasjon Systemet skal gjøres tilgjengelig via en webapplikasjon. Applikasjonen blir å anse som en, så langt det lar seg gjøre, fungerende prototype som F/NLF kan videreutvikle, eller høste erfaring fra Applikasjonen utvikles med tanke på demonstrasjon av funksjonalitet, mens utseende, validering osv ikke er viktig i denne delen 97

98 Vedlegg 3 - Oversikt over ressurser Web API. Ressurs/URL Metoder Autorisasjon Mediatype /anomalies get, post, put alle token. application/json /anomalies/{id} get, delete alle token application/json JSON-objekt { "id": int, "datetime": int, "anomalytype": { "id": int, "name: string, "description": string, "active": boolean }, "anomalystatus": { "id": 1, "name": string }, "involvedpersons":[ { "id": int, "licenses": [ { "id": int, "melwinid": string, "licensename": string, "active": boolean } ], "firstname": string, "lastname": string, "birthdate": int, "gender": string, "street": string, "postnumber": string, "postplace": string, "mail": string, "phone": string, "melwinid": string, "nakkey": string, "memberclubs": [ { "id": int, "melwinid": string, "name": string, "chiefinstructormelwinid": string, "active": boolean } ], "numberofjumps": string, "yearsofexperience": string, "jumptype": { "id": int, "name": string, "description": string, "active": boolean }, 98

99 "gear": { "maincanopy": { "id": int, "manufacturer": { "id": int, "name": string, "url": string, "phone": string, "fax": string, "mail": string, "active": boolean } "name": string, "productiondate": intl, "serialnumber": int, "nlfapproved": int, "size": int, "active": boolean }, "reservecanopy": { "id": int, "manufacturer": { "id": int, "name": string, "url": string, "phone": string, "fax": string, "mail": String, "active": boolean }, "name": string, "productiondate": int, "serialnumber": int, "nlfapproved": boolean, "size": int, "active": boolean }, "automaticactivationdevice": { "id": int, "manufacturer": { "id": int, "name": string, "url": string, "phone": string, "fax": string, "mail": string, "active": boolean }, "name": string, "productiondate": int, "lastinspectiondate": int, "serialnumber": string, "nlfapproved": boolean, "lastbatterydatechangedate": int, "active": boolean }, "harnesscontainer": { "id": int, "manufacturer": { "id": int, "name": string, "url": string, "phone": string, "fax": string, 99

100 "mail": string, "active": boolean }, "name": string, "productiondate": int, "serialnumber": string, "nlfapproved": boolean, "size": int, "active": boolean } } }], "incidents": [ { "involvedpersonsid": [ int ], "incidenttype": { "id": int, "name": string, "group": string, "description": string, "active": boolean, }, "commentfromhl": string, "commentfromhi": string, "timelineindex": int, } ], "location": { "id": int, "name": string, "latitude": int, "longitude": int, }, "club": { "id": int, "melwinid": string, "name": string, "chiefinstructormelwinid": string, "active": boolean }, "attachments": [{ "attachmentname":string, "size":int, "path":string, }], "jumpleader":{ "id": int, "licenses": [ { "id": int, "melwinid": string, "licensename": string, "active": boolean } ], "firstname": string, "lastname": string, "birthdate": int, "gender": string, "street": string, "postnumber": string, "postplace": string, "mail": string, 100

101 "phone": string, "melwinid": string, "nakkey": string, "memberclubs": [ { "id": int, "melwinid": string, "name": string, "chiefinstructormelwinid": string, "active": boolean } ] }, "jumpleadercomment": string, "hicomment": string } Ressurs/URL Metoder Autorisasjon Mediatype /anomalystatuses get, post, put get åpen, post og put token application/json /anomalystatuses/{id} get, delete get åpen, delete token application/json JSON-objekt { } "id": 1, "name": string Ressurs/URL Metoder Autorisasjon Mediatype /anomalytypes get, post, put get åpen, post og put token application/json /anomalytypes/{id} get, delete get åpen, delete token application/json JSON-objekt { } "id": int, "name: string, "description": string, "active": boolean Ressurs/URL Metoder Autorisasjon Mediatype /aads get, post, put get åpen, post og put token application/json 101

102 /aads/{id} get, delete get åpen, delete token application/json /isactiveaads/ get åpen application/json JSON-objekt { } "id": int, "manufacturer": { "id": int, "name": string, "url": string, "phone": string, "fax": string, "mail": string, "active": boolean }, "name": string, "productiondate": int, "lastinspectiondate": int, "serialnumber": string, "nlfapproved": boolean, "lastbatterydatechangedate": int, "active": boolean Ressurs/URL Metoder Autorisasjon Mediatype /clubs get, post, put get åpen, post og put token application/json /clubs/{id} get, delete get åpen, delete token application/json /isactiveclubs get åpen application/json JSON-objekt { } "id": int, "melwinid": string, "name": string, "chiefinstructormelwinid": string, "active": boolean Ressurs/URL Metoder Autorisasjon Mediatype /harnesscontainers get, post, put get åpen, post og put token application/json /harnesscontainers/{id} get, delete get åpen, delete token application/json /isactivharnesscontainers get åpen application/json JSON-objekt 102

103 { } "id": int, "manufacturer": { "id": int, "name": string, "url": string, "phone": string, "fax": string, "mail": string, "active": boolean }, "name": string, "productiondate": int, "serialnumber": string, "nlfapproved": boolean, "size": int, "active": boolean Ressurs/URL Metoder Autorisasjon Mediatype /incidenttypes get, post, put get åpen, post og put token application/json /incidenttypes/{id} get, delete get åpen, delete token application/json /isactiveincidenttypes get åpen application/json JSON-objekt { } "id": int, "name": string, "group": string, "description": string, "active": boolean Ressurs/URL Metoder Autorisasjon Mediatype /jumptypes get, post, put get åpen, post og put token application/json /jumptypes/{id} get, delete get åpen, delete token application/json /isactivejumptypes get åpen application/json JSON-objekt { } "id": int, "name": string, "description": string, "active": boolean 103

104 Ressurs/URL Metoder Autorisasjon Mediatype /licenses get, post, put get åpen, post og put token application/json /licenses/{id} get, delete get åpen, delete token application/json /isactivelicenses get åpen application/json JSON-objekt { } "id": int, "melwinid": string, "licensename": string, "active": boolean Ressurs/URL Metoder Autorisasjon Mediatype /locations get, post, put get åpen, post og put token application/json /locations/{id} get, delete get åpen, delete token application/json JSON-objekt { } "id": int, "name": string, "latitude": float, "longitude": float Ressurs/URL Metoder Autorisasjon Mediatype /maincanopies get, post, put get åpen, post og put token application/json /maincanopies/{id} get, delete get åpen, delete token application/json /isactivemaincanopies get åpen application/json JSON-objekt { "id": int, "manufacturer": { "id": int, "name": string, "url": string, "phone": string, "fax": string, "mail": string, "active": boolean } "name": string, 104

105 } "productiondate": intl, "serialnumber": int, "nlfapproved": int, "size": int, "active": boolean Ressurs/URL Metoder Autorisasjon Mediatype /manufacturers get, post, put get åpen, post og put token application/json /manufacturers/{id} get, delete get åpen, delete token application/json /isactivemanufacturers get åpen application/json JSON-objekt { } "id": int, "name": string, "url": string, "phone": string, "fax": string, "mail": string, "active": boolean Ressurs/URL Metoder Autorisasjon Mediatype /persons get, post, put token application/json /persons/{id} get, delete token application/json /parachutistswithlicense get token application/json /nlfparachutist/{melwinid} get token application/json JSON-objekt { "id": int, "licenses": [ { "id": int, "melwinid": string, "licensename": string, "active": boolean } ], "firstname": string, "lastname": string, "birthdate": int, "gender": string, "street": string, 105

106 } "postnumber": string, "postplace": string, "mail": string, "phone": string, "melwinid": string, "nakkey": string, "memberclubs": [ { "id": int, "melwinid": string, "name": string, "chiefinstructormelwinid": string, "active": boolean } ] Ressurs/URL Metoder Autorisasjon Mediatype /quartalreports get, post, put get åpen, post og put token application/json /quartalreports/{id} get, delete get åpen, delete token application/json JSON-objekt { } "id": id, "sendtin": int, "club": { "id": int, "melwinid": string, "name": string, "chiefinstructormelwinid": string, "active": boolean }, "year": int, "quartal": int, "passeduljumps": int, "faileduljumps": int, "passedulmjumps": int, "failedulmjumps": int, "passedultjumps": int, "failedultjumps": int, "passedstudentfreefall": int, "failedstudentfreefall": int, "passedstudentafffreefall": int, "failedstudentafffreefall": int, "trainingjumps": int, "demojumps": int, "competitionjumps": int, "tandemjumps": int Ressurs/URL Metoder Autorisasjon Mediatype 106

107 /reservecanopies get, post, put get åpen, post og put token application/json /reservecanopies/{id} get, delete get åpen, delete token application/json /isactivereservecanopies get åpen application/json JSON-objekt { } "id": int, "manufacturer": { "id": int, "name": string, "url": string, "phone": string, "fax": string, "mail": String, "active": boolean }, "name": string, "productiondate": int, "serialnumber": int, "nlfapproved": boolean, "size": int, "active": boolean 107

108 Vedlegg 4 - Klasseoversikt Domenemodellen - No.nlf.models.classes Klasse Beskrivelse AutomaticActivationDevice Anomaly AnomalyStatus AnomalyType Club Gear GearComponent HarnessContainer Incident IncidentParachutist IncidentType JumpType License Location MainCanopy Manufacturer Parachutist QuartalReport ReserveCanopy User Modellklasse for Aad Modellklasse for et avvik Modellklasse for statusen på avviksrapporten Modellklasse for hva slags type avvik det er Modellklasse for klubb Modellklasse for utstyr (arver MainCanopy, ReserveCanopy, Aad og HarnessContainer) Modellklasse for utstyrskomponent Modellklasse for Modellklasse for hendelse (kan være flere hendelser I et avvik) Modellklasse for en Parachutist some r involvert I en hendelse. Den arver parachutist og har en del tilleggsinformasjon om utstyr. Modellklasse for type hendelse Modellklasse for hopptyper Modellklasse for lisenser Modellklasse for hopplokasjoner med navn og lenge- og breddegrader Modellklasse for hovedskjerm Modellklasse for produsent av utstyr Modellklasse for en hopper Modellklasse for kvartalsrapport Modellklasse for reserveskjerm Modellklasse for broker (innloggingsinfo) Datalayer - No.nlf.dal Klasse Beskrivelse AutomaticActivationDeviceController AdminController AnomalyController AnomalyStatusController AnomalyTypeController ClubController HarnessContainerController IncidentTypeController JumpTypeController LicenseController Kontrollerklasse for *Aad Kontrollerklasse for å sjekke admin roller til en eventuell hopper. Kontrollerklasse og CRUD metoder for avvik Kontrollerklasse for avviksstatus Kontrollerklasse for avvikstyper Kontrollerklasse for hoppklubber Kontrollerklasse for Seletøy og container (som skjermen ligger pakket i) Kontrollerklasse for hendelsestype Kontrollerklasse for type hopp som er gjort Kontrollerklasse for lisenser 108

109 LocationsController MainCanopyController ManufacturerController ParachutistController QuartalReportController ReserveCanopyController SecurityService Kontrollerklasse for hopplokasjoner Kontrollerklasse for hovedskjerm (utstyr) Kontrollerklasse for produsent av utstyr Kontrollerklasse for fallskjermhopper Kontrollerklasse for kvartalsrapport Kontrollerklasse for reserveskjerm (utstyr) Service-klasse knyttet til sikkerhet. Finner rollene til bestemt hopper basert på sertifikater. No.nlf.dal.config Klasse AppContext MongoCounter SpringMongoConfig1 Beskrivelse Klasse som knytter SpringMongoConfig en til en MongoOperationsbønne En teller som oppdaterer id I en egen collection Service- /bønne-klasse for MongoDb (tilkobling, port) No.nlf.dal.security Klasse Beskrivelse DataBaseInitializer SaltedSHA256PassowrdEncrypter UserController UserDao Initialiserer en database med bruker for testing av systemet Krypterer passordet til bruker med SHA256 kryptering Kontrollerklasse for bruker som implementerer interfacet «UserDao». Interface som arver interfacet UserDetailService fra SpringSecurity. No.nlf.models.mongoclasses Klasse Counters MongoAdmin MongoAnomaly MongoAnomalyType MongoAttachment MongoAutomaticActivationDevice MongoClub MongoForeignParachutist MongoGear MongoGearComponent MongoHarnessContainer MongoIncident Beskrivelse Tellerklasse tilknyttet MongoDB som holder rede på ID ene til de forskjellige objektene lagret i databasen. Admin kolleksjon for MongoDb Anomaly kolleksjon for MongoDb Avvikstype for MongoDb Attachment kolleksjon for MongoDb AutomaticActivationDevice kolleksjon for MongoDb Klubb kolleksjon for «mapping» mot MongoDb Utenlandsk hopper kolleksjon mot MongoDb Utstyr kolleksjon mot mongodb Utstyrskomponent kolleksjon mot mongodb Seletøy kolleksjon mot mongodb Hendelseskolleksjon mot MongoDb 109

110 MongoIncidentParachutist MongoIncidentType MongoJumpType MongoLicense MongoLocation MongoMainCanopy MongoManufacturer MongoParachutist MongoQuartalReport MongoReserveCanopy MongoUser Fallskjermhopper tilknyttet hendelse mot MongoDb Hendelsestype mot MongoDb Hopptype som lagres i MongoDb Lisenser som lagres i MongoDb Lokasjoner mot MongoDb Hovedskjerm mot MongoDb Produsent som mappes mot MongoDb Fallskjermhopper som lagres imongodb Kvartalsrapport MongoDb Reserveskjerm som mappes mot MongoDb Brukerinformasjon, brukernavn og passord som lagres i MongoDb LogicLayer - No.nlf.logic Klasse AnomalyLogic AnomalyStatusLogic AnomalyTypeLogic AutomaticActivationDeviceLogic ClubLogic HarnessContainerLogic IncidentTypeLogic JumpTypeLogic LicenseLogic LocationLogic MainCanopyLogic ManufacturerLogic ParachutistLogic QuartalReportLogic ReserveCanopyLogic Beskrivelse Logikk-klasse for avvik Logikk-klasse for avviksstatus Logikk-klasse for avvikstype Logikk-klasse for utstyr (aad) Logikk-klasse for klubb Logikk-klasse for utstyr(seletøy) Logikk-klasse for hendelser Logikk-klasse for hopptyper Logikk-klasse for lisenser Logikk-klasse for lokasjoner Logikk-klasse for hovedskjerm Logikk-klasse for produsent av utstyr Logikk-klasse for fallskjermhoppere Logikk-klasse for kvartalsrapporter Logikk-klasse for reserveskjermer RestLayer No.nlf.model.restClasses Klasse Beskrivelse Link Klasse for linker RestAnomaly Speilbilde av domeneklassen med linker (REST nivå 3) RestAnomalyStatus Speilbilde av domeneklassen med linker (REST nivå 3) RestAnomalyType Speilbilde av domeneklassen med linker (REST nivå 3) RestAttachment Speilbilde av domeneklassen med linker (REST nivå 3) RestAutomaticActivationDevice Speilbilde av domeneklassen med linker (REST nivå 3) RestClub Speilbilde av domeneklassen med linker (REST nivå 3) 110

111 RestGear Speilbilde av domeneklassen med linker (REST nivå 3) RestHarnessContainer Speilbilde av domeneklassen med linker (REST nivå 3) RestIncidentType Speilbilde av domeneklassen med linker (REST nivå 3) RestJumpType Speilbilde av domeneklassen med linker (REST nivå 3) RestLicense Speilbilde av domeneklassen med linker (REST nivå 3) RestLocation Speilbilde av domeneklassen med linker (REST nivå 3) RestMainCanopy Speilbilde av domeneklassen med linker (REST nivå 3) RestManufacturer Speilbilde av domeneklassen med linker (REST nivå 3) RestParachutist Speilbilde av domeneklassen med linker (REST nivå 3) RestQuartalReport Speilbilde av domeneklassen med linker (REST nivå 3) RestReserveCanopy Speilbilde av domeneklassen med linker (REST nivå 3) RestRoot Klasse med bare linker (Oppslagsverk) No.nlf.rest Klasse Application HostAddressHolder RestAnomalyController RestAnomalyStatusController RestAnomalyTypeController RestAutomaticActivationDeviceController RestClubController RestHarnessContainerController RestIncidentTypeController RestJumpTypesController Beskrivelse Main metoden for hele applikasjonen. Her startes Spring-Boot med en embedded TomCat-server på port Klassen skanner hele prosjektet for komponenter, bønner og ressurser, og starter hele rest-tjenesten. RestController for avviksressurser. Ressursene er de samme som innholdet i Anomaly.class i domenemodellen. RestController for avviksstatusressurser. Ressursene er de samme som innholdet i AnomalyStatus.class i domenemodellen. RestController for avvikstyperessurser. Ressursene er de samme som innholdet i AnomalyType.class i domenemodellen. RestController for utstyrsressurser (aad). Ressursene er de samme som innholdet i AutomaticActiviationDevice.class i domenemodellen. RestController for klubbressurser. Ressursene er de samme som innholdet i Club.class i domenemodellen. RestController for seletøyressurser (utstyr). Ressursene er de samme som innholdet i RestHarnessContainer.class i domenemodellen. RestController for hendelsestyperessurser. Ressursene er de samme som innholdet i IncidentType.class i domenemodellen. RestController for hopptyperessurser. Ressursene 111

112 RestLicenseController RestLocationController RestMainCanopyController RestManufacturerController RestParachutistController RestQuartalReportController RestReserveCanopyController RootController UserResource er de samme som innholdet i JumpTypes.class i domenemodellen. RestController for lisensressurser. Ressursene er de samme som innholdet i License.class i domenemodellen. RestController for lokasjonsressurser. Ressursene er de samme som innholdet i Location.class i domenemodellen. RestController for hovedskjermressurser (utstyr). Ressursene er de samme som innholdet i MainCanopy.class i domenemodellen. RestController for produsentressurser. Ressursene er de samme som innholdet i Manufacturer.class i domenemodellen. RestController for fallskjermhopperressurser. Ressursene er de samme som innholdet i Parachutist.class i domenemodellen. RestController for kvartalsrapportressurser. Ressursene er de samme som innholdet i QuartalReport.class i domenemodellen. RestController for reserveskjermressurser. Ressursene er de samme som innholdet i ReserveCanopy.class i domenemodellen. Controller for link til alle rotressursene. RestController for autentisering og autorisering. No.nlf.rest.tokens Klasse AuthenticationTokenProcessingFilter TokenUtils UnauthorizedEntryPoint Beskrivelse Setter hva slags headere som skal være tillatt, og håndterer mottakelse av Tokens. Er knyttet til Spring Security og UserDetailService. Lager og validerer tokens. Melding om uautorisert innlogging. No.nlf.rest.transfers Klasse TokenTransfer UserTransfer Beskrivelse Klasse get- set tokens Klasse get set users 112

113 Vedlegg 5 - Filstruktur frontend Controllerklasse for administrasjon av lokasjoner og hovedinstruktører Controllerklasse for klubber Controllerklasse for administrasjon av klubber Controllerklasse for administrasjon av utstyr Controllerklasse for utlisting og detaljvisning av avvik Controllerklasse for side 3 i registreringen av avvik, legg til hendelser Controllerklasse for administrasjon av hendelsestyper Controllerklasse for administrasjon av lisenser 113

114 Controllerklasse for administrasjon av lokasjoner Controllerklasse for index.html Controllerklasse for 2.html Controllerklasse for håndtering av involverte personer Controllerklasse for håndtering av dato og tid, samt lagring og henting av rapport under registrering AngularJS rammeverket Bibliotek for å kunne benytte cookies Bibliotek for kommunikasjon med RESTbackend Bibliotek for routing av single page applikasjoner Konfigurasjonsfil for token Twitter Bootstrap rammeverket Twitter Bootstrap 114

115 rammeverket Twitter Bootstrap rammeverket Twitter Bootstrap rammeverket Twitter Bootstrap rammeverket Twitter Bootstrap rammeverket Twitter Bootstrap rammeverket Twitter Bootstrap rammeverket Gif-animasjon Styling av Bootstrap datetimepicker Norsk språkpakke til Bootstrap datetimepicker Bibliotek for Bootstrap datetimepicker Styling av Bootstrap datetimepicker 115

116 Moment.js, bibliotek for håndtering av dato og tid, benyttes av Bootstrap datetimepicker Bibliotek for søkbare selectbokser Wrapper- bibliotek for tilpasning av Select2 til AngularJS Styling av select2 Styling av select2 Norsk språkpakke Twitter Bootstrap rammeverket jquery rammeverket, brukes av Twitter Bootstrap Hovedside for administrator 116

117 Administrasjon av klubber Administrasjon av utstyr Administrasjon av hendelsestyper Administrasjon av hopptyper Administrasjon av lisenser Administrasjon av lokasjoner Liste over alle lokasjoner Detaljert visning av valgt rapport Første side i rapportering, valg av type rapport, klubb, lokasjon, dato og involverte personer Registrering av lisenser, hopptype og erfaring på hver enkelt involvert Registrering av hendelsesforløp Gjennomlesing før rapporten sendes videre 117

118 Hovedside for avviks- registrering Rammen rundt single page applikasjonen. Alle andre sider vises inni index.html Filer merket med grått er biblioteker og rammeverk vi har benyttet oss av, mens filer merket med hvitt er dokumenter vi har skrevet selv. 118

119 Vedlegg 6 - Brukertest Vi brukte to forskjellige case for brukertestene. Begge casene var basert på virkelige avvik som var rapportert med det eksisterende hendelsesrapporteringssytemet. Case 1 En hendelse som omhandler en feilfunksjon på hovedskjerm med påfølgende nødprosedyre. Dato ID 1408 Kategori Naeruhell Kjennelse (ingen) Sted Klubb Stend Bergen Nak-nr ********** Sertifikat EL Medlemsklubb Bergen Hopptype UFF Prod hovedskjerm PD Modell hovedskjerm Navigator Stør. h. skjerm (sqft) 260 Erfaring år 1 Erfaring hopp 20 Erfaring hovedskjerm 0-10 Skjermutløsing Seletøy produsent VectorSE Skjerm Seletøy modell Åpning Seletøy erfaring Håndtak Utløsersystem Liner vridd Annen feil Feilfunksjon Produsent reserveskj. PD Materiellkontrollør ********** Reserveskj. modell PR253 MK lisens nr. ********** Størrelse res. (sqft) 253 Res. skjerm pakket Nødåpner Ikke aktuelt Siste Cypres 4års kontr. S/N nødåpner FXC kalibrert før hopp Ikke aktuelt Siste batteribytte FXC kalibrert av 119

120 Siste FXC kontroll Vind Vind maks Skade Skade, annen HL HL var også elevens HM på dette løftet. Normalt hopp og skjermåpning, men oppdager «salto i seletøy»/tvinn på risere. Blir i tvil om han kan lande skjermen og utfører korrekt nødprosedyre. Inspeksjon av utstyret etterpå viser at LOR ikke ble aktivert. Utstyr ble inspisert av undertegnede, både på bakken, før hoppet, og i flyet uten at LOR-smykket var frikoblet. Hoppleder ********** HLs epost ********** HI Viser kor viktig det er å fullføre nødprosedyre. Hovedinstruktør ********** E-post HI ********** Rapportert Case 2 Denne omhandler samme avvik med to involverte personer. Avviket var derfor innrapportert som to forskjellige hendelser Dato ID 1411 Kategori Naeruhell Kjennelse (ingen) Sted Klubb Bømoen Bergen Nak-nr ********** Sertifikat B Medlemsklubb Bergen Hopptype Trening Prod hovedskjerm PD Modell hovedskjerm Spectre Stør. h. skjerm (sqft) 150 Erfaring år 2 Erfaring hopp 315 Erfaring hovedskjerm Skjermutløsing Skjerm Seletøy produsent Seletøy modell 120

121 Åpning Håndtak Seletøy erfaring Utløsersystem Liner Annen feil Feilfunksjon Produsent reserveskj. Reserveskj. modell Størrelse res. (sqft) Materiellkontrollør MK lisens nr. Res. skjerm pakket Nødåpner Ikke aktuelt Siste Cypres 4års kontr. S/N nødåpner FXC kalibrert før hopp Ikke aktuelt Siste batteribytte FXC kalibrert av Siste FXC kontroll Vind 2 Vind maks 2 Skade Skade, annen Vondt i hodet og nakke senere samme kveld. HL Se rapport med samme sted/dato. ********** ble truffet bakfra rett etter landing av **********. Ble truffet i hodet (hadde fortsatt hjelm på) og fikk smerter i hodet,men ikke tap av bevissthet. Fikk senere samme kveld og neste dag smerter i nakke. Akuttmedisinsk behandling ble, i samråd med hopper, ikke vurdert nødvendig. Hoppleder ********** HLs epost ********** HI Viser til rapport med ********** samme sted og dato. Dette er den samme hendelsen. ********** sto i ro på landingsområdet og kunne ikkje gjort noko anneledes. Hovedinstruktør ********** E-post HI ********** Rapportert Dato ID 1410 Kategori Naeruhell Kjennelse (ingen) Sted Bømoen 121

122 Klubb Bergen Nak-nr ********** Sertifikat B Medlemsklubb Voss Hopptype Trening Prod hovedskjerm PD Modell hovedskjerm Sabre Stør. h. skjerm (sqft) 150 Erfaring år 1 Erfaring hopp 88 Erfaring hovedskjerm 0-10 Skjermutløsing Seletøy produsent UPT Skjerm Seletøy modell Vector Åpning Seletøy erfaring 0-10 Håndtak Utløsersystem BOC Liner Annen feil Feilfunksjon Produsent reserveskj. Reserveskj. modell Størrelse res. (sqft) Materiellkontrollør MK lisens nr. Res. skjerm pakket Nødåpner Ikke aktuelt Siste Cypres 4års kontr. S/N nødåpner FXC kalibrert før hopp Ikke aktuelt Siste batteribytte FXC kalibrert av Siste FXC kontroll Vind 2 Vind maks 2 Skade Skade, annen HL Skjermkollisjon i landing. Hopper **********, NAK: ********** hadde nettopp landet og skjerm var på vei til å legge seg ned, da hopper ********** kom inn for landing bakfra og traff ********** skjerm, hektet og landet relativt hardt i bakken fra ca 1,5-2 meters høyde. Utstyret til ********** fikk noen små skader: bla overflatisk rift på hovedrisere. Disse skadene ble besiktiget av MK og ikke vurdert til alvorlige, men hopper sørger likevel for å få disse utbedret snarest. 122

123 Hoppleder ********** HLs epost ********** HI HL har hatt en god dialog med begge hoppere, og ********** er helt inneforstått med eget ansvar for situasjonen. Hun beklager hendelsen sterkt og forklarer hendelsesforløpet med overfokusering på tiltenkt landingspunkt og manglende evne til å styre unna situasjonen når kollisjon ble uungåelig. HL og ********** har i ettertid snakket om viktighet av å skape god separasjon tidligst mulig før/under innflygning (henge på brems osv), samt mulighet for bruk av flate svinger. Hovedinstruktør ********** E-post HI ********** Rapportert For testen ble det satt opp følgende sjekkliste. 1. Innlogging Testpersonen blir presentert med startsiden på en pc. Blir tildelt brukernavn og passord og bedt om å logge seg inn. 2. Tilbakemelding på førsteside. 1. Så hva tenker du om denne nettsidesløsningen, hva er det du ser og tenker ved første øyekast? 2. Hva er annerledes med denne planleggeren kontra det du er vant til? (førsteinntrykk)? (oppfølgingsspørsmål) 3. Hva kan du gjøre i dette vinduet? Hva forventer du at kommer til å skje når du interagerer på denne måten? 3. Registrer avvik. Testpersonen blir presentert med et reelt avvik skjedd i 2014 og bedt om å rapportere inn dette. 1. Tilbakemelding på siden, a. Hva er det du ser og tenker ved første øyekast? b. Hva er annerledes med denne planleggeren kontra det du er vant til? (førsteinntrykk)? (oppfølgingsspørsmål) c. Hva kan du gjøre i dette vinduet? Hva forventer du at kommer til å skje når du interagerer på denne måten? 2. Angi type rapport 3. Velg klubb der avviket skjedde. 4. Velg sted for avviket, eller angi sted. 5. Angi tidspunkt for avviket. 6. Angi innvolverte personer. 7. Tilbakemelding på interaksjon: 123

124 a. Hva var bra med løsningen b. Hva burde være annerledes. 4. Fyll ut informasjon om involverte personer. Testpersonen blir presentert med siden for kontroll og utfylling av personopplysninger. 1. Tilbakemelding på siden, a. Hva er det du ser og tenker ved første øyekast? b. Hva er annerledes med denne planleggeren kontra det du er vant til? (førsteinntrykk)? (oppfølgingsspørsmål) c. Hva kan du gjøre i dette vinduet? Hva forventer du at kommer til å skje når du interagerer på denne måten? 2. Kontroller og oppdater innvolvert person. 3. Tilbakemelding på interaksjon: a. Hva var bra med løsningen? b. Hva burde vært gjort anderledes? 5. Legg til hendelser til avviket. Testpersonen blir presentert med siden for å legge til hendelser med avviket. 1. Tilbakemelding på siden, a. Hva er det du ser og tenker ved første øyekast? b. Hva er annerledes med denne planleggeren kontra det du er vant til? (førsteinntrykk)? (oppfølgingsspørsmål) c. Hva kan du gjøre i dette vinduet? Hva forventer du at kommer til å skje når du interagerer på denne måten? 2. Legg til hendelser til avviket. 3. Tilbakemelding på interaksjon: a. Hva var bra med løsningen? b. Hva burde vært gjort anderledes? 6. Oppsummering Generell tilbakemelding på løsningen Hva var bra med løsningen? Test med Jan Wang, case 1. Brukerinteraksjon Så ikke at personen var registrert med feil lisens i melwin i forhold til lisensstatus til hopperen nevnt i avviket. Fylte ut en hendelse men trykket ikke på legg til hendelseknappen. Var usikker på hva kommentarfeltet betydde. Var det kommentar fra HL eller HI? Lite felt, vanskelig å lese hva 124

125 man har skrevet i etterkant.ville legge til en ny person i dette vinduet, prøvde å finne ut hvordan. La først til bare feilfunksjonen som hendelse, ikke nødprosedyre. Glemte å trykke på legg-til hendelsen med frakoblet smykkelås. Denne hendelsen ble da ikke lagt til i avviket. Generell usikker på forskjellen mellom kommentarer på hendelser og avvikskommentaren. Hvor bør det skrives? Generelt postiv til løsningen, men var noe usikker på hvordan siden med hendelser skulle betjenes. Savnet større vindu for å kommentere enkelthendelser. Teknisk Testen avdekket en feil med innlesing av persons ressursen. Dette fant vi fort ut var fordi ressursen ble forsøkt hentet før autentisering og autentisering av bruker. Test med Jan Wang, case 2 Brukerinteraksjon Syntes det ikke var helt selvforklarende hvordan legge til personer. Savnet informasjon om klubbmedlemskap til hopperen i vinduet for medlemskontroll Ved legge til hendelser, savnet kategori på hoppet, burde kanskje ikke velges hvis hopptype ikke er relevant som for eksempel i avvik der hendelsen er landingsrelatert. Test med Tore Granmo, case 1 Brukerinteraksjon Problemer med klokke ved angivelse av tidspunkt. Hadde litt problemer med å forstå betjeningen. Valgte og la til hendelser i vinduet, men la ikke til personer til hendelsen. Haket ikke av navnet på den involverte. Savnet større vindu for å kommentere hendelser Hadde ingen spesielle ønsker om forandringer med tanke på brukere med dysleksi. Test med Tore Granmo, case 2 Brukerinteraksjon Valgte og la til hendelser i vinduet, men la ikke til personer til hendelsen. Haket ikke av navnet på den involverte. Oppsummering av brukertestene. Erfaringene etter testene viste at det burde gjøres endringer på siden der det legges til hendelser til avviket. Denne siden var testerne mest usikker på bruken av. For begge testerne gikk registrering av case 2 betydelig raskere enn med case

126 126

127 Vedlegg 7 - Tilbakemelding fra oppdragsgiver. Fra høsten 2008 har Fallskjermseksjonen sett etter løsninger på et nytt avviksrapporteringssystem. Flere alternativer for kjøp av eksisterende systemer eller utvikling av et nytt system er blitt vurdert og forkastet. På årsmøtet 2013 ble det vedtatt og satt opp et budsjett for utvikling av et nytt system. Høsten 2013 ble Fallskjermseksjonen kontaktet av studentgruppen der de tilbød seg å starte på prosjektet som bacheloroppgave. Våren 2014 har Eivind Jacobsen, Tore Buer og Morten Kristoffersen jobbet med utvikling av en ny avviksrapporteringsapplikasjon. De har fått på plass en løsning som i disse dager er til brukertesting av rapportering. Avviksrapporteringsapplikasjonen som er utviklet av studentgruppen vil løse de utfordringer Fallskjermseksjonen har i dag i forbindelse med avviksrapportering. Det har blitt engasjert en gruppe med utviklere som vil fortsette med å ferdigstille applikasjonen med planlagt bruk av applikasjonen fra 1. januar Fallskjermseksjonen er svært fornøyd med resultatet så langt og vil fortsette testingen ut året og intensjonen er å ta det i bruk fra 1. januar Jan Erik Wang Fagsjef Fallskjermseksjonen / Norges Luftsportforbund Oslo 26/

128 Vedlegg 8 Risikoanalyse BACHOLOROPPGAVE TITTEL: AVVIKSRAPPORTERING F/NLF RISIKO BETYDNING TILTAK FOREBYGGING SANNSYNLIGHET KOMMENTARER Sykdom (over lengre tid) Middels Fordele mer arbeid på gjenværende gruppemedlemmer. Evt. Kutte ned på kravspesifikasjonen. Lev sunt, gode arbeidstimer og ikke overdrivelse av arbeid Liten Uenighet i gruppe Liten Avgjøre med diskusjon. Være flinke til å være åpne med hverandre og ta saklige diskusjoner. Liten Klarer ikke å levere ferdig produkt Middels-høy Må da levere kildekode med forklaring på hva vi har gjort. Foreta estimeringer ofte, og hele tiden sørge for at vi har kjørende applikasjon, men legger til funksjonalitet for hver iterasjon. Liten Kunde vil veldig gjerne ha noe kjørbart ved prosjektslutt. (De er inneforstått med at det skal videreutvikling til også) Bruker mye tid på å implementere teknologier vi ikke kan Middels Finne enklere og raskere løsninger. Gjør mye research på forhånd. Feilsøke systematisk og effektivt. Liten-middels Syke barn Middels Jobbe hjemmefra Liten-middels 2 av gruppemedlemmene har barn Oppdragsgiver ikke har nok tid til å svare på krav og ønsker fra oss Middels Mase på oppdragsgiver. Evt. Ta beslutninger selv. Informere viktigheten av dette til oppdragsgiver på forhånd og forklare konsekvensen av dette. Middels Oppdragsgiver har ikke tid til å kommentere brukertesting Middels Evt. Teste på oss selv å andre Informere viktigheten av dette til oppdragsgiver på forhånd og forklare konsekvensen av dette. Liten RISIKO TOTALT: LITEN-MIDDELS LITEN RISIKO RISIKOANALYSE SLUTT DATO:

129 Vedlegg 9 Fremdriftsplan 129