Hovedprosjekt 2013 Høgskolen i Oslo og Akershus

Transkript

1 HiOA 2013 Hovedprosjekt 2013 Høgskolen i Oslo og Akershus Digipost for Android Digipost for Android Gruppe 13 Gruppe 13 Fredrik ThorbjørOsen Lillejordet Sigurd Hagen Falk Fredrik Stenbro

2 PROSJEKT NR: Studieprogram: Ingeniørfag - data Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Åpen Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Digipost for Android DATO ANTALL SIDER / BILAG 126/10 PROSJEKTDELTAKERE Fredrik Thorbjørnsen Lillejordet s Sigurd Hagen Falk s Fredrik Stenbro s INTERN VEILEDER Eva Hadler Vihovde OPPDRAGSGIVER Bekk Consulting AS KONTAKTPERSON Christian Schwarz SAMMENDRAG Applikasjonen gir digipostbrukere med en androidenhet muligheten til sikker innlogging mot Digipost og visning av innhold i innboksen, arkivet og på kjøkkenbenken, samt kvitteringer mottatt fra butikker som støtter dette. Applikasjonen er utviklet for avdelingen Digipost ved Posten Norge AS i samarbeid konsulentselskapet Bekk Consulting AS. 3 STIKKORD Android Digipost Kvalitetssikring

3 Innhold' ' Denne'dokument'inneholder'følgende'delrapporter'og'vedlegg.' ' Presentasjon' Kravspesifikasjon' Prosessrapport' Produktrapport' Testrapport' Android=sammendrag'(vedlegg'1)' Ordliste'(vedlegg'2)' Kilder'(vedlegg'3)' Attest'fra'oppdragsgiver'(vedlegg'4)' Attest'fra'kunde'(vedlegg'5)' Apache'2.0'lisens'(vedlegg'6)'

4 Presentasjon PRESENTASJON FORORD Dette prosjektet er et produkt av et semesters arbeid på Høgskolen i Oslo og Akershus (HiOA), avdeling for ingeniørutdanning. Det har vært et utfordrende og ambisiøst prosjekt, hvilket har resultert i en fullverdig Android applikasjon for brukere av Digipost. Vårt arbeid ville aldri vært mulig uten våre veiledere, bidragsyterne og andre frivillige. Denne seksjonen er dedikert til dere. Vi ønsker å gi en stor takk til de personene i Bekk Consulting AS (BEKK) som har hjulpet oss gjennom utviklingen av prosjektet. Takk til Espen Herseth Halvorsen som har vært vår veileder: Uten deg og din kompetanse og oppfølging gjennom prosjektet ville vi ikke kunne produsert en applikasjon med samme profesjonalitet. Takk til Olav Bjørkøy for verdifulle tilbakemeldinger angående utforming av brukergrensesnitt. Takk til Erlend Oftedal, leder for sikkerhetsgruppen i Bekk: Dine råd og meninger har gitt oss trygghet under utviklingen av løsninger angående datasikkerheten. Takk til Sindre Nordbø for tilbakemeldinger på problemstillinger knyttet til Android. Takk til Martin Bekkelund, produkteier for Digipost: Du ga oss muligheten til å utføre prosjektet og har gjennom hele prosessen vist entusiasme for vårt arbeid. Du lot oss også få sitte på Postgirobygget i et profesjonelt arbeidsmiljø sammen med Digipost sine utviklere. For oss som studenter har denne erfaringen vært utrolig nyttig. Til slutt vil vi rette en spesiell takk til vår veileder ved Høgskolen i Oslo og Akershus, Eva Hadler Vihovde: Din oppfølging og erfaring fra tidligere prosjekter har vært gull verdt. Signert Oslo Side 1 av 8

5 Presentasjon INNHOLD Forord... 1 Innledning... 3 Om Gruppen... 3 Om oppdragsgiver... 4 Posten Norge AS / Digipost... 4 BEKK Consulting AS... 4 Bakgrunn for oppgaven... 5 Hvordan vi ble med:... 6 Oppgavens mål... 6 beskrivelse av applikasjonen... 7 Side 2 av 8

6 Presentasjon INNLEDNING Hensikten med dette dokumentet er å presentere de involverte parter, bakgrunn for oppgaven og gi leseren et innblikk i hva oppgaven går ut på. Ved lesing av de andre dokumentene i rapporten, legges det til grunn at dette dokumentet er lest først. For å kunne beskrive applikasjonen mest mulig korrekt var det nødvendig å benytte en del fremmede ord og uttrykk, disse er enten beskrevet i den medfølgende ordlisten (vedlegg 1) eller i Android vedlegget (vedlegg 2). OM GRUPPEN Vi er tre dataingeniørstudenter som etter tre år på HiOA har blitt gode venner både i og utenfor skolesammenheng. Gruppen består av Sigurd Hagen Falk, Fredrik Thorbjørnsen Lillejordet og Fredrik Stenbro. Det var en tilfeldighet at to av oss etter få uker ut i første skoleår innledet en slags kollokviegruppe for samarbeid i samtlige fag. Noen måneder senere kom vi i kontakt med sistemann og ble fort en spleiset gruppe. Vi erfarte raskt at vi hadde samme ambisjonsnivå og at alle kunne bidra med relevant og forskjellig kunnskap. Etter snart 3 år på HiOA har samarbeidet foregått på flere plan, både som studenter i gruppearbeid og kollokviegruppe, men også som kolleger som studentassistenter under studiet. Det lå derfor i kortene at samarbeidet også skulle fortsette i form av hovedprosjektoppgaven. Vi er alle veldig interesserte i å utvide vår faglige kompetanse og har lenge hatt en ønske om å komme i gang med applikasjonsutvikling til mobile enheter. Figur 1: Organisasjonskart Side 3 av 8

7 Presentasjon OM OPPDRAGSGIVER POSTEN NORGE AS / DIGIPOST Posten Norge AS (Posten) er et nordisk post- og logistikkonsern som utvikler og leverer helhetlige løsninger innenfor post, kommunikasjon og logistikk - med Norden som hjemmemarked. Konsernet har over dyktige og kvalitetsbevisste medarbeidere, som jobber for å lever for å levere. Figur 2: Digipost-logo Digipost er et digitalt postsystem utviklet av Posten. Gjennom Digipost får brukerne tilgang til en egen digital postkasse, tilsvarende dagens fysiske postkasse. Denne kan benyttes til sikker kommunikasjon mellom privatpersoner og private og offentlige virksomheter. Fordi Digipost gjør det mulig å sende digital post basert på postadresser, er det svært enkelt å finne frem til riktige mottakere. For å sikre et godt resultat stilte Posten med Direktør for produkt- og forretningsutvikling Martin Bekkelund. Martin hadde en rolle som produkteier for appen som blant annet innbar at han kom ønsker om funksjonalitet og at han kunne ta avgjørelser når vi kom til Posten med flere alternative løsninger. Martin sørget for at vi fikk kontorplass på Posthuset i nærheten av Digipostteamet og ellers alt vi trengte. Posten vil bli referert til som kunden i det videre arbeidet. BEKK CONSULTING AS BEKK er et norsk konsulentselskap. De gjennomfører prosjekter for store private og offentlige virksomheter innen strategisk rådgivning, utvikling av IT-systemer og design av digitale tjenester. De har i dag omkring 330 ansatte, kontorlokaler på Vippetangen i Oslo og på Sluppen i Trondheim. Siden BEKK er et konsulentselskap holder de fleste ansatte til ute på prosjekt og sitter derfor i lokalet til kundene. Figur 3: Bekk-logo Til prosjektet vårt stilte BEKK med en hovedveileder: Espen Herseth Halvorsen, Espen er utdannet sivilingeniør fra Norges teknisk-naturvitenskaplige universitet (NTNU) og jobber som seniorkonsulent i BEKK. Han deltar i Digipost-prosjektet hos Posten. Vi har hatt ukentlige møter med Espen gjennom hele perioden, der vi kontinuerlig har kommet med statusoppdateringer. Han har også sørget for å inkludere eventuelle andre personer som kunne bistå oss om det var behov. I tillegg til Espen har vi fått god hjelp av flere dyktige konsulenter hos BEKK: Olav Bjørkøy har bistått oss tilbakemeldinger angående grensesnitt. Erlend Oftedal har vi kunnet drøfte sikkerhetsutfordringer med. Sindre B Nordbø har kommet med tilbakemeldinger angående Android brukeropplevelse. BEKK vil bli referert til som oppdragsgiver i det videre arbeidet. Side 4 av 8

8 Presentasjon BAKGRUNN FOR OPPGAVEN Formålet med Digipost er å erstatte den eksisterende løsningen for utsendelse av konfidensiell post med sikker elektronisk post. Hver konto er basert på postadresse. Her kan lønnsslipper, kvitteringer og annen personlig eller konfidensiell post sendes på en trygg måte. Digipost tilbyr også stor lagringsplass i et personlig arkiv der brukeren kan lagre post, dokumenter og annet. For Android-brukere var eksisterende løsning kun en nettside tilpasset mobile enheter med hensyn til skjermstørrelse. Det eksisterer en native Digipost versjon for ios som et eksternt firma, Shortcut AS, har utviklet på oppdrag fra Digipost, dette ble lansert i 2011 og har vært under kontinuerlig utvikling siden. Mange ser ikke det umiddelbare poenget med å ta i bruk Digipost når de allerede har e-post og postboks, eller har vanskeligheter med å gjenkjenne forskjellen mellom disse. Før prosjektstart hadde heller ikke vi et så klart bilde av hva Digipost var og hvorfor det er et så stort vakum i markedet for denne typen tjeneste. Kort oppsummert kan dette forklares med at Digipost er sikker elektronisk post til deg som person registrert med personnummer, i motsetning til e-post som er elektronisk post sendt til en adresse ofte gitt ved ( fornavn.etternavn@bedrift.landkode ) eller brevpost sendt til en fysisk adresse et sted i verden angitt av gatenavn, nr, område, by/sted og land. Dette byr på mange fordeler for deg som mottaker eller avsender sammenlignet med vanlig post og e-post. De viktigste fordelene vi ser er: For mottaker: posten din blir sendt kryptert fra avsender til deg som mottaker man mottar posten rett etter at den er sendt uavhengig av adresseendring eller navnbytte motta post uavhengig av hvor man er i verden siden det er kostbart å sende store volum for bedrifter blir det lite søppelpost ingen kan lese dokumentene under transport varsling på SMS om ønskelig For avsender: enkelt å finne mottakere siden mottaker unike, kan man ikke sende feil trygghet om at mottaker har mottatt dokumentet rimeligere enn brevpost mulighet for å kreve at bruker autentiserer seg med BankID ved åpning av brev mindre papir Disse fordelene betyr enormt mye med tanke kommunikasjon med meldinger, de gjør at ting som tidligere ikke var mulig raskt, enkelt og sikkert. Typiske scenarioer for dette er: brev fra helseforetak med personlige opplysinger om sykdomstilstand personlige brev lønnslipper med fra arbeidsplass strømregninger fra leverandør Side 5 av 8

9 Presentasjon Digipost tilbyr også opplasting til et sikkert arkiv hvor dataen din ligger trygt lagret. Siden det eksisterer en ios versjon har Digipost etter stor etterspørsel fra sine kunder bestemt seg for å utvikle en native Digipost app for Android. HVORDAN VI BLE MED Høsten 2012 sendte vi ut søknader per e-post til de mest spennende IT-bedriftene vi visste om. Etter kort tid ble vi invitert av Christian Schwarz til å komme på et uforpliktende møte hos BEKK for å snakke om mulige bacheloroppgaver. Christian viste oss flere spennende alternativer. Da han fortalte om Digipost for Android ble vi veldig interesserte - dette virket som noe vi virkelig kunne tenke oss å jobbe med. Da Christian påpekte at dette var noe Digipost ønsket a sette i produksjon i løpet av våren og ha tilgjengelig som åpen kildekode, takket vi umiddelbart ja! Det var jo en drømmeoppgave sett med våre øyne. OPPGAVENS MÅL Hensikten med en egen applikasjon til Android er å gjøre det lettere og mer brukervennlig å benytte seg av Digipost sine tjenester på mobile enheter som har Android operativsystem. Applikasjonen skal ha samme funksjonalitet som den allerede eksisterende applikasjonen for IPhone og IPad. Applikasjonen skal tilby å: la brukere logge seg inn med fødselsnummer og passord vise lister brev, dokumenter på kjøkkenbenken og i arkivet vise kvitteringer som en liste åpne brev, dokumenter og kvitteringer flytte brev og og dokumenter slette brev, dokumenter og kvitteringer oppdatere lister på en god måte søke i listene med brev, dokumenter og kvitteringer Applikasjonen skulle i utgangspunktet programmeres med Android SDK basert på Java og XML, men det ble etter hvert klart at Android NDK basert på C også måtte tas i bruk for å oppnå ønsket funksjonalitet. Begrunnelsen for dette følger senere i rapporten. Det var viktig at designet ikke skulle være en kopi av applikasjonen for IPhone og IPad. Det ble derfor bestemt at Google sine retningslinjer for Androidutvikling skulle følges slik at sluttbrukeren skulle sitte igjen med følelsen en optimalisert applikasjon for sitt operativsystem. Side 6 av 8

10 Presentasjon BESKRIVELSE AV APPLIKASJONEN Applikasjonen gir digipostbrukere med en androidenhet muligheten til sikker innlogging mot Digipost og visning av innhold i innboksen, arkivet og på kjøkkenbenken, samt kvitteringer mottatt fra butikker som støtter dette. Brukeren trenger kun å taste inn innloggingsdata en gang, og vil etter dette være sikkert innlogget helt til utlogging. Det er implementert visning av PDF basert på et C-bibliotek utviklet i Android NDK og modifisert av oss for å passe applikasjonen. Visning av HTML og diverse bildeformater er også implementert. For enkelt å kunne finne frem i en økende mengde innhold, er det mulighet for å filtrere basert på søketekst. Det har vært et omfattende arbeid å tilegne oss de kunnskaper som er nødvendig for å utvikle en god applikasjon for Digipost sine brukere. Sikkerheten bør nevnes spesielt. Alle brev som mottas i Digipost skal anses å være sensitive. Vi har under hele perioden hatt en pågående dialog med oppdragsgiver for å diskutere og bestemme oss for sikkerhetsløsning slik at det blir håndtert på en tilfredsstillende måte. Designet er utformet med tanke på å gjenspeile Digipost sitt konsept med bruk av Googles retningslinjer for Androidutvikling, slik at brukergrensesnittet er kjent og logisk riktig etter de standarder android-brukere er vant med. Applikasjonen er lansert i første versjon og ligger tilgjengelig på Google Play. Både kunde og Figur 4: Skjermbilde, arkiv oppdragsgiver har gitt uttrykk for at de er meget fornøyd med resultatet. Applikasjonen har per dags dato i underkant av nedlastinger. Figur 6: Google play-logo Figur 5: Android robot Side 7 av 8

11 Presentasjon < Denne siden skal være blank > Side 8 av 8

12 Kravspesifikasjon KRAVSPESIFIKASJON FORORD Hensikten med kravspesifikasjonen er å gi oppdragsgiver og utviklere en enighet og forståelse av funksjonaliteten til applikasjonen som skal produseres. Kravspesifikasjonen definerer i tillegg prosjektets rammer og krav til funksjonalitet og design. Utviklingsprosessen foregår smidig ved bruk av utviklingsverktøyet Trello (beskrevet i prosessdokumentasjonen). Å jobbe på denne måten vil si å levere produktet fortløpende i delleveranser slik at deler av funksjonaliteten blir implementert og kan bli godkjent av kunden. Kravspesifikasjonen er basert på de krav som ble stilt både ved prosjektstart og under utviklingsfasens iterasjoner. Kravene til prosjektgruppen ble gitt både som individuelle funksjonaliteter og referanser til eksisterende applikasjoner. Implementasjon av denne funksjonaliteten blir diskutert i prosess- og produktrapportene. Kravene ble delt i to forskjellige kategorier - minimumskrav og ønsket ekstrafunksjonalitet. Minimumskravene ble ansett som førsteprioritet, mens ønsket ekstrafunksjonalitet ble sett på som mulige arbeidsoppgaver om tiden tillot. Kravspesifikasjonen har fungert som et styringsdokument for gruppen, og har endret seg fortløpende ut fra erfaringer og kunnskap utviklet underveis i prosjektet. Samtidig oppdaterte vi kravspesifikasjonen når vi mottok nye ønsker fra oppdragsgiver. Side 1 av 8

13 Kravspesifikasjon INNHOLD Forord... 1 Innledning... 3 Bakgrunn for oppgaven... 3 Systemkrav... 3 Kundens krav til funksjonalitet... 3 Ønsket tilleggsfunksjonalitet... 4 Tekniske krav... 4 Krav til koden... 4 Sikkerhetskrav... 4 Krav til grensesnitt... 5 Generelle designkrav... 5 Bruk av farger og fonter - merkevarebygging... 5 Dokumentasjonskrav... 5 Konklusjon... 6 Side 2 av 8

14 Kravspesifikasjon INNLEDNING Prosjektet gjennomføres som et hovedprosjekt ved Høgskolen i Oslo og Akershus (HiOA) avdeling for ingeniørutdanning for Bekk Consulting AS og deres kunde Get AS. Det skal produseres en applikasjon for Digipost for Android-baserte smarttelefoner. Applikasjonen skal ha samme funksjonalitet som dagens versjon på ios, og være designet i tråd med Google sine retningslinjer for Android-utvikling. Bekk skal utvikle denne applikasjonen for Digipost (heretter referert til som kunden) og vi vil utvikle applikasjonen for Bekk (heretter referert til som oppdragsgiver). Innledningsvis bestod kravspesifikasjonen av kundens krav til funksjonalitet, som innebærer at applikasjonen skulle ha samme funksjonalitet som den eksisterende applikasjonen for ios. Videre funksjonelle krav har blitt lagt til underveis i utviklingsprosessen. En konsekvens av dette har vært at vi ikke har hatt en kravspesifikasjon som et ferdig styringsdokument fra starten. Krav til design og kode har blitt satt i samarbeid med oppdragsgiver og kunden. BAKGRUNN FOR OPPGAVEN Som orientert om i presentasjonen er formålet med Digipost er å erstatte den eksisterende løsningen for utsendelse av konfidensiell post med sikker elektronisk post. Hver konto er basert på postadresse. Her kan lønnsslipper, kvitteringer og annen personlig eller konfidensiell post sendes på en trygg måte. Digipost tilbyr også stor lagringsplass i et personlig arkiv der brukeren kan lagre post, dokumenter og annet. For Androidbrukere var eksisterende løsning kun en nettside tilpasset mobile enheter med hensyn på skjermstørrelse. Det eksisterer en native Digipost versjon for ios som et eksternt firma, Shortcut AS, har utviklet på oppdrag fra kunden. Dette ble lansert i 2011 og har vært under kontinuerlig utvikling siden. Kunden ønsker seg nå en applikasjon for mobile enheter som benytter Android operativsystem. SYSTEMKRAV KUNDENS KRAV TIL FUNKSJONALITET Kundens grunnleggende krav er å implementere all funksjon dagens ios-applikasjon tilbyr. Følgende krav som satt av kunden beskriver grunnleggende funksjonalitet til applikasjonen og applikasjonen skal tilby: pålogging med OAuth2 og sikker lagring av refresh token ny access token basert på refresh token skal skje automatisk uten at bruker merker det tvinge innføring av skjermlås med passord eller fingerbevegelse for å sikre innhold ved tyveri av telefonen utlogging liste ut metadata o liste ut brev i postkassen o liste ut brev på kjøkkenbenken o liste ut innhold i arkivet o liste ut elektroniske kvitteringer vise innhold knyttet til metadata o vise pdf o vise html Side 3 av 8

15 Kravspesifikasjon flytte brev fra postkasse til arkiv flytte brev fra postkasse til kjøkkenbenk flytte brev fra kjøkkenbenk til arkiv og visa versa ØNSKET TILLEGGSFUNKSJONALITET Følgende krav er tilleggsfunksjoner som gjennom utviklingsprosessen ble ønsket av oppdragsgiver, disse funksjonene er ikke nødvendigvis implementert i kundens eksisterende mobilapplikasjoner, men ønskes utforsket og eventuelt implementert: sikker lagring av brev opplastning til arkiv offline-funksjonalitet/ hendelseskø push-notifications TEKNISKE KRAV applikasjonen skal utvikles i Java, XML og C applikasjonen skal kunne kjøres på Androidenheter med operativsystemversjon 4.0 eller høyere applikasjonen skal fungere på alle Android telefoner, Android nettbrett og Android PCer som oppfyller versjonskravenene funksjonalitet på bekostning av kjente sikkerhetshull eller mangler skal ikke implementeres data skal lagres kryptert brukeren skal vente kortest mulig på at innhold lastes ned nettverksspørringer skal utføres i egne programtråder nettverksbruken skal minimeres ved nedlastning av store filer skal det være mulig å avbryte underveis KRAV TIL KODEN Vi ble enige om at all kode og alle kommentarer skal skrives på engelsk, og føre en konsekvent linje på det. Ellers skal koden være mest mulig oversiktlig, og gjøre det enklest mulig for kunden å overta, vedlikeholde og videreuvikle applikasjonen. Utviklingsmønsteret MVC skal benyttes for å strukturere koden Navn på klasser, metoder og variabler skal være såpass forklarende at det ikke er nødvendig med kommentarer Koden skal implementeres og struktureres slik at den enkelt kan utvides med ny funksjonalitet SIKKERHETSKRAV Følgende sikkerhetskrav stiller Digipost til applikasjoner som skal benytte deres API. Trafikken skal krypteres all trafikk som inneholder tokens eller Digipost-data skal krypteres, f.eks. ved å bruke HTTPS Side 4 av 8

16 Kravspesifikasjon Refresh_tokens skal lagres kryptert disse har samme verdi som passord, og kan f.eks. lagres i keychain eller krypteres med en sterk kryptering (f.eks. AES256). Dersom man krypterer med egne krypteringsnøkler, skal disse lagres adskilt fra refresh_tokens (ikke holde begge to i samme database). Det skal benyttes forskjellig krypteringsnøkkel i utviklingsmiljø og produksjon. De skal ikke benyttes som parametere i URL-er eller lignende Access tokens skal ikke lagres i klartekst disse skal ha samme verdi som en sesjons-id. Disse kan normalt sett bare holdes i minnet pga. kort varighet på tokenet, men skal man lagre dem på disk, bør de lagres på tilsvarende måte som refresh tokens. Access tokens skal ikke benyttes som parametere i URL-er eller lignende Client secret skal lagres kryptert Se krav for refresh token. Dette gjelder ikke for mobilapplikasjoner e.l. State skal brukes og sjekkes state-parameteren skal gis en unik kryptografisk tilfeldig verdi, og denne skal senere sjekkes Ved bruk av Digipost for innlogging, skal id token verifiseres - signatur og client id skal verifiseres. Ugyldige tokens skal forkastes KRAV TIL GRENSESNITT GENERELLE DESIGNKRAV Applikasjonen skal føles som en fullverdig Android applikasjon Navigasjonen skal føles enkelt og intuitivt Grafiske elementer skal ha et flatt og moderne utseende Bruker skal sitte igjen med inntrykk av et ferdig produkt Ikoner skal se bra ut sammen med andre applikasjoner på Hjem-skjermen Bruker skal få varslinger som står i stil med varslingsgrunnlaget Det skal være enkelt å endre designelementer i ettertid BRUK AV FARGER OG FONTER - MERKEVAREBYGGING Det skal brukes farger fra webutgaven Det skal brukes standard Android font (Roboto Regular) DOKUMENTASJONSKRAV Eneste kravet til dokumentasjonen fra oppdragsgiver og kunde var at innholdet ikke skulle være i strid med de taushetserklæringer og andre avtaler vi har skrevet under på i forbindelse med prosjektet. Side 5 av 8

17 Kravspesifikasjon KONKLUSJON Kravspesifikasjonen har spilt en sentral rolle for oss da vi konkretiserte prosjektets rammer og omfang. Prosjektets rammer var definert på en måte som gjorde at utviklingen av selve applikasjonens funksjonalitet var fleksibel og tilpasningsdyktig. Ved å ha et krav om at applikasjonen skulle ha samme funksjonalitet som kundens øvrige mobilapplikasjoner, men mulighet for ny funksjonalitet gjennom nye iterasjoner, hadde vi et godt fundament for hva som skulle jobbes med, samtidig som kunden var sikret et brukbart produkt ved prosjektslutt. Det ferdige produktet tilfredsstiller alle krav fra kunden, både med tanke på funksjonalitet, design og kode. Ekstrafunksjonaliteten ble funnet for tidkrevende å implementere, men med de utfordringene vi har hatt rundt den øvrige funksjonaliteten har kunden likevel ytret at vår innsats har oversteget deres forventninger. Basert på dette og tilbakemeldinger fra oppdragsgiver og kunden, legger vi til grunn at vårt produkt samsvarer med kravspesifikasjonen og overgikk forventningene fra oppdragsgiver og kunden. Oppfyllelse av krav er i mer detaljert form beskrevet i produktrapporten. Side 6 av 8

18 Kravspesifikasjon < Denne siden skal være blank > Side 7 av 8

19 Kravspesifikasjon < Denne siden skal være blank > Side 8 av 8

20 Prosessrapport PROSESSRAPPORT FORORD I denne rapporten vil vi beskrive prosessen bak utviklingen av Digipost for Android. Vi forutsetter at leseren har lest presentasjonsdokumentet og gjort seg kjent med helheten i dokumentasjonen. Noen kapitler forutsetter også at leseren er kjent med teknologier og tekniske aspekter. Ellers oppfordres det til å benytte Android-sammendraget (vedlegg 1) og ordlisten (vedlegg 2) ettersom tekniske ord og uttrykk vil bli benyttet uten forklaring. Vi beskriver hvordan arbeidsprosessen gjennom hele hovedprosjektet har vært for vår gruppe.. Den består av fire kapitler i følgende rekkefølge: Planlegging og metode: Tar for seg planleggingen, hvordan vi har jobbet sammen, kommunikasjon med oppdragsgiver og kunde, arbeidsfordeling og prosjektstyring. Til slutt gis en oversikt over verktøy og teknologi som er benyttet Utviklingsprosessen: Her beskrives prosjektes gang fra konseptutvikling til programmering av funksjonalitet og design. Vi begrunner våre løsninger, samt beskriver de utfordringer vi har møtt på veien mot et ferdig produkt Kravspesifikasjonen og dens rolle: Tar for seg nytteverdien av kravspesifikasjonen og dens viktighet i en så omfattende oppgave vi har utført Avsluttende del: Presenterer våre tanker rundt læringsutbyttet og produktet og gir en avsluttende konklusjon Den som skal vurdere rapporten, bør legge spesielt fokus på utviklingsprosessen. Vi ønsker at denne delen spesielt i sammenheng med produktrapporten. Det vil i produktrapporten bli beskrevet de tekniske finessene bak utfordringene og valgene hver funksjonalitet beskrevet i denne rapporten har medført. Delkapitlene læringsutbytte og det ferdige produktet under kapittelet avsluttende del bør også leses under vurderingen. Side 1 av 38

21 Prosessrapport INNHOLD Forord... 1 Planlegging og metode... 5 Forløp til prosjektstart... 5 Arbeidsteknikker og utviklingsmetoder... 5 Smidig utvikling... 5 Kommunikasjon med kunde/veileder... 8 Prosjektstyringsdokumenter... 9 Arbeidsplan... 9 Fremdriftsplan... 9 Arbeidslogg... 9 Arbeidsforhold Postgirobygget HiOA Verktøy Versjonskontroll Prosjekthåndtering Dokumentasjon Utviklingsverktøy Utvidelser og rammeverk Analyseverktøy Android Utviklingsprosessen Konseptutvikling Datainnsamling Målgruppe og behov Gruppemøter og Brainstorming Side 2 av 38

22 Prosessrapport Presentasjon av konsept for oppdragsgiver og kunde Utvikling med Android SDK og Android NDK Fordeler og ulemper med native utvikling Open source REST-rammeverket Implementering av funksjonalitet Testing Sikker lagring Minnebruk Utforming av brukergrensesnitt Navigasjonsvalg Dokumentbehandling Fargevalg Grafikk Helhetlig følelse Personvern Kravspesifikasjon og dens rolle Bakgrunn for kravspesifikasjon Rammekrav Fortløpende endringer Vår erfaring med kravspesifikasjonen Kravspesifikasjonen av det endelige produktet Oppfyllelse av krav og/eller måloppnåelse Tilbakemelding fra oppdragsgiver og kunde Konklusjon Google Analytics Avsluttende del Side 3 av 38

23 Prosessrapport Ord fra oppdragsgiver Ord fra kunden Samarbeid i gruppen Konfliktløsing og konstruktive diskusjoner Veiledning ved HiOA Læringsutbytte Det ferdige produktet Nytteverdi Videre utvikling Fora for brukerdialog Google Play som kanal Twitter lab.digipost.no Konklusjon Side 4 av 38

24 Prosessrapport PLANLEGGING OG METODE God planlegging er essensielt for å oppnå et godt resultat. I dette kapittelet vil vi beskrive teknikker, metoder, verktøy og hjelpemidler som har hjulpet oss med å oppnå et vellykket prosjektarbeid. FORLØP TIL PROSJEKTSTART Det første gruppemøtet fant sted tidlig i oktober Møtets hensikt var å få kartlagt tanker og ideer, hvilke teknologier vi ønsket å benytte og hva vi generelt så for oss som aktuelt å jobbe med. Ideene haglet og engasjementet var på topp! Vi diskuterte også hvilke virksomheter som var potensielle oppdragsgivere og som kunne tilby et prosjekt som samsvarte med de visjonene vi hadde. Vi noterte ideer og aktuelle oppdragsgivere underveis. Etter idemyldringen satt vi igjen med en liste bedrifter og en vag formulering av hvordan oppgaven skulle se ut. Deretter måtte vi finne ut om bedriftene hadde en eksisterende ordning og tradisjon rundt det å tilby hovedprosjekter til studenter. Dette lot seg undersøke raskt på nettet. Vi opprettet første kontakt via e-post og telefonsamtaler og ble i de fleste tilfeller bedt om å sende over karakterer og et lite skriv om hvilke teknologier vi var kjent med og ønsket å jobbe med. Vi fikk mye positiv respons og interesse og flere tilbakemeldinger med forespørseler om å komme til uforpliktende møter. Vi var på flere interessante møter der vi ble introdusert for spennende oppgaver, men tok en rask avgjørelse hos BEKK da vi ble kjent med Digipost-oppgaven. Av de oppgavene vi ble introdusert til var dette oppgaven med størst omfang og mest spennende teknologi. Det faktum at applikasjonen skulle produksjonssettes og brukes av potensielt digipostbrukere, var også med i betraktningen og en del av motivasjonen. ARBEIDSTEKNIKKER OG UTVIKLINGSMETODER SMIDIG UTVIKLING Smidig utvikling har de siste årene blitt meget populært og er den mest brukte modellen for programvareutvikling. Begreper som Scrum, Kanban og Extreme Programming dukker opp i de fleste utviklingssammenhenger - representanter fra næringslivet hevder det er nøkkelen til en effektiv utviklingsprosess. Å definere hva smidig utvikling er kan være vanskelig, men disse tre påstandene kan være med å synliggjøre behovet: Du vil aldri klare å samle alle krav til en løsning før du begynner! Kravene vil garantert komme til å endre seg underveis! Det vil alltid være mer å gjøre enn man har tid til! Punktene er hentet fra I forkant av prosjektet hadde vi kun et teoretisk bekjentskap til disse metodikkene, blant annet fra skolefag og media. Vi skjønte fort at det ikke nyttet med de tradisjonelle metodene som for eksempel Fossefallmetoden og Unified Process. Det vi trengte var en lettvekter innfor smidighetsmodellen som hadde en iterativ og inkrementell arbeidsform siden rammene for prosjektet sannsynligvis ville endres underveis. Side 5 av 38

25 Prosessrapport Det var naturlig for oss å velge Extreme Programming (XP), en utviklingsmodell som har flere egnede faktorer som parprogrammering, brukerinteraksjon under utviklingen og som tillater iterativ og inkrementell utvikling. I kombinasjon med XP har vi benyttet Trello, et prosjekthåndteringsverktøy beskrevet i neste delkapittel. Å velge smidighetsmodell var ikke en tidskrevend oppgave, men vi ønsket alikevel å være bevisste på dette valget. EXTREME PROGRAMMING XP er en utviklingsmetodikk med fokus på enkelhet, fleksibilitet og løpende endring i kundebehov. Det er de korte sprintene med høy produktivitet som gjør denne metodikken egnet for små til mellomstore prosjekter, eller som delmetodikk i store prosjekter. Følgende punkter beskriver XP: Iterativ og inkrementell utvikling Brukerinteraksjon under utviklingen Omfattende kodegjennomgang og refaktorisering Testing av all kode Implementasjon ved behov Parprogrammering Kommunikasjon BEGRUNNELSE FOR BRUK AV EXTREME PROGRAMMING Vi var på forhånd ikke innstilt på å legge mye tid eller arbeid i å følge en omfattende utviklingsmetodikk slavisk. Dette kunne medføre tap av tid i form av unødvendig forarbeid og planlegging som i stor del allerede var utført av kunden. Rammene, samt en stor del av funksjonaliteten var allerede på plass. Mye var dermed tilrettelagt for at utviklingen av selve applikasjonen kunne påbegynnes forholdsvis tidlig. Vi hadde kjennskap til teorien rundt XP og visste at den var enkel å bruke og tillot stor grad av fleksibilitet og endringsmuligheter. Vi visste også at samarbeidet i stor grad kom til å foregå rundt samme bord, som ga mulighet for parprogrammering. VÅR ERFARING MED XP Å benytte XP i praksis, har i liten grad vært et moment vi har måttet følge opp og bruke tid på. Dette fordi den naturlige måten å samarbeide på i dette prosjektet ville vært av lignende natur. Vi har likevel dratt nytte av flere aspekter i metodikken. Parprogrammering har forekommet på en daglig basis, og i denne sammenheng har også kodegjennomgang og refaktorisering av kode fulgt naturlig. I en applikasjon som håndterer sensitiv informasjon er det ikke rom for feil. Derfor har det vært viktig for oss å kvalitetssikre koden. Grundig testing har vært en stor del av utviklingsarbeidet. Fleksibiliteten og endringsmulighetene til XP har også vært verdifullt ettersom vi hatt en løpende dialog med fremtidige brukere som har ytret sine meninger på våre kommunikasjonskanaler. Det var spesielt viktig etter beta-versjonen. Side 6 av 38

26 Prosessrapport TRELLO Trello er et verktøy for prosjekthåndtering basert på et brett bestående av flere lister som inneholder mange kort. I denne sammenhengen representerer brettet selve prosjektet, hver liste en tilstand og hvert kort oppgaver som har oppnådd denne tilstanden. Alle prosjektdeltakere kan legges til brettet og på den måten erklære sin avhengighet og sitt ansvar til arbeidsoppgaver i de forskjellige listene. Det er også mulighet for å kommentere på kort, sette opp sjekklister, legge ved filer med mer. Siden Trello er en nettbasert tjeneste oppdateres prosjektfremgangen i sanntid. HVORFOR UTVIKLE MED TRELLO? Ingen av oss var fra før kjent med Trello som utviklingsverktøy. Det var våre veiledere som introduserte oss for verktøyet på første ukentlige møte. Vi ble fortalt at Digipost sine utviklere benyttet seg av dette med suksess. Ved å bruke Trello kunne både kunde og oppdragsgiver følge prosjektutviklingen tett, samt være tilgjengelig for å svare på kommentarer vi måtte komme med på oppgaver under arbeid. Det var et ønske at vi skulle ta i bruk verktøyet. HVORDAN VI UTVIKLET MED TRELLO Figur 7: Trello Et brett ble opprettet under navnet Digipost for Android. Alle med tilknytning til prosjektet ble gitt tilgang til å lese, samt redigere. Videre opprettet vi følgende lister: Info: Informasjonskanal mellom oss, kunde og oppdragsgiver. Her la vi kort knyttet til prosjektet, men ikke direkte relevant for selve utviklingen av funksjonalitet. Milepæler: Tidsbestemte kort som utgjorde vår milepælsplan. Prioritert backlog: Funksjonalitet og ideer til funksjonalitet som enda ikke var ferdig utviklet. De forskjellige kortene ble markert enten Must have eller Nice to have avhengig av prioriteten. Under arbeid: Kort hentet fra prioritert backlog som det ble jobbet med å implementere. Trenger tilbakemelding fra Digipost: Ferdig funksjonalitet som trengte en vurdering/ tilbakemelding fra veileder. Ferdig (Beta): Funksjonalitet ferdig til betaversjonen. Ferdig (Versjon 1.0): Funksjonalitet ferdig til første versjon. Ferdig (Andre ting): Andre praktiske ting utført i sammenheng med prosjektet, men ikke direkte relevant til selve utviklingen av funksjonalitet. Gangen i implementering av funksjonalitet startet med at vi valgte ut det høyest prioriterte kortet i listen prioritert backlog. Deretter ble vi enige om hvem som skulle få ansvar for arbeidet. Den ansvarlige oppdaterte så kortet med sjekklister over hvilke deloppgaver som måtte utføres for å ferdigstille funksjonaliteten. Kortet ble deretter flytte over til under arbeid. Dersom det var nødvendig med tilbakemelding fra veileder var neste stopp trenger tilbakemelding fra Digipost. Hvis utbedringer var Side 7 av 38

27 Prosessrapport nødvendig, ble det iterert tilbake til under arbeid. Hvis ikke ble funksjonaliteten ansett som ferdig og plassert i den riktige listen for ferdigstilte kort. Under hele utviklingsperioden hadde vi hatt en løsning for at oppdragsgiver og kunde skulle kunne laste ned en oppdatert utgave av applikasjonen. Hver gang et kort ble plassert i listen ferdig, ble det lastet opp en ny versjon for dem å laste ned og teste. Med dette oppnådde vi en kontinuerlig testing og et bra grunnlag for veileder å komme med tilbakemeldinger på vårt arbeid. VÅR ERFARING MED TRELLO Å jobbe med en smidig utviklingsmetodikk var en ny og lærerik prosess for oss i gruppen. Ved tidligere prosjekter har vi hatt langsiktige mål, og underveis ikke jobbet med små, konkrete delmål. Her fikk vi derimot erfare hvordan det var å jobbe med konkrete delmål underveis. Å utvikle i Trello ga oss også muligheten til å starte på kodingen umiddelbart etter konseptutviklingsfasen. Trello sin oppbyggning med kort som flytter seg fra fase til fase har vært en motiverende faktor for oss i gruppen. Vi har alltid hatt en følelse på hvordan vi ligger an, og kort har alltid blitt flyttet fra under arbeid til ferdig med et preg av stolthet. Trello har også vært en viktig kanal for kommunikasjon med veileder. Siden dette er et verktøy Digipost sine utviklere bruker daglig og alltid er pålogget, har det vært rask respons på våre spørsmål og kommentarer. KOMMUNIKASJON MED KUNDE/VEILEDER Gjennom utviklingsprosessen har vi hatt ukentlige møter med veileder og kunde. Her har vi gitt statusoppdateringer for utviklingen og drøftet eksisterende og ny funksjonalitet. Det har vært et forum for oppdragsgiver og kunde til å komme med deres tilbakemeldinger og forslag, samt for oss til å presentere vårt arbeid og komme med problemstillinger som er under arbeid. Disse møtene var veldig verdifulle under hele prosessen. Det at Digipost er en tjeneste som besitter privatpersoner sine konfidensielle brev, gir ikke rom for feil i sikkerheten til applikasjonen og ivaretakelse av personvern. I tillegg til de ukentlige møtene på Postgirobygget, har vi hatt sporadiske møter med veileder fra HiOA, Eva Hadler Vihovde. Temaet på disse møtene har vært planlegging av dokumentasjon underveis, strukturering og innhold i sluttrapporten. HiOAs veileder har hatt en mindre rolle i selve prosjektet, da vi følte oss relativt selvgående med hensyn til dokumentasjonen. Ved eventuelle spørsmål, var veileder derimot rask til å svare og korrigere eventuelle feil vi hadde gjort. Vi sitter igjen med et meget positivt inntrykk av arbeidsprosessen med vår veiledere. Kontinuerlig kommunikasjon og tilbakemelding bidro til å gjøre prosjektet så komplett og ferdig som overhodet mulig i den tildelte prosjektperioden. Side 8 av 38

28 Prosessrapport PROSJEKTSTYRINGSDOKUMENTER ARBEIDSPLAN Ved fornuftig bruk av Trello til utvikling, vil du også få mye prosjektstyring med på kjøpet. Vi brukte verktøyet til å føre opp tidsbestemte arbeidsoppgaver og milepæler. Milepælene har vært fastsatt fra starten av, mens arbeidsoppgavene var mer flytende etter vurdering av fremdriften i prosjektet. Arbeidsoppgaver ble også på Trello knyttet til personen som jobbet med dem slik at det var lett for veileder å ta kontakt dersom det skulle være behov for oppklaring. FREMDRIFTSPLAN Fremdriftsplanen ga oss en oversikt over hvor vi burde være på hvilket tidspunkt. Tidsbestemte Trello-kort under listen prioritert backlog gjorde det lett for alle involverte i prosjektet å følge progresjonen. Fremdriftsplanen ble kontinuerlig justert for endringer, og var et nyttig verktøy i både planleggingen og utføringen av prosjektet. ARBEIDSLOGG Vår arbeidslogg har i hovedsak vært historien over commits på Github. Vi har fra starten av vært nøye på at commits skulle ha gode beskrivelser. På denne måte ville det være lett å se hva som er gjort til hvilken tid og av hvem. Github har også muligheten til å vise grafer basert på forskjellige parametere fra commit-historien. I tillegg til Github opprettet vi en konto på Twitter knyttet til prosjektet. Her kom vi med kontinuerlige oppdateringer på arbeidet som ble gjort. Dette var opprinnelig et ønske fra kunden for å nå ut til den mest entusiastiske delen av deres brukere. Siden vi la ut oppdateringer om funksjonalitet og design, ga dette også en mulighet for personer utenforstående prosjektet til å gi tilbakemeldinger underveis. Side 9 av 38

29 Prosessrapport ARBEIDSFORHOLD Vi har i hovedsak arbeidet på Posthuset og på Høgskolen i Oslo og Akershus. Hvor vi har jobbet og når, har i stor grad vært avhengig av når vi skulle treffe veiledere. POSTGIROBYGGET I januar 2013 fikk vi utdelt adgangskort og faste plasser i 14. etg. på Postgirobygget, adgangskortene ga oss tilgang til bygget fra 07:00 til 22:00 på hverdager hele perioden. Siden vi hadde faste møter med ekstern veileder hver tirsdag, var det naturlig for oss å sitte her mandag til onsdag. Vi hadde tilgang til ansattkantine og spiste vi ofte lunsj sammen med kunde og oppdragsgiver. Vi hadde gratis tilgang til kaffemaskiner og på sene kvelder ble det bestilt pizza. HIOA På HIOA satt vi for det meste på Datatorget i 4. etg. i Pilestredet 35. Her var vi på torsdager og fredager. Figur 8: Utsikt fra kontoret på Postgirobygget VERKTØY Vi har benyttet oss av følgende verktøy og hjelpemidler for å gjennomføre hovedprosjektet: VERSJONSKONTROLL Et versjonskontrollsystem er programvare laget for å dele filer i prosjekter, og sørger for at endringer blir sammensmeltet. Versjonskontrollsystemer er essensielle for prosjekter med flere utviklere GIT MED GITHUB Git er et versjonskontrollsystem som vi tidligere har lært i forbindelse med andre prosjekter. Git har egne kommandoer, bl. a. pull og push, for synkronisering med andre repositorier. Dette muliggjør alle-til-allesynkronisering (ikke bare alle-til-en, som i CVS og SVN). Dessuten, uten implisitt synkronisering trenger man for eksempel ikke å være koblet til nettverk hele tiden for å kunne jobbe. Alt innhold i et Git-repositorium er indeksert etter sha1-sum. I tilfelle bitfeil i lagring eller overføring, kan man være rimelig sikker på at det vil oppdages. Fordi sjekksummen regnes for å være kryptografisk sikker, kan man stole på at ikke uvedkommende kan ha endret innholdet uten at dette også vil oppdages. Git er både raskt og godt til sammenfletting (merging) av kode. Figur 9: Octocat, Github Side 10 av 38

30 Prosessrapport Ved hjelp av Github, som er et web-basert hostingsystem for Git-prosjekter, har vi oversikt over hvem som har tilgang til hvem som jobber med prosjektet og hvilke endringer de gjør, samt oppgaver som må gjøres. Ved commit av endringer skrives en beskrivelse av endringen inn, som igjen kan sees av alle medlemmer på GitHub. Slik er det enkelt å se siste endringer gjort av andre. PROSJEKTHÅNDTERING TRELLO Trello er beskrevet tidligere i dette dokument. DOKUMENTASJON MICROSOFT WORD Microsoft Word er et tekstredigeringsprogram som gjør det enkelt å forfatte innhold, plassere grafikk og endre stiloppsett. GOOGLE DOCS Google Docs er et webbasert tekstredigeringsprogram som støtter at flere brukere skriver samtidig og har mulighet for å eksportere innhold som PDF eller Word-dokument. ADOBE PHOTOSHOP Adobe Photoshop er et bilderedigeringsprogram som gjør det enkelt å tegne og redigere bilder uten å forringe kvaliteten. Alle elementer i et dokument kan ligge i egne lag, dette gjør det lettere å kopiere og redigere enkeltelementer. DROPBOX Dropbox er en skybasert lagring og fildelingstjeneste som synkroniserer lagrede filer automatisk. UTVIKLINGSVERKTØY ECLIPSE Eclipse versjon 4, kodenavn Juno. Eclipse er en fullverdig Java IDE som har alt som skal til for å utvikle fullverdige Java applikasjoner med unntak av Java JDK. Eclipse ble konfiguert med formateringsreglene som brukes hos Digipost utviklere. JAVA DEVELOPMENT KIT (JDK) JDK er en programvareutviklings pakke for å utvikle, kompilere, debugge og overvåke java-applikasjoner. Side 11 av 38

31 Prosessrapport ANDROID SDK Android SDK er en programvareutviklingspakke som gjør det mulig å utvikle Android-applikasjoner. Android SDK inneholder mange nyttige verktøy, emulator og eksempler på applikasjoner medfølgende kildekode. Følgende er de mest brukte verktøyene som inngår i Android SDK: ANDROID DEBUG BRIDGE (ADB) ADB er et verktøy for å opprette forbindelse mellom Eclipse og en enhet eller emulator. Over denne forbindelsen kan man overføre data begge veier. Brukes oftest til å laste en ny versjon av en applikasjon for så å få tilbakemeldinger fra enheten. DALVIK DEBUG MONITOR SERVER (DDMS) DDMS benytter seg av ADB til å feilsøke applikasjoner kjørende på enhet eller emulator. Her kan man feilsøke nettverkstrafikk, diskplass, minnebruk mm. LOGCAT Logcat benytter seg av ADB for å samle inn og kategorisere systeminformasjon fra en enhet slik at man enklere kan finne den informasjonen man er ute etter ved hjelp av filtering. ECLIPSE MEMORY ANALYZER Eclipse Memory Analyzer er et enkeltstående kjapt og effektivt minneanalyseringsverktøy som gjør det lettere å lokalisere objekter Garbage Collector (GC) ikke klarer å håndtere på ønsket måte, slik at de forårsaker minnelekkasjer i applikasjonen. ANDROID NDK Android NDK er et rammeverk som lar deg utvikle applikasjoner i native programmeringsspråk som C og C++. CYGWIN Cygwin er et verktøy som simulerer linux-funksjonalitet på Windows. APACHE ANT Apache ANT er et hjelpeverktøy for å bygge java-applikasjoner fra kommandolinjen. UTVIDELSER OG RAMMEVERK MAVEN Side 12 av 38

32 Prosessrapport Maven er et verktøy for automatisk importering og bygging av Java-prosjekter. Det er eid av Apache Software Foundation. Maven bruker en XML-fil til å beskrive programvaren, avhengigheter til eksterne biblioteker og komponenter, byggerekkefølge, nødvendige plugin og lignende. Eksterne komponenter blir automatisk lastet ned fra Maven Central Repository og lagret i en lokal cache. JERSEY Jersey er en åpen kildekode-implementasjon for bygging av REST-tjenester i Java. JSON JSON er en tekstbasert struktur for enkel overføring av data. JACKSON Jackson er Java-bibliotek for prosessering av JSON til java-objekter. MUPDF MuPDF er et lettvekts bibliotek skrevet i C som konverterer sider i et PDF-dokument om til bilder, tekst i dokumentet er fortsatt søkbar ved visning. PHOTOVIEW PhotoView er bibliotek for å tolke bilder som ImageView på Android, PhotoView gitt ut som åpen kildekode under apache 2 lisens. POSTMAN REST CLIENT Postman REST Client er en Google Chrome utvidelse som gjør det enkelt å forstå eksterne REST APIer. Etter at man har opprettet en forbindelse til API via en autentiseringstjeneste som OAuth kan man åpne Postman og kjøre spørringer mot APIet, for så å motta svaret som JSON i en nettleser. Slik kan man gjøre spørringer og tolke svaret på en ryddig måte. ANALYSEVERKTØY GOOGLE ANALYTICS Google Analytics er et web-basert statistikk- og analyseverktøy som gjør det lett å samle inn og kategorisere data slik at man kan lage informasjon i form av bruksmønstre og andre relevante opplysninger. ANDROID Se eget dokument for innføring til Android operativsystem og dets retningslinjer for design (Vedlegg 1). Side 13 av 38

33 Prosessrapport UTVIKLINGSPROSESSEN Vi vil i dette kapittelet beskrive prosessen med å utvikle applikasjonen i flere faser. Den første og innledende fasen er konseptutvikling. Neste fase tar for seg implementering av funksjonalitet og utforming av brukergrensesnitt i to separate deler. Vi har valgt å separere disse delene for å få frem det omfattende arbeidet som er gjort på begge fronter, og for ikke å blande prinsipper for god programmering med prinsipper for god design. Dette kapittelet vil også ta for seg utfordringer ved de enkelte funksjonaliteter. KONSEPTUTVIKLING Helt siden vårt første møte med oppdragsgiver og kunde har de vært klare på at det overordnede målet med applikasjonen er at den skal tilsvare den allerede eksisterende applikasjonen for ios, men med en Android brukefølelse. Vi stod relativt fritt i hvordan vi skulle gå frem for å nå målet, men fikk vite at dersom vi hadde behov for et ekstra par øyne kunne designansvarlig for Digipost stilles til vår disposisjon. Annet enn at applikasjonen skulle gjenspeile en Android brukeropplevelse, var den eneste begrensningen vi fikk at farger skulle passe kundens konsept. Vi vil i de følgende underkapitler beskrive hvordan vi kom frem til vårt konsept. DATAINNSAMLING Det finnes retningslinjer for å utvikle en god applikasjon for Android, men ingen fasit. For å danne et best mulig grunnlag for videre arbeid med konsept, samlet vi inn flere populære designmønstre og utforsket mulighetene rundt bruken av forskjellige komponenter i brukergrensesnittet. Vi ville komme frem til noe som kunne virke kjent for brukere av Android, men også ha et unikt preg over seg. MÅLGRUPPE OG BEHOV Digipost er en tjeneste som skal gi et alternativ til dagens fysiske postkasse, Digipost har hittil rundt unike brukere. En markedsundersøkelse basert på Our Mobile Planet ( sine nettsider på oppdrag fra Google viser at 39% av smarttelefonene i Norge har Android operativsystem. Det kommer også frem at denne fordelingen er omtrentlig lik for alle aldersgrupper. Vi anså det som sannsynlig at disse dataene også er representative for Digipost sin brukermasse. Vår målgruppe er brukere av Digipost med en Android smarttelefon som vi optimistisk anslår at er * 0.39 = unike brukere. Siden Digipost i dag er en relativt avansert tjeneste antar vi at alle brukere har smarttelefon og derfor inngår i målgruppen. I juni 2011 lanserte Digipost en applikasjon for ios. Det har siden den tid vært stor etterspørsel på deres forumer etter en applikasjon også til Android. Det ble utviklet en webløsning tilpasset mobile enheter, men denne løsningen gir ikke inntrykk av å være utviklet for Android. En selvstendig applikasjon utviklet for Android gir langt flere muligheter til å utnytte mobilens egenskaper. GRUPPEMØTER OG BRAINSTORMING Etter datainnsamlingen startet vi en periode med regelmessige grupemøter. På disse møtene brukte vi aktivt brainstorming og diskusjon for å komme frem til det beste resultatet. Den kunnskapen vi hadde tilegnet oss ved å utforske populære mønster for Android design viste seg å være av stor betydning. Vi opplevde at vi på Side 14 av 38

34 Prosessrapport dette tidspunkt hadde gode forutsetninger for å komme frem til en god løsning, hvilket også viste seg i den faglige dybden i diskusjonene. Når vi var kommet til enighet om et forslag til konsept tegnet vi dette opp som en skisse. Denne prosessen gjentok vi flere ganger for å ha flere alternativer og presentere kunden. Iterasjoner her gjorde også at forkastede elementer til et konsept kunne gjenbrukes i et annet. Vi oppnådde på denne måten stor variasjon i konseptene, men alle med den likhet at de hadde en gjennomført Android brukeropplevelse. PRESENTASJON AV KONSEPT FOR OPPDRAGSGIVER OG KUNDE Den 28. januar hadde vi et møte hos kunden hvor vi presenterte våre forslag til konsept, hvor vi i etterkant kom frem til et felles konsept ved hjelp fra Olav Bjørkøy, designansvarlig i Digipost, og innspill fra veileder og produktsjef Martin Bekkelund om hvilke ideer de likte best. Konseptet det ble kommet frem til minner om konseptet til applikasjonen for ios. Forskjellen ligger i hvordan ting blir presentert. Komponentene som blir brukt i brukergrensesnittet er alle typisk Android. Farger er tilpasset Digipost sitt overordnede konsept. I grove trekk inneholdt konseptet følgende: En innloggingsskjerm med linker til juridisk informasjon, samt hvordan opprette en konto i Digipost for nye brukere. En toppmeny i hovedvinduet som skal holde seg lik for postkassen, kjøkkenbenken, arkivet og elektroniske kvitteringer. Bruk av fingerbevegelser for å navigere seg mellom postkassen, kjøkkenbenken, arkivet og elektroniske kvitteringer. Visning av brevinnhold i et eget vindu med en toppmeny og bunnmeny som gjenspeiler toppmenyen brukt i hovedvinduet. UTVIKLING MED ANDROID SDK OG ANDROID NDK I dette kapittelet beskrives utvikling av funksjonalitet og brukergrensesnitt og de utfordringene vi møtte i forbindelse med dette. Vi beskriver forhold som har påvirket applikasjonen og kundens Rest-rammeverk det blir kommunisert med. Det ble hensiktsmessig å inkludere utfordringene i beskrivelsen av funksjonaliteten for å forstå problemene bedre. FORDELER OG ULEMPER MED NATIVE UTVIKLING Native utvikling i Android NDK kan gi en betydelig øking i ytelse for enkelte applikasjoner eller operasjoner i en applikasjon. Generelt vil det være en fordel å programmere C i Android NDK for programmer som prosesserer mye data, har et høyt CPU-forbruk eller foretar tunge grafikkoperasoner. Å bruke native kode vil altså ikke nødvendigvis forbedre ytelsen til en applikasjon, men det vil alltid øke kodens kompleksitet. Du har heller ikke tilgang til det brede klassebiblioteket i Android SDK og Java. Det er generelt anbefalt å bruke Android SDK med mindre applikasjonen som skal utvikles foretar liknende operasjoner som de beskrevet tidligere i avsnittet. Side 15 av 38