Telefon: 22 45 32 00

Telefaks: 22 45 32 05

BACHELORPROSJEKT

HOVEDPROSJEKTETS TITTEL PersonAAL - active and assisted living

DATO 24.05.2017

ANTALL SIDER / BILAG 123 / 4

PROSJEKTDELTAKERE Elisabeth Kongshavn s194524 Julian Refsland s236638 Huebert Miguiel Fabros s236358

INTERN VEILEDER Thor E Hasle

OPPDRAGSGIVER International Business Machines AS

KONTAKTPERSON Loek Vredenberg

SAMMENDRAG PersonAAL er et forskningsprosjekt i samarbeid med Sunnaas Sykehus og IBM AS. I løpet av prosjektperioden har vi utviklet en applikasjon som støtter bedre overholdelse av medisinske resepter.

3 STIKKORD Webapplikasjon Web API, IBM Cloudant Database

Angular 2, Node.js, Express.js

1

HØGSKOLEN I OSLO OG AKERSHUS FAKULTET FOR TEKNOLOGI, KUNST OG DESIGN

Bacheloroppgave i Ingeniørfag- Data & Informasjonsteknologi

Gruppe 22

Elisabeth Kongshavn s194524 Huebert Miguiel Fabros s236358

Julian Refsland s236638

2

3

Innholdsfortegnelse 1 Oppsummering 7

1.2 Innledning 8

1.3 Involverte aktører 10 Student Gruppen 10 Veileder fra Høgskolen i Oslo & Akershus 10 Oppdragsgiver 10 Kontaktperson fra IBM 10 Veiledere fra IBM 10

2 Prosessen 11

2.1 Oppgaven 11

2.2 Planlegging og metode 11 2.2.1 Kravspesifikasjonen 11 2.2.2 Endring i kravspesifikasjonen 11

2.3 Metoder, verktøy og teknologier 12 2.3.1 Design thinking 12 2.3.2 Smidig utvikling 13 2.3.3 Scrum 14 2.3.4 Hvorfor Scrum 14 2.3.5 Sprinter 15 2.3.6 Planlegging av sprint 15 2.3.6.1 Sprint 0 16 2.3.6.2 Sprint 1 16 2.3.6.3 Sprint 2 17 2.3.6.4 Sprint 3 17 2.3.7 Vår erfaring med Scrum 18

2.4 Verktøy 19 2.4.1 Box Note 19 2.4.2 Git/Github 19 2.4.3 Facebook 20 2.4.4 Slack 20 2.4.5 Google Drive 20 2.4.6 IBM Bluemix DevOps Services 21 2.4.7 IBM Bluemix Git 21 2.4.8 Cloudant Dashboard 21 2.4.9 IntelliJ IDEA 22 2.4.10 Visual Studio Code 22 2.4.11 yEd 22 2.4.12 Visual Paradigm 23

4

2.5 Teknologier 23 2.5.1 Node.js 24 2.5.2 Angular 2 24 2.5.3 Express.js 24 2.5.4 IBM Bluemix Cloudant NoSQL Database 24 2.5.5 JavaScript 25 2.5.6 TypeScript 25 2.5.7 MEAN-Stack 25 2.5.8 HTML5 25 2.5.9 Bootstrap 4 26 2.5.10 Cascading Style Sheets 3 26 2.5.11 ECMAScript 2015 26 2.5.12 Babel.js 27 2.5.13 Passport.js 27 2.5.14 Web API 27

2.6 Fremdriftsplan 27 2.6.1 Fremdriftsplan 28 2.6.2 Prioriteringsliste 28

3 Universell utforming 29 3.1 Responsive versus Adaptive Web Design 30 3.2 Flyten 30 3.3 Relative Enheter 31 3.4 Bruddpunkt 32 3.5 Max og Min verdier 32 3.6 Nested objects 33 3.7 Mobile or Desktop first 34 3.8 Webfonts versus System fonts 34 3.9 Bitmap bilder versus Vektorer 35 3.10 WCAG 2.0 36 3.10.2 Mulig å oppfatte 36 3.10.3 Mulig å betjene 36 3.10.4 Forståelig 37 3.10.5 Robust 37

4 Utviklingsprosessen 39 4.1 Startfasen 39 4.2 Research 40

4.3 Sprinter 41 4.3.1 Sprint 0 41 4.3.2 Sprint 1 44 4.3.3 Sprint 2 48 4.3.4 Sprint 3 56

5 Begrensninger 58

5

5. 2 Utviklingsprosessen avsluttes 59 5.2.1 Arbeidsfordeling og samarbeid 59 5.2.2 Forhold til oppdragsgiver 60 5.2.3 Veiledning fra Høgskolen 60

6 Produktdokumentasjon 61 6.1 Leserveiledning 61 6.2 Overordnet systembeskrivelses 61 6.3 Videreutvikling for utviklere 61

6.4 Webapplikasjonen 63 6.4.1 Forsiden 63 6.4.2 Registrering 64 6.4.3 Min side 67 6.3.4 Toggle-tip 68 6.4.5 Endre profilinformasjon 69 6.4.6 Medisinliste 71 6.4.7 Medisinlisten er tom 72 6.4.8 Kalender 73 6.4.9 Legge til medisin 74 6.4.10 Push-notifications 77

6.5 Samsvar mellom kravspesifikasjon og endelig produkt 78

6.6 Applikasjonens oppbygging og virkemåte 81 6.6.1 MEAN-Stack struktur og informasjonsflyt 81 6.6.2 Systemarkitektur 82 6.6.3 Microservice 83

6.7 Frontend 84 6.7.1 Brukergrensesnitt 84 6.7.2 Bootstrap & Responsive Web 84 6.7.3 Angular 2 87

6.7.4 Backend 90 6.7.4.1 Web API 90 6.7.4.2 Cloudant databasen 92 6.7.4.3 Databasestruktur 93

6.8 Sikkerhetsaspekter ved applikasjonen 94 6.8.2 Tilgangskontroll og passordlagring 94

6.9 Deployering av applikasjonen 98

7 Testing av applikasjonen 99 7.1 Enhetstesting 99 7.2 Testplan 99 7.3 Gjennomføring 99 7.4 Konklusjon av testing 100

6

8 Videreutvikling 101 8.1.1 Brukergrensesnitt 101 8.1.2 Caregiver 101 8.1.3 Push Notifications 101 8.2 Andre tanker 102

9 Konklusjon 103 9.1.1 Utfordringer 103 9.1.2 Hva kunne vært gjort annerledes 104 9.1.3 Læringsutbytte 104 9.2 Videre arbeid 105

Vedlegg Nr 1 Kravspesifikasjon 106

Vedlegg Nr 2 Fremdriftsplan 114

Vedlegg Nr 3 Ordbok 115

Vedlegg Nr 4 Litteraturliste 120

7

1 Oppsummering I denne rapporten vil du som leser få et innblikk i hvordan det har vært å delta i

PersonAAL prosjektet, et forskningsprosjekt i samarbeid med Sunnaas Sykehus og

IBM, og vår del av applikasjonsutviklingen.

Vi går igjennom hva oppgaven er, utforming av kravspesifikasjonen, beskrivelse av

utviklingsprosessen, hvilke metoder, verktøy og teknologier som er brukt underveis

og hvordan selve applikasjonen er utviklet og dens funksjonaliteter.

Den siste delen av rapporten inneholder en oppsummering av prosessen etterfulgt

av en konklusjon.

Språket i rapporten er holdt til et middels teknisk nivå og vi benytter oss av tekniske

begreper. Enkelte begreper i rapporten er skrevet på engelsk siden disse var

vanskelige å oversette til norsk. Vi har valgt å legge ved en ordliste som inneholder

en kort forklaring på ulike begreper/ord som dukker opp underveis i rapporten.

Alle begreper/ord som er i fet skrift kan henvises til ordboken [Vedlegg Nr 3].

Selve systemet/løsningen vil bli referert som applikasjonen.

Ytterligere informasjon om prosjektet finnes på http://www.personaal-project.eu/

8

1.2 Innledning I Europa blir det stadig flere eldre mennesker, selv om denne demografiske trenden

betraktes som et positivt signal om bedre levekår, er det samtidig behov for å gi

tilstrekkelig støtte til et slikt økende antall eldre mennesker for å takle den økte

risikoen for å utvikle helse sykdommer senere i livet.

I tillegg har økt levetid kombinert med fallende fødselsrater fått mange til å bekymre

seg over kostnadene og bærekraften for å støtte denne voksende befolkningen av

eldre i kommende generasjoner.

I løpet av de siste årene har det vært en stor vekst i utviklingen og opptaket av ny

teknologi, særlig med hensyn til internettjenester, der bruk ofte er problematisk for

eldre mennesker.

Dette skyldes at eldre fortsatt står overfor problemer ved bruk av slike tjenester da

de kan lide av noen form for funksjonelle (midlertidige eller permanente)

begrensninger eller forringelser (syn, hørsel, motoriske og / eller kognitive evner)

som noen ganger gjør samspill med enheter utfordrende for eldre mennesker.

PersonAAL-prosjektet tar sikte på å forlenge tiden eldre mennesker kan leve i sitt

hjemmemiljø, ved å øke sin autonomi og hjelpe dem med å utføre daglige

livsaktiviteter ved hjelp av intelligente og intuitive webapplikasjoner.

Webapplikasjonene vil gjøre det mulig for brukerne å motta personlig og

kontekstsensitiv hjelp direkte i deres egne hjem, med målet om å forbedre

livskvaliteten og redusere helsetjenesters leveringskostnader.

Spesielt er målet med dette prosjektet å gi eldre nyttige og brukbare hjelpemidler for

bedre å styre deres livsstil. Slike hjelpemidler skal gi dem mulighet til å øke

bevisstheten og kontrollen av deres nåværende livsstil, ved å gi dem relevant og

skreddersydd informasjon på en intuitiv og naturlig måte.

Dette vil bli gjort gjennom utvikling av nye løsninger for tilgjengelige og

kontekstavhengige, personlige webapplikasjoner og for å forbedre omsorgen for

eldre.

9

I den forbindelse vil PersonAAL prosjektet gi utviklere et utviklingsmiljø som vil

inkludere tilgjengelighetsproblemer og design-for-all-prinsipper under

webapplikasjonsutvikling, og tilpasse eksisterende programmer til eldre brukere,

deres skiftende evner, deres miljø og enhets karakteristikker.

Videre vil prosjektet bruke dette til å forbedre og optimalisere tre eksisterende støtte

applikasjoner ved å legge til personaliserings teknologi, slik at disse applikasjonene

kan være mer effektive og bedre kan tilpasses eldres behov.

10

1.3 Involverte aktører

Student Gruppen

Elisabeth Kongshavn s194524

Huebert Miguiel Fabros s236358

Julian Refsland s236638

Veileder fra Høgskolen i Oslo & Akershus

Thor E Hasle

Oppdragsgiver

International Business Machines AS (IBM)

Kontaktperson fra IBM

Loek Vredenberg

Veiledere fra IBM

Roy Mitchley

Marek Franciszek Machnik

Millad Dagdoni

Juraj Piovar

Hege Furseth Hjertø

Ragne Nilsen Ribu

Karina Bjørnarøy

11

2 Prosessen

2.1 Oppgaven Vi har fått i oppgave av IBM å lage et system som støtter bedre overholdelse av

medisinske resepter.

2.2 Planlegging og metode

2.2.1 Kravspesifikasjonen

Kravspesifikasjonen [Vedlegg Nr 1] ble utformet i samråd med IBM, og inneholder en

liste over ønsket funksjonalitet, med forskjellige nivåer av prioritet.

Kravspesifikasjonen har spilt en viktig rolle for å sikre oss en smidig og målrettet

utviklingsprosess. Kravspesifikasjonen gjorde det tydelig hva som måtte være på

plass. De funksjonelle og ikke-funksjonelle kravene beskrevet i kravspesifikasjonen

har fungert som byggesteiner for å oppnå de overordnede kravene.

2.2.2 Endring i kravspesifikasjonen

Endringer har forekommet underveis i prosessen, siden det har vært funksjonaliteter

vi enten ikke har hatt tid til eller nok kunnskap til å implementere. Disse endringene

har vært i samråd med IBM.

Funksjonaliteten “Caregiver” som skulle benyttes av pårørende og/eller autorisert

helsepersonell, måtte endres på underveis.

Vi hadde ikke nok tid til å implementere denne funksjonaliteten, så IBM’s utviklere

skal ta seg av dette senere. Utviklingsleder mente vi heller burde prioritere og

fokusere på de andre funksjonelle kravene som ble satt.

I senere tid har vi derfor endret prioriteringsnivået på kravene som angår

“Caregivers” fra prioritets-nivå “Høy” til “Lav”.

12

2.3 Metoder, verktøy og teknologier Nedenfor følger en oversikt, samt beskrivelse av metoder, verktøy, hjelpemidler og

teknologier vi har benyttet oss av under gjennomføringen av prosjektet.

2.3.1 Design thinking

IBM har en metode som heter Design Thinking1. Denne metoden går ut på at

systemene i verden skal fungere i samhold med mennesker.

Design Thinking er et rammeverk som benyttes for å løse brukernes problemer med

hastigheten og omfanget av moderne teknologi.

Viktige kriterier innenfor Design Thinking er:

● “Hvordan kan vi bedre forstå brukerne våre?”

● “Hvordan leverer vi banebrytende løsninger som tilfredsstiller brukernes

behov?

IBM Design Thinking begynner med et sett av prinsipper som er kjernen til disse

spørsmålene. Prinsippene danner grunnlaget for å levere løsninger som oppfyller

eller overgår brukernes forventninger. For å lykkes må man kunne sette seg inn i

brukerens “sko” og prøve å tenke hva brukeren tenker, føler, ser etc.

1 IBM Design Thinking (2016). IBM Design Thinking. I IBM Design. Hentet 30. mars 2017 fra https://www.ibm.com/design/thinking/

13

Figur 0: IBM Design Thinking - My Essentials copyright IBM Corporation 2016

2.3.2 Smidig utvikling

Smidig utvikling2, også kalt agile utvikling, er en prosessmodell for

programvareutvikling som har blitt svært populært, og er godt innarbeidet hos mange

firmaer i program-utviklingsbransjen.

Det finnes flere forskjellige prosessmodeller innen smidig utvikling, hvor av de mest

kjente er Scrum, Kanban, og Extreme Programming.

Hovedpoenget med smidig utvikling er å tillate endringer i krav og funksjonalitet

underveis i utviklingsprosessen, uten å måtte forkaste store mengder arbeid og

gjennomføre prosessen på nytt.

Smidig utvikling hjelper teamet til å reagere på uforutsigbarheter gjennom

inkrementelle, iterasjoner og empirisk tilbakemelding. Smidig utvikling er et alternativ

til blant annet fossefallsmetoden. 2 The Agile Movement (2008). The Agile Movement. I Agile Methodology. Hentet 23. februar 2017 fra http://agilemethodology.org/

14

Alle i gruppen hadde god kjennskap til denne metoden fra faget “Systemutvikling”,

og ble enige med IBM om at “Scrum” var en god måte å organisere

utviklingsprosessen.

2.3.3 Scrum

Scrum3 er den mest populære måten å introdusere smidig utvikling, på grunn av sin

enkelhet og fleksibilitet.

Scrum legger vekt på empirisk tilbakemelding, team selvtillit, og streber etter å bygge

riktig testet produkt innen korte iterasjoner.

Man fordeler utviklingen i iterasjoner, eller sprinter, hvor innholdet i hver sprint blir

avtalt på et Scrum-møte der alle partene er til stede. Alle partene består av Scrum Master, Product Manager og utviklingsteamet.

Innholdet hentes fra prosjektets backlog, en liste over funksjonalitet som skal

implementeres for å nå målet, og legges i en sprint-backlog som representerer målet

for hver iterasjon. I tillegg til å definere målet for hver sprint, evaluerer man hva som

er gjort siden forrige møte, og hva som eventuelt hindrer effektiviteten til hvert enkelt

medlem ved implementering av funksjonalitet. Slik fortsetter utviklingen inkrementelt

helt til applikasjonen er ferdigstilt.

Scrum har totalt fem møter: Backlog grooming, sprint planning, daily scrum (ca 15

minutters oppstart), sprint review meeting og sprint retrospective meeting.

2.3.4 Hvorfor Scrum

IBM benytter seg av scrum til andre prosjekter, og det var naturlig for dem å benytte

seg av scrum til dette prosjektet.

Vi studenter har også benyttet oss av scrum tidligere så derfor ble vi enige med IBM

om å benytte oss av scrum i dette prosjektet også. I tillegg var vi færre enn åtte

personer under utviklingsperioden, og derfor passet scrum ypperlig for oss.

3 The Agile Movement (2008). The Agile Movement. I Agile Methodology. Hentet 23. februar 2017 fra http://agilemethodology.org/

15

En standard oppbygging av et prosjekt i IBM innebærer at man først benytter seg av

scrum, og deretter går over til kanban etter en gitt tidsperiode.

Kanban er en mer flytbasert utviklingsmetode der man fokuserer på at oppgaver skal

“flyte” uten avbrudd gjennom de nødvendige aktivitetene til de er ferdige.

Man definerer gjerne et sett med oppgaver eller “features” og leverer så snart man er

ferdig. Det er også mulighet for utviklere å kunne vente med oppgaver hvis det

optimaliserer overordnet flyt, samt mindre fokus på estimering.

Vi fikk ikke muligheten til å være med på overgangen fra scrum til kanban, da vi kun

deltok i oppstartsfasen til prosjektet.

2.3.5 Sprinter

Utviklingsperioden startet fra midten av februar og endte 4 mai 2017.

Vi valgte å avslutte utviklingsperioden på dette tidspunktet, for å kunne ferdigstille

dokumentasjonen.

I samarbeid med IBM bestemte vi oss for å benytte sprinter med 3 ukers varighet.

Ved bruk av 3 ukers sprinter hadde vi nok tid til å implementere ny funksjonalitet i

løsningen, som vi viste fram til IBM etter hver endte sprint.

2.3.6 Planlegging av sprint

Etter en endt sprint4 hadde vi et retrospective møte med IBM der vi viste frem hva vi

hadde fått til hittil, og deretter gikk vi igjennom backlog i plenum.

I en sprint har man gjerne et sett med user stories eller brukerhistorier.

Brukerhistorier konkretiseres i form av akseptansekriterier, som relativt entydig

brukes for å oppnå enighet mellom f. eks en kunde og en leverandør.

Utifra brukerhistoriene vi hadde, prøvde vi å estimere hvor lang tid hver

brukerhistorie ville ta å fullføre. Deretter valgte vi ut brukerhistorier basert på

viktighet for videre utvikling samt avgrensning der det var nødvendig i samråd med

utviklingsleder fra IBM.

4 The Agile Movement (2008). The Agile Movement. I Agile Methodology. Hentet 23. februar 2017 fra http://agilemethodology.org/

16

2.3.6.1 Sprint 0

Varighet: 13.02.2017 - 03.03.2017

1 Bygge en hybridapp/cordova app

2 Rammeverk og moduler for serverside skal settes opp.(Walking Skeleton for en microservice arkitektur)

3 Sette opp toolchain i Bluemix for komponenter som lages.

4 Toolchain bør inkludere bygg, statisk testing, unit testing og deploy til test server.

5 Lag en kalender microservice

2.3.6.2 Sprint 1 Varighet: 05.03.2017 - 23.03.2017

2566 Implement push notifications for reminders about taking medicine

2568 Set up authentication for patients and other roles

2576 Register taking my medicine in the web app

2578 Receive notification to take medicine

2590 Create two way communication with the database

2652 Create a reminder class, which will handle actions related to reminding the patient to take his/her medicine

2748 Update calendar table datamodel

2750 Create MS for Registration

2761 Change to calendar data model in database

2838 Logon to medication monitor application

2580 Create database and table to hold user profile

2987 Use authentication service for BFF

3218 Restructure web application to MEAN stack

3221 Mobile friendly web app (Bootstrap)

17

2.3.6.3 Sprint 2

Varighet: 24.03.2017 - 13.04.2017

2722 Send notification of medicine taken to PersonAAL context engine

2723 Medicine Monitor integration with PersonAAL adaptation engine services

2986 Authentication using local authentication service

3132 Create a Caregiver MS

3136 Create a new service in BFF/API connect for Patient MS which allows registration of new caregivers

3137 Create a new function in Patient MS which allows patients to give permission to a caretaker, to view and edit, medication plan and patient data

3138 Create a button in the user interface to press to access the patient profile and an event associated with it

3139 Create a function which sends a request for user data to BFF

3140 Parse the response, and display the user profile information to the user

3142 Create a new function in Patient MS which fetches user profile information from the database

3144 Create a function which shows notification when it is time to take medicine

3141 Create a new service in BFF/API connect for getting user profile information

3145 Create “Ja”, “Nei”, “Vet ikke” buttons, to be showed after the user has clicked on the notification

3146 Create a function that send the medication data taken to the BFF

3223 Spike push notification using cordova

2.3.6.4 Sprint 3

Varighet: 14.04.2017 - 04.05.2017

2571 As a patient I wish to view my patient profile

2988 As a patient I wish to be able to give caregivers permission to my medication plan and patient data

2984 Merge gui and backend code to BFF

18

2989 As a caregiver I should see all users I have been given the role caregiver for

3222 Use SWAGGER on backend services

3422 Implement Passport to request authentication and protect API endpoints

2.3.7 Vår erfaring med Scrum

Scrum har fungert godt gjennom vår utviklingsprosess. Å jobbe med en backlog har

gitt oss en god oversikt, og å jobbe med sprinter har gitt oss gode rammer.

Hovedgrunnen til dette er at vi hadde svært kort tid til å drive utvikling.

Kravspesifikasjonen ble endret underveis, da IBM endret prioriteringer og fant andre

løsninger underveis for deler av funksjonaliteten.

Vi kunne spart mer tid hvis kravspesifikasjonen krevde små endringer, men det er en

utfordring å få til, da det er flere aktører involvert i dette prosjektet.

I slutten av hver sprint benyttet vi oss av en time med retrospektiv, hvor alle i teamet

skrev ned en lapp om hva som fungerte bra, hva som kunne forbedres og alle hadde

muligheten til å stille spørsmål.

Ved å benytte seg av retrospektiv tok vi lærdom av hver sprint og forbedret

forskjellige aspekter ved neste sprint.

Dette kunne for eksempel være estimering av tid angående hver oppgave, og hvilke

oppgave som ble flaskehalser for prosjektet.

I tillegg fikk vi også konstruktiv kritikk og positiv feedback tilbake fra IBM etter å ha

vist frem applikasjonen etter hver sprint, slik at vi kunne forbedre disse punktene.

Dermed kunne vi forbedre utviklingsprosessen vår, men siden vi benyttet oss av 3

ukers sprinter førte dette til at det ble for få sprinter, og gruppen mener at vi kunne

ha fått et større læringsutbytte ved å ha flere korte sprinter.

Teamet bestod av oss studentene og ansatte fra IBM. Til tider har veiledere fra IBM

vært svært opptatte med andre oppgaver.

19

2.4 Verktøy

2.4.1 Box Note

Box Note5 gjør det enklere å opprette notater, dele ideer, følge opp

statusoppdateringer og planlegger prosjekter sammen.

IBM opprettet et Box Note som ble delt med oss der det ble delt informasjon

angående prosjektet, applikasjonen, metoder, inspirasjon og fremdriftsplan.

Box Note ble også brukt til ha en oversikt over brukerhistoriene som er knyttet til

prosjektet.

2.4.2 Git/Github

Git6 er et versjonshåndteringssystem for utvikling av programvare, som forenkler

prosessen ved å dele tillegg og endringer i programkoden.

Dette er et helt essensielt hjelpemiddel i prosjekter med flere utviklere, og mange

filer.

Git organiserer et prosjekt i et repository som hver av de involverte utviklerne i

prosjektet kan skrive eller lese fra. Fremgangsmåten for synkronisering av arbeid

består av å legge til endrede filer i en commit, som man igjen legger inn i

repositoriet. Når en skal hente ned nyeste versjon av koden, henter man ved bruk av

Git.

Om det er registrert flere endringer i en enkelt fil, vil Git gjøre sitt beste for å

sammenflette disse automatisk, eller instruere brukeren om å gjøre det. På denne

måten har alle involverte i prosjektet mulighet til å synkronisere kode mellom

hverandre på en effektiv og sikker måte. Man har også tilgang til komplett historikk

for prosjektet, ettersom alle commits er indeksert etter en unik SHA1-hash sum.

Git gir også muligheten til å reversere tilbake til en fungerende versjon dersom man

skulle havne i en situasjon hvor det er fordelaktig.

5 Box Notes (u.å.). Box Notes. I Box. Hentet 29. mars 2017 fra https://www.box.com/en-gb/notes 6 Github (2017). Github. I Github. Hentet 21. februar 2017 fra https://github.com/

20

Vi benyttet oss av Github under “Sprint 0” og halvveis i “Sprint 1” for applikasjonen

før vi byttet over til IBM JazzHub.

2.4.3 Facebook

Facebook7 er et populært sosialt medium som lar brukere opprette profiler, laste opp

bilder og videoer, sende meldinger via chat funksjonen og holde kontakt med

venner, familie og kollegaer.

Vi har benyttet oss av chat funksjonen for kommunikasjon mellom oss i gruppen. Her

har vi blant annet avtalt møtetidspunkter, delt linker til nettsteder, og andre generelle

kommunikasjonsbehov som oppsto underveis i prosessen.

2.4.4 Slack

Slack8 er et cloud-basert team samarbeidsverktøy der brukere kan opprette teams til

å bli med gjennom en spesifikk lenke eller invitasjon som er sendt av administrator

av teamet.

Utviklingsleder opprettet et eget team som ble kalt for “IBM PersonAAL Project”, og

der kommuniserte vi med hverandre.

I tillegg ble det opprettet ulike kanaler for å diskutere emner relatert til sin kanal.

F.eks i #stand-up kanalen fikk man beskjed om når stand-up skulle skje, og i

#technical kanalen kunne man stille spørsmål om eventuelle råd eller utfordringer og

så videre.

2.4.5 Google Drive

Google Drive9 er en skylagringstjeneste som Google har utviklet for filer og

dokumenter med funksjonalitet for tekstredigering i sanntid.

Google Drive ble brukt til å ha strukturert ordning på alle dokumentene våre for selve

prosjektet.

7 Facebook (2017). Facebook. I Facebook. Hentet 01. januar 2017 fra https://www.facebook.com/ 8 Slack (u.å.). Slack. I Slack. Hentet 3. februar 2017 fra https://slack.com/ 9 Google Drive (2017). Google Drive. I Google. Hentet 10. oktober 2016 fra https://www.google.com/drive/

21

2.4.6 IBM Bluemix DevOps Services

IBM Bluemix DevOps Services10 er et software as a service i Bluemix som støtter

kontinuerlig levering. Her kan man utvikle, følge, planlegge og deploye programvare

på et sted.

I tillegg har man muligheten til å koble seg til JazzHub, som er tilnærmet lik GitHub.

For teamutvikling kan man opprette en “track & plan”, det vil si at man lager en

tidslinje for prosjektet man oppretter, planlegger sprinter og legger inne

brukerhistorier.

2.4.7 IBM Bluemix Git

IBM Bluemix Git11 er IBM sitt eget Git og fungerer på samme måte som Github/Git.

Dette ble tatt i bruk fra 5 april for videre deployment.

Figur 1: Skjermdump av Track & Plan for PersonAAL prosjektet.

10 Hub Jazz (u.å.). Hub Jazz. I IBM Bluemix DevOps Services. Hentet 05. april 2017 fra https://hub.jazz.net/ 11 IBM Bluemix (u.å.). IBM Bluemix. I IBM. Hentet 5. april 2017 fra https://git.ng.bluemix.net/

22

2.4.8 Cloudant Dashboard

Cloudant Dashboard12 er et verktøy som blir brukt til å administrere Cloudant

Databasen, gjennom denne webapplikasjonen kan man lage, endre og slette

databaser. I tillegg kan man se hvilke dokumenter som er lagret i databasen

gjennom en query eller å gå direkte inn å se på de ulike dokumentene. Videre kan

man administrere hvem som har tilgang til hvilke databaser samt overvåke hvor mye

trafikk databasen har.

2.4.9 IntelliJ IDEA

IntelliJ IDEA13 er et IDE (Integrated development environment) for utvikling av

programvare. Det ble utviklet av JetBrains, tidligere kjent som IntelliJ.

IntelliJ har innebygget støtte for versjonshåndtering med blant annet Git. I tillegg

finnes innebygget funksjonalitet for plugins, slik at man for eksempel kan håndtere

databaser direkte i utviklingsmiljøet.

2.4.10 Visual Studio Code

Visual Studio Code14 er en koderedigeringsprogram som er optimalisert for å bygge

og feilsøke moderne web og sky applikasjoner. Redigereren kombinerer enkelheten

til en kode redigerer med kraftige utviklingsverktøy og programvare utvidelser.

2.4.11 yEd

yEd15 er et kraftig skrivebordsprogram som kan brukes til å lage diagrammer som

flytdiagrammer, UML, nettverk diagrammer og mye mer.

Man kan enten lage diagrammer manuelt, eller importerte eksterne data til analyse

og generere et diagram av det.

12 Holt, S (2016). What is a cloud database?. I IBM Cloud. Hentet 13. mai fra https://www.ibm.com/cloud-computing/learn-more/what-is-cloud-database/ 13 Enjoy Productive Java (u.å.). Enjoy Productive Java. I IntelliJ IDEA. Hentet 17. februar 2017 fra https://www.jetbrains.com/idea/ 14 Visual Studio Code (2017). Visual Studio Code. I Microsoft. Hentet 17. februar 2017 fra https://code.visualstudio.com/ 15 yEd Graph Editor (2017). yEd Graph Editor. I yWorks. Hentet 19. mai 2017 fra https://www.yworks.com/products/yed

23

2.4.12 Visual Paradigm

Visual Paradigm16 er et UML case-verktøy som støtter UML 2, System modelling

language process modelling notation fra Object Management Group.

I tillegg til modellerings støtte, gir den rapportgenerering og kodeverks teknikk

inkludert kodegenerering.

16 Visual Paradigm(u.å.). Visual Paradigm. I Visual Paradigm. Hentet 19. mai 2017 fra https://www.visual-paradigm.com/download/

24

2.5 Teknologier

2.5.1 Node.js

Node.js17 er et åpent kryssplattform runtime-system for server og

nettverksapplikasjoner.

Node.js eksekverer JavaScript kode ved hjelp av Google V8-motoren, slik at

JavaScript-programmer kan kjøre på servere.

2.5.2 Angular 2

Angular 218 er et TypeScript basert open-source frontend webapplikasjon

rammeverk. Angular 2 belager seg i større grad på standard JavaScript, noe som

gjør at rammeverket er lettere å ta i bruk.

Senere ut i prosjektet benyttet vi oss av Angular 4, da dette var den nyeste

versjonen.

2.5.3 Express.js

Express.js19 er et Javascript rammeverk basert på Node.js-plattformen. Express

brukes til utvikling av serverside-programvare. Express.js utgjør sammen med

MongoDB, AngularJs og Node.js det man kaller MEAN-stack.

2.5.4 IBM Bluemix Cloudant NoSQL Database

Cloudant20 er et fullt administrert datalag laget for moderne mobil og

webapplikasjoner som utnytter et fleksibelt JSON-skjema. Cloudant er bygget på og

er kompatibelt med Apache CouchDB og tilgjengelig gjennom en sikker HTTP API, som skalerer når applikasjonen blir større.

17 Node.js(2017). Node.js. I Node.js. Hentet 13. februar 2017 fra https://nodejs.org/en/ 18 Angular2(u.å.). Angular2. I Angular2. Hentet 13. februar 2017 fra http://www.angular2.com/ 19 Express(2016). Express. I Node.js. Hentet 13. februar 2017 fra https://expressjs.com/ 20 Cloudant NoSQL DB(2017). Cloudant NoSQL DB. I IBM Bluemix. Hentet 13. februar 2017 fra https://console.ng.bluemix.net/catalog/services/cloudant-nosql-db

25

2.5.5 JavaScript

JavaScript21 et et høynivå-programmeringsspråk og sammen med HTML og CSS er

det en av grunnsteinene i moderne webutvikling.

JavaScript er et tolket språk med støtte for både prototype basert objektorientering

og funksjonell programmering.

2.5.6 TypeScript

TypeScript22 er et språk for JavaScript og legger til valgfrie typer, klasser og moduler

til JavaScript. Det støtter verktøy for store JavaScript-applikasjoner for alle nettlesere

på alle operativsystemer, i tillegg til å kompilerer til lesbar, standardbasert JavaScript

2.5.7 MEAN-Stack

Ved å kombinere Express, Angular og Node.js, og en NoSQL database som for

eksempel MongoDB, så ender man opp med et utviklingsmiljø basert 100% på

JavaScript.

Kombinasjonen av disse teknologiene kalles for MEAN-Stack23.

Men i dette tilfellet hadde vi ingen MongoDB, men IBM Cloudant NoSQL database

som fungerer på samme måte som MongoDB.

2.5.8 HTML5

Hypertext Markup Language24 (HTML5) er et markeringsspråk som er brukt til å

strukturere nettsider, og er en av grunnsteinene i teknologien for World Wide Web.

Vi har valgt å bruke HTML5, fordi de fleste nettlesere støtter det, og i 2014 ble

spesifikasjon prosessen for HTML5 ferdig av W3C (World Wide Web Consortium).

21 JavaScript(u.å.). JavaScript. I Code School. Hentet 13.februar 2017 fra https://www.javascript.com/ 22 Typescript(u.å.). Typescript. I NPM. Hentet 13. februar 2017 fra https://www.npmjs.com/package/typescript 23 Mean(2014). Mean. I MEAN.IO. Hentet 13. februar 2017 fra http://mean.io/ 24 HTML(2017). HTML. I MDN. Hentet 09. mai 2017 fra https://developer.mozilla.org/en-US/docs/Web/HTML

26

2.5.9 Bootstrap 4

Bootstrap25 er et open-source frontend web rammeverk for å designe websider og

webapplikasjoner. Bootstrap inneholder HTML og CSS baserte design-maler for

typografi, skjemaer, knapper, navigasjon og andre brukergrensesnitt komponenter.

Bootstrap er essensielt for å kunne oppnå et responsivt design.

2.5.10 Cascading Style Sheets 3

Cascading Style Sheets (CSS)26 er et språk som brukes til å definere utseendet på

filer skrevet i HTMl eller XML. CSS er gjennomgående stilark som gjerne inneholder

oppsett, farger, og annen stilinformasjon. Stilarkene kan integreres i selve

dokumentet eller skilles ut som en egen fil med endelsen .css. Et ubegrenset antall

dokumenter kan peke til og styres av samme .css-fil, noe som er styrken i CSS. Ved

å endre på en fil, kan man endre fargebruk, bakgrunnsbilder osv. i alle dokumenter

som peker til CSS-filen.

2.5.11 ECMAScript 2015

ECMAScript 2015 er en standard for skriptspråk, også kjent som ECMAScript 627

eller ES6. ES6 er ikke støttet vanligvis i nettlesere og krever derfor kilde-til-kilde

kompilator(source-to-source compiler eller transpiler) for å fungere, og i dette

tilfellet ble Babel.js kompilatoren.

Fordelen med ES6, er at man får tilgang til en rekke nye funksjoner som ikke er

tilgjengelig i ECMAScript 5.

Funksjoner man kan benytte seg av er blant annet arrow functions og promises.

25 Bootstrap(u.å.). Bootstrap. I Bootstrap. Hentet 13. februar 2017 fra http://getbootstrap.com/ 26 CSS Tutorial(2017). CSS Tutorial. I w3schools. Hentet 09. mai 2017 fra https://www.w3schools.com/css/ 27 Standard ECMA-262(2016). Standard ECMA-262. I ECMA Standards. Hentet 09. mai 2017 fra https://www.ecma-international.org/publications/standards/Ecma-262.htm

27

2.5.12 Babel.js

Babel.js28 er en JavaScript kompilator som oversetter ECMAScript 2015 kode til

nettleser kompatibel ECMAScript 5 kode.

2.5.13 Passport.js

Passport.js29 er et sikkerhetsrammeverk som brukes til å beskytte Web API endepunkter, og for å gi sessions til brukere samt autentisering for Node.js.

Passport er ekstremt fleksibel og modulær, og kan diskret slippes inn i Express-

baserte webapplikasjoner.

2.5.14 Web API

Web API30 er en API over nettet som kan nås ved hjelp av HTTP-protokollen. Man

kan bygge Web API ved hjelp av ulike teknologier som Java, .NET o.l.

28 Babel is a JavaScript compiler(u.å.). Babel is a JavaScript compiler. I Babel. Hentet 09. mai 2017 fra https://babeljs.io/ 29 Hanson, J.(u.å.). Documentation. I Passport.js. Hentet 19. mai 2017 fra http://passportjs.org/docs 30 Chauhan, S.(2016). What is Web API and why to use it?. I DotNetTricks. Hentet 19. mai 2017 fra http://www.dotnettricks.com/learn/webapi/what-is-web-api-and-why-to-use-it-

28

2.6 Fremdriftsplan

2.6.1 Fremdriftsplan

I startfasen hadde IBM allerede laget en fremdriftsplan [Vedlegg Nr 2] som inkluderte

oss. Vi valgte derfor å følge denne i samråd med IBM.

Fremdriftsplanen viser milepæler og tidsfrister som skal forholdes til underveis i

prosjektet.

Etter anbefaling fra IBM satt vi oss som mål å være ferdig med programmering av

applikasjonen den 4. mai, for å frigjøre tid den siste måneden til å fullføre

dokumentasjonen.

2.6.2 Prioriteringsliste

Kravspesifikasjonen [Vedlegg Nr 1 ] ble utformet i samråd med IBM, og inneholder

en liste over ønsket funksjonalitet, med forskjellige nivåer av prioritet.

Detaljert beskrivelse av funksjoner som funksjonelle og ikke-funksjonelle krav og

prioriteringsnivå er spesifisert i denne.

29

3 Universell utforming Begrepet universell utforming brukes ofte synonymt med “design for alle”.

Med universell utforming menes utforming eller tilrettelegging av hovedløsningen i de

fysiske forholdene, herunder informasjons- og kommunikasjonsteknologi (IKT), slik

at virksomhetens alminnelige funksjon kan benyttes av flest mulige.

For dette prosjektet har universell utforming måttet være en ganske sentral metode,

siden applikasjonen i første omgang er rettet mot eldre.

Applikasjonen blir da også mer brukervennlig slik at det i liten grad skulle være

behov for spesialløsninger ved siden av.

På denne måten oppnår vi:

● Færre løsninger å utvikle og vedlikeholde

● Få eller ingen spesialløsninger for funksjonshemmede

● Løsninger som er enkle og bedre for alle

● Flere måter å bruke løsningen på

● Mulighet for at enda flere kan bruke løsningen

Det har vært ekstremt viktig at applikasjonen skal være responsiv.

Det betyr at applikasjonen skal kunne bli brukt effektivt, være enkel og man skal ha

muligheten til å kjøre applikasjonen fra hvilken som helst enhet.

Da er det viktig at man følger prinsippene for universell utforming, slik at man har en

oversikt over hvem som er brukeren.

En av huskereglene er å tenke at innholdet er som vann. Hvordan vil innholdet bli

seende ut på forskjellige enheter?

30

Figur 2: Content is like water31

3.1 Responsive versus Adaptive Web Design

Responsivt og tilpasset web design utfyller hverandre, så her må man la selve

innholdet bestemme.

3.2 Flyten

Når skjermstørrelsen blir mindre, begynner innholdet å ta opp mer vertikal plass og

noe innhold vil bli presset nedover.

Figur 3: Flyt vs Statisk

31 Walter, S.(2013). Content is like Water. I Stephanie Walter. Hentet 16. mai 2017 fra https://www.stephaniewalter.fr/portfolio/content-is-like-water-illustration/

31

3.3 Relative Enheter

Lerretet som kan benyttes kan være desktop, mobil skjerm, ipad eller alt i mellom.

Pixlene sin tetthet kan også variere, og det fører til at man trenger enheter som er

fleksible og fungerer overalt. Det er der relative enheter kommer til nytte. Fremfor å

benytte seg av pixler, så kan man heller benytte seg av prosenter. Hvis man setter

innholdets størrelse til 500 pixler, vil det alltid være 500 pixler uansett størrelse på

enheten. Mens hvis man setter størrelsen til 50%, så vil bakgrunnsbilde alltid følge

enhetens størrelse.

Figur 4: Relative enheter vs Statiske enheter

32

3.4 Bruddpunkt

Bruddpunkt gjør at layouten kan endres på forhåndsdefinerte punkter, med andre

ord kan man ha 3 kolonner på desktop, men bare ha 1 kolonne på en mobil enhet.

Med CSS kan man endre endre et bruddpunkt til et annet. Hvis en setning bryter på

en mobil enhet må man legge til et bruddpunkt

Figur 5: Med og uten bruddpunkt

3.5 Max og Min verdier

Noen ganger er det flott at innholdet tar opp hele bredden på en skjerm, som på en

mobil enhet, men å ha det samme innholdet som strekker seg til hele bredden på

TV-skjermen, gir ofte mindre mening. Derfor hjelper Min / Max verdier. For eksempel

å ha bredde på 100% og maks bredde på 1000px ville bety at innholdet vil fylle

skjermen, men ikke gå over 1000px.

33

3.6 Nested objects

Hvis man har mange elementer som er avhengig av hverandre, kan det bli vanskelig

å kontrollere. Derfor blir det enklere å pakke alt inn i containere, da blir det lettere å

holde orden samt at det er mer rent og ryddig.

Statiske enheter som pixler er nyttig for innhold som ikke skaleres, dette kan være

logoer og knapper.

Figur 6: Nested and not nested

34

3.7 Mobile or Desktop first

Teknisk er det ikke mye forskjell hvis et prosjekt startes fra en mindre skjerm(mobile

first) til en større(desktop first) eller motsatt.

I de fleste tilfeller vil en utvikler benytte seg av både mobile first og desktop first, men

det er opp til utvikler å bestemme hva som egner seg best.

Figur 7: Desktop first, mobile first

35

3.8 Webfonts versus System fonts

Selv om webfonts kan lages selv, eller hentes fra nettet og gi applikasjonen flott

uttrykk på teksten, betyr det ikke at det er effektivt. Hver webfont som blir lastet ned

og tatt i bruk vil sluke opp nedlastingstiden for applikasjonen.

System fonts er derimot raske, men hvis brukeren ikke har den lokalt, vil teksten falle

tilbake til en standard skrifttype.

Figur 8: Systemfonts vs Webfonts

3.9 Bitmap bilder versus Vektorer

Bitmaps bruker bildeformatet jpg, png eller gif mens vektorer bruker SVG eller en

type ikon skrift.

Hver av dem har fordeler og ulemper, og man bør være oppmerksom på størrelsen.

Ingen bilder skal gå online uten optimalisering.

Vektorer er som regel ganske små, og på noen eldre nettlesere støttes det ikke

vektorer.

Hvis bildet har mange kurver, vil vektorer være tyngre enn en bitmap. Så her må

man tenke seg nøye igjennom hva som egner seg best.

36

Figur 9: Forskjellen på Bitmap og Vector

3.10 WCAG 2.0

WCAG 2.032 (Web Content Accessibility Guidelines) er web, innhold,

tilgjengelighet(funksjonshemmede) og retningslinjer.

WCAG 2.0 gjelder stort sett for mer avanserte teknologier, er enklere å bruke og

forstå. I tillegg er den mer nøyaktig når det kommer til automatisert testing og

menneskelig evaluering.

Den følger 4 prinsipper, 12 retningslinjer og 61 suksesskriterier.

De 4 prinsippene som danner grunnlaget for tilgjengelighet på nett er:

3.10.2 Mulig å oppfatte

● Tekstalternativer: Gi tekstalternativer til alt ikke-tekstlig innhold

● Tidsbaserte medier: Gi alternativer til tidsbaserte medier

● Mulig å tilpasse

● Mulig å skille fra hverandre

3.10.3 Mulig å betjene

● Tilgjengelig med tastatur

● Nok tid

● Anfall

● Navigerbar

32 Henry, S.(2017). Web Content Accessibility Guidelines (WCAG) Overview. I W3. Hentet 19. mai 2017 fra https://www.w3.org/WAI/intro/wcag

37

3.10.4 Forståelig

● Leselig

● Forutsigbar

● Inndatahjelp

3.10.5 Robust

● Kompatibel

Etter utviklingen testet vi applikasjonen med en WCAG 2.0 checker for å se om applikasjonen følger retningslinjer for tilgjengelig webinnhold.

Det ser ut til at applikasjonen følger WCAG 2.0. “Potential risks” er problemene som

WCAG checker ikke kan identifisere, og trenger derfor en menneskelige beslutning.

Vi har gjennomgått disse potensielle problemene, og kom frem til at de beskrevne problemene ikke er tilstede.

WCAG checker som ble brukt: https://achecker.ca/checker/index.php

Figur 10: Output fra WCAG 2.0 checker.

38

Figur 11: Desktop av PersonAAL fra Sprint 2 - Responsivt

Figur 12: iPhone 6 plus av PersonAAL fra Sprint 2 - Responsivt

39

4 Utviklingsprosessen I denne delen tar vi for oss hvordan det har vært å utvikle applikasjonen i kronologisk

rekkefølge.

4.1 Startfasen

Helt i starten av prosessen brukte vi en del tid på finne ut hvilken bedrift vi kunne

skrive bacheloroppgave hos.

I denne perioden før vårt første møte med oppdragsgiver hadde vi “et hopp”

gjennom flere personer før vi kom i kontakt med Loek Vredenberg i IBM.

Vi fikk positivt svar fra Loek Vredenberg fra IBM og begynte å avtale vårt første

møte.

Fredag 11 November 2017 hadde vi vårt første møte med Loek, som da ble vår

kontaktperson fra IBM frem til en eventuell operasjonell ansvarlig for våre oppgaver

ble tildelt etter at alle detaljene var på plass.

Sammen med Loek kom vi fram til 2 planer som kunne definere en “bachelor

oppgave”:

Plan A: Bidra inn i forskningsprosjektet som er på trappene hvor dere skal inngå i

prosjektteamet fra IBM og får tildelt relevante utviklingsoppgaver ift deres mål.

Beslutning på IBM sin side for å gå for dette prosjektet vil ta noen uker før det er

formalisert.

Plan B: Alternativt skal vi definere et internt prosjekt som dere skal kjøre sammen

med noen utvalgte personer fra IBM. Her skal det da utvikles en løsning basert på

IBM Bluemix PAAS skybaserte plattform. Løsning og formål til et internt prosjekt skal

nærmere defineres i samarbeid med dere, dersom Plan A ikke blir virkeliggjort.

Etter å ha snakket med bachelor ansvarlig for IKT, Tor Krattebøl ved Høgskolen i

Oslo og Akershus, ga han oss tommel opp for Plan A.

Loek Vredenberg fikk beskjed om at Plan A var godkjent som bacheloroppgave, og

vi diskuterte videre når neste møte ville ta sted.

40

IBM hadde noen formaliteter som måtte ferdigstilles før vi endelig fikk svar på når, så

det ble ikke noe møte før 17 januar 2017.

På neste møte med Loek fra IBM, var også to representanter fra IBM til stede. Vi fikk

en gjennomgang av informasjon angående prosjektet og veien videre.

I senere tid fikk vi e-post fra prosjektleder om vi kunne delta på et møte 10 februar

2017 for å gå igjennom prosjektplan, metodeverk, IBM bluemix og annet.

Etter dette møtet var utviklingsprosessen vår ordentlig i gang, men i første omgang

var det usikkert hva som skulle lages.

4.2 Research

I startfasen var planen å prøve ut ulike teknologier før vi tok en endelig beslutning

om hvilke teknologier som skulle brukes videre i prosjektet.

Teamet hadde ikke fått et komplett bilde over hva de andre aktørene i PersonAAL

prosjektet hadde blitt enige om.

Dette førte til at vi tok oss friheten til å finne ut av hvilke teknologier som egnet seg

best til vår problemstilling.

41

4.3 Sprinter

4.3.1 Sprint 0

Varighet: 13.03.2017 - 03.03.2017 Ved start av sprint 0 var teamet bestående av oss og en veileder fra IBM, med

utviklingsleder i spissen.

I første omgang skulle vi bli kjent med nye teknologier og utvikle en hybrid mobil app.

Utviklingsleder foreslo å bruke Node.js, Express.js, IBM Cloudant NoSQL database

og bruk av microservice arkitektur på backend.

Microservices arkitekturstil er en utvikling av SOA (Services Oriented Architecture)

arkitekturstil. Programmer bygget med SOA-tjenester pleier å være fokusert på

tekniske integrasjonsproblemer, og nivået på de implementerte tjenestene er ofte

Sine-grained tekniske APIer.

Microservices er mange diskrete, nettverkstilkoblet komponenter.

Ved bruk av komponenter i applikasjonen vil det bli enklere å videreutvikle løsningen

i senere tid. Man har nemlig muligheten til å fjerne enkelt komponenter fra

applikasjonen uten å måtte endre noe særlig mer, og derfor vil ikke applikasjonen ta

noe “skade” av dette.

42

Figur 13: IBM Microservice Architecture33

På frontend derimot ble det foreslått å bruke Apache Cordova og Ionic for å bygge

hybrid appen.

Tanken bak å benytte seg av denne teknologien var at det skulle være enklere å

utvikle mobilapper for både iOS og Android fremfor å måtte utvikle to helt forskjellige

løsninger, og dermed spare mye tid.

Tidlig i sprinten oppdaget vi at det var litt for mange brukerhistorier og at

tidsestimeringen av oppgavene var feilvurdert, vi hadde en diskusjon med

utviklingsleder om hva som egentlig burde prioriteres.

15 - 17 februar 2017 var prosjektleder sammen med utviklingsleder i Pisa, Italia,

angående PersonAAL prosjektet, og påfølgende uke ble oppgaven om å utvikle en

33 Interactive Diagram(u.å.). Interactive Diagram. I IBM. Hentet 03. mars 2017 fra https://www.ibm.com/devops/method/content/architecture/omnichannelArchitecture

43

hybrid app forkastet da PersonAAL plattformen forutsetter at man tar i bruk en

webapplikasjon.

Microservice arkitektur og IBM’s cloudant databasen skulle fortsatt være tilstede i

løsningen, dermed ble ikke brukerhistoriene knyttet til microservices og cloudant

forkastet.

Dette var selvfølgelig litt demotiverende, men vi innså at slike endringer kunne

foregå ofte innen utvikling, da forandringer kan forekomme hele tiden.

Vi måtte da vurdere hvilke editor vi skulle bruke for programmeringsdelen, og det

endte med at medlemmene brukte hver sin editor, IntelliJ og Visual Studio Code.

I tillegg ble det opprettet et GitHub repository for å kunne oppdatere og dele kode.

Nå var det bare å sette seg inn i Node.js og Angular 2, og i første omgang hadde vi

en del problemer med å kjøre applikasjonen da vi ofte hadde problemer med Node.js

sitt library.

Vi hadde heller ikke noe særlig kjennskap til Angular 2, og måtte i første omgang

prøve oss frem og benytte oss av mye dokumentasjon fra Angular 2 sin offisielle

webside.

Brukergrensesnittet ble utviklet i denne sprinten. Det hadde kun funksjonalitetene

registrering og login. “Min profil” ble også utviklet, der man fra “Login” ble

videresendt til “Min profil” hvis innlogging er vellykket.

Vår første demo for IBM ble holdt torsdag 3 mars, og sprint 0 ble avsluttet.

Responsen fra IBM sin side var positiv, selv om det ikke var mye å vise i første

omgang.

Etter demoen ble det gjort en retrospective, og planlegging av neste sprint.

44

4.3.2 Sprint 1

Varighet: 06.03.2017 - 23.03.2017 Underveis i sprint 1 syntes vi at det ble ganske tungvint å få applikasjonen til å kjøre

da applikasjonen kjørte på Node.js sin server.js.

Hver gang vi skulle teste om ny kode fungerte måtte vi skrive “npm start” i

kommandolinjen, og da skal alle modulene bygges før man kan kjøre applikasjonen

lokalt.

Dette tok mye tid, og førte til at vi valgte å konvertere prosjektet vårt til et Angular Cli

prosjekt.

Ved å benytte oss av Angular Cli fikk vi bygget alle modulene raskere. Cli bygger

serveren med Node, og oppdaterer nettleseren hver gang man endrer eller legger til

kode og lagrer prosjektet. Denne endringen førte til at vi enkelt kunne se endringer

og nye moduler mer effektivt.

På web API fortsatte arbeidet med å implementere kalender-microservice.

Kalender datamodellen knyttet til brukerhistoriene 2761 ble oppdatert etter en

diskusjon innad i gruppen, og da måtte kalender microservices også gå gjennom en

oppdatering.

Siden NoSQL var veldig ferskt for de fleste i gruppen, førte det til at vi hadde behov

for flere iterasjoner av datamodellen før den kunne ansees som komplett.

I løpet av denne sprinten ble det også utviklet en ny microservice (brukerhistorie

2839), som skulle ha ansvaret for å registrere om en bruker hadde registrert at

brukeren hadde tatt medisinen sin.

For at de andre aktørene i PersonAAL prosjektet skulle få tilgang til disse dataene,

måtte vi gjøre det mulig i senere tid å integrere vår løsning med resten av

PersonAAL prosjektet.

For å kunne oppnå tilgang på data, måtte vi dermed finne en god måte til å få sendt

disse dataene.

En mulighet var å benytte seg av IBM OpenWhisk siden det ga muligheten til å gjøre

"noe når det skjedde endring i databasen."

Brukerhistoriene 2722 ble flyttet til neste sprint grunnet manglende tid.

45

Vi hadde en del problemer med å få hentet ut data fra kalender-microservicen i

første omgang, og brukte en del tid på å løse dette, men fant løsningen til slutt.

Etter å ha endelig programmert medisin-komponentene, kunne vi teste ut kalender-

microservicen for å hente ut data fra medisin-databasen.

I løpet av denne sprinten fikk også brukergrensesnittet et skikkelig boost. Bootstrap

ble tatt i bruk for å gjøre brukergrensesnittet mer delikat og responsivt slik at

webapplikasjonen responderte noenlunde likt utseendemessig på ulike plattformer

som mobiltelefon og tablets.

Eksperimentering av Cascading Style Sheets for å forbedre og optimalisere

brukergrensesnittet til webapplikasjonen ga det et skikkelig boost, og i første

omgang forholdt vi oss til gråtoner når det gjaldt fargevalg.

Figur 14: Skjermdump fra Medisinliste i webapplikasjonen

Tre av brukerhistoriene tilknyttet Sprint 1 gjaldt “push notifications”, eller rettere sagt

varsling/påminnelse.

For å kunne ta i bruk push notifications måtte vi ta i bruk et av Angular 2’s plugins

“angular2-notification”.

46

Det var en del problemer med å implementere push notifications, da vi ikke hadde

noe kjennskap til hvordan vi skulle koble push notifications til en bestemt medisin fra

databasen, slik at den gitte push-notification kun gjaldt den medisinen eksplisitt.

Dermed ble brukerhistoriene 2566, 2578 og 2652 satt på vent frem til sprint 3.

Ca midt i sprinten fikk vi tilbud om delta på workshop som skulle bli holdt ved Aker

Sykehus 24 mars 2017. Der vi skulle delta i IBM Design Thinking for å kunne komme

dypere inn på brukeren, og fortelle hva prosjektet gikk ut på og få tilbakemeldinger

fra de potensielle brukerne av webapplikasjonen.

Vi så veldig frem til dette og læringsutbytte vi ville oppnå fra denne workshopen.

23 mars 2017 var det duket for ny demo, der vi viste frem hvilke funksjonaliteter vi

hadde utviklet ut ifra brukerhistoriene for denne sprinten. Disse funksjonene var

“login”, “registrering av bruker” via en falsk backend generert av Angular, liste over

medisiner og notifications.

Notifications delen var krevende da vi på daværende tidspunkt hadde lite kjennskap

og kunnskap til hvordan man skulle/burde implementert denne funksjonen.

På daværende tidspunkt stilte vi en gitt tid, som ville da gi et signal til funksjonen og

man fikk en varsel på det tidspunktet som var gitt.

Etter demonstrasjonen utførte en retrospective der vi gikk igjennom følgende

punkter:

● Hva gjorde vi bra?

● Hva likte vi mindre/Hva gikk dårlig?

● Hva bør forbedres?

47

Figur 15: “Hva gikk bra?” fra retrospective meeting

Figur 16: “Hva bør forbedres?” fra retrospective meeting

48

Figur 17: “Hva likte vi mindre/Hva gikk dårlig?” fra retrospective meeting

4.3.3 Sprint 2

Varighet: 24.03.2017 - 13.04.2017

24. mars 2017 møtte vi opp på Aker Sykehus for å delta på workshop sammen med

ansvarlig for Design Thinking, prosjektleder og en representant fra Sunnaas

Sykehus.

Målet for workshopen var å komme tettere inn på brukere, og sammen med oss

deltok to personer som kunne være potensielle brukere.

Hege fra IBM holdt et lite grunnkurs i Design Thinking og fortalte konsist om de

grunnleggende prinsippene og bakgrunnen til konseptet.

Deretter ble post-it lapper og tusjer delt ut til alle og vi fikk nå oppgave om å tegne en

vase på 1 minutt.

Oppgave 2 var å tegne opp “en bedre måte å oppleve blomster på i hjemmet”, der

hadde man også 1 minutt på seg.

49

Til slutt ble det en sammenligning av resultatet i første og andre oppgave, og alle

hadde ulikt syn på en vase samt hvordan å oppleve blomster på i hjemmet.

Neste oppgave var å kunne “sette seg inn i en bruker”. Hege hadde på forhånd laget

en persona som het “Petra Pensjonist”.

Petra er 78 år, pensjonist, har dosett og tar fem medisiner inkludert én sprøyte og én

kosttilskudd hver dag.

Figur 18: “Personalia til Petra Pensjonist”

I første omgang virket det som alt tilsynelatende stod bra til med Petra, hun var klar i

hodet og hadde heller ingen kognitive vansker. Hovedutfordringene hennes var å

huske om hun hadde tatt medisinene sine til rett tid, og hun ønsket å få en oversikt

over medisinene sine.

Vi skulle likevel få muligheten til å komme dypere inn på Petra ved å benytte oss av

et empati kart. Her skulle vi plotte inn hva Petra sa, tenkte, følte og gjøremål.

50

Figur 19: “Design Thinking Empathy Map”

Det var tur for “As is”, der man går igjennom hva vedkommende gjør, tenker og føler.

Vi skulle nå fylle inn hva Petra Pensjonist gjorde i løpet av morgen, formiddag,

ettermiddag og på kvelden. Det var ingen grenser på hva Petra kunne gjøre, så her

var det for oss å slippe fantasien løs.

51

Figur 20: “Design Thinking - As is”

Morgen:

Doing: ● Står opp,

● Dusj/påkledd,

● Tar medisin ut av skuffen,

● Sjekker blodsukkeret, sjekker dosetten,

● Trekker opp insulin/setter injeksjon,

● Tar medisin

● Ser på frokost-tv, lager frokost, drikker kaffe og leser avisen.

Thinking: ● Jeg føler meg litt tung i kroppen i dag

● Hvor la jeg dosetten i går?

● Når var den legetimen?

Feeling: ● Tenk om jeg bommer på insulindosen - ser jo litt dårlig

● Glad (Sol og isen har smeltet)

● Føler seg bra

52

Formiddag:

Doing: ● Avtale utenfor huset. Glemmer medisinen.

● Legetime - Legen endre dosering på medisin

● Jeg skal ifølge legen slutte på pille 2

● Ringer datter for å fortelle om legetimen

● Spiser lunsj

● Tar medisin 2

● Handletur

Thinking: ● Kan jeg spørre legen om å sette sprøyten? Liker det ikke selv…

● Får jeg nye medisiner i dag?

● Nå skjønner jeg ikke hva legen mener?

● Når endret vi medisin sist?

● Finnes det nye og bedre medisiner?

Feeling: ● Lei av medisinene

● Forvirret/usikker

● Demotivert

Ettermiddag:

Doing: ● Går tur

● Tar sprøyte

● Lager middag

● Får besøk av nabo, spiser kake

Thinking: ● Jeg lurer på om kvalmen er en bivirkning?

● Hva skal jeg ha til middag?

Feeling: ● Trøtt

53

Kveld:

Doing: ● Sjekker blodsukker for natten, beregner insulin for natten, finner frem riktig

insulin

● Leter etter dosetten, tar medisin

● Legger seg, står opp og sjekker dosetten

Thinking: ● Hva er egentlig denne medisinen for?

● Obs, glemte å ta medisinene i går...gjør det noe?

● Har jeg tatt medisinen i dag?

Feeling: ● Trøtt

I og med at det var 7 personer som skrev på hver sine post-it lapper til disse stegene

ble det ganske tydelig at alle hadde en forskjellige mening om hva Petra gjorde,

tenkte og følte, og siden det er snakk om medisiner så er det veldig viktig å ha god

oversikt og kontroll.

Utfra disse stegene så vi at Petra visste hvor medisinene var, men så glemte hun

det. Det var tid for legetime, og hun fikk ny medisin. Dette gjorde Petra usikker og

demotivert.

Hensiktet med “As is” er å bidra til å dokumentere kollektiv forståelse for brukerens

arbeidsflyt.

Studentgruppen fikk stor læringsutbytte av dette, da sju ulike personer som sagt

tenker ulikt og gjennomfører oppgaver på forskjellige måter.

54

Til slutt skulle vi gå igjennom hva Petras behov var i form hva han hun trengte.

Figur 21: “Design Thinking - Needs Statement”

Alle post-it lappene ble rangert helt tilfeldig i første omgang, deretter gikk man

igjennom de ulike punktene og satt de sammen med andre punkter for å kunne

utfylle “Petra trenger en måte X slik at X”.

55

Trenger en måte å: Slik at:

● Et system som bidrar til at hun klarer

å administrere sine medisiner

● Holde orden på forbruket av

medisinene

● Helsa holdes vedlike

● Hun skal fortsette selvhjelpen

● Rutiner og jevnlig oppfølging

● Klare rutiner for medisinering

● Hun har kontroll på medisininntaket

og holder seg frisk

● Hun holder seg frisk og blir ivaretatt

● Hjelp til å få med medisiner når hun

er ute av huset

● Bli påminnet til å ta medisiner til

riktig tid

● Hun kan ta medisinen sin på god tid

● Hun ikke lider konsekvensene av å

glemme å ta medisinene

● Sjekke medisinering

● En god oversikt over alle medisiner

hun skal ta

● Hun tar rett medisin til rett tid

● Ikke tar medisin unødvendig/feil

medisin

● En måte for å huske medisiner hver

dag til alle tidspunkter

● Vite at hun har tatt medisin

● Hun ikke går glipp av en dose

● Hun ikke tar dobbelt

Mot slutten av sprinten var det tid for en ny demo, og denne gangen var designet blitt

mørkeblått. Funksjonene som registrering og login gikk nå via databasen fremfor den

falske backenden vi hadde tidligere. I tillegg hadde vi implementert kalenderen, men

den var ikke integrert i selve applikasjonen på dette tidspunktet.

56

Figur 22: Skjermdump fra PersonAAL forsiden fra Sprint 2

4.3.4 Sprint 3 Varighet: 14.04.2017 - 04.05.2017

I løpet av denne sprinten var det om å ferdigstille applikasjonen slik at vi var klare for

siste demo.

Funksjonalitetene som gjaldt registrering og login gikk nå gjennom databasen

fremfor den falske backenden vi hadde tidligere, og funksjonaliteten “Edit profile” ble

implementert.

Notifications som ble satt på vent fra sprint 1, ble også implementert og bruker fikk

nå endelig varsling om at det er på tide å ta en bestemt medisin.

Kalenderen ble endelig integrert i applikasjonen ved hjelp av veileder fra IBM, og

koblet til medisinlisten, og vi var svært fornøyde med vår innsats.

Teamet gikk inn for å implementere sikkerhet ved bruk av Passport Local, fordi vi

kom fram til at dette var god løsning . Passport Local gir muligheten til å autentisere

seg ved bruk av brukernavn og passord, og tildeling av sessions. På slutten av

sprinten, fant vi ut at bruk av Passport Local ikke egnet seg best i vår applikasjonen.

Vi ønsker nemlig å dele data med andre aktører i PersonAAL prosjektet.

57

Vi gikk derfor inn for å skifte over til Passport Basic, som støtter OAuth34. OAuth gir

muligheten til å gi tilgang til tredjeparts aktører uten å oppgi brukernavn og passord.

På den siste demoen vår var også vår kontaktperson tilstede, og vi fikk høre alles

synspunkter angående sluttproduktet vårt.

Figur 23: Skjermdump fra PersonAAL forsiden fra Sprint 3

34 Hanson, J.(u.å.). Documentation. I Passport.js. Hentet 19. mai 2017 fra http://passportjs.org/docs

58

5 Begrensninger Mot slutten av den oppsatte prosjekttiden hos IBM, valgte IBM å nedprioritere

funksjonaliteten “Caregiver” og heller fokusere på de andre funksjonalitetene og

kravene som er satt i kravspesifikasjonen [Vedlegg Nr 1].

Derimot ble event funksjonen til “Caregiver” implementert, men ikke selve rollen.

Som tidligere nevnt i rapporten ble prioriteringsnivået til funksjonaliteten “Caregiver”

satt ned fra Høy til Lav.

Dette kravet inngår derfor i punkt “7 Videreutvikling, Frontend”.

59

5. 2 Utviklingsprosessen avsluttes

5.2.1 Arbeidsfordeling og samarbeid

Selv om vi kjente hverandre fra før av, og hadde arbeidet sammen i et annet fag

tidligere, hadde vi fortsatt noen utfordringer.

Vi var tross alt tre personer med helt forskjellige personligheter og tre forskjellige

måter å arbeide på. Til tross for at det har vært noen uenigheter, har vi diskutert det

ut og stort sett vært enige om det meste når det gjaldt prosjektet. I tillegg har vi lært

hverandre å kjenne enda bedre.

Prosjektleder la til rette for at vi kunne arbeide med prosjektet hos IBM på Mastemyr

når vi måtte ønske det, og vi har benyttet oss av denne muligheten. Senere ut i

prosessen fikk vi anledning til å jobbe på Oslo Cancer Cluster på Ullern, og på

Sundtkvartalet på Tøyen.

I starten av sprint 0 delte vi applikasjonen i to der Elisabeth og Huebert jobbet med

selve webapplikasjonen, mens Julian jobbet med IBM Cloudant databasen og web

API.

I tillegg var vi ganske oppslukt i hver vår del, så det endte med at vi var litt dårlige til

å lære bort det vi nylig hadde lært selv.

I starten var vi også veldig flinke til å føre prosjektdagbok, men det dabbet av etter at

et gruppemedlem måtte opereres i midten av mars. Til gjengjeld kunne vi alltids gå

igjennom chat-loggen, slack eller loggen til git for å se hva en enkelt hadde arbeidet

med tidligere.

Hvis det var noe vi lurte på, som vi selv ikke kunne svare på, var alltid veiledere eller

utviklingsleder tilgjengelige på slack om noe skulle være uklart.

De var også veldig behjelpelige hvis vi møtte på et problem som vi ikke kunne løse,

og dette gjorde at vi for det meste slapp å bruke flere dager på å løse et problem.

60

Rundt siste uka av mars fikk vi også ny veileder som var tilgjengelig så og si døgnet

rundt. Veileder Juraj var blant annet til stor hjelp i sprint 3 når vi skulle integrere

kalenderen inn i webapplikasjonen.

5.2.2 Forhold til oppdragsgiver

Vårt forhold til IBM har vært godt, og vi har følt at kommunikasjonen har vært god

gjennom hele prosjektet. Vi føler det har vært klare definerte forventninger til oss

som gruppe og til produktet vi har utviklet.

IBM har vært med oss under hele prosessen, og gitt oss veiledning etter behov. Har

vi hatt spørsmål, så har enten veiledere eller utviklingsleder alltid vært tilgjengelige

for å hjelpe oss.

Prosjektleder har også vært til stort hjelp når det kom til dokumentasjon.

5.2.3 Veiledning fra Høgskolen

Vi fikk tildelt Thor E Hasle som veileder, og vårt forhold har vært bra.

Vi har sendt han e-poster ved behov når vi har lurt på noe, eller for å avtale møter.

Alle møtene vi har hatt med Thor har gitt oss mye, og han har gitt oss råd og tips om

hvordan ting bør utføres og vi har hatt et læringsutbytte av dette. I alt har vi vært

svært fornøyde med vår veileder, vi takker for hans tid og hjelp gjennom prosessen.

61

6 Produktdokumentasjon

6.1 Leserveiledning

I produktdokumentasjonen beskriver vi applikasjonens funksjonalitet og virkemåte i

detalj.

Her presenterer vi applikasjonens omfang ved å beskrive de forskjellige mulighetene

det gir brukeren, samt en teknisk redegjørelse for oppbyggingen av disse.

Det forutsettes også at leseren har satt seg inn i oppgavens formål og omfang, som

beskrevet i presentasjonsdelen og i prosessen.

Det forutsettes at leseren innehar en viss teknisk innsikt, men de konkrete

teknologiene samt eventuelle kodesnutter vi har benyttet oss av blir beskrevet.

Alle klasser, metoder og attributter har selvforklarende navn som sier noe om hvilke

funksjoner de utfører.

6.2 Overordnet systembeskrivelses

Applikasjonen skal gi brukere en oversikt over deres medisiner og en kalender som

viser når brukeren skal ta medisinen sin.

Medisinen til en bruker skal kunne endres på og/eller slettes, og man kan legge til ny

medisin hvis det skulle være ønskelig.

6.3 Videreutvikling for utviklere

For videreutvikling av applikasjonens frontend kreves det kunnskap om Angular 2,

HTML, Bootstrap, CSS og JavaScript. Det anbefales også at man har kjennskap til

MEAN-stack strukturen da selve applikasjonen er bygd opp på den, og

applikasjonen følger MEAN-stack mappestrukturen i selve prosjektmappa.

For videreutvikling av Web-API kreves det kunnskap om Node.js, Express.js,

JavaScript, IBM Bluemix og forståelse for hvordan klient-server kommunikasjon via

HTTP fungerer.

For videreutvikling og vedlikehold av Cloudant databasen stilles det krav til at man

kan å bruke Cloudant Dashboard og forstår hvordan oppbygningen i NoSQL, og

hvordan bruken av dokumenter fungerer.

62

Det er viktig å merke seg at man ikke må tenke relasjonsdatabase ved oppbygging

av dokumentene, da dette er i strid med strukturen som brukes i en NoSQL

Database.

63

6.4 Webapplikasjonen I denne omgang har vi tatt høyde for at brukeren som skal benytte seg av

applikasjonen er en førstegangsbruker.

6.4.1 Forsiden

Når man tar i bruk applikasjonen for første gang, så er det første man får opp

innloggingsboksen.

For å kunne logge inn må man ha en bruker. Har man ikke det, kan man registrere

seg som ny bruker.

Figur 24: Innlogging

64

6.4.2 Registrering

For registrering får brukeren opp skjemaet vist i figuren nedenfor.

Brukeren må fylle ut E-postadresse, Fornavn, Etternavn, Brukernavn og Passord for

å kunne registrere seg. Her har man også muligheten til å kunne se passordet man

ønsker å benytte seg av, fremfor at passordet blir omgjort til asterisk *.

Figur 25: Registrering av ny bruker

65

Skulle noen felt mangle, vil man få beskjed om å fylle ut disse. Man får ikke opprettet

en bruker før alle feltene er korrekt fylt ut.

Figur 26: “Alle felter må fylles ut”

Hvis e-postadressen mangler alfakrøll, så vil man få en feilmelding om å bruke riktig

epost-format.

Figur 27: “Feil e-post format”

Etter at registrering er fullført og vellykket vil man bli sendt videre til login for å kunne

logge inn.

66

Figur 28: Innlogging

Hvis bruker taster inn feil brukernavn eller passord, vil brukeren få opp en feilmelding

som vist i figuren nedenfor.

Figur 29: Innlogging feilet

67

6.4.3 Min side

Dersom innloggingen er vellykket blir brukeren ført direkte til sin personlige side. I

tillegg vil man få opp en forespørsel fra nettleseren om man vil tillate varslinger.

For at brukeren skal kunne motta varsel om medisinering er det gitt at brukeren har

godkjent varsling.

Inne på “Min side” har brukeren muligheten til å endre personalia, se oversikt over

medisiner, se i kalenderen og selvfølgelig logge ut. Brukeren kan også bruke

menybaren fremfor knappene.

Figur 30: Min side med forespørsel om varsling

Figur 31: Min side

68

6.3.4 Toggle-tip

Hvis noe skulle være uforståelig, så er det lagt til toggle-tips som automatisk

kommer opp hvis brukeren peker musen over en av knappene. På denne måten vil

brukerne kunne få informasjon om hva hensikten til hver enkelt knapp er.

Figur 32: Medicine toggle-tip “Your full list of medications”

Figur 33: Calendar toggle-tip “Add medications into calendar and list of medications”

69

6.4.5 Endre profilinformasjon

En bruker kan endre på sin egen profilinformasjon og passord om dette måtte være

ønskelig.

Ved endring av profilinformasjon vil informasjon allerede knyttet til profilen være utfylt

i de korrekte feltene.

Feltene kan endres, og lagres ved å klikke “Save changes”. Brukeren har ikke

muligheten til å endre på brukernavnet sitt, derfor er feltet “Username” markert som

grått og deaktivert.

Figur 34: Endre profil

70

For at brukeren skal kunne endre passordet sitt må brukeren skrive inn nytt passord

to ganger. Deretter trykkes “Save changes”.

I hvert felt er det lagt til en “show” funksjon, og hvis brukeren trykker på den vil de få

muligheten til å se hva de skriver inn.

Figur 35: Endre passord

Hvis endringene er vellykket vil bruker få beskjed om at databasen er oppdatert.

Figur 36: Lagring av data vellykket

71

6.4.6 Medisinliste

Ved å trykke på “Medicine”, blir man ført over til listen over medisiner tilknyttet sin

bruker.

Her kan man se hva medisinen heter, når start og sluttdato er, hvilke dager man skal

ta medisinen på, hvilken tid og eventuelle notater fra legen.

En “More information” knapp tar brukeren videre til for eksempel felleskatalogen for

mer informasjon angående den spesifikke medisinen.

Medisinlisten er knyttet til kalenderen, og for at man skal kunne få lagt til en ny

medisin må man inn på kalenderen for å gjøre dette.

Figur 37: Medisinliste

72

6.4.7 Medisinlisten er tom

Skulle medisinlisten være tom, vil man få opp en feilmelding som gir beskjed om

dette.

Figur 38: Medisinlisten er tom

73

6.4.8 Kalender

Opprinnelig er tanken at en bruker og en gitt caregiver skal dele en kalender, der

caregiver har muligheten til å legge inn nye medisiner til brukeren, og brukeren vil

kunne se disse endringene i sin medisinliste og kalender.

Brukeren skal opprinnelig ikke ha muligheten til å se “Edit Events”, men kun

kalenderen.

Som nevnt tidligere i prosessen ble funksjonen “Caregiver” implementert, men ikke

selve rollen.

Dagens dato vil alltid være markert i kalenderen når brukeren trykker seg inn.

Figur 39: Kalender

74

6.4.9 Legge til medisin

Ønsker man å legge til eller endre på medisin kan man gjøre dette under “Edit

Events”.

Figur 40: Edit Events

For å legge til en ny medisin må man først trykke på “Add new”, og deretter fylle inn

feltene. Feltene med asterisk symbolet * er obligatoriske og må fylles ut.

Figur 41: Legge til ny medisin

75

Etter utfyllingen trykker man på “Save changes”, og dataene om ny medisin vil bli

lagret til databasen.

I tillegg vil tiden man har skrevet inn under “Time to take” trigge push-notifications til

å gi brukeren varsling fra applikasjonen om når brukeren skal ta den rette medisinen

sin.

For å kunne motta varsling er det gitt at brukeren trykket på “Godkjenn/Allow” etter

innloggingen. Skulle det være slik at brukeren avviste tilbudet om varsling, har

brukeren mulighet til å endre dette i innstillinger i netteleseren.

Man kan legge til flere medisiner samtidig om det skulle være ønskelig, og en eller

flere medisiner kan enkelt slettes ved å trykke på “Delete”.

Figur 42: Legge til ny medisin del 2

76

Etter at lagring av data er vellykket vil bruker kunne se sin nye medisin i kalenderen.

Figur 43: Ny medisin i kalender

Informasjon om ny medisin vil nå være tilgjengelig i medisinlisten.

Figur 44: Ny medisin lagt til i listen

77

6.4.10 Push-notifications

Etter at ønsket tid er angitt til en medisin i kalenderen, vil man få varsling om at det

er på tide å ta medisinen sin.

Hvis man for eksempel har satt tiden til 12:00 på medisinen Glivec, vil brukeren få en

påminnelse på det gitte tidspunktet om at det nå er på tide å ta medisinen sin.

Figur 45: Skjermbilde av applikasjonen med varsling “Glivec: Det er på tide å ta

medisinen din”

78

6.5 Samsvar mellom kravspesifikasjon og endelig

produkt I prosessen nevnte vi at funksjonaliteten “Caregiver” ikke ble utviklet da IBM heller

ville at vi skulle prioritere og fokusere på andre oppgaver.

Funksjonaliteten “Caregiver” sin hensikt var å være en ordinær bruker, men med

rettigheter til å endre og legge til medisiner i kalenderen til en annen ordinær bruker.

En bruker skal ha muligheten til å søke opp i en liste over brukere som har caregiver

rollen. Deretter kan de huke av for om de ønsker å gi denne brukeren tilgang til

deres kalender.

Nedenfor er en figur av en sketch vi lagde underveis i prosessen som viser ønsket

funksjonalitet i form av et brukergrensesnitt der brukeren har en liste over sine

“Caregivers”.

Figur 46: Sketch av caregiver

Brukere som har fått tildelt rollen “Caregiver” skal ha muligheten til å klikke seg inn

på en liste over deres brukere, og få tilgang til deres medisinliste og kalender.

79

Kalender brukergrensesnittet til en ordinær bruker og en “Caregiver” vil se likt ut,

men “Caregiver” vil i tillegg ha “Edit Events” komponenten.

Hensikten med “Edit Events” er at “Caregiver” skal kunne legge inn nye medisiner,

endre og/eller slette medisiner til den aktuelle brukeren.

Figur 47: Kalender med Edit Events

80

Figur 48: Development tasks for Caregiver

Figur 49: Caregiver

81

6.6 Applikasjonens oppbygging og virkemåte

6.6.1 MEAN-Stack struktur og informasjonsflyt

MEAN-stack er en samling av teknologier som sammen utgjør en full JavaScript-

stack. Dette innebærer at alle delene av stacken er skrevet i JavaScript og at hele

applikasjonen må skrives i JavaScript. MEAN-stacken brukes til å skrive

webapplikasjoner eller dynamiske nettsider. De fire teknologiene som inngår i

MEAN-stacken er MongoDB, Express.js, Angular.js og Node.js.

Vi tok ikke i bruk MongoDB, men heller en Cloudant NoSQL database da dette var

forhåndsbestemt fra IBM sin side.

Figur 50: MEAN-stack flyt

82

6.6.2 Systemarkitektur

Figur 51: Systemarkitektur PersonAAL Medication Monitoring

Figuren ovenfor viser systemarkitekturen for hele systemet.

Arkitekturen er separert i to hoveddeler og består av en webapplikasjon og et Web

API.

Webapplikasjonen er igjen delt inn i to deler, frontend og backend.

Hovedansvaret til backend er å rendre angular til frontend, og kommunisere med

Web API’et. Rendering er prosessen som konverterer en datamodell til et bilde som

kan vises på en skjerm. I programvare konverteres datamodellen til design,

konstruksjon og lignende.

Frontend har som ansvar å vise brukergrensesnittet til brukeren, og kommunisere

med autentiseringen med Passport.js.

Web API’et har som ansvar å motta forespørsler fra webapplikasjonen og å svare

med en passende respons. Før webapplikasjonen kan få tilgang til API’et må

webapplikasjonen autentisere seg via Passport.js. Denne prosessen blir forklart i

delkapittelet om Sikkerhet.

83

6.6.3 Microservice

Microservice er en liten web service som er spesialisert til å gjøre en ting.

For å lage oversikt og forenkle administrasjon og tilgang er microservices gjerne

samlet bak en API Manager. I vårt tilfellet har vi valgt å bruke Express.js middleware

til å administrere de ulike API’ene.

En microservice er liten, intuitiv/selvforklarende og brukes til et spesielt formål. Den

har heller ingen kode avhengigheter til andre tjenester, og er en del av en

koreografert løsning.

Figur 52: Kalender-Microservice

84

6.7 Frontend

6.7.1 Brukergrensesnitt

Brukergrensesnittet er rent, minimalistisk og forståelig.

Det inneholder de funksjonelle egenskapene innlogging, registrering, endre profil &

passord, medisinliste, kalender og utlogging.

Brukergrensesnittet er brukervennlig, har et ryddig oppsett med knapper og

informasjon.

6.7.2 Bootstrap & Responsive Web

Bootstrap er laget spesielt for utvikling av responsive websider. Dette CSS-

rammeverket er bygget på konseptet “Mobile First” hvor man i utgangspunktet

utvikler en applikasjon for enheter med lav skjermoppløsning for å så gjøre

tilpasninger for visning på større skjermstørrelser.

Rammeverket introduserer et responsivt grid system som skalerer opp til 12

kolonner etterhvert som visningsstørrelsen øker.

Det inneholder forhåndsdefinerte klasser for enkle layout alternativer, og mixins som

generere flere semantiske oppsett.

Klassene er definert slik:

● Col-xs-* → ekstra små enheter

● Col-sm -* → små enheter

● Col-md-* → medium enheter

● Col-lg-* → store enheter

Grid klasser gjelder for enheter med en skjermbredde større eller lik den definerte

klassestørrelsen.

Ved å angi en col-md-* klasse til et element som f. eks et panel, vil det påvirke

utseendet på både medium og store enheter.

85

Grid klassen kontrolleres av visningsstørrelse.

Etterhvert som nettleserens bredde øker vil de forskjellige klassene overskrive de

klassene rettet mot mindre enheter, og omvendt. På en bredde som tilsvarer en

mobil vil klassen for ekstra små enheter, col-xs-* være aktiv. Økes bredden til full

bredde vil klassen for store enheter, col-lg-*, bli aktiv, og klassen vil overskrive alle

klassene som gjelder mindre enheter. Alle kolonner er antatt å ha en bredde på

100% av skjermstørrelsen, og blir stablet oppå hverandre vertikalt. Det må derfor

defineres kolonne størrelser for de forskjellige enhetene. Col-md-4 vil lage en 4’er

kolonne for størrelsen medium og større. På mindre enheter enn medium vil de gå

tilbake til å ha en bredde på 100% av skjermstørrelsen. Det er dette som blant annet

gjør applikasjonen responsiv.

Figur 53: Kodesnutt fra “Medicine.Component”

86

Alle HTML komponentene våre har en grid klasse i form av “col-” slik at innholdet

alltid vil følge sin enhet.

Figur 54: Forsiden på desktop

Figur 55: Forsiden på iPhone 6

87

6.7.3 Angular 2

Applikasjonen er bygget opp med “components” og “services”, og navnene til disse

som er brukt i applikasjonen er selvforklarende.

I Angular er komponenter viktig, og det er måten man bygger og spesifiserer logikk

og elementer i applikasjonen gjennom egendefinerte elementer og attributter som

legger til funksjonalitet til eksisterende komponenter.

Komponenter inneholder to viktige deler, en template som viser hvordan elementene

skal se ut i applikasjonen, og logikken.

Template er HTML filer, mens logikken er TypeScript filer.

Figur 56: Logikken i Medicine.Component.ts

Components inneholder to viktige ting, en template, som omhandler hvordan

elementene skal se ut i applikasjonen, f eks input felter og knapper, og logikken.

88

Applikasjonen er også bygget opp på “services”. Services brukes til å lage

funksjoner som er gjenbrukbare. Hvis man trenger samme kodesnutt i forskjellige

komponenter, så benytter man seg av services.

Services sitt formål er å forhindre at man skriver samme kode i ulike komponenter.

Funksjonene trenger da bare å bli definert en gang, og kan så brukes i de ulike

komponentene der det er nødvendig.

Figur 57: Medisinlisten i Medicine.Component.ts

Oversikt over komponenter i applikasjonen:

login.component En bruker kan logge inn med å bruke brukernavn og

passord.

Ved bruk av “Authentication Service”, sender vi en request

til API og sjekker om brukeren eksisterer.

Eksisterer brukeren sender API’et en JSON-fil tilbake som

inneholder informasjon om brukeren som logger inn.

Informasjonen blir lagret i session storage sammen med

en JSON Web Token, for sikkerhet, i nettleseren til senere

bruk.

home.component Komponenten viser informasjon om innlogget bruker som

er hentet fra session storage i nettleseren. (Brukernavn,

navn og epostadresse)

Logikken for push notifications ligger også i denne

komponenten, som forespørsel om man vil tillate

varslinger, og sende varsling om når en medisin skal tas.

89

medicine.component I denne komponenten skjer visning av medisinliste. Vi

bruker “Medicine Service” sammen med denne

komponenten.

Vi henter data fra API’et og får det som en JSON-fil.

Deretter lagrer vi JSON-filen som et array, og viser

dataene ved bruk av Angular *ngFor.

register.component

Komponenten brukes til å registrere en ny bruker i

applikasjonen. Ved hjelp av “Patient Service”, sender vi

informasjonen som er lagret i et JSON-fil, ved bruk av

HTTP.POST til API’et. Dataene som skrevet i input feltene

blir validert først, før det sendes videre. Hvis alt går bra, får

bruker beskjed om dette, ellers vil bruker få en feilmelding.

editprofile.component Endring av profilinformasjon skjer i denne komponenten.

All informasjon om innlogget bruker blir vist på skjermen.

Service som brukes her er “EditProfile Service”, og

informasjonen som er endret blir sendt til API’et ved bruk

av HTTP.PUT.

calendar.component Komponenten brukes for å blant annet generere

brukergrensesnittet for kalenderen.

Komponenten inneholder flere services som calendar-

header, colors, date-time-picker og module.

All input i kalenderen vil bli lagret til databasen og

videresendt til medisinlisten.

90

6.7.4 Backend

6.7.4.1 Web API

Web API’et er bygget med rammeverket Node.js og Express.js, Web API’et har en

rekke API’er som kan kalles. Stort sett all funksjonalitet som er bygd i frontend kaller

på API’ene som er laget i web API’et. Disse kan kalles om man har tilstrekkelige

rettigheter.

ApI’ene kalles på følgende måte: https://ibm-

personaal.mybluemix.net/<API_navn>/:evt_parameter

F.eks: https://ibm-personaal.mybluemix.net/api/calendars/:brukernavn

Vi følger konvensjonen fra Mulloy, B.(2012)35.

● Det er kun 2 URL’er per ressurs

● Bruker HTTP verb for å operere på forskjellige elementer og samlinger

(Collections)

● Ingen HTTP verb i URLene

Alle API ressursene har “/api” i URL’en foran seg, dette er for å fremheve at det er

API’er man kaller på.

API’er som er implementert i vår løsning er:

● Patient

● Calendar

● Authenticate

35 Mulloy, B.(2012). Web API Design: Crafting Interfaces that Developers Love. I E-bok. Hentet 21.mai 2017 fra http://www.goodreads.com/book/show/13574087-web-api-design

91

Eksempel Kall til Web API

Ressurs POST GET PUT DELETE

/api/authenticat

e

Autentisering for å

aksessere web API.

Brukernavn og passord

må være del av

forespørselen

Error Error Error

Ressurs POST GET PUT DELETE

/api/calendars Lag en ny

pasient

kalender

(denne blir

automatisk

laget når en

pasient

registrer seg)

List ut alle

kalendere

Oppdater alle

kalendere

Slett alle

kalendere

/api/calendars/

:parameter

Error Vis pasient

kalender med

parameter

Oppdater

pasient

kalender med

parameter.

Hvis den ikke

eksisterer,

kast error

Slett pasient

kalender

innlegg med

parameter

92

Ressurs POST GET PUT DELETE

/api/patients Lag en ny

bruker

List ut alle

kalendere

Oppdater alle

kalendere

Slett alle

kalendere

/api/patients/:p

arameter

Error Vis pasient

med med

parameter

Oppdater

pasient med

parameter

Slett pasient

med

parameter

Figur 57: Web API Microservicer klassediagram

6.7.4.2 Cloudant databasen

All aksess til databasen gjøres via Web-API, databasen er beskyttet med brukernavn

og passord og er lagret på Node.js serveren som en .env fil(miljø fil).

Alle kall til databasen via web API er kryptert med HTTPS, slik at informasjon fra

databasen ikke er lekker ut til en tredjepart.

Når en spørring gjøres mot databasen, og er vellykket, vil databasen returnere

dataene i et JSON format tilbake til Web API.

93

6.7.4.3 Databasestruktur

Figur 58: Database model

Figur 59: Calendar og userprofile databasestruktur(fra brukerhistorie 2576)

94

6.8 Sikkerhetsaspekter ved applikasjonen Med tanke på at applikasjonen skal ligge tilgjengelig på internett, og inneholder

personsensitive data, er det viktig at den er så sikker som mulig.

Dette omfatter både tilgangskontroll, datalagring og dataoverføring, som blir

beskrevet nærmere i følgende punkter:

6.8.2 Tilgangskontroll og passordlagring

Passport.js Basic krever brukernavn og passord for autentisering.

Figur 58 nedenfor viser hvordan vi har implementert sikkerhet mellom

webapplikasjonen og Web API.

95

Figur 58: Påloggings flyt fra Webapplikasjonen til Web API (versjon 2)

96

Hvis man prøver å aksessere web API utenom webapplikasjonen, blir man bedt om

å autentisere seg.

Figur 59: Authorization header

Hvis brukeren prøver å trykke på x i høyre hjørne eller “cancel”, vil brukeren få

tilbake HTTP Response 401 Unauthorized.

Figur 60: HTTP Response 401 Unauthorized

Når det gjelder tildeling av session til brukeren vil den gå utenfor systemarkitekturen

nevnt ovenfor, Figur 51: Systemarkitektur PersonAAL Medication Monitoring.

Kommunikasjonen vil gå direkte fra webapplikasjons frontend til Passport.js og visa-

versa vist på figuren nedenfor.

97

Figur 61: Systemarkitektur tildele session

Det er viktig å merke seg at denne sikkerhetsløsningen ikke er fullstendig og har

mangler. For det første er det slik at etter en bruker har autentisert seg, vil brukeren

ha tilgang til all data, også andre brukeres data. Dernest aktører i PersonAAL

prosjektet som har ansvar for å utvikle en sikkerhetsløsning og den implementerte

sikkerhetsløsningen er kun midlertidig. Disse funksjonalitetene vil bli ordnet opp i av

IBM som skal videreutvikle dette prosjektet.

98

6.9 Deployering av applikasjonen Webapplikasjonen og Web-API’et blir deployert ved bruk av IBM Bluemix Cloud Foundry App på IBM sin public cloud.

Ved å benytte seg av public cloud gir det muligheten for alle som har tilgang til

internett å aksessere nettsiden.

Videre blir selve prosjektet bygget og deployert automatisk ved bruk av Pipeline fra

Continuous Delivery Toolchain.

Fordelen ved å bruke dette, er at man kan for hver gang man gjør en endring, se

hvordan produktet fungerer i det faktiske produksjonsmiljøet, og ikke bare på hver

enkelt datamaskin.

I tillegg får man ved bruk av denne metoden inn DevOps mentalitet med

Continuous deployment og integration.

Integrerer man systemene sammen oftere, fører dette til at man kan enklere

oppdage bugs i programmet og eventuelle feil i integreringen av de forskjellige

modulene.

99

7 Testing av applikasjonen

7.1 Enhetstesting

Det hadde vært fordelaktig å integrere enhetstester i applikasjonen, både for vår

egen og IBMs del og for andre som skal videreutvikle applikasjonen.

Det at vi ikke har enhetstester i applikasjonen er en avgjørelse fra IBMs side.

IBM mente det ikke var nødvendig å utføre tester, da IBM skulle ta over utviklingen

når vi ble ferdige og det var andre aktører som skulle stå for testing.

Derfor valgte vi heller å fokusere på å implementere det vi anså som mer viktig

funksjonalitet.

Først og fremst var vi opptatt av å strukturere informasjonsflyten, slik at strukturen på

dataene og funksjonene var konsistente gjennom hele applikasjonen.

Hvis vi skulle utført noen form for enhetstester, mener vi at API’et er den delen av

applikasjonen det hadde vært nødvendig å skrive enhetstester for.

Da måtte vi ha gjort dette samtidig som vi bygde det opp.

7.2 Testplan

Testplanen har bestått av å gi en bruker et sett med use cases, for så å utføre det

med minst mulig instruksjoner fra gruppen.

Grunnen til dette er for å undersøke om siden er intuitivt lagt opp, og observere

eventuelle bugs eller feil som kan oppstå.

Funksjonalitetene som skal testes er kravene fra kravspesifikasjonen [Vedlegg Nr 1].

7.3 Gjennomføring

En uavhengig person ble satt til å utføre hver enkelt oppgave i testplanen, med så

lite innspill fra gruppen som mulig.

Det er gitt at testpersonen er 88 år og har en liten til middels kunnskap om teknologi.

100

Gruppen noterte seg resultatet av hver enkelt test, og førte dette inn i den tilhørende

resultat-cellen

7.4 Konklusjon av testing

Testpersonen gjennomførte alle oppgavene i testplanen på tiltenkt måte, kun basert

på egen intuisjon. Gruppen konkluderer med at applikasjonen er konstruert på en

tilfredsstillende intuitiv måte, og er uproblematisk å sette seg inn i for nye brukere.

Funksjonalitet Test Resultat

Registrere bruker Følge stegene for å opprette en brukerkonto OK

Logge inn Logg inn i applikasjonen ved hjelp av oppgitt

brukerinformasjon

OK

Endre e-

postadresse eller

passord

Navigere til “Edit profile” for å endre e-

postadresse eller passord

OK

Legge til Medisin i

kalenderen

Opprette en ny medisin i kalenderen OK

Se ny medisin Navigere til medisinlisten OK

Få varsling for en

medisin

Legge til tid på en medisin og se om bruker for

opp varsel

OK

Slette medisin fra

kalender

Slette medisin fra kalenderen OK

Sjekke at medisin

er slettet

Medisinen skal være slettet fra medisinlisten OK

Logge ut Logge ut fra applikasjonen OK

101

8 Videreutvikling

8.1.1 Brukergrensesnitt

Brukergrensesnittet kan videreutvikles på flere måter. Utvikler kan endre på CSS,

eller legge til egne CSS filer.

Bootstrap kan benyttes for enda mer responsivt design, og bruk av diverse bootstrap

komponenter.

8.1.2 Caregiver

Som nevnt tidligere ble funksjonaliteten til “Caregiver” implementert, men ikke selve

rollen.

Man kan utvikle en komponent for “Caregiver”, hvor brukeren med rollen caregiver

får en liste over “pasientene” sine som de har tilgang til.

En “Caregiver” skal logge inn på applikasjonen, få oversikt over pasientene sine, få

tilgang til kalenderen til hver av pasientene og registrere,endre og/eller slette medisin

for den aktuelle pasienten.

“Caregiver” kan også godkjenne at brukeren/pasienter registrere varslinger i sin

kalender på riktig måte.

8.1.3 Push Notifications

Push notifications kan utvides med at det kommer opp en alarm boks som spør om

du har tatt medisinen din. Brukeren vil da ha muligheten til å svare “Ja”, “Nei” eller

“Vet ikke”.

Svaret fra brukeren skal lagres i databasen, og hvis brukeren har svart “Nei” eller

“Vet ikke”, så vil brukeren få en ny påminnelse om den medisinen ved senere tid.

102

8.2 Andre tanker

IBM Watson kan integreres i PersonAAL Context Engine, og da kan man benytte

seg av talegjenkjenning på Norsk og muligens eventuelle andre språk slik at brukere

som er blinde eller svaksynte kan benytte seg av lyd.

I senere tid kan man også implementere andre roller som for eksempel

“Helsepersonell”.

Helsepersonell kan for eksempel få data om en gitt bruker og få oversikt om

brukeren har tatt medisinen sin. Har ikke bruker tatt medisinen sin over en gitt tid, så

kan man sende en sykepleier over for å se hvordan det står til med brukeren.

Resepter kan også fornyes eller etterlyses i applikasjonen, slik at brukeren slipper å

fysisk måtte dra innom sin fastlege.

Det finnes allerede en løsning for resepter, PasientSky.

PersonAAL applikasjonen kan for eksempel integreres med PasientSky for å få

tilgang til dens funksjoner.

103

9 Konklusjon

9.1.1 Utfordringer

En av de største utfordringene vi hadde, var når vi måtte sette oss inn i så mange

forskjellige teknologier og metoder i startfasen.

Det var ikke så enkelt å bli kastet ut i hvordan man skulle utvikle en mobil hybrid app,

eller bygge opp et web API med en cloudant database.

Det å sette seg inn i Angular og Node.js var også krevende siden vi hadde ekstremt

lite kunnskap om teknologiene. Vi hadde såvidt vært innom Angular tidligere.

Når det gjaldt cloudant databasen fikk vi beskjed om å bruke callbacks når

databasen ble aksessert. Dette var noe vi aldri hadde jobbet med tidligere, så det ble

gjort mye research, prøving og feiling for å få til dette.

En av veilederne fra IBM tipset oss om at vi heller kunne benytte oss av promises i

stedet, siden det var enklere å bruke.

Dessverre så var promises vanskelig å sette seg inn i og forstå, og det tok litt tid før

vi fikk forståelse for promises. Men det løste seg etter at det ble benyttet i store deler

av løsningen, og da fikk vi en forståelse på hvordan promises fungerte i praksis.

Node.js skapte en del trøbbel for oss når vi skulle pushe opp kode til Git, og andre

skulle hente.

I starten måtte vi ofte fjerne hele Node.js biblioteket fra prosjektet, for å så installere

det på nytt med “npm install”.

Det hendte ofte at Huebert eller Elisabeth, måtte fjerne prosjektet lokalt fra deres

maskin, for å så hente det på nytt fra Git, noe som var ganske slitsomt i lengden.

I tillegg var det utfordringer når det gjaldt Angular 2. Hvis det var spørsmål rundt en

funksjon, så var Google til veldig lite hjelp.

Det var ekstremt lite tutorials som gjaldt Angular 2, og det førte til at vi slet en del i

starten. Senere ut i prosjektet fikk vi lært en del om Angular 2 fra en av veilederne fra

IBM, og da kunne vi komme oss videre med oppgavene vi skulle fullføre.

104

9.1.2 Hva kunne vært gjort annerledes

Når vi ser tilbake på prosessen så ser vi at det var ganske upraktisk å bruke

forskjellige typer versjonskontroller for deling av kode.

I tillegg kunne vi heller benyttet oss av MEAN-stack strukturen fra starten av fremfor

grunnstrukturen i et angular-webapplikasjon prosjekt. Det førte til at vi byttet over til

MEAN-stack i løpet av sprint 2 for å blant annet få en bedre mappestruktur.

Samtidig ser vi også at vi burde fordelt arbeidet bedre, vi burde heller ha jobbet med

frontend og backend sammen, fremfor å dele opp i webapplikasjon og Nodejs/Web

API.

Hadde vi gjort det slik, så ville vi kunne ha hjulpet hverandre bedre og fått en bedre

forståelse på hvordan løsningen fungerer i sin helhet.

I tillegg hadde denne måten bidratt til at vi som gruppe kunne deltatt mer i

diskusjonene vi hadde under demoene med IBM.

Vi var heller ikke de flinkeste til å spørre om hjelp i startfasen når vi stod fast.

Hadde vi vært flinkere til å benytte oss av veiledere fra IBM i startfasen, så hadde vi

nok ikke sittet fast en del ganger slik som vi gjorde.

Et annet punkt som kunne vært forbedret betraktelig er prosjektdagboken. Vi førte

dagbok fra høsten 2016 til midten av mars 2017. Hadde ikke dagboken blitt

neglisjert, så kunne vi ha sett igjennom den hvis det for eksempel skulle være noe vi

glemmer, hvorfor vi gjorde en endring eller hvorfor vi tok akkurat den beslutningen.

9.1.3 Læringsutbytte

Det største læringsutbyttet vårt må være erfaringen med å jobbe i et prosjekt som er

såpass stort med flere aktører som er involvert.

Dette er første gangen noen av oss jobber på et så stort prosjekt, og vi synes det var

vanskelig å vurdere størrelsen på oppgaven og hvordan vi burde strukturere

utviklingen.

Samtidig fikk vi på en måte en smakebit av hvordan arbeidslivet kommer til å bli,

siden vi jobbet for IBM.

105

Å jobbe med en dokumentbasert NoSQL database har også vært spesielt lærerikt.

Nå kjenner vi til både SQL og NoSQL, og ved senere anledning vet vi hva som

passer best til en prosjekt.

Vi har lært hvilke strukturer som passer for hvilke type webapplikasjoner og vi kan i

framtiden ta informerte valg basert på en applikasjoners formål og størrelse.

Design Thinking og deltagelsen på workshopen har også gitt oss et stort

læringsutbytte. Det å lære å komme tettere inn på brukere gir oss en større

forståelse på hvordan det er å være i “bruker-situasjonen”. På den måte kan vi i

fremtiden utvikle bedre løsninger basert på hva brukeren tenker, føler, gjør og

brukerens behov. Tilbakemeldingene vi fikk fra de potensielle brukerne fra

workshopen ga oss mye nyttig informasjon om hvordan vi videre skulle utvikle

webapplikasjonen når det kom til brukergrensesnittet og funksjonalitet.

Det vi synes er et fantastisk brukergrensesnitt er ikke nødvendigvis like fantastisk i

deres øyne.

Vi har også lært oss moderne teknologier som blant annet Node.js, Express.js,

microservice arkitektur, ES6 og mye mer som vi kommer til å ta oss med videre.

I tillegg har det også vært svært givende å få være med på utvikle en løsning som

kan bidra med på å løse samfunnskritiske problemer.

9.2 Videre arbeid Applikasjonen er i første omgang rettet mot eldre brukere, men man skal ikke se bort

ifra at applikasjonen kan utvide bredde horisonten ved å nå yngre brukere.

Selv yngre brukere som kanskje er tungt medisinerte, og har vansker med å ha

oversikt over medisinene deres kan ha nytte av applikasjonen.

IBM fortsetter med utviklingen fra vi slapp, det er gitt at applikasjonen kan endre seg

fram til presentasjonen, både med ny funksjonalitet og utseendet.

I slutten av utviklingsprosessen til IBM, vil de integrere vår applikasjon med deres

løsning.

Det ferdige produktet skal leveres til Sunnas Sykehus.

URL til applikasjonen https://ibm-personaal-webapp.mybluemix.net/

106

Vedlegg Nr 1 Kravspesifikasjon

Prosjekttittel IBM in the PersonAAL research project, EU Prosjekt i samarbeid med Sunnaas

Sykehus HF

Gruppemedlemmer Elisabeth Kongshavn s194524

Huebert Miguel Fabros s236358

Julian Refsland s236638

Intern veileder Thor E Hasle, Førstelektor

Kontor 67 23 86 69 - Email: thor.hasle@hioa.no

Oppdragsgiver International Business Machines AS

Rosenholmveien 25, 1414 Trollåsen

Tlf 66 99 80 00

E-mail: ibminfo@no.ibm.com

Kontaktperson

Loek Vredenberg, CTO og Technical Leder IBM Norway

Mob 92 83 81 33

Email: loek.vredenberg@no.ibm.com

107

Oppdragsgiver

IBM - International Business Machines, med virksomhet i over 170 land, opererer i

skjæringspunktet mellom teknologi, forretning og samfunn, og ønsker å bidra til å

kunne effektivisere og digitalisere bedrifter og industrier i Norge.

IBM har innovasjon og utvikling av nye løsninger som forstår, vurderer og lærer

basert på analyse av data som en viktig del av sin strategi, IBM leverer

bransjetilpassede, skybaserte og kognitive løsninger innen big data, analyse,

sikkerhet, mobilitet og samhandlingsverktøy

Oppgaven

Dette er et EU Prosjekt i samarbeid med Sunnaas Sykehus HF.

Sunnaas Sykehus HF er et forsknings sykehus med universitetsfunksjoner som har

spesialisert seg innen rehabilitering og er en del av Helse Sør-øst. I tillegg

samarbeider sykehuset med mer enn 200 kommuner i hele Norge. Sunnaas

Sykehus HF er veldig høyt ansett internasjonalt, og jobber på et innovasjonssenter

med Oslo Universitets Sykehus og kommunene rundt velferdsteknologi.

IBM ønsker å utvikle en løsning i samarbeid med Sunnaas Sykehus HF slik at eldre

kan utnytte tiden sin bedre og bo lengre i hjemmene sine med støtte av

webapplikasjoner.

Vi har fått i oppgave av IBM å lage et system som støtter bedre overholdelse av

medisinske resepter.

108

Forord Hensikten med kravspesifikasjonen er å beskrive applikasjonens funksjonalitet og

hvilke retningslinjer som er satt av arbeidsgiver. Kravspesifikasjonen vil også fungere

som en avtale mellom studentene og arbeidsgiver.

På denne måten sørger en for at sluttresultatet av applikasjonen blir som planlagt

mellom de ulike partene.

Eventuelle endringer i kravspesifikasjonen gjøres i samråd med arbeidsgiver.

Leserveiledning Kravspesifikasjonen er delt opp i en forklaring av hvordan systemet er bygget opp,

hvilke krav arbeidsgiver har satt for systemet og disse kravene er igjen delt opp i

funksjonelle og ikke-funksjonelle krav.

Systembeskrivelse Applikasjonen som skal utvikles er en webapplikasjon der man som ny bruker skal

ha muligheten til å opprette en bruker, logge inn, komme til personlig side, få en

oversikt over brukerens medisiner, få varsel om bruker har tatt medisinen. Data om

bruker, om medisiner som er blitt lagt til, tatt og endret på skal lagres i en cloudant

database.

Applikasjonen består av en frontend del og en backend del.

Oppbyggingen av applikasjonen skal være strukturert og enkel slik at andre aktører i

prosjektet skal kunne ha muligheten til å videreutvikle det.

109

Krav For å nå disse essensielle målene har vi satt opp en rekke funksjonelle og ikke-funksjonelle krav som blir beskrevet i de to tabellene nedenfor. Vi har valgt å kategorisere funksjonelle krav etter viktighet, de standardene vi har sortert etter er "Høy, Middels, Lav". Alle funksjonelle krav som har høy status er systemkritiske, og det er viktig at de blir fullstendig implementert. Alle funksjonelle krav som har middels status blir utviklet etter at alle funksjonelle krav med høy status er blitt implementert. Funksjonelle krav med lav status blir kun implementert om vi skulle få litt tid til overs. Ikke-funksjonelle krav er krav som angir kriterier for kvaliteter ved systemet. Kravene med lav prioritet har ikke blitt implementert.

110

Funksjonelle krav Krav til systemet. Prioriteres med høy, medium og lavt.

Nr Krav Prioritet

1 Bruker skal kunne logge seg inn Høy

2 Bruker skal få oversikt over medisinlisten sin Høy

3 Listen over medisiner skal være nøyaktig og med link til f.eks felleskatalogen

Høy

4 Data skal lagres i en cloudant-database Høy

5 Systemet skal deployes Høy

6 Bruker skal kunne få varsel om å ta medisinen sin til en gitt tid.

Medium

7 Applikasjonen må være responsive slik at det kan tas i bruk både på pc, tablet, telefon etc.

Medium

8 Brukeren skal kunne få en liste over sine “caregivers” Lav

9 “Caregiver” skal kunne legge til medisiner i kalenderen til gitt bruker de har tilgang til

Lav

Ikke-funksjonelle krav

Nr Krav Prioritet

1 Applikasjonen skal være tilgjengelig uavhengig av topologi Høy

2 Applikasjonen skal være sikker Høy

3 Appen skal kunne tilby påminnelse funksjon i form av notifications

Høy

4 Brukergrensesnittet skal være enkelt å navigere gjennom Høy

111

Rammebetingelser

● Data skal lagres i IBM Bluemix NoSQL Cloudant database. ● Data skal lagre sikkert i databasen. ● Applikasjonens backend skal kodes i javascript med bruk av rammeverkene

Node.js og Express.js ● Applikasjonens frontend skal utvikles med Angular 2. ● Bootstrap skal brukes for å gjøre applikasjonen responsiv på alle enheter. ● Kildekoden skal være strukturert. ● Kildekoden skal være på engelsk. ● Systemet skal være strukturert og følge MEAN-stack mappestrukturen.

Datamodeller

Figur 1: Microservice Calendar

112

Figur 2: Use case

Figur 3: Klassediagram

113

Krav til dokumentasjon Det skal enkelt komme frem av dokumentasjonen hvordan systemet er bygget opp, slik at det er enkelt å videreutvikle og vedlikeholde i fremtiden. Brukerdokumentasjon må også kunne anvendes som referanse for de ansatte i bedriften i forbindelse med opplæring i systemet, i tillegg til en generelt intuitiv oppbygging. Det skal komme klart frem av prosessdokumentasjonen hvilke utfordringer og valg gruppen har støtt på underveis i utviklingsprosessen, og hvorfor gruppen har tatt de enkelte avgjørelsene for å løse disse problemene.

114

Vedlegg Nr 2 Fremdriftsplan

115

Vedlegg Nr 3 Ordbok API er et slags grensesnitt som har et sett med funksjoner som tillater

programmerere å få tilgang til bestemte funksjoner eller data i et program,

operativsystem eller andre tjenester.

Apache CouchDB er database programvare som fokuserer på brukervennlighet og

har en arkitektur som fullstendig omslutter nettet. Den har en dokumentorientert

NoSQL database arkitektur og implementeres i språket Erlang.

Arrow-function ES6 har kortere syntax enn vanlige funksjonsuttrykk og er best

egnet som non-method-funksjoner, og de kan ikke brukes som konstruktører.

Autonomi er et fra et gresk ord der auto betyr «selv» og nomi som nærmest kan

oversettes med lov, regel. I internasjonal politikk refererer autonomi til en delstat,

provins eller region som har blitt gitt betydelig selvstyre i indre anliggender av

nasjonen området ligger under, se selvstyrt område.

Backend er hva som ligger bak, altså inne i systemer, og alle innstillinger som ikke

en vanlig deltager ser.

Backlog er en liste med oppgaver laget av Scrum teamet, som skal gjøres i løpet av

en sprint.

Backlog grooming er når produkteier, noen eller alle i teamet går igjennom

brukerhistoriene i backloggen for å sikre seg at backloggen inneholder de riktige

oppgavene, hvordan oppgaven er prioritert og at oppgavene er klare for levering.

BFF er backend for frontend.

Callbacks er en funksjon som passerer som et argument til en annen funksjon og

blir påkalt av et slags event.

Når den opprinnelige funksjonen er fullført, blir funksjonen som blir sendt som et

argument, kalt.

116

Collections er en generisk samling (array-lignende objekt som ligner på

argumenter) av elementer (i dokument rekkefølge) og tilbyr metoder og egenskaper

for å velge fra listen.

Commit brukes til å lagre endringer man har gjort.

Container er en container eller en beholder som inneholder rader med elementer.

Continuous Delivery Toolchain skaper en repeterbar, pålitelig og inkrementell

forbedringsprosess for å ta programvare fra konsept til forbruker. Målet med

kontinuerlig levering er å muliggjøre en konstant strøm av endringer i produksjon via

en automatisert programvare produksjonslinje.

Deployment er distribusjon, er alle aktivitetene som gjør et programvaresystem

tilgjengelig for bruk.

Front-end er hva som vises på siden for de som ikke er brukere av systemet. De

som er deltagere i en aktivitet vil kun se hva som er front-end

Grid klasser er klasser som “.row” og .”col-xs-4” og er tilgjengelige for å raskt lage

grid oppsett.

Grid-System er et rutenett system, for å kartlegge et sted for universell forståelse.

Et rutenett består av vertikale og horisontale linjer.

HTTP API sin hensikt er å støtte så mange som mulig med et API som er simpelt og

standard for hver av transportene.

IBM Bluemix Cloud Foundry App sikrer at bygge- og distribusjon aspekter ved

koding forblir nøye koordinert med eventuelle vedlagte tjenester, noe som resulterer i

rask, konsistent og pålitelig iterering av applikasjoner i produksjon.

117

IDE (Integrated development environment) er et program som gir omfattende

fasiliteter utviklere for programvareutvikling. En IDE består vanligvis av en kode

redigerer og en debugger.

Library (Node.js) er biblioteker som kan inneholde Bootstrap, Angular og andre

komponenter.

Mixin er er en klasse som inneholder metoder som brukes av andre klasser uten å

være foreldre klassen av de andre klassene.

Mixins er noen ganger beskrevet som inkludert, i stede for arv.

Open-source betegner kildekode som er gjort tilgjengelig.

Pipeline innenfor Continuous Delivery, er en automatisert manifestasjon av

prosessen for å få programvare fra versjonskontroll i hendene til brukeren.

Pixler/px er et av de mange små punkter som tilsammen utgjør en representasjon

av et bilde på en datamaskin. Vanligvis er punktene så små og så mange at når de

skrives ut på papir eller vises på en dataskjerm ser de ut som et jevnt bilde.

Product Manager eier visjonen og representerer interessentene og skal sikre at

Scrum-teamet til enhver tid jobber med de rette tingene sett fra et

forretningsperspektiv.

Promises ES6 objektet representerer eventuell fullføring (eller feil) av en asynkron

operasjon og dens resulterende verdi.

Public cloud eies og drives av selskaper som tilbyr rask tilgang over et offentlig

nettverk til rimelige databehandling ressurser. Med offentlige skytjenester trenger

brukere ikke å kjøpe maskinvare, programvare eller støtte infrastruktur, som eies og

administreres av tilbydere.

Pull er når du henter ned data fra et repository.

118

Push er når du dytter data opp til et repository.

Query er et form for ett spørsmål som sender en forespørsel om informasjon fra en

database.

Repository er et oppbevaringssted for lagring og deling av kode.

Retrospektiv er et møte som holdes av Scrum Master. Teamet diskuterer den nylig

avsluttede sprinten og bestemmer hva som kan endres og gjøre neste sprint med

produktiv.

Runtime-system implementerer primært deler av en utførelse modell. Dett er i

kontrast til kjøretidets livssyklusfase i et program, der kjøretid systemer er i drift.

Scrum Master er ansvarlig for at Utviklingsteamet lærer seg å selvorganisere, at

Produkteier forstår sin rolle og at samspillet mellom disse fungerer godt. Scrum-

master er ansvarlig for at man hele tiden forbedrer arbeidsformen og at

refleksjonsmøtene fører til forbedring. Om det er nødvendig må Scrum-master

beskytte

Scrum-møte er et møte som holdes i Scrum teamet.

Session Storage lagrer data for en session/økt. Dataen går tapt når nettleseren

lukkes.

SHA1-hash er en kryptografisk hash-funksjon. Resultatet er vanligvis uttrykt som et

160 bit hex-nummer.

Software as a Service refererer generelt til en ny og alternativ måte å få tilgang til

programvare, i motsetning til mer tradisjonelle metoder for tilgang.

Source-to-Source Compiler er en type kompilator som tar kildekoden til et program

skrevet på ett programmeringsspråk som sin inngang og produserer tilsvarende

kildekoden i et annet programmeringsspråk

119

Sprint er en tidsperiode i den smidige prosessmetodikken scrum, hvor det konkrete

arbeidet må fylles ut og gjøres klar til gjennomgang.

Stand-Up er et møte der deltakerne vanligvis deltar mens de står. Ubehaget for å

stå i lange perioder er ment å holde møtene korte.

SVG Scalable Vector Graphics (SVG) er et XML-basert filformat for markeringsspråk

som beskriver todimensjonal vektorgrafikk

Toggle-tip er en funksjon som blir aktivert når en gitt “action” blir foretatt, og toggle-

tipen gir råd eller tips.

Transpiler er en type kompilator som tar kildekoden til et program skrevet på ett

programmeringsspråk som sin inngang og produserer tilsvarende kildekoden i et

annet programmeringsspråk

UML står for Unified Modeling Language og er en industristandard for datarelatert

modellering.

Use Case er en beskrivelse av et system i form av «historier» om hva systemet skal

kunne gjøre. Eksempel: En bruker henter kakao fra maskinen.

User Stories, også kjent som brukerhistorier er en del av en smidig utvikling og

bidrar til å skifte fokus fra å skrive om krav til å snakke om det.

Alle smidige brukerhistorier inneholder en skriftlig setning eller to, og enda viktigere

en serie samtaler om ønsket funksjonalitet.

120

Vedlegg Nr 4 Litteraturliste

1. IBM Design Thinking (2016). IBM Design Thinking. I IBM Design. Hentet 30. mars 2017 fra https://www.ibm.com/design/thinking/

2. The Agile Movement (2008). The Agile Movement. I Agile Methodology.

Hentet 23. februar 2017 fra http://agilemethodology.org/

3. Box Notes (u.å.). Box Notes. I Box. Hentet 29. mars 2017 fra https://www.box.com/en-gb/notes

4. Github (2017). Github. I Github. Hentet 21. februar 2017 fra

https://github.com/

5. Facebook (2017). Facebook. I Facebook. Hentet 01. januar 2017 fra https://www.facebook.com/

6. Slack (u.å.). Slack. I Slack. Hentet 3. februar 2017 fra https://slack.com/

7. Google Drive (2017). Google Drive. I Google. Hentet 10. oktober 2016 fra

https://www.google.com/drive/

8. Hub Jazz (u.å.). Hub Jazz. I IBM Bluemix DevOps Services. Hentet 05. april 2017 fra https://hub.jazz.net/

9. IBM Bluemix (u.å.). IBM Bluemix. I IBM. Hentet 5. april 2017 fra

https://git.ng.bluemix.net/

10. Holt, S (2016). What is a cloud database?. I IBM Cloud. Hentet 13. mai fra https://www.ibm.com/cloud-computing/learn-more/what-is-cloud-database/

11. Enjoy Productive Java (u.å.). Enjoy Productive Java. I IntelliJ IDEA. Hentet

17. februar 2017 fra https://www.jetbrains.com/idea/

12. Visual Studio Code (2017). Visual Studio Code. I Microsoft. Hentet 17. februar 2017 fra https://code.visualstudio.com/

13. yEd Graph Editor (2017). yEd Graph Editor. I yWorks. Hentet 19. mai 2017 fra

https://www.yworks.com/products/yed

14. Visual Paradigm(u.å.). Visual Paradigm. I Visual Paradigm. Hentet 19. mai 2017 fra https://www.visual-paradigm.com/download/

121

15. Node.js(2017). Node.js. I Node.js. Hentet 13. februar 2017 fra https://nodejs.org/en/

16. Angular2(u.å.). Angular2. I Angular2. Hentet 13. februar 2017 fra

http://www.angular2.com/

17. Express(2016). Express. I Node.js. Hentet 13. februar 2017 fra https://expressjs.com/

18. Cloudant NoSQL DB(2017). Cloudant NoSQL DB. I IBM Bluemix. Hentet 13.

februar 2017 fra https://console.ng.bluemix.net/catalog/services/cloudant-nosql-db

19. JavaScript(u.å.). JavaScript. I Code School. Hentet 13.februar 2017 fra

https://www.javascript.com/

20. Typescript(u.å.). Typescript. I NPM. Hentet 13. februar 2017 fra https://www.npmjs.com/package/typescript

21. Mean(2014). Mean. I MEAN.IO. Hentet 13. februar 2017 fra http://mean.io/

22. HTML(2017). HTML. I MDN. Hentet 09. mai 2017 fra

https://developer.mozilla.org/en-US/docs/Web/HTML

23. Bootstrap(u.å.). Bootstrap. I Bootstrap. Hentet 13. februar 2017 fra http://getbootstrap.com/

24. CSS Tutorial(2017). CSS Tutorial. I w3schools. Hentet 09. mai 2017 fra

https://www.w3schools.com/css/

25. Standard ECMA-262(2016). Standard ECMA-262. I ECMA Standards. Hentet 09. mai 2017 fra https://www.ecma-international.org/publications/standards/Ecma-262.htm

26. What is the difference between JavaScript and ECMAScript?(2017). What is

the difference between JavaScript and ECMAScript?. I StackOverflow. Hentet 09. mai 2017 fra http://stackoverflow.com/questions/912479/what-is-the-difference-between-javascript-and-ecmascript

27. Babel is a JavaScript compiler(u.å.). Babel is a JavaScript compiler. I Babel.

Hentet 09. mai 2017 fra https://babeljs.io/

28. Hanson, J.(u.å.). Documentation. I Passport.js. Hentet 19. mai 2017 fra http://passportjs.org/docs

122

29. Chauhan, S.(2016). What is Web API and why to use it?. I DotNetTricks.

Hentet 19. mai 2017 fra http://www.dotnettricks.com/learn/webapi/what-is-web-api-and-why-to-use-it-

30. Ruluks, S.(2014). 9 basic principles of responsive web design. I FROONT.

Hentet 09. mai 2017 fra http://blog.froont.com/9-basic-principles-of-responsive-web-design/

31. Walter, S.(2013). Content is like Water. I Stephanie Walter. Hentet 16. mai

2017 fra https://www.stephaniewalter.fr/portfolio/content-is-like-water-illustration/

32. Henry, S.(2017). Web Content Accessibility Guidelines (WCAG) Overview. I

W3. Hentet 19. mai 2017 fra https://www.w3.org/WAI/intro/wcag

33. Interactive Diagram(u.å.). Interactive Diagram. I IBM. Hentet 03. mars 2017 fra https://www.ibm.com/devops/method/content/architecture/omnichannelArchitecture

34. Mutero, F.(2015). MEAN : One Language To Rule Them All. I LGIT. Hentet

21. mai 2017 fra https://lgitsmart.com/2015/02/25/mean-one-language-to-rule-them-all/

35. Mulloy, B.(2012). Web API Design: Crafting Interfaces that Developers Love. I

E-bok. Hentet 21.mai 2017 fra http://www.goodreads.com/book/show/13574087-web-api-design