Precision Teaching App for Android

Precision Teaching App for Android Hovedprosjekt i Informasjonsteknologi, våren 2014 Gruppe 39 Høgskolen i Oslo og Akershus Sted/dato: Høgskolen i Oslo og Akershus, 25.04.2014 Tittel: Precision Teaching App for Android Prosjektmedlemmer: Vegard Krusedokken (s164830) Ole Aarnseth (s180482) Veileder: Kirsten Ribu, Tlf.: 41648686, Kirsten.Ribu@hioa.no Oppdragsgiver: Fakultet for helsefag, Høgskolen i Oslo og Akershus Kontaktpersoner: Børge Strømgren, Tlf.: 97424499, borge.stromgren@hioa.no Torunn Lian, Tlf.: 92213191, torunn.lian@hioa.no

1 Innholdsfortegnelse 1 Innholdsfortegnelse...2 1.1 Bildeoversikt..7 2 Sammendrag..9 3 Prosessrapport. 10 3.1 Om gruppen..10 3.2 Om oppdragsgiver...10 3.3 Bakgrunn for oppgaven....11 3.3.1 Om Precision Teaching.11 3.3.2 Dagens situasjon...11 3.4 Mål...12 3.4.1 Oppgavens mål......12 3.4.2 Egne mål...12 3.5 Planlegging..12 3.5.1 Arbeidsforhold......12 3.5.2 Fordeling av arbeid...13 3.5.3 Styringsdokumenter..13 3.5.4 Prosjekthjemmesiden...14 3.6 Teknologier..14 3.6.1 XML..14 3.6.2 Java 15 3.6.3 SQLite... 15 3.6.4 Ajax...15 3.6.5 JavaScript..15 3.6.6 PHP... 15 3.6.7 Apache HTTP Server....16 3.6.8 HTML...16 3.6.9 CSS...16 3.6.10 JSON..16 3.6.11 Dropbox..16 3.6.12 MySQL...16 3.6.13 Google Docs...16 3.7 Utviklingsverktøy...17 3.7.1 Gedit..17 3.7.2 Eclipse...17 3.8 Forarbeid..17 3.8.1 Datainnsamling.....17 3.8.2 Utredning..17 3.9 Utvikling..20 3.9.1 Fase 1: Første prototype av app...21 3.9.1.1 Synkende ProgressBar eller nedteller med sekunder?...21

3.9.1.2 Testing av første prototype...23 3.9.2 Fase 2: Videreutvikling av prototype og utvikling av Adminnettsted..23 3.9.2.1 Videreutvikling av prototype.23 3.9.2.1.1 Versjonkontroll og backup med Dropbox...23 3.9.2.1.2 Intern lagring - serialisering eller SQLite?...23 3.9.2.2 Videreutvikling av brukergrensesnittet..24 3.9.2.2.1 Innstillinger. 24 3.9.2.2.2 Spørsmålsvalg. 25 3.9.2.2.3 Ny økt.....26 3.9.2.2.4 Øktskjerm....27 3.9.2.3 Utvikling av databaseserver og Adminnettsted.....27 3.9.2.3.1 Endringer i Adminnettstedet... 28 3.10 Forsinkelser....29 3.11 Problemer og løsninger..29 3.11.1 Android ListView markering..29 3.11.2 JSON skriver ikke ut UTF-8 karakterer......29 3.11.3 Feil ved laging av spørsmål 30 3.11.4 Feil i dialogvinduet.....30 3.12 Testing under utviklingsfasen....30 3.13 Systemtesting og endelig produkt..31 3.13.1 Hva kunne vært annerledes.....31 3.13.1.1 Krav til lengde for spørsmålstekst...31 3.14 Sluttdokumentasjon...31 3.15 Konklusjon.....32 4 Produktrapport....33 4.1 Beskrivelse av produkt.....33 4.1.1 Generell beskrivelse av Precision Teaching App. 33 4.1.2 Generell beskrivelse av Adminnettsted.33 4.2 Rammekrav......34 4.2.1 Krav til løsning..34 4.2.1.1 Funksjonelle krav...34 4.2.2 Økonomi....35 4.3 Hovedfunksjoner..36 4.3.1 Precision Teaching app for Android - Sentrale funksjoner...36 4.3.1.1 Økter...36 4.3.1.2 Velge spørsmål... 37 4.3.1.3 Tidsavgrensning.37 4.3.1.4 Brukernavn.....37 4.3.1.5 Highscore...38 4.3.1.6 Eksporter til epost..38 4.3.1.7 Hurtigøkt....38 4.3.1.8 Spørsmål hentes fra ekstern database.38 4.3.2 Adminnettsted - Sentrale funksjoner.....38

4.3.2.1 Meny..39 4.3.2.2 Fagmeny.....39 4.3.2.3 Nytt fag..39 4.3.2.4 Slette fag....39 4.3.2.5 Endre fag....40 4.3.2.6 Vise fag..40 4.3.2.7 Kategorimeny.....40 4.3.2.8 Ny kategori.....40 4.3.2.9 Vise kategori..40 4.3.2.10 Slette kategori.. 40 4.3.2.11 Endre kategori......40 4.3.2.12 Spørsmålsmeny....40 4.3.2.13 Nytt spørsmål...41 4.3.2.14 Slette spørsmål.....41 4.3.2.15 Endre spørsmål.41 4.3.2.16 Vise spørsmål...41 4.3.2.17 Ny admin..41 4.4 Brukergrensesnitt.....42 4.3.1 Precision Teaching app for Android.42 4.3.1.1 Tekniske løsninger.42 4.3.1.1.1 XML Layout...42 4.3.1.1.2 Android Button... 43 4.3.1.1.3 Android Fragment...43 4.3.1.1.4 Android ListView... 44 4.5 Teknisk arkitektur....45 4.4.1 Precision Teaching App for Android - intern arkitektur...46 4.4.1.1 Teknologier....46 4.4.1.1.1 SQLite.46 4.4.1.1.2 AsyncTask...47 4.4.1.1.2.1 AsyncTask i SelectCourseFragment, SelectCategoryFragment og SessionQuestionFragment..47 4.4.1.2 Sentrale klasser..48 4.4.1.2.1 User. 48 4.4.1.2.2 Question.. 48 4.4.1.2.3 Answer....48 4.4.1.2.4 Session....49 4.4.1.3 Kjøring av en Precision Teaching økt....49 4.4.2 Adminnettsted - intern arkitektur..50 4.4.2.1 Class.admin.php.50 4.4.2.2 Class.answer.php....50 4.4.2.3 Class.category.php.....50 4.4.2.4 Class.course.php.50 4.4.2.5 Class.dbversion.php...50

4.4.2.6 Class.login.php...50 4.4.2.7 Javascript/Ajax...51 4.4.2.8 Sikkerhet....51 4.4.3 Databaseserver - intern arkitektur.52 4.6 Konklusjon...52 5 Testrapport......53 5.1 Formål med testing...53 5.2 Testverktøy...54 5.2.1 Teknologier... 54 5.2.1.1 Eclipse IDE med debugger og emulator....54 5.2.1.2 Mozilla Firefox med Firebug add-on.....54 5.2.1.3 ApacheBench.55 5.2.1.4 PHP utviklingskonfigurasjon. 55 5.2.2 Testenheter 56 5.3 White box og black box...57 5.4 Testing av første prototype..57 5.4.1 Fremgangsmåte.....57 5.4.2 Resultater..57 5.5 Testing i utviklingsfasen......58 5.5.1 Enhetstesting. 58 5.5.1.1 Enhetstesting av Android-applikasjon...58 5.5.1.2 Enhetstesting av Adminnettsted.....58 5.6 Systemtesting...59 5.6.1 Systemtesting av Android-applikasjonen..59 5.6.1.1 Fremgangsmåte......60 5.6.1.2 Resultater...60 5.6.2 Systemtesting av Adminnettstedet....61 5.6.2.1 Fremgangsmåte......61 5.6.2.2 Resultater...62 5.7 Stresstesting av server..62 5.7.1 Fremgangsmåte.....62 5.7.2 Resultater..63 5.7.2.1 Resultater for PHP-servicer...63 5.7.2.2 Resultater for Adminnettsted...64 5.8 Konklusjon......65 6 Kravspesifikasjon....66 6.1 Presentasjon.....66 6.2 Kort systembeskrivelse....67 6.3 Funksjonelle krav.....68 6.3.1 Krav til Android-applikasjon....68 6.3.1.1 Krav til økter.. 68 6.3.1.2 Krav til score.. 68 6.3.1.3 Krav til spørsmål....68

6.3.2 Krav til Database og Adminnettsted.....68 6.4 Ikke-funksjonelle krav. 69 6.3.1 Android-applikasjon.. 69 6.5 Tekniske krav... 69 6.6 Øvrige ønsker... 69 6.8 Krav til dokumentasjon....70 6.8.1 Styringsdokumentasjon.....70 6.8.2 Sluttdokumentasjon...70 6.9 Risikoanalyse...70 7 Brukerveiledning.71 7.1 Innledning....71 7.2 Brukerveiledning for Android-appen...72 7.2.1 Installeringsinstruksjoner..72 7.2.2 Første oppstart...73 7.2.3 Hovedmeny... 74 7.2.4 Ny økt....75 7.2.4.1 Velg tid...75 7.2.4.2 Brukervalg..76 7.2.4.3 Spørsmålsvalg 77 7.2.5 Kjøring av en økt...78 7.2.5.1 Øktslutt-dialogvindu.. 79 7.2.5.2 Riktige svar....80 7.2.6 Hurtigøkt...81 7.2.7 Sjekk High Score......82 7.2.7.1 Eksporter scorer til epost 83 7.2.8 Innstillinger...84 7.3 Brukerveiledning for Adminnettsted...85 7.3.1 Innlogging.....85 7.3.2 Meny.....86 7.3.3 Ny admin...86 7.3.4 Fagmeny....87 7.3.5 Nytt fag.....87 7.3.6 Slette fag...88 7.3.7 Endre fag... 89 7.3.8 Vise fag.....90 7.3.9 Kategorimeny....90 7.3.10 Ny kategori..91 7.3.11 Slette kategori.91 7.3.12 Endre Kategori.......92 7.3.13 Vise kategori......92 7.3.14 Spørsmålsmeny...93 7.3.15 Nytt spørsmål..94 7.3.16 Slette spørsmål....95

7.3.17 Endre spørsmål....96 7.3.18 Vise spørsmål og svar.....96 8 Kilder..97 1.1 Bildeoversikt Prosessrapport: Bilde 3.5.4.1: ASP.NET-versjonen av prosjekthjemmesiden....14 Bilde 3.8.2.1: Oversikt over løsningen etter utredning......19 Bilde 3.9.1: Oversikt over utviklingsfasene... 20 Bilde 3.9.1.1.1: Forslag fra oppdragsgiver og prototype...22 Bilde 3.9.1.1.2: Hovedmeny og Sluttøktdialog......22 Bilde 3.9.2.2.1.1: Iterasjoner av Innstillinger-menyen......24 Bilde 3.9.2.2.2.1: Iterasjoner av Spørsmålsvalg 25 Bilde 3.9.2.2.3.1: Iterasjoner for gangen i Ny økt.26 Bilde 3.9.2.2.4.1: Iterasjoner av øktskjerm....27 Produktrapport: Bilde 4.3.1.1.1: Skjermbilde fra et spørsmål i en økt som kjører..36 Bilde 4.3.1.2.1: Skjermbilde fra menyen for å velge spørsmål..37 Bilde 4.3.2.1: Bilde av startsiden for innloggede brukere.39 Bilde 4.3.1.1.1.1: Eksempel på en Android layout-fil i XML-format...42 Bilde 4.3.1.1.2.1: Knapp i vanlig og trykket tilstand.....43 Bilde 4.3.1.1.2.2: Eksempel på en inaktiv knapp...43 Bilde 4.3.1.1.4.1: Eksempel på en ListView i appen.....44 Bilde 4.5.1: Oversikt over interaksjonen mellom app og database/adminnettsted...45 Bilde 4.4.1.1.1.1: SQLite-databasen er et speilbilde av MySQL-databasen..46 Bilde 4.4.1.1.2.1.1: Tilstandsdiagram for fragmenter med AsyncTask.48 Bilde 4.4.1.2.4.1: Klassediagram for et Session-objekt.....49 Bilde 4.4.3.1: ER-diagram over hele databasen.....52 Testrapport Bilde 5.2.1.1.1: Eclipse IDE med emulator og debugger..54 Bilde 5.2.1.2.1: Mozilla Firefox med Firebug add-on...55 Bilde 5.5.1.2.1: Eksempel på en funksjon som sikrer input...59 Bilde 5.6.1.2.1: Menyen som noen hadde litt problemer med skjønne..61 Bilde 5.7.1.1: Skjermbilde fra ApacheBench....63 Brukerveiledning Bilde 7.2.1.1: Precision Teaching-ikonet...72 Bilde 7.2.2.1: Appen vil automatisk laste ned spørsmål ved første oppstart.73

Bilde 7.2.3.1: Appens hovedmeny.....74 Bilde 7.2.4.1: Før ny økt kan startes vil appen be deg om å velge kurs og kategori.75 Bilde 7.2.4.2.1: Brukervalg-skjermen....76 Bilde 7.2.4.3.1: Spørsmålsvalg-skjermen..77 Bilde 7.2.5.1: Øktskjermen 78 Bilde 7.2.5.1.1: Øktsluttvinduet.....79 Bilde 7.2.5.2.1: Riktige svar-skjerm.. 80 Bilde 7.2.6.1: Hurtigøkt-skjerm.....81 Bilde 7.2.7.1: High Score-skjerm...82 Bilde 7.2.7.1.1: Eksporter til epost-skjerm....83 Bilde 7.2.8.1: Innstillenger-menyen...84 Bilde 7.3.1.1: Innlogging-skjerm... 85 Bilde 7.3.2.1: Meny-skjerm...86 Bilde 7.3.3.1: Ny admin-skjerm.86 Bilde 7.3.4.1: Fagmeny..87 Bilde 7.3.5.1: Nytt fag-skjerm...87 Bilde 7.3.6.1: Slett fag-skjerm...88 Bilde 7.3.7.1: Endre fag-skjerm.89 Bilde 7.3.8.1: Vise fag-skjerm...90 Bilde 7.3.9.1: Kategorimeny......90 Bilde 7.3.10.1: Ny kategori-skjerm....91 Bilde 7.3.11.1: Slette kategori-skjerm...91 Bilde 7.3.12.1: Endre kategori-skjerm...92 Bilde 7.3.13.1: Vise kategori-skjerm.92 Bilde 7.3.14.1: Spørsmålsmeny.....93 Bilde 7.3.15.1: Nytt spørsmål-skjerm....94 Bilde 7.3.16.1: Slette spørsmål-skjerm..95 Bilde 7.3.17.1: Endre spørsmål-skjerm......96 Bilde 7.3.18.1: Vis spørsmål og svar-skjerm.....96

2 Sammendrag Precision Teaching App for Android er en lære-app for Android som skal hjelpe studenter med å trene på vanskelige fag. Appen er basert på læringsprinsipper fra Precision Teaching, og vil utfordre studenten med en rekke multiple choice-spørsmål som må besvares innenfor en tidsfrist. Studenten får en score basert på antall riktige svar, og appen legger opp til at studenten skal forbedre denne scoren. Faglærere kan legge inn, endre og slette spørsmål som benyttes i appen gjennom et eget nettsted, dette nettstedet har vi kalt Adminnettstedet.

3 Prosessrapport Denne rapporten beskriver prosessen rundt utviklingen av applikasjonen og nettstedet. Dette omfatter beslutningner som ble gjort underveis, vurderinger, hvordan vi jobbet, dokumentasjon og hvilke teknologier vi benyttet. 3.1 Om gruppen Gruppen besto av to informatikkstudenter ved HiOA, Ole Aarnseth og Vegard Krusedokken. Vi har jobbet mye sammen gjennom studioløpet på høyskolen, og vet av erfaring at vi samarbeider godt med prosjektoppgaver. Veilederen vår var Kirsten Ribu, førstelektor ved fakultet for teknologi, kunst og design på HiOA. 3.2 Om oppdragsgiver Oppdragsgiveren vår var fakultet for helsefag på HiOA. Slik presenterer oppdragsgiver seg selv: Fakultet for helsefag tilbyr høyere utdanning innen helsefag og har også forsknings- og utviklingsaktiviteter innen fagområdet. Fakultetet har rundt 5300 studenter og om lag 530 ansatte, og holder til i Pilestredet i Oslo sentrum og på Kjeller og Sandvika i Akershus. 1 Våre kontaktpersoner hos oppdragsgiver var Børge Strømgren, førsteamanuensis ved fakultet for helsefag, og Torunn Lian, også førsteamanuensis ved fakultet for helsefag. 1 http://www.hioa.no/om-hioa/fakultet-for-helsefag-hf (lastet ned 14.04.2014)

3.3 Bakgrunn for oppgaven 3.3.1 Om Precision Teaching Precision Teaching er et undervisningsprinsipp som kan benyttes til å evaluere undervisning og trening. Opprinnelig ble det utviklet av Ogden Lindsley på 1960-tallet. Kjennetegn ved Precision Teaching er at det vektlegger tempo og presisjon, der all jobbing er tidsavgrenset. Feil blir ikke korrigert underveis. Treningsøkter er veldig korte, og prinsippet legger opp til et høyt antall repitisjoner. Resultater vises deretter som en logaritmisk skala i det som kalles Standard Endringsskjema (eng. Standard Celeration Chart.) Dermed kan studenten få en oversikt over hva hun/han trenger å øve på. Som læringsprinsipp er Precision Teaching velegnet for implementasjon i en applikasjon for smarttelefoner og nettbrett med touch-skjerm. Brukeren kan utfordres med et multiple choice -spørsmål, og trykke på svaralternativet hun/han tror er riktig. 3.3.2 Dagens situasjon Innenfor sykepleierutdanningen viser ferske tall at 1 av 3 stryker i legemidderegning. 2 På høyskolen i Oslo og Akershus strøk 6 av 10 sykerpleierstudenter i dette faget i 2013. 3 Legemiddeldoser blir ofte angitt i milligram eller mikrogram, og riktig beregning av legemiddeldoser er veldig viktig for pasientsikkerheten innenfor helsevesenet. Derfor forlanger eksamen i legemiddelregning 100 prosent korrekte svar. For å hjelpe studenter i sykepleierutdanningen ønsket fakultet for helsefag en app basert på Precision Teaching, som skal hjelpe studentene med å bli flinkere til legemiddelregning. 2 http://khrono.no/campus-samfunn/2014/02/legemiddelregning-til-besvaer (lastet ned 23.04.2014) 3 http://www.studenttorget.no/index.php?show=22&artikkelid=12862 (lastet ned 23.04.2014)

Appen skulle være en generell Precision Teaching-applikasjon, hvor faglærere kan legge inn spørsmål relevante for faget deres, som studentene skal trene på. I første omgang skulle den brukes til legemiddelregning, men på sikt skulle den kunne benyttes i alle fag der Precision Teachinglæringsteknikker er relevante. 3.4 Mål 3.4.1 Oppgavens mål Formålet med oppgaven var å utvikle en Android-applikasjon som studenter skal kunne bruke til å trene på mestring og kompetanse innenfor forskjellige fag. Applikasjonen skal benytte læringsprinsipper fra Precision Teaching, der brukeren vil bli utfordret med korte treningsøkter hvor hun/han må svare på en rekke utvalgte spørsmål innenfor en gitt tidsfrist. Målet er å forbedre studentenes læring og øke studentenes kompetanse innenfor fagområdet. 3.4.2 Egne mål Et av våre mål med oppgaven er å utvikle etter beste evne et produkt som både vi og oppdragsgiver er fornøyd med. Produktet skal være brukervennlig og respondere raskt. Et annet mål er å erfare hvordan det er å utvikle et produkt for en oppdragsgiver. Dette er første gang vi jobber på et større prosjekt, og lager et ordentlig produkt for noen andre. Vi har også som mål å tilegne oss kunnskap innenfor nye områder, og friske opp gammel kunnskap. Dette er nødvendig for å få et godt resultat. 3.5 Planlegging 3.5.1 Arbeidsforhold

Vi kommer til å møtes og jobbe sammen ved behov. Arbeidet vil da som regel foregå hjemme hos en av oss. Dette gjør det enklere å samarbeide og løse eventuelle problemer som dukker opp. Dersom det ikke er nødvendig å møtes vil vi jobbe hjemme hver for oss, og all kommunikasjon vil foregå via Facebook eller Skype. Siden vi har samarbeidet på tidligere prosjekter før og kjenner hverandre godt, vet vi at vi kommer til å jobbe sammen på en bra måte. 3.5.2 Fordeling av arbeid Arbeidet vil bli fordelt så jevnt som mulig. Hver person skal bidra med utviklingen av det endelige produktet, men vil ha forskjellig hovedansvar. En vil ha ansvaret for applikasjonen, mens den andre har ansvaret for nettstedet. I starten av arbeidet vil begge studenter jobbe med applikasjonen for å få ferdig en fungerende prototype så fort som mulig. Senere vil en student fokusere på applikasjonen og den andre på databaseserveren og nettstedet. Dokumentasjonsskrivingen vil bli jevnt fordelt. 3.5.3 Styringsdokumenter Statusrapport - En rapport som vi leverte i fjor, for å vise at vi var i gang med å finne oppdragsgiver. Prosjektskisse - En kort beskrivelse av oppdragsgiver og oppgaven. Forprosjektrapport - En rapport som utreder dagens situasjon for oppdragsgiver og hvilken løsning vi tenker å implementere. Inkluderer også Arbeidsplan og Risikoanalyse. Prosjektdagbok - En dagbok hvor vi fyller inn korte stikkord og sammendrag om hva vi har gjort for hver dag. Kravspesifikasjon - Utreder alle kravene for løsningen, den har blitt endret underveis. Blant annet har vi valgt å droppe kravet om Precision Teaching-spørsmål med bilder.

3.5.4 Prosjekthjemmesiden Bilde 3.5.4.1: Skjermbilde fra ASP.NET-versjonen av prosjekthjemmesiden. Det var et krav fra skolen å lage en hjemmeside for hovedprosjektet. På denne siden skal vi laste opp alle dokumenter som gjelder for dette hovedprosjektet. Siden ble opprinnelig skrevet i ASP.NET, men vil bli skrevet på nytt i HTML/CSS da serveren der endelig dokumentasjon skal lastes opp ikke støtter ASP.NET. 3.6 Teknologier 3.6.1 XML

XML er et markeringsspråk brukt for å kode dokumenter som er lesbare for både mennesker og datamaskiner. All data organiseres i en hierarkisk struktur, der tagger gir informasjon om hva innholdet er. Hele det grafiske brukergrensesnittet til Android-applikasjonen er kodet i layout-filer som er skrevet på XML-formatet, dette gjør det lettere å lage forskjellige layouter til forskjellige skjermstørrelser. 3.6.2 Java Java er et objektorientert programmeringsspråk med fokus på prinsippet write once, run anywhere. Java-programmer kan kjøre på alle plattformer som har støtte for JVM (Java Virtual Machine). På Androidplattformen kjører Java på en egen virtuell maskin kalt Dalvik. Java er det mest brukte språket for Android-utvikling, og er et av de språkene vi behersker best. Derfor valgte vi å kode Android-applikasjonen i Java. 3.6.3 SQLite SQLite er et open source kodebibliotek som kjører en SQL-basert databasemotor. Dette muliggjør lagring og administrering av SQL-databaser internt i Android-applikasjoner. SQLite er en del av Android API-et, og Android-systemet vil automatisk ta seg av administrering databasen for appen når den opprettes. SQLite benyttes for lokal lagring av alle spørsmål og brukerdata for Android appen. 3.6.4 Ajax Ajax (Asynkron JavaScript og XML) er en webutviklingsteknikk for å lage interaktive nettsider. Det gjør at nettsiden utveksler data med serveren i bakgrunnen slik at man slipper å laste opp siden på nytt hver gang man gjør en forandring. Vi kunne litt om Ajax i forbindelse med ASP.NET og Visual Studio, men hadde liten erfaring om hvordan det ville fungere sammen med PHP. Det måtte derfor litt testing til før vi fikk den funksjonaliteten vi ønsket. 3.6.5 JavaScript JavaScript er et programmeringsspråk som ofte brukes for å tilføre dynamiske elementer til en nettside. Vi har laget en JavaScript-fil med funksjoner som overfører data til PHP-sider. Noen av funksjonene

oppretter også dialogvinduer hvor man må bekrefte at en handling skal utføres. Dette brukes blant annet under sletting av fag, kategori og spørsmål. 3.6.6 PHP PHP (PHP: Hypertext Preprocessor) er programmeringsspråk brukt først og fremst for utvikling av nettsider. Vi hadde opprinnelig tenkt å bruke ASP.NET og Visual Studio for utvikling av nettstedet, men siden bare en av oss kunne programmere i det valgte vi å bruke PHP istedet. PHP var noe begge kjente til fra før av, noe som ville gjøre det lettere å samarbeide for å lage nettstedet. 3.6.7 Apache HTTP Server Apache HTTP Server er et veldig populært HTTP webserver-program som utvikles av Apache-stiftelsen, og utgis med åpen kildekode. Adminnettstedet vårt kommer til å kjøre på en Apache-server. 3.6.8 HTML HTML (HyperText Markup Language) er et markeringsspråk for formatering av nettsider med hypertekst. Det brukes til å organisere informasjon slik som overskrifter, avsnitt og lister. Vi har brukt HTML for å skrive frontend-kode for nettstedet. 3.6.9 CSS CSS (Cascading Style Sheets) er et språk som benyttes til å organisere og definere utseendet på filer skrevet i HTML eller XML. Vi har laget filen Stylesheet.css som bestemmer utseendet på nettstedet. 3.6.10 JSON JSON (JavaScript Object Notation) er en åpen standard for datautveksling, som baserer seg på tekst som er lesbar både for mennesker og datamaskiner. Databaseserveren vår overfører data til Androidapplikasjonen ved hjelp av JSON. 3.6.11 Dropbox Dropbox er en gratis tjeneste på nettet hvor man kan lagre filer i skyen. Vi har ofte brukt denne tjenesten under tidligere prosjekter, og har derfor god kjennskap til den. Vi kommer til å benytte Dropbox for å ta backup av både applikasjonen og nettstedet. 3.6.12 MySQL

MySQL er et SQL-basert databaseadministrasjonssystem, som er veldig populært til bruk i webapplikasjoner. Alle Precision Teaching-spørsmålene til Android-applikasjonen legges på en sentral MySQL-server, som administreres fra Adminnettstedet. 3.6.13 Google Docs Google Docs er en gratis skytjeneste hvor man kan opprette, dele og redigere dokumenter i nettskyen. Vi kommer til å benytte oss av denne tjenesten til å skrive styringsdokumenter og sluttdokumentasjon for prosjektet. En nyttig funksjon er at to Google-brukere kan sømløst jobbe med samme dokument samtidig. 3.7 Utviklingsverktøy 3.7.1 Gedit Gedit er et gratis tekstredigeringsprogram ofte brukt av Linux-brukere. Da vi fikk en Ubuntu 12.04 VM av HiOA som server for nettstedet, valgte vi å bruke Gedit til å kode i. Dette er fordi det er enklere å kode inne på VM en, og fordi vi har god kjennskap til Gedit fra før av. All kode for nettstedet er derfor skrevet i dette programmet. 3.7.2 Eclipse Eclipse er en IDE (Integrated Development Environment) som brukes til å utvikle applikasjoner. Den støtter et bredt spekter av plug-ins for utvikling på mange forskjellige programmeringsspråk. Eclipse med pluginen ADT (Android Developer Tools) er en del av standard SDK-en for Android-plattformen, og derfor falt det naturlig for oss å benytte denne IDE-en til utvikling av Android-applikasjonen. 3.8 Forarbeid I dette kapittelet redegjøres det for alt forarbeid i forkant av utviklingen av produktet. Dette omfatter blant annet datainnsamling og utredning av løsning basert på innsamlede data. 3.8.1 Datainnsamling

Datainnsamling til oppgaven foregikk gjennom gjentatte møter med oppdragsgiver i januar og starten av februar. Møtene ble benyttet til å redegjøre for hva Precision Teaching er, siden ingen på gruppen kunne noe om disse læringsprinsippene fra før av. Det ble også diskutert hvordan Precision Teaching-teknikker kan implementeres i en applikasjon for smarttelefoner og nettbrett med touch-skjerm. Møtene ble også benyttet for å få på plass alle krav oppdragsgiver hadde til løsningen, og hvilke eventuelle krav som kunne nedprioriteres. Disse kravene ble brukt til å skrive Forprosjektrapporten, og etter hvert en overordnet kravspesifikasjon for løsningen. 3.8.2 Utredning Etter å ha diskutert med oppdragsgiver og veileder, besluttet vi at løsningen skulle bestå av en Androidapplikasjon og en databaseserver. Faglærere måtte få tilgang til databaseserveren på en eller annen måte, vi valgte å gjøre det via et enkelt PHP-basert nettsted som ligger på samme server. Dette nettstedet fikk etterhvert navnet Adminnettsted. Android-applikasjonen måtte hente spørsmålene fra databaseserveren. Etter en epostkorrespondanse med Torunn Gjester, faglærer for fagene Databaser og Apputvikling på HiOA, kom vi fram til at en PHPservice som henter ut dataene og gjør dem tilgjengelig som en JSON-tekststreng, ville være den enkleste løsningen. Android-applikasjonen skulle benytte spørsmålene til å utfordre brukeren i tidsavgrensede økter, hvor bruker måtte svare riktig på flest mulig spørsmål før tidsfristen gikk ut. Score ble beregnet ut ifra antall riktige og feil per økt, og dette skulle lagres. Vi kom fram til at bruker måtte benytte seg av et brukernavn i appen, og at scorer brukeren hadde oppnådd skulle lagres under dette brukernavnet. Med disse kravene skrev vi første utkast til en overordnet kravspesifikasjon. Vi kom fram til at databaseserveren skulle kjøre en LAMP-stack bestående av Ubuntu, Apache, MySQL og PHP. Etter at utredningsfasen var konkludert, og vi hadde nok krav å jobbe med, begynte vi med utvikling av produktet.

Bilde 3.8.2.1: Oversikt over løsningen vi kom fram til etter utredning.

3.9 Utvikling I dette kapittelet redegjøres det for utviklingsprosessen for Android-applikasjonen og databaseserveren med Adminnettstedet. Utviklingen er delt inn i to faser: Bilde 3.9.1: Oversikt over utviklingsfasene for Android-applikasjonen, databaseserveren og Adminnettsted.

3.9.1 Fase 1: Første prototype av app Vi begynte å jobbe med første prototype for Android-applikasjonen tidlig i februar, etter at vi var ferdige med datainnsamling og utredning. Vi hadde fått utlevert et Android-nettbrett til utvikling, og planen var å utvikle en prototype på nettbrettet som kunne vises fram til oppdragsgiver. Utviklingen av første prototype gikk rimelig kjapt. I fjor høst hadde vi begge tatt faget Apputvikling, et eget fag som handler om utviklig av Android-applikasjoner. Vi var derfor godt kjent med Android API-et og trengte ikke lære noe mye nytt. I et dokument fra oppdragsgiver var det inkludert et forslag til hvordan appen kunne se ut. I det bildet var grensesnittet organisert med spørsmålsteksten på toppen av siden, med svaralternativer under organisert som en liste. I vår prototype valgte vi å avvike litt fra den layouten, for mer effektiv bruk av skjermplass. Feltet for spørsmålstekst ble gjort større, siden spørsmålene ofte kan være lange. Istedet for å organisere svaralternativene som en liste, valgte vi å sette dem opp som en 2x2 tabell under spørsmålsteksten, så appen fikk bedre vertikal plass. Feltet rundt spørmålsteksten ble farget lyseblå, mens svaralternativene ble lysegrønne, dette for å skape et skille mellom teksten og svaralternativene. 3.9.1.1 Synkende ProgressBar eller nedteller med sekunder? På toppen skulle en GUI-widget angi hvor mye tid som var igjen av økten. Vi diskuterte en stund om vi bare skulle vise antall sekunder og telle disse ned, eller vise tiden grafisk med en synkende ProgressBar. Vi landet til slutt på en synkende ProgressBar, etter å ha kommet fram til at en grafisk representasjon ville virke mindre distraherende og være mer diskret under en økt. Når første prototype var ferdig, så den sånn ut:

Bilde 3.9.1.1.1: T.v. er forslaget fra oppdragsgiver, t.h. er hvordan første prototype ble seende ut. Bilde 3.9.1.1.2: T.v. er hovedmenyen, t.h. er dialogvinduet som viser score etter endt økt.

3.9.1.2 Testing av første prototype Første prototype ble ferdig rundt midten av februar, da organiserte vi et nytt møte med oppdragsgiver for å prøve ut prototypen. Prøvekjøringen gikk over all forventning, og oppdragsgiver var meget positiv til prototypen. Eneste kritikk var at score-vinduet burde fokusere mer på antall riktige. Ellers fikk vi høre at prototypen hadde truffet spikeren på hodet. Med testing konkludert gikk vi over til fase 2 av utviklingen. 3.9.2 Fase 2: Videreutvikling av prototype og utvikling av Adminnettsted 3.9.2.1 Videreutvikling av prototype Videreutvikling av prototypen ble gjort av gruppemedlem Ole Aarnseth. Fra starten av mars til tidlig mai ble prototypen videreutviklet. Alle de viktigste kravene til appen skulle implementeres i løpet av det tidsrommet. Ole opererte med en liste over krav, og jobbet seg nedover listen ved å implementere kravene. 3.9.2.1.1 Versjonkontroll og backup med Dropbox Kildekoden for appen ble lagt ut på en Dropbox-mappe bare gruppemedlemmene hadde tilgang til. Hver gang et nytt krav hadde blitt implementert, ble det regnet som en ny versjon og lastet opp på Dropbox. Å legge kildekoden i nettskyen gjorde at vi kunne utvikle på mange forskjellige datamaskiner. Tidligere versjoner ble også liggende på Dropbox, hovedsaklig til bruk i prosessdokumentasjon. 3.9.2.1.2 Intern lagring - serialisering eller SQLite? Når appen skulle utvikles måtte vi velge hvordan lokal data for appen skulle lagres. Valget sto mellom serialisering, en metode der Java-objekter blir fysisk skrevet til en fil; eller SQLite, en SQLdatabasemotor som følger med Android API-et og muliggjør opprettelse av en lokal SQL-database. Valget falt på SQLite. Hvis vi hadde gått for serialisering hadde vi måtte skrive våre egne søkemetoder for å lete etter objekter, mens i SQLite kan data søkes opp med enkle SQL-setninger. I tillegg var det

praktisk med tanke på at spørsmålene skulle hentes fra en ekstern MySQL-database, med SQLite kunne vi speile denne databasen i appen. 3.9.2.2 Videreutvikling av brukergrensesnittet I tillegg til nye funksjoner, har brukergrensesnittet til Android-applikasjonen gjennomgått forskjellige iterasjoner i utviklingsprosessen. 3.9.2.2.1 Innstillinger Innstillinger-menyen er den menyen som har endret seg mest under utviklingen. Når den først ble implementert inneholdt den en liste for å velge kurs, og en rød knapp for å hardkode inn dummydata for testing av SQLite-databasen (denne knappen ble fjernet i den endelige utgaven.) Lenger ut i utviklingsprosessen ble kursvalg-listen flyttet til sitt eget vindu, Innstillinger-menyen fikk lagt til en knapp for å laste ned nye spørsmål, samt knapper for å velge kurs og kategori for øktene, og en knapp for å slette en bruker (og all scoredata lagret på brukeren), i tillegg til en knapp for å sette URLadressen til databaseserveren som appen henter spørsmål fra. Den røde knappen for å hardkode databasen ble fjernet. Bilde 3.9.2.2.1.1: T.h. den tidligste iterasjonen av Innstillinger-menyen, t.v. er slik den ser ut i siste iterasjon.

3.9.2.2.2 Spørsmålsvalg Menyen for valg av spørsmål endret seg litt fra første iterasjon. Menyen inneholder en rullbar liste der bruker velger spørsmål for økten ved å markere dem i listen. I siste iterasjon ble det lagt til knapper for å velge kurs og kategori, tilsvarende de i Innstillinger-menyen. Bilde 3.9.2.2.2.1: T.v. er første iterasjon av spørsmålsvalg, t.h. er siste iterasjon.

3.9.2.2.3 Ny økt Gangen i grensesnittet for å komme i gang med en ny økt, ble endret da vi under testing konkluderte med at den første iterasjonen inneholdt for mange menyer som bruker måtte gjennom. Vi endret på dette ved å flytte valg av kategori til spørsmålsvalg-menyen, der kategorivalg kan bringes opp med en knapp. Dermed tvinges ikke bruker til å velge kategori hver gang en ny økt skal startes, og vi fikk redusert antall menyer som må gjennomgås. Bilde 3.9.2.2.3.1: Antall menyer bruker må gjennom for å starte en ny økt reduseres i siste iterasjon.

3.9.2.2.4 Øktskjerm Øktskjermen har fra første prototype vært forholdsvis uforandret. Feltet for spørsmålstekst og knappene med svaralternativer har blitt gjort større, for å ha nok plass til spørsmål med opptil 250 bokstaver. Større knapper er også lettere å trykke på, og gir dermed bedre brukervennlighet. Bilde 3.9.2.2.4.1: T.v. øktskjerm fra prototypen, t.h. øktskjerm fra siste iterasjon. 3.9.2.3 Utvikling av databaseserver og Adminnettsted

Etter at første prototype av applikasjonen var ferdigtestet, begynte gruppemedlem Vegard Krusedokken å utvikle nettstedet. Under tidligere møter med oppdragsgiver ble det utredet noen få krav til nettstedet. Et av disse kravene var at kun faglærere skulle få tilgang til nettstedet. Et annet krav var at brukerne skulle kunne opprette, endre, slette og vise spørsmål. Det var ellers ingen andre krav, og vi stod ganske fritt til hvordan vi kunne lage nettstedet. Det første som ble laget var indeks-siden, som er den siden man kommer til når man kobler seg til nettstedet. Det ble deretter opprettet en header-fil som blir inkludert på alle synlige sider. Denne filen har en svart bakgrunn med HiOA-logoen og tittelen Precision Teaching. Den har også to lenker: hjem og logg inn. Det ble etter dette laget to div-tags som former to søyler med grå bakgrunn. Søylene er spredd til venstre og høyre. Utseendet til nettstedet ble definert i filen Stylesheet.css. Etter at indeks-siden ble opprettet og utseendet var definert, ble innloggingssiden laget. Det ble lagt til en overskrift, to inputfelt og en knapp for å logge seg inn. Det var et inputfelt for epost, og et inputfelt for passord. Etter dette ble klassen class.login.php påbegynt. Da hver tabell i databasen trengte funksjoner som opererte mot dem, fant vi det naturlig å løse oppbygningen av nettstedet i backend på en objektorientert måte i form av PHP-klasser. Disse klassene er omtalt i produktrapporten. Når innloggingsfunksjonene var på plass ble det laget en ny header-fil, samt en ny indeks-side for innloggede brukere. Filen er helt lik som den første header-filen bortsett fra at den har lenken logg ut istedenfor logg inn. Det ble deretter opprettet en meny som er inkludert på alle sider brukerne har tilgang på som innlogget. Da menyen var på plass ble de andre sidene opprettet en etter en. Først en side for å opprette brukerkontoer, deretter sider for å håndtere fag, så sider for kategorier, og til slutt sider for spørsmål. 3.9.2.3.1 Endringer i Adminnettstedet Det har blitt foretatt en rekke endringer underveis i utvikling av nettstedet. Istedenfor å dele inn menyen i flere undermenyer, var det bare èn stor meny. Dette ble endret etter testing av veileder på grunn av estetiske og praktiske årsaker. Størrelsen på lenkene i menyen er også forandret. De er nå bedre adskilt og lettere å trykke på. Vi la også til flere lenker enkelte steder for å bedre navigasjonen og flyten på nettstedet. I starten brukte vi ikke JavaScript og Ajax. Vi fant fort ut at det var nødvendig å bruke disse, da det var tungvint å måtte laste opp siden på nytt hver gang vi gjorde en handling. Det var også tungvint siden man

måtte velge fra drop down -listene på nytt hver gang et spørsmål ble laget. Vi trengte også dialogvinduer for å sikre enkelte funksjoner, for eksempel sletting. Dette ble innført slik at brukeren hadde mulighet for å angre handlingen. Brukervennligheten økte betraktelig da vi tok i bruk JavaScript og Ajax. Vi gjorde også noen endringer i databasen. Før hadde alle brukere av nettstedet tilgang til alt innholdet i databasen. De kunne se og endre på alt som hadde blitt opprettet. Dette ble gjort om på slik at brukeren kun kunne se og forandre det han selv hadde laget. Vi løste dette ved å legge til en fremmednøkkel (AdminID) i hver gjeldende tabell, og tilpasse alle funksjoner som ble berørt av dette. Denne endringen ble innført etter diskusjon med oppdragsgiver. En siste endring ble gjort under systemtestingen. Istedenfor å ha radiobuttons som bestemmer hvilket svar som er riktig, gjorde vi så første svar alltid er riktig. Denne endringen kom etter ønske fra oppdragsgiver. 3.10 Forsinkelser Noen ganger har vi måtte fokusere tiden vår på obliger i andre fag, men bortsett fra det har det ikke oppstått noen store forsinkelser. 3.11 Problemer og løsninger I dette kapittelet redegjøres det for noen av problemene vi hadde underveis. 3.11.1 Android ListView markering Et problem vi støttet på underveis var en ganske merkelig oppførsel i ListView-objektet i spørsmålsvalgmenyen. Når flere spørsmål ble markert kunne det hende at objekter nederst i listen også ble markert. Grunnen til denne oppførselen var at Android API-et resirkulerer Views i ListViewen for å øke ytelsen når listen rulles. Vi fikk løst problemet ved å skrive egne ListView-adaptere, der koden som resirkulerer Views sørger for at Views som er markerte får denne markeringen fjernet før resirkulering.

3.11.2 JSON skriver ikke ut UTF-8 karakterer Når vi kodet PHP-servicene som skulle hente ut data fra MySQL-databasen og sende til appen som en JSON-tekststreng, så vi at JSON-strengen som kom ut hadde hoppet over alle UTF-8 karakterer. For å lage JSON-tekststrengen brukte vi PHP-funksjonen json_encode(). LAMP-serveren kjørte på det tidspunktet PHP 5.3, i denne versjonen støtter ikke denne funksjonen UTF-8 karakterer, istedet blir de hoppet over. Løsningen på problemet ble å oppdatere LAMP-serveren til PHP 5.4. I denne versjonen kan funksjonen json_encode() kalles med konstanten JSON_UNESCAPED_UNICODE, som gjør at funksjonen ikke hopper over UTF-8 karakterer. 3.11.3 Feil ved laging av spørsmål Det oppstod noen feil ved laging av spørsmål på nettstedet. En feil var at plusstegnet ikke kom med når man satte inn spørsmålet i databasen. Dette til tross for at filterfunksjonen tillot plusstegn. Vi prøvde å fjerne filterfunksjonen for å se om det kom med da, men plusstegnet ble fortsatt ikke lagret. Vi fant ingen løsning på denne feilen. En annen feil vi oppdaget når vi lagde spørsmål var at UTF-8 karakterer ikke ble registrert i databasen på en korrekt måte. Det ble registrert helt andre tegn enn æ, ø, å. Denne feilen ble løst ved å bruke mysqli_set_charset() i de forskjellige funksjonene. 3.11.4 Feil i dialogvinduet Opprinnelig hadde vi tenkt at dialogvinduet, som dukker opp ved sletting av fag og kategorier på nettstedet, skulle vise navnet på faget og kategorien som ble slettet. Grunnet en uidentifisert feil fikk vi ikke dette til å fungere. 3.12 Testing under utviklingsfasen Under utvikling av Android-applikasjonen og Adminnettstedet ble hver funksjon enhetstestet med white box-testing under implementering. Koden ble kvalitetssikret med det mål at ingenting skulle generere en fatal exception og få programmet til å kræsje. For å sikre dette ble feks. funksjoner skrevet med kode som

skulle blokkere såkalt bad input, og deretter testet mot test cases som inneholdt bad input for å sjekke at koden fungerte som den skulle. Enhetstestingen vår beskrives i detalj i Testrapporten. 3.13 Systemtesting og endelig produkt Systemtesting ble utført den 21. mai ved oppdragsgivers lokaler i Wergelandsveien 27. Kontaktperson Børge Strømgren og et utvalg studenter fikk prøve appen på nettbrettet, samt teste ut Adminnettstedet på en laptop. Testen beskrives i detalj i Testrapporten. Gjennom dette prosjektet har vi etter beste evne forsøkt å lage et produkt som skal oppfylle kravene til oppdragsgiver. Etter at systemtesting ble utført fikk vi veldig gode tilbakemeldinger. Løsningen kan forbedres på noen områder, og det endelige produktet kan videreutvikles. I skrivende stund har vi ikke rukket å tilpasse layoutene for smarttelefoner, så appen vil kjøre best på Android-nettbrett. Dette vil komme i framtiden. 3.13.1 Hva kunne vært annerledes 3.13.1.1 Krav til lengde for spørsmålstekst Et problem vi støttet på gjaldt oppdragsgivers krav til lengde på spørsmålstekst. Kravet lå på maksimalt 250 bokstaver, noe som bød på utfordringer når grensesnitt for smarttelefoner med mindre skjermer skulle utvikles. Skriften måtte krympes en del for å få plass til 250 bokstaver. Problemet med dette kravet rakk vi ikke ta opp med oppdragsgiver, konsekvensen er at spørsmålsteksten kan oppleves som liten når appen kjøres på smarttelefoner med mindre skjermer.

3.14 Sluttdokumentasjon Når sluttdokumentasjon skulle skrives så vi først på en mal vi fikk av veileder, samt malen til Ann-Mari Torvatn. I tillegg så vi også på hva mange andre tidligere grupper gjorde, og vurderte selv hva som passet til denne prosjektoppgaven. Etter å ha diskutert med veileder, endte vi opp med å avvike en del fra malene. All dokumentasjon ble skrevet på Google Docs og lagret på Googles skylagringstjeneste Google Drive. Fordelen med Google Docs er at dokumenter kan redigeres fra en hvilken som helst datamaskin med internettilkobling og nettleser, i tillegg til at flere brukere kan jobbe samtidig med samme dokument. Dette gjorde det enkelt å samkjøre dokumentasjonen. Sluttrapporten er delt inn i mange kapitler og underkapitler, og består av følgende hoveddeler: Produktrapport: Tar for seg det endelige produktet for prosjektet. Prosessrapport: Tar for seg arbeidsprosessen som resulterte i produktet. Testrapport: Tar for seg hvordan testing ble utført, blant annet brukertesting. Brukerveiledning: Forklarer hvordan Android-applikasjonen og Adminnettstedet skal brukes. Vedlegg: Diverse styringsdokumenter og endelig kravspesifikasjon. 3.15 Konklusjon Gjennom studieløpet vårt på Høyskolen i Oslo og Akershus er dette det største prosjektet vi har jobbet med. Det har vært en tidkrevende, men lærerik prosess. Læringskurven har vært bratt noen steder, men erfaringene vi har fått har vært verdt det. Prosjektet har gitt oss en bedre forståelse for hvordan større prosjekter burde takles, og vi har erfart viktigheten av god planlegging med krav og frister. Samarbeidet har vært bra hele veien, med god kommunikasjon med både veileder og oppdragsgiver. Med dette har vi fått et produkt vi er stolte over og veldig mye verdifull erfaring på veien.

4 Produktrapport I denne rapporten gis det en detaljert beskrivelse av produktet, dette omfatter Precision Teaching applikasjonen for Android-enheter, samt Adminnettstedet for databasen som benyttes av appen. 4.1 Beskrivelse av produkt 4.1.1 Generell beskrivelse av Precision Teaching App Precision Teaching app for Android er en læreapp ment for studenter hos Høyskolen i Oslo og Akershus. Appen skal benytte læringsprinsipper fra det som kalles Precision Teaching. Formålet er at studenter skal kunne benytte appen til å øve på mestring og forbedre kompetansen innenfor forskjellige fag. 4 Appen vil fungere ved at brukeren blir utfordret med en rekke multiple choice -spørsmål, der brukeren skal svare riktig på flest mulig spørsmål innenfor en tidsavgrensning. Dette kalles en økt, og økter kan ha tidsavgrensninger fra 10 sekunder og opptil 1 minutt. 4.1.2 Generell beskrivelse av Adminnettsted 4 Fag der Precision Teaching-teknikker er relevante.

Nettstedets oppgave er å gi faglærere et verktøy for å kunne administrere innholdet i "Precision Teaching"-appen. Det gir lærerne mulighet til å legge inn fag, kategorier, spørsmål og svar inn i en database. Når læreren er ferdig med å legge inn spørsmål, kan han gjøre det nye innholdet klart for nedlastning. Elever vil da kunne laste ned det nye innholdet fra databasen til appen. Det vil også være mulig for lærerne å endre og slette innholdet i databasen. 4.2 Rammekrav Her beskrives de rammekrav som ble satt før utvikling begynte. 4.2.1 Krav til løsning 4.2.1.1 Funksjonelle krav Precision Teaching app for Android Bruker skal utfordres av treningsøkter, med multiple choice spørsmål. Hvert spørsmål skal ha opptil fire svaralternativer. Hver treningsøkt skal være tidsavgrenset. Svaralternativene skal stokkes om hver gang et spørsmål vises. Bruker skal kunne velge tidsfrist på økt. Hver treningsøkt skal inneholde flere spørsmål enn det brukeren rekker å svare på innenfor tidsfristen. Scorer for hver økt skal lagres under et individuelt brukernavn for hver bruker av appen. Applikasjonen skal etter hver økt vise hvor mange riktige og hvor mange feil bruker hadde. Bruker skal ha mulighet til å se hva som var feil, etter endt økt. Frekvens for antall riktige og antall feil delt på tid for hver økt, skal lagres lokalt under brukernavnet. Rådataene for frekvens for alle økter gjennomført i løpet av en dag, skal kunne sendes til evt. faglærere. Applikasjonen skal hente spørsmål fra en ekstern database, og lagre disse lokalt.

Applikasjonen skal kunne sjekke om databasen har blitt endret, og oppdatere de lokale spørsmålene deretter. Bruker skal kunne velge i en liste hvilke spørsmål som skal trenes på i økten. Etter endt økt skal bruker kunne velge om hun/han vil øve på de samme spørsmålene eller en annen kategori. Adminnettsted Faglærere skal ha tilgang til Adminnettstedet. Faglærere skal autentisere seg for nettstedet med brukerkontoer (som består av brukernavn/epost og passord). Faglærere skal kunne opprette/endre/slette spørsmål, fag og kategorier i Adminnettstedets database. Spørsmålene skal lagres i en database. Databaseserveren skal gjøre spørsmålene tilgjengelig for Android applikasjonen. 4.2.1.2 Tekniske krav Applikasjonen skal utvikles for Androidplattfomen, og minimumsversjonen for å kjøre applikasjonen skal være Android 2.2 (API 8). Applikasjonen skal kodes i Java Runtime Environment 1.5. Applikasjonen skal utvikles i Eclipse IDE med ADT Bundle. Adminnettstedet skal utvikles i HTML, CSS, PHP og Javascript. Gedit skal brukes til å skrive kildekoden til Adminnettstedet. JSON skal brukes for å overføre data fra Adminnettsted til applikasjonen. Serveren for Adminnettstedet skal kjøre en LAMP stack som skal bestå av Ubuntu Linux, Apache HTTP Server, MySQL og PHP.

4.2.2 Økonomi Dette er i hovedsak en nullbudsjettsoppgave, men Høyskolen i Oslo og Akershus skal låne oss et Androidnettbrett til utvikling. I tillegg skal vi få en virtuell maskin på en av høyskolens servere til Adminnettstedet. 4.3 Hovedfunksjoner 4.3.1 Precision Teaching app for Android - Sentrale funksjoner 4.3.1.1 Økter Den alle mest sentrale funksjonen for appen å kjøre såkalte økter, det vil si utfordre brukeren med en rekke spørsmål innenfor en tidsavgrensning. Brukeren trykker på svaret hun/han tror er riktig, så vil neste spørsmål vises. Rekkefølgen på spørsmål er tilfeldig, og svaralternativene bytter plass for hver visning. Når tiden er over vil brukeren få vite hvor mange riktige og feil hun/han hadde.

Bilde 4.3.1.1.1: Skjermbilde fra et spørsmål i en økt som kjører. 4.3.1.2 Velge spørsmål Brukeren velger selv hvilke spørsmål som inngår i en økt. Minimum to spørsmål må velges for at økten skal starte. Spørmål er fordelt på kategori, som igjen er fordelt på kurs.

Bilde 4.3.1.2.1: Skjermbilde fra menyen for å velge spørsmål. 4.3.1.3 Tidsavgrensning Bruker velger selv hvilken tidsavgrensning hun/han ønsker. Tidene som kan velges er 10 sekunder, 15 sekunder, 30 sekunder og 1 minutt. 4.3.1.4 Brukernavn Når en økt skal kjøres må bruker velge et brukernavn. Antall riktige/feil for hver eneste økt som gjennomføres vil bli lagret under dette brukernavnet. 4.3.1.5 Highscore Bruker kan se alle scorene som er lagret på et brukernavn i en såkalt highscore -liste, der alle score blir vist i en liste ordnet etter antall riktige.

4.3.1.6 Eksporter til epost Bruker kan også få alle scorer (antall riktige/feil) som er registrert på samme dato skrevet ut til en tekstfil, som eksporteres som vedlegg til Android-enhetens epostklient og kan sendes til feks. faglærer. 4.3.1.7 Hurtigøkt Bruker kan velge å spille en av de 10 sist spilte øktene gjennom Hurtigøkt-funksjonen. 4.3.1.8 Spørsmål hentes fra ekstern database Alle spørsmålene vil bli hentet fra en ekstern databaseserver på høyskolen. Første gang appen startes opp vil spørsmål lastes ned automatisk. Etter dette kan bruker velge å sjekke om nye spørsmål til appen er tilgjengelig, og isåfall laste ned disse. Som nevnt tidligere er alle spørsmål fordelt på kategori, som igjen er fordelt på kurs. For eksempel kan kurset Matematikk inneholde kategoriene Addisjon og Subtraksjon, og disse kategoriene vil da inneholde addisjonsspørsmål og subtraksjonsspørsmål. 4.3.2 Adminnettsted - Sentrale funksjoner Som nevnt tidligere er nettstedets oppgave å gi faglærere et verktøy for å kunne administrere innholdet i "Presicion Teaching"-appen. Det er kun faglærere som vil få tilgang til nettstedet. De vil få rettigheter til å opprette, endre og slette fag, kategorier og spørsmål. De vil også ha mulighet til å se hva de har laget. Faglærere vil kun se hva de selv har laget, ikke hva andre lærere har opprettet. Under følger et bilde av startsiden for innloggede brukere. For flere bilder se brukerveiledningen.

Bilde 4.3.2.1: Bilde av startsiden for innloggede brukere. 4.3.2.1 Meny Etter at faglærer har logget seg inn vil det dukke opp en meny på venstre side. Denne menyen er inndelt i Fag, Kategori, Spørsmål og Ny admin. Disse er igjen inndelt i nye lenker for å lage, slette, endre eller vise, bortsett fra Ny admin som kun kan opprette nye brukerkontoer for nettstedet. Det er også lagt til flere lenker rundt omkring på nettstedet for å skape redundans og gjøre det lettere å navigere. 4.3.2.2 Fagmeny Denne menyen inneholder seks lenker. De fire første lenkene er "Nytt fag", "Slette fag", "Endre fag" og "Vis fag". De to siste lenkene er "Kategori" og "Spørsmål" som linker til menyene for kategori og spørsmål. 4.3.2.3 Nytt fag På denne siden oppretter man fag. Den har også to lenker til sidene for å lage kategori og spørsmål. Dette er gjort for å skape redundans og en bedre flyt i bruk av nettstedet. 4.3.2.4 Slette fag Denne siden viser hvilke fag man kan slette. Et dialogvindu sikrer at slettingen går riktig for seg.

4.3.2.5 Endre fag På denne siden kan man endre navn på fagene. Man velger fra en liste hvilket fag man vil endre på. 4.3.2.6 Vise fag Her vises alle fag som brukeren har laget. 4.3.2.7 Kategorimeny Denne menyen inneholder seks lenker. De fire første er "Ny kategori", "Endre kategori", "Slette kategori" og "Vis kategori". De resterende to linker til fagmenyen og spørsmålsmenyen. 4.3.2.8 Ny kategori Her kan man lage nye kategorier som skal tilhøre et fag. Man kan velge fra en liste hvilket fag kategorien skal tilhøre. Det finnes også to lenker til sidene for å opprette fag og spørsmål. 4.3.2.9 Vise kategori Denne siden viser alle kategorier som brukeren har lagt inn ved å velge fag fra en liste. Den viser også hvilke kategorier som er ferdige og klare for nedlastning. 4.3.2.10 Slette kategori På denne siden kan man slette kategorier. Kategoriene dukker opp ved å velge fag fra en liste. Et dialogvindu sikrer at slettingen går riktig for seg. 4.3.2.11 Endre kategori Her kan brukeren endre navn på kategorier som han har lagt inn. 4.3.2.12 Spørsmålsmeny Spørsmålsmenyen inneholder seks lenker. Disse lenkene er "Nytt spørsmål", "Slette spørsmål", "Endre spørsmål" og "Vis spørsmål", samt lenkene "Fag" og "Kategori". De to sistnevnte lenkene linker til fagmenyen og kategorimenyen.

4.3.2.13 Nytt spørsmål På denne siden kan man legge inn nye spørsmål og svar. Når man er ferdig med å legge inn spørsmål, kan man gjøre det nye innholdet klart for nedlastning. Brukeren får også se hvilket spørsmål og hvilke svar han lagde. Det finnes også to knapper som linker til sidene for å opprette nye fag og kategorier. 4.3.2.14 Slette spørsmål Her kan man slette spørsmål. Spørsmålene dukker etter at man har valgt fag og kategori fra to lister. Et dialogvindu sikrer at slettingen går riktig for seg. 4.3.2.15 Endre spørsmål På denne siden kan man endre på spørsmål. Man velger fag, kategori og det spørsmålet man vil endre fra noen lister. 4.3.2.16 Vise spørsmål Denne siden viser spørsmål og svar som brukeren har lagt inn. De dukker opp etter at man har valgt fag, kategori og det spørsmålet man vil se nærmere på fra noen lister. 4.3.2.17 Ny admin Her kan man opprette nye brukerkontoer for faglærere. Det er to inputfelt for å skrive inn epost og passord.

4.4 Brukergrensesnitt 4.3.1 Precision Teaching app for Android For en Android-applikasjon ment for mobile enheter med touch-skjerm, så vil det grafiske brukergrensesnittet ha meget stor betydning for brukeropplevelsen. Smarttelefoner med mindre skjermer byr ofte på design-utfordringer, siden man da har mindre brukbar skjermplass til applikasjonens grensesnitt. 4.3.1.1 Tekniske løsninger 4.3.1.1.1 XML Layout I Android API-et er det vanlig at GUI-en blir definert i layout-filer som er skrevet på XML-format. På denne måten kan man enkelt bygge opp forskjellige layouter som er spesialtilpasset de mange forskjellige skjermstørrelser Android-enheter kan komme i.

Bilde 4.3.1.1.1.1: Eksempel på en Android layout-fil i XML-format. 4.3.1.1.2 Android Button Button er en GUI widget i Android API-et som representerer en enkel knapp ment for touch-skjermer. Knappene vi har benyttet i appen er hovedsaklig lyseblå eller lysegrønne, og vil skifte til en mørkere fargetone når de blir trykket på, for å indikere ovenfor bruker at knappen er trykket inn. Knapper som er inaktive5 er grået ut, for å indikere at de ikke er trykkbare. Bilde 4.3.1.1.2.1: Eksempel på en knapp i appen, t.v. i vanlig lyseblå farge; t.h. er den trykket inn, og har derfor en mørkere fargetone. 5 At en knapp er inaktiv vil si at den ikke vil gjøre noe når den trykkes inn, grunnet at den mangler de rette parametre for å foreta den tiltenkte handlingen. Hurtigøkt -knappen vil feks. være inaktiv hvis appen ikke finner noen lagrede økter.

Bilde 4.3.1.1.2.2: Eksempel på en inaktiv knapp. 4.3.1.1.3 Android Fragment Fragmenter i Android API-et representer en bit av grensesnittet med egne GUI-layouter. Fragmenter har en egen livssyklus fra skapelse til destruering, og egne input events. Appen benytter fragmenter for å skape et dynamisk og kjapt grensesnitt, for god brukeropplevelse. Alle menyer i appen er et eget Fragment, og appen navigerer fra meny til meny ved å utføre en fragmenttransaksjon. I tillegg benyttes også Fragmenter til å kjøre AsyncTask-operasjoner, mer om dette i AsyncTask-delen på side 46. 4.3.1.1.4 Android ListView ListView er en GUI widget i Android API-et som viser rullbare lister med objekter som er trykkbare. Brukeren kan rulle gjennom listen ved å gjøre vertikale swipe -bevegelser på touch-skjermen, og velge et objekt ved å trykke på det. I noen lister kan bruker kun velge ett objekt, mens i andre må bruker markere flere objekter i listen.

Bilde 4.3.1.1.4.1: Eksempel på en ListView i appen. 4.5 Teknisk arkitektur Alle spørsmålene som benyttes i appen hentes fra databasen, og faglærere kan legge inn, redigere og slette spørsmål i databasen via Adminnettstedet, som befinner seg på samme server som databasen.

Bilde 4.5.1: Helhetlig oversikt over interaksjonen mellom app og database/adminnettsted. Videre følger eksempler på hvordan kildekoden for både app og Adminnettsted er bygget opp. 4.4.1 Precision Teaching App for Android - intern arkitektur 4.4.1.1 Teknologier 4.4.1.1.1 SQLite

For intern lagring av spørsmål benytter appen seg av SQLite, det er et open source kodebibliotek som kjører en SQL-basert databasemotor. Dette muliggjør lagring og administrering av SQL-databaser internt i Android-applikasjoner. SQLite er en del av Android API-et, og Android-systemet vil automatisk ta seg av administrering databasen for appen når den opprettes. SQLite-databasen som benyttes i appen er et speilbilde av av MySQL-databasen på serveren. Appen vil hente alt innhold fra tabellene Course, Category, Question og Answer i MySQL-databasen, og lagre det lokalt med SQLite. Bilde 4.4.1.1.1.1: SQLite-databasen er et speilbilde av MySQL-databasen. 4.4.1.1.2 AsyncTask

AsyncTask er en klasse i Android API-et som på en enkel måte muliggjør kjøring av tidkrevende operasjoner i en bakgrunnstråd. Appen benytter AsyncTask til blant annet databaseoperasjoner på den lokale SQLite-databasen, samt til å laste ned spørsmål fra den eksterne databaseserveren. Alle AsyncTask-objekter i appen kjører inni et Fragment-objekt, der fragmentets retaininstance -attributt er satt til true. Når et fragment har retaininstance, vil instansen av fragmentet overleve at den omsluttende aktiviteten destrueres og gjenskapes på nytt. Dermed vil AsyncTask-objektet kjøre uavbrutt inni fragmentet, uansett om aktiviteten destrueres og gjenskapes. 4.4.1.1.2.1 AsyncTask i SelectCourseFragment, SelectCategoryFragment og SessionQuestionFragment For å gi brukeren mulighet til å velge kurs, kategori og spørsmål for en økt, benytter appen seg av fragmentene SelectCourseFragment, SelectCategoryFragment og SessionQuestionFragment. Disse Fragmentene er internt bygget opp på samme måte, der objektene fra databasen vises i en ListView. Når fragmentet opprettes, eller tegner opp grensesnittet på nytt, vil den først sjekke om den har objektene til listen fra før av, hvis ikke vil objektene hentes fra den lokale SQLite-databasen med en AsyncTask, og et dialogvindu med en progressbar vil vises mens AsyncTasken kjører.

Bilde 4.4.1.1.2.1.1: Tilstandsdiagram som viser hvordan fragmentene henter objektene fra databasen og viser dem i ListView. 4.4.1.2 Sentrale klasser Siden appen er kodet i java, er den basert i objektorientert programmering. Her er noen av de viktigste klassene for appens interne programlogikk. 4.4.1.2.1 User User-klassen representerer brukeren som kjører en Precision Teaching-økt. 4.4.1.2.2 Question Question-klassen representerer et spørsmål. Den inneholder opptil 4 Answer-objekter i en array. 4.4.1.2.3 Answer Answer-klassen representerer et svar som er tilknyttet et Question-objekt. 4.4.1.2.4 Session Session-klassen representer en Precision Teaching-økt. Den inneholder alle Question-objekter som inngår i økten i en array, i tillegg til andre variabler som øktens tidsavgrensning, samt et User-objekt som økten er knyttet til og øktens score.

Bilde 4.4.1.2.4.1: Klassediagram for et Session-objekt, som her eksempelvis inneholder 4 Question-objekter i arrayen. 4.4.1.3 Kjøring av en Precision Teaching økt Når er Precision Teaching økt kjøres, vil hvert spørsmål hentes fra Session-objektet ved å kalle objektets nextquestion()-metode. Denne metoden vil sørge for at et tilfeldig spørsmål vises, og hindre at samme spørsmål vises to ganger på rad. Svarene til et spørsmål vil stokkes om for hver visning. Når bruker besvarer et spørsmål, vil det registreres om svaret var riktig eller galt, og score settes ut ifra det (antall riktige/feil.) Så vil neste spørsmål hentes med nextquestion(). Når tiden er over og økten er ferdig vil scoren i Session-objektet lagres i SQLite-databasen, deretter vil objektets score nullstilles, og en ny økt kan kjøres med samme Session-objekt. 4.4.2 Adminnettsted - intern arkitektur Nettstedets oppbygning i backend er løst på en objektorientert måte. Den består av forskjellige PHPklasser som hver representerer en tabell i databasen. Disse klassene er "class.admin.php",

"class.answer.php", "class.category.php", "class.course.php", "class.question.php" og "class.dbversion.php". Den har også en klasse, "class.login.php", som håndterer alle funksjoner for å logge seg inn på nettstedet. 4.4.2.1 Class.admin.php Denne klassen inneholder alle funksjoner for å opprette nye brukerkontoer for faglærere. Den sjekker også at all input er korrekt, og rapporterer til brukeren dersom det oppstår noen feil. 4.4.2.2 Class.answer.php Klassen inneholder en funksjon for å lage svar. Den har også en filterfunksjon for å sikre input. 4.4.2.3 Class.category.php "class.category.php" består av mange forskjellige funksjoner for å behandle kategorier. Den har funksjoner for å opprette, vise, endre og slette kategorier. Det finnes også mange ulike funksjoner som sikrer at bruker fyller inn korrekt input, og som sier ifra hvis det er noen feil. 4.4.2.4 Class.course.php Denne klassen fungerer på samme måte som "class.category.php", men behandler fag istedenfor kategorier. 4.4.2.5 Class.dbversion.php "Class.dbversion.php" inneholder en funksjon for å oppdatere tabellen Version hver gang innholdet i databasen blir endret. 4.4.2.6 Class.login.php Som nevnt tidligere håndterer denne klassen alle funksjoner for å logge seg inn på nettstedet. Den sjekker at brukernavn og passord er korrekte, og bruker også en tilfeldig generert token for ekstra sikkerhet. Klassen sikrer også input, og sier i fra hvis det oppstår feil. Økten ("session") blir også registrert med id, epost og kryptert passord. 4.4.2.7 Javascript/Ajax I tillegg til PHP-klassene nevnt ovenfor bruker nettstedet Javascriptet "functions.js". Dette skriptet inneholder flere funksjoner som overfører verdier over til andre PHP-sider. Disse verdiene blir blant annet brukt for å opprette objekter av forskjellige typer, som igjen blir brukt til å populere "drop down"-lister og

vise tabeller. De blir også brukt ved sletting og under opprettelse av spørsmål og svar. Dette er gjort for å slippe å laste inn siden på nytt hver gang man lager et spørsmål. Det gjør også at man slipper å laste inn innholdet i "drop down"-listene manuelt via knapper. 4.4.2.8 Sikkerhet Nettstedet er sikret på flere måter. For det første finnes det filterfunksjoner i de ulike PHP-klassene som fjerner uønskede tegn. Dette bidrar til å sikre mot "sql-injection". For det andre blir det tatt i bruk en "session token" for å indentifisere økten når man logger seg inn. Hver side sjekker om brukeren er logget inn. Hvis han ikke er det, blir han omdirigert til startsiden for nettstedet. Alle passord i databasen er også kryptert med sha256. Ved tilkobling og spørring mot databasen er det brukt mysqli istedenfor mysql. Dette er gjort da mysqli er en nyere og sikrere versjon enn mysql. 4.4.3 Databaseserver - intern arkitektur

Databaseserveren som administreres gjennom Adminnettstedet kjører MySQL 5.5.35 for Ubuntu. Android-applikasjonen kobler seg til databasen gjennom noen PHP-skript som skriver ut de relevante tabellene som en JSON-tekststreng. Den interne oppbygningen i databasen er relativt ukomplisert, nedenfor følger et ER-diagram. Bilde 4.4.3.1: ER-diagram over hele databasen. 4.6 Konklusjon Utifra de krav som ble gitt, og de implementasjoner vi har gjort, har vi levert et rimelig tilfredsstillende produkt. Det er brukervennlig, responderer raskt og følger kravene vi fikk av oppdragsgiver. I skrivende stund har vi ikke rukket å få på plass spesialtilpassede layouter for Android-smarttelefoner, så appen vil fungere best på nettbrett. 5 Testrapport

I denne rapporten beskriver vi testingen av Android-applikasjonen og Adminnettstedet. Testingen har foregått på flere måter. Gruppemedlemmene har kontinuerlig enhetstestet sin egen kode under utviklingen. Første prototype ble testet av oppdragsgiver. Da nettstedet var på plass, ble også dette testet av oppdragsgiver. Systemtesting av det endelige produktet fant sted etter utviklingsfasen, med påfølgende stresstest av server. 5.1 Formål med testing Det finnes flere formål med testing av produkter. Et formål er at det avdekker feil i produktene. Et annet formål er at det sjekker at produktene oppfører seg slik de er ment å gjøre. Det sikrer også at produktene oppfyller kravene satt av oppdragsgiver, samt er testing nyttig for å oppdage svakheter i design og brukervennlighet. Stresstesting av servere er også nødvendig for å kunne evaluere kapasiteten og hvor mange brukere serveren kan tjene. 5.2 Testverktøy

5.2.1 Teknologier 5.2.1.1 Eclipse IDE med debugger og emulator Til å utvikle Android-applikasjonen benyttet vi Eclipse IDE med plugin-en Android Deceloper Tools. Denne plugin-en har mulighet til å emulere Android-enheter og kjøre applikasjonen direkte i Eclipse IDE, og kombinere dette med debugger-funksjonen i Eclipse som viser hvor feil oppstår i koden under kjøring. Bilde 5.2.1.1.1: Eclipse IDE med emulator og debugger. 5.2.1.2 Mozilla Firefox med Firebug add-on For å teste Adminnettstedet, samt finne ut antall HTTP requests nettstedet og PHP-servicene tengte, benyttet vi nettleseren Mozilla Firefox med Firebug add-on. Den lar oss inspisere HTML og CSS kode, samt verdien av PHP POST og GET variabler mens de kjører. I tillegg er den nyttig for å måle nettverksytelsen.

Bilde 5.2.1.2.1: Mozilla Firefox med Firebug add-on. 5.2.1.3 ApacheBench ApacheBench er et verktøy som følger med Apache HTTP Server, og er ment for stresstesting av Apacheserveren og måling av hvor mange HTTP requests serveren klarer å takle. ApacheBench ble benyttet for å stressteste Adminnettstedet og PHP-servicene som Android-applikasjonen kobler seg til. 5.2.1.4 PHP utviklingskonfigurasjon Under utvikling av Adminnettstedet ble konfigurasjonsfilen til PHP satt til utviklingsinnstillinger. Med utviklingsinnstillinger vil PHP gi feilmeldinger direkte til nettleseren når feil i koden oppstår under kjøring, dette er nødvendig for å enkelt teste og kvalitetssikre PHP-koden.

5.2.2 Testenheter Samsung P7500 Galaxy Tab 10.1 3G CPU: ARM Cortex-A9 Dual-core 1 GHz Minne: 1 GB RAM OS: Android 3.1 (Honeycomb) Skjerm: 10 tommer Dette var hovedenheten som vi benyttet under utvikling av Android-applikasjonen, samt prototypetesting og systemtesting hos oppdragsgiver. Selvbygget Windows 7 PC CPU: Intel Core 2 Quad Q9450 @ 3,2 GHz (overklokket) Minne: 4 GB RAM OS: Microsoft Windows 7 32 bit Dette var PC-en som ble benyttet til å emulere mange forskjellige Android-enheter i Eclipse IDE, som også ble benyttet til testing under utvikling av Android-applikasjonen. Lenovo Windows 8 Laptop CPU: Intel Core i7-3632qm @ 2,2 GHz Minne: 8 GB RAM OS: Microsoft Windows 8 64 bit Denne bærbare PC-en ble brukt under utvikling av første prototype. Den ble senere benyttet til å programmere og teste nettstedet.

5.3 White box og black box Gjennom denne testrapporten blir uttrykkene white box og black box brukt for å beskrive tester. White box referer i denne rapporten til testing av den interne kildekoden, der kjennskap til denne koden er nødvendig for testingen. Formålet er å avdekke svakheter og feil i kildekoden, og korrigere disse feilene. All enhetstesting gjort av gruppemedlemmene har vært av typen white box. Black box referer til funksjonstesting av produktet, der testeren ikke bryr seg om den interne kildekoden for produktet. Formålet er å teste at produktet fungerer som det skal, at funksjonene gjør det de skal, og oppfyller kravene til produktet. All testing gjort av oppdragsgiver har vært av typen black box. 5.4 Testing av første prototype Testingen av første prototype foregikk i Wergelandsveien 27 hos oppdragsgiver. Vi benyttet oss av Samsung Galaxy Tab-nettbrettet. 5.4.1 Fremgangsmåte Oppdragsgiver ble gitt nettbrettet med prototypen til applikasjonen lastet inn, og skulle da prøve ut prototypen og evaluere om den oppfylte de kravene som hadde blitt diskutert ved tidligere møter. Oppdragsgiver hadde null innsikt i den bakenforliggende kildekoden til prototypen, så dette er derfor å regne som en black box-test. 5.4.2 Resultater Etter å ha utført testen var oppdragsgiver meget positiv til prototypen, og hadde veldig lite kritikk å komme med. Vi fikk skryt for å ha laget et enkelt no-nonsense brukergrensesnitt, og oppdragsgiver mente at prototypen oppfylte kravene i meget stor grad.

5.5 Testing i utviklingsfasen 5.5.1 Enhetstesting Under utvikling av både Adminnettsted og Android-applikasjon ble enhetstesting utført under implementasjon av krav for å kvalitetssikre koden. Koden ble white box -testet ved at vi lagde forskjellige test cases for de relevante kodesnuttene som skulle testes, og kontrollerte at kodesnuttene ga forventet resultat basert på test casene. 5.5.1.1 Enhetstesting av Android-applikasjon Android-applikasjonen ble enhetstestet ved å designe test cases for de relevante kodesnuttene, og deretter kontrollere oppførsel og resultat ved hjelp av debuggeren i Eclipse IDE. En hendig funksjon som hyppig ble benyttet var Log-funksjonen i Android API-et. Denne funksjonen gjør det mulig å skrive ut verdien til en variabel under kjøring direkte til LogCat-konsollen i Eclipse IDE. På denne måten kunne vi enkelt sjekke at alle variabler i appliksjonen hadde forventede verdier, og dermed sørge for at programlogikken gikk som forventet. 5.5.1.2 Enhetstesting av Adminnettsted For å vise eventuelle feilmeldinger, måtte vi som nevnt tidligere endre utviklingsinstillingene i konfigurasjonsfilen til PHP. Adminnettstedet ble enhetstestet på samme måte som Android-applikasjonen ved å designe test cases for de relevante kodesnuttene. Deretter kontrollerte vi oppførselen og resultatet ved hjelp av feilmeldingene som dukket opp i nettleseren. Etter dette tok vi høyde for disse feilmeldingene i kodingen. De ulike PHP-klassene inneholder funksjoner som reflekterer dette. Dersom det oppstår en feil, blir det kastet en Exception med en egendefinert feilmelding. Alle Exceptions blir lagret i en Array og blir printet ut når feilen oppstår. Brukeren får da beskjed om hva feilen var i nettleseren.

Bilde 5.5.1.2.1: Eksempel på en funksjon som sikrer input. 5.6 Systemtesting Etter et utviklingsfasen for Android-applikasjonen og Adminnettstedet var ferdig, ble det foretatt systemtesting hos oppdragsgiver på Wergelandsveien 27. Testenheten for Android-applikasjonen var Samsung Galaxy Tab-nettbrettet, mens Adminnettstedet ble testet på Lenovo-laptopen til gruppemedlem Vegard. 5.6.1 Systemtesting av Android-applikasjonen Formålet med systemtesting av Android-applikasjonen var å evaluere brukervennligheten til applikasjonen, samt evaluere i hvor stor grad applikasjonen oppfylte kravene som oppdragsgiver hadde satt under tidligere møter.

5.6.1.1 Fremgangsmåte Oppdragsgiver hadde samlet et utvalg av studenter fra Institutt for atferdsvitenskap på HiOA, som skulle prøve ut applikasjonen på nettbrettet. Før hver test ble applikasjonens lokale data slettet, så hver gang den ble kjørt fikk testeren oppleve applikasjonen under såkalt first run -tilstand der spørsmål lastes ned automatisk. For hver test ble studenten gitt nettbrettet og bedt om å starte applikasjonen, uten noen ytterligere instruksjoner. Deretter skulle studenten klare å starte en ny økt og kjøre økten, uten noen hjelp eller veiledning fra vår side. Vi skulle observere hvordan studenten taklet oppgaven, om hun/han hadde noen problemer underveis, og hvor lett det var å utføre oppgaven. Dette var for å evaluere brukervennligheten til applikasjonen. Etter hver test ble studenten stilt diverse spørsmål om applikasjonens brukervennlighet. I tillegg skulle også oppdragsgiver prøvekjøre applikasjonen, for å evaluere om den oppfylte kravene som var blitt satt. 5.6.1.2 Resultater Alle studentene klarte på egenhånd å starte en ny økt og kjøre gjennom denne økten, helt uten hjelp. Når de ble stilt spørsmål om applikasjonens brukervennlighet, uttrykte alle studentene at de mente at den var meget enkel å bruke. En student bemerket at han syntes skriften var noe liten, men alle var positive til applikasjonens brukervennlighet. Under vår observasjon av testene, merket vi at noen studenter hadde litt problemer med en meny i applikasjonen. Problemet gjaldt spørsmålsmenyen, der flere spørsmål må markeres i en liste og ny økt startes ved å trykke på Start ny økt. Noen brukte litt lang tid på å skjønne at de måtte markere flere objekter i listen for å starte en ny økt. Til tross for at noen brukte lengre tid, klarte alle å komme gjennom menyene på egen hånd, og ingen uttrykte at de hadde problemer.

Bilde 5.6.1.2.1: Menyen som noen hadde litt problemer med skjønne. Oppdragsgiver fikk også teste applikasjonen, og gikk gjennom absolutt alle funksjoner. Han uttrykte at applikasjonen oppfylte kravene som hadde blitt diskutert, og hadde veldig lyst til å ta den i bruk ved fakultet for helsefag til høsten. 5.6.2 Systemtesting av Adminnettstedet Hensikten med systemtestingen av Adminnettstedet var i likhet med testingen av Android-applikasjonen å sjekke nettstedets brukervennlighet, samt å finne ut i hvilken grad det oppfylte oppdragsgivers krav. 5.6.2.1 Fremgangsmåte Da det kun er faglærere som skal bruke nettstedet, ble testingen utført av oppdragsgiver. Oppdragsgiver logget seg inn på nettstedet og testet de ulike funksjonene uten hjelp fra vår side. Dersom noe var uklart forklarte vi funksjonene. Deretter stilte vi noen spørsmål om brukervennlighet og responsivitet, og om det ellers var noen annen kritikk av nettstedet.

5.6.2.2 Resultater Oppdragsgiver kom seg fort inn i gangen i systemet. De fleste funksjoner fungerte slik de skulle bortsett fra noen få unntak. Det oppstod en feil når man skulle velge hvilket svar som var riktig, og plusstegn kom ikke med under opprettelse av spørsmål. Når man lagde navn på fag og kategori kom ikke tall med i navnet. Dette var egentlig ikke en feil, men var fordi filterfunksjonen ikke var satt til å tillate tall. Vi tenkte ikke over at fagnavn som regel inneholder tall. Filterfunksjonen ble fikset på stedet. Alt i alt var oppdragsgiver fornøyd med nettstedet. Han syntes det var enkelt å bruke, responderte raskt og var godt lesbart. Utseendemessig beskrev han det som rent og ryddig, uten mye dall. Det eneste han ville endre på var måten man valgte riktig svar på. Istedenfor å ha radiobuttons som bestemmer hvilket svar som er riktig, ville han gjøre så det første svarfeltet alltid er riktig. Denne endringen ble innført senere på dagen etter at testingen var ferdig. 5.7 Stresstesting av server Etter systemtesting hos oppdragsgiver ble serveren for databasen og Adminnettsted stresstestet. Serveren kjørte Apache på en Ubuntu virtuell maskin, så programverktøyet ApacheBench ble benyttet. Formålet med stresstesting er å måle ytelsen til serveren, og se hvor mange brukere den takler. 6 Ytelsen til Adminnettstedet og PHP-servicene som applikasjonen kobler seg til, ble målt separat, da disse kommer til å ha forskjellig antall brukere. 5.7.1 Fremgangsmåte 6 Ytelsen for den virtuelle maskinen vil variere med trafikken på høyskolens servere, disse testene er bare ment for å gi en generell pekepinn på hvor mange brukere den takler.

Stresstestingen fokuserer på hvor mange samtidige (concurrent) brukere serveren klarer å takle. For å kunne måle dette måtte vi finne ut hvor mange HTTP requests Adminnettstedet og PHP-servicene trengte for å lastes ned. Til dette formålet benyttet vi nettleseren Mozilla Firefox med Firebug add-on. Vi fant ut at Adminnettstedet trenger mellom 1-3 requests, mens PHP-servicene trengte bare 1. Dermed anslo vi at for Adminnettstedet er 1 bruker lik 3 requests, mens for PHP-servicene er 1 bruker lik 1 request. Med disse tallene målte vi hvor mange samtidige brukere serveren takler med ApacheBench. Bilde 5.7.1.1: Skjermbilde fra ApacheBench. 5.7.2 Resultater 5.7.2.1 Resultater for PHP-servicer: Antall brukere 30 50 100 130 140 Antall requests 30 50 100 130 140 Total tid brukt 0,055 sekunder 0,059 sekunder 0,11 sekunder 0,19 sekunder 1,979 sekunder Lengste request 55 ms 57 ms 107 ms 183 ms 1975 ms Evaluering OK OK OK OK Treg

200 350 570 600 200 350 570 600 4,285 sekunder 10,605 sekunder 12,489 sekunder - 4277 ms 10602 ms 12485 ms - Treg Treg Treg Gikk ikke Som man ser i tabellen, gir serveren lav responstid opp mot 130 samtidige brukere, over dette går responstiden kraftig opp. Opp mot 570 brukere får responstiden en jevn stigning, og med 600 samtidige brukere klarer den ikke svare. Utifra disse tallene anslår vi at fakultet for helsefag kan benytte PHP-servicene på serveren uten å oppleve noe nevneverdig treghet. Vi ser på det som usannsynlig at fakultetet kommer til å få over 130 brukere til å laste ned spørsmål på nøyaktig samme tidspunkt. 5.7.2.2 Resultater for Adminnettsted: Antall brukere 10 30 43 50 100 190 200 Antall requests 30 90 130 150 300 570 600 Total tid brukt 0,02 sekunder 0,049 sekunder 0,06 sekunder 1,636 sekunder 3,799 sekunder 5,399 sekunder - Lengste request 19 ms 45 ms 53 ms 1628 ms 3787 ms 5390 ms - Evaluering OK OK OK Treg Treg Treg Gikk ikke Utifra tallene så vil Adminnettstedet kunne tjene opptil 43 brukere samtidig uten treghet. Fra 50 til 190 brukere blir nettstedet merkbart tregere, og ved 200 samtidige brukere svarer den ikke. Nå skal disse tallene tas med en klype salt, vi har tatt utgangspunkt i at 1 bruker = 3 requests, men i virkeligheten varierer antallet requests en bruker trenger mellom 1-3. Forholdene som stresstesten simulerer er et worst case -scenario, der alle brukere trenger 3 requests og alle requests er samtidige.

5.8 Konklusjon Denne testrapporten gir en oversikt over hvordan testingen i dette prosjektet har blitt gjennomført. Dette omfatter blant annet enhetstesting under utviklingsfasen, testing av første prototype og systemtesting hos oppdragsgiver, samt stresstest av server. Enhetstestingen under utviklingsfasen har hjulpet oss med å kvalitetssikre koden vår, og sørge for at produktene kjører stabilt uten å kræsje. Protoypetest og systemtest hos oppdragsgiver har hjulpet oss med å evaluere brukervennligheten til produktenen, samt evaluere i hvilken grad produktene oppfyller kravene vi ble enige om. Stresstest av server ga en pekepinn på hvor stort kapasitet den virtuelle Ubuntu-maskinen på HiOAs servere hadde. Dette var veldig nyttig for å kunne vurdere hvor mange brukere som kan benytte seg av Adminnettstedet og laste ned spørsmål til app via PHP-services.

6 Kravspesifikasjon 6.1 Presentasjon Tittel Precision Teaching App for Android Oppgave Å lage en Android app som skal benyttes av studenter for å øve på fagpensum. Appen skal ta i bruk prinsipper fra Precision Teaching, der brukeren blir utfordret av en rekke multiple choice-spørsmål med tidsbegrensning. Score og progresjon for hver økt skal lagres, så brukeren blir motivert til forbedring. Gruppemedlemmer Ole Aarnseth, s180482 Vegard Krusedokken, s164830 Prosjektgruppe Gruppe 39 Veileder Kirsten Ribu Kirsten.Ribu@hioa.no Tlf.: 41648686 Oppdragsgiver Børge Strømgren Institutt for Adferdsvitenskap Fakultet for Helsefag på HiOA borge.stromgren@hioa.no Torunn Lian Institutt for Adferdsvitenskap Fakultet for Helsefag på HiOA torunn.lian@hioa.no

6.2 Kort systembeskrivelse Systemet består av en Android-applikasjon som kjøres lokalt på smarttelefoner og nettbrett. I tillegg har systemet en ekstern MySQL-database, som befinner seg på en virtuell Ubuntu-maskin hos Høyskolen i Oslo og Akershus. Ved å ta i bruk prinsipper fra Precision Teaching, kan applikasjonen benyttes til å forbedre mestring og kompentanse innenfor forskjellige fagområder. Studenten utfordres av multiple choice-spørsmål med tidsavgrensning. Disse spørsmålene blir hentet fra MySQL-serveren, og lagres deretter lokalt på telefonen/nettbrett. I første omgang vil den bli tatt i bruk av studenter ved fakultet for helsefag ved HiOA, for å trene på legemiddelregning.

6.3 Funksjonelle krav 6.3.1 Krav til Android-applikasjon 6.3.1.1 Krav til økter Bruker utfordres av treningsøkter, med multiple choice spørsmål. Svaralternativene stokkes om hver gang et spørsmål vises. Bruker kan velge tidsfrist på økt. Hver treningsøkt inneholder flere spørsmål enn det brukeren rekker å svare på innenfor tidsfristen. Før en økt begynner må bruker angi et individuelt brukernavn, som identifiserer brukeren. Applikasjonen viser etter hver økt hvor mange riktige og hvor mange feil bruker hadde. Bruker har mulighet til å se hva som var feil, etter endt økt. Hver treningsøkt er tidsavgrenset. Applikasjonen har støtte for både norsk og engelsk språk. 6.3.1.2 Krav til score Scorer for hver økt lagres under et individuelt brukernavn for hver bruker av appen. Frekvens for antall riktige og antall feil delt på tid for hver økt, lagres lokalt under brukernavnet. Rådataene for frekvens for alle økter gjennomført i løpet av en dag, kan sendes til evt. faglærere. 6.3.1.3 Krav til spørsmål Applikasjonen kan hente spørsmål fra en ekstern database, og lagre disse lokalt. Applikasjonen kan sjekke om databasen har blitt endret, og oppdatere de lokale spørsmålene deretter. Bruker kan velge i en liste hvilke spørsmål som skal trenes på i økten. Etter endt økt kan bruker kunne velge om hun/han vil øve på de samme spørsmålene eller en annen kategori. Hvert spørsmål består av tekst. Hvert spørsmål kan ha opptil fire svaralternativer. Spørsmål skal fordeles på kategorier som igjen fordeles på fag.

6.3.2 Krav til Database og Adminnettsted Faglærere har tilgang til Adminnettstedet. Faglærere kan autentisere seg for nettstedet med brukerkontoer (som består av epost og passord). Faglærere kan opprette/endre/slette spørsmål, fag og kategorier i Adminnettstedets database. Spørsmålene kan lagres i en database. Databaseserveren kan gjøre spørsmålene tilgjengelig for Android applikasjonen. 6.4 Ikke-funksjonelle krav 6.3.1 Android-applikasjon Grensesnittet skal være tilpasset for svaksynte og fargeblinde. Applikasjonen skal reagere kjapt på tastetrykk, så det ikke oppfattes som tregt. 6.5 Tekniske krav Applikasjonen skal utvikles for Androidplattfomen, og minimumsversjonen for å kjøre applikasjonen skal være Android 2.2 (API 8). Applikasjonen skal kodes i Java Runtime Environment 1.6. Applikasjonen skal utvikles i Eclipse IDE med ADT Bundle. Adminnettstedet skal utvikles i HTML, CSS, PHP og Javascript. Gedit skal brukes til å skrive kildekoden til Adminnettstedet. JSON skal brukes for å overføre data fra Adminnettsted til applikasjonen. Serveren for Adminnettstedet skal kjøre en LAMP stack som skal bestå av Ubuntu Linux, Apache HTTP Server, MySQL og PHP. 6.6 Øvrige ønsker Studenter skal kunne legge inn egne spørsmål, og kunne kjøre treningsøkter med disse i tillegg til spørsmål fra faglærere. Faglærere skal kunne legge inn bilder i tillegg til skriftlige spørsmål.

6.8 Krav til dokumentasjon 6.8.1 Styringsdokumentasjon Prosjektskisse Prosjektdagbok Forprosjektrapport Arbeidsplan og fremdriftsplan Kravspesifikasjon (overordnet) 6.8.2 Sluttdokumentasjon Prosessdokumentasjon Kravspesifikasjon (endelig) Produktdokumentasjon Testdokumentasjon Brukerveiledning 6.9 Risikoanalyse Risiko Sannsynlighet Sykdom eller skade. Middels Konsekvens Lav, ved kortvarig sykdom. Høy, ved langvarig sykdom Dårlig samarbeid. Lav Alvorlig Manglende motivasjon. Middels Middels Tiltak Jevn arbeidsfordeling, lett tilgjengelighet av all dokumentasjon og kildekode. Jevnlige møter og tett kommunikasjon. Oppmuntre hverandre, pauser ved utbrenning, hjelpe hverandre hvis noen står fast.

Tekniske problemer. Middels Alvorlig Mangel på tid. Middels Middels Backup av alt materiale på minnepenn og i nettskyen. Nøye planlegging og effektiv jobbing. 7 Brukerveiledning Dette er en brukerveiledning for Android-applikasjonen og Adminnettstedet. Brukerveiledningen tar for seg hvordan man kan bruke disse produktene steg for steg med forklarende tekst og bilder. 7.1 Innledning Android-applikasjonen er en lære-app ment for å hjelpe studenter med å trene på fagstoff. Appen bruker læringsprinsipper fra Precision Teaching, og utfordrer brukeren med økter der bruker må besvare en rekke multiple choice-spørsmål innenfor en tidsfrist. Appen henter spørsmålene fra en database, som administreres fra at nettsted vi har valgt å kalle Adminnettstedet. Dette nettstedet gjør det mulig for faglærere å administrere spørsmålene som brukes i appen. I denne brukerveiledningen vil vi ta for oss bruk av både Android-applikasjon og Adminnettsted.

7.2 Brukerveiledning for Android-appen Android-applikasjonen er en lære app som benytter læringsprinsipper fra Precision teaching, og er ment for å hjelpe studenter med å trene på fagstoff som kan være utfordrende og stiller høy krav til mestring. Nedenfor følger en brukerveiledning for Android-applikasjonen. 7.2.1 Installeringsinstruksjoner For å installere appen må du tillate installasjon av ikke-markedsprogrammer: 1. På Android-enheten din, gå til Innstillinger. 2. Velg Programmer. 3. Huk av for "Tillat installering av ikke-markedsprogrammer". NB! Vi har ikke rukket på dette tidspunktet å tilpasse grensesnittet til appen for smarttelefoner, så appen bør kjøres på et Android-nettbrett (10 tommer). 1. Koble Android-enheten din til en PC med USB-kabel. 2. Kopier filen "PrecisionTeaching.apk" over til Android-enheten. 3. På Android-enheten, gå til filutforskeren (Mine filer) og finn det stedet du la filen. 4. Trykk på filen, og velg "Bekreft og installer", og trykk Installer. 5. Appen kan startes ved å trykke på "Precision Teaching"-ikonet i Programmer-menyen.

Bilde 7.2.1.1: Precision Teaching-ikonet. 7.2.2 Første oppstart Første gang du starter opp applikasjonen vil den automatisk koble seg til databaseserveren og laste ned spørsmål. Hvis Android-enheten ikke er tilkoblet internett, vennligst koble til internett og prøv igjen. Bilde 7.2.2.1: Appen vil automatisk laste ned spørsmål ved første oppstart. Når spørsmålene er lastet ned, vil du komme til hovedmenyen for appen.

7.2.3 Hovedmeny Bilde 7.2.3.1: Appens hovedmeny. Appens hovedmeny inneholder følgende valg:

Ny økt: Start en ny Precision Teaching-økt. Hurtigøkt: Gå til Hurtigøkt-funksjonen, kun tilgjengelig hvis tidligere økter er lagret. Sjekk High Score: Sjekk highscores for alle økter som er kjørt. Innstillinger: Gå til Innstillinger for appen. 7.2.4 Ny økt Du kan starte en ny Precision Teaching-økt ved å velge Ny økt i hovedmenyen. Hvis du ikke har valgt Kurs eller Kategori, vil appen be deg om å velge dette. Bilde 7.2.4.1: Før ny økt kan startes vil appen be deg om å velge kurs og kategori.

7.2.4.1 Velg tid Når du har valgt kurs og kategori, eller hvis dette tidligere er valgt, vil du komme til tidsvalg-menyen. Her velger du ønsket varighet for økten din. Du kan velge fra 10 sekunder og opptil 1 minutt. Etter å ha valgt tid vil du komme til brukervalg-menyen: 7.2.4.2 Brukervalg Bilde 7.2.4.2.1: Brukervalg-skjermen. I brukervalg-menyen kan du velge en bruker for økten din, eller lage en ny bruker ved å trykke Lag ny bruker. Alle high scorene du oppnår vil bli registrert under brukeren du velger.

Etter å ha valgt bruker for økten vil du komme til spørsmålsvalg-menyen. 7.2.4.3 Spørsmålsvalg

Bilde 7.2.4.3.1: Spørsmålsvalg-skjermen. I spørsmålsvalg-menyen kan du velge hvilke spørsmål du ønsker å trene på i økten din. Du må velge minst 2 spørsmål for å kunne starte økten. Du kan også endre kurs eller kategori med knappene Velg kurs og Velg kategori. Når du har valgt spørsmålene dine trykker du Start ny økt for å kjøre økten. 7.2.5 Kjøring av en økt Bilde 7.2.5.1: Øktskjermen.

Under en økt vil du bli utfordret til å besvare så mange av spørsmålene som mulig før tiden renner ut. Spørsmål besvares ved å trykke på svaret du tror er riktig. Når et spørsmål besvares vil neste spørsmål vises. Hvilket spørsmål som er neste er helt tilfeldig. For hver gang et spørsmål vises i en økt, vil svarene stokkes om. Når tiden er over, vil du få opp Øktslutt-dialogvinduet. 7.2.5.1 Øktslutt-dialogvindu Bilde 7.2.5.1.1: Øktsluttvinduet, til høyre med Vis riktig svar-knapp, til venstre uten. I øktslutt-vinduet kan du se scoren din for gjeldede økt. Trykk Ny runde for å kjøre en ny økt med samme spørsmål, eller Hovedmeny for å gå tilbake til hovedmenyen for appen. Noen ganger vi du også få opp en knapp som heter Vis riktige svar, trykk på denne for å gå til riktige svar-skjermen.

7.2.5.2 Riktige svar

Bilde 7.2.5.2.1: Riktige svar-skjerm. I skjermen for riktige svar vises alle besvarte spørsmål i en liste, der svaret som ble valgt vises i den blå boksen, mens riktig svar vises i den grønne. Trykk Ny runde for a starte en ny økt med samme spørsmål, eller Hovedmeny for å gå til hovedmenyen. 7.2.6 Hurtigøkt

Bilde 7.2.6.1: Hurtigøkt-skjerm. Velger du Hurtigøkt i hovedmenyen kommer du til hurtigøkt-skjermen vist ovenfor. Her kan du velge en av de 10 siste øktene du spilte. Når du velger en økt, vil du komme til brukervalg-menyen. Etter å ha valgt bruker, vil økten begynne. NB! Når du laster ned nye spørsmål fra databaseserveren, vil alle dine lagrede økter her slettes. 7.2.7 Sjekk High Score

Bilde 7.2.7.1: High Score-skjerm. Velger du Sjekk High Score i hovedmenyen vil du komme til brukervalgmenyen. Velg brukeren du vil sjekke high score for, og du vil komme til high score skjermen, vist ovenfor. Denne skjermen rangerer alle scorer du har oppnådd etter antall riktige. Trykk Eksporter scorer til epost for å gå til eksporter til epost-funksjonen. 7.2.7.1 Eksporter scorer til epost

Bilde 7.2.7.1.1: Eksporter til epost-skjerm. Her kan du eksportere alle scorene som er registrert for en dato til en tekstfil, og legge den til som et vedlegg i epost. Velg datoen du vil eksportere, så vil alle scorene dine for den datoen skrives til en tekstfil, og epostklienten til Android-enheten åpnes med tekstfilen som vedlegg. 7.2.8 Innstillinger

Bilde 7.2.8.1: Innstillenger-menyen. Velger du Innstillinger i hovedmenyen kommer du til Innstillinger-menyen. Her kan du gjøre følgende ting: Last ned nye spørsmål: Trykker du denne knappen vil appen sjekke databaseserveren om nye spørsmål er tilgjengelige. Hvis det fins nye spørsmål, vil du bli spurt om du ønsker å laste ned de nye spørsmålene. NB! Dette vil slette alle lagrede økter i Hurtigøkt-funksjonen. Velg kurs og Velg kategori: Trykk på disse knappene for å velge kurs og kategori for økter. Slett bruker: Trykk her for å slette en bruker. Du vil komme til en brukervalg-meny, der du velger brukeren du ønsker å slette. NB! Sletter du en bruker vil alle scorer lagret på brukeren også slettes. Sett database URL adresse: Her kan du sette URL-adressen til databaseserveren som spørsmål hentes fra. Når du skriver inn adressen og trykker Ok vil appen sjekke om den får kontakt med databaseserveren på adressen, hvis den får kontakt vil adressen lagres. Default-adresse er hp2.vlab.cs.hioa.no, trykk Bruk default for å bruke den.

7.3 Brukerveiledning for Adminnettsted Adminnettstedets oppgave å gi faglærere et verktøy for å kunne administrere innholdet i "Precision Teaching"-appen. Under følger en veiledning for hvordan man kan bruke nettstedet. 7.3.1 Innlogging Bilde 7.3.1.1: Innlogging-skjerm. For å logge seg inn må man skrive inn epost og passord. Eposten for admin er admin@admin.no med passord Kaffetrakter1986. Dersom det oppstår en feil vil man få beskjed om dette.

7.3.2 Meny Bilde 7.3.2.1: Meny-skjerm. Etter at faglærer har logget seg inn vil det dukke opp en meny på venstre side. Denne menyen er inndelt i Fag, Kategori, Spørsmål og Ny admin. Disse er igjen inndelt i nye lenker for å lage, slette, endre eller vise, bortsett fra Ny admin som kun kan opprette nye brukerkontoer for nettstedet. Det er også lagt til flere lenker rundt omkring på nettstedet for å skape redundans og gjøre det lettere å navigere. 7.3.3 Ny admin Bilde 7.3.3.1: Ny admin-skjerm

For å opprette en ny brukerkonto for en faglærer trykker man på lenken "Ny admin". Deretter skriver man inn sin epostadresse og ønsket passord. Til slutt får man beskjed om operasjonen var vellykket eller ikke. 7.3.4 Fagmeny Bilde 7.3.4.1: Fagmeny. Denne menyen inneholder seks lenker. De fire første lenkene er "Nytt fag", "Slette fag", "Endre fag" og "Vis fag". De to siste lenkene er "Kategori" og "Spørsmål" som linker til menyene for kategori og spørsmål.

7.3.5 Nytt fag Bilde 7.3.5.1: Nytt fag-skjerm. For å opprette et fag klikker man på lenken "Nytt fag". Deretter skriver man inn det ønskede navnet på faget, og trykker på knappen "Lagre fag". Etter dette gis det beskjed om at faget er blitt lagt til i databasen. Dersom det skulle oppstå en feil vil man få informasjon om dette. 7.3.6 Slette fag

Bilde 7.3.6.1: Slett fag-skjerm. Ved sletting av fag, trykk på lenken "Slett fag". Da vil det dukke opp en liste over tilgjengelige fag som faglæreren selv har lagt inn. Hvert fag har en lenke ved siden av seg som det står "slett" på. Dersom denne lenken blir trykket på, får man opp et dialogvindu hvor man bekrefter at man virkelig vil slette faget. Når faget blir slettet vil alle tilhørende kategorier og spørsmål også bli fjernet. Lista over fagene blir så oppdatert. 7.3.7 Endre fag

Bilde 7.3.7.1: Endre fag-skjerm. Trykk på lenken "Endre fag" for å endre navn på fag. Velg deretter hvilket fag som skal endres, skriv inn det nye navnet og trykk på knappen "Endre fag". Til slutt får man beskjed om operasjonen var vellykket eller ikke.

7.3.8 Vise fag Bilde 7.3.8.1: Vise fag-skjerm. For å se hvilke fag man har lagt inn i databasen, trykk på lenken "Vis fag". Da dukker det opp en liste over disse fagene. 7.3.9 Kategorimeny Bilde 7.3.9.1: Kategorimeny. Denne menyen inneholder seks lenker. De fire første er "Ny kategori", "Endre kategori", "Slette kategori" og "Vis kategori". De resterende to linker til fagmenyen og spørsmålsmenyen.

7.3.10 Ny kategori Bilde 7.3.10.1: Ny kategori-skjerm. Trykk på lenken "Ny kategori" for å lage en ny kategori. Velg deretter hvilket fag kategorien skal tilhøre, og skriv inn navnet på kategorien. Etter dette får man beskjed om kategorien ble lagret eller ikke. 7.3.11 Slette kategori Bilde 7.3.11.1: Slette kategori-skjerm. For å slette en kategori må man først trykke på lenken Slette kategori. Velg deretter et fag fra drop down -lista for å få oversikt over hvilke kategorier som tilhører det valgte faget. Trykk til slutt på lenken Slett for å slette kategorien.

7.3.12 Endre Kategori Bilde 7.3.12.1: Endre kategori-skjerm. Trykk på lenken Endre kategori. Velg deretter fag og hvilken kategori du vil endre navn på. Skriv etter dette inn det nye navnet på kategorien og trykk på knappen Lagre kategori. 7.3.13 Vise kategori Bilde 7.3.13.1: Vise kategori-skjerm.

Trykk på lenken "Vis kategori". Velg deretter fag fra "drop down"-lista for å vise tilhørende kategorier. Det vises også en oversikt over hvilke kategorier som er klare for nedlastning. 7.3.14 Spørsmålsmeny Bilde 7.3.14.1: Spørsmålsmeny. Spørsmålsmenyen inneholder seks lenker. Disse lenkene er "Nytt spørsmål", "Slette spørsmål", "Endre spørsmål" og "Vis spørsmål", samt lenkene "Fag" og "Kategori". De to sistnevnte lenkene linker til fagmenyen og kategorimenyen.

7.3.15 Nytt spørsmål Bilde 7.3.15.1: Nytt spørsmål-skjerm. For å lage et nytt spørsmål må man trykke på lenken "Nytt spørsmål". Deretter velger man fag og kategori fra "drop down"-listene. Hvis det ønskede faget eller kategorien ikke eksisterer, kan man trykke på knappene "Nytt fag" eller "Ny kategori". Da havner man på sidene for å opprette disse. Under knappene er det et tekstfelt som brukes til å skrive inn spørsmål. Her står det også informasjon om hvordan man oppretter et spørsmål. Etter å ha skrevet spørsmålet, må man skrive inn svar. Det må være minst to svar. Det første svaret man skriver inn vil bli det riktige svaret. De andre svarene vil bli feil. Trykk til slutt på knappen "Lagre spørsmål" for å opprette spørsmålet og svarene. Man får beskjed om alt gikk riktig for seg eller om det oppstod en feil. Ved siden av knappen "Lagre spørsmål" er knappen "Kategori ferdig". Denne knappen brukes når man vil gjøre klar kategorier og deres tilhørende spørsmål for nedlastning til appen. Da dukker det opp et dialogvindu hvor man bekrefter dette. Dersom kategorien allerede er klargjort får man beskjed om dette.

7.3.16 Slette spørsmål Bilde 7.3.16.1: Slette spørsmål-skjerm. Trykk på lenken "Slette spørsmål". Velg etter dette fag og kategori fra "drop down"-listene. Det vil da dukke opp en liste over alle spørsmål som tilhører den valgte kategorien. Ved siden av hvert spørsmål finnes det en ny lenke kalt "Slett". Dersom man trykker på denne lenken vil det komme fram et dialogvindu hvor man må bekrefte at man vil slette spørsmålet. Det blir gitt beskjed om spørsmålet ble slettet.

7.3.17 Endre spørsmål Bilde 7.3.17.1: Endre spørsmål-skjerm. Ved endring av spørsmål, trykk på lenken "Endre spørsmål". Velg deretter fag og tilhørende kategori, samt hvilket spørsmål som skal endres på. Skriv så inn det nye spørsmålet og trykk på knappen "Endre spørsmål". Når dette er gjort får man beskjed om spørsmålet ble endret eller om det oppstod en feil. 7.3.18 Vise spørsmål og svar

Bilde 7.3.18.1: Vis spørsmål og svar-skjerm. For å vise spørsmål trykk på lenken "Vis spørsmål". Velg deretter fag, kategori og det spørsmålet som skal vises. Etter at spørsmålet er valgt blir det vist fram sammen med de tilhørende svarene. Det vil også bli vist hvilke av svarene som er riktig. 8 Kilder Stackoverflow http://stackoverflow.com/ Wikipedia www.wikipedia.org Youtube www.youtube.com PHP www.php.net

W3Schools www.w3schools.com MySQL http://dev.mysql.com Android http://developer.android.com JSON http://www.json.org/ Precision Teaching http://psych.athabascau.ca/html/387/openmodules/lindsley/introa.shtml