Forprosjekt. Oppgdragsgiver Unikia, Lille grensen 7, 0159 Oslo, Kontaktperson Anders Kose Nervold,

Transkript

1 Hovedprosjekt i data/informasjonsteknologi Høgskolen i Oslo og Akershus Forprosjekt Prosjekttittel Unikia Android applikasjon Gruppe 13 Markus Bugge-Hundere s Morten Wold Aksel Wiig s s Oppgdragsgiver Unikia, Lille grensen 7, 0159 Oslo, Kontaktperson Anders Kose Nervold, anders.nervold@unikia.com, Veileder Aiko Yamashita Sammendrag Unikia var primært et produktutviklingsselskap, men har nylig utvidet virksomheten med konsulenttjenester, nettbutikk og fysiske butikker. Unikia ønsker å få utviklet en applikasjon som vil gjøre det enkelt å få et overblikk over bedriften. Grunnen for dette er at de vil at deres ansatte skal kunne ha enkel tilgang til nøkkeltall for å skape motivasjon. De ønsker å få denne applikasjonen i tre former; Android, ios og som en webapplikasjon. Håpet er å ha noe lignende en dashboard app, med enkel oversikt over nøkkeltall for bedriften, framstilt som bare tall eller grafisk. Vi har informert Unikia om at vi har god erfaring innenfor applikasjonsutvikling for Android, men ingen når det kommer til ios. Derfor vil vi ha hovedfokuset vårt på å ferdigstille en fungerende Android app, og så gå over til å lage noe som vil fungere på web. Vi vil hovedsakelig bruke Android Studios for utvikling, siden Android applikasjonen er hovedfokuset vårt. Etterhvert vil vi også bruke Netbeans for å lage webapplikasjonen. For å enkelt kunne kode sammen, og på tvers av forskjellige maskiner, vil vi bruke Github. Vi starter prosjektet med å utvikle kode, samt jobbe litt med design slik at appen kan brukes og testes. I nesten hele prosjektperioden vil vi jobbe med utvikling, mens det endelige designet kommer i andre halvdel. Rapportskriving begynner så snart koden er på et nivå hvor 1

2 vi har noe ordentlig å skrive om, og vil fortsette helt til prosjektet er ferdig. Det blir noen dager med øving/forberedelse av presentasjon på slutten. Dagens situasjon Vi spurte Anders Kose Nervold (Prosjektleder og vår kontaktperson) om han kunne beskrive dagens situasjon: Unikia AS er et ungt selskap i sterk vekst, med mange nye prosjekter i sving. Unikia var primært et produktuvtiklingselskap, som nylig har har utvidet virksomheten med konsulenttjenester, nettbutikk og fysiske butikker, og satsing på nye prosjekter sammen med norske gründere. Selskapet har et ganske flatt hierarki, med korte og raske beslutningskanaler. Det er ca 25 ansatte på tvers av selskapets virksomheter, med planer om videre vekst i antall ansatte i For ledelsen i selskapet er det nyttig å til enhver tid kunne se på nøkkeltall for å måle bedriftens resultater løpende. Ettersom forskjellige prosjekter styres av og involverer forskjellige verktøy og systemer, er det per i dag ingen sentral kilde til selskapets nøkkeltall. Per i dag må derfor ledelsen henvende seg til flere nøkkelpersoner i selskapet for å danne seg et bilde av dagen, uken, eller månedene som har gått, for å få oversikt over relativt enkle tall. Resultatet er at man ikke til enhver tid kan være oppdatert på hele selskapets situasjon og performance. Fra de ansattes sted er det også nyttig å ha enkel tilgang på denne informasjonen slik at de lettere kan se tallene som skal motivere de til å yte ekstra godt på jobb. Unikia AS ønsker seg derfor en dashboard -app som henter inn data fra de forskjellige kildene og presenterer det på en enkel måte for de ansatte og selskapets ledelse. For eksempel er det nyttig å kunne se dagens omsetning i forskjellige salgskanaler som forskjellige nettbutikker selskapet driver, de forskjellige fysiske butikkene selskapet har, b2b, engasjement i sosiale medier, osv samlet på et sentralt dashboard. Her er det også ønskelig å kunne dra ut rapporter per dag og over tidsperioder, gjøre enkel statistikk/beregninger, og eksportere til Excel/Csv for dypere analyse. 2

3 Da selskapet har ansatte som bruker både Android og ios, er det et ønske om å få til en dashboard -app som fungerer på tvers av disse enhetene, og gjerne også som en ren webtjeneste. Mål og rammebetingelser Unikia ønsker en applikasjon på både Android/iOS og som en web-app. Appen skal fungere som et Dashboard for bedriften, og brukes av deres ansatte. Appen vil gi ansatte en raskere og enklere måte å få oversikt over hvordan det går med selskapet på forskjellige fronter. Vi tenker at applikasjonen er vellykket om Unikia mener den gjør hverdagen lettere. Informasjonen hentes ut i form av salgsresultater/ likes fra butikk og sosiale medier. Det vil da bli aktuelt å generere statistikker og rapporter fra forskjellige tidsperioder. Appen vil da kunne sammenligne resultater fra ønskede tidsrom. En av grunnene til at Unikia ville utvikle denne applikasjonen er for å motivere de ansatte ved å vise resultatene grafisk istedenfor å bare ha informasjon spredt rundt. Verktøyet som hovedsakelig skal bli brukt til å jobbe med prosjektet er Android Studios. Det er dette vi har lært tidligere og har erfaring innenfor. Det skal bli brukt Github (Verktøy for å synkronisere kode i gruppen) hyppig underveis i prosjektet for å holde orden og at vi lettere og raskere skal kunne jobbe med appen. Hvis vi får tid til å lage en webapp, vil vi bruke netbeans som utviklingsverktøy. Vi holder kontakt med oppdragsgiver ofte via slack for å holde han oppdatert på arbeidet og om vi har noen spørsmål. Vi har ikke mye erfaring i design, og vil derfor trenge hjelp til å få appen til å se bra ut. Unikia har sagt at de kan hjelpe oss med design, og vi kommer til å benytte dette så mye som vi trenger. 3

4 Løsninger /alternativer Selv om Unikia ønsker en app på Android/iOS og på web har vi forklart at vi ikke har erfaring fra ios og derfor fokuserer på å lage en Android app. Som prioritering nummer to skal vi utvikle en web-basert applikasjon. Hvis det blir tid skal vi prøve å utvikle noe i ios, men dette er veldig usannsynlig fordi vi har null erfaring med dette og programmeringsspråket det skrives i. Vi vil fokusere på en fungerende Android applikasjon før vi begynner å jobbe med en webapp. Det vil være viktigere å ha en versjon som fungerer istedenfor to som er halvveis ferdige. Vi har diskutert dette med Unikia og de har helt fra starten av vært veldig klare på at det er viktig at vi utvikler noe vi kan og er interessert i å utvikle. De forstår at vi ikke kan love for mye, men heller legge til nye funksjoner underveis. En ulempe med prosjektet er at vi mest sannsynlig ikke får utviklet appen i ios, men det er ikke mye vi får gjort med det. Man kan også se det som en fordel at vi får mer tid til å fokusere på Android delen. Analyse av virkninger Om vi bare utvikler appen for Android vil det si at noen av de ansatte hos Unikia ikke kan bruke appen. Dette er noe Unikia kan jobbe med, og eventuelt ansette/leie ut jobben til noen som kan ios. Det er mye enklere å lage en kopi av en fungerende app. Web-applikasjonen vil kunne fungere for alle, uavhengig av telefon. 4

5 Arbeids- og Fremdriftsplan Vi planlegger å begynne med litt research og idemyldring rundt hvordan vi kan fullføre prosjektet på en best mulig måte. En god plan kan i mange tilfeller hindre oss i å måtte gå tilbake til kode vi har gjort fordi noe nytt ikke fungerte/passet med det gamle. Det er viktig at vi har en ryddig og god plan, og dette lager vi i starten at utviklingsfasen, periode 1. Vi må også gjøre research rundt hvordan man henter ut all informasjonen vi skal fremstille og undersøke om noe er spesielt vanskelig. Det er veldig vanskelig å lage en nøyaktig plan i et slikt prosjekt, spesielt siden oppgaven vår er ganske åpen og vi har lov til å endre på, eller legge til nye funksjoner. Gruppen satser på å ha en fungerende Android app først, før vi begynner på web-applikasjonen. Android appen kommer ganske sikkert til å trenge oppdateringer i denne perioden også, ettersom vi kan finne bedre måter å løse problemer på eller legge til nye funksjoner. Om vi planlegger noe av utviklingen i mer detalj på dette tidspunktet vil det bare bli bortkastet tid, så vi kommer ikke til å bruke mye tid på det. Har vi en fungerende Android app i slutten av periode 2 eller begynnelsen av periode 3 tenker vi at prosjektet går som planlagt. Vi håper at vårt prosjekt kan være ferdig en eller to uker før fristen, men det kan godt hende at vi må jobbe med koden helt til siste dag. Det blir sikkert noen små endringer i denne perioden uansett, og det hadde vært enklere å fokusere på å optimalisere utseende/detaljer enn å måtte fikse problemer. Vi tenker å gjøre noe enkelt design når vi begynner med hovedprosjekt. Dette vil for det meste være så vi kan se hvordan appen fungerer. Vi kommer ikke til å bruke Unikia for dette, men vi vil spørre dem om hjelp etter at prosjektet er kommet ordentlig igang. Det kommer til å bli mindre oppdateringer underveis i andre del av periode 1, samt periode 2, men disse vil mest sannsynlig ikke være så veldig viktige for prosjektet som helhet. Vi kommer til å samarbeide med Unikia for å skjønne hvordan de vil at appen skal se ut, samt få grafisk hjelp. 5

6 Rapporten kommer vi til å jobbe mye med og har derfor satt at vi skal jobbe med den fra periode 2 og utover. Det er noe det er lurt å lage underveis i prosjektet men vil begynne å fokusere mer med når det nærmer seg siste periode. Vi trenger også å ha kommet et stykke i utviklingen for å kunne begynne på rapporten. Vi regner med at vi jobber med presentasjonen den siste måneden, men det er noe usikkert hvor mye tid vi trenger. Vi kommer til å jobbe med presentasjonen ved siden av eventuelle problemer som må fikses. Vi setter av noen dager før fremføringen til å øve. Risikoanalyse For å gi en bedre oversikt over mulige risikoer vi kan komme over i prosjektet har vi laget en risikoanalyse. 1. Manglende kunnskap om et språk 2. Bugs 3. Tap av data 4. Falle bak skjema Som en kan se på risikoanalysen vår, har vi ikke noen problemer som ligger i rød sone. De ligger i gul, som vil si at vi burde kunne klare å håndtere de om de skulle oppstå. Vi har allerede oppklart med Unikia at vi ikke vil kunne levere en ios applikasjon ettersom vi ikke har noe erfaring med den plattformen, så vi har allerede håndtert det problemet. Når det kommer til eventuelle andre funksjoner vi muligens ikke vil klare å kode har vi alltids hele internettet tilgjengelig. Annet enn det er det mange lærere tilgjengelige på skolen som har kompetanse innenfor hva vi jobber med. 6

7 Bugs vil garantert oppstå under utviklingen. Hvor seriøs en bug er vil variere på hvor vi ligger i utviklingsprosessen, og hvor lang tid det vil ta å fikse. Oppstår en bug tidlig i utviklingsprosessen vil det nok være en mindre en som er enkel å fikse. Skulle det skje senere i prosessen kan det være mer seriøst, og i verstefall gjøre at vi faller bak skjema. Tap av data kan være et stort problem. Vi vil ha hele koden vår på Github, noe som tillater oss å ha backup på internett. Så skulle, mot all formodning, en PC slutte å fungere er det nok bare et mindre tap av data vi vil oppleve. Hvor kritisk det er for oss å falle bak skjema vil variere med tidspunktet av prosjektet. Skjer det sent i prosjektet, nærmere innleveringsdato, er dette noe som kan gjøre at vi faller i kvalitet eller opplever manglende funksjonalitet. Det er ikke alt for mye vi kan gjøre for å hindre dette, annet enn å prøve å være så streng som mulig når det kommer til å følge en arbeidsplan. 7