Vedlegg A: Prosessdokumentasjon

Transkript

1 Vedlegg A: Prosessdokumentasjon A.1. Redegjørelse Temabakgrunn Alto, skyen på Høgskolen i Oslo og Akershus, er bygget av forskningsgruppen der på huset. Hovedpersonen bak skyen er Kyrre Begnum, førsteamanuensis, og er også vår oppdragsgiver. Det hele startet med at oppdragsgiver hadde ett problem. Han hadde en sky, men visste ikke om den fungerte. Tanken var at dette kunne være et passende bachelorprosjekt, for noen skyinteresserte studenter, og det var her vi kom inn. Vi ble presentert skyen av veilederen vår Alfred Bratterud, høgskolelektor, sammen med OpenStack og OpenTSDB, og detaljer rundt dette. Det ble tidlig fastslått at vi skulle lage en overvåkningsløsning for skyen, og at det var en del mangler i eksisterende løsninger. Det viktigste for oppdragsgiveren virket å være å kunne se så mye data på en gang som overhodet mulig. Og få satt dataene i sammenheng, altså se flere datakilder på samme tid, i samme vindu. Slik begynte prosjektet vi nå refererer til som Perspect.io. Problemstilling Vi skulle merke at å skrive en problemstilling til dette prosjektet skulle bli vanskelig fort. Etter en del forslag hvor skyen var nøkkel i problemet, kom vi frem til at vi kunne lage en mer generell løsning, som ikke bare kunne overvåke sky. Siden systemet skulle vise seg å visualisere data fra en database som er indeksert på tid, og det var eneste begrensing, kunne man fremstille mye mer enn kun skyhelse. Problemet var ikke lengere hvordan overvåke en sky brukervennlig og effektivt, men mer

2 i banene av hvordan man kan overvåke data som vi ikke vet hvordan ser ut og som endrer seg hele tiden. Istedenfor å overvåke sky, ble det helt generelt overvåking av big data. Omfangsbegrensning Målet vårt for denne oppgaven var å lage overvåkningsløsningen for skyen. Vi hadde mange ideèr. Og vi sammenlignet de påtenkte widgetene, som delbart materiale. Vi så for oss en side med widgets, hvor man kunne se hvem som hadde laget den, hva den monitorerte, og hvor mange likes den hadde fått. Vi ville lage ett form for sosialt medium, for skyovervåkning. Meldingssystem kom fort på banen, at hadde vært interessant å ha, for å snakke om widgets, og for enkel deling av dem. Etterhvert tenkte vi at det samme måtte være mulig å gjøre med påtenkte brett, men først av alt måtte vi ha data å vise frem i widgeter på brett. Så det var naturlig å begynne her. I samtale med veileder og oppdragsgiver ble vi også enige om at dette blir nice to have -features. Fordi vi har hatt disse tankene, skal det ikke være vanskelig å implementere dette, men når alt kom til alt, ble det ikke tid til å lage dataovervåkningsens facebook. Prosesshistorie Gruppen hadde sitt første møte med oppdragsgiveren og veileder den På dette møtet presenterte oppdragsgiver hva han ønsket at gruppen skulle lage. Oppdragsgiver skulle ha rollen som project owner, mens veilederen skulle være rådgivere angående teknologier som skulle brukes, og en sterk fagperson. Vi gikk så igjennom hvilken type teknologi som kunne være aktuell å bruke.

3 Det ble også fastsatt at vi ønsket å gjøre et forsøk på forskningsrapport når både oppdragsgiver og veileder hadde god kontroll på hvordan dette var utformet. Vi så på det som en mulighet til å forberede oss til masteroppgaven om to år, de av oss som skulle det. Vi brukte deretter tiden over jul på å se på teknologi som kunne være relevant og få enda bedre oversikt over OpenStack, og tenke på hvordan en sluttløsning kunne bli. Det første møtet vi hadde på nyåret gikk vi igjennom hva oppdragsgiver ønsket seg av produktet og hvordan vi man skal skrive en introduksjon i en masteroppgave. Vi begynte snarlig å produsere det første kapitlet. I det andre møtet i januar så fikk vi en grundigere gjennomgang av hvordan Alto, skyen på Høgskolen i Oslo og Akershus, er bygd opp og hvordan opentsdb fungerte. Det var viktig at vi fikk vite hvordan alt fungerte for å lage APIet. Etter møtet så ble arbeidoppgave ble fordelt i oppgavene backend, design og widgets. Backenden består av å lage et API som kommuniserer med OpenTSDB og sender ferdig prosessert til frontend. Designet går ut på å lage rammen som siden skal kjøres i, samt implementere nødvendige biblioteker for å tilrettelegge for ryddige visning av flere ting. Vi ønsket også å gjøre designet responsivt. Vi så for oss noen små applikasjoner som kjørte i noen bokser som skulle visualisere data, vi valgte og kalle de for widgets.

4 Vi leste oss opp på mer teknologi, og fant ut etter testing hvilke teknologier vi ønsket å benytte oss av. Videre begynte vi å skrive neste kapittel i rapporten, på tross av manglende tilbakemelding på første kapittel. Det var i midten av mars vi var i samtale med oppdragsgiver om tilgang til noen flere ressurser i skyen for å kunne visualisere data fra virituelle maskiner. Her ble det store diskusjoner rundt ustrukturerte og strukturerte data. Vi hadde tatt utgangspunkt tidlig i at det ville bli en form for trestruktur. Når endringen kom så betydde dette store omveltninger i programmet. Vi begynte omstruktureringen av hele produktet vårt med en gang, men det var en mye tyngre prosesse enn hva vi trodde, og vi var offisiellt bak skjema. Vi måtte få gjort ferdig produktet fortest mulig. I mai så begynte det å haste å få ferdig rapporten, siden koden hadde blitt såpass avansert og resultater lot vente på seg, begynte store deler av gruppen å fokusere på rapportferdigstiling når vi innså at dette begynte å bli minst like kritisk som produktet. Beslutningsprosess Måten vi har håndert problemer og valg underveis er ved den godt anerkjente demokratiske avstemningen. Siden vi gruppemedlemmenes antall var partall, hadde vi en valgt gruppeleder som i de tilfeller det skulle være nødvendig hadde dobbelt stemme. Dette var noe vi i liten grad brukte når gruppen stort sett var enige om hvordan ting måtte gjøres når alle hadde fått vist frem sitt syn på saken. Vi som gruppe var interessert i å høre på de som hadde erfaring med like situasjoner, eller teknologier fra før og deres stemme ble derfor vektet tyngre de stedene det var naturlig.

5 Utgått arbeid Hele vårt system har blitt gjort om for å passe tidsstemplet data. Den alpha versjonen vi hadde klart i mars, er det mindre deler av som er representert i det endelige produktet. Vi hadde fler widgets, vi hadde ett annerledes backend api, og vi hadde enda ikke sett nødvendigheten til et frontend-api. Disse delene har blitt omarbeidet, eller kastet når de ikke har vært aktuelle for produktet lengere. Bidragsytere Kyrre Begnum underviser på masternivå på Høgskolen, og har stilt alle sine oppgaveskrivings seminarer tilgjengelige på nett. Dette har gitt oss muligheten til å se gode eksempler på hvordan en forskningsrapport skal bygges opp, og vi har brukt mye tid i disse videoene. Det viktigste er at vi har kunnet brukt tid på dette når det har passet for oss i en hektisk hverdag. Samtidig har vår veileder Alfred Bratterud veiledet på en annerledes måte enn hva vi forventet på forhånd. Han har stilt en mengde kritiske spørsmål og har hjulpet oss til å forme produktet, slik vi ønsker, og som fremdeles er teknisk godt. Kombinasjonen av disse fagsterke menneskene, og den hjelpen vi har fått fra dem, har hjulpet oss igjennom en fremmed verden av forskning, skytjenester og abstrakte modeller. Utarbeiding av artikkelen De første utkastene til de første kapitlene ble skrevet i sammarbeid, med nokså lik arbeidsmengde. Men det blir ofte slik at når man utvikler ett produkt, og ønsker seg gull, vil alltid de som er sterkest i faget jobbe med å perfeksjonere det fysiske systemet.

6 Dette førte til at noen av deltakerene har bidratt til de produktkritiske delene av rapporten, mens resten har formet artiklen og styrt prosjektet i den retningen det måtte for å komme i mål. Det er gruppen som har formet artiklen som i har kontroll-lest, og vært fagpersoner i de redaksjonelle banene. Vi valgte å bruke Google Drive til utvikling av rapporten, når dette onlinesystemet innehar mange av de egenskapene vi kjenner fra GIT. Vi får muligheten til å samtidig kunne redigere samme dokument i sanntid, og kan fortløpende legge kommentarer knyttet til spesifikkedeler av teksten.

7 A.2. Milepælsplan Aktivitestplan - forberedelse Aktivitestplan - implementering

8 Alle våre grener har samme milepæler og er delt opp etter rekkefølge: 1. Informasjon tilegnet 2. Protoyp produsert 3. Implementert med de andre grenene 4. Ferdigstilt produkt

9 A.3. Prosjekstyringsapplikasjoner Netbeans Et gratis utviklingsmiljø (IDE) for programvareutviklere som gjør det mulig å utvikle integrerte applikasjoner for Java, PHP, C++, HTML5 og andre platformer. Dette verktøyet er nyttig til utvikling av produkter fordi det har høy funksjonalitet uansett hvilke språk man utvikler i, og spesielt om man har flere språk å forholde seg til er dette et stort pluss. Google Drive En gratis og nettbasert programvarepakke med ulike programmer tilpasset kontorbruk som f.eks. Microsoft Office. Flere brukere kan opprette, dele og redigere dokumenter samtidig i sanntid. Samtidig er det lett å lagre dokumenter både på og fra egne PC er i flere forskjellige filformater. yed Et kraftig cross-platform diagramprogram som er raskt, effektivt og kan kjøres på blant annet Windows, Linux og Mac OS. Programmet kan tegne mange forskjellige type diagrammer. Trello En gratis webapplikasjon for projektstyringsformen kanban. Prosjektene er representert med dashbord som inneholder kort med oppgavelister. Disse oppgavelistene blir da flyttet mellom kortene, oftest da mellom opprettede To Do, Doing og Done. Vagrant Vagrant er en gratis applikasjon som veldig enkelt setter opp lokale utviklingsmiljøer. Ved å zfortelle Vagrant hvilken oppskrift den skal følge, setter den opp en virtuell

10 maskin og installerer ønsket operativsystem og programvare. Vagrant gjør det også smertefritt å reinstallere utviklingsmiljøet hvis man har eksperimentert og vil begynne fra scratch.