Hovedprosjekt - Bachelorstudium i Ingeniørfag Anvendt Datateknologi

Transkript

1 Hovedprosjekt - Bachelorstudium i Ingeniørfag Anvendt Datateknologi Gruppe 18: Bilal Ahmad Marit Berntsen Tamas Czipri Jardar L. Haugland Benedicte Paulsen S S S S S180347

2 Studieprogram: Anvendt datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo PROSJEKT NR TILGJENGELIGHET Åpen HOVEDPROSJEKT Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL BassengWeb NIH DATO ANTALL SIDER / BILAG 212 / 4 PROSJEKTDELTAKERE Bilal Ahmad s Tamas Czipri s Benedicte Paulsen s Marit Oline Bakkerud Berntsen s Jardar Løken Haugland s INTERN VEILEDER Geir Skjevling OPPDRAGSGIVER Norges idrettshøgskole KONTAKTPERSON Hans Olav Krogsæter SAMMENDRAG Prosjektet går ut på å erstatte Norges Idrettshøgskole sin datainnsamling og lagringsmetodikk av målinger gjort i bassenger. Fra et papirbasert - til digitaltbasert system. Prosjektet inneholder også en mikrokontroller, Arduino Yún, denne er med på å utføre automatiske målinger og lagrer disse i databasen uten brukerinteraksjon. 3 STIKKORD Laravel MSSQL Arduino Yún

3 Forord Dette dokumentet er en presentasjon av hovedprosjekt for gruppe 18 ved Høgskolen i Oslo og Akershus, våren Bakgrunn, utførelsen og mål for denne oppgaven, samt gruppen presenteres her i sin helhet. Vårt hovedprosjekt, BassengWeb NIH, gikk ut på å utvikle en webapplikasjon som skal benyttes av Norges idrettshøgskole. Applikasjonen er utviklet for å kunne loggføre relevant data for deres bassenganlegg, og det er også integrert et system for å automatisere målinger. Sluttdokumentasjonen består av prosessdokumentasjon, produktdokumentasjon, testdokumentasjon og brukerveiledningen. Disse skildrer forskjellige aspekter ved oppgaven. Produktdokumentasjonen og brukerveiledningen vil kunne være til nytte for fremtidige brukere av systemet. Prosessdokumentasjonen og testdokumentasjonen beskriver hvordan vi har jobbet mot endelig løsning. En stor takk til Geir Skjevling. Geir var veilederen vi fikk tildelt av Høgskolen i Oslo og Akershus, og var tilstede da vi trengte råd til gjennomføring av prosjektet. Han var også til stor hjelp da vi skulle skrive dokumentasjon for prosjektet. Også stor takk til Hans Olav Krogsæter som var vår kontaktperson ved Norges idrettshøgskole. Han hjalp oss i gang, og ga oss muligheten til å jobbe med et veldig spennende prosjekt.

4 Innholdsfortegnelse 1. Prosessdokumentasjon Produktdokumentasjon Testdokumentasjon Brukerveiledning..189

5 Prosessdokumentasjon Prosessdokumentasjon 1

6 Prosessdokumentasjon Forord Prosessdokumentasjonen er et dokument som er beregnet for sensor, NIH (oppdragsgiver) og øvrige parter som skulle ha en interesse av prosjektet. Dokumentasjonen skal beskrive arbeidsmetode, verktøy, nye teknologier som vi har anvendt samt eventuelle utfordringer vi har måttet løse underveis. Altså vil denne dokumentasjonen begrunne hvilke valg som er gjort, hvordan vi har jobbet som gruppe og hvilke problemer som har oppstått i løpet av prosjektarbeidet. Denne dokumentasjonen består av hovedkapitlene: Beskrivelse av BassengWeb og Arduino Yún Planlegging og arbeidsmetode Om utviklingsprosessen Designprosess Kravspesifikasjonen og dens rolle Om resultatet Kildekoden er tilgjengelig her: BassengWeb kan testes ut, (Brukernavn: rootr, Passord: testing) - Denne er tilgjengelig fram til 20.juni : NB: Betegnelsene Arduino og Arduino Yún brukes om hverandre og menes det samme. Målinger i teksten er definert som fanene i BassengWeb: Timemåling, Vannmåling og Oppgaver. Oppgaver er definert som fanene i BassengWeb: Rutiner (Dagvakt, Kveldsvakt, Helgevakt) og Vask med CM. 2

7 Prosessdokumentasjon Innholdsfortegnelse 1. Innledning Bakgrunn for prosjektet Oppdragsgiver Økonomi Gruppen Mål Funksjonelle krav Brukerkrav Systemkrav Krav til Arduino Ikke - funksjonelle krav Tekniske krav Sikkerhetskrav Rammekrav Andre krav Beskrivelse av BassengWeb og Arduino Planlegging og arbeidsmetode Start fasen Dokumentasjon Dokumentasjonsstandard Styringsdokumenter Gruppeside Prosjeklloggldagbok Ansvarsfordeling Arbeidsforhold og samarbeid Kommunikasjon I gruppen Med oppdragsgiver Med veileder Kommunikasjonsverktøy Diagrammer og strukturering Arbeidsplan

8 Prosessdokumentasjon Gantt diagram Risikoplan Styringsverktøy Trello Dropbox Google Docs FiI- og kodedeling Om utviklingsprosessen Teknologier Frontend HTML5. CSS30gJavascript Backend PHP FDPF Laravel Model-view-controller (MVC) Laravel Eloquent Blade Google Chart Arduino Yun Hvorfor Arduino i vårt prosjekt? Hvorfor Arduino Yun? Pris Ansaffeise Lærinasorossesen Arduino IDE r2 BETA Arduino Skisse Lodding og Oppkobling Temperatur skisse Atlas Scientific ph stamp Oppkobling PH skisse Prototyping- og designfase Dokumentasjonsfase Avgjørelser

9 Prosessdokumentasjon 4.9 Testing Sluttfasen/Overlevering Oppsett av server og database Fag lige utfordringer Laravel Fra Fluenttil Eloquent Databasearkitektur Mysq l til MSSQL(SQLSRV) Arduino Yun Designprosess Design Utseende Logo Fargevalg og skrifttype Plassering av innhold Knapper Ikoner Inforrnasjonsarkitektur Organ isering Navigering Navng ivning og labeling ; endre tekst Søk Universell Utform ing WCAG 2.0 og BassengWeb WCAG 2.0; hvilke krav nådde ikke opp Mobilvenn lighet Designet av mobilversjonen Kravsoesifikasionen oa dens rolle Endringer Kravspesifikasjon i samsvar med det ende lig produktet Om resultatet Utbytte for oppdragsgiver Læringsutbytte

10 Prosessdokumentasjon 7.3 Hva kunne ha vært annerledes Fremtidig utvikling Avsluttende del Sluttord Kildehenvisninger Bibliografi Kilder Kilder for rammeverk og verktøy

11 Prosessdokumentasjon 1. Innledning 1.1 Bakgrunn for prosjektet Prosjektet er et hovedprosjekt ved HIOA. Slik det foreligger i dag benytter Norges idrettshøgskole (NIH) seg av penn og papir for å loggføre målingene gjort i deres bassenger. Tatt i betraktning at det er snakk om store mengder data, er dette en tungvint måte å gjøre oppgaven på. Måleverdiene har tidligere blitt ført inn i et IT-system, dette systemet har dessverre sluttet å virke. Det er derfor ønskelig med et nytt system for registrering av de forskjellige verdiene. 1.2 Oppdragsgiver I fjor høst kom vi kom i kontakt med NIH ved at de hadde lagt ut et prosjektforslag på hovedprosjektsiden til HIOA, som vi svarte på. Vi syntes oppgaven hørtes interessant og lærerik ut, og med dette ble NIH kontaktet ang hovedprosjekt. Vi hadde vårt første møte med NIH allerede i september På dette møtet fikk vi introdusert oss som gruppe samt gått igjennom prosjektbeskrivelsen litt mer i detalj. På dette møtet ble vi enige om at vi skulle jobbe for dem i forbindelse med forbindelse med hovedprosjektet vårt. I forbindelse med dette prosjektet har vi gått sammen med Norges Idrettshøgskole om å lage et IT-system. NIH er en høyskole som tilbyr studier innen idrettsvitenskaplige fagfelter. Vi samarbeider med både IKT-avdelingen samt de som drifter bassenganlegget. Hovedansvarlig for prosjektet er Hans Olav Krogsæter. Han er IKT-sjef ved NIH og var vår kontaktperson i forbindelse med hovedprosjektet. Tor Sundby har hovedansvaret for anlegget, og var med dette vår kontaktperson når det kom til utformingen og bruken av systemet. 7

12 Prosessdokumentasjon Økonomi Norges idrettshøyskole ønsket å få laget et system med hjelp av avgangselever ved HIOA som skulle utføre deres hovedprosjekt. På grunn av dette har det ikke blitt satt opp noe budsjett, da vi skulle stille med eget utstyr. Etter hvert som prosjektet har blitt planlagt, ønsket vi å avansere systemet litt ved å tilføre automatisk måling med Arduino Yún. I forbindelse med dette lurte vi på om dette var noe NIH var interessert i, og om vi skulle gå videre og investere i utstyr. NIH har vært veldig interessert i dette, og har betalt for utstyret som trengtes til denne utvidelsen. Det har også vært klart fra vi fikk prosjektet, at dette er et system vi kan gå videre med, og eventuelt selge til andre som driver svømmehall, da det er stor mangel på lignende systemer. NIH vil derfor opprettholde sine interesser, ved at de får fortsette å bruke systemet, samtidig som de ønsker at vi potensielt kan tjene penger på dette, og muligens vedlikeholde det. 1.3 Gruppen Denne gruppen består av fem gruppemedlemmer, vi er: Bilal Ahmad, Tamas Czipri, Jardar Løken Haugland, Marit Berntsen og Benedicte Paulsen. Det var ønskelig for oss å danne hovedprosjektsgruppe sammen, ettersom vi har jobbet godt sammen i tidligere gruppeprosjekter. Vi er alle avgangsstudenter på Anvendt Datateknologi ved Høgskolen i Oslo og Akershus. 1.4 Mål For å ha et godt utgangspunkt i en utviklingsprosess trenger man noen mål å jobbe etter. I dette avsnittet lister vi opp alle kravene til BassengWeb, som til sammen utgjør det overordnede målet om å gjøre NIH fornøyd. Dette inkluderer altså de funksjonelle kravene og de ikke-funksjonelle kravene. Videre har vi også med et avsnitt Andre krav, hvor vi nevner blant annet krav til dokumentasjonen og de andre kravene som ikke hører hjemme under de funksjonelle- og ikke-funksjonelle kravene. 8

13 Prosessdokumentasjon Funksjonelle krav Brukerkrav Brukeren skal kunne: Registrere utførte målinger. Registrere utførte oppgaver. Slette registrerte målinger/oppgaver (admin). Redigere registrerte målinger/oppgaver (admin). Søke etter registrerte målinger/oppgaver. Generere rapporter i PDF eller Excel. Se statistikk i diagrammer. Se en endringslogg for redigerte/slettede registreringer (admin). Opprette, deaktivere, aktivere og redigere brukere. (admin) Systemkrav BassengWeb skal kunne: Be om innloggingsinformasjon ved oppstart av applikasjonen. Håndtere autorisasjon basert på brukertype (user eller admin). Vise statistikk i diagrammer. Generere rapporter i Excel eller PDF. Endringer og slettinger blir lagret i endringslogg. Knytte utførte målinger/oppgaver mot en bruker. Registrere informasjon fra Arduino i databasen. 9

14 Prosessdokumentasjon Krav til Arduino Skal sende målinger mellom bestemte tidsintervaller. Kommunisere med BassengWeb slik at målinger blir lagret i databasen Ikke - funksjonelle krav Tekniske krav Web-applikasjonen sin backend skal utvikles i php5 med rammeverket: Laravel 4. Frontend skal utvikles i javascript, html5 og css3 med rammeverket Twitter Bootstrap. Web-applikasjonen skal være mobilvennelig. Google charts brukes til å visualisere data. Arduino Yún skal utvikles i C/C++. Modellering gjøres med UML - diagrammer i Violet UML Web-applikasjonen skal være kompatibel med alle nettlesere (IE, FF, GC og Opera). Web-applikasjonen skal være satt på oppdragsgiverens Windows-baserte server. Kildekoden blir lastet opp i Github for versjonshåndtering Sikkerhetskrav Brukere får tilgang til funksjonalitet ut i fra brukertypen de innehar. Redigering/sletting av målinger/oppgaver skal kun være mulig av admin. Det skal opprettes en endringslogg for redigerte/slettede målinger/oppgaver. 10

15 Prosessdokumentasjon Rammekrav Systemet skal utvikles slik at videreutvikling og vedlikehold skal være mulig ved en senere anledning. Systemet skal stå klart i drift i løpet av mai måned. Systemet skal kjøres på NIH sin plattform (Windows 7-64-bit og server 2008/12) Andre krav Utvidbart Kapasiteten til systemet skal kunne utvides etter behov. Systemet skal utvikles objektorientert slik at koden og systemet lett kan endres om ønskelig. Koden skal være strukturert slik at man enkelt kan forbedre spesifikke komponenter i systemet og foreta små inngrep. Testbart Hele systemet skal være testbart Det skal være mulig å teste en enkelt komponent av systemet for seg selv. Test-løsningen skal gi fornuftige tilbakemeldinger ved alle problemer som er kritiske for systemet (exceptions). Robust Systemet skal håndtere feilaktig input. o Ved ugyldig input skal det vises en forståelig tilbakemelding. o Feilaktig input skal på ingen måte kunne krasje systemet. o Kun admin har tilgang til redigering og sletting av målinger/oppgaver. 11

16 Prosessdokumentasjon Universell utforming Vi utvikler applikasjonen mot WCAG 2.0 retningslinjen, og skal godkjenne systemet som nivå AA av denne. Krav til dokumentasjon Systemet skal være dokumentert hensiktsmessig. Dokumentasjonen skal være presis og detaljert. Dokumentasjonen skal ikke inneholde unødvendige repetisjoner. Dokumentasjonen skal være saklig og objektiv. Dokumentasjonen følger UML-standard, men tilpasses hensiktsmessig. Dokumentasjonen utarbeides etter Hioa s standard retningslinjer for dokumentasjon. Systemets kode skal ha forklarende kommentarer for all funksjonalitet. For oss har det vært ønskelig å utvikle et best mulig system for NIH, dette har altså vært det overordnede målet til oss som gruppe. Kravene som kommer frem i dette avsnittet har til sammen utgjort vårt mål om å lage et prima BassengWeb. Gjennom samarbeidet dette semesteret har vi har jobbet hardt for å tilfredsstille disse kravene på en best mulig måte. 12

17 Prosessdokumentasjon 2. Beskrivelse av BassengWeb og Arduino BassengWeb er en web-applikasjon hvor backend er utviklet i PHP-rammeverket Laravel 4. I tillegg tilbys det funksjonalitet hentet fra open-source kilder som for eksempel Google Charts for visualisering av data. I frontend er rammeverket Twitter Bootstrap tatt i bruk i kombinasjon med Blade syntaksen til Laravel for å sikre ett robust design som ikke bare ser bra ut, men også er funksjonell. Hovedmålet med BassengWeb er å gjøre hverdagen til de ansatte på NIH enklere når det gjelder å lagre målinger og oppgaver, applikasjonen skal erstatte dagens papirbaserte løsning. Dette gjør det enklere å aggregere data og hente det ut over tid. Arduino Yún er en mikrokontroller som er koblet opp mot en temperatursensor, og som automatiserer prosessen med å utføre og lagre målinger i MSSQL-databasen. Den er programmert i C/C++ og består av to kjerner ATmega og Linino, disse kjernene kommuniserer med hverandre ved hjelp bridge biblioteket. Mikrokontrolleren sender en HTTP Request med verdier i URL til web-serveren som lagrer disse verdiene i databasen. 13

18 Prosessdokumentasjon 3. Planlegging og arbeidsmetode Som gruppe har vi tidligere erfart at vi jobber forskjellig i forbindelse med prosjekter. For å ta hensyn til dette var det ønskelig å forholde oss til hverandre på en dynamisk måte. Altså at vi hele tiden er i dialog, både med gruppemøter og via andre kommunikasjonsmedier. Ved hjelp av digitale kommunikasjonsverktøy var dette en fungerende måte for oss å jobbe på som gruppe. I denne delen av dokumentasjonen skal vi beskrive planleggingen av prosjektet. Videre skal vi beskrive samarbeidet mellom gruppemedlemmene, hva vi måtte sette oss inn i, metodikk samt verktøy og teknologier vi benyttet underveis. 3.1 Start fasen Som nevnt tidligere i oppgaven startet prosjektet med at vi hadde et møte med IKT-ansvarlige, Hans Olav Krogsæter, på NIH i september Der gikk vi igjennom prosjektforslaget og ble enige om at vi skulle lage et system for dem i forbindelse med vårt hovedprosjekt. Vi i gruppa hadde allerede før møtet blitt enige om at oppgaven passet godt for oss, og at vi skulle takke ja dersom vi fikk tilbudet. For å best mulig imøtekomme kravene IKT-avdelingen hos NIH hadde lyst ut i sin prosjektbeskrivelse, var det behov for kompetanse på flere områder. Deriblant om programmering, databaser, systemutvikling, visualisering og menneske - og maskininteraksjon. Vi syntes dette prosjektet ga muligheter for å anvende mye av det vi hadde lært i løpet av studietiden, samtidig som vi kunne sette oss inn i nye teknologier for å løse oppgaven best mulig. Som vi har vært inne på tidligere har alle gruppemedlemmene samarbeidet i tidligere prosjekter i vår tid på HIOA. Dette har vært tilsynelatende vellykket, derfor var det naturlig for oss å fortsette dette samarbeidet i hovedprosjektet. En av fordelene med dette er at vi kjente vi hverandres vaner godt noe som medførte at planleggingen gikk greit for seg. 14

19 Prosessdokumentasjon 3.2 Dokumentasjon For å holde orden på hva som skal gjøres og produseres trenger man dokumentasjon av forskjellige sort. Og etter hvert som idéene blir mange og tankene store, trenger man overordnede planer. Det er akkurat dette vi skal ta for oss i følgende kapittel. Formålet med dokumentasjon er å gjøre et system enklest mulig både hva gjelder bruk og forståelse for brukeren Dokumentasjonsstandard I starten av prosjektet brukte vi dokumentet Dokumentasjonsstandard for bachelor-prosjekter (hovedprosjekt) for institutt for informasjonsteknologi i Høgskolen i Oslo og Akershus av Ann-Mari Torvatn. Denne standarden beskriver hvordan man kan strukturere et hovedprosjekt. Selvfølgelig må denne tilpasses hvert enkelt prosjekt, men vi valgte å bruke denne som et utgangspunkt. Etter hvert som prosjektet fikk gå sin gang dukket det opp, naturligvis, temaer som har skapt et behov for å tilføye samt endre på ting i oppgaven. Dokumentasjonsstandarden har ikke minst vært et godt verktøy for å kunne komme seg raskt i gang med en oppgavetekst som krever stor innsikt og ikke minst oversikt Styringsdokumenter Underveis i denne prosessen har vi laget dokumenter med formål å støtte opp under nettopp denne prosessen. Disse dokumentene har hjulpet oss i å nå vårt mål, nemlig å kunne ferdigstille et system som samsvarer med prosjektbeskrivelsen til NIH. I tillegg til å kunne levere en tilfredsstillende sluttdokumentasjon. Prosjektskisse Dette var det første dokumentet vi skrev i forbindelse med hovedprosjektet. En prosjektskisse er rett og slett en beskrivelse av prosjektet, dets omfang og litt om oppdragsgiver. Et slikt dokument kan anses som et utkast, til selve hovedprosjektet, i seg selv. 15

20 Prosessdokumentasjon Prosjektdagbok Prosjektdagbok er noe vi har ført i forbindelse med hvert gruppemøte vi har hatt. Her har vi notert dato, hvem som møtte, hva som ble sagt/gjort og oppgaver til neste møte. Disse loggene har også fungert som møtereferater, ettersom de kort oppsummerer hva som har skjedd på det møtet. Prosjektdagboken er tilgjengelig i gruppesiden vår under Prosjektdagbok. ( Forprosjektrapport En forprosjektrapport ligner på prosjektskissen bare at den er noe mer detaljert. Altså er dette et større dokument som analyserer hva vi har, hvordan vi skal jobbe ut ifra dette og videre hvordan vi tror dette kommer til å gå. Kravspesifikasjon En kravspesifikasjon er en slags videreføring av prosjektskisse-dokumentet og forprosjektrapporten. Kravspesifikasjonen tar for seg kravene som oppdragsgiver har til det produktet som skal utvikles. Dette dokumentet ble laget i forkant av prosjektstart og vi har underveis hatt behov for å gjøre flere endringer. Vi ble ganske raskt klare på hvilke endringer som måtte gjøres i kravspesifikasjonen, og informerte videre NIH om dette. NIH hadde ingenting å utsette på dette og vi jobbet videre ut ifra vår fornyede kravspesifikasjon. Se punkt 5.2 i produktrapporten for å se endringer som er foretatt i kravspesifikasjonen. Arbeids og fremdriftsplan I starten av prosjektet lagde vi en arbeidsplan hvor vi tildelte alle gruppemedlemmene forskjellige hovedansvarsområder. Vi valgte å jobbe på en måte slik at vi ikke var låst til å kun jobbe hovedansvarsområdene vi ble tildelt, men at dette heller innebærer å kvalitetssikre oppgaven etter at den er utført. 16

21 Prosessdokumentasjon I løpet dette halvåret har styringsdokumentene utgjort en stor og viktig rolle. Styringsdokumentene har vært bra fordi de har vært av organisatorisk gevinst og ikke minst i seg selv vært veiledende. Alt av dokumentasjon har altså støttet opp vår prosess på best mulig måte Gruppeside I forbindelse med prosjektet, har vi opprettet en gruppeside der vi legger ut dokumentasjon og gruppelogger fortløpende. Dette for å lettere kunne holde veileder, arbeidsgiver, andre interessenter, og oss selv oppdatert på prosessen, veien mot et ferdig produkt, samt endelig resultat. Ved siden av et alternativ for hjem, består menyen av dokumenter, om gruppen og prosjektdagbok. Under dokumenter finner man per dags dato statusrapport, prosjektskisse, forprosjekt, kravspesifikasjon, arbeidsplan, fremdriftsplan, prosessdokumentasjonen, produktdokumentasjonen og testdokumentasjonen. Vi har ikke valgt å skrive noe spesielt om gruppemedlemmene, men under om gruppen har vi vært så heldige at en fotograf ville ta bilder av oss, slik at alle som vil, kan se hvem vi er. Under prosjektdagbok legger vi fortløpende ut møtereferat fra gruppemøtene vi har holdt underveis i prosjektet Prosjektlogg/dagbok Som nevnt i avsnitt har vi ført prosjektdagbok for hvert av gruppemøtene våre. De gangene vi kun har jobbet med hver våre oppgaver har vi ikke ført noe i loggen. Innleggene har fungert som referater fra gruppemøtene våre. Helt i starten av prosjektet lagde vi en mal for hvordan disse skulle føres. Det var relevant og ha med hvem som møtte, dato, hva som ble sagt/gjort og til slutt om det var noe som skulle gjøres til neste møte og eventuelt hva. Dagboken ble ført direkte inn i Google Docs og 17

22 Prosessdokumentasjon videre automatisk oppdatert på vår gruppeside. Prosjektloggen har vært god å ha i de stunder hvor ting har vært uklart i etterkant av et møte. Videre var den også verdifull de gangene en eller flere fra gruppen ikke hadde anledning til å delta på et gruppemøte. På denne måten kunne den som ikke møtte lese seg opp på hva som ble sagt og gjort. 3.3 Ansvarsfordeling I begynnelsen av semesteret lagde vi en arbeidsplan for å få en oversikt over arbeidet som skulle gjøres i forbindelse med dette prosjektet. Ikke nok med at gruppen nå hadde noe å rette seg etter videre i prosessen, fikk også hvert enkelt medlem et bilde over hva han/hun skulle jobbe med dette semesteret. Det var ikke meningen at vi skulle være låst til arbeidsplanen, men at den skulle være et utgangspunkt. I startfasen til et større prosjekt er det ikke alltid like lett å være klar over nøyaktig arbeidsmengde. Tidligere har vi erfart at alt som har med programmering å gjøre, gjerne har en tendens til å eskalere mot slutten av prosjektet hva gjelder arbeidsmengde. Med dette var det ønskelig å fordele programmeringen mest mulig. Men ettersom det er kode det er snakk om er ikke dette like forenelig med virkeligheten som man av og til skulle ønske. Vi valgte akkurat på grunn av dette å planlegge god tid og mest mulig luft mot slutten av prosjektet. Vi ønsket også i tillegg til dette å legge oss på en linje hvor vi var strenge med oss selv hva gjaldt milepæler og egendefinerte frister underveis i prosjektet. Videre ble vi tidlig enige om at alle på gruppen skulle sette seg inn i rammeverket Laravel som vi valgte å benytte i dette prosjektet. Fordelingen av de forskjellige ansvarsområdene gikk smertefritt for seg. Tamas fikk hovedansvaret for rammeverket Laravel, og hadde med dette nok å bryne seg på for en stund fremover. Bilal hadde en god del organisatorisk ansvar i og med at han var vår gruppeleder. I tillegg til dette har han hatt hovedansvaret for graphical user interface, rapport og diagram. Videre jobbet Marit med design, og hadde hovedansvaret for produktdokumentasjonen. En av de nye teknologiene som vi skulle sette oss inn i for å anvende i systemet vårt tok vi for oss Arduino, Jardar hadde ansvaret for dette. Prosessdokumentasjonen, brukertesting samt underveis rapportering fikk Benedicte ansvaret for. 18

23 Prosessdokumentasjon Det er viktig å presisere at gruppen har jobbet mest mulig samlet. På denne måten får man luftet eventuelle utfordringer for de andre i gruppen raskest mulig, og man er ikke lenger alene om eventuelle problemer. Dette er verdifullt i et samarbeid. Det har vært viktig for oss at alle hele tiden skulle ha full innsikt i pågående arbeid. På denne måten ville alle i gruppen føle en tilhørighet til alt av arbeid mens det som pågikk. Vi har fått mye ut av å sitte mest mulig samlet på skolen. Dette har vært positivt for effektiv jobbing, ettersom man fikk raskt besvart eventuelle spørsmål andre på gruppa kunne besvare og ikke minst har det vært bra for motivasjonen. 3.4 Arbeidsforhold og samarbeid Som nevnt tidligere har alle på denne gruppen jobbet sammen i forbindelse med prosjekter tidligere. Det å jobbe sammen om et hovedprosjekt var, for denne gruppa, noe som hadde ligget i kortene lenge. I tidligere prosjekter har vi jobbet godt sammen blant annet fordi alle har unike måter å bidra på. Gruppemedlemmene kommer også godt over ens med hverandre, noe som er viktig når man skal forholde seg til hverandre ukentlig i et halvt år. I og med at vi er en stor gruppe var det klart fra starten av at vi måtte ha nok oppgaver til alle medlemmene. En god start for å sørge for at alle skulle få nok å jobbe med var å legge lista høyt hva gjelder krav til systemet. Vi holdt ikke tilbake på noe når det kom til visualiseringen av hvordan systemet skulle utvikles og etter hvert bli. Vi fant raskt ut at vi ønsket å sette oss inn i rammeverket Laravel i php og Arduino som brukes for automatisering av målinger av temperatur- og ph -verdier, med dette har vi i gruppen hatt nok av oppgaver å fordele oss imellom. Vi har trivdes med oppgaven vår, og vært fornøyd med at den kunne sees på som en utfordring. En viktig ingrediens som må til for å lykkes med en stor oppgave som denne, er motivasjon. Vi har allerede vært inne på at vi valgte oss ut dette prosjektet i september Vi var tidlig ute med å se i gjennom prosjektbeskrivelser, noe som naturligvis medførte at vi fikk mange valgmuligheter. BassengWeb var det vi syntes virket mest interessant, og vi sendte en forespørsel med en gang. Det at 19

24 Prosessdokumentasjon vi fikk vårt førstevalg, ga oss en fin dytt i starten av prosjektet. De på NIH var svært imøtekommende og ikke minst hyggelige, et godt forhold til oppdragsgiver har vært en god motivasjon for oss som gruppe med tanke på prosjektet. Vi ønsket ikke kun å jobbe for en god karakter, men var (og er) oppriktig interessert i at en så imøtekommende oppdragsgiver skal få det produktet de sammen med oss har definert. 3.5 Kommunikasjon I dette avsnittet skal vi beskrive hvordan kommunikasjonen har gått for seg i prosessen. Det har vært brukt forskjellige medier innad i gruppen og videre skal vi nevne hvordan vi har holdt oppdragsgiver oppdatert underveis I gruppen I utgangspunktet var det ønskelig at vi som gruppe skulle sitte mest mulig samlet når vi jobbet med prosjektet. Dette for å hele tiden være i dialog om det vi jobbet med, og rett og slett for å få et best mulig samarbeid. I starten av prosjektet avtalte vi alltid vårt neste møte på et gruppemøte. Samtidig har enkelte av gruppemedlemmene i all hovedsak jobbet på skolen hver dag, mens andre har jobbet mer hjemme og til andre tider med sine oppgaver. Gruppemedlemmene var godt kjent med hverandres vaner og var klare over at de forskjellige medlemmene gjerne jobber i litt forskjellige mønstre. For at dette ikke skulle bli noe problem hadde vi en Facebook gruppe hvor vi hele tiden har hatt diskusjoner om arbeidet vi har jobbet med. Samt har vi anvendt Dropbox for å laste opp dokumenter slik at alle har tilgang på disse. Vi har også jobbet direkte i Google Docs, der har det vært mulig for alle å samarbeide om dokumenteringen blant annet ved at man kan kommentere dokumentene og at dette lagres fortløpende. Videre har vi også hatt en gruppeside, det mest relevante med denne hva gjelder kommunikasjon mellom oss i gruppa var prosjektdagboken. Dersom noen ikke kunne delta på et gruppemøte var dette også et supplement for å holde seg oppdatert på progresjonen. 20

25 Prosessdokumentasjon Etter hvert som vi kom ordentlig i gang med hovedprosjektet var det naturlig at hver av gruppemedlemmene fikk mer kontroll over sine ansvarsområder. Dette medførte naturligvis at arbeidsmengden økte etter hvert nå som oppgaven tok form. Det var derfor ønskelig med hyppigere gruppemøter. I startfasen hadde vi ett fast i uken, dette i tillegg til at vi jobbet sammen. Men i februar ble det ønskelig å ha to møter hver uke. Dette skulle da komme i tillegg til eventuelle andre møter hvor gruppemedlemmer jobbet sammen med prosjektet. Ettersom vi har brukt Google Docs har det vært mulig, dersom nødvendig, at enkelte har kunnet jobbe andre steder enn på skolen ved behov. Men for å få et godt samarbeid og god en god flyt i oppgaveløsningen har det vært verdifullt å sitte mest mulig sammen Med oppdragsgiver Kommunikasjonen med IKT-avdelingen, samt driftsansvarlige for svømmehallen har primært bestått av møter, i tillegg har vi kommunisert noe med e-post. Vi har hatt, som nevnt tidligere, to kontaktpersoner ved NIH. Hans Olav Krogsæter, IKT-sjef har vært ansvarlig for prosjektet og har vært den personen vi har henvendt oss til ved eventuelle tekniske spørsmål. Tore Sundby er formann, han har ansvaret for driften av svømmehallen, han har vært den personen vi har kontaktet vedrørende utformingen og spørsmål om bruken av systemet. Vi har hatt tilsynelatende regelmessige møter med NIH, etter hvert som behovet har meldt seg. Vi ønsket primært å komme raskest mulig i gang med oppgaven vår, og vi ønsket å sitte på HIOA. Vi fikk tilbud om å sitte på NIH, noe vi valgte å benytte oss av etterhvert som implementeringen av systemet skulle ta sted. Det var naturlig også å brukerteste systemet på NIH for at dette skulle foregå nærmest mulig brukeren. 21

26 Prosessdokumentasjon Med veileder Geir Skjevling har vært vår kontaktperson fra HIOA i forbindelse med dette prosjektet. Kommunikasjonen med vår veileder har i all hovedsak bestått av avtalte møter. I starten var de ikke mer enn én til to ganger i måneden, men etter hvert som oppgaven tok form dukket det stadig opp flere spørsmål, og med dette ble møtene flere. På gruppemøtet vårt den 20. mars ble vi enige med veileder om å ha et fast møte med ham annenhver uke. Dette var det nå behov for ettersom vi var godt i gang med utviklingsprosessen og trengte hyppigere tilbakemelding. Etter et par av disse møtene var det ikke lenge til prosjektet var i sluttfasen. I dette stadiet av prosessen skulle vi kun skrive rapport, og dette kunne vi ikke få noe mer enn en tilbakemelding på Kommunikasjonsverktøy Det har vært sentralt å ha et eller flere kommunikasjonsverktøy for at alle til enhver tid kunne vite hva som foregår. Vi har blant annet benyttet oss av Skype for gruppesamtaler om vi skulle ha behov for dette, vi har også hatt vår egen gruppe på Facebook hvor vi har postet saker vi ønsket å få diskutert videre har vi tatt i bruk en del andre nyttige verktøy. Videre har e-post vært et nyttig og ikke minst naturlig verktøy for oss i dette prosjektet. Vi har både benyttet skole e-posten og vår private. I Google Docs, som vi har brukt for å flette sammen rapportene våre, er det også mulig å kommentere ting samtidig som man kan åpne en samtale (chat) i dokumentet. Denne har vi brukt for å diskutere teksten. For eksempel hvis det har dukket opp spørsmål om hvor avsnitt hører hjemme, hva som mangler om det er noe uklart også videre. 22

27 Prosessdokumentasjon 3.6 Diagrammer og strukturering Arbeidsplan I starten av semesteret gikk vi sammen om en arbeidsplan som skulle være vår overordnede plan i forbindelse med hovedprosjektet. I denne arbeidsplanen tok vi å delte arbeidet inn i naturlige faser med tilhørende estimert tidsbruk. Fasene vi valgte å kategorisere etter var: Startfasen, kravspesifikasjon, design, utvikling, testing, dokumentasjon og kode, innlevering og til slutt presentasjon. Figur viser øvre del av arbeidsplanen. Figur: Arbeidsplan Arbeidsplanen fungerte svært godt som en pådriver for å komme effektivt i gang med arbeidet. Vi trengte å kartlegge hva som skulle gjøres, når og hvordan. Som man ser over på figuren tok vi med beskrivelse, frist og ansvarlig til de forskjellige aktivitetene. Ansvarlige hadde ansvaret for at aktiviteten 23

28 Prosessdokumentasjon ble gjennomført, og det på best mulig måte. Det er nok flere små ting som har endret seg litt i arbeidsplanen etter hvert som prosjektet begynte å ta form. Disse endringene går nok for det meste ut på hvem som burde ha hatt hovedansvaret for de forskjellige aktivitetene. Men som nevnt hadde vi en enighet om at den med hovedansvaret skulle sørge for at arbeidet var blitt utført, men ikke nødvendigvis være den til å gjøre det selv Gantt diagram Figur er et gantt diagram som vi lagde i starten av semesteret for å få et overblikk over hva som skulle gjøres når i løpet av semesteret. Et gantt diagram anvendes når man arbeider smidig og etter scrum. Vi valgte å navngi diagrammet fremdriftsplan. Dette fordi det, som nevnt over, er en oversiktlig plan som tar for seg alle oppgaver med tilhørende tidsintervaller. Utviklingsprosessen tok lenger tid enn vi hadde beregnet. Dette kommer av at det var vanskeligere å sette seg inn i rammeverket Laravel enn vi opprinnelig hadde planlagt samtidig var vi litt rustne på hvordan en database skal designes, slik at den er utvidbar for fremtidig utvikling. Koden var satt av til å være klar i uke 17, noe vi bommet på med en uke fordi det var noen feil vi måtte rette opp i. I tillegg til dette ønsket oppdragsgiver at vi skulle legge til et par små ekstra ting mot slutten av prosjektet. Til gjengjeld var systemet satt i drift en uke tidligere enn planlagt, altså i uke 19 fremfor uke 20. Som vi ser på figur tok vi ukene bortover med tilhørende aktiviteter nedover. For oss var det viktig å ha en realistisk plan som var tilpasset til oss. I og med at det ikke alltid er like enkelt å forutse hvor mye tid man trenger i starten av et prosjekt la vi inn litt ekstra rom på slutten. Arbeidsplanen har vært viktig for oss og vi har vært flinke til å følge den. Vi tok oss dog noe mer tid mot slutten å jobbe med rapportene. En så stor skriftlig rapport vi alltids kunne pusses mer på, og vi satt veldig pris på at vi kunne gjøre nettopp dette. 24

29 Prosessdokumentasjon Figur Fremdriftsplan 25

30 Prosessdokumentasjon Risikoplan På starten av prosjektet etablerte vi en risikoplan for å kunne ta høyde for saker som kunne gå galt underveis i prosjektet. Her tok vi høyde for alt fra sykdom til at noen på gruppa eventuelt kunne komme til å hoppe av kurset. Videre presiserte vi hvordan vi skulle reagere om noen av disse hendelsene inntraff. Heldigvis opplevde vi ikke at noen på gruppa ble så syke at det ga konsekvenser for gruppearbeidet. Ettersom vi hadde mulighet til å jobbe hjemme var det å vare syk et par dager ikke noe problem, ettersom man faktisk kunne følge med hjemme ifra. Sykdom var med andre ord ett mye mindre problem i realiteten enn middels, som risikorangeringen vår tilsier. Når det gjelder kommunikasjon har alle vært tilgjengelige i såpass stor grad at dette aldre utgjorde et problem for oss. Hovedverktøyet vi har brukt for å kommunisere har vært gruppemøter, hvor facebook og/eller telefon har vært tatt i bruk for å nå gruppemedlemmer som av noen grunn ikke har vært tilstede. Ett av gruppemedlemmene opplevde ett dødsfall i kjernefamilien dette semesteret, noe som gjorde at bidraget under den perioden ikke var på det høyeste. Dette er noe som skjer og er generelt vanskelig å forutse, så man må bare ta det som det kommer og vise forståelse for at ting tar litt ekstra tid i en periode. Selv om motivasjonen var der, tar det naturligvis litt tid å komme seg på beina igjen.vi velger å slutte at risikoen for at vi rangerte risikoen om motivasjon riktig, altså lav. Dette fordi vi håndterte en relativt uforutsett hendelse, som krevde sitt, på best mulig måte. Og dette preget ikke i noen stor grad videre arbeid for gruppa. Informasjonsmangel var det største problemet vi kom over, da Laravel 4 var nytt når vi tok det i bruk og det var lite informasjon om det ute på web, spesielt lite i bruks-caser. Dette førte til at vi tok nytte av stackoverflow.com som ressurs, og måtte sette oss litt inn i Laravel 3 for å kunne oversette enkelte løsninger på våre spørsmål. Dette var også noe som løste seg etter par måneder da rammeverket ble tatt i bruk i større grad av utviklere. 26

31 Prosessdokumentasjon Tidsmangel var noe vi var litt redde for i starten da vi begynte å merke at det tok lang tid å sette seg inn i Laravel. Etter at vi kom ordentlig i gang med rammeverket ble denne bekymringen stadig mindre, og til syvende og sist bommet vi kun med en uke når det gjaldt å ferdigstille koden i henhold til gantt diagrammet. Vi fikk endte opp med å få applikasjonen ut i drift en uke før planen, dette var naturligvis noe vi var fornøyd med. For backup tok vi i bruk flere kopier lokalt av applikasjonen, Dropbox og Github. Vi hadde stort sett til enhver tid flere kopier av seneste og tidligere versjoner. Dersom om noe hadde gått galt og med det ført til et informasjonstap, eller at applikasjonen hadde blitt ødelagt. Ville det vært mulig, til enhver tid, å gjenopprette en tidligere versjon. 3.7 Styringsverktøy Trello Trello er et verktøy som hjelper flere mennesker som jobber sammen mot et mål til å holde oversikt over hvem som gjør hva, når de gjør dette, når de skal være ferdig, og når de er ferdig. Mens gruppemedlemmene tidligere har vært godt kjent med de andre styringsverktøyene som har vært tatt i brukt, var Trello nytt for alle. Dette har vært en god pådriver for å holde motivasjonen oppe ettersom at vi stadig ser at vi nærmer oss sluttresultatet, og fordi det alltid er gøy å huke av at vi har blitt ferdig med det vi har jobbet med. 27

32 Prosessdokumentasjon Figur Skjermdump fra vår trello board Dropbox Dropbox har vært et viktig verktøy i forbindelse med denne prosessen, samtidig som det har vært flittig tatt i bruk. Ved bruk av Dropbox har alle hatt tilgang til samme mappe, der vi underveis har lagret alt vi har brukt av ressurser til hovedprosjektet. Herunder finner vi styringsrapporter, bildefiler, litteratur, og diverse utkast. Mappen har vi kalt Hovedprosjekt, og den er blitt nøye strukturert, slik at man enkelt kan finne frem til det man trenger Google Docs Vi har fra starten av brukt Google Docs til å skrive rapporter og prosjektdagbok. Dette er et verktøy som gjør det mulig å dele et dokument med flere brukere, slik at hver enkelt kan skrive i dette samtidig. Dette har vært veldig praktisk da styringsdokumentene har vært omfattende, og vi alle har måtte bidra med diverse punkter. Det har også gjort det enklere for alle å holde oversikt over hva de andre skriver, og man har lett kunnet gått inn i en annens tekst for å rette opp eventuelle feil. 28

33 Prosessdokumentasjon 3.8 Fil- og kodedeling Siden begynnelsen av prosjektet har det vært viktig at alle skal delta på alle områder og dermed har det vært viktig at for å jobbe effektiv, så må alle ha tilgang til samme oppdatert kode og dokumentasjon. For kodedeling falt valget på GitHub. Git er et distribuert versjonskontollsystem for kildekode. Git tar vare på revisjoner av koden, og det er mulig å gå tilbake i tid for å se på tidligere revisjoner. 4. Om utviklingsprosessen 4.1 Teknologier Frontend HTML 5, CSS 3 og Javascript HTML 5 (HyperText Markup Language) er en standard for beskrivelse av Web dokumenter som kan manipuleres ved hjelp av Javascript. Dette innebærer blant annet at det er mulig å manipulere form, innhold og media i html dokumenter på klientsiden. Grunnen til at vi valgte å kombinere HTML 5, CSS og javascript er fordi: Kombinasjonen er støttet på de fleste plattformer, dette inkluderer Windows, Linux, OS X, Android og IOS. Teknologiene er standardisert og har store aktører som støttespillere. Støtten for HTML 5 er stor og økende i de ulike nettlesere. Alt av HTML 5 funksjonalitet som er brukt er støttet i de valgte nettleserne som oppdragsgiver ønsket. 29

34 BassengWeb Hovedprosjekt ved HIOA 2014 Prosessdokumentasjon Twitter Bootstrap er et front end verktøy for rask utvikling av web applikasjoner. Det er en samling av CSS og HTML konvensjoner. Den bruker noen av de nyeste nettleserteknikkene for å kunne gi utviklere stilfull typografi, skjemaer, knapper, tabeller, navigasjon og mye mer som blir brukt i forskjellige web applikasjoner. Det var et ønske fra vår side å kombinere blade syntaksen i view med Twitter Bootstrap. Dette bød på en del utfordringer, men Laravel var laget for å ta i bruk Twitter Bootstrap, dermed fikk vi øsnket vår oppfylt Backend PHP For å programmere backend tok vi i bruk PHP, som er ett programmeringsspråk som prosesserer serverbasert kode og fletter dette inn i HTML for å kunne lage dynamiske nettsider. PHP blir tolket av webserveren mens det kjører, altså blir det ikke sammensatt før det kjøres. PHP brukes sammen med HTML, som vi har nevnt tidligere, for å gjøre websider dynamiske. Den tillater videre bruk av logikk som for eksempel å utføre en spesifikk funksjon basert på statusen til noe annet i samme kode. Vi kunne alle grunnleggende PHP fra før, men å bruke det til å utvikle noe eget har vært utfordrende for oss alle. Vi har med dette hovedprosjektet tatt vår kunnskap i PHP til ett nytt nivå FPDF FPDF er en klasse i PHP som kan lastes ned å tas i bruk gratis (opensource), denne klassen gjør det mulig å generere PDF filer med ren PHP. Dette kan gjøres statisk eller dynamisk fra for eksempel en database, som er gjort i vårt tilfelle. Mye er predefinert i FPDF, noe som gjør det enkelt og lettvint å sette det opp. 30

35 BassengWeb Hovedprosjekt ved HIOA 2014 Prosessdokumentasjon Laravel 4 Laravel 4 er ett rammeverk innenfor PHP, rammeverket gir oss verktøy som ikke er inkludert i vanlig PHP og gjør utviklingen enklere (spørs selvfølgelig på formålet med hva som skal utvikles). Laravel 4 forklarer vi nærmere i punkt Model-view-controller (MVC) MVC et designmønster som er vanlig å anvende innen programvareutvikling. Det fungerer som en arkitektur som deler applikasjonen inn i tre lag: model(data), view(brukergrensesnitt) og controller. Modellen håndterer databasen i form av at tabellene blir konvertert til objekter man kan jobbe med som skal være 1:1 med det som er i databasen. For eksempel om vi kaller på all data i routines tabellen vil vi kunne aksessere de enkelt ved å kalle på attributtet vi er ute etter. View er presentasjonslaget som bruker har kontakt med, dette er stort sett kun HTML og CSS. Oppgaven til view er å presentere data på en enkel og oversiktlig måte for at en bruker skal kunne se, manipulere, opprette eller slette data. Controller har som oppgave å håndtere logikk i applikasjonen, det er her data blir filtrert og manipulert før det sendes videre til view. Alt som gjøres med data skjer her, om en bruker skal opprette en ny måling så er det controller som tar seg av å kalle på modellen, fylle den med data og til slutt lagre den. Man kan si at det er ett slags lim mellom modell og view. 31

36 Prosessdokumentasjon Figur MVC modellen 4.3 Laravel 4 Laravel 4 er ett rammeverk for PHP som er strukturert etter MVC prinsippet, applikasjonen er da delt inn i tre lag som vist i figur ovenfor, modell, view og controller. Rammeverket benytter seg av routes som brukes for å trigge hendelser basert på spesifikke URI er (universal resource identifier), For eksempel om man skal sette inn data i en tabell så sender inntastingsformen nettleser til en URI (som i vårt tilfelle) er../bassengweb/postinsert. Dette trigger en funksjon som er definert i en route som reagerer på /postinsert som forstår at den skal hente data fra formen, kalle på en modell og lagre denne i databasen. Laravel 4 tilbyr også en rekke andre funksjoner, som enkel autentisering via en innebygget Auth klasse som blir linket med brukertabellen i databasen. Denne kan da settes opp med forskjellige filtre, som for eksempel sjekker om en bruker er logget inn, hva slags brukertype brukeren har og filtrene er da lagt rundt spesifikke routes som ikke alle skal ha tilgang til. 32

37 Prosessdokumentasjon Valideringer er gjort med innebygde metoder som er veldig lette å tilpasse til ens eget bruk. Laravel sin validator klasse kommer ut av boksen med mange funksjoner, eneste man trenger å gjøre for at de i det hele tatt skal fungere er å skrive inn navnene på input feltene og definere noen enkle regler (eksempler på dette kan være, men ikke begrenset til; required password, eller unique:users). Som man ser i eksempelet kan disse valideringene også linkes til databasemodellene. I dette tilfellet vil den gjøre det umulig å registrere to brukere med samme epost. Det er også støtte for å sette inn egne feilmeldinger som trigger da en validering ikke går igjennom. Masterpages er ett konsept hvor man bygger en slags grunnmur av en view fil som andre views kan extende. Dette betyr kort og godt at om man skal ha en hovedmeny som skal følge med på alle view filene så kan denne defineres i master. Når views extender master så kommer de også til ha denne. Rammeverket baserer seg på enkelt og ren kode, noe som gjør at det er enkelt å forstå som igjen gjør videreutvikling enklere. I starten av prosjektet var det, som vi har vært inne på tidligere, utfordrende å sette seg inn i Laravel. Men vi sitter igjen med masse ny kunnskap, samtidig som vi føler det på sikt var lurt å velge å sette seg inn i rammeverket. Vi ønsket å benytte muligheten hovedposjektet ga til å lære oss noe nytt. Vi tittet på flere rammeverk, av disse var Laravel det som virket mest interessant ettersom sikkerhet i form av login funksjonalitet er bra, videre virket også databasehåndteringen interessant Eloquent Eloquent ORM (engelsk: Object relational mapper) er en teknikk som brukes for å gjøre det simpelt å hente, manipulere og lagre/slette data mellom koden og en relasjonsdatabase. Her blir objekter hentet fra databasen som tilsvarer tabellene som man får ut av en SQL spørring, på disse objektene kan man utføre logikk og dette gjenspeiler seg i selve databasen. Eloquent gjør det mulig å håndtere databaselogikken uten at man nødvendigvis trenger å skrive så mye som en eneste linje med SQL. Eloquent tar også hensyn til relasjonene i databasen, dette gjøres ved å definere de i modellene slik. 33

38 Prosessdokumentasjon Figur Routines tabellen sine relasjoner. Figur Tasks sin relasjon, her ser man også ett eksempel på valideringsregler med regex. På denne måten skjønner Eloquent at om man for eksempel skal hente ut en utført oppgave fra routines tabellen så henter også riktig tittel fra tasks automatisk Blade Blade templating engine gjør det enkelt å jobbe med view filene, den er med på å gjøre koden mer leselig, enklere og med dette forkortet. Ett eksempel på en funksjonalitet som blade tilbyr er master pages. Denne funksjonaliteten gjør det lettere med gjenbruk av kode. I tillegg er det lagt til noen logiske handlere som ikke finnes i vanlig PHP, ett eksempel på dette som er en motsatt if statement. 34

39 Prosessdokumentasjon Blade templating engine gjør det mulig å gjøre følgende: 1. Definere seksjoner: Man lager en master layout fil som nevnt ovenfor, og denne inneholder da ting som man gjerne vil ha på alle forskjellige view pagene, hovedmeny, header, footer, tittel o.l. 2. Utvide views: For å utvide en view trenger vi kun å definere en utvidelse, og videre enten overskrive eller tilføye seksjoner man selv har definert. Figur View filen er en utvidelse av filen master.blade.php i mappen layouts. 3. Echo og escaping: Blade gjør det veldig enkelt å skrive ut variabler, samt å escape input slik at man kan unngå injection. For eksempel kan man i stedet for å skrive: Figur Eksempel på hvordan man vanligvis ville skrevet ut navn. 35

40 Prosessdokumentasjon kan man skrive: Figur Hvordan man kan gjøre det samme med Blade. For å escape input kan man benytte denne metoden med trippel klammeparantes: 4. Ifs Figur Her blir bruker input escapet. Blade gjør if statements mye enklere ved at koden for de er forkortet og syntaksen er simpel: Figur Eksempel på en logisk if med Blade syntaks. 5. Løkker I tillegg til å gjøre ifs enklere gjør Blade dette også med løkker: Figur En foreach løkke med Blade syntaks. I eksempelet kan man også se hvordan man henter ut data fra en Eloquent model. 36

41 Prosessdokumentasjon 6. Includes: Blade tillater at man inkluderer views i views, for eksempel om man lager en navigasjon kan man (i tillegg til å gjøre det i en master.blade.php fil) lagre den i en egen view og inkludere denne i en annen: Figur En masterpage man kan utvide andre view filer ifra slik at de inneholder dette innholdet. 4.4 Google Chart Google chart er et verktøy som brukes til å lage ulike typer diagrammer innebygd i en web-applikasjon fra statisk- eller dynamiske data. Google lager et PNG bilde av diagrammet og formaterer parameterne i en HTTP forespørsel. Google chart er i tillegg kompatibel med alle nettlesere og krever ingen plugins, i motsetning til andre verktøy som krever flash. Google Chart er brukt til å visualisere målinger, som blant annet Badende Per Time vist i figur 4.4. Diagrammet er et linjediagram, med verdi i Y-aksen og tid i X-aksen. Hvert punkt viser en måling, ved å muse over et punkt får brukeren vite tid, dato for målingen og verdien, dette vil si at det er multivariate data. Visualiseringsteknikkene som er brukt er farger for å vise relasjoner mellom objekter som representasjonsmetoder. 37

42 Prosessdokumentasjon Christoffer Haeley har i sin artikkel beskrevet flere problemstillinger ved bruk farger, (Haeley, 1999) Oversatt til norsk: " "Hvis vi bruker farger for å representere data er det viktig at vi stiller oss selv spørsmålet: Hvordan kan vi velge de mest effektive fargene som gir oss en god differensiering mellom data elementer under visualiseringsoppgaven". Han stiller videre tre spørsmål: Hvordan kan vi tillate rask og nøyaktig identifikasjon av individuelle data elementer gjennom bruk av farger. Hvilke faktorer avgjør om mål-elementets farger gjør den lett å finne, relativ til forskjellig fargende ikke mål elementer. Hvor mange farger kan vi bruke på en gang og fremdeles ha en rask og nøyaktig identifikasjon av målet. Healey stiller noen interessante spørsmål når han for eksempel spør om hvor mange farger man bør bruke samtidig, slik at det fremdeles er mulig å identifisere målet. Det kan gjøre det vanskeligere for brukeren dersom bruken av farger på en eller annen måte blir for overveldende. Dette kan føre til at den sentrale informasjonen blir utydelig. Dette er unngått ved at vi tok i bruk farger som er enkle å skille fra hverandre kombinert med bruk av labels som forklarer hva de ulike fargene står for. 38

43 Prosessdokumentasjon Figur 4.4 Google Chart (Badende Per Time og Auto Temperatur) 39

44 Prosessdokumentasjon 4.5 Arduino Yún Arduino Yún er en unik mikrokontroller. Den programmeres tilnærmet likt som Arduino Leonardo, og bruker i tillegg samme prosessor (Atmel ATmega32U4). Den har også en ekstra prosessor, en Atheros AR9331, som kjører en Linux distribusjon basert på OpenWRT. Brettet kan programmeres via USB, på lik linje med Leonardo. Man kan og konfigurere Yún en til å koble seg opp til nettet via WiFi. Da kan man programmere 32U4 prossessoren via det trådløse nettet. For å koble Arduino en til en datamaskin, trenger man en Micro-B USB kabel. Kabelen gir strøm og data til brettet. Når man programmerer Yún en er det essensielt at man velger Arduino Yún fra Tools > Board menyen i Arduino en sitt IDE. Arduino Yún er kun støttet av Arduino IDE eller nyere. Forskjeller fra Arduino Leonardo Figur: Arduino Yún oversikt 40

45 Prosessdokumentasjon I tillegg til 32U4, kommer Yún med en ekstra prosessor, Atheros AR9331, som kjører en distribusjon av Linux for innebydge systemer kalt Linino som baserer seg på OpenWRT. På brettet finner vi og en full installasjon av Python 2.7. Yún en har flere fysiske forskjeller fra Leonardo brettet. Brettet har inngang for SD-kort, en Ethernet jack og en USB-A kontakt. Brettet får strøm fra micro-usb porten, og ikke via en egen strøm kontakt slik som Leonardo. Det finnes derimot ingen 5V regulator, og hvis man tilføyer mer enn 5V, kan man skade brettet. Man kan tilføye strøm til Vin eller 5V pin, men det er anbefalt å alltid bruke USB-tilkoblingen hvis mulig. SD, Ethernet og USB-A kontaktene har ikke kontakt med 32U4 prosessoren, men er koblet mot AR9331. Arduino Yún fungurer på samme måte som Leonardo, med unntak av bruk av Serial, som er reservert for kommunikasjon med AR9331 prosessoren. Yún en har i tillegg en WiFi modul innebygd. Den tillater brettet å koble seg opp mot en trådløs ruter, eller fungere som et tilgangspunkt. 32U4, WiFi og AR9331prosessorene har alle hver sin fysiske knapp på brettet for tilbakestilling. Yún en kommer og med flere LED lys. De indikerer status på strøm, WLAN-, Wan- og USB-kontakt. I tillegg er pin 13 koblet mot et av statuslysene (L13). Figur: Arduino Yún forskjellige knapper 41

46 Prosessdokumentasjon Yún en kommer og med flere LED lys. De indikerer status på strøm, WLAN-, Wan- og USB-kontakt. I tillegg er pin 13 koblet mot et av statuslysene (L13). Figur: Arduino Yún koblingsmuligheter Hvorfor Arduino i vårt prosjekt? Vi snakket med oppdragsgiver om Arduino i et møte før nyåret. De gav uttrykk for at de ønsket automatiske målinger for sammenligning mot de manuelle målingene. Verdiene for temperatur, ph og klor var ønsket automatisert. Det som var problematisk var knyttet til at det er lovpålagt at målinger gjøres manuelt, dermed kunne ikke Arduino overta den manuelle jobben Hvorfor Arduino Yún? For vårt prosjekt trengte vi en Arduino Yún som vi først trodde skulle lagre målinger trådløst, men i ettertid viste seg at det ikke var trådløst nettverk i det tekniske rommet. Dermed kunne vi ikke bruke det trådløse nettverket på Arduino Yún. Det viste seg at det var et nettverkuttak som ikke var i bruk, så 42

47 Prosessdokumentasjon dermed endte vi opp med å koble Arduinoen på det kablede nettverket Pris Da oppdragsgiver stod for betalingen, ble priser og budsjett diskutert med dem. Temperatur sensoren kostet under hundrelappen, ph litt over tusen og klor over ti tusen. Temperatur og ph ble bestemt som rimelige nok for prosjektet, Klor sensoren var for risikofylt, med tanke på at vi ikke hadde noe tidligere erfaring med Arduino og beløpet som kunne gå tapt ved eventuelle feil. Selve Arduino en kostet kr Anskaffelse Anskaffelsen av temperatur-sensoren ble gjort via ebay.com fra en selger i Kina, mens ph-kitet ble kjøpt fra firmaet Atlas Scientific. Ph-kiten bestod av: ph5 krets BNC tilkobling ph sensor ph kalibreringsvæsker Arduino Yún ble kjøpt via nettbutikken EZtronics som holder til i Sverige Læringsprossesen Ettersom Arduino var et ukjent tema for oss, tok vi turen til Sonen ved UiO for å tilegne oss kunnskap. Her er det flere studenter som jobber med Arduino er og andre prosjekter. Der fikk vi en introduksjon i bruken av Arduino av en student som selv jobbet med ett Arduino basert prosjekt. Han gav oss en introduksjon i IDE et og lærte oss grunnlaget for Arduino skisser. På sonen fikk vi mulighet til å lodde sensor kablene på et eget koblingsbrett og oppkobling av temperatur sensoren siden det 43

48 Prosessdokumentasjon fantes utstyr til dette Arduino IDE r2 BETA Først fikk vi en introduksjon til IDE et. Da lærte vi hvilke innstillinger vi måtte sette for at programmet skulle fungere sammen med Arduino Yún. Et IDE, Integrated Development Interface, er en applikasjon for utvikling av programvare. Man må sørge for at man har valgt riktig brett under tools > board. Den skal settes til Yùn, som man finner i listen hvis man har nyeste versjon av IDE et, r2 BETA. Så må man velge COM porten som programmet skal snakke med. Med Arduino en koblet til pc en via usb, finner vi den listet under tools > Serial ports. Dersom man kobler Arduino en til samme nettverk som pc en, finner vi den listet med en ip adresse på samme sted. IDE et kommer med en innebygd seriell monitor. Man bruker den til å overvåke data strømmen ut fra Arduino en, eller sending av kommandoer via kommandofeltet. Det er viktig at baudrate er definert likt i skissen og monitoren. Baudrate er hastigheten for informasjonen som overføreres, eller rettere sagt antall symboler som kan sendes hvert sekund. Baudrate måles i antall bps (bauds per second). Definering av baudrate i skissen, skjer i setup metoden. Koden Serial.begin(9600), setter baudraten i skissen til 9600 bps. For at skissen skal snakke korrekt med monitoren, må vi også sette den til 9600 bps. Man finner monitoren under tools > Serial monitor, eller via en snarvei øverst til høyre i IDE et. Man velger baudrate fra en dropdown liste nederst til høyre i monitoren Arduino skisse En arduino skisse består av to metoder, void setup() og void loop(). Setup metoden kjøres med en gang en skisse startes. Her kan man initialisere variabler, pin-modus, starte biblioteker, etc. Setup 44

49 Prosessdokumentasjon BassengWeb - Hovedprosjekt ved HIOA 2014 kjøres kun en gang, ved oppstart eller omstart av Arduino Yún. Loop metoden kjøres gjentagende når programmet kjører. Det er her programkoden kjøres. Mange av Arduino ens innebygde funksjoner krever importering av spesielle biblioteker for at de skal fungere. Dette fordi de inneholder forhåndsdefinerte metoder som Arduino en må ta i bruk. Det er også biblioteker for de fleste sensorene på markedet, som inneholder metodene man trenger for å bruke dem. For temperatur sensoren vår trengte vi bibliotekene DallasTemperature og OneWire Lodding og Oppkobling Når det gjelder lodding og oppkobling av temperatursensoren, måtte vi koble ledningene på et eget koblingsbrett, sammen med en 4k7 resistor. Alt vi trengte lå på sonen, og vi fikk ett lite koblingsbrett og en 4k7 resistor. Vi ble vist hvordan vi korrekt skulle lodde kablene og resistoren, men utførte loddingen selv. Koblingen av sensoren til Arduino, er vist gjennom figurene , men vi har også illustrert det selv, for å gi en bedre oversikt (Figur ). Figur: Kobling1 Figur: Kobling2 45 Figur: Kobling3

50 Prosessdokumentasjon Figur: Oversikt Temperatur skisse Se figur Neste steg i agendaen var å lage en skisse som hentet temperatur målinger og printet dem ut i monitoren. Det var nødvendig å importere bibliotekene DallasTemperature (Metoder for selve sensoren), og OneWire (Metoder for kommunikasjonen mellom sensor og arduino). Metodene blir brukt automatisk når de trengs, eller direkte i koden. Det måtte opprettes objekter av bibliotekene. OneWire objektet sendes med parameteren 7, den definerer porten som man skal koble OneWire kabelen til. DallasTemperature har metoder som trenger tilgang til OneWire biblioteket, og vi sender derfor med OneWire objektet som parameter til DallasTemperature objektet. Vi deklarerte en variabel hvor vi skulle lagre verdien vi fikk fra sensoren. I setup metoden startes først kommunikasjonen med Arduino en og seriell porten. Hastigheten ble satt 46

51 Prosessdokumentasjon til 9600 bps, som er verdien monitoren er satt til som standard. En while metode stopper programmet til kommunikasjonen er opprettet. Det siste som måtte gjøres i setup er å starte DallasTemperature objektet. Dette starter sensoren og gjør den klar til å motta kommandoer. I loop metoden blir målingene startet og printet ut i monitoren. Metodene for å gjøre dette er definert i DallasTemperature biblioteket. Den første linjen med kode som kjøres starter målingene. Disse blir utført kontinuerlig og legges i et array i det midlertidige minnet til temperatur sensoren. Neste linje i koden henter verdien i celsius format fra index posisjonen i arrayet, og legger den i variabelen vi deklarerte. Til slutt printes verdien ut i monitoren. Slik kjøres programmet i en gjentagende loop. Vi hadde nå bekreftet at temperatursensoren fungerte, og laget kode som vi kunne ta i bruk ved et senere stadie i prosessen. Det var da tid for å starte arbeidet med ph sensoren. Figur: Temperatur skisse 47

52 Prosessdokumentasjon Atlas Scientific ph stamp 5.0 PH sensoren var en stor del av Arduino prosjektet. I sluttfasen av prosjektet sluttet desverre ph kretsen å respondere. Grunnet begrenset tid var det ikke mulig å bestille en ny og dermed ble den ikke en del av sluttproduktet. PH Circuit er et svært kompakt ph overvåkingssystem som passer på alle koblingsbrett. Dette lar brukeren nøyaktig overvåke ph uten å legge noen ekstra kretser eller komponenter til systemet. Kommunikasjon med ph kretsen gjøres ved hjelp av kun 14 enkle ASCII kommandoer. PH kretsen gir vitenskapelig grad avlesninger i systemer hvor spenningen er 0. PH Circuit er en innebygd løsning utviklet for å sende ut raske, kalibreringsfrie, vitenskapelige grad ph-verdier i en enkel asynkron seriell dataoverføring. Fra en enkel ph lesing til et uendelig antall målinger, så vil ph-kretsen levere nøyaktige målinger på bare 378 millisekunder. Det skal nevnes at man kun oppnår vitenskapelig grad målinger ved å gjøre ph sensoren temperatur-avhengig. Uten å sende med temperatur informasjon til kretsen, vil kretsen bruke en standard temperatur på 25 grader Celsius. Vi var ikke interessert i å oppnå vitenskapelig grad målinger i starten, ettersom vi ikke visste hvilke problemer vi kunne møte på ved oppkobling av to sensorer på samme koblingsbrett. Vi ønsket først og fremst å koble opp ph kretsen riktig. 48

53 Prosessdokumentasjon Oppkobling Figur: Oppkobling ph Vi fant koblingsskjema på hjemmeområdet til Atlas Scientific. Ut i fra figur skjønte vi at GND, TX, RX og VCC skulle kobles mot Arduino en, og PRB og GND (shield) mot BNC en (sensor kontakten). Første oppkobling så ut som følger. ph >> Arduino GND >> GND TX >> Pin 1 (RX) RX >> Pin 2 (TX) VCC >> 5V PRB >> BNC (midt) GND >> BNC (shield) Vi tenkte at vi hadde riktig oppkobling og begynte derfor arbeidet med å lage en skisse som skulle teste om systemet virket. Vi fant ut tidlig i denne fasen at vi måtte bruke biblioteket SoftwareSerial. Denne 49

54 Prosessdokumentasjon bruker de digitale pinnene på Arduino en til kommunikasjon. Vi måtte derfor definere rx og tx for Arduino til pin 8 og 9. Den nye og riktige oppkoblingen kan du studere i figur Figur: Oversikt ph sensor PH skisse Vi ønsket nå å lage en skisse tilsvarende som den for temperatur sensoren. Vi ville utføre målinger, og printe dem ut i monitoren. Arduino Yún er det nyeste brettet på markedet og det var begrenset med ressurser som omhandlet oppkobling av ph sensoren mot Yún en. Vi fant flere eksempler til andre mikrokontrollere, men de var komplekse og villedet oss til tider. Etter å ha utforsket flere metoder og 50

55 Prosessdokumentasjon opparbeidet tilstrekkelig med kunnskap, kom vi fram til en kort og enkel løsning på oppgaven (Figur ). Vi var som sagt nødt til å bruke de digitale pinnene på Arduino en, og det gjøres med SoftwareSerial. Det er et bibliotek som håndterer kommunikasjon tilsvarende pin 1 og 2 (rx og tx) på brettet. Pin 1 og 2 bruker en maskinvare komponent, UART, for seriell kommunikasjon. Denne tillater seriell kommunikasjon selv om Arduino en utfører andre oppgaver, men har begrenset plass til mellomlagring på 64 byte. SoftwareSerial er utviklet for å tillate bruk av de andre digitale pinnene, og bruker programvare til å etterligne funksjonaliteten. Det er mulig å ha flere software serial porter med maksimal baudrate. Øverst i koden importeres biblioteket slik at det skal kunne brukes. Deretter defineres rx og tx til henholdsvis pin 8 og 9. Disse sendes med som parameter til objektet vi oppretter av SoftwareSerial, myserial. En variabel ph opprettes for midlertidig lagring av målingene. Setup Her startes seriell kommunikasjonen som vanlig med Serial.begin. Deretter starter SoftwareSerial kommunikasjonen ved å initiere objektet, myserial.begin. Det var en ting her som var viktig å passe på. Hvis ikke seriell koblingen, SoftwareSerial koblingen og ph-kretsen opererer på samme baudrate, risikerer man unøyaktige målinger. PH kretsen kjører standard på bps. Den hastigheten er ikke implementert i Arduino sin monitor. Det var derfor nødvendig å velge en annen hastighet. Vi valgte å gå for en høyere hastighet for at systemet ikke skulle operere saktere enn standard. Vi satt hastigheten for Serial og myserial til bps i skissen. For å endre hastigheten i ph kretsen måtte vi ta i bruk en av de innebygde kommandoene. 51

56 Prosessdokumentasjon Kommandoer Det finnes 14 innebygde kommandoer man kan sende til ph kretsen. Alle kommandoene må følges av en carriage return karakter (<CR>, CR eller bare R). Monitoren måtte settes til å kun lese og skrive data som ender med carrige return for at programmet skal funke. Det gjøres i dropdown listen ved siden av baudrate nederst i høyre hjørne. Figur viser de ulike kommandoene. Kommando Funksjon Standard status L1 Aktiverer feilsøke LED en Aktivert L0 Deaktiverer feilsøke LED en Deaktivert R Foretar en måling N/A C Foretar målinger kontinuerlig hvert 378 millisekund N/A TT.TT Gjør målingene temperatur avhengige 25 C E Stopper målingene / går i standby modus N/A S Kalibrering for ph 7 N/A F Kalibrering for ph 4 N/A T Kalibrering for ph 10 N/A X Tilbakestiller kretsen til fabrikkinnstillinger N/A I Printer informasjon om kretsen N/A #(xxxx,!,?) Setter ID for enheten Ikke satt Z0 Endrer baudraten til standard verdi 38,400 bps Z(1-8) Endrer baudraten til fikset verdi Z6 (38,400 bps) Figur ph kommandoer Nederst i setup metoden finner vi koden myserial.print( Z7/r ). Ved bruk av funksjonen print, skriver vi til ph kretsen via myserial objektet. Vi sender med kommandoen Z7, som setter baud hastigheten for kretsen til bps, etterfulgt av den nødvendige carriage return karakteren /r. 52

57 Prosessdokumentasjon Programmet Selve programmet skal kun foreta en måling og printe den ut i monitoren om og om igjen. Først sendes derfor kommandoen R, som foretar èn måling, gjennom myserial objektet til kretsen. Vi mottar så en strøm av data fra kretsen til myserial. Mens datastrømmen er tilgjengelig, leses en karakter som deretter legges til variabelen vi deklarerte. Dette skjer gjentagende til vi har mottatt siste karakter i datastrømmen. Variabelen ph inneholder nå all data vi fikk fra datastrømmen, som tilsvarer en ph måling. Til slutt printes variabelen ut i monitoren og ph variabelen klargjøres for ny måling. Kalibrering Kit en vi kjøpte fra Atlas Scientific inneholdt 4 ph løsninger for testing og kalibrering. En gul (ph 7), rød (ph 4), blå (ph 10) og grå (Oppbevaringsvæske). Hovedsakelig skulle ph sensoren være kalibrert fra det øyeblikket vi tok den ut av boksen. Vi opplevde derimot at målingene ikke stemte med ph løsningen vi la sensoren i. Vi så derfor behovet for å lage en skisse for kalibrering. Under ser du guiden fra Atlas Scientific: 1. Først plasser ph sensoren i den gule ph 7 løsningen. 2. Sett kretsen i continues mode (kontinuerlige målinger). 3. Vent 1-2 minutter. 4. Send S kommandoen. Din ph krets er nå kalibrert for ph 7! 5. Rist ph sensoren og tørk med et papirtørkle. 6. Plasser ph sensoren i den røde ph 4 løsningen. 7. Vent 1-2 minutter (Kretsen skal fortsatt være i continues mode). 8. Send F kommandoen. Din ph krets er nå kalibrert for ph 4! 53

58 Prosessdokumentasjon 9. Rist og tørk ph sensoren. 10. Plasser sensoren i den blå ph 10 løsningen. 11. Vent 1-2 minutter (Kretsen skal fortsatt være i continues mode). 12. Send T kommandoen. Din ph krets er nå kalibrert for ph 10! 13. Send E kommandoen. (Stopper målinger) 14. PH kretsen er nå kalibrert. Kalibreringsdata blir lagret i kretsens EEPROM (midlertidig minne) og blir tatt vare på selv om vi kobler strømmen fra kretsen. Ut i fra guiden så vi hva skissen vår måtte gjøre. Alt som skulle gjøres var å sende kommandoer, vente og gi beskjeder når kretsen er kalibrert. Det var en detalj vi tenkte var viktig, men som ikke stod i guiden. Det var å sende med temperatur til ph kretsen for å gjøre målingene vitenskapelig gradert. Skissen vi lagde var bygd opp likt som LesPH. I loopen sendte vi først C kommandoen med myserial.print( E/r ) og startet målingene. Vi tok temperaturen på ph løsningene og sendte med gjennomsnittlig temperatur verdi til kretsen, eksempelvis myserial.print( 23.50/r ). Vi kunne også fått temperatur verdien automatisk fra temperatur sensoren, men vi hadde ikke koblet opp begge sensorene samtidig på dette stadiet. Så pauset vi programmet i 2 minutter med delay(120000l). Det er nødvendig å definere delay en som long, da funksjonen ikke klarer å lese en så stor int. Delay stopper skissen, men ph kretsen utfører fortsatt målinger kontinuerlig. Etter delay en sender vi S kommandoen og kretsen blir kalibrert for ph 7. Vi skriver så ut en beskjed i monitoren som forteller brukeren at sensoren er kalibrert for ph 7 og at det nå er tid for å tørke sensoren og legge den i ph 4 løsningen. Vi utsetter så programmet i 3 minutter. Dette for å gi brukeren 1 minutt på å bytte ph løsning og sensoren 2 minutter på å stabilisere verdiene. Kommandoen F sendes og prosessen gjentar seg også en siste gang for ph 10. Etter at T kommandoen er sendt, stoppes målingene med E kommandoen og vi printer en melding om fullført kalibrering. Etterhvert som vi lærte mer om Arduino, fant vi ut at vi kunne lage våre egne kommandoer. I monitoren er det et input felt som snakker med Arduino en. Med funksjonen Serial.read() kunne vi lese det som 54

59 Prosessdokumentasjon sendes herfra. Med dette i bakhodet, innså vi at det var mindre stressende å kalibrere hvis vi kunne sende kommandoene selv i stedet for å måtte være konstant oppmerksom på monitoren. Vi videreutviklet derfor kalibrering skissen: Skissen står hele tiden og leser det som sendes til Serial fra monitoren. Hvis noe sendes, legges karakteren til en variabel. Vi tester så denne variabelen og utfører forskjellig kode ut ifra hvilken karakter vi som er sendt. Vi gjorde det enkelt og lagde våre egne kommandoer til å tilsvare tallene sender med temperaturverdi, 2 sender C kommandoen, 3 sender F kommandoen, osv. Dersom variabelen er noe annet en tallene 1-8 sendes en feilmelding. Kommandoen 8 skriver en liste over de egnedefinerte kommandoene i monitoren. Denne listen blir også printet en gang fra setup metoden for å gi brukeren oversikt over kommandoene. Sending av data Vi fikk nå tak i temperatur og ph verdier. Det som manglet for prosjektet var kommunikasjonen over internett og sending av verdier til databasen. Databasen vi skulle sende data til var en MSSQL database. Vi var da sikre på at vi kunne sende verdiene med SQL spørringer. Vi lagde en php fil, updatedb.php, som via SQL spørringer skulle lagre en temperatur i databasen, samt tiden og datoen for når målingen ble utført. Filen tar i mot en temperaturverdi, $value = $_GET['Temp'] og legger den til databasen med en insert setning. Filen henter variabelen Temp fra en HTTP request. Verdien kan defineres i enden av URL en, eksempelvis http/.../updatedb.php?temp= Filen sender ut en beskjed om vellykket eller feilet transaksjon. Lagringen ble utført i databasen ved en kjøring av URL en i nettleser. Kommunikasjonen mellom databasen og php filen var dermed korrekt, og manglet kun siste steg i prosessen. Deretter måtte det gjøres et kall på updatedb.php fra Arduino en. 55

60 Prosessdokumentasjon Vi visste at nettverkskortene til Arduino en var koblet mot Linino prosessoren og at kommunikasjon mellom de to prosessorene var nødvendig. Linux har innebygd programvare for å håndtere overføring av data gjennom HTTP protokollen. For å utnytte dette må man lage en prosess som tar i bruk programvaren. Da måtte Process biblioteket importeres. Vi utforsket Process på Arduino nettstedet og fant fram til et eksempel som viste hvordan man tok det i bruk. Flaks for oss var det at eksempelet også foretok en HTTP request med den innebygde funksjonen Curl. Curl er et kommandolinje program som brukes til å hente eller sende filer ved bruk av URL syntax. Den støtter en rekke med internett protokoller, deriblant HTTP. Eksempelet vi fant curlet en URL adresse og leste det vi fikk tilbake fra serveren. I praksis er det som å kjøre URL en i nettleseren. Likt som en nettleser, sender Curl funksjonen en forspørsel til serveren om å få tilsendt dokumentet. Etter å ha fått det tilsendt, kjører den dokumentet og sender ut en datastrøm. I nettleseren vil datastrømmen tilsvare det vi får visualisert. I skissen leser vi datastrømmen som tekst, som vi kan fremstille i monitoren. Det eneste vi altså trengte å gjøre var å bytte URL en i eksempelet med URL en til updatedb.php. Da kjøres filen og vi får vist beskjeden den sender i monitoren. Vi testet først uten bruk av temperatur sensoren. Ergo definerte vi verdien selv i URL en. Dette fungerte uten problemer. Vi prøvde deretter med sensoren ved å legge til currenttemp etter URL en i addparameter metoden. Da fikk vi en feilmelding om at metoden ikke kan motta double verdier. Dette synes vi var merkelig ettersom currenttemp er en String. Vi antok at det var grunnet + operatoren, så vi lagde en String vi kalte URL og la currenttemp til enden av denne. Vi la strengen URL til addparameter og ved neste test var målinger fra sensoren lagret i databasen. Figur viser metoden fra hovedskissen som sender data til databasen. 56

61 Prosessdokumentasjon Figur: Hovedskissen Console Som man kan se i figur , brukes Console der det vanligvis ble brukt Serial. Dette fordi vi installerte skissen over internett og da brukes Console for kommunikasjon. Det er nødvendig at pc en man skal installere skissen fra, er koblet mot samme modem som Arduino en. 57

62 Prosessdokumentasjon 4.6 Prototyping- og designfase Designprosessen startet etter at prosjektbeskrivelsen var klar, og vi hadde vært i møte angående kravspesifikasjonen. Ut ifra disse og egne ideer, startet vi med å tegne enkle skisser av BassengWeb (figur 4.6.1). Noe som kommer frem av i skissen, og som også er et viktig element i eksisterende løsning er den globale menyen. Siden vi skulle lage en forholdsvis liten applikasjon, ønsket vi å holde navigasjonsmulighetene til et minimum. Videre begynte vi å bruke Balsamiq (figur 4.6.2) for å se videre potensiale. Her la vi inn flere av detaljene som kom frem i skjemaene vi hadde mottatt av NIH, og lekte oss med hvordan det vi lagde ville fungere i praksis. Samtidig som vi holdt på med dette, kom det også ønsker fra NIH om å ha med flere skjemaer de brukte, og vi måtte se hvordan dette ville fungere, særlig med tanke på størrelsen til menyen. Da programmeringen var godt i gang, kunne vi etablere et endelig design (figur 4.6.3). Fra NIH kom det noen endelige ønsker, og vi fikk inkludert disse inn i designet. For å få alle valgene i menyen på en rad, uten at det ville føre til plassproblemer, jobbet vi mye navnene. Da NIH også ville ha med skjema over helgevakten, ble vi nødt til å endre designet av menyen litt, slik at valget for vakt nå går ned i en rullgardin. Figurene under viser designprosessen illustrert ved å sammenligne vannmåling fra det var en skisse og frem til endelig løsning, som de i dag bruker ved NIH. 58

63 BassengWeb - Hovedprosjekt ved HIOA 2014 Figur 4.6.1: Skisse av Bassengweb Prosessdokumentasjon Figur 4.6.2: Balsamiq Figur 4.6.3: Endelig design 59

64 Prosessdokumentasjon 4.7 Dokumentasjonsfase Da vi startet med hovedprosjektet ble vi enige om å jobbe så jevnt som mulig med alt av dokumentasjon. Altså ønsket vi å se på det som en pågående prosess gjennom hele semesteret, fremfor å måtte haste mot slutten. Dette så vi på som verdifullt, ikke bare fordi det er mye som skal dokumenteres, men også fordi det kan lønne seg å skrive om ting mens de enda er ferske i minnet. Dette gjelder da især prosessdokumentasjonen. Vi disponerte alle oppgavene så tidlig som mulig, og dersom noen i gruppen ikke hadde nok å gjøre på de resterende oppgavene kunne de alltid sette i gang med dokumenteringen. Fristen vi satte for å være ferdig med prosessdokumentasjonen var uke 18 og for sluttdokumentasjonene var uke det uke 20. Det var litt igjen å skrive i de forskjellige dokumentasjonene siste uken, men ikke i noe stor grad. Vi hadde altså den tiden vi trengte til kvalitetskontroll av dokumentasjonen. Selv om vi gjorde oss ferdige med styringsdokumentene tidlig i semesteret, var fristen vi satte på disse også i uke 18, dette grunne prosjektdagboken. Som naturligvis måtte oppdateres helt mot slutten av prosjektet. Vi har altså i dette prosjektet forsøkt å hele tiden gjøre så mye som mulig. Tidlig i semesteret var det utfordrende å skrive om en prosess som så vidt hadde begynt. Men vi kunne i hvert fall disponere oppgaven og jobbe med å lage en struktur som var passende og fleksibel dersom ting skulle bli annerledes enn antatt. Da slutten av prosjektet nærmet seg var det veldig godt å skrevet ferdig om det vi hadde jobbet med i starten, slik at vi kunne fokusere på det som måtte skrives om etter overlevering av systemet. 4.8 Avgjørelser I planleggingsfasen ble det naturligvis foretatt flere avgjørelser av oss i gruppen. Vi har alltid diskutert ting grundig, og videre har det vært viktig for oss å veie alle alternativer så grundig som mulig. Med dette nevnt, så har vi alltid hatt en tendens til å bli enige, dette er nok noe av grunnene for at vi har holdt ut 60

65 Prosessdokumentasjon sammen gjennom flere prosjektet. Ved eventuelle spørsmål var det naturlig for oss å høre hva veileder hadde å si før vi valgte å slutte de store konklusjonene. Det har aldri oppstått konflikter hva gjelder valg av oppgaver, design, hvilket programmeringsspråk vi skulle bruke også videre. For å finne ut om applikasjonen vår trengte endringer var vi, fremfor å komme med personlige meninger, fokusert på å få brukerens tilbakemelding. Videre har alle på gruppen hele tiden hatt kundens interesse i fokus, fremfor å trumfe igjennom personlige preferanser. Kravspesifikasjonene vår var det vi jobbet etter, og når vi først var blitt enige om hva som skulle inngå her, hadde vi ett felles mål vi ønsket å jobbe mot. 4.9 Testing Testingen bestod av testing av kode og brukertesting. I testingen tok vi for oss som overordnet for BassengWeb: Funksjonalitetstesting: Denne tok for seg å avdekke feil og mangler som vi hadde gått glipp av under utviklingen. Dette gjaldt da feil knyttet til validering, lagring, søk o.l. som for eksempel navn som ikke stemte overens i view og controller. Testene ble foretatt fra en brukers perspektiv og ble gjort for alle funksjoner i applikasjonen. Kompatibilitetstesting Vi utførte tester på applikasjonen i forskjellige nettlesere for å se om funksjoner og design klarte å holde seg konsistent mellom disse. Vi testet da Firefox, Chrome, Opera og IE. Designet og navigasjon opplevdes likt, vi testet også applikasjonen på mobiltelefoner og for å se til at den fungerte som planlagt. Tabellene i applikasjonen er ikke mobilvennlige, og disse er brukt for ti siste timemålinger, søk og endringslogg. Grunnen til dette er at tabellene er statiske entiteter og med dette ikke skalerer bra på mindre skjermer. Vi utforsket noen alternative løsninger, men disse endte opp med å skape utfordringer da titlene var for lange. Men i all hovedsak fungerte det å lagre oppgaver og målinger, og dette var det viktigste med kompatiblitestestingen. 61

66 Prosessdokumentasjon Sikkerhetstesting Her testet vi applikasjonen ved at vi prøvde å hacke den, altså vi prøvde SQL-injection, URL-injection, logge på med deaktiverte brukere (hvilket vi fikk til, før vi fikset det). Arduino Testingen avslørte at målingene som ble lagret i databasen ikke var korrekte, grunnet for lang skjøt fra stikkontakten til plasseringen av Arduino og usb-adapteren, dette resulterte i at kun verdien -127 ble lagret. Ved å bytte på kablingen, fikk man løst dette problemet. Brukertesting Brukertestingen avslørte problemstillinger som ikke var like lette å oppdage fra en utviklers perspektiv. Hovedsakelig var dette navnet 3. Timemåling som ble omgjort til vannmåling etter brukernes ønske. Knappene for Timesmåling viewen ble med dette endret, slik at de skulle bli mer intuitive for brukeren. Videre var det et par ting til vi gjorte endringer på, samtidig som brukertesten faktisk gjorde at vi oppdaget et par bugs. Vi ønsket å få så mye som mulig igjen for brukertesten vår, altså jo mer tilbakemelding fra testpersonene jo bedre. Dette føler vi var tilfellet i høy grad, ettersom testen tok for seg hele systemet, i tillegg til at vi fikk teste systemet på brukere som hadde god tid. Testingen er nærmere beskrevet i Testingsdokumentasjonen Sluttfasen/Overlevering De siste ukene før overleveringen jobbet vi tett sammen med oppdragsgiver, vi satt for det meste og jobbet med deres IKT avdeling. Dette var fordelaktig fordi vi kunne få hjelp til å bruke deres systemer og samtidig hele tiden få tilbakemelding dersom vi foretok oss noen endringer. Brukerne av 62

67 Prosessdokumentasjon applikasjonen kunne også se hva vi hadde gjort og kunne dermed i dynamisk stil kunne fortelle oss om noe ikke stemte, noe manglet eller om noe måtte endres. Denne fasen bestod også av å sette opp Arduino i det tekniske rommet under bassengene. Her fikk vi tak i en koblingsboks som er lufttett, noe som er nødvendig da luftkvaliteten i dette rommet er mindre enn optimal. Overleveringen fant sted fredag 2. mai med plan om at NIH skulle sette applikasjonen i drift førstkommende mandag, altså den 5. mai. Dette gikk som planlagt og systemet var oppe og gikk innen fristen. Etter overleveringen var vi der i par ekstra dager hvor vi tok imot tilbakemeldinger om produktet, eksempelvis at de ti siste målingene under timemålinger burde vises. Ved å være til stede et par dager ekstra kunne vi raskt og enkelt rette opp i feil som ikke ble oppdaget tidligere Oppsett av server og database Vi fikk en virtuell Windows Server 2012 maskin som skulle stå for å hoste vår applikasjon på NIH sitt nettverk. Her fikk vi en mulighet til å installere det vi trengte siden dette var en ren installasjon. Vi startet med å sette opp WampServer. På Wamp måtte vi legge til nødvendige ekstensjoner til PHP for å kunne ta i bruk kommandoer til MSSQL databasen, i tillegg til at vi måtte legge til et alias for NIH mappen i Wamp i Apache slik at den skulle kunne aksesseres fra andre maskiner på nettet, og ikke bare den hvor det var installert. Deretter installerte vi vår applikasjon her. En utfordring vi møtte på var å finne riktig driver for at PHP skulle klare å kommunisere med NIH sin database server, dette er en MSSQL 2008R2 server, noe vi klarte å løse etter at vi fant riktig driver fil på nettstedet til Microsoft. Selve innloggingen på databaseserveren var noe mer problematisk da dette gikk gjennom Active Directory, noe vi ikke hadde gjort før, problemet vi støtte på var at databaseserveren ikke ville akseptere login for vår serverbruker. I tillegg om vi fant ut av at noe var feil så måtte vi gjennom en middelmann for å kommunisere med databaseansvarlig, noe som gjorde at det tok mer tid. Etter at 63

68 Prosessdokumentasjon innloggingsproblemene var løst, dette gjorde vi ved å sette opp en egen bruker i MSSQL som vi kunne ta i bruk, så lastet vi opp seneste versjonen av vår database og koblet til. Når alt dette var utført så fungerte applikasjonen som planlagt, den klarte altså å lagre, redigere og slette, og kunne med dette overleveres til oppdragsgiver. Vi tømte routines og change_log tabellene i databasen etter at testingen var gjort og la inn en root bruker som kunne brukes for å opprette de første brukerne for bassengansvarlig Faglige utfordringer Laravel 4 Å lære seg ett nytt rammeverk er ikke enkelt, man kan nesten si at det er ett programmeringsspråk i seg selv. Fra tidligere av har vi hatt grunnleggende programmering i PHP og HTML. Det var altså mye nytt for oss å sette oss inn i når det kom til Laravel. MVC metoden er også noe ingen av oss hadde kjennskap til fra før av, dette var i og for seg greit ettersom vi ønsket nok utfordringer for fem personer. Det å lære seg Laravel medførte altså, for oss, en bratt læringskurve og en interessant oppgave. Måten å programmere på var helt ny og alt var MVC- og objekt-basert. Vi forutså ikke at den første måneden i prosjektet skulle gå med på å sette seg inn i det grunnleggende som å få MVC lagene til å kommunisere ordentlig, men det gjorde det altså. De første ukene hadde vi problemer med å lese ut en variabel definert i controller. Vi ble nødt til å tilpasse oss, noe som gikk helt greit og vi kom oss i gang med programmeringen i god tid. Vinteren 2014 var Laravel 4 relativt nytt, noe som medførte en liten brukerbase som igjen gjorde at det å søke etter løsninger og hjelp ikke var så lett som når man bruker de mer etablerte programmeringsspråkene. Når vi satt fast med noe, var det altså litt ekstra utfordrende å finne løsninger. 64

69 Prosessdokumentasjon Det fantes dog en del ute om Laravel 3, men for oss som ikke var kjent med Laravel 3 var det ikke alltid til like stor hjelp i praksis. Nettstedet stackoverflow, som er en avgren til stackexchange, har vært til stor hjelp for oss. På denne siden kan man nemlig poste spørsmål som andre i brukerbasen kan svare på, vi har fått mange gode tilbakemeldinger ved bruk av denne tjenesten. Etterhvert begynte det å føles mer og mer naturlig å programmere i Laravel, og egentlig før man visste ordet av det så ble det plutselig lettere og lettere. Denne mestringen nådde vi halvannen måned etter vi startet å programmere. Derifra gikk det raskere og raskere å programmere i det nye språket. En av de større utfordringene vi møtte på var hvordan vi skulle få databasen til å lagre dynamisk, altså uten å kreve at hele html-formen var utfylt. Etterhvert fant vi en løsning som gjorde dette mulig på en kjempeenkel måte ved bruk av en ny databasearkitektur. Denne nye løsningen bestod av en foreach-løkke som tok hvert felt i html formen og opprettet en rad i routines tabellen for hver av dem. Dette Samtidig som en annen løkke sjekket om noen av avkrysningsfeltene var tomme (da de returner en tom string selv om de ikke er merket, noe som ser stygt i databasen), fant den slike, så slettet den disse fra matrisen før de lagret. Det å sette seg inn i Eloquent var også litt av en utfordring som fikk oss til å benytte Laravel sin simple query builder, Fluent. Dette er stortsett bare en klasse man benytter for å skrive SQL spørringer mot databasen i stedet for å håndtere database-objektene som modeller Fra Fluent til Eloquent Etterhvert som vi ble bedre til å kode i Laravel kom vi frem til at vi skulle bytte ut bruken av Fluent med Eloquent modeller. Dette fordi den forkorter kode, gjør det lettere leselig og generelt er en mer elegant måte å håndtere en database på. Vi satt oss ned, opprettet de nødvendige modell filene med nødvendige parametere, og deretter satte vi i gang med å prøve oss frem. Til vår overraskelse viste det seg i ettertid å være enkelt når man ikke 65

70 Prosessdokumentasjon lenger var helt ny, og det medførte at koden ble mer fleksibel. For eksempel så startet vi med å prøve ut applikasjonen tilknyttet til en Mysql database. Migreringen fra Mysql til MSSQL i Fluent hadde krevd en god del rekonstruksjon av koden, Eloquent eliminerte dette problemet da den som nevnt lenger ned benytter en databasedriver som er kompatibel med Mysql, Pagesql og MSSQL(sqlsrv). Dette gjør at spørringene ikke trengs å skrives om på, dette fordi de egentlig bare er funksjonskall til en predefinert modell som ens egne modeller utvider Databasearkitektur Med vår opprinnelige databasearkitektur var ikke løsningen vår spesielt skalerbar, da det å legge til oppgaver og målinger i grunn krevde at man måtte rekonstruere hele databasen. I og med at det var gått hele to år siden vi hadde hatt faget databaser, var vi relativt rustne på hvordan man skulle konstruere en arkitektur. Dette medførte at vi ikke var rutinerte på å generalisere, noe som gjorde at vi i første sprint endte opp med over 18 tabeller for forskjellige målingene og oppgavene. Når vi ser tilbake på dette skjønner vi jo naturligvis at så mange tabeller er ett eneste stort rødt flagg i seg selv. Når vi ser tilbake på dette nå i ettertid, ser vi at dette naturligvis ikke var optimalt. Vi innså etterhvert at indeksering i denne arkitekturen hadde blitt ett stort problem, og ikke minst hadde det vært mye jobb å legge til nye oppgaver og målinger. Heldigvis for oss var det mulig å få litt veiledning fra Torun Sundby, foreleseren vi hadde i databaser for to år siden. Vi satt oss ned og tok en prat med henne hvor vi kom vi fram til at vår arkitektur var dårlig og måtte bygges opp fra bunn av. Med en lyn repetisjon så strukturerte vi vår nye database basert på generaliseringer som gjorde at vi hadde totalt 8 tabeller. Videre gjorde vi det slik at insetting av nye aktiviteter i tabellene kunne gjøres problemfritt og uten krav til rekonstruksjon. Med dette sa vi oss fornøyde, og tok den i bruk. Dette er den samme arkitekturen vi bruker per dags dato. 66

71 Prosessdokumentasjon Mysql til MSSQL(SQLSRV) Siden starten av prosjektet hadde vi store utfordringer med å ta i bruk MVC rammeverket Laravel. Dette førte til at vi gikk for å bruke Mysql, selv om vi senere skulle konvertere databasen om til MSSQL. Da den tid kom bød dette på problemer. Heldigvis gjorde verktøyet Microsoft SQL Server Migration Assistant for MySQL jobben enkel. Siden vi brukte Eloquent trengte vi ikke å gjøre om noen SQL-spørringer, siden Eloquent genererer sql-spørringer basert på hvilken database driver som er aktiv i Laravel sin database konfigurasjon. Når det gjelder rapport generering i PDF og Excel, i tillegg til Google Chart som er programmert i PHP, så har vi trengt å konvertere funksjoner fra Mysql til Sqlsrv for at PHP skal ha kunnet hente data fra MSSQL databasen. Figur viser hvordan PHP med sqlsrv sender spørringer til en SQL server. Mange av funksjonene har vært enkle å endre på. Eksempel: Sqlsrv_num_fields til mysql_num_fields som returnerer antall kolonner. Figur SQLSRV 67

72 Prosessdokumentasjon Arduino Yún Arduino, slikt som Laravel, var et helt nytt tema og som ingen på gruppen hadde tidligere erfaring med. Arduino Yùn var også ny på markedet, som kunne tilsi at ressursene var begrenset. Arduino har imidlertid dokumentert Yún en i stor grad og mesteparten av kunnskapen vi trengte kunne vi hente fra hjemmesiden deres. Det mest utfordrende med prosjektet var å vite hvordan man skulle gå frem for å løse oppgavene. Man var ikke ekspert etter å ha gjennomgått guiden som lå på hjemmesiden til Arduino, og mange av de eksterne ressursene omhandlet skisser for andre Arduino er. Dette var ikke alltid så lett å få øye på, og det hendte til tider at vi brukte metoder som var utdaterte for Arduino Yún. Det var også veldig få ressurser om ph sensoren, og det var ikke tilstrekkelig med det vi fant på hjemmesiden til Atlas Scientific. Vi fant flere eksterne eksempler, men alle omhandlet andre Arduino er og var mye mer avansert enn vi trengte å forholde oss til. Noen av kodesnuttene inneholdt brukbar kode, også for yúnen, og dette ledet frem til en fungerende løsning. Plasseringen av Arduino en var problematisk da luften i det tekniske romet var veldig syrlig. Vi ble fortalt at ting i rommet ruster fort og vi hadde ikke kunnskap til å vite hvor lenge Arduino en faktisk kom til å leve. Vi kom frem til at en luftett koblingsboks var den beste løsningen for utvidet levetid. Den største og nærmest eneste faglige utfordringen var altså at vi støtte på problemer som lå utenfor vår kunnskap. Vi endte derfor til tider opp med å gjøre det vanskeligere for oss selv. Det at ph kretsen sluttet å respondere kom som et sjokk og var svært skuffende. Vi hadde ikke de tekniske ferdighetene eller kunnskapen til å forstå problemet og supporten til Atlas Scientific mente at den mest sannsynlig var ødelagt. Det skjedde også såpass sent i prosessen at vi ikke kunne kjøpe ny. 68

73 Prosessdokumentasjon 5. Designprosess 5.1 Design Utseende BassengWeb ønsket vi fra starten av skulle ha et enkelt utseende (figur 5.1.1), og ville derfor fokusere på brukervennlighet fremfor finurlige finesser. Detaljer rundt applikasjonens utseende, og veien mot endelig design beskriver vi videre på de neste punktene. Ved et første øyekast vil vi allikevel kunne si at BassengWeb etter hvert har blitt en oversiktlig applikasjon, som også er lett å navigere seg rundt i. Figur: Inntrykk av utseende 69

74 BassengWeb Hovedprosjekt ved HIOA 2014 Prosessdokumentasjon Logo Siden vi har laget en applikasjon for målinger av svømmebasseng, vil vi i all enkelhet ha en logo (figur 5.1.2) som viser nettopp at vi her har med vann og gjøre. Derfor fant vi det naturlig å velge en blå logo. Vi har ved siden av å velge en lettlest skrifttype, også lagt ved et symbol som består av tre firkanter i ulike blåtoner. Dette for å understreke navnet «BassengWeb». Figur BassengWeb Logo Fargevalg og skrifttype Vi ønsket å lage en enkel web applikasjon med fokus på brukervennlighet. På grunn av dette valgte vi å bruke mørk skrift på lys bakgrunn, og ellers ingen spesielle finesser som spenstige skrifttyper. Dette valgte vi på et tidlig tidspunkt, og vi har vært fornøyd med hvordan resultatet har vært med tanke på lesbarhet. Siden BassengWeb er en web applikasjon, og alle nettlesere har funksjoner der man selv kan velge størrelsen på skriften, så vi det som unødvendig å legge til en slik tjeneste som en tilleggsfunksjon. Det var viktigere å fokusere på at applikasjonen skulle være lesbar for alle, vi tok derfor valget om tydelig og mørk skrift på lys bakgrunn tidlig i prosessen. Vi har ikke endret på dette i etterkant. 70

75 Prosessdokumentasjon Ved tilbakemelding, som at brukeren ikke har skrevet inn desimaltall der det er nødvendig, eller at lagringen har vært vellykket, har vi valgt å bruke grønn skrift for positiv validering, og rød for negativ validering. Vi har altså valgt å basere dette på trafikklysprinsippet, der alle er kjent med at grønn står for klart, og rødt for stans. Når vi ser vi på forskjellen mellom designet slik vi så det for oss i starten og ved endelig resultat, er det ikke store endringer som er blitt gjort med tanke på fargevalg og skrifttype. Figur: Balsamiq rapport 71

76 Prosessdokumentasjon Figur: Dagens rapport Forskjellene ligger hovedsakelig i plasseringen, videre ser vi at begge designene er enkle (figur og figur ). Vi ser også at det endelige resultat er mer åpent, og applikasjonen har blitt lysere Plassering av innhold Vi har valgt å lage en informativ toppmeny, slik at det skal være enkelt å navigere seg i webapplikasjonen ut i fra hva man skal registrere; timemåling, vannmåling, oppgaver, rutiner (dagvakt, kveldsvakt og helgevakt), vask med CM, søk, rapport, diagrammer, min side (med navnet til påloggede) og logg ut. For hvert valg man tar, vil man få opp aktuelt skjema. Registrering av timemåling, vannmåling og oppgaver består alle av å fylle inn forskjellige variabler, og dette skal skrives inn i bokser, videre skal dette lagres ved å trykke på «Lagre» nederst til høyre. Dagvakt, kveldsvakt, helgevakt og vask med CM består alle av en sjekkliste, slik at man her huker av for hvert gjøremål som blir gjort, etterfulgt av å lagre ved å trykke på «Lagre» nederst til høyre. Søk, rapport og diagrammer består av å huke av og fylle ut for valg som er aktuelt for ditt søk, eller resultat av utskrift av rapport eller diagram. Tar vi utgangspunkt i designet fra Balsamiq-skissene og 72

77 Prosessdokumentasjon endelig resultat, har vi ikke gjort de store endringene med tanke på plassering. Vi har endt opp med en mer åpen og luftig applikasjon, og mye av grunnen til dette er bestemt av valgmulighetene man har i Balsamiq, som består av mange ferdige komponenter, sammenlignet med programmeringen, der vi har kunne velge alle detaljer selv. Vi har under hele prosessen vært veldig opptatt av plassering, og at det skal være lett å finne frem i applikasjonen. I bruketestingen kom det klarere frem hvordan resultatet fungerte, og vi så raskt at brukerne fant frem lett i den globale menyen. Da de hadde fylt ut et bestemt skjema, var det heller ikke problematisk å finne frem til lagreknappen. Utfordringene lå derfor ikke i plasseringen av innholdet, men heller hos tilfeller av litt dårligere valg av navn i menyen, noe vi fikk rettet opp i enkelt og smertefritt Knapper For hver operasjon som blir gjort må man lagre, hente eller søke. Ut i fra dette har vi valgt å bruke knapper med de selvforklarende navnene: «Lagre», «søk» og «hent». Under rapport har vi også en knapp for Pdf og en for Excel, som bestemmer hva slags fil brukeren ønsker å hente rapporten sin ut i. Disse valgene tok vi blant annet for å ikke skape usikkerhet for brukere med lavere IT-kunnskaper, og for å sikre at brukerne raskt kan lære seg å bruke applikasjonen. Den skal ligne på noe de er kjent med fra før av. Derfor skal lagring gjøres med lagre-knappen, i stedet for en knapp som for eksempel sier «skriv til database». Brukertesten vi utførte på brukerne av applikasjonen viste at knappene var lette å forstå seg på, og de fant det lite utfordrende å avslutte oppgaven de var satt til å gjøre, da noen av oppgavene som ble gitt gikk ut på å registrere målinger og oppgaver, samt skrive ut en rapport. Det var ved et sted knappene skapte usikkerhet i brukertesten, og det fant vi under timemåling. Her hadde vi satt opp to knapper som begge het lagre. Den ene skulle være for lagring av vannmålinger, og den andre for lagring av luftmåling. Grunnen til at vi i utgangspunktet løste det på denne måten hadde 73

78 Prosessdokumentasjon med hvilken database resultatet skulle skrives inn i, men dette var vanskelig å se for brukeren da han skulle lagre målinger for både vann og luft. Vi har derfor løst dette ved å endre navnene på knappene, slik at de nå heter lagre vannmåling og lagre luftmåling. Under ser man hvordan knappene ved vannmåling har endret seg fra design i startfasen (figur ) og frem til endelig løsning (figur ). Figur: Balsamiq timemåling 74

79 Prosessdokumentasjon Figur: Dagens timemåling Ikoner Ut ifra valgene i menyen, har vi kommet frem til disse ikonene. Valgene er tatt ut ifra hva vi mener hjelper brukeren best med tanke på hva bildet representerer (figur 5.1.6). Timemåling: Temperaturmåler, viser til at man her skal måle noe. Vannmåling: En bølge og et celsiustegn, for å vise måling av blant annet temperatur i vann. Oppgaver: Penn og papir, symboliserer at vi her skal noterer ned gjøremål og oppgaver. Rutiner: En hake, som indikerer av man her huker av for noe. Vask med CM: Feiebrett, viser at dette har med renhold å gjøre. Søk: Forstørrelsesglass, symbol for å kunne søke etter målinger og oppgaver. Rapport: Et skrevet ark, skal forestille en rapport. Diagram: Kakediagram, viser til at det er her man får ut diagrammer. Min side: Et hode, symboliserer at det er en person som er pålogget Navigasjonsmeny 75

80 Prosessdokumentasjon Brukertesten viste oss at brukerne ikke hadde problemer med å forstå symbolene, og at de passet fint til teksten de tilhørte. Allikevel mente de aller fleste at de fant størst hjelp i teksten, og at de egentlig ikke så nøye på ikonene. Hadde vi brukt ikonene alene, uten noen form for tekst, hadde det nok spilt en større rolle å velge gode ikoner. Men dette var noe vi mente allerede i designprosessen ikke ville holde, fordi det ville gjøre applikasjonen mindre brukervennlig. Så lenge det er menyvalg brukerne på forhånd er kjent med, syntes vi det var unødvendig å skulle få dem til å bli kjent med nye bilder i stedet. 5.2 Informasjonsarkitektur Organisering Vi har organisert siden ved å bruke en global meny med ni valg. Hvert punkt i menyen leder til en ny side for det aktuelle valget. Dette gjør at brukeren ikke trenger å forholde seg til noe annet enn det en ser i denne menyen. I løpet av hele prosessen har vi vært bestemte på at applikasjonen skal være oversiktlig, dette løste vi best mulig ved å benytte oss av denne løsning i dette tilfellet. Vi har på grunn av dette hele tiden bearbeidet menyen til vi var helt fornøyde, desto viktigere var det at brukerne var helt tilfreds Navigering Vi har valgt å bygge opp siden ved bruk av et globalt navigeringssystem. Dette fungerer ved at menyen brukeren ser øverst på siden alltid vil forholde seg lik. Det som vil endre seg er innholdet på siden, ut ifra hvor brukeren ønsker å gå. Siden applikasjonen blir så enkel, ser vi det ikke som nødvendig å bruke andre navigeringshjelpemidler, da den globale menyen nettopp er dette i seg selv. Brukeren trenger ikke å bruke tilbakeknappen, hjelp som brødsmulesti, eller komme frem til informasjon ved hjelp av noe annet en menyen, der alle valgalternativene er synlige. En del av dette nevnes også i avsnitt om WCAG og navigering. 76

81 Prosessdokumentasjon Navngivning og labeling; endre tekst Menynavnene er gitt ut ifra funksjonen på hvert enkelt valg. Det skal være enkelt å finne frem til skjemaet for kveldsvakten, da menyvalget heter kveldsvakt. Timemåling indikerer at dette skal gjøres hver time, og under søk kan man søke opp informasjon. Disse navnene har blitt basert på skjemaene som har vært i bruk hos NIH tidligere. Det kom frem i brukertesten at det var ønskelig å fortsette å bruke navnene, da de alt var kjent med disse. I tillegg til dette, har vi brukt ikoner. Hver av dem representerer hvert enkelt valg, og de skal hjelpe brukeren til å kunne assosiere seg frem til riktig sted. Eksempler på dette er temperaturmåler for valg av måling, et feiebrett for valg av vaskeskjema under kontroll med CM, og en sol for dagvakt og måne for kveldsvakt. Ikonoversikten finne i punkt Ikoner Søk Ut ifra hvordan siden er bygget opp, da all navigering kun skjer ut ifra de åtte valgene i den globale menyen, har vi valgt vekk muligheten for å kunne søke seg frem med hjelp av et søkefelt. Et slikt valg ser vi rett og slett på som redundant. Vi bruker allikevel en søkemotor under «rapport» og «diagram», men dette er søk i den forstand at brukeren skal hente frem rapporter og diagrammer over tidligere målinger og registreringer som har blitt gjort, og ikke som en del av å finne frem i applikasjonen generelt. 5.3 Universell Utforming Forskrift om universell utforming (uu) av IKT trådte i kraft 1.juli 2013 (Direktorat for forvaltning og IKT, Difi.no) og alle nye IKT-løsninger rettet mot allmennheten skal være universelt utformet, både for offentlig og privat sektor. Derfor var kravet om universell utforming i kravspesifikasjonen vi mottok hos NIH ikke bare et krav fra dem, men også et krav bestemt i forskrift på grunnlag av diskriminerings- og tilgjengelighetsloven. 77

82 Prosessdokumentasjon Underveis i prosessen var vi i samtale med NIH, som trakk universell utforming fra kravspesifikasjonen. Grunnen til det var at BassengWeb ikke skulle være rettet mot allmennheten, og de ansatte ved bassenganlegget måte være helt funksjonsfriske for i det hele tatt å kunne utføre jobben sin. Allikevel anså vi det som viktig å levere en applikasjon som ville være god for de aller fleste, og har brukt WCAG som retningslinje, for å få et mest mulig universelt utformet grensesnitt. En del av WCAGs kriterier inngår forsåvidt i kravene til universell utforming WCAG 2.0 og BassengWeb For å sørge for at vi fyller flest mulig av kravene til forskriften om universell utforming, bruker vi retningslinjene til WCAG 2.0 (uu.difi.no). Målet er å bestå flest mulig av de 35 suksesskriteriene, fra nivå A til AA, slik at forskriften er blitt fulgt best mulig. Det er allikevel ikke alle retningslinjene som gjelder BassengWeb, da applikasjonen ikke inneholder alle alternativene (video- og lydfiler) som er nevnt. Derfor kommenterer vi dette raskt ved gjeldene retningslinjer. 1. Mulig å oppfatte 1.1- Tekstalternativer: Her sier retningslinjene at man skal gi alt ikke-tekstlig innhold tekstalternativer, slik at brukeren kan konvertere alt innhold til formater etter eget behov. Vi har valgt å presentere alt innhold ved bruk av tekst. Der vi har brukt ikoner, er dette for å understreke teksten i menyen. Dette gjør at det skal være enkelt å formatere innholdet i BassengWeb over til for eksempel større skrift, tale eller blindeskrift Tidsbaserte medier: Applikasjonen har hverken lyd- eller videomedier. Derfor vil denne retningslinjen ikke være aktuell for BassengWeb, så lenge slikt innhold ikke eksisterer Mulig å tilpasse: Innholdet skal kunne presenteres på ulik måte, uten at informasjon og struktur går tapt. Dette har vi tatt hensyn til ved at vi har god kode. Dette fører til at koden ikke vil kunne komme i konflikt med ulike formater. BassengWeb er også en oversiktlig applikasjon, der menyvalgene er satt i 78

83 Prosessdokumentasjon rekkefølge ut i fra det som vil virke logisk for brukeren, som i dette tilfellet er de ansatte ved NIH, og menyen vil forholde seg lik, selv når man skifter valg. Dette gjør at informasjonen også vil forholde seg lik, uavhengig av formatet man bruker Mulig og skille fra hverandre: Dette er en retningslinje vi har skrevet en del om tidligere. Denne omfatter bruk av farger, styring av lyd, kontraster, endring av tekststørrelse, og bilder av tekst. Vi har valgt å bruke tydelige kontraster (5.1), som ikke vil gjøre det vanskelig for svaksynte og fargeblinde. Ellers har det blitt lagt vekt på at applikasjonen skal kunne brukes i alle nettlesere, som igjen har hjelpemiddelfunksjoner som gjør det mulig å endre blant annet tekststørrelsen. 2. Mulig å betjene 2.1- Tilgjengelig med tastatur: BassengWeb kan brukes med både mus og tastatur, eller andre fysiske hjelpemidler som fungerer som alternativ til mus og tastatur. Bruker man kun tastatur, er det blitt tatt hensyn til i designet at man enkelt kan navigere seg fra punkt til punkt, både i menyen og skjemaene, ved hjelp av for eksempel piltaster og enter. Det er ikke satt inn tidsbegrensninger på noen av funksjonene, og brukeren lagrer ved bruk av riktig knapp for dette, når han selv er klar Nok tid: Applikasjonen krever ingen bruk av medier som trenger å justeres med tanke på hastighet, eller som kan settes på pause eller stoppes. Derfor vil denne retningslinjen ikke være aktuell for BassengWeb, så lenge slikt innhold ikke eksisterer Anfall: Det finnes ikke innhold i applikasjonen som kan glimte mer enn tre ganger i sekundet, eller innenfor terskelverdiene for generelle glimt og røde glimt. Applikasjonen er ganske statisk, og eneste endring av innholdet skjer når brukeren selv velger å endre skjema i menyen Navigerbar: Navigering har vært et viktig fokus under hele designprosessen. Det skal hele tiden være enkelt å se hvor i applikasjonen man befinner seg, samtidig som det skal være lett å skifte over til et annet skjema i applikasjonen. Det skal ikke være nødvendig å bruke tilbakeknapper eller 79

84 Prosessdokumentasjon brødsmulestier, da menyen alltid vil ta deg dit du vi samtidig som den viser BassengWeb i sin helhet. Dette betyr at brukeren selv bestemmer rekkefølgen når han/hun navigerer, og er ikke avhengig av å gå en bestemt vei for å finne frem, annet enn ved innloggingen. En overskrift under hvert tema viser også hvor i applikasjonen man befinner seg. Her har vi basert oss på de skjemaene som brukes hos NIH, slik at brukerne alt er kjent med terminologi og innhold. 3. Forståelig 3.1- Leselig: Som nevnt under retningslinje 2.4, så har vi basert innholdet i applikasjonen på skjemaer fra NIH, språket er derfor valgt på grunnlag av hva brukerne fra før av er kjent med. Terminologien er faglig, men retter seg mot brukerne, og ikke utviklerne. Dette krever at den som skal bruke BassengWeb gjør dette fordi han eller hun er ansatt og drifter bassenganlegget ved NIH Forutsigbar: Når brukerne gjør et valg, er de sikre på hva som kommer. Trykker de på timemåling, vet de at de konsekvent vil få opp skjema for timemåling. Dette gjelder for alle valg i menyen. Vi har gjennom hele prosessen hatt fokus på forutsigbarhet med tanke på applikasjonen, og det skal være konsekvent at du alltid får opp likt innhold hver gang du gjentar samme handling Inndatahjelp: Formuleringene av feilmeldingene har vi vært nøye på. Dette fordi det ikke skal være noen tvil for brukeren om hva som menes med tilbakemeldingen som vises når noe ikke er som det skal. I de fleste tilfeller i BassengWeb har vi lagt opp til at man ikke kan gjøre særlig mange feil. Mye går ut på å skrive inn, eller huke av, og gjør man feil, kan dette rettes opp ved å skrive inn på nytt. En typisk feilmelding som vi så var gjengående under brukertesten, var mangel av desimaltall der dette var viktig for riktig verdi. Årsaken til dette var at de under brukertesten kom opp med egne tall, og de var gjerne runde. I praksis vil de alltid få resultater med desimaler, så dette er også en feil som sjeldent vil oppstå. Når brukeren allikevel får en feilmelding, skal det også svært lite til for at han/hun skal kunne klare å rette opp i dette. Gjerne ved å skrive inn komma, eller legge til et tall. 80

85 Prosessdokumentasjon Vi har forsøkt å forhindre at brukerne vil gjøre feil, ved å stanse opp der feilen alt er gjort, slik at de kan rette opp dette. Videre har vi utviklet en applikasjon uten «feller». Det skal altså ikke gå an å gjøre fatale feil, og alt kan eventuelt rettes opp ved å skrive inn nye verdier, eller slette de gamle (må gjøres av administrator). Ser verdiene ved en vannmåling unormale ut, vil de i verste fall måtte ta nye målinger for å se om disse stemmer overens med de forrige. Nedenfor ser man eksempler på feilmeldinger som kan oppstå, her for meldinger ved registrering av ny bruker, som gjøres av administrator (Figur 5.3.1). Figur Eksempler på feilmeldinger 4. Robust 4.1- Kompatibel Når det gjelder brukeragenter som for eksempel opplesning av tekst, har vi ikke tatt høyde for dette da brukere av applikasjonen jobber som bassengvakter, der syn og hørsel er viktig å ha inntakt. Våre skjemaer er dog markert med tilhørende <labels>, så i dette tilfellet hadde jo teknologien fungert. Start- og sluttkoder er tatt i bruk, og åpner vi ett element eller liknende, blir den også stengt. Et eksempel på dette er <div id= svart ><p>noen_tekst_her</p></div> WCAG 2.0; hvilke krav nådde ikke opp Målet til gruppa var å utforme et mest mulig universelt utformet applikasjon, og følge WCAGs nivåer A og AA. Det er dessverre noen prinsipper vi ikke har klart å følge helt, og dette er en liten oversikt over hva som ikke nådde opp. 81

86 Prosessdokumentasjon Menyen har lavere kontrast enn 5.1. Den har grå skrift på grå bakgrunn, og dette er ikke optimalt for svaksynte. Ideelt skulle den ha vært svart på hvitt, men grunnen til at vi ikke gikk for denne løsningen er fordi dette alt lå inne som en ferdig løsning i Bootstrap. Alternativet hadde vært å ha hvit skrift på sort bakgrunn, men dette ville ikke ha gjort menyen mer lesbar, og ikonene ville ha blitt mindre synlige. Applikasjonen har ikke validert 100% i W3C. Vi vet ikke hva slags konflikter dette vil kunne skape for eventuelle hjelpemidler, men vi har igjen vurdert dette som mindre kritisk, da vi er sikre på at brukerne ikke vil trenge hjelpemidler, utover at noen kan være svaksynte. Disse kan bruke verktøy som alt finnes innebygd i nettleseren, slik at de blant annet kan forstørre teksten. 5.4 Mobilvennlighet Tidligere har de ansatte ved bassenganlegget ved NIH brukt penn og papirskjemaer for registrering av målerverdier. Med dette som bakgrunn, skulle de få en web-applikasjon de kunne skrive dataene ned i, slik at det igjen ville bli lettere å hente dem frem igjen. Før vi startet brukertesten spurte vi alle om hva slags forventninger de hadde til den nye løsningen. Normalbrukerne trodde ikke de ville oppleve noen særlig stor forskjell, og syntes papirskjemaene var helt greie. Administratorene derimot hadde høye forventninger, og så frem til lettere å kunne hente gamle verdier, samt kjøre dem ut i grafer for å se variasjoner. Forskjellen er derfor at mens normalbruk forsetter å ta målinger som tidligere, vil det for de med hovedansvaret bli mye enklere å hente ut data, i og med at alt blir registrert i databasen. Dette utgangspunktet var veldig viktig å ha med da vi skulle lage designet. For web-applikasjonen må være mobil. Ved å lage en applikasjon som kun egner seg på en datamaskin, der skjermen er stor nok til å dekke alt innhold, ville dette medføre dobbeltarbeid for brukerne. I dag tas målingene i et teknisk rom, som ligger i kjelleren, en etasje under der de normalt oppholder seg på vakt. De tar derfor, med eksisterende løsning, med seg blokka med skjema på ned og noterer verdiene på stedet. Ved en stasjonær applikasjon, så måtte verdiene bli notert nede i teknisk rom på en lapp, for så å skrive dem inn når de kom opp. Det tekniske rommet er veldig varmt og fuktig, og alle kjemikaliene som brukes 82

87 Prosessdokumentasjon gjør også at rommet er fylt av tunge gasser. Her er det med andre ord umulig å ha elektronisk utstyr, og ved tidligere forsøk, har fukt og gasser «spist» opp det som finnes av metall i maskinene. Derfor har vi måtte lage en applikasjon som også egner seg godt til mobilt utstyr som smarttelefoner og nettbrett. Da kan de registrere verdiene på disse, uten at de trenger å oppholde seg i teknisk rom mer enn den lille tiden det tar å gjøre målingene Designet av mobilversjonen For at applikasjonen skal fungerer best mulig for mobile verktøy, har vi sørget for å tilpasse BassengWeb slik at innholdet blir lett leselig. Applikasjonen har samme utseende på mobilen som på stasjonær datamaskin. I stedet for at innholdet vises i to rader (figur ), slik man får det opp på en større skjerm, må man i mobilversjonen scrolle nedover, og man får informasjonen på en og en rad nedover. Menyen er endret i mobildesignet. Den finner man under knappen øverst i høyre hjørnet med tre streker. Dette menyikonet er veldig mye brukt, og vi har tenkt at denne skal være enkel å finne fordi brukeren gjenkjenner knappen. Menyen er listet nedover (figur ) slik at man får den listet opp ved å scrolle nedover. 83

88 Prosessdokumentasjon Figur: Vannmåling Figur: Navigasjonsmeny 84

89 Prosessdokumentasjon 6. Kravspesifikasjonen og dens rolle 6.1 Endringer Kravspesifikasjonen har vært noe vi har fulgt nøye under hele prosjektet, det har vært veldig viktig å få de viktigste funksjonalitetene på plass. Videre var det også viktig å sette de funksjonalitetene med lavere prioritet inn under utvidelser slik at ikke disse blir glemt. Endringene som ble foretatt er knyttet til de med lavere prioritet som er nærmere beskrevet under punkt 5.2 i produktdokumentasjonen. Endringene er knyttet til innlogging med active directory, og varselmail. 6.2 Kravspesifikasjon i samsvar med det endelig produktet Kravene vi har satt for oss i samarbeid med oppdragsgiver er overholdt, de funksjonelle og ikke-funksjonelle kravene samsvarer med oppdragsgivers ønsker. 7. Om resultatet 7.1 Utbytte for oppdragsgiver Utbyttet for oppdragsgiver har vært enormt, det er første gangen de har outsourcet ett gruppeprosjekt til en gruppe fra en skole. Dette har spart dem tid og ressurser, for eksempel bare det å diskutere implementeringen av systemet vi har utviklet hadde allerede en startpris på over kroner. 85

90 Prosessdokumentasjon 7.2 Læringsutbytte Dette prosjektet har ikke kun bydd ny kunnskap hva gjelder systemutvikling, men også på prosessering. Vi har alle hatt muligheten til å utvide vår kompetanse på flere områder i forbindelse med dette prosjektet. Dette føler vi i gruppen at vi har fått til på en bra måte. Tidligere har vi hatt mindre prosjekter i forbindelse med 10-studiepoengsfag, mens nå har det vært mer tverrfaglig. Vi anser det som svært lærerikt å ha fått testet ut i praksis det vi har lært gjennom disse tre årene. Vår utfordring har vært det å kunne plukke ut det vi har lært tidligere som nå kunne være relevant for hovedprosjektet. Videre måtte vi sette oss dypere inn i forskjellige temaer, for å best kunne løse oppgaven vår. Det er mye vi har lært tidligere, som vi ikke nødvendigvis har fått testet ut på samme måte som vi fikk dette semesteret. Eksempelvis var strukturering av oppgaven vært viktigere nå enn det noen gang har vært tidligere, ettersom oppgaven har vært større. I og med at oppgaven har basert seg på selvstendig arbeid har vi nærmest jobbet som en bedrift. Med dette har vi lagt opp en egen kjøreplan utifra hva vi mente var passende og riktig. Dette har ikke minst vært interessant, men også gitt oss en litt større innsikt i hva arbeidslivet kan ha by på. 7.3 Hva kunne ha vært annerledes Det alltid mye som kunne ha vært annerledes ved et prosjekt av et såpass stort omfang. For eksempel kunne vi ha brukt plattformen.net i backend, siden den er nærmere knyttet opp mot MSSQL. Vi kunne jo forsåvidt også ha tatt i bruk andre programmeringsspråk, men vi er fornøyde med de vi endte opp med å bruke. Noe vi ikke fikk fullført var ph sensoren som ble ødelagt noen uker før implementasjon, dette grunnet tidsmangel. Dersom vi hadde hatt litt mer mer tid kunne vi ha bestilt en ny krets og fått den som en del av produktet. Men igjen, dette var ikke et krav fra kundens side. Og de har muligheten til å fullføre dette selv, dersom dette er ønskelig. 86

91 Prosessdokumentasjon 7.4 Fremtidig utvikling BassengWeb kan sies å være et ferdig produkt per dags dato, med unntak av de punktene nevnt under 5.1 i produktrapporten om utvidelser. Kildekoden er kommentert og dermed er det tilrettelagt for fremtidig utvikling, da man ikke kan se bort ifra at det vil være behov for ny funksjonalitet. Når det gjelder Arduino vil man se det hensiktsmessig at man i fremtiden legger til flere sensorer, som for eksempel ph og klor. Beklageligvis ble den ikke en del av produktet grunnet kortslutning. I fremtiden vil NIH kunne videreutvikle systemet, forhåpentligvis enkelt, ved at vi har kommentert koden og forsøkt å gjøre det så forståelig som mulig. Videre har vi forsøkt å lage en så grundig produktdokumentasjon som mulig, slik at videreutvikling er mulig dersom ønskelig. 87

92 Prosessdokumentasjon 8. Avsluttende del 8.1 Sluttord Denne prosessen har, som nevnt i kapittel 7.2, vært svært lærerik for alle medlemmene av gruppen. Vi har fått erfare hvordan det er å jobbe i samarbeid med en ekte kunde. Noe som har vært både interessant, og ikke minst verdifullt for fremtiden. Hele veien har vårt ønske vært at NIH skulle bli mest mulig fornøyd med sluttproduktet. Videre har vi også ønsket fra starten av at vi skulle klare å disponere arbeidet best mulig. At vi altså ikke skulle sittende mot våren med overraskende mye å gjøre. Dette krevde naturligvis innsats helt fra starten av, noe vi ikke angret på da vi klarte å overholde våre egne frister utover i semesteret. Nå som vi ser tilbake på prosjektet er det tydelig at dette semesteret ikke kun har handlet om denne prosessen i seg selv. Men det å kunne gjenkjenne hva vi har kunnet anvende av tidligere erfaringer fra HIOA. Vi har etter tre år ved dette studiet tilegnet oss mye forskjellige kunnskap, og vi ser at dette prosjektet var en endelig test i dette. Vi sier oss med dette godt fornøyd med prosess som har vært en interessant og lærerik erfaring. 88

93 Prosessdokumentasjon 9. Kildehenvisninger 9.1 Bibliografi 1. Visualisering: a. Spence, R. (2007). Information visualization: design for interaction (2nd ed.). Harlow, England: Addison Wesley. 2. Universell utforming: a. Sandnes, E. F. (2011). Universell utforming av IKT systemer. Oslo: Universitetsforlaget. 89

94 Prosessdokumentasjon 9.2 Kilder 1. Christopher G. Healey. (1999). Perceptual Techniques for Scientific Visualization. North Carolina State University. Hentet den fra: 2. Ann-Mari Torvatn. (januar mai 2014) Dokumentasjonsstandard for bachelor prosjekter (hovedprosjekt) for institutt for informasjonsteknologi Høgskolen i Oslo og Akershus. 3. Oppbygning av WCAG 2.0. (2014). Hentet den fra: 3. Steele, J. (2012, February 12). Why data visualization matters. Strata. Hentet November 25, 2014, fra 4. Universell utforming. (2013). Hentet den fra 90

95 Prosessdokumentasjon 9.3 Kilder for rammeverk og verktøy Sublime text Brackets Gliffy Google docs Twitter Bootstrap Laravel 4 Wamp Server GitHub VioletUML Snagit GreenShot SQL-Server Google-chart FDPF Trello NotePad++ Dropbox Balsamiq Skype Arduino: DS18B20 OneWire DallasTemperature Arduino IDE Arduino Yun

96 Produktdokumentasjon Produktdokumentasjon 1

97 Produktdokumentasjon Forord Dette dokumentet gir en oversikt over systemets egenskaper og funksjoner. Innholdet er ment for sensor, oppdragsgiver og personer som eventuelt ønsker å drifte systemet. Av lesere forventes det kunnskap om program- og webutvikling. Kildekoden er tilgjengelig her: BassengWeb kan testes ut, (Brukernavn: rootr, Passord: testing) - Denne er tilgjengelig fram til 20.juni : NB: Betegnelsene Arduino og Arduino Yún brukes om hverandre og menes det samme. Målinger i teksten er definert som fanene i BassengWeb: Timemåling, Vannmåling og Oppgaver. Oppgaver er definert som fanene i BassengWeb: Rutiner (Dagvakt, Kveldsvakt, Helgevakt) og Vask med CM. 2

98 Produktdokumentasjon Innholdsfortegnelse 1. Beskrivelse av BassengWeb Beskrivelse av Arduino Teknologier Rammebetingelser Utviklingsm iljø Nettlesere Endelig kravspesifikasjon Funksjonelle krav Brukerkrav Systemkrav Ikke - funksjonelle krav Sikkerhetskrav Rammekrav Samsvar mellom kravspesifikasjon og produkt Mulige utvidelser End ringer Kildestruktur Dalabasestruktur og oppbygging Tekn isk Arkitektur Databasestruktur Tabellforklaringer Emps Routines Tasks Task_routine Measurements Measure_routine Pools ChangeJog

99 Produktdokumentasjon 8. Beskrivelse av BassengWeb Autentisering og roller Auth Filters Min side/adminpanel Lagring av målinger/oppgaver Målinger / oppgaver Tasks Søk Søk Redigering og sletting Validering Models Rapport Excel PDF Diagram Beskrivelse av Arduino Yun Dallas Temperature Sensor D Oppkobling Gjennomgang av "LesTemperatur" Kommunikasjon Proeess og Curl Databasen Ferd ig løsning Programmet Metodene Plassering Videreutvikling Installasjon av BassengWeb Krav til installasjon Installasjonsprosessen WampServer konfigurasjon

100 Produktdokumentasjon Microsoft SQL SeN er Express Konfigurerin g av BassengWeb mot nih_ bw Innlogg ing i nettleser Feilmeldinger WampSeN e r ikonel lyser oransje Kildehenvisninger Bibliografi Kilder for rammeverk og verktøy

101 Produktdokumentasjon 1. Beskrivelse av BassengWeb BassengWeb er en web-basert applikasjon som lagrer målinger, oppgaver, og annen relevant informasjon i en MSSQL-database. Behovet for BassengWeb oppstod som en konsekvens av at det over lengre tid har blitt registrert målinger og oppgaver for hånd. Dette var ikke lengre ideelt, ettersom dette medfører fysisk rot, og utelukker muligheten for å kunne hente ut informasjonen på en dynamisk måte. BassengWeb gir brukerne mulighet til å legge inn data basert på avkrysningsruter eller inntastingsfelter. Disse kan igjen hentes ut i forskjellige formater. Dette gjøres ved å ta i bruk enten søkefunksjonen, generering av rapporter i PDF og Excel, eller visualisering av data i grafer. Videre kan man opprette brukere med to forskjellige roller, admin og user. Brukertypen admin har utvidet funksjonalitet knyttet til BassengWeb og kan opprette, redigere, deaktivere, og aktivere brukere. Admin har også mulighet til å slette og redigere målinger og oppgaver. Av sikkerhetshensyn, blir alle endringer og slettinger av målinger og oppgaver, lagret i en endringslogg. Klient (Figur 2.1): Klienten utfører en HTTP request til serveren, og mottar en view (siden brukere ser) når en bruker har fylt inn data og trykker lagre. Da blir ett nytt HTTP request sendt til serveren, den tar da de medsendte verdiene, og sender de videre inn i en controller (filene som tar seg av logikken i applikasjonen) som igjen lagrer de i databasen ved hjelp av en ORM (object-relational mapper). Deretter sender den en bekreftelsesmelding tilbake til viewen hvor brukeren kan se at lagringen er utført. Om noe er galt med dataene som blir satt inn, sender controlleren tilbake en feilmelding til view som beskriver hva feilen var, for eksempel at verdien i inntastingsfeltet ikke er ett heltall da den skal være det. 6

102 Produktdokumentasjon 2. Beskrivelse av Arduino Arduino er en mikrokontroller som kan brukes til å sanse omgivelsene med input fra forskjellige sensorer, og til å kontrollere lys, motorer og andre akturatorer. I prosjektet brukes Arduino en til å utføre og lagre temperatur verdier. Arduino gir brukerne av BassengWeb mulighet til å sammenlikne sine manuelle målinger med de automatiske målingene. Hvis brukerne har mistet en måling eller flere, kan for eksempel de automatiske verdiene brukes som backup. I prosjektet sender Arduino en temperaturverdier for hovedbasseng fra det tekniske rommet. Den er programmert til å konstant lese verdier fra temperatur sensoren og sende disse til en database via en HTTP request. I BassengWeb er det mulig søke opp disse verdiene og få dem fremstilt på lik linje med annen data. Arduino (figur 2.1): Når Arduino en har utført sin automatiske måling så sendes denne verdien til serveren via en URL som en variabel, for eksempel for 25 grader blir det seende slik ut: nihsrvv10-40/nih/public/updatedb.php?temp=25 Updatedb.php drar denne verdien ut av URLen og lagrer den inn i databasen med en SQL spørring. Figur: 2.1 Oversikt over BassengWeb og Arduino 7

103 Produktdokumentasjon 3. Teknologier 3.1 Rammebetingelser Oppdragsgiver hadde ingen betingelser for hvilke teknologier vi skulle benytte for utvikling av web-applikasjonen utenom at det skulle være kompatibelt med Windows server 2012 og Microsoft SQL server 2008 R2. Dermed valgte vi å ta i bruk php rammeverket Laravel versjon 4 for utviklingen av backend. Grunnen til at vi valgte å ta i bruk Laravel var blant annet Eloquent ORMen i rammeverket, noe som gjør det utrolig enkelt å håndtere database kommunikasjon ved bruk av modeller. Laravel tilbyr også en enkel måte å håndtere autentisering av brukere ved hjelp av den innebygde Auth klassen. 3.2 Utviklingsmiljø Utviklingen av backend i BassengWeb ble gjort i Sublime text 2, dette valget ble tatt fordi verktøyet har god støtte for utviklingen i Laravel. Blant annet støtte for blade templating enginen, noe som flere av de andre text editorene manglet. Utviklingen av frontend ble utført i text editoren Brackets. Dette er en opensource editor for frontend-utvikling, og er kraftig når det gjelder koding av html og CSS. 3.3 Nettlesere Vi hadde som mål å gjøre BassengWeb funksjonell og tilgjengelig uavhengig av nettlesere tatt i bruk da flere forskjellige nettlesere blir brukt hos oppdragsgiver. Bassengweb er derfor testet i de mest brukte nettleserne, Internet Explorer, Mozilla Firefox, Google Chrome og Opera (noe som også gjør det enda mer mobilvennelig da disse også er tatt i bruk der). 8

104 Produktdokumentasjon 4. Endelig kravspesifikasjon 4.1 Funksjonelle krav Et funksjonelt krav beskriver en funksjon eller tjeneste som systemet skal eller ikke skal tilby. Funksjonelle krav kan testes. Man kan skille funksjonelle krav inn i brukerkrav og systemkrav: Brukerkrav Brukeren skal kunne: Registrere utførte målinger. Registrere utførte oppgaver. Slette registrerte målinger/oppgaver (admin). Redigere registrerte målinger/oppgaver (admin). Søke etter registrerte målinger/oppgaver. Generere rapporter i PDF eller Excel. Se statistikk i diagrammer. Se en endringslogg for redigerte/slettede registreringer (admin). Opprette, deaktivere, aktivere og redigere brukere. (admin). 9

105 Produktdokumentasjon Systemkrav BassengWeb skal kunne: Be om innloggingsinformasjon ved oppstart av applikasjonen. Håndtere autorisasjon basert på brukertype (user eller admin). Vise statistikk i diagrammer. Generere rapporter i Excel eller PDF. Endringer og slettinger blir lagret i endringslogg. Knytte utførte målinger/oppgaver mot en bruker. Registerere informasjon fra Arduino i databasen. Arduino skal kunne: Skal sende målinger mellom bestemte tidsintervaller. Kommunisere med BassengWeb slik at målinger blir lagret i databasen. 4.2 Ikke - funksjonelle krav Web-applikasjonen sin backend skal utvikles i php5 med rammeverket: Laravel 4. Frontend skal utvikles i javascript, html5 og css3 med rammeverket Twitter Bootstrap. Web-applikasjonen skal være mobilvennelig. Google charts brukes til å visualisere data. Arduino Yun skal utvikles i C/C++. Modellering gjøres med UML - diagrammer i Violet UML Web-applikasjonen skal være kompatibel med alle nettlesere (IE, FF, GC og Opera). Kildekoden blir lastet opp i Github for versjonshåndtering. Web-applikasjonen skal være satt på oppdragsgiverens Windows-baserte server. 10

106 Produktdokumentasjon Sikkerhetskrav Brukere får tilgang til funksjonalitet ut i fra brukertypen de innehar. Redigering/sletting av målinger/oppgaver skal kun være mulig av admin. Det skal opprettes en endringslogg for redigerte/slettede målinger/oppgaver Rammekrav Systemet skal utvikles slik at eventuell videreutvikling og vedlikehold skal senere være mulig. Systemet skal stå klart i drift i løpet av Mai måned. Systemet skal kjøres på NIH sin plattform (Windows 7-64-bit og server 2008/12). 5. Samsvar mellom kravspesifikasjon og produkt Når det gjelder de funksjonelle kravene, så har vi designet applikasjonen med utgangspunkt i disse. Dette er jo tross alt den funksjonaliteten applikasjonen skal tilfredsstille. Det finnes noen funksjonelle krav vi har valgt å ikke implementere basert på hva vi har blitt enige om med oppdragsgiver, dette ser man også beskrevet nærmere nedenfor under punkt 5.2. På de ikke-funksjonelle kravene var det i hovedsak en ting vi bestemte oss for å droppe, og det var at innloggingen skulle fungere gjennom Windows Server - Active Directory. Vi bestemte oss å gjøre applikasjonen mobilvennlig da dette tillater at brukere kan benytte deres mobiltelefoner eller nettbrett for å utføre registreringene. Vi oppnådde dette ved bruk av rammeverket Twitter Bootstrap. 11

107 Produktdokumentasjon 5.1 Mulige utvidelser Muligheten til å legge til og fjerne oppgaver i applikasjonen. Brukertypen user kan endre informasjon om seg selv. Automatisk mailservice for glemt passord. Avvik beskrevet i kommentarer blir sendt til en eller flere admins via epost. Mulighet til å sortere søkeresultatene basert på verdi, ansatt, tid og dato. 5.2 Endringer Krav som ikke er dekket: Varselmail Dette er knyttet til at målinger som ble registrert med større avvik fra normale verdier. Dette ville føre til at systemet sendte varselmail til bassengansvarlig. Det var noe vi var enige om å sette inn i starten, men senere fant vi ut, med oppdragsgiver, at dette fikk dette lav prioritet i prosjektet. Dermed ble dette flyttet til mulige utvidelser. Innlogging med active directory Mens utviklingen foregikk, kom vi fram til at det var best med en egen innloggingsfunksjon da NIH har en del vikarer som kommer og går. Dette er noe som hadde påvirket arbeidsmengden til IKT avdelingen og det er lettere om en admin-bruker i applikasjonen kan håndtere dette selv. 12

108 Produktdokumentasjon Krav som har blitt lagt til underveis: Mobilvennlig Vi kom frem til at i stedet for å porte webapplikasjonen til android/ios, ville det være enklere å heller satse på å gjøre applikasjonen mobilvennelig på tvers av ulike mobile enheter da dette gjør det mulig å benytte applikasjonen på alle skjermstørrelser. En fordel med mobilvennelig applikasjon er at brukerne kan ta med seg sin mobiltelefon/nettbrett og foreta registreringene on-the-fly så lenge enheten er koblet til deres interne nettverk. For å oppnå dette valgte vi å ta i bruk utviklingen av frontend med rammeverket Twitter Bootstrap. 13

109 Produktdokumentasjon 6. Kildestruktur Nedenfor i figur 6 kan man se hierarkiet/strukturen på kildekoden for BassengWeb. Alt som vises nedenfor er filene som vi har jobbet med. Koden er strukturert etter MVC modellen, hvor modellen er i models, controllerne er i controllers og view-filene er under view. I tillegg til at rapport og diagram funksjonen ligger under public, samt skissene, biblioteker og for lagring av målinger for Arduino. Figur 6: Oversikt over kildestrukturen til BassengWeb 14

110 Produktdokumentasjon 7. Databasestruktur og oppbygging 7.1 Teknisk Arkitektur Figur: Teknisk Arkitektur Bruker gjør en forespørsel fra klienten denne går via det interne nettverket eller det trådløse interne nettverket (disse er forskjellige) til en virtuell server hvor forespørselen blir håndtert av applikasjonen. Videre kommuniserer applikasjonen med NIH sin databaseserver hvor relevant data blir lagret eller hentet. Applikasjonen sender dette tilbake i form av et HTML - dokument til nettleseren hos klienten. 15

111 Produktdokumentasjon 7.2 Databasestruktur Figur: Logisk skjema 16

112 Produktdokumentasjon 7.3 Tabellforklaringer Emps Denne tabellen inneholder informasjon om brukere registrert i systemet som navn, brukernavn og epost. I tillegg spesifiseres brukertype som definerer rettighetene til en bruker, denne kan være admin eller user. I tillegg er det en kolonne som definerer om brukerkontoen har lov til å logge inn, dette er active kolonnen, om denne er 0 (false) så får ikke bruker tilgang til applikasjonen. Passordet til brukeren er kryptert med en Laravel funksjon som hasher passordet. Til slutt inneholder tabellen informasjon om når en bruker ble opprettet og sist endret Routines I denne tabellen lagres informasjon om målinger og oppgaver som er utført. Disse blir lagret med en id, tid, dato og verdi. Deres id er linket til enten tasks eller measurements tabellen ved hjelp av hjelpetabellene (task_routine og measure_routine) som tillater at en tittel på oppgaven eller målingen blir knyttet til id en. Den lagrer også emp_id som knytter målingen eller oppgaven mot en bruker i systemet slik at man ser hvem som har utført oppgaven eller målingen Tasks Denne tabellen inneholder de forskjellige oppgavene som skal gjøres, dette er lagret med en spesifikk id og en tilhørende tittel, denne konstruksjonen gjør det enkelt å legge til nye oppgaver. Titlene på oppgaver med Dagvakt er lagret med D_tittel, mens Kveldsvakt er lagret med K_tittel også videre Task_routine Denne hjelpetabellen knytter id en i routines tabellen mot en id i tasks tabellen som har en tilhørende tittel. 17

113 Produktdokumentasjon Measurements Denne tabellen inneholder de forskjellige målinger som skal gjøres, dette er lagret med en spesifikk id og en tilhørende tittel, denne konstruksjonen gjør det simpelt å legge til nye oppgaver. Titlene på målinger med Timemåling er lagret med T_tittel, mens Vannmåling er lagret med M_tittel, til slutt er Oppgaver lagret med O_tittel Measure_routine Denne hjelpetabellen knytter id en i routines-tabellen mot en id i measurements tabellen som har en tilhørende tittel. Her blir også en basseng id knyttet mot målingen hentet fra pools tabellen, da målinger utføres på spesifikke basseng Pools Pools inneholder en id som knytter ett basseng mot ett navn, for eksempel id 1 er Hovedbasseng Change_log Denne tabellen er en endringslogg over målinger eller oppgaver som blir redigert eller slettet. Her får man hvilken routine id målingen eller oppgaven hadde, tittel, den originale verdien og den nye redigerte verdien, samt en action som forteller om den har blitt endret eller slettet. Det blir også lagret når målingen eller oppgaven originalt ble lagret, samt hvilken dato den ble endret og hvilken bruker den ble endret av. 18

114 Produktdokumentasjon 8. Beskrivelse av BassengWeb 8.1 Autentisering og roller Auth Laravel har en innebygget klasse som håndterer autentiseringen av brukere, denne klassen heter Auth. Auth blir i konfigurasjonen linket opp til databasetabellen som brukere lagres i, i vårt tilfelle er det emps tabellen. Når dette er gjort kan en kalle på klassen for å utføre for eksempel en innlogging slik som vist i figur 8.1.1: Figur: Auth klassen sin login funksjon. På figur kan vi se funksjonen som heter attempt, den sammenlikner det en bruker har skrevet inn i innloggingsfeltene. I vårt tilfelle blir disse lagret i en variabel matrise (array) som er kalt credentials, Auth sammenlikner disse med kolonnene user_name og password i tabellen emps, og om de stemmer overens returnerer den true eller 1 (betyr det samme), den tester også om brukeren sin active kolonne i emps tabellen i databasen er 0 eller 1 - mer om dette under punkt 8.2, også blir brukeren betraktet som innlogget. Når dette er gjort kan man hente ut all brukerinformasjon i emps for den innloggede 19

115 Produktdokumentasjon brukeren via Auth klassen, det er ved hjelp av dette at det blir enkelt å koble en bruker mot data som er registrert, og det er ett innebygget samarbeid med filters som vi kommer tilbake til på neste punkt. På figur kan vi også se ett sekvensdiagram som illustrerer hvordan lagene i MVC kommuniserer med hverandre når det gjelder innlogging: Figur: Sekvensdiagram for login Filters Måten Laravel håndterer forskjellige requests på er ved bruk av routes, her definerer man hvilken funksjoner som skal kalles på eller hvilke sider som skal vises basert på hva som står i URL en. For eksempel å kalle på Auth::attempt som i figur ovenfor så har vi definert den funksjonen i en controller som heter HomeController. Når applikasjonen prøver å logge inn brukeren går den altså til bassengweb/login, da reagerer routes og henter funksjonen i HomeController. Om man vil beskytte sine routes mot at ikke-autentiserte brukere kan man sette dette opp i filters hvor det er lagt inn funksjoner som for eksempel before => auth. Det denne gjør er at den sjekker om brukeren er innlogget, og om brukeren ikke er det så får den ikke tillatelse til å åpne en side som er filtrert i routes, dette beskytter mot at en uautentisert bruker for eksempel skriver bassengweb/vannmaling i URL en for å komme seg forbi innloggingsfunksjonen. Den fungerer ved at man setter routes inn i en filter funksjon som man kan se i figur 8.1.2: 20

116 Produktdokumentasjon Figur: Hvordan filter funksjonen er bygd opp Det man oppnår med dette er at om den kombineres med: Figur: En filterbeskyttelse rundt routes som kun skal fungere for innloggede brukere Om en bruker da forsøker å gå inn på bassengweb/timemaling uten å være innlogget, så sender funksjonen i figur vedkommende tilbake til innloggingssiden med feilmelding om at man må være logget inn for å se innholdet. Videre kan filters også benyttes, ikke bare til å se om en bruker er logget inn, men også til å se om en bruker har nødvendige rettigheter for å se spesifikt innhold, altså autorisering. Figur viser hvordan man setter opp dette: Figur: Filter som sjekker rollen til en innlogget bruker På samme måte som i figur så kan man legge dette filteret rundt flere routes man vil gjøre utilgjengelig for alle som ikke er admin (man bytter kun ut before => auth, med before => admin i dette tilfellet). Den sjekker ens brukertype eller rolle, og om den ikke stemmer overens med det definerte, altså user!= admin så blir brukeren sendt tilbake til sin Min side med en feilmelding om rettighetsmangel. 21

117 Produktdokumentasjon 8.2 Min side/adminpanel Det er i Min side brukere kan hente informasjon om seg selv, det samme gjelder admin. Forskjellen er at en bruker som er registrert som admin har ekstra funksjonalitet, som en user ikke har. Dette er oppretting, redigering og deaktivering av brukere. I tillegg til å se endringsloggen. På figur illustreres funksjonen for opprettelse av en bruker, aller først hentes input fra et html skjema, hvor vi utelater _token, denne brukes for CSRF(cross-site request forgery) fordi det ikke trengs i selve opprettelsen. Deretter lages en modell av emp tabellen hvor det enkelt bare kan fylles inn informasjon, som figuren viser så opprettes brukernavnet(user_name) til brukeren basert på fornavn og etternavn, nærmere plukker substr funksjonen ut første bokstav i etternavnet slik at om Ola Nordmann registrerer seg, blir brukernavnet OlaN. Dette er brukernavnet som tas i bruk ved innlogging og vises under hvilken bruker som har utført målinger/oppgaver. For passord benyttes en Laravel klasse som heter Hash, denne klassen har en make funksjon som konverterer passordet til en 60 karakter stor hash basert på blowfish chifferet, Auth tar denne i bruk automatisk når den sammenlikner. Når denne modellen kaller sin save() funksjon så gjør den en spørring mot databasen hvor den lagrer brukeren som en ny rad i emps. Videre blir brukeren opprettet som en ny bruker, også blir skaperen av brukeren omdirigert til adminpanelet, under min side med en bekreftelse om at brukeren er opprettet. Figur: Funksjonen for å opprette en bruker (valideringsbiten er klipt ut her for å spare plass, kommer til denne senere). 22

118 Produktdokumentasjon Når det gjelder redigering av eksisterende brukere så fungerer det stort sett på samme måte, med unntak av at passord nødvendigvis ikke er nødt til å endres. Funksjonen sjekker om passord feltet står tomt eller ikke og om det står tomt vil passordet forbli det som allerede er lagret. All nåværende informasjon om en bruker som skal redigeres står allerede i feltene. Figur viser funksjonen for å deaktivere en bruker, først så sjekkes det om brukeren prøver å deaktivere seg selv og om så vil brukeren få en feilmelding om at dette ikke er tillatt. Dersom brukeren som skal deaktiveres ikke er brukeren som er innlogget, så setter den verdien 0 i active kolonnen i emps for brukeren som skal deaktiveres. Brukeren som er deaktivert vil dermed få en feilmelding når personen prøver å logge inn om at kontoen er deaktivert. Aktivering av brukere er essensielt det samme, bare at man setter verdien 1 i active kolonnen i emps. Når det gjelder valget med å deaktivere brukere i stedet for å slette de, så ble dette valget tatt på bakgrunn av at om en bruker blir slettet, blir også brukerens registrerte målinger/oppgaver også slettet og dette var ikke ønskelig. Figur: Funksjonen for å deaktivere en bruker 23

119 Produktdokumentasjon 8.3 Lagring av målinger/oppgaver Målinger / oppgaver Metoden applikasjonen lagrer utførte målinger/oppgaver på er ved å kun ta avkrysningsfelter og inntastingsfelter som er fylt ut. Da ikke nødvendigvis alle målinger eller oppgaver blir gjort samtidig, var det derfor viktig at det gikk an å lagre utført arbeid i segmenter. Dette fordi en vanlig lagringsfunksjon tar alt, inkludert tomme felter. Funksjonen som er brukt ser disse tomme feltene, og fjerner disse fra matrisen før lagringen skjer, noe som gjør at man slipper nullverdier i routines tabellen for ikke enda utført arbeid. I figur kan vi se at den første foreach-løkken finner tomme felter i matrisen som henter input, og fjerner disse fra den. Deretter setter den opp en ny matrise som inneholder all data som var fylt ut, og oppretter en routine modell med dataene. Når dette er gjort opprettes en ny matrise som henter alle titlene på utført arbeid/måling i enten tasks eller measurements tabellen basert på om det var en måling eller en oppgave, den siste foreach-løkken henter ut IDene til titlene fra enten task- eller measurements-tabellen, og lagrer disse i $link matrisen, når dette er gjort så kaller applikasjonen på modellen sin attach() funksjon som lagrer dataene i databasen og samtidig lagrer relasjonene i hjelpetabellene. 24

120 Produktdokumentasjon Figur: Lagringsfunksjon til VannMåling Controlleren (her også er validering klipt ut for å spare plass) 25

121 Produktdokumentasjon Tasks I figur ser vi ett segment av funksjonen for å hente ut view-filen for KveldsVakt. Itillegg til å hente den sjekker den også hvilken dag det er, samt henter ut titlene for oppgavene som er utført for den dagen, legger den inn i $finito matrisen, og sender den med til view en. Figur: Funksjon for å hente utførte oppgaver for Kveldsvakt for dagen. Henter også dagens dato. I view-filen for KveldsVakt har vi en if (figur 8.3.3) som sjekker om dagen stemmer med når oppgaven skal vises, hvis ikke så blir det heller vist et ikon med kryss ikon der avkryssningsruten ellers er. Dersom tittelen for en spesifikk oppgave finnes i $done matrisen ($finito i controller), så får vi ett utført ikon der avkryssingsruten skal være. Om ingen av delene er tilstede vil avkrysningsruten vises. Figur: Sjekker om dager stemmer overens med når oppgaven skal gjøres, samtidig som den sjekker om den er utført basert på data hentet i figur

122 Produktdokumentasjon 8.4 Søk I utgangspunktet kan vi skille mellom user-søk og admin-søk, forskjellen er at en admin vil få mulighet til å redigere og slette målinger og oppgaver, noe en user ikke vil Søk Funksjonen knyttet til henting av data fra routines tabellen, samt hjelpetabellene er vist i figur Her utføres et oppslag mot alle dagvaktsoppgaver med D_tittel. Routine-modellen kaller på sin wherehas() funksjon som følger med Eloquent, denne henter alle rader i routines-tabellen som har en tilknytning til tasks. Videre tar den med ansatte som er knyttet mot de utførte oppgavene, sorterer de basert på dato og tid, og paginater resultatet av spørringen. Pagination er en funksjon som deler opp resultat i segmenter, i dette tilfellet 25 per side. Dette betyr at om man for eksempel har 50 rader som blir returnert, så inneholder side 1 25 av disse, og side 2 de siste 25. Figur: Søk etter oppslag for utførte DagVakt oppgaver, uten spesifisert dato eller tid. 27

123 Produktdokumentasjon Redigering og sletting Når en admin trykker på redigeringsknappen ved en rad i resultatet fra søk og foretar endringer, vil denne funksjonen (vist i figur 8.4.2) hente de endrede dataene og oppdatere den spesifikke raden i routines tabellen (samt i hjelpetabeller der dette gjelder) basert på Id. Funksjonen tar også og lager en instans av endringslogg-modellen hvor den lagrer gammel verdi, ny verdi, hvem endringen ble utført av og når den ble utført, hva slags type endring som ble gjort samt når den originalt ble lagret. Funksjonen for å slette en måling/oppgave er i grunn ganske lik redigeringsfunksjonen. I stedet for å oppdatere data, så blir det slettet basert på id, endringsloggen lagrer denne også, i stedet for at type endring er Redigert så er den Slettet og ny verdi er Ingen. Figur: Funksjon for redigering av målinger/oppgaver. 28

124 Produktdokumentasjon 8.5 Validering For det meste blir alle inntastingsfelter validert i applikasjonen, Laravel har en innebygget validerings klasse som heter Validator. Denne har innebygde feilmeldinger som er på engelsk, men vi har definert våre egne som er på norsk. Det er dette $message på figur viser, men vi har valgt å klippe de vekk fra figuren da dette hadde gjort bilde altfor stort. Figur viser hvordan en validator blir satt opp og brukt i dette tilfellet for opprettelse av en ny bruker. Man ser også reglene, for eksempel må required felter fylles ut, unique:emps betyr at feltet må være unikt i emps-tabellen, for eksempel at to brukere ikke kan ha samme e-post. Figur: Litt sammenflettet kode for validering, rules, og funksjonen er tatt ut av Emp modellen og input biten viser når valideringen blir kalt. Figur illustrerer feilmeldingene som vises når feltene i opprettelse av bruker ikke samsvarer med reglene i validate funksjonen. Her ser vi er som nevnt ovenfor at alle feltene er nødvendige og Fornavn ikke er fylt inn, samtidig må passordfeltene stemme, mens e-post må være korrekt. Figur: 8.5.2: Eksempel på feilmeldinger ved opprettelse av bruker 29

125 Produktdokumentasjon 8.6 Models Modeller benyttes for å kommunisere med databasen på en enkel måte, modellene er en objekt representasjon av tabellene og det er disse Eloquent ORM bruker når den genererer spørringer, det er også derfor disse modellene må extende Eloquent klassen, det er det som gir dem denne funksjonaliteten. På figur vises modell klassen for routines tabellen, her defineres tabellen den er linket til, hvilke kolonner man kan fylle ut og hvordan dens relasjon til andre tabeller er. Vi vet for eksempel at en ansatt kan utføre flere målinger, men en måling kan kun bli utført av en ansatt, altså en én-til-flere kobling. Dette defineres ved man oppretter en funksjon mot den relaterte tabellen, og her så definerer belongsto() funksjonen sammen med Emp modellen sin hasmany() (figur 8.6.2) at dette er en én-til-flere relasjon. Man kan også definere hvilke nøkkel eller nøkler tabellene er linket på, samt hvilken tabell som er hjelpetabell mellom de (gjelder for flere til flere). Disse modellene er de som blir kalt i controllerne når man vil utføre spørringer mot databasen, illustrert blant annet i figur og Figur: Routine tabellen linket med emps og tasks tabellen. Figur: Emp sin relasjon definert mot Routine. 30

126 Produktdokumentasjon 8.7 Rapport Rapportfunksjonen i BassengWeb befinner seg under public i kildestrukturen. Filen connection.php brukes av både Excel og Pdf til å spesifisere oppkobling mot database. Rapport består av en html index side som er view-filen og inneholder skjemaer for generering av rapport. Basert på hva brukeren ønsker å få generert rapport i sendes variablene videre til enten generateexcel.php eller generatepdf.php basert på hvilken knapp som trykkes. Dette gjøres med HTML attributtet formaction, som støttes i alle nettlesere. Dette attributtet gjør det mulig å ha to submit knapper til et skjema som sender dataene til to forskjellige filer. Figur 8.7 viser hvordan attributtet er brukt. Figur: Formaction attributtet Excel I generateexcel.php gjøres en SQL-spørring basert på hvilken måling/oppgave brukeren ønsker å generere i et Excel-dokument. Som figur illustrerer for helgevakt, vil først SQL spørringen SELECTE kolonnetitlene og omgjøre disse til norsk i Excel en som genereres. CONVERT funksjonen brukes for tid og dato, der 08 er er formatet i hh:mm:ss, mens 105 i dato er formatet i dd-mm-yyyy. Figur: SQL spørring for Helgevakt 31

127 Produktdokumentasjon Excel-dokumentene genereres i formatet CSV, slik illustrert i figur Filnavnet til Excel-filen er spesifisert i en variabel som inneholder tidspunktet den generes i, altså: TimerMinutterSekunder.csv. Nederst i figuren er \t brukt for å separere hver kolonne i hver celle. Det er lokalt satt hva som brukes for å separere kolonne, dermed endte det opp med å bruke tab i kombinasjon med sep=<x> i første rad. Da denne automatisk separerte kolonnene i egne celler, ulempen er at denne dukker opp i første rad i Exceldokumentet som genereres. Figur: CSV format 32

128 Produktdokumentasjon PDF I generatepdf.php tas biten for genereringen av rapporter i pdf. Som vi ser i figur 8.7.2, defineres først header som gjelder for alle pdf-filer som genereres. Denne gjelder kun for første side og består av tittelen. Deretter initieres new PDF (), sammen med AddPage() som oppretter en ny side, hvor deretter kolonnene navngis. Kolonnene er til forskjell fra Excel, statiske for både målinger og oppgaver. Deretter initieres $pdf->table("sql") som inneholder SQL spørringen og filen lastes ned med TimerMinutterSekunder.pdf formatet som vist i Excel eksemplet. Der er D er spesifisert som Download. $pdf->output("$strf.pdf", 'D');. I figur er dette vist for timemåling. Figur: FPDF 33

129 Produktdokumentasjon 8.8 Diagram Mappen diagram under public inneholder filene knyttet til Google Chart. Filen connection.php brukes også av Google chart for oppkobling mot databasen, denne ligger under rapport. Filen index.php består av view filen, mens kode.php består hovedsakelig av backend. Det kjøres en query (figur 8.8) mot databasen med SUM og Case som sjekker tittelen i measurements-tabellen og erstatter verdien til tittelen fra komma til punktum og sender deretter spørring mot databasen. Deretter legges tittelen som label i arrayet, slikt array('label' => 'Temperatur', 'type' => 'number'), som igjen legger disse i en $row=array. Som deretter benytter json_enode for å gjøre tabellen om til et array $jsontable = json_encode($table, JSON_NUMERIC_CHECK). Figur: SQL spørring Deretter enkodes tabellen for diagrammet: var data = new google.visualization.datatable(<?=$jsontable?>) og diagrammet legges i en div chart_div som plasseres i containeren, slik spesifiseres diagrammet slik at den kan plasseres rundt: chart = new google.visualization.linechart(document.getelementbyid('chart_div')). Videre er det muligheter for definere egenskaper til diagram som vist i figur 8.8.1, her er høyde og bredde definert, med tittel og curvetype som gjør linjene i diagrammet bøyelige og ikke strake. Videre kan man definere punktstørrelsen med pointsize. Med explorer er det mulig å definere handlinger 34

130 Produktdokumentasjon knyttet til å forstørre, dette er definert til at man kan markere området som skal forstørres, og tilbakestille ved å høyreklikke. Med focustarget er dette knyttet til punktene hvordan informasjonen vises om punktet, dette er satt til å vises per kategori. Til slutt er interpolatenulls satt til true, dette for å hindre at strekene løser seg opp mellom punktene grunnet nullverdier, slik at man får en sammenhengende graf mellom punktene. Figur: Egenskaper til diagrammet 35

131 Produktdokumentasjon 9. Beskrivelse av Arduino Yun Arduino Yun er et unikt Arduino brett. Det som gjør den unik er dens to prosessorer, med mulighet for kommunikasjon seg imellom, Atmel ATmega32U4 og Atheros AR9331. ATmega32U4 kontrollerer I/O pinnene på Arduino, og det er her vi installerer skissene. AR9331 kommer installert med en distribusjon av Linux, Linino. Sammen har de grensesnitt til å gjøre alt en mikrokontroller og pc kan gjøre. Begrensingene er minne og kraft. Arduino Yún har flere fysiske trekk og tilkoblinger som skiller den fra andre Arduino er, se figur 9. Strøm blir gitt til systemet via mikro-usb inngangen. Det er en Ethernet port koblet mot AR9331 prosessoren, men internett kan også enkelt kobles trådløs, ettersom Arduino Yùn har to nettverkskort. Sending av data og skisser til Arduino gjøres via Internett. Arduino Yùn har begrenset med lagringsplass, men tilbyr en SD-kort inngang for øking av kapasiteten. Det interne minne er altså tilstrekkelig for oppgavene Arduino en utfører i dette prosjektet. Figur: 9 - Arduino Yun 36

132 Produktdokumentasjon Opplasting av skisser og overvåking av seriell kommunikasjonen, gjøres med Arduino IDE. Sørg for at det er den rette versjonen som støtter Arduino Yun brettet. I skrivende stund er det versjon r2 BETA. 9.1 Dallas Temperature Sensor DS18B20 DS18B20 er et digitalt termometer og gir 9 til 12 bits temperaturmålinger i Celsius format. Bruker OneWire for kommunikasjon, som tilsier at man trenger kun en port for å sende data. Vi tilføyer 5V strøm til kretsen, som først må gjennom en 4k7 resistor. Leverer temperaturer med en nøyaktighet på +- 0,5C. For at sensoren skal fungere må man installere bibliotekene OneWire og DallasTemperature. De pakkes ut i C:\Users\ brukernavn \Documents\Arduino\libraries. Endre navn på DallasTemperature_372Beta mappen til kun DallasTemperature. Bibliotekene importeres i skissen Oppkobling Temperatursensoren sine 3 pinner er loddet på et eget brett med en 4k7 resistor koblet i serie. Figur viser temperatur sensoren. GND (jording) og DQ (strøm) kobles på siden av koblingsbrettet. GND til + (rød side) og DQ til - (blå side). Det kobles tilsvarende fra Arduino en til koblingsbrettet. Fra koblingsbrettet til 5V på Arduino, og fra + til GND. Fra VDD går kabelen som kommuniserer med OneWire biblioteket. Den kobles direkte mot pin 7 på Arduinoen (Pin 7 må defineres for OneWire i skissen). Sending og mottak av data skjer fra RX og TXportene på Arduinoen. Disse kobles i samme kolonne som koblingene til temperatur sensoren på koblingsbrettet. Det er en gylden regel at oppkoblingen aldri skal være RX til RX eller TX til TX. Den skal være rx til tx og tx til rx. På koblingsbrettet og generelt ellers kommer RX først i kolonnen. Vi kobler derfor RX fra Arduino en til rad 11 på koblingsbrettet, og TX til rad 10. Da blir rad 10 RX, og 37

133 BassengWeb - Hovedprosjekt ved HIOA 2014 Produktdokumentasjon rad 11 TX, for DS18B20. Strøm blir tilføyd systemet via en 5V adapter og mikro-usb inngangen på Arduino en. Figurene til illustrerer oppkoblingen. Figur: Oppkobling 1 Figur: Oppkobling 2 38 Figur: # - Tittel Figur: Oppkobling 3

134 Produktdokumentasjon Gjennomgang av LesTemperatur Figur: LesTemperatur Du som leser dette dokumentet kjenner nok ikke så godt til Arduino fra før. Skissen LesTemperatur skal lære deg litt om hvordan programmering i Arduino er. Den henter verdier fra sensoren og printer det ut i monitoren og kan også brukes til å teste om temperatur sensoren fungerer. Nedenfor er en gjennomgang av skissen, om hvordan skissen er strukturert, og hvordan vi kan bruke verdiene vi henter fra sensoren. Importering Det som skjer først i skissen er importering av biblioteker. Bibliotekene inneholder forhåndsdefinerte metoder for forskjellig funksjonalitet. Hvilke biblioteker man trenger, avhenger av hva man skal gjøre i programmet. Console biblioteket er for programmering av Arduino via nettet. Hvis man skal installere skisser via USB trenger man ikke Console. I skissen byttes da Console med Serial. Bridge sørger for 39

135 Produktdokumentasjon kommunikasjonen mellom 32U4 og AR9331 og følger med importeringen av Console. Vi importerer bibliotekene DallasTemperature og OneWire. Disse må, som forklart tidligere, være installert i IDE et. DallasTemperature inneholder metoder som initierer og leser målinger fra sensoren. OneWire inneholder metoder som sikrer kommunikasjon mellom sensor og Arduino. Deklarering Det neste som gjøres i skissen er deklarering av objekter og eventuelle variabler man trenger. Først deklareres et OneWire objekt, med 7 som parameter. OneWire biblioteket bruker parameteren til å bestemme hvilken pin, sensoren snakker med. I vårt tilfelle, pin 7 på Arduino. Så deklareres et objekt av DallasTemperature, sensor, med OneWire objektet som parameter. Variabelen «currenttemp» blir deklarert for midlertidig lagring av verdiene som blir sendt fra sensoren. Initiering I setup metoden initieres bibliotekene og kommunikasjonen startes. Bridge.begin() starter bridge, og prosessorene kan nå snakke med hverandre. Console.begin() starter kommunikasjonen mellom Arduino en og nettet. Funksjonen while(!console) stopper programmet og venter til kommunikasjonen har oppstått. Til slutt initieres DallasTemperature objektet, som vil si at sensoren står klar for måling. Programmet I metoden void loop() legges alt som skal kjøres gjentagende i programmet. Man kan skrive all kode inne i loop metoden, eller lage egne metoder og kalle på dem i loop. I dette eksempelet ligger all kode i loop, ettersom det bare er 3 linjer kode som utføres. Først startes målingene ved å kalle sensor.requesttemperatures(). Så skal det hentes en måling som skal legges i variabelen currenttemp. Det gjøres med currenttemp = sensor.gettempcbyindex(0). Verdien legges til variabelen i formatet XX.XX. Metodene som blir tatt i bruk er fra DallasTemperature biblioteket. Verdien er midlertidig lagret i en variabel, som kan brukes på diverse måter. I dette tilfellet printer vi den 40

136 Produktdokumentasjon ut i Console, med Console.println( currenttemp ), for å se om målinger blir utført. Skissen er for testing av temperatur sensor, og viser framstillingen av resultatet. Figur: Temperatur utskrift 9.2 Kommunikasjon Eksemplet Sending er hentet fra og viser hvordan man kan hente og håndtere data over nettet med Arduino. Skissen skal laste ned Arduino logoen, som finnes på Arduino nettstedet, og printe det ut i monitoren. 41

137 Produktdokumentasjon Figur Arduino logo Process og Curl Process er hovedklassen for alle Bridge baserte kall for kommunikasjon. Med andre ord brukes klassen til å kjøre prosesser på Linux prosessoren. Curl er en innebygd funksjon i Linux. Den blir brukt for overføring av data via forskjellige protokoller, deriblant HTTP. Det lages først et prosess objekt, p. Prosessen opprettes i Linux med curl funksjonen, p.begin( curl ). Så legges URL adressen til som parameter til prosessen, p.addparameter( ). Og til slutt kjøres den, p.run(). 42

138 Produktdokumentasjon Curl henter informasjonen fra nettsiden og det brukes en while løkke til å lese informasjonen som kommer ut av prosessen. Den leser og printer karakterene enkeltvis, helt til prosessen avsluttes. Funksjonen Serial.flush printer ut det siste av informasjon, hvis det var noe som ikke ble sendt. Funksjonen delay(5000) stopper programmet i 5 sekunder, og fungerer som en pause i dette tilfellet. Eksempelet kan være nyttig for å teste om Arduino en har tilgang til internett og du kan finne den i IDE et under File > Eksamples > Bridge > Process Databasen For at Arduino en skal kunne sende en HTTP request til en lukket/beskyttet webserver, må den ha direkte tilgang. Det vil si at den må være tilkoblet til samme tilkoblingspunkt som serveren. Modemet som serveren og arduino en står koblet opp mot, har Ip adressen Så lenge man er koblet til det samme tilkoblingspunktet, kan man installere skisser på Arduino en fra hvor som helst. 9.3 Ferdig løsning Programmet Slik vi ser på figur importeres og deklareres alt det samme som er gjennomgått. Det er imidlertid to nye deklarasjoner. I den ferdige løsningen trengs det en metode som regulerer målingene til kun å skje hver 2. time, som ønsket av oppdragsgiver. Derfor deklareres strengen timestring for å holde på tid, og en boolean itstime som blir true når det er tid for måling. 43

139 Produktdokumentasjon Nytt i loop-metoden er at det kalles på metoder som er definert lengre ned i skissen. Først kalles metoden gettime(), som lagrer tiden som tekst i strengen timestring. Deretter kalles sjekktid() metoden, som sjekker om det er tid for måling. Dersom det er tid for måling, settes itstime til true. Ellers forblir den false og resten av koden blir hoppet over og starter på nytt. Hvis itstime er true, kalles metoden senddata(), som foretar en temperatur måling og sender en HTTP request til updatedb.php, og itstime blir satt tilbake til false Metodene gettime() Linino har en innebygget funksjon, date, som henter dato og tid. For å kalle den opprettes en prosess, som er kalt time. Det sendes med date funksjonen og parameteren +%T. Parameteren er en formateringsvariabel. Den forteller prosessen at den kun skal lese tiden, ved å utelukke D, og setter formatet på informasjonen som blir mottatt til TT:MM:SS. Prossesen leses igjen med en while løkke. Karakter for karakter legges til i timestring strengen, til det treffes på karakteren /n. Det betyr linjeskift, men også at man har kommet til enden av tidstrengen. Det må testes etter linjeskift karakteren så den ikke blir med i strengen og skaper problemer for sjekktid() metoden. 44

140 Produktdokumentasjon sjekktid() Prinsippet bak sjekktid() metoden er enkel. Den starter med å teste om timestring er 00:00:00, som figur viser. Det følger så en rekke else if som tester strengen på samme måte, men med en økning på 2 timer. For hver andre time i døgnet vil altså itstime variabelen settes til true og senddata() metoden blir kalt. Helt nederst i metoden startes om timestring variablen. Det er nødvendig for at den ikke skal øke og øke for hver loop. senddata() Metoden foretar en temperatur måling og sender verdien via en HTTP request. Metoden gjør tilsvarende det som er gjennomgått i de to første eksemplene, med noen få unntak. URL en er det viktigste å legge merke til /nih/public/arduino/updatedb.php er filstien. Hovedsaklig ønsket vi ikke å bruke ip adressen til webserveren. Dette fordi den kan endre seg, og da vil ikke målingene bli lagret i databasen. Dersom programmet slutter å skrive målinger til databasen, bør man være oppmerksom på om ip adressen stemmer overens med ip adressen til webserveren. Det beste hadde vært å bruke den faste adressen nihsrw10-40/nih/..., men av uante grunner fikk den ikke kontakt. I enden av filstien er det skrevet?temp=. Det er variabelen som skal sendes med til updatedb.php. 45

141 Produktdokumentasjon Verdien som skal sendes med ligger i currenttemp og den legges til i URL strengen ved neste linje i koden. Adressen som da blir curlet ser eksempelvis slik ut: /nih/public/arduino/updatedb.php?Temp= Filen updatedb.php inneholder SQL spørringene som legger verdiene i databasen. Den henter verdien fra URL en og lagrer den i en egen variabel, $value = $_GET['Temp'];. Verdien legges til database tabellen routines, sammen med dato, tid og id. Updatedb.php returnerer en melding som bekrefter eller avkrefter vellykket transaksjon. if( $query && $stmt ) { sqlsrv_commit( $conn ); echo "Transaction committed.<br />"; } else { sqlsrv_rollback( $conn ); echo "Transaction rolled back.<br />"; } Det er dette vi finner printet i monitoren. Denne koden passer også på at det både lagres i routines og hjelpetabellen, og rollback() blir kalt om det av noen grunn ikke skulle gå. Man kan også sjekke om transaksjonen var vellykket ved å se om verdien er satt inn i databasen. Figur Målinger utført av arduinoen Som man kan se i figur er ikke klokken til Arduino synkronisert med tiden fra updatedb.php. Dette er en bagatell og målingene blir fortsatt utført hver andre time, med et avvik på noen sekunder. 46

142 BassengWeb - Hovedprosjekt ved HIOA 2014 Produktdokumentasjon Dersom det er ønskelig å se nærmere på updatedb.php, finnes den i kildekoden under public/arduino Plassering Arduino prosjektet kunne ikke ligge oppe ved bassenget, ettersom det både er stygt og utrygt. Dermed måtte den plasseres i kjelleren, i det tekniske rommet for bassengene. Her er det mye gasser og syrlig luft. Saltsyre prosenten er så høy som 35% i rommet. Det vil si at alt mekanisk ruster ekstremt fort. For å beskytte Arduino en mot luften i rommet ble den lagt beskyttet i en koblingsboks. Den er så og si luftett, men vi kan ikke garantere at systemet ikke ruster. Vi forventer at systemet lever i minst et år, med tanke på hvor lufttett koblingsboksen er, figurene og illustrerer dette.. Figur: Arduino i koblingsboksen Figur: Plassering av koblingsboksen Videreutvikling Som en del av prosjektet, koblet vi opp en ph sensor som skulle fungere sammen med temperatur sensoren. Dessverre ble denne ødelagt underveis i prosessen og ekskludert fra prosjektet. Dette er mer beskrevet i prosessrapporten under punkt 4.5. Det store utviklingspotensialet for dette prosjektet, er det å legge til flere sensorer. De mest aktuelle er ph, klor og eventuelt flere temperatur sensorer for de andre bassengene. 47

143 Produktdokumentasjon 10. Installasjon av BassengWeb 10.1 Krav til installasjon WampServer 32 bit Visual Studio 2012 VC 11 PHP versjon 5.4 eller nyere. MS SQL SERVER 2008 eller nyere Installasjonsprosessen Installasjonsprosessen består av riktig konfigurering av WampServer, oppsett av database og BassengWeb. Først må applikasjonen og konfigurasjonsfiler lastes ned, dette kan lastes ned her: Figur 10.2 viser hvor man må trykke for å få lastet ned. Når nedlastningen er gjort. Opprett en ny mappe som heter nih under C:\wamp\www kopier innholdet av nedlastede zip-filen inn i nih mappen. Figur: Nedlastning av filene 48

144 Produktdokumentasjon WampServer konfigurasjon 1. Neste som må gjøres er å gå inn i Installasjonsfiler under nih mappen som ble opprettet av deg og kopier filene nevnt under til: C:\wamp\bin\php\php5.4.X\ext: php_sqlsrv_54_ts.dll php_pdo_sqlsrv_54_ts.dll 1.1. Om WampServer kommed med php versjon 5.5.X så kreves også 5.5 drivere: php_sqlsrv_55_ts.dll php_pdo_sqlsrv_55_ts.dll Disse ligger i en egen mappe i Installasjonsfiler som heter PHP5.5. Deretter må teksten nevnt under legges inn helt nederst i php.ini-filen, se figur for å se hvor du finner php.ini. PHP VERSJON 5.4 extension=php_sqlsrv_54_ts.dll extension=php_pdo_sqlsrv_54_ts.dll PHP VERSJON 5.5 extension=php_sqlsrv_55_ts.dll extension=php_pdo_sqlsrv_55_ts.dll Deretter må WampServer refreshes (høyre klikk på ikonet og refresh), dette gjøres ved å trykke på Wamp-ikonet og velge Restart all services. Videre viser figur viser hvilke utvidelser (5.4 eller 5.5) som må aktiveres i WampServer -> php -> extensions. 49

145 Produktdokumentasjon Figur: Trykk på wampserver ikonet og velg PHP (her finner man også php.ini filen) 2. Helt til slutt må modulen rewrite_module i WampServer under Apache -> apache modules aktiveres. 50

146 Produktdokumentasjon Microsoft SQL Server 2012 Express For å laste inn databasen i MSSQL finnes SQL-filen nih_bw.sql i mappen Installasjonsfiler under nih, man dobbelklikker på denne så burde man få opp vinduet som vises i figur (forutsett at MSSQL server er installert). Etter at man har trykket Execute som er markert rødt i figuren så skal databasen være importert (dette kan man se ved å høyreklikke på teksten inne i den grønne markeringen og velge Refresh, åpne Databases og se at nih_bw er tilstede). Deretter må det høyreklikkes i den grønne markeringen, og velge Properties, her skal Security velges og under Server authentication skal SQL Server and Windows Authentication mode velges. Figur: Importing av nih_bw til MSSQL SERVER 51

147 BassengWeb Hovedprosjekt ved HIOA 2014 Produktdokumentasjon Konfigurering av BassengWeb mot nih_bw For å koble databasen til applikasjonen så må to filer modifiseres, dette er filene som står for koblingen mellom applikasjon og database. Figur viser hvor man kan finne disse to filene, og figur viser innholdet av filene. Her må SERVERNAVN fylles inn med servernavnet til SQL serveren (vanligvis PC NAVN\SQLEXPRESS, hvor PC NAVN er navnet på datamaskinen). NB! Hvis SQL SERVER 2008 benyttes, så skal password og PWD feltene stå tomme, altså eller som standard (fnuttene må være der, bare ingenting i dem). Figur: Filene som må fylles inn med riktig informasjon. Figur: Path til filene 52

148 BassengWeb Hovedprosjekt ved HIOA 2014 Produktdokumentasjon Innlogging i nettleser Nå skal det være mulig å logge inn i BassengWeb ved å gå inn med denne URL en.: Det er lagt inn en predefinert bruker i databasen med: Brukernavn: rootr Passord: tester 10.3 Feilmeldinger WampServer ikonet lyser oransje Vanligvis skyldes dette at port 80 (porten WampServer bruker) er i bruk, den vanligste grunnen til at den er i bruk er Skype som bruker samme porten. Om dette er tilfellet forsøk å slå av Skype og restarte WampServer. Om feil vedvarer etter dette kan man endre porten WampServer bruker, dette gjøres ved å klikke på WampServer ikonet, velge Apache deretter klikke på httpd.conf. Her inne trykk CTRL+F og skriv Listen 80. Når denne er funnet kan denne endres til for eksempel Listen 8080 og lagre, deretter restart Wamp. Dette forårsaker også at URLen man går inn med må endres til (i tilfelle av 8080). 53

149 Produktdokumentasjon 11. Kildehenvisninger 11.1 Bibliografi 1. Laravel 4 a. Rees, D. (2013). Laravel: Code Bright. Vancouver: Leanpub. b. Saunier, R. (2014). Getting started with Laravel 4. n/a: Packt publishing. 2. Twitter bootstrap a. Cochran, D. (2012). Twitter Bootstrap Web development How-To. Birmingham: Packt publishing. 3. Arduino Yun a. Monk, S. (2013). Programming Arduino Next Steps: Going Further with Sketches. n/a: McGraw-Hill/TAB Electronics. 54

150 Produktdokumentasjon 11.2 Kilder for rammeverk og verktøy Verktøy: Sublime text Brackets Gliffy Google docs Twitter Bootstrap Laravel 4 Wamp Server GitHub VioletUML SnagIt GreenShot SQL-Server Google-chart FDPF Trello NotePad++ Dropbox Balsamiq Skype Arduino: DS18B20 OneWire DallasTemperature Arduino IDE Arduino Yun

151 Testdokumentasjon Testdokumentasjon 1

152 BassengWeb Hovedprosjekt ved HIOA 2014 Testdokumentasjon Forord Dette dokumentet inneholder testdokumentasjon for prosjektet BassengWeb NIH. Dokumentet er delt i tre: 1. I første del beskrives bakgrunn, formålet, metoder og verktøy brukt i testene. 2. I andre del beskrives planlegging og utføring av tester, i tillegg til resultatet av hver test. 3. I tredje del beskrives brukertesten, og resultatet av denne. Dokumentet er hovedsakelig ment for sensor, driftere og videreutviklere. Kildekoden er tilgjengelig her: NB: Betegnelsene Arduino og Arduino Yún brukes om hverandre og menes det samme. Målinger i teksten er definert som fanene i BassengWeb: Timemåling, Vannmåling og Oppgaver. Oppgaver er definert som fanene i BassengWeb: Rutiner (Dagvakt, Kveldsvakt, Helgevakt) og Vask med CM. 2

153 Testdokumentasjon Innholdsfortegnelse 1. Bakgrunn og formål Funksjonalitetstesting KOlnpatibilitetstesting Sikkerhetstesting Testing av Arduino Brukertesting Testing av BassengWeb Intern testing Funksj onalitetstesting Kompatibilitetstesting Sikkerhetstesting Testing av instaijasjonsveiledning Akseptansetesting Testing av Arduino Brukertesting For testing bllliedning Valg av frenlgangslnåte Målet med brukertesten Målgruppe Tilstanden til applikasj onen ved testing Tid, sted og organisering av testen Oppgavesett Erklæring Hvilket område av programmet ble testet? Hva som ble testet og resultatene av testen Brukertest user Brukertest adtnin Konklusjon av brukertestingen

154 Testdokumentasjon 5. Kilder Bibliografi Vedlegg Erklæring Brukertest Adtnin Brukertest User

155 Testdokumentasjon 1. Bakgrunn og formål Testing er et av de viktigste elementene for å bygge en solid og fungerende web-applikasjon. Testing kan utføres ved å verifisere at alt skal være korrekt, komplett, og fungere som det skal. Testingen av Arduino vil i hovedsak bestå av at vi med sikkerhet vet at målingene som blir utført og lagret i databasen, ut i fra de tidsintervallene som er spesifisert, er riktige. I tillegg skal sensorene være kalibrert for å lagre korrekte verdier. BassengWeb er en applikasjon som skal brukes daglig av ansatte for å lagre målinger som er utført, og de oppgavene som er relevante. Dermed er det viktig at systemet er enkelt å bruke med tanke på navigering, og å kunne legge inn målinger og oppgaver. I testingen vil det også foretas en brukertesting for å teste de ulike aspektene ved bruken av BassengWeb. Dette inkluderer forståelse av ikoner, navn på navigasjonsmenyen, opplevelsen av arbeidsflyt og hvor enkelt det er å finne frem. Testingen BassengWeb vil bestå av: 1.1 Funksjonalitetstesting Dette inkluderer testing av alle interne koblinger. Test av validering knyttet til innlegging av målinger og oppgaver, redigering og innlogging. Test av database for å kontrollere integritet som produseres under lagring, redigering eller sletting av målinger/oppgaver. 1.2 Kompatibilitetstesting Testing av BassengWeb i forskjellige nettlesere. Mobilvennlighet av BassengWeb. 5

156 Testdokumentasjon 1.3 Sikkerhetstesting Autentisering av brukere. Hashing av passord. Administrator panel kun tilgjengelig for administrator. Redigering og sletting av målinger/oppgaver kan kun utføres av brukere med brukertype admin. Redigering eller slettinger blir lagret i en endringslogg. 1.4 Testing av Arduino Korrekte verdier blir lagret i databasen. Målinger blir utført i riktig tidsintervall. 1.5 Brukertesting Hvor brukervennlig og intuitiv grensesnittet er. Hvor lett det er å navigere seg rundt. Forståelse av ikoner og navn. 6

157 Testdokumentasjon 2. Testing av BassengWeb Testingen av BassengWeb foregikk både internt og eksternt. Det ble utført testing av funksjonene underveis mens de ble utviklet. Videre ble det ble det foretatt en intern test av hele systemet når det var i sluttfasen. Dette inkluderer både BassengWeb og Arduino. 2.1 Intern testing Under utviklingen ble det foretatt tester mens funksjoner ble utviklet og implementert. Formålet var å avdekke feil og mangler for å sikre alle kravene som var satt for systemet. I den interne testingen ble det avdekket at noen av titlene for målinger og oppgaver samstemte med det som lå inne i databasen. Dette returnerte en feil hvor $link variabelen, som brukes til å linke relasjoner mellom routines og measurements eller taskstabellen, er udefinert. Dette ble løst ved å legge inn riktige titler i tilhørende tabeller, eller å endre navn på titlene til inntastingsfeltene. En annen feil som også resulterte i samme feilmelding var det at _token eller time ikke var ekskludert fra input, som resulterte i at $link så etter _token eller time som titler i de nevnte tabellene Funksjonalitetstesting Funksjonalitetstestingen ble foretatt for å avdekke mangler og feil som vi kunne ha gått glipp av under utviklingen. Det ble satt som mål å gå gjennom alt av funksjonalitet i BassengWeb. Resultatet avslørte bugs, og dette ble rettet opp fortløpende. Vi kom frem til at validering av tid og dato ikke er nødvendig, siden det er sjeldent behov for å endre dette når målinger skal lagres. Testen avslørte at det er viktig med konsistens, og som oppdragsgiver ønsket, blir målinger som skal være i desimaltall validert med to desimaler, og målinger som skal være heltall validert i heltall. Figur viser feilmeldingene ved feil inntasting i inntastingsfeltene. Feilmeldingen er tydelig og klar. Her får brukeren beskjed om at Badende Per Time må være i heltall, og viser til et eksempel. Det samme med Temperatur, som må være i desimaltall, og et eksempel på det riktige formatet. 7

158 Testdokumentasjon Figur: Feilmelding ved feil innstasting i inntastingsfeltene 8

159 Testdokumentasjon Det er videre foretatt en full funksjonalitetstest av hele applikasjonen av alle i gruppen. Vi hadde som mål å gå igjennom alt fra innlogging, til opprettelse av bruker. Her er en liten beskrivelse av testen med hvilke funksjoner som ble testet, beskrivelse og prosedyre, resultat, og kommentar. Tabellen under viser dette: Funksjon Beskrivelse/Prosedyre Resultat Kommentar Legge til målinger i timemåling. 1. Trykket på fanen Timemåling i navigasjonsmenyen. 2. Valgte basseng. 3. Fylte ut feltene for basseng måling. 4. Trykket på knappen Lagre Basseng måling. 5. Fylte ut Luft Temperatur. 6. Trykket på knappen Lagre Luft-måling Ok! Fikk beskjed om at målinger er lagret i databasen. Legge til målinger i vannmåling. 1. Trykket på fanen Vannmåling i navigasjonsmenyen. 2. Valgte basseng. 3. Fylte ut feltene for vannmåling. 4. Trykket på knappen Lagre. Ok! Fikk beskjed om at målinger er lagret i databasen. Legge til målinger i oppgaver. 1. Trykket på Oppgaver i navigasjonsmenyen. 2. Valgte basseng. 3. Fylte ut feltene for oppgaver. 4. Huket av avkrysningsrutene. 5. Trykket på knappen Lagre Ok! Fikk beskjed om at målinger er lagret i databasen. Huke ut avkrysningsrutene i dagvakt, kveldsvakt, helgevakt og Vask med CM. 1. Trykket på de nevnte fanene i navigasjonsmenyen. 2. Huket av avkrysningsrutene. 3. Trykket på knappene Lagre Ok! Fikk beskjed om at oppgavene er lagret i databasen. I tillegg vises det ikoner for utførte oppgaver. Generering av rapporter i PDF og Excel for lagrede 1. Trykket på Rapport i navigasjonsmenyen. 2. Huket av Timemåling 3. Trykket på Knappen PDF Ok! 9

160 Testdokumentasjon målinger og oppgaver. 4. PDF fil generes og lastes ned. 5. Trykket på Knappen Excel 6. Excel fil generes og lastes ned. Gjentok prosessen for alle målinger og oppgaver. (Vannmåling, Oppgaver, Dagvakt, Kveldsvakt, Helgevakt og Vask med CM. Lagre diagram 1. Trykket på Diagram i navigasjonsmenyen. 2. Fylte ut Fra-Tid. 3. Fylte ut Til-Tid. 4. Valgte basseng. 5. Trykket på knappen Hent 6. Huket av avkrysningsrutene. Ok! Visualisering av målingene vises korrekt i diagrammet. Redigere måling/oppgave 1. Trykket på Søk i navigasjonsmenyen. 2. Huket av Timemåling 3. Trykket på knappen Søk 4. Trykket på ikonet under kolonnen Rediger på den første målingen. 5. Endret verdien på målingen fra 5,00 til 6, Trykket på knappen Lagre Endringer. 7. Gikk inn på Min Side og valgte Endringslogg for å se om endringen ble logget. Ok! Endringer blir utført, og endringsloggen logger endring korrekt. Slette måling/oppgaver 1. Trykket på Søk i navigasjonsmenyen 2. Husket av Timemåling 3. Trykket på ikonet under kolonnen Slett på den første målingen. 4. Trykket på knappen Slett 5. Gikk inn på Min Side og valgte Endringslogg for å se om sletting ble logget. Ok! Sletting blir utført og endringsloggen logger slettingen korrekt. 10

161 Testdokumentasjon Opprette en ny bruker 1. Trykket på Min Side i navigasjonsmenyen. 2. Trykket på knappen Opprett Bruker 3. Fylte ut Fornavn, Etternavn, Epost, passord og passord-bekreftelsen og valgte brukertype lik user. 4. Trykket på knappen Opprett bruker Ok! Brukeren opprettes med user-rettigheter. Redigere bruker 1. Trykket på Min Side i navigasjonsmenyen. 2. Valgte bruker som skal redigeres fra listen med epost-adresser. 3. Trykket på knappen Rediger Bruker 4. Endrer bruker type fra user til admin. 5. Endrer Fornavnet, Etternavn, E-post og passord. 6. Tykket på knappen Oppdater bruker Ok! Bruker endres og brukernavnet blir oppdatert. Brukeren får rettigheter til å endre/slette målinger og tilgang til adminpanelet i min side. Deaktivere bruker 1. Trykket på Min Side i navigasjonsmenyen. 2. Valgte bruker som skal deaktiveres fra listen med epost-adresser. 3. Trykket på knappen Deaktiver Bruker 4. Trykker på den nye knappen som dukker opp Deaktiver (Brukernavnet). Ok! Brukeren blir deaktivert og om man prøver å logge inn på brukeren får man en feilmelding om at brukeren er deaktivert. Aktivere bruker 1. Trykket på Min Side i navigasjonsmenyen. 2. Valgte bruker som skal aktiveres. 3. Trykket på knappen Aktiver Bruker Ok! Brukeren aktiveres og har mulighet til å logge inn på sin konto. 11

162 Testdokumentasjon Kompatibilitetstesting Nettleserkompatibilitet: Beskrivelse: BassengWeb testes i ulike nettlesere. Da testes alt fra innlegging av målinger og oppgaver, validering, rapportgenerering, søk, redigering og sletting av målinger og oppgaver, til å vise målinger i diagrammer. Da vil man få testet om alt av funksjonalitet er lik på alle nettlesere som er testet. Resultatene vises i tabellen under. Her dukket det opp kun et problem i IE, noe som ble rettet opp med en gang. Nettleser Resultatet Kommentar Firefox Opera Google Chrome Internet Explorer Ok Ok Ok Stilark lastet ikke ordentlig inn. Måtte legge til en meta tag for at navigasjonsmenyen skulle Fikset, Ok fungere i IE: <meta http equiv="x UA Compatib le" content="ie=edge"> Mobilvennelighet: Verktøy: Google Chrome har en innebygd modul som gjør det mulig å emulere som en mobilskjerm. Det er også mulig å spesifisere type mobil dersom dette er nødvendig. Beskrivelse: I denne testen ble flere ulike typer mobiler emulert. Dette for å teste BassengWeb på ulike skjermstørrelser. Denne testen var vellykket. Her er skjermdump fra to av mobiltypene som ble testet: 12

163 Testdokumentasjon Figur: Iphone 5 Figur : Samsung Galaxy Note 2 Kommentar: Tabeller i applikasjonen er ikke mobilvennelige. For brukerne er det viktigst at innlegging av målinger og oppgaver er mobilvennelig. Dermed er det ikke tatt høyde for det i søk og endringsloggen, hvor det er brukt tabeller. 13

164 Testdokumentasjon Sikkerhetstesting Deaktivert bruker En feil vi avdekket var at en deaktivert bruker, selvom vedkommende ikke kom forbi innloggingssiden ved å prøve å logge inn, kunne etter forsøket, få tilgang til innholdet via URL injection (forklart under punktet URL Injection). Dette fordi funksjonen som logger inn en bruker ikke initierte Auth::logout() om active variabelen var satt til 0. Dette ble rettet på ved å legge til overnevnt funksjon i innloggingsfunksjonen. URL injection Det er lagt til sikkerhetsmekanismer som tar hånd om brukere som forsøker å lure applikasjonen ved for eksempel å skrive følgende URL inn i nettleseren, enda deres brukertype ikke har tilgang til å redigere data. I dette tilfellet blir brukeren omdirigert til deres Min side i stedet. Dette er testet for alle funksjoner eksklusive for administrator, som for eksempel oppretting av brukere. Dette kommer som følger av en funksjon lagt til i routes, der routes, som styrer admin funksjonene, er lagt inn i en filter-wrapper som definerer at om brukertypen ikke er admin. Da blir brukeren omdirigert til Min side. Dette gjelder for så vidt også brukere som ikke er logget inn og forsøker å skrive: Brukeren blir i dette tilfellet omdirigert til innloggingssiden med en feilmelding, figur illustrerer dette. 14

165 Testdokumentasjon Figur: URL injection Dermed kan vi konkludere vi at sikkerhetstesten er vellykket. 15

166 Testdokumentasjon 2.2 Testing av installasjonsveiledning Testing av installasjonsveiledning gikk ut på å teste veiledning beskrevet i produktdokumentasjonen fra start til slutt. Beskrivelse Fremgangsmåte Resultat Kommentar WampServer-konfigurasjon 1. Konfigurering av sqlsrv-filene. 2. Starting av services/moduler. Ok WampServer må refreshes, ikke restartes etter at SqlSrv-filene er konfigurert inn. Importering av database 1. Importering av nih_bw til databasen. 2. Nih_bw blir satt opp med alle tabeller og rader. Feil Rettet: Ok Path på loggene måtte endres i nih_bw. Konfigurering av BassengWeb mot nih_bw 1. BassengWeb blir satt riktig opp mot nih_bw. Feil Rettet: Ok Aktivering av både Windows autentisering og SQL server autentisering. Innlogging 1. Bruker kan logge inn. 2. Får lagret målinger/oppgaver. 3. Får hentet ut målinger/oppgaver. OK 2.3 Akseptansetesting For å sørge for at oppdragsgiver får det produktet som er avtalt i kravspesifikasjonen, er det ikke nok med at programvaren er fri for feil. Den må også akseptansetestes for å avklare om den oppfyller de kravene som er satt. Dette ble utført og vellykket. 16

167 Testdokumentasjon 3. Testing av Arduino Testingen av Arduino ble foretatt i det tekniske rommet. Den ble kablet opp mot det interne nettverket, og temperatursensoren dyppet i vannet for hovedbassenget. Ved å ha en laptop koblet til det samme nettverket som Arduinoen, var det mulig å laste opp skissene trådløst, som dermed kunne lagre målingene via filserveren. Dette førte til at det kun ble lagret målinger med verdi -127, som figur 3 illustrerer. Etter å ha feilsøkt, kom vi frem til at det var for lang avstand mellom strømtilkoblingen med skjøtekabelen til plasseringen av Arduino, og at det var en feil med strømadapteret. Ved forsøk med kortere skjøtekabel og ny strømadapter, løste problemet seg. Figur: 3 Data fra testing 17

168 Testdokumentasjon 4. Brukertesting Når man utvikler et IT-system er det nødvendig å utføre en brukertest. Dette er ikke kun for å få tilbakemelding på om systemet er brukervennlig, men også blant annet for å oppdage potensielle feil. Ved å være med i utviklingsprosessen av et system vil man kjenne systemet for godt til at man kan komme med like god tilbakemelding, slik en person som ikke har sett systemet før vil. Det var med dette ønskelig for oss å benytte flest mulig øyne som ikke hadde vært i kontakt med BassengWeb på noe tidligere tidspunkt. Videre gjør brukertestingen det mulig for oppdragsgiver å komme med ønsker om endringer før systemet er ferdigstilt. Jo tidligere man finner en feil, jo enklere er de å rette opp i. 4.1 Før testing Innledning Grunnlaget for BassengWeb er at brukerne frem til i dag har registrert målinger og oppgaver ned på papirbasert skjema, og derfor hadde de ingen andre lignende systemer å sammenligne BassengWeb med, annet enn nettopp disse skjemaene. Ved bruk av testing ønsket vi å se om vi hadde laget en applikasjon som fungerer for brukerne, slik at de i fremtiden slipper å gå tilbake til papirskjemaene Valg av fremgangsmåte For å se hvordan applikasjonen fungerer i bruk av de ansatte ved NIH, og for å se hva som fungerer godt, samt avdekke eventuelle feil og mangler, bestemte vi oss for å arrangere en brukertesting. Valg av fremgangsmåte ble valgt på bakgrunn av at det i utgangspunktet er få brukere av applikasjonen, selv om det over tid vil bli flere pga. utskiftning av ansatte. Dette gjør at en kvantitativ fremgangsmåte som spørreskjema ville kunne gi oss vage svar, og denne metoden ville fungert bedre om det hadde vært flere brukere, og om de var bedre kjent med systemet på forhånd. En kvalitativ test, som brukertesting er, fant vi som den beste metoden, og valgte å benytte oss av denne alene. Dette også fordi vi i den grad 18

169 Testdokumentasjon vi ønsket at brukerne skulle føle seg trygge underveis, kunne stille en del spørsmål som en del av brukertestingen, uten at de ville føle at de ble intervjuet Målet med brukertesten Som tidligere nevnt ønsket vi å se hvordan BassengWeb fungerer i bruk av de ansatte, og eventuelt hva som kunne ha fungert bedre. I utviklingsprosessen ble vi også nødt til å forfatte en del av navnene på menyvalgene selv, og det var viktig for oss å se om dette var navn som var forståelige for brukerne, eller om vi burde endre disse, samt om de hadde noen bedre navn å komme med. Formålet med brukertestestingen er å kartlegge brukervennligheten og brukeropplevelsen til BassengWeb I brukertesten var det viktig for oss å se hvordan brukeren brukte applikasjonen, og vi lagde ulike oppgaver på forhånd som skulle få dem til å bruke BassengWeb slik de tidligere har brukt skjemaer på papir. Disse oppgavene skulle underveis svare på spørsmål som hvordan de løste oppgaven, og om det var enkelt eller utfordrende, samt hva det var som gjorde det enkelt eller utfordrende. Samtidig som funksjonaliteten er viktig, så ønsket vi også å vite om de generelt synes applikasjonen er fin, oversiktlig, og om hvordan de tror bruk av BassengWeb vil hjelpe dem i arbeidshverdagen. Til syvende og sist kan vi være såpass ærlige å si at målet med brukertesten er å få konstatert at vi har laget en brukervennlig applikasjon brukerne ved NIH liker, og så vil brukertesten eventuelt gi oss svar på om vi har greid det, og at det vil små endringer til, som gjør BassengWeb helt perfekt. 19

170 Testdokumentasjon Målgruppe Målgruppen til BassengWeb er de ansatte ved NIH som drifter bassengene, og som daglig gjør målinger av vann og temperatur, samt generelle vedlikeholdsoppgaver. Disse består hovedsakelig av to ansatte med hovedansvar, og vil de vil i applikasjonen få rollen som admin, samt flere studenter som jobber der deltid, og derfor kun er user Tilstanden til applikasjonen ved testing Før brukertestingen går i gang, er applikasjonen helt ferdig, og det er med utgangspunkt i eventuelle feil og mangler vi får avdekket i brukertesten, vi i ettertid kommer til å gjøre endringer. Derfor vil brukerne se BassengWeb slik vi har tenkt at den skal fungere, og ingenting blir overlatt til fantasien. 4.2 Tid, sted og organisering av testen Torsdag den 24. April hadde vi brukertesting på NIH. Vi hadde planlagt fem testobjekter som skulle utføre gitte oppgaver ved bruk av BassengWeb. To av deltagerne hadde sett bilder av BassengWeb tidligere, mens de øvrige ikke var kjent med systemet. Brukertestingen ble avtalt i god tid på forhånd, slik at vi kunne få muligheten til å teste ut systemet på flest mulig fremtidige brukere. Vi fikk avtalt å disponere et møterom i forbindelse med brukertesten. Brukertesting er noe som raskt kan komme til å kreve mer tid enn man skulle tro. Etter å ha forhørt oss litt med noen som jobber med interaksjonsdesign og brukertesting til vanlig, ble vi rådet til å ha en halvtime per testperson. Videre lød anbefalingen å ha minst tyve minutter med pause mellom hver person, da testing er slitsomt, og man trenger tid til å absorbere inntrykkene man får samt for å notere, gjøre klart til neste testobjekt, og for å rydde opp i et par feil vi oppdaget underveis i testingen. Hele dagen skulle gå med til å utføre en så grundig test som mulig. 20

171 Testdokumentasjon Oppgavesett På forhånd lagde vi ett sett med ark per testdeltaker med ulike oppgaver som ble gitt underveis, de ble gitt ved at vi lese spørsmålene opp høyt. Planen for brukertesten var at en skulle oppgi oppgavene, samt stille spørsmål underveis, slik at mest mulig ble avdekket. Den andre skulle sitte mer passiv på sidelinjen for å observere og ta notater for å kunne svare på det vi på forhånd trodde vi lurte på. I tillegg til dette tok vi opptak av skjermen og stemmene, slik at vi i ettertid kan gå igjennom for å se hvordan de beveget musepekeren samtidig som de tenker høyt og forklarer hva det er de gjør. Oppgavesettene ligger som vedlegg; Brukertest admin og brukertest user Erklæring Ved oppstart av brukertesten måtte alle signere en erklæring som de fikk lese igjennom før selve brukertesten. Alle som deltok måtte signere en erklæring de hadde lest igjennom, slik av de visste hva formålet med testen var, hva den skulle brukes til, hvem som vil hadde tilgang til resultatene, og til slutt nevner den at vi innen to uker ville slette opptakene gjort av testen. Erklæringen ligger som eget vedlegg. 4.3 Hvilket område av programmet ble testet? Vi ønsket å benytte muligheten til å teste mest mulig av systemet når vi først hadde anledning til det. Som utviklere av et system er det fort gjort å se seg blind på eget verk. Derfor kan det bli ekstra vanskelig å finne potensielle feil etter en lang utviklingsprosess som medfører ekstrem god kjennskap til hver minste krok i systemet. Med dette lagde vi en brukertest som tok for seg alle funksjonene i systemet. I oppgavesettene for brukertestingen kommer det også frem hvordan vi har valgt å få testet de forskjellige områdene. 21

172 Testdokumentasjon Den første oppgaven i testen spør brukeren om å gjøre det første du gjør når du kommer på vakt. Utenom å ta en tur ned i det tekniske rommet, er dette å foreta en vannmåling. Vi lagde slike oppgaver for alle tilsvarende funksjoner i systemet. For å gjøre testen litt smidig, forsøkte vi å lage varierte oppgaver i forbindelse med testen. Vi hadde altså ikke alltid en klar fremgangsmåte for å løse oppgavene, dette gjorde vi ved å lage noen oppgaver som utfordret brukeren til å lete litt selv før han/hun kunne foreta seg et valg. Eksempelvis hadde vi en oppgave som gikk ut på at testobjektet skulle registrere tre ting som de hadde gjort i forbindelse med daglige oppgaver. Her må brukeren selv finne ut at det er rutiner som skal trykkes på, og videre hvilke av døgnets tider han/hun ønsker. Fremfor at vi formulerte oppgaven slik at man skulle trykke på rutiner, og deretter foreta seg et valg. Testen ble altså laget av oss med det formål om å dekke hele systemet mest mulig enkelt, og hvor alt ikke minst var relevant. 4.4 Hva som ble testet og resultatene av testen I dette avsnittet skal vi gjennomgå hvordan testobjektene løste oppgavene og hvilke tilbakemelding de hadde til BassengWeb. Vi tar først for oss user, og deretter admin, ettersom det er en liten variasjon i testene Brukertest user Vi hadde muligheten til å teste ut systemet på tre user -brukere på NIH. En ting vi noterte oss var at denne gruppen syntes dagens løsning var helt ok. De hadde ikke noen store formeninger om funksjoner som kunne ha vært greie å ha i tillegg til de mulighetene som eksisterer når man opererer for hånd. Men de var svært positive da vi forklarte dem hva BassengWeb var for noe. De første tre oppgavene gikk veldig greit i alle tre tilfellene. Det var ikke før testobjekt nummer to at vi fant en bug i oppgave 4 - Klokken er 10, og du skal registrere tre ting du har gjort. Denne feilen oppstod også ved de senere forsøkene. Det som skjedde var at når man skulle klikke lagre, så hoppet hele systemet ut. Naturligvis var dette ønskelig å få fjernet så raskt som mulig. Vi trengte litt 22

173 Testdokumentasjon ekstra tid for å rette opp i koden på akkurat dette området. Ergo kom den ekstra tiden vi hadde satt av godt med i forbindelse med testingen. Det som skjedde når man klikket på rutiner, Kveldsvakt og deretter trykket lagre var at time fulgte med som en tittel, $link fant ikke tittelen fordi time ikke er en tittel som finnes i databasen, derav stod den udefinert og dermed resulterte i feilmeldingen, illustrert i figur og Under på figuren ser vi hva som skjedde når testbrukeren trykket på lagre etter å ha fylt ut helgevakt. Det samme gjentok seg når man trykket lagre for kveldsvakt og dagvakt. Figur: trykker lagre i helgevakt Figur Feilmeldingen I test nummer tre fant vi i et forbedringspotensiale, da knappen som linker til brukerprofilen til de forskjellige brukerne kunne by på misforståelser. I oppgave 7 spurte vi nemlig brukeren om kan du sjekke profilen din?. Som vi ser på figur fant testobjekt nummer 2 riktig sted i systemet for å finne profilen sin. Men det er kun navnet TestUse som faktisk fungerer som en link til brukerprofilen. På grunn av dette begynte testbrukeren å lete etter brukerprofilen sin alle mulige andre steder i systemet. Dette tok til slutt så lang tid at vi vurderte løsningen som lite optimalt. Derfor måtte det gjøres en endring, slik at hele feltet som er relatert til Min side ble gjort om til en link for brukerprofilen. På figur ser vi et bilde av musetasten som ikke reagerer når den befinner seg på Min side i samme feltet som linken til brukerprofilen befinner seg. 23

174 Testdokumentasjon Figur Knapp til brukerprofil En ting til vi noterte oss, som både ble kommentert av en user og en admin, var navnet på 3. timemåling. Vi lagde dette navnet ut ifra hvordan det originale skjemaet så ut. I skjemaet stod det analyseverdier og målerverdier, disse ble foretatt hver 3. time. Disse skulle legges under samme menyvalg i BassengWeb og de fikk inntil videre navnet 3. timemåling. Dette var faktisk noe vi hadde håpet på at noen skulle kommentere, og begge brukerne foreslo navnet vannmåling Brukertest admin Første testperson ut var en av administratorene. De kommenterte at det var svært ønskelig med et IT-system for å registrere målinger av bassengene, ettersom dagens løsning gjør det vanskelig ved uthenting av målinger over et lengre tidsperspektiv. Ettersom administrator har mer ansvar, og bruker dagens løsning i større grad, er det naturlig at de hadde mer å kommentere. Eksempelvis ble vi fortalt at det ved en tidligere anledning hadde vært behov for diagrammer som kunne vise gitte verdier over tid. Dette var da noe som måtte plottes inn for hånd med penn på papir, ved å lese av gamle skjemaer. Med dagens IT-løsning trenger man kun å klikke på Diagram og deretter foreta seg ønskelige valg. En ting som kom frem allerede under den første testingen, som også dukket opp senere, var lagreknappene inne på Timemåling. Det oppstod en misforståelse hvorvidt man måtte trykke på én 24

175 Testdokumentasjon eller begge knappene. Dette var fordi alle feltene, de til høyre også, ble blanke når man klikket på lagreknappen vi ser på høyre side. Grunnen til at feltene ble blanke var rett og slett fordi siden oppdateres når man trykker på en av knappene. På figur ser vi et bilde av de to like lagreknappene som skapte litt forvirring under brukertestingen. Figur: To like lagreknapper skapte forvirring Vi hørte med testbrukerne om de hadde noen forslag til løsning på problemet. Ett forslag som gikk igjen, både hos dem og hos oss, var å gi knappene forskjellige navn. På gruppemøtet etterpå ble alle enige at dette var en forbedring alle kunne gå god for. Slik knappene er i dag, vil brukeren få besvart et eventuelt spørsmål om han/hun er nødt til å klikke på én eller begge. På figur under er bilde av de nye knappene. Det kommer altså på denne måten tydeligere frem at det er to forskjellige skjemaer som lagrer uavhengige verdier. 25

176 Testdokumentasjon Figur Nye navn på lagreknappene Videre i testingen var det en ting som gikk igjen hos alle testobjektene. Dette var rett og slett en bug som skjulte seg under Diagram. Det som skjedde var at punktene ble plassert uavhengig av hverandre rundt på skjermen, ettersom vi ønsket oss en graf, var ikke dette helt optimalt. Det som var problemet var nullverdier mellom punktene som gjorde at linjene ble brutt. Dette har vi fått endret på, slik at grafene i dag henger sammen og er enkle å forstå for brukeren. 26

177 Testdokumentasjon Figur Problemer med å få opp en sammenhengende graf Videre var det en ting som også ikke var helt optimalt for våre testbrukere i forbindelse med diagrammene. Dette var at man skulle hente ut ønskelig data i form av et diagram, måtte man foreta ønskelig valg og deretter trykke på hent. Videre så må man huke av ønskelig avkrysningsfelter, som vi ser i punkt to av figur Det som var misforståelsen var at brukeren trodde han/hun måtte huke av avkrysningsfeltene og deretter trykke Hent. Men slik vi hadde intendert det var at brukeren skulle klikke hent etter at han/hun hadde valgt dato, tid og basseng. Deretter var det tid for å huke av ønskelige valg i del to. Vi løste dette ganske greit med å gjøre del 2 usynlig inntil brukeren har valgt ønskelige verdier i del en og klikket hent. På denne måten vil man ikke nøle med når man skal trykke på knappen, ettersom det ikke eksisterer andre valg som kan skape forvirring. Figur: Valgene under diagram ble todelt 27

178 Testdokumentasjon 4.5 Konklusjon av brukertestingen Da vi startet planleggingen av brukertestingen var det viktig for oss å jobbe for å få mest mulig igjen for muligheten. Det var med en gang ganske klart for oss at en kvalitativ måte å teste på ville passe best for BassengWeb, og dette stemte godt. Målet vårt med testingen av å se hvordan BassengWeb fungerer i bruk og hva som fantes av forbedringspotensiale. Dette var testbrukerne flinke til å hjelpe oss med å finne ut av. Som vi har vært inne på i forrige avsnitt var det flere mindre ting som det var nødvendig å gjøre endringer på. Vi opplevde ikke noen problemer med å rette opp i disse feilene, og alle i gruppen var enstemmig enig i hvordan vi skulle håndtere dem. Testbrukerne var totalt veldig positive til BassengWeb, så vi kunne ikke være noe annet enn fornøyd med brukertesten, som fremfor å by på store ubehageligheter, ga oss konstruktive forslag til endring, og ikke minst underbygde det vi har hele tiden har trodd, det at vi har laget en god web-applikasjon. 28

179 Testdokumentasjon 5. Kilder 5.1 Bibliografi 1. Benyon, David. 2010: Designing Interactiv Systems, 2 utgave. Pearson Education (US) 2. Sandnes, E. F. (2011). Universell utforming av IKT-systemer. Oslo: Universitetsforlaget. 29

180 Testdokumentasjon 6. Vedlegg 6.1: Erklæring 6.2: Brukertest admin 6.3: Brukertest user 6.1 Erklæring Bakgrunnen for brukertestingen er vårt hovedprosjekt ved Høyskolen i Oslo og Akershus, med Norges Idrettshøyskole, NIH, som arbeidsgiver. I forkant av brukertestingen ønsker vi at du er klar over hva opplysningene skal brukes til, og hvem som i etterkant vil ha tilgang til disse. Vi har de siste månedene utviklet Bassengweb, en webapplikasjon som i fremtiden skal brukes for registrering av målinger av bassenget, og ellers daglige rutiner rundt driften av bassengområdet ved NIH. I forbindelse med dette ønsker vi å brukerteste applikasjonen, slik at vi kan se brukermønster, samt å se om vi har utviklet Bassengweb slik at det er brukervennlig, og fungerer etter kravspesifikasjonen som ble gitt før prosjektet ble satt i gang. Vi ser ingen hensikt ved å vise til navn, fødselsdato og kjønn i rapporten, da dette ikke vil ha noen hensikt for forskningen. Det er kun opplysninger som kommer frem ved brukertestingen, som vil ha betydning for oss, og som vil videreformidles. Under bruketestingen vil det bli tatt lydopptak, samt et video-opptak av hva som skjer på skjermen, men ikke av deg. Dette vil bli brukt i analyseprosessen som skjer i etterkant av brukertestingen, og vil videre bli slettet innen en periode på to uker. I tillegg til de fem gruppemedlemmene, vil også opplysningene som kommer frem ved testing, bli lest av faglærer og en sensor i en endelig rapport, da dette er et prosjekt som vil bli evaluert. Muligheten for at prosjektet også kan bli lest av andre studenter og tilsatte ved HIOA kan vi ikke se bort ifra, men du vil i rapporten holdes anonym, og sensitiv informasjon vil ikke bli delt. Med dette er du inneforstått med hva opplysningene som kommer frem ved brukertesten vil bli brukt til, og godkjenner herved bruk av disse til nevnt formål. 30

181 Testdokumentasjon Sted/dato: Signatur: Brukertester Signatur: Representant fra gruppa 31

182 Testdokumentasjon 6.2 Brukertest Admin Start: Fortelle litt om eksisterende løsning? Fortell litt om forventninger? 1) Kan du gjøre de første du gjør når du kommer på vakt? Tid: Smidighet: Utfordringer: Total: Notat: 2) Noter ned antall badende den siste timen, 25 badende Tid: Smidighet: Utfordringer: Total: Notat: 3) Skriv ned klorverdien du nettopp har mål, total klor = 2,65, og fritt klor= 2,21. Hvilket resultat får du for bundet klor? Tid: Smidighet: Utfordringer: Total: Notat: 32

183 Testdokumentasjon 4) Klokken er 10, og du skal registrere tre ting du har gjort; ettersyn av solarier, renhold av wc og handicapheis. Tid: Smidighet: Utfordringer: Total: Notat: 5) Fyll ut skjema etter vask. Tid: Smidighet: Utfordringer: Total: Notat: 6) Skriv ut rapport for en rapport i pdf for å få oversikt over gjøremål fra dagens dagvakt. Tid: Smidighet: Utfordringer: Total: Notat: 7) Hent frem diagram; dagens dato, fra kl.8:00 nå, antall badende, og temperaturen fra hovedbassenget. Tid: Smidighet: Utfordringer: Total: Notat: 33

184 Testdokumentasjon 8) Kan du sjekke profilen din? Tid: Smidighet: Utfordringer: Total: Notat: 9) Opprett ny bruker; AneHan/PerHan som vanlig bruker. Tid: Smidighet: Utfordringer: Total: Notat: 10) Kan du endre AneHan/PerHan til admin? Tid: Smidighet: Utfordringer: Total: Notat: 11) Kan du deaktivere brukeren? Tid: Smidighet: Utfordringer: Total: Notat: 34

185 Testdokumentasjon Avslutning: Hvordan synes du dette gikk? Hva var «greit»? (Om dette er svaret) Helhetsinntrykk: Forståelse av logo: Valg av navn: Navigere på siden: 35

186 Testdokumentasjon 6.3 Brukertest User Start: Fortelle litt om eksisterende løsning? Fortell litt om forventninger? 1) Kan du gjøre de første du gjør når du kommer på vakt Tid: Smidighet: Utfordringer: Total: Notat: 2) Noter ned antall badende den siste timen, 25 badende Tid: Smidighet: Utfordringer: Total: Notat: 3) Skriv ned klorverdien du nettopp har mål, total klor = 2,65, og fritt klor= 2,21. Hvilket resultat får du for bundet klor? Tid: Smidighet: Utfordringer: Total: Notat: 4.1) Klokken er 10, og du skal registrere tre ting du har gjort; Tid: Smidighet: Utfordringer: Total: Notat: 36

187 Testdokumentasjon 4.2) Det er lørdag, og du skal registrere tre ting du har gjort; Tid: Smidighet: Utfordringer: Total: Notat: 4.3) Klokken er 19, og du skal registrere tre ting du har gjort; Tid: Smidighet: Utfordringer: Total: Notat: 5) Fyll ut skjema etter vask. Tid: Smidighet: Utfordringer: Total: Notat: 6) Skriv ut rapport for en rapport i pdf for å få oversikt over gjøremål fra vakt. Tid: Smidighet: Utfordringer: Total: Notat: 7) Kan du sjekke profilen din? Tid: Smidighet: Utfordringer: Total: Notat: 37

188 Testdokumentasjon Avslutning: Hvordan synes du dette gikk? Hva var «greit»? (Om dette er svaret) Helhetsinntrykk: Forståelse av logo: Valg av navn: Navigere på siden: 38

189 BassengWeb Hovedprosjekt ved HIOA 2014 Brukerveiledning Brukerveiledning 1

190 BassengWeb Hovedprosjekt ved HIOA 2014 Brukerveiledning Forord Brukermanualen er ment som en forklaring og veiledning til som ønsker å ta i bruk BassengWeb. Først beskrives applikasjonen for user, deretter går den inn på funksjonalitet knyttet til en admin. Det er brukt bilder i kombinasjon med tekst, for at dokumentet skal være mest mulig forståelig. Helt til slutt vises det til ulike feilmeldinger som en bruker kan støte på, og videre hvordan man kan løse disse. NB: Målinger er i teksten definert som fanene i BassengWeb: Timemåling, Vannmåling og Oppgaver. Oppgaver er i teksten definert som fanene i BassengWeb: Rutiner (Dagvakt, Kveldsvakt, Helgevakt) og Vask med CM. 2

191 Brukerveiledning Innholdsfortegnelse 1. Generelt Innlogging Hovedsiden Navigasjonsmeny Min Side Registrering av måling Timemåling Vann måling Oppgaver Registrering av oppgaver Søk Generering av rapport PDF Excel Diagram Admin Min side / Adminpanel Opprettelse av bruker Redigering av bruker Deaktivering av bruker Aktivering av bruker Endringslogg Adm in Søk Redigering av målinger/oppgaver Sletting av målinger/oppgaver Feilmeldinger

192 BassengWeb Hovedprosjekt ved HIOA 2014 Brukerveiledning 1. Generelt BassengWeb består av to hoveddeler. Den første er fra brukeren users perspektiv, og den andre fra brukeren admin sitt perspektiv. En admin har tilgang til alt av funksjonalitet en user har tilgang til, i tillegg til dette har admin også tilgang til en mer funksjonalitet som er nærmere beskrevet under punkt 10. Først beskrives installasjonsprosessen, og krav knyttet til installasjon. Deretter er det en stegvis veiledning gjennom denne prosessen og eventuelle feilmeldinger knyttet til installasjonen. Videre beskrives BassengWeb fra en users perspektiv, fra navigering i applikasjonen til innlegging av målinger og oppgaver. Til slutt er det en gjennomgang av funksjonalitet knyttet til admin. Når det henvises til noe i bildene i teksten, blir bildene markert med ulike typer farge, nummerert eller tekstet. 4

193 BassengWeb Hovedprosjekt ved HIOA 2014 Brukerveiledning 2. Innlogging For å få tilgang til BassengWeb, må bruker logge inn med brukernavnet som består av fornavnet og førstebokstaven i etternavnet. Eksempel: Fornavn: Ola Etternavn: Nordmann Brukernavnet vil bli: OlaN Bokstaven i etternavnet må ikke være i caps lock. Figur 2 illustrerer innlogging. Figur 2 Innlogging 5

194 BassengWeb Hovedprosjekt ved HIOA 2014 Brukerveiledning 3. Hovedsiden Hovedsiden er det første brukeren møter på etter at innlogging er utført. Denne siden viser navigasjonsmenyen som er statisk på alle sider. Videre er det mulig å se knappene for Min Side øverst til høyre, og Logg ut. Figur 3 viser hovedsiden etter innlogging. Figur: 3 Hovedside 3.1 Navigasjonsmeny Figur 3.1 viser hovedmenyen: 1. Trykk på Timemåling for registrering av målinger som utføres hver time og de 10 siste registrerte timemålingene. 2. Trykk på Vannmåling for å registrere målinger som utføres hver tredje time. 3. Trykk på Oppgaver for å registrere dagens utførte oppgaver. 4. Trykk på Rutiner og velg enten mellom Dagvakt, Kveldsvakt eller Helgevakt for å registrere utføre oppgaver. 6

195 BassengWeb Hovedprosjekt ved HIOA 2014 Brukerveiledning 5. Trykk på Søk for å søke gjennom utførte målinger og oppgaver. 6. Trykk på Vask med CM for å registrere utførte oppgaver. 7. Trykk på Rapport for å generere rapport i enten Excel eller PDF. 8. Trykk på Diagram for å se utførte målinger i grafer. 9. Trykk på Min side for å se registrert informasjon om deg. 10. Trykk på Logg ut for å logge ut av BassengWeb. Figur: 3.1 Navigasjonsmeny 3.2 Min Side I Min side vil informasjon om innlogget bruker bli presentert. Slik figur 3.2 illustrerer så vises ansatt ID, navn, e post og brukernavnet til brukeren. Figur: 3.2 Min Side 7

196 BassengWeb Hovedprosjekt ved HIOA 2014 Brukerveiledning 4. Registrering av måling 4.1 Timemåling Figur 4.1 viser innholdet i Timemåling, her ser vi: 1. For å registrere en bassengmåling må man fylle ut innfyllingsfeltene. Videre må ønskelig basseng velges, merk at det ikke er nødvendig å registrere både Badende Per Time og Temperatur, deretter lagres basseng målingen. 2. Fyll ut Luft temperaturen i svømmehallen, og deretter lagre luft målingen. Husk å velge Svømmehall når du søker etter Luft temperatur i Søk. 3. Viser de 10 siste utførte Basseng målingene. Figur: 4.1 Oversikt over Timemåling 8

197 BassengWeb Hovedprosjekt ved HIOA 2014 Brukerveiledning 4.2 Vannmåling Figur 4.2 illustrerer innholdet i Vannmåling, her registreres målingene utført i det tekniske rommet, samt avlesningen av klor og ph verdier. Brukeren trenger ikke å regne ut bundet klor, dette vil bli gjort automatisk basert på hva som fylles inn i Fritt Klor og Total Klor. Husk at feltene må være i desimaltall med to desimaler, med unntak av Redox som registreres som heltall. Figur: 4.2 Vannmåling 9

198 BassengWeb Hovedprosjekt ved HIOA 2014 Brukerveiledning 4.3 Oppgaver I fanen Oppgaver, finner vi: gjøremål, tilsats av kjemikalier og sirkulasjon/filtrering. Under tilsats av kjemikalier kan brukeren enten velge at kalsiumklorid er utført, eller velge en verdi, se figur 4.3. Figur: 4.3 Oppgaver (Merk Sirkulasjon/filtrering ikke er med grunnet plassmangel) 10

199 BassengWeb Hovedprosjekt ved HIOA 2014 Brukerveiledning 5. Registrering av oppgaver Utførelsen av Dagvakt, Kveldsvakt, Helgevakt og Vask med CM fungerer på samme måte. Figur 5.1 bruker Dagvakt som et eksempel. Oppgaver som er utført for dagen, hukes av med et ikon, slik det som er markert grønt illustrerer nedenfor. Ved oppgaver som kun skal utføres på spesifikke dager, som for eksempel Filterrens / spyle filter, vil ikonet istedenfor være en X andre dager enn de aktuelle dagene. I dette tilfellet vises det en X istedenfor en avkrysningsrute, siden bildet er fra en mandag. Ved siden av gjøremål, er det tatt med de tre første bokstavene til dagene oppgaven skal utføres. Figur 5.1 Avkrysningsfelter for Dagvakt 11

200 BassengWeb Hovedprosjekt ved HIOA 2014 Brukerveiledning 6. Søk I søkefunksjonen er det mulig å søke i utførte oppgaver og målinger. Det kreves ikke at tid og dato er utfylt, men da vil alle målingene/oppgavene vises sortert etter når malingen ble utført, altså at den nyeste komme opp først. Om man derimot skal søke på dato, tid, eller begge deler, må man i tillegg til å fylle ut fra, også fylle ut til. Målinger er markert i figur 6 som blått. Her må det først velges et basseng; hovedbasseng er satt som predefinert. Deretter må type måling velges. Merk: Søk etter luft måling kreve at det velges Svømmehall i basseng. Automatikken er knyttet til automatiserte temperaturmålinger som utføres av Arduino i det tekniske rommet. Oppgaver er i figuren markert som rødt. Her kreves det ikke at basseng er valgt, da oppgavene ikke er knyttet til noen av bassengene. Helt nederst vises de ulike kolonnene for et utført søk, i dette tilfellet for Dagvakt. Derfor starter tittelen på D_. Man ser altså først ID en, deretter tittel, verdi, hvilken ansatt oppgaven ble utført av, og dato og tid for utførelse. Figur: 6 Oversikt over søk 12

201 BassengWeb Hovedprosjekt ved HIOA 2014 Brukerveiledning 7. Generering av rapport Ved generering av rapport velges Rapport i hovedmenyen. Her har man først mulighet til å velge fra og tildato. Slik figur 7 illustrerer; målinger er venstrestilt med basseng som overordnet. Et annet basseng velges, om det ikke skal genereres rapport for Hovedbasseng, som er satt som predefinert. Oppgaver er i rapport høyrestilt. Videre er det to muligheter; rapporten kan genereres i PDF eller i Excel format. Figur: 7 Rapport 13

202 BassengWeb Hovedprosjekt ved HIOA 2014 Brukerveiledning 7.1 PDF Ved generering av rapport i PDF, vil filen lastes ned med filnavnet: TimerMinutterSekunder, for eksempel vil en rapport som blir generert klokken 19:44:43 få tildelt filnavnet pdf. I dette tilfellet, som figur 7.1 illustrerer, er Hovedbasseng og timemåling valgt i søket for rapporten som er generert. Tabellen viser følgende informasjon fra søket: tittel for måling, verdi, tid, og dato for når målingen ble utført. Deretter basseng og den ansatte som utførte målingen. Figur: 7.1 Skjermdump fra generert PDF fil for timemåling. 14

203 BassengWeb Hovedprosjekt ved HIOA 2014 Brukerveiledning 7.2 Excel Ved generering av rapport i Excel, med utgangspunkt i valgene Hovedbasseng og timemåling, vil innholdet vises som i figur 7.2 (se bort i fra den første raden med innholdet sep=<x>, da dette er kun der for å skille innholdet i egne celler). Her ser vi samme innholdet som vist ovenfor i punkt 7.1. Figur: 7.2 Skjermdump fra en generert excel fil for timemåling. 8. Diagram Ved å velge diagram, som vises i figur 8.1, må først dato, tid og basseng fylles inn (se 1) og deretter må Hent knappen trykkes på fr at valgene om ulike målinger skal dukke opp. Når dette er gjort er det mulig å velge mellom ulike målinger dynamisk (se 2). Når et eller flere av innfylingsfeltene er valgt, vil et diagram dukke opp under, som vist i figur

204 BassengWeb Hovedprosjekt ved HIOA 2014 Brukerveiledning Figur: 8.1 Søk i diagram I dette tilfellet er AutoTemperatur valgt. Her viser y aksen verdi, mens x aksen viser tiden. Dersom flere målinger er valgt, vil disse ha forskjellige farger, noe som vil gjøre det enklere å skille disse fra hverandre. Hvert punkt i linje diagrammet er en måling, og dersom man tar muse pekeren over, vil man kunne se dato, tid og verdien for den aktuelle målingen. Det er også mulig å zoome inn. Dette gjøres enkelt ved å markere området man ønsker å ta en nærmere titt på. Ved å høyreklikke kan man enkelt tilbakestille til normal visning. Figur: 8.2 Etter søk 16

205 BassengWeb Hovedprosjekt ved HIOA 2014 Brukerveiledning 9. Admin Som administrator har man tilgang til flere funksjoner under Min side enn det en user har under Min side, dette beskrives mer nøye i dette kapitlet. 9.1 Min side / Adminpanel Figur: 9.1 Min side for en admin bruker I figur 9.1 kan man se de forskjellige funksjonene som er tilgjengelige for en admin i BassengWeb. Her kan man opprette, redigere, deaktivere og aktivere brukere, samt se en endringslogg som beskriver endringer gjort på registrerte målinger/oppgaver. Tallene på figuren blir beskrevet i respektive punkter nedenfor. 17

206 BassengWeb Hovedprosjekt ved HIOA 2014 Brukerveiledning Opprettelse av bruker Under opprettelse av en ny bruker, må admin legge inn informasjon om brukeren som skal opprettes; navn, e post og brukertype skal defineres her. Nye brukere blir automatisk aktivert, dette behøver altså ikke å gjøres separat. Brukernavn for brukeren blir også automatisk generert basert på for og etternavn, og blir hele fornavnet pluss første bokstav i etternavnet. Eksempel: Fornavn: Ola Etternavn: Nordmann Brukernavnet vil bli: OlaN Figur viser skjermen for opprettelse av bruker. Figur: Skjermbilde for opprettelse av ny bruker 18

207 BassengWeb Hovedprosjekt ved HIOA 2014 Brukerveiledning Redigering av bruker En admin har muligheten til å redigere eksisterende brukere, dette ligner mye på opprettelsen, og figur viser ett bilde av hvordan det ser ut. Merk; Om passordfeltene står tomme, vil passordet forbli det samme som brukeren allerede er registrert med. Figur: Redigering av eksisterende bruker 19

208 BassengWeb Hovedprosjekt ved HIOA 2014 Brukerveiledning Deaktivering av bruker En bruker som ikke lenger er i bruk, kan deaktiveres for å hindre at vedkommende skal ha videre tilgang til applikasjonen. Man velger ut e posten til brukeren, og trykker deretter på deaktiver. Dette er markert rødt på figur 9.1. Man får opp en bekreftelsesskjerm for deaktiveringen, som viser informasjon over brukeren som skal deaktiveres. Her kan man bekrefte deaktiveringen, og brukeren er med dette deaktivert Aktivering av bruker Når en bruker er deaktivert, havner brukeren sin e post i listen velg bruker som skal aktiveres, markert grønt på figur 9.1 Her kan man ganske enkelt velge brukeren man vil aktivere, og bekrefter med Aktiver Bruker. Etter dette er brukeren aktivert og han/hun kan logge inn Endringslogg Endringsloggen lagrer redigeringer/slettede verdier som er foretatt på lagrede målinger/oppgaver, se figur 9.1. Her kan man se når noe ble endret, hva som ble endret, hva det som ble endret ble endret til, og hvem som foretok endringen. Slettede verdier lagrer for så vidt bare at det er slettet med Ingen som ny verdi. Det er også lagt inn funksjoner for å filtrere hva som vises i endringsloggen på dato, man kan søke mellom to datoer, og endringene gjort mellom disse to datoene blir vist. Det er også en knapp for å vise alle endringer igjen etter at ett søk har blitt gjort. Figur viser skjermen for endringsloggen. Merk at original id referer til id en for den registrerte målingen/oppgaven og ikke id en i endringsloggen. 20

209 BassengWeb Hovedprosjekt ved HIOA 2014 Brukerveiledning Figur: Endringsloggen med en redigering og en sletting som har blitt gjort 9.2 Admin Søk Her har admin mulighet til å søke gjennom lagrede målinger og oppgaver. Søket gir mulighet til å filtrere resultatene på en rekke kriterier. Resultatene blir vist på flere sider, om det er mer enn 25 resultater av ett gitt søk, dette for å spare plass. Det er en liten forskjell mellom user og adminsøkeskjermen, da admin har to ekstra knapper; en for å redigere og en for å slette resultatene. Figur 9.2 viser de to ekstra knappene en admin har tilgang til. Figur: 9.2 Admin søk 21

210 BassengWeb Hovedprosjekt ved HIOA 2014 Brukerveiledning Redigering av målinger/oppgaver Her har admin mulighet til å redigere en måling/oppgave som er lagret, redigering kan gjøres av verdi, tid, dato og hvem den ble utført av. Når dette er gjort lagres også endringen i endringsloggen. Figur viser hvordan skjermen ser ut når man redigerer. Figur: Redigering av en måling Sletting av målinger/oppgaver Når man trykker på slett, blir man sendt til en side som på samme måte som redigering, viser all data lagt inn for det spesifikke resultatet, samt en knapp for å bekrefte slettingen. Her blir også slettingen lagret i endringsloggen, se figur for skjermbilde for sletting av en måling. 22

211 BassengWeb Hovedprosjekt ved HIOA 2014 Brukerveiledning Figur: Sletting av en måling 10. Feilmeldinger Feilmeldinger i applikasjonen er knyttet til validering av data. Når man lagrer en måling eller en oppgave, skal enkelte verdier skrives inn med desimaler. For eksempel skal temperatur alltid inneholde to desimaler. Figur 10.1 viser ett eksempel på feilmeldinger der timemålingsverdiene ikke tilfredsstiller kriteriene. Figur: 10.1 Feilmeldinger for lagring av timemåling Det er også en rekke feilmeldinger knyttet til validering av informasjon under opprettelse eller redigering av brukere. Disse er stort sett de samme, da informasjonen som skal settes inn både i opprettelse og i redigering er av samme type. Figur 10.2 viser hvordan disse ser ut. 23

212 BassengWeb Hovedprosjekt ved HIOA 2014 Brukerveiledning Figur: 10.2 Feilmeldinger for opprettelse/redigering av brukere 24