Hovedprosjekt. Teknologi, kunst og design Høyskolen i Oslo og Akershus, våren 2014

Transkript

1 Hovedprosjekt Høyskolen i Oslo og Akershus, våren 2014 Sted/Dato: Høyskolen i Oslo og Akershus, Oslo Tittel: Prosjektmedlemmer: Tore Angell Petersen Tommy Kihlstrøm Alexander Seldal Bakke s s s Oppdragsgiver: EVRY AS, Snarøyveien 30A, 1360 Fornebu, tlf: / Kontaktperson: Nino Lo Cascio, tlf: , nino.lo.cascio@evry.com

2

3 PROSJEKT NR. 29 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen HOVEDPROSJEKT Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL DATO ANTALL SIDER / BILAG PROSJEKTDELTAKERE Tommy Kihlstrøm Tore Angel Petersen Alexander Seldal Bakke INTERN VEILEDER Simen Hasselknippe OPPDRAGSGIVER EVRY AS KONTAKTPERSON Nino Lo Cascio SAMMENDRAG er et system laget for å opptimalisere registrering av vitale verdier på pasienter. ehelse Live dataoverføring til flere klienter Scoringsalgoritme for vitale verdier hos pasient Utviklet for videreutvikling og fremvisning Tilgjengelig for bruk på mobile plattformer 3 STIKKORD Windows 8 Store app(xaml/c#) Scrum MEWS

4

5 DOKUMENTOVERSIKT 1. Sammendrag Produktrapport Prosessrapport Vedlegg Litteraturliste Figurliste

6 6

7 Høyskolen i Oslo og Akershus, våren 2014 Dokument 1 Sammendrag 7

8 8

9 INNHOLDSFORTEGNELSE FOR SAMMENDRAG 1 Sammendrag Om gruppen Problemstilling Bakgrunn for prosjektet Produkt Prosess Sammendrag

10 1 SAMMENDRAG Høyskolen i Oslo og Akershus Hovedprosjektet er ment å gi studentene arbeidserfaring og mulighet til å skaffe seg et nettverk i næringslivet. Avtalen med EVRY AS kom i stand høsten 2013, med prosjektoppstart og innleveringsfrist kl.12:00. Faget gir totalt 20 studiepoeng. Vi vil takke Nino Lo Cascio, Benny Andreassen og Lise Grette Strømmen på EVRY. Dere har gitt oss og hjulpet oss mye med bacheloroppgaven, en stor takk til dere alle sammen for mange hyggelige og interessante samtaler. EVRY stilte og med en designkonsulent Alexandra Lo Cascio som kom med flere tips til applikasjonen og hvilke tanker vi burde ha når vi lagde det visuelle. Vi må også takke Marianne Haugland fra Sykehuset i Østfold for å ha samlet så mange sykepleiere for å teste applikasjonene den 11. april. Her fikk vi mange gode tilbakemeldinger om hva som kunne forbedres. Takk for at vi fikk besøke dere. Simen Hasselknippe har vært den perfekte veileder i dette prosjektet. Han har hjulpet oss masse med gjennomføringsprosessen, forskjellige teknologier og dokumentasjonsprosessen. Han har vært helt enestående. Når vi har strevd med en bagatell har han alltid vært tilgjengelig til å hjelpe og svare på spørsmål. Tusen takk Simen. 1.1 OM GRUPPEN Prosjektgruppen består av studenter fra Dataingeniørstudiet som har jobbet sammen tidligere på ulike prosjekter under studieløpet ved Høgskolen i Oslo og Akershus. Gruppemedlemmene har en del felles interesser, men samtidig et spredt kunnskapsområde som gjør oss gode på forskjellige fagområder. 1.2 PROBLEMSTILLING Følgende problemstilling ble formulert i samarbeid med EVRY: Hvordan gjøre hverdagen til en sykepleier enklere. Med tanke på MEWS registrering. Modified Early Warning Score(MEWS) kan leses mer om i Produktrapporten kap Sammendrag

11 1.3 BAKGRUNN FOR PROSJEKTET Samfunnet blir mer og mer digitalisert og Sykehuset i Østfold er ikke et unntak. I dag må sykepleiere notere verdier på papirer og senere legge det inn på datamaskin, i dette tilfellet MetaVision. Dette gjør at sykepleiere må bruke lang tid på å fylle inn disse verdiene etter deres ordinære arbeidsrutiner. Etter at Nino Lo Cascio introduserte oss for oppgaven om å lage et program, som ennå ikke eksisterte, var vi interessert. Tanken på å lage noe som senere kan bli brukt i offentlig sektor var inspirerende. Problemene vi måtte løse var: Hvordan gi sykepleier informasjonen han/hun trenger ved sengepost Hvordan presentere data som legges inn i sykehuset sine systemer. Hvordan skal man kommunisere med MetaVision EVRY har hatt en tanke om å kunne selge dette til flere sykehus, men det krever at det har litt mer funksjonalitet. Det betyr at vi i utgangspunktet ikke lager et ferdig program men noe som kanskje blir videreutviklet senere. 1.4 PRODUKT Sykehuset i Østfold har valgt Windows 8 som plattform for sine systemer. Vi valgte derfor å lage en Windows 8 applikasjon som fungerer både på Windows 8.1 tablet og pc, og en Android applikasjon. Systemet bygger på rammeverkene til Windows 8.1 (WinRT/.NET), SignalR, JSON, OWIN, NLog, Moq og Android. Rammeverkene er beskrevet i Prosessrapporten - 8. Vurdering av Teknologi. er et system laget for å gjøre MEWS-registrering lettere for sykepleiere og leger. MEWS er en skåringsalgoritme for å få et overblikk over pasientens tilstand. Les mer om MEWS i Produktrapporten Modified Early Warning Score - MEWS 11 Sammendrag

12 Figur 1.1 Systemoversikt Serveren sin kommunikasjon bygger på rammeverket SignalR som utvikles av Microsoft. SignalR klient API-et har støtte for JavaScript, C# og Java. Det gjør at vi i teorien kan koble til hvilken som helst plattform til serveren. SignalR tar i bruk forskjellige teknologier, bla. Websockets og long polling for å kunne kommunisere med de forskjellige klientene, server vil automatisk velge beste tilkoblingsmetode. Serverens funksjonalitet er kun å kommunisere med et databasesystem og levere en live tjeneste mellom server og klient. Når man sender data til databasesystemet, gjennom server, vil server samtidig levere oppdatering til de andre klientene som er koblet til server. Men kun til de klientene som abonnerer på de verdiene som blir sendt. Dvs. en klient som ikke abonnerer på informasjon om pasient-1 vil ikke få informasjon om pasient-1. På denne måten vil man fjerne unødvendig trafikk på nettverket. Brukergrensesnittet på klienten er bygd opp slik at de viktige oppgavene kan bli utført med maks tre trykk. Og all viktig informasjon vil man finne med maks to trykk. Man har prøvd å legge inn nok luft mellom tekst og figurer slik at det er lett å lese når man kaster blikket over på applikasjonen. For hver avdeling har man et kakediagram som viser fordelingen av MEWS på den avdelingen, dette blir gjort av OxyPlot. OxyPlot er et open source prosjekt med MIT lisens. Kakediagrammet gir sykepleierne rask oversikt over hvordan situasjonen på avdelingen er. Tilsvarende har man også grafer i pasient-siden som viser MEWS over tid og en graf som viser de forskjellige verdienes progresjon over tid. Uten disse grafene må man bla gjennom potensielt mange mews registreringer for å få et overblikk. Grafene gjør dermed at sykepleier får et raskt overblikk. Grafene kan også zoomes på, enten med musehjulet eller med to fingre på berøringsskjerm. Dette gjør det lettere å se verdiene over en kortere periode. 12 Sammendrag

13 Når MEWS skal vises, så regnes skåringen ut av klienten, den er aldri lagret i noen database. Det gjør at om utregningen av MEWS skulle bli endret så vil alle pasienter få oppdatert MEWS verdi når de kjører oppdatert klient PROSESS Utviklingsprosessen av startet 1. okt med et møte hos EVRY. Siden Tore jobbet hos EVRY ble det tidlig bestemt at vi ville skrive bacheloroppgave hos dem. Vi hadde til da kun muntlig kontakt med EVRY. I møte diskuterte vi hvordan mulighetene var for å skrive bacheloroppgave hos EVRY, og om mulige oppgaver. Vi fikk tre oppgaver fra EVRY og fikk tilbud om å lage vår egen oppgave om vi hadde noe som vi brant for. Dette førte til at gruppen samlet seg og diskuterte de ulike alternativene. Oppgaven som vi mente skilte seg ut på en svært positiv måte var å lage en applikasjon som skulle gjøre registrering av verdier til MetaVision enklere. MetaVision er meget omfattende og innholdsrikt, og kan dermed være vanskelig å bruke (se Produktrapport MetaVision). I starten av prosjektet la vi opp en overordnet plan ved hjelp av vår veileder Simen Hasselknippe. Vi fulgte utviklingsmetodikken Scrum (se Produktrapport Scrum). Under bruken av scrum skulle vi operere med sprinter på to uker som resulterte i et ferdig produkt til overlevering en måned før prosjektslutt. Figuren nedenfor gir oversikt over de forskjellige fasene i prosjektet. Figur 1.2 Fremdriftsplan for prosjektet. 13 Sammendrag

14 Under hele prosessen har veilederen og representanter fra EVRY vært tilgjengelig når vi har støtt på utfordringer. De kom med forslag til ulike verktøy som bidro med å gjøre produktet mer robust. Dette førte til at vi unngikk en del tidkrevende testing av verktøy for å finne gode løsninger til systemet. Midt i utviklingsperioden fikk vi beskjed fra EVRY og imdsoft at vi ikke fikk tilgang til MetaVision. Dette gjorde at vi måtte endre systemet den 12. mars. Se Prosessrapporten for mer informasjon om dette. EVRY var klar på at de ikke forventet et ferdig produkt med alle ønskelige funksjoner implementert. Det de ønsket i første omgang var en prototyp slik at de kunne videreutvikle på den ideen vi kom med. De tilbakemeldingene vi fikk fra EVRY underveis har vært meget positive og de er godt fornøyd med sluttproduktet. EVRY mener det vi har utviklet er noe de har fått gode muligheter til å videreutvikle. Etter endt prosjektperiode har vi et produkt som har løst utfordringene med registrering av MEWS for sykepleiere. Produktet er brukervennlig og meget intuitivt i forhold til MetaVision. I løpet av prosjektperioden har vi fått verdifull erfaring med alle fasene i et prosjekt. Fra å forholde seg til en oppdragsgiver og kartlegge deres behov, til gjennomføring og dokumentasjon av prosjektet. Det å følge et produkt fra start til slutt, i et større prosjekt, har vært meget nyttig for vår læring. Dyktig veileder har også gjort hovedoppgaven til en meget positiv opplevelse. 14 Sammendrag

15 Høgskolen i Oslo og Akershus, våren 2014 Dokument 2 - Produktrapport 15

16 1. FORORD Denne rapporten er prosjektets produktdokumentasjon som redegjør for systemets oppbygning, funksjonalitet, tekniske detaljer og videreutvikling. Rapporten er beregnet for sensor, veileder, arbeidsgiver og eventuelle utviklere som skal bruke eller videreutvikling systemet, men kan også leses av andre interessenter. Det forutsettes at leseren har datatekniske kunnskaper. 2. INNHOLDSFORTEGNELSE 1. Forord Innholdsfortegnelse Rammekrav Krav til løsningen Teknologi Systembetingelser Server Windows 8 applikasjon Android Økonomi Domene Sykehuset i Østfold MetaVision Elektronisk Pasient Journal(EPJ) Modified Early Warning Score - MEWS Dagens Rutiner Beskrivelse av programmet Sentrale funksjoner Logge inn/ut Oversikt over alle pasienter

17 5.3 Oversikt over en avdeling Oversikt over en bestemt pasient Oversikt over MEWS-historikk Oversikt over vitale verdier og historikk Registrere MEWS Live oppdatering Brukergrensesnitt Windows Android Definere xml layout ListActivity Teknisk arkitektur Server arkitektur Library Server/API Layer Business Logic Layer - BLL Data Access Layer - DAL Error håndtering / logging Windows 8.1 arkitektur Model View ViewModel - MVVM Binding Oxyplot Android arkitektur Activities Services Content providers Broadcast receivers Manifest Andorid Klient

18 8 Videreutvikling Klient utvikling Flere scorings algoritmer Medisinering av pasienter Loggføring av væskeinntak og uttak Tavlemøte Støtte av flere språk Server utvikling Verifisering og testing Enhetstesting Bruk av Moq Bruk at Stub Brukertesting Systemtesting Akseptansetest Metode og planlegging Scrum Parprogrammering Utviklingsmiljø og språk

19 3. RAMMEKRAV Dette kapittelet beskriver hvilke avgrensninger som er gjort for prosjektet, hvilke krav må oppfylle, hvilke teknologier som er benyttet samt prosjektets økonomiske forutsetninger. 3.1 KRAV TIL LØSNINGEN Her vises en liste av de viktigste funksjonen må ha, de gir essensen av hva burde gjøre. For en komplett kravspesifikasjon se Vedlegg B. En bruker skal kunne logge inn. Systemet skal vise en liste over pasienter i systemet. Systemet skal kunne velge en pasient og få deres opplysninger. Systemet skal kunne vise en pasient sin puls. Systemet skal kunne vise en pasient sitt blodtrykk. Systemet skal kunne vise en pasient sin pustefrekvens. Systemet skal kunne vise en pasient sin kroppstemperatur. Systemet skal kunne vise en pasient sitt nivå av bevissthet Systemet skal kunne vise en pasient sin MEWS. Systemet skal kunne legge til verdier for pasientens blodtrykk. Systemet skal kunne legge til verdier for pasientens pustefrekvens. Systemet skal kunne legge til verdier for pasientens kroppstemperatur. Systemet skal kunne legge til verdier for pasientens nivå av bevissthet. Det skal ikke være mer enn 3 klikk for å gjøre enkle oppgaver. Ikoner og bilder i applikasjonen skal gi mening. Applikasjonen skal følge Windows 8 sitt brukermønster og krav. Skal følge Microsoft design Guidelines. 19

20 3.2 TEKNOLOGI Evry hadde krav noen få krav til teknologien som skulle brukes før utviklingen av startet. Applikasjonen skal utvikles i C# og XAML(Utviklere) Applikasjonen skal kjøres på Windows 8.1(Evry) Applikasjonen skal kunne kjøres på Windows Nettbrett og pc. (Evry) 3.3 SYSTEMBETINGELSER SERVER For at server skal kunne fungere må den være utstyrt med Windows, med.net framework Nettverkstilgang og port 8080 må være åpen WINDOWS 8 APPLIKASJON For at applikasjonen skal fungere må det kjøres på (operativsystem) Windows ANDROID Android klient versjon 1.0 krever Android SDK 12 (Honeycomb 3.1) eller høyere for å kunne kjøres. 3.4 ØKONOMI Det er ikke satt opp noen form for økonomisk budsjett for utvikling av ettersom dette i utgangspunktet er et Bachelorprosjekt for studenter. Evry har bidratt med kompetanse og en Windows tablet til bruk for testing og fremvisning. 4. DOMENE er et system som skal brukes innenfor helsesektoren. Dette kapittelet er ment å gi innblikk i de begrepene og domenene berører innenfor Helsesektoren. 4.1 SYKEHUSET I ØSTFOLD Nå bygges det nytt sykehus i Østfold for å erstatte det gamle sykehuset, dette skal stå klart i Dette sykehuset kommer til å ta i bruk det nyeste av IT løsninger som finnes på markedet. De bruker nå EPJ (Elektronisk Pasient Journal) -systemet 20

21 MetaVision versjon i det gamle sykehuset, men vil bytte til MetaVision 6.0 når det nye sykehuset er ferdigstilt. Dette er et tungt klinisk program som går på stasjonære datamaskiner METAVISION MetaVision er et Elektronisk Pasient Journal(EPJ) system som er utviklet av imdsoft som er basert i Israel. Det er nå i bruk på flere norsk sykehus. Dette er et meget omfattende og innholdsrikt system, som kan være vanskelig å bruke for sporadiske brukere eller i spesifikke, gjerne mobile, kontekster. Figur 2.1. MetaVision v skjermbilde ELEKTRONISK PASIENT JOURNAL(EPJ) Ut fra helsepersonelloven og pasientjournalforskrifter får man en følgende definisjon av hva et EPJ er: En elektronisk ført samling eller sammenstilling av nedtegnede/registrerte opplysninger om en pasient i forbindelse med helsehjelp. Pasientjournalen skal inneholde relevante og nødvendige opplysninger om pasienten og helsehjelpen, samt de opplysninger som er nødvendige for å oppfylle meldeplikt eller opplysningsplikt fastsatt av lov eller i medhold av lov. I helse Norge er hvert legesenter/legekontor/sykehus sin egen juridiske enhet, derfor vil ikke de forskjellige virksomhetene kunne dele pasientjournaler. 21

22 4.2 MODIFIED EARLY WARNING SCORE - MEWS Modified Early Warning Score (MEWS) er en skåringsalgoritme for å hurtig få innblikk i pasientens tilstand. MEWS består av fem vitale parametere hos hver enkelt pasient; Respirasjonsfrekvens (antall innåndinger per minutt), puls, systolisk blodtrykk (blodtrykket under hjertets sammentrekningsfase, tallet som står først i en vanlig blodtrykksmåling), temperatur og CNS (pasientens mentale tilstand). Hver parameter gir et tall fra 0-3 som blir summert sammen for å beregne en endelig MEWS (se Figur 2.2). Figur 2.2. MEWS-verdier Figur 2.2. viser hvilke parameterintervaller som gir hvilken skåring. Der grønn sone er normalt og blir dårligere jo nærmere rødt man kommer. En MEWS med respirasjonsfrekvens lik 10, puls lik 87, systolisk blodtrykk lik 90, temperatur lik 37.2 og CNS er Klar og orientert gir en MEWS lik 1. En MEWS på 0 betyr at man skal ta en ny måling om et døgn. MEWS lik 1 gir 8-12 timer, 2 gir 4-8 timer og 3 til 4 gir 1-4 timer, eventuelt kontakte lege. Er MEWS over 4 skal seksjonens lege kontaktes. En lav MEWS betyr ikke at pasienten er frisk, pasienten kan fremdeles ha en alvorlig sykdom. MEWS skal kun føres på voksne mennesker. På barn brukes PEWS som er likt som MEWS, men da kun med andre verdisoner. fokuserer kun på MEWS. 4.3 DAGENS RUTINER Idag skal det registreres MEWS på alle pasienter. Dette blir gjort med et eget skjema, se vedlegg J - MEWS skjema, og skal skje når pasienten ankommer avdelingen, ved forverring og ved uro for pasientens tilstand. Her må lege/sykepleier føre inn verdier og selv beregne MEWS. Vanlig praksis er å gå rundt til alle pasienter og føre MEWS. Deretter må dette føres inn manuelt til systemene sykehuset har. Et slikt system kan være DIPS, MetaVision eller et annet system. 22

23 Med dagens rutiner er det flere muligheter for innføring av feilinformasjon til bakenforliggende systemer. Dette kan skje ved at lege/sykepleier regner feil MEWS, glemmer skåringen, mister eventuell lapp der verdier står, eller glemmer å føre MEWS til sykehusets systemer. Det er også tidkrevende å bruke dagens løsning. 4.4 BESKRIVELSE AV PROGRAMMET tar sikte på å gjøre MEWS- registrering hurtigere, enklere og mer sikkert. Den skal gi leger og sykepleiere oversikt over pasient eller avdeling basert på MEWS, samt abstrahere vekk tunge og innviklede systemer slik som MetaVision (se MetaVision). 5 SENTRALE FUNKSJONER sitt hovedformål er å gjøre hverdagen lettere for sykepleiere. Dette gjøres ved å gi lettere tilgang til pasientlister og deres MEWS over tid. Uansett hvilket system sykehusene bruker, skal applikasjonen for å lese og registrere MEWS være lik. 5.1 LOGGE INN/UT Inn- og utlogging er en viktig funksjon for å få kontakt med sykehusets systemer. Det første skjermbilde som vises på Android Klient og Windows Klient er en innloggingsskjerm. Her må brukeren logge inn med det brukernavnet og passordet han/hun har til sykehusets systemer. vil logge brukeren inn i bakenforliggende systemer om dette kreves. Deretter vil brukeren få tilgang til resten av sine funksjoner. I versjon 1.0 på Android Klient og versjon 1.0 på Windows klient må brukeren selv koble seg til Server før innlogging. Hvordan dette gjøres blir forklart i brukerveiledningen (se vedlegg A- Brukerveiledning). 5.2 OVERSIKT OVER ALLE PASIENTER Etter at en bruker er logget inn i får han/hun en liste over alle pasienter brukeren har lov til å se. Det er sykehusets system som bestemmer hvilke pasienter han/hun har tilgang til å se. Skjermbildet (figur 2.3) gir brukeren oversikt over fullt navn, sengenummer, kjønn, diagnose og MEWS til hver pasient samt hvilken avdeling de ligger på. 23

24 5.3 OVERSIKT OVER EN AVDELING Figur 2.3. Viser Pasientlisten til Windows klienten. Bruker har mulighet til å fokusere på en gitt avdeling. Da vil brukeren få oversikt over alle pasienter som ligger på valgt avdeling, samt et kakediagram som viser fordeling av MEWS på alle pasienter på avdelingen. Dette gir brukeren en kjapp oversikt over situasjonen på avdelingen. 5.4 OVERSIKT OVER EN BESTEMT PASIENT Ved å trykke på en pasient får brukeren spesifikk informasjon om gitt pasient. Dette inkluderer fornavn, etternavn, fødselsnummer, kjønn, sengenummer, ankomstdato og diagnose. Her har bruker også mulighet til å se detaljert informasjon om MEWS, vitale verdier og registrere en ny MEWS OVERSIKT OVER MEWS-HISTORIKK. I skjermbildet som viser informasjon om pasient ligger det en liste som viser alle MEWSregistreringer. Disse er fargekodet slik at det er enkelt å se hvilke verdier som ligger utenfor normalen. Det er også en graf (kalt Mews ) som viser oversikt over alle MEWS som er registrert på pasienten OVERSIKT OVER VITALE VERDIER OG HISTORIKK I tillegg til MEWS graf er det også en graf som viser temperatur, respirasjonsfrekvens, puls og systolisk blodtrykk over tid. Denne grafen er kalt Vitale verdier og gir brukeren en oversikt over hvilke parametere som varierer. 24

25 5.4.3 REGISTRERE MEWS Det er også mulighet for å registrere en ny MEWS på en pasient. Brukeren vil få opp et skjema der han/hun blir bedt om å fylle inn de gitte parameterne for å registrere en MEWS. Her blir det gitt tilbakemeldinger dersom brukeren prøver å registrere ulovlige eller manglende verdisett. 5.5 LIVE OPPDATERING Når en registrering av en MEWS blir sendt til en server, vil serveren oppdatere alle klienter som har denne pasienten i sin liste. Er brukeren inne på en pasient som har fått en registrert ny MEWS vil brukeren få en pop-up melding som forklarer at pasienten har fått en ny MEWS registrert, og alle grafer vil bli oppdatert. 6 BRUKERGRENSESNITT I dette kapittelet forklares brukergrensesnittet til Windows- og Android klienten samt forskjellige designprinsipper og -mønstre applikasjonene følger. For å se hvordan applikasjonene ser ut se Vedlegg C - Skisser og Skjermbilder. 6.1 WINDOWS Designet følger Microsoft design language, tidligere kalt Metro, som ble introdusert til Windows Media Center og Zune. Det har vært brukt som bakgrunn for flere av Microsofts produkter som Xbox 360 system software, Windows 8 start meny (se Figur 2.4), Windows Phone og flere. 25

26 Figur 2.4. Windows 8 start meny Prinsippet i dette designen er basert på King Country Metro transitt system, som er transportsystemet rundt Seattle hvor hovedkvarteret til Microsoft ligger. Designet skal være med stor skrift som fanger øyet kjapt. Microsoft ser på denne designmåten som Elegant, kjapp og moderne. Microsoft utformet designmåten spesielt for å samle grupper av vanlige oppgaver for å framskynde bruken. Det oppnås ved å utelukke overflødig grafikk og i stedet stole på at det faktiske innholdet fungerer som den viktigste UI(User Interface). Det resulterende grensesnittet favoriserer større grupper, over mindre knapper og har ofte mulighet for horisontal scrolling. Sidetitler er vanligvis store og kan dermed også dra nytte av horisontal scrolling. 6.2 ANDROID Androidklient følger Androids standarder (se og bruker kun Android-definerte GUI-objekter. Applikasjonen består av tre hovedvindu som blir definert i XML med Android sitt navnerom. Designet baserer seg på 3-klikk design, som betyr at brukeren ikke skal bruke mer enn tre klikk for å utføre en oppgave. Når bruker har logget inn, kan han/hun utføre alle funksjoner i applikasjonen ved hjelp av tre klikk (her regnes ikke føring av verdier). Designet prøver også å gi brukeren så få valg som mulig for at brukervennligheten skal være høy og opplæringstid minimal. Figur 2.5. viser de tre hovedskjermbildene i Androidklienten. 26

27 Figur 2.5. viser tre skjermbilder fra Android klienten DEFINERE XML LAYOUT Hver Activity i Android må ha ett eller flere Layout knyttet til seg. Det er Layout-filen som definerer det grafiske brukergrensesnittet til applikasjonen. Denne filen blir skrevet i XML. <RelativeLayout xmlns:android=" xmlns:tools=" android:layout_width="match_parent" android:layout_height="match_parent" <!-- Defines the rest of this element--> > <ImageView android:id="@+id/view_logo" <!--Defines the rest of this element --> android:src="@drawable/logo" /> <EditText android:id="@+id/etusername" <!--Defines the rest of this element--> > </EditText> </RelativeLayout> Figur 2.6. Utdrag fra fragment_login.xml 27

28 Figur 2.6. viser hvordan layout-filen til Login er definert. Dette er en trestruktur med RelativeLayout som hovedelement, som er et objekt definert av Android. De to første linjene sier at dette XML-dokumentet bruker et navnerom definert av Android (xmlns er XML Name Space). Videre defineres GUI-objekter som TextView og Button. Flere IDE er (Integrated Development Environment) slik som Eclipse gir utvikleren mulighet til å definere brukergrensesnittet uten å skrive XML-kode, men ved hjelp av draog-slipp-elementer i en egen designer. Designeren gir utvikler god oversikt over hvordan skjermbildet vil se ut og minsker utviklingstiden. Se figur 2.7 for å se hvordan Eclipse sin designer ser ut. Figur 2.7 viser Designer verktøyet til Eclipse LISTACTIVITY Android Klienten bruker en ListActivity for å vise alle pasienter. Dette er en egen klasse for å vise lister i Android. Her defineres hvordan hvert element i listen skal se ut, for så å legges i en liste. Dette gir applikasjonen likt bruksmønster som andre Android applikasjoner og følger dermed prinsipper i Universell-utforming. Se bilde nummer 2 fra venstre i Figur

29 7 TEKNISK ARKITEKTUR er ment som å være en data aggregator (et system som henter data fra databasesystemer og selger informasjon videre) som uavhengig av bakenforliggende systemer skal kunne gi sykepleiere og leger lettere tilgang til MEWS. skal også kunne levere og motta data til klient uavhengig av operativsystem. Det er også utviklet en Windows 8.1 klient og en Android klient som bruker Server. Figur 2.8 System arkitektur Figur 2.8 viser en oversikt over systemet. server henter og skriver data til en database eller et bakenforliggende system og tilbyr så et tjeneste-api via SignalR (se 7.1.2) 29

30 7.1 SERVERARKITEKTUR Serveren er lagdelt i tre lag, API-lager, BLL, DAL. Denne lagdelingen gjør slik at API laget ikke trenger å vite hvilket system den henter data fra. Ved installasjon av server skal det defineres hvilket Data Access Layer (DAL) som skal brukes. I versjon 1.0 trengs ikke dette ettersom det kun finnes en DAL-klasse(Connection) som aksesserer en testdatabase. Skal produktet utvides til å bruke systemer som MetaVision og lignende må det skrives egne klasser som håndterer lesing og skriving til disse systemene, se for mer informasjon. Figur 2.9 Serverarkitektur 30

31 7.1.1 METAVIEW LIBRARY Library er et lite bibliotek som definerer tre klasser, User, Patient og MewsData. Det er disse objektene som blir sendt frem og tilbake mellom server og klient. Figur 2.10 Klassediagram for Library SERVER/API LAYER For å kommunisere mellom server og klient bruker API-laget SignalR. SignalR er et asynkront web-api som bygger på websockets og andre kommunikasjonsteknologier. SignalR tar i bruk allerede eksisterende teknologier slik at utvikleren kan bruke mer tid på funksjonalitet og mindre tid på hvordan kommunisere med klientene. På serveren lages Hub klasser, disse klassene definerer metoder som klienten kan si til server at den skal utføre. Server kan på samme måte kommunisere tilbake til klienten. For at dette skal fungere må klienten, helst før forbindelsen er opprettet, definere metodene server kan kalle på. Nedenfor vises en kommando som kaller på login-metoden i userhub. await ServerConnection.userHub.Invoke("login", brukernavn.text, passord.password); 31

32 ServerConnection er en static klasse som holder på tilkoblingen til server, i den blir hubtilkoblingene definert. Invoke-metoden i userhub sender parametere til server, første parameter er en streng som sier hvilken metode skal kjøres hos server, og etter det sendes parameterne til metoden. await betyr at metoden starter en annen tråd, og at den opprinnelige tråden må vente til den andre tråden har stoppet. 32

33 namespace.server.signalr { [HubName("UserHub")] public class UserHub : Hub { /* Constructor and variables */ /// <summary> public Task login(string username, string password) { /* Logs the client call*/. try { //Get user from server User user = userbll.login(username, password); //If illegal login, shows error message on client. Clients.Caller.showErrorMessage("Wrong username or password!"); //Defines a variable usable by both the client and server Clients.Caller.user = user; return Clients.Caller.receiveLogin(user); } catch (Exception e) { /* Logs exception and shows error message on client */ } } /* More methods */ } } Figur 2.11, utdrag fra userhub klassen. 33

34 I Figur 2.11 viser login-metoden klienten kaller hos serveren i UserHub klassen. Denne metoden vil hente data fra backend og returnere et User-objekt som er definert i.model.library. Både klient og server har kjennskap til dette objektet og server kan dermed sende dette objektet tilbake til klienten. Dette gjør den ved å kalle på Clients.Caller.receiveLogin(user). Denne metoden kjører på tilsvarende måte, som klienten gjorde mot server, en metode hos klienten. //receive login from server userhubreceivelogin = ServerConnection.userHub.On<User>("receiveLogin", user => { Context.Post(delegate { this.frame.navigate(typeof(groupeditemspage)); }); }, null); Figur 2.12, metode server kan kjøre hos klient. Figur 2.12 viser metoden som server kjører hos klienten når den vil sende brukeren til klienten. Her blir ikke user-objektet brukt. Siden det er definert et user-objekt som kan brukes av både klient og server er denne datatrafikken unødvendig. Når klienten senere kjører metoder hos serveren vil serveren kunne sjekke om bruker er autentisert og autorisert med Clients.Caller.user-objektet. Ved å bruke disse teknikkene kan man kommunisere asynkront og sende forskjellige typer data over nettet, opplevelsen vil være rask og det er like lett å koble til server som det er for server å koble til klient SIKKERHET I SIGNALR Sikker kommunikasjon er en viktig faktor når det gjelder sensitive data. SignalR bruker websockets og andre verktøy for nettverkskommunikasjons, som alle er basert på HTTP kommunikasjon over en port. Dette betyr at SignalR kan benytte seg av HTTPs som tilsvarer http med TLS/SSL. 34

35 For å få dette til å fungere bruker man et sertifikat og binder det til porten SignalR kjører på. I vårt tilfelle er det port Det å opprette sikker kommunikasjon er helt uavhengig av programvaren, det blir dermed ikke gått videre inn på hvordan dette konfigureres BUSINESS LOGIC LAYER - BLL Dette laget kan også kalles en Fasade og består av to klasser; UserBLL og PatientBLL. Det finnes lite logikk i dette laget i Versjon 1.0, BLL sitt eneste ansvar er å abstrahere bort DAL laget, derfor fungerer det som en Fasade. UserBLL håndterer oppgaver knyttet til User objektet som er å logge inn, bytte passord og sjekke at brukeren er logget inn eller finnes i det bakenforliggende systemet. PatientBLL håndterer oppgaver knyttet til Patient objektet som er å hente pasienter, hente MEWS-registreringer og registrere MEWS. I versjon 1.0 er konstruktøren til PatientBLL og UserBLL enkel. De oppretter kun et MetaVisionInterface av typen Connection. For videreutvikling av er det viktig å definere hvilket system skal koble seg til i dette laget. public class PatientBLL { private MetaVisionInterface mvinterface; /// <summary> /// Creates a connection to a MetaVision interface. Use this object to handel /// patient objects, and MEWS-objectes. /// </summary> public PatientBLL() { // Should read from Configfile to find the proper DAL-class to create // Atm there is only one DAL-Class, so we do it simple. mvinterface = new Connection(); } Figur 2.13 Konstruktør for patientbll 35

36 7.1.4 DATA ACCESS LAYER - DAL DAL har som oppgave å opprettholde en tilkobling til bakenforliggende systemer, samt skrive og hente data. I dette laget blir objekter fra Library opprettet og sendt videre. Her defineres et Interface kalt MetaVisionInterface (må ikke forveksles med MetaVision fra imdsoft). Dette må implementeres i alle klasser som skal snakke med systemer bak. Figur 2.14 viser MetaVisionInterface med de metodene som må implementeres. Figur 2.14 MetaVisionInterface I versjon 1.0 finnes kun Connection som implementerer MetaVisionInterface. Som tidligere forklart oppretter Connection en tilkobling med en testdatabase som ligger på server. Her vises en implementing av metoden getpatientlist (User user) i Connection. 36

37 public List<Patient> getpatientlist(user user) { // Should only get the patients user has access to. TODO if (user == null) return null; try { // Gets the list of patients var temp = db.patients.tolist(); List<Patient> patients = new List<Patient>(); // Converts the data to.library objects foreach (PatientModel p in temp) { var patient = new Patient(p.patientID,...); patient.mews = new List<MewsData>(); // Only adds the last mews to the patient var m = getlatestmews(user, patient); if(m!= null) patient.mews.add(m); patients.add(patient); } return patients; } catch (Exception e) { // Handels errors, logs them and thorws the error to the caller. throw e; } } Figur 2.15 Kode eksempel fra getpatientlist(user user) i Connection. 37

38 7.1.5 FEILHÅNDTERING / LOGGING Alle handlinger som skjer på server skal loggføres, staten krever at helsevesenet skal loggføre alle handlinger og oppslag av pasientinformasjon. Derfor har utviklerne benyttet seg av NLog. NLog er open source og er tilgjengelig gjennom NuGet i Visual Studio. NLog er lisensiert med BSD lisens som betyr at man får lov til å benytte seg av programvaren som den er så lenge man legger med lisensen der lisenser vises. Nedenfor er et utklipp av NLog.config hvor man konfigurerer NLog. <?xml version="1.0" encoding="utf-8"?> <nlog xmlns=" xmlns:xsi=" <targets> <target name="userlog" xsi:type="file" filename="nlog/userlog/${shortdate}.txt" /> //Other target loggers! </targets> <rules> <logger name=".server.signalr.userhub" minlevel="trace" writeto="userlog" final="true" /> //Other loggers <logger name="*" minlevel="info" writeto="other" /> </rules> </nlog> Figur 2.16 Utsnitt fra NLog.config I targets delen så definerer man hvor loggeren skal skrive til, her kan man også konfigurere logging mot database og sending av logg via mail. I har utviklerne valgt det enkleste, å skrive til fil. I Figur 2.16 under i rules definerer man loggere, og hvor de skal loggføre til. Navn feltet definerer hvilke klasser som skal bruke denne loggeren. Name= * betyr at denne 38

39 loggeren vil loggføre alle logger som kommer til den i listen. Hver logg starter øverst i listen og vil gå til den første loggeren som har name lik sitt klasse navn. Minlevel definerer laveste nivå av logging, det vil si skal man loggføre Trace så vil ikke logger med name= * loggføre hendelsen da minlevel= Info, info er mer kritisk enn trace. I rekkefølge er logg nivåene fra minst kritisk til mest kritisk: Trace, Debug, Info, Warn, Error, Fatal. WriteTo variabelen forteller hvilket target loggen skal skrives til. Final gjør at logging vil stoppe etter at denne loggeren har gjort oppgaven. Hvis final= false vil flere loggere kunne loggføre hendelsen. Dette gjør at man enkelt kan loggføre til fil på mindre hendelser og ved mer kritiske hendelser kan man sende mail. Nedenfor er det et eksempel på en logghendelse, når en klient kobler seg til sever. /// <summary> /// Metod called first time connecting to hub. /// </summary> /// <returns></returns> public override Task OnConnected() { Console.WriteLine("Someone is Connected to userhub: " + Context.ConnectionId); logger.info("#onconnected" + " #invoked" + " #Connection id: " + Context.ConnectionId ); } return base.onconnected(); Figur 2.17, OnConnected metoden på server. Denne metoden kjøres hver gang en klient kobler seg til server. Her logges det at en klient med unik ConnectionId er koblet til. logger.info( Feilmelding ) sier at dette er en Info logging og vil dermed ikke bli logget av loggere som har minlevel= Warn eller høyere. 39

40 7.2 WINDOWS 8.1 ARKITEKTUR. I dette kapittelet gjennomgås hvordan Windows 8.1 arkitektur skal være og noe hvordan det har blitt brukt i applikasjonen. Det gjennomgås MVVM, bindings og OxyPlot MODEL VIEW VIEWMODEL - MVVM Model View ViewModel(MVVM) er et arkitektonisk mønster som brukes i programvareutvikling som stammer fra Microsoft som en spesialisering av Presentasjons Model designmønsteret introdusert av Martin Fowler. MVVM stammer fra Model-View- Controller mønsteret(mvc). MVVM er en spesifikk implementering rettet mot UI-utviklingsplattform som støtter eventdreven programmering i bl.a. Windows Presentation Foundation(WPF) og Silverlight på.net plattformer ved hjelp av XAML og.net språk. MVVM mønsteret forsøker å få begge fordelene med separasjon av funksjonell utvikling levert av MVC samt utnytte fordelene med databinding og rammeverket ved å binde data så langt bak som mulig mens du bruker binding, ViewModel og enhver businesslag datakontroll funksjon for å validere eventuelle innkommende data BINDING Data binding er en prosess som etablerer en kontakt mellom applikasjonens UI(User Interface) og modellen. Når man setter det opp korrekt vil dataene reflekteres når det skjer endringer, dette kan være både en 1 veis binding slik som grafene i applikasjonen er eller en 2 veis binding. Dersom dataene blir endret på ene siden, vil de også endres på andre siden, dette vil gå begge veier. Det lages grupper (Figur 2.18) av pasienter i en egen fil slik at det ikke vil tynge ned det det grafiske i appen. public class PatientItem { public string PatientId { get; private set; } public string FullName { get; private set; } public string Sex { get; private set; } public string BedId { get; private set; } public string SocialSecurity { get; private set; } public string MewsScore { get; set; } public string AdmitionReason { get; private set; } public PatientItem(String patientid, String fullname, String sex, String bed, String sosialsecurity, String mewsscore, String admitionreason) 40

41 { this.patientid = patientid; this.fullname = fullname; this.sex = sex; this.bedid = bed; this.socialsecurity = sosialsecurity; this.mewsscore = mewsscore; this.admitionreason = admitionreason; } public override string ToString() { return this.fullname; } } public class PatientGroup { public string UniqueId { get; private set; } public string Title { get; private set; } public ObservableCollection<PatientItem> Items { get; private set; } public PatientGroup(String uniqueid, String title) { this.uniqueid = uniqueid; this.title = title; this.items = new ObservableCollection<PatientItem>(); } internal void updatepie() { GroupDetailPage.updateGraph(Items); } public override string ToString() { 41

42 return this.title; } } Figur 2.18 Deklarasjon av pasient og gruppen pasientene tilhører. For å få kontakt med pasientene så deklareres det i C# filen som hører til Xaml filen(figur 2.19). public ObservableDictionary DefaultViewModel { } get { return this.defaultviewmodel; } private async void navigationhelper_loadstate(object sender, LoadStateEventArgs e) { var sampledatagroups = await SampleDataSource.GetGroupsAsync(); this.defaultviewmodel["groups"] = sampledatagroups; } Figur 2.19 Binding fra xaml siden sin C# side til C# filen hvor pasientene deklareres. I starten av Page taggen brukes datacontext (Figur 2.20) for å fortelle hvor dataene som skal inn i siden finnes. <Page x:name="pageroot" x:class="meteviewgrid.groupeditemspage" DataContext="{Binding DefaultViewModel, RelativeSource={RelativeSource Self}}" xmlns=" xmlns:x=" xmlns:local="using:meteviewgrid" xmlns:data="using:meteviewgrid.data" xmlns:common="using:meteviewgrid.common" 42

43 xmlns:d=" xmlns:mc=" mc:ignorable="d" NavigationCacheMode="Disabled"> Figur 2.20 Data binding i page. I Resources settes hvilke data det skal bindes mot. Her finnes også konverterer som konvertere kjønn eller mews til ikoner. <Page.Resources> <x:string x:key="chevronglyph"> </x:string> <local:genderconverter x:key="genderconverter" /> <local:mewsconverter x:key="mewsconverter" /> <CollectionViewSource x:name="groupeditemsviewsource" Source="{Binding Groups}" IsSourceGrouped="true" ItemsPath="Items" d:source="{binding Groups, Source={d:DesignData Source=/DataModel/SampleData.json, Type=data:SampleDataSource}}"/> </Page.Resources> Figur 2.21 Data binding i Resources til page. 43

44 I gridview.groupstyle sier bindingen hvordan grupperingene er og binder til tittel av gruppene (Figur 2.22). <GridView.GroupStyle> <GroupStyle> <GroupStyle.HeaderTemplate> <DataTemplate> <Grid Margin="0,0,0,2"> <Button Foreground="{ThemeResource ApplicationHeaderForegroundThemeBrush}" AutomationProperties.Name="Group Title" Click="Header_Click" Style="{StaticResource TextBlockButtonStyle}" > <StackPanel Orientation="Horizontal"> <TextBlock Text="{Binding Title}" Margin="0,-11,10,10" Style="{StaticResource SubheaderTextBlockStyle}" TextWrapping="NoWrap" /> <TextBlock Text="{StaticResource ChevronGlyph}" FontFamily="Segoe UI Symbol" Margin="0,-11,0,10" Style="{StaticResource SubheaderTextBlockStyle}" TextWrapping="NoWrap" /> </Grid> </StackPanel> </Button> </DataTemplate> </GroupStyle.HeaderTemplate> </GroupStyle> </GridView.GroupStyle> Figur 2.22 Gruppering av pasienter.. 44

45 I gridview er det itemtemplates som bindes til hver pasient og itemtemplates er en grid med flere children der det ligger textblocks (Figur 2.23) som har binding til hver pasient sine verdier. /*Patientname*/ <TextBlock Text="{Binding FullName}" /*Style config*/ /> /*Sex*/ <TextBlock Text="{Binding Sex, Converter={StaticResource GenderConverter}}" /*Style config*/ /> <TextBlock Text="{Binding MewsScore, Converter={StaticResource MewsConverter}}" /*Style config*/ /> Figur 2.23 Data binding i hver pasient boks OXYPLOT OxyPlot er et open source plottingsbibliotek som er lisensiert under MIT-lisens. Dette gjør at alle kan bruke OxyPlot fritt og endre hva man vil i koden. Biblioteket er basert på.net og er åpen for flere plattformer. Kjernebiblioteket er plattform-uavhengig, hvilket gjør det enkelt å bruke samme plotting kode på forskjellige.net plattformer. OxyPlot gir mulighet til å bruke XY-grafer, kartesiske grafer (samme skala som XY-graf), polar graf og pai graf. Se Figur 2.24 for å se hvordan en OxyPlot graf blir implementert. Se Figur 2.25 og 2.26 for å se hvordan OxyPlot blir knyttet opp mot et View. private void SetUpMewsModel() { PlotModel.Title = "Mews"; var xaxis = new DateTimeAxis(); /* Defines properties of xaxis */ PlotModel.Axes.Add(xAxis); var yaxis = new LinearAxis(); /* Defines properties of yaxis */ PlotModel.Axes.Add(yAxis); } MewsLine = new LineSeries(); /* Defines properties of MewsLine */ PlotModel.Series.Add(MewsLine); 45

46 private void updatemewsmodel(list<mewsdata> mewslist) { var line = (PlotModel.Series[0] as LineSeries); line.points.clear(); // Sets the maximum x axis to now. PlotModel.DefaultXAxis.AbsoluteMaximum = DateTimeAxis.ToDouble(DateTime.Now); // Sets the minimum x axis to 6 houers after the first MEWS registration var date = mewslist.first().registrationdate; var d = new DateTime(date.Year, date.month, date.day, date.hour-6, 0, 0); PlotModel.DefaultXAxis.AbsoluteMinimum = DateTimeAxis.ToDouble(d); } // Plots all the Mews registration to the graph foreach (MewsData mews in mewslist) { var mewsscore = mews.getmewsscore(); if (mewsscore > line.yaxis.maximum) line.yaxis.maximum = mewsscore + 0.5; line.points.add(new DataPoint(DateTimeAxis.ToDouble(mews.registrationDate), mewsscore)); } Figur 2.24 Viser hvordan Mewsgrafen er implementert. <!-- Adds the Plotmodel to the view <Grid> <!-- Code for the view --> <oxy:plot x:name="plotmews" Model="{Binding PlotModel}" Background="{StaticResource ItemBackgroundColor}"/> <!-- More view code --> </Grid> public MewsGraph mewsgraph; public MewsGraph valuegraph; /* */ Figur 2.25 Viser hvordan MewsGraph blir knyttet til et View 46

47 public ItemDetailPage() { // Creats the graphs mewsgraph = new MewsGraph(GRAPH_TYPE.MEWS); valuegraph = new MewsGraph(GRAPH_TYPE.VITAL_VALUE); } /* */ this.initializecomponent(); this.navigationhelper = new NavigationHelper(this); this.navigationhelper.loadstate += navigationhelper_loadstate; async protected override void OnNavigatedTo(NavigationEventArgs e) { } navigationhelper.onnavigatedto(e); // Sets the datacontext the the graphs PlotMews.DataContext = mewsgraph; PlotValues.DataContext = valuegraph; /* */ // Updates the graphs private void updategraphs(list<mewsdata> mewslist) { } if (mewslist!= null && mewslist.count() > 0) { mewsgraph.updatemodel(mewslist); valuegraph.updatemodel(mewslist); } // Redraws the graphs PlotMews.InvalidatePlot(true); PlotValues.InvalidatePlot(true); Figur 2.26 Viser hvordan koden bak viewet setter opp grafer og oppdaterer grafen. 47

48 7.3 ANDROID ARKITEKTUR En Android-applikasjon er bygd opp av fire komponenter; Activities, Services, Content providers og Broadcast receivers. Disse komponentene er byggesteinene i applikasjonen og hver komponent har et spesifikt bruksområde og livssyklus. I tillegg til dette har alle Android applikasjoner en Manifest - fil som deklarerer applikasjonens komponenter, rettigheter med mer. Figur 2.27 viser hvordan livssyklusen til en Android Activity er håndtert. Figur 2.27 Android Activity livssyklus. Hentet fra 48

49 7.3.1 ACTIVITIES En Activity representerer en aktivitet med et skjermbilde. Hver aktivitet er knyttet opp mot et Layout som definerer et skjermbilde. Dette skjermbildet blir definert i en XML fil og knyttet opp mot aktiviteten når aktiviteten blir laget. Se for mer om protected void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); // Sets the Activity layout setcontentview(r.layout.activity_login); /*Creats the rest of the activity*/ } Figur 2.28 OnCreate metode for LoginActivity.java SERVICES En Service er en komponent som kjører i bakgrunnen for å kjøre operasjoner som skal kjøre lenge eller utføre arbeid på prosesser som ikke kjører innenfor applikasjonen. Android Klient har en Service, ConnectionService.java, som har som oppgave å håndtere nettverkstilkoblingen til Server. Den håndterer også kommunikasjonen med serveren og sender ut et broadkast til applikasjonen hver gang den får noe fra server eller tilkoblingen endrer seg (se Figur 2.29). Kodesnutten viser hvordan en Activity binder seg til en Service, her i protected void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); Context /*..*/ // Creates an Intent of the Service type ConnectionService, with the Application Intent intent = new Intent(DataStorage.getAppContext(), ConnectionService.class); // Binds the Service 49

50 bindservice(intent, mconnection, Context.BIND_AUTO_CREATE); // Registrate the reciver getbasecontext().registerreceiver(reciver, new IntentFilter(ConnectionService.ACTION)); } // Handels the Service private ServiceConnection mconnection = new ServiceConnection() { public void onserviceconnected(componentname classname, IBinder service) { LocalBinder binder = (LocalBinder) service; mservice = binder.getservice(); isbound = true; } // When service is bounded, we init the service. mservice.init(readfromfile()); public void onservicedisconnected(componentname arg0) { } isbound = false; }; Figur 2.29 Opprettelse og håndtering av ConnectionService i LoginActivity CONTENT PROVIDERS Content providers håndterer sett med data som er delt med enheten. Slik som å hente kontaktlisten på mobilenheten. Android Klient bruker ikke Content providers. 50

51 7.3.4 BROADCAST RECEIVERS Broadcast receivers er komponenter som tar imot alt som blir reklamert/kringkastet av enheten. For eksempel så kringkastes det ut en melding om at skjermen skrus av. Dette blir da fanget opp av en Broadcast receiver. Android Klient definerer en egen Broadcast receiver i hver aktivitet. Disse reciverene lytter etter meldinger av typen.action som blir sendt ut av ConnectionService.java // Defines the BroadcastReceiver public class Reciver extends BroadcastReceiver public void onreceive(context context, Intent intent) { // Gets the code from intent int code = intent.getintextra("code", -1); // Handels the broadcast switch(code){ case ConnectionService.LOG_OUT: ((DataStorage)getApplication()).setUser(null); finish(); break; case ConnectionService.MEWS_UPDATED: String msg = intent.getstringextra("message"); Toast.makeText(getApplicationContext(), msg, Toast.LENGTH_SHORT).show(); if(infront){ patient = ((DataStorage)getApplication()).getPatient(patient.patientID); } break; update(); case ConnectionService.DISCONNECTED: ((DataStorage)getApplication()).setUser(null); finish(); break; 51

52 } } } Figur 2.30 PatientView.java sin Broadcast receiver Figur 2.30 viser hvordan PatientView.java sin broadcast receiver er definert. public void receivelogin(user user){ if(user!= null) { Log.d("ConnectionService", "Got user"); // Sets the user to the Context ((DataStorage)getApplication()).setUser(user); // Asks for all patients getallpatients(); Intent i = new Intent(ACTION); i.putextra("code", LOGIN_SUCCSESS); // Broadcast that user has logged in. sendbroadcast(i); } } Figur 2.31 ConnectionService.java sin recivelogin(user user) Figur 2.31 viser metoden serveren kjører når clienten har bedt server om å logge inn. Det siste som skjer i denne metoden er at ConnectionService.java kringkaster en melding om at bruker er logget inn MANIFEST Manifestfilen er et XML dokument der alle komponentene til applikasjonen må bli deklarert. Her skal det også defineres hvilke tillatelser applikasjonen har, hvilket minimum API enheten må ha og hvilke hardware og software funksjoner (kamera, Bluetooth) applikasjonen bruker med mer. Figur 2.32 viser litt av manifestfilen til 52

53 Android Klient, der det defineres hvilket API og funksjoner som kreves. <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android=" package="com.example.mewtaviewtest" android:versioncode="1" android:versionname="1.0" > <!-- Defines the API level of the App--> <uses-sdk android:minsdkversion="12" android:targetsdkversion="17" /> <!--Request the features--> <uses-permission android:name="android.permission.internet" /> <uses-permission android:name="android.permission.access_network_state"/> <uses-permission android:name="android.permission.access_wifi_state"/> <uses-permission android:name="android.permission.change_wifi_state"/> <application <!--Defines the app </application> </manifest> Figur 2.32 utdrag fra Android Klient sin manifestfil METAVIEW ANDORID KLIENT Klienten er bygd opp av tre Activities som alle lytter på en Service som håndterer tilkoblingen til server. All data om pasienter blir håndtert av et Applicationobjekt. Se klassediagram Figur

54 Figur 2.33 Android Klient sitt klassediagram. DataStorage.java er et Applikasjons-objekt som alle objekter i applikasjonen har tilgang til. I denne klassen blir pasientene lagret i en liste. LoginActivity.java er aktiviteten som blir startet når applikasjonen startes. Den viser en innloggingsskjerm og oppretter en ConnectionService.java object. Når LoginActivity fanger opp en kringkasting av typen LOGIN_SUCCSESS så starter den PatientView aktiviteten. PatientView.java er en aktivitet som viser et skjermbilde av en gitt pasient og gir bruker mulighet til å registrere en ny MEWS. Under oppstart og ved trykk på tilbakeknappen vil denne aktiviteten starte ListPatientActivity. ListPatientActivity.java er en ListActivity som viser en liste av pasienter og returnerer den pasienten brukeren trykker på. ConnectionService.java er en service som håndterer tilkobling og kommunikasjon med server. Hver gang server sender objekter vil ConnectionService.java kringkaste en beskjed om status. Alle aktivitetene lytter etter mulige meldinger de kan håndtere og håndterer disse etterhvert som de kommer. ConnectionService snakker med server via SignalR. 54

55 8 VIDEREUTVIKLING Klienten er nå spesifisert til å bare registrere mews scoring, vise MEWS logg og vise mews historikk på graf. IMDsoft hadde ikke mulighet til å teste hvordan påvirkning av lagring av data fra vil påvirke databasetrafikken som går mellom MetaVision og databasen. Derfor fikk ikke utvikleren tilgang til å lagre data i MetaVision databasen under utviklingen av produktet. Dermed ble det laget en testdatabase slik at applikasjonen kunne testes og vises frem. 8.1 KLIENT UTVIKLING FLERE SCORINGS ALGORITMER. MEWS begynner å bli utdatert og skal bli erstattet av NEWS, Hverken MEWS eller NEWS kan brukes hos barn under 16 år eller hos gravide, de fysiologiske parameterne som benyttes er normalt annerledes hos disse gruppene, for barn vil PEWS brukes. NEWS (National Early Warning Score) er den nye MEWS der benyttes SaO2 (oksygenmetning i blodet) i tillegg til respirasjons frekvens. SaO2 er ofte tilgjengelig med den utbredelse pulsoksymetere nå har på sengepost. NEWS vil også være dårligere egnet ved KOLS ettersom SaO2 er lav hos KOLS-pasienter. PEWS (Pediatric Early Warning Score) er det samme som MEWS bare for barn. Grunnen til at det er en egen skåring for barn er at verdiene til et barn vil ikke være det samme som verdiene til en voksen, så om det brukes MEWS på et barn så vil det alltid bli en høy skåring på barnet MEDISINERING AV PASIENTER. Som sykepleier vil man ofte medisinere pasienter, dette er en krevende prosess der sykepleier må registrere ut medisinene til de pasientene som man har på runden sin. Når sykepleieren har gått runden sin må han/hun registrere inn hva som er gitt til de pasientene sykepleieren har vært innom. Med en mulighet for registrering av medisiner i applikasjonene vil man kunne registrere hva som er gitt til en pasient med en gang pasienten er medisinert. Da er det anledning for leger å følge medisineringen til en gitt pasient nærmere. Dette vil også gjøre feil registrering av medikamenter mindre sannsynlig siden man får registrert dette inn i systemet med en gang det er gjort. Man vil også få en bedre historikk av hvordan pasientene er medisinert når det blir registrert hva og når pasienten får medisinene sine LOGGFØRING AV VÆSKEINNTAK OG UTTAK Loggføring av væskeinntak og væskeeliminering hos en pasient er noe som brukes på pasienter per dags dato. Denne loggføringen vil gi god indikasjon til leger og sykepleiere hvordan den enkelte pasientens status er. 55

56 8.1.4 TAVLEMØTE Tavlemøter er noe som er i bruk hos flere sykehus rundt om i Norge, sykehuset i Vestfold er en av aktørene EVRY er i kontakt med om dette. Praksisen for dette er nå at man har whiteboard der man skriver opp pasienter, hva som feiler, hva som må gjøres og hva som har blitt gjort på dem. Her vil det være gunstig å koble til på med implementert medisinering. Da vil det være på prosjektor hele dagen en oversikt over pasienter på avdelingen, hvordan statusen er på alle pasientene og når hver pasient skal ha medisinene sine. Per Idag så blir følgende kategorier brukt under tavlemøte etter eksempel fra Sykehuset i Vestfold: Samstemning: Samstemming av legemiddelopplysninger i henhold til hva pasient skal ha. IVABX: Intravenøs antibiotika, om pasient har fått det. Grunnen til at antibiotika (AB) er en egen kolonne er at de skal vurdere om pasienten får rett type AB i forhold til mikrobiologiske prøver som er tatt av pasienten - og at de skal avslutte AB-behandlingen på rett tid. AB behandling skal ikke gis uten grunn. PVK: Har pasienten fått perifer venekateter(intravenøs). Grunnen til at de har med PVK på tavlemøte-gjennomgang er at de skal ikke ligge mer enn 3-4 døgn for da øker risiko for infeksjon. Infeksjon-> lengre sykehusopphold-> koster mer penger->gir pasienten plager - det forsøker de å minske ved å ha tavlemøte. Fall: Er det risiko for fall og isåfall er det funnet mulige tiltak mot dette. Trykksår: Er det risiko for trykksår og isåfall er det funnet mulige tiltak for dette. Ernæring: Ernærings-screening, er det satt opp ernæringsplan for pasienten STØTTE AV FLERE SPRÅK Ettersom applikasjonen har bruksområdet utenfor Norge vil det være hensiktsmessig å legge til mulighet for å velge språk på klientapplikasjoner. 8.2 SERVER UTVIKLING I versjon 1.0 av Server er det kun implementert kobling til en testdatabase. Systemet er skrevet slik at utviklere kun skal skrive en klasse som implementerer et Interface for å koble seg til andre systemer. Skriving av disse klassene ses på som videreutvikling. For at de forskjellige Data Access lagene skal fungere må BLL-laget også skrives om slik at hvilket lag som brukes, velges under installasjon/konfigurasjon. 56

57 9 VERIFISERING OG TESTING Systemet har gjennomgått flere tester under utvikling for å sikre at kvaliteten er høy og at systemet fungerer optimalt. Det er gjort testing på flere nivåer, dette inkluderer testing av kode, testing av samhandling mellom moduler og testing av bruk. Dette kapittelet beskriver de forskjellige testene som er utført. 9.1 ENHETSTESTING Server er delvis enhetstestet. Både BLL og DAL har over 80% dekning på enhetstestet. API-lage har 70% dekning i UserHub og 0% på PatientHub. Dekningen angir hvor mange situasjoner unittestene tar for seg. Ved 100% dekning har en testet alle mulige inputs på alle metoder. Dette er i ideelle forhold ofte umulig å oppnå derfor regnes 70-80% som godkjent i praksis BRUK AV MOQ Både API-laget og DAL er enhetstestet ved hjelp av Moq. Moq er et bibliotek som gjør det lettere for utviklere å enhetstestet ved å mocke dataobjekter. Figur 2.34 viser hvordan en metode i DAL laget er testet ved bruk av Moq og Windows sitt enhetstestings bibliotek. public void MV_Connection_ChangePassword_succsess() { //Arrange var Users = new List<UserModel>() { // Adds User objects }.AsQueryable(); //Creates dataset var mockset = new Mock<DbSet<UserModel>>(); mockset.as<iqueryable<usermodel>>().setup(m =>m.provider).returns(users.provider); mockset.as<iqueryable<usermodel>>().setup(m => m.expression).returns(users.expression); mockset.as<iqueryable<usermodel>>().setup(m => m.elementtype).returns(users.elementtype); mockset.as<iqueryable<usermodel>>().setup(m =>m.getenumerator()).returns(users.getenumerator()); //Creates the context var mockcontext = new Mock<.Database.Context>(); 57

58 mockcontext.setup(c => c.users).returns(mockset.object); //Act var connection = new.server.dal.connection(mockcontext.object); var user = new User(1, "KEY", Convert.ToBase64String(Users.First().password), "Name"); var outcome = connection.changepassword(user, "NewPassword"); //Assert Assert.IsTrue(outcome); } Figur 2.34 Utdrag fra testing med moq BRUK AT STUB BLL-laget er enhetstestet ved hjelp av Stubs. Istedenfor å koble BLL opp mot DAL, kobles laget opp mot en klasse som kun gir bestemte data tilbake. Figur 2.35 viser PatientBLL sin konstruktør for testing. private MetaVisionInterface mvinterface; /*... */ public PatientBLL(string test) { } if (test == "TEST") { } else { } mvinterface = new Stub(); throw new ArgumentOutOfRangeException("test", "This can only be -> 'TEST'"); Figur 2.35 En av PatientBLL sine konstruktører. 58

59 9.2 BRUKERTESTING Android- og Windows-applikasjonen er brukertestet. Testgruppen besto av sykepleiere som ikke hadde fått noe opplæring av systemet. Se brukertesten og resultater i Vedlegg I-Brukertest. 9.3 SYSTEMTESTING Hele systemet har blitt kjørt samtidig der flere klienter har vært koblet mot Server. Klientene har da blitt testet med all funksjonalitet. Se vedlegg H - Systemtest for resultater av systemtest. 9.4 AKSEPTANSETEST Akseptansetest utføres for å avgjøre om et produkt oppfyller kundens behov, og stemmer overens med kravspesifikasjonen og annen dokumentasjon. Akseptansetesten er siste mulighet for en kunde å avvise et utilstrekkelig produkt, før det settes i drift. En godt gjennomført akseptansetest kan beskytte kunden mot tap som skyldes dårlige produkter. Akseptansetesten ble utført uformelt med et møte mellom utviklere og EVRY, der EVRY gikk gjennom applikasjonene. Utviklerne forklarte hvordan backend fungerte og kunne endres for å passe andre systemer. EVRY ga positive tilbakemeldinger på dette møtet, men det ble ikke noe skriftlig her, derfor ble det sendt mail til EVRY med spørsmål om hvordan oppfatning EVRY hadde om produktet. Se Vedlegg K - Evaluering fra EVRY for svarene fra EVRY. 10 METODE OG PLANLEGGING Under utvikling av er det brukt forskjellige metoder, verktøy og teknikker, disse vil bli forklart i dette kapittelet. Riktig bruk av disse elementene i utviklingsprosessen har vært med på å øke kvaliteten på sluttproduktet. Valg av teknologi og utviklingsverktøy ble i stor grad bestemt av utviklerne SCRUM Scrum er en interaktiv og inkrementell smidig prosjektmetodikk og brukes i hovedsak for å utvikle programvareprosjekter. Det baserer seg på å sette rammene på hva som skal utføres, ikke hvordan det utføres. Dette bestemmes av utviklingslaget / Scrum-teamet. Figuren under viser Scrum-prosessen 59

60 Figur 2.36 Viser Scrum prosessen. Bildet er hentet fra PARPROGRAMMERING Parprogrammering er en smidig programmeringsteknikk som går ut på å ha to programmerere som programmerer sammen. Den ene vil skrive kode mens den andre ser igjennom hver kodelinje som blir skrevet. Rollene byttes ofte. Dette sikrer kvaliteten på koden som blir skrevet, og kan øke effektiviteten når programmereren er ukjent med teknologien som blir brukt UTVIKLINGSMILJØ OG SPRÅK systemet er skrevet i C#, XAML, XML og Java og er blitt utviklet i både Eclipse og Microsoft Visual Studio Prosjektet har støttet seg til Team Foundation Server (TFS) gjennom hele utviklingen av produktet. TFS er et prosjekthåndteringssystem fra Microsoft gir prosjekter versjonshåndtering, rapportering, testing og utgivelseshåndtering med mer. 60

61 Høgskolen i Oslo og Akershus, våren 2014 Dokument 3 - Prosessrapport 61

62 62

63 1 INNHOLDSFORTEGNELSE 2 Gruppen Om oppdragsgiver EVRY Sykehuset i Østfold Visjon og Mål Visjon Mål for EVRY Mål for Sykehuset i Østfold Mål for Gruppen Bakgrunn for prosjektet Vår kunnskap Tildeling av oppgaven Oppgave 1: HealthVault Oppgave 2: Åpne sykehusdata Oppgave 3: MetaVision Dagens løsning Vurdering av kravspesifikasjon Prosessen rundt kravspesifikasjonen Endring i kravspesifikasjonen Kravspesifikasjonens rolle Endelig kravspesifikasjon Kravspesifikasjonens samsvar med produktet Vurdering av metode og planlegging Utviklingsfaser Valg av metode Scrum Backlog Prosessrapport

64 7.3.2 Scrum team Scrum møter Planleggning av sprinter Hjelpeverktøy til Scrum Scrum-backlog håndtering Interaktiv Scrum-tavle Scrum burndown kart Retroperspektiv Sprint Sprint Sprint Sprint Sprint Sprint Parprogrammering Viktige valg Utviklingsmetode Brukergrensesnitt Arkitektur Ansvarsområder Utviklingsmiljø Samarbeid med oppdragsgivere og leverandører EVRY Sykehuset i Østfold imdsoft Risikohåndtering Vurdering av Teknologi Windows Store Applikasjon Windows Runtime Library Prosessrapport

65 8.3 Android Applikasjon SignalR Oxyplot Open Web Interface for.net (OWIN) JSON Json.NET NLog Microsoft Team Foundation Server (TFS) Visual Studio Eclipse Dropbox Vurdering av teknisk arkitektur Server Klient Windows Android Database / Dal / BLL Vurdering av brukergrensesnitt Testing Enhetstester Brukertest Systemtest Akseptansetest Konklusjon Prosessrapport

66 PROSESSRAPPORT Prosessrapporten inneholder informasjon om bakgrunnen til prosjektet, vurderinger vi har gjort og resultatene vi har tilegnet oss ved testing av produktet og samtaler med EVRY. Prosessrapporten har som hovedpunkter å formidle: - Hvordan utviklingsprosessen har gått - Våre meninger om prosjektet - Begrunne viktige valg i utviklingen - Peke på styrker og svakheter i produktet. - Fortelle om oppgaven og mål de forskjellige aktørene har. 2 GRUPPEN Gruppen består av tre studenter som går Dataingeniør ved Høyskolen i Oslo og Akershus: Tore Angell Petersen, Tommy Kihlstrøm og Alexander Seldal Bakke. Tore og Tommy har jobbet sammen flere ganger i tidligere skoleprosjekter. Alexander fikk vi kontakt med når vi så etter det siste gruppemedlemmet. Vi har alle det samme ambisjonsnivå om å fullføre en god bacheloroppgave. 3 OM OPPDRAGSGIVER I denne oppgaven har vi måtte folholde oss til to oppdragsgivere, EVRY gav oss oppgaven og krav til oppgaven mens Sykehuset i Østfold har fortalt hva de egentlig trenger og litt om deres problemer i hverdagen. 3.1 EVRY EVRY er et av de største IT-selskapene i Norge og Norden. Over en million nordmenn er til enhver tid avhengig av tjenester som EVRY leverer, hver eneste time. Hele døgnet logger noen seg inn i nettbanken, henter fram viktige dokumenter på jobben eller sjekker når neste tog går hjem. Digital tjenesteutvikling er ikke bare noe som foregår inne i datamaskiner, det er en forutsetning for hele samfunnet. EVRY har ansvaret for om lag en tredjedel av alle ITtjenesteleveranser i Norge. De har et stort antall kunder både i offentlig sektor og privat næringsliv, som for eksempel: DnB, Telenor, Posten Norge, Sparebank 1 Gruppen, Statoil, Hydro, REC, Storebrand, Gjensidige, Oslo kommune, Trondheim kommune, NAV og Helse Norge. 66 Prosessrapport

67 3.2 SYKEHUSET I ØSTFOLD Sykehuset i Østfold har over 4800 ansatte per 2014 og er dermed Østfolds største arbeidsplass. De hadde over innleggelser i 2013 hvor ca var innlagt relatert til fysikk. De har 407 senger for pasienter som er innlagt relatert til fysikk. Det bygges nå nytt sykehus på Kalnes i Sarpsborg som er på over kvm. Her skal moderne teknologi og IKT-løsninger benyttes. 4 VISJON OG MÅL Applikasjonene er skrevet som bacheloroppgave på Høyskolen i Oslo og Akershus våren Denne oppgaven gir oss mulighet til å samle all kunnskapen vi har tilegnet oss og lage et produkt som summerer opp mye av det vi har lært. Nedenfor står det litt om de mål vi satte oss når prosjektet startet. 4.1 VISJON Vi ønsker å gjøre hverdagen til sykepleiere, som allerede er hektisk og til tider vanskelig, enklere. Målet er å minske tiden man bruker på dokumentasjon, å gi dem mer tid til å det som virkelig er viktig, pasienten. Når prosjektet avsluttes skal produktet være bra og dokumentert godt. Det skal gi et innblikk i hvordan fremtiden kan se ut. 4.2 MÅL FOR EVRY Utvikle en prototype som de kan videreutvikle hvis det er bra, og godt nok dokumentert. Noe de kan selge til sykehusene som er godt produkt som vil hjelpe sykehusene på en god måte. 4.3 MÅL FOR SYKEHUSET I ØSTFOLD Sykehuset i Østfold ønsker en mer mobil hverdag, der de kan eksempelvis ta med seg en tablet til sengepost og notere det som må noteres. Slik at man slipper å bruke tid på å skrive det inn på datamaskin senere samme dag. 4.4 MÅL FOR GRUPPEN Gruppens mål har hele tiden vært å lage et bra, sikkert og robust system som er dokumentert godt. Tanken har også vært at etter prosjekttiden er over skal systemet kunne videreutvikles. Derfor har vi hele tiden prøvd å programmere og dokumentere etter best practice. Vi ønsker en god karakter, rett å slett noe vi kan være stolte av å ha laget. 67 Prosessrapport

68 5 BAKGRUNN FOR PROSJEKTET I dette kapittelet går vi gjennom hvilken relevant kunnskap vi har fra før, hvilke oppgave alternativer vi fikk i møte med EVRY, begrunnelse for valg av oppgave og dagens situasjon i forhold til hva oppgaven skal løse. Da vi bestemte oss for å velge en oppgave hos EVRY hadde Tore allerede vært i kontakt med Antonio Lo Cascio hos EVRY og fått noen detaljer om forskjellige oppgaver. I et møte med Antonio fikk vi oppgavene spesifisert uten spesifikke krav, det gjorde at vi fikk frihet til å tenkte stort og spesifikt. Det ble vist noen prototyper fra EVRY i møtet. Vi vurderte mye de forskjellige oppgavene sammen i gruppa, og så at denne oppgaven krevde mye kunnskap om noen teknologier vi aldri hadde vært inne på før. Oppgaven blir kompleks når man skal koble seg på et eksisterende system. I tillegg må man tenkte på alle konsekvenser som forekommer ved å legge til denne funksjonaliteten. Det var også ønskelig at data skal sendes live til alle brukere i systemet slik at man kan være sikker på at alle data man ser, er det siste som er registrert. 5.1 VÅR KUNNSKAP Da vi valgte denne oppgaven hadde alle noe kunnskap om C#, fra faget Webapplikasjoner (LO139I). Det var dermed lite krevende å sette seg inn i hvordan bruke.net i Windows 8 Store applikasjon. Dette er også veldig likt Java, noe vi har brukt mye på skolen. Ingen av oss hadde prøvd oss på Windows 8 Store applikasjon, men vi så ikke vi på dette som et problem. Alexander hadde i sin fritid satt seg inn i Android utvikling som viste seg å være til stor nytte for oppgaven. 5.2 TILDELING AV OPPGAVEN Tore jobbet allerede hos EVRY på deltid, dette var vår inngangsbilletten til EVRY slik at vi kunne ta en bacheloroppgave hos dem. I et møte med EVRY fikk vi servert tre oppgaver som var basert på noe helse Norge hadde hatt bruk for OPPGAVE 1: HEALTHVAULT Den første oppgaven handlet om å lage en app som koblet seg på Microsoft sitt HealthVault system. HealthVault er et system der du selv kan lagre helse data som du måler selv. Slik som blodtrykk, puls og mer til, hvis du har utstyr hjemme som kan måle dette. Vi gikk ikke i dybden på denne oppgaven da denne oppgaven ikke var veldig godt definert. 68 Prosessrapport

69 5.2.2 OPPGAVE 2: ÅPNE SYKEHUSDATA Den andre oppgaven vi fikk servert handlet om å bruke åpne data hos HelseNorge.no. Oppgaven var spesifisert til å bruke åpne data fra sykehus. Med disse data skulle vi rangere sykehusene på hvilke behandlinger de er best på, og deretter gi brukeren kvalitetsindikatorer de kan forholde seg til. Dataene skal gis til brukere gjennom en app til mobile enheter som iphone, Android og muligens Windows Phone det er også ønskelig at applikasjonen fungerer på tablet også OPPGAVE 3: METAVISION Den siste oppgaven var å lage en applikasjon som koblet seg på MetaVision sin WebServices-grensesnitt slik at man skulle kunne registrere å hente data i MetaVision sitt system. MetaVision brukes av Sykehuset i Østfold der de registrerer alle data om pasientene. Oppgaven var å kunne registrere Modified Early Warning Score (Heretter kalt Mews) når sykepleiere eller leger (heretter kalt brukere) besøker sengeposter. EVRY hadde to prototyper å vise som forklarte i praksis hva de ønsket at vi skulle lage og forbedre. Problemet denne oppgaven løser er Post-it lapp relatert. Når en sykepleier måler verdier hos pasienten noteres disse verdiene ofte på en Post-it lapp og blir etter runden er tatt, skrevet inn i MetaVision. Dette er tregt og kjedelig for sykepleier og kan resultere i tapte data om Post-it lappen skulle bli borte. Vi valgte den siste oppgaven da denne var best definert, den hadde stort omfang. Men den største grunnen var at vi så den store nødvendigheten av en slik applikasjon på sykehusene. Denne applikasjonen vil kunne forandre fremtiden til sykehusene i Norge. EVRY var fornøyd med at vi valgte denne oppgaven. 5.3 DAGENS LØSNING Som kort nevnt i oppgaveteksten i forrige avsnitt brukes det idag MetaVision på Sykehuset i Østfold. MetaVision kjører på Windows og er koblet mot en egen server. Det er ingen planer om å bytte ut MetaVision på sykehuset siden dette er et omfattende og bra system. Problemer de opplever med MetaVision er at det er så innviklet at det krever flere uker kanskje måneder for en sykepleier å lære seg å bruke det effektivt. Noe av grunnen er at MetaVision skal kunne konfigureres til hver enkelt sykepleiers ønske, dette gjør at MetaVision kan være helt annerledes fra en sykepleier til en annen. Dette er ikke negativt men krever mye tid. 69 Prosessrapport

70 Sykehuset i Østfold bygger nytt bygg og ønsker å gå bort fra stasjonære maskiner og har dermed tatt bort rommene som er beregnet for datamaskiner. Det betyr at sykepleiere må begynne å benytte seg av tablet eller laptop. MetaVision på tablet er i praksis en dårlig løsning da det ikke er optimalisert for tablets eller multitouch-skjermer. 6 VURDERING AV KRAVSPESIFIKASJON I dette kapittelet går vi gjennom prosessen å lage og definere kravspesifikasjonen. Vi vil også gå gjennom hvordan den ble brukt og hva som endret seg under prosjektet. Etter at vi og EVRY ble enige om oppgaven og kontrakten var skrevet under, begynte vi å definere en kravspesifikasjon. Den sendte vi til EVRY som leste dokumentet og endret på noen punkter. Etter det ble versjon 1.1 satt som oppgavens kravspesifikasjon. I prosjektperioden har forhold endret seg og noen punkter er satt som umulig i dette prosjektet. Mer om dette senere i dette kapittelet. Versjon 1.2 er endelig versjon og er lagt med som Vedlegg B. Kravspesifikasjonen ble utarbeidet sammen med EVRY, vi diskuterte ofte funksjonalitet og videreutvikling i ukentlige møter på Fornebu. 6.1 PROSESSEN RUNDT KRAVSPESIFIKASJONEN Da vi begynte å jobbe med kravspesifikasjonen så vi på prototypene vi fikk av EVRY, her prøvde vi å se hvilke funksjoner som er essensielle for funksjonaliteten av denne applikasjonen. I møte med EVRY snakket vi om hvilke funksjonalitet de så for seg at skulle være med. I første omgang da vi skrev kravspesifikasjonen prøvde vi å liste ut veldig generelt hvilke funksjonalitet vi ønsket. Deretter delte vi dem opp i spesifikke funksjoner som enkelt kan sjekkes mot applikasjonen når den var ferdig. I første utkast satte vi disse punktene som EVRY sine krav til funksjonalitet: Hente ut pasienter og informasjon om pasienter fra MetaVision. Velge en pasient og se deres MEWS. Legge inn verdier til pasientens MEWS. Måten å vise MEWS skal generaliseres (mulighet for å endre visning). EVRY var fornøyde med kravene vi hadde satt og lurte på om vi ikke hadde satt lista litt høyt når vi listet brukbarhetskrav. Dette er brukbarhetskravene: Man skal ikke trenge mer enn 1 times kursing. Det skal ikke være mer enn 3 klikk for å gjøre enkle oppgaver. Ikoner og bilder skal gi mening. 70 Prosessrapport

71 Brukertesten på Sykehuset i Østfold viser at alle disse kravene er oppnådd, les mer om brukertesten i Vedlegg I: Brukertest ENDRING I KRAVSPESIFIKASJONEN 12. Mars fikk vi etter mye om og men endelig et konkret svar fra imdsoft, hvis vi skulle legge inn data i MetaVision måtte imdsoft analysere hvordan dette kunne påvirke all annen trafikk mot databasen deres. Dette hadde ikke imdsoft ledige ressurser til å få gjort på den tiden vi trengte det, ettersom imdsoft holder på å rulle ut MetaVision 6.0 og dette krevde alle ressursene til imdsoft.dette medførte at punktet Hente ut pasienter og informasjon om pasienter fra MetaVision ble flyttet til fremtidige utvidelser. Dette var en stor nedtur for hele prosjektet og ville gjort at prosjektet var unyttig om man ikke kunne koble det til MetaVision senere. Men det stoppet ikke oss, vi lagde vår egen backend som har den funksjonaliteten vi trengte for at applikasjonen skulle fungere under utvikling og testing. I stedet for å la problemet med MetaVision tynge oss så vi da muligheten for å bruke mer tid på å lage en Android applikasjon til telefon som kobler seg på vårt system, som senere vil fungere mot MetaVision om det skulle gjennomføres. Dette snakket EVRY mye om i de første møtene vi hadde med dem, tanken da var at en pasient skulle kunne registrere smertegrad selv. Vi valgte derimot å legge inn samme funksjonalitet i Android applikasjonen som man ønsker i tablet versjonen til Windows; liste alle pasienter, liste Mews og kunne registrere Mews. Utviklingens tidspress og prioriteringer av andre funksjonaliteter har gjort at Måten å vise MEWS skal generaliseres er flyttet til fremtidige utvidelser, da dette punktet ikke var kritisk for at applikasjonen skulle være funksjonell. 6.2 KRAVSPESIFIKASJONENS ROLLE Hensikten med en kravspesifikasjon er å definere en avtale mellom kunde og leverandør som definerer hva som skal leveres. Denne avtalen gjør det enklere å kunne begrense oppgaven og dermed kunne se hvilke funksjoner som kreves av produktet. Dette gjør at EVRY har større innsyn i hvilke funksjoner vi prioriterer og hva de kan forvente å ha når prosjektet ferdigstilles. Kravspesifikasjonen brukes når EVRY skal ha en akseptansetest på produktet. Kravspesifikasjonen gjør det også enkelt å se hva man må implementere og i hvilken rekkefølge det vil være mest hensiktsmessig å gjøre det i. Dette gjør det enklere å sette 71 Prosessrapport

72 opp sprintene og backloggen. Hovedpunktene i sprintene ble dermed ofte basert på kravspesifikasjonen. Kravspesifikasjonen har under hele prosjektet vært vår rettesnor. Når vi kommer med nye ideer har vi lagt dem i fremtidige utvidelser, oftest etter statusmøter med EVRY der man ser potensialet for denne applikasjonen. Utviklingsmiljøet ble satt opp før kravspesifikasjonen var ferdigstilt (Visual Studio 2013, Team Foundation Server). Vi undersøkte hvilke teknologier vi måtte bruke og begynte å studere disse før vi ferdigstilte kravspesifikasjonen (Windows Store Applikasjon, XAML, SignalR). 6.3 ENDELIG KRAVSPESIFIKASJON Se endelig kravspesifikasjon i Vedlegg B - Kravspesifikasjon. 6.4 KRAVSPESIFIKASJONENS SAMSVAR MED PRODUKTET Produktet tilfredsstiller alle de nødvendige kravene til den endelige kravspesifikasjonen. På grunn av at vi ikke fikk tilgang til MetaVision sin database og dermed hadde noe bedre tid, fant vi at det var hensiktsmessig å utvikle en Android applikasjon i tillegg, for å vise at vårt system fungerer på tvers av plattformer. Gruppa er veldig fornøyd med at vi har kunnet lage en applikasjon med live oppdatering over flere plattformer. Selv om vi ser at alt fungerer bra, så kan aldri dette publiseres da det vil gi sykepleiere mer jobb, de må skrive inn verdiene i to systemer, og MetaVision. Vi er glade for å kunne levere med en Android applikasjon som har nesten tilsvarende funksjonalitet som Windows applikasjonen. EVRY uttrykker at designet er enkelt, brukervennlig og virker fornøyd med resultatet og måten vi taklet utfallet med imdsoft og MetaVision. 72 Prosessrapport

73 7 VURDERING AV METODE OG PLANLEGGING Vi valgte å bruke Scrum som utviklingsmetode. Vi har også benyttet oss av parprogrammering, dette mest under design. I dette kapittelet vil vi fortelle om hvilke endringer vi har gjort med Scrum, hvordan vi har brukt det og erfaringer vi har fått gjennom arbeidet. Her vil vi også beskrive og begrunne utføringen av prosjektet. 7.1 UTVIKLINGSFASER Tidlig i prosjektet satte vi opp en fremdriftsplan som satte tiden vi hadde på de forskjellige oppgavene. Siden vi ikke hadde nok kunnskap om oppgaven og kravene fra EVRY ikke var fastsatt hadde vi ikke så mange milepæler å sette opp. Nedenfor ser du et utklipp av første versjon. Figur 3.1 Planlagt fremdriftsplan Milepælene ble aldri oppdatert men vi fulgte sprintene og hadde møte med EVRY i begynnelsen av hver sprint om hva som var viktigst å implementere. Vi hadde aldri problemer med å vite hva som var målet og når vi begynte en sprint satte vi mål for den sprinten. Det er beklagelig at en skikkelig milepælplan aldri ble satt sammen. Dette har vi som sagt aldri savnet og det hadde i tillegg vært problematisk da store endringer av oppgaven skulle komme underveis. 73 Prosessrapport

74 Fremdriftsplanen ble oppdatert i dokumentasjonsfasen. Noen dokumenter er oppdatert og er dermed markert med tidspunkt. Under ser du et utdrag som viser sprintene slik de forekom i praksis. Figur 3..2 Fremdriftsplan Slik du ser er det lagt til en Sprint 6 som vi la til da vi og EVRY ble enige om at grafer var en viktig del av oppgaven, en uke ble da satt av til dette. En uke ekstra koding hadde vi regnet med da vi planla en måned med testing. 7.2 VALG AV METODE Scrum-metoden er den utviklingsmetoden vi har mest kunnskap om, den gir også god oversikt over framdriften, under utviklingen og det er lettere å oppdatere alle parter på prosjektets tilstand. Veileder har gode erfaringer med Scrum og EVRY har Scrum som standard utviklingsmetodikk for alle prosjekter. Scrum er en type smidig metodikk, smidig metodikk har følgende grunnverdier: Individer og samspill fremfor prosesser og verktøy. Fungerende programvare fremfor omfattende dokumentasjon Samarbeid med kunden fremfor kontraktsforhandlinger Svare på endringer fremfor å følge en plan 74 Prosessrapport

75 Scrum er en smidig utviklingsmetode som prioriterer kundes ønsker fremfor prosedyrer og kontrakter. Det er fokus på å gi det kundene sine ønsker raskt og det som virkelig er viktig fremfor å holde på langsiktige planer som fossefallsmodellen prioriterer. Fossefallsmodellen er på ingen måte dårlig men er best egnet på store prosjekter hvor målet er klart og man er sikker på at tilnærmet ingen krav endres under utviklingsperioden. Vi valgte å bruke scrum metoden. Siden vi var lite erfarne og hadde liten kunnskap om hva dette prosjektet ville ha som milepæler. Vi satte dermed bare opp sprintene og viktige datoer som milepæler. Vi vet at dette ikke er riktig metode, men hadde vi gjort dette en gang til hadde vi brukt mer tid på dette etter at vi hadde skrevet kravspesifikasjonen, ikke før. 7.3 SCRUM Siden det er første gang vi jobber med Scrum i praksis var trangen etter å begynne å kode og jobbe med prosjektet stor og noen rutiner ble til tider omgått. Man kan jo prøve å si at vi hadde standup-møter hver dag, men realiteten var noe helt annet. Standupmøtene hadde vi ca. annenhver dag. Mot slutten av prosjektet fikk vi flere av rutinene inn, og standup-møtene hadde vi noen ganger også etter lunch. Vi benyttet oss av Team Foundation Server sin backlogg og Scrum-tavle for å holde struktur i oppgavene som skulle gjøres. Scrum-tavlen var meget enkel å bruke men det tok tid før alle brukte den hyppig og holdt den oppdatert BACKLOG Siden vi ikke har gjort noe lignende før så ble backlog items først satt opp sent i sprinten, før sprinten og noen ganger første dagene i den sprinten det ble gjort i. Oppgavene ble satt opp etter hvor langt vi var kommet og hva vi så trengtes for å komme videre. Vi har lært av dette at vi skulle satt opp en liste av oppgaver som skulle gjennomføres før vi startet på første sprint. Nesten som en ønskeliste over hva som vi ville ha med i applikasjonen som vi fortløpende kunne velge fra for å dekke kravene som var satt til applikasjonen. Det er viktig å merke seg at vi gjorde egne prioriteringer. I normal Scrum er det kunden som gjør dette. Vi valgte denne løsningen for å spare tid og krefter på kommunikasjon med EVRY og på grunn av at EVRY holdt på å kjøre ut en ny versjon av MetaVision til kundene sine, slik at de hadde få ressurser til disposisjon for oss. Dette utgjorde en klar risiko, om vi hadde prioritert feil ville det fått konsekvenser siden vi hadde statusmøter med EVRY rett etter hver sprint og hadde vi gjort noe feil måtte vi gått en sprint tilbake. 75 Prosessrapport

76 Selv om vi gjorde det på måten vi gjorde det på nå, så er vi veldig fornøyde med hvordan vi fikk dette til uten store forkunnskaper. Vi klarte å prioritere de tunge kjerneoppgavene som vi tror ville gi bedre utslag på sluttproduktet. 76 Prosessrapport

77 7.3.2 SCRUM TEAM Etter hva som er vanlig skal et scrum team være fra 3-9 individer, så vår gruppe på tre personer var akkurat nok til å danne et scrum team. Vi valgte ikke en Scrum-master, men når vi ble hengende litt etter gikk Alexander Bakke inn i rollen som Scrum-master og dyttet gruppen videre så vi kom tilbake på rett spor. I et normalt Scrum-team sitter gjerne ulike deltakere fast på ulike oppgaver. Vi fulgte denne normen til en viss grad der vi startet på våre ulike deler av oppgaven, da noen deler av oppgaven ble fullført før de andre, flyttet vi litt rundt på ressursene slik at når noen ble tidlig tom for oppgaver hjalp dem de andre SCRUM MØTER I henhold Scrum-metoden skal det avholdes et raskt statusmøte hver morgen. I og med at vi har vært så få og alle stort sett har jobbet samtidig på et grupperom har det virket unødvendig siden vi diskuterte fortløpende hva vi gjør. Vi har hatt mindre uformelle møter på starten av dagen der vi fortalte hvor langt vi har kommet og diskutert om hva som var planen for dagen PLANLEGGNING AV SPRINTER Da kravspesifikasjonen var ferdigstilt startet arbeidet med å prioritere de forskjellige funksjonene. Siden vi ikke hadde satt opp backloggen fra starten valgte vi oppgaver for å får en basic applikasjon opp å gå. Slik at vi etterhvert kunne videreutvikle denne basen. Figur 3.3 Illustrasjon av metodikken i Scrum. 77 Prosessrapport

78 Figur 3.3 viser hvordan backlog og sprinter henger sammen. Avvikende fra denne figuren har vi derimot valgt å ha to ukers sprinter og sprint backloggen ble laget underveis. 7.4 HJELPEVERKTØY TIL SCRUM Vi brukte TeamFoundationServer(TFS) til overvåkning av progresjon. Vi brukte dette til å sette opp oppgaver over hva som skulle gjøres i hver sprint, sette av tid på oppgaver og fordele dem. Ved hjelp av TFS har man til enhver tid oversikt over prosjektet, framgangen i utviklingsprosessen og de oppgavene som var definert. TFS håndterte Scrum-backloggen interaktivt og vi brukte det i planlegging av neste Scrum-sprint. Ved hjelp av den virtuelle Scrum-tavlen fikk vi en god visuell oversikt over oppgavene for gjeldene sprint og hvem som utfører disse SCRUM-BACKLOG HÅNDTERING Skjermbildet viser oversikt over Scrum-backloggen i TFS. Her kan prosjektleder prioritere oppgaver. Figur 3.4 Skjermbilde av Scrum-backlog håntering. 78 Prosessrapport

79 7.4.2 INTERAKTIV SCRUM-TAVLE Her oppdaterer hver utvikler status på de oppgavene hun/han utfører. Prosjektleder kan også definere hvilken utvikler som skal utføre hvilke oppgaver. Når en oppgave blir laget estimerer man hvor lang tid man kommer til å bruke på oppgaven. Figur 3.5, Sprint board for sprint 5. Øverst til høyre i Figur 3.5 ser man burndown kartet for sprinten. Før sprinten starter bør hver utvikler ha satt opp oppgaver som tilsvarer 7 timers arbeid i 10 dager (2 uker). 79 Prosessrapport

80 7.4.3 SCRUM BURNDOWN KART Scrum burndown kart er en graf som viser sprintens progresjon i forhold til oppgavene som er satt til sprinten. Hvor mye tid som er brukt sammenliknet med antatt tidsforbruk. Vi har aldri brukt dette før så de første sprintene gikk først oppover så nedover, men Figur 3.6 viser den sprinten vi klarte å planlegge best og følge den avsatte tiden gjennom sprinten. Figur 3.6, Sprint 5 Burndown chart. Midt på figuren ser vi at grafen flater ut og så faller brått dette var på grunn av at vi glemte å føre ned timer eller en eller flere oppgaver tok lengre tid enn antatt. Så ser vi i slutten av uken at estimerte timer ikke fulgte den anbefalte linja, dette var på grunn av at vi møtte på noen vanskeligheter i slutten. Dette medførte at vi ikke klarte å fullføre alle oppgavene planlagt for denne sprinten. 7.5 RETROPERSPEKTIV Vi ser i ettertid at god planlegging før hver sprint er uvurderlig. Vi brukte to sprinter før vi lærte å bruke TFS ordentlig. Vi la godt merke til at produktiviteten økte da sprintene var godt planlagt og alle på gruppen hadde estimert timer. Ved at vi begynte å skrive ned timer riktig fikk vi også bedre oversikt over hvordan vi lå an i forhold til milepælene våre. Scrum reviews ble også bedre utnyttet og hjalp til å planlegge neste sprint. Kommunikasjon med kunden må være god gjennom hele prosjektet. Vi slet litt i starten av prosjektet med å få gode svar fra EVRY. Dette var ikke bare EVRY s feil men også vår, vi formulerte ikke alltid spørsmålene bra nok. Dette gjorde at det tok lengre tid å få 80 Prosessrapport

81 svar og svaret ble dermed ikke det vi egentlig ville ha. Av det ser man at vi skulle vært flinkere med å formulere oss i mail og be om tilbakemelding når vi ikke fikk svar etter en lengre periode. Vi føler selv at vi tidlig fikk god oversikt over hva som skulle lages, og en plan på hvordan dette skulle gjennomføres. Dette hjalp oss da vi fikk beskjed fra imdsoft og EVRY at vi ikke kunne koble til MetaVision halvveis ut i prosjektet. Vi tok fort tak og ettersom alle oppgaver var definert og utdelt fant vi fort ressurser til å redde prosjektet. Dette er det første store prosjektet der alle medlemmene har måttet utføre alle oppgaver selv gjennom ett helt prosjekt. Vi har lært mye om planlegging, hvilke dokumenter som er viktige og hvordan vi skal gjennomføre prosessen best mulig SPRINT 1 Vi fikk gjort de store oppgavene. Alle backlogg oppgavene ble gjort utenom Klassediagram, Aktivitetsdiagram, Use-Cases og testmiljø. Vi har fått en god sammenslått forståelse av systemet som skal utvikles. Kravspesifikasjonen har blitt godkjent av EVRY. Vi fikk ikke kjørt standup hver dag. Tore var mye borte i løpet av sprinten som gav oss mindre fremdrift. Vi fikk også sen informasjon av EVRY som gav oss mye «Dødtid» som ble brukt til å lese på teknologi. Vi føler vi har kommet godt i gang. Og har veien klar fremover. Eneste som vi venter på nå er et Testmiljø og selve MetaVision SPRINT 2 Vi ble ferdig med arkitektur av systemet tidlig i sprinten. Videre jobbet vi med utvikling. Der fikk vi en stopp ettersom vi hadde problemer med å installere MetaVision som testmiljø. Det er et stort problem at vi må starte sprint 3 med å legge inn MetaVision. Vi har ikke greid å ta Scrum ordentlig i bruk. Vi har lært mye av hvordan vi skal sette opp sprinter og gjennomføre dem. Vi har startet å teste SignalR mellom Client og. Dette er bra. Vi ligger bak skjema. Dette må hentes inn i løpet av Sprint SPRINT 3 Vi startet for fullt med implementering av system. Vi fikk opp MetaVision på lokale maskiner etter mye slit og maling med EVRY. Det viste seg da at dette var ikke det vi trengte. Vi må ha en service som gir oss MvBus. Dette kunne ikke EVRY noe om så de tok kontakt med imdsoft. Vi venter fremdeles på svar fra imdsoft. Vi måtte derfor ta en stor avgjørelse på om vi skulle vente på imdsoft på tilgang til MetaVision eller ikke. Avgjørelsen ble at vi lager vår egen database som ligger i. Denne avgjørelsen ble tatt midt i sprinten og gjør slik at vi kan fullføre prosjektet. 81 Prosessrapport

82 Server frontend er blitt satt opp, og server backend fungerer (Fremdeles mye som må gjøres). Klientapplikasjonen er også kommet i gang. Vi ligger fremdeles litt bak planen. Men har greid å hente inn en del tid denne sprinten. (Mye grunnet avgjørelsen som ble tatt ang MetaVision) SPRINT 4 Serveren er blitt testet med et testprosjekt. Den er klar for å implementeres i den faktiske klienten. Serveren er ikke ferdig, men kan brukes. Vi har ikke hørt mer om hva som skjer med MetaVision, men fikk beskjed fra EVRY at vi ikke skulle fokusere på dette nå. Frontend viser våre tre Views, men er enda ikke koblet opp mot Server-API-et. Denne sprinten har fungert ok. Vi har kjørt standupmøter hver dag, noe som har gitt oss god oversikt over hva som skjer. Gruppen har vært litt dårlig til å loggføre hva man gjør fra dag til dag. Det ble heller ikke skrevet ned timer helt riktig, altså det ble glemt å skrive ned timer noen av dagene, noe som gir oss en ufullstendig sprintgraf. Vi flyttet også noen backlogg items over til sprint 5. Dette var fordi vi ikke ble ferdige med dem. Bli bedre til neste gang -Mer utfyllende dagbok. -Skrive av timer når man gjør noe SPRINT 5 Siden vi ikke har kunnet koble oss på MetaVision har vi valgt å lage en Android klient i tillegg. Dette for å gjøre oppgaven kompleks nok og vise at SignalR er uavhengig av plattform. Alexander har vært super og lagd applikasjonen, den lar deg logge inn, liste ut pasienter og se MEWS. Android applikasjonen får ikke oppdateringer ennå men det blir gjort neste sprint. På serveren har vi lagt inn loggføring til fil. Alle handlinger og feilmeldinger blir logget til fil. Man har brukt mye tid på å lese seg opp på autentisering og autorisering, dette er nå stoppet. Det er egentlig ikke nødvendig å ha dette da det API vi kobler oss på har dette innebygget. Eneste man må sikre er nettverkskommunikasjon over HTTPs (TLS/SSL). Windows 8 applikasjonen begynner og ta form. Vi har laget applikasjonen på nytt med en Windows templaten slik at vi følger Windows standard istedenfor å lage objektene manuelt. Dette er BRA! Men vi må ta en uke fra testing og sette det til utvikling SPRINT 6 82 Prosessrapport

83 Den siste sprinten har vi ryddet i koden og fått lagt inn grafer. Denne sprinten var i utgangspunktet ikke planlagt, men vi hadde regnet med at vi skulle kunne ta en uke fra testperioden til utvikling. Vi har nå et program som er funksjonelt og bra. Vi er meget fornøyd med resultatet. Android applikasjonen fungerer også meget bra. Den viser kun siste MEWS og lar deg registrere nye MEWS. 7.6 PARPROGRAMMERING Parprogrammering er en metode vi har brukt en del. Metoden bygger på at to personer jobber sammen om samme oppgave på en datamaskin. Vanlig praksis er at en skriver kode samtidig som den andre ser helheten og har oversikten. Dette er nyttig i kritiske systemer og øker kvaliteten på koden. Vi brukte denne metoden flere ganger gjennom prosjektet, mest under design prosessen. Da den ene visste hvordan skrive koden og den andre viste hvordan vi ønsket at det skal se ut. I tillegg brukte vi denne metoden når SignalR skulle legges inn i klientene og under feilsøking. Å jobbe i par likte vi veldig godt, det gjør at vi kan dele tanker og finne gode løsninger sammen. Det gjorde også at vi lærte hverandre hvordan ting fungerer samtidig som vi jobbet med oppgaven. Derimot var vi bare tre på gruppen som gjorde at kun en av oss kunne jobbe med en annen. 7.7 VIKTIGE VALG Gjennom prosjektet har man måtte ta valg som er avgjørende for videreutvikling og resultatet. Her kommer vi til å skrive litt om hvilke valg som var avgjørende og noe begrunnelse for valgene UTVIKLINGSMETODE Scrum ble valgt som utviklingsmetode. Grunnen til dette var at vi har hørt om det før og har noe kjennskap til utviklingsmetoden. Vi ville få erfaring med en utviklingsmetode som er i daglig bruk på flere arbeidsplasser. Scrum er også en smidigutviklingsmetode som er enkel å styre om man skulle måtte endre på noe kritisk under utviklingen BRUKERGRENSESNITT Vi valgte å bruke XAML (Extensible Application Markup Language) og C# som utviklingsspråk. XAML er Microsoft sitt programmeringsspråk for å programmere utseende på brukergrensesnittet. XAML er basert på XML som er veldig likt HTML, det 83 Prosessrapport

84 gjør det veldig lett å sette seg inn i. Vi valgte XAML da vi ønsket å lære mer om Microsoft sine utviklingsspråk. I tillegg ønsket vi at applikasjonen skal være så raskt som mulig da er C# raskere enn HTML/JavaScript som er et alternativ til XAML/C# ARKITEKTUR Vi startet tidlig i prosjektet med å velge hvordan arkitekturen skulle være, vi delte dermed koden inn i hvert sitt prosjekt. Et prosjekt kan inkluderes i et annet prosjekt som en ressurs. Det gjør at det er enklere å få oversikt og det er lettere å se hensikten med de forskjellige delene. Hvis noen skulle endre koden i et av prosjektene, har dette ingen påvirkning så lenge det er en innadrettet endring. Denne metoden gjør at det lett for oss å fordele oppgavene og oppdatere kode uten at vi påvirker hverandres Vi valgte også å lage et business lag for å ha muligheten for å kunne koble oss mot andre backend eller databaser enn MetaVision ANSVARSOMRÅDER Vi i gruppa ble tidlig enige om hvem som skulle ha hvilke ansvarsområder. Dette ble mye basert på hva vi selv var interessert i å lage. Vi vurderte også dette i forhold til hvilke evner den enkelte har. Figur 3.7 Planlagte ansvasområder Figur 3.7 viser ansvarsområdene i begynnelsen av prosjektet. Under utviklingen så vi flere ansvarsområder komme og Alexander var ofte den som ville ta tak i noe nytt. Tore jobbet med Windows 8 applikasjonen og Tommy med SignalR. Alexander jobbet med backendserver og Android. 84 Prosessrapport

85 Figur 3.8 Ansvarsområder Figur 3.8 viser ansvarsområdene i slutten av prosjekt perioden. Antall ansvarsområder er ikke proporsjonalt med tiden som er brukt på de forskjellige ansvarsområdene UTVIKLINGSMILJØ I begynnelsen av prosjektet måtte vi ta et valg om hvilket verktøy vi skulle bruke under utviklingen. Microsoft har laget Visual Studio, som er et verktøy som inneholder alt en utvikler kan ønske seg. Med det programmet hadde vi mulighet til å teste applikasjonen på maskinen direkte fra programmet eller på tablett via trådløstnettverk. Det er lett å versjons kontrollere koden og viktigst av alt, det har innebygget støtte for C# og WinRT. Vi var alle enige om at Visual Studio 2013 var utviklingsmiljøet vi skulle bruke. Les mer om våre erfaringer med Visual Studio i kapittel Når vi valgte å lage en Android applikasjon brukte Alexander Eclipse, da den har innebygd støtte for Android utvikling. Han koblet seg derimot ikke mot versjonskontroll da Eclipse ikke har støtte for team foundation server som standard. Les mer om våre erfaringer med Eclipse i kapittel SAMARBEID MED OPPDRAGSGIVERE OG LEVERANDØRER EVRY EVRY har vært tilgjengelig ved alle spørsmål, vi har hatt mye kontakt i møter og per mail. EVRY har hele veien vært meget interessert og fått bestemme hvordan ting bør være og hva som er forventet funksjonalitet. De har også vært behjelpelig med å skaffe kontaktene vi trenger for å kjøre brukertest og kontakte imdsoft som holder til i Israel. EVRY har også uttrykt at de ønsker at vi skal presentere programmet for en super arkitekt med mange års erfaring innen programmering. Han kan vurdere arkitektur og svakheter programmet kan ha. I tillegg har vi fått bruke deres nye lokaliteter på Fornebu som har veldig bra arbeidsforhold og kantine! 85 Prosessrapport

86 7.8.2 SYKEHUSET I ØSTFOLD Ved Sykehuset i Østfold testet vi produktet vårt på sykepleiere som var kjent med MEWS-registrering. Vi fikk en kontaktperson fra EVRY som de har brukt mye i kontakt med sykehuset, Marianne var meget stor hjelp for oss da hun svarte kjapt på alle spørsmål vi hadde om kliniske rutiner. Når vi skulle kjøre brukertester stilte Marianne opp med flere sykepleiere som var kjent med å bruke MEWS i sitt daglige arbeid. Når vi var på denne brukertesten fikk vi vite at det er planlagt å bytte ut MEWS med NEWS (MEWS med O2 metning). Dette er informasjon som vi ellers ikke ville fått. Det var en veldig nyttig og et hyggelig møte med sykepleierne som i mulig framtid vil bruke programmet vårt IMDSOFT imdsoft har vi ikke hatt noe direkte kontakt med bortsett fra over mail da vi prøvde å forstå hvordan vi skulle koble oss på MetaVision og etter hvert om vi fikk lov til å koble oss på dem. Siden disse holder til i Israel og vi hadde litt problemer med å formulere spørsmålene slik at de forsto dem tok det lang tid før vi fikk svar på det vi lurte på. Bortsett fra at det tok litt lang tid var imdsoft meget hjelpsomme og gjorde sitt beste får å bistå oss, selv om de ikke hadde tid til å undersøke hvordan påvirkning vår påkobling på deres database ville ha på trafikken mellom MetaVision og deres database. 7.9 RISIKOHÅNDTERING Når vi utarbeidet forprosjektrapporten skrev vi samtidig en risikoanalyse. Denne analysen viser hvor kritisk de forskjellige risiki har for prosjektets resultat og hvilke tiltak som kan benyttes. I vårt tilfelle var den største risiko tidsproblemer. Resultatene av tidsproblemer er misfornøyd kunde, i dette tilfellet er det EVRY. Det vil også påvirke dokumentasjonsfasen og vi får dermed levert en dårligere dokumentert oppgave. I vårt tilfelle har vi hatt et lite utslag av tidsproblemer og har bla. måttet nedprioritere enhetstesting av server og mulighet for flere språk i applikasjonene. Vi fikk heller ikke koble oss på MetaVision da imdsoft ikke hadde nok ressurser til å hjelpe oss med tilkoblingen. Se vedlegg D - Risikoplan for fullstendig risikoanalyse. 86 Prosessrapport

87 8 VURDERING AV TEKNOLOGI I dette kapittelet står det en del om hvilke teknologier vi har tatt i bruk i vårt prosjekt. Vurderinger vi har gjort og erfaringer vi har tilegnet oss gjennom prosjektperioden blir også reflektert. 8.1 WINDOWS STORE APPLIKASJON Windows 8 har blitt med på app-bølgen og har lansert sin egen Store. Gjennom denne får man tilgang til applikasjoner gjennom et enkelt brukergrensesnitt lik Apples App Store og Android sin Play Store (tidligere Market). Introduksjonen av Store har gjort at man nå kan utvikle tabletapplikasjoner til Windows tablets og pc samtidig. Det betyr at man under utviklingen må tenkte på at dette skal brukes både med mus og tastatur og touch skjermer. Store applikasjonene kjører i sandbox mode som betyr at applikasjonen ikke får tilgang til mer enn det som er angitt i applikasjonens metadata. Det å utvikle applikasjoner til Windows 8 har vært til tider krevende men veldig gøy. Mulighetene er enorme og kun fantasien setter grenser. Måten det skilles mellom det visuelle og programkode er innovativ og gjør utviklingen enklere for oss. Under utviklingen brukte vi mye tid på å forstå MVVM (Model-View View Model) modellen som Windows Store applikasjon bygger på. Vi har brukt MVC før men vi følte at MVVM var en helt annen verden. Etter veldig mange timer lesing og det å prøve å forstå hvordan det fungerte fikk vi det til. Noe kode hadde vi ikke tid til å endre på som resulterer i at noe backendkode setter inn visuelle objekter i Pasientsiden. Dette er dårlig kode praksis, men det betyr at det er forbedrings potensiale. 8.2 WINDOWS RUNTIME LIBRARY Windows Runtime Library(WinRT) er et bibliotek Microsoft har laget for å kunne jobbe med Windows 8 Store applikasjoner. Siden Store applikasjoner skal jobbe i sandbox mode kan man ikke gi tilgang til alle Win32 funksjonene, det er her WinRT kommer inn i bildet. WinRT gir tilgang til visse funksjoner i Win32 dermed begrenser tilgangen ved å ikke gjøre alle funksjoner tilgjengelig. Det er også viktig å bemerke at WinRT på ingen måte kan erstatte Win32. WinRT gir utvikleren tilgang til utvalgte Win32 funksjoner. WinRT er da et API som kobler Store applikasjonen mot Win32 API-et. Det betyr at så lenge WinRT jobber mot Win32, kan Win32 ikke fjernes. 87 Prosessrapport

88 Figur 3.9, Illustrerer sammenheng mellom Windows Store og Windows Kernel. Figur 3.9 gir en forenklet visning av hvordan Windows Store applikasjon henger sammen med WinRT og Win32, størrelser og farger er ikke relevant. 88 Prosessrapport

89 8.3 ANDROID APPLIKASJON I tillegg til Windows applikasjonen, utviklet vi en Android versjon. Denne ble lagd for å vise at systemet vårt kan levere på flere plattformer, vi ville prøve SignalR for Android og for at brukere skal få teste hvordan enhånds holdte enheter fungerer som registreringsterminal. Det var spennende og utfordrende å utvikle en Android applikasjon med SignalR ettersom det fremdeles var under utvikling til Android da vi begynte. Vi måtte selv hente ned hele prosjektet fra GitHub (filhåndterings system) og generere jar-filene derfra, vi måtte altså bygge biblioteket selv. 8.4 SIGNALR SignalR er et API som brukes for asynkron kommunikasjon mellom klient og server. Idag utvikles SignalR av Microsoft og flere lærebøker er tilgjengelig. Fordelen med SignalR er at det er open source og har en Apache 2.0 lisens som betyr at vi kan benytte oss av koden uten å tenke på kostnader i privat og kommersielt bruk. Eneste som må gjøres er å referere til SignalR sin lisensiering der man viser programlisensen til ditt egent program. SignalR er laget for C#, Java og JavaScript noe som gjør at det kan kjøre native i Windows, Java eller en nettleser som støtter JavaScript. Java versjonen gjør at SignalR kan brukes i Windows, OS X, Linux og Android. Det finnes også open source prosjekter som gjør det mulig å koble seg på SignalR med ios. SignalR har som mål å gjøre det lett å bruke for utvikleren. Utvikleren trenger ikke tenke på vanskelige punkter som; hvordan opprettholde kommunikasjon, hvordan kalle på klient fra server og hvordan sende data til spesifikke grupper. Alt dette er ferdig laget med gode bøker som tar for seg de fleste situasjoner. SignalR bruker teknologier som long poling og websockets for å kommunisere med klienten. Målet er at alt skal kommunisere via websockets, men ikke alle klienter støtter dette ennå. Derfor velger SignalR automatisk den beste måten å kommunisere på, slik at utvikleren kun forholder seg til SignalR sitt API. Vi har aldri brukt SignalR før, men veileder anbefalte at vi tok en titt på det. Det å jobbe med SignalR har vært en fryd, selv om dette har krevd mye tid til lesing og feilsøking. Resultatet er et oversiktlig og robust program som er enkelt å endre på og legge til ny funksjonalitet. For å lese mer om SignalR se nettsidene: Prosessrapport

90 8.5 OXYPLOT Høyskolen i Oslo og Akershus Etter noe leting etter et open source plottingsbibliotek kontaktet vi EVRY for å se om de hadde noe inhouse programvare. Det hadde de ikke, men de anbefalte oss å bruke OxyPlot. OxyPlot er et opensource plottingsbibliotek som er lisensiert under MIT lisens. Dette gjør at alle kan bruke OxyPlot fritt og endre hva man vil i koden. Dette betyr at vi kan bruke dette i den applikasjon som skal selges videre av EVRY. Biblioteket er basert på.net og er åpen for flere plattformer. Kjerne biblioteket er plattform-uavhengig, hvilket gjør det enkelt å bruke samme plotting kode på forskjellige.net plattformer. OxyPlot gir deg mulighet til å lage linjediagram og kakediagram, noe som vi har brukt på henholdsvis pasientsiden og avdelingssidene. Dette var ganske enkelt å sette seg inn i siden det var godt dokumentert på nettsiden til OxyPlot. Vi hadde derimot problemer når vil ville at grafene skulle oppdateres live, men med litt prøving og feiling fikk vi det til. 8.6 OPEN WEB INTERFACE FOR.NET (OWIN) OWIN definerer en standard kobling mellom webserver og webapplikasjonen. Siden vi programmerer funksjonaliteten i.net er man i utgangspunktet avhengig av en server som kjører Internett Information Services(IIS). Men med OWIN er man ikke lenger avhengig av IIS. Dette gjør at applikasjonen ikke er avhengig av en Windows Web Server for å kunne kjøre. I stedet blir det så lite som en enkel applikasjon. Dette betyr også at man kan kjøre serveren i Linux som er verdens mest brukte webserver OS. IIS har full støtte for OWIN som betyr at serveren fortsatt kan kjøres i IIS. Vi valgte å bruke OWIN da det gjorde det lettere å kjøre serveren under utvikling. Serveren blir da mer portabel, noe som er positivt. I dagens samfunn er det mange forskjellige systemer og man kan ikke regne med at alle bruker det samme systemet. Det er derfor naturlig å gjøre serveren så portabel som mulig, slik at man kan dekke størst mulig marked. Vi brukte en del tid på å få dette til å fungere da det er mange gamle forklaringer ute på nettet som ikke fungerte med siste versjon. I tillegg må man under oppsett velge om klienter fra andre maskiner skal få lov til å koble seg på SignalR. Dette tok tid, men etter at det fungerte har vi aldri opplevd problemer med OWIN. OWIN er lite, kompakt og enkelt å sette opp. 8.7 JSON JSON er en tekststreng som på en serialiserbar måte definerer objekter. På norsk betyr dette at strukturerte data kan sendes som tekst over nettverket. SignalR benytter seg av JSON når server og klient kommuniserer. Men, dette har ikke vi måttet tenke på, siden konvertering av data skjer automatisk både på server og klient siden. SignalR har rett og 90 Prosessrapport

91 slett gjort det usynlig, noe som gjør at vi har mindre å tenkte på. Det gjør SignalR ved å bruke Json.NET biblioteket JSON.NET Json.NET (tidligere kalt Newtonsoft.Json) serialiserer og deserialiserer.net objekter. Json.NET er open source og er opptil dobbelt så raskt som andre JavaScript biblioteker med samme funksjonalitet. Vi har kun opplevd et problem med Json gjennom hele prosjektet. Siden Json serialiserer objektene vil to objekter som peker på hverandre resultere i en løkke som aldri slutter. Dette fikset vi med å bytte pasient objekt med pasient id. 8.8 NLOG Det er krav om at alle data som blir hentet fra et EPJ system (les mer om EPJ i Produktdokumentasjon, Kapittel 4.1.2) skal loggføres, dette betyr at hver gang klienten går inn på en pasient eller registrerer noe om en pasient skal dette loggføres. Det er her NLog kommer inn. NLog er et open source prosjekt skrevet i C# som brukes til loggføring. I vårt tilfelle er NLog brukt til å logge enhver handling en klient ber serveren om å gjøre til et tekst dokument. NLog brukes også til å logge feilmeldinger som skulle forekomme på server. NLog er meget lite og var meget enkelt å bruke og konfigurere. Det er første gangen vi bruker et loggersystem. Det betyr at vi hadde noen problemer under oppsett. Men etter noen timers lesing var det klart hva som var feil og vi kunne enkelt sette opp logging til fil. 8.9 MICROSOFT TEAM FOUNDATION SERVER (TFS) Det er ikke første gang vi bruker Microsoft Team Foundation Server, og det er ikke uten grunn at vi valgte å bruke det igjen. TFS gjør prosjektarbeid mye enklere og problemfritt når man skal sette sammen hverandres arbeid. TFS er et versjonerings system som gjør at du enkelt kan sjekke at du utvikler på siste versjon. Vi har brukt en gratis online TFS på dette er gratis for inntil 5 utviklere. På TFS har man mer enn bare versjonerings av kildekode men også backlog og sprint oversikt. Dette gjør at det er enkelt å loggføre hva man har gjort og når funksjonalitet er programmert ferdig. Det er også enklere å ta en ny oppgave når man er ferdig med oppgavene man er tildelt. 91 Prosessrapport

92 Figur 3.10 Viser en scrum tavle Kort oppsummert, uten Team Foundation Server hadde vi aldri kommer så langt som vi har gjort VISUAL STUDIO Under utvikling brukte vi Microsoft sitt utviklerverktøy Visual Studio, her programmerte vi Windows 8 applikasjonen og server applikasjonen. Android applikasjonen ble laget i Eclipse. Vi brukte Visual Studio fordi dette er enkelt å bruke og Microsoft har bygget inn mye bra funksjonalitet, slik som NuGet package manager som vi bruker når vi skal laste ned ressurser. Laste opp ny versjon av kilde koden til TFS er enkelt, man høyre klikker og velger last opp. Og hvis der er versjons konflikter så vil man få opp et vindu der du kan løse konflikten. Muligheten for å velge Dark som tema gjør at man klarer å sitte lengere og kode, det er mindre stressende for øynene. Vi syns alle sammen at det å jobbe med Visual Studio har vært lett. Det blir også veldig gøy når ting fungerer så bra som det har gjort. 92 Prosessrapport

93 8.11 ECLIPSE Høyskolen i Oslo og Akershus Alexander hadde brukt Eclipse før, det ble derfor valgt som IDE da vi skulle utvikle Android klienten. Eclipse er et meget bra utviklingsverktøy for Java og Android. Eclipse er raskt og intuitivt og tilbyr Virtual Devices for å teste Android applikasjonen. I tillegg til dette har Eclipse også en XML Designer for å utvikle GUI til Android. Vi brukte denne designeren til å se hvordan applikasjonen ville se ut, men programmerte i XML for å gjøre de endringene som designeren ikke tilbyr. Ettersom vi var godt vant til Eclipse ga dette oss hurtigt resultater da vi begynte på utviklingen av Android klienten DROPBOX Vi har brukt Dropbox til å holde styr på dokumenter, diagrammer og installasjons filer. Siden alle på gruppa har god erfaring med Dropbox var det aldri noe spørsmål om hvordan dele dokumenter og filer. Dropbox synkroniserer en mappe på harddisken din med dropbox på nettet, det gjør at du alltid vil ha en type backup, hvis harddisken din skulle gå i stykker. Dropbox lagrer alle endringer som skjer i 30 dager. Det betyr at du kan hente slettede filer og eldre versjoner av filer du har synkronisert tidligere. Vi har aldri hatt problemer med Dropbox og er meget fornøyde med tjenesten de leverer. 9 VURDERING AV TEKNISK ARKITEKTUR I applikasjonene er det brukt flere typer arkitekturer. I serveren har man SignalR sitt system for å lage hubs, for å koble oss til database har vi business access layer og data access layer som bruker substitusjons prinsippet for å kunne koble seg til forskjellige web-apis eller databaser. I klienten bruker man MVVM arkitektur for å dele det visuelle og dataene. I dette kapittelet vil vi skrive om de forskjellige prinsipper og arkitekturer vi har tatt i bruk. 93 Prosessrapport

94 9.1 SERVER Å sette seg inn i SignalR som server modul har vært krevende, selv om det er meget enkel struktur. Måten man bygger SignalR var helt nytt for oss og krevde mye lesing og noen fag bøker var utdatert da ny versjon av SignalR var kommet. Men når systemet var oppe og kjørte var det meget lett å legge til ny funksjonalitet. Serveren er den delen som kobler seg til databasen, vi hadde fra starten planlagt å lage et business layer logic som tar seg av koblingen til de forskjellige systemene serveren skulle kunne koble seg til på et senere stadium. I første omgang ville vi koble oss på MetaVision. Men da dette ikke ble, koblet vi oss på en egen database isteden. Uten at server måtte endres, kun et nytt database access layer måtte lages. Vi ser nå at vi burde begynt tidligere med enhetstesting av server, da dette var både tidkrevende og krevde at vi satte oss inn i Moq. Vi fikk derfor bare testet UserHub på server, noe som er en av to hubs. Dette syns vi er dumt men det er andre ting som er viktigere å prioritere. 9.2 KLIENT WINDOWS 8 Alle hadde kunnskap om C# fra tidligere men ingen hadde vært noe særlig innom XAML. Siden Tore hadde lyst til å sette seg inn i dette startet han med å lese om dette i starten av prosjektet. Siden det ble avtalt at vi skulle ha en tidlig demo for EVRY ble det startet med å kode fra bunnen av, uten alt for god kunnskap om Windows 8 arkitektur og hvordan dette skulle settes opp. Vi fikk satt opp hele applikasjonen på feil måte før vi fant ut hva som var rett i henhold til Windows 8 sine retningslinjer. Dette tok lang tid siden Tore leste mens han utviklet, og fant bedre måter å programmere på etterhvert. Da vi hadde lest oss ferdig opp på dette bestemte vi oss for å endre arkitekturen slik at den ville følge Windows 8 standarden, og siden Tore var ferdig med å lese gikk dette fort. 94 Prosessrapport

95 Figur 3.11 Før og etter MVVM i ANDROID Det var kun Alexander som hadde drevet med Android utvikling før dette prosjektet. Da vi ikke fikk muligheten til å koble oss til MetaVision bestemte vi oss for å utvikle en Android applikasjon. Dette var for å vise at flere systemer kunne koble til serveren, for å gi brukerne muligheten til å teste hvordan det var å bruke mobil til å føre MEWS og fordi vi syntes SignalR var spennende og vil teste hvordan dette fungerte på Android. Det var en liten utfordring å bruke SignalR til Android ettersom dette fremdeles var under utvikling. Det var få eller ingen eksempler på hvordan dette burde implementeres. Derfor var det bra at Tommy hadde satt seg godt inn i SignalR, og sammen med Alexander fant de gode løsninger på kort tid. 9.3 DATABASE / DAL / BLL BLL laget fungerer egentlig som en fasade for å sende systemet til riktig system/databasetilkobling. systemet har lite logikk i dette laget, det er ment at bakenforliggende systemer skal håndtere sykehusets data, vi skal bare vise det frem lettere for brukeren. BLL en var derfor veldig enkel å skrive og vi hadde den klart veldig tidlig i utviklingsprosessen og den har ikke blitt endret veldig mye siden. Etterhvert som systemet får flere tilkoblingers klasser så må BLL en endres slik at man under installasjon av produktet kan velge bakenforliggende system. I utgangspunktet skulle vi skrive en tilkobling til MetaVision, men etter problemer fra imdsoft sin side (se Endring i kravspesifikasjonen ) fikk vi ikke lov til dette. Vi 95 Prosessrapport

96 måtte derfor endre arkitekturen sent i utviklingen. Vi valgte derfor å skrive et interface som kunne håndtere de metodene vi trengte mot ett bakenforliggende system. Vi har skrevet en testdatabase for å vise frem produktet og vise hvordan man skal bruke interfacet. Dette gjør at i teorien kan koble seg opp mot mange forskjellige systemer. Vi har flyttet en del av programmeringsjobben til utviklerne som skal integrere med sitt system. Vi føler at denne måten å gjøre det på fungerer veldig bra. Dette er en god abstraksjon og gjør mye mer fleksibel enn hva det i utgangspunktet var tenkt til å være. 96 Prosessrapport

97 10 VURDERING AV BRUKERGRENSESNITT Hensikten med oppgaven var å gjøre arbeidsdagen til sykepleiere enklere ved at de registrerer mews verdiene direkte inn i systemet uten å bruke Post-it lapper. Applikasjonen bør dermed være lett utformet som gjør det enkelt for sykepleiere å finne sine pasienter og registrere MEWS. Man må kunne få et raskt overblikk uten å måtte sette seg inn i og konsentrere seg om applikasjonen. Vi har brukt Windows Store applikasjon med XAML/C# for å lage brukergrensesnittet på Windows og Android SDK 12 for Android applikasjonen. Vi er meget fornøyd med hvordan utseende på applikasjonene. Vi har brukt OxyPlot for å vise MEWS over tid. OxyPlot er opensource og man er fri til å bruke det så mye man vil så lenge man forholder seg til MIT lisensen det er lisensiert med. Under har vi lagt til en figur som viser MEWS over en lengre periode. Figur 3.12: Mews graf for en test pasient. Det er lurt å bemerke at denne grafen ikke er et eksempel på pasient data men kun for å illustrere grafen. Så fort vi fikk grafer inn i applikasjonen så vi straks at applikasjonen hadde en funksjon. I stedet for å bare liste ut alle data så får sykepleieren alle data illustrert der det er lett å se hvordan det går for pasienten. Applikasjonen bruker stilrene farger, ser ryddig ut, luft mellom tekst gjør det lettere å lese under stressende forhold. Det bør nevnes at grønnfarget som er brukt som bakgrunn ikke alltid vises som den samme grønnfarget på forskjellige skjermer. Det ser ut til at skjermer på Windows Tablets har god fargegjengivning som gjør at fargen blir riktig. Bakgrunnen burde vurderes endret. 97 Prosessrapport

98 Ved å sette oss inn i MVVM strukturen fikk vi penere og raskere brukergrensesnitt. Det gjorde også at man kunne ta databehandlingen ut av viewet og kun konsentrere oss om det visuelle. 11 TESTING Vi har utført brukertest, enhetstest, systemtest og akseptansetest på. Vi føler selv at vi har fått testet produktet vårt meget godt. Videre følger en forklaring og konklusjon av alle testene som har blitt utført ENHETSTESTER Når det gjelder enhetstester skulle vi ønske at vi hadde mer tid til å teste hele serveren. Men da tiden ikke strakk til måtte vi kutte der det ikke var kritisk. Derfor valgte vi å teste BLL og DAL grundig. BLL laget ble testet ved å koble den opp mot en Stub istedenfor DAL laget. For å teste DAL laget og UserHub brukte vi Moq. Dette er et bibliotek for å mocke objekter som returnerer det vi spesifiserer. Her har vi en dekning på over 80% på hver av lagene. I API-laget testet vi kun UserHub klassen som har en dekning på 70%. Vi er godt fornøyd med dette resultatet BRUKERTEST EVRY gav oss tilgang til fem sykepleiere ved Sykehuset i Østfold som deltok på en brukertest Vi lagde en del spørsmål de måtte svare på i plenum, for å sikre at vi hadde forstått domenet. Etter det presenterte vi prosjektet og fortalte kort hvilke funksjoner programmet inneholdt. Deretter hadde vi skrevet noen oppgaver de måtte utføre på via tablet, pc og en Android enhet uten at de hadde fått noen innføring i systemet. Testerne fikk minutter til å utføre disse oppgavene og utforske systemet mens vi fikk se deres bruksmønster i applikasjonen. Det er viktig å presisere at vi ga dem ingen opplæring før de selv fikk prøve programmet. Vi loggførte feilmeldinger som oppstod, om de hadde problemer, om noe var vanskelig osv. Etter dette måtte hver tester svare på noen spørsmål angående bruksopplevelsen. Se spørsmål og resultater av brukertesten i Vedlegg I: Brukertest. Brukertesten var meget vellykket og lærerik. Vi fikk avdekket noen problemområder som ble fikset. Vi fikk gode tilbakemeldinger og alle testbrukere likte applikasjonen. De utførte oppgavene uten at opplæring var nødvendig. Dette gav oss en indikasjon på at vi hadde utviklet noe både vi og kunde var interessert i. 98 Prosessrapport

99 11.3 SYSTEMTEST Høyskolen i Oslo og Akershus Vi skrev en systemtest for å teste hele systemet sammen. Dette fungerte også som en Integrations test. Vi koblet flere enheter til server og utførte oppgaver skrevet av Alexander. Vi hadde også skrevet ned hva vi forventet skulle skje. Da vi utførte oppgavene loggførte vi hva som skjedde og sammenlignet. Les mer om testen i Vedlegg H - Systemtest. Vi valgte å kun teste Windows klienten ettersom det var lite tid og det er dette produktet som EVRY er mest opptatt av. Windows klienten bestod systemtesten uten problemer AKSEPTANSETEST Akseptansetest er en test som utføres av oppdragsgiver eller kunde, i dette tilfellet var det EVRY som hadde akseptansetesten. Akseptansetesten skal avdekke mangler og fortelle om systemet oppfyller de krav EVRY har satt i kravspesifikasjonen. Akseptansetesten var meget kort da EVRY hele tiden har vært med å bestemme hvordan ting skal fungere. De var dermed allerede kjent med det vi hadde laget. På det siste møtet med EVRY (28. April 2014) hadde vi en akseptansetest av applikasjonen. I møtet var Benny Andreassen og Nino Lo Cascio tilstede. EVRY var fornøyd med oppgaven, men de bemerket noen punkter. Når man legger inn ny MEWS lukkes registrer ny mews -vinduet. Tastatur med kun tall hadde vært ønskelig Annet enn dette hadde de ingen bemerkninger og var fornøyd med oppgavens resultat. Applikasjonen har ingen mangler annet enn at vi ikke har fått testet server med 20 forespørsler på en gang. Dette ble nedprioritert da vi hadde liten tid, men dette var ikke noe EVRY bemerket. Men systemet har vært stabilt under testing med 4 klienter koblet til. Se Vedlegg K: Evaluering fra EVRY for å se svarene på akseptansetesten. Svaret ble skrevet av Benny hos EVRY og levert til oss 15. Mai Generelt var de meget fornøyd med resultatet. 99 Prosessrapport

100 12 KONKLUSJON Høyskolen i Oslo og Akershus Totalt sett har vi nådd de målene vi har kunnet nå. Programmet fungerer og EVRY har en prototype som de kan vise til og videreutvikle hvis de ønsker det. Selv ønsket vi at programmet skulle kunne gå ut i produksjon ved slutten av prosjektet. Men resultatet er jo det vi ønsket; et program som gjør det lett for sykepleiere å registrere mews verdiene også regne ut deretter presentere verdiene og resultatene i en graf. Applikasjonen er brukbar gjennom en Windows tablet når legen går rundt til sengeposter. Innad i gruppa mener vi at vi kunne planlagt prosessen bedre, da hadde vi kommet lenger og kunne lagt til mer funksjonalitet. Vi hadde brukergrensesnittet godt planlagt og hadde ytterst få konflikter i gruppen om visuell utforming. Dette gjorde at vi aldri var i tvil om hvordan resultatet skulle være. I starten av prosjektet brukte vi mye tid på å lese om teknologier som vi kunne benytte. Etterhvert ble vi trygge på de forskjellige teknologiene og kunne forme det slik vi trengte det. Når vi ikke fikk koblet oss til MetaVision taklet vi dette på en god måte, og valgte naturligvis å fullføre uten MetaVision. Vi er meget fornøyd med prosjektet og er stolte over å ha kunnet lage disse applikasjonene. Dette hadde ikke vært mulig uten samtalene med EVRY og veileders oppfølging. 100 Prosessrapport

101 101

102 102

103 Høgskolen i Oslo og Akershus, våren 2014 Vedlegg 103

104 104

105 INNHOLDSFORTEGNELSE Vedlegg A: Brukerveiledning Veldegg B: Endelig Kravspeifikasjon Vedlegg C: Skisser og Skjermbilder Vedlegg D: Risikoplan Vedlegg E: Sekvensdiagrammer Vedlegg F: Use-Case Diagrammer Vedlegg G: Klassediagram Vedlegg H: Systemtest Vedlegg I: Brukertest Vedlegg J: MEWS skjema Vedlegg K: Evaluering fra EVRY Vedlegg L: Installasjons Guide Vedlegg

106 106

107 Høgskolen i Oslo og Akershus, våren 2014 Vedlegg A- Brukerveiledning 107

108 108

109 1. INNHOLDSFERTEGNELSE 2. Windows Koble til serveradresse Logge inn Logge ut Pasientliste Se en avdeling Se en pasient Navigering Pasient holder Avdeling Oversikt over MEWS på avdeling Pasient Pasient info MEWS graf Vitale Verdier graf MEWS Boks Registrere MEWS Android Koble til serveraddresse Logge inn Logge ut Pasientliste Se en pasient Navigering Pasient Pasient info MEWS Registrere MEWS

110 2. METAVIEW WINDOWS Dette kapittelet viser hvordan man skal bruke Windows klienten til for å utføre all funksjonalitet tilbyr. 2.1 KOBLE TIL SERVERADRESSE 1. Start applikasjonen. Da vil du komme til en innloggingsskjema. 2. Trykk på Innstillinger nede i høyre hjørne. 3. I tekstfeltet skriver du adressen til Serveren du vil koble til. Etter installering vil tilkoblingsstrengen være Denne vil koble til Server som går på samme maskin som Klienten om den finnes. Har adressen en sikker tilkobling er det viktig å skrive HTTPs. Tilkoblingsstrengen må bestå av + IP adresse+ :8080 der :8080 sier hvilken port Server finnes. 4. Trykk Lagre, deretter Koble til og kobler seg opp mot gitt adresse. Denne adressen vil bli lagret i applikasjonen. Du trenger derfor bare legge inn adressen en gang. 110

111 2.2 LOGGE INN Høyskolen i Oslo og Akershus 1. Etter at du har koblet deg til server fyller du inn brukernavn og passord. Om du kjører sin testserver kan du bruke Admin som brukernavn og Admin som passord Trykk Logg inn 3. Du skal nå være logget inn i 111

112 2.3 LOGGE UT Høyskolen i Oslo og Akershus Så lenge du er logget inn i vil du ha brukernavnet ditt synlig øverst i høyre hjørne. 1. Trykk på brukernavnet ditt. I vårt eksempel Admin 2. Her vil du få en nedtrekks-liste med en knapp Logg ut. 3. Trykk Logg ut. og du vil bli logget ut av MetaVision. 112

113 2.4 PASIENTLISTE Høyskolen i Oslo og Akershus Dette er hovedvinduet du kommer til etter at du har logget inn i. Dette vinduet viser en oversikt over alle pasienter brukeren har tilgang til, sortert etter avdelinger. Her kan du se og få adgang til avdelinger og pasienter. Nummer 4 viser brukermenyen SE EN AVDELING Ved å trykke på en avdeling som markert med nr. 1 på bildet over kommer du videre for å se informasjon om den avdelingen SE EN PASIENT Ved å trykke på en pasient får du oversikt over den gitte pasienten, markert med 2 på bildet over. Her kan du legge til MEWS NAVIGERING På tablet kan du gli med fingeren for å se flere pasienter og avdelinger som ligger til høyre. Hvis du sitter på en PC må du bruke Scrollbar nederst i vinduet markert med PASIENT HOLDER Hver pasient blir fremstilt som et rektangel der du kjapt kan få oversikt over pasienten med MEWS, sengenummer, kjønn og diagnose. Kjønn blir 113

114 markert med et ikon øverst i venstre hjørne. Er MEWS 3 eller høyere vil det vises ved en gul trekant med et utropstegn øverst i høyre hjørne. 2.5 AVDELING Dette skjermbildet gir deg en oversikt over alle pasienter på en avdeling. For å komme tilbake til pasientlisten trykker du på tilbakeknappen øverst i venstre hjørne markert med 2 i bildet under OVERSIKT OVER MEWS PÅ AVDELING Markert med 1 i bildet over vises et kakediagram som viser fordelingen av MEWS på avdelingen. Denne blir oppdatert live. 114

115 2.6 PASIENT Høyskolen i Oslo og Akershus Dette skjermbildet gir deg mer informasjon om den enkelte pasienten. For å komme tilbake til siden du var på tidligere trykker du på tilbakeknappen som er øverst i venstre hjørnet markert med 1 i bilde under, applikasjonene vil huske hvilken side du var i tidligere og navigere til den PASIENT INFO I feltet markert med 2 i bildet over får man listet opp all informasjonen om pasienten MEWS GRAF I feltet markert med 4 i bildet over får man vist MEWS. Her vil man få opp historikken over MEWS-registreringer for den pasienten man er inne på VITALE VERDIER GRAF I feltet markert med 5 i bildet over, under grafen av MEWS, vil man får opp en graf av Vitale verdier. Her blir historikken over pasientens respirasjonsfrekvens, puls, systolisk blodtrykk og temperatur listet opp i grafen MEWS BOKS I feltet markert med 3 i bildet over vil man få opp den MEWS-en som er sist registrert. I denne boksen vil man på toppen få scoringsverdien, midt i boksen får man listet de vitale verdiene og nederst får man opp datoen MEWS-en er registrert. 115

116 I feltet markert med 6 i bildet over vil man få opp historikk av MEWS-scoringer med nyligs fremst og første registrerte scoring sist i rekken. 2.7 REGISTRERE MEWS Dette skjermbildet gir deg mer informasjon om hvordan man registrere MEWS på den enkelte pasienten. Ved å trykke på knappen Legg til MEWS markert med 1 vises det et vindu (markert 2) der man skriver inn vitale verdier for pasienten og velger en CNS fra dropdown menyen. Alle verdier må være innenfor gyldige verdier og CNS valgt for å få registrert MEWS. Registrer verdiene inn i systemet ved å trykke på "Lagre Mews" nederst i skjema. 116

117 3.METAVIEW ANDROID Dette kapittelet viser hvordan man gjør de vanligste oppgavene på Android tilbyr. Merk at Android 1.0 ikke tilbyr like bred funksjonalitet som Windows 1.0, man får ikke MEWS historikk eller grafer. trenger internett tilkobling. Og vil be bruker om å skru på trådløstnettverk under oppstart, blir den ikke slått på vil applikasjonen terminere etter å viste en beskjed. 3.1 KOBLE TIL SERVERADDRESSE 1. Trykk på Android enheten sin meny/settings knapp. 2. Du vil få en meny i applikasjonen som tilbyr Settings og Reconnect. Trykk Settings. 3. Applikasjonen ber deg skrive inn en adresse. Husk HTTPS hvis du skal koble til en sikker tilkobling. Applikasjonen viser standard Skriv inn IPadressen etterfulgt med port nummer. Eks Trykk Ok 4. Trykk Reconnect og applikasjonen vil logge seg på. 3.2 LOGGE INN 1. Fyll inn brukernavn og passord i gitte felter. 2. Trykk Sign in. Vises ikke denne knappen er du ikke koblet til server. Gjør 4.1. Er du koblet til sin test server. Kan du bruke Admin som brukernavn og passord. 3. Du skal nå være logget inn. 3.3 LOGGE UT Så lenge du er logget inn i kan du logge ut. 1. Trykk på Android enheten sin meny/settings knapp. 2. I menyen velg Sign out 3. Da vil du få spørsmål om du vil logget ut. Trykk Ok 4. Du skal nå være logget ut av MetaVision. 117

118 3.4 PASIENTLISTE Høyskolen i Oslo og Akershus Så fort du har logget inn kommer du til et skjermbilde som viser alle pasienter. Hvert listeelement viser pasientens navn, kjønn i form av et ikon, hvilken seng de ligger på og hvilken MEWS de sist er registrert med. I bildet til høyre vises pasientens MEWS med fargekoder fra grønn mot rød, grønn er bra og rød er dårlig SE EN PASIENT For å se informasjon om en gitt pasient. Trykk på pasienten du vil se NAVIGERING Navigerer i listen ved å føre fingeren over skjermen. Bruk menyknappen på enheten til å logge ut. Om du trykker på tilbake knapp når du er i pasientliste vil du bli spurt om du vil logge ut. 3.5 PASIENT Dette skjermbildet viser all informasjon om en pasient PASIENT INFO Øverst vises generell pasientinformasjon, personnummer, sengenummer, ankomstdato og innleggelsesgrunn MEWS Så lenge det er registrert en MEWS på pasienten vil den siste registrerte MEWS-en vises. I bildet til høre vises skåringen og parameterne med fargekoder. 3.6 REGISTRERE MEWS Registrering av MEWS kan kun skje på en pasient. 1. Trykk Registrate MEWS knappen i vinduet eller menyknappen og velg Registrate MEWS. 2. Du vil da få et skjema du må fylle ut. Når MEWS-verdiene er skrevet inn trykker du Registrate. Har du skrevet inn ulovlige verdier vil du få beskjed om dette nå. 3. Du har nå registrert en MEWS. 118

119 VEDLEGG B KRAVSPESIFIKASJON METAVIEW BACHELOROPPGAVE VÅREN 2014 GRUPPE

120 1. PRESENTASJON Tittel: Oppgave: Lage en applikasjon og API som skal kommunisere med MetaVision slik at det skal bli enklere for leger og sykepleiere å ha deler av MetaVision tilgjengelig ute på poster. Gruppemedlemmer: Tore Angell Petersen Alexander Bakke Tommy Kihlstrøm Prosjektgruppe: Gruppe 29 Veileder: Simen Hasselknippe Oppdragsgiver: EVRY AS Kontaktperson: Nino Lo Cascio Tlf: Forord Kravspesifikasjonen beskriver oppdragsgiver, bakgrunn for prosjektet og prosjektplass i oppdragsgivers framtidsplaner. Den skal gi en oversikt over fremgangsmåten som skal brukes ved utviklingen av api-et som skal koble MetaVision sammen med vår applikasjon til nettbrett bruk. Videre skal den gi utvikler og oppdragsgiver en forståelse av systemet og funksjonaliteten til nettbrettapplikasjonen som utvikles. 3. BAKGRUNN EVRY er Norges største og Nordens nest største IT-selskap. De har ansvaret for om lag en tredel av alle ITtjenesteleveranser i Norge og har dermed et stort antall kunder både i offentlig sektor og privat næringsliv, som for eksempel: DnB, Telenor, Posten Norge, Sparebank 1 Gruppen, Statoil, Hydro, REC, Storebrand, Gjensidige, Oslo kommune, Trondheim kommune og NAV. Gruppe 29 skal skrive hovedoppgave som avslutning på tre-årig bachelor program på Data-linjen ved HiOA. Vi har fått i oppgave å lage en applikasjon som gjør MetaVision mer tilgjengelig fra nettbrett. Vi skal lage en Windows 8 applikasjon som kan vise MEWS, samt et API som gjør at man kan hente data fra MetaVision. 120 Vedlegg B - Kravspesifikasjon

121 4. LESERVEILEDNING Hensikten med dette dokumentet er å forklare i dybden hvilke krav som arbeidsgiver har og vise hva slags funksjonalitet vi kommer til å implementere. For å lese dette dokumentet bør du ha grunnleggende kunnskap om begreper innen dataprogrammering. Flere begreper blir forklart i del 9. Dataordbok sist i dokumentet. 5. KORT SYSTEMBESKRIVELSE MetaVision er et verktøy laget av imdsoft. Dette er ment for å digitalisere lege- og sykepleierhjelp på sykehus og er et stort system som logger verdier på pasienter, regner ut formler for leger og sykepleiere, og lagrer data om pasienter (og mye mer). Systemet er meget omfattende og innholdsrikt, og kan dermed være vanskelig å bruke for sporadiske brukere eller i spesifikke, gjerne mobile, kontekster. Det kreves kursing for å ta i bruk MetaVision, og tid og erfaring med systemet for å utnytte dets potensial. Hensikten med den nye applikasjonen er: Å gjøre en liten del av MetaVision mer intuitiv og enkel å bruke for sykepleiere og leger. Kvalitet i pasientbehandling og understøtte helhetlig pasientforløp. Starte å utvikle et API for Windows 8 applikasjoner som utnytter MetaVision. Øke effektivitet for sykepleiere og leger. 6. RAMMEKRAV Tidsrammen på prosjektet er , tilsvarende 21 uker. 7. SYSTEMKRAV 7.1 KUNDENS KRAV TIL FUNKSJONALITET Kundens grunnleggende krav er at applikasjonen kan skrive og hente data fra MetaVision. Et API som sørger for at MetaVision og Windows 8 applikasjoner snakker sammen. Samt at applikasjonen er brukervennlig. Hente ut pasienter og informasjon om pasienter som er lagret i vårt system. Velge en pasient og se deres MEWS. Legge inn verdier til pasientens MEWS. 121 Vedlegg B - Kravspesifikasjon

122 7.2 FUNKSJONELLE KRAV Kunden ønsker mer funksjonalitet, men det er viktig for dem at de får et fungerende API mot MetaVision og en Applikasjon som kan videreutvikles. Skal: Bør: Sykepleiere skal kunne logge inn. Skal vise en liste over pasienter i systemet. Skal kunne velge en pasient og få deres opplysninger. Skal kunne vise en pasient sin puls. Skal kunne vise en pasient sitt blodtrykk. Skal kunne vise en pasient sin pustefrekvens. Skal kunne vise en pasient sin kroppstemperatur. Skal kunne vise en pasient sitt nivå av bevissthet Skal kunne vise en pasient sin MEWS. Skal kunne legge til verdier for pasientens blodtrykk. Skal kunne legge til verdier for pasientens pustefrekvens. Skal kunne legge til verdier for pasientens kroppstemperatur. Skal kunne legge til verdier for pasientens nivå av bevissthet. Systemet skal tåle 20 forespørsler om gangen. Bør kunne sammenligne verdier for flere pasienter. Bør kunne vise vitale verdier via grafer over pasientens opphold. Bør kunne justere tidsskalaen på grafer. Bør kunne lage en liste over Mine pasienter for en gitt bruker. Applikasjonen bør støtte flere språk, Norsk, Engelsk. 7.3 TEKNISKE KRAV Applikasjonen skal utvikles i C# og XAML Applikasjonen skal kjøres på Windows 8.1 Applikasjonen skal kunne kjøres på Windows Nettbrett og pc (Windows 8.1). 7.4 Brukbarhetskrav Man skal ikke trenge mer enn 1 times kursing. Det skal ikke være mer enn 3 klikk for å gjøre enkle oppgaver. Ikoner og bilder skal gi mening. 7.5 KRAV TIL KODEN Koden skal være ryddig, gi mening og være godt kommentert. Applikasjonen og server skal være lagdelt og være lett å vedlikeholde. Koden skal bruke Camel Case. Alle metoder skal ha selv-forklarende navn. 122 Vedlegg B - Kravspesifikasjon

123 Koden skal skrives på Engelsk. Utviklings-team har ansvar for koden frem til levering av prosjektet. Dette gjelder sikring, tap, ødeleggelse og tyveri. 7.6 DESIGNKRAV Kunde har få spesifikke designkrav. Generelt skal applikasjonen Være intuitiv og prosess-støttende. Kunne benyttes i en sengepost-kontekst. Ikke kun inneholde farger som informasjonsbærer. Applikasjonen skal følge Windows 8 sitt brukermønster og krav. Skal følge Microsoft design Guidelines. 7.7 DOKUMENTASJONSKRAV Det skal skrives en brukermanual for produktet. God dokumentasjon på kode og prosjektarbeid. Hver klasse skal forklares i kommentarfelt øverst i kildekoden. Skal skrives logg for hver dag gruppen jobber. Prosjektdokumentasjonen skal leveres til kunde senest API-et skal dokumenteres godt og vise eksempler på bruk av koden. 7.8 TESTKRAV Applikasjonen må bestå en brukertest. Prosjektet skal være unit-testet. Applikasjonen skal bestå en akseptansetest av kunde. Systemet skal tåle 20 forespørsler av gangen. 8. FREMTIDIGE UTVIDELSER Kritiske utvidelser Hente ut pasienter og informasjon om pasienter fra MetaVision. Kunden har flere ønsker på utvidelser av applikasjonen. Lage en Android applikasjon, med samme/likende funksjonalitet. Ønske om å legge til flere skårings algoritmer slik at man har frihet til å velge eller sammenligne resultater fra de forskjellige algoritmene. Ønske om å kunne vise pasientens medisiner. Ønske om å vise logg på hva pasienten har fått av medisiner. Ønske om å vise og loggføre pasientens væskeinntak og uttak. 123 Vedlegg B - Kravspesifikasjon

124 9.DATAORDBOK Høyskolen i Oslo og Akershus METAVISION MetaVision er et verktøy laget av imdsoft, for å digitalisere legehjelp på sykehus MEWS Modified Early Warning Score, er en guide for leger og sykepleiere for å avgjøre hvor syk en pasient er. API Application Programming Interface, er et grensesnitt i en programvare, slik at andre programmer kan kjøre deler av programmet, hente data osv. C# Er et objekt orientert programspråk laget av Microsoft. Basert på C++ og Java. XAML Extensible Application Markup Language, er et språk for å lage det grafiske utseendet til applikasjonen. Bruker samme syntax som XML. CAMELCASE Er en praksis for hvordan bestemme navn på metoder og variabler i programmering. Hvert ord starter med stor bokstav, men første er liten. Eks. first name blir firstname. MICROSOFT DESIGN GUIDELINES Er retningslinjer fra Microsoft på hvordan man skal designe/skrive biblioteker, applikasjoner mm. BRUKER-TEST Er en evaluering der man observerer og analyserer hvordan funksjoner i en løsning blir brukt av faktiske brukere - Wikipedia. UNIT-TESTING En automatiskmetode for å teste metoder i kildekode for å se at inn-data og ut-data stemmer i forhold til hva metoden skal gjøre. 124 Vedlegg B - Kravspesifikasjon

125 AKSEPTANTSE-TEST Høyskolen i Oslo og Akershus Er en test som utføres for å avgjøre om et produkt oppfyller kundens behov, og stemmer overens med spesifikasjonen og annen dokumentasjon. Blir ofte utført av kunden 125 Vedlegg B - Kravspesifikasjon

126 126

127 Høgskolen i Oslo og Akershus, våren 2014 Vedlegg C Skisser og Skjermbilder 127 Vedlegg C Skisser og Skjermbilder

128 SKISSER VERSJON 1 Her er de aller første skissene som ble tegnet. Tanken var at alt skulle være tilgjengelig fra forsiden. Arkene bortover viser da hva du finner når du skråler bortover siden. 128 Vedlegg C Skisser og Skjermbilder

129 Fortsettelse av side 1. Høyskolen i Oslo og Akershus 129 Vedlegg C Skisser og Skjermbilder

130 Fortsettelse av side 2. Høyskolen i Oslo og Akershus 130 Vedlegg C Skisser og Skjermbilder

131 Høyskolen i Oslo og Akershus SKISSER VERSJON 2 Dette er pasient siden. Her er siden som viser pasient oversikten. 131 Vedlegg C Skisser og Skjermbilder

132 DETTE ER BILDER FRA APPLIKASJONEN SLIK DEN BLE LAGET Her har vi splash screen som vises ved oppstart av applikasjonen. Her har vi Logg inn siden der applikasjonen prøver å koble til serveren. 132 Vedlegg C Skisser og Skjermbilder

133 Her viser vi at applikasjonen ikke får kontakt med serveren og viser feilmelding. Her viser har man trykket på tannhjulet nede i høyre hjørne for å få fram innstillinger der man kan ender server adresse slik at man kan koble seg på serveren. 133 Vedlegg C Skisser og Skjermbilder

134 Her har man rett server adresse og bilde viser at man er tilkoblet. Dette om man kom fra sist bilde trykte man på koble til som vist i bilde på siden før. Her viser man hva som skjer når man prøver å koble til. 134 Vedlegg C Skisser og Skjermbilder

135 Her får man opp feilmelding når man enten har feil brukernavn og/eller passord, eller ikke noe brukernavn og/eller passord. Her har bruker logget inn med korrekt informasjon og får vist listen av pasienter. 135 Vedlegg C Skisser og Skjermbilder

136 Her ser vi en av de siste skissene vi lagde på hvordan Pasientlisten var tenkt. Her holder brukeren muspekeren over ene brukeren og man ser at den blir uthevet men en kant rundt. 136 Vedlegg C Skisser og Skjermbilder

137 Her holder brukeren over Menyknappen med brukernavnet til brukeren. Her har bruker trykket på menyknappen og får fram Logg ut muligheten. 137 Vedlegg C Skisser og Skjermbilder

138 Her har bruker trykket på overskriften til vær avdeling og kommet inn til oversikten til avdelingen. Her viser et kakediagram oversikten over MEWS på avdelingen. Her holder bruker musepekeren over en pasient og den pasienten blir uthevet med en kant rundt. 138 Vedlegg C Skisser og Skjermbilder

139 Her har bruker trykket på menyen for å vise Logg ut knappen. Her har bruker trykket seg inn på en pasient. Her får vi fram informasjon om pasienten til venstre, så ser man siste MEWS, så kommer grafene og helt til høyre ser man begynnelsen på historikken. 139 Vedlegg C Skisser og Skjermbilder

140 Her har vi en av de siste skissene om hvordan pasient siden var tenkt. Her ser vi at bruker begynner å bevege seg inn i historikken til pasienten. 140 Vedlegg C Skisser og Skjermbilder

141 Her har bruker beveget seg så langt inn i historikken at man ikke ser grafene lengere. Her ser vi at bruker prøver å legge til en ny mews på pasienten. 141 Vedlegg C Skisser og Skjermbilder

142 Her får vi feilmelding på at blodtrykk må være et tall. Feilmelding om at respirasjonsfrekvens må være tall. 142 Vedlegg C Skisser og Skjermbilder

143 Feilmelding om at Respirasjonsfrekvens på være under 100 Feilmelding om at blodtrykket må være under Vedlegg C Skisser og Skjermbilder

144 Feilmelding om at puls må være et tall. Her ser vi at det blir lagt inn MEWS. 144 Vedlegg C Skisser og Skjermbilder

145 Feilmelding om at puls må være under 250. Feilmelding om at temperatur må være under Vedlegg C Skisser og Skjermbilder

146 Feilmelding om at temperatur må være over 20. Her har bruker trykket på uttrekkslisten av alle mulige CNS verdier. 146 Vedlegg C Skisser og Skjermbilder

147 Her har bruker lagt til 2 nye MEWS-scoringer slik at grafene og siste MEWS er oppdatert. Her ser vi at bruker forandrer på tidspunkt grafene skal vise. 147 Vedlegg C Skisser og Skjermbilder

148 Her ser vi at bruker «zoomer» på verdiene og tidsaspektet. 148 Vedlegg C Skisser og Skjermbilder

149 Her ser man hvordan applikasjonen starter når du har installert den for først gang. Da må man inn å legge til server adresse. 149 Vedlegg C Skisser og Skjermbilder

150 Her ser man menyen som kommer opp når bruker trykker på meny knapp på sin telefon. 150 Vedlegg C Skisser og Skjermbilder

151 Her ser vi bruker velger server adresse. 151 Vedlegg C Skisser og Skjermbilder

152 Her ser vi logg inn skjermen på android applikasjonen. 152 Vedlegg C Skisser og Skjermbilder

153 Her ser vi logg inn med informasjon puttet inn. 153 Vedlegg C Skisser og Skjermbilder

154 Her har bruker logget inn og applikasjonen lister ut alle pasienter. 154 Vedlegg C Skisser og Skjermbilder

155 Her har brukeren trykket på en spesifikk pasient og vi ser informasjon om pasienten. 155 Vedlegg C Skisser og Skjermbilder

156 Her ser vi bruker skal legge til en MEWS-scoring på pasienten. 156 Vedlegg C Skisser og Skjermbilder

157 Her ser du at bruker har brukt meny mulighetene for å logge ut så får du spørsmål om å logge ut. 157 Vedlegg C Skisser og Skjermbilder

158 158

159 Høgskolen i Oslo og Akershus, våren 2014 Vedlegg D - Risikoanalyse 159

160 RISIKOMOMENTER LANGTIDS SYKEMELDT Risikonivå: 6 Sannsynlighet: Lite sannsynlig, Konsekvens: Betydelig Konsekvens: Mister verdifull arbeidskraft Hvordan respondere: Fordele arbeidsoppgavene mellom andre gruppemedlemmer. Fjerne mindre viktige deler fra oppgaven. FEILKOMMUNIKASJON MELLOM UTVIKLERE Risikonivå: 12 Sannsynlighet: Sannsynlig, Konsekvens: Betydelig Konsekvens: Kan oppstå feil i kode, og at funksjoner ikke jobber sammen som de skal. Hvordan respondere: Avklare hvordan hver enkelt har forstått oppgaven, altså angripe feilen ved roten. Deretter rette feilen. TAP AV DATA Risikonivå 6 Sannsynlighet: Lite sannsynlig, Konsekvens: Betydelig Konsekvens: Mye ekstra arbeid, der man må gjøre ting om igjen Hvordan respondere: Hente ut den siste backup av data, og raskt hente seg inn derfra. TIDSPROBLEMER Risikonivå 16 Sannsynlighet: Sannsynlig, Konsekvens: Alvorlig Konsekvens: Misfornøyd kunde Hvordan respondere: Melde fra til arbeidsgiver så fort vi ser at det er en forsinkelse. Og sette av mer tid til prosjektet og eliminere mindre viktige deler fra oppgaven. 160 Vedlegg D - Risikoanalyse

161 OPPSIGELSE AV KONTAKTPERSON Risikonivå: 6 Sannsynlighet: Lite sannsynlig, Konsekvens: Betydelig Konsekvens: Mister verdifull kontaktperson. Hvordan respondere: Skaffe ny kontaktperson, den tidligere kontakt personen kan ofte være behjelpelig. IKKE TILGANG TIL SYSTEM Risikonivå: 8 Sannsynlighet: Lite sannsynlig Konsekvens: Alvorlig Hvordan respondere: Lage eget system å koble seg på. TILEGNE SEG FEIL KUNNSKAP Risikonivå: 4 Sannsynlighet: Lite sannsynlig Konsekvens: Mindre alvorlig Hvordan respondere: Skaffe seg riktig kunnskap HARDWARE SLUTTER Å FUNGERE Risikonivå: 6 Sannsynlighet: Mindre sannsynlig Konsekvens: Mindre alvorlig Hvordan respondere: Få reparert eller skaffe alternativ hardware. MISLYKKET ORGANISERING Risikonivå: 8 Sannsynlighet: Sannsynlig Konsekvens: Mindre alvorlig 161 Vedlegg D - Risikoanalyse

162 Hvordan respondere: Om organisere og prøve å gjøre det riktig denne gangen. FORSINKELSER FRA OPPDRAGSGIVER Risikonivå: 12 Sannsynlighet: Sannsynlig Konsekvens: Betydelig Hvordan respondere: Mase på oppdragsgiver. 162 Vedlegg D - Risikoanalyse

163 VISUELL FORKLARING AV RISIKONIVÅENE Høyere tall betyr høyere negativ virkning på prosjektflyten. 1 er ubetydelig og 20 er en meget betydelig. Grønn farge betyr liten på virkning, gul betyr middels påvirkning og rød er kritisk påvirkning. Meget sannsynlig Sannsynlig Mindre sannsynlig Lite sannsynlig Usannsynlig Ubetydelig Mindre alvorlig Betydelig Alvorlig Vedlegg D - Risikoanalyse

164 164

165 Høgskolen i Oslo og Akershus, våren 2014 Vedlegg E- Sekvensdiagrammer 165

166 Dette sekvensdiagrammet viser flyten av innloggingen av en bruker i fra klient til server. Brukernavn og passord blir sendt gjennom hele systemet for så å logge inn i et bakenforliggende system. DAL laget vil ha en tilkobling til en Database eller system. Sekvensdiagram over innlogging i 166 Vedlegg E - Sekvensdiagrammer

167 Dette sekvensdiagrammet viser flyten av registrering av en ny MEWS i. Verdier blir ført inn på klient og sendt videre gjennom systemet. Det skjer en direkte update til alle klienter når server får MEWS. Skjer det en feil med registreringen behandler serveren dette og gir beskjed til bruker. Sekvensdiagram over registrering av en MEWS i 167 Vedlegg E - Sekvensdiagrammer

168 168

169 Høgskolen i Oslo og Akershus, våren 2014 Vedlegg F- Use-Case diagrammer 169

170 BRUKER LOGGER INN I METAVIEW Use-case diagram som viser en bruker som logger inn i. Use case Aktør Sekundær aktører Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Variasjoner Bruker logger inn i Bruker som vil bruke. Server, Database/Hovedsystem. Bruker ønsker å logge inn i Brukeren må være en gyldig bruker og være ført inn i Databasen/Hovedsystemet. Klienten må være koblet til en server. Bruker har blitt logget inn i. Bruker skriver inn brukernavn. Bruker skriver inn passord. Bruker trykker på login-knappen og bruker blir logget inn i systemet. Brukernavnet er feil. Passordet er feil. Klient mister kontakt med server. Server får ikke kontakt med bakenforliggende system. 170 Vedlegg F Use-Case diagrammer

171 BRUKER REGISTRERER EN MEWS I METAVIEW Use-case diagram som viser en bruker registrere en MEWS på pasient. Use case Aktør Sekundær aktører Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Variasjoner Bruker registrerer en MEWS i Innlogget bruker. Server, Database/ Hovedsystem. Bruker ønsker å registrere en MEWS på en pasient. Bruker må ha tilgang til pasienten. Bruker har fått registrert en MEWS i bakenforliggende system. Bruker velger en pasient. Bruker trykker «Legg til MEWS». Bruker fyller inn verdier i MEWS-vinduet. Bruker trykker «Lagre MEWS» og bruker får se den nye MEWS-en. Parameterne som bruker har angitt er feilaktige eller mangelfulle. Mister kontakt med Server. Bakenforliggende system godtar ikke registreringen. 171 Vedlegg F Use-Case diagrammer

172 172

173 Høgskolen i Oslo og Akershus, våren 2014 Vedlegg G- Klassediagram 173

174 174

175 KLASSEDIAGRAM OVER METAVIEW SERVER Her vises et Klassediagram over hele serversystemet. Klassediagrammet viser de forskjellige lagene og hvilke klasser som er koblet opp mot hverandre. Klassediagram over Server. 175 Vedlegg G - Klassediagram

176 176

177 Høgskolen i Oslo og Akershus, våren 2014 Vedlegg H - Systemtest 177

178 178

179 System test MetaVision WINDOS APPLIKASJON Oppgave Forventet resultat resultat Innloggings-skjerm Starte applikasjon uten tilkobling. Starte applikasjon med tilkobling Starte applikasjon med tilkobling uten at server er oppe. Logge inn med riktig brukernavn og passord Logge inn med riktig brukernavn og feil passord Logge inn med feil brukernavn Logge inn uten å skrive i feltene Logge inn med tomt brukernavnfelt Logge inn med tomt passordfelt Skal få beskjed om at klient er frakoblet server. «Logg inn» - knappen skal bli en «Tilkobling»- knapp. Klienten skal koble seg opp mot server og vise en «Login» -knapp Skal få beskjed om at client er frakoblet server. «Logg inn» - knappen skal bli en «Tilkobling» - knapp. Brukeren skal da bli guidet til neste skjerm som viser en liste av avdelinger med pasienter. Skal få beskjed om at det er feil brukernavn og passord Skal få beskjed om at det er feil brukernavn og passord Skal få beskjed om at feltene ikke er fylt ut Skal få beskjed om at brukernavnfeltet ikke er fylt inn Skal få beskjed om at passordfeltet ikke er fylt inn Får beskjed om at man ikke får kontakt og logg-inn-knapp blir tilkoblings-knapp Får mulighet til å logge inn og logginn knappen vises. Får server Connection time-out. Må trykke ok og det vises tilkoblingsknapp. Når man trykker logg-inn kommer det frem et ventehjul helt til man blir sendt til neste vindu på svar fra server. Får beskjed om at brukernavn eller passord er feil. Får beskjed om at brukernavn eller passord er feil. Får beskjed om at brukernavn eller passord er feil. Får beskjed om at brukernavn eller passord er feil. Får beskjed om at brukernavn eller passord er feil. 179 Vedlegg H - Systemtest

180 Pasientliste-skjerm Velge en pasient ved å trykke på den med musen Velge en pasient ved å bruke touch-skjerm Logge ut ved hjelp av brukermenyen Dra gjennom listen ved hjelp av slider. Bruke musen til å dra slideren nederst i skjermen får å se mer av pasienten. Se flere pasienter ved å dra fingeren over skjermen Velge en avdeling ved å trykke på avdelings navnet. Legge inn en mews på en pasient fra en annen enhet og se at den blir oppdatert live. Skal bli guidet til Pasientinfoskjerm. Der pasientens informasjon skal være utfylt. Skal bli guidet til Pasientinfoskjerm. Der pasientens informasjon skal være utfylt. Skal se Innloggings skjermen. Der brukernavnet skal stå i feltet og tomt passordfelt. Listen av pasienter skal bevege seg slik at man ser «gjemte» pasienter. Forutsatt at det er nok pasienter til å flyte ut av skjermen. Listen av pasienter skal bevege seg slik at man ser «gjemte» pasienter. Forutsatt at det er nok pasienter til å flyte ut av skjermen. Skal se Avdelings-skjermen. Skal få informasjon på skjermen, deretter skal verdiene endres på gitt pasient Når man trykker på en pasient så blir man sendt til pasientens side der alt av info på pasienten er oppdatert. Når man trykker på en pasient så blir man sendt til pasientens side der alt av info på pasienten er oppdatert. Blir logget ut og blir sendt til logginn side der passordfeltet er tomt og brukernavnet står i brukernavnfeltet. Listen av pasienter beveger seg slik at man ser pasientene som ikke fikk plass på vinduet når siden ble vist i starten. Listen av pasienter beveger seg slik at man ser pasientene som ikke fikk plass på vinduet når siden ble vist i starten. Ser avdelingsskjermen med pasientene på valg avdeling. Man ser at pasienten forsvinner før den kommer tilbake med oppdatert mews. Avdelings-skjerm Kunne finne ut hvor mange pasienter som er på avdelingen ved hjelp av kake graf Velge en pasient ved å trykke på den med musen Tallet på kaken skal stemme overens med hvor mange pasienter som blir vist. Skal bli guidet til Pasientinfoskjerm. Der pasientens informasjon skal være utfylt. Vises ikke antall av pasienter, viser bare % av pasienter som har forskjellig mews. Når man trykker på en pasient så blir man sendt til pasientens side der alt av info på pasienten er oppdatert. 180 Vedlegg H - Systemtest

181 Velge en pasient ved å bruke touch-skjerm Logge ut ved hjelp av brukermenyen Dra gjennom listen ved hjelp av slider. Bruke musen til å dra slideren nederst i skjermen får å se mer av pasienten. Se fler pasienter ved å dra fingeren over skjermen Skal bli guidet til Pasientinfoskjerm. Der pasientens informasjon skal være utfylt. Skal se innloggings skjermen. Der brukernavnet skal stå i feltet og tomt passordfelt. Listen av pasienter skal bevege seg slik at man ser «gjemte» pasienter. Forutsatt at det er nok pasienter til å flyte ut av skjermen. Listen av pasienter skal bevege seg slik at man ser «gjemte» pasienter. Forutsatt at det er nok pasienter til å flyte ut av skjermen. Når man trykker på en pasient så blir man sendt til pasientens side der alt av info på pasienten er oppdatert. Blir logget ut og blir sendt til logginn side der passordfeltet er tomt og brukernavnet står i brukernavnfeltet. Listen av pasienter beveger seg slik at man ser pasientene som ikke fikk plass på vinduet når siden ble vist i starten. Fungerer på tablet, men på pc må man scrolle med musehjulet eller ta tak i scrollbar nederst på siden. Legge inn en mews på en pasient fra en annen enhet og se at den blir oppdatert live. Skal få beskjed på skjermen. Verdiene skal bli oppdatert på gitt pasient, Kake grafen skal også oppdateres til riktige verdier Pasienten blir borte og kommer tilbake med oppdatert. Kakegraf blir oppdatert med riktige verdier i gruppe siden. Pasientinfo-skjerm Logge ut ved hjelp av brukermenyen Gå tilbake ved hjelp av tilbakeknappen. Skal se innloggings skjermen. Der brukernavnet skal stå i feltet og tomt passordfelt. Skal se hele pasientlisten eller gruppesiden avhengig av hvor du kommer fra. Blir navigert til innloggings skjermen og må fylle inn passord for å komme inn igjen. Brukernavn ligger der ennå. Brukeren blir sendt tilbake til den forrige siden med tilbakeknappen. Trykke på «Legg til MEWS» Skal se MEWS-registrerings skjerm. Får opp en boks der man kan fylle inn de måte verdiene som utgjør MEWS. 181 Vedlegg H - Systemtest

182 Legge inn en mews på en pasient fra en annen enhet og se at den blir oppdatert live. Skal få beskjed på skjermen. Verdiene skal bli oppdatert på gitt pasient, grafene skal også oppdateres til riktige verdier Får en melding som er heldekkende der det står at mews er oppdatert. Må trykke ok for å gå videre. Mews-registrering Trykke «Lagre MEWS» uten å ha fylt ut noen felter. Trykke «Lagre MEWS» uten å ha fylt ut Resp.Frekvens Trykke «Lagre MEWS» uten å ha fylt ut Puls/min Trykke «Lagre MEWS» uten å ha fylt ut Syst.BT Trykke «Lagre MEWS» uten å ha fylt ut Temperatur Trykke «Lagre MEWS» uten å ha valgt CNS Lagre MEWS med verdiene: Resp.Fekvens: 10 Puls/min: 66 Syst.BT: 110 Temperatur: 36.5 CNS: Klar og orientert(våken) Skal få beskjed om at feltene ikke er fylt ut, der bruker må godta for å gå videre. Så returnere til Mewsregistrering. Skal få beskjed om at feltet ikke er fylt ut, der bruker må godta for å gå videre. Så returnere til Mewsregistrering. Skal få beskjed om at feltet ikke er fylt ut, der bruker må godta for å gå videre. Så returnere til Mewsregistrering. Skal få beskjed om at feltet ikke er fylt ut, der bruker må godta for å gå videre. Så returnere til Mewsregistrering. Skal få beskjed om at feltet ikke er fylt ut, der bruker må godta for å gå videre. Så returnere til Mewsregistrering. Skal få beskjed om at feltet ikke er fylt ut, der bruker må godta for å gå videre. Så returnere til Mewsregistrering. Mews skal blir registrert, bruker skal se at en ny mews kommer frem. Denne skal har MEWS = 0 og være grønn Får varsel om at respirasjonsfrekvens må fylles inn som et tall. Må trykke ok og Legg til mews på nytt for å redigere. Ingen MEWS er sendt. Får varsel om at respirasjonsfrekvens må fylles inn som et tall. Må trykke ok og Legg til mews på nytt for å redigere. Ingen MEWS er sendt. Får varsel om at puls må fylles inn som et tall. Må trykke ok og Legg til mews på nytt for å redigere. Ingen MEWS er sendt. Får varsel om at Syst.BT må fylles inn som et tall. Må trykke ok og Legg til mews på nytt for å redigere. Ingen MEWS er sendt. Får varsel om at temperatur må fylles inn som et tall. Må trykke ok og Legg til mews på nytt for å redigere. Ingen MEWS er sendt. Får varsel om at du må velge CNS. Må trykke ok og Legg til mews på nytt for å redigere. Ingen MEWS er sendt. Fyller inn verdiene, så fort Lagre Mews er trykket får man en beskjed om at en ny mews er registrert. MEWS blir 0, og er markert med grønn farge. Tekst boksen forsvinner. 182 Vedlegg H - Systemtest

183 Lagre MEWS med verdiene: Resp.Fekvens: 10 Puls/min: 110 Syst.BT : 110 Temperatur: 36.5 CNS: Klar og orientert(våken) Lagre MEWS med verdiene: Resp.Fekvens: 10 Puls/min: 110 Syst.BT : 110 Temperatur: 36.5 CNS: Forvirret Lagre MEWS med verdiene: Resp.Fekvens: 15 Puls/min: 66 Syst.BT: 90 Temperatur: 36.5 CNS: Forvirret Lagre MEWS med verdiene: Resp.Fekvens: 15 Puls/min: 66 Syst.BT: 200 Temperatur: 37 CNS: Forvirret Mews skal blir registrert, bruker skal se at en ny mews kommer frem. Denne skal har MEWS = 1 og være gul Mews skal blir registrert, bruker skal se at en ny mews kommer frem. Denne skal har MEWS = 2 og være oransje Mews skal blir registrert, bruker skal se at en ny mews kommer frem. Denne skal har MEWS = 3 og være rød Mews skal blir registrert, bruker skal se at en ny mews kommer frem. Denne skal har MEWS = 4 og være rød Fyller inn verdiene, så fort Lagre Mews er trykket får man en beskjed om at en ny mews er registrert. MEWS blir 1, og er markert med gul farge. Tekst boksen forsvinner. Fyller inn verdiene, så fort Lagre Mews er trykket får man en beskjed om at en ny mews er registrert. MEWS blir 2, og er markert med oransje farge. Tekst boksen forsvinner. Fyller inn verdiene, så fort Lagre Mews er trykket får man en beskjed om at en ny mews er registrert. MEWS blir 3, og er markert med rød farge. Tekst boksen forsvinner. Fyller inn verdiene, så fort Lagre Mews er trykket får man en beskjed om at en ny mews er registrert. MEWS blir 4, og er markert med rød farge. Tekst boksen forsvinner. 183 Vedlegg H - Systemtest

184 184

185 Høgskolen i Oslo og Akershus, våren 2014 Vedlegg I - Brukertest 185

186 1.INNLEDNING Høyskolen i Oslo og Akershus I dette vedlegget ligger brukertestene som ble gitt til sykepleiere ved Sykehus Øst. Brukertesten ble utført på Sykehus Øst i Sarpsborg. Brukertesten startet med syv spørsmål som baserte seg på domene og daglig praksis som ble spurt i plenum. Deretter fikk brukerne enheter med installert. Enhetene som ble brukt var en bærbar pc og tablet med MetaVision Windows-klient og en Samsung Galaxy s4 med Android-klient. Alle enhetene var koblet opp mot samme server. Deretter fikk brukerne seks oppgaver de skulle utføre før de skulle svare på spørsmål angående bruksopplevelsen. Se 2. Resultat for resultatet av brukertesten. Det var fem brukertestere som utførte testen der to av brukerne skrev på samme skjema. 2.RESULTAT 2.1 SPØRSMÅL STILT I PLENUM Spørsmål stilt i plenum Spørsmål Svar Hva bruker du MEWS til? Grov vurdering på hvordan pasienten er. Skal registreres på alle. Blir ikke gjort i praksis. Hvordan bruker dere MEWS i dag? Fører det på ark, må regne ut MEWS selv. Tidkrevende og kronglete. Hvordan registrer dere en MEWS i dag? Tar det på runden rundt. Skriver det på Post-it lapp. Lapp i lommen Hvor ofte tar dere verdier fra pasienter? Varierer veldig. Det kommer an på pasientens tilstand og situasjon. 186 Vedlegg I - Brukertest

187 Hvor mange pasienter har du ansvar for? Varierer fra avdeling til avdeling (Ingen godt svar på antall) Hva er viktig å vite om en pasient (generelt)? Om pasientens generelle tilstand. Hvordan de har forandret seg. Hva er normalen i MEWS (pleier den å være 0)? Det varierer fra post til post. Umulig å si. På lunge (avdeling ) ligger det hel annerledes 187 Vedlegg I - Brukertest

188 2.2 OPPGAVER Høyskolen i Oslo og Akershus Brukerene ble bedt om å utføre følgende oppgaver under testen, uten opplæring. Logg deg inn med brukernavn «Admin» og passord «Admin» Gå inn på en pasient og register en MEWS. (Hvilke verdier). Gjør hva du vil. Hvordan ville du brukt denne applikasjonen på jobb. Du er på akuttmottaket på jobb og har Martin Gåskjønli som en våken og oppegående pasient, du skal legge inn en mews og verdiene er: Blodtrykk 140, Puls 67, Temperatur 37 og Respirasjonsfrekvens 10. Du er på akuttmottaket, Daniel Nilsen kommer inn med brukket kraveben, du skal registrere mews og verdiene er: Respirasjonsfrekvens på 15, Puls 70, Blodtrykk 90, temperatur 36 og han er forvirret. Du er på Kirurgisk og har Lise Olsen som pasient hun har hatt en mews over 4 så du er tilbake etter under 1 time, hun har verdiene: respirasjonsfrekvens på 15, Puls 120, Blodtrykk 90 og temperatur på 37 og er Reagere til smerte. 2.3 SPØRSMÅL STILT BRUKERTESTEREN Spørsmål Svar Bruker 1 Bruker 2 Bruker 3 Bruker 4 og 5 Hvordan var Applikasjonen å bruke? Lett å bruke Intuitiv og rask Enkel og logisk å bruke Grei å tolke og oversiktlig Var teksten lett å lese? Ja Ja Ja Ja Var det enkelt å registrere en MEWS? Ja Ja Ja Ja Gav applikasjonen deg god oversikt over pasienter? (Blank) Mobilversjonen gav fin oversikt m/fargene. På nettbrettet måtte man lete mer etter score, bortsett fra de med utropstegn! Ja Så ikke mer informasjon (Var noe på venstre side men så ikke på det) 188 Vedlegg I - Brukertest

189 Forstod du hva symbolene var? Ja Ja Ja Marker at «+» er Ny MEWS. Angi at feltene skal inneholde kliniske verdier, ikke score. Bør det være større font? (Blank) Øverste linje på mobilversjonen ved Reg. Av pasienttilstand var vanskelig å treffe Nei. Evt. Mulighet til å bytte font selv? Grei Bør det være fargekoder? (Blank) JA Ja Nei Hjelper denne applikasjonen deg i arbeidet ditt? Ja Vil være lettvint når den går som en direkte integrasjon til andre IKT systemer Ja Ja Kunne du brukt denne applikasjonen i det daglige? Ja Ja Ja Ja Var det noe som var vanskelig å forstå/fremmed med applikasjonen? Nei For meg var den lett å forstå Nei Se under «Forstod di hva symbolene.» Er det noe du savner å se, kunne utføre, når det kun kommer til MEWSregistrering og oversikt? (Blank) Må være desimaler ved temperatur. Komma på temp.måling. Varsel om når neste måling skal utføres. Se over 189 Vedlegg I - Brukertest

190 Annet (Blank) Viktig å tenke på hvor dette skal presenteres og at det ikke skal være dobbeltføringer. (Blank) (Blank) 190 Vedlegg I - Brukertest

191 Høgskolen i Oslo og Akershus, våren 2014 Vedlegg J- MEWS skjema 191

192 192

193 Dette skjemaet er det leger og sykepleiere Idag bruker for å regne og registrere MEWS, samt få oversikt over pasientens tilstand. 193 Vedlegg J MEWS skjema

194 194

195 Høgskolen i Oslo og Akershus, våren 2014 Vedlegg K- Evaluering fra EVRY 195

196 196

197 Mot slutten av hovedprosjektet har vi gitt EVRY noen spørsmål, der forteller de litt om hvor fornøyd de er med applikasjonene og prosjektarbeidet. OM APPLIKASJONENE(AKSEPTANSETEST) Hva synes dere om det ferdige produktet? EVRY synes produktet helt klart svarer til forventningene og at det tilfredsstiller de krav som stilles til programvare i helse og omsorgssektoren. Produktet følger oss de IT-standarder som benytte si Norge Er oppgaven avvikende fra hva dere i utgangspunktet ønsket? - Hvis ja, ble produktet bedre eller dårligere? Oppgaven er helt klart innenfor vårt ønske, det hadde vært ønskelig med en full integrasjon med MetaVision, men har forståelse for at på den korte tiden lot dette seg ikke gjennomføre Er det ferdige produktet noe EVRY har bruk for? Produktet er innenfor EVRY s satsingsområde under området «en bedre klinisk hverdag» og er et effektivt verktøy som bidra til kvalitet i pasientbehandlingen og et helhetlig pasientforløp. Videre ligger det muligheter gjennom data som systemet gir til ulike forskningssenarioer. OM PROSJEKTARBEIDET Hvordan har kontakten med gruppen vært? Har møtene med gruppen vært bra? Hvordan har dere følt fremdriften av prosjektarbeidet har vært? Sitter dere igjen med en god følelse etter prosjektet? Prosjektet har vært kjørt etter anerkjent prosjektmetodikk med desicion gates for de ulike fasene, Planfase, løsningsdesign med prototyping, utvikling og test og brukertest. Prosjektgruppen har jobbet godt sammen og har på en god måte evnet å få med brukerne nært i prosjektet. Prosjektfremdriften har vært ihht plan og det har vært avholdt faste prosjektmøter med EVRY med rapportering på status og fremdrift. EVRY har en klar oppfatning av et godt gjennomført prosjekt. 197 Vedlegg K - Evaluering fra EVRY

198 198

199 Høgskolen i Oslo og Akershus, våren 2014 Vedlegg L- Installasjons Guide 199

200 200

201 SAMMENDRAG Høyskolen i Oslo og Akershus I dette vedlegget vil du finne installasjons guider for systemet. består av to frontender og en server: Windows 8 store applikasjon, Android applikasjon og Server. Det er viktig å bemerke at Windows 8 applikasjonen kan kreve en developer lisens for å fungere. Dette har vi ikke mulighet for å gi, men en som har brukt Visual Studio 2013 kan enkelt bli autorisert som Windows 8.1 Developer gratis. Det er noe som ikke kommer til å bli gått gjennom. INNHOLDSFORTEGNELSE_Toc Installering av Server (Windows 8.1) Systemkrav: Installasjon Microsoft SQL Server 2012 Express Installer server Installering av på Windows pc og tablet Installasjon Installering av på Android Vedlegg L Installasjons Guide

202 INSTALLERING Høyskolen i Oslo og Akershus 1. INSTALLERING AV METAVIEW SERVER (WINDOWS 8.1) For å installere Server kreves det at man har en Windows basert datamaskin. SYSTEMKRAV: Windows 7 SP1, Windows 8, Windows Server 2012 eller nyere. 1 Ghz Prosessor eller raskere. 512 MB minne Minst 2 GB ledig disk plass..net Framework INSTALLASJON For at programmet skal kunne bruke nettverks port 8080 på denne åpnes. Start kommandolinje som administrator og bruk følgende kommando for å kunne bruke port Start kommandolinjen ved å høyre-klikke på start knappen og velg Command Prompt (Admin) Fyll inn følgende kommando for å gi alle log til å bruke port netsh http add urlacl url= user=everyone Du kan nå lukke kommandolinjen. 202 Vedlegg L Installasjons Guide

203 MICROSOFT SQL SERVER 2012 EXPRESS For å kunne kjøre SQL server lokalt må Microsoft SQL Server 2012 Express installeres. Link: Velg ENU\x86\SqlLocaLDB.MSI for 32 bit prosessor. Velg ENU\x64\SqlLocalDB.MSI for 64 bit prosessor. INSTALLER SERVER Last ned server programvaren fra internet. Pakk ut filene og kjør setup.exe Eller installer fra cd i mappen cd:\installasjon\.server\setup.exe Programmet starter automatisk etter fullført installasjon. Du vil finne igjen.server.signalr i Startmenyen. Gratulerer du har nå installert Server på din datamaskin. 2. INSTALLERING AV METAVIEW PÅ WINDOWS PC OG TABLET Vi har ikke kunnet lage en guide for Windows 8.1 ARM basert tablet da vi ikke har hatt tilgang til dette. Det er viktig å bemerke at Windows 8 applikasjonen kan kreve en developer lisens for å fungere. Dette har vi ikke mulighet for å gi, men en som har brukt Visual Studio 2013 kan enkelt bli autorisert som Windows 8.1 Developer gratis. Det er noe som ikke kommer til og bli gått gjennom. For å installere Windows 8 Store applikasjonen må du først laste ned pakken. 203 Vedlegg L Installasjons Guide

204 Installasjons link: Pakk ut filene i en mappe. INSTALLASJON. Filene i mappen vil se slik ut. Høyreklikk på den valgte filen i bilde over og velg kjør med PowerShell som vist i bilde under. 204 Vedlegg L Installasjons Guide

205 Da vil PowerShell komme opp og du vil få spørsmål om du vil endre execution policy. Dette er noe som må til for at appen skal fungere. PowerShell må kjøres som administrator. Når man trykker på YES/Ja vil installasjonen starte og man skal få et slikt skjermbilde. 205 Vedlegg L Installasjons Guide

206 Da er applikasjonen installert. Du finner applikasjonen i start menyen. 206 Vedlegg L Installasjons Guide