FoodView. Hovedprosjekt, våren Gruppe 30: Muhammed Ibraheem Cheema. Steinar Iversen. Erling Sandbekk. Geir Løitegaard Henrik Skjolden

Transkript

1 FoodView Hovedprosjekt, våren 2013 Gruppe 30: Muhammed Ibraheem Cheema Steinar Iversen Erling Sandbekk Geir Løitegaard Henrik Skjolden

2 PROSJEKT NR. 30 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL FoodView PROSJEKTDELTAKERE 5 TILGJENGELIGHET Info på CD DATO ANTALL SIDER / BILAG 72 / 2 INTERN VEILEDER Kirsten Ribu Telefon: Telefaks: OPPDRAGSGIVER QlikTech Norge AS/Intrinsic AS KONTAKTPERSON Petter Skjolden SAMMENDRAG Dette er rapporten til hovedprosjektet FoodView våren Vi har laget en QlikView-applikasjon som gjør oppslag i matvaretabellen til mattilsynet. QlikView er et rammeverktøy innen BI som dynamisk henter informasjon fra ulike kilder og sammenstiller og presenterer informasjonen ved hjelp av ulike objekter i programmet. Denne tabellen opplyser om næringsinnholdet i mange ulike matvarer vi finner her i landet. Disse to kombinerer vi for å tilby brukere et nytt og bedre verktøy for informasjon og sammenligning av mat og måltider. Vi var tre forskjellige grupper som slo oss sammen til én gruppe. Gruppen består av to personer fra dataingeniør, to fra informasjonsteknologi og én fra anvendt datateknologi. Vi kom i kontakt med faren til Henrik Skjolden, som jobber i QlikTech. Han tilbød oss en oppgave hvor vi skulle utvikle en nettapplikasjon, til bruk for demonstrasjon, ved hjelp av verktøyet, QlikView. Han foreslo å hente ut verdier fra matvaretabellen som matportalen legger ut for offentlig bruk, og bruke QlikView for å vise det frem på en bedre måte. I matvaretabellen ligger det tabeller med den aller vanligste norske maten, og viser da altså næringsinnholdet. Dette skulle vi da hente ut fra et nettsted og deretter presentere ved hjelp av QlikView. QlikView er en Business Intelligence-applikasjon som henter frem informasjon fra ulike systemer, hvorpå man kan presentere og sammenstille denne dataen på nye måter. Verktøyet er lett å benytte for nybegynnere, til å lage enkle applikasjoner, men det er også mye dybde i programmet til å implementere mer komplekse løsninger. Vi begynte med å ha en workshop hvor vi fikk opplæring i selve QlikView, før vi hadde idémyldring hvor vi kastet frem alt vi kunne tenke oss å ha i applikasjonen. Oppdragsgiver var med på å sette opp kravspesifikasjon, og har i tillegg gitt oss veldig mye bra veiledning og tips underveis. 3 STIKKORD Matvaretabellen QlikView Nettapplikasjon 2

3 Forord: Dette er rapporten til hovedprosjektet FoodView våren Vi har laget en QlikViewapplikasjon som gjør oppslag i matvaretabellen til mattilsynet. QlikView er et rammeverktøy innen BI som dynamisk henter informasjon fra ulike kilder og sammenstiller og presenterer informasjonen ved hjelp av ulike objekter i programmet. Denne tabellen opplyser om næringsinnholdet i mange ulike matvarer vi finner her i landet. Disse to kombinerer vi for å tilby brukere et nytt og bedre verktøy for informasjon og sammenligning av mat og måltider. Vi var tre forskjellige grupper som slo oss sammen til én gruppe. Gruppen består av to personer fra dataingeniør, to fra informasjonsteknologi og én fra anvendt datateknologi. Vi kom i kontakt med faren til Henrik Skjolden, som jobber i QlikTech. Han tilbød oss en oppgave hvor vi skulle utvikle en nettapplikasjon, til bruk for demonstrasjon, ved hjelp av verktøyet, QlikView. Han foreslo å hente ut verdier fra matvaretabellen som matportalen legger ut for offentlig bruk, og bruke QlikView for å vise det frem på en bedre måte. I matvaretabellen ligger det tabeller med den aller vanligste norske maten, og viser da altså næringsinnholdet. Dette skulle vi da hente ut fra et nettsted og deretter presentere ved hjelp av QlikView. QlikView er en Business Intelligence-applikasjon som henter frem informasjon fra ulike systemer, hvorpå man kan presentere og sammenstille denne dataen på nye måter. Verktøyet er lett å benytte for nybegynnere, til å lage enkle applikasjoner, men det er også mye dybde i programmet til å implementere mer komplekse løsninger. Vi begynte med å ha en workshop hvor vi fikk opplæring i selve QlikView, før vi hadde idémyldring hvor vi kastet frem alt vi kunne tenke oss å ha i applikasjonen. Oppdragsgiver var med på å sette opp kravspesifikasjon, og har i tillegg gitt oss veldig mye bra veiledning og tips underveis. 3

4 Innholdsfortegnelse 1. Innledning Bakgrunn Gruppen Arbeidsfordeling: Arbeidsforhold Oppdragsgiver Om oppdragsgiver Støtte fra oppdragsgiver: Mål for oppgaven Planlegging... 8 Forhold til dokumentasjonsstandard Styringsdokumenter Fremdriftsplan Risikoanalyse Rammekrav Logisk datamodell Krav til systemkonstruksjon Krav til dokumentasjon Krav til manuelle funksjoner Verktøy og systemkrav Systemkrav for QlikView-programvaren Benyttede verktøy Prosessdokumentasjon Introduksjon, generelt Startfasen/Kursing Teknologi Idémyldring Kravspesifikasjon Design og prototyping Forkunnskaper og videre utvikling Utviklingsprosessen Utviklingsmodell/metode

5 3.2.2 Utviklingsfaser: Individuelle beskrivelser av arbeidet Produktdokumentasjon Introduksjon Load Script: Hoveddel Om de ulike sidene i applikasjonen Avslutning Extensions: Testing Enhetstest Gjennomføring: Resultat: Systemtest Gjennomføring: Resultat: Brukertest Utrulling Konklusjon Resultat Ferdig implementert: Delvis implementert: Ikke implementert: Oppsummering Generelt Hva kunne blitt gjort annerledes: Muligheter...55 Kilder:...56 Bøker:...56 Nettsider/nettressurser:...56 Ordliste...57 Vedlegg 1, Dagbok...58 Vedlegg 2, Fremdriftsplan

6 1. Innledning 1.1 Bakgrunn Vi hadde muligheten til å jobbe med Business Intelligence gjennom BI-produktet QlikView. Dette var for oss et nytt felt innen informasjonsteknologi og produktet er et nytt og spennende konsept innen BI. Med gode kontakter i QlikTech var det derfor meget spennende for oss å jobbe med hovedprosjektet innenfor dette feltet og med dette verktøyet. Vi ville lage en web-applikasjon ved hjelp av QlikView og Matvaretabellen fra Matportalen.no. Dette er en ernærningstabell utgitt av Mattilsynet, Helsedirektoratet, Vitenskapskomiteen for mattrygghet, Nasjonalt folkehelseinstitutt, Veterinærinstituttet, Bioforsk, Statens strålevern og Nasjonalt institutt for nærings- og sjømatforskning (NIFES) Denne applikasjonen skal vise frem mulighetene i QlikView og sortere og presentere informasjonen i ulike relevante former, og gjøre informasjonen mer tilgjengelig, relevant og interessant. Dette kan da sees på som en uoffisiell oppgradering av programmet "Mat på Data". Mat på data er en applikasjon utviklet av mattilsynet, som viser frem disse dataene på en ganske enkel måte. Det kan det også være aktuelt å kunne knytte denne applikasjonen til andre informasjonskilder for å bygge om et mer helhetlig tema, eksempelvis helse og trening. I tillegg kan det være aktuelt å bygge opp om en "personlig" applikasjon med muligheter for loggføring og benytte mobile enheter som hjelpemiddel rundt hovedapplikasjonen. QlikTechs motivasjon i dette prosjektet er å øke bevisstheten rundt områdene BI og BD (Business Discovery), i tillegg til eventuell merverdi dette kan gi som markedsføring for bedriftens produkt. Dette er da et ledd i firmaets tankegang og inspirasjon: "Touch a billion lives". Mattilsynet drifter en nettside som heter matportalen.no. Her finnes diverse informasjon om mat og næring, blant annet er det lagt ut en næringstabell med informasjon om de fleste norske matvarer og deres innhold. 1.2 Gruppen Gruppen som helhet har ikke jobbet sammen tidligere. Vi slo oss sammen tidlig i januar og etablerte prosjektidèen sammen. Vi stiller høye krav til oss selv, så kompetansenivået i gruppa var relativt høyt. Vi ble godt kjent med hverandre, og fungerte tilfredsstillende som gruppe. Vi fant ut tidlig at vi ville satse på denne oppgaven, også fordi det ikke var så mange andre relevante og spennende oppgaver tilgjengelig,. Vi delte inn ulike roller ganske tidlig i prosjektfasen. 6

7 Gruppen har medlemmer fra hver datalinje fra HiOA. Det er alltid krevende når nye grupper opprettes for et slik stort prosjekt. Derfor er det viktig med et godt samarbeid i gruppa, og at man utnytter hvert enkelt gruppemedlems styrke Arbeidsfordeling: Arbeidsfordelingen har variert gjennom alle prosjektets faser. Under utviklingen stilte det store krav til gruppemedlemmene som måtte kode og løse problemer. I sluttfasen var det fullt fokus på dokumentasjonen. Det har ikke vært noe problem å spørre andre gruppemedlemmer om å ta over en jobb, hvis man har hatt for mye å gjøre. Vi har jobbet med tanke på fleksibilitet og arbeidsfordelingen har vært jevnt fordelt under hele prosjektløpet. Noe av problemene med programmeringsoppgavene er at det ofte er blir slik at arbeidsoppgaver blir skjevt fordelt. Spesielt tidlig i utviklingsfasen ble dette et problem, og personene som satt å programmerte fikk litt for store oppgaver. Sånn vi ser det i ettertid burde vi jobbet med i forkant av programmering, sånn at hadde mer plan over hva vi faktisk skulle programmere. Vi hadde bare satt opp en enkel scetch på hva vi skulle gjøre. Vi burde ha løst dette med å ha flere varierte oppgaver i sprinten. Ikke bare oppgaver som fokuserte på selve sluttproduktet til applikasjonen, men satt opp detaljerte planer for hvordan vi ville produktet skulle se ut. Vi burde ha papirprogrammert mer underveis, slik at de som utviklet produktet kunne ha bedre definerte oppgaver på forhånd Arbeidsforhold Gruppen har aldri jobbet sammen før, og vi begynte planlegging av dette i januar. Vi så ikke på dette som et problem, men heller som en fin utfordring. Alle har forskjellig kompetanse, og forskjellige måter å arbeide på, men dette fungerte bra gjennom hele prosjektet. Fleksibilitet, samarbeid og kommunikasjon er nøkkelord for samarbeidet vårt. Vi hadde faster dager hvor vi jobbet sammen på skolen. Dette var hensiktmessig både med tanke på at vi hver for oss hadde ulike fag parallellt med hovedprosjektet og at det gav oss andre arbeidsmetoder og til dels muligheter. Fra januar til april møttes vi tirsdag, torsdag og fredag på skolen. Det ble også jobbet i snitt en til to helger i måneden. To av gruppemedlemmene arbeidet best hjemmefra på deres stasjonære pc er. Kontakten med de som møtte opp på skolen ble holdt via skype, både i form av tale og tekst noe som har blitt flittig brukt gjennom hele prosjektet. Det ble også holdt møter hvor alle møtte uansett for å få til en bedre kommunikasjon. 1.3 Oppdragsgiver Om oppdragsgiver QlikTech er et raskt voksende software-selskap innenfor området BI (Business Intelligence). QlikTech ble grunnlagt i Lund i Sverige i Selskapet utvikler et verktøy som heter QlikView, og ønsker at vi skal utvikle en demonstrasjonsapplikasjon på vegne av dem. Dette verktøyet brukes mye til rapportering og informasjonsanalyser for å se trender, salg, og oversiktsbilder av 7

8 stor data. Selskapet har 11 årsverk her i Norge, og har kontor på Skøyen her i Oslo. Internasjonalt har selskapet 1600 ansatte og har hovedkontor i Radnor, Pennsylvania. Selskapet har hatt en stor vekst, og er notert på NASDAQ-børsen i New York. Selskapet har ca estimert kunder i 100 forskjellige land. Selskapet har en verdi på rundt 2 milliarder dollar Støtte fra oppdragsgiver: Vår kontakt fra QlikTech (Petter Skjolden) har vært veldig tilgjengelig for gruppen hele veien, gjennom mail, telefon og møter. Han stilte også med møterom i starten slik at vi kom i gang med presentasjon og kursing i QlikView hos QlikTech i deres lokaler på Skøyen. Han var også innom for å sjekke utviklingen i prosjektet, og følge opp som oppdragsgiver. Kontakten var også aktiv med tips og råd for å gjøre applikasjon enda bedre. Opplysninger om bugs fra QlikViews side og workarounds fikk vi også etter å ha fått slike problemer. 1.4 Mål for oppgaven Vi har som mål å lage en web-applikasjon ved hjelp av QlikView. Denne applikasjonen skal presentere Matvaretabellen og vise innovative løsninger rundt matportalen sine tall. Informasjonen hentes dynamisk og kontinuerlig fra oppgitt datakilde (matportalen.no) ved hjelp av QlikView. Hovedmålene er som følger: Lære å utvikle/programmere i QlikView Bruke funksjoner innebygd i QlikView så langt det lar seg gjøre Utvikle en web-applikasjon ved hjelp av verktøyet QlikView Presentere næringsdata via web-applikasjon til allment bruk Designe applikasjonen med tanke på brukervennlighet Utvikle dokumentasjon og brukerveiledning for applikasjonen Hente informasjon om alternative kilder, eventuelt legge til rette for videreutvikling av applikasjonen med data fra flere kilder og for flere formål innen samme tema Dersom tiden tillater det; utvikle muligheter for "personlig" applikasjon med logg, egen input, egne felt m.m. Utvikle et moderne brukergrensesnitt. 2 Planlegging For å kunne få en bedre oversikt over prosjektet har vi løpende skrevet prosjektdagbok for gruppen og diverse hjelpedokumenter. Prosjektdagboka har bare blitt ført med enkle stikkord, og hver enkelt har hatt ansvar for føre opp sin egen logg med hva man har gjort iløpet av perioden. Dagbok ble ført fortløpende i starten, og vi har fulgt den ut i hele prosjektperioden. Forhold til dokumentasjonsstandard Vi har til dels fulgt dokumentet "Hovedprosjektet i data/it Dokumentsstandard"[2] av Ann-Mari Torvatn. Dette gjorde vi for å sørge for alt var godt strukturert, dokumentert og at prosjektrapporten inneholdt det nødvendige og relevante. 8

9 Styringsdokumenter Versjonskontroll og backup Ingen versjonkontroll Backup kjøres i Googles cloud-løsning, Google Drive 2.1 Styringsdokumenter Gjennom prosjektet har vi utarbeidet noen styringsdokumenter, de er som følger: Statusrapport Prosjektskisse Forprosjektrapport Prosjektdagbok Risikoplan Arbeidsplan og fremdriftsplan Fremdriftsplan Vi hadde en fremdriftsplan for å ha en god oversikt over arbeidet vi planla å gjennomføre. Dette er for å få oversikt og sette av tilstrekkelig tid, og for å styre arbeidet fra uke til uke. Vi satte den for å være realistisk, men ambisiøs. Vi brukte den flittig for å holde oversikt over hva vi skulle gjøre. Se vedlegg for fullstendig fremdriftsplan Risikoanalyse I ethvert prosjekt er det viktig å ha en risikoanalyse for å kunne forutse eventuelle problemer som kan oppstå. Dette kan bli veldig sårbart i et utviklingsprosjekt, siden det ofte kan være 9

10 vanskelig å erstatte noen om det skulle oppstå problemer. Her har vi også lagt inn visse tiltak for eventuelle problemer som kan dukke opp. Risiko Sannsynlighet Konsekvens Tiltak Sykdom Middels Fordele arbeid på Flere gruppemedlemmer. Oversikt over hva hver enkelt driver med. Arbeide jevnt under hele perioden. Frafall fra gruppen Liten Kan føre til mer arbeid. Kan miste viktig kompetanse i gruppa. God stemning i gruppa, og arbeide godt sammen. For dårlig kompetanse Middels Kan bruke lang tid på å løse et problem. Forberede seg godt når man skal jobbe, og å prøve og forutse eventuelle problemer. Rekker ikke innlevering Lav Ikke bestått, karaktertrekk. God planlegging, fokus på milepæler og del-innleveringer. Tap av data Lav Kan være kritisk for prosjektet, men liten sannsynlighet at dette skjer. Ha backup av backup. Ha kontroll på versjoner, og være forsiktig om man skal slette. Konflikter i gruppa Middels Problemer og frustrasjon hos gruppemedlemmer. Dårlig arbeid fører ofte til konflikter. God konfliktløsning. Ha en løs og fin tone i gruppe. Gjøre et godt arbeid, slik at resultatet blir bra. Manglende dokumentasjon Høy Vanskelig å skrive rapport, og sette seg Skrive dokumentasjon 10

11 inn i prosjektet i etterkant. underveis. Følge opp at det gjøres. For stor arbeidsmengde i sprint Høy Må utsette oppgaver og prosjektet blir forsinket. Ikke ferdig med produktet til slutt Ikke sette for høye mål for hver sprint. Jevnlig sjekk av tidsbruken, slik at man ser hvor mye man har igjen Rammekrav Det er et krav at det både på server og klientside må være støtte for HTML 5. Scripting på serversiden skrives i hovedsak i QlikView s eget script-språk. For eventuelle makro er benyttes VBScript eller JScript. For eventuelle extensions benyttes standard javascript. Det er også nødvendig å legge til rette for implementering av flere språk når det gjelder brukerinformasjon og visning av informasjonen. Dette gjelder for både tekst i programmet og for eventuelle kulturelle forskjeller i informasjonen og benevninger/units o.l. I tillegg er det et krav at det skal legges til rette for en velintegrert brukerveiledning i applikasjonen, med pop-ups og relevant informasjon "der og da". Det skal blant annet benyttes løs eller tett kobling til wikipedia for detaljert informasjon om relevante emner. Under utviklingshensyn er det viktig å nevne at det er nødvendig med gyldig QlikView-lisens for å kunne ferdigstille og hoste en slik applikasjon. Det er tilgjengelig for nedlasting en såkalt personal edition som er lisensløs, men denne tillater ikke direkte deling av informasjon. Denne kan benyttes for å utvikle egne applikasjoner, men tillater kun et begrenset antall view/open av eksterne QlikView-dokumenter. Det er et rammekrav at det under hele utviklingsprosessen skal legges til rette for videre utvikling av applikasjonen. Dette gjelder både forbedringer og utvidelser med nye elementer og funksjoner. Eksempelvis: Skal følge en gitt navnestandard for å gjøre utvidelser og forbedringer lettere å implementere Dokumentere utvikling og utviklingsprosessen for senere utviklingshensyn Tettere integrering med mobile enheter, egen mobil-app for ios, Android og Windows 8 Inkludere flere språk i programmet Inkludere data/informasjon fra flere land/områder Muligheter for sammenligning av data fra ulike land Flere funksjoner og valgmuligheter med tanke på personliggjøring og lagring/benytting av personlig informasjon 11

12 Alternativer for visningsmåte/designvalg for bruker av applikasjonen I tillegg følger det visse krav til design og brukervennlighet når målgruppen vår er konsumenter. Tekst og språk som benyttes i programmet skal være allmennt og generelt forståelig, det skal ikke være nødvendig med teknisk bakgrunn for å forstå og benytte programvaren. Design og grensesnitt skal være konstruert på en intuitiv måte for å gjøre programmet lett å lære og navigere. Design skal i tillegg være utformet med fokus på enkelhet, dvs. ikke overflødige og forstyrrende elementer i grensesnitt, samt rask og enkel vei for å fullføre ønskede funksjoner. Funksjoner som benyttes ofte må fremheves og optimaliseres. Dette gir et bilde på fokuset vårt under utviklingen. Det er satt opp generelle punkter. Senere vil analyser og diagrammer for relevante punkter gi et mer detaljert bilde av kravene Logisk datamodell Her følger en visuell beskrivelse av hvordan hoveddelen av applikasjonen vil fungere. QlikView assosierer automatisk feltnavn, men kilder/info kan lastes inn i ulike tables. Vi ser for oss en oppdeling av programmets informasjon og funksjon i moduler for å legge til rette for eventuelle utvidelser. Selve matvaretabellen ligger i NorwegianFoodTable. Matvaretabellen inneholder en samlet oversikt over innhold av energi og næringsstoffer for de vanligste matvarene som spises i Norge. Denne tabellen lastes ned ifra matportalens egen hjemmeside: %28.xls%29 Tabellen blir deretter filtrert for å fjerne uønskede rader, kolonner og celleverdier. Tabellen har også fått opprettet en input-kolonne ved navn Mengde. Denne kolonnen fungerer ved å la brukeren sette inn verdier til en hvilken som helst rad. Kolonnen benyttes i opprettelse av måltid, hvor den spesifiserer hvor stor mengde av en ingrediens som skal i måltidet. Under Forbrenning benytter vi oss også av mengder; her for å få regnet ut energien i den ønskede 12

13 mengden av utvalgte matvarer. Deretter kan vi regne ut hvor lang tid det tar å forbrenne totalenergien. NorwegianFoodTable -tabellen er knyttet til meal -tabellen via en mange-til-mange relasjon. NorwegianFoodTable - og meal -tabellene har hver en èn-til-mange relasjon med ingredient - tabellen. Nøklene her er MealID og MatvareID. Her vil et måltid kunne inneholde flere ingredienser, og en matvare vil kunne bli benyttet som ingrediens i flere måltid. Tabellen meal inneholder to kolonner. MealID(int) benyttes til å identifisere måltidet. Meal(varchar(30)) benyttes til å navngi måltidet. Her også har det blitt opprettet en inputkolonne ved navn Antall. Denne kolonnen benyttes under Forbrenning for å spesifisere ett antall av hvert utvalgte måltid. Tabellen ingredient inneholder tre kolonner. MealID(int) benyttes til å identifisere hvilket måltid det er snakk om. MatvareID(varchar(11)) identifiserer en matvare (ingrediens). IngrediensMengde(int) holder på mengden, i gram, til ingrediensen. Tabellene meal og ingredient ligger i en database på Programmet synkroniseres umiddelbart med denne databasen når det legges til og fjernes måltider. Hver gang en oppretter eller fjerner et måltid kjøres en Partial Reload som oppdaterer bare meal - og ingredient -tabellene. Dette er en veldig enkel datamodell som lar oss opprette flere måltider med flere ingredienser. Til høyre i bildet kan en se alle dataøyene våre. Disse benyttes til ulike formål: NutrientChartSort; Denne tabellen benyttes til å sortere Næringsinnhold -grafene under Matvarer og Måltid. Sted, Location og Maptype benyttes under Karttjeneste. Denne løsningen er ikke ferdigutviklet. Dette var en utvidelse til programmet vi så på som aktuell, men ikke med veldig høy prioritet. Hovedtanken bak var å la brukeren finne dagligvarebutikker og treningsentre i nærheten. Vi hadde også tanker om å koble dette til forbrenning ved å legge opp treningsruter for så å regne på hva man ville forbrent over disse distansene Krav til systemkonstruksjon For å kunne utvikle eller utvide denne applikasjonen er det nødvendig å kunne QlikView. Dette er hovedverktøyet man benytter seg av for utvikling, men man benytter seg av andre teknologier under utviklingen. Eksempelvis benytter plattformen seg av HTML for visning fra server eller WebView. For macros (utvidelser) benytter seg av enten VBScript eller Jscript (tilsvarende Javascript) og extensions benytter javascript og XML. QlikTech benytter et eget scriptspråk til det viktige Load-Scriptet og for alle expressions for objektene Krav til dokumentasjon Det skal utvikles en brukerveiledning, men det skal i tillegg knyttes tett til applikasjonen med diverse pop-up info, egen introduksjonsside og hjelpeside. Det skal dokumenteres for å vise hvordan vi har tenkt, og hvordan prosjektet er bygd opp. Det er viktig å dokumentere hvordan 13

14 utviklingprosessen har vært, og hvordan vi har tenkt. Applikasjonen skal også knyttes til eksterne lenker som eksempelvis Wikipedia. Det er også viktig å at det dokumenteres, slik at endringer kan gjøres i fremtiden, eller om produktet skal videreutvikles Krav til manuelle funksjoner Ingen krav til manuelle funksjoner 2.2 Verktøy og systemkrav Systemkrav for QlikView-programvaren Alle medlemmene i gruppen disponerte egne laptoper. Vi kjørte QlikView 11 på Windows 7. Det krever en Inter Core Duo-prosessor eller bedre. Minimumkravet er 1 GB ram, men helst opp mot 8GB om det skal fungere godt. Programvaren krever 300 mb. QlikView fungerte med Explorer, Firefox, Chrome og Safari. QlikTech har delt ut 5 ulike educational-licenses til oss, slik at vi har tilgang til alt. Det er mulig å bruke programvaren uten lisens også, men da kan vi ikke dele applikasjonene mellom oss Benyttede verktøy Adobe Photoshop 6 Brukt til å designe deler av hjemmesiden vår. QlikView 11 Programvaren vi utviklet applikasjonen i, og den kan lastes ned gratis fra Denne personlige utgaven har kun én begrensning; filene du lager med denne er låst til din utgave. Man kan likevel låse opp andres filer opp til fem ganger. Vi fikk utdelt lisenser, slik at vi kunne arbeide uten dette hinderet, og gjorde det slik at vi lettere kunne dele mellom hverandre. Skype Gruppen brukte Skype til å kommunisere utenfor skolen. Alt blir logget, og det funker bra for å gi korte beskjeder. Det var av og til lettere å jobbe hjemme, og da kunne vi kommunisere godt sammen uavhengig av hvor vi satt. Google Drive Google Drive ble brukt til å lagre dokumentene, og ha oversikt over alle dokumentene og filene. Passet perfekt for slik bruk, og vi hadde ikke problemer med at noe ble borte, og alt ble lagret der. Backup ble gjort på pc en, med å laste ned programvaren, slik at filene også var lokalt på pc en. Google Docs 14

15 Mesteparten av skrivearbeidet ble gjort i google docs, da dette er knyttet sammen med google drive og oppdateres raskt. Det er her også mulighet for at flere skriver i samme dokument uten versjonstrøbbel. Andre programmer kan ha blitt brukt individuelt av gruppemedlemmene. Teamviewer Logge på pc en fra forskjellige plasser hvis dette var praktisk. Sitte på laptop på skolen, mens man jobbet på den stasjonære pc en hjemme. Ganttproject er et gratisverktøy for å opprette og holde rede på ganttdiagrammer. 15

16 3 Prosessdokumentasjon 3.1 Introduksjon, generelt Startfasen/Kursing I perioden 1. januar til 21. februar hadde vi kursing samtidig som ideémyldring og tidlig planlegging. Det var nødvendig med kursing og veiledning for å raskt kunne sette sett inn i QlikView. Dette er et som sagt et BI-verktøy og krever noe omstilling for studenter. Vi fikk god hjelp i denne fasen av oppdragsgiver. Vi hadde noen intense økter over en månedsperiode hvor vi utforsket programmet, alle dets funksjoner og hvordan disse kunne kombineres. Dette tok lengre tid enn vi forventet. Vi utvidet kursingen to ganger for å kunne hente mer kunnskap. Dette gjorde at vi kom senere igang med produktet. Vi hadde flere helger hvor vi hadde workshop, da vi jobbet med selve QlikView for å komme inn i dette verktøyet. I dette rammeverktøyet er det lett å lære seg det mest grunnleggende, men det kan også bli meget komplekst, avhengig av hvor dypt man ønsker å gå. Selv om vi har jobbet mye med produktet, er det fortsatt veldig mye å lære seg. Blant annet kunne vi gått mye dypere inn på de såalte extensions, tillegg til programmet. Disse programmeres i javascript i ekstern fil og kan brukes som objekter i grensesnittet til QlikView. Med dette verktøyet er det mulig å lage et svært utvidet antall funksjoner til applikasjonen. Dette var også noe vi ønsket å utforske nærmere parallellt med utviklingen for å eventuelt kunne benytte senere. Dessverre ble det ikke tid til dette Teknologi QlikView bruker en «in-memory data model», som laster all data på RAM istedenfor å bruke disk. RAM er mye raskere enn disk, som vil sørge for at programmet svarer raskere og vil gi en bedre bruker-erfaring med programmet. Programmet bruker også mindre ressuser fordi det da ikke er nødvendig å hente data direkte fra disken. Antall spørringer til disk blir også redusert, og det bidrar til mindre slitasje på pc ens hardware. Programmer er gratis, men har da en del begrensende funksjoner i forhold til modellen som koster penger. Det er en «personal edition» og en «business edition». 16

17 Hensikten med prosjektet er å lage en demoapplikasjon gjennom QlikView. Applikasjonen blir laget gjennom QlikView som er en Business Intelligence-applikasjon. Den kan illustrere tabeller på en bedre måte enn man kan gjøre gjennom excel, og kan i tillegg dynamisk transformere data basert på såkalte expressions hos ulike objekter. Dette tillater stor fleksibilitet da data er separert fra det visuelle. Så vi hentet ut data fra matvaretabellen, som ligger ute på internett i ren tabell-format, og inn QlikView. QlikView kan hente fra ERP, CRM, Excel, SQL-databaser og andre dataformat. QlikView formatet kan vises frem på cloud-format, laptoper, mobile applikasjoner. QlikView kan gjøre slik at den henter frem relevant informasjon på en dynamisk måte. Mat på data fungerer helt greit å vise frem i excel-tabeller, men med QlikView vil vi vise frem hvordan i kan bruke disse dataene i et mer dynamisk grensesnitt med ulike visningsmodeller og diagrammer. Matvaretabellen har en samlet oversikt over innhold av næringsstoffer i de aller vanligste matvarene vi har i landet. Tabellen viser næringsinnholdet pr. 100 gram spiselig matvare. Denne er utviklet for gi en god oversikt over næringsinnholdet i maten. Matvareportalen har også lagd et program som viser denne fremstillingen mer grafisk. Dette er et eldre Windowsprogram, som er utdatert og tungvint. Se bilde under. 17

18 QlikTech community QlikTech har egne diskusjonsforum som gjør at man kan være i kontakt med andre utviklere mens man jobber i QlikView. Dette var veldig praktisk underveis i utviklingen, og vi benyttet oss av dette forumet gjennom hele utviklingssperioden. Extensions QlikView extensions gjør det mulig å utvide funksjonaliten i QlikView. I QlikView 10 har man muligheten til å utvikle i extensions med hjelp av javascript. Nærmere beskrivelse av Extensions finnes i kapittel Idémyldring Gruppen hadde i innledningen av prosjektet en brainstorming hvor vi skrev ned alt det vi kunne tenke oss å utvikle. Dette noterte vi opp en whiteboard, bare for å få tankene og idene i gang. Vi hadde som mål å involvere både matportalen og andre fagressurser i utviklingen, men de viste ikke interessere for å bistå oss. Her er et eksempel på en idé vi ønsker å implementere i vår applikasjon. Denne QlikViewapplikasjonen er laget for å vise måltidene til fast-food selskaper i USA, som viser hva man må gjøre for å forbrenne måltidene ved hjelp av ulike aktiviteter. Her ser man hvor man faktisk må drive på før man har forbrent alle kaloriene Kravspesifikasjon Her følger i store trekk kravspesifikasjonen som vi utarbeidet tidlig i prosjektet. Denne dannet dermed utgangspunktet for all videre arbeid med applikasjonen. Denne ble i hovedsak utarbeidet av gruppen selv og ble godkjent av arbeidsgiver. 18

19 Om bakgrunnen Mattilsynet drifter en nettside som heter matportalen.no. Her finnes diverse informasjon om mat og næring, blant annet er det lagt ut en næringstabell med informasjon om de fleste norske matvarer og deres innhold. I tillegg ble det for flere år siden utviklet en Windowsapplikasjon som presenterer denne informasjonen, kalt Mat på Data. Vi vil lage en applikasjon som automatisk innhenter denne informasjonen. Samtidig skal denne applikasjonen sortere og presentere informasjonen i ulike relevante former og på en måte som gjør informasjonen mer tilgjengelig, relevant og interessant. Dette kan da sees på som en uoffisiell oppgradering av applikasjonen Mat på Data, samt med mulige nye funksjoner og områder. Forord Hensikten med kravspesifikasjonen er å kartlegge alle nødvendige deler av prosjektet og prosessen. Dette skal deretter benyttes til å utarbeide en fullstendig arbeidsplan. Den er derfor laget med hensyn til bruk av prosjektgruppen og som oversikt for arbeidsgiver. Spesifikasjonen er derfor en viktig del av prosjektet og danner mye av grunnlaget for videre arbeid. Kort systembeskrivelse Vår måte å utarbeide krav og sprints vises i pyramiden under. Vi begynner på toppen og arbeider oss nedover i pyramiden. Vår ønskede arbeidsmetode er SCRUM, det er derfor et mål å kunne dele opp arbeidsmengden i sprints. Disse sprintene utgjør da alle deler av product backlog. Applikasjon er nyutviklet og ikke en direkte oppgradering av eksisterende systemer/applikasjoner. Det er likevel noe sammenligningsgrunnlag med eksisterende applikasjoner, eksempelvis: Matvare-/næringstabellen.xls fra Mattilsynet.no Mat på Data (Windows-applikasjon utviklet av Mattilsynet) QlikView Demonstrasjonsprogram (QlikView-applikasjoner utviklet av QlikTech) Vi tar sikte på å benytte disse for inspirasjon for utvikling av FoodView. Det er forsøkt å etablere en kontakt med Mattilsynet for et lett samarbeid, men vi har ikke fått positiv tilbakemelding på dette punktet. Applikasjonen skal utvikles for konsumenter, dvs. alle personer med enkel interesse for oversikt og informasjon om næring i hverdagen og generelt. Det skal ikke kreves spesielle datakunnskaper for benyttelse av programmet, kun grunnleggende dataferdigheter. Main Use Case: Familien Hansen Familien Hanssen, fire personer: mor, far, sønn og datter. Far og mor bruker FoodView til å lære barna om næring, kosthold og matinnhold, samtidig som de lærer å bruke datamaskiner generelt og i hverdagen. 19

20 Mor og far er bevisste på helse og næring og er interessert i å vite hva de spiser og får i seg av mat og næring. Derfor bruker de FoodView. Her kan de lagre måltider og retter og sammenligne med standardverdier og andre måltider. Her får de oversikt over innholdet av hva de spiser. Samtidig kan de få oversikt på ukes eller månedsbasis over hva de spiser. Dette vises i graf og kan justeres og vise forskjellige typer informasjon. En eller to ganger i uken er de inne i programmet og legger til og justerer sine måltider og retter. De er ivrige brukere og har bidratt mye til biblioteket over forskjellige retter. Her kan også de forskjellige matvarene/ingrediensene skannes fra QR-koder på skjerm direkte til mobil for handleliste, eller sendes som mail. De kan også sendes andre veien. Fra mobil kan man sende handlelister eller annet direkte til egen mail, eller til FoodView-mail som lagrer ønsket informasjon. Samtidig liker far å sitte og leke litt rundt i FoodView og eksperimentere litt med forskjellige retter og lete frem informasjon om forskjellige matvarer på datamaskinen til familien. Han liker å finne sunne og gode retter som han legger til som forslag til retter og måltider. Samtidig er mor inne på Facebook-gruppen for FoodView og prater med andre brukere om FoodView og mat på nettbrettet sitt. Barna liker å leke med mobilskannerne sine og prøve å registrere/sjekke ulike produkter på mobilen sin. Funksjonelle krav: Søke i matvaretabellen og vise all relevant informasjon tilknyttet valgt vare/ingrediens Velge flere varer/måltider/retter og vise samlet næringsinnhold og kunne sammenligne Vise innhold over tid i grafer og sammenligne med standardverdier Knyttet/integrert med eksterne funksjoner/steder for hjelp og informasjon (eks. Wikipedia) Kunne lagre personlig informasjon (lokalt/server) og vise dette i overnevnte sammenheng Sjekke mat/måltider opp mot forbrenningsinfo/-verdier Kunne justere forbrenningsinfo etter personlig info, gjøre ulike valg i forhold til aktivitetsnivå, alder og kjønn m.m. Kunne sende informasjon til mobile enheter (eksempelvis via mail) Kunne hente informasjon fra POP3 (mail) eller annet medium som opprinner fra mobile enheter Egen side i applikasjon med råd og tips angående anbefalte mengder av næringstoffer og sunt kosthold Egen side med disclaimer Ikke-funksjonelle krav: Skal hostes enten i cloud-løsning eller egen server Skal designes med fokus på brukervennlighet og lett forståelig og raskt grensesnitt. Dette er et konsument-produkt, og følger derfor dertil egnet design og grensesnitt. Enkel og rask navigering Intuitivt valg av "sider/tabs" i applikasjonen slik at det er for bruker er lett å lære og lett å finne frem 20

21 Lett integrasjon mot mobile enheter (dvs. ikke i utganspunktet nødvendig med egen tung QlikFood-app for integrering, eksisterende apps og pop3/mail kan benyttes) Åpenhet og informasjon angående kilder og referanser Rammekrav: Det er et krav at det både på server og klientside må være støtte for HTML 5. Alle script og kode skal benytte seg av HTML5-standarden. Det er også nødvendig å legge til rette for implementering av flere språk. Dette gjelder for både tekst i programmet og for eventuelle kulturelle forskjeller i informasjonen og benevninger/units o.l. I tillegg er det et krav at det skal legges til rette for en velintegrert brukerveiledning i applikasjonen, med pop-ups og relevant informasjon "der og da". Det skal blant annet benyttes løs eller tett kobling til wikipedia for detaljert informasjon om relevante emner. Under utviklingshensyn er det viktig å nevne at det er nødvendig med gyldig QlikView-lisens for å kunne ferdigstille og hoste en slik applikasjon. Det er tilgjengelig for nedlasting en såkalt personal edition som er lisensløs, men denne tillater ikke direkte deling av informasjon. Det er et rammekrav at det under hele utviklingsprosessen skal legges til rette for videre utvikling av applikasjonen. Dette gjelder både forbedringer og utvidelser med nye elementer og funksjoner. Eksempelvis: Skal følge en gitt navnestandard for å gjøre utvidelser og forbedringer lettere å implementere Dokumentere utvikling og utviklingsprosessen for senere utviklingshensyn Tettere integrering med mobile enheter, egen mobil app for ios, Android og Windows 8 Inkludere flere språk i programmet Inkludere data/informasjon fra flere land/områder Muligheter for sammenligning av data fra ulike land Flere funksjoner og valgmuligheter med tanke på personliggjøring og lagring/benytting av personlig informasjon Alternativer for visningsmåte/designvalg for bruker av applikasjonen I tillegg følger det visse krav til design og brukervennlighet når målgruppen vår er konsumenter. Tekst og språk som benyttes i programmet skal være allmennt og generelt forståelig, det skal ikke være nødvendig med teknisk bakgrunn for å forstå og benytte programvaren. Design og grensesnitt skal være konstruert på en intuitiv måte for å gjøre programmet lett å lære og navigere Design skal i tillegg være utformet med fokus på enkelhet, dvs. ikke overflødige og forstyrrende elementer i grensesnitt, samt rask og enkel vei for å fullføre ønskede funksjoner. Funksjoner som benyttes ofte må fremheves og optimaliseres. Dette gir et bilde på fokuset vårt under utviklingen. Det er satt opp generelle punkter. Senere vil analyser og diagrammer for relevante punkter gi et mer detaljert bilde av kravene. 21

22 Logisk datamodell Her følger en visuell beskrivelse av hvordan hoveddelen av applikasjonen vil fungere. QlikView assosierer automatisk feltnavn, men kilder/info kan lastes inn i ulike tables. Vi ser for en oppdeling av programmets informasjon og funksjon i moduler for å legge til rette for eventuelle utvidelser. Hovedvekten av data vil ligge i table Food. Tilhørende informasjon som Food Names, Unit og Nutrition legges som egne tables for å kunne støtte ulike språk og ulike enheter. I tillegg er det nødvendig med en egen table for referanser i forhold til energi/forbrenning. Krav til systemkonstruksjon For å kunne utvikle eller utvide denne applikasjonen er det nødvendig å kunne QlikView. Dette er hovedverktøyet man benytter seg av for utvikling, men man benytter seg av andre teknologier under utviklingen. Eksempelvis benytter plattformen seg av HTML for visning fra server eller WebView. For extensions og macros (utvidelser) benytter seg av enten VBScript eller Jscript (tilsvarende Javascript). Krav til dokumentasjon Det skal utvikles en brukerveiledning, men det skal i tillegg knyttes tett til applikasjonen med diverser pop-up info, egen introduksjonsside og hjelpeside. Applikasjonen skal også knyttes til eksterne lenker som eksempelvis Wikipedia. Krav til manuelle funksjoner Foreløpig ingen krav til manuelle funksjoner Dataordbok Vil fylles ut etterhvert som flere begreper trenger å defineres: Business intelligence (BI) is a set of theories, methodologies, processes, architectures, and technologies that transform raw data into meaningful and useful information. BI can handle large amounts of information to help identify and develop new opportunities. Making use of new opportunities and implementing an effective strategy can provide a competitive market advantage and long-term stability. Wikipedia.org Scrum is an iterative and incremental agile software development framework for managing software projects and product or application development. Scrum focuses on project management institutions where it is difficult to plan ahead. Mechanisms of empirical process control, where feedback loopsthat constitute the core management technique are used as opposed to traditional command-and-control management. Its approach to planning and managing projects is by bringing decision-making authority to the level of operation properties and certainties. Wikipedia.org Design og prototyping Vi ville ha et gjennomgående likt design av alle våre tabs i programmet. Dette er for å holde en lik standard sånn at det blir lett for brukerne å sette seg inn i applikasjonen. Vi hadde som mål å ha brukervennlig grensesnitt, som brukerne lett kan skjønne seg på. I utviklingsfasen sto ikke 22

23 design og brukervennlighet høyt i fokus, men etter hvert som utviklinga og kodingen var på plass, måtte vi tenke mer på brukeropplevelser av produktet. Det ble også tid til å teste Våres applikasjon er delt inn flere sheets. Kan sammenlignes med at excel har du én bok, men flere ark under samme bok. Dette gjør det svært enkelt å navigere gjennom applikasjonen. Hensikten med prototyping var nødvendig for å tenkte hvordan vi skulle sette opp applikasjonen, og planlegge oppbygging av den. Det var nødvendig for å gjøre designet mest mulig brukervennlig. Målet var å ha en høy brukervennlig for uerfarne databrukere, slik at de kunne ta i bruk programmet uten ha vært flittig bruker av datamaskiner tidligere. Gruppen gjennomførte en idémyldring på dette: Enkel oppbygging av applikasjon: Ingen avanserte innstillinger. Enkelt å navigere mellom applikasjoner. Hvis det er en vanskelig funksjon, ha en god brukanvisning(for eksempel legge ut video) Brukertesting på slutten. Involvere andre i gruppa, slik at man får mer input på designet Forkunnskaper og videre utvikling Ingen av gruppemedlemmene hadde noe forhåndskunnskap om QlikView. Vi har gått gode tips og råd fra oppdragsgiver som har hadde noen dager hvor vi har fått kyndig opplæring. Programmet er ganske omfattende, og har utallige muligheter for videreutvikling og utvidelser. Det er tiden vi har til rådighet som setter begrensninger i forhold til utvikling av produktet. Derfor hadde gruppen noen utfordringer med å sette en god nok kravspesifikasjon, slik at vi kunne oppnå målene våre uten at vi virkelig kjente til programmet. Derfor valgte vi å sette en del begrensninger i starten, slik at målene ikke ble for omfattende. Vi fant at det var bedre å lage tre grundige applikasjoner, enn fem halvferdige applikasjoner som ville inneholdt flere bugs. Erfaringene fra tidligere prosjekter på skolen, var at det ville komme utfordringer underveis i utviklinga. For å kunne begynne å mestre QlikView måtte man bruke mye tid på å sette seg inn i programmet. Vi hadde tilgang til noen tutorials og en "resources for the beginner" som man bruke for å sette seg inn i programmet. Dette hjalp oss en god del, men det var mye testing av forskjellige funksjoner for å se om ting fungerte slik vi ville. 3.2 Utviklingsprosessen Tre av gruppens medlemmer som sto for det meste av utviklinga av QlikView. De jobber hver for seg med hver applikasjon, men gjorde justeringer og endringer seg imellom. Her kom SCRUM-arbeidsmetoden på sin plass. Dette gjorde det lettere å samarbeide, selv om de hadde ansvaret for hver sin applikasjon. Når man kommer til et problem og utfordring er det ofte veldig greit å få input fra noen andre for å komme seg videre i prosessen. 23

24 3.2.1 Utviklingsmodell/metode Vi ville prøve å bruke SCRUM-metoden under utvikling. Det ble ingen fullskala scrum-metode, men vi fulgte hovedprinsippene innenfor denne scrum. Scrum er et rammeverk som ofte blir brukt til å utvikle komplekse systemer. Gruppemedlemmene hadde variert erfaring med SCRUM fra tidligere prosjekter på HiOA. Vi fant tidlig ut at det, underveis i utviklingen av de forskjellige funksjonene, kom til å dukke opp nye krav. Programutvikling er komplekst, og det er vanskelig å vite hvor lang tid visse problemer eller utfordringer som dukker opp underveis tar av tid til å løse. Siden vi benyttet oss av SCRUM-metoden hadde vi et kort møte om morgenen, hvor vi diskuterte hva man hadde gjort dagen i forveien, og hvilke utfordringer som må løses den kommende dagen. Gruppelederen var scrum-master, og ledet møtene. Vi hadde altså et sprint planleggingsmøte i forkant, og den daglige scrum, og i etterkant et sprint-review møte. Siden vi var hovedsakelig 3 personer som programmerte daglig fører dette til en mindre interaksjon og resultatet av det viser seg i form av lavere effektivitet. Vi ser vel i etterkant at vi burde valgt en annen modell, siden vi var en for lite gruppe til å få noe utbytte av å benytte oss av en slik utviklingsmetode. Men gruppen hadde stort utbytte av det daglige scrum-møte, samt en backlog som viste hva vi skulle gjøre. Gruppemøter De dagene vi møtes hadde vi den daglige scrum. Møtene var tidlig på dagen, og var viktig for å samkjøre gruppen slik at vi kunne innsikt i arbeidet til de forskjellige i prosjektet. Dette møtet varte bare i kort tid, og holdt gruppen oppdatert. Disse møtene var viktige og nyttige for gruppen. Sprints Sprinten er en hoveddel i scrum, der vi skal skape et ferdig produkt. Her skal vi oppnå et konkret resultat. Prosjektperioden besto av totalt to Sprinter, hvor den første sprinten vil være et «forprosjekt» for å sette seg inn i utviklingsmetodikk og enklere å kunne estimere tasks for kommende sprinter. Vi satt opp en fast plan på hva vi ville oppnå innenfor den tidsperioden. Vi valgte å dele inn sprintene på ca 14 dager. Dette fungerte bra for gruppen, og nedenfor har vi skrevet inn en oversikt over hva vi gjorde under sprintene. Hver sprint var fordelt på to arbeidsuker, hvor vi jobbet tirsdag til fredag begge ukene. Scrum definerer et team (Scrum-teamet) som selvdrevet og med store fullmakter til å nå definerte mål for programvareutviklingen. Målene nåes gjennom å utvikle konkrete, små produktinkrementer i iterasjoner på 1-4 uker. De funksjonene man skal utvikle for å nå målene legges i en liste kalt Product Backlog (Produktkø). Denne er alltid levende, elementene er grovestimerte og ligger alltid i prioritert rekkefølge. Hver inkrement som lages blir gjenstand for inspeksjon der man evaluerer resultatet og sørger for å lære. I Scrum kalles iterasjonene Sprinter. Det første man gjør i en sprint er å plukke ut det sett med funksjoner som skal implementeres fra toppen av produktkøen. For hver av disse funksjonene lager man så oppgavelister og ender så opp med en "Sprint backlog". Underveis i Sprinten gjennomføres daglige møter der team-medlemmene koordinerer arbeidet seg imellom. Møtet, som oftest holdes stående, skal vare maksimum et kvarter og i løpet av perioden skal alle teammedlemmene gi uttrykk for følgende tre forhold: Hva er gjort siden forrige scrum-møte? Hva skal gjøres før neste møte? Hva har (eventuelt) vært til hinder for at gruppemedlemmet effektivt jobber med implementering av funksjonalitet? 24

25 Det siste man gjør i Sprinten er å demonstrere det inkrementet som ble laget til noen utvalgte interessenter. Dette kalles Sprint review. Hensikten med dette er å få tilbakemeldinger fra de som har kravene og få verdifulle innspill til forbedringer basert på det som demonstreres. Etter dette gjennomfører hele Scrum-teamet et tilbakeblikk-møte ("Sprint retrospective") der man samler erfaringer fra siste Sprint og finner måter å jobbe litt mer effektivt på i neste Sprint. Hver sprint består av to uker, som består av til sammen fem hele dager og tre halve dager totalt 52 timer. Siden vi er lite team i SCRUM-sammenheng kan det føre til lite interaksjon og en lavere produktivitetsgevinst. Siden vi ikke har jobbet med dette verktøyet før, opplevde vi litt kompetansebegrensninger. At ting gikk litt tregere enn forventet, siden dette var en ny metode for oss. Arbeidsmetoden krever høy fokus på selve oppgave, og at vi jobbet effektivt. Sprint 1 Backlog (produktkøen) for den første sprinten er følgende: 1. Matvarer Søk tabell Sortering/visning Charts/grafer Design. 2. Måltider: Valg av flere måltider Lagring/henting. Sammenligning, Knytte sammen applikasjonene hovedside og forbrenning, Charts/relevant info Design, kontakte 3. Næringstabellen: Lage tabell slik at denne infoen vises 4. Forbrenningstabellen: Legge inn formel for beregning Sprint 2 Backlog for den 2. sprinten: 1.Startside Introduksjon Bruksanvisning Disclaimer Generell info 2.Måltider Fjerne bugs i opprette flere måltider Legge til slik at man kan se energi og næringsinnhold 25

26 Gjøre det mulig å slette måltider 3.Næringstabellen Gjøre det mulig å bytte visning til visning av næringsstoffer Gjøre det mulig å bytte mellom alle næringsstoffene 4.Forbrenningstabellen Glidebryter for daglig inntak Legge inn input for for forskjellig aktivitetsnivåer Bruker skal kunne bytte energienhet mellom kilojoule og kilokalorier Personinformasjon 5. Sluttdokumentasjon Følge opp fremdriftsplan Dokumentere underveis til prosessdokumentasjonen Sprint-review I etterkant av sprinten hadde vi et møte for å oppsummere hvordan sprintene gikk, hva vi hadde fått ut av det, og om resultatet av disse sprintene var tilfredsstillende for ferdigstillelse av produktet. Den første sprinten var den minst produktive av de to sprintene, da denne strekte seg ut i påskeferien. Vi tok med oss mange av erfaringene fra første sprint, inn i den andre sprinten Utviklingsfaser: I starten var det en utfordring å finne ut hvor omfattende vi skulle gjøre applikasjonene. Vi måtte være ambiøse, men også klar på våre begrensninger. Dette er på bakgrunn av at dette et helt nytt rammeverktøy, og at vi bare hadde maks tre måneder å lære oss selve rammeverktøyet. Det har vært mange eksempler på prosjekter som har blitt for omfattende. Derfor valgte vi derfor å satse realistisk, men tenke ambisiøst. Vi gjorde oss godt kjent med programmet før vi satte i gang utviklingen, og vi kom litt tregt ut i forhold til ambisjonene. Skal du utvikle en nettside uten kjennskap til HTML(X) eller PHP(X), så må du lære dette ordentlig før du kan begynne å utvikle selve nettsidene. For å bygge opp applikasjonene i QlikView brukte vi en enkel scetching metode for å se hva vi ønsket å ha med. Dette var for å visualisere hvordan siden kunne bygges opp, fordi det er viktig å ha en plan på hvordan man skal bygge opp siden. Vi var flinke, men det litt sent igang med utviklingen, og burde ha begynt med dette tidligere. Utfordringene var å finne ut hvordan man skulle gjøre ting mulig i de forskjellige applikasjonene. Det var viktig at løsningene ville fungere for sluttbrukeren Individuelle beskrivelser av arbeidet Under følger en individuell beskrivelse av hver persons arbeid og tanker rundt prosjektet. Henrik På dette prosjektet har jeg fungert som prosjektleder. Det har dermed vært mitt ansvar å overse arbeidet. Dette innebærer planlegging av møter og oppfølging i forhold til gruppemedlemmene. Det har vært min oppgave å se til at prosjektet har hatt flyt og fremdrift og at arbeidet følger styringsdokumentene i størst mulig grad. Dette har vært en ny og spennende utfordring med vekslende hell. Gruppen som helhet har fungert bra med tanke på samarbeid og gruppedynamikk. En større utfordring har vært å legge 26

27 opp konkrete arbeidsplaner og sørge for at arbeidet i stor grad følger disse. Vi har benyttet oss av SCRUM-metoden, men ser i ettertid at det kanskje kunne vært valgt en annen metode. Det har derimot vært meget interessant og lærerikt å prøve ut SCRUM, og metodevalget har ikke vært noen hindring i arbeidet. Det var til tider vanskelig å følge opp med daglige sprints da vi i en gitt uke ikke møttes hver dag. Samtidig har det vært perioder med færre arbeidsdager hvor arbeidet i forhold til valgt metode har sklidd i to retninger. I tillegg har jeg også fungert som kontaktperson i forhold til veileder fra skolen og veileder fra QlikTech sin side. Denne kommunikasjonen har foregått på en fin måte og det har ikke vært forbundet noen problemer med dette. Veiledere fra skolen har vært tilgjengelig på mail og veileder fra QlikTech har vært meget tilgjengelig både på mail og telefon. I mitt arbeid med selve applikasjonen har jeg jobbet med flere oppgaver. I planleggingsfasen jobbet hele teamet med å utarbeide funksjonelle og ikke-funksjonelle krav. I denne fasen startet vi også så smått med å bygge på applikasjonen og gjorde ulike designvalg. Med innspill fra arbeidsgiver var jeg ansvarlig for å sette opp kravspesifikasjonen i samarbeid med gruppen. Dette la føringer for videre utvikling av applikasjonen og har videre kommet med innspill for designvalg i ulike deler av applikasjonen. Eksempelvis har jeg i samarbeid med Ibraheem kommet frem til elementer og design for karttjenesten, i tillegg til kostholdsråd-siden. Matvarer/Næringsinnhold jobbet jeg også en del med i samarbeid med Erling, hvor vi endelig bestemte å benytte Erlings designvalg. Jeg var også en del av det innledende arbeidet med måltidstab en, hvor vi eksperimenterte med ulike løsninger og metoder. Mye av arbeidet mitt her lå i implementeringen av måltidsfunksjonen og hvordan dette kunne gjøres. Her forsøkte jeg å benytte QlikViews egne funksjoner for å tilvirke måltidsfunksjonen vår, eksempelvis gjennom Selection States og Bookmarks. Dette virket med vekslende hell. Jeg fikk implementert lagring av matvarer/ingredienser, men da altså ikke direkte visuell sammenligning og ikke lagring av ulike mengdeverdier. 27

28 I det avsluttende arbeidet har oppgaven min vært å knytte sammen våre ulike dokumenter og sørge for fremdrift i dokumentasjonsarbeidet i samarbeid Geir, som sekretær, og øvrige gruppemedlemmer. Steinar Jeg har hovedsaklig vært med på å utvikle applikasjonen. I begynnelsen, samtidig som vi lærte oss å bruke QlikView ble det stort sett gjort en del forarbeid i forhold til hvordan vi ville løse oppgaven. Vi hadde det klart at dette skulle være en applikasjon for oppslag i matvaretabellen til mattilsynet. Oppgaven vår sa også at vi i tillegg skulle finne løsninger på ny tilleggsfunksjonalitet til applikasjonen. Her hadde vi mange idéer og vi måtte bestemme oss for enkelte vi ville prioritere slik at vi ikke fikk for mye å gjøre. Valget falt først og fremst på den grafiske framstillingen av data, muligheten til å legge sammen matvarer som måltid og beregning av forbrenning. Jeg fikk ansvaret for forbrenningsbiten og brukte deretter mye tid på innsamling av informasjon. Ingen på gruppa har noen erfaring med næring og forbrenning og vi er veldig avhengige av at våre kilder er riktige. Vi så oss nødt til å avklare i en disclaimer at vi ikke kan stå til ansvar for at våre beregninger er eksakte, eller de beste. Jeg føler meg likevel trygg på at jeg har tatt greie valg av måter å beregne forbrenning på. Ellers har jeg hjulpet de andre på gruppa, særlig tilbakemeldinger og løsninger på andre deler av applikasjonen. Jeg har også testet applikasjonen mye underveis og funnet feil/mangler og fått disse rettet. Har også kommet med egne synspunkter på brukervennlighet og mest mulig logisk og selvforklarende design. Foruten andre deler av rapporten tok jeg også på meg oppgaven med å skrive brukerveiledningen til applikasjonen. Jeg hadde da erfaring med både QlikView generelt og FoodView-applikasjonen vår. Som allerede nevnt har jeg hatt brukeren i tankene for designvalg noe jeg visste jeg ville få nytte av under skriving av brukerveiledningen. De siste dagene brukte jeg også mye tid på korrekturlesing og fikk rettet mange feil. Sitter da igjen med en mer lettlest rapport hvor færrest mulig skrivefeil vil inntreffe. Jeg er ikke noen profesjonell korrekturleser og har i tillegg benyttet meg av stavekontroll i LibreOffice. Kan fortsatt ikke garantere at feil kan inntreffe. Geir Jobbet som sekretær, og har hatt ansvar for å følge med på dokumenter underveis i prosjektet. Holdt oversikt over hva vi har jobbet med underveis. Skrevet dokumentasjon underveis, og bistått andre gruppemedlemmer om det har vært nødvendig. Har jobbet med fremdriftsplanen, skrevet dagbok og fulgt opp daglige frister. Har hatt oversikt over gruppesamarbeidet, og tilrettelagt slik at hvert gruppemedlem hadde den dokumentasjonen de trenger for å kunne jobbe. 28

29 Fulgt med på interne frister vi har hatt i prosjektet og sett an hvordan vi har ligget an underveis i prosjektperioden. Jobbet sammen med Henrik på å planlegge frister, og har også skrevet veldig mye av prosjektrapporten, slik at de andre gruppemedlemmene kunne fokusere mest mulig på programmeringen av programmet. Jobbet litt med design av funksjonene vi har implementert, slik at det skal være logisk bygd opp og lett for brukerne å skjønne hva vi har tenkt. Har jobbet med brukermanulen sammen med Steinar. Muhammad Ibraheem Cheema Mitt ansvarsområde er å lage gruppeside og oppdatere denne, ellers var det min oppgave å designe hovedside og startside for applikasjonen og implementere kart-løsningen. Planlegging: Første oppgave i gruppen var for meg å lage gruppesiden. Jeg planla å lage en side som deles inn i tre hovedområder: forprosjekt, kravspesifikasjon og sluttrapport. Neste ting som tilfalt meg var å design introduksjonssiden for prosjektet. Jeg laget tre mockups og deretter valgte vi en av disse til videre arbeid. I forhold til design for hovedside tok jeg to ting i betraktning: enkelhet og attraktivitet. Siste konkrete oppgave for meg var å lage tab/side for kart. Der brukte jeg metoder og funksjoner vi lærte under veiledingskurs fra arbeidsgiver. Videre forsøkte jeg å utvide funksjonaliteten til kartet ved å bygge det opp via QlikView-extension, men ble ikke ferdig med dette på grunn av tidsmangel. Utvikling: For gruppesiden brukte jeg HTML5 og CSS3. Gruppesiden er delt opp i tre hovedtab er: en er forprosjekt, andre for kravspesifikasjon og tredje er for sluttrapporten. På venstre side er overskrifter/lenker for hovedpunktene i hver tab. Under finner man HIOA logo og verifiseringslenke for HTML5 krav. I midten finner man hovedfeltet/body med detaljert tekst. På 29

30 høyre side er gruppelogoen og en boks med medlemmers navn og under er det lenket til aktuelle PDF-dokumenter. For hovedprosjektets applikasjon designet jeg en logo i Adobe Photoshop 6 og ett bilde for hovedgrupper av matvarer. I kartsiden laget jeg tre objekter: location som variabelvalg for by, en med variabelvalg for karttype og en tredje med variabelvalg for markørvisning i kartet. Disse variablene dannet da delelementer for request mot Google Static Maps API. 30

31 Testing: Jeg lastet opp gruppesiden på skolen sin server og testet at den fungerte helt fint og validerte html-tagene. Jeg viste logo til andre medlemmer for godkjenning og jeg testet kartsiden fortløpende under utvikling og gjorde testing også etter utrulling på server. 4 Produktdokumentasjon 4.1 Introduksjon I dette kapittelet følger en nærmere beskrivelse av hvordan selve produktet er bygget opp. Videre i introduksjonen forklarer vi nærmere stegene som tas for å starte med oppbygningen av applikasjonen. I hoveddelen vil vi forklare nærmere hvordan informasjonen som er hentet, transformert og lastet brukes til å bygge opp ulike bestanddeler av selve applikasjonen og brukergrensesnittet. Avslutningsvis beskriver vi nærmere hvordan man kan gå enda lenger med å bygge sine egne utvidelser (extensions) til applikasjonen. Disse er lagt til rette for av QlikView, men er mindre dokumentert. Formålet med produktet er å bruke verktøyet QlikView til å lage en web-applikasjon. QlikView gis informasjon om hvor og hvordan den skal hente informasjon,i vårt tilfelle er dette matvaretabellen fra Matportalen.no. Deretter foretar man, i de fleste tilfeller, en transformasjon av dataen og laster informasjonen inn i selve QlikView via en reload av scriptet. Dette sørger for å gjøre hentet informasjon tilgjengelig for manipulering og visning i QlikView-grensesnittet. Under følger en nærmere beskrivelse Load Script: Load-scriptet er en essensiell del av QlikView. Dette scriptet er selve grunnlaget for alt videre arbeid med en QlikView-applikasjon. Her foregår ETL (Extract Transform Load): innhenting, transformering og lasting av informasjon. Det er her alle tabeller og feltnavn blir bestemt, og det er disse man jobber med i form av ulike objekter i verktøyets grafiske grensesnitt. Her kan man 31

32 også opprette og initialisere variabler og konstanter, og man kan legge til egne inline-tabeller om ønskelig. For å kjøre endringer må scriptet reloades i applikasjonen. Under kan man se forskjellige datakildekoblingsmuligheter, samt at det vises hvordan en slik kobling vises i loadscriptet. Datakilder, Extract: Som et BI-verktøy er informasjon en viktig del av en QlikView-applikasjon. Som oftest er det første man gjør å opprette en kobling til en ønsket datakilde. Via load-scriptet angir man ønsket datakilde, dette kan være en databasekobling, direkte filkobling eller en indirekte filkobling over internett, eksempelvis en peker til et nettsted. Det er derimot nødvendig at det finnes informasjon i datakilden som er lagt i tabeller i en eller annen form fordi QlikView automatisk forsøker å hente ut informasjon i tabell-form. Datakilden blir deretter forsøkt koblet til og man får et preview over informasjonen som hentes. Transform: Når Load-scriptet har hentet informasjonen fra datakilden og man får et preview kan man benytte seg av en wizard for å transformere den rå informasjonen. Eksempelvis kan man sørge for å kutte uønskede rader før og etter, eller gjøre utvalg av rader. Man kan vri tabellen og gjøre 32

33 rader til kolonner. Endringer man gjør her vil bli registrert i load-scriptet, og man kan endre og legge til direkte i load-scriptet om man ønsker. Load: Når ønsket datakilde er opprettet og koblet til, og man har foretatt ønsket transformasjon kjører man en reload av scriptet. Informasjonen blir deretter lastet inn i minneområdet til QlikViewapplikasjonen og man kan deretter jobbe med informasjonen i selve grensesnittet til QlikView som objekter av ulike typer. QlikView sørger også selv for automatisk å assosiere tabeller basert på feltnavn. Det er derfor viktig å sørge for at felt som ikke skal kobles har blitt endret til andre navn og at alle felt som skal kobles har samme navn. 4.2 Hoveddel Om de ulike sidene i applikasjonen Vi kom frem til tre applikasjoner som skulle være hovedinnholdet i FoodView. Vi la også inn enkel kartfunksjon på slutten for å vise mulighetene for videre utvikling av applikasjonen. Side 1, Introduksjon: Denne siden/tab en er det første en bruker vil se i web-applikasjonen. Her finner man logo for applikasjonen samt fire undersider: Introduksjon, Disclaimer, Bruksanvisning og Om tabellverdiene. Disse er implementert med knapper. Fire knapper endrer verdien til showhidewelcome-variabelen. Når denne endres vil den enten gjemme eller vise en av fire objekter, avhengig av variabelverdien. 33

34 Disse fire informasjonssidene er satt opp ved hjelp av et extension-objekt, Web Page Viewer. Dette er en enkel HTML-tolker som da viser angitt side eller dokument oversatt til HTML. Som vist under er disse sidene hostet på egen server: Disse sidene blir deretter direkte lastet inn i extension-objektet og dermed applikasjonen. 34

35 Disclaimer-side: Matportalen har skrevet en ansvarsfraskrivelse på nøyaktigheten i de tallene som forekommer i matvaretabellen. Vi arver denne. Vi har ikke faglig bakgrunn innen helse og næring og har kun benyttet oss av de fakta vi har klart å hente inn. Vi tar ikke stilling til hva som fungerer av f.eks. dietter og trening da dette er svært omdiskuterte temaer. Vi viser til de kildene vi har brukt til uthentning av data og formler slik at bruker selv kan avgjøre om dette er troverdig nok. Feil kan forekomme. Vi vil teste applikasjonen og sørge for minst mulig feil. Det kan likevel være feil i beregninger av data og dermed være følgefeil. F.eks. Feil utregnet sum av kilokalorier i et utvalg produkter vil føre til feil treningsmengde dette vil medføre. Denne applikasjonen er ikke en kommersiell virksomhet. Den data vi behandler ligger allerede fritt tilgjengelig for allmennheten og vi har kun kombinert og presentert dette på en ny måte. Side 2, Matvarer: Dette var vårt første fokus i utviklingen vår og danner mye av grunnlaget for både måltidssiden og treningssiden. Her får bruker direkte tilgang til matvaretabellen slik den er presentert i applikasjonen. Siden har ulike funksjoner, øverst har vi hurtiglenker for de andre sidene i applikasjonene (tabs). input-felt, Søk: Under finner vi søk i informasjonen tilgjengelig i tabellene Matvare og måltid. Knapp, Nullstill valg: Ved siden av søkefeltet har vi lagt en knapp for enkelt å nullstille valgene i forhold til matvarer. Vi ser at knappen kjører en makrofunksjon, resetchoices, hvor alle relevante felt blir nullstilt. Vi ser at det ikke er noen kobling til feltene for visningsvalg. 35

36 Liste, Matvaregrupper: Under søkefeltet langs venstre kant finner vi listbox en Matvaregrupper. Her kan man gjøre utvalg for visning av matvarer i angitt gruppe. Disse elementene blir opprettet i Load-scriptet som vist i figuren under. Den laster og assosierer spesifikke matvarer med en matvaregruppe basert på den unike matvareid en, alle med matvareid som starter med 01.* er dermed del i gruppen Melkeprodukter osv. QlikView laster dermed inn denne informasjonen som egen tabell FoodGroupMap. Denne informasjonen blir dermed hentet rett ut i listbox. Liste, Matvarer: Under listen for matvaregrupper finner vi listen over samtlige matvarer i hovedtabellen. Her ser vi at listbox en refererer til feltet Matvare som da er selve navnene til alle matvarene. Disse lastes og sorteres alfabetisk. 36

37 Liste, måltid: Siste langs venstre kant finner vi liste over måltider. Dette er en egen tabell som blir lastet fra database. Matvarer i måltidene på databasen lagres med MatvareID fra selve matvaretabellen og disse feltnavnene er like for både matvaretabellen og databasen. Disse feltene blir dermed automatisk assosiert og de to tabellene blir koblet. Knapper, Vis Næringsinnhold/Velg Næringstoffer: I hovedbildet øverst finner vi to knapper. Disse er koblet til samme variabel: showhidenutrient. Vis-knappen setter variabel til 0 og Velg-knappen setter variabel til 1. 37

38 Liste, Næringsinnhold: Denne listbox en viser valgte matvarer og innholdet. Avhengig av hvilke checkbox es man har krysset av i listbox en for Næringsstoffer, vil man se de ulike næringstoffene og tilhørende mengder. Lister, næringsstoffer: Denne boksen er teknisk sett 6 ulike listbox es: Energigivende, Fett, Karbohydrater, Fettløselige vitaminer, vannløselige vitaminer og mineraler/sporstoffer. Disse er da populært med tilhørende næringstoffer. Dette er for å kunne velge enkeltvis eller gruppevis for visning av de ulike næringstoffene og for visuell gruppering av hovedgruppene. Vi ser her hvordan tabellen NutrientChoices blir opprettet i load-scriptet. Under ser vi også eksempel på at listbox en for Fettløselige vitaminer har koblet til en trigger/action. Når et eller flere felt har endret seg for denne gruppen vil variabler for visning av næringstoffer endre seg. Vi ser i Edit Expression under at vi har laget en expression som henter ut informasjonen for denne gruppen og sjekker for spesifikke næringstoffnavn. Her settes dermed variablene som sørger for korrekt visning av næringsinnholdet, både i liste og graf. 38

39 Knapper, Næringsinnhold/Energi: Disse knappene setter variabel showhidenutrientmenu til henholdsvis 0 og 1. Denne variabelen bestemmer dermed om det er visning av stolpediagram for næringsinnhold eller informasjon og stolpediagram for energi i valgte matvarer. Liste, Næringsgrupper (under knapp næringsinnhold): I listen for næringsgrupper vises tabellen Nutrient Chart Choices. Denne tabellen er også lenket til en spesifikk action/trigger. Når det skjer endringer i valgene for denne tabellen vil QlikView sette variabler. Dette gjøres ved å sammenligne utvalget med Match (tekstsammenligning) og dermed sette tilhørende variabler. Disse variablene brukes til visning for grafen under Næringsgruppene. Liste, Sorter (under knapp næringsinnhold): Denne listen er opprettet i load-script og viser kolonne i tabellen avhengig av valg for hovedgruppe fra listen Næringsgruppe over. I dette tilfellet er Mineraler(sporstoffer) valgt og denne listen viser dermed liste for mer spesifikke valg i denne kategorien. Valg her reflekteres dermed i stolpediagrammet over listen. Liste, Energi (under knapp Energi): Her vises en liste over energien i de valgte matvarene. Hvert stoff regnes om til prosent og viser dermed spesifikke energigivende stoffer som del av en total beregning på 100 prosent. Under listen har man stolpediagram for å vise fordeling av energi fordelt på hovedtypene. 39

40 Side 3, Måltid: En av tankene våre ved denne web-applikasjonen var å tillate brukere å legge til utvalg av ingredienser/matvarer med tilhørende mengder i gitte grupper, som måltider. Dette ønsket vi å implementere i en egen side ved hjelp av listbox med matvarene, input-felt for mengder tilhørende valgte matvarer, input-felt for måltidsnavn, liste over andre måltider og alle tilhørende knapper for tømming av valg, sletting av måltid og registrering av måltid. Opprinnelig forsøkte vi å benytte bookmarks til å lagre utvalg av ingredienser i bokmerker som måltider. Dette er en eksisterende funksjonalitet i QlikView. Det er i utgangspunktet ingenting i veien for å bruke denne løsningen, men det er ikke mulig for bruker å direkte sammenligne to måltider visuelt. Man kan kun velge å vise ett og ett bokmerke og får derfor ikke plassert to måltider side om side. I QlikView er alle felt med samme navn automatisk koblet. Det vil si at valg innenfor et felt automatisk vil oppdatere alle grafer og valg som benytter seg av informasjonen i det valgte feltet. Ved hjelp av såkalte Selection States kan man separere ulike bokser og grafer med like felt. Disse blir dermed behandlet separat i forhold til hvilket stat de tilhører. Denne innebygde funksjonaliteten tillater derimot ikke å separere ut input-feltene for mengde. Verdien av disse feltene vil bli satt til samme verdi over samtlige selection states og to måltider med samme ingrediens blir dermed tvunget til å benytte samme verdi i input-feltet. Dette ødelegger dermed noe av poenget med måltider. Det er heller ikke mulig med en kombinasjon av bookmarks- og selection states-metodene. Bookmarks overkjører selection states og tar ikke hensyn til hvilke states som tilhører hva, kun valgene som er gjort i det bokmerket ble opprettet. Det ble derfor opprettet en egen liten database på skolen med tabellene Meal og Ingredient med felt for måltidsnavn og ingrediensmengde og id. Id er her koblet til MatvareID i selve matvaretabellen i hovedapplikasjonen. Her skulle det da kunne lagres måltider for uthenting og visning via QlikView. Verktøyet har begrensede muligheter for input og oppdatering fra brukerens side. Det er lagt lite tilrette for dette da QlikView er hovedsakelig et BI-verktøy med fokus på innhenting og sammenstilling av data, ikke oppdatering og innsetting av data. Det var dermed ingen åpenbar og direkte måte å koble til denne databasen på. Vi forsøkte derfor å benytte makroer til dette. Her benyttes VBScript eller JScript til å kjøre funksjoner ved siden av applikasjonen, men det er begrenset med hvilke funksjoner som lar benytte på server-siden i en 40

41 slik applikasjon, disse makroene kjører ikke som vanlig javascript hos klienten. I tillegg er det svært begrenset med dokumentasjon for hvordan man kan benytte dette til å koble seg opp mot databaser. Vi gjorde ulike forsøk for å se hvorvidt det var mulig å koble seg til en database via disse makrofunksjonene. Vi forsøkte direkte med både VBScript og JScript å koble til å kjøre sqlkommandoer på databasen, men støtte på noen tilkoblingsproblemer. Det ble også forsøkt å kjøre AJAX i makro for å hente informasjon via databasekoblinger i PHP-script på server. Til slutt valgte vi heller å påkoste oss et eget domene: FoodView.org. Her satte vi da opp en egen database og fikk omsider koblet til med applikasjonen. Det er derimot nødvendig med MySQL ODBC driver for å koble til. Ved testing av applikasjonen direkte med.qvw-filen må denne derfor installeres. 41

42 Beskrivelse av elementer: Mange elementer er her samme elementer som i siden for Matvarer. Hvis ikke annet er spesifisert fungerer de også på samme måte. Liste, Vis Næringsinnhold: Denne listen fungerer nesten som samme listen i siden for Matvarer. Forskjellen er at den sorter for måltider, altså en samling av matvarer, først. Den vil derfor i utgangspunktet vise totalsummen for de ulike næringstoffene i måltidet. Ved å utvide informasjonen i et gitt måltid vil man også kunne se informasjonen for de spesifikke matvarene i måltidet. Diagram, Næringsinnhold (under knapp Næringsinnhold): Dette diagrammet fungerer også nesten likt tilsvarende diagram fra siden matvarer. Forskjellen her er at stolpene vil vise summen for hvert valgt næringsstoff i valgte måltider. Liste og diagram, Energi (under knapp Energi): Denne listen og stolpediagrammet fungerer tilsvarende energilisten og stolpediagrammet fra siden Matvarer. Forskjellen er at den viser informasjonen for hver matvare i måltidet. 42

43 Knapp og visning, Opprett/Fjern Måltid: Denne knappen endrer også variabel for visning. Ved å trykke på denne knappen vil man få opp to knapper for oppretting og fjerning av måltid, input-felt for måltidsnavn og liste over valgte ingredienser for måltidet. Her skal man kunne lagre nye måltider til database. Foreløpig er det også en knapp for sletting av måltid fra database. Videre utvikling vil nok skjerme hele eller deler av databasen, eller dele den for å håndtere og beskytte hver brukers måltider. Når man trykker på knappen Opprett Måltid vil makro-funksjonen registermeal kjøre. Den henter informasjonen som er valgt og skrevet inn og oppretter deretter en kobling til databasen. Videre forsøker den en innsetting i databasen og setter statusmelding nederst på siden. Av ulike grunner har vi hatt problemer med kobling mot annet en lokal database. Det er derfor trolig at denne funksjonen ikke vil fungere helt eller delvis ved testing av applikasjonen på server. 43

44 Likeledes kjøres makro-funksjonen deletemeal når man forsøker fjerning av måltid. Side 4, Forbrenning: Bakgrunn og research I de andre delapplikasjonene er hovedfokuset å gjøre utvalg og presentere verdiene på en god måte. Vi ønsket å bruke dataene videre og så oss ut forbrenning som et svært aktuelt tema. Mye tid gikk på å sette seg inn i temaet forbrenning; da vi har liten bakgrunnskunnskap om dette temaet. Etter en del arbeid kom vi fram til en revidert utgave av Harris-Benedict-formelen: Menn Kvinner BMR = ( x vekt i kg) + (4.799 x høyde i cm) - (5.677 x alder i år) BMR = (9.247 x vekt i kg) + (3.098 x høyde i cm) - (4.330 x alder i år) Her beregnes Basal Metabolic Rate (BMR) som er den energien kroppen til en person (med oppgitt kjønn, vekt, høyde og alder) trenger i løpet av en dag i hvile. Det vil si den energien diverse organer og funksjoner i kroppen benytter. For så å regnet ut det daglige energibehovet som vi er ute etter ganges BMR med en ny konstant etter hvilket aktivitetsnivå denne kroppen er i: Lite eller ingen trening Daglig kilokaloribehov = BMR x 1,2 Lett trening (1 3 dager per uke) Daglig kilokaloribehov = BMR x 1,375 Moderat trening (3 5 dager per uke) Daglig kilokaloribehov = BMR x 1,55 Tung trening (6 7 dager per uke) Daglig kilokaloribehov = BMR x 1,725 Veldig tung trening (to ganger om dagen, ekstra tunge økter) Daglig kilokaloribehov = BMR x 1,9 Brukeren av applikasjonen vil kunne fylle inn de opplysningene som passer for så å få et daglig energiforbruk. Dette kan så benyttes til sammenligning med utvalg av ulike mengder mat fra matvaretabellen for å se hvordan man ligger an næringsmessig. 44

45 Harris-benedict-formelen kan også brukes til å beregne endring i vekt. Får en person i seg mer eller mindre energi enn hva det daglige energibehovet er beregnet til, vil han gå opp eller ned i vekt. For de personlige opplysningene: alder, høyde og vekt, har vi ikke satt noen annen begrensning enn at verdiene ikke kan være negative. Det er opp til brukeren å plotte inn de riktige verdiene. Når det gjelder endring i vekt følte vi at vi måtte sette noen grenser. Hovedpoenget er at endringer i kroppsvekt går over tid og man kan ikke forsøke å halvere sin egen vekt i løpet av ett døgn. Vi endte opp med en løsning der man kan justere opp eller ned 1000 kilokalorier på personens daglige energibehov. Deretter vises beregnet endring i vekt i løpet av en uke. En av de første tankene våre rundt forbrenning var å vise hvor lang tid det tok å forbrenne energimengden i utvalgt mengde matvarer ved ulike aktiviteter. Der var aktivitetsnivåene til formelen ikke nok. Vi fant derfor forbrenning ved ulike aktiviteter og la til disse som en egen funksjon. Det er her også mulighet til å gjøre overdrevne utvalg av matvarer og dermed få lange tidsløp med aktiviteter, men dette er likevel med på å danne et bilde av hva energien i mat er. Tar man konsekvent å velger et måltid bestående av ulike mengder av ulike matvarer, vil man få et mer realistisk bilde av hva som skal til for å forbrenne det man spiser. Ble enige om å tilby valget mellom å benytte kilokalorier eller Joule. Det er ofte kilokalorier som blir brukt om energi i mat, mens det er Joule som har blitt satt som standard SI-enhet og er ment til å ta over. Tekniske detaljer Forbrenningsfanen benytter samme utvalgsmulighet når det kommer til valg av matvarer/måltid og mengde. Denne er den samme og husker det du har valgt fra Næringsinnhold-fanen. For å beregne det daglige energibehovet må brukeren fylle inn variablene: kjønn, alder, høyde og vekt i tillegg til et aktivitetsnivå som passer. På bildet under vises formelen for BMR som er nevnt tidligere, men denne gangen i form av en expression. En if/else bestemmer hvilken formel som skal brukes ut i fra kjønnet som er valgt. Før dette igjen presenteres som daglig energibehov har vi ganget med aktivitetsnivået som vi her har kalt [BMR factor]. If-setningen her er kun for å velge valgte energienhet; kj eller kcal. 45

46 For å regne på forbrenning ved ulike aktiviteter har vi laget et eget excel-ark med disse verdiene hentet fra en av våre kilder. Dette blir så lastet inn i loadscriptet sammen med selve matvaretabellen. Side 5, Kart: Denne siden er en demonstrasjon av kartmulighetene i applikasjonen. Ved hjelp av Google Static Map API og QlikView objekter kan man hente og vise kart direkte i applikasjonen. Her lastes kartet inn basert på variablene i de tre boksene og glidebryter for zoom. Ved endringer i disse variablene vil en ny request sendes til Google og kartet/objektet vil oppdateres dynamisk. Ved hjelp av variabler sendt med request en vil man kunne få med forskjellige markører i kartet. Denne siden er kun ment som en demonstrasjon over hvordan man kan benytte seg av Google Maps i selve applikasjonen. Vi har valgt å inkludere ulike treningssentre, kiosker og matbutikker i Oslo-området. Ved en utvidelse skal det være mulig å opprette variabler med mer avanserte funksjoner. Eksempelvis kan man legge til biblioteker som inkluderer informasjon om spesifikke ingredienser/matvarer og hvor man kan finne disse i et gitt område. Dette kan deretter siles ut basert på brukervalg og velges å sendes som en gitt markørtype til Google. Man vil da få et kart med denne informasjonen tilbakesendt og vist i QlikView-objektet. 46

47 Eventuelt kan man inkludere en informasjonsboks ved siden av kartet som gir en detaljert beskrivelse av en gitt markør eller variabelvalg, enten med informasjon om en gitt matvare/ingrediens, bestemt kiosk eller en matvarekjede et cetera. For å oppnå dette er det derimot nødvendig å koble til flere datakilder eller opprette eget bibliotek for lagring av denne informasjonen, slik at man enkelt kan hente ut og vise denne. Side 6, Kostholdsråd: På samme måte som med forsiden har vi her kun knapper til å endre visning av Web Page Viewer-extensions-objekt. Knappene setter variabelen showhideadvice til en gitt verdi hvorpå riktig objekt vil vises under knappene. Bildet under viser Conditional-expression for objektet som inneholder teksten var allergikere. Denne teksten er også et html-dokument hentet direkte fra Avslutning Extensions: I QlikView er det muligheter å legge til såkalte extensions. Disse deklareres i en.xml-fil hvor man også beskriver meny- og valgmuligheter for objektet. Ved siden av beskriver man selve funksjonaliteten til objektet i en egen scriptfil. Her benyttes javascript, og her kan man kombinere med eksempelvis jquery-biblioteket. Dette betyr at man kan benytte all medfølgende 47

48 javascript-funksjonalitet for å lage nær sagt hva man vil av objekter og legge det til QlikViewdokumentet sitt. Det er derfor også lett å dele disse extensions med andre. De legges som egne filer i en gitt mappestruktur på datamaskinen og oppdages automatisk av programvaren. Det er derfor krevd som minimum noe javascript-kunnskap for å kunne lage en fungerende extension. En slik extension kan eksempelvis lete igjennom filer/databaser på server og sende data tilbake inn i QlikView-applikasjonen basert på input fra bruker. Det er derfor sannsynlig at vår løsning i forhold til måltider bør lages i form av en extension, da vi har valgt å benytte en lokal database for lagring av dette mobil-app QlikView er også tilgjengelig på mobil også. Vi testet også muligheten for å kjøre applikasjonen vår på denne. Man laster ned appen fra Itunes eller google play. Deretter må man legge nettadressen til serveren for applikasjonen ligger. Applikasjonen våres er ikke designet under utvikling, men QlikView gjør det mulig å bruke demoapplikasjonen med app en de har utviklet. Har tatt med et utvalg bilder for å vise hvordan denne fungerer. Det vi kom frem til var det fungerer, men ikke tilfredstillende for å gjøre den tilgjengelig for bruk. 48

49 Slik blir altså menyen vår i QlikView sin app. Her kan man altså klikke på de ulike applikasjonene. Hvis man åpner en av applikasjonene, så ser det slik ut. Man scroller nedover for å velge de ulike applikasjonene. Over til høyre får man en oversikt over næringsinnholdet i de ulike matvarene. De små runde knappene på undersiden, gjør at man scrolle mellom de ulike tabs ene innenfor applikasjonene. Her er det valgt Egg under matvaregruppe. 49

50 Grafene gir en bra oversikt i de forskjellige applikasjonene, men næringsgruppevalgene er ikke helt tilpasset for mobilbruk. Ovenfor har jeg gjort et valg av ål, røkt Her kan du hvordan forbrenningsapplikasjonen ser ut i appen. Det er mulig å velge mellom de forskjellge aktivietsnivåene for trening. Det er mulig å bruke denne applikasjonen, men vi måtte ha brukt mer tid på optimalisere demoapplikasjonen vår for at det skulle ha funket tilfredsstillende for aktivt bruk. Den fungerer helt ok for bruk, men er ikke tilrettelagt for aktivt brukt. 5 Testing 5.1 Enhetstest Gjennomføring: QlikView har en innebygd funksjon kalt WebView. Denne bytter grensesnittet til Internet Explorer og HTML og gir en forholdsvis nøyaktig representasjon av hvordan applikasjonen du arbeider med ser ut og oppfører seg slik en bruker vil oppleve den. Med tanke på at dette er en webapplikasjon var dette et meget nyttig verktøy for testing av objekter og funksjoner. Alle objekter, funksjoner, scripts og expressions ble derfor fortløpende testet av utviklere. Som oftest av utvikler selv og ett gruppemedlem til. Både QlikViews vanlige grensesnitt og web-viewgrensesnittet har i meget stor grad all funksjonalitet klar når et objekt er opprettet og konfigurert. Det er ikke krav om kompilering eller andre operasjoner for å kunne benytte og kjøre de mest vanlige objektene. For FoodView er det også slik at de aller fleste objektene lar seg teste på denne måten. Hvert objekt er også forholdsvis isolert i at det i liten grad er avhengig av andre objekter, men heller i større grad avhengig av informasjonen som er lastet inn først via loadscriptet. Vi fant det derfor hensiktsmessig og effektivt å kjøre tester fortløpende uten å lage test cases og analyser. 50