Studieprogram: Informasjonsteknologi BACHELORPROSJEKT

Transkript

1 PROSJEKT NR Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Offentlig Telefon: Telefaks: BACHELORPROSJEKT HOVEDPROSJEKTETS TITTEL GS1 DataBar Expanded Stacked Skanner DATO ANTALL SIDER / SIDER BILAG 83/44 PROSJEKTDELTAKERE Martin Løland s Vidar Vasrud s Odd Magnus Meyer s Eirik Stensbøl s INTERN VEILEDER Ismail Hassan OPPDRAGSGIVER GS1 Norway KONTAKTPERSON Anders Askevold aa@gs1.no Terje Menkerud tm@gs1.no SAMMENDRAG GS1 DataBar Expanded Stacked Skanner er et «Proof of concept» og viser mulighetene ved bruk av GS1 DataBar Expanded Stacked i forhold til EAN STIKKORD GS1 DataBar Expanded Stacked strekkode Mobilapplikasjon Docker-back end

2 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Eirik Stensbøl, Martin Løland, Odd Magnus Meyer og Vidar Vasrud HØGSKOLEN I OSLO OG AKERSHUS

3 Forord 1 Forord Det rettes stor takk til oppdragsgiver GS1 representert av Anders Askevold og Terje Menkerud. De ga oss denne muligheten, en spennende oppgave og godt samarbeid. De har vært til god hjelp. En stor takk rettes også mot veileder Ismail Hassan, høgskolelektor tilknyttet institutt for informasjonsteknologi på Høgskolen i Oslo og Akershus. Leserveiledning Det trengs kun generell kunnskap om IT for å forstå rapporten, men enkelte tekniske ord er forklart i en ordliste. Ordlisten ligger i «Vedlegg». Et ord som går igjen i sluttdokumentasjonen er «utløpsdato». Dette ordet dekker både «siste forbruksdag» og «best før». Der kun et av disse ordene gjelder er det spesifikke ordet nevnt. Det anbefales å bruke en PDF-leser for å få anvendt sluttdokumentasjonens hyperkoblinger. Skrifttypen Consolas er brukt for å tydeliggjøre kodesnutter i teksten. Rapporten er delt inn i fire deler og består av: Introduksjon - Av bakgrunnen for prosjektet, informasjon om gruppen og oppdragsgiver. Prosessdokumentasjon - Beskrivelse av blant annet utviklingsprosess, planlegging, arbeidsforhold, utfordringer og vurdering av resultat og sluttprodukt. Produktdokumentasjon - Endelig kravspesifikasjon, beskrivelse av programmet, sikkerhet, brukermanual og testdokumentasjon. Vedlegg - Ordliste, kildehenvisning, planleggingsdokumenter og diverse andre vedlegg som endringer til kravspesifikasjon, risikovurdering og back end-filer.

4 2 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Sammendrag Denne sluttdokumentasjon består av all produsert dokumentasjon i hovedprosjektet, «GS1 DataBar Expanded Stacked Skanner», for gruppe 20 på Institutt for informasjonsteknologi, våren Rapportens målgruppe er hovedsakelig produktets interessenter, veileder og sensorer. Rapporten gir et helhetlig innblikk i prosessen bak prosjektet, utviklingen av produktet, samt dokumentasjon for videre drift, vedlikehold og utvikling. Oppgaven er gitt av GS1 Norway. Den består av å lage en open source mobilapp for ios som skal brukes i demonstrasjon av GS1 sin strekkode GS1 DataBar Expanded Stacked. I løpet av våren 2017 har gruppen utviklet en mobilapp som skal anvendes som et kontroll- og handelsverktøy. Verktøyet skal gi brukergoder samt sporingsmuligheter for alle varer merket med en strekkode av typen GS1 DataBar Expanded Stacked, som GS1 Norway ønsker å erstatte den gjeldende GS1 EAN-13 strekkoden med. Appen er en «Proof of concept» og viser mulighetene ved bruk av GS1 DataBar Expanded Stacked i forhold til EAN-13. Gruppen har hatt et nært samarbeid med oppdragsgiver GS1 Norway, hvor Anders Askevold og Terje Menkerud fungerte som eksterne veiledere. GS1 Norway har gitt meget frie tøyler til selve utviklingen av produktet, med unntak at appen skal fungere på ios.

5 Innholdsfortegnelse: Sluttdokumentasjon 3 Innholdsfortegnelse: Sluttdokumentasjon Forord... 1 Sammendrag... 2 Innholdsfortegnelse: Sluttdokumentasjon... 3 GS1 DataBar Expanded Stacked: Introduksjon... 5 Forord: Introduksjon... 6 Innholdsfortegnelse: Introduksjon Introduksjon Mål og rammebetingelser Forord: Prosessdokumentasjon Innholdsfortegnelse: Prosessdokumentasjon Innledning Planlegging og metode Utviklingsprosessen Kravspesifikasjonen og dens rolle Eget utbytte fra prosjektet Hva ville vi gjort annerledes Mulig videreutvikling Appens bruksområde og nytte Attest GS1 DataBar Expanded Stacked: Produktdokumentasjon Forord: Produktdokumentasjon Innholdsfortegnelse: Produktdokumentasjon Endelig Kravspesifikasjon Beskrivelse av programmet Sikkerhet Brukermanual Instruksjon for Implementering og bruk av Docker Testdokumentasjon GS1 DataBar Expanded Stacked: Vedlegg Innholdsfortegnelse: Vedlegg Ordliste Kildehenvisninger Planleggingsdokumenter Endelige kravspesifikasjon Kravspesifikasjonsendringer GS

6 4 GS1 DataBar Expanded Stacked: Sluttdokumentasjon 23 Risikovurdering Back end-filer

7 Innholdsfortegnelse: Sluttdokumentasjon 5 GS1 DataBar Expanded Stacked: Introduksjon

8 6 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Forord: Introduksjon Denne delen gir en nærmere introduksjon og beskrivelse av gruppen, oppdragsgiver og mål med oppgaven. Valgt verktøy og teknologi samt alternativer, er forklart mot slutten av introduksjonsdelen. For en oversikt over oppgaven kan sammendraget leses på s. 2.

9 Innholdsfortegnelse: Introduksjon 7 Innholdsfortegnelse: Introduksjon 1 Introduksjon Gruppe Intern veileder fra HiOA Oppdragsgiver Eksterne veiledere fra GS Oppgave Dagens situasjon Mål og rammebetingelser Mål Rammebetingelser Originale kravspesifikasjon Løsninger Xamarin Visual Studio / Xamarin Studio Visual Studio Team Services med Git SharePoint Online Skype Docker Representational state transfer (REST) Model-View-ViewModel Programmeringsspråk C# XAML JavaScript/JSON Alternativer Analyse av virkninger... 16

10 Introduksjon 8 1 Introduksjon 1.1 Gruppe Gruppen består av fire studenter fra spesialiseringene informatikk og ingeniørfag data, ved høgskolen i Oslo og Akershus. Fra informatikk: Odd Magnus Meyer. Fra ingeniørfag data: Vidar Vasrud, Eirik Stensbøl og Martin Løland. 1.2 Intern veileder fra HiOA Høgskolelektor tilknyttet institutt for informasjonsteknologi Ismail Hassan E-post: Ismail.Hassan@hioa.no Telefon (kontor): Oppdragsgiver Oppdragsgiveren GS1 Norway er en not-for-profit organisasjon som jobber med utvikling og vedlikehold av effektiv vare- og informasjonsflyt. GS1 Norway er et datterselskap av GS1 som er representert i over 112 land, og over 1 million bedrifter bruker deres standarder. De er ansvarlig for strekkodestandarder i Norge. GS1 effektiviserer kommunikasjonen i verdikjeder ved å lagre informasjon i strekkoder som kan leses på tvers av bransjer og landegrenser. Dette forenkler aktørenes handel og logistikkprosesser. Nettside: Eksterne veiledere fra GS1 Manager Smart Centre and Partner Program/Senior Advisor Anders Askevold E-post: aa@gs1.no Telefon (kontor): Seniorrådgiver Datafangst, Terje Menkerud E-post: tm@gs1.no Telefon (kontor):

11 Introduksjon Oppgave GS1 Norway ønsker en mobilapp som skal brukes som et handelsverktøy. Denne appen skal fungere som en handleapp og skanne en strekkode av typen GS1 DataBar Expanded Stacked. Med denne typen strekkode kan en rekke ekstra informasjon gjøres tilgjengelig. Til det ønskede formålet skal det legges inn best før dato eller siste forbruksdag sammen med sporbarhetsinformasjon. Kundene som anvender appen vil kunne skanne varene sine og få ulike rabatter ut fra hvor nære man er utløpsdato. Hvis et produkt er forbi siste forbruksdato, vil dette varsles og produktet vil bli låst for salg. Er det derimot forbi best før dato skal produktet bli gratis. I tillegg til brukergoder skal appen spore hvor en gitt vare kommer fra. Dette vil være spesielt viktig i situasjoner hvor det oppstår eventuelle problemer med produktet. Da kan man ved å skanne strekkoden finne varens produksjonssted. Det skal deretter være mulig å blokkere andre varer fra samme produsent, fabrikk eller lignende med å sperre på batch/lot-nummer. 1.6 Dagens situasjon GS1 jobber med GS1-systemet og forbedring av forretningsprosesser. Vare- og informasjonsflyten skal bli enklere, raskere og sikrere. De hjelper bedrifter og bransjer med å analysere og identifisere muligheter ved bruk av nevnt system. De tilbyr strekkodetjenester, arrangementer og kurs, onlinetjenester og consulting. Kompetansesenteret, GS1 Norway Smart Centre, er et showroom hvor verdikjeden kan oppleves for teoretisk og praktisk læring. GS1 ønsker at bruk av strekkoder for forbrukere skal moderniseres, og dette spesielt mot matvarebransjen. Dette for å gi forbrukere en enklere, billigere og økonomisk handel. Samtidig skal det gi en positiv følge for miljøet fordi automatisk rabatt av matvarer vil hjelpe til salg av varer. Varer som ikke hadde blitt kjøpt på grunn av full pris og kort holdbarhet.

12 10 GS1 DataBar Expanded Stacked: Sluttdokumentasjon 2 Mål og rammebetingelser 2.1 Mål Hovedmålet for bachelorprosjektet er å tilby GS1 en mobilapp som skal brukes ved demonstrasjon for kunder og partnere som NorgesGruppen og Coop. Dette for å vise hvilke muligheter det ligger i bruk av strekkoden GS1 DataBar Expanded Stacked i handelsnæringen. 2.2 Rammebetingelser Oppdragsgiver har hatt følgende rammebetingelser: Mobilappen skal være open source. GS1s partnere og kunder skal kunne bruke appen som inspirasjon og utgangspunkt for å utvikle en egen app. Om ønskelig skal de kunne vedlikeholde og videreutvikle kildekoden. Appen må kunne håndtere strekkoder av typen DataBar Expanded Stacked. Løsningen skal være kjørbar på ios.

13 Mål og rammebetingelser Originale kravspesifikasjon Dette var den originale kravspesifikasjonen mottatt fra GS1 (figur 2.3-A Original kravspesifikasjon) og som sammen med rammebetingelser ga utgangspunkt for appen. Figur Original Kravspesifikasjon

14 12 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Skanneren skal kunne lese strekkode med disse spesifikasjonene (figur 2.3-B DataBar spec): Figur 2.3-B DataBar spec 2.4 Løsninger For å produsere appen har vi benyttet oss av flere ulike teknologier. Her forklarer vi de nærmere: Xamarin Xamarin er et rammeverk eid av Microsoft som bruker C# som programmeringsspråk, med støtte for alle eksisterende ios og Android APIer. Rammeverkets intensjon er å dele mest mulig kode mellom Windows-, ios- og Androidprosjekter. Brukergrensesnittet trekkes frem som den mest splittende delen, hvor Xamarin også tilbyr et eget Xamarin.Forms API for å lage delbart brukergrensesnitt i C# eller XAML. Xamarin kan brukes med Xamarin Studio eller Visual Studio.

15 Mål og rammebetingelser 13 Figur A) Xamarin vs Xamarin.Forms Visual Studio / Xamarin Studio Visual studio er et utviklingsmiljø for websider og mobilapper (Figur A Visual Studio). Visual Studio ligger som kjernen bak Xamarin. Visual Studio tilbys per dags dato ( ) ikke til Mac i annet enn en preview versjon 1. Løsningen er Xamarin studio. Dette er Xamarin sitt eget IDE for Mac brukere. I funksjonalitet er Xamarin Studio og Visual Studio ganske like og samarbeider sømløst sammen. Figur A) Visual Studio 1 Visual Studio 2017 for Mac ble sluppet

16 14 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Visual Studio Team Services med Git Visual Studio Team Services er et verktøy som anvender Git sammen med en rekke organiseringsmuligheter. Git er en gratis open source versjonskontroll. Git baserer seg på å la flere personer arbeide med samme kode samtidig uten å skrive over eventuelle endringer andre har gjort. Alle brukerne har mulighet til å laste ned de nyeste endringene av koden, mens de kan laste opp egne endringer. Alle endringene loggføres slik at man lett kan finne hvem som har gjort hvilke forandringer. Akkurat som GitHub fungerer Visual Studio Team Services sine nettsider som en lagringsplass for git-repositories. I tillegg til Git får man god oversikt over organiseringen av selve prosjektet på nettsiden. Man kan legge inn to-do oppgaver, sprinter, loggføre bugs, se statistikk med og uten grafer, med mye mer SharePoint Online SharePoint Online er en skytjeneste fra Microsoft. Her deles dokumentasjon og andre relevante filer for gruppen. På denne måten kan vi se hverandres arbeid og jobbe på samme filer, som for eksempel sluttdokumentasjonen Skype Skype er et kommunikasjonsverktøy hvor gruppen holdt møte og samtaler om prosjektet. Skype ble brukt når gruppen ikke møtes fysisk. På Skype kan det deles tekst, bilde, lyd og video som tilrettela for godt samarbeid. Med Skype installert på blant annet smarttelefonene var det ikke behov for å ha tilgang til en datamaskin for å være med i en samtale Docker Docker er en verdensledende software container plattform. Ved å bruke Docker kan repeterende oppgaver som å sette opp og konfigurere utviklingsmiljøer automatiseres. For eksempel trengs ikke programvare for databasen å installeres og konfigureres overalt. Dette hindrer mange mulige, medfølgende problemer. En annen utvikler og administrator skal kjapt kunne begynne å jobbe med databasen uten at det må bruke lang tid på å installere software og forklare oppsett. Ved bruk av Dockers containere kan alle med Docker og en editor starte å utvikle i løpet av minutter Representational state transfer (REST) REST gjør interoperabilitet mellom datasystemer på internett. REST-kompatible web services tillater systemer tilgang og mulighet til å manipulere tekst i Web ressurser (figur A). Dette ved aksess til URI og manipulering gjennom http og https.

17 Mål og rammebetingelser 15 Figur A) REST API Model-View-ViewModel Model-View-ViewModel er en måte å dele opp koden i ulike lag. Denne typen arkitektur består av et view-lag som beskriver utseende eller presentasjonen av appsiden. Et viewmodel-lag hvor all programlogikk utføres, og et model-lag som beskriver selve dataene. MVVM benyttes for å forenkle programmeringsprosessen ved å skille det visuelle fra det logiske. Dette lar arbeidere med ulike kompetanser jobbe med hver sin del. En front end programmerer trenger derfor ikke ta noe hensyn til logikken bak utseende som blir laget, mens en back end programmerer slipper å fokusere på det visuelle. 2.5 Programmeringsspråk C# C# er et objektorientert programmeringsspråk som baserer seg på C++ og Java. C# er utviklet av Microsoft og ble laget for å ha et kraftig språk med hurtig utvikling. Selv om C# er ganske likt Java som alle på gruppen er kjent med, var det helt nytt for to av medlemmene i gruppen XAML XAML er et XML-basert markup language som også er utviklet av Microsoft. XAML blir brukt til å definere GUI i prosjektet mens C# tar seg av oppførselen i en separat code-behind fil. XAML var nytt for alle medlemmene av gruppen JavaScript/JSON JSON (JavaScript Object Notation) er et data-utvekslingsformat som er lett å skrive og å lese for mennesker, mens det er lett for maskiner å analysere og generere. JSON er baserer seg på

18 16 GS1 DataBar Expanded Stacked: Sluttdokumentasjon programmeringsspråket JavaScript. 2.6 Alternativer Oppgavens løsning kunne blitt gjort ved å lage en webapp i HTML5, noe som ble valgt bort. Det finnes fordeler og ulemper med begge løsningene. Subjektivt følte vi å lage native apper ville gi et mer profesjonelt preg og en større utfordring. Objektivt vil det være lettere å lage en webapp da man parallelt lager den for begge plattformer samtidig. Negativt er det derimot at appen vil kjøre i mobilens nettleser og kreve internettilkobling. Man kan lage en hybridapp, hvor den kan kjøres uten nett, men man vil da miste evnen til å benytte seg av multitouch. Native apper vil ikke miste denne ferdigheten og vil ikke kreve nett for å fungere. Samtidig vil det være lettere å videreutvikle og optimalisere appen. Google disk er et alternativ til SharePoint. Dette er også en skytjeneste hvor filer og dokumenter kan deles innad i en gruppe og hvor medlemmene kan jobbe samtidig på samme dokument. Derimot krever det at man jobber i Google-programmer som Google Dokumenter og Google Regneark. Da skolens konto er i Office 365 og Microsoft-produkter skal brukes i arbeidet ble det bestemt av gruppen å bruke SharePoint. Dette for å lette arbeidet og slippe å flytte dokumenter og filer mellom Googles sine programmer og Microsoft sine programmer. I stedet for Visual Studio Team Services ble det vurdert å bruke GitHub og Trello. Visual Studio Team Services tilbyr hva disse to verktøyene gir hver for seg i en og samme anvendelse. Visual Studio Team Services gir en tydelig oversikt over alle oppgaver som må gjøres med et kanban-board. I tillegg til dette er det mulighet for å organisere og planlegge sprinter. Disse mulighetene var avgjørende for valget å bytte fra GitHub og Trello til Visual Studio Team Services. 2.7 Analyse av virkninger For prosjektgruppen vil dette bli en utfordring i og med at ingen har utviklet for ios før. Gruppen har varierende forkunnskaper både rundt utvikling for mobilenheter og utvikling i C#. Xamarin har heller ikke blitt brukt før. Som gruppe tror vi disse utfordringene vil gjøre oss til bedre utviklere. Ved å velge Xamarin vil løsningen kunne utvikles med mest mulig delt kjernekode for ios, Android, Windows og web, og gruppen vil få erfaring med kryssplattformutvikling. Erfaring med utvikling i C# vil tilegnes. Dette er nyttig dersom man skal jobbe med.net i arbeidslivet. Bruk av Docker er heller ikke kjent for gruppen. Docker er aktuelt i dagens arbeidsliv og er nyttig kunnskap å ha med seg videre. Samtidig letter det arbeidet med å gi sluttproduktet til GS1 og deres videreutvikling. Oppdragsgiver, GS1, vil få en app som kan brukes til å vise organisasjonsmedlemmer fordelene med GS1 DataBar Expanded Stacked. Appen vil vise at produkter kan spores fra produsent frem til produktet skannes i appen, og at rabatter basert på utløpsdato kan være med å minske matsvinn. Denne løsningen vil ha muligheter for videreutvikling med tanke på webapper, samt grunnlag for videreutvikling eller inspirasjon for å utvikle en fullverdig handleapp.

19 Mål og rammebetingelser 17 GS1 DataBar Expanded Stacked: Prosessdokumentasjon

20 18 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Forord: Prosessdokumentasjon Prosessdokumentasjonen beskriver metodene og fremgangsmåten brukt for å gjennomføre hovedprosjektet. Her kommer det fram blant annet viktige valg, begrunnelser og utfordringer som ikke kommer tydelig fram i produktdokumentasjonen. Til slutt er det skrevet om hva gruppen sitter igjen med av ny erfaring og kunnskap. Prosessdokumentasjonen er delt inn i følgende kapitler: Innledning Forklaring av bakgrunnen for prosjektet og valget av prosjektet. Planlegging og metode Hvordan prosessen ble planlagt og hvordan den fungerte. Hvilket rammeverk som ble valgt. Utviklingsprosessen Hvilke utviklingsfaser prosjektet har hatt, faglige utfordringer, valg som er tatt og tilegnede erfaringer. Kravspesifikasjonen og dens rolle Hvilken betydning har kravspesifikasjonen hatt for appen endringer i kravspesifikasjonen underveis og hvorfor. Til slutt hvordan kravspesifikasjonen samsvarer med endelig produkt. Samarbeid En beskrivelse av samarbeidet gjennom perioden. Samarbeidet innad i gruppen, med oppdragsgiver og med veileder fra HiOA. Eget utbytte fra prosjektet Læringsutbytte gruppemedlemmene har ervervet etter fullført prosjekt. Dette gjelder både teoretisk kunnskap og praktisk erfaring. Hva ville blitt gjort annerledes. Appens bruksområde og nytte Hva kan produktet brukes til per i dag, og hva kan appen brukes til senere. Hvilke nytteområder har appen. Oppdragsgivers mening Om oppdragsgiver fornøyd med samarbeidet og sluttproduktet med bachelorgruppen.

21 Innholdsfortegnelse: Prosessdokumentasjon 19 Innholdsfortegnelse: Prosessdokumentasjon 3 Innledning Bakgrunn for prosjektet Valg av oppgave Planlegging og metode Scrum Arbeidsmetode Prosessdokumenter Prosjektskisse Forprosjekt Dagbok Referater Sprintoversikt Risiko Utviklingsprosessen Pre-fase (September Oktober 2016) Utfordringer og løsninger Startfasen (Oktober ) Utfordringer og løsninger Tidlig programmeringsfase ( ) Utfordringer og løsninger Sprint 1 - Databasekartlegging ( ) Utfordringer og Løsninger Sprint 2 Prosjekthjemmeside og UI testversjon ( ) Utfordringer og Løsninger Sprint 3 Fungerende skannerimplementasjon ( ) Progresjonsfasen ( ) Sprint 4 Basis UI ( ) Utfordringer og Løsninger Sprint 5 Database ( ) Utfordringer og løsninger Sprint 6 Logikk, og Sprint 7 Testing ( ) Utfordringer og løsninger Sluttfase ( ) Sprint 8 Produktbeskrivelse Manual ( ) Utfordringer og Løsninger Sprint 9 Ferdigstilling av app, og Sprint 10 Sluttrapport ( ) Utfordringer og løsninger Kravspesifikasjonen og dens rolle Endringer i kravspesifikasjonen Det endelige produktet Eget utbytte fra prosjektet Ny kunnskap og nye erfaringer Hva ville vi gjort annerledes Mulig videreutvikling... 46

22 20 GS1 DataBar Expanded Stacked: Sluttdokumentasjon 10 Appens bruksområde og nytte Bruksområde Nytte Attest... 48

23 Innledning 21 3 Innledning 3.1 Bakgrunn for prosjektet Bachelorprosjektet hadde oppstart i september Gruppen ble dannet sent oktober 2016, med god tid til å starte forprosjektet. Deltakerne hadde alle kjennskap til hverandre etter tidligere samarbeid. Gruppen startet med et møte for at gruppemedlemmene skulle bli kjent med hverandres mål og tanker om bachelorprosjektet. Dette for å finne ut om alle var samstemte om arbeidsinnsats, ønsket type prosjekt og mål med oppgaven. I selve møtet var det fem deltakere, men etter møtet valgte en å trekke seg for å finne en annen gruppe. Gruppen ble derfor bestående av de fire forfatterne av denne sluttdokumentasjonen. Når det kom til ønsket prosjekt ble det ikke stilt noen spesielle ønsker bortsett fra at prosjektet skulle være å utvikle en app til enheter som kjørte på ios, Android og/eller Windows Phone. Eventuelle programmeringsspråk, programmer og lignende ville vi komme med som forslag om ikke oppdragsgiver selv hadde spesifikke ønsker Valg av oppgave Kontakt med potensielle oppdragsgivere ble gjort av enkelte av medlemmene allerede før første gruppemøte. Allikevel fortsatte medlemmene å kontakte mulige oppdragsgivere for å eventuelt selv kunne velge prosjekt ut i fra tilbud. Det sto til slutt igjen to tilbud om samarbeid. Etter tilbudet om samarbeid fra GS1 Norway dro gruppen på besøk til oppdragsgiver for å diskutere eventuelle oppdrag. Gruppen følte seg godt ivaretatt og ble behandlet som en seriøs arbeidspartner. Oppdragsgiver hadde to ulike oppdrag hvor gruppen fikk komme med tanker og meninger om hva som virket mest interessant. Oppdragene det sto mellom dreide seg om å lage en smart handleapp for dagligvarer med fokus på ferskprodukter og bruk av en ny type strekkode, eller å lage et videreutviklet app/web-system for en fiktiv klesbutikk. Appen skulle være til ios- og Androidenheter, og skulle brukes ved demonstrasjon for deres kunder hos GS1 sitt Smart Centre. Dette for å vise potensiale og mulighetene ved bruk av GS1 DataBar Expanded Stacked strekkode. Samtidig stilte de seg åpne for forslag og idéer til appen både når det gjaldt utviklingen og funksjoner. Her ville vi ha mer ansvar og innvirkning på prosjektet enn det andre alternativet. Det sto til slutt igjen to prosjektoppgaver. Oppgaven til GS1 ble valgt basert på GS1 sin erfaring med tidligere masterstudenter og deres interesse i å hjelpe gruppen med å få et godt produkt. Dette sammen en spennende oppgave. Medlemmet som kontaktet GS1 til å begynne med ble dermed valgt til å være talerøret mellom gruppen og oppdragsgiver.

24 22 GS1 DataBar Expanded Stacked: Sluttdokumentasjon 4 Planlegging og metode I dette prosjektet har det vært frie tøyler fra oppdragsgiver på utviklingsmetodikk. Det ville ikke bli mange møter med oppdragsgiver om det ikke var spesielt ønsket fra GS1 eller gruppen. Derimot var oppdragsgiver tilgjengelig på mail fortløpende. Dette gjorde at det lå mye ansvar på gruppen når det kom til det som kan betegnes som mindre og mellomstore avgjørelser. Arbeidet ville ikke bli fulgt opp jevnlig fra oppdragsgiver, men det ble gitt ansvar og tillit på at gruppen skulle gjøre en god jobb. Vi var enige innad i gruppen at vi skulle jobbe tett og inkluderende med fortløpende feedback på hverandres arbeid. Utviklingen av appen skulle ha bestemte funksjoner, men det ville være mulig å legge til ekstra om tiden strakk til. Bachelorprosjektet hadde fastsatt frist på når produktet skulle være ferdig. Det ble derfor bestemt at vi først skulle fokusere på de viktigste funksjonene og ønskene fra oppdragsgiver. Ble det tid igjen på slutten av prosjektperioden kunne dette brukes på funksjoner som kunne sees på som «ekstra». På grunn av ansvaret som ble gitt fra oppdragsgiver valgte vi å gjennomføre prosjektet med en smidig metodikk. Dette for å gi oss en bedre tilpasningsmulighet om oppdragsgiver skulle ønske å endre noen av avgjørelsene som ble tatt utenom deres tilstedeværelse. Det overnevnte gjorde at vi bestemte oss for å gå for scrum som utviklingsmetode. 4.1 Scrum Scrum er et rammeverk for utvikling og for å opprettholde komplekse oppgaver (scrum.org, 2017). Scrum er godt brukt i arbeidslivet, spesielt innen programutvikling. Scrum er basert på å organisere arbeid inn i kortere arbeidsperioder kalt sprinter. En sprint varer gjerne en til fire uker. Man ønsker gjerne korte sprinter for å kunne fortløpende få tilbakemelding fra produkteier, samt unngå minifossefallsmetodikk inne i Scrum-metodikken. I løpet av sprinten arbeides det mot ett konkret mål, en funksjon eller en del av prosjektet. Når sprinten er ferdig skal det ha endt i et fullt funksjonelt og testbart inkrement til det ferdige produktet. Er det tid igjen av sprinten kan det begynne å arbeides på andre oppgaver. Scrum består av tre roller (Lindsjørn, 2015): Scrum Master, Product Owner og Scrum-team. Scrum Master skal blant annet sørge for at Scrumprosessen blir fulgt, koordiner sprintplanlegging og hindre støy slik at utviklerne kan fokusere på oppgavene de skal gjøre. Product Owner representerer kunden, setter opp mål for hver sprint og har ansvaret for product backlog og for å sette prioriteringer blant aktivitetene i backlogen. Scrum Team består typisk av 5-9 personer og er et selvstyrt, tverrfaglig team. Teamet skal blant annet utvikle, designe, teste og dokumentere arbeidet. Da gruppen bare består av fire medlemmer og prosjektet er et bachelorprosjekt med de rammer og krav det innbefatter, ble det bestemt å ikke ha rollene Product Owner og Scrum Master. Å dedikere roller som Product Owner og Scrum Master ble sett på som unødvendig ressurs- og tidsbruk både for oppdragsgiver og prosjektgruppen. Det ble i stedet slik at en i gruppen fikk hovedansvaret for å ha kommunikasjon mellom gruppen og GS1, og mellom gruppen og veileder. Gruppen ble sammen enige om de ulike oppgavene en Scrum Master normalt ville jobbet med.

25 Planlegging og metode 23 Backlog, sprinter og andre spesifikke scrumoppgaver ble diskutert og bestemt i gruppen. Det ble lagt opp 10 sprinter for arbeidet i utviklingen av appen. Disse hadde en varighet fra en uke til 4 uker. Backlogen (figur 4.1-A) ble utført og justert fortløpende på gruppens visualstudio-nettside. Figur 4.1-A) Gruppens Backlog på gruppe20.visualstudio.com Hver arbeidsdag var det et kort stand-up møte om morgenen. Der ble det blant annet ble pratet om hva som var gjort siden sist, og hva som skulle jobbes med videre. Disse møtene ble tatt enten ansikt til ansikt på skolen, eller via Skype om det ble jobbet hjemmefra. Dette var en måte å holde sørge for at alle hadde noe å jobbe med og gjøre at alle hadde en viss oversikt over progresjonen i prosjektet. Via nettsiden til gruppen kunne man også fortløpende se sprint burndown grafer. Man kunne se dem enkeltvis eller sammenligne (figur 4.1-B). Dette ga mulighet til å se hvordan gruppen var til å planlegge, estimere og arbeide gjennom sprinten. Grafene viser totale antall arbeidstimer satt opp for sprinten, og viser hvor mye arbeidstid som bør gjenstå på et bestemt tidspunkt i sprinten. Figur 4.1-B) Burndown Etter møtene ble det jobbet selvstendig med de tildelte oppgavene.

26 24 GS1 DataBar Expanded Stacked: Sluttdokumentasjon 4.2 Arbeidsmetode Det ble ikke holdt noen faste møter med oppdragsgiver under utviklingen. I stedet var det jevn kontakt via mail med mulighet til å avtale møter om det var ønskelig. Med veileder var det oppsatt mulighet for faste møter hver mandag. Der ble gitt en oppdatering av fremgang siden sist, mulighet for å stille spørsmål gruppen og veileder måtte ha, samt få tips og veiledning for videre arbeid. Disse møtene ble holdt hver uke eller annen hver uke. Dette ga en sikkerhet i at prosjektet hadde en fornuftig fremdrift og god kvalitet. Oppgaven ble delt inn i periodiske sprinter hvor hvert medlem fikk sitt eget hovedansvar. Deloppgavene ble noenlunde fordelt likt mellom gruppemedlemmene. Hvor alle var disponible til å hjelpe hverandre om behovet var der. Det ble avtalt tre faste arbeidsdager hvor det kunne jobbes individuelt på hjemmekontor eller på skolen. Alle medlemmene i gruppen har samme valgfag og dermed like dager med forelesning. Etter å ha tatt hensyn til arbeidstider ble det bestemt at mandag, onsdag og fredag ble arbeidsdager. Hvor mandag var fast møte på skolen og veileder. Ble det behov for ekstra arbeidstimer i uken ble det tatt i tillegg til de faste arbeidsdagene. Dette ble fulgt gjennom hele prosjektet, kun med hensyn til eventuelle ferie- og helligdager samt potensielle andre grunner som oppsto. 4.3 Prosessdokumenter For å kontrollere utviklingen av prosessen opprettet vi flere ulike dokumenter. Dokumentene var med på å gi oversikt til medlemmene og dermed en bedre fremdrift. De fleste av dokumentene ble opprettet tidlig i prosjektet, men ble til en viss grad endret underveis Prosjektskisse Prosjektskissen er et kort dokument som inneholder navn på prosjektet, navn på medlemmene av gruppen, informasjon om oppdragsgiver og deres kontaktperson. I tillegg til dette er det en beskrivelse av oppdragsgiver og en snau forklaring av selve oppgaven, inkludert rammebetingelser. Prosjektskissen kan ses i vedlegg: «Bachelorprosjektskisse» Forprosjekt Forprosjektet er en utdypning av prosjektskissen. Oppgaven skal her presiseres og avgrenses slik at den er mulig å gjennomføre innen tidsfristen. Ved å skrive et forprosjekt får man en myk overgang fra planlegging til selve arbeidet.

27 Planlegging og metode Dagbok Dagbøkene er skrevet separat for hvert medlem. For hver økt med arbeid har deltakerne skrevet ned hva de har gjort samt hvilke problemer de har støtt på. Disse har til tider blitt brukt under ukens oppdateringsmøter hvor hver student har forklart hva som har blitt gjennomført Referater Under hvert møte ble det notert et referat slik at gruppen lett kunne finne tilbake til hva som ble diskutert, samt oppdatere medlemmer som ikke var tilstede. Dette ble gjort ved interne møter, møter med veileder og møter med oppdragsgiver Sprintoversikt Gruppen opprettet tidlig en løs sprintoversikt basert på fremdriftsplanen. Denne kan ses i vedlegg «Fremdriftsplan». Sprintoversikten ga et tydelig bilde over hvilke oppgaver som skulle fokuseres på i den gitte perioden. Figur A) Sprintoversikt

28 26 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Risiko Risikovurderingen er foretatt med skjemaene Grovmatrise, Analyseskjema, Risikodiagram og Handlingsplan. Disse ligger som vedlegg «Risikovurdering». Litt utover i prosjektet ble det bestemt å ta en risikovurdering. En risikovurdering burde vært i fokus tidligere enn det ble. Da ville vurderingen vært foretatt før prosjektet hadde vært i gang for fullt. Innen vurderingen ble foretatt, hadde det ikke inntruffet noen større og alvorligere hendelser. Derimot kunne det ha skjedd. Da ville man vært bedre forberedt om en risikovurdering allerede var gjort. Et bachelorprosjekt er av en størrelse hvor det er nyttig med en risikovurdering. Størrelsen på prosjektet gjør at risikoene er annerledes eller er vektlagt annerledes, sammenlignet med større prosjekter i arbeidslivet. Dette har med det få antall medlemmer i gruppen og det korte perspektivet. Det vil være naturlig å tro at det er større risiko for at et gruppemedlem trekker seg, enn om at en ansatt gjør det. Samtidig er det større risiko for større endringer i kravspesifikasjonen i arbeidslivet enn i et bachelorprosjekt. Til en annen gang er det en prioritet å gjøre en risikovurdering i starten av et prosjekt. Det å vente med å gjøre en risikovurdering er en risiko i seg selv.

29 Utviklingsprosessen 27 5 Utviklingsprosessen 5.1 Pre-fase (September Oktober 2016) Gruppen ble opprettet tidlig da medlemmene kjente hverandre og hadde god erfaring med samarbeid tidligere. Alle på gruppen ønsket en programmeringsbasert oppgave, det vil si å lage et produkt av typen webapp eller mobilapp. Det ble fort fraslått å gjennomføre en forskningsbasert oppgave, om muligheten for å velge det bort var der. Det ble enighet om at alle deltakerne skulle kontakte hver sine oppdragsgivere for å øke sjansen for en oppgave som var interessant for hele gruppen. Etter et par uker med leting var det kun en håndfull bedrifter som hadde gitt tilbakemelding på oppdragssøknadene. Selskapet GS1 Norway ønsket et møte for å diskutere mulighetene for en oppgave den 6. oktober. Da det var Vidar Vasrud som hadde tatt kontakt med bedriften ble han det naturlige talsleddet mellom gruppen og bedriften. Gruppen møtte opp hos GS1 Norway sine lokaler på Brynseng hvor vi ble tatt imot av Anders Askevold. Det ble holdt en kort presentasjon av selskapet og deretter stilt spørsmål til gruppen for å kartlegge ferdigheter og ønsker. Det ble så lagt frem forslag til to ulike oppgaver som kunne gjennomføres i regi av GS1 Norway. Den første oppgaven besto av å produsere et klesbutikksystem med tilhørende web- og mobilapp. Den andre oppgaven gikk ut på å lage en skanner for strekkodetypen DataBar Expanded Stacked ved bruk av en mobilapp. Den sistnevnte hadde fokus på bruk i dagligvarehandelen. Etter å ha diskutert alternativene sammen med bedriften ble det takket ja til sistnevnte oppgave, fem dager etter møtet, 11. oktober Utfordringer og løsninger Da dette var veldig tidlig i bachelorprosessen var det få utfordringer på dette stadiet. Gruppen startet derimot med fem medlemmer som ikke var anbefalt av høyskolen i Oslo og Akershus. Dette løste seg tidlig da et av medlemmene valgte å melde seg av. 5.2 Startfasen (Oktober ) Første obligatoriske innlevering var en kort statusrapport med frist Dette var hovedsakelig en bekreftelse på at man hadde funnet seg en gruppe å jobbe sammen med, samt om oppgave allerede var funnet. Da gruppen allerede hadde funnet en oppgave begynte føringen av prosjektskissen. Skissen ble ferdig lenge før fristen som var den Forprosjektet var siste obligatoriske innlevering før selve arbeidet med oppgaven begynte. Da forprosjektet var en utdypning av skissen ble det dermed et krav om å sette seg inn i hva som måtte til for å få gjennomført oppgaven. For enkelhetens skyld ble mesteparten av all kommunikasjon mellom gruppen og oppdragsgiver utvekslet via mail. Midt i januar fikk gruppen tilsendt kravspesifikasjonen fra GS1 og forberedelsene til programmeringen startet. Denne kravspesifikasjonen kan ses i introduksjonen, «Originale kravspesifikasjon».

30 28 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Ut fra kravspesifikasjonen ble det tatt utgangspunkt i å lage en app for operativsystemet ios eller en webapp i HTML5. Gruppen veide de to løsningene opp mot hverandre og kom frem til å ha en native app ville være den beste løsningen. Dette kom av flere årsaker som: - En native app skrives i plattformen sitt programmeringsspråk, og dermed gir full tilgang til plattformen sin maskinvare. Dette fører til bedre ytelse. - En native app vil være lettere å videreutvikle, den vil føles mer profesjonell og være mer optimalisert. - En webapp vil kreve en nettleser og vil miste enkelte funksjoner som multitouch. Da kun et medlem hadde erfaring med mobilapper på Android, fikk gruppen tillatelse av oppdragsgiver å utvikle appen til Android. For at appen skulle fungere tilfredsstillende, ble det enighet mellom oppdragsgiver og gruppen at skanneren skulle være kjapp og enkel i bruk. Appen skal tas i bruk på forskjellige enheter med ulike kameraspesifikasjoner hvor skanneren må fungere på alle. I tillegg var det krav til at skanneren måtte kunne lese strekkoder av typen «GS1 DataBar Expanded Stacked». Gruppen fikk dermed valget mellom å programmere en egen skanner eller implementere en eksisterende open source skanner. På grunn av lengden av prosjektperioden var det tydelig at det ikke var tid til å utvikle både en skanner og en app. Da det var en app som var ønsket ble det valgt å se etter en open source skanner. Valget falt på ZXing («Zebra Crossing»). I utforskningsfasen ble Odd Magnus tipset av en venn, som jobber med apputvikling, om et utviklingsmiljø kalt Xamarin. Ved hjelp av Xamarin kan man produsere kode til både Android og ios samtidig. Back end koden skrives i C# mens front end programmeres i XAML. For mer informasjon om Xamarin se avsnitt «Xamarin». Da det var ønskelig med en app i ios valgte vi å benytte oss av denne løsningen og slik lage en app til begge operativsystemene. Gruppen ble tidlig rådet av veileder til å finne en løsning for å kontrollere og holde oversikt over ulike oppgaver og deres frist. Vi gikk gjennom ulike løsninger som Trello og Taskworld, men endte opp med VisualStudio sine egne prosjektsider. Dette kom av at Xamarin brukes sammen med VisualStudio og gir mange innebygde funksjoner i nettsiden. Disse kan leses mer om i «Visual Studio Team Services med Git». Slutten av fasen ble benyttet til å sette seg inn i Xamarin, samt sette opp utviklingsmiljøet. Mye av denne læringen fortsatte i neste fase, Programmeringsfasen Utfordringer og løsninger Da kun ett av medlemmene hadde erfaring med å programmere mobilapper, og ingen hadde brukt Xamarin tidligere ble det brukt mye tid på å sette seg inn i dette. Xamarin var løsningen på hvordan gruppen skulle få produsert den ønskede appen til ios. En annen utfordring var å finne en passende skannerimplementasjon for mobilprogrammet. Det var satt et krav slik at all kode skulle være open source, skanneren måtte derfor også være det. Skanneren måtte også kunne lese GS1 DataBar Expanded Stacked strekkode. GS1 hadde ingen ITansatte med mulighet til å hjelpe oss innenfor dette fagfeltet. Utfordringen ble løst med en rekke tester av ulike skannerapper som også tilbød tilgang til kodebiblioteker som kunne innføres i appen. Som nevnt ovenfor endte vi opp med en løsning fra ZXing.

31 Utviklingsprosessen Tidlig programmeringsfase ( ) For å få utnyttet Xamarin til det fulle gikk mye av tiden i begynnelsen med på å prøve og feile samt lese seg opp på nettet. Det var flere ulike kilder som ble brukt, blant annet den offisielle dokumentasjonen på Xamarins nettsider 2. I tillegg benyttet deltakerne seg av Xamarin University og Youtube. Xamarin University er Xamarins egne kurs på nett. Her ligger det en rekke video-tutorials for både nybegynnere og de litt mer erfarne. Det var også mulighet for å melde seg opp til ulike online classes, noe vi hadde problemer med (Se mer i utfordringer senere i kapittelet). På Youtube ligger det flere opplæringsvideoer for bruk av Xamarin.Forms og Visual Studio. Dette ga en annen stimuli til læring enn kun å lese dokumentasjon. Kommentarer og eksempler fra andre utviklere ga godt læreutbytte Utfordringer og løsninger For å få relevante kurs samlet på et sted ønsket gruppen å benytte seg av Xamarin University. Det oppsto derimot problemer med brukerkontoene. Xamarin University er en betalt tjeneste, men som studenter fikk medlemmene gratis tilgang via Høyskolens Microsoft Imaginekontoer. Det ble derimot en krasj mellom høyskolekontoene og Xamarinkontoene som førte til at gruppen ikke fikk tilgang til alt de ønsket Sprint 1 - Databasekartlegging ( ) Den første sprinten startet 30. januar. Fokuset i denne sprinten ble å opprette en database appen skulle bygge på. Tanken bak var at appen skulle skanne en strekkode og deretter benytte seg av GTIN (Global Trade Item number) som en indeks i en database hvor mer informasjon rundt produktet skulle hentes. Figur A) Aktivitetsdiagram av tidlig applogikk Databasemodellen for produktene kom fort opp med attributtene: GTIN, Varenavn, Best før dato, Siste forbruksdag, sperret og ulike rabattverdier. 2

32 30 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Utfordringer og Løsninger Da gruppen var noe usikker på hvordan man skulle starte hele prosjektet ble fokuset satt på hvordan databasen skulle bygges opp. I senere tid har gruppen sett at dette var en meget liten del av oppgaven og at man gjerne kunne begynt med større deler av appen. Med liten erfaring og kunnskap om Scrum var det usikkerhet på hvordan man skulle sette opp gode sprinter. Visual Studio sin hjemmeside hadde også flere ukjente funksjoner som kunne brukes med scrum. Det var derfor en utfordring å lære seg dette. For å forbedre dette til neste sprint ble gruppen enige om å sette seg mer inn i nettsiden Sprint 2 Prosjekthjemmeside og UI testversjon ( ) På dette stadiet delte gruppen seg i tre og jobbet med hver sine deler: opprettelse av nettside til bachelorprosjektet, innføring i Visual Studios funksjoner, og lage basis brukergrensesnitt til appen. Gruppen fordelte seg slik at en person jobbet med nettsiden, en satte seg inn i Visual Studio og to ble satt til å lage brukergrensesnittet. På dette tidspunktet var det sagt at bachelorprosjektet skulle leveres inn på en nettside, noe som ble endret av høgskolen to uker før innlevering. To av medlemmene hadde noe mer erfaring med webapper enn de andre og en av de ble dermed satt til denne jobben. Da dette er en ukritisk del av hele prosjektet valgte vi å sette kun én person til å gjennomføre denne jobben da den hadde krav om få ressurser (rask og enkel oppgave). For å oppnå ønsket utseende på nettsiden fikk vi tilgang av GS1 Norway til deres bedriftsressursside. Her fikk vi tilgang til alt vi trengte av logoer, fargevalg, osv. for at oppgaven skulle stå i stil til oppdragsgiver. Ved å laste ned et web toolkit gikk det fort å få opp en nettside med ønsket utseende. Javascript ble benyttet for å skape interaktive menyer. Figur A) Bacheloroppgavens hjemmeside, laget i henhold til GS1 Norways stil

33 Utviklingsprosessen 31 Et medlem fikk ansvar for å sette seg grundig inn i Visual Studios nettsider med tilhørende tjenester. Denne personen holdt så et kort sammendrag for gruppen om de viktigste funksjonene på hjemmesiden og hvordan disse skulle benyttes. To av gruppens deltakere satte seg ned og begynte å lage en grov skisse på hvordan appen skulle fungere. Første utgave ble veldig enkel med en hovedside hvor man kunne bla seg til en annen side og starte skannerfunksjonen. Resultatet av den utførte skanningen ble skrevet ut på siden som en streng, men ikke videre behandlet. Denne delen var like mye for å lære seg å bruke Visual Studio med Xamarin, som å faktisk få et utbytte av programmeringen og implementeringen av ZXing. For å få testet koden benyttet man seg av en Androidemulator. Man fikk testet ut å bla mellom ulike Views på appen og sett at skannerimplementasjonen ga et resultat ved lest strekkode. Hva et view er forklares i kapittelet «Views». For å dele koden med alle medlemmene på gruppen ble det anvendt Visual Studios innebygde Git-funksjon Utfordringer og Løsninger Når vi endelig begynte å ta i bruk Visual Studio med Xamarin støtte vi på utallige problemer. De fleste ble løst ved å lese dokumentasjon på nettet, eller i hjelpeforum som StackOverflow. En feilmelding som dukket opp ved kjøringen av appen i Androidemulatoren var «An unhandled exception occured». Dette tilfellet ble løst ved å slette hele prosjektmappen lokalt og deretter klone prosjektets git repository fra nettet. Deretter måtte man gjennom føre en «Clean Solution» og «Rebuild Solution» ved å høyretrykke på «Solution» (se figur A). Til slutt måtte man fjerne all brukerdata fra emulatoren. En annen løsning på dette problemet var å kjøre emulatoren uten debugging.

34 32 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Figur A) Valg ved høyreklikk på solution. Det viste seg at en av maskinene ikke var kraftig nok til å kunne kjøre Visual Studio med emulatorene. Løsningen på dette problemet ble å anskaffe en kraftigere maskin, som i dette tilfellet var en MacBook Pro. Da Visual studio ikke er tilgjengelig i annet enn en Preview versjon for macos, ble det benyttet Xamarin Studio. For å kunne kjøre ios-emulatoren på en Windows maskin kreves det tilgang til en Mac. Instruksjonene for å kunne gjøre dette finner man via menylinjen «Tools -> ios -> Xamarin Mac Agent». For hver pc kreves det en Mac og kun en kan koble seg til den spesifikke Macen av gangen.

35 Utviklingsprosessen 33 Dette var lite optimalt siden mye av programmeringen ble gjort hver for seg. Det var derfor behov for tilgang til Mac for de tre pcene. Løsningen ble bruk av tjenesten MacinCloud 3. HiOA sponset gruppen med leie av to Mac servere. På den måten kunne gruppemedlemmene koble seg til en Mac i skyen for å få kjørt ios-emulatoren. Samme problem og løsning oppsto ved emulering av app til en iostelefon. Etter hvert fant gruppen ut at emulatoren ikke var spesielt optimalisert for dagens formål. Den var treg og benyttet seg av tidlige utgaver av Androids operativsystem. Løsningen ble å oppdatere SDKpakkene. Noen av deltakerne merket at det ikke var mulig å installere en pakke kalt HAXM (Hardware Accelerated execution Manager) via SDK-manageren. De det angikk måtte installere dette ved siden av for å kunne benytte teknologien. Etter dette laget hvert medlem hvert sitt optimaliserte bilde som appen kunne testes på Sprint 3 Fungerende skannerimplementasjon ( ) Da gruppen allerede hadde fått implementert ZXings biblioteker til appen, var denne sprinten noe avslappet. Som nevnt ovenfor kunne appen allerede skanne en strekkode via mobilens kamera og returnere en string av strekkodens innhold. Det ble ikke lagt noe mer arbeid inn i hvordan den returnerte stringen skulle tolkes av appen. Mye av denne korte sprinten ble derimot brukt til å sette oss dypere inn i Scrum og begynne på neste sprints oppgave, å lage det grunnleggende brukergrensesnittet. I denne fasen var det ingen spesielle utfordringer. 5.4 Progresjonsfasen ( ) Sprint 4 Basis UI ( ) Da vi hadde mottatt en meget tydelig kravspesifikasjon fra GS1 Norway angående hvordan appen skulle se ut og hvordan den skulle fungere, valgte vi å fullføre brukergrensesnittet først og deretter komplementere det med selve programlogikken. Hvert medlem fikk en til to sider i appen som skulle fullføres. I Xamarin programmeres front end koden i XAML som var nytt for alle medlemmene. Sent i sprinten ble gruppen oppmerksomme på en arkitektur kalt Model-View-ViewModel som ble valgt til å anvendes. Denne type arkitektur baserer seg på å skille den visuelle koden og den bakomliggende logikken. Dette gjør det enklere å fordele oppgaver slik at en front end programmerer kan jobbe på utseende uten å kunne noe som helst om funksjonene bak. Da gruppen bestod av fire medlemmer hvorav ingen hadde spesialisert seg innen front- eller back end kode kan denne arkitekturen ses på som unødvendig og heller mer arbeid. Gruppen følte det derimot som en utfordring, samtidig som det forenkler arbeidet for andre å videreutvikle appen. 3

36 34 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Utfordringer og Løsninger Da alt det visuelle i appen måtte kodes via et nytt språk, XAML (Extensible Application Markup Language), ble mye av tiden brukt til å sette seg inn i hvordan dette brukes. Løsninger som å sette riktig skriftstørrelse og fargevalg gikk fort, men ble fort komplisert når man begynte å arbeide med layouts og hvordan få de ulike elementene til å ligge i korrekt posisjon. Figur A) Oppbygning av XAML Layout Tags i EditProductPage På bildet over ses en oversikt over de ulike XAML-taggene som var nødvendig for å få det riktige utseende på EditProductPage, et av viewene i løsningen. Selv om dette ikke virker vanskelig ble dette et stort problem ved enkelte av sidene som skulle opprettes da det ikke var intuitivt f.eks. å ha en StackLayout utenfor et Grid-view. En annen grunn til at dette ble et problem var Visual Studio ikke støttet feilmeldinger ved slike problemer. Med et slik layout-problem var det ofte at emulatoren krasjet uten noen videre forklaring på hvorfor og det ble derfor vanskelig å feilsøke. Mye av dette ble løst med en prøv og feil metode som var lite effektiv. Dette førte til at denne oppgaven tok lengre tid enn planlagt. Et av hovedpoengene med å bruke Xamarin er å kunne kode så mye som mulig av appen i et felles prosjekt. Ved bruk av Xamarin.Forms kan oppimot 90% av all kode produsert benyttes til ulike mobile operativsystemer. Enkelte steder må man derimot spesialisere koden for hvert operativsystem. Et eksempel på dette er statuslinjen til ios. For at denne skal synes kreves det at appen får en forskyvning på 20 tetthetsuavhengige piksler (dp) fra toppen. Løsningen på dette kan ses i bildet under. Da det var vanskelig å forutsi hvor det var behov for ulik kode tok slike løsninger noe lengre tid. Figur B) Her ses kode hvor det har blitt spesifisert at den kun gjelder "OnPlatform... ios"

37 Utviklingsprosessen 35 Til å begynne med var det en feil i Xamarins innstillinger som førte til at autoutfylling av attributter til de ulike taggene ikke fungerte. Dette ble løst med feilsøking og ble endret ved å høyreklikke på xamlfilen og deretter velge «Open With» og «Source Code Editor». Xamarin hadde heller ingen støtte for bruk av checkboxes slik kravspesifikasjonen ønsket. Dette ble løst ved å endre bruken av to checkboxes til en bryter. Bryteren bestemmer om en rabatt skal regnes som prosent eller fastsatt verdi. Da gruppen endret arkitektur til MVVM ble det brukt en del tid til å lese seg opp på dette konseptet og hvordan det skulle gjøres korrekt Sprint 5 Database ( ) Etter å ha ordnet det grunnleggende til appen var det på tide å begynne videreutvikling av databasen. Databasen skulle kobles til via nett etter ønske fra GS1. Nettbaserte databaser var helt nytt for gruppen og det ble brukt en del tid for å se etter ulike løsninger. Det ble besluttet å benytte Docker til å holde databasen og REST API for kommunikasjon mellom database og app. Docker inneholder containere med kode. I gruppens tilfelle var det selve databasen og API-et til å utføre oppgaver mot den. Figur A) Tilkobling mellom appens RestService og databasens API RESTSQL. Over ses en enkel visualisering av stegene som ble tenkt gjennomført ved kommunikasjon mellom appen og databasen. Ettersom prosjektet hadde vært pågående en stund begynte gruppen smått å føre inn prosjektets notater i sluttdokumentasjonen. Gruppen sendte mail til GS1 for en midlertidig oppdatering av arbeidet, samt spørsmål om det var mulighet for bruk av Docker på deres webhotell. GS1 var fornøyd med arbeidet så langt, men ønsket å ha et møte for å se nærmere på appen. Møtet ble holdt i GS1 sine lokaler på Brynseng.

38 36 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Gruppen fikk positiv tilbakemelding på arbeidet, og ønskede endringer fra oppdragsgiver og arbeidstakere ble godkjent på møtet. Endringene kan ses i kapittel «Endringer i Kravspesifikasjonen». Det kom frem at GS1 per i dag ikke hadde et webhotell, men ønsket et som støttet en database med voksende behov. Gruppen fikk dermed ansvar for å sjekke ut forskjellige leverandører av webhotell. Det kunne derfor også ses etter webhotell som støttet Docker. Valget falt på DigitalOcean som leverer IaaS (Infrastructure as a Service). Til forskjell fra PaaS (Platform as a Service) vil dette si man har noe mer kontroll over det underliggende systemet til serveren. Eksempler på PaaS er f.eks. Google App Engine eller Heroku. Her kan man ikke velge OS eller andre konfigurasjoner for serveren, kun aksessere dataene eller endre det man har hostet. Ved å velge DigitalOcean kunne vi velge et Linuxbasert OS som er et krav for å kjøre Docker Utfordringer og løsninger Det ble brukt mye tid på å sette seg inn i Docker. Docker er et nokså nytt konsept og ingen av medlemmene i gruppen hadde erfaring med dette. Løsningen ble å lese seg opp på dokumentasjon rundt temaet sammen med instruktive videoer. Databasen måtte bli tydeligere definert enn hva som var gjort så langt ved opprettelsen av databasen. Til å begynne med var det tenkt at alle attributtene til et produkt skulle legges inn i databasen. Dette ble endret da verdier som: best før dato, siste forbruksdag, batch/lot nummer og serienummer ville være bestemt av selve strekkoden og dermed ikke ha noen funksjon i databasen. Hovedtabellen ble bestemt til å inneholde: GTIN, varebeskrivelse, pris og rabattverdier. Batch/lot numrene ble lagret i en egen tabell da disse måtte oppbevares et sted for å teste om et produkt var sperret. Når en strekkode skannes fra handlekurven skal GTIN testes mot hovedtabellen hvor all informasjon utenom strekkodedataen ligger. Dette lå til grunn for en databasemetode hvor man hentet et produkt med en gitt id (GTIN). Deretter sjekkes det om strekkoden inneholder et batch/lot nummer. Hvis dette er tilfellet må denne sjekkes opp mot batch/lot-tabellen for å se om produktet er sperret. Her igjen kreves det en "hent objekt"-metode som henter objektet med gitt batch/lot nummer og deretter ser på boolean verdien «sperret», om produktet er tilrettelagt for salg eller ikke. Når en strekkode skannes fra adminmenyen vil man derimot ha tre andre valg: Registrer nytt produkt, endre produkt og slett produkt. Hvis en GTIN ikke finnes i databasen vil man ha valget å lagre det i databasen med en metode for å legge inn produkter. Hvis GTIN blir funnet skal man ha mulighet til å endre produktet eller slette det herav metodene endre og slett. Da det var generelt lite kunnskap om databaser i gruppen og ble det lest mye på databasehåndtering via et API. Siden gruppen hadde bestemt seg for å bruke Docker måtte det også dannes en forståelse for hvordan databasen ble opprettet i en Dockerkontainer. Et av medlemmene på gruppen ble satt til å ha hovedansvaret for dette, mens resten jobbet med sluttdokumentasjon og videreutvikling av funksjonene til appen. I ettertid har gruppen sett at dette ansvaret kunne blitt delt videre ut i gruppen, da dette medlemmet fikk veldig mye arbeid og et stort ansvar Sprint 6 Logikk, og Sprint 7 Testing ( ) Etter databasen var tydelig definert ble det jobbet mye med å programmere databasemetodene. Samtidig ble det stadig mer fokus på å føre rapporten. Det ble også lagt vekt på å lage

39 Utviklingsprosessen 37 applikasjonsmetodene som skulle benytte seg av databasemetodene til å hente ut og vise informasjon til brukeren. Medlemmet som tidligere hadde hatt hovedansvaret for databasen ble satt til å lage databasemetodene da han hadde mest forståelse for temaet. Metodene som ble gjort via WebAPIet RestSQL var GET, hent objekt fra databasen; POST, lagre objekt i databasen; PUT, endre objekt i databasen; DELETE, fjern objekt fra databasen. Et annet medlem fikk deretter hovedansvaret for å jobbe med applikasjonsmetodene. Disse metodene består av to viktige deler: Tolkning av strekkoder og oversettelse av databaseobjekter til brukervennlige tekst og verdier. Når databasemetoden returnerer et objekt med følgende verdier: GTIN, varebeskrivelse, pris og rabattverdier må applikasjonsmetoden hente ut de ulike attributtene til objektet og bruke de slik at brukeren får det ønskede resultatet. Når en bruker skanner en strekkode fra handlekurven må appen først tolke strekkoden. ZXing integrasjonen benyttet i appen tok seg av selve avlesningen av strekkoden, men returnerte den kun i en string. Det ble derfor benyttet regulære uttrykk (Regex) for å videre tolke denne tekststrengen. Etter strengen er blitt tolket vil appen så benytte seg av en databasemetode for å hente ut et objekt med en bestemt identifikasjon (GTIN). Hvis objektet blir funnet må det så testes om det er sperret. Her må man benytte seg av en hentemetode mot batch/lot-tabellen. Finnes batch/lot nummeret fra før vil appen tolke batch/lot-objektets boolean verdi «sperret». Hvis denne verdien er false gjenstår det bare å skrive ut varebeskrivelsen og den kalkulerte prisen. Prisen blir kalkulert ved hjelp av produktets rabattverdier og strekkodens utløpsdato. Så sant produktet ikke er over sin siste-forbruksdag vil det legges inn i handlekurven. Figur A) Aktivitetsdiagram for å legge et produkt til i handlekurven De to resterende medlemmene ble satt til å utføre endringene som var ønsket i kravspesifikasjonen samt videre føring av sluttdokumentasjonen.

40 38 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Utfordringer og løsninger Det oppsto problemer med implementering og bruk av Docker. Ved linking av MySQL-container mot RestSQL-containeren oppsto det et problem med MySQL-containeren. Det viste seg at MySQLcontaineren «forsvant» etter kort tid og gjorde databasen utilgjengelig for RestSQL. Dette skjedde selv om flere guider ser på denne linkingen som den aksepterte løsningen for kobling av containere. Løsningen ble å bruke Docker «networking» fremfor «linking», samt å passe på at de kritiske containerne ble opprettet med tilleggskommandoen «--restart=always». For fullstendig forklaring se kapittelet «Instruksjon for Implementering og bruk av Docker». Dockerproblemet tok cirka to uker med av-og-på arbeid for å løse. Det ble støtt på mange problemer med RestService da RestSQL-APIet både sender og mottar et annet JSON-format enn det som var brukt i guiden som ble fulgt. Problemene skyldtes at RestSQL forventet å motta JSON-Arrays med lister av JSON-serialiserte objekter. JSON-versjoner av AI/Produkt/BatchBlock-modellene ble laget, samt en BooleanConverter for å håndtere JSONkonvertering av boolean til TINYINT med tanke på BatchBlock sin «Blocked» attributt. Alle metodene i RestService ble skrevet om for å snakke ordentlig med RestSQL sitt API. RestService med tilhørende problemer tok cirka fire fulle arbeidsdager på grunn av ukjent JSON-funksjonalitet og formatering. Etter kravspesifikasjonsendringene den ble det jobbet med å legge inn en spørsmålstegnknapp på forskjellige sider i appen. Ved å trykke på denne knappen ville man bli navigert til en midlertidig side med aktuell informasjon om siden man var på da knappen ble trykket. En statisk pop-up ble ordnet, men det ble bestemt å lage en dynamisk hjelpeside. Dette for å individualisere hjelpesidens utseende med tekst, farget og bilder i forhold til hva man ønsket hjelp med. Det viste seg at dette var en mer avansert og tidkrevende oppgave enn først forventet. Det store problemet som forårsaket forsinkelsen var ved å få en ikke-statisk hjelpeside måtte det i konstruktøren sendes informasjon som gjenspeilet hvilken side man trengte hjelp med. Da metoden som benytter seg av viewets konstruktør ble kalt, resulterte dette i at appen krasjet. Det ble derfor besluttet at dette var en oppgave som ikke var nødvendig og dermed kunne legges til side. Hvis det gjensto tid på slutten av perioden kunne det jobbes videre med dette problemet. Løsningen ble å beholde den statiske pop-upen til hver side. Sprinten tok lenger tid enn satt opp på grunn av nevnte problemer og innlevering av et mer omfattende hovedprosjekt enn forventet i et annet fag. Kravspesifikasjonsendringene til GS1 spilte også inn her. Det ble derfor bestemt at «Testing»-sprinten ble inkludert i denne utviklingsperioden for å få de ekstra dagene. Utviklingsperioden ble forlenget fra 23. april til og med 28. april. 5.5 Sluttfase ( ) Sprint 8 Produktbeskrivelse Manual ( ) Da utvikling nærmet seg ferdig ble det mer fokus på testing av appen og fiksing av bugs. Gruppen satte som dato hvor appen skulle være ferdigstilt, da det var avtalt et møte med GS1 den Det var flere mindre bugs som fort ble rettet underveis. Eksempler på disse var: ulike logoer brukt på de ulike sidene til appen, skalering av startbildet til appen, sette riktige ikoner til

41 Utviklingsprosessen 39 appen, korrektur av enkelte tekst output og fjerning av gamle testknapper. Det var derimot to feil som skilte seg ut fra de andre med hensyn til at de tok lengre tid for å finne en løsning. Under testingen av strekkodeskanneren oppsto det problemer ved skanning av flere produkter med ulik utløpsdato. Samtidig var det problemet med hjelpesiden som kom tilbake da appen endelig skulle ferdigstilles. Det ble videre jobbet med sluttrapporten hvor hovedfokuset til denne sprinten var å begynne på produktbeskrivelsen og manualen til appen Utfordringer og Løsninger Som nevnt ovenfor oppsto det to større problemer med kodingen i denne perioden. Hjelpesideproblemet ble til slutt løst ved å benytte seg av en løsning uten bilder, men kun forklarende tekst. Etter gruppen hadde klart å laste inn den individuelle informasjonen for hver hjelpeside viste det seg at enkelte deler av de lengre forklaringene ble kuttet. Dette ble så løst ved å benytte seg av relative layout for hjelpesidens view. Relative layout baserer seg på å plassere elementer på skjermen ut i fra elementets foreldre. I tillegg til relative layout måtte det settes en height request til listviewet. Listview er en tabell som fyller seg ut fra hvor informasjonen hentes fra. Dette vil si hvis man har en liste med 3 elementer vil tabellen fylle en rad for hvert element, mens om man har en liste med 23 elementer vil tabellen få 23 rader med informasjon. Før height request ble satt, fylte listviewet kun halve siden. Dette forårsaket at man måtte bla unødvendig. Ved skanning av flere produkter med ulik utløpsdato oppsto det problemer med kalkulering av den totale summen, samt visning av produktet i handlekurvlisten. Når et nytt produkt ble lagt til i handlelisten ville produktene som lå der fra før av, bli oppdatert til å bli lik det nyeste produktet. Totalsummen ble regnet som om produktet ikke hadde avslag. Ved å fjerne produkter oppdaterte totalsummen seg ved å legge til prisen av et ekstra produkt. Det ble satt av en del tid til å løse disse problemene. Det viste seg at listen som ble vist til brukeren, og den bakenforliggende listen i modellen var forskjellig. Problemet ble løst ved å sørge for at GUIet ble oppdatert etter hver endring. Gruppen følte det vanskelig å fylle ut produktbeskrivelsen når produktet ennå ikke var ferdigstilt og enkelte småting kunne forandre seg. Det ble derfor valgt å føre videre på prosessdokumentasjonen Sprint 9 Ferdigstilling av app, og Sprint 10 Sluttrapport ( ) Noe siste finpuss gjensto på appen før det avtalte møtet med oppdragsgiver 12. mai. På møtet skulle gruppen vise sluttproduktet og få tilbakemeldinger, samt avtale veien videre. I perioden frem til innlevering ble det holdt gruppemøter over Skype mens alle jobbet med sluttdokumentasjonen. Arbeid ble fordelt, og spørsmål om oppsett og informasjon ble diskutert. Selve utgangspunktet for dokumentasjonen har vært «Dokumentasjonsforslag for bachelorprosjekter (kun veiledende)» 4 fra Høgskolen i Oslo og Akershus. Det ble gjort endringer der det har vært enighet om at det bør gjøres tilpasninger i forhold til dette prosjektet. Gjennomgang og eventuelle tillegg til kodekommentering ble utført. 4

42 40 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Mandag ble det holdt møte med veileder. På dette møtet tok gruppen opp et spørsmål om overføring av selve appen til GS1. For å levere appen til oppdragsgiver via korrekt prosedyre, App Store for ios og Google Play for Android, kunne hvem som helst få tilgang til å aksessere databasen og utføre eventuelle endringer. Dette kom av at appen skal være open source, som vil si at alle har tilgang til koden bak appen. Gruppen tok derfor dette opp med veileder for å finne en løsning som kunne sikre appen samtidig som det var mulighet for å legge ut bakenforliggende kode. Allerede innen møtet med oppdragsgiver samme uke, hadde gruppen funnet en mulig løsning på problemet (se dypere forklaring under Utfordringer og løsninger). Fredag dro gruppen til GS1s lokaler på Brynseng for siste møtet med oppdragsgiver før rapportens innlevering. På møtet forklarte gruppen GS1 om det mulige sikkerhetsproblemet, men at en mulig løsning allerede var funnet. Oppdragsgiver kom ikke frem til noen bestemt metode for overlevering av appen, men det ble vurdert å opprette en egen developer license og legge ut appen på App Store. Ved å gjøre dette ville GS1 ha muligheten til å oppdatere appen selv, om behovet skulle oppstå. Samtidig vil det ikke være nødvendig å overføre appen ukentlig fra en Macintosh til de ulike enhetene via et midlertidig sertifikat. Etter å ha diskutert de ulike mulighetene for overlevering viste gruppen frem den ferdige appen med de ønskede funksjonalitetene. Oppdragsgiver var fornøyd med arbeidet og ønsket gjerne å få teste appen selv. Etter å ha overført appen til Terje Menkerud ble det oppdaget en feil i appen som forårsaket en krasj når skannerfunksjonen ble kalt fra en iphone. Problemet ble funnet såpass sent da gruppen ikke hadde muligheten til å teste appen på egne iosenheter. To dager etter problemet med skanneren var funnet ble det laget en løsning (Se en utdypet forklaring under). Frem mot innleveringsfrist jobbet alle medlemmene med sluttrapporten og å rydde koden klar til levering Utfordringer og løsninger Løsningen på sikkerhetsproblemet ble å sikre databasen med TLS og HTTPS, samtidig som det ble opprettet en administrasjonsbruker kryptert på databasen. En dypere forklaring av løsningen kan leses i kapittel «Sikkerhet». Skannerproblemet til ios ble løst ved å legge til setningene: <key>nscamerausagedescription</key> <string>this app needs camera access to scan barcodes</string> i filen Info.plist. Disse setningen ga appen den nødvendige tillatelsen til å bruke enhetens kamera. Det var dette som hadde forårsaket appens krasj da enheten ikke hadde tilgang til å åpne kameraet. Etter dette var løst oppsto et nytt problemet, at mobilen kun skannet strekkoder på tvers. Løsningen ble å nedgradere ZXing biblioteket fra versjon til

43 Kravspesifikasjonen og dens rolle 41 6 Kravspesifikasjonen og dens rolle Kravspesifikasjonen er de krav oppdragsgiver har hatt til gruppen da det kom til appen som skulle utvikles. Den har fungert som en kontrakt og som rettesnor gjennom utviklingen. Organisasjonene IEEE (Institute of Electrical and Electronics Engineers) og ANSI (American National Standards Institute) har utviklet en standard for utforming av kravspesifikasjoner (Mikalsen, 1999). Disse er Basis for enighet mellom kunde og leverandør om hva programmet skal gjøre Redusere nødvendig innsats Basis for å estimere kostnader og framdrift Basis for validering og verifikasjon Gjøre flytting av produktet lettere Basis for utvidelser Entydig og komplett Nevnte punkter er stilt til større prosjekter enn det et bachelorprosjekt er. Derfor faller noen av disse i mindre grad bort. For eksempel er det ikke behov for å estimere kostnader da arbeidet skal gjøres ulønnet og man skal bruke verktøy fra høgskolen eller andre tilgjengelige gratisverktøy og teknologier. Kravspesifikasjonen var gitt med forventninger om endringer i løpet av prosessen. Dette for å sikre et best mulig resultat for oppdragsgiver, og et resultat gruppen selv sa seg godt fornøyd med. Kravspesifikasjonen har også hatt endringer underveis. De større endringene ligger som vedlegg, i kapittelet «Hovedendring i kravspesifikasjonen». 6.1 Endringer i kravspesifikasjonen Gruppen sa seg enig i kravspesifikasjonen mottatt av oppdragsgiver om hva programmet skulle ha av funksjoner. Den beskrev godt funksjonene til appen, men lite om teknologien som skulle brukes. Eneste som sto nevnt var at det skulle utvikles en ios eller HTML5 mobilapp, samt at prosjektet skulle være open source. Kravet om open source står i rammebetingelsene og var akseptert. Bruk av open source gir godt grunnlag for videre utvikling både hos firmaer og enkeltpersoner. Kommunikasjon via med GS1 avklarte at utvikling til ios var en prioritet. Etter å ha diskutert gruppen i mellom ble disse kommentarene notert. «Ved å bruke HTML5 lages en webapp som vil fungere på både Android- og ios-enheter, men da krever det at brukeren har tilgang til internett. Det er mulig å få webappen til å kjøre uten internett (lokalt på enheten), men da vil muligheter som for eksempel multitouch bli borte og appen kan bli tregere. Brukes HTML5 er det ikke nødvendig å lage en app spesifikt til ios. Hvis vi lager en app spesifikt til ios, eventuelt også spesifikt til Android, så vil appen lettere fungere uten internett. Det er også kjent for brukere, enklere å bruke og enklere å vedlikeholde og videreutvikle. Ved å bruke Xamarin som utviklingsverktøy for app til ios og Android, kan man utvikle en webapp senere med dette som grunnlag om det er ønsket.».

44 42 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Etter videre kommunikasjon med GS1 ble det enighet om at HTML5 ble erstattet av Android som krav, og at appen skulle utvikles med Xamarin som utviklingsverktøy. Dette er nok en av de største endringene i kravspesifikasjonen. Krav til utseende var ikke nevnt i første versjon av kravspesifikasjonen, men det ble gitt senere fra oppdragsgiver den Denne kan sees i vedlegg, «Hovedendring i kravspesifikasjonen». Underveis i utviklingen har diverse endringer i GUI oppstått for å gjøre appen mest mulig gjenkjennelig og spesialtilpasset for hvert operativsystem. Dette for å blant annet gi bedre brukervennlighet. Disse endringene har derimot ikke har større konsekvenser for verken kravspesifikasjonen eller utviklingen. Etter hvert ble mer fokus rettet på utviklingen av databasen. Oppdragsgiver hadde ikke noen preferanser da det kom til teknologi foruten at det skulle kunne brukes på deres webhotell. Ved forespørsel angående støtte av Docker kom det frem at de ikke hadde webhotell. Det kom derfor et krav om å undersøke og sammenligne webhotell for å finne et godt alternativ. Det ble vedlagt å prioritere webhotell hvor databasen kunne utvides etter hvert som behovet økte, som støttet Docker og som hadde god brukervennlighet var det møte med GS1 hos deres kontor. Det ble forklart om pris og ansvar for oppdragsgiver ved å ha appen ute i Apple App Store og Google Play. Både Google og Apple tar betalt for at appen skal være tilgjengelig i deres appbutikker. GS1 hadde standardisert ios som plattform. Det var derfor ikke behov for å få appen ut på Google Play. Behov for å legge ut appen på App Store skulle vurderes nærmere av GS1. Det er derfor ikke bestemt innen innlevering av bacheloroppgaven hvilken løsning GS1 ønsker for distribusjon. 6.2 Det endelige produktet Det endelige produktet samsvarer godt med kravspesifikasjonen. Funksjonskravene er oppfylt og godkjent fra oppdragsgiver. Ekstra funksjoner har blitt implementert fortløpende underveis etter ønsker fra både oppdragsgiver og gruppen. Funksjoner som ikke har blitt implementert er funksjoner av mindre betydning for selve appen, men som går mer på brukervennlighet. Disse er merket med gul bakgrunn: - Advarsel på skannede varer med utløpt dato eller sperret. o Rødt for utløpte og sperrede -> havner ikke i handlekurv. Forblir i kameravindu. o Ha gult varsel for best før utløpt. Gi beskjed at varen er gratis -> havner i handlekurv til Pris = 0,- og Rabatt = 100%. - I handlekurven: Trykke «Søppelbøtte» gir mulighet for å merke flere varer, samt en knapp øverst til høyre for å huke av alle. Ved skanning av strekkode kommer det opp en advarsel om at varer er sperret eller ikke ligger i databasen. Denne advarselen har ingen farge (figur 6.2-A). Som forbruker havner man deretter i handlekurven. Skal man tilbake til skanning må man trykke på skann-knappen.

45 Kravspesifikasjonen og dens rolle 43 Figur 6.2-A) Varsel at produktets batch/lot nummer har blitt sperret. Figur 6.2-B) Produkt med oversteget best-før dato. Ved skanning av vare som har utløpt best før dato kommer det ikke noen advarsel, men varen havner i handlekurven til pris = 0,- og rabatt = 100% (figur 6.2-B). I handlekurven slettes en og en vare ved å trykke direkte på varen i handlekurven. Ved å trykke på «Søppelbøtte» vil man få spørsmål om man vil slette alle varer. Det er ikke noe alternativ for å merke flere enn en av gangen eller ha en knapp for å huke av alle (figur 6.2-C). Figur 6.2-C) Advarsel ved tømming av handlekurven.

46 44 GS1 DataBar Expanded Stacked: Sluttdokumentasjon 7 Eget utbytte fra prosjektet 7.1 Ny kunnskap og nye erfaringer Gruppemedlemmene hadde varierende kunnskap og erfaring fra tidligere. Allikevel var det flere nye oppgaver som var felles for alle. Teori måtte tilegnes og det måtte mye «prøving og feiling» til for å forstå og få løst problemstillinger med ukjente verktøy og teknologier. Samtidig var det å jobbe med en så omfattende prosjektoppgave nytt for oss. Kravene til dokumentasjon på både grundighet og størrelse var nytt. Planlegging over en såpass stor periode og vurdering av størrelsen på oppgaven ble vanskelig da gruppen ikke hadde noen tidligere erfaringer å sammenligne med. Det har tidligere heller ikke vært samarbeidet med en stor aktør utenfor høgskolen. Planleggingen måtte også ta hensyn til andre fag som ble tatt samtidig. Fag som man ikke visste hvor tids- og arbeidskrevende ville være. Her viste det seg at den fastsatte arbeidstiden ikke ble oppnådd en periode på tre uker inkludert påskeferie. Det medførte et høyere arbeidspress da arbeid måtte tas igjen samtidig som planlagt arbeid skulle utføres. Dette er slikt som man tar lærdom av og som vil bli tatt hensyn til ved eventuelle senere anledninger. Scrum var nytt for alle medlemmene så det gikk bort tid å lære seg og forstå bruken av det. Det var satt av tid i starten av prosjektet for å sette seg inn i Scrum. Selv om det også trengtes praktisk bruk for å lære seg bruk av Scrum, ses det på som riktig valg ved slutten av prosjektet. Scrum er utbredt i arbeidsmarkedet så en slik erfaring er nyttig å ha med seg. Det nevnte tapet av arbeidstiden var lettere å hente igjen da Scrum er mer smidig enn rammeverk som ikke i like stor grad tillater og kan ta hensyn til slike perioder. Det ble derfor ikke like store konsekvenser for prosjektet enn om et annet ikke-smidig rammeverk hadde vært valgt. Erfaring med en kravspesifikasjon som endret seg over tid var også ny. I utdanning er kravspesifikasjoner fastsatt og endres gjerne ikke under perioden før innlevering. Også her var det enighet om at valget av Scrum viste seg riktig. Til slutt var det det omfattende ansvaret. Ikke bare er det en karakter på vitnemålet for gruppen selv, men produktet skal brukes av GS1. Det ga et stort ansvar for at produktet skulle innfri kravene satt av GS1 på punkter som brukervennlighet, stabilitet, sikkerhet og dokumentasjon. Appen skal kunne brukes i dag, og vedlikeholdes og utvikles for senere bruk. Dette til forskjell fra en oppgave på høgskolen hvor oppgaven anses som ferdig ved fullført innlevering.

47 Hva ville vi gjort annerledes 45 8 Hva ville vi gjort annerledes Det er spesielt et par ting som ville vært gjort annerledes om prosjektet ble startet på nytt: - Det er mer omfattende krav til å utvikle til ios enn til Android. Ved utvikling av en ios app kreves en lisens og en tilkobling mot en mac. Gratislisensen hadde holdbarhet på kun syv dager og maksimalt tre enheter. Dette var gruppen ikke klar over ved prosjektets start. Enkelte medlemmer av gruppen har erfaring med apputvikling til Android hvor det er færre restriksjoner for å utvikle en app. Dette uavhengig av datamaskinens operativsystem, programvare og enheter. Det burde vært satt av tid i starten av prosessen for å sette seg inn i dette og å skaffe seg det nødvendige utstyret og informasjonen til å utvikle for ios. - Sikkerhet ville vært et større fokus tidligere i utviklingen. Fokus på hva som kreves for å gjøre appen sikker og hvordan det kodes. Da ville det ikke vært behov for å endre noe kode mot utviklingslutten for å få appen mer sikker. Mest sannsynlig ville det blitt spart noe arbeidstid om sikkerheten hadde vært jobbet med jevnt under utviklingen. - Risikoanalyse ble gjort utover i prosjektet. Dette gjorde at risikoer kunne hatt større følger enn nødvendig da det ikke var forberedt tiltak. Det var heller ikke gjort forebyggende tiltak. Risikoanalysen burde vært gjort tidligere i prosjektet.

48 46 GS1 DataBar Expanded Stacked: Sluttdokumentasjon 9 Mulig videreutvikling Dette er en handleapp som skal brukes i demonstrasjon. Noe GUI kan legges til, for eksempel punktene nevnt i «Det endelige produktet» som det ikke var tid til å fullføre. Appen er tiltenkt og tilrettelagt for å kunne videreutvikles og er derfor lagt ut som open source på GitHub. Appen er også kodet med kodemønsteret MVVM for å strukturere kildekoden. Da kan for eksempel andre utviklere kode uten å ha kunnskap om viewet. Alt dette gjør videreutvikling enklere med at det er lettere å sette seg inn i kildekoden og forstå oppbygningen til appen. Prosjektet inneholder også to services, IDB_Service og DB_Service, som ble brukt av gruppen mens det ble jobbet med lokale databaser. Disse er merket [Obsolete] og det gis advarsel dersom de prøves å bli brukt. De er beholdt i kildekoden hvis det er ønskelig å jobbe med lokale databaser ved fremtidig videreutvikling. Selve databasen er satt opp for å være skalerbar hos skytjenesteleverandøren DigitalOcean. Dette gjør at databasen til appen kan skaleres opp eller ned etter behov. Gruppen har flere forslag til funksjoner ved eventuell videreutvikling: - Skaffe sertifikat til Androiddelen av appen. - Få opp push notification hvis du har nylig kjøpt en vare som blir trukket tilbake av hensyn på produktkvalitet eller sperret av annen grunn. - Videreutvikle appen til å også tolke andre strekkoder som er til bruk i handelsvirksomhet. - Appen bør deles i to deler: en administratorapp og en kundeapp. Dette av brukervennlighetog sikkerhetshensyn. - Lagring av «dagens dato» i databasen, slik at man slipper å sette dagens dato for hver enhet for hver gang appen startes. - Mulighet for kundebrukere med logging av kjøp.

49 Appens bruksområde og nytte Appens bruksområde og nytte GS1 Norway ønsket en mobilapp som skulle brukes som en showcase for fremtidige samarbeidspartnere og kunder. Appen skal være open source, som vil si alle skal ha tilgang til koden om ønskelig. Tanken bak er at appen skal være inspirasjon og et startselement for bedrifter som ønsker å ta i bruk denne typen teknologi Bruksområde Appen skal brukes som et handelsverktøy i GS1 sin demonstrasjonsbutikk. Mobilapparatet vil fungere som kundens personlige skanner og handleliste. Appen vil anvende mobiltelefonens kamera til å skanne produkters strekkode. Strekkoden som er av typen GS1 DataBar Expanded Stacked vil inneholde ulik informasjon som blant annet best før dato eller siste forbruksdag. Kunden vil så bli rabattert ut fra hvor nære man befinner seg produktets utløpsdato. Appen skal også kunne brukes av en administrator/butikkansatt for å skanne produkters strekkode. Der vil produktenes informasjon som pris, rabatter og varetekster kunne endres. I tillegg til dette hovedområdet skal appen inneholde sporingsinformasjon som forteller bl.a. hvor produktet er produsert, for å kunne sperre varer fra denne leverandøren om nødvendig Nytte Tanken bak produktet er at rabattene som gis kunden vil være et insentiv til å kjøpe varer som snart går ut på dato. Dette vil føre til at butikkene kaster mindre mat som har kort holdbarhet eller som ikke har blitt dårlig. Det er utført spørreundersøkelser som viser at kunder er villige til å kjøpe produkter smed kortere holdbarhet, om prisen justeres deretter. Sporingsinformasjonen vil effektivisere sperring av varer dersom det skulle være fare for smitte. Ved å ha batch/lot nummer på en vare vil man kunne ha mulighet til å søke opp nummeret til produktet og dermed sperre alle varer med samme batch/lot nummer. Batch/lot-nivå identifisering (GTIN + batch/lot nummer) gir muligheten til å skille produkter i en batch/lot fra en annen. Dette er spesielt gunstig i prosesser som har krav til en viss kvalitet og som ofte oppstår i en batch-til-batch basis. Et eksempel på dette kan være tilbakekalling av produkter med en forurenset batch/lot. Med batch/lot-nivåsporing kan man identifisere alle plasseringene i produktkjeden hvor en gitt batch/lot har vært, og bekrefte antallet gjenstander som er tilstede fra den bestemte batch/lot. Likevel vil det ikke være mulig å skille produkter fra samme batch/lot, og man kan derfor ikke skille konkrete produkter fra hverandre innad i batchen. Imidlertid er sporbarhet på batch/lotnivå i hvert fall på kort sikt et meget skalerbart nivå av identifikasjon og et nivå som mange benytter seg av i dag (GS1 US, 2016, s. 9, Lølands oversettelse).

50 48 GS1 DataBar Expanded Stacked: Sluttdokumentasjon 11 Attest

51 Attest 49 GS1 DataBar Expanded Stacked: Produktdokumentasjon

52 50 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Forord: Produktdokumentasjon I produktdokumentasjonen er all relevant informasjon for å bruke, drifte og vedlikeholde appen DataBar Expanded Stacked Skanner. For systemadministratorer er det god beskrivelse av appen, databasen, bruk av Docker og testdokumentasjonen. Sikkerhet har vært i fokus og forklares i en egen del. For brukere er det en brukermanual som forklarer både kundedelen og administratordelen av appen. Produktdokumentasjonen er delt inn i følgende kapitler: Endelig Kravspesifikasjon Link til vedlagt kravspesifikasjon. Beskrivelse av programmet Programflyt og oppbygging. Sikkerhet Sikkerhet på applikasjonsnivå og back end. Brukermanual Beskrivelse av riktig og sikker bruk. Instruksjon for Implementering og bruk av Docker Forklaring av oppsett av database og REST-api på en Dockerserver. Testdokumentasjon Dokumentasjon fra enhetstester og andre tester.

53 Innholdsfortegnelse: Produktdokumentasjon 51 Innholdsfortegnelse: Produktdokumentasjon 12 Endelig Kravspesifikasjon Beskrivelse av programmet Programflyt Sentrale datastrukturer Database Programmets oppbygning og virkemåte Models ViewModels Views Services Sikkerhet Appen restsql HTTPS / TLS SQL Injection Validering av input Sikkerhetsprivilegier Tomcat MySQL ACL Brukermanual Brukergrensesnitt Forside Handlekurven Skannervindu Velg betalingsmetode Bekreftet kjøp Det administrative grensesnittet Administrasjonsinnlogging Administrasjonsmenyen Produktredigeringsvindu Instruksjon for Implementering og bruk av Docker MySQL-oppsett restsql-oppsett Filendringrer Ressursoppretting Kobling i kildekode Testdokumentasjon Enhetstester Andre tester... 79

54 52 GS1 DataBar Expanded Stacked: Sluttdokumentasjon 12 Endelig Kravspesifikasjon Se vedlegg «Endelig Kravspesifikasjon».

55 Beskrivelse av programmet Beskrivelse av programmet 13.1 Programflyt Appen er delt inn i tre hoveddeler etter MVVM (Model-View-ViewModel) programmeringsarkitekturen. Programlogikken er skrevet i C# som strukturerer klassene ved hjelp av namespaces. Hovednamespacen heter Databar, og under denne har MVVM-strukturen: Databar.Views, Databar.Models og Databar.ViewModels. Samt har vi flere hjelpeklasser for å snakke med databasen i Databar.Services. Fordelen med MVVM er beskrevet tidligere i kapittel 2, avsnitt Model-View- ViewModel. Figur 13.2-A) MainPage UML-Diagram Diagrammet viser de funksjonelle kravene til startsiden med hensyn på kravspesifikasjonen. Vi kan se MainPage sin deklarasjon av knappene, og hvilke Views som starter ved brukerens input. Diagrammet viser ikke alle klassene i Databar.Views, se avsnitt 13.3 for full liste over appens klasser og namespace-struktur. Videre ned i kapittelet komme vi til å beskrive hvordan appen sine klasser er oppbygd, hvordan databasen ser ut, og hvordan disse kommuniserer med hverandre.

56 54 GS1 DataBar Expanded Stacked: Sluttdokumentasjon 13.2 Sentrale datastrukturer Database Gruppens løsning benytter seg av en MySQL-database på en ekstern server. Databasens tabeller har følgende struktur: Figur A) Databasestruktur 13.3 Programmets oppbygning og virkemåte Siden gruppens løsning benytter seg av Xamarin.Forms, blir løsningskoden delt opp i tre prosjekter: Portable, Android og ios. Her gjøres nesten all koden i Portable, hvor koden hovedsakelig er delt opp i Models, ViewModels, Views og Services. Det som er gjort spesielt for Android- og iosprosjektene er små plattformspesifikke ting som plassering, utseende på elementer og navngiving av bilderessurser.

57 Beskrivelse av programmet Models Gruppens løsning bruker følgende modeller. Disse objektmodellene brukes for å overholde objektintegritet mot databasen og for å brukes som hjelpeobjekter i appen. AI BatchBlock Product JsonAI JsonBatchBlock JsonProduct HelpItem Navn Beskrivelse Application Identifier. Har et nummer og en beskrivelse. Batch/lot blokkering. Har et nummer og en boolsk verdi som angir om den er blokkert eller ikke. Produkt. Har felter lik Product i databasemodellen som er JSON-serializable, samt hjelpefelter for bruk i handlekurv. JSON-wrapper for AI, for å sende og motta lister av AI-objekter som JSON-arrays. JSON-wrapper for BatchBlock, for å sende og motta lister av BatchBlock-objekter som JSONarrays. JSON-wrapper for Product, for å sende og motta lister av Product-objekter som JSONarrays. Hjelpeelement. Har to felter, et for bildetekst dersom det ikke er noe bilde å vise og et for en forklaring av elementet ViewModels Løsningen ViewModels brukes for å sende informasjon som lister av objekter til tilhørende views hvor informasjonen skal vises. Navn CartViewModel EditProductPageViewModel InformationPageViewModel MainViewModel PayConfirmationViewModel Beskrivelse Håndterer ShoppingCart-viewet med metoder som tolker skannede strekkoder og holder styr på innholdet i handlekurven og dets sum. Håndterer tolking av skannede strekkoder i administrasjonsgrensesnittet og videre operasjoner på disse mot databasen. Håndterer utfylling av InformationPage sin liste av HelpItems. Inneholder metoder for å fange opp «tap»- events, men er per dags dato ikke i bruk. Sender total rabatt «spart» basert på produkter i handlekurven til PayConfirmationPage når en kunde velger en betalingsmetode.

58 56 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Views Felles for alle views er at de viser en rad med knapper nederst som fungerer som linker til respektive views. Unntakene for denne regelen er LoginModal og InformationPage, hvor kun en «X» som representerer en tilbakeknapp er tilgjengelig. Gruppen har videre valgt å benytte seg av Xamarins NavigationPage, som vil si at så lenge man skal kunne gå tilbake til forrige sider uten å miste informasjon så vil det være en navigasjonsbar i toppen av appen med en pil for å gå tilbake. Navn AdminMenu EditProductPage InformationPage LoginModal MainPage PayConfirmationPage PayPage ShoppingCart Beskrivelse Kun tilgjengelig for administratorbrukere via LoginModal. Viser informasjon om administrasjonsmuligheter og sender brukeren til tilhørende administratorsider, eventuelt til MainPage ved valg av utloggingsknappen. Administratorside for lagring/endring/sletting av produkt i database basert på skannet strekkode via AdminMenu. Et modalt view som viser hjelpeinformasjon basert på siden brukeren trykket på «hjelp»- knappen. Viser innloggingsfunksjonalitet. Sender brukeren til AdminMenu ved godkjent administratorbrukerinnlogging. Hovedside, den første siden som vises brukeren ved åpning av appen. Viser brukeren totalt beløp spart på kjøp av produkter i handlekurv etter valg av betalingsmetode. Viser brukeren betalingsmuligheter med mulighet for å avbryte kjøp/gå tilbake. Viser brukerens handlekurv med tilhørende funksjonalitet.

59 Beskrivelse av programmet Services Services i løsningen brukes for funksjonalitet som det ikke er naturlig å ha i en ViewModel. Servicene gruppens løsning bruker inneholder metoder som for eksempel operasjoner mot RestSQL-APIet, metoder for handlekurv, hjelpesider og en konverteringsklasse for boolske verdier. DBRestManager RestService IRestService CartServices HelpServices BooleanConverter Navn Beskrivelse En wrapper-klasse som håndterer RestService og tillater appen å utføre databaseoperasjoner. Opererer mot restsql, inneholder databasemetoder og brukerautentisering. Interface for et REST-service, implementeres av RestService. Inneholder metoder for handlekurven. Setter korrekte elementer i InformationPage. Brukes i JSON-konvertering av boolean og TINYINT. I tillegg til de seks servicene over inneholder prosjektet to services, IDB_Service og DB_Service, som ble brukt av gruppen mens det ble jobbet med lokale databaser. Disse er nå merket [Obsolete] slik at en utvikler får advarsler dersom den prøver å bruke klassene, men er beholdt i kildekoden i det tilfellet at det er ønskelig å jobbe med lokale databaser ved fremtidig videreutvikling.

60 58 GS1 DataBar Expanded Stacked: Sluttdokumentasjon 14 Sikkerhet Gruppen har forsøkt å gjøre brukerinformasjon og databasen så sikker som mulig ved bruk av appen, og med den tanken at hvem som helst kan få tak i kildekoden. Disse sikkerhetstiltakene er gjort både på applikasjonsnivå og på back end nivå Appen For å hindre at alle med tilgang til appen skal kunne ha tilgang til administratorrettigheter som oppretting, oppdatering og sletting av produkter i databasen, har appen en innloggingsdel. På innloggingssiden er «admin» oppgitt som foreslått brukernavn. Her må brukeren taste inn et brukernavn og passord, som blir sjekket mot brukeren definert i tomcat-users.xml i restsqlcontaineren på serveren. Denne sjekken blir utført over TLS 1.2, hvor brukernavn og passord blir base64-enkodet og overført i HttpClient sin Authorization-header. Sjekken, som blir gjort av AuthenticateAdmin i RestService, utfører en GET-operasjon mot en adminsikret side på serveren: /restsql/conf/security. Responsen av denne operasjonen blir så sjekket mot HttpResponseMessage.IsSuccessStatusCode, som kun returnerer true dersom brukeren tastet inn gyldig informasjon for en bruker med «admin»-rollen. Dersom innlogging feiler eller blir avbrutt, blir appens tilgang til restsql satt tilbake til kun leserettigheter via defaultkonstruktøren i RestService restsql HTTPS / TLS Når restsql settes opp som lagt ut i den vedlagte brukermanualen, vil all trafikk mellom appen og serveren sendes over en kryptert TLS 1.2-forbindelse. Dette hindrer at eventuell sensitiv informasjon som brukernavn, passord, eller SQL-spørringer kan enkelt fanges opp i klartekst SQL Injection restsql beskytter mot SQL Injection via typesjekking av inputparametere og forhåndsdefinerte setninger for databaseaksess. Delen av SQL-spørringen som omfatter verdien det utføres på blir satt til et spørsmålstegn og en JDBC-metode blir kalt med verdien. Dette gjør at skadelige spørringer ikke kan injiseres i restsql sine parametre Validering av input Som nevnt over utfører restsql typesjekking av input. Standard validatorer sjekker også nummerintervaller, strenglengder og strengformater med regulære uttrykk.

61 Sikkerhet Sikkerhetsprivilegier restsql støtter begrensing av tilgang til sine ressursdefinisjoner basert på roller. Gruppen har valgt å bruke dette for å gi rollene «all», «limited» og «readonly» kun GET-tilgang, mens kun «admin»-rollen har tilgang til POST, PUT, DELETE. Se figuren under for hvordan dette ser ut for en administrator via /restsql/conf/security i nettleseren. Disse ressursbegrensingene kan også utvides slik at f.eks. kun adminrollen får tilgang til brukerdatabaser eller lignende sensitiv informasjon. Figur A) Rettigheter hos ulike brukere Tomcat Tomcat er serveren som restsql kjører på internt i Dockercontaineren. Denne har gruppen konfigurert for å sende HTTPS-trafikk over port Figur A) Tomcat server konfigurert for å sende HTTPS-trafikk. Videre har Tomcat definert en lokal brukerdatabase UserDatabase, hvor en administrator kan definere roller og brukere i XML-format. Denne brukerdatabasen brukes av gruppens løsning for å logge inn som administrator i appen, samt begrense rolletilgang til ressurser som nevnt i punktet om sikkerhetsprivilegier. Her vil også GS1s systemadministrator kunne legge til flere brukere med «admin»-rollen for å unngå sikkerhetsbrudd ved innloggingsinformasjon på avveie MySQL ACL MySQL støtter aksesskontroll, ACL, via user -tabellen. Rootbrukeren kan legge til brukere og gi disse aksess fra kun spesifikke Hostverdier. For et eksempel på hvordan dette kan settes opp, se figuren under:

62 60 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Figur A) Eksempel på oppsett av brukere i access control list ( Dette har ikke per dags dato blitt brukt av gruppen, men kan settes opp senere av GS1 sine systemadministratorer til å for eksempel kun tillate spørringer fra GS1s lokale trådløse nett.

63 Brukermanual Brukermanual 15.1 Brukergrensesnitt Forside Det første som møter brukeren etter appen har blitt kjørt, er en oversiktlig forside med tre knapper plassert i en bunnmeny: Ved å trykke på denne knappen vil brukeren bli navigert videre til handlekurv-vinduet. Ved å trykke på denne knappen vil brukeren bli sendt til et innloggingsvindu for administrasjonsmenyen. Dette vil bli dekket senere i brukermanualen. Ved å trykke på informasjonsknappen vil brukeren bli sendt til en midlertidig side som vil gi informasjon om de ulike mulighetene på forsiden.

64 62 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Under ses et bilde av informasjonssiden som tilhører startsiden: Her kan man se de ulike knappene lett forklart sammen med en lukke-knapp nederst på siden. Lukke knappen vil ta brukeren tilbake til tidligere side.

65 Brukermanual Handlekurven Handlekurv-vinduet vil være kundens hovedvindu hvor mesteparten av appens bruk vil bli gjennomført. Etter første gang brukeren trykker på handlekurvknappen vil det åpnes et tomt handlekurvvindu: 1 Den øverste blå linjen kalles navigasjonslinjen. Etter å ha navigert seg videre kan Back knappen her brukes til å gå tilbake til tidligere sider. 2 Dette åpne rommet vil fylles av produkter med henholdsvis produktets navn, rabatt for produktet om det nærmer seg utløpsdato, og prisen etter rabatten er avslått. 3 Her vil summen av produktene vises og oppdateres ettersom produkter legges til i listen. 4 Her finner brukeren tilsvarende bunnmeny som på forsiden, men med nye ikoner og nye funksjoner slik forklart under. Ved å trykke på strekkodeknappen vil appens skannefunksjon startes. Ved å skanne gyldige strekkoder vil de tilhørende produktene bli lagt til i vinduets handleliste. Ved å trykke på denne knappen vil brukeren bli navigert videre til et betalingsvindu. Dette vinduet vil bli dypere forklart senere. Ved å trykke på søppelbøtten vil brukeren få opp et varsel om det ønskes å slette alle produktene i listen.

66 64 GS1 DataBar Expanded Stacked: Sluttdokumentasjon På bildet over ser vi et eksempel av en handlekurv med 6 produkter lagt til. For enkelhetens skyld er alle produktene av typen Edamer, men med ulik best før dato. Under kolonnen produkt finner man produktets navn og den ordinære prisen. Under kolonnen rabatt kan man se hvor stort avslag som er gitt for produktet i samme rad. I kolonnen Pris(kr) kan man se prisen for det gitte produktet etter rabatten er utregnet. Nederst til høyre finner man prisen det vil koste å kjøpe alle produktene i handlelisten etter rabatt. Alle produkter som har utløpt sin best før dato vil være gratis. I eksempelet over kan man se hvordan rabattene til edamer forandrer seg ut fra utløpsdato: Etter best før, 100% avslag (gratis), på utløpsdagen, 75% avslag, 2 dager før, 50% avslag, 3 dager før, 30% avslag, 4 dager før, 15% avslag og tilslutt 5 dager før, 10% avslag.

67 Brukermanual 65 Til forskjell fra best før dato, vil siste forbruksdag gi et varsel om produktet har passert sin utløpsdato. Produktet vil da være sperret for salg. Varselet kan ses i bildet under: Ved å trykke på søppeldunken vil følgende varsel med valgalternativer gis: For å fjerne et enkelt produkt drar man produktet fra venstre mot høyre. Det vil da slettes fra handlelisten og summen vil oppdateres.

68 66 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Skannervindu Etter man har trykket på skanneknappen vil vinduet under åpnes. Her kan man enten avbryte skanningen eller plassere enhetskameraet over en strekkode for å legge produktet til i handlelisten. Hvis strekkoden er av feil type eller produktet ikke ligger i databasen vil det gis ulike feilmeldinger for dette. Hvis man ikke ønsker å gjennomføre skanningen og trykker cancel vil følgende varsel bli vist og man blir returnert til handlelisten:

69 Brukermanual Velg betalingsmetode Etter å ha skannet inn alle ønskede produkter og trykket på bankkortknappen i handlekurvvinduet får man tre valg for hvordan man ønsker å betale. På bunnen av siden finner man den faste menyen med tre knapper. Betalingsmetode Back-knapp Med de tre ulike knappene midt på skjermen kan brukeren velge den betalingsformen som er ønsket. Ved å trykke på denne knappen vil man bli navigert tilbake til handlekurven. Ved å trykke på handlekurvknappen vil man bli navigert tilbake til handlekurven. Ved å trykke på menyknappen vil man bli navigert til appens forside. Handlekurven vil ikke tømmes. Ved å trykke på informasjonsknappen vil brukeren bli sendt til en midlertidig side som vil gi informasjon om de ulike mulighetene på betalingssiden.

70 68 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Under ses et bilde av informasjonssiden som tilhører betalingssiden:

71 Brukermanual Bekreftet kjøp Etter å ha valgt en metode for betaling vil man bli sendt videre til en side hvor man får bekreftet kjøpet, samtidig som man får et overblikk på hvor mange kroner som er spart på handelen. På bildet under har vi brukt eksempelet fra tidligere med de 6 ulike edamerostene: Ved å trykke på krysset vil brukeren bli navigert tilbake til forsiden og handlekurven vil tømmes for produkter.

72 70 GS1 DataBar Expanded Stacked: Sluttdokumentasjon 15.2 Det administrative grensesnittet Administrasjonsinnlogging Ved å trykke på menyknappen på appens forside vil man bli ledet til et innloggingsvindu. Her kreves det et godkjent brukernavn og passord for å bli navigert videre og få tilgang til administratorfunksjonene: Etter å ha fylt inn brukernavn og passord trykker man «Enter» for å gå videre. Hvis man vil avbryte prosessen og gå tilbake til appens forside, trykker man på lukkeknappen eller tilbakeknappen.

73 Brukermanual Administrasjonsmenyen Etter å ha logget inn kommer man til en administrasjonsmeny hvor det er listet opp hva som kan gjøres som administrator: Ved å trykke på strekkodeknappen vil appens skannefunksjon startes. Hvis strekkoden er gyldig og produktet eksisterer i databasen vil produktets verdier bli fylt inn i et skjema på redigeringssiden. Hvis strekkoden er gyldig, men produktet ikke allerede finnes i databasen vil det være mulig å legge til verdier og lagre produktet i databasen. Redigeringssiden forklares nærmere senere i dokumentasjonen. Ved å trykke på lukkeknappen vil man bli logget ut som administrator og bli sendt tilbake til appens forside. Ved å trykke på kalenderknappen kan man redigere dagens dato. Ved å gjøre dette kan man lett vise frem appens rabattkalkulator uten å måtte skrive ut nye strekkoder.

74 72 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Ved å trykke på kalenderknappen vil følgende kalender komme opp på skjermen: Etter rett dato er valgt trykker man «Done» for å overskrive dagens dato.

75 Brukermanual Produktredigeringsvindu Etter å ha skannet et produkt fra administrasjonsmenyen vil følgende vindu åpnes: 1 GTIN står for Global Trade Item Number og vil alltid være 14 siffer. Denne verdien leses rett ut av strekkoden, fylles inn automatisk og er ikke redigerbar. 2 Varetekst vil være produktets navn. Dette feltet må fylles inn selv og kan redigeres. 3 Batch/lot nummer brukes til å spore en vares opphav. Denne verdien vil leses rett ut av strekkoden hvis den er tilstede, fylles inn automatisk og er ikke redigerbar. 4 Best før dato/siste forbruksdag vil leses rett ut av strekkoden, fylles inn automatisk og er ikke redigerbar. 5 Serienummer vil leses rett ut av strekkoden hvis den er tilstede, fylles inn automatisk og er ikke redigerbar. 6 Bruttopris i kroner vil være produktets utsalgspris i butikk før eventuelle rabatter. Dette feltet må fylles ut selv og kan redigeres. 7 Sperret bryteren vil i utgangspunktet være skrudd av. Hvis denne bryteren aktiveres vil produktets batch/lot nummer sperres. Alle produkter med samme batch/lot nummer vil da være låst for salg. 8 I disse radene settes hvordan produktet vil bli rabattert ut fra hvor mange dager som er igjen før det utløper. Man kan deretter velge om rabatten skal være i hele kroner eller som prosent. Dette gjøres ved å vri på bryterne på høyre side. Det vil indikeres om rabatten er satt til kroner eller prosent ved å se på teksten foran bryteren. 9 Her finner man den gjennomgående bunnmenyen med funksjonene forklart under.

76 74 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Ved å trykke på informasjonsknappen vil brukeren bli sendt til en midlertidig side som vil gi informasjon om de ulike mulighetene på redigeringssiden. Ved å trykke på lagringsknappen vil produktet bli lagret i databasen. Om produktet ikke eksisterer vil det bli opprettet. Hvis produktet allerede eksisterer i databasen vil det gamle produktets informasjon bli overskrevet. Ved å trykke på søppelbøtten vil produktet bli slettet fra databasen. Før dette skjer vil brukeren få en advarsel som vist under. Under ses et bilde av informasjonssiden som tilhører redigeringssiden:

77 Instruksjon for Implementering og bruk av Docker Instruksjon for Implementering og bruk av Docker De to Docker-imagene som blir brukt i vår løsning er: Ved skriving av dette dokumentet ( ) går disse instruksene og vår løsning ut ifra at databasens navn er «databar_db», med tilhørende tabeller «AI», «Product», og «BatchBlock». Se databasedefinisjon for mer info om disse. Videre går gruppens løsning ut ifra at brukernavn for root-aksess på MySQL- og restsql-containerene er «root». Gitt en skytjeneste med dockerfunksjonalitet, som f.eks. DigitalOcean, bruk SCP eller lignende til å overføre «databar_db.sql» til maskinen eller sett opp databasen med tabeller manuelt MySQL-oppsett SSH til maskinen eller bruk DigitalOceans egne command window, og kjør: # docker run restart=always name mysql -p 3306:3306 -e MYSQL_ROOT_PASSWORD=PASSORD -d mysql Hvor PASSORD i MYSQL_ROOT_PASSWORD=PASSORD er passordet som gis til root-bruker med tanke på databaseaksess og tillatelser. # docker exec -i mysql mysql -uroot -ppassord e create database databar_db # docker exec -i mysql mysql -uroot -ppassord databar_db < databar_db.sql # docker inspect mysql Notér IP-adressen som docker inspect gir, denne trengs til oppretting av nettverk til restsql. For å få shell-tilgang til mysql-containeren, kjør: # docker exec -it mysql bash Dette er spesielt nyttig for databaseadministrasjon, ved at man kan legge inn nye databaser og tabeller, samt gjøre endringer på eksisterende tabeller som f.eks. endre «Ainumber» fra INT (heltall) til VARCHAR (streng). Dette muliggjør også å opprette «databar_db»-databasen med tilhørende tabeller og startverdier manuelt dersom man ikke har en SQL-dump å starte fra restsql-oppsett SSH til maskinen, og kjør: # docker run --restart=always --add-host="mysql:ip" -p 8080:8080 -p 8443: name restsql --volume /var/log/restsql:/var/log/restsql -d restsql/service

78 76 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Hvor IP I add-host er IP en til mysql-containeren notert ovenfor. Følg så instruksjonene på «Prerequisites» punkt 3 a-e. Legg spesielt merke til punkt c hvor database.root og database.password må være lik root-bruker og passordet fra MySQL-oppsettet. Eventuelt kan man vente med dette og endre filen i punktet under hvor totalt fem filer endres i containeren. Følgende punkter går ut på å konfigurere restsql og Tomcat-serveren som restsql kjører på internt i Dockercontaineren. Utfør følgende kommando for å få shell-tilgang til restsql-containeren: # docker exec -it restsql bash Filendringrer Inne i containeren er det fem filer som må endres på, så her bør man installere et kommandolinjetekstredigeringsprogram som nano eller lignende: # apt-get update # apt-get install nano De fem filene som må endres på er: - /etc/opt/restsql/privileges.properties - /etc/opt/restsql/restsql.properties - /usr/local/tomcat/conf/server.xml - /usr/local/tomcat/conf/tomcat-users.xml - /usr/local/tomcat/webapps/restsql/web-inf/web.xml Se vedlegg om back end-filer for hvordan disse filene bør se ut. Her har man også muligheten til å legge til og endre brukere i tomcat-users.xml. I tillegg til disse endringene er det en nøkkelfil som må opprettes med følgende kommando: # keytool -genkey -alias tomcat -keyalg RSA -keystore /etc/opt/restsql/keys.keystore Dette er et «self-signed» sertifikat, og bør byttes ut med et sertifisert sertifikat dersom man har tilgang til det. Her velges det også et passord for keystore, dette må legges inn i server.xml. Merk at absolutt path til keystore må legges inn i server.xml over, så dersom man velger et annet navn eller plassering enn /etc/opt/restsql/keys.keystore så må dette også endres i server.xml. Se server.xml, hvor dette skal legges inn under Connector port= 8443 og verdiene som skal endres er keystorefile= /absolutt/path/til/keystore og keystorepass= PASSORD. Med disse endringene utført kan man gå ut av containeren og restarte den ved å utføre: # exit # docker restart restsql Her kan det være nyttig å utføre følgende kommandoer for å gjøre omstart av restsql-containeren raskere, ellers kan det ta fem til ti minutter før restsql er tilgjengelig igjen. Dette på grunn av lite entropi i virtuelle maskiner, som betyr at det er få pseudotilfeldig tall tilgjengelig:

79 Instruksjon for Implementering og bruk av Docker 77 # apt-get install -y rng-tools # rngd -r /dev/urandom Ressursoppretting Gå så inn på Her blir man bedt om å logge inn. Bruk her en bruker med «admin»-rollen fra tomcat-users.xml, for eksempel «admin»-brukeren. Gå der til Tools -> Resource Definition Creation, og skriv inn: Subdirectory: databar_db Database: databar_db Dette oppretter resursdefinisjonene for restsql mot databasen og databasens tabeller, som lar RestService gjøre operasjoner via restsql sitt API Kobling i kildekode Med back end ferdig satt opp må man endre en linje kode i appens kildekode for å kunne koble den mot restsql. Linjen som må endres på er i Databar (Portable), i filen Constants.cs: public static string RestUrl = " Denne linjen må endres slik at den inneholder IP-adressen eller domenet hvor restsql- og MySQLdockercontainerene kjører, slik: public static string RestUrl = " I Constants.cs oppgis også standardbrukeren «all», med passord «all». Dersom man har fulgt oppsettinstruksene over vil dette være en bruker som kun har leserettigheter i restsql. Om man endrer noe i innstillingsfilene over må også de to linjene som refererer til brukernavn og passord for standard kundebruker endres for å tillate en «kunde» å bruke appen.

80 78 GS1 DataBar Expanded Stacked: Sluttdokumentasjon 17 Testdokumentasjon 17.1 Enhetstester Gruppen har ikke benyttet enhetstester i utstrakt forstand, men benyttet seg av Visual Studio Enterprise sin IntelliTest-funksjonalitet til å automatisk generere enhetstester for funksjonene i prosjektet. Figur 17.1-A) Enhetstester Disse testene kan så kjøres for å raskt få et overblikk over hvor utbedring og optimalisering kan gjøres, selv om appen tilsynelatende fungerer som den skal. Figur 17.1-B) Sammendrag av kjørte enhetstester

81 Testdokumentasjon Andre tester Oppgave Forventet resultat Resultat Strekkodetolkning: En strekkode uten best før dato eller siste forbruksdato skal ikke leses av skanneren En display alert som forklarer at produktet har en ugyldig strekkode Bestått Varehåndtering: En vare med utløpt siste forbruksdato skal ikke bli lagt til handlekurven. En vare med utløpt best før dato skal registreres som gratis En vare som ikke ligger i database skal ikke bli lagt til handlekurven En vare med sperret batch/lot nummer skal ikke legges til i handlekurven Display alert som forklarer at varens utløpsdato er oversteget Varen legges til i handlekurven med 100% avslag Display alert som forklarer at varen ikke har blitt registrert Display alert so forklarer at varen sin batch- eller lot nummer er sperret Bestått Bestått Bestått Bestått Databasehåndtering: Databasen skal ikke være sårbar til SQL injection RestSQL bør validere bruker input og blokkere SQL injection Bestått Å legge til en eksisterende vare skal ikke legge inn et duplikat i databasen, men oppdatere tabellen som ligger der Å legge til en vare uten å fylle ut alle felter skal lagre produktet med standardverdier, ikke lagres i databasen med tomme verdier. EditProductPageViewModel må sjekke om produktet finnes i databasen og oppdatere eller opprette deretter. EditProductPageViewModel må sjekke om det er noen tomme felter og fylle ut disse før varen sendes til databasen. Bestått Bestått

82 80 GS1 DataBar Expanded Stacked: Sluttdokumentasjon GS1 DataBar Expanded Stacked: Vedlegg

83 Innholdsfortegnelse: Vedlegg 81 Innholdsfortegnelse: Vedlegg 18 Ordliste Kildehenvisninger Planleggingsdokumenter Prosjektskisse Fremdriftsplan Ganttdiagram Endelige kravspesifikasjon Presentasjon Kort om bakgrunnen Forord Systembeskrivelse Handlekurven Betalingssiden Administrasjonsmenyen Vareredigering/opprettingside Informasjonssiden Rammeverk Kravspesifikasjonsendringer GS Hovedendring kravspesifikasjon Endringer i kravspesifikasjon etter møte med GS Risikovurdering Grovmatrise Analyseskjema Analyseskjema side 1 av Analyseskjema side 2 av Analyseskjema side 3 av Analyseskjema side 4 av Risikodiagram Risikodiagram A: Mennesker Risikodiagram C: Karakter eller materiale Handlingsplan Handlingsplan side 1 av Handlingsplan side 2 av Back end-filer Privileges.properties Server.xml Restsql.properties Tomcat-users.xml Web.xml Databar_db.sql

84 82 GS1 DataBar Expanded Stacked: Sluttdokumentasjon 18 Ordliste Ord Backlog Github GS1 DataBar Expanded Stacked GS1-systemet Interoperabilitet MacinCloud Multitouch Nano NuGet SCP Forklaring Oversikt over ulike sprinter og deloppgaver som må gjøres, jobbes med og er ferdigstilte. En utviklingsplattform for å blant annet legge ut egen kode, og se på andre utvikleres kode. En DataBar strekkode fra GS1 ofte brukt til å merke ferskvarer. Kan inneholde tilleggsinformasjon om produktet som batch/lot-nummer og utløpsdato. Et system hvor GS1 standardene danner et foretningsspråk som identifiserer, lagrer og deler nøkkelinformasjon om produkter, lokasjoner, ressurser med mer. En egenskap ved et produkt eller et system. Det innebærer at dets grensesnitt er fullstendig forstått, slik at det kan arbeide sammen med andre produkter eller systemer, nåværende eller fremtidige, i en hvilken som helst implementasjon eller tilgang, uten noen restriksjoner En skytjeneste på internett hvor det kan leies en Mac. Kan brukes til å få kjørt ios-emulator i Visual Studio eller Xamarin Studio uten fysisk tilgang til en ios- eller macos-enhet. Et berøringsfølsomt brukergrensesnitt for elektroniske apparater som kan registrere flere fingerberøringer samtidig. Enkelt, lite tekstbehandlingsprogram. Pakkemanager for Microsoft development platform inkludert.net. Gir muligheten for å produsere og konsumere pakker. Secure Copy. Nettverksprotokoll for å sikkert overføre filer mellom lokale og eksterne enheter.

85 Ordliste 83 SSH StackOverflow Secure Shell. Kryptografisk nettverksprotokoll som støtter sikker operering av tjenester over usikre nettverk, som f.eks. brukerinnlogging til eksterne maskiner. StackOverflow er det største onlinesamfunnet for programmere til å lære og dele kunnskap. TINYINT SQL Server data type for små tall. Kan lagre 1 byte som vil si tall fra 0 til 255. URI ZXing ZXing.Net ZXing.Net.Mobile URI er en standard for å identifisere dokumenter ved hjelp av en streng som inneholder bokstaver, symboler og tall. URI er et set som inneholder underset som blant annet: URL, URN og URC. Et open source, multi-format 1D/2D strekkode prosesseringsbibliotek og leser. Implementert i Java. En.Net og C# port av den javabaserte strekkodeleseren og prosesseringssbiblioteket ZXing. En C#/.Net strekkodeleser for Xamarin.iOS, Xamarin.Android, Windows Phone (Silverlight) og Windows Universal. Basert på ZXing.Net.

86 84 GS1 DataBar Expanded Stacked: Sluttdokumentasjon 19 Kildehenvisninger GS1 US. (2016, Ukjent Ukjent). How GS1 Standards Support Product Tracing, Critical Tracking Events and Key Data Elements. (M. Løland, Red.) Hentet fra Webområde for GS1 US: d=core_download&entryid=733&language=en-us&portalid=0&tabid=785 Lindsjørn, Y. (2015). "Use Case modellering", forelesningspresentasjon i DAFE2200: Systemutvikling. Oslo: Høgskolen i Oslo og Akershus. Mikalsen, A. B. (1999, 03 16). Leksjon: 7, Utforming av system/kravspesifikasjon. Hentet fra Fag: Prosjektrettet systemarbeid: Petzold, C. (2016). Creating Mobile Apps with Xamarin.Forms. Washington: Microsoft Press. scrum.org. (2017, 05 02). Hentet fra What is scrum:

87 Planleggingsdokumenter Planleggingsdokumenter 20.1 Prosjektskisse Gruppe Nr. 20 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo BACHELORPROSJEKTSKISSE Mobil DataBar-Scanner DATO ANTALL SIDER / BILAG 1 PROSJEKTDELTAKERE Eirik Stensbøl, s Martin Løland, s Odd Magnus Meyer, s Vidar Vasrud, s INTERN VEILEDER Ikke tildelt OPPDRAGSGIVER GS1 Norway firmapost@gs1.no Tlf: KONTAKTPERSON Anders Askevold anders.askevold@gs1.no Tlf: BESKRIVELSE GS1 Norway er en brukerstyrt, not-for-profit organisasjon, som er medlem av en global organisasjon GS1 som utvikler, vedlikeholder og tilbyr standarder for effektiv vare- og informasjonsflyt mellom handelspartnere verden over. Hjertet i virksomheten er GS1-systemet som effektiviserer aktørenes handelsprosesser, og forenkler handel og logistikk globalt og lokalt. GS1 er representert i 112 land og over 1 million bedrifter bruker GS1s standarder. GS1 Norway har i dag mer enn 5000 brukere i stadig flere bransjer. Prosjektet baserer seg på en app som skal bruke mobilens kamera til å skanne GS-1 DataBar Expanded Stacked, og bruke dette til å utføre dageligvarehandel. I denne typen strekkode vil det være mulig å legge inn ekstra informasjon utenom det vanlige produktnavnet. Denne informasjonen vil f.eks. inneholde siste forbruksdag eller best før dato. Disse vil så kunne brukes til å gi brukeren avslag på varer som nærmer seg utløpsdato. Hvis tiden strekker til skal det innføres en betalingsmetode i appen slik at all handel kan foregå uten et kassaapparat. Tanken bak prosjektet er at kundene skal spare penger samtidig som butikkene kaster mindre mat og slik sparer miljøet. Appen skal fungere som et proof-of-concept for mulighetene GS1 DataBar Extended Stacked gir over «vanlig» GS1 EAN. Appen kommer kun til Android da det er dette vi har erfaring med. Selve kodingen vil bli utført i Android Studio (Java + XML). Skannermodulen til prosjektet vil bli hentet fra eksisterende programvare (open source, mer informasjon kommer etter hvert). Github vil brukes for å samhandle arbeidet underveis.

88 86 GS1 DataBar Expanded Stacked: Sluttdokumentasjon 20.2 Fremdriftsplan 20.3 Ganttdiagram

89 Endelige kravspesifikasjon Endelige kravspesifikasjon 21.1 Presentasjon Oppdragsgiver GS1 Norway Nettside Prosjekttittel Oppgave Mobil DataBar Skanner Mobilapp for skanning av GS1 DataBar Expanded Stacked. Med denne type DataBar vil appen hente ut blant annet informasjon om utløpsdato og batch/lot nummer. Dette kan gi forbrukeren informasjon om rabatter basert på utløpsdato og sporingsinformasjon av matvaren. Hovedtanken bak dette vil være at det blir mindre svinn og tryggere handel av matvarer. Periode Gruppe 20 Gruppemedlemmer Odd Magnus Meyer s Vidar Vasrud s Eirik Stensbøl s Martin Løland s Veileder Eksterne Veiledere Ismail Hassan Anders Askevold Tlf: Terje Menkerud Tlf:

90 88 GS1 DataBar Expanded Stacked: Sluttdokumentasjon 21.2 Kort om bakgrunnen Oppdragsgiver GS1 Norway er en not-for-profit organisasjon som jobber med utvikling og vedlikehold av effektiv vare- og informasjonsflyt. De er ansvarlig for strekkodestandarder i Norge. GS1 Norway og deres partnere (blant annet Matvett AS) prøver å forhindre matsvinn i Norge. For å oppnå dette ønsker GS1 Norway innføre en ny strekkode for dagligvareprodukter som vil inneholde mer informasjon enn dagens strekkode. Den nye strekkoden GS1 DataBar Expanded Stacked inneholder batch/lot nummer og utløpsdato for å gi rabatt til varer som nærmer seg utløp, og for å sperre varer med produksjonsfeil fra å bli kjøpt. Figur 20.2-A) GS1 DataBar Expanded Stacked. Application identifiers (AI) er tallene i parentes GS1 Norway har bedt gruppen om å utvikle en mobilapp som vil ta i bruk informasjonen i den nye strekkoden i en handleapp. Handleappen vil bli brukt i GS1 Norway sitt Smart Centre for å vise frem mulighetene ved den nye strekkoden til sine samarbeidspartnere Forord Hensikten med kravspesifikasjonen er å gi gruppen en forståelse for hva oppdragsgiver ønsker å få levert. Den fungerer som en kontrakt og som en rettesnor gjennom utviklingen. Kravspesifikasjonen er først og fremst beregnet for gruppen, men også for både oppdragsgiver og sensor. Oppdragsgiver vil kunne se at deres krav blir oppfylt, og sensor vil kunne sammenligne sluttproduktet med kravspesifikasjonen. Kravspesifikasjonen har blitt endret underveis, endringene kan leses om i «Hovedendring kravspesifikasjon».

91 Endelige kravspesifikasjon Systembeskrivelse Oppgaven går ut på å utvikle en handleapp til ios som kan håndtere bruk av GS1 DataBar Expanded Stacked; en strekkode fra GS1 som kan inneholde mer informasjon enn den strekkoden som brukes på varer i dag. Ved å bruke denne nye strekkoden skal appen gi automatisk rabatt på varer som nærmer seg enten best før dato eller siste forbruksdag. Appen skal ha de funksjonelle kravene som er beskrevet i vedlegget, disse kravene blir nå oppsummert. For en fullverdig beskrivelse, se den originale mailen fra GS1. Appen sin startside skal ha tre knapper for navigasjon: Figur 10.4-A) Startssiden navigasjonsknapper Handlekurvikonet skal ta brukeren til handlekurven. Menyknappen skal ta brukeren til en innloggingsside for administratorer. Spørsmåltegnet skal ta brukeren til en informasjonsside Handlekurven Handlekurven starter tom og fylles på etterhvert som brukeren skanner inn varer. Den skal inneholde Varenavn: Denne finnes ved å lese GTIN i strekkoden og sjekke i databasen etter matchende GTIN og varenavn. Ordinær pris: Leses også fra databasen Rabatt: Denne skal endres med hensyn på informasjonen som er beskrevet i databasen, og hvor nær varen er enten best før dato eller siste forbruksdag. Datoen leses fra strekkoden som enten AI 15 (best før dato) eller AI 17 (siste forbruksdag). Rabattype: En vare kan være rabattert på prosent eller kroner. Pris: Skal vise varen sin pris etter rabatt. Sum: Totale summen i handlekurven.

92 90 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Eksempelskisse: Figur A) Handlekurven Kredittkortikonet skal ta brukeren til betalingsside. Søppelbøtten skal slette varer fra handlekurven Betalingssiden Betalingssiden skal gi brukeren valget om å betale med f.eks. Vipps, MobilePay eller Apple Pay. Disse skal ikke implementeres, men kun gjøres klar til videreutvikling. Å klikke på en av valgene vil ta brukeren til en ny side som viser hvor mye brukeren har spart på rabatt, og at brukeren har spart miljøet for matsvinn. En skisse på dette kan ses i avsnittet «Bekreftet kjøp» Administrasjonsmenyen Administrasjonsmenyen skal gi muligheten for GS1 å logge inn i appen for å gjøre endringer i databasen og endre dagens dato. Siden appen skal brukes i GS1 sitt Smart Centre er det best om appen sin dato kan endres, dette er for å kunne gjenbruke allerede produserte strekkoder. Administratoren skal få valget mellom tre knapper.

93 Endelige kravspesifikasjon 91 Strekkodeikonet skal starte skanneren på telefonen. Når en strekkode er skannet skal administratoren sendes til en side hvor informasjonen om varen kan endres. Kryssikonet skal logge administratoren ut og sende han til startsiden. Kalenderikonet skal åpne en kalender for å sette dagens dato Vareredigering/opprettingside Etter at en vare er skannet skal all informasjonen i strekkoden skrives til utseendet. Her skal administratoren kunne legge inn informasjon angående varen, eller redigere en tidligere vare: GTIN (Global Trade Item Number): Informasjonen som står etter AI 01 Varetekst: Beskrivelse av varen Batch/lot nummer: Informasjonen som står etter AI 10 Best før dato: Informasjonen som står etter AI 15 Siste forbruksdato: Informasjonen som står bak AI 17 Serienr: Informasjonen som står bak AI 21 Bruttopris kr: Ordinær pris på varen Sperret: Om batch/lot nummeret er sperret, f.eks. ved at en produsent sender en dårlig batch, og du som administrator vil sperre denne fra å kunne skannes inn av kunder. 5, 4, 3, 2, 1- dagsrabatter og rabattype: Definere hvor mye rabatt varen får m.h.t hvor nær datoen er best før dato eller siste forbruksdato. Eksempelskisse: Figur A) Rediger/opprett vare siden

94 92 GS1 DataBar Expanded Stacked: Sluttdokumentasjon Lagreikonet skal lagre varen i databasen. Søppelbøtten skal slette hele varen fra databasen Informasjonssiden Informasjonssiden skal gi brukeren en god innføring i hvordan appen fungerer og hvordan den kan navigeres. Full utdypelse av den originale kravspesifikasjonen kan ses i vedlegg lenger ned Rammeverk Appen skal brukes i fremvisninger på GS1 sitt Smart Centre, og må dermed kjøre på ios. Databasen skal legges på et webhotell, og gruppen må finne ut hvilken skyløsning som vil passe best for GS1 Norway. Kildekoden skal også legges ut som open source.

95 Kravspesifikasjonsendringer GS Kravspesifikasjonsendringer GS Hovedendring kravspesifikasjon Utklipp fra GS1 sin powerpointpresentasjon angående appens funksjoner og utseende.

96 94 GS1 DataBar Expanded Stacked: Sluttdokumentasjon

97 Kravspesifikasjonsendringer GS1 95

98 96 GS1 DataBar Expanded Stacked: Sluttdokumentasjon

99 Kravspesifikasjonsendringer GS1 97

100 98 GS1 DataBar Expanded Stacked: Sluttdokumentasjon