Hovedprosjekt Høgskolen i Oslo og Akershus. Gruppe 4. Bachelor i Anvendt datateknologi

Transkript

1 Hovedprosjekt 2015 Høgskolen i Oslo og Akershus Gruppe 4 Bachelor i Anvendt datateknologi Vegar Norman, s Even Holthe, s Per Erik Finstad, s189138

2 Denne siden er blank med hensikt ifeel BEKK Consulting AS 2

3 PROSJEKTNR. 4 TILGJENGELIGHET Offentlig Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs Plass, 0130 Oslo Besøksadresse: Holbergs Plass, Oslo Telefon: Telefaks: BACHELORPROSJEKT HOVEDPROSJEKTETS TITTEL ifeel PROSJEKTDELTAKERE DATO ANTALL SIDER / BILAG 151 / 4 INTERN VEILEDER Vegar Norman Even Holthe Per Erik Finstad s189153@stud.hioa.no s189124@stud.hioa.no s189138@stud.hioa.no Knut Rolland rolknu@westerdals.no OPPDRAGSGIVER KONTAKTPERSON BEKK Consulting AS Christian Schwarz christian.schwarz@bekk.no SAMMENDRAG Verktøy for kvalitativ datainnsamling i forbindelse med utvikling av nye og eksisterende systemer. 3 STIKKORD ios JavaScript Kvalitative undersøkelser ifeel BEKK Consulting AS 3

4 Denne siden er blank med hensikt ifeel BEKK Consulting AS 4

5 Innholdsfortegnelse Innledning Kravspesifikasjon Produktdokumentasjon.. 21 Prosessdokumentasjon Testdokumentasjon Kildelister Dataordbok. 148 Vedlegg #1 Fremdriftsplan. N/A #2 Prosjektdagbok.. N/A #3 API-dokumentasjon. N/A #4 Prosessdokumentasjon fra interaksjonsdesigner. N/A ifeel BEKK Consulting AS 5

6 Innledning Forord Denne rapporten dokumenterer arbeidet og produktet som har blitt utviklet i forbindelse med hovedprosjekt i Anvendt Datateknologi ved Høgskolen i Oslo og Akershus, Rapporten består av flere enkeltstående deler som danner en helhet og har som mål å gi leseren innsikt og et fullstendig bilde av prosessen og systemet som er utviklet. Dokumenter er i særdeles grad rettet mot sensor og brukere (kunden) av systemet, men er åpent for alle interessenter som av ulike årsaker har interesse av innholdet. Vi vil benytte sjansen til å takke alle involverte for samarbeidet og uttrykke vår takknemlighet for at prosjektet har blitt så lærerikt som vi ønsket. Spesielt vil vi trekke fram vår veileder Knut Rolland, som har gitt oss utrolig innsikt i utviklingsprosessen, og også BEKK som ga oss muligheten til å få utfordre oss selv med et prosjekt av denne størrelsen, og ikke minst to faglig dyktige veiledere fra BEKK som har bidratt til større forståelse om hvordan det er å gjennomføre et prosjekt i et såpass stort selskap. Samtidig vil vi takke Kyrre Begnum for tilgang til Alto-skyen, samt familie og samboere som har utvist særdeles stor forståelse og tålmodighet mens hovedprosjektet har pågått. Leserveiledning Dokumentet er delvis strukturert i henhold til høgskolens dokumentasjonsstandard (Høgskolen i Oslo og Akershus [HiOA], udatert), men der det har vært naturlig har vi organisert de ulike rapportdelene noe annerledes, da vi har funnet det hensiktsmessig i forhold til lesbarhet og naturlig rekkefølge. Rapporten består av enkeltstående dokumenter for de ulike delene av prosjektet og kan således leses hver for seg, men for mest mulig innsikt og forståelse er det anbefalt å lese dokumentet i sin helhet fra start til slutt. Leseren kan oppleve at ulike temaer blir repetert på tvers av de ulike delene i rapporten, men dette har vi sett på som nødvendig da hver del skal gi mening i seg selv for interessenter som leser utvalgte deler. I tillegg til de spesifiserte dokumentene vi er pålagt å ha, har vi vært nødt til å legge til dokumentasjon på deler av prosessen vi mener det er vesentlig å få fram for å gi et fullstendig bilde av prosjektet. Det kreves ingen inngående kunnskaper i alle temaer som blir tatt opp i denne rapporten, men vi forventer at leseren har et visst teknisk grunnlag. Vi har tatt høyde ifeel BEKK Consulting AS 6

7 for at det allikevel kan være begreper og uttrykk som er særlig spesifikke i forhold til dette prosjektet, eller av andre grunner er ukjent for leseren. Vi henviser da til en felles dataordbok for hele rapporten. Se gjerne innholdsfortegnelsen for å finne frem til denne. Omtale av involverte personer I denne rapporten bruker vi ulike begreper for å omtale de personene som har arbeidet med eller vært involvert i prosjektet, og det kan være forvirrende for leseren å ha oversikt over hvem vi omtaler. Vi ønsker derfor å etablere noen begreper da dette er viktig for at leseren skal vite hvem som omtales, og dermed forstå rollefordelingen og hvem som har arbeidet med hva: Gruppe 4 består av Per Erik Finstad, Even Holthe og Vegar Norman. Disse personene har skrevet denne rapporten, har vært ansvarlige primært for utvikling og implementasjon, og omtales som gruppen i denne rapporten, og i noen tilfeller kun som vi eller oss. Noen steder brukes vi i stedet for gruppen. Gruppen har også måttet forholde seg til en fjerdemann underveis i prosjektperioden da BEKK ønsket å ha en interaksjonsdesigner involvert i prosjektet. Eirik Gihle, masterstudent ved Høgskolen i Gjøvik, har primært vært ansvarlig for design, interaksjonsdesign og grafisk utforming av produktet. Når vi refererer til alle fire som har arbeidet med prosjektet i denne oppgaven, omtaler vi dette som teamet eller prosjektgruppen. Vi har valgt å benytte disse bestemte begrepene for å unngå forvirringer i forhold til hvem som faktisk har arbeidet med hva, hvilke personer som har hatt ansvar for hvilke oppgaver, og så videre. Der det har vært vanskelig å benytte seg av disse begrepene på en konsistent måte har vi forsøkt å forklare dette best mulig underveis i rapporten. Når vi refererer til andre personer som har vært involvert har vi valgt å gjøre dette på følgende vis: Gruppen har skrevet hovedprosjekt for BEKK Consulting AS, og dette selskapet refereres til som oppdragsgiver eller kunde gjennom rapporten. I de tilfeller der vi refererer til oppdragsgivers egne kunder, har vi forsøkt å utdype dette på best mulig måte de steder der dette gjelder. Vi har fått tildelt Mattias Olovsson, senior interaksjonsdesigner og fagleder for tjenestedesign hos BEKK Consulting AS, som veileder for prosjektet. Han har også hatt rolle som produkteier/kunde og veileder i løpet av prosjektet, og refereres til som produkteier av denne grunn. I tillegg har Christoffer Marcussen, seniorkonsulent hos BEKK Consulting AS, vært vår tekniske veileder hos oppdragsgiver. Han refereres til som teknisk veileder i rapporten. ifeel BEKK Consulting AS 7

8 Gruppen har fått tildelt en intern veileder av Høgskolen i Oslo og Akershus; Knut Rolland som er lærer ved Westerdals Oslo School of Arts, Communication and Technology. Vi refererer til Knut som veileder i denne rapporten. I tilfeller der det har vært nødvendig å referere til Eirik Gihle, har vi valgt å gjøre dette ved å bruke uttrykket interaksjonsdesigner gitt hans rolle og funksjon i prosjektet. Bruk av ekstern kode i prosjektet Vi har brukt relativt store mengder programvare basert på åpen kildekode i prosjektet vårt for å oppnå ønsket resultat, og som en følge av dette ønsker vi å redegjøre for hvilken andel av koden i prosjektet som ikke er skrevet av gruppen. Vi ønsker samtidig å rette en takk til de utviklerene som har gjort sine verktøy og sin kode tilgjengelig for bruk til alle som ønsker det, og dermed indirekte hjulpet dette bachelorprosjektet. All kode i mappen /node_modules i backend og administrasjonspanel er lastet ned ved hjelp av pakkemanageren NPM. En liste over hvilke pakker som er tatt i bruk finnes i filen package.json i rotmappen til hver av komponentene. Vi har benyttet verktøyet CocoaPods for nedlasting av kode som tas i bruk i ios-applikasjonen. Denne koden lastes ned i mappen /Pods i ios-applikasjonen, og en liste over hvilke pakker som brukes finnes i filen Podfile i prosjektroten. Vi har benyttet Twitter Bootstrap til utforming av grensesnitt. Filene relatert til dette finnes i mappene /src/scss/bootstrap og /src/lib i administrasjonspanelet. Vi har benyttet AngularJS som MVC-rammeverk. Filene relatert til AngularJS finnes i mappen /src/lib i administrasjonspanelet. Vi har benyttet JQuery til enkle JavaScript-interaksjoner og -oppgaver. Dette biblioteket finnes i mappen /src/lib i administrasjonspanelet. Vi har benyttet et valideringsverktøy skrevet av Chris O Hara for enkel validering av inndata i administrasjonspanelet. Dette biblioteket finnes i mappen /src/lib i administrasjonspanelet. Vi har benyttet biblioteket angular-gravatar skrevet av Sebastian Wallin for enkel innhenting av Gravatar-bilder for brukere. Dette biblioteket finnes i mappen /src/js/vendor i administrasjonspanelet (filene angular-gravatar.js og md5.js ). Vi har benyttet biblioteket SweetAlert skrevet av Tristan Edwards for visning av dialogbokser i administrasjonspanelet. Dette biblioteket finnes i mappene /src/js/vendor og /src/scss/vendor i administrasjonspanelet. Vi har benyttet biblioteket UI Bootstrap for å lettere koble sammen AngularJS og Bootstrap. Dette biblioteket finnes i mappen /src/js/vendor i administrasjonspanelet. Det finnes også noe kode inline i de ulike prosjektene, som har egne kildereferanser i kommentarene. ifeel BEKK Consulting AS 8

9 Kravspesifikasjon Hovedprosjekt Gruppe 4 Høgskolen i Oslo og Akershus ifeel BEKK Consulting AS 9

10 Denne siden er blank med hensikt ifeel BEKK Consulting AS 10

11 Innholdsfortegnelse for kravspesifikasjon Presentasjon Om bakgrunnen Forord Leserveiledning Systembeskrivelse Rammekrav til systemet Sikkerhet API Roller ios-applikasjon Kapasitet Effektivitet Skalerbarhet Fremtidig utvidelse av systemet Bruk og brukervennlighet Funksjonelle og ikke-funksjonelle krav Brukerhistorier Krav til systemkonstruksjon Krav til dokumentasjon ifeel BEKK Consulting AS 11

12 Presentasjon Prosjektgruppen består av Per Erik Finstad, Even Holthe og Vegar Norman, alle fra studieprogrammet Anvendt datateknologi ved Høgskolen i Oslo og Akershus. Medlemmene har fordypet seg innenfor programmering og programutvikling gjennom studieløpet. Gruppen har tidligere jobbet sammen i andre fag. Som en del av prosjektet har også gruppen et eksternt medlem fra Høgskolen i Gjøvik, masterstudent Eirik Gihle, som fungerer som produkteier. Gruppens leder er Vegar Norman. Om bakgrunnen Prosjektet går ut på å gjennomføre en utviklingsoppgave for BEKK Consulting AS, der vi skal lage en løsning bestående av flere mindre deler, mer bestemt en mobilapplikasjon, en serverløsning med databasetilknytning og et webbasert administrasjonspanel. Utførelse vil skje over en periode på omtrent fire måneder, og gruppen har valgt en smidig utviklingsmodell. Andre kunnskaper som vil tas i bruk gjennom prosjektets gang er systemutvikling, prototyping, menneske-maskin interaksjon og universell utforming. Oppdragsgiver for oppgaven er BEKK Consulting AS (videre referert til som BEKK). BEKK er et norskeid konsulentselskap som gjennomfører prosjekter for store private og offentlige virksomheter innen strategisk rådgivning, utvikling av IT-systemer og design av digitale tjenester (BEKK Consulting, 2015). BEKK hadde i 2013 en omsetning på over 473 MNOK. Forord Hensikten med kravspesifikasjonen er å sette rammene for prosjektet, basert på hva oppdragsgiver og oppdragstaker har blitt enige om. Det skal også fungere som et dokument som sikrer at alle parter er inneforstått med hvilke rammer og betingelser som er satt og hva som kan forventes av det ferdige systemet. Kravspesifikasjonen skal også sikre at det ikke blir uenighet underveis om prosjektets omfang og/eller systemets funksjonalitet. Dokumentet er ment for alle av prosjektets interessenter, inkludert sensor og veiledere, og kan brukes til å få et raskt overblikk over systemet som utvikles. For oppdragstakerne har dokumentet fungert som et referansepunkt i arbeidet, for å sikre at utviklingen av det endelige produktet er i henhold til kundens ønske. ifeel BEKK Consulting AS 12

13 Leserveiledning Dokumentet er organisert i den hensikt at leseren raskt skal kunne sette seg inn i systemets funksjonalitet, struktur og rammebetingelser. For å få en større forståelse av hele prosjektrapporten kan kravspesifikasjonen gi leseren et overblikk av systemet som beskrives og være til hjelp til å forstå valg som er gjort i forbindelse med utviklingen. Dataordboken skal bidra til leserens forståelse av teksten og være til hjelp hvis leseren er ukjent med ord og uttrykk som hyppig blir brukt i prosjektrapporten. Se gjerne innholdsfortegnelsen for å finne frem til denne. Systembeskrivelse Det skal utvikles en applikasjon for ios-plattformen som oppdragsgiver skal kunne bruke for innhenting av data i forbindelse med andre utviklingsprosjekter. Dataene skal innhentes på lokasjonen til brukerne hvor de kan gjennomføre en test og gi spontane tilbakemeldinger i form av tilfredshet på forhåndsdefinerte punkter, eller definere egne punkter basert på deres opplevelse av tjenesten eller produktet de er med på å teste. Systemet består av tre deler: en ios-applikasjon et web-basert administrasjonspanel backend med et tilhørende RESTful-API ifeel BEKK Consulting AS 13

14 Applikasjonen brukes til innhenting av data for hver enkelt brukerreise. I administrasjonspanelet skal man kunne opprette nye brukerreiser og administrere disse. Dette innebærer blant annet redigering, publisering, legge til testpersoner, og se visualiserte data fra brukerreisene. Backenden består av en database håndtert av et API og fungerer som et bindeledd mellom applikasjonen og administrasjonspanelet. Rammekrav til systemet Sikkerhet For å forhindre tap, misbruk og ødeleggelse av data er det planlagt en rekke sikkerhetstiltak for samtlige komponenter. Når det gjelder kodebasen skal denne sikres ved opprettelse av private repositories på GitHub hvor oppdragsgiver krever at alle kontoer som er i bruk sikres med gode passord. Siden BEKK eier koden har vi også fått strenge restriksjoner på å ikke dele eller distribuere koden utenfor dette domenet. API Alle endepunkter i APIet skal gjennom to sikkerhetsbarrierer. Det første er OAuth 2.0 noe som krever at en bruker har autentisert seg med systemet før ytterligere aktivitet tillates. I tillegg autentiseres klienten som benyttes (administrasjonspanel/ios-applikasjon) mot en liste av forhåndsdefinerte godkjente klienter. Neste barriere er en rollesjekk for å avgjøre om den brukeren som har kalt på endepunktet har rettigheter til å utføre valgte handling. Det eneste unntaket er det å registrere brukere, da det ikke kan forutsette en brukerkonto i systemet. Alle passord blir enveiskryptert (hashet) med et unikt salt før de blir lagret i databasen. Roller I rollesjekken avgjøres det for eksempel om en bruker har tilgang til å utføre en gitt handling, f.eks. å endre undersøkelser eller andre brukeres passord. Har brukeren en administratorrolle, er dette tillatt, hvis ikke blir brukeren avvist. På nåværende tidspunkt er det ikke planlagt å kunne utføre rolleeskalering fra systemet, så kun forhåndsdefinerte administratorer skal ha tilgang til administrasjonspanelet. Dette minsker da også sårbarheten for at andre skal kunne eskalere sine normale brukere til å bli administratorer. ifeel BEKK Consulting AS 14

15 ios-applikasjon Når en bruker logger på systemet, blir de spurt om brukernavn og passord. Disse opplysningene sendes til server (som i produksjon vil bruke HTTPS). Server returnerer to engangskoder med ulik funksjonalitet og varighet og disse to lagres sikkert i systemets nøkkelring. Dette gjør at hvis brukerens enhet skulle bli stjålet/mistet finnes ikke kombinasjonen av brukernavn/passord lagret noe sted på systemet. Ved utlogging fjernes disse to unike engangskodene fra brukerens nøkkelring permanent. Fra systemets side er det også en rekke sikkerhetsmekanismer bygget inn. ios-applikasjonen kjøres i en sandbox. Med denne isoleringen hindrer det at andre applikasjoner kan få tilgang til ifeel-applikasjonen og vice versa. Kapasitet Effektivitet Vi ønsker i så stor grad det er mulig å etterleve såkalte best practices for hvordan lage et system som er så effektivt som mulig. Dette innebærer bl.a. å sørge for riktig indeksering av databasen, skrive effektive algoritmer, minimere respons- og lastetid og velge tredjepartsløsninger med omhu. Skalerbarhet I samråd med oppdragsgiver er det besluttet at utvikling skal skje mot Herokus skytjenester. Tilstand lagres i en MySQL-database og filer vil lagres i Amazon S3. Denne arkitekturen gjør det lett å produksjonssette nye funksjoner og feilrettinger, samt skalere horisontalt (skalere ut) ved å legge til flere noder som kjører programvaren. Dette gjelder både for APIet og administrasjonspanelet. Skaleringen kan gjøres på svært få minutter, både ut og inn. ios-applikasjonen er avhengig av APIet og skaleringen foregår i skyen. Hvis man skalerer ut APIet, fører dette til lavere responstid fra APIet som igjen fører til en bedre brukeropplevelse. Fremtidig utvidelse av systemet Systemdesignet blir planlagt så modulært som mulig. Dette gjelder samtlige komponenter i systemet, nettopp med tanke på at det etter all sannsynlighet blir gjennomgått og omskrevet/utvidet før det blir produksjonssatt av oppdragsgiver. Det er også mulig senere å bytte ut MySQL-databasen i backenden med en annen SQL-basert relasjonsdatabase, hvis oppdragsgiver ønsker dette. ifeel BEKK Consulting AS 15

16 Bruk og brukervennlighet Vi ønsker å ha et så brukbart og brukervennlig system som mulig. Her vil fokuset hovedsaklig være på de to brukersentrerte komponentene: administrasjonspanelet og ios-applikasjonen. I samråd med interaksjonsdesigneren ønsker vi å ha et administrasjonspanel med god brukbarhet og som følger good practice for webapplikasjoner. For ios-applikasjonen tar vi utgangspunkt i velrenommerte Apples Human Interface Guidelines (HIG), som er et sett med retningslinjer for brukervennlighet og gode brukeropplevelser, og har forsøkt å følge disse så langt det har latt seg gjøre. I tillegg skal applikasjonen være native (man programmerer direkte mot plattformen i stedet for å bruke tredjepartsverktøy). Dette i seg selv skaper en god brukeropplevelse da applikasjonen oppfører seg på samme måte som applikasjonene som følger med telefonen, i motsetning til noen applikasjoner som oppfører seg som websider. Funksjonelle og ikke-funksjonelle krav Brukerhistorier I starten av prosjektet ble det utarbeidet en rekke brukerhistorier som skal dekke systemets funksjonelle og ikke-funksjonelle krav. Disse brukerhistoriene er utarbeidet basert på hva de ulike brukerene av systemet skal kunne gjøre, uten å ta hensyn til teknisk oppdeling av komponenter og lignende. Brukerhistoriene er utarbeidet av interaksjonsdesigner i samråd med oppdragsgiver, og fremstår i rapporten slik de ble oversendt gruppen. Som... ønsker jeg å... slik at... Akseptansekriterie Admin opprette en test brukeren kan motta ønsket test At admin oppretter og sender en test til korrekt bruker, at bruker mottar test og kan åpne den Admin Legge inn forhåndsdefinerte testpunkter Bruker kan respondere på ønskede testpunkter At admin setter opp en liste med testpunkter og at bruker mottar dem Admin Lage en skala basert på følelser Bruker kan rangere At bruker responderer på en ifeel BEKK Consulting AS 16

17 testpunkter etter hvor fornøyde de er likert-skala med ulike følelsesladde pictogramer som indikerer ansiktsuttrykk etter hvor godt man liker testpunket, og at admin mottar korrekt svar Admin Definere tidspunkt for testperioden Bruker vet hvor lang tid han/hun har på å utføre den En oversikt over dagens dato og sluttdato Admin legge til ønskede testpunkter underveis i en testperiode Kundereisen kan skaleres etter behov At admin sender et nytt testpunkt og bruker får varsel om at et nytt testpunkt er opprettet Admin Legge til ulike testeres navn Tester mottar en personlig hilsen før test starter En velkomsthilsen med navn som stemmer med mottager Admin Sende ut en kode for å aktivere en test Bruker kan logge inn på ulike tester basert på egne koder for hver test Bruker mottar kode som tastes inn i et velkomstfelt og korrekt test åpnes Bruker At bruker kan stenge en test halvveis, for så å fortsette i en annen Bruker kan ta testen uten å måte fullføre den i en handling Kunne stenge og åpne en test, men komme inn igjen på siste spørsmål som var aktivt før den ble lukket Admin sende testen til flere ulike testere fra en liste Admin kan motta en mailliste og sende automatisk ut til bruker Fra en mailliste går det informasjon sømløst til brukers enhet som varsler med et pushvarsel om at ny test er opprettet Admin At man kan endre rekkefølge på testpunkter som vil sjekkes Man kan være mer fleksibel i kundereisen Fra en liste må man kunne dra og slippe for å endre en rekkefølge Bruker At bruker kan legge til et testpunkt Bruker og kan tilføre nyttig informasjon som ikke admin kjente til At bruker kan legge til et nytt treffpunkt og loggføre data i form at tekst ifeel BEKK Consulting AS 17

18 Admin få en oversikt over antall testere, antall svar... Admin kunne generere en pdf eller annen form for fil som enkelt kan deles på mail eller legges direkte inn i en rapportmal...anvarlig hele tiden har kontroll på hvor mye data som er innsamlet i forhold til ønsket mengde slik at innsamlet data kan spres enkelt til ønskede mottagere En oversikt som hele tiden oppdateres automatisk ettersom antallet endres En oversikt over treffpunkter og score, samt annen tekst innsamlet av bruker Bruker Legge til data som bilde, film, lyd og tekst i sin loggføring av et testpunkt Berike innsamlet data Muligheter for å sortere ulike data i en innsamlingsfase Admin få et resultat av ulike data på en oversiktlig måte slik at man sparer tid på å kjøre analyser i andre eksterne programmer Genereres en kundereise med ulik behandling av komplekse data: bilde/lyd, etc. Bruker Lage avatar av seg selv før man logger inn på en test Opplevelsen av å delta føles mer individuell Mulighet for å pimpe et pictogram av et menneske: kle på med ulik hår osv. Bruker Kunne lagre og sende melding fra sin avatar til andre venner For å få venner til å delta i testen. Mulighet for en chattefunksjon mellom avatar i form av delta på denne testen og vinn Admin Legge til GPS i sin test En test kan varsles til bruker dersom bruker befinner seg i et område som skal testes mottagere At bruker mottar pushvarsel når vedkommende er nært et testpunkt Admin Få et rikt oversiktsbilde eller kart av innsamlet data Man lettere kan generer svar ut fra innsamlet data At man kan zoome inn i svarene for å grave dypere etter detaljer Admin Genere en kode og sende ut Gi bruker en gevinst Generer en kode i form av penger /gavekort. ifeel BEKK Consulting AS 18

19 Krav til systemkonstruksjon Disse kravene er utformet av gruppen og oppdragsgiver i fellesskap. Backend-komponenten skal skrives i Node.js med MySQL som databasemotor Administrasjonspanelet skal skrives i AngularJS ios-applikasjonen skal være skrevet i Swift Web-komponentene skal kunne kjøre hos Heroku Det skal brukes Git som versjonskontrollsystem for kildekoden utviklet i dette prosjektet Krav til dokumentasjon Oppdragsgiver har ikke stilt noen krav til dokumentasjon. Vi har allikevel valgt å dokumentere APIet som har blitt produsert. Bakgrunnen for dette er at anvendeligheten for et API ofte kan måles på hvor godt det er dokumentert; et veldokumentert API vil være enkelt å ta i bruk for andre utviklere og gjør at man kan lese dokumentasjonen framfor å lete i koden for å finne ut hvordan ulik funksjonalitet fungerer. Hvis det på et senere tidspunkt skal lages en klient for andre plattformer kan disse fritt kommunisere med APIet, og i et slikt tilfelle vil dokumentasjonen være avgjørende for produktiviteten i utviklingen. Dette sikrer også at utviklere bruker den korrekte måten å interagere med tjenesten på, slik at underliggende implementasjon kan endre seg uten konsekvenser for tredjepartsutviklere. ifeel BEKK Consulting AS 19

20 Denne siden er blank med hensikt ifeel BEKK Consulting AS 20

21 Produktdokumentasjon Hovedprosjekt Gruppe 4 Høgskolen i Oslo og Akershus ifeel BEKK Consulting AS 21

22 Denne siden er blank med hensikt ifeel BEKK Consulting AS 22

23 Innholdsfortegnelse for produktdokumentasjon API- og backenddokumentasjon.. 25 Forord Innledning.. 25 Systemarkitektur.. 26 Logisk datamodell Systemkrav Installasjon og vedlikehold Modifisering Filstruktur over de viktigste filer/mapper. 28 Brukerveiledning.. 29 Feil og rettingsmuligheter.. 30 Administrasjonspanelet.. 31 Hensikt Valg av teknologi Teknologiske utfordringer og problemstillinger 34 Håndtering av sikkerhet gjennom en proxy i Express HTTP-interceptorer og tilgangsnivåer i AngularJS. 38 Modulære stilark ved hjelp av Sass Utforming av utviklingsmiljø Asset pipelining og automatisering i Gulp.. 41 Utrulling til produksjonsmiljø.. 44 Design og utforming.. 45 Skjermbilder med forklaring Kjente feil og mangler ios-applikasjonen Hensikt Valg av teknologi Utforming av utviklingsmiljø Teknologiske utfordringer og problemstillinger.. Xcode.. 64 Swift Kunnskapsmangler.. 65 Utrulling av testversjoner til brukere. 65 Design og utforming.. 65 Kjente feil og mangler Skjermbilder med forklaring Innlogging Registrering ifeel BEKK Consulting AS 23

24 Testliste Delta i en test med testkode Se nye invitasjoner Akseptere en invitasjon Vise sidemenyen Vise aktiviteter i en test Legge til egendefinert aktivitet Besvare aktivitet Legge til bilde/video til en besvarelse. 73 Brukermanual for ifeel Forord Ord og uttrykk vi bruker.. 75 Test.. 75 Aktivitet Følelsesskala. 76 Beherskelsesskala. 76 Trinnvis skala Administrator Testperson.. 77 Invitasjon. 77 Aktiveringskode.. 77 Hva gjør administrasjonspanelet? Hvordan bruker jeg administrasjonspanelet?. 78 Lage en ny test Publisere eller avpublisere en test Redigere en test.. 79 Invitere nye brukere og fjerne brukere fra en test Hente aktiveringskode Eksportere og laste ned innsamlede data 80 Opprette en ny bedrift.. 80 Opprette en ny administrator.. 80 Hjelp, noe er galt med administrasjonspanelet!. 80 Hva gjør ios-appen? 81 Hvordan bruker jeg ios-appen?. 81 Registrere en bruker Delta i en test Besvare aktiviteter Redigere aktivitetsbesvarelse Legge til egne aktiviteter.. 82 ifeel BEKK Consulting AS 24

25 API- og backenddokumentasjon Forord Denne dokumentasjonen er laget for å gi en innføring i bruk av APIet som serverer applikasjonens administrasjonspanel og den tilhørende ios-appen. Det forutsettes at leseren er kjent med produktet ifeel, systemets rammer og hva produktets bruksområde og konsept er. Selv om APIet er skrevet i Node.js, forutsettes det i utgangspunktet ikke noen kunnskaper om JavaScript/Node.js for å ta selve APIet i bruk, da det stort sett følger vanlige RESTful-prinsipper. Det er dog nødvendig med JavaScript-kunnskaper hvis backenden skal videreutvikles eller modifiseres. Brukerhåndboken er først og fremst skrevet for brukere som ønsker å benytte seg av APIets tjenester til bruk under utvikling av andre klienter, men også for systemadministratorer som skal installere og vedlikeholde applikasjonen. Første del av manualen vil fokusere på systemadministratoren, mens andre del vil inneholde dokumentasjon på selve APIet og hvordan dette kan konsumeres. Innledning Dette prosjektet har som mål å forenkle kvalitativ datainnsamling ved å tilby et funksjonsrikt verktøy for opprettelse av digitale tester (i enkelte tilfeller også kalt kundereiser eller brukerundesøkelser), og består av: En serverløsning for lagring av data på en trygg måte Et administrasjonspanel slik at BEKKs konsulenter på en enkel måte kan administrere eksisterende tester og opprette nye tester En ios-applikasjon som skal tas i bruk av testere, som gjør besvarelser på farten enkelt å håndtere. ifeel BEKK Consulting AS 25

26 Systemarkitektur Systemarkitektur for det leverte produktet Logisk datamodell ifeel BEKK Consulting AS 26

27 Systemkrav For å kjøre APIet trengs en servermaskin tilkoblet internett som andre enheter kan nå uten problemer. Vi anbefaler at denne serveren kjører Ubuntu Server eller en annen Linux-distribusjon av nyere art, med minst 1GB RAM og minst 1GB ledig harddiskplass. Serveren må ha installert Node.js, versjon eller en nyere versjon som er kompatibel med denne, og pakkehåndteringsverktøyet NPM, versjon eller kompatibel. Serveren må ha MySQL installert, versjon 5.5 eller kompatibelt, med tilgang til en database med brukernavn og passord. Vi anbefaler at APIet installeres og rulles ut ved hjelp av en PaaS-tilbyder, som for eksempel Heroku eller Linode. Vennligst kontakt en passende tjenestetilbyder for ytterligere informasjon. For epost utsendelse må tjenesten SendGrid benyttes, og for lagring av bilder og video må Amazon S3 benyttes. På sikt kan dette utvides, eller endres hvis ønskelig. Installasjon og vedlikehold Installasjonsveiledningen tar utgangspunkt i at du installerer APIet på en servermaskin der du selv utfører installasjonen. 1) Last ned eller kopier kildekoden til backend-komponenten og legg den på et passende sted. Vi anbefaler å installere til mappen /var/ifeel/backend. 2) Vi anbefaler at du kjører filen devsetup.sh dersom du installerer APIet lokalt på din datamaskin for testing. Merk at dette scriptet er laget spesielt for Mac OS X versjon og at scriptet ikke nødvendigvis vil fungere helt som tiltenkt på alle datamaskiner, da det er tilknyttet vårt utviklingsmiljø med JIRA. 3) Kjør kommandoen sudo npm install for å installere alle avhengigheter. 4) Sett korrekte miljøvariabler: a) DATABASE_URL : Korrekt utformet URL til MySQL-serveren på systemet. Eksempel: mysql://brukernavn:passord@host:port/database b) DATABASE_TEST : Sett til sqlite:// dersom du er i et utviklingsmiljø. c) NODE_ENV : Sett til development for utviklingsmiljøer og production for produksjonsmiljøer. d) _FROM_NAME : Navnet som kommer i fra-feltet i e-post som sendes. e) _FROM_ E-posten som kommer i fra-feltet i e-post som sendes. f) _SMTP_SERVER : SMTP-servernavnet som e-post skal sendes fra. g) _SMTP_PORT : Port som skal brukes ved oppkobling til SMTP-serveren. h) _SMTP_USERNAME : Brukernavn til SMTP-serveren. i) _SMTP_PASSWORD : Passord til SMTP-serveren. j) S3_BUCKET_NAME : Navnet på Amazon S3-bucketen der data skal lagres. k) S3_ACCESS_KEY : Tilgangsnøkkelen til S3. l) S3_SECRET_KEY : Den hemmelige nøkkelen til S3. ifeel BEKK Consulting AS 27

28 5) Kjør kommandoen node index.js for å starte APIet. Vi anbefaler at denne prosessen startes med et administrasjonsverktøy for Node-prosesser, som for eksempel PM2 eller Forever, slik at tjenesten ikke avsluttes ved feil eller advarsler. Applikasjonen trenger ikke noe spesielt vedlikehold da alle avhengigheter og pakker som er i bruk skal installeres i spesielle versjonsnumre, slik at oppdateringer ikke er nødvendig å gjennomføre. Vi anbefaler at Node.js, NPM og de ulike avhengighetene til ifeel ikke oppdateres med mindre dette er strengt nødvendig og du har oversikt over hvilke feil som kan oppstå. Modifisering Systemadministrator står fritt til å endre APIet og modifisere det til sitt bruk. I denne delen vil selve arkitekturen av backenden gjennomgåes, for å gi leseren inngående forståelse, nok til å gjøre endringer og modifikasjoner tilpasset sitt bruk. Filstruktur over de viktigste filer/mapper For å konfigurere APIet er følgende mapper og filer de man først og fremst trenger. /ifeel-back /api /migrations /middleware /models.env app.js index.js package.json I API-mappen finner man JavaScript-filer som inneholder funksjonaliteten til endepunktene, definert i app.js. Vi har brukt SequelizeJS som et abstraksjonslag mellom backend og database. Dette betyr i prinsippet at man ikke skriver rene SQL-spørringer, men bruker et ORM for behandle data i databasen. SequelizeJS gjør at vi kan behandle tabellene i databasen som JavaScript-objekter noe som frigjør oss fra selve databasen og fritt kan endre databasetype (PostgreSQL, SQLite) uten å måtte endre koden. SequelizeJS har også støtte for transaksjoner, noe som sikrer integritet av data. Vi har organisert koden slik at alle spørringer som skal være en del av en transaksjon, ligger i mappen transactions. Sequelize støtter databasemigrasjoner. En migrasjon fungerer som en versjonskontroll for databasen. Det gjør det enkelt å utvide databasen i produksjon, samt å rulle tilbake endringer hvis det viser seg at noe gikk galt under utvidelse av databasen, da man har tilstanden lagret i denne filen. ifeel BEKK Consulting AS 28

29 Mappen models inneholder JavaScript-filer som representerer egenlagde objekter, som har hver sin tabell i databasen. Dette er filene som gjør tabellen om til JavaScript-objekter (og vice versa), og det er her selve abstraksjonen ligger, som gjør oss uavhengig av SQL..env-filen inneholder miljøvariabler. Denne filen kan endres hvis du f.eks har en database for testing og en for produksjon. Dette lar deg enkelt skifte mellom ulike miljøer, uten å sette alle miljøvariablene manuelt. Filen app.js er filen hvor applikasjonen kjøres fra og hvor man registrerer alle endepunkter i APIet. Denne filen sjekker miljøvariablen og her spesifiserer man også hvilken port applikasjonen skal kjøres på, med mindre miljøvariabelen PORT er satt. index.js er selve tilgangspunktet til applikasjonen. Her startes serveren og henter inn filer som trengs for å kjøre. For å starte serveren, kjør følgende kommandoer: node index.js package.json er kun en referansefil som peker på hvilke pakker applikasjonen trenger for å kjøre. Når man kjører kommandoen npm install leses denne filen, og alle pakker og deres avhengigheter installeres i applikasjonen. Denne filen bør helst ikke endres manuelt. Pakkene som er listet her blir installert i mappen node_modules. Legg merke til at i package.json er det to typer avhengigheter. devdependencies er pakker som kun trengs under utvikling, og ikke er nødvendige for at applikasjonen skal kjøres. For å installere en ny pakke, kjør kommandoen: npm install <pakkenavn> --save For pakker som kun skal brukes under utvikling, kan følgende kommando benyttes: npm install <pakkenavn> --save-dev Brukerveiledning Dette dokumentet omhandler backend-komponenten og det er derfor ikke noe tilhørende GUI. Administratorer bør sette seg inn i gjeldende filsystem før modifisering. For utviklere som ønsker å ta i bruk APIet finnes det dokumentasjon i rotmappen av applikasjonen. Denne dokumentasjonen er tilgjengelig som en HTML-side med eksempler ved å kjøre opp API-dokumentasjonen inneholder all nødvendig informasjon om endepunkter og hvordan man skal/kan bruke disse. ifeel BEKK Consulting AS 29

30 Feil og rettingsmuligheter Det vil tidvis oppstå en feil i loggene fra APIet, relatert til OAuth-pakken som brukes i utviklingsmodus ( NODE_ENV=development ). Denne feilen kommer hvis en bruker ikke har autentisert mot APIet i et kall hvor autentisering kreves. Denne har ingen påvirkning i forhold til systemets funksjonalitet. Feilen logges allikevel, og er derfor nevnt for å unngå misforståelser. Dersom en feil oppstår ved kjøring av APIet, vil APIet terminere seg selv. Dette betyr at det å kjøre APIet ved å kun kjøre i gang prosessen én enkelt gang vil være fatalt for alle brukere. Derfor anbefaler vi som tidligere nevnt bruk av et verktøy for å holde prosessen i live over lengre tid, som for eksempel PM2 eller Forever, slik at en feilet prosess automatisk kan startes opp på nytt. Dette er den beste måten å kjøre opp APIet på dersom det skal brukes i produksjon. Dersom feil oppstår anbefaler vi å undersøke loggene, og om nødvendig foreta en reinstallasjon av APIet for å løse problemet. ifeel BEKK Consulting AS 30

31 Administrasjonspanelet Hensikt Administrasjonspanelet er en av tre sentrale komponenter i den endelige leveransen, sammen med backend og ios-applikasjon. Administrasjonspanelet har en meget sentral rolle for oppdragsgiverens ansatte, ettersom det er her de ferdige innsamlede dataene kan uthentes og nye tester kan skapes og sendes ut til brukere av ios-applikasjonen. Stakeholders er dermed: Oppdragsgiver som en helhet; dersom den ferdige løsningen er velfungerende og laget til ønskede spesifikasjoner vil BEKK kunne rulle ut kvalitative undersøkelser på en raskere og mer kostnadseffektiv måte, samtidig som videreutvikling av løsningen på sikt vil være mulig dersom ytterligere funksjonalitet ønskes. Oppdragsgivers brukere av komponenten (kalt administratorer), ettersom disse vil være sluttbrukerne av administrasjonspanelet. Dersom det er problemer med funksjonalitet eller interaksjon her, vil dette fremstå som lite intuitivt og vanskelig i bruk, og dermed være til problem når nye tester skal rulles ut eller data skal hentes. Oppdragsgivers kunder, ettersom disse til syvende og sist vil bli påvirket av at nye verktøy tas i bruk. Dersom det nye verktøyet fungerer godt vil dette resultere i bedre innsamling av kvalitative data som igjen vil påvirke bruk av tid og ressurser ved datainnsamling. God datainnsamling vil resultere i at oppdragsgiver har et bedre grunnlag å ta beslutninger på i forhold til utvikling av nye og eksisterende løsninger. Utviklingen av administrasjonspanelet har foregått over lengre tid, og ble påbegynt relativt tidlig i prosjektet da ios-applikasjonen avhenger veldig av at administrasjonspanelet fungerer som tiltenkt; dette er nemlig det eneste verktøyet for å lage nye tester og invitere brukere. I starten av prosjektet ble det laget et sett med brukerhistorier som i stor grad var gjeldende for prosjektet som en helhet, og disse ble siden brutt ned til mindre brukerhistorier som gjaldt per komponent. Mange av disse brukerhistoriene var gjeldende for administrasjonspanelet, og over tid ble det laget flere brukerhistorier basert på hvilke endringer som ble gjort i konsept og prosjektet generelt. Basert på brukerhistoriene kunne vi kartlegge hvilken funksjonalitet som var nødvendig og ønsket; i tillegg hadde vi hyppige avsjekk og demonstrasjoner for oppdragsgiver og interaksjonsdesigner for å avgjøre den beste veien fremover. Etterhvert som vi kom utover i prosjektet kom vi raskt til at det var flere features vi ble nødt til å stryke fra prosjektet av ulike grunner: ifeel BEKK Consulting AS 31

32 Helt fra starten av prosjektet var det mye snakk om premiering eller belønning av brukere som deltok i de ulike testene. Dette ble til slutt skrinlagt da det ikke var noen klar måte å gjøre dette på, ei heller noen tidligere eksempler på hvordan premiering var gjort i forbindelse med datainnsamling fra oppdragsgivers side. I noen designiterasjoner var det foreslått bruk av bonuspoeng fremfor håndfaste premier, men ettersom innveksling av disse bonuspoengene var uavklart, valgte vi derfor å droppe dette fra listen over features. Forhåndsvisning av tester slik at administratorer kunne få se hvordan en publisert test ville se ut i ios-applikasjonen var også en planlagt feature, men ble til slutt droppet da det ikke var nok ressurser til å implementere dette på en god måte. Dette ble heller ikke prioritert av produkteier. Visualisering av innsendte data var også noe som ble snakket om på et veldig tidlig stadie i prosjektet, men ble til slutt droppet fra prosjektet av flere grunner. For det første så vi at det var heller lite tid til å implementere visualiseringer av data på en god måte; dette ville, gitt dataenes ukonsistente natur, ha krevd en større innsats for å finne en visualiseringsmetode som passet og gitt mening for administratorene. Til tross for at alle gruppens medlemmer har hatt faget Visualisering og kunne ha arbeidet med dette hvis behovet var meget presserende, ville det også ha spist store ressurser å implementere disse visualiseringene programmatisk. Oppdragsgiver hadde i tillegg gitt oss beskjed om at den viktigste funksjonaliteten var å kunne uthente rådataene i egne filer, og derfor ble visualiseringer nedprioritert. I tillegg tok det lengre tid enn planlagt å få avklart enkelte aspekter ved konsept og også å motta ferdige grensesnitt fra interaksjonsdesigner, slik at mer tid enn vi skulle ha ønsket gikk med på å avvente dette. Det er derfor flere faktorer som har spilt inn på denne beslutningen. Personalisering av invitasjoner og utsendte e-poster var også en feature som var planlagt, men denne ble skrinlagt da det ikke var ressurser til å implementere dette, og ei heller et veldig uttrykt ønske fra produkteier om at dette skulle være en del av den ferdige løsningen. Dette kan heller implementeres senere, da teknologien rundt er lagt opp for at dette er mulig. Utsendelse vi epostlister gjorde også personalisering vanskelig, da man ikke nødvendigvis vet navnet til mottakeren. Støtte for innsending og god visning av GPS-koordinater var også planlagt, men da dette ikke ble høyt prioritert av oppdragsgiver, ble dette skrinlagt relativt raskt når gruppen justerte prosjektets omfang. Det var i tillegg en del diskusjon rundt hvorvidt administrasjonspanelet skulle være tilpasset bruk på tvers av enheter og skjermstørrelser (responsivt design), og den umiddelbare tanken var at bruk skulle være tilpasset to typer skjermer: mobilskjermer og større skjermer (laptop-størrelse og større). Etter å ha kommet et stykke ut i prosjektet ble det deretter klart at dette ville bli droppet. Grunnen til dette var primært at måten administrasjonspanelet var laget på ville vanskeliggjøre bruk på enheter uten en god pekeenhet (mus eller penn), og at applikasjonens teknologi ikke umiddelbart er meget godt tilpasset bruk på mobile enheter. Det ble også ansett som ifeel BEKK Consulting AS 32

33 lite sannsynlig at det skulle være behov for å opprette nye undersøkelser på mobil eller nettbrett. Denne avgjørelsen ble tatt i samråd med oppdragsgiver. Valg av teknologi Tidlig i prosjektet tok gruppen en diskusjon på hvilke teknologier som skulle brukes i prosjektet, og da administrasjonspanelet ble tatt opp, ble det tidlig klart at vi ønsket å bruke et JavaScript-rammeverk for å lage en SPA (Single Page Application), ettersom dette ville gi ønsket grad av interaksjon og dynamikk. Dette ville også samhandle godt med backend-komponenten, som var avgjort at skulle skrives i Node.js og ExpressJS, da disse deler mange programmatiske konvensjoner, spesielt med tanke på objekttyper og datatyper. Etter å ha diskutert flere muligheter ble det til slutt bestemt at vi ønsket å benytte rammeverket AngularJS, da dette var noe enkelte gruppemedlemmer hadde hatt litt erfaring med fra tidligere. I tillegg innehar AngularJS en del funksjonalitet som var ønskelig, deriblant god støtte for asynkrone forespørsler mot REST-tjenester, mulighet for å sette opp prosjekter etter MVC-standarden som ofte finnes i større rammeverk, og også god bakoverkompatibilitet mot eldre nettlesere. AngularJS er et rammeverk som er skrevet av Google, og utvikles derfor aktivt. AngularJS tillater også bruk av ferdige komponenter på en enkel måte med dependency injection, noe som passer godt til videreutvikling og utvidelser av prosjektet på sikt. Vi vurderte andre alternativer til AngularJS, deriblant Backbone, Ember.js og React, men kom til at AngularJS var den løsningen som passet best til prosjektets omfang og natur, og krevde at vi skrev færrest komponenter fra bunnen opp på egenhånd. Backbone er også et godt alternativ, men ville da bety at mye logikk måtte skrives på egenhånd. I tillegg ønsket vi et rammeverk med toveis databinding, som vil si at modell og visning er tettere bundet opp til hverandre; en endring i den ene vil resultere i en umiddelbar endring i den andre. Dette er funksjonalitet Backbone ikke har innebygget, og derfor ble dette forkastet. Eksempler på hvorfor dette er ønskelig er for eksempel ved innsending av data fra et skjema; fordi visning og modell er bundet på denne måten, trenger ikke data å hentes inn før innsending. Dersom et skjema er bundet opp mot en modell som tilsvarer en modell som finnes i backend, for eksempel en test, vil AngularJS muliggjøre lagring eller oppdatering ved å kjøre en enkelt kommando programmatisk, for eksempel $scope.survey.$save(); eller $scope.survey.$update();, og dermed spare mye skriving av kode. Dette er i tråd med DRY-prinsippet (Don t Repeat Yourself), som vi har hatt ønske om å følge så tett som mulig i dette prosjektet. Vi valgte å avslå bruk av React, da dette i utgangspunktet kun vil fungere godt som en del av et større økosystem; React fokuserer kun på visnings-biten av et MVC-miljø, og ville derfor være ukomplett. Ember.js ble også avslått, primært fordi dette ikke var like moderne og hadde like stor grad av funksjonalitet som vi ønsket oss. Det skal riktignok merkes at Ember.js trolig ville ha fungert i prosjektet, og at vi trolig ville ha kommet i mål med dette; en del av beslutningen her ble tatt på bakgrunn av at vi ifeel BEKK Consulting AS 33

34 hadde noe kompetanse med AngularJS fra tidligere og dermed hadde mulighet til å gjøre læringskurven noe mindre gjennom prosjektets gang. Vi kom i tillegg raskt frem til at vi ønsket å bruke et ferdig rammeverk til å lage grensesnitt, og beslutningen falt raskt på Bootstrap, et meget utbredt og mye brukt rammeverk laget av Twitter, og som inneholder mange komponenter skrevet i CSS og JavaScript. Mye av grunnen til at vi ønsket å bruke et ferdig rammeverk var flerdelt; for det første handlet det om korrekt allokering av ressurser innad i gruppa. Det å lage et rammeverk for brukergrensesnitt ville kreve mye tid, spesielt for å få konsistens på tvers av nettlesere og enheter, og også mye tid for å lage design for alle komponenter som vi ville få bruk for. I tillegg ville bruk av en bredt brukt og akseptert løsning være med på å forhøye sluttverdien av produktet, med færre bugs og programfeil. Det finnes mange andre rammeverk i tillegg til Bootstrap, som blant annet Zurb Foundation eller Materialize. Vi valgte allikevel bruk av Bootstrap da dette integrerer veldig godt mot AngularJS med egne direktiver ved bruk av en bestemt pakke, noe som har resultert i at mindre kode har måttet skrives for at Bootstrap og AngularJS skal samarbeide. I tillegg til dette valgte vi å ikke bruke ren CSS for å lage administrasjonspanelets grensesnitt, men heller en preprosessor kalt Sass. Sass er et separat språk med mye større fokus på programmeringslogikk enn det som finnes internt i CSS fra tidligere av, deriblant med mulighet for bruk av variabler, løkker og valgsetninger, samt bedre støtte for modularisering gjennom funksjoner, placeholders og bedre importeringer. Ettersom Bootstrap finnes i Sass-format valgte vi bruk av dette, da dette medfører at vi kunne endre grensesnittet ved å endre variabler og funksjoner fremfor å gjennomføre endringer på tvers av flere tusen linjer med CSS-kode. Vi hadde et alternativ i å bruke LESS, en annen preprosessor for CSS. Dette valgte vi bort da LESS ikke har støtte for løkker, ikke like god støtte for modularisering og vi ved tidligere anledninger har opplevd at språket har enkelte bugs som ikke umiddelbart har noen gode workarounds. Teknologiske utfordringer og problemstillinger Valg av teknologi og plattform for administrasjonspanelet har naturlig nok medført enkelte teknologiske problemstillinger vi har måttet håndtere. AngularJS, i måten det er laget på, muliggjør modularisering i stor grad. Vi har derfor valgt å ha kontrollere og andre programfiler i hver sin separate fil, for å unngå store og uoversiktlige filer og sørge for at applikasjonen kan organiseres i en bedre logisk mappestruktur. En utfordring dette har medført har vært at vi har endt opp med svært mange forskjellige filer, deriblant 8-10 filer kun for biblioteker som skal brukes og nærmere 40 filer for de ulike komponentene i applikasjonen. Dersom vi hadde skrevet dette i et tradisjonelt kompilert språk som for eksempel Java, hadde ikke dette vært et problem fordi den resulterende programfilen kun ville lastes lokalt, men fordi administrasjonspanelet fungerer som en webapplikasjon skrevet i AngularJS, må alle ifeel BEKK Consulting AS 34

35 filene lastes inn hver gang de skal brukes. Under vanlige omstendigheter ville dette medført at flere titalls filer hadde måttet blitt lastes inn under kjøring av applikasjonen, og dermed også flere titalls HTTP-forespørsler, noe som ville medført større last for enheten som administrasjonspanelet skulle taes i bruk på, og lengre ventetider for brukeren, spesielt under forhold der internetthastigheten er lav eller ikke pålitelig med tanke på dekning. Vi hadde derfor behov for å se på hvordan vi kunne løse dette på best mulig måte. Vi hadde flere muligheter med tanke på denne problemstillingen: Alle applikasjonsfiler og biblioteker kunne ha blitt lastet opp på en CDN-tjeneste (Code Distribution Network) og bli hentet derfra, da et nettverk av servere med høy tilgjengelighet ville gjort lastetider kortere og tilgjengeligheten blitt høyere og mer pålitelig enn ved bruk av en server alene. Alle applikasjonsfiler og biblioteker kunne konkateneres og minifiseres, slik at applikasjonen kun ville ha lastet ned et fåtall større filer fremfor et flertall mindre filer, og dermed resultere i mindre lastetid og færre HTTP-forespørsler. Vi kunne ha gått bort fra bruk av mange små filer og heller skrevet større applikasjonsfiler, og forsøkt å gjøre disse så oversiktlige som mulig for oss selv. Dette ville medføre mindre merarbeid med å forberede og opplaste filer, men mer frustrasjon i uoversiktlige applikasjonsfiler. Ettersom tjenesten kun skal brukes av BEKKs ansatte, og dermed ikke kan anses som kritisk med tanke på at nedetid ikke medfører fare for liv, helse eller varige materielle skader, kunne filer blitt lastet opp i sin normale tilstand uten noen form for optimalisering, og headere settes for å sørge for at filene ikke ble oppdatert i mellomlageret til nettleseren oftere enn årlig (far-out headers). En annen svært viktig problemstilling med tanke på at vi har laget en JavaScript-basert applikasjon, er sikkerhetsaspektet. Fordi JavaScript ikke er et tradisjonelt kompilert språk, er kildekoden tilgjengelig i filene som lastes til alle tider, noe som gir uvedkommede adgang til å undersøke applikasjonens oppbygning ved noen enkle klikk i nettleseren. Dette betyr at sensitiv informasjon ikke kan lagres i kildekoden til applikasjonen ettersom det er lett å undersøke denne. Autentiseringsmetoden vi har valgt å benytte i prosjektet som en helhet medfører lagring av to typer autentiseringsnøkler for at disse skal brukes for å få tilgang til data: Access tokens gis ut fra server, og brukes for å autentisere brukeren. Denne autentiseringsnøkkelen må gis ut med alle HTTP-forespørsler for å få tilgang til data fra server. Disse nøklene er kun gyldige i systemet i én klokketime. Dersom en access token har utløpt, kan komponentene hente en ny access token ved å bruke en refresh token. Dette er en helt separat autentiseringsnøkkel som, ved suksess, gir ut en ny access token som har gyldighet i én klokketime. I tillegg gis det ut en ny refresh token, slik at komponenten kan uthente nye autentiseringsnøkler senere. ifeel BEKK Consulting AS 35