BACHELORPROSJEKT. Allora

Transkript

1 PROSJEKT NR. Gruppe 27 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpent Telefon: Telefaks: BACHELORPROSJEKT HOVEDPROSJEKTETS TITTEL Allora DATO ANTALL SIDER / BILAG 200 / 20 PROSJEKTDELTAKERE Chirster Erik Bang Kristoffer Gard Osen Daniel Aleksander Thoresen Trym Skilleås INTERN VEILEDER André Rognes OPPDRAGSGIVER Prego Media AS KONTAKTPERSON Robin Bang SAMMENDRAG Allora er en webapplikasjon med formål å automatisere tidkrevende og manuelt arbeid for de ansatte i Prego Media. Applikasjonen lar de ansatte vedlikeholde bedriftens produktdatabase og binder sammen bedriftens sentrale data. Prego Media ønsker å kunne benytte seg av applikasjonen i daglig drift. 3 STIKKORD Webapplikasjon MEAN-stack Sikkerhet

2 HØGSKOLEN I OSLO OG AKERSHUS FAKULTET FOR TEKNOLOGI, KUNST OG DESIGN Bacheloroppgave i Ingeniørfag - Data Sluttrapport Veileder: André Rognes Oppdragsgiver: Prego Media AS Kontaktperson: Robin Bang Gruppe 27: Daniel Aleksander Thoresen Kristoffer Gard Osen Trym Skilleås Christer Erik Bang

3 Innhold 1 Presentasjon 2 2 Kravspesifikasjon 2 3 Prosessrapport 2 4 Produktrapport 2 5 Testrapport 2 6 Brukerveiledning 2 7 Deployeringsveiledning (Vedlegg 1) 2 8 Prosjektdagbok (Vedlegg 2) 2

4 HØGSKOLEN I OSLO OG AKERSHUS FAKULTET FOR TEKNOLOGI, KUNST OG DESIGN Bacheloroppgave i Ingeniørfag - Data Presentasjon

5 Innhold 1 Gruppen 2 2 Oppdragsgiver og bakgrunn for oppgaven 2 3 Prosjektoppgaven 3 4 Beskrivelse av applikasjonen 4 1

6 1 Gruppen Gruppe 27 består av Trym Skilleås, Christer Bang, Kristoffer Osen og Daniel Thoresen. Vi er fire studenter ved «Ingeniørfag - Data»-linjen på HiOA. Vi møttes tidlig i studietiden, har jobbet på flere forskjellige prosjekter og har opparbeidet en god arbeidsdynamikk oss i mellom. Selv om av alle har forskjellige interesseområder, føler vi at vi har lik smak hva teknologier og løsninger gjelder. Alle er vandt til å jobbe i prosjekter med høyt ambisjonsnivå og vi var så på at denne samlede erfaringen kunne føre til et godt samarbeid. 2 Oppdragsgiver og bakgrunn for oppgaven Prego Media er et medieselskap som driver utleie av reklameplasser og er en ledende aktør innenfor utendørsreklame. Prego Media tilbyr utleie av fem forskjellige mediekanaler. Billboards er enkle reklameflater over hele landet, Backlight er bakbelyste flater i Oslo sentrum, Carpark Panorama er store flater installert i parkeringshus og Convenience er skjermer montert i Deli De Luca og Narvesens filialer. I dag består Prego Media av 5 ansatte og tar stadig større andel av markedet. Bedriften benytter seg i dag av regneark for å holde oversikt over planlagte kampanjer, disponible reklameflater, monteringslister, og fakturagrunnlag for gårdeiere de leier veggplass av. Det krever mye tid og arbeid å kryssjekke informasjon mellom alle regnearkene, og Prego har selv konkludert at løsningen ikke er bærekraftig på sikt, ettersom at selskapets katalog øker raskt. (a) Backlite (b) Carpark Panorama Vi ble gjort oppmerksom på at Prego Media var interessert i å inngå et samarbeid og vi lærte om hvilke problemstillinger de sto ovenfor med sitt daværende system. Før vårt første møte med de ansatte diskuterte vi 2

7 mulige løsninger og kom fram til at en webapplikasjon var en naturlig retning å gå. På møtet ble dette bekreftet, Prego Media var også interessert i en webapplikasjon. De ansatte var spesielt opptatt av at løsningen skulle binde sammen de tidligere separerte dataene de brukte regneark for å organisere. Både gruppen og de ansatte var sikre på at sammen kunne vi komme fram til den beste løsningen. Å løse problemstillingene med en webapplikasjon passet oss bra, vi hadde nettopp fullført emnet «Webapplikasjoner» ved HiOA og følte oss kompetente til å utvikle en solid løsning. Figur 1: Billboard, med og uten frontbelysning. 3 Prosjektoppgaven Vår oppgave er å utvikle en webapplikasjon for Prego Media. Applikasjonen vil brukes internt i selskapet som et verktøy i den daglige driften. Prego Media vil at løsningen skal binde sammen tidligere separerte, sentrale data for bedriften, fortrinnsvis bedriftens produkt- og gårdeierdatabase. Applikasjonen skal gjøre det enkelt å vedlikeholde produktdatabasen og forbedre de ansattes arbeidsflyt. Det ønskes også funksjonalitet for å trekke ut rapporter, beregninger og dokumenter fra denne kombinasjonen med data. Applikasjonen må være tilgjengelig i nettleser for interne og eksterne maskiner. Problemene vi måtte løse var: Hvordan lagre dataene på en hensiktsmessig måte Hvordan presentere dataen oversiktlig Hvordan gjøre riktig beregninger for rapporter Hvordan gjøre applikasjonen en naturlig del av de ansattes arbeidsflyt Hvordan sikre applikasjonen 3

8 4 Beskrivelse av applikasjonen Web-applikasjonen vi har laget for Prego Media har fått navnet «Allora» og er et verktøy som skal hjelpe bedriften å begrense tidkrevende, manuelt arbeid. Den bygger på strukturer og begreper de ansatte er kjent med, mens den binder sammen datastrukturer som tidligere var adskilte. Applikasjonen lar de ansatte vedlikeholde bedriftens produktdatabase, knytte produkter til kampanjer og gårdeiere og produsere dokumenter basert på disse relasjonene. Figur 2: Startsiden Applikasjonen møter de ansatte med en startside som gir god oversikt over de viktigste tallene for bedriften. Øverst på startsiden vises en oversikt over hvor mange av de forskjellige reklameflatene bedriften har. Under dette er det en kalender som viser status for hver uke. Kalenderen viser hvor mange «Billboard»-flater som er ledige og hvor mange som er opptatt hver uke. Kalenderen viser også hvilke kampanjer som går over hvilke uker. I applikasjonen kan de ansatte bygge opp en produktdatabase med de forskjellige reklameflatene de tilbyr. Hvis bedriften anskaffer flere flater kan de ansatte legge disse til og hvis dataene for en flate er feil, kan de ansatte endre de. Reklameflatene kan også samles i serier som de ansatte selv definerer. Applikasjonen gir de ansatte to oversiktslister for hver type produkt: En enkel oversiktsliste hvor flater kan endres eller slettes og en liste som viser uke for uke hvilke reklameflater som har en reklameplakat oppført og hvilke som er ledige. Alle disse listene kan sorteres på alle feltene og filtreres på serier eller byer. 4

9 I motsetning til Prego Medias tidligere løsning kan man i applikasjonen knytte reklameflater til en gårdeier. Når bedriften skal betale en gårdeier for veggplassene de leier, kan applikasjonen nå kalkulere beløpet som gårdeier kan fakturere for og generere et brev de ansatte kan sende ut på epost eller pr brev. Dette er en oppgave som tidligere tok en ansatt to uker å fullføre, mens den nå kun krever et par museklikk. Også for gårdeier har applikasjonen en oversiktsliste hvor de ansatte kan slette, endre og vise detaljert informasjon om en gårdeieren. Her kan de ansatte også endre hvilke reklamefelter som tilhører den enkelte gårdeieren. Figur 3: Oversikt over gårdeiere Det som bestemmer om en reklameflate er ledig eller ikke, hva bedriften skylder en gårdeier eller hvilke reklameflater det skal klistres opp plakater på i neste uke er avhenging av at noen har booket en reklamekampanje. Derfor er det å opprette kampanjer en sentral del av applikasjonen. En kampanje opprettes ved å oppgi hvem som er kunden, hvor lenge kampanjen varer og hvilke reklameflater som inngår i den. På samme måte som for reklameflater og gårdeier får de ansatte også en oversiktsliste for kampanjer. Her kan de ansatte endre informasjonen om kampanjene, endre hvilke reklameflater som skal inngå i kampanjene og slette kampanjer. For å kunne gi bedriftens kunder en bedre forståelse for hvilke områder deres kampanje dekker, kan de ansatte trekke ut kartdata om de enkelte kampanjene fra applikasjonen. Denne kartdataen kan importeres i en karttjeneste bedriften allerede benytter seg av og den vil vise hvor de forskjellige reklameflatene befinner seg. Applikasjonen lar de ansatte også trekke ut slik data om gårdeiere og serier. Prego Media samarbeider med andre aktører på markedet for å få montert 5

10 opp reklameplakater på flatene. Disse aktørene arbeider med lister i regneark for å holde styr på hva som skal monteres på hvilke flater. Applikasjonen gir de ansatte mulighet til å generere slike regneark fra dataene i applikasjonen og disse kan lastes ned og sendes til montørene. Applikasjonen er designet for å være tilgjengelig over internett, så det er viktig at applikasjonen er sikker. Derfor er det implementert bruker-autentisering ved innlogging. Alle ansatte har en egen brukerkonto. En super-bruker har autorisasjon til å opprette og slette brukere. I tillegg til bruker-autentisering blir all trafikk sendt kryptert over https og passord lagres kryptert i databasen. Alle disse egenskapene utgjør en løsning som forbedrer arbeidsflyten til de ansatte og sparer bedriften for tid og penger. 6

11 HØGSKOLEN I OSLO OG AKERSHUS FAKULTET FOR TEKNOLOGI, KUNST OG DESIGN Bacheloroppgave i Ingeniørfag - Data Kravspesifikasjon

12 1 Forord Kravspesifikasjonen ble skrevet tidlig i utviklingsprosessen og reflekterer et innsiktsnivå som ikke måler seg med nivået vi har endt på sent i prosjektperioden. Kravspesifikasjonen har fungert som et styringsdokument og hovedlinjene er fulgt gjennom hele prosessen og her ikke blitt endret. Noen detaljer er blitt endret og/eller utdypet ettersom vi fortløpende har funnet bedre løsninger, mens noen funksjonelle krav har falt bort basert på prioriteringer vi har gjort sammen med de ansatte i Prego Media. Innhold 1 Forord 1 2 Presentasjon Gruppen Oppdragsgiver Oppgaven Bakgrunn Forord 3 4 Systembeskrivelse Funksjonelle krav Ikke-funksjonelle krav Datamodeller 6 6 Krav til dokumentasjonen 7 1

13 2 Presentasjon Prosjekttittel: «Allora» 2.1 Gruppen Gruppe 27: Daniel Thoresen Kristoffer Gard Osen Trym Skilleås Christer Erik Bang Veileder: André Rognes Førsteamanuensis, HiOA Tlf: Epost: Bedriften: Prego Media AS Tlf: Grev Wedels Plass Oslo Kontaktperson: Robin Bang Produktansvarlig Tlf: Epost: robin@pregomedia.no 2.2 Oppdragsgiver Prego Media er et medieselskap bestående av mennesker med tilsammen 60 års erfaring i mediebransjen. De tilbyr i dag seks ulike OOH media-kanaler med fokus på store formater. Prego Media ønsker å være en dynamisk utfordrer i OOH markedet og deres hovedmål er å tilby målrettede og kostnadseffektive løsninger til våre kunder. 2.3 Oppgaven Prego Media ønsker et system som kan brukes til å booke kampanjer, vedlikeholde kundedatabase og danne fakturagrunnlag. Systemet har som mål å forenkle og effektivisere manuelle oppgaver samt tilføye ny funksjonalitet. 2

14 2.4 Bakgrunn Prego Media er en leverandør av utendørs reklameplasser. «Billboards», som er utleie av store reklameflater utendørs, er deres største av totalt seks forskjellige mediekanaler. De er idag fem ansatte og tar stadig større andel av markedet. Prego Media ønsker et system som kan brukes til å booke kampanjer, vedlikeholde kundedatabase og danne fakturagrunnlag. Systemet har som mål å forenkle og effektivisere manuelle oppgaver samt tilføye ny funksjonalitet. 3 Forord Hensikten med en kravspesifikasjon er at den skal fungere som et styringsdokument for gruppen, slik at det blir enklere å løse uenigheter som oppstår underveis i prosjektet. Ved hjelp av kravene som er beskrevet kan man lettere ta beslutninger og justere retningen om det skulle bli nødvendig. Kravspesifikasjonen fungerer som en avtale med oppdragsgiver. Sammen har vi kommet fram til ønsket funksjonalitet og de de konkrete mål for utvikling av systemet. Den skal i tillegg fungere som en referanse i senere tid for prosjektets tiltenkte retning og funksjon. 4 Systembeskrivelse Prego Media ønsker et system som kan brukes til å booke kampanjer, vedlikeholde kundedatabase og danne fakturagrunnlag. Systemet har som mål å forenkle og effektivisere manuelle oppgaver samt tilføye ny funksjonalitet. De vil ha utviklet et håndteringssystem som de ansatte i bedriften kan bruke for å holde oversikt. Her skal de kunne administrere kampanjer, kunder, gårdseiere, produkter og fakturagrunnlag. Kampanjene inneholder informasjon om hvilke produkter som til enhver tid er utleid hvilken kunde. Basert på historikken som lagres kan systemet generere rapporter basert på ulike kriterier. Her vil de ha presentert nøkkelinformasjon på en oversiktlig og brukervennlig måte. Det er ønskelig at systemet inneholder en CRM-løsning med funksjonalitet for logging og påminnelser. Fakturagrunnlaget dannes ved å kalkulere perioden en gårdseier har hatt en kampanje på sin gård. Prego Media ønsker at systemet kjører i nettleseren på forskjellige arbeidsstasjoner på kontoret og private laptoper. Det er viktig at systemet er tilgjengelig overalt fra en cloud-server. 3

15 4.1 Funksjonelle krav nr Krav Prioritet Kommentar 1 En bruker skal kunne booke en kampanje Høy En bruker skal kunne booke en kampanje som knytter boards, kunde og gårdeier sammen. 2 En bruker skal få en visuell fremstilling av bookinger 3 En bruker skal kunne generere rapporter ved ønske 4 Det skal kunne genereres monteringslister til montører. 5 En bruker skal kunne kunne opprette, se, endre og deaktivere boards, gårdeier, kunde og serier 6 En bruker skal til en hver tid kunne få en intuitiv og oversiktlig framvisning av ledige board. Høy Høy Høy Høy Høy En bruker skal kunne få en detaljert redigerbar kalendervisning av hvilke boards som er ledig til hvilken tid. En bruker skal kunne generere rapporter fra ønsket tidsintervall basert på tidligere bookinger til bruk for å finne hva Prego skylder gårdeier for leie av annonseplass Montørene som setter opp annonser på billboards skal kunne få lister over hva som skal monteres hvor på bestilling. En bruker vil ikke kunne slette, men sette det aktuelle som inaktiv. Dette for å ivareta historikk. En bruker skal enkelt se hva som er ledig for å vite hva vedkommende kan tilby kunden. 7 Notifikasjonssenter Middels En bruker skal kunne aksessere et notifikasjonssenter for å får få oversikt over, kampanjer som utgår den gitte dag, evt. andre avtaler som måtte inntreffe den dagen. 8 Framvisning av boards og serier gjennom kart Lav En bruker skal se en oversikt over boards og booke boards gjennom klikk på aktuelle lokasjoner i en karttjeneste 9 Enkel CRM-funksjonalitet Lav En bruker skal kunne få oversikt over tidligere korrespondanse med en kunde, samt. legge ved kommentarer om kunde for framtidig referanse. 4

16 4.2 Ikke-funksjonelle krav nr Krav Prioritet Kommentar 1 Applikasjonen skal være tilgjenglig uavhengig av toplogi Høy Den skal kunne nås av alle interessenter 2 Applikasjonen skal være sikker Høy Det skal være tilnærmet umulig for uvedkommende å sikre seg tilgang til applikasjonen og data lagret i dens forbindelse. 3 Applikasjonen skal være intuitiv og selvforklarende Høy Det skal ikke være nødvendig med omfattende opplæring i bruk av applikasjonen 4 Applikasjonen skal være grundig testet 5 Applikasjonen skal være rask og ha kort responstid 6 Applikasjonen skal fungere optimalt på moderne nettlesere Høy Høy Høy Det er ønskelig å levere en så feilfri applikasjon som mulig da vi ikke har mulighet til å supportere den etter applikasjonen er overlevert. Applikasjonen skal ikke være kilde til frustrasjon som følge av tregheter 5

17 5 Datamodeller Figur 1: Databasemodeller 6

18 Figur 2: MEAN-stacken 6 Krav til dokumentasjonen Det skal enkelt komme frem av dokumentasjonen hvordan systemet er bygget opp, slik at det er enkelt å videreutvikle og vedlikeholde i fremtiden. Brukerdokumentasjon må også kunne anvendes som referanse for de ansatte i bedriften i forbindelse med opplæring i systemet, i tillegg til en generelt intuitiv oppbygging. Det skal komme klart frem av prosessdokumentasjonen hvilke utfordringer og valg gruppen har støtt på underveis i utviklingsprosessen, og hvorfor gruppen har tatt de enkelte avgjørelsene for å løse disse problemene. 7

19 HØGSKOLEN I OSLO OG AKERSHUS FAKULTET FOR TEKNOLOGI, KUNST OG DESIGN Bacheloroppgave i Ingeniørfag - Data Prosessrapport

20 1 Forord I prosessrapporten vil vi beskrive prosessen det har vært å gjennomføre hovedprosjektet. Det er fordelaktig, men ikke avgjørende at leseren har lest presentasjonsdelen før prosessrapporten. Viktig informasjon vil bli repetert hvor det er nødvendig. Språket i prosessrapporten er holdt til et lavt teknisk nivå og der tekniske begreper benyttes, følger også en forklaring slik at leseren kan få en god forståelse av innholdet. Prosessen blir beskrevet i fem individuelle kapitler, i følgende rekkefølge: Innledning - En innledende del som gir leseren grunnleggende informasjon om gruppen, oppdragsgiver og bakgrunnen for oppgaven. Planlegging og metode - Planlegging av utviklingsprosessen, beskrivelse av metoder og verktøy. Utviklingsprosessen - Kronologisk fortelling om utviklingsprosessen, samt mer detaljerte beskrivelse av enkelte temaer, tilegnede erfaringer, valg vi har tatt og utfordringer vi har møtt. Kravspesifikasjonen og dens rolle - Kravspesifikasjonens rolle i utviklingsprosessen, og endringer i denne underveis. Avsluttende del - Avsluttende ord for prosessdokumentasjonen 1

21 Innhold 1 Forord 1 2 Innledning Om oppdragsgiver og bakgrunn for oppgaven Prosjektoppgaven Planlegging og metode Planleggingsmetoder og verktøy Smidig utvikling Scrum Begrunnelse for bruk av Scrum Sprinter Planlegging av sprint Sprint Sprint Sprint Sprint Sprint Vår erfaring med Scrum Trello Arbeidsflyten med Trello Vår erfaring med Trello Git/GitHub Google Drive Facebook Webstorm Fremdriftsplan Prioriteringsliste Arbeidsforhold og kommunikasjon Prosjektdagbok Forhold til oppdragsgiver Veiledning fra HiOA Utviklingsprosessen Startfasen Reasearch Bygge opp et REST-API Utformer brukergrensesnitt Forbedrer eksisterende funksjonalitet og bygger på ny Ferdigstiller databasemodellene Utvider med forskjellige typer reklameflater HTML-oppdeling

22 4.5.4 Lister og seleksjon Modaler Hvordan velge datoer Kalender Eksport av kartdata Generering av brev til gårdeiere Generering av masterliste Hvordan har API-et forandret seg Bootstrap Innlasting av data Andre Erfaringer Asynkronitet Informasjonssikring og sikkerhet rundt applikasjonen Begrensninger Sprinter Planlegging av sprint Komme igang Sprint Sprint Sprint Sprint Sprint Kravspesifikasjon Kravspesifikasjonens rolle Rammekrav Samsvar mellom kravspesifikasjon og endelig produkt Krav som ikke er med i det endelige produkt Notifikasjonssenter - prioritet: middels Framvisning av boards og serier gjennom kart - prioritet: lav Enkel CRM-funksjonalitet - prioritet: lav Applikasjonen skal være grundig testet - prioritet: høy Applikasjonen skal være rask og ha kort responstid - prioritet: høy Databasemodell Avsluttende del Arbeidsfordeling og samarbeid Forhold til veileder Forhold til oppdragsgiver Læringsutbytte Konklusjon

23 2 Innledning 2.1 Om oppdragsgiver og bakgrunn for oppgaven Prego Media er et medieselskap som driver utleie av reklameplasser og er en ledende aktør innenfor utendørsreklame. Prego Media tilbyr utleie av fem forskjellige mediekanaler. Billboards er enkle reklameflater over hele landet, Backlight er bakbelyste flater i Oslo sentrum, Car Park Panorama er store flater installert i parkeringshus og Convenience er skjermer montert i Deli De Luca og Narvesens filialer. I dag består Prego Media av fire ansatte og tar stadig større andel av markedet. Prego benytter seg i dag av regneark for å holde oversikt over planlagte kampanjer, disponible reklameflater, monteringslister, og fakturagrunnlag for gårdeiere de leier veggplass av. Det krever mye tid og arbeid å kryssjekke informasjon mellom alle regnearkene, og Prego har selv konkludert at løsningen ikke er bærekraftig på sikt, ettersom at selskapets katalog øker raskt. Med utgangspunkt i dette har vi og de ansatte i Prego Media kommet fram til at en web-løsning som binder sammen de tidligere separerte dataene vil være det beste for å kutte ned på unødvendig manuelt arbeid og for forenkle hverdagen til de ansatte. 2.2 Prosjektoppgaven Vår oppgave var å utvikle en webapplikasjon for Prego Media. Applikasjonen vil brukes internt i selskapet som et verktøy i den daglige driften. Prego Media vil at systemet skal binde sammen sentrale data for selskapet, fortrinnsvis selskapets produkt- og gårdeierdatabase. I tillegg ønskes det å trekke ut rapporter, beregninger og dokumenter fra denne kombinasjonen med data. Applikasjonen må være tilgjengelig i nettleser for interne og eksterne maskiner. Problemene vi måtte løse var: Hvordan lagre dataene på en hensiktsmessig måte Hvordan presentere dataen oversiktlig Hvordan gjøre riktig beregninger for rapporter Hvordan gjøre applikasjonen en naturlig del av de ansattes arbeidsflyt Hvordan sikre applikasjonen 4

24 3 Planlegging og metode 3.1 Planleggingsmetoder og verktøy Nedenfor følger en oversikt, samt kort beskrivelse av verktøy og hjelpemidler vi har benyttet oss av under gjennomføringen av prosjektet: Smidig utvikling Smidig utvikling, også kalt agil utvikling, er en modell for programvareutvikling som har blitt svært poplært, og er i godt innarbeidet hos mange firmaer i programutviklingsbransjen. Det finnes flere forskjellige modeller innen smidig utvikling, hvor av de mest kjente er Scrum, Kanban, og Extreme Programming. Hovedpoenget med smidig utvikling er å tillate endringer i krav og funksjonalitet underveis i utviklingsprosessen, uten å måtte forkaste store mengder arbeid og igangsette prosessen på nytt. Gruppemedlemmene hadde grunnleggende kjennskap til denne metodikken fra tidligere fag på HiOA, og ble enige om at dette var en god måte å organisere utviklingsprosessen på. Vi besluttet å bruke Scrum-metodikk som vi ned-skalerte etter behov for prosjektet Scrum Scrum er et rammeverk laget for å optimalisere utvikling av informasjonssystemer. Scrum baserer seg på utvikling og leveranse i korte iterasjoner. Med andre ord fordeler man utviklingen i iterasjoner, eller «sprinter», hvor innholdet i hver sprint blir avtalt på et «Scrum-møte» der alle partene er tilstede. Innholdet hentes fra prosjektets «backlog», en liste over funksjonalitet som skal implementeres for å nå målet, og legges i en sprint-backlog som representerer målet for hver iterasjon. I tillegg til å definere målet for hver sprint, evaluerer man hva som er gjort siden forrige møte, og hva som eventuelt hindrer effektiviteten til hvert enkelt medlem ved implementering av funksjonalitet. Slik fortsetter utviklingen inkrementelt helt til applikasjonen er ferdigstilt Begrunnelse for bruk av Scrum Vi har som nevnt erfaring med Scrum fra før og vi hadde en veldig klar visjon om hvordan utvikling med Scrum ville fungere for oss. På et bachelorprosjekt med fire gruppemedlemmer er det noen aspekter ved Scrum som ikke gir mening eller ikke er mulig å ta i bruk. Vi har valgt å ta i bruk de to aspektene som er viktigst for et prosjekt på vår størrelse: Backlog og sprinter. Vi skulle gjerne hatt mulighet til å benytte oss av et tredje aspekt, nemlig hyppige møter med og demonstrasjoner for oppdragsgiver. Dette var dessverre ikke mulig å koordinere for begge parter. 5

25 Alle gruppemedlemmene har jobbet med hverandre fra før av, noen gjennom hele utdanningsløpet og vi er godt kjent med dynamikken oss imellom. I en slik situasjon kan det fort skje at man blir litt for komfortabel og ikke jobber så effektivt og godt som man har potensiale til. Vi mener at å organisere arbeidsflyten vår strengere enn det vi er vant til ved bruk av sprinter, kan ha positivt utslag på effektiviteten vår. 3.2 Sprinter Vi valgte utviklingsperiode fra starten av februar til slutten av april. Ved å avslutte utviklingsperioden på dette tidspunktet, fikk vi ca en måned til dokumentering. Utviklingsperioden delte vi inn i sprinter på 1 uke, med noen sprinter som strakk seg over 2 uker Planlegging av sprint På mandager startet vi en ny sprint ved at vi gikk gjennom «backlog» i plenum. Utifra brukerhistoriene vi hadde, prøvde vi å estimere hvor lang tid hver brukerhistorie ville ta å fullføre. Vi valgte ut brukerhistorier basert på viktighet for videre utvikling Sprint 1 1 Som bruker skal man kunne opprette, endre og slette kunder 2 Som bruker skal man kunne opprette, endre og slette produkter 3 Som bruker skal man kunne se oversikt over kunder 4 Som bruker skal man kunne se oversikt over alle produkter 5 Bestem og test ut datamodellene 6 Test API med Angular Sprint 2 1 Som bruker skal man kunne opprette, endre og slette kampanjer 2 Som bruker skal man kunne logge inn 3 Som bruker skal man kunne opprette, endre og slette gårdeiere 4 Som bruker skal man kunne se oversikt over kampanjer i en kalender 6 Som bruker skal man kunne velge et produkt i en liste 7 Dialogbokser for endring av objekter 8 Bytte bootstrap-design 6

26 3.2.4 Sprint 3 1 Som bruker skal man kunne se oversikt over ledige reklameflater 2 Som bruker skal man kunne se en visuell framstilling av kampanjer 3 Det skal være mulig å sortere reklameflater på serier 4 Som superbruker skal man kunne opprette nye brukere og nullstille passord 5 Som bruker skal man kunne generere og eksportere rapport for gårdeier 6 Som bruker skal man kunne endre eget passord Sprint 4 1 Endring av informasjon skal foregå i modaler for alle typer 2 Som bruker skal man kunne generere monteringslister som kan lastes ned 4 Som bruker skal man kunne se oversikt over kampanjer pr uke 5 Det skal ikke være mulig å dobbeltbooke reklameflater 6 Forskjellige reklameflater skal organiseres med faner 7 Som bruker skal man kunne laste ned kartdata for en samling reklameflater 8 Det skal ikke være mulig å gjøre kall mot APIet uten gyldig brukertoken 9 Som bruker skal man kunne logge ut Sprint 5 1 Som bruker skal man ikke kunne skrive inn feil data i et tekstfelt 2 Det skal vises en «loadingscreen» når data laster inn 3 Som bruker skal man kunne laste ned kartdata for en samling reklameflater 4 Som bruker skal man kunne legge til reklameflater til gårdeier 5 Funksjonen «glemt passord» skal være tilgjengelig for bruker 6 Som bruker skal man kunne endre eksisterende kampanjer 7 Som bruker skal man få oversikt over data i et «dashboard» Vår erfaring med Scrum Scrum har fungert godt gjennom vår utviklingsprosess. Å jobbe med en backlog har gitt oss oversikt og å jobbe med sprinter har gitt oss gode rammer. Å kunne endre kravspesifikasjonen underveis har vært vært viktig. Prego Media har endret prioriteringer og funnet andre løsninger underveis for deler av funksjonaliteten og å kunne fjerne denne fra kravspesifikasjonen har spart oss fra mye unødvendig arbeid. Dette har også gjort at vi kan levere en løsning som dekker Prego Medias behov best mulig. Til tross for at vi føler at prosessen har fungert bra og at Scrum var det riktige valget ser vi i ettertid at det er en del ting vi kunne gjort annerledes. Vi kunne med fordel vært strengere med hvordan vi utførte sprintene. I noen sprinter ble vi for ivrige og tenkte vi kunne få gjennomført flere brukerhistorier enn det vi hadde kapasitet til. Dette førte til at noen av sprintene 7

27 gikk over lengre tid enn vi hadde planlagt. I disse tilfellene hadde det vært fordelaktig å ha et mer moderert forhold mellom mengden arbeid vi planla for en sprint og vår egen disiplin til å fullføre arbeid innen tiden. Vi har også forstått i ettertid at vi kunne med fordel utnyttet oss av flere aspekter ved Scrum, spesielt aspektet med hyppige møter med og levering til oppdragsgiver. Vi merket spesielt på møtene mot slutten at de ansatte i Prego Media ikke hadde fått nok tid til å uttrykke seg om hvilken tilleggsfunksjonalitet de kunne tenke seg. Det var ingen uenighet om hva hovedfunksjonaliteten skulle være, men vi mener at hyppige møter kunne hjulpet oss med å bedre forstå hvordan å utvikle applikasjonen for de ansattes arbeidsflyt. Vi tror også at hyppigere møter kunne hjulpet de ansatte med tankeprosessen om hva de faktisk ønsket seg av applikasjonen og hvordan de ville prioritere de forskjellige funksjonalitetene Trello Trello er et web-basert verktøy for prosjekthåndtering. Måten dette gjøres på er å lage et rom, hvor en kan lage flere lister. I disse listene kan man legge til kort som representerer forskjellige gjøremål, og knytte enkeltpersoner til dette kortet. Man kan også gruppere kortene ved hjelp av fargekoder, samt kommentere på dem underveis. Dette gjør det mulig å gruppere gjøremål, delegere ansvar, og holde oversikt over fremgangen i prosjektet i sanntid Arbeidsflyten med Trello Et rom ble opprettet for prosjektet, «Allora». Her opprettet vi følgende lister: Backlog - Liste over ønsket funksjonalitet, med forskjellige prioriteringsnivåer In Progress - Funksjonalitet som holder på å implementeres Bugs/Needs Fix - Bugs/feil i applikasjonen Egen liste for sprint 1 til og med 5 - Backlog tilhørende hver sprint, hentet fra hoved-backlog Sprint 1-5 DONE - Ferdigstilt funksjonalitet tilhørende hver sprint Hvert kort med funksjonalitet ble tilknyttet en eller flere gruppemedlemmer for å indikere hvem som har ansvar for å implementere den. Kortet ble deretter flyttet til «In Progress» når arbeidet med den tilhørende funksjonaliteten ble påbegynt, og flyttet til «Sprint X - DONE» ved ferdigstillelse. Om det skulle være nødvendig å utbedre funksjonaliteten, ble kortet flyttet tilbake til «In Progress». 8

28 Vår erfaring med Trello I tidligere samarbeidsprosjekter ved HiOA har gruppen erfart at delegering av ansvar og tildeling av arbeid kan vise seg å være mer utfordrende enn først tenkt. I enkelte tilfeller fører det til skjev arbeidsfordeling hvor enkelte tar på seg mye ansvar, og andre blir sittende igjen som tilnærmede gratispassasjerer og dermed med mindre læringsutbytte. Ved å ta for oss en smidig utviklingsmodell hvor konkrete delmål er en fundamental del av prosjektstyringen har vi i større grad eliminert denne utviklingen, og samtidig opprettholdt god oversikt over prosjektets gang underveis i prosessen. Trello har vist seg å være et veldig nyttig element i denne utviklingsmodellen, med et lettfattelig og anvendelig brukergrensesnitt som visualiserer arbeidsplanen og forenkler ansvarsdelegering på en god måte Git/GitHub Git er et versjonshåndteringssystem for utvikling av programvare, som forenkler prosessen med å dele tillegg og endringer i programkoden. Dette er et helt essensielt hjelpemiddel i prosjekter med flere utviklere, og mange filer. Git organiserer et prosjekt i et «repository» som hver av utviklerne involvert i prosjektet kan skrive eller lese fra. Fremgangsmåten for synkronisering av arbeid består av å legge til endrede filer i en «commit», som man igjen «pusher» til repositoriet. Når en skal hente ned nyeste versjon av koden, «puller» man fra Git. Om det er registrert flere endringer i en enkelt fil, vil Git gjøre sitt beste for å sammenflette disse automatisk, eller instruere brukeren om å gjøre det. På denne måten har alle involverte i prosjektet mulighet til å synkronisere kode mellom hverandre på en effektiv og sikker måte. Man har også tilgang til komplett historikk for prosjektet, ettersom alle commits er indeksert etter en unik SHA1-hash sum. Dette fungerer ikke bare som en måte å ivareta integriteten til dataene på (siden hver commit er å regne som kryptografisk sikker), men gir også muligheten til å reversere tilbake til en fungerende versjon dersom man havner i en situasjon hvor det er fordelaktig. Figur 1 er en skjermdump fra commit-loggen til vårt prosjekt på GitHub. GitHub er et web-basert hostingsystem for Git-prosjekter med diverse ekstrafunksjonalitet for å kartlegge bidrag fra hver enkelt deltager, opprette notiser på feil og mangler, samt oversikt over alle filene i prosjektet Google Drive Google drive er en skylagringstjeneste for filer og dokumenter med funksjonalitet for teksredigering i sanntid, det være seg tekstfiler eller regneark. 9

29 Figur 1: Utdrag av commit-log Facebook Vi har benyttet oss av chatfunksjonen på nettsamfunnet facebook for rask og uformell kommunikasjon. Her har vi avtalt møtetidspunkter, delt linker til nettsteder, og andre generelle kommunikasjonsbehov som oppsto underveis Webstorm Webstorm er et IDE (integrated development enviroment) skreddersydd for utvikling av webapplikasjoner. Webstorm er spesielt tilrettelagt for utvikling med JavaScript, og har innebygget støtte for versjonshåndtering med blant annet Git. I tillegg finnes innebygget funksjonalitet for plugins, slik at man for eksempel kan håndtere databaser direkte i utviklingsmiljøet. Webstorm er i utgangspunktet underlagt en årlig lisensavgift, men tilbyr gratislisenser for utdanningsformål ved bruk av en e-post tilhørende høyskole/universitet. 3.3 Fremdriftsplan Etter anbefaling fra veileder satte vi oss som mål å være ferdig med programmering av applikasjonen den 1. mai, for å frigjøre tid den siste måneden til å fullføre dokumentasjonen. Deretter organiserte vi gjøremålene i Scrumsprinter, med konkrete delmål for hver enkelt sprint. 3.4 Prioriteringsliste Kravspesifikasjonen som ble utformet i samråd med Prego, inneholder en liste over ønsket funksjonalitet, med forskjellige nivåer av prioritet. Detaljert beskrivelse av funksjoner og prioriteringsnivå er spesifisert i denne, og ligger vedlagt sluttrapporten. 10

30 3.5 Arbeidsforhold og kommunikasjon Vi har arbeidet med prosjektet på Høgskolen i Oslo og Akershus gjennom hele semesteret. Her har vi vært nøye med å booke grupperom, og møtt hverandre til satte tider slik at vi kom inn i en daglig rutine. Møte med veileder har også blitt gjennomført her. 3.6 Prosjektdagbok Prosjektdagboken i sin helhet ligger vedlagt i sluttdokumentasjonen. Vi har ført dagbok så ofte vi har kunnet. I de tilfeller det er store hull i prosjektdagboken er det fordi vi har hatt perioder hvor vi har fokusert på andre fag og har hatt pause fra hovedprosjektet. Prosjektdagboken har vi brukt til å dokumentere hva vi har jobbet med i løpet av prosjektperioden. Vi har også brukt den til å dokumentere utfordringer vi har støtt på. I de tilfellene vi har stått fast på et problem har det vært godt å kunne ha et sted å skrive om det, etter som at dette ofte gir et nytt perspektiv på problemet og kan være med å hjelpe oss nærmere en løsning. Møtereferater fra møter med oppdragsgiver og veileder er også blitt ført i prosjektdagboken. 3.7 Forhold til oppdragsgiver Gruppens forhold til oppdragsgiver har vært godt. Vi føler at kommunikasjonen har vært god og at vi har vært på samme plan igjennom hele prosjektperioden. Vi føler det har vært klart definerte forventninger til oss som gruppe og til produktet vi har levert. Hvis vi var nødt til å peke på noe mindre positivt hadde det vært at vi kunne inkludert oppdragsgiver mer i prosessen. Vi føler at vi med fordel gjerne kunne hatt hyppigere møter, et poeng vi beskriver i punkt Dette har ikke forhindret oss i å levere et produkt som lever opp til oppdragsgivers forventninger. Oppdragsgiver har uttrykt at de er fornøyd med resultatet og er takknemlig for arbeidet vi har lagt ned. Kommunikasjon fra oss har gått gjennom vår kontaktperson hos oppdragsgiver, Robin Bang. Gjennom han har vi organisert møter. Begge parter har vært fleksible på tidspunkter og vi har alltid fått til et møte hvis noen ønsket et. Tonen på møtene har vært god og uformell, samtidig som løsningsorientert. Gruppen har vært positive til de ansattes forslag og de ansatte har vært oppmerksom på gruppens begrensninger. På disse møtene har alle i gruppen fått god forståelse for utfordringene de ansatte opplever. Vår kontaktperson hos oppdragsgiver har delt Prego Medias data fra deres daværende løsning med oss så vi alltid har hatt korrekte data å jobbe med. 11

31 3.8 Veiledning fra HiOA Vårt forhold til veiledning fra HiOA har vært delt. Vi fikk tildelt en veileder høsten I januar sendte vi en mail til vår tildelte veileder for å avtale et møte. Verken denne eller noen av mailene vi sendte de første ukene ble besvart. Først tre uker ut i prosjektperioden fikk vi vite at vår tildelte veileder ikke skulle veilede noen grupper det semesteret. Vi følte oss skuffet over den dårlige kommunikasjonen fra HiOAs side og bekymret fordi vi ikke visste hvordan vi lå an. Heldigvis ble det ordnet fort og vi fikk tildelt en ny veileder, André Rognes. Forholdet mellom gruppen og André har vært bra. Vi har hatt møter hver uke hvor vi har fortalt hvordan vi ligger an. André har vært flink til å holde oss til forpliktelsene våre. Hver gang vi har startet en sprint har han skrevet ned oppgavene vi skal ha utført til neste uke og ved neste møte har han fulgt opp disse. 12

32 4 Utviklingsprosessen I denne delen vil vi beskrive hvordan det har vært å utvikle applikasjonen. I Punkt 4.1 til 4.4 forteller vi kronologisk om den første fasen av prosjektet. Dette er fasen hvor vi bygger grunnlaget for applikasjonen. Punkt 4.5 forteller om den etterfølgende fasen. Her forteller vi ikke kronologisk, men deler heller opp pr funksjonalitet. Hvert punkt forteller om en funksjonalitet eller teknologi vi har jobbet med, hvordan vi har brukt den og hvilken erfaringer vi har gjort oss. Punkt 4.6 forteller om andre erfaringer vi har gjort oss i løpet av prosessen. Punkt 4.7 forteller om utviklingsprosessen fra et sprintperspektiv. 4.1 Startfasen I perioden før vårt første møte med oppdragsgiver hadde vi vært i kontakt med vår kontaktperson hos oppdragsgiver om muligheten om å inngå et samarbeid. Vi var klar over hvilke problemer de ønsket en løsning på og vi gjorde oss opp noen tanker om hva som kunne være passende. Når det gjaldt størrelsen på problemene, var vi litt bekymret for at det ikke skulle være nok for en hovedoppgave med fire deltagere. I tillegg til å diskutere forskjellige løsninger, brukte vi de første dagene også på å lese oss opp på selskapet for å bli bedre kjente med produktene de solgte og for å være forberedt til møtet. Første møte med oppdragsgiver ble holdt Januar Det var et konstruktivt møte hvor vi fikk bedre forståelse for problemene selskapet opplevde og hvilken løsning som kom til å passe dem best. Vi forsto fort at vi var på samme plan som Prego, hva tanker om en løsning gjaldt. Før møtet hadde vi diskutert en web-løsning som beste alternativ. Prego var også innstilt på dette og presiserte at de ville at løsningen ikke bare skulle være tilgjengelig fra intern-nettet deres, men også kunne brukes fra for eksempel et hjemmenett. Vi ble enige om at en webapplikasjon, kjørende på en platformtjeneste var den beste løsningen. Videre diskuterte vi arbeidsoppgavene til de ansatte og identifiserte hvilke som var mest tidkrevende å utføre med deres eksisterende løsning. Vi ble enige om hvilke manuelle oppgaver som kunne automatiseres og kom fram til kombinasjoner av funksjonalitet som ville spare Prego mest mulig tid, samtidig at de var innenfor rekkevidde for oss å utføre. Sammen med de ansatte ble vi enige om en prioritert liste over funksjonaliteter. De ansatte hadde mange idéer om hvordan løsningen kunne gjøre hverdagen deres lettere og hvordan det kunne forbedre tilbudet til kundene deres. Den mest tidkrevende arbeidsoppgaven de ansatte utførte var å kartlegge hvor mange kampanjer som hadde blitt vist på hvor mange reklameflater, over hvor mange uker, på en gårdeiers eiendom og ut i fra det, kalkulere et fakturerbart beløp de kan sende ut til nevnte gårdeier. Det ble derfor høyest prioritert for oss å finne en måte å koble sammen reklameflater, gårdeiere 13

33 og kampanjer. Prego bruker et stort Excel-ark til å holde styr på når det skal være hvilket budskap på hvilken reklameflate og de bruker mye tid på å traversere dette excel-arket og oppdatere det. Excel-arket blir også sendt ut ukentlig til selskapet som monterer opp budskap på reklameflatene. Å kunne generere en slik monteringsliste fra dataene i webapplikasjonen ble også prioritert høyt. Ellers ønsket også Prego en løsning for å vise gruppe med, eller alle, reklameflater de tilbyr i et kart. Dette gjør det lettere for prego å visualisere for en kunde hvor stort omfang kampanjen deres vil få. Annen funksjonalitet som ble foreslått av de ansatte var: En liten CRM-løsning integrert i appen, funksjonalitet for å føre budsjetter basert på data fra appen og et notifikasjon-system. Disse kom lengre ned på prioriteringslisten og var ikke essensielle for å effektivisere arbeidsoppgavene. 4.2 Reasearch Etter første møte med oppdragsgiver brukte vi lang tid på å gjøre grundig reasearch på teknologier som kunne være aktuelle for oss å bruke. Vi hadde bestemt oss for å lage en webapplikasjon, så vi begynte å se på hvilken teknologistack 1 som kom til å passe oss best. Tre av medlemmene hadde erfaring med å lage en webapplikasjon fra et tidligere emne ved HiOA. I dette faget brukte de en løsning med Angular.js på klient-side og ASP.NET på serverside. Samtidig som vi ville finne den beste kombinasjonen for vårt prosjekt ville vi bruke så få teknologier vi hadde erfaring med som mulig, så vi valgte å lete etter alternativer som kunne passe oss. Vi var også interessert i å lære rammeverk som var moderne og som vi kan få bruk for etter utdanningen. To alternativer kom til oss tidlig. Vi hadde hørt om full-stack javascriptløsninger og Java Enterprise Edition, men visste ikke helt hvordan noen av de ville fungere. Etter å ha lest flere artikler om Java EE merket vi at det var noe som passet bedre for større systemer og at det ikke var helt riktig for oss. Vi leste også om stacker med javascript i alle ledd. Her er det så veldig mange varianter som fasiliterer for forskjellige behov og vi forsto vi måtte gjøre mye reasearch. En full javascript-stack består ofte av fire eller flere teknologier. Den har en database, en javascript-engine på server-side, et server-rammeverk og et front-end-rammeverk. En av oss hadde litt erfaring med node.js som javascript-engine og express.js som server-rammeverk fra tidligere, så vi hadde et utgangspunkt for server-siden, men vi ville helst forsikre oss om at vi valgte det som passet oss best før vi bestemte oss. Vi hadde hørt mye bra om MongoDB som database og mens vi lette etter alternativer forsto vi at det var det som passet best for oss. MongoDB har rykte på seg å være programmererens database, noe som passet oss bra. Vi 1 Teknologistack: En kombinasjon at teknologier som i en webapplikasjon bygger opp strukturen helt fra databasenivå på server-side, til nettleser på klient-side 14

34 så ikke for oss at vi kom til å trenge en relasjons-database og vi var ikke interessert i å bruke en SQL-database, da vi heller ville sette oss inn i mer samtidige teknologier. Vi fant mange frontend-rammeverk som kunne være aktuelle, men det var vanskelig å se hvilke som passet best for oss, ettersom at alle spesialiserer seg på forskjellige områder. Det finnes mange populære, for eksempel React.js, Angular.js, Ember.js, Backbone.js, Mercury.js osv. Vi visste at vi kom til å jobbe veldig mye frontend, så vi tok oss god tid til å bestemme oss for riktig rammeverk. Vi fant utallige artikler på området, så vi hadde mange anbefalinger å vurdere. Først ekskluderte vi Angular.js fordi store deler av gruppen hadde jobbet med det fra før. Vår første avgjørelse falt på React.js men etter samtale med ansvarlig for hovedprosjekter, Tor Krattebøl, gikk vi bort fra dette da han mente det ikke passet til vårt prosjekt. Han anbefalte oss å se til Angular.js 2.0 som da var kun i betaversjon. Vi hadde lest mye om hvor bra Angular.js 2.0 kom til å bli, men var litt bekymret for at det kun var i betaversjon. Vi forsto til slutt at Angular.js (versjon 1) kom til å være det beste for applikasjonen vår og bestemte oss derfor for å velge det, til tross for at store deler av gruppen hadde jobbet med det fra før. Den beste ressursen når man skal løse problemer man har med en teknologi er artikler på internett og internettforum som stackoverflow.com hvor folk gjerne opplever de samme problemene som deg og andre hjelper dem å løse de. Vi valgte å ikke bruke Angular.js 2.0 på grunn av mangelen på slik support på nettet. Angular.js (versjon 1) er det rammeverket som har mest support på nettet. Det hadde nok vært en spennende prosess å sette seg inn i et rammeverk i tidlig utviklingsfase, men det hadde nok vært lite hensiktsmessig med tanke på at vi også skulle skrive en bacheloroppgave. Dette viste seg å være en lur avgjørelse ettersom at vi i senere tid har snakket med andre hovedprosjektsgrupper som valgte å bruke Angular.js 2.0 og har opplevd store utfordringer på grunn av teknologiens unge alder og mangelen på dokumenterte og oppløste problemer på nettet. Vi endte opp med en full javascript-stack med MongoDB som database, Node.js som javascript-engine, Express.js som server-rammeverk og Angular.js som frontend-rammeverk. Dette kalles en MEAN-stack(MongoDB, Express, Angular.js, Node.js) og er en ganske populær kombinasjon med teknologier. Det finnes to implementasjoner(mean.js og mean.io) av MEANstacken som gjør mye for deg, men vi ville bygge det opp fra bunnen av, slik at vi kunne strukturere det slik vi selv ville. Vi brukte de neste dagene på å lære om de forskjellige teknologiene og hvilket oppsett som passet best for oss. Oppsettet vi landet på er vist i figur 2. Valg av teksteditor var også en prosess. Vi har hatt god erfaring med mange 15

35 Figur 2: Tidlig filstruktur forskjellige editorer. Alle på gruppen jobber til vanlig i Sublime Text, men vi følte vi trengte en editor som ga oss bedre oversikt over prosjektstrukturen og mer funksjonalitet for for eksempel databasehåndtering og versjonshåndteringsverktøy. To gruppemedlemmer hadde jobbet med IntelliJ sin standard IDE i et større prosjekt før og hadde bare gode erfaringer. Vi fant ut at Jet Brains, som lager IntelliJ, har en egen versjon for utvikling av webapplikasjoner, som heter Webstorm. Vi prøvde denne ut og det viste seg at den var akkurat det vi trengte. Neste steg var å få opp en fungerende stack. Alle jobbet først individuelt på hver sin stack med samme oppsett slik at alle ble fortrolig med hvordan de forskjellige delene kommuniserte med hverandre og hvordan strukturen var. Det var naturlig å først få opp Node.js og Express.js, slik at man kunne servere enkel html og få bekreftelse på at det funket. Videre koblet vi til databasen gjennom Mongoose 2 og gjorde enkel lagring og spørringer mot databasen. Å sette opp Angular krevde mye infrastruktur i frontend, i forhold til at så tidlig i prosjektet ville vi bare teste ut at det funket. Vi skrev først 2 Mongoose: Et interface for å kommunisere med MongoDB. Vi brukte det som en node.js-modul, da har man biblioteket installert på server-side og har tilgang på funksjonaliteten gjennom en variabel i javascript. 16

36 Figur 3: Tidlig databasemodellering 17

37 all Angular-kode i filen core.js, men fordelte senere ut controller-kode 3 til controller.js og http-kallene til service.js og koblet disse to sammen i core.js. Angular har mange funksjoner, men det var to som var spesielt viktig for oss: Toveis-databinding og ng-repeat. Toveis-databinding fungerer slik at man har variabler som er tilgjengelig både i javascript-filene og i html-filene. Når det blir gjort en en endring på den ene siden, skjer også endringen på den andre. For eksempel hvis et script endrer en variabel mens brukeren jobber med applikasjonen i nettleser vil variabelen, hvis den vises på den siden brukeren jobber på, bli oppdatert umiddelbart. Ng-repeat gir oss mulighet for å vise store bolker data i brukergrensesnittet på en strukturert måte. Hvis man for eksempel henter en stor samling med objekter fra databasen kan man lagre denne i en toveis-databindingvariabel og bruke ng-repeat for å skrive ut en liste med alle objektene. Dette sparer oss veldig mange kodelinjer i html-filene. I begynnelsen brukte vi disse funksjonene til å lagre data fra tekstfelt som objekter i databasen for så, med en gang objektet ble lagret i databasen, sende det tilbake til brukergrensesnittet og oppdatere en liste over alle lagrede objekter. Videre var det viktig for oss å definere databasemodeller. MongoDB er en no-sql-database 4 og det er noe vi ikke har jobbet med før. Når vi skulle begynne å modellere var det vanskelig å se for seg hvordan databasen skulle fungere uten relasjoner. Nå vi prøvde å modellere databasen, klarte vi ikke å holde oss helt unna klassisk relasjonsdatabase-modellering. Mongoose bruker et spesielt oppsett for å definere en type objekt. Dette oppsette kalles en «modell» og det er lett allerede her å bli forvirret av hvordan man skal modellere en database med modeller. Figur 3 viser et førsteutkast av hvordan vi visualiserte databasen i tidlig fase. Figur 3 viser at vi ikke forsto fullt ut fordelene ved en no-sql-database. Vi modellerte med nøkler, noe som ikke er nødvendig, men var noe vi gjorde for vår egen forståelses del. Vi ga også hver modell et egen «ID»-felt, noe som heller ikke er nødvendig ettersom at MongoDB gir hvert objekt en egen ID når det blir lagret. Denne ID-en er mye lettere å jobbe med enn en selvlaget ID fordi Mongoose har metoder som baserer seg på denne ID-en. Figur 3 inneholder også en tidlig versjon av attributten «Available»(senere «Bookable») i modellen «Board». Denne har vært subjekt for store endringer i løpet av prosjektet og vil bli diskutert i større detalj lengre ute i rapporten. Hvordan vi lagrer over hvilken periode en «Kampanje» skal gå er også her vist som dobbel-array, en løsning som vi endret senere. Modellen «Board» inneholder også en GPS-atributt som var ment til å lagre kartdata. Denne ble også fjernet i ettertid, ettersom at den ikke var nødvendig. Vi har også i ettertid endret alle modeller og at- 3 Kode som inneholder variabler og metoder som er tilgjengelig i html-en, i tillegg til koden som kaller på html-kallene i service.js 4 En no-sql-database er en database som ikke baserer seg på de samme prinsippene med relasjoner som en klassisk sql-database bruker 18