bachelorprosjekt - hioastudent.cs.hioa.no/hovedprosjekter/data/2017/18/final bachelor rapp… · 6...

6

Bachelorprosjekt

BACHELORPROSJEKTETS TITTEL: MemoFrame

DATO: 24/05/17

ANTALL SIDER/BILAG: 173

PROSJEKTDELTAGERE:

Christopher Llanes Reyes (s236624)

Muddasar Hussain (s231841)

Raja Zulqurnine Ali (s236318)

Zain-Ul-Mubin Mushtaq (s236306)

INTERN VEILEDER:

Eva Hadler Vihovde

OPPDRAGSGIVER: HiOA Fakultet for teknologi, kunst og design

KONTAKTPERSON: Asieh Abolpour Mofrad

SAMMENDRAG: MemoFrame er et bachelorprosjekt i samarbeid med Fakultet for Teknologi, Kunst og Design ved Høgskolen i Oslo og Akershus. Dette prosjektet går ut på å utvikle en applikasjon som skal brukes til forskning av demenspasienter og for hver enkelt bruker som hovedsakelig ønsker å forbedre hukommelsen sin.

Vår løsning består av en webapplikasjon, en IOS versjon tilpasset iPad enheter, og en administrasjonsløsning. For forskere skal applikasjonen fungere som et datainnsamlingsverktøy, der nyskapende øyesporingsteknologi tas i bruk. For brukerne skal applikasjonen gi mulighet for å utføre ulike tester, hvor disse testene simulerer en artig spillopplevelse.

På webløsningen har vi benyttet oss av Angular 2 med Typescript, og for IOS applikasjonen har vi

benyttet oss av programmeringsspråket Swift 3.0. Administrasjonsløsningen er utviklet i PHP som

kan brukes for å administrere innholdet i applikasjonen. Som en felles backend løsning har vi brukt

ExpressJS-rammeverket i NodeJS til å utvikle et REST API-grensesnitt mellom klientene våre og

serveren.

3 STIKKORD:

Forskning

Demens

Moderne teknologier

7

Forord

I samarbeid med Høgskolen i Oslo og Akershus har vi utviklet en applikasjon som er tilpasset

demente pasienter, og enhver bruker som ønsker å trene hukommelsen sin. Applikasjonen

fungerer som et datainnsamlingsverktøy for forskere, og for brukerne skal applikasjonen

simulere en artig spillopplevelse. Applikasjonen er tilrettelagt for videreutvikling ettersom

dette var et ønske fra oppdragsgiver, og er også tilpasset et bredt utvalg av plattformer.

Denne rapporten vil beskrive utviklingsprosessen for vår bacheloroppgave, og innebærer alt

fra planlegging til endelig sluttprodukt. Rapporten er optimalisert for å leses elektronisk,

men kan fint leses som et hefte i papirform. Relevante lenker og nærmere informasjon er

plassert nederst på hver side i fotnoten, og er referert til i teksten. Siste kapittel omhandler

vedlegg hvor vi har blant annet lagt til referanseliste og en terminologioversikt for ord som

kan være tvetydige.

Vi vil gjerne takke vår veileder Eva Hadler Vihovde for å ha fulgt oss opp hele veien, og for å

ha bidratt med tilbakemeldinger og gode tips underveis. Videre vil vi gjerne takke vår

oppdragsgiver Asieh Abolpour Mofrad, for at hun alltid var tilgjengelig og stilte opp med

nødvendig materiale. Vi vil også takke Hugo Lewi Hammer og Anis Yazidi for sine innspill til

koden og systemet.

8

Innholdsfortegnelse

1 Presentasjon ...................................................................................................................................................... 18

1.1 Innledning ................................................................................................................................................... 18

1.2 Hvem er vi? ................................................................................................................................................. 19

1.3 Hvem jobber vi for? .................................................................................................................................... 20

1.4 Bakgrunn for oppgaven .............................................................................................................................. 21

1.5 Kort om dagens situasjon ........................................................................................................................... 21

1.6 «MemoFrame» ........................................................................................................................................... 22

1.6.1 Konseptet ”MemoFrame”.................................................................................................................... 22

1.6.2 Fordeler med vår løsning ..................................................................................................................... 23

1.6.3 Bruk av symmetri test i applikasjonen ................................................................................................. 24

1.6.4 Liknende løsninger ute i markedet ...................................................................................................... 24

1.7 Konklusjon ................................................................................................................................................... 25

2 Brukerveiledninger............................................................................................................................................. 26

2.1 Konseptavklaring / Begrepsdefinisjoner ..................................................................................................... 26

2.1.1 Test ....................................................................................................................................................... 27

2.1.2 Testrunde ............................................................................................................................................. 27

2.2 Gameplay / Gjennomføring av test ............................................................................................................ 27

2.3 Bruk av webapplikasjon og ios applikasjon ................................................................................................ 31

2.3.1 Bruk av webapplikasjonen ................................................................................................................... 31

2.3.2 Bruk av ios applikasjon ........................................................................................................................ 32

2.3.3 Startmeny............................................................................................................................................. 32

2.3.4 Flere muligheter ................................................................................................................................... 33

2.3.5 Kontakt oss ........................................................................................................................................... 33

2.3.6 Mer informasjon .................................................................................................................................. 34

9

2.3.7 Demonstrasjon ..................................................................................................................................... 34

2.3.8 Test med kode ..................................................................................................................................... 34

2.3.9 Registrer ny bruker .............................................................................................................................. 35

2.3.10 Glemt passord .................................................................................................................................... 36

2.3.11 Logg inn .............................................................................................................................................. 37

2.3.12 Hovedmeny ........................................................................................................................................ 38

2.3.13 Instillinger .......................................................................................................................................... 38

2.3.14 Endre passord .................................................................................................................................... 39

2.3.15 Testvalg .............................................................................................................................................. 40

2.3.16 Bildetest ............................................................................................................................................. 40

2.4 Administrasjonspanelet .............................................................................................................................. 41

2.4.1 Tester ................................................................................................................................................... 42

2.4.2 Pinkoder ............................................................................................................................................... 47

3 Produktbeskrivelse............................................................................................................................................. 49

3.1 Beskrivelse av løsningen ............................................................................................................................. 50

3.2 Tilgjengelighet og designvalg ...................................................................................................................... 52

3.2.1 WCAG 2.0 ............................................................................................................................................. 52

3.2.2 Brukervennlighet ................................................................................................................................. 53

3.2.2.1 Tilbydelser ..................................................................................................................................... 53

3.2.2.2 Tilbakemeldinger .......................................................................................................................... 54

3.2.2.3 Metaforer ...................................................................................................................................... 55

3.2.2.4 Sperring av ugyldige handlinger ................................................................................................... 55

3.2.2.5 Forgrunn og bakgrunn .................................................................................................................. 56

3.2.2.6 Konsistens, likhet og gruppering .................................................................................................. 56

3.2.2.7 Tekst og lesbarhet ......................................................................................................................... 57

3.2.2.8 Navngiving .................................................................................................................................... 58

10

3.2.2.9 Bruk av ikoner ............................................................................................................................... 59

3.2.2.10 Farger og kontraster ................................................................................................................... 59

3.2.2.11 Organiseringsstruktur ................................................................................................................. 61

3.2.2.12 Design for målgruppen ............................................................................................................... 61

3.3 Backend ....................................................................................................................................................... 62

3.3.1 NodeJS server ...................................................................................................................................... 62

3.3.1.1 NodeJS i backend .......................................................................................................................... 62

3.3.1.1.1 Node Package Manager ......................................................................................................... 62

3.3.1.2 ExpressJS server ............................................................................................................................ 63

3.3.1.3 REST API ........................................................................................................................................ 63

3.3.1.3.1 Tokenbasert Autentisering .................................................................................................... 63

3.3.1.3.1.1 JSON Web Token (JWT) .................................................................................................. 64

3.3.1.3.2 API Struktur ............................................................................................................................ 65

3.3.1.3.2.1 URL-format ..................................................................................................................... 65

3.3.1.3.3.2 Forespørsel krav ............................................................................................................. 66

3.3.1.3.3.3 Respons format ............................................................................................................... 67

3.3.1.3.3 API Referanse ......................................................................................................................... 68

3.3.1.3.3.1 Autentisering .................................................................................................................. 69

3.3.1.3.3.1.1 POST /api/authenticate ........................................................................................... 69

3.3.1.3.3.2 Brukeradministrasjon ..................................................................................................... 69

3.3.1.3.3.2.1 POST /api/users ....................................................................................................... 69

3.3.1.3.3.2.2 GET /api/users ......................................................................................................... 70

Parametre: ingen .................................................................................................................................. 70

3.3.1.3.3.2.3 GET /api/users/:email .............................................................................................. 70

Parametre: email:string ........................................................................................................................ 70

3.3.1.3.3.2.4 PUT /api/users ......................................................................................................... 70

11

3.3.1.3.3.2.5 DELETE /api/users/:email ........................................................................................ 71


3.3.1.3.3.2.6 POST /api/users/reset ............................................................................................. 71


3.3.1.3.3.2.7 POST /api/users/sendInfo........................................................................................ 71


3.3.1.3.3.2.8 POST /api/admin ...................................................................................................... 72

3.3.1.3.3.2.9 GET /api/admin ........................................................................................................ 72

Parametre: ingen .................................................................................................................................. 72

3.3.1.3.3.3 Tester .............................................................................................................................. 72

3.3.1.3.3.3.1 POST /api/test .......................................................................................................... 72

3.3.1.3.3.3.2 GET /api/test ............................................................................................................ 73

Parametre: ingen .................................................................................................................................. 73

3.3.1.3.3.3.3 GET /api/test/:testid ................................................................................................ 74

Parametre: testid:int ............................................................................................................................. 74

3.3.1.3.3.3.4 POST /api/test/runde .............................................................................................. 74

3.3.1.3.3.3.5 GET /api/test/runde ................................................................................................ 75

Parametre: testid:int ............................................................................................................................. 75

3.3.1.3.3.3.6 GET /api/test/runde/:rundeid ................................................................................. 76

Parametre (route): rundeid:int Parametre (GET): testid:int ............................................................ 76

3.3.1.3.3.3.7 POST /api/resultat ................................................................................................... 77

3.3.1.3.3.4 Pinkoder .......................................................................................................................... 77

3.3.1.3.3.4.1 POST /api/pincode ................................................................................................... 77

3.3.1.3.3.4.2 GET /api/pincode ..................................................................................................... 77

Parametre: ingen .............................................................................................................................. 77

3.3.1.3.3.4.3 GET /api/pincode/test ............................................................................................. 78

12

Parametre: pincode:int ..................................................................................................................... 78

3.3.1.3.3.4.4 GET /api/pincode/validate ...................................................................................... 78

Parametre: kode:int .......................................................................................................................... 78

3.3.1.3.3.4.5 POST /api/pincode/login ......................................................................................... 79

Parametre: kode:int .......................................................................................................................... 79

3.3.1.3.3.5 Annet .............................................................................................................................. 79

3.3.1.3.3.5.1 POST /api/contact .................................................................................................... 80

3.3.2 Apache server ...................................................................................................................................... 80

3.3.2.1 Statisk web server ......................................................................................................................... 80

3.3.3 Database .............................................................................................................................................. 80

3.3.3.1 Type database ............................................................................................................................... 80

3.3.3.2 Databasemodell ............................................................................................................................ 80

3.3.3.2.1 Logisk skjema ......................................................................................................................... 81

4.1 Klientside ..................................................................................................................................................... 81

4.1.1 Teknologier .......................................................................................................................................... 82

4.1.1.1 IOS teknologier ............................................................................................................................. 82

4.3.1.2 Rammeverk/biblioteker ................................................................................................................ 82

4.3.1.3 PopupDialog .................................................................................................................................. 83

4.3.1.4 Alamofire: ..................................................................................................................................... 86

4.3.1.5 AlamofireImage ............................................................................................................................ 87

4.3.1.6 FaceBook logginn .......................................................................................................................... 87

4.3.2 Swift 3 programmeringsspråk .............................................................................................................. 91

4.3.3 IOS kall mot Web-Api´et ...................................................................................................................... 91

4.3.4 Model View Controller ......................................................................................................................... 92

4.3.4.1 Model ............................................................................................................................................ 93

4.3.4.2 View .............................................................................................................................................. 94

13

4.3.4.3 Controller ...................................................................................................................................... 95

4.3.4.4 Klassediagram ............................................................................................................................... 96

4.3.4.5 Model View Controller struktur .................................................................................................... 98

4.3.6 CocoaPods ............................................................................................................................................ 99

4.3.7 Carthage ............................................................................................................................................. 100

4.3.7 Mappestruktur, filer og navngivning ................................................................................................. 102

4.4 Webapplikasjonen .................................................................................................................................... 104

4.4.1 App component ................................................................................................................................. 105

4.4.2 App route ........................................................................................................................................... 105

4.4.3 App template ..................................................................................................................................... 106

4.4.4 App Module ....................................................................................................................................... 106

4.4 EyeTracking: .............................................................................................................................................. 107

4.5 Admin panel .............................................................................................................................................. 108

4.5.1 Sideoversikt ........................................................................................................................................ 108

4.5.1.1 Dashboard ................................................................................................................................... 108

4.5.1.2 Testoversikt ................................................................................................................................. 109

4.5.1.2.1 Ny testrunde ........................................................................................................................ 109

4.5.1.2.1.1 Bildegalleri valg ............................................................................................................. 109

4.5.1.2.1.2 Bildegalleri antall valg ................................................................................................... 110

4.5.1.3 Ny test ......................................................................................................................................... 110

4.5.1.3.1 Testskjema ........................................................................................................................... 110

4.5.2 Oppbygg ............................................................................................................................................. 111

4.5.2.1 Type filer ..................................................................................................................................... 111

4.5.2.2 Skjelettmal for kode .................................................................................................................... 111

4.5.2.3 API kall......................................................................................................................................... 113

4.5.2.3.1 Httpful .................................................................................................................................. 114

14

4.7 Drift ........................................................................................................................................................... 115

4.8 Videreutvikling .......................................................................................................................................... 116

4.8.1 Administrasjonsløsning (klient) ......................................................................................................... 117

4.8.2 Webapplikasjon (klient) ..................................................................................................................... 117

4.8.3 IOS applikasjon ................................................................................................................................... 117

4.8.4 REST API ............................................................................................................................................. 118

4.9 Konklusjon ................................................................................................................................................. 118

5 Prosessdokumentasjon .................................................................................................................................... 119

5.1 Innledning ................................................................................................................................................. 119

5.2 Planlegging og metode ............................................................................................................................. 120

5.2.1 Utviklingsmetodikk ............................................................................................................................ 120

Smidig utviklingsmetodikk .................................................................................................................. 120

5.2.2 Fasene i prosjektet ............................................................................................................................. 121

5.2.2.1 Oppstart av prosjektet ........................................................................................................... 122

5.2.2.2 planlegging ............................................................................................................................ 122

5.2.2.3 gjennomføring ....................................................................................................................... 123

5.2.2.4 Prosjekt avsluttning og dokumentasjon med testing ............................................................... 124

5.2.4 Bruk av verktøy i planleggingen ....................................................................................................... 124

5.2.4.1 Verktøy for kommunikasjon ....................................................................................................... 125

5.2.4.2 Facebook ..................................................................................................................................... 125

5.2.4.3 Slack ............................................................................................................................................ 125

5.2.4.4 Trello ........................................................................................................................................... 127

5.2.4.5 Github ......................................................................................................................................... 128

5.2.5 Kompetanseutvikling ....................................................................................................................... 129

5.2.6 Budsjett .............................................................................................................................................. 131

5.3 Om utviklingsprosessen ............................................................................................................................ 131

15

5.3.1 Utfordringer og valg i løpet av prosjektperioden .............................................................................. 131

5.3.1.1 Valg av prosjekt ........................................................................................................................... 132

5.3.1.2 Valg av utviklingsmetodikk ........................................................................................................ 132

5.3.1.3 Valg av IOS applikasjon ............................................................................................................... 132

5.3.1.4 Valg av XCode 8........................................................................................................................... 133

5.3.1.5 Valg av Design ............................................................................................................................. 133

5.3.1.6 logo ............................................................................................................................................. 137

5.3.1.7 Valg av navn ................................................................................................................................ 138

5.3.1.8 Adminpanel ................................................................................................................................. 139

5.3.1.9 Eyetracking ................................................................................................................................. 139

5.3.1.10 token/sikkerhet......................................................................................................................... 139

5.3.1.11 utfordringer med arbeidsgiver ................................................................................................. 140

5.3.1.12 Utfordring kall mot server - IOS applikasjon Synkronisering:................................................... 140

5.3.2 Beskrivelse av sprintene .................................................................................................................... 141

5.3.3 Utviklingsverktøy ............................................................................................................................... 143

5.3.3.1 Xcode .......................................................................................................................................... 143

5.3.3.2 Microsoft Visual studio ............................................................................................................... 145

5.3.4 Refleksjoner fra utviklingsfasen ......................................................................................................... 146

5.5 Avslutning ................................................................................................................................................. 147

6 Testing .............................................................................................................................................................. 148

6.1 Brukertesting ........................................................................................................................................ 149

6.2 Verktøy .................................................................................................................................................. 150

6.1.1 Xcode 8 som testing verktøy.............................................................................................................. 150

6.3 Planlegging ............................................................................................................................................ 150

6.5 Gjennomføring .......................................................................................................................................... 151

6.6 Produktesting ............................................................................................................................................ 151

16

6.6.1 Enheter og skjermstørrelse ............................................................................................................... 151

6.6.1.1 IOS applikasjon ............................................................................................................................ 152

6.6.1.2 Webapplikasjon .......................................................................................................................... 152

6.6.1.3 Adminløsning .............................................................................................................................. 153

6.6.2 IOS applikasjon .................................................................................................................................. 153

6.6.3 Adminløsning ..................................................................................................................................... 155

6.6.4 Rest API med databasen .................................................................................................................... 155

6.7 Enhetstesting ............................................................................................................................................ 155

6.7.1 IOS Unit Testing ................................................................................................................................. 156

6.8 Ytelsestest ................................................................................................................................................. 158

6.9 Sikkerhet ................................................................................................................................................... 159

6.10 Integrasjonstesting ................................................................................................................................. 159

6.10.1 Postman ........................................................................................................................................... 159

6.10.2 Server ............................................................................................................................................... 161

7 Vedlegg ............................................................................................................................................................ 162

7.1 Kravspesifikasjon....................................................................................................................................... 162

Forord ............................................................................................................................................................. 162

3 System Beskrivelse ............................................................................................................................. 163

3.1 System krav ..................................................................................................................................... 164

3.1.1 Webapp .................................................................................................................................... 164

3.1.2 iOS ............................................................................................................................................. 166

3.1.3 Administrasjonsløsning ............................................................................................................ 168

Tekniske krav .............................................................................................................................................. 169

Krav til koden .............................................................................................................................................. 169

Krav til grensesnitt ...................................................................................................................................... 169

Bruk og brukervennlighet ........................................................................................................................... 169

17

7.2 Smidig arbeidsmetodikk – Scrum ............................................................................................................. 170

Sprint retrospective .................................................................................................................................... 173

7.3 Risikoanalyse ............................................................................................................................................. 173

18

1 Presentasjon

Formålet med dette kapittelet er å presentere prosjektet for leseren. Det anbefales at

leseren starter med å lese dette kapittelet for å få en god oversikt og samtidig tilegne seg

bakgrunnskunnskap rundt prosjektet. Kapittelet krever ingen programmeringstekniske

kunnskaper.

1.1 Innledning

Forskning viser at nesten hver femte person får demens i løpet av livet1. Som den yngre

andelen av befolkningen tenker vi ikke så mye over eldrebølgen og utfordringene som

kommer derav. Det finnes imidlertid noe i generasjonen som er til stor fordel -- teknologi har

aldri vært i større vekst enn noensinne før. Dørene til en digital verden er bare et fingertrykk

unna, og det gir enormt mange muligheter til innovative løsninger. Bachelorprosjektet vårt

legger fokus i bruk av teknologi hos den eldre generasjonen, og hvordan det kan bidra til å

løse utfordringer på en effektiv måte.

Det viser seg at hele 1,5% av befolkningen lider av demente symptomer, og det er en

utvilsom sannhet at vi en dag vil være i en lignende situasjon. Som kompetente brukere av

teknologi i hverdagen, er det også vår oppgave å løse samfunnsproblemer som kan være oss

alle til fordel i det store bildet og det lange løp. Vi ser hvordan utviklingen av datamaskiner

har lettet arbeidet i forskning, medisin, utdanning, og ikke minst, hverdagen vår. Eldre

metoder blir stadig erstattet med oppdaterte digitale løsninger, og vi ser hvordan dette

forenkler alt. En digital oppgradering av metodene som brukes hos demente pasienter, vil

kunne akselerere minneforbedringen eksponentielt.

Hovedoppgaven vi har fått fra Høgskolen i Oslo og Akershus (HiOA), går i hovedtrekk ut på å

utvikle en applikasjon for å forbedre minnet til demente pasienter. Oppdragsgiveren ønsket

først og fremst en applikasjon for å samle inn data for forskere, gjøre det mulig for brukere å

utføre ulike tester, og at applikasjonen kunne bli brukt som et treningsverktøy for å trene

1 https://www.fhi.no/nettpub/hin/helse-og-sykdom/demens---folkehelserapporten-2014/#hovedpunkter

19

hukommelsen til brukerne. Det var også et ønske om å implementere “eye-tracking”

teknologi i applikasjonen, ettersom de ville kartlegge sammenhengen mellom øyebevegelser

og brukerens atferd når brukeren gjennomfører de ulike testene.

Med alt det ovennevnte i bakhodet, sammen med ønsket vårt å utvikle et samfunnsnyttig

digitalt verktøy, tok vi på oss oppdraget om å utvikle en web- og mobilapplikasjon som tar i

bruk nyskapende øyesporingsteknologi. Denne kombinasjonen er under utvikling, og kan

bidra til uvurderlig forskning innenfor demens. I tillegg skal testene, som brukerne skal ta,

basere seg på arbeidet til professor Erik Arntzen ved fakultetet for helsefag ved HiOA. Disse

testene er spesielt utviklet for personer som har demens.

1.2 Hvem er vi?

Vi er en gruppe på fire studenter som studerer i samme kull ved HiOA. To og to av oss har

kjent hverandre fra første året på skolen, men denne gruppedannelsen er en ny og

uvurderlig erfaring vi har godt av. Som en gruppe har alle en bred forståelse av ulike

aspekter innenfor informatikk og data, men vi har også våre egne spesialiserte felter. Ved å

dekke hverandres svakheter utgjør vi en allsidig gruppe med et godt grunnlag for å takle nye

utfordringer sammen.

Zain-ul-Mubin Mushtaq går på dataingeniør linjen ved HiOA, og står med bred erfaring som

fullstack utvikler. Han har tatt flere IT-relaterte frilansjobber og jobbet med programmering i

fritiden, noe som gir han solide ferdigheter innenfor frontend- og backend-utvikling.

Raja Zulqurnine Ali går på dataingeniør linjen ved HiOA, og har erfaring innen HTML, CSS og

PHP. Raja satte opp en egen server i Rasperry PI til dette prosjektet, som vi brukte som

backend i prosjektet vårt og til å teste systemet. Utover det har Raja tatt mange oppdrag

som frilanser hvor han stort sett har jobbet med frontend.

Muddasar Hussain går på dataingeniør linjen ved HiOA, og er interessert i tilegne seg mye ny

kunnskap på kort tid. Han har nylig utviklet en IOS applikasjon (Tolk1) som ligger ute på

20

Apple sin ”App store”. Dette gir han bred erfaring rundt det å lage en IOS applikasjon, og han forstår

rammene rundt dette og hvordan det fungerer. I fritiden er Muddasar en selverklært psykolog, noe som

har stor nytte for oppgaven.

Christopher Llanes Reyes går på informasjonsteknologi linjen ved HiOA, og har vært medlem

av en komité for skolen hvor oppgaven var å forbedre TKD sine nettsider. Christopher

interesserer seg for design, brukervennlighet, informasjonsarkitektur og universell

utforming. Han har vært studentassistent i faget Databaser, og har bl.a. utviklet en robust

database for oppgaven vår. Christopher har også vært med å utvikle registrering nettstedet

for studentforeningen ”HiOA Gaming”.

1.3 Hvem jobber vi for?

Vi valgte en bacheloroppgave som ble gitt på skolen hvor vi studerer, nemlig Høgskolen i

Oslo og Akershus. HiOA er en skole som tilbyr høyere utdanning innenfor en rekke ulike

profesjonsstudier og i dag er er HiOA landets største statlige høgskole2.

Skolens historiske bakgrunn strekker seg langt tilbake i tid. Noen av HiOAs utdanninger har

eksistert som utdanningsinstitusjoner i over 100 år, blant annet ingeniør-, lærer- og

sykepleierutdanningene. I 1994 ble 13 selvstendige høgskoler i Oslo slått sammen til èn

Høgskole. Deretter i 2011 slo Høgskolen i Oslo og Høgskolen i Akershus seg sammen til den

skolen slik vi kjenner den i dag.

Forskning og utviklingsarbeid er en viktig del av virksomheten i Høgskolen i Oslo og

Akershus. Vår bacheloroppgave, som benytter seg av tester som er spesielt tilpasset

dementia personer, er basert på forskning gjort av professor Erik Arntzen3 ved Fakultet for

helsefag (HF) i HiOA.

2 http://www.hioa.no/Om-HiOA/Mer-om-HiOA 3 Professor Erik Arntzen har lang erfaring med å utvikle treningsoppgaver for demenspasienter. Mer om hans publikasjoner

og arbeid: https://www.hioa.no/tilsatt/earntzen

21

Prosjektleder for vår bacheloroppgave er doktorgradsstipendiat Asieh Abolpour Mofrad.

Asieh har fått tildelt et forskningsprosjekt av professor Erik Arntzen og er også ansatt ved

HiOA. Asieh Abolpour Mofrad sitt prosjekt4 startet 21.november 2016, og fra 17 januar 2017

ble vi en del av prosjektet og fikk muligheten til å delta i oppgaven.

I vår bacheloroppgave utvikler vi først og fremst et verktøy som hun kan bruke videre i

hennes forskningsprosjekt av dementia ved HiOA. Videre er førsteamanuesis Hugo Lewi

Hammer og førsteamanuesis Anis Yazidi involverte personer fra HiOA, og de har bidratt oss

med både teknisk og praktisk veiledning og assistanse under bachelorprosjektet vårt.

I vår bacheloroppgave utvikler vi først og fremst et verktøy som hun kan bruke videre i

hennes forskningsprosjekt av dementia ved HiOA. Videre er førsteamanuesis Hugo Lewi

Hammer og førsteamanuesis Anis Yazidi involverte personer fra HiOA, og de har bidratt oss

med både teknisk og praktisk veiledning og assistanse under bachelorprosjektet vårt.

1.4 Bakgrunn for oppgaven

Tidlig i startfasen var det visse kriterier vi ønsket oppgaven skulle oppfylle. Vi var ute etter en

oppgave hvor vi kunne utnytte egenskapene til hvert medlem i gruppa, og samtidig hjelpe

andre mennesker og bidra med noe godt. Vi så på oppgavene HiOA hadde utlyst og der fant

vi en oppgave som interesserte oss.

1.5 Kort om dagens situasjon

Demens er en fellesbetegnelse på en tilstand som skyldes ulike typer sykdom eller skader i

hjernen. Noen vanlige symptomer på demens innebærer dårligere hukommelse, problemer

med å uttrykke seg, endringer i humøret og vanskeligheter med å utføre hverdagslige

oppgaver. Alzheimer sykdom er den mest utbredte årsaken til demens. Hvis man har

demens er det viktig å få diagnosen tidlig slik at man kan få den tilrettelagte behandlingen og

oppfølgingen man trenger.

4 https://hioa.mynetworkglobal.com/dk/what:job/jobID:101475/where

22

For å stille diagnosen demens benytter legen seg av blant annet ulike metoder5. Disse

metodene er blant annet ulike former for hukommelsesoppgaver, eller tester, pasienten må

utføre.

En av metodene er at legen presenterer pasienten med ulike gjenstander, for så å deretter

dekke til eller gjemme vekk disse gjenstandene. Deretter må pasienten fortelle hvilke av de

gjenstandene personen klarer å huske. Vårt verktøy gir muligheten å simulere disse testene

på en elektronisk måte.

1.6 «MemoFrame»

Oppdragsgiver ønsket en applikasjon for demente folk som skulle være tilgjengelig i de fleste

enheter. Vi foreslo også at vi kunne utvikle en IOS applikasjon parallelt ved siden av

webapplikasjonen ettersom dette fører til en mer tilpasset opplevelse på IPad enheter, og

dette var noe som ble godt tatt imot av oppdragsgiver. Det var også et ønske om å

implementere “eye-tracking” teknologi i applikasjonen.

Det var viktig at applikasjonen skulle være tilrettelagt for videreutvikling, ettersom dette var

et primært krav fra oppdragsgiver. Vår oppgave var først og fremst å få det fundamentale i

applikasjonen på plass, slik at arbeidsgiver kunne videreutvikle og samtidig bruke den i sin

forskning. Derfor har vi utviklet løsningen på en slik måte at

den kan lett bli brukt til andre formål ved å ha fokus på at verktøyet er utformet på en svært

generisk måte.

1.6.1 Konseptet ”MemoFrame”

Applikasjonen vi tilbyr brukerne er MemoFrame. Konseptet bak MemoFrame er å hjelpe

demente pasienter for å trene hukommelse, og bruke applikasjonen som et verktøy for

5 https://www.nrk.no/tvaksjonen/her-blir-selda-testet-for-demens-1.11307461 https://www.nrk.no/tvaksjonen/ta-

demenstester-her-1.11274937

https://www.nrk.no/tvaksjonen/her-blir-selda-testet-for-demens-1.11307461














https://www.nrk.no/tvaksjonen/ta-demenstester-her-1.11274937










23

forskere. Denne applikasjonen vil gjøre det enklere demente pasienter gjennom testene

forskere lager.

Vi har som nevnt tidligere utviklet en applikasjonen som er tilpasset to ulike løsninger. En

webapplikasjon vil i praksis gjøre applikasjonen tilgjengelig i hvilken som helst enhet så lenge

man har tilgang til en nettleser. Versjonen for iPad enheter er utviklet fordi

Ettersom en administrasjonsløsning er helt avgjørende for å få til konseptet om å samle inn

data fra applikasjonen, har vi utviklet en felles administrasjonsløsning for begge plattformer.

På denne måten slipper man det problemet med at man alltid trenger å oppdatere begge

enhetene. nå ønsker å legge en ting til felles å administrere fra forskjellige steder og man har

et sted samlet. Hvordan bruke. Mer om de ulike kan du lese på kapittel om

”produktbeskrivelse” og ”brukerveiledning”.

1.6.2 Fordeler med vår løsning

Det finnes flere fordeler ved å utføre disse testene elektronisk. Innsamling av data over tiden

en pasient bruker på en test, eller hvilke gjenstander personen rettet blikket fysisk mot (ved

hjelp av øyesporing) er enklere å lagre i en database når man benytter seg av elektroniske

enheter.

Fra et praktisk perspektiv slipper man også nødvendigheten for fysiske gjenstander, slik at

man på den måten kan for eksempel vise pasienten ulike bekjente eller perioder som har

hatt betydning i pasientens liv.

Det har vært forskning som sier at bruken av nettbrett kan gi flere fordeler når det gjelder å

assistere eldre med teknologi. Blant annet foretrekker eldre personer større knapper og det

er enklere for dem å bruke dette (å tilpasse størrelsen etter behov eller å lage større

knapper i en applikasjon, krever mindre arbeid og materiale enn å produsere en fysisk

knapp). Et nettbrett krever også direkte brukerinteraksjon, og man slipper behovet for flere

24

elektroniske komponenter slik som datamus, tastatur og skjerm6, komponenter som kan

være slitsomt, krevende og tar mer tid for eldre å lære seg.

En studie gjort av Pew Research angående mobile enheters demografi7, sier at den eldre

generasjonen ofte foretrekker å bruke nettbrett fremfor den yngre generasjonen. Den yngre

generasjonen velger heller å bruke mobilen som sin daglige teknologiske plattform. Man

skulle tro at dette ikke er tilfelle, ettersom at teknologi ofte er en representasjon på verktøy

som er nytt. Det er derfor naturlig å tro at det er den yngre generasjonen som er den største

brukeren av nettbrett, men ifølge denne studien er det ikke slik.

1.6.3 Bruk av symmetri test i applikasjonen

Det hovedsakelige testoppsettet vi har brukt på vår applikasjon ( er som tidligere nevnt

basert på forskningen gjort av professor Erik Arntzen. Den testen vi bruker i applikasjonen

kalles for symmetri test 8(på engelsk ”Equivalence test”).

Slik en test fungerer er at man får presentert en gjenstand (eller flere gjenstander) i en

bestemt periode, for så at den samme gjenstanden forsvinner etter en bestemt periode.

Deretter skal personen prøve å gjenkjenne gjenstandene og fortelle hvilke gjenstander

personen kan huske. For å øke vanskelighetsgraden kan man forlenge eller forkorte den

tiden mellom da personen så gjenstanden og når personen skal angi sitt svar.

1.6.4 Liknende løsninger ute i markedet

I dag finnes det mange ulike applikasjoner som er tilpasset demente personer. Applikasjonen

”Sea Hero Quest” 9er en applikasjon som har fått mye oppmerksomhet i det siste.

Applikasjonen er laget på en morsom og innovativ måte slik at man opplever erfaringen av å

spille et eventyrspill. Det er derimot mye datainnsamling som skjer i bakgrunnen hele tiden.

6 https://core.ac.uk/download/pdf/11309888.pdf 7 http://www.pewinternet.org/files/old-media//Files/Reports/2013/PIP_Tablets%20and%20ereaders%20update_101813.pdf 8 http://equivalence.net/pdf/Om%20stimulusekvivalens.pdf. 9 Du kan prøve ut spillet her http://www.seaheroquest.com/en/.

http://equivalence.net/pdf/Om%20stimulusekvivalens.pdf

http://equivalence.net/pdf/Om%20stimulusekvivalens.pdf

25

Når det gjelder ”eye-tracking” teknologi og bruken av dette i applikasjoner, er dette fortsatt

ny teknologi som er under utvikling. Vi synes det er veldig nyttig og spennende å ta i bruk slik

teknologi i vår applikasjon. Vi kommer å gå i dypere detalj i om eye tracking senere i

rapporten.

1.7 Konklusjon

Som vi har nevnt i tidligere avsnitt viser forskning at riktig bruk av teknologi kan være

praktisk for å assistere eldre mennesker. Teknologien er under stadig utvikling, og bør være

noe som kan ha nytteverdi for alle, også for de eldre. Eldre personer blir ofte utelukket

ettersom moderne teknologi ofte har fokus på yngre, en generasjonen som ofte er vokst opp

og er vant med dette.

MemoFrame er en del av et større forskningsprosjekt på HiOA, og vi ønsker at MemoFrame

skal knytte eldre mennesker med moderne teknologi, samt tilby de et verktøy hvor de kan

trene opp sin hukommelse.

Løsningen er utviklet ut ifra et solid og allsidig grunnlag, og har derfor enormt

utviklingspotensiale og kan brukes til andre formål. MemoFrame er en applikasjon som vil

ha stor nytteverdi for samfunnet.

Vi har fått stor utbytte av bachelorprosjektet, som både har vært spennende og lærerikt. I

sin natur var oppgaven av veldig stor omfang, noe som ga oss relativ stor frihet til å velge

teknologi og fremgangsmåte selv. Vi tok på oss utfordringen av å bruke moderne teknologier

og rammeverk, med tanke på at det skal være best tilpasset dagens og fremtidige

standarder.

26

2 Brukerveiledninger

Løsningen vår består av en web- og iOS applikasjon, samt en administrasjonsløsning for å

kunne administrere systemet.

For at brukeren skal enkelt lære å ta i bruk systemet, følger brukergrensesnittet i

applikasjonen samme utgangspunkt i de ulike plattformene.

Brukerveiledning er beregnet på å gi leseren en detaljert beskrivelse på hvordan de skal

bruke den løsningen som er tilpasset dem, enten det er webapplikasjonen, IOS applikasjon

eller administrasjonsløsningen.

I webapplikasjonen har vi valgt å vise noen få bilder på nettleser i en datamaskin, ettersom

applikasjonen er responsiv og vil ha samme utseendet enten det er mobil, nettbrett eller

skjerm. Vi vil derfor kun vise hvordan brukergrensesnittet er i iPad (iOS) plattformen,

ettersom det ikke er nødvendig å repetere samme skjermbildene.

Det er ikke nødvendig med programmatisk tekniske kunnskaper for å ta i bruk

brukerveiledningen.

2.1 Konseptavklaring / Begrepsdefinisjoner

Her beskrives noen essensielle begrep for oppgaven i mer detalj for å oppklare

misforståelser som kan oppstå. For denne oppgaven og fra kravspesifikasjonen fra

oppdragsgiveren var det en del ord og uttrykk med tvetydigheter vi måtte få avklart for å

komme til enighet og gjensidig forståelse. Disse teoretiske begrepene og konseptene er listet

nedenfor med klart skille, og de endelige definisjonene vi bestemte oss for.

27

2.1.1 Test

En test vil si en samling av en eller flere testrunder som ligger i en bestemt rekkefølge. En slik

test kan tas av en bruker, som da besvarer testrundene enkeltvis og ender opp med et

sluttresultat som er knyttet til hele testen.

2.1.2 Testrunde

En testrunde inngår i en test, og kan bestå av en instruks og minst ett bilde. Et hovedbilde

vises i starten av testrunden, etterfulgt av forsinkelsestid og deretter et rutenett med totalt

antall bilder lagret for testrunden. Slutten av en testrunde markeres etter valg av bilde i

rutenettet.

2.2 Gameplay / Gjennomføring av test

Delaytid = dette er tiden mellom et bilde og alternativer som vises i form av 2,3 eller 4 bilder.

Når bruker velger å ta testen vil han/hun komme til et vindu som ser slik ut:

Figur 2.2.1, Slik starter testen.

28

Brukeren vil se instruks/tekst for testen, teksten blir værende frem til bruker trykker på

“Start test” knappen.Etter at brukeren har trykket “Start test” vil brukeren se et bilde. Det

kan være hvilke som helst bilde her et et eksempel se figur 2.2.2:

Figur 2.2.2 Oppgave bildet.

Bruker kan avslutte testen når han/hun måtte ønske det ved å klikke på “Avslutt test”

knappen oppe til venstre.Oppe til høyre beskrives hvor mange oppgaver det er og hvilke

oppgave brukeren er på. Figur 2.2.2 viser at det er første bilde/oppgave av hele 3

oppgaver/bilder. Bildet blir vist i 2 sec før den forsvinner, etter at bildet er borte vil du se

dette vinduet(se figur 2.2.3):

figur 2.2.3 Tekst vises under delay tid.

29

Om bruker ønsker å avsluttet testen her, kan det trykkes på “Avslutt test” knappen oppe til

venstre.

Hver gang bruker ser “Avslutt test” knapp har de mulighet til å avslutte testen.

Dersom testen er demo test vil dette vinduet forsvinne etter 2 sec, har man valgt testen

etter å ha logget inn må man se på hva delay tiden er f,eks delaytid satt av til 5 sec så vil

dette vinduet bli værende for 5 sec.

Etter den tiden er endt vises 2,3 eller 4 nye bilder som alternativ:

Figur 2.2.4 Alternativer å velge mellom

Figur 2.2.4 viser alternativer for å gi svar, svaret her er å trykke på det bilde brukeren så sist.

Uansett hva bruker trykker på av alternativer vil neste vindu vise. Se figur 2.2.5

30

Figur 2.2.5 Tekst vises i delaytid

Svarte brukeren riktig blir bildet vist i figur 2.2.5 visende i dilaytid + 1 sec.

Varte delaytid 2 sec sist, er delay tiden nå 3 sec og dette bildet blir stående i 3 sec, hver gang

bruker svarer riktig blir delaytiden forlenget med 1 sec. Max en bruker kan ha på delay tid er

20 sec.

Er brukeren uheldig og svarer feil blir delaytiden trukket med 1 sec. Minste grense for

delaytid er 2 sec. Det vil si at dette vinduet vil bli visende delaytid + 1 sec lengre enn bildet

vist i figur 2.2.3 ved riktig svar eller at det vises i delaytid -1 sec ved feil svar.

Når delaytiden er over vises nytt bilde slik som vist i figur 2.2.2, dette er da bilde 2 av 3 vises i

2 sec etter det forsvinner bilder, avhengig av hva brukeren svarte sist er delaytiden

beregnet, bruker venter til nye alternativer vises. Slik fortsetter det til siste oppgave/bilde.

Etter at svaret er gitt på siste bildet, nytt vindu vises, se figur 2.2.6

31

Figur 2.2.6 Siste bilde som viser resultat

Dette bildet (figur 2.2.6) forteller brukeren om antall riktig han/hun fikk, her kan vi nå

avslutte testen. Tar brukeren demotest vil han/hun komme tilbake til det vinduet som ledet

til test vinduet (figur 2.2.1). Er testen tatt etter å ha logget inn vil brukeren bli dirigert til det

vinduet hvor de valgte testene.

2.3 Bruk av webapplikasjon og ios applikasjon

Webapplikasjonen og iOS applikasjonen er tilpasset demenspasienter men kan også brukes

av alle som ønsker å trene hukommelsen. Under vil vi presentere hver side som et “vindu”.

2.3.1 Bruk av webapplikasjonen

Applikasjonen kan benyttes via alle nettleserne på mobile enheter, nettbrett eller

datamaskiner uten nødvendig nedlasting av programvare. I webapplikasjonen er det støtte

for eye-tracking.

32

2.3.2 Bruk av ios applikasjon

iOS applikasjonen kan kun benyttes på iPad enheter. I nåværende tidspunkt kan man kun få

tilgang til applikasjonen ved hjelp av administrator, men i fremtiden skal de kunne bli lastet

ned fra App Store. Det er ikke implementert støtte for eye-tracking.

2.3.3 Startmeny

Startmenyen er det første vinduet man blir presentert med når man tar i bruk applikasjonen.

Alternativer i form av knapper som brukeren har tilgang til er

• logg inn

• ny bruker

• kode

• demonstrasjon

• flere muligheter

33

2.3.4 Flere muligheter

Trykker man på knappen “flere muligheter” fra “startmenyen” kommer man til vinduet

“flere muligheter”. Her blir man presentert med to nye knapper. Disse er “kontakt oss” og

“mer informasjon”. Vil man tilbake til “startmenyen” bruker man knappen “tilbake til

startmeny”.

2.3.5 Kontakt oss

I vinduet “kontakt oss” har man mulighet å sende inn kommentarer og tilbakemeldinger ved

å skrive inn i tekstfeltet som har grå bakgrunn og er plassert over e-post feltet. Tast så

deretter inn e-post addresse og trykk på knappen send. For å komme tilbake til flere

muligheter kan man trykke på knappen “flere muligheter”.

34

2.3.6 Mer informasjon

I iOS applikasjonen vil “mer informasjon” vinduet gi en tekstlig beskrivelse av hvor man kan

finne mer informasjon om applikasjonen. I webapplikasjonen vil “mer informasjon” vinduet

vise nærmere informasjon om applikasjonen. I dette vinduet har man mulighet å gå tilbake

til flere muligheter eller å gå direkte til startmeny ved hjelp av tilsvarende knapper.

2.3.7 Demonstrasjon

I Demonstrasjonvinduet har man mulighet å utføre en demonstrasjon av en test i

applikasjonen. Man kan enhver til velge å avslutte demoen om man ønsker.

2.3.8 Test med kode

I vinduet test med kode kan man komme til en tilsvarende test ved hjelp av kode. For å

komme til tilsvarende test taster man inn koden man har fått av administrator i tilsvarende

felt og trykker deretter på knappen start test. Fra dette vinduet kan man komme tilbake til

startmenyen ved å bruke knappen “tilbake starmeny”.

35

2.3.9 Registrer ny bruker

Vinduet registrer ny bruker gir brukeren muligheten for å registrere seg i systemet. Det er

laget tekstfelter hvor brukeren må taste informasjon, og man må forholde seg til visse

kriterier.

• E-post må bestå av dette formatet

• tilfeldig antall tall, bokstaver, bindestrek, punktum eller understrek,

• oppfulgt av et alfakrøll,

• oppfulgt av tilfeldig antall tall, bokstaver, bindestrek, punktum eller

understrek

• oppfulgt av ett punktum

• oppfulgt av to eller tre bokstaver

• Fødselsår må være et tall fra 1850 og nåværende dato

• Kjønn må være enten “Mann” eller “Kvinne”

• Land må bestå av vilkårlig antall bokstaver

• Passord må bestå av en kombinasjon av minst 8 ulike bokstaver eller tall

36

Ønsker man å gå tilbake til startmenyen kan man benytte seg av knappen “tilbake til

startmeny” knappen.

Etter vellykket registrering vil man komme til en nytt vindu hvor man kan se den

informasjonen man har registrert seg meg. Man kan deretter direkte logge seg inn i

applikasjonen eller få tilsendt info på mail med den informasjonen man har registrert seg

med.

2.3.10 Glemt passord

I dette vinduet kan man få tilsendt passord hvis det har blitt glemt. For å få tilsendt

passordet må man taste inn e-posten som er brukernavnet som er registrert i systemet og

trykke på knappen “send passord”, og da vil man få tilsendt et nytt passord på e-mailen sin

som man senere kan endre senere. Ønsker man å gå tilbake til startmenyen kan man trykke

på “tilbake til startmeny”.

37

2.3.11 Logg inn

I innloggingsvinduet må man skrive inn registrert e-post adresse og passord og trykke på

knappen “logg inn” for å logge seg inn på applikasjonen. Man kan også logge seg inn ved

bruk av knappen “logg inn via facebook”, benytte seg av knappen “glemt passord” eller gå

tilbake til startmeny ved å trykke på knappen “tilbake til startmeny”.

38

2.3.12 Hovedmeny

I vinduet hovedmeny kan man trykke på knappene “ta test”, “testresultater”, “bruker” og

“instillinger”. Man kan logge seg ut av applikasjonen ved å trykke på knappen “logg ut”.

2.3.13 Instillinger

I dette vinduet kan man endre på instillinger i applikasjonen. Man kan endre på lydnivå ved å

trykke på de ulike knappenivåene, trykke på knappen for å endre språk, trykke på knappen

for å aktivere fargeblindstøtte og trykke på knappen for å aktivere fargeblindstøtte. Disse

knappene er ikke aktive og vil ikke påvirke applikasjonen.

Man kan gå tilbake til hovedmenyen ved å trykke på knappen “tilbake til hovedmeny” og

man kan logge av applikasjonen ved å benytte seg av knappen “logg ut”.

39

2.3.14 Endre passord

I dette vinduet har man muligheten å endre brukernavn og passord. For å endre passord må

man taste inn e-post på begge felter og deretter det nye passordet på de to feltene og trykke

på knappen “endre”. Man kan gå tilbake til hovedmeny ved å trykke på knappen “ tilbake til

hovedmeny” og logge ut av applikasjonen ved å trykke “logg ut”.

40

2.3.15 Testvalg

Dette vinduet viser de ulike testene. For å ta en bildetest trykker på man tilsvarende knapp.

“Lydtest” og “bilde og lydtest” er ikke implementert. Man kan gå tilbake til hovedmeny ved å

trykke på knappen “tilbake til hovedmeny” og man kan logge av ved å trykke på knappen

“logg ut”.

2.3.16 Bildetest

I vinduet bildetest må man først trykke på knappen “trykk her for å velge test”. Deretter blir

man presentert med en liste over tilgjengelige tester. Velg deretter en test og knappen “start

test” for å starte tilsvarende test. Trykk på knappen “tilbake til testvalg” for å gå tilbake til

testvalg og knappen “logg ut” for å logge ut.

41

2.4 Administrasjonspanelet

Administrasjonspanelet er et felles administrativt verktøy for applikasjonen vår. Panelet gir

oversikt over alle testene som er lagt inn i systemet. Det er også mulighet for å legge inn

pinkoder assosiert med visse tester, hvor man bruker innlogging med pinkode på klientsiden

for å ta testen knyttet med valgt kode.

Admin logger inn via nettleser på nettadressen: «URL har sendt i orginal rapporten til

sensor». Admin skriver inn brukernavn og passord, og trykker på “Sign in”-knappen for å

logge inn.

Etter at administrator er logget inn får administrator opp kontrollpanelet som består av

forskjellige valg. Oversikt over tester, pinkoder og generell informasjon listes opp på høyre

spalte, mens menyen på venstre side fører til andre sider som Tests og Pincodes.

42

2.4.1 Tester

Administrator ser alle testene som er opprettet ved å klikke på All tests under Tests. Her får

administrator opplistet alle testene, både gyldige og ugyldige, sammen med litt detaljer for

hver test. Gyldig/ugyldig er status på om en valgt test kan tas av brukere eller ikke.

43

Ved å klikke på hver enkel test kan admin se alle detaljer om testen, samt ha muligheten til å

legge til nye testrunder.

Bildene på hver runde kan sees ved å klikke på “Vis bilder”-knappen til høyre for hver

opplistet testrunde.

44

Flere runder kan legges til i den valgte testen ved å klikke på den grønne plussknappen.

Bildene i den nye runden kan velges fra serveren, altså allerede opplastede bilder, eller så

kan man laste opp nye.

Administrator kan også lage en ny test ved å klikke på New test under Tests, i

navigasjonsmenyen til venstre. Admin fyller ut skjemaet med informasjon om testen, og

trykker på “Legg til”-knappen for å lagre den nye testen. En test kan inneholde en eller flere

runder.

45

Feltene som inngår i skjemaet er forklart nærmere her:

• Navn på test: Navnet på testen som skal betegne testen

• Kort beskrivelse: Denne beskrivelsen forklarer i korte trekk bakgrunnen for testen

• Oppgavetekst: Denne teksten forklarer hovedmålet med testen; hva som skal gjøres i

hver testrunde

• Tidsdelay: Ventetiden mellom det første bildet som vises i en testrunde og

påfølgende bilderutenettet

• Vanskelighetsgrad: Nivå på vanskeligheten til testen, basert på hvordan bildene er og

hvor lang tidsdelay-en er. Grad 1 vil si at testen er veldig lett, mens grad 10 tilsier at

den er meget utfordrende.

• Random bilder?: Kryss av for Ja hvis du ønsker at testrundene skal genereres

automatisk med tilfeldige bilder. Trykk på Nei hvis du ønsker å legge inn bildene

manuelt.

o Antall runder: Hvis random bilder er satt til Ja, så tast inn antall testrunder

som skal genereres

o Bilder per runde: Hvis random bilder er satt til Ja, så tast inn antall bilder som

skal vises i hver testrunde

o Rundetekst: Hvis random bilder er satt til Ja, så skriv inn instruksen som vises

på starten av hver eneste testrunde

• Gyldig?: Hvis Ja, så vil testen være aktiv for brukere. Hvis Nei vil testen ikke kunne tas

av brukere.

Etter at en ny test er laget, kan admin velge bilder for hver runde om random bilder var satt

til nei. Hvis random bilder var valgt, kan man likevel legge til nye testrunder. Gå inn på All

Tests under Tests, og velg den testen du nettopp opprettet. Klikk på den grønne

plussknappen under Testrunder for å få opp et modalvindu. Her kan man oppgi instruksen

for runden (rundetekst), og enten laste opp nye bilder, eller velge fra listen over de

opplastede bildene. Merk at man kun kan velge opptil 4 bilder. Etter at bildene er valgt,

trykker admin på Legg til runde for å legge til ny runde i testen.

47

2.4.2 Pinkoder

Admin har også oversikt over alle pinkoder som er opprettet, enten de er gyldige eller

ugyldige (om brukeren kan bruke de eller ikke). En pinkode er enkel måte ta en test på uten

å måtte logge inn eller registrere seg. Med kun en gyldig pinkode, kan man ta en test som på

forhånd er knyttet til pinkoden. En pinkode vil alltid føre til én test, mens en test kan ha flere

pinkodier assosiert med den.

En liste over alle pinkoder fås opp ved å klikke på All Pincodes under Pincodes menyvalget til

venstre.

Ved å klikke på hver enkel pinkode får admin opp detaljer om pinkoden, samt litt

informasjon om den tilknyttede testen. Ønsker man flere detaljer om testen kan man trykke

på (Details) knappen.

48

Admin kan opprette en ny pin kode ved å klikke på New Pincode.

49

Feltene i skjemaet er som følger:

• Navn for pinkode: Navnet assosiert med pinkoden. Det brukes for å lettere

gjenkjenne hva slags test pinkoden fører til

• Velg test: Her velger man testen pinkoden skal knyttes til. Velg test i

dropdownmenyen

• Gyldig?: Hvis Ja, så vil pinkoden være aktiv for brukere. Hvis Nei vil ikke brukere

kunne logge seg inn med denne pinkoden

Ny test med pin kode blir opprettet ved å klikke på Legg til pinkode knappen.

Administrator kan logge ut av panelet ved å klikke på Logg ut knappen øverst til høyre.

3 Produktbeskrivelse

Formålet med produktbeskrivelse er å gi leseren teknisk innblikk i hvordan

løsningen/produktet er bygget opp og samkjøring mellom serverdel og klientdel. Den er

beregnet for brukere som skal jobbe med drift, vedlikehold og videreutvikling av

løsningen, og vi forutsetter derfor at leseren har programmeringstekniske forkunnskaper.

For best utbytte av produktbeskrivelsen anbefaler vi at leseren først gjør seg kjent med

innholdet i kapittel 1 presentasjon, dette for å forstå produktbeskrivelsen bedre og

konseptet bak produktet.

50

3.1 Beskrivelse av løsningen

Figur 3.1, deler av løsningen.

Figur 3.1 viser hvordan systemet er laget, her ser vi at systemet hovedsak består to deler.

Klient del (front-end) og server del (back-end). Klient delen som da er brukergrensesnittet

slik som webapplikasjonen som er utviklet med rammeverket Angular 2, admin panel

utviklet i Php og IOS applikasjon utviklet med swift programmeringsspråk.

Via brukergrensesnittet (webb eller IOS applikasjon) kan brukerne registrere seg, logge inn,

ta demo test, sende tilbakemelding til administrator, logge inn med pin kode de får av

administrator for å ta forhåndsvalgt test, logge inn med Facebook konto eller resette glemt

51

passord. Etter at de er logget inn får de mange muligheter, et av mulighetene er å kunne ta

bilde tester.

Administrator kan legge inn nye bilde, lyd eller bilder med lyd test(er). Administrator vil også

ha oversikt over brukerens alder,kjønn,land og email. Hovedgrunnen til admin panel er at

admin/forskerne skal kunne få data som resultat av testene sammen med koordinaten på

hvor de har sett på bildene (eye tracking), disse koordinatene får de ved at kamera på

skjermen fanger refleksjon fra øynene, dette kalibreres før testene starter noe som gjør at

riktig koordinater lagres i databasen. Disse er viktige data som kan bli brukt videre i

forskning.

Klient delen er laget som webapplikasjon for å få en løsning der innholdet er tilgjengelig på

alle plattformer med internettilgang og en nettleser. En webapplikasjon har derfor en lavere

terskel for å få tilgang til innholdet sammenliknet med å installere en plattformavhengig app,

men for å gi brukerne en utvidet opplevelse har vi også laget samme applikasjon for Ipad

enheter med internettilgang som da er plattformavhengig. Selv om webapplikasjonen er

tilgjengelig på alle plattformer vil den ikke være like brukervennlig som en applikasjon

utviklet for ipad enheter. Ipad er også det eldre foretrekker, dette kan vi lese om i

forskningsrapporten10.

Server delen består av database på apache server, databasen inneholder viktige informsjon

som er nyttig for forskningen. Databasen inneholder også bildetester eventuelt andre tester

admin legger inn. Disse testene kan brukerne på klientside velge mellom, ellers er alt av

brukerinformasjon lagret i databasen, hvor passord er hashet. Databasen er også sikret og vi

har unngått å lagre sensitiv informasjon, informasjon som blir lagret er kun den

informasjonen som er nyttig å bruke i statistikk under forskningen.

På serveren har vi installert NodeJs, NodeJs brukes for å lage skalerbar nettverk applikasjon.

Denne applikasjonen er mellomledd for kommunikasjon mellom klient og server.

Kommunikasjonen / datautveksling skjer i JSON ( JavaScript Object Notation), JSON blir ofte

brukt for å sende data over et nettverk. Dette sendes først å fremst mellom server og

10 http://cdn.intechopen.com/pdfs/31905.pdf

52

webapplikasjon alternativ til XML, XML er plasskrevende derfor er også JSON best å bruke

her.

3.2 Tilgjengelighet og designvalg

Både web- og IOS versjonen har blitt designet ut ifra samme utgangspunkt. Dette betyr at

designet og valgene som er tatt for tilgjengelighet er de samme på begge plattformene. Vi

tok høyde for å utforme et design som er best tilpasset målgruppen eldre mennesker og

personer med dementia, men vi ønsket også at applikasjonen generelt fremmer en intuitiv,

enkel og god brukeropplevelse uavhengig av bruker.

I avsnittene under vil vi starte med å fortelle hvordan avgjørelsene vi har tatt generelt

fremmer et godt design. Tilslutt vil vi fortelle hvordan spesielt eldre, eller personer med

dementia, kan ha nytte av disse designvalgene.

3.2.1 WCAG 2.0

WCAG 2.0 11 er retningslinjer på hvordan man gjør innhold tilgjengelig for mennesker

uavhengig av funksjonshemninger. Dessverre kan man ikke dekke enhver person behov,

ettersom dette varierer fra person til person, men ved å følge disse retningslinjene øker

sjansene for at innholdet blir mest mulig tilgjengelig ovenfor brukere.

På øverste nivå består WCAG 2.0 av fire hovedprinsipper;

1. Mulig å oppfatte vil si at informasjon og brukergrensesnittkomponenter må

presenteres for brukere på måter som de kan oppfatte,

11 https://uu.difi.no/krav-og-regelverk/wcag-20-standarden/oppbygging-av-wcag-20#oppbygging

https://uu.difi.no/krav-og-regelverk/wcag-20-standarden/oppbygging-av-wcag-20#oppbygging
















53

2. Mulig å betjene vil si at det skal kunne finnes alternativer slik at man kan

brukergrensesnittkomponenter og navigeringsfunksjoner

3. Forståelig vil si at det skal være enkelt å forstå og intuitivt å benytte seg til systemet,

4. Robust vil si at innholdet er kodet på en slik måte at den kan vedlikeholdes å tilpasse

seg endringer ettersom man senere ønsker å introdusere ny teknologi

Noen eksempler på hvordan vi har brukt disse retningslinjene i vår applikasjon er blant annet

at vi har brukt tekstalternativer til ikke-tekstlig innhold, brukt enkle ord og korte setninger

for å gjøre innholdet forståelig, hvor det kreves inndata fra brukeren er det tydelige

instruksjoner på hva man skal gjøre, og man kan navigere seg i systemet ved hjelp av

trykking og tastatur.

3.2.2 Brukervennlighet

Det viktig å ha fokus på brukervennlighet for at brukeren skal kunne benytte seg av

applikasjonen på den mest optimale måten. Don Normans12 er en anerkjent forsker på

brukervennlighet, og under vil vi vise hvordan vi har gjort dette tatt i bruk noen av hans

designprinsipper.

3.2.2.1 Tilbydelser

For å hjelpe brukeren å vite hvordan man utfører handlinger i applikasjonen har vi benyttet

oss av virtuelle tilbydelser. Størrelsen og plassering av knapper i forhold til

brukergrensesnittet er et eksempel på en bevisst beslutning vi har tatt for at brukeren

lettere skal forstå hvilke elementer det er mulig å ha interaksjon med.

12 https://www.csun.edu/science/courses/671/bibliography/preece.html

54

3.2.2.2 Tilbakemeldinger

Tilbakemeldinger er viktig for at brukeren kan forsikre seg at handlingen er i samsvar etter

hva brukeren ønsker å utføre. Uten tilbakemeldinger kan brukeren lett bli forvirret eller

frustrert, spesielt når brukeren ikke kommer videre eller det har skjedd noe galt. I

applikasjonen har vi benyttet oss av ”pop up” vinduer med simpel og presis ordbruk slik at

brukeren lett skal få beskjed om hva som har blitt utført, om noe gikk galt eller om det er

noe som mangler.

55

3.2.2.3 Metaforer

I applikasjonen har vi benyttet oss av visuelle gjenstander som skal formidle innholdet på en

slik måte at det blir tydelig. For eksempel er et ”puslespill” et konsept som er kjent for de

fleste fra den virkelige verden. Puslespillbrikke forbindes ofte med et spill, noe tester i vår

applikasjon skal simulere.

3.2.2.4 Sperring av ugyldige handlinger

Funksjonalitet som er utilgjengelig er skildret ulikt fra andre elementer i brukergrensesnittet.

Sammen med en tekstlig forklaring fører dette til at det blir lettere for brukeren å forstå

hvilke elementer en ikke har tilgang til.

56

3.2.2.5 Forgrunn og bakgrunn

Slik at det ikke oppstår tvetydighet i brukergrensesnittet har vi benytter vi oss av skille

mellom forgrunn og bakgrunn. Tilbakeknapper som alltid er tilgjengelig i øverste venstre

hjørnet er av mørkere variant enn den som er i bakgrunnen. På denne måten er knappen i

mindre grad diskret, men fortsatt lett tilgjengelig og tydelig uten at det går på bekostning av

det visuelle designet.

3.2.2.6 Konsistens, likhet og gruppering

For å skape et ryddigere grensesnitt har vi blant annet benyttet oss av konsistente

plasseringer og størrelser for å gruppere og vektlegge de ulike elementene. Knapper som

utgjør funksjoner som vektlegges like mye har samme form, noe som indikerer at at de er

relaterte. For eksempel er hovedkategorier og knapper av lik størrelse og er samtidig

midtstilt i vinduet, i mens tilbakeknapper alltid har faste plasser i samme område. Dette

fører til at brukeren for en bedre oversikt over navigeringen, og også at de blir vant til

systemet fortere.

57

3.2.2.7 Tekst og lesbarhet

Målbevisste valg over utformingen av teksten er viktig ettersom tekst er et av de helt

avgjørende faktorene for at brukeren skjønner hvordan man bruker applikasjonen.

Fonten vi har valgt å bruke er ”Futura” som er ”sans serif font”13. Dette vil si at fonten ikke

består av små serifer, som er detaljer som kan gjøre det vanskelig for brukere, spesielt eldre

eller de med funksjonsnedsettelser, å forstå og lese teksten.

Vi har benyttet oss av halvet tekst med ekstra stor tekstørrelse i applikasjonen og samtidig

benyttet oss av små bokstaver ettersom de er mer lesbare enn store. Små bokstaver har

forskjellige høyde, noe som gjør dem lettere å kjenne igjen ordet.

13 https://www.solopress.com/blog/print-inspiration/dementia-friendly-print/

https://www.webdesignerdepot.com/2013/03/serif-vs-sans-the-final-battle/

https://www.solopress.com/blog/print-inspiration/dementia-friendly-print/




















58

Det er bedre at teksten er for stor enn for liten, spesielt med tanke på eldre personer med

dementia, ettersom med alder kommer synsproblemer, motorikkproblemer osv.

3.2.2.8 Navngiving

Menyknappene og titteloverskriften over hvor man befinner seg i applikasjonen, er

beskrevet kort og presist. Vi har også lagt vekt på at man skal vite nøyaktig hvor en knapp

fører videre i systemet, slik at man alltid vet hvor i systemet man er.

Dette er spesielt viktig for dementia personer, ettersom at disse vanligvis har svekket

korttidshukommelse og problemer med å orientere seg.

59

3.2.2.9 Bruk av ikoner

I applikasjonen har bruk av ikoner blitt brukt som et supplement til den tekstlige beskrivelsen

av knappen. Ved konsistent bruk av en kombinasjon av både tekst og ikoner fører dette til at

man utelukker sjansen for tvetydighet.

For eksempel forstår man ikke teksten eller språket, formidler ikonene et alternativt bilde på

hva formålet med elementet er og fortsatt vet hva som er funksjonen til elementet. Forstår

man ikke ikonet gir det muligheten og også lære det underveis på grunn av den tekstlige

beskrivelsen.

3.2.2.10 Farger og kontraster

Bruk av farge og kontraster i applikasjonen er nøye gjennomtenkt. Vi har brukt tydelige

kontraster og man kan lett skille mellom de ulike elementene, men samtidig fører skille ikke

til at man opplever det visuelle som anstrengende og slitsomt.

Det er brukt konsistent bruk og ikke altfor mange farger, ettersom for mye bruk av dette kan

skape forvirring hos brukeren. Nyanser av samme farge er også et annet middel for å skille

mellom elementer i brukergrensesnittet uten å innføre nye farger. Bakgrunnsfargen og noen

knapper i applikasjonen bruker blant annet nyanser av fargen grå.

Fargene utenom bakgrunnsfargen som er brukt i applikasjonen består av disse fargene med

tilsvarende fargekoder.

60

Man ser tydelig at det er en kontrast mellom de ulike fargene samtidig som de fortsatt er

harmonisk og gir en følelse av beslektning. Det er ingen brå kontraster mellom de ulike som

kan være anstrengende.

Eksempel på fargebruk som kan være anstrengende for øynene:

61

3.2.2.11 Organiseringsstruktur

I hvert vindu av applikasjonen blir brukeren kun presentert med de elementene som er

absolutt nødvendig til enhver tid. Dette er et bevisst designvalg vi har valgt å bruke ettersom

det fører til at det er mindre sannsynlighet for brukeren å gjøre feil.

Vi har også brukt visuelle teknikker for å videre fremme hvor vi ønsker brukeren skal

fokusere blikket mot. På denne måten kan vi forsterke hva vi ønsker å formidle samtidig som

dette er en raskere måte å få brukeren til å lese det viktigste stoffet.

3.2.2.12 Design for målgruppen

Ettersom målgruppen vår er spesifikk, finnes det flere tiltak som kan gjøres for å forbedre

brukeropplevelse for personer med dementia eller generelt eldre personer14.

Blant annet må man ta hensyn til at dementia personer ofte ikke har god hukommelse som

dermed fører til at personen har vanskeligheter med å huske hvor ting befinner seg i

systemet, eller hvordan man kommer dit. Da er det spesielt viktig at man derfor bruker

14 https://core.ac.uk/download/pdf/11309888.pdf

62

forklarende og tydelige navn på f.eks menyer og knapper og alltid opplyser brukeren hvor

den befinner seg i systemet, noe som vi har nevnt tidligere i avsnittet om navngiving. Dette

er også tilfelle for eldre personer generelt, ettersom de ofte bruker lengre tid å lære og

huske ny terminologi. Ved å ta i bruk ikoner i kombinasjon med selvforklarende navn er

dette med på å gjøre brukeropplevelsen bedre.

Det er også en mulighet for at det motoriske bevegelsene hos eldre ikke fungere optimalt,

noe som kan gjøre det vanskelig å ta i bruk navigering slik som scroll bars eller zooming

funksjoner. Ved å ha mye plass mellom hvert element, ha større form på elementene og

benytte seg av den enkleste formen for brukeren kan ha med systemet, nemlig å peke, vil

dette forhåpentlig gi en bedre opplevelse for eldre.

Stor og tydelig tekst er også viktig ettersom både eldre og personer med dementia ofte har

problemer angående synet.

3.3 Backend

3.3.1 NodeJS server

3.3.1.1 NodeJS i backend

Backend applikasjonslageret er hovedsakelig bygd ved hjelp av NodeJS, en rask

implementasjon av javascript for bruk på serversiden. NodeJS baserer seg på Javascripts

prinsipper og drar nytte av dette ved å anvende funksjon callbacks for asynkront kjøring.

Dette gjør at NodeJS kun trenger å bruke én tråd for å håndtere all kodekjøringen. En slik

implementasjon på serversiden gir en sømløs skalerbar løsning som håndterer økning av

samtidige brukere på en elegant måte.

3.3.1.1.1 Node Package Manager

NodeJS er stort sett avhengig av tredjeparts moduler som må installeres og konstant

oppdateres. Dette kan gjøres manuelt, men dette er både tidkrevende og kan fort bli rotete.

Løsningen vi bruker er Node Package Manager, forkortet NPM, som vedlikeholder

63

pakkemodulene automatisk for oss. Alle modulene prosjektet er avhengig av, defineres i en

fil package.json, og et simpelt kall fra terminalen npm install fikser resten.

3.3.1.2 ExpressJS server

Vi benytter ExpressJS-rammeverket for NodeJS for å håndtere webserver funksjonaliteten på

backend-en. Dette rammeverket letter mye av arbeidet med drift av web server. Tjening av

filer, opplasting/nedlasting, routing, og integrering av middelvare er bare noen av

oppgavene ExpressJS tar seg av suverent. Denne serveren tjenes på portnummer 8080 som

standard.

3.3.1.3 REST API

All kommunikasjon mellom våre frontend klienter og backend server foregår gjennom et

tilstandsløs programmeringsgrensesnitt (REST API) kodet i NodeJS. API-et følger

retningslinjene for REpresentational State Transfer (REST), som i hovedtrekk krever at all

kommunikasjon mellom klient og server foregår tilstandsløst og fullstendig selvforklarende.

Dette vil i praksis si at en vilkårlig klient og server kan interagere uten å vite noe om den

underliggende arkitekturen til hverandre.

Vår implementasjon av et REST API foregår over HTTP-protokollen, og bruker Javascript

Object Notation-format (JSON) som kommunikasjonsmediet. Ved bruk av semantisk routing i

URL-stien til å gi klientene våre et enkelt grensesnitt til å utføre en haug med operasjoner på

serversiden, har vi fått til et godt og RESTfullt grunnlag for API-et vårt som integreres feilfritt

med klientene våre via HTTP protokollen.

3.3.1.3.1 Tokenbasert Autentisering

Siden API-et er URL-basert og linkene brukes direkte i koden, kan dette forårsake et svakt

ledd i sikkerheten om det ikke tas hensyn til. Om noen andre får tak i URL-ene til API kallene,

kan de utføre de samme operasjonene på backend-et som om det var

systemadministratoren. Dette løses ved hjelp av et mellomlager for nesten hvert API kall

sammen med et token-system.

64

3.3.1.3.1.1 JSON Web Token (JWT)

Vi bruker JWT, JSON Web Tokens, som et alternativ til sessions/cookies for å bevare

innloggingstilstanden til brukeren/administratoren. JWT er et token-system som genererer

en kryptert enveis hash av dataen som skal sendes frem og tilbake, og signeres ved hjelp av

en privat nøkkel som bare er kjent for backend-et. På den måten sendes tokenet frem og

tilbake ved hvert kall, og det sjekkes om JWT-et er gyldig eller ikke ved å bekrefte de

hashede verdiene. API kallet godkjennes kun hvis verdiene stemmer overens med den

private nøkkelen og en eventuell tidsfrist på tokenet. Disse tokenene genereres bare ved

innlogging av bruker eller administrator, og er dermed ganske sikret mot uautorisert bruk.

Figur: Sekvensdiagram på den normale utvekslingen av informasjon mellom server og klient ved

token autentisering. Bildet hentet fra: https://scotch.io/tutorials/the-ins-and-outs-of-tokenbased-

authentication#the-benefits-of-tokens

https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication#the-benefits-of-tokens






















65

3.3.1.3.2 API Struktur

Hvert kall er en URI som må kalles på via et HTTP-forespørsel med HTTP-metode (POST, GET,

osv.), som så vil returnere en respons. Et slikt forespørsel kan gjøres uavhengig av program,

språk og system, så lenge en slik funksjonalitet støttes av det som anvendes. Legg merke til

at portnummeret 8080 anvendes til alle API-kallene, siden ExpressJS-serveren i NodeJS er

satt til å kjøre på port 8080 (Se avsnitt om ExpressJS).

3.3.1.3.2.1 URL-format

Alle API-endepunktene består av følgende URL-format:

{base_url}/api/{route}?{GET-parametre}

{base_url} er domenenavnet til nettsiden som tjener API-et. I vårt tilfelle vil det være

URL:8080. Vi tilføyer portnummeret 8080 siden serveren kjøres der (Se avsnitt om

expressjs).

/api/ er roten i strukturen av alle API-endepunktene

{route} er den semantiske route-en som gjør et kall på en operasjon i serveren. Det er disse

route-ene som tilsvarer API-endepunktene, og som beskrives i denne referansen. Hvis API

kall for å få alle testene ser slik ut i URL-format: URL:8080/api/test, så vil /test tilsvare route-

en. En route kan ha flere nivåer som f.eks. /test/runde.

{GET-parametre} er parametrene som direkte inngår i URL-stien for et API kall, og som

vanligvis sendes med ved GET-baserte kall. I denne API referansen tar vi utgangspunktet i

/api/{route}, og velger å utelate base_url-en.

http://www.gruppe18.tk:8080/

8080/api/test

8080/api/test

66

Noen ganger tas det i bruk route parametre. I et slikt tilfelle vil URL-formatet være:

{base_url}/api/{route}/:{route_parameter}

3.3.1.3.3.2 Forespørsel krav

API-endepunkter som krever HTTP-metoden POST, PUT, eller DELETE, krever parametre

inkludert i body-delen av HTTP-forespørselen. Content-Type header-en må alltid være

xwww-form-urlencoded for at variablene skal kunne sendes. Eksempel på raw HTTP-request

med parametre i body:

HTTP-forespørsel RAW (POST):

POST /api/pincode/login HTTP/1.1

Host: URL:8080

Content-Type: application/x-www-form-urlencoded

Cache-Control: no-cache

Postman-Token: 4d1c11fc-0bdc-5873-f144-5c92182cb8c2

token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoicHJpZF9vdXRpbmdAaG90bWFp

bC5jb20iLCJpYXQiOjE0OTE5ODkzNzAsImV4cCI6MTQ5MjA3NTc3MH0.5SHyWxoINNmYGdo

mZM5ONb3HrMy8caYftxi-9vCVaE&kode=1001

Denne kodesnuten er hentet fra programmet Postman (Se avsnitt om programmet for mer

info). Vi ser at body-delen kommer etter et mellomrom mellom header-ene øverst, og

bodydelen som følger etter med parametrene token og kode.

API kallene som krever HTTP-metoden GET, krever parametre inkludert på enden av URI-en

til API-endepunktet. Eksempel på URL for HTTP-forespørsel, for kall på å få en liste over alle

testene:

HTTP-forespørsel URL (GET): URL:8080/api/test/runde?testid=2

67

Denne URL-en kalles på når man trenger å få en liste over alle testrundene til en spesifikk

test. Testen identifiseres gjennom GET-parameteren testid på enden av URL-stien.

En tredje måte å sende parameter på er route parametre. Det vil si en URL-segment som er

en del av URL-stien, hvis verdi lagres som en variabel. Eksempel:

HTTP-forespørsel URL med route parameter (GET): URL:8080/api/test/2/

Denne URL-en kalles på når man vil få all informasjon om test med id 2. Route parameteren

inngår som et naturlig segment av URL-en.

Merk at selv om body-delen av POST, PUT, UPDATE eller DELETE HTTP-forespørslene er de

som inneholder parametrene, så kan det likevel sendes med GET-parametre valgfritt. Dette

gjelder imidlertid ikke for GET-kall.

3.3.1.3.3.3 Respons format

Alle responser fra API kallene returneres i JSON-format. For de fleste kallene returneres det

alltid en Error- og Message-nøkkel med verdi som sender med metadata fra kallet.

Errornøkkelen er av boolsk verdi, der true tilsier at det skjedde noe galt med API kallet, mens

false betyr at forespørselen gikk som den skulle. Message-nøkkelen sender med en verdi av

type string for å utdype statusen av Error-nøkkelen med vanlige ord. Message vil som regel

returnere “Success” når Error returnerer false. For et mislykket API kall vil alltid kun

returneres Error- og Message-nøkkel.

Utenom nøkkelverdi-parene Error og Message, vil en JSON-respons inkludere en eller flere

ekstra nøkler, vanligvis av typen Array, som en direkte respons på det API kallet egentlig ber

om i utgangspunktet. Her er eksempel på respons når man har kalt på API-endepunktet som

returnerer en liste over alle runder for testid 1:

68

JSON Respons:

{

"Error": false,

"Message": "Success",

"Testrunder": [

{

"testrundeid": 8,

"bilder": [

"URL/images/flat-icon-social-media.jpg",

"URL/images/14708392_758899407581223_830798171136140889 7_n.jpg",

"URL/images/flat-icon-nodejs.jpg",

"URL/images/bc69a3c97fd3b4481b7afe69538b5d52.jpg"

],

"tekst": "Mega Testrunde",

"testid": 3,

"rundenr": 1

}

]

}

Vi observerer at nøklene Error og Message returneres og indikerer at kallet gikk feilfritt. I

tillegg følges det med en ekstra nøkkel, Testrunder, som er en array av de ulike testrundene

for testid 1 i dette eksemplet. Hver testrunde er et eget objekt med sin metadata.

3.3.1.3.3 API Referanse

Her er en referanseliste og oppbygg over de viktigste API-endepunktene som kan kalles på,

delt opp etter bruksområde og filstruktur. Noen av API kallene kan påkalles uten autorisering

og uten token -- dette er spesifisert i hvert API kall under, om kallet krever autentisering

og/eller autorisering som f.eks. klient eller administrator. Vær obs på at et token må sendes

med enten som GET-parameter, legges til i body-delen, eller settes som x-access-token

header der det kreves autentisering/autorisering.

69

NOTE: Del opp seksjonene i ulike Routes; autentisering, administratorer, bruker, tester,

demo, pin, email

3.3.1.3.3.1 Autentisering

Som nevnt i tidligere delkapittel består API-et av et mellomledd som tar seg av all

autorisering for å sikre grensesnittet mot uønskede tredjeparter gjennom generering av

token. Følgende API-endepunkter brukes for autentisering, som genererer og returnerer en

token. Denne token-en må følge med på hvert konsekvent kall som krever autorisering.

3.3.1.3.3.1.1 POST /api/authenticate

Brukes til å autentisere en bruker eller administrator. Returnerer en token som er generert

basert på brukeropplysninger.

Parametre: email:string, passord:string

Respons: Error:boolean, Message:string, Token:string

Tilgang: alle (token kreves ikke)

3.3.1.3.3.2 Brukeradministrasjon

Her listes opp en rekke operasjoner for å legge til, oppdatere og slette brukere og

administratorer.

3.3.1.3.3.2.1 POST /api/users

Legger til en ny bruker i databasen.

Parametre: email:string, passord:string, land:string, alder:int, kjonn:string

70

Respons: Error:boolean, Message:string

Tilgang: alle med token

3.3.1.3.3.2.2 GET /api/users

Returnerer en liste over alle brukere lagret i databasen.

Parametre: ingen

Respons: Error:boolean, Message:string, Users:array

- Users: email:string, passord:string, land:string, alder:int, kjonn:string, instillingsid:int


3.3.1.3.3.2.3 GET /api/users/:email

Returnerer brukeren med den spesifiserte email adressen. Brukeren returneres i form av en

array med ett element.

Parametre: email:string


- Users: email:string, passord:string, land:string, alder:int, kjonn:string, instillingsid:int


3.3.1.3.3.2.4 PUT /api/users

Oppdaterer bruker med spesifisert email adresse.

Parametre: email:string, passord:string

71



3.3.1.3.3.2.5 DELETE /api/users/:email

Sletter bruker med spesifisert email adresse.




3.3.1.3.3.2.6 POST /api/users/reset

Generer et nytt random passord til den spesifiserte brukeren, og sender den til brukerens

email. Passordet anvender en enkel algoritme til å kombinere bokstaver og tall med vilkårlig

lengde.




3.3.1.3.3.2.7 POST /api/users/sendInfo

Sender brukerinformasjon på email til spesifisert bruker. Brukes til nyregistrerte brukere.



72


3.3.1.3.3.2.8 POST /api/admin

Legger til ny administrator i databasen.

Parametre: brukernavn:string, passord:string



3.3.1.3.3.2.9 GET /api/admin

Returnerer en liste over alle administratorer.

Parametre: ingen


- Users: admin_id:int, brukernavn:string, passord:int


3.3.1.3.3.3 Tester

Oversikt over en rekke operasjoner for å administrere tester og testrunder.

3.3.1.3.3.3.1 POST /api/test

Legger til en ny test i databasen. Hvis parameteren random settes like true, så må de valgfrie

parametrene under (i parentes) også sendes med.

73

Parametre: testnavn:string, beskrivelse:string, tekst:string, delay:int, vanskelighetsgrad:int,

gyldig:boolean, random:boolean, [random_runder:int, antall_bilder:int, rundetekst:string]



3.3.1.3.3.3.2 GET /api/test

Returnerer en array med alle testene i databasen.

Parametre: ingen

Respons: Error:boolean, Message:string, Tests:array

- Tests: testid:int, testnavn:string, testbeskrivelse:string, oppgavetekst:string, tidsdelay:int,

vanskelighetsgrad:int, gyldig:boolean, dato:date, admin_id:int, antall_runder:int


Eksempel:

Respons fra kall på GET /api/test:

74

{

"Error": false,


"Tests": [

{

"testid": 1,

"testnavn": "Ok",

"testbeskrivelse": "Dette er en demotest for førstegangsbrukere",

"oppgavetekst": "Trykk på det riktige bildet etter at det har blitt vist",

"tidsdelay": 1,

"vanskelighetsgrad": 4,

"gyldig": 0,

"dato": "0000-00-00 00:00:00",

"admin_id": 2,

"antall_runder": 3

}

}

3.3.1.3.3.3.3 GET /api/test/:testid

Returnerer test med spesifisert ID. Det returneres en array med ett element.

Parametre: testid:int

Respons: Error:boolean, Message:string, testid:int, testnavn:string, testbeskrivelse:string,

oppgavetekst:string, tidsdelay:int, vanskelighetsgrad:int, gyldig:boolean, dato:date,

admin_id:int, creator:string


3.3.1.3.3.3.4 POST /api/test/runde

75

Legger til ny testrunde for en spesifisert test med ID. Bildearray-en som sendes med må

bestå av fullstendige URL-stier til bilderessursene.

Parametre: testid:int, bilder:string[], tekst:string, testid:int, rundenr:int



3.3.1.3.3.3.5 GET /api/test/runde

Returnerer alle rundene til en spesifisert test med ID. Bildearray-en som returneres består av

fullstendige URL-stier til bilderessursene.

Parametre: testid:int

Respons: Error:boolean, Message:string, Testrunder:array

- Testrunder: testrundeid:int, bilder:string[], tekst:string, testid:int, rundenr:int


Eksempel:

Respons fra kall på GET /api/test/runde for test ID 1:

76

{

"Error": false,


"Testrunder": [

{

"testrundeid": 1,

"bilder": [

"URL/images/flat-icon-design.jpg",

"URL/images/HTML5-.jpg",

"URL/images/Screenshot_67.png",

"URL/images/bc69a3c97fd3b4481b7afe69538b5d52.jpg"

],

"tekst": "Velg riktig bilde",

"testid": 1,

"rundenr": 1

}

}

3.3.1.3.3.3.6 GET /api/test/runde/:rundeid

Returnerer en spesifikk runde til en spesifisert test med ID. Det returneres en array med ett

element. Bildearray-en som returneres består av fullstendige URL-stier til bilderessursene.

Parametre (route): rundeid:int Parametre (GET): testid:int

Respons: Error:boolean, Message:string, Testrunde:array

- Testrunde: testrundeid:int, bilder:string[], tekst:string, testid:int, rundenr:int


77

3.3.1.3.3.3.7 POST /api/resultat

Lagrer resultatet til en test i databasen. Dette API-endepunktet brukes når en bruker er

ferdig med å ta en test. En bruker kan ta samme test flere ganger, men resultatet er unikt

hver gang.

Parametre: email:string, testid:int, tid_start:date, poeng:int, tid_slutt:date



3.3.1.3.3.4 Pinkoder

Oversikt over en rekke operasjoner for å administrere pinkoder.

3.3.1.3.3.4.1 POST /api/pincode

Legger til en ny pinkode i databasen for en gitt test. Returnerer den nye pinkoden som blir

generert.

Parametre: navn:string, admin:string, testid:int, gyldig:boolean

Respons: Error:boolean, Message:string, Pinkode:int


3.3.1.3.3.4.2 GET /api/pincode

Returnerer en liste over alle pinkodene.

Parametre: ingen

78

Respons: Error:boolean, Message:string, Pincodes:array

- Pincodes: pinkode:int, navn:string, admin_brukernavn:int, testid:int, gyldig:boolean,

dato:date


3.3.1.3.3.4.3 GET /api/pincode/test

Returnerer testen som er assosiert med den spesifiserte pinkoden. Returverdien er i form av

en array med ett element.

Parametre: pincode:int

Respons: Error:boolean, Message:string, Tests:array

- Tests: testid:int, testnavn:string, testbeskrivelse:string, oppgavetekst:string, tidsdelay:int,

vanskelighetsgrad:int, gyldig:boolean, dato:date, admin_id:int, pinkode:int, navn:string,

admin_brukernavn:int


3.3.1.3.3.4.4 GET /api/pincode/validate

Verifiserer om en pinkode eksisterer eller ikke. Returnerer en statusmelding.

Parametre: kode:int



79

3.3.1.3.3.4.5 POST /api/pincode/login

Autentiserer en bruker som logger inn med pinkode. Returnerer ID-nummeret til den nye

brukeren, sammen med test ID-en til testen som skal tas.

Parametre: kode:int

Respons: Error:boolean, Message:string, Pinkode:int, User:int, Test:int


Eksempel:

Hvis vi logger oss inn med pinkode 1000, som er assosiert med test ID 1, så kan responsen se

slik ut:

Respons til kall på POST /api/pincode/login for pinkode 1000:

{ "Error": false,


"Pinkode": "1000",

"User": 18,

"Test": 1 }

Vi ser at i dette tilfellet er vi bruker nummer 18. Det betyr at dette var den attende

innloggingen for pinkode 1000. Kombinasjonen av pinkode og brukernummer gir en unik

identifikasjon. Vi kan skrive dette brukernavnet som 1000_18.

3.3.1.3.3.5 Annet

Oversikt over REST API-endepunkter for diverse operasjoner.

80

3.3.1.3.3.5.1 POST /api/contact

Sender en email til administrasjonen, fra en vilkårlig bruker.

Parametre: email:string, message:string


Tilgang: alle (krever ikke token)

3.3.2 Apache server

3.3.2.1 Statisk web server

Høynivå serverspråket, PHP, sammen med en Apache server har vi brukt til å tjene det

statiske admin panelet. Apache server håndterer ikke mange samtidige brukere like bra som

NodeJS, men er perfekt for å tjene statiske filer, noe som passer ganske godt for admin

panelet. Standardspråket for Apache server er PHP, et allsidig skriptspråk som brukes på

serversiden. PHP kan inngås direkte inn i HTML-kode, noe som gir dynamiske templates som

forebygger redundans og direkte interaksjon mellom server og klient.

3.3.3 Database

3.3.3.1 Type database

Vi benytter oss av en MySQL database -- en relasjonsdatabase som driftes ved hjelp av SQL-språket.

En slik database er nødvendig for håndtering av høyt skalering av applikasjonen når antall brukere

økes eksponensielt. Siden applikasjonen vår skal holde på store mengder data, være best strukturert

som mulig, ha periodiske backups, og vedlikeholdes over større belastninger grunnet transaksjoner

samt samtidige brukere, så er en database av slikt kaliber den perfekte løsningen for oss.

3.3.3.2 Databasemodell

Kravspesifikasjonen, som beskrevet av oppdragsgiveren, bestod i hovedtrekk av et

autentiseringssystem med et minnespill-lignende funksjonalitet i kjernen (#Se avsnittet som forklarer

nærmere hvordan spillet fungerer). Derfor var det en selvfølge å bygge databasemodellen rundt

dette for denne oppgaven.

81

3.3.3.2.1 Logisk skjema

Etter logiske resonnementer og gruppeinnspill, kom vi frem til dette logiske skjemaet:

Databasen er bygget rundt denne modellen.

4.1 Klientside

Klientsiden består av tre deler; webapplikasjon,IOS applikasjon og administrasjonsløsningen.

Web og IOS applikasjonen er laget med tanke på dement pasienter som tar testen(e) . Disse

applikasjoner er laget generisk, noe som gjør at med noen justeringer vil man kunne bruke

appene som hvilke som helst formål. De fleste apper pr dags dato har en form for innlogging

vi har brukt alle typer innlogginger og alle er uavhengig av hverandre. Videre er det kodet

slik at vi enkelt kan bytte ut alle vinduer etter innlogging med hva vi måtte ønske. Metodene

i klassene er også laget så generisk som mulig for å kunne bruke det i hvilke som helst

applikasjon.

82

Administrasjons løsningen er laget for å gi administrator/ forskere et verktøy for å lage tester

og for å samle informasjon/statistikk. De endringer admin gjør via administrasjon løsningen

vil påvirke klientsiden (web og IOS applikasjon)

4.1.1 Teknologier

Klientsiden er utviklet i Angular 2 med Typescript og Swift programmeringsspråk for IOS

applikasjon. For design har vi brukt Bootstrap frontend-rammeverket for webapplikasjonen.

For nedlasting og vedlikehold av biblioteker har vi brukt pakkesystemet «Npm» for

webapplikasjon og «cocoapads» for IOS applikasjon sammen med «Carthage» for å legge til

rammeverk/biblioteker.

4.1.1.1 IOS teknologier

Her vil vi skrive om de teknologier som er brukt i IOS applikasjonen, disse er

rammeverk/biblioteker. Vi har ikke fått implementert eye tracking i denne løsningen.

Grunnen til dette er at kamera på enheten ikke ville være stødig og dermed ville kalibrering

vært vanskelig. Å implementere eye tracking ville vært egen prosjekt i seg selv, da det ikke er

laget noen biblioteker/rammeverk for dette enda. Apple har også patent for denne

teknologien. Et annet alternativ er å koble på enhet som man bruker som briller og de vil da

kunne fange opp øyebevegelsene med brillene vil man kunne få til nøyaktig data som igjen

kan lagres i databasen. Appen er laget slik at det skal være mulig å legge til, videreutvikle og

implementere eyetracking senere.

4.3.1.2 Rammeverk/biblioteker

I vårt prosjekt har vi gjort nytte av rammeverk/biblioteker. Disse bibliotekene har vi brukt i

flere av våre klasser/controller for å få bruke ønsket funksjonalitet. Dette gjorde arbeidet

noe enklere, vi trengte ikke å kode dette direkte, men heller importere bibliotekene og

bruke de funksjonene som biblioteket inneholder. Klassen som objektet trenger for å utføre

83

sine handlinger blir gitt uten at avhengigheten er hardkodet direkte i programmet. I stedet

for å referere til spesifikke implementasjoner, blir bibliotekene dermed et mellomledd for

denne kommunikasjonen, ved at bibliotekene er kodet/brukt i egne klasser for å enkelt

kunne endre,fjerne eller legge til noe i klassen uten at vi trenger å gjøre noe flere endringer

flere steder i applikasjonen.Dette er brukt for å skape et system som er generisk,

klassene/controller er også kodet slik at applikasjonen kan brukes til alt og mye av koden kan

brukes til hvilke som helst formål.

Biblioteker som er brukt er følgende:

PopupDialog 0.5

AlamoFire version 4.4

AlamoFireImage 3.1

AlamoFire-Synchronous 4.0

FacebookCore

FacebookLogin

FacebookShare

4.3.1.3 PopupDialog

Popup Dialog er en enkel, tilpassbar popup-dialog vindu.

PopupDialog er en underklasse av UIViewController og kan legges til visning kontrollen. Du

kan initialisere den enten med den praktiske standard visningen eller en tilpasset visning

kontroll.

Vi har laget egen klasse hvor vi har importert PopupDialog, denne klassen har vi brukt videre

for å vise popup vindu. Klassen vi har laget heter Popup og koden ser slik ut:

84

import UIKit

import

PopupDialog

class Popup: UIViewController {

override func viewDidLoad() {

super.viewDidLoad()

}

override func didReceiveMemoryWarning() {

super.didReceiveMemoryWarning()

// Dispose of any resources that can be recreated.

}

//Denne funksjonen blir kalt på der vi ønsker å vise popup dialogen. func

vis(fromController controller: UIViewController,melding: String,tittel:String){

//lage costumize popup

var dialogAppearance = PopupDialogDefaultView.appearance()

dialogAppearance.titleFont = UIFont(name: "Futura-Bold", size: 40)!

dialogAppearance.titleColor = UIColor(red:252, green:0, blue:0, alpha: 100)

dialogAppearance.messageFont = UIFont(name: "Futura-Medium", size: 30)!

dialogAppearance.messageColor = UIColor(red:0, green:0, blue:0, alpha: 80)

dialogAppearance.messageTextAlignment = .center

85

// knappen

let cb = CancelButton.appearance()

cb.titleFont = UIFont(name: "Futura", size: 30)!

cb.titleColor = UIColor(white: 100.0, alpha: 1)

cb.buttonColor = UIColor(red:0.0, green:0.70, blue:0.0, alpha:1.00

//forbereder popup vindu

let title = tittel

var message = melding

// oppretter dialog vindu

let popup = PopupDialog(title: title, message: message)

// opretter knapp

let buttonOne = CancelButton(title: "OK") {

print("Ok knapp trykket i poupvindu.")

}

// Legger til knapp i popup vinduet

popup.addButtons([buttonOne])

// Presenter popup

controller.present(popup, animated: true, completion: nil)

}

}

Vi oppretter instans av denne klassen kaller på dens funksjon og sender parameter av det

vinduet vi er i samt teksten vi ønsker å vise på den måten får vi denne klassen generisk ok

kan bruke den i hvilke som helst sammenheng / kode. Slik ser det ut ved f,eks en feil:

86

4.3.1.4 Alamofire:

Alamofire er et HTTP-nettverksbibliotek.

Alamofire er brukt for å gjøre kall på server funksjoner, dermed kan vi bruke put,post,get

som metode. Disse metodene er også brukt av serveren/backend.

Klassen vi har laget for Alamofire er Networking.

Denne kan f,esk bruke slik:

Alamofire.request("url skriver vi her")

Denne metoden kan sendes med parametere og header som serveren tillater. Videre

kan vi gjøre et kall med denne metoden å se om alt gikk greit eller om vi fikk en

feilmelding(dersom serveren er nede, eller parameter/header ikke var riktig).

Alamofire er også egnet for vårt bruk, vi sender og mottar Json objekter noe som gjør at

denne passer for vårt formål.

87

4.3.1.5 AlamofireImage

Ettersom vi bruker bilder i vår applikasjon kan ikke Alamofire laste ned bilder fra server vi

ønsker å bruke. For å få til dette brukte vi et annet bibliotek fra Alamofire som heter

AlamofireImage, AlamofireImage har vi brukt i kontrollere som viser bilder.

Bildene vi bruker er lagt på server med egen adresse, disse får vi som Json objekt i form av

array.

De adressene bruker vi direkte i AlamofireImage metode slik: let

bilde = Alamofire.request(“url på bildet”).responseImage nå

som vi har bildet kan vi bruke den videre som vi måtte ønske.

Vi har valgt å lagre bildene i UImage array så det blir enklere å bruke bildene i testene.

4.3.1.6 FaceBook logginn

Disse er biblioteker vi brukte for å kunne logge inn med Facebook konto.

Facebook har satt opp biblioteket slik at vi ikke får gjort så mye med metodene, og brukeren

blir validert av Facebook servere. Koden for å logge inn via Facebook kontoen:(vi har kodet

hele metoden men viser dette som et ekempel om hvordan man kan implementere, har

fjernet mellom kode og bare vist hva som må til for å kunne logge via Facebook konto:

88

Her sjekker metoden emailen fbLoginManager .logIn(withReadPermissions: ["email"],

handler: { (result, error) -> Void in

//Her sjekkes om det ikke oppstod noe error

if (error == nil){

//Her får vi resultatet om brukeren er gyldig let

fbloginresult : FBSDKLoginManagerLoginResult = result!

//Dersom brukeren tastet riktig email og passord

if(fbloginresult.grantedPermissions.contains("email"))

{

// her kan vi kode det vi måtte ønske(det å få token, navn,email på bruker)

}

else{

//her kodes det som skal skje når brukeren ikke var gyldig

}

else{

//Her kommer koden som sier om det oppstod noe feil

}

}

Når metodene var implementert og appen kjørt blir brukere dirigert videre til egen

innloggingsvindu hvor brukere kunne taste inn passord og email for å logge inn i appen.

89

Dette er mer for sikkerheten til Facebook brukere. Dermed kan ikke apputviklere få tilgang til

brukernes passord. Om brukeren blir godkjent får de token returnert, denne token brukte vi

for å vite om brukeren er riktig og skal få tilgang til appen eller ikke.

Når vi nå har token kan vi bruke emailen til brukeren for å lagre informasjon i databasen,

informasjonen kan være alt fra når brukeren logger inn, tar testen, hvilke test han/hun tar og

poeng.

For å bruke denne funksjonen må vi selv ha Facebook konto og vi må via kontoen opprette

en applikasjon i Facebook developer kono. Vi får da App ID som vi legger inn i applikasjonen.

Nå kan vi også se hvordan brukere bruker appen via Facebook.

Daglig,ukentlig og månedlig.

Vi ser også om unike brukere logger inn, det er da nye brukere som bruker appen for første

gang med Facebook.

90

Et annet analyse av aktive brukere.

Under testing brukte vi testbrukere, vi har mulighet til å opprette disse brukere via Facebook

developer konto. Her er 2 test brukere vi laget for å teste appen vår mot Facebook logginn.

91

4.3.2 Swift 3 programmeringsspråk

Vi valgte kodespråket Swift 3 for IOS enheter, grunnen til dette var at det er det nyeste på

“markedet” og for å kunne lage app til ipad enheter måtte vi bruke Swift.Dette er apples

programvare utviklings språk. Swift språket vedtar sikre programmerings mønstre og legger

til moderne funksjoner for å gjøre programmeringen lettere, mer fleksibel og moro. Dette

var viktig for vårt valg siden vår applikasjon brukes på ipad, selv om Angular er tilpasset til

alle enheter så er Ios appen mer brukervennlig på ipad.Et annet fordel med kodespråket

Swift 3 og dens biblioteker/rammeverk var at webapplikasjonen og Ios appen kunne

kommunisere med samme backend, i form av Json objekter. Det finnes veldig mange

prosjekter/biblioteker i kodespråket C (Objective-C )som man enkelt kunne implementere

sammen med Swift 3. En annen stor fordel med Swift 3 er at alle biblioteker/rammeverk som

er tilgjengelig for bruk, inkludert tredjeparts, leveres via «Cocoapods».

Swift 3 er den første store versjonen som er utviklet åpent på Swift.org, med kildekoden,

bugs sporing, adresselister og regelmessig utvikling er det tilgjengelig for alle. Dette brede

samfunnet av utviklere, både innenfor Apple og hundrevis av utenlandske bidragsytere,

jobber sammen for å gjøre Swift enda mer fantastisk. Swift støtter allerede alle

Appleplattformer samt Linux, med utviklere som aktivt jobber med å få det på flere

plattformer. Vi måtte også bruke dette kodespråket, fordi Apple bruker kun det ene språket

for sine produkter. Det var veldig lett å lære seg og veldig moro å jobbe med. Ingen i gruppa

hadde erfaring med Swift kodespråket og det har heller ikke vært en del av studieplanet,

men vi lærte oss underveis og det gikk veldig bra.

4.3.3 IOS kall mot Web-Api´et

På klientsiden opprettes, hentes, oppdateres og slettes data med kall til API-et. Alle kall til

API-et gjøres igjennom i en service. Dette gjøres i IOS applikasjonen bruk av Alamofire egne

metoder, URL-en(e) som skal brukes som en del av kallet hentes fra URL klassen som også

blir hentet i klassen Networking. URL blir kalt på med post metoden i Networking klassen.

92

Alamofire får også JSON objekt i retur, om det er meldinger i form av objekter eller

informasjon som brukes videre i app slik som token.

4.3.4 Model View Controller

Apple har noen retningslinjer når det gjelder arkitekturen på systemet, og da kan vi se at de

anbefaler Model View Controller(MVC).

https://developer.apple.com/library/content/documentation/General/Conceptual/

MOSXAppProgrammingGuide/CoreAppDesign/CoreAppDesign.html

Design mønsteret MVC har vi brukt tidligere, og var godt kjent til dette, ellers kan vi klikke på

blå linken “Model-View-Controller” under Design pattern for å lære MVC.

MVC består av tre “lag”, Model,View og Controller.

I prosjektmappen opprettet vi tre mapper kalt Model,View og Controller og i disse fordeler vi

prosjekt filene (kode filer) som vi lager.

93

4.3.4.1 Model

Modellobjekter inneholder dataene som er spesifikke for et program, og definerer logikken

og beregningen som manipulerer og behandler dataene. Vi har disse filer i Model. Når de

objektene i Model utfører arbeidet eller blir oppdatert varsler de controlleren om dette.

Model:

• Regex: Denne klassen sjekker om input som brukeren gjør er riktig.

• Testinfo: Denne klassen lagrer all info om testen som bruke videre i appen

• Testen: Denne klassen lagrer informasjonen om testen som brukeren har valgt for å

ta, når instansen er opprettet sendes den videre til neste controller som oppdaterer

view og viser valgte testen.

• Tid: Denne klassen starter og stopper tiden, samt lagrer i variabel, bruker denne til å

registrere tid brukeren tar på en oppgave og hele testen.

• Url: Denne klassen har lagret alle url til backend som igjen brukes sammen med

andre klasser.

• PopUp: Denne klassen lager vi popup som vi ønsker å vise hvor vi ønsker.

• Networking: Her skjer alle kall til backend/databasen og i denne klassen bruker vi url

klassen.

• CollectionViewCell: Denne klassen sørger for å vise alternativer for testen, her kan vi

velge om 4 eller fler bilder skal vises.

94

• TestOgBrukerInfo : Denne klassen lagrer info om brukeren og testen som blir sendt til

andre view.

• Kalkulator : Denne klassen kalkulerer progresjon, dersom bruker klarer det bra

gjennom testen, vil brukeren kunne få vansklig test neste omgang.Går det dårlig vil

brukere få enklere test eller så blir de på den samme.

4.3.4.2 View

View:

• Main.storyboard : inneholder alle view og

koblinger til hverandre.

• LaunchScreen.storyboard: det første viewet som

vises.

Et visningsobjekt er et objekt i et program som brukere kan se. Et visningsobjekt vet hvordan

man tegner seg og kan svare på brukerhandlinger.

Når brukeren gjør en handling vil Controlleren forstå dette, nå vil Controlleren enten

oppdatere viewet eller oppdatere objekt i Modell for å få tilbakemelding for så å gjøre noe

med viewet. View mappen inneholder alle views.

95

Et controller fungerer som en mellomledd mellom en eller flere av en applikasjons view og en

eller flere av modellobjektene. Controlleren får input fra bruker, Controlleren oppdaterer view

eller sender oppdatering til objekter i Model for å få varsel tilbake. Utifra varslen vil så

controllren enten oppdatere Viewet, utføre ingen eller en annen oppgave.

4.3.4.3 Controller

Controller:

• SplashScreenController : loading view controller.

• KontaktOssViewController: Kontakt oss skjema.

• LogginnViewController: Controller for loginn view

• HovedmenyViewController: Controller for view med hovedmeny.

• TesterViewController: Controller for view med test kategorier(bilde tes,lyd test

osv..)

• ResultaterViewController: Controller for resultat view.

96

• OppdaterBrukerViewController: Controller for view der bruker kan endre

passord.

• InstillingerViewController: Controller for view

med instillinger ( lyd, teks til tale, font skrift osv..)

• RegistreringViewController: Controller for view hvor brukeren kan registrerer

seg.

• RegistreringTilbakemeldingViewController: Controller for view som dukker opp etter

vellykket registrering.Brukeren kan her få tilsendt info som de er registrert med på

sin email, eller komme til view etter å ha logget inn.

• BildeTesterViewController: Controller for view hvor brukeren kan velge hvilke

bildetest de ønsker å ta.

• BildeTestenViewController: Controller som viser det viewet hvor brukeren tar testen.

• DemoViewController: Controller for demostrasjon view

• CollectionViewController: Denne kontrolleren styrer en del av viewet dette viewet

syres også av DemoViewController og BildeTestenViewController.

• KodeLogginnViewController: Controller for view der bruker taster inn pinkode og

kommer direkte til view med test som admin har valgt.

• GlemtPassordViewControll: Controller for view som vises om brukeren har glemt

passord og ønsker å få tilsendt et nytt passord.

4.3.4.4 Klassediagram

Vi har valgt å la implementere IOS applikasjonen i klasser, vi har implementert biblioteker i

disse klasser istedenfor å bruke bibliotekene direkte i controllere. Dette er gjort for

skalerbarheten, og for å kunne få applikasjonen generisk som mulig. Ved å få applikasjonen

generisk vil man kunne nytte av den i andre sammenheng. Klassene er også laget slik at de

kan endres eller enkelt fjerne fra systemet uten å gjøre endringer flere steder.

Figuren under viser koblinger mellom controllere og model klassene.

98

4.3.4.5 Model View Controller struktur

Her illustrerer vi hvordan MVC er “koblet” sammen og hvordan de kommuniserer med

hverandre.

Når Ios appen starter vises første view kalt splash screen.Etter 1 - 2 sec vises første view.

Dette viewet er styrt med egen controller,dersom bruker av appen skal logge inn så skjer

følgende:

View - Bruker input/handling - Controller :

Brukeren ser felter og knappen i viewet.

Bruker fyller inn brukernavn og passord,trykker så på knappen “logg inn”.

Dette viewet er koblet til sin controller, i denne controlleren er det kode som skal utføres når

brukeren har trykket på knappen.

Controller - Oppdater - Model:

99

Koden som er i knappen sender info til database for å sjekke om brukeren ligger inne og om

passordet er riktig tastet. Denne koden er ikke direkte kodet i controlleren, men i en klasse i

Model.Vi har kalt en klasse Networking denne klassen tar for seg alle kall mot databasen.

Model - Varsler - Controller:

Etter at klassen/objektet i Model har sjekket at alt er ok varsler denne controlleren om at

infoen er godkjent.Skulle informasjonen ikke være godkjent vil klasen/objektet også varsle

dette.

Controller - Oppdater - View

Dersom alt var godkjent blir viewet oppdatert og et nytt view vises f,eks view etter

innlogging.

Skulle noe ikke være godkjent eller bruker ikke tilkoblet nettet, vil brukeren være på samme

view, men få varsel om problemet.

4.3.6 CocoaPods

CocoaPods er en “pakke/bibliotek behandler” for Swift og Objective-C kakao prosjekter. Den

har over 31 tusen biblioteker og brukes i over 2 millioner apper.Dette gjør det enkelt å legge

til biblioteker uten å gå via nettsider eller manuell nedlastning av pakker. Vi kan enkelt

installere det på Mac´en ved å skrive $ sudo gem install cocoapods i terminalen. Når

Cocoapods er installert oppretter vi en fil kalt podfile i mappen som vi har prosjekt filene i.

Podfilen inneholder alle biblioteker/rammeverk vi ønsker å bruke. nå skriver vi i terminalen

$pod install

Alle nevnte rammeverk/biblioteker blir nedlastet, hver gang man ønsker et nytt rammeverk

skriver vi det inn her og i termianlen $pod install

100

For det første oppretter CocoaPods (som standard) automatisk og oppdaterer et

Xcodearbeidsområde for applikasjonen og alle biblioteker. Sammen med Cocoapods er også

Carthage brukt.Carthage bygger rammeverket ved hjelp av xcodebuild, men legger ansvaret

for å integrere dem opp til brukeren. CocoaPods tilnærming er enklere å bruke, mens

Carthage er fleksibel.

4.3.7 Carthage

Carthage er ment å være den enkleste måten å legge til rammer for kakao applikasjonen.

Disse verktøyene flytter og kompilerer filer automatisk ved bygging av prosjektet, og

forhindrer mye manuell, repeterende arbeid. Vi oppretter Cartfile i prosjektmappen, i denne

skriver vi alle rammeverk som vi ønsker å ha.

101

Vi kan få Carthage via Homebrew,Dette er pakkebehandler for Mac, det som blir installert er

Unix verktøy som Apple ikke inkluderer i sine Mac operativsystemer. Disse verktøyene er

veldig viktige å ha når man skal installere, kompilere og opprette rammeverk.

kan installeres via terminalen ved å skrive:

/usr/bin/ruby -e "$(curl -fsSL

https://raw.githubusercontent.com/Homebrew/install/master/install)”,brew install wget og

brew update.

Nå som alt er på plass kan vi i terminalen skrive:

$carthage update

Vi må alltid skrive dette i terminalen når et nytt rammeverk er lagt til Carthage filen, når alt er

fullført vil vi kunne se rammeverket i Xcode 8 og vi kan legge de inn for videre bruk i

koden/prosjektet. Her er alle biblioteker/rammeverk lagt inn.

Disse kan igjen bruke i koden ved å skrive import også navnet på rammeverket.

https://raw.githubusercontent.com/Homebrew/install/master/install

https://raw.githubusercontent.com/Homebrew/install/master/install

102

4.3.7 Mappestruktur, filer og navngivning

Hele IOS prosjektet ligger i mappen MemoFrameFinal, i denne mappen har vi flere kataloger.

Application Delegate mappen inneholder swift fil ved samme navnet som mappenavnet.

Denne filen har kode som kjøres først og når appen lukkes, her kan man velge hva som skal

skje ved oppstart og ved lukking av app. Vi har ikke hatt så mye behov for å kode i denne

klassen, kun kod relatert til FaceBook logginn ligger her.

I Startup mappen har vi en fil kalt info.plist denne filen er for å konfigurere appen, her kan vi

legge til viktig informasjon relatert til appen.

103

Videre så ligger Model View Controller mapper i MemoFrameMappe i disse ligger de

tilhørende klasser som er beskrevet tidligere i kapittelen 4.3.5.1

104

Slik ser strukturen når vi ser bort fra filene:

Veldig lett å finne frem til de filene man skal finne og veldig oversiktlig, vi ha også sortert og

laget det slik at navigeringen skal være enklest mulig. Det er flere mapper som inneholder

filer, disse mappene er selvforklarende, MemoFrameFinalTests inneholder tester,

MemoFrameFinalUITests inneholder UI (user interface) tester.

Products mappen inneholder selve appen.

Pods mappen har de filene som er lastet ned via CocoaPods, mens Frameworks inneholder

alle rammeverk/biblioteker som er lagt til i appen.Disse er beskrevet i kapittel 4.3.1.2

4.4 Webapplikasjonen

Angular 2 er en utviklingsplattform for å utvikle webapplikasjoner. Alle Angular web

applikasjonene har minst en Module klasse. Den klassen blir brukt for å starte applikasjonen.

Angular 2 består av module, component, route og html filene.

Typescript er et graris og open-source programmeringsspråk som ble utviklet av Microsoft.

Typescript er et supersett av JavaScript og kompilerer til JavaScript før programmet kjøres.

105

Vi beskriver webapplikasjonen her, altså hvordan applikasjonen er satt opp ved hjelp av

klasser.

4.4.1 App component

Appcomponent er “root component” i webapplikajson og er vert for alle components det

routes til.

I Figur x under kan vi si hvordan componentene i en app koblet sammen.

(15)

4.4.2 App route

Angular Route gjør det mulig å navigere fra en view til den neste mens bruker utfører

applikasjons oppgaver. Hver Route linker url til en component. Route filen i angular ser

følgene ut:

15 http://a2.hubwiz.com/docs/ts/latest/guide/architecture.html

http://a2.hubwiz.com/docs/ts/latest/guide/architecture.html

http://a2.hubwiz.com/docs/ts/latest/guide/architecture.html

106

4.4.3 App template

App template er viktigst template i webapplikasjonen. Her finnes det navigasjonsbar og

footer som blir vist i alle views i webapplikasjonen.

4.4.4 App Module

Module er en fin måte å organisere en applikasjon på og utvide den med enver fra eksterne

biblioteker. Module kan også legge til services i applikasjonen. slike services kan være internt

utviklet eller kan komme fra eksterne kilder, for eksempel Angular router og Httpclient.

vi har brukt både eksterne biblioteket og internt utviklet components i Module.

107

4.4 EyeTracking:

Eyetracking er prosessen med å måle enten blikk punktet “point of gaze” (hvor man ser) eller

bevegelsen av et øye i forhold til hodet. En eyetracking er en enhet for måling av

øyeposisjoner og øyebevegelse. Eyetracking brukes i forskning på det visuelle systemet, i

psykologi, i psykolingvistikk og markedsføring. Det finnes en rekke metoder for måling av

øyebevegelse. Den mest populære varianter bruker videobilder hvor øyeposisjoner utvinnes.

WebGazer.js er et øyesporingsbibliotek som ble utviklet av studenter fra Brown Universitet i

USA. WebGazer.js bruker vanlige webkameraer til å utlede de blinkende stedene til web

besøkende på en side i sanntid. Den inneholder selv kalibrer ved å se på at web besøkende

samhandler med nettsiden og trener en kartlegging mellom øyets funksjoner og posisjoner på

skjermen.

108

WebGazer.js er skrevet i JavaScript, og med bare noen få linjer med kode kan integreres i et

nettsted. WebGazer.js kjører helt i klientens nettleser, så ingen video data må sendes til en

server. WebGazer.js kjøres bare hvis brukeren samtykker i å gi tilgang til sitt webkamera.

Alle metoder er definert inn i WebGazer.js. webgazer.begin() metoden starter data

samlingen. Det er enkelt å integrere WebGazer.js på en nettside eller applikasjon. Det eneste

man trenger å gjøre er å klikke på noen steder på skjermen mens man ser på markøren. Både

klikk og markørbevegelser gjør det lettere å samle data fra posisjoner mer nøyaktige der

brukeren ser.

Vi har brukt WebGazer.js i web applikasjon for å gjennomføre brukertester med eyetracking.

Dette kan gi verdifull informasjon om hvor brukeren ser under testene. Eyetracking kjører i

bakgrunn uten å blir vist og samler data ved hjelp av eyetracking. Den vises kun ved

kalibrering. Samlet data bruker vi videre for forskning.

4.5 Admin panel

Vi har utviklet et eget backend-panel for administrator-relaterte enkle CRUD-operasjoner,

d.v.s. opprettelse, håndtering, vedlikehold og endring av tester. Admin panelet er utviklet

ved hjelp av PHP og en Apache server (Se avsnittet om PHP + Apache for mer info), og er kun

optimalisert for bruk på nettet på en datamaskin. Brukergrensesnittet er utviklet ved hjelp

av Bootstrap 4. Adgang til denne delen av applikasjonen er begrenset til kun autoriserte

administratorer.

4.5.1 Sideoversikt

Her er en teknisk oversikt over undersidene i admin panelet. Etter innlogging er panelet delt

inn i flere sider som utfører hver sine oppgaver, med felles startpunkt i kontrollpanelet.

4.5.1.1 Dashboard

Etter innlogging vil du bli møtt på kontrollpanelet med en kompakt oppsummering over

testene, generell statistikk og annen nyttig informasjon, samt tilgang til de hyppigste

operasjonene som å opprette/endre på en test.

109

4.5.1.2 Testoversikt

Under menyvalget All tests kan man få en oversikt over alle de tilgjengelige testene. Man kan

trykke på ønsket test for å få opp flere detaljer, informasjon, oversikt over alle testrundene

som tilhører testen, samt muligheten til å legge til nye testrunder. Klikker man på en

eksisterende testrunde vil alle de tilhørende bildene dukke opp.

4.5.1.2.1 Ny testrunde

Når du er inne på en test, kan du legge til en ny testrunde helt nederst ved å trykke på den

grønne plussknappen. Ved trykk får du opp et modalskjema som legger seg øverst på

vinduet. I dette skjemaet kan du legge til en ny testrunde. Det består av et tekstfelt for å

legge til rundeteksten, og et bildegalleri, med alle opplastede bilder, for valg av bilder som

skal vises på denne nye runden.

4.5.1.2.1.1 Bildegalleri valg

Bildegalleriet er utviklet ved hjelp av jQuery pluginene Image Picker og Masonry.js. Image

Picker brukes til å rendere et grafisk grensesnitt for dropdown-menyen (select) som holder

på alle bildene. Selve menyen er skjult i bakgrunnskoden. Dette blir imidlertid fort rotete og

uoversiktlig jo flere bilder man legger til, og det er her Masonry.js kommer inn i bildet.

Masonry.js generer et mønster som legger bildene i forband (kilde), noe som kan minnes

veldig om hvordan murstein blir lagt (se bildet under). I stedet for at bildene står i rad og

rekke i sammenhengende vertikale fuger, vil et sideliggende bilde forbinde to bilder på den

andre siden. Dette fyller mange av tomrommene mellom bildene og gir et estetisk

tilfredsstillende struktur.

https://rvera.github.io/image-picker/

https://rvera.github.io/image-picker/

https://masonry.desandro.com/

https://masonry.desandro.com/

http://kunsthistorie.com/fagwiki/Forband

http://kunsthistorie.com/fagwiki/Forband

110

4.5.1.2.1.2 Bildegalleri antall valg

Antall bilder som kan velges i bildegalleriet kan justeres på i konfigurasjonsinnstillingene (Se

konfig-avsnittet). Default-verdien er satt til 4.

4.5.1.3 Ny test

Trykker man på undermenyvalget Ny test, under Tests, kan man opprette en ny test. Her er

det flere valg for å tilpasse testen. Merk at det ikke er mulig å legge til testrunder i dette

skjemaet. Det må gjøres under testoversikten (Se .2 over).

4.5.1.3.1 Testskjema

Skjemaet består av alle mulige felter som kan legges inn i databasen. Her er en liste over

skjemaet:

Navn på test: Navnet på testen som skal betegne testen

111

Kort beskrivelse: Denne beskrivelsen forklarer i korte trekk bakgrunnen for testen

Oppgavetekst: Denne teksten forklarer hovedmålet med testen; hva som skal gjøres i hver

testrunde

Tidsdelay: Ventetiden mellom det første bildet som vises i en testrunde og påfølgende

bilderutenettet

4.5.2 Oppbygg

PHP-filene brukt til admin panelet er strukturert ved hjelp av modulær metodikk, og her

beskrives det generelle oppbygget til en del kjernefiler og den helhetlige strukturen.

4.5.2.1 Type filer

Alle PHP-filer brukt i denne oppgaven er såkalte template-filer, det vil si at de primært sett

består av frontend kode i HTML, CSS og Javascript, men at de i tillegg har PHP-kode som

genereres på serversiden. Vi kan likevel dele PHP-filene inn i to hovedtyper for admin

panelet.

Sidefiler: dette er selve PHP-filene som renderer grensesnittet og viser all HTML-kode og

PHP-generert kode. Disse filene representerer de ulike sidene i admin panelet. Eksempler på

slike filer: admin.php, tests.php, pincodes.php.

Assisterende filer: dette er modulære PHP-filer med fokus på å løse en bestemt del av

funksjonaliteten, og som skal inngås i spesifikke deler av sidefilene for å generere det

komplette grensesnittet. Eksempler på slike filer: admin_session.php, head.php, nav.php,

footer.php

4.5.2.2 Skjelettmal for kode

Koden i alle PHP-sidefilene i admin panelet består i grunnmuren av en mal som deler opp

strukturen i flere moduler. Denne oppdelingen forebygger redundans og gir bane for enkel

modifisering, gjenbrukbarhet og oppfyller modularitet. Se figuren under for en generisk

PHPsidefil.

112

Figur: Template for en generisk PHP-sidefil

Andre includes: Helt øverst i PHP-kodemalen kan det legges inn ekstra assisterende PHP-filer

for å utvide funskjonaliteten. I noen av filene inkluderes blant annet en config.php fil for å

laste inn konfigurasjonsverdier fra en sentral fil som er enkel å endre på (Se

filstrukturavnsittet om config.php for mer info).

En viktig fil som går under her er admin_session.php. Denne filen kjører kode for å aktivere

session på filen den inkluderes i, og sjekker om en variabel admin er satt eller ikke i

sessionen. Dette brukes til å sikre alle sidene mot uautorisert tilgang, og i slik tilfelle blir man

omdirigert til login-siden.

113

head.php: Denne filen består egentlig bare av HTML-tagger som importerer eksterne

CSSstilarksfiler (bl.a. Bootstrap), og litt metainformasjon. Denne filen inkluderes under

<head>taggene i PHP-sidefilene. Eventuelle tilleggsimport må skrives manuelt etter at denne

filen har blitt inkludert.

nav.php: HTML-kode for oppbygg av toppbaren på admin panelet, samt navigasjonsmenyen

på venstre side. I tillegg inneholder filen logisk kode for å markere riktig menyvalg avhengig

av hvilken side er man på. For at dette skal virke tar filen imot en variabel $l, av type string,

for indikasjon på hvilken side man er på. Eksempel på en slik implementasjon for siden

tests.php:

PHP-kode:

<?php $l = "all_tests";

include('nav.php'); ?>

Samsvarende kode for denne stringen må legges inn i nav.php filen. Se implementasjon av

eksisterende kode for referanse.

**current_file**.php: det unike innholdet til den PHP-sidefilen som bruker denne malen.

Eksempel på dette er skjemaet som finnes i new_test.php filen.

footer.php: samlested for alle skript-filer (Javascript) som inkluderes i malen. Eventuelle

tilleggsskript må legges til manuelt etter at denne filen har blitt inkludert.

4.5.2.3 API kall

Admin panelet er avhengig av REST API kall for å kunne utføre en rekke operasjoner på

serveren. Disse HTTP-forespørslene mot API-et vårt brukes i mange av PHP-sidefilene, og

inngår alltid øverst i koden. Siden vi allerede har utviklet et tilstandsløst REST API, er det

naturlig at denne anvendes fremfor å direkte koble til databasen via PHP-kode og gjenta den

samme koden. Kallene autentiseres ved at admin-variabel, samt den private nøkkelen,

sendes med i kallene.

114

Autentiseringssiden i starten er kodet i login.php filen, og består av innlogging til admin

panelet. Det er en egen tabell i databasen som holder på administratorene og deres

logindetaljer, som passord (#Se avsnitt om database for mer info). Ved login sammenlignes

brukerinput med det som ligger i databasen for autentifikasjon.

4.5.2.3.1 Httpful

Httpful er et simplifisert bibliotek for anvendelse av REST API gjennom HTTP-forespørsler i

PHP, som er bygget rundt metodekall som kan lenkes sammen (kilde). Dette biblioteket

letter mye av arbeidet fra API kall i ren PHP, og gir oversiktlige, enkle og konsise

klassemetoder som reduserer antall kodelinjer drastisk og gjør koden leselig. Her benyttes

kun HTTP-forespørsel funksjonaliteten fra biblioteket, og alle responser sendes i

JSONformatet.

Her er eksempel på kode for å få tak i alle testene via Httpful-biblioteket:

PHP-kode:

$uri = "URL:8080/api/test/";

$test = \Httpful\Request::get($uri)

->expectsJson()

->sendsJson()

->body('{"admin":true, "passkey": "bachelor2017"}')

->send();

Som vi ser er biblioteket basert på å være leselig og semantisk, og at metodekallene kan

lenkes sammen til en kjede med kall som utføres i rekkefølge. Dette kalles funksjonell

programmering.

http://phphttpclient.com/

http://phphttpclient.com/

115

4.7 Drift

Vi har valgt å hoste vår løsning på egen server.

Vi satte opp raspberry pi som server, og dette var midlertidig løsning inntil vi fikk tilgang til

skolens server.

Nå som vi har tilgang til skolens servere har vi overføre alt fra raspberry til skolens servere.

På raspberry pi har vi installert apache server, NodeJS og phpmyAdmin.

På skolens server installerer vi apache server samt NodeJs og phpmyAdmin. Databasen

ligger også på raspberry pi, denne exporterer vi til skolens server slik at databasen kan

aksesseres via phpmyadmin fra skolens server.

Vi har laget backend delen fra grunnen av, systemet er skalerbar og stabil. Vi har også mye

mer kontroll på alt. Drifting av backend er dermed kostnadsfritt og lett å vedlikeholde.

NodeJs er selveste REST API, mens phpmyadmin er hvor vi kan administrere databasen.

Backend delen er laget uavhengig av klient delen, alle kall blir gjort mot serveren, ingen kall

blir gjort mot klientsiden fra server delen, dette gjør også at man slipper å få feil på serveren

og at man slipper å vedlikeholde. Om backend tjenesten stopper eller skulle krasje går man

via terminal inn på mappen node og skriver node index.js for å starte NodeJs igjen.

IOS applikasjonen inneholder egen klasse med navnet URL, i denne klassen trengs det kun å

endre på base url,det er hoved linken til apache serveren. Istedenfor å skrive url´en flere

steder i koden har vi bevisst laget denne klassen for at man enkelt skal kunne flytte systemet

til et annet sted og kun oppdatere dette på et sted i applikasjonen. Et annet fordel med

klassen er at alle nye linker kan legges i denne klassen og enkelt bruke det sammen med

Networking klassen.

IOS applikasjonen er ikke publisert offentlig enda, fordi arbeidsgiver ønsker å videreutvikle

løsningen. Skulle man ønske å bruke applikasjonen på Ipad kan man enkelt koble ipaden til

Mac og generere applikasjonen for testing eller for bruk. Det er flere måter å gjøre dette på,

skulle også dette publiseres så kan det enkelt gjøres. Enkel guid kan følges her:

116

https://developer.apple.com/library/content/documentation/IDEs/Conceptual/AppDistribut

ionGuide/TestingYouriOSApp/TestingYouriOSApp.html

Webapplikasjon inneholder GET og POST requests med URL til apache server. De URL’ene

må oppdateres til de nye URL’ene hvis systemet skal flyttes til et annet server.

Webapplikasjon kan publiseres på server for å bruke online. Ellers så kjører vi den lokalt via

Visual Studio.

For administrasjonsløsningen har vi satt opp PHPMyAdmin på Apache server slik at den kan

aksesseres via nettleseren. Adressen vil avhenge av hvor man plasserer PHP-filene, men som

standard vil det være http://www.nettside.com/admin.php. Endring i databasen kan gjøres

manuelt via PHPMyAdmin.

Vi har installert raspbian operativsystem på raspberry, og benytter den som hovedserver for

oppgaven. Migrering til en annen løsning er enkel siden det bare er snakk om å flytte filer

over til den nye serveren. For å lagre data har vi laget MySQL database. Applikasjoner kan

endre på databasen gjennom REST API-et, men direkte tilgang til databasen gjennom

PHPMyAdmin gir full kontroll over tabellene.

4.8 Videreutvikling

Applikasjoner har potensiale til mange tilleggsfunksjoner som kan videreutvikle, hele

systemet er laget med tanke på videreutvikling. Dette fordi arbeidsgiver ønsker å ha stabil

system som de senere ville videreutvikle til sin forskning. Vi har mange teknologier og

systemet dekker flere plattformer, dette for å gi arbeidsgiver flere muligheter i forskningen.

Vi har mange ideer og forslag til videreutvikling, og ønsker at dette blir implementert da

systemet er åpnet for videreutvikling. Ettersom løsningen er generisk kan også dette utvikles

til noe helt annet enn dette formålet. Vi har også som ønske å se applikasjonen utvikle til

andre formål da hele systemet har potensialet til det.

117

Hele løsningen er implementert med det nyeste teknologier, noen av de teknologiene er så

nye at de ikke er godt dokumentert og heller ikke fullt utviklet, dette vil også være med på å

kunne gi utviklere muligheten til å kunne videreutvikle løsningen. Under setter vi punkter

som kan forbedres eller videreutvikle.

4.8.1 Administrasjonsløsning (klient)

• Presentasjon av testresultater ved hjelp av graf, testresultater kan ses i databasen.

• Mulighet for å opprette, endre eller slette bruker, alt dette kan gjøres i databasen

manuelt.

• Presentasjon av testresultater av hver enkel bruker, testreultat av hver enkel bruker

kan ses i databasen.

• Oversikt over brukere, oversikten kan ses i databasen.

4.8.2 Webapplikasjon (klient)

• Lyd, språk, tale og fargeblind støtte under innstillinger.

• Logge inn med facebook

• Eyetracking optimalisering

• Kunne vise testresultater for bruker, dette er tilrettelagt men ikke implementert.

4.8.3 IOS applikasjon

Applikasjonen er laget med alle krav fra arbeidsgiver, men vi har lagt inn tilleggs funksjoner

og tilrettelagt for videre utvikling for arbeidsgiver da dette var ønsket. Her vi vil nevne de

funksjonene som vi ikke rakk å implementere, men disse ligger klart for videreutvikling.

118

Forskningsrapport har blitt brukt for å lage design og brukervennlighet, dette for å tilpasse

demenspasienter, om applikasjonen skal brukes til andre formål kan dette endres.

• Innstillinger som lyd,språk,tale og fargeblind støtte. Dette er lagt i appen må bare

kodes.

• Lyd tester, vinduet(view) er tilrettelagt mangler controller og kode.

• Lyd og bilde test, vidnuet (view) er lagt inn mangler å koble controller med kode.

• FaceBook funksjonaliteten kan optimaliseres noe.

• Eyetracking dette var ikke mulig å implementere i IOS app pr dags dato, men vi har

tilrettelagt for å kunne implementere dette.

• Kunne vise testresultater for bruker, dette er tilrettelagt men ikke implementert.

4.8.4 REST API

• Logg for feil.

• Logging av endring i databasen.

4.9 Konklusjon

Vårt prosjekt “Memoframe” er en omfattende løsning med klient og serverside. Vi har

RestAPI, apache server og MYSQL database på serverside, vi har utviklet webapplikasjon, iOS

applikasjon og administratorløsning på klientside. Løsningen på klientside har vi kommet opp

med er både intuitiv og brukervennlig. Når vi ser på alt vi har utviklet så er det ganske mye

på så kort tid.

Nyeste teknologier har blitt brukt, og løsningen kan videreutvikles da dette var et krav fra

arbeidsgiver. Vi har klart å lage generisk løsning noe som er nyttig med tanke på at man kan

bruke løsningen til å lage applikasjoner til et helt annet formål/konsept.

119

Vi er veldig fornøyd med hele prosessen , alt fra valg av oppgaven og utfordringer knyttet til

utvikling av klient- og server side. Vår valg av utviklingsverktøy og utviklingsmetodikk var

veldig nyttig til oppgaven.

Gjennom dette prosjektet har vi lært mye om å sette opp server,systemutvikling,

programmering, applikasjonsutvikling, sikkerhet og har fått erfaring med å bruke nye

programmer,utviklingsverktøy og teknologier.

5 Prosessdokumentasjon 5.1 Innledning

Dette kapittelet forteller om arbeidet som er gjort i bachelorprosjektet, og som har ført frem

til slutt resultatet. Forskningsprosjektet startet 21.november 2016 ved HiOA, vi ble del av

prosjektet 17 januar 2017 det var også da vi satt i gang prosjektet. Vi har jobbet i skolens

lokaler og har prøvet å møtt daglig, de gangene vi ikke har møttes har vi hatt konferanse via

Skype(tall) og jobbet hjemme. Vi har fordelt arbeidsoppgaver likt hvor alle i gruppa har hatt

hovedansvaret for et spesifikk del av løsningen, dette for å ha bedre oversikt og for å sikre

ferdig produkt med god kvalitet selv om alle jobbet med alle deler i løsningen på tvers.

Vi har hatt ukentlig møter med veileder og oppdragsgiver, de møtene var på fredager. Hvor

første møtet var med vår veileder og andre med oppdragsgiver. Det var uker hvor vi hadde 2

møter med oppdragsgiver pr uke, dette for å avklare misforståelser og for å få bedre

forståelse av produktet de ønsket. Evaluering og fremføring var også ukentlig med veileder

og oppdragsgiver. Hvor vi fikk tilbakemeldinger,råd og tips om videre utvikling.

I løpet av prosjektperioden har vi hatt to møter hvor veileder og oppdragsgiver var tilstede,

første møtet fikk vi intro om konseptet og hva de ønsket, andre møtet kom vi frem til krav i

løsningen,enighet om teknologier,i hvilke rammeverk applikasjonene skulle lages i og hvilke

enheter applikasjonen skulle dekke.

120

På de første møtene var ikke oppdragsgiver helt sikker på hva de ønsket selv om vi hadde

ganske mange punkter i kravspesifikasjonen. Litt etter litt begynte arbeidsgiver å forstå hva

hun ønsket, dette gjorde også at vi måtte legge om designet og løsningen begynte å gå mot

det arbeidsgiver ønsket. Det viktigste for oppdragsgiver var at produktet kunne

videreutvikles og de minst fikk til å kjøre en test, hvor data blir lagret samt implementering

av eye tracking.

Det at oppdragsgiver ønsket å videreutvikle produktet gav oss mange nye ideer som vi delte

med oppdragsgiver og det var også det som gjorde at vi fikk lagt inn flere moderne måter å

logge inn i applikasjonen på. Nå er applikasjonen klar for å videreutvikle til hva de måtte

ønske.

Dette kapittelet begynner med en diskusjon av hvordan gruppen har planlagt sitt arbeid og

utviklingsmetodikken vi har valgt.Videre følger en gjennomgang avutviklingsprosessen. Så

diskuterer vi kravspesifikasjon opp mot sluttproduktet, før kapittelet

prosessdokumentasjon avsluttes med våre refleksjonsnotater rundt produktet verdi for

bruker,oppdragsgiver og oss selv og hvordan dette har blitt påvirket av utviklingsprosessen.

5.2 Planlegging og metode

Dette kapittelet omhandler planleggingsarbeid i prosjektet, vi vil ta for oss oppstarten av

prosjektet og planleggingen av arbeidet underveis i prosjektet.

Kapittelet starter med gjennomgang av utviklingsmetodikken vi har brukt i arbeidet.

Videre har vi beskrevet alle verktøyene vi har brukt til planlegging.

Etter dette skriver vi om kompetansen gruppemedlemmene har tilegnet seg og avslutter

kapittelet med prosjektets budsjett.

5.2.1 Utviklingsmetodikk

Smidig utviklingsmetodikk

121

Arbeidsmetoden vi har valgt å bruke under utviklingsprosessen er scrum. Scrum er en

arbeidsmetode som går ut på at man starter med å ha fokus på de mest essensielle

funksjonene som skal til for et kjørende program. Videre i prosessen kan man legge til mer

funksjonalitet, og man skal også være fleksibel til å gjøre endringer i programmet underveis.

Man ønsker å holde et tett samarbeid med arbeidsgiver/kunden, og har derfor faste møter

med disse i korte tidsrom slik at alle parter er oppdaterte. Det er heller ikke så mye fokus på

forberedelse av dokumentasjonen.

I scrum så jobber man i små iterasjoner såkalte ”sprinter” (et begrenset men kort tidsrom).

Man arbeider med en serie utvalgte brukerhistorier (en modul funksjonalitet) i disse

sprintene, og de brukerhistoriene man jobber med blir bestemt på starten av en sprint (fra

sprint backlog). Disse brukerhistoriene kommer fra en liste med brukerhistorier også kalt

”produktbacklog”.

Ved bruk av arbeidsmetoden scrum har alle ulike partier i prosjektet sin egen rolle. For mer

informasjon les vedlagt dokument om scrum.

5.2.2 Fasene i prosjektet

Slik har har prosjektet vært delt i 4 hovedfaser. Se figur x

Figur 5.2.2, Prosjektfaser

Figuren viser Memoframe prosjektmodell som er delt i faser.Første pil viser oppstart av

prosjektet, neste pil viser planlegging. Pilen midt i figuren viser gjennomføringsfase og til

122

slutt har vi prosjekts avsluttning og dokumentasjon. Linjene i figuren x forteller når en fase

starter og slutter, sluttdato på en fase er startdato på neste.

5.2.2.1 Oppstart av prosjektet

Denne fasen varte fra 22. september 2016 - 17. januar 2017, i denne fasen dannet vi

gruppen.

Muddasar og Raja har jobbet tidligere sammen, så de var allerede i gruppe, Zain og

Christoffer som tidligere hadde jobbet sammen var på utkikk etter en gruppe.

Muddasar og Raja hadde jobbet med flere andre fra klassen, men denne gangen ønsket de å

jobbe med noen de ikke kjente. Dette var på grunn av praksisen på arbeidsplassen, der

jobber man med folk man ikke kjenner som oftest. Fra to til fire ble gruppen etter at

Christoffer og Zain takket ja til å bli med i gruppen.

Nå som gruppen var dannet satte gruppen krav til hvordan oppgave de ønsket, før de gikk ut

for å finne prosjektet.Vi fant prosjektoppgaven på skolens hjemmeside. Dette var veldig

interessant og hadde nytte for samfunnet, det var også grunnen til at vi alle valgte

oppgaven. Vi tok kontakt med HiOA, møtte Anis Yazidi og fikk prosjektet den 17.januar.2017

5.2.2.2 planlegging

Planleggingsfasen varte fra 17. januar til 25. februar. I denne fasen jobbet vi med

forprosjektrapporten og kravspesifikasjonen tillegg til det satt vi oss inn i de nye teknologier

som ble bestemt for å løse oppgaven. Vi brukte nesten alle nye teknologier derfor var det

viktig å lære de før vi begynner med gjennomføringsfasen.

Planleggingsfasen startet med å ha et internt møte mellom gruppemedlemmene, hvor vi

valgte oppmøte tidene og inngikk hvilke regler vi skulle forholde oss til. Deretter hadde vi

møte med oppdragsgiver for valg av teknologier. Etter møte med oppdragsgiver og veileder

kom vi frem til å utvikle applikasjon for to forskjellige plattformer altså webapplikasjon og

iOS applikasjon, I utgangspunktet var arbeidsgiver kun ute etter en databaseløsning for å

123

administrere klientsiden. Ettersom dette ikke vil være en optimal løsning for

forskerne/arbeidsgiver, valgte vi å utvikle enkelt et brukergrensesnitt for å kunne

administrere databasen.

Nå som gruppa viste hva arbeidsgiver ønsket, laget de use case, forprosjektrapport,

kravspesifikasjon. Gruppa hadde et nytt møtet med arbeidsgiver, vi la frem

kravspesifikasjonen og use case. Arbeidsgiver var veldig fornøyd og med litt endringer hadde

vi fullstendig kravspesifikasjon vi kunne jobbe etter.

Ettersom vi brukte scrum som arbeidsmetode laget vi backlog av kravspesifikasjonen,

backlog´en ble igjen delt i seks sprint. Ved siden av dette laget vi også “mock-up” av

applikasjonen på begge plattformer og designet. Ettersom en administrasjonsløsning er helt

avgjørende for å få til konseptet om å samle inn data fra applikasjonen, har vi utviklet en

felles administrasjonsløsningen. Vi begynte også med innkjøp av Mac og raspberry pi for å

sette opp egen server, dette var på plass før gjennomføring av selveste prosjektet.

Etter levering av forprosjektrapporten og kravspesifikasjonen til skolen hadde vi siste

gruppemøte før gjennomføringsfasen. I dette møte gikk vi gjennom evaluering av arbeid

under planlegging og ble klar for utvikling av applikasjonen,databasen,server og

administrasjonsløsning.

5.2.2.3 gjennomføring

Gjennomføringsfasen varte fra 25. februar til 27. april. Presentasjon av produktet hadde vi

124

28. april for veileder.

Utviklingen av applikasjonen og administrasjonsløsningen fordelt på fem sprinter (fra første

sprint til sprint 5). Vår første sprint begynte tirsdag uke 8 og avsluttet fredag uke 9. neste fire

sprint starter mandager og avslutter fredag hver andre uke. Siste sprint nr seks var avsatt til

dokumentasjon og testing, denne sprinten startet uke 18 mandag og avsluttet på

innleveringsdato uke 21 onsdag.

Vi hadde fem leveranser, disse leveransene var på slutten av et sprint og på fredager. Hver

gang vi hadde en leveranse fikk vi ny sprint backlog for sprinten som skulle begynnes. Vi

fikk tilbakemeldinger på hver endt sprint, noe som gjorde at vi kunne forbedre det vi

hadde,endre eller legge til noe mer som var ønsket. Siste leveranse sprint nr 6 skjer ved

innlevering av bacheloroppgaven, og inkluderer hele løsningen samt dokumentasjon.

5.2.2.4 Prosjekt avsluttning og dokumentasjon med testing

Siste fasen hadde sprint på fire uker, den varte fra 28. april til 23. mai. Vi rettet små feil på

klientside og skrev ferdig dokumentasjonen samtidig gjorde testing i denne fasen.

5.2.4 Bruk av verktøy i planleggingen

125

Vi har tatt i bruke ulik verktøy for kommunikasjon og rammeverk som assistanse under

prosjektet. Noen av disse var vi kjent med fra før, mens andre lærte vi underveis i prosjektet.

Tidlig i prosjektet tok vi i bruk de alternativene vi trodde var best tilpasset vårt prosjekt. Fant

vi andre alternativer senere som viste seg å fungere bedre, nølte vi ikke med å ta i bruk

disse, ettersom det er en stor fordel å kunne lett tilpasse seg nye teknologier ute i

arbeidslivet.

5.2.4.1 Verktøy for kommunikasjon

Verktøy for kommunikasjon er nødvendig slik at arbeidsflyten mellom personene i gruppa

blir effektiv. Vi har tatt i bruk ulike kommunikasjonsverktøy, noen bedre tilpasset et spesifikt

formål enn andre.

5.2.4.2 Facebook

I den tidligste fasen av prosjektet benyttet vi oss av ”Facebook” som

kommunikasjonsverktøy. Vi fant fort ut at dette ikke var et optimalt verktøy, og var ikke

tilpasset våre behov i lengden.

”Facebook” støtter muligheten for å opprette såkalte ”grupper” hvor man kan invitere andre

personer til en gruppe, dele dokumentasjon, bilder og filer. Man har også muligheten for å

kommunisere skriftlig med andre personer i gruppa ved hjelp av å opprette en ny ”post”,

eller starte en privat samtale med dem.

Derimot så er det å bruke dette som et kommunikasjonsverktøy en ulempe, ettersom at man

alltid blir utsatt for uprofesjonelle omgivelser som kan virke distraherende i et profesjonelt

arbeidsmiljø. Konklusjonen er at facebook er bedre tilegnet sosiale begivenheter fremfor å la

seg benytte som et profesjonelt kommunikasjonsverktøy.

5.2.4.3 Slack

126

Applikasjonen ”Slack” endte opp med å være vårt endelige valg av verktøy for bruk av

kommunikasjon. Man kan opprette ulike ”teams” som får tildelt sine egne url adresser. For å

få tilgang til det område som blir brukt for kommunikasjon og deling, må man skrive in url

adressen i en tilgjengelig nettleser. Dette kan være veldig nyttig ettersom det er veldig lite

man må huske (kun den adressen man fikk tildelt) og krever få trinn for å få tilgang til det

gitte område.

Applikasjonen tilbyr de fleste grunnleggende funksjonene for kommunikasjon slik som

lagring av dokumenter og filer. Derimot tilbyr Slack også muligheten for å opprette spesifikke

kanaler til ulike formål. Man har mye kontroll over disse kanalene og man kan blant annet

opprette en gruppesamtale eller en privatsamtale. Dette er veldig nyttig ettersom man kan

dele opp de diskusjonene, filene og dokumentasjonen på en systematisk måte. Slack tilbyr

også muligheten å filtrere søk etter spesifikke kriterier i diskusjonen, noe som kan være

nyttig hvis man på en hurtig måte trenger tilgang til eldre historikk.

127

Slack har også innebygd integrering med andre kommunikasjonsverktøy som github og

trello, noe som er veldig nyttig fordi dette er teknologier vi har tatt i bruk i prosjektet vårt.

Slack gir også muligheten å dele koden direkte på kanalen, og dette blir da formatert

automatisk. Muligheten for notifikasjon når noen har skrevet noe nytt er også veldig nyttig

ettersom man alltid kan være oppdatert hvis det skulle bli skrevet/lagt til noe nytt.

5.2.4.4 Trello

”Trello” er det verktøyet vi har brukt som arbeidsplan og for å holde oversikt over

utviklingsprosessen. I Trello kan man sette opp ulike tavler med merkelapper som man kan

bruke for å holde oversikt over ting som må gjøres, har blitt gjort eller man har problemer

med.

128

På grunn av disse funksjonene samsvarer verktøyet veldig godt med bruken av

arbeidsmetoden scrum, den arbeidsmetoden vi har valgt å bruke. Brukerhistoriene kunne

enkelt representeres med merkelapper i trello, og de ulike tavlene kunne brukes for å

representere en sprint. Vi hadde en egen tavle som representerte produkt backlog der vi

skrev ned alle brukerhistoriene, og derfra kunne man dra disse til de til hver sin sprint

ettersom man kom videre i utviklingen. Muligheten for legge til notater på alle de ulike

merkelappene var også en nyttig funksjon hvis det noen gang skulle være kommentarer man

ønsket å videreføre til andre i gruppen.

5.2.4.5 Github

For deling av kode har vi valgt å bruke verktøyet ”Github”. Github tilbyr muligheten for å

opprette forskjellige versjoner av kode (også kalt ”grener”) som man kan jobbe med

individuelt. Historikk og tidligere versjoner av kode blir også automatisk lagret i programmet.

Man jobber ut ifra en såkalt ”hovedgren” som fungerer som en rotnode (opprinnelig versjon,

på engelsk ”master branch”). Via denne hovedgrenen kan man opprette ulike ”undergrener”

129

som er eksakte kopier av av denne. Fordelen med dette er man at kan jobbe uavhengig med

en kopi av koden, uten at det har noe å si på koden som ligger i hovedgrenen.

Konseptet er at kode som er under utvikling blir skrevet i undergrenene. Hovedgrenen

fungerer som versjonen der ”sist oppdatert løsning” befinner seg. Når koden i undergrenen

er ferdig skrevet kan den slås sammen med koden i hovedgrenen.

”Github” benytter seg av noen grunnleggende kommandoer:

• ”Commit” begår tilsvarende kode (setter koden man jobber med lokalt som ferdig),

• ”Push” kommandoen overfører den nåværende koden med koden som befinner seg i

hovedgrenen og erstatter det,

• ”Pull” henter og kopierer koden som ligger i hovedgrenen over til nåværende gren,

• ”Discard” sletter og kaster nåværende arbeid man har arbeidet med.

Vi var ikke kjent med bruk av github tidligere men vi vet at det er en stor fordel å beherske

slike verktøy i arbeidslivet noe som gjør dette derfor til en stor fordel at vi har brukt under

prosjektet.

5.2.5 Kompetanseutvikling

Det som har vært veldig viktig med prosjektet er å vise hva vi kan ut fra kunnskapen og

ferdighetene vi har tilegnet oss gjennom studiene som vi benytter i et større prosjekt. Vi

har valgt å brukt nye teknologier som var ukjent for oss ved prosjektstart. Vi har f,eks ikke

hatt programmeringsspråket Swift i studieplanen. Angular 2 et lite del av et valgfag så ingen

på gruppa hadde erfaring med dette og programmeringsspråket Typescript var helt nytt for

oss. Adminløsningen ble utviklet i Php, det var bare en som kunne noe om php på gruppa.

Kommunikasjonen mellom klient og server var via JSON (JavaScript Object Notation) format

dette var også helt nytt for oss.

130

Databaser var det eneste vi hadde jobbet med på skolen, men kun teoretisk og ikke i praksis.

For å håndtere databasen brukte vi phpMyadmin som vi først installerte på serveren og

logget inn på. Å sette opp egen server gjorde vi første gang, men her hadde vi erfaring da vi

har lært om det på skolen og dette gikk relativt fort, samme med apache server. NodeJs

brukte vi som backend løsning, det er nettverksmappen som kommuniserer med databasen

og frontend delen. Dette var helt nytt teknologi og var litt krevende å sette seg inn i men når

vi først forsto det gikk det raskt å implementere alle metoder og funksjoner vi ønsket. Vi fikk

også programmert sikkerheten via token dette lærte vi underveis.

Vi valgte disse teknologiene fordi de er godt egnet til vårt formål, disse teknologiene er

veldig populære og kommer til å bli brukt videre i fremtiden også. Et annet fordel vil være at

videreutvikling kan skje med disse teknologiene og det er flere og flere som benytter seg av

disse teknologiene pr dags dato.

Selv om vi ikke har lært om de fleste teknologiene i løsningen gjennom studiene, har vi lært

oss grunnleggende ferdigheter og fått mye kunnskap fra våre studier som gjør at vi enkel kan

lære oss nye programmeringsspråk og systemer. Det er alltid stor risk når man prøver seg på

det ukjente, men vi hadde trua på oss og den kunnskapen vi hadde tilegnet oss via

studiene.For å minimere risikoen begynte vi allerede i planleggingsfasen hvor vi delte

arbeidet og satt oss inn i de nye teknologiene, vi begynte med å lese dokumentasjon om

aktuelle teknologien samt lage demo. Vi kunne bruke det vi laget i demo inn i vårt prosjekt,

men hovedgrunnen var å kunne se hvordan teknologien fungerte og hvordan vi kunne bruke

dette i vår løsning.

Vi hadde beregnet at ting kunne tatt lenger tid, dette på grunn av at dokumentasjon var

mangelfull og at de funksjonaliteten vi trengte ikke var ferdig utviklet i rammeverkene,et

eksempel på det er eyetracking for IOS applikasjon, men nå som vi vet at denne teknologien

er under utvikling har vi lært hvordan eyetracking egentlig fungerer og kan lage denne

teknologien selv. Ettersom vi ikke hadde nok tid og eyetracking er et prosjekt i seg selv rakk

vi ikke å lage den med implementasjon til løsningen.

131

Vi har lært ganske mye og om de nye teknologiene vi har brukt i løsningen, hadde vi ikke turt

å tatt det valget hadde vi ikke lært noe nytt heller. Vi møtte på noen utfordringer og disse er

skrevet i neste kapittel.

5.2.6 Budsjett

Arbeidsgiver ønsket å bruke så lite som mulig på prosjektet, dermed hadde vi begrensninger

på løsningen, men vi skulle ikke stoppes av disse begrensningene. Vår forslag om å lage IOS

app ble godtatt, for dette trengte vi Mac. Siden IOS applikasjon lages i swift

programmeringsspråk og i programmeringsverktøyet Xcode var vi nødt til å ha Mac. Gruppa

kjøpte Mac til kr 4000,-, vi trengte også server, vi bestemte oss for å sette opp vår egen

server, senere kunne gi dette til arbeidsgiver. Vi kjøpte da raspberry pi 2 til kr 399,- Totalt

brukte gruppa kr 4399,- og løsningen ble fortsatt kostnadsfritt for arbeidsgiver.

5.3 Om utviklingsprosessen

Dette kapittelet starter med å gjennomgå hvorfor vi valgte det vi valgte og forteller om

utfordringer vi har hatt om det var noen, videre vil vi nevne hvordan dette har påvirket

arbeidet og sluttproduktet. Vi nevner så sprintene etter som vi har brukt scrum som

arbeidsmetode. Vi kan velge å skrive utfordringer sprint for sprint, men vi ønsker å vise

utfordringer og valgene på en oversiktlig måte derfor har vi et eget underkapittel for det.

Etter sprintgjennomgangen vil vi beskrive de verktøyene vi har brukt i utviklingen, og

kapittelet avsluttes med noen betraktninger rundt samarbeidet i gruppa og den valgte

utviklingsmetoden.

5.3.1 Utfordringer og valg i løpet av prosjektperioden

Gruppa møtte på mange utfordringer under arbeidet med prosjektet. Største utfordring har

være token, og i dette kapittelet beskrives utfordringene nøyere. Vi forteller også hvordan vi

132

har håndtert utfordringene,hvordan det har påvirket prosjektet og hvilke beslutninger som

ble tatt på grunnlag av utfordringer vi møtte på underveis.

5.3.1.1 Valg av prosjekt

Gruppa hadde mange kriterier , det var utfordrende å kunne velge den oppgaven som passet

oss. Med litt leting fant vi et prosjekt som oppfylte våre kriterier og derfor valgte vi

MemoFrame. Vi fikk oppfylt våre kriterier dette påvirket prosjektet positivt og alle var

motivert gjennom hele prosjektperioden, dette virket veldig positivt på slutt produktet da vi

ble ferdig med de kravene arbeidsgiver stilte oss.

5.3.1.2 Valg av utviklingsmetodikk

Fra tidligere erfaring vet vi at smidig utvikling er den beste med tanke på endringer

underveis samt bekreftelse fra oppdragsgiver(”product owner”) på produktet som utvikles.

Alle i gruppa var enig om at vi skulle bruke Scrum. Dette fortalte vi til arbeidsgiver og de var

positivt til det.

Utfordringer var at det var noen dager der noen gruppemedlemmer ikke kunne møtes for å

løse det problemet hadde vi våre daglige møter over Skype. Vi fikk våre daglige møter, og

Scrum-metoden var positivt for løsningen/prosjektet.

5.3.1.3 Valg av IOS applikasjon

Vi kom med et forslag til IOS applikasjon i tillegg til det oppdragsgiver ønsker, vår

arbeidsgiver var glad for tilbudet og sa ja til det. Utfordringer var at dette var helt nytt for

oss, det å sette seg i programmeringsspråket tok litt tid. Selveste prosjektet gikk greit, fordi

vi begynte å lære oss teknologier i planleggingsfasen. Sluttproduktet ble veldig bra, hvor

oppdragsgiver var veldig fornøyd å ha IOS applikasjon med webapplikasjon og adminløsning.

133

5.3.1.4 Valg av XCode 8

Ettersom vi skulle lage IOS applikasjon kan dette kun gjøres i utviklingsverktøy Xcode 8, vi

hadde ingen erfaring med dette, dette gjorde at vi brukte litt tid med å sette oss inn i dette.

Sammen med programmeringsspråket Swift 3 brukte vi Xcode 8 i planleggingsfasen, det

gjorde at vi ikke fikk noe direkte utfordringer med utviklingsverktøy eller kodingen i

prosjektperioden.

5.3.1.5 Valg av Design

Oppdragsgiver hadde ingen klare retningslinjer om designet, vi var heller ikke klar over hva

oppdragsgiver ønsket så vi fokuserte ikke på design. Utfordringen her var å kunne få til et

bra design som oppdragsgiver var fornøyd med og brukerne av applikasjonen. Vi valgte å

drøye designet, men så var det en dag vi spurte vår oppdragsgiver om hjelp til design. Vi fikk

mange gode tips, men så kom vi frem til at siden appen er rettet mot demens pasienter

hvorfor ikke lage applikasjon tilpasset de og spesielt eldre personer. Da satte vi oss inn i

forskningsrapporter som sier litt om design valg i forhold til demenspasienter og eldre

mennesker,dette kan leses om i kapittelet produktbeskrivelse. Vi brukte noe lenger tid på

design en nødvendig men vi fikk et helt nytt og brukervennlig applikasjon tilslutt.

134

Designet før:

136

Designet etter at vi hadde lest forskningsartikler, fått tips og råd(sluttprodukt):

137

5.3.1.6 logo

Logoen var en stor utfordring og tidkrevende jobb for oss fordi vi ikke fikk noe design forslag

fra oppdragsgiver.

For oss var det veldig viktig å ha en god logo som er veldig verdifull og representerer

produktet vi utvikler.

En logo er visuelle element som gjenspeiler et produkt, derfor ønsket vi at logoen skulle

være nyskapende og representativ for applikasjonen. Logoen er viktig for brukerne til å

oppdage og huske vår applikasjonen. Den ble designet ved hjelp av tre farger.

Vi begynte med å tegnet logoen med hånd og adobe illustrator. Vi endte opp med mange

forskjellige logo design som er følgene:

138

Tilslutt valgte vi sist tegnet logoen med noen noen endringer av farger og uten ramme rundt.

5.3.1.7 Valg av navn

Etter enighet med oppdragsgiver har løsningen fått navnet “MemoFrame”. Dette er en

kombinasjon av det engelske ordet minne (”memory”) og ramme (”frame”). Vi ønsker at

brukeren skal kunne lagre et minne i hukommelsen slik som om et bilde hadde blitt rammet

inn. Dette bildet representerer et minne brukeren alltid vil ha tilgang til, så lenge bruker har

bilde. akkurat slik som om en person som lider av demens ville kunne beholde minnene sine

så lenge de kontinuerlig “trener” hukommelsen slik som ved bruk av “MemoFrame” og

tilsvarende løsninger.

139

5.3.1.8 Adminpanel

Oppdragsgiver ønsket enkelt adminløsning det var grunnen til at vi hadde denne type

løsning. Dette gikk greit da hele admin løsning ble laget i PHP. Designen var vår og alt som

opdrgsgiver ønsket ble implementert.

5.3.1.9 Eyetracking

Implementasjon var et krav fra oppdragsgiver, vi måtte på utfordringer slik som at IOS

applikasjonen hadde ingen rammeverk for øyesporings mekanisme. Det var et nytt

teknologi, mens webapplikasjonen støttet dette, men vi hadde problemer med å importere

javascript i Typescript. Dette gjorde at vi brukte litt lenger tid enn beregnet, det påvirket

prosjektet i en liten grad da vi fant løsningen og fikk implementert øyesporings teknologien i

webapplikasjonen.

Vi har tilrettelagt for videreutvikling,men har ikke implementert øyesporings teknologien i

IOS.

5.3.1.10 token/sikkerhet

Hashing og salting av passord under lagring av passord av en bruker, dette var noe vi måtte

implementere da vi ønsket å sikre brukerens data. Det er ikke mye sensitiv som blir lagret i

databasen, men det er brukerinformasjon så vi ønsker å sikre dette. Dette gikk smertefritt,

men token derimot tok tid. Det er en mekanisme som gjør at kun våre applikasjoner kan

gjøre kall mot server.

Når vi kom til den delen virket ingen kall mot server fra klientsiden. Det gjorde at vi var på et

problem over lenger tid, dette gjorde at vi mistet tid. Vi måtte løse det på en eller annen

måte, det vi gjorde var å hoppe over “problemet” å heller gjøre andre ting relatert til

prosjektet det for å ikke stoppe opp. Etter en litt tid gikk vi tilbake til problemet og da løste

problemet seg og vi kunne koble sammen det meste. Sluttproduktet fungerer pr dags dato

med god sikkerhet.

140

5.3.1.11 utfordringer med arbeidsgiver

Første dag vi møtte vi vår oppdragsgiver, men det viste seg at den personen kun var en del

av det og arbeidsgiver var en annen. Vi hadde intro om prosjektet, men nå var det litt

annerledes. Nye oppdragsgiveren var usikker på selveste prosjektet og kommunikasjonen i

startfasen var vanskelig, begge parter visste ikke hva sluttproduktet skulle bli.

Dette var utfording som påvirket prosjektet, litt etter litt fikk begge parter mer forståelse og

det gjorde at produktet ble slik oppdrags gir ønsket til slutt.

5.3.1.12 Utfordring kall mot server - IOS applikasjon Synkronisering:

Vi møtte på et problem underveis, som gjorde at kallene mot serveren ikke var

synkronisert. Ønsket vi f,eks å få bilder, ble resten av koden utført først. Skulle f,eks en

metode returnere bilder returnerte metoden ingen bilder, så kjørte kallet mot server.

Vi tenkte å løse problemet med semaforer, men da måtte vi bruke semafor flere steder for

få alle kall synkronisert dette var stor jobb i seg selv, Alomafire har metoder som

synkroniserer. Disse metoder var heller ikke aktuelt for oss å bruke. De synkroniserte greit

nok, men da oppsto det problemer flere steder. Med litt leting fant vi et biblioteket

Alamofire-Synchronous. Denne synkroniserte akuratt som vi ønsket og mye arbeid var

spart. Nå måtte vi bare endre på det vi allerede hadde skrevet for å få alt til å

synkronisere.

Vi brukte Alamofire-Synchronous i klassen Networking, koden som vi brukte før vi ikke

synkroniserte:

Alamofire.request("url").responseJSON { response in

if let JSON = response.result.value { print("JSON: \(JSON)")

}

}

for å synkronisere måtte vi endre koden, koden over måtte endres til dette:

141

let response = Alamofire.request("url").responseJSON if let json =

response.result.value { print(“koden blir synkronisert”)

}

print(“så blir det her vist”)

}

Vi kan nå bruke variabelen response videre som vi måtte ønske og dermed er koden synkronisert.

5.3.2 Beskrivelse av sprintene

Sprint 1:

Sprint 1 begynte vi med å opprette database med MYSQL database og satt det ut på server

via phpmyadmin. Tillegg til det jobbet vi med å sette opp prosjektløsning for webapplikasjon

og mvc model for iOS. Vi jobbet også med å utviklet splash screen for iOS applikasjon.

Alt av arbeid gikk uten noen utfordringer. Viktigste delen av denne sprinten var å starte

utvikling av webapplikasjonen og iOS.

Formålet i denne sprinten ble oppnådd.

Sprint 2:

I denne sprinten jobbet vi med å lage REST-API i nodejs og koble dem med database. Vi

testet de REST-API underveis ved hjelp av postman. Vi begynte også å utvikle logg inn,

registrering og gjenopprette passord funksjoner for applikasjon for begge plattformer.

Etter vi ble ferdig med å implementere de funksjonene i begge applikasjoner var vi klar for å

teste med å registrere og logge inn i systemet.

142

Vi brukte JWT-authentication ( JSON web token authentication) for å sikre systemet. Dette

var en stor utfordring for oss da web- og iOS applikasjon kunne ikke få authentication for å

registrere eller logge inn.

Til slutt ble problemet løst og vi kunne registrere og logge inn via web applikasjonen også.

Sprint 3:

Vi jobbet med å designe layout for begge applikasjoner. Slik at brukerne kunne se ulike

testene, resultatene av testene de har tatt, kunne logge ut. Tillegg til det jobbet vi med å

lage resten av REST-API.

Etter vi ble ferdig med layout, begynte vi med å implementere logg inn med facebook og pin

kode.

Sprint 4:

I denne sprinten jobbet vi med å lage tester på back-enden og koble dem med applikasjon.

Etter implementasjon av testene i back-enden kunne vi kjøre de i applikasjonen. Tilrettelagt

innstillinger for videreutvikling senere. Demonstrasjonen av de testene ble ferdig i denne

sprinten.

Sprint 5:

Vi jobbet med å utvikle administrasjonsløsning og testene for brukerne etter innlogging slik

at resultatene av testene kunne lagre på back-enden. Administrasjonsløsning utviklet vi for å

lage nye testene og laste opp nye bilder for testene. Denne løsningen var nyttig for å

administrerer testene uten noen programmerings erfaringen.

143

Sprint 6:

Den siste sprinten varte fire uker. Vi ferdigstilte administrasjonsløsningen, rettet noen bugs

på klientsiden, men hovedfokuset i sprinten var dokumentasjon og testing.

Ettersom Angular 2 er ny teknologi og lite dokumentasjon tilgjengelig manglet vi noe

funksjonalitet som var viktig. For å bli ferdig med dette jobbet to gruppemedlemmer med

programmering parallelt med dokumentasjonen.

5.3.3 Utviklingsverktøy

5.3.3.1 Xcode

Xcode 8

Kodingen ble gjort i Xcode 8, Xcode 8 var veldig lett å installere samt lett å jobbe med.

Xcode 8 inneholder alt som trenger for å lage fantastiske apps til iPhone, iPad, Mac, Apple

Watch og Apple TV. Dette er en raskere versjon av Integrert utviklingsmiljø av type Xcode 8

som hjelper utviklere med å skape og feilsøke. Det er første gang vi har brukt Xcode under

koding av Ios app, vi vil nevne at vi er veldig fornøyd med Xcode 8 og kodingopplevelsen var

på et helt annet nivå. Nye kjøretid problemer varsler om skjulte feil ved å peke ut

minnelekkasjer, og en ny Memory Debugger går dypt inn i objektgrafen.

Xcode 8 er utviker verktøy som kan lastes ned gratis fra App store på Mac.

For å kunne lage Ios app må dette gjøres på en Mac, ingen andre muligheter.

144

Blant programmer i Mac ser vi App Store

Ved å klikke på App store kan vi gjøre et søk på Xcode da vil vi få opp det vi er på jakt etter,

neste var å laste det ned så var vi klar til å sette i gang med programmeringen.

145

Etter at Xcode 8 er lastet ned, vil man kunne se dette blant programmene.

5.3.3.2 Microsoft Visual studio

Microsoft visual studio er en programvare for utvikling av webapplikasjoner, skapt for

operativsystemet Windows. Denne applikasjon disponenerer støtte av forskjellige

programmering språk som C++, C#, ASP.NET, Java, Typescript osv..

Webapplikasjonen ble utviklet og testet i Visual studio 2015. Vi brukte Visual studio for å

lage administrasjonsløsning også. De fleste programmeringsspråk kan programmere i den.

I figur x vil det vise hvordan Microsoft visual studio blitt tatt i bruk.

146

5.3.4 Refleksjoner fra utviklingsfasen

Alle gruppemedlemmene har uttrykt at de synes det var interessant å forsøke seg på å bruke

Scrum som arbeidsmetodikk, og vi har gjort oss både positive og negative erfaringer med

Scrum og vår tolkning av Scrum.

Det har blitt mye prøving og feiling i bruken av metoden, og gruppen har brukt mye tid på

planlegging og estimering, uten at utbyttet av dette har vært åpenbart. Det hadde vært mye

enklere med å ha en scrum master, på denne måten kunne en person kommunisere og

forstått. Flere misforståelser hadde unngått og teamet kunne fulgt Scrum 100%. Dette ville

også gjort at Scrum-metodikken ble brukt likere gjennom hele prosjektet.

Et negativt effekt av det er at Scrum master ville fått mindre tid til programmering, vi hadde

dermed “mistet” en viktig ressurs i en periode.

Dette har spesielt vært viktig for oss siden vi er en sammensatt gruppe, der alle har hatt sin

unike kompetanse å bidra med. Vi valgte ikke noen fast Scrum master, dette var for å kunne

gi alle mulighet til å tilegne seg den erfaring.

For å få optimal bruk av Scrum metoden måtte vi bruke tid på sette oss i dette, men vi er

glad for å ha prøvet ut metodikken i den grad vi kunne. Hadde vi brukt for mye tid på å sette

oss inn i selveste metoden ville det ha gått utover prosjektet, noe som igjen hadde vært

ugunstig.

Dette mener vi imidlertid ville tatt for mye tid vekk fra gjennomføringen.

147

Sprintplanlegging,backlog og sprint log i seg selv var krevende. Vi brukte mange nye

planleggingsverktøy online, vi brukte blant annet Trello hvor vi satte opp tavler for

gjennomføring av Scrum.

Det var vanskelig å sette sprint mål, fordi gruppa ikke hadde erfaring med Scrum, men Scrum

metodikken har vært den beste metodikken i dette prosjektet. Hadde vi f eks brukt

fossefallsmetoden kunne vi ikke i så stor grad lykkes med gjennomføringen og

sluttproduktet.

Det var mange endringer underveis og dette fant vi ut ved ofte møter med oppdragsgiver, og

fikk iverksatt arbeidet for å gjøre disse endringene underveis. Det er alltid vanskeligere og

tyngre å endre en hel løsning senere.

Prosjektet var stort og vi hadde lite tid, forhold til det var det vanskelig å dele prosjektet i sprinter, men vi gjorde vår beste og delte prosjektet på antall sprint ut fra krav som måtte implementeres. Et annet viktig lære vi fikk ut av Scrum var å holde tidsfrister, hver enkel

sprint har en frist med spintens backlog. Ved å gjøre det også vil man klare å jobbe under press, noen ganger er det vanskelig å beregne tiden det tar for valgt sprint logg og da kan det gå utover sprinten noe som vi ikke ønsker.

Det var flere oppgaver vi måtte gjøre som var utenom sprint loggen, selv om vi noen tilfeller

ikke rakk alt i sprinten var backlog sprint og viktig, dette fordi vi hadde en guide vi hadde et

plan å følge.

Daglige møter var must for oss siden det er en del av Scrum, de dagene vi ikke kunne møte

hadde vi møter over Skype.Disse møtene gjorde at teamet fikk mer kontakt med hverandre

og ble trygg på hverandres arbeid.

Gjennom bacheloroppgaven har vi lært masse, vi har brukt mange teknologier og alle

teknologiene vi brukte er nye, det gir oss mulighet til å lære oss det det vi ikke kan fra før. Vi

fikk muligheten til å utvikle backend og frontend løsning, dette er vi glad for.

5.5 Avslutning

Etter 5 måneder med hardt arbeid og ukentlige møter med veileder og oppdragsgiver, kunne

vi endelig si oss ferdige med et godt produkt som kan videreutvikles sømløst.

Å få bidratt til uvurderlig forskning innen demens har både vært et privilegium og en

utfordring. Sluttresultatet står som et bevis på innsatsen vår, det enorme tekniske utbyttet vi

har fått, og ikke minst et verktøy som kan føre til store gjennombrudd for menneskeheten.

Oppgaven står også som et symbol på tre lærerike år på skolen, som er enda et bidragende

faktor for gjennomføringen av prosjektet så vel som et milepæl i livet vårt.

148

Den kunnskapen og de ferdighetene vi har tilegnet oss i løpet av prosjekttiden, både når det

gjelder frontend og backend, er erfaringer som vil være ekstremt nyttige fremover.

Fremtidens teknologier som Angular 2.0, TypeScript, NodeJS og programmeringsspråket

Swift 3.0 er bare toppen av isfjellet over den nye kompetansen vi nå innehar. Vi har fått

innblikk i å skrive ordentlige dokumentasjoner og rapporter, og fått god innsikt i hvordan

smidige metoder som scrum kan bidra til økt effektivitet, produktivitet og god flyt både

innad i gruppen og med oppdragsgiver. Den viktigste erfaringen vi fikk var imidlertid

samarbeidet om en komplett teknisk løsning.

Applikasjonen vi har utviklet har en absolutt nyttig samfunnsverdi, og har flere

bruksområder i det store bildet. Dette kommer av at arkitekturen i applikasjonen vår er

utformet som et grunnbasis som kan bygges videre på. Selv om oppdragsgiveren ønsket en

skreddersydd løsning som bare løser problemet deres, tok vi veien om generisk struktur og

utviklet en solid løsning som kan utvides til allsidige formål. Ikke bare ble oppdragsgiveren

svært fornøyd med dette, men sluttresultatet kan også brukes til å løse andre problemer så

vel som demens.

Gjennom arbeidet har det vært stort pågangsmot å se løsningen vår bli benyttet videre i

forskning, og at applikasjonen skal videreutvikles. Det vil også være veldig spennende å følge

med på forskningsprosjektet for å se løsningen vår bygges videre på, samt få se dens

potensiale til å kunne gi oss svar på mange ubesvarte spørsmål. Vi er svært fornøyde med

samarbeidet vårt med HiOA, og kan avslutte bacheloroppgaven vår med god samvittighet,

eget utbytte og samfunnsnytte.

6 Testing

Målet med testing er å begrense antall feil og avvik i applikasjonene på begge plattformer

samt adminløsningen. Ved testingen får vi også bekreftelse på at det som vi har laget virker

som det skal og bekreftelse på at vi har klart å gjennomføre kravene fra vår arbeidsgiver og

eventuelt andre interessent. Vår produkt blir ikke offentliggjort enda, grunnen til det er at

149

produktet skal brukes i startfasen av et større forskningsprosjekt, så arbeidsgiver ønsker å

videreutvikle løsningen noe før de virkelig tester dette med reelle brukere. Selv om vi ikke

har testet dette med målgruppen, har vi selv samt venner/familie testet løsningen på

enhetene. På den måten får vi tilbakemelding på de feilene/bugs og tilbakemelding på

brukeropplevelse.

6.1 Brukertesting

Kort tid etter at vi hadde fått prosjektet spurte vi arbeidsgiver om de ville hjelpe oss med

brukertesting med tanke på målgruppen løsningen er laget for. Arbeidsgiver var sikker på at

de ikke kunne hjelpe oss med brukertesting, de ønsket å videreutvikle løsningen før de selv

brukertester dette senere.

Gruppen hadde ønske om å brukerteste løsningen, for å få bekreftelse på at det de har laget

fungere slik som det skal og at brukere får et godt brukeropplevelse. Vi sendte mail til

institusjoner som har med demens å gjøre samt Ullevål sykehus. Det var veldig vanskelig for

de å hjelpe oss med dette, vi ble også henvist til andre steder, men vi lykkes ikke med å få til

brukere fra målgruppen.

150

Vi ønsket fortsatt en form for brukertesting, vi fikk testet applikasjonen og vi fikk hjelp av

venner og familie. Det var gode tilbakemeldinger vi fikk, alle syntes at applikasjonen var

enkelt og bruke samt enkelt å forstå. De syntes også at det var gøy å ta de testene. Det

eneste feilen de møtte på var at når serveren var nede eller NodeJs ikke kjørte kunne ikke

brukere logge inn på applikasjonen og heller ikke kjøre demo. Dette ble fikset ved at de får

opp feilmelding om å prøve igjen eller å ta kontakt med admin. Administrator vil kunne

sjekke hvor feilen er slik løsningen er laget.

6.2 Verktøy

Det finnes flere typer verktøy for å teste ut forskjellige deler av løsningen. Oftest inneholder

utviklingsverktøyet også verktøy for testing. Noen ganger ønsker man å bruke ekstern

testing, hvor man bruker verktøy metode som er noe helt fra det utviklingsverktøyet tilbyr.

Vi bruker testverktøy som allerede er integrert i utviklingsverktøy.

6.1.1 Xcode 8 som testing verktøy

Utviklingsverktøyet Xcode 8 som vi brukte med programmeringsspråket Swift

inneholder klasser for å teste deler av koden. Med deler av koden mener vi

units(enhetstesting) testing.

6.3 Planlegging

Vi benyttet oss av testdrevet utvikling gjennom hele prosjektet, det var en del av

planleggingen. Testdrevet utvikling gjør at vi slipper å få mye feil/bugs mot slutten og

dermed kan vi være ferdig med de delene av løsningen uten å bekymre oss om testing

senere.

Den testingen som blir gjort ville være veldig effektiv og vi vil kunne eliminerer de feilene

som oppstår ved egen periode for testing. Det gjør også at løsningen vil ha minimal eller

ingen feil ved leveranse av hele løsningen.

151

Backend ble utviklet parallelt med frontend delen, når vi koblet klient siden med server siden

testet vi funksjon for funksjon og del for del. Vi skulle gå over til neste når det første var

testet og fungerte 100% uten feil. For å være sikker på at vi ikke brukte for mye tid på dette

ble vi enig om å gå til neste funksjon om vi satt fast, så komme tilbake til den funksjonen

eller ta det til slutt.

Klientsiden var også testdrevet utvikling, men i stort sett at vi testet funksjonene fortløpende

når de var laget. Under planleggingen bestemte vi oss for å følge denne metoden når vi lager

produktet.

6.5 Gjennomføring

Testingen har blitt gjort parallelt med hele prosjektutviklingen, så satte vi av 3 - 4 uker der vi

tester løsningen på forskjellige måter, som brukertesting, produkttesting, enhetstesting og

ytelsestesting.

6.6 Produktesting

Her tester hele løsningen om alt som er implementert og ferdig fungerer som det skal. Vi

tester også oppløsning på forskjellige enheter, arbeidsgiver ønsker å få applikasjonen til å

kjøre på forskjellige enheter (pc,mobil og nettbrett).

6.6.1 Enheter og skjermstørrelse

Vi sjekker responsiviteten og hvordan applikasjonen fungerer på valgte enheter. Disse

enhetene er blant annet hva arbeidsgiver ønsker.

152

6.6.1.1 IOS applikasjon

Det er mulighet å få applikasjonen responsive på flere ipad og mobil enheter, men da må vi

ordne dette på alle enheter manuelt. Det finnes ingen måter som tilpasser IOS applikasjonen

automatisk til alle enheter i alle størrelser. Kravet var at applikasjonen skulle virke på ipad

derfor har vi ikke prioritert de andre enhetene og her er et test utført på de enhetene vi har

laget applikasjonen for.

Enhet Operativsystem Skjerm Resultat

ipad air iOS 10 9.7” OK

Ipad pro Ios 10 12.9” ok

Ipad pro Ios 10 9.7” ok

6.6.1.2 Webapplikasjon

Applikasjonen er responsiv og skal dekke alle mulige enheter alt fra mobil, nettbrett og

pc´er.

Vi har testet webapplikajonen på de enhetene vi hadde tilgang til.

Enhet Operativsystem Nettleser Skjerm Resultat

Samsung s7 Androide 6 (Marshmallow) Firefox,Nettleser for

android

5,1” OK

MacBook

Pro

MacOS Sierra (versjon

10.12.2)

Google Chrome, Firefox 13” OK

Ipad mini iOS 9 Safari 7.9” OK

153

6.6.1.3 Adminløsning

Adminløsning aksesseres fra pc´er, vi har testet adminløsningen på flere pc´er for å se om

dette vireker som det skal. Selv om adminløsning ikke var nødvendig å teste på mobile

enheter har vi også gjort det.

Enhet Operativsystem Nettleser Skjerm Resultat

Samsung s7 Androide 6 (Marshmallow) Firefox,Nettleser for

android

5,1” OK

MacBook

Pro

MacOS Sierra (versjon

10.12.2)

Google Chrome, Firefox 13” OK

6.6.2 IOS applikasjon

Test Case Test stadium Resultat

Hovedmeny - logg inn Skal gå til nytt view ved trykking på logg inn. OK

Hovedmeny - ny bruker Skal gå til registrering view ved å klikke på ny

bruker knappen.

OK

Hovedmeny - Kode Ved å trykke på denne skal brukeren til et nytt

vindu hvor de kan taste inn passord.

OK

Hovedmeny - demonstrasjon Skal gå til demo av testene OK

Hovedmeny - Flere

muligheter

Ved å trykke på denne knappen skal brukeren

komme inn på et nytt view.

OK

154

Kunne gå tilbake fra logg inn

vindu

Ved å trykke på “tilbake” knapp skal bruker gå

tilbake til hovedmeny.

OK

Kunne logge inn Logge inn med passord og email OK

Gi brukeren feilmelding ved

feil passord eller email

Skal ikke kunne logge inn med feil bruker eller

passord.

OK

Registrer ny bruker Skal kunne registrere ny bruker, eventuelt få

feilmelding om noen felt ikke er fylt riktig eller

tomme.

OK

Glemt passord Bruker skal kunne få tilsendt radom passord på

mail.

OK

Facebook logg inn Kunne logge inn med eksisterende Facebook

konto.

OK

Kontakt oss Bruker med gyldig epost skal kunne kontakte

admin.

OK

Demo Bruker skal kunne ta demo test OK

Tester Bruker skal kunne velge blant tester admin lager OK

Oppdater passord Bruker skal kunne bytte passord. OK

Utlogging Bruker skal kunne logge ut. OK

Test Bruker skal kunne ta valgt test. OK

155

6.6.3 Adminløsning


Innlogging Admin skal kunne logge inn i admiløsning. OK

Utlogging Admin skal kunne logge ut. OK

Lage tester Admin skal kunne lage tester. OK

Pinkode tester Admin skal lage et bestemt test for et bestemt pinkode. OK

Slette tester Admin skal kunne slette tester. OK

Endre tester Admin skal kunne endre tester. OK

6.6.4 Rest API med databasen


Test liste Liste opp alle tester OK

Tilkobling Kall mot databasen OK

6.7 Enhetstesting

Enhetstesting tar for seg av en isolert funksjon av gangen. Hvor vi tester om funksjonen

virker som vi ønsker. Denne testen skal være automatisk og raskt. Vi har prøvet å

enhetsteste all funksjonalitet, men prioritert de viktigste. På klientsiden laget vi enhetstester

som først sjekket funksjoner/metoder mot dummy server. Når funksjonaliteten var riktig

implementert i backend brukte vi koden i klient applikasjonen mot serveren. Det gjorde at vi

ikke trengte å vente på at backend funksjonaliteten var klar og kunne jobbe uten å måtte

vente.

156

For riktig enhetstesting så skal testene kjøres raskt, samme resultat skal vises hver gang, det

skal også testes for om funksjonen feiler og testene skal enten feile eller passere. Vi har i

noen tilfeller laget enhetstesting før produksjonskoden dette for feilsøke koden effektivt.

6.7.1 IOS Unit Testing

Her tester vi de viktigste klassene og funksjonene, det tok litt tid å sette opp enhetstesting,

men når det først virket så gikk resten veldig enkelt.

Vi legger til testklasse og i den er koden generert vi trenger kun å kode klassen som vi

ønsker.

Oppsettet er veldig enkelt: Her er testklasse som blir generert:

Først er XCTest importert dette er rammeverket for testing

@testable import MemoFrameFinal er prosjektet vi bruker i testingen altså IOS

applikasjonen prosjekten.

setUp() funksjonen blir kalt på hver gang et funskjon skal testes.

tearDown() funksjonen blir kalt på når en funksjon er testet, dette for å nullstille variablene.

Videre kan vi lage våre funksjoner, her er et utdrag fra klassen regex:

157

Først har vi alle alle variabler vi skal bruke under testing, så setter vi dem opp i setUp()

ettersom vi bruker samme variabler så trenger vi ikke å nullstille noen og ingen av variablene

blir endret under testing derfor er teraDown() ikke kodet.

så har vi kodet funksjoner under første metoden tester om koden er riktig tastet, mens

andre tester på om koden var feil tastet inn. Disse funksjonen returnerer true eller false så

første testen sjekker om vi får returnert true i neste tester vi om passordet verifiskajonen

feilet ved false.

Vi kan nå sjekke om hele testklasser passerer, vi kan også sjekke funksjoner i klassene en for

en om hva som feiler og hva som passerer, etter enhetsteigner resultatet:

158

6.8 Ytelsestest

Et av grunnen til at vi valgte NodeJS var på grunn av ytelsen fremfor PHP, backend løsning vi

har valgt er skalerbar. Noe som gjør at serveren skal kunne klare å ta imot flere brukere på

en gang. Vi hadde planer om å stressteste serveren, men ettersom alt er flyttet til skolens

server fikk vi ikke tid til å teste skolens servere. Det er allerede mye trafikk på skolens server

som de takler ,det ville ikke vært noe problem å ha mye trafikk på serveren av vår løsning

uansett.

159

6.9 Sikkerhet

Vi har implementert sikkerhetsmekanisme som authentication, denne mekanismen gjør at

vår applikasjon blir verifisert først, om de skal ha lov til å gjøre kall til REST API. Disse kalles

POST,PUT,DELETE og GET. Vi sjekket mekanismen ved å bruke et kall mot REST API manuelt.

Dette ser ut til å virke slik vi ønsker, vi fikk ikke tilgang til å gjøre kall som POST,PUT,GET og

DELETE mot server.

Når det gjelder lagring av passord for brukere så er det blitt brukt algoritme som hasher

passordet og salter før det lagres i databasen. For å teste om passordet er riktig kryptert har

en i gruppa laget passord og vi andre i gruppa har prøvd å “knekke” koden, vi brukte mange

verktøy et av de var ordbok angrep eller Rainbow Tables og det var ikke mulig å få bruker

aksess.

6.10 Integrasjonstesting

For omfattende testing av API-et ble programmet Postman brukt. API-endepunktene ble

hele tiden testet underveis ved hjelp av enkle HTTP-forespørsler med ulike HTTP-metoder

(POST, GET, osv.). I tillegg ble serveren benyttet for å identifisere feilene og bugsene.

6.10.1 Postman

Postman er et desktopbasert verktøy for grundig testing av API-er, utviklet i Electron ved

bruk av webteknologier. Programmet har et intuitivt grensesnitt for å taste inn en URL-sti,

sammen med HTTP-metode, parametre som skal sendes med, og en del andre alternativer

for autentisering, format, osv.

160

Figur: Skjermdump av programmet Postman. Her er en respons i JSON-format returnert etter

kall på et API-endepunkt.

Programmet ble brukt til å teste de fleste API kallene. Dette lettet testingen utrolig mye, og

bidro til å fortere finne bugs og feil i serveren.

161

6.10.2 Server

Konsollen i serveren som tjener REST API-et ble ofte brukt for å lese feilmeldingene som dukket opp.

Disse meldingene bidro til å hurtigere diagnostisere problemet, og var en uvurderlig ressurs for

testing.

Figur: Skjermdump fra Raspberry PI serveren. Vi er tilkoblet til eksternt skrivebord fra en annen PC. Terminalen viser at

NodeJS server kjører.

162

7 Vedlegg

7.1 Kravspesifikasjon

Forord

Hensikten med en kravspesifikasjon er å gi et overblikk over programmets funksjonalitet og

tilleggsfunksjoner, dette vil si både over de som er utviklet før prosjektstart, og de som er

utviklet ved utviklingsfasen.

Dokumentet er beregnet for alle involverte rundt prosjektet. Disse består blant annet av

oppdragsgiver, utviklere, driftspersonale og sluttbrukere. Dokumentet skal gi et innblikk i hva

og hvordan systemet skal operere. Kravspesifikasjonen skal også fungere som en intern

kontrakt mellom utvikler og arbeidsgiver, og må stadig godkjennes av begge parter.

Applikasjonen fungerer som et treningsverktøy tilpasset hovedsakelig demente personer, og

som et datainnsamlings verktøy for forskere. Brukerne vil kunne trene hukommelsen sin,

eventuelt forebygge demens, mens forskere vil kunne se resultatet i en form for statistikk.

Det er også viktig å la brukerne teste produktet slik at man får nok informasjon til å

videreutvikle applikasjonen.

Kravspesifikasjon brukes som veiledning for prosjektet og for å ta beslutninger.

Kravspesifikasjonen vil bli endret underveis, men disse endringene må godkjennes av begge

parter før det forekommer endring i dokumentet. Når produktet er ferdigutviklet skal

kravspesifikasjonen stemme overens med produktet.

Kravspesifikasjonen skal også fungere som en veileder for sensor om hva som kan forventes

av prosjektet. Dette gjør at sensor kan sammenligne kravspesifikasjonen med det endelige

resultatet.

163

Arbeidsmetoden vi har valgt å bruke er scrum. Man jobber i korte intervaller og arbeidet skal

gjøres i henhold til kravspesifikasjonen. Det kan forekomme nye endringer eller situasjoner

som gjør at kravene endres eller utvikles trinnvis. Ved bruk av denne metoden vil det føre til

en tettere dialog med arbeidsgiver som også vil godkjenne implementasjonen for hvert

intervall, og da minsker man sjansen for at uønskede problemer oppstår.

Innhold - Kravspesifikasjon

1 Presentasjon

2 Bakgrunn

3 System Beskrivelse

3.1 Systemkrav

3.1.1 Webapp

3.1.2 iOS

3.2 Tekniske krav

3.3 Krav til koden

3.4 Bruk og brukervennlighet

3.5 Dokumentasjons krav

3 System Beskrivelse

Vi skal utvikle en applikasjon som er hovedsakelig tilpasset demens-pasienter, men det

vil også være mulighet for vanlig brukere å trene hukommelsen. Treningsoppgavene vil basere

164

seg på arbeidet til Prof. Erik Arntzen som har lang erfaring med forskning innenfor demens.

Oppdragsgiver hadde også et ønske om at treningsoppgavene skullle støtte

øyesporingsfunksjonalitet, slik at man kan kartlegge sammenheng mellom øyebevegelser og

brukerens atferd.

Applikasjon skal også fungere som et datainnsamlingsverktøy som skal gi forskerne

statistikk over brukerens poengsum, tidsforbruk, alder, kjønn, land og hvordan deres atferd

er over tid.

Applikasjonen skal være utviklet som en webapplikasjon og en iOS applikasjon. Ved

hjelp av brukertesting skal vi forsikre oss at applikasjonen vil være brukervennlig og stabil.

Applikasjonen vil ikke kreve noen erfaring fra brukerne. Den er designet slik at den

skal være enkel å bruke for alle målgrupper, også eldre personer. Det stilles både

funksjonelle og ikke funksjonelle krav til systemet for å utvikle applikasjonen. Disse kravene

kommer under “systemkrav”:

MÅ - Kravet må implementeres for at prosjektet er tilferdsstilt på minimumsnivå

BØR - Kravet bør implementeres hvis mulig, men prosjektet er ikke avhengig av det

KAN - Kravet kan implementeres om det ikke ødelegger for krav med høyere prioritert.

3.1 System krav

KUNDENS KRAV TIL FUNKSJONALITET

3.1.1 Webapp

Brukeren taster inn url i webbrowseren og da skal man komme til loading screen.

Loading Screen:

Progressbar / logo

Innloggingsvindu:

Det vinduet er det første brukern kommer til.

Brukere skal kunne registrere seg

165

Brukere skal kunne logge inn ved hjelp av e-mail og passord

Brukeren skal kunne gjenopprette glemt passord

Info om appen og generell info

Brukeren skal kunne få demo versjon

Kontaktinfo

Bruker skal kunne logge inn med facebook

Hovedmeny:

Navigasjonsmeny med selvforklarende ikoner.

Brukere kunne ta ulike tester

Brukere kunne se resultatet av testene de har tatt

Logge ut

Brukeren skal kunne endre passord

Registrerings vindu:

Brukere kunne registrere seg ved hjelp av epost,land, kjønn, alder og

passord. Brukeren skal kunne gå tilbake til innloggingsvinduet

Glemt passord vindu:

Brukere skal kunne gjenopprette passord

Brukeren skal kunne gå tilbake til innloggingsvinduet

Innstillinger:

Kunne justere lyden

kalibrering av øyesporing


166

Ønsket tilleggsfunksjoner:

Kunne gjøre om fra norsk til engelsk.

Test:

Brukere skal kunne se og ta alle tester.


Resultat:

Brukere kunne se resultater av testene de har tatt.


Tilgjengelighet:

For svaksynte

Fargeblindhet

Lese opp tekst (TTS, text to speech)


3.1.2 iOS

Etter at brukeren har lastet ned applikasjonen kan brukeren trykke på

ikonet for starte appen.

Man kommer til loading screen.

Loading Screen:

Progressbar / logo

Innloggingsvindu:

Det vinduet er det første brukern kommer til.

Brukere skal kunne registrere seg

Brukere skal kunne logge inn ved hjelp av e-mail og passord

167

Bruker skal kunne logge inn med facebook

Brukeren skal kunne gjenopprette glemt passord

Info om appen og generell info

Brukeren skal kunne få demo versjon

Kontaktinfo

Hovedmeny:

Navigasjonsmeny med selvforklarende ikoner.

Brukere kunne ta ulike tester

Brukere kunne se resultatet av testene de har tatt

Logge ut

Brukeren skal kunne endre passord

Registrerings vindu:

• Brukere kunne registrere seg ved hjelp av epost,land, kjønn, alder og passord.


Glemt passord vindu:

Brukere skal kunne gjenopprette passord


Innstillinger:

• Kunne justere lyden

• kalibrering av øyesporing


Ønsket tilleggsfunksjoner:

168

Kunne gjøre om fra norsk til engelsk.

Test:

Brukere skal kunne se og ta alle tester.


Resultat:

Brukere kunne se resultater av testene de har tatt.


Tilgjengelighet:

For svaksynte

Fargeblindhet

Lese opp tekst (TTS, text to speech)


3.1.3 Administrasjonsløsning

Admin View:

Admin panelet brukes for admin personer til å samle data i statistikk form. Dataen skal

videre brukes i større forskningsprosjekt.

Kunne lage nye tester.

Kunne lage nye pin koder.

Kunne se alle testene.

Kunne endre testene.

Backend:

169

• Database som holder info på brukeren,tester,tid og alt som kan vises i

statistikk.

Tekniske krav

Applikasjon skal utvikles for iOS enheter

Applikasjonen skal utvikles med Swift 3 i Xcode 8.

Webapplikasjonen skal utvikles i Angular 2 medd typescript.

Webapplikasjonen skal også utvikles i html,css og javascript.

Krav til koden

Kodingen og kommentarer skal skrives på engelsk.

Koden skal være ryddig og ha riktig syntaks.

Kodingen skal struktureres slik at det skal være enkelt å endre eller sette inn nye

funksjonaliteter inn i applikasjonen i fremtiden.

Krav til grensesnitt

Det skal ta hensyn til universell utforming.

Det skal være enkelt å navigere for brukerne.

God bruk av skriftstørrelse og tekst.

Fokus på detaljer.

Gjenkjennelig logo for applikasjonen.

Bruk og brukervennlighet

Applikasjon skal være på norsk.

Applikasjonen skal være lett å bruke og krever ikke noe erfaring.

170

7.2 Smidig arbeidsmetodikk – Scrum

Scrum – en kort oversikt

Scrum er en empirisk (erfarings basert) arbeidsmetode som blant annet har fokus på at man

er fleksibel og åpen til endringer. Man er opptatt av feedback fra kunden og man ønsker å

være tidlig ute med resultater av fungerende programvare.

Fordelen med scrum er at det blant annet kan egne seg for ”små team”. Med tanke på

størrelsen av antall medlemmer til vår bacheloroppgave, kan det derfor være nyttig å

benytte seg av scrum rammeverket. Arbeidsgiveren vår har også et klart bilde på hvordan de

ønsker applikasjonen skal være, så en arbeidsmetode som inngår mye feedback og tett

samarbeid vil være gunstig.

I scrum arbeider man i såkalte ”sprinter” og iterasjoner. Innenfor disse holder man seg

innenfor spesifikke rammer. Eksempel på arbeidsflyt på en sprint er slik:

1. Gjennomgang av produkt backlog

2. Sprint planning -> sprint backlog

3. Selve sprinten (2-3 uker, tid vil variere)

Daily scrum

4. Sprint review

Sprint retrospective

Roller

171

Scrum består av forskjellige roller som har ulikt ansvar og funksjoner for at arbeidsmetoden

skal fungere.

• Produkteier

- Hovedansvar for å definerer ulike egenskaper og funksjonalitet ved produktet

- [derfor] Ansvar for brukerhistorier - Hovedansvar for produkt backlog.

• Scrum master

- Hovedansvar for møtene

- Bindeledd mellom produkteier og utviklerteamet

- Kontaktperson

- Generelt hovedansvaret/tilsyn over sprinten

• Utviklerteamet

- Software utviklere

- Testere

- Forfattere osv

Brukerhistorier

Produkt backlogen og sprint backlogen består av brukerhistorier. Dette er simulerte

”situasjoner” som skal gjøre det lettere for utviklingsteamet å sette seg inn i og forstå

kundens eller brukernes behov.

Brukerhistorier defineres på dette formatet:

”Som en ____

ønsker jeg å ____ slik at

jeg kan/vet ____”

Eksempel:

172

”Som en bruker

ønsker jeg å se en progressionsbar slik at jeg vet hvor lenge jeg

må vente for at jeg er inni programmet”

Ressurser

• Produkt backlog

- Produktets egenskaper og funksjonalitet. Består av alle brukerhistoriene.

• Sprint backlog

- Består av utvalgte brukerhistorier som skal settes i fokus i tilsvarende sprint

- Består av de brukerhistoriene som er mest relevante og har høyest prioritering

• Burndown chart

- Viser progresjonen i sprinten

- Hvilke brukerhistorier som har blitt gjort, og hvilke som fortsatt mangler, og evt

hvilke brukerhistorier som har fått ”stopp” (det oppstår et problem eller at man ikke

vet hvordan man kommer videre)

Møter

• Sprint planning

Dette utføres i starten av en sprint. Her diskuterer man de brukerhistoriene som er

de mest relevante og prøver å anta en størrelse på dem. Sprint planning fører til

opprettelse av en sprint backlog.

• Daily scrum

173

Daglige møter hvor mange diskuterer hva som har blitt gjort siden forrige daily

scrum, hva som skal gjøres til neste gang, og evt hva man sitter fast med. Gjøres for

orientering.

Review/retrospective (2 deler)

• Sprint review

Viser kunden produktet, en gjennomgang og evaluering av produktet hittil o.l

Sprint retrospective

Hva man kan gjøre bedre ved neste sprint (relasjoner, arbeidsforhold, verktøy o.l)

generelt en refleksjon over arbeidet og arbeidsforholdet

7.3 Risikoanalyse

De viktigste risikoene for Prosjektet.

Risiko Sannsynlighet Konsekvense

Sykdom Middels Lav

Tidsmangel Høy Høy

Lite kunnskap for teknologier Middels Høy

Bugs i applikasjoner og back-end Høy Høy

Dårlig kommunikasjon mellom oppdragsgiver og gruppe Lav Høy

Gratispassasjer Lav/Moderat Høy

bachelorprosjekt - hioastudent.cs.hioa.no/hovedprosjekter/data/2017/18/final bachelor rapp… · 6...

Documents