MyPlan En dagsplan for nettbrett. Noora Catherine Østgård Fagerland. Høgskolen i Oslo og Akershus Institutt for informasjonsteknologi

Transkript

1 MyPlan En dagsplan for nettbrett Noora Catherine Østgård Fagerland Høgskolen i Oslo og Akershus Institutt for informasjonsteknologi

2 PROSJEKT NR. 34 TILGJENGELIGHET Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo Telefon: Telefaks: BACHELORPROSJEKT HOVEDPROSJEKTETS TITTEL MyPlan DATO ANTALL SIDER / BILAG 59/9 PROSJEKTDELTAKER Noora Catherine Østgård Fagerland INTERN VEILEDER Kirsten Ribu OPPDRAGSGIVER Oslo Universitetssykehus, avdeling for nevrohabilitering KONTAKTPERSON Morten Berger morten.berger@gmail.com Vidar Antonsen antonsen.vidar@gmail.com SAMMENDRAG Målet med oppgaven er å programmere en prototype i form av en dagsapplikasjon for nettbrett som gir sluttbrukerne oversikt over gjøremål den aktuelle uken, samt en sjekkliste eller handlingskjede som kan knyttes til hvert enkelt gjøremål. Brukergruppen er voksne mennesker med ulike typer kognitiv svikt og med varierende behov. Prototypen er en del av et forskningsprosjekt i regi av Oslo Universitetssykehus (OUS) avdeling for nevrohabilitering, og med støtte fra Helse Sør-Øst. Applikasjonen er kodet i XML og Java, serverkoden er kodet i C# og databasekallene i Java og JSON. Vi er flere grupper som jobber parallelt med samme prosjekt. Oppdragsgiver velger det beste fra de ulike prototypene og lager en ny applikasjon basert på løsningene de ulike gruppene har produsert. 3 STIKKORD Android Database Systemutvikling

3 FORORD Denne rapporten beskriver gjennomføringen av prosjektet og sluttproduktet MyPlan. Dette er min bacheloroppgave som student ved Høgskolen i Oslo og Akershus, institutt for informasjonsteknologi. Jeg kom i kontakt med oppdragsgiver gjennom min veileder, Kirsten Ribu. Høgskolen ble kontaktet av Oslo Universitetssykehus, avdeling for nevrohabilitering. Brukerne er voksne mennesker med varierende behov, med hvor fellesnevneren er at alle har hjerneskader, psykiske utviklingshemminger, syndromer eller annen kognitiv svikt. Noen av brukerne bor hjemme hos foreldrene, andre bor for seg selv eller på institusjon. Oppdragsgiver ønsket en dagsapplikasjon for nettbrett som har som mål å gjøre sluttbrukere mer selvstendige, samtidig som det kan avlaste assistentene for oppgaver brukerne kan greie selv. I denne rapporten skiller jeg mellom bruker/sluttbruker, som referer til brukere av avdelingen, og assistenter/ansatte, som referer til de ansatte på avdelingen. I delkapittelet Resultat vil jeg gjennomgå hvilke deler av applikasjonen hvor funksjonaliteten er kodet, og hvilke deler som kun er kodet i XML. Jeg ønsker å takke Kirsten Ribu ved Høgskolen i Oslo og Akershus, som har vært en uvurderlig hjelp gjennom hele studieperioden og som veileder under hovedprosjektet. Jeg vil også takke Vidar Antonsen og Morten Berger ved Oslo Universitetssykehus (OUS) som ga meg mulighet til å jobbe med et så spennende prosjekt. Forord innledning oppdragsgiver bakgrunn for prosjektet kravspesifikasjon funksjonelle krav for bruker funksjonelle krav for administrator krav til koden tekniske krav sikkerhetskrav ikke-funksjonelle krav rammebetingelser universell utforming kravspesifikasjon høst kravspesifikasjon januar mål resultatmål læringsmål avgrensninger prosessen arbeidsmetode liste over arbeid som gjenstår aktivitetsplan risikoanalyse prosessmodell vurdering av arbeidsinnsats use case-modell Utviklingsprosessen widget designevolusjon utkast fra oppdragsgiver # utkast # utkast # utkast fra oppdragsgiver # utkast # utkast #4 endelige skisser utfordringer underveis feilmelding administratortilkobling og logiske brister... 29

4 6 produktdokumentasjon verktøy feilhåndtering databasen oppsett applikasjonen server/klient testing brukertesting testing av kode aksepttesting resultat videre utvikling brukerveiledning starte programmet innlogging uke dag innstillinger ny aktivitet sjekkliste handlingskjede konklusjon vedlegg INNLEDNING Prosjektet hadde oppstart allerede høsten 2014 som en del av studieemnet ADTS3100 Universell utforming av IKT. I denne fasen utformet vi skisser og prototyper, og prototypene ble testet av oppdragsgiver. Prototypen ble i mitt tilfelle laget i PowerPoint. Oppdragsgiver lagde så en prototype basert på det beste fra de ulike løsningene fra alle gruppene. Som bacheloroppgave programmerer jeg en prototype basert på prototypen i PowerPoint. Det meste av prototypen er programmert i XML og Java og er koblet til databasen, mens enkelte deler kun er kodet i XML for å vise hvordan jeg ser for meg det sluttproduktet. 1.2 OPPDRAGSGIVER Oppdragsgiver er Oslo Universitetssykehus, enhet for miljøbasert behandling (EMB) som er én av tre avdelinger under avdeling for nevrohabilitering. EMB har 11 ansatte. Avdelingens målgruppe er voksne med kognitiv svikt. Oppdragsgiver ønsker en dagsapplikasjon for nettbrett som gir brukerne oversikt over aktiviteter/gjøremål den aktuelle dagen og uken, samt en sjekkliste og/eller handlingskjede knyttet til hver enkel aktivitet. 1.3 BAKGRUNN FOR PROSJEKTET Avdeling for nevrohabilitering jobber med personer med hjerneskader, psykisk utviklingshemminger, syndromer og kognitiv svikt. Noen av brukerne bor hjemme med foreldrene sine, andre bor på institusjon eller alene med varierende støtte fra kommunen. Flere av brukerne kan ikke lese, mens andre kan lese, men foretrekker bilder fremfor tekst. De ansatte har begrenset tid til hver bruker og en del tid går med på å gi brukerne beskjeder og hjelpe dem med grunnleggende oppgaver som å pusse tenner. Målet er at applikasjonen skal frigi tid slik at de ansatte kan bruke mer av tiden på aktiviteter med brukeren etter brukerens ønske. Samtidig skal applikasjonen bidra til at brukeren blir mest mulig selvstendig. Det finnes applikasjoner og systemer på markedet med enkelte av funksjonene oppdragsgiver ønsker, men da må brukeren typisk benytte seg av flere forskjellige applikasjoner eller systemer. Med MyPlan vil disse funksjoner integreres i samme applikasjon. I tillegg må applikasjonen være fleksibel nok til at brukere med forskjellige behov kan ha glede av applikasjonen. Det innebærer muligheten til å deaktivere funksjoner som kan være for avanserte eller forstyrrende for enkelte brukere. Applikasjoner på markedet mangler denne fleksibiliteten. 4

5 1.4 KRAVSPESIFIKASJON Kravspesifikasjonen har blitt endret flere ganger, blant annet etter brukertesting høsten 2014 og møter våren De eneste endringene i forhold til den siste kravspesifikasjonen er at menyen i venstre marg ble fjernet, samt at poengsystemet ble lagt på is inntil videre da oppdragsgiver ikke var helt sikker på hvordan denne skulle utformes. Kravspesifikasjonene er hovedsakelig utformet av oppdragsgiver, men de ulike gruppene har kommet med innspill, og den siste kravspesifikasjonen er basert på løsningene produsert av gruppene i ADTS3100 Universell utforming FUNKSJONELLE KRAV FOR BRUKER Mulighet til å få oversikt over aktiviteter i ukemodus eller dagsmodus Mulighet til å åpne og fullføre en aktivitet Mulighet til å ringe en ansatt gjennom applikasjonen FUNKSJONELLE KRAV FOR ADMINISTRATOR Mulighet til å logge inn Mulighet til å registrere ny bruker Mulighet til å endre på innstillinger Mulighet til å legge til navn og nummer på ansatt i databasen Mulighet til å legge inn ny aktivitet Mulighet til å logge ut KRAV TIL KODEN Koden skal legge til rette for videre utvikling (for eksempel poengsystemet) All tekst skal legges i Strings Koden skal være ryddig og enkel å forstå med tanke på videre utvikling Beskrivende kommentarer i klasser og metoder TEKNISKE KRAV For skjermstørrelse 8"-12.5" Skal kodes i Java, XML Databasekallene skal kodes i JSON Serverkoden skal kodes i LINQ og C# Android SIKKERHETSKRAV Passord skal krypteres Bruker uten administratortilgang skal ikke ha tilgang til administratorfunksjonalitet Nye aktiviteter skal ikke deles med andre brukere i biblioteket da sensitiv informasjon og rutiner må beskyttes Bruk av RegEx Validering av input som passord og gjenta passord, brukernavn og adresse IKKE-FUNKSJONELLE KRAV Det skal ikke ta mer enn fem minutter å bli videresendt til neste delsystem (innlogging -> main, main -> day) Rapporten skal følge HiOAs standarder Nedetid og oppdateringer må planlegges godt for å hindre unødig forvirring blant brukerne Applikasjonen må ikke lanseres før den er ferdig for å hindre at applikasjonen gjennomgår store forandringer etter at brukerne har tatt i bruk applikasjonen

6 Fordi en del punktene under rammebetingelser overlapper med punktene under universell utforming har jeg valgt å slå de to kategoriene sammen RAMMEBETINGELSER Applikasjonen skal inneholde minst mulig tekst da ikke alle brukerne kan eller vil lese Kun nødvendige funksjoner skal inkluderes Unngå forstyrrende elementer Unngå rotete brukergrensesnitt Applikasjonen må programmeres med hensyn til videreutvikling Prosjektperioden er mellom januar og mai 2015 Designet skal ikke være barnslig For Android-nettbrett (8"-12.5") Applikasjonen skal tilpasse seg språket på nettbrettet. Hvis nettbrettet har norsk som visningsspråk skal språket i applikasjonen være norsk, for andre språk skal applikasjonen være på engelsk UNIVERSELL UTFORMING Tilbakemelding (ProgressBar/indikator) Scrolling Tilbydelse (switch-knapper, i aktivitet skal man skjønne at det går an å scrolle) Enkelt språk Faste mønstre KRAVSPESIFIKASJON HØST 2014 Applikasjonen skal bestå av tre menyer: 1. Ukeoversikt Gir oversikt over samtlige aktiviteter den aktuelle uken. På sikt skal det være mulig å bla mellom uker for å få oversikt over aktiviteter og oppgaver frem i tid. 2. Sjekkliste Viser en liste over flere aktiviteter i samme vindu og med en sjekkboks knyttet til hvert bilde/trinn i aktiviteten. 3. Handlingskjede Handlingskjede likner på sjekkliste, men viser kun ett bilde omgangen. Øvrige krav: Gjennomførte oppgaver skal markeres med sjekksymbol Oppgaver som er avhengig av at andre oppgaver er gjennomført skal markeres med hengelås For eksempel at man ikke kan se på TV før man har tatt oppvasken Oppgaver som først kan åpnes ved et gitt tidspunkt skal markeres med en alarm Oppgaver andre dager kan åpnes og sees, men ikke iverksettes Hvis man trykker på en av dagene videresendes man til første aktivitet som ikke er gjennomført Alarm Mulig å legge til lydfil eller video Skjult aktivitet (belønning) som kan åpnes når visse oppgaver er fullført Mulig å velge mellom ulike oppgaver/aktiviteter Poengsystem Bilde av ansatt, eventuelt med ringefunksjon KRAVSPESIFIKASJON JANUAR 2015 Fire menyer: 1. Ukeoversikt 6

7 2. Dagsoversikt Likt som ukeoversikt, men viser kun én dag om gangen og aktiviteter knyttet til den aktuelle dagen. Hvis man trykker på en av aktivitetene i listen blir man videresendt til aktiviteten, på samme måte som man ville blitt i ukeoversikt. 3. Sjekkliste 4. Handlingskjede Prioritet 1: Handlingskjede Sjekkliste Dagsmodus Ukeplan Når en aktivitet er gjennomført videresendes man automatisk til neste aktivitet Mulig å legge til notater eller lydfil Vertikal venstremeny i aktivitet som gir oversikt over alle aktiviteter den aktuelle dagen (denne menyen ble senere fjernet) Prioritet 2: Alarm/påminner når en aktivitet skal utføres Mulig å velge mellom ulike aktiviteter Låste oppgaver En aktivitet kan ikke gjennomføres før et visst klokkeslett eller før andre betingelser er oppfylt Hjelp Motivasjonssystem For eksempel i form av poeng som kan byttes mot en premie Visuell timer En nedtellingstidstaker koblet til en aktivitet og som kan gi et varsel etter at et gitt antall minutter har passert. Et eksempel er en aktivitet som går ut på å lage Toro-suppe. Nedtellingstidstakeren kan da settes til et visst antall minutter. Fargekoding av aktiviteter Grønn betyr at aktiviteten kan gjennomføres alene, hvit betyr at den kan gjennomføres med en ansatt. Prioritet 3: Månedsoversikt Lyd og video Aktivisere andre programmer direkte fra applikasjonen Overstyre andre programmer direkte fra applikasjonen Overstyre spill frem til visse aktiviteter er gjennomført Ringefunksjon Personaloversikt Oversikt med bilde over ansatte og muligheten til å ringe en ansatt ved å trykke på bildet. Ekstraaktiviteter En bank av ekstraaktiviteter som bruker kan velge mellom. Prioritet 4 (videre utvikling): Fjernadministrering Oppsummere mestring og sende rapport Sende oversikt over fullførte aktiviteter på mail. GPS-funksjoner 7

8 2 MÅL 2.1 RESULTATMÅL Oppdragsgiver ønsker at løsningen skal gjøre brukerne mer selvstendige, på sikt hjelpe dem å utføre oppgaver uten bruk av detaljerte handlingskjeder (ved å kutte trinn). Samtidig skal den frigi assistenter for tid og ressurser som kan brukes til for eksempel sosialt samvær som brukerne har gitt uttrykk for at de ønsker. Til sist vil en slik applikasjon kunne gi brukere mestringsfølelse fordi de kan utføre flere oppgaver på egenhånd, samtidig som det gir dem en følelse av trygghet og forutsigbarhet. 2.2 LÆRINGSMÅL Gjennom prosjektet ønsker jeg å få økt kunnskap om Prosjektplanlegging Android-programmering Databasebehandling Ny programvare (Azure, Visual Studio, ALM og Android Studio) Universell utforming Informasjonsarkitektur Dokumentere større prosjekter Viktig erfaringer om hvordan det er å jobbe som programmerer Kunnskap om ulike funksjonshemminger og hvordan teknologi kan brukes til å hjelpe denne pasientgruppen 2.3 AVGRENSNINGER Jeg er det eneste medlemmet i gruppen, og dermed har jeg ikke tid eller ressurser til å implementere alle funksjonene jeg ønsker eller gjøre applikasjonen såpass brukervennlig som jeg mener er nødvendig for at den skal kunne lanseres på markedet. Det gjelder spesielt den delen av applikasjonen som går på å legge til nye aktiviteter eller hente frem gamle maler. I tillegg gjelder det enkelte innstillinger som å vise dato, deaktivere enkelte funksjoner, og liknende. Jeg har derfor fokusert på å få på plass grunnstrukturen da dette hadde førsteprioritet. Enkelte deler av applikasjonen er kun kodet i XML for å vise hvordan jeg ser for meg den videre utviklingen. Dette gjelder for eksempel nyactivity.

9 3 PROSESSEN 3.1 ARBEIDSMETODE Som nevnt innledningsvis jobber flere grupper med samme prosjekt. Vi startet allerede med planleggingen høst 2014 som en del av et annet fag, og frem til januar hadde vi workshops og delte ideer. Fra januar 2015 jobbet de ulike gruppene hver for seg. Det har vært møter med oppdragsgiver gjennom hele vårsemesteret, men da uten de andre gruppene tilstede. Under møtene har vi gjennomgått brukergrensesnittet og funksjonene. Jeg har fått tilbakemeldinger som har ført at jeg har endret på koden. Gjennom prosjektperioden har det viktigste styringsdokumentet vært en detaljert liste over hva som gjenstår av arbeid. Denne listen inkluderer detaljer som metoder som må programmeres, endringer i layout og liknende. Etter at en oppgave er fullført blir den strøket over. Det har gitt en god oversikt over hva som gjenstår av arbeid. Tillegg har jeg ført en liste over hva jeg har gjort av arbeid (se tabell 2.11). Siden jeg er det eneste medlemmet i gruppen er styringsdokumentene mine enklere enn hos grupper med flere medlemmer. Derfor har jeg heller ikke brukt en milepælsplan. Derimot har jeg laget en risikoanalyse med risikoer og tiltak som jeg har hatt i bakhodet gjennom prosjektperioden. Jeg har også brukt en prosessmodell som har gitt oversikt over fasene prosjektperioden. Denne prosessmodellen er inspirert av fossefallsmodellen. Når jeg har jobbet med prosjektet har jeg sjekket listen over hva som gjenstår av oppgaver og gjort oppgaver som ikke er for vanskelige. Jeg har søkt på nettet, spesielt StackOverflow, for å finne svar på problemer. Etter at jeg har gjort de enkle oppgavene har jeg lært nok til at jeg har kunnet gå over til vanskeligere oppgaver. I tillegg har jeg jobbet med mentoren min. Hun har da forklart meg hvordan løse ulike oppgaver, for eksempel AsyncTask, slik at jeg kan gjøre oppgavene på egenhånd. Jeg har hatt møter med veilederen min enten på HiOA eller på Skype. Skype har vært et enkelt alternativ fordi jeg bor utenfor Oslo og fordi jeg er i full jobb fra og med mai. Møtene har foregått ved at jeg sender dokumenter eller spørsmål på forhånd og så diskuterer vi det på Skype. Kontakten med oppdragsgiver har foregått via mail og møter enten på OUS eller HiOA. Nedenfor følger en liste over styringsdokumenter jeg har støttet meg på gjennom prosjektperioden. 3.2 LISTE OVER ARBEID SOM GJENSTÅR Figur 1.1 viser et utdrag fra arbeid som gjenstår. Oversikten er gruppert etter de ulike menyene i applikasjonen. Til sist er det en diverse-folder som fanger opp oppgaver som ikke passer inn i en av de øvrige kategoriene, for eksempel å oversette alle verdiene i Strings til engelsk. Når en oppgave er fullført strykes den ut. Listen har blitt oppdatert kontinuerlig gjennom prosjektperioden ettersom jeg kommer på flere ting som må gjøres. Det kan argumenteres med om en sånn plan gir en fullgod oversikt over arbeid som gjenstår fordi den oppdateres jevnlig, den skiller ikke mellom oppgaver som tar lang tid og oppgaver som tar kort tid, og den inkluderer ikke frister. Jeg har gjort oppgavene fortløpende og ikke etter en viss rekkefølge eller innen en gitt frist. På den andre siden har det gitt meg oversikt over små oppgaver jeg kan gjøre, og kombinert med at jeg stryker ut oppgavene når de er fullført har det gjort at jeg har jobbet svært effektivt og målrettet. For større prosjekter og med flere variable måtte jeg hadde en mer avansert plan. Figur 1.1 arbeid som gjenstår

10 3.3 AKTIVITETSPLAN Aktivitetsplanen er egentlig en refleksjon av listen over arbeid som gjenstår. Når jeg har fullført en aktivitet blir den strøket i listen (se figur 1.1) og samtidig oppdaterer jeg aktivitetsplanen med arbeidet jeg har gjort. Tabell 1.2 utdrag fra aktivitetsplanen DATO ARBEID Lagt til applikasjonsikon Oppdatert arbeidsplan Laget layout til registrer ny bruker Button i LoggInn og intent som leder til registrer ny bruker Javakoden til registrer ny bruker Databasemetode som sjekker om bruker(navn) finnes fra før Metode som sjekker om passord og gjenta er like Metode i databasen som validerer ID og passord AsyncTask på ID og passord Menu registrer ny bruker Filter på trinn som er fullført Logge ut XML Logge ut java Trykke på bilde-gå til aktivitet Innlogging med sessions 3.4 RISIKOANALYSE A. Sykdom Mild til moderat sykdom under prosjektperioden har som konsekvens at jeg kan bli liggende etter med arbeid. Som eneste gruppemedlem er jeg mer fleksibel og kan tilpasse arbeidsmengden enklere enn hvis jeg er i en gruppe. Jeg kan også jobbe hjemmefra og har tilgang til alt materiale. Jeg går heller ikke glipp av gruppemøter. Dermed er konsekvensene mindre for meg. Tiltak: Ligge foran minst to uker med arbeidet gjennom hele prosjektperioden. B. Manglende ferdigheter eller kunnskap 10

11 Siden det ikke er andre medlemmer i gruppen kan jeg ikke spørre om hjelp eller velge en annen oppgave. Jeg må gjøre absolutt alle oppgavene i prosjektet. Det gjør at jeg lærer mer, men samtidig kan det skape store problemer hvis jeg står fast. Blant annet kan det gjøre at jeg blir liggende etter i forhold til frister. Tiltak: Som med punkt A er det viktig å sette av ekstra tid. I tillegg kan jeg spørre mentoren min eller på dataforum hvis det er programmeringsrelatert, eller studentveileder hvis det er knyttet til utformingen av applikasjonen eller rapporten. C. Mangel på tid Mangel på tid kan oppstå som en konsekvens av punktene A og B, endringer i kravspesifikasjon, eller på grunn av svake styringsdokumenter og prosjektplanlegging. Tiltak: Sette av ekstra tid, sterke styringsdokumenter med aktivitetsplan og kravspesifikasjon som prioritert liste. D. Dataproblemer Inkluderer problemer med hardware eller programvaren. Eksempler er at data blir slettet, dataen bryter sammen, programvare som ikke er kompatibel med operativsystem, og liknende. Tiltak: Tilgang til Windows-maskin, backup på ekstern server, oppdatert antivirusprogrammer. E. Misforståelser Misforståelser kan oppstå i forhold til innleveringsfrister og standarder, kravspesifikasjonen eller kommunikasjon med oppdragsgiver. Tiltak: Så langt det er mulig få all informasjon skriftlig. Lese gjennom dokumentene flere ganger. Sørge for å spørre hvis det er uklarheter rundt formuleringer. Gjenta muntlige beskjeder for å være sikker på at de er forstått riktig. Tabell 1 - Sannsynligheter og konsekvenser Sannsynlighet Konsekvens Høy Middels Lav Høy Middels Lav A. Sykdom x x B. Manglende x x ferdigheter eller kunnskap C. Mangel på tid x x D. Dataproblemer x x E. Misforståelser x x F. Bugs og feil i koden x x 3.5 PROSESSMODELL I utgangspunktet hadde jeg tenkt å bruke fossefallsmodellen for å organisere prosjektperioden. I praksis var denne modellen altfor rigid. Jeg så blant annet at koding og testing gikk om hverandre og at jeg gikk tilbake til kravspesifikasjonen og endret denne etter brukertestinger. Modellen jeg brukte er derfor inspirert av fossefallsmodellen. I tillegg er den inspirert av testprosessmodellen til International Software Testing Qualification Board (ISTQB) beskrevet av Hans Schaefer. (Schaefer, 2014) Figur 2.1 fossefallsmodellen 11

12 Planlegging( Planlegging( Kravspes( Koding( Koding( Tes1ng(av(kode( Tes1ng( Brukertes1ng( Systemet(er( klart( Ferdig( Tid( Figur 2.2 testprosessmodellen beskrevet hos ISTQB Prosjektfasen har bestått av følgende fem faser: 1. Planlegging 2. Kravspesifikasjon 3. Koding 4. Testing 5. Dokumentasjon Som figur 2.3 viser har testing ført til endringer i kode og kravspesifikasjon. Testing inkluderer brukertesting og testing av kode. I praksis har jeg jobbet med dokumentasjonen samtidig som jeg jobbet med koden, spesielt på slutten. Figur 2.3 prosessmodell 12

13 3.6 VURDERING AV ARBEIDSINNSATS Planleggingen min var ikke god nok. Spesielt databasen og datametodene tok langt lengre tid enn jeg forutså. Jeg hadde ikke tatt godt nok hensyn til forsinkelser som dette. Jeg hadde lagt inn en forsinkelse på to uker, og det var ikke nok. Jeg kom for sent i gang med Java-kodingen. Jeg burde ha begynt med tutorials allerede før skolestart for å være bedre forberedt slik at kodingen kunne starte allerede da den nye kravspesifikasjonen forelå. Videre jobbet jeg med administratordelen og brukerdelen parallelt istedenfor å fullføre én modul før jeg gikk over til den neste. Det gjorde at brukertestingen måtte utsettes. Det hadde vært bedre å dele opp programmet i iterasjoner og teste hver iterasjon for seg før hele systemet ble testet som en helhet. Jeg burde startet på dokumentasjonen samtidig med planleggingsfasen og oppdatert de ulike kapitlene underveis istedenfor å ha dokumentasjon som en fase til slutt. Det jeg derimot synes er bra er at jeg kodet selve grunnstrukturen og fikk den på plass før jeg gikk videre til andre funksjoner. Jeg har også jobbet jevnt gjennom semesteret, selv om kodingen kom i gang for sent. 13

14 3.7 USE CASE-MODELL Figur 2.4 viser en use case-modell av aktørene og deres krav til systemet. Modellen har følgende aktører: 1) Bruker 2) Administrator Administrator kan enten være en bruker med administratorrettigheter eller en ansatt. En vanlig bruker har ikke administratorrettigheter. En bruker skal kunne åpne en aktivitet, fullføre en aktivitet (aktiviteten blir merket som fullført i databasen) og ringe en ansatt direkte fra applikasjonen hvis det er behov for det. En administrator skal kunne behandle aktiviteter og brukerkonti. Figur 2.4 use case-modell MyPlan 14

15 UTVIKLINGSPROSESSEN 4.1 WIDGET I en brukertest høst 2014 kom det frem at oppdragsgiver på sikt ønsker å utvikle en light-versjon av applikasjonen som kan brukes på mobilen. Den kan for eksempel sende handleliste fra applikasjonen slik at brukeren slipper å ta med seg hele nettbrettet til butikken. Etter brukertestingen begynte jeg å tenke på om det kunne være mulig å heller lage en widget som hadde liknende funksjonalitet. Jeg snakket først med veilederen min og deretter snakket jeg med oppdragsgiver. De synes at ideen var god og derfor fortsatte jeg å jobbe med widgeten. Widgeten jeg har programmert viser neste aktivitet i listen. På sikt ønsker jeg at det skal være mulig å bla mellom aktivitetene, slik at den neste aktiviteten ligger øverst i listen. I tillegg går det an å programmere andre widgeter som for eksempel kan sende et valgt trinn eller en valgt aktivitet, som for eksempel sjekkliste for å gå i butikken. 4.2 DESIGNEVOLUSJON Som nevnt innledningsvis startet designprosessen allerede høsten 2014 i faget Universell utforming av IKT. Vi har jobbet tett med oppdragsgiver gjennom hele prosessen, blant annet flere møter hvor oppdragsgiver har evaluert designet. Designet og kravspesifikasjonen har blitt endret flere ganger. De største endringene fant sted januar 2015 da vi fikk den nye kravspesifikasjonen og fikk presentert et nytt forslag til utforming UTKAST FRA OPPDRAGSGIVER #1 Under det første møtet med oppdragsgiver fikk vi presentert et forslag til utforming laget i PowerPoint, se figur 2.5a. Aktivitetene er sortert kronologisk etter tid vertikalt og etter dag horisontalt. Dagene er skilt fra hverandre ved hjelp av farger. Aktivitetene er merket med ikoner eller fargerammer. Figur 2.5a uke Ukeplan Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag Figur 2.5b er et annet eksempel fra oppdragsgiver. Bildet viser en sjekkliste som i motsetning til en handlingskjede har flere trinn i samme bilde.

16 Figur 2.5b sjekkliste Notat: tekst/lyd/video Fordeler og ulemper Svakhetene ved uke er at fargevalg og utforming kan virke barnslig og at det er for mange forstyrrende elementer blant annet med merkingen av aktiviteter. Det kan ta litt tid for både bruker og administrator hva de ulike fargerammene og ikonene betyr, og det kan skape mye frustrasjon. Når det gjelder sjekklisten er den ikke tydelig nok. Skal man dra bildet over til boksen til høyre for å merke den som fullført, eller skal man trykke på pilene? I dette utkastet er det en boks under bildet hvor det er mulig å legge inn en tekst- eller lydfil. Det burde også være mulig for administrator å legge inn en tekst- eller lydfil i hvert trinn i aktiviteten, for eksempel hvis en bruker har fått som oppgave å lage mat vil det kunne være aktuelt å ha med en tekst- eller lydbeskrivelse av hvert enkelt trinn og ikke bare for hele aktiviteten UTKAST #1 Figur 2.5c viser startsiden slik jeg så for meg den høst 2014 før brukertestingen. Stjernene indikerer oppnådde poeng. Dette var før oppdragsgiver valgte å skrinlegge poengsystemet inntil videre. Hvis man trykker på stjernene enten over planen eller nederst på hver dag blir man videresendt til poengsiden. Pilene på høyre og venstre side gjør det mulig å bla mellom uker. Ringeikonet øverst i venstrehjørne gjør at bruker kan ringe en ansatt og verktøy-ikonet øverst i høyre hjørne fører til innstillinger og legge inn ny aktivitet. Figur 2.5c MainActivity/uke 16

17 mandag tirsdag onsdag torsdag fredag lørdag søndag aktivitet 1 aktivitet 1 aktivitet 1 aktivitet 1 aktivitet 1 aktivitet 1 aktivitet 1 aktivitet 2 aktivitet 2 aktivitet 2 aktivitet 2 aktivitet 2 aktivitet 2 aktivitet OPPG aktivitet n aktivitet n aktivitet n aktivitet n aktivitet n aktivitet n aktivitet n Fordeler og ulemper Designet ser stygt og lite profesjonelt ut. Ringeikonet burde være på høyre side, det virker mer logisk. Det er dobbelt sett med stjerneikoner, noe som kan skape forvirring. Dagen i dag er ikke fremhevet godt nok UTKAST #2 Figur 2.5d forsøk 2 MainActivity/uke mandag tirsdag onsdag torsdag fredag lørdag søndag aktivitet 1 aktivitet 2 aktivitet 1 aktivitet 2 aktivitet 1 aktivitet 2 aktivitet 1 aktivitet 2 aktivitet 1 aktivitet 2 aktivitet 1 aktivitet 2 aktivitet 1 aktivitet OPPG aktivitet n aktivitet n aktivitet n aktivitet n aktivitet n aktivitet n aktivitet n Figur 2.5e viser et eksempel på et trinn i en handlingskjede. Menyen i høyre marg viser trinnene i handlingskjeden. Det skal være mulig å scrolle mellom dem. Trinnet man er på er fremhevet med en svart ramme. Figur 2.5e handlingskjede 17

18 Fordeler og ulemper Designet i uke er barnslig, ringeikonet burde plasseres øverst i høyre hjørne. Planen burde dekke mest mulig av skjermen. Pilene på hver side av skjermen burde fjernes, i innstillinger bør det kunne velges om bruker skal kunne swipe mellom uker eller kun ha tilgang til aktuell uke. Når det gjelder handlingskjeden burde hjemikonet og ringeikonet plasseres øverst i høyre hjørne. At knappene flytter på seg avhengig av hvilken meny man er i skaper forvirring. I tillegg er det logisk å ha disse knappene til høyre og ikke til venstre i bildet. Menyen til høyre gir god oversikt over hvilket trinn man er på, men på et lite nettbrett tar det for mye plass. Menyen burde derfor kunne fjernes i innstillinger hvis den i det hele tatt skal inkluderes i planen. Som standard burde menyen fjernes og hovedbildet forstørres slik at det dekker mest mulig av skjermen UTKAST FRA OPPDRAGSGIVER #2 Figurene 2.5f og 2.5g ble levert inn som en del av et prosjekt i Universell utforming av IKT. Oppdragsgiver lagde en ny prototype basert på det beste fra løsningene til de ulike gruppene i Universell utforming av IKT. Figur 2.5f MainActivity/uke 18

19 Figuren over viser uke. Aktuell dag (tirsdag) er fremhevet. Hvis man trykker på et av bildene blir man videresendt til aktiviteten. Figur 2.5g viser en sjekkliste. Øvrige aktiviteter den aktuelle dagen vises i menyen til venstre. Hovedbildet er delt inn i to deler: 1. Tittel, tid og bilde på aktiviteten 2. Sjekklisten Figur 2.5g sjekkliste 19

20 Fordeler og ulemper Designet er rent og profesjonelt med få forstyrrende elementer. Fargene er nøytrale. Menyen til venstre i sjekklisten gir god oversikt over andre aktiviteter den aktuelle dagen. Teksten kan derimot virke forstyrrende og burde i stor grad fjernes. Menyen og det todelte hovedbildet tar mye plass av skjermen UTKAST #3 Figur 2.5h handlingskjede Figur 2.5h viser min løsning basert på eksempelet fra oppdragsgiver. Hovedbildet er bildet man er på i handlingskjeden, A1-An står for aktivitet 1-aktivitet n, det vil si samtlige aktiviteter den aktuelle dagen. Under hovedbildet er det en tekstboks. Administrator kan legge inn tekst når han eller hun registrerer en ny aktivitet. Oppdragsgiver ønsket i utgangspunktet at vi skulle implementere menyen i venstre marg, men senere ble den fjernet fordi den kunne virke forstyrrende og tok opp for mye plass av skjermen. Fordeler og ulemper Hovedbildet må forstørres slik at det dekker mer av skjermen. Designet er rent. Menyen til venstre passer for mer avanserte brukere UTKAST #4 ENDELIGE SKISSER MainActivity/uke Figur 2.5i viser MainActivity/uke. Ukeplanen er en LinearLayout med kolonner, og navnene på dagene er trykkbare knapper. Øverst i høyre hjørne er det et sett med ikoner avhengig av om telefonikon er aktivert eller deaktivert. Dagen man er på er fremhevet ved hjelp av et blått filter. Bakgrunnen er svart med hvit skrift. Jeg valgte disse fargene fordi det gir et voksent og profesjonelt uttrykk. Designet er enkelt med få forstyrrelser og kun nødvendige funksjoner. Når bruker trykker på en aktivitet i denne menyen blir han eller hun videresendt til den valgte aktiviteten. Når en aktivitet er gjennomført blir brukeren videresendt til ukeoversikten. Hvis man trykker på en av dagene blir man videresendt til dagsmodus hvor man får oversikt over aktiviteter knyttet til valgt dag. Øverst i høyre hjørne er det en snarvei til andre menyer avhengig av innstillinger og rettigheter. I de andre menyene minus innlogging og registrer ny bruker er det et hjem-ikon øverst i høyre hjørne som leder til ukeplanen. Ikoner er lagt på oppgavelinjen øverst i høyre hjørne. Det er mulig å swipe mellom uker hvis denne funksjonen ikke er deaktivert i innstillinger. 20

21 Figur 2.5i MainActivity/uke Aktivitet Figur 2.5j viser et trinn i en aktivitet. Det er en enkel layout med ett hovedbilde som dekker store deler av skjermen, en tekstboks, en sjekknapp og ikoner i øvre marg. Bakgrunnen er svart med hvit skrift, tekstboksen er hvit med svart skrift. En visuell timer vil være synlig her hvis den er valgt. Figur 2.5j trinn i en aktivitet 21

22 Innstillinger I innstillinger kan en administrator enten legge til navn og telefonnummer til en ny ansatt eller velge blant ansatte som er registrert fra før. Nummeret brukes hvis bruker ønsker å ringe en ansatt ved å trykke på et ringeikon. Videre følger et sett med innstillinger og til slutt en logg ut-knapp. En bruker uten administratorrettigheter har ikke en logg ut-knapp. Det er viktig for å hindre at brukeren låser seg ut av programmet ved en feiltakelse. Brukeren må være logget inn for å kunne ringe til en ansatt gjennom applikasjonen. Til høyre for tekstboken er det en sjekkboks. Når sjekkboksen merkes blir man videresendt til neste steg i aktiviteten. Hvis det ikke er flere steg blir man videresendt til ukeplanen. Figur 2.5k innstillinger 22

23 Innlogging I innloggingsmenyen kan man logge inn med brukernavn og saltet passord eller registrere ny bruker. Opprinnelig hadde jeg satt tre passordforsøk som øvre grense, men jeg fjernet etterhvert grensen for å ikke risikere at brukere låser seg ute av systemet. I innlogging er det ikke noen ikoner på oppgavelinjen. Figur 2.5l innlogging Registrer ny bruker Figur 2.5m viser menyen registrer ny bruker. Her kan en administrator registrere en ny bruker, med eller uten administratorrettigheter. Passord og gjenta passord må matche, brukernavn og må ikke finnes fra før. Når administrator trykker lagre videresendes han eller hun til innlogging. I denne menyen er det ingen ikoner med unntak av en tilbakeknapp for å komme tilbake til innlogging. 23

24 Figur 2.5m registrer ny bruker DayActivity/dag Hvis man trykker på en av dagene i MainActivity/uke, kommer man til dagen man har trykket på, se figur 2.5n. Denne menyen gir en oversikt over alle aktiviteter den aktuelle dagen. Hvis man trykker på en av aktivitetene i menyen blir man videresendt til aktiviteten man har trykket på, på samme måte som i MainActivity/uke. Hvis det er flere trinn i aktiviteten skal den øverste delen av det neste trinnet være synlig så bruker skjønner at det er mulig å scrolle. Figur 2.5n DayActivity/dag ActivityOnUser/aktivitet på bruker Hvis administrator trykker på ny-ikonet i en av menyene vil han eller hun bli videresendt til ActivityOnUser (figur 2.5o). Her kan administrator velge mellom å lage en ny aktivitet eller bruke en lagret aktivitet. Hvis 24

25 administrator velger å lage en ny aktivitet blir han eller hun videresendt til Ny (se figur 2.5p). Hvis han eller hun derimot velger å bruke en gammel aktivitet, åpnes det en ListView som viser alle lagrede aktiviteter. Deretter velger administrator dato og tidspunkt for aktiviteten og trykker lagre. Aktiviteten blir lagret i databasen og vises i MainActivity og DayActivity som et klikkbart bilde. Figur 2.5o ActivityOnUser Ny aktivitet Hvis administrator har trykket på knappen Ny aktivitet blir han eller hun videresendt til menyen ny hvor det kan registreres en ny aktivitet. Først må administrator velge et bilde som skal illustrere aktiviteten (for eksempel pusse tenner), enten fra nettet, ved hjelp av kameraet på nettbrettet eller fra galleri. Bildet vil bli lastet opp i 25

26 ImageView til venstre for knappene. Deretter velger administrator et navn på aktiviteten, som brukes hvis aktiviteten skal hentes frem senere. Til slutt velger administrator om det skal legges til handlingskjede eller sjekkliste. Hvis verken sjekkliste eller handlingskjede er valgt er det ikke nødvendig å fylle ut skjemaet under streken. Hvis handlingskjede eller sjekkliste derimot er valgt må administrator legge til bilde, beskrivelse og eventuell nedtellingstidstaker for hvert enkelt trinn. Til slutt trykker administrator på lagre og blir videresendt til ActivityOnUser. Figur 2.5p ny aktivitet Grunnen til at jeg har skilt aktivitet på bruker og ny er fordi for mange valg i samme layout kan virke forvirrende og det ville bli ryddere å lage en egen layout hvis man ønsker å legge til en helt ny aktivitet. 26

27 Widget Widgeten skal vise neste aktivitet i listen. I første omgang er kun neste aktivitet synlig, men på sikt ønsker jeg at flere aktiviteter skal ligge oppå hverandre i en bunke. Hvis man trykker på bildet vil man automatisk bli videresendt til aktiviteten slik man ville blitt hvis man trykket på bildet i MainActivity/uke eller DayActivity/dag. Når en aktivitet er fullført vises neste aktivitet i listen. Widgeten oppdateres hvert 30.minutt, men på sikt bør den oppdateres oftere. Figur 2.5q widget: neste aktivitet 27

28 5 UTFORDRINGER UNDERVEIS 5.1 FEILMELDING 403 I slutten av prosjektperioden fikk jeg to ganger feilmelding 403 (bilde 3.1). Det skapte store problemer fordi jeg kunne ikke teste applikasjonen eller forbedre koden mens serveren var nede. Jeg tok kontakt med kundeservice i Microsoft, men innen jeg fikk et svar fra dem dagen etter var serveren oppe igjen. Kundeansvarlig sa at feilen kan skyldes at minnekvota er overskredet. Jeg fikk senere samme feilmelding. Denne gangen tok jeg ikke kontakt med kundeservice, men fjernet bilder fra ListView i aktivitet på bruker. Jeg forminsket også samtlige bilder i databasen for at opplastning skal gå raskere. Bilde 3.1 feilmelding Figur 3.2 svar fra Microsoft kundeservice

29 5.2 ADMINISTRATORTILKOBLING OG LOGISKE BRISTER En viktig betingelse for at applikasjonen skal være brukervennlig er at det er få forstyrrende elementer og kun nødvendige funksjoner skal inkluderes. Det innebærer at funksjoner som bruker ikke har tilgang til eller ikke trenger heller ikke skal være synlige. Jeg valgte derfor tidlig å lage to ulike moduser: 1. Bruker 2. Administrator En bruker kan ha administratorrettigheter, men må ikke ha det. En administrator er en bruker med administratorrettigheter. Tanken bak var at visse elementer kun skulle være synlige hvis brukeren hadde administratorrettigheter. Problemet oppstår når en administrator har lagt en aktivitet på bruker. I virkeligheten har administrator lagt en aktivitet på administrator og ikke på bruker. Når administrator logger ut, logger også brukeren ut. Dette hadde fungert ved fjernadministrering eller hvis administrator kunne velge mellom brukere aktiviteten skulle legges på. Denne logiske bristen oppdaget jeg først 18.mai, det vil si etter brukertestingen og dager før innlevering. En midlertidig løsning har derfor vært å endre brukergrensesnittet slik at ikonene er synlige for brukeren, inkludert ny aktivitet og innstillinger, men disse krever passord. Det vil si at en bruker som ikke har fått passordet heller ikke har tilgang til disse menyene. Slik jeg ser det skaper dette to store problemer: 1. De ekstra ikonene kunne virke forstyrrende for enkelte brukere 2. Kun administrator kan logge ut av applikasjonen og ikke bruker Løsningen blir ikke optimal, men punkt 1 kan løses ved at ny aktivitet blir lagt til i innstillinger slik at det kun blir ett forstyrrende element på startsiden. Det betyr flere klikk for administrator. Hvis administrator skal legge inn en ny aktivitet istedenfor å bruke en mal må han eller hun gå fra uke -> innstillinger -> aktivitet på bruker-> ny -> aktivitet på bruker. Når det gjelder punkt 2 ønsket ikke oppdragsgiver at en bruker uten administratorrettigheter skal kunne logge ut av applikasjonen, fordi dette vil kunne føre til at brukere låser seg ute. For at en bruker skal kunne logge ut må derfor administrator være logget inn. Et alternativ kan derfor være å ha to logg ut-knapper; én for å logge ut som administrator og én for å logge ut som bruker. Hvis man trykker på logg ut som administrator blir man logget ut av selve administratormodusen og må gå på innstillinger og skrive inn et passord for å kunne logge inn igjen. Hvis man derimot trykker på logg ut som bruker blir man logget ut av hele applikasjonen. På sikt burde man derfor fjerne hele administratormodusen og kun ha et felles passord som gjelder for alle administratorene. Når man logger på applikasjonen må man først logge på som bruker og deretter gå på innstillinger og skrive inn passordet for å få tilgang til de ekstra funksjonene. Dette kan gjøres ved å lage en drop down menu som kommer opp når man trykker på innstillinger-ikonet (se figur 3.3). Istedenfor alle elementene i figuren skal det kun være et passordfelt. Et annet alternativ er å fjerne innstillinger-ikonet og heller ha en drop down menu som på iphone som i utgangspunktet er gjemt (figur 3.4). Bildet til venstre i figur 3.4 viser skjermen når menyene er gjemt. Bildet i midten viser skjermen når menyen er dratt ned fra toppen. Bildet helt til høyre viser skjermen når menyen er dratt frem fra bunnen av skjermen. Både innstillinger og ny aktivitet kan ligge i denne menyen. Figur 3.3 drop down menu passord Figur 3.4 skjult meny iphone

30 30

31 6 PRODUKTDOKUMENTASJON 6.1 VERKTØY Backup og dokumentasjon: Dropbox for Mac - Brukt til å lagre bilder og dokumenter og for å delse filer med oppdragsgiver Microsoft Office PowerPoint og Word versjon for Mac - Brukt til å skrive rapporten og presentasjonen LucidChart - Brukt til modellering Utvikling og database Testing Android Studio - Brukt til å programmere applikasjonen Visual Studio versjon update 4 med Microsoft.NET Framework versjon Brukt til å programmere databasen og databasemetoder Azure - Pay-as-you-go server hvor databasen blir lagret HP ALM versjon Brukt til aksepttesting Programmeringsspråk C# - serverkoden LINQ - databaseforespørsler Java - applikasjonen og databasekall JSON - databasekall XML - layout 6.2 FEILHÅNDTERING Tekstfeltene i logg inn og registrer ny bruker valideres. Hvis brukernavn eller passord ikke stemmer kommer det opp en toast. Hvis det ikke er nettverksforbindelse kommer det opp en toast som gir beskjed om det. Hvis brukernavn i registrer ny bruker finnes fra før får bruker opp en toast når han eller hun trykker på lagre. Tilsvarende vil skje hvis passord og gjenta passord ikke stemmer. Til slutt er det med en RegEx som sjekker at man har skrevet inn et visst antall tegn. Hvis applikasjonen ikke får kontakt med databasen kommer det også opp en toast. 6.3 DATABASEN Databasen er kodet i C# og LINQ. Jeg har brukt MS Visual Studio for å skrive serverkoden, databasekallene er skrevet med JSON i Android Studio og serveren jeg har brukt er Azure. Grunnen til at jeg har valgt nettopp disse programmene og språkene er at jeg har allerede brukt Visual Studio på skolen, og jeg tenkte at jeg kommer til å lære mye nytt og bruke mange nye programmer dette semesteret, og da er det fint å ha noen programmer jeg er vant til å bruke. I tillegg ønsket jeg å lære å kode i C#. Jeg kan SQL fra før, og derfor å lære LINQ. Siden Visual Studio bruker LINQ var valget lett. Databasen består av fem klasser: 1. User 2. ActivityUser 3. Activity 4. Steps 5. Employee Verdier med understrek er primærnøkler, verdier med stjerne er fremmednøkler.

32 Figur 4.1 databasen Jeg lagde først en ER-modell for å få oversikt over klassene og attributtene i klassen før jeg lagde databasen. Selv om jeg planla hvordan databasen skulle se ut måtte jeg slette databasen og bygge den på nytt flere ganger underveis. Ettersom jeg kom lenger med Java-koden forstå jeg at jeg måtte utforme databasen annerledes. Siste gang jeg slettet databasen var 16. mai. Da endret jeg også antall pixler og fjernet ImageView fra liste for å forsøke å hindre at serveren krasjer på nytt. Figur 4.2 viser et eksempel på en databasemetode i C# og LINQ. Metoden henter den neste aktiviteten og brukes i widgeten. Figur 4.2 databasemetode 32

33 6.4 OPPSETT APPLIKASJONEN Applikasjonen er bygget opp av ni menyer: 1. Innlogging 2. Registrer ny bruker 3. MainActivity/uke 4. DayActivity/dag 5. Innstillinger 6. ActivityUser/aktivitet på bruker 7. NyActivity/lag en helt ny aktivitet 8. Sjekkliste 9. Handlingskjede Registrer ny bruker ligger under innlogging. ActivityUser ligger under innstillinger og nyactivity ligger under ActivityUser. Opprinnelig hadde jeg to moduser: administrator og bruker. Det ble derimot for tungvint, så isteden valgte jeg å fjerne administratormodusen og heller legge til et passord for enkelte av funksjonene. De opprinnelige nettverkskartene så slik ut: Figur 5.1 nettverkskart før endring: bruker 33

34 Brukerens nettverkskart er svært enkelt, med kun noen få menyer. Når applikasjonen åpnes blir bruker sendt til applikasjonens startside så fremt administrator ikke har logget ham eller henne ut. Dag kan nåes gjennom uke, aktivitet og sjekkliste kan nåes gjennom uke og dag. Figur 5.2 nettverkskart før endring: administrator Administrators nettverkskart er langt mer avansert med flere menyer. Administrator har også tilgang til mange funksjoner som ikke er nødvendige, som handlingskjede og sjekkliste. I utgangspunktet hadde jeg tenkte at når administrator legger til en ny aktivitet skal han eller hun i tillegg til å velge aktivitet, også velger brukere fra en liste. Problemer var at denne løsningen var tungvint å bruke. Det er derfor den ene klassen heter ActivityUser; 34

35 det er her aktiviteten legges på bruker. Nå er hele denne modusen fjernet slik at administrator må logge inn via brukerens profil ved å skrive inn et passord. Dette passordet er likt for alle administratorer. Figur 5.3 nettverkskart etter endring Innstillinger ligger kun i MainActivity/uke for ikke å skape unødvendige forvirringer. Handlingskjede/aktivitet og sjekkliste kan nåes gjennom uke eller dag. Dag kan nåes gjennom uke. Aktivitet på bruker kan nåes gjennom innstillinger og ny aktivitet kan nåes gjennom aktivitet på bruker. 6.5 SERVER/KLIENT Nettbrett og mobiler som kjører applikasjonen kommuniserer med serveren ved hjelp av internett. Applikasjonen er avhengig av internettilgang for å kunne kjøre. I Java-klassene sender applikasjonen forespørsler til serveren som deler ressurser med klienten. Figur 5.4 server/klient 35

36 6.6 TESTING BRUKERTESTING Brukertestingen av applikasjon foregikk ved at de ansatte ved sykehuset testet applikasjonen. De har god erfaring med hvordan brukerne tenker og hva de trenger av en applikasjon. Første brukertesting foregikk ved at de to ansatte satt i hvert sitt rom og testet applikasjonen hver for seg. På den måten kunne vi sammenlikne meningene deres til slutt. De to andre brukertestingene foregikk underveis i prosjektperioden etter at enkelte av modulene var ferdige. Oppdragsgiver testet brukergrensesnittet mens jeg forklarte og de kom med viktige innspill. Da applikasjonen var tilnærmet ferdig brukertestet oppdragsgiver applikasjonen en siste gang. De andre gruppene gjennomførte brukertestingen blant sluttbrukere, men dette ga ikke like mange viktige innspill fordi applikasjonen isåfall måtte testes over tid. Av den grunn og på grunn av mangel på tid var det derfor bedre at de ansatte ved OUS testet applikasjonen. Under bruketestingen kom det blant annet frem at poengsystemet burde fjernes og at menyen som viste alle trinnene i en handlingskjede også burde fjernes eller at den kunne deaktiveres i innstillinger. Videre kom det frem at skyggeleggingen av fullførte aktiviteter ikke er tydelig nok. Derfor bør skyggelegging på sikt byttes ut med et ikon. Jeg var bekymret fordi logg ut kun var mulig hvis man var logget inn som administrator, men oppdragsgiver sa at det var det de ønsket og at det ellers kunne skapt store problemer for bruker. Ved siden av disse møtene har jeg også sendt screen shot på mail eller lagt det i Dropbox-folderen jeg deler med oppdragsgiver for å spørre hva de synes om endringer jeg har gjort. Dette var spesielt nyttig da jeg programmerte XML-koden til nyactivity TESTING AV KODE Jeg har testet koden ved å kjøre applikasjonen på en emulator. Jeg har trykket på alle knappene, fylt ut feltene både med korrekt og ikke-korrekt informasjon. Problemet med å teste på den innebygde emulatoren var at jeg flere ganger fikk feil fordi jeg trykket for fort på knappene eller at jeg klikket meg videre før alle bildene i MainActivity var lastet inn. Jeg har ikke fått til å kjøre koden på et nettbrett når jeg bruker Mac, derfor må jeg låne PCen til mentoren min og kjøre på hennes PC. Problemet er ikke koden eller nettbrettet fordi koden kjører på PC på nettbrettet. Nettbrettet er satt opp riktig. Derfor har jeg hovedsakelig testet applikasjonen ved å bruke den innebygde emulatoren og jeg har testet den på en Android-telefon når jeg har hatt tilgang AKSEPTTESTING Jeg hadde lyst til å lære å bruke flere programmer gjennom prosjektperioden, derfor valgte jeg å teste programmet i HP ALM. Jeg testet applikasjonen manuelt fordi det ville tatt for langt tid å lære seg automatisert testing. Testingen ble gjennomført ved at jeg definerte krav og releases og satte opp testene, mens en kollega 36

37 med aspergers syndrom gjennomførte testene. Vi brukte to ulike datamaskiner, applikasjonen kjørte på Macen, mens ALM kjørte på en PC. Et steg i testen gikk for eksempel på innlogging. Kollegaen min testet innloggingen i applikasjonen og markerte steget i testen som passed eller failed avhengig av resultatet. Jeg var til stede under testingen. Kollegaen min fikk ikke instrukser om hvordan programmet skulle kjøres, kun om hva programmet gikk ut på. For å gjennomføre testen må først releases defineres. Releases er utgivelser og er en milepælsplan med dato for prosjektstart og prosjektslutt. Figur 5.5 releases Deretter må kravene defineres. Kravene knyttes til cyclene i releases og testene knyttes til krav. Figur 5.6 kravspesifikasjon 37