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, morten.wedum@gmail.com 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: kyrre.begnum@hioa.no 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
© Copyright 2024