Jan Wang Fagsjef Fallskjermseksjonen/Norges Luftsportforbund (F/NLF) og oppdragsgiver Tlf:

Transkript

1 Forprosjektrapport Gruppe 13 Presentasjon Gruppesammensetning: Morten Kristoffersen, s Dataingeniør Eivind Jacobsen, s Anvendt Datateknologi Tore Buer, s Anvendt Datateknologi Kontaktpersoner: Eva Vihovde Intern veileder Høyskolen i Oslo og Akershus EvaHadler.Vihovde@hioa.no Tlf: Nils Ove Erstad Konsulent i Accenture og veileder for vårt prosjekt nils.ove.erstad@accenture.com Tlf: Fredrik Bjørnøy Konsulent i Accenture og veileder for vårt prosjekt fredrik.bjornoy@accenture.com Tlf: Jan Wang Fagsjef Fallskjermseksjonen/Norges Luftsportforbund (F/NLF) og oppdragsgiver jan.wang@nlf.no Tlf: Accenture Accenture er et globalt konsern som tilbyr konsulent, teknologi og outsourcingtjenester innen IT. De gjennomfører prosjekter for offentlige og private virksomheter og har idag ca ansatte i 53 land. Accenture er et av de største konsulentselskapene i verden.

2 Norges Luftsportsforbund Norges Luftsportsforbund (NLF) er et særforbund innen Norges idrettsforbund og Fallskjermseksjonen er en adskilt seksjon innen Norges Luftsportsforbund. Sammendrag F/NLF har i dag et papirbasert system for rapportering av hendelsene. Registrering av rapporter i felles system 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. I dette systemet 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. En responsiv webklient vil skape en opplevelse av dialog med brukeren, der kun aktuelle felter for det gitte avviket som skal registreres blir synlig. Systemet bygges med fokus på muligheter for videreutvikling, og utskifting av deler av systemet. Systemet 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. Dagens situasjon F/NLF har i flere år sett etter en bedre løsning for rapportering av hendelser enn det de har i dag. Dagens løsning er papirbasert, der et skjema fylles ut med penn og papir av inntil tre forskjellige personer, for deretter å scannes og sendes pr epost, og manuelt skrives digitalt og lagre som pdf. I 2009 ble det skrevet en oppgave av Frode Finnes Larsen i forbindelse med et C trenerkurs i fallskjermseksjonen. Oppgaven tar for seg problematikken rundt dagens system for hendelsesrapportering og drøfter flere mulige løsninger. F/NLF har altså lagt ned en del arbeid rundt et elektronisk rapporteringssystem, men uten at noen løsning har blitt produsert. Oppgaven til Frode Finnes Larsen forutsetter at leseren har god kjennskap til hvordan F/NLF har organisert fallskjermhoppingen i Norge operativt. Her følger derfor en kort forklaring og oversikt. Organisering av fallskjermhopping i regi av F/NLF Fallskjermseksjonen er en av to organisasjoner i Norge som har tillatelse fra Luftfartstilsynet til å drive med fallskjermhopping sivilt. Kravet Luftfartstilsynet har til organisasjoner som ønsker å

3 gjennomføre fallskjermhopping i sivil regi er beskrevet i Bestemmelser for Sivil Luftfart D 4 2 (BSL D4 2). Et krav som Luftfartstilsynet setter, er at organisasjonen skal ha et system for rapportering av avvik av organisasjonens bestemmelser for utdanning, materiell og operativ drift. Sikkerhetsbestemmelsene til F/NLF er beskrevet i F/NLF Håndbok. Her er det satt som krav at rapporteringspliktige hendelser skal rapporteres inn fra klubbene innen 48 timer. Hendelser deles inn i 3 forskjellige kategorier: 1. Næruhell Dette kan være brudd på sikkerhets eller materiellreglement. Feilfunksjoner som ender med bruk av reserveskjerm. 2. Uhell Hendelser som ender med skade som må behandles av lege. 3. Ulykke Hendelser som ender med død, eller varige men. Hver gang det er hopping er det utpekt en Hoppleder (HL) som er operativ ansvarlig under hoppingen. Ved eventuelle hendelser er det HLs oppgave å skrive en hendelsesrapport. I dag skrives disse rapportene ved å fylle ut et skjema på papir. Se også utdrag av skjema på side 4. HL overleverer så dette skjemaet til fallskjermklubbens hovedinstruktør (HI) som skal legge ved sine kommentarer og sende rapporten inn til F/NLF sentralt. Denne rapporteringen skjer elektronisk via et web skjema. F/NLF har ansatt en person kalt fagsjef som jevnlig henter ut nye hendelser fra hendelsedatabasen. Seksjonen har en komité kalt Sikkerhets og Utdanningskomiteen (SU) som går igjennom hendelsene, setter opp statistikk og bruker dette som beslutningsgrunnlag for eventuelle revisjoner av F/NLF Håndbok. Skjema for hendelsesrapportering:

4 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å avkryssningsvalg. 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 fritekskt og avkryssningsvalg. 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. Det er ingen veiledning for kommentarene. Det SU gjerne vil se i disse kommentarene er 3 punkter: a. Hva som har skjedd b. HL og HIs formening om hvorfor det har skjedd. c. Hvilke tiltak HL og HI har iverksatt i etterkant for å sørge for at samme type hendelse kan unngås i fremtiden. Mål og rammebetingelser Som et minimum skal man i systemet kunne registrere avvik i en webklient der autoriserte personer har tilgang. Systemet skal tilby en administrasjonsside der autoriserte personer kan lese, endre og skrive ut et utvalg av rapporter for videre analyse. Data skal lagres i en egen database, og systemet skal kunne kommunisere med eksisterende medlemsregister Videre er det ønsket at systemet skal gi rom for minst mulig fritekst, samtidig som det skal være raskt og enkelt å fylle ut en rapport. For å nå dette ønsket er det viktig at kun de feltene som er aktuelle for den typen avvik som blir registrert er synlig, mens irrelevante felter skjules. Tidligere registrerte rapporter må granskes for å finne typer avvik, og variasjoner av disse, som må kunne registreres. F/NLF har gått til anskaffelse av en Linux server som utelukkende skal benyttes til dette systemet. Det er også satt av midler til prosjektet, slik at eventuelle anskaffelser forbundet med systemet kan godkjennes på kort varsel. F/NLF er en frivillig organisasjon, og personene som i fremtiden skal benytte systemet gjør dette på fritiden. Brukertesting og innspill i forbindelse med prosjektet vil bli gjort av en gruppe som

5 frivillig har takket ja til å bridra. Dog forventer vi at deres motivasjon vil variere over tid, noe som kan forlange responstiden. Vi har derfor bedt om at størrelsen på gruppen økes, nettopp for å kunne få god nok respons ved hver sprint demo. Se også vedlegg 1, Brukerhistorier Løsninger og alternativer Under dette punktet gjenstår det en del avgjørelser, og informasjonen under vil derfor være tentativ. Hva Hvordan Hvilken/Hvilke Kommentar/Begrunnelse Utviklingsmetode Smidig Scrum Smidig metodikk. Oppdragsgiver vil kunne endre sine ønsker underveis, uten at det medfører større problemer for utviklerne. Gruppen har også tatt kurs i Scrum. Brukergrensesnitt frontend Webklient, responsiv HTML5, CSS3, JavaScript, jquery, Twitter Bootstrap 3.0 HTML/Css for ui. Bootstrap for responsivt design. Vurderer også AngularJS. Backend Web API REST Java Spring/Jersey Frikobling mellom server og klient. Database, ikke avgjort Relasjonsdatabase PostgreSQL Standard relasjonsdatabase MongoDB Dokumentdatabase, klassifisert som NoSQL database. Enklere å utvide og videreutvikle enn relasjonsdatabaser. Spørringer returnerer JSON liknende objekter, kalt BSON. Arkitektur Lagdelt REST Web API, BLL (Business Logic Layer), DAL (Data Access Layer), Database(r) Enklere videreutvikling. Ett lag kan endres eller skiftes ut, uten at dette påvirker de andre lagene Versjonskontroll Distribuert Git Distribuert, endringslogg, backup av kode. Varsling av konflikter, sammenslåing av filer Enhetstesting TDD JUnit Enhetstesting. Bedre bevisstgjøring av hva hver metode og klasser skal gjøre,

6 før koden skrives. Mindre fare for større feilsøkingsjobber, siden hver metode blir testet separat Prosjektstyring Atlassian Jira Sprintplanlegging, oversikt over brukerhistorier, backlog osv. Confluence Deling av data og informasjon Byggeverktøy, ikke avgjort Atlassian Bamboo Integrasjonsverktøy. Settes opp til å bygge systemet automatisk. Kommuniserer med Git repository og andre Atlassiansystemer. Jenkins Continous Integration Integrasjonsverktøy. Kommuniserer med Git repository. Automatisk bygging gjør det enklere å kjøre hyppige brukertester Bygg/administreringsverktøy Prosjekthåndtering Maven Uniformt byggsystem. Gir god oversikt over prosjekt dependencies. Forenkler build prosessen.

7 Arkitektur Fig. 1: Lagdeling av systemet For å gjøre systemet modulært og da lettere å oppdatere og videreutvikle, vil arkitekturen være lagdelt. Man kan dele systemet opp i to hoveddeler: Et backend system som består av databaser og et web API som er et REST grensesnitt. Data som går mellom backend og frontend er i JSON eller XML format. Avvikene lagres i en database på serveren der systemet ligger. Dette kan være en relasjonsdatabase eller en nosql dokumentdatabase. Data om personer som er medlemmer i NLF blir hentet via et web API mot medlemsdatabasen Melwin. En frontend klient som i dette prosjektet vil være en webclient med et responsivt design for å gi en god brukeropplevelse på forskjellige plattformer.

8 Analyse av virkninger For F/NLF så vil gevinsten av et godt system for hendelsesrapportering gi to ting: Redusert administrasjon og bedre informasjonskvalitet. Redusert administrasjon oppnås ved at rapporten kun skrives en gang, og at det hovedsaklig benyttes faste felter. Fritekst brukes kun til utfyllende informasjon ved behov. rapportene valideres før innsending. Dette reduserer HI og/eller Fagsjefens arbeid med å renskrive hver enkelt rapport utvalgte rapporter kan skrives ut (som pdf), uten behov for manuell redigering av felter datasett for bruk i statistikk kan tas ut fra systemet, uten behov for å lese igjennom hver enkelt rapport. Bedret informasjonskvalitet oppnås ved at rapporten skrives digitalt, og kun en gang, i motsetning til i dag der rapporten først skrives med penn og papir for så å punches inn digitalt på et senere tidspunkt rapporten kan påbegynnes umiddelbart og lagres, for så å fullføres på et senere tidspunkt sjansen for at påbegynte rapporter ikke fullføres blir umulig faste felter gir mindre rom for subjektiv tolkning av hva som har skjedd og årsaken til det I tillegg vil enklere tilgang til tidligere rapporter og statistikk kunne bidra til å se trender tidlig, noe som kan gi økt sikkerhet for hoppere. Oslo, 24/ Morten Kristoffersen Eivind Jacobsen Tore Buer

9

10 Vedlegg 1 - Brukerhistorier 1. Som HL ønsker jeg at å registrere et avvik skal være så lett som mulig med minst mulig informasjon fordi hopppdagen er hektisk og det er lett å glemme men nå er den registrert og jeg kan ta tak i den når jeg har tid 2. Som HL ønsker jeg å kunne skrive inn og redigere en rapport, og siden frigjøre denne for HI'kommentarer. Slik vil jeg kunne legge inn en rask kommentar mens jeg er på feltet, for siden å fylle på med relevant informasjon når jeg har bedre tid etter hopping, og derfor gi HI en bedre og mer utfyllende rapport. 3. Som HL ønsker jeg å kunne gi andre hoppere tilgang til å kommentere en rapport som jeg selv skriver. Slik vil jeg enkelt kunne hente inn uttalelser, vitneutsagn, kommentarer fra andre, noe som igjen vil føre til mer utfyllende rapporter. 4. Som HL ønsker jeg å kunne registrere flere personer i en hendelse. 5. Som HL ønsker jeg å enkelt kunne se andre avvik som er registrert på hopperen(e) jeg registrerer i gjeldende avvik. Slik kan jeg raskt få oversikt om hopperen har hatt lignende avvik eller andre forhold som kan ha innvirkning på min behandling av avviket. 6. Som HL ønsker jeg å kunne "tagge" personer i en rapport, slik at disse får tilgang til å gjøre sine kommentarer i rapporten 7. Som HL ønsker jeg at video og bilder fra avviket kan lastes opp under registreringen, slik at førstehåndsdokumentasjon blir tilgjengelig for senere bruk 8. Som HL ønsker jeg at irrelevent informasjon ikke må rapporteres 9. Som HI ønsker jeg å ha oversikt i form av en tabell/liste over alle avvik i klubben uansett status med nøkkelinformasjon fordi dette vil gjøre at jeg oppnår å raskt ha oversikt over avvikene 10. Som HI ønsker jeg å kunne filtrere avvik på nøkkelinformasjon slik at jeg oppnår å kunne finne de avvikene som jeg er interessert i gjennom flere dimensjoner som status, hopper, type 11. Som HI ønsker jeg å raskt kunne sende en rapport tilbake til rapporterende HL eller andre involverte når det mangler informasjon eller noe er uklart som vil lette arbeidet mitt og øke datakvaliteten 12. Som HI ønsker jeg å kunne legge ved kommentarer når jeg sender en rapport tilbake til HL fordi jeg da kan presisere hva som må gjøres og minimere misforståelser og få det jeg er ute etter tilbake 13. Som hopper ønsker jeg å kunne lese aviksrapporter, gjerne anonymiserte, fordi jeg vil lære av andres feil 14. Som HI ønsker jeg å få varsel på sms eller epost når HL legger oppretter en avviksrapport eller gjør endringer i status fordi jeg nå kan respondere raskt uten å måtte logge inn for å sjekke om det er noe nytt hver gang 15. Som HI ønsker jeg muliget for å se en hoppers historikk. 16. Som HI vil jeg få en påminnelse et par uker ettar at rapporten er levert, om den feks bør oppdateres om mer informasjon rundt skade eller tilbakemelding/oppfølging som er gitt til hopperen.

11 17. Som HI ønsker jeg å kunne avslå/slette rapporter som ikke er relevante, slik at unødvendige rapporter ikke blir liggende lagret 18. Som HI ønsker jeg å kunne redigere (legge til og slette) personer som er tagget i en rapport 19. Som HI ønsker jeg å kunne avgjøre om et avvik krever behov for ytterligere undersøkelser/granskning 20. Som HI ønsker jeg et varsel om ufullstendige rapporter fra HL i god tid før det er gått 48 timer siden hendelsen fant sted, slik at jeg kan sørge for at HL fullfører sin del, og jeg kan gjøre mine 21. kommentarer før den sendes videre. 22. Som HI ønsker jeg å kunne avslå/slette rapporter som ikke er relevante, slik at unødvendige rapporter ikke blir liggende lagret 23. Som Hl ønsker jeg å kunne registrere data som utsprangshøyde, temperatur og høyden avviket skjedde, dersom dette er relevant for rapporten. 24. Som HI ønsker jeg å kunne redigere (legge til og slette) personer som er tagget i en rapport 25. Som HI ønsker jeg å kunne avgjøre om et avvik krever behov for ytterligere undersøkelser/granskning 26. Som HI ønsker jeg et varsel om ufullstendige rapporter fra HL i god tid før det er gått 48 timer siden hendelsen fant sted, slik at jeg kan sørge for at HL fullfører sin del, og jeg kan gjøre mine kommentarer før den sendes videre. 27. Som bruker av systemet ønsker jeg selv å kunne velge hvordan jeg skal bli varslet eller slå varsling helt av. Slik kan jeg tilpasse systemet til mine behov og unngå å føle at systemet plager meg 28. Som bruker ønsker jeg å kunne laste opp filer som gir ekstra dokumentasjon til avviket, for eksempel, video og bilder, eller pdf filer med vitneutsagn 29. Som bruker ønsker jeg å kunne legge til gradering av medisinsk invaliditet dersom dette er relevant 30. Som bruker ønsker jeg å kunne kommentere andres rapporter, for å etterspørre informasjon og bidra med tips 31. Som bruker ønsker jeg at systemet fanger opp flest mulig feil før innsending, slik at informasjonskvaliteten holdes på et høyt nivå 32. Som bruker av systemet ønsker jeg at skjermbilder er tilpasset min rolle, slik at jeg lett kan lese informasjonen som er relevant for meg 33. Som bruker ønsker jeg å kunne endre oppføringen i MelWin gjennom en personlig administrasjonsside 34. Som bruker av systemet ønsker jeg at innsender av rapporten registreres som personen som faktisk gjorde registreringen og ikke som "HI TøFSK" 35. Som bruker ønsker jeg å få varsel på sms/mail når det legges inn rapport hvor jeg selv er nevnt, fordi det vil ivareta rettsikkerheten at jeg vet hva som er rapportert om meg 36. Som statistikkansvarlig F/NLF ønsker minst mulig fritekst og mest mulig predefinert tekst, og å kunne eksportere alle rapporter for import i annet system

12 37. Som Fagsjef ønsker jeg å kunne gi tilgang til systemet til de personene som har behov for det, uavhengig av rollen de faktisk har. 38. Som Fagsjef ønsker jeg at kvartalsrapportering kan gjøres i systemet, slik at statistikker blir oppdatert fortløpende 39. Som Fagsjef ønsker jeg å kunne godta eller avslå nye labels som er lagt inn av HL/HI og eventuelt knytte rapporten til eksisterende labels slik at feltene er så entydige som mulig 40. Som Fagsjef ønsker jeg å kunne deaktivere eksisterende labels slik at disse ikke kan benyttes i nye rapporter 41. Som Fagsjef ønsker jeg varsling dersom en hopper er tildelt permanent hoppforbud 42. Som HI/Fagsjef/SU medlem ønsker jeg automatisk varsling ved rapportering av alvorlige skader 43. Som Fagsjef ønsker jeg at systemet er enkelt å vedlikeholde, slik at jeg kan fristille tid til annet arbeid 44. Som HI/Fagsjef/SU medlem/statistikkansvarlig ønsker jeg å kunne lagre utvalg av rapporter med mine kriterier, slik at jeg kan følge med på utviklingen over tid. Eksempler kan være rapporter på en gitt person, eller skader på uerfarne hoppere 45. Som Fagsjef ønsker jeg en varsling pr epost når nye hendelsesrapporter er godkjent av HI. 46. Som Fagsjef ønsker jeg at uleste hendelsesrapporter blir uthevet i systemet 47. Som Fagsjef ønsker jeg å kunne legge til hendelser som tidligere ikke har blitt rapportert, slik at forsikringsselskapene kan få den informasjonen de behøver 48. Som SU medlem ønsker jeg å rangere alvorlighetsgrad på innkommende hendelser, slik at disse blir fremhevet for senere bruk. 49. Som SU medlem ønsker jeg å kunne markere hendelser slik at disse kan tas med i rapportering til fagseminaret