SLUTTDOKUMENTASJON. Bachelorprosjekt Sammendrag. Karianne Løkke. Sofia Aittamaa. Petter Lysne

Transkript

1 SLUTTDOKUMENTASJON Bachelorprosjekt 2016 Sammendrag En Single Page Application (SPA) i form av en quizapplikasjon for Cappelen Damm Undervisning. Sofia Aittamaa Karianne Løkke Petter Lysne

2 PROSJEKT NR Studieprogram: Informasjonsteknologi TILGJENGELIGHET Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo BACHELORPROSJEKT Offentlig Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL Quizapplikasjon for Cappelen Damm DATO ANTALL SIDER / BILAG 85/6 PROSJEKTDELTAKERE Karianne Løkke s Sofia Aittamaa s Petter Lysne s INTERN VEILEDER Thor E. Hasle OPPDRAGSGIVER Cappelen Damm Undervisning KONTAKTPERSON Espen Skovdahl Redaksjonssjef Realfag Espen.Skovdahl@cappelendamm.no Telefon: SAMMENDRAG En Single Page Application (SPA) i form av en quizapplikasjon for Cappelen Damm Undervisning. 3 STIKKORD AngularJS, NodeJS, ExpressJS Single Page Application (SPA) Læringsverktøy 2

3 Denne siden er blank med hensikt. 3

4 FORORD Denne sluttrapporten er inneholder all dokumentasjon som er utarbeidet i forbindelse med hovedprosjektet for bachelorprogrammet informasjonsteknologi våren Prosjektoppgaven er gitt av Cappelen Damm Undervisning og er vårt avsluttende hovedprosjekt for studiet informasjonsteknologi ved Høyskolen i Oslo og Akershus. Prosjektet går ut på å utvikle et digitalt læringsverktøy i form av en webapplikasjon. Webapplikasjonen skal være frittstående og kunne implementeres på nettsidene til oppdragsgiver, Cappelen Damm. Applikasjonen skal være en quiz-applikasjon, hvor lærere eller andre skal kunne utforme og delta på quizer, enten individuelt eller i fellesskap. Det vil også eksistere ferdige quizer tilhørende de forskjellige bokverkene til oppdragsgiver, f.eks. innenfor matematikk, naturfag og lignende. Målet for dette prosjektet har vært å kunne implementere applikasjonen i størst mulig grad, og legge til rette for enkel videreutvikling i fremtiden dersom oppdragsgiver skulle ønske dette. Det er ikke behov for mye kunnskap for å lese denne rapporten, men den inneholder noen tekniske ord innen JavaScript-utvikling som krever litt programmeringsforståelse. Skulle noe derimot være uklart finnes en ordliste med disse ordene vedlagt som vedlegg 5 i slutten av rapporten. Vi vil rette en stor takk til vår oppdragsgiver, Cappelen Damm, for hyggelige møter, en spennende oppgave og god veiledning under prosjektperioden. I tillegg vil vi takke vår interne veileder, Thor Hasle, som hjalp oss i gang med prosjektet, og var hjelpsom da vi var usikre rundt dokumentasjon og prosessen overfor skolen. LESERVEILEDNING Sluttrapporten er hovedsakelig rettet mot sensor og oppdragsgiver og er delt inn i følgende deler: - Presentasjon av prosjekt: Denne delen tar for seg bakgrunnen for prosjektet, oppdragsgivers situasjon, begrensninger, rammebetingelser og målet med prosjektet. - Prosessrapport: Prosessrapporten gir en grundig beskrivelse av utviklingsprosessen, planlegging, utviklingen og til slutt en kort vurdering av resultatet og sluttproduktet. - Produktrapport: Denne delen beskriver applikasjons oppbygning, backend og frontend. - Testdokumentasjonen: Testdokumentasjonen inneholder dokumentasjon på tester som er utført på applikasjonen. - Brukerveiledning: Brukerveiledningen beskriver hvordan applikasjonen fungerer. - Avsluttende del: Denne delen konkluderer og forteller om selve produktet, videreutvikling og gruppens læringsutbytte. - Vedlegg: Kravspesifikasjon, risikoplan, skisser, fremdriftsplan, ordliste og ord fra oppdragsgiver. 4

5 INNHOLDSFORTEGNELSE Forord... 4 Kapittel 1 - Presentasjon av prosjektet Leserveiledning Presentasjon Gruppen Oppdragsgiver Kontaktpersoner Oppgave Målgruppe Sammendrag Dagens situasjon Løsninger Analyse av virkninger Kapittel 2 - Prosessen Leserveiledning Forberedelser og planlegging Bakgrunn For prosjektet Utviklingsmetode og prosessmodell Arbeidsmetode Prosjektstyringsdokumenter Verktøy Teknologier Utviklingsprosessen Selvstudie fase (27 desember - 15 januar) Kartlegging av oppgaven og funksjonelle krav (25 januar - 1 februar) Kartlegging av databasebehov (1-4 februar) Utvikling av rest-api (4-18 februar) Utvikling av angular applikasjon (18 februar - 1 mai) Kravspesifikasjonen og dens rolle Endringer i kravspesifikasjonen Det endelige produktet

6 Kapittel 3 - Produkt Leserveiledning Middlertidlig nettadresse for applikasjonen Back-end Api Struktur och funktion Systemarkitektur Systemkrav Installation av programmet Säkerhet Front-End Struktur och funktion Utformning av användargränssnitt Kända problem med applikationen Lista över roller och funktioner Inloggninsdetaljer för adminkonto Besked till användaren Överenstämmelse mellan kravspecifikation och produkt Vidareutveckling Kapittel 4 - Testdokumentation Leserveiledning Användartester Användartest Användartest Användartest Konklusion av samtliga tester Kapittel 5 - Användarvägledning Leserveiledning Ord och Uttryck Användardelen Vad gör användardelen av applikationen? Hur använder man användaredelen? Deltagardelen Vad gör deltagardelen av applikationen? Hur använder man deltagardelen?

7 Kapittel 6 - Avsluttende del Leserveildning Sluttproduktet Læringsutbytte Hva ville vi gjort annerledes? Videreutvikling Hva er vi stolte av? Konklusjon Kildeliste

8 1 PRESENTASJON AV PROSJEKTET 1.1 PRESENTASJON Oppdragsgiver Prosjekttittel Oppgave Cappelen Damm Undervisning avdeling grunnskole Quizapplikasjon for Cappelen Damm Prosjektet går ut på å utvikle et digitalt læringsverktøy, som har som mål å gjøre det lett for lærere å opprette quizer relatert til fag, og samtidig gjøre læring lettere og morsommere for elevene. Applikasjonen kan også brukes til å vurdere elevenes måloppnåelse. Periode Gruppenummer 26 Gruppemedlemmer Karianne Løkke s Sofia Aittamaa s Petter Lysne s Intern Veileder Nettside Thor E. Hasle GRUPPEN Prosjektgruppen består av Sofia Aittamaa, Karianne Løkke og Petter Lysne. Samtlige er studenter på bachelorstudiet Informasjonsteknologi ved Høyskolen i Oslo og Akershus. 1.3 OPPDRAGSGIVER Hovedprosjektet skal utføres i samarbeid med Cappelen Damm Undervisning avd. Grunnskole som er en del av forlaget Cappelen Damm. Cappelen Damm eller CDU er det største undervisningsforlaget i Norge. De tilbyr læremidler i de aller fleste fag i grunn- og videregående skole og i voksenopplæringen. Blant læremidlene som CDU tilbyr finnes det en rekke digitale ressurser som lærere og elever bruker gjennom blant annet data, nettbrett eller mobiltelefon. Nettside: 8

9 1.4 KONTAKTPERSONER Veileder HIOA: Thor E. Hasle Epost: Telefon: Kontaktperson ved Cappelen Damm Undervisning: Espen Skovdahl Redaksjonssjef Realfag Epost: Telefon: OPPGAVE CDU ønsker et lærerverktøy i form av en applikasjon hvor lærere kan utforme quizer etter undervisning og fag. Det kreves at hver quiz skal kunne inneholde ubegrenset med oppgaver og at hver oppgave skal kunne ha minst to svaralternativer. Det må i tillegg være mulig å legge inn verkslogo i applikasjonen. Applikasjonen skal bestå av følgende oppgavetyper: video, bilde, lyd eller kun tekst. Det må være mulig for forfatteren av quizen å legge inn tekst, bilder, video eller lyd i oppgavene. De riktige svarene må kunne markeres som riktige av forfatteren. Oppgavene må nummereres fortløpende fra 1 og oppover. I tillegg må hver quiz ha sin egen ID, som benyttes for å melde seg på/ta en quiz. Et annet krav til applikasjonen er at det skal være mulig å bruke quizene på forskjellige måter, dvs. med ulikt antall deltagere. Det skal være mulig å benytte seg av quizen som én deltager, flere deltagere og i grupper. I tillegg skal det være mulig å skrive ut quizen på papir. Elevene svarer da individuelt, eller gruppevis. Hver elev, eller gruppe, får et skjema med oppgaver for avkryssing. Det skal være en administratordel hvor lærerne kan utforme quizen. Elevene kommer inn på den aktuelle quizen ved å skrive inn en quiz ID og så registrere navnet sitt. Hvis det er en quiz for flere deltagere må elevene vente på at læreren starter quizen, ellers kan elevene starte når de selv vil. 1.6 MÅLGRUPPE Målgruppen til applikasjonen er først og fremst lærere som bruker Cappelen Damms bokverk eller digitale læringsressurser i undervisningen. Applikasjonen er ment som et komplement til Cappelen Damms bokverk, da applikasjonen skal inneholde et biblotek med quizer, tilhørende hvert av verkene. Applikasjonen er ikke rettet mot en spesiell aldersgruppe når det gjelder de som skal ta quizene, men passer for elever og andre fra grunnskolen og oppover. Selvom applikasjonen i all hovedsak er rettet mot lærere som bruker Cappelen Damms bokverk, kan 9

10 applikasjonen også tas i bruk av andre som bare ønsker å lage og ta quizer. Applikasjonen trenger ikke bare å brukes i undervisnningssammenheng, men kan også brukes til å f.eks. lage quizer som er ment som underholdning. 1.7 SAMMENDRAG Vi skal under våren 2016 utvikle et digitalt læringsverkyøy i form av en webapplikasjon, i samarbeid med Cappelen Damm Undervisning (videre referert til som CDU). Applikasjonen skal være frittstående og kunne implementeres på nettsidene til CDU slik at lærere skal ha mulighet til å utforme quiz etter undervisning og fag. Målgruppen er først og fremst lærere som bruker Cappelen Damms bokverk eller digitale læringsressurser i undervisningen, men applikasjonen kan også brukes av andre som kun ønsker f.eks. underholdning. Vår veileder fra HIOA vil være Thor E. Hasle. Vår kontaktperson hos CDU er Espen Skovdahl som er redaksjonssjef for Realfag. Vi har fått en liste på hvordan CDU ønsker at quizen skal fungere men utover det så har vi i stort sett fått frie tøyler når det gjelder teknologier. Vi har valgt å utvikle applikasjonen på en Microsoft Azure database og teknologiene vi har valgt å bruke er NodeJS og Express JS for back-end, og AngularJS, HTML og CSS (Bootstrap) for front-end. Dette er i tilegg til øvrige open-source moduler tilhørende NodeJS og AngularJS under MIT lisens. 1.8 DAGENS SITUASJON Cappelen Damm Undervisning (CDU) tilbyr digitale ressurser og pedagogiske løsninger for læring på sine nettsider. På grunn av den konstante utviklingen av nye teknologier kreves det at disse ressursene fornyes eller at nye ressurser utvikles med tiden. Cappelen Damm benytter seg av eksterne IT-selskaper for å utvikle disse ressursene. Vi kom i kontakt med CDU via Ravn Webveveriet AS som utvikler slike ressurser og pedagogiske løsninger for Cappelen Damm. CDU ønsket seg en applikasjon i form av et quiz-verktøy som en ressurs på sine nettsider og gav oss derfor i oppdrag å utvikle en slik applikasjon. 1.9 LØSNINGER I denne seksjonen forklares det rundt våre valg av teknologier. FRONT-END AngularJS Til utvikling av front-end har vi valgt å bruke rammeverket AngularJS. AngularJS er et strukturelt open-source Javascriptrammeverk utviklet av Google. Rammeverket bistår med å kjøre single-page applikasjoner (SPA). Model-view-controller (MVC) er et designmønster brukt i programvareutvikling. Et MVC-program 10

11 deler programmet opp i data (model) og brukergrensesnitt (view), slik at endringer i brukergrensesnittet ikke vil ha noen innvirkning på hvordan dataene håndteres, og vice versa. Det brukes en mellomliggende komponent kalt $scope, for å knytte sammen view og controller. (Model view controller: Wikipedia, 2016) Modell-View-Controller konseptet AngularJS har som mål å forenkle utvikling og testing av moderne webapplikasjoner i form av SPA's (single-page applications), skille DOM (document object model) manipulasjon fra applikasjons-logikk, samt skille klient-side fra server-side. AngularJS flytter mye kode, som tradisjonelt har kjørt på server, over til klient. På denne måten reduseres belastning på serveren. Bootstrap Som CSS-rammeverk velger vi å bruke Bootstrap for konstruksjon av brukergrensesnitt og skjermbilder. Grunnen til at vi har valgt dette rammeverket er at det er et godt kjent i utviklingsmiljøet, noe som er med på å gjøre det enklere å videreutvikle applikasjonen ved en senere anledning. I tillegg er et av våre krav til applikasjonen er at den være responsiv ovenfor forskjellige skjermstørrelser, noe som enkelere kan oppnås ved bruk av Bootstrap. Sammendrag Administrasjonsdelen hvor lærerne skal utforme quizen skal ha et grensesnitt laget med Bootstrap. Det skal benyttes AngularJS for å følge klar MVC-arkitektur i applikasjonen og for å kommunisere med backendløsningen på en asynkron måte. Fordelen ved å benytte seg av AngularJS er at det sørger for å oppdatere brukergrensesnittet om den underliggende modellen endres ved hjelp av toveis binding mellom view og controller. Den ferdige løsningen blir en Single Page Application (SPA). Dette gjør at brukeren kun forholder seg til en HTML side og all interaksjon og data henting fra server foregår i JavaScript på klientsiden. 11

12 Fordelen med dette er at det blir mindre belastning på serversiden, og applikasjonen vil oppleves som mer responsiv og rask. I tillegg vil det også være lettere å videreutvikle applikasjonen ved en senere anledning til å støtte flere plattformer. En annen fordel med SPA, er at man hele tiden vil forholde seg til ett enkelt javascript memory-space. (10 Reasons Web Developers Should Learn AngularJS, 2014) BACK-END NodeJS NodeJS er en åpen kryssplattform runtime system for utvikling av server-side webapplikasjoner. Node er både et frittstående program og rammeverk for opprettelse av webservere og server-side kode. Det er utviklet i C++, og benytter Google sin V8 javascript motor for å kjøre javascript kode. (NodeJs, 2016) Vi har valgt å bruke NodeJS til å utvikle back-end fordi NodeJS kombinerer den svært raske JavaScript-motoren fra Chrome, V8, med et fullstendig asynkront I/O API, og reduserer kompleksiteten ved å skrive server-side API'er. NodeJS er også sentrum for et svært aktivt fritt kildekode-miljø. (Wikipedia, Node JS, 2016) ExpressJS ExpressJS er et server-rammeverk for NodeJS. Grunnen til at vi har valgt Express.js er fordi det forenkler jobben med å opprette en web-server og opprette RESTful API'er. (ExpressJS, ExpressJS, 2016) Database Vi kommer til å bruke MSSQL / SQL Server etter krav fra oppdragsgiver. MSSQL er en relasjonsdatabase som betyr at dataene er lagret i tabeller med rader og kolonner. Sistnevnte kan ha relasjoner til kolonner i andre tabeller, som sikrer integritet i dataene og eliminerer redundante data gjennom normalisering av tabeller. (Wikipedia, 2016) Sammendrag Løsningen blir et RESTful API. REST står for Representational state transfer, dette er en ny måte å bruke den eksisterende HTTP protokollen ved hjelp av for eksempel GET, POST og mer. REST gjør at alle komponenter koblet til et nettverk kommuniserer med hverandre via en delt felles kommunikasjonsprotokoll kjent som Hypertext Transfer Protocol (HTTP). (Rouse, 2016) Fordeler med denne løsningen er at det på denne måten oppstår et klart skille mellom de ulike lagene i løsningen, og ved å «frakoble» dem vil dette gjøre vedlikehold og videreutvikling lettere. En kan for eksempel kjøre API'et på en egen server, helt uavhengig av front-end serveren. Dette har utviklet seg til å bli en standard for back-end API'er, og det er på bakgrunn av dette at vi har bestemt oss for å gå for en slik løsning. I tillegg fungerer en slik løsning svært godt med en Single Page Applikasjons front-end. 12

13 1.10 ANALYSE AV VIRKNINGER Sammen har vi blitt enige om å benytte oss av disse teknologiene på bakgrunn av disse punktene: Hovedgrunnen til at vi har valgt å benytte oss av akkurat disse teknologiene er fordi de fungerer godt sammen. Dette er først og fremst fordi de bygger på hverandre og benytter seg av det samme språket, JavaScript. En annen grunn er at disse teknologiene er fremtidsrettede, noe som er viktig ved en eventuell videreutvikling av programmet. Læringsutbyttet fra hovedprosjektet er viktig. Samtlige i gruppen har lite erfaring med disse teknologiene og ønsker å lære mer. Open Source. At teknologiene er Open Source, begrenser kostnader, gir oss frihet og fleksibilitet, kvalitet og sikkerhet. Godt kjente teknologier. Godt kjente rammeverk og teknologier gjør det enklere å videreutvikle koden eller programmet ved en senere anledning. 13

14 2 PROSESSEN LESERVEILEDNING Prosessdelen gir en grundig beskrivelse av utviklingsprosessen, planlegging og utviklingen. Prosessrapporten inneholder følgene deler: - Planlegging og forberedelser: Denne delen gjør rede for planleggingen, verktøy og teknologi som ble benyttet, hvilken metode som ble brukt i arbeidsprosessen, utfordringer underveis, tilegning av ny og nødvendig kunnskap samt samarbeidet/forholdet med oppdragsgiver. - Utviklingsprosessen: I denne delen beskrives de ulike utviklingsfasene og faglige utfordringer som oppsto i utviklingen av prosjektet. I tillegg redegjør vi for valgene vi tok med hensyn på oppbygning, design, verktøy og funksjonalitet i programmet. - Kravspesifikasjonen og dens rolle: Beskriver viktigheten av en dynamisk kravspesifikasjon. I tillegg beskriver den om endringer som er gjort i kravspesifikasjonen underveis. Om kravspesifikasjonen samsvarer med det endelige produktet blir grundigere beskrevet i produktrapporten. 14

15 2.1 FORBEREDELSER OG PLANLEGGING I denne delen beskrives det hvordan vi planla utviklingen av prosjektet BAKGRUNN FOR PROSJEKTET Prosessen med å lete etter et passende bachelorprosjekt startet midten av høstsemesteret. I det første gruppemøte dannet vi oss en idé om hva slags type prosjekt vi ønsket å jobbe med og hvilke teknologier og verktøy vi ønsket å benytte oss av. Vi ble fort enige om å velge noe som var relevant til de fagene vi hadde hatt, men samtidig bruke nye og aktuelle teknologier. En slik løsning ville gi oss et godt læringsutbytte og samtidig utfordre oss ved at vi må lære oss en helt ny teknologi. Dette resulterte i at vi ville velge et prosjekt hvor programmeringsspråket JavaScript er sentralt, da JavaScript er et språk vi ikke har lært så mye om før, men som har hatt stor utvikling de siste årene og har blitt et veldig aktuelt. Spesielt så har rammeverkene AngularJS og NodeJS bidratt til å virkelig sette JavaScript på kartet. (Rowinski, 2016) VALG AV OPPGAVE I oppstarten av vårsemesteret var vi i kontakt med flere mulige oppdragsgivere, men vi fant fort ut at vi ville velge Cappelen Damm. Cappelen Damm hadde tilbudt oss å utvikle en quizapplikasjon som vil bli brukt av lærere og elever som bruker Cappelen Damms bokverk i undervisningen. Applikasjonen vil gjøre det enkelt for lærere å lage quizer, og bidra til at læringen blir mer spennende og lærerikt for elevene. Dette virket som et spennende og ikke minst givende prosjekt. De hadde i tillegg ingen konkrete ønsker med tanke på programmeringsspråk, så vi kunne benytte oss av JavaScript, noe som var et av våre ønsker helt fra starten UTVIKLINGSMETODE OG PROSESSMODELL I dette prosjektet stod vi fritt til å velge utviklingsmetodikk, dette var fordi vi først og fremst skulle arbeide adskilt fra oppdragsgiver. Helt fra starten av prosjektet var vi enige om at en smidig utviklingsmetodikk var det mest hensiktsmessige metoden for oss å bruke, da vi ville fokusere på våre viktigste mål og hva vi skulle gjøre for å oppnå disse. Vi mente derfor at smidig utvikling ville passe prosjektet vårt. I tillegg måtte vi i løpet av prosjektperioden forholde oss til endringer i ønsker og krav fra oppdragsgiver. I motsetning til typisk fossefallsutvikling, kan smidig metodikk håndtere uventede situasjoner på kort tid med minimale ressurskostnader. Faktisk er det nesten forventet at prosjektet endres i løpet av prosjektperioden. En av de mest populære og kjente smidige arbeidsmetode er Scrum. (Wikipeida, 2016) Vi valgte å benytte oss av Scrum under utviklingen av prosjektet. 15

16 SCRUM Scrum er en «agile» eller smidig metode for programvareutvikling (Brombach, 2016). Det som menes med at Scrum er en smidig metode er at Scrum må tilpasses settingen den skal brukes i, dvs. at man prioriterer de oppgavene som skal utføres først, og plukker så mange oppgaver som det er tid til ut i fra de ressursene du har tilgjengelig. Har man tid til overs plukker man nye oppgaver, eller tar oppgaver bort dersom man får for dårlig tid. Scrum-prosessen omfatter i utgangspunktet tre ulike roller: Produkteier, Scrum-master og Scrumteam. Produkteieren representerer gjerne kunden eller brukeren, og skal sikre at Scrum-teamet jobber med de rette tingene sett fra et forretningsperspektiv. (Brombach, 2016) I vårt tilfelle var dette vår kontakt i Cappelen Damm, Espen Skovdahl. Scrum-master forbereder prosessen ved å legge ting til rette for utviklerne. Utfører nødvendig forarbeid ved å sørge for at de har tilgang til verktøy og programmer som er nødvendig for utviklingen, og fjerner alt som står i veien for dem. (Brombach, 2016) I gruppen vår har Sofia fungert som Scrum-master. Den siste rollen i utviklingsmetoden er Scrum-teamet. Scrum-teamet består typisk av 3 til 9 personer med ulik kompetanse, for eksempel designere, utviklere og andre. Disse er ansvarlige for å gjøre selve utviklingsarbeidet og å levere produktet (Brombach, 2016). Dette teamet er i vårt tilfelle de resterende medlemmene av gruppen. Scrum baserer seg på det som kalles en «sprint». En sprint er en periode som typisk varierer mellom 15 og 30 dager. Et prosjekt deles opp i en eller flere sprinter, vanligvis av samme lengde. (Brombach, 2016) Vårt prosjekt består av 3 sprinter. Hver av disse hadde variende lengde ARBEIDSMETODE Gruppen jobber med en mer eller mindre flat struktur, hvor vi fordeler oppgavene jevnt mellom medlemmene. Det eneste unntaket er Sofia, som har fungert som Scrum-master i prosjektperioden. På bakgrunn av at vi er 3 studenter med 3 forskjellige deltidsjobber og arbeidstider, så fant vi tre fulle arbeidsdager i uka hvor vi kunne arbeide sammen på skolen, og valgte å bruke tirsdag, onsdag og torsdag til dette. Utover dette så har vi arbeidet med oppgaven alle øvrige dager der man selv ikke har hatt vanlig arbeid, med unntak av fredager som ble satt av til arbeid med øvrig(e) fag. Dette er et opplegg vi har fulgt gjennom hele prosjektet, med unntak av uker med enkelte helligdager eller andre grunner til å flytte eller avlyse arbeidsdager. Som sagt var det ingen utpreget leder av gruppen, og utfra sprintene vi satt opp, valgte gruppemedlemmene mer eller mindre selv hva de ønsket å jobbe med. Dette ble gjort fra dag til dag, på stand up-møter på morgenen, og ellers via chat. Om noen oppgaver så ut til å bli for vanskelige eller ta for lang tid å bli ferdig med, hjalp vi hverandre med å komme i mål. Denne arbeidsmetoden har fungert svært godt, og vi føler vi har hatt god flyt og effektivitet i arbeidet. 16

17 PARPROGRAMMERING Parprogrammering er en utviklingsmetode fra smidig (agile) systemutvikling der to personer jobber ved siden av hverandre på samme maskin. Forskning viser at den er spesielt nyttig for å løse krevende oppgaver og for mindre erfarne utviklere. Hovedgevinsten ved bruk av parprogrammering sammenlignet med soloprogrammering er økt kvalitet og redusert kalendertid for utvikling. (Beck, 2001) I løpet av prosjekttiden har vi møtt på utfordringer som har vært krevende, ofte innen emner ingen av oss har hatt noen erfaring med tidligere. For å gjøre dette mest mulig effektivt med minst mulig risiko med tanke på feil, valgte vi å sette oss i par for å løse mange av disse problemene. En slik form for parprogrammering fungerte veldig bra fordi vi kunne ut fylle hverandre med erfaringer og idéer, slik at vi kom frem til en best mulig løsning på problemet PROSJEKTSTYRINGSDOKUMENTER I løpet av prosjekttiden ble det opprettet dokumenter relatert til fremgangen i prosjektet. Dokumentene skulle være med på å sikre framdrift. Noen av disse ble utviklet under planleggingen, andre ble utviklet i løpet av prosjektperioden. Under beskrives dokumentene vi har opprettet. PROSJEKTSKISSE Dette dokumentet skulle skissere og presisere hva slags prosjekt vi hadde valgt å jobbe med. Vi utformet en prosjektbeskrivelse og en kort beskrivelse av oppdragsgiver. Videre skulle vi redegjøre for mulige krav til maskinplattform, dataverktøy og andre rammebetingelser. Kontaktinformasjonen til oppdragsgiver og kontaktpersonen i bedriften skulle også oppgis i denne skissen. I tillegg måtte vi gi hovedprosjektet en foreløpig tittel. DAGBOK OG MØTEREFERATER Etter hver dag vi jobbet ble det tatt notater om hva som ble gjort den dagen, når og av hvem, utfordringer/problemer gruppen møtte og hvordan de kunne bli løst. Notatene ble en slags dagbok for gruppen og har i tillegg fungert som hovedkilde for mye av prosessdokumentasjonen. I tillegg til dagboknotatene ble det laget egne møtereferater ved møter med veileder og oppdragsgiver. Disse er det skriftlige beviset på hva som er blitt sagt og bestemt på møtene, og var av den grunn mer utfyllende enn dagboknotatene. FREMDRIFTSPLAN Helt i starten av prosjektet ble det også satt opp en fremdriftsplan. Planen beskriver hva vi måtte arbeide med, når vi skulle arbeide med dette og dato vi skulle være ferdig. Det ble laget to versjoner, et ganttdiagram og et mer utfyllende skjema. Ganttdiagram ga et godt overblikk på hva som måtte arbeides med parallelt for å nå fristene og hvordan man lå an med hensyn på tidsbruk. Det andre skjemaet beskrev tydeligere hva som skulle gjøres og er vedlagt som vedlegg 3 til slutt i denne rapporten. 17

18 ganttdiagram RISIKOPLAN En viktig del av ethvert prosjekt er å bedømme risiko. Vi lagde derfor en risikooversikt over mulige risikoer som kunne påvirke prosjektarbeidet. Planen beskriver konsekvenser av at en mulig hendelse skjer, sannsynligheten for at hendelsen skjer, alvorlighetsgraden etter at en hendelse har skjedd og risikofaktoren. Risikofaktoren er summen av sannsynligheten og alvorlighetsgraden og har tre nivåer: lav, middels og høy. Etter tabellen kommer det forebyggende handlinger og tiltak som skal til dersom hendelsen skjer. Risikoplanen er lagt med som vedlegg 2 til slutt i denne rapporten. 18

19 2.1.5 VERKTØY Denne delen beskriver verktøyene vi har tatt i bruk under prosjektperioden. VERSJONSKONTROLL I prosjekter som dette hvor det er flere personer som utvikler, ønsker tilgang til å se og redigere filer samtidig er det nødvendig med gode rutiner og et godt versjonskontrollverktøy. Et Versjonskontrollverktøy er et system som holder styr på forandringer i en fil, eller et sett av filer, over tid, slik at du kan finne tilbake til spesifikke versjoner senere. (1.1 Komme i gang - Om versjonskontro: git-scm.com, 2016) GIT MED GITHUB Til denne oppgaven valgte vi å benytte oss av GitHub. GitHub er et populært distribuert kildekodekontrollsystem (SCM) som ble utviklet i 2005 av Linus Torvalds for utviklingen av Linuxkjernen. (Capgemini, 2016) Grunnen til at vi valgte nettopp GitHub, var fordi vi hadde erfaring med dette systemet fra tidligere og at GitHub på mange måter regnes som standard i bransjen. GitHub fungerer slik at når en fil oppdateres eller forandres, slettes ikke den gamle versjonen, men blir lagret i en database som inneholder tidligere versjoner av filene. På denne måten kan man hele tiden hente frem gamle versjoner, og man unngår å miste arbeid. GitHub tillater i tillegg at flere jobber på filene samtidig, noe som er essensielt når flere skal utvikle et program sammen. DROPBOX Sammen med GitHub brukte vi Dropbox til fildeling. Dropbox er en skytjeneste som synkroniserer filer mellom PC-er, nettet og mobile enheter. Programmet gir muligheten til å dele filer og mapper mellom brukere, og holde styr på hvem som har tilgang til disse dataene. Vi bruke Dropbox til å dele rapportdokumenter, bilder og annen relevant informasjon. PROSJEKTSTYRING I et prosjekt er det viktig å holde styr på oppgaver som skal gjøres, hvem som gjør hva og hva som har blitt gjort et prosjekt. Da kan det være greit og ta i bruk et prosjektstyringsverktøy. Vi benyttet oss av programmet Jira til å løse denne oppgaven. JIRA Som prosjektstyringsprogram gir Jira oss god oversikt over sprinter, user-stories, tasks og tidsbruk. Programmet er et flott verktøy å bruke i prosjektstyringsfasen. Det har et veldig intuitivt brukergrensesnitt, og er veldig responsivt ved at det oppdaterer seg fortløpende når en gjør endringer. Programmet regnes som en standard i bransjen for prosjektstyring. 19

20 Eksemplel på prosjektsttyring i Jira KOMMUNIKASJON Kommunikasjon mellom gruppemedlemmene, når vi ikke jobbet sammen på skolen, gikk i hovedsak igjennom Facebook Messenger. Kommunikasjon med veileder og oppdragsgiver gikk igjennom e- post. FACEBOOK MESSENGER Facebook Messenger er et Instant Message program utviklet av Facebook som gjør at personer kan kommunisere via private meldinger. Dette ble brukt av gruppen for å kommunisere når vi ikke var på samme sted. Programmet ble også brukt til å dele lenker til nyttige sider og annen god informasjon. E-POST E-post er et verktøy som tilbyr elektronisk kommunikasjon mellom en eller flere personer. I dette prosjektet ble e-post først og fremst blitt benyttet for kommunikasjon mellom gruppen og veileder, og gruppen og oppdragsgiver. I tillegg er det blitt benyttet når større filer ble delt med veileder, oppdragsgiver og ellers innad i gruppen. DOKUMENTASJON Det ble brukt ulike tekstbehandlingsprogrammer til å utvikle dokumentasjonen og rapportene. Vi benyttet oss av Google Docs når flere skulle skrive i samme dokument, slik at det var mulig å gjøre dette samtidig. Til å ferdigstille dokumentasjonen med innholdsfortegnelse, kilder, referanser og bilder o.l. benyttet vi oss av Microsoft Office Word. 20

21 GOOGLE DOCS Google Docs er et webbasert tekst-redigeringsprogram som ble brukt når flere gruppemedlemmer skulle skrive på samme dokument. Programmet gjorde det mulig for gruppemedlemmene å redigere dokumenter samtidig. MICROSOFT OFFICE WORD Microsoft Office Word er et tekstbehandlingsprogram. Vi har benyttet oss av dette programmet til å ferdigstille dokumentasjonen. UTVIKLING VISUAL STUDIO CODE Visual Studio Code er en IDE (Integrated Development Environment) som har blitt brukt til å utvikle kode i. Dette programmet gir en oversiktlig og god struktur på koden og byr på syntaksmerking, autocomplete, og IntelliSense. Sistnevnte fungerer som moduler/programutvidelser en kan installere som gir deg autocomplete for metoder/funksjoner mm. relatert til forskjellige programmeringsspråk og/eller rammeverk. Vi installerte IntelliSense for AngularJS og NodeJS for å forenkle arbeidet med å skrive kode. SQLPRO FOR MSSQL SQLPro er en Microsoft SQL Server-database klient, og gir rask og enkel tilgang til MSSQL servere, inkludert de som hosted via sky-tjenester som SQL Azure eller Amazon RDS. (Itunes, 2016) Programmet har under utviklingen blitt brukt til datamodellering og SQL utvikling. BROWSERSTACK Browserstack er en webapplikasjon som gjør det mulig å teste applikasjonen vår i forskjellige operativsystemer (mobil og desktop) og nettlesere. Dette er viktig å teste for å finne ut i hvilke operativsystemer og nettlesere applikasjonen vår støtter for å kunne gi beskjed om dette til brukeren, og utbedre evntuelle feil. POSTMAN Postman er et program som er utviklet for å teste API'er. Programmet gir en mulighet til å kjøre skreddersydde HTTP kall mot URL'er. Dette inkluderer da full kontroll over HTTP headers, content types osv. Ved hjelp av dette programmet, så er det ikke behov for noen implementert front-end for testing av RESTful back-end API'er. 21

22 2.1.6 TEKNOLOGIER Siden JavaScript har hatt såpass stor utvikling de siste 5 årene, med flere spennende rammeverk der ute, så var det mye å velge mellom. (Rowinski, 2016) Spesielt gjelder dette front-end, der du finner bla. AngularJS, ReactJS, BackboneJS, EmberJS mm. Alle med sine egne filosofier, arkitekturer, og fokus. For JavaScript på back-end, så har vi rammeverk som NodeJS, OPA, og CommonJS. Vi hadde fått relativt frie tøyler av Cappelen Damm til å velge de teknologier vi selv ønsket, med unntak av database, der de selv benytter MSSQL. Vi synes det ville vært spennende å lage en enkeltside applikasjon (Single-Page-Application eller SPA på engelsk), da dette var noe ingen av oss på gruppen hadde gjort tidligere. Ettersom AngularJS er utviklet med fokus på nettopp dette, så gjorde dette at valget falt på AngularJS som front-end rammeverk. ANGULARJS AngularJS er et rammeverk utviklet av Google, som gjør det enklere å utvikle enkeltsidede webapplikasjoner. (Wikipedia, Angular JS, 2016) Det vl si nettsider som kun lastes én gang, og hvor innholdet byttes dynamisk ut via AJAX kall i JavaScript. På denne måten senker man belastningen på serveren, reduserer mengden data som må lastes ved navigering mellom forskjellige sider, og applikasjonen vil oppleves som kvikkere og mer responsiv sammenlignet med en tradisjonell nettside. (Stackoverflow, Single Page Application: advantages and disadvantages, 2016) NODEJS NodeJS er et back-end rammeverk utviklet av Ryan Dahl, og senere sponset av Joyent. NodeJS gjør det mulig å enkelt opprette webservere, samt lage en fullstendig backend løsning i ren JavaScript. (Wikipedia, Node JS, 2016). Det kan også argumenteres for å være det mest populære back-end JavaScript rammeverket i dag, og NodeJS utviklere er ettertraktet i arbeidsmarkedet, som igjen var endel av bakgrunnen for vår beslutning om å benytte dette. (Rowinski, 2016) MEAN STACK Ved å kombinere disse to teknologiene, og gjerne også en såkalt nosql database som for eksempel MongoDB, så ender du opp med et utviklingsmiljø basert 100% på JavaScript. Denne kombinasjonen av teknologier kalles gjerne "MEAN" stacken (MongoDB, ExpressJS, AngularJS, NodeJS). Med andre ord en kombinasjon av teknologier som fungerer veldig godt sammen. (Mean.IO, 2016) ExpressJS er et rammeverk som bygger videre på NodeJS, og forenkler jobben med å lage en webserver og backend API, og er også noe vi har valgt å benytte. (ExpressJS, ExpressJS, 2016) 22

23 2.2 UTVIKLINGSPROSESSEN Denne delen av rapporten beskriver prosessen med å utvikle applikasjonen i ulike faser. Her vil vi ta for oss utfordringer ved enkelte funksjonaliteter og beskrive utviklingen SELVSTUDIE FASE (27 DESEMBER - 15 JANUAR) I første del av utviklingsprosessen hadde vi en selvstudie fase der vi gjennomførte kurs i JavaScript, AngularJS, og NodeJS på nettstedet Udemy.com. Dette er et nettsted som tilbyr videobasert undervisning. Vi meldte oss på 3 anerkjente og høyt graderte kurs, alle av samme foreleser: Disse kursene går grundig gjennom alle aspekter av nevnte teknologier enkel og forståelig måte. Å lære visuelt på denne måten var både veldig givende og interessant, og samtidig forkortet tiden vi måtte benytte på å sette oss inn i disse teknologiene Udemy kursene vi benyttet oss av KARTLEGGING AV OPPGAVEN OG FUNKSJONELLE KRAV (25 JANUAR - 1 FEBRUAR) I andre del av utviklingsprosessen begynte vi med å kartlegge selve oppgaven, og hvilke funksjonelle krav oppdragsgiver kunne tenke seg å ha med. Vi mottok et dokument fra Cappelen hvor de beskrev dette, sammen med hvordan de kunne se for seg at applikasjonen skulle fungere når det kom til deltakelse av quiz, opprettelse av quiz osv. Etter litt idémyldring og diskusjon rundt forslaget til Cappelen, hadde vi en kommunikasjon gående for å få oppklart noen uklarheter, samt at vi kom med noen forslag til forbedringer på enkelte punkter. Mer spesifikt så beskrev Cappelen: 23

24 "En elev a pner quizapplikasjonen, velger en quiz og «FLERE DELTAKERE». Opptil 5 deltakere til kan na koble seg pa denne quizen ved a ga inn pa quizapplikasjonen og registrere seg pa aktiv quiz ved a oppgi navnet sitt. Tidsbegrensning. Quizen startes av den som a pnet den og alle deltakerne gjennomfører den samtidig." Vi så det som mer intuitivt at hver quiz har sin egen ID, som elevene kan taste inn for å melde seg på den aktuelle quizen. På denne måten slipper elevene å måtte finne fram riktig quiz blant potensielt hundrevis av quizer Aktivitetsdiagram for å ta en quiz. Henvises til at brukeren kan avslutte quiz når som helst. Når det kom til quizmodus, så foreslo vi at læreren eller forfatter av quizen kan velge modus på quizen (Én eller flere deltakere). Ved modus for én deltaker, så går eleven inn på nettsiden, taster inn quiz ID, navnet sitt, og tar quizen uten tidsbegrensning. Ved modus for flere deltakere, så går elevene inn på quizen, taster inn sitt navn, og quizen startes så av læreren når hun/han ser at alle er klare. Forskjellen her blir altså i all hovedsak at læreren bestemmer når quiz med flere deltakere skal startes, og kan velge hvilken modus quizen skal tas i. På denne måten blir det mindre krevende for eleven å melde seg på en quiz, og hele løsningen blir mer fleksibel og intuitiv. Dette sa Cappelen seg enig i, og vi begynte deretter å utvikle en kravspesifikasjon, sammen med skisser av brukergrensesnitt. Sistnevnte ble gjort ved hjelp av en applikasjon kalt Balsamiq: Se vedlegg 4 for skisser KARTLEGGING AV DATABASEBEHOV (1-4 FEBRUAR) Etter at vi hadde laget en kravspesifikasjon måtte vi kartlegge hvilke databasebehov vi vil få. Hvordan databasen skulle bygges opp er i nær relasjon til hvilke funksjonelle krav som ble definert, samt hva slags informasjon som måtte lagres. Vi kom fram til at vi i utgangspunktet har behov for følgende: 24

25 - En quiz-tabell. Inneholder informasjon om quizen, som f.eks navn på quzien, hvem som har opprettet den, og hvilken modus den har på et gitt tidspunkt (felles eller inviduell). I tilegg til en unik quiz ID som identifiserer quizen, og som deltagere kan benytte for å melde seg på quizen. - En spørsmål-tabell. En quiz kan ha flere spørsmål, så er vi nødt til å skille dette ut i en egen spørsmålstabell dersom databasen skal være normalisert. Et spørsmål har en unik ID, spørsmålstekst, spørsmålstype som sier hvorvidt dette er en tekst, video, bilde eller lyd-spørsmål, samt et filnavn som benyttes dersom spørsmålet har bilde, video eller lyd knyttet til seg. Et spørsmål har en relasjon til en Quiz tabellen via en fremmednøkkel for quiz ID. - En svaralternativ-tabell. Et spørsmål kan ha flere svaralternativer, så har vi behov for en egen svaralternativtabell. Et svaralternativ må ha en unik ID, tekst, et BIT (true/false) felt som sier hvorvidt dette er det rette svaralternativet eller ei, og en fremmednøkkel til spørsmålet som svaralternativet tilhører. - En forfatter-tabell. En quiz tilhører en bruker, som må ha en konto og være logget inn på denne for å kunne opprette quiz, endre, slette osv. Vi trenger sådan en egen forfatter tabell. I denne tabellen har vi behov for å lagre epost, som vil fungere som brukernavn. I tilegg har vi behov for å lagre passord og salt. Passordet lagres som en 40 karakterers hash verdi, som er utarbeidet av å hashe passord og et tilhørende salt sammen. - En resultat-tabell. Til slutt har vi behov for å lagre resultater for en tatt quiz. Et resultat vil tilhøre en bestemt quiz, og har sådan en fremmednøkkel til denne via Quiz ID. Øvrig så har behov for å lagre navn på hvem som har tatt quizen, hvilket tidspunkt og dato den er tatt, og poengsum. Vi har også en fremmednøkkel til forfatter epost, da dette vil gjøre det lettere å liste ut alle resultater tilhørende en forfatter. Hvis vi skulle droppet dette, så hadde vi måttet hente resultater en gang for hver quiz som hører til brukeren, som potensielt kan bety flere titalls kall mot databasen kun for å hente ut alle resultater tilhørende den innloggede brukeren sine quizer. Det ble også brukt endel tid på problemstillingen for hvordan vi skal håndtere fil-opplastning. Skal vi lagre filene i selve databasen? På server? Skal brukeren kunne laste opp egne videoer? Etter å ha gjort litt undersøkelse på såkalt "best practice" når det gjelder filopplastning, så ble vi enige om å lagre filer på server, og filnavnet i databasen. For å kunne gjøre muligheten for bruk av video i spørsmål, så ble det valgt å benytte YouTube til dette. Bakgrunnen for dette valget var at denne løsningen er mer fleksibel, ettersom den byr på følgende fordeler: - Ferdig testet og stabilt økosystem for opplastning av video. Kan fremdeles laste opp egne videoer på sin egen brukerkonto hos YouTube, og linke til dem i quizen. - Behøver ikke opprette egne videoer, men kan i stedet benytte eksisterende videoer som allerede ligger på YouTube. - Reduserer stress på server, samt behov og bruk for lagringsplass. 25

26 Databaseskjema UTVIKLING AV REST-API (4-18 FEBRUAR) I denne neste delen av utviklingsprosessen begynte vi med utvikling av backend API. Kort fortalt, så gjør et API som er bygget på REST prinsippene følgende mulig: (Stackoverflow, What exactly is RESTful programming?, 2009) - Klienten behøver ikke vite noe om arkitekturen til API'et Annet enn å vite URL'en til API'et, så behøver ikke klienten å vite noe mer om API'ets arkitektur, oppbyggning, virkemåte, design osv. for å kunne benytte det. API'et leverer beskrivende URL'er for de handlinger man ønsker å utføre. - Benytter eksisterende HTTP verb/metoder for å utveksle data. Dette inkluderer i all hovedsak HTTP metodene GET, POST, PUT, DELETE. Hvilket av disse som benyttes i HTTP kallet mot API'et beskriver hvordan data skal utveksles. GET benyttes der en ønsker å hente ut data. POST benyttes for å opprette data. PUT benyttes for å oppdatere data, og DELETE benyttes for å slette data. - Returnerer beskrivende HTTP statuskoder for hvorvidt kallet mot API'et gikk greit eller ei. Sammen med evnt. data returnert, så returneres det standard HTTP statuskoder for hvorvidt kallet mot API'et gikk greit eller ei. Dette inkluderer da f.eks statuskode 200 for OK, statuskode 404 for "ikke funnet", eller 503 dersom server er nede. På denne måten returneres det beskrivende statuskoder til klienten, som igjen gjør det mulig å utføre evnt. nødvendige tiltak. Data returneres som oftest i JSON eller XML format. I vårt tilfelle førstnevnte, da det i JavaScipt gjør det mulig å behandle dataene som objekter, uten å måtte på forhånd prosessere dataene på noen som helst måte. For å teste API'et ble det brukt en applikasjon ved navn "Postman". Denne applikasjonen gjør det mulig å kjøre HTTP kall mot API'et, med full kontroll over alle variabler i kallet, bla. headers, verb mm, 26

27 og deretter se hvilke resultater som returneres. På denne måten er det ikke behov noen front-end for å kunne teste API'et, og det forenkler hele jobben betraktelig Eksempel på Postman API kall STARTFASE (4-6 FEBRUAR) I startfasen begynte vi med å opprette hele filstrukturen til applikasjonen, samt opprettet nødvendige filer for et helt enkelt API. Dette inkluderer da "www" filen, som er startpunktet for applikasjonen, og inneholder koden for selve webserveren. Når node serveren startes, så er det altså denne filen som kjøres. Vi tok utgangspunkt i ExpressJS sin express-generator funksjon, som oppretter en anbefalt filstruktur for en typisk NodeJS webapplikasjon. (ExpressJS, Express application generator, 2016) Anbefalt filstruktur generert av Express På dette punktet ble det også gjort endel undersøkelser for å finne en NodeJS modul for kommunikasjon med databasen, og valget falt på MSSQL modulen utviklet av Patrik Simek ( En stor fordel med denne modulen er at den automatisk konverterer rådata fra databasen over til JSON objekter, som betyr at vi i vårt kunne klare oss uten et dedikert ORM-lag. Utfordringer: Ingen spesifikke. 27

28 INNLOGGING OG VERIFISERING (7-9 FEBRUAR) I denne fasen ble det brukt en hel del tid på å undersøke forskjellige anbefalte autentiseringsmetoder for en moderne webapplikasjon. En mye tidligere brukt autentiseringsmetode er å benytte sessionvariabler. Dette kan for eksempel være noe så enkelt som en boolsk verdi som lagres i sessionminnet på server, og sier noe om en bruker er logget inn eller ikke. Et problem med å løse det på denne måten, er at applikasjonen ikke blir skalerbar. Det vil si at den ikke blir skalerbar over flere servere. Hvis vi benytter sessions for autentisering, så vil f.eks autentiseringen feile dersom proxyserveren på et tidspunkt velger å levere applikasjonen fra en annen webserver enn tidligere. For at en moderne webapplikasjon skal kunne være skalerbar, så utgår altså sessions. En annen autentiseringsmetode som har blitt svært populært i senere tid er JSON Web Tokens (JWT's). JSON Web Tokens fungerer på den måten at webserveren genererer et token, som så lagres hos klienten, enten som en cookie, eller i nettleserens "local storage". JSON Web Tokens ha flere fordeler enn sessions, blant annet: - Skalerbart, fordi det lagres på klientsiden - Fungerer på tvers av programmeringspråk - Kan bli brukt til å lagre øvrig informasjon om brukeren (payload) Eksempel på oppbygningen av et JSON-Web-Token På bakgrunn av dette ble det valgt å benytte JWT's som autentiseringsmåte i denne applikasjonen. Ettersom JWT's også benyttes som autentiseringsmåte i sosiale medier som facebook, twitter mm. via "OAuth", så vil det også gjøre det enklere å utvide applikasjonen til å benytte innlogging via sosiale medier på et senere tidspunkt, dersom det skulle være ønskelig. 28

29 Utfordringer: Ettersom konseptet med JWT's var noe helt nytt for oss, så ble det brukt endel tid på å sette seg inn i hvordan dette fungerer i praksis. Dette i tillegg til å sette seg inn i konseptet med middleware i NodeJS, dvs. kode som kjøres før koden for den aktuelle API ruten, som igjen er der selve autentiseringen via JWT's tar sted. OPPRETTELSE AV QUIZ (9-13 FEBRUAR) Oppgaven med å lagre en hel quiz i databasen var en komplisert prosess, dette var fordi enkelte tabeller i databasen er avhengig av at data i andre tabeller eksisterer før data kan lagres. Dataene må må derfor lagres i rett rekkefølge. Normalt så blir kode utført synkront, linje for linje. Kall mot databasen er asynkrone og vi er avhengig av at enkelte data blir lagret før øvrige data. I tillegg så er vi i enkelte tilfeller avhengig av informasjon returnert fra databasen før vi kan gå videre til neste databasekall. F.eks må vi få returnert en ny Quiz ID fra databasen før vi kan begynne å lagre spørsmål som tilhører den aktuelle quizen. For å få utført asynkrone databasekall i riktig rekkefølge så benyttet vi et åpent kildekodebibliotek kalt Async.js, som har som opppgave å forenkle prosesser som dette. Her har vi blant annet en såkalt "vannfall"-metode, som tar imot en array av funksjoner, hvor hver funksjon har en callback-funksjon som parameter. Callback-funksjonen kaller vi når det aktuelle databasekallet er ferdig, og vi kan gå videre til neste. Som parametre i callback-funksjonen, så kan vi enten sende med data returnert fra databasen, eller en feilmelding dersom noe gikk galt. Dersom vi sender med data returnert fra databasen (f.eks den nye Quiz ID'en), så kan neste funksjon i vannfallet ta imot denne informasjonen som parameter, og benytte denne for å utføre sin jobb. Async.js har også metoder for å loope igjennom arrays, som igjen er nødvendig i vår applikasjon da en quiz kan ha mange spørsmål, og et spørsmål kan ha mange svaralternativer. Kort fortalt fungerer det slik: - Funksjon for opprettelse av quiz kjører, og den nye Quiz ID'en returnert fra databasen sendes som parameter til neste funksjon - Funksjon for opprettelse av spørsmål kjører, og tar imot Quiz ID'en sendt med som parameter fra første funksjon. Spørsmåls-ID returnert fra databasen sendes som parameter til neste funksjon. - Funksjon for opprettelse av svaralternativ kjøres, og tar imot spørsmåls-id'en sendt med som parameter fra forrige funksjon. - Prosessen gjentas til alle spørsmål og svaralternativer er lagret i databasen. - Til slutt kjøres en siste callback funksjon, som tar imot en evnt. feilmelding som parameter. Vi kan på bakgrunn av dette feilmeldingsobjektet, returnere informasjon til klient om utfallet av API kallet. 29

30 Eksempel på bruk av AsyncJS vannfall-funskjon for opprettelse av quiz Utfordringer: Dette viste seg å være en svært utfordrende oppgave. Det å få utført databaseoperasjonene i korrekt rekkefølge, og bruken av nøstede callback-funksjoner inne i nøstede asynkrone løkker gjør hele algoritmen svært utsatt for feil. Det ble derfor brukt mye tid på feilsøking og utbedring, samt det å sette seg inn i virkemåten til de forskjellige AsyncJS funksjonene, og deretter bruke disse riktig. OPPDATERING OG HENTING AV QUIZ (14-18 FEBRUAR) Algoritmene vi brukte i oppdatering og henting av quiz ligner på opprettelse av quiz i virkemåte og struktur, med unntak at det her blir benyttet AsyncJS sine "Series" og "Parallel" funksjoner. Førstnevnte blir benyttet ved henting av quiz, der det er viktig at vi henter ut informasjon og bygger opp et quizobjekt i riktig rekkefølge. I tilfelle ved oppdatering av quiz, så er det ikke lenger viktig å få utført databaseoperasjonene i riktig rekkefølge, og vi kan gjøre algoritmen raskere ved å benytte "Parallel" i stedet. Dette er fordi slipper å vente på at en operasjon blir ferdig før vi begynner med neste. 30

31 Utfordringer: Algoritmen for oppdatering av quiz endte opp noe mer kompleks enn ved opprettelse av quiz. Dette var på grunn av at det var flere potensielle feil vi må ta hensyn til. Hva hvis en oppgave eller svaralternativ er slettet? Hva hvis det er lagt til et nytt svaralternativ eller spørsmål? På bakgrunn av dette må det legges til endel undersøkelser inne i algoritmen, som igjen bestemmer hvilke databaseoperasjoner som må utføres. I utgangspunktet så hentet vi den eksisterende quizen fra databasen, og gikk systematisk igjennom hele quizen. Deretter sammenlignet vi den med den oppdaterte quizen for å finne ut hva som må oppdateres, slettes eller lignende. Dette førte imidlertid til at hele algoritmen ble ganske treg, da det er mye databaseoperasjoner og sammenligninger som måtte utføres. En bedre løsning er å sjekke om det skal opprettes et nytt spørsmål/svaralternativ eller ikke. Dette gjøres ved å sjekke om spørsmålet eller svaralternativet i quizen som skal oppdateres, har en ID. Hvis den ikke har en ID fra før, så vet vi at det er snakk om et nytt spørsmål/svaralternativ, og i motsatt tilfelle så vet vi at det er snakk om et eksisterende spørsmål/svaralternativ som skal oppdateres. For å løse problematikken rundt tilfeller der spørsmål eller svaralternativer skal slettes, så ble det i stedet implementert egne API funksjoner for dette, som kan kalles i selve applikasjonen ved trykk på "Slett svaralternativ" eller "Slett spørsmål" UTVIKLING AV ANGULAR APPLIKASJON (18 FEBRUAR - 1 MAI) GRUNNAPPLIKASJON (18-22 FEBRUAR) I denne fasen begynte vi på selve webapplikasjonen, dvs. opprettelse av selve Angular grunnapplikasjonen. Dette inkluderer da en index side med HTML grunnstrukturen, som inkluderer alle scripts, navbar, container osv. Dette vil være applikasjonens eneste helhetlig HTML side, applikasjonen er en single-page-application. Når grunnapplikasjonen var opprettet, ble det deretter utviklet funksjonalitet for å logge inn, logge ut og opprettelse av brukerkonto. Ved å logge inn, ble tokenet returnert fra API'et, lagret i nettleserens "local storage", og injected i hvert HTTP ajax kall fra Angular. På denne måten slipper man å gjøre dette manuelt hver gang vi skal utføre et ajax kall mot API'et Token injection i HTTP header 31

32 Utfordringer: I denne delen var den største utfordringen å begynne å skrive Angular-kode for første gang og å ta i bruk API'et for front-end. Det ble også brukt tid på å sette seg inn i HTML5 input-validering, og å sørge for beskrivende tilbakemeldinger til brukeren på bakgrunn av resultatet fra API kallene. Dette inkluderer for eksempel informasjon om at epost ikke finnes dersom man forsøker å logge inn med en ikke-eksisterende brukerkonto/epostadresse, eller at brukerkontoen allerede finnes dersom man forsøker å opprette en brukerkonto med en allerede eksisterende epostadresse. OPPRETTELSE AV QUIZ (22 FEBRUAR - 8 MARS) I denne fasen ble front-end delen for opprettelse av quiz implementert. Ved implementasjonen av dette ble det tatt utgangspunkt i skisser/mockups opprettet i begynnelsen av prosjektet. Disse er vedlagt som vedlegg 4. I tillegg ble det brukt endel tid på å sette seg inn i Bootstrap sitt gridsystem, og hvordan dette fungerer med hensyn til skalering fra full-skjerm dekstop maskiner, ned til mindre mobile enheter som nettbrett og smarttelefoner. Det ble også lagt fokus på å lage løsningen så intuitiv og pålitelig som mulig. Eksempler på dette er: - Knapper blir deaktivert der det ikke er hensiktsmessig å bruke dem. F.eks er det ikke mulig å gå tilbake til forrige spørsmål, dersom man allerede står på spørsmål nummer 1. - Valg for riktig svaralternativ dukker ikke opp før det er skrevet inn et svaralternativ - Dersom man går videre til opprettelse av et nytt spørsmål, og deretter tilbake til forrige spørsmål uten å skrive inn noe på det nye ikke fullførte spørsmålet, og deretter fullfører quiz, så blir det nye spørsmålet forkastet. - HTML5 validering som hindrer en i å gå videre til neste spørsmål uten å ha fullført det første, samt opprettelse av quiz uten noen spørsmål osv. Kort fortalt, så fungerer opprettelsen av quiz ved at det bygges opp et quiz-objekt, der verdier tilføres etterhvert som bruker legger inn data. Quizobjektet er bygget opp slik API'et forventer å motta det som via JSON Starten på et quiz objekt 32

33 Utfordringer: I denne fasen ble det brukt endel tid her på å sette seg inn i to-veis bindingen til Angular, og hvordan bruke dette i praksis. Måten Angular får til dette er ved bruk av noe de kaller sin "digest cycle". Dette er en loop som overvåker endringer i input felter, og oppdaterer de bakomliggende modellene automatisk. Har du f.eks et inputfelt for quiz-navn, så blir modellen bak oppdatert kontinuerlig. Dette kan ses i praksis i selve applikasjonen ved at quiztittelen oppdateres samtidig som man skriver den inn. Et problem vi støtte på her var at bruk av såkalt "auto-complete" i tekstfelter ikke ble plukket opp av Angular"digest cycle", noe som fører til at den bakomliggende modellen ikke blir oppdatert. Dette er en velkjent svakhet ved to-veis bindingen til Angular, og det har blitt sluppet en polyfill av Tobias Bosch (senior-utvikler hos Angular) som løser dette problemet. Denne har vi benyttet oss av. Implementasjon av funksjonalitet for opplastning av lyd og bilde til server ble det også brukt endel tid på. Vi bestemte oss for å benytte en NodeJS modul kalt "Multer" til dette. Denne modulen forenkler jobben med fil-opplastning, og leverer nyttig funksjonalitet som for eksempel endring av filnavn. Dette er viktig for å sikre at ingen fil-opplastninger overskriver en tidligere fil-opplastning fra f.eks en annen bruker. For å sikre at hver fil vil være unik, så konkatinerer vi tidspunkt for opplastningen i millisekunder sammen med filnavnet. Filen blir da lagret på server som feks " afrika.jpg". Et annet problem var relatert til HTML5 validering, som noen eldre nettlesere ikke støtter. For å løse dette problemet ble det brukt en Webshims polyfill ( QUIZ PÅMELDELSE (9-22 MARS) Dersom en quiz skal tas i "felles-modus", det vil si med mange deltakere, hvor fremgangen styres av bruker, så må det implementeres en form for quiz-påmelding og -avmelding. Brukere må enkelt kunne gå inn på applikasjonen, og melde seg på en quiz. Dette må så vises på brukeren sin hovedside, hvor vedkommende skal kunne se hvor mange som har meldt seg på hver enkelt quiz. Her ble det benyttet websockets for kommunikasjon mellom klienter. Websockets gjør det mulig med real-time kommunikasjon mellom klienter over en enkelt TCP tilkobling. Websockets benytter port 80 på lik linje med all annen vanlig internett-trafikk. Dette hindrer eventuelle problemer med brannmurer og er mye brukt i alle applikasjoner der det er behov for kommunikasjon mellom forskjellige klienter, som for eksempel chatapplikasjoner. Vi valgte å benytte oss av et populært websocketbibliotek kalt "Socket.IO" til implementasjon av quizpåmelding. Dette biblioteket er brukt av blant annet Microsoft Office, Yammer og Zendesk. Socket.IO kommer med funksjonalitet som gjør det enklere for oss å identifisere enkelte brukere, mellomlagre informasjon, påmelding og avmelding av såkalte "socket rooms". Socket.IO er event-driven, det vil si at du definerer selv funksjoner som skal kjøres ved en event med 33

34 et gitt navn, og du sender ut events med gitte navn manuelt. På denne måten kan du styre gangen og funksjonaliteten i applikasjonen etter hvilke events som sendes ut eller plukkes opp. Eksempel: Eksempel på bruk av websockets i kildekoden Vi har brukt websockets for quizpåmelding, avmeldelse, tilkobling, frakobling, og framgang til neste spørsmål mm. Utfordringer: Ettersom ingen av oss hadde benyttet websockets i før, så tok det naturlig nok noe tid å sette seg inn i. Det er en hel del problemstillinger som måtte løses: - Hvordan skal bruker til enhver tid vite hvor mange som er påmeldt en quiz? - Hva hvis bruker kobler fra? Hva hvis deltaker kobler fra? - Hvordan skille websockets events mellom forskjellige quizer? - Hvordan sikre at events kun blir plukket opp av riktige brukere? - Hva hvis bruker eller deltaker navigerer vekk til en annen side? I utgangspunktet ble løsningen implementert slik at bruker har en lokal array fylt med ID'ene til deltakerne. Disse ID'ene blir plukket opp når en deltaker sender ut en event for å melde seg på quiz. En ulempe her var at det ble svært mange events hos både klient og server for å utføre relativt enkle oppgaver. En kompleks løsning, er også en løsning som er mer utsatt for feil. I tillegg er en kompleks løsning vanskelig å videreutvikle med ny funksjonalitet. På bakgrunn av dette bestemte vi oss for å gjøre om hele denne implementasjonen. Daværende løsning var rett og slett ikke pålitelig nok. Etter å ha brukt mye tid på å undersøke andre muligheter, samt sette oss mer inn i hvilke muligheter Socket.IO tilbyr utover standard bruk, så falt valget på å bruke av såkalte "rooms". Dette kan sammenlignes med et chatterom, som du kan melde deg på og forlate. Når en bruker melder seg på en quiz, så meldes han inn et socketrom på serveren for akkuratt denne quizen. På denne måten kan man begrense og styre hvem man sender ut events til. Man kan da for eksempel sende ut en "startquiz" event til deltakere av quiz med ID 13, uten at andre plukker opp hendelsen. En annen fordel er at brukeren ikke trenger å være pålogget for at deltakere skal ha mulighet til å melde seg på quizer, slik som var tilfellet i den første implementasjonen. På brukeren sin hovedside kjøres det en løkke hvert sekund som ser etter endringer i antall påmeldte for sine quizer. Dermed har det ingen konsekvenser om brukeren skulle navigere vekk fra siden, eller koble fra. Bruker kan også starte en påbegynt quiz på nytt, og quizen blir da startet på nytt hos alle deltakerne. 34

35 På denne måten er hele implementasjonen mer robust og pålitelig. Den gir rom for brukerfeil, frakoblinger og navigering over til andre sider osv, uten kritiske følger. DELTAKELSE AV QUIZ (23-31 MARS) I forrige fase av prosjektet ble det implementert mulighet for quizpåmelding, hvor neste naturlige steg var å implemetere funksjonalitet for quizdeltakelse. Dette inkluderer da brukergrensesnitt for å ta og fullføre en quiz, og den bakomliggende funksjonaliteten når det kommer til kommunikasjon mellom bruker og deltakere, avspilling av video og lyd, valg/visning/registrering av riktig/feil svar og registrering av resultater. Det ble brukt mye tid på brukergrensesnittet. Mer spesifikt hvordan bygge et brukergrensesnitt som gjør det enkelt, oversiktlig og brukervennlig å delta på en quiz, enten man er på en mobilenhet eller en PC. Det ble vurdert bruk av "radioknapper" for valg av svaralternativ og deretter markere det riktige svaralternativet ovenfor deltaker. Dette ble imidlertid ikke særlig pent visuelt, og samtidig knotete ved bruk av mobile enheter. Valget falt derfor heller på bruk av tradisjonelle knapper, i form av en knappegruppe. Disse gjør det enkelt å velge svar uavhengig av hvilken enhet man er på, og gir i tillegg følgende fordeler: - Riktig og feil svar kan vises umiddelbart via farger ved å endre CSS-klasser dynamisk etter å ha gjort et valg - Knappene kan deaktiveres etter å ha valgt et svar, slik at det kun er mulig å velge én gang - Er mer intuitivt å bruke og quizdeltakelse blir mer likt et spill enn en tradisjonell quiz - Fleksibelt for forskjellig antall svaralternativer, da knappene bygges i høyden (vertikalt) For avspilling av lyd ble det benyttet HTML5 sin innebygde lydavspiller. Denne har bred støtte blant nettlesere og er enkel å benytte. For avspilling av video ble det vurdert å gjøre det samme, men ettersom HTML5 sin videospiller ikke støtter avspilling av "remote content" som f.eks. YouTube videoer, så falt dette valget vekk. Et alternativ var bruk av HTML iframes, sammen med YouTube sitt API for videoavspilling. Et problem med denne var at den ikke skalerer godt med Bootstrap. Den er heller ikke særlig enkel å benytte i en AngularJS applikasjon som dette, da endring av video ved overgang til nytt spørsmål krever mye kode for en relativt liten jobb. Et AngularJS direktiv som kan fungere som en wrapper, og i tillegg tilby ytterligere funksjonalitet hadde sådan vært svært nyttig. Et mye brukt Angular direktiv for dette, er "Angular-YouTube-Embed" ( Dette direktivet forenkler arbeidet med å vise og endre YouTube videoer betraktelig, og skalerer samtidig godt med Bootstrap. Direktivet tar en youtube video-id som parameter, i tillegg til et "player-vars" objekt, som kan modifiseres for å endre hvordan video avspilleren ser ut og hvilken funksjonalitet den tilbyr. Her deaktiverte vi for eksempel visning av videotittel i avspilleren, slik at en kan ha videospørsmål hvor svaret ikke avsløres på noen måte ved å kikke på tittelen. Video-ID'en kan 35

36 endres dynamisk i den bakomliggende controlleren, slik at ved navigering over til et nytt spørsmål så oppdateres det samtidig hvilken video som vises Eksempel på oppdatering av video URL og lydfil ved navigering til nytt spørsmål Utfordringer: De største utfordringene i denne fasen var relatert til det å få oppdatert lydavspilleren med ny lydfil og starte avspillingen på nytt. Normalt så skjer dette av seg selv i en tradisjonell nettside. I en singlepage-application (SPA) derimot, så må dette gjøres manuelt i controlleren. Fordi angular-digest-cycle ikke plukker opp endringen i lyd/video fil, på grunn av at koden kjøres asynkront ved en socket event, så viste deg seg at dette måtte bli gjort manuelt ved å plassere denne koden inne i angular sin $apply-funksjon. Vi måtte også sørge for å kalle lydavspilleren sin "load"-metode manuelt ved bytte av spørsmål. ENDRING AV QUIZ, ANIMASJONER, OG ALERTS (3-6 APRIL) I denne fasen ble det implementert funksjonalitet for endring av eksisterende quizer, animasjon ved endring av innhold/navigering mellom undersider og dialogbokser ved diverse feil. Eksempler på dette er hvis en forsøker å opprette en quiz uten nettilgang eller lignende. Vi tok i bruk et eget wrapperbibliotek for JavaScript, kalt SweetAlerts ( Dette biblioteket stiller med penere dialogbokser, og små enkle animasjoner som indikerer utfallet av en handling, f.eks at opprettelse av quiz gikk bra. Se eksempel på hvordan disse har blitt brukt i vår applikasjon i produktrapporten. Ved navigasjon mellom undersider og ved endring av innhold, så ønsket vi en animasjon som gir applikasjonen bedre flyt, og bidrar positivt til den generelle brukeropplevelsen. Ved bruk av animasjoner så er det viktig at den ikke blir en irritasjon for brukeren. Det må være en funksjonell hensikt med dem. Brukeren skal slippe å måtte vente på at en animasjon fullføres for å kunne gjøre oppgaven sin. Valget falt på en helt enkel «scale-up» animasjon med en kort kjøretid på 0.3 sekunder. Vi benyttet Angular sin ng-animation modul sammen med CSS for å opprette denne animasjonen CSS animasjon Funksjonaliteten for opprettelse av quiz bestod i utgangspunktet av 2 sider - en for quiznavn og sjanger, og videre til en ny side med opprettelse av svaralternativer, bilder, video osv. Det samme ble gjort her ved endring av eksisterende quiz. 36

37 Denne løsningen hadde imidlertid stort forbedringspotensialet. For det første, så valgte vi å gå vekk fra registrering av en sjanger tilhørende en quiz. Dette grunnet at det ikke hadde noen praktisk verdi for applikasjonen, og ville heller ikke bli brukt noe sted. Da gav det også liten mening å ha en egen side for registrering av quiznavn. Det ble derfor besluttet å slå disse to sidene sammen til én side. Ettersom siden for opprettelse og endring av quiz var relativt identiske, så var det også redundant å ha 2 separate sider for dette. Vi kunne med fordel slå dette sammen til et og samme view, som gjenbrukes for både opprettelse og endring av quiz. Angular sin to-veis binding, og støtte for direktiver gjør det også lett å gjenbruke views til bruk forskjellige steder. Her endte vi altså opp med å kunne gå fra 4 til 1 view, med en mer intuitiv og penere brukeropplevelse som resultat. Mer intuitivt i den form av at brukeren som allerede har opprettet en quiz, vil gjenkjenne det samme brukergrensesnittet. Samtidig så ivaretar vi "dry code" prinsippet (ikke gjenta deg selv). SVARSKJEMA/FASIT OG GLEMT PASSORD (7-8 APRIL) I denne fasen ble det implementert funksjonalitet for print av svarskjema og fasit, samt mulighet for å tilbakestille/endre passord. Oppdragsgiver ønsket i tillegg mulighet for å skrive ut et svarskjema for å kunne ta quizer på papir. Dette ble implementert som en helt egen side, separert fra resten av applikasjonen. Ved å trykke på "Print svarskjema" alternativet for en quiz, så blir en viderekoblet til denne siden. Her blir spørsmål og svaralternativer formatert på en måte som gjør det lett for deltakere å huke av sine svar, og print dialogboksen til nettleseren blir brakt opp automatisk. Det samme gjelder print av fasit, hvor forskjellen ligger i at de korrekte svaralternativene allerede er markert. Det ble valgt å ikke inkludere disse sidene som undersider i selve applikasjonen, men som helt separate sider. Dette for å unngå at noe annet enn det faktiske svarskjemaet blir med i printen, altså øvrig grafikk og brukergrensesnitt blir ekskludert. Dette gir oss også mulighet til å benytte CSS media queries for print, og ta i bruk sidens fulle bredde. Sistnevnte er viktig, da forskjellige nettlesere har forskjellige funksjonalitet for å skrive ut med forskjellig bredde og utseende. Vi er nødt til å ha en «glemt passord»-funksjonalitet, som brukere kan benytte dersom de ikke lenger husker sitt passord. For å verifisere brukeren, så benytter vi epost. Her er det to metoder de vanligste - verifisere via. en kode, eller en link. Vi valgte å benytte oss av førstnevnte metode, da vi ser på denne som den mest brukervennlige. Brukeren blir bedt om å taste inn sin epost adresse, og trykke på knappen for "Send kode". Det genereres da en 4-5 sifret kode, som blir sendt med til et API kall for å sende epost. Hashverdien av koden mellomlagres så i localstorage til nettleseren, og brukeren får så mulighet til å taste inn koden mottatt på epost. Dersom hashverdien til inntastet kode og koden mellomlagret i nettleseren stemmer overens, så får brukeren mulighet til å taste inn et nytt passord. 37

38 Kodesnutt fra epost API route Utfordringer: Et problem vi støtte på i dennne fasen var når svarskjemaet går over flere sider. Da kunne spørsmål og svaralternativer bli splittet mellom sider, slik at for eksempel halvparten av et spørsmål er på bunnen av en side og resten på toppen av neste side. Dette ble løst ved å benytte en egen div-tag som container for hvert enkelt spørsmål. Nettlesernes funksjonalitet for å skrive ut vil da se på hver div som en egen seksjon av siden og ikke splitte disse opp, men heller strukturere dem korrekt over flere sider. Når det gjelder tilbakestilling av passord, så var det en sikkerhetsbekymring her da vi i utgangspunktet lagret koden i klartekst i nettleserens localstorage. Ettersom man med litt innsats kan få tilgang på informasjon som er lagret her, kan man i praksis finne frem til koden, uten å måtte ha tilgang på brukerens epostadresse. For å løse dette, valgte vi å mellomlagre en hash av koden som genereres, og sammenligne hasher i stedet. En annen problemstilling var behovet for en betrodd SMTP server for å sende mail. I PHP så behøver du ikke spesifisere noen bruk av en egen SMTP server for å sende mail. Dette er grunnet det store økosystemet som PHP gjerne kommer levert med, typisk Apache. PHP sin mail funksjon fungerer som regel problemfritt ettersom PHP har eksistert i over 20 år, og Apache sin SMPT server har utviklet gjennom alle disse årene til å bli en betrodd avsender. Dette er imidlertid ikke tilfellet med NodeJS. For å sikre at epost faktisk blir levert, så er det her altså nødvendig å spesifisere en egen SMTP server/epost leverandør. I vårt tilfelle har vi opprettet en helt enkel Gmail konto som benyttes for dette. Dette kan enkelt endres i backendkoden til å benytte en selvvalgt epostadresse fra oppdragsgiver i ettertid. RESULTATSIDE OG TOPPLISTE (9-19 APRIL) Oppdragsgiver ønsket en egen resultatside som viste resultater for deltakelse av quiz, enten det var snakk om en inviduell deltakelse eller felles med mange deltakere samtidig. Et resultat lagres i databasen med et navn, dato/tidspunkt og en poengsum, samt en fremmednøkkel til epost og quiz ID. Det var altså nødvendig med en algoritme her som kunne skille mellom forskjellige resultater, og se om de hører sammen eller ikke. Denne algoritmen fungerer slik at vi henter alle resultater fra databasen knyttet til brukeren som er logget inn. Vi oppretter så en array og går igjennom alle resultatene. For hvert resultat så oppretter vi et objekt med quiznavn, dato og en array av deltakere, som vi så legger til arrayen med resultater dersom den ikke allerede finnes. Dette sjekkes via en lokal funksjon som sjekker om objektet allerede finnes i arrayen. 38

39 Hvis det ikke allerede finnes, så går vi inn i en ny løkke som går igjennom alle resultater fra databasen på nytt, og samler alle resultater som hører sammen, og legger dem til i "deltakere" arrayen til resultat-objektet. For å avgjøre hvorvidt flere resultater hører sammen, så sjekker vi tidspunktet for resultatet som er lagret i millisekunder. Dersom flere resultater hører sammen, så vil de alle ha en timestamp pluss/minus noen sekunder i forhold til hverandre. På denne måten kan vi skille mellom resultater som hører sammen og de som ikke gjør det Kodesnutt av algoritme for å sortere resultater Denne løsningen for å finne ut hvilke resultater som hører sammen er imidlertid ikke 100% pålitelig. Dette grunnet at det er en sjanse for at to resultater som egentlig ikke hører sammen, kan bli feiltolket av algoritmen til å nettopp gjøre det. Eksempel på dette er hvis to deltakere som ikke har noen relasjon til hverandre tar den samme quizen inviduellt, og fullfører den så og si samtidig. Algoritmen vil da feilaktig tolke disse to resultatene til å høre sammen. En bedre løsning hadde hvert å redesigne tabellen for resultater til å benytte 2 tabeller som har en relasjon til hverandre via. en fremmednøkkel. F.eks en tabell med informasjon om quiznavn og dato, samt en tabell med deltakere som har en fremmednøkkel til den første tabellen. En ulempe med denne løsningen vil være at registrering av resultater fra deltakere ville blitt svært komplekst. Slik vi ser det så måtte brukeren (quizmaster) ha opprettet en rad i den første tabellen ved fullført quiz, og deretter fått returnert ID for den nye raden. Denne hadde så måttet blitt sendt til alle deltakere via websockets, hvor de så kan benytte ID'en til å registrere sine resultater i den andre tabellen for deltakere. Etter møte med oppdragsgiver ble det også utrykt et ønske om å vise en toppliste over de 3 beste ved en fullført quiz med flere deltakere. Denne funksjonaliteten ble implementert via en algoritme svært lik den som blir benyttet på resultatsiden med unntak av at den henter alle resultater som hører til quizen som nettopp ble tatt, sorterer dem etter poengsum, og mellomlagrer kun de 3 beste for å så vise disse. Alt dette gjøres etter at deltakeren har registrert sin egen poengsum i databasen, 39

40 hvor det deretter ventes 2 sekunder før resultater hentes og sorteres. Grunnen til dette er for å sikre at alle deltakere har fått registrert sin poengsum i databasen før vi henter og viser de 3 beste. Utfordringer: Algoritmen for å finne ut hvilke resultater som hører sammen viste seg å være ganske utfordrende å utvikle. Det ble brukt mye tid på idémyldring for hvordan vi skulle få til dette med å finne ut hvilke resultater som hører sammen, sortere og vise dem med de begrensninger databaseimplementasjonen stiller med i dette tilfellet. I utgangspunktet så ble dato/tidspunkt for et resultat opprettet av databasen når et nytt resultat ble registrert. Databasen benytter da sin egen lokaltid for dette. Når vi skulle benytte tidspunkt hos klienten for å skille mellom resultater i algoritmen, så førte dette til problemer, da databasen i vårt tilfelle ikke befinner seg i vår tidssone. Det er også dumt å måtte ta hensyn til tidssoneforskjeller mellom database og klient. Vi bestemte oss derfor for å endre API kallet for lagring av resultater til å ta imot tidspunkt fra klienten og benytte dette i stedet for databasen sin egen lokaltid. En annen endring vi gjorde her var å lagre tidspunkt i millisekunder i stedet for et typisk dato/tidspunkt format. På denne måten ble det lettere å skille mellom resultater i algoritmen for visning av resultater og toppliste. Det var også et problem i API'et ved lagring av resultater. Hvert DB kall i API'et opprettet i utgangspunktet en egen kobling mot databasen, som så ble benyttet til å utføre database kallene, og som deretter blir lukket. Det viste seg at dersom mange deltakere skal lagre resultater samtidig, så feilet dette i noen tilfeller der serveren har lukket koblingen mot databasen samtidig som et nytt databasekall blir forsøkt utført. API'et ble derfor overhalt til å benytte kun én og samme kobling mot databasen for alle databaseoperasjoner. Dette løste problemet med registrering av resultater fra mange deltakere. Det viste seg også å være et stort pluss ved å gjøre det slik når det kom til hastighet på APIkall fra klient. Disse ble betydelig raskere nå som det ikke var nødvendig å opprette en ny databasekobling for hver databaseoperasjon. VALG AV VERK (19-21 APRIL) Oppdragsgiver ønsket etter et møte, mulighet til å kunne velge mellom forskjellige bokverk i applikasjonen, hvor hvert bokverk kan ha ferdige quizer. På denne måten blir det ikke bare en standard quizapplikasjon, men en applikasjon som er nært knyttet opp mot oppdragsgiver og deres forskjellige verk. Disse quizene som tilhører et bestemt bokverk skulle være tilgjengelig for alle brukere, men ikke kunne endres, slettes eller lignende av andre enn adminkontoene tilhørende hvert enkelt bokverk. Dette ble løst ved at det må lages en egen adminkonto til hvert bokverk. Et eksempel på en slik konto kan være mylder@cappelendamm.no. Disse kontoene kan benyttes til å opprette ferdige quizer tilhørende det aktuelle bokverket. Når en vanlig bruker logger inn, så vil de måtte velge mellom forskjellige bokverk. Når et bokverk er valgt, så endres verkslogo oppe i venstre hjørne til å reflektere dette, i tillegg til at ferdige quizer tilhørende det aktuelle bokverket vil være synlig for brukeren. Disse quizene vil ikke være mulig å slette, endre eller lignende uten at man er logget inn på adminkontoen tilhørende det aktuelle bokverket. 40

41 Verkslogoer ble levert fra oppdragsgiver i jpg og pdf format. Disse var det nødvendig å gjøre endringer på grunnet følgende behov: - For å benytte dem som logoer i applikasjonen, så må de være i PNG format med en alpha kanal - Størrelsesforholdet (aspect ratio) må være likt for de forskjellige logoene Vi laget derfor egne varianter i Adobe Photoshop der vi fjernet den hvite bakgrunnen, og gjorde dem om til png-format med en gjennomsiktig alpha kanal som bakgrunn. Alle logoene ble så redigert til å ha samme størrelsesforhold. Dette var for å sikre at de skaleres korrekt i forhold til hverandre, f.eks som logo øverst i venstre hjørne av applikasjonen eller i knappene for valg av bokverk. Utfordringer: Det var en problemstilling relatert til hvilken logo som skal vises for ikke-brukere, det vil si brukere som enten ikke har logget inn eller gjester som kun besøker nettsiden for å delta på en quiz. Her ble det valgt å benytte oppdragsgiver sin egen standard logo som placeholder for verkslogoer dersom man ikke har valgt et bokverk. NETTLESER KOMPATIBILITETSJEKKING (25 APRIL TIL 1 MAI) I den siste fasen ønsket vi å teste applikasjonen over et bredt utvalg av nettlesere og enheter for å kunne kartlegge hva som støttes eller ikke. Dette var fordi vi ønsket å gi brukeren passende tilbakemeldinger dersom applikasjonen blir brukt av en nettleser eller enhet som ikke er støttet. For å teste dette benyttet vi oss av Browserstack ( Denne tilbyr testing av over 1000 nettlesere på desktop, og mobile enheter. Både via virtuelle maskiner, emulatorer og fysiske enheter. Dette forenklet arbeidet med nettleser-testing betraktelig Browserstack skjermbilde 41

42 Vi testet applikasjonen på de fleste versjoner av de mest brukte nettleserne. Dette inkluderer alle versjoner av Internet Explorer, Firefox, Opera, Safari, Edge, og Chrome, samt standard nettleserne til Android versjon 4 og opp, Windows Phone, og ios versjon 3 og opp. På bakgrunn av disse testene kunne vi utbedre feil, og legge inn sjekker for hvordan nettleser og/eller operativsystem klienten benytter, som igjen gir beskrivende tilbakemeldinger ved bruk av ikkestøttede nettlesere og/eller operativsystemer. Utfordringer: Ingen spesifikke. 2.3 KRAVSPESIFIKASJONEN OG DENS ROLLE Store norske leksikon sier at en kravspesifikasjon er en beskrivelse av hvilke brukerfunksjoner og generell ytelse et programsystem skal ha. Kravspesifikasjon utarbeides før et programsystem utvikles, for å sikre at brukernes behov blir dekket når det gjelder funksjonalitet, ytelse og brukervennlighet. (Liseter, 2016) Kravspesifikasjonen er en utrolig viktig del av utviklingen av et prosjekt. I dette prosjektet ble kravspesifikasjonen utviklet før utviklingen begynte, helt i starten. Den ble utviklet i samarbeid med oppdragsgiver, slik vi fikk et grundig bilde på akkurat hvordan de ville at produktet skulle bli. Kravspesifikasjonen fikk en veiledende rolle gjennom hele prosjektperioden. Den har bidratt til vi har hele tiden hatt en «mal» å følge og har på den måten gjort at vi har holdt oss innenfor gitte rammer. Kravspesifikasjonen var til for å endres, slik at utviklingen av prosjektet ikke stoppet opp eller at vi var for oppsatte på de forhåndsatte kravene, men at den ga oss muligheten for en dynamisk prosess der oppdragsgiver var sikret et best mulig resultat til slutt. Kravspesifikasjonen har hatt endringer underveis. Den har blitt mer detaljert og det har blitt gjort endringer i de funksjonelle kravene. Kravspesifikasjonen er vedlagt som vedlegg 1 i slutten av denne rapporten ENDRINGER I KRAVSPESIFIKASJONEN Ettersom vi valgte en smidig utviklingsmetodikk var det til å forvente at kravspesifikasjonen kom til å endre seg i løpet av prosjektperioden. Vi hadde i tillegg fått mye frihet rundt hvordan produktet skulle utvikles fra oppdragsgiver sin side, så kravspesifikasjonen ble derfor utviklet med noen faste krav og noen frivillige. Grunnen til dette var at vi på denne måten kunne ta hensyn til brukertester, tidsbruk og selve utviklingen for å til slutt finne ut hva som fungerer best for akkurat denne applikasjonen. Da vi begynte å utvikle applikasjonen la vi merke til at den opprinnelige kravspesifikasjonen var noe mangelfull. Vi valgte derfor å opprette en ny versjon med flere krav. Det var denne versjonen vi i all hovedsak benyttet oss av under resten av utviklingen. 42

43 En av de største endringene fra den opprinnelige kravspesifikasjonen, var at vi endret kravet som sa at deltagerne kan komme inn på quizen ved hjelp av en URL-link. Grunnen til dette var at vi så det som mer hensiktsmessig, både når det gjaldt programmeringskoden og brukervennligheten, at elevene aksesserer quizer med en kode (quiz ID) i stedet. Det er med andre ord lettere å dele ut en kode enn en URL link, da en kode er kortere og lettere å huske. Vi endret også kravet som ga et maks antall på oppgaver og svaralternativer. Dette var i utgangspunktet satt opp til maks 3 svaralternativer og 30 oppdager. Vi så imidlertid ingen god grunn til å sette en grense her, og endret disse til å være ubegrenset etter samtale med oppdragsgiver. I tillegg til å endre noen av kravene i den første kravspesifikasjonen ble det lagt til nye. Mange av disse kravene handlet i all hovedsak om universell utforming og brukervennlighet. I den første versjonen ble disse faktorene mindre vektlagt, men vi fant ut da utviklingen begynte at disse også hadde en stor betydning og trengte å bli bedre representert i kravspesifikasjonen DET ENDELIGE PRODUKTET Man kan si at det endelige produktet samsvarer i stor grad med kravspesifikasjonen. Alle krav med unntak av endring av rekkefølge, lydavspilling av spørsmål og maks svaralternativer/oppgaver ble implementert. I tillegg ble det også implementert noen ekstra funksjoner vi fant nødvendige. Eksempler på dette var funksjonen som viser de tre beste resultatene når en quiz er ferdig og funksjonen hvor verkslogo er koblet til quizer som er laget på forhånd. Begge disse fant vi nødvendige å implementere under utviklingen og etter møte med oppdragsgiver. Mer om dette kan leses om i produktdokumentasjonen. 43

44 3 PRODUKT LESERVEILEDNING Produktdokumentationen är i huvudsak uppdelad i 4 delar; produktrapporten, testdokumentationen, användarvägledningen och kravspecifikationen. Dessa ska ge användaren en inblick och förståelse för programmets uppbyggnad och funktionalitet. Den är i huvudsak till för den som ska installera, underhålla och modifiera systemet. Själva programmet är en quiz-applikation där en användare upprättar en quiz och en eller flera deltagare tar en quiz. Programmet är uppdelat i ett back-end och ett front-end och båda är utvecklade med olika javascript-teknologier. Det har blivit utfört ett flertal tester som man kan läsa om i testdokumentationen. För att börja använda applikationen rekommenderar vi att man läser användarvägledningen först. Produktrapporten innehåller följande delar: Middlertidlig nettadresse for applikasjonen Back-end API Front-end MIDDLERTIDLIG NETTADRESSE FOR APPLIKASJONEN Applikationen ligger för tillfället ute på en server så att man kan använda applikationen utan att behöva ladda ned och installera programkoden. Detta är en tillfällig lösning och applikationen kommer att tas bort från servern efter sommaren. Detta är adressen till applikationen: 44

45 3.1 BACK-END API Denna delen av produktrapporten går igenom back-end API et för applikationen. Det är inget behov för kunskaper i NodeJS eller Javascript-teknologier för att använda programmet. Om applikationen ska vidareutvecklas är det dock viktigt att användaren har kunskaper om de Javascript-teknologierna som programmet har utvecklats i. Denna delen är uppdelad i följande avsnitt: Struktur och funktion Systemarkitektur Systemkrav Installation av programmet Sikkerhet STRUKTUR OCH FUNKTION API Applikationens back-end är ett RESTful API utvecklat i NodeJS. NodeJS är ett kryssplattform runtime system för utveckling server-delen av webb-applikationer. (NodeJs, 2016) Ett back-end API består av olika router för de olika funktionerna. Rutene blir i praksis API URL'er som utfører bestemte oppgaver. Exempel på det är en API-route för upprättelse av quiz. Routen förväntar en hel quiz formaterad som et JSON objekt och bild nedan är exempel på hur detta kan se ut Exempelbild på JSON-objekt för Opprettelse av Quiz 45

46 FILSTRUKTUR Filstruktur för de viktigaste filerna i back-end API: /Mimir /bin www api.js db.js packages.json bower.json Filen api.js innehåller alla API-koder medan filen db.js innehåller alla metoder för kommunikation med databasen. Bower.json och packages.json är två referensfiler som pekar på vilka paket applikationen behöver installerade för att köra. Filen www är själva web-servern och är uppstartspunkten för applikationen. Här finner man även hanteringen av WebSockets. DATABAS Bild på databasschema Det finns en MSSQL-modul i NodeJS som returnerar datan från databasen i Json-format som är det önskade formatet. I vårt tillfälle eliminerar det behovet för ett dedikerat ORM-lag. 46

47 Ett exempel ur programkoden på det förväntade formatet när ett resultat blir satt in i databasen: { } poengsum : 28, navn : "Kristian", epost : test@test.com, quizid : 1 Programmet har en funktion för att återställa lösenord genom att sända en engångskod via mail till användaren. För att sända mail är det nödvändigt att specificera en egen SMTP-server eller epostleverantör. I programmet har det blivit upprättat en gmail-konto för detta. Det är dock inga problem att ändra detta i källkoden. Detta gör man i så fall i filen api.js på linje Bild på programkod från filen api.js SYSTEMARKITEKTUR Bild på systemarkitekturen 47

48 3.1.3 SYSTEMKRAV För att använda applikationen krävs det en servermaskin. Servern måste ha installerat NodeJS samt pakethanterar-verktyget Bower. Det måste även finnas tillgång till en MSSQL databas där man upprättar de tabeller som krävs för applikationen. Detta görs via ett skript. Vänligen läs om Installation av programmet för mer information om vad som krävs av användaren innan programmet är redo att köras. Webbläsare som applikationen stöder: ios safari 6 och nyare versioner Firefox 21 och nyare versioner Opera 25 och nyare versioner Safari 6 och nyare versioner Android 4 och nyare versioner Microsoft Edge Delvis støtte for Internet Explorer 11 og 10 Applikationen stöder inte tidigare versioner av Internet Explorer enn 10 og 11. Internet Explorer 10 og 11 støttes delvis. Mer spesifikt så oppdateres ikke listen over quizer etter opprettelse eller sletting av en quiz i disse nettleserne. Dette kan en komme rundt ved å laste siden på nytt etter å ha gjort en av disse endringene INSTALLATION AV PROGRAMMET Installationsvägledningen tar i utgångspunkt att användaren installerar applikationens API på servermaskinen och där utför installationen. Maskinen måste ha installerat NodeJS och pakethanterar-verktyget Bower. För att installera NodeJS, gå till hemsidan och ladda ned NodeJS. 1. Ladda ned eller kopiera programkoden och lägg den på en passande plats. Öppna terminalen på Mac eller cmd på Windows. Kör följande kommando när du står i projektmappen: 1. npm install alternativt sudo npm install 2. bower install alternativt sudo bower install 4. Modifiera connection-string överst i filen db.js till att använda den databasen man önskar. For lokal testing så kan eksisterende Microsoft Azure DB connection-string benyttes. 5. Kör skriptet createdatabase.sql för att upprätta de riktiga tabellerna. 6. Eventuellt modifiera vilken port man önskar att använda i filen www. 48

49 7. Kör kommandot npm start för att starta web-servern. För att testa applikationen lokalt, skriv in localhost:3000 i din webbläsare. 8. Opprett epost kontoer for de forskjellige admin-kontoene tilhørende deres cappelendamm.no domene. Se liste over disse epostene lenger nedenfor. (f.eks mylder@cappelendamm.no). 9. Opprett brukerkontoer med epostene opprettet i forrige punkt. Dette vil være admin-kontoene til de forskjellige bokverkene SÄKERHET Applikationen har en inloggningsfunktion som användaren använder för att upprätta konto för att sen kunna administrera quiz. Den information som sparas på applikationen för användaren är inloggningsdetaljerna, vilka är en epostadress och ett lösenord. I tillägg sparas även resultat för de som har tagit en quiz. Den som tar en quiz väljer själv under vilket namn den vill ta en quiz. På så vis sparas ingen sensitiv information om den som tar en quiz. Applikationen använder sig av JSON Web Tokens som autentiseringsmetod. JSON Web Tokens fungerar som så att API et generar ett token som sparas hos klienten, antingen som en cookie eller i webbläsarens Local Storage. Detta token är en textsträng kodat i base64encode och består av 3 delar separerade med ett punkt. Exempel på ett token: eyj0exaioijkv1qilcjhbgcioijiuzi1nij9.eyjlcg9zdci6inrlc3radgvzdc5jb20ilcjpyxqioje0nty0oty4mdb9.-xiummt_rnpmxzlultdbu9xw9ft2ejs-chocnbu5zk0 Första delen markerat med grönt innehåller information om vad för slags token det är och vilken hashing-algoritm som är använd. Dekodat kan den exempelvis se ut såhär: Exempelbild på hur första del av token kan se ut Andra delen som är markerad med blått innehåller själva datan i tokenet. Det kan exempelvis vara information om när tokenet går ut, var det kommer ifrån eller information om användaren. Dekodat kan det exempelvis se ut såhär: Exempelbild på hur andra del av token kan se ut 49

50 Den tredje och sista delen som är markerad med rött är signaturer. Den består av ett hash-värde utarbetat av den första och andra delen, samt en privat nyckel sparad på servern. Kombinerat kan de verifiera tokenets autenticitet. Vid ett API-kall mot servern sänder klienten detta tokenet med i HTTP-kallet, antingen genom att placera det i header eller via URL en. Ettersom JSON Web Token via OAuth" också används som autentiseringsmetod i sociala medier som exempelvis Facebook och Twitter, så finns det också möjlighet att vidareutveckla applikationen så att man kan logga in via sociala medier om så önskas. Vid återställning av lösenord får användaren tillsänt en engångskod till sin epost som användaren sen använder för att skapa ett nytt lösenord. Det blir sparad en hash av koden som genereras istället för att spara koden i klartext i Local Storage. Når det kommer til sikkerhet mot scripting så har AngularJS innebygget beskyttelse mot dette. Scripting vil bli behandlet som ren tekst av AngularJS, og sådan ikke bli kjørt av nettleseren. F.eks hvis en skriver inn noe script kode i quiz-navn feltet, så vil ikke denne koden bli kjørt ved visning av quiznavnet, men snarere bli vist i klartekst. API'et er sikret mot SQL-injection via. bruk av SQL parametre. Verdier som normalt blir plassert i SQL setningen blir registrert som parametre i selve spørringen. SQL-motoren sjekker at verdiene er korrekt for den aktuelle kolonnen, og behandler ikke disse verdiene som endel av selve SQL setningen. Sådan unngår vi at SQL injection kan ta sted Eksempel på bruk av sql-parametre 3.2 FRONT-END I den här delen av produktrapporten går vi igenom front-end för applikationen. Front-end är den delen som användaren ser när den använder applikationen. Här kan användaren upprätta och administrera quiz, se resultater samt ta en quiz. För att kunna administrera en quiz måste användaren upprätta ett konto. Deltagaren behöver inget konto för att ta en quiz utan behöver bara en quiz-id för att anmäla sig på en quiz. Denna quiz-id får deltagaren av den användare som har upprättat quizen. Denna delen innehåller följande avsnitt Struktur och funktion Utformning av användargränssnitt 50

51 Kända fel med applikationen Lista över roller och funktioner Inloggninsdetaljer för adminkonto Besked till användaren Överensstämmelse mellan kravspecifikation och produkt Vidareutveckling STRUKTUR OCH FUNKTION Front-end delen av programmet är utvecklat i AngularJS som är ett front-end javascript-ramverk speciellt utvecklad för att förenkla arbetet med att utveckla en Single Page Application (SPA). En SPA innebär att användaren endast förhåller sig till en HTML sida och all interaktion och data från server föregår i JavaScript på klientsidan. Fördelen med att använda denna form för utveckling är att det blir mindre belastning på serversidan och applikationen upplevs som snabbare och mer responsiv. Lösningen är uppbyggd med en MVC (Model View Controller) arkitektur för att få en god struktur. Model: håller på data View: visar fram data Controller: manipulerer data FILSTRUKTUR Filstruktur för de viktigaste filerna i front-end: /MIMIR /public index.html /javascripts app.js controllers.js Index.html innehåller HTML-grundstrukturen och inkluderar alla skript, navbar, container osv. Detta är applikationens enda HTML sida då applikationen är en SPA. I tillägg är det lagat ett flertal views som ligger i mappen Views. Ett view är en del av en HTML. Via HTML-attributen ng-views i index.html ges besked till Angular när ett bestämt view ska användas. I filen controllers.js ligger alla controllers som mottar input/data, validerar den och därefter utför operationer som ändrar tillstånden i modellen. Under katalogen /public/javascripts finner man filen app.js som innehåller alla URL-ruter och generell konfiguration av applikationen. 51

52 UPPLADDNING AV LJUD OCH BILD Funktionaliteten för uppladdning av ljud och bild till server blir hanterat via en NodeJS modul som heter Multer. Denna modulen säkrar bland annat att varje fil får ett unikt filnavn genom att lägga till tidpunkt för upplastning i filnamnet. Detta för att försäkra om att ingen användare överskriver en annan användares filer. Disse havner i /uploads. BILBLIOTEK MED QUIZER Det är möjligt att skapa ett bibliotek med quizer tillhörande ett bokverk. Varje bokverk har sitt eget adminkonto, exempel på detta kan vara mylder@cappelendamm.no för verket Mylder. Dessa verk kan ses och användas av alla inloggade användare men kan endast redigeras av adminkontot. Dessa bibliotek med quizer är kopplade till en verkslogo och den inloggade användaren väljer då en verkslogo för att få tillgång till biblioteket. Vänligen se användarvägledningen för instruktioner om hur man skapar en quiz. För att få tillgång till ett adminkonto vänligen se avsnittet om Inloggningsdetaljer för adminkonto tillhörande ett bokverk UTFORMNING AV ANVÄNDARGRÄNSSNITT Vi har använt oss av Bootstrap vid utveckling av användargränssnittet. Resultatet är en responsiv design som med hjälp av ett välkänt bibliotek lägger en god grund för vidareutveckling av applikationen. Användargränssnittet är anpassat för både stor och liten skärm vilket gör att den går att använda med dator, surfplatta och telefon Exempelbild på applikationen i liten skärmstorlek 52

53 Exempelbild på applikationen i fullstor skärmstorlek INFORMATIONSARKITEKTUR Informasjonsarkitektur har fokus på organisering, strukturering og merking av innhold på en effektiv måte. Målet er å hjelpe brukerne å finne frem til informasjon eller fullføre oppgaver. En god struktur på applikasjonen er utrolig viktig for at brukerne skal finne frem til akkurat den informasjonen de leter etter. En god informasjonsarkitektur kan stå for over 60 80% av brukervennligheten på nettstedet, og hvis denne feiler, blir resultatet derfor ofte svært dårlig. Av den grunn har informasjonsarkitekturen vært en viktig del av utviklingen av denne applikasjonen. Organiseringsstrukturer er en viktig del av informasjonsarkitekturen til en applikasjon. En organisationsstruktur är en struktur som definierar relationerna mellan olika grupper och innehållselement på en sådan webbplats. En organiseringsstruktur visar också hur användaren kan navigera sig på webbsidan. (Fagernes, Organiseringssystemer, 2015) Denna applikationen har en organisationsstruktur som är hierarkisk och bred. En hierarkisk struktur er en av de vanligste strukturene som er brukt på nettsider og applikasjoner, och den är så kallad top-down tilnærming. Enkelt sett är det huvudkategorier som blir till underkategorier uppifrån till ned. Denna strukturen är lätt för en användare att känna igen då den är intuitiv och används därför ofta på andre webbsidor og applikasjoner. I informasjonsarkitekturen skilles det mellan en djup och bred struktur, där en bred struktur kännetecknas av många kategorier med få underkategorier till skillnad från en djup struktur där det är ett flertal underkategorier som ligger under ett mindre antal huvudkategorier. En djup struktur kan leda till att det tar längre tid för användaren att finna fram då det kräver fler klick för att gå igenom alla underkategorierna. En bred struktur kan göra det svårt får användaren att välja rätt kategori så det bästa är oftast att ha en god balans mellan djup och bred struktur. Denna applikationen har inga underkategorier då alla val i navigeringsmenyn leder direkt till den tillhörande sidan, vilket ger en väldigt bred struktur. 53

54 Menyn på toppen av applikationen är en global meny och visas oavsett var du är på webbsidan Exempelbild på global meny i applikationen Labels og navngiving er viktig innenfor informasjonsarkitekturen til en applikasjon. Grunnen til dette er at det er disse virkemidlene som hjelper brukeren å finne akkurat den informasjonen han/hun er ute etter. En label eller «merkelapp» representerer en informasjonsblokk på web. Ved å bruke gode labels og navn vil det bli enklere for brukeren å søke igjennom nettsiden fordi menyvalgene er intuitive. (Fagernes, "Labeleing": Merking av innhold, 2015) Det finnes fire måter man kan bruke tekst labels på. Kontekstuelle lenketekster, overskrifter, valgmuligheter i en navigeringsmeny og søkeord/metadataens-labels. I denne applikasjonen er det blitt brukt små ikoner sammen med overskriftene i navigeringsmenyen. Disse er med på å gjøre det enklere å forstå hva som skjuler seg bak de forskjellige alternativene. Overskrifter beskriver innholdet i informasjon bolken som under overskriften. Det bør komme tydelig fram på nettsider hva som er overskriften for å unngå forvirring for brukerne. (Fagernes, "Labeleing": Merking av innhold, 2015) Det har blitt gjort tydelig hva som er overskriftene i applikasjonen ved hjelp av størrelse og tykkelse på teksten. Overskriftene er større og tykkere enn resten av teksten og beskriver godt hva teksten under inneholder. Det finns ingen sökfunktion i applikationen. Vi har inte sett ett behov för en sökfunktion som applikationen ser ut just nu då det inte finns några dokument sparade i applikationen och inget flertal underkategorier eller sidor. Vi ser möjligtvis ett behov för en sökfunktion på resultatsidan om resultatsidan blir väldigt stor och användaren vill gå tillbaka längre bak i tiden för att se ett resultat, eller om användaren vill se ett resultat för en särskild person eller grupp. Detta är något som vi har tänkt att version 2 av applikationen bör innehålla. Den globala menyn har en logo som fungerar som en länk till en lista över de olika verk användaren kan välja. Till varje verk finns redan inlagda quiz. Denna logon är en verkslogo och ändras beroende på vilket verk och vilka quiz användaren önskar att använda. Den globala menyn är en subjektiv hybrid med metoderna Uppgift och Tema. Metoden Uppgift frågar vad användaren vill göra medan metoden Tema frågar vad användaren är intresserad i. (Fagernes, Grupperingsmetoder, 2014) Exempel på detta är Ny quiz - Användaren vill skapa en ny quiz och Resultater - Användaren är intresserad i vilka resultat deltagerna har fått på quizen. FARGEVALG En viktig del av applikasjonens brukergrensesnitt er farger. Brukeropplevelsen kan endres drastisk om fargevalgene i applikasjonen kolliderer med hverandre. I mange applikasjoner er det vanlig å bygge opp brukergrensesnitt med mye fokus på harmoni og balanse. Nærliggende farger på fargespekteret skaper ofte en dette. Rent stilmessig blir designet også penere. 54

55 I denne applikasjonen har vi først og fremst benyttet nyanser av fargene blå og grønn. Disse er begge nærliggende i fargespekteret og gir brukergrensesnittet et rent stilpreg. Applikasjonens hovedbakgrunn har fått en lysegrå farge og selve innholdet har fått hvit bakgrunn. Dette er for å skape kontrast mellom innhold og bakgrunn og på denne måten gjøre innholdet lettere å lese. For å drive oppmerksomhet til et spesielt sted i brukergrensesnittet er det vanlig å bruke farger som er direkte kontraster (farger på motsatt side av fargespekteret) av hverandre. Ved tilbakemelding til brukeren når det for eksempel ikke blir skrevet i et input-felt, er tilbakemelding i fargen rød. Denne fargen er på motsatt side av fargespekteret for blå og grønn og gjør at oppmerksomheten rettes mot dette elementet. Andre elementer i brukergrensesnittet som har fått fargen rød er slett-spørsmål knappen og minus-knappen i svaralternativer, på ny-quiz siden. UNIVERSELL UTFORMNING Universell utforming er en viktig del av utviklingen av en applikasjon. Universell utforming er et begrep innen samfunnsplanlegging, design og produktutvikling. Den grunnleggende ideen bak universell utforming er å utforme samfunnet slik at så mange som mulig kan delta aktivt uavhengig av funksjonsevne. Begrepet «universell utforming» blir brukt synonymt med «design for alle», «universell design» og «tilgjengelighet for alle». Målet er at universelt utformede løsninger skal kunne brukes av alle, slik at spesialløsninger unngås. (Wikipedia, 2016) I løpet av utviklingsprosessen i denne prosjektperioden har det hele tiden vært stort fokus på universell utforming. Grunnen til dette er først og fremst at vi måtte ta hensyn til applikasjonens målgruppe, alle fra grunnskolen og oppover. Ingen mennesker er like og det finnes mennesker med ulik funksjonsevne. Applikasjonen måtte derfor få enkle farger og et enkelt design slik at den ble tilgjengelig for alle, men samtidig inneholde alle nødvendige funksjoner. Det är använt enkla färgskalor, mörk bakgrund med ljus text eller ljus bakgrund med mörk text. Detta för att göra det enklare för exempelvis svagsynta eller färgblinda att urskilja text från bakgrund. Det är dock inte möjligt att använda applikationen i högkontrast-modus. Applikationen är för tillfället endast på norska (bokmål).det är inte implementerat någon funktion för att ändra texten till en större storlek för personer med dålig syn och det är inte heller möjligt att få text uppläst för användaren. Det är dock möjligt att zooma in/göra texten större via webbläsaren. Det är implementerat så kallade tooltips som visar vad en funktion gör eller vad en text betyder genom att hålla muspekaren över den. I tillägg finns det också en FAQ-sida där man kan få svar på de vanligaste frågorna. 55

56 Exempelbild på tooltip Största delen av funktionaliteten finns på användardelen på applikationen. Här har vi använt oss av enkla självförklarande menyval som till exempel Ny Quiz för att laga en quiz, Resultat för att se resultat, Mine quizer för att se sina quiz eller Ta quiz för att ta en quiz. Det ska vara enkelt att navigera sig dit man vill och liten risk för att göra fel. Det är användaren som skapar ett quiz. Användaren har då möjlighet att anpassa quizen för de deltagare som ska ta en quiz. Exempel på detta kan vara att anpassa språket eller språkbruket, använda mer bilder än text eller att skriva ut frågorna på ett papper till deltagaren. Användaren styr även själv quizen och bestämmer då när deltagarna är redo för nästa fråga. Frågorna kan vara i text, ljud eller video men svarsalternativen är för tillfället endast i text vilket gör att man kan inte fullt ut anpassa applikationen för en person med exempelvis synnedsättning. Användaren har som tidigare nämnt möjlighet att själv styra quizen och kan då läsa upp svarsalternativen för deltagaren men detta är inte en optimal lösning. I en vidareutveckling borde applikationen anpassas för en mer universell utformning genom bland annat ha möjligheter för att; Ändra storlek på text Ändra språk Se den i högkontrast Möjlighet för att sätta ljud på svarsalternativ KÄNDA PROBLEM MED APPLIKATIONEN Det problem som vi känner till hittills med applikationen är följande: Youtube video kan ikke alltid lastes Det hender at YouTube videoer ikke alltid kan spilles av, med beskjed "Something went wrong" i avspillervinduet. Det er gjort mye undersøkelser rundt hva som kan ligge til bakgrunn for dette, og slik det ser ut i dag så ser feilen ut til å være relatert til WebGL biblioteket som YouTube API'et benytter seg av. Dette virker å være noe utenfor vår kontroll, uten at vi kan si noe sikkert her. 56

57 3.2.4 LISTA ÖVER ROLLER OCH FUNKTIONER I det här avsnittet beskrivs det vad de olika rollerna kan och inte kan göra samt vilka funktioner de två olika quiz-alternativen i applikationen har. Rollerna är uppdelade i inloggad användare, den som upprättar ett konto för att administrera quizer, och deltagare som är den som tar en quiz. I applikationen finns det möjlighet att på förhand lägga in quizer som sen finns tillgängliga för alla användare. Dessa inlagda quizer är kopplade till olika bokverk som exempelvis Faktor, Radius eller Mylder. Funktionen för dessa quizer skiljer sig från de quizer som användaren själv lagar och är därför listade nedan för att ge en översikt över vad de gör och inte gör. I användarvägledningen kan man mer ingående läsa om vad programmet gör och vad man måste göra för att uppnå önskat resultat. Listorna är uppdelade på följande sätt: Som inloggad användare kan jag Som deltagare kan jag Som inloggad användare kan jag INTE Som deltagare kan jag INTE Inlagda quiz kopplade till ett verk kan Inlagda quiz kopplade till ett verk kan INTE Quiz skapad av en användare kan Quiz skapad av en användare kan INTE Som inloggad användare kan jag Som deltagare kan jag upprätta en quiz ta en quiz som en individuell person välja vilket modus en quiz ska vara i ta en quiz som en grupp välja vilken typ av frågor som ska vara med i quizen välja hur många frågor jag vill ha med i quizen välja hur många svaralternativ som ska höra till en fråga välja ett verk via en verkslogo ta en quiz på en dator ta en quiz på en telefon ta en quiz på en surfplatta ta en quiz på ett papper redigera en quiz se mitt resultat radera en quiz se de tre bästa resultaten se mina quizer se redan inlagda quizer för ett verk se direkt vilket svar som är rätt eller fel när jag tar en se resultaten för mina egna quizer 57

58 se allas resultat för redan inlagda quizer ändra mitt lösenord starta en quiz i felles-modus printa ut en quiz på ett papper printa ut ett facit på ett papper styra quizen genom att bestämma när nästa fråga ska starta Inlagda quiz kopplade till ett bokverk kan endast raderas av den admin som skapade quizen endast redigeras av den admin som skapade quizen ses av alla inloggade användare tas av alla deltagare Inlagda quiz kopplade till ett bokverk kan INTE raderas av en annan inloggad användare redigeras av en annan inloggad användare visa resultat om den är tagen i individuell modus tas i felles-modus om den startas av en inloggad användare tas i individuell modus visa resultat om den är tagen i ett felles-modus endast visa resultatet till den användare som har startat quizen i felles-modus Quiz skapad av en användare kan ses av den användare som skapade quizen redigeras av den användare som skapade quizen raderas av den användare som skapade quizen tas i felles-modus om den startas av användaren tas i individuell modus Quiz skapad av en användare kan INTE ses av någon annan än den användare som skapade quizen redigeras av någon annan än den användare som skapade quizen raderas av någon annan än den användare som skapade quizen visa resultat till den användare som har skapat quizen 58

59 3.2.5 INLOGGNINSDETALJER FÖR ADMINKONTO Bokverk Användarnamn Lösenord Faktor Ta kontakt eller benytt "Glemt passord" funksjonalitet i applikasjon Radius radius@cappelendamm.no Ta kontakt eller benytt "Glemt passord" funksjonalitet i applikasjon Mylder mylder@cappelendamm.no Ta kontakt eller benytt "Glemt passord" funksjonalitet i applikasjon Nova nova@cappelendamm.no Ta kontakt eller benytt "Glemt passord" funksjonalitet i applikasjon BESKED TILL ANVÄNDAREN Här beskrivs de olika besked som ges till användaren beroende på vad användaren försöker göra och vad resultatet blir. När användaren ska logga in ges besked om att användaren måste skriva in en giltig epostadress och lösenord. Dette skjer dersom brukeren har trykket på, og gått vekk fra et av feltene uten å ha tastet inn noe Bild på Logg Inn Besked till användaren 59

60 När användaren har loggat in får användaren besked om att välja ett bokverk för att på så vis få tillgång till alla quizer som hör till det bokverket. Det är inte möjligt att se resultater, skapa en ny quiz eller se egna inlagda quizer innan man har valt ett bokverk Bild på Velg Verk - Besked till användaren Om användaren upprättar en quiz inne på Ny Quiz måste användaren välja vilken av svarsalternativen är riktig, annars kommer man inte vidare Bild på Opprett en quiz - Besked till användaren Om användaren vill radera en quiz inne på Mine Quizer får användaren besked om att bekräfta att den önskar göra detta. 60

61 Bild på Slett quiz- Besked till användaren När användaren vällyckat har upprätt en quiz får användaren besked om det Bild på Quiz opprettet - Besked till användaren Om användaren mister tillgång till internet får användaren detta beskedet om användaren trycker på Mine Quizer Bild på Mine Quizer - Besked till användaren Om användaren trycker på Resultater men inte har några registrerade resultat, får användaren detta beskedet med en länk till att ta en quiz Bild på Resultater - Besked till användaren 61

62 Om användaren trycker på Mine Quizer men inte har några egna quizer sparade får användaren detta beskedet med en länk till att upprätta en ny quiz Bild på Mine Quizer - Besked till användaren När en deltagare vill ta en quiz måste deltagaren anmäla sig på en quiz. När deltagaren trycker på Meld deg på får deltagaren besked att vänta tills användaren startar quizen. Användaren styr quizen och startar den när exempelvis alla som ska vara anmälda på quizen är anmälda eller vid en speciellt tidspunkt Bild på Ta quiz - Besked till användaren Om en deltagare försöker anmäla sig på en quiz men för exempel förlorar tillkoppling till internet eller skriver in en QuizID som inte finns, får deltagaren detta beskedet Bild på Påmelding av quiz- Besked till användaren 62

63 Om man använder en webbläsare som applikationen inte stöder får man besked om detta Exempelbild på besked om applikationen inte stöder webläsaren ÖVERENSTÄMMELSE MELLAN KRAVSPECIFIKATION OCH PRODUKT De flesta av de funktionella krav som var med i kravspecifikationen har blivit implementerade medan några funktionella krav under processen ansågs som ej nödvändiga. I tillägg har det blivit implementerat funktioner som inte var med i kravspecifikationen. Dessa nya funktionerna är: Visa de tre bästa resultaten Verkslogo kopplad till redan inlagda quizer Detta innebär att en deltagare kan vid quizens slut se de tre bästa resultaten i omgången. Resultaten är dock inte rankade som då det är en viktig aspekt att vi inte ska skapa förlorare. En verkslogo kopplad till redan inlagda quizer innebär att varje bokverk kommer med ett bibliotek av quizer. För att få tillgång till dessa quizer måste användaren välja ett bokverk. I avsnittet Lista över roller och funktioner kan man läsa mer ingående om vad skillnaden mellan dessa quizer är från de quizer en användare själv skapar. De funktionella krav som togs bort var: Max 30 frågor Max tre svaralternativ URL ved påmelding av quiz Istället för att ha en övre gräns på svarsalternativ är det satt en nedre gräns på minst 2 stycken svarsalternativ. Användaren kan själv välja hur många fler alternativ som en fråga ska ha. Det samma gäller antall frågor. I stedet for å benytte en egen URL for hver quiz, så ble det valgt å benytte ID'er i stedet. Deltakere skriver inn ID'en for den quizen de ønsker å melde seg på i applikasjonen. Rent praktisk fungerer dette bedre, da en kode er betydelig lettere å dele enn en url-link. Av krav som ikke ble implementert på bakgrunn av tidsrammen, så finner vi lydavspilling av spørsmålstekst, samt endring av rekkefølge på spørsmål. 63

64 3.3 VIDAREUTVECKLING Själva planen med applikationen är det ska vara möjligt och enkelt att vidareutveckla den efter behov. Det som först och främst borde vidareutvecklas är den universella utformningen av användargränssnittet. Detta går att läsa mer om i avsnittet Utformning av användargränssnitt. Vi rekommenderar att applikationen blir testad av en person med särskilda behov för att finna ut av vilka behov för universell utformning det finns för applikationen. I tillägg hade vi kunnat se implemetering av följande funktioner: - För tillfället kan deltagaren direkt se vilket svar som är rätt eller fel när deltageren har svarat på en fråga. Vi kan se att det kan vara en nackdel med detta då det finns deltagare som inte svarar lika fort som en annan deltagare. Den deltagaren kan då se vilket svar som är rätt. En funktion för användaren att själv bestämma om rätt svar ska visas under spelets gång eller när det eventuellt ska visas kan implementeras i framtiden. - Användaren som styr quizen, Quizmastern, kan per idag inte se när alla deltagare har svarat på en fråga. Quizmaster väljer själv när man ska gå vidare till nästa fråga och de som inte har svarat i tid får då noll poäng. En funktion som visar Quizmaster hur många som har svarat på en fråga kan implementeras i nästa version. - En annan funktion som projektgruppen har övervägt är om quizen ska gå vidare automatisk när alla deltagare har svarat. För tillfället är det Quizmaster som styr när nästa fråga ska starta. - Med varje bokverk finns det möjlighet att upprätta bibiliotek med inlagda quizer som är tillgängliga för alla inloggade användare. Vi tänker att för framtiden borde det implementeras för deltagare en meny med dessa quizer och tillhörande Quiz-ID så att en deltagare kan ta dessa quizer i individuellt modus. Resultat vill då inte sparas men deltageren kan använda dessa quizer som övning. - I denna version får deltagaren 10 poäng per fråga men det kan vara önskvärt att användaren själv bestämmer hur många poäng en fråga ska vara värd. - En søkefunksjon blant quizer og resultater vil forenkle arbeidet med å finne fram en bestemt quiz eller resultat dersom det finnes mange av disse. - I denne versionen er det ikke muligt å endre rekkefølge på spørsmål. Dette var et av kravene i kravspesifikasjonen vi ikke fikk tid til å implementere. - I neste version borde statiske ressurser (bilder og lydfiler) slettes ved sletting av hele quizer. Dette før å frigjøre lagringsplass på server, og hindre at det blir brukt unødig lagringsplass på ressurser som ikke lenger er i bruk. - Vid vidareutvikling kan det være aktuelt å implementere inlogging ved bruk av OAuth for innlogging via sosiale medier. API'et lagt opp til at dette skal kunne gjøres uten store problemer, ettersom det allerede benytter seg av JSON web tokens for autentisering. Det er imidlertid diskuterbart hvorvidt dette er hensiktsmessig eller ønskelig i en slik applikasjon å koble den opp mot sosiale medier. 64

65 4 TESTDOKUMENTATION LESERVEILEDNING Denna delen av rapporten beskriver vilka tester som har blivit utförda på applikationen samt vad som ligger till grund för de tester vi har valt och de tester vi inte har valt. Testdokumentation innehåller följande avsnitt: Test av API Test av operativsystem Funktionstest Säkerhetstest Enhetstest Användartester Konklusion av samtliga tester TEST AV API För att testa ut applikationens API har projektgruppen använt sig av en tjänst som heter Postman. Detta är en gratistjänst som testar vilken Json-format som kommer ut av applikationens API. Då applikationens API inte har något GUI (grafiskt användargränssnitt) har detta varit absolut nödvändigt för att testa APIet. TEST AV OPERATIVSYSTEM Projektgruppen har använt sig av en hemsida som erbjuder en tjänst för att testa en applikation för olika webbläsare. Detta är en tjänst man köper och projektgruppen anser att det är en god investering då det absolut är en viktig del av testingen. FUNKTIONSTEST Projektgruppen har inte haft en testplan för funktionstester. Funktionstester har blivit gjorda kontinuerligt efter varje implementerad funktion innan vi har gått vidare till nästa funktion. Projektgruppen har testat samtliga funktioner varje gång en ny funktion har blivit implementerad för att upptäcka eventuella fel. I tillägg testas funktionerna vid användartesterna. 65

66 SÄKERHETSTEST Den säkerhetstesting som har blivit gjord är test av inloggningsfunktion och återställning av lösenord. Vid återställning av lösenord får användaren tillsänt en engångskod till sin epost. Det upptäcktes då att vid utsändningen av denna engångskoden blev den sparad i klartext i Local Storage. Detta innebär att det är möjligt att få tag på engångskoden vilket innebär en säkerhetsrisk. Detta blev löst genom att sända engångskoden krypterad genom att skapa en hash av engångskoden. ENHETSTEST Projektgruppen tog tidigt beslutet att inte skriva egna enhetstester. Grunden till detta var tidsramen för vilket projektet skulle vara färdigt inom. Projektgruppen saknar även kompetensen för att kunna skriva väl fungerande enhetstester vilket gör att risken för att enhetstesten blir utfört med en ej funktionell enhetstest. 4.1 ANVÄNDARTESTER Vi har haft tre olika användartester under projektets gång. Dessa har haft som mål att testa användarvänligheten och även funktionaliteten. Två av testpersonerna har varit oavhängiga av projektet och har varierat i ålder och kön medan den tredje testpersonen har ett intresse i slutprodukten. Fokus har varit på användarvänligheten för användaren som ska upprätta en quiz då den mesta av funktionaliteten ligger på användardelen av systemet. Funktionen för att ta en quiz består endast av funktion för att logga på en quiz samt val av svarsalternativ till en fråga. I användartest 1 ska testperson upprätta ett användarkonto, logga in och upprätta en quiz. Denna test ska genomföras den 8/ I användartest 2 ska testperson ändra en existerande quiz och se resultatöversikten. Denna test ska genomföras den 6/ I användartest 3 ska testperson upprätta en quiz, starta en quiz, anmäla seg på en quiz och ta en quiz. Denna test ska genomföras den 12/ Testpersonerna ska få förklarat vad målet med testet är och kort förklarat hur applikationen fungerar. Testpersonerna ska sedan själva navigera sig fram i applikationen för att lösa den uppgift testpersonen har fått ANVÄNDARTEST 1 TESTPLAN 66

67 MÅL Målet med användartest 1 är att se användarvänligheten och funktionaliteten för följande funktioner: Upprätta användarkonto Logga in Upprätta en quiz UTFÖRANDE För att testa dessa funktioner ska en person, oberoende till projektet, genomföra dessa 3 moment steg för steg. Projektgruppen kommer då att observera för att se hur lätt det är för testpersonen att navigera sig fram i applikationen, om utformningen av applikationen är intuitiv samt se funktionaliteten för dessa funktioner. Användartest 1 är planerad att utföras den 8/ TESTRAPPORT BESKRIVNING AV TEST Testperson för användartest 1 var en man mellan år. Testen blev utförd på HIOA den 8/ Test som först blev utfört var upprättning av användarkonto. Efter det fick testperson logga in och upprätta en quiz. Testperson fick utan hjälp från projektgruppen själv navigera sig fram i applikationen för input av data. Testen blev utfört med Safari som webbläsare. RESULTAT AV ANVÄNDARTEST 1 Testperson upplevde inga problem med att upprätta ett konto och logga in men testperson saknade en funktion för glömt lösenord. Testperson kände även att funktionen för att upprätta en quiz hade för många steg då testperson först måste skriva in namn och genre på quiz för att sen gå vidare till upprättning av frågor och svar. Detta kan istället göras enklare i ett steg. KOMMENTAR TILL RESULTAT Funktion för glömt lösenord är planerad att implementeras senare i projektet. Projektgruppen är enig med testperson att funktionen för att upprätta quizen kan göras i ett steg istället för flera. KONKLUSION AV ANVÄNDARTEST 1 Ta bort det första steget i funktionen för att upprätta en quiz där användaren ger sin quiz ett namn och en genre. Tillrättalägger funktionen så att detta kan göras i ett steg. 67

68 4.1.2 ANVÄNDARTEST 2 TESTPLAN MÅL Målet med användartest 2 är att se användarvänligheten och funktionaliteten för följande funktioner: Ändra en existerande quiz Se resultatöversikt UTFÖRANDE För att testa dessa funktioner ska en person, oberoende till projektet, genomföra dessa 2 moment steg för steg. Projektgruppen kommer att observera för att se hur lätt det är för testpersonen att navigera sig fram i applikationen, om utformningen av applikationen är intuitiv samt se funktionaliteten för dessa funktioner. Användartest 2 är planerad att utföras den 6/ TESTRAPPORT BESKRIVNING AV TEST Testperson var en kvinna mellan år. Testen blev utförd på HIOA den 6/ Testperson skulle ändra existerande quiz samt se resultatöversikten. Projektgruppen förklarar vad testen går ut på och kort hur applikationen fungerar. Projektgruppen har redan loggat in med en användare och lagt in quiz innan testperson startar testen. Testperson fick utan hjälp från projektgruppen själv navigera sig fram i applikationen för input av data. Testen blev utfört med Chrome som webbläsare. En fungerande resultatöversikt hade ännu inte implementeras vi tidpunkt för test. RESULTAT AV ANVÄNDARTEST 2 Testperson har inga problem med att navigera sig fram till önskad funktion. Testperson får dock inte upp en bekräftelse vid val av Slett. Testperson föreslår att detta implementeras så att användare inte raderar en fråga av misstag. KOMMENTAR TILL RESULTAT Varningar vid val som Slett är planerade att implementeras under projektets gång. 68

69 KONKLUSION AV ANVÄNDARTEST 2 Resultatöversikt ska implementeras. Varningar vid val som Slett ska implementeras ANVÄNDARTEST 3 TESTPLAN MÅL Målet med användartest 3 är att se användarvänligheten och funktionaliteten för följande funktioner: Upprätta en quiz Starta en quiz Anmäla sig på en quiz Ta en quiz UTFÖRANDE För att testa dessa funktioner ska en person, oberoende till projektet, genomföra detta steg för steg. Projektgruppen kommer då att observera för att se hur lätt det är för testpersonen att navigera sig fram i applikationen, om utformningen av applikationen är intuitiv samt se funktionaliteten för dessa funktioner. Användartest 3 är planerad att utföras den 12/ TESTRAPPORT BESKRIVNING AV TEST Testperson var en man mellan år. Testen blev utförd hos Cappelen Damm den 12/ Testperson skulle upprätta en quiz, starta en quiz, anmäla seg på en quiz og ta en quiz. Testperson fick utan hjälp från projektgruppen själv navigera sig fram i applikationen för input av data. Testen blev utfört med Safari som webbläsare. RESULTAT AV ANVÄNDARTEST 3 Testperson klarade av att upprätta en quiz och ta en quiz. Testperson framförde dock en önskan om någon form av väglednings-sida, FAQ-sida eller någon annan typ av hjälpmedel. Testperson var mycket positiv till utformning av applikationen men önskade att det fanns färdiga quiz inlagda i applikationen. Då detta är en applikation även riktad mot grundskolebarn var det viktigt att 69

70 inte skapa förlorare, så testperson önskade endast att de 3 bästa resultaten skulle visas när en quiz var färdig. Under testen upptäcktes ett fel vid visning av video i quiz. KOMMENTAR TILL RESULTAT Testperson önskar funktioner som inte var med på kravspecifikationen så projektgruppen måste överväga om det är möjligt att implementera dessa funktioner inom tidsfristen. Dessa funktioner är att visa de 3 bästa resultaten och färdiga quiz inlagda i applikationen. Projektgruppen måste felsöka funktionen för visning av video. KONKLUSION AV ANVÄNDARTEST 3 En funktion för att hjälpa användaren var planerad att implementeras. Gruppen överväger vilken form av hjälpmedel som är den bästa. Om det är möjligt att färdigställa inom tidsfristen ska en funktion för att visa de 3 bästa resultaten implementeras. Detta gäller även för färdiga quiz kopplade till bokverk i applikationen. 4.2 KONKLUSION AV SAMTLIGA TESTER Produkten har inte blivit testad på användare med behov för särskild utformning så det är svårt att säga om produkten har en tillräckligt universell utformning. Användartester för personer med särskilda behov borde bli utfört för att få et optimalt produkt. Det sparas ingen sensitiv information om användarna så det har inte varit något behov för att säkra något annat än inloggningsfunktionen och funktion för återställning av lösenord. Vid testen av dessa två funktioner upptäcktes en svaghet i att engångskoden som blev sänt till användaren, vid återställning av lösenord, blev sparad i klartext i Local Storage. Detta löstes genom att spara en hash av engångskoden istället. Användartesterna har upptäckt få fel med applikationen men har gett projektgruppen en bättre bild av vad som kan förbättras för att göra applikationen enklare att använda. Projektgruppen har även fått önskemål om nya funktioner som inte fanns med i den ursprungliga kravspecifikationen. Dessa funktioner går att läsa mer om i avsnittet «Överenstämmelse mellan kravspecifikation och produkt» i Produktrapporten. 70

71 5 ANVÄNDARVÄGLEDNING LESERVEILEDNING Applikationen blev utvecklad i samarbete med Cappelen Damm Undervisning och fungerar som ett digitalt inlärningsverktyg i form av en quizapplikation. Användaren skapar en quiz och deltagaren tar quizen. Applikationen är uppdelad i en användardel och en deltagardel. Funktionaliteten ligger i huvudsak på användardelen av applikationen. Här upprättar en användare ett användarkonto för att kunna skapa och administrera quiz. Deltagardelen av applikationen är riktad mot deltagaren och har endast en funktion för att ta en quiz. I denna manual finner du information om vad varje del av applikationen kan göra och hur man använder den. Manualen är i första hand riktad mot användaren som ska använda användardelen av applikationen och även förklara för deltagarna hur de ska göra för att starta en quiz. Användarvägledningen innehåller följande delar: Ord och uttryck Vad gör användardelen av applikationen? Hur använder man användardelen? Vad gör deltagardelen av applikationen? Hur använder man deltagardelen? 5.1 ORD OCH UTTRYCK ANVÄNDARDELEN Administrations-delen. Den del av applikationen som användaren använder för att skapa en quiz, se resultat, ändra en quiz. Här har användaren tillgång till samtliga funktioner i applikationen. DELTAGARDELEN Den del av applikationen som är riktad mot deltagaren som ska ta en quiz. Deltagardelen har endast en funktion för att ta en quiz. BOKVERK Ett bokverk är en volym med böcker. I detta fall läroböcker. VERKSLOGO Den logo som hör till ett bokverk. 71

72 5.2 ANVÄNDARDELEN VAD GÖR ANVÄNDARDELEN AV APPLIKATIONEN? Upprättar en användare Loggar in Väljer bokverk från Cappelen Damm Upprättar en quiz Ser egna quizer Ser redan inlagda quiz tillhörande ett bokverk Väljer modus på quiz Skriver ut svarsschema i pappersformat Skriver ut facit i pappersformat Startar quiz i fellesmodus Sätter quiz i individuell modus Ändrar en existerande quiz Ser resultater Ändrar lösenord Loggar ut HUR ANVÄNDER MAN ANVÄNDAREDELEN? För att börja använda användardelen av applikationen måste du ha tillgång till en dator med en webbläsare om uppfyller följande krav: ios safari 6 och nyare versioner. Firefox 21 och nyare versioner. Opera 25 och nyare versioner. Safari 6 och nyare versioner. Android 4 och nyare versioner. Microsoft Edge Delvis støtte for Internet Explorer 10 og 11 Applikationen stöder inte tidigare versioner av Internet Explorer enn 10 og 11. Du måste även ha tillgång till internet. För att få tillgång till systemet måste du logga in med användarnamn och lösenord. Detta upprättar du själv genom att välja Opprett konto. 72

73 Bild på Startside UPPRÄTTA EN ANVÄNDARE Välj Opprett konto i menyn på toppen. Fyll ut din epostadress och välj ett lösenord Exempelbild på Opprett Konto LOGGA IN Välj Logg inn i menyn på toppen. Skriv in din epostadress och ditt lösenord Exempelbild på Logg inn 73

74 VÄLJ BOKVERK Välj det bokverket du önskar för att få tillgång till bibliotek med quizer Exempelbild på Velg bokverk UPPRÄTTA EN QUIZ Välj «Ny Quiz» i menyn på toppen. 1. Skriv in ett namn på Quiz. 2. Välj vilken typ av fråga du vill ha - Text, Bild, Ljud eller Video. 3. Skriv in en fråga. 4. Skriv in svarsalternativ. Du kan välja själv hur många alternativ du önskar. 5. Välj vilket svarsalternativ som är korrekt. 6. Önskar du att göra fler frågor, välj «Neste». 7. Vill du gå tillbaka och se eller ändra tidigare frågor väljer du «Forrige». 8. Önskar du att radera en fråga trycker du på Slett. 9. När du är färdig med din quiz väljer du Ferdig Exempelbild på Ny Quiz

75 SE EGNA QUIZER Välj Mine quizer i menyn på toppen. Här kan man se vilken ID en quiz har Exempelbild på Mine Quizer SE REDAN INLAGDA QUIZER TILLHÖRANDE ETT BOKVERK Välj Mine quizer i menyn på toppen. Under verkslogon kan du se alla inlagda quizer som tillhör bokverket Exempelbild på Mine Quizer - Quiz tillhörande ett bokverk 75

76 VÄLJ MODUS PÅ QUIZ Välj mellan individuell eller felles-modus Exempelbild på Mine Quizer välj modus SKRIV UT SVARSCHEMA I PAPPERSFORMAT Välj Mine Quizer i menyn. Tryck på den gröna knappen med en vit pil för att se fler alternativ. Välj Print svarskjema Exempelbild på Mine Quizer Print Svarsskjema 76

77 SKRIV UT FACIT I PAPPERSFORMAT Välj Mine Quizer i menyn. Tryck på den gröna knappen med en vit pil för att se fler alternativ. Välj Print svarskjema m/ fasit Exempelbild på Mine Quizer Print Svarsskjema m/fasit STARTA QUIZ I FELLESMODUS Välj Mine Quizer i menyn. Finn den quiz du önskar att starta. Välj fellesmodus du önskar att starta quizen med. Du kan se hur många som är anmälda på quizen. När önskat antal personer är anmälda på quizen trycker du på Start quiz Exempelbild på Mine Quizer Start Quiz fellesmodus 77

78 QUIZ I INDIVIDUELL MODUS Välj Mine Quizer i menyn. Finn quizen. Välj individuell modus. När quizen är satt i individuell modus kan deltagaren när som helst ta quizen. Användaren behöver då alltså inte starta quizen Exempelbild på Mine Quizer Quiz Individuell modus ÄNDRA EN EXISTERANDE QUIZ Välj Mine quizer i menyn på toppen. Finn den quiz du önskar att ändra på. Tryck på den gröna knappen med en vit pil på för att få upp fler alternativ. Välj Endre. När du är färdig med dina ändringar trycker du på Ferdig Exempelbild på Mine Quizer Endre 78

79 SE RESULTATER Välj Resultater i menyn på toppen Exempelbild på Resultater ÄNDRA LÖSENORD Välj Endre passord i menyn. För att ändra ditt lösenord går du igenom 3 steg. Steg 1: Skriv in din epostadress. Tryck Send kode. En engångskod blir sänt till din epostadress. Steg 2: Skriv in engångskoden. Steg 3:Välj en ny kod Exempelbild på Logg ut LOGGA UT Välj Logg ut i toppen på menyn Exempelbild på Logg ut 79

80 5.3 DELTAGARDELEN VAD GÖR DELTAGARDELEN AV APPLIKATIONEN? Tar en quiz För att börja använda deltagardelen av applikationen måste du ha tillgång till en dator, telefon eller surfplatta med en webbläsare om uppfyller följande krav: ios safari 6 och nyare versioner. Firefox 21 och nyare versioner. Opera 25 och nyare versioner. Safari 6 och nyare versioner. Android 4 och nyare versioner. Microsoft Edge Internet Explorer 10 og 11 Applikationen stöder inte tidigare versioner av Internet Explorer enn 10 og 11. Du måste även ha tillgång till internet. Du behöver inte ha ett användarkonto för att ta en quiz HUR ANVÄNDER MAN DELTAGARDELEN? TA EN QUIZ Välj Ta Quiz i menyn. Skriv först in den Quiz ID du har fått utdelad från Admin. Skriv sen in ditt namn eller namnet på din grupp. Tryck på Meld deg på Exempelbild på Quizpåmelding Quizen startar först när användaren trycker på start Exempelbild på Venter på quizmaster 80

81 6 AVSLUTTENDE DEL LESERVEILDNING Dette er den avsluttende delen av sluttrapporten hvor vi konkluderer, forteller om selve sluttproduktet, videreutvikling av denne og gruppens læringsutbytte etter prosjektperioden. 6.1 SLUTTPRODUKTET I løpet av prosjektperioden har vi arbeidet intensivt og målrettet mot et godt sluttprodukt som oppdragsgiver skulle bli fornøyd med. Vi har klart å oppfylle de fleste kravene som er satt i kravspesifikasjonen, i tilegg til noe øvrig funksjonalitet. Sluttproduktet er en ferdigstilt applikasjon som kan tas i bruk av oppdragsgiver. Det finnes allerede mange quizverktøy applikasjoner på markedet. Hvorfor skal oppdragsgiver da ta i bruk akkurat denne? Hvis vi skal sammenligner produktet vårt med allerede eksisterende produkter vil vi trekke frem noen fordeler med tanke på oppdragsgiver. Den første fordelen med vår applikasjon er at man kan ha ubegrenset med svaralternativer til hvert spørsmål. I eksisterende applikasjoner som for eksempel Kahoot er det fastsatt 4 svaralternativer uansett, noe som gir klare begrensninger i applikasjonen. En annen klar fordel er muligheten for bilde, lyd og video i spørsmålene. Dette gir mange valgmuligheter for den som skal lage quizen og byr på mer fleksibilitet. I tillegg til dette er det mulig å ta quizene både individuelt og i felleskap. Dette er det f.eks. ikke mulig i quizapplikasjonen Kahoot. Den siste og aller viktigste fordelen med applikasjonen vår, når det gjelder oppdragsgiver, er muligheten for at Cappelen Damm kan opprette ferdige quizer som tilhører bestemte bokverk, som igjen da er tilgjengelige for alle innloggede brukere. Dette gjør at applikasjonen blir nærmere knyttet til Cappelen Damm, og gir dem et sted hvor de kan fremme bokverkene sine. 6.2 LÆRINGSUTBYTTE Arbeidet med hovedprosjektet har både vært svært interessant og lærerikt, men samtidig utfordrerne. Hovedgrunnen til dette var at selv om hovedprosjektet var utfordrende nok i seg selv, tok vi i tillegg på oss oppgaven med å ta i bruk et programmeringsspråk og rammeverk som vi ikke kunne fra før. Dette gjorde at prosjektet ble ekstra krevende, men også mye mer lærerikt. Ved å benytte et programmeringsspråk og rammeverk som var ukjent for oss, hadde vi større læringsutbytte enn om vi hadde benyttet oss av noe vi kunne fra før. I tillegg til dette, har gruppen gjennom prosjektperioden tilegnet seg kunnskap og god innsikt i hvordan det er å utføre et oppdrag for en reell oppdragsgiver. Vi har lært hvordan det er å jobbe med IT ute i arbeidslivet og hvordan opptre profesjonelt. Dette er viktig kunnskap og erfaring som kommer godt med ute i arbeidslivet. Å følge utviklingsmetoden Scrum har gitt dette prosjektet en god struktur og en mer profesjonell tilnærming. Ved å benytte oss av denne utviklingsmetoden har vi har lært hvordan man planlegger, 81

82 delegerer og hvordan man skal takle alle utfordringene man kommer bort i når man utvikler et så stort prosjekt. Bruken av denne utviklingsmetoden har derfor på mange måter gitt oss nyttig erfaring som vi kan ta med oss videre i arbeidslivet eller videre studier. 6.3 HVA VILLE VI GJORT ANNERLEDES? Skulle vi startet prosjektet på nytt ville vi forsøkt å få tid til å: - Kjøre enhetstester før Git commits. Hvis en test feiler, så får en heller ikke pushet til Git før problemet er utbedret. Dette er svært hjelpsomt i større prosjekter med mange utviklere, og sikrer at en utvikler ikke pusher kode som kan føre til feil andre steder. - Benytte SCSS (Sass). Dette er en CSS preprossesor (et meta-språk) som kompilerer ned til standard CSS. Sass gjør det mulig å skrive objektorientert CSS, og stiller med støtte for kodeblokker, variabler og konstanter. Standard CSS bryter med "dry-prinsippet" (do not repeat yourself), og Sass har som mål å løse nettopp dette, i tillegg til å gjøre oppgaven med å skrive CSS enklere og lettere å vedlikeholde. - Returnere HTTP statuskoder ved API kall. Dette hadde gjort det lettere å vite hva som eventuelt gikk galt ved et API kall, og derfor også ta avgjørelser i front-end koden på bakgrunn av hvilken statuskode som ble returnert. - Sette oss dypere inn i bruk av services og direvtives i AngularJS. Spesielt sistnevnte er en vesentlig del AngularJS sin funksjonalitet og fordeler. Dette kan imidlertid også argumenteres for å være det mest komplekse aspektet av AngularJS, og derfor det som tar lengst tid å lære og ta i bruk. Som igjen er grunnen til at vi ikke har tatt i bruk dette like mye som vi gjerne skulle ønske. - Skille backend API og front-end 100%. Til tross for at backend og frontend er svært adskilt slik applikasjonen er bygget opp nå, så finnes det alikevel en kobling mellom back-end og front-end i form av at NodeJS serveren som kjører API'et, også leverer applikasjonens index.html fil. - Benytte oss av Grunt ved bruk av Sass og enhetstester. Dette er en task-runner som automatiserer ting som kjøring av enhetstester og kompilering av Sass filer. - Sette opp en dokumentasjonsmal. Starte å skrive tidligere på dokumentasjonen enn det vi gjorde nå, og heller skrive litt hele prosjekttiden, istedenfor kun i de siste månedene. - Implementere endring av rekkefølge på spørsmål, og lydavspilling av spørsmålstekst. 6.4 VIDEREUTVIKLING Selvom applikasjonen i seg selv er en ferdigstilt applikasjon finnes det mulighet for videreutvikling. Mye av dette er nevnt i avsnittet ovenfor vedrørende hva vi ville gjort annerledes. I tillegg til disse kunne vi sett for oss noen flere funksjonaliteter. Disse er beskrevet i produktrapporten. 82

83 6.5 HVA ER VI STOLTE AV? MODERNE OG AKTUELLE TEKNOLOGIER Applikasjonen er svært fremtidsrettet og moderne gjennom bruk av aktuelle teknologier som AngularJS og NodeJS. Den vil derfor være enkel å vedlikeholde av fremtidens utviklere, samt potensielt ha en lengre levetid enn en applikasjon utviklet med eldre og utdaterte teknologier. SKALERBAR OG RESPONSIV Applikasjonen skalerer bedre over flere servere igjennom bruk av JSON Web Tokens for autentisering, sammenlignet med en mer tradisjonell autentisering gjennom sessions. Applikasjonen er også responsiv over forskjellige enheter som f.eks mobiler, nettbrett og datamaskiner. SEPARERT FONT-END OG BACK-END Applikasjonen har en separert front-end og back-end. Applikasjonslogikk kjøres på font-end, og databaselogikk på back-end i form av et REST API. All kommunikasjon med back-end foregår asynkront via AJAX kall. Denne måten å bygge opp en applikasjon på gjør det også mulig å separere front-end og back-end på forskjellige servere. WEBSOCKETS Bruk av websockets for sanntids-kommunikasjon mellom klienter ved quizdeltakelse. 6.6 KONKLUSJON I løpet av prosjektperioden har vi arbeidet intensivt og målrettet mot et godt sluttprodukt som oppdragsgiver skulle bli fornøyd med. Et av målene med prosjektet var å utvikle en ferdigstilt frittstående quizapplikasjon som oppdragsgiver faktisk kunne ta i bruk. Dette føler vi at vi har klart. Sluttproduktet oppfyller de aller fleste krav som ble gitt av oppdragsiver og er i tillegg utviklet med tanke på videreutvikling, sikkerhet, pålitelighet og brukervennlighet. Blant annet har moderne teknologier blitt benyttet, front-end/back-end er separert, informasjonsarkitektur er blitt tatt i betrakning under utviklingen og tester har blitt utført. Arbeidet med dette hovedprosjektet har både vært svært interessant og lærerikt, men samtidig utfordrerne. I tillegg til å ha lært oss å bruke et helt nytt programmeringsspråk og rammeverk, har gruppen gjennom prosjektperioden tilegnet seg kunnskap og god innsikt i hvordan det er å utføre et oppdrag for en reell oppdragsgiver. Samtidig har bruken av utviklingsmetoden scrum gitt oss nyttig erfaring som vi kan ta med oss videre i arbeidslivet eller videre studier. 83

84 KILDELISTE "What is angular?". (2016, 05 13). Hentet fra AngularJs: Komme i gang - Om versjonskontro: git-scm.com. (2016, 05 04). Hentet fra git-scm.com: 10 Reasons Web Developers Should Learn AngularJS. (2014, 04 24). Hentet fra Winintellect: Beck, K. (2001). extreme Programming explained: Embrace Change. AddisonWesley. Brombach, H. (2016, 04 11). digi.no. Hentet fra Capgemini. (2016, 05 04). Capgemini. Hentet fra Capgemini: Dingsøyr, T. (2008, 01 22). NTNU forelesning. Hentet fra ExpressJS. (2016, 05 13). Hentet fra ExpressJS. (2016, 5 3). Express application generator. Hentet fra ExpressJS: ExpressJS. (2016, 04 28). ExpressJS. Hentet fra ExpressJS: Fagernes, S. (2014). Grupperingsmetoder. Fagernes, S. (2015). "Labeleing": Merking av innhold. Fagernes, S. (2015). Organiseringssystemer. Itunes. (2016, 05 13). SQLPro for MSSQL. Hentet fra Liseter, I. M. (2016, 05 08). Store Norske Leksikon. Hentet fra Mean.IO. (2016, 04 28). The MEAN Stack. Hentet fra Mean.IO: Model view controller: Wikipedia. (2016, 05 13). Hentet fra Wikipedia: NodeJs. (2016, 05 13). Hentet fra Rouse, M. (2016, 05 13). RESTful API. Hentet fra 84

85 Rowinski, D. (2016, 04 28). JavaScript Is Eating The World. Hentet fra Arc: Stackoverflow. (2009, 6 23). What exactly is RESTful programming? Hentet fra Stackoverflow: Stackoverflow. (2016, 04 28). Single Page Application: advantages and disadvantages. Hentet fra Stackoverflow: Wikipedia. (2016, 05 13). Hentet fra Wikipedia. (2016, 04 28). Angular JS. Hentet fra Wikipedia: Wikipedia. (2016, 04 28). Node JS. Hentet fra Wikipedia: Wikipedia. (2016, 05 19). Universell Utforming. Hentet fra Wikipeida. (2016, 05 21). Scrum. Hentet fra Scrum: 85

86 VEDLEGG 1. Kravspesifikasjon 2. Risikoplan 3. Fremdriftsplan 4. Skisser 5. Ordliste 6. Ord fra oppdragsgiver

87 VEDLEGG 1 KRAVSPESIFIKASJON INNHOLDSFORTEGNELSE Forord Systembeskrivelse Mål for systemet Funksjonelle krav Ikke-funksjonelle krav Use-case diagram Rammekrav

88 FORORD Hensikten med denne kravspesifikasjonen er å beskrive bakgrunnen og formålet med applikasjonen, hvilke behov som finnes og hvilke tekniske rammer prosjektet skal gjennomføres innenfor. Kravspesifikasjonen blir regnet som et internt styringsdokument mellom arbeidsgiver og gruppen, og fungerer som en slags avtale. Kravspesifikasjonen er beregnet på alle interessenter i prosjektet, og er skrevet deretter med tanke på faguttrykk og liknende. Prosjektet med dets funksjonelle og ikkefunksjonelle krav vil bli nøye undersøkt og definert og datamodeller vil bli utarbeidet. 1 SYSTEMBESKRIVELSE Prosjektet går ut på å lage en webapplikasjon hvor lærere kan utforme quizer etter undervisning og fag. Det kreves at hver quiz skal kunne inneholde minst 30 oppgaver og at hver oppgave skal kunne ha opptil tre svaralternativer. Det må i tillegg være mulig å legge inn verkslogoer i applikasjonen. Applikasjonen kan skal bestå av følgende oppgavetyper: videosnutt med spørsmål, bilde med spørsmål, lyd med spørsmål og kun spørsmål (kan være en lengre tekst etterfulgt av et spørsmål).. De riktige svarene må kunne markeres som riktige av forfatteren. Oppgavene skal nummereres fortløpende fra 1 og oppover. Et annet krav til applikasjonen er at det skal være mulig å bruke quizene på forskjellige måter, dvs. med ulikt antall deltagere. Det skal være mulig å benytte seg av quizen som én deltager, flere deltagere og i grupper. I tillegg skal det være mulig å skrive ut quizen på papir. Elevene svarer da individuelt, eller gruppevis. Hver elev, eller gruppe, får et skjema med oppgaver for avkryssing. Det skal være en administratordel hvor lærerne kan utforme quizen. Elevene kommer inn på den aktuelle quizen ved å skrive inn en kode og så registrere navnet sitt. Hvis det er en quiz for flere deltagere må elevene vente på at læreren starter quizen, ellers kan eleven starte når den selv vil. Webapplikasjonen skal la lærere opprette quizer/prøver, som elevene kan ta ved å gjøre følgende: - Gå inn på applikasjonen og taste inn en quiz id (kode) - Gå inn på quizen sin unike URL Elevene kan melde seg på en quiz enten individuelt, eller som en gruppe. Ved tidsbegrensing, kan lærer selv starte quizen når alle har meldt seg på. Lærer vil kunne se måloppnåelse for elevene/gruppene inne på en egen side. I tillegg til quizene læreren selv lager, vil det være quizer til noen av oppdragsgiverens bokverk som er laget på forhånd. 2

89 2 MÅL FOR SYSTEMET Hovedmålet med arbeidet vårt er å tilby Cappelen Damm en god applikasjon som skal fungere som et digitalt lærerverktøy for lærere i grunnskolen. Applikasjonen skal gjøre det mulig for lærere å opprette quizer relatert til fag, inneholde et bibliotek med quizer og lærere skal kunne vurdere elevenes måloppnåelse ved å holde quizene. I tillegg har vi disse målene: Løsningen skal være en webapplikasjon, altså en nettside som kan leses i en nettleser. Lage en komplett løsning som fungerer, bestående av back-end og front-end. Kildekoden skal kunne vedlikeholdes og videreutvikles av andre utviklere uten store utfordringer. Løsningen skal være frittstående slik at den lett kan implementeres på nettstedene til CDU. Løsningen skal ha en administratordel, hvor lærerne kan opprette, endre, eller slette quizer. Løsningen skal koble brukere til quizen ved hjelp av innskriving av en kode/id. Løsningen skal inneholde et bibliotek av quizer, knyttet opp mot CDU sine bokverk. FUNKSJONALITETSKRAV Det skal kunne opprettes quizer med én deltager, flere deltagere og/eller grupper. Svarskjema skal kunne skrives ut på papir. Applikasjonen skal gjøre det mulig å lage følgende oppgavetyper: videosnutt + spørsmål, bilde + spørsmål, lyd + spørsmål og bare spørsmål. Hver quiz skal ha en egen ID. Hvert spørsmål skal kunne ubegrenset antall svaralternativer. Hver quiz skal kunne ha verkslogo for hvert av Cappelen sine bokverker. Elev skal kunne melde seg på en quiz ved å taste inn quizens kode og skrive inn navnet sitt. TEKNOLOGIER AngularJS NodeJS ExpressJS HTML CSS (Bootstrap) MS SQL / SQL Server RAMMEBETINGELSER Bruke JavaScript i både front-end og back-end. Bruke HTML, CSS (Bootstrap) og AngularJS til å utforme front-end. Bruke NodeJS og Express JS til å utforme back-end. 3

90 Bruke Adobe Brackets og Visual Studio Code IDE for å utvikle systemet GitHub for versjonshåndtering og backup. Bruke smidig metodikk for prosjekthåndtering ved hjelp av Scrum. 3 FUNKSJONELLE KRAV Krav Forklaring Viktighetsgrad Opprette quiz Lenke til quiz Opptil 30 spørsmål Opptil 3 svaralternativer Adgangskode Oppgavetyper Logo Verkslogo Avspilling av spørsmål Endre rekkefølge på spørsmålene Animasjoner Hjelp Karakterskala Skal ha muligheten til å opprette opptil flere quizer Hver quiz skal ha sin egen URL som man kan lenke til Hver quiz skal kunne ha opptil 30 spørsmål Hvert spørsmål skal kunne ha opptil 3 svaralternativer Elev som går inn på en nettside vil ha mulighet til å skrive inn en kode for quizen. Alternativ til å gå direkte inn på en aktuelle URL en Videosnutt + spørsmål Bilde + spørsmål Lyd + spørsmål Spørsmål Applikasjonen skal ha logo for Cappelen Damm Hver quiz skal kunne ha verkslogo for lærebok Spørsmålsteksten skal kunne spilles av som lyd f.eks. via google translate Lærer burde kunne endre rekkefølgen på spørsmålene Flyt og brukeropplevelse kan forbedres med animasjoner En hjelpedialog skal vises ved mouse-hover på knapper o.l. Lærer kan velge på sin egen side hvilken prosentandel som gir hvilken karakter. Karakteren vil da dukke opp ved siden av hver elev på resultatsiden. Absolutt krav Absolutt krav Absolutt krav Absolutt krav Høy Høy Høy Høy Middels Middels Middels Middels Lav 4

91 Nummerering Oppgave skal nummereres Høy Moduser Enkeltperson-modus Felles-modus Gruppe-modus Papir-modus Vise riktig svar Registrere seg Påmelding av quiz Lærer kan velge en modus på quizen (en eller flere personer) Enkeltperson uten tidsbegrensing Flere enkeltpersoner kan ta quizen med tidsbegrensing. Quiz startes av lærer når alle har registrert seg. En gruppe kan ta quizen med tidsbegrensing. Quiz startes av lærer når alle har registrert seg. Lærer starter quiz uten tidsbegrensing. Svarskjema kan enkelt printers ut, og elevene gjør På hvert spørsmål kan lærer trykke på en knapp som viser riktig svar Lærer skal kunne registrere en brukerkonto Elev skal kunne melde seg på en quiz via. URL og taste inn sitt navn Høy Høy Høy Høy Høy Høy Absolutt krav Absolutt krav 4 IKKE-FUNKSJONELLE KRAV Krav Forklaring Viktighetsgrad SPA Responsiv Ytelse Applikasjonen skal være en SPA (Single page application) Applikasjonen skal være responsiv ovenfor forskjellige skjermstørrelser Applikasjonen skal ha god flyt og ytelse Absolutt krav Absolutt krav Middels 5

92 5 USE-CASE DIAGRAM 5.1 Use-case diagram over applikasjonen Use-case diagrammet viser applikasjonens funksjonalitet og samspillet mellom systemet og omgivelsene (brukere, andre systemer og komponenter). Use-case diagrammet er en modellering av de funksjonelle kravene representert over. Diagrammet viser hvordan en lærer og en elev kan bruke applikasjonen. 6 RAMMEKRAV SIKKERHETSKRAV - Sikring av inndata mot SQL injection - All sensitiv data skal sikres - Applikasjonen skal ikke lagre unødvendig sensitiv informasjon - Scripting TEKNISKE KRAV - Applikasjonen skal utvikles i Angular JS, Node og Express JS, HTML, CSS (Bootstrap) - Applikasjonen skal støtte Google Chrome, Firefox, Safari, Edge og Internet Explorer 9 eller høyere. - MVC (model view controller) skal benyttes for å skille logikk fra grensesnitt. - Applikasjonen skal være skalerbar, dvs. det skal være enkelt å legge til ny funksjonalitet i fremtiden. - Koden skal være godt strukturert, og navn på metoder, variabler mm. skal være selvforklarende. - Koden skal supplementers med kommentarer som tydelig beskriver hva som foregår. 6

93 DESIGN KRAV - Knapper skal ha tilstrekkelig størrelse for å veie opp for unøyaktigheter - Fargekontraster skal være tydelige. - Plassering av knapper skal ligge naturlig i forhold til hverandre. KRAV TIL DATALAGRING - Databasen skal være bygd opp med krav om normalisering KRAV TIL UNIVERSELL UTFORMING - Applikasjonen skal være lettleselig og knappene skal være godt synlig. - Applikasjonen skal ikke inneholde unødvendig gjentagelser. - Farger som er brukt i applikasjonen skal være leselig for fargeblinde, svaksynte og folk med andre funksjonsnedsettelser 7

94 VEDLEGG 2 RISIKOPLAN Beregningen av sannsynligheten for at en hendelse skal skje er vist med tallene 1 til 4 der: 1 ikke sannsynlig for at en hendelse skal skje 2 mindre sannsynlighet for at en hendelse skal skje 3 sannsynlig at en hendelse skal skje 4 svært sannsynlig at en hendelse skal skje Beregning av konsekvensen og alvorlighetsgraden av at hendelse kan skje er vist med tallene 1 til 4 der: 1 Ikke alvorlig 2 Alvorlig 3 Kritisk 4 Svært kritisk Beregningen av risikofaktoren er summen av sannsynligheten og konsekvensen av en hendelse, representert med fargene grønn, gul og rød. 1-3: Lav risiko 4-5: Middels risiko 6-8: Høy risiko Beskrivelse av hendelse Konsekvens av hendelsen Sannsynlighet Alvorlighetsgrad Risikofaktor Sykdom veileder Sykdom oppdragsgiver Langvarig sykdom/fravær innad i gruppen Ved sykdom hos veileder kan det føre til manglende veiledning av arbeidet. Sykdom hos oppdragsgiver kan føre til manglende kravspesifikasjon og dårlig veiledning. Ved langvarig fravær blir det mer arbeid på resten av gruppen, aktiviteter kan bli forsinket og det blir hull i aktivitetsplanen som må fylles opp. Mindre sannsynlig (2) Alvorlig (2) Middels risiko Mindre sannsynlig (2) Ikke alvorlig (1) Lav risiko Mindre sannsynlig (2) Kritisk (3) Middels risiko 1

95 Kortvarig sykdom/fravær innad i gruppen Løsningen tilfredsstiller ikke oppdragsgivers krav Studenten kan ikke møte opp og gjennomføre sin del av arbeidet. Arbeidet må tas igjen senere. Kunden ønsker ikke å benytte seg av prosjektet og gir en dårlig tilbakemelding. Svært sannsynlig (4) Ikke alvorlig (1) Middels risiko Mindre sannsynlig (2) Svært Kritisk (4) Høy risiko Tap av gruppemedlem Gruppekonflikt/ uenighet innad i gruppen Noen slutter eller blir utvist. Kan føre til at målene som har blitt satt ikke blir nådd, på grunn av for stor arbeidsmengde. Uenigheter innad i gruppen når det gjelder prosjektet kan føre til dårlig samarbeid og dermed et dårligere resultat. Ikke sannsynlig (1) Kritisk (3) Middels risiko Mindre sannsynlig (2) Ikke alvorlig (1) Lav risiko Ikke mestrer bruk av ukjent teknologi Gruppen klarer ikke å benytte seg av teknologien og må vurdere å bytte. Sannsynlig (3) Svært Kritisk (4) Høy risiko Utvikling av unødvendige funksjoner Sette seg for vanskelige mål Gruppen bruker mye tid på funksjoner som er ikke er nødvendige, slik at funksjoner som er viktige ikke blir prioritert. Gruppen setter seg for vanskelige mål slik at prosjektet ikke blir ferdig. Sannsynlig (3) Alvorlig (2) Middels risiko Ikke sannsynlig (1) Svært Kritisk (4) Middels risiko Tidsfrister overholdes ikke Gruppen undervurder mengde arbeid i forhold til tidsfrister. Kan føre til at prosjektet ikke blir ferdigstilt. Sannsynlig (3) Svært Kritisk (4) Høy risiko Tap av data Mister data slik at ting må gjøres på nytt. Kan føre til at tidsfrister ikke holdes. Ikke sannsynlig (1) Alvorlig (2) Lav risiko Nye brukerkrav Kan føre til at hele prosjektet må endres og at det ikke blir ferdigstilt. Sannsynlig (3) Alvorlig (2) Middels risiko 2

96 LANGVARIG SYKDOM VEILEDER Forebygging: ha gode kommunikasjonsmuligheter og sette seg inn i rutiner ved langvarigsykdom hos veileder og mulighetene for å få en ny veileder. Tiltak: ved kortvarig sykdom kommunisere via mail. Ved langvarig sykdom vurdere å søke om å få ny veileder. SYKDOM OPPDRAGSGIVER Forebygging: ha gode kommunikasjonsløsninger ved sykdom og en klar plan på hva som skal utføres tidlig i prosjektet slik at kommunikasjon ikke er veldig nødvendig. Tiltak: Ved langvarig sykdom: få ny kontaktperson slik at møter kan utføres. LANGVARIG SYKDOM INNAD I GRUPPEN Forebygging: ha gode kommunikasjonsløsninger ved fravær og god dokumentering av alle arbeidsoppgaver, slik at de andre i gruppen enkelt kan sette seg inn i oppgavene som skal løses. Være flinke til å følge hverandre opp og hjelpe til hvis noen ligger bak. Tiltak: Finne ut hvordan fraværet påvirker prosjektet, og om det må føre til endringer i størrelse/kompleksiteten til prosjektet. KORTVARIG SYKDOM INNAD I GRUPPEN Forebygging: ha gode kommunikasjonsløsninger ved fravær og god dokumentering av alle arbeidsoppgaver, slik at de andre i gruppen enkelt kan sette seg inn i oppgavene som skal løses. Være flinke til å følge hverandre opp og hjelpe til hvis noen ligger bak. Tiltak: legge dokumenter ut i Dropbox/GIT og sørge for at de andre gruppemedlemmene er klar over situasjonen, og kan hjelpe til med- eller ta over eventuelle oppgaver. LØSNINGEN TILFREDSSTILLER IKKE OPPDRAGSGIVERS KRAV Forebygging: Kommunisere godt med oppdragsgiver og lage en god kravspesifikasjon. Tiltak: Få en oversikt over hva som ikke står til forventningene og gjøre nødvendige endringer slik at kundens krav oppfylles. Eventuelt be om hjelp fra tilgjengelige ressurspersoner. TAP AV GRUPPEMEDLEM Forebygging: God kommunikasjon mellom gruppemedlemmene slik at det er en god tone innad i gruppen. Tiltak: Få en oversikt over hvor mye det er igjen å gjøre og eventuelt droppe noen av funksjonene for å komme i mål med prosjektet. GRUPPEKONFLIKT/ UENIGHET INNAD I GRUPPEN Forebygging: Gjøre de oppgavene vi må. Møte opp på møter. Bli ferdig til avtalt tidsfrister. Være behjelpelige og imøtekommende. Tiltak: Prøve å løse problemet innad i gruppen, dersom det ikke lar seg gjøre, ta et møte med intern veileder. IKKE MESTRER BRUK AV UKJENT TEKNOLOGI Forebygging: Sette seg tidlig og grundig inn i teknologien som skal brukes i prosjektet. Tiltak: Spørre veileder og andre ressurspersoner om råd. UTVIKLING AV UNØDVENDIGE FUNKSJONER Forebygging: Sette opp en grundig kravspesifikasjon og fremdriftsplan. Tiltak: Fjerne funksjoner som ikke bidrar til å gjøre løsningen bedre 3

97 SETTE SEG FOR VANSKELIGE MÅL Forebygging: Sørge for god planlegging i en tidlig fase av prosjektet og hør gjerne med veileder. Tiltak: Gjøre nødvendige endringer slik at kundens krav oppfylles. Be om hjelp fra tilgjengelige ressurspersoner. TIDSFRISTER OVERHOLDES IKKE Forebygging: Sørge for god planlegging i en tidlig fase av prosjektet, samt sørge for at hver sprint består av realistiske mål og arbeidsmengder. Tiltak: Gi beskjed så tidlig som mulig til oppdragsgiver dersom man ikke klarer å overholde fristene. TAP AV DATA Forebygging: Bruke Dropbox, samt være flinke til å stadig lagre dokumenter lokalt for å ha back-up lagret på flere steder. Tiltak: Vurdere omfanget og viktigheten av tapt data, deretter sette opp en ny plan på hvordan og hvor mye man må jobbe for å ta igjen det tapte. NYE BRUKERKRAV Forebygging: Kartlegge brukerkrav, samt sørge for en oppdatert kravspesifikasjon. Tiltak: Finne ut viktigheten av de nye kravene i samsvar med kunde, samt legge det inn i kravspesifikasjonen. 4

98 VEDLEGG 3 FREMDRIFTSPLAN Fase Varighet Beskrivelse Innførelse 27 desember - 25 januar Selvstudie av AngularJS, NodeJS, og ExpressJS Kartlegging av oppgave 25 januar til 1 februar Kartlegging av oppgaven og funksjonelle krav Kartlegging av databasebehov 1-4 februar Kartlegging av databasebehov med tabeller, scripts, opprettelse av DB i Azure mm. Startfase back-end 4-6 februar Opprettelse av filstruktur, og nødvendige filer/kode for et helt enkelt API Innlogging og verifisering 7-9 februar API kall for opprettelse av brukerkontoer og innlogging via. JWT's Opprettelse av quiz 9-13 februar API kall for opprettelse av en quiz Oppdatering og henting av quiz februar API kall for oppdatering av quiz, og henting av quiz Startfase front-end februar Opprettelse av AngularJS grunnapplikasjon. Opprettelse av quiz 22 februar til 8 mars GUI og AngularJS kode for opprettelse av quiz Brukertest 1 (Sprint 1) 8.mars Testperson skal opprette en brukerkonto, logge inn og opprette en quiz. Quiz påmeldelse 9-22 mars GUI og angular/socket.io kode for påmelding og avmelding av quiz Deltakelse av quiz mars GUI og angular/socket.io kode for deltakelse av quiz 1

99 Endring av quiz, animasjoner og alerts 3-6 april GUI og angular kode for endring av quiz. I tilegg til CSS3 animasjoner og notifikasjoner ved evnt. feil Brukertest 2 (Sprint 2) 6.april Testperson skal endre eksisterende quiz og se resultater. Svarskjema/fasit og glemt passord 7-8 april Mulighet for print av svarskjema og fasit for en quiz, samt funksjonalitet for å resette passord Resultatside og toppliste 9-19 april GUI og angular kode for visning av resultater for quizer som er tatt. Toppliste med de 3 beste ved fullført quiz. Brukertest 3 (Sprint 3) 12.april Testperson skal opprette en quiz, starte en quiz, melde seg en quiz og ta en quiz. Valg av verk april GUI og kode for valg av bokverk. Adminkontoer for bokverk. Nettleser kompatibilitetsjekking 25 april - 1 mai Test av applikasjonen over et bredt utvalg av nettlesere, operativsystemer og mobiltelefoner. Kode for sjekk av hvorvidt det benyttes en støttet nettleser. Ferdigstilling av dokumentasjon 1 23 mai Skrive og ferdigstille sluttrapporten. 2

100 VEDLEGG 4 SKISSER 1 BRUKERDEL 1.1 Skisse på brukergrensesnitt for quizpåmelding hvor deltageren skal skrive inn quizkoden til quizen han/hun ønsker å delta på. 1.2 Skisse på brukergrensesnittet for innskrivning av navn ved påmelding av quiz 1

101 1.3 Skisse på brukergrensesnittet for hvordan det er å ta en quiz 2 ADMINDEL 2.1 Skisse på brukergrensesnittet på siden som viser admin-brukeren sine quizer 2

102 2.2 Skisse på brukergrensesnittet på siden hvor adminbrukeren kan lage en quiz 2.3 Skisse på brukergrensesnittet på siden som viser resultatene 3