Chruntch! Chruntch!- et nettbasert turneringsvektøy

Chruntch!
Chruntch!- et
nettbasert
turneringsvektøy
Hovedprosjekt ved institutt for informasjonsteknologi
Høgskolen i Oslo og Akershus våren 2015
Prosjekt nummer 36
Morten Langeland Wedum
s182855
Dataingeniør
1
PROSJEKT NR.
36
Studieprogram: Informasjonsteknologi
Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo
Besøksadresse: Holbergs plass, Oslo
TILGJENGELIGHET
Offentlig
BACHELORPROSJEKT
Telefon: 22 45 32 00
Telefaks: 22 45 32 05
HOVEDPROSJEKTETS TITTEL
DATO
Cruntch! –et nettbasert turneringsverktøy
26.05.2015
ANTALL SIDER / BILAG 82
PROSJEKTDELTAKERE
INTERN VEILEDER
Morten Langeland Wedum (s182855), Dataingeniør, [email protected]
Thor E. Hasle
OPPDRAGSGIVER
KONTAKTPERSON
Kyrre Begnum
SAMMENDRAG
Nettbasert turneringsvektøy bygget med Node.js og Express.js
3 STIKKORD
Node.js
Express.js
2
MongoDB
Forord
Denne rapporten beskriver planlegging av utviklingsprosessen og gjennomføring av
prosjektet for oppgradering og modernisering av web-applikasjonen «Chruntch!».
Prosjektet er hovedprosjekt i bachelorstudium i Dataingeniør ved Høgskolen i Oslo og
Akershus (HIOA), våren 2015.
Oppdragsgiver for prosjektet er førsteamanuensis Kyrre Begnum, Institutt for Informasjonsteknologi ved HIOA. Han har utviklet en algoritme med en prototype for en webapplikasjon som kan kartlegge ulike interessenters preferanser for et antall alternativer. Prototypen er operativ, men det er ønskelig å øke funksjonaliteten. Oppgaven
går ut på å forbedre prototypen ved hjelp av moderne teknologi som Node.js og
MongoDB/CouchDB og andre Linux-baserte plattformer.
I denne oppgaven er det lagt mest vekt på Node.js delen som består av webserver,
applikasjonslag/businesslag og websider.
Oppgaven skulle i utgangspunktet løses i en gruppe på fire. Da dette ikke lot seg
gjennomføre innen tidsrammen for oppgaven, leverer studenten derfor en egen oppgave med hovedvekt på brukergrensesnittet og presentasjon av statistikk.
Rapporten har fire hoveddeler:

Analyse

Teori, teknologi og metode

Implementering

Evaluering av arbeidet og forslag til videre arbeid
3
Jeg takker min veileder Thor E. Hasle for nyttige innspill, oppmuntring og god hjelp.
Jeg vil også takke oppdragsgiver Kyrre Begnum for et morsomt og lærerikt prosjekt
og en muliggjørende veiledning.
Da det ble klart at dette måtte bli en individuell oppgave, arrangerte jeg en idédugnad
i nettverket mitt for å få innspill til det videre arbeid. Jeg vil takke Ole Langeland, Petter Wedum og Astrid Langeland for inspirasjon og at de delte av sin erfaring fra hhv.
FMC Technology, Google og Innovasjon Norge.
4
Innhold
Forord ............................................................................................................................................................... 3
Innhold .............................................................................................................................................................5
1. Innledning.................................................................................................................................................... 9
1.1 Mål .............................................................................................................................................................. 10
1.1.1 Formål ...................................................................................................................................................... 10
1.1.2 Resultatmål ............................................................................................................................................. 10
1.1.3 Læringsmål ............................................................................................................................................. 10
1.2 Hovedfunksjoner for systemet ................................................................................................................ 12
2.Teori ............................................................................................................................................................. 12
2.1 Turneringer ............................................................................................................................................... 12
2.1.1 Knock out prinsippet ............................................................................................................................. 13
2.1.3 Single-eliminasjons turnering .............................................................................................................. 13
2.1.3 Dobbel-eliminasjons turnering ............................................................................................................ 14
2.1.4 All-play-all ............................................................................................................................................. 15
2.2 Teknologi.................................................................................................................................................. 15
2.2.1 Linux operativsystem ............................................................................................................................ 16
2.2.2 Apache Webserver ................................................................................................................................ 16
2.2.3 HTML, HTTP, CSS og nettlesere ......................................................................................................... 17
2.2.4 Programmeringsspråk .......................................................................................................................... 18
2.2.4.1 PHP ...................................................................................................................................................... 18
2.2.4.2 JavaScript ............................................................................................................................................ 18
2.2.5 Twitter Bootstrap .................................................................................................................................. 18
2.2.6 Rammeverk for webapplikasjonen ..................................................................................................... 19
2.2.6.1 Node.js og Express.js .......................................................................................................................... 19
2.2.7 API ......................................................................................................................................................... 20
2.2.8 Databaser ............................................................................................................................................. 20
2.2.8.1 Relasjonsdatabaser ............................................................................................................................ 20
2.2.8.2 Dokumentdatabaser (NoSQL-databaser) ....................................................................................... 21
5
2.2.8.3 MongoDB ........................................................................................................................................... 23
2.2.8.4 CouchDB ............................................................................................................................................ 23
2.2.8.5 Relasjonsdatabaser vs. dokumentdatabaser .................................................................................. 24
2.2.8.6 MongoDB vs CouchDB .................................................................................................................... 24
2.2.9 MVC ...................................................................................................................................................... 24
3.Metoder ....................................................................................................................................................... 25
3.1 Prosjektstyring .......................................................................................................................................... 25
3.1.1 Samarbeidskontrakt ............................................................................................................................... 25
3.1.2 Prosjektdagbok ...................................................................................................................................... 25
3.1.3 Arbeidsplan ........................................................................................................................................... 26
3.1.4 Trello ..................................................................................................................................................... 26
3.1.5 Risikomatrise ........................................................................................................................................ 28
3.1.6 Fossefall versus Smidig utvikling ........................................................................................................ 28
3.1.7 Git .......................................................................................................................................................... 29
3.1.8 Ide dugnad .............................................................................................................................................30
3.2 Analysemetoder .......................................................................................................................................30
3.2.1 Business case ..........................................................................................................................................30
3.2.2 Hvordan intervjue kunder/brukere? .................................................................................................. 31
3.2.3 User story ............................................................................................................................................... 32
3.2.4 Use case ................................................................................................................................................. 32
3.2.5 ER- modellering .................................................................................................................................... 32
3.3 Verktøy ..................................................................................................................................................... 33
3.4 Kommunikasjon ......................................................................................................................................34
3.4.1 Prosjektdokumentasjon ........................................................................................................................34
4. Analyse .......................................................................................................................................................34
4.1 Business case ............................................................................................................................................ 35
4.1.1 Mediamarkedet ...................................................................................................................................... 35
4.1.2 Forskning .............................................................................................................................................. 39
4.1.3 Kundebestemt produktutvikling ......................................................................................................... 41
4.1.4 Mentometerknapper ............................................................................................................................ 42
4.1.5 Beslutningsstøtte ...................................................................................................................................43
4.2 Analyse av business case for media markedet ......................................................................................43
6
4.3 User story og use case ............................................................................................................................ 44
4.3.1 Verktøy for vennegjenger .................................................................................................................... 45
4.3.2 Verktøy for Melodi Grand Prix ........................................................................................................... 45
4.4 Utforming av funksjons spesifikasjon .................................................................................................. 47
4.4.1 Utforming av kravspesifikasjon .......................................................................................................... 47
4.4.1.1 Universell utforming ......................................................................................................................... 47
4.4.1.2 Kravspesifikasjon .............................................................................................................................. 48
5. Implementering ........................................................................................................................................ 50
5.1 Database .................................................................................................................................................... 51
5.2 Filstruktur ................................................................................................................................................ 51
5.3 Utforming ................................................................................................................................................. 51
5.4 Design ....................................................................................................................................................... 51
5.5 Testing ...................................................................................................................................................... 52
5.6 Skisser ....................................................................................................................................................... 52
5.7 Skjermbilder ............................................................................................................................................. 55
6. Evaluering av arbeidet .............................................................................................................................. 61
6.1 Vurdering av målrealisering.................................................................................................................... 61
6.1.1 Formål og resultatmål ........................................................................................................................... 61
6.1.2 Læringsmål ............................................................................................................................................ 61
6.2 Evaluering av og læring om samarbeid ................................................................................................ 62
6.2.1 Samarbeid i gruppe ............................................................................................................................63
6.2.2 Samarbeid med oppdragsgiver og veileder på HIOA .......................................................................63
6.2.3 Ide dugnad med eksterne ................................................................................................................... 64
6.3 Vurdering av produktutviklings prosessen .......................................................................................... 64
6.3.1 Designprosessen ................................................................................................................................... 64
6.3.2 Turneringsoppsettet ............................................................................................................................ 65
7. Konklusjon og videre arbeid ................................................................................................................... 66
Kilder ............................................................................................................................................................. 68
Vedlegg A. Arbeidsplan ................................................................................................................................ 71
Vedlegg B. Risikomatrise .............................................................................................................................. 75
Vedlegg C. Prosjektskisse .............................................................................................................................77
Vedlegg D. Forprosjekt rapport .................................................................................................................. 79
7
1. Innledning
Cruntch! er et utviklingsprosjekt med mål om å lage et web-basert verktøy som skal
hjelpe grupper med brukere med å velge ut hva de synes er viktigst av et utvalg alternativer. Denne kartleggingen av preferanser utføres ved at de aktuelle alternativene
registreres på en nettside med en påfølgende avstemmingsprosess. Deltakerene i
rangeringen, enkeltpersoner eller grupper av personer, prioriterer hvilket av de to alternativene, som de får presentert per omgang, til å være mest viktig eller riktig for
den enkelte. Prioritering av alternativer gjentas etter et cup system helt til det er ett alternativ som står igjen som en vinner eller klart foretrukket alternativ.
Oppdragsgiver Kyrre Begnum, Institutt for Informasjonsteknologi, HIOA har utviklet
selve algoritmen for gjennomføringen av slike spørrerunder. En prototype av Cruntch!
er ferdig og demonstrerer funksjonalitet. I dette prosjektet skal prototypen av
Cruntch!, som er skrevet i PHP, videreutvikles. Målet er å bedre brukergrensesnittet
og øke skalerbarheten opp til flere tusen brukere. Videreutviklingen ønskes gjennomført på Node.js, MongoDB/CouchDB og andre moderne Linux-baserte plattformer.
I denne oppgaven er det fokusert på å utvikle front-end og spesielt er det lagt vekt på
å arbeide med hvordan turneringsresultater kan presenteres og et utkast til registrering og stemming er utviklet. Det er utarbeidet design kriterier for både småskala og
storskala turneringer, men kriteriene er implementert kun for småskala turneringer.
Det er implementert funksjonelle nettsider som kjører mot en mock-up database.
Ved oppstart av prosjektet var det vanskelig å forstå behovet for enten individuelt eller
kollektivt å sammenligne og rangere ulike alternativer. Å forstå den praktiske nytten
av en slik algoritme var nødvendig for å kunne designe en god, videreutviklet prototype. Det er derfor laget et business case i rapporten. Dette avsnittet har blitt mer omfattende enn planlagt fordi avstemminger brukes i mye større grad enn antatt i utgangspunktet. Det ble derfor spennende å få innblikk i de kommersielle mulighetene
8
for prosjektet og knytte dette opp mot undervisningen i entreprenørskap og innovasjon. Det var også behov for å forstå fundamentet for algoritmen som beskriver en
turnering. Ulike turnerings former og deres funksjon er derfor beskrevet i kapittelet om
teori.
Rapporten forutsetter noe grunnleggende datakunnskaper av leseren.
1.1 Mål
1.1.1 Formål
Formålet med videreutvikling av prototypen Cruntch! er å integrere algoritmen i en
moderne og skalerbar web-applikasjon med sikte på en kommersialisering av konseptet.
1.1.2 Resultatmål
Oppdragsgiver ønsker en oppgradert versjon av sin første prototype av en algoritme
for rangering av alternativer. Den neste versjonen av prototypen Cruntch! skal kunne
representere en fullstendig web applikasjon med en rask og brukervennlig nettside og
en skalerbar database som kan håndtere mange tusen stemmegivere.
1.1.3 Læringsmål
Formålet med bachelor oppgaven er å simulere oppgaver eller prosjekter fra arbeidslivet. Det betyr at man må tilegne seg kunnskap om ny og moderne teknologi og lære
seg å implementere dette nye sammen med det andre man har lært ved Høgskolen
de tre siste årene. Helt konkret vil dette bl.a. vises ved at jeg har lært å operere innenfor rammeverket Node.js og å bruke programmeringsspråket JavaScript som det
ikke har vært undervisning i.
9
Det har vært et mål å bruke kunnskapen fra studiet som også har omfattet entreprenørskap og innovativ virksomhet. Det er derfor utviklet et business case for Cruntch!
for å kunne vise noen forretningsmessige muligheter og for å bruke denne kunnskapen inn i design prosessen.
Et annet relevant punkt er planlegging. Oppgaven er veldig omfattende og det vil derfor være viktig å prøve og planlegge så godt man kan slik at prosjektet ikke stopper
opp eller at man plutselig finner ut at det er altfor lite tid igjen. Dette er en læringsprosess og sannsynligvis vil prosjektet ikke gå helt som planlagt, men dette er som oftest
også tilfelle i arbeidslivet. Det er et læringsmål å kunne forholde seg til uforutsette
hindringer og å kunne finne relevante løsninger.
Omfattende prosjekter krever samarbeid mellom flere. Uansett om oppgaven løses i
arbeidslivet eller i en studiesituasjon må fordeling av arbeidsoppgaver, fordeling av
ansvarsområder (gruppeleder, referent etc.), koordinering og fremdrift være avklart og
fungere godt i gruppen. Det er et læringsmål å få innsikt i gruppedynamikk og egen
og andres rolle i gruppeprosesser.
Et så omfattende prosjekt vil også kreve god dokumentasjon. Man må kunne gjøre
rede for hva som har blitt gjort, hvorfor det har blitt gjort og hvordan det har blitt gjort
for ettertiden slik at resultatene kan etterprøves og videreutvikles. Det er ett av læringsmålene å lage en god rapport.
10
1.2 Hovedfunksjoner for systemet
Følgende hovedspesifikasjoner er utgangspunkt for oppgaven:

Turneringens administrator skal kunne sette opp sin egen turnering

Turneringen skal kunne gjennomføres ved hjelp av email og mobiltelefon

Deltagerene skal kunne avgi stemmer

Et alternativ/en vinner skal bli kåret

Statistikk skal vises for alle turneringer

Siden skal være universelt utformet

Systemet skal være skalerbart
2.Teori
Fundamentet for Cruntch! er en algoritme som beskriver et turneringsoppsett. For å få
innsikt i grunnlaget for algoritmen er det i det følgende beskrevet prinsippene for ulike
turneringer.
2.1 Turneringer
Turneringer er en serie av konkurranser med et antall deltakere som konkurrerer mot
hverandre. Konkurrenten som fullfører siste runde med best resultat, kåres som vinner. En enkelt kamp i turneringen kalles også for en match, tie eller et heat. Turneringen kan bestå av mange kamper mellom deltakerne i ulike oppsett som en cup eller en serie.
Turneringer arrangeres vanligst innenfor lagidretter som fotball, men også innenfor
individuelle idrettsgrener som tennis og sjakk. Pokerturneringer og bridgeturneringer
er andre godt kjente konkurranser innenfor spill. Målet med turneringene er å måle
styrker, kåre vinnere og rangere deltakerne etter ferdigheter.
11
Utgangspunktet for en turnering er å klargjøre hva slags turneringsform som gjennomføres, hvilke regler og rammer som gjelder. Hvem kan delta, hvor lenge skal
kampene vare, hva som skjer hvis noen får like mange poeng, unntaksregler etc.. En
oversikt over alle kampene og hvilke lag som spiller mot hvem i hver runde er grunnlaget for gjennomføringen av en turnering. Dette kalles et kampoppsett, en turneringstabell eller en turneringsmatrise.
Det arrangeres ulike varianter av turneringer basert på spesifikke filosofier. I det videre er prinsippene for de som er relevante for å forstå den grunnleggende algoritmen i dette prosjektet beskrevet:
2.1.1 Knock out prinsippet
En knockout turnering er delt inn i suksessive runder hvor hver deltaker spiller i minst
en kamp per runde. Den deltakeren som vinner kampen, går videre til neste runde.
Antall deltakere minsker for hver runde fordi taperne går ut av turneringen. Vinneren i
den siste runden, også kalt finalen vinner hele turneringen.
2.1.3 Single-eliminasjons turnering
En single-elimination turnering, som også kalles en knockout eller sudden death turnering, er en type elimineringsturnering. Her går bare vinneren i en konkurranse mellom to deltagere videre. Alle andre deltagere er eliminert fra turneringen. Dette sikrer
at en vinner kan kåres med et minimum av en mot en kamper.
Det er ikke alltid at taperne ikke får fortsette i turneringen. I noen turneringer, som kalles klassifiserings konkurranser, konkurerer taperne om rangeringer av tredje-, fjerde
plass osv. i semifinaler, kvartfinaler opp til åttendedels finaler. Ved enda større antall
deltagere arrangeres det før konkurranser eller kamper for å kunne såkalt “seede”
konkurrentene. Seeding brukes for at du skal komme i rett startpulje, sammen med
de på som er på samme prestasjonsnivå som deg. Dette skaper bedre flyt og en
bedre opplevelse for alle deltagere, uansett nivå i turneringen.
12
Turnerings matrisen for singel-eliminasjon er vist i figur 1:
Figur 1: Turneringsmatrise for singel-eliminasjons oppsett
2.1.3 Dobbel-eliminasjons turnering
Algoritmen som ligger til grunn for den utviklede Cruntch! prototypen er basert på
knockout turneringsprinsippet kalt double-elimination. Denne turneringen består av to
turneringer, en overordnet (winners bracket) og en underordnet (losers bracket). Alle
spillerne starter i winners bracket, de som taper her havner i loser bracket hvor de får
en sjanse til, taper de her er de eliminert fra hele turneringen. Etter første iterasjon vil
loser bracket kampene bestå av en som har gått videre fra losers bracket og en som
har tapt i winners bracket. Etter at det har blitt kåret en vinner av winners- og losersbracket vil de to møtes i en siste kamp for å bestemme hvem som vinner hele turneringen.
Dobbel eliminasjons turneringer er godt egnet for viktige mesterskap hvor resultatene
må være mindre tilfeldige og mer troverdige enn de av en enkelt knock-out turnering
hvor rene uhell kan være det utslagsgivende. Den grunnleggende ideen i dobbel-elimineringen er at enhver spiller som taper to kamper, ikke fortjener å bli mester. Dette
er ansett for å være det klareste mesterskaps kriteriet som er tilgjengelig.
13
Turneringsmatrisen for dobbel-eliminasjon er vist i figur 2:
Figur 2: Turneringsmatrise for en dobbel-eliminasjons turnering.
2.1.4 All-play-all
For helhetens skyld nevnes også en annen svært vanlig turneringsform; en round-robin turnering eller all-play-all turnering. Dette er et turnerings oppsett hvor hver deltager møter alle de andre konkurrentene i en serie. Her kåres vinneren basert på de poengene de har vunnet i hver kamp. I for eksempel fotball får vinneren i en kamp 3 poeng og taperen 0 poeng, ved uavgjort får hvert lag 1 poeng. Poengene fra hver kamp
summeres gjennom hele serien. Dette er prinsipielt forskjellig fra eliminasjonsturneringene.
2.2 Teknologi
Oppdragsgiver har allerede utviklet en prototype skrevet i programmeringsspråket
PHP. Han ønsker seg imidlertid videre utvikling på Node.js, MongoDB eller CouchDB
og andre moderne, Linux-baserte plattformer.
14
Cruntch! som web-applikasjon består av front-end, back-end og database. Front end
presenterer data for bruker og back end er en mediator som tilgjengeliggjør dataene
for presentasjon og også overfører data fra front-end til databasen for lagring.
For å kunne kjøre en web-applikasjon er det nødvendig med en web-server. Enkelt
sagt er en web-server en PC som svarer på HTTP forespørsler. Serveren kjører på et
operativsystem, en web-server programvare, en database og et programmeringsspråk for å prosessere dynamiske forespørsler. I 2013 var det vanlig med en LAMP
Software Stack. LAMP referer til kombinasjonen av Linux operativ system, Apache
web-server, MySQL-database, og PHP som programmeringsspråk.
I det følgende er de viktigste teknologiene som ble brukt for å videreutvikle Cruntch!
kort beskrevet. I noen tilfeller beskrives også teknologi som er vurdert anvendt, spesielt MySQL-database og PHP som i denne oppgaven erstattes med den moderne programstacken for web-applikasjoner MEAN(MongoDB, Express.js, Angular.js og
Node.js) og JavaScript som blir brukt som programmeringsspråk i oppgaven.
2.2.1 Linux operativsystem
Operativsystemet er et bindeledd mellom maskinvaren og applikasjonene i systemet.
Linux er et operativsystem i åpen kildekode. Det blir brukt i alt fra PCer til superdatamaskiner og mobiltelefoner. Mange analytikere fremhever leverandøruavhengighet,
lave realiseringskostnader, trygghet, tilgjengelighet og stabilitet som dette operativsystemets styrker i forhold til de proprietære systemene fra f.eks. Windows og UNIX.
2.2.2 Apache Webserver
Apache HTTP Server er verdens mest brukte web-server programvare og hadde i
2013 en markedsandel på 54,2%. Apache har spilt en nøkkelrolle for utviklingen av
internett. Apache er en gratis og åpen kilde-kode programvare og det er et stort offentlig bibliotek tilgjengelig for Apache add-ons.
15
2.2.3 HTML, HTTP, CSS og nettlesere
HTML (HyperText Markup Language, hypertekstmarkeringsspråk) er fundamentet for
å utvikle en web applikasjon som Cruntch!. HTML er et markeringsspråk for formatering av nettsider og innhold som vises i nettlesere. HTML bruker tagger til å formatere
innholdet. Taggene gir det innholdet som er inne i taggen forskjellige egenskaper avhengig av hvilken tag som blir brukt f.eks. gir taggen <h1>(som er en tag for overskrifter) innholdet større og fet skrift. En annen viktig del er hypertekst som gjør det enkelt
å referere til noe på samme dokument eller til et annet dokument.
HTML ble opprinnelig definert i 1989 av Tim Berners-Lee og Robert Caillau. Protokollen er videreutviklet og er nå en internasjonal standard (ISO/IEC15445:2000.).
HTMLs grammatiske struktur er en internasjonal standard for tekstformatering (ISO
8879).
CSS (Cascading Style Sheets, gjennomgående stilark) er et språk som brukes til å
definere utseende på filer skrevet i HTML eller XML. Dette gjøres ved at man gir ulike
attributter til de forskjellige HTML-taggene. Man kan f.eks. sette et bakgrunnsbilde til
body-taggen eller endre skriftfargen til <h1>. Endringer kan gjøres på HTML-taggene
eller så kan man definere egne områder med <div id> eller <div class>. Stilarket lages gjerne i et eget dokument som ender på .css og linkes til med <script>-taggen.
En CSS fil kan brukes av et ubegrenset antall dokumenter.
HTTP (Hypertext Transfer Protocol, hypertekstoverføringsprotokoll), er en protokoll
for utveksling av informasjon over nettet. HTTP håndterer forespørsler og respons for
klienter og tjenere der klienter er nettlesere og tjenere er servere. HTTP bruker primært TCP til overføring av pakker, men kan også bruke UDP.
16
Nettlesere (web browser) er programmer som oversetter web-dokumenter, som regel
HTML, til et mer leselig format. Nettlesere har tre hovedfunksjoner: hente data, vise
data og interaksjon som f.eks. linker og knapper. De mest populære nettleserne er
Explorer, Chrome, Firefox og Opera. Nettleseren går igjennom HTML-dokumentet og
finner hva som skal vises og hvor på siden det skal være.
2.2.4 Programmeringsspråk
I det følgende beskrives PHP, det opprinnelige programmeringsspråket for Cruntch!
og JavaScript som denne nye versjonen av Cruntch! er skrevet i.
2.2.4.1 PHP
PHP er verdens mest populære språk når det kommer til utvikling av web-applikasjoner og brukes av flere av de største nettstedene i verden. En grunn til at PHP er så
populært er at det er et robust språk som er enkelt å lære og kan kjøre med noen feil.
PHP støtter også de fleste teknologier innenfor databaser, datautveksling og tekstbehandling.
2.2.4.2 JavaScript
JavaScript er et skriptspråk som er best kjent for å tilføre dynamiske elementer til
nettsider. Sammen med øvrig innhold på nettsiden (hovedsakelig HTML) sendes det
kode innenfor et <script>-tagpar, som kjøres lokalt i nettleseren, automatisk eller som
reaksjon på brukervalg på siden. Vanlige bruksområder er å bytte ut, fjerne eller
legge inn tekst avhengig av hvor på siden du klikker, å skifte fokus i et skjema, og å
åpne pop-up-vinduer.
2.2.5 Twitter Bootstrap
Twitter Bootstrap er en samling verktøy for utvikling av web-sider og inneholder en
rekke maler for HTML og CSS som knapper, forms og navigasjon. Bootstrap skiller
seg fra CSS ved at man skriver koden rett inn i HTML-dokumentet. Bootstrap benytter
17
seg av et rutenett som gjør det enkelt å dele opp skjermen. Man kan ha 12 ruter på
samme rad og en rad defineres av <div class = “row”> og ruter lages ved <div class =
“spanx”> hvor x er et tall mellom 1-12, 1 gir de minste rutene som er 1/12 av bredden
til skjermen mens 12 gir den største som dekker hele bredden av skjermen.
2.2.6 Rammeverk for webapplikasjonen
Ønskene fra oppdragsgiver var at applikasjonen Cruntch! skulle være rask og at den
skulle kunne håndtere mange samtidige brukere. Etter forslag fra oppdragsgiver falt
valget på Express.js som er det mest populære Node.js rammeverket.
2.2.6.1 Node.js og Express.js
Node.js er et open source, multi-platform rammeverk for webutvikling. Node.js er et
relativt nytt rammeverk og ble utviklet i 2009 for Linux og i 2011 for Windows. Node.js
brukes i hovedsak til å lage nettløsninger som webservere. Node ligner litt på PHP,
men den største forskjellen er at PHP er et blocking språk, som betyr at systemet må
vente på at en oppgave er ferdig før det kan begynne på en ny, mens Node kan
håndtere flere oppgaver samtidig.
Node er bygget på Googles V8 JavaScript Engine som er ekstremt raskt siden det
oversetter JavaScript til maskinkode og optimaliserer denne før kjøring.
Siden Node bare bruker en tråd og gjør non-blocking I/O calls kan det håndtere flere
tusen samtidige brukere uten å bruke tid på bytte context. Node har også en innebygget pakkehåndterer NPM (node package manager) som gjør det enkelt å laste ned
brukergenererte pakker og programmer.
Express.js er et raskt og minimalistisk web-rammeverk for Node.js som gjør routing
og serving enkelt.
18
2.2.7 API
API (Application Programming Interface, applikasjonsprogrammeringsgrensesnitt) er
et programeringsgrensesnitt som gjør det mulig for flere programmer å utveksle informasjon med hverandre. En API er en definisjon på hvordan andre programmer skal
legge til sin funksjonalitet eller tjenester, slik at personer som ikke har vært i kontakt
med programvaren lett kan sette seg inn i hvordan man skal koble programmene
sammen. Et eksempel på dette er hvordan API-en til Linux eller Microsoft Windows
gjør det mulig å lage programmer som passer til operativsystemet og utnytter dets
egenskaper. Det er svært vanlig for store programvarehus å publisere API-er til sine
programsystemer, slik at uavhengige aktører kan bygge videre.
2.2.8 Databaser
Oppdragsgiver hadde ikke noen spesifikke krav til hva slags databasesystemer som
skulle benyttes, men hadde et ønske om en NoSQL-database og foreslo MongoDB
og CouchDB som potensielle kandidater.
Under følger en kort beskrivelse og sammenligning av de to vanligste databasetypene; relasjonsdatabaser og dokumentdatabaser herunder MongoDB og CouchDB:
2.2.8.1 Relasjonsdatabaser
En relasjonsdatabase er en database hvor dataene er organisert i tabeller, hvor hver
rad representer en entitet som for eksempel en person eller bedrift, og hver kolonne
representerer en datatype som for eksempel telefonnummer eller adresse. Alle data
blir derfor lagret etter en bestemt struktur og etter et predefinert skjema. Relasjonene
mellom tabellene er angitt med et nøkkel datafelt i minst to tabeller. Når man kobler
flere tabeller sammen ved hjelp av primær- og fremmednøkler, knyttes relasjonene.
For å lese og manipulere dataene i relasjonsdatabaser, bruker man det standardiserte språket SQL. SQL er utviklet for arbeid med databaser og brukes til å hente ut
relevante data fra tabellene ved å konstruere en SQL setning.
19
Fordeler ved relasjonsdatabaser:

Krever mindre lagringsplass enn alternativene siden dataene bare lagres en
gang på ett sted.

Oppdatering av data er raskt, siden det bare er å endre data i en tabell.

SQL er et standadrisert språk og kan brukes mot en rekke systemer uten store
endringer i syntaksen.

For databaser der det skal gjøres mange transaksjoner er det en fordel med
tabeller og relasjoner

Relasjonsdatabaser følger ACID (Atomicity, Consistency, Isolation, Durability)
prinsippene.
Ulemper ved relasjonsdatabaser:

Relasjonsdatabaser skalerer best vertikalt, noe som betyr at hvis man trenger
mer fart eller lagringsplass er det best å investere i den enheten som databasen kjører på som for eksempel å legge til en ny disk eller en raskere prosessor. Å distribuere databasen over flere enheter vil nødvendigvis ikke øke ytelsen på grunn av de store mengdene med data som må gå over nettverket.

Endringer i tabellstrukturen kan være veldig krevende, spesielt hvis man har
en stor database med mange relasjoner, da alle relasjonene må oppdateres
manuelt og det kan være vanskelig å holde oversikt over hvem som hører
sammen med hvem.
2.2.8.2 Dokumentdatabaser (NoSQL-databaser)
En samlebetegnelse på databaser som ikke er relasjonsdatabaser blir ofte kalt
NoSQL-databaser. Dette er databaser som ikke organiserer data etter tabeller og relasjoner. NoSQL er en forkortelse for “Not only SQL”.
Dette er et nyere alternativ til relasjonsdatabaser, typisk brukt i større web-løsninger
med behov for å lagre data som er problematisk å lagre i tabellform, for eksempel dokumentsamlinger brukt i søkemotorer og nettverk lagret i sosiale medier. Data lagres i
et friere format, ofte distribuert på flere tjenermaskiner, og er ikke basert kun på SQL
20
som spørrespråk. Slike systemer er gjerne optimalisert for å besvare mange spørringer som i hovedsak leses fra databasen, men har som regel ikke full støtte for
transaksjoner. Et fellestrekk ved NoSQL databaser er at de er såkalt skjemaløse, de
behøver ikke følge en fast mal for datastrukturen.
Det er flere grupper av NoSQL-databaser som key-value databaser for enkle datatyper, graf databaser basert på graf-teori og dokumentdatabaser som MongoDB og
CouchDB. I dokumentdatabasene kan nøkkel-verdien være en kompleks datastruktur
kalt dokument.
Fordeler ved dokumentdatabaser:

Skalering: NoSQL databaser kan skaleres horisontalt. For å øke ytelse og kapasitet kan man enklere enn med relasjonsdatabaser fordele databasen over
flere servere og over flere datasentre.

Pris: For løsninger som kjører i nettskyen er NoSQL databaser som oftest billigere.

Skjemaløs:Ustrukturert datastruktur gjør at endringer i datastrukturen underveis i utviklingen går raskere enn ved relasjonsdatabaser.

Bruker ofte et datalagringsformat som er helt eller svært likt et vanlig programmeringsspråk. For eksempel bruker dokumentdatabasen MongoDB en binær
form av JSON (BSON) som lagringsformat.

Fart: Hvis data for det meste skal legges til eller leses vil en NoSQL database
ofte være raskere enn en relasjonsdatabase.
Ulemper ved dokumentdatabaser:

NoSQL databaser bruker ikke et standard spørrespråk som SQL. Hva slags
språk hvert databasesystem bruker kan variere. Hvis man skal bruke et nytt
databasespråk, må man derfor beregne tid til å lære seg API språket.

Ikke alle NoSQL databaser følger ACID prinsippene for transaksjoner, man
kan derfor som utvikler eller som driftsansvarlig bli overrasket om man tar
dette for gitt.

Kapasitet vs Ytelse: Ved bruk av NoSQL må man ofte ta valget om man skal
normalisere:
21
o
Man kan normalisere for å spare plass, men får da dårligere ytelse fordi
NoSQL databaser trenger å utføre flere spørringer enn ved en SQLspørring som bruker JOIN.
o
Ved å droppe normalisering vil man få raskere spørringer, men det blir
lagret mer redundant informasjon.

Fart: Fordi NoSQL databaser vanligvis ikke er normalisert vil ofte spørringer
som går på oppdatering være tregere enn ved relasjonsdatabaser.

Kompetanse: For videre drift og utvikling vil det være lettere å skaffe kompetanse på mer utbredte relasjonsdatabaser enn å finne kompetanse på de
mindre utbredte NoSQL-databasene.
2.2.8.3 MongoDB
MongoDB er en dokument-orientert database, og en NoSQL database. MongoDB
bruker JSON lignende dokumenter med dynamiske skjemaer i formatet BSON. Dette
gjør integrasjonen av data i visse typer applikasjoner enklere og raskere. MongoDB
kan lagre ustrukturerte data og endringer i databasestrukturen krever mindre innsats.
MongoDB er akseptert som back-end programvare blant flere store web-brukere som
eBay, Viacom og New York Times. MongoDB er det mest populærer NoSQLdatabase
systemet som muliggjør applikasjoner som tidligere ikke var mulig med relasjonsdatabaser og til en vesentlig lavere pris.
MongoDB ble lansert som en gratis og åpen kildekode programvare i 2009.
2.2.8.4 CouchDB
Apache CouchDB eller CouchDB er en åpen kildekode database tilpasset web-applikasjoner. Det er en dokumentorientert NoSQL database som bruker JSON for å
lagre data, JavaScript som query språk og MapReduce og HTTP som API.
22
2.2.8.5 Relasjonsdatabaser vs. dokumentdatabaser
Et hovedmål for videreutviklingen av Cruntch! er at applikasjonen skal kunne oppskaleres til å kunne håndtere flere tusen stemmegivere innenfor et ofte begrenset tidsvindu. Dokumentdatabasene har sin styrke nettopp i forhold til oppskalering.
Business caset indikerer at de viktigste anvendelsesområdene for Cruntch! vil være
innenfor media og forskning. Dette er institusjoner som normalt ikke har egen stor
serverkapasitet som kan imøtekomme kravet om tilstrekkelige QPS. Det vil derfor
være hensiktsmessig for disse at Cruntch! er designet for å kunne leie kapasitet i
nettskyen.
2.2.8.6 MongoDB vs CouchDB
Begge databasene tilfredsstiller alle kravene som har blitt satt til skalerbarhet og det
er bare små forskjeller som gjør at MongoDB blir foretrukket i dette tilfelle. MongoDB
lagrer data som BSON som er et binært JSON. CouchDB lagrer som JSON.
BSON er raskere og tar mindre plass enn JSON. Med mange brukere kan derfor lagring bli et problem i CouchDB. Med MongoDB er det enkelt å gjøre enkle queries,
mens med CouchDB må man lage Map/Reduce queries. Mongo skalerer bedre pga
innebygget sharding. MongoDB er også bedre dokumentert.
2.2.9 MVC
MVC (Model-View-Controller) er et designmønster som brukes i programvareutvikling. Poenget med MVC er å skille hvordan data håndteres fra hvordan dataene presenteres. MVC sørger for at endringer i det visuelle ikke har noen innvirkning på hvordan data håndteres og vice versa. Programmet blir da delt opp i tre lag, der model er
data og businesslogikk view er delen som presenterer informasjonen for brukeren og
kontrolleren som er koblingen mellom view og model.
23
Oppsummert:
Model: holder på data
View: viser fram data
Controller: flytter på data
3.Metoder
3.1 Prosjektstyring
Prosjektstyring er nødvendig for å gjennomføre prosjekter slik at man oppnår ønskede resultater ut fra ressursene som er tilgjengelige. Prosjekter går gjerne over ulike
faser, fra en idéfase til en realiseringsfase. Fokus er på planlegging, styring, koordinering, og leveranser innenfor tids-, kvalitets-, og ressursrammer.
I denne oppgaven er følgende metoder vurdert og prioritert for bruk:
3.1.1 Samarbeidskontrakt
Ved oppstart av prosjektoppgaven er det hensiktsmessig å lage en samarbeidskontrakt. Hensikten med kontrakten er å bli enige om noen grunnleggende vilkår for samarbeidet i gruppen og en plan for hvordan gruppens mål skal nås. Samarbeidskontrakten forplikter gruppe deltagerene til å følge avtalte spilleregler og regulerer hvor
mye innsats den enkelte skal bidra med inn i oppgaveløsningen. Den beskriver også
ansvarsfordeling og verv, slik som gruppeleder, referent, hvem som har ansvar for
innkalling til møter med veileder etc. Gode kontrakter inneholder også avtalte sanksjonsmåter ved brudd på kontraktens forutsetninger.
3.1.2 Prosjektdagbok
Å føre en dagbok eller hendelseslogg under prosjektarbeidet gjør det enklere å rekapitulere fremdrift, hva som erdiskutert og hva man avtalte på de enkelte møtene. Disposisjonen for et møtereferat er ofte: Dato, gruppedeltagere til stede, emne for møtet,
status for fremdriften og avtale om hvem som gjør hva til neste møte.
24
3.1.3 Arbeidsplan
For å løse denne oppgaven er det laget en arbeidsplan som har fungert både som en
disposisjon for skriving av rapporten og som viser hva som skal analyseres og hva
som skal programmeres med tidsfrister. Denne arbeidsplanen ligger i vedlegg 1.
3.1.4 Trello
Trello er en gratis web-basert prosjektledelses applikasjon basert på Kanban tavle
(oppgaver gjennomføres etter just in time prinsippet). Oppgaver settes inn i en liste
og blir flyttet over i andre lister etterhvert som arbeidet utvikles. De nye listene indikerer status for arbeidsoppgaven.
Trello ble valgt som styringsverktøy for programmeringsoppgavene fordi den gir oppdateringer på status via mobiltelefon og reduserer ledetid i samarbeidsprosjekter.
Oppgaven ble tildelt den personen som skulle utføre den. De fleste oppgavene ble
delt inn i flere deloppgaver og Trello ga en klar oversikt over fremdriften.
25
Figur 3: Skjermbilde fra Trello
26
3.1.5 Risikomatrise
Risikomatrisen er et dokument som lister opp hva som kan gå galt i prosjektgjennomføringen. Dette for å være forberedt på problemer. Gruppen listet opp sykdom,
ukjente teknologi, tidsmangel og interne problemer. De ulike risikofaktorene ble kategorisert etter konsekvensens alvorlighets grad. Matrisen for dette prosjektet er vist i
vedlegg B.
3.1.6 Fossefall versus Smidig utvikling
Fossefallsmetoden er en metode som har sine røtter i produksjons- og byggebransjen, men er også mye brukt innen IT. Metoden består av syv tydelig definerte faser
eller trinn. Første trinn er å lage en kravspesifikasjon, andre trinn er design, tredje
trinn er konstruksjon (koding), fjerde trinn er implementasjon, femte trinn er testing,
sjette trinn er installasjon og syvende trinn er vedlikehold.
Tid brukt på planlegging av prosjektet i tidlige faser kan spare mange ressurser i senere faser. Det viser seg at en feil som blir funnet i en tidlig fase vil koste mindre tid
og penger enn å finne den samme feilen i en senere fase. I et fossfallsprosjekt vil
man normalt bruke 20-40% av tiden på planlegging, 30-40% av tiden på koding og
resten på testing og implementasjon.
Store prosjekter med mange ulike aktører som er avhengige av hverandre, vil nyte
godt av de strenge rammene som er blir fastsatt og kravene til god dokumentasjon.
På denne måten vil alle de involverte ha en oversikt over hva som skal gjøres, hvem
som gjør det og når det blir gjort.
Ulempene er at metoden ikke tar høyde for endringer av oppgaven eller problemstillingen. Et vanlig eksempel på dette er at oppdragsgiver ikke er helt sikker på hva de
ønsker eller at de kommer med nye krav. En annen vanlig problemstilling er at det er
27
vanskelig å se for seg alle mulige problemer som kan oppstå før man faktisk har begynt å programere. Alle avik fra planen vil kreve oppdatering av alle prosjektdokumentene og føre til endringer i planen. Dersom man er riktig uheldig, vil man komme
til et punkt der man bruker mer tid på å endre og oppdatere dokumentasjonen enn
man bruker på å faktisk jobbe med prosjektet.
Smidige metoder tar som utgangspunkt at systemutvikling er uforutsigbar, og at prioriteringen av funksjonelle krav vil kunne endre seg etter hvert som systemet tar form.
Smidige metoder begrenser denne risikoen ved å utvikle systemet bitvis og med hyppige del leveranser. Det styres etter verdi og fokuseres på kontinuerlig læring ved
evaluering av gjennomførte leveranser
Prosjektet deles ofte inn i faser som konseptfasen, planleggingsfasen, gjennomføringsfasen og fasen for avslutning, evaluering og bruk.
Scrum er en gren under smidig utvikling og er et rammeverk laget med henblikk på å
utvikle komplekse informasjonssystemer. Det brukes i hovedsak til å utvikle programvarebaserte systemer og benyttes gjerne i kombinasjon med Extreme Programming
(XP), men kan i prinsippet brukes til å håndtere alle slags prosjekter av en viss
kompleksitet. Teorien er basert på empirisk prosesskontroll og fordrer at man jobber
inkrementelt og iterativt og at selve utviklingsjobben utføres av tverrfaglige, selvstyrte
team.
3.1.7 Git
Når man jobber med et omfattende IT-prosjekt, vil det oppstå behov for et versjonskontrollsverktøy slik at de som er involverte lett kan synkronisere og dele filene sine. I
dette prosjektet ble Git benyttet som versjonskontrollverktøy med et repository på gitlab.com som er et nettsted som tilbyr gratis git-repositories
28
Git er distribuertnoe som betyr at alle kan synkronisere med alle og ikke bare med hovedgrenen. Dette gjør det mulig for hver enkelt å jobbe med sin lokale versjon og når
man blir ferdig kan man enkelt flette sitt arbeid inn i hovedgrenen.
3.1.8 Ide dugnad
En idédugnad er et møte der mennesker kommer sammen for å finne ideer. Ofte er
det for å hjelpe en eller flere personer (eller organisasjoner) til å løse problemer, utfordringer eller finne muligheter. Grupper kan ofte løse problemer som deltakerne
hver for seg ikke ville greie. En gruppe mennesker har: Flere informasjoner, flere måter å se et problem på, flere måter å tenke på og mange flere erfaringer. For å kunne
bruke en gruppes mentale ressurser best mulig, kreves gode kreative arbeidsmetoder
og en dyktig prosessleder.
3.2 Analysemetoder
I denne oppgaven er det lagt vekt på gjennomføre gode analyser i forkant av utviklingsarbeidet for å kartlegge og sikre god innsikt i problemstillingene både fra oppdragsgivers, sluttbrukers og dataingeniørens ståsted. Det er gjennomført analyser på
det forretningsmessige/kommersielle plan, og også ved å sette seg inn i potensielle
sluttbrukeres situasjon som grunnlag for systemutviklingen og for å skissere database
strukturen.
3.2.1 Business case
Business Case er en analysemetodikk som benyttes for på et overordnet nivå å avgjøre om et prosjekt eller en større aktivitet skal iverksettes. Hensikten med Business
case er allerede i konseptfasen å kunne avgjøre, med bruk av begrensede ressurser,
om det er hensiktsmessig å starte opp den aktuelle aktiviteten eller prosjektet. Business caset er også godt egnet til å presentere prosjektet eller ideen for andre, som
samarbeidspartnere eller investorer.
29
Basert på konklusjonen fra analysen av følgende parametere, kan aktiviteten bli besluttet iverksatt eller ikke:

Hva aktiviteten er ment å skulle løse, hvilket behov hos målgruppene skal løsningen møte

Hvilke forretningsmessige fordeler vil aktiviteten gi

Hvilke andre alternativer foreligger

Gevinst, kostnad og risiko ved hvert alternativ

Forhold til interne og eksterne betingelser
3.2.2 Hvordan intervjue kunder/brukere?
I designet av nye produkter eller tjenester er det sentralt å forstå kundenes eller brukernes opplevelser av den situasjonen produktet skal løse for dem. Den viktigste informasjonskilden er å snakke med kundene direkte og høre deres egne fortellinger
om hva de faktisk vektlegger. Disse samtalene bør gjennomføres både i konseptfasen, men også følges opp i design og gjennomføringsfasen for å kunne sjekke ut om
produktutviklingen er på rett spor.
Det er viktig ved kundeintervjuer å ikke selv selge inn egen ide eller løsning, men faktisk lytte til kundens opplevelser og problem forståelse. Ikke forled kundene ved bruk
spørsmål med ordet "ville" i som f.eks.:

"Hvis vi bygget et produkt som løste X problem, ville du bruke det?"

"Hvor mye ville du betalt for noe som gjorde X?"

"Ville du skiftet ut din eksisterende løsning hvis den gjorde X?"
Følgende intervju mal med åpne spørsmål anbefales:
1. Hva er den vanskeligste delen ved ditt problem og i hvilken sammenheng opplever du dette?
2. Kan du fortelle meg om den siste gangen det skjedde?
30
3. Hvorfor var det vanskelig?
4. Hva, om noe, har du gjort for å løse det problemet?
5. Hva liker du ikke ved de løsningene du har prøvd?
3.2.3 User story
En user story er en kort beskrivelse fra sluttbrukere av et system som uttrykker hva
brukeren trenger å gjøre for å løse sin oppgave. User stories brukes som basis for å
definere programvarens nødvendige funksjoner. User storyen beskriver på en enkel
måte for hvem, hva og hvorfor programvaren/IT systemet skal fungere og er viktig i
utformingen av kravspesifikasjonen og designprosessen.
3.2.4 Use case
Innenfor programvare utvikling benyttes use case til å analysere, definere og fremstille interaksjonen mellom eksterne aktører og systemet for å gjennomføre en oppgave. Aktørene må kunne gjøre beslutninger, og kan være en person en organisasjon
eller et computer system. Aktøren er alltid interessert i resultatet av transaksjonene.
Transaksjonene fremstilles ofte i Use case diagrammer som viser forholdet mellom
brukeren og datasystemet ved de ulike oppgavene som skal gjennomføres
3.2.5 ER- modellering
"ER" står for "Entity / Relationship". Et ER-diagram er en grafisk fremstilling av strukturen i en database. ER-diagrammet er en visualisering av databasens funksjon og
oppbygning, og vektlegger ikke tekniske spesifikasjoner eller kapasiteter. En ER-modell egner seg godt som diskusjonsgrunnlag for å avklare behov og begrepsbruk i
møter mellom sluttbrukere og databasedesignere.
I alle fasene i utviklingen av en database må man alltid ta utgangspunkt i hvordan og
av hvem databasen forventes brukt. Det bør være klart hvilken informasjon som skal
kunne hentes ut av databasen før man begynner designprosessen.
31
Figur 4. ER-diagram av Cruntch! databasene.
3.3 Verktøy
Google documents sin draw funksjon har blitt brukt for utforming av diagrammer og
skjemaer.
Til å lage skisser ble hotgloo.com brukt, og gliffy ble brukt til å lage ER-diagram.
Microsoft Excel ble brukt til risikomatrise og Gantt-skjema.
32
3.4 Kommunikasjon
Gruppen etablerte en Facebook side; bachelor chat, som ble benyttet til å avtale møter og utveksle informasjon. I tillegg til møter hver 2. uke på skolen, ble Skype benyttet til diskusjoner mellom en eller flere i gruppen.
For å dokumentere utviklingsarbeidet og for å skrive den endelige rapporten ble
Google documents benyttet. Google documents gjør det mulig for flere å skrive i
samme dokument samtidig slik at alle kan følge med på hva som blir skrevet og dermed hele tiden er oppdatert på fremdriften for rapporten.
3.4.1 Prosjektdokumentasjon
Utviklingen av prosjektet i de forskjellige fasene er dokumentert i en prosjektskisse og
en forprosjektrapport som ligger i vedlegg 3 og vedlegg 4. Gjennomføringen av hovedprosjektet er dokumentert i denne rapporten.
4. Analyse
I analyse kapittelet beskrives analyser som er gjennomført for å få innsikt i sluttbrukers mulige behov knyttet til en web-basert avstemmings- og rangeringstjeneste. Det
er også gjort enkle søk for å kartlegge hvilke bruker grupper som kan være aktuelle
som kjøpere av en slik tjeneste.
Det er videre valgt å analysere forretningsmuligheter i mediamarkedet gjennom et business case for Melodi Grand Prix og den store avstemmings prosessen som utgjør
en viktig del i dette TV konseptet. Det er også beskrevet User story og Use case for
Melodi Grand Prix. Use caset berører den kritiske parameteren som er knyttet til hvilket tidsvindu stemmegiver vil holde oppmerksomheten rettet mot sin individuelle
stemmegivning. Dimensjonerings kriterier for oppskalering av antall stemmegivere er
også beskrevet.
33
Som et eksempel på en småskala avstemmings turnering er det valgt å illustrere en
pizza avstemming i en vennegjeng gjennom User story og Use case.
Innsiktene i bruker adferd og hvilke krav som må stilles til systemet, som er ervervet
gjennom analysene, er benyttet i designprosessen.
4.1 Business case
Oppdragsgiver illustrerer anvendelsen av algoritmen, som er grunnlaget for denne
oppgaven, med følgende tekst:
“Cruntch!: 'Hva er viktigst for deg`?
Se for deg at du koser deg sammen med vennene dine en fredags ettermiddag. Dere
får lyst til å bestille pizza, men da begynner allerede diskusjonen med hva folk liker av
forskjellige toppings på pizzaen. «Slik blir vi aldri enige», tenker du. Du tar frem
Cruntch! på mobilen og skriver inn alle navnene på pizzaene som folk ønsker seg. Så
sendes det en melding til alle vennene tilstede og de må nå gjøre noen valg. De vil bli
spurt en rekke små spørsmål om hvilken pizza de helst vil ha med alltid to av pizzaene som alternativene. Når alle er ferdig, sitter du igjen med en nøyaktig liste over
hvilke pizzaer som er mest populære. Endelig kan dere bestille,”
Umiddelbart er det vanskelig å se for seg hyppig bruk av en "Valg-av-pizza" tjeneste.
Hvor ofte er man i en slik situasjon? Gidder man å bruke en web tjeneste i så fall?
I det følgende beskrives noen eksempler på mulige anvendelsesområder og markedsmuligheter for en web basert beslutnings- eller rangerings tjeneste:
4.1.1 Mediamarkedet
Når først problemstillingen knyttet til avstemminger og rangeringer ble bevisst, har det
etterhvert dukket opp flere og flere eksempler på at avstemminger og rangeringer er
veldig utbredt. Som eksempler nevnes Folkedebatten på radio P4, kåringer i aviser
34
og TV av årets navn, årets juleøl og årets ildsjel mfl. TV programmer som Idol, Skal vi
danse og Melodi Grand Prix har seer avstemmingen som en integrert og viktig del av
program konseptet. For å vise hvor stort engasjement slike kåringer vekker, viser vi til
et utdrag av en artikkel i VG 01.05.15:
Her er de fire «Publikumpris»-finalistene

KRISTINE HELLEM AANSTAD
(VG) 01.05.2015 08:54 - oppdatert 01.05.2015 09:05
Antall kommentarer på artikkelen13
Del på FacebookDel på Twitter
Over 86.000 VG-lesere har talt: Kadafi Zaman, Anne Rimmen, Otto Robsahm og
Truls Svendsen skal kjempe videre om «Publikumsprisen» under Gullruten i
Bergen.
I en måned har VGs lesere stemt på sin favoritt til å vinne Publikumsprisen under TV-prisutdelingen.
86.000 har så langt stemt i den store kåringen, og nå kan VG avsløre hvilke fire
som har kapret flest stemmer og dermed går videre i konkurransen: Kadafi
Zaman, Anne Rimmen, Truls Svendsen og Otto Robsahm.
Hvem av disse fire som vinner, er det VGs lesere som skal avgjøre gjennom å
stemme på sin favoritt helt frem til dagen prisutdelingen blir holdt i Bergen.
De fire finalistene tar med seg stemmene fra forrige runde, og nå kan du eventuelt på nytt stemme på din favoritt blant de fire. Det gjør du ved å trykke
«stem» i avstemningen med kun Zaman, Rimmen, Robsahm og Svendsen –
som du finner øverst i denne saken.
På en måned er det avgitt 86 000 stemmer i denne kåringen, og avstemmingen skal
fortsette en måned til. Kanskje avgis det opptil 200 000 stemmer for å kåre Publikumsprisen i 2015? Dette illustrer hvor stort rangeringer er i Norge.
35
En artikkel i VG den 14.04.2004 viser at publikum også engasjerer seg i prinsippene
for hvordan kåringen eller turneringer gjennomføres. Dette illustreres av følgende sitat:
“- Dette er helt utrolig!!!!! Vinneren går ut!!! Det er jo helt feil! Det er stemmesystemets
feil!!!!!!!! Dette hadde aldri skjedd om systemet hadde vært slik at du stemmer på den
du vil skal gå ut!!”
I avstemmingen om stemmesystemet, som VG arrangerte den 14.04.2004, avgis 23
460 stemmer og 68% mener at Idol systemet var feil mens 32% mente at det ga riktig
resultat. Det er misnøye og uenighet rundt avstemmings oppsettet også i American
Idol.
I både norsk og amerikansk Idol klager publikum over at avstemmings regimet ikke
gir riktig resultat. Nettstedet VoteFair kaller single-elimineringen for primitiv og hevder
at velgerene også bør angi andrevalg, tredjevalg osv. når det foreligger mer enn to alternativer, slik som det gjøres i Melodi Grand Prix. Dette krever et eget oppsett for
stemmesedlene:
36
Figur 5: Eksempel på stemmeseddel oppsett for individuell rangering av konkurrenter.
Kilde: www.votefair.org.
Det ble avgitt 330 000 stemmer på en kveld i Idol i 2004. Mens i American Idol økte
antallet stemmer med 100 millioner stemmer da sms stemmer ble tillatt i 2009. I 2012
stemte 132 millioner mennesker i American Idol sammenlignet med 122 millioner
stemmer i det amerikanske president valget.
Hvor viktig det er at regelverket rundt en avstemning er rettferdig og klart viser følgende debatt innlegg i VG den 23.11.2007:
“Legger merke til at de første deltakerne som er på lufta får sitt telefonnummer på
skjermen der man kan ringe på for å stemme på vedkommende. Og dette kan folk
ringe på og sende SMS på FØR folk har hørt resten av innslagene og før de vet i hvilken rekkefølge artistene kommer i! Altså kan førstemann utpå, i kveld var det Linda,
innhente mange flere stemmer i minuttene som går før siste deltaker får komme på
lufta. ...hvis jeg ikke tar feil blir det ikke likt antall minutter for avstemming på hver deltaker?”
VG artikkelen den 17.04.2004 viser også til at det er marked for avstemnings tjenester - da TV2 som arrangerer Idol viser til sin leverandør av tjenesten for å forsvare
stemme innretningen. TV2 Interaktiv, som er et datterselskap av TV2, har bl.a ansvar
for drift av konkurranser og spill.
En artikkel i Dagens Næringsliv 04.02.2014 beskriver en inntekts strøm knyttet til Idol
avstemningen på ca. 1,1 millioner kroner pr program som fordeles på TV2, teleoperatørene, og TV produksjonsselskapet som er rettighetshaver :
37
“Å stemme på sin favorittdeltager koster 4 kroner og 50 øre hvis man bruker telefon, 5
kroner dersom man sender en SMS. Etter de to første programmene var det avgitt
471.000 stemmer, noe som ifølge Aftenposten gir over 2,2 millioner kroner i inntekter.
Av disse pengene sitter tv-kanalen TV 2 igjen med rundt en krone per stemme. Resten fordeles mellom TV 2 Interaktiv, teleoperatørene Netcom og Telenor, og mobilselskapet Carrot, som er ansvarlig for å samle inn telefonstemmene. I tillegg skal produksjonsselskapet Fremantle, som eier formatrettighetene til Idol, ha sitt.
- Det kommer da inn noe penger, men Idol er langt fra gratis å produsere. Så det er
ingen automatikk i at vi blir rike av dette, men det er jo godt at det kommer noe inn,
sånn at ikke alt går ut, sier presseansvarlig Bjarne Laastad i TV 2 til Aftenposten.
Ifølge Laastad har Idol nesten dobbelt så mange seere i år som ifjor. Han påpeker at
det derfor ikke er unaturlig at det blir mer penger ut av dette heller, og legger til at
man i fjor så at antall stemmer økte parallelt med seertallene.
Forrige onsdag ble det avgitt 287 000 stemmer, mens programmet ble sett av over
700 000. Det siste programmet før fjorårets finale endte opp med 390 000 stemmer.
Under forutsetning av at antall stemmer i går kveld endte på rundt 300 000, vil de totale Idol-stemmene til nå ha nådd 3,6 millioner kroner. Ifølge Aftenpostens regnestykker har TV 2 i så fall fått 700. 000 kroner i inntekter.”
4.1.2 Forskning
Oppdragsgiver nevner selv forskning som ett mulig anvendelsesområde. Som et eksempel trekkes det her frem sensoriske analyser. Beskrivelsen av temaet på Wikipedia viser at det her er snakk om store informasjonsmengder som behandles statistisk
for å kåre vinnere innenfor områder hvor de menneskelige sanser blir brukt til å vurdere egenskaper. Vurdering av mat og smak var den opprinnelige anvendelsen av
sensoriske analyser, men metoden benyttes nå også til å sammenligne og rangere
kvalitet og bruksegenskaper på alt fra TV, biler og mobiltelefoner:
38
“Sensorikk er et fagområde som beskriver egenskaper som menneskelige sanser kan
oppfatte, enten ved å lukte, smake, se, berøre eller høre på et produkt. Sensorisk
analyse er en vitenskapelig disiplin som handler om å planlegge, utføre og analysere
forsøk hvor de menneskelige sansene er blitt brukt til å vurdere ett eller flere produkter. Opprinnelig ble sensorisk analyse brukt i forbindelse med mat, men blir også benyttet på enhver gjenstand som lar seg vurdere etter de ovennevnte sanser. Eksempler på andre produkter enn mat som analyseres ved hjelp av sansene er: TV-apparater (visuell bedømmelse av bildet, kontrast, farger, oppløselighet,…), biler (kjøreegenskaper på forskjellige underlag, lukt, sittefølelse, …), mobiltelefoner (utseende, høyttalerlyd, brukervennlighet,…).
Mat bedømmes både i forbindelse med produktutvikling og kvalitetskontroll. I sensorisk analyse kan man være ute etter objektive eller subjektive bedømmelser. Objektive bedømmelser gis av et sensorisk panel, vanligvis bestående av 8-15 trenede
dommere som har blitt rekruttert på basis av deres evne til å gjenkjenne og rangere
styrken av 4 grunnsmaker (søt, salt, bitter, sur). (Umami holdes vanligvis utenfor i
slike sammenhenger, siden den fremdeles regnes som ukjent for de fleste). I forbindelse med mat bedømmer dommerne egenskaper som har med farge, tekstur, lukt og
smak å gjøre. I sjeldnere tilfelle bedømmes også lyd: ”knekk”-lyden i wienerpølser;
knasingen i frokostblandinger. Fargeegenskapene som bedømmes er særlig hvithet,
fargetone og fargestyrke, definert ifølge NCS (Natural Colour System fra Färginstitutet, Sverige). Lukt- og smaksegenskapene er enten utledet av grunnsmakene, er produktspesifikke, så som rånelukt, eller gruppespesifikke, så som viltsmak, malinglukt
(som beskrivelse av harskhet). De vanligste teksturegenskapene er hardhet, mørhet,
saftighet og fethet.
Et sensorisk panel regnes som et objektivt måleapparat: de bedømmer hvor mye det
er av de forskjellige egenskapene, aldri hvorvidt de liker produktet, dette må gjøres
ved hjelp av en forbrukerundersøkelse. Nesten alle som arbeider med sensorisk analyse benytter et system for elektronisk registrering. Dette fungerer på den måten at
39
dommeren markerer på en skjerm eller ved hjelp av et tastatur hvor mye det er av de
forskjellige egenskapene, og resultatene blir straks lagret på en datafil for videre analyse. Tidligere registrerte dommerne sine bedømmelser ved hjelp av papir og blyant,
men dette var både tidkrevende og førte lett til feil, særlig ved at dommerne glemte å
registrere enkelte tall. I tillegg lå det en feilkilde i den prosessen hvor disse dataene
ble overført til et elektronisk lagringsmedium. Å gjøre de statistiske analysene for
hånd har neppe blitt praktisert i noen særlig stor grad – datamaskiner har stort sett
blitt benyttet til dette siden 1970-tallet.”
4.1.3 Kundebestemt produktutvikling
I et samarbeid mellom bloggeren Stine Skoli, som skriver bloggen Speiltvillingene, og
klesprodusenten Lise Arvesen i Virre Vapp inviteres mødre til å bestemme innholdet i
nye kolleksjoner gjennom avstemming som i vises i følgende sitat fra Virre Vapps
hjemmeside:
“Sosiale medier og stadig ny og bedre teknologi gjør fremtiden spennende! Våren
2015 snur virrevapp.no for første gang design prosessen på hodet. Nå er det ikke
lenger gründermamma Lise Arvesen i Drøbak som står i spissen for nye kolleksjoner
alene. Egen gjeste-designer er invitert inn. Hun heter Stine Skoli og er damen bak
bloggen Speiltvillingene. Stine er kreativ, flink til å sy i tillegg til å ha to små jenter
«Speiltvillinger». Sammen med sine mange tusen blogg-lesere og følgere på Instagram har Stine kommet frem til en liten eksklusiv kolleksjon som lanseres våren
2015. På denne måten kan vi være sikrere enn før på at kundene virkelig ønsker det
som settes i produksjon. Målet er å la kundene bestemme både modeller og valg av
stoffer.”
Hvordan dette forholdet mellom blogger og produsent beskrives er vist i figur 6:
40
Figur 6 :Blogg innlegg på Speiltvillingene.blogg.no
4.1.4 Mentometerknapper
Mentometerknapper ble kjent gjennom radio programmet Ti i skuddet som var på
lufta fra 1965 til 2007. De beste låtene ble kåret gjennom avstemning via mentometerkanpper og senere sms. Wikipedia beskriver mentometerkanpper som:
“En mentometer är en elektronisk apparat för rösträkning, som oftast används i TVprogram. Den kan ha en eller flera knappar beroende på vad publiken skall framrösta,
och registrerar antalet samstämmiga svar, uttryckt i procent av antalet deltagare i en
omröstning. Genom mentometrar kan man snabbt få en bild av den uppfattning som
råder i en viss fråga hos till exempel en TV-studiopublik. Mentometeromröstningar
41
kan också användas medvetet för att skapa en känsla av deltagande och inflytande,
till exempel på kongresser och andra större möten.
Dagens mentometerdosor är trådlösa. Mobiltelefoner kan även användas som
mentometer. Med mobilen kan deltagarna rösta med hjälp av SMS, via en mobil
webbtjänst eller en mobilapplikation.
Tillhörande plattform för förberedelse och presentation kan variera mellan enklare
webbsidor till mer funktionsrika integrationer i PowerPoint eller Keynote.”
Mentometerknapper har fått en renessanse ref. Smartvote.no i mai 2015: ”.... med
mentometerknapper og ny og brukervennlig programvare, kan dere gå fra
presentasjon til direkte og engasjerende kommunikasjon med alle deltagerne
samtidig i møter og konferanser.”
Det interessante som knytter Cruntch! sammen med Mentometerknappene er om
Cruntch! kan fornye måten avstemingene gjennomføres og avstemmingsresultatene
presenteres?
4.1.5 Beslutningsstøtte
Gjennom et Use case intervju ble det synliggjort at også på individuelt nivå kan det
være behov for støtte i beslutningsprosesser. Torill (52år) hadde nettopp kjøpt ny bil.
Hun hadde plukket ut 5 bilmerker som hun var interessert i og vurderte disse opp mot
hverandre i forhold til 10 parametere som pris, kvalitet, leveringstid, anbefalinger mm.
Hun kunne ha tenkt seg hjelp i denne situasjonen.
4.2 Analyse av business case for media markedet
Business caset for media markedet, som vi har mest informasjon om, viser at det er
store inntektsmuligheter i forbindelse med større avstemmings TV arrangementer
som Idol og Grand Prix. En avstemmingsrunde kan generere 500.000 stemmer à 5 kr
42
= 2,5 mill kr. En mindre del av dette kan forventes å gå til system leverandøren for avstemmings programvaren. En antagelse kan være en royalty for bruk av systemet på
0,5% som ville gitt Cruntch! en inntekt på 125.000 kr pr program eller 1,25 mill kr for
en serie på 10 programmer inklusive et finale program.
Det ser ut til å være et etablert marked for avstemmingsprogramvare og de store kundene vi har sett foreløpig synes å være TV produksjonsselskapene feks. TV2 Interaktiv, som kjøper tjenester av underleverandører.
Dagens avstemmings TV serier ser ut til å bruke rene stemme flertalls knock out turneringer, som mange seere mener er urettferdige. En av styrkene til Cruntch! er at
den er basert på double-elimination prinsippet og analyserer hvilke alternativer som
konsekvent taper over et annet, og man får derfor en mer nøyaktig rangering enn ved
single-elimination.
I tillegg flytter Cruntch! avstemmingen over på en nett plattform som vil oppfattes som
mer moderne, og stemmegivingen vil kunne oppleves som underholdene i seg selv i
forhold til telefon og SMS stemmer til den ene favoritten i programmet.
Det er nødvendig med grundigere forretningsmessige analyser før det investeres for
mye i videre utvikling av Cruntch! som forretningskonsept, men det synes på dette
stadiet å være mulig å utnytte konseptet kommersielt både nasjonalt og internasjonalt.
4.3 User story og use case
Det er skissert mulige anvendelsesområder for en avstemmingsalgoritme innenfor
områdene media, forskning, kundebestemt produktutvikling, mentometer avstem-
43
minger og beslutnings støtte. To bruksområder har blitt prioritert i tråd med oppdragsgivers forslag: Verktøy for avstemming i vennegjenger og en stor avstemming som
Melodi Grand Prix.
4.3.1 Verktøy for vennegjenger
En gjeng på 8-10 venner er samlet og blir ikke enig om hvilken topping de skal ha på
pizzaen og dermed hvilken pizza de skal bestille hos en pizzakjede som leverer på
døren. Et beslutningsstøtte system ville kunne løse problemet med de opphetede diskusjonene slik at de pizzaene som er de største favorittene i gruppen, kan bestilles
før sulten tar dem alle.
Verten for selskapet påtar seg å administrere en avstemming i form av en turnering
på nettsiden Chruntch!. Han registrerer e-post adressene til gjestene og alle pizzaforslagene på nettsiden for Cruntch!. Cruntch! sender så en mail til e-postene til deltagerene med link til Home siden for Chruntch!
De er da allerede registrert i turneringen og de klikker seg inn på My Vote siden hvor
alle pizza alternativene er listet opp i en kolonne. For å velge pizza type, blir hver enkelt gjest presentert for to og to pizzaer som de stemmer på som vinner innenfor dette
paret. Cruntch! presenterer fortløpende parvise avstemminger inntil hver gjest har
plukket èn vinner i pizzautvalget. Avstemmingen er da avsluttet og Chruntch! viser
rankingen for pizzaene basert på antall ganger pizzaen har vunnet,
Antall avstemminger vil være (2n -1) hvor n = antall alternativer.
4.3.2 Verktøy for Melodi Grand Prix
Melodi Grand Prix (Eurovision Song Contest) er en musikkonkurranse for medlemslandene i Den europeiske kringkastingsunion. Hvert deltakerland har valgt én sang til
konkurransen, som blir vist på direktesendt TV. Det blir så arrangert en avstemming
44
hvor hvert land kan stemme på de andre landenes sanger for å kåre en vinner. Konkurransen har de siste årene hatt rundt 100 millioner seere på verdensbasis. Konkurransen har blitt arrangert årlig siden 1956, og avstemmings systemet har blitt endret
flere ganger for å bli mer rettferdig og kunne bli gjennomført på kortere tid.
I den nasjonale finalen på NRK det bare stemmes mens showet går på tv og bare på
din favoritt.
Dersom Cruntch! i første omgang ble tatt i bruk for å rangere den norske stemmegivningen i den internasjonale finalen, vil det kreve internett tilgang for alle stemmegivere.
NRK ville være administrator for denne avstemmings turneringen. Vanligvis er det
satt av en time til avstemming, og NRK må åpne og lukke siden for avstemming i
stemme givings vinduet.
Stemmegiver må selv kunne registrere seg med sin e-post adresse og gjennomføre
sine avstemminger. Dersom det er 16 sanger med i finalen, må de gjennomføre 31
parvise valg. Dette er et stort antall interaksjoner som forutsetter at stemmegiverene
holder oppmerksomheten på avstemmingen lenge nok.
De fleste internettbrukere er på en nettside i mindre enn 1 minutt. Studier fra National
Center for Biotechnology Information viser at oppmersomhets vinduet for mennesker
har falt fra 12 sekunder i 2000 til 8 sekunder i 2013. Studier relatert til web bruk viser
at brukere mister interessen for trege sider på fra 1 til 5 sekunder. Dette indikerer at
Cruntch! bør presentere en ny avstemming minimum hvert 5. sekund. En Grand Prix
avstemming med 16 konkurrerende sanger vil da ta 31 avstemminger x 5 sekunder +
reaksjonstid pr personlig avstemming anslått til ca 10 sekunder = ca 8 min. Disse 8
minuttene kan oppleves som ekstra underholdning.
Antall stemmer i den nasjonale finalen for Melodi grand prix i 2012 var ca 350.000.
Dette stiller krav til systemet. Det må være plattform uavhengig og kunne brukes
både på mobil og PC. Siden det blir en peak belastning, må systemet designes slik at
overbelastning unngås og at alle stemmer blir registrert. Det må være raskt og kunne
skaleres etter belastningen. Dvs. ha en QPS (Query per sec), som er en måleenhet
for belastning, på 500.000 stemmer/60minx60 sec = 140 QPS gitt at belastningen er
45
jevn over den aktuelle timen. En enkelt web server som også fungerer som en applikasjon og database kan sjelden behandle mer enn et par hundre requests pr sekund.
Det bør derfor legges til rette for belastnings deling (sharding) i nettskyen. Kobling til
nettskyen vil også sikre oppetiden.
4.4 Utforming av funksjons spesifikasjon
Funksjons spesifikasjonen beskriver hvilke brukerfunksjoner web applikasjonen
Cruntch! må kunne tilby:

Turneringens administrator skal kunne sette opp sin egen turnering

Turneringen skal kunne gjennomføres ved hjelp av email og mobiltelefon

Deltagerne skal kunne avgi stemmer

Et alternativ/en vinner skal bli kåret

Statistikk skal vises for alle turneringer

Siden skal være universelt utformet

Systemet skal være skalerbart
4.4.1 Utforming av kravspesifikasjon
Kravspesifikasjonen beskriver hvilken generell ytelse et programsystem skal ha.
Kravspesifikasjonen utarbeides før programsystemet utvikles, for å sikre at brukernes
behov blir dekket når det gjelder funksjonalitet, ytelse og brukervennlighet. I tillegg til
designkrav som kan utledes fra User story og Use case må det tas hensyn til de lovfestede kravene til universell utforming:
4.4.1.1 Universell utforming
Universell utforming er et moderne begrep som sier at samfunnet bør utformes slik at
så mange som mulig kan delta uavhengig av funksjonsevne og uten at det skal være
behov for spesialløsninger. Dette gjelder også for utforming av web og er pålagt under norsk lov i FOR 2013-06-21 nr 732 “nettløsninger skal minst utformes i samsvar
med standard Web Content Accessibility Guidelines 2.0 (WCAG 2.0)/NS/ISO/IEC
46
40500:2012, på nivå A og AA med unntak for suksesskriteriene 1.2.3, 1.2.4 og 1.2.5,
eller tilsvarende denne standard.”
I WCAGs rettningslinjer er det lagt vekt på fire prinsipper.

Mulig å oppfatte. -Utformingen skal gi tekstalternativer til alt ikke-tekstlig innhold, og konvertere til et format brukeren kan forstå, for eksempel større skrift,
tale, symboler eller blindeskrift.

Mulig å betjene. -Utformingen skal gjøre all funksjonalitet tilgjengelig med tastatur, gi brukeren nok tid til å lese og bruke innholdet, ikke være utformet på en
måte som kan forårsake epileptiske anfall.

Forståelig. -Utformingen skal gjøre innholdet leselig og forståelig, sørge for at
websider presenteres og fungerer på forutsigbare måter.

Robust. -Utformingen skal sørge for best mulig kompatibilitet med aktuelle og
fremtidige brukeragenter, inkludert kompanserende teknologi.
4.4.1.2 Kravspesifikasjon
Basert på foregående analyser er følgende designkrav til Cruntch! for bruk på små og
store turneringer formulert:

Systemet må være plattform uavhengig og kunne brukes både på mobil og PC

Det må være mobil vennlige nettsider og bør gjerne tilbys som en app

Universell utforming

Rankingen av konkurrentene må presenteres

Konkurrenter/alternativer bør vises sammen med et flowskjema over progresjonen i avstemmingen

Responstiden fra Cruntch! for å presentere nye avstemminger og resultater
må være mindre enn 5 sekunder
For storskala turneringer gjelder i tillegg:
47

Cruntch! løsningen må kunne håndtere hele systemet som inkluderer frontend, back-end og databasen. Ved større data input enn det èn PC kan håndtere, må belastningen fordeles (load balancing) ved dynamisk fordeling (sharding) av stemmene/forespørslene (requests) mellom de tilgjengelige maskinene ved at alle bruker e-postene får en unik hash #.

Systemet bør være skalerbart og en dimensjonering for 140 QPS bør minimum legges til grunn.

Statistikken som presenteres for administrator bør også vise stemmefordelingen over tid i en belastningskurve for å kunne brukes som dimensjonerings
kriterie for senere turneringer

Stemme giverene må kunne registrere seg selv på nettsiden

Betalingsløsninger til arrangør bør integreres da de i dag får 5 kr pr stemme
via telefon og sms
En alvorlig ulempe med dagens algoritme er at den kun kan håndtere turneringer hvor
antallet konkurrenter eller varianter er 2 . Dvs oppsett med 4, 16, 32 osv varianter. I
n
Gran Prix finalen for eksempel er det 21 sanger som deltar, et tall som ikke er 2 . Ann
vendelsesområdet for Cruntch! vil øke dersom algoritmen gjøres mer robust.
48
5. Implementering
Nettsidestrukturen er bygget opp av elementene introduksjon, lage turneringsside, avstemmingsside, sider som viser resultater og sider som viser oversikt over turneringen. Et sitemap er vist i figur 7.
Kildekoden ligger er lagret på en CD vedlagt oppgaven.
Figur 7: Sitemap for Cruntch!
49
5.1 Database
MockData blir brukt som impromptu database. Den er veldig lik et JSON dokument i
utforming og er laget med tanke på at det skal skiftes ut med en dokumentdatabase,
så innholdet vil være så likt som dataene fra databasen som mulig. Alle metoder er
laget med hensyn til dette.
5.2 Filstruktur
Package.JSON er et dokument som inneholder data om applikasjonen, som metadata og avhengigheter. Gjør det også mulig for NPM å hente de pakkene som er nødvendige for at applikasjonen skal kjøre. App.js er selve hovedfilen som starter applikasjonen. I mappen views ligger alle skjermbildene som ejs filer, i mappen router ligger filen main.js som fungerer som controller og håndterer all routingen, mappen public inneholder det estetiske (css og bootstrap) og mappen node_modules er de modulene som blir benyttet. I denne oppgaven er det ejs og express.
5.3 Utforming
Sidene ble laget i ejs og stylet med css. EJs er et JavaScript template som fjerner
html koden fra JavaScript, så <script>-taggen blir byttet ut med <% %> som indikerer
at her er det JavaScript og man kan skrive ren JavaScript kode inn. Twitter Bootstrap
3 ble brukt til å lage navigasjonsbar og footer. Det ble laget tre partial-sider for ting
som vil være felles for alle sidene som footer, navigasjonsbar og header, disse blir inkludert ved <% include %> kommandoen. Dette er gjort både for å spare tid og for å
forsikre seg om at alle sidene blir like og får med seg alt de trenger. Head-partialen
har ikke med seg head-tagger slik at det er mulig å legge til nye script, dette ble gjort i
statistic.ejs hvor scriptet for grafene måtte legges til.
5.4 Design
Et ønske fra oppdragsgiver var at applikasjonen skulle være enkel, men samtidig elegant og lett å bruke. Valget falt derfor på en svart navigasjonsbar med hvit skrift på
50
toppen av siden for å gjøre det enkelt å navigere. Det ble laget en tilsvarende bar på
bunnen av siden for å ha et sted å vise metainformasjonen og linker til sosiale medier
eller lignende. Noen prinsipper for universell utforming har blitt fulgt som gode kontraster, men da dette bare er et utkast har ikke dette vært prioritert.
5.5 Testing
Siden dette prosjektet bare er utkast til hvordan oppgaven kan løses har ikke testing
blitt prioritert.
5.6 Skisser
De første skissene til site design er tegnet i hotgloo.com.
51
52
Figur 8,9,10: Skisser.
53
5.7 Skjermbilder
I dette kapitelet presenteres nettstedet Cruntch! i form av skjermbildene brukerne vil se
index.ejs
Dette er velkomstsiden, her står det kort fortalt hva Cruntch! er og det er knapper for
å gå til avstemming (playtour.ejs) og lage turnering(createtour.ejs).
Figur 11: Skjermbilde av index.ejs
54
createtour.ejs
Dette er siden for å lage en turnering. Siden består av et HTML-form med seks inputfelter og en submitknapp.
Figur 12: Skjermbilde for createtour.ejs
55
result.ejs
Denne siden viser hva som ble skrevet inn i createtour.ejs og har en lenke til playtour.ejs. Ved henting av siden blir req.body sendt med som parameter og siden blir
populert basert på det.
Figur 13: Skjermbilde for result.ejs
56
playtour.ejs
Dette er siden for avstemning, brukeren får valget mellom to knapper og trykker på
den knappen man føler er best.
Figur 14: Skjermbilde for playtour.ejs
57
mycruntch.ejs
Siden er ment å være en samleside for alle turnerningene som brukeren har vært
med på. Siden er delt i to lister der den ene listen er turneringer som brukeren har
markert som favoritt og den andre listen inneholder alle turneringene sortert etter
dato.
Figur 15: Skjermbilde for mycruntch.ejs
58
statistic.ejs
En side som gir et mer detaljert bilde over hvordan turneringen utspilte seg. Inneholder en liste over hvem som var med og hvor mange poeng de fikk, et stolpediagram
over alle deltakerne og poengsummen, og et stolpediagram for hver enkelt deltaker
som viser de ulike plasseringene deltakeren fikk. Grafene blir laget ved hjelp av
Google chart tools.
Figur 16: Skjermbilde for statistic.ejs
59
6. Evaluering av arbeidet
I innledningskapittelet ble det beskrevet formål og resultatmål for oppgaven. I dette
evaluerings kapitlet blir både måloppnåelse og arbeidsprosessene i bachelor oppgaven evaluert.
6.1 Vurdering av målrealisering
6.1.1 Formål og resultatmål
Det er kartlagt flere mulige markedsområder for Cruntch!. De største er media markedet og innenfor sensoriske analyser i forskningsmarkedet som hjelpemiddel innen
produktutvikling. Et helt nytt anvendelsesområde som har vokst frem i kjølvannet av
den store veksten i bruk av sosiale medier, er noe vi har kalt kundebestemt produktutvikling. Vi har også relatert en mulig bruk av Cruntch! til mentometerknapper som brukes i konferanser og undervisning. Et annet anvendelsesområde i mindre skala kan
være beslutningsstøtte for indvider og grupper.
Det er utviklet en fungerende web side for å gjennomføre stemmegivning og visning
av resultater. Applikasjonen er lagt til rette for skalering gjennom bruk av JavaScript
og Node.js Databasen er grovt designet, men er ikke implementert da dette ble en for
omfattende oppgave innenfor denne tidsrammen.
6.1.2 Læringsmål
Oppdragsgiver har etterspurt en skalering for bruk av sitt statistiske verktøy. Ved å
jobbe med oppgaven fant vi at oppdragsgivers implementering var en verdifull inspirasjon til å designe tilsvarende funksjonalitet i moderene verktøy og rammeverk. Da den
originale kildekoden ikke var kjørbare i sin presenterte form, ga dette et godt incentiv
til å sette seg inn i PHP, som var det opprinnelige programmeringsspråket og å lære
60
seg å bruke nye programmeringsspråk som JavaScript og rammeverket Node.js og
andre web utviklings verktøy.
Planlegging har vært helt nødvendig for å kunne komme igjennom alt arbeidet. Prosjektstyringsverktøy krever mye for å holde dem oppdatert, og hvis de ikke er oppdatert er de til liten nytte. Gant diagrammer er tidkrevende fordi de må oppdateres forløpende og justeres ved endringer. De store planverkene ble derfor raskt erstattet med
mindre lister og oversikter over oppgaver og tidsfrister for å ha en oversikt og huske
alt. Git var ikke nødvendig etter at det ble klart at jeg skulle fullføre oppgaven alene.
Skriving av rapporten ble en av de største oppgavene og som det var satt av for lite
tid til. Disposisjonen for rapporten ga strukturen, men den har vært endret underveis
ettersom innsikten i materialet har økt.
6.2 Evaluering av og læring om samarbeid
Det var et krav fra HIOA at bacheloroppgaven skulle skrives i en gruppe på 2 til 4 studenter. Da jeg meldte meg som student til bachelor oppgaven primo januar, var allerede gruppene etablert og jeg måtte finne en gruppe å arbeide i selv. Jeg sendte da
en individuell mail til alle de 12 gruppene som hadde mindre enn 4 deltagere. Jeg
presenterte meg og spurte om det var mulig å få lov til å samarbeide med dem. Jeg
fikk raskt svar fra 3 grupper hvorav en beklaget at oppgaven var for liten i omfang til å
være flere studenter.
To andre grupper svarte hyggelig at jeg kunne få en samtale med dem og diskutere
muligheten for samarbeid. Begge gruppene besto av tre studenter. Den ene gruppen
skulle lage en hjemmeside for et arkitekt kontor. Den andre gruppen skulle lage både
hjemmeside og database for en prosjektide fra en oppdragsgiver på HiOA, som jeg
valgte å delta i fordi jeg syntes det var faglig mer utfordrende.
61
6.2.1 Samarbeid i gruppe
Både prosjektskisse og forprosjekt rapport var innlevert da jeg startet i gruppen.
Gruppen var dermed relativt godt etablert blant de 3 studentene som også kjente
hverandre fra studieretningen Anvendt Data. Gruppe leder var også valgt. Vi var imidlertid enige om at gruppen fikk et bredere kompetanse grunnlag med min bakgrunn
fra Dataingeniør linjen.
For å løse oppgaven ble arbeidet delt i fire delprosjekter med fire delprosjektledere:
1. Front-end
2. Database
3. Back-end
4. Dokumentasjon
Jeg påtok meg oppgaven med å designe og programmere nettsiden, da jeg har løst
flere slike oppgaver tidligere i studiet.
I starten kommuniserte gruppen på Skype eller i møter en gang i uken. Ganske raskt
sank kommunikasjons hyppigheten og det ble ikke vist til noen resultater fra de ulike
delprosjektene med begrunnelsen at arbeids oppgavene var vanskelig. Først etter 8
uker søkte gruppen hjelp til database utviklingen hos oppdragsgiver, og veileder ble
ikke kontaktet til tross for utfordringene vi opplevde.
Jeg opplevde det som vanskelig å ta en mer ledende plass i en allerede etablert
gruppe. Da jeg til sluttet snakket med veileder, rådet han meg til å ta ansvar for min
egen eksamen og levere en individuell oppgave
6.2.2 Samarbeid med oppdragsgiver og veileder på HIOA
Da jeg først tok kontakt med oppdragsgiver og veileder fikk jeg god hjelp både i møter
og på mail. Disse har sikret framdriften for oppgaven.
62
6.2.3 Ide dugnad med eksterne
Da jeg startet å arbeide alene, opplevdes det som nesten umulig å kunne fullføre. Da
det ble foreslått at jeg kunne lage en ide dugnad, fikk jeg mye inspirasjon og ideer til
hvordan jeg kunne komme videre.
Å delta i en idedugnad med mer erfarne mennesker var spennende. De er mer ukritsiske til hva de faktisk kan akkurat nå og har mer pågangsmot til å finne ut av ting,
selv om de var tydelige på at det var jeg som måtte gjøre den jobben i dette prosjektet.
6.3 Vurdering av produktutviklings prosessen
6.3.1 Designprosessen
Det var planlagt å gjennomføre reelle User story og Use case intervjuer med utvalgte
sluttbrukere og å bruke resultatene inn i design prosessen. Business case analysen
viste imidlertid at Cruntch! i hovedsak henvender seg til et i utgangspunktet nisjepreget behov i bedriftsmarkedet. De viktigste sluttbrukerene som er identifisert, ville være
innenfor media og forsknings segmentet hvor vi ikke hadde noen nære kontakter.
Også innenfor personmarkedet som vennegjenger og personlig beslutnings støtte var
det vanskelig å gjennomføre åpne, ikke ledende intervjuer fordi personene vi møtte
ikke hadde erkjent noe behov for et rangerings verktøy basert på avstemminger.
Bloggposter fra publikum som kommenterer TV sendinger som Idol og er referert i
rapporten, viser imidlertid at avstemminger engasjerer og kan vekke sterke følelser
som sinne og aggresjon.
63
Av praktiske hensyn er det ikke gjennomført reelle bruker intervjuer bortsett fra ett
som avdekket et mulig behov for personlig besluttningsstøtte. Studentens egen situasjons forståelse, som muligens ikke er helt i tråd med sluttbrukeres faktiske behov, er
lagt til grunn for designprosessen.
6.3.2 Turneringsoppsettet
Oppgaven var svært utfordrende da bare det å forstå Cruntch! algoritmens turnerings
logikk i praktisk anvendelse var vanskelig. Som teori kapittelet viser, er det er mange
muligheter for turneringsoppsett. Det ble usikkert om utgangspunktet for oppdragsgivers algoritme var det mest hensiktsmessige valg for å kunne produsere et praktisk
anvendelig produkt.
Fortåelse av turneringsoppsettet var det viktigste design kriteriet for front end og brukergrensesnittet. Den opprinnelige algoritmen er beholdt, og det er valgt å se bort fra
alternative forståelser og løsninger, som muligens ville vært bedre tilpasset praktiske
bruker situasjoner. Da dette er en bachelor oppgave innenfor data, er det valgt å
legge det meste av ressursene inn i arbeidet med programmering for å vise at studenten evner å utvikle en web applikasjon i moderne programmeringsspråk og rammeverk innenfor oppgavens tidsramme
Mulighetene for skalering var en sentral driver for videreutvikling av Cruntch!. Skaleringen kan skje i to dimensjoner: Flere stemmegivere og flere alternativer å stemme
på.
Flere alternativer gir mange sub avstemminger for den enkelte stemmegiver, noe som
forlenger tiden stemmegiver må benytte - da maksimum antall avstemminger er n-1og
minimum antall avstemminger er n-2. Melodi Grand Prix caset som er belyst i rapporten er beregnet å ta omlag 8 minutter dersom det er 16 konkurrerende sanger med.
Dersom denne private avstemmingen oppleves som underholdende, er det kurant og
en tilførsel av merverdi for TV programmet. Dersom avstemmingen forventes å være
64
unnagjort med samme tidsforbruk som en sms stemme, blir Cruntch! en altfor tidkrevende avstemmings løsning.
Ulempen med dagens Crunch! sin algoritme er at den bare egner seg for avstemminger med et konkurrent antall som er delelig med 4. Finalen i feks Melodi Grand
Prix har 21 deltagere og kunne derfor ikke benyttet Cruntch! i dag.
Flere stemmegivere belaster bare server kapasiteten og antallet kan være nærmest
ubegrenset. En million stemmegivere er ikke uvanlig i feks USA og vil kunne håndteres av Crunch! når den er designet for bruk av nettskyen.
Innenfor utgangs algoritmens begrensninger kan det konkluderes med at Cruntch! er
modernisert og skalerbar med hensyn på antall stemmegivere. Når det gjelder antall
variable/konkurrenter, anbefales det å ikke overstige 4 eller 8 pr turnering.
For at stemmegiver skal kunne følge med på turneringens utvikling ville det vært hensiktsmessig om turnernings oppsettet og progresjonen i turneringen ble vist i et diagram på avstemmings siden. Dette anbefales gjennomført under videre arbeid.
7. Konklusjon og videre arbeid
Gjennom arbeidet med denne bachelor oppgaven har Cruntch! kommet nærmere til å
bli en fullstendig skalerbar web applikasjon. Front end fungerer for småskala turneringer, men det gjenstår å programmere databasen.
65
Innenfor utgangs algoritmens begrensninger kan det konkluderes med at Cruntch! er
modernisert og skalerbar med hensyn på antall stemmegivere. Når det gjelder antall
variable/konkurrenter, anbefales det å ikke overstige 4 eller 8 pr turnering.
Business caset viser at det er marked for turnerings verktøy. Det gjenstår mye research hos mulige kunder for å brukertilpasse applikasjonen til de spesifikke kundesegmentene. Det gjenstår også mer forretningsutviklings analysearbeid før det bør taes
beslutninger om å kommersialisere web applikasjonen Cruntch!
Innenfor det tekniske området foreslås det å gjennomføre følgende utviklings oppgaver:

Algoritmen må kunne håndtere alle tall og ikke bare 2 .

En grafisk representasjon av hvor man befinner seg i turneringen når man
n
stemmer.

Lage en app for mobiltelefoner

For å optimalisere designet bør det gjennomføres reelle brukerintervjuer for
segmenter av brukere med ulike funksjonskrav

En innloggingsfunksjon hvis brukerene har lyst til å se på gamle turneringer.
66
Kilder
Kilder turneringer:
http://www.thefreedictionary.com/tournament
http://en.wikipedia.org/wiki/Tournament
http://en.wikipedia.org/wiki/Single-elimination_tournament
http://www.sjakkskolen.no/instrukt%C3%B8r/lage-turenring/
http://en.wikipedia.org/wiki/Round-robin_tournament
Kilder teknologi:
http://www.slideshare.net/randyconnolly/chapter01-presentation16514220?qid=0f2cbe87-e797-4c46-a380-cff971c72399&v=default&b=&from_search=1
http://nn.wikipedia.org/wiki/Linux
http://en.wikipedia.org/wiki/Apache_HTTP_Server
http://no.wikipedia.org/wiki/HTML
http://no.wikipedia.org/wiki/HTTP
http://no.wikipedia.org/wiki/PHP
http://no.wikipedia.org/wiki/JavaScript
http://en.wikipedia.org/wiki/Node.js
http://en.wikipedia.org/wiki/Express.js
http://no.wikipedia.org/wiki/API_%28programmering%29
http://www.sqlserver.no/hva-er-en-relasjonsdatabase/
Databasesystemer. Bjørn Kristoffersen. 3. utgave. Universitetsforlaget 2012. s.9
http://no.wikipedia.org/wiki/MySQL
http://en.wikipedia.org/wiki/MongoDB
http://en.wikipedia.org/wiki/CouchDB
http://no.wikipedia.org/wiki/Cascading_Style_Sheets
http://en.wikipedia.org/wiki/Representational_state_transfer
http://no.wikipedia.org/wiki/SOAP
http://getbootstrap.com/2.3.2/
67
http://no.wikipedia.org/wiki/Nettskyen
Kilder metode:
http://no.wikipedia.org/wiki/Model–view–controller
http://www.kreativtnorge.no/Kreative_Prosesser/idedugnader.htm
http://customerdevlabs.com/2013/11/05/how-i-interview-customers/
http://no.wikipedia.org/wiki/Scrum
http://no.wikipedia.org/wiki/Prosjektstyring
http://no.wikipedia.org/wiki/Business_case
http://en.wikipedia.org/wiki/Trello
http://en.wikipedia.org/wiki/Use_case
http://en.wikipedia.org/wiki/Use_Case_Diagram
http://en.wikipedia.org/wiki/User_story#Story_map
http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_mode
Kilder analyse:
http://www.vg.no/rampelys/tv/gullruten/her-er-de-fire-publikumpris-finalistene/a/23444061/
http://www.vg.no/rampelys/tv/idol/raser-over-idol-avstemning/a/223482/
http://vgd.no/musikk-tv-og-film/idol/tema/1307103/tittel/rettferdig-telefonavstemning
http://en.wikipedia.org/wiki/American_Idol#Season_14
http://www.itv.com/news/2012-05-24/x/
http://no.wikipedia.org/wiki/TV_2_Interaktiv_%28Norge%29
http://www.dn.no/etterBors/2004/02/26/tv-2-tjener-fett-pa-idolavstemninger
http://no.wikipedia.org/wiki/Sensorikk
http://no.wikipedia.org/wiki/Ti_i_skuddet
http://sv.wikipedia.org/wiki/Mentometerde største
http://www.smartvote.no/
http://www.virrevapp.no/pages/barnas-designkonkurrans
http://speiltvillingene.blogg.no/1385538928_morgenstund_.htmle
68
www.votefair.org/americanidol.html
http://no.wikipedia.org/wiki/Eurovision_Song_Contest
http://www.ministryoftruth.me.uk/2014/09/03/do-goldfish-have-a-longer-attentionspan-than-american-internet-users/
https://snl.no/kravspesifikasjon%2FIT
https://lovdata.no/dokument/SF/forskrift/2013-06-21-732
http://no.wikipedia.org/wiki/Universell_utforming
http://www.w3.org/Translations/WCAG20-no/
69
Vedlegg A
Arbeidsplan
Oppgave
Innhold
Metoder
Prosjektstyring
Samarbeidskontrakt
Prosjektdagbok
Milepælsplan
Risikoplan
Kommunikasjon
Verktøy og hjelpemidler
Utviklingsmodell
Smidig metodikk
Use case
ER-modell
Analyse
Businesscase
Hva er dette konseptet
Anvendelsesområder
Hva eksisterer av produkter i dag
Hvem er kunder
Hvilke aktører er på markedet
Hvem bruker dette?
Hvorfor bruker de det
Hovedfunksjoner for systemet
70
Kravspesifikasjon
Hva som var planlagt i gruppen/oppdragsgiver
Funksjoner for bruker
Komplett kravspek i vedlegg
System design
Applikasjonen
hvorfor – business case,
businessmessig edge.
Hovedkonseptet
Raskt,
elegant,
brukervennlig,
salgbarhet ,
krever dynamisk oppdatering,
statistikk over tid og elementene
Web server
ikke spesielle krav til sikkerhet
enkel
må kunne håndtere sesjoner, huske hvem
som er inne på skjermbildet, flere bukere
cookies
dimensjoneringskriterie flere 1000 samtidige
brukere
sideskifte 4x/min
båndbredde ikke spesielle krav
Database
ER-modell
Lagre alle konkurranser, mange alternativer
Hvert alternativ har bare en konkurrent
71
En til mange relasjon
Tegne et skjema som viser hva som må gjøres
Alt 1 mongo/couch
Alt 2 SQEL – har de fra før – vurdere hva som
er raskest
Websider
Nettsider – prinsipper
Nettsidens struktur
Side struktur – liste opp alle og sketch mock
up
Use case beskrivelser
Applikasjonesdesign – dataflyt diagram
Database design
Beskrive Json dokumentet
som skal inn i databasen
Skisser
Evaluering - fordeler /ulemperved alternativ 1 og 2
Universell utforming
72
Implementering
Database
Hva er MongoDB og CouchDB
Hvorfor dokument og ikke relasjon?
Evaluering av arbeidet
Samarbeid i gruppe
Ide dugnad med eksterne
Eget arbeid gruppe/alene
Produktet
Konklusjon og forslag til videre arbeid
Vedlegg
73
Vedlegg B
Tabell 1: Risikomatrise
Konsekvens: Ubetydelig Liten Moderat Alvorlig
Svært
Sannsynlighet:
alvorlig
Liten
4,5
Middels
2
Stor
Svært stor
1
3
·
Grønt felt = Lav risiko à akseptabelt
·
Gult felt = Middels risiko à individuell vurdering
·
Rødt felt = Høy risiko à uakseptabelt
1. Sykdom: Sykdom blant gruppemedlemene over en fem måneders periode er nesten noe man må regne med. Det er derfor viktig å ha gode rutiner når det kommer til
kommunikasjon og deling av arbeid, slik at de andre på gruppen vet hva den personen som blir syk jobber med og enkelt kan ta over. Ved langtidssykdom vil konsekvensene bli større, men det samme gjelder også her.
2. Ny teknologi: I prosjekter der nye teknologier skal brukes vil det være hensiktsmessig å sette av en periode til fordypning eller budsjettere med litt ekstra tid. I noen
tilfeller kan de nye teknologiene være dårlig dokumentert og prosjektet kan stoppe
opp, for å forhindre dette vil det være lurt å se litt på teknologiene under planleggingsfasen.
74
3. Tidsmangel: Alle prosjekter vil på et eller annet tidspunkt oppleve at de burde hatt
mer tid. Det er derfor viktig å lage en realistisk framgangsplan og legge inn rikelig
med buffere slik at man har litt ekstra å gå på.
4. Tap av data: Hvis hele prosjektet blir borte så vil det selvfølgelig få katastrofale
konsekvenser. For å forhindre dette er det viktig å lagre ofte og på mange forskjellige
steder, hvis alle på gruppen har en oppdatert kopi av prosjektet og det ligger på gitlab
er sjansene for at alt forsvinner nærmest lik null.
5. Interne problemer: Interne problemer er veldig vanlig i gruppearbeider. De kan variere fra små uenigheter til store krangler og konsekvensene vil variere deretter. God
kommunikasjon vil virke forebyggende.
75
Vedlegg C
Prosjektskisse
Oslo, 2014
Prosjektskisse
Hovdeprosjekt i Anvendt Datateknologi ved Høgskolen i Oslo og
Akershus - Våren 2015
Cruntch!
Medlemmer
Alexander N. S. Storhaug, S180479
Mikkel B. Oddum, S189144
Aleksander Skodbo, S189107
Oppdragsgiver
Kyrre Begnum, Institutt for Informasjonsteknologi, HIOA
Epost:
[email protected]
Beskrivelse
I dette prosjektet skal vi lage et verktøy i form av en webside hvor brukere kan starte
en avstemming, hvor man skriver inn alternativene som så blir satt opp mot hverandre to og to, for å finne ut hva en gruppe mennesker liker. Videre kan denne brukeren dele avstemmingen med venner for å få de til å gå gjennom samme prosess med
to og to alternativer opp mot hverandre. Så vil en algoritme, som allerede er utviklet,
finne ut hvilket av alternativene brukeren foretrekker og tilslutt vil man ha en oversikt
som viser hva alle gruppen samlet foretrekker. Et av styrkene til Cruntch! er at den
analyserer hvilke alternativer som konsekvent taper over et annet, man får derfor et
mer nøyaktig liste.
76
Prinsippet kan overføres til mange forskjellige bruksområder, som f.eks å finne ut hva
en gruppe vil ha på pizzaen man skal bestille, hvilken film man skal se, eller til forskning. Oppdragsgiver har allerede laget en fungerende prototype i PHP, men denne
skal vi vidreutvikle og designe til å bli en elegant og brukervennlig tjeneste som er lett
å bruke. Tjenesten skal være en webside som også skal fungere på mobil, og det er
viktig at det er mulighet for oppskalering for å kunne ta i mot høy pågang. Github skal
brukes for versjonskontroll og for å lettere dele kode med oppdragsgiver for vidreutvikling. En opensource og skalerbar database, f.eks mongoDB eller couchDB, skal
brukes, men det er ikke bestemt hvilken. Moderne rammeverk skal brukes, f.eks NodeJS, men det er ikke bestemt hvilket.
77
Vedlegg D
Forprosjektrapport
Presentasjon
Tittel: Cruntch
Oppdragsgiver: Kyrre Begnum, HIOA
Oppgave: Videreutvikle en eksisterende prototype til en fungerende webtjeneste hvor
brukere kan lage og gjennomføre avstemninger i form av en turnering
Periode: 05.01.2015 - 26.05.2015
Gruppenummer: 8
Gruppemedlemmer:
Alexander N.S. Storhaug, s180479
Mikkel B. Oddum, s188144
Aleksander Skodbo, s189107
Morten Wedum, S182855
Gruppetalsmann: Aleksander Skodbo
Veilder: Thor E. Hasle
Prosjektside: bachelor.skodbo.no
Sammendrag:
Cruntch! er en løsning som kan brukes til å bestemme det mest populære i en liste
med elementer. Bruksområdene er varierte, og tjenesten kan brukes i alt fra vennegjenger til profesjonelle arbeidsgrupper. For å få til dette bruker Cruntch en cupalgoritme som setter to og to elementer opp mot hverandre. Vinnere og tapere fordeles og
kjemper mot hverandre, helt til man sitter igjen med en komplett rangering.
Løsningen skal fungere slik at brukere kan opprette og administrere sine cuper, og
dele dem med de personene de ønsker. Løsningen skal også være utviklet slik at den
fungerer sømløst på både stasjonære og mobile enheter. Løsningen skal utvikles ved
hjelp av HTML, CSS, CouchDB og Javascriptmoduler(NodeJS, ExpressJS, JSON).
Oppdragsgiver har ikke gitt noen krav om teknologi, utenom bruk av CouchDB og at
78
løsningen skal programmeres med det formål at den kan skaleres opp for kraftigere
pågang.
Dagens situasjon
Bakrunnen for Cruntch! er en idé oppdragsgiver hadde lyst til å sette ut i live. Han så
derfor på det som aktuelt at en bachelorgruppe kunne bruke denne ideen som sitt
prosjekt.
Det er laget en fungerende prototype av tjenesten. Denne er skrevet i PHP og veldig
lite CSS, som viser at konseptet fungerer.
Mål og rammebetingelser
Videreutvikle og designe en brukervennlig og elegant løsning basert på prototype
som arbeidsgiver allerede har laget. Arbeidsgiver ville at vi skulle bruke en skalerbar
database, hvor coutchDB har blitt gitt som eksempel, da han ønsker mulighet for at
tjenesten kan skaleres opp. Tjenesten vil bli skrevet i HTML, CSS og JavaScript. For
JavaScript vil vi bruke node.js, express.js og JSON. Vi ser ikke bort ifra at vi kommer
til å være borti jQuery også. For at tjenesten skal være rask vil vi bruke node.js sammen med express.js. Resten vil skrives i HTML og CSS. Arbeidsgiver har ikke gitt oss
noen krav til utseende, og vi har heller ikke bestemt oss for om vi skal bruke et CSSrammeverk eller skrive CSS’en selv. Algoritmen som brukes i prototypen skal også
brukes i det ferdige produktet. Med tanke på skalerbarhet ønsker arbeidsgiver også at
tjenesten skal kunne kjøres på flere servere. Arbeidsgiver ønsker også at vi bruker
Git for versjonskrontroll og Trello.com for prosjektstyring.
Løsninger/alternativer
Alternativ 1:
Løsningen er per dags dato skrevet i PHP og bruker MySQL database, denne fungerer fint. Vi kunne derfor kun fokusert på å lage en pen og brukervennlig løsning. Problemet med dette er at PHP ikke er raskt nok når denne tjenesten skal ha mange brukere og MySQL ikke er lett å skalere opp
Alternativ 2:
Skrive webtjenesten utifra webprogrameringsspråk og tjenester som arbeidsgiver
ønsker og har foreslått. Dette innebærer Node og CoutchDB, resten velger vi selv.
Dette vil gi arbeidsgiveren en rask og skalerbar tjeneste.
79
Analyse av virkninger
Dersom man benytter seg av alternativ 1, så vil man ikke få den løsningen oppdragsgiver ønsker seg. Selv om det vil være en mulig løsning på oppgaven, så vil den ikke
være aktuell. Det er ikke bare på grunn av løsningens behov, men også oppragsgivers ønske av teknologi. Alternativ 2 er for oss den eneste akutelle løsningen, da vi
føler at denne vil gi oss muligheten til å utvikle løsningen vi ønsker, med mulighet for
oppskaler om det blir behov for å takle større pågang på nettsiden. Teknologien vi har
valgt gir oss nettopp denne løsningen, samtidig som vi kan lage en god og responsiv
nettside.
Vedlegg: Fremdriftsplan
Fremdriftsplan
NB! Merk at denne planen ikke er endelig og at endringer kan forekomme
Faser
Varighet
Beskrivelse
Prosjektopp-
01.01.2015 Møter med arbeidsgiver, veileder og gruppemedlemmer
start
23.01.2015 skal gjennomføres. Prosjektskisse, forprosjekt og fremdriftsplan skal planlegges og ferdigstilles.
Innsiktsfasen
26.01.2015 Innsiktsfasen av prosjektet tar for seg kartlegging av de
08.02.2015 nøyaktige rammene for software siden av prosjektet.
Planlegging av sprint 1
Iterasjon 1
09.02.2015 Sprint 1 utføres
Første sprint
22.02.2015 Planlegging av sprint 2
Iterasjon 2
23.02.2015 Sprint 2 utføres
Brukertesting
08.03.2015 Brukertesting av grensesnitt
1
Planlegging av sprint 3
Andre sprint
Iterasjon 3
09.03.2015 Sprint 3 utføres
Tredje sprint
22.03.2015 Planlegging av sprint 4
80
Iterasjon 4
06.04.2015 Sprint 4 utføres
Brukertesting
19.04.2015 Brukertesting av endringer gjort i brukergrensesnitt
2
Planlegging av sprint 5
Fjerde sprint
Iterasjon 5
20.04.2015 Sprint 5 utføres
Femte sprint
03.05.2015 Planlegging av sprint 6
Iterasjon 6
04.05.2015 Sprint 6 utføres
Sjette sprint
18.05.2015
Ferdigstillelse
18.05.2015 Ferdigstillelse av prosjektet
26.05.2015
Leveranse
26.05.2015 Endelige datoen for leveranse av bachelorprosjektet
Presentasjon
06.2015
Muntlig presentasjon av bachelorprosjektet
11.06.2015
Figur 17: Milepælsplan
81
82