1. No category

 En sluttrapport for
Lønnsomhetskalkulator
Framlagt som en del av fullførelsen av
BACHELOR I ANVENDT DATATEKNOLOGI
Av
Magnus Reisæter
Avgangsåret 2015
Student 189106
Anthony Davies
Avgangsåret 2015
Student 189121
Alexander Evensen
Avgangsåret 2015
Student 189104
Stian Rydje
Avgangsåret 2015
Student 189127
Morten Nordengen
Avgangsåret 2015
Student 189098
Fakultet for teknologi, kunst og design (T.K.D.)
Høgskolen i Oslo og Akershus
1.1 Forord
Dette prosjektet er et produkt av et semesters arbeid på Høgskolen i Oslo og Akershus, avdeling for
ingeniørutdanning. Prosjektet har vært utfordrende og ambisiøst. Arbeidet har resultert i et
fullverdig produkt som i stor grad tilfører verdi til et allerede etablert produkt i EVRY sin
portefølje.
Det ferdige produktet er et resultat av et meget godt samarbeid mellom oss som gruppe, våre
veiledere ved HiOA, veiledere fra EVRY, og andre som har kommet med råd og veiledning
underveis.
Vi ønsker å rette en stor takk til alle personene i EVRY som har tatt seg tiden til å bidra på hver sin
måte under prosjektet. En spesiell takk til Andreas Røe som har fungert som veileder og
nettverksbygger internt i selskapet. Du har gitt oss en stor mengde inspirasjon med all den
erfaringen du besitter fra din tid i bransjen, og ditt innovative tankesett. Vi har følt oss hjemme hos
dere fra første dag.
Takk til Rune Gjørøy, selger, for verdifulle tilbakemeldinger angående salgsprosessen, og innspill
på grensesnitt. Takk til Odd Egil Orøy, produkteier, for kontinuerlig oppfølging, og din tillit til oss
når det kom til å ta avgjørelser underveis.
Signert
Oslo
Dato
Magnus Reisæter
Alexander Evensen
Anthony Davies
Morten Nordengen
Stian Rydje
2
Kapittel 1: Presentasjon
Forord
1.1
Innledning
1.2
Om gruppen
1.2.1
Om oppdragsgiver
1.2.2
Ord fra oppdragsgiver
1.2.3
Bakgrunn for oppgaven
1.3
Bedriftens målsetninger
1.3.1
Spesifikke føringer
1.3.1.1
Gruppens målsetninger
1.3.2
Hvordan vi fikk oppgaven
1.3.3
Beskrivelse av applikasjonen
1.4
1.2 Innledning
Hensikten med en presentasjonsrapport er å presentere oppdragsgiver og oppdragstaker for leseren
av rapporten. Vi ønsker å gi leseren et innblikk i hva oppgaven går ut på, og hvilke målsetninger
partene har under prosjektets varighet.
3
Det anbefales å starte med dette kapittelet, da det vil bli antatt at rapporten er gjennomgått i
kronologisk rekkefølge. En god forutsetning for å lese rapporten er å ha noe kjennskap til
dagsaktuell teknologi og rammeverk. Oppgavespesifikke fremmedord vil bli forklart i en vedlagt
ordliste.
Underveis kan leseren av rapporten være tjent med å følge stegene som blir forklart i selve
applikasjonen som er tilgjengelig på:
http://anvend.me/lonnsomhetskalkulator/lonnsom-latest/
1.2.1 Om gruppen
Vi er fem studenter fra studiet Anvendt Datateknologi ved Høgskolen i Oslo og Akershus. Gjennom
kontinuerlig bra samarbeid gjennom bachelorstudiene har vi fått en gruppe som kjenner hverandre
bra på godt og vondt. Hvert enkeltmedlem har sine sterke og svake punkter, og sammen i et team
får vi utnyttet dette på en god måte. Til felles har vi ambisjonsnivå, interessen for teknologi og mål
om selvstendig utvikling i fagfeltet.
Figur 1 - Organisasjonskart
4
1.2.2 Om oppdragsgiver
EVRY ASA, tidligere EDB ErgoGroup ASA, er et norsk informasjonsteknologiselskap etablert 14.
oktober 2010 gjennom en sammenslåing av EDB Business Partner og ErgoGroup, som gjør
konsernet til Norges største IT-selskap. Selskapet har 10.000 ansatte fordelt på 135 kontorer i 16
land, og en årlig omsetning på circa 13 milliarder kroner ​
(EVRY Annual Report, 2013​
).
EVRY Retail implementerer morgendagens løsninger med flere kanaler for kommunikasjon
mellom forhandlere, daglivarekjeder og deres kunder. EVRY er markedsledende på innhold og
dokumentformidling og utvikler egne løsninger for distribusjon. Store deler av
applikasjonsporteføljen er bygget på Open Source og forvaltes internt. Enheten har en tverrfaglig
sammensetning av utviklere, arkitekter, prosjektleder og domenekunnskap innenfor våre fagfelt.
EVRY har en ambisiøs vekststrategi. Enheten består i dag av 90 medarbeidere i Norge. EVRY Retail
betjener til daglig mer enn 900 kunder som alle har det til felles at de har forbrukere som
sluttkunde. EVRY Retail hadde en omsetning på ca. 250 MNOK i 2012(​
EVRY Annual Report, 2012).
5
1.2.3 Ord fra oppdragsgiver
Anthony Davies , Morten Nordengen, Alexander Evensen, Magnus Reisæter og Stian Rydje har
våren 2015 arbeidet hos EVRY AS med å utvikle en løsning for å kalkulere lønnsomhet ved bruk
av vår tjeneste Multikanal – kalt Lønnsomhetskalkulator.
Som en del av arbeidet har gruppen også testet å bruke markedsaktuelle arbeidsmåter og tekniker
som Lean Startup og Business Canvas til å strukturere arbeidet sitt. De har gjort refleksjoner
gjengitt i rapporten, som har vært lærerik også for EVRY sine medarbeidere som har vært
involvert i prosjektet
EVRY er tilfreds med hvordan gruppen har jobbet selvstendig gjennom perioden denne våren.
De har etter felles ønske brukt mye tid hos oss, som har vært viktig for å kunne ta kjappe
diskusjoner og fatte avgjørelser – og for å unngå unødvendig tidsbruk til mailutveksling og
formell kommunikasjon. Gruppen har selv tatt initiativ til å sette opp møter, intervjuer og avtaler
de har hatt bruk for og kommunisert ryddig gjennom ukentlige statusmøter.
Vennlig hilsen
Andreas Røe
Avdelingsleder Utvikling
1.3 B​
akgrunn for oppgaven
Forretningsvertikalen Information Logistics (IL) har en portefølje av systemer innen området
“Information Logistics” og distribuerer store mengder dokumenter og meldinger både til
privatpersoner og foretak. Til privatpersoner er dette ofte regninger, lønnsbrev, årsoppgaver og
6
innhold som gjerne kan distribueres elektronisk. Fordelene med elektronisk distribusjon kan være
blant annet økonomisk lønnsomhet, miljøøkonomisk lønnsomhet og å møte kunder der de
forventer å få informasjon.
Illustrasjonen under viser i grove trekk en logisk beskrivelse av flyt i disse systemene
Figur 2 - Modell av multikanal.
Tjenestens hovedstruktur er vist i figuren over. Kunden sender en eller flere filer som skal benyttes
for å skape dokumentene og sørge for at de distribueres til fakturahotell og rett mottager i ønsket
kanal. Tjenesten har basisfunksjonalitet og en rekke opsjoner som kan bestilles. I figuren over er
basistjenesten vist med blått, og opsjonene er vist med grønt.
Basistjenesten sørger for å distribuere dokumentene til fakturahotell samt til valgt utgående kanal
basert på innhold i filen som kommer fra kunden. Det holdes oversikt over hvilke dokumenter som
er distribuert hvor, samt oversikt over leveringskvitteringer fra de forskjellige kanaler.
Det kan bestilles en rekke opsjoner:
➢ Oppsett og konfigurering av utkanaler som nettbank, SMS, e-post, print, digipost og EHF.
➢ Produksjon av visuelt format (PDF) for fakturahotell eller andre kanaler.
7
➢ Oppsett av regler for én til én kommunikasjon og inkludering av forskjellige tekst- og
designelementer basert på segmentering av mottagere.
➢ Remote Collaboration som gjør det mulig for flere aktører og “eie” deler av dokumentet.
1.3.1 Bedriftens målsetninger
EVRY tilrettelegger en database som inneholder statistikk over distribusjoner for gitte utstedere. I
tillegg til databasen gis en mal for et Business Case som synliggjør hva distributører tjener av
økonomisk inntjening ved å ta i bruk siste versjon av løsningen og overføre dagens papirbaserte
distribusjon til elektroniske kanaler som eFaktura, digipost og e-post.
Denne informasjonen skal være nødvendig bakgrunnsinformasjon for oss som gruppe til å lage en
applikasjon som kan generere verdi for selger basert på innholdet i databasen og Business caset.
Applikasjonen skal kunne brukes til å formidle markedsføringsbudskapet ovenfor aktuelle kunder.
Forventet leveranse er en kjørende applikasjon som utfører funksjonalitet beskrevet over, sammen
med en erfaringsrapport om bruk av Lean Startup til å gjennomføre oppgaven.
1.3.1.1 Spesifikke føringer for oppgaven
➢ Bruke Lean Startup og Lean Canvas til å synliggjøre oppgavens omgivelser og styre
gjennomføringen av prosjektet.
➢ Gruppen skal i periodene utdanning tillater det jobbe i EVRY sine lokaler på Fornebu.
➢ Ingen tekniske begrensninger utover koblingen til database (Oracle) og at løsningen skal
kunne kjøre på RedHat Linux.
8
1.3.2 Gruppens målsetninger
Målet med prosjektet er å utvikle en applikasjon som kan generere markedsføringsverdi for
produkteier og andre ansatte i EVRY i forbindelse med deres arbeid.
Hensikten med applikasjonen er å kunne gi selger konkrete tall på hvilke besparelser kunden kan få
ved å sette ut dokumentdistribusjonen til EVRY. Gevinsten i dette er at salgsbudskapet blir sterkere,
og kunden får konkrete tall å relatere til.
Dagens system ville krevd mye manuelt arbeid for å få generert et presist kostnadsbilde for kunden.
Derfor ønsker vi å utvikle en løsning som gjør at brukeren enkelt kan medbringe seg et
salgsbudskap som kan framvises på mobil, nettbrett eller PC.
Løsningen som skal utvikles vil ha muligheter for utvidelse som legger til rette for videreutvikling
internt i EVRY. Sammen med applikasjonen ønsker vi å levere grundig dokumentasjon på
produktet.
1.3.3 Hvordan vi fikk oppgaven
Høsten 2014 var vi med på ​
Dagen@IFI​
som arrangeres av studentene ved Institutt for
Informasjonsteknologi ved Universitet i Oslo. Her traff vi mange interessante oppdragsgivere. Vi
fikk god kontakt med flere, og fulgte opp med å maile rundt relevant info om gruppen til de aktuelle
oppdragsgiverne. Vi hadde også opprettet en åpen søknad som vi delte gjennom venner og sosiale
medier.
Rundt juletider fikk vi innkalling til et møte hos EVRY på Fornebu. Her gjennomgikk vi oppdraget
de ønsket løst, og vi argumenterte for hvorfor vi var de rette til å løse det. Oppgaven berørte
retail-segmentet av EVRY sine arbeidsområder. Dette passet oss veldig godt, da to av
9
gruppemedlemmene har meget god kjennskap til fagfeltet med nesten fem års samlet erfaring med
drift og support i en av de største aktørene innenfor retail i Norge.
Vi takket ja til oppgaven grunnet interessen for utviklingsmetodikken, vår tro på at oppgaven var
overkommelig innen vårt tidsperspektiv, og var veldig fornøyd da EVRY hadde lyst til å satse på oss
når det kom til gjennomføringen.
1.4 Beskrivelse av applikasjonen
Figur 3 - Skjermdump, førsteside av applikasjon.
Vår applikasjon er en lønnsomhetskalkulator som gjennom fem steg viser bedrifter som allerede
benytter en eller flere av EVRYs kanaler hvordan de kan oppnå økonomiske besparelser ved å bedre
utnytte disse kanalene samtidig som den viser nye og aktuelle kunder hva de sparer ved å gå over til
EVRY sine løsninger. Applikasjonen fungerer som et hjelpemiddel for en selger som er ute hos
kunden ved at den på en enkel og visuell måte viser kunden konkrete tall, og vil derfor gi selger et
tydeligere salgsbudskap, men skal også fungere som et markedsbudskap som skal kunne
sendes/ligge tilgjengelig for potensielle kunder slik at de selv kan gå igjennom applikasjonen selv.
Om de skulle konkludere med at det EVRY tilbyr er noe som de og deres bedrift kunne tenke seg å
lære mer om, kan de velge om de vil bli kontaktet av en selger/kontaktperson hos EVRY.
10
Kapittel 2: Innhold (Kravspesifikasjon)
Forord
2.1
Innledning
2.2
2.2.1
Bakgrunn for oppgaven
Systemkrav
2.3
Oppdragsgivers krav til funksjonalitet
2.3.1
Ønsket tilleggsfunksjonalitet
2.3.2
Tekniske krav
2.3.3
Krav til koden
2.3.4
Grensesnit​
t
2.4
Generelt om design
2.4.1
Bruk av branding og fonter
2.4.2
Dokumentasjonskrav
2.5
Konklusjon
2.6
11
2.1 Forord
Hensikten med å spesifisere krav til applikasjonen er å gi utviklere og oppdragsgiver en fastsatt
enighet og forståelse av hvilke krav applikasjonen skal oppfylle. Kravspesifikasjonen definerer en
klar ramme på det som angår funksjonalitet og tilhørende design. Vi følger utviklingsmodellen Lean
Startup som nevnt i flere andre deler av rapporten. Utviklingsprosessen foregår kombinert med
bruk av Trello. Dette vil si at vi leverer produktet i inkrementer fortløpende, slik at deler av
funksjonaliteten blir implementert underveis. Funksjonaliteten får godkjenning av produkteier, og
blir med andre ord godkjent av kunden. Kravene til prosjektet blir gitt som enkeltfunksjoner, og
anmodninger om å vinkle design i en retning av andre eksisterende løsninger. Implementasjon av
funksjonaliteten blir forklart i prosess- og produktrapportene.
Kravene som blir satt blir i hovedsak delt i to forskjellige kategorier - ​
must have​
og ​
nice to have​
.
Naturlig nok blir minimumskravene som er ​
must have​
prioritet 1, mens ekstrafunksjonalitet som er
nice to have​
blir ansett som funksjonalitet eller andre ​
fix​
som kan implementeres om det er ressurser
til det.
Kravspesifikasjonen har fungert som et veiledende dokument for gruppen, og har endret seg hyppig
underveis i prosjektets løp. Dette kommer av at vi har vært gode til å selge våre egne forslag når det
kom til funksjonalitet til produkteier, men også fått oppdaterte kriterier fra produkteier.
2.2 Innledning
Prosjektet gjennomføres som et avsluttende hovedprosjekt av oss som studenter ved Høgskolen i
Oslo og Akershus avdeling for ingeniørutdanningen for EVRY. Det skal produseres en applikasjon
som kan kjøres på alle enheter som er etter dagens standard. Applikasjonen utvikles med tanke for
at den vil kjøre på mobile enheter som nettbrett og smarttelefoner, men også kunne kjøre feilfritt på
desktop.
12
Applikasjonen skal ha samme funksjonalitet på desktop- og mobile enheter. Det vil bli en forskjellig
opplevelse å bruke applikasjon på forskjellige plattformer, dette for å tilpasse opplevelsen for små
skjermer, og for å utnytte større skjermer for plattformer som har det. Helhetsinntrykket skal
bevares, og gå på tvers av plattformer.
EVRY har mulighet, og vil videreutvikle applikasjonen etter vårt opphold om vi ikke skulle bli
ferdig. På grunn av at det stadig kommer fram mer funksjonalitet som ønskes implementert, så er
det mulig at det dukker opp ønsket funksjonalitet i etterkant.
Innledningsvis hadde vi en meget løs kravspesifikasjon fra EVRY sin side om funksjonalitet. Den
bestod bare av kompabilitet ovenfor rammeverk, og hadde ingen spesifikke krav til funksjonalitet.
Det ble tegnet en rød linje av hva EVRY ønsket applikasjonen skulle kunne gjøre, men utover det
fikk vi frie tøyler. For å kunne kjøre oppgaven i kombinasjon med Lean Startup var det helt
nødvendig å ha en kravspesifikasjon som var på grensen til ikke-eksisterende for å kunne gi Lean
Startup hensikt. Dette medførte at kravspesifikasjonen ble til underveis i utviklingsprosessen. Krav
til design og kode har blitt satt i samarbeid med EVRY i løpet av prosjektets varighet.
2.2.1 Bakgrunn for oppgaven
Som opplyst om i presentasjonen i første kapittel er formålet med applikasjonen å genere verdi for
selger via et salgsbudskap i form av en lønnsomhetskalkulator. Applikasjonen gjør utregninger på
hva en eksisterende eller potensiell kunde kan tjene på å utsette blant annet print, faktura og
oppbevaring av disse i fakturahotell. Applikasjonen baserer seg på kostnadene som er
markedsstandard for nevnte tjenester.
Det er per i dag ingen applikasjon som gjør tilsvarende utregninger for potensielle kunder eller
selger. Derfor er det framlagt et ønske fra EVRY om å utvikle en applikasjon som på en fin måte
kan framlegge gode salgsargumenter gjennom utregninger og informasjon rundt tjenestene EVRY
kan tilby.
13
2.3 Systemkrav
EVRY sine innledende krav til applikasjonen var at den var kjørbar på Red Hat Linux og kunne
benyttet seg av en tilkobling til en Oracle-database. Utover dette hadde vi relativt frie tøyler, men vi
vil likevel spesifisere hvilke ønsker om funksjonalitet som er kommet fram underveis.
2.3.1 Kundens krav til funksjonalitet
Følgende funksjonalitet er krav vi har satt i samarbeid med produkteier. Ønsket funksjonalitet er
resultater av hva som kom fram som ønskelig under intervjuer med brukerne.
Utregning:
➢ Applikasjonen skal kunne gjøre en utregning på spesifiserte tall over kostnader for ulike
tjenester. Dette innebærer at utregningen skal kunne være fleksibel ovenfor input, og
utregningen skal endres dynamisk med user input.
Omdirigering av printkanal til digitale kanaler:
➢ Utregningen skal vise mulig besparelse over å flytte papirbaserte fakturaer til digitale
kanaler som digipost og eFaktura.
Utnyttelse av whitespace:
➢ Applikasjonen skal kunne gjøre en utregning på hva en kunde kan spare på å utnytte det
hvite rommet på en faktura som ikke blir utnyttet. Besparelsen kommer hvis kunden kan
utnytte whitespace i den grad at det ikke lenger er behov for å sende ut en individuell
forsendelse med eksempelvis et markedsbudskap eller tilleggsinformasjon.
14
Utnyttelse av konvolutt:
➢ Applikasjonen skal gjøre en utregning på hva en kunde kan spare på å utnytte hver enkelt
konvolutt til sitt potensiale. Dette innebærer å legge ved ekstra markedsbudskap i form av
reklame eller lignende i samme forsendelse. Ønsket scenario er at kunden skal slippe å måtte
sende en individuell forsendelse for å oppnå det samme som kunne blitt oppnådd i en
konvolutt. Dette er mulig ved og ikke overskride kriteriene for vektklassen konvolutten
sendes i.
Feilhåndtering i forbindelse med digitale kanaler:
➢ Denne funksjonaliteten innebærer å kunne spare kunden for kostnaden som tilhører og
manuelt måtte gå over alle digitale forsendelser som feiler. I praksis vil applikasjonen sende
digitale forsendelser på print/papir hvis noe skulle gå galt under den digitale forsendelsen.
Portooptimalisering:
➢ Grunnet EVRY sin allerede store portefølje av kunder, vil man kunne oppnå en besparelse
med å sende store volum med forsendelser gjennom EVRY. I praksis vil man få rabatter fra
posten hvis man sender et volum som overgår en satt sum. Derfor vil mindre kunder oppnå
den samme rabatten når de sendes sammen med kunden som sender ut større volum.
Applikasjonen skal informere kunden om denne muligheten, og hva den er verdt for
kunden.
2.3.2 Ønsket tilleggsfunksjonalitet
Følgende krav er funksjonalitet som har blitt ansett som ​
nice to have ​
av oss og produkteier under
utviklingsprosessen. Funksjonaliteten er ikke nødvendigvis implementert i applikasjonen, men det
vil være hensiktsmessig å utforske mulighetene for implementasjon i framtiden.
15
Komme i kontakt med selger:
➢ Funksjonaliteten innebærer at en potensiell kunde kan på egenhånd gjennomgå løpet i
applikasjonen. Informasjonen og utregningene skal bli lagret og bli sendt til en e-postkonto
hos EVRY, og brukeren skal ha mulighet for å ​
hake av​
for å bli kontaktet av en selger.
2.3.3 Tekniske krav
➢ Applikasjonen skal kunne kjøres på en Red Hat Linux server.
➢ Applikasjonen skal kunne kjøres på Android-enheter som kjører operativsystemversjon 4.0
eller nyere.
➢ Applikasjonen skal kunnes kjøres på iOS-enheter som kjører operativsystemversjon 6.0 eller
nyere.
➢ Applikasjonen skal kunne kjøres på Desktop-enheter som kjører de mest kjente nettlesere.
○ Internet Explorer release: 10.0 eller nyere
○ Chrome release: 42.0.2311.90 eller nyere.
○ Mozilla Firefox release: 37.0.2 eller nyere.
○ Opera release: 28 eller nyere.
○ Safari release: 6.2.5 eller nyere.
➢ Utregningene skal skje skjult for brukeren, og formelen skal ikke være direkte synlig for
kunden.
➢ Brukere skal oppleve applikasjonen som responsiv, dynamisk og hurtig.
➢ Bruk av nettverksressurser skal være minimal.
➢ Det skal være enkelt å navigere fram og tilbake i applikasjonen.
2.3.4 Krav til koden
Alle kommentarer og kode skal skrives på norsk, og dette skal være en konsekvent regel. Ellers skal
det tilstrebes at koden er mest mulig oversiktlig, slik at koden lett kan overtas og vedlikeholdes.
Ryddig kode gjør det også lettere å videreutvikle for EVRY etter prosjektets varighet.
16
Det skal tilstrebes å navngi klasser, metoder og variabler med så selvforklarende navn at omfattende
kommentering ikke er nødvendig. Koden skal struktureres slik at utvidet funksjonalitet lett kan
implementeres.
2.4 Grensesnitt
Vi har under hele løpet forsøkt, etter beste evne, at applikasjonen skal ha et design som tilsvarer
det EVRY bruker på sine andre offentlige grensesnitt. Dette innebærer å bruke tilsvarende fonter
og logoer som blir brukt på deres hjemmeside.
Dette er et valg vi selv har fattet, da det allerede fantes eksisterende arkiver med det vi måtte trenge
av logoer og lignende. Det ga oss også en fin linje vi kunne følge.
2.4.1 Generelt om design
Vi har i hovedsak tatt egne avgjørelser på hvordan applikasjonen skal se ut, og har fått gode
tilbakemeldinger på produkteier på de avgjørelsene vi har tatt. Oppsummert har vi prøvd å innfri
følgende punkter:
➢ Applikasjonen skal ha et logisk design på både Desktop og mobile enheter.
○ Elementer skal ha en størrelse som tilsvarer normalen i markedet.
➢ Navigasjon skal oppleves som enkel og feiltolerant. Det skal være intuitivt å navigere seg
gjennom prosessene i applikasjonen.
➢ Grafiske elementer skal ha et flatt utseende, og det skal ha et moderne preg i forhold til
dagens standarder.
➢ Brukere skal sitte igjen med et helhetlig inntrykk av at applikasjonen er ferdigutviklet til
enhver tid.
17
○ Det skal ikke finnes døde lenker, synlig kode, kryptiske feilmeldinger.
➢ Ikonet for applikasjonen skal være i tråd med andre applikasjoner på sitt respektive
operativsystem.
➢ Hvis brukeren skal motta push-meldinger, skal meldingen være kortfattet og i tråd med
grunnlaget for varslingen.
➢ Designet skal være lett å oppdatere med tidens gang.
○ Moderne design står ikke stille, derfor kan ikke applikasjonen gjøre det heller. Dette
må være lett å vedlikeholde over lengre tid for å holde designet tidsriktig.
2.4.2 Bruk av branding og fonter
➢ Det skal konsekvent brukes farger som er å finne i det sentrale designet som EVRY fører.
➢ Det skal konsekvent brukes samme font som er å finne i tekst på EVRY sine applikasjoner
og sider.
➢ Ved bruk av logoer skal det brukes bilder som er skalert riktig.
○ Det vil si at bildet ikke skal være for stort, og ikke for lite for enheten bildet kjøres
på.
2.5 Dokumentasjonskrav
Kravene til dokumentasjonen fra oppdragsgiver er:
➢ Dokumentasjonen skal kun publiseres etter ​
need to know​
prinsippet.
○ Herunder faller kontaktpersoner i EVRY og veileder og sensor ved Høgskolen i Oslo
og Akershus.
➢ Dokument- og informasjonsforvaltning skal skje i tråd med taushetserklæringer som er
undertegnet av samtlige gruppemedlemmer.
➢ Dokumentasjon i form av sluttrapport skal ikke diskuteres med andre personer enn de
nevnte før sluttproduktet er lansert.
18
2.6 Konklusjon
Kravspesifikasjon har vært til stor hjelp i prosessen med å konkretisere prosjektets omfang og
rammer. Grunnet naturen i Lean Startup har vi aldri operert med en kravspesifikasjon som var satt
i stein. Kravspesifikasjonen har i motsetning til andre planmetodikker vært fleksibel og tilgjengelig
for tilpasninger.
Vi gjorde det enkelt for oss selv med å følge samme designveien som allerede finnes på EVRY sine
hjemmesider. Dette la et godt fundament for designet, og vi slapp på denne måten å oppfinne
kruttet på nytt. Funksjonalitetsmessig har kravene dukket opp underveis, og dette har prosjektet
taklet godt takket være bruken av smidig utviklingsmetodikk. Dette sørget også for at produktet var
brukbart når vi leverer det fra oss, siden det fortsatt kan gjøres implementasjoner inkrementelt.
Det ferdige produktet skal tilfredsstille alle de krav vi har oppført som første prioritet(​
need to have)​
.
Dette gjelder for det som måtte angå funksjonalitet, design og kode. Ekstrafunksjonalitet kan ved
behov implementeres som inkrementer i etterkant. Det ferdige produktet vi leverer fra oss har i
skrivende stund ingen ekstrafunksjonalitet som ikke er implementert. Vi har derimot ingen tvil om
at det er rom for utvidet bruk av applikasjon, og ​
håper​
det vil fortsette å komme oppdateringer til
applikasjon, slik at den kan få utvidet levetid.
Basert på det som er nevnt mener vi at overleverer et produkt som innfrir alle krav som er stilt
underveis, og det har overgått våre egne og produkteiers forventninger.
19
Kapittel 3: Prosess
Forord
3.1
Planlegging og metode
3.2
Forløp til prosjektstart
3.2.1
Arbeidsteknikker og utviklingsmetodikk
3.2.2
Lean Startup
3.2.2.1
Lean Canvas
3.2.2.2
Trello
3.2.2.3
Kommunikasjon mot produkteiere
3.2.3
Prosjektstyringsdokumenter
3.2.4
Arbeidsplan
3.2.4.1
Fremdriftsplan
3.2.4.2
Arbeidslogg
3.2.4.3
3.2.5
Arbeidsforhold
Telenor Fornebu
3.2.5.1
Pilestredet 35
3.2.5.2
Verktøy
3.3
Versjonskontroll
3.3.1
Prosjekthåndtering
3.3.2
Dokumentasjon
3.3.3
20
Utviklingsverktøy
3.3.4
Utvidelser og rammeverk
3.3.5
Utviklingsprosessen
3.4
Konseptutvikling
3.4.1
Datainnsamling
3.4.2
Målgruppe og behov
3.4.3
Gruppemøter og brainstorming
3.4.4
Presentasjon av Minimum Viable Product
3.4.5
Utvikling for web
3.5
Fordeler og ulemper med web
3.5.1
Implementering av funksjonalitet
3.5.2
Testing
3.6
Utforming av brukergrensesnitt
3.7
Navigasjonsvalg
3.7.1
Fargevalg
3.7.2
Grafikk
3.7.3
Personvern
3.8
Kravspesifikasjons og dens rolle
3.9
3.9.1
Bakgrunn for kravspesifikasjon
Rammekrav
3.9.1.1
Fortløpende endringer
3.9.1.2
3.9.2
Vår erfaring med kravspesifikasjon
21
Oppfyllelse av krav og/eller måloppnåelse
3.9.2.1
Tilbakemelding fra oppdragsgiver og kunde
3.9.2.2
Konklusjon
3.9.3
3.1 Forord
Denne rapporten skal beskrive prosessen bak utviklingen av Lønnsomhetskalkulatoren. Leseren vil
være tjent med å ha lest presentasjonsdokumentet og gjort seg kjent med helheten i
dokumentasjonen. Leseren av rapporten bør også være kjent med teknologiene og de tekniske
aspektene prosjektet er bygget på. For oppklaring rundt teknologier og tekniske faguttrykk, så
henvises leseren til ordlisten, ettersom faguttrykk vil bli brukt uten en tilhørende forklaring i
hovedrapporten.
Prosessene blir gjennomgående beskrevet for hvordan arbeidet har foregått gjennom hele
hovedprosjektet for vår gruppe. Den består av fire kapitler:
➢ Planlegging og metode: ​
Her inngår planleggingen, hvordan vi har jobbet med hverandre,
vår kommunikasjon med oppdragsgiver, prosjektstyring og hvordan vi har fordelt arbeidet
oss i mellom. Herunder vil det også bli begrunnet valg av verktøy og teknologi som er blitt
tatt i bruk.
➢ Utviklingsprosessen: ​
Beskriver prosessen fra oppstart til programmering, funksjonalitet
og design. Her vil vi gjøre rede for de valgene vi har tatt, og vi vil også gå inn på problemene
som har møtt oss på veien til et ferdig produkt.
➢ Kravspesifikasjon: ​
Hvilke krav som var satt av arbeidsgiver til vårt ferdige produkt, og
hvordan vi har forholdt oss til det.
➢ Avsluttende del: ​
Her vil vi presentere våre tanker rundt utbytte av å gjennomføre et
hovedprosjekt, og hvor fornøyd vi ble med det endelige produktet.
22
3.2 Planlegging og metode
God planlegging og utnyttelse av tilgjengelige ressurser er kritisk for å gjøre et godt prosjekt. I dette
kapittelet vil vi beskrive metodikk, teknikker, verktøy og andre ressurser som i stor grad har bidratt
til å gjøre prosjektet til en suksess.
3.2.1 Forløp til prosjektstart
Det første gruppemøtet fant sted tidlig på høsten 2014. Agendaen for møtet var å kartlegge tanker
og ideer. Vi ønsket å drøfte hva type prosjekt vi ønsket å gjennomføre. Møtet var preget av god flyt
av ideer, og stort pågangsmot for året som la foran oss.
Det ble også diskutert aktuelle arbeidsgivere som vi så for oss kunne sitte på et aktuelt prosjekt av
ønsket størrelse. Vi var avhengige av å treffe spikeren på hodet når det kom til prosjektets omfang.
Skulle vi bomme på dette punktet, ville begge ytterpunkter vært uheldig det kommende året.
Ønskelig ville vi sitte med et prosjekt som kunne fore oss med stor arbeidsmengde i løpet av hele
semesteret. Var prosjektet for lite, ville vi hatt problemer med å få delegert tilstrekkelig arbeid til
hvert av gruppemedlemmene. Om prosjektet skulle vise seg å være for omfattende, ville vi fått
problemer med å etterlate oss et produkt vi stolt kunne sette våre navn på.
Vi anså det også som et stort pluss om bedriften hadde tidligere historie med å utlyse prosjekter til
bachelorstudenter. Dette var lett å undersøke med å gjennomgå tidligere prosjektoppgaver som
ligger tilgjengelig på HiOA sine sider.
Søknadsprosessen foregikk i stor grad gjennom å sende rundt vår åpne søknad gjennom våre egne
nettverk og sosiale medier. Når vi fikk interessenter på den åpne søknaden, ble vi i de fleste tilfeller
anmodet om å sende et lite skriv om gruppen sammen med karakterer.
23
Når vi ble kalt inn til EVRY for et møte i desember, tok vi raskt en avgjørelse om at dette var en
oppgave vi gjerne ønsket å jobbe med. Det grunnet i EVRY sin lange historie med å engasjere
bachelorstudenter til å løse reelle prosjektoppgaver. Utviklingsmetodikken som var fastsatt var
også en inspirasjonsfaktor, sammen med det at produktet vi skulle lage skulle produksjonssettes.
Det faktum at vi traff riktig arbeidsgiver på første møte med næringslivet var veldig motiverende,
og vi fikk bedre tid til å lese oss opp på teknologier og metodikk som inngikk i oppgaven før
semesterstart.
3.2.2 Arbeidsteknikker og utviklingsmetodikk
Smidig utvikling har de siste årene overtatt rollen som den mest brukte modellen for
utviklingsprosjekter. Ord og utrykk som Scrum, Extreme Programming, Kanban og Lean er
gjengangere i utviklingsmiljøer verden over. Dette er metodikker som er blitt godt tatt imot av
næringslivet, og blir i dag anerkjent som en hjørnestein i en effektiv utviklingsprosess. Det er ingen
enkel jobb å definere hva smidig utvikling er, og når det skal brukes, men kjernen av metodikken er:
➢ Individer og samspill framfor prosesser og verktøy.
➢ Fungerende system framfor utførlig dokumentasjon.
➢ Samarbeid med kunden framfor kontraktsforhandlinger.
➢ Å reagere på endringer framfor å følge en plan.
Utviklingsmetodene var ikke fremmede for noen av oss, da de har overtatt største delen av pensum
som foreleses på skoler rundt om i hele verden. Det er også et tema som blir skrevet bøker om, samt
at det det er mye å lese om i forskjellige mediumer for utviklere.
Når det kom til valg av utviklingsmetodikk, så var det ikke opp til oss, da det allerede var spesifisert
i oppgaven vi fikk av EVRY. Dette synes vi absolutt ikke var negativt, det var mer et krav fra vår
side at vi fikk lov til å jobbe etter en smidig modell. Det begrunner vi med at vi har relativt liten tid,
24
og var med prosjektstart ikke helt sikre hva vi egentlig skulle lage. Prosjektet var som skapt for å
følge en smidig utviklingsmodell.
Alternativet ville vært å følge en klassisk fossefallsmetode, og dette ville ikke gjort mye rom for
feiling underveis. Fossefallsmetoden legger alt for mye vekt på detaljert planstyring for et prosjekt
med varighet på kun ~fem måneder.
Bruk av Lean Startup tilrettelegger i stor grad for programmering i par, brukerinteraksjon
underveis i utviklingsløpet, og inkrementell utvikling under hele prosjektets varighet. Vi har valgt å
kombinere bruken av Lean Startup med prosjektstyringsverktøyet Trello for å kunne utnytte tiden
vi har til rådighet best mulig. Vi vil komme tilbake på hva Trello kan gjøre for prosjektstyring.
3.2.2.1 Lean Startup
Hovedessensen i Lean Startup er at du har en idé. I vårt tilfelle skulle vi komme opp med en idé som
kunne svare på oppgaveteksten som produkteier var villig til å satse på. Deretter vil man på den
letteste, kjappeste, minst ressurskrevende måten framstille idéen for den som skal kjøpe den. Man
må som gruppe erkjenne at forslaget ikke er annet enn antakelser på hvordan vi tror problemet bør
bli løst. Tusenkronersspørsmålet er om ideen er god nok eller ikke.
Vi kan med andre ord ikke faktisk vite om vår måte å gjøre det på ville fungert i markedet. Som
gruppe har vi synset fram og tilbake, og hatt dialog oss imellom, men ingen av oss kan sitte på
fasiten. Du kan også snakke med andre involverte i bruken av produktet, men det er ikke sikkert de
er enige om hva som er beste løsning de heller.
25
Figur 4 - Illustrasjon av Lean Startup.
Lean Startup en metodikk som hjelper deg fra stadiet hvor ​
tror​
du har en god løsning, til du ​
vet​
du
har en god løsning.
Det som står aller mest sentralt i metoden er læring gjennom eksperimentering. (Lean Startup avmystifisert, David Sagen, 2014). Dette vil si at vi prøver ut ulike sider av ideene man har kommet
opp med i praksis. Da blir det mest naturlig å innkalle de som skal bruke produktet til en
gjennomgang av vår hypotese på løsningen på problemet. Målet vårt da er enten å få hypotesen til å
holde vann (brukerne har lyst på produktet), eller at hypotesen skal feile(brukerne har ikke lyst på
produktet), slik at man som gruppe kan prøve ut andre ideer og hypoteser.
Poenget ligger iå gjøre dette så tidlig som mulig, og så lite ressurskrevende som overhodet mulig,
før man virkelig satser på en idé. På denne måten kan vi få en bekreftelse på at det vi lager, finnes
det en brukergruppe for som er villig til å kjøpe det vi lager. Det er kritisk å gjøre det så tidlig som
mulig, slik at man ikke bruker unødige ressurser på å lage et produkt som det ikke finnes kjøpere til.
26
Denne ​
prøve seg fram​
metodikken skal man gjøre om og om igjen, på en hypotese av gangen. Ønsket
sluttsituasjon etter hypotesetesting er at man som gruppe kan være sikker på at man har et produkt
det er etterspørsel etter, og man vil mye større sannsynlighet for å lykkes.
3.2.2.2 Lean Canvas
Figur 5 - Lean Canvas.
Et ​
Lean Canvas​
er et strategisk styringsverktøy for å utvikle nye eller dokumentere eksisterende
businessmodeller. Det er en visuell framstilling med elementer som beskriver produktets
verdiforslag.
27
Business Model Canvas var originalt utgitt av Alexander Osterwalder basert på hans tidligere arbeid
på Business Model Ontology. Siden utgivelsen av Osterwalders arbeid i 2008, har det også oppstått
spesifikke nisjer, slik som Lean Canvas som vi har benyttet oss av(The Business Model Canvas, juli
2008).
Lean Canvas som det står i dag er videreutviklet av Ash Maurya. Han utformet Lean Canvas for å
gjøre det mer interaktivt, samtidig som det skulle fokusere på entreprenørskap. Metaforen han
hadde i tankene var å bygge en taktisk plan eller blueprint fra bunnen og opp. Dette skal veilede
entreprenøren fra idémyldring til han sitter igjen med en oppstartsbedrift med suksess i
markedet(Ash Maurya, 2012).
Problem
➢ De fleste oppstartsbedrifter feiler ikke på grunn av hva de ikke får til å lage det de hadde
planlagt, men fordi de kaster bort tid, ressurser, og putter innsats i å bygge feil produkt.
Løsning
➢ Når man har forstått problemet, det er da man er i beste posisjon til å komme opp med en
mulig løsning. I vårt ​
canvas​
har vi valgt å svare på hvert av de tre største problemene med en
egen løsning. Dette gjorde vi for å ha et godt utgangspunkt til å skape et ​
Minimum Viable
Product(MVP).
Unike verdiforslag
➢ Ved å feile med å identifisere de unike verdiene med produktet kan det gå rett vest for
prosjektet. Det kan lede til bortkastede aktiviteter som for tidlig optimalisering, eller å bruke
for mye av tiden til disposisjon på feil mål. De unike verdiforslagene burde fokusere på
løsningene, og burde over tid bevege seg over til å bli nøkkelpunktene for videre vekst for
produktet i markedet.
Urettferdige fordeler
➢ En ekte urettferdig fordel er noe som ikke enkelt kan bli kopiert eller kjøpt.
Det har vi i vårt prosjekt, da produktet vi utvikler allerede har eksisterende brukere. Dette
28
er en fordel vi må utnytte for hva den er verdt, da de eksisterende brukerne ofte har en klar
indikator hva på hvilke løsninger som er verdt å løse.
Kundekanaler
➢ Det er en god idé å starte ethvert produkt med en direkte kontakt med kunden/brukeren av
produktet. Vi har hatt kunne snakket med produkteier, selgere, og andre personer som er
enten direkte eller indirekte i kontakt med produktet når det er ferdig. Det har gitt
utvilsomt gitt oss uvurderlige tilbakemeldinger på om vi er på rett vei med det vi gjør.
3.2.2.3 Trello
Figur 6 - Trello, prosjektstyringsverktøy.
Trello er et prosjektstyringsverktøy. Vi ble tipset av vår kontaktperson hos EVRY, Andreas, om å ta
i bruk dette for å holde oversikt over kortsiktige mål og arbeidsoppgaver.
Brettet består av flere lister som inneholder ett eller flere kort. Brettet representerer prosjektet, og
deretter kan man opprette lister, som man så kan fylle ut med kort. Kortene skal inneholde
arbeidsoppgaver som kan gjennomføres på noen timer, og ikke mer. Hvis oppgaven kortet
representerer har lengre varighet, burde den brytes opp i flere deloppgaver. På denne måten får
29
man en konstant følelse av ​
noe blir gjort, ​
som er en veldig god følelse i seg selv, og virker
inspirerende på gruppen.
Alle medlemmer av prosjektet kan opprette lister og kort, og enten tildele seg selv oppgaven, eller
tildele den til noen andre. Det finnes også muligheter for å kommentere på et kort, laste opp
vedlegg med mer. Trello er nettbasert, og plattformuavhengig, så vi dro god nytte av å kunne også
bruke Trello på mobil og nettbrett.
Dette var et meget godt verktøy for å kunne utnytte arbeidskapasiteten til hele gruppen. Slik unngår
man følelsen av at man ikke har noe å gjøre, da man alltids kan sjekke Trello for nye
arbeidsoppgaver.
Alternativt ville vi måtte satt oss ned og laget en langtidsplan med langsiktige mål. Dette ville vært
en metode som gikk dårlig overens med Lean Startup metodikken, da gjøremålene høyst trolig ville
bli endret underveis i prosessen. Da ville scenarioet vært at vi jobbet etter en plan som ikke stemte
overens med de faktiske gjøremålene vi hadde på agendaen, som ville vært uheldig og meningsløst.
Da ville alternativet være å utforme en ny plan hver gang det oppsto en endring. Ved å bruke Trello
unngår vi tidsbruken på å utforme en omfattende utviklingsplan, og vi kan forholde oss til små
iterasjoner som vi hele tiden kan holde oppdatert og fordele.
Oppsummert, så anser vi det å jobbe etter en smidig utviklingsmetodikk som noe spennende,
hektisk og meget lærerikt. Tidligere oppgaver i regi av studiet har vært preget av krav om planer
over veien fra A til Å fra starten av prosjektfasen. Så ved å ta i bruk Lean Startup i kombinasjon med
Trello, så har vi fått kjenne på hvordan det er å levere iterasjoner og jobbe mot konkrete delmål
underveis gjennom hele prosjektet. Trello gir brukerne en mestringsfølelse underveis, og det bygger
selvtillit hos enkeltpersoner og gruppe når man ser at man leverer varene. Vi valgte og ikke
inkludere personell fra EVRY på vårt Trello brett. Dette fordi vi ønsket å presentere endringene og
progresjonen underveis for å kunne begrunne valgene vi hadde tatt på en ordentlig måte.
30
3.2.3 Kommunikasjon mot produkteier
Gjennom hele utviklingsprosessen har vi hatt et kontinuerlig godt samarbeid med produkteier og
veileder ved EVRY. Møte med veileder Andreas Røe, har vært et fast møte i loungen på Fornebu
klokken 10 hver mandag. Her tar vi opp hva vi har gjort foregående uke, og hva vi tenker å gjøre i
uken som kommer. Andreas har under disse møtene kommet med gode forslag til oss på hvordan
han ville ha løst problemet. Han har også vært god på å trekke tråder mellom vårt prosjekt, og
erfaringer har han fra næringslivet, som har virket veldig motiverende for oss som en gruppe.
Dette ukentlige møtet har også vært tidspunktet hvor det ville vært aktuelt å ta opp om vi hadde
noen problemer med arbeidet, eller om vi sto fast på et spesifikt punkt.
Kommunikasjonen mot produkt eier, Odd Egil Orøy, har skjedd i snitt annenhver uke etter vi
startet med utviklingen. Da kaller vi som gruppe inn til møte, og framlegger hva vi har gjort siden
sist. Presentasjonen blir ledet av en av oss på gruppen, og produkteier får lede den andre halvdelen
av møtet. Da kommer gjerne tilbakemeldinger på det produkteier har fått se, og hva han ønsker å se
videre. Det er disse tilbakemeldingene som har vært største faktoren på hvordan prosjektet blir til
syvende sist. Situasjoner har oppstått der vi har vært uenige om hva vi mener det burde satses på,
men i dette tilfellet så har produkteier siste ord, og det er vi innforstått med.
I tillegg til møtene med produkteier og veileder ved EVRY, har vi også hatt møter med Siri
Fagernes, veileder fra HiOA. Siri har hatt mest fokus på fokusering på rapporten, og det med å
huske på at man er der for å lære. Hun har under hele prosjektet vært imøtekommende og
oppfordret til løpende kommunikasjon.
Alt i alt, synes vi at våre veiledere, representert fra HiOA og EVRY har gjort en strålende jobb
gjennom hele prosjektet. Kommunikasjonen har vært bra, og vi har alltid fått den hjelpen vi har
forespurt. En spesiell takk til Andreas, som har virkelig fått oss varme i trøya på Fornebu, det har
gjort at prosjektet føles enda mer reelt som en arbeidssituasjon.
31
3.2.4 Prosjektstyringsdokumenter
3.2.4.1 Arbeidsplan
Trello fungerte som vårt hovedprosjektstyringsdokument. Verktøyet ble brukt til å føre opp
arbeidsoppgaver, milepæler, og andre ting som trengte å bli gjort. Gjøremålet med høyest prioritet,
lå øverst i hierarkiet.
Vi opererte med satte milepæler fra oppstart, men arbeidsoppgavene ble opprettet som kort i Trello
underveis som det ble synlig at det var noe som måtte bli gjort. Og deretter ble oppgavene løst i
rekkefølge i henhold til prioritet.
Figur 7 - Timebox. Prosessplanlegging.
3.2.4.2 Framdriftsplan
Timebox-modellen fungerte som en oversikt om hvor vi skulle og burde være innenfor de gitte
tidsrammene. I et prosjekt som dette, så er ​
tid​
vår kapital. Denne metaforen gjorde det lettere å
forstå viktigheten av å holde seg innenfor rammene. Eksempelvis så har man ikke råd til å ta i bruk
for mye tid på å holde brukerintervjuer, siden man da vil risikere å gå tom for tid under andre
stadier. Timeboxen er satt opp med de estimatene vi trodde vi trengte for hvert stadie. Vi opplevde
et ​
happy accident​
under fase 3(Teste MVP/Finne beste MVP). Her antok vi at vi kom til å gå et par
32
runder med presentasjon av MVP, før produkteier sa seg fornøyd. Dette viste seg å ta mindre tid
enn estimert, som ga oss mer tid disponibelt til siste fase, videre utvikle MVP.
3.2.4.3 Arbeidslogg
Arbeidsloggen vår er en god blanding av commit-log på Git, og statusoppdateringer på
prosjektstyringssiden. Vi har forsøkt å gi utfyllende kommentarer på ​
commnits​
i Git for å kunne
holde en god oversikt over endringer gjort i selve koden. Git sine innebygde verktøy gir en særs god
oversikt for brukeren for å kunne se spesifikt hva som er endret. Kommentaren gjør det greit for
andre gruppemedlemmer og utenforstående for å få en kjapp beskrivelse av hva endringene utgjør i
praksis.
Statusoppdateringer på prosjektstyringssiden har fungert som en mer overordnet logg over dagens
gjøremål i sin helhet, hvilke utfordringer vi har overkommet, og hvilke vi møter til morgendagen.
Her har vi også publisert sammendrag av møter vi har hatt med produkteier og andre involverte.
3.2.5 Arbeidsforhold
Vi har nesten utelukkende jobbet på Fornebu, og kun jobbet på skolen i forbindelse med møter med
veileder fra HiOA. Slik har det vært fordi det var et ønske fra EVRY sin side at vi arbeidet i deres
lokaler. Det har også vært med praktisk rett og slett på mer tilgang på plass til fem stykker. Man skal
heller ikke legge skjul på at lokalene i Snarøyveien 30 holder en høy standard, og har en del bonuser
som gratis kaffe og veldig rimelig lunsj.
Figur 8 - Kart over arbeidslokasjon.
33
3.2.5.1 Telenor Fornebu
Vi fikk utdelt adgangskort etter juletider 2014. Adgangskortene ga oss tilgang til store deler av
bygget, ekskludert Telenor-biten av bygget. Vi fikk tilgang til å booke møterom, og vi fikk også
tilgang til stort felles areal i 5. etasje, hvor avdelingen ​
Retail ​
jobber til daglig.
Det er her vi tilbrakt mesteparten av tiden vår, siden ved å sitte så åpent og synlig, så var det lettere
å komme i kontakt med andre ansatte.
3.2.5.2 Pilestredet 35
På HiOA møtte vi veileder, Siri Fagernes, i den administrative delen av bygget. Utover dette
benyttet vi oss lite av lokalene. Det hendte at vi møttes der for å diskutere fremgang og andre
grupper sine bachelorprosjekter.
3.3 Verktøy
Vi har benyttet oss av følgende verktøy og hjelpemidler for å løse oppgaven:
3.3.1 Versjonskontroll
Et versjonskontrollsystem er et system eller verktøy som står for å dele ​
work in progress​
filer under
prosjektfasen. Dette har som hovedoppgave i å sørge for at alle jobber med samme versjon av filer,
og endringene berører alle. Det er helt essensielt at man tar i bruk en form for versjonskontroll i
prosjekter hvor det er flere utviklere som jobber med det samme.
34
Figur 9 - GitHub logo.
Git (Github)
Github er et web-basert Git pakkebrønn vertstjeneste, som tilbyr alle distribuerte revisjonskontroll
og kildekodekontrollstyring funksjonaliteten til Git, samtidig som de legger til egne
tilleggsfunksjoner. Github tilbyr et web-basert grafisk grensesnitt for desktop og mobil. Vi har
brukt verktøyet for versjonskontroll og samarbeidsmuligheter på koding.
3.3.2 Prosjekthåndtering
Figur 10 - Trello logo.
Trello
Trello er et gratis web-basert prosjektstyringsverktøy som originalt var utvikling av Fog Creek
Software i 2011, men utviklet seg til et eget selskap i 2014.
Vår bruk av Trello er beskrevet grundigere tidligere i dette dokumentet.
35
3.3.3 Dokumentasjon
Figur 11 - Google Docs logo.
Google Docs
Google Docs er et verktøy som lar deg opprette og redigere tekstdokumenter. Man har også
mulighet for å plassere grafikk. Vi anser Google Docs til å ha samme tyngde som den gamle
traveren Microsoft Word. Google Docs er i motsetning til Word - gratis og web-basert. Man har
mulighet til å dele dokumenter seg i mellom, og derfor får man innebygd versjonskontroll av
dokumentet man arbeider i med på kjøpet.
Figur 12 - Google Drive logo.
Google Drive
Google Drive er en skybasert tjeneste som tar seg av lagring og fildeling mellom angitte
medlemmer av en gruppe. Dette fungerer veldig godt i samarbeid med Google Docs. Alle Google
sine verktøy har også utmerkede smarttelefon-applikasjoner som gjør at du kan få unna arbeid på
farten.
36
3.3.4 Utviklingsverktøy
Figur 13 - Sublime Text logo.
Sublime Text
Sublime Text er en kross-plattform tekst- og kilderedigeringsprogram. Sublime er et proprietært
programvare. Det har støtte for en rekke plugins, som er utviklet og vedlikeholdt av åpen kildekode
entusiaster verden over.
Figur 14 - Dploy logo.
Dploy.io
Dploy er et utrullingsverktøy. Applikasjonen brukes til å iverksette en utrulling. Dploy innhenter
selv endringer i filer og repositories siden sist utrulling, noe som gjør det kjapt og enkelt å gjøre
utrullinger.
Videre laster den opp filene dine, kjører SSH kommandoer, og loggfører hva den gjør. Man kan
selv velge hvordan man vil bli gjort oppmerksom på endringene, men vi har valgt å motta mail som
notifikasjon på endringer.
37
Figur 15 - Protoshare logo.
ProtoShare
ProtoShare et kollaborativt verktøy utviklet av Site9. Det blir brukt for å lage, gjennomgå, og
finpusse web- og mobile applikasjoner. Vi har brukt dette verktøyet til å utvikle MVP, og for å lage
skisser til endelig produkt. Det flotte med ProtoShare er at du kan lage interaktive prototyper som
framstår som avanserte, uten å ha nødvendigvis brukt mye tid på det.
3.3.5 Utvidelser og rammeverk
Figur 16 - Bootstrap logo.
Bootstrap
Bootstrap er en gratis og åpen samling av verktøy for å lage nettsider og webapplikasjoner. Det
inneholder HTML- og CSS-baserte designmaler for typografi, skjemaer, knapper, navigasjon og
andre grensesnittkomponenter.
Det har sine røtter i utviklingen av Twitter, med mål om å ha en mer uniform kode og design.
Inspirasjonen var å få ned vedlikeholdskostnader i form av tid og penger.
38
Figur 17 - jQuery logo.
jQuery
jQuery er et JavaScript-bibliotek utviklet for å forenkle klientskripting av HTML. Det ble lansert i
2006 i New York av John Resig. jQuery er det mest populære JavaScript-biblioteket i bruk, og
brukes på 46 % av de 10.000 mest besøkte nettstedene(W3 Techs, 2010).
jQuery er fri, åpenkilde programvare, lisensiert under MIT-lisensen. jQuery syntaks er laget for å
gjøre det lettere å navigere et dokument, velge DOM-elementer, opprette animasjoner, og behandle
hendelser.
Figur 18 - HTML5 logo.
HTML5
HyperTextMarkupLanguage(HTML) er et markeringsspråk for formatering av nettsider med
hypertekst og annen informasjon som kan vises i en nettleser. HTML blir brukt til å strukturere
informasjon - angi noe tekst som overskrifter, avsnitt, lister og så videre - og kan, i en viss grad,
brukes til å beskrive semantikk i et dokument.
39
Figur 19 - CSS3 logo.
CSS3
Cascading Style Sheets(CSS) er et språk som brukes til å definere utseende på filer skrevet i HTML.
Prinsippet er at HTML-filen utelukkende skal beskrive struktur og semantikk, mens oppsett, farger
og annen stilinformasjon skal beskrives ved hjelp av CSS. Stilinformasjonen kan integreres i selve
dokumentet eller skilles ut som en egen fil med endelsen .css. Styrken til CSS, er at et ubegrenset
antall HTML filer kan styres av en enkelt .css-fil. Derfor har utvikleren også muligheten til å endre
på alle .html-filene som er linket opp til en enkelt .css-fil.
Figur 20 - iOS 8 logo.
iOS 8
iOS er et mobilt operativsystem som kjører på alle enheter utgitt av Apple. Operativsystemet har
omlag 1,2 millioner applikasjoner tilgjengelig for kjøp og nedlasting i sin App Store (​
Wong, H.
2014).
iOS har en markedsandel på 21 % i følge tall fra Q4, 2013(McCracken, H, 2013).
Vi har brukt Apple-enheter for å teste ut vår applikasjon på enheter som kjører iOS.
40
Figur 21 Android 5.0 Lollipop logo.
Android 5.0 Lollipop
Android er et mobilt operativsystem for smarttelefoner og nettbrett, og er opprinnelig utviklet av
Android Inc, som ble kjøpt opp av Google i 2005. Android er basert på en modifisert versjon av
Linux-kjernen. Google ga ut mesteparten av Android-koden under Apache-lisensen, en fri
programvare og åpen-kildekodelisens. Det er verdens mest brukte operativsystem.
Vi har brukt Android-enheter for å teste ut vår applikasjon som kjører nyeste versjon av Android.
Figur 22 - FitText logo.
FitText - jQuery plugin
FitText gjør størrelsen på fonter fleksible. Vi har brukt denne pluginen på våre flytende og/eller
responsive elementer for å oppnå skalerbare overskrifter som fyller bredden til sitt parent-element.
41
Figur 23 - jQuery mobile logo.
jQuery Mobile
jQuery Mobile er et touch-optimalisert web-rammeverk/mobil-rammeverk, mer spesifikt et
JavaScript bibliotek, som for tiden utvikles av jQuery prosjektteamet. Utviklingen fokuserer på å
lage et rammeverk som er kompatibelt med en rekke smarttelefoner og nettbrett. Dette er
nødvendig, da disse enhetene har en stadig voksende brukermasse.
Vi har tatt i bruk enkelte funksjoner som finnes i dette biblioteket for å oppnå en god
kross-plattformløsning.
jQuery Session-Plugin
En plugin til jQuery for lagring av sesjonsvariabler og informasjonskapsler med støtte for
cross-protokoll lagring.
3.4 Utviklingsprosessen
Dette kapittelet skal beskrive utviklingsprosessen som har pågått under utviklingen av
applikasjonen i flere faser. Innledningsvis vil vi beskrive første fase; konseptutvikling. Deretter vil
vi i kronologisk rekkefølge ta for oss fasen som omhandler implementering og funksjonalitet,
etterfulgt av fasen som tar for seg brukergrensesnittet.
Kapittelet vil også ta for seg utfordringer og komplikasjoner vi har møtt i forbindelse med
implementering av funksjonalitet.
42
3.4.1 Konseptutvikling
Helt siden vi møtte for første gang med EVRY, og fikk framlagt oppgaveteksten, så har vi hatt en
klar visjon om hva produktet skal gjøre for brukeren. Applikasjonen vi skulle utvikle skulle ha et
overordnet mål, og det var å kunne produsere et salgsbudskap som kunne gjøre selger av produktet
lettere. Applikasjonen skulle med andre ord gjøre det lettere å selge et eksisterende produkt i EVRY
sin portefølje.
Vi sto veldig fritt i valg av teknologi og design. De eneste kriteriene var at applikasjonen skulle
kunne kjøre på Red Hat Linux, og kunne benytte seg av en Oracle databasetilkobling. Designmessig
sto vi helt fritt, men fra starten av har vi hatt en dragning mot å legge oss litt på samme stil som
EVRY sine hjemmesider og branding generelt.
Prosessmessig var det også stilt et krav til at vi skulle utvikle etter Lean Startup modellen. Dette var
et krav som ble stilt oss, da EVRY ønsket å utforske hvordan en slik metodikk fungerte i en slik
setting vi var i.
3.4.2 Datainnsamling
Akkurat som vitenskapsmenn benytter seg av vitenskapelige metoder for å finne ut hvordan en ting
fungerer, kan vi som bachelorstudenter benytte oss av Lean Startup metoder for å finne ut hvilken
business modell som vil fungere for oss. Metodikken praktiserer:
➢ Datainnsamling.​
Observer og intervju personene som skal er logiske brukere for
applikasjonen du skal utvikle. Målet skal være å innhente kvalitativ innsikt i deres situasjon,
utfordringer og måten de bruker applikasjoner på. Underveis vil man også være avhengig
av å innhente et kvantitativt datagrunnlag for nærmere innsikt i brukermønster.
43
➢ Utform hypoteser. ​
Basert på observasjonene og innsikten man har innhente under
datainnsamlingen, kan man utforme en hypotese på problemene brukerne har, og
løsningen vi kan tilby. En hypotese skal inneholde et problem den ønsker å løse.
➢ Utfør eksperimenter. ​
Man må erkjenne at i alle fall noen av hypotesene kommer til å
feile. Det vil si at brukeren enten ikke anser løsning som hypotesen fremlegger som god
nok, eller at de ikke kjenner seg igjen i problemet. Derfor er det viktig at hypotesene er
utviklet på en måte som kan gjøre at de er målbare, og at de er i stand til å feile.
➢ Tilpass og ta læring. ​
Når man har utført disse stegene, så må man analysere utfallet og
produsere nye hypoteser basert på lærdommen fra tidligere forsøk.
3.4.3 Målgruppe og behov
Multikanal er en tjeneste som er beskrevet grundig innledningsvis i oppgaven. Tjenesten har per i
dag en betydelig kundeportefølje som inkluderer samtlige dagligvarekjeder i Norge, flere av de store
bankene, samt andre telekomaktører.
Eksisterende brukere er likevel ikke våre sluttbrukere. Våre sluttbrukere blir in-house selgere fra
EVRY, og potensielle nye kunder. Multikanal har til nå satset på segmentet med bedrifter som er av
en viss størrelse, siden de har flere fakturaer i omløp.
Selgere og produkteier har etterspurt en måte som kan gjøre det lettere å selge og markedsføre
Multikanal, så det er det behovet for applikasjon skal stå for.
3.4.4 Gruppemøter og brainstorming
Etter datainnsamlingen, som i vårt tilfelle i hovedsak besto av intervjuer, så satt vi av tid til noen
møter til brainstorming innad i gruppen. På disse møtene diskuterte vi hva som var de største
44
problemene som var verdt å løse. Vi tok informasjonen vi hadde opparbeidet under
intervjurundene, og omgjorde dette til hypoteser.
Hypotesene skulle vi omgjøre til en MVP som vi kunne demonstrere for produkteier. Vi hadde på
dette stadiet nok bakgrunnsinformasjon til å utvikle flere hypoteser, og herunder flere MVPer. Men
siden vi ville teste én og én MVP, så forlot vi brainstormingsprosessen for å kunne teste hypotesen.
Vi forlot brainstormingstadiet tidlig med en klar hensikt. Hensikten var å ta læring i
tilbakemeldingene på presentasjonen, for og deretter kunne gå tilbake i tenkeboksen, og deretter
utvikle nye MVPer som traff bedre på problemstillingen.
3.4.5 Presentasjon av konsept for produkteier
Den 23. februar hadde vi et møte med Odd Egil. Her skulle vi presentere vårt forslag til en løsning
på oppgaven. Forslaget kom i form av en MVP.
Konseptet som ble framvist var et resultat av intervjurundene vi hadde hatt, og problemene vi
hadde bestemt oss for å prøve å løse. Komponentene som utgjør grensesnittet skulle gjenspeile et
profesjonelt design som har likhetstrekk med EVRY sine nettsider og generell branding. Fargevalg
er tatt med støtte i samme beslutning.
Forsiden var seende slik ut, med en innledning for bruker, og en indikasjon på hvor mange steg det
finnes i applikasjonen. Branding er tatt direkte fra EVRY sin samling av logoer på deres intranett.
45
Figur 24 - Skjermdump. Førsteside MVP.
I grove trekk inneholdt vår MVP følgende:
➢ En velkomstskjerm med informasjon om hva hensikten med applikasjonen er.
➢ En toppmeny med faner som indikerer hvor i prosessen man er. Delt inn i tre forskjellige
faner.
➢ En hovedside hvor bruker kunne utfylle ut sine gjeldende verdier over hvilke forsendelser
de opererer med i dag, og størrelsen på volumet i forsendelsen.
➢ En siste side hvor brukeren får oppsummert sine muligheter på det som angår besparelser
de kan utnytte hvis de hadde satt ut fakturering til EVRY.
46
3.5 Utvikling for web
I dette kapittelet beskrives utvikling av funksjonalitet og brukergrensesnitt. Vi vil skrive om de
utfordringene vi møtte i forbindelse med dette. Det vil også bli omtalt forhold som har påvirket
applikasjonens utviklingsløp på det positive og negative.
Det ble logisk å inkludere utfordringene i beskrivelsen av funksjonaliteten for å forstå problemene
bedre.
3.5.1 Fordeler og ulemper med utvikling for web
Den aller største fordelen med å utvikle web-applikasjoner er at man utvikler til alle plattformer på
tvers av operativsystem. Vi har utviklet en applikasjon som kan fungere like godt på iOS og
Android, som på Windows Phone eller et annet OS. På denne måten har vi redusert tiden vi måtte
ha investert vesentlig for å ha laget en egen applikasjon for hvert OS. I tillegg til dette kan man
publisere applikasjonen raskt og enkelt, uten noen mellomledd som skal godkjenne eller ha noe
bakgrunnskunnskap om applikasjon. Eksempelvis slik som iOS sin app-store eller Google Play.
Oppdateringer og vedlikehold av løsningene er like enkle. Det er heller ingen tredjepart som skal ha
en del av salgssummen dersom man ville publisert den for nedlastning. Det er vanlig at
applikasjonsbutikker tar opptil 30 % av salgssummen når en bruker kjøper den via en app-store.
En annen fordel er at veldig mange utviklere kjenner HTML godt, så det finnes mange ressurser og
kunnskap tilgjengelig i form av bøker og informasjon på nettet. En webapplikasjon kan også
utvikles slik at det framstår som en “native” applikasjon, og kan få sitt eget ikon på hjemmeskjermen
til brukerens mobil eller skrivebord.
47
Webapplikasjoner har også sine utfordringer. En av hovedutfordringene er at det finnes mange
ulike nettlesere på tvers av operativsystemene, som alle har ulik støtte for funksjonalitet levert av
HTML5. Dette er en ganske stor utfordring når det kommer til å lage en løsning som fungerer likt
på tvers av alle nettlesere og operativsystemer. Dette er en kostnadsdriver som sluker tid i jakten på
å finne en løsning som fungerer bra på alle operativsystemer og/eller nettlesere.
En annen nedside med webapplikasjoner er at de ikke vil fungere hvis brukeren ikke har tilgang til
internett. I og med at teknologien baserer seg på web, er det verre å lage en løsning som fungerer
like godt uten nettilgang.
En mobil enhet kan ha mange ulike tjenester som en native applikasjon kan benytte fritt. Tjenester
som kamera, stedstjenester, kontaktliste, kompass og mye mer. En webapplikasjon kan også benytte
seg av en del av disse tjenestene, men ikke i samme grad som en native applikasjon ville kunnet.
Inntil videre vil det være en stor fordel for native applikasjoner å benytte mulighetene som ligger i
en mobil enhet.
Som tidligere nevnt er en av fordelene til webapplikasjoner publiseringsmåten. Det er likevel ikke
alle aspektene med publiseringsmetoden som er utelukkende positive. Brukere av mobile enheter er
vant til å finne applikasjoner i applikasjonsbutikken tilhørende sitt operativsystem. Mangelen på en
sentral applikasjonsbutikk for webapplikasjoner er en ulempe for publisering av webapplikasjoner.
3.5.2 Implementering av funksjonalitet
Enkeltutsendelse, månedlig- og årlige utsendelser.
Kort tid etter utviklingen startet ble vi enig om at det er logisk å gi brukeren valget mellom å se tall
for enkeltutsendelser, månedlig- og årlige utsendelser. Det første bildet brukeren vil møte i
applikasjonen er valget mellom disse. Valget brukeren tar vil spille inn på utregningen som følger i
de neste stegene i Lønnsomhetskalkulatoren. Implementeringen av selve førstesiden var relativt
enkelt, men det lå større utfordringer i utregningen som det er skrevet mer om i Produktrapporten.
48
Siden dette er første steg i applikasjonen har det blitt lagt ned en innsats i å få den til å se bra ut.
Skape et godt førsteinntrykk. Vi har valgt å kjøre et flatt grensesnitt, som ser moderne ut. Figur 25
illustrerer hvordan førstesiden ser ut på en mobil enhet.
Figur 25 - Skjermdump. Førsteside applikasjonen.
Utsendelsessiden, allokering av utsendelsesvolum.
Utsendelsessiden spiller ballen videre til brukeren. Her er det tenkt at brukeren selv skal fylle ut sin
bedrifts gjeldende allokering av utsendelser fordelt på kanaler. Dette har sin hensikt med å gi
brukeren et overblikk over sin bedrifts gjeldende kostnader per dags dato. Vi viderefører det flate
designet fra førstesiden, og samme fargevalg og fonttype.
49
Figur 26 - Skjermdump. Utsendelsessiden. Skritt 1.
Løsningen er implementert som faner, for å spare den dyrebare skjermplassen på mobile enheter.
Feltet til venstre i bildet er automatisk fylt ut med markedsledende priser på enkeltutsendelse av en
printet, konvoluttert og sendt A4-side. Her er det påtenkt at brukeren selv skal fylle ut hva sin
bedrift i dag betaler for samme tjenesten.
Det har vært utfordringer i å tilpasse denne funksjonaliteten for å fungere tilfredsstillende på tvers
av nettlesere og ulike plattformer. Utfordringene har vært i største grad å få det til å se pent og
intuitivt ut. I den sammenheng har vi måttet lese oss opp på jQuery-mobile og hvordan vi kan
bruke dette for å få et pent grensesnitt på mobile enheter.
Framgangsmåten er den samme på alle kanalvalgene, og utregningsmodulen regner sammen
brukerens totale volum av forsendelser, og hva det koster han i dag. Prisene som står som
50
ferdigutfylt er hva som er veiledende priser i markedet i dag, om brukeren ikke skulle være sikker
på hans kostnader knyttet til dokumentdistribusjon - kun volumet.
Sluttsummen i bunnen av siden er generert på datagrunnlaget utfylt av brukeren og videresendes til
neste side for å gjøre utregninger på datagrunnlaget som nå eksisterer.
Automatisering av kanalvalg.
Denne siden gir brukeren mulighet til å velge om han/hun har lyst til å benytte seg av opsjonen
automatisering av kanalvalg- og flytte eksisterende printvolum over til elektroniske kanaler. Den
første delen med kanalvalg hadde vi ingen utfordringer med å implementere, da den enkelt spør om
brukeren vil la Multikanal ta seg av feilhåndtering om elektroniske kanaler skulle feile.
Figur 27 - Skjermdump. Automatisering av kanalvalg. Skritt 2.
51
Det neste punktet på samme siden er et valg vi gir til brukeren om å flytte utsendinger fra
printkanalen over til elektroniske kanaler. Det var en krevende prosess å videreføre volumet som
blir angitt på den forrige siden(Figur 26), for og deretter gjøre prosentregning på det samme
datagrunnlaget. Her måtte datagrunnlaget beholde sin integritet for å kunne gjøre nøyaktige
beregninger på gjenstående utsendelser som fantes i form av printkanalen. Det kunne ikke være
mulig å flytte mer enn 100 % over til elektroniske kanaler, så derfor ble det implementert
omfattende funksjoner som behandlet reglene satt for brukerens evne til å overskride 100
%-grensen.
Figur 28 - Skjermdump. Flytting fra print til elektroniske kanaler. Skritt 2
52
Optimalisering av porto
Portooptimalisering er også en opsjon brukeren kan velge å benytte seg av. Ingen utfordringer med
implementering, men i back-end generer denne siden enda en variabel for utregningen. Hvis
kunden ønsker å benytte seg av portooptimalisering, vil det trekkes fra 20 % på det gjenstående
volumet for printkanalen. Her var det viktig at vi gjorde utregningen på det oppdaterte
datagrunnlaget som oppsto etter flytting av print til elektroniske kanaler.
Figur 29 - Skjermdump. Optimalisering av porto. Skritt 3.
Markedsbudskap sammen med forsendelser
Brukeren kan velge å sende ut markedsbudskap sammen med sitt eksisterende printvolum. I praksis
vil dette si at dersom det er plass til et ekstra ark i en konvolutt som skal sendes ut, og det ekstra
arket ikke medfører at forsendelsen får en høyere portokostnad, så kan man spare 50 % på og ikke å
sende det ekstra arket separat. Det ekstra arket kan inneholde reklame, eller annen form for
budskap som bedriften ønsker å få sendt ut til kunden. I praksis for utregningen, så vil utregningen
bli:
53
Figur 30 - Utregning på utnyttelse av konvolutt.
Det gis også brukeren mulighet til å velge å la Multikanal utnytte ​
whitespace​
. Dette er tomme
områder på et printet område som er blanke. Disse områdene kan brukes til å bringe ut
markedsbudskap og informere om kampanjer.
Figur 31 - Skjermdump. Markedsbudskap. Skritt 4.
54
Figur 32 - Utnytting av whitespace.
Under implementasjonen av eksempelframvisningen var det viktig at den ikke fungerte som en
pop-up, da dette er generelt noe brukere flest ikke liker. Det er også verdt å merke seg at en økende
andel brukere på web benytter seg av programvare som blokkerer pop-ups. Eksakt hvordan vi løste
det kan man lese om i produktrapporten.
Oppsummering
Oppsummeringssiden gir brukeren oppdatert informasjon om hvilke valg han/hun har tatt under
gjennomføringsløpet til Lønnsomhetskalkulatoren. Implementeringsmessig har det ikke vært noen
stor utfordring å videreføre valgene som er blitt tatt, da mange av valgene kan fungere som ​
boolske
variabler. Ja- eller nei spørsmål. Det gis også mulighet om å få oppsummering tilsendt på e-post, og
om du ønsker å bli kontaktet av en representant fra EVRY. Implementasjonen av funksjonen som
sender mail beskrives nøye i Produktrapporten.
55
Figur 33 - Oppsummering. Skritt 5
Figur 34 - Sluttside.
56
3.6 Testing
Testing og tilhørende prosesser er beskrevet grundig i Testrapporten.
3.7 Utforming av grensesnitt
I vårt studie, Anvendt datateknologi, har man et stort fokus på universell utforming. Det man
utvikler skal være tilgjengelig for så mange brukergrupper som mulig, om ikke alle. Derfor har vi
under utviklingen av Lønnsomhetskalkulatoren hatt et stort fokus på dette. Vi har tatt hensyn til at
en større del av brukere nå surfer på mobil og nettbrett og har derfor tatt i brukt en
utviklingsmetode som heter “mobile-first”. Dette er en metode der man i stor grad utvikler
produktet til at det først og fremst skal fungere optimalt på mobile enheter. Siden produkteier også
ville ha en løsning som virker like godt på desktop, var dette noe vi også måtte ta hensyn til i stor
grad.
3.7.1 Navigasjonsvalg
Vår forside består av 4 navigasjonsvalg som består av:
➢ En infoknapp som ligger øverst i høyre hjørne
➢ De 3 ulike typene utsendelser - Enkeltutsendelser, månedlige utsendelser og årlige
utsendelser.
57
Figur 35- Førsteside. Desktop.
Infoknappen valgte vi å legge oppe i høyre hjørne fordi dette gjør at knappen er enkel å se, samtidig
som man slipper å scrolle/lete etter den. Dette valget falt også naturlig for oss fordi vi allerede hadde
valgt et design som hadde overskriften plassert oppe til venstre.
Hvis man trykker på informasjonsknappen vil et pop-up vindu dukke om med informasjon om
siden man er på og forklare hva formålet med siden er, hvordan man oppnår dette formålet og
annen tilleggsinformasjon som kan være nødvendig
Figur 36 - Informasjon på førstesiden. Desktop.
58
I bildet over ser man de 3 andre navigasjonsvalgene på vår forside, nemlig de 3 ulike typene
utsendelser. Her velger bruker hvilken type utsendelser den vil angi senere i prosessen og blir
dermed sendt videre til valgt utsendelse.
Figur 37 - Kanalvalg. Desktop.
Her ser man et bilde av siden man kommer til etter man har valgt type utsendelse på forsiden. Her
skal brukeren selv interagere ved å sette i de verdiene de vil. I dette eksempelet har vi valgt å vise
siden for enkeltutsendelser.
Man ser igjen at vi har valgt å sette informasjonsknappen øverst i høyre hjørne. Vi valgte å gjøre
dette fordi det gir en følelse av kontinuerlighet og en rød tråd i gjennom hele prosessen.
Figur 38 - Fremgangsindikator. Desktop.
59
Videre har vi valgt å ha en fremgangsindikator ligger sentralt i toppen av alle sidene foruten
forsiden for og hele tiden gi brukeren en pekepinn på hvor langt han/hun er i prosessen.
Figur 39- Interaktivt design. Desktop.
Her ser man et nærmere bilde av selve slideren. Vi valgte nettopp denne løsningen fordi den
fungerer like godt på mobile enheter som på desktop. Den gjør det intuitivt og enkelt for brukere
som ikke har et stort tastatur tilgjengelig, som for eksempel mobiltelefoner.
Figur 40 - Manuell spesifisering av verdi. Desktop.
Man kan også manuelt sette verdien på både enhetspris som ligger i venstre input-boks. Denne
boksen inneholder tall som er satt som standard. Disse prisene er markedsstandarder og kan derfor
stemme overens med de tallene brukeren allerede bruker. Dette kan spare brukeren for noen
tastetrykk som igjen gjør hele prosessen lettere.
Til høyre kan man manuelt endre antall utsendelser ved å skrive inn verdien man ønsker isteden for
å dra i slideren. Hvis man skriver inn et tall vil slideren flytte seg og motsatt.
60
Antall utsendelser, altså tallet man får ved å dra i slideren eller skriver inn manuelt, valgte vil å legge
til venstre der hvor navnet på kanalen tidligere stod.
Den blå skriften fungerer også som knapper til de ulike kanalene slik at man ikke trenger å gå
igjennom kanalene i den rekkefølgen vi har satt den opp, og gir også brukeren mulighet til å hoppe
fritt frem og tilbake mellom de ulike kanalene.
Nederst på siden har vi lagt 2 knapper - neste og tilbake som lar brukeren navigere tilbake til
forsiden eller frem til neste skritt i prosessen som er automatisering av kanalvalg.
Figur 41- Automatisering av kanalvalg. Desktop.
Automatisering av kanalvalg er side der brukeren må ta 2 valg, nemlig om han/hun ønsker
muligheten til automatisk routing til print dersom en av de elektroniske kanalene feiler. Denne
opsjonen gjør slik av hvis en av de elektroniske kanalene, nærmere bestemt epost, sms, efaktura,
digital postkasse og EHF skulle feile under en utsendelse, vil trafikken som var tiltenkt den kanalen
som feilet bli sendt automatisk til print, noe som kan spare bruker for arbeid og ressurser. Den
andre opsjonen man kan velge er om man ønsker å flytte en prosentdel av utsendelsen/utsendelser
fra print til en eller flere av de elektroniske kanalene. Dette kan gi bruker økonomiske besparelser
grunnet at print er dyrere med tanke på diverse kostnader som for eksempler papir og blekk.
Brukeren må ta valget ved hjelp av radioknapper. Vi valgte radioknapper fordi de er enkle å treffe
på desktop og mobile enheter. Vi gjorde dette enda enklere ved å gjøre slik at man kan trykke på
61
hele feltet rundt ja eller nei, og ikke bare akkurat der knappen er. Dette vil være til stor hjelp til
brukere med begrenset motorikk eller andre begrensinger.
Hvis brukeren vil flytte utsendelser fra print til en eller flere av de elektroniske kanalene trykker
han/hun ja på dette punktet og da vil dette være det som møter brukeren
Figur 42 - Slider-navigasjon. Desktop.
Her valgte vi igjen å gå for slider løsningen fordi den som tidligere nevnt fungerer utmerket på
mobil og desktop, men også for å gi brukeren følelse om at det går en rød tråd igjennom hele
løsningen. Vi håpet at dette ville gi brukeren følelsen: “ dette har jeg vært borti før, så dette vet jeg
hvordan jeg gjør”, noe vi mener vi har fått til. Som på alle de andre sidene fungerer EVRY logoen
som en hjem knapp og det er plassert en informasjons knapp oppe i høyre hjørne.
Når man så trykker på neste knappen kommer man til neste steg i prosessen, nemlig
portooptimalisering. Denne siden har som formål å informere brukeren om hva
portooptimalisering er, og hva brukeren og/eller brukerens bedrift kan spare på å inkorporere dette
i sin virksomhet.
62
Figur 43 - Portooptimalisering. Desktop.
På denne siden fungerer fortsatt EVRY logoen som en knapp som tar deg tilbake til forsiden,
samtidig som infoknappen fortsatt har samme funksjon som tidligere, men informasjonen den
inneholder varierer fra side til side. Nytt på denne siden er radioknappene som gir brukeren valget
mellom ja og nei. Dette falt som en selvfølge for oss fordi her er brukeren nødt til å bestemme seg
om han/hun vil ta med seg tallene fra portooptimalisering videre i prosessen eller ikke. Vi valgte å
forhåndsvelge “Ja” valget fordi vi og EVRY tror at dette kan bidra til at flere velger å la den stå på
“Ja”. Nederst på siden har vi igjen lagt frem og tilbake knappene for å gi brukeren en følelse av
kontinuitet.
Neste steg i prosessen er whitespaceutnyttelse og utnyttelse av konvolutt.
63
Figur 44 - Markedsbudskap. Desktop.
Denne siden følger samme mønster som de andre sidene ved bruk av 3 store mobilvennlige knapper
samtidig som EVRY logoen, informasjonsknappen og frem/tilbake knappene har samme funksjon
som tidligere. Nytt på denne siden er at vi har lagt inn tilleggsinformasjon ved bruk av fremhevet
blå tekst som gir brukeren mer informasjon om hva whitespace er, og hva det brukes til. Her valgte
vi en pop-up løsning mye med tanke på plassen vi hadde til rådighet på de mobile enhetene,
samtidig som den ga den effekten vi ville at den skulle ha.
Det siste skrittet i prosessen er en oppsumeringsside hvor man får en oversikt over hva man har
valgt av opsjoner tidligere i prosessen. De opsjonen man har valgt tidligere i prosessen er huket av,
mens de man de man valgte og ikke ta med beregningen vil ikke være huket av. Vi valgte å sette en
regel på denne siden som sa at bruker ikke skal få lov til å legge til eller fjerne ulike opsjoner fra
beregningen, på grunn av dette ville ha medført masse arbeid som ville gjort at vi ikke ville blitt
ferdig i tide.
64
Figur 45 - Oppsummering. Desktop.
3.7.2 Fargevalg
Når det kom til fargevalg har vi prøvd å gjøre vår løsning så ren og enkel som mulig, samtidig som
vi prøvde å inkorporere fargen til EVRY. EVRY bruker en mørk blåfarge over en hvit bakgrunn,
eller hvit skrift over den samme blåfargen i sin logo, men etter å ha tilbrakt litt tid med de ansatte på
Fornebu og diverse presentasjoner senere så vi at de også brukte en lyseblå farge mye. Denne fargen
blir også brukt i stor grad på hjemmesiden til EVRY. Vi valgte derfor å prøve å bruke disse der vi så
behov, uten å gjøre vår løsning mindre lesbar for alle de tiltenkte brukergruppene. Med det mener
vi at vi har tatt hensyn til diverse konsepter slik som svart på hvit kontrast, farger som er lite
forstyrrende eller distraherende.
Hvis brukeren velger å trykke på informasjonsknappen valgte vi som tidligere nevnt å vise denne
ved hjelp av et pop-up vindu, noe som gjør at skjermen bak blir noe faset ut. Dette bidrar til at
brukeren lettere kan fokusere på den informasjonene den er ute etter.
65
Figur 46- Portooptimalisering. Desktop.
3.7.3 Grafikk
Når det kom til grafikk, fikk vi helt frie tøyler, men siden vi ville ha en løsning som fungerte like
godt på mobile enheter som på Desktop, var dette noe vi måtte ta hensyn til. Derfor har vi gått for
et grafisk grensesnitt som er rent og ryddig, med få forstyrrende elementer som tar opp unødvendig
plass. Dette ble spesielt viktig når det kom til mobilversjonen. Størrelsen på en skjerm til en
smarttelefon kan i dag variere fra 3” til circa 5,5”. Dette ga oss ikke voldsomt mye plass å jobbe med,
så derfor valgte vi et design med en grafikk som var relativt minimalistisk for å kunne utnytte den
plassen vi hadde tilgjengelig så godt og effektivt som mulig. Vi mener at ved å velge dette designet
og denne grafikken at brukeren vil få en enkel, ryddig og profesjonell brukeropplevelse.
66
3.8 Personvern
Dagens samfunn har økende oppmerksomhet på personvern, og personvernets rolle blir stadig
viktigere. Dette gjelder særlig applikasjoner som vår, som tar i bruk internett. Internettet åpner for
større muligheter for en ondsinnet tredjepart som kan ha som hensikt å stjele personopplysninger
eller annen informasjon. Derfor er det særs viktig å respektere brukeren og verne om deres
personopplysninger på en måte som tilfredsstiller retningslinjene anlagt av Datatilsynet.
Lønnsomhetskalkulatoren behandler ingen data som blir betegnet som sensitive i henhold til
Personopplysningsloven, men den behandler data som anses som personlige i henhold til samme
loven. Vi har ikke hatt et stort behov for å sette av mye tid eller ressurser i forbindelse med
opplysningene. Dette er fordi vi ikke lagrer noen opplysninger på server, de blir kun videresendt på
mail til hver respektive part. Brukeren og EVRY. Brukeren må selge godkjenne at opplysningene
blir sendt til EVRY.
Vi har ikke hatt noen store utfordringer i forbindelse med sikkerhet og personvern, da det finnes
etablerte sikre løsninger på kommunikasjon over epost.
3.9 Kravspesifikasjon og dens rolle
Kravspesifikasjonen er i stor grad bestemt av oppdragsgiver og er med på å definere prosjektets
rammer applikasjonens funksjonalitet.
I vårt prosjekt har kravspesifikasjonen hatt i stor grad en dynamisk rolle. Dynamisk i den forstand at
den har blitt endret fortløpende under utviklingsprosessen. Grunnen til dette var ikke at vi eller
oppdragsgiver ikke klarte å se for oss et ønsket sluttprodukt, men fordi det vi ønsket en smidig
utviklingsprosess der kunden kunne sitte igjen med best mulig produkt etter prosjektets varighet.
67
Ved å følge denne prosessen ville produktet ha en verdi selv om ikke all funksjonalitet ble
implementert.
3.9.1 Bakgrunn for kravspesifikasjon
Vår kravspesifikasjon som framlegges i sin helhet i kapittel 2, er et resultat av bruken av Lean
Startup i forbindelse med utvikling av applikasjonen. Følgende av å bruke Trello kombinert med en
smidig utviklingsmetode er at kravspesifikasjonen har erfart en del endringer underveis. Dette
gjelder i hovedsak endringer i forbindelse med funksjonalitet som har blitt rangert fra ​
must have​
og
nice to have. ​
Hvordan vi synes opplevelsen av Trello har vært og hvordan det er blitt brukt er
beskrevet grundigere i prosessrapporten.
3.9.1.1 Rammekrav
Rammekravene til applikasjonen ble definert i første fase av prosjektet. Oppdragsgiver hadde
allerede en klar formening om hva applikasjonen skulle gjøre, men de lot det være opp til oss
hvordan vi skulle gjøre det. Det var ønskelig fra flere hold at applikasjonen skulle være meget godt
tilpasset for bruk på mobile enheter, uten av at det skulle gå på kompromiss med følelsen av å kjøre
applikasjonen på en vanlig laptop(13”-24”).
Vi bestemte selv at vi ville kjøre et gjennomgående design som reflekterer at applikasjonen er
utviklet av EVRY, med tilhørende branding og fontbruk.
Fra et teknisk aspekt har vi også satt et krav til oss selv om å skrive kode som skal være enkel og
oversiktlig. Dette er for å gjøre det lettere å vedlikeholde koden til applikasjonen, og tilrettelegge for
et langt livsløp for vårt eget produkt.
68
3.9.1.2 Fortløpende endringer
Ettersom vi har jobbet etter smidige utviklingsprinsipper gjennomgående, så har
kravspesifikasjonen vært under kontinuerlig endring. Underveis i prosessen kom deg stadig opp
nye anmodninger om ønsket funksjonalitet fra produkteier, og ønskede endringer fra vår side. I
noen tilfeller kunne det være konkret funksjonalitet som vi mener burde implementeres, og andre
ganger kan det være presisering på punkter som allerede er spesifisert i den eksisterende
kravspesifikasjonen. Disse endringene ble fortløpende oppdatert eller lagt til i kravspesifikasjonen.
3.9.2 Vår erfaring med kravspesifikasjon
Kravspesifikasjonen har vært fungert som et dokument med generelle retningslinjer for hva som
skulle utvikles og hvordan grensesnittet skulle utformes. Kravspesifikasjonen har i stor grad
forenklet planleggingen av utviklingen.
Det har også vært betryggende å ha noe spesifikt å forholde seg til under et klassisk hektisk
utviklingsløp som smidig metodikk ofte forbindes med. Funksjonaliteten tilhørte også
kravspesifikasjonen, men kravet til funksjonalitet var i kontinuerlig endring grunnet vårt ønske og
krav satt av EVRY til å følge Lean Startup.
Vi har også fått et innsyn i hvordan et utviklingsprosjekt på et lite team blir gjort hos et privat
IT-selskap, som vi er sikre på at kan være en god erfaring videre i livet.
3.9.2.1 Oppfyllelse av krav og/eller måloppnåelse
Vi har fullført alle tekniske, funksjonelle, kodemessige og designrelaterte krav. Det foreligger ingen
ønsket tilleggsfunksjonalitet fra oppdragsgiver som ikke er fullført. Det er ytret ønske fra
69
oppdragsgiver at de selv vil kunne bruke produktet på LinkedIn for promotering, og brukerrettet
annonsering. Dette er et mål som EVRY må selv stå ansvarlig for å implementere, men som vi har
vært frampå med å få satt produktet i drift.
3.9.2.2 Tilbakemeldinger fra oppdragsgiver
Oppdragsgiver har utelukkende gitt oss positive tilbakemeldinger på hvordan vi har løst
oppfyllingen av krav. Vi har gjennom møter og dialog kommet til enighet om hva som er reelt å
oppnå i forhold til funksjonalitet i de gitte tidsrammene, men oppdragsgiver har likevel vært
imponert over produksjonsnivået.
3.9.3 Konklusjon
Den flytende kravspesifikasjonen har spilt en stor rolle for utviklingen i prosjektet. Spesialt når det
kommer til rammesetting og omfanget av oppgaven. Funksjonalitetskrav er blitt innfridd, og det
foreligger per dags dato ingenting ufullstendigheter med produktet. Vi mener det er rom for å
strømlinjeforme designet enda mer opp i mot EVRY sine standarder på produkter som er i drift,
men siden design av natur er preget av trender så vil dette være noe som alltid vil ha behov for
oppdateringer om produktet skal beholde sitt moderne preg.
70
Kapittel 4: Produktrapport
Forord
4.1
Datagrunnlag
4.2
Introduksjon til Lønnsomhetskalkulatoren på web
4.2.1
For virksomheter
4.2.1.1
Innlogging til tjenesten
4.2.1.2
For privatpersoner
4.2.1.3
Beskrivelse av applikasjonen
4.3
Lisenser
4.3.1
Funksjonalitet
4.3.2
Design
4.3.3
Info til bruker
4.3.4
Feilhåndtering
4.3.5
Dataintegritet
4.3.6
Ytelse
4.3.7
71
4.1 Forord
V forutsetter at leseren har lest presentasjonen av prosjektet i forkant av Produktrapporten. Hvis
nevnte kriterier er utført, kan dette dokumentet leses uavhengig og selvstendig. Oppbygningen i
rapporten(e) er bygd opp slik for å gi leseren et bedre innblikk i hva vår oppgave handler om, samt
gi informasjon om gruppen og vår arbeidsgiver.
Produktrapporten gir utfyllende informasjon om de tekniske aspektene rundt produktet. Vi vil
benytte samme begreper som vi ville gjort ovenfor hverandre og arbeidsgiver, så Produktrapporten
vil gi mest uttelling hvis leseren har en relativt oppdatert datateknisk forståelse. Vi henviser til
ordlisten om det skulle oppstå begrep som oppfattes som uklare.
4.2 Datagrunnlag
Vårt datagrunnlag har vært basert på informasjonen vi har fått fra oppdragsgiver, og eksisterende
priser de kjører mot kunder av Multikanal i dag. Vi har valgt å benytte oss av datagrunnlaget som
danner prisbildet på distribusjon før eventuelle rabatter for kunder med volumer store nok til å
danne sin egen prisgruppe.
Vi har valgt å benytte oss av ikke-rabaterte tall, som i de fleste tilfeller vil generere tall for en
mindre besparelse enn det som er aktuelt. Dette er fordi vi og oppdragsgiver kom til enighet om at
det er bedre at selger kan komme med et bedre tilbud enn den aktuelle kunden selv har fått generert
ved bruk av Lønnsomhetskalkulatoren. I motsetning til å komme med en skuffende melding om at
det blir dyrere.
72
4.2.1 Introduksjon til Lønnsomhetskalkulatoren på web
Web-baserte applikasjoner er en av de ledende plattformene å lansere en applikasjon på. (Edwards,
J., 2014). En web-applikasjon baserer seg som mobile applikasjoner på tjenere og klienter.
Lønnsomhetskalkulatoren baserer seg i stor grad på klienten, men man er fortsatt avhengig av
tjeneren for at brukeren skal få tilgang til applikasjonen samt for utsending av epost. Klienten vil
fortsatt ha tilgang til store deler av funksjonaliteten hvis applikasjonen lagres i cache på klientens
maskin, men brukeren vil møte begrensninger hvis koblingen mellom klient-tjener blir brutt. Dette
bruddet kan være i form av at brukeren ikke lenger er koblet til internett, eller at tjeneren skulle gå
ned.
Det har vært stort fokus på at det skal enhver tid foreligge et uniformt grensesnitt på tvers av
klientene. Uavhengig av hvilken plattform de velger å bruke for å benytte seg av applikasjonen.
Dette har vi lagt fokus på for å fremme portabilitet, som var hovedgrunnlaget for å velge å utvikle
en web-applikasjon i utgangspunktet. Disse valgene går hånd i hånd på hvordan man skal løse
skalerbarheten for applikasjonen, når man hele tiden utvikler for alle mulige plattformer og
skjermstørrelser.
4.2.2.1 For virksomheter
Det er flere mulige måter en virksomhet kan bli kjent med applikasjonen på. Vi vil gjennomgå de
måtene vi anser som mest sannsynlige.
Promotering på EVRY sine hjemmesider.
Eksisterende og potensielle nye brukere vil oppdage linken og bli interessert gjennom promotering
på EVRY sin hjemmeside. EVRY sin hjemmeside har allerede en eksisterende brukergruppe, så der
er man sikker på at promotering vil bli sett.
73
Annonsering rettet mot brukergrupper på LinkedIn.
Vår oppdragsgiver har diskutert med oss hvordan vi kan implementere applikasjonen som en
annonse på LinkedIn. Annonsen ville vist til hvilke resultater Multikanal har kunne gitt andre
virksomheter, med mulighet for at de som ser annonsen kan finne ut hva Multikanal kan gjøre for
dem. Måten de skal finne ut hva de kan spare, er å bruke vår applikasjon.
Virksomheten blir kontaktet av EVRY - som henviser til applikasjonen.
EVRY sine selgere prøver kontinuerlig å sikre seg markedsandeler i
dokumentdistribusjonsmarkedet. Selgeren vil kontakt en potensiell bedrift for å prøve å selge
Multikanal, og vil i denne sammenheng kunne bruke Lønnsomhetskalkulatoren for å forsterke
salgsbudskapet sitt.
Jungeltelegrafen - applikasjonen får friksjon i bedriftsmiljøet.
Hvis brukerne av applikasjonen er fornøyd med den, så er det sannsynlig at de vil kunne fortelle
kollegaer eller andre personer og/eller virksomheter kan være potensielle nye kunder. Dette er
trolig den kanalen vi tror vil kunne bringe flest brukere. Siden applikasjonen er så portabel og
mobiltilpasset, vil det være raskt og enkelt å kunne åpne applikasjonen på mobil eller nettbrett på
farten for å vise frem.
4.2.2.2 Innlogging til tjenesten
Vi har tatt en beslutning på og ikke implementere en innlogging for brukere. Løsningen vil være
åpen for alle, og vi vil ikke ha et eget administratorpanel i back-end. Det er flere grunner til dette
som har overbevist oss om at den åpne løsningen er den beste for vår applikasjon.
Førsteinntrykk
Hvis brukeren har sitt første møte med applikasjonen i et registreringsskjema, så er det høyst
sannsynlig at interessen for applikasjonen ikke er stor nok til å generere gjennomføringsvilje til å
registrere seg. Da risikerer vi å miste potensielle brukere av applikasjonen før vi har vist hva den
74
var god for. I den sammenhengen vil Multikanal også kunne miste potensielle brukere, og da gjør jo
applikasjonen vår det stikk motsatte av hva den er laget for å utrette.
Brukervedlikehold
Hvis brukere skulle ha egne kontoer, må man se seg nødt til å ha noen ansvarlige for
brukervedlikehold. Det ville krevd ressurser for å implementere sikkerhetstiltak på den eksisterende
brukerdatabasen, og driften av denne. Det kunne oppstått behov for support over telefon eller
lignende, for gjenoppretting av passord og glemte brukernavn.
Nødvendighet
Dette er kanskje det punktet som veier mest. En egen konto for hver bruker er det ikke behov for.
Det er ikke behov for at brukeren skal logge inn og ut, da det ikke er noen framgang som anses som
nødvendig å lagre. Å gjennomføre første til siste steg i Lønnsomhetskalkulatoren vil trolig ta noen
minutter for den gjennomsnittlige brukeren. I etterkant av gjennomføring har brukeren mulighet
til å lagre sine resultater i den forstand at han får den tilsendt på mail.
4.2.2.3 For privatpersoner
Privatpersoner vil i stor grad være påvirket av samme markedsføring som virksomheter for å
komme i kontakt med applikasjonen. Det er lite trolig at privatpersoner vil bli kontaktet av EVRY
personlig, da det er svært få privatpersoner som hadde hatt nytte av sluttproduktet Multikanal.
Likevel så tilhører jo ofte privatpersoner en eller annen form for virksomhet, så det er absolutt ikke
forkastede ressurser og brukt på å markedsføre på denne brukergruppen.
De vil i samme grad som virksomheter bli truffet av annonser, jungeltelegrafen og friksjon i
markedet hvis de tilhører et miljø som har et behov for dokumentdistribusjonstjenester.
En annen verdi vi ser for privatpersoner er for EVRY sine egne ansatte. Dette er ikke en verdi som
kan måles i kroner og øre, men kan skape en tilhørighet og stolthet for de det måtte gjelde. Det er
75
nok ikke veldig lett å forklare et familiemedlem eller en venn om dokumentdistribusjon, og derfor
kan den det måtte gjelde vise fram Lønnsomhetskalkulatoren for å beskrive hva eller hun jobber
med.
4.3 Beskrivelse av applikasjonen
Følgende kapittel vil ta for seg en beskrivelse av applikasjonen og dens funksjoner på et teknisk
plan, med konkrete eksempler i form av kode.
4.3.1 Lisenser
Applikasjonen er utviklet av oss, men eies av EVRY ASA. Derfor er videre modifisering helt opp til
EVRY ASA ene og alene.
Verktøy og rammeverk vi har benyttet oss av er lisensiert under:
➢ GNU General Public License, version 3.
○ https://www.gnu.org/licenses/gpl.html
➢ The MIT License.
○ http://opensource.org/licenses/MIT
➢ Creative Commons Attribution 4.0 International Public License.
○ https://creativecommons.org/licenses/by/4.0/legalcode
4.3.2 Funksjonalitet
Selve utregningen for besparelse, som er den viktigste funksjonen i Lønnsomhetskalkulator starter i
steg nummer to, utsendelses-siden og avsluttes på siste side, sluttside. Vi vil nå gå gjennom
funksjonalitet på de fem forskjellige stegene som til slutt vil vise besparelsen.
76
Første side - utsendelse
Hovedfunksjonene på dette steget er å regne ut grunnkostnaden til utsendelser basert på
enhetspriser og antall utsendelser av hver type. For å få til dette, finner vi seks såkalte sliders på
siden. Sliderne er egentlig HTML5-range inputs, som tolkes av en jQuery Mobile modul som står
for transformeringen til funksjonelle “baner med håndtak”. I tillegg til banen, vil jQuery mobile
modulen legge til et input/output felt som viser brukeren nåværende verdi der håndaket er,
samtidig som håndtaket oppdateres dersom man skriver inn tall i feltet.
<​
input​​
class​
=​
"add"​​
type​
=​
"range"​​
name​
=​
"slider-2"​​
id​
=​
"slider-2"​​
data-highlight​
=​
"true"​​
min​
=​
"0"
max​
=​
"250000"​​
value​
=​
"0"​​
data-unit-price​
=​
"2.5"​
/>
Eksempel på kall av slider.
Vi har gjort det slik, at hver gang et håndtak tilhørende en slider blir rørt, vil en funksjon kjøres.
Dette gjøres ved å legge alle sliders inn i en variabel, og legge til en on.change-funksjon på
variabelen. Denne funksjonen ganger så verdien til håndtaket der det er når det “slippes” med
data-unit-price. Denne summen blir så lagt til i en totalsum, som er summen av alle håndtakene sine
verdier ganget med sin tilhørende data-unit-price. Denne verdien er viktig senere i løsningen, da
den er grunnlaget for utregningen av hvor mye en bruker til slutt kan spare.
77
var​p ​
=​$​
(​
'input[name|="slider"]'​
);
p​
.​
on​
(​
'change'​
,​​
function​
(​
e​
){
var​totalsum
​
=​​
​
0;
var​price ​
​
=​​
0;
var​prisforskjell ​
​
=​​
0;
totaluser ​
=​​
0;
p​
.​
each​
(​
function​
(​
slider​
){
var​value
​
=​$​
​
(​
this​
)[​
0​
].​
value;
var​unitPrice ​
​
=​$​
(​
this​
).​
data​
(​
'unit-price')
totalsum
+=​isNaN​
​
(​
this​
.​
value​
)​​
||​$​
.​
trim​
(​
this​
.​
value​
)​​
===​​
''​​
?​​
0​​
:
parseFloat​
(​
this​
.​
value​
);
price ​
+=​isNaN​
(​
this​
.​
value​
*​
unitPrice​
)​​
||​$​
.​
trim​
(​
this​
.​
value​
*​
unitPrice​
)​​
===​​
''​​
?​​
0
:​parseFloat​
(​
this​
.​
value​
*​
unitPrice​
);
totaluser ​
=​​
(​
total​
+​
total2​
+​
total3​
+​
total4​
+​
total5​
+​
total6​
);
});
​
Utregning av grunnkostnad som initieres av berøring på en slider.
Dersom en bruker ønsker å sette egne enhetspriser for de forskjellige sliderne, gjøres dette i et
input-felt som ligger rett til venstre for slideren den tilhører. Dette feltet oppdaterer prisene både
ved “keyup” og “change” da det finnes flere måter for å legge verdier inn i et input-felt.
$​
(​
"#pris1"​
).​
on​
(​
"change"​​
||​​
"keyup"​
,​​
function​
(​
e​
)​{
}); pris1 ​
=​​
this​
.​
value;
Eksempel på hvordan priser blir satt
For å gjøre løsningen bedre tilpasset mobil og enheter med liten skjerm, har vi i flere tilfeller brukt
Bootstrap sin collapse-plugin. Denne gjør det mulig å gjemme og vise innhold ved interaksjon. På
utsendelser-siden har vi brukt denne pluginen til å pakke hver distribusjonskanal inn i hver sin
boks. Kun en boks vises av gangen, og eventuelt åpne bokser vil lukkes når en bruker velger en
78
annen kanal. Dersom bruker vil aksessere en annen kanal kan det gjøres ved å klikke på panelet til
en annen boks, eller gå til neste kanal ved å trykke inn “neste-kanal” knappen.
//Når siden lastes skal første panel være "åpent"
$​
(​
collapse1​
).​
parents​
(​
'.panel-default'​
).​
addClass​
(​
'active'​
);
//Når neste-knappen trykkes på skal det aktive panelet lukkes og neste åpnes og få fokus
$​
(​
'#neste1'​
).​
click​
(​
function​
(){
$​
(​
"#collapse1"​
).​
collapse​
(​
'hide'​
);
$​
(​
"#collapse2"​
).​
collapse​
(​
'show'​
);
$​
(​
'.panel-default'​
).​
removeClass​
(​
'active'​
);
$​
(​
collapse2​
).​
parents​
(​
'.panel-default'​
).​
addClass​
(​
'active'​
);
});
​
//gjør hele panelet sin heading klikkbar isteden for kun link
$​
(​
'#panelheading1'​
).​
click​
(​
function​
(){
$​
(​
"#collapse1"​
).​
collapse​
(​
'show'​
);
$​
(​
'.panel-default'​
).​
removeClass​
(​
'active'​
);
$​
(​
collapse1​
).​
parents​
(​
'.panel-default'​
).​
addClass​
(​
'active'​
);
});
​
//Sørger for at det alltid maks er èn collapse "åpen" til enhver tid
$​
(​
'#accordion'​
).​
on​
(​
'show.bs.collapse'​
,​​
function​​
()​​
{
$​
(​
'#accordion .in'​
).​
collapse​
(​
'hide'​
);
});
​
Eksempel på bruk av Bootstrap collapse-funksjon
Når en bruker velger en annen kanal, vil antall utsendelser bli satt i tittelen på den aktuelle boksen.
Dette gjør at brukeren fortsatt har relevant info om kanalen, samtidig som nå “overflødig”
funksjonalitet og info blir gjemt for å spare plass.
79
$​
(​
'#collapse1'​
).​
on​
(​
'hide.bs.collapse'​
,​​
function​​
()​{
if​​
​
(​
titteltall1 ​
==​​
0​
)​​
{
$​
(​
'#collapsetittel1'​
).​
html​
(​
"<span class='text-warning'></span>"​
+​
" Antall utsendelser av
print: "​
+​
"<FONT COLOR='#9F6000'>"​
+​
titteltall1​
+​
"</font>"​
);}
else​
​
{
$​
(​
'#collapsetittel1'​
).​
html​
(​
"<span class='text-success'></span>"​
+​
" Antall utsendelser
av print: "​
+​
"<span class=text-success>"​
+​
titteltall1​
+​
"</span>"​
);}
});
​
Funksjon for å sette antall i tittel på collapse-boks
Når brukeren har gjort sitt sine valg på utsendelser-siden, trykker man på knappen for “neste side”.
Verdier som er viktige for utregningen lagres da som sesjonsvariabler og informasjonskapsler hos
brukeren. Disse verdiene hentes så ut senere i løsningen og brukes videre i utregningen.
JavaScript/jQuery har ingen standardisert innebygget metode for slik lagring, så vi har valgt å bruke
en plugin kalt jQuery Session til å ta seg av dette. Variabler kan da enkelt settes og hentes med hver
sin enkle kommando.
//Sette en variabel
$​
.​
session​
.​
set​
(​
"prisPrintSession"​
,​pris1​
);
//hente en variabel
$​
.​
session​
.​
get​
(​
"prisPrintSession"​
);
Hvordan sette og hente variabler i jQuery-session plugin
Andre side - Automatisering
Hovedfunksjonen på denne siden er at bruker kan flytte antall utsendelser fra print over til
elektroniske kanaler. Antall print valgt i forrige steg hentes ut og brukes som grunnlag for
overflytting. Dersom brukes huker av på en radio-knapp for at man ønsker å flytte utsendelser, vil
en boks med forskjellige sliders vises. En maks sum blir satt til antall print som tidligere ble valgt, og
funksjon kjøres for å passe på at antall overflyttinger til elektroniske kanaler ikke overstiger denne.
Dersom antall overflyttinger til sammen når antall print satt i forrige skritt, vil man ikke kunne
80
flytte et håndtak “høyere”. Drar man et annet håndtak lavere, vil man igjen kunne dra de andre
håndtakene høyere til man igjen treffes på maksgrensen. Den samme funksjonen vil også regne ut
hvor mye prosent de forskjellige overflyttingene representerer og brukeren vil umiddelbart se hvor
mye som nå blir flyttet.
//Sjekk at total verdi for sliders ikke overstiger antall print
if​​
​
(​
totalAlle ​
>​sjekkTotal​
)​​
{
if​​
​
(​
hentSlider ​
==​​
"range1"​
)​​
{
altVerdi ​
=​sjekkTotal ​
-​total2 ​
-​total3​
;
$​
(​
"input#range1"​
).​
val​
(​
altVerdi​
).​
slider​
(​
"refresh"​
);
}
​
if​​
​
(​
hentSlider ​
==​​
"range2"​
)​​
{
altVerdi ​
=​sjekkTotal ​
-​total1 ​
-​total3​
;
$​
(​
"input#range2"​
).​
val​
(​
altVerdi​
).​
slider​
(​
"refresh"​
);
}
​
if​​
​
(​
hentSlider ​
==​​
"range3"​
)​​
{
altVerdi ​
=​sjekkTotal ​
-​total1 ​
-​total2​
;
$​
(​
"input#range3"​
).​
val​
(​
altVerdi​
).​
slider​
(​
"refresh"​
);
}
​
}
Funksjon for å sørge for at verdier ikke overstiger maks antall print.
Tredje side - Portooptimalisering
Dette steget har kun én funksjon, og det er å kartlegge om bruker ønsker portooptimalisering eller
ei. Dette velges ved hjelp av en radio-knapp og verdien blir tatt med videre i utregningen på samme
måte som tidligere. Alternativet “ja” kan kun velges dersom brukeren har utsendelser på Print, da
det er kun denne typen som har porto. En funksjon kjøres derfor for å sjekke at utsendelser til
denne kanalen er høyere enn null. Dersom en bruker prøver å velge “ja” når utsendelser på print er
null, vil man få beskjed om hvorfor valget ikke kan gjøres, og “nei” blir valgt isteden.
81
//Sjekker at bruker har fler enn 0 utsendelser før man får lov til å gå til neste side
if​​
​
(​
antallPrint ​
>​​
0​
)​{
$​
(​
"#portoJa"​
).​
prop​
(​
"checked"​
,​
true​
);
}
else​{
​
$​
(​
"#portoNei"​
).​
prop​
(​
"checked"​
,​
true​
);
$​
(​
"#portoJa"​
).​
click​
(​
function​
(){
swal​
({​ html​
:​​
true​
,​title​
:​​
"Oops!"​
,​ text​
:​​
"Dette alternativet kan ikke velges
når antall printutsendelser tidligere er satt til 0"
});
​
$​
(​
"#portoJa"​
).​
prop​
(​
"checked"​
,​
false​
);
})
​
}
​
Funksjon for å sjekke om antall print er høyere enn 0.
Fjerde side - utnyttelse
I likhet med forrige side, har dette steget som formål å ta med brukervalg videre for utregning på
siste side. Dersom man velger “ja”, vil en boks vises med nye, spesifikke alternativer. Her har igjen
brukt Bootstrap sin collapse-plugin for å spare skjermplass.
//Dersom bruker huker av på radiobutton "ja" vil innhold i "collapse 1" vises
$​
(​
'#markedja'​
).​
click​
(​
function​
(){
$​
(​
"#collapse1"​
).​
collapse​
(​
'show'​
);
$​
(​
"#whitespaceja"​
).​
prop​
(​
"checked"​
,​​
true​
).​
trigger​
(​
"click"​
);
$​
(​
"#arkja"​
).​
prop​
(​
"checked"​
,​​
true​
).​
trigger​
(​
"click"​
);
$​
(​
".obligatorisk"​
).​
text​
(​
''​
);
$​
(​
".obligTekst"​
).​
text​
(​
""​
);
});
​
Bruk av collapse for å spare skjermplass.
82
Femte side - oppsummering
I dette steget vil brukeren få en oppsummering basert på alle valg som har blitt gjort. Verdier hentes
da fra sesjonsvariabler og informasjonskapsler og danner bakgrunn for statusen til ulike
sjekkbokser. Et eksempel vil være dersom en bruker tidligere har valgt “ja” på portoptimalisering,
vil en sjekkboks på oppsummeringssiden vise dette valget.
if​
(​
onskePorto​
===​
"true"​
){
//Denne gjør slik at portooptimalisering er huket av om man har valgt dette på
​
portooptimalisering.html
$​
(​
'#portooptimalisering'​
).​
prop​
(​
"checked"​
,​
true​
).​
checkboxradio​
(​
"refresh"​
);
}
Eksempel på sjekk som setter status på sjekkboks for porto
I dette steget vil man ikke lenger ha mulighet til å påvirke utregningen, og statusen i sjekkboksene
kan derfor ikke endres. En funksjon sørger derfor for at ingen sjekkbokser på dette steget endrer
status dersom den blir trykket på. Bruker vil også få beskjed om at man må gjøre en ny utregning
hvis man vil endre valg.
$​
(​
".ui-checkbox"​
).​
click​
(​
function​
(​
event​
){
event​
​
.​
stopImmediatePropagation​
();
event​
​
.​
preventDefault​
();
swal​
({​html​
:​​
true​
,​ title​
:​​
"Gjøre endringer?"​
,​ text​
:​​
"<strong
class='text-warning'>obs!</strong> For å gjøre endringer, må du starte på nytt.",
});
​
});
​
Funksjon for å hindre at sjekkbokser kan endres
På oppsummeringssiden vil også den viktigste beregningen skje, nemlig hvor mye en bruker kan
spare basert på valg gjort i løsningen. Derfor blir alle nødvendige sesjonsvariabler og
informasjonskapsler hentet ut på denne siden. Utregning blir så gjort på bakgrunn av valg som er
83
gjort av bruker sammen med beregningsmekanismen vi har kommet frem til i samarbeid med
EVRY.
Siste side - sluttside
På siste side er målet å formidle besparelser til bruker samt innsamling av data til EVRY.
Besparelsen vises på siden, og kommer med i en epost dersom det blir skrevet inn en epostadresse.
Det vil da bli sendt ut to eposter, én til EVRY og én til adressen som bruker skriver inn. Verken
jQuery eller JavaScript har noen innebygget funksjonalitet for å sende ut epost. For å løse dette har
vi benyttet Node.js og en modul som heter Nodemailer. Node.js kjøres, i motsetning til jQuery, på
server. Derfor må dataene fra lønnsomhetskalkulator sendes til server før eposten kan bli generert.
Dette blir gjort via en POST-melding fra denne siden. Post meldingen vil da inneholde alle
sesjonsvariabler som har blitt satt, da disse er verdifulle for den som går gjennom eposten hos
EVRY.
var​mailPost ​
=​$​
.​
post​
(​
'http://anvend.me:3000/mail'​
,​​
{​
mottaker​
:​mottaker​
,​utsendelseType​
:
utsendelseType​
,​prisPerPrint​
:​prisPerPrint​
,​prisPerEfaktura​
:​prisPerEfaktura​
,
prisPerDigipost​
:​prisPerDigipost​
,​prisPerEpost​
:​prisPerEpost​
}​​
);
En liten del av POST-meldingen som sendes til server.
Mottak av data og utsending av epost - serverside
På serversiden har vi laget et Node.js-program som lytter etter data på port 3000. Dette er da porten
som data blir sendt ut på etter at utregningen er gjort ferdig i Lønnsomhetskalkulator. Når dataene
kommer inn, vil programmet generere to eposter, én til epostadressen som mottakeren selv har
skrevet inn og én til EVRY. Eposten som blir sendt ut vil inneholde et sammendrag av brukerens
valg, samt ferdig utregning, men vil være litt forskjellig avhengig av om den går til en bruker, eller
til EVRY. Eposten som går til EVRY vil inneholde alle sesjonsvariablene som ble sendt inn til
programmet, og eposten til brukeren vil inneholde en liten takkemelding, litt info, samt den
utregnede besparelsen. Programmet bruker SMTP-protokoll og Gmail til utsending slik det er satt
opp nå, min vil senere bli konfigurert av EVRY til å bruke deres egen epostutsendingsmekanisme.
84
Hvordan den ferdige eposten vil se ut er også opp til EVRY, og vil bli bestemt før den rulles ut på
deres servere. Eksempel på eposter sendt fra programmet i dag kan sees på vedlegg C og D.
4.3.3 Design
Typografi
Gjennomgående i hele applikasjonen blir det brukt samme font som på EVRYs egne websider.
Fonten er ikke standard i det fleste nettlesere, men lastet automatisk ned fra vår server ved hjelp av
en CSS regel kalt @font-face.
@font​
-​
face {
font​
-​
family​
:​evry​
;​
src​
:​url​
(​
ITCAvantGardeStd​
-​
Bk​
.​
otf)
;}
Eksempel på bruk av @font-face regel
Mye av designet i løsningen blir automatisk generert etter regler som er satt av jQuery, jQuery
mobile og Bootstrap. Det er derimot ikke overalt i løsningen at standard designregler passer
optimalt. Dette har vi løst på følgende måter som vil bli beskrevet under.
Egne CSS filer
Vi har opprettet egne CSS-filer som blir lastet inn etter CSS-filene til Bootstrap og jQuery Mobile.
CSS følger regler, ofte kalt “CSS specificity” for å bestemme hvilke egenskaper som skal gjelde. Dette
betyr at et element, for eksempel en knapp kan bli “tilbudt” mange egenskaper. Det er da den
regelen som veier “tyngst” som bestemmer elementets endelige egenskaper. Ved å legge våre
CSS-filer under de andre CSS-filene i koden, blir våre CSS-filer lastet sist. Dette gjør at regler og
egenskaper i disse CSS-filene sees på som viktigere. Disse vil da overkjøre tidligere satte egenskaper
og regler, slik at resultatet, utseende og egenskaper blir slik vi ønsker. Egenskaper som er spesifisert
85
i disse egne CSS-filene er egenskaper som vi ønsker at kun skal gjelde på en enkelt side, eller et
enkelt/få element(er).
<link​​
rel​
=​
"stylesheet"​​
href​
=​
"css/bootstrap.min.css">
<link​​
rel​
=​
"stylesheet"​​
href​
=​
"css/indexcss.css">
“Egen” CSS-fil nederst.
Modifisering av nedlastede CSS-filer
Der vi ønsket at egenskaper skulle gjelde på flere sider eller alle elementer av samme type, er dette
blitt definert direkte inn i nedlastede CSS-filer. Ved flere anledninger, har vi gått direkte inn i
kildekoden og endret egenskaper. Et godt eksempel på dette er standardfargen på alle knapper.
Denne fargen er definert i jQuery Mobile sin CSS-fil. Her har vi gått direkte inn i kildekoden til
filen og endret til en farge som kjennetegner EVRY.
.​
btn​
-​
primary​
{​
color​
:​
#fff;​
background-color:#0092c1;​
border-color:#2e6da4}
Endring av kildekode i jQuery-mobile CSS-fil.
Egne regler for forskjellige skjermstørrelser og skjermorientering
Vi har hele veien vært opptatt av at løsningen skal fungere godt på små skjermer. Derfor har vi ved
flere anledninger benyttet oss av en regel i CSS kalt @media only. Denne gjør at man kan spesifisere
egenskaper på bakgrunn av skjermstørrelse og skjermorientering. Et godt eksempel på dette er at vi
ønsker mindre luft mellom knapper på førstesiden dersom en bruker holder en enhet i
landskapsmodus. Dette er fordi man har mindre skjermplass i høyden i denne orienteringen. Vi kan
dermed forhindre scrolling ved å skrive inn én enkelt kodesetning for å overstyre
standardegenskapen som blir satt av Bootstrap og jQuery mobile.
86
@media​only screen ​
and​​
(​
max​
-​
device​
-​
height​
:​​
1000px​
)​​
and​​
(​
orientation​
:​landscape​
)​{
.​
row {
padding​
:​​
5px;
}
Eksempel på bruk av @media only regel.
4.3.4 Info til bruker
En annen viktig del av dette verktøyet er å gi brukeren informasjon om tjenester som tilbys
gjennom EVRYs distribusjonssystem Multikanal. Siden løsningen er ment til å fungere godt på små
skjermer, var vi nødt til å finne en metode for at løsningen skulle kunne gi nok informasjon og
samtidig forhindre endeløs scrolling. Til dette formålet har vi benyttet oss av en jQuery plugin kalt
SweetAlert. Denne vil kunne legge seg midt på skjermen, i forgrunnen slik at den er i fokus.
Gjennom hele løsningen vil man kunne finne info-ikoner som man kan trykke på og disse vil trigge
forskjellige SweetAlerts som vi selv har definert med relevant info.
$​
(​
"#infoEfakt"​
).​
click​
(​
function​
(){
swal​
({​ html​
:​​
true​
,​title​
:​​
"eFaktura"​
,​ text​
:​​
"eFaktura er en elektronisk faktura
som sendes fra fakturautsteder til fakturamottaker i form av en elektronisk fil i stedet for
den tradisjonelle papirfakturaen"
});
​
});
​
Eksempel på info til bruker i plassert i en Sweet-Alert
Et annet viktig punkt, er at løsningen i veldig stor grad baserer seg på JavaScript, og vil derfor være
ubrukelig dersom en bruker har skrudd av denne funksjonaliteten, eller ikke har den i sin
web-browser. Derfor gir vi bruker beskjed om at JavaScript må være aktivert allerede på første side.
Dette gjøres ved hjelp av en melding lagt i en <noscript>-tag. Denne taggen er innebygget i HTML5
og vil vises til brukeren dersom JavaScript er deaktivert.
87
<!-- Gir brukere som har JS deaktivert en melding at løsningen ikke vil fungere-->
<noscript>
​
<div​​
​
style​
=​
"​
border​
:​​
1px​solid purple​
;​padding​
:​​
10px​
">
<span>​
​
Oops! Denne løsningen krever JavaScript for å fungere.​
</span>
</div>
​
</noscript>
​
Eksempel på bruk av noscript-tag
4.3.5 Feilhåndtering
Feilhåndtering i løsningen kan sies å være to-delt. Den første, og viktigste delen er informasjon til
brukeren om hvor feilen ligger. For tekstlige beskrivelser av feil har vi benyttet SweetAlert, slik at
brukeren ikke kan unngå å legge merke til feilen. Dessuten blir det lagt til stjerner (​
*​
) i selve html
dokumentet for å vise hva som må endres av brukeren for å kunne komme til neste steg.
if​​
(​
$​
(​
'input[name=marked]:checked'​
).​
length ​
<=​​
0​
)​{
swal​
({
html​
:​​
true​
,​title​
:​​
"Oops!"​
,​ text​
:​​
"Du må velge om du ønsker å sende ut
markedsbudskap med dine utsendelser"
});
​
$​
(​
".obligatorisk"​
).​
text​
(​
'*'​
);
$​
(​
".obligTekst"​
).​
text​
(​
"Felt merket med * er obligatorisk"​
);
}
Funksjon for å vise bruker hvor en eventuell feil ligger
Den andre delen av feilhåndtering er rett og slett å forhindre at brukeren kan gjøre feil. Et godt
eksempel på dette er at brukeren ikke blir sendt til neste side, til tross for at man har trykket på
“neste-knappen” dersom man ikke har gjort et viktig valg på siden. Dette betyr derfor at visse krav
må være oppfylt, i dette eksempelet et valg må være gjort før brukeren vil få mulighet til å nå neste
side.
88
$​
(​
"#neste"​
).​
click​
(​
function​
(){
if​​
​
((!​
$​
(​
'input[name=printroute]:checked'​
).​
is​
(​
":checked"​
))​​
||
(!​
$​
(​
'input[name=elektroute]:checked'​
).​
is​
(​
":checked"​
)))​{
swal​
({
html​
:​​
true​
,​title​
:​​
"Oops!"​
,​ text​
:​​
"Du må gjøre valg i felt merket med <strong
class='text-danger'>*</strong>"
});
​
$​
(​
"#oblig1"​
).​
text​
(​
'*'​
);
$​
(​
"#oblig2"​
).​
text​
(​
'*'​
);
$​
(​
".obligTekst"​
).​
text​
(​
"Felt merket med * er obligatorisk"​
);
}
else{
​
window​
.​
location​
.​
href​
=​
'porto.html';
}
});
Eksempel på sjekk av input før man kan nå neste side.
​
Et annet godt eksempel på hindring av brukerfeil, er sjekk av input. Dette gjøres for eksempel på
input-feltene for enhetspris på utsendelser-siden. Her vil kun at bruker skal kunne skrive inn tall, da
utregningen kan bli feil om bokstaver og andre tegn blir skrevet inn. En funksjon sørger for dette
ved å inneholde tre klausuler:
1. Kun ett kommategn
2. Kun tall fra 0 - 9
3. Maks fem tegn
Funksjonen kjøres ved hvert tastetrykk, og returnerer enten true eller false. Dersom et tastetrykk
overholder regler som er satt, vil funksjonen returnere true og tegnet vil bli satt inn i input-feltet.
Dersom tastetrykket ikke overholder regler, vil det returneres false, og tegnet vil ikke bli satt inn i
input-feltet.
89
$​
(​
'.bredInput'​
).​
keypress​
(​
function​​
(​
event​
)​{
return​erNummer​
​
(​
event​
,​​
this)
});
​
function​erNummer​
​
(​
evt​
,​element​
)​{
var​tastekode ​
​
=​​
(​
evt​
.​
which​
)​​
?​evt​
.​
which ​
:​​
event​
.​
keyCode
if​(
​
(​
​
tastekode ​
!=​​
44​​
||​$​
(​
element​
).​
val​
().​
indexOf​
(​
'.'​
)​​
!=​​
-​
1​
)​​
&&
(​
​
tastekode ​
<​​
48​​
||​tastekode ​
>​​
57​
))
return​​
​
false;
else​​
​
if​​
((​
$​
(​
element​
).​
val​
().​
length​
)​​
>=​​
5)
return​​
​
false;
return​​
​
true;
}
​
Funksjon for å hindre at bruker taster inn feil.
4.3.6 Dataintegritet
En stor utfordring ved løsninger som hovedsakelig er klientbaserte, er dataintegritet. Siden
utregninger skjer på klientsiden, har brukeren mulighet til å manipulere så og si alt av data som
brukes i utregningen. Dette betyr at en bruker kan endre hele regnestykket, og “jukse” seg til en
urealistisk besparelse. Det er derfor viktig å formidle til brukeren at utregningen kun er laget for å
gi en pekepinn på hvor mye man kan spare og at tall fra utregningen ikke er bindende for noen
parter. En endelig utregning om besparelse vil skje dersom brukeren velger å bli kontaktet av EVRY
etter bruk. En erfaren representant fra EVRY vil dessuten med en gang kunne se om tall generert av
Lønnsomhetskalkulator er reelle eller manipulerte, da alle tall vil bli sendt til EVRY etter at
utregningen er ferdig.
90
4.3.7 Ytelse
Modifiserte, egenhostede javaScript og CSS-filer
Som tidligere nevnt har vi benyttet oss av jQuery, jQuery Mobile og Bootstrap. Alle tre tilbyr en
rekke funksjonalitet som vi har tatt i bruk, men også funksjonalitet vi ikke har benyttet oss av.
Heldigvis har jQuery og Bootstrap egne verktøy hvor man enkelt kan velge ut funksjonalitet man
trenger, som genererer en modifisert utgave for nedlastning. I tillegg til å bruke disse verktøyene
har vi også gått direkte inn i kildekoden for filene og tatt vekk noe “overflødig” kode. Resultatet blir
da at brukeren må laste ned mindre data, som igjen fører til at alt går raskere. I tillegg har vi valgt å
hoste alle filer selv, slik at vi er sikre på at alle filer er tilgjengelig til enhver tid. Da har vi også
kontroll på faktorer som hastighet/ytelse på hardware og software på serveren.
Figur 47 - Stor størrelsesforskjell.
91
Kapittel 5: Testrapport
Forord
5.1
Mål med testing
5.2
Verktøyer og enheter brukt ved testing
5.3
Testing
5.4
Brukertesting
5.4.1
Testing på forskjellige skjermstørrelser
5.4.2
Beta-versjon
5.4.3
Testing av sikkerhetstiltak på enhet
5.4.4
Konklusjon
5.5
5.1 Forord
I denne rapporten blir det kort og konsist beskrevet hva vi har foretatt oss for å kvalitetssikre
produktet vi har laget. Det vil bli beskrevet hvordan vi har testet, hvilke verktøy vi har benyttet og
resultatet av testene.
92
5.2 Mål med testing
Når vi skulle teste var formålet å forsikre oss om at løsningen vår fungerte tilfredsstillende på alle
tiltenkte enheter. Siden vår brukergruppe er meget bred, vil det si at løsningen vår vil bli brukt på
en stor variasjon enheter. Hovedsakelig vil det bli brukt på iOS-enheter, Android-enheter, og PCer
som kjører Windows/OS X. Vi vil at alle som bruker Lønnsomhetskalkulatoren skal få den samme
gode brukeropplevelsen, og det var dette vi hadde fokus på under testing.
5.3 Verktøy og enheter brukt ved testing
Vi testet applikasjonen på følgende enheter:
➢ iPhone 5s
➢ iPhone 6
➢ Samsung Galaxy s5
➢ iPad 2
➢ PC med Windows 7.
➢ Mac med OS X Yosemite.
Vi har testet applikasjonen i følgende programvare/nettlesere:
➢ Internet Explorer release: 11
➢ Chrome release: 42.0.2311.90
➢ Mozilla Firefox release: 37.0.2
➢ Opera release: 28
➢ Safari release: 6.2.5
93
5.4 Testing
5.4.1 Brukertesting
Funksjonalitet
Test
Resultat
Utregning
Regnestykket inkluderer
OK
input-variabler fra og gir
riktig resultat.
Omdirigering
Besparelsen med omdirigering
OK
vises med input til bruker.
Whitespace
Besparelsen med
OK
whitespaceutnyttelse vises hvis
bruker velger det.
Konvoluttutnyttelse
Besparelsen i å utnytte
OK
konvolutt inkluderes i
regnestykket og vises hvis
kunden velger det.
Feilhåndtering
Bruker har mulighet til å velge
OK
funksjonaliteten.
Portooptimalisering
Bruker har mulighet til å velge
OK
funksjonaliteten.
Navigering
Applikasjonen kan navigeres
feilfritt i på alle nevnte enheter
og programvare.
94
OK
5.4.2 Testing på forskjellige skjermstørrelser
Vi har kjørt applikasjonen på enheter med følgende skjermstørrelser:
➢ 4.7” iPhone 6.
➢ 4” iPhone 5.
➢ 5.1” Galaxy S5.
➢ 9.7” iPad 2.
➢ 13.3” Macbook Air.
➢ 24” Windows 7.
➢ 15.3” Lenovo ThinkPad.
Applikasjonen kjørte tilfredsstillende på alle enheter. All funksjonalitet fungerte på samtlige, og
applikasjonen skalerte logisk etter skjermstørrelse.
5.4.3 Beta-versjoner
Applikasjonen har gjennomgått en rekke beta-versjonutkast. Vi har hatt nyeste utgave ute
tilgjengelig på nettet hele tiden. Versjonen har derifra sirkulert til involverte i prosjektet og blitt
brukt til framvisning for produkteier.
Vi har ikke operert med versjonsnummer på beta-versjonene, da det hadde blitt vanskelig og
unødvendig å formelt gi den et versjonsnummer. Dette ville blitt overflødig da de som jobbet med
prosjektet kunne til enhver tid forholde seg til gjeldende release på GitHub.
5.4.4 Testing av sikkerhetstiltak på enhet
Lønnsomhetskalkulatoren behandler ikke data som anses som sensitive ifølge lovgivning eller
utgiver. Derfor er det ikke blitt utført noen utbredt testing på sikkerhet.
95
5.5 Konklusjon
Testingen har gitt oss en bekreftelse på at applikasjonen håndterer den funksjonaliteten som er lagt
fram i kravspesifikasjonen. Vi har også fått forsikret oss om at skalerbarheten på applikasjonen
ivaretas på alle kjente enheter.
96
Kilder
Edwards, J. (2014, april 7). Mobile Apps Are Killing The Free Web, Handing A Censored Duopoly
to Google And Apple. Hentet mai 18, 2015, fra
http://www.businessinsider.com/mobile-web-vs-app-usage-statistics-2014-4
Lov om behandling av personopplysninger(personopplysningsloven). (2000). Hentet april 11, 2015,
fra
http://lovdata.no/lov/2000-04-14-31/§2
Maurya, A. (2012, februar 1). Why Lean Canvas vs Business Model Canvas? Hentet mars 24, 2015,
fra
http://practicetrumpstheory.com/why-lean-canvas/
Ries, E. (2011). 7. Measure. In ​
The Lean Startup: How constant innovation creates radically successful
businesses​
(1st ed., Vol. 1, p. 320). London: Portfolio Penguin.
Sagen, D. (2014, september 10). Lean Startup - avmystifisert. Hentet mars 24, 2015, fra
http://open.bekk.no/lean-startup-avmystifisert
Tech, W. (Ikke datert). Usage of JavaScript libraries for websites. Hentet april 7, 2015, fra
http://w3techs.com/technologies/overview/javascript_library/all
The Business Model Canvas​
, juli 05, 2008. Hentet mars 24, 2015, fra
http://nonlinearthinking.typepad.com
McCracken, H. (2013, april 16). Who’s Winning, iOS or Android? All the Numbers, All in One
Place | TIME.com. Hentet april 7, 2015, fra
http://techland.time.com/2013/04/16/ios-vs-android/
97
Wong, H. (2014, juni 26). Apple Brings Vibrant Colors iSight Camera to Most Affordable iPod
touch-Model. Hentet april 7, 2015, fra
http://www.apple.com/pr/library/2014/06/26Apple-Brings-Vibrant-Colors-iSight-Camera-to-Mo
st-Affordable-iPod-touch-Model.html
Årsrapport 2012. (2013, januar 1). Hentet mars 10, 2015, fra
http://epub.artbox.no/evry/ar2012no/files/assets/basic-html/page15.html
Årsrapport 2013. (2014, januar 1). Hentet mars 10, 2015, fra
http://epub.artbox.no/evry/ar2013no/files/assets/common/downloads/EVRYAnnualReport
2012.pdf
98
Vedlegg A - Ordliste.
Brainstorming
Brainstorming/Idédugnad er en metode for kreativ problemløsning
tilrettelagt for en gruppe deltakere, der deltakerne impulsivt ytrer
idéer og tanker de kommer på.
Branding
Merkenavn.
Business Case
Et Business Case er en analysemetodikk som benyttes for å avgjøre
om et prosjekt eller en større aktivitet skal iverksettes.
Digipost
Digipost er et digitalt postsystem. Digipost tilbyr for alle personer
over 15 år med norsk fødselsnummer eller D-nummer en egen
“digital postkasse”.
EHF
EHF/Aksesspunkt er en tjeneste for virksomheter som skal sende
eller motta elektroniske meldinger i henhold til EHF-standarden.
Fakturahotell
Lagringsplass for fakturaer for eksterne og interne kunder.
In-house
Internt i en virksomhet.
Lean Canvas
Lean Canvas er et strategisk styringsverktøy for å utvikle nye eller
dokumentere eksisterende businessmodeller.
Lean Startup
Lean Startup er en metode innen produkt og systemutvikling.
Minimum
Viable
Product
En MVP er det produktet som kan returnere høyest mulig verdi til
minst mulig innsats.
Native
En applikasjon som er utviklet for et spesifikt operativsystem.
Open Source
Åpen kildekode betyr at kildekoden til et dataprogram er gjort
tilgjengelig for allmenheten.
PDF
PDF er et digitalt dokumentformat. Filene vises på skjerm i samme
form som de har når de blir skrevet ut.
Plugins
I databehandling, en plug-in er en programvarekomponent som
legger til en bestemt funksjon i et eksisterende program.
Portooptimali
sering
Ved portooptimalisering sendes antall utsendinger som er valgt for
print sammen med andre utsendelser.
99
Remote Collaboration
Verktøy som har mulig for at flere arbeider i samme fil eller
dokument uavhengig av hvor de er i verden.
Retail
Detaljhandel. En betegnelse for salg av varer i kvanta tilpasset
personlig eller husholdningsbehov direkte til forbruker eller
husholdninger.
Timebox
I tidsstyring, tildeler timeboxing en fast tidsperiode, kalt en
timebox, til hver planlagt aktivitet.
Whitespace
Områder uten tekst og bilder på dokumenter.
100
Vedlegg B - Papirskisser med forslag til design.
101
102
103
Vedlegg C - Eksempel på mail til bruker.
104
Vedlegg D - Eksempel på mail til EVRY.
105
106