3 Prosessdokumentasjon

Transkript

1 3 Prosessdokumentasjon Vote4Music Gruppe 3 Bachelorprosjekt ved Høgskolen i Oslo og Akershus Oslo, vår

2 3.2 Forord Planlegging og metode Forløp Arbeidsmetodikk Smidig utvikling Scrum Vår erfaring med Scrum Samarbeid med veiledere Styringsdokumenter og arbeidsforhold Fremdriftsplan Risikorapporter Arbeidsforhold Valg av teknologi Utviklingsteknologi Test-rammeverk Utviklingsverktøy Jira Agile Git med Github Øvrige verktøy Kravspesifikasjon og dens rolle Kravspesifikasjon Rammekrav Samsvar mellom endelig produkt og kravspesifikasjon Vår erfaring med kravspesifikasjon Utviklingsprosessen Sprinter Presentasjon for oppdragsgiver Presentasjon Utfordringer og løsninger Lære seg ny teknologi Begrensninger hos Spotify Oppdatering hos Spotify Testing

3 Applikasjonen på mobil Socket.IO Kall mot Soundcloud og Spotify Spotify access/refresh Token Design Målgruppe Brukergrensesnitt Farger, språk, størrelse Skalering for mobil og tablets Universell utforming Avsluttende del Ord fra oppdragsgiver Samarbeid i gruppen Læringsutbytte Produktet Videreutvikling Konklusjon

4 3.1 Forord I denne dokumentasjonen vil prosessen bak utviklingen av applikasjonen Vote4Music beskrives. Hensikten med dette dokumentet er å gi leseren innblikk i hvordan arbeidet har foregått fra start til slutt, hvilke utfordringer vi har hatt underveis og valgene som er tatt. Denne rapporten er ment for sensor og andre som vil ha et innblikk i hvordan prosessen har vært. Leseren bør ha lest gjennom innledning til sluttrapporten for å ha en oversikt over hva prosjektet går ut på. Dokumentet består av fire deler: Planlegging og metode o Planlegging o Arbeidsmetodikk o Samarbeid med veiledere o Styringsdokumenter og arbeidsforhold o Utviklingsverktøy og teknologier Kravspesifikasjon og dens rolle o Endringer i kravspesifikasjon underveis o Betydningen av kravspesifikasjon o Samsvar mellom kravspesifikasjon og endelig løsning Utviklingsprosessen o Målgruppe og behov o Prosjektets faser o Utfordringer og løsninger o Implementering av funksjonalitet Avsluttende del o Læringsutbytte o Oppsummering og konklusjoner o Nytteverdi av produkt 67

5 3.2 Planlegging og metode I denne delen vil vi beskrive hvordan planleggingen av prosjektet har fungert. Vi vil også ta for oss hvordan veilederne har hjulpet oss, og hvordan kommunikasjonen har fungert både innad i gruppen samt med oppdragsgiver og veiledere. Det å jobbe smidig var et av kravene fra oppdragsgiver, så vi vil også ta for oss hvordan dette har påvirket vårt arbeid. Videre vil vi diskutere ny teknologi og utviklingsverktøy som er blitt tatt i bruk, samt begrunnelser for de valg vi har gjort. 3.3 Forløp Da vi fikk tilbud fra Accenture om å skrive oppgave for dem, så var det ikke noen uenigheter i gruppen om at dette var en bedrift vi hadde lyst til å skrive for. Accenture ga oss mulighet til å komme med egne ideer samtidig som de ga oss et hefte med forskjellige oppgaver som vi kunne bruke. Opprinnelig hadde vi lyst til å komme med egne ideer, men ble raskt motivert for å jobbe med en av oppgavene Accenture foreslo Jukebox App, nå under navnet Vote4Music. Grunnen til at vi valgte denne oppgaven var fordi vi så behovet for funksjonaliteten denne applikasjonen ville ha det var en applikasjon vi selv kunne tenkt oss å bruke, og fordi det var spennende og utfordrende teknologi som ville bli brukt i utviklingen. Oppstartsdag på prosjektet var på kontorene til Accenture. Dette var vårt første møte med veilederne vi hadde blitt tildelt, og vi diskuterte hvordan vi skulle begynne prosjektet, hva slags teknologi det var viktig å lese seg opp på og andre praktiske detaljer rundt det å skrive en bacheloroppgave. 3.4 Arbeidsmetodikk Det var et krav fra Accenture sin side at vi skulle benytte oss av smidig utvikling som arbeidsmodell. Her vil vi beskrive hva det vil si å jobbe smidig, nærmere bestemt med Scrum som utvklingsmetodikk, og hvordan dette har påvirket vår arbeidsprosess. Vi hadde ikke noe mer enn teoretisk kunnskap om Scrum, men fikk et innføringskurs hos Accenture av to personer som begge er scrum-master og har lang erfaring med å jobbe i scrum team. 68

6 3.4.1 Smidig utvikling Smidig utvikling har over de siste årene blitt en veldig populær arbeidsmodell i systemutvikling og er et alternativ til tradisjonell prosjektstyring. Modellen fokuserer på det å kunne tilpasse seg endringer raskt og å arbeide iterativt ettersom krav og løsninger utvikler seg gjennom prosjektperioden. Selv om det var et krav at vi skulle jobbe smidig, er nok dette modellen vi hadde valgt uansett. Prosjektperioden har vært preget av endringer i hvordan webapplikasjonen skal utvikles og hvilken funksjonalitet som skal være med, og vi er derfor glad for at vi ikke har brukt tid på å utvikle en langsiktig plan som en ville gjort i en typisk fossefall-metodikk. Det smidige manifestet forteller oss følgende: Personer og samspill fremfor prosesser og verktøy Programvare som virker fremfor omfattende dokumentasjon Samarbeid med kunden fremfor kontraktsforhandlinger Å reagere på endringer fremfor å følge en plan Dette betyr ikke at punktene til høyre ikke er verdsatt i smidig utvikling, men at punktene til venstre har en høyere prioritering Scrum De involverte i et slikt prosjekt kalles et scrum-team. Scrum-teamet består av produkteier, Scrum-master og utviklingsteam. I vårt tilfelle vil Accenture være produkteier, og vår gruppe stå for utviklingsteam hvor en av oss i gruppen tar ansvaret for å være Scrum-master. Et vanlig utviklingsteam består som regel av 3-9 personer. I noen tilfeller er det også flere medlemmer, men blir det for mange medlemmer deles det som oftest opp i flere team. Målene i prosjektet kan bli oppfylt ved å fullføre små konkrete produktfunksjoner i iterasjoner(sprinter) på 1-4 uker. De funksjonene man skal lage legges i en liste som kalles product backlog. Oppgavene i backlogen skal ligge i en prioritert rekkefølge, noe produkteier har ansvar for å holde oppdatert. I vårt tilfellet har vi brukt Jira til å holde oversikt over backlog. Vi har valgt å ha en sprintvarighet på 2 uker, og møte med produkteier etter hver sprint. Ettersom det er en såpass kort periode å utvikle på, ville det blitt for få sprinter om vi skulle 69

7 hatt en vanlig varighet på 4 uker. Vi vurderte til og med å ha varighet på 1 uke, men bestemte oss for å droppe det da det blir vanskelig å gjøre oppgavene så små at en alltid har fremgang å vise til etter en ukes arbeid. Underveis i sprinten holdes daglige stand-up møter med utviklingsteamet som ledes av scrummaster. Vi har i vår gruppe byttet på å være scrum-master for at alle skulle få erfaring med dette. På slutten av hver sprint demonstreres den funksjonaliteten som er lagt til for en gruppe interessenter, i vårt tilfelle for veilederne hos Accenture. Vi har så gjennomført review møte og retrospective møte. I review møtene diskuterte vi hva som hadde gått bra og dårlig i sprinten og kikket på hva vi hadde definert i retrospective møtene fra forrige sprint som burde forbedres. Retrospective møte dreide seg så om hva teamet bør bli flinkere på i neste sprint Vår erfaring med Scrum Mange av aspektene ved det å jobbe smidig kommer ganske naturlig når en jobber så tett på hverandre som det vi gjorde. Scrum har hjulpet oss veldig med det å ha en oversikt over hva som skal gjøres, og til å reagere raskt på hindringer. Det har til tider føltes overflødig å ha et stand-up møte hver dag ettersom vi jobbet så tett på hverandre, men vi har også sett nytten av det å ha full kontroll over hva alle på gruppen gjør og hvordan fremgangen til hver enkelt går. Det at Accenture har kommet med ønsker til hvilken funksjonalitet som skal være med og oppført seg som en produkteier, har hjulpet veldig med å få en mer virkelighetsnær tilnærming av Scrum og smidig utvikling. 3.5 Samarbeid med veiledere Gjennom prosessen har vi hatt kontinuerlig kontakt med våre veiledere fra Accenture. Vi har hatt møte med dem etter hver sprint, og hatt kontakt ellers via /lync. De har kommet med tilbakemeldinger på arbeid som er gjort, og hva de ønsker vi skal fokusere på i neste sprint. Det har vært verdifullt å ha kontakt med veiledere som begge har vært igjennom et bachelorprosjekt, og har arbeidserfaring. Deres tilbakemeldinger har vært med på å gi oss et større overblikk over prosjektet og hjulpet oss å fokusere på de viktige og riktige tingene. 70

8 Vi har i tillegg blitt tildelt intern veileder Tor-Morten Grønli, som vi har hatt møter med fra tid til annen. På disse møtene ble fremgangen i utviklingen samt dokumentasjonen diskutert, og vi har fått råd og tips om hvilken teknologi vi bør kikke på når vi har stått fast. Veilederne har ikke blitt brukt så mye til tekniske spørsmål, men mer som hjelp til å peke oss i riktig retning hvis vi har stått fast og til generelle spørsmål rundt hva som er viktig å fokusere på i et bachelorprosjekt. Vi sitter igjen med et godt inntrykk av veilederne våre etter et vellykket samarbeid, og er veldig fornøyd med hvor tilgjengelig de har vært. 3.6 Styringsdokumenter og arbeidsforhold Vi har gjennom hele prosjektperioden laget risikorapporter for hver sprint, dokumentert Review møter, Retrospective møter, valg som er tatt samt logget alt arbeid som er gjort Fremdriftsplan Etter vi hadde satt oss inn i utviklingsmetodikk og valgt teknologier og verktøy, så arbeidet vi med å utvikle en fremdriftsplan. Vi satt frist for å bli ferdige med utviklingen til 1. Mai, og bestemte oss for at ingenting annet enn design skulle bli implementert i applikasjonen etter denne datoen. Når utviklingen var ferdig skulle resten av tiden bli brukt på dokumentasjon (og design hvis tiden strakk til), og vi satt frist for ferdigstilt sluttrapport til å være 22. Mai, 4 dager før innleveringsfrist. Alle medlemmene på gruppen hadde et fag ved siden av bachelorprosjektet. Vi satt derfor kjernetid som skulle gå med til prosjektet til å være syv-timers dager på Mandager, Torsdager og Fredager. Det har vært arbeidet mer enn dette, men disse dagene var minstekravet av arbeidstimer vi satt til oss selv. Vi kom frem til at med den tiden vi hadde til rådighet ville det bli syv sprinter, hver på to uker. De to første sprintene ville hovedsaklig gå med på å lese seg opp på all teknologi som skulle brukes, men også til å få ferdigstilt en prototype en enkel nettside som bruker valgt teknologi og kommuniserer med Spotify sitt web-api. Resten av sprintene skulle basere seg på oppgaver hentet fra backloggen. 71

9 3.6.2 Risikorapporter Vi har hatt en risikorapport for hver sprint hvor vi har listet opp oppgavene som skulle gjøres i Figur 32: Accenture sitt hovedkontor på Fornebu. sprinten og estimert risikoen for at noe går galt, for så å liste ut eventuelle konsekvenser og tiltak som måtte iverksettes. Vi lagde også en risikorapport i begynnelsen av prosjektet som skulle dekke hele prosjektperioden. Dette har hjulpet oss med å være forberedt på det meste som kan skje galt, og hatt klare tiltak til hva som måtte gjøres. Alle risikorapportene er lagt til som vedlegg. De største risikoene gjennom prosjektperioden har vært å møte på begrensninger i web API ene til SoundCloud og Spotify som kunne føre til at ønsket funksjonalitet ikke ble implementert. Vi har hatt dialog med veiledere fra Accenture og utviklere i Spotify for å redusere risikoen for stopp i utviklingen, og ha alternative løsninger/fremgangsmåter. Selv om det har vært en trygghet med risikorapportene, så har vi fått erfare at en ikke kan ta høyde for alt. Midt i prosjektperioden kom Spotify med oppdateringer som gjorde at mesteparten av arbeidet vi hadde gjort ikke fungerte lenger, og vi måtte starte på nytt med alternative løsninger. Resultatet ble en god løsning med SoundCloud, mens vi fikk en alternativ og mindre brukervennlig løsning med Spotify. Dette er beskrevet mer detaljert i Utfordringer og løsninger i dette dokumentet Arbeidsforhold Vi har for det meste jobbet på Høgskolen i Oslo og Akershus eller på Accenture s hovedkontor. Det har vært litt avhengig av hvor og når vi har møter, eller om noen på gruppen skal dra tidligere for å jobbe. På Høgskolen har vi stort sett benyttet oss av grupperommene i 4.etg i Pilestredet Valg av teknologi Utviklingsteknologi Da vi startet prosjektet var HTML5, CSS3 og Node.js de første teknologiene som ble fastsatt. HTML5 og CSS3 var et krav fra Accenture sin side, mens Node.js var en anbefaling. Eksemplene som ble gitt på Spotify sitt web API brukte Node.js og Javascript, og vi så det derfor som hensiktsmessig å bruke dette. Vi begynte deretter å lete etter teknologi for de andre delene av systemet og etter noe som fungerte bra sammen med Node.js. Etter undersøkelser og anbefalinger fra veiledere fant vi ut at det var en veldig populær stack med 72

10 teknologier som brukte Node.js kalt Mean stack, og valgte å gå for denne. Teknologiene som denne stacken består av er MongoDB, Express JS, Angular JS, og Node JS. AngularJS var den eneste teknologien som gruppen hadde noe erfaring i fra før av, hvor to av gruppemedlemmene hadde et fag på HiOA kalt Webapplikasjoner foregående semester Test-rammeverk Når vi skulle velge test-rammerverk var vi nøye på å finne det rammeverket som passet best sammen med MEAN-stack teknologien. Siden vi var relativt nye til testing var det også viktig at rammeverket var godt dokumentert. Vi kom frem til at test-rammeverkene som var mest hensiktsmessig for oss å bruke var Mocha eller Jasmine. Begge rammeverkene var godt egnet til å teste javascript og til å håndtere asynkrone kall. Grunnen til at vi endte opp med å velge Mocha var fordi det var et nyere rammerverk, bygd spesifikt til å teste Node.js. 3.8 Utviklingsverktøy Vi vil her beskrive hvilke verktøy som er blitt brukt til prosjektstyring og utvikling Jira Agile Figur 33: Oversiktsbilde over sprint 5. Jira Agile er en nettbasert løsning for å styre smidige prosjekter. Det gir oss en plattform for å styre prosjektet på best mulig måte i henhold til Scrum. Her kan en lage og estimere userstories som legges i backlog, opprette sprinter, visualisere fremgangen ved hjelp av burndown chart, logge timer og mye mer. Ingen på gruppen hadde vært innom Jira før, men ble tatt i bruk etter anbefalinger fra veilederne fra Accenture. Veilederne hadde lisenser som vi kunne bruke, og de ga oss et kort innføringskurs i hvordan programmet skulle brukes. 73

11 Backlogen har under hele prosjektet blitt fortløpende oppdatert så snart nye funksjoner eller oppgaver har kommet frem. Burndown chart er en grafisk fremstilling av gjenstående arbeid vs gjenstående tid, derfor er estimering og logging av timer essensielle aspekter ved bruk av Jira. Det å skulle estimere hvor lang tid vi tror vi bruker på hver oppgave har vært et nytt og utfordrende aspekt ved prosjektutvikling for oss. Ved bruk av Jira har vi fått en grafisk fremstilling av burndown chart for hver sprint. De første sprintene ble den ikke seende veldig bra ut grunnet dårlig estimering og uventede hindere. Estimering var noe vi forbedret oss veldig på ila prosjektperioden, noe sammenligningene mellom bildene av burndown chart fra sprint 1 og sprint 3 tydelig viser. Figur 34: Burndown chart sprint 1 Figur 35: Burndown chart sprint 3 I en optimal burndown chart skal den røde linjen følge den grå. Figur 34 og 35 viser en sammenligning av hvordan burndown charten så ut i sprint 1 vs sprint 3. 74

12 Vår erfaring med Jira Det at vi har måttet dele oppgaver opp i mindre biter enn ved tidligere prosjekter har hjulpet oss å måle fremgang og økt motivasjon og mestringsfølelse. Jira har vært et utmerket verktøy for å holde oversikt over prosjektet og hvilke arbeidsoppgaver som står på agendaen Git med Github Figur 36: Bruk av GitHub 6. Git er et versjonskontrollsystem som har gitt oss god orden og oversikt over prosjektet og endringer som har blitt gjort. Vi fikk tildelt gratis privat repositorie av Github, noe som var nødvendig ettersom vi har private nøkler for å kommunisere med Web-Api et til Spotify i koden vår. Ingen på gruppen har brukt GIT versjonskontrollsystem i tidligere prosjekter, så vi fikk et innføringskurs av Morten, vår veileder fra Accenture. Vi er veldig fornøyd over hvor mye enklere dette har gjort utviklingen vår. Det har vært tider hvor alle på gruppen jobber med forskjellige oppgaver men mot de eksakt samme filene, noe som ville vært en betydelig større utfordring hadde det ikke vært for Git og Github. Ingen på gruppen kommer nok til å jobbe med et prosjekt uten versjonskontrollsystem igjen Øvrige verktøy Øvrige verktøy som er brukt finnes i kravspesifikasjon - se vedlegg. 3.9 Kravspesifikasjon og dens rolle Her vil vi beskrive hvilken rolle kravspesifikasjonen har spilt i utviklingen. For å lese kravspesifikasjon - se vedlegg

13 3.9.1 Kravspesifikasjon Funksjonalitet og krav som er med i kravspesifikasjon ble hentet fra prosjektskisse gitt av Accenture. Det ble også tatt med funksjonalitet utover dette i samarbeid med veilederene. Første utkast av kravspesifikasjonen skulle fungere som et grunnleggende dokument for hvilke krav vi skulle implementere i backlogen på Jira. Backlogen har vært bygd opp slik at den består av overordnede krav fra Kravspesifikasjon, og oppgaver/issues som knyttes til disse. Oppdateringer underveis ville bli direkte implementert i backlogen. Kravspesifikasjonen har naturligvis endret seg en del underveis i prosjektet, spesielt med tanke på hvordan vi måtte gjøre om store deler av applikasjonen midt i prosjekt perioden på grunn av oppdateringer i Spotify. Det at vi har jobbet smidig og hele tiden tatt imot ønsker fra oppdragsgiver samt kommet med egne ideer, har også gjort at kravspesifikasjonen har vært under kontinuerlige endringer Rammekrav Vi stod ganske fritt til å utvikle oppgaven slik vi ville, både med tanke på teknologivalg og ideer til selve applikasjonen. De eneste kravene fra Accenture var at front end skulle være HTML5 og CSS3, mens de anbefalte Node.js back-end men her stod vi fritt til å velge så lenge det var en utbredt og robust teknologi. Øvrige krav fra Accenture var at det skulle brukes Scrum som arbeidsmetodikk, med mindre vi la frem gode argumenter for noe annet Samsvar mellom endelig produkt og kravspesifikasjon Til tross for omstrukturering i applikasjonen underveis, har det endelige produktet nesten alt av hva den opprinnelige kravspesifikasjonen ber om. Punkter som ikke kom med er følgende: Arrangør skal kunne sette restriksjoner for hvor mange sanger en gjest kan legge til Dette punktet ble nedprioritert da det ble tidkrevende og ikke var en essensiell funksjon. Om arrangøren er misfornøyd med antall sanger som blir lagt til, så er det allikevel mulighet for å fjerne sanger manuelt. Arrangør skal kunne sette restriksjoner for hvor mange sanger en gjest kan stemme på Dette punktet er delvis implementert. Arrangør kan ikke sette en spesifikk grense på antall sanger en gjest kan stemme på, men kan slå av stemmemuligheter. Arrangør skal kunne fjerne sanger i en periode fra spillelisten 76

14 Meningen med dette punktet var at arrangøren skulle kunne fjerne muligheten for en sang å bli lagt til. Dette ble komplisert i tillegg til at det er en funksjon som er vanskelig å vite om hadde vært populær eller ikke. Arrangøren har dog mulighet til å fjerne sanger manuelt om det er sanger i spillelisten som ønskes vekk. En annen grunn til at de to første funksjonene ble nedprioritert er at det ville krevd en bruker på gjest for å fungere optimalt, noe som går imot konseptet om å holde applikasjonen enkel og intuitiv. Punkter som kom med, men ikke var beskrevet i den opprinnelige kravspesifikasjonen: Spillelisten til et Spotify-Arrangement blir lagret på arrangørens Spotify konto Spillelisten med navn Vote4Music:dagens dato blir lagret på arrangørens Spotify konto. Enkel å slette hvis bruker ikke vil beholde den. Arrangør kan tillatte fjernstyring av arrangementet Ved at arrangøren tillatter Remote access, kan han selv eller andre fjernstyre arrangementet med en unik kode. Dette er nyttig hvis arrangør vil låse avspillingsenhet, men ha mulighet til å styre arrangementet fra en annen enhet. Arrangør kan stenge muligheten for å stemme på sanger Hvis arrangør ønsker at sangene skal bli spilt av i den rekkefølgen de blir lagt til, så kan muligheten for å stemme slås av. Arrangør kan starte et Spotify spilleliste på nytt Hvis arrangør av et Spotify Arrangement ønsker å starte en ny spilleliste gjøres dette ved å trykke på Reset Playlist. Arrangør skal kunne åpne en visningsside Hvis arrangør av et SoundCloud arrangement har en skjerm i et lokale og vil vise hvilke sanger som er i spillelisten, arrangement kode og hva som spilles av, så kan det åpnes en forenklet visningsside som ikke viser søkebar og instillinger Vår erfaring med kravspesifikasjon Kravspesifikasjonen som ble utarbeidet i starten var veldig nyttig når vi skulle sette opp en backlog i Jira. Vi overførte punktene til backlogen og delte opp hvert krav i så små oppgaver som mulig. Endringer underveis har blitt gjort i backlogen, så en kan si at backlogen har fungert som en kravspesifikasjon ettersom både gruppen og oppdragsgiver har hatt tilgang til 77

15 denne. Kravspesifikasjonen har hjulpet mye i planlegging av prosjektet og det å holde seg til de grunnleggende oppgavene før nye og ikke-essensielle funksjoner blir utviklet Utviklingsprosessen I denne delen vil vi beskrive de forskjellige fasene i utviklingen, og hvordan vi har taklet de faglige utfordringene. Det vil redegjøres hvordan forskjellig funksjonalitet er implementert. Vi vil ta for oss hvordan vi har løst utfordringene og forskjellige valg som måtte tas underveis Sprinter Ettersom vi har jobbet sprintvis vil det være hensiktsmessig å utrede om de forskjellige fasene i prosjektet ved å beskrive hva som er blitt gjort i hver sprint. De forskjellige utfordringene vi har møtt underveis vil bli beskrevet. Vi startet prosjektet med en test-sprint, hvor vi skulle gjøre oss kjent med Jira og det å arbeide med scrum før vi skulle starte Sprint 1 med en utviklet backlog sammen med våre veiledere Sprint 0 / Test-sprint Tiden frem til dette hadde vært benyttet på ferdigstilling av forprosjektrapport og kravspesifikasjon samt å lese seg opp på teknologi. Bakgrunnen for en test sprint var at vi ikke hadde hatt scrum-kurset hos Accenture(kurset ble holdt i løpet av denne sprinten) eller en ferdig backlog. Vi ble derfor enig med veilederene våre om å bruke sprinten til å gjøre oss kjent med Jira, og implementere Scrum på en best mulig måte. Med Nodejs, Express og MongoDB allerede valgt måtte vi bestemme oss for hvilket språk vi skulle bruke på klient side. Vi hadde opprinnelig startet utvikling i Handlebars, men valgte å gå for AngularJS etter prat med veileder fra HiOA og undersøkelse om hvilke teknologistacker som fungerer best. I løpet av denne sprinten hadde vi fått opp en liten prototype hvor en kunne søke og hente ut sanger i nettleseren via Spotify sitt web API og satt opp en mongodb database Sprint

16 Figur 37: Burndown chart sprint 1. I denne sprinten fikk vi introduksjonskurs i versjonkontrollsystemet Git av Morten, en av våre veiledere hos Accenture, og tatt det i bruk. Denne sprinten ble det masse oppgaver som ikke ble gjort grunnet en uventet presentasjon for styringsgruppen til Accenture. Vi visste at vi skulle ha to presentasjoner for dem i løpet av semesteret, men ikke noe faststemt dato. Da vi fikk beskjed en snau uke i forveien, så gikk mesteparten av tiden bort til forberedelse av presentasjon. Backlog ble ferdigstilt så langt det lot seg gjøre. I tillegg ble de 2 første sprintene mye brukt til å finne en løsning på en essensiell funksjon i programmet; at neste sang i spilleliste automatisk blir spilt av når en sang er ferdig. Vi fant tidlig en løsning, men vi var i tvil om dette var den mest optimale løsningen. Dette ble løst med å gjøre seg skikkelig kjent med Spotify sitt web api og kommunikasjon med utviklerene i Spotify via deres forum. Her er et utsnitt av kommunikasjonen vi hadde med dem: Christian Hunstad (Vote4Music): Staying tuned for this! May be asking the same question here, but is there any way of getting the current "time" the player is at? (Interested in finding out how much time left of a song). Andy Smith (Spotify Mod): The Web API isn't connected to any player, so there's no way for it to know the playback progress. If you're a fan of super-hacks, and providing you are using the desktop client to play tracks, you could trigger playback by opening a spotify:track URI (which begins playback in the client) and simultaneously start a javascript timer. The API returns the duration of a track in 79

17 milliseconds, so you can calculate a reasonable guess of how much of the track has passed/is left to play. Not super accurate or reliable (I wouldn't recommend it for anything other than playing around), but that's one way! Metoden Spotify moderatoren foreslår her, var en vi allerede brukte. Som en kan se av svaret så er det ikke en optimal løsning, men den eneste måten med mindre en ville bruke en metode som krever at en spilleliste blir opprettet hos bruker og som kan bruke opptil ti minutter til å oppdatere spillelisten. For å se all kommunikasjon mellom Spotify og oss - se vedlegg Sprint Figur 38: Burndown chart sprint 2 Sprint 2 var den første sprinten hvor vi følte at vi fikk jobbet skikkelig med de planlagte oppgavene og hvor estimering ble ganske korrekt, noe som kan ses gjennom forbedring av burndown chart fra sprint 1 til sprint 2. Fremgangen i prosjektet var mye bedre enn tidligere på alle områder; utvikling, dokumentasjon og å følge Scrum punktvis. De største oppgavene som ble fullført denne sprinten var å lage innlogging via Spotify og håndtering av session (gjøre det mulig med unike rom for forskjellige arrangementer). 80

18 Å lage innlogging via Spotify ble mer utfordrende enn hva vi først hadde forventet. Å håndtere flyten i alt som skulle skje var relativt komplisert, men det største problemet var å tillate cross-origin requests som er begrenset grunnet Same-origin policy. Vi leste oss også opp på testing i denne sprinten og vurderte hvilke test-rammeverk som skulle brukes Sprint Figur 39: Burndown chart sprint 3. Sprint 3 skulle vise seg å bli den mest utfordrende sprinten i løpet av prosjekt perioden. Første uken gikk veldig bra og fremgangen var god. Vi klarte å opprette rom og styre aksess til forskjellige rom ved hjelp av generert kode. Applikasjonen begynte å ta form ved stemmefunksjoner, restriksjoner på å legge til samme sang, egne start og stopp knapper osv kom en stor oppdatering i Spotify som satt applikasjonen vår langt tilbake. Les mer om dette under Utfordringer og løsninger - Oppdatering hos Spotify. I denne sprinten fikk vi oppleve mange aspekter av det å jobbe med større prosjekter. Vi gikk fra å ha en kjempegod fremgang til at applikasjonen ble mer eller mindre ubrukelig, for så å ta raske valg og utvikle en alternativ løsning raskere enn noen av oss kunne håpet på da problemene oppsto. Sett i retrospekt er vi veldig glad for at vi tok et raskt valg om å forkaste den første versjonen og starte utviklingen med to alternative løsninger, ettersom feilene som fulgte med oppdateringen i Spotify fortsatt ikke er fikset. 81

19 Sprint Figur 40: Burndown chart sprint 4. Til tross for alle utfordringene i forrige sprint, så hadde vi en alternativ løsning i SoundCloud som var kommet så langt i utviklingen som var planlagt. Forskjellen var at vi nå hadde to deler å fokusere på, selv om vi var innstilt på at Spotify delen ville komme som en bonus om vi fikk til en god løsning. I denne sprinten begynte vi med implementering av Socket IO som skulle vise seg å være komplisert og tidkrevende. En alternativ løsning i Spotify var under utvikling. Vi skulle nå bruke Spotify Play button, som essensielt er en mini spiller i nettleseren som kobler seg opp mot en spilleliste i brukerens Spotify. I tillegg ble feilhåndtering implementert i denne sprinten. Dette var et par enkle funksjoner beskrevet i dokumentasjonen til Express som logger feilmeldinger i en tekstfil. Vi la også til funksjoner som sørget for stemmerestriksjoner ved hjelp av cookies. En bruker kunne ikke lenger legge til en sang som allerede var i spillelisten eller stemme på samme sang flere ganger. 82

20 Sprint Figur 41: Burndown char sprint 5. I denne sprinten begynte vi å fokusere mer på testing og rapportskriving. Webapplikasjonen nærmet seg ferdig, og det var kun små funksjoner og design som gjensto. Testing har vært komplisert og tidkrevende, og gått på rundgang hos alle gruppemedlemmene. Ettersom vi har lagd noe nytt og unikt, så har det vært veldig vanskelig å finne eksempler på nettet som kan videreføres til deler av vårt program. Dette ga tydelig utslag på burndown charten, da vi ikke klarte å estimert tiden til testingen godt nok. Vi har i denne sprinten lastet opp en Beta versjon på nettsiden Vote4Music.com.Vi hadde ikke fått testet applikasjonen grundig på mobil før den var tilgjengelig på nett, og oppdaget noen få problemer. På grunn av restriksjoner på mobile enheter og bugs hos Spotify, vil ikke arrangering (dvs avspilling av musikk) være optimalt på mobile enheter. Å bli med på arrangement for å legge til sanger og stemme på sanger fungerer som det skal, så vi har valgt å sette et krav om at arrangør må bruke en bærbar/stasjonær datamaskin Sprint

21 Figur 42: Burndown chart sprint 6. I denne sprinten ville det bli fokusert mest på rapportskriving. Selv om det er blitt gjort små endringer i applikasjonen, så klarte vi å overholde fristen for at det ikke skulle legges til mer funksjonalitet etter 1 mai. I denne sprinten har vi fikset små bugs i Socket IO og lagt til en alert når sanger blir lagt til i spillelisten for å gjøre applikasjonen mer intuitiv. Vi har laget en visningsside etter ønske fra Accenture som kan bli brukt til å vise arrangementinfo på skjermer i lokalet hvor det holdes et arrangement. Designet på nettsiden er blitt gjort om og forbedret i denne sprinten. Tidligere design hadde store bilder som kunne være vanskelig å gjenkjenne som knapper, mens nå er knappene kun bilder med tekst som henger bra sammen med ny logo på siden. Vi har ferdigstilt en disposisjon av sluttrapporten som vi har gått igjennom med intern veileder. Her fikk vi nyttig feedback for hvilke punkter som bør legges til og fjernes. Prosessrapport er blitt sendt til samme veileder for tilbakemelding, men vi fikk ikke tilbakemelding i denne sprinten. Kravspesifikasjon og installasjonsveiledning er også klargjort for å sendes til veileder for å få tilbakemelding. Vi har ikke møtt på noen store utfordringer denne sprinten, og fått gjort alt som var planlagt å gjøre Sprint Denne sprinten var det fullt ut fokus på å få ferdigsilt sluttrapport.vi har fått hjelp både av intern veileder og Tor Krattebøl til å komme med tilbakemeldinger på forskjellige utkast av rapporten. 84

22 3.11 Presentasjon for oppdragsgiver I løpetet prosjekt perioden var det planlagt to presentasjoner for styringsgruppen i Accenture. Den første var relativt tidlig i semesteret hvor vi skulle fortelle om hvordan vi hadde kommet igang med arbeidet og pitche prosjektet. Den siste skulle være på slutten av semesteret og hjelpe som forberedelse for den avsluttende presentasjonen på Høgskolen. Den siste presentasjonen for Accenture vil være 29.05, etter at denne rapporten er ferdig og levert Presentasjon Vi fikk beskjed ca en uke i forveien at den første presentasjonen skulle være Vi brukte mesteparten av arbeidstiden vi hadde satt av til prosjektet på å forberede oss. Det ville gå utover oppgaver i sprinten, men vi ville få mest mulig øving og nyttige kommentarer frem mot senere presentasjoner. Presentasjonen varte omtrentlig 20 minutter hvor vi forklarte hensikten med applikasjonen, teknologistack, arbeidsmetodikk, styringsdokumenter og en video-demo som vi hadde lagd. Etterpå fikk vi spørsmål og kommentarer om hva som kunne forbedres av tilskuerene. Tilbakemeldingene var stort sett bra og styringsgruppen syntes det virket som et spennende prosjekt som vi hadde kommet godt igang med. Frem mot neste presentasjon kunne vi bli bedre på følgende punkter: - Mer illustrasjoner i oppbyggingen av presentasjonen og forklaring av problemstilling. - Lage presentasjon mer forretningsrettet (fortelle om hvordan man kan tjene på dette produktet). - Vise backlog, planer og features. Hvilke funksjoner kom med og hvilke kom ikke med. - Presenter problemstillingene vi har hatt, og forklar løsningen på dem. - Spesifisere risikopunkter mer detaljert. Vi var veldig fornøyd med den konstruktive kritikken vi fikk, og tok særlig til oss punktet om at risikorapportene våre kunne bli mer detaljert Utfordringer og løsninger Lære seg ny teknologi Det har vært spesielt utfordrende å sette seg inn i ny teknologi, og samtidig to forskjellige web API er. Vi merket fort forskjellen med det å utvikle noe helt nytt kontra det å skulle utføre standard skoleoppgaver. Det ble mye vanskeligere å søke seg frem til de løsningene en var ute 85

23 etter når det utvikles noe nytt, hvilket har resultert i at vi må lære teknologiene mer grundig enn i et vanlig skolefag. Til tider har det føltes det som fremgangen gikk sakte, men dette var noe vi forventet da vi utviklet i ny teknologi og utfører oppgaver hvor det var vanskelig å søke seg frem til lignende eksempler. Dokumentasjonen til de forskjellige teknologiene er varierende, noen er velutviklet og tar for seg så å si alle mulige aspekter, mens andre har store mangler. Vi har med dette fått erfare fordeler og ulemper med åpen skildekode Begrensninger hos Spotify Frykten for at oppgaven ikke skulle la seg gjennomføre var tilstede de første ukene. Vi jobbet hardt for å komme til det utviklingspunktet hvor vi var sikre på at en skulle klare å automatisk spille av neste sang i Spotify. Da vi kom frem til vår første løsning som beskrevet under Sprint 1, kunne vi senke skuldrene og være trygge på at konseptet i det minste ville være gjennomførbart Oppdatering hos Spotify kom en stor oppdatering i Spotify sin klient som satt applikasjonen vår tilbake flere uker. Ved å sende inn en spotify URI til nettleseren ville ikke desktop klienten lenger spille den av, men kun finne den frem. Hensikten fra Spotify sin side var at sanger ikke automatisk skulle bli spilt av hvis noe annet allerede spilles av i klienten, men fungere som før ellers. Dette var imidlertid ikke saken etter denne oppdateringen, og etter tilbakemeldinger fra Spotify utviklere var dette sett på som en bug. For å se samtalene vi hadde med Spotify - se vedlegg. Vi tok raskt kontakt med veiledere fra Accenture for å få råd om hva vi skulle gjøre. Her ble vi rådet til å fortsette utviklingen som normalt, og håpe på at Spotify fikser bugen i løpet av prosjekt perioden. Vi var ikke så veldig optimistiske på at dette skulle bli fikset med det første. Vi valgte derfor å sette et av gruppemedlemmene til å jobbe med en lignende løsning i Soundcloud, og de to andre gruppemedlemmene til å jobbe med funksjonalitet som vi var relativt sikre på at ville la seg overføre til en eventuell alternativ løsning i Spotify. Heldigvis møtte vi ingen lignende problemer i utviklingen av Soundcloud delen. Denne perioden i prosjektet ser vi tilbake på som ekstremt lærerik, og vi er stolte over hvordan vi håndterte problemene. 86

24 Testing Testing har vært svært tidkrevende og noe som alle gruppemedlemmene har brukt tid på. Det har vært utfordrende å skrive korrekte tester for de forskjellige delene i applikasjonen. Det finnes mye eksempler på nettet men svært lite som kunne direkte overføres til vår kode. Vi har løst dette ved mye prøving og feiling Applikasjonen på mobil Vi støtte på problemer med det å bruke mobile enheter som avspillingsenhet. I SoundCloud delen vil ikke neste sang bli spilt av automatisk. Dette er restriksjoner på HTML5 funksjonen <<autoplay>> som er satt i alle de store nettleserne til mobil (Chrome, Firefox, Opera, etc.). Vi prøvde lenge å finne en vei rundt denne restriksjonen, men har funnet ut at det ikke lar seg gjøre. Restriksjonen er satt for å beskytte mobil brukere mot å automatisk laste ned data når de besøker en nettside. I Spotify delen av applikasjonen så vil ikke minispilleren vise hvilken sang som spilles av i tillegg til at spillelisten må startes manuelt. Dette er rett og slett problemer vi ikke kan gjøre noe med, og vil derfor anbefale brukere om å bruke en bæbar/stasjonær datamaskin til å styre musikken fra. Å være gjest på et arrangement via mobil fungerer som det skal Socket.IO Socket.io, heretter referert til som Socket, er det som får applikasjonen vår til å virke sanntid. Det å implementere Socket ble fort en større utfordring enn vi hadde forutsett. Socket var ment for å fungere optimalt sammen med en NodeJs server, men det oppsto likevel problemer. Årsaken var at vi hadde delt opp serveren vår i flere deler. Dette var en funksjonalitet som ble innført i nyeste versjonen av ExpressJs (4.X), og er kalt routing. Socket hadde ingen ferdigbygd støtte for routing og vi måtte derfor finne en egen måte å håndtere dette på. Socket er en sanntidsprotokoll som ligger på toppen av andre sanntidsprotokoller. Fordelen med dette var at vi ikke trengte å lære andre sanntidsprotokoller en Socket. Ulempen var at vi ikke kunne bruke funksjoner utover det Socket biblioteket tilbydde, uten å måtte grave oss ned alle de underliggende protokollene. Dette gjorde at det ble vanskelig å løse noen av problemene som oppsto. Blant annet problemet ved at mobile enheter frakobles websocket etter en periode i dvalemodus, og ikke kobler seg til på nytt før en viss tid har gått. Dette gjør at brukere verken kan sende eller motta sanntidsoppdateringer i en liten periode. 87

25 Socket har derfor blitt implementert som en bonus funksjonalitet, og applikasjonen er ikke avhengig av at Socket fungerer optimalt. Dette gjør at applikasjonen til enhver tid har konsistent data enten bruker er koblet til websocket eller ikke. Unntakshåndtering utover det Socket biblioteket tilbyr ble derfor ikke nødvendig fordi applikasjonen ville fungere uavhengig av Socket. Vi ser i ettertid at sanntidsrammeverk som Firebase kunne gjort implementering av sanntid enklere. Dette er fordi dataene som sendes rundt automatisk blir lagret i en database. Det vil si at databasen har sanntidsfunksjonalitet innebygd. Lagring og oppdatering trengs derfor ikke å håndteres i to forskjellige omganger Kall mot Soundcloud og Spotify Kommunikasjon med Soundcloud og Spotify sine servere viste seg også å være en krevende oppgave. Developer nettsidene til Soundcloud og Spotify ga oss mye informasjon, men ikke nok til at løsningen kom av seg selv. Informasjonen vi fant ga oss mer en retningslinje på hva vi måtte prøve ut, og hvilken type informasjon som ble returnert fra serverne. Dette tok mer tid enn antatt. Vi slet for eksempel lenge med å komme frem til det riktige formatet å gjøre kall mot Spotify, da bildene og eksemplene hentet fra nettet ikke fungerte i vår applikasjon. Det ble etter mye prøving og feiling vi fant svaret. Løsningen kom fra et URL kall som ga oss et godt utgangspunkt i tolkningen av kallet. Derifra jobbet vi oss videre til det endelige resultatet vist i eksempelet under som er et oppsett av hva som sendes til Spotify ved oppretting av spilleliste. var option = { url: url, headers: { 'Content-Type': 'application/json', 'Authorization': 'Bearer '+ token}, json: {'name': 'Vote4Music:' + new Date().toDateString()} }; 88

26 Spotify access/refresh Token Bruken av Spotify sin refresh token i applikasjonen har vært en tidkrevende og vanskelig oppgave å implementere. Oppsettet av når applikasjonen skal bruke refresh-token har blitt endret flere ganger, enten fordi det har blitt uryddig og unødvendig kode, eller at oppbyggingen ikke har fungert (riktig). Ettersom autoriseringen med refreshtoken skjer asynkront har det vært en utfordring å få til et synkront kall når nytt token skal settes etter en feilmelding. Problemet som oppsto var at den gamle token ble brukt før en ny hadde blitt satt, og fikk konsekvenser for visning og innsending til Spotify-spillelisten da disse krever en gyldig access token. Den endelige løsningen ble en checktoken metode som kjøres før hvert kall mot Spotify sin server og oppdaterer token hvis nødvendig Design Målgruppe Hvis man skal definere en målgruppe så er det naturlig å se etter hvilke type mennesker som bruker Spotify eller Soundcloud til å spille av musikk på fester/arrangementer. Dette er selvfølgelig vanskelig å finne statistikk på, men har valgt å sikte oss inn på aldersgruppen år. Dette spiller hovedsaklig inn på designet av nettsiden. Vi vil lage en så enkel nettside som mulig, uten for mye forklaring og tekst. Det vil selvfølgelig være en liten forklaring på nettsiden, men vi belager oss på at besøkende på siden har fått konseptet forklart ved hjelp av jungeltelegrafen. En enklere nettside vil videre hjelpe brukere med nedsatte motoriske og kognitive egenskaper, noe som ofte er tilfellet på fester og arrangementer der alkoholkonsumering blant gjester er et faktum Brukergrensesnitt Utvikling av applikasjon og grensesnitt har blitt gjort med konseptet K.I.S.S (Keep It Simple Stupid) som en visjon. Vi startet tidlig med å tegne og tenke på valgene en bruker skulle ha, og hvordan applikasjonen skulle fungere. Det ble fort enighet om at forsiden kun skulle innehold muligheten for å lage et arrangement og finne et arrangement (senere Bli med ). 89

27 Figur 43: Bilde tatt En enkel forside ble konseptet for nettsiden. Videre kunne en bruker få flere valgmuligheter. Vi hentet inspirasjon fra forskjellige bilder som hadde et DJ -festtema. Dette var for å skape et inntrykk av hvordan nettsiden kunne se ut og preget til slutt logoen til applikasjonen. Ettersom grensesnittet til Soundcloud og Spotify skulle stå sentralt i opprettelsen av et arrangement, ble utfordringen å finne løsninger på hvordan annen funksjonalitet skulle fremvises. Spørsmål som hvor spillekøen og innstillinger-knappen skulle plasseres, eller hvor sentralt logoen fremstilles, var spørsmål som ble stilt. Vi fikk tilbakemelding fra veiledere, familie og medstudenter om hva de syntes, og tok dette til etterretning ved utarbeiding av sluttdesignet. Figur 44: Bilde tatt

28 Figur 45: Første logo tatt i bruk. Figur 46: Forslag til logo utviklet i Adobe Photoshop. Figur 47: Forslag til logo utviklet i Adeobe Photoshop Farger, språk, størrelse For å holde designet enkelt og ha så få distraksjoner som mulig, er det brukt komfortable farger i applikasjonen. Vi har begrenset fargebruken til å hovedsaklig bestå av sort, hvit og oransje med noe mindre bruk av grønn og grå. Oransje farge symboliserer glede, bevegelse og nytelse 7 - veldig positive faktorer for applikasjonen å bli knyttet til. Videre er sort og hvitt tilstedet for å beholde simplisiteten. Grønn er en fin farge for å tiltrekke seg oppmerksomhet, og er brukt på diverse knapper. Grått er brukt på steder som trenger en kontrast fra sort og hvitt uten å virke forstyrrende. Å bruke engelsk i applikasjonen var mer en selvfølge enn et valg vi tok selv. Likevel ble språkbruk nevnt for veiledere fra Accenture, og vi fikk beskjed om at vi stod fritt til å gjøre det vi ville. Det falt oss naturlig når det å skrive for et amerikansk selskap, og et selskap som har ansatte fra flere nasjoner, at engelsk er språket som i all hovedsak blir brukt. Dette ville også føre til at flere kunne forstå og bruke applikasjonen. Dermed ble beslutningen enkel. Størrelsen av bildene og logo er viktig i den forstand at det ikke skal være distraherende, men samtidig være stort nok til å se hva som vises. Dette ble noe vi måtte ta til oss ved utarbeiding

29 av albumbilder i søk og visningssiden i Soundcloud delen. Her ble prøving, feiling og tilbakemeldinger fra medstudenter og veiledere brukt. Skalering av bilder ble også viktig når bruk av mobil og tablets skulle implementeres Skalering for mobil og tablets Applikasjonens design vil fungere like fint på mobilen som på pcen, noe som er veldig viktig i webapplikasjon. Her brukes bootstrap sine skaleringsklasser for å få ønsket effekt. Bootstrap er bygget opp med et Mobile first konsept og introduserer et responsivt rutenettsystem som skalerer opp til 12 kolonner ettersom visningsstørrelsen øker. Rammeverket inneholder fire forhåndsdefinerte klasser for ulike størrelser: - Ekstra små enheter - Mobil - Små enheter - Nettbrett - Medium enheter - Desktop - Store enheter - Desktop Disse klassene er definert: - Col-xs-* - Ekstra små enheter - Col-sm-* - Små enheter - Col-md-* - Medium enheter - Col-lg-* - Store enheter Med bootstrap klassene tilpasses applikasjonen etter plattformen som brukes, og applikasjonen på mobil vil dermed ligne på bildet under (figur x.4). 92

30 Figur 48: Applikasjonen på Android telefon i nettleseren Google Chrome Universell utforming For å holde designet mest mulig universelt, har vi prøvd å følge punkter i WCAG dokumentasjonen. Web Content Accessibility Guidelines (WCAG) er utviklet for å holde en internasjonal nettstandard som sørger for at nettsider er tilgjengelig og tilpasset for flest mulig individer, organisasjoner og stater. Den forklarer hvordan en kan gjøre nettinnhold mer tilgjengelig for individer med spesielle utfordringer. WCAG 2.0 oppsummerer innholdet sitt med stikkord som gir et overblikk over hva som inngår i selve dokumentasjonen 8. Noen punkter som er definert: Gi bruker nok tid til å lese og bruke innholdet på nettsiden Ikke noe innhold som fører til anfall Tekst er lesbart og forstålig Innholdet oppfører seg forutsigbart Innhold som kan presenteres ved hjelp av annen teknologi

31 Disse retningslinjene gir en kort forklaring på hva som bør tenkes på ved utforming av design, og er utdypet mer i deres dokumentasjon. Applikasjonen følger flere punkter i retningslinjene ovenfor til en viss grad. Et eksempel på noe som ikke oppfyller punkt en ovenfor er Spotify timeren. Det gis dessverre ingen mulighet til å stoppe timeren, da dette vil hindre visningsfunksjonalitet av Spotify-spillelisten. Fordi designet innholder få farger og dynamiske bilder blir punkt to mindre relevant for applikasjonen. Et design som ikke tar bort fokus og forstyrrer en bruker har likevel vært viktig ved utvikling. Kontraster i applikasjonen er et viktig punkt i applikasjonen. Vi har i etterkant brukt nettsiden WebAIM 9 for å teste dette. Her får en testet om kontrastene godkjennes på WCAG nivå AA eller AAA. Vi har også brukt verktøyet Web Accessibility Evaluation Tool (WAVE) til å sjekke kontraster og feil i designet. WAVE er en utvidelse av WebAIM og tilbyr en evaluering av designet på nettsiden vist på skjermen. Verktøyet viser blant annet kontrastfeil og manglene elementer som bør implementeres for å holde nettsiden mest mulig universell utformet. Figur 49: WAVE fremvisning av kontrastfeil i designet. Dette har blitt fikset. For å teste om innholdet kunne presenteres på en annen måte har vi testet applikasjonen på mobil med en talkback funksjon. Dette fungerte fint, da vi greide å bli med på et

32 arrangement og legge til en sang. Det gikk likevel ikke helt som planlagt. Vi møtte noen problemer ved stemming av sanger og navigering da disse ikke fungerte optimalt. RomId ble lest opp feil, dette var fordi talkback funksjonene prøvde å lese romid som et ord istedenfor å lese et og et tegn. Vi har prøvd å gå gjennom problemene for å rette dem opp. Vi ser i ettertid at det burde blitt satt av mer tid til å gå igjennom dette Avsluttende del Her vil vi utrede om det endelige produktet, hvilket læringsutbytte vi har hatt og valg vi ville gjort annerledes om vi hadde startet på nytt Ord fra oppdragsgiver Hans Hallaråker, Christian Hunstad og Daniel Reinholdt fikk som oppgave å lage en digital jukeboks i form av en webapplikasjon som skal gjøre det mulig for en person å opprette et arrangement hvor deltakere kan legge til og stemme frem sanger som spilles under arrangementet. Løsningen består hovedsaklig av to deler, en webapplikasjon og en backendserver. Webapplikasjonen gjør det mulig for en arragementseier å opprette et arrangement hvor deltakerne på arrangementet kan, ved hjelp av en unik kode, stemme på, og legge til sangene de ønsker å høre. Sangene kan hentes fra Spotify eller Soundcloud. I tillegg har studentene utviklet et skjermbilde som kan vises på en skjerm hvor alle kan se hvilke sanger som ligger i køen og hvor mange stemmer de har. Serveren håndterer koblingen mot Spotify og holder styr på stemmene som kommer inn. Sluttresultatet er en solid applikasjon som oppfyller kravene som var satt for oppgaven. Studentene har hatt en svært positiv og profesjonell opptreden gjennom hele perioden de har vært hos Accenture. Dette har blant annet gjort at samarbeidet med studentene har vært knirkefritt sett fra veiledernes side. Gruppen har vist en god evne til å sette seg inn i ny teknologi og har gjort grundige undersøkelser på hvilke teknologier og løsninger som passer best til oppgaven. De har også vist en meget god evne til problemløsning. Da Spotify uten forvarsel endret APIet som studentene brukte, implementerte de støtte for Soundcloud som et annet alternativ. De har senere også funnet en ny løsning for å få Sppotify til å fungere. Gruppen har også mange gode forslag til forbedringer og fremtidige funksjoner som er et godt grunnlag for videre utvikling. 95