II Prosessdokumentasjon

Transkript

1 II Prosessdokumentasjon Bachelorprosjekt 2016 Høgskolen i Oslo og Akershus Gruppe 20

2 Forord Denne dokumentasjonen har som hensikt å gi et innblikk i gjennomføringen av bachelorprosjekt for gruppe 20 på Høgskolen i Oslo og Akershus våren Dokumentasjonen tar for seg gjennomføringen steg for steg, og belyser blant annet viktige valg og utfordringer i arbeidet med prosjektet som ikke direkte fremkommer av sluttproduktet. Prosessdokumentasjonen er strukturert i fire hoveddeler: Planlegging og metode beskriver forarbeidet gruppen har gjort. Valg av oppgave og teknologi, definere oppgavens omfang, utviklingsmetodikk og arbeidsmiljø. Utviklingsprosessen beskriver faser av utviklingen fra startfase, gjennom to utviklingsfaser og dokumentasjonsfase. Kravspesifikasjonen og dens rolle beskriver hvilke betydning kravspesifikasjonen har hatt, hvilke endringer som er gjort underveis og hvordan sluttproduktet samsvarer med endelig løsning. Avsluttende del inneholder drøfting av hva gruppen har hatt av utbytte i arbeidet med prosjektet, hva som har vært utfordrende og kunne vært gjort annerledes, de fremtidige planene for produktet og sluttkonklusjon. 1

3 Innhold Forord 1 Planlegging og metode 4 Valg av gruppe og oppgave Definere omfang av oppgaven Valg av teknologi Programmeringsspråk Plattform Internet Of Things Valg av utviklingsmetodikk Smidig utvikling Verktøy Trello Github Atom Latex Arbeidsprosess Kommunikasjon Arbeidssted Møter Interne møter Møter med oppdragsgiver Møter med veileder Fremdriftsplan Prosjektdagbok Utviklingsprosessen 9 Startfase Kunnskap og øving Oppsett av utviklingsmiljø Graf og spørring mot database Utviklingsfaser Utviklingsfase Applikasjonslayout i React Endring av databasestruktur Brukerkontoer Versjonsoppdatering av Meteor Utviklingsfase Kanban React Strukturen Design Animasjoner Node-RED og den nye databasestrukturen Hvordan graf tegnes når der ikke er data Ekstra funksjonalitet

4 Testing Valgfag Motivasjon Dokumentasjonsfase Dokumentasjon Gjennomgang av kode Kravspesifikasjonen og dens rolle 20 Prioritert funksjonalitet Endringer av kravspesifikasjonen Ikke implementert funksjonalitet Konklusjon Avsluttende del 22 Eget utbytte Teknologisk utbytte Hva kunne vært gjort annerledes Ord fra oppdragsgiver Konklusjon

5 Planlegging og metode Valg av gruppe og oppgave Gruppen ble dannet av tre studenter på Informasjonsteknologi-studiet på Høgskolen i Oslo og Akershus. Gruppemedlemmene kjente hverandre godt og hadde tidligere arbeidet sammen i prosjekter på HiOA. Prosessen med å velge oppgave startet i midten av høsten Det ble først laget en hjemmeside for gruppen ( som ble brukt til å presentere gruppen og hva vi kunne tenke oss å arbeide med av teknologi i forbindelse med bachelorprosjektet. Gruppen ønsket en oppgave bestående av både front- og backend-programmering som ga oss muligheten til å lære ny teknologi. Gruppen startet deretter å sende ut forespørsler om samarbeid til større norske aktører innen flere bransjer, blant annet musikk og finans. Etter flere avslag fant vi et prosjektforslag sendt inn til skolen fra Biogrid AS. Vi tok kontakt og avtalte møte i midten av november. Siden to av gruppemedlemmene befant seg på utveksling i Australia var det kun én representant tilstede under møte med daglig leder August Flatby hos Biogrid. En uke etter møtet er vi i kontakt med Biogrid igjen og de ønsker å samarbeide med oss. Vi takket ja til samarbeid og avtalte å møtes i midten av desember for en grundigere innføring om hva oppgaven vil innebære. Definere omfang av oppgaven Omfanget av oppgaven var definert av oppdragsgiver. De ønsket å utvikle en webapplikasjon som skal være et kontrollpanel som fremstiller data sendt fra sensorer. Sensorene skal være utplassert i landbruk og plukker opp data som f.eks co2-nivå, ph- og Rh-verdier. Sensorene inngår i det som i dag er kjent som Internet Of Things. IoT er nettverket av enheter koblet til internett. Enheter kan identifisere seg selv og kommunisere med hverandre, og utveksling av data og informasjon som ikke var mulig før har blitt mulig. Cisco (Cisco, udatert) estimerer at 50 milliarder enheter vil være koblet til internett i 2020, som da vil være alt fra datamaskiner og biler til kjøleskap. Valg av teknologi Programmeringsspråk Bakgrunnen for valgene var ønsket om å lære ny teknologi som virket relevant for fremtiden. Det var ingen krav fra oppdragsgiver om teknologi, men det var ønske om å bruke JavaScript plattformen Meteor. Vi var ikke bundet til å bruke Meteor og sto fritt til å foreslå andre webteknologier. Siden vi har grunnleggende kunnskaper om JavaScript valgte vi å etterfølge ønsket fra oppdragsgiver og utvikle 4

6 applikasjonen i Meteor. I Meteor kombineres JavaScript, HTML og CSS. Meteor integrerer med databasen MongoDB og applikasjonen vil dermed få sine data gjennom spørringer mot databasen. I Meteor står man fritt til å velge hvilket bibliotek man ønsker å bruke som frontend og igjen lot oppdragsgiver oss sjekke hvilke alternativer vi mente var aktuelle. Oppdragsgiver foreslo å sjekke ut React som er et bibliotek for å lage user interface komponenter. React skrives i JSX som rendrer HTML. Gruppen syntes React virket å være et godt alternativ i kombinasjon med Meteor og valgte derfor å bruke biblioteket. Plattform Applikasjonen kjøres på Docker. Docker brukes for å knytte sammen alle avhengigheter en applikasjonen består av og sørger for at den kjører i et miljø med de samme forutsetningene hver gang. Internet Of Things Internet of things forandrer verden vi lever i. Fler og fler ting kommer på nett. Alt fra kjøleskap, brødbakermaskiner, biler og kuer. Teknologi i dag gjør det mulig å vite at en ku skal kalve ved å overvåke bevegelsesmønstret dens. Sensorer sender data som igjen blir behandlet og prosessert av datamaskiner. All denne informasjonen kan brukes til å tilegne oss mer kunnskap om verden rundt oss og hvordan vi kan bli mer effektive. Med høyere effektivitet kommer også lavere kostnader. (Wikipedia DIKW, udatert). Felles for disse tingene er at en ting sender data over en sikker kanal f.eks MQTT som er mye brukt i IOT verden. Her blir det videresendt til en platform som behandler dataene og videresender de mest verdifulle og relevante dataene til en applikasjon eller et brukergrensesnitt. Valg av utviklingsmetodikk Smidig utvikling Figur 1: DIKW Pyramiden Gruppen valgte å utvikle smidig siden vi har erfaring med den typen utvikling fra før. Kravspesifikasjonen var relativt udefinert og derfor måtte vi være mottakelige for endringer som ville komme senere. Ved å benytte kanban gjorde vi dette mulig. Kanban er en metode utviklet av Toyota og bygger på kontinuerlig arbeidsflyt og leveranse. I kanban prioriteres oppgavene av produkteier og det fokuseres på et fåtall oppgaver om gangen for å ha et klart fokus og kunne levere så raskt som 5

7 mulig. Oppdragsgiver prioriterte våre oppgaver og gjennom prosjektet ble oppgaver omprioriterte og lagt til i backloggen uten at det påvirket pågående oppgaver gruppen arbeidet med. Ved å ha en grense på hvor mange oppgaver hvert gruppemedlem kunne arbeide med samtidig sørget vi for å opprettholde effektiviteten og levere fortløpende. (Kanban, udatert). Verktøy Det har ikke vært krav til utstyr og maskiner for prosjektet, men alle i gruppen er utstyrt med Macbook Pro og applikasjonen har derfor blitt utviklet på operativsystemet Mac OS X El Capitan. Applikasjonen er operativsystemuavhengig. Trello Trello er et prosjektstyringsverktøy som ble brukt til å organisere oppgaver for backloggen. I figur 2 kan man se tabellene som ble opprettet for hver fase en oppgave kunne være i, og hver oppgave kunne flyttes fra fase til fase. En oppgave ble representert av et kort og hvert gruppemedlem kunne sette seg på kortet. Slik kunne man kunne se hvem som jobbet med hva og hvem som hadde jobbet med hvilke oppgaver. I To Do -tabellen ble oppgavene prioritert og de med høyest prioritet lå alltid øverst. Figur 2: Gruppens tavle i Trello 6

8 Github Github er et versjonshåndteringsverktøy som gruppen har brukt for håndtering av kildekode. Vi har hatt tre repositories for prosjektet: BiogridCortex. Et offentlig repository som inneholder filer som trengs for å kjøre Docker. Dette ble opprettet og administrert av oppdragsgiver. Et repository for kildekoden til applikasjonen. Dette ble opprettet av oss og oppdragsgiver ble lagt til for å ha tilgang på koden. Et privat repository for dokumentasjonen. Ved å ha dokumentasjonen på Github har det gjort det mulig for gruppen å jobbe på kryss av filer uten at det oppstår problemer om vi har redigert på samme tidspunkt. Ved prosjektets slutt vil repositoryet som inneholder applikasjonen bli klonet inn i BiogridCortex og gjort tilgjengelig offentlig. Dette er etter ønske fra oppdragsgiver som vil at de som finner prosjektet interessant skal kunne se det og eventuelt utvikle det. Atom Alle gruppemedlemmene har brukt teksteditoren Atom. Atom er open-source og tilbyr tusenvis av tilleggspakker for å tilpasse editoren etter egne ønsker. Gruppen tok blant annet i bruk språkstøtte for React og JSX. Latex All dokumentasjon er skrevet i Latex som er et typesettingsystem for å produsere dokumentasjon. Latex tilbyr tilleggspakker som gjør arbeidet med å generere innholdsfortegnelse, lister og inkludering av figurer og bilder oversiktlig. Arbeidsprosess Kommunikasjon Gode kommunikasjonsalternativer er viktig for at informasjon skal nå alle involverte i prosjektet, inkludert oppdragsgiver. For kommunikasjon valgte vi å bruke følgende: Slack er et kommunikasjonsverktøy som tilbyr funksjoner som chat og filoverføringer. Slack tillater integrasjon av Github som gjorde at vi kunne få oppdateringer hver gang det ble pushet kode til repositories. Oppdragsgiver var en del av Slack og det ble lettere å spørre om hjelp sammenlignet med en mer formell epost. Ved å bruke Slack unngikk vi meldingstjenester som Facebooks Messenger der meldinger fra andre personer kunne virke forstyrrende. Appear.in er en gratis video chat. Det ble brukt da gruppemedlemmene ikke kunne møtes og ved et par anledninger i møte med oppdragsgiver. Epost og telefon ble brukt i tidlig fase av prosjektet mellom gruppen og oppdragsgiver. 7

9 Arbeidssted Prosjektet er i stor grad utviklet med gruppen samlet. Det var ikke mulighet å sitte hos oppdragsgiver, så gruppen har møttes hjemme hos hverandre. Ved å arbeide hjemmefra fikk vi arbeidsroen vi ønsket og kunne i friere grad møtes når vi ønsket i forhold til om vi skulle benytte oss av grupperom på skolen. Noen få ganger valgte vi å sitte på Høgskolen i Oslo og Akershus i Pilestredet 35. Møter Interne møter I og med gruppen hadde mulighet til å møtes omtrent hver dag gjennom prosjektperioden var det ikke nødvendig å avtale spesielle møter. Om vi visste vi ikke kunne arbeide samlet i løpe av to-tre dager avklarte vi arbeidsoppgaver på forhånd siste samlet arbeidsdag. Over to perioder der gruppen var borte fra hverandre i over 5 dager hadde vi daglige møter på appear.in. Møter med oppdragsgiver Oppdragsgiver hadde i starten av prosjektet ønske om å møte oss to ganger i uken, men det lot seg ikke gjøre. Møter ble derfor avtalt fortløpende i prosjektet med et intervall på ca 4 uker mellom hvert møte. Møtene ble brukt til å oppsummere hva som hadde blitt gjort i perioden siden forrige møte, sette nye prioriteringer av oppgaver og demonstrasjon av applikasjonen. Møter med veileder Det ble ikke avtalt faste møter med intern veileder fra HiOA. Gruppen kunne ta kontakt med veileder for å avtale møter etter behov. Fremdriftsplan Før utviklingsprosessen startet satt gruppen opp en komplett fremdriftsplan for prosjektet. Den er bygget opp gjennom seks hoveddeler med fokus på de fire fasene utviklingsprosessen består av: startfase, utviklingsfase 1 og 2 og dokumentasjonsfase. Alle gruppemedlemmene har hatt et fag ved siden av, og estimert arbeidstid ble derfor satt til 30 timer pr. uke for å ha tid til å arbeide med det andre faget. Det har blitt arbeidet over estimert tid. Frist for siste implementering i applikasjonen ble satt til 4.mai og dokumentasjonen skulle være ferdig én dag før endelig innlevering 24.mai. Fremdriftsplan kan ses i helhet som vedlegg. 8

10 Prosjektdagbok Det ble ført prosjektdagbok fra det tidspunkt vi tok kontakt med de første bedriftene og frem til prosjektslutt. Dagboken har gjort det enklere å gå tilbake å se hva som ble arbeidet på eller hvilke tanker og problemstillinger gruppen hadde under de forskjellige periodene i prosjektet. Utviklingsprosessen Utviklingsprosessen beskriver de ulike fasene av utviklingen. Den er delt inn i fire underfaser: startfase, to utviklingsfaser og dokumentasjonsfase. Fasene kommer kronologisk og gruppen reflekterer rundt utfordringer og viktige valg knyttet til hver av fasene. Startfase Startfasen var første fase rettet mot programmeringen av applikasjonen. Den beskriver de grunnleggende egenskapene gruppen måtte tilegne seg og hvordan dette ble gjort. Fasen gikk fra 2.februar til 5.mars. Kunnskap og øving Første tid av startfasen gikk med på å bli kjent med teknologiene vi skulle bruke. For å føle oss best mulig forberedt lærte vi oss hver teknologi hver for seg fremfor å prøve å kombinere dem fra første stund. Det ble brukt flere kilder til læring: Offisiell dokumentasjon: Både Meteor Development Group og Facebook som henholdsvis står bak Meteor og React har skrevet god dokumentasjon som er tilgjengelig på internett. Gruppen benyttet seg også av tutorials som er laget av selskapene. På den måten tilegnet vi oss basiskunnskaper før vi skulle kombinere de to teknologiene. MongoDB som var vår database hadde offisiell dokumentasjon på sine nettsider. Annen dokumentasjon, artikler og diskusjoner: I dag finnes det store utviklingsmiljøer på internett der det er lett å finne nyere og oppdatert informasjon. Gruppen benyttet flere nettbaserte kilder som Github, Stack Overflow og Discover Meteor. Discover Meteor har i tillegg lansert en bok som gruppen fikk tilsendt av oppdragsgiver som pdf. (Coleman & Greif, 2015). Videotutorials: Både for å få innfallsvinkler på hvordan man kunne bruke teknologier og lære grunnleggende prinsipper benyttet gruppen seg av gratis videotjenester som Youtube der vi kunne lære av tutorials produsert av andre utviklere. 9

11 Oppsett av utviklingsmiljø Tidlig i startfasen var vi i møte hos oppdragsgiver der gruppen fikk satt opp utviklingsmiljøet i Docker lokalt på sine maskiner. På denne måten fikk vi sikret at alle programmerte i samme miljø på like premisser og uten andre påvirkninger. Slik kunne oppdragsgiver være sikker på at applikasjonen ville kjøre når den settes ut i produksjon siden den vil være innstallert i eksakt samme miljø. Gruppen fikk innføring i hvordan miljøet skulle startes og stoppes og hvordan applikasjonen er én av byggeklossene i miljøet. For å få en større forståelse leste vi oss opp om Docker og hvilke fordeler dette ga. Med miljøet kjørende var vi i stand til å genere data til databasen og dermed ta et steg videre mot å vise dataene. Graf og spørring mot database Tidlig i startfasen ønsket gruppen å teste ut om valget av bibliotek for grafer var riktig. Biblioteket ble testet med hardkodet data for å prøve ut de forskjellige funksjonene som var inkludert. Det gikk forholdsvis raskt å sette seg inn i biblioteket og tegne en graf med hardkodet data. Siden grafen skulle tegnes med data hentet fra databasen kunne vi kombinere arbeidet med grafen med å bli kjent med strukturen i databasen. Det var på dette tidspunktet gruppens første store utfordring oppstod. Figur 3: Objekter i databasestrukturen Utfordringen var å traversere datastrukturen slik at korrekt data ble hentet ut og lagret i en string som skulle sendes til metoden som tegnet grafen. Datastrukturen for verdier i databasen er bygget opp gjennom objekter slik figur 3 viser. Hver time og hvert minutt er representert som objekter og sekundet som inneholder selve verdien er en double-verdi. Problemet var å aksessere time- og minuttobjektene i rett rekkefølge for å hente ut hvert sekund. Gruppen forsøkte først å gjøre én spørring mot databasen pr. verdi, men kom frem til å gjøre én spørring som lagret alle verdiene i et array ville være en bedre løsning. Med denne løsningen ble det lettere å traversere gjennom verdiene ved hjelp av for-løkker. 10

12 Utviklingsfaser Perioden med utvikling av applikasjonen er delt opp i to deler, fase 1 og fase 2. De to fasene beskriver utfordringer som oppstod under utviklingen og hvordan gruppen kom frem til de forskjellige løsningene. Utviklingsfase 1 Utviklingsfase 1 varte fra 5.mars til 1.april. Applikasjonslayout i React Før gruppen startet utviklingen av applikasjonen hadde vi satt opp en grov skisse av hvordan vi ønsket den skulle se ut. Første prioritet i denne fasen ble å sette opp de mest elementære komponentene for å få applikasjon til å kjøre. Komponentene utgjorde tre sider brukeren av applikasjonen skulle kunne navigere seg gjennom: Innloggingsside. Foreløpig side med en knapp for å sende videre til siden med lokasjoner. Side med oversikt over lokasjoner. For denne siden ble det hardkodet inn en liste med lokasjoner og koblet linker til hver av lokasjonene slik man kunne trykke på disse for å gå videre. Kontrollpanelet. Etter valgt lokasjon ble man sendt videre til det som etter hvert skulle bli kontrollpanelet. Det var på denne siden grafene skulle vises. Siden graf-komponenten allerede var fungerende kunne gruppen begynne å implementere den og dens funksjoner i kontrollpanelet. Oppsettet av de tre sidene gjorde at vi kunne sette opp en midlertidig routing mellom sidene og samtidig bli bedre kjent med hvordan dataflyten mellom reactkomponenter fungerte. Endring av databasestruktur Halvveis ute i fasen bestemte oppdragsgiver seg for å endre datastrukturen i databasen. Fra å ha én collection der alle data var lagret skulle databasen nå bestå av åtte forskjellige collections. Dette ble betydningsfullt for hvordan vi skulle få hentet verdiene tilknyttet hver sensor. Figur 4 viser den nye strukturen og sammenhengen mellom collections. Sammenlignet med tidligere databasestruktur der det ble gjort én spørring for å hente data ble vi avhengig av å gjøre spørringer mot hver collection i en viss rekkefølge for å aksessere reading collection som inneholdt de data som skulle brukes i tegning av grafer. 11

13 Figur 4: Forhold mellom collections i ny datastruktur Oppdragsgiver sendte et skjema med oppsett av de nye collectionene og gruppen inkluderte oppsettet i applikasjonen. Første steg med å spørre mot site collection gikk forholdsvis enkelt, men etter dette fikk vi problemer siden vi var avhengig av å ta vare på resultatet fra første spørring og sende dette videre til en annen komponent for å kunne foreta spørring mot neste collection. Siden react-komponenter er bygget opp på prinsippet om en nedgående dataflyt - data sendes fra forelder og ned til barn - ble vi nødt til å dele spørringene utover flere komponenter som hadde en slik relasjon. Siden vi ikke ønsket å ta i bruk enda en arkitektur som Redux for å ta vare på data mellom komponenter, og som igjen kunne gjøre arkitekturen mer kompleks enn nødvendig, valgte vi å lage foreldrekomponenter. I foreldrekomponentene gjorde vi spørringer mot ønsket collection og sendte dataene til barne-komponentene som rendret HTML ut i fra hvilke data som ble mottatt. En annen utfordring som oppstod i forbindelse med flyten av data mellom komponenter var den reaktive måten React henter data fra databasen på. Ved oppdatering i databasen har React en metode som henter data reaktivt til komponentene, men vi klarte ikke å kontrollere når denne skulle kjøre. Det gjorde at vi kunne få mellom tre og fem kjøringer av metoden før vi fikk returnert et resultat som 12

14 inneholdt et komplett sett av data. For å ikke vise en tom side eller komponent mens applikasjonen ventet på at alle data skulle bli klare valgte vi å rendre en melding som forklarte at data lastes eller data ikke var tilgjengelige. De overnevnte utfordringene tok lengre tid å rette opp enn det gruppen hadde beregnet. Det tok omtrent to og en halv uke fra vi fikk vite om endringene til applikasjonen var tilpasset og fungerte som den var ment å gjøre. Dette var ikke forventet og medførte at oppgaver ble forskjøvet. Brukerkontoer I følge opprinnelig arbeidsplan skulle brukerkontoer og innloggingsfunksjon implementeres til slutt i prosjektet, men ble omprioritert til denne fasen. Siden den nye databasestrukturen var basert på spørringer i rekkefølge ville vi ha på plass funksjonen for å logge inn på et tidligere tidspunkt siden det var første steg i rekkefølgen av spørringer. Meteor har en egen tilleggspakke for å kunne lage innloggingsfunksjon og gruppen valgte å bruke den siden den var godt dokumentert, men også for å utnytte rammeverket fullt ut fremfor å ta i bruk et tredjeparts bibliotek. Det ble raskt satt opp en side for å logge inn ved hjelp av en ferdig template som tilbød funksjoner man forbinder med innlogging som glemt passord og å lage ny bruker. Ved å bruke templaten hadde vi lite kontroll over inkluderte funksjoner og hvordan designen var, derfor ble templaten forkastet og en innlogging ble bygget fra bunnen av. Oppdragsgiver var ikke interessert i å ha funksjoner for å opprette bruker eller få tilsendt passord på nytt, dermed kunne vi ta utgangspunkt i å lage logg inn. Arbeidet med funksjonen foregikk parallelt med å løse utfordringene med databasestrukturen slik at utviklingen ikke stoppet fullstendig opp. Versjonsoppdatering av Meteor Applikasjonen er utviklet i Meteor versjon 1.2, men i slutten av mars ble versjon 1.3 lansert (Meteor Blog, 2016). Oppdateringen innebærer en del store forandringer i forhold til hvordan en applikasjon i tidligere versjon er bygget, der i blant hvordan man reaktivt skal hente og oppdatere data. Meteor (Meteor Guide, udatert) sier at versjon 1.2 fortsatt skal fungere, men at man gradvis bør oppdatere siden man får utviklet og feilsøket i ES2015. Det ble vurdert en oppdatering til versjon 1.3, men gruppen kom frem til at det ville bli for mange forandringer på for mange deler av applikasjonen. Blant annet måtte React blitt inkludert gjennom pakkemanageren npm (NPM, udatert) for deretter å bli inkludert i hver fil, og måten hvordan data ble hentet fra databasen på måtte totalforandres ved bruk av en funksjon kalt createcontainer i Meteor. Tidsbruk for å fullføre oppdateringen ble beregnet til å ta for mye tid av gjenstående prosjektperiode og det ble hovedgrunnen til at en versjonsoppdatering ikke ble foretatt. 13

15 Utviklingsfase 2 Utviklingsfase 2 ble startet med å planlegge i detalj hvordan denne utviklingsfasen skulle utarte seg fremover. Det var nå blitt enda viktigere å overholde tidsfrister og frem mot innleveringsdato 24 Mai. Utviklingsfase 2 varte fra 1.april til 4.mai. Kanban Gruppen bestemte seg for å bruke Kanban som smidig utviklingsmetodikk. Mange arbeidsoppgaver begynner å bli komplette og back-loggen begynner å bli stadig mindre. Imidlertid er det stadig nye oppgaver som kommer til. Mindre feil og bugs som ikke har blitt oppdaget under utvikling og testing dukker opp. På grunn av dette går gruppen noe vekk fra Kanban prinsippene om en ferdigstilt oppgave. I stedet for å utføre et og et oppgavekort har det blitt utført litt og litt på mange forskjellige oppgaver. Oppgavekort har blitt sendt frem og tilbake mellom To Do, In progress og Done. I tillegg har oppgaver blitt utvidet. Noen oppgaver ble også bare gjort ferdig halvveis før en annen oppgave ble påbegynt. Dette skjedde da en oppgave tok lengre tid enn planlagt, eller at andre oppgaver trengte oppmerksomhet. I ettertid skulle man hatt mer fokus på å definere en oppgave nøyaktig. Det kan virke som om en oppgave har blitt lagt til for fort, uten å tenke nok igjennom omfanget og påvirkning av andre elementer. Oppgavekort har også blitt satt for fort til Done uten å ha testet og man har forsikret seg om at det ferdige resultatet er tilfredstillende. React Strukturen I utviklingsfase 1 ble det satt opp en grov skisse på hvordan arkitekturen i applikasjonen kunne se ut. Hovedsakelig for å teste hvordan komponenter fungerer, men også at komponentene fungerer på korrekt måte. 2 måneder senere jobber vi fortsatt med den samme strukturen. I React er det sentralt med forhold mellom komponenter. Det er vanlig med parent-child komponenter, altså at et element er barn av en forelder-komponent. Noen av våre komponenter begynner å bli forholdsvis kompliserte. Strukturen vår begynner å bli veldig dyp. Sending av data mellom komponentene som React er et meget godt rammeverk for, begynner å bli vanskelig på grunn av kompleksiteten til strukturen. Det har etterhvert gått opp for gruppen at dette ikke er den beste måten å strukturere applikasjonen på. Utviklingen burde stoppet opp og restrukturering av komponentene hadde vært hensiktsmessig. Selv dette tatt i betrakting valgte vi å ikke forandre strukturen. Det var nok av andre oppgaver i back-logen vår som trengte vår fulle oppmerksomhet og det var ikke tid til å starte en full restrukturering. Et annet argument for å ikke restrukturere er bekymringer for at applikasjonen kommer til krasje. Uthenting av data fra databasen er på plass og dette har tatt veldig lang tid. Om dette må utføres på nytt vil ikke tidsrammene vi har satt på prosjektet bli overholdt frem mot innlevering. 14

16 Design I et tidligere møte med oppdragsgiver ble det tatt opp design på applikasjonen. Det var ønskelig at funksjonalitet var første prioritet, men om det var tid til det hadde det vært hensiktsmessig å utarbeide en god design på applikasjonen også. Siden gruppen nå var godt ute i andre utviklingsfase begynte diverse funksjonalitet å falle på plass. Utviklingen startet å gå den veien vi ønsket. Det begynte fortløpende å melde seg et behov for å utforme designen på applikasjonen. Gruppen satte seg sammen og diskuterte hva som måtte gjøres for å få applikasjonen til å se mer profesjonell ut. Det ble valgt at applikasjonen skulle ha et svart tema med sterke lyse farger på tekst og grafer som skulle skille seg ut fra resten. ble brukt for å finne ut hvilke farger som kunne passe godt sammen. Figur 5: Paletton.com Figur 6: Basisfarger Figur 7: Font-valg Det ble bestemt å bruke fonten HelveticaNeue- Light som støttes av de fleste moderne nettlesere. Dette ble brukt gjennom hele applikasjonen for å gi en sammenheng på siden. Gjennom hele applikasjonen ble det påført luft mellom de forskjellige elementene. På denne måten ble det ikke for mye informasjon presset inn på et sted og brukeren får en bedre totaloversikt. Animasjoner Små ting som animasjoner kan gjøre en side mye mer levende. På den andre siden kan animasjoner gjøre en applikasjon uoversiktlig og rotete. Det ble bestemt å bruke animasjoner på noen få utvalgte elementer. Når en bruker går inn på kontrollpanelet for en lokasjon blir de tilgjengelige dataene fadet inn. En stor utfordring var å få animasjonene til å animere slik vi ønsket. Det var fullt mulig å animere i CSS og JavaScript, men vi følte det var lite hensiktsmessig når React har egne innebygde funksjoner for animasjon. Det ble derfor tatt en avgjørelse om at vi skal forsøke å bruke animasjonene til React fullt ut. Gruppen ønsker å bruke React så langt det er mulig. Det tok litt lengre tid en planlagt å sette seg inn React sine animasjoner. Syntaks og oppbygging av animasjonen var annerledes enn hva vi var vant med. Selv om React er veldokumentert var det ikke alltid like lett å forstå hvordan eksemplene i dokumentasjonen fungerte. 15

17 Node-RED og den nye databasestrukturen I møte med oppdragsgiver tidlig i utviklingsfasen satte vi opp et utviklingsmiljø slik at vi kunne arbeide på like premisser med like data. Dette ble gjort med Docker og Node-RED. Node-RED produserte fiktive sensordata for oss, som vi igjen kunne behandle og tegne grafer med. Som tidligere nevnt ble databasestrukturen endret av oppdragsgiver. Det ble brukt mye tid på å omstrukturere vår kode for å tilpasse oss den nye strukturen, men Node-RED ble ikke oppdatert til å produsere data til den nye strukturen. Oppdragsgiver skulle oppdatere oppsettet på Node-RED, men dette har ikke blitt utført. Vi på den andre siden hadde heller ikke mulighet til å starte å sette oss inn i Node-RED å omprogrammere de gamle komponentene så sent i prosjektet. En konsekvens av dette er at vi nå ikke får testet applikasjonen med livedata fra Node-RED som tidligere, men ved å legge inn data manuelt ser vi at applikasjonen fungerer som den skal når data blir behandlet. Hvordan graf tegnes når der ikke er data Under møter med oppdragsgiver ble det diskutert hva som skjer med en graf når den ikke inneholder data. Med andre ord, hvordan vil en graf bli tegnet hvis det er avbrudd i løpet av dagen og det ikke blir mottatt data? Dette var en problemstilling gruppen ikke hadde tenkt på. Nå blir grafen fortsatt tegnet selv om det er brudd i dataflyten. Det vil bli en rett strek mellom sist kjente punkt og neste kjente punkt. Oppdragsgiver ønsker at dette er vår hovedprioritet fremover, da grafen kan tolkes på flere måter. Ved mindre avbrudd er det vanskelig å se om det har vært nedetid i løpet av en dag. Oppdragsgiver ser for seg en løsning som i figur 8 der grafen ikke blir tegnet i punkter det ikke finnes data for. 16

18 Figur 8: Oppdragsgiver sitt forslag, Illustrasjon via Photoshop Det skal vise seg at løsningen oppdragsgiver ser for seg er mer komplisert enn forventet. Som nevnt i produktdokumentasjonen bruker vi grafbiblioteket dygraphs. Løsning som oppdragsgiver ser for seg er ikke mulig i dygraphs. Det ble løst ved å ikke tegne linjen over fyllområdet der det manglet datapunkter som vist i figur 9 under. Figur 9: Endelig løsning Ekstra funksjonalitet Gruppen har fått på plass fremvisning av de forskjellige sensorene. Det var nå ønskelig fra vår side å kunne fremstille mer data. Vi testet med å vise antall sensorer og hubs. Det ble laget en metadata komponent, figur 10, som er plassert over grafene. Det er kun 1 av de 4 boksene som fremstiller ekte data per nå. De 3 andre er hardkodet inn og er bare eksempler. Vi slet med å fremstille de relevante data vi ønsket. En oversikt over antall sensorer som er nede og ikke sender data hadde vært relevant å illustrere i kontrollpanlet. Det skulle vise seg å lage en slik løsning var mer komplisert enn planlagt. Så sent i utviklingsfase 2 blir det ikke noe mer utvikling av en slik løsning. Grunnet kompleksiteten og tidsperspektivet må andre oppgaver prioriteres. Gruppen testet ut implementasjonen av yr.no sitt API. Oppdragsgiver så for seg å kunne fremstille værdata i grafen for sensordata, med både historiske og kommende prognoser. Det kunne vært av interesse å sammenligne værdata med dataene fra egne sensorer. Det hadde vært veldig interessant å implementere dette i oppgaven, men det var nok av andre oppgaver som lå i back-loggen og ventet på oss på dette tidspunktet. Dette var heller ikke et krav fra oppdragsgiver i kravspesifikasjonen. Hele prosjektet om vær-api ble derfor skrinlagt inntil videre. 17

19 Figur 10: Metadata-komponent Testing Oppdragsgiver har ikke satt noen krav til testing av applikasjonen. Dette har da heller ikke vært i fokus under utviklingen. Det som har vært ønskelig for oppdragsgiver er at applikasjonen var brukervennlig og enkel å forstå for brukerne. Underveis i utviklingen ble det testet på dataene vi behandlet. Spesielt med tanke på henting av data fra databasen måtte vi benytte oss mye av JavaScript sin innebygde funksjon console.log() for å se hva som ble hentet. I mange tilfeller ble det hentet ut helt feil data og denne måten å jobbe på hjalp oss å finne fram til riktig måte å hente korrekt data. Brukertesting ble utført flere ganger under utviklingen for å hele tiden kunne optimalisere applikasjonen. Applikasjonen ble testet på medstudenter og bekjente. Dette for å se at brukergrensesnittet var intuitivt og at interaksjonen fungerte som planlagt. I login-skjermbildet ble det ikke oppdaget spesielle utfordringer knyttet til brukervennlighet da dette er en ganske vanlig utforming på ett innloggingsvindu. Forklarende feilmeldinger blir synlig for brukeren. Videre i site-delen av applikasjonen var det uklart om hva som skulle trykkes på for å komme seg videre. Det startet med at kun navnet på stedet var en klikkbar link, mens kartet i underkant var interaktivt. Dette viste seg å være en løsning testerne hadde forskjellig synspunkter på. Noen skjønte med en gang at teksten skulle klikkes på for å komme seg videre, mens noen prøvde å klikke på kartet for å komme videre. Løsningen ble å gjøre hele boksen med både navn og kart klikkbar. Videre testing av denne løsningen gjorde at alle testerne klarte å komme seg videre uten problemer. På kontrollpanelet var det største usikkerhetsmomentet å forstå hvilket tidsintervall som var valgt. Applikasjonen gav ingen tilbakemelding på dette og løsningen ble å ha en blå strek under valgt tidsintervall. Valgfag Ved siden av bacheloroppgaven har gruppen hatt et annet fag, Software Architecture and Frameworks. Faget bestod av flere innleveringer som tok tid gruppen gjerne skulle hatt til bachelorprosjektet. Dette medførte flere mindre opphold i arbeidet med oppgaven. 18

20 Motivasjon Motivasjonen til gruppen begynte å synke i siste halvdel av utviklingsfase 2. Det føltes til tider tungt å rette i små-bugs som tok for lang tid å fikse. Bugs som har så liten betydning i det store og hele totalintrykket, men som allikevel var veldig synlige for oss. Det føltes ut som vi hadde jobbet på de samme tingene i evigheter. Allikevel har tiden gått raskt. Det føltes ut som om det var i forrige uke vi hadde de første møtene med oppdragsgiver og fikk hjelp med å sette opp Docker. Gruppen forsøkte å holde motivasjonen oppe og fortsette inn mot leveringsfrist. Alle var enige om at dette var noe vi hadde lagt ned mye tid i og ønsket å få en god karakter. Gruppen ønsket å levere et produkt som vi kunne være stolte av og som innfridde oppdragsgivers forventinger. Dokumentasjonsfase Dokumentasjonsfasen var den siste fasen av prosjektet. Selv om noe av dokumentasjon var skrevet underveis i prosjektet ble det meste av dokumentasjon skrevet i perioden mellom 25.april og frem til innleveringsfrist 24.mai. Her følger en beskrivelse av de viktigste hovedpunktene gruppen arbeidet med i siste fase. Dokumentasjon For å gjøre dokumentasjonsskrivingen effektiv delte vi den opp slik at hvert gruppemedlem fikk hovedansvar for en spesifikk del. Personen med hovedansvaret fikk i oppgave å utarbeide et oppsett på hva vi ønsket å ha med under hver dokumentasjonsdel med underliggende stikkord for emnene vi ønsket å skrive om. Etter at forslaget var utarbeidet gikk gruppen sammen for å diskutere og bli enige om et endelig oppsett, men med rom for endringer senere i fasen. Da alle oppsett var klare begynte hvert gruppemedlem å skrive på dokumentasjonsdelen som det var tilordnet ansvaret for, og på denne måten fikk vi skrevet på hver del av dokumentasjonen samtidig. Fortløpende gjennom skriveprosessen satt gruppen seg sammen og gjennomgikk hva som var blitt skrevet. Ved å gjennomgå alt i fellesskap kom vi med forslag til forbedringer og tilbakemeldinger på det som var skrevet og vi unngikk å få én persons synspunkt på emner som gjaldt for hele gruppen. Utgangspunktet for dokumentasjonen har vært kompendiet dokumentasjonsstandard(høgskolen i Oslo og Akershus, udatert) med de tilpasninger vi har følt vært naturlig for vårt prosjekt. Gruppen har opplevd det som utfordrende å skrive dokumentasjonen i å med vi ikke har skrevet dokumentasjon som har vært like omfattende tidligere. Det var utfordrende å utarbeide et oppsett for hva vi ønsket å skrive om og sortere ut hva som var relevant og ikke. Etter hvert som dokumentasjonen kom ordentlig i gang og strukturen fikk mer helhet ble det lettere å velge ut hva som kunne være med eller ikke. 19

21 Gjennomgang av kode Gruppen har vært konsistent når der gjelder skriving av kode, men det ble satt av tid i fasen til å gjennomgå all kode og sørge for at denne fulgte retningslinjene fra AirBnb styleguide (AirBnB styleguide, 2016), etter ønske fra oppdragsgiver. Ved å følge styleguiden har gruppen produsert kode som ser lik ut og er satt opp ryddig. Styleguiden var i seg selv lærerik og begrunnet hvorfor kode skulle skrives som den ble gjort. Vi har brukt variabel- og funksjonsnavn som er selvforklarende. Det gjør koden mer lesbar og forståelig for en person som ikke har arbeidet med koden i den grad vi har. Kravspesifikasjonen og dens rolle Kravspesifikasjonen skal fungere som en kontrakt mellom oppdragsgiver og oss studenter. Kravspesifikasjonen var med å danne omfanget av oppgaven. Kravspesifikasjonen fungerte som en rød tråd for oss og pekte oss i riktig retning av utviklingen. Spesielt i startfasen ble kravspesifikasjonen brukt mye for å fokusere på hva som var viktigst å få på plass først. Kravspesifikasjonen var fleksibel og kunne endres senere i prosessen, noe den også ble. Kravspesifikasjonen kan ses i sin helhet som vedlegg. Prioritert funksjonalitet Første prioritering var å få plukket opp dataene som ble sendt fra sensorene. Uten disse dataene på plass var det ikke mulig å videreutvikle applikasjonen. Etter at sensordata ble implementert fant vi et passende bibliotek for fremstilling av dataene i grafer. Det ble satt som krav at Bootstrap skulle brukes, så et enkelt brukergrensesnitt for testing ble satt opp i kombinasjon av Bootstrap og React komponenter. Endringer av kravspesifikasjonen Siden kravspesifikasjonen var relativt dynamisk stod gruppen og oppdragsgiver frie til å legge til ekstra funksjonalitet som vi mente var relevant for applikasjonen. Dette ble utført etter at kravene fra den originale kravspesifikasjonen var utført. For eksempel utvidet vi databasen til å inneholde koordinater til lokasjoner. På denne måten var det mulig å fremstille på et kart hvor lokasjonen befant seg. Dette ble gjort gjennom Google Maps sitt API. Utover i oppgaven var det mulighet for å jobbe mer med designen på applikasjonen. Oppgaven i seg selv hadde ikke fokus på design, allikevel ønsket vi å levere et produkt som skulle se bra ut. I siste del av utviklingsfase 2 ble det jobbet mye med å få en god og brukervennlig design på applikasjonen. 20

22 Ikke implementert funksjonalitet Under møter med oppdragsgiver kom det frem at måten vi hadde løst det å fremstille data når det ikke var data ikke var tilfredstillende nok. Oppdragsgiver informerte om at det var høyeste prioritet og alle andre oppgaver måtte settes til side. Gruppen fikk ikke løst oppgaven slik oppdragsgiver hadde sett for seg, men kom med et alternativt forslag. I forlengelse av Google Maps APIet ønsket vi å benytte oss av et vær-api for fremstilling av live værdata. Dette ble diskutert i samarbeide med oppdragsgiver slik at det var felles konsensus om at dette var relevant for applikasjonen. Oppdragsgiver likte godt forslaget om et vær-api. Muligheter for å sammenligne sensordata med værdata kunne være ekstremt nyttig. Gruppen begynte å arbeide med implementasjonen av et vær-api men i slutten av utviklingsfasen skjønte gruppen at dette kom til å bli for komplisert og ta for lang tid. Konklusjon Det har vært spennende og utfordrende å jobbe med en såpass fri kravspesifikasjon. På den ene siden hadde vi strenge krav om hvordan data skulle fremstilles, men på den andre siden stod vi fritt til å velge den teknologien vi mente var best for å nå målet. Den originale kravspesifikasjonen ble utvidet med ekstra krav til funksjonalitet etter som oppgaver ble fullført. Funksjonaliteten satt i den originale kravspesifikasjonen ble innfridd, men noen punkter som ble lagt til senere utgikk. 21

23 Avsluttende del Denne delen tar for seg hvordan oppgaven har fungerte for oss som gruppe og hvilke utbytte vi har fått gjennom prosjektperioden. Eget utbytte Alle i gruppen er enige om at vi har lært mye gjennom denne perioden. Noe av det som utpeker seg ekstra er det å jobbe med en oppgave over så lang tid. Tidligere har vi hatt noen større prosjekter igjennom skolen, men ikke i nærheten av hva denne oppgaven har krevd av oss. Det har vært utfordrende og spennende å jobbe for noen utenfor skolen med teknologibakgrunn. August fra Biogrid har lenge jobbet med utvikling og vi følte det som en realistisk smakebit på hvordan arbeidslivet kunne utarte seg da vi samarbeidet med Biogrid. Nytt for gruppen er også dette med dokumentasjon av slik karakter. Kommunikasjonen innad i gruppen har fungert bra. Vi har i tidligere prosjekter brukt Facebook som foretrukken kanal for kommunikasjon, noe som har fungert bra. Ved å bruke Slack har vi hatt en mer profesjonell kommunikasjon. Gjennom bruk av Slack har vi også fått hjelp av Meteor miljøet. Vi har fått hjelp og innspill ved å spørre i Meteor sin offisielle Slack kanal, noe som har vært veldig nyttig for oss. Teknologisk utbytte Før vi valgte oppgave var vi alle veldig motiverte og spente på hva slags oppgave vi skulle få jobbe med. Alle var enige om at siden vi skulle jobbe såpass lenge med denne oppgaven ønsket vi en oppgave som ikke bare var spennende og motiverende, men også en oppgave som var relevant for oss etter at skolen var ferdig. Meteor og React er teknologier som ikke har vært like lenge tilgjengelig som PHP og Java. Meteor var helt nytt for oss og tok tid å sette seg inn i all den tilgjengelige funksjonaliteten. Vi har parallelt med utviklingen av vår oppgave fulgt med på hvordan Meteor også har utviklet seg. Dette er naturligvis veldig vanskelig å gjette, men utifra hva vi har sett så blir Meteor og miljøet rundt Meteor bare større og større. i løpet av denne oppgaven har Meteor blitt oppgradert til 1.3 versjon og støtte for npm pakkehåndtering. React.js fremstår heller ikke som en døgnflue. For et år siden var Angular veldig i vinden og alle skulle ha utviklere som kunne det. I dag er det fler og fler jobbannonser som skriver at de trenger folk som kan React.js. I teknologiradaren til BEKK 2016 (BEKK Teknologiradar, 2016) er React fremhevet som noe av det heteste i år å utvikle front-end med. Vi er derfor veldig fornøyde med å ha jobbet med noe som er ettertraktet på arbeidsmarkedet. 22

24 Hva kunne vært gjort annerledes Helt i startfasen da vi kom i kontakt med oppdragsgiver så vi for oss tett samarbeid. Det var snakk om møter hver uke og tett oppfølging. For oss som studenter er dette noe vi synes er svært viktig. Allerede tidlig i startfasen går det opp for oss at vi ikke kommer til å ha så tett oppfølging som forespeilet. Oppdragsgiver er veldig opptatt og har mange prosjekter i gang samtidig. Vi begynner å se ulempene med å jobbe med et så lite firma. Andre bekjentes grupper som skriver for større selskaper får bruke kontor, utstyr og har egne ansatte til å hjelpe de med prosjektet, mens vi sliter å få kontakt med vår oppdragsgiver. I utviklingsfase 2 drøftes dette med fullføring av oppgaver. Vi har ikke vært flinke nok til å jobbe med en oppgave om gangen. Oppgaver ble halvveis utført for deretter å bli lagt tilbake i backloggen og en annen ny oppgave me påbegynt. Dette gjorde at vi måtte gå tilbake til oppgaver for å fullføre dem. Dette stemte ikke overens med prinsippene om smidig utviklingen gjennom kanban. Sent i utviklingsfase 2 jobbes det en del med designet på applikasjonen og det går opp for oss at Bootstrap har blitt brukt for mye. Ferdig-generert CSS må overkjøres for å få det slik vi ønsker. Dette begynner å ta tid og blir mer komplisert enn det burde være. I sammenheng med dette skulle vi ha ønsket at vi benyttet oss av SASS. Både for å lære oss et nytt språk, men også for en enklere og mer effektiv utvikling av design. React-strukturen skulle ha blitt forandret. Dette går opp for oss for sent i oppgaven at dette er en struktur som ikke skalerer for vår applikasjon. Etter litt diskusjon i gruppen blir vi enige om at det ikke er tid til å omstrukturere applikasjonen. Applikasjonen vår fungerer som den skal, men måten det er bygget opp er ikke optimalt. 23

25 Ord fra oppdragsgiver Studentene var veldig samarbeidsvillige og lydhøre, og var spesielt interesserte i å utforske Meteor, MongoDB, React og Docker. Jeg synes applikasjonen ble veldig bra, den løser oppgaven på en god måte, og med moderne webutviklings-teknologier. Et av problemstillingene rundt IoT-prosjekter er at mye data produseres, og at det kan være utfordrende å visualisere disse dataene på en hensiktsmessig måte. Studentene løste dette på en elegant måte ved hjelp av et open source rammeverk for fremstilling av grafer. Applikasjonen vil bli en integrert del av Biogrids videre satsing på et større rammeverk for IoT-baserte tjenester. Dette er en utvidelse av den opprinnelige ideen om kun å lage et system for bruk til innendørs dyrking av grønnsaker. - August Flatby 23/ Konklusjon Som gruppe er vi fornøyde med resultatet vi har levert inn. Vi har nådd våre egne personlige mål om å videreutvikle oss og lære nye programmeringsspråk. Vi leverer inn et produkt vi er stolte av og mer enn gjerne setter på vår CV. I tillegg har det vært hyggelig at Biogrid er veldig fornøyd med det endelige resultat og at det stod til over forventning. Gruppen har fungert godt gjennom hele prosjektet. Alle 3 kjente hverandre godt fra før av, men det er alltid spennende hvordan det skal bli når man går så tett på hverandre over lengre tid. Det har vært konflikter og uenigheter, men alle disse har blitt løst på en god måte i plenum med konstruktive argumenter og forsøk på å se den andre part sine argumenter. Oppfølgingen fra oppdragsgiver kunne helt klart vært bedre, men vi er allikevel fornøyde med det samarbeidet vi har hatt. Det har vært spennende å få et innblikk i hvordan en fremtidig arbeidssituasjon kan se ut. 24