Forprosjektrapport Hovedprosjekt for gruppe 4, Anvendt datateknologi våren 2015 1.0 Presentasjon 2.0 Sammendrag 3.0 Dagens situasjon 4.0 Mål og rammebetingelser 5.0 Løsninger/alternativer 6.0 Analyse av virkninger 1.0 Presentasjon Prosjektgruppen består av Per Erik Finstad, Even Holthe og Vegar Norman, alle fra studieprogrammet Anvendt datateknologi ved Høgskolen i Oslo og Akershus. Medlemmene har fordypet seg innenfor programmering og programutvikling gjennom studieløpet. Gruppen har tidligere jobbet sammen i andre fag. Som en del av prosjektet har også gruppen et eksternt medlem fra Høgskolen i Gjøvik, masterstudent Eirik Gihle, som fungerer som produkteier. Gruppens leder er Vegar Norman. Prosjektet går ut på å gjennomføre en utviklingsoppgave for Bekk Consulting AS, der vi skal lage en løsning bestående av flere mindre deler, mer bestemt en mobilapplikasjon, en serverløsning med databasetilknytning og et webbasert administrasjonspanel. Utførelse vil skje over en periode på omtrent fire måneder, og gruppen har valgt en smidig utviklingsmodell. Andre kunnskaper som vil tas i bruk gjennom prosjektets gang er systemutvikling, prototyping, menneske-maskin interaksjon og universell utforming. Oppdragsgiver for oppgaven er Bekk Consulting AS (videre referert til som Bekk). Bekk er et norskeid konsulentselskap som gjennomfører prosjekter for store private og offentlige virksomheter innen strategisk rådgivning, utvikling av IT-systemer og design av digitale tjenester (Bekk Consulting, 2015). Bekk hadde i 2013 en omsetning på over 473 MNOK.
Kontaktperson Stilling Rolle Epost-adresse Mattias Olovsson Senior Interaksjonsdesigner Prosjektleder mattias.olovsson@bekk.no Christian Schwarz Manager Ansvarlig studentoppgaver christian.schwarz@bekk.no Christoffer Marcussen Senior consultant Teknisk veileder christoffer.marcussen@bekk.no Veileder tildelt av Høgskolen i Oslo og Akershus er Dr. Knut H. Rolland, som arbeider ved Westerdahls (tidligere Norges Informasjonsteknologiske Høgskole, NITH). Knut har tidligere jobbet i utviklingsprosjekter og har også veiledet andre grupper med sine hovedprosjekter ved tidligere anledninger. 2.0 Sammendrag Konsulentselskapet Bekk Consulting AS ønsker å se på muligheten for effektivisere innhenting av data i forbindelse med kundetilfredshet. Som hovedprosjekt på bachelorstudiet har vi tatt på oss ansvaret for å utvikle denne løsningen. Bekk ønsker en mobilapplikasjon for ios som kan lastes ned av sluttbrukere og brukes for å gjennomføre undersøkelser/kundereiser. Dataene skal visualiseres på en måte som effektiviserer analysen av dataene og produktet er i første omgang til internt bruk. Løsningen består av 3 deler, en ios-applikasjon, et administrator-panel og et RESTful-API. Bekk ønsker en framtidsrettet, innovativ og skalérbar løsning som gjør at produktet kan videreutvikles etter vår prosjektperiode. 3.0 Dagens situasjon Bekk Consulting jobber for tiden med flere prosjekter der det er viktig å kartlegge tilfredshet blant sluttbrukerene; for eksempel er det flere prosjekter som innebærer salg av tjenester med flere ulike steg, der det er viktig å kartlegge hvordan sluttbrukerene opplever hver fase fra start til slutt i prosessen. Derfor er det et ønske om et verktøy som kan hjelpe Bekk i å lettere kartlegge dette, ved å tilby sluttbrukerene en mulighet til å gi umiddelbar tilbakemelding. Dette verktøyet skal gjøre det lett å sette opp måling av brukertilfredshet med fokus på emosjoner/følelser, der det også er viktig at sluttbrukerene umiddelbart kan gi tilbakemeldinger på en brukervennlig måte. Det er også et ønske om tydelige og lettolkede visualiseringer slik at dataene som samles inn kan analyseres og vurderes.
4.0 Mål og rammebetingelser Mål: For at det Bekk skal ha et utbytte av prosjektet, skal det endelige produktet gjøre det mulig å samle inn og dokumentere (spontane) følelser og emosjoner knyttet til en tjeneste/produkt. Produktet må legge til rette for at administratorer skal kunne opprette nye undersøkelser, samt hente gi innsikt og automatisk visualisere eksisterende/avsluttende undersøkelser. For sluttbrukere må det være lett å bidra med tilbakemeldinger og følelser for ulike kontaktpunkter gjennom applikasjonen på en stabil, givende og tilfredsstillende måte når brukeren benytter seg av en tjeneste. Teknologier: Gruppen skal bruke Git som system for versjonskontroll Gruppen skal bruke Jira som et verktøy for prosjektstyring Gruppen skal kode og kommentere på engelsk Gruppen skal jobbe smidig ved hjelp av Scrum Gruppen skal skrive dokumentasjon og rapporter på norsk Gruppen skal benytte seg av enhetstesting og annen relevant testmetodologi Mobilapplikasjonen skal utvikles for ios-plattformen versjon >= 7.0 med programmeringspråket Swift. Swift setter begrensninger for ytterligere bakoverkompatibilitet. Serversidekomponenten (backend) skal utvikles med node.js versjon 0.10.x, Express versjon 4.11.x og med MySQL 5.6.x som database. Dataene som tilbys konsumentene skal være i henhold til REST-prinsipper. Administrasjonspanelet skal utvikles i HTML5, CSS3 og JavaScript (AngularJS versjon 1.3.x) 5.0 Løsninger/alternativer Gruppen skal lage en løsning bestående av tre bestanddeler: En backendløsning med en database som gjør dataene tilgjengelig gjennom et RESTful API. På denne måten kan backend-siden kommunisere med de andre bestanddelene på en enkel måte og videreutvikling gjøres lettere i fremtiden. Andre fordeler med denne løsningen er at det på denne måten oppstår et klart skille mellom de ulike lagene i løsningen, og ved å frakoble dem vil dette gjøre vedlikehold og videreutvikling lettere. Dette åpner også muligheten for fremtidige klienter, så lenge de kan konsumere JSON. En ulempe ved dette er at dataene fra API-et må hentes asynkront, noe som kan by på problemer ved bruk av eldre teknologier og rammeverk. I prosjektets tilfelle er allikevel et slikt API å foretrekke da det vil gjøre løsningen mer sentralisert, og dermed enklere å utvikle fordi arbeidsmengden vil minske.
Administrasjonsløsningen skal ha et grensesnitt laget med Twitter Bootstrap for enkel konstruksjon av grensesnitt og skjermbilder. Løsningen skal benytte AngularJS for å følge klar MVC-arkitektur i applikasjonen og for kommunisering med backendløsningen på en asynkron måte. Fordelen ved å bruke AngularJS er at webapplikasjonen vil fremstå som langt mer responsiv og intuitiv i bruk enn ved synkrone løsninger, da hvert skjermbilde ikke må renderes hver gang brukeren trykker på en knapp, men data lastes inn ved behov. Løsningen blir derfor en SPA (single page application). En ulempe ved å gjøre dette er at skjermbildene i applikasjonen kan renderes galt dersom data ikke kommer inn eller ved ukomplette datasett, samt at søkemotoroptimalisering gjøres vanskeligere. Vi mener allikevel at dette er den beste løsningen for prosjektet ettersom fordelene klart utveier ulempene. Mobilapplikasjonen skal lages så denne kan kjøres på nyere ios-enheter, og skal skrives i Swift gjennom Apples verktøy for applikasjonsutvikling, Xcode. Vi vil her følge MVC-arkitektur i utvikling av appen. Swift har en syntaks som ligger nært opp mot det vi har erfaring med fra tidligere. Et alternativ til å bruke Swift hadde vært å bruke Objective-C. Dette bedømmer vi til å være noe vanskeligere å ta i bruk, grunnet en litt sær syntaks og tidvis manuell minnehåndtering. Læringskurven blir derfor såpass høy at vår vurdering mellom de to språkene har vært at Swift vil være lettere å komme i gang med. En ulempe ved å bruke Swift er mangelen på støtte for eldre versjoner av ios, i tillegg til at språket er ganske nytt og dermed kan ha uforutsette problemer på sikt. 6.0 Analyse av virkninger I samråd med oppdragsgiver har vi kommet fram til en løsning som er hensiktsmessig for begge parter. Pågrunn av prosjektets omfang var det viktig for oss bli enige om de teknologiske rammene på et tidlig stadie, og vi har derfor ingen alternativ løsning på dette området. Til grunn for valgene av teknologi var dette kriteriene: Framtidsrettede teknologier. For både kunde og oss veide det tungt å velge teknologier for framtiden. Dette av to grunner; det er viktig kunnskap å besitte for oss, og det skal kunne være et produkt kunden skal kunne videreutvikle i framtiden. Skalérbarhet. Fra oppdragsgiver er det aktuelt å fortsette utviklingen av produktet etter våres engasjement, og skalérbarhet er derfor viktig, slik at kodebasen ikke setter begrensinger for framtidig utvikling. Erfaring. Prosjektet består av 3 hoveddeler, og det er derfor nødvendig at vi har erfaring fra en del av teknologien vi tar i bruk. Open Source. For oss er det et naturlig valg å gå for Open Source-teknologier da dette begrenser kostnader, gir oss frihet og stor fleksibilitet, kvalitet og sikkerhet.
Læringsutbytte. Et vesentlig mål for prosjektet er å lære og vårt ønske om kunnskap har vært avgjørende for hvilke teknologier som er valgt. Oversikt. For at prosjektet skal foregå på en professjonell og ryddig måte har vi valgt å ta i bruk verktøy for versjonshåndtering og prosjektstyring. I tillegg til å være helt nødvendig for å holde oversikt, er det også viktig kunnskap i arbeidslivet. Med disse kriteriene til grunn mener vi at alle innvolverte skal få mest mulig utbytte av prosjektet. Vedlegg: Fremdriftsplan
Arbeids- og fremdriftsplan Gruppe 4 Bachelorprosjekt ved HiOA 2015 NB! Merk at planen er tentativ og kan endres underveis. Fase Varighet Beskrivelse Oppstart 01/01-15 23/01-15 Oppstartsfase. Møter med veiledere og prosjektmedlemmer skal gjennomføres, prosjektplan skal legges og innledende planlegging ferdigstilles til frist den 23. januar 2015. Innledende backlog av issues til de første sprintene opprettes. Innsiktsfase (Sprint 1) 26/01-15 13/02-15 Innsiktsfasen i prosjektet skal være med på å kartlegge grafisk profil og de nøyaktige rammene for den software-relaterte siden av prosjektet. Første sprint kjøres for å komme i gang med de delene av utviklingen som kan gjøres tidlig, hovedsaklig relatert til backend-programmering og databasedesign. Iterasjon 1 (Sprint 2) 16/02-15 06/03-15 Første iterasjon av papirprototype skal gjøres. Det skal lages en lo-fi prototype i første omgang for å raskt komme i gang med brukertesting og for å avdekke umiddelbare problemer med grensesnitt og konsept. Andre sprint kjøres. Hvilke oppgaver som skal gjøres i løpet av sprinten avklares i slutten av sprint 1, basert på gjenværende backlog og Brukertesting av iterasjon 1 Iterasjon 2 (Sprint 3) 09/03-15 Resultatene fra papirprototyping gjort i iterasjon 1 skal brukertestes. Planlegging i forbindelse med dette gjøres i slutten av iterasjon 1. Ansvar for dette kartlegges underveis. 09/03-15 27/03-15 Andre iterasjon av prototype skal kjøres. Hvorvidt dette skal være lo-fi eller hi-fi skal bestemmes etter brukertesting av første iterasjon, da gruppen vil ta en evaluering på dette. Tredje sprint kjøres. Hvilke oppgaver som skal gjøres i løpet av sprinten avklares i slutten av sprint 2, basert på gjenværende backlog og Systemtest 1 + planlegging og bugfixes Iterasjon 3 (Sprint 4) 31/03-15 03/04-15 (Påskeferie) Systemtest skal kjøres samtidig som en planleggingsfase gjennomføres. I utgangspunktet individuelt arbeid hvor feilrettinger implementeres og backlog blir videre fylt opp. Sprint 4 planlegges. 06/04-15 24/04-15 Tredje iterasjon av prototype kjøres. Basert på resultatene fra systemtesten avgjøres det her om det skal kjøres en prototype eller om en test av et mer eller mindre ferdig produkt skal gjennomføres i neste fase. Fjerde sprint kjøres. Hvilke oppgaver som skal gjøres i løpet av sprinten avklares i slutten av sprint 3, basert på gjenværende backlog og
Systemtest 2 Brukertesting av iterasjon 3 Iterasjon 4 (Sprint 5) 24/04-15 Systemtest skal gjennomføres i samråd med brukertesting av iterasjon 3, muligens i en og samme testrunde. Nærmere planlegging av denne testrunden må gjennomføres i god tid i forkant. 27/04-15 15/05-15 Fjerde iterasjon igangsettes. Denne iterasjonen vil være rettet mot lansering og levering av oppgaven, og i utgangspunktet vil ingen større endringer eller nye features implementeres i denne fasen med mindre dette er strengt nødvendig. Femte sprint kjøres. Hvilke oppgaver som skal gjøres i løpet av sprinten avklares i slutten av sprint 4, basert på gjenværende backlog og Forberedelser til lansering 18/05-15 24/05-15 Siste finpuss på kode og dokumentasjon. Lansering 25/05-15 Endelig leveranse til oppdragsgiver (kode og dokumentasjon). Levering 26/05-15 Endelig leveranse av prosjektet med dokumentasjon til HiOA. Presentasjon 08/06-15 11/06-15 Muntlig presentasjon av bachelorprosjektet for sensorer ved HiOA.